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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Динамический следящий сервер

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

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

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

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

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

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

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

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

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

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

Примеры

Два узла без следящего сервера

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

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

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

Два узла с следящий сервер

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

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

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

Три узла без следящего сервера

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

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

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

Три узла со следящий сервером

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

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

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

Четыре узла без следящего сервера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принцип работы кворума пула

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

Дальнейшие действия