Miesiąc: sierpień 2012

disk2vhd na wersji core

przy uruchomieniu disk2vhd na w2k8 R2 od razu pojawia się ‘missing vssapi.dll’. kwestią jest wersja x64 a standardowo próbuje dostępu do 32bit biblioteki. proste rozwiązanie:

set path=c:windowssyswow64;%path%

a potem już disk2vhd śmiga jak trzeba.

ps. próbowałem stworzyć ‘livecd’ z disk2vhd – tak, aby można było zfałhadekować offlineowy serwer. niestety na żadnym WinPE – nawet w DaRTS – nie jest uruchamiany podsystem obsługi vhd ): póki co nie mam pojęcia czy da się [i jak] stworzyć WinPE z obsługą VHD.

eN.

Migration attempt failed

problemy z live migration są ohydne do debugowania. poza krótkim opisem ‘migration attempt failed’ i enigmatycznym wpisie w eventvwr, który w najlepszym przypadq podpowie ‘error on source/destionation’ nie wiadomo nic więcej. pozostaje zbadanie całej konfiguracji krok-po-kroq. BUEEE.

najczęstszą przyczyną są błędy w nazewnictwie – np. sieci wirtualnych. literówki, brak jakiejś spacji etc. dość łatwo to przetestować po prostu podłączając do innej sieci i sprawdzić czy działa.

doczytałem o problemie z przesyceniem łącza dla LiveMigration – dlatego MS zaleca aż dwa dedykowane połączenia bezpośrednie między węzłami – oddzielne na LM i oddzielne na CSV i Hearbeat.

trafiłem na bardziej wredny problem ale trywialny w rozwiązaniu:
wszystko hula jak trzeba, maszyny używane od jakiegoś czasu, więc żadne literówki nie wchodzą w grę. na wszelki wypadek porobiłem testy migracji – maszyny, które mają pojedyncze dyski migrują się bez problemu… kłopot z migracją był tylko z maszynami, które miały podłączone dodatkowe dyski na drugim CSV. już chciałem się wściekać, że “to głupie LM nie obsługuje dwóch CSV”… ale zauważyłem, że w interfejsie brakuje informacji o powiązaniu z drugim CSV:

a rozwiązanie jest tak proste:

• po każdej zmianie wykonanej z poziomu Hyper-V Manager – bez względu czy dotyczy dysków, sieciówek czy czegokolwiek – należy odświeżyć konfigurację na klastrze.

w widoq maszyny wirtualnej RMB –> more actions –> refresh virtual machine configuration.

**UPDATE

i jeszcze jeden LoL http://blogs.msdn.com/b/robertvi/archive/2011/06/07/problems-with-live-migration.aspx

eN.

iSCSI na guest’cie. optymalizacja

można wyobrazić sobie dwa modele podłączenia dysku  iSCSI z danymi do maszyny wirtualnej:

• oba dyski dostępne są jako vhd na hosta i z tego poziomu podpięte do guesta
• dysk systemowy jest widoczny dla hosta a dysk z danymi jest dostępny via iSCSI i mountowany z poziomu guesta

jaka jest różnica?

różnica będzie polegać na kilku elementach: optymalizacji wykorzystania sieci, gdzie wchodzi przepustowość, i MPIO oraz wykorzystania pewnych mechanizmów – np. snpshotów, a to wiąże się z backupami. różni się również przenaszalność/elastyczność.

Scenariusz 1 – oba dyski jako vhd

niewątpliwie jest bardziej standardowym scenariuszem. dysk systemowy i dysk z danymi są w postaci VHD widoczne na poziomie hosta. zazwyczaj takie dyski będą albo lokalnie na serwerze albo na macierzy. bardziej interesujący jest przypadek z macierzą:

• jasna sprawa, że w takiej konfiguracji cała optymalizacja będzie realizowana z poziomu hosta. tutaj musi być odpowiednio skonfigurowane np. MPIO
• najważniejszą kwestią jest przepustowość sieci. jeśli maszyn wirtualnych jest wiele – a tak zazwyczaj jest, to (zakładając, że to konfiguracja Hyper-V z Cluster Shared Volume) wykorzystywane jest pojedyncze połączenie dla wszystkich maszyn. można zatem próbować kombinować z różnymi mechanizmami agregacji – czy to teaming kart sieciowych czy LACP. gdzieś na stronach MS można znaleźć, że Microsoft iSCSI nie obsługuje MPIO dla kart w teamingu, ale nie potwierdzam tego w praktyce i znalazłem podobne opinie na innych blogach.
• druga kwestia to mechanizmu snapshotów – macierz ma zazwyczaj swoje mechanizmy a Windows ma swoje [VSS dla systemu oraz snapshoty dla Hyper-v]. i tu zaczyna się trochę kombinowania – który mechanizm da najlepsze wyniki i jak to skonfigurować. aplikacje backupujące będą odwoływać się do VSS Hyper-V. jeśli tylko producent dostarcza odpowiednie sterowniki, można jednym snapshotem z poziomu macierzy zrobić wszystkie maszyny – warto zwrócić się do producenta maszyny o informacje czy jest to wspierane i jak to skonfigurować, ponieważ zysk może być duży.
• jest to rozwiązanie bardzo przenaszalne – ponieważ pliki vhd łatwo skopiować, podmountować itp, itd. w związku z czym łatwo zarządza się całym dyskiem jako pojedynczym plikiem.

Scenariusz 2 – dysk z danymi jako iSCSI

w pewnych sytuacjach może jednak być potrzeba innej optymalizacji. dysk z danymi może być jako volumen na macierzy udostępniany via iSCSI. jak wygląda optymalizacja i potencjalny zysk:

• daje to dużą dynamikę w alokacji przepustowości sieci, ponieważ można dedykować konkretny interfejs sieciowy dla konkretnego guesta (albo kilq) mapując go z poziomu Hyper-V i wykorzystać do połączenia iSCSI
• inaczej też wyglądają wtedy możliwości snapshotowania – host oczywiście nie dostanie się do takiego dysku a więc mechaznimy backupu muszą być optymalizowanie na poziomie guesta lub macierzy. nie da się w takim wypadku skorzystać ze sterowników macierzy dla Hyper-V.
• przenaszalność jest ograniczona – co prawda volumen można za pomocą iSCSI połączyć na dowolnym hoście, ale wszelkie mechanizmy dostępowe/zarządzania przenoszą się na macierz.
• olbrzymim zyskiem jest możliwość bardzo łatwej i bardzo szybkiej zmiany wielkości partycji danych – w przypadku vhd taka operacja zajmie wiele godzi, w tym scenariuszu – kilka sekund.

które lepsze?

w większości przypadków – scenariusz 1. daje to zoptymalizowane wykorzystanie sieci oraz potencjalnie – wsparcie mechanizmów snapshotowania z poziomu hosta przez macierz. jednak jeśli przyrost danych jest nie do przewidzenia lub konieczne jest dedykowane łącze zapewniające 1oo% przepustowości sieci – w takim wypadku scenariusz 2 staje się bardzo zachęcający.

eN.