Prvním zástupcem je vSAN. První verze přišla s vSphere 5.5U1 a aktuální verze vSAN je 6.7 která přišla s vSphere 6.7. Ten využívá lokální disky v serveru a z minimálně 2 fyzických, resp. 3 serverů a aktuálně s verzí 6.7 maximálně 64, dohromady publikuje sdílený datastore. Ten se replikuje na pozadí.
Nejedná se ale o replikaci celého úložiště, jako tomu je například u VSA, ale právě pouze o replikaci konkrétních objektů.
Počet replik je pak dán politikou, kterou na daný objekt aplikujeme. Tedy, jaké vlastnosti mu nastavíme. A jsme zpátky u těch objektů.
Každý objekt má svoje Object ID, což je hexa decimální hodnota.
Když se pak podíváme do Browse datastore, tak už uvidíme jen logickou reprezentaci, tudíž jen zobrazení složek a souborů, ale nevidíme, co se skutečně děje na pozadí. Abychom se mohli podívat i hlouběji, tak se musíme podívat přes RVC konzoli, která je už nějakou dobu automaticky součástí vCenter Server Appliance, nebo přímo přes SSH na hostu.
Jak vypadá takový vSAN object storage?
Každý objekt je složen z několika komponent, které jsou buď kompletními replikami včetně dat, nebo jen witness metadata, jež rozhodují která komponenta bude dále publikovaná a která ne. Například, pokud se část hostů odpojí. Vždy je potřeba mít nadpoloviční většinu dostupných komponent, aby mohl být objekt nadále dostupný.
Když budeme vytvářet novou politiku, máme k dispozici několik parametrů, které ve výsledku budou ovlivňovat dostupnost, výkonnost a také obsazené místo objektem, na kterém tuto politiku aplikujeme.
1) “Failures to tolerate” (FTT)
Pro toleranci výpadku 1 komponenty (FTT=1) tedy potřebuji mít 2 komponent repliky a 1 witness
Pro toleranci výpadku 2 komponent (FTT=2) potřebuji 3 komponent repliky a 2 witness
pro toleranci výpadku 3 komponent (FTT=3) potřebuji 4 komponent repliky a 3 witness
Samozřejmě že každá komponenta, ať už kompletní replika, nebo witness musí být umístěna na jiném hostu, tak aby se nepotkali na stejném. Od toho se odvíjí i minimální počet hostů, který k takovéto dostupnosti je vyžadován.
FTT=1 vyžaduje minimálně 3 hosty
FTT=2 vyžaduje minimálně 5 hostů
FTT=3 vyžaduje minimálně 7 hostů
Výhoda tohoto modelu je, že pro každý objekt můžete nastavit jinou úroveň dostupnosti a nemusíte tedy celý datastore nastavit na maximální výpadek a pak tam dávat i stroje, které takovou úroveň dostupnosti vůbec nepotřebují, jako to bývá u běžných sdílených polí.
Proč ale na začátku jsem zniňoval 2 fyzické hosty? Protože existuje možnost, která je používaná zejména pro vzdálené malé lokality, kde jsou 2 fyzické hosty přímo na lokalitě a 3. witness je virtuální v datacentru.
2) “Disk stripes per object”
Tento parametr je důležitý zejména na hybridních řešeních, kdy se používají pro kapacitu klasické rotační disky (HDD). Tyto disky hold mají svoje fyzikální limity v počtu skutečně náhodných přístupů. Představte si situaci, kdy se disk otáčí, hlavička je nastavena na nějakou polohu a vy budete chtít přečíst informaci, kterou hlavička právě minula. Bude se muset počkat, dokud se plotna prostě neotočí. Tímto je u HDD limit pro skutečně náhodné operace, tzv. Random IOPS.
Díky tomu, že se nastaví větší množství částí, na které se každý objekt rozdělí můžeme využít toho, že je možno číst z více HDD najednou. Toto již nemusí být rozloženo jen mezi hosty, ale stačí rozložit jen mezi HDD v rámci jednoho hosta.
I když ale nastavíme Stripes na 1, nebo nenastavíme tento parametr vůbec, je možno, že se objekt rozdělí na více částí. To se stane pokud objekt přesáhne velikost 250 GB.
3) Dataprotection method
Od verze vSAN 6.2 je možno nastavit na AllFlash konfiguraci místo úplné kopie (RAID 1) aby využívat paritu na blocích, tedy RAID5/6 podle toho, jaké FTT nastavíme.
Toto umožní lepší využití kapacity, protože pro zajištění odolnosti při výpadku jednoho objektu (FTT=1) není potřeba mít 2x alokovanou kapacitu, ale jen 1,33x, stejně tak pro FTT2 místo 3x alokované kapacity to je 1,5x.
Má to i svoje stinné stránky, jako je větší provoz na pozadí na síti, nebo minimálně 4 hosty pro RAID5 a 6 hostů pro RAID6.
4) Object space reservation
Primárně se na vSAN všechny objekty vytváři ve thin provisioning módu. Tedy alokuje se jen takové místo, kam se někdy zapisovalo. Abychom ale u některých systémů mohli zajistit, že budou mít minimálně nějaký prostor i kdyby na zbylém datastore už místo došlo, máme tu tento parametr. Ten určuje kolik % už se dopředu vyhradí pro tento objekt. Má to tedy více možností, než jen prosté Thin/Thick provision na VMFS
Příště se podíváme na zoubek virtual Volumes na NetAppu.