A VMware vSAN megjelenésekor – az 5.5-ös verzió volt az első, 2014-ben – valódi újdonságnak számított a HCI piacon, a hypervisorba történt integrációval végre elhagyhatóvá váltak a kontroller-VM-ek, és nem volt már szükséges különböző admin felületek között ugrálni a virtuális infrastruktúra és a storage kezeléséhez, mindent megkapunk egy felületen a vCenterben.
Viszont korának termékeként a hybrid felhasználás volt a legfőbb tervezési szempont – az all-flash kiépítés nem is volt még támogatott eleinte a 6.0-ig – és ebből következett a két-tieres architektúra, cache ssd-vel és kapacitás diszkekkel diszkgrouponként.
De a fejlődés nem állt meg, és az all-flash, majd all-flash nvme tárolók megjelenésével olyan alacsony válaszidők váltak elérhetővé, amikre korábban nem, vagy csak high-end tárolókkal volt lehetőség, így a HCI technológiáknak is föl kellett zárkóznia.
Itt kerül a képbe a VMware vSAN 8, aminek megjelenésével a szokásos hibajavítások és fejlesztések mellett talán a legnagyobb újdonság a vSAN ESA – Express Storage Architecture.
Ez az újragondolt vSAN architektúra kizárólag all-flash nvme diszkekből építkezik. Erre ugyan korábban is lehetőség volt – a mostantól OSA(Original Storage Architecture)-nak nevezett eredeti vSAN felépítéssel – de mostantól teljesen ki tudjuk használni az nvme-technológiában rejlő potenciált. Az első legszembetűnőbb változás a diszkgroupok és cache-diszkek elhagyása. Eddig hostonként egy vagy több diszkgroup tartalmazott egy cache diszket, ez egy magas írástűrésű ssd, valamint több kapacitásdiszket, amik lehetnek alacsonyabb terhelhetőségű, költséghatékonyabb ssd-k, vagy hagyományos merevlemezek. Az írások először a cachere érkeztek (hybrid kiépítésben egyúttal read-cacheként is funkcionált) majd onnan kerültek továbbadásra – destagelve – a kapacitásrétegre.
Az ESA esetében ez a két tier logikailag a performance és capacity-leg formájában él tovább, viszont mindkettő használja az összes elérhető ssd-t, nincs külön dedikált cache diszk, aminek először el kell viselnie az összes a diskgroupra érkező írást, írási szűk keresztmetszet, és a hasznos kapacitást se növeli. Helyette a performance-leg a beérkező írásokat először RAID1 formában írja ki, annyi replikával amennyit a storage policy megkövetel,- FTT=0-val 1, FTT=1 esetén 2, FTT=2-nél 3 -, hogy minél hamarabb visszaigazolhassa az írást az alkalmazásréteg felé, és hogy összevárhasson egy teljes RAID5/6 stripe-ot,- 128Kb-ot objektumonként – , mielőtt a replikált performance legről a capacity legre kerülnének az adatok az optimális erasure-code írási teljesítményért (a write-amplification nevű jelenség elkerülésével) Így ötvözhető a RAID1 válaszideje a RAID5/6 kapacitás-takarékosságával.
Fentiekből következik, hogy a legkisebb 2 szerveres ROBO kiépítéseket leszámítva a RAID1 használata már nem javasolt, és már 3 host esetén is elérhető a RAID5, az új 2+1 stripe opció használatával, a korábbi 3+1-ből következő minimum 4 host helyett. Ezen felül most már a 4+1 RAID5 is elérhető még jobb kapacitás hatásfokkal (1,25x) minimum 5 hosttal.
A RAID5 erasure code policy az új stripe opciók, azaz a 2+1 és 3+1 között dinamikusan is képes váltani, amennyiben növeljük, vagy csökkentjük a cluster méretét, hogy megfelelő számú host esetén könnyedén ki tudjuk használni a nagyobb hatásfokot. A szolgáltatásbiztonság érdekében ez nem egy meggondolatlanul hirtelen változás, a cluster méretének változása után csak 24 órával kezdi el a háttérben az átállást:
Itt fontos megjegyezni, hogy a minimum hostszám nem egyenlő az ajánlottal, amennyiben van rá lehetőség mindig érdemes +1 hosttal számolni – mint egy hagyományos RAID tömb esetén az egy vagy több spare diszk – hogy egy host huzamosabb kiesése esetén helyre tudjon állni a redundancia, vagy tervezett karbantartás előtt a maintenance mode bekapcsolásakor mi kérhetünk Full data migration-t, mielőtt leállítjuk a szervert.
Ha már szóba került a karbantartás, a cache diszk+diszk groupok elhagyása ezen a téren is előnyös. Egy cache diszk kiesése esetén a teljes diszkgroup elveszett a cluster számára, a cache diszk cseréje után az érintett groupot újra kell építeni, és minden adatát átmozgatni a megmaradt hostokon lévő replikákból vagy EC-blokkokból a vSAN hálózaton. Ezért is best-practice a mai napig, hogy ha van rá lehetőségünk, akkor OSA vSAN clustert hostonként több diskgrouppal tervezzünk, mert minél több diszkgroupunk van, akkor egy kiesése annyival kevesebb rebuild forgalmat, és időt igényel, mire újra egészséges lesz a cluster. Ezen felül, ha bekapcsoltuk a Deduplication and Compression opciót, akkor a deduplikáció miatt a diszkgroup kapacitás diszkjei a deduplikált vSAN objektumok számára új látszódnak mint egy RAID-0 tömb, ekkor bármelyik diszk kiesése esetén a groupban ugyanaz a helyzet áll fent, mint a cache elvesztésekor.
Az ESA esetében viszont minden diszk független, és egy kiesése esetén maximum az érintett diszknyi adatot kell újraépíteni. A kiesett objektumok újraépítése a megmaradt diszkeken lévő szabad területen automatikusan elindul, és ha a vSAN Managed disk claim opció is be van kapcsolva, a cserediszket is automatikusan használni kezdi a cluster amint behelyeztük.
Deduplikációt az ESA egyelőre nem támogat, viszont cserébe jelentős fejlődésen esett át a tömörítési képességeit illetően. A hagyományos vSAN a tömörítést cluster szinten engedte bekapcsolni, és az IO útvonalon hostonként, a diskgroupok fölött történt a tényleges tömörítés. Az ESA ezzel szemben följebb emelte a tömörítést a stackben, a VM-ről érkező írás először tömörítésre – és ha be van kapcsolva, titkosításra – kerül, majd utána kerül kiírásra a helyi hostra, és továbbításra a hálózaton a cluster többi tagjának. Így CPU erőforrást is megtakarítunk – egy alkalommal kell tömöríteni csak az adatot, nem diszkgrouponként – és hálózati forgalmat is, mivel csak a már tömörített adatot továbbítjuk. A teljesítményt tovább javíthatja, hogy immár VM objektum szinten kapcsolhatjuk a tömörítést, így ha tudjuk, hogy például bizonyos virtuális diszkeken már tömörített, vagy titkosított adatokat tárolunk, ott kikapcsolva további fölösleges köröket spórolhatunk meg a CPU számára.
A minimum követelmények – hogy az ESA lehetséges hátrányairól is beszéljünk egy kicsit:
– 1.6TB vagy nagyobb, legalább 1 DWPD terhelhetőségű NVMe diszkek.
– 25GbE vagy gyorsabb vSAN backend hálózat
– 512GB RAM / host.
A minimum memória értékektől a ReadyNode profilokhoz képest fölfelé el lehet térni, lefelé nem. Ez utóbbi pont lehet különösen fájó kisebb környezetek esetén, de fontos kihangsúlyozni, hogy nem az új architektúra memóriaigénye növekedett meg, sőt, a fentebb taglalt fejlesztéseknek köszönhetően még hatékonyabban is gazdálkodik az erőforrásokkal. Az OSA esetében elérhető,szabadabban konfigurálható build-your-own megoldásokkal szemben a szigorúbb ReadyNode feltétel az esetleges szűk keresztmetszeteket hivatott elkerülni. Viszont van okunk bizakodni, hogy ahogy gyűlik a tapasztalat, úgy lesz ez a feltétel egyre rugalmasabb. Az ESA első megjelenésekor például az ssd endurance érték minimum 3 DWPD volt – ezt a kategóriát nevezik már mixed-use-nak – amit a legnagyobb ReadyNode profilt leszámítva már 1 DWPD-re csökkentettek, valamint VMware körökben már említésre kerültek esetleges jövőbeli ROBO/Edge profileok is, csökkentett minimum memóriaigénnyel (viszont ezen cikk írásakor erre ígéret még nem született).
Természetesen az eredeti OSA architektúrát sem hanyagolja mostantól a VMware, és ha akár a megnövekedett minimum igények miatt, akár csak azért, mert a workloadunk egyszerűen nem követel meg all-flash teljesítményt, továbbra is remek alternatíva.
Viszont ha all-flash teljesítményre van szükségünk, és szeretnénk mindent kihozni abból, amire az nvme technológia csak képes, akkor ha vSAN, akkor a jövő az Express Storage Architecture.
