В статье приводится краткий обзор
создания отказоустойчивого кластера 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
Содержание
- Что такое реплика Hyper-V
- Объем и назначение реплики Hyper-V
- Реплика предназначена для аварийного восстановления
- Реплика не является заменой кластеризации или автоматизированного аварийного переключения
- Реплика не заменяет резервную копию
- Реплика не заменяет контрольные точки
- Реплика Hyper-V не является универсально применимой
- Настройка Hyper-V Replica
- Добавляем хосты Hyper-V в диспетчере Hyper-V
- Конфигурация репликации
- Включение правила брандмауэра Windows для включения репликации между основным сервером, репликой и сервером расширенной реплики
- Включаем репликацию для виртуальной машины на Server1
- Просмотр состояния репликации виртуальной машины, Server1
- Test Failover
- Planned Failover and Failback
- Unplanned Failover
- Cancel Failover
Что такое реплика Hyper-V
«Hyper-V Replica » — это технология, представленная в Windows Server 2012, которая не требует настройки «отказоустойчивого кластера Windows» на серверах Hyper-V.
Использование Hyper-V Replica в производственной среде в качестве технологии аварийного восстановления дает ряд преимуществ. «Реплика Hyper-V» может не только работать в некластерной среде, но также предоставляет подмножество компонентов; под названием «Hyper-V Replica Broker», который можно использовать для обеспечения высокой доступности для «основных серверов» Hyper-V. В этой статье я не буду касаться компонента «Hyper-V Replica Broker», а сосредоточусь на том, чем полезна «Hyper-V Replica» и как ее реализовать.
Реплика Hyper-V предоставляет следующие преимущества:
- С некоторым простоем виртуализированные рабочие нагрузки могут быть переключены на «сервер-реплику» на случай, если что-то пойдет не так с «основным сервером».
- Нет необходимости иметь идентичное оборудование для «основного сервера и сервера-реплики», как в случае с функцией «отказоустойчивой кластеризации Windows».
- «Реплика Hyper-V» может работать в режимах «Модель безопасности рабочей группы» и «Модель безопасности домена». Таким образом, членство в домене Active Directory не требуется для «основных серверов и серверов-реплик».
- «Реплика Hyper-V» предоставляет возможности для восстановления виртуальных машин на «сайте реплики» в резервную копию «на момент времени».
- Реплика Hyper-V предоставляет интерфейсы прикладного программирования (API). С помощью API-интерфейсов поставщики программного обеспечения могут настраивать параметры и создавать корпоративное решение для аварийного восстановления.
- В отличие от технологий высокой доступности «Быстрая и динамическая миграция» Hyper-V, членство в Active Directory не требуется для «Основных серверов и серверов-реплик», и оба сервера могут быть частью другого домена Active Directory, если это необходимо.
- Реплика Hyper-V тесно интегрирована со службой теневого копирования томов, которая позволяет администраторам создавать несколько резервных копий на определенный момент времени.
- Поскольку реплицированные данные передаются по сети, реплика Hyper-V обеспечивает шифрование и сжатие данных при репликации данных виртуальной машины на «сайт реплики».
Важным, но часто игнорируемым компонентом защиты данных является аварийное восстановление (DR). Аварийное восстановление сбивает с толку, может быть дорогостоящим и, при отсутствии реальной или предполагаемой угрозы, может быть проигнорировано как ненужные накладные расходы. Многие предприятия, которые страдают от полной потери данных, не восстанавливаются, но очень немногие предприятия вообще страдают от полной потери данных. Реплика Hyper-V устраняет сложность и стоимость аварийного восстановления; оставшаяся задача для ИТ состоит в том, чтобы преодолеть любые барьеры восприятия.
Объем и назначение реплики Hyper-V
К сожалению, многие не до конца понимают, для чего лучше всего подходит реплика Hyper-V (HVR), и, следовательно, используют ее не по назначению или вовсе пропускают, когда она может быть полезна. Потратьте несколько минут, чтобы подумать о том, что он действительно может сделать, и какие проблемы лучше всего решить с помощью другого инструмента.
Помните, что реплика Hyper-V не является повсеместно поддерживаемой технологией. Например, не поддерживается использование HVR для любой роли Microsoft Exchange. Прежде чем использовать HVR с какой-либо технологией, проверьте ее документацию или обратитесь к персоналу службы поддержки.
Реплика предназначена для аварийного восстановления
Реплика виртуальной машины — это полная, готовая к запуску копия исходной виртуальной машины. Его можно включить и начать работу через несколько секунд. Когда это происходит, HVR предполагает, что исходная виртуальная машина потеряна и не подлежит восстановлению. Когда реплика активирована, она в каком-то смысле становится «официальной» копией виртуальной машины.
Реплика не является заменой кластеризации или автоматизированного аварийного переключения
Основное различие между HVR и отказоустойчивым кластером заключается в том, что HVR всегда поддерживает две отдельные копии одной и той же виртуальной машины, тогда как при кластеризации используется только одна. Отказоустойчивая кластеризация предназначена для быстрого перемещения защищенного ресурса — в данном случае виртуальных машин — с недоступного хоста на доступный хост. Причиной того, что исходный хост стал недоступным, может быть что-то вроде операции перезагрузки. Для кластеризации требуется устойчивый доступный базовый механизм общего хранилища. Реплика предназначена для обеспечения быстрого восстановления виртуальной машины при потере одного или нескольких исходных компонентов, при условии, что быстрое восстановление этих компонентов невозможно.
Отказоустойчивая кластеризация предназначена для автоматизации. HVR не должен быть автоматизирован. В отличие от отказоустойчивой кластеризации здесь нет кворума, блокировки файлов или другой защиты, предотвращающей одновременный перевод источника и реплики в оперативный режим, если узлы источника и реплики не могут связаться друг с другом. Реплика работает на предположениях: если реплика активна, она должна быть активирована намеренно. Если виртуальные машины-источник и реплика активны одновременно, у вас есть сценарий «разделенного мозга». Клиенты могут быть сбиты с толку, к какому из них подключаться. Данные могут обновляться в двух местах одновременно. Это может создать ситуацию, из которой вы не сможете восстановиться без потери данных.
Реплика не заменяет резервную копию
Для максимальной эффективности резервные копии следует размещать в мобильном или удаленном хранилище, которое можно перевести в автономный режим. Хосты-реплики должны быть постоянно подключены, чтобы HVR обеспечивал максимальное значение. Резервная копия должна иметь некоторую возможность ротации, чтобы она могла поддерживать несколько копий. HVR имеет некоторые функции многократного копирования для своих данных, но не для компонентов виртуальной машины. Резервное копирование лучше всего работает с достаточно длинной исторической цепочкой. Реплика лучше всего работает с довольно короткой исторической цепочкой.
Основное различие между HVR и резервным копированием заключается в том, что данные HVR потенциально доступны в любое время. Резервная копия должна быть доступна только для чтения, если только она не перезаписывается новой резервной копией. В идеале резервное копирование должно иметь некоторую методологию ротации, при которой существуют по крайней мере две отдельные, несвязанные копии. Replica может сделать что-то подобное, указав вторую цель для той же реплики — это называется Extended Replica . Однако эта вторичная реплика также всегда готова к подключению к сети в любое время и поэтому восприимчива к тем же событиям, что и первичная. К ним относятся сбой хранилища, повреждение, переданное из источника, подделка данных и другие проблемы, которые не влияют на автономные носители.
Реплика не заменяет контрольные точки
Контрольные точки — это полезная функция, изначально предназначенная для быстрого отката состояния виртуальной машины. После некоторой эволюции технологии она также позволяет экспортировать виртуальную машину, даже если она работает, что позволяет создавать полные дубликаты по запросу.
- У вас есть полный контроль над тем, когда создается контрольная точка, тогда как реплики выполняются автоматически по заданному расписанию.
- Контрольная точка не может существовать независимо от базовой виртуальной машины, тогда как реплика — это отдельная копия.
- Контрольную точку можно восстановить гораздо быстрее, чем реплику.
- Контрольные точки непригодны для аварийного восстановления, тогда как HVR в первую очередь предназначен для аварийного восстановления. HVR вообще не может быстро восстановить виртуальную машину и не может вернуть ее на определенный момент времени.
Эти две технологии радикально различаются по функциям и назначению и не могут использоваться взаимозаменяемо.
Реплика Hyper-V не является универсально применимой
Некоторые технологии несовместимы или бессмысленны для использования с репликой Hyper-V. Реплика Hyper-V похожа на отказоустойчивую кластеризацию в одном отношении: Microsoft разработала универсальную службу, которую можно использовать с технологиями, не имеющими такой встроенной службы. Почти каждой службе, имеющей собственные возможности репликации, лучше не использовать реплику Hyper-V. Два основных примера:
- Доменные службы Active Directory . Реплику Hyper-V можно использовать с Active Directory. Если вы не выполняете репликацию для стороннего поставщика, в этом нет особого смысла. Гораздо лучше установить полноценную виртуальную машину контроллера домена на хост-реплику. Технология репликации Active Directory работает намного лучше при гораздо меньших накладных расходах, и у вас есть дополнительное преимущество — работающий контроллер домена, работающий в вашем центре обработки данных-реплике.
- Exchange Майкрософт . Microsoft полностью не поддерживает Exchange с репликой Hyper-V, и существуют известные проблемы с ее использованием. Как и в случае с Active Directory, Exchange имеет свои собственные технологии репликации, которые намного превосходят те, что может предложить реплика Hyper-V.
- Microsoft SQL-сервер . При некоторых условиях Microsoft будет поддерживать SQL Server, защищенный репликой Hyper-V. Однако, подобно AD и Exchange, SQL может реплицировать себя лучше, чем Hyper-V.
В целом, я бы сказал, что любое приложение с собственными возможностями репликации не выиграет от реплики Hyper-V.
Настройка Hyper-V Replica
Windows Server 2016 Hyper-V мы будем настраивать виртуальную машину для репликации с Основного сайта A на Вторичный (Реплику) Сайт B, а затем для дальнейшей репликации с Вторичного Сайта B на Расширенную Сайт-реплику C, как показано на рисунке.
В рамках этого разбора мы настроим от отного сайта репликацию в 30 секунд , и на расширенную 5 минут или 15 минут в зависимости от среды, критичности операций и доступной пропускной способности. Под сайтами подразумеваются Hyper-V хосты.
Добавляем хосты Hyper-V в диспетчере Hyper-V
1. На Server1 в консоли Hyper-V Manager щелкните правой кнопкой мыши Hyper-V Manager и выберите « Подключиться к серверу… ».
2. В диалоговом окне « Выбор компьютера » выберите « Другой компьютер », введите Server2 и нажмите «ОК » , где Server2 — это сервер Hyper-V. Проделайте тот же процесс с сервером Hyper-V, Server3.
Конфигурация репликации
1. В интерфейсе диспетчера Hyper-V щелкните правой кнопкой мыши SERVER1, выберите « Настройки Hyper-V… ».
2 . В диалоговом окне « Настройки Hyper-V для SERVER1» нажмите « Конфигурация репликации » . В области репликации выберите Включить этот компьютер в качестве сервера-реплики . В разделе Аутентификация и порты выберите Использовать Kerberos (HTTP).
3. В разделе Авторизация и хранилище выберите Разрешить репликацию с указанных серверов и нажмите Добавить.
4. В диалоговом окне Добавить запись авторизации в поле Укажите основной сервер : *.pentagon.loc нажмите кнопку Обзор и выберите папку C:Hyper-V Replica . В поле Specify the trust group введите My Replica Group и нажмите OK.
Что такое Trust server group ?
5. В диалоговом окне « Настройки Hyper-V для SERVER1 » нажмите « Применить », а затем нажмите « ОК».
6 . Проделайте тот же процесс на SERVER2 и SERVER3. На SERVER2 в диалоговом окне « Добавить запись авторизации » в поле « Укажите основной сервер » ; SERVER1.pentagon.loc, а затем нажмите « Обзор » и выберите папку C:Hyper-V Replica . В поле Укажите, что группа доверия должна быть такой же, как и предыдущая . На SERVER3 в диалоговом окне « Добавить запись авторизации » укажите основной сервер ; SERVER2.pentagon.loc, а затем нажмите « Обзор » и выберите папку D:Hyper-V Replica .Укажите, что группа доверия должна быть такой же, как и предыдущая.
Включение правила брандмауэра Windows для включения репликации между основным сервером, репликой и сервером расширенной реплики
1. На SERVER1 откройте брандмауэр Windows с расширенной безопасностью , откройте окно « Выполнить », введите wf.msc и нажмите « ОК».
На странице Брандмауэр Windows в режиме повышенной безопасности щелкните Правила для входящих подключений в разделе Брандмауэр Windows в режиме повышенной безопасности на локальном компьютере.
В правилах для входящих подключений щелкните правой кнопкой мыши HTTP-прослушиватель реплики Hyper-V (TCP-In) и выберите Включить правило. Проделайте тот же процесс на SERVER2 и SERVER3 . Если используется проверка подлинности на основе сертификата, мы должны включить прослушиватель HTTPS реплики Hyper-V Rule (TCP-In).
Включаем репликацию для виртуальной машины на Server1
1 . На Server1 откройте консоль управления Hyper-V , на панели сведений щелкните правой кнопкой мыши выбранную виртуальную машину в моем случае это Server1 и выберите « Включить репликацию». Это запустит мастер включения репликации.
2. На странице « Перед началом » нажмите « Далее».
3. На странице « Укажите сервер-реплику» в поле « Сервер-реплика » введите либо NetBIOS, либо полное доменное имя (FQDN) для сервера-реплики, SERVER2 , и нажмите « Далее».
4. На странице « Укажите параметры подключения » нажмите « Далее » .
5. На странице Choose Replication VHD нажмите Next.
6. На странице « Настройка частоты репликации » выберите 30 секунд и нажмите « Далее».
7. На странице « Настройка дополнительных точек восстановления » выберите « Создать дополнительные точки восстановления с почасовой оплатой » и нажмите « Далее » .
8. На странице « Выберите метод начальной репликации » нажмите « Далее».
9. На странице « Завершение работы мастера включения репликации » просмотрите информацию в сводке и нажмите « Готово».
10. Запустится процесс включения репликации , который должен завершиться успешно (т. е . на сервере реплик создается виртуальная машина и начинается дельта-репликация). После завершения реплики между основным хостом, SERVER1 и вторичным хостом, SERVER2, запустите расширенную репликацию с SERVER2 .
Включение расширенной репликации с сервера реплики на сервер расширенной реплики (Server2 на Server3)
11 . В интерфейсе диспетчера Hyper-V щелкните Server2 и щелкните правой кнопкой мыши Реплицированную виртуальную машину , «server1» , щелкните Репликация , а затем выберите Расширить репликацию…
12. На странице « Перед началом » нажмите « Далее».
13. На странице « Укажите сервер -реплику » введите Server3 в поле « Сервер-реплика » и нажмите « Далее».
14. На странице « Задать параметры подключения » нажмите « Далее».
15. На странице « Настройка частоты репликации » выберите 5 минут и нажмите « Далее».
16. На странице Настройка дополнительных точек восстановления нажмите Далее.
17. На странице « Выберите метод начальной репликации » нажмите « Далее».
18. На странице « Завершение работы мастера расширения репликации » нажмите « Готово».
19. Расширенная репликация.. Начинается
Просмотр состояния репликации виртуальной машины, Server1
1. Репликация Heath между Server1 и Server2.
2. Состояние репликации между SERVER2 и SERVER3.
Test Failover
Чтобы проверить согласованность репликации между сайтами, доступна Test Failover функция аварийного переключения, которая инициируется по запросу администратором Hyper-V. Он создает временную виртуальную машину, которая является копией оригинала,не прерывая производственную рабочую нагрузку, выполняемую на основном сайте. Во время тестирования Failover нет необходимости останавливать ВМ на производственной площадке. Целью Test Failover является проверка состояния репликации виртуальной машины в реплике и на сайте расширенной реплики. Конфигурация сети для виртуальной машины Test Failover отключена по умолчанию, чтобы не мешать производственной рабочей нагрузке, как указано выше.
1. Войдите на основной сайт, Server1 , откройте консоль диспетчера Hyper-V и подключитесь к виртуальной машине Server1, а затем создайте тестовый документ с именем Hyper-v Test Failover на рабочем столе и введите » Это тест Failover » и сохраните его.
2. В консоли диспетчера Hyper-V на панели сведений выберите виртуальную машину на сервере реплик, Server2, щелкните правой кнопкой мыши виртуальную машину-реплику (Server1), выберите «Репликация » и выберите «Проверить отказоустойчивость…».
3. В диалоговом окне Test Failover выберите точку восстановления и нажмите Test Failover.
4. Новая копия виртуальной машины, созданная в диспетчере Hyper-V в выключенном состоянии, а затем щелкните правой кнопкой мыши только что созданную виртуальную машину, server1 и нажмите Подключить…
6. Убедитесь, что документ Hyper-V Test Failover находится на рабочем столе.
7. Убедившись в этом, в области сведений выберите виртуальную машину для начала тестирования. Щелкните правой кнопкой мыши виртуальную машину server1 , выберите « Репликация », а затем выберите «Остановить тестовую отработку отказа» , чтобы остановить тестовую отработку отказа.
8. В диалоговом окне Stop Test Failover щелкните Stop Test Failover , после чего он автоматически удаляется из диспетчера Hyper-V по завершении теста. Мы можем сделать тот же процесс на сервере расширенной реплики, Server3.
Planned Failover and Failback
Planned Failover ,
Если на данный момент все в порядке, а неприятности запланированы на определенное время, то можно не дожидаться проблем и произвести переключение с основной площадки на резервную заранее. Эта процедура называется Planned Failover —
Инициирует отказ виртуальной машины с основного сайта на сайт-реплику. При выполнении планового перехода на другой ресурс виртуальная машина основного сайта(Server1) должена быть отключена. После того, как виртуальная машина сайта-реплики(Server2) заработает, направление репликации следует изменить на противоположное, чтобы направить трафик с сайта-реплики (который теперь является нашим основным сайтом(Server2)) на исходный основной сайт(Server1) который сейчас отключен для целей запланированного отказоустойчивость. Для запланированного тестового аварийного переключения, если установлен флажок Reverse the replication после аварийного переключения, мы должны отключить extended replication на виртуальной машине-реплике или удалить extended replication на виртуальной машине-реплике. Однако если флажок Reverse the replication после аварийного переключения не установлен, процесс будет работать без ошибок, но будет невозможно вернуться к основному. Таким образом, тест должен быть тщательно спланирован. Пожалуйста, внимательно следуйте приведенным ниже инструкциям.
1. Чтобы выполнить запланированный переход на другой ресурс , сначала мы должны выключить основную виртуальную машину (server1) с основного сервера, SERVER1
2. На Server1 в диспетчере Hyper-V на панели сведений выберите виртуальную машину и щелкните правой кнопкой мыши server1 , выберите « Replication », а затем выберите « Planned Failover».
3. В диалоговом окне « Planned Failover » убедитесь, что выбрано «Reverse the replication direction after failover» , «Start the replica virtual machine after failover» и нажать « Fail Over» .
4. В диалоговом окне «Planned Failover» мы получаем сообщение об ошибке «The virtual machine is not prepared for planned failover». Нажмите «Закрыть» и нажмите «Отмена».
5. В консоли диспетчера Hyper-V щелкните Server2 и щелкните правой кнопкой мыши по виртуальной машине server1, выберите « Replication», а затем выберите « Remove replication».
6. В диалоговом окне Удалить репликацию выберите Remove extended replication , а затем выберите Remove replication .
7. Повторите процесс с шага 1 по шаг 3 . Затем начинается процесс Planned Failover . Через несколько минут в диалоговом окне «Planned Failover completed successfully » нажмите «Закрыть».
8. В интерфейсе диспетчера Hyper-V щелкните SERVER2 и убедитесь, что виртуальная машина server1 запущена . Состояние Running
9. В интерфейсе диспетчера Hyper-V щелкните SERVER1 и убедитесь, что виртуальная машина (server1) находится в выключенном состоянии.
10. После успешного тестирования виртуальной машины с запланированным отказоустойчивостью (server1) на Server2 хосте выключите виртуальную машину, чтобы вернуться к основному хосту Server1.
11. В диалоговом окне « Завершение работы компьютера » нажмите «Завершение работы».
12. В интерфейсе диспетчера Hyper-V щелкните SERVER2, щелкните правой кнопкой мыши на виртуальную машину server1 , щелкните Replication, а затем щелкните Planned Failover.
13. В диалоговом окне « Planned Failover » выберите «Reverse the replication derection after failover » и «Start the Replica virtual machine after failover», а затем нажмите « Fail Over» .
14. Начинается плановое аварийное переключение.
16. В интерфейсе диспетчера Hyper-V щелкните Server1 и убедитесь, что виртуальная машина (server1) находится в рабочем состоянии , а затем установите флажок View Replication Health.
Изначально мы будем видеть warning , но после временной репликации , получим Replication Health : Normal
Replication Health с Server2
Unplanned Failover
Unplanned failover — незапланированная отработка отказа инициирует отработку отказа, когда виртуальная машина основного сайта неожиданно выходит из строя и не может быть возвращена в оперативный режим. На сайте реплики инициирован незапланированный переход на другой ресурс. (Это тест, наиболее близкий к реальному сценарию).
1. Для выполнения незапланированного перехода на другой ресурс основной сайт должен находиться выключенном состоянии . Здесь мы выключим сервер Hyper — V основного сайта, Server1.
2. Перейдите на сервер-реплику Server2 . В интерфейсе диспетчера Hyper-V щелкните правой кнопкой мыши виртуальную машину-реплику (server1) , выберите « Replication », а затем щелкните « Failover».
3. В диалоговом окне Failover выберите точку восстановления, которую нужно использовать, а затем щелкните Failover. Затем виртуальная машина запускается на сервере-реплике.
4. После запуска виртуальной машины-реплики репликация между основным и вторичным прерывается, возникают проблемы с репликацией.
По началу это будут warning, после Critical
5. Когда последствия аварии будут устранены и связь с основным сервером будет восстановлена, у нас есть два варианта развития событий:
• Cancel Failover — произвести отмену файловера. Реплика останавливается, основная машина стартует и репликация продолжает идти в том же направлении. При этом все изменения, которые производились с репликой во время Failover, будут потеряны;
• Reverse Replication — повернуть репликацию в обратную сторону, меняя местами основной сервер и сервер реплики. Если выбрать этот пункт, то запустится мастер настройки и репликацию придется настраивать заново.
6. Мы выбираем Reverse Replication , это создаст обратную репликацию даже если сервер переустановился. То есть мы будем заново настраивать репликацию.
К примеру hyper-v Server1 , пережил переустановки или разрушение RAID массива.
Переходим на Server1 , и выключаем виртуальную машину , или у нас ее нет , в зависимости от ситуации.
Переходим на хост Server2 , в интерфейсе диспетчера Hyper-V щелкните правой кнопкой мыши виртуальную машину-реплику (server1) , выберите « Replication», а затем щелкните « Reverse Replication». и повторяем все что мы делали ранее. Только в этом процессе мы запускаем обратную репликацию где хост Server1 , у нас станет сервером репликой.
7.Теперь хост Server1 , держит реплику виртуальной машины Server1 , где Primary сервер является хост SERVER2.
8. Запускаем обратную репликацию чтобы Server1 стал снова Primary сервером. Описываю ниже
Проверяем Server2 — да он является Primary
9.Перейдите на Primary server — Server2 . Выключаем виртуальную машину server1
В интерфейсе диспетчера Hyper-V щелкните правой кнопкой мыши виртуальную машину-реплику (server1) , выберите « Replication», а затем щелкните « Planned Failover».
10. В интерфейсе диспетчера Hyper-V щелкните Server1 и убедитесь, что виртуальная машина (server1) находится в рабочем состоянии , а затем установите флажок View Replication Health.
11.На этом все закончено , хост Server1 , является primary сервером для виртуальной машины server1 , хост Server2 теперь является репликой. В текущем случае вам осталось , только настроить extend replica с Server2 на Server3. Но это вы уже и сами теперь умеете
Cancel Failover
• Cancel Failover — произвести отмену файловера. Реплика останавливается, основная машина стартует и репликация продолжает идти в том же направлении. При этом все изменения, которые производились с репликой во время Failover, будут потеряны;
1. Перейдите на сервер-реплику Server2 . В интерфейсе диспетчера Hyper-V щелкните правой кнопкой мыши виртуальную машину-реплику (server1) , выберите « Replication», а затем щелкните « Cancel Replication».
2. Соглашаемся с данным меню.
3.Виртуальная машина отключается , все данные которые в ней были с момента последней репликации , удаляются!
In this blog, we’ll learn the skill to make a Microsoft Windows Failover Cluster with Windows Server 2019. The environment may be a two-node cluster with one shared disk.
Environment details:
SRV2019-DC
10.0.0.20
SRV2019-1
Primary – 10.0.0.30
Cluster – 192.168.0.10
SRV2019-2
Primary : 10.0.0.40
Cluster: 192.168.0.20
iSCSI Storage : 10.0.0.100
Cluster Name – XTCLUSTER
Cluster IP Address – 10.0.0.110
1- Before we start, make sure you meet the following prerequisites:
I have 2 Windows Server 2019 machines with the latest updates installed. The machines have at least two network interfaces, I rename them Primary and Cluster.
Join both servers to your Microsoft Active Directory domain and confirm that both servers see the shared memory device available in disk management. So, don’t bring the disk online yet.
2- User the Following PowerShell command to enable failover clustering and management Toole 1 Node (SRV2019-1)
Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools
Failover Cluster Server 2019
Enabling Failover Manager Feature in 2 Node (SRV2019-2).
3- Open Server Manage select dashboard and then click on ADD Roles and Features.
4- So, click Next.
5- Click Role-based or feature-based installation and then click Next.
6- Select a server from the server pool and then click next.
7- So, click Next.
8- Select Failover clustering.
9- Click Add features.
10- After enabling the failover clustering feature so, click next.
11- Then click Install.
12- Successfully enable the Failover cluster feature so, click Close.
13- After a successful installation, it appears in the Server Manager, click Tools, and then Failover Cluster Manager.
After you installed the Failover Clustering feature so, you can bring the shared disk online and format it on one of the servers 1 Node (SRV2019-1).
The following steps are performed on the 1 Node (SRV2019-1).
14- In Server Manager click Tools and then click Computer Management.
15- Click on Disk Management.
ou will see disk 1 which is in offline status right click on disk 1 and then select Online.
16- Right-click on disk 1 and click Initialize Disk.
17- Click OK.
18- Right-click on unallocated disk 1 and select New Simple Volume.
19- Click Next.
20- Click Next.
21- Assign a drive letter and click Next.
22- Type a volume label and click next.
23- Click Finish.
24- 1 Node (SRV2019-1) Disk Management (disk status online)
25- Please Don’t change anything on the 2nd Node (SRV2019-2), the disk stays offline. 2ND Node (SRV2019-2) Disk Management (disk status offline).
Failover Cluster readiness check-in 1 Node (SRV2019-1).
Before we create the cluster, we’d like to form sure that everything is about up properly.
26- In Server Manager click Tools and Click Failover Cluster Manager.
27- Under Action menu click Validate Configuration.
28- Click Next.
29- Select the browse button.
30- Type both the Nodes name, click check name and click ok.
31- After Selecting the two-node servers for validation, click next.
32- Select Run all tests (recommended) and click next.
33- Review the validate configuration confirmation and click next.
34- Cluster validation testing is in progress.
35- After you make sure that every applicable test passed with the status successful. If you have any errors or warnings, you can use the detailed report by clicking on View Report and click Finish.
Create a Failover Cluster Server 2019
36- Under Action Menu so, select Create Cluster.
37- Click Next.
38- Click the browse button.
39- Type both the node names, click check names and click ok.
40- Both the servers nodes selected, click next.
41- Type a Cluster name, select the IP address and click next.
42- As a last step, confirm everything, click next and wait for the cluster to be created.
43- Cluster setup successfully completed and click Finish.
44- 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 afterward. As a result, you can see a new Active Directory computer object named XTCLUSTER.
45- You can ping the new computer to check whether it is online (if you allow ping on the Windows firewall).
As an alternative, you’ll create the cluster also with PowerShell. the subsequent command also will add all eligible storage automatically:
New-Cluster -Name XTCLUSTER -Node SRV2019-1, SRV2019-2 -StaticAddress 10.0.0.110
46- Both the Nodes are up now.
47- You can see the result in the Failover Cluster Manager in the Nodes and Storage under Disks sections.
For more information click here
How to Configure Network Load Balancing In Windows Server 2019.
Руководство по подключению ноды к кластеру 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 [VZLJOTotherservername$] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
CREATE LOGIN [VZLJOTsql-serv] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [dbcreator] ADD MEMBER [DOMAINotherservername$]
ALTER SERVER ROLE [dbcreator] ADD MEMBER [DOMAINsql-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 [DOMAINalmaaz$]
Проверка наличия:
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 ключ:
HKLMSOFTWAREVeeamVeeam Backup and Replication
REG_DWORD (32-bit)
Name UseCifsVirtualSynthetic
Value 0
Перенос в Hyper-V. Гостевая система bsod.
Загрузиться в виртуалке с какого-нибудь liveCD.
Regedit’ом встать на HKEY_LOCAL_MACHINE
Подгрузить куст WindowsSystem32configSYSTEM из склонированной системы под имененм 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 машины и убить его
1.1 Введение
Существует много способов создания кластера Hyper-V. Можно использовать традиционный способ — это когда средства отказоустойчивости кластеров устанавливаются локально на узлы Hyper-V и затем следовать пошаговым инструкциям Диспетчера Отказоустойчивости Кластеров на экране дисплея, чтобы создать кластер Hyper-V. Другие способы используют командлеты PowerShell отказоустойчивой кластеризации и System Center Virtual Machine Manager 2012. Начиная с SCVMM 2012, были представлены новые возможности по созданию кластера Hyper-V несколькими нажатиями клавиш в консоли VMM. Необходимо развернуть высокодоступное окружение для того, чтобы виртуальные машины, работающие на узлах Hyper-V, можно было перенести на другие узлы Hyper-V, являющиеся частью отказоустойчивого кластера. Несколько действий для создания кластера Hyper-V, необходимых выполнить вручную, описаны ниже:
- Установите компонент отказоустойчивой кластеризации на все узлы Hyper-V с помощью Диспетчера Серверов. Можно также использовать скрипты PowerShell для установки компонента отказоустойчивой кластеризации на все узлы Hyper-V, но для этого необходим опыт работы со скриптами PowerShell.
- Соединитесь к общему хранилищу и вручную представьте LUN`ы всем узлам Hyper-V. Кроме представления LUN`ов, необходимо инициализировать и отформатировать жёсткие диски и назначить им буквы.
- Создайте кластер на первом узле, открыв Диспетчер Отказоустойчивости Кластеров и затем добавив дополнительные узлы в кластер.
- Проверьте кластер, чтобы убедиться в том, что конфигурация кластера поддерживается Командой службы поддержки продукта Microsoft.
- Настройте параметры кворума кластера. В большинстве случаев параметры кворума настраиваются автоматически в зависимости от количества узлов Hyper-V в кластере.
- Затем необходимо добавить общее хранилище в Общий Том Кластера (CSV).
- И наконец, добавьте виртуальные машины в кластер Hyper-V.
Выполнение вышеуказанных действии вручную может занять достаточно много времени, если планируется развернуть сотни кластеров Hyper-V в производственной среде. Как только кластер Hyper-V развёрнут вручную, их надо добавить в VMM, если необходим VMM для управления кластерами Hyper-V. VMM выполняет все необходимые последовательные действия на узлах Hyper-V автоматически. Как только кластер Hyper-V создан с помощью VMM, кластер Hyper-V и его узлы управляются VMM.
Было дано задание: собрать для клиента кластер Hyper-V с 8-ю узлами. Само собой, воспользовался документацией Microsoft по VMM для создания кластера Hyper-V, однако документация не полностью отражает то, как же именно без проблем создать кластер Hyper-V, при этом храня в уме различные требования и параметры настройки. Например, документация Microsoft по VMM не отражает того, что физические сетевые адаптеры узлов Hyper-V должны быть доступны для размещения. Также документация Microsoft не предоставляет инструкций по настройке параметров TCP/IP на всех Hyper-V хостах, которые станут частью кластера Hyper-V. Возможно, что не увидите страницу с IP-адресом для указания IP-адреса кластера, который отображается во время создания кластера Hyper-V с помощью VMM, если параметры TCP/IP некорректны. Эта статья написана для того, чтобы помочь понять различные требования по настройке перед началом создания кластера Hyper-V с помощью VMM. Будет использоваться SCVMM 2012 R2 для создания двухузлового кластера Hyper-V.
В данной статье будут затронуты следующие темы:
- Требования к узлам Hyper-V и группе узлов VMM
- Требования к общему хранилищу кластера Hyper-V
- Требования к сети узлов Hyper-V
- Как создать кластер Hyper-V с помощью VMM
- Как это работает
- Добавление виртуальных машин в кластер Hyper-V посредством VMM
Существует несколько требований, которые необходимо помнить, перед тем, как начать создавать кластер Hyper-V посредством VMM. Например, перед тем, как начать создавать кластер Hyper-V из консоли VMM, необходимо удостовериться, что оптоволоконный канал правильно настроен вместе с узлами Hyper-V, группами узлов VMM, общим хранилищем и сетью узлов. В первой части статьи рассмотрим необходимые шаги для настройки узлов Hyper-V и групп узлов VMM. В последующих частях приступим к изучению настроек хранилища и сети, затем выполним пошаговые инструкции для успешного создания кластера Hyper-V.
1.2 Требования к узлам Hyper-V и группе узлов VMM
Группа узлов VMM: Группу узлов VMM необходимо создавать в SCVMM. Группа узлов VMM — это административная единица, которая необходима перед тем, как начать создавать кластер Hyper-V. Группа узлов VMM необходима для распределения логических устройств общего хранилища, если нужен VMM для назначения общего хранилища узлам Hyper-V. VMM ищет доступные логические устройства, которые нужно назначить, во время процесса создания кластера Hyper-V на группе узлов VMM. Если группе узлов VMM не были назначены логические устройства, то мастер создания кластера Hyper-V не отобразит общее хранилище. Об этом будет рассказано позже в требованиях к общему хранилищу.
Два или более узла Hyper-V: Узлы Hyper-V, которые станут частью кластера Hyper-V, должны быть добавлены в VMM, и они должны быть частью одной группы узлов VMM. Например, есть два узла Hyper-V с названиями «Hyper-VHost1» и «Hyper-VHost2» и одна группа узлов VMM с названием «Building2», эти узлы Hyper-V должны быть помещены в группу узлов VMM «Building2». VMM не предоставляет возможности для кластеризации узлов Hyper-V, которые расположены в разных группах узлов VMM. Как показано на рисунке ниже, создана родительская группа узлов, названная «Dallas» и дочерняя группа узлов VMM «Building2», где расположены узлы Hyper-V.
 |
| Рисунок 1 |
Помимо создания группы узлов VMM и помещения узлов Hyper-V в группу узлов VMM, необходимо запомнить следующие моменты перед тем, как продолжить создание кластера посредством VMM:
- Установка компонента Отказоустойчивой Кластеризации (Необязательно): Узлы Hyper-V могут быть установлены с компонентом Отказоустойчивой Кластеризации. VMM пропустит установку Отказоустойчивой кластеризации, если он уже был установлен на узлах Hyper-V. Есть вот такая ошибка при создании кластера «Ошибка (25300) Ошибка проверки кластера из-за ошибки: на сервере «Имя_сервера» не установлен компонент Отказоустойчивости Кластеризации. Используйте Диспетчер Серверов для установки компонента на этом сервере». В таком случае, заранее установите компонент Отказоустойчивой кластеризации на требуемых узлах Hyper-V.
- Узлы Hyper-V должны работать на поддерживаемой версии операционной системы Windows. Если узлы Hyper-V работают на операционной системе Windows Server 2012 R2, тогда необходимо, чтобы был установлен VMM 2012 R2 на операционной системе Windows Server 2012 R2.
- Если надо, чтобы узлы Hyper-V работали на Windows Server 2008 R2 с SP1, тогда необходимо установить исправление KB2531907.
- Узлы Hyper-V должны быть частью одного домена. Это стандартное требование для Отказоустойчивой кластеризации. Кластеризация не поддерживается, если узлы находятся в разных доменах. Помимо включения узлов Hyper-V в один домен, выполните другие требования для Отказоустойчивого кластера, которые описаны на сайте Microsoft.
- Включение Многопутевого ввода-вывода (Обязательно): Для получения доступа к общему хранилищу, компонент Многопутевого Ввода-Вывода (MPIO) должен быть установлен на каждом узле Hyper-V с помощью Диспетчера Серверов. SCVMM автоматически не добавляет компонент MPIO при добавлении узла Hyper-V в VMM. VMM отобразит предупреждающее сообщение в окне Заданий при добавлении узла Hyper-V в группу узлов VMM, если компонент Многопутевого Ввода-Вывода (MPIO) не установлен.
- Инициатор Microsoft ISCSI (Необязательно): Если используется iSCSI SAN в качестве общего хранилища, то убедитесь, что служба инициатора Microsoft iSCSI установлена и запущена на каждом узле Hyper-V, который станет частью кластера. Важно отметить, что служба инициатора Microsoft iSCSI используется VMM для автоматической настройки общего хранилища на узлах Hyper-V во время процесса создания кластера. Нет необходимости задавать iSCSI порталы на каждом узле Hyper-V, если используется общее хранилище, управляемое через SCVMM. Также можно задать и присоединить общее хранилище ко всем узлам Hyper-V вручную. Если так и сделано, то мастер создания кластера VMM автоматически настроит общее хранилище для отказоустойчивого кластера.
1.3 Краткий итог части
В первой части статьи были изучены различные требования узлов Hyper-V и групп узлов VMM перед тем, как мастер Создания Кластера Hyper-V может быть задействован для создания кластера посредством VMM. VMM требует, чтобы узлы Hyper-V принадлежали одной группе узлов VMM; также были обозначены другие требования, которые будут рассмотрены в этой статье.
Во второй части статьи начнём изучение настроек общего хранилища и сети для узлов Hyper-V, что поможет успешно создать кластер Hyper-V.
2.1 Введение
System Center Virtual Manager — это комплексный продукт управления центрами обработки данных. SCVMM спроектирован для управления всеми аспектами работы ИТ дата-центра. В SCVMM можно задать компоненты физической сети с помощью Сетей Виртуальных Машин. SCVMM позволяет управлять SAN хранилищем и кластерами файловых серверов. В первой части статьи были рассмотрены требования к группе узлов VMM и узлам Hyper-V перед началом создания кластера Hyper-V с посредством VMM. Во второй части рассмотрим требования к общему хранилищу и сети.
2.2 Требования к Общему Хранилищу Hyper-V
Так как для кластера Hyper-V требуется общее хранилище, то необходимо удовлетворить требования к общему хранилищу перед началом создания кластера Hyper-V. VMM позволяет присоединить iSCSI и оптоволоконный канал SANS и управлять этими массивами хранения данных. Пулы носителей из массивов хранения данных могут использоваться узлами Hyper-V, которые управляются посредством VMM. Например, можно назначить пулы носителей при создании Частного Облака, когда развёртываются виртуальные машины на узлы и когда развёртывается кластер Hyper-V. Существует два способа назначения общего хранилища узлам Hyper-V перед тем, как запустить мастер создания кластера Hyper-V:
Общее хранилище, управляемое и назначенное, с помощью SCVMM: Если хотите использовать общее хранилище, управляемое с помощью SCVMM, то запомните следующие моменты:
- Требуемые массивы общего хранилища должны быть заданы и классифицированы в рабочей области Структура. Если это не сделано, то перейдите в рабочую область Структура, правой клавишей мышки нажмите на раздел «Хранилище» и затем нажмите «Добавить Запоминающее Устройство», как показано на рисунке ниже:
 |
| Рисунок 2 |
- Если используется iSCSI SAN или конечный объект iSCSI Windows, то убедитесь, что служба инициатора iSCSI установлена и запущена на узле VMM. Это необходимо для успешного создания соединения к серверу iSCSI SAN из консоли VMM. В качестве примера в данной статье используется конечный объект iSCSI Windows, установленный на сервер с Windows Server 2012 R2. Как только массив хранения данных был добавлен в VMM, то можно будет увидеть все доступные пулы носителей при нажатии кнопки мышки на раздел «Классификации и Пулы» в рабочей области Структура, как показано на рисунке ниже:
 |
| Рисунок 3 |
Замечание: Сервер конечного объекта iSCSI Windows проверяет все локальные жёсткие диски и добавляет их в пулы носителей. В примере имеется четыре локальных жёстких диска, созданных на Сервере Хранилища, и каждый диск считается пулом носителей. Также там можно увидеть размер каждого пула носителей и размер свободного места.
- Логические устройства создаются и выделяются группе узлов, где размещаются узлы Hyper-V. Рассмотрим это подробней. Пулы носителей и логические устройства можно назначить только группе узлов VMM. Выделенные пулы носителей могут использоваться VMM только для размещения виртуальных машин. Выделенные логические устройства могут использоваться как кластером, так и виртуальными машинами. Нет необходимости выделять пулы носителей, но надо выделить логические устройства группе узлов VMM, если хотите, чтобы мастер создания кластера отобразил доступные логические устройства. Мастер создания кластера ищет логические устройства, а не пулы носителей, выделенные группе узлов VMM. Перед тем, как выделить логические устройства, убедитесь, что они были созданы с помощью «Создать Логические Устройств» в рабочей области Структура. Как только логические устройства созданы, нажмите правой кнопкой мышки на группу узлов VMM, на которых размещаются узлы Hyper-V, и выберите «Выделить Логические Устройства», как показано на рисунке ниже:
 |
| Рисунок 4 |
Замечание: Логические устройства, созданные из пула носителей общего хранилища, не должны быть назначены ни одному узлу Hyper-V. Мастер создания кластера Hyper-V в VMM может определить только логические устройства, которые не назначены ни одному узлу Hyper-V в VMM. Как видно на рисунке ниже, есть несколько логических устройств, выделенных группе узлов VMM, но некоторые из них зарезервированы для создания кластера.
 |
| Рисунок 5 |
В рабочей области Структура можно убедиться, что логические устройства, используемые кластером Hyper-V, не назначены ни одному узлу Hyper-V, перейдя в раздел «Классификации и Пулы», как показано на рисунке ниже:
 |
| Рисунок 6 |
- Общее хранилище, управляемое узлами: Если хотите использовать общее хранилище, которое управляется узлами Hyper-V, то убедитесь, что логические устройства были созданы на одном из узлов Hyper-V и отформатированы в NTFS. Это традиционный подход, которому нужно следовать при создании кластера Hyper-V посредством Диспетчера Отказоустойчивости Кластеров. Общее хранилище в данном случае должно быть назначено и доступно на всех узлах Hyper-V перед запуском мастера создания кластера Hyper-V посредством VMM.
2.3 Требования к сети узлов Hyper-V
Отказоустойчивая кластеризация требует, чтобы необходимый сетевой адаптер был добавлен в каждый узел Hyper-V. Помимо добавления сетевых адаптеров также необходимо понимать, как VMM будет работать с сетью на узлах Hyper-V в момент создания кластера Hyper-V посредством VMM. Мастер Создания Кластера Hyper-V также предоставляет возможность назначения IP-адреса кластеру, помимо назначения имени кластера. Страница IP-адреса может появиться, а может и нет, это зависит от выполнения следующих условий:
- Если используется конфигурация со статическим IP на каждом узле Hyper-V, то убедитесь, что по крайней мере один физический сетевой адаптер на всех узлах Hyper-V принадлежит той же подсети IP. Физические сетевые адаптеры должны быть также настроены со шлюзом по умолчанию для того, чтобы страница IP-адреса появилась во время создания кластера.
- Если узлы Hyper-V настроены на получение IP-адреса от DHCP-сервера, что не рекомендуется для производственной среды, мастер создания кластера не предоставит возможности назначения IP-адреса кластеру. Т.к. Windows Server 2012 и последующие ОС поддерживают назначение кластеру IP-адреса от DHCP-сервера, то мастер создания кластера автоматически выберет свободный IP-адрес от DHCP-сервера вместо отображения страницы IP-адреса.
Независимо от того, какой способ назначения IP-адресов сетевым адаптерам узлов Hyper-V используется, убедитесь, что эти сетевые адаптеры доступны для размещения. Чтобы узнать, доступны ли сетевые адаптеры для размещения, перейдите к свойствам всех узлов Hyper-V, нажмите кнопку «Сеть» и затем выберите сетевую карту для просмотра параметров настройки, как показано на рисунке ниже:
 |
| Рисунок 7 |
Виртуальный коммутатор: Мастер создания кластера Hyper-V позволяет автоматически создать виртуальный коммутатор на каждом узле Hyper-V. Нет необходимости создавать виртуальные коммутаторы во время создания кластера. Можно создать виртуальные коммутаторы на каждом узле Hyper-V заранее, но создание виртуальных коммутаторов посредством VMM сохраняет конфигурацию согласованной и в том же виде. Перед просмотром сетей виртуальных машин на странице Виртуального Коммутатора, необходимо убедиться, что физические сетевые адаптеры назначены на использование сети виртуальных машин в свойствах узла Hyper-V. Чтобы проверить, что сети виртуальных машин назначены узлам Hyper-V, перейдите в свойства каждого узла Hyper-V, нажмите кнопку «Оборудование» и затем выберите физический сетевой адаптер, как показано на рисунке ниже:
 |
| Рисунок 8 |
Как можно увидеть на рисунке выше, физический сетевой адаптер ассоциирован с логической сетью «Corp_Net». Если физический сетевой адаптера не ассоциирован ни с одной логической сетью, то на странице Виртуального Коммутатора не будет дано возможности создать виртуальный коммутатор автоматически на узлах Hyper-V.
2.4 Краткий итог части
Как видно, следует проделать много действий до фактического запуска Мастера Создания Кластера Hyper-V посредством VMM. В данной части было рассмотрено, как настроить общее хранилище и есть ли возможности успешного развёртывания отказоустойчивого кластера Hyper-V посредством VMM. В следующей части рассмотрим мастер Создания Кластера Hyper-V.
3.1 Введение
В двух первых частях данной статьи были рассмотрены требования, которые необходимо выполнить, перед началом использования мастера Создания Кластера в VMM. В третьей части рассмотрим процесс создания кластера на двух узлах Hyper-V посредством консоли VMM. Процесс создания Отказоустойчивого кластера Hyper-V посредством VMM очень прост. VMM сокращает время, необходимое для выполнения того же набора действии вручную. Выполняя этот процесс вручную, необходимо выполнить несколько действий, включая подготовку общего хранилища, установку компонента Отказоустойчивой Кластеризации Windows на всех узлах и т. д. VMM может выполнить все необходимые действия на узлах Hyper-V, которые станут частью кластера Hyper-V, автоматически.
Чтобы запустить Мастер Создания Кластера из консоли VMM, перейдите в рабочую область Структура, нажмите «Создать» и затем выберите «Кластер Hyper-V», как показано на рисунке ниже:
 |
| Рисунок 9 |
Нажатие на «Кластер Hyper-V» запустит окно «Мастер Создания Кластера», как показано на рисунке ниже. Мастер поможет создать кластер Hyper-V за минимальное количество действий. Всё, что требуется, – это предоставлять необходимую информацию мастеру создания кластера.
3.2 Шаг №1 — Назначение кластеру имени
Во вкладке «Общие» необходимо ввести имя кластера и данные учётной записи. Данные учётной записи будут использованы сервером VMM для доступа ко всем узлам Hyper-V и выполнения необходимых операций, таких как добавление компонента Отказоустойчивой Кластеризации, маскирование общего хранилища, выполнение проверочных тестов на кластере и т. д.
 |
| Рисунок 10 |
Нажмите кнопку «Далее» для перехода на страницу «Узлы».
3.3 Шаг №2 — Выбор узлов Hyper-V
На странице «Узлы» выберите Группу Узлов, содержащую узлы Hyper-V, которые станут частью кластера Hyper-V. Важно отметить, что нельзя выбирать узлы Hyper-V из разных групп узлов VMM. Узлы Hyper-V должны быть размещены в одной группе Узлов VMM перед тем, как начать создание кластера Hyper-V.
После выбора Группы Узлов отобразится список доступных узлов Hyper-V в данной группе узлов VMM. Необходимо выбрать узлы Hyper-V в списке «Доступных узлов» и затем нажать кнопку «Добавить» для помещения узла Hyper-V в список «Узлы для Кластера». Как видно на рисунке ниже, все узлы Hyper-V помещены в список «Узлы для Кластера».
Также имеется возможность пропустить выполнение тестов проверки кластера. Если установить флажок «Пропустить тесты проверки кластера», то VMM не станет запускать тесты проверки кластера на всех узлах, что в свою очередь сократит время необходимое для создания кластера посредством VMM. Можно запустить тесты проверки кластера позднее с помощью Диспетчера Отказоустойчивости кластеров.
 |
| Рисунок 11 |
Нажмите «Далее» для перехода на страницу IP-адреса.
3.4 Шаг №3 — Назначение кластеру IP-адреса
Мастер создания кластера предоставляет возможность назначение IP-адреса кластеру помимо назначения ему имени. Страница IP-адреса может появиться, а может и нет, в зависимости от выполнения следующих условий:
- Если используется конфигурация со статическим IP на каждом узле Hyper-V, то убедитесь, что по крайней мере один физический сетевой адаптер на всех узлах Hyper-V принадлежит той же подсети IP. Физические сетевые адаптеры должны быть также настроены со шлюзом по умолчанию для того, чтобы страница IP-адреса появилась во время создания кластера.
- Если узлы Hyper-V настроены на получение IP-адреса от DHCP-сервера, мастер создания кластера не предоставит возможности назначения IP-адреса кластеру. Другими словами, страница IP-адреса не появится. Поскольку Windows Server 2012 и последующие ОС поддерживают назначение кластеру IP-адреса от DHCP-сервера, то мастер создания кластера автоматически выберет свободный IP-адрес от DHCP-сервера вместо отображения страницы IP-адреса.
 |
| Рисунок 12 |
Нажмите «Далее» для перехода к выбору дисков общего хранилища. На странице Хранилища можно выбрать диски, которые желаете сделать доступными для кластера Hyper-V.
3.5 Шаг №4 — Выбор дисков общего хранилища
Существует два типа дисков, которые необходимо выбрать для кластера Hyper-V, чтобы он корректно работал: Диск-Свидетель и диск Данных Кластера.
Диск-Свидетель: Важно отметить, что Мастер Создания Кластера выбирает диск в качестве Диска-Свидетеля автоматически. Как можно увидеть на рисунке ниже, мастер создания кластера автоматически выбирает ClusterDisk1 в качестве Диска-Свидетеля. Если число узлов кластера чётно, то мастер создания кластера автоматически выберет диск, размер которого превышает 500 МБ. Невозможно отменить выбор диска, который автоматически выбран мастером создания кластера.
Диск Данных Кластера: Диск Данных Кластера необходим для хранения файлов виртуальных машин, таких как XML и VHD/VHDX файлы. Мастер Создания Кластера отобразит доступные кластеру диски. Важно понимать, что мастер создания кластера может только определить диски, которые не назначены ни одному узлу Hyper-V в VMM. Имеется несколько вариантов выбора для Дисков Данных Кластера, такие как выбор метки тома, форматирование дисков, назначение диска в Общие Тома Кластера (CSV) и т.д.
Выберите диски данных кластера и нажмите кнопку «Далее».
 |
| Рисунок 13 |
3.6 Шаг №5 — Назначение виртуальных коммутаторов
На следующей странице настроек Мастера Создания Кластера можно выбрать логические сети для создания внешних виртуальных коммутаторов на целевых узлах Hyper-V. VMM автоматически создаст виртуальные коммутаторы на всех узлах Hyper-V. Нет необходимости создавать виртуальные коммутаторы во время процесса создания кластера. Можно создать виртуальные коммутаторы на каждом узле Hyper-V позднее, но создание виртуальных коммутаторов посредством VMM сохраняет конфигурацию согласованной и в том же виде.
Замечание: Страница настройки Виртуальных Коммутаторов может не появиться во время работы Мастера Создания Кластера, если физические сетевые адаптеры узлов Hyper-V не были назначены в Сети Виртуальных Машин. Это можно проверить в свойствах каждого узла Hyper-V.
 |
| Рисунок 14 |
Как только необходимая информация введена, отобразится окно с краткой сводкой. Можно ещё раз проверить верность введённых данных перед нажатием кнопки «Готово».
 |
| Рисунок 15 |
После нажатия кнопки «Готово» останется только наблюдать за ходом создания кластера в окне Заданий VMM, как показано на рисунке ниже:
 |
| Рисунок 16 |
На этой стадии VMM начнёт создание кластера Hyper-V посредством выполнения нескольких заданий PowerShell в фоне. Ход выполнения всех заданий можно посмотреть в окне Заданий. Как можно увидеть на рисунке выше, VMM выполняет несколько заданий и показывает статус выполнения каждого задания в окне Заданий.
VMM устанавливает компонент Отказоустойчивой Кластеризации, если он не был установлен на каждом узле Hyper-V. Он проверяет, удовлетворяют ли все узлы необходимым требованиям, таким как требуемая операционная система и членство в домене. VMM маскирует и размаскировывает диск общего хранилища для каждого узла Hyper-V. Он также выполняет проверочные тесты, если это было выбрано и т. д.
3.7 Краткий итог части
Существует несколько требований, которые надо выполнить перед началом создания кластера Hyper-V посредством VMM. Некоторые из этих требований были рассмотрены в первых двух частях статьи. Третья часть была посвящена процессу создания кластера Hyper-V посредством VMM. Как только кластер Hyper-V создан, он управляется VMM. Главная цель создания кластера Hyper-V состоит в обеспечении высокой доступности виртуальных рабочих нагрузок. В заключительной части статьи рассмотрим, как сделать виртуальную машину высокодоступной в только что созданном кластере Hyper-V.
4.1 Введение
В первых трёх частях статьи было рассмотрено, как можно использовать диспетчер виртуальных машин для создания кластера Hyper-V. Поскольку главная цель создания кластера Hyper-V состоит в обеспечении высокой доступности виртуальных рабочих нагрузок, рассмотрим, как развернуть виртуальную машину в кластере Hyper-V посредством VMM и других способов. Перед тем, как рассказать о процессе создания высокодоступной виртуальной машины посредством VMM, важно удостовериться, что кластер Hyper-V сконфигурирован с подходящим хранилищем, виртуальной сетью и общими томами. Рассмотрим конфигурацию кластера Hyper-V.
Если перейти на страницу свойств кластера Hyper-V, то там обнаружите несколько вкладок, в которых имеется информация касательно кластера Hyper-V, которая поможет настроить доступное хранилище, общее хранилище файловое, общие тома кластера и виртуальные коммутаторы, как показано на рисунке ниже:
 |
| Рисунок 17 |
На странице Свойств кластера Hyper-V, можно найти следующие вкладки: Общие, Состояние, Доступное хранилище, Общее хранилище файловое, Общие тома, Виртуальные коммутаторы; а также другие настраиваемые свойства, заданные для кластера Hyper-V. Рассмотрим каждую вкладку свойств подробней.
Общие: Вкладка Общие содержит информацию, такую как имя кластера Hyper-V, местоположение группы узлов VMM, на которых создан кластера Hyper-V, описание кластера Hyper-V, резерв кластера, состояние резерва кластера, сведения о резерве кластера. Поле Описание позволяет ввести описание кластера Hyper-V. Поле Описание поможет определить роль кластера в производственной среде. Если имеется несколько кластеров Hyper-V в производственной среде, и каждый из них работает с различными типами рабочих нагрузок, то рекомендуется ввести описательный текст, который поможет идентифицировать роль кластера Hyper-V. Например, можно ввести «Кластер Hyper-V для Критически Важных Рабочих Нагрузок» или «Кластер Hyper-V для виртуальных машин для Тестирования и Разработки» и т. д.
Параметр Резерв Кластера (узлы) указывает число отказов узлов, которое должен выдерживать кластер, продолжая поддерживать работу всех виртуальных машин без каких-либо неполадок. Этот параметр имеет прямое влияние на функцию Интеллектуального Размещения VMM. Если кластер не может выдержать указанное число отказов узлов, не прерывая работы всех виртуальных машин, кластеру назначается «перегруженное» состояние. Если кластера Hyper-V перегружен, то узлы перегруженного кластера получают нулевую оценку во время размещения виртуальных машин, или, когда функция Интеллектуального Размещения проверяет подходящий узе для размещения виртуальной машины. Администратор может переопределить оценку и поместить виртуальную машину высокой доступности в перегруженный кластер вручную.
Состояние: При переключении на вкладку Состояние можно увидеть сведения о состоянии кластера Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 18 |
Вкладка Состояние показывает общее состояние кластера Hyper-V, включая состояние службы кластера на всех узлах кластера, состояние основных ресурсов кластера, таких как Имя кластера и IP-адрес кластера. Во вкладке Состояние VMM также показывает состояние тестов проверки кластера Hyper-V. Как видно на рисунке выше, VMM сообщает, что тест проверки кластера не был выполнен для кластера Hyper-V. Всегда имеется возможность создать кластер Hyper-V без запуска теста проверки кластера. Хотя кластер Hyper-V может работать без каких-либо неполадок и без выполнения теста проверки кластера, очень важно понимать, что команда службы поддержки продукта Microsoft не поддерживает кластер Hyper-V, если не был выполнен тест проверки кластера.
4.2 Можно ли выполнить Тест Проверки Кластера посредством VMM?
Да, можно выполнить тест проверки кластера посредством VMM, нажав правой кнопкой мышки на кластер Hyper-V. Для проверки кластера Hyper-V посредством VMM нажмите правой кнопкой мышки на кластер Hyper-V и затем нажмите на действие «Проверить Кластер», как показано на рисунке ниже:
 |
| Рисунок 19 |
При нажатии на «Проверить кластер» VMM создаст задание PowerShell для выполнения теста проверки кластера на всех узлах в кластере Hyper-V и затем покажет отчёт о выполнении, как показано на рисунке ниже:
 |
| Рисунок 20 |
Окно Заданий VMM всегда показывает результат выполнения задания. Как можно видеть, тест проверки кластера Hyper-V был завершён, но VMM сообщает в отчёте о предупреждении. Если нужно просмотреть к чему относится созданное предупреждение как часть теста проверки кластера, то следует открыть отчёт о проверке кластера, созданный на каком-либо узле, находящимся в папке WindowsClusterReports.
Как только тест Проверки Кластера был выполнен на кластере Hyper-V, заново откройте вкладку Состояние для просмотра состояния теста проверки кластера. Там будет гиперссылка, которая указывает на отчёт о проверке кластера, созданном на одном из узлов Hyper-V в кластере Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 21 |
Очень важно понимать, что необходимо устранить все предупреждения в отчёте о выполнении теста проверки кластера перед тем, как выпускать кластер Hyper-V в производственную среду или обращаться в службу поддержи продукта Microsoft для решения проблем с кластером Hyper-V. Вкладка Состояние также показывает состояние службы кластера на каждом узле кластера Hyper-V, как показано на рисунке выше.
4.3 Краткий итог части
В данной части были рассмотрены конфигурационные вкладки Общие и Состояние на странице Свойства кластера Hyper-V, а также доступная в них информация. Вкладка Общие отображает информацию, относящуюся к кластеру Hyper-V, такую как имя кластера Hyper-V, резерв кластера и описание кластера, которое можно задать для идентификации роли кластера Hyper-V. Вкладка Состояние предоставляет информацию об общем состоянии кластера Hyper-V, например, состоянии проверки кластера, состоянии службы кластера на всех узлах Hyper-V и состояние основных ресурсов кластера.
В следующей части статьи продолжим рассмотрение вкладок, доступных на странице Свойств кластер Hyper-V.
5.1 Введение
Как сказано в Части 4 данной статьи, как только кластер Hyper-V развёрнут, необходимо удостовериться, что кластер Hyper-V настроен верно, просмотрев данные на странице свойств кластера Hyper-V. В Части 4 были рассмотрены вкладки Общие и Состояние. Вкладка Общие содержит информацию о кластере Hyper-V, такую как имя кластера Hyper-V, число узлов резерва кластера и состояние резерва. Также во вкладке Общие можно ввести описание для идентификации роли кластера Hyper-V в производственной среде. Вкладка Состояние показывает общее состояние кластера Hyper-V, включая состояние службы кластера на всех узлах в кластере Hyper-V.
Доступное Хранилище: Вкладка Доступное Хранилище, как следует из названия, показывает диски общего хранилища, которые были добавлены для использования кластером Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 22 |
Как можно видеть, имеется четыре диска, добавленных в кластер Hyper-V из классификации хранилища VMM «Storage1». Также там показано свободное место и общая ёмкость каждого диска. Заметьте, что вкладка Доступное Хранилище также показывает имя ресурса кластера, которое было создано для каждого диска в кластере Hyper-V, как показано на рисунке выше, это крайняя правая колонка.
На вкладке Доступное Хранилище доступно три кнопки: «Добавить», «Удалить» и «Преобразовать в Общий Том Кластера (CSV)». Кнопка «Добавить» позволяет добавить дополнительные диски общего хранилища в кластер Hyper-V, кнопка «Удалить» позволяет удалить и изъять диски общего хранилища из кластера Hyper-V, кнопка «Преобразовать в Общий Том Кластера (CSV)» позволяет преобразовать диск общего хранилища в диск Общего Тома Кластера.
При нажатии на кнопку «Добавить» будет необходимо выбрать диск из доступного хранилища для его добавления в кластер Hyper-V. В случае отсутствия доступных дисков можно создать таковой, нажав на кнопку «Создать Логическое Устройство», как показано на рисунке ниже:
 |
| Рисунок 23 |
Как только логическое устройство создано, задайте ему имя, выберите тип таблицы разделов и отформатируйте диск, как показано на рисунке ниже:
 |
| Рисунок 24 |
После добавления диска в кластер Hyper-V, нажмите кнопку «OK». Нажатие кнопки «OK» даст инструкции VMM создать задание PowerShell, которое зарегистрирует диск в существующем кластере Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 25 |
Можно добавить сколько угодно много дисков в кластер Hyper-V посредством VMM. Добавить общее хранилище в кластер Hyper-V посредством VMM очень просто. VMM сам отформатирует и зарегистрирует диск в кластере Hyper-V, что в свою очередь помогает сократить требуемое время, если будете добавлять диск в кластер Hyper-V вручную.
Удалить диск из кластера Hyper-V также просто, но обратите внимание на действующие рабочие нагрузки, которые могут быть на диске, выбранном для изъятия. Важно понимать, что изъятие диска из работающего кластера Hyper-V может привести к простою служб Hyper-V.
Замечание: При удалении диска из работающего кластера Hyper-V, VMM просто удаляет регистрацию диска из кластера Hyper-V. Диск остаётся доступным для VMM для использования в других целях.
Кнопка «Преобразовать В Общий Том Кластера (CSV)» поможет преобразовать общее хранилище в Общий Том Кластера. Общий Том Кластера (CSV) необходим для Динамической Миграции Hyper-V. Преобразование диска в Общий Том Кластера (CSV) довольно простой процесс. Просто нажмите на диск, который надо преобразовать в Общий Том Кластера (CSV) и затем нажмите на кнопку «Преобразовать В Общий Том Кластера (CSV)». Как только диск преобразован он появится во вкладке Общие Тома, как показано на рисунке ниже:
 |
| Рисунок 26 |
VMM предоставляет поддержку и для блочных, и для файловых хранилищ. Блочное хранилище, такое как Fibre Channel, ISCSI и последовательный SCSI (SAS) и файловое хранилище, такое как общий файловый ресурс на основе SMB 3.0, созданный на сервере с ОС Windows Server 2012 или новее, поддерживаются в VMM в качестве общего хранилища кластера. Если нужно, чтобы общая папка SMB была доступна для кластера Hyper-V, перейдите на вкладку Общее Хранилище Файловое.
Общее Хранилище Файловое: Вкладка Общее Хранилище Файловое содержит список общего хранилища файлового, которое было добавлено в кластер Hyper-V. Если необходимо добавить новое общее хранилище файлов, нажмите кнопку «Добавить». Заметьте, что после нажатия на кнопку «Добавить», появиться запрос на ввод полного пути к общей папке SMB, как показано на рисунке ниже:
 |
| Рисунок 27 |
Как написано на странице «Добавить Общую Папку», VMM ожидает ввода корректного пути к общей папке SMB в формате UNC. Как только путь к общей папке SMB в формате UNC введён, нажмите кнопку OK, чтобы VMM сделал общую папку SMB доступной для кластера Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 28 |
После нажатия кнопки «OK» будет создано задание VMM, которое зарегистрирует общую папку SMB в кластере Hyper-V.
Кнопка «Починить» во вкладке Общего Хранилища Файлов позволяет починить любые проблемы с доступом к общей папке SMB. В случае если колонка «Состояние Доступа» для общей папки SMB не сообщает «OK», нажмите кнопку «Починить» для решения любых возможных проблем. Заметьте, что во вкладке Общего хранилища файлового необходимо убедиться, что была назначена учётная запись VMM для Выполнить От Имени, которая будет использована для выполнения корректирующих действии, в случае если общая папка SMB находится в состоянии предупреждения или есть какие-либо проблемы с общей папкой SMB.
Кнопка «Удалить», как понятно из названия, помогает удалить общую папку SMB из кластера Hyper-V. При нажатии на кнопки «Удалить» и «OK» VMM удалит регистрацию общей папки SMB из кластера Hyper-V. VMM не удаляет саму общую папку SMB.
5.2 Краткой итог части
В этой части описаны вкладки «Доступное Хранилище» и «Общее Хранилище Файлов» на странице свойств кластера Hyper-V и то, как можно использовать эти вкладки для добавления/удаления общего хранилища, преобразования хранилища в CSV и добавления общей папки SMB в кластер Hyper-V.
В следующей части статьи продолжим изучать другие конфигурационные вкладки, доступные на странице свойств кластера Hyper-V.
6.1 Введение
Общие Тома: Функция Динамической Миграции используется функцией Динамической Оптимизации VMM. Перед тем, как использовать функцию Динамической Миграции Hyper-V, необходимо добавить общие тома кластера в кластер Hyper-V. VMM позволяет добавлять хранилища, управляемые VMM, в кластер Hyper-V как Общие Тома Кластера. Вкладка Общие Тома содержит список всех общих томов кластера, которые был настроены в кластере Hyper-V, и также предоставляет возможность настроить и добавить дополнительное хранилище в качестве Общего Тома Кластера, в существующий кластер Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 29 |
Чтобы добавить Общий Том Кластера в кластер Hyper-V, нажмите кнопку «Добавить», как показано на рисунке выше, затем выберите доступное хранилище, которое необходимо добавить в кластер Hyper-V в качестве диска Общего Тома Кластера. Можно выбрать доступные диски или создать логическое устройство, как показано на рисунке ниже:
 |
| Рисунок 30 |
Если требуется удалить/отписать Общий Том Кластера из существующего кластера Hyper-V, нажмите кнопку «Удалить». Отметьте, что диск Общего Тома Кластера всегда может быть преобразован в доступное хранилище путём выбора диска Общего тома Кластера и последующего нажатия кнопки «Преобразовать в Доступное Хранилище».
Важно понимать, что VMM не предпримет никаких действий пока не нажата кнопка «OK» на странице свойств кластера Hyper-V. VMM обрабатывает изменения конфигурации путём создания заданий VMM, которые выполняются в фоне, пока используется консоль VMM. В случае внесения каких-либо изменений в конфигурацию кластера Hyper-V путём изменения параметров в конфигурационных вкладках, доступных на странице свойств кластера Hyper-V, кнопка «Просмотреть Скрипт» будет подсвечена (доступна для нажатия). При нажатии на кнопку «Просмотреть Скрипт», VMM покажет в блокноте скрипт PowerShell, который будет выполнен как задание VMM для внесения изменений в конфигурацию. Например, при добавлении диска из доступного хранилища в общий том кластера, VMM создаст скрипт PowerShell, который будет запущен при нажатии кнопки «OK». Как показано на рисунке ниже, скрипт PowerShell создан VMM для Disk9, который надо добавить в кластер Hyper-V. Как только кнопка «OK» нажата, VMM исполняет скрипт PowerShell для регистрации Disk9 в кластере Hyper-V.
 |
| Рисунок 31 |
Виртуальные Коммутаторы: Отметьте, что все узлы кластера в кластере Hyper-V должны иметь идентичную конфигурацию, включая и виртуальный коммутатор. Необходимо создать общие виртуальные коммутаторы на узлах Hyper-V для того, чтобы виртуальные машины, перемещённые на узел кластера по кластеру Hyper-V, могли быть назначены и присоединены к тому же виртуальному коммутатору. Вкладка Виртуальный Коммутатор показывает виртуальные коммутаторы, которые являются общими для всех узлов кластера, как показано на рисунке ниже:
 |
| Рисунок 32 |
Как видно на рисунке выше, был создан виртуальный коммутатор, названный «VMSwitch». Когда создался виртуальный коммутатор VMSwitch нажатием кнопки «Создать», VMM создал такой же виртуальный коммутатор на всех узлах кластера Hyper-V. Как видно на рисунке ниже, показывающем Диспетчеры Виртуальных Коммутаторов обоих серверов Hyper-V, Primary и Secondary, виртуальный коммутатор с именем «VMSwitch» был создан VMM на обоих, Primary и Secondary, серверах Hyper-V.
 |
| Рисунок 33 |
Это и в самом деле полезная вещь, которую делает VMM. VMM гарантирует, что все узлы Hyper-V в кластере Hyper-V созданы с коммутатором, имеющим общие имя и конфигурацию. Если необходимо добавить ещё один виртуальный коммутатор Hyper-V в кластер Hyper-V, нажмите кнопку «Создать» во вкладке Виртуальные Коммутаторы. При нажатии на кнопку «Создать», VMM запросит выбор логической сети VMM и имени виртуального коммутатора, который надо создать, как показано на рисунке ниже:
 |
| Рисунок 34 |
Отметьте, что VMM может не предоставить список логических сетей VMM для выбора, если не было создано логических сетей виртуальных машин в VMM или если логические сети не были назначены узлам Hyper-V, которые являются частью кластера Hyper-V. Если логическая сеть VMM была создана, убедитесь, что логическая сеть виртуальных машин назначена всем узлам Hyper-V, перейдя во вкладку Оборудование на странице свойств узла Hyper-V. Во вкладке Оборудование необходимо назначить Логическую Сеть Виртуальных Машин сетевым адаптерам Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 35 |
Настраиваемые Свойства: Последней конфигурационной вкладкой, доступной на странице свойств кластера Hyper-V, является Настраиваемые Свойства. Используя настраиваемые свойства можно контролировать размещение виртуальных машин. Например, можно проверить, на каких узлах Hyper-V должна работать каждая виртуальная машина.
6.2 Краткий итог части
В этой части было рассмотрены вкладки Общие Тома и Виртуальные Переключатели. Вкладка Общие Тома помогает настроить Общие Тома Кластера в кластере Hyper-V. Можно добавлять/удалять тома CSV, а затем развёртывать на них виртуальные машины. VMM также может помочь запустить кластер Hyper-V с идентичной конфигурацией виртуальных коммутаторов на узлах кластера Hyper-V. Для любого виртуального коммутатора, который определён на странице свойств кластера Hyper-V, VMM будет гарантировать, что имя виртуального коммутатора будет общим для всех узлов кластера Hyper-V.
В следующей части статьи рассмотрим, как сделать виртуальную машину высокодоступной в кластере Hyper-V посредством VMM и других способов.
7.1 Введение
В части 6 данной статьи были рассмотрены вкладки, доступные на странице свойств кластера Hyper-V, управляемого Диспетчером Виртуальных Машин (VMM). В этой и следующей частях данной статьи рассмотрим действия, доступные в контекстном меню при нажатии правой кнопкой мышки на кластер Hyper-V в VMM.
Как видно, создан кластер Hyper-V с названием HVCluster. HVCluster содержит два узла Hyper-V, названные Primary и Secondary. При нажатии правой кнопкой мышки на кластер Hyper-V, отобразится ряд действий в контекстном меню, как показано на рисунке ниже.
 |
| Рисунок 36 |
Эти действия помогают развернуть службы VMM, виртуальные машины, выполнить динамическую оптимизацию вручную, перемести кластер на другую группу узлов VMM, понизить уровень кластера, добавить узел в существующий кластер Hyper-V, проверить кластер, удалить кластер Hyper-V из VMM. Рассмотрим каждое из этих действия подробней.
«Создать Службу» и «Создать Виртуальную Машину»: Действия «Создать Службу» и «Создать Виртуальную Машину» используются для развёртывания службы или виртуальной машины в кластере Hyper-V. При нажатии на действие «Создать Службу», VMM откроет окно «Создать Службу», как показано на рисунке ниже.
 |
| Рисунок 37 |
Можно использовать существующей шаблон службы или создать новый шаблон службы, с помощью которого создать службу. При нажатии на кнопку «OK» VMM откроет Конструктор шаблонов служб, с помощью которого можно создать службу и затем развернуть её в кластере Hyper-V.
Нажатие на действие «Создание Виртуальной Машины» запустит мастер создания виртуальной машины, как показано на рисунке ниже.
 |
| Рисунок 38 |
Так как главная цель создания кластера Hyper-V — сделать виртуальные машины высокодоступными, необходимо понять, как развернуть виртуальную машину в кластере Hyper-V. Рассмотрим действия «Создать Виртуальную Машину» и «Создать Службу» детальней, когда будем рассматривать «как развернуть виртуальную машину или службу в кластере Hyper-V посредством VMM» в следующих частях данной статьи.
Обновить: Действие Обновить помогает отделить свойства кластера Hyper-V ото всех узлов кластера и затем отобразить обновлённую информацию о кластере узлов в консоли VMM. Отметьте, что VMM запускает командлет PowerShell «Read-SCVMHostCluster» как часть задания обновления VMM, как показано на рисунке ниже.
 |
| Рисунок 39 |
Также обновить кластер узлов можно, выполнив командлет Read-SCVMHostCluster вручную, как показано ниже:
- Get-SCVMHostCluster –Name “HVCluster.Test.Local” | Read-SCMHostCluster
Оптимизировать Узлы: VMM предлагает балансировку ресурсов узлов кластера с помощью функции Динамической Оптимизации. Функция динамической оптимизации помогает отбалансировать узлы кластера путём миграции виртуальных машин на узлы кластера в кластере Hyper-V, как только это необходимо. Параметры Динамической Оптимизации настраиваются на странице свойств группы узлов VMM. Как только параметры настроены, VMM вызывает функцию Динамической Оптимизации каждые 10 минут (интервал по умолчанию), собирает данные о текущем использовании ресурсов на всех узлах кластера узлов, сравнивает их с предельными значениями, настроенными во вкладке Динамической Оптимизации группы узлов VMM и затем автоматически выполняет динамическую миграцию виртуальных машин, если это необходимо.
Если необходимо выполнить Динамическую Оптимизацию кластера Hyper-V вручную, то нужно выбрать действие «Оптимизировать Узлы» в контекстном меню кластера узлов, нажав на него правой кнопкой мышки. Действие «Оптимизировать Узлы» делает тоже самое, что и функция Динамической Оптимизации автоматически, за исключением того, что в данном случае будет предложен список виртуальных машин, которые необходимо динамически мигрировать на другой узел в кластере узлов. Нажав на действие «Оптимизировать Узлы», VMM покажет окно Оптимизации Кластера Узлов, как показано на рисунке ниже:
 |
| Рисунок 40 |
VMM присоединится ко всем узлам кластера узлов, соберёт информацию о текущем использовании ресурсов на всех узлах, затем сравнит эти значения с предельными значениями, указанными во вкладке Динамической Оптимизации на странице свойств группы узлов VMM. В случае если VMM не видит необходимости в оптимизации кластера узлов, то появится следующее сообщение, как показано на рисунке ниже:
 |
| Рисунок 41 |
Переместить в Группу Узлов: Действие «Переместить в Группу Узлов» не предназначено для постоянного использования. Действие «Переместить в Группу Узлов» можно применить, если расположение кластера было изменено, или если кластер не соответствует текущему физическому расположению, для которого была настроена группа узлов VMM. Хотя перемещение кластера узлов в другую группу узлов VMM является лёгкой задачей, важно понимать, что кластер узлов и узлы унаследуют параметры, которые были настроены на целевой группе узлов VMM. Рекомендуется перед перемещением кластера узлов на другую группу узлов VMM, убедиться, что перемещаемый кластер узлов не унаследует параметры от целевой группы узлов VMM.
Исключить из Кластера: Если необходимо удалить отказоустойчивую кластеризацию со всех узлов кластера узлов, выберите действие «Исключить из Кластера» в консоли VMM, это поможет сэкономить уйму времени. Может потребоваться значительное количество времени, если планируется удаление компонента отказоустойчивой кластеризации со всех узлов с помощью Диспетчера Отказоустойчивости Кластеров.
При нажатии на действие «Исключить из Кластера», VMM покажет окно с предупреждением, как показано на рисунке ниже:
 |
| Рисунок 42 |
Нажатие на кнопку «Да» на вышеуказанном рисунке передаёт инструкцию VMM создать задание VMM, выполняемое в фоне, на удаление компонента отказоустойчивой кластеризации со всех узлов кластера узлов. Важно понимать, что VMM приступит к удалению компонента отказоустойчивой кластеризации со всех узлов кластера узлов Hyper-V после нажатия кнопки «Да». Поэтому перед тем как начать, убедитесь, что кластер узлов не размещает высокодоступные виртуальные машины или какие-либо кластеризованные сервисы или приложения.
7.2 Краткий итог части
В этой части рассмотрены некоторые полезные действия, доступные в контекстном меню правой кнопки мыши кластера Hyper-V, управляемого VMM.
В следующей части статьи продолжим изучать действия «Добавить Узел Кластера», «Проверка Кластера», «Представление Сети» и «Удалить».
8.1 Введение
Добавить Узел Кластера: Действие «Добавить Узел Кластера» помогает добавить узел в существующий кластер узлов. Всегда есть возможность добавить узел в существующий кластер Hyper-V с помощью оснастки Диспетчера Отказоустойчивости Кластеров или других методов, таких как командлеты Отказоустойчивости PowerShell. Добавление узла, управляемого VMM, в кластер Hyper-V посредством VMM — лёгкий процесс. Надо просто нажать правой кнопкой мышки на кластер Hyper-V и затем выбрать действие «Добавить Узел Кластера», как показано на рисунке ниже.
 |
| Рисунок 43 |
После нажатия на действие «Добавить Узел Кластера» надо выбрать узлы из списка доступных узлов, которые необходимо сделать частью кластера Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 44 |
Очень важно понимать, что узел, который будет добавлен в кластер узлов Hyper-V, должен находиться в той же группе узлов VMM. Если узел Hyper-V находится в другой группе, переместите узел в группу узлов VMM, в которой находится кластер Hyper-V. Выберите узлы кластера, которые надо добавить в существующий кластер Hyper-V, и затем нажмите кнопку «Добавить». При нажатии на кнопку «Добавить» появится окно «Добавить Узлы Кластера Узлов» с запросом выбора учётной записи, которая будет использована VMM для выполнения различных действия при добавлении узлов в действующий кластер Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 45 |
Затем VMM создаст задание VMM, которое в фоне добавит новый узел в кластер Hyper-V. Как показано на рисунке ниже, VMM выполняет множество задач автоматически. Задание VMM будет настроено на установку компонента отказоустойчивой кластеризации, проверку кластера, обновления состояния узла кластера в VMM и обновление кластера узлов для обновления информации о кластере.
 |
| Рисунок 46 |
Проверить Кластер: Запустить тест проверки кластера посредством VMM можно нажатием правой кнопкой мышки на кластер Hyper-V. Для проверки кластера Hyper-V посредством VMM, нажмите правой кнопкой мышки на кластер Hyper-V, затем выберите действие «Проверить Кластер», как показано на рисунке ниже:
 |
| Рисунок 47 |
При нажатии на действие «Проверить Кластер» VMM создаст задание PowerShell для запуска тестов проверки кластера для всех узлов в кластере Hyper-V и затем предоставит отчёт, как показано на рисунке ниже:
 |
| Рисунок 48 |
Окно Заданий VMM всегда показывает результат выполнения задания. Как видно, действие «Проверить Кластер» выполнено для кластера Hyper-V, но VMM сообщил о предупреждении. Если необходимо посмотреть, по какой причине предупреждение было создано как часть теста проверки кластера, то откройте отчёт о проверке кластера, созданный на каком-либо узле, в папке WindowsClusterReports.
Подсказка: Рекомендуется всегда запускать тест проверки кластера в следующих случаях:
- Когда узел добавляется или удаляется из кластера.
- Когда диск добавляется или удаляется из кластера.
- Когда кластер узлов перемещается на другую группу узлов VMM.
Представление Сети: Действие «Представление Сети» помогает понять, как настроена сеть для кластера узлов Hyper-V. При нажатии на действие «Представление Сети», VMM покажет окно Представления Сети, как показано на рисунке ниже:
 |
| Рисунок 49 |
В окне Представления Сети имеется три кнопки: «Сеть Виртуальных Машин», «Сеть Узлов», «Топология Сети». Кнопка «Сеть Узлов» покажет, как узлы в кластере узлов Hyper-V соединены и, используемые ими, логические сети VMM. Нажатие на кнопку «Топология Сети» покажет то, как сетевые компоненты ассоциированы с логической сетью VMM, как показано на рисунке ниже:
 |
| Рисунок 50 |
Нажатие на кнопку «Сеть Виртуальных машин» покажет виртуальные машины, работающие в кластере узлов Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 51 |
8.2 Краткий итог части
В этой и предыдущей частях рассмотрены действия, доступные в контекстном меню правой кнопки мышки кластера Hyper-V, управляемого Диспетчером Виртуальных Машин. В следующей части статьи изучим то, как удалить конкретный узел из кластера Hyper-V.
Поскольку главная цель создания кластера Hyper-V состоит в том, чтобы сделать виртуальные машины высокодоступными, также изучим, как развёртывать виртуальную машину или службу в кластере Hyper-V.
9.1 Введение
Поскольку главная цель создания кластера Hyper-V состоит в том, чтобы сделать виртуальные машины высокодоступными, рассмотрим развёртывание виртуальных машин в кластере Hyper-V. Несмотря на то что можно использовать оснастку Диспетчер Отказоустойчивости Кластеров или командлеты PowerShell, чтобы сделать виртуальные машины высокодоступными, довольно просто произвести развёртывание виртуальной машины в кластере Hyper-V посредством VMM.
Имеется кластер Hyper-V, названный HVCluster. HVCluster содержит два узла: Primary и Secondary. При нажатии правой кнопкой мышки на кластер Hyper-V можно увидеть набор различных действий, как показано на рисунке ниже:
 |
| Рисунок 52 |
Эти действия помогут развернуть службу, виртуальную машину, оптимизировать узлы виртуализации, переместить кластер в другую группу узлов VMM, понизить уровень кластера, добавить узел в существующий кластер Hyper-V, проверить кластер, полностью удалить кластер из VMM.
Действия «Создать Службу» и «Создать Виртуальную Машину» используются для развёртывания службы и виртуальной машины в кластере Hyper-V. При нажатии на действие «Создать Службу» VMM откроет Конструктор Служб, который поможет создать службу и затем развернуть её в кластере Hyper-V. Шаблон Службы содержит две или более виртуальных машин.
Процесс развёртывания виртуальной машины в кластере Hyper-V относительно прост. Рассмотрим необходимые шаги для развёртывания виртуальной машины в кластере Hyper-V посредством VMM.
При нажатии на действие «Создать Виртуальную Машину» появится окно Мастера Создания Виртуальной Машины, как показано на рисунке ниже:
 |
| Рисунок 53 |
Перед тем нажать кнопку «Далее» необходимо выбрать источник для виртуальной машины. Можно выбрать существующую виртуальную машину, шаблон виртуальной машины или виртуальный жёсткий диск в качестве источника, применив опцию «Использовать существующую виртуальную машину, Шаблон Виртуальной Машины или Виртуальный жёсткий диск». Если надо создать новую виртуальную машину, то выберите опцию «Создать новую виртуальную машину с виртуальным жёстким диском без данных».
Подсказка: В большинстве случаев администратор VMM создаст шаблон виртуальной машины, который будет использовать при развёртывании виртуальных машин. Шаблон виртуальной машины содержит такие параметры, как оборудование и настройки гостевой ОС. Рекомендуется создать шаблон виртуальной машины перед тем, как приступить к созданию виртуальной машины.
В следующем окне необходимо ввести имя виртуальной машины, её описание и версию виртуальной машины, как показано на рисунке ниже:
 |
| Рисунок 54 |
На странице «Удостоверение» необходимо выбрать версию виртуальной машины. Версия 1 — это устаревшая виртуальная машина и является единственной опцией для Windows Server 2012 и ранее на узлах Hyper-V. Если на узлах Hyper-V в кластере Hyper-V установлены Windows Server 2012 R2, выберите Версию 2. Версия 2 предлагает больше возможностей, таких как безопасная загрузка, перемещение файла подкачки операционной системы на виртуальный SCSI-диск, загрузка с SCSI-диска, PXE-загрузка с помощью стандартного сетевого адаптера и т. д.
Нажмите кнопку «Далее» для перехода на страницу «Настройки Оборудования» виртуальной машины, как показано на рисунке ниже:
 |
| Рисунок 55 |
Отметьте, что на странице «Настройки Оборудования» Мастер Создания Виртуальной Машины позволяет выбрать профиль оборудования, если таковой уже был создан. Крайне рекомендуется, создать шаблон виртуальной машины, профилей оборудования и гостевой ОС в панели Библиотека в консоли VMM перед тем, как приступить к созданию виртуальной машины. Это позволить сэкономить уйму времени при развёртываниях виртуальных машин.
Во вкладке «Настройки Оборудования» укажите количество оперативной памяти, виртуальный процессор и другие параметры, подходящие для виртуальной машины, затем прокрутите вниз до секции «Дополнительно». В секции «Дополнительно» выберите опцию «Сделать эту Виртуальную Машину высокодоступной», как показано на рисунке ниже:
 |
| Рисунок 56 |
Подсказка: Если необходимо сделать существующую виртуальную машину высокодоступной, выберите опцию «Сделать эту Виртуальную Машину высокодоступной» на странице свойств этой существующей виртуальной машины. Выбор вышеуказанной опции укажет Диспетчеру Виртуальных Машин сохранить выбранную виртуальную машину как источник кластера и сохранит файлы виртуальной машины на хранилище кластера.
Затем выберите назначение виртуальной машины. Можно выбрать одну из трёх опций: «Развернуть виртуальную машину в частном облаке», «Разместить виртуальную машину на узле» или «Сохранить виртуальную машину в библиотеке», как показано на рисунке ниже:
 |
| Рисунок 57 |
Поскольку развёртывается новая виртуальная машина в кластере Hyper-V, то выберите опцию «Разместить виртуальную машину на узле» и затем выберите группу узлов VMM, на которых располагается кластер Hyper-V. Нажмите кнопку «Далее». При нажатии на кнопку «Далее» VMM вызовет функцию размещения для расчёта рейтинга каждого узла Hyper-V и затем отобразит список доступных для развёртывания этой виртуальной машины узлов Hyper-V, как показано на рисунке ниже:
 |
| Рисунок 58 |
Здесь нужно выбрать узел Hyper-V, являющийся частью кластера Hyper-V, затем жать кнопку «Далее» пока не достигните вкладки «Сводка». На вкладке Сводки нажмите кнопку «Завершить», что позволить VMM создать задание VMM и затем начать развёртывание виртуальной машины в кластере Hyper-V.
9.2 Краткий итог части
В этой части рассмотрен процесс развёртывания виртуальной машины в кластере Hyper-V посредством VMM. Также было рассмотрено, как сделать существующую виртуальную машину высокодоступной, выбрав опцию «Сделать эту виртуальную машину высокодоступной».
В заключительной части статьи рассмотрим, как развертывать виртуальные машины в кластере Hyper-V с помощью Диспетчера Отказоустойчивости Кластеров и командлетов PowerShell.
10.1 Введение
В всех частях этой статьи рассматривается процесс успешного развёртывания кластера Hyper-V посредством Диспетчера Виртуальных Машин. В предыдущей части статьи был рассмотрен процесс развёртывания новой или существующей виртуальной машины в кластере Hyper-V посредством консоли VMM.
С помощью Диспетчера Отказоустойчивости Кластеров можно добавить виртуальную машину в качестве ресурса кластера. Можно добавить новую или существующую виртуальную машину в кластер Hyper-V. Рассмотрим шаги, необходимые для создания высокодоступной виртуальной машины посредством оснастки Диспетчера Отказоустойчивости Кластеров.
В Диспетчере Отказоустойчивости Кластеров нажмите правой кнопкой мышки на раздел «Роли» под отказоустойчивым кластером и выберите одну из двух опций: «Настроить Роль» или «Новая Виртуальная Машина» в опции «Виртуальные Машины», как показано на рисунке ниже:
 |
| Рисунок 59 |
Как видно на рисунке выше, нажав на действие «Новая Виртуальная Машина» Диспетчер Отказоустойчивости Кластеров позволяет развернуть новую виртуальную машину в кластере Hyper-V. Если необходимо добавить существующую виртуальную машину в кластер Hyper-V, выберите действие «Настроить Роль», которое рассмотрим немного позже.
При нажатии на действие «Новая Виртуальная машина» Диспетчер Отказоустойчивости Кластеров отобразит список узлов Hyper-V в кластере, как показано на рисунке ниже:
 |
| Рисунок 60 |
Перед тем, как продолжить, необходимо выбрать один из узлов Hyper-V. Выберите подходящий узел Hyper-V, на который будет развёрнута новая виртуальная машина и затем нажмите кнопку «OK» для перехода к странице «Мастер Создания Новой Виртуальной Машины», как показано на рисунке ниже:
 |
| Рисунок 61 |
Мастер Создания Новой Виртуальной Машины похож на то, в чём создаётся новая виртуальная машина посредством диспетчера Hyper-V. Hyper-V использует библиотеку VMCLUSEX.DLL, которая ответственна за предоставление интерфейсов для настройки и управления параметрами виртуальной машины посредством Диспетчера Отказоустойчивой Кластеризации. Hyper-V также использует собственную библиотеку ресурсов (HVCLUSRES.DLL) для обеспечения высокой доступности виртуальных машин в отказоустойчивом кластере. Ресурсная библиотека (VMCLUSRES.DLL) содержит необходимые инструкции для включения виртуальной машины, выключения и т. д.
Библиотеки VMCLUSRES.DLL и VMCLUSEX.DLL можно найти в папке WindowsSystem32, как показано на рисунке ниже:
 |
| Рисунок 62 |
Подсказка: Если интерфейс Мастера Создания Новой Виртуальной Машины не виден или имеются какие-либо проблемы с созданием виртуальной машины посредством Диспетчера Отказоустойчивой Виртуализации, попробуйте зарегистрировать библиотеки VMCLUSRES.DLL и VMCLUSEX.DLL, используя следующие команды:
- Regsvr32.exe VMCLUSRES.DLL
- Regsvr32.exe VMCLUSEX.DLL
Поскольку создание новой виртуальной машины относительно просто и возможно имеется опыт её создания с помощью Диспетчера Hyper-V, не будем подробно рассматривать все доступные страницы настроек в мастере Создания Новой Виртуальной Машины.
После настройки параметров виртуальной машины нажмите на кнопку «Готово» на странице «Сводки» для того, чтобы позволить отказоустойчивому кластеру развернуть новую виртуальную машину в качестве источника кластера в кластере Hyper-V. После нажатия кнопки «Готово» на странице «Сводки» отказоустойчивый кластер покажет сообщение о том, что новая виртуальная машина была успешно сконфигурирована в отказоустойчивом кластере, как показано на рисунке ниже:
 |
| Рисунок 63 |
Также можно подтвердить создание виртуальной машины в отказоустойчивом кластере, перейдя в раздел «Роли», как показано на рисунке ниже:
 |
| Рисунок 64 |
Хотя вышеописанные шаги можно использовать для развёртывания новой виртуальной машины в отказоустойчивом кластере, но, если надо добавить существующую виртуальную машину в отказоустойчивый кластер Hyper-V, нужно нажать правой кнопкой мышки на раздел «Роли», а затем выбрать «Настроить Роль», как показано на рисунке ниже:
 |
| Рисунок 65 |
На странице «Перед работой» нажмите кнопку «Далее» для отображения списка доступных ролей, как показано на рисунке ниже. В списке ролей выберите «Виртуальная Машина» в качестве роли и затем нажмите кнопку «Далее».
 |
| Рисунок 66 |
На следующей странице Мастер Высокой Доступности покажет список виртуальных машин со всех узлов Hyper-V, сконфигурированных в отказоустойчивом кластере. Необходимо выбрать виртуальные машины, которые нужно сделать высокодоступными, и затем нажать кнопку «Далее», как показано на рисунке ниже:
 |
| Рисунок 67 |
На этой стадии отказоустойчивый кластер готов к тому, чтобы сделать выбранные виртуальные машины высокодоступными. На странице «Подтверждение» нажмите кнопку «Далее» для того, чтобы позволить отказоустойчивому кластеру добавить выбранные виртуальные машины в отказоустойчивый кластер Hyper-V. Для проверки факта добавления существующих виртуальных машин в отказоустойчивый кластер, перейдите к разделу «Роли» и просмотрите список виртуальных машин, только что добавленных в отказоустойчивый кластер, как показано на рисунке ниже:
 |
| Рисунок 68 |
Вышеупомянутые шаги помогут вам с процессом развёртывания новых или существующих виртуальных машин в отказоустойчивом кластере Hyper-V с помощью Диспетчера Отказоустойчивой Кластеризации. Если необходимо добавить виртуальные машины в отказоустойчивый кластер Hyper-V, используя командную строку, примените командлет PowerShell отказоустойчивой кластеризации Add-ClusterVirtualMachineRole следующим образом:
- Add-ClusterVirtualMachineRole –VirtualMachine Gen2VM
Вышеупомянутая команда добавляет виртуальную машину Gen2VM в качестве ресурса кластера в отказоустойчивом кластере Hyper-V. Если нужно изменить предпочтительного владельца виртуальной машины, используйте командлет PowerShell Set-ClusterOwnerNode следующим образом:
- Set-ClusterOwnerNode –Group Gen2VM –Owner Secondary
10.2 Заключение
В данной статье был рассмотрен процесс создания высокодоступной виртуальной машины с помощью диспетчера отказоустойчивой кластеризации. Был также рассмотрен командлет PowerShell Add-ClusterVirtualMachineRole, который можно использовать для добавления виртуальных машин в отказоустойчивый кластер Hyper-V из командной строки.
Как видно, требуется выполнить достаточное количество действий для развёртывания кластера Hyper-V посредством Диспетчера Отказоустойчивой Кластеризации. Диспетчер Виртуальных Машин — прекрасный продукт, который позволяет администраторам VMM управлять узлами виртуализации Hyper-V, VMware и Xen более простым и надёжным способом.
Редакция Практики