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.

Source EventID Details
FailoverClustering

1126

Cluster network interface ‘Heartbeat (NIC1) (1)’ for cluster node on network ‘Heartbeat’ is unreachable by at least one other cluster node attached to the network. The failover cluster was not able to determine the location of the failure. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
i40ea

27

Intel(R) Ethernet Converged Network Adapter X710 #2 Network link is disconnected.
Hyper-V-VmSwitch

22

Media disconnected on NIC /DEVICE/ (Friendly Name: Microsoft Network Adapter Multiplexor Driver).
MsLbfoSysEvtProvider

16949

Member Nic Disconnected.
i40ea

27

Intel(R) Ethernet Converged Network Adapter X710 Network link is disconnected.
MsLbfoSysEvtProvider

16949

Member Nic Disconnected.
MsLbfoSysEvtProvider

16945

Member Nic Disconnected.
sdddsm

24

MPDISK reservation preempted.
FailoverClustering

1135

Cluster node was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
FailoverClustering

5120

Cluster Shared Volume ‘Volume3’ has entered a paused state because of ‘(c000020c)’. All I/O will temporarily be queued until a path to the volume is reestablished.
FailoverClustering

5120

Cluster Shared Volume ‘Volume4’ has entered a paused state because of ‘(c000020c)’. All I/O will temporarily be queued until a path to the volume is reestablished.
i40ea

27

Intel(R) Ethernet Converged Network Adapter X710 Network link is disconnected.
Hyper-V-VmSwitch

22

Media disconnected on NIC /DEVICE/ (Friendly Name: Microsoft Network Adapter Multiplexor Driver).
MsLbfoSysEvtProvider

16949

Member Nic Disconnected.
i40ea

27

Intel(R) Ethernet Converged Network Adapter X710 #2 Network link is disconnected.

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.