Що робити, коли ваш кластер Always On втрачає кворум?

Я переглядав процедури нашої компанії щодо взаємодії з дією, і коли я шукав в Інтернеті рішення щодо кворуму, який завжди втрачає, завжди Я знайшов три сторінки в google результатах, перш ніж знайти першу публікацію SE на тему Кластеризація проти транзакційної реплікації та групи доступності, яка лише злегка торкається теми втраченого кворуму.

Хоча всі погоджуються на те, що втрата кворуму погана, і є кілька пропозицій щодо зменшення потенціалу, все-таки це може статися. Я шукаю гарну рецензовану відповідь на кращий шлях до відновлення після кворуму Always On, який втрачає.

AG засновані на кластеризації Windows. Застосовуються процедури WSFC щодо втрати кворуму.

• Відновлення аварійних ситуацій через форсований кворум
• Примушуйте кластер WSFC починати без кворуму

Після запуску WSFC ви можете примусити АГ, якщо потрібно. Виконайте примусове ручне відключення групи доступності :

Після примусового кворуму на кластері WSFC (примусовий кворум) вам потрібно примусити відмовитись від кожної групи доступності (з можливою втратою даних). Примусовий відхід необхідний, оскільки реальний стан значень кластера WSFC може бути втрачено. Однак ви можете уникнути втрати даних, якщо зможете примусити перемогтись на екземплярі сервера, на якому розміщувалася репліка, яка була первинною реплікою до вимушеного кворуму, або до вторинної репліки, яка була синхронізована до примусового кворуму. Для отримання додаткової інформації див. Потенційні способи уникнути втрати даних після примусу кворуму .

Що робити, коли ваш кластер AlwaysOn втрачає кворум?

Я потрапив у цю ситуацію, особливо з кластеризацією різних підмереж, що охоплюють різні країни (NY-LD-HK).

Як уникнути втрати кворуму в кластері з кількома підмережами?

• Змініть налаштування за замовчуванням кластеру на більш спокійний стан моніторингу, особливо налаштування серцебиття кластера за допомогою цього виправленняCrossSubnetDelay або CrossSubnetThresholdвластивості .
• Компанія AG використовує WSFC, який використовує підхід, заснований на кворумі, для визначення стану кластеру. Переконайтесь, що ви правильно обрали та налаштували кворум . Ця публікація в блозі заглиблюється в конфігурацію голосування кворуму за AlwaysON

• Речі змінюються на Windows Server 2016 із впровадженням кластерів, що знають про сайт, та хмарних свідків .

  Вузли в розтягнутих кластерах тепер можна згрупувати на основі їх фізичного розташування (сайту). Поінформованість щодо кластера щодо сайтів покращує ключові операції протягом життєвого циклу кластера, такі як поведінка з відмовою, політика розміщення, серцебиття між вузлами та поведінка кворуму.

  Cloud Witness - це новий тип свідчення кворуму Failover Cluster, який використовує Microsoft Azure як арбітражний пункт. Він використовує Microsoft Azure Blob Storage для читання / запису файлу blob, який потім використовується як арбітражний пункт у випадку роздільної здатності мозку.

Що робити, коли кворум втрачений?

• Якщо кластер знижується через незапланований відключення / аварія, тоді необхідне втручання вручну. Або адміністратору Windows, або адміністратору кластеру доводиться вручну примушувати кворум (посилаючись на відповідь @ Ремуса, що охоплює цю точку) та виводити залишилися вузли в Інтернеті.

Як завжди, щоб зробити Root Cause Analysis (RCA), збирайте ваші журнали журналів кластерів Windows, а для AlwaysON RCA - використовуйте журнали діагностики кластерів з відмовою від SQL Server . Ці файли в каталозі SQL Server Log мають такий вигляд: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Одного разу я брав участь у відключенні, коли наші дзеркальні сервери втратили зв’язок. Однією з речей, про яку слід турбуватися, є те, щоб ваші програми були вказані на один екземпляр. При відключенні мережі ви можете мати всі вузли кластера Always On, але не можете спілкуватися один з одним. Ви змушуєте відмовитись від вторинного, і тоді, поки відбувається відключення, у вас можуть бути два основних вузли, оскільки первинний первинний не буде знати про примусовий збій.

Залежно від розташування ваших серверів прикладних програм, їх конфігурації та їх здатності дістатися до SQL-сервера, то теоретично ви можете мати два вузли, вважаючи, що вони є первинними та змінюють дані одночасно. Після того, як ви виправите проблеми з мережею та вузли відновлять зв’язок, усі дані, змінені на первинному первинному, будуть перезаписані з вузла, до якого змушений був відмовитись. Це може призвести до втрати критичних даних.

Я бачив цю ситуацію один раз із SQL 2005 та дзеркальним відображенням. І ми вирішили не змушувати провалюватися і дозволити йому залишатися недосяжними. Причина полягає в тому, що в гіршому випадку, якщо нам довелося створити резервну копію та відновити, щоб перезапустити дзеркальне відображення, тоді це був би 2-денний процес для нас, коли ризик заповнення журналу транзакцій і неможливість розширення диска, на якому він сидів.