Przemysław Tomaszewski, Systems Engineer, VMware

Rozmawiając z naszymi Klientami i Partnerami zauważam, że vSAN w oczach polskiego rynku IT staje się rozwiązaniem Enterprise’owym. Z tego też faktu wynika rosnące zainteresowanie doborem licencji oraz wymiarowaniem sprzętu. O ile typy licencji to sprawa prosta, ponieważ dzielimy funkcjonalności względem przynależności do trzech różnych edycji vSAN (więcej informacji o licencjonowaniu vSAN znajdziecie tutaj), o tyle wymiarowanie to już bardziej skomplikowana sprawa.

Podchodząc do tematu wymiarowania, zacznijmy od początku czyli od doboru cześci sprzętowej. Tu mamy trzy drogi:

• Pierwsza z nich, to możliwość skorzystania z zaprojektowanych i certyfikowanych przez producentów sprzętu zestawów serwerowych dobranych zgodnie z VMware vSAN HCL (pełną, aktualizowaną listę tzw. vSAN Ready Nodes znajdziecie tutaj).
• Druga możliwość, to rozwinięcie powyższej propozycji, czyli skorzystanie ze specjalizowanych serwerowych urządzeń Hyper-Converged Infrastructure (HCI) – tzw. appliance, które są w pełni zintegrowane, prekonfigurowane i certyfikowane przez producenta sprzętu i VMware, przy czym zawierają one również w swoim zestawie licencje VMware vSphere\vCenter\vSAN (HCS) oraz pakiet oprogramowania do ochrony danych (więcej o HCI Gen.1 tutaj). Jeśli ktoś jednak myśli “szerzej” w tej materii, to jest też opcja zbudowania certyfikowanego sprzętu z pełnym stosem produktów VMware SDDC o nazwie VMware Cloud Foundation (więcej o VCF tutaj).
• Ostatnia, trzecia droga, to samodzielne wybranie serwera oraz pojedynczych jego komponentów sprzętowych i złożenia tego razem w całość – w tym miejscu jedna uwaga, tutaj odpowiedzialność za poprawność tej konfiguracji spoczywa na nas – zatem warto wesprzeć się vSphere HCL przy wyborze serwera oraz vSAN HCL przy doborze kontrolera RAID, dysków flash oraz dysków magnetycznych, tak aby podczas uruchamiania nie być rozczarowanym.

Jeśli zdecydowaliśmy się na jeden z powyższych wariantów, to znaczy że nadszedł moment, aby zwymiarować moc obliczeniową, przestrzeń cache oraz pojemność klastra vSAN pod nasze założenia i wymagania.

Procesor fizyczny
VMware vSAN wprowadza narzut na zasoby procesorowe, jednak nie będzie o większy niż 10% per host. W większości znanych mi przypadków wdrożeniowych u naszych polskich Klientów wynika, że narzut ten nie przekracza 5%.

Pamięć operacyjna
vSAN został zaprojektowany według koncepcji grup dyskowych. Jedna grupa dyskowa może mieć maksymalnie 1 dysk SSD, realizujący funkcje cache i od 1 do 7 dysków tworzących pojemność (HDD lub SSD). Takich grup per host może być maksymalnie 5. Łatwo zatem policzyć, że cache może w najliczebniejszym jego wariancie tworzyć 5 dysków SDD, a przestrzeń pojemnościową aż 35 dysków (per host).
Przy okazji pamięci wspominam o koncepcji dyskowej dlatego, iż narzut na pamięć jest zmienny i ściśle zależny od liczby grup dyskowych i zawartych w niej dysków zarządzanych przez host. W chwili gdy host posiada więcej niż 32GB RAM, może śmiało obsługiwać maksymalną liczbę dysk grup i ich dysków, zatem najlepiej aby host nie posiadał mniej pamięci z uwagi na pełne wsparcie skalowalności cache’owo-pojemnościowej vSAN. (Tak przy okazji wspomniane 32GB pamięci hosta nie jest w całości utylizowane przez vSAN, ale również wykorzystywane na poczet hostowania wirtualnych maszyn).

W celu dokładnego obliczenia rozmiaru konsumpcji pamięci RAM przez vSAN potrzebujemy skorzystać z poniższego wzoru:

gdzie:
BaseConsumption: stały rozmiar pamięci konsumowanej przez vSAN per host. Aktualnie wynosi 3GB i głównie wykorzystywany jest przez silnik vSAN, jego metadane oraz cache. W sytuacji gdy klaster vSAN posiada więcej niż 16 nodów, parameter ten rośnie do 3,3GB
NumDiskGroups: liczba grup dyskowych na hoście, może osiągnąć wartości od 1 do 5.
DiskGroupBaseConsumption: stały rozmiar pamięci konsumowanej przez każdą z grup dyskowych hosta. Aktualnie wynosi on 500MB.
SSDMemOverheadPerGB: stała wartość pamięci zaaklokowana na każdy GB rozmiaru dysku cache. Obecnie wynosi 2MB dla modelu vSAN Hybrid i 7MB dla modelu vSAN All-Flash. Pamięć ta jest używana do śledzenia bloków dysku SSD używanych podczas cache’owania operacji “zapisu” i “odczytu”.
SSDSize: rozmiar dysku SSD w GB.

W przypadku gdy host ma mniej pamięci RAM niż 32GB, stosujemy liniowe przeskalowanie wykorzystywanej pamięci, dlatego też powyższy wzór przemnażamy przez iloraz ( SystemMemory / 32 ).

Aby zrozumieć jak vSAN absorbuje pamięci operacyjną policzmy narzut w kilku przykładach:

Przykład 1:
Host ma 128GB pamięci RAM (czyli więcej niż 32GB), liczba hostów w klastrze jest większa niż 16, każdy host ma po 3 grupy dyskowe, rozmiar dysku SSD (cache) to 600GB, a konfiguracja vSAN to All-Flash:

