Многим из вас известны решения компании StarWind и, в частности, ее флагманский продукт для создания отказоустойчивых хранилищ StarWind Vritual SAN. С помощью этого решения можно не только организовать программные хранилища на базе серверов Hyper-V, но и расширить кластеры StarWind в облако публичного сервис-провайдера, например, Microsoft Azure. Это позволяет получить множество преимуществ от использования гибридной инфраструктуры хранилищ.
Многие давно знают о преимуществах гибридных облаков - это бОльшая гибкость, свобода в подключении/отключении ресурсов по мере возрастания/спада нагрузки, а главное - катастрофоустойчивость на уровне географически разделенных площадок. StarWind и Hyper-V реализуют эту концепцию для Microsoft Azure для серверов и хранилищ для виртуальных машин.
Давайте рассмотрим подробно, как это делается. Гибридная архитектура решения StarWind Virtual SAN выглядит следующим образом:
Для создания кластера из локального и удаленного узлов StarWind Virtual SAN и их хранилищ, на стороне Azure поднимается виртуальная машина StarWind VM с ролью Hyper-V, на которой работают вложенные виртуальные машины, образующие единое пространство с рабочими нагрузками на стороне частной инфраструктуры.
В локальной инфраструктуре нужно использовать физический сервер с развернутым на нем ПО StarWind. Эти два сервера (локальный физический и облачная ВМ StarWind) объединяются в кластер отказоустойчивости Failover Cluster, а их хранилища - в тома Cluster Shared Volumes.
С точки зрения сетевого взаимодействия, коммуникации происходят серез VPN-туннель, организованный через VPN Device на стороне онпремизной инфраструктуры и Virtual Network Gateway на стороне публичного облака Azure.
Таким образом достигается возможность миграции виртуальных машин на хранилищах StarWind между площадками, а также возможность восстановления машины в облаке в случае отказа основного сервера StarWind.
Перед началом построения такого решения вам понадобится следующее:
Подписка Azure Subscription (можно бесплатно получить триал тут).
Выбрать датацентр Azure на площадке, для которой с вашим датацентром обеспечивается наименьшая Latency (задержка). Проверить ее можно здесь.
Нужно выбрать датацентр Azure, который поддерживает вложенную виртуализацию, то есть запуск виртуальных машин в виртуальной машине (см. нашу статью тут и тут).
Публичный IP-адрес для организации VPN-сети.
100-мегабитное соединение в интернет (рекомендуется 1 Гбит).
Инфраструктура Active Directory и DNS на вашей онпремизной площадке.
Windows Server 2016, установленный на сервере, который предполагается кластеризовать.
В качестве данных для примера ниже будут использованы следующие параметры:
Virtual Network Name: AzureVNet1
Azure Address Space: 10.10.0.0/25
Azure Subnet: 10.10.0.0/26
Azure GatewaySubnet: 10.10.0.128/27
Resource Group: AzureRG
Location: East US
DNS Server: опционально (ваш DNS-сервер)
Virtual Network Gateway Name: AzureVNet1GW
Public IP: AzureVNet1GW-IP
VPN Type: Route-based
Connection Type: Site-to-site (IPsec)
Gateway Type: VPN
Local Network Gateway Name: On-Premise
Connection Name: AzureVNet1toOnPremise
Процесс по шагам выглядит следующим образом:
Создаем Site-to-Site соединение.
Создаем виртуальную сеть.
Идем в Azure Portal, создаем новую группу ресурсов (Resource group):
Далее создаем виртуальную сеть, выбрав созданную группу ресурсов:
Создаем шлюз VPN со стороны Azure.
Создадим подсеть для шлюза (Gateway subnet):
Создадим шлюз VPN (Virtual network gateway), указав нашу виртуальную сеть и тип VPN Route-based. Он будет обслуживать гибридное облако со стороны Azure:
Также нужно будет создать публичный IP-адрес для шлюза на вкладке Public IP address:
Создаем шлюз локальной сети (Local Network Gateway).
Создадим Local Network Gateway, который будет относиться к онпремизной сети. В качестве IP-адреса указываем устройство VPN на стороне вашей площадки, которое будет соединяться со шлюзом Azure:
Добавляем VPN-соединение между площадками.
Для этого на вкладке Connections нажимаем +Add:
Настраиваем RRAS-сервер: добавляем роли и фичи.
Чтобы создать VPN-туннель между облаком Azure и вашей площадкой, надо поднять Routing and Remote Access Service (RRAS) как роль Windows Server 2016.
Запускаем на сервере Server Manager и добавляем роль RRAS. На вкладке Features добавляем следующие фичи:
Server Roles: Remote Access
Role Services: Direct Access and VPN (RAS)
Add Features: Routing
Web Server Role (IIS): Role Services
Настраиваем RRAS-соединение на стороне частной инфраструктуры.
Откройте Routing and Remote Access (в данном случае используется сервер, у которого есть еще роли AD и DNS), выберите "Secure connection between two private networks" и завершите мастер с дефолтными настройками:
Пройдите мастер Demand-Dial Interface Wizard, задав имя интерфейса и выбрав тип "VPN":
Далее нужно создать статический маршрут (static route). Вбиваем данные маршрута нашей подсети Azure-VMs:
После завершения мастера идем в Routing and Remote Access > Network Interfaces, нажимаем правой кнопкой "On-Premise-To-Azure" и нажимаем Properties. Идем на вкладку Options и выставляем тип соединения в persistent. На вкладке Security выставляем pre-shared key, который мы настроили в Azure ранее.
Теперь выбираем соединение On-Premise-To-Azure и нажимаем для него пункт Connect. После этого оно должно отображаться в статусе Connected:
На стороне облака Azure соединение также должно показываться как Connected:
Проверьте еще раз статические маршруты на RRAS, маршрут должен выглядеть так:
Настройка фаервола
Теперь надо открыть вкладку Exceptions, затем нажмите Add Port, нажмите Inbound Rules и откройте мастер "New Rule…". Разрешите соединения по портам 500, 4500, 1701, 50.
Подготовка онпремизного сервера
Далее мы считаем, что на онпремизном сервере виртуализации настроены фичи Failover Clustering and Multipath I/O, а также, само собой, роль Hyper-V.
Далее надо скачать последнюю версию StarWind Virtual SAN по этой ссылке.
Включение доступа по нескольким путям
Идем в MPIO manager: Start->Administrative Tools->MPIO, далее на вкладку Discover Multi-Paths и там ставим чекбокс Add support for iSCSI, после чего жмем Add.
Развертываем виртуальную машину StarWind в облаке Azure
Идем в Azure portal и находим поиском машину StarWind Virtual SAN как продукт. Выбираем тип "Bring your own license" (BYOL), если у вас есть уже лицензия StarWind. Это прединсталлированная машина с ролями Hyper-V, MPIO и Failover Cluster. Надо учитывать, что StarWind также может оплачиваться на почасовой основе (Hourly).
Машину создаем через Resource Manager:
Выбираем локейшен датацентра, где будет размещаться ВМ и размер инстанса (помним, что нужен интсанс с поддержкой вложенной виртуализации - это только Dv3 или Ev3):
Настраиваем возможности машины:
Нажмите Network security group и добавьте UPN-порты 500, 4500, 1701, 50 как inbound и outbound rule, чтобы позволить ходить трафику VPN. Выставьте опцию High availability в None.
Добавление сетевого адаптера
Его можно добавить только через PowerShell. Логинимся через командлет Login-AzureRmAccount и определяем следующие переменные:
Чтобы проверить, что конфигурация ВМ изменилась и содержит новый NIC, выполните команду:
$VM.NetworkProfile.NetworkInterfaces Assign the first NIC as the primary: $VM.NetworkProfile.NetworkInterfaces.Item(0).Primary = $true
Ну и надо закоммитить конфигурацию:
Update-AzureRmVM -VM $VM -ResourceGroupName $RG
Настройка IP Forwarding
В Azure portal идем в VM -> Networking. Выбираем сетевой интерфейс и открываем IP configuration, где включаем IP forwarding.
Создание хранилища для ВМ
Azure требует создание Storage Account для хранения дисков ВМ.
Идем в New -> Storage -> Storage account.
Вводим имя и deployment model (выбираем Resource Manager).
Storage account: General purpose.
Performance tier: Standard или Premium.
Выбираем опции replication, subscription, region.
Нажимаем Create.
Идем в StarWind VM -> Disks. Нажимаем +Add data disk, указываем тип аккаунта в соответствии с конфигурацией хранилища.
Устанавливаем роли и фичи
Проверяем, что есть роль Hyper-V и нужные фичи:
Присоединяем к домену
Присоединяем машину StarWind к домену нашей организации:
Организация Failover Cluster
Создание общего хранилища
Открываем StarWind Management Console на стороне частной инфраструктуры (сервер StarWind там уже добавлен):
Далее появится диалог запроса создания нового пула хранения:
Нажимаем Yes и создаем новый виртуальный диск, где будут храниться виртуальные машины:
Указываем параметры устройства. Лучше выбрать "толстый" (thick) диск:
Опционально можно настроить политику кэширования:
После создания устройства надо добавить облачный сервер в консоли StarWind. Нажимаем Add Server и добавляем нашу ВМ на Azure:
Кликните правой кнопкой на устройстве (диске), которое вы только что создали, и запустите Replication Manager, в появившемся окне нажмите Add Replica:
Выберите тип репликации Synchronous two-way replication, после чего нужно будет указать партнерский узел - это виртуальная машина на стороне Azure:
Указываем тип стратегии репликации - Heartbeat:
Выбираем Create new Partner Device:
После указания каналов синхронизации и хартбитов (сигналов доступности) можно задать настройки ALUA, нажав Change ALUA Settings. И обязательно нажмем Change Network Settings:
Укажите, какие сетевые интерфейсы относятся к каналам синхронизации и сети хартбитов. Затем вас спросят о способе инициализации партнерского узла, выберите Do not Synchronize (так как данных у вас пока нет).
После этого реплицируемый девайс появится в консоли StarWind:
При необходимости добавьте новые диски, повторив шаги, приведенные выше.
Обнаружение iSCSI Target Portals
Запускаем Microsoft iSCSI Initiator: Start > Administrative Tools > iSCSI Initiator или выполняем команду iscsicpl. Появятся iSCSI Initiator Properties, идем на вкладку Dicscovery:
Нажимаем Discover Portal и в появившемся диалоге вбиваем адрес 127.0.0.1. Далее нажимаем кнопку Advanced.
Выбираем Microsoft ISCSI Initiator в качестве локального адаптера и задаем IP инициатора (оставляйте дефолтное 127.0.0.1).
Далее снова идем в Discover Portal и вбиваем адрес узла на стороне Azure:
Жмем Advanced и указываем настройки онпремизного сервера:
Таким же образом нужно проделать операции и на втором узле - виртуальной машине StarWind в облаке Azure:
Соединение таргетов
Теперь переходим на вкладку Targets (если таргетов там нет, то надо проверить фаерол и список сетей в разделе StarWind Management Console -> Configuration -> Network):
Выбираем таргет компонента Witness, который размещен на локальном (онпремизном) сервере и нажимаем Advanced:
В поле локального адаптера выставляем Microsoft iSCSI Initiator, а в Target portal IP - значение 127.0.0.1:
2 раза нажимаем Ok. Внимание: не соединяйте таргет локального партнер-узла для устройства Witness со стороны облачного узла StarWind.
Выбираем второй локальный таргет (уже не Witness) и нажимаем Connect. Далее жмем кнопку Advanced:
В поле локального адаптера выставляем Microsoft iSCSI Initiator, а в Target portal IP - значение 127.0.0.1:
Теперь идем на облачную ноду StarWind, там выбираем облачный узел и нажимаем Connect:
В поле локального адаптера выставляем Microsoft iSCSI Initiator, а в Target portal IP - облачную подсеть, а в поле Initiator IP - соответствующий адрес для канала iSCSI.
Повторите действие со вторым таргетом на стороне машины в облаке Azure.
В итоге на стороне онпремизной инфраструктуры картина будет выглядеть так:
А на стороне облачной ВМ вот так:
Настройка доступа по нескольким путям (Multipathing)
На стороне локального сервера нажимаем кнопку Devices для конфигурации политики MPIO:
Кликаем MPIO:
Выбираем политику балансировки Fail Over Only, и мы должны увидеть, что локальный путь помечен как активный:
Удостовериться в этом можно, нажав кнопку Details для выбранного пути:
Повторите эти действия на облачном узле.
Далее нужно инициализировать диски и создать разделы через оснастку Computer Management. Необходимо, чтобы эти дисковые устройства были видны на обоих узлах, чтобы создать кластер. Рекомендуется разметить диски как GPT.
Создание кластера отказоустойчивости Failover Cluster
В Server Manager выберите Failover Cluster Manager из меню Tools. Кликните Create Cluster в меню Actions и укажите серверы, которые мы добавляем в кластер:
Валидируем конфигурацию кластера:
Вводим имя кластера и указываем две подсети - локальную и облачную на стороне Azure:
После создания кластера посмотрим на детальную информацию о нем:
Добавление Cluster Shared Volumes (CSV)
Открываем Failover Cluster Manager и идем в Cluster->Storage -> Disks. Нажимаем Add Disk на панели Actions panel, выбираем диски StarWind из списка и нажимаем OK. Для конфигурации диска Witness кликните Cluster->More Actions->Configure Cluster Quorum Settings и пройдите мастер с дефолтной конфигурацией:
Чтобы избежать ненужных накладных расходов CSV, настройте каждый том так, чтобы им владел один узел кластера. Этот же узел должен быть и preferred owner для виртуальных машин, исполняемых на этом узле.
Выберите диск и нажмите Add to Cluster Shared Volumes:
После того, как вы добавите все диски в CSV, можно переходить к проверке связей имен серверов. Для двух настроенных подсетей тип связи должен быть OR:
Тестирование восстановления после отказа (Failover)
Создайте новую виртуальную машину, а в качестве места ее хранения - том CSV:
Далее откройте настройки ВМ и отметьте галку поддержки миграции между процессорами различных версий (у вас внутри и в облаке Azure - разные процессоры):
Установите в машине гостевую ОС и запустите горячую миграцию Live Migration на облачный узел StarWind VM:
Раз миграция отработала, сработает и Failover, проверить это вы сможете самостоятельно.
Таким образом, вы все корректно настроили и конфигурация гибридной среды StarWind Virtual SAN готова к эксплуатации.