Wydanie w połowie br. przez Microsoft Hyper-V zmieniło oblicze rynku hypervisorów, czyli hipernadzorców maszyn wirtualnych. W związku z wejściem na rynek nowego gracza zespół testujący amerykańskiego IDG zdecydował się poddać ocenie rozwiązania wirtualizacyjne w zakresie wydajności. Najważniejsze wnioski z porównania: Hyper-V wyróżnia się zestawem sterowników, które pomagają mu w obsłudze maszyn wirtualnych Linuksa. VMware zachowuje przewagę technologiczną i wyprzedza Hyper-V pod względem funkcjonalności.

Zaproszenie do testu przyjęły Microsoft i VMware. Dostawcy rozwiązań open source - Citrix (Xen) i Red Hat (hypervisor oparty na Linuksie) nie mogli uczestniczyć w testach - ich produkty znajdowały się dopiero na etapie wstępnych weryfikacji. W rezultacie na placu boju pozostały Microsoft Hyper-V i VMware ESX.

Odpowiedź na pytanie, który hypervisor jest szybszy, zależy od kilku czynników, w tym od tego: jak maszynom wirtualnym goszczącym systemy operacyjne są przydzielane dostęp do CPU i pamięć hosta. Znaczenie ma także wiele ograniczeń specyficznych dla produktów mogących wpływać na wydajność.

VMware ESX został ostatecznym zwycięzcą w konkurencji wydajności wirtualizacji - w rywalizacji ograniczonej do uruchamiania sześciu współbieżnych maszyn wirtualnych VM (Virtual Machines), co wynikało z dostępnych rdzeni procesorów i pojemności pamięci, a także ograniczeń testowanych hypervisorów. ESX zwyciężył w większości podstawowych testów - hostingu VM na wielu procesorach i wydajności dyskowych operacji we-wy.

Microsoft Hyper-V sprawił się dobrze w kilku przypadkach, gdy używano specjalnego zestawu sterowników dostarczonych przez Microsoft dla poprawienia wydajności jedynej oficjalnie obsługiwanej przez Hyper-V platformy Linux: Novell Suse Enterprise Linux.

Hypervisory VM zostały zaprojektowane do odwzorowywania zasobów sprzętowych serwera wielu goszczonym systemom operacyjnym. Fizyczna CPU (utożsamiana także z rdzeniem) jest udostępniana goszczonemu systemowi operacyjnemu jako wirtualna CPU (vCPU). Ale niekoniecznie istnieje tu powiązanie "jeden rdzeń - jedna vCPU". Dokładne przełożenie zależy od hypervisora. W testach pozwolono hipernadzorcy decydować, jak prezentować zasoby CPU jako vCPU.

System operacyjny widzi zasoby serwera w ramach ograniczeń narzucanych przez hypervisora. Na przykład: system z czterordzeniowym CPU może być reprezentowany jako pojedyncza jednostka CPU dla systemu operacyjnego. W innych wypadkach cztery CPU mogą być prezentowane jako osiem vCPU - w scenariuszu, w którym "spokojniejsze" VM prawdopodobnie nie będą zbyt często wykorzystywać zasobów CPU. Na VM mogą być narzucane również inne ograniczenia, odnoszące się np. do rozmiarów dysku, we-wy sieci, a nawet tego, który gość zamierza używać pojedynczego CD/DVD w ramach serwera.

Jednym z frustrujących ograniczeń narzucanych zarówno przez Hyper-V, jak i ESX, jest to, że liczba vCPU, która może być użytkowana przez pojedynczą VM, jest ograniczona do czterech (bez względu na typ czy wersję instancji goszczonego systemu operacyjnego) lub tego, jak wiele fizycznych rdzeni może być w rzeczywistości dostępnych. Co więcej, jeżeli wybierze się pracę 32-bitowej wersji SLES 10 w roli systemu-gościa, to okaże się, że Microsoft pozwala mu tylko na pojedynczą vCPU.

Ograniczenia wprowadzane przez dostawców hypervisorów w zakresie liczby dostępnych vCPU wynikają z dwóch powodów. Po pierwsze, śledzenie działań VM z bardzo dużym zapotrzebowaniem na CPU wymaga zaangażowania skomplikowanego zarządzania pamięcią oraz intensywnej komunikacji między CPU (obejmującej sterowanie buforem procesora, potokiem instrukcji i stanami we-wy), co jest bardzo trudne. Po drugie, zadanie hostowania VM jest postrzegane jako konsolidacja akcji serwera, a potrzebujące konsolidacji serwery są często maszynami jednoprocesorowymi.

Takie ograniczenia w przydzielaniu zasobów sprzętowych przez hypervisor wyznaczyły warunki, na jakich można było wykorzystać zalety 16-rdzeniowego serwera HP DL580G5 podczas testów (zob. "Jak testowano").

Jak wspomniano wcześniej, Microsoft obsługuje oficjalnie swoje systemy operacyjne oraz Novell SLES 10 (edycja z SP 1 i SP 2) jako instancje goszczone. To wyjaśnia, dlaczego testowano wyłącznie VM Windows 2008 i SLES 10.2. Inne systemy operacyjne (Red Hat Linux, Debian Linux i NetBSD) mogą również pracować, ale wtedy trzeba zdać się na własne wsparcie techniczne i poszukiwanie błędów we własnym zakresie.

W czasie testów Microsoft udostępnił Hyper-V Linux Interface Connector (Hyper-v LinuxIC), który jest zestawem sterowników wspomagających optymalizację CPU, pamięci, dysków i we-wy sieci dla instancji SLES. Zestaw ten rzeczywiście poprawia wydajność, ale jedynie w przypadku jednej vCPU na gościa. Hyper-V LinuxIC nie obsługuje środowisk SMP.

Koszty własne wirtualizacji

Wirtualizacja serwerów pozwala na upakowanie wielu instancji systemów operacyjnych na tym samym sprzęcie, który wcześniej gościł tylko jedną instancję. Ponadto pomaga wdrożyć standardowy profil systemu operacyjnego w centrum danych.

Jednak nic nie ma za darmo. Hypervisory stają się bazowymi systemami operacyjnymi serwerów, które wirtualizują, co prowadzi do obniżenia ich wydajności. Podczas tych testów mierzono koszt własny wirtualizacji, porównując wydajność transakcyjną: kiedy system operacyjny sam pracuje na serwerze, z przypadkiem kiedy pomiędzy systemem operacyjnym a systemem sprzętowym działa swoisty bufor w postaci hypervisora. Różnica w wydajności jest równoznaczna z teoretycznym podatkiem pobieranym przez zarządzanie hypervisora.

Obniżenie wydajności - po przejściu z natywnej instancji systemu operacyjnego do wirtualizowanej - z przydzielonym pojedynczym CPU, zmieniało się od ok. 2,5% (w przypadku ESM obsługującego Windows 2008) - do ponad 12%, kiedy Hyper-V obsługiwał SLES. Podstawowa utrata wydajności każdego hypervisora jest różna, ale VMware wygrywa tę hipotetyczną rundę. Jest ona hipotetyczna, ponieważ występuje niewiele przypadków uruchamiania platformy wirtualnej z jednym tylko systemem goszczonym, ograniczonym do jednego CPU.

Kiedy liczba CPU udostępnianych gościowi pojedynczej maszyny wirtualnej rośnie, koszt wirtualizacji zmienia się w szerszym zakresie. Podczas testów dopuszczono dostęp pojedynczej instancji systemu operacyjnego SMP do czterech vCPU i tu koszt był najniższy (mniejszy niż 4%), kiedy VMware ESX obsługiwał instancje SLES. Najwyższa cena wydajności, jaką odnotowano, to ponad 15% - Hyper-V obsługujący instancję SLES.

Podsumowując: także w tej rundzie Hyper-V tracił więcej niż ESX: różnica była mniejsza, kiedy obsługiwał maszyny wirtualne Windows, większa w wypadku SLES (prawdopodobnie z powodu braku zestawu LinuxIC, który poprawia wydajność).