Co zrobić, gdy klaster Always On traci kworum?

Przeglądałem procedury DR firmy i kiedy szukałem w Internecie rozwiązań dla kworum Always On Cluster, które można porównać. Byłem trzy strony w wynikach Google, zanim znalazłem pierwszy post SE na temat Klastrowanie vs. replikacja transakcyjna vs. grupy dostępności, które tylko lekko dotykają tematu utraconego kworum.

Chociaż wszyscy zgadzają się, że utrata kworum jest zła i istnieją pewne sugestie dotyczące zmniejszenia potencjału, nadal może się zdarzyć. Szukam dobrej recenzowanej odpowiedzi na najlepszą ścieżkę odzyskiwania po utracie kworum przez klaster Always On.

AG oparte są na klastrowaniu systemu Windows. Obowiązują procedury WSFC dotyczące utraty kworum.

• Odzyskiwanie po awarii WSFC poprzez wymuszone kworum
• Wymuś uruchomienie klastra WSFC bez kworum

Po uruchomieniu WSFC możesz w razie potrzeby zmusić AG. Wykonaj wymuszone ręczne przełączanie awaryjne grupy dostępności :

Po wymuszeniu kworum w klastrze WSFC (kworum wymuszone) należy wymusić przełączenie awaryjne każdej grupy dostępności (z możliwą utratą danych). Wymuszanie przełączania awaryjnego jest wymagane, ponieważ rzeczywisty stan wartości klastra WSFC mógł zostać utracony. Można jednak uniknąć utraty danych, jeśli można wymusić przełączenie awaryjne na instancję serwera, na której znajduje się replika będąca repliką podstawową przed wymuszeniem kworum lub na replikę wtórną, która została zsynchronizowana przed wymuszeniem kworum. Aby uzyskać więcej informacji, zobacz Potencjalne sposoby uniknięcia utraty danych po wymuszeniu kworum .

Co zrobić, gdy klaster AlwaysOn traci kworum?

Byłem w takiej sytuacji, szczególnie z klastrowaniem wielu podsieci obejmującym różne kraje (NY-LD-HK).

Jak uniknąć utraty kworum w klastrze z wieloma podsieciami?

• Zmień domyślne ustawienie klastra na bardziej swobodny stan monitorowania, zwłaszcza ustawienia pulsu klastra za pomocą CrossSubnetDelaylub tę CrossSubnetThresholdwłaściwość dzięki tej poprawce .
• AG używa WSFC, który inturn wykorzystuje podejście oparte na kworum do określania kondycji klastra. Upewnij się, że właściwie wybierasz i konfigurujesz kworum . Ten post na blogu omawia konfigurację głosowania w Kworum dla AlwaysON

• Sytuacja zmienia się w systemie Windows Server 2016 wraz z wprowadzeniem klastrów rozpoznających witryny i usługi chmurowej .

  Węzły w rozciągniętych klastrach można teraz grupować na podstawie ich fizycznej lokalizacji (witryny). Świadomość witryny klastra usprawnia kluczowe operacje podczas cyklu życia klastra, takie jak zachowanie przełączania awaryjnego, zasady rozmieszczania, bicie serca między węzłami i zachowanie kworum.

  Cloud Witness to nowy typ kworum klastra trybu failover, który wykorzystuje Microsoft Azure jako punkt arbitrażu. Używa Microsoft Azure Blob Storage do odczytu / zapisu pliku blob, który jest następnie używany jako punkt arbitrażowy w przypadku rozdzielenia mózgu.

Co zrobić, gdy utracone zostanie Kworum?

• Jeśli klaster ulegnie awarii z powodu nieplanowanej awarii / awarii, wymagana jest ręczna interwencja. Zarówno administrator systemu Windows, jak i administrator klastra musi ręcznie wymusić kworum (łącząc się z odpowiedzią @ Remus, ponieważ obejmuje to ten punkt) i wprowadzić pozostałe węzły do ​​trybu online.

Jak zawsze, aby wykonać RCA Cause Analysis (RCA), zbierz dzienniki klastra systemu Windows, w przypadku AlwaysON RCA - użyj dzienników diagnostycznych klastra pracy awaryjnej programu SQL Server . Te pliki w katalogu SQL Server Log mają następujący format: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Kiedyś byłem zaangażowany w awarię, w której nasze serwery lustrzane straciły łączność. Jedną z rzeczy, o które należy się martwić, jest upewnienie się, że aplikacje są skierowane do pojedynczego wystąpienia. W przypadku awarii sieci możesz mieć wszystkie węzły klastra Always On, ale nie można się ze sobą komunikować. Wymuszasz przełączenie awaryjne na pomocnicze, a następnie, dopóki wystąpi awaria, możesz mieć dwa główne węzły, ponieważ pierwotny główny nie będzie wiedział o wymuszonym przełączeniu awaryjnym.

W zależności od lokalizacji serwerów aplikacji, ich konfiguracji i możliwości dotarcia do serwera SQL, teoretycznie możesz mieć dwa węzły, które uważają, że są one podstawowe, i jednocześnie zmieniają dane. Po rozwiązaniu problemów z siecią i wznowieniu połączenia z węzłami wszystkie dane zmienione na pierwotnym serwerze podstawowym zostaną zastąpione z węzła, do którego zmuszono przełączenie awaryjne. Może to spowodować utratę kluczowych danych.

Raz widziałem tę sytuację z SQL 2005 i tworzeniem kopii lustrzanych. Postanowiliśmy nie wymuszać przełączania awaryjnego i pozostawić go nieosiągalnym. Powodem jest to, że w najgorszym przypadku, gdybyśmy musieli wykonać kopię zapasową i przywrócić, aby ponownie uruchomić kopię lustrzaną, byłby to dla nas proces dwudniowy z ryzykiem zapełnienia dziennika transakcji i niemożności rozszerzenia dysku, na którym siedział.