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

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

Отказоустойчивая кластеризация Windows Server обеспечивает высокий уровень доступности рабочих нагрузок, работающих в кластерах Azure Stack HCI и Windows Server. These resources are considered highly available if the nodes that host resources are up; however, the cluster generally requires more than half the nodes to be running, which is known as having quorum.

Quorum is designed to prevent split-brain scenarios that can happen when there's a partition in the network and subsets of nodes can't communicate with each other. Это может привести к тому, что оба подмножества узлов пытаются владеть рабочей нагрузкой и записывать на один и тот же диск, что может привести к многочисленным проблемам. Однако это предотвращается с помощью концепции кворума отказоустойчивой кластеризации, которая заставляет только одну из этих групп узлов продолжать работать, поэтому только одна из этих групп остается в сети.

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

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

• Cluster Quorum: This operates at the cluster level (i.e. you can lose nodes and have the cluster stay up)
• Pool Quorum: This operates on the pool level (i.e. you can lose nodes and drives and have the pool stay up). Пулы носителей предназначены для использования как в кластеризованных, так и некластеризованных сценариях, поэтому они имеют другой механизм кворума.

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

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

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

• If you have two nodes, a witness is required.
• If you have three or four nodes, witness is strongly recommended.
• Если у вас есть пять узлов или более, свидетель не нужен и не обеспечивает дополнительную устойчивость.
• If you have internet access, use a cloud witness.
• Если вы находитесь в ИТ-среде с другими компьютерами и общими папками, используйте следящий файловый ресурс.

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

When nodes fail, or when some subset of nodes loses contact with another subset, surviving nodes need to verify that they constitute the majority of the cluster to remain online. Если они не смогут это подтвердить, то уйдут в офлайн.

But the concept of majority only works cleanly when the total number of nodes in the cluster is odd (for example, three nodes in a five node cluster). Итак, что касается кластеров с четным числом узлов (например, четырьмя кластерами узлов)?

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

1. First, it can go up one by adding a witness with an extra vote. Для этого требуется настройка пользователя.
2. Or, it can go down one by zeroing one unlucky node's vote (happens automatically as needed).

Whenever surviving nodes successfully verify they're the majority, the definition of majority is updated to be among just the survivors. Это позволяет кластеру потерять один узел, а затем другой, а затем и т. д. Эта концепция общего числа голосов , адаптировавшихся после последовательных сбоев, называется динамическим кворумом.

Dynamic witness

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

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

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

• If you have an even number of nodes and no witness, one node gets its vote zeroed. Например, только три из четырех узлов получают голоса, поэтому общее количество голосов составляет три, а два выживших с голосами считаются большинством.
• If you have an odd number of nodes and no witness, they all get votes.
• If you have an even number of nodes plus witness, the witness votes, so the total is odd.
• If you have an odd number of nodes plus witness, the witness doesn't vote.

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

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

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

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

Examples

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

One node's vote is zeroed, so the majority vote is determined out of a total of 1 vote. Если узел, отличный от голосования, неожиданно исчезнет, выживший имеет 1/1, а кластер выживает. Если узел голосования неожиданно отключается, выживший имеет 0/1, и кластер останавливается. Если поддерживающий узел корректно выключен, голосование передается другому узлу, и кластер выживает. Поэтому важно настроить свидетеля.

• Может выжить один сбой сервера: пятьдесят процентов шансов.
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

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

Both nodes vote, plus the witness votes, so the majority is determined out of a total of 3 votes. Если любой узел выходит из строя, выживший имеет 2/3, а кластер выживает.

• Can survive one server failure: Yes.
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

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

All nodes vote, so the majority is determined out of a total of 3 votes. Если какой-либо узел исчезнет, выжившие — 2/3, и кластер выживает. Кластер становится двумя узлами без следящего сервера. На этом этапе вы находитесь в сценарии 1.

• Can survive one server failure: Yes.
• Может выжить один сбой сервера, а затем еще один: пятьдесят процентов шансов.
• Can survive two server failures at once: No.

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

Все узлы голосуют, поэтому свидетель изначально не голосует. The majority is determined out of a total of 3 votes. После одного сбоя кластер состоит из двух узлов с свидетелем, что соответствует сценарию 2. Итак, теперь голосуют два узла и свидетель.

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: No.

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

One node's vote is zeroed, so the majority is determined out of a total of 3 votes. После одного сбоя кластер становится тремя узлами, и вы находитесь в сценарии 3.

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Может выжить два сбоя сервера одновременно: пятьдесят процентов шансов.

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

All nodes votes and the witness votes, so the majority is determined out of a total of 5 votes. После одного сбоя вы находитесь в сценарии 4. После двух одновременных сбоев перейдите к сценарию 2.

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

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

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

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

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

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

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

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

• Cloud Witness - Blob storage in Azure accessible by all nodes of the cluster. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
• Файловый ресурс-свидетель — файловый ресурс SMB, настроенный на файловом сервере под управлением Windows Server. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
• Disk Witness - A small clustered disk that is in the Cluster Available Storage group. Этот диск является высокодоступным и может переключаться между узлами. Он содержит копию базы данных кластера. Дисковый свидетель не поддерживается с Storage Spaces Direct.

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

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

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

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

When drives fail, or when some subset of drives loses contact with another subset, surviving drives hosting metadata need to verify that they constitute the majority of the pool to remain online. Если они не смогут это подтвердить, то уйдут в офлайн. Пул — это объект, который становится оффлайн или остается подключённым, в зависимости от того, достаточно ли у него дисков для кворума (50% + 1). База данных кластера может быть +1, если сам кластер является кворатом.

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

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

Examples

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

Каждый из 16 дисков имеет один голос и узел два также имеет один голос (так как это владелец ресурса пула). The majority is determined out of a total of 16 votes. Если узлы три и четыре отключаются, выживающее подмножество содержит 8 дисков и владельца ресурса пула, имеющее 9 из 16 голосов. Таким образом, бассейн выжил.

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

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

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

• Can survive one server failure: Yes.
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

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

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

Next steps

• Настройка кворума и управление им
• Настроить свидетеля для кластера