Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке
Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер hyper-v. Однако времена были давние, еще до выхода 2012 сервера. Для организации кластера требуется внешнее хранилище и сделать отказоустойчивость из двух серверов было в принципе невозможно.
Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.
Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.
Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.
Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.
Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Поддерживаются NVMe, SATA, SAS. Работа с дисками через RAID контроллеры не поддерживается. Более подробно о требованиях 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 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.
Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.
Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты 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. Путь к отчету утилита пишет, только если есть ошибки.
Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100
New-Cluster –Name hpvcl –Node "node1","node2" –NoStorage -StaticAddress 192.168.1.100 После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.
Enable-ClusterStorageSpacesDirect –CimSession hpvcl И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.
Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том. Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB.
New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 74GB -ResiliencySettingName Mirror 
На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.
Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.
Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster 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 делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.
Вторая и основная ложка дёгтя, это новость о том, что функцию (S2D) уберут из следующей сборки server 2016 . Надеюсь, сотрудники Microsoft, читающие Хабр, это прокомментируют.
В заключении хотел бы сказать несколько слов о своих впечатлениях. Знакомство с новыми технологиями это был для меня весьма интересный опыт. Назвать его полезным, пока не могу. Я не уверен, что смогу применить эти навыки на практике. Поэтому у меня вопросы к сообществу: готовы ли вы рассматривать переход на гиперконвергентные решения в будущем? как относитесь к размещению виртуальных контроллеров домена на самих нодах?