🥇Analiza wydajności VM w VMware vSphere. Część 3: Storage

Część 1. O CPU
Część 2. O pamięci

Dzisiaj omówimy metryki systemu dyskowego w vSphere. Problemy z pamięcią masową są najczęstszą przyczyną wolnej pracy maszyny wirtualnej. W przypadku CPU i RAM rozwiązywanie problemów kończy się na poziomie hypervisora, podczas gdy przy problemach z dyskiem może być konieczne zbadanie sieci przesyłowej i macierzy dyskowej.

Temat będę omawiać na przykładzie blokowego dostępu do macierzy dyskowej, chociaż w przypadku dostępu plikowego wskaźniki są z grubsza podobne.

Trochę teorii

Kiedy mówi się o wydajności systemu dyskowego maszyn wirtualnych, zazwyczaj zwraca się uwagę na trzy powiązane ze sobą parametry:

liczba operacji wejścia/wyjścia (Input/Output Operations Per Second, IOPS);
przepustowość (Throughput);
opóźnienie operacji wejścia/wyjścia (Latency).

Liczba IOPS jest zazwyczaj ważna dla obciążeń losowych: dostęp do bloków na dysku rozmieszczonych w różnych miejscach. Przykładem takich obciążeń mogą być bazy danych, aplikacje biznesowe (ERP, CRM) itp.

Przepustowość jest istotna w przypadku obciążeń sekwencyjnych: dostęp do bloków rozmieszczonych jeden za drugim. Na przykład, takie obciążenia mogą generować serwery plików (ale nie zawsze) oraz systemy monitorowania wideo.

Przepustowość jest związana z liczbą operacji wejścia/wyjścia w następujący sposób:

Throughput = IOPS * rozmiar bloku, gdzie rozmiar bloku to wielkość bloku.

Rozmiar bloku jest dość istotną cechą. Nowoczesne wersje ESXi przepuszczają bloki o rozmiarze do 32 767 KB. Jeśli blok jest jeszcze większy, dzieli się na kilka mniejszych. Nie wszystkie macierze dyskowe mogą efektywnie pracować z tak dużymi blokami, dlatego w Ustawieniach Zaawansowanych ESXi dostępny jest parametr DiskMaxIOSize. Dzięki niemu można zmniejszyć maksymalny rozmiar bloku przepuszczanego przez hypervisor (więcej tutaj). Zalecam skonsultowanie się z producentem macierzy dyskowej przed zmianą tego parametru lub przynajmniej przetestowanie zmian na stoisku laboratoryjnym.

Duży rozmiar bloku może negatywnie wpływać na wydajność macierzy dyskowej. Nawet jeśli liczba IOPS i przepustowość są względnie niskie, przy dużym rozmiarze bloku mogą występować wysokie opóźnienia. Dlatego zwracaj uwagę na ten parametr.

Opóźnienie – najciekawszy parametr wydajności. Opóźnienie operacji wejścia/wyjścia dla maszyny wirtualnej składa się z:

opóźnienia wewnątrz hypervisora (KAVG, Średnia Milisekunda Jadra / Odczyt);
opóźnienia, które wprowadza sieć przesyłania danych i macierze dyskowe (DAVG, Średnia Milisekunda Sterownika / Komenda).

Całkowita opóźnienie, widoczne w systemie operacyjnym gościa (GAVG, Średnia Milisekunda Gościa / Komenda), to suma KAVG i DAVG.

GAVG i DAVG są mierzone, a KAVG jest obliczane: GAVG–DAVG.

Źródło

Skupmy się bardziej na KAVG. Podczas normalnej pracy KAVG powinno dążyć do zera lub przynajmniej być znacznie mniejsze niż DAVG. Jedynym znanym mi przypadkiem, kiedy KAVG jest zasłużenie wysokie, jest ograniczenie według IOPS na dysku VM. W takim przypadku, przy próbie przekroczenia limitu, KAVG będzie rosło.

Najważniejszym składnikiem KAVG jest QAVG – czas oczekiwania na przetwarzanie wewnątrz hypervisora. Pozostałe składniki KAVG są zaniedbywalnie małe.

Kolejka w sterowniku adaptera dyskowego i kolejki do lun mają stały rozmiar. W przypadku obciążonych środowisk rozmiar ten warto zwiększyć. Tutaj opisano, jak zwiększyć kolejki w sterowniku adaptera (jednocześnie zwiększy się kolejka do lun). Ustawienie to działa, gdy z lunem współpracuje tylko jedna VM, co rzadko się zdarza. Jeśli na lunie działa kilka VM, konieczne jest również zwiększenie parametru Disk.SchedNumReqOutstanding (instrukcja tutaj). Zwiększając kolejkę, zmniejszasz QAVG i KAVG odpowiednio.

Jednak najpierw zapoznaj się z dokumentacją dostawcy HBA i przetestuj zmiany na stanowisku laboratoryjnym.

Rozmiar kolejki do luny może być wpływany przez włączenie mechanizmu SIOC (Storage I/O Control). Zapewnia on zrównoważony dostęp do luny ze strony wszystkich serwerów klastra poprzez dynamiczną zmianę kolejki do luny na serwerach. Oznacza to, że jeśli na którymś z hostów działa VM, która wymaga nieproporcjonalnie dużo wydajności (noisy neighbor VM), SIOC zmniejsza długość kolejki do luny na danym hoście (DQLEN). Więcej informacji tutaj.

Z KAVG się uporaliśmy, teraz trochę o DAVG. Tutaj wszystko jest proste: DAVG to opóźnienie, które wprowadza zewnętrzne środowisko (sieć przesyłania danych i macierze dyskowe). W każdej nowoczesnej, a także starszej macierzy dyskowej są własne liczniki wydajności. Aby analizować problemy z DAVG, warto na nie spojrzeć. Jeśli z strony ESXi i macierzy dyskowej wszystko jest w porządku, sprawdź sieć przesyłania danych.

Aby uniknąć problemów z wydajnością, wybierz odpowiednią politykę wyboru ścieżki (PSP) dla swojej macierzy dyskowej. Praktycznie wszystkie nowoczesne macierze dyskowe obsługują politykę PSP Round-Robin (z ALUA, Asymmetric Logical Unit Access, lub bez). Ta polityka pozwala na wykorzystanie wszystkich dostępnych ścieżek do macierzy. W przypadku ALUA używane są tylko ścieżki do kontrolera, który posiada LUN. Nie wszystkie macierze dyskowe na ESXi mają domyślne zasady, które ustalają politykę Round-Robin. Jeżeli dla twojej macierzy nie ma zasady, użyj wtyczki od producenta macierzy, która stworzy odpowiednią zasadę na wszystkich hostach klastra, lub stwórz zasadę samodzielnie. Szczegóły tutaj.

Część producentów macierzy dyskowych również zaleca zmianę liczby IOPS na ścieżkę z domyślnej wartości 1000 na 1. W naszej praktyce pozwoliło to „wycisnąć” więcej wydajności z macierzy dyskowej oraz znacznie skrócić czas potrzebny na failover w przypadku awarii lub aktualizacji kontrolerów. Skonsultuj się z rekomendacjami dostawcy, a jeśli nie ma przeciwwskazań, spróbuj zmienić ten parametr. Szczegóły tutaj.

Podstawowe wskaźniki wydajności podsystemu dyskowego maszyny wirtualnej

Wskaźniki wydajności podsystemu dyskowego w vCenter zostały zebrane w sekcjach Datastore, Disk, Virtual Disk:

W sekcji Datastore znajdują się metryki dotyczące magazynów dyskowych vSphere (datastore), na których znajdują się dyski VM. Tutaj znajdziesz standardowe wskaźniki dotyczące:

IOPS (średnia liczba operacji odczytu/zapisu na sekundę),
przepustowości (wskaźnik odczytu/zapisu),
opóźnień (opóźnienia przy odczycie/zapisie/najwyższe opóźnienia).

Z nazw wskaźników zasadniczo wszystko jest zrozumiałe. Ponownie zwracam uwagę, że statystyki te nie dotyczą konkretnej VM (lub dysku VM), ale są ogólne dla całego datastore. Moim zdaniem, tę statystykę wygodniej obserwować w ESXTOP, chociażby z tego powodu, że minimalny okres pomiaru wynosi tam 2 sekundy.

W sekcji Dysk znajdują się metryki dotyczące urządzeń blokowych używanych przez VM. Znajdziesz tu wskaźniki dotyczące IOPS w typie summation (liczba operacji wejścia/wyjścia w danym okresie pomiaru) oraz kilka wskaźników odnoszących się do dostępu blokowego (Commands aborted, Bus resets). Tę informację, moim zdaniem, również wygodniej obserwować w ESXTOP.

Sekcja Wirtualny dysk – jest to najważniejszy element, jeśli chodzi o wykrywanie problemów z wydajnością dysków w maszyny wirtualnej. Tutaj można zobaczyć wydajność dla każdego wirtualnego dysku. To informacje, które są potrzebne, aby zrozumieć, czy konkretna maszyna wirtualna ma problem. Oprócz standardowych wskaźników liczby operacji wejścia/wyjścia, objętości odczytu/zapisu oraz opóźnienia, w tej sekcji znajdują się użyteczne wskaźniki, które pokazują rozmiar bloku: rozmiar żądania odczytu/zapisu.

Na poniższym obrazku znajduje się wykres wydajności dysku maszyny wirtualnej, na którym można zobaczyć liczbę IOPS, opóźnienia i rozmiar bloku.

Można także zobaczyć metryki wydajności dla całego datastore, jeśli SIOC jest włączony. Tutaj znajduje się podstawowa informacja na temat średniego opóźnienia i IOPS. Domyślnie tę informację można zobaczyć tylko w trybie rzeczywistym.

ESXTOP

W ESXTOP znajduje się kilka ekranów, które przedstawiają informacje o systemie dyskowym hosta jako całości, dla poszczególnych maszyn wirtualnych i ich dysków.

Zacznijmy od informacji o maszynach wirtualnych. Ekran „Disk VM” wywołuje się klawiszem „v”:

NVDISK – liczba dysków maszyny wirtualnej. Aby zobaczyć informacje o każdym dysku, naciśnij „e” i wprowadź GID interesującej maszyny wirtualnej.

Wartości pozostałych parametrów na tym ekranie są zrozumiałe z ich nazw.

Jeszcze jednym przydatnym ekranem do rozwiązywania problemów jest ekran adaptera dysku. Wywołuje się klawiszem „d” (na poniższym obrazku wybrane są pola A, B, C, D, E, G):

NPTH – liczba ścieżek do lun widocznych z tego adaptera. Aby uzyskać informacje o każdej ścieżce na adapterze, naciśnij „e” i wprowadź nazwę adaptera:

AQLEN – maksymalny rozmiar kolejki na adapterze.

Na tym ekranie znajdują się również wskaźniki opóźnienia, o których wspominałem wcześniej: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

Na ekranie urządzenia dyskowego, który wywołuje się klawiszem „u”, przedstawione są informacje o poszczególnych urządzeniach blokowych – lunach (na poniższym obrazku wybrane są pola A, B, F, G, I). Można tutaj zobaczyć stan kolejki do lun.

DQLEN – rozmiar kolejki dla urządzenia blokowego.
ACTV – liczba operacji wejścia/wyjścia w jądrze ESXi.
QUED – liczba operacji wejścia/wyjścia w kolejce.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.

Jeśli %USD jest wysokie, warto rozważyć zwiększenie kolejki. Im więcej poleceń w kolejce, tym wyższe QAVG i, odpowiednio, KAVG.

Na ekranie urządzenia dyskowego można również sprawdzić, czy VAAI (vStorage API for Array Integration) działa na macierzach. Aby to zrobić, należy wybrać pola A i O.

Mechanizm VAAI pozwala przenieść część pracy z hypervisor bezpośrednio na macierz, na przykład zerowanie, kopiowanie bloków lub blokady.

Jak widać na powyższym obrazku, na tej macierzy VAAI działa: aktywnie wykorzystywane są prymitywy Zero i ATS.