This article gives a short overview of how to create a Microsoft Windows Failover Cluster (WFC) with Windows Server 2019 or 2016. The result will be a two-node cluster with one shared disk and a cluster compute resource (computer object in Active Directory).
Preparation
It does not matter whether you use physical or virtual machines, just make sure your technology is suitable for Windows clusters. Before you start, make sure you meet the following prerequisites:
Two Windows 2019 machines with the latest updates installed. The machines have at least two network interfaces: one for production traffic, one for cluster traffic. In my example, there are three network interfaces (one additional for iSCSI traffic). I prefer static IP addresses, but you can also use DHCP.
Join both servers to your Microsoft Active Directory domain and make sure that both servers see the shared storage device available in disk management. Don’t bring the disk online yet.
The next step before we can really start is to add the Failover clustering feature (Server Manager > add roles and features).
Reboot your server if required. As an alternative, you can also use the following PowerShell command:
Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools
After a successful installation, the Failover Cluster Manager appears in the start menu in the Windows Administrative Tools.
After you installed the Failover-Clustering feature, you can bring the shared disk online and format it on one of the servers. Don’t change anything on the second server. On the second server, the disk stays offline.
After a refresh of the disk management, you can see something similar to this:
Server 1 Disk Management (disk status online)
Server 2 Disk Management (disk status offline)
Failover Cluster readiness check
Before we create the cluster, we need to make sure that everything is set up properly. Start the Failover Cluster Manager from the start menu and scroll down to the management section and click Validate Configuration.
Select the two servers for validation.
Run all tests. There is also a description of which solutions Microsoft supports.
After you made sure that every applicable test passed with the status “successful,” you can create the cluster by using the checkbox Create the cluster now using the validated nodes, or you can do that later. If you have errors or warnings, you can use the detailed report by clicking on View Report.
If you choose to create the cluster by clicking on Create Cluster in the Failover Cluster Manager, you will be prompted again to select the cluster nodes. If you use the Create the cluster now using the validated nodes checkbox from the cluster validation wizard, then you will skip that step. The next relevant step is to create the Access Point for Administering the Cluster. This will be the virtual object that clients will communicate with later. It is a computer object in Active Directory.
The wizard asks for the Cluster Name and IP address configuration.
As a last step, confirm everything and wait for the cluster to be created.
The wizard will add the shared disk automatically to the cluster per default. If you did not configure it yet, then it is also possible afterwards.
As a result, you can see a new Active Directory computer object named WFC2019.
You can ping the new computer to check whether it is online (if you allow ping on the Windows firewall).
As an alternative, you can create the cluster also with PowerShell. The following command will also add all eligible storage automatically:
New-Cluster -Name WFC2019 -Node SRV2019-WFC1, SRV2019-WFC2 -StaticAddress 172.21.237.32
You can see the result in the Failover Cluster Manager in the Nodes and Storage > Disks sections.
The picture shows that the disk is currently used as a quorum. As we want to use that disk for data, we need to configure the quorum manually. From the cluster context menu, choose More Actions > Configure Cluster Quorum Settings.
Here, we want to select the quorum witness manually.
Currently, the cluster is using the disk configured earlier as a disk witness. Alternative options are the file share witness or an Azure storage account as witness. We will use the file share witness in this example. There is a step-by-step how-to on the Microsoft website for the cloud witness. I always recommend configuring a quorum witness for proper operations. So, the last option is not really an option for production.
Just point to the path and finish the wizard.
After that, the shared disk is available for use for data.
Congratulations, you have set up a Microsoft failover cluster with one shared disk.
Next steps and backup
One of the next steps would be to add a role to the cluster, which is out of scope of this article. As soon as the cluster contains data, it is also time to think about backing up the cluster. Veeam Agent for Microsoft Windows can back up Windows failover clusters with shared disks. We also recommend doing backups of the “entire system” of the cluster. This also backs up the operating systems of the cluster members. This helps to speed up restore of a failed cluster node, as you don’t need to search for drivers, etc. in case of a restore.
See More:
- On-Demand Sessions from VeeamON Virtual
Данная статья подойдёт для новичков, которые хотят потренироваться в настройке кластера Hyper-V 2019. Итак, имеется:
— Тестовый комп1 «железный»
— Тестовый комп2 «железный»
— Тестовый комп3 «виртуальный» с Windows srv 2019 и настроенной ролью контроллера домена.
— Тестовый комп4 «железный» с расшаренным диском по протоколу iSCSI.
— Всё это соединено через обычный пассивный коммутатор.
На тестовый комп1 установлена Windows Srv 2019 Standard Evaluation с графической оболочкой. На тестовый комп2 установлена Microsoft Hyper-V Server 2019 — данная ОС бесплатна и устанавливается как обычная Windows 10/2019. Скачать эту ОС можно с оф.сайта Microsoft:
https://www.microsoft.com/ru-ru/evalcenter/evaluate-hyper-v-server-2019
Собственно, на этой же странице можно скачать и Windows Srv 2019 Standard Evaluation. И если, после установки Windows Srv 2019 с графической оболочкой, вопросов о том, как ей пользоваться дальше, нету, то после установки Hyper-V Server 2019 могут возникнуть вопросы, что с этой ОС делать дальше. Ведь у Hyper-V Server 2019 графической оболочки нет. После установки есть лишь вот такое окно:
Здесь можно сделать самые основные настройки: задать имя компьютера, прописать статический IP, включить доступ по RDP.
Для дальнейшего удобства администрирования данной ОС, я установлю пару инструментов. Первый из них — это банальный Total Commander portable, который я просто скопирую на диск C: с флэшки. Сделать это можно командой:
xcopy f:\totalcmd c:\totalcmd\ /y /e
Где f:\totalcmd — это каталог с total командером на флэшке, а c:\totalcmd\ — каталог, в который копирую.
Потом перехожу в этот каталог и запускаю тотал командер:
c:
cd c:\totalcmd
totalcmd.exe
Дальше уже будет проще. Пользуясь тотал командером, нахожу каталог с драйверами и устанавливаю их.
Следующий инструмент, который облегчит администрирование Hyper-V Server 2019 — это WINDOWS ADMIN CENTER. Это вэб-админка от Microsoft, с помощью которой можно администрировать сервер через вэб-интерфейс. Некий аналог Webmin, но для Windows-систем. Скачать его можно на той же странице, где скачивались установочные образы операционных систем:
https://www.microsoft.com/ru-ru/evalcenter/evaluate-windows-admin-center
Дистрибутив Windows админ центра можно тоже перенести через флэшку на сервер.
Установка данного программного обеспечения самая обычная, где все параметры можно оставить по умолчанию.
После установки Windows админ центра нужно зайти на сервер через обычный браузер по https протоколу:
https://192.168.0.206/
Сообщение безопасности нужно игнорировать, т.к. используется самоподписанный сертификат. Логин и пароль при подключении — это виндовый «администратор» с его паролем в самой ОС. Вот так выглядит Windows Admin Центр:
В списке серверов выбираю свой, который также стал шлюзом Windows AdminЦентра. Ну и подробно на всех возможностях останавливаться не буду, т.к. их много. Вэб-интерфейс хоть и тормозной, но довольно функциональный — через него можно будет управлять и виртуальными машинами в том числе. Или, например, если какие-то драйвера не установлены, то их можно доустановить уже через Windows AdminЦентр:
Я же пробую ввести данный сервер в домен. Жму на меню «Обзор» и затем на «Изменить идентификатор компьютера».
Ну а дальше, всё как обычно:
Сервер перезагрузится. После чего, в Windows Admin Центр рекомендуется войти уже под доменным администратором! Имя пользователя надо вводить в таком формате:
Ну и кстати, желательно бы установить обновления для Windows Admin Центра, если они есть. Для этого надо нажать на шестерёнку и выбрать пункт «расширения». Ну и там дальше всё понятно будет:
Разобравшись с сервером на ОС Hyper-V Server 2019, сделаю всё то же самое и на сервере под управлением Windows Srv 2019 Standard Evaluation. Там уже всё делается в привычном виде — через графическую оболочку Windows. Установил драйверы, ввел сервер в домен AD — подробности этого всего описывать не буду.
Следующим шагом будет подключение сетевого диска iSCSI. Захожу в «Средства администрирования»:
И там выбираю Инициатор iSCSI:
При первом запуске выйдет сообщение о том, что служба iSCSI не запущена, и будет предложено запустить эту службу и включить её автозапуск при старте сервера. Ну а потом появится окно, в котором надо будет перейти на вкладку «Обнаружение» и нажать на кнопку «Обнаружить портал»:
Затем надо ввести IP-адрес сервера iSCSI:
В моём случае, этого будет достаточно. Но если iSCSI сервер требует пароль для подключения к себе, то надо нажать кнопку «Дополнительно» и там ввести этот пароль.
Далее, надо перейти на вкладку «Конечные объекты» и нажать кнопку «Подключить»:
В появившемся окне надо нажать на «ОК», после чего диск перейдёт в состояние «Подключено»:
Всё, это окно можно закрывать. Дальше надо зайти в диспетчер управления дисками, в котором отобразится подключенный iSCSI диск. Его надо проинициализировать и отформатировать в NTFS:
Сильно подробно это не буду расписывать. Уверен, что форматировать диск под NTFS умеют все ИТ-специалисты. После форматирования можно попробовать что-нибудь записать на него, чтобы убедиться в работоспособности диска.
Далее, этот же диск надо подключить на втором сервере под управлением Hyper-V Server 2019. На самом деле, там это всё делается точно также. Надо лишь в командной строке ввести:
iscsicpl
Появится точно такое же окно, как и на сервере с графической оболочкой:
Нужно проделать те же действия, что и на первом сервере. Но в диспетчер дисков заходить уже не нужно. Достаточно просто подключить диск по iSCSI.
Теперь снова перехожу к серверу под управлением Windows Srv 2019 Standard Evaluation, на котором нужно установить роль Hyper-V, а также роль Кластера. В диспетчере сервером жму «Добавить роли и компоненты»:
В первом шаге жму «далее», потом снова «далее», оставив на месте крыжик «Установка ролей или компонентов». Выбираю в списке свой сервер, который там пока один, жму «далее»:
Ставлю галку на Hyper-V и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму «далее». На следующем шаге, где уже предлагается выбрать компоненты, ставлю галку на «Отказоустойчивой кластеризации» и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму кнопку «Далее». На следующем шаге предлагается сразу создать виртуальный коммутатор, но я пока не буду. Создам его потом вручную. Просто жму «Далее».
На следующем шаге предлагается включить и выбрать протокол для динамической миграции. Однако внизу есть предупреждение, что если данный сервер будет членом кластера, то этого делать на надо. Поэтому ничего не трогаю и жму «далее».
Расположение по умолчанию дисков и конфигурации виртуальных машин тоже пока не трогаю. Эти значения надо менять уже после настройки кластера. Жму «далее», а затем «установить». Дожидаюсь окончания установки.
Теперь кое-какие компоненты надо установить на машине с Hyper-V Server 2019. Для этого открываю диспетчер серверов на машине с Windows Srv 2019 Standard Evaluation и жму «Добавить другие серверы для управления»:
В поле «Имя» ввожу имя компьютера машины Hyper-V Server 2019, жму «найти» и потом добавляю его в правый список. Жму «ОК»:
Потом жму «Добавить роли и компоненты» и на шаге, где предлагается выбрать сервер, выбираю машину с Hyper-V Server 2019:
На шаге с выбором ролей сервера ничего не трогаю и жму «далее». А вот на шаге выбора компонентов добавляю «Отказоустойчивую кластеризацию» и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму «далее» и «установить», дожидаюсь окончания установки.
Теперь надо создать кластер. На машине Windows Srv 2019 Standard Evaluation захожу в «средства администрирования» и выбираю «Диспетчер отказоустойчивости кластеров»:
В открывшемся окне жму «Создать кластер».
На первом шаге «Перед началом работы» жму «далее». А на следующем шаге выбираю, какие серверы будут членами кластера:
На следующем шаге предлагается выполнить проверочные тесты для выбранных серверов. Пусть выполнит. Оставляю «да» и жму «далее».
Откроется дополнительный мастер с вопросом, какие тесты выполнить. Оставляю «Выполнить все тесты» и жму «далее».
Запускается тестирование, жду его окончания:
У меня тестирование нашло ошибки, которые я и предполагал, что будут:
Да, действительно, у меня тестовые компы на разных процессорах. Один на Intel Xeon 2620 v3, а второй на AMD FX 8350. Но других компов у меня нет, да и это лишь тестовая установка. Сеть у меня тоже одна, хотя рекомендуется иметь выделенную сеть для соединения с дисками iSCSI. Ну и разные версии операционных систем я выбрал нарочно — хочу посмотреть, как оно будет работать именно в таком варианте. Повторюсь, что установка тестовая, в домашних условиях и лишь для ознакомления. Для продакшена надо делать следуя рекомендациям Microsoft.
После тестов появляется следующий шаг, на котором надо задать имя кластера и указать его IP-адрес:
Жму «далее». Здесь тоже жму «далее»:
После создание кластера появится такое окно:
Иии… Сразу обращаю внимание, что есть какие-то ошибки.
Смотрю их подробнее:
Ресурсу сетевого имени «Имя кластера» кластера не удалось зарегистрировать одно или несколько связанных DNS-имен по следующей причине:
Неверный раздел DNS.
Убедитесь, что сетевые адаптеры, связанные с зависимыми ресурсами IP-адресов, настроены для доступа хотя бы к одному DNS-серверу.
И действительно на DNS-сервере запись о кластере не добавилась. Причину тому не знаю:
Но не страшно, добавляю эту запись вручную.
После создания кластера надо настроить для него параметры кворума. Что это за кворум, почитать можно тут:
https://docs.microsoft.com/ru-ru/windows-server/storage/storage-spaces/understand-quorum
Вообще, мастер установки сделал правильно. Он под кворум забрал диск iSCSI. Но дело в том, что это мой единственный диск iSCSI, который я хочу использовать под виртуальные машины, а не под кворум. Кворум можно разместить в обычной сетевой папке. Поэтому захожу вот сюда:
Там выбираю «Выбрать свидетель кворума»:
И дальше выбираю «Настроить файловый ресурс-свидетель»:
И указываю сетевую папку:
Потом жму везде «далее».
Важно! В правах доступа к этому каталогу должны быть указаны не только администраторы, но и сам кластер:
Добавить его можно, включив галку «Компьютеры» вот тут:
После того, как диск высвободился из-под кворума, добавляю его в общие тома кластера:
Теперь надо добавить виртуальный коммутатор на обе машины. Важно, чтобы виртуальные коммутаторы имели одинаковое название. Создать их можно как через оснастку на Windows Srv 2019 Standard Evaluation, так и через Windows Admin Center. Я, ради интереса, создам виртуальный коммутатор на машине с Windows Srv 2019 Standard Evaluation через Windows Admin Center. А виртуальный коммутатор на машине с Hyper-V Server 2019 создам через оснастку на Windows Srv 2019 Standard Evaluation.
Итак, захожу в Windows Admin Center и выбираю «Диспетчер кластеров»:
Потом жму «Добавить»:
И справа будет предложено ввести имя кластера, а также учётные данные для подключения к нему. Заполняю и жму «Подключитесь с помощью учётной записи»:
Потом жму «Добавить»:
Теперь вижу кластер в списке хостов для управления через Windows Admin Center. Выбираю его:
Ну а там перехожу в меню «Виртуальные коммутаторы» и жму «Создать».
Ну а там дальше выбираю узел, задаю название коммутатора и тип выбираю ему внешний. Жму создать.
Во время создания виртуального коммутатора отвалится ненадолго связь с машиной, на которой он создаётся. Потом он отобразится в списке виртуальных коммутаторов:
Теперь создам виртуальный коммутатор для машины с Hyper-V Server 2019, но через оснастку на машине Windows Srv 2019 Standard Evaluation. Открываю «Средства администрирования» и выбираю оснастку «Диспетчер Hyper-V»:
Там выбираю «Подключиться к серверу», пишу его имя и жму «ОК»:
Дальше захожу в «Диспетчер виртуальных коммутаторов»:
Выбираю внешний и жму «Создать виртуальный коммутатор»:
Задаю такое же имя, как и на первой машине, жму «ОК»:
Выйдет предупреждение, что связь с машиной потеряется на некоторое время. Соглашаюсь и жду завершения. После чего снова захожу в «Диспетчер виртуальных коммутаторов» и вижу, что коммутатор там появился:
Также его можно видеть и через Windows Admin Center:
Что ж, пришло время создать виртуальную машину. Я попробую что-нибудь лёгкое, например, виртуальную машину с Windows XP. Создаю:
Выбираю хост:
Задаю название машины и расположение её конфигурации. Каталог C:\ClusterStorage\volume1 — это и есть тот самый iSCSI диск.
Далее предлагается выбрать поколение виртуальной машины. Для Windows XP надо выбирать первое поколение.
Оперативной памяти выделяю 1Гб, хватит сполна.
Далее настройка сети. Там выбираю виртуальный коммутатор komm1.
Дальше мастер предлагает сразу создать виртуальный диск для этой виртуальной машины. Для XP большой диск не нужен. Также указываю месторасположение диска — тоже на ресурсе iSCSI:
Жму «Далее». На следующем шаге предлагается выбрать установочный носитель с операционной системой. В моём случае, он лежит на флэшке, подключенной к серверу. Выбираю его:
Жму «далее», жму «готово» и получаю вот такую непонятную ошибку:
Не удалось создать виртуальную машину. Проблема оказалась в правах доступа файловой системы. Мастер не мог создать виртуальную машину, т.к. у него просто не было доступа в указанный каталог. Дал вот такие права, и виртуальная машина создалась:
Пробую запустить и установить Windows XP. Жму сначала «Запустить», а потом «Подключить»:
Началась установка Windows XP. Кстати, эту виртуальную машину видно и в Windows Админ Центре:
И от туда к ней тоже можно подключиться:
После установки в Windows XP даже мышь работать не будет. Чтобы всё заработало, надо установить службы интеграции. Установочный образ можно взять тут:
https://disk.yandex.ru/d/b8dcTwIQerC-EQ/vmguest.iso
А затем подставить его в свойствах виртуальной машины вместо установочного образа Windows XP:
Это можно сделать даже при включённой виртуальной машине. Сработает автозапуск с виртуального CD, и интеграционные службы начнут сразу устанавливаться:
Потом установщик попросит перезагрузку. После перезагрузки Windows XP будет работать абсолютно нормально.
Теперь хочется проверить, как виртуальная машина будет переходить с одного узла на другой в кластере. Пробую запустить динамическую миграцию на узел Hyper1:
И получаю ошибку. В подробных сведениях написано вот что:
Собственно, это то, о чём и предупреждал мастер создания кластера на этапе тестирования. Невозможно произвести динамическую миграцию от узла с процессором Intel на узел с процессором AMD. И наоборот — тоже нельзя. Но зато можно это сделать, завершив работу виртуальной машины. Пробую. Работу Windows XP завершил и теперь пробую сделать быструю миграцию (меню динамической миграции уже неактивно):
На этот раз всё успешно, виртуальная машина переместилась на узел Hyper1. Пробую запустить:
Работает. Пробую теперь погасить сервер Hyper2. Виртуальная машина с Windows XP осталась работать при этом:
На этом можно и заканчивать статью. Конечно, для продакшена такая настройка кластера не подойдёт. Но для ознакомления — вполне себе вариант. Так что, может кому и пригодится.
Донаты принимаются на кошельки:
Yoomoney:
4100118091867315
BTC:
bc1qzw9vam8mv6derwscxl0vrnd6m9t2rpjg273mna
ETH / BNB BSC / Polygon MATIC:
0x5cc07FF76490350ac6112fbFdA1B545Bc794602F
Tron:
TJUz8sJr9XYMjVqzmFNnCzzRWfPa57X2RV
USDT/USDC в сетях ETH/BSC/Polygon:
0x5cc07FF76490350ac6112fbFdA1B545Bc794602F
USDT в сети TRX (Tron):
TJUz8sJr9XYMjVqzmFNnCzzRWfPa57X2RV
LTC:
LRMZaFCSyCT6FUF62WEX1BokWV7v2dh2zo
Doge:
DTEnGLZRps9XaWNtAhchJWSeD4uTNDRxg7
XMR:
4A6uP1WxEc7HktToZFyiJuK6YmjdL8bSn2aY653qPwABhT4Y56iFuedgHcmpvLwWE55u8qkjGc715ZJs761FqedA8gkgznr
TON:
UQAdSPiWIDx2Q1VIeezkUV3s4sNlZM90w2ohSO6bD2-okwgY
Failover clustering will enable you to make you Windows Server services highly available. In this guide we will go just through simple setup of failover clustering on Windows Server 2019 without setting up any services.
Before we begin
These are the resources you will need if you are completely new to Failover Clustering – https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster
Prerequisites
I assume you know basic things about Windows Server before you attempt to do this.
DC
LAB for this guide consists of following:
Domain: informatiker.local
Domain Controller named DC1 – 10.0.0.31
ISCSI
One Windows Server ISCSI Target server named ISCSI1 (if you don’t know how to make ISCSI target server, here is the guide)
ISCSI1 – 10.0.0.50
That machine has one additional disk of 40GBs that will be assigned to ISCSI Target.
Optionally, you don’t have to bring up iscsi target server and configure iscsi for failover cluster – you can also bring up failover cluster without storage.
Failover cluster
We will have two nodes that will have failover clustering installed. These machines will have two network cards – one for communication with network, and another one for clustering communication.
Failover1 – NIC1 10.0.0.52 NIC2 192.168.4.2
Failover2 – NIC1 10.0.0.53 NIC2 192.168.4.3
192.168.4.xx network is only for internal cluster configuration (heartbeat). On netowrk cards that will serve you as heartbeat and internal cluster communication – Control Panel | Network and Sharing Center | Change Adapter Settings | right click on network adapter that will serve for cluster communication – Properties | under Networking tab select IPv4 – Properties | click on Advanced button | under DNS tab deselect Register this connection’s addresses in DNS | WINS tab – select Disable NetBIOS over TCP/IP. Do this ONLY ON network adapters that will server for internal cluster communication!
All of these machines should be part of domain.
Be sure to enable MPIO Feature and iSCSI Initiator on both Failover1 and Failover2 machines. Be sure to follow my guide I posted above for creating ISCSI target, it has all the details in it.
MPIO is very important when you use shared storage.
Connect one 40GB disk you defined as ISCSI target to both Failover1 and Failover2, leave it offline at failover2 node.
Cluster is going to be named Cluster1
Cluster1 – 10.0.0.54
Cluster Witness. We need additional VM that will hold file share that ill be available to our cluster – Witness1
Witness1 – 10.0.0.55
Install Failover Clustering
We will go through the process on Failover1 node, you will repeat the process on Failover2 node. I will show you only important parts, I assume you know how to use Server Manager.
Open Server Manager | click on Manage | Add Roles And Features | on Features screen select Failover Clustering
Additional pop-up will appear, click on Add Features
Next
Install
Close wizard and reboot server.
Repeat this process on Failover2 node.
Validate Cluster Configuration
After you installed Failover Clustering on both nodes, login to Failover1 node, click on Start | Windows Administrative Tools | select Failover Cluster Manager
Click on Failover Cluster Manager, and from the middle screen select Validate Configuration…
Next
Select both servers (in my case Failover1 and Failover2) and select Next
Run all tests | Next
Next
…
All test were success | Finish
We can proceed to creating cluster
Failover Cluster Manager | from Action screen, select Create Cluster
Next
Again select both servers that will be part of the cluster | Next
I will name cluster – Cluster1 and give it IP 10.0.54 | Next
Next
…
Success! Finish
We can now see created cluster1 and two nodes as part of it.
Add Cluster Quorum Witness
Cluster Quorum Witness will enhance your Failover Cluster Availability. I will not go into detail about witness role, you can find many more details here – https://docs.microsoft.com/en-us/windows-server/failover-clustering/manage-cluster-quorum
In our scenario, we will add File Share as Witness. since we have only two nodes, witness and one node will always have to be up, for cluster to be valid. So, make sure you plan you outages and patching so that you always have two nodes up.
On Witness1 machine, I added folder named ClusterWitness and shared it. In the screenshot below – three things are MISSING – you should also add Failover1, Failover2 and Cluster1 computers to this fileshare with full rights. Also, visit security tab of the shared folder and repeat procedure there!!
Back to Failover1 node – Open Failover Cluster Manager | select Actions | More Actions | Configure Cluster Quorum Settings
Next
Select the quorum witness | Next
You have many options, today we will select “Configure a file share witness” Next
Enter FQDN to your file share on witness1. In my case it is \witness1\ClusterWitness | Next
Review and click Next
Success! Finish
Now, we can see in Failover Cluster Manager that Witness is available.
That is it, we covered the basics and we can now start deploying various services in our clustered scenario.
Disclaimer
In this tutorial, we would learn how to install and setup Failover cluster in Windows Server 2019 step by step. In the previous tutorial, we configures an iSCSI storage server and created three virtual disk.
To install and configure a failover cluster, let’s look at our network setup, then we follow some steps
- Our Network Environment
- Determine the Cluster Disks
- Add Failover Clustering Role
- Create the Failover Cluster
- Add Disks to the Cluster
1. Our Network Environment
Our lab network is set up using VirtualBox and consists of 4 computers:.
How to set up a domain network is explained here.
DC (192.168.1.90) – This is our domain controller.
Node1 (192.168.1.91) – This is one of the failover cluster nodes and a iSCSI initiator.
Node2 (192.168.1.92) – This is the second failover cluster nodes and an iSCSI initiator.
Node3 (192.168.1.93) – This is out iSCSI target server. It hosts the virtual disks
2. Determine the Cluster Disks
Before you start creating the failover cluster, you need to determine the disk that hold the cluster data. This is so that if a member of the cluster fails, then the data would still be available. In our setup, we have decided to host the disks in another computer (Node3). This is configured as iSCSI target server and contain 3 virtual disk.
The figure below shows Node3 with the 3 iSCSI disks configured.
How to configure iSCSI target server and disks
Note: Ensure that the disks are iSCSI virtual disks are initialized on one of the failover nodes
3. Add the Failover Clustering Role
Now we have to install the Failover cluster role in Node1 and Node2. Follow the steps below to do that.
Step 1 – In Node1, click on Add Roles and Feature. This will launch the Add Roles and Features wizard. Follow the steps and select Failover Clustering as shown below. Then complete the installation.
Step 2 – Repeat the process for Node2
4. Create the Failover Cluster
We would now use the Failover cluster manager to create a cluster. Follow the steps below:
Step 1 – In Node1, click on Manager and select Failover Cluster Manager. The window is shown below
Step 2 – Click on Validate Configuration and follow the wizard steps to do the validation (this is done only in Node1). The wizard will ask you to specify the Servers you want to participate in the clustering. You will use AD to find Node1 and Node2 and select them.
At the end of the validation, you may have warning relating to unsigned drivers. Ignore these warnings because they come from VirtualBox Guest Additions.
Step 3 – Click on Create Cluster. You will have to select the Node1 and Node1. Then you need to specify the cluster name. The complete the cluster creation. The figure below shows the final screen indicating the cluster creation was successful.
5. Add Disks to the Cluster
Failover clusters require disks and in this case we would used virtual disks from the iSCSI target server.
Step 1– Add storage to the cluster. To do that open the Failover Cluster manager as shown below.
Step 2 – Click on Add Disk. The three iSCSI disks would be listed. Ensure that they are selected.
Click on OK.
At this point, the disks are added to the cluster and they are online as well. See the figure below
In subsequent tutorials, I discuss the concept of Witness in failover cluster and how to configure Quorum witness and Disk witness.
I also recommend you watch the video in my Youtube Channel.
В статье приводится краткий обзор
создания отказоустойчивого кластера 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
Данная статья подойдёт для новичков, которые хотят потренироваться в настройке кластера Hyper-V 2019. Итак, имеется:
— Тестовый комп1 «железный»
— Тестовый комп2 «железный»
— Тестовый комп3 «виртуальный» с Windows srv 2019 и настроенной ролью контроллера домена.
— Тестовый комп4 «железный» с расшаренным диском по протоколу iSCSI.
— Всё это соединено через обычный пассивный коммутатор.
На тестовый комп1 установлена Windows Srv 2019 Standard Evaluation с графической оболочкой. На тестовый комп2 установлена Microsoft Hyper-V Server 2019 — данная ОС бесплатна и устанавливается как обычная Windows 10/2019. Скачать эту ОС можно с оф.сайта Microsoft:
https://www.microsoft.com/ru-ru/evalcenter/evaluate-hyper-v-server-2019
Собственно, на этой же странице можно скачать и Windows Srv 2019 Standard Evaluation. И если, после установки Windows Srv 2019 с графической оболочкой, вопросов о том, как ей пользоваться дальше, нету, то после установки Hyper-V Server 2019 могут возникнуть вопросы, что с этой ОС делать дальше. Ведь у Hyper-V Server 2019 графической оболочки нет. После установки есть лишь вот такое окно:
Здесь можно сделать самые основные настройки: задать имя компьютера, прописать статический IP, включить доступ по RDP.
Для дальнейшего удобства администрирования данной ОС, я установлю пару инструментов. Первый из них — это банальный Total Commander portable, который я просто скопирую на диск C: с флэшки. Сделать это можно командой:
xcopy f:totalcmd c:totalcmd /y /e
Где f:totalcmd — это каталог с total командером на флэшке, а c:totalcmd — каталог, в который копирую.
Потом перехожу в этот каталог и запускаю тотал командер:
c:
cd c:totalcmd
totalcmd.exe
Дальше уже будет проще. Пользуясь тотал командером, нахожу каталог с драйверами и устанавливаю их.
Следующий инструмент, который облегчит администрирование Hyper-V Server 2019 — это WINDOWS ADMIN CENTER. Это вэб-админка от Microsoft, с помощью которой можно администрировать сервер через вэб-интерфейс. Некий аналог Webmin, но для Windows-систем. Скачать его можно на той же странице, где скачивались установочные образы операционных систем:
https://www.microsoft.com/ru-ru/evalcenter/evaluate-windows-admin-center
Дистрибутив Windows админ центра можно тоже перенести через флэшку на сервер.
Установка данного программного обеспечения самая обычная, где все параметры можно оставить по умолчанию.
После установки Windows админ центра нужно зайти на сервер через обычный браузер по https протоколу:
https://192.168.0.206/
Сообщение безопасности нужно игнорировать, т.к. используется самоподписанный сертификат. Логин и пароль при подключении — это виндовый «администратор» с его паролем в самой ОС. Вот так выглядит Windows Admin Центр:
В списке серверов выбираю свой, который также стал шлюзом Windows AdminЦентра. Ну и подробно на всех возможностях останавливаться не буду, т.к. их много. Вэб-интерфейс хоть и тормозной, но довольно функциональный — через него можно будет управлять и виртуальными машинами в том числе. Или, например, если какие-то драйвера не установлены, то их можно доустановить уже через Windows AdminЦентр:
Я же пробую ввести данный сервер в домен. Жму на меню «Обзор» и затем на «Изменить идентификатор компьютера».
Ну а дальше, всё как обычно:
Сервер перезагрузится. После чего, в Windows Admin Центр рекомендуется войти уже под доменным администратором! Имя пользователя надо вводить в таком формате:
Ну и кстати, желательно бы установить обновления для Windows Admin Центра, если они есть. Для этого надо нажать на шестерёнку и выбрать пункт «расширения». Ну и там дальше всё понятно будет:
Разобравшись с сервером на ОС Hyper-V Server 2019, сделаю всё то же самое и на сервере под управлением Windows Srv 2019 Standard Evaluation. Там уже всё делается в привычном виде — через графическую оболочку Windows. Установил драйверы, ввел сервер в домен AD — подробности этого всего описывать не буду.
Следующим шагом будет подключение сетевого диска iSCSI. Захожу в «Средства администрирования»:
И там выбираю Инициатор iSCSI:
При первом запуске выйдет сообщение о том, что служба iSCSI не запущена, и будет предложено запустить эту службу и включить её автозапуск при старте сервера. Ну а потом появится окно, в котором надо будет перейти на вкладку «Обнаружение» и нажать на кнопку «Обнаружить портал»:
Затем надо ввести IP-адрес сервера iSCSI:
В моём случае, этого будет достаточно. Но если iSCSI сервер требует пароль для подключения к себе, то надо нажать кнопку «Дополнительно» и там ввести этот пароль.
Далее, надо перейти на вкладку «Конечные объекты» и нажать кнопку «Подключить»:
В появившемся окне надо нажать на «ОК», после чего диск перейдёт в состояние «Подключено»:
Всё, это окно можно закрывать. Дальше надо зайти в диспетчер управления дисками, в котором отобразится подключенный iSCSI диск. Его надо проинициализировать и отформатировать в NTFS:
Сильно подробно это не буду расписывать. Уверен, что форматировать диск под NTFS умеют все ИТ-специалисты. После форматирования можно попробовать что-нибудь записать на него, чтобы убедиться в работоспособности диска.
Далее, этот же диск надо подключить на втором сервере под управлением Hyper-V Server 2019. На самом деле, там это всё делается точно также. Надо лишь в командной строке ввести:
iscsicpl
Появится точно такое же окно, как и на сервере с графической оболочкой:
Нужно проделать те же действия, что и на первом сервере. Но в диспетчер дисков заходить уже не нужно. Достаточно просто подключить диск по iSCSI.
Теперь снова перехожу к серверу под управлением Windows Srv 2019 Standard Evaluation, на котором нужно установить роль Hyper-V, а также роль Кластера. В диспетчере сервером жму «Добавить роли и компоненты»:
В первом шаге жму «далее», потом снова «далее», оставив на месте крыжик «Установка ролей или компонентов». Выбираю в списке свой сервер, который там пока один, жму «далее»:
Ставлю галку на Hyper-V и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму «далее». На следующем шаге, где уже предлагается выбрать компоненты, ставлю галку на «Отказоустойчивой кластеризации» и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму кнопку «Далее». На следующем шаге предлагается сразу создать виртуальный коммутатор, но я пока не буду. Создам его потом вручную. Просто жму «Далее».
На следующем шаге предлагается включить и выбрать протокол для динамической миграции. Однако внизу есть предупреждение, что если данный сервер будет членом кластера, то этого делать на надо. Поэтому ничего не трогаю и жму «далее».
Расположение по умолчанию дисков и конфигурации виртуальных машин тоже пока не трогаю. Эти значения надо менять уже после настройки кластера. Жму «далее», а затем «установить». Дожидаюсь окончания установки.
Теперь кое-какие компоненты надо установить на машине с Hyper-V Server 2019. Для этого открываю диспетчер серверов на машине с Windows Srv 2019 Standard Evaluation и жму «Добавить другие серверы для управления»:
В поле «Имя» ввожу имя компьютера машины Hyper-V Server 2019, жму «найти» и потом добавляю его в правый список. Жму «ОК»:
Потом жму «Добавить роли и компоненты» и на шаге, где предлагается выбрать сервер, выбираю машину с Hyper-V Server 2019:
На шаге с выбором ролей сервера ничего не трогаю и жму «далее». А вот на шаге выбора компонентов добавляю «Отказоустойчивую кластеризацию» и соглашаюсь с добавлением остальных компонентов по зависимостям:
Жму «далее» и «установить», дожидаюсь окончания установки.
Теперь надо создать кластер. На машине Windows Srv 2019 Standard Evaluation захожу в «средства администрирования» и выбираю «Диспетчер отказоустойчивости кластеров»:
В открывшемся окне жму «Создать кластер».
На первом шаге «Перед началом работы» жму «далее». А на следующем шаге выбираю, какие серверы будут членами кластера:
На следующем шаге предлагается выполнить проверочные тесты для выбранных серверов. Пусть выполнит. Оставляю «да» и жму «далее».
Откроется дополнительный мастер с вопросом, какие тесты выполнить. Оставляю «Выполнить все тесты» и жму «далее».
Запускается тестирование, жду его окончания:
У меня тестирование нашло ошибки, которые я и предполагал, что будут:
Да, действительно, у меня тестовые компы на разных процессорах. Один на Intel Xeon 2620 v3, а второй на AMD FX 8350. Но других компов у меня нет, да и это лишь тестовая установка. Сеть у меня тоже одна, хотя рекомендуется иметь выделенную сеть для соединения с дисками iSCSI. Ну и разные версии операционных систем я выбрал нарочно — хочу посмотреть, как оно будет работать именно в таком варианте. Повторюсь, что установка тестовая, в домашних условиях и лишь для ознакомления. Для продакшена надо делать следуя рекомендациям Microsoft.
После тестов появляется следующий шаг, на котором надо задать имя кластера и указать его IP-адрес:
Жму «далее». Здесь тоже жму «далее»:
После создание кластера появится такое окно:
Иии… Сразу обращаю внимание, что есть какие-то ошибки.
Смотрю их подробнее:
Ресурсу сетевого имени «Имя кластера» кластера не удалось зарегистрировать одно или несколько связанных DNS-имен по следующей причине:
Неверный раздел DNS.
Убедитесь, что сетевые адаптеры, связанные с зависимыми ресурсами IP-адресов, настроены для доступа хотя бы к одному DNS-серверу.
И действительно на DNS-сервере запись о кластере не добавилась. Причину тому не знаю:
Но не страшно, добавляю эту запись вручную.
После создания кластера надо настроить для него параметры кворума. Что это за кворум, почитать можно тут:
https://docs.microsoft.com/ru-ru/windows-server/storage/storage-spaces/understand-quorum
Вообще, мастер установки сделал правильно. Он под кворум забрал диск iSCSI. Но дело в том, что это мой единственный диск iSCSI, который я хочу использовать под виртуальные машины, а не под кворум. Кворум можно разместить в обычной сетевой папке. Поэтому захожу вот сюда:
Там выбираю «Выбрать свидетель кворума»:
И дальше выбираю «Настроить файловый ресурс-свидетель»:
И указываю сетевую папку:
Потом жму везде «далее».
Важно! В правах доступа к этому каталогу должны быть указаны не только администраторы, но и сам кластер:
Добавить его можно, включив галку «Компьютеры» вот тут:
После того, как диск высвободился из-под кворума, добавляю его в общие тома кластера:
Теперь надо добавить виртуальный коммутатор на обе машины. Важно, чтобы виртуальные коммутаторы имели одинаковое название. Создать их можно как через оснастку на Windows Srv 2019 Standard Evaluation, так и через Windows Admin Center. Я, ради интереса, создам виртуальный коммутатор на машине с Windows Srv 2019 Standard Evaluation через Windows Admin Center. А виртуальный коммутатор на машине с Hyper-V Server 2019 создам через оснастку на Windows Srv 2019 Standard Evaluation.
Итак, захожу в Windows Admin Center и выбираю «Диспетчер кластеров»:
Потом жму «Добавить»:
И справа будет предложено ввести имя кластера, а также учётные данные для подключения к нему. Заполняю и жму «Подключитесь с помощью учётной записи»:
Потом жму «Добавить»:
Теперь вижу кластер в списке хостов для управления через Windows Admin Center. Выбираю его:
Ну а там перехожу в меню «Виртуальные коммутаторы» и жму «Создать».
Ну а там дальше выбираю узел, задаю название коммутатора и тип выбираю ему внешний. Жму создать.
Во время создания виртуального коммутатора отвалится ненадолго связь с машиной, на которой он создаётся. Потом он отобразится в списке виртуальных коммутаторов:
Теперь создам виртуальный коммутатор для машины с Hyper-V Server 2019, но через оснастку на машине Windows Srv 2019 Standard Evaluation. Открываю «Средства администрирования» и выбираю оснастку «Диспетчер Hyper-V»:
Там выбираю «Подключиться к серверу», пишу его имя и жму «ОК»:
Дальше захожу в «Диспетчер виртуальных коммутаторов»:
Выбираю внешний и жму «Создать виртуальный коммутатор»:
Задаю такое же имя, как и на первой машине, жму «ОК»:
Выйдет предупреждение, что связь с машиной потеряется на некоторое время. Соглашаюсь и жду завершения. После чего снова захожу в «Диспетчер виртуальных коммутаторов» и вижу, что коммутатор там появился:
Также его можно видеть и через Windows Admin Center:
Что ж, пришло время создать виртуальную машину. Я попробую что-нибудь лёгкое, например, виртуальную машину с Windows XP. Создаю:
Выбираю хост:
Задаю название машины и расположение её конфигурации. Каталог C:ClusterStoragevolume1 — это и есть тот самый iSCSI диск.
Далее предлагается выбрать поколение виртуальной машины. Для Windows XP надо выбирать первое поколение.
Оперативной памяти выделяю 1Гб, хватит сполна.
Далее настройка сети. Там выбираю виртуальный коммутатор komm1.
Дальше мастер предлагает сразу создать виртуальный диск для этой виртуальной машины. Для XP большой диск не нужен. Также указываю месторасположение диска — тоже на ресурсе iSCSI:
Жму «Далее». На следующем шаге предлагается выбрать установочный носитель с операционной системой. В моём случае, он лежит на флэшке, подключенной к серверу. Выбираю его:
Жму «далее», жму «готово» и получаю вот такую непонятную ошибку:
Не удалось создать виртуальную машину. Проблема оказалась в правах доступа файловой системы. Мастер не мог создать виртуальную машину, т.к. у него просто не было доступа в указанный каталог. Дал вот такие права, и виртуальная машина создалась:
Пробую запустить и установить Windows XP. Жму сначала «Запустить», а потом «Подключить»:
Началась установка Windows XP. Кстати, эту виртуальную машину видно и в Windows Админ Центре:
И от туда к ней тоже можно подключиться:
После установки в Windows XP даже мышь работать не будет. Чтобы всё заработало, надо установить службы интеграции. Установочный образ можно взять тут:
https://disk.yandex.ru/d/b8dcTwIQerC-EQ/vmguest.iso
А затем подставить его в свойствах виртуальной машины вместо установочного образа Windows XP:
Это можно сделать даже при включённой виртуальной машине. Сработает автозапуск с виртуального CD, и интеграционные службы начнут сразу устанавливаться:
Потом установщик попросит перезагрузку. После перезагрузки Windows XP будет работать абсолютно нормально.
Теперь хочется проверить, как виртуальная машина будет переходить с одного узла на другой в кластере. Пробую запустить динамическую миграцию на узел Hyper1:
И получаю ошибку. В подробных сведениях написано вот что:
Собственно, это то, о чём и предупреждал мастер создания кластера на этапе тестирования. Невозможно произвести динамическую миграцию от узла с процессором Intel на узел с процессором AMD. И наоборот — тоже нельзя. Но зато можно это сделать, завершив работу виртуальной машины. Пробую. Работу Windows XP завершил и теперь пробую сделать быструю миграцию (меню динамической миграции уже неактивно):
На этот раз всё успешно, виртуальная машина переместилась на узел Hyper1. Пробую запустить:
Работает. Пробую теперь погасить сервер Hyper2. Виртуальная машина с Windows XP осталась работать при этом:
На этом можно и заканчивать статью. Конечно, для продакшена такая настройка кластера не подойдёт. Но для ознакомления — вполне себе вариант. Так что, может кому и пригодится.
Донаты принимаются на кошельки:
Yoomoney:
4100118091867315
BTC:
bc1qzw9vam8mv6derwscxl0vrnd6m9t2rpjg273mna
ETH / BNB BSC / Polygon MATIC:
0x5cc07FF76490350ac6112fbFdA1B545Bc794602F
Tron:
TJUz8sJr9XYMjVqzmFNnCzzRWfPa57X2RV
USDT/USDC в сетях ETH/BSC/Polygon:
0x5cc07FF76490350ac6112fbFdA1B545Bc794602F
USDT в сети TRX (Tron):
TJUz8sJr9XYMjVqzmFNnCzzRWfPa57X2RV
LTC:
LRMZaFCSyCT6FUF62WEX1BokWV7v2dh2zo
Doge:
DTEnGLZRps9XaWNtAhchJWSeD4uTNDRxg7
XMR:
4A6uP1WxEc7HktToZFyiJuK6YmjdL8bSn2aY653qPwABhT4Y56iFuedgHcmpvLwWE55u8qkjGc715ZJs761FqedA8gkgznr
TON:
UQAdSPiWIDx2Q1VIeezkUV3s4sNlZM90w2ohSO6bD2-okwgY
Failover clustering will enable you to make you Windows Server services highly available. In this guide we will go just through simple setup of failover clustering on Windows Server 2019 without setting up any services.
Before we begin
These are the resources you will need if you are completely new to Failover Clustering – https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster
Prerequisites
I assume you know basic things about Windows Server before you attempt to do this.
DC
LAB for this guide consists of following:
Domain: informatiker.local
Domain Controller named DC1 – 10.0.0.31
ISCSI
One Windows Server ISCSI Target server named ISCSI1 (if you don’t know how to make ISCSI target server, here is the guide)
ISCSI1 – 10.0.0.50
That machine has one additional disk of 40GBs that will be assigned to ISCSI Target.
Optionally, you don’t have to bring up iscsi target server and configure iscsi for failover cluster – you can also bring up failover cluster without storage.
Failover cluster
We will have two nodes that will have failover clustering installed. These machines will have two network cards – one for communication with network, and another one for clustering communication.
Failover1 – NIC1 10.0.0.52 NIC2 192.168.4.2
Failover2 – NIC1 10.0.0.53 NIC2 192.168.4.3
192.168.4.xx network is only for internal cluster configuration (heartbeat). On netowrk cards that will serve you as heartbeat and internal cluster communication – Control Panel | Network and Sharing Center | Change Adapter Settings | right click on network adapter that will serve for cluster communication – Properties | under Networking tab select IPv4 – Properties | click on Advanced button | under DNS tab deselect Register this connection’s addresses in DNS | WINS tab – select Disable NetBIOS over TCP/IP. Do this ONLY ON network adapters that will server for internal cluster communication!
All of these machines should be part of domain.
Be sure to enable MPIO Feature and iSCSI Initiator on both Failover1 and Failover2 machines. Be sure to follow my guide I posted above for creating ISCSI target, it has all the details in it.
MPIO is very important when you use shared storage.
Connect one 40GB disk you defined as ISCSI target to both Failover1 and Failover2, leave it offline at failover2 node.
Cluster is going to be named Cluster1
Cluster1 – 10.0.0.54
Cluster Witness. We need additional VM that will hold file share that ill be available to our cluster – Witness1
Witness1 – 10.0.0.55
Install Failover Clustering
We will go through the process on Failover1 node, you will repeat the process on Failover2 node. I will show you only important parts, I assume you know how to use Server Manager.
Open Server Manager | click on Manage | Add Roles And Features | on Features screen select Failover Clustering
Additional pop-up will appear, click on Add Features
Next
Install
Close wizard and reboot server.
Repeat this process on Failover2 node.
Validate Cluster Configuration
After you installed Failover Clustering on both nodes, login to Failover1 node, click on Start | Windows Administrative Tools | select Failover Cluster Manager
Click on Failover Cluster Manager, and from the middle screen select Validate Configuration…
Next
Select both servers (in my case Failover1 and Failover2) and select Next
Run all tests | Next
Next
…
All test were success | Finish
We can proceed to creating cluster
Failover Cluster Manager | from Action screen, select Create Cluster
Next
Again select both servers that will be part of the cluster | Next
I will name cluster – Cluster1 and give it IP 10.0.54 | Next
Next
…
Success! Finish
We can now see created cluster1 and two nodes as part of it.
Add Cluster Quorum Witness
Cluster Quorum Witness will enhance your Failover Cluster Availability. I will not go into detail about witness role, you can find many more details here – https://docs.microsoft.com/en-us/windows-server/failover-clustering/manage-cluster-quorum
In our scenario, we will add File Share as Witness. since we have only two nodes, witness and one node will always have to be up, for cluster to be valid. So, make sure you plan you outages and patching so that you always have two nodes up.
On Witness1 machine, I added folder named ClusterWitness and shared it. In the screenshot below – three things are MISSING – you should also add Failover1, Failover2 and Cluster1 computers to this fileshare with full rights. Also, visit security tab of the shared folder and repeat procedure there!!
Back to Failover1 node – Open Failover Cluster Manager | select Actions | More Actions | Configure Cluster Quorum Settings
Next
Select the quorum witness | Next
You have many options, today we will select “Configure a file share witness” Next
Enter FQDN to your file share on witness1. In my case it is witness1ClusterWitness | Next
Review and click Next
Success! Finish
Now, we can see in Failover Cluster Manager that Witness is available.
That is it, we covered the basics and we can now start deploying various services in our clustered scenario.
Disclaimer