Кластер удаленных рабочих столов windows server 2016

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

Естественно, что на всех узлах кластера нужно устаровить Windows Server 2016. Поддерживаются следующие сценарии кластеризации:

На всех будущих узлах кластера нужно

1. Установить роль Failover Clustering:
   Install-WindowsFeature Failover-Clustering –IncludeManagementTools
2. На каждой кластерной ноде нужно создать локальную учетную запись с правами администратора (или использовать встроенную учетку администратора) с одинаковыми паролями.
   net user /add clustadm Pa$$word!
net localgroup administrators clustadm /add
   
3. При появлении ошибки Requested Registry access is not allowed, необходимо изменить в реестре параметр удаленного UAC — Данный ключ разрешает удаленный доступ к административным шарам.
   New-ItemProperty -Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem -Name LocalAccountTokenFilterPolicy -Value 1
4. На всех узлах кластера нужно задать одинаковой первичный DNS суффикс (Primary DNS suffix). Это нужно для того, чтобы сервера кластера могли обращаться друг к другу по FQDN именам
5. Также нужно снять галку Register DNS connection addresses
6. В файл hosts на всех узлах кластера нужно внести изменения, чтобы сервера могли отрезолвить имена других членов кластера, а также имя кластера (в том числе FQDN имена). Добавить имена в файл c:windowssystem32driversetchosts можно так:
   Set file="%windir%System32driversetchosts"
echo 192.168.1.21 clust-host1 >> %file%
echo 192.168.1.21 clust-host1.mylocal.net >> %file%
echo 192.168.1.22 clust-host2 >>  %file%
echo 192.168.1.22 clust-host2.mylocal.net >> %file%
echo 192.168.1.20 cluster1 >> %file%
echo 192.168.1.20 cluster1.mylocal.net>> %file%
   

Для предварительной валидации узлов кластера можно воспользоваться командой:

test-cluster -node "clust-host1.mylocal.net"," clust-host2.mylocal.net"

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

New-Cluster -Name cluster1 -Node clust-host1.mylocal.net, clust-host2.mylocal.net -AdministrativeAccessPoint DNS  -StaticAddress 192.168.1.20

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

Для подключения (и удаленного управления) кластером через GUI нужно воспользоваться оснасткой Failover Cluster Manager (входит в состав) RSAT для Windows 10.

Теперь с помощью пункта меню Connect to cluster можно подключаться к созданному кластеру. В том случае, если в кластере четное количество серверов, придется настроить ресурс-свидетель. Отметим, что в качестве кворумного свидетеля нельзя использовать сетевую папку SMB. Поддерживается режим Disk Witness — общий диск (с одновременным доступом к нему с обоих узлов), либо Cloud Witness — облачный дисковый ресурс в Azure.

Еще немного технических видео на канале… Нет, это видео не про Petya – про защиту от Petya смотрите здесь и читайте статьи здесь на блоге, и не про мониторинг производительность дисков (но обещанное продолжение про производительность тоже следует). Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

Хотя это видео про развертывание кластера Windows Server 2016 и получилось слегка длинным – но, на мой взгляд – удачным – тут и использование тиминга (NIC Teaming) сетевых интерфейсов для ускорения дисковых операций, и подключение к сетевым дискам iSCSI для общего хранилища кластера, и проблемы с правильным определением кластеров “нужных” сетевых интерфейсов с дальнейшим исправлением, и, конечно же – создание собственно отказоустойчивых ролей в кластере – таких, как высокопроизводительный отказоустойчивый файловый сервер Scale-out File Server и роль виртуальной машины Hyper-V, и вложенная/наследуемая виртуализация (nested virtualization) в Hyper-V, используемая для лабы.

Надеюсь, это видео про основные шаги при развертывании отказоустойчивого кластера Windows Server 2016 Failover Cluster будет полезным для тех, кому “вот прямо срочно” требуется развернуть кластер на Windows Server 2016 и запустить в нем те или иные роли.

СофТы: как развернуть и настроить кластер Windows Server 2016 Failover Clustering, ч.01

Но я пообещал более подробно (кроме собственно, развертывания кластера) раскрыть эту тему – поэтому в следующем “длинном” видео смотрите более подробно про настройки параметров ролей в кластере, а также – о создании гостевого кластера (кластера внутри кластера) для еще более бесперебойной работы и высокой доступности приложений.

И немного о вирусе Petya и украинской “эпидемии”

Продолжение темы про отказоустойчивые кластеры Windows Server 2016 – на этот раз про настройки собственно отказоустойчивости и высокой доступности. А предыдущее видео – про установку и начальную настройку самого кластера Windows Server 2016 Failover Clustering – смотрите тут.

В этом видео про настройку ролей в отказоустойчивом кластере Windows Server 2016 Failover Clustering вы найдете:

• как работает отказоустойчивость и высокая доступность в кластере Windows для “обычного” приложение – настройка количества сбоев, перезапуск/”переползание” приложения между узлами кластера, остановка приложения.

• работа приложений, поддерживающих распределенный режим работы и позволяющий им работать на всех (нескольких) узлах кластера одновременно – на примере Scale-Out File Server.

• Работа отказоустойчивой виртуальной машины Hyper-V в кластере.

• Настройка параметров восстановления роли кластера в случае сбоя одного из узлов кластера – возврат роли на оригинальны узел после восстановления работоспособности роли, настройка общих приоритетов работы роли и преференций по работе роли на разных узлах кластера Windows Server 2016.

• Настройка мониторинга отдельного сервиса внутри роли виртуальной машины кластера Hyper-V для мониторинга состояния отдельных процессов ВМ и ее общего здоровья, запущенной в кластере.

• И, конечно же, демонстрация “падения” одно из узлов кластера Windows Server 2016 и реакция на это событие разных типов ролей – подолжение процесса копирования файлов на Scale-out File Server, старт общей роли на втором узле кластера, и перезапуск виртуальной машины, которая “обрушилась” при падении узла кластера.

Смотрим, учимся, разбираемся и планируем отказоустойчивую работу и высокую доступность необходимых приложений под управлением Windows Server 2016 Failover Clustering.

СофТы: настройка отказоустойчивых ролей в кластере Windows Server 2016 Failover Clustering, ч.02

В продолжение темы про отказоустойчивые кластеры Windows Server 2016 – в следующем видео смотрите про создание гостевого кластера из виртуальных машин Hyper-V внутри основного (физического) кластера Windows Server 2016. Зачем? чтобы гарантировать еще более высокую доступность и надежность приложения, запущенного на виртуальной машине в кластере (которое будет тоже в кластере). Так что улучшается доступность чуть ли не на порядок 😉

Видео об ИТ-карьере – как стать ИТ-специалистом и заработать много денег:

Заключительное видео в серии по теме отказоустойчивого кластера Windows Server 2016 – создание гостевого кластера из виртуальных машин внутри основного кластера – такая себе фукурума 😉

Особенностью данного видео и основным отличием от первого видео – просто развертывания кластера Windows Server 2016 – в том, что гостевой кластер создается не просто так, а в режиме “Active Directory-Detached Cluster” – отключенного от Active Directory кластера Windows.

СофТы: установка гостевого Hyper-V кластера Windows Server 2016 без Active Directory, ч.03

Подробную инструкцию по развертыванию гостевого кластера Windows Server 2016 без Active Directory вы найдете в этом видео, а основные шаги по развертыванию такого отключенного от AD кластера Windows приводятся ниже:

• все узлы кластера должны быть зарегистрированы в каком-то из доменов (зон) DNS – для этого необходимо, чтобы DNS сервер поддерживал динамические обновления, суффиксы требуемого домена были прописаны в настройках серверов, а в настройках сетевых интерфейсов – стояли опции обязательной регистрации имени. Или вам потребуется создавать все записи в DNS зоне для узлов кластера, самого кластера и его ролей ручками.

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

• на каждом из узлов будущего кластера должна существовать учетная запись-локальный администратор с общими одинаковым именем и паролем. Также, должен быть отключен сетевой фильтеринг в UAC – тот самый ключ в реестре – New-ItemProperty -Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem -Name LocalAccountTokenFilterPolicy -Value 1
  ВНИМАНИЕ! Помните, что такой кластер представляет собой потенциальную жертву для атак типа pth/ptt – которые использует тот же Petya и другие вирусы (и просто хакеры). Поэтому смотрите видео про защиту от подобных атак Pass-the-Hash/Pass-the-ticket и, конечно же, читайте статью, посвященную стратегии защиты ИТ-инфраструктуры Defense-in-Depth на примере защиты от Petya.

А поскольку мы развертываем гостевой кластер из виртуальных машин и ему требуется также общие диски для своей работы – смотрите в данном видео сценарии, каким образом вы можете создать и где разместить такие диски в виде специальны общих виртуальных дисков Hyper-V (Shared Disk – VHDX или VHD Set). И, пожалуйста, не монтируйте диски гостевого кластера на те же LUN SAN/iSCSI, которые уже используются “большим” основным кластером – это приведет к катастрофическим последствиям для обеих систем.

Думаю, что все 3 инструкции по кластерам Windows Server 2016 помогут вам освоиться с базовыми аспектами работы с отказоустойчивыми кластерами Windows Server 2016 и их вариациями – гостевым кластером из виртуальных машин Hyper-V и кластером Windows без использования Активного Каталога.

Поэтому данную тему будем пока считать закрытой… Хотя есть масса нюансов в обслуживании повседневном кластеров и, конечно же, есть команды PowerShell, которые позволят намного быстрее и гибче развертывать и управлять кластерами Windows… Но это тема уже другой серии видео про кластеры Windows Server 2016.

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

Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

Немного ссылок на другие материалы для тех, кто хочет стать просто ИТ-специалистом – смотрите первые шаги по созданию тестового рабочего места:

И смотрите другие видео для ИТ-специалистов у меня на канале:

Видео про новые возможности дисков и дисковых массивов:

Также, по просьбам посетителей – меня найти можно (добавляйтесь в друзья и подписчики):

Время прочтения
13 мин

Просмотры 39K

Автор статьи – Роман Левченко (www.rlevchenko.com), MVP – Cloud and Datacenter Management

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

Cluster OS Rolling upgrade

Миграция кластера в прошлых версиях 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.

Процесс CRU на примере 2-х узлового кластера Hyper-V:

1. Рекомендуется предварительное резервное копирование кластера (БД) и выполняемых ресурсов. Кластер должен быть в работоспособном состоянии, узлы доступны. При необходимости следует исправить имеющиеся проблемы перед миграцией и приостановить задачи резервного копирования перед стартом перехода.

   

2. Обновить узлы кластера Windows Server 2012 R2, используя Cluster Aware Updating (CAU) или вручную через WU/WSUS.
3. При имеющемся настроенном CAU необходимо временное его отключение для предотвращения его возможного воздействия на размещение ролей и состояния узлов во время перехода.

   

4. CPU на узлах должны иметь поддержку SLAT для поддержки выполнения виртуальных машин в рамках WS2016. Данное условие является обязательным.
5. На одном из узлов выполняем перенос ролей (drain roles) и исключение из кластера (evict):

   

6. После исключения узла из кластера выполняем рекомендуемую полную установку WS2016 (clean OS install, Custom: Install Windows only (advanced))

   

7. После переустановки верните сетевые параметры обратно*, обновите узел и установите необходимые роли и компоненты. В моем случае требуется наличие роли Hyper-V и, конечно, Failover Clustering.

   New-NetLbfoTeam -Name HV -TeamMembers tNIC1,tNIC2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

   Add-WindowsFeature Hyper-V, Failover-Clustering -IncludeManagementTools -Restart

   New-VMSwitch -InterfaceAlias HV -Name VM -MinimumBandwidthMode Weight -AllowManagementOS 0

   * использование Switch Embedded Teaming возможно только после полного завершения перехода на WS2016.

8. Добавьте узел в соответствующий домен.

   Add-Computer -ComputerName HV01 -DomainName domain.com -DomainCredential domainrlevchenko

9. Возвращаем узел в кластер. Кластер начнет работать в смешанном режиме поддержки функциональности WS2012R2 без поддержки новых возможностей WS2016. Рекомендуется завершить обновление оставшихся узлов в течение 4 недель.

   

10. Перемещаем кластерные роли обратно на узел HV01 для перераспределения нагрузки.
11. Повторяем шаги (4-9) для оставшейся ноды (HV02).
12. После обновления узлов до WS2016 необходимо поднять функциональный уровень (Mixed Mode – 8.0, Full – 9.0) кластера для завершения миграции.

    PS C:Windowssystem32> 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

    Name
    — Hvcl

13. (опционально и с осторожностью) Обновление версии конфигурации ВМ для включения новых возможностей Hyper-V. Требуется выключение ВМ и желателен предварительный бекап. Версия ВМ в 2012R2 – 5.0, в 2016 RTM – 8.0.В примере показана команда для обновления всех ВМ в кластере:

    Get-ClusterGroup|? {$_.GroupType -EQ "VirtualMachine"}|Get-VM|Update-VMVersion

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

    

Cloud Witness

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

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

Cloud Witness использует ресурсы Microsoft Azure (Azure Blob Storage, через HTTPS, порты на узлах должны быть доступны) для чтения/записи служебной информации, которая изменяется при смене статуса кластерных узлов. Наименование blob-файла производится в соответствии с уникальным идентификатором кластера, — поэтому один Storage Account можно предоставлять нескольким кластерам сразу (1 blob-файл на кластер в рамках создаваемого автоматически контейнера msft-cloud-witness). Требования к размеру облачного хранилища минимальны для обеспечения работы witness и не требует больших затрат на его поддержку. Так же размещение в Azure избавляет от необходимости третьего сайта при конфигурации Stretched Cluster и решения по его аварийному восстановлению.

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

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

Процесс создания и добавления Cloud Witness достаточно прост:

1. Создайте новый Azure Storage Account (Locally-redundant storage) и в свойствах аккаунта скопируйте один из ключей доступа.

   

2. Запустите мастер настройки кворумной конфигурации и выберите Select the Quorum Witness – Configure a Cloud Witness.

   

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

   

4. После успешного завершения мастера конфигурации, Witness появится в Core Resources.

   
5. Blob-файл в контейнере:

   

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

   

Workgroup and Multi-Domain Clusters

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

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

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

  Install-WindowsFeature Failover-Clustering -IncludeManagementTools

• На каждом из узлов требуется создать пользователя с членством в группе Administrators или использовать built-in уч. запись. Пароль и наименование пользователя должны быть идентичны.

  

  net localgroup administrators cluadm /add

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

  New-ItemProperty -Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem -Name LocalAccountTokenFilterPolicy -Value 1

• Primary DNS -suffix на узлах должен быть определен.

  

• Создание кластера поддерживается как через PowerShell, так и через GUI.

  New-Cluster -Name WGCL -Node rtm-1,rtm-2 -AdministrativeAccessPoint DNS  -StaticAddress 10.0.0.100

• В качестве Witness возможно использование только Disk Witness или описанный ранее Cloud Witness. File Share Witness, к сожалению, не поддерживается.

Поддерживаемые сценарии использования:

Virtual Machine Load Balancing / Node Fairness

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

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

Предельные допустимые значения загрузки определяются значением AutoBalancerLevel:

get-cluster| fl *autobalancer*
AutoBalancerMode  : 2
AutoBalancerLevel : 1

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

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

AutoBalancerLevel: 2

(Get-Cluster).AutoBalancerLevel = 2

AutoBalancerMode: 2

(Get-Cluster).AutoBalancerMode = 2

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

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

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

Virtual machine start ordering

Изменение логики старта ВМ в рамках кластера в 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: {Clu-VM01}
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. Пример:

Set-ClusterGroupSet Application -StartupDelayTrigger Delay -StartupDelay 30

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

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

StartupDelay – время задержки в секундах. 20 секунд по умолчанию.

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

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

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

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

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

VM Compute/Storage Resiliency

В 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:

(Get-Cluster). QuarantineDuration = 1800

Storage Resiliency

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

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

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

Site-Aware/Stretched Clusters и Storage Replica

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

Ранее нам советовали сторонние решения (много $) для создания полноценных распределенных кластеров (обеспечение 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).

New-ClusterFaultDomain –Name Voronezh –Type Site –Description “Primary” –Location “Voronezh DC”
New-ClusterFaultDomain –Name Voronezh2 –Type Site –Description “Secondary” –Location “Voronezh DC2”
New-ClusterFaultDomain -Name Rack1 -Type Rack 
New-ClusterFaultDomain -Name Rack2 -Type Rack
New-ClusterFaultDomain -Name HPc7000 -type Chassis
New-ClusterFaultDomain -Name HPc3000 -type Chassis
Set-ClusterFaultDomain –Name HV01 –Parent Rack1
Set-ClusterFaultDomain –Name HV02 –Parent Rack2
Set-ClusterFaultDomain Rack1,HPc7000 -parent Voronezh
Set-ClusterFaultDomain Rack2,HPc3000 -parent Voronezh2

Такой подход в рамках мульти-сайт кластера несет следующие плюсы:

• Отработка Failover первоначально происходит между узлами в рамках Fault домена. Если все узлы в Fault Domain недоступны, то только тогда переезд на другой.
• Draining Roles (миграция ролей при режиме обслуживания и т.д.) проверяет возможность переезда сначала на узел в рамках локального сайта и только потом перемещает их на иной.
• Балансировка CSV (перераспределение кластерных дисков между узлами) так же будет стремиться отрабатывать в рамках родного fault-домена/сайта.
• ВМ будут стараться располагаться в том же сайте, где и их зависимые CSV. Если CSV мигрируют на другой сайт, то ВМ через 1 минуту начнут свою миграцию на тот же сайт.

Дополнительно, используя логику site-awareness, возможно определение «родительского» сайта для всех вновь создаваемых ВМ/ролей:

(Get-Cluster).PreferredSite = <наименование сайта>

Или настроить более гранулярно для каждой кластерной группы:

(Get-ClusterGroup -Name  ИмяВМ).PreferredSite = <имя предпочтительного сайта>

Другие нововведения

• Поддержка Storage Spaces Direct и Storage QoS.
• Изменение размера shared vhdx для гостевых кластеров без простоя, поддержка Hyper-V репликации и рез. копирования на уровне хоста.
• Улучшенная производительность и масштабирование CSV Cache с поддержкой tiered spaces, storage spaces direct и дедупликации (отдать десятки ГбБ RAM под кеш – без проблем).
• Изменения в формировании журналов кластера (информация о временном поясе и т.д.) + active memory dump (новая альтернатива для full memory dump) для упрощения диагностирования проблем.
• Кластер теперь может использовать несколько интерфейсов в рамках одной и той же подсети. Конфигурировать разные подсети на адаптерах не требуется для их идентификации кластером. Добавление происходит автоматически.

На этом наш обзорный тур по новым функциям WSFC в рамках Windows Server 2016 завершен. Надеюсь, что материал получился полезным. Спасибо за чтение и комментарии.

Отличного всем дня!

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

• Процессор: от 4 ядер
• Оперативная память : 1 ГБ на каждого пользователя + 4 ГБ для работы ОС + 4 ГБ запас
• Дисковая система: для большей отказоустойчивости нужно настроить RAID-массив
  Для установки выделить два диска: первый логический диск от 50 ГБ. До 100 ГБ выделить для установки ОС, второй логический диск выделить под пользовательские профили с расчетом минимум 1 ГБ на пользователя
• Ширина канала для терминального сервера: 250 Кбит/с на пользователя

У нас вы можете взять терминальный сервер 1С в аренду с бесплатными индивидуальными настройками.

Первоначальные настройки Windows Server 2016:

1. Настроить статический IP-адрес сервера
2. Проверить правильность настройки времени и часового пояса
3. Установить все обновления системы
4. Задать понятное имя для сервера и, при необходимости, ввести его в домен
5. Включить доступ до сервера по удаленному рабочему столу для удаленного администрирования
6. Настроить запись данных профилей пользователей на второй логический диск
7. Активировать лицензию Windows Server 2016

Настройка терминального сервера

Начиная с Windows 2012 терминальный сервер должен работать в среде Active Directory.

Если в вашей локальной сети есть контроллер домена, просто присоединяйте к нему сервер терминалов, иначе установите на сервер роль контроллера домена.

Установка роли и компонентов

В панели быстрого запуска открываем Диспетчер серверов:

Нажимаем Управление — Добавить роли и компоненты:

Нажимаем Далее до «Выбор типа установки». Оставляем Установка ролей и компонентов и нажимаем Далее дважды:

В окне «Выбор ролей сервера» выбираем Службы удаленных рабочих столов:

Кликаем Далее, пока не появится окно «Выбор служб ролей» и выбираем следующие:

• Лицензирование удаленных рабочих столов
• Узел сеансов удаленных рабочих столов

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

При необходимости, также выставляем остальные галочки:

• Веб-доступ к удаленным рабочим столам — возможность выбора терминальных приложений в браузере.
• Посредник подключений к удаленному рабочему столу — для кластера терминальных серверов посредник контролирует нагрузку каждой ноды и распределяет ее.
• Узел виртуализации удаленных рабочих столов — для виртуализации приложений и запуска их через терминал.
• Шлюз удаленных рабочих столов — центральный сервер для проверки подлинности подключения и шифрования трафика. Позволяет настроить RDP внутри HTTPS.

Нажимаем Далее и в следующем окне Установить. Дожидаемся окончания процесса установки и перезагружаем сервер.

Установка служб удаленных рабочих столов

После перезагрузки открываем Диспетчер серверов и нажимаем Управление — Добавить роли и компоненты:

В окне «Выбор типа установки» выбираем Установка служб удаленных рабочих столов и нажимаем Далее:

В окне «Выбор типа развертывания» выбираем Быстрый запуск и нажимаем Далее:

В «Выбор сценария развертывания» — Развертывание рабочих столов на основе сеансов — Далее:

Еще раз Далее — при необходимости, ставим галочку «Автоматически перезапускать конечный сервер, если это потребуется» и кликаем по Развернуть.

Настройка лицензирования удаленных рабочих столов

Для корректной работы сервера, необходимо настроить службу лицензирования. Для этого открываем диспетчер серверов и кликаем по Средства — Remote Desktop Services — Диспетчер лицензирования удаленных рабочих столов:

В открывшемся окне кликаем правой кнопкой мыши по нашему серверу и выбираем Активировать сервер:

В открывшемся окне дважды кликаем Далее — заполняем форму — Далее — Далее — Снимаем галочку «Запустить мастер установки лицензий» — Готово.

Снова открываем диспетчер серверов и переходим в «Службы удаленных рабочих столов»:

В «Обзоре развертывания» кликаем по Задачи — Изменить свойства развертывания:

В открывшемся окне переходим в Лицензирование — Выбираем тип лицензий — прописываем имя сервера лицензирования (в данном случае локальный сервер) и нажимаем Добавить:

Применяем настройки, нажав OK.

Добавление лицензий

Открываем диспетчер серверов и кликаем по Средства — Remote Desktop Services — Диспетчер лицензирования удаленных рабочих столов:

В открывшемся окне кликаем правой кнопкой мыши по нашему серверу и выбираем Установить лицензии:

В открывшемся окне нажимаем Далее:

Выбираем программу, по которой куплены лицензии, например, Enterprise Agreement:

Нажимаем Далее — вводим номер соглашения и данные лицензии — выбираем версию продукта, тип лицензии и их количество:

Нажимаем Далее — Готово.

Проверить статус лицензирования можно в диспетчере серверов: Средства — Remote Desktop Services — Средство диагностики лицензирования удаленных рабочих столов.

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

Естественно, что на всех узлах кластера нужно устаровить Windows Server 2016. Поддерживаются следующие сценарии кластеризации:

Поддерживается, но не рекомендуется
Не поддерживается Kerberos-аутентфикация для SMB

Hyper-V

Поддерживается, но не рекомендуется
Не поддерживается режим Live Migration, доступна только Quick migration

Message Queuing (MSMQ)
Не поддерживается
MSMQ хранит свои свойства в Active Directory.

На всех будущих узлах кластера нужно

1. Установить роль Failover Clustering: Install-WindowsFeature Failover-Clustering –IncludeManagementTools
2. На каждой кластерной ноде нужно создать локальную учетную запись с правами администратора (или использовать встроенную учетку администратора) с одинаковыми паролями.
   net user /add clustadm Pa$$word!
   net localgroup administrators clustadm /add
3. При появлении ошибки Requested Registry access is not allowed, необходимо изменить в реестре параметр удаленного UAC — Данный ключ разрешает удаленный доступ к административным шарам.
   New-ItemProperty -Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem -Name LocalAccountTokenFilterPolicy -Value 1
4. На всех узлах кластера нужно задать одинаковой первичный DNS суффикс (PrimaryDNSsuffix). Это нужно для того, чтобы сервера кластера могли обращаться друг к другу по FQDN именам
5. Также нужно снять галку Register DNS connection addresses
6. В файл hosts на всех узлах кластера нужно внести изменения, чтобы сервера могли отрезолвить имена других членов кластера, а также имя кластера (в том числе FQDN имена). Добавить имена в файл c:windowssystem32driversetchosts можно так:
   Set file=»%windir%System32driversetchosts»
   echo 192.168.1.21 clust-host1 >> %file%
   echo 192.168.1.21 clust-host1.mylocal.net >> %file%
   echo 192.168.1.22 clust-host2 >> %file%
   echo 192.168.1.22 clust-host2.mylocal.net >> %file%
   echo 192.168.1.20 cluster1 >> %file%
   echo 192.168.1.20 cluster1.mylocal.net>> %file%

Для предварительной валидации узлов кластера можно воспользоваться командой:

test-cluster -node «clust-host1.mylocal.net»,» clust-host2.mylocal.net»

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

New-Cluster -Name cluster1 -Node clust-host1.mylocal.net, clust-host2.mylocal.net -AdministrativeAccessPoint DNS -StaticAddress 192.168.1.20

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

Для подключения (и удаленного управления) кластером через GUI нужно воспользоваться оснасткой Failover Cluster Manager (входит в состав) RSAT для Windows 10.

Теперь с помощью пункта меню Connect to cluster можно подключаться к созданному кластеру. В том случае, если в кластере четное количество серверов, придется настроить ресурс-свидетель. Отметим, что в качестве кворумного свидетеля нельзя использовать сетевую папку SMB. Поддерживается режим Disk Witness — общий диск (с одновременным доступом к нему с обоих узлов), либо Cloud Witness — облачный дисковый ресурс в Azure.

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

Шаг №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 системе:

Win + R – control.exe – Администрирование – «Диспетчер серверов» — «Управление» — «Добавить роли и компоненты» и отмечаю галочкой, а на уведомление мастера установки, что к выбранному необходимы дополнительные компоненты соглашаюсь нажатием кнопку «Добавить компоненты»

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

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

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

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

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

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

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

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

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

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

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

Win + R – control.exe – Администрирование – «Диспетчер серверов» — перехожу в группу серверов srv-noda и через правый клик мышью по сервер srv-noda2 выбираю меню «Перезапустить сервер» и подтверждаю свое намерение нажатием кнопки «ОК». Пока сервер в перезагрузку проделываю все шаги с третьим сервером.

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

Mstsc – srv-noda1.polygon.local – Win + R – control – Администрирование – «Диспетчер отказоустойчивости кластеров» — потом через правый клик мышью по «Диспетчер отказоустойчивости кластеров» выбираю действие «Проверить конфигурацию» на предмет создания кластера.

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

• Введите имя: — Обзор – нахожу всех srv-noda[1-3], выделяю их и указываю имя объединяющее их это: srv-cluster, получается следующее:
• Выбранные серверы: srv-noda1.polygon.local,srv-noda2.polygon.local,srv-noda3.polygon.local

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

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

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

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

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

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

C:Windowssystem32>sconfig

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

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

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

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

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

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

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

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

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

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

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

Win + R – control.exe – Администрирование – «Диспетчер отказоустойчивости кластеров» — перейти в «Хранилище» — «Диски» и увидеть все диски кластера (либо это LUN, либо это логические тома), выделяю в моем случаем «Диск кластера 2»

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

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

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

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

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

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

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

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

Общее имя кластера: HVCLUSTER2016 (IP адрес 10.0.0.10)
Первый сервер: имя HOST01, с двумя интерфейсами
10.0.0.11 – интерфейс управления, и трафика виртуальных машин
10.0.1.11 – интерфейс для трафика Cluster Shared Volume и Heartbeat
Второй сервер: имя HOST02, с двумя интерфейсами
10.0.0.12 — интерфейс управления, и трафика виртуальных машин
10.0.1.12 – интерфейс для трафика Cluster Shared Volume и Heartbeat

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

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

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

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

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

Нужно дождаться окончания валидации. Если будут найдены ошибки – их нужно исправить. После этого нажать на Finish.

Далее на странице настройки 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.

В статье приводится краткий обзор
создания отказоустойчивого кластера 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.

Вы можете отправить запрос к новому компьютеру, чтобы убедиться в его доступности (если ICMP-запросы разрешены в брандмауере Windows).

В качестве альтернативы можно создать кластер с помощью 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