Strona główna > Hyper-V, Wirtualizacja, Zauważyłem > Ciekawostki Live Migration

Ciekawostki Live Migration

Dziś garść ciekawostek  dotyczących Live Migration. Cześć pewnie jest na 100 innych blogach a cześć to moje osobiste odkrycia dotycząca co nie znaczy ze ktoś ich nie odkrył gdzieś. Jak chyba każdy kto się w tematach wirtualizacji cos orientuje wie, e wraz z pojawieniem się W2k8 R2 pojawiła się długo oczekiwana funkcjonalność, która u konkurenta istnieje już jakiś czas i zwie się VMotion.  Każdego MS admina zżerało, ze nie mógł sobie w locie przerzucić VM-a pomiędzy fizycznymi hostami pod Hyper-V a admin VMwareowy mógł i do tego ciągle się tym chwalił- od W2k8 R2 szanse się wyrównały – przynajmniej w teorii. A jak to bywa w praktyce ?

W praktyce Live Migration do działania potrzebuje klastra, wszystkie VMHosty muszą być węzłami klastra itp. To jasne.  VMy muszą leżeć na jakimś wspólnym storage (iSCSI, fibery itp)  to tez jasne. W odróżnieniu od Hyper-V 1.0 (W2k8) VMy mogą leżeć na tym samym fizycznym LUN-ie bo Hyper-V 2.0 wprowadza technologie zwana CSV – Cluster Shared Volume – czyli teraz kilka VMów może leżeć na tym samym LUN-ie co ładnie widać na obrazku poniżej:

I tu zaczynają się ciekawostki.

1. Klaster Hyper-V 2.0 oparty o CSV nie da nam możliwości przyłączenia się jakiekolwiek innego systemu (W2k8 z Hyper-V 1.0 do tego wolumenu) Tzn nie napisze ze nie można a zapyta czy sformatować ;) A praktyce oznacza to ze albo mamy klaster W2k8  i jest Quick Migration, albo inwestujemy kasę w upgrade wszystkich VMhostow do W2k8R2 i cieszymy się Live Migration. Klastry mieszane odpadają ze względu na CSV.

2. By Live Migration działało interfejsy sieciowe na wszystkich VMhostach muszą mieć te same nazwy a VMy muszą być w tej samej podsieci/sieci. W przypadku gdy nazwy się nie zgadzają VM się nie przeniesie ale i pozostanie nietknięty – nie będzie downtime. Nie wiem czy nazwy są ‚case sensitive’ ja po prostu zawsze daje albo wszystkie nazwy na caps-locku albo wszystko małymi literami, żadnych spacji, myślników itp – przyzwyczajenia z dawnych dobrych czasów ;)  W trakcie gdy jeden węzeł pada, a siec jest ustawiona źle VMy się przeniosą ale sieci mieć nie będą. I tak lepsze to niż nic i nie można oczekiwać, że Hyper-V magicznie to podłączy do jakieś sieci.

3. Procesory na VMhostach:  W teorii nie muszą być takie same  tzn muszą być wszystkie albo Intela albo AMD, ale nie ma problemu jeśli są to rożne modele, rzecz jasna wszystkie muszą wspierać wirtualizacje. Tylko teraz w przypadku w którym mamy dajmy na to VMa o nazwie VM1.  Ten VM1 został stworzony na świeżo nabytym serwerze, który wcześniej już został dołączony do klastra, storage tez ma zapięty itp. Jest ‚pusty’ to ma masę wolnych zasobów wiec tworzymy wszystko tam, wiemy ze procki inne wiec zaznaczamy w ustawieniach i teraz jak tego VMa tworzymy poprzez  Hyper-V managera z Visty  to to będzie wyglądać tak:

A jak robimy to z W7  Hyper-V managera albo W2k8R2 Hyper-V managera to będzie już tak:

I tu małe schody, w tym pierwszym przypadku stanie się coś takiego: 2 tygodnie później zachodzi potrzeba zmigrowania  w locie VM1 na innego vmhosta bo w obecnym coś tam trzeba zrobić. To nie zadziała. Wyskoczy błąd, ze procesory nie pasują i nic z tego.

Rozwiązania są dwa i oba spowodują downtime: Shutdown VMa (a wiec downtime) potem przeniesienie VM-a nie przez Live Migration a przez Move na maszynę gdzie jest starszy procek i start. I od tej pory Live Migration będzie już działał w obie strony, nie wiem czemu tak jest ale tak jest. I opcja numer 2  zmiana tych ustawień bezpośrednio z konsoli Hyper-V managera na serwerze i od tej pory tez będzie to działać w obie strony.  Było by miło jakby ktoś sprawdził u siebie i się pochwalił w komentarzu jakimś. Jednym słowem trzeba uważać z czego się tego VM-a tworzy bo można potem się wpakować w downtime.

W drugim przypadku wszystko będzie cacy.

4. Im więcej RAMu ma VM tym dłużej będzie się migrował, w końcu stan RAMu musi się tez przemigrować. To powoduje ze nie do końca będzie to prawdziwe Live. Źle napisane aplikacje np takie oparte o bazę Progressa się wysypia.

5. Oczywistości typu jak docelowy VMhost ma jakiś duży load to tez to potrwa dłużej, czy ze jak siec jest zajęta to też się to przedłuży są jasne.

To chyba tyle z tego co na razie zaobserwowałem.

Advertisements
  1. Brak komentarzy.
  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: