ITsberg.ru

Администрирование, Exchange и остальное.

Отказоустойчивый кластер Hyper-V Server 2019

Сегодня опишу процесс построения отказоустойчивого кластера из двух серверов на основе Microsoft Hyper-V Server 2019 и с общим блочным хранилищем.

Упрощённое описание инфраструктуры кластера:

У каждого сервера по четыре сетевых интерфейса. Два сетевых интерфейса гигабитные — будут объединены в агрегированный канал, на котором будет создан виртуальный коммутатор Hyper-V, и через него же будет осуществляться доступ к кластеру.
Два других сетевых интерфейса (10 GB каждый) так же будут объединены агрегированный канал. Здесь будут построены виртуальные сети для доступа к общим блочным хранилищам, сеть Live Migration и Cluster Shared Volume. Доступ к этим сетям будет только у кластера.
Интерфейсы подключены к разным коммутаторам для обеспечения отказоустойчивости, сети изолированы друг от друга.

Почему именно Microsoft Hyper-V Server 2019? Эта ОС бесплатна, её функционала достаточно для обеспечения отказоустойчивого выполнения виртуальных машин, а что касается вопроса, какой гипервизор лучше — на эту тему в интернете навалом статей и нет однозначного ответа. Мне нравится работать с Hyper-V и его возможностей хватает для задач подавляющего большинство компаний.

После установки ОС на хост-сервер всплывает интересный нюанс: к Hyper-V Server 2019 не удастся подключиться по RDP, т.к. данный функционал Microsoft убрали из этой версии ОС. Для настройки у нас остаются четыре метода:
Прямой доступ к серверу.
Powershell Remoting (WinRM)
Приложение «Диспетчер серверов» от Microsoft
Windows Admin Center, тоже от Microsoft.
Так же есть несколько сторонних утилит, к примеру PsTools от Sysinternals.

Sconfig выглядит так, доступен на локальной консоли:

Конфигурирование серверов буду производить в Windows Admin Center.

Итак, что входит в предварительную настройку хоста при подготовке его к включению в кластер:
Настройка сетевых интерфейсов
Введение сервера в домен
Установка необходимых ролей и компонентов
Подключение сетевого хранилища (в нашем случае — iSCSI-диски)
Установка обновлений ОС

Все операции выполняются от имени учётной записи пользователя домена (Domain User), имеющей права администратора на обоих серверах.
Так же у этой учётной записи должны быть права Create Computer в том OU или контейнере, в котором находятся серверы, из которых будем собирать кластер.
Чаще всего данные операции выполняются пользователем с правами Domain Admin.

С самого начала необходимо настроить доступ к сети чтобы присоединить сервер к домену. Как собрать кластер без доменной инфраструктуры — описано в этой статье.

Т.к. sconfig, предлагаемый нам при логине, не имеет функционала для настройки агрегирования каналов, выходим из него в командную строку и запускаем powershell (последний пункт меню в sconfig — Exit to Command line). Powershell запускается из командной строки командой powershell. Даже скриншоты делать не буду чтобы описать запуск PS подробнее.

Получаем список сетевых адаптеров:

В данный момент поднято три интерфейса. Интерфейсы QLogic (ifIndex 3 и 9) — одногигабитные, их и будем объединять в «сеть доступа». Третий поднятый интерфейс — по нему я в данный момент подключен к серверу. После настройки сети доступа будет необходимо переключиться на управление через неё и тогда можно будет настраивать сеть кластера на интерфейсах Intel, по 10Gb каждый.

Первым делом объединяем интерфейсы QLogic в агрегированный канал, тип объединения будет LACP.

Теперь, если снова написать Get-NetAdapter, увидим новый сетевой интерфейс с именем LACP_LAN

Чтобы два раза не ходить, сразу на этот интерфейс повесим виртуальный коммутатор для клиентского доступа

Созданный VMSwitch появился в списке сетевых адаптеров — значит всё сделано правильно. Если у вас применяется разделение на виртуальные сети — указываем VLAN ID на созданном интерфейсе:

И задаём IP адрес и прочие настройки сети (тут важно не перепутать и указать правильный ifIndex, в нашем случае — 22)

Всё, можно переключаться на сеть доступа и работать уже через неё.
Вводим сервер в домен и переименовываем как нам необходим (если ещё не переименовали). Удобнее всего это делать через sconfig, там всё предельно просто. Из powershell sconfig вызывается командой «sconfig».
sconfig sconfig sconfig

Список сетевых интерфейсов теперь такой:

Интерфейсы 10Gb от Intel подключены в разные коммутаторы, на случай, если один из коммутаторов откажет. На их основе настроим агрегированный канал с несколькими виртуальными сетями для доступа к блочному дисковому хранилищу по протоколу iSCSI и для работы кластера.

В данной ситуации необходимо применить режим объединения SwitchIndependent, т.к. физические интерфейсы подключены к разным коммутаторам и управлять агрегированием будет операционная система, а не коммутатор. Но мы создали один виртуальный интерфейс, а нам необходимо минимум две раздельные сети для стабильного функционирования кластера (всё по заветам MS) и хотя-бы одна сеть для iSCSI. Не рекомендуется смешивать iSCSI и сеть доступа.
Разделять сети будем посредством VLAN. Т.е. нам необходимо взять виртуальный интерфейсLACP_CL, собранный на прошлом шаге, и собрать на нём ещё три виртуальных интерфейса, каждый в своём VLAN’е.

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

Создаём виртуальные интерфейсы с VLAN’ами.

Этой командой мы добавили виртуальный сетевой интерфейс с именем «LACP_CL_CSV» с VLAN’ом 11 к интерфейсу «LACP_CL». Делаем то же самое для для остальных VLAN’ов:

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

Выполняем командлет присвоения IP-адреса, внимательно подставляя свои адреса и номера интерфейсов:

Если где-то ошиблись, удалить созданные виртуальные адаптеры можно командой, где «VLAN» — номер VLAN.

Ставим роли и службы:

Install-WindowsFeature failover-clustering, rsat-clustering, rsat-role-tools, rsat-hyper-v-tools, hyper-v-powershell

Сначала необходимо перевести сервис iSCSI-инициатора в режим автоматического запуска и запустить его:

Для работы с дисковыми устройствами по протоколу iSCSI необходимо настроить так называемый iSCSI target portal:

Где:
TargetPortalAddress — IP адрес устройства, к которому подключаемся
ItiniatorPortalAddress — IP адрес сетевого интерфейса, которым смотрим в сеть iSCSI, т.е. IP-адрес интерфейса на Hyper-V сервере. В нашем случае это адрес интерфейса с именем LACP_CL_3200.
Посмотреть на доступные iSCSI-таргеты можно комадлетом

Подключаем доступные iSCSI-таргеты:

Либо можно вызвать обычную графическую консоль командой

Всё то же самое необходимо выполнить и на втором сервере.

Можно начинать работать с дисками.

Для того, чтобы диски можно было добавить в кластер как общее дисковое хранилище — диски должны быть отформатированы в NTFS и должны быть доступны на обоих серверах.
Нам понадобится минимум два диска — диск-свидетель кворума и диск для хранения виртуальных машин. Диск-свидетель может быть небольшим, хватит объёма в 1 GB.
Командлет Get-Disk возвращает список доступных дисков на данном сервере:

Начнём работу с диска номер 4, объёмом 1GB:

По необходимости то же самое делаем с остальными дисками. В результате получается такая картина:

Перезагружаем оба сервера.

Всё, основные вещи на серверах сделаны, можно приступать к сборке кластера.

Кластер будем собирать используя Failover Cluster Manager.

Если проводить настройки будем с какого-либо подходящего стороннего сервера — предварительно необходимо установить на него средства удалённого управления отказоустойчивым кластером: Failover Cluster Management Tools и Failover Cluster Module for Windows Powershell

Если будем настраивать с десктопной ОС — все необходимые модули ставятся во время установки средств удалённого администрирования сервера. Взять их можно на сайте Microsoft: https://www.microsoft.com/ru-RU/download/details.aspx?id=45520

Теперь можем запустить Failover Cluster Manager и заняться непосредственно сборкой кластера. Прежде всего необходимо проверить конфигурацию серверов, из которых мы всё это будем собирать. В Failover cluster Manager’е есть подходящий функционал — в разделе Management ссылочный пункт «Validate Cluster»:

Запускаем мастер проверки конфигурации, указываем наши серверы, в следующем пункте оставляем отметку Run all tests, жмём пару раз Next и ждём завершения тестов.

Важный момент: Если запустить проверку кластера на уже действующем кластере — все запущенные роли кластера аварийно остановятся, т.к. общие дисковые пространства будут отключены для проведения проверки.

После проведения проверки можно посмотреть отчёт, понятно — в отчёте не должно быть ошибок.
Отчёт записывается в текущий рабочий каталог, например C:\Users\UserName\AppData\Local\Temp

Когда удостоверились что конфигурация серверов выполнена правильно — можно приступать к непосредственному созданию кластера. Запускаем мастер создания кластера (Create Cluster), добавляем серверы.
На шаге Access Point for Administering the Cluster в поле Cluster Name указываем имя создаваемого кластера и чуть ниже в таблице указываем IP-адрес кластера. При создании кластера это имя будет зарегистрировано в AD как cluster computer object (или cluster name object, CNO).

Нажимаем далее и подтверждаем создание.

Созданный кластер должен появиться в списке слева в Failover Cluster Manager’е. Если этого не произошло — нажимаем Connect to Cluster и подключаемся к нему.

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

Начинаем с сетей кластера. Раскрываем древовидное представление в менеджере и выбираем Networks:

Такое представление не очень информативно, я предпочитаю переименовать все Cluster Network # в соответствии с их назначением.

Что означает столбец Cluster Use:
Cluster Only — эта сеть будет использоваться только для рабочих нагрузок кластера (CSV или Live Migration)
None — кластер не будет использовать эту сеть. Через эти сетевые адаптеры у нас подключены iSCSI диски с общих блочных хранилищ и за работу с ними отвечает операционная система.
Cluster and Clients — Эту сеть могут использовать как кластер, так и клиенты. Кластер данную сеть будет использовать для отслеживания доступности и работы нод кластера (т.н. HeartBeat-пакеты, ранее для этих целей было необходимо создавать отдельную сеть). Ну через эту же сеть будет осуществляться доступ к администрированию кластера и к виртуальным машинам, развёрнутым в кластере.

Теперь нужно настроить дисковые массивы и диск-свидетель кворума.

Идём в Storage — Disks и должны тут увидеть несколько дисков, подключенных и подготовленных на стадии подготовки серверов.

Если дисков в списке нет — их необходимо добавить. Нажимаем Add Disks и выбираем необходимые нам диски из списка предложенных. Если же система говорит что No disks Suitable for cluster disks were found… значит где-то ошиблись при подготовке дисков. Мастер проверки должен был об этом написать.
Диски необходимо отформатировать в NTFS, назначить им букву и добавить в список.

Диск-свидетель. Для него будем использовать диск объёмом 1GB, в моём случае это Cluster Disk 1.
Для настройки свидетеля необходимо выбрать сам кластер и в разделе Actions нажать More-Actions — Configure Cluster Quorum Settings… Снова откроется соответствующйи мастер.
В мастере на шаге Select Quorum Configuration Options выбираем Select the quorum witness. На следующем шаге — Configure a disk witness.
Так же есть возможность использовать свидетель кворума на основе сетевой папки общего доступа (необходимое условие — протокол SMB3.0, либо использовать «облачный» свидетель кворума).
Мы будем использовать диск-свидетель, полученный по iSCSI с дисковой полки.
На следующем шаге выбираем хранилище, на котором разместим свидетель кворума.
В списке дисков можно посмотреть что изменилось. Так же я переименовал диск свидетель, чтобы не путаться в дальнейшем (делается так же, как и с сетями кластера):

Теперь необходимо добавить общее хранилище (Cluster Shared Volume, CSV).
В разделе Disks выбираем диск, из которого хотим сделать CSV и жмём Add to Cluster Shared Volume.

После добавления диска в CSV на системном диске каждого хоста кластера в директории C:\ClusterStorage автоматически создаётся объект с именем Volume#, в нашем случае — Volume1. Опять же, для удобства его можно переименовать.

Ну вот вроде бы и всё что хотел рассказать о создании кластера Hyper-V на основе Microsoft Hyper-V Server 2019.
Не обязательно кластер собирать именно так, как я описал в этой статье, вариантов конфигурации множество, может отличаться конфигурация сети (разные варианты обеспечения отказоустойчивости, хоть вообще всё через один коммутатор соединяй — работать будет, но крайне не желательно так делать), тип общего дискового хранилища (SAN или NAS, разные протоколы) и .т.д. Я описал, по моему мнению, один из универсальных вариантов.

P.S. Как работать с кластером, в двух словах: ПКМ на пункт Roles — Configure Role, выбрать из списка Virtual Machine и выбрать необходимые ВМ, уже развёрнутые на одном из хостов кластера.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.