A VMworld-ön az utolsó előadás – szó szerint – csütörtökön 15:00 és 16:00 között, számomra a 2VSAN Best practices” volt. Aki hallgatja a Virtually Speaking podcast-ot ( https://www.vspeakingpodcast.com/ ) azok számára nem ismeretlen Pete Flecha neve – és John Nicholson sem. Tavaly volt szerencsém velük találkozni Atlantában, de most csak Mr.Flecha tette tiszteletét, Glenn Sizemore-al az oldalán. Ebben a posztban a hallottakat egészítem ki a saját gondolataimmal.
Stílusosan a második slide máris elárulta, hogy nincs általános legjobb gyakorlat, semmi sem igaz mindig és minden környezetre. Mivel a VSAN maga egy szoftveres megoldás és mivel gyakorlatilag bármin be lehet konfigurálni ami ESXi-t képes futtatni, ezért kismillió konfiguráció képzelhető el és ezek közül akár egy adott rendszerre vizsgálva is lehet több jó megoldása. A technikai konfiguráció természetesen annak rendelőjön alá, hogy mit akarunk kiszolgálni a VSAN-nal.
Aki foglalkozott a VSAN-nal az pontosan tudja, hogy bár hasonlóan prezentált a datastore mint egy blokkos tárolónál, valójában a VSAN egy objektum alapú tároló. Minden amit tárolunk rajta, az egy objektum és ennek megfelelően minden egyes virtuális gép, több objektumból áll.
Igazából még egy VMDK is állhat több objektumból, főleg hogy egy objektum maximális mérete 255GB lehet, viszont egy VMDK értelemszerűen ennél lehet és kell is néha hogy nagyobb legyen. Ahhoz, hogy jól meg tudjunk tervezni egy VSAN-os tárolót, tisztában kell lenni azzal is, hogy mégis miképpen helyezi el ezeket az objektumokot a VSAN. Itt jön a képbe az, hogy hány példányban tárolja és milyen metódus mellett. Fentebb látszik, hogy RAID1-ről beszélünk, így mindent tulajdonképpen kétszer tárol el és van witness is. Így a példában szereplő 700GB-os objektumot háromszor kettő plusz egy objektum „írja” majd le. A védelem szintjét a „VM Storage policy” határozza meg, ami rendelhető több vagy egy VM-hez, de akár egy VMDK-hoz is.
Ezek a vCenter adatbázisában tárolónak, így bármilyen objektumhoz – VM és konténerek – hozzárendelhetők, akár VMDK szinten is.
Természetesen semmi sincs ingyen. A RAID1-nél FTT1-nél kétszeres, az FTT2-nél háromszoros tárolási igénnyel fizetünk, így lesz egy 100GB-os VM-ből 300GB foglaltság és a szükséges hosztok száma, első esetben legalább 3, a második esetben legalább 5. Ha RAID5-ről beszélünk, akkor bár picit barátságosabb az a „büntetés” amit tárolási kapacitásban a redundanciáért fizetünk, de a szükséges hosztok számával viszont fizetünk érte, mert FTT1 esetén 4 szerver kell hozzá. RAID6-nál pedig már 6, de ez legalább lefelezi az RAID1 FTT2 300GB-os igényét, 150GB-ra.
Hardver
Két model van, a hibrid és az all flash, de felépítésben teljesen azonos a kettő, attól eltekintve hogy az elsőben a kapacitást HDD-k adják.
A működésben is van némi különbség, mert az all flash-ben a cache csak írásra használt, az olvasás mindig a kapacitás SSD-kről érkezik. Ezzel szemben a hibrid a cache réteget 70-30 arányban használja írásra és olvasásra, ezáltal erősen hagyatkozik a jó caching algoritmusra. Mindkettőre általánosan igaz, hogy disk group(okra) osztottak és mindegyik ilyen group-ban kell legyen egy és csak egy cache SSD és legalább egy, de maximum hét kapacitást adó HDD (hibrid esetén) illetve SSD (all flash esetén).
Mindig legyen legalább kettő disk group a VSAN környezetünkben! Ez nem újdonság, régóta mondogatom én is. Azért nagyon fontos ez, mert mivel disk group-onként csak egy cache SSD van, ezért annak meghibásodása a teljes disk group-ot elérhetetlenné teszi. Ha ez megtörténik és a virtuális gépek nem RAID0 policy-vel voltak beállítva, akkor nincs kiesés, mert valahol a VSAN klaszterben valahol még biztosan van legalább egy példány – RAID5/6-nál pedig több is lehet. Azonban ekkor, ha van az érintett node-on még egy disk group, akkor azon újra tudja építeni a kiesett komponenseket. Erre egyébként akkor is van lehetősége, ha van egy olyan szabad node is a klaszterben, ahol a meghibásodott disk group-on tárolt objektumok más másolatai még nem tároltak. Magával azzal, hogy több disk group-ot teszünk egy node-ba, igazából sokkal több lehetőséget adunk a rendszernek az öngyógyításra.
Mivel a VSAN egy elosztott tároló, ami központi tárolónak mutatja magát, ezért nagyon-nagyon fontos a hálózat. Ezt nem szabad alulméretezni. Erről korábban is beszéltem már, hogy nem kifizetődő ócska/olcsó/levetett switch-eket felhasználni erre, mert hiába tesz valaki NVMe SSD-ket a VSAN-ba, ha a hálózat rossz a node-ok között.
Legalább 10Gbit-es hálózat, de inkább 25GBit manapság, mivel utóbbiak portra számolt ára kürölbelül azonos. A switch-ek non blocking/line rate switch-ek legyenek nagy bufferrel – bár ezt utóbbi gyakorlatilag a 25/40/50Gbit-es switch-eknél már alap. Bár a VSAN még nem használ RDMA-t de ez nem jelenti azt, hogy nem is fog soha, ezért olyan NIC-ek kerüljenek a szerverekbe, amik ezt tudják – manapság már majdnem mindegyik tudja.
A cache SSD-n nem szabad spórolni, mivel MINDEN írás ide jön be. Ennek elég gyorsnak kell lennie és elég magas megbízhatósággal kell rendelkeznie (TBW)
Kapacitásba elég teljesítmény tekintetében a Class B vagy C, de cache rétegbe inkább D-E-F kerüljön. Az elérhető teljesítményt amúgy is a cache fogja legjobban befolyásolni, illetve talán még a szerverben található processzor órajele és teljesítménye. Fontos, hogy legyen elég szabad CPU, hogy még a VSAN-t is ki tudja szolgálni a VM-ek mellett. Ezért egy alapvetően túlterhelt hosztra VSAN-t tenni értelmetlen, ugyanígy ha low end CPU-kkal tervezi valaki az SDS kalandot.
A node-ok száma. Talán sokat ezt nem is kell magyarázni. Attól függően, hogy milyen RAID szintet és azon belül milyen mennyi hiba együttes tűrését tervezzük kiesés és adatvesztés nélkül lekezelni, kell meghatározni a hosztok optimális számát. Alább a minimális szám látható.
Így a példa kedvéért egy RAID1-es módon, két hoszt együttes kiesése esetét is kezelni képes VSAN klaszterben legalább 5 darab hoszt szükséges.
Ez szép és jó, de inkább minimum + 1 hoszt javasolt, de inkább minimum + 2. Meglepő lehet, de ez azért javasolt, mert ha például karbantartás folyik az egyik hoszton és akkor történik valami nem várt esemény, akkor legyen olyan hoszt, amin újra előállítható a szükséges redundancia. Azt gondolom, hogy ez útóbbi csak akkor valós, ha valakinek sok a pénze vagy éppen nincs támogatása a hardverre, szóval a meghibásodott hoszt javítása csak igen lassan történik meg.
Deduplikáció és tömörítés. Ilyen csak all flash-nél van és csak bizonyos licenszelési szinteken. Bekapcsolni könnyű viszont azért érdemes átgondolni, mit is csinál.
Konfigurációs elemek
A deduplikáció nevezhető in-line-nak, mivel a cache rétegből a kapacitásra történő destage folyamat alatt történik a DECO folyamat, 4K fix mérettel.
Fentebb látható hogy nem ritka a 2.5:1-hez, de legalább 2:1-hez várható a DECO arány. Ez csábító, de pusztán ennek a bekapcsolásával a párhuzamosan használható tárolónkat – mivel egyszerre több VM képes, azonos blokkot írni – szekvenciálissá tesszük. Ennek ára van a CPU felhasználásban is, szóval ha olyan VSAN-t szeretnénk, ahol az átviteli sebesség – throughput – és igazából a nyers elő a fontos, akkor ne kapcsoljuk be. Ha van elegendő hely, akkor egyébként ez be- és kikapcsolható menet közben, ha mégsem hozza az elvárt dedup arányt vagy nagyon sérül a sebesség.
Titkosítást is tud a VSAN, de kell hozzá valami KMS szerver. Magától értetődik, hogy a KMS szerver ne legyen magán a VSAN-on futtatott VM, mert akkor könnyel kerülhetünk körkörös függőségbe és elveszíthetjük minden adatunkat.
A frissítések során, mint minden vCenter-el is dolgozó egyéb VMware termék esetén – NSX, vCOPS stb. – a vCenter Server-t kell először frissíteni, utána pedig a hosztokat, a klasztereken belüli kontisztencia elsődleges és minél hamarabbi visszaállítására törekedve.
Quality of service is van és végre valahára valaki más szájából is hallottam azt, amit évek óta szajkózok. A QoS nem a noisy neighbor probléma megoldására van, hanem a normális baseline kialakítására. Hogy jobban megmagyarázzam, nem azzal van a baj, ha egy tároló pédául 5 ms késleltetéssel szolgál hanem, azzal ha egyszer 1ms, máskor meg 10 ms a késleltetés. Azaz azzal van a baj ha ennyire változó és nem kiszámítható. Ha valami mindig 1000 IOPS-ot tudott, de még nem volt teljesen belakva és az ügyfél emiatt 1000000 IOPS-ot kapott, akkor majd ha 1000 IOPS-ot fog kapni, akkor érzi hogy a korábbinál sokkal lassabb lett. Rossz baseline alakul ki benne. És pont erről van itt is szó, így állítja be a Microsoft is Azure-ban a lemezek IOPS értékeit.
Csíkozásnak – stripe width – csak akkor van értelme, ha kimérhetően segít egy adott workload nagyobb teljesítményének elérésében. Korábban említettem, hogy 255GB a maximális objektum mérete a VSAN-ban. Ezt lehet még kisebb darabokra szűkíteni.
A fentebbi példában stripe witdh = 1 esetén csak egy objektum lenne a VMDK, amit tárolna két node-on és egy harmadikon a witness objektum miatt. Na ha ezt stripe width = 2-re konfiguráljuk, akkor ez az egy objektumot szétvágja két részre és azokat tárolja le, viszont elképzelhető, hogy azt azonos disk group-ba teszi, amik így még azonos cache SSD-t is használnak. Ebbe beleszólásunk nincs, így kb elképzelhető, hogy nemhogy gyorsabb nem lesz, hanem éppen ellenkezőleg, lassabb ha SW=2-t használunk. Kapcsoljuk be, mérjük ki és kapcsoljuk ki, ha nem segített!
Force provisioning. Ez a kill switch, ha bekapcsolod az kb olyan mintha az autóban kikapcsolsz minden vezetést segítő és biztonsági rendszert. Ha baromságot akarsz csinálni, akkor nem fog sokat ellenkezni, hagyja hogy baromságot csináj és legrosszabb esetbe adatvesztésbe torkolljon egy ilyen outrun.
Az Object space reservation értékén akkor érdemes módosítani, ha egyébként a VSAN által mutatott szabad helyet szeretnénk oly módon beállítani, hogy az elvegye a kedvét mindenkinek a túlfoglalástól. Ha ezt itt thick-re állítom, akkor a VSAN szabad kapacitása az ennek megfelelő RAID védelem és FTT értékével automaikusan dekrementálódik. Adat nem kerül leírásra, tehát nem nulláz ki semmit – eager zeroed – lazy zeroed lesz, viszont ennyivel kevesebbet mutat majd, így mikor VM-et hoz létre valaki, akkor azt nem tudja megtenni a mi VM-ünk kárára.
Storage policy
Használj több storage policy-t, mert nem minden VM/VMDK igényli ugyanazt a beállítást. Pont ez minden SDS rendszer előnye, hogy nem a LUN szinten beállított, hogy valami RAID5 és minden erre a datastore-ra kerülő VM majd alapból RAID5-tel lesz védve, hanem elemi szinten határozható meg.
A storage policy váltásokkal érdemes vigyázni, mert a teljes rendszer beborítható vele, mind teljesítmény, mind kapacitás tekintetében. Ez is inkább azt implikálja, hogy soha ne módosíts egy használatban lévő policy-t, inkább másold le és explicit rendelgesd hozzá ahhoz, amihez akarod. Megkérdeztem Pete Flecha-át az előadása után, hogy lesz-e végre valahára olyan, hogy egy policy modósításkor a vCenter szól egy lista mutatásával, hogy milyen VM-ek érintettek és hogy ennek kapacitásban milyen kövektezménye lesz. Azt mondta erre ne vegyek mérget.
Nézzünk meg egy ilyen váltást részleteiben:
- Adott egy VM, ami RAID1-et használ FTT=1-el. Stretched VSAN a kiépítés, de ez a VM csak lokális.
2. Átállítjuk a policy-t, hogy a telephelyi kiesés ellen is védjen. Ekkor egyből jelzi, hogy a VM nem compliant a policy miatt és elkezdi létrehozni a másik telephelyen a szükséges komponenseket (2 data és 1 paritás)
3. Kisvártatva meg is építi a szükséges objektumokat és újra zöld, azaz compliant lesz a VM. Létrejött a másik telephelyen még két data objektum – a RAID1 miat – egy witness és a stretch witness is.
4. Ha ezen a ponton átállítjuk RAID5-re, akkor másfajta objektumokat kell létrehozni, mivel itt már nem csak másolatok és witness lesz. Hanem RAID5 szerinti adatok és paritás. A folyamat alatt meg kell őrizni az eredeti RAID1-es objektumokat is, amíg a RAID5 és annak paritását letárolja. Ezért itt szükséges szabad kapacitásra van szükség a node-okon. Ha nincs, akkor kifutunk a helyből és minden read only-vá válik.
5. Ha volt elegendő kapacitás, akkor a szükséges RAID5 komponensek létrehozása után az eredeti RAID1-eseket eltörli és a VM újra compliant lesz.
Mint említettem mindennek ára van és itt adott módosításoknak magasabb az ára.
És ezt most egy virtuális gépen mutattam be, mi lenne akkor, ha ezt többre értelmeznénk. Például ha van egy olyan policy ami RAID-5-öt használ és ezt a policy-t pedig 6 VM is használja.
Hát ennek módosítása ezt eredményezi, bizonyosan megáll minden, mi pedig mehetünk a HR-re a közös megegyezéssel.
Ehelyett tényleg másoljuk le a policy-t és abban állítsuk át RAID6-ra.
Majd ehhez rendeljük hozzá a VM-eket, batchelve.
Nem mellékesen a VSAN 6.7 U3 már amúgy is szakaszosan csinálja a policy módosítások következtében az akciókat, tehát nem az összes VM-re egyszerre, hanem pár VM-es kötegelve. Így van idő cselekedni, ha valami mégis rosszul sülne el.
Slack space – azaz szabad hely. Világos, hogy szükség van rá, legalább az ilyen policy modosítások miatt és legalább legyen 30% szabad. Akkor is jó szolgálatot tesz, ha újra kell építeni egy kiesett disk group-ot, egy teljes hosztot.
Összefoglaló
Egyszerűnek tűnik, mert tényleg csak három kattintás bekapcsolni a VSAN-t, de végső soron egyáltalán nem az. Jól meg kell tervezni és jól meg is kell tanulni az üzemeltetését.
Kérdés esetén keressetek bizalommal!
