Realna wydajność wirtualizacji

Dyskowe operacje we-wy

Podczas testów śledzono także przepustowość dysków hostowanych VM, wykorzystując Intel IOMeter (prekompilowane wersje Windows i Linux). IOMeter "ćwiczy" podsystemy dyskowe, tworząc wątki odczytu i zapisu w podsystemie w zdefiniowanym dla testów układzie. Pomiary są podsumowywane w operacjach we-wy na sekundę (IOs), rejestrowanych przez IOMeter na końcu przebiegu testu. Im wyższa liczba IOs, tym lepiej.

W świecie zwirtualizowanym instancje gościnne VM muszą rywalizować bądź o dysk wewnętrzny, bądź o zasoby pamięci sieciowej. Kiedy sprzęt jest prezentowany goszczonym systemom operacyjnym poprzez wirtualizację, poziom hypervisora pomiędzy sprzętem i goszczoną VM używa własnych sterowników dyskowych do zarządzania działaniem dysków. Dodawanie wirtualizowanych gości dzieli zasoby sprzętowe między instancje gościnnych systemów operacyjnych. Pomimo że natywne sterowniki systemów operacyjnych mogą być dostatecznie dobre, zdolność hypervisora do zarządzania potrzebami komunikacji między gośćmi staje się bardzo skomplikowana, a problemy opóźnień oraz efektywności można zauważyć w miarę spadku wydajności aplikacji.

W czasie testów uruchamiano IOmeter w każdej instancji VM w celu oceny, jak hypervisor może współpracować z dyskiem. Używano innego niż w świecie realnym stosunku zapisów do odczytów (odpowiednio: 70 i 30%). Faworyzowano zapis, ponieważ nie jest on silnie buforowany przez system operacyjny, a czytanie oparte na buforze może zakłócać pomiary.

Ustalono wydajność we-wy natywnego systemu operacyjnego (zarówno na pojedynczym serwerze, jak i na SMP) w celu określenia punktu odniesienia dla szybkości dyskowych operacji we-wy, mierzonych przez IOmeter. Ten sam test powtórzono w każdym z testowych środowisk wirtualnych z sześcioma maszynami wirtualnymi. W ten sposób zamierzano określić, czy hypervisor może oferować większą dostępność kanału dla goszczonych VM niż mogą one uzyskać w ich własnych instancjach natywnych.

Dobra wiadomość to taka, że testy pokazały, iż oba hypervisory mogą "pompować" kanał dyskowy z szybkością większą od pojedynczej instancji natywnej, kiedy dodaje się więcej instancji VM. Oznacza to, że sterowanie kanałem dyskowym (HP Smart Array) w wykonaniu hypervisora lepiej wykorzystuje go, gdy liczba gości rośnie.

W hostowanym SLES, kiedy każda VM miała dostęp do pojedynczej vCPU, można było zaobserwować, że instancje VM Hyper-V osiągały ogromne przyspieszenie, wykorzystując Microsoft LinuxIC, tak więc VM SLES Linux na Hyper-V była szybsza niż na VMware ESX. Gdy testowano SLES bez LinuxIC, wydajność obu hypervisorów była porównywalna. Na Hyper-V, bez LinuxIC, dla instancji SLES średnia liczba operacji we-wy na sekundę wynosiła 83,78 mln, ok. 5% więcej niż przepustowość dysków w przypadku VMware i SLES.

Jednak Hyper-V nie spisuje się już tak dobrze, kiedy zapewnia operacje dyskowe we-wy dla Windows 2008 Server. VMware wyprzedził Microsoft z sześcioma instancjami Windows 2008.

Kiedy mierzono dyskowe operacje we-wy w środowisku SMP - gdzie każda z sześciu VM miała przydzielone cztery vCPU - specjalnie posługiwano się nadsubskrypcją serwera w celu zaobserwowania, czy hypervisor może podtrzymać działania swojego kanału dyskowego, kiedy weźmie się pod uwagę zapotrzebowania na dysk z każdego systemu goszczonego. Ponieważ hypervisor sam jest pewnego rodzaju systemem operacyjnym, to musi ostrożnie realokować czas zapisu na dysku i przełączać kontekst między gośćmi czysto i efektywnie.

W tych testach oba hypervisory osiągnęły większą wydajność we-wy niż natywne systemy operacyjne pracujące bezpośrednio na sprzęcie. Jednak VMware jest wyraźnym zwycięzcą. Kiedy gościł maszyny wirtualne Windows 2008, to zarejestrowano 1733,63 mln operacji we-wy na sekundę, w porównaniu z 874,29 mln operacji we/wy na sekundę w przypadku Hyper-V i natywnej wydajności systemu operacyjnego na poziomie 712,97 mln operacji na sekundę. Jednak pokonał on też Hyper-V w środowisku SLES o ok. 45 mln operacji na sekundę (Hyper-V nie mógł tu wykorzystać zestawu LinuxIC, który nie obsługuje środowiska SMP).

Podsumowanie

Czołowa pozycja VMware na rynku znajduje potwierdzenie w fakcie uzyskiwania lepszej wydajności w większości przeprowadzonych testów, aczkolwiek trzeba uznać sprawność Microsoftu w obsłudze podstawowego obszaru - wydajności VM skupionej na konsolidacji pojedynczej CPU. Obaj dostawcy prawdopodobnie będą ulepszać wydajność swoich rozwiązań tak szybko, jak to możliwe, co też wymusi konkurencja pomiędzy nimi. To samo dotyczy pozostałych graczy w tym segmencie rynku: Citrix, Sun i Red Hat. Wydajność jest jednym z najważniejszych obszarów wirtualizacji.

Jak testowano

Testowano VMware ESX 3.51 Virtual Infrastructure Edition i Microsoft Hyper-V. Dla tego ostatniego używano także Microsoft Linux Interconnection Kit w wydaniu RTM.

Podstawową platformą testującą był serwer HP DL580G5, podłączony do sieci Gigabit Ethernet opartej na przełącznikach. Serwer wyposażono w: 32 GB dynamicznej RAM z szyną 1300 MHz obsługującą pamięć DDR3, dwa porty Gigabit Ethernet i wewnętrzny adapter HP Smart Array P400, obsługujący konfiguracje RAID 5 pięciu dysków i gorącej rezerwy. Wykorzystano cztery gniada CPU, każde zawierające czterordzeniowy procesor Intel 2,92 GHz, co daje 16 rdzeni 64-bitowych 2,93 GHz.

Jako goszczonych systemów operacyjnych, pracujących na hypervisorach w czasie testów, używano kombinacji instancji systemów operacyjnych Windows 2008 Enterprise Edition i Novell Suse Linux Enterprise Server/SLES wersji 10 SP2. Używano też Microsoft LinuxIC edycji RTM w połączeniu z SLES 10.2, kiedy hostowany był jako VM na Hyper-V.

Zastosowano edycje 64-bitowe Windows 2008 i SLES 10.2 zarówno w trybie natywnym, jak i goszczonym. Windows i SLES instalowano, używając tej samej pamięci i ustawień vCPU. Jądra SMP wykorzystano w celu zachowania jednolitości we wszystkich testach. Tam gdzie testowano wydajność dla jednej vCPU w trybie natywnym i hypervisora, wyjmowano trzy procesory z gniazd serwera HP DL 580G5. Dla pozostałych testów wszystkie rdzenie serwera były udostępniane dla hypervisorów, a następnie realokowano vCPU, zgodnie z opisem testów, dla każdego gościa CPU.

Wydajność testowano poprzez użycie dwóch benchmarków: jednego dla wydajności aplikacji biznesowych, o nazwie SPECjbb2005, i jednego dla wydajności operacji dyskowych - Intel IOMeter.

SPECjbb2005 stosowano na każdej natywnej i wirtualnej maszynie, wykorzystując pamięć operacyjną 2 GB, oraz - do ładowania - lokalny HP Smart Disk Array. Używano procesów alokacji pamięci w celu zapewnienia każdej instancji tej samej wielkości przydzielonej użytkownikowi pamięci.

Do pomiarów: kanał dyskowy - podsystem dysków (wewnętrzna HP Smart Array) wykorzystano IOMeter w prekompilowanej formie binarnej. Aby ocenić kanał dyskowy, używano trudniejszego niż w świecie realnym kontekstu zapisów i odczytów w kanale dyskowym. Stosunek zapisów do odczytów wynosił 7:3.

Wszystkie testy wykonano trzy razy, każde powtórzenie było porównywane z pozostałymi w celu zapewnienia, że rezultaty mieściły się w przedziale odchyleń nieprzekraczających 3%.