Dostrajanie progów sieci klastra trybu failover

W tym artykule przedstawiono rozwiązania umożliwiające dostosowanie progów ustawień sieci klastra trybu failover. Zwiększenie wartości tych ustawień może pomóc zmniejszyć wrażliwość klastra na przejściowe problemy z siecią.

Objaw

Podczas uruchamiania węzłów klastra trybu failover systemu Windows zalecane jest zmianę ustawienia klastra na bardziej zrelaksowany stan monitorowania. Ustawienia klastra, które są gotowe do użycia, są restrykcyjne i mogą powodować niepotrzebne awarie. Ustawienia domyślne są przeznaczone dla wysoce dostrojonych sieci lokalnych i nie uwzględniają możliwości wywołania opóźnienia spowodowanego przez wielodostępne środowisko, takie jak 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ł nie jest osiągalny za pośrednictwem sieci, akcja odzyskiwania jest podejmowana w celu odzyskania i przełączenie aplikacji i usług w tryb online w innym węźle w klastrze. Opóźnienie komunikacji między węzłami klastra może prowadzić do następującego błędu:

Błąd 1135 (dziennik zdarzeń systemu)

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 utratą komunikacji z innymi aktywnymi węzłami w klastrze trybu failover. Uruchom kreatora Weryfikowanie 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 sieciowych, z którymi węzeł jest połączony, 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 używane 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ępować 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 — określa liczbę pulsów, które są pomijane przed podjęciem akcji odzyskiwania przez klaster. Próg jest liczbą 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, które znajdują się w różnych podsieciach.

Domyślnie system Windows Server ustawia wartość SameSubnetThreshold na 10 i SameSubnetDelay na 1000 ms. Jeśli na przykład monitorowanie łączności zakończy się niepowodzeniem przez 10 sekund, próg trybu failover zostanie osiągnięty, co spowoduje usunięcie 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łoszono 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 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.