W najnowszej wersji Hyper-V Microsoft wprowadził szereg istotnych udoskonaleń i nowych funkcji. Przyglądamy się im uważnie, skupiając się na rzadziej eksponowanych, ale ważnych zagadnieniach. Opisujemy również różnice pomiędzy różnymi wersjami Hyper-V.
Podobnie, jak pierwsza wersja, Hyper-V 2.0 to hypervisor przeznaczony do wirtualizacji serwerów. Umożliwia uruchamianie w wirtualnych maszynach klienckich i serwerowych systemów operacyjnych. Wymaga instalacji na serwerze systemu Windows Server 2008 R2 (nie dotyczy wersji Microsoft Hyper-V Server).
Hyper-V można wykorzystać do konsolidacji serwerów, wirtualizacji przestarzałych maszyn i wykonywania innych zadań typowych dla maszyn fizycznych. Hyper-V, podobnie jak inne hypervisory, bardzo ułatwia tworzenie środowisk testowych. Zdaniem producent, Hyper-V znajdzie zastosowanie zarówno w małych i średnich firmach, jak również w dużych wdrożeniach w centrach przetwarzania danych.
W posiadanie Hyper-V 2.0 można wejść na dwa sposoby. Oprogramowanie to jest integralną częścią systemu Windows Server 2008 R2. Można je zainstalować jako rolę w Windows Server 2008 R2 Standard, Enterprise lub Datacenter. Jest również dostępne w Windows Server 2008 R2 Foundation Edition. Drugim sposobem jest pobranie bezpłatnego oprogramowania Microsoft Hyper-V Server 2008 R2. Jest to mocno okrojona wersja Windows Server 2008 R2 (zawiera mniej komponentów, niż Windows Server 2008 Core), ale z preinstalowanym Hyper-V.
Zwróć uwagę, że Hyper-V jest dostępny tylko w wersji 64-bitowej.
Nowości w Hyper-V 2.0
Za najważniejszą nowość można uznać funkcję Live Migration. Jej wprowadzenie pozwoli Microsoftowi nawiązać konkurencję z innymi platformami wirtualizacji, w których ta przydatna funkcja była już od kilku lat.
Live Migration umożliwia szybką migrację maszyn wirtualnych między serwerami fizycznymi bez przerywania ich działania i zrywania sesji (poprzednia wersja Hyper-V zawierała funkcję Quick Migration, która umożliwiała migrację wirtualnych maszyn, ale powodowała kilkuminutową przerwę w działaniu).
Funkcja Live Migration współpracuje z jednym z mechanizmów Windows Server 2008 R2 – Cluster Shared Volumes. Połączenie tych funkcji zapewnia funkcjonalność typu failover. Trzeba jednak zaznaczyć, że każdy z serwerów musi być w tym samym klastrze failover i mieć dostęp do tej samej pamięci masowej.
Z punktu widzenia skalowalności, Hyper-V 2.0 lepiej radzi sobie przydzielaniem zasobów i obsługuje sprzęt zgodny z platformą Windows Server 2008 R2 (poprzednia wersja Hyper-V była znacznie bardziej ograniczona). Obsługuje osiem gniazd procesorów fizycznych (w przypadku wersji Datacenter nawet 64). Liczba obsługiwanych rdzeni procesorów wzrosła do 64 (Hyper-V 1.0 obsługiwało najpierw 16 rdzeni, a po jednej z aktualizacji 24 rdzenie). Maksymalna liczba wirtualnych procesorów to ośmiokrotność liczby procesorów logicznych (procesory logiczne to ekwiwalent rdzeni procesorów fizycznych).
Poza tym Hyper-V 2.0 obsługuje do 1 TB RAM i maksymalnie 16 węzłów klastra. Zwróć uwag, że węzły klastra nie są obsługiwane przez Microsoft Hyper-V Server 2008 R2. Maksymalna liczba wirtualnych maszyn, które można uruchomić, wynosi obecnie 384 (w przypadku Hyper-V 1.0 były to 192 wirtualne maszyny).
Jeśli skonfiguruje się klaster failover, w każdym węźle można uruchomić 32 maszyny wirtualne, a jeśli wykorzystuje się Virtual Desktop Infrastructure (VDI), to liczba ta rośnie do 64. Ograniczenie to dotyczy pojedynczego węzła, a w klastrze można mieć do 16 węzłów. Co oznacza, że w całym klastrze może działać maksymalnie 512 maszyn wirtualnych. W przypadku VDI stosowanie klastrów nie ma uzasadnienia. Jeśli dojdzie do awarii, wystarczy po prostu uruchomić kolejną wirtualną maszynę, ponieważ dane użytkownik są przechowywane poza zwirtualizowanym systemem operacyjnym.
W Hyper-V 2.0 poprawiono wydajność wirtualnych sieci, dodając kilka nowych mechanizmów, m.in. VM Chimney, funkcję, której zadaniem jest mapowanie ruchu w wirtualnej sieci do wybranych kart sieciowych. To pozwala wykorzystać tzw. TCP Offload Engine, czyli sprzętowe funkcje przetwarzania stosu TCP/IP. Z kolei funkcja Jumbo Frames wprowadzona w Windows Server 2008 jest teraz dostępna również w wirtualnych maszynach, co zwiększa przepustowość sieci i zmniejsza obciążenie procesora.
Porównanie możliwości Hyper-V 2.0 i Microsoft Hyper-V Server 2008 R2
Wprawdzie hypervisor w Microsoft Hyper-V Server 2008 R2 jest niemal identyczny, jak Hyper-V 2.0 w Windows Server 2008 R2, występują jednak pewne różnice.
Microsoft Hyper-V Server 2008 R2 obsługuje klastry, ale nie zawiera żadnych dodatkowych licencji na systemy operacyjne instalowane w maszynach wirtualnych (Windows Server 2008 R2 Enterprise Edition oferuje cztery licencje, natomiast wersja Datacenter Edition zawiera licencję na nielimitowaną liczbę wirtualnych maszyn).
Dla administratorów największą różnicą jest fakt, że Microsoft Hyper-V Server 2008 nie ma lokalnej, graficznej konsoli zarządzania. Oferuje jedynie proste narzędzie działające w trybie tekstowym, które pozwala na wprowadzanie podstawowych zmian w konfiguracji wirtualnych maszyn, np. zmianę nazwy czy dodanie do domeny.
Dlatego pełne zarządzanie Microsoft Hyper-V Server 2008 R2 możliwe jest tylko zdalnie, np. z wykorzystaniem Microsoft Remote Server Administration Tools (RSAT) w Windows Server 2008, 2008 R2 oraz Windows 7 (w tym ostatnim systemie narzędzie RSAT trzeba pobrać i zainstalować). Należy o tym pamiętać, ponieważ wdrożenie bezpłatnego Microsoft Hyper-V Server 2008 R2 będzie wymagało uruchomienia dodatkowego serwera z systemem Windows i narzędziami administracyjnymi.
Wydajność
Hyper-V 2.0 zawiera szereg istotnych zmian i udoskonaleń, które zbliżają to oprogramowanie do konkurencji. Dlatego z punktu widzenia wydajności i skalowalności, klienci używający Hyper-V 1.0 powinni bezdyskusyjnie dokonać aktualizacji.
Dużo istotniejsze jest jednak porównanie wydajności Hyper-V 2.0 z produktami VMware i Citriksa. Niestety, brakuje dokładnych, wiarygodnych testów wydajności. Wprawdzie można znaleźć wiele publikacji na temat wydajności hypervisorów, ale są to testy wykonywane na zlecenie producentów, więc z góry wiadomo, który z produktów okaże się lepszy.
Doświadczenie pokazuje, że wydajność nie powinna być kluczowym czynnikiem przy wyborze hypervisora. Na tym samym sprzęcie i przy identycznej konfiguracji platformy wirtualne powinny uzyskiwać zbliżone wyniki. Trzeba jednak pamiętać, że o wynikach decyduje bardzo wiele czynników – w zależności od sprzętu, konfiguracji środowiska i działających w nim maszyn wirtualnych, można otrzymać bardzo różne wyniki. Dlatego wybór hypervisora należy opierać na dostępności zaawansowanych funkcji, liście obsługiwanych systemów operacyjnych, funkcjonalności narzędzi zarządzania i liście obsługiwanych platform sprzętowych.
Wpływ Hyper-Threading na Hyper-V
Nowe, czterordzeniowe procesory Intel Core i7 mają wbudowany Hyper-Threading, mechanizm, który dzieli rdzeń procesora na dwa wirtualne rdzenie, co ma w założeniu zwiększać wydajność.
W kontekście Hyper-V i Hyper-Threading pojawia się następujący problem: jakie będą skutki, gdy pojedynczy procesor zostanie przypisany do kilku wirtualnych maszyn? Przykładowo, dwie maszyny wirtualne zostały tak skonfigurowane przez administratora, że używają tego samego procesora, ale mają używać oddzielnych rdzeni. Co się stanie, jeśli hypervisor przypisze je do tego samego rdzenia, który został podzielony na dwa rdzenie wirtualne? Należy spodziewać się znacznego spadku wydajności oraz tego, że pozostałe rdzenie procesora będą niewykorzystane. Na szczęście Microsoft przewidział taką sytuację i przygotował Hyper-V pod kątem procesorów z Hyper-Threading, więc nie należy obawiać się spadku wydajności.
Kompatybilność Live Migration z procesorami
Przede wszystkim, nie jest możliwa migracja wirtualnych maszyn pomiędzy serwerami z procesorami Intela i AMD, używając funkcji Live Migration lub Quick Migration, ponieważ procesory te mają inną architekturę i inne zestawy instrukcji. Przy standardowych ustawieniach nie uda się nawet migracja maszyn wirtualnych pomiędzy różnymi wersjami procesorów z tej samej rodziny – nawet jeśli procesory pochodzą od jednego producenta, mogą mieć wbudowane różne funkcje i zestawy instrukcji.
Ograniczanie te wynikają z faktu, że niektóre aplikacje w momencie uruchomienie sprawdzają właściwości procesora. Jeśli po uruchomieniu aplikacja sprawdzi, jakimi instrukcjami dysponuje procesor, zapisze informacje na ich temat w swojej konfiguracji i będzie z nich korzystać bez ponownego sprawdzania. Po migracji na inny serwer z procesorami, która mają uboższy zestaw instrukcji, aplikacja taka nadal będzie próbowała wywołać brakujące instrukcje, co spowoduje błąd w jej działaniu.
Aby rozwiązać ten problem, Hyper-V 2.0 oferuje możliwość ukrywania wielu zaawansowanych instrukcji procesora przed maszynami wirtualnymi. Po skonfigurowaniu tej funkcji można przenosić maszyny wirtualne pomiędzy węzłami klastra wyposażonymi w różne wersje procesorów tego samego producenta. Będzie to możliwe, ponieważ maszyny wirtualne będę miały udostępnione tylko te zestawy instrukcji, które są dostępne we wszystkich procesorach w danym klastrze.
Należy zauważyć, że ta funkcje nie wyszukuje zbioru funkcji dostępnych we wszystkich procesorach w danym klastrze, ale ogranicza zestaw instrukcji dostępnych dla wirtualnych maszyn poniżej instrukcji oferowanych przez procesory w klastrze. Aby włączyć tę funkcję, w konsoli Hyper-V Manager należy zaznaczyć opcję Migrate to a physical computer with a different processor version.
