Windows 2016 Failover Cluster. Nano Server. Развертывание. Часть 3.

И так, мы выполнили все предварительные работы и подошли к нашей основной цели – развертыванию кластера.

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

Сразу надо оговориться, что при работе с кластерами на нано-серверах набор PowerShell команд сильно ограничен, поэтому все команды мы будем выполнять на отдельном сервере, а не в режиме удаленного выполнения на нано-сервере, как мы делали прежде.

Для валидации кластера выполним команду, показанную ниже.

11_2.jpg

Результаты валидации сохраняются на узлах кластера в папке C:\Windows\Cluster\Reports.

12_2.jpg

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

13_1.jpg

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

14_3.jpg

Мы видим, что кластер работоспособен, его узлы находятся в состоянии “Up” и созданы три кластерных сети, по количеству интерфейсов, присоединенных к узлам.

Далее нам необходимо навести некоторый порядок с кластерными сетями. Что я имею ввиду.

Посмотрите на результат выполнения команды, показанный ниже.

15_2.jpg

Что мне не нравится:

  • Название сетей не соответствует их предназначению, что в хаосе, который возникает во время нештатных событий, может привести к нерпавильным действиям администраторов.
  • Метрики сетей назначены автоматически, а мне это не нравится, посольку не всегда это так, как мы того сами желаем.
  • Сеть, выделенная под дисковый обмен (Cluster Network 1), при данной конфигурации будет использоваться для обмена сообщениями между узлами кластера, а это уже совсем плохо.

И так, начнем менять.

Переименуем сети.

16_2.jpg

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

17_3.jpg

Метрика влияет на порядок внутрикластерных коммуникаций, как-то обмен heartbeat-пакетами через порт 3343, редирект CSV траффика, и пр.

При включенном параметре AutoMetric ОС самостоятельно определяет какой вес (метрику) поставить сети. Алгоритм этот основан на нескольких свойствах сети, таких как скорость, режим работы, поддержка RDMA и пр. Лично я не всегда доверяю автоопределению и всегда перепроверяю и, если это необходимо, корректирую. Так я и поступлю в данном случае.

Минимальную метрику я присвою сети через, которую будут преимущественно передаваться heartbeat-пакеты, это сеть “Private”.

Значительно более высокую метрику присвою сети “Public”, через которую будут подсоединяться клиенты и, которая будет выступать в качестве резервной для heartbeat-пакетов.

Метрику сети “iSCSI” можно не менять, поскольку эту сеть мы исключим из кластерного обмена.

 19_1.jpg

Сделано.

Теперь исключим сеть “iSCSI” из кластерного обмена.

19_2.jpg

Теперь все красиво.

Сказать по правде, некоторые операции можно было выполнить из консоли управления кластером, подключившись удаленно, но PowerShell это красиво.

Ниже приведен внешний вид кластера в консоли удаленного управления.

20.jpg

 

И так, кластер развернут и настроен для работы, но…

...к нему не подключены диски, а как работать без них.

Вот об этом мы и поговорим в следующей нашей статье.

 

 Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)