(BaseConsumption +
(NumDiskGroups x
(DiskGroupBaseConsumption + (SSDMemOverheadPerGB x SSDSize))) =

(3,3GB + (3 x (500MB + (7MB x 600GB))))
= (3,3GB + (3 x (0,5GB + 4,2GB))
= (3,3GB + (3 x 4,7GB))
= 3,3GB + 14.1GB
= 17.4 GB

Przykład 2:
Host ma 16GB pamięci RAM (czyli mniej niż 32GB), liczba hostów w klastrze jest mniejsza niż 16, każdy host ma 1 grupę dyskową, rozmiar dysku SSD (cache) to 400GB, a konfiguracja vSAN to Hybrid:

(BaseConsumption +
(NumDiskGroups x
(DiskGroupBaseConsumption + (SSDMemOverheadPerGB x SSDSize))))
* ( SystemMemory / 32 ) =

(3GB + (1 x (500MB + (2MB x 400GB)))) * 0,5
= (3GB + (0,5GB + 0,8GB)) * 0,5
= (3GB + 1,3GB) * 0,5
= 4,3 GB * 0,5
= 2,15 GB

Dysk boot’ujący host:
VMware zaleca aby uruchamiać system VMware ESXi™ na potrzeby vSAN:

• z karty SD, pendrive’a USB albo dysku HDD w sytuacji gdy serwer ESXi posiada do 512GB pamięci RAM,
• z dedykowanego dysku HDD lub SSD w sytuacji gdy serwer ESXi posiada więcej niż 512GB pamięci RAM.

Rozmiar cache (SSD):
Przy projektowaniu pojemności dyskowej cache, zaleca się przeznaczenie na cache nie mniej niż 10% przestrzeni przewidzianej na pojemność wynikającą z zajętości dyskowej maszyn wirtualnych (VMDK), niezależnie od tego, którą politykę tolerancji na awarię będziemy używać. W prosty sposób opisuje to poniższy wzór:

gdzie:
NumberOfVMs: liczba wirtualnych maszyn
VMSpaceUsage: rozmiar dysku wirtualnej maszyny

Przykład 3:
Planujemy na vSAN umiejscowienie 1000 wirtualnch maszyn, każda z maszyn będzie posiadać wirtualny dysk w rozmiarze 40GB:

TotalFlashCapacityRequired = NumberOfVMs * VMSpaceUsage * 10% =

1000 * 40GB * 10%
= 40TB * 0,10
= 4TB

Podsumowując na przykład, w chwili gdy nasz klaster vSAN będize składał się 8 nodów, każdy node będzie potrzebował conajmniej 500MB.

Rozmiar przestrzeni pojemnościowej (RAW):
Surowa pojemność vSAN powinna zostać obliczana według poniższego wzoru:

gdzie:
Hst: liczba hostów w klasteze vSAN,
NumDskGrpPerHst: liczba grup dyskowych per host,
NumDskPerDskGrp: liczba dysków przestrzeni pojemnościowej per grupa dyskowa,
SzHDD: rozmiar dysku przestrzeni pojemnościowej.

Przykład 4:
Klaster vSAN składać się będzie z 8 hostów, w każdym z nich będzie po 5 grup dyskowych, każdą grupę dyskową bedzie tworzyło 7 dysków przestrzeni pojemnościowej i 1 dysk przestrzeni cache. Pojemność dysku przestrzeni pojemnościowej będzie miał rozmiar 4TB.

ClusterCapacity =
Hst x NumDskGrpPerHst x NumDskPerDskGrp x SzHDD =

8 * 5 * 7 * 4TB
= 1.120TB

Rozmiar przestrzeni pojemnościowej (USABLE):
Użyteczna przestrzeń pojemnościowa będzie ściśle zależna od sumarycznej pojemności dysków wirtulnych maszyn zlokalizowanych na vSAN oraz od zastosowanych polityk tolerancji klastra na awarie (hosta, kontrolera RAID, dysku/ów czy sieci). Dostępne polityki to NumberOfFailuresToTolerate (FTT) oparte na RAID1, RAID5 lub RAID6.
Użyteczną przestrzeń pojemnościową wyliczamy ze wzoru:

gdzie:
ClusterCapacity: surowa przestrzeń pojemnościowa wyliczona wg. wzoru z wcześniejszego kroku,
VMs: liczba wirtualnych maszyn,
vmSwp: rozmiar wirtualnej pamięci alokowanej do maszyny (vRAM) *1)
fft: polityka ochrony danych na wypadek awarii, może przyjąć wartość od 1 do 3,
fftReplicas: liczba replik wynikająca z zastosowanej polityki FTT, zależna od rodzaju zabezpieczenia (RAID1: ftt=1 to fttReplicas=2, ftt=2 to fttReplicas=3, ftt=3 to fttReplicas=4, RAID5: ftt=1 i fttReplicas=0,33, RAID6: ftt=2 i fttReplicas=0,5)
DskGrp: liczba grup dyskowych per host,
DskPerDskGrp: liczba dysków przestrzeni pojemnościowej per grupa dyskowa,
Hst: liczba hostów w klastrze vSAN,
VSANoverhead: to stały narzut vSAN na obsługę komponentów i metadanych VMFS per dysk, równy 1GB.

*1) – jeśli maszyna wirtualna posiadać będzie rezerwacje vRAM w fizycznej pamięci operacyjnej hosta, wtedy parameter vmSwp musi zostać pomniejszony o wartość tej rezerwacji

Przykład 5:
Klaster vSAN posiada surową pojemność równą 1,120TB, klaster będzie hostował 800 wirtualnych maszyn, każda maszyna posiadać będzie plik wymiany Swap o rozmiarze 10GB. Klaster będzie chronił dostępność danych wirtualnych maszyn zgodnie z polityką RAID1:FTT=1 (odporność na 1 awarię) w związku z tym dla każdej maszyny zostaną stworzone po 2 repliki.
Każdy z 8 hostów biorących udział w budowaniu przestrzeni vSAN będzie miał 5 grup dyskowych oraz w każdej z nich po 1 dysku cache oraz 7 dysków przestrzeni pojemnościowej. Narzut na VSAN jest równy 1GB.

UsableCapacity =
((ClusterCapacity – VMs x vmSwap x fftReplicas) – DskGrp x DskPerDskGrp x Hst x VSANoverhead )/(ftt+1) =

((1.120.000GB – 800 x 10 x 2) – 280GB)/(1+1)
= 1.103.720GB/2
= 551.860GB

Przykład 6:
Klaster vSAN posiada surową pojemność równą 1,120TB, klaster będzie hostował 800 wirtualnych maszyn, każda maszyna posiadać będzie plik wymiany Swap o rozmiarze 10GB. Klaster będzie chronił dostępność danych wirtualnych maszyn zgodnie z polityką RAID5:FTT=1 (odporność na 1 awarię) przechowując pojedyńczą parzystość w czteroczęściowym rozproszonym pasku (podstawiamy tutaj: fftReplicas=1,33 i fft=0,33). Każdy z 8 hostów biorących udział w budowaniu przestrzeni vSAN będzie miał 5 grup dyskowych oraz w każdej z nich po 1 dysku cache oraz 7 dysków przestrzeni pojemnościowej. Narzut na VSAN jest równy 1GB.

UsableCapacity =
((ClusterCapacity – VMs x vmSwap x fftReplicas) – DskGrp x DskPerDskGrp x Hst x VSANoverhead )/(ftt+1) =

((1,120,000GB – 800 x 10 x 1,33) – 280GB)/(0,33+1)
= 1.109.080GB/1,33
= 833.895GB

Zweryfikujmy oszczędność przestrzeni, RAID5:FTT1 który wymaga x1,33 zajętości względem RAID1:FTT1 który posiada potrzebę x2 zajętości – czyli 66% różnicy na korzyść RAID5.

Przykład 7:
Ten sam przykład co powyższy (Przykład 6) z tą różnicą, że klaster będzie chronił dostępność danych wirtualnych maszyn zgodnie z polityką RAID6:FTT=2 (odporność na 2 awarie) przechowując podwójną parzystość w sześcioczęściowym rozproszonym pasku (podstawiamy tutaj:

fftReplicas=1,50 i fft=0,50)
UsableCapacity =
((ClusterCapacity – VMs x vmSwap x fftReplicas) – DskGrp x DskPerDskGrp x Hst x VSANoverhead )/(ftt+1) =

((1,120,000GB – 800 x 10 x 1,50) – 280GB)/(0,5+1)
= 1.108.000GB/1,5
= 738.480GB

Zweryfikujmy oszczędność przestrzeni, RAID5:FTT2 wymaga x1,5 zajętości względem RAID1:FTT2 który posiada potrzebę x3 zajętości – czyli to 100% różnicy na korzyść RAID6.

Drugą metodą oszacowania rozmiaru cache (tzw. active working set) oraz rozmiaru przestrzeni pojemnościowej, jak dla mnie dokładniejszą ponieważ odwzorowującą potrzeby naszego aktualnego środowiska VMwara, jest skorzystanie z narzędzia vSAN Assessment Tool.

Obiekty i Komponenty
Na koniec warto zwrócić uwagę na jeszcze jeden ważny element o którym często zapominamy, mam tu na myśli maksymalną konfiguracja obiektów i ich komponentów, Obiektami w vSAN są: katalog domowy wirtualnej maszyny i jego pliki, plik wymiany Swap, wirtualny dysk VMDK oraz Snapshoty. Komponentami natomiast są repliki obiektów, ich witness czy pasek (stripe). Np: dysk VMDK chroniony FTT=1 posiada dwa komponenty dyskowe i jednego “witness” rozlokowane na różnych hostach. VMware vSAN 6.5 Configuration Maximums definiuje parametery które warto wziąć pod uwagę przy projektowaniu:
“Components per vSAN host” = 9000,
“Maximum size of a component” = 255,
“Disk stripes per object” = 12.

—————————————

Chcesz zobaczyć inne posty Przemysława Tomaszewskiego na temat VMware vSAN? Kliknij tu >

Kategoria: SDDC

Tagi: Przemyslaw Tomaszewski, SDDC, vSAN