Ha HCI-ben gondolkozol

Miért ne tennéd? Picivel több mint két éve a VMware-től a régióért felelős külhoni vezető nekem – nekünk – szegezte a kérdést, hogy miért nem lehet itthon VSAN-t eladni. Mivel erre a válasz nem egyszerű, gondoltam megnyugtatom, addig amíg összeszedem fejben a hatvanhét perces válaszomat. Annyit feleltem “Más HCI sem eladható itthon”.

Nyilvánvalóan ez így nem teljesen igaz, de kétségtelen tény hogy azért nem tarolta le az SMB piacot a 2-3 node-os HCI-k eladása. Fakad ez abból, hogy a hardver és szoftverek ára itthon is pontosan azonos a nálunk fejlettebb kelet nyugati országokban. Viszont csak nem lehet erre fogni az egészet, szóval valami mélyebb oka mégis legyen már.

Nehéz bekategorizálni a kisvállalat jellemzőit, de ha IT oldalról közelítem meg, akkor 2-3 szerver és egy NAS – QNAP,Synology – a lépték. Mindenes ITs szakember van, aki egyben portás is – túlzóan viccelek – szóval a lehető legegyszerűbben oldja meg a dolgokat. Hálózati szempontból egy-két gigabites switch és ennyi. A kiszolgálók életciklusa az ilyen ügyfeleknél nem a három, hanem a hét évet is elérheti. Tehát ha vásárolnak valamit, azt bizonytalanul hosszú ideig használják.

Eladható-e a HCI a fenti ügyfélnek? Technológiai szempontból igen, üzemeltetést egyszerűsítő megoldásként is. Pénzügyi szempontból nem állja meg a helyét. Egyszerűen túl drágává válik és most tekintsünk el a kedvezményes árképzéstől.

Tehát sokkal magasabb redundanciát és performanciát biztosítana számára egy HCI, de olyan magas áron és behoz egy fontos limitációt:

“A HCI rendszerekben óhatatlanul összekapcsolódik a tároló és a számítási réteg életciklusa”

Ha lejár a szerverek garanciája, akkor abban a pillanatban a tárolóé is lejár. Ha egyiket cserélnénk egy másik gyártóra, újabb modellre stb, akkor óhatatlanul a másikat is cseréljük.

A kiépítés limitációi

A HCI rendszerekben a tárolás nyilván megköveteli a redundanciát. Ezért gyártótól függően és azon belül kiépítéstől függően más más módon garantálják ezt.

Itt az all flash/hibrid kérdés hatványozottabban lényeges. A VSAN ebbből a szempontból hátrányban van, mert a Simplivity-ben és a Hyperflex-ben alapból be van kapcsolva a DE/CO. VSAN-nál viszont csak all flash esetén lehet bekapcsolni, ahogyan a RAID1 helyett használható RAID5/6-ot – erasure coding-ot is. Utóbbiakhoz kell elegendő számú node is.

Tehát itt egy igen sok tényezős képlet alakul ki hiszen:

  • kevés node esetén csak RAID1 lesz, spórolunk a socket alapú licenszeken és hardveren
  • legalább 5 node esetén már lehet RAID5 és így kevesebb flash médiát kell beletenni a hardverbe

Viszont ára is van a deduplikációnak, néhozzá hogy a disk group entitást failure domain-né teszi. Tehát ha bármelyik kapacitás SSD egy disk group-ban elveszik, akkor a teljes disk group rebuild-je fog a csere után történni illetve a teljes disk group elveszett. Lehet csak compression-t használni, ami pont ezt köszörüli ki, de akkor a hatékonyságból vesztünk.

A RAID5/6-nak is ára van, mivel a VSAN csak szoftveres alapon tud működni – a HyperFlex és Simplivity modellek lefedik a szoftveres és a hardverrel gyorsított opciókat is – ezért CPU/RAM-ban fizetjük meg. Nem véletlen, hogy érzékeny produktív VM-ek alá RAID1 a javasolt.

Kiépítés Előny Hátrány
RAID1 – hibrid vagy all flash(DE/CO nélkül)Nem szükséges sem erasure coding, sem a DE/CO CPU+RAM igényével számolni
A failure domain marad a cache SSD és egy kapacitás HDD/SSD
Minden tárigény duplán kezelendő – 100GB VMDK az 200GB-ot foglal majd
RAID1 – all flash DE/CO-valA tárigény jelentősen alacsonyabb – kb 1,5:1 – tehát 100GB VMDK 122GB-ot foglal majd RAID1-ben A failure domain maga a disk group lesz
CPU+RAM igény
RAID1 – all flash CO-val(compression only) A tárigény jelentősen alacsonyabb – kb 1,22:1 – tehát 100GB VMDK 166,6GB-ot foglal majd RAID1-benCPU+RAM igény
RAID5/6 all flash – DE/CO nélkülRAID5-ben 100GB VM, 166GB-ot foglal majd – itt egy hoszt eshet ki
RAID6-ban 100GB VM, 150GB-ot foglal majd – itt akár két hoszt is kieshet
CPU+RAM igény
R5 esetén legalább 4, R6 esetén legalább 6 node szükséges
RAID5/6 all flash – DE/CO-val) RAID5-ben 100GB VM, 110GB-ot foglal majd
RAID6-ban 100GB VM, 100GB-ot foglal majd
CPU+RAM igény
A failure domain maga a disk group lesz
R5 esetén legalább 4, R6 esetén legalább 6 node szükséges
RAID5/6 all flash – CO-val(compression only) RAID5-ben 100GB VM, 139GB-ot foglal majd
RAID6-ban 100GB VM, 125GB-ot foglal majd
CPU+RAM igény
R5 esetén legalább 4, R6 esetén legalább 6 node szükséges

Nem szabad elfelejteni azt sem, hogy a minimálisan szükséges kiszolgálók számához érdemes még egyet hozzáadni, hiszen karbantartás esetén is szükség lehet rá, illetve ha hosszabb időre veszik el egy hoszt, akkor a javítás idejére jó ha van kapacitás – mind diszk, mind CPU/RAM. Viszont ez a node-ot is licenszelni kell mind vSphere-re és VSAN-ra is. Tehát a plusz hardver mellé, plusz licensz is kell.

Apróbb ügyfeleknél a 3 szerver egy QNAP NAS rendszereik cseréje. Pénzügyileg lehetetlen egy 4 szerver, VSAN all flash irányra váltani. De még akkor is ott van a tény, hogy tükörbe kell tárolni minden adatot. Szóval egész egyszerűen túl kicsi ahhoz, hogy ilyet vehessen. Hibrid is megoldás lehet, de akkor tényleg dupla tárterületet fog felhasználni, ami nyilvánvalóan több mint amennyit például a QNAP használ RAID5-ben. Két node fölött még a 10Gbit-es hálózat igénye is felmerül, ami szintén plusz költség ha egyébként nem rendelkezik olyannal.

A nagyobb ügyfeleknél általában a szigetszerű működés miatt gondolkodnak el rajtuk és nem azért mert teljes egészében le kívánják válatni a tárolójukat. Ezekenél az eseteknél jelentős tényező az üzemeltetés mikéntje. Egy ablakból kezelhető minden ami a rendszerrel kapcsolatos – bár ez ma már elérhető rendes tárolós rendszereknél is. Nem kell a SAN-os kolléga egy új szerver beállításához, nem kell a tárolós csoport egy új datastore kiadásához.

Apropó bővítés. Ez a lényeg. Itt dől el, hogy VSAN irányba lép valaki vagy HPE Simplivity/Cisco Hyperflex felé. A DellEMC VXrail egy VSAN alapú rendszer és azt annyiban veszem a VSAN kalapja alá, hogy bővíthetőségét tekintve szinte azonos szabadságot ad a másik két gyártó megoldásával szemben.Felfogható ez egy mérleg két serpenyőjén lévő két elemmel.

Itt nem a technológiai különbségekről beszélek, mert a Simplivity-nek nincs párja az adattárolás hatékonysága területén, a Cisco-nak pedig a hálózati részek HyperFlex-el összefüggő konfigurációjában. Arról beszélek, hogyha bővíteni kell, akkor milyen lépésekben és milyen jóváhagyással tehetem. VSAN esetén gyakorlailag bármit módosíthat az ügyfél, amíg támogatott komponenst használ fel. HPE Simplivity esetén nem lehet csak egy médiát betenni, csak az előre definiált méreteken lehet lépkedni – extra small-small-medium-large-extra large. A memóriával is így van ez. Nem működik, ha valaki 192GB RAM-ról csak simán 256GB-ra menne fel hosztonként, mivel olyan kiépítés gyárilag sincs.

A Cisco HyperFlex kicsit szabadabb ebből a szempontból. Viszont az elmúlt egy évben több olyan vCenter-t és ESXit érintő sebezhetőséget láttunk, amely azonnali frissítést igényelt a rendszerekben. Az összecsiszolt mivolta miatt a nem natív VSAN-nal operáló gyártók sajnos nem tudnak gyorsan lépni, kétségtelenül eltelhet pár hét vagy hónap mire a javítással telepített vCenter/ESXi támogatottá válik a rendszereiken.

Ma meg is jelent például egy CVSS 9.8 sérülékenység és a nem HCI – kivéve VSAN – ügyfelek, már nyugodtan telepítik is a frissítéseket, mindenki más vár! (link)

Ha ez fontos valakinek, akkor csak a VSAN jöhet szóba – a VXrail sem – azaz VSAN ready node alapú HCI.

Összefoglaló

A HCI rendszerek a gyenge forint és a csúcson lévő RAM/SSD árak tekintetében most picit még nehezebben eladható megoldások. Technológiai szinten szinte minden infrastruktúrába illeszhetők, de az esetek 99%-ban sajnos a pénzügyi tényező miatt nem kerülnek kiválasztásra. Itt kettősséget érzek, mert a “start small” lenne a kecsegtető kezdet – induljon kicsiben – de akkor nem jönnek ki olyan előnyei, amelyek jóval olcsóbbá is tehetnék az egészet, szóval “go big” mégis jobb lenne – pl VSAN-nál legalább 4-5 node – viszont az árak miatt elrettentő tud lenni. Főleg, hogy ekkor viszont már bele kell számolni a képletbe a 10Gbit-es hálózatot is, ami ha nem áll rendelkezésre még, akkor további teher.

A HCI-nek van helye a piacon, de leváltani soha az életben nem fogja a központi tárolókat a nagy ügyfeleknél, maximum valamilyen speciális feladatra – VDI, K8s, DMZ, felügyeleti klaszter – kerülnek telepítésre. Kis ügyfeleknél egyáltalán nem, mert kevés kivétellel túl nagy pénzügyi teher.

Kirakott HCI-ban