Co nowego VMware vSphere 5? – Wydajność

Zmiany, które zaszły pod względem wydajności w nowym vSphere 5 opisane są chyba najbardziej kwiecistym językiem, jaki można sobie wyobrazić. Dokument o tym traktujący jest oczywiście najobszerniejszy, najwięcej w nim wodotrysków, porównań, wykresów i wniosków. Oczywiście sporo się zmieniło na lepsze… po odciśnięciu tej marketingowej wody pozostają następujące suche fakty.

Klastrowanie i HA

Zwiększono zdecydowanie ilość tak zwanych operacji zarządzania na sekundę – o 120%. Przykładem operacji na sekundę może być włączanie i wyłączanie maszyn wirtualnych, vmotion, stworzenie resource poola, dodanie folderu itp. Dzięki temu zaistniała możliwość uruchomienia zdecydowanie większej ilości maszyn wirtualnych w klastrze, oraz zmniejszenia czasu wykonywanie różnych operacji zarządzania do 75% (zależnie od tego, co w związku nimi jest wykonywane w tle). Od wersji vSphere 5 będzie można uruchomić klaster 32 hypervisorów z 3200 maszyn wirtualnych w nim pracujących. Zwiększanie ilości operacji na sekundę znacząco ma przyśpieszyć działania klastra HA. Zarówno jego koniuracji, oraz czasu odzyskania sprawności po awarii któregokolwiek z węzłów. Dane przedstawione w dokumencie mówią o tym, że konfiguracja nowego klastra będzie szybsza dziewięciokrotnie a uruchamianie maszyn wirtualnych po awarii węzła przyspieszy o 14%. Trudno się jeszcze ustosunkować do podanych danych… Obietnice są obiecujące, jednak nauczony doświadczeniem myślę, że te procenty należy traktować z podobnym dystansem jak średnie spalanie samochodu w katalogach…

vCPU i vRAM

Sprawa wirtualnych procesorów i wirtualnego ramu jest przyjemnie prosta… Będzie można więcej! 😉 Nowe vSphere 5 pozwoli nam na ustawienie do 32 vCPU i 1TB vRAM dla maszyny wirtualnej. Według informacji które podaje VMware utylizacja vCPU będzie w znacznym stopniu zbliżona do fizycznego procesora, ma oscylować w okolicach 92–97%. Dodatkowo wprowadzono bardziej wydajną obsługę architektury Intel SMT, oraz vNUMA. Nowe vSphere 5 zostanie wyposażone w technologię SSD Swap Cache dzięki której będzie można umieszczać swapy dla maszyn wirtualnych na dyskach SSD.

Storage & Network I/O Control

Rozwiązanie to jest swoistym QoS’em zarówno dla sieci normalnych jak i sieci stroage. Dzięki niemu można będzie swobodnie ustalać, która maszyny wirtualna jest VIP’em i jaki ma mieć priorytet w dostępnie do sieci LAN lub SAN. Sieci LAN, tak jak już wspomniałem w jednym z poprzednich artykułów, będą miały możliwość definiowania pól zasobów i priorytetowania ruchu zarówno ze względu na maszynę wirtualną jak również na typ ruchu. Sprawa podobnie ma wyglądać z sieciami SAN z wyjątkiem typu ruchu, będzie można priorytetować tylko ze względu na maszynę wirtualną. Schemat poniżej:

vMotion & Storage vMotion

Największym udoskonaleniem w vMotion jest możliwość definiowania go na kilku interfejsach sieciowych na raz. Mechanizm został tak zgrabnie skrojony, że VMkernel wykonuje load-balancing zupełnie przezroczyście i dzięki temu możemy przerzucać maszyny z jednego hosta fizycznego na drugi znacznie szybciej. Poniżej porównanie czasu przerzucania maszyn wirtualnych z zainstalowanym w środku SQL serwerem. Pierwsza VM została wyposażona w 4 vCPU, 16GB RAM oraz posiada zainstalowany SQL Serwer z jedną instancją, która jest obciążona testem OLTP. Druga maszyna wirtualna konfigurację sprzętową ma analogiczną do pierwszej, ale posiada zainstalowany SQL Serwer z wieloma instancjami, które również obciążane są testem OLTP.

  1. vSphere 4.1: Host fizyczny z jednym interfejsem 10GbE dla vMotion
  2. vSphere 5.0: Host fizyczny z jednym interfejsem 10GbE dla vMotion
  3. vSphere 5.0: Host fizyczny z dwoma interfejsami 10GbE dla vMotion

Wykres jasno pokazuje usprawnienia wprowadzone w vMotion w celu migracji maszyn wirtualnych z jednego hosta fizycznego na drugi. Warto zwrócić uwagę, że jest zarówno szybciej w przypadku jednej maszyny jak i dwóch. Kolejnym przyjemnym usprawnieniem jest Metro vMotion. Mechanizm ten jest ukłonem dla osób posiadających rozproszoną geograficznie infrastrukturę. Dzięki Metro vMotion będą mieli oni możliwość wykonywania vMotion między hostami po łaczach WAN… o ile opóźnienia nie przekroczą 5 milisekund.

Storage vMotion doczekało się również pewnej zmiany ideowej – na początku w wersji 3.5 korzystano z snapshotów aby wykonać Storage vMotion, w wersji 4.0 autorzy przeszli na koncepcję wykorzystującą „dirty block tracking” w wersji 5.0 postanowiono użyć technologii I/O Mirroring. Dzięki temu zwiększono szybkość wykonywania Storage vMotion oraz uniezależniono się od problemu migracji maszyn współdzielących wspólne zasoby dyskowe.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.

Leave a Reply