Az 99999 Informatikánál kifejezetten építünk az ügyféligényekre, ezért olyan gyártókkal dolgozunk, illetve olyan technológiákat tartunk a portfóliókban, amelyek az ügyfeleink specifikus problémáira megoldást jelenthetnek. A Nutanix-al azonban a mindennapokban nem gyakran találkozunk, hiszen nem sok helyen fut, de ez nem azt jelenti, hogy nem is érdemes vele foglalkozni.
Ezért is gondolkodtam – figyelembe véve a fent említetteket -, hogy érdemes-e részt vennem a Lenovo rendezésében megtartott Nutanix-os rendezvényen. Szakmailag mindig is érdekelt a Nutanix – tekintve, hogy hozzájuk kapcsolódik az egész hiperkonvergens infrastruktúra elterjedése – ahogy a cím is sugallja – és mindenki hozzájuk hasonló termékkel villogtatja a nagy HCI logót az oldalán. Ez alól kivétel a vSAN és talán az összes open source termék. Egy zárójeles megjegyzés: mint írtam a Lenovo (és a TD Synnex) szervezte az eseményt, emiatt pedig ebben a gyártóban pozitívan csalódtam, alapvetően én a két nagy gyártó termékeiben hiszek (szerver, storage fronton), na hát ez most bővült a Lenovo-val. Mind a termékek színvonala, mind az IT iparághoz való hozzáállásuk felteszi őket a másik két, számomra kiemelkedő gyártó mellé.
HCI vs Klasszikus Infra
Vissza a Nutanixhoz és HCI-hez. Szóval mi is ez a Hiperkonvergens téma? A régi siló szerű (3-tier) megközelítés ugye úgy néz ki, vannak számítási kapacitás nyújtó szerverek, az adatok tárolására szolgáló tárolók és ezek összeköttetését biztosító hálózati eszközök (lásd a lenti képen).
Nézzük is az előnyét a klaszikus 3 tier-es rendszernek: Ha fejlesztést kell véghezvinni, akkor az építőkockánként megtehető, a skálázáshoz hasonlóan. Emellett pedig válogathatunk a gyártók közül, mert nem feltétlenül egy gyártó terméke az, ami megfelel számunkra mind a három területen. Azonban itt nagyjából ennyi pozitívumot sorolhatunk fel a hiperkonvergens rendszerrel szemben.
Ahhoz, hogy ezt a silós rendszert üzemeltessük, azért jól jön a közös menedzsment felület, azonban ha ezek nem egy gyártó termékei, akkor ez igencsak nehézkes feladat. A következő probléma az életciklus menedszment. A fent említett közös menedzsment hiánya megnehezíti a frissítési feladatokat, kezdve az előkészűleteknél esedékes végeláthatatlan support matrix-ok ellenőrzésével, amelyek végén az akár több napig tartó frissítési folyamat van.
Lényegében erre ad választ egy hiperkonvergens rendszer, ahol mindhárom klasszikus tier (compute, storage, network) egybegyúrásra került (azért ToR switchek kellenek), így egy közös felületen tudjuk kezelni a teljes infrastruktúránkat, megoldva a teljes életciklus kezelését.
Motorháztető alatt
Hogyan is néz ki ez a Nutanixnál? Az ő termékük szép magyar szóval egy software-defined megoldás, aminek az alapját valamelyik népszerű hypervisor (ESXi, Hyper-V) vagy a saját (AHV) KVM fork-juk adja. Az ESXi és a Hyper-V esetében a virtualizációs rétegben – tekintve hogy meglehetősen zárt – harmadik félnek, így a Nutanix-nak sem lehetséges kernel szinten a tárolóvirtualizáció megvalósítása. Ezért a tárolási funkciók vezérlésére és felhasználására úgynevezett control VM alapon működik, amelyek a tárkapacitást is biztosítják a virtualizáció számára. Ha jól számolunk, akkor 3 tier-ből 2 (compute, storage) meg is van. Maradt a network.
A Nutaxinak erre is van megoldása, mivel Nutanix Flow néven OVS-re építettek egy saját SDN terméket. Ha ez nem lenne elég akkor VMware alapokon még használhatjuk az NSX-et, amivel már elég komplex hálózati igényket is ki lehet szolgálni.
Egy kicsit menjünk bele, hogyan is működik ez a rendszer. Tehát hardveresen van legalább három (ROBO esetén akár 2) diskekkel teli szerverünk, mondjuk a Lenovo ThinkAgile HX szériából. Ezeken a szervereken, ahogy említettem futhat ESXi, Hyper-V vagy AHV. Azonban amik a vázát adják az egésznek, azok a kontroll VM-ek, amik a user VM-ek mellett futnak dedikált host-on, dedikált erőforrásokkal. Az alacsonszintű elérés és a lehető legalacsonyabb késleltetés miatt a control VM-ek számára át van adva a fizikai szerver SCSI/SAS vezérlője, ahogyan a médiák is.
A VM-ek reprezentálják a közöstárolót és szolgálják ki a szerverek I/O kéréseit. Egy-egy node kiesés esetén a többi kontroll VM szolgálja ki a kéréseket. Ha már kiesés, hogy lesz redundáns ez a rendszer? A fent említetteken túl szükséges az adatok védelme, nem csak a hozzáférhetőség biztosítása. A klasszikus tárolóknál valamilyen RAID (RAID5-6, RAID+) biztosítja a redundanciát. Ez a HCI világban a többpéldányos tárolás oldja meg (kivéve HPE SimpliVity), itt node számtól függően lehet RF2, RF3. RF2 = 2 példány, RF3 = 3 példány. És nagyjából meg is vagyunk, mert többit a hypervisor beépített funkciói biztosítják (pl.: vSphere HA). A lenti kép egy elég jó szemléltetést biztosít.
Single Pane Of Glass – avagy egy helyen minden
És erre az egészre ül rá a Prism, ami közös menedszmentet biztosít a rendszer számára. Itt tudunk lunokat létrehozni, látjuk mennyi szabad helyünk van, lényegében az összes szükséges dolgot itt lehet elvégezni, ami szükséges a tárterület szempontjából. Tovább Prism-en keresztül lehet hálózatokat kezelni, illetve VM-eket létrehozni, menedzselni (AHV esetén).
Ami viszont a legfontosabb hogy, amikor elérkezünk a frissítéshez és a bővítéshez akkor azt szintén erről a felületről tudjuk könnyedén elvégezni. Ilyenkor automatikusan frissülnek a szükséges firmware-ek a szerverekben, az Hypervizor OS-hez tartozó driverek, illetve a controll VM-ek maguk, így sosem lesz az, hogy sikerül egy olyan állapotott előidézni, ahol a gyártói support felteszi a kezét, hogy már pedig ez egy nem támogatott verzió mátrix.
Skálázni a rendszert node-ok bővítésével lehet. Felmerül a kérdés, hogy mi van, ha nekem tárterületet nem, csak számítási teljesítmény kell bővítenem. Nos, ez igen egyszerűen kivitelezhető, mivel a van lehetőség úgynevezett compute node-ok illesztésére a rendszerbe, amik nem rendelkeznek saját tárterülettel.
Amennyiben ez az ízelítő felkeltette az érdeklődésed, kérdéseiddel keress minket bizalommal!
