Az adatközpontokról mindenkinek rácsok mögötti, hűtőszekrény méretű szilíciumszörnyek vagy éppen zsúfolt, kisebb, asztali gépekhez hasonló masinákkal teli tömött polcok jutnak eszébe. Arról már jóval kevesebbet tudunk, hogy az adatközpontok ténylegesen hogyan is működnek és mikben változott az adatközpontok kialakítása az idő folyamán.

2-3 évvel ezelőtt még többen határozottan azt jósolták, hogy a jövő kis- és középvállalati környezetben a mikroszervereké, azaz az olyan szervereké, amik nem sokkal nagyobbak, mint egy asztali gép, csak éppenséggel a rendelkezésre állásuk sokkal nagyobb, emiatt persze egy átlagos asztali géphez képest drágábbak is. A mikroszerverek piaca ha nem is torpant meg, a kezdeti felfutás lelassulni látszik, vélhetően azért, mert ha a szerver többek közt attól szerver, hogy folyamatosan működnie kell, elfogadhatatlan, hogy a 2-3 év garanciális időszak után egy-egy ilyen kis szerver egy hardverhiba miatt leálljon és bizony ha nincs a kkv-nak szerződése valamilyen hosztingszolgáltatóval, amelyiknél egy tartalékszerver át tudná venni a mikroszerver feladatát, akkor az érthetően komoly kellemetlenség, mivel mikroszervert javíttatni nem is olcsó, másrészt veszélyeztetheti az üzletmenet-folytonosságot, akárcsak más leállás.

A megoldások egyike tehát nagyon sok esetben a klasszikus ún. polcos vagy rackszekrényes elhelyezés egy jól védett szerverhotelben, ahol nem kell számolni a porral, hőmérsékletingadozással, ingadozó páratartalommal, elektromágnesesség okozta zajjal vagy éppenséggel az olyan áramszünettől, amit a szünetmentes táp ne tudna áthidalni.
Hiszen a szerverhotelek tipikusan több, egymástól független, nagyteljesítményű betáppal vannak ellátva, nagyteljesítményű szünetmentes tápok gondoskodnak róla, hogy egy-egy áramszünet esetén se maradjanak a vasak áram nélkül, ha pedig még ezek a monstrum méretű szünetmentes tápok sem bírnák szuflával tovább, az szerverhotelek közelében vagy tetején elhelyezett dízelgenerátorokkal biztosítják az áramellátást, ugyan úgy tudom, hogy dízelgenerátorok beindítására Magyarországon még egyszer sem volt szükség a komolyabb adatközpontok esetén.


Dízelgenerátorok a tetőn [Dataplex]

A közelmúltban megtartott IDC Adatközponti Transzformáció Konferencián az adatközponti infrastruktúrákkal foglalkozó és céges ügyfélként jelen lévő részvevők oszthatták meg egymással a tapasztalataikat.

Szinte mindegy, hogy milyen infrastruktúráról van szó, máig a hibrid rendszerek a jellemzőek, azaz klasszikus dedikált szervergépek, nagy számításigényű és magas rendelkezésre állású mainframek  és felhő-alapú megoldások vegyesen.

Ami némileg meglepő lehet, hogy a 64 bites architektúra a nagyszámítógépek piacán csak szép lassan terjed ki, míg az asztali gépeknél és a laptopoknál már természetes, hogy mind 64 bites, ugyan 8-10 évvel ezelőtt a 64 bites architektúrák nem jelentettek a felhasználók számára akkora érezhető változást, mint korábban a 16 bitesről a 32 bitesre történő áttérés.
Ma már a tudatos otthoni felhasználónak sem kell tartania tőle, hogy komolyabb adatvesztést szenved el, ha elszáll a gépe, hiszen jobbnál-jobb cloud storage szogláltatók jelentek meg, amik folyamatosan feltalicskázzák a felhasználói adatokat a felhőbe, aminek tartalmát folyamatosan szinkronizálják a gépen, helyben tárolt
tartalommal.

Kis- és közepes méretű vállalatok szerverei esetén nyilván sokkal kackiásabb a helyzet. Az IDC-n az adatbiztonságra specializálódott Veeam regionális menedzsere egészen elképesztő adatokat osztott meg a hallgatósággal. Kiderült, hogy a felhő-alapú tároló megoldásoknál egy-egy leállás esetén az esetek közel 20%-ában lépnek fel súlyos nehézségek illetve a visszaállításkor. A cloudban alapvetően annyira bízik mindenki, hogy szinte sosem tesztelik. Egy-egy virtuális gép újraindítása egy kkv-nál olyan módon, hogy minden zökkenőmentesen haladhasson tovább, átlagosan négy órát vesz igénybe. Márpedig - ahogy erről többször is írtam ezen a blogon - egy-egy óra downtime társadalmi hatása időről időre egyre nagyobb, az érintett cég számára egyre nagyobb presztízsveszteséget jelent és a kiesésből adódó költségek is egyre nagyobbak.

Állítólag egy, a közelmúltban történt pénzintézeti szerverleállás 880 ezer USD veszteséget jelentett óránként.

IBM AS400 - napjainkig az egyik legelterjedtebb mainframe pénzintézeti környezetben

A Veeam előadásában elhangzott, hogy egy teljes adat- és szolgáltatásvisszaállítás meghibásodás esetén akár kevesebb, mint 15 perc alatt is megoldható. Itt persze nem arra kell gondolni, ami még régen volt IT-üzemeltetési gyakorlat, azaz, hogy - egyszerűsítve - "tükörszerverek" futnak egymással párhuzamosan így biztosítva a redundanciát, nem is úgy kell elképzelni a helyreállítást, mintha egyszerűen csak biztonsági másolatokat kapnának elő, hiszen azok természetükből adódóan nem tartalmaznák a legfrissebb adatokat illetve a kiesett szolgáltatások utolsó ismert állapotát. Valójában ún. replikátumokról, ha úgy tetszik, élő másolatokról van szó.

Egy másik előadásban volt róla szó, hogy a sok, különböző gépből álló szerverpark felügyeletét segítő integrált felügyeleti megoldások egyszerre képesek figyelni az infrastruktúra minden rezdülését és beavatkozni, ha kell. A központi felügyelet pedig nagyon nem mindegy, ha egy több ezer, ráadásul különböző platformon futó, különböző földrajzi helyen lévő gépekről van szó, amiknél nyilván igencsak veszélyes üzem lenne, ha csak külön-külön lehetne menedzselni. Ez utóbbinak az a magyarázata, hogy sokszor a nagygépes vagy több gépből álló rendszerek olyan módon futtatnak párhuzamos folyamatokat vagy éppenséggel biztosítanak virtualizált környezeteket eltérő szolgáltatásokhoz, hogy az IT-s nem is tudja valójában, hogy melyik melyiken fut fizikailag.

A HP előadásában volt róla szó, hogy a big data szép is, jó is, viszont azért, hogy egyre kifinomultabb módszerekkel lehessen hasznát venni, szükségszerűen olyan infrastruktúrára lesz a közeljövőben szükség, amik ma még nem elterjedtek.

Márpedig a jövőben a big datával tudnia kell bánnia minden olyan cégnek, ami meg szeretné tartani a versenyképességét, hiszen a hatékony üzleti tervek kialakításához nyilván jó minél pontosabban tudni, hogy hogyan optimalizálhatóak a belső folyamatok, hogy mit szeretne az ügyfél, arra mennyit hajlandó költeni és ez milyen paraméterekkel áll összefüggésben, amire a big data előtti korban esélyük sem lett volna rájönniük a kutatóknak.

Megjegyzem, ebben a posztban most nem megyek bele, hogy a big data mennyire buzzword vagy sem, na meg abba sem, hogy milyen bizarr módon néz ki, amikor egy aktuális tudományos vagy technológiai paradigmáról irritálóan sokan beszélnek a megrendelői oldalon olyanok, akiknek amúgy lövésük nincs a témáról. Ami viszont tény, hogy igencsak tekintélyes számítási kapacitásra és ehhez igazodó infrastruktúrára szükség lesz, ennek pedig szerintem is egyik flagshipje a HP, ha az igények kiszolgálásáról van szó. Ma ha egy szervezet hatékony szeretne lenni, a meglévő adattárházát az általa megbízott big datával foglalkozó cégnek úgy kell használnia, hogy úgymond minél jobb kérdéseket tudjon feltenni, ennek megfelelően minél részletgazdagabb válaszokat tudjon visszajuttatni a megrendelő szervezethez, ehhez viszont erős infrastruktúra kell.

