Настройка failover cluster windows server 2016

Обновлено: 05.07.2024

В этой небольшой инструкции мы покажем пошагово как создать простой отказоустойчивый кластер Hyper-V Cluster из двух серверов с Windows Server 2016. Такой кластер позволяет без особых проблем организовать отказоустойчивость для виртуальных машин Hyper-V при аппаратных проблемах с одним из серверов.

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

Два сервера с установленной ОС Windows Server 2016 (желательно чтобы количество памяти и CPU на обоих серверах было одинаково) с компонентами Failover Cluster и MPIO ( iSCSI по необходимости)
Как минимум по 2 сетевых карты на каждом сервере (одна сетевая карта будет использоваться для управления и через нее будет идти трафик ВМ, вторая – для взаимодействия хостов между собой – трафик CSV и Heartbeat)
Общее дисковое хранилище, подключенное к обоим серверам (в этом примере дисковый массив подключается к каждому серверу через 2 порта Fiber Channel, при этом компонент MPIO нужен для того, чтобы каждый сервер видел только одно подключение к диску, а не два)
Как минимум один диск (LUN) с общего хранилища презентован обоим сервера, инициализирован и отформатирован.

Настройки сети Hyper V

В нашем примере мы настроим следующую IP адресацию для компонентов кластера:

Установка кластера Hyper-V

Итак, на любом из серверов запускаем оснастку Failover Cluster Manager и запускаем мастер создания кластера (Create Cluster).

На странице выбора серверов кластера добавляем обе наших ноды.

На странице Validation Warning соглашаемся с запуском встроенных тестов валидации кластерной конфигурации.

Выберите, что нужно прогнать все тесты.

Далее на странице настройки Access Point for Administering the Cluster нужно указать имя кластера и его IP адрес и подсеть.

Осталось нажать 2 раза кнопку Next и мастер создаст новый кластер.

Настройка кластера Hyper-V

Теперь в кластер нужно добавить диски. Для этого откройте консоль Failover Cluster Management и в разделе Storage -> Disks добавьте общие в кластер общие диски (они должны быть инициализированы и отформатированы)

Задайте содержательные имена дискам. В нашем примере один кластерный диск будет использоваться как том Cluster Shared Volumes (CSV) для хранения файлов ВМ, а второй использоваться для кворума (диск небольшого размера).

Далее нужно настроить кластерный кворум. Для этого щелкните ПКМ по имени кластера и выберите пункт меню More Actions-> Configure Cluster Quorum Settings.

Выберите вариант настройки кворума для кластера Select the quorum witness.

В качестве типа кворума выберите Quorum Witness Select Disk Witness (кворум с использованием диска свидетеля).

Выберите кластерный диск, который вы хотите использовать в качестве диска-свидетеля.

Теперь в настройках Hyper-V на каждой из нод нужно указать кластерный том CSV в качестве диска по-умолчанию для хранения виртуальных машин.

Теперь можно в консоли управления кластером создать новую виртуальную машину: Roles -> Virtual Machines -> New Virtual Machine.

Затем с помощью обычного мастера Hyper-V нужно создать новую виртуальную машину. С помощью Live Migration в дальнейшем можно убедится, что ВМ на легко перемещается между узлами кластера Hyper-V.

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

Шаг №1: На все физические сервера в рамках этой заметке установлена операционная система Windows Server 2016 Standard (RUS) Version 10.0.14393 и все обновления на текущую дату (29.04.2018).

Шаг №2: Операционная система введена в текущий домен (в моем случае это polygon.local)

Шаг №3: Подключаюсь по RDP к первому серверу (srv-noda1) с правами учетной записи (Login: ekzorchik) в ходящей в группу «Администраторы домена» и устанавливаю роль Hyper-V и компонент, через который формируется кластера на Windows системе:

