A vSAN már jó ideje létezik és persze verzióról verzióra kapott új képességeket, változtattak rajta ezt-azt – például a használható cache réteg méretét – és el is hasadt két vonalra, az OSA-ra – ez az ami a kezdetektől velünk van – és ESA-ra.
ESA-t én még az életben nem láttam és OSA-ból sincs túl sok a környékemen, de azért van pár. Nem kell messzire menni, a 99999 Informatika Skyblocks felhőjében is vSAN OSA van. A licenszelési mizéria miatt persze ügyfél oldalon én nem gondolom, hogy majd most kap új lendületet, sőt ahol van jelenleg, ott is elgondolkodnak a kivezetésén, hiszen állati drága lett. Önmagában már nem is vásárolható – ez sem – szóval akinek jelenleg van vSAN-ja, az eldöntheti hogy vSphere Foundation-t akar és veszi hozzá a per TiB licenszeket (gondolom a 100 GiB/core nem boldogít senkit sem) vagy veszi a drágább Cloud Foundation csomagot és vagy belefér az 1 TiB/core kapacitásba vagy/és szintén veszi a per TiB bővítést.
Legalább könnyű a számolás. Vegyünk alapul négy kiszolgálót, kiszolgálónként két fizikai processzorral és processzoronként 16 maggal és egy picit kevesebb magos kiépítéssel.
| vSphere Foundation | Cloud Foundation | |
| 4 szerver x 2 foglalat x 16 mag | 12,8 TiB | 128 TiB |
| 3 szerver x 1 foglalat x 16 mag | 4,8 TiB | 48 TiB |
Árakat nem írok, de arányosítva azért látható, hogy a két konfiguráció között 1/3-a a költsége a VMware licenszeknek ha a processzormagok számát harmadoljuk (128 helyett ugye 48 mag lesz csak). Jelenleg ha valaki Cloud Foundation-t vásárol, mert neki tényleg VCF kell vagy mert éppen úgy éri meg jobban a vSAN-t licenszelni (és lehet még egy csomó másik okat is, pl NSX) akkor nem szükésges azt VCF-ként telepíteni is. Őszintén remélem ez nem fog változni, mert ha VCF-et kell telepíteni, akkor mindenképpen legalább négy node kell és akkor mindenképpen lesz vSAN is, legalább a management/consolidated domain-ben.
Most a nem VCF esetről beszélnék vagy éppen a vSphere Foundation esetről. Teljesen jogos, ha valaki nem négy-öt-hat kiszolgálóval akarja megépíteni a környezetét, hanem a lehető legkevesebbel. A hibrid vSAN-t el is vetem, azt hagyjuk meg a múltnak, szóval all flash-ről legyen szó és teljesen irreleváns, all NVMe, NVMe/SAS vagy SAS/SATA akármi összetételű. Ismétlem OSA-ról beszélek.
A VMware Cloud Foundation amúgy nem buta, mármint aki a követelményeit írta az nem volt az. Azért kell négy szerver ahhoz, mert kell a redundancia. Ebből kiindulva mindig felmerül a kérdés, hogy a három node-os az nem redundáns?
De igen, redundáns. Normál üzemben az, mivel mindent vagy RAID1-ben vagy RAID0-ban tárol, a node-ok között. Utóbbi esetben persze nem az, de ki az aki ilyet csinálna? A vSAN egy storage policy által működő dolog, illetve fogalmazhatnék úgy is, hogy a vSAN egy tároló, ami önmagában nem ad semmit csak tárolási kapacitást. A VM-hez/VM home-hoz/VMDK-khoz rendelt storage policy az, ami megmondja a vSAN-nak, hogy milyen redundanciával tárolja a kívánt adatokat és milyen egyéb paraméterekkel tegye azt.
Ha három node van csak, akkor minden egyes objektum – VM home, VMDK stb. – két példányban kerül tárolásra egy witness objektum társaságában. Ezek az elemek nem lehetnek azonos fizikai kiszolgálón, azaz olyan nem fordulhat elő, hogy az egyik node-on semmi sincs, a másik kettőn pedig ott van a két példány és a witness.
Normál üzemben ezzel semmi gond nincs, ha tervezett vagy véletlen okok miatt az egyik fizikai szerver nem elérhető, akkor a redundancia elveszik, hiszen vagy az adott elemnek az egyik adatpéldánya vagy a witness komponense nem lesz elérhető. Működésben ez nem probélma, mert ha az éritnett VM mondjuk pont azon a hoszton futott, ami elpusztult, akkor a HA újraindítja a maradék két hoszton és minden megy tovább, nincs adatvesztés.
De mi nincs ilyen esetben? Mi nem működik?
Nem lehet létrehozni egyetlen VM-et, új VMDK-t sem, hiszen nincs meg a három fault domain, azaz nem tudja eltárolni a létrejövő három objektumot úgy, hogy ne legyen közös pontjuk a fizikai kiszolgálókon. Említettem azt, hogy storage policy szabályozza ezeket, szóval két módon mégis lehetséges léterhozni bármit.
Hogy mi nem lesz még?
Snapshot. Snapshot alapú mentés. És ez probléma, elég nagy. Szóval mondjuk az egyik node behal és önmagában ez, kritikus helyzetbe hozza a rendszert. Az kiszolgálás nem áll meg, kockázatot fut, de ha mentés van, akkor legalább az adatbiztonság megoldott, ha az elérhetőség nem is biztos az elsődleges helyre nézve. Csak éppen mentés sem lesz, hiszen a mentőrendszer hiába szól a vCenter-nek, hogy csináljon snapshot-ot a VM-ről, az kiírja hogy hát nem tud snapshot-ot csinálni.
Nézzünk meg egy ilyen esetet a Veeam-ben is péládul – nem a fenti eset de az ok azonos volt.
Legalább mentés legyen!
Ezt két módon lehet megoldani egy ilyen helyzetben, de mindkettő maximum ideiglenes kell legyen. Csak a snapshot-ra vonatkozóan nem lehet policy-t beállítani, ezért vagy VM vagy datastore szinten kell ezt policy-vel kezelni.
Force provisioning
Ezt nevezném az expert kapcsolónak. Bármi be lehet állítva a policy-ben, mindenképpen létrehozza az objektumot, még akkor is ha amúgy nem lesz redundáns. Persze ha a létrehozás után visszatér a harmadik – vagy a compliance előállításához elegendő – node, akkor kiépíti a redundanciát, de amíg nem, az az objektum amit a „kiesés” alatt hoztunk létre, állatira nem lesz hibatűrő. Lehet létrehozni egy új policy-t és azt explicit hozzárendelni a menteni kívánt VM-ekhez vagy éppen módosíthatunk egy már használtat – ami amúgy nem javasolt annyira. Utóbbi esetben meg is kérdezi, hogy a módosításokat végigvezesse-e a hozzá rendelt VM-eken vagy ne. Hát ahhoz hogy érvényre jusson egy már meglévő objektumon, mindenképpen újra kell érvényesíteni, míg az újonnan létrehozásra kerülőkön nyilván nem.
Ezek után a snapshot létrehozás is menni fog.
Nézzük meg az objektumokat is. Alább látható hogy diszk maga tükörben lenne tárolva, persze hiányzk az egyik objektuma, de maga a snapshot amúgy egy komponensből áll már.
Ha ezek után visszatér a harmadik node, akkor a hiányzó objektumok megoldódnak, viszont érdemes a beállított „Force provisioning”-et kikapcsolni és újra alkalmazni a policy-t.
Fentebb még az is látható, hogy a snapshot is RAID1-ben van már a reapply miatt.
RAID0 policy
Az ilyen policy nem is használna redundáns tárolást, nem jön létre más, mint egy példányban a kívánt objektum. Ezzel az a baj, hogy a létrehozáskor nem fog sírni, viszont később, ha majd visszatér az éppen „halott” hoszt a világba, akkor emlékezni kell arra, hogy az ilyen policy-val létrehozott objektumokat/VM-eket át kell tenni a redundanciát adó policy-re.
Összefoglaló
Három node tehát elég és persze redundáns is, viszont pont amikor a legjobban kellene – ha például nem javítható instant a hoszt – akkor áttételes problémákat képez majd és így például mentés sem lesz, amíg a fentiekkel fel nem oldja valaki vagy vissza nem tér a harmadik szerver.
