Поделиться через


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

Область применения: Azure Stack HCI, версии 22H2 и 21H2; Windows Server 2022, Windows Server

Отказоустойчивая кластеризация Windows Server обеспечивает высокий уровень доступности рабочих нагрузок, работающих в кластерах Azure Stack HCI и Windows Server. Эти ресурсы считаются высокодоступными, если узлы, на которых размещаются ресурсы, работают; однако кластеру обычно требуется, чтобы более половины узлов были в работе, что называется кворумом.

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

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

В Azure Stack HCI и Windows Server 2019 есть два компонента системы, которые имеют собственные механизмы кворума:

  • Кворум кластера: кворум работает на уровне кластера (т. е. даже при потере узлов кластер продолжает работать).
  • Кворум пула: это работает на уровне пула (т. е. вы можете потерять узлы и диски, а пул останется рабочим). Пулы носителей предназначены для использования как в кластеризованных, так и некластеризованных сценариях, поэтому они имеют другой механизм кворума.

Обзор кворума кластера

В таблице ниже приведен обзор результатов кворума кластера для каждого сценария:

Узлы сервера Может пережить один сбой узла сервера Может пережить один сбой узла сервера, а затем другой Может пережить два одновременных сбоя узла сервера
2 50/50 нет нет
2 + свидетель Да нет нет
3 Да 50/50 нет
3 + свидетель Да Да нет
4 Да Да 50/50
4 + свидетель Да Да Да
5 и выше Да Да Да

Рекомендации кворума кластера

  • Если у вас есть два узла, требуется свидетель.
  • Если у вас есть три или четыре узла, настоятельно рекомендуется использовать следящий сервер.
  • Если у вас есть пять узлов или более, свидетель не нужен и не обеспечивает дополнительную устойчивость.
  • Если у вас есть доступ к Интернету, используйте облачный свидетель.
  • Если вы находитесь в ИТ-среде с другими компьютерами и общими папками, используйте следящий файловый ресурс.

Как работает кворум кластера

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

Но концепция большинства четко работает, если общее количество узлов в кластере нечетно (например, три узла в кластере из пяти узлов). Итак, что касается кластеров с четным числом узлов (например, четырьмя кластерами узлов)?

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

  1. Во-первых, оно может повыситься, добавив свидетеля с дополнительным голосом. Для этого требуется настройка пользователя.
  2. Кроме того, может снизиться, обнулив голос одного из неудачливых узлов (происходит автоматически при необходимости).

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

Динамический свидетель

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

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

Динамическое поведение кворума

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

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

В этом случае кластер перестал бы работать, если вы потеряете два узла.

Схема с четырьмя узлами кластера, каждый из которых получает голос.

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

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

Приведенный выше сценарий применяется к обычному кластеру, в котором не активирована функция Storage Spaces Direct. Однако, когда включено Storage Spaces Direct, кластер может поддерживать только два сбоя узлов. Это объясняется больше в разделе кворума пула.

Примеры

Два узла без свидетеля

Голос одного узла аннулирован, поэтому большинство голосов определяется из всего 1 голоса. Если узел, отличный от голосования, неожиданно исчезнет, выживший имеет 1/1, а кластер выживает. Если узел голосования неожиданно отключается, выживший имеет 0/1, и кластер останавливается. Если поддерживающий узел корректно выключен, голосование передается другому узлу, и кластер выживает. Поэтому важно настроить свидетеля.

Кворум объясняется на примере случая с двумя узлами без свидетеля.

  • Может выжить один сбой сервера: пятьдесят процентов шансов.
  • Может пережить один сбой сервера, а затем другой: Нет.
  • Может выжить два сбоя сервера одновременно: нет.

Два узла с свидетелем

Оба узла голосуют, свидетель тоже голосует, поэтому большинство определяется из 3 голосов. Если любой узел выходит из строя, выживший имеет 2/3, а кластер выживает.

Объяснение кворума в случае двух узлов с участием свидетеля.

  • Может выжить один сбой сервера: Да.
  • Может пережить один сбой сервера, а затем другой: Нет.
  • Может выжить два сбоя сервера одновременно: нет.

Три узла без свидетеля

Все узлы голосуют, поэтому большинство определяется из общего числа 3 голосов. Если какой-либо узел исчезнет, выжившие — 2/3, и кластер выживает. Кластер становится двумя узлами без следящего сервера. На этом этапе вы находитесь в сценарии 1.

Кворум в системе из трех узлов без использования свидетеля.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем еще один: пятьдесят процентов шансов.
  • Может выжить два сбоя сервера одновременно: нет.

Три узла с свидетелем

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

Кворум объяснил в случае с тремя узлами с свидетелем.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем другой: Да.
  • Может выжить два сбоя сервера одновременно: нет.

Четыре узла без свидетеля

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

Объяснение кворума в случае с четырьмя узлами без свидетеля.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем другой: Да.
  • Может выжить два сбоя сервера одновременно: пятьдесят процентов шансов.

Четыре узла с свидетелем

Все голоса узлов и свидетельские голоса, таким образом большинство определяется из общего числа в 5 голосов. После одного сбоя вы находитесь в сценарии 4. После двух одновременных сбоев перейдите к сценарию 2.

Кворум объясняется на примере четырех узлов со свидетелем.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем другой: Да.
  • Может выжить два сбоя сервера одновременно: Да.

Пять узлов и более

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

Объяснение кворума в случае пяти узлов и более.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем другой: Да.
  • Может выжить два сбоя сервера одновременно: Да.

Теперь, когда мы понимаем, как работает кворум, давайте рассмотрим типы свидетелей кворума.

Типы свидетеля кворума

Отказоустойчивая кластеризация поддерживает три типа свидетелей кворума:

  • Cloud Witness — хранилище BLOB-объектов в Azure, доступное всеми узлами кластера. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
  • Файловый ресурс-свидетель — файловый ресурс SMB, настроенный на файловом сервере под управлением Windows Server. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
  • Диск-свидетель — небольшой кластеризованный диск, который находится в группе доступного хранилища кластера. Этот диск является высокодоступным и может переключаться между узлами. Он содержит копию базы данных кластера. Дисковый свидетель не поддерживается с Storage Spaces Direct.

Обзор кворума пула

Мы только что говорили о кворуме кластера, который работает на уровне кластера. Теперь давайте рассмотрим кворум пула, который работает на уровне пула (т. е. вы можете потерять узлы и диски, но пул продолжит функционировать). Пулы носителей предназначены для использования как в кластеризованных, так и некластеризованных сценариях, поэтому они имеют другой механизм кворума.

В таблице ниже приведен обзор результатов кворума пула для каждого сценария:

Узлы сервера Может пережить один сбой узла сервера Может пережить один сбой узла сервера, а затем другой Может пережить два одновременных сбоя узла сервера
2 Да нет нет
2 + свидетель Да нет нет
3 Да нет нет
3 + свидетель Да нет нет
4 Да нет нет
4 + свидетель Да Да Да
5 и выше Да Да Да

Как работает кворум пула

Если диски выходят из строя или когда некоторые подмножества дисков теряют контакт с другим подмножеством, выжившие диски, на которых размещаются метаданные, должны убедиться, что они составляют большую часть пула, чтобы оставаться в рабочем состоянии. Если они не смогут это подтвердить, то уйдут в офлайн. Пул — это объект, который становится оффлайн или остается подключённым, в зависимости от того, достаточно ли у него дисков для кворума (50% + 1). База данных кластера может быть +1, если сам кластер является кворатом.

Но кворум пула работает по-разному от кворума кластера следующим образом:

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

Примеры

Четыре узла с симметричным расположением

Каждый из 16 дисков имеет один голос и узел два также имеет один голос (так как это владелец ресурса пула). Большинство определяется в общей сложности 16 голосов. Если узлы три и четыре отключаются, выживающее подмножество содержит 8 дисков и владельца ресурса пула, имеющее 9 из 16 голосов. Таким образом, бассейн выжил.

Кворум пула 1.

  • Может выжить один сбой сервера: Да.
  • Может выжить один сбой сервера, а затем другой: Да.
  • Может выжить два сбоя сервера одновременно: Да.

Четыре узла с симметричной конфигурацией и сбоем диска

Каждый из 16 дисков имеет один голос, и узел 2 также имеет один голос, поскольку он является владельцем ресурса пула. Большинство определяется в общей сложности 16 голосов. Во-первых, диск 7 опускается вниз. Если узлы три и четыре выходят из строя, выживающее подмножество содержит 7 дисков и владельцем ресурса пула, что составляет 8/16 голосов. Таким образом, пул не набирает большинство и теряет позиции.

Кворум пула 2.

  • Может выжить один сбой сервера: Да.
  • Может пережить один сбой сервера, а затем другой: Нет.
  • Может выжить два сбоя сервера одновременно: нет.

Рекомендации для кворума пула

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

Дальнейшие шаги