Роль: Hyper-V
Компоненты: Отказоустойчивая кластеризация
Не забываем выбрать виртуальный коммутатор на каждой ноде, в моем случае у меня Nic Teaming из двух карт, а потому отмечаю галочкой сетевой интерфейс с именем Team1G в роли виртуального коммутатора для Hyper-V.

Этап Hyper-V -> Миграция никак не отмечаю, данные настройки я выполню позже

Указываю размещение виртуальных жестких дисков и конфигураций виртуальной машины на еще одном общем диске, который через хранилище Dell EMC SCv3020 назначен физическим нодам:

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

Расположение по умолчанию для файлов виртуальных жестких дисков: E:\disk
Расположение по умолчанию для файлов конфигурации виртуальной машины: E:\conf

На заметку: Но при создании VM нужно указывать путь: C:\ClusterStorage\Volume1\conf, где Volume1 есть LUN логического диска E.

И нажимаю кнопку «Далее», «Установить», галочку об автоматическом перезапуске конечного сервера не ставлю, я считаю, что лучше убедиться, что это действительно нужно, об этом должен сообщить мастер установки устанавливаемого. И вот когда установка завершена я вижу надпись: «Ожидается перезапуск на srv-noda1.polygon.local. Для завершения установки необходимо перезапустить сервер», перезапускаю:

Win + X – Командная строка (Администратор) -> shutdown /r /t 3

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

Шаг №4: Проделываю действия Шага №3 и на других серверах которые будут входить в собираемый кластер. Можно либо подключиться к ним по RDP и повторить шаги или же дождаться, когда сервер с именем srv-noda1.polygon.local перезагрузиться и подключиться к нему по RDP и запустить установку роли и компоненты, но уже задействую настройку «Выбор сервера» выбрать сервер, входящий в группу, а у меня это следующая нода.

Для перезапуска/перезагрузки следует воспользоваться созданной группой сервер в которую входит данный сервер:

Теперь, когда необходимые роли и компоненты установлены соберем кластер.

Выбор серверов или кластера:

И нажимаю «Далее», оставляю дефолтным выбор мастера «Выполнить все тесты» и нажимаю «Далее», «Далее»

На заметку: к серверам уже должен быть подключен общий диск, который будет кворумным для обмена информацией между нодами кластера

По окончании проверки на создании кластера нужно в обязательном порядке нажать на «Просмотреть отчет…»

На заметку: я отключаю поддержку ipv6 и устанавливаю все обновления на момент написания данной заметки, плюс настройка что уведомлять об обновлениях, а скачивание и установку их я принимаю вручную или же отключаю их:

Управляем обновлениями на Windows Server 2016

Win + X – Командная строка (Администратор)

C:\Windows\system32>sconfig

Введите номер параметра: 5 (Параметры центра обновления Windows)

Выберите режим обновления: указываю M (Ручной)

Введите номер параметра: 15

На заметку: Если на серверах используется Nic Teaming, то интерфейсы на всех серверах должны называться одинаково (Team10G,Team1G)

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

После через Мастер «Создать кластер» создаю, отвечая и заполняя настройки мастера:

Имя кластера: srv-cluster
Сети: 10.99.99.0/27
Адрес: указываю свободный IP адрес и подсети, к примеру 10.99.99.99

На заметку: имя кластера не должно быть длиннее 15 символов

И нажимаю «Далее», галочка у «Добавление всех допустимых хранилищ в кластер» должна стоять и нажимаю снова «Далее», «Готово»

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

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

Имя	Состояние	Назначено	Узел владельца
Диск кластера 2	Оперативный	Доступное хранилище	Srv-noda1

И через правый клик мышью по нему выбираю «Добавить в общие тома кластера», этой настройкой логический диск размеченного LUN с отформатированной файловой системой NTFS переназначится в том видимый лишь кластеру с файловой системой CSVFS. Когда это проделано то в колонке «Назначено» будет значится уже «Общий том кластера».

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

Свою задачу по разворачиваю кластера я выполнил и прощаюсь, с уважением автор блога Олло Александр aka ekzorchik.

