Настройка отказоустойчивой кластеризации для Hyper-V (часть 7)

• Настройка отказоустойчивой кластеризации для Hyper-V (часть 9)

Введение

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

Чтобы кластер продолжал функционировать после отработки отказа, кластер должен поддерживать кворум. Это причудливый способ сказать, что большинство узлов в кластере должны продолжать функционировать (отсюда и термин «набор большинства узлов»). Это небольшая проблема, поскольку мы строим кластер из двух узлов, потому что, если один из двух узлов выйдет из строя, останется только одна заметка. Один единственный узел кластера не составляет большинства, если во всем кластере всего два узла.

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

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

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

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

Что ж, если бы два узла кластера были единственными участниками кластера, то да, ни один из узлов не мог бы претендовать на большинство в случае отказа. Однако вместо добавления третьего узла в кластер мы собираемся создать псевдоузел (это мой термин, а не Microsoft).

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

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

Местоположение файлового ресурса-свидетеля

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

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

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

Вывод

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

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

• Настройка отказоустойчивой кластеризации для Hyper-V (часть 8)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 9)