Zachowanie trybu failover w klastrach z co najmniej trzema węzłami

W tym artykule opisano logikę, za pomocą której grupy kończą się niepowodzeniem z jednego węzła do innego, gdy istnieją co najmniej trzy elementy członkowskie węzła klastra.

Oryginalny numer KB: 299631

Podsumowanie

Ruch grupy może być spowodowany przez administratora, który ręcznie przenosi grupę lub przez awarię węzła lub zasobu. Miejsce, w którym grupa jest przenoszone, zależy od sposobu zainicjowania przenoszenia i od tego, czy jest ustawiona lista Preferowany właściciel.

Więcej informacji

Informacje o liście preferowanych właścicieli znajdują się w pliku Pomocy w obszarze "Klastry serwerów", w tym informacje o planowaniu i optymalizowaniu klastrów serwerów. Ten artykuł zawiera następujące cztery możliwe scenariusze:

1. Występuje błąd węzła lub zasobu, a lista preferowanych właścicieli jest ustawiona.
2. Występuje błąd węzła lub zasobu, a lista preferowanych właścicieli nie jest ustawiona.
3. Administrator ręcznie przenosi grupę do pozycji "Najlepsze możliwe", a lista preferowanych właścicieli jest ustawiona.
4. Administrator ręcznie przenosi grupę do pozycji "Najlepsze możliwe", a lista preferowanych właścicieli nie jest ustawiona.

Scenariusz 1

Jeśli węzeł lub zasób zakończy się niepowodzeniem i zdefiniowano listę preferowanych właścicieli, usługa klastrowania nie powiedzie się grupie do następnego dostępnego węzła na liście węzłów. Lista węzłów składa się z listy preferowanych właścicieli, a następnie pozostałych węzłów rozmieszczonych według ich identyfikatora węzła. Identyfikator węzła jest definiowany, gdy węzeł jest przyłączony do klastra lub jeśli węzeł jest eksmitowany lub ponownie dodawany.

Kolejność identyfikatorów węzła można wyświetlić, sprawdzając rejestr w kluczu \HKEY_LOCAL_MACHINE\Cluster\Nodes.

Załóżmy na przykład, że mamy sześć węzłów Klaster i że węzły zostały zainstalowane i przyłączone do klastra w następującej kolejności: NodeA, NodeB, NodeC, NodeD, NodeE i NodeF. Załóżmy, że grupa ma węzły NodeA, NodeC i NodeE wymienione jako preferowane właściciele.

Po wykonaniu tych informacji lista węzłów dla grupy będzie następująca:

1. NodeA — preferowany numer właściciela jeden
2. NodeC — preferowany właściciel numer dwa
3. NodeE — preferowany właściciel numer trzy
4. NodeB — drugi zainstalowany węzeł
5. NodeD — czwarty zainstalowany węzeł
6. NodeF — szósty zainstalowany węzeł

W tym scenariuszu, jeśli wystąpi awaria węzła lub awaria zasobu, a próg ponownego uruchomienia zostanie osiągnięty, cała grupa zakończy się niepowodzeniem w następnym węźle na liście węzłów. Jeśli na przykład węzeł NodeC zawierał zasób, który zakończył się niepowodzeniem, cała grupa nie powiedzie się NodeE. Nie udałoby się to węzłowi NodeA, mimo że jest on wymieniony jako pierwszy na liście preferowanych właścicieli. Jeśli środowisko NodeE zakończy się niepowodzeniem, grupa przełączy się w tryb failover do węzłaB, a nie do środowiska NodeA.

Scenariusz 2A

Jeśli zasób ulegnie awarii, a lista preferowanych właścicieli nie zostanie ustawiona, grupa jest zgodna z listą węzłów podobnie jak w scenariuszu 1. Lista węzłów jest kompilowana tylko z identyfikatora węzła. Po awarii węzła lub zasobu zasoby postępują zgodnie ze ścieżką w dół, która kończy się niepowodzeniem z kolejnego węzła na liście węzłów. Gdy osiągnie ostatni węzeł na liście węzłów, rozpoczyna się od pierwszego węzła na liście węzłów.

1. NodeA — po raz pierwszy zainstalowany węzeł

2. NodeC — drugi zainstalowany węzeł

3. NodeE — trzeci zainstalowany węzeł

4. NodeB — czwarty zainstalowany węzeł

5. NodeD — piąty zainstalowany węzeł

6. NodeF — szósty zainstalowany węzeł

Na przykład ta lista ma kolejność instalacji różnych węzłów klastra. Jeśli środowisko NodeE zakończy się niepowodzeniem, wszystkie grupy, które należały do niego, przełączą się w tryb failover do węzła NodeB, a nie do środowiska NodeF.

Scenariusz 2B

Jeśli węzeł ulegnie awarii, a lista preferowanych właścicieli nie zostanie ustawiona dla grupy w tym węźle, dostępny węzeł zostanie wybrany losowo, aby grupa została przeniesiona. Spowoduje to dystrybucję grup między dostępne węzły.

Scenariusz 3

Jeśli administrator klastra ręcznie wybierze pozycję Przenieś grupę i wybierze pozycję Najlepsze możliwe , a lista preferowanych właścicieli zostanie skonfigurowana, grupa będzie zawsze rozpoczynać się w górnej części listy węzłów. Podobnie jak w scenariuszu 1, lista węzłów składa się z listy preferowanych właścicieli i kolejności instalacji.

1. NodeA — preferowany numer właściciela jeden
2. NodeC — preferowany właściciel numer dwa
3. NodeE — preferowany właściciel numer trzy
4. NodeB — drugi zainstalowany węzeł
5. NodeD — czwarty zainstalowany węzeł
6. NodeF — szósty zainstalowany węzeł

W tym przykładzie po wybraniu opcji Best Possible grupa zawsze próbuje przejść do węzła NodeA. Jeśli grupa jest już w środowisku NodeA lub NodeA nie jest dostępna, grupa próbuje przejść do węzła NodeC. Jeśli grupa znajduje się w węźle NodeD, a administrator zdecyduje się przenieść ją do pozycji Best Possible, grupa zostanie przeniesiona do węzła NodeA. Jeśli węzły NodeA, NodeC lub NodeE nie są aktywne, wybrano losowo węzeł NodeB lub NodeF.

Scenariusz 4

Jeśli jako administrator klastra ręcznie wybierzesz pozycję Przenieś grupę i wybierzesz pozycję Najlepsze możliwe , a lista preferowanych właścicieli nie jest skonfigurowana, aktywny węzeł jest wybierany losowo do hostowania grupy. Bez skonfigurowanej listy preferowanych właścicieli możliwe jest, że grupa może przejść do węzła, na którym jest już uruchomionych kilka innych grup.

Zalecamy skonfigurowanie listy preferowanych właścicieli w dużym klastrze węzłów, jeśli obciążenie między węzłami jest znacznie inne lub jeśli węzły nie są jednorodne.

Uwaga 16.

Wyjątkiem od zachowania trybu failover wymienionego w tym miejscu jest grupa domyślna, która zawiera zasób kworum o nazwie Grupa klastrów. Grupa klastrów nie jest zgodne z typowym zachowaniem listy preferowanych właścicieli. Zamiast tego, jeśli właściciel zasobu Kworum zakończy się niepowodzeniem, nowy właściciel będzie poprzednią grupą, która pomyślnie posiadała zasób Kworum.

Właściwość publiczna AntiAffinityClassNames może również mieć wpływ na to, gdzie grupa przejdzie w tryb failover.