Wystąpił problem z usunięciem węzłów z aktywnego członkostwa w klastrze trybu failover

W tym artykule przedstawiono sposób rozwiązywania problemów, w których węzły są usuwane z członkostwa klastra trybu failover losowo.

Symptomy

W przypadku wystąpienia problemu są wyświetlane zdarzenia takie jak to zdarzenie zarejestrowane w dzienniku zdarzeń systemu:

To zdarzenie jest rejestrowane we wszystkich węzłach w klastrze z wyjątkiem usuniętego węzła. Przyczyną tego zdarzenia jest to, że jeden z węzłów w klastrze oznaczył ten węzeł jako wyłączony. Następnie powiadamia wszystkie pozostałe węzły zdarzenia. Gdy węzły są powiadamiane, przerywają i przerywają połączenia pulsu z węzłem wyłączonym.

Co spowodowało, że węzeł został oznaczony w dół

Wszystkie węzły w klastrze trybu failover systemu Windows Server komunikują się ze sobą za pośrednictwem sieci, które są ustawione, aby umożliwić komunikację sieciową klastra w tej sieci. Węzły wysyłają pakiety pulsu w tych sieciach do wszystkich innych węzłów. Te pakiety mają być odbierane przez inne węzły, a następnie odpowiedź jest wysyłana z powrotem. Każdy węzeł w klastrze ma własne pulsy, które będą monitorowane, aby upewnić się, że sieć jest włączona, a inne węzły są w górę. Poniższy przykład powinien pomóc wyjaśnić to zachowanie:

Jeśli którykolwiek z tych pakietów nie zostanie zwrócony, określony puls zostanie uznany za nieudany. Na przykład W2K8-R2-NODE2 wysyła żądanie i odbiera odpowiedź z W2K8-R2-NODE1 do pakietu pulsu, aby określić sieć i węzeł jest w górę. Jeśli W2K8-R2-NODE1 wysyła żądanie do W2K8-R2-NODE2 i W2K8-R2-NODE1, nie otrzyma odpowiedzi, zostanie uznane za utracone puls, a W2K8-R2-NODE1 śledzi to. Ta nieodebrana odpowiedź może mieć wartość W2K8-R2-NODE1 wyświetlać sieć jako wyłączoną do momentu odebrania innego żądania pulsu.

Domyślnie węzły klastra mają limit pięciu błędów w ciągu 5 sekund przed oznaczeniem połączenia. Jeśli więc W2K8-R2-NODE1 nie otrzyma odpowiedzi pięć razy w okresie, uważa, że określona trasa do W2K8-R2-NODE2 nie działa. Jeśli inne trasy są nadal uważane za aktywne, W2K8-R2-NODE2 pozostanie aktywnym elementem członkowskim.

Jeśli wszystkie trasy są oznaczone jako W2K8-R2-NODE2, zostaną usunięte z aktywnego członkostwa w klastrze trybu failover, a zdarzenie 1135 widoczne w pierwszej sekcji zostanie zarejestrowane. W wersji W2K8-R2-NODE2 usługa klastra zostanie zakończona, a następnie ponownie uruchomiona, aby można było spróbować ponownie połączyć klaster.

Aby uzyskać więcej informacji na temat obsługi określonych tras przechodzących w dół z co najmniej trzema węzłami, zobacz blog "Partitioned" Cluster Networks (Podzielone na partycje) dotyczący sieci klastrów napisany przez Jeffa Hughesa.

Teraz, gdy wiemy, jak działa proces pulsu, jakie są niektóre ze znanych przyczyn niepowodzenia procesu

1. Rzeczywiste awarie sprzętu sieciowego. Jeśli pakiet zostanie utracony w przewodzie gdzieś między węzłami, puls kończy się niepowodzeniem. Dane śledzenia sieci z obu węzłów, których dotyczy ten proces, zostaną ujawnione.

2. Profil połączeń sieciowych może być prawdopodobnie odbijany z domeny do domeny publicznej i z powrotem do domeny ponownie. Podczas przechodzenia tych zmian można zablokować we/wy sieci. Możesz sprawdzić, czy tak jest, przeglądając dziennik operacyjny profilu sieciowego. Ten dziennik można znaleźć, otwierając Podgląd zdarzeń i przechodząc do obszaru Dzienniki aplikacji i usług\Microsoft\Windows\NetworkProfile\Operational. Sprawdź zdarzenia w tym dzienniku w węźle, który został wymieniony w zdarzeniu o identyfikatorze 1135 i sprawdź, czy profil się zmieniał w tej chwili. Jeśli tak, zobacz Profil lokalizacji sieciowej zmienia się z "Domena" na "Publiczny" w systemie Windows 7 lub Windows Server 2008 R2.

