Wiedza Procesory fizyczne vs. maszyny wirtualne – granica wydajności!

[Silas Mariusz]

Procesory fizyczne vs. maszyny wirtualne
– granica wydajności!

Autor: Silas, Mariusz
Date: 18.12.2017

Słownik pojęć

• Host – master serwer hostujący maszyny wirtualne – QNAP NAS
• Hypervisor – nadzorca, oprogramowanie prowadzące proces wirtualizacji
• VM/Gość: maszyna wirtualna, gość nadzorcy Hypervisor w serwerze Host – w stacji wirtualizacji QNAP NAS
• pCPU – procesor fizyczny, rdzeń
• Procesor logiczny – procesor powstały w wyniku zwiększenia o 2 lub więcej rdzeni przez technologię Hyper-threading
• vCPU – procesor wirtualny przyporządkowany będący warstwą procesora logicznego, w nomenklaturze systemów wirtualizacji pojedynczy procesor logiczny zwany jest procesorem wirtualnym
• (top %wa) I/O wait – procentowo oszacowane oczekiwanie procesora na zasoby z magazynu wej./wyj.
• (top %st) CPU Steel Time – czas skradzionych cykli procesora przez hypervisora dla innych VM udzielając im zasoby procesora
• (top %id) Idle time – procentowo ilość wolnych zasobów procesora

Jeśli rozglądałeś się kiedykolwiek za hostingiem stron WWW, to na pewno spotkałeś się z ofertą serwerów wirtualnych VPS. Linia serwerów VPS zazwyczaj podzielona jest na kilka wariantów w zależnych od ilości vCPU (z reguły od 1 do 4 vCPU). Wydawałoby się, że serwer wirtualny z większą ilością vCPU będzie wydajniejszy i w teorii tak powinno być, jednak w praktyce już niekoniecznie. Świetnym przykładem jest tutaj największa firma hostingowa OVH, której praktyki overloadu są na porządku dziennym a liczba vCPU właściwie ma się nijak do wydajności. Na pozór serwery z większą ilością vCPU wydają się być szybsze, ale wystarczy odczekać kilka tygodni, aż host zostanie zapełniony sprzedanymi VPS’ami. Wykorzystanie CPU przez VM nie ulegnie zmianie, za to praca na VM stanie się mniej komfortowa, będzie można odczuć opóźnienia podczas wykonywanych operacji. Ze statystyk odczytamy wzrost Kernel I/O wait. Oczywiście I/O wait mógłby być przyczyną pracy lokalnego procesu lub sugerować uszkodzenie/overload HDD albo utrudnienie dostępu przez sieć do storage’u po iSCSI. Nie! Nie w przypadkach wirtualizacji! To nic innego jak kolejkowanie oczekujących nadmiernie tworzonych, zamykanych i synchronizowanych wątków vCPU z maszyn wirtualnych, które osiągnęły maksymalną wydajność zużywając dostępne na hoście wszystkie zasoby procesorów logicznych!

Dlaczego tak się dzieje? Na warsztat bierzemy dowolny serwer, czy to QNAP, czy maszyna VMware ESX, Citrix XenServer, Microsoft Hyper-V. Problem dotyczy wszystkich… Wyobraźcie sobie serwer QNAP z procesorami jak poniżej…

Serwer NAS, A: 1x procesor AMD, 6 rdzeni, hyper-threading po 2 wątki / rdzeń
Serwer NAS, B: 2x procesory Intel, każdy po 8 rdzeni, hyper-threading po 2 wątki / rdzeń

Jak wyliczyć dostępną ilość zasobów Hosta?

1. Liczbę dostępnych rdzeni zwanych fizycznymi procesorami (pCPU, Physical Processors) należy obliczyć od strony hosta w następujący sposób:
   pCPU = (CPU*Socket, łączna ilość procesorów) * (cores, średnia ilość rdzeni ze wszystkich procesorów)
   
   
