Miesiąc: marzec 2013

Hyper-v replication v1.o?

znaczenie wersji produktów/ficzerów w Microsoft:

• v1.o – marketing czyli ‘mamy taki produkt, jesteśmy na rynq!’. w rzeczywistości nie zdatny do użytq – po prostu ładnie wygląda na reklamie i informuje, że eMeS wyraża zainteresowanie tym fragmentem rynku
• v2.o – początek, czyli – ‘mamy taki a taki produkt, potrafi to i to, nie potrafi jeszcze tego i tego, ale SOHO/SMB ma już pewne funkcjonalności za free’. w rzeczywistości – hmmm.. faktycznie działa.
• v3.o – wdrażamy w ENT. w rzeczywistości – można wdrażać w ENT, bo faktycznie już jest skalowalny i większość funkcji nie dość że jest, to działa dobrze.

w w12 jest PowerShell v3.o oraz Hyper-v v3.o – oba naprawdę fajne i dojrzałe. a do Hv dodano nową, świetną funkcjonalność – Hv Replication… i jest ona ewidentnie w v1.o.. no może v2.o. o samej konfiguracji już trochę pisałem. czas na opis samej funkcjonalności.

co można o niej powiedzieć – jest. pomysł zaiste przedni – na miarę VMWare SRM. do tego stopnia fajnie pomyślane, że pozwala na wykorzystanie w scenariuszu hostingowym, gdzie stacje nie są w tej samej domenie. zacnie. skoro backup na hostingu – to znaczy łącze jakieś-takie. w sensie, że nie LAN 1GB. i teraz dochodzimy do clue, czyli to, co w całej świetności zostało spartaczone do stopnia nieużywalności. a są to dwa podstawowe ‘mankamenty’ + jeszcze trochę:

• miejsce docelowe replikacji ustawiane jest per cały cluster a nie per replikowana maszyna wirtualna.
• replikacja wykonywana jest co 5 min. i nie inaczej.

konsekwencje:

– jeśli chce się zrobić replikę całego clustra Hv, to wszystkie maszyny pchane są na pojedynczy storage. nawet jeśli maszyny-źródła są rozlokowane na wielu CSV dla zwiększenia wydajności, to docelowo będą przechowywane na pojedynczym. czyli jeśli strzeli podstawowa serwerownia, to zapasowa i tak może nie unieść takiego obciążenia. w efekcie można stosować albo dla bardzo małych środowisk – jedna, dwie maszyny, albo dla bardzo bogatych – gdzie jest się w stanie dostarczyć infrastrukturę [macierz, switche, NIC etc] potrafiącą unieść ‘takie’ obciążenie na jedym CSV. ‘takie’ – testowaliśmy to myśląc o redundancji dla klienta, gdzie na źródlanym klastrze stoi ok. 4o produkcyjnych maszyn. jedynym ratunkiem jest dodatnie do naszego DRP kroku pod tytułem ‘storage migration’ – czyli w trakcie uruchamiania maszyn w naszej lokalizacji offsite, równolegle migrujemy je na inne/docelowe CSV. odpalenie 4o wirtualek na jednym CSV po prostu się nie uda.

– no i najgorsze z najgorszych – czyli te nieszczęsne 5 min. ktoś, kto to zaharcodował musiał być po ciężkiej nocy – nie wnikając czy chodzi o pracę, czy zabawę, ale na pewno miał zaćmienie. replikowane są oczywiście delty – super. Mierzyliśmy je i nawet przy produkcyjnej maszynie nie są to *standardowo* duże zmiany – ot, 2-4MB. nawet dla 4o maszyn, przy 1oMbps łączu – 5min [teoretycznie i przy pełnej przepustowości] powinno wystarczyć. ale często, zbyt często, na maszynach produkcyjnych pojawiają się zmiany dużo większe – transakcje sql przy operacjach maintenancowych, operacje na serwerze plików, gdzie wrzuca się duże wielości czy tymczasowe pliki zrzucane przez aplikacje. nieszczęsny DPM potrafi na chwilę wrzucić 5GB plik. nie ma niestety możliwości utworzenia wykluczenia dla katalogu czy typu pliq – co w jakiś sposób by zminimalizowało problem w związq z czym trochę matematyki:

• załóżmy, że aplikacja utworzyła tempa 5GB. w sumie to bez większej różnicy czy jest to temp czy nie, ale ten scenariusz jest bardziej absurdalny i pokazuje nonsens w jaki się wpada, bo plik za chwilę znika. 5GB=4o96oMb. przy teoretycznym 1oo% dostępności, dajmy na to na 5oMb łączu, taki plik repliqje się 4o96o/5o/6o=13,65 minuty. tylko ta jedna zmiana i na naprawdę fajnym łączu i przy 1oo% dostępności – czyli warunki bardzo optymistyczne [czyt. mało realne]. dla 1oMb łącza ta liczba to już ponad 1h.
  co się dzieje w tym czasie? oczywiście uruchamiają się kolejne wyliczenia delty, ponieważ w ciągu tego czasu minęło kilka/wiele 5minutówek. w praktyce może się okazać, że za nim zreplikujemy naszą pierwszą zmianę (5GB) to przestanie ona być aktualna, ponieważ za chwile nadpisze ją kolejna zmiana. czyli w praktyce hv wysyła coś, co za chwilę zostanie nadpisane kolejną zmianą. zamiast się połapać i od razu wysłać ostatnią wersję naszych zmian. mały schemat:

jakieś tam obejście to zpauzowanie replikacji i uruchomienie z opcją resynchronizacji [koniecznie run as admin, inaczej krzyczy, że takiej maszyny nie ma]

• Suspend-VMReplication –vmname <VNAME>
• Resume-VMReplication –vmname <VNAME> -resynchronize

dzięki opcji resynchronize hv idzie po rozum do głowy i porównuje stan maszyny replikowanej na chwilę obecną z maszyną kopią, ergo tworzy nową deltę jedynie z ostatnimi zmianami. oszczędza nam to replikowanie ‘stanów pośrednich’. niestety resynchronizacja trochę zajmuje, dodatkowo została pisana z myślą o vhd/vhdx nie większych niż 500 GB. jeśli mamy takie trochę większe (np. dysk z danymi baz ponad 1TB), wtedy resynchronizacja zachowuje się mało wydajnie.

pojawia się wiele dodatkowych wątpliwości – bo trzeba nieźle się wstrzelić z czasem tegoż suspendu. w praktyce, wymagane jest małe dochodzenie, w jakich godzinach dochodzi do tworzenia ogromnych delt. osobiście pomogłem sobie małym skryptem, odpalanym ze schedulera co 5 minut

• $time = "{0:yyyy-MM-dd_HH.mm.ss}" -f (get-date)
• measure-vmreplication <VNAME> >> c:temp$time.txt

w prosty sposób mamy fajny obraz jak nasze delty rosną na przestrzeni czasu.

a rozwiązanie mogłoby być bardzo trywialne: zamiast nie-wiedzieć-skąd-wymuszone-5-min, wystarczyłoby, aby każda synchronizacja była wzbudzana – ot choćby przez scheduler. dzięki temu można byłoby w pełni kontrolować całą replikację, robić ją np. 2 razy dziennie, omijać okienka maintenancowe i backupowe i tak dalej…

z rzeczy na plus, które faktycznie działają i są miłym zaskoczeniem:

• kompresja – pogłoski mówiły o superwydajnym rosyjskim algorytmie, ale nie wiadomo jak to jest w praktyce. wiadomo natomiast, że faktycznie działa. zależnie od pomyślności wiatrów skacze od 5o% do 7o%. przy wstępnych wyliczeniach można założyć, że mamy prędkość replikacji równą 1,5 przepustowości naszego łącza.
• robienie pierwszej repliki na dysk USB – by zacząć replikację, musimy najpierw skopiować całą wirtualną maszynę do lokacji off-site. można to robić po WANie, ale można też tą pierwszą kopię zrobić na nośnik i przesłać go do serwerowni. kiedy nasza ‘initial replica’ zrobi się na dysk USB, po drugiej stronie powstaje replikowana maszyna z pustymi dyskami i snapshotem. Hv replikuje już zmiany do snapshota, mimo, że cała maszyna nie została jeszcze wgrana. replikacja działa, a kiedy kurier zawita do nas z nośnikiem, możemy w dowolnym momencie zaimportować sobie naszą pierwszą replikę.
• wersjonowanie – czasami może się okazać,
  że replikujemy zmiany z już uszkodzonej wirtualnej maszyny. nasza replika jest odwzorowaniem oryginału 1:1, więc jeśli uszkodzi się OS w oryginalnej maszynie, to samo spotka naszą replikę. wersjonowanie umożliwia trzymanie kilku snapshotów replikowanej maszyny. gdyby okazało się, że coś nie hula, możemy cofnąć się o te kilka/kilkanaście godzin.

na chwilę obecną Hv replica jest i się uśmiecha, ale jest to jeszcze bardzo nieśmiały uśmiech. niemniej działa i przy świadomości ‘charakterystyki’ tego działania, można śmiało wdrożyć to dla klienta, który nie ma wyśrubowanych wymagań. w praktyce eMeS oferuje nam trzy opcje na stworzenia sobie taniego DRP:

• Hv Replica
• połączenie Hv Replica i Data Protection Manager Chain Backup – maszyny, których nie da się replikować Hv Replicą, replikujemy DPMem, który podobnie wylicza delty, ale w bardziej zarządzalny sposób.
• DPM Chain Backp – wszystko replikowane za pomocą DPMa

każde podejście ma swoje zady i walety ale o tym… może kiedyś…

eN & Damian Skrzypiec