Pár hónapja volt alkalmam tartani két „Hiperkonvergens reggeli” rendezvényt, aminek keretében prezentálhattam az elérhető és a hírhedt és széles körben utált Gartner quadrant jobb felső négyzetében található gyártók megoldásait, azok hasonlóságait és különbözőségeit.
Ezen gyártók – a gyártók amikkel foglalkoztam szubjektív:
- HPE Simplivity
- Cisco HyperFlex
- Netapp HCI
- Nutanix AHV
- DellEMC VXrail
- Microsoft Storage Spaces Direct
- indirekt VSAN
Várom a savat, hogy a cikk további részében miért nem tárgyalom a Microsoft Storage Spaces Direct-et és a Nutanix megoldásait. Előbbit azért nem, mert nem foglalkozom Microsoft-tal, ugyanakkor fél kezemen meg tudom számolni mennyi S2D-t láttam élesben életemben. Lehet ez a legjobb a világon, a többi részben sort kerítek rá. A Nutanix pedig biztosan nagyon szuper, de a saját hypervisor-át én tuti nem használnám. Kizártnak tartom, hogy egy VMware/HyperV virtualizációval bíró itthoni ügyfél feladja mindenét és átvált a Nutanix sajátjára. Ha VMware alá használjuk, akkor pedig lehet van jobb, főleg úgy hogy nincs Nutanix Magyarország Kft, ezért lényegében a nemzetközi támogatásra vagyunk utalva, legyen szó break-fix-ről vagy akárcsak egyetlen kérdésről.
Architektúrális megközelítések
Virtuális gépen a tároló
Az első ilyen architektúra már mára szerencsére kikopott. Ezeknél a tároló nem volt más mint egy virtuális gép, aminek oda volt „adva” a sok hely és lényegében benne volt a szoftveres logika, illetve ő ajánlotta ki a területet.
Ismerős lehet a Lefthand/Storevirtual VSA.
Diszaggregált HCI
Nagyon jó példa erre a NetApp HCI megoldása. Valamiért a gyártó úgy gondolja, hogy ezt HCI-nek lehet hívni, holott ill a storage-ot adó node-okon nem fut és nem is futhat virtuális gép.
Minden más gyártónál is elérhető a „compute only” node, de a Netapp-nál csak ilyen megoldás van. Nem tud teljes HCI lenni. Főleg hogy a belépő szint igen magas, minimálisan hét node kell hozzá.
Rendes HCI
Itt minden node-on van virtualizált tároló és compute is, azaz futnak rajta végfelhasználói virtuális gépek is.
Minden gyártó – kivéve a Netapp – olyan megoldásokat kínál, amelyek ebbe a kategóriába tartoznak.
Integrációs szintek
Itt két út létezik, annak fényében, hogy a kérdéses gyártó egyébként rendelkezik-e virtualizációs szoftverrel. A VMware-en, a Microsoft-on és a Nutanix-on kívül mindenki más a második kategóriába tartozik, míg az említett három az elsőbe.
Virtualizációban integrált SDS
Itt lényegében a compute virtualizáció kernelébe integrált SDS-ről van szó.
Nem kernel integrált SDS
Mindenki más, akinek valamilyen módon alkalmazkodnia kell a saját SDS rendszerével, valaki más virtualizációjához.
Mindegyik megoldásban – kivéve Netapp – minden esetben van egy „Controller VM”, ami szinte minden esetben direkt hozzáféréssel rendelkezik a HBA/RAID-vezérlőhöz, ezáltal a diszkekhez is, illetve ha van speciális ASIC – a HPE Simplivity-nék kötelezően van, a Cisco HyperFlex-hez opcionálisan létezik – akkor ahhoz. Ezek általában PCI-express-en csatoltak, és DirectPath IO-val át vannak adva a Control VM számára. Ezen VM-ek tartalmazzák az SDS réteg szoftverét, felelnek a logikáért, az IO kezeléséért, a magas rendelkezésreállás biztosításáért, a tároló prezentációjáért. Abban van eltérés, hogy NFS-en csatolják a hosztokra a területet, SMB-n vagy iSCSI-n.
Mi alapján ne dönts?
CPU és RAM igény – indirekt módon kernel vagy nem kernel integrált
Általános vélekedés, hogy a kernel integrált sokkal jobb, mert nem kell neki annyi erőforrás, mint a Control VM alapúnak. Ez nem igaz és ezt például a VSAN példáján bemutatva meg is lehet érteni. A VSAN-nak kell 10% CPU erőforrás a puszta működéshez és a node-ban lévő lemezek száma alapján RAM-ra is.
Illetve a szükséges memória képlete:
BaseConsumption + (NumDiskGroups * (DiskGroupBaseConsumption + (SSDMemOverheadPerGB * SSDSize))) + (NumCapacityDisks * CapacityDiskBaseConsumption)
Konstansok:
BaseConsumption = 5426 MB,DiskGroupBaseConsumption = 636 MB,SSDMemOverheadPerGB (hydrid) = 8 MB, SSDMemOverheadPerGB (allflash) = 14 MB, CapacityDiskBaseConsumption= 70 MB
Szóval, ha van egy node-om, amiben van 1 SSD – cache – és 3 HDD – kapacitás – akkor abban a szerverben szükségem van 14672MB RAM-ra.
5426 MB + (1 * (636 MB + (14MB * 600))) + (3 * 70 MB) = 14672 MB
Aláírom, hogy kicsit kevesebb mint egy Cisco HyperFlex vagy HPE Simplvitiy esetében, nem sok az előnye.
Lokalitás
Korábban már írtam róla itt:
Nincs olyan HCI megoldás, ami alapbeállításban használna lokalitást. Bármelyik gyártó bármit állít, hazudik!
Sem a Simplivity-nél, sem a VSAN-nál és a HyperFlex-nél sincs ilyen. Az első kettőnél egyébként beállítható, a VSAN-nál egyenesen a VMware Support-ot kell hívni. Ennek amúgy sincs semmi értelme, ha például VSAN-nál erasure coding-ot használnánk (RAID5 vagy RAID 6).
Mi alapján dönts?
Minimális kiépítés
Ha kicsiben szükséges indulni vagy távoli, kis telephelyre kell vagy csak ki akarod próbálni, akkor fontos lehet az induló készlet.
Majdnem mindenhol van két node-os kiépítés, de a Cisco-nál például valamilyen megmagyarázhatatlan ok miatt közvetlen nem lehet összekábelezni a szervereket. Sok helyen nincs 10/40Gbit-es switch, ezért ez fontos. A witness/artbiter kikerülhetetlen, páros számnál kell valaki aki eldönti ki legyen aktív.
„Box to VM-ready” idő
Mennyi idő szükséges egy HCI rendszer beüzemeléséhez. Itt a Cisco HyperFlex verhetetlen. A legnagyobb előnye – ami a legnagyobb hátránya is – hogy nem Edge – azaz nem három node-os kiépítésben – a Cisco Fabric Interconnect kötelező használata miatt azt is automatizálva képes beállítani, mármint a szervereket profilozni UCS Manager-ben, hálózatokat létrehozni, interfészeket konfigurálni. Állítólag 37 perc alatt feltelepül – 38 alatt tényleg megcsinálta.
A DellEMC VXrail és a HPE Simplivity kb egy szinten van, mindkettő körülbelül hasonlót tud.
Beépített szolgáltatások
A HPE Simplivity nyeri a kategóriát. Beépítve képes „mentésre”, minden külső szoftver vagy komponens nélkül. Replikálni is tud, amit a Cisco HyperFlex is, de optimálisabban. A rendszer működéséből fakadóan csak olyan blokkokat visz át, amiket még a replikáció célját adó Simplivity klaszter még nem „látott”. Ezzel szemben a HyperFlex mindent replikál, a VSAN és az erre épülő VXrail pedig az ingyenes vSphere Replication appliance-ra szorul ha replikálni akar.
T-shirt méretezés és egységes támogatás
Nincs egyszerűbb annál, hogy kiválasztom a számomra megfelelő kiszerelésű modellt és hátradőlve használom. Ez minden saját kézzel összeépített „VSAN ready node” ellen szól.
Amennyiben nem „VSAN ready node”-ot veszünk, akkor a egy számot kell a tárcsázó kedvencei között tartani, faltól falig támogatja a rendszert. A frissítéseket is előre tesztelt formában adja át, több esetben bundle formában. Biztosak(biztosabbak) lehetünk abban, hogy ez működni fog a frissítés után is.
Deduplikáció/tömörítés
Mindegyik tudja, de más áron és máshogy. A VSAN-nál csak all flash esetén lehet használni és legalább Advanced licensz kell hozzá. A Cisco HyperFlex tudja hibrid esetén is, ráadásul kikapcsolhatatlan funkciója. A HPE Simplivity pedig amúgy is csak all flash verzióban kapható, ott is alavető a dedup/tömörítés.
Ami különbség, az az hogy a VSAN-nál a dedup/compression egy disk group-on belül történik csak. Amíg egy disk group-om van, addig ez nem jelent hátrányt más megoldásokkal szemben, de ha túlnövünk a 7 kapacitást adó lemezen, akkor kapásból a sor végére dobja a megoldást. Ebben a Simplivity a legjobb – holtversenyben a HyperFlex-el – a dedup határa itt a teljes node, sőt replikáció esetén a teljes klaszter.
Hány node-ot lehet elveszteni?
Senki sem akar elveszteni egyet sem, de érdemes kezelni az ilyen nem várt helyzeteket. Ez a legkuszább dolog, mert a különböző gyártók, adott rendszere alapjaiban másképp kezeli a redundanciát.
VSAN-nál ha nem használunk RAID5/6-ot, akkor beállítható 1,2 vagy 3 failures to tolerate. Ez pont annyit jelent, hogy ennyi példányban tárolja majd az adott virtuális gép objektumait. Ez nincs ingyen, ennyivel több hely kell majd.
Mi jelenti a VSAN-nál azt az eseményt, hogy elveszünk egy node-ot?
- teljes node leállás/PSOD stb.
- tönkremegy a cache SSD
Cisco HyperFlex-nél beállítható 2 és 3 – itt replication factor-nak hívják, viszont értelmezésében ez a VSAN-os terminológiában az FTT=1 és FTT=2-nek felel meg. A HyperFlex nem tud erasure coding-ot, ezért itt „RAID1” lesz a VM objektumain, így kell számolni a hellyel.
A HPE Simplivity-nél az elveszthető node-ok száma 1. Nincs más. Tehát ha van 16 node-unk egy federációban/klaszterben, akkor is egy node veszhet el, viszont ez tud valami olyat, amit a másik kettő nem. Ez RAID-et használ és attól függően melyik modellről van szó, az lehet RAID-5 vagy RAID-6. Ebből fakadóan, akár mind a 16 node-ból elveszhet egy vagy két lemez is egyszerre, plusz egy teljes node, akkor is működni fog minden. Ellenben két teljes node kiesését, nem kezeli. Védelmére szóljon az, hogy a VM-ek elhelyezése minden esetben FTT=1, azaz csak azok a VM-ek lesznek „elérhetetlenek” amelyeknek mindkét kópiája azon a két kiesett node-on van.
Összefoglaló
Ne dőlj be a gyártói slide-oknak, kérj tanácsot! Mindegyik HCI megoldásnak van helye, de mindegyiknek van előnye és hátránya, ami miatt adott célra az egyik jobb lesz, mint a másik.