3. Na serwerach włączono protokół IPv6, ale w zaporze systemu Windows są wyłączone następujące dwie reguły dla ruchu przychodzącego i wychodzącego:

   • Podstawowa sieć — anons odnajdywania sąsiadów
   • Podstawowa sieć — żądanie odnajdywania sąsiadów

4. Oprogramowanie antywirusowe może również zakłócać ten proces. Jeśli podejrzewasz, że jest to możliwe, przetestuj, wyłączając lub odinstalowując oprogramowanie. Zrób to na własne ryzyko, ponieważ w tym momencie nie masz ochrony przed wirusami.

5. Opóźnienie w sieci może również spowodować wystąpienie tego problemu. Pakiety mogą nie zostać utracone między węzłami, ale mogą nie być wystarczająco szybko do węzłów przed upływem limitu czasu.

6. Protokół IPv6 jest domyślnym protokołem używanym przez klaster trybu failover dla pulsów. Sam puls to pakiet sieciowy emisji pojedynczej UDP, który komunikuje się za pośrednictwem portu 3343. Jeśli istnieją przełączniki, zapory lub routery, które nie zostały prawidłowo skonfigurowane w celu zezwolenia na ten ruch, mogą wystąpić takie problemy.

7. Odświeżanie zasad zabezpieczeń protokołu IPsec może również spowodować ten problem. Konkretny problem polega na tym, że podczas aktualizacji zasad grupy protokołu IPSec wszystkie skojarzenia zabezpieczeń protokołu IPsec (SA) są rozdarte przez zaporę systemu Windows z zabezpieczeniami zaawansowanymi (WFAS). Mimo że tak się dzieje, wszystkie połączenia sieciowe są blokowane. W przypadku ponownego negocjowania skojarzeń zabezpieczeń, jeśli występują opóźnienia w wykonywaniu uwierzytelniania za pomocą usługi Active Directory, opóźnienia te (w przypadku zablokowania całej komunikacji sieciowej) blokują również pulsy klastra przed przejściem i spowodowanie, że monitorowanie kondycji klastra będzie wykrywać węzły tak, jakby nie odpowiadały w ramach 5-sekundowego progu.

8. Stare lub nieaktualne sterowniki kart sieciowych i/lub oprogramowania układowego. Czasami prosta błędna konfiguracja karty sieciowej lub przełącznika może również spowodować utratę pulsów.

9. Nowoczesne karty sieciowe i wirtualne karty sieciowe mogą mieć utratę pakietów. Można to śledzić, otwierając monitor wydajności i dodając licznik "Interfejs sieciowy\Odebrane pakiety odrzucone". Ten licznik jest skumulowany i zwiększa się tylko do momentu ponownego uruchomienia serwera. Wyświetlanie dużej liczby porzuconych pakietów może być znakiem, że odbierania na karcie sieciowej są ustawione zbyt niskie lub że serwer działa wolno i nie może obsłużyć ruchu przychodzącego. Każdy producent karty sieciowej wybiera, czy uwidocznić te ustawienia we właściwościach karty sieciowej, dlatego należy odwołać się do witryny sieci Web producenta, aby dowiedzieć się, jak zwiększyć te wartości i zalecane wartości powinny być używane. Jeśli korzystasz z oprogramowania VMware, w poniższym blogu omówiono to nieco bardziej szczegółowo, w tym o tym, jak powiedzieć, czy jest to problem, a także wskazuje na artykuł VMware na temat ustawień, które należy zmienić.

   Węzły usuwane z członkostwa w klastrze trybu failover w programie VMware ESX

Są to najczęstsze przyczyny rejestrowania tych zdarzeń, ale mogą być również inne przyczyny. Chodziło o to, aby dać ci wgląd w proces, a także dać pomysły na to, czego szukać. Niektóre z nich podniosą następujące wartości do ich maksymalnych wartości, aby spróbować zatrzymać ten problem.

Parametr	Wartość domyślna	Zakres
SameSubnetDelay	1000 milisekund	250–2000 milisekund
CrossSubnetDelay	1000 milisekund	250–4000 milisekund
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

Zwiększenie tych wartości do maksymalnej wartości może spowodować, że usunięcie zdarzenia i węzła zniknie, ale po prostu maskuje problem. Nie naprawia niczego. Najlepszą rzeczą do zrobienia jest znalezienie głównej przyczyny błędów pulsu i naprawienie go. Jedyną rzeczywistą potrzebą zwiększenia tych wartości jest scenariusz obejmujący wiele lokacji, w którym węzły znajdują się w różnych lokalizacjach i nie można przezwyciężyć opóźnienia sieci.