Sok tévhit, mítosz és mágia kering az interneten, arról hogy miképp is kell pontosan méretezni egy VSAN környezetben a hosztokat. Azért fontos gyakorlat ez, mert nem csak az elérhető sebességet befolyásolja, hanem elveheti a kedvét egy cégnek kb. egy életre az az első – és vélhetően rossz – tapasztalat amit egy ilyen rendszer ad.
Mi teszi elégedetté/boldoggá a felhasználókat? Az a teljesítmény / sebesség / felhasználhatóság, amely minden esetben – konstans módon – rendelkezésre áll és nem ingadozik. Tehát az negatív érzetet kelt, ha például egy VDI gép 90 másodperc alatt indul el és 35 másodpercig tart rá belépni, mikor öt perccel ezelőtt teljesen ugyanez a folyamat csak 30 másodperc volt. Nem konzisztens….és mindenki szereti a konzisztenciát.
Két megközelítést látok itthon azzal kapcsolatban mi kerül egy SDS megoldás alá:
- (gyakoribb) Vannak nem olyan régi szerverek, jó sok lemezzel és talán SSD-vel is. Használjuk fel őket és nézzük meg mit tud a VSAN.
- (ritkább) Írjuk le hogy mit akarunk futtatni, mennyi tárkapacitásra van szükség, milyen rendelkezésre állást várok el. Ezek mentén kiválaszjuk a hardvert. Jobb esetben VSAN ready, még jobb esetben Vxrail vásárlása.
Mindkét esetben fel kell tenni a következő kérdéseket:
Hány telephelyem van? Ha egy telpehelyem van, akkor valószínű hogy nem kell nekem stretched cluster. Határozzuk meg a fault domain-t, azaz a node-jaim egy rack-ben vannak (ekkor egy fault domain-ben van mind), több rack-be van szétszórva(több fault domain)? Azért fontos ez mert a következő kérdés mentén, kikalkulálható a szükséges kapacitás.
All flash vagy hibrid? Ez a legnehezbb kérdés, viszont egy fontos különbség egyből látható. Az all flash VSAN-nál az olvasás minding SSD rétegből jön, hiszen a kapacitást is SSD adja. Ezzel szemben a hibrid kiépítésben a caching algoritmus legjobb szándéka ellenére is előfordulhat olyan olvasás, amely nincs az SSD cache-ben, ezáltal az pörgő lemezről kerül kiszolgálásra. Másik tényező az, hogy hibrid esetén csak RAID0 és RAID1 elérhető, így utóbbinál legalább kétszer annyi tárhelyre van szükség mint a virtuális gépek lemezei. A teljesen flash kiépítésben alkalmazható a RAID5/6 erasure coding is, amivel ez a fajta overhead csökkenthető, megőrizve a szükséges redundanciát, továbbá bekapcsolhato a deduplikáció és tömörítés is. Ez a döntés meghatározza a szükséges kiszolgálók minimális számát, azt hogy kell-e az erasure coding miatt CPU terheléssel számolni.
Milyen formátumú kiszolgálókkal tervezek? Rack mount esetében is nyitott a kérdés hogy mennyire tervezem skálázhatóra a rendszert. Például egy HPE DL360 Gen10 esetében SFF lemezek esetén 10 – plusz egy hátra – 2,5”-os lemeznél többet betenni nem lehet, ezáltal a kialakítható disk group-ok száma normális keretek között kettő, esetleg három. Ezzel a VSAN licenszek nem optimális megvalósítása történik, mivel 29 lemezzel kevesebbet használok ki mint amennyit egy akár egy socket-re licenszelt VSAN támogat.
Hány kontrollert használhatok? Sok gyártó SAS expander segítségével valósítja meg a lemezek elérését, ezáltal a fault domain végső esetben a SAS vezérlő, illetve az expander maga. Ez jól tervezett rendszernél nem jelenthet problémát, de jó észben tartani. Nem tennék bele több controller-t, mivel megdrágítja a hardvert és nem jelenthet gondot egy hiba miatti pár óra amely a javításig eltelik – persze ha garanciális a szerver.
Mennyi disk group legyen? Nincs igazi szabály, de véleményem szerint érdemesebb két disk group-pal kezdeni, mivel bár a beruházási költség magasabb lesz, később, bővítés esetén már nem kell SSD-t vásárolni/átszervezni, elég csak a kapacitást adó lemezek beillesztése. Tehát ha van 6 darab kapacitást adó lemezem akkor, javasolt 1 SSD cache + 3 SSD/HDD capacity formában felhasználni.
Milyen hálózati lehetőségekkel rendelkezem? Minden esetben javaslom a 10Gbit/s hálózat használatát, függetlenül attól hogy hibrid vagy all flash, mivel 110-120MB/s igen kevés lehet, figyelembe véve a VSAN-on kiszolgált virtuális gépek írás/olvasását és mivel a VSAN világában a lokalitás nem értelmezett, könnyen előfordulhat, hogy azon a hoszton amin a VM fut, annak egyetlen objektuma sincs, ezért annak minden aktivitása a hálózatot terheli.
Fiktív ügyfél 24TB virtuális géppel rendelkezik, hibrid megoldást szeretne, egy karbantartás során is megvalósuló redundanciával. A virtuális gépek memóriája, 6.7-ben már nem “számít” a tervezés szempontjából kiemelt fontosságúnak, sparse módon jön létre.
Hogyan kell kiszámolni mennyi és milyen lemez kell? Alapul kell venni a virtuális gépek méretét – én mindig thick gépekre méretezek – meg kell szorozni a szükséges FTT+1 értékkel, ennek 130%-át venni + 10%-ot (snaphsot stb).
((24TB*1,3(slack))*1,1) * 2(FTT) = 64,32TB
Az SSD cache mennyisége javasoltam a teljes kapacitás 10%-a az FTT kalkuláció előtt.
((24TB*1,3)*1,1) * 0,1 = 34,32 * 0,1 = 3,432 TB
Azaz 3,5TB SSD-re van szükség, amelyet, a node-ok számával kell elosztani. Mivel itt négy kiszolgálóval tervezünk, ezért 3,432TB / 4 = 0,858, de inkább 900GB SSD kell, per szerver. A disk group-ok száma tervezetten legalább kettő, ezért két SSD-vel kell előállítani a 900GB-ot.
Mennyi forgó lemez kell szerverenként? 64,32 / 4 = 16,08TB. Itt felmerül a kérdés, hogy mekkora kapacitású lemezeket használjak? Egy SATA lemez kb 80IOPS-ot szolgáltat, ezért ha lemezcsoportonként kettő 4TB-os, szervereknént négy lemezzel tervezünk, akkor kicsit kevés lehet a pörgő lemezek által biztosított IOPS. A VSAN persze mindent megtesz, hogy kisimítsa a terhelést a flash használatával, de ez igen kevés. Ebben az esetben javaslom inkább a fele akkora, 2TB-os HDD-k használatát.
Mit nyerünk ezzel? Azt, hogy a tervezett kapacitáshoz mérten optimális lesz a kiépítés, viszont egy dologgal még nem számoltunk. Az pedig a bővítés, az SSD kapacitásban nem számoltunk azzal hogy teljes méretre bővítjük a két disk group-ot – amit végső esetben harmadikkal, negyedikkel és ötödikkel bővíthetünk, de az első bővítés mindenképpen a két már meglévő disk group teljes feltöltése kell legyen, lehetőleg azonos méretű HDD-kel.
Ha ez megtörténik, akkor nem 900GB cache kell kiszolgálónként hanem annál többre. Kétszer annyira per disk group, szerverenként 1,8TB-ra.
Ezzel a kiépítéssel már teljesül az a kitétel, hogy a kapacitás megduplázható, pusztán 2TB-os lemezek párban történő bővítésével (szerverenként párban ha lehet). Ha ebből is kifutunk, akkor egy újabb disk group létrehozásával lehet tovább bővíteni a rendszert, ha az is elfogyott, akkor egy újabbal, egészen ötig vagy a kiszolgálóba tehető számosságig.
Egy jól megtervezett és kiszámolt rendszer, az életciklusa alatt képes a kiszolgált rendszerrel együtt nőni, költséghatékony módon. Ezért furcsa az, amire az első bekezdésben utaltam, hogy levetett szervereken gyakrabban fordul elő VSAN, mint újakon, ezáltal aláásva a jó teljesítményt, a költségek szintjén történő összehasonlíthatóságot.