A DevOps megközelítéssel a Prezi előadása foglalkozott behatóan. Akinek nem lenne ismerős a DevOps, nos, ez az a szemléletmód, ami azt vallja, hogy a szoftverrendszerek fejlesztői legyenek annak üzemeltetői is egyben. Aki nem foglalkozik informatikával, elsőre még így sem biztos, hogy világos, hogy miről van szó, hiszen elvben az informatikus tud szoftvereket fejleszteni, na meg üzemeltetni is, nem? Nos, az egyszerűsített válasz persze az, hogy valóban, viszont nyilván van, aki az idő folyamán a fejlesztésre, tesztelésre megint más pedig az üzemeltetésre specializálódik. Nagyméretű szoftverrendszerek pedig akkor működhetnek a legnagyobb hatékonysággal, rendelkezésre állással és persze leggyorsabban, ha a fejlesztőnek minél inkább pontos képe van arról a környezetről, azaz architektúráról, amire ténylegesen fejleszt valamint az admin-szemléletű informatikus képben van azzal kapcsolatban, hogy a sok-sok különböző technológiát használó szoftverrendszer alá hogyan érdemes beállítani a vasakat vagy éppen a felhőt.

A DevOps igazából kicsiben nem igazán értelmezhető dolog, viszont ha már arról van szó, hogy egy szolgáltatásnak percenként adatbázis lekérdezések milliárdjait kell végrehajtania nyilván megfelelő sebességgel, akkor a szolgáltatás által küldött adatbázis-lekérdezéseket kell optimalizálni ÉS az adatbázisszerveren a célnak leginkább megfelelő adatbáziskezelő motort kell választani, különben a szolgáltatás vagy lassú és megbízhatatlan lesz vagy veszett nagy összegeket kell a cégnek költenie arra, hogy meglegyen a megfelelő erőforrásigény. Az IT-re fordítható pénz pedig nyilván szűk keresztmetszet, azaz többet ésszel, mint erővel.

A klasszikus fejlesztési módszertanról és az agilis fejlesztésről szóló kerekasztal beszélgetésnek megvoltak a maga tanulságai. Megjegyzem, amikor ez kerül szóba valahol, többször tapasztalható, hogy úgy teszünk, mintha egyedül a V-modellel gyakran tévesztett vízesés-modell és az agilis fejlesztési módszertan létezne, holott van még bőven, másrészt gyorsan belátható, hogy az egyik nem váltja fel a másikat időben, hanem tisztában kell lenni azzal, hogy bizony, van, ahol az egyik, van, ahol pedig a másik fejlesztési módszertan hatékony. Ahogy az egész ipar, természetesen maga a fejlesztő is folyamatosan az idő szorításában dolgozik, tény, hogy időt spórolni valahogy a tesztelési folyamatoknál /*veszélyesen rossz*/ szokás. Az olyan módszertanokat követő fejlesztők, amik hallgatólagosan sokkal kisebb hangsúlyt fektetnek a tesztelésre, később komoly árat fizethetnek emiatt.
IMHO persze nincs általános képlet, megfelelő szoftverfejlesztési igényhez a megfelelő módszertant kell kiválasztani, igazán tragikusan például akkor sülhet el a dolog, amikor egy csapat olyan módszertant választ, amit esetleg saját maga talált ki vagy egyszerűen nincs elegendő rendelkezésre álló tapasztalat a hatékonyságával kapcsolatban.


Az IDC-n kiderült, amiről korábban csak pletykák voltak, nevezetesen, hogy a Raiffeisen Bank, kulcs fontosságú rendszerét ért leállást egy IBM AS400-as mainframe egy processzorának elfüstölése okozta, ami rántotta magával a többi hardverelemet. Ismereteim szerint ennyi még bőven kevés ahhoz, hogy egy pénzintézeti rendszer órákra elszálljon, emellett több, konkrétabban meg nem nevezett emberi eredetű hibát is elkövettek a helyreállítás során. Tehát az eset tanulsága ismétcsak az, hogy a leállást kizárni még méregdrága, többszörösen redundáns infrastruktúrával sem lehet biztosan, viszont nagyon nem mindegy, hogy a kiesett rendszer mennyi idő után áll talpra illetve veszi át a szerepét egy tartalék rendszer, ennek a gyakorlata viszont nyilván emberi tényező. Hogy mennyire részletes és szigorú annak a forgatókönyve, hogy különböző kieséseknél milyen protokoll szerint kell eljárni, nagyban függ attól, hogy milyen szektor informatikai rendszeréről van szó, ezzel a ISO/IEC 27000 szabványcsalád foglalkozik behatóan.

Közel teljes rendelkezésre állás létezik. Ez viszont nem csak a technikai kialakítástól, hanem az azt üzemeltető IT-stafftól, mint emberi tényezőtől is függ. Hogy a technikai megvalósítás mennyire is tud redundáns lenni, az IDC egyik előadójának a HP-nak egy ősrégi reklámjával szemléltetném.

Pontosabb, bővebb magyarázat? Kapcsolatfelvétel? Kattints ide!