Moje prve stretnutie s Linuxom sa spaja s nastupom do firmy, kde dodnes pracujem. Stalo sa tak na jar v r. 1996.
Informacny system bol postaveny na technologiach IBM – siet Token Ring s protokolom SNA, servery AS400, klienti x86 s operacnym systemom OS/2. ERP ProFiS od PragoDaty, databaza Progress, avsak data fyzicky ulozene v DB2. Vsetko vyspele technologie, podpora renomovanych dodavatelov, garancia kvality, bla-bla-bla.
Kym bolo uzivatelov par, vsetko chodilo skvele, ovsem s linearnym rastom ich poctu sa exponencialne generovali problemy so spracovanim dat. Ukazalo sa, ze uzkym miestom bol tzv DataServer, softver, ktory konvertoval medzi Progressom na strane aplikacie a DB/2. IBM aj Progress hrali „mrtvych brukov“ a PragoData si za danej situacie tiez velmi nevedela rady.
Ked sa pocet uzivatelov priblizil stovke, situacia zacala byt neunosna. Pomala odozva, nestabilne a strasne dlho trvajuce spracovanie (mzdova uzavierka trvala 14 hodin! a spustala sa opakovane, lebo padala, takze spravidla uspesne prebehla az cez vikend, ked bolo minimum aktivnych uzivatelov). Stres, nedovera zo strany vedenia… Co s tym, ked sa do toho investovali take peniaze?
Nakoniec PragoData prisla s radikalnym navrhom: nez investovat dalsie prostriedky do evidentne spatneho dizajnu, lepsie je hodit vsetko za hlavu a zacat s cistym stolom. Lenze co pouzit? K dispozicii boli alternativy od Sunu, HP, aj od IBM (AIX), ovsem to by stalo majlant a nebola sanca, ze na to niekto da peniaze. Naviac, firma sa „privatizovala“ a novy „majitel“ evidentne nehodlal do nej investovat – tunel je v tomto pripade jednosmerna vec ;).
Vtedy nam PragoData navrhla prejst na lacne riesenie, postavene na troch vrstvach: Linux ako SSH server, za nim Linux ako aplikacny server a za nim Linux ako databazovy server. Po niekolkych tyzdnoch vahania, zvazovania, vidiac, ze aktualny stav vedie – s podporou IBM i Progressu – do pekiel, rozhodli sme sa, ze to skusime. Niekolko mesiacov sme testovali distribuciu (Slackware), ucili sa kompilovat kernel a ladit jeho schopnosti voci existujucemu prostrediu s predpokladanym prechodom na TCP/IP.
Nakoniec sme – v priebehu jednoho vikendu – spravili toto:
- nainstalovali 4 linuxy ako SSH servery pre pristup uzivatelov k ProFiSu (firma bola vtedy uz rozdelena na matersku a 3 dcerske – tunel sa zacal rozbiehat ;)
- nainstalovali 1 linux ako aplikacny server s ProFiSom, beziacim v emulacii SCO prostrednictvom ibcs2 emulatora
- nainstalovali 1 linux ako DB server s databazou Progress/SCO, takisto v emulacii ibcs2
a cele sme to spustili, ked sme medzitym skonvertovali databazu z AS/400 na PC a uzivatelske data z Novell servera a pripravili skript, pomocou ktoreho sa kazde klientske PC zmenilo z SNA na TCP/IP klienta.
Bol to sok! Vsetko chodilo neuveritelne rychlo. Spominana uzavierka zbehla za absurdnych 20 minut (oproti 14 hodinam), takze mzdar celkom prirodzene reagoval: „Ajajaj, aj toto spadlo! A nejako rychlo! Pockat, ONO TO PRESLO!“
V pondelok sa zacali pripajat uzivatelia. Niektori ani nezaregistrovali, ze sa nieco zmenilo, okrem toho, ze tam , kde si medzi dvoma operaciami mohli postavit na kavu (pripadne ju aj vypit) im terminaly pipali „Hotovo!“ este nez vstali zo stolicky. Zrychlenie odozvy aplikacie ako takej bolo uzasne. A to vsetko na 6 serverovych strojoch triedy Pentium/32MB.
Riesenie, ktore som tu len nacrtol (niet casu ani miesta na detaily) sme postupne ladili:
- z trojvrstvej architektury sme presli na dvojvrstvu zlucenim aplikacneho a databazoveho servera (s prechodom na lepsie a vykonnnejsie zelezo a nove diskove pole – vid dalej)
- servery sme pripojili k enterprise diskovemu polu EMC SYMMETRIX (re-investicia za povodnu pole HARMONICS, ktore drzalo DB/2), cim sme obratili model na „datacentricky“ – servery sa stali periferiou diskoveho pola s datami. Navyse cache tohto pola mala 512 MB, co znamenalo, ze takmer 100% diskovych operacii sa udialo priamo z nej. Inymi slovami: rychlost diskovych operacii sa zvysila limitne na rychlost pamatovych i/o. A uzkym miestom sa stalo SCSI! Dosledkom bola este vyssia rychlost, stabilita, odolnost – v pripade vypadku servera stacilo dalsie PC podobnych parametrov, instalacia systemu a programov zo zalohy a islo sa dalej.
A propos, diskove pole: ked sme nasmu partnerovi MHM povedali, ze tento Rolls Royce chceme pripojit k plebejcovi Linux, zostali napriek dovtedajsim vybornym vztahom mierne rezervovani. Vyziadali si stanovisko EMC, ktore znelo: „Nasa spolocnost nepodporuje uvedeny system a jeho pouzitie DORAZNE NEDOPORUCUJE!“. Nasadenim v linuxovom prostredi sme riskovali, ze EMC odmietne online vzdialeny dohlad, ktory bol sucastou ceny prenajmu a predstavoval vyznamny bezpecnostny komponent celeho riesenia. Preto sme sa rozhodli urobit dokladne testy kvality, spolahlivosti, rychlosti, bezpecnosti a komplexnej funkcionality zvoleneho riesenia. Porovnavali sme s PC/Linux, PC/WinNT, Sun SS1000/Solaris (oboje podporovane zo strany EMC). Vysledky testov (predovsetkym rychlostnych) jednoznacne hovorili pre Linux, co Microsoft aj Sun zdovodnovali „robustnostou I/O operacii v ich systemoch“, co „sa premieta do rychlosti“.
Vysledky testov presvedcili MHM, aby podporili nasadenie Linuxu so Symmetrixom a zarucili sa EMC, ze to takto bude chodit. Dodnes sme im za to vdacni! Mali sme plnu podporu EMC – a po roku, na Invexe v priestoroch MHM svietila tabulka: Nase diskova pole nove podporuji i system Linux!
Takyto bol zaciatok linuxovej ery v nasej spolocnosti. Postupne sa dostal na rozne miesta v IT infrastrukture ako router, firewall, postovy server, VPN server, Lotus Notes (to bola bomba!) server a podobne. Dokonca aj skvely sietovy analyzer EtherScope od Fluke, ktory pouzivame, je postaveny na Linuxe. Nehovoriac o najnovsom prirastku: VMware ESX. Ale to uz je na ine – ovela dlhsie rozpravanie.
Len pri jednom by som sa chcel este pristavit. Velmi casto sa proti Linuxu pouziva argument o neexistujucej, resp. nedostatocnej podpore a ako protivaha sa spomina podpora komercnych spolocnosti, najma tych velkych. Musim povedat, ze nase skusenosti su skor opacne. Ked sme mali problemy s produktami IBM a Progress, realnej pomoci sme sa nedockali. Pokial sa nieco nedalo vymenit ihned, cakalo sa na patche (mesiace), pripadne nam partner odporucil prechod na novy HW ci SW. Alebo nieco ine – podobne „efektivne“.
Pri nasich experimentoch s aplikaciou ProFis a databazou Progress sa obcas stalo, ze uzivatelov terminal skysol a nedalo sa robit nic ine iba ho odstrelit a prihlasit sa znova. Posledna neuzavreta session bola tym padom v kybli. Zistili sme, ze na vine je databaza, ktora jadru odkazovala FD so zapornou hodnotou, co jadro odmietlo a aplikacia ostala stat. Zdokumentovany bug sme poslali do Progressu. Odpoved znela: „Linux nepodporujeme“. Ked sme namietali, ze bezime na SCO verzii ich databazy, bola problemom emulacia. Tak sme sa spojili s autorom emulatora ibcs2, ktory nam na druhy den(!) poslal patch a po preklade vsetko fungovalo bezvadne.
Iste, zazili sme aj krusne chvile a niekedy nam Linux pripravil aj necakane a nemile prekvapenia. Vzdy sa nam ich vsak podarilo prekonat a co sme raz rozbehli, to uz islo spolahlivo a stabilne (uptimy na serveroch boli i v radoch tisicov dni!). Energia a praca investovana do ziskania know-how okolo Linuxu sa velakrat vratila v moznosti implementovat lacne a kvalitne riesenie tam, kde by sme draho platili za porovnatelnu komercnu variantu. Aktualne studujeme IP telefoniu. Cisco nam ju ponuka za 6 milionov. My skusame Asterisk ;-). Uvidime!
