Хабрахабр

[Из песочницы] Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке

Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер hyper-v. Однако времена были давние, еще до выхода 2012 сервера. Для организации кластера требуется внешнее хранилище и сделать отказоустойчивость из двух серверов было в принципе невозможно.

Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.
Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Причем выход одного из дисков или целого сервера не должны привести к потере данных. Некий единый рейд из дисков, которые находятся на разных серверах.

Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Звучит заманчиво и мне было интересно узнать, как это работает. Благо и вложенная виртуализация в hyper-v недавно появилась.

На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. Для своих экспериментов я создал 3 виртуальные машины. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.

Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Работа с дисками через RAID контроллеры не поддерживается. Поддерживаются NVMe, SATA, SAS. Более подробно о требованиях docs.microsoft.com

Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Подробнее по ссылке.

Затем необходимо включить поддержку вложенной виртуализации: Поэтому я создал две виртуальные машины – node1, node2 и сразу отключил динамическую память.

Set-VMProcessor -VMName node1,node2 -ExposeVirtualizationExtensions $true

Включаем поддержку спуфинга на сетевых адаптерах ВМ:

Get-VMNetworkAdapter -VMName node1,node2 | Set-VMNetworkAdapter -MacAddressSpoofing On


HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.

Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера. Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена.

С помощью консольной утилиты sconfig это не составит большого труда. Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. Уточню только, что установил Windows Admin Center с помощью скрипта:

msiexec /i "C:\WindowsAdminCenter1804.msi" /qn /L*v log.txt SME_PORT=6515 SSL_CERTIFICATE_OPTION=generate

По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.

Когда подготовительная часть готова и перед тем, как приступать к созданию кластера, рекомендую обновить ноды, поскольку без апрельских обновлений Windows Admin Center не сможет управлять кластером.

Напомню, что все необходимые консоли у меня установлены на контролере домена. Приступим к созданию кластера. Затем устанавливаю на ноды необходимые роли для построения кластера с помощью скрипта: Поэтому я подключаюсь к домену и запускаю Powershell ISE под администратором.

$Servers = "node1","node2"
$ServerRoles = "Data-Center-Bridging","Failover-Clustering","Hyper-V","RSAT-Clustering-PowerShell","Hyper-V-PowerShell","FS-FileServer" foreach ($server in $servers)

И перегружаю сервера после установки.

Запускаем тест для проверки готовности нод:

Test-Cluster –Node "node1","node2" –Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration

Отчёт в фомате html сформировался в папке C:\Users\Administrator\AppData\Local\Temp. Путь к отчету утилита пишет, только если есть ошибки.

168. Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192. 100 1.

New-Cluster –Name hpvcl –Node "node1","node2" –NoStorage -StaticAddress 192.168.1.100

После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.

Включаем (S2D)

Enable-ClusterStorageSpacesDirect –CimSession hpvcl

И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.

Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB. Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том.

New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 74GB -ResiliencySettingName Mirror

Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище. На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.
Кластер с общим диском готов.

Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager. Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем.

Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center.

Подключимся к одной из нод и выполним скрипт:

Add-ClusterResourceType -Name "SDDC Management" -dll "$env:SystemRoot\Cluster\sddcres.dll" -DisplayName "SDDC Management"

Проверяем Admin Center и на этот раз получаем красивые графики

Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.

В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Тут стоит вернуться к аппаратным требованиям. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.

Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют. Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 .

Знакомство с новыми технологиями это был для меня весьма интересный опыт. В заключении хотел бы сказать несколько слов о своих впечатлениях. Я не уверен, что смогу применить эти навыки на практике. Назвать его полезным, пока не могу. как относитесь к размещению виртуальных контроллеров домена на самих нодах? Поэтому у меня вопросы к сообществу: готовы ли вы рассматривать переход на гиперконвергентные решения в будущем?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть