VXRAIL (vSAN) – Analiza wydajności IOPS w zależności od dysków, grup oraz polityk

Dzięki uprzejmości DellEMC Polska mieliśmy możliwość przeprowadzenia testu wydajności systemu dyskowego w zależności od ilości dysków oraz grup dyskowych co jest często istotnym pytaniem przy konfiguracji zestawów VxRail. Dodatkowo porównaliśmy wydajność w zależności od polityk przechowywania danych – które są mocno upraszczając są odpowiednikiem znanych RAID0/1/5

Konfiguracja środowiska testowego

 

środowisko składa się z 4-ech węzłów VxRail, typu P, gdzie konfiguracja pojedynczego węzła była następująca:

• 2 x Intel Xeon 6134 8c @3.2Ghz
• 384 GB RAM
• 2 disk groups, each (1 x 1,7 TB SATA capacity SSD, 1 x 400 GB SAS cache SSD)
• 2 x 10G Ethernet (VM and vSAN traffic)
• 1 x 1G Ethernet (management traffic)

 

wersje oprogramowania użytego do testów:

Tabela wersji vSAN dla danej wersji esxi: https://kb.vmware.com/s/article/2150753

PLAN TESTÓW

Zaplanowane testy zakładają sprawdzenie wydajności podsystemu rozproszonego systemu Storage (vSAN) z wykorzystaniem narzędzia HCI Bench (labs.vmware.com/flings/hcibench). Jest to dedykowane narzędzie Vmware, które ułatwia automatyzację testów w klastrze HCI. HCI bench ma na celu uproszczenie i przyspieszenie testów wydajności na potrzeby testów POC i POP  w spójny i kontrolowany sposób. Narzędzie w pełni automatyzuje kompleksowy proces wdrażania maszyn wirtualnych, koordynowania przebiegu pracy, agregacji wyników testów i zbierania danych niezbędnych do rozwiązywania problemów.

HCIBench jest nie tylko narzędziem benchmarkingowym zaprojektowanym dla vSAN, ale może być również używany do oceny wydajności wszystkich rodzajów pamięci masowych Hyper-Converged Infrastructure Storage w środowisku vSphere.

Plan testów zakładał testy porównawcze dla stałej floty maszyn wirtualnych o następującej charakterystyce:

Parametr	Wartość	uwagi
Ilość hostów	4
Ilość maszyn wirtualnych	32	włączony mechanizm DRS
Ilość dysków dla każdej VM	8	nie licząc dysku systemowego
Rozmiar pojedynczego dysku	10 GB	Dyski typu Thin

 

Konfiguracja obciążenia:

Parametr	Wartość
Wielkość bloku	4K
Stosunek odczyt/zapis	70/30
Czas trwania każdego testu	10 minut
Ilość wątków na każdy dysk wirtualny	2
Working-Set	10%

Podsumowanie charakteryski obciążenie: vdb-8vmdk-10ws-4k-70rdpct-30randompct-2threads

Realizowane testy:

Testy zostały podzielone na 3 grupy

1. Wydajności pomiędzy dwoma grupami dyskowymi a jedną grupą dyskową
2. Rożnicę wydajności pomiędzy konfiguracją Stripe 1/2
3. Wydajności pomiędzy polityką RAid0/ Raid11/RAid5
4. Spadku wydajności po włączeniu kompresji i deduplikacji

Test 1 – zależność ilości dysków i grup dyskowych

Konfiguracja 1 – dwie grupy dyskowe w każdej grupie jeden dysk SSD SAS 400Gb Cache + 1 dysk SSD SATA 1,75TB

Wydajność obserwowana przez VxRail Managera

Konfiguracja 2 – jedna grupa dyskowa w każdej grupie jeden dysk SSD SAS 400Gb Cache + 1 dysk SSD SATA 1,75TB

Grupy dyskowe:

Dyski w każdej grupie:

Wydajność obserwowana przez VxRail Managera

Konfiguracja 3 – jedna grupa dyskowa w każdej grupie jeden dysk SSD SAS 400Gb Cache + dwa dyski danych  SSD SATA 1,75TB

Grupy dyskowe:

Dyski w każdej grupie:

Wydajność obserwowana przez VxRail Managera

Wyniki sumarycznie

 

Descripe	IOPS	Throughput	Latency	Read Latency	Write Latency	Latency Standard Deviation	Total Outstanding IO	Physical CPU Usage	Physical Memory Usage	vSAN CPU Usage
2 grupy dyskowe	197512,3	771,53	2,6958	2,4891	3,1769	557,69	204,688	65.46%	25.67%	25.36%
1 grupa z jednym dyskiem	73475,1	287,01	9,1686	6,9976	14,1928	265,21	368,054	32.41%	23.18%	10.0%
1 grupa z dwoma dyskami	76646,7	299,41	8,936	6,4656	14,6595	276,38	371,457	32.84%	23.5%	10.15%

Wnioski

Wyniki dość jasno wykazują, że zwiększenie ilości grup dyskowych zwielokrotniają wydajność całego podsystemu pamięci masowej. Nieduży przyrost z kolei daje nam dokładanie kolejnych dysków ramach tej same j grupy dyskowej (około 5%) co pokazuje, że według architektów vSANu jest to działanie mającena celu powiększanie przestrzeni nie wydajności.

 

Test 2 – różnice wydajności dla polityki Stripe 1/2

