Ile rywalizacji jest za dużo w VMware?

Od jakiegoś czasu próbuję dowiedzieć się, dlaczego sporo naszych krytycznych systemów biznesowych otrzymuje raporty o „spowolnieniu”, od łagodnego do ekstremalnego. Niedawno zwróciłem uwagę na środowisko VMware, w którym hostowane są wszystkie omawiane serwery.

Niedawno pobrałem i zainstalowałem wersję próbną pakietu zarządzania Veeam VMware dla SCOM 2012, ale trudno mi jest uwierzyć (podobnie jak mój szef) w liczby, które mi przekazuje. Aby przekonać mojego szefa, że ​​podane mi liczby są prawdziwe, zacząłem szukać samego klienta VMware w celu zweryfikowania wyników.

Przejrzałem ten artykuł KB VMware ; specjalnie dla definicji Co-Stop, która jest zdefiniowana jako:

Czas, przez który maszyna wirtualna MP była gotowa do uruchomienia, ale spowodowała opóźnienie z powodu niezgodności harmonogramu co-vCPU

Które tłumaczę

System operacyjny gościa potrzebuje czasu od hosta, ale musi czekać na dostępność zasobów, dlatego może zostać uznany za „niereagujący”

Czy to tłumaczenie wydaje się poprawne?

Jeśli tak, to tutaj trudno mi uwierzyć w to, co widzę: host, który zawiera większość maszyn wirtualnych, które są „wolne”, obecnie pokazuje średnią zatrzymania CPU wynoszącą 127 835.94 milisekund!

Czy to oznacza, że ​​średnio maszyny wirtualne na tym hoście muszą czekać ponad 2 minuty na czas procesora?

Ten host ma dwa 4-rdzeniowe procesory i ma gościa z procesorem 1x8 i gościa z procesorem 14x4.

Mogę opisać niektóre doświadczenia, które miałem w tej dziedzinie ...

Nie sądzę, aby VMware w odpowiedni sposób informował klientów ( lub administratorów ) o najlepszych praktykach, ani nie aktualizował wcześniejszych dobrych praktyk w miarę ewolucji ich produktów. To pytanie jest przykładem tego, jak podstawowa koncepcja, taka jak alokacja vCPU, nie jest w pełni zrozumiała. Najlepszym rozwiązaniem jest rozpoczęcie od małej, z pojedynczym vCPU, aż do ustalenia, że ​​maszyna wirtualna wymaga więcej.

W przypadku OP serwer hosta ESXi ma dwa czterordzeniowe procesory, co daje 8 rdzeni fizycznych.

Opisany układ maszyny wirtualnej to 15 gości; 1 x 8 vCPU i 14 x 4 vCPU. To zdecydowanie zbyt duże zaangażowanie, szczególnie w przypadku istnienia jednego gościa z 8 procesorami vCPU . To nie ma sensu. Jeśli potrzebujesz maszyny wirtualnej tak dużej, prawdopodobnie potrzebujesz większego serwera.

Spróbuj odpowiednio dobrać swoje maszyny wirtualne. Jestem pewien, że większość z nich może żyć z 2 vCPU. Dodanie wirtualnych procesorów nie przyspiesza działania, więc jeśli jest to rozwiązanie problemu z wydajnością, jest to niewłaściwe podejście.

W większości środowisk pamięć RAM jest najbardziej ograniczonym zasobem. Ale procesor może stanowić problem, jeśli występuje zbyt duża rywalizacja. Masz na to dowód. Pamięć RAM może również stanowić problem, jeśli za dużo maszyn wirtualnych zostanie przydzielonych .

Można to monitorować. Metryka, której szukasz, to „% gotowości procesora”. Możesz uzyskać dostęp do tego od klienta vSphere wybierając VM i przechodząc do Performance> Overview> CPU wykresie.

• Poniżej 5% Gotowy na procesor - Wszystko w porządku.
• 5-10% Gotowy na procesor - Obserwuj uważnie aktywność.
• Ponad 10% Gotowy na procesor - niezbyt dobrze.

Zwróć uwagę na żółtą linię na poniższym wykresie.

Czy mógłbyś sprawdzić to na swoich problemach z maszynami wirtualnymi i zgłaszać z powrotem?

W komentarzach stwierdzasz, że masz dwurdzeniowy host ESXi i korzystasz z jednej maszyny wirtualnej 8vCPU i czternastu maszyn wirtualnych 4vCPU.

Gdyby takie było moje środowisko, uznałbym to za rażąco nadmiernie rezerwowane . Na tym sprzęcie umieściłbym co najwyżej czterech do sześciu gości 4vCPU. (Zakłada się, że dane maszyny wirtualne mają obciążenie, które wymaga, aby miały tak wysoką liczbę vCPU).

Zakładam, że nie znasz złotej zasady ... w VMware nigdy nie powinieneś przypisywać VM więcej rdzeni, niż potrzebuje. Powód? VMware stosuje nieco ścisłe współsprawianie, które utrudnia maszynom wirtualnym uzyskanie czasu procesora, chyba że dostępnych jest tyle rdzeni, ile przydzielono maszynie wirtualnej. Oznacza to, że maszyna wirtualna 4vCPU nie może wykonać 1 jednostki pracy, dopóki nie zostaną otwarte 4 fizyczne rdzenie w tym samym momencie. Innymi słowy, architektonicznie lepiej jest mieć maszynę wirtualną 1vCPU z obciążeniem procesora 90%, a następnie maszynę wirtualną 2vCPU z obciążeniem 45% na rdzeń.

Więc ... ZAWSZE twórz maszyny wirtualne z minimum vCPU i dodawaj je tylko wtedy, gdy jest to konieczne.

W tej sytuacji użyj Veeam do monitorowania zużycia procesora przez gości. Zmniejsz liczbę vCPU na jak największej liczbie. Byłbym skłonny założyć się, że możesz spaść do 2vCPU na prawie wszystkich swoich obecnych gości 4vCPU.

To prawda, że ​​jeśli wszystkie te maszyny wirtualne faktycznie obciążają procesor, aby wymagać liczby procesorów vCPU, to po prostu trzeba kupić dodatkowy sprzęt.

127 835.94 milisekund to suma i musisz podzielić czas próbkowania, aby uzyskać prawidłowe wartości% RDY. Wygląda jednak na to, że już teraz otrzymujesz prawidłowe odczyty% RDY. Możesz osiągnąć całkiem wysoki współczynnik vCPU do fizycznego procesora, ale nie tak, jak to robisz.

Masz o wiele za dużo wirtualnych maszyn wirtualnych vCPU, a nawet 8 maszyn wirtualnych vCPU. Istnieją już pewne odpowiedzi jakościowe omawiające dobór odpowiednich rozmiarów i pewne konsekwencje braku konsolidacji cykli do mniejszej liczby procesorów wirtualnych. Jedyne, co chciałem wyjaśnić, to fakt, że chociaż nie jest już tak, że maszyna wirtualna musi czekać na liczbę fizycznych procesorów równą liczbie procesorów vCPU, zanim będzie można przetworzyć dowolną instrukcję, jest to bardzo szkodliwe nadmiernej alokacji tej wielkości w stosunku do maszyn wirtualnych z wieloma procesorami vCPU do rdzeni fizycznych. 64 procesorów vCPU na 8 rdzeniach znacznie przekracza maksymalny stosunek 4 do 1. Zakładam, że masz HT na tych procesorach, więc masz 16 rdzeni logicznych? Może to być poprawne w przypadku 1 i 2 maszyn wirtualnych vCPU, które mają niewielkie obciążenie, ale jeśli masz duże obciążenie maszyn wirtualnych, byłoby to trudne.

Do Twojej wiadomości Procesory HT nie są używane w obliczeniach% wykorzystywanego procesora - co oznacza, że ​​jeśli na serwerze masz 32 rdzeń logiczny działający z częstotliwością 2,4 Ghz, to jesteś w 100% wykorzystywany, gdy osiągniesz 38,4 GHz. Dlatego gdy widzisz średnie obciążenia pokazujące więcej niż 1,0, właśnie dlatego.

Oto host ESXi, w którym działa współczynnik vCPU 3,5 do 1 procesora fizycznego (w tym rdzeni HT) ze średnim% RDY wynoszącym 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

Od tamtej pory zainstalowaliśmy Veeam ONE, który rzucił sporo światła na nasze problemy z wydajnością. Patrząc na ekran wąskich gardeł procesora w Veeam ONE, a następnie wykorzystując rozwiązywanie problemów z maszyną wirtualną, która przestała odpowiadać: porównanie użycia procesora VMM i gościa jako odniesienie doszliśmy do wniosku, gdzie jest miejsce na naszą „niedopuszczalną” rywalizację.

Jedną małą wskazówką, którą chciałem się szczególnie podzielić, jest to, że w jednym przypadku nie mogłem wyeliminować rywalizacji procesora, dopóki nie usunąłem migawki na maszynie wirtualnej. Mam nadzieję, że to komuś pomoże.