Режимы кворума отказоустойчивого кластера Windows в группах доступности AlwaysOn

Обновлено 27.11.2021

Добрый день! Уважаемые читатели и гости одного из крупнейших IT порталов pyatilistnik.org. В прошлый раз я вас научил сбрасывать пароль SA в SQL сервере. Идем далее и сегодня хочу поговорить про режимы кворума в отказоустойчивом кластере Windows в группах доступности AlwaysOn MS SQL. Тут статья больше для себя, чтобы систематизировать знания и всегда их иметь под рукой.

SQL Server Always On - это гибкое решение для обеспечения высокой доступности (HA) и аварийного восстановления (DR). Он построен на отказоустойчивом кластере Windows, но нам не требуется разделяемое хранилище между узлами отказоустойчивого кластера. Каждая реплика поддерживает свое хранилище, системные базы данных, задания агента, логин, связанные серверы, учетные данные и пакеты услуг интеграции. До SQL Server 2012 мы использовали зеркальное отображение базы данных и доставку журналов для решений HADR.

SQL Server Always On заменяет зеркальное отображение базы данных и доставку журналов для решения HADR. Мы определяем группы доступности как единицу отказа вторичной реплики. Мы также определяем прослушиватель SQL для перенаправления всех подключений приложения к первичной реплике, независимо от того, какая реплика выполняет первичную роль.

Основными требованиями для настройки SQL Server Always On является отказоустойчивая кластеризация. Все участвующие узлы должны быть частью отказоустойчивого кластера. После настройки новой группы доступности она проверяет конфигурацию кворума отказоустойчивого кластера Windows. В этой статье я расскажу про кворум в кластере Windows и различные способы настройки голосования узлов.

Обзор кворума в отказоустойчивом кластере Windows

В отказоустойчивом кластере Windows у нас есть два или более узлов кластера, и эти узлы взаимодействуют друг с другом через порт UDP 3343. Предположим, из-за каких-то непредвиденных обстоятельств; узлы не могут общаться друг с другом. В этом случае все узлы кластера предполагают, что им необходимо перевести ресурсы в оперативный режим. Несколько узлов могут попытаться подключить один и тот же ресурс одновременно, но это невозможно. Эта ситуация называется ситуацией с разделенным мозгом (split brain), и мы никогда не хотим оказаться в такой ситуации. В этом случае мы можем столкнуться с проблемами повреждения данных.

Мы можем избежать сценария split brain в отказоустойчивом кластере Windows, разместив ресурсы на одном узле. В кластере Windows это достигается за счет реализации механизма голосования. Кворум проверяет минимальное количество голосов, необходимое для получения большинства и владения ресурсами.

Каждому узлу кластера разрешено отдать свой единственный голос. В каждом сценарии более половины избирателей должны быть в сети и иметь возможность общаться друг с другом. Если кластер не достигает большинства, ему не удается запустить службы кластера, и весь кластер отключается.

Шаги в обмене данными между узлами кластера заключаются в следующем.

• Узел кластера в отказоустойчивом кластере Windows пытается начать обмен данными со всеми другими узлами в группе кластера.
• После установления связи между доступными узлами они общаются друг с другом для достижения большинства.
• Если после голосования установлено большинство, ресурсы кластера переходят в оперативный режим.
• В случае отсутствия большинства службы кластера временно переводятся в автономный статус, и узлы ждут, пока другие узлы не подключатся к сети, чтобы можно было установить большинство.

Режимы кворума для отказоустойчивого кластера Windows

В предыдущем разделе я рассмотрел инструмент Windows Cluster Quorum. Основываясь на информации, мы можем установить следующую формулу для большинства в кластере.

Где N = количество узлов. Предположим, у нас есть четыре узла кластера, и на каждом узле кластера работает экземпляр SQL Server.

Согласно приведенной выше формуле, нам нужно три голоса, чтобы кластер оставался в сети.

А теперь представьте сценарий

• Узел 1 и узел 2 не могут обмениваться данными между узлом 3 и узлом 4. Узел 1 и узел 2 могут обмениваться данными друг с другом.
• Узел 3 и узел 4 не могут обмениваться данными между узлом 1 и узлом 2. Узел 3 и узел 4 могут обмениваться данными друг с другом.

В этом сценарии Узел 1 и Узел 2 пытается перевести в оперативный режим ресурсы, принадлежащие Узлу 3 и Узлу 4. Аналогичным образом, Узел 3 и Узел 4 пытается перевести в оперативный режим ресурсы, принадлежащие Узлу 1 и Узлу 2. Чтобы избежать этих сценариев, у нас есть различные конфигурации кворума, и мы должны тщательно настраивать конфигурацию кворума. Давайте обсудим эти режимы конфигурации кворума.

Режим настройки кворума большинства узлов в отказоустойчивом кластере Windows

В большинстве узлов каждый узел кластера вносит свой голос. Эта конфигурация кворума обрабатывает потерю половины узлов кластера после округления до меньшего числа. Это рекомендуемый метод для нечетного числа узлов кластера. Допустим, у нас есть три узла кластера, и один узел не может связываться с другими узлами. В этом случае, как показано на следующем изображении, у нас есть большинство узлов с двумя онлайн узлами.

Точно так же в случае кластера из пяти узлов он может обрабатывать отказы до двух узлов.

Режим настройки кворума большинства узлов и дисков в отказоустойчивом кластере Windows

В этом режиме конфигурации кворума каждый узел кластера получает один голос, и, кроме того, один голос поступает от кластерного диска (кворумного диска). Этот диск может быть диском небольшого размера с высокой доступностью и должен входить в группу кластера. Подходит для кластера с четными узлами. Диск кворума также хранит данные конфигурации кластера. Обычно администраторы Windows устанавливают размер диска кворума равным 1 ГБ.

Допустим, узел 1 и узел 2 не работают. У нас все еще есть три голоса, чтобы запустить кластерные сервисы.

Если еще один узел также выходит из строя, и у нас есть только один узел и один диск кворума для голосования, службы кластера в этом случае отключены.

Режим конфигурации кворума большинства узлов и общих файловых ресурсов в отказоустойчивом кластере Windows

Большинство узлов и общих файловых ресурсов аналогичны предыдущим режимам кворума большинства узлов и дисков. В этом случае мы заменяем диск кворума файловым хранилищем-свидетелем (FSW). FSW также подает единый голос, аналогичный диску кворума.

У нас может быть кластер Windows в разных регионах, и у нас может не быть общего хранилища между ними. Файловый ресурс-свидетель - это файловый ресурс, и мы можем настроить его на любом сервере, присутствующем в активном каталоге, и все узлы кластера должны иметь доступ к этому сетевому ресурсу. Он не содержит никаких данных конфигурации. Активный узел кластера блокирует общий файловый ресурс, а свидетель файлового ресурса-свидетеля содержит информацию о владельце.

Если файловый ресурс-свидетель недоступен, кластер остается в сети из-за большинства голосов.

Нет большинства: режим конфигурации кворума только для диска в отказоустойчивом кластере Windows

В этой конфигурации только диск-свидетель имеет право голоса, а узлы кластера не могут выступать в качестве избирателя. В этом случае диск-свидетель действует как единая точка отказа, и если он недоступен или поврежден, весь кластер выходит из строя. Это не рекомендуемая конфигурация кворума. На следующем изображении вы можете видеть, что если диск-свидетель недоступен, весь кластер отключен.

Режим настройки динамического кворума в отказоустойчивом кластере Windows

В Windows Server 2012 появилась новая функция "Динамический кворум". По умолчанию он включен. В этой конфигурации отказоустойчивый кластер Windows динамически вычисляет кворум в соответствии с состоянием активных избирателей. Если узел не работает, группа кластера не учитывает свой голос при вычислении кворума. Как только узел снова присоединяется к кластеру, ему назначается голос кворума. Мы можем увеличить или уменьшить количество голосов кворума, используя динамический кворум, чтобы кластер продолжал работать. Голоса кворума динамически корректируются, если сумма голосов меньше трех в конфигурации многоузлового кластера.

Мы должны добавить свидетеля к четному количеству узлов. Если конкретный узел не работает, вы можете уйти с четным числом узлов, что может стать проблемной ситуацией.

Windows Server 2012 R2 также включает динамический свидетель после настройки динамического кворума. С помощью этой функции голос Свидетелей динамически корректируется. Если у нас нечетное количество голосов кворума в конфигурации кластера, он не использует динамический свидетель кворума. В случае четного количества голосов динамический кворум также дает голос. Мы можем настроить либо файловый ресурс-свидетель, либо диск-свидетель как часть конфигурации динамического свидетеля. Мы также можем использовать Cloud-свидетель, начиная с Windows Server 2016.

Он работает по следующим концепциям.

• Для четного числа узлов каждый узел имеет голос и динамический голос свидетеля.
• Для нечетного числа узлов каждый узел имеет голос, но динамический голос свидетеля не учитывается. (Динамическое голосование свидетеля = 0)

Давайте разберемся с динамическим кворумом на примере. Предположим, у нас есть четыре узла в отказоустойчивом кластере.

Каждый узел может отдать голос, и нам требуется (4/2 + 1) три голоса для большинства. Допустим, узел 1 не работает. Кластер поднимется, так как у нас все еще есть три голоса, необходимых для большинства.

Теперь узел 2 также не работает. В этом случае кластер также останется в сети из-за динамического кворума с одним голосом.

В это время узел 3 также не работает. Используя динамический кворум, мы определяем большинство на основе доступных узлов. Благодаря этому у нас все еще может быть служба кластеров. Общее количество голосов , необходимых для кворума теперь определяется на основе количества узлов , доступных. Следовательно, с динамическим кворумом кластер будет работать, даже если вы потеряете три узла. Эта ситуация называется "последним человеком", в которой кластер также работает с одним узлом.

В этой статье мы изучили концепции режимов кворума отказоустойчивого кластера Windows, которые необходимы для конфигурации SQL Server Always on Availability Group. Вы должны учитывать плюсы и минусы каждого подхода в соответствии с вашей конфигурацией. Вы должны выбрать режимы кворума в соответствии с требованиями и протестировать аварийное переключение, чтобы избежать проблем в производственной среде. С вами был Иван Сёмин, автор и создатель IT блога Pyatilistnik.org.