Celem testu jest obserwacja różnicy w wydajności i obciążeniu systemu przy polityce Stripe=1 oraz Stripe=2.  O ile przyjęcie polityki stripe=2 może zwiększyć liczbę IOPS dla pojedynczego obciążenia to spójrzmy jak sumarycznie klaster zachowa się w przypadku gdy wiele maszyn będzie intensywnie pisało/czytało w jednym czasie.  W tym przypadku nadal 32 maszyny, każda z maszyn posiadająca 8 dysków wirtualnych i piszaca jednocześnie dwoma wątkami na każdym dysku.

Na potrzeby tego testu przyjęliśmy jedną konfigurację posiadającą węzły z jedną dwu-dyskową grupą dyskową  (analogicznie do 2 konfiguracji z pierwszego testu)

Policy	IOPS	Throughput	Latency	Read Latency	Write Latency	Latency Standard Deviation	Total Outstanding IO	Physical CPU Usage	Physical Memory Usage	vSAN CPU Usage
Stripe=1	46129,5	180,2	11,2668	7,3767	20,2729	340,07	447,65	24.98%	23.75%	6.91%
Stripe=2	36728,3	143,49	15,2444	4,8675	39,2475	882,76	851,294	29.75%	23.75%	9.59%

Wnioski

Wyniki wskazują na to, że wdrożenie polityki Stripe=2 w przypadku wielu róznoległych operacji IOPS zmniejsza wydajność całego systemu oraz jednocześnie zwiększa narzut vSANu na procesory. Zgodnie zresztą z zamysłem architektów polityka ta ma najistotniejsze znaczenie w przypadku dysków mechanicznych gdzie wydajność IO pojedynczego dysku jest bardzo ograniczona.

Test 3 – różnice wydajności w zależności od polityki

Konfiguracja Storage do testu (dwie grupy dyskowe w każdej grupie jeden dysk SSD SAS 400Gb Cache + 1 dysk SSD SATA 1,75TB)

 

Aby maksymalnie obciążyć testowany klaster zwiększono flotę maszyn wirtualnych generujących obciążenie dwukrotnie, czyli do 64 maszyn.  Reszta paramentów pozostała bez zmian.

Parametr	Wartość	uwagi
Ilość hostów	4
Ilość maszyn wirtualnych	64	włączony mechanizm DRS
Ilość dysków dla każdej VM	8	nie licząc dysku systemowego
Rozmiar pojedynczego dysku	10 GB	Dyski typu Thin

Konfiguracja 1 = Polityka (failures to tolerate =1) RAID 1

Konfiguracja 2 = Polityka (failures to tolerate =0) RAID 1

Konfiguracja 3 = Polityka (failures to tolerate =1) RAID 5/6

Wydajność obserwowana przez VxRail Managera dla konfiguracji 1

Wydajność obserwowana przez VxRail Managera dla konfiguracji 1 oraz 2

 

Czerwoną przerywaną linią zaznaczono charakterystyczne dla VxRAil managera przesunięcie w czasie odczytu obciążenia procesorów.  Wykresy aktualizowane są przez VxRail Managera co minutę, odczyty obciążenia procesowa opóźnione są o jeden odczyt w stosunku do Storage IOPS.

 

Wyniki i wnioski

Configuration	IOPS	Throughput	Latency	Read Latency	Write Latency	Latency Standard Deviation	Total Outstanding IO	Physical CPU Usage	Physical Memory Usage	vSAN CPU Usage
RAID1/ NumberOfTolerance=0	315083,7	1230,76	4,0433	4,0312	4,0717	832,94	479,253	81.23%	23.86%	31.9%
RAID1/ NumberOfTolerance=1	308508,4	1205,13	3,802	3,8823	3,615	343,61	399,205	83.56%	25.65%	34.26%
RAID5/ NumberOfTolerance=1	302161,1	1180,29	3,8559	4,0242	3,4644	333,25	404,589	84.83%	25.84%	35.16%

Konfiguracja polityki trzymania danych bez żadnej redundancji pozwoliła osiągnąć największą ilość IOPS (347.574 szczytowo, 315.083 wartość uśredniona). No co istotne – stosowanie polityki RAID5 w porównaniu do RAID1 z polityką tolerancji awarii jednego węzła  nie przynosi dużego narzutu obliczeniowego czy też zmniejszenia wydajności IOPS oraz opóźnień.  Różnica utrzymała się  na poziomie około 1%

 

TEST 4 – narzut obliczeniowy i zmniejszenie wydajności IOPS przy stosowaniu deduplikacji i kompresji danych

Oczywiście należy sobie zdawać sprawę, że test realizowany na danych losowych nie pokaże zysku z deduplikacji i kompresji, niemniej celem tego testu jest jedynie zaobserwowanie narzutu vSAN na obliczenia związane z procesem analizy bloków do deduplikacji cz też kompresją danych.

Przeprowadzono więc test porównawczy:

1. Konfiguracja 1 – bez kompresji i deduplkacji
2. Konfiguracja 2 – z włączona kompresją oraz dedupliakcją

Konfiguracja floty VDI Bench jest oczywiście jednakowa we wszystkich 3 konfiguracjach: 64 VMki, każda po 8 dysków na testy, kady dysk 10GB, charakterystyka obciążenia: vdb-8vmdk-10ws-4k-70rdpct-30randompct-2threads

Wyniki i wnioski

Configuration	IOPS	Throughput	Latency	Read Latency	Write Latency	Latency Standard Deviation	Total Outstanding IO	Physical CPU Usage	Physical Memory Usage	vSAN CPU Usage
Bez dedup. I kompresji	152308	594,93	9,0278	6,4617	14,9704	295,8	776,644	63.0%	26.0%	22.62%
Z dedup. I kompresją	122234,8	477,46	10,4328	5,8143	21,1162	365,06	992,79	57.2%	26.25%	19.95%