Skip to Content

IT nieuczesane.
category

Category: virtualization

Hyper-v replication–konfiguracja

podczas konfiguracji Hyper-V replication można natrafić na wiele niespodzianek. teoretycznie jest to trywialne w konfiguracji – w praktyce artykuły są niepełne i wprowadzają w błąd. podstawowy jaki można znaleźć już zamieszczałem:

teraz testowałem konfigurację cluster-to-cluster i dwie ciekawostki:

  • teoretycznie usługa broker potrzebna jest na docelowym klastrze. niemniej trzeba ja zainstalować również na źródłowym – ponieważ jest tak dziwnie zaprojektowane, że będzie przedstawiać się FQDN’em CAP zasobu brokera [jego nazwą i IP]. żeby było ciekawiej – sam zasób brokera oraz obiekt CAP w AD można wyłączyć a nadal będzie działać /:
  • podczas generowania certyfikatu na replika-serwerze trzeba dodać SAN dla nazw obu węzłów klastra. czyli certyfikat musi mieć:
  • nazwę z CN dla brokera
  • nazwy wszystkich węzłów jako alternate name
  • takiego certyfikatu nie da się wygenerować makecertem – nie obsługuje alternate names. jedymym obejściem przy self-signed jest wygenerowanie certyfikatu wildcardowego.
  • jeśli na klastrze repliki będzie cert tylko z nazwą brokera, podczas konfiguracji Hyper-V replica pojawi się błąd:

    connection with the server could not be wstablished (0x00002EFD)

    HV connot connect to specified Replica server ‚<NODE-A>’. Error: A connection with the server could not be established (0x00002EFD). Verifiy that the specified server is enabled as a Replica server, allows inbound connection on port 443 and supports the same authentication scheme

    ten błąd jest dość mylący i dopiero rzut okiem do eventlogu wskazuje prawdziwy problem – brak obsługi na drugim węźle ze względu na certyfikat.

    eN.

    Replikacja Hyper-V – url revocation list check failed

    wraz z ws2o12 i nowym Hv v3 jest możliwość replikowania maszyny na zdalnego hosta. najbardziej interesujący scenariusz to replikacja hostingowa – jest sobie firma, która outsource’uje usługi IT i chce, aby ich maszyny były dodatkowo zabezpieczone. do tej pory wymagało to tworzenia całkiem wymyślnych struktur – VPNy, trusty, skomplikowane procedury recovery czy inne wynalazki. teraz scenariusz jest trywialny:

    • no owszem.. jakiś VPN czy inna komunikacja jest niezbędna
    • Hyper-v v3 u klienta i Hyper-v v3 w ośrodku hostującym
    • brak trustów, jakichkolwiek innych związqw między domenami. jedyny mechanizm uwierzytelniający to certyfikaty zdefiniowane po obu stronach. de facto cross-trust między rootCA choć wystarczy na wybranych serwerach

    jakie jest PKI każdy widzi (; CRLe często-gęsto są niedostępne. w labie z kolei łatwiej byłoby zrobić na selfsign’ach a nie bawić się w stawiania CA. a więc kilka tricków z pola walki:

    • do generowania certów można użyć makecert. niestety, pomimo że ma tylko 37kb nie ma go w systemie /: trzeba ściągnąć i zainstalować kilqGB SDK do Windows. LoL. albo sięgnąć po tego linka.
    • łatwo znaleźć art, w którym krok po korq opisana jest cała konfiguracja łącznie z poleceniami dla makecert – które są trudne i łatwo się pomylić. więc to bardzo ładnie, że ktoś to tak zacnie opisał
    • jest nawet polecenie w rejestrze wyłączające weryfikację CRLi. i tu się zaczyna problem, ponieważ on nie działa. ktoś zapomniał dopisać jeszcze jednego wpisu w rejestrze:

      ten wpis jest potrzebny zarówno przy clustrze jak i bez niego. kluczowa informacja
    • zmiany działają natychmiast i nie wymagają restartów – a więc jeśli nadal pojawia się błąd, to należy sprawdzić czy wartości są poprawnie wprowadzone do obu kluczy

    eN.

    weak event living on wrong object

    brzmi jak słowa piosenki. develperskiej piosenki (;

    foerr

    problemem jest jak się okazuje KB2750149 zainstalowany na Hyper-V na Failover Cluster. błąd generauje konsola clustra. więcej informacji można znaleźć np. tu.

    poprawkę trzeba póki co odinstalować, zrestartować i zablokować na WSUS.

    eN.

    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:

    image

    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.

    image

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

    Hyper-V z CSV cd…

    w końcu wszystko zahulało i od dwóch dni mam świetną zabawę testując czasy przenoszenia maszyn. nie tracą nawet pojedynczego pinga (: średnia prędkość kopiowania przy LM: 3ooMbps. teraz tydzień-dwa testów – ale wygląda na to, że osiągnąłem stabilizację środowiska.

    co było nie tak, że CSV się wieszał? nie znalazłem finalnej odpowiedzi ale kilka wskazówek:

    • znalazłem ciekawy art, w którym jest opisane podobne zachowanie – nie mój scenariusz ale warto się zapoznać
    • zrobiłem kilka zmian, po których zaczęło wszystko działać ‘ez expekted’ – podstawową było wyeliminowanie jednego ze switchy. czy była to kwestia jakiś problemów na styku HP/Cisco , czy problem MPIO – tego nie wiem, a testować już nie będę. tak jest docelowo i nie ma co komplikować.
    • drugą zmianą która mogła [choć nie powinna] mieć wpływ to włączenie obsługi jumboframes na obu węzłach

    wygląda na to, że fundamenty stoją. kilka nuketestów i redukujemy fizyczne klocki (:

    eN.

    Hyper-V cluster i Cluster Shared Volumes

     

    na ten temat znaleźć można wiele artykułów od stron technet po wpisy na blogu:

    to tylko kilka przykładów [polecam zwłaszcza ten ostatni]. niemniej jest kilka pytań, na które nie umiałem znaleźć odpowiedzi. a więc podsumowując oraz co nieco dodając…

    konfiguracja interfejsów sieciowych na Hyper-V Cluster

    to największy problem i najbardziej zagmatwany. wykorzystanie interfejsów sieciowych jest co najmniej nieintuicyjne – zarówno dla klastra jak i samego Hyper-v. po pierwsze ile ich jest potrzebne:

    • potrzebne są oddzielne interfejsy dla:
      • iSCSI [jeśli używane do dostępu do macierzy]. oczywiście sugerowana redundancja.
      • heartbit + LiveMigration
      • Host Network – komunikacja z węzłem, HV, i inne takie
      • Virtual Switch – min. jedna ale oczywiście zależne od ilości maszyn

    w niektórych artykułach jest wręcz przykazane, aby było jeszcze jedno połączenie – dedykowane dla Clustered Shared Volumes. jako niebezpieczeństwo łączenia funkcji heartbeat i LM jest możliwośc pełnego wysycenia podczas migracji i utraty heartbeatu – a co za tym idzie zfailowania całego klastra. nie wiem na czym dokładnie polega komunikacja CSV i jakie są jej wymagania – nie udało mi się tego odnaleźć w żadnym z artów.

    jak widać, zakładając wykorzystanie iSCSI, minimalna sugerowana ilość to 4 interfejsy. 3 wykorzystane na samą infrastrukturę. teraz druga kwestia – jak toto skonfigurować?

    • iSCSI – interfejs powinien mieć wyłączone wszystkie dowiązania protokołów (bindings) poza niezbędnym, czyli TCP/IP – v4 lub v6 zależnie z której korzystamy. obecnie można przyjąć, że v4 – tak zapewne ma 99,9% środowisk.
      • numeracja sieci: prywatna, bez zdefiniowanego GW
      • w konfiguracja klastra ta sieć powinna być oznaczona jako ‘do not allow cluster network communication on this network’. nie chcemy przecież zaśmiecać iSCSI…
      • konfiguracja zazwyczaj oparta na VLANach – należy pamiętać o zapewnieniu maksymalnej redundancji
    • heartbeat + LiveMigration + CSV – do wymiany danych przy LM powinien być dedykowany interfejs. imho można zaryzykować i połączyć te role. UWAGA! sugerowane są dwa oddzielne interfejsy – jeden na CSV+HB drugi na LM. tylko zaczyna się ich robić strasznie mało dla maszyn…
      • numeracja sieci – prywatna [inna niż dla iSCSI], bez zdefiniowanego GW. połączenie najlepiej fizyczne – bezpośrednie. ew. może być VLAN [ale po co sobie utrudniać życie?]
      • ze względu na Cluster Shared Volumes muszą być włączone protokoły ‘Client for Microsoft Network’ oraz ‘File and Printer Sharing for Microsoft Networks’
      • no i oczywiście TCP/IP w odpowiedniej wersji
    • Host Network – czyli zwykły dostęp do serwera.
      • numeracja sieci: sieć lokalna, powinien być oczywiście GW i DNS. na podstawie tego czy GW jest zdefiniowany czy nie, algorytm LM dobiera sieć, którą będzie pchał dane. można to wymusić ręcznie, ale standard jest właśnie taki: na normalnym interfejsie jest GW, a na specjalnych go nie powinno być [ w większości to i tak połączenia punkt-punkt]. z tego też korzystają mechanizmy samej usługi clustra – w LABie trzeba było na siłę wpisywać GW bo głupek nie przyjmował takiego interfejsu q:
      • tu oczywiście można zostawić wszystkie wymagane protokoły wraz z QoS i LLT
    • Virtual Switch – czyli co najmniej jeden interfejs dla maszyn wirtualnych. raczej będzie ich sporo więcej. dla każdego takiego interfejsu zostanie utworzona karta wirtualna. przeważnie podczas konfiguracji VirtualSwitcha [czyli po prostu sieci] w Hyper-V, interfejs jest konfigurowany automatycznie.. ale nie zawsze. wynikowo jest tak: 
      • konfiguracja wymaga opisania obu interfejsów – fizycznego i wirtualnego:
        • fizyczny: można odbindować wszystkie protokoły. samego interfejsu nie można wyłączyć, bo wirtualny również przestanie działać. oczywiście trzeba zostawić ‘Microsoft Virtual Switch Protocol’.
        • wirtualny z HV: ponieważ fizyczny jest ‘przechwytywany’ i staje się switchem, wirtualny staje się jego odpowiednikiem – jest jako zwykła sieciówka, która może być wykorzystana do komunikacji. co z nią zrobić? można choćby wyłączyć – nie do końca znalazłem odpowiedź czy to czymś grozi ale na logikę.. nie powinno.

    Cluster Shared Volume

    czytając arty odnosi się wrażenie, że konfiguracja to kilka kliknięć. być może w labie – ale ja mam na drugie Murphy. owszem – wystarczy trochę poklikać i jest. jednak kilka ważnych informacji:

    • nie zapomnieć wywalić dedykowanych sieci – oznaczyć jako ‘do not allow cluster network communication on this network’  – np. iSCSI
    • trzeba sprawdzić której sieci używa cluster do komunikacji LiveMigration – jest to znów nieintuicyjne ponieważ sprawdza się we właściwościach zasobu a nie na poziomie samego clustra. dodatkowo jest dziwne – ponieważ zmiana tego ustawienia na pojedynczym zasobie jest globalna…
    • trzeba sprawdzić której siei używa cluster do komunikacji CSV – i tego już z GUI się nie zrobi.

    inne takie…

    • bardzo nie chciałem serwerów HP – wsparcie tej firmy jest fatalne. i serwery są droższe. niestety zostałem pozbawiony wyboru i qpilismy HP. dodatkowo wybrałem architekturę AMD – więcej corów w mniejszej cenie daje większą elastyczność przy dystrybucji zasobów procesora na maszyny wirtualne.
    • niesamowite jest ile startują te HPki! trzeba czekać ok. 2min [SIC!] zanim w ogóle zacznie uruchamiać się BIOS. do tej porty wydawało mi się, że BIOS jest zawsze pierwsze – ale w tych serwerach jest coś, co się dzieje wcześniej. MASAKRA.
    • z AMD natomiast jest inny ból – Hyper-V nie chce działać, złośliwie mówiąc, że procesor nie wspiera wirtualizacji albo nie jest włączony DEP. okazuje się, że jest to spowodowane dodaniem do Opterownów z serii Buldozer technologii AVX. szczęśliwie jest na to poprawka: opis i download poprawki KB jest tutaj. pomimo, że technologia jest
      również w Intelach – poprawka jest tylko dla AMD. O_o
    • pozostaje kwestia konfiguracji jumboframes… na co najmniej oddzielny artykuł – to kolejna sprawa, która najczęściej podsumowywana jest ‘wystarczy włączyć’, a kiedy sprawę się ruszy okazuje się, że konfiguracja tego badziewia jest przytłaczająca i roi się wyjątków, wyjąteczków i wyjątusiów. wyjątusie są najgorsze q:
    • tak na prawdę to siedzę nad konfiguracją tego syfu 4 dzień i nadal mi nie działa – po uruchomieniu CSV w momencie, kiedy dwa serwery próbują coś pisać w tym samym czasie, całość przestaje działać. no i stąd mam za sobą kilkanaście artów na każdy temat. powinienem być mądrzejszy a czuję się głupszy. sprawę złożyłem we wsparciu Dell bp problem jest na pewno gdzieś na linii komunikacji z voluminem na macierzy… a więc na pewno będzie jeszcze krótkie podsumowanie dot. [za pewne jakiegoś głupiego] błędu jaki można zrobić podczas konfiguracji CSV..

    eN.

    system backupu na maszynie wirtualnej

    scenariusz: chcemy zwirtualizaować serwer backupów.

    problem: podstawowy problem to obsługa sterowników/urządzeń. oczywiście w przypadq backupu dyskowego nie ma problemów – mamy do dyspozycji kilka opcji. albo po prostu podłączenie dysq pass-through albo iSCSI. w przypadku napędu taśmowego nie jest tak łatwo. VMWare częściowo wspiera takie rozwiązania, pozwalając na bezpośrednie przekierowanie obsługi urządzenia do systemu guesta – nie mam w tej kwestii doświadczeń, poczytałem sobie tylko, że nie wszystko jest obsługiwane, ale szczegółów nie znam,

    co w przypadku Hyper-V? jest bardziej uniwersalny sposób – iSCSI. tak, tak. nie służy tylko do dysków – przecież to pełna obsługa SCSI przez TCP/IP a więc czemu by nie opublikować urządzenia taśmowego po iSCSI?

    zredefiniowany problem: jak znaleźć odpowiedni iSCSI Target? jest wiele darmowych produktów – choćby Microsoftowy – ale większość pozwala wyłącznie na tworzenie targetów do dysków wirtualnych. bardziej zaawansowane pozwalały na publikację plików ISO jako targety, fizycznych dysków etc. jednak ze znalezieniem takiego, który wspiera napędy taśmowe – był problem.

    sięgnąłem po StarWinda – ponieważ to AFAIK najbardziej zaawansowany software iSCSI Target. nie myliłem się – w pełni obsługuje takie rozwiązanie. problem polega na tym, że pojedyncza licencja kosztuje ok. $1.ooo. to trochę dużo – zwłaszcza, że nie mam zamiaru wykorzystywać go do celu tworzenia wielkiego SANa, a tylko opublikować jedno urządzenie. q mojej uciesze na stronie z darmowymi produktami jest “Tape Redirector” – uproszczony iSCSI Target, stworzony właśnie w tym celu, i to za free!  

    instalacja: aby zassać program trzeba mieć konto StarWind – weryfikacja danych jest na tyle niemiła, że nie przyjmuje nawet maila z publicznej skrzynki – musi to być konto korporacyjne. aplikacja instaluje się łatwo i przyjemnie i jest tak intuicyjna, że nie ma co się rozwodzić. jedyny problem – interfejs z jakiś powodów przekłamuje numer portu, dodając 1 – standardowy port tego targetu to 33268 a wszędzie pokazuje 33269.

    image

    po odpaleniu inicjatora po stronie systemu guesta i skonfigurowaniu połączenia, w urządzeniach pięknie pokazuje się odpowiednie urządzenie.

    niespodzianką był komunikat podczas próby instalacji sterowników urządzenia na guescie, iż nie są wspierane w środowisq wirtualnym. szczęśliwie była również opcja ‘extract’ i po ręcznej instalacji samego sterownika, całość zahulała jak należy (: zresztą BE ma swoje własne sterowniki i niechętnie współpracuje z tymi dostarczanymi przez producenta – a więc najlepiej nie instalować!

    na próbę zainstalowałem Backup Exec 2o12 w wersji trial. przetestowałem backup, inwentaryzację, restore – wydje się, że wszystko działa jak należy. można wirtualizować!

    wydajność: to oczywiste, ale na wszelki wypadek – aby uzyskać odpowiednią wydajność rozwiązania należy odpowiednio skonfigurować środowisko wirtualne. karta sieciowa dla powinna być dedykowana dla rozwiązania. bez żadnej szczególnej konfiguracji miałem 93MBps.

    eN.

    Diabeł leży w szczegółach

    konsola Hyper-v. sprawa prosta – używam jej od… 2k7 czy 2k8, kiedy wyszła beta [a nawet wcześniej, bo miałem dostęp do wewnętrznych wersji]. maszyny wirtualne zmieniły moje życie zawodowe (; sądziłem, że nie ma przede mną tajemnic.

    był jeden drobny szczegół, który mnie strasznie irytował – po usunięciu maszyn, te jakoś niedetrministycznie znikały, albo nie. restartowałem usługę – nadal czasem zostawały wiszące w konsoli. restartowałem serwer – i dopiero udawało mi się ich pozbyć. przekonany to że to ewidentny bug… aż w końcu przyszło mi do głowy przesunąć pasek widoq, w którym na końcu znajduje się kolumna ‘status’. i tam po usunięciu maszyn pięknie pokazuje się ‘destroying (x%)’ … po dojściu do 1oo% maszyna znika tak, jak powinna.

    powinienem swoją firmę nazwać ‘w gorącej wodzie company’

    eN.