Свежий взгляд на кластеры Hyper-V (часть 1)

• Новый взгляд на кластеры Hyper-V (часть 2)
• Свежий взгляд на кластеры Hyper-V (часть 3)
• Свежий взгляд на кластеры Hyper-V (часть 4)
• Свежий взгляд на кластеры Hyper-V (часть 5)
• Свежий взгляд на кластеры Hyper-V (часть 6)
• Свежий взгляд на кластеры Hyper-V (часть 7)
• Свежий взгляд на кластеры Hyper-V (часть 8)

Введение

Некоторое время назад я написал серию статей, описывающих процесс настройки Hyper-V для использования отказоустойчивого кластера Windows. Как вы понимаете, многое изменилось с тех пор, как я написал эту серию статей. На самом деле Microsoft внесла ряд улучшений как в Hyper-V, так и в отказоустойчивую кластеризацию в Windows Server 2012 R2. В связи с этим я решил воспользоваться возможностью, чтобы по-новому взглянуть на кластеры Hyper-V.

Чьи улучшения

Как упоминалось ранее, Microsoft внесла огромное количество улучшений в отказоустойчивую кластеризацию в Windows Server 2012 R2. На самом деле улучшений так много, что я мог бы легко написать целую серию статей, посвященных исключительно новым функциям. Однако я хочу начать с некоторых улучшений, внесенных Microsoft в отношении модели кворума.

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

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

В Windows Server 2012 Microsoft представила новую функцию, называемую динамическим кворумом. Основная идея динамического кворума заключается в том, что состояние узла учитывается при голосовании кворума. Если узел отключается (или выходит из строя), он теряет свой голос. Если узел возвращается в сеть, он восстанавливает свой голос кворума. Преимущество этой модели заключается в том, что кластер может динамически регулировать количество голосов, необходимое для сохранения кворума в кластере.

Хотя функция динамического кворума была очень долгожданным улучшением, Microsoft внесла некоторые дополнительные улучшения в Windows Server 2012 R2. Одним из таких улучшений стало введение динамического свидетеля. Основная идея здесь заключается в том, что если отказоустойчивый кластер Windows Server 2012 R2 настроен на использование динамического кворума (по умолчанию), то голосование свидетеля также становится динамическим. Наличие динамического свидетеля имеет два значения.

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

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

Учитывая изменения, которые Microsoft внесла в модель кворума, легко задаться вопросом, действительно ли необходим следящий сервер. Однако Microsoft рекомендует, чтобы каждый кластер Windows Server 2012 R2 был снабжен свидетелем кворума.

Как вы, вероятно, уже знаете, работа сервера-свидетеля заключается в том, чтобы действовать как средство разрешения конфликтов в ситуациях, когда в отказоустойчивом кластере имеется разделение узлов 50/50. Тем не менее, Microsoft реализовала функцию автоматического разрешения конфликтов, которая может динамически регулировать подсчет голосов, чтобы всегда было нечетное количество голосов (чтобы избежать ужасного разделения узлов 50/50).

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

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

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

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

Имея это в виду, давайте представим, что сервер-свидетель был отключен для обслуживания. В такой ситуации кластер по-прежнему будет поддерживать кворум, поскольку имеется множество функциональных узлов. Однако, поскольку в этой ситуации Windows Server 2012 R2 использует динамический следящий сервер, операционная система сервера удаляет голос следящего сервера. Это означает, что весь кластер теперь имеет восемь голосов кворума (по одному на каждый узел кластера).

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

Стремясь исключить возможность разделения 50/50, Windows удаляет голос кворума из случайного узла кластера. Это означает, что несмотря на то, что восемь узлов кластера функционируют, одна из площадок имеет четыре голоса, а другая — только три. Это означает, что в случае сбоя канала WAN сайт с четырьмя голосами сохранит кворум и продолжит функционировать.

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

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

Вывод

Как видите, многое изменилось в модели кворума отказоустойчивой кластеризации. Во второй части этой серии статей я расскажу о некоторых изменениях, внесенных Microsoft.

• Новый взгляд на кластеры Hyper-V (часть 2)
• Свежий взгляд на кластеры Hyper-V (часть 3)
• Свежий взгляд на кластеры Hyper-V (часть 4)
• Свежий взгляд на кластеры Hyper-V (часть 5)
• Свежий взгляд на кластеры Hyper-V (часть 6)
• Свежий взгляд на кластеры Hyper-V (часть 7)
• Свежий взгляд на кластеры Hyper-V (часть 8)