Testowanie VM z obciążeniem aplikacji biznesowych

W drugiej rundzie testów porównywano wydajność aplikacji VM w miarę dodawania maszyn VM do systemu: dla jednej, trzech i sześciu VM obsługujących zaakceptowane systemy operacyjne. Wydajność mierzono po przedzieleniu każdej VM jednego vCPU i kiedy każda była dopuszczona do czterech vCPU. Ten test obciążeń powinien teoretycznie wzmocnić różnice wydajności.

Jako narzędzie testowe wybrano SPECjbb2005 - popularny benchmark, który symuluje transakcje rozproszone w środowisku imitowanych hurtowni danych. Test SPECjbb2005 używa komponentów aplikacyjnych Java pracujących na pojedynczym hoście lub instancji VM. Pierwszy komponent symuluje klienta generującego wątki przetwarzane przez drugi komponent - silnik logiki biznesowej, który po kolei zapamiętuje i przenosi obiekty w transakcjach z zestawem obiektów Java Collection (emulujących silnik bazy danych). SPECjbb2005 tworzy parametry testu, opierając się na liczbie znalezionych CPU, a także dostępnej pamięci w hoście. Wyniki podawane są w podstawowych operacjach na sekundę (bops) - im więcej bops w czasie przebiegu testów, tym lepiej.

Wykonano pewną liczbę przebiegów z każdym hypervisorem, w dwóch układach: kiedy każda VM miała przydzielone własne vCPU lub każda VM miała pozwolenie na korzystanie z czterech vCPU.

W obu przypadkach uruchamiano test z jedną, trzema i sześcioma VM. Każda sekwencja przebiegała najpierw z Windows Server 2008, jako hostowanym systemem operacyjnym, i następnie z Suse SLES 10.2.

Pierwsza runda realizowana była w układzie: jedna VM goszcząca system operacyjny na jedną vCPU i ograniczony dostęp do pamięci (2 GB) dla każdej instancji systemu operacyjnego. Taka alokacja zasobów jest typowa dla tego, co się dzieje podczas procesu konsolidacji serwera, w którym są konsolidowane starsze, jednoprocesorowe maszyny w układzie "fizyczny na wirtualny".

W tej rundzie VMware z Windows 2008 i SLES 10.2 osiągnął wydajność wirtualną prawie tak dużą, jak wydajność naturalna, i utrzymał się blisko tych wyników z trzema goszczonymi systemami operacyjnymi. Hyper-V z trzema VM był o ok. 1400 bopsów gorszy niż VMware, z goszczonym Windows 2008, i o 1800 bopsów gorszy z VM SLES.

Przy sześciu goszczonych VM, oba hypervisory zaczęły zmagać się z zapewnieniem wydajności porównywalnej z działaniem systemów operacyjnych pracujących bezpośrednio na serwerze. Microsoft utrzymał swoją wydajność nieco bardziej pod kontrolą, wykazując się zdecydowanie liniową dystrybucją zasobów hypervisora, kiedy maszyny wirtualne zaczęły zgłaszać coraz większe potrzeby w tym zakresie.

W praktyce skonsolidowane instancje niekoniecznie muszą być tak obciążające, jak to ma miejsce w sytuacji uruchomienia współbieżnych testów SPECjbb2005. Wiele instancji systemów operacyjnych i aplikacji zazwyczaj ma dużo mniejsze stałe użytkowanie CPU niż nakłada na nie benchmark SPECjbb2005, i takie użytkowanie jest często bardziej losowe w naturze. Podczas testów jednak VM i hypervisor ją obsługujący poddano szczególnym obciążeniom w celu określenia, jak każdy hipernadzorca reaguje na anormalne obciążenia.

Druga runda iteracyjnych testów VM pozwalała, aby każda VM miała dostęp do czterech vCPU - maksimum dopuszczane przez każdy testowany hypervisor. Każda VM nadal była ograniczona do 2 GB pamięci, ponieważ jest to powszechnie przyjęta górna granica, gdy konsoliduje się i testuje system operacyjny. Ten scenariusz testów czytelniej pokazuje, jak VM powinna być używana w wirtualizowanych aplikacjach bazodanowych, systemach transakcyjnych i innych aplikacjach stawiających duże wymogi wobec obciążania CPU.

Jak poprzednio, wystartowano z jedną VM w celu ustalenia linii odniesienia, a następnie dodawano dwie kolejne VM, aby osiągnąć trzy instancje, po czym zwiększono ich liczbę do sześciu. W pierwszym teście VMware uzyskał lepsze osiągi, goszcząc klientów Windows 2008, i miał 1100 bopsów przewagi w porównaniu z sytuacją, gdy gościł VM SLES 10.2. Ponieważ zestaw Microsoft LinuxIC nie obsługuje środowiska SMP, wydajność Hyper-V z SLES została wyraźnie obniżona brakiem wzmocnienia, jakie zapewniono w testach, w których można przydzielić pojedyncze vCPU każdej VM.

W testach, gdzie każda z trzech VM używała cztery vCPU, w grze było 12 vCPU. Ze względu na to, że serwer testowy udostępniał 16 fizycznych rdzeni CPU, cztery z nich były na biegu jałowym. Hyper-V wyprzedził VMware ESX w tej rundzie o średnio 6500 bopsów. Rezultaty testów sugerują, że Hyper-V mógł widzieć te dodatkowe zasoby sprzętowe i wykorzystać je, podczas gdy ESX - nie.

Ta przewaga znikła jednak, kiedy nastąpiła tzw. nadsubskrypcja, co miało miejsce w ostatniej rundzie testów. Nadsubskrypcja (oversubscription) jest metodą przydzielania większej liczby fizycznych CPU niż jest dostępna, pozwalając maszynie wirtualnej na współdzielenie przydzielonych vCPU z innymi VM. Jest to proces pożyteczny, kiedy VM obsługuje aplikacje używające CPU losowo, pozwalając na załadowanie więcej VM z nadzieją (w zależności od aktywności gości) zapewnienia wydajności na poziomie zbliżonym do tego, jaki systemy-goście osiągały przed wirtualizacją.

Sześć VM, z których każda używa czterech vCPU, stwarza sytuację nadsubskrypcji 16 fizycznych rdzeni CPU dostępnych podczas testów. Oba hypervisory zaczęły uginać się pod tym ekstremalnym obciążeniem, ponieważ moc CPU jest krytyczna w tych trudnych testach. Jednak VMware poradził sobie z nadsubskrypcją lepiej niż Hyper-V, nadal "wyciągając" średnio 16 136 bopsów z Windows 2008 (Hyper-V - 14 488) i 17 089 bops z SLES (Hyper-V - 11 122). Microsoft jest trochę w niekorzystnym położeniu w wypadku nadsubskrypcji, ponieważ do uruchomienia systemu hypervisora Hyper-V potrzebna jest naturalna instancja Windows 2008 Server (używano edycji Enterprise), która zużywa własną pamięć i CPU.