2. Jeśli procesory w hoście korzystają z technologii HT (hyper-threading), to łączna liczba dostępnych procesorów logicznych wynosi:
   Procesory logiczne = (pCPU, ilość rdzeni fizycznych) * 2 wątki HT
   
   Na przykład:
   4 procesory * 6 rdzeni (w każdym procesorze) = 24 pCPU
   
   (hyper-threading):
   24 pCPU * 2 wątki HT = 48 procesorów logicznych (zwanych dalej vCPU)

ważna notka Należy pamiętać, że hyper-threading nie podwaja ilości dostępnych procesorów fizycznych. Hyper-threading umożliwia wyłącznie wykonanie kolejnego wątku w trakcie spoczynku lub podczas oczekiwania wykonywanej przez rdzeń operacji. Taki zabieg pozwala zwiększyć efektywność wykonywanych operacji optymalizując niepotrzebne czasy oczekiwania pomiędzy operacjami wielowątkowymi. W praktyce hyper-threading pozwala zwiększyć wydajność głównych rdzeni maksymalnie o 30% zależnie od napisanej aplikacji.

vCPU a wydajność

Serwer QNAP TS-877, procesor AMD, 6 rdzeni, hyper-threading.
W przykładzie poniżej utworzone zostały 2x VM i każdej z nich przypisano po 12 vCPU.

VM 1:

VM 2:

Host umożliwia utworzenie kilku maszyn wirtualnych i dla każdej z nich przypisać maksymalną dostępną ilość procesorów wirtualnych.

Procesor w serwerze QNAP TS-877 dysponuje 12 procesorami logicznymi a dla 2x VM utworzono łącznie 24 vCPU.

Scenariusz ten zakłada wykorzystanie zawsze 100% zasobów CPU pod warunkiem, że maksymalne obciążenie wykonuje tylko jedna maszyna wirtualna. W przypadku pracy dwóch maszyn wirtualnych na maksymalnym obciążeniu, hypervisor/host będzie kolejkował oczekujące wątki powstałe z nadmiaru vCPU i kolejno uruchamiał je na poszczególnych procesorach logicznych, kiedy te zostaną zwolnione. Niestety przeładowanie vCPU będzie skutkowało spadkiem wydajności i wykluczy możliwość uruchomienia usług typu mission-critical jak scentralizowanych baz danych, systemów cache i w najgorszym wypadku doprowadzić inne pozostałe operacje na hoście do opóźnionego działania.

należy pamiętać

1. Procesory wirtualne (vCPU, Virtual Processors), to nadzorowane i uruchamiane według harmonogramu hypervisora wirtualne procesy będące odwzorowaniem 1:1 procesorów logicznych
   vCPU (Virtual Processors) = liczba wszystkich procesorów logicznych
   
   
2. vCPU ≠ procesory logiczne.
   1. Liczba vCPU w pojedynczym VM nie może być większa od liczby procesorów logicznych
   2. Łączna liczba vCPU w hoście może być wielokrotnością ilości VM

Przydzielanie vCPU dla maszyn wirtualnych w QNAP

Najlepsze praktyki

1. Zacznij od jednego vCPU dla pojedynczej maszyny i zwiększaj jeśli to konieczne.
   
   
2. Nie przypisuj większej liczby procesorów wirtualnych niż jest to wymagane przez gościa, ponieważ może to niepotrzebnie ograniczyć zasoby dla maszyn wirtualnych i zwiększyć czasy oczekiwanie na gotowość procesora CPU.
   
   
3. Nie jest zabronione używanie maksymalnej liczby vCPU dla każdej maszyny wirtualnej. Przydzielając wszystkie możliwe vCPU dla wszystkich VM, dajemy gwarancje na maksymalny dostęp do zasobów pCPU. Jednak maksymalna całkowita ilości vCPU dla wszystkich VM, którą może pomieścić host jest zależna od częstotliwości i procentu użycia zasobów CPU przez aplikacje uruchomione wewnątrz nich. Dla najlepszych rezultatów należy określić schemat opisany powszechnie stosowaną regułą:
   {przydzielonych vCPU}:{dostępnych pCPU}
   • Od 1:1 do 3:1 nie stanowi problemu
   • Od 3:1 do 5:1, może zacząć powodować obniżenie wydajności
   • Od 6:1 lub więcej często powoduje problem
   
   Powyższe reguły dotyczą przeciętnych VM, które wykonują wiele krótkich wątków w różnych odstępach czasowych np. hosting Web, serwer pocztowy itp.
   
   Do wyjątków należy stosować schematy z mieszanymi regułami różnych ilości vCPU na VM lub rozbijanie maszyn na poszczególne procesory logiczne. Takie praktyki są wyłącznie polecane dla ekspertów, którzy mają pewność i dokonały precyzyjnych pomiarów użycia CPU przez VM, ponieważ ich brak zaplanowania ograniczy VM z dysponowanych przez hosta możliwości pCPU.

Dla ekspertów
Precyzyjne przydzielanie zasobów CPU dla maszyn wirtualnych uruchomionych w QNAP

1. (top %us) – Wykorzystanie procesora CPU w VM
   Postępuj według zaleceń określonych w punkcie nr. 1 opisanych wyżej w najlepszych praktykach dot. przydzielania vCPU dla maszyn wirtualnych. Rozpocznij monitorowanie wykorzystanie procesora przez maszynę wirtualną, aby określić, czy wymagane są dla niej dodatkowe jednostki vCPU lub czy jest ich nadmiar. Wykorzystanie procesora może być mierzone od strony hosta QNAP, jednak najlepsze efekty zostaną uzyskane monitorując VM od środka systemu operacyjnego. Wykorzystanie CPU w VM powinno na ogół wynosić średnio <= 80%, natomiast przekroczenie poziomu >90% należy potraktować jako ostrzeżenie wyczerpania dostępnych zasobów CPU w VM sugerując zwiększenie ilości vCPU dla wydajniejszej pracy VM.
   
   
2. (top %wa) – Wskaźnik CPU I/O wait
   Jeśli I/O wait jest wysoki, to oznacza, że procesor jest w gotowości do pracy, jednak jest w oczekiwaniu na ukończenie zadań I/O. Wzrost I/O wait jest sygnałem do diagnozy ale nie wskazuje jednoznacznie czy jego bezpośrednią przyczyną jest lokalny proces, np. gzip z dużą ilością bloków do zapisu/odczytu, czy czynnik zewnętrzny obciążający I/O przez inną VM, która ma większe priorytety i dysponuje większą ilością maksymalnie obciążonych vCPU. Dlatego warto zaczynać od przydzielania po 1vCPU per VM i zwiększać w celu osiągnięcia najlepszej wydajności.
   
   
3. (top %st) – CPU Steal time
   Wskaźnik, którego nie powinieneś monitorować i służy wyłącznie dla celów obliczeniowych i planowania. Jeśli postępujesz zgodnie z instrukcjami i zaczynasz od przydzielania po 1 vCPU dla maszyny wirtualnej, to nie powinieneś zobaczyć wzrostu tego parametru, aż do momentu overloadu vCPU i ich maksymalnym użyciem wobec pCPU. Wskaźnik Steal time zaczyna być widoczny dopiero, kiedy vCPU we wszystkich VM obciąży maksymalnie wszystkie procesory logiczne, a gość pomimo ich nadmiernego przydziału jest kolejkowany. To zazwyczaj oznacza, że hypervisor przydziela podany % pCPU pozostałym vCPU pracujących w innych VM.
   
   
4. (top %id) – Idle time
   Idle time to najbardziej klarowny i trudny do analizy parametr. Niska wartość %id wskazuje na brak przestrzeni w procesorze na wykonanie kolejnych zadań płynnie, np. kolejkowanie zadań z nadmiernych vCPU przez Hypervisor. Wartość >90% oznacza spoczynek i czas oczekiwania w gotowości na kolejne zadanie. Mimo wszystko spadek do 0% należy traktować krytycznie jako brak zasobów dla operacji VM. Może być on spowodowany operacjami innych VM, a może być też spowodowany zbyt małym przydzieleniem vCPU lokalnemu VM. Dlatego po raz kolejny proponuje się przydzielania po 1vCPU dla każdej VM i zwiększanie do momentu osiągnięcia najlepszych rezultatów.
   
   
5. Wykorzystanie procesora na hoście maszyn wirtualnym – w serwerze QNAP
   Monitoruj wykorzystanie procesora w serwerze QNAP, aby określić czy dostępne zasoby procesora/ów fizycznych nie zbliżają się do wartości krytycznych. Podobnie jak w przypadku obciążenia procesora w maszynach wirtualnych, poziom wykorzystania CPU 80-90% w hoście powinien traktowany być jako ostrzeżenie, gdzie wykorzystanie CPU >90% oznacza przeciążenie i może doprowadzić do niepoprawnej pracy całego hosta.

Wskazówki
Pomiar omawianych wyżej parametrów należy dokonywać na każdej VM osobno. W tym celu dla maszyn VM opartych o Linux idealnie sprawdzi się Monitorix.

Podsumowując

• Nadmierne przydzielenie vCPU pozwala osiągnąć lepsze efekty i wydajność utylizując w maksymalny sposób dostępną ilość pCPU, ale sprawdza się to wyłącznie dla VM, które wykonują krótkie zadania w różnych odstępach czasowych. Dlatego nie zapominaj monitorować wykorzystania CPU, aby zapobiec długotrwałemu użyciu CPU >90%.
  
  
• Unikaj alokowania więcej niż wymaganych vCPU dla maszyn wirtualnych. Nadmiar vCPU pozornie obniży wykorzystanie CPU przez VM w narzędziach monitorujących CPU, ale zwiększy czasy oczekiwania na wykonanie kolejnych wątków skutkując dłuższym czasem realizacji całego zadania.

Wnioski i notatki

Ilość procesorów wirtualnych w VM

• Zawsze używaj tylko jednego rdzenia na jedną maszynę wirtualną. Nigdy nie przydzielaj więcej niż jeden vCPU na VM, chyba że aplikacja na VM tego wymaga.
  Dla przykładu: Symulatory sieciowe, programowe interfejsy sieciowe pracują najlepiej na jednym rdzeniu.
  
  
• Nigdy nie przydzielaj więcej vCPU dla VM niż dostępnych procesorów fizycznych, bo to nie możliwe

Maksymalna ilość maszyn wirtualnych w serwerze

• Serwery QNAP korzystają ze sprzętowej akceleracji wirtualizacji dla zapewnienia najlepszej wydajności maszyn wirtualnych. Jednak to rozwiązanie ma ograniczoną ilość możliwych do uruchomienia VM korzystających z tą akceleracją. Po przekroczeniu tego limitu, każda kolejna maszyna wirtualna, będzie emulowana programowa przez QEMU, co jest znacznie wolniejsze niż KVM ze sprzętowym wsparciem dla wirtualizacji.
  Dla przykładu: Jeśli procesor w serwerze QNAP posiada 6 rdzeni i Hyper-threading dając łącznie 12 logicznych procesorów, to ilość maszyn wirtualnych korzystających ze sprzętowej akceleracji nie może przekroczyć 6 maszyn wirtualnych i w każdej po 2 vCPU.

Limity pamięci RAM

• Przyjęło się praktykę przydzielenia dla wszystkich maszyn wirtualnych 150% całkowitej dostępnej pamięci RAM w hoście uwzględniając średnio-wysokie użycie pamięci RAM przez host. Dla przykładu, jeśli w serwerze QNAP dostępne jest 8GB RAM, każdej z 10 maszyn wirtualnych można przydzielić po 1GB RAM nie przekraczając łącznie 10GB RAM dla wszystkich VM i pozostawiając bufor dla hosta i usług w serwerze QNAP 2GB RAM (10GB VM + 2GB HOST = 150% z 8GB fizycznej pamięci RAM w hoście). Jednak należy pamiętać, że jeżeli maszyny wirtualne alokują całą dostępną dla nich przestrzeń pamięci, to wydajność maszyn wirtualnych dramatycznie spadanie a na dodatkową przestrzeń będzie pracować SWAP. W takim przypadku wydajność może spaść nawet o 300-500%
• (Oprogramowanie NAS nie pozwala przekroczyć więcej pamięci RAM niż to możliwe. Dobra praktyka.)