A HCI reggelik során elég mélyen kifejtettem azt, hogy a döntési tényezők és a tervezési szempontok miképpen alakulnak egy hiperkonvergens megoldás kapcsán. A lista nem végleges, bővül majd, de első körben én úgy gondolom, hogy aki ezeket a pontokat átgondolja és el tudja dönteni ezek alapján, hogy mit akar, az nem hibázhat mikor produktív üzembe helyezi a megvásárolt rendszert.
Terhelés (VM) pontos ismerete (IOPS,RAM,CPU,tárterület)
Bár silós és konvergens rendszernél is igaz, de ismerni kell azt a terhelést amit a rendszernek ki kell szolgálnia. Itt nem arra gondolok, hogy RVtools riport alapján kapott RAM, vCPU és tárterület kumulált értéke lesz az amire keresünk rendszert. Elemi szinten kell ismerni a virtuális gépek főbb jellemzőit, ezáltal hogy például mekkora blokkokkal dolgozik, teljesen véletlenszerű az írás/olvasás amiket végez, CPU intenzív-e az alkalmazás amit futtat?
Azért fontos ez még inkább mint nem HCI esetén, mert itt minden hatással van mindenre és ha kevés RAM-mal tervezünk, ha nem megfelelő SSD-t választunk – méret, endurance és teljesítmény – vagy nincs elég kapacitás a tárolási rétegben, ne adja ég a CPU lesz alulméretezve, akkor ezt a tervezési hibát igen nehéz feloldani, mivel egy hiperkonvergens rendszerben elvárható a homogenitás, ezáltal mindent az összes node-ban meg kell változtatni.
Hibrid és/vagy all-flash – dedup/compression?
Az elérhető IOPS nyilvánvalóan nagyban függ hogy hibrid vagy teljesen flash alapú a választott rendszer, illetve végső soron a node-ok számán is múlik majd az elérhető I/O teljesítmény. Vannak gyártók, akik nem is foglalkoznak hibrid megoldásokkal – pl HPE, a Simplivity csak flash lehet – mások pedig a deduplikáció/tömörítés megvalósítását vagy licensztől teszik függővé és csak all flash esetén tudják – VMware VSAN – mások pedig ezt beépítve – kikapcsolhatatlanul – tudják – HPE Simplivity és Cisco Hyperflex.
(VSAN BYO) SSD TBW
Ezt nem lehet eléggé hangsúlyozni. Ha valaki magának épít VSAN alá rendszert – nem VSAN ready node-ot vesz – akkor fontos a cache SSD-t úgy méretezni, hogy legalább 10%-át tegye ki kapacitásban a tárolási rétegnek – hibrid esetén. Ugyanilyen a fontos a két bekezdéssel feljebb már érintett, cache SSD TBW – régebben DWPD – és teljesítmény. VSAN-nál, az írás mindenképpen megjárja a cache SSD-t, szóval egy disk group-ra írt összes adat átmegy ezen az egy SSD-n. Fontos, mint „endurance” szinten tudja ezt tolerálni, illetve hogy a szükséges IOPS-ot képes legyen hozni.
VM swap – sparse swap (VSAN)
Ez nem kizárólag HCI specifikus, de érdemes számolni a VM swap-pal is. Ha egy futó gép könyvtárát megnézzük a datastore-on akkor, látható egy vswp kiterjesztésű fájl, aminek mérete pont akkora, mint a VM-nek adott memória mérete. A „reservation” nyilvánvalóan csökkenti, teljesen el tudja tüntetni ezt a fájlt, de akkor ha ezt minden gépnél beállítjuk, nem tudjuk túlfoglalni a hoszt fizikai memóriáját sem, illetve mindenféle trükktől megszabadítjuk a rendszert, amit a VMware olyan jól tud. Szóval ha a HCI rendszeremre kerül összesen annyi virtuális gép, amelyek 6 TB memóriát igényelnek, akkor szükség lesz legalább 6 TB-tal több kapacitásra. Mit több, X-szer 6 TB-ra, mivel ha tükörben tároljuk a VM-et akkor ezt is tükörbe fogja tartani a rendszer. VSAN-nál választható sparse swap is, akkor thin módon hozza létre a vswp fájlt, de ez szintén a fizikai RAM túlfoglalását zárja ki, mivel nagyon kell ügyelni arra, hogy ne történjen ilyen.
Overhead – CPU és RAM
Álljon itt az első sorban máris a lényeg: Minden HCI rendszernek van CPU és RAM igénye. Ha deduplikációt és tömörítést használunk (VSAN és Cisco Hyperflex esetén kell számolni ennek CPU terhelésével is) vagy RAID5/6-ot használnánk VSAN-al, akkor ezeknek is van további igénye.
VSAN-nál például a képlet a RAM szükségletre:
A CPU igénye pedig:
Még azt sem lehet mondani, hogy gyökeresen eltérne az igény egyik és másik megoldás között, viszont kétségtelen, hogy a felhasználás prezentációja nem egységes. Minden olyan gyártó, aki nem rendelkezik hypervisor-ral, sajnos arra kényszerül, hogy control/service VM-et futtasson minden hoszton és ott kezelje az elsztott tárolót. Ebből fakadóan ezen VM entitásoknak a CPU és RAM felhasználása elég jól elkülöníthető és jól láttatható is, mivel ez egy VM, amire vCenter-ben ráállva pontosan látom mennyi host CPU-t és RAM-ot használ. Ezzel szemben a VSAN-nál, a hoszt entitáson állva csak annyi látható hogy a teljes kumulált CPU kapacitás (pl 24 x 3200Mhz) mennyit használ és mennyi a teljes RAM foglalása a hosztnak. Maga a skála akkora, hogy 4 GHz használat alig észrevehető, illetve ebben benne van minden, nem csak a tárolási réteg igénye. Innen fakad az érzés, hogy ez utóbbi biztosan nem kér annyi erőforrást.
Gyakran támadják például a HPE-t azzal, hogy a Simplivity-ben ott egy fizikai kártya, amin van egy ASIC – és még sok más – ami a munka dandárját végzi, ugyanakkor ez alacsonyabb teljesítménnyel bír mint egy kernel integrált megoldás. Hadd tegyek ide egy képet arról, hogy a Simplivity-ben hogy működik az SVC:
A Virtual Controller VM úgynevezett VMware DirectPath IO „funkcióval” kapja az ASIC-ot tartalmazó PCIe kártyát, illetve a RAID-vezérlőt is.
A VMware dokumentációja ezt mondja a DirectPath IO-ról, bár kicsit más kontextusban, hálózati csatoló kapcsán:
Mindenkinek a józan ítélőképességére bízom, hogy mennyire érzi ezt valós tüskének egyik gyártó irányából a másik felé.
Slack space
Operatív terület, olyan esetre ha például szeretnénk snapshot-okat készíteni, illetve például egy node hibája esetén legyen elegendő szabad kapacitás a redundancia újraépítésére. Ennek általában legalább 30%-nak kell lennie és ezt érdemes megfogadni, de nincs ez másképpen egy SAN tárolónál sem, ott sem illik 95%-ra töltve használni éles üzemben.
(VSAN,HyperFlex) – Resiliency factor – VSAN esetén RAID szint (is)
Fentebb már említettem, de fontos már az elején tervezni a hibatűrés szintjével. Egy node kiesését minden gyártó kezeli – hacsak valaki direkt nem hoz létre RAID0/RF1-el VM-et – RAID1-el. Ha két node kiesését szeretnénk kezelni, akkor három példányt tárol majd a megoldás minden VM lemezeiből.
Így például egy 100 GB-os VM, 300 GB tárolási kapacitással fog bírni, cserébe tolerálni tudja két teljes node elvesztését egy időben.
VSAN-nál választható RAID5/6 – erasure coding – is, ekkor a szükséges kapacitásigény csökkenthető a redundancia szintjének megtartása mellett, cserébe van CPU igény is a hoszt oldaláról, más licensz is kellhet, változik az elérhető IOPS, azaz picit kevesebb mint egyébként sima RAID1 tükör esetén, illetve nem elhanyagolható, hogy szükség van legalább 4 node-ra is.
Magad építed, validált rendszer, kulcsrakész megoldás
Az első opció VSAN – és Microsoft S2D – esetén igaz csak. Senkinek nem javaslom, mivel senki sem szereti a VSAN HCL böngészni, hogy melyik disk HBA, melyik SSD FW, milyen driver és VSAN verzió támogatott stb…egy HCI rendszernek ezeteket kell pont levennie az üzemeltetés válláról és nem újabb hátizsákot adni rá.
Validált rendszer például egy VSAN Ready Node, VMware és a szerver gyártója, kézenfogva validálták a rendszert, lemérték az elérhető teljesítményt vele és támogatják azt teljes mellszélességgel. Ez az egyik jó irány, de ez nem kulcsrakész megoldás.
Azok a HCI rendszerek, amik a dobozból a rack-be helyezve, kis túlzással, azonnal használhatóak, integrált rendszerek. Ilyenek a HPE Simplivity, a DellEMC VXrail, a Cisco Hyperflex és a Nutanix is. Valamilyen varázsló segítségével a telepítés végbemegy és igen gyorsan kész a rendszer a virtuális gépek fogadására. A gyártói támogatás hasonlóan „single point”, nincs egymásra mutogatás hiba esetén. A frissítések pedig előre teszelt bundle/csomagokban érkezik, ezzel is tehermentesíve az üzemeltetést a kompatibilitási vizsgálatok alól, illetve a telepítésben is segítő kezet nyújtanak, mivel ezeknél ez gyakorta szintén varázsló alapú.
A legfontosabb: Indulj kicsiben – de ne nagyon kicsiben!