Hyper-V cluster i Cluster Shared Volumes

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

• Hyper-V: Using Hyper-V and Failover Clustering
• Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2
• Rough Guide To Setting Up A Hyper-V Cluster
• Microsoft Hyper-V Networking and Configuration – Part 1 [pomimo ‘part 1’ nie znalazłem innych partów (; ]
• Virtual Networking for Hyper-V part 1 [z niego są linki do pozostałych części]

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.

• link do instrukcji powershell
• wpis na blogu gdzie są konkretne instrukcje
• a w skrócie: get-clusternetworks | ft name, mertic, autometric

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.