IaaS z SQL Server — dostrajanie progów sieci klastra trybu failover

W tym artykule przedstawiono rozwiązania dotyczące dostosowywania progu sieci klastra trybu failover.

Objaw

Po uruchomieniu węzłów klastra trybu failover systemu Windows w usłudze IaaS z SQL Server zawsze włączoną grupą dostępności zaleca się zmianę ustawienia klastra na bardziej swobodny stan monitorowania. Ustawienia klastra są restrykcyjne i mogą powodować niepotrzebne awarie. Ustawienia domyślne są przeznaczone dla wysoce dostosowanych sieci lokalnych i nie uwzględniają możliwości wystąpienia opóźnienia spowodowanego przez środowisko wielodostępne, takie jak Platforma Microsoft Azure (IaaS).

Klaster trybu failover systemu Windows Server stale monitoruje połączenia sieciowe i kondycję węzłów w klastrze systemu Windows. Jeśli węzeł jest nieosiągalny przez sieć, zostanie podjęta akcja odzyskiwania w celu odzyskania i przełączenia aplikacji i usług w tryb online w innym węźle klastra. Opóźnienie w komunikacji między węzłami klastra może prowadzić do następującego błędu:

Błąd 1135 (dziennik zdarzeń systemowych)

Węzeł klastra Node 1 został usunięty z aktywnego członkostwa w klastrze trybu failover. Usługa klastrowania w tym węźle mogła zostać zatrzymana. Może to być również spowodowane tym, że węzeł utracił komunikację z innymi aktywnymi węzłami w klastrze trybu failover. Uruchom kreatora Sprawdzanie poprawności konfiguracji, aby sprawdzić konfigurację sieci. Jeśli warunek będzie się powtarzać, sprawdź, czy występują błędy sprzętu lub oprogramowania związane z kartami sieciowymi w tym węźle. Sprawdź również błędy w innych składnikach sieci, z którymi jest połączony węzeł, takich jak koncentratory, przełączniki lub mostki.

Cluster.log przykład:

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG   [NETFTAPI] Signaled NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address 10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] got event: Remote endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Marking Route from 10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] Checking to see if all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] All routes for route (virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [CORE] Node 8: executing node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: Cleaning up connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [Nodename] Clearing 0 unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: n12 node object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO  [DCM] HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 1: Old: 05.936, Message: Response, Route sequence: 150415, Received sequence: 150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: closing n12 node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 2: Old: 06.434, Message: Request, Route sequence: 150414, Received sequence: 150402, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO  [DCM] HandleRequest: dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 3: Old: 06.934, Message: Response, Route sequence: 150414, Received sequence: 150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 4: Old: 07.434, Message: Request, Route sequence: 150413, Received sequence: 150401, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:26.664, Ticks since last sending: 36

0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO  </struct mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO   removed

0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: Lost quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: goingAway: 0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   lost quorum (status = 5925)

Przyczyna

Istnieją dwa ustawienia służące do konfigurowania kondycji łączności klastra.

Opóźnienie — określa częstotliwość wysyłania pulsów klastra między węzłami. Opóźnienie to liczba sekund przed wysłaniem następnego pulsu. W tym samym klastrze mogą wystąpić różne opóźnienia między węzłami w tej samej podsieci i między węzłami, które znajdują się w różnych podsieciach.

Próg — definiuje liczbę pulsów, które zostały pominięte przed podjęciem przez klaster akcji odzyskiwania. Próg to liczba pulsów. W tym samym klastrze mogą istnieć różne progi między węzłami w tej samej podsieci i między węzłami znajdującymi się w różnych podsieciach.

Domyślnie Windows Server 2016 ustawia wartość SameSubnetThreshold na 10, a wartość SameSubnetDelay na 1000 ms. Jeśli na przykład monitorowanie łączności zakończy się niepowodzeniem przez 10 sekund, zostanie osiągnięty próg trybu failover, co spowoduje nieosiągalne usunięcie tego węzła z członkostwa w klastrze. Spowoduje to przeniesienie zasobów do innego dostępnego węzła w klastrze. Zostaną zgłoszone błędy klastra, w tym zgłaszany jest błąd klastra 1135 (powyżej).

Rozwiązanie

Aby rozwiązać ten problem, zrelaksuj ustawienia konfiguracji sieci klastra. Zobacz Puls i próg.

Informacje

Aby uzyskać więcej informacji na temat dostrajania ustawień konfiguracji sieci klastra systemu Windows, zobacz Tuning Failover Cluster Network Thresholds (Dostrajanie progów sieci klastra trybu failover).

Aby uzyskać informacje na temat używania cluster.exe do dostosowywania ustawień konfiguracji sieci klastra systemu Windows, zobacz Jak skonfigurować sieci klastra dla klastra trybu failover.