Hyper-V Live Migration


Co innego czytac (choc w artykulach na ten temat spotyka sie glównie ogólniki) co innego, samodzielnie dotknac. W ramach przygotowania szkolenia z wirtualizacji skonfigurowalem sobie testowe srodowisko Hyper-V w oparciu o maszyny Windows Server 2008 R2 beta. Wykorzystujac trzy komputery, spialem sobie Active Directory i klaster, na którym zainstalowalem testowa maszyne wirtualna. Maszyna dala sie bez problemu wczytac do klastra.

Gdy tylko zobaczylem, ze srodowisko dziala, w konsolce Cluster Management czym predzej kliknalem “Move virtual machine(s) to another node”. Moje rozczarowanie bylo ogromne. Saving state, moving, restoring… dlugie sekundy. Mialo byc tak pieknie, a jest dokladnie jak w starszym Windows Server 2008. Nim zdazylem sie dobrze zastanowic co moglem w swoim srodowisku zrobic zle, zobaczylem, ze w menu jest jeszcze jedna opcja:

1 

Live migrate!
Po kliknieciu, maszyna wirtualna znalazla sie w dosc ciekawym stanie:

2

Operacja trwa kilkanascie sekund, po czym na chwilke widac zasoby w trybie offline, po czym wszystko znowu ma status “Running”. Szybko.
Z ciekawych rzeczy warto wspomniec, ze gdy w konsoli pojawia sie stan “Migrating”, dostepna jest opcja anulowania migracji. Ciezko okreslic, kiedy w praktyce moze okazac sie przydatna, ale warto wiedziec, ze jest.

3

Ciekawie zachowuja sie procenty pokazujace postep migracji. Prawdopodobnie zalezy to od srodowiska, ale u mnie po 55% bylo cos w okolicach 90%, potem na chwilke 98% a potem wszystko dzialalo na drugim wezle. Proces jest wiec nieco szybszy niz sie na poczatku po procentach moze wydawac.

Operacja “Move” bez opcji “live” jest szybsza. Opcja “Live” sprawia, ze maszyna krócej jest niedostepna. Mozna tak, mozna tak… co kto woli.

Z poziomu zarzadzania klastrem (czyli nie z poszczególnych wezlów) mozna podlaczyc sie do konsoli maszyny wirtualnej, jednak nalezy miec oprogramowanie do zarzadzania Hyper-V. Na chwile obecna, jedyna opcja jego instalacji jest instalacja calej roli, czyli dosc daleko idaca zmiana w systemie. Da sie z tym zyc, ale moze lepiej byloby miec same narzedzia zarzadzajace? Zobaczymy jak to bedzie w wersji finalnej. Warto jednak zaznaczyc, ze konsola laczy sie do wezla i na nim do maszyny. Tak wiec przelaczenie wezlów, niezaleznie od metody, na pewno wiazac sie musi z ponownym podlaczeniem konsoli.

Prawdziwe piekno testów Live Migration wychodzi dopiero podczas lacznosci sieciowej. Ile bedzie “zgubionych pingów”, jak przyjemnie bedzie sie pracowac z RDP, jak zachowa sie dedykowana aplikacja testujaca opóznienia pakietów, moze cos z filmem jak u konkurencji… To jednak sprawdze (i pewnie opisze) przy kolejnej okazji. Na razie pokonal mnie zupelnie prozaiczny brak wystarczajacej ilosci kart sieciowych. Windows Server 2008 R2 jest tu bardziej wymagajacy niz wersja bez R2 czyli build 6001 i trudno o wiarygodne testy majac w komputerach po jednej karcie.

Na koniec postanowilem zrobic test ostateczny. Wyciagnalem wtyczke z aktywnego wezla. Z pewna doza wyrozumialosci dla wersji beta, powiem, ze lepiej wyobrazalem sobie zachowanie maszyny wirtualnej. Pozostaje miec nadzieje, ze w wersji finalnej zachowa sie to tak, jak chcialbym…

Autor: Grzegorz Tworek [MVP]

Comments (2)

  1. Anonymous says:

    Wrażenie ogólne jest takie, że wierzę, że i tu nic nie zginie, ale jak napisałem – w ogóle nie testowałem sieciowości. To znaczy już po napisaniu notki, dodałem karty sieciowe i podłubałem w tym trochę, ale skończyło się na zaraportowaniu w MS Connect dość dziwnego błędu. Jak go rozwiążemy – będę kontynuować zabawy.

  2. Kaarol says:

    U konkurencji (VMWare) przeważnie nie ma zgubionych pingów. Czasem zdarzył mi się jeden ale bardziej winiłbym za to switch i przechowywane w nim informacje 🙂 Co do rdp to jak raz przesuwałem maszynę, to spokojnie na niej pracowałem i nie zostałem rozłączony.

Skip to main content