Настройка кластера windows server 2019

Обновлено: 04.07.2024

Как бы не ругали пользователи Windows 10 но это самая популярная ОС. Серверные ОС Windows Server также не имеют аналогов. Это что касается относительной простоты настройки и дружелюбности к пользователю. Каждый меня поймет кто хоть когда то пытался соорудить нечто подобное Active Directory на Linux. Это небольшое отступление. Но сегодня я хочу рассказать насколько проста установка и настройка Microsoft Hyper-V Server 2019. Это бесплатный гипервизор от Microsoft.

Я долго сравнивал разные бесплатные гипервизоры (Proxmox, VMWare). Мне хотелось чтобы была возможность управлять сервером через WEB и консоль. Рассматривал Proxmox, но совсем не тривиальная настройка меня остановила.

Про Microsoft Hyper-V Server я знал, но в нем не было WEB интерфейса для управления. Хотя подкупал RDP доступ, Hype-V Manager и возможность использовать Powershell со всем его огромным функционалом.

Буквально на днях узнал о существовании WEB консоли для управления WIndows серверами Windows Admin Center. Этот факт подтолкнул меня к установке бесплатного гипервизора от Microsoft последней версии.

Установка Microsoft Hyper-V Server 2019

Скачанный ISO файл необходимо записать на USB Flash. Для этих целей я использую Rufus. Используйте накопитель с минимальным объемом не менее 4 Гб.


  • Устройство: выбрать ваш Flash накопитель
  • Метод загрузки: Диск или ISO нажать кнопку ВЫБРАТЬ и указать ISO образ Hyper-V 2019
  • Файловая система: NTFS

Нажать СТАРТ и дождаться окончания записи образа на Flash накопитель.


После окончания записи на флешку можно приступить к установке системы.

Установка системы проста как любой Windows, на этом заострять внимание я не буду.

Настройка Microsoft Hyper-V Server 2019

Пройдя авторизацию в Hyper-V Server возникнет окошко Server Configuration с основными настройками сервера. Для использования каждого пункта нажимаем соответствующую цифру и далее Enter.


Проведем первоначальные настройки сервера с помощью консоли Server Configuration

Изменим имя компьютера на WHS19. Включим удаленное управление Remote Management и Remote Desktop. Windows Update Settings я оставляю в изначальном состоянии DownloadOnly. Меняю часовой пояс на свой и настройки телеметрии ставлю Secutiry. Сетевые настройки приходят по DHCP (не забываем сделать резервацию) или вручную. После измененных настроек рекомендую перезагрузить сервер.

Если по чистой случайности вы закрыли оба окна (консоль cmd и Server Configuration) можно воспользоваться сочетанием клавиш Ctrl+Shift+Esc и вызвать диспетчер задач.



Настройка дисков

В моём сервере установлено 3 диска. На одном диске установлена система, два других под виртуальные машины и резервные копии. Запустим Powershell из консоли cmd.

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


Создадим новый раздел на диске и присвоим ему букву D.

Отформатируем диск под файловую систему NTFS


Создаем новый раздел на диске HGST для резервных копий и присвоим диску букву E

Форматируем диск E


Место хранения виртуальных машин

По умолчанию система сохраняет новые виртуальные машины на диск C. Изменим путь сохранения на диск D

Создаем папку для хранения виртуальных машин и дисков


Укажем системе куда сохранять настройки и диски виртуальных машин

Проверим что все получилось


Настройка виртуального коммутатора Hyper-V

Нам необходимо создать виртуальный коммутатор который будет связан с сетевой картой сервера Hyper-V. Он будет получать сетевые адреса также по DHCP как и остальные физические машины в сети.

Проверим поддерживает ли наша сетевая карта технологию SR-IOV (Single Root Input/Output Virtualization). Данная технология виртуализации предоставляет виртуальным машинам прямой доступ к части аппаратных возможностей сетевой карты.

Если данная технология поддерживается, необходимо ее включить командлетом Enable-NetAdapterSriov. После создания виртуального коммутатора включить данную технологию уже не получится.

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


Создадим новый виртуальный коммутатор с именем External. Он будет использоваться как внешний сетевой адаптер получающий адреса по DHCP. При создании включим функцию совместного использования виртуального коммутатора и сетевой карты с виртуальной машиной.


Просмотреть детальную информацию по сетевым настройкам можно так

Enhanced Session Mode

Включение функции Enhanced Session Mode позволит подключиться к консоли виртуальной машины используя RDP соединение. С той лишь разницей что подключение будет не к самой виртуальной машине а через средства интеграции гипервизора. Данный метод позволяет подключаться к виртуальной машине даже с отсутствующей сетевой картой. Для себя я вижу удобство именно в подключении к виртуальным машинам с изолированной сетью. Нет необходимости запускать консоль Hyper-V, все можно сделать через RDP.

Основные преимущества Enhanced Session Mode

  • можно выбрать произвольное разрешение экрана
  • использование локальных принтеров
  • перенаправление USB устройств
  • подключение дисков
  • общий буфера обмена
  • работа с аудиоустройствами
  • проброс смарт-карт
  • поддержка остальных plug-and-play устройств

Включим данный режим сразу для всего сервера


Удаленное управление Microsoft Hyper-V Server 2019

Удаленное управление Hyper-V сервером доступно многими средствами. Среди них консоль Hyper-V Manager, Powershell, Windows Admin Center, MMC. Для удаленного управления сервером Hyper-V необходимо произвести настройки на сервере и на каждом клиенте с которого будет подключение. Настройку клиента буду проводить на Windows 10 Pro (минимально необходимая версия).

Если сервер используется в сети с доменом, то необходимо добавить запись типа A в DNS сервер (обычно это контроллер домена). В случае рабочей группы просто добавляем имя сервера Hyper-V в файл C:\Windows\System32\drivers\etc\hosts. В моем случае запись будет выглядеть так:

Вначале идет IP адрес сервера: 172.16.169.49 далее через пробел имя WHS19. В случае использования файла hosts не забываем добавлять запись на каждой машине используемой для управления сервером.

На сервере Hyper-V запустим Powershell и выполним командлет для разрешения удаленного подключения

По умолчанию данный командлет открывает доступ только из доменной и приватной сети. Разрешим доступ также из публичной сети.

Включаем поддержку проверки подлинности CredSSP на стороне сервера


Проверим что на сервере открыт порт WinRM


В выводе командлета поле TcpTestSucceeded должно иметь статус True.

Добавим в межсетевой экран правило разрешающее подключаться с любых IP адресов

Список правил межсетевого экрана касаемо WinRM можно посмотреть с помощью командлета Get-NetFirewallRule

Добавим еще одно разрешающее правило для доступа с помощью оснасток MMC

На данном этапе с настройкой сервера мы закончили переходим к настройке клиента.

Настройка клиента Windows 10

Если вы следовали четко по инструкции то прописали имя компьютера в соответствии с его адресом в файле hosts либо на DNS сервере. Следующим этапом убедимся что на компьютере установлена консоль управления Hyper-V Management. Если её нет, давайте установим.

Нажимаем правой кнопкой мыши на Пуск -> Приложения и возможности -> Программы и компоненты -> Включение или отключение компонентов Windows -> Hyper-V -> Средства управления Hyper-V




Далее запускаем Powershell с правами администратора и выполняем все действия по ним.

Включим возможность удаленного подключения

Добавим сервер Hyper-V в доверенные узлы на локальном ПК

Проверим что все получилось


Настройка проверки подлинности CredSSP для службы WS-Management





Настройка клиента закончена. Пробуем подключится к серверу используя Hyper-V Manager.

Подключение к серверу с помощью Hyper-v Manager

Запустим Hyper-V Manager (он же Диспетчер Hyper-V). Нажимаем Подключиться к серверу. В открытом окне выбираем поле Другой компьютер пишем имя нашего сервера: WHS19. Ставим галочку Подключиться как другой пользователь.


Нажимаем кнопку Выбрать пользователя


Внимательно заполняем логин и пароль для входа на сервер Hyper-V. Обязательно в поле имя пользователя вначале пишем имя компьютера затем имя пользователя. В нашем случае WHS19\Administrator. Нажимаем OK. Все готово, теперь можно управлять сервером Hyper-V 2019 из удобной консоли.


Подключение к серверу с помощью Windows Admin Center

Для использования Windows Admin Center необходимо его скачать. Скопируем скачанный файл на сервер Hyper-V. Я скопировал файл WindowsAdminCenter2009.msi по пути C:\Users\Administrator. Переходим в открытую консоль cmd или powershell и запускаем установку.

Данная команда запустит скрытую установку Windows Admin Center. Журналирование установки идет в файл log.txt, порт для подключения я использую 9010 (можно указать любой свободный). Сертификат создается автоматически. Дожидаемся окончания установки и можем пробовать подключаться.


В консоли Windows Admin Center можно следить за загрузкой сервера через удобные графики расположенные на одной странице. Можно быстро выключить, перезагрузить, переименовать сервер. Большой набор функций доступен изначально, также есть воможность расширения за счет дополнительных плагинов.


Можно создавать/удалять/управлять виртуальными машинами. Очень удобно прямо из браузера без необходимости запуска других консолей.


Резюмируя хочу сказать что WAC интересный инструмент для быстрой настройки/доступа к серверу. Хотя конечно не без недостатков. Мне лично не нравится то что просмотр логов идет сплошным текстом без выделения по цвету (warning, error и т.д.). В общем смотрите, изучайте, пользуйтесь.

Подключаться к серверу можно и с консоли mmc и с powershell. В общем большой набор инструментов для управления сервером. Установка и настройка Microsoft Hyper-V Server 2019 в целом почти идентична с версией сервера 2016. Можно использовать данную статью как мануал для старой версии.

В этом разделе описывается, как создать отказоустойчивый кластер с помощью оснастки диспетчера отказоустойчивости кластеров или Windows PowerShell. В нем рассматривается типичное развертывание, при котором объекты-компьютеры для кластера и связанные с ним кластерные роли создаются в доменных службах Active Directory (AD DS). если вы развертываете дисковые пространства прямой кластер, см. раздел развертывание дисковые пространства direct. Сведения об использовании отказоустойчивого кластера в Azure Stack ХЦИ см. в статье создание Azure Stack хЦи.

Также можно развернуть кластер, отсоединенный Active Directory. Этот метод развертывания позволяет создать отказоустойчивый кластер без разрешений на создание объектов-компьютеров в AD DS или необходимости запрашивать эти объекты-компьютеры в AD DS. Он возможен только посредством Windows PowerShell и рекомендуется только в определенных сценариях. Дополнительные сведения см. в разделе о развертывании отсоединенного от Active Directory кластера.

Контрольный список: Создание отказоустойчивого кластера

Состояние Задача Справочник
☐ Проверка предварительных требований Проверьте предварительные требования.
☐ Установка средства отказоустойчивости кластеров на всех серверах, которые необходимо добавить как узлы кластера Установка средства отказоустойчивости кластеров
☐ Запуск мастера проверки кластеров для проверки конфигурации Проверка конфигурации
☐ Запуск мастера создания кластера для создания отказоустойчивого кластера Создание отказоустойчивого кластера.
☐ Создание кластерных ролей для размещения рабочих нагрузок кластера Создание кластерных ролей

Проверка предварительных требований

Перед началом работы проверьте выполнение следующих необходимых условий.

  • Убедитесь в том, что все серверы, которые нужно добавить в качестве узлов кластера, работают под управлением одной и той же версии Windows Server.
  • Изучите требования к оборудованию, чтобы убедиться в том, что ваша конфигурация поддерживается. Подробнее см. в разделе Требования к оборудованию для отказоустойчивой кластеризации и варианты хранилища. если вы создаете прямой кластер дисковые пространства, см. раздел дисковые пространства direct, требования к оборудованию.
  • Чтобы добавить кластерное хранилище во время создания кластера, убедитесь, что все серверы имеют доступ к хранилищу. (Кластерное хранилище можно добавить и после создания кластера.)
  • Убедитесь в том, что все серверы, которые нужно добавить в качестве узлов кластера, присоединены к одному и тому же домену Active Directory.
  • (Необязательно.) Создайте подразделение и переместите в него учетные записи компьютеров для серверов, которые нужно добавить в качестве узлов кластера. Мы рекомендуем размещать отказоустойчивые кластеры в собственном подразделении в AD DS. Это позволит лучше контролировать параметры групповой политики и шаблона безопасности, применяемые к узлам кластера. Изоляция кластеров в собственном подразделении также помогает предотвратить случайное удаление объектов-компьютеров кластера.

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

  • Убедитесь в том, что учетная запись, которую вы хотите использовать для создания кластера, принадлежит пользователю домена с правами администратора на всех серверах, которые нужно добавить в качестве узлов кластера.
  • Убедитесь, что выполняется одно из следующих условий:
    • У пользователя, создающего кластер, есть разрешение на создание объектов-компьютеров для подразделения или контейнера, в котором размещаются серверы, которые войдут в кластер.
    • Если у пользователя нет разрешения на создание объектов-компьютеров, попросите администратора домена предварительно подготовить объект-компьютер кластера. Подробнее см. в разделе Подготовка кластерных объектов-компьютеров в доменных службах Active Directory.

    это требование не применяется, если требуется создать Active Directory отсоединенный кластер в Windows Server 2012 R2. Дополнительные сведения см. в разделе о развертывании отсоединенного от Active Directory кластера.

    Установка средства отказоустойчивости кластеров

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

    Установка средства отказоустойчивости кластеров

    Запустите диспетчер серверов.

    В меню Управление выберите команду Добавить роли и компоненты.

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

    На странице Выбор типа установки выберите Установка на основе ролей или компонентов, а затем нажмите кнопку Далее.

    На странице Выбор целевого сервера выберите сервер, на котором требуется установить компонент, и нажмите кнопку Далее.

    На странице Выбор ролей сервера щелкните Далее.

    На странице Выбор компонентов установите флажок Отказоустойчивая кластеризация.

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

    На странице Подтверждение выбранных вариантов установки нажмите кнопку установить.
    После установки средства отказоустойчивости кластеров не нужно перезапускать сервер.

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

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

    После установки средства отказоустойчивости кластеров рекомендуется применить последние обновления из Центра обновления Windows. кроме того, для отказоустойчивого кластера на основе Windows Server 2012 ознакомьтесь с рекомендуемыми исправлениями и обновлениями для отказоустойчивых кластеров на основе Windows Server 2012 служба поддержки Майкрософт статье и установите все применимые обновления.

    Проверка конфигурации

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

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

    Выполнение тестов проверки кластера

    На компьютере, на котором установлены средства управления отказоустойчивыми кластерами из средств удаленного администрирования сервера, или на сервере, на котором установлено средство отказоустойчивости кластеров, запустите диспетчер отказоустойчивости кластеров. Чтобы сделать это на сервере, запустите диспетчер сервера, а затем в меню Сервис выберите Диспетчер отказоустойчивости кластеров.

    В области Диспетчер отказоустойчивости кластеров в разделе Управление выберите проверить конфигурацию.

    На странице Перед началом работы нажмите кнопку Далее.

    На странице Параметры тестирования выберите выполнить все тесты (рекомендуется), а затем нажмите кнопку Далее.

    На странице Подтверждение нажмите кнопку Далее.

    На странице "Проверка" показано состояние выполняющихся тестов.

    На странице Сводка выполните одно из указанных ниже действий.

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

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

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

    Создание отказоустойчивого кластера.

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

    Запустите диспетчер серверов.

    В меню Сервис выберите Диспетчер отказоустойчивости кластеров.

    В области Диспетчер отказоустойчивости кластеров в разделе Управление выберите создать кластер.

    Откроется мастер создания кластеров.

    На странице Перед началом работы нажмите кнопку Далее.

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

    Если ранее вы пропустили проверку, появится страница Предупреждение проверки. Настоятельно рекомендуется выполнить проверку кластера. Корпорация Майкрософт поддерживает только те кластеры, которые прошли все проверочные тесты. Чтобы выполнить проверочные тесты, выберите Да, а затем нажмите кнопку Далее. Завершите работу мастера проверки конфигурации, как описано в разделе Проверка конфигурации.

    На странице Точка доступа для администрирования кластера выполните указанные ниже действия.

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

    • В процессе создания кластера это имя регистрируется в качестве объекта-компьютера кластера (также известного как объект имени кластера или CNO) в доменных службах Active Directory. Если для кластера указано имя NetBIOS, объект CNO создается в том же расположении, в котором находятся объекты-компьютеры узлов кластера. Это может быть контейнер "Компьютеры" (по умолчанию) или подразделение.
    • Чтобы указать другое расположение для CNO, можно ввести различающееся имя подразделения в поле Имя кластера. Например: CN=ClusterName, OU=Clusters, DC=Contoso, DC=com.
    • Если администратор домена предварительно подготовил CNO в подразделении, отличном от того, в котором размещаются узлы кластера, укажите различающееся имя, предоставленное администратором домена.

    Если на сервере нет сетевого адаптера, настроенного на использование DHCP, для отказоустойчивого кластера необходимо настроить один или несколько статических IP-адресов. Установите флажок напротив каждой сети, которую необходимо использовать для управления кластером. Выберите поле адреса рядом с выбранной сетью, а затем введите IP-адрес, который нужно назначить кластеру. Этот IP-адрес (или адреса) будет связан с именем кластера в службе доменных имен (DNS).

    если вы используете Windows Server 2019, у вас есть возможность использовать имя распределенной сети для кластера. Имя распределенной сети использует IP-адреса рядовых серверов вместо использования выделенного IP-адреса для кластера. по умолчанию Windows использует имя распределенной сети, если обнаруживает, что вы создаете кластер в Azure (поэтому вам не нужно создавать внутренний балансировщик нагрузки для кластера) или обычный статический или IP-адрес, если вы работаете в локальной среде. Дополнительные сведения см. в разделе имя распределенной сети.

    1. По завершении нажмите кнопку Далее.

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

    • Хранилище следует настроить позднее.
    • Вы планируете создать кластерные дисковые пространства с помощью диспетчера отказоустойчивости кластеров или командлетов отказоустойчивой кластеризации Windows PowerShell, но еще не создали дисковые пространства в файловых службах и службах хранилища. Подробнее см. в разделе Развертывание кластерных дисковых пространств.

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

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

    После создания кластера можно выполнить такие действия, как проверка конфигурации кворума кластера и создание общих томов кластера — CSV (необязательно). дополнительные сведения см. в разделе понимание кворума в дисковые пространства Direct и использование общих томов кластера в отказоустойчивом кластере.

    Создание кластерных ролей

    После создания отказоустойчивого кластера можно создать кластерные роли для размещения кластерных рабочих нагрузок.

    Для кластерных ролей, требующих точки доступа клиента, в доменных службах Active Directory создается виртуальный объект-компьютер (VCO). По умолчанию все объекты VCO для кластера создаются в том же контейнере или подразделении, что и объект CNO. Имейте в виду, что после создания кластера объект CNO можно переместить в любое подразделение.

    Вот как можно создать кластерную роль:

    Чтобы на каждом узле отказоустойчивого кластера установить роль или компонент, необходимый для кластерной роли, используйте диспетчер сервера или Windows PowerShell. Например, чтобы создать кластерный файловый сервер, установите роль файлового сервера на всех узлах кластера.

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

    В диспетчер отказоустойчивости кластеров разверните узел имя кластера, щелкните правой кнопкой мыши элемент роли и выберите пункт настроить роль.

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

    Чтобы проверить, создана ли кластерная роль, на панели Роли убедитесь в том, что роль имеет состояние Выполняется. На панели "Роли" также указан узел владельца. Чтобы протестировать отработку отказа, щелкните правой кнопкой мыши роль, выберите пункт переместить, а затем выберите пункт выбрать узел. В диалоговом окне Перемещение кластерной роли выберите нужный узел кластера и нажмите кнопку ОК. В столбце Узел владельца убедитесь в том, что узел владельца изменился.

    Создание отказоустойчивого кластера с помощью Windows PowerShell

    следующие командлеты Windows PowerShell выполняют те же функции, что и предыдущие процедуры в этом разделе. Введите каждый командлет в отдельной строке, даже если кажется, что из-за ограничения возможностей форматирования они переносятся по словам на другую строку.

    для создания Active Directory отсоединенного кластера в Windows Server 2012 R2 необходимо использовать Windows PowerShell. Информацию о синтаксисе см. в разделе Развертывание отсоединенного от Active Directory кластера.

    В приведенном ниже примере устанавливается средство отказоустойчивости кластеров.

    В приведенном ниже примере запускаются все проверочные тесты кластера на компьютерах с именами Server1 и Server2.

    Командлет Test-Cluster выводит результаты в файл журнала в текущем рабочем каталоге. Например: C:\Users <username> \AppData\Local\Temp.

    В приведенном ниже примере создается отказоустойчивый кластер с именем MyCluster и узлами Server1 и Server2; ему присваивается статический IP-адрес 192.168.1.12, и в него добавляются все подходящие дисковые пространства.

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

    После создания отказоустойчивого кластера с отключенным AD создайте резервную копию сертификата с возможностью экспорта закрытого ключа. Откройте MMC = =>файл = =>добавить оснастку "Удалить" в = =>Certificates =>=>локальный компьютер = =>службы кластеров = =>Certificates = =>Клуссвк\персонал = =>выбор сертификата — щелкните правой кнопкой мыши = =>Export = =>далее = =>Да экспорт закрытого ключа = =>формат PfX = =>выбрать пароль или добавить группу = =>следующий = =>выберите путь, по которому нужно сохранить сертификат = =>далее = =>готово.

    В статье приводится краткий обзор создания отказоустойчивого кластера Microsoft Windows (WFC) в ОС Windows Server 2019 или 2016. В результате вы получите двухузловой кластер с одним общим диском и кластерный вычислительный ресурс (объект «компьютер» в Active Directory).


    Подготовка

    Не имеет значения, какие машины вы используете — физические или виртуальные, главное, чтобы технология подходила для создания кластеров Windows. Перед тем, как начать, проверьте соответствие необходимым требованиям:

    Две машины Windows 2019 с установленными последними обновлениями. У них должно быть по крайней мере два сетевых интерфейса: один для производственного трафика и один для кластерного трафика. В моем примере у машин три сетевых интерфейса (один дополнительный для трафика iSCSI). Я предпочитаю статические IP-адреса, но также можно использовать DHCP.


    Введите оба сервера в домен Microsoft Active Directory и убедитесь, что они видят общий ресурс хранения, доступный в Disk Management. Пока не переводите диск в режим «онлайн».

    Далее необходимо добавить функциональность Failover clustering (Server Manager > Аdd roles and features).


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

    Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools


    После успешной установки в меню Start, в Windows Administrative Tools появится Failover Cluster Manager .

    После установки Failover-Clustering можно перевести общий диск в режим «онлайн» и отформатировать его на одном из серверов. Не меняйте ничего на втором сервере. Там диск остается в режиме offline.

    Обновив Disk Management, вы увидите что-то типа такого:

    Server 1 Disk Management (disk status online)


    Server 2 Disk Management (disk status offline)


    Проверка готовности отказоустойчивого кластера

    Перед созданием кластера необходимо убедиться, что все настройки правильно сконфигурированы. Запустите Failover Cluster Manager из меню Start, прокрутите до раздела Management и кликните Validate Configuration.


    Выберите для валидации оба сервера.


    Выполните все тесты. Там же есть описание того, какие решения поддерживает Microsoft.


    После успешного прохождения всех нужных тестов, можно создать кластер, установив флажок Create the cluster now using the validated nodes (создать кластер с помощью валидированных узлов), или это можно сделать позже. Если во время тестирования возникали ошибки или предупреждения, можно просмотреть подробный отчет, кликнув на View Report.


    Создание отказоустойчивого кластера

    Если вы решите создать кластер, кликнув на Create Cluster в Failover Cluster Manager, потребуется снова выбрать узлы кластера. Если вы используете флажок Create the cluster now using the validated nodes в мастере валидации кластера, выбирать узлы не понадобится. Следующим шагом будет создание точки доступа для администрирования кластера — Access Point for Administering the Cluster. Это будет виртуальный объект, с которым позже будут коммуницировать клиенты. Это объект «компьютер» в Active Directory.

    В мастере нужно будет задать имя кластера — Cluster Name и сетевую конфигурацию.


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


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

    В результате вы увидите новый объект «компьютер» Active Directory под названием WFC2019.



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

    New-Cluster -Name WFC2019 -Node SRV2019-WFC1 , SRV2019-WFC2 -StaticAddress 172.21.237.32


    Результат можно будет увидеть в Failover Cluster Manager, в разделах Nodes и Storage > Disks.



    Иллюстрация показывает, что в данный момент диск используется в качестве кворума. Поскольку мы хотим использовать этот диск для данных, нам необходимо сконфигурировать кворум вручную. Из контекстного меню кластера выберите More Actions > Configure Cluster Quorum Settings (конфигурирование настроек кворума).


    Мы хотим выбрать диск-свидетель вручную.


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


    Просто укажите путь и завершите мастер установки.


    После этого общий диск можно использовать для работы с данными.


    Поздравляю, вы сконфигурировали отказоустойчивый кластер Microsoft с одним общим диском.


    Следующие шаги и резервное копирование

    Одним из следующих шагов будет добавление роли для кластера, но это выходит за рамки данной статьи. Когда кластер будет содержать данные, пора будет подумать о его резервном копировании. Veeam Agent for Microsoft Windows может применяться для резервного копирования отказоустойчивых кластеров Windows с общими дисками. Мы также рекомендуем осуществлять резервное копирование «всей системы» кластера. При этом выполняется резервное копирование операционных систем узлов кластера. Это поможет ускорить восстановление отказавшего узла кластера, так как вам не придется искать драйверы и прочее при восстановлении.

    Руководство по созданию отказоустойчивых кластеров для Windows Server 2019


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

    Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.

    Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.


    Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.

    Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.


    Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Подробнее по ссылке.

    Поэтому я создал две виртуальные машины – node1, node2 и сразу отключил динамическую память. Затем необходимо включить поддержку вложенной виртуализации:


    Включаем поддержку спуфинга на сетевых адаптерах ВМ:




    HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.

    Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.

    Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты sconfig это не составит большого труда. Уточню только, что установил Windows Admin Center с помощью скрипта:


    По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.

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

    Приступим к созданию кластера. Напомню, что все необходимые консоли у меня установлены на контролере домена. Поэтому я подключаюсь к домену и запускаю Powershell ISE под администратором. Затем устанавливаю на ноды необходимые роли для построения кластера с помощью скрипта:


    И перегружаю сервера после установки.

    Запускаем тест для проверки готовности нод:


    Отчёт в фомате html сформировался в папке C:\Users\Administrator\AppData\Local\Temp. Путь к отчету утилита пишет, только если есть ошибки.

    Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100


    После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.



    И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.

    Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том. Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB.



    На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.
    Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.


    Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager.

    Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center. Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик


    Подключимся к одной из нод и выполним скрипт:


    Проверяем Admin Center и на этот раз получаем красивые графики


    После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.

    И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. Тут стоит вернуться к аппаратным требованиям. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.

    Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 . Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют.

    В заключении хотел бы сказать несколько слов о своих впечатлениях. Знакомство с новыми технологиями это был для меня весьма интересный опыт. Назвать его полезным, пока не могу. Я не уверен, что смогу применить эти навыки на практике. Поэтому у меня вопросы к сообществу: готовы ли вы рассматривать переход на гиперконвергентные решения в будущем? как относитесь к размещению виртуальных контроллеров домена на самих нодах?

    Читайте также: