Sprawdzenie poprawności działania komunikacji CSV dla Microsoft Failover Cluster dla Hyper-V

Rozwiązania wysokiej dostępności z wykorzystaniem technologii Microsoft Failover Cluster dla Hyper-V wraz z Clustered Shared Volume konfiguruje się dosyć prosto i można powiedzieć, że rozwiązanie działa out of the box.

Problemy mogą zacząć się, gdy środowisko się rozrasta i/lub zaczyna być poważnie obciążone np. Podczas backupu Clustered Shared Volumes.

W przypadku Clustered Shared Volumes odczyt i zapis danych odbywa się z wykorzystaniem bezpośredniego połączenia każdego węzła z zasobem dyskowym, czy też po iSCSII lub Fibre Chanell. Wyjątek tutaj stanowi zapisywanie metadanych – czyli np. powiększanie pliku, zmiana uprawnień – wówczas wykorzystywany jest ruch CSV po sieci Ethernet do węzła, który jest właścicielem danego dysku.

W przypadku jakichkolwiek problemów z komunikacją możemy ujrzeć następujące błędy, w końcowym stadium powodujące wyłączenie jednego z węzłów.

Najważniejsze to rozdzielenie ruchu sieciowego na różne karty sieciowe dla:

• Maszyn Wirtualnych
• Live Migration
• HeartBeat
• Ruchu CSV
• Backupu (o ile wykonywany jest po sieci)

Nawet jeżeli nie mamy tyle fizycznych kart sieciowych do rozdzielenia ruchu zastosujmy wirtualne karty sieciowe (Add-VMNetworkAdapter), dodatkowo rozważmy zastosowanie Teamingu kart sieciowych. Poprawny opis konfiguracji sieci w Microsoft Failover Cluster znajdziemy tutaj: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj735302%28v=ws.11%29.

Po, których kartach sieciowych odbywać się ma ruch Kliencki (Maszyn Wirtualnych), HeartBeat oraz ruch Live Migration ustawiamy w Failover Cluster Manager.

Domyślnie ruch CSV będzie odbywał się po sieci HeartBeat – co zazwyczaj jest dobrym wyborem, chyba, że sieć ta nie jest za szybka. Do kontroli, którą siecią ma odbyć się ruch CSV służą metryki. Aby je wyświetlić używamy komendy:

Get-ClusterNetwork|ft Name,Metric,AutoMetric

Użyta zostaje sieć z najniższą metryką i możemy ją zmodyfikować poniższą komendą, aby wybrać sieć dedykowaną do ruch CSV:

(Get-ClusterNetwork eth0).metric=800

Jeżeli natomiast, z jakiś przyczyn chcemy aby ruch CSV odbywał się po sieci klienckiej powinniśmy wykonać (zazwyczaj nie jest to zalecane):

(get-cluster).UseClientAccessNetworksForSharedVolumes=$true

Dodatkowo aby zoptymalizować ruch między węzłami Clustra warto zaznaczyć opcje Microsoft Failover Cluster Virtual Adapter Performance Filer dla kart sieciowych .

Sieć dotyczącą backupu trzeba skonfigurować w programie do owego backupu i w przypadku Veeam robimy to jak poniżej:

Jeszcze raz chciałbym uczulić na odseparowanie ruchu dla CSV i HeartBeat od innego ruchu, gdyż wysycenie łącza dla CSV i Heartbeat może doprowadzić do awarii Clustra.

Na zakończenie warto też zaimplementować reguły QoS dla Clustra, jak poniżej:

# Live Migration
New-NetQosPolicy “Live Migration” –LiveMigration –Priority 4
# CSV
New-NetQosPolicy “SMB” –SMB –Priority 5
# HeartBeat
New-NetQosPolicy “HeartBeat” -IPDstPort 3343 –Priority 6
# Wlaczenie na wszystkich interface QoS
get-VMNetworkAdapter -ManagementOS|Set-VMNetworkAdapter -IeeePriorityTag On

Aby sprawdzić, czy nie następuje wysycenie łącza oraz komponentów systemu odpowiedzialnych za komunikacje miedzy-nodową oraz docelowo wyrzucenie jakiegoś węzła z Clustra proponuje użyć oprogramowania iperf i wygenerować ruch multicast. Proszę używać programu iperf skompilowanego natywnie dla windows w wersji 2, gdyż tylko on prawidłowo obsługuje muliticast. iperf-2.0.4-win32.

Na jednym Nodzie proponuje uruchomić komendę:

iperf.exe   -c 224.0.166.111 -u -T 100 -i 1 -b 9000000000 -t 3600

na drugim Nodzie natomiast:

iperf -s -u -B 224.0.166.111 -i 1

Z założenia ruch ten nie powinien odbywać się poprzez sieć dla CSV oraz Heartbeat. Testy możemy powtórzyć z maszyn wirtualnych. Proszę zauważyć, iż w powyższym teście, również obciążamy wirtualnego switcha (o ile dojdzie do niego ruch), gdyż to on musi zmultiplikować ruch multicast do każdej maszyny wirtualnej.

Możemy zintensyfikować testy uruchamiając kolejne instancje oprogramowania iperf dla kolejnych adresów multicast np. 224.0.166.112, 224.0.166.113, 224.0.166.114.

Przy okazji wspomnę, iż powyższy test pomaga zlokalizować bug w kartach sieciowych Intel(R) Ethernet Converged Network Adapter X710 (Driver Version 1.8.94.0, Firmware: Version: 18.5.17), które w przypadku zainstalowania roli Hyper-V, oraz uruchomienia VMQ rozłączają się, co automatycznie powoduje awarie rozwiązania wysokiej dostępności.