В этом разделе описывается, как создать отказоустойчивый кластер с помощью оснастки диспетчера отказоустойчивости кластеров или 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-адрес, если вы работаете в локальной среде. Дополнительные сведения см. в разделе имя распределенной сети.

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

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

Хранилище следует настроить позднее.
Вы планируете создать кластерные дисковые пространства с помощью диспетчера отказоустойчивости кластеров или командлетов отказоустойчивой кластеризации 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 = =>выбрать пароль или добавить группу = =>следующий = =>выберите путь, по которому нужно сохранить сертификат = =>далее = =>готово.

В данной статье мы опишем развертывания кластера Hyper-V, на операционной системой ОС Windows 2016.
В примере рассмотрим вариант с двумя серверами, два сервера с ролью Hyper-V и один iSCSI.

На SRV-1 и SRV-2 устанавливаем роль Hyper-V и Failover Cluster.

На серверах SRV-1 и SRV-2 запускаем службу iSCSI Initiator.

Переходим на сервер iSCSI Storage. Из раздела File and iSCSI Services устанавливаем роль iSCSI Target Server.

Добавляем роль iSCSI Target Server

На сервере iSCSI Storage в Server Manager находим iSCSI и создаем 2 виртуальных диска.
Диск свидетеля кворума и диск для хранения виртуальных машин.

Создаем iSCSI таргет. Задаем имя iSCSI таргета.

Добавляем сервера, которые могут подключаться к этим дискам (iSCSI инициаторы).

CHAP пропускаем.

Следующим шагом, создаем второй диск, называем его Storage и подключаем к уже созданному iSCSI таргет.

В Server Manager мы видим созданный таргет и инициаторы, но диски пока не подключены.

Возвращаемся на сервера SRV-1 и SRV-2.

Запускаем оснастку iSCSI Initiator. Добавляем таргет и подключаемся к нему.

В Disk Management мы видим 2 новых диска. Инициализируем и форматируем новые диски. На втором сервере форматирование не нужно, только инициализация.

Здесь вернемся на сервер iSCSI Storage и убедимся, что все подключено.

Переходим в диспетчер Hyper-V на серверах SRV-1 и SRV-2 и настраиваем виртуальный коммутатор. Обязательно даем одинаковое название коммутаторам на обоих серверах.

Открываем оснастку Failover Cluster Manager и приступаем к созданию кластера.

Вначале запускаем проверку. Если проверка не выдала ошибок, создаем кластер.

После проверки создаем кластер. При создании кластера для него создается виртуальный объект, которому даем имя и IP-адрес. В AD в том же OU, в котором находятся сервера появится новая машина.

Добавляем диски.

В Failover Cluster Manager переходим в Storage -> Disk -> справа выбираем add Disk и добавляем диски.

Далее указываем Disk Quorum (диск-свидетель)

И добавляем Disk Storage в общие тома кластера.

Настраиваем сеть

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

На этом настройка кластера окончена.

Теперь все виртуальные машины должны создаваться не в диспетчере Hyper-V, а в Failover Cluster Manager. Для создания новой машины заходим в Roles -> Virtual Machines -> New Virtual Machine. Выбираем узел, на котором будет находится машина.

В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN.

В параметрах машины Automatic Start Action указываем Automatically Start и задержку старта, что бы избежать перегрузки системы.

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

На этом настройка виртуальной машины закончена.

Проверяем миграцию виртуальной машины
Move -> Live Migration -> выбираем ноду.

Проанализируем созданный кластер с
BPA (Best Practices Analyzer, Анализатором наилучших решений).

Переходим в Server Manager -> Hyper-V -> справа Tasks -> Start BPA Scan.

Вот что показал мне тест.

Всем привет! Совсем недавно была объявлена глобальная доступность Windows Server 2016, означающая возможность уже сейчас начать использование новой версии продукта в Вашей инфраструктуре. Список нововведений довольно обширный и мы уже описывали часть из них (тут и тут), но в этой статье разберем службы высокой доступности, которые, на мой взгляд, являются самыми интересными и используемыми (особенно в средах виртуализации).

