Данная статья подойдёт для новичков, которые хотят потренироваться в настройке кластера 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
Карта Т-Банк (бывший Тиньков):
2200 7017 2612 2077
Карта Альфа-Банк:
2200 1539 1357 2013
We were testing many backup tool compatibility with Hyper-V Cluster 2019, we configured 2016 earlier but the latest version not tried. In this article will take you through installing and Configuring Hyper-V Cluster in Windows 2019 Server.
Prerequisites
- Windows 2019 Servers, You can Download from the evaluation center
- Enable hardware-based virtualization
- Disable C States (power management)
- Consider disabling all power management
- Enable the Trusted Platform Module (TPM) if your system has one.
Pre-Installation Checklist
Perform below steps on the Windows Server 2019 Servers prior to installing Hyper-V
- Perform Windows Full Update
- Update Device drivers
- Computer Name is Correct
- Join to the domain For more security
- Configure Basic networking
Installing Hyper-V
Hyper-V role can be installed in three ways powerShell, dism.exe, and Server Manager, here we will share the steps for power shell and a dism . We have already shared the step on the previous BlogPost – Installing Hyper-V On Windows Server 2019, you can refer this, once complete the installation of HYpe-V on Windows 2019 Servers follow below procedure to Configuring the Cluster.
Руководство по подключению ноды к кластеру Hyper-V с центразизованым хранением VM на СХД lenovo DE2000
В общем случае, получается отказоустойчивое соединение iscsi через два коммутатора к двух контроллерам СХД.
Только по факту используется не 2, как на изображении, а 8 путей подключения
Данная инструкция предусмотрена для подключения к Lenovo DE2000. Для других СХД возможны изменения, но общий принцип остается тем же.
-Hyper-V хост
— установка сервера и драйверов
— включение необходимых ролей и опций (Roles and Features). Установка роли Hyper-V, а также опций Failover Clustering и Multipath IO.
— В свойствах сетевых адаптеров, выделенных для сети СХД должны быть включены Jumbo фреймы:
— найстройка LACP если нужно (через Server manager -> Local Server -> NIC Teaming). IP адреса не присваивать, потом VirtualSwitch не соберется
— Создать VirtualSwitch в Hyper-V manager. Если настроен LACP, выбрать Microsoft Network Adapter Multiplexor driver. Надо обратить внимание на то, чтобы имя виртуального коммутатора было на всех хостах одинаково, например vSwitch0.
- Далее настраивается подключение к СХД. В оснастке iSCSI Initiator на вкладке Discovery необходимо прописать адрес цели и доступные пути до неё.(Discover portal -> ip_shd_1->OK,DicoverPortal -> ip_shd_2->OK и тд)
- На вкладке Targets необходимо выделить цель и перейти в настройку, нажав Connect. Аналогичным образом прописываются все доступные пути к СХД. Список добавленных путей можно посмотреть на вкладке Favorite Targets.(Connect->отметить всё, advanced-> Microsoft_iscsi+HostIp1+ShdIp1, Connect->отметить всё, advanced-> Microsoft_iscsi+HostIp1+ShdIp2 …… Connect->отметить всё, advanced-> Microsoft_iscsi+HostIp2+ShdIp4)
- Установить ПО СХД (storagemanager) в режиме host.
— Запустить failoverCluster Manager и создать кластер. Потребуется указать IP адрес кластера.
— Создать VM для SQL кластера. Есть используется LACP virtual switch, нужно поставить галку в nic teaming в advanced features сетевого адаптера.
-SQL cluster-
— установить WIN сервер
— установка SQL сервера 2017 standart.
Компоненты:
— Службы ядра СУБД
Идентификатор экземпляра
— MSSQLSERVER
Учетные записи служб
— Агент SQL сервер — авто
— ядро СУБД SQL сервер — авто
— обохреватель SQL сервер — Отключено
Конфигурация сервера
— смешанный режим.
— указать sa пароль
— добавить администраторов сервера
Каталоги данных
— указать пути баз на SSD диск
— указать пути для бэкапов
TempDB
— на SSD
— Установить роль FailoverCluaster
— Включение режима поддержки AlwaysOn SQL servera
(рекомендуется запускать от доменной учетки)
— Запустить диспетчер конфигурации SQL Server 2017
— Выбрать свойства службы SQL Server
— На вкладке «Высокий уровень доступности AlwaysOn» установить флажок
— проверить, что в имени кластера указан тот кластер, который требуется
— Перезапустить службу SQL Server (действия по правой кнопке мыши на записи службы)
— Убедиться, что на сервере БД доступен режим Высокий уровень доступностиˆ
— настройки работы с памятью и тд
— в SSMS выбрать свойства сервера
— память: нижний — 2048, верхний — (полный объем на сервере минус 4-8Гб)
— процессоры: максимальное число раб. потоков 2048, галка «поддерживать приоритет…»
— дополнительно:
максимальная степень параллелизма — 4
стоимостный порог — 45
— Добавление перекрестно пользователей SQL
Для кластеров добавить перекрестно учетные записи экземпляров SQL Server с правами создания БД (ниже описание для инстансов SQL Server под локальной учетной записью)
Шаблон скрипта добавления
USE [master]
GO
CREATE LOGIN [VZLJOT\otherservername$] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
CREATE LOGIN [VZLJOT\sql-serv] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [dbcreator] ADD MEMBER [DOMAIN\otherservername$]
ALTER SERVER ROLE [dbcreator] ADD MEMBER [DOMAIN\sql-serv]
GO
— Создаем endpoint на каждом сервере и перекрестно предоставляем права
CREATE ENDPOINT Hadr_endpoint
AS TCP
(
LISTENER_PORT = 5022
)
FOR DATA_MIRRORING
(
ROLE = ALL,
ENCRYPTION = REQUIRED ALGORITHM AES
)
GO
GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [DOMAIN\almaaz$]
Проверка наличия:
SELECT * FROM sys.endpoints WHERE type = 4
— Создать группы доступности для каждой базы
— открыть SMSS
— Высокий уровень доступности — мастер:
— автоматический переход на другой ресурс (галка)
— синхронная фиксация
— посмотреть результат «показать панель мониторинга»
Полезные команды:
Включение роли Hyper-V
Install-WindowsFeature hyper-v
Список машин на хосте
Get-VM
Получение ID машины
get-vm -Name «Test Win10» | Select-Object id
Старт машины
Start-VM -Name
Создание снэпшота
Get-VM -Name | Checkpoint-VM -SnapshotName for snapshot>
Создание машины
$VMName = «VMNAME»
$VM = @{
Name = $VMName
MemoryStartupBytes = 2147483648
Generation = 2
NewVHDPath = «C:\Virtual Machines\$VMName\$VMName.vhdx»
NewVHDSizeBytes = 53687091200
BootDevice = «VHD»
Path = «C:\Virtual Machines\$VMName»
SwitchName = (Get-VMSwitch).Name
}
New-VM @VM
Скрипт для вложенном виртуализации, докера и тд
#replace with the virtual machine name
$vm = «»
#configure virtual processor
Set-VMProcessor -VMName $vm -ExposeVirtualizationExtensions $true -Count 2
#disable dynamic memory
Set-VMMemory -VMName $vm -DynamicMemoryEnabled $false
#enable mac spoofing
Get-VMNetworkAdapter -VMName $vm | Set-VMNetworkAdapter -MacAddressSpoofing On
Veeam Backup and replication
Решение проблемы фэйла бэкапа VM:
Processing VM Error: Incorrect function.
Agent failed to process method {ReFs.SetFileIntegrity}.
Сjздать в реестре сервера veeam ключ:
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
REG_DWORD (32-bit)
Name UseCifsVirtualSynthetic
Value 0
Перенос в Hyper-V. Гостевая система bsod.
Загрузиться в виртуалке с какого-нибудь liveCD.
Regedit’ом встать на HKEY_LOCAL_MACHINE
Подгрузить куст \Windows\System32\config\SYSTEM из склонированной системы под имененм 123.
Найти в нем ключи
- Atapi
- Intelide
- LSI_SAS
Исправить параметры Start и изменить на 0.
Выгрузить куст.
Возникновение в linux системах спама вида:
systemd[1]: Time has been changed
— отключить службу синхронизации времени в параметрах VM
Сервера программных лицензий
Если на виртуалке имеется сервер лицензий, привязанный к MAC адресу, надо сделать MAC адрес в параметрах статическим.
Машина в статусе «Сохранена» (Saved)
Get-VMSnapshot «Porrima win19» | Remove-VMSavedState
Remove-VMSavedState «Porrima win19»
Машина зависла. Нужно принудительно ее выключить.
Найти ID машины:
get-vm -Name «Test Win10» | Select-Object id
Запустить Диспетчер задач (Task Manager).
Найти процесс vmwp с ID машины и убить его
Skip to content
Windows Server 2019 Failover Clustering Types and Uses
One of the powerful features of Windows Server is the ability to create Windows Failover Clusters. With Windows Failover clustering, pools of hardware resources can be bound together in a virtual entity that allows seamlessly hosting resources in a way that is highly available and resilient to failure. Windows Server has certainly evolved over the past several iterations and releases. Now, with Windows Server 2019, Windows Failover Clustering is more powerful than ever and can host many highly available resources for business-critical workloads.
Table of Contents
- Windows Server 2019 Failover Clustering Types and Uses
- Hyper-V Clustering
- Clustering for File Services
- Scale-Out File Server
- Application Layer Clustering
- Host Layer Clustering
- Tiered Clustering
- Concluding Thoughts
Let’s take a look at Windows Server Failover Clustering types and uses for hosting resources.
Windows Server 2019 Failover Clustering Types and Uses
Protect Your Data with BDRSuite
As mentioned earlier, the functionality in the latest version of Windows Server is more capable than ever before with various forms of Windows Failover Clustering functionality able to back multiple types of business-critical services.
Let’s take a look at the following types of Windows Server 2019 Failover Clustering.
- Hyper-V Clustering
- Clustering for File Services
- Scale-Out File Server
- Application Layer Clustering
- Host Layer Clustering
- Tiered Clustering
Each provides tremendous capabilities to ensure production workloads are resilient and highly available.
Hyper-V Clustering
In the realm of virtualization in the enterprise running production workloads, to effectively run Hyper-V in a resilient and highly available fashion, Hyper-V cluster configurations are required. Hyper-V clusters are built on top of Windows Failover Clusters.
How is the Hyper-V cluster architected?
In a traditional Hyper-V cluster, all Hyper-V hosts are connected to shared storage. This allows VMs to reside on storage that all hosts have access to, allowing all hosts to share ownership of the various virtual machines. If a host fails, healthy hosts are able to assume the responsibility of providing compute for the virtual machines assumed from a downed host.
A Hyper-V cluster internally monitors the other Hyper-V hosts so when a host goes down, VMs can be spun up relatively quickly on the healthy hosts. This is done by simply restarting the VMs connected to healthy hosts in the cluster. This highlights the “Failover” in Windows Failover Clustering.
Clustering is not only beneficial when an unforeseen problem arises; it is also beneficial to perform needed maintenance on a Hyper-V host. Using Hyper-V Live Migration, virtual machines can be moved while they are running to different hosts in the Hyper-V cluster to safely evacuate all workloads from a particular host so that maintenance can be performed.
Hyper-V clustering allows for intelligent load balancing for virtual machines running on top of the Hyper-V hosts that make up the Hyper-V Windows Failover Cluster. Much like VMware vSphere’s DRS mechanism, Hyper-V can evaluate Hyper-V hosts and their present load and automatically decide if workloads need to be moved for more efficient placement inside the Hyper-V cluster.
Clustering for File Services
The Clustering for File Services Clustering technology has been around perhaps the longest of any of the other types of clustering use cases. This was one of the original ideas behind clustering technology. This was so that file resources could be made highly available in case a single server failed.
The Clustering for File Services clustering technology works in an active-passive configuration.
Only one file server is active for user connections to files. However, if this active server goes down, the passive server(s) in the cluster will become the active file server that accepts end user connections.
Scale-Out File Server
Traditional Clustering for File Services technology is not robust enough to handle the ever-demanding needs of today’s enterprise, especially considering the storage needs to back virtual machines in a Hyper-V Cluster environment.
As mentioned in the previous section, the Clustering for File Services technology is an active-passive configuration. This is not robust enough for high bandwidth, resiliency, and redundancy requirements of virtual hard disk files. This is where Scale-Out File Server or SOFS comes in.
Scale-Out File Server is designed for hosting high-performance workloads such as Hyper-V storage. SOFS allows supporting the requirements of Hyper-V storage. It does this in an active-active configuration of multiple file servers that have persistent connections between them. If one of the SOFS hosts goes down, another SOFS host picks up the workload without any type of migration or failover process. This allows running Hyper-V virtual machines to stay online even during a failure of an SOFS backing file server host.
Application Layer Clustering
Application Layer Clustering is a feature that can be utilized if a service or application needs to have the most uptime possible, regardless of any hardware failures. As already covered, Hyper-V hosts clustered in a Windows Failover Cluster can restart a VM in the event one of the Hyper-V hosts fails. However, this means any applications the VM is hosting will be unavailable during the time required to restart the VM.
If this time of service interruption, albeit brief, is unacceptable, Application Layer Clustering is certainly an option. Application Layer Clustering can be thought of as “nested” clustering. It involves creating a Windows Failover Cluster using VMs running on top of the physical Windows Failover Cluster hosts. This allows the application to be highly available in addition to the physical Hyper-V hosts backing the Hyper-V Cluster VMs.
Host Layer Clustering
Host Layer Clustering is the general term used to describe the technology we have already referred to when talking about Hyper-V Clustering. This is the clustering of the physical Windows Server Failover hosts. This allows clustering two or more physical servers using the Windows Failover Clustering technology to make various roles highly available. Notable among these in today’s production data centers is the Hyper-V role.
Windows Server 2019 Hyper-V Cluster
Tiered Clustering
When it comes to production workloads, generally the component that matters the most to end users or business stakeholders is the application. However, to ensure that application is resilient and redundant, a tiered clustering approach can be used where both a combination of Host Layer Clustering and Application Layer Clustering are used to ensure both the VM is resilient and redundant (host layer clustering) and the application itself is resilient and redundant (application layer clustering). This allows providing the most resilient configuration possible to ensure the most uptime and high availability for business-critical workloads.
Concluding Thoughts
Clustering technology has certainly evolved from the early days with legacy versions of Windows Server. Windows Server 2019 Failover Clustering types and uses have certainly expanded the various applications of Windows Server Failover Clustering technology and broadened its scope in the enterprise.
Today’s business-critical workloads are required to be more and more resilient and redundant to support “always on” infrastructure driving today’s very web-centric businesses. Windows Server 2019 Failover Clustering supports these new and demanding use cases with a combination of various cluster types and applications of clustering technologies.
BDRSuite offers robust Windows backup solutions to secure your data and ensure data integrity. Explore its features and benefits for Windows backup today.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
Try BDRSuite for Free!
Schedule a live demo with one of our product experts
Start your full-featured 30-day free trial
Explore detailed pricing, editions & features
Содержание
- ITsberg.ru
- Отказоустойчивый кластер Hyper-V Server 2019
- Добавить комментарий Отменить ответ
- Создание группы доступности AlwaysON на основе кластера Failover
- Что это и зачем требуется
- Подготовка инфраструктуры
- Создание свидетеля (Quorum Witness Share)
- Добавление тестовой базы данных в MSSQL
- Настройка Always On в MS SQL Server
- Ключевые параметры
ITsberg.ru
Администрирование, Exchange и остальное.
Отказоустойчивый кластер Hyper-V Server 2019
Сегодня опишу процесс построения отказоустойчивого кластера из двух серверов на основе Microsoft Hyper-V Server 2019 и с общим блочным хранилищем.
Упрощённое описание инфраструктуры кластера:
У каждого сервера по четыре сетевых интерфейса. Два сетевых интерфейса гигабитные — будут объединены в агрегированный канал, на котором будет создан виртуальный коммутатор Hyper-V, и через него же будет осуществляться доступ к кластеру.
Два других сетевых интерфейса (10 GB каждый) так же будут объединены агрегированный канал. Здесь будут построены виртуальные сети для доступа к общим блочным хранилищам, сеть Live Migration и Cluster Shared Volume. Доступ к этим сетям будет только у кластера.
Интерфейсы подключены к разным коммутаторам для обеспечения отказоустойчивости, сети изолированы друг от друга.
Почему именно Microsoft Hyper-V Server 2019? Эта ОС бесплатна, её функционала достаточно для обеспечения отказоустойчивого выполнения виртуальных машин, а что касается вопроса, какой гипервизор лучше — на эту тему в интернете навалом статей и нет однозначного ответа. Мне нравится работать с Hyper-V и его возможностей хватает для задач подавляющего большинство компаний.
После установки ОС на хост-сервер всплывает интересный нюанс: к Hyper-V Server 2019 не удастся подключиться по RDP, т.к. данный функционал Microsoft убрали из этой версии ОС. Для настройки у нас остаются четыре метода:
Прямой доступ к серверу.
Powershell Remoting (WinRM)
Приложение «Диспетчер серверов» от Microsoft
Windows Admin Center, тоже от Microsoft.
Так же есть несколько сторонних утилит, к примеру PsTools от Sysinternals.
Sconfig выглядит так, доступен на локальной консоли:
Конфигурирование серверов буду производить в Windows Admin Center.
Итак, что входит в предварительную настройку хоста при подготовке его к включению в кластер:
Настройка сетевых интерфейсов
Введение сервера в домен
Установка необходимых ролей и компонентов
Подключение сетевого хранилища (в нашем случае — iSCSI-диски)
Установка обновлений ОС
Все операции выполняются от имени учётной записи пользователя домена (Domain User), имеющей права администратора на обоих серверах.
Так же у этой учётной записи должны быть права Create Computer в том OU или контейнере, в котором находятся серверы, из которых будем собирать кластер.
Чаще всего данные операции выполняются пользователем с правами Domain Admin.
С самого начала необходимо настроить доступ к сети чтобы присоединить сервер к домену. Как собрать кластер без доменной инфраструктуры — описано в этой статье.
Т.к. sconfig, предлагаемый нам при логине, не имеет функционала для настройки агрегирования каналов, выходим из него в командную строку и запускаем powershell (последний пункт меню в sconfig — Exit to Command line). Powershell запускается из командной строки командой powershell. Даже скриншоты делать не буду чтобы описать запуск PS подробнее.
Получаем список сетевых адаптеров:
В данный момент поднято три интерфейса. Интерфейсы QLogic (ifIndex 3 и 9) — одногигабитные, их и будем объединять в «сеть доступа». Третий поднятый интерфейс — по нему я в данный момент подключен к серверу. После настройки сети доступа будет необходимо переключиться на управление через неё и тогда можно будет настраивать сеть кластера на интерфейсах Intel, по 10Gb каждый.
Первым делом объединяем интерфейсы QLogic в агрегированный канал, тип объединения будет LACP.
Теперь, если снова написать Get-NetAdapter, увидим новый сетевой интерфейс с именем LACP_LAN
Чтобы два раза не ходить, сразу на этот интерфейс повесим виртуальный коммутатор для клиентского доступа
Созданный VMSwitch появился в списке сетевых адаптеров — значит всё сделано правильно. Если у вас применяется разделение на виртуальные сети — указываем VLAN ID на созданном интерфейсе:
И задаём IP адрес и прочие настройки сети (тут важно не перепутать и указать правильный ifIndex, в нашем случае — 22)
Всё, можно переключаться на сеть доступа и работать уже через неё.
Вводим сервер в домен и переименовываем как нам необходим (если ещё не переименовали). Удобнее всего это делать через sconfig, там всё предельно просто. Из powershell sconfig вызывается командой «sconfig».
sconfig sconfig sconfig
Список сетевых интерфейсов теперь такой:
Интерфейсы 10Gb от Intel подключены в разные коммутаторы, на случай, если один из коммутаторов откажет. На их основе настроим агрегированный канал с несколькими виртуальными сетями для доступа к блочному дисковому хранилищу по протоколу iSCSI и для работы кластера.
В данной ситуации необходимо применить режим объединения SwitchIndependent, т.к. физические интерфейсы подключены к разным коммутаторам и управлять агрегированием будет операционная система, а не коммутатор. Но мы создали один виртуальный интерфейс, а нам необходимо минимум две раздельные сети для стабильного функционирования кластера (всё по заветам MS) и хотя-бы одна сеть для iSCSI. Не рекомендуется смешивать iSCSI и сеть доступа.
Разделять сети будем посредством VLAN. Т.е. нам необходимо взять виртуальный интерфейсLACP_CL, собранный на прошлом шаге, и собрать на нём ещё три виртуальных интерфейса, каждый в своём VLAN’е.
Так же я хочу включить поддержку Jumbo-frame на физических интерфейсах сети кластера — это позволит передавать более крупные пакеты по сети, что немного уменьшит нагрузку на коммутаторы и сетевые интерфейсы.
Создаём виртуальные интерфейсы с VLAN’ами.
Этой командой мы добавили виртуальный сетевой интерфейс с именем «LACP_CL_CSV» с VLAN’ом 11 к интерфейсу «LACP_CL». Делаем то же самое для для остальных VLAN’ов:
В результате получается такой список интерфейсов и остаётся настроить IP-адреса.
Т.к. интерфейсов уже довольно много, удобнее будет отсортировать вывод, к примеру, в алфавитном порядке:
Выполняем командлет присвоения IP-адреса, внимательно подставляя свои адреса и номера интерфейсов:
Если где-то ошиблись, удалить созданные виртуальные адаптеры можно командой, где «VLAN» — номер VLAN.
Ставим роли и службы:
Install-WindowsFeature failover-clustering, rsat-clustering, rsat-role-tools, rsat-hyper-v-tools, hyper-v-powershell
Сначала необходимо перевести сервис iSCSI-инициатора в режим автоматического запуска и запустить его:
Для работы с дисковыми устройствами по протоколу iSCSI необходимо настроить так называемый iSCSI target portal:
Где:
TargetPortalAddress — IP адрес устройства, к которому подключаемся
ItiniatorPortalAddress — IP адрес сетевого интерфейса, которым смотрим в сеть iSCSI, т.е. IP-адрес интерфейса на Hyper-V сервере. В нашем случае это адрес интерфейса с именем LACP_CL_3200.
Посмотреть на доступные iSCSI-таргеты можно комадлетом
Подключаем доступные iSCSI-таргеты:
Либо можно вызвать обычную графическую консоль командой
Всё то же самое необходимо выполнить и на втором сервере.
Можно начинать работать с дисками.
Для того, чтобы диски можно было добавить в кластер как общее дисковое хранилище — диски должны быть отформатированы в NTFS и должны быть доступны на обоих серверах.
Нам понадобится минимум два диска — диск-свидетель кворума и диск для хранения виртуальных машин. Диск-свидетель может быть небольшим, хватит объёма в 1 GB.
Командлет Get-Disk возвращает список доступных дисков на данном сервере:
Начнём работу с диска номер 4, объёмом 1GB:
По необходимости то же самое делаем с остальными дисками. В результате получается такая картина:
Перезагружаем оба сервера.
Всё, основные вещи на серверах сделаны, можно приступать к сборке кластера.
Кластер будем собирать используя Failover Cluster Manager.
Если проводить настройки будем с какого-либо подходящего стороннего сервера — предварительно необходимо установить на него средства удалённого управления отказоустойчивым кластером: Failover Cluster Management Tools и Failover Cluster Module for Windows Powershell
Если будем настраивать с десктопной ОС — все необходимые модули ставятся во время установки средств удалённого администрирования сервера. Взять их можно на сайте Microsoft: https://www.microsoft.com/ru-RU/download/details.aspx?id=45520
Теперь можем запустить Failover Cluster Manager и заняться непосредственно сборкой кластера. Прежде всего необходимо проверить конфигурацию серверов, из которых мы всё это будем собирать. В Failover cluster Manager’е есть подходящий функционал — в разделе Management ссылочный пункт «Validate Cluster»:
Запускаем мастер проверки конфигурации, указываем наши серверы, в следующем пункте оставляем отметку Run all tests, жмём пару раз Next и ждём завершения тестов.
Важный момент: Если запустить проверку кластера на уже действующем кластере — все запущенные роли кластера аварийно остановятся, т.к. общие дисковые пространства будут отключены для проведения проверки.
После проведения проверки можно посмотреть отчёт, понятно — в отчёте не должно быть ошибок.
Отчёт записывается в текущий рабочий каталог, например C:\Users\UserName\AppData\Local\Temp
Когда удостоверились что конфигурация серверов выполнена правильно — можно приступать к непосредственному созданию кластера. Запускаем мастер создания кластера (Create Cluster), добавляем серверы.
На шаге Access Point for Administering the Cluster в поле Cluster Name указываем имя создаваемого кластера и чуть ниже в таблице указываем IP-адрес кластера. При создании кластера это имя будет зарегистрировано в AD как cluster computer object (или cluster name object, CNO).
Нажимаем далее и подтверждаем создание.
Созданный кластер должен появиться в списке слева в Failover Cluster Manager’е. Если этого не произошло — нажимаем Connect to Cluster и подключаемся к нему.
Теперь кластер необходимо настроить: добавить кластерные хранилища, разграничить сети и, собственно, добавить роли,которые будут исполняться на нашем кластере.
Начинаем с сетей кластера. Раскрываем древовидное представление в менеджере и выбираем Networks:
Такое представление не очень информативно, я предпочитаю переименовать все Cluster Network # в соответствии с их назначением.
Что означает столбец Cluster Use:
Cluster Only — эта сеть будет использоваться только для рабочих нагрузок кластера (CSV или Live Migration)
None — кластер не будет использовать эту сеть. Через эти сетевые адаптеры у нас подключены iSCSI диски с общих блочных хранилищ и за работу с ними отвечает операционная система.
Cluster and Clients — Эту сеть могут использовать как кластер, так и клиенты. Кластер данную сеть будет использовать для отслеживания доступности и работы нод кластера (т.н. HeartBeat-пакеты, ранее для этих целей было необходимо создавать отдельную сеть). Ну через эту же сеть будет осуществляться доступ к администрированию кластера и к виртуальным машинам, развёрнутым в кластере.
Теперь нужно настроить дисковые массивы и диск-свидетель кворума.
Идём в Storage — Disks и должны тут увидеть несколько дисков, подключенных и подготовленных на стадии подготовки серверов.
Если дисков в списке нет — их необходимо добавить. Нажимаем Add Disks и выбираем необходимые нам диски из списка предложенных. Если же система говорит что No disks Suitable for cluster disks were found… значит где-то ошиблись при подготовке дисков. Мастер проверки должен был об этом написать.
Диски необходимо отформатировать в NTFS, назначить им букву и добавить в список.
Диск-свидетель. Для него будем использовать диск объёмом 1GB, в моём случае это Cluster Disk 1.
Для настройки свидетеля необходимо выбрать сам кластер и в разделе Actions нажать More-Actions — Configure Cluster Quorum Settings… Снова откроется соответствующйи мастер.
В мастере на шаге Select Quorum Configuration Options выбираем Select the quorum witness. На следующем шаге — Configure a disk witness.
Так же есть возможность использовать свидетель кворума на основе сетевой папки общего доступа (необходимое условие — протокол SMB3.0, либо использовать «облачный» свидетель кворума).
Мы будем использовать диск-свидетель, полученный по iSCSI с дисковой полки.
На следующем шаге выбираем хранилище, на котором разместим свидетель кворума.
В списке дисков можно посмотреть что изменилось. Так же я переименовал диск свидетель, чтобы не путаться в дальнейшем (делается так же, как и с сетями кластера):
Теперь необходимо добавить общее хранилище (Cluster Shared Volume, CSV).
В разделе Disks выбираем диск, из которого хотим сделать CSV и жмём Add to Cluster Shared Volume.
После добавления диска в CSV на системном диске каждого хоста кластера в директории C:\ClusterStorage автоматически создаётся объект с именем Volume#, в нашем случае — Volume1. Опять же, для удобства его можно переименовать.
P.S. Как работать с кластером, в двух словах: ПКМ на пункт Roles — Configure Role, выбрать из списка Virtual Machine и выбрать необходимые ВМ, уже развёрнутые на одном из хостов кластера.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Источник
Создание группы доступности AlwaysON на основе кластера Failover
Коротко о главном: каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. В каждой группе доступности может быть до 8 вторичных реплик.
Что это и зачем требуется
Группы доступности AlwaysOn — это решение высокой доступности и аварийного восстановления, является альтернативой зеркальному отображению баз данных на уровне предприятия. Если БД не справляется с потоком запросов или есть опасения, что при сбое на сервере пропадут ценные данные, есть смысл использовать это решение. Группы доступности AlwaysOn могут отвечать за выполнение сразу двух задачи: высокий уровень доступности обеспечивает бесперебойную работу системы, а нагрузка по чтению из БД частично выполняется на репликах.
Создание группы доступности может понадобиться, если вам необходимо:
Создать избыточную доступность баз данных (в этом случае рекомендуем располагать ноды в геоудалённых дата-центрах, т.к. избыточная доступность предполагает доступность БД при любых технических неполадках на любой из нод);
Увеличить быстродействие ответов баз данных по принципу горизонтального расширения (в этом случае одна нода в кластере является мастером, осуществляющей операции записи и чтения, остальные ноды работают в режиме слушателей и позволяют считывать данные при запросах обращения)
При отказе основой реплики, кластер проголосует за новую основную реплику и Always On переведёт одну из вторичных реплик в статус основной. Так как при работе с Always On пользователи соединяются с прослушивателем кластера (или Listener, то есть специальный IP-адрес кластера и соответствующее ему DNS-имя), то возможность выполнять write-запросы полностью восстановится. Прослушиватель также отвечает за балансировку select-запросов между вторичными репликами.
Подготовка инфраструктуры
Сначала необходимо создать виртуальную машину и пользователей. В VDC создаем 3 ВМ, даём имена согласно ролей, выполняем настройки кастомизации.
После этого переходим к этапу настройки контроллера домена. Устанавливаем роли AD, DNS, Failover Cluster.
Устанавливаем роль контроллера домена
Создаём в AD компьютеры ND01 и ND02.
На ВМ ND01 и ND02 ставим компонент Failover Cluster
Теперь переходим к созданию кластера отказоустойчивости. На контроллере домена DC01 создаём кластер отказоустойчивости и добавляем в него наши ноды.
При создании кластера снимаем галочку с добавления массивов в каталог. Эту настройку можно сделать позже.
Создание кластера завершено.
Переходим к настройке кворума. Для этого выбираем пункты, которые указаны на скриншоте.
В конфигурации свидетеля кворума указываем file share.
После этого необходимо создать директорию на сервере, не участвующем в кластере, но имеющим общую сеть с кластером. После создания такой директории и добавления шары для доступа к ней нод из кластера, в настройке свидетеля нужно указать UNC путь.
Если после создания свидетеля у вас возникнет ошибка как на примере ниже,
…то в этом случае необходимо проверить настройки прав доступа к сетевой директории, указанной в настройках свидетеля.
Переходим к установке MS SQL 2015 Enterprise на ноды в кластере. Перед установкой модуля необходимо отключить брандмауэр на работу в доменной сети на всех ВМ, участвующих в кластере.
Устанавливаем MS SQL в standalone режиме, без дополнительных модулей. При выборе пользователя для примера берём Администратора доменной сети. Для боевых серверов рекомендуем сделать отдельного пользователя. Наверное, не нужно объяснять, почему это важно.
Затем необходимо установить SQL Management Studio на обе ноды в кластере.
Добавление тестовой базы данных в MSSQL
На ноде ND01 устанавливаем тестовый образец базы данных. Имя тестовой БД будет Bike-Store. Тестовая БД взята отсюда.
После установки БД выделяем созданную базу данных, после чего выбираем файл БД при помощи комбинации Ctrl+O.
После открытия файла нажимаем «Выполнить»
Важно! Перед развертыванием группы доступности обязательно делаем резервную копию БД, в противном случае не получится создать группу доступности
Настройка Always On в MS SQL Server
Для каждой ноды необходимо включить поддержку схемы AlwaysON в SQL Server Configuration Manager в свойствах экземпляра.
На ноде ND01 В SQL Server Management Studio выберите узел «Always On High Availability» и запустите мастер настройки группы доступности (New Availability Group Wizard).
Присваиваем имя нашей группе доступности: BikeStores-AG
Нажмите «Добавить реплику» и подключитесь к второму серверу SQL. Таким образом можно добавить до 8 серверов.
Ключевые параметры
Исходная роль – роль реплики на момент создания группы. Может быть Primary и Secondary;
Автоматический переход – если база данных станет недоступна, Always On переведёт primary роль на другую реплику. Отмечаем чекбокс;
Режим доступности – возможно выбрать Synchronous Commit или Asynchronous Commit. При выборе синхронного режима транзакции, поступающие на primary реплику, будут отправлены на все остальные вторичные реплики с синхронным режимом. Primary реплика завершит транзакцию только после того, как реплики запишут транзакцию на диск. Таким образом исключается возможность потери данных при сбое primary реплики. При асинхронном режиме основная реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;
Вторичная реплика для чтения – параметр, задающий возможность делать select-запросы к вторичным репликам. При значении yes, клиенты даже при соединении без ApplicationIntent=readonly смогут получить read-only доступ;
Для фиксации требуются синхронизированные получатели – число синхронизированных вторичных реплик для завершения транзакции. Нужно выставлять в зависимости от количества реплик. Имейте в виду, что, если вторичных синхронизированных реплик станет меньше указанного числа (например, при аварии), базы данных группы доступности станут недоступны даже для чтения.
На вкладке Параметры резервного копирования можно выбрать откуда будут делаться бекапы. Оставляем всё по умолчанию – Предпочитать вторичную.
Указываем имя слушателя группы доступности, порт и IP-адрес.
Если все тесты во время окончания прошли успешно, то нажимаем кнопку «Далее».
На этом первичная настройка группы доступности AlwaysON завершена. Вы можете провести тесты отказоустойчивости, попеременно отключая каждую ноду в кластере, а также давая простые запросы select, insert.
Надеемся, наша инструкция по создании групп доступности поможет вам обеспечить надлежащий уровень работоспособности вашей ИТ-инфраструктуры. В дальнейшем мы планируем выпустить и другие варианты сценариев. Если вам интересны какие-то нюансы – напишите о них в комментариях. Спасибо за внимание!
В России стартовала распродажа «Киберпонедельник-2021». Мы тоже решили принять участие в этой акции, и на три дня открыли бесплатный доступ к видеокурсу «Управление виртуальным дата центром и сетями в vCloud Director (VMware)» специально для тех, кто хочет разобраться в этой теме и научиться управлять облачной инфраструктурой.
В результате вы и ваши сотрудники сможете эффективнее использовать облачные платформы и больше не будете не путаться при работе с виртуальными машинами.
Курс уже получил 91 оценок от 366 студентов, средняя оценка — 4,5. Сейчас он снова бесплатно доступен на Udemy! Регистрируйтесь и учитесь!
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Источник