Общие сведения о кворуме кластеров и пулов
Область применения: Azure Stack HCI, версии 22H2 и 21H2; Windows Server 2022, Windows Server
Внимание
Azure Stack HCI теперь является частью Azure Local. Выполняется переименование документации по продукту. Однако старые версии Azure Stack HCI, например 22H2, будут продолжать ссылаться на Azure Stack HCI и не отражают изменение имени. Подробнее.
Отказоустойчивая кластеризация Windows Server обеспечивает высокий уровень доступности рабочих нагрузок, работающих в кластерах Azure Stack HCI и Windows Server. Эти ресурсы считаются высокодоступными, если работают узлы, в которых они размещены. Обычно требуется, чтобы в кластере в рабочем состоянии находилось более половины настроенных узлов. Такое состояние называется кворум.
Кворум предназначен для предотвращения сценариев разделения мозга , которые могут произойти, когда в сети и подмножества узлов не могут взаимодействовать друг с другом. Это может привести к тому, что оба подмножества узлов пытаются владеть рабочей нагрузкой и записывать на один и тот же диск, что может привести к многочисленным проблемам. Однако это предотвращается с помощью концепции кворума отказоустойчивой кластеризации, которая заставляет только одну из этих групп узлов продолжать работать, поэтому только одна из этих групп остается в сети.
Кворум ограничивает количество узлов, которые могут оказаться неработоспособными без прекращения работы кластера. Кворум предназначен для обработки сценария, когда возникает проблема с взаимодействием между подмножествами узлов кластера, чтобы несколько серверов не пытались одновременно размещать группу ресурсов и записывать на один и тот же диск одновременно. Имея эту концепцию кворума, кластер заставляет службу кластера остановиться в одном из подмножеств узлов, чтобы убедиться, что существует только один истинный владелец определенной группы ресурсов. Узлы, которые были остановлены, снова могут взаимодействовать с основной группой узлов и автоматически перезаходить в кластер и запускать свою службу кластера.
В Azure Stack HCI и Windows Server 2019 есть два компонента системы, которые имеют собственные механизмы кворума:
- Кворум кластера: это работает на уровне кластера (т. е. вы можете потерять узлы и остаться в состоянии кластера).
- Кворум пула: это работает на уровне пула (т. е. вы можете потерять узлы и диски и остаться в пуле). Пулы носителей разработаны таким образом, чтобы их можно было использовать как в кластеризованных, так и в некластеризованных сценариях. Поэтому у них есть отдельный механизм кворума.
Общие сведения о кворуме кластера
В таблице ниже приведен обзор результатов кворума кластера для каждого сценария:
Узлы сервера | Может пережить один сбой узла сервера | Может пережить один сбой узла сервера, а затем другой | Может пережить два одновременных сбоя узла сервера |
---|---|---|---|
2 | 50/50 | No | No |
2 + свидетель | Да | No | No |
3 | Да | 50/50 | No |
3 + свидетель | Да | Да | Нет |
4 | Да | Да | 50/50 |
4 + свидетель | Да | Да | Да |
5 и выше | Да | Да | Да |
Рекомендации по кворуму кластера
- При двух узлах свидетель является обязательным.
- При трех или четырех узлах использовать свидетель настоятельно рекомендуется.
- Если у вас есть пять узлов или более, свидетель не нужен и не обеспечивает дополнительную устойчивость.
- Если у вас есть доступ к Интернету, используйте облачный свидетель.
- Если вы находитесь в ИТ-среде с другими компьютерами и общими папками, используйте следящий файловый ресурс.
Как работает кворум кластера
Если происходит сбой узлов или определенное подмножество узлов теряет связь с другим подмножеством, сохранившимся в кластере узлам необходимо подтверждение того, что они составляют большинство от исходного числа узлов кластера, прежде чем продолжать работу. Если это невозможно гарантировать, все они переходят в автономный режим.
Но концепция большинства хорошо работает только при нечетном числе узлов в кластере (например, три работающих узла из пяти узлов кластера). Что же делать с теми кластерами, в которых число узлов четное (скажем, с кластером из четырех узлов)?
Есть два способа, которые позволяют кластеру получить нечетное общее число голосов:
- Во-первых, его можно увеличить, добавив свидетель с дополнительным голосом. Это настраивается пользователем вручную.
- Во-вторых, его можно уменьшить, обнулив один из голосов произвольного узла (выполняется автоматически по мере необходимости).
Всякий раз, когда выжившие узлы успешно проверяют, что они большинство, определение большинства обновляется, чтобы быть только выжившими. Это позволяет кластеру терять поочередно по одному серверу длительное время. Концепция адаптации общего числа голосов после каждого отдельного сбоя называется динамическим кворумом.
Динамический свидетель
Динамический свидетель автоматически изменяет вес своего голоса таким образом, чтобы общее число голосов всегда оставалось нечетным. Если число голосов всех узлов нечетное, свидетель не имеет собственного голоса. Если есть даже количество голосов, свидетель имеет голосование. Динамический свидетель значительно снижает риск сбоя кластера из-за сбоя следящего сервера. Кластер решает, нужно ли применять голос свидетеля, исходя из общего числа узлов с голосами, доступных на текущий момент в кластере.
Динамический кворум работает с динамическим свидетелем таким образом, как описано ниже.
Применение динамического кворума.
- Если в кластере работает четное число узлов и нет свидетеля, один из голосов обнуляется. Например, в голосовании участвуют только три узла из четырех, чтобы общее число голосов равнялось трем (нечетное число), и два оставшихся узла могли объявить себя большинством.
- Если в кластере работает нечетное число узлов и нет свидетеля, все голоса учитываются.
- Если в кластере работают четное число узлов и свидетель, голос свидетеля учитывается, чтобы общее число оставалось нечетным.
- Если в кластере работают нечетное число узлов и свидетель, голос свидетеля не учитывается.
Динамический кворум позволяет динамически присваивать узлам голоса, чтобы не потерять возможность установить большинство и позволить кластеру работать в конечном счете даже с одним узлом (последний оставшийся). Давайте рассмотрим пример кластера с четырьмя узлами. Предположим, что для кворума нужно три голоса.
В этом случае кластер окажется неработоспособным при потере двух узлов.
Но динамический кворум позволяет избежать такой ситуации. Общее число голосов для кворума будет переопределено на основе числа доступных узлов. Таким образом, при динамическом кворуме кластер остается в состоянии, даже если вы потеряете три узла.
Описанный выше сценарий применяется к обычному кластеру, для которого не включены Локальные дисковые пространства. Но при включении Локальных дисковых пространств кластер сможет выдержать только сбой двух узлов. Подробнее это описано в разделе о кворуме пула.
Примеры
Два узла без свидетеля
Голос одного из узлов обнуляется. Поэтому большинство определяется по результатам голосования одного узла. Если произойдет внезапный сбой на узле без права голоса, выживший получит один голос (при одном нужном) и кластер продолжит работу. Если произойдет внезапный сбой на узле с правом голоса, выживший получит 0 голосов (при одном нужном) и кластер прекратит работу. Если узел с правом голоса выключается корректно, его голос передается другому узлу и кластер продолжает работу. Поэтому так важно настроить для кластера свидетель.
- Может выжить один сбой сервера: пятьдесят процентов шансов.
- Может выжить один сбой сервера, а затем другой: нет.
- Может выжить два сбоя сервера одновременно: нет.
Два узла с свидетелем
Оба сервера и один свидетель участвуют в голосовании. Поэтому большинство определяется по результатам голосования трех узлов. Если произойдет сбой в любом из узлов, оставшиеся сохранят два голоса (из трех общих) и кластер продолжит работу.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: нет.
- Может выжить два сбоя сервера одновременно: нет.
Три узла без свидетеля
Оба сервера участвуют в голосовании. Поэтому большинство определяется по результатам голосования трех узлов. Если происходит сбой в любом из узлов, оставшиеся имеют два голоса (из трех общих) и кластер продолжает работу. Теперь у кластера только два узла без свидетеля. То есть мы вернулись к сценарию № 1.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем еще один: пятьдесят процентов шансов.
- Может выжить два сбоя сервера одновременно: нет.
Три узла с свидетелем
Все узлы голосуют. Поэтому у свидетеля изначально нет голоса. Большинство определяется по результатам голосования трех узлов. После первого сбоя в кластере остаются два узла и свидетель. То есть мы вернулись к сценарию № 2. Теперь оба узла и свидетель участвуют в голосовании.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: Да.
- Может выжить два сбоя сервера одновременно: нет.
Четыре узла без свидетеля.
Голос одного из узлов обнуляется. Поэтому большинство определяется по трем голосам. После одного сбоя в кластере остаются три узла. То есть мы вернулись к сценарию № 3.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: Да.
- Может выжить два сбоя сервера одновременно: пятьдесят процентов шансов.
Четыре узла с свидетелем
Все узлы и один свидетель участвуют в голосовании, поэтому большинство определяется по пяти голосам. После одного сбоя возникает сценарий № 4. После двух одновременных сбоев возникает сценарий № 2.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: Да.
- Может выжить два сбоя сервера одновременно: Да.
Пять узлов и более
В голосовании участвуют все узлы или все кроме одного, в зависимости от четности общего количества. Локальные дисковые пространства не может обрабатывать более двух узлов в любом случае, поэтому на этом этапе не требуется или не требуется следящий сервер.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: Да.
- Может выжить два сбоя сервера одновременно: Да.
Теперь, когда мы знаем, как работает кворум, перейдем к изучению типов свидетелей.
Типы свидетелей кворума
Отказоустойчивая кластеризация поддерживает свидетели трех типов.
- Облачный свидетель — хранилище BLOB-объектов в Azure, доступное всем узлам кластера. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
- Файловый ресурс-свидетель — общая папка на файловом сервере под управлением Windows Server. Поддерживает сведения о кластере в файле witness.log, но не хранит копии базы данных кластера.
- Диск-свидетель — небольшой кластеризованный диск, который находится в группе доступности кластера. Этот диск является высокодоступным и может выполнять отработку отказа между узлами. Он содержит копию базы данных кластера. Локальные дисковые пространства не поддерживают дисковый свидетель.
Общие сведения о кворуме пула
Мы только что говорили о кворуме кластера, который работает на уровне кластера. Теперь давайте рассмотрим кворум пула, который работает на уровне пула (т. е. вы можете потерять узлы и диски и остаться в пуле). Пулы носителей разработаны таким образом, чтобы их можно было использовать как в кластеризованных, так и в некластеризованных сценариях. Поэтому у них есть отдельный механизм кворума.
В таблице ниже приведен обзор результатов кворума пула для каждого сценария:
Узлы сервера | Может пережить один сбой узла сервера | Может пережить один сбой узла сервера, а затем другой | Может пережить два одновременных сбоя узла сервера |
---|---|---|---|
2 | Да | No | No |
2 + свидетель | Да | No | No |
3 | Да | No | No |
3 + свидетель | Да | No | No |
4 | Да | No | No |
4 + свидетель | Да | Да | Да |
5 и выше | Да | Да | Да |
Обзор кворума пула
Если диски завершаются сбоем или когда некоторые подмножества дисков теряют контакт с другим подмножеством, выжившие диски, на котором размещаются метаданные, должны убедиться, что они составляют большую часть пула, чтобы оставаться в сети. Если это невозможно гарантировать, все они переходят в автономный режим. Пул как общая сущность сохраняет или теряет работоспособность в зависимости от того, достаточно ли в нем сохранилось дисков для кворума (50 % + 1). База данных кластера может быть +1, если сам кластер является кворатом.
Но кворум пула имеет следующие важные отличия от кворума кластера:
- Пул выбирает подмножество дисков на узел для размещения метаданных
- Пул использует базу данных кластера для разрыва связей
- У пула нет динамического кворума
- Пул не реализует собственную версию удаления голосования
Примеры
Четыре узла с симметричным макетом
Каждый из 16 дисков имеет один голос, и узел 2 тоже имеет один голос (на правах владельца ресурса). Большинство определяется по результатам 16 голосов. Если, к примеру, узлы 3 и 4 будут отключены, у подмножества оставшихся сохраняются 8 дисков и среди них есть владелец ресурса пула, что дает им в общей сложности 9 из 16 голосов. Это означает, что пул продолжит работу.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: Да.
- Может выжить два сбоя сервера одновременно: Да.
Четыре узла с симметричным макетом и сбоем диска
Каждый из 16 дисков имеет один голос, и узел 2 тоже имеет один голос (на правах владельца ресурса). Большинство определяется по результатам 16 голосов. Сначала отключается диск 7. Если теперь узлы 3 и 4 будут отключены, у подмножества выживших сохраняются 7 дисков и среди них есть владелец ресурса пула, что дает им в общей сложности 8 из 16 голосов. Этот пул не сохраняет большинство и будет отключен.
- Может выжить один сбой сервера: Да.
- Может выжить один сбой сервера, а затем другой: нет.
- Может выжить два сбоя сервера одновременно: нет.
Рекомендации по кворуму пула
- Убедитесь, что все узлы в кластере симметричны (имеют одинаковое число дисков).
- Включите трехсторонняя зеркальная или двойная четность, чтобы можно было терпеть два сбоя узла и сохранять виртуальные диски в сети.
- Если будут отключены более двух узлов или два узла и диск на третьем узле, тома могут потерять доступ ко всем трем копиям данных и перейдут в автономный режим, то есть станут недоступны. Рекомендуется быстро вернуть серверы или заменить диски, чтобы обеспечить большую устойчивость для всех данных в томе.