Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер 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){
    Install-WindowsFeature –Computername $server –Name $ServerRoles} 

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

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

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 и проверим что у нас получилось.



Включаем (S2D)

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, читающие Хабр, это прокомментируют.

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

Комментарии (17)


  1. Arxitektor
    24.04.2018 19:28

    Спасибо. Пусть будет в закладках. Если функционал оставят.
    А есть ли еще решения для организации такого кластера из 2 серверов с отказоустойчивым хранилищем?


    1. Daysleeper Автор
      24.04.2018 19:41

      Я думаю, функционал вернут. Возможно с выходом 2019 сервера. Нужно понимать, что Microsoft эту технологию делает для себя и под Azure, что бы на хранилищах и на администрировании экономить.
      По поводу других решений, вряд ли подскажу. Самому интересно. Вроде бы у Nutanix, что-то подобное есть.


      1. navion
        26.04.2018 23:25

        У Nutanix минимум 3 ноды и лучше сразу использовать их гипервизор.


    1. SyavaSyava
      25.04.2018 09:51

      У StarWind есть распределённое хранилище с риал-тайм зеркалированием между нодами.
      И даже бесплатно, и даже можно на бесплатный Hyper-V Server вкорячить )))
      Да есть ряд ограничений, но для бюджетного кластера на пару нод – очень хорошо.
      Особенно если сравнивать с парой лицензий Windows Server Datacenter, убедить купить которые небольшой бизнес невозможно очень трудно.
      Разворачивал так же в тестовой виртуальной среде – при выдёргивании одной ноды отрабатывает вроде нормально, тайм-аут в дисковых операциях около 3-5 секунд ±.


  1. red5
    24.04.2018 19:37

    как относитесь к размещению виртуальных контроллеров домена на самих нодах?

    При правильной настройке DNS и NTP ничего страшного нет. Одна нода — один DC, полет нормальный, вопрос к цене лицензий.


  1. Daysleeper Автор
    24.04.2018 19:50

    Спасибо за ответ. Я тоже думаю, что такое решение — жизнеспособное. По поводу лицензий, согласен что дорого. С другой стороны, когда надежность и отказоустойчивость были дешёвыми?


  1. pvs043
    24.04.2018 19:57

    О-о, сам осваиваю эту тему. Респект за статью!

    Отмечу:

    новость о том, что функцию (S2D) уберут из следующей сборки server 2016

    представлена не совсем верно. S2D убирают в новой ветке Windows Server (1709/1803/...) и всячески рекомендуют использовать для этих целей полный Windows 2019+GUI (ссылку лень сейчас искать, но она есть).

    Новейшая ветка Windows Server (без указания версии, в цикле быстрой разработки) позиционируется для развёртывания в облаке — NO-GUI/Containers/Nano. Версия для локальных датацентров (2019) выйдет с полным функционалом 2016 и усовершенствованиями.

    Тестовую лабу с вложенной виртуализацией (4 VM+Hyper-V) собирал — работает.
    Полу-продакшн из 2-х железных серверов в конфигурации HP ProLiant G5(!) / 300x6 HDD / 1 Gbit Net тоже шевелится :) Правда, пришлось поднять на каждом сервере виртуалки Hyper-V — внутренний RAID не отключить, а S2D это не нравится.

    Сейчас появилась возможность возвести полноценный кластер Hyper-V/S2D на 8 серверах: 24 CPU / 512 Gb RAM / 10 Gbit Net / 24x3 Tb HDD).


    1. pvs043
      24.04.2018 21:39

      Windows Server Semi-Annual Channel update

      Q: Will HCI and SDDC features be available in the Semi-Annual Channel release?
      A: The Semi-Annual Channel releases will focus on modern application platform and other innovation scenarios such as containers and micro-services. While some infrastructure roles, such as Hyper-V, may be available, the full range of HCI and SDDC scenarios will be the focus of the LTSC channel and not the Semi-Annual Channel. Windows Server 2016, the latest LTSC release, is the recommended version today for Storage Spaces Direct and HCI scenarios.


      1. Daysleeper Автор
        24.04.2018 22:27

        спасибо за ссылку


        1. vvmtutby
          25.04.2018 14:31

          [Обсуждение] Windows Server version 1709 ( 2 комплекта RSAT, S2D)
          Про S2D в 1709 Denis Dyagilev 19 декабря 2017 сообщил следующее:

          VVM>> Кстати, из «Windows Server, version 1709» убрали S2D
          VVM>> ( а через пару недель S2D вернулся в insider сборки )
          Обновлённый до 1709 кластер прекрасно работает с S2D.
          Windows Server 1709/1803/1809/1903/etc ( принадлежность к каналу SAC)
          пока один релиз, где S2D нельзя развернуть с нуля. В 1803 эта возможность будет
          P.S. Информация достаточно редкая ( и не очевидная).


    1. roschacker
      25.04.2018 13:47

      Nano — всё!

      Starting in Windows Server, version 1709, Nano Server will be available only as a container base OS image. Check out Changes to Nano Server to learn what this means.


      Важно!
      Начиная с Windows Server версии 1709, сервер Nano Server будет доступен только в качестве базового образа ОС контейнера. Ознакомьтесь с разделом Изменения сервера Nano Server, чтобы узнать, что это означает.


  1. vesper-bot
    25.04.2018 09:05

    готовы ли вы рассматривать переход на гиперконвергентные решения в будущем?

    Грубо говоря, уже сидим. Но на предыдущем поколении — две ноды HyperV с репликацией ВМ между ними.


    как относитесь к размещению виртуальных контроллеров домена на самих нодах?

    Нормально, если их не один в локальном сайте, или если есть хотя бы один контроллер off-site.


  1. scruff
    25.04.2018 12:34

    К сожалению пока не работал с fail-over кластерами на Hyper-V. В ходе управления standanolne Hyper-V наткулся на опцию «enable replica». Я так понял — она позволяет делать реплики гостевых машин между двумя Hyper-V серверами, но только в выключеном состоянии, т.е. если падает один Hyper-V сервак, то со второго можно стартануть реплику гостевой машины. Минус — простой сервисом пока гостевая машина поднимается на втором Hyper-V. Поправьте меня, если не прав.


    1. vesper-bot
      25.04.2018 13:17

      Да, именно так. При этом ещё нужно разобрать репликацию, если второй сервер не поднять, и обратить, если сервер удалось завести, так как иначе изменения на ВМ, запущенной из реплики, не будут отражены на сервере, который был для неё «мастером». Репликация VHD идет с определенной периодичностью, т.о. при поднятии реплики последние несколько минут записей на диск будут потеряны.


  1. scruff
    25.04.2018 13:56

    Может кто-нибудь знает — имеется ли подобный функционал для Linux, например в KVM?


    1. larrabee
      25.04.2018 18:53

      Имеется, например такое можно организовать с помощь Ceph или кластерных ФС (например Gluster). Но рекомендую все таки смотреть в сторону Ceph.


    1. DaemonGloom
      26.04.2018 06:58

      Помимо предложенного Ceph могу ещё назвать drbd. Он проще гораздо. И восстановлению поддаётся без особых проблем.