Миграция кластера в прошлых версиях Windows Server является причиной значительного простоя из-за недоступности исходного кластера и создания нового на базе обновленной ОС на узлах с последующей миграцией ролей между кластерами. Такой процесс несет повышенные требования к квалификации персонала, определенные риски и неконтролируемые трудозатраты. Данный факт особенно касается CSP или других заказчиков, которые имеют ограничения по времени недоступности сервисов в рамках SLA. Не стоит описывать, что для поставщика ресурсов означает значительное нарушение SLA )

Windows Server 2016 ситуацию исправляет через возможность совмещения Windows Server 2012 R2 и Windows Server 2016 на узлах в рамках одного кластера во время его апгрейда (Cluster OS Rolling Upgrade (далее CRU)).

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

Определим сначала список «плюшек», которые CRU предоставляет:

Полное отсутствие простоя при апгрейде кластеров WS2012R2 Hyper-V/SOFS. Для других кластерных ролей (к примеру, SQL Server) возможна их недоступность (менее 5 минут), необходимая для отработки разового failover.
Нет необходимости в дополнительном аппаратном обеспечении. Как правило, кластер строится из учета возможной недоступности одного или нескольких узлов. В случае с CRU, недоступность узлов будет планируемой и поэтапной. Таким образом, если кластер может безболезненно пережить временное отстутствие хотя бы 1 из узлов, то для достижения zero-downtime дополнительных узлов не требуется. Если планируется апгрейд сразу нескольких узлов (это поддерживается), то необходимо заранее спланировать распределение нагрузки между доступными узлами.
Создание нового кластера не требуется. CRU использует текущий CNO.
Процесс перехода обратим (до момента повышения уровня кластера).
Поддержка In-Place Upgrade. Но, стоит отметить, что рекомендуемым вариантом обновления узлов кластера является полноценная установка WS2016 без сохранения данных (clean-os install). В случае с In-Place Upgrade обязательна проверка полной функциональности после обновления каждого из узлов (журналы событий и т.д.).
CRU полностью поддерживается VMM 2016 и может быть автоматизирован дополнительно через PowerShell/WMI.

PS C:\Windows\system32> Update-ClusterFunctionalLevel

Updating the functional level for cluster hvcl.
Warning: You cannot undo this operation. Do you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is Y): a

Перечень версий ВМ, поддерживаемые 2016 RTM:

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

В Windows Server 2016 для обеспечения возможности построения DR на базе Windows Server и для других сценариев доступна новая модель кворумной конфигурации на базе Cloud Witness.

Cloud Witness может применяться в следующих сценариях:

Для обеспечения DR кластера, размещенного в разных сайтах (multi-site).
Кластеры без общего хранилища (Exchange DAG, SQL Always-On и другие).
Гостевые кластеры, выполняющиеся как в Azure, так и в on-premises.
Кластеры хранения данных с или без общего хранилища (SOFS).
Кластеры в рамках рабочей группы или разных доменах (новая функциональность WS2016).

Для упрощения можно использовать PowerShell:

В Windows Server 2012 R2 и предыдущих версиях необходимо соблюдение глобального требования перед созданием кластера: узлы должны быть членами одного и того же домена. Active Directory Detached кластер, презентованный в 2012 R2, имеет подобное требование и не упрощает его существенным образом.

В Windows Server 2016 возможно создание кластера без привязки к AD в рамках рабочей группы или между узлами, являющиеся членами разных доменов. Процесс схож с созданием deattached -кластера в 2012 R2, но имеет некоторые особенности:

Поддерживается только в рамках среды WS2016.
Требуется роль Failover Clustering.

При появлении ошибки “Requested Registry access is not allowed” необходимо изменить значение политики LocalAccountTokenFilterPolicy.

Динамическая оптимизация, доступная в VMM, частично перекочевала в Windows Server 2016 и предоставляет базовое распределение нагрузки на узлах в автоматическом режиме. Для перемещения ресурсов используется Live Migration и эвристики, на базе которых кластер каждые 30 минут решает проводить балансировку или нет:

Текущий % использования памяти на узле.
Средняя загрузка по CPU в 5 минутном интервале.

AutoBalancerLevel	Агрессивность балансировки	Комментарий
1 (по умолчанию)	Low	Осуществлять балансировку при загрузке узла более 80% по одной из эвристик
2	Medium	При загрузке более 70%
3	High	При загрузке более 60%

Параметры балансировщика можно определить и в GUI (cluadmin.msc). По умолчанию, используется Low уровень агрессивности и режим постоянной балансировки.

Для проверки я использую следующие параметры:

AutoBalancerLevel: 2

AutoBalancerMode: 2

Имитируем нагрузку сначала по CPU (около 88%) и затем по RAM (77%). Т.к. определен средний уровень агрессивности при принятии решения о балансировке и наши значения по загрузке выше определенного значения (70%) виртуальные машины на загруженном узле должны переехать на свободный узел. Скрипт ожидает момент живой миграции и выводит затраченное время (от точки начала загрузки на узла до осуществления миграции ВМ).

В случае с большой нагрузкой по CPU балансировщик переместил более 1 ВМ, при нагрузке RAM – 1 ВМ была перемещена в рамках обозначенного 30 минутного интервала, в течение которого происходит проверка загрузки узлов и перенос ВМ на другие узлы для достижения <=70% использования ресурсов.

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

Изменение логики старта ВМ в рамках кластера в 2012 R2 строится на понятии приоритетов (low,medium,high), задача которых обеспечивать включение и доступность более важных ВМ перед запуском остальных «зависимых» ВМ. Обычно это требуется для multi-tier сервисов, построенных, к примеру, на базе Active Directory, SQL Server, IIS.

Для повышения функциональности и эффективности в Windows Server 2016 добавлена возможность определять зависимости между ВМ или группами ВМ для решения обеспечения корректного их старта, используя Set или наборы кластерных групп. Преимущественно нацелены на использование совместно с ВМ, но могут быть использованы и для других кластерных ролей.

Для примера используем следующий сценарий:

1 ВМ Clu-VM02 является приложением, зависимым от доступности Active Directory, выполняемой на вирт. машине Clu-VM01. А ВМ Clu-VM03, в свою очередь, зависит от доступности приложения, расположенного на ВМ Clu-VM02.

Создадим новый set, используя PowerShell:

ВМ с Active Directory:
PS C:\> New-ClusterGroupSet -Name AD -Group Clu-VM01
Name: AD
GroupNames:
ProviderNames: <>
StartupDelayTrigger: Delay
StartupCount: 4294967295
IsGlobal: False
StartupDelay: 20

Приложение:
New-ClusterGroupSet -Name Application -Group Clu-VM02

Зависимый сервис от приложения:
New-ClusterGroupSet -Name SubApp -Group Clu-VM03

Добавляем зависимости между set’ами:
Add-ClusterGroupSetDependency -Name Application -Provider AD
Add-ClusterGroupSetDependency -Name SubApp -Provider Application

В случае необходимости можно изменить параметры set’а, используя Set-ClusterGroupSet. Пример:

StartupDelayTrigger определяет действие, которое необходимо произвести после старта группы:

Delay – ожидать 20 секунд (по умолчанию). Используется совместно с StartupDelay.
Online – ожидать состояния доступности группы в set.

isGlobal – определяет необходимость запуска set’а перед стартом других наборов кластерных групп (к примеру, set с группами ВМ Active Directory должен быть глобально доступен и, следовательно, стартовать раньше других коллекций).

Попробуем стартовать ВМ Clu-VM03:

Происходит ожидание доступности Active Directory на Clu-VM01 (StartupDelayTrigger – Delay, StartupDelay – 20 секунд)

После запуска Active Directory происходит запуск зависимого приложения на Clu-VM02 (StartupDelay применяется и на этом этапе).

И последним шагом является запуск самой ВМ Clu-VM03.

В Windows Server 2016 появились новые режимы работы узлов и ВМ для повышения степени их устойчивости в сценариях проблемного взаимодействия между кластерными узлами и для предотвращения полной недоступности ресурсов за счет реакции на «малые» проблемы перед возникновением более глобальных (проактивное действие).

Режим изоляции (Isolated)

На узле HV01 внезапно стала недоступна служба кластеризации, т.е. у узла появляются проблемы интра-кластерного взаимодействия. При таком сценарии узел помещается в состояние Isolated (ResiliencyLevel) и временно исключается из кластера.

Виртуальные машины на изолированном узле продолжают выполняться* и переходят в статус Unmonitored (т.е. служба кластера не «заботится» о данных ВМ).

*При выполнении ВМ на SMB: статус Online и корректное выполнение (SMB не требует «кластерного удостоверения» для доступа). В случае с блочным типом хранилища ВМ уходят статус Paused Critical из-за недоступности Cluster Shared Volumes для изолированного узла.

Если узел в течение ResiliencyDefaultPeriod (по умолчанию 240 секунд) не вернет службу кластеризации в строй (в нашем случае), то он переместит узел в статус Down.

Режим карантина (Quarantined)

Предположим, что узел HV01 успешно вернул в рабочее состояние службу кластеризации, вышел из Isolated режим, но в течение часа ситуация повторилась 3 или более раза (QuarantineThreshold). При таком сценарии WSFC поместит узел в режим карантина (Quarantined) на дефолтные 2 часа (QuarantineDuration) и переместит ВМ данного узла на заведомо «здоровый».

При уверенности, что источник проблем был ликвидирован, можем ввести узел обратно в кластер:

Важно отметить, что в карантине одновременно могут находиться не более 25% узлов кластера.
Для кастомизации используйте вышеупомянутые параметры и cmdlet Get-Cluster:

Storage Resiliency

В предыдущих версиях Windows Server отработка недоступности r/w операций для вирт. диска (потеря соединения с хранилищем) примитивная – ВМ выключаются и требуется cold boot на последующем старте. В Windows Server 2016 при возникновении подобных проблем ВМ переходит в статус Paused-Critical (AutomaticCriticalErrorAction), предварительно «заморозив» своё рабочее состояние (её недоступность сохранится, но неожиданного выключения не будет).

При восстановлении подключения в течение таймаута (AutomaticCriticalErrorActionTimeout, 30 минут по умолчанию), ВМ выходит из paused-critical и становится доступной с той «точки», когда проблема была идентифицирована (аналогия – pause/play).

Если таймаут будет достигнут раньше возвращения хранилища в строй, то произойдет выключение ВМ (действие turn off)

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

Ранее нам советовали сторонние решения (много $) для создания полноценных распределенных кластеров (обеспечение SAN-to-SAN репликации). С появлением Windows Server 2016 сократить бюджет в разы и повысить унификацию при построении подобных систем становится действительностью.

Storage Replica позволяет осуществлять синхронную (!) и асинхронную репликацию между любыми системами хранения (включая Storage Spaces Direct) и поддерживающая любые рабочие нагрузки, — лежит основе multi-site кластеров или полноценного DR -решения. SR доступна только в редакции Datacenter и может применяться в следующих сценариях:

Использование SR в рамках распределенного кластера особенно ещё наличием автоматической отработки по отказу и тесной работы с site-awareness, который был презентован так же в Windows Server 2016. Site-Awarieness позволяет определять группы узлов кластера и привязывать их к физическому месторасположению (site fault domain/сайт) для формирования кастомных политик отказа (failover), размещения данных Storage Spaces Direct и логики распределения VM. Кроме того, возможна привязка не только на уровне сайтов, но и на более низкие уровни (node, rack, chassis).

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