VxRail – Skalowalność

Po przetestowaniu odporności systemu na awarie, przyjrzymy się jak reaguje środowiska na zwiększające się obciążenie operacjami dyskowymi.W ramach przygotowań do kolejnych testów poszukiwany jest sposób na wygodne zebranie informacji o generowanych obciążeniach w środowisku. W konsoli Web Client dostępne są informacje o wydajności które wydają się być tym co jest potrzebne. W szczególności prezentacja zbiorczego obciążenia w całym klastrze.

Rysunek 1 Rozwiązanie vSAN udostępnia wykresy obciążenia klastra, zarówno od strony maszyn wirtualnych jak i systemu wewnętrznego.

Niestety po bliższym zapoznaniu się z tym modułem, ujawnia się jego ogromna ułomność – dane są próbkowane co pięć minut i nie ma możliwości tego zmiany. Przy tak rzadkim próbkowanie nie ma możliwości rzetelnego zabrania informacji z aktualnego obciążenia środowiska – jest to tylko poglądowy widok nie pozwalający na monitorowanie środowiska w trybie rzeczywistym. Łatwo sobie wyobrazić sytuację gdy chcemy zobaczyć reakcję środowiska na ostatnią zmianę, a pięć minut oczekiwania nie jest akceptowalnym czasem.

Innym sposobem zmonitorowania środowiska jest vSAN Observer – wbudowane w vCenter rozwiązanie. Rozwiązaniu temu daleko do ideału, wymaga ręcznego uruchomienia, trudno zbierać dane za dłuższe okresy czasu, czy porównać przebiegi za ostatni dzień czy tydzień. Pomimo swoich wad rozwiązanie nie wymaga instalacji dodatkowych komponentów i zupełnie wystarczy do monitorowania bieżących obciążeń. Observer dostarcza bardzo dużo danych, wręcz za dużo jak na potrzeby testu, jednocześnie brak mu widoku prezentującego sumaryczne obciążenie całego klastra.

Rysunek 2 Widok z vSAN observer, rozwiązanie dostarcza bardzo dużo danych do szczegółowego monitorowania, brakuje jednak widoku zbiorczego do szybkiego rozeznania się w stanie środowiska

Na potrzeby testu przygotowano maszynę wirtualną, która sklonowano trzykrotnie. Maszyny te będą służyć do generowania obciążenia na klastrze, maszyny rozłożono pomiędzy węzłami, niestety o rozmieszczeniu plików w klastrze rozwiązanie decyduje samodzielnie. W wyniku automatycznego rozmieszczenia jedna z kopii każdej maszyny wylądowała na hoście ESXi node01. Druga kopia danych dwóch maszyn znalazła się na node02, natomiast node03 i node04 przechowywały po jednej kopii plików dwóch maszyn. Na tym etapie już wiadomo, że node01 będzie najbardziej obciążony i być może będzie stanowić wąskie gardło.

Rysunek 3 Widok rozmieszczenia drugiego dysku twardego maszyny Win2012-6 pomiędzy dyski węzłów klastra

W pierwszym teście uruchomiona zostaje generacja danych dla jednej maszyny wirtualnej. Proces ten trwał 55 minut, maksymalną prędkość zapisu uzyskano na poziomie 110MB/s przy 140IOPS. Zgodnie z domyślną polityką vSAN, maszyna zapisana jest w dwóch kopiach i generowała operacje zapisu odczytu na dwóch węzłach klastra. W idealnej sytuacji druga taka sama maszyna wirtualne znajdowały by się na dwóch innych węzłach w klastrze. Obie maszyny z uruchomionym obciążeniem nie rywalizowałby by o zasoby i można domniemywać, że proces generacji danych zakończyłyby po takim samym czasie jak dla jednej maszyny. Niestety jak już wspomniano wszystkie maszyny mają wspólny węzeł, co niewątpliwie jest przyczyną dla którego generacja danych uruchomiana jednocześnie na obu maszynach trwała 80 minut, czyli 45% dłużej. Ten sam proces dla czterech maszyn trwał 140 minut, czyli 75% dłużej niż dla dwóch i 154% dłużej niż dla jednego obciążenia.

Rysunek 4 Szczegółowy wykres obciążenia generowanego przez jedną maszynę wirtualną na klastrze vSAN w narzędziu vSAN observer

Przyjrzyjmy się teraz obciążeniu procesorów hostów ESXi wynikających z obsługi klastra vSAN. Wprawdzie brakuje narzędzi, które szybko pokazały by takie wartości, jednak w trakcie trwania obciążenia czterema maszynami wirtualnymi zebrano średnie obciążenie procesorów wszystkich maszyn wirtualnych oraz samych hostów ESXi. Różnica między obciążeniem procesorów hostów a maszyn wirtualnych na nich się znajdujących jest obciążeniem hostów operacjami innymi niż maszyny wirtualne, czyli np. obciążenie generowane przez mechanizm vSAN. Cała różnica to około 7,5% mocy procesora hostów. Trudno się spodziewać, że cała ta moc jest wykorzystywana przez vSAN, lecz musi być to zdecydowana większość. Zakładając zatem, że sam vSAN w przeprowadzonym teście obciążył procesory hosta na poziomie około pięciu procent, możemy uznać wynik za bardzo dobry. Oznaczałoby to bowiem nieznaczne obciążenie systemu, przy sporych możliwościach jakie niesie ze sobą ta technologia.

VSAN daje spore możliwości w zakresie wykorzystania lokalnych dysków do utworzenia rozproszonego zasobu dyskowego, niestety szczególnie w wersji hybrydowej (z obrotowymi dyskami) nie daje wiele więcej. Brak jest tu takich funkcjonalności jak błyskawiczne klonowanie maszyn wirtualnych, czy wydajna replikacja maszyn wirtualnych do zdalnych lokalizacji. Samo monitorowanie środowiska także wymaga dopracowania. Wbudowanie w klienta vSphere monitorowanie ma zbyt rzadnie proóbkowanie aby dawało większą wartość. Wbudowany vSAN Observer jest narzędziem przygotowanym raczej do poszukiwania źródeł problemów w środowisku. Oczywiście są jeszcze inne możliwe rozwiązania które mogą posłużyć do monitorowania, wymagają one jednak dodatkowej instalacji i konfiguracji, a ich wskazania mogą być obarczone błędami. Brak dobrego natywnego rozwiązania utrudnia wykonanie obiektywnych pomiarów, które mogłyby posłużyć porównaniu z innymi rozwiązaniami.  Możemy zatem zakładać, że w kolejnych wydaniach takie udoskonalenia będą wprowadzone. Na pewno ogromną zaletą tego rozwiązanie jest łatwość wdrożenia, ścisła integracji z VMware oraz brak potrzeby wprowadzania rozwiązań innych producentów. Modułowość i wygoda jaką daje VxRail, znacznie skraca czas niezbędny na rozbudowę środowiska jak i minimalizuje liczbę elementów które mogą zaskoczyć podczas rozrostu środowiska, w szczególności gdy problem pojawiłby się na styku sprzętu i oprogramowania.