Hyper-V Live Migration

Hyper-V Live Migration

  • Comments 2
  • Likes

Co innego czytać (choć w artykułach na ten temat spotyka się głównie ogólniki) co innego, samodzielnie dotknąć. W ramach przygotowania szkolenia z wirtualizacji skonfigurowałem sobie testowe środowisko Hyper-V w oparciu o maszyny Windows Server 2008 R2 beta. Wykorzystując trzy komputery, spiąłem sobie Active Directory i klaster, na którym zainstalowałem testową maszynę wirtualną. Maszyna dała się bez problemu wczytać do klastra.

Gdy tylko zobaczyłem, że środowisko działa, w konsolce Cluster Management czym prędzej kliknąłem "Move virtual machine(s) to another node". Moje rozczarowanie było ogromne. Saving state, moving, restoring... długie sekundy. Miało być tak pięknie, a jest dokładnie jak w starszym Windows Server 2008. Nim zdążyłem się dobrze zastanowić co mogłem w swoim środowisku zrobić źle, zobaczyłem, że w menu jest jeszcze jedna opcja:

1 

Live migrate!
Po kliknięciu, maszyna wirtualna znalazła się w dość ciekawym stanie:

2

Operacja trwa kilkanaście sekund, po czym na chwilkę widać zasoby w trybie offline, po czym wszystko znowu ma status "Running". Szybko.
Z ciekawych rzeczy warto wspomnieć, że gdy w konsoli pojawia się stan "Migrating", dostępna jest opcja anulowania migracji. Ciężko określić, kiedy w praktyce może okazać się przydatna, ale warto wiedzieć, że jest.

3

Ciekawie zachowują się procenty pokazujące postęp migracji. Prawdopodobnie zależy to od środowiska, ale u mnie po 55% było coś w okolicach 90%, potem na chwilkę 98% a potem wszystko działało na drugim węźle. Proces jest więc nieco szybszy niż się na początku po procentach może wydawać.

Operacja "Move" bez opcji "live" jest szybsza. Opcja "Live" sprawia, że maszyna krócej jest niedostępna. Można tak, można tak... co kto woli.

Z poziomu zarządzania klastrem (czyli nie z poszczególnych węzłów) można podłączyć się do konsoli maszyny wirtualnej, jednak należy mieć oprogramowanie do zarządzania Hyper-V. Na chwilę obecną, jedyną opcją jego instalacji jest instalacja całej roli, czyli dość daleko idąca zmiana w systemie. Da się z tym żyć, ale może lepiej byłoby mieć same narzędzia zarządzające? Zobaczymy jak to będzie w wersji finalnej. Warto jednak zaznaczyć, że konsola łączy się do węzła i na nim do maszyny. Tak więc przełączenie węzłów, niezależnie od metody, na pewno wiązać się musi z ponownym podłączeniem konsoli.

Prawdziwe piękno testów Live Migration wychodzi dopiero podczas łączności sieciowej. Ile będzie "zgubionych pingów", jak przyjemnie będzie się pracować z RDP, jak zachowa się dedykowana aplikacja testująca opóźnienia pakietów, może coś z filmem jak u konkurencji... To jednak sprawdzę (i pewnie opiszę) przy kolejnej okazji. Na razie pokonał mnie zupełnie prozaiczny brak wystarczającej ilości kart sieciowych. Windows Server 2008 R2 jest tu bardziej wymagający niż wersja bez R2 czyli build 6001 i trudno o wiarygodne testy mając w komputerach po jednej karcie.

Na koniec postanowiłem zrobić test ostateczny. Wyciągnąłem wtyczkę z aktywnego węzła. Z pewną dozą wyrozumiałości dla wersji beta, powiem, że lepiej wyobrażałem sobie zachowanie maszyny wirtualnej. Pozostaje mieć nadzieję, że w wersji finalnej zachowa się to tak, jak chciałbym...

Autor: Grzegorz Tworek [MVP]

Comments
  • 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.

  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment