Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4360 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / Articles / Как работает StarWind Vritual SAN Hybrid Cloud на базе Hyper-V и Azure.

Как работает StarWind Vritual SAN Hybrid Cloud на базе Hyper-V и Azure.

Как работает StarWind Vritual SAN Hybrid Cloud на базе Hyper-V и Azure.

Автор: Александр Самойленко
Дата: 21/11/2017

Многим из вас известны решения компании 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 и определяем следующие переменные:

  • $vmName = 'sw-sed-azure-01'
  • $vnetName = 'AzureVNet1'
  • $RG = 'AzureRG'
  • $subnetName = 'default'
  • $nicName = 'sw-sed-azure-01011'
  • $location = 'East US'
  • $ipAddress = '10.10.0.10'

Создаем объект для Get-AzureRmVM:

$VM = Get-AzureRmVM -Name $vmName -ResourceGroupName $RG

Теперь создаем объект для виртуальной сети через командлет Get-AzureRmVirtualNetwork:

$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $RG

Новый NIC должен быть присоединен к сети, но сначала надо получить subnet ID:

$subnetID = (Get-AzureRmVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $vnet).Id

Теперь можно создать адаптер через командлет New-AzureRmNetworkInterface:

New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $RG -Location $location -SubnetId $subnetID -PrivateIpAddress $ipAddress

Сетевой адаптер создан, и его можно подключить к ВМ. Сначала создадим объект NIC:

$NIC = Get-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $RG

Добавим NIC к конфигурации ВМ:

$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $NIC.Id

Чтобы проверить, что конфигурация ВМ изменилась и содержит новый 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 готова к эксплуатации.

Реклама



Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

Быстрый переход:
IT-Grad VMware Cisco StarWind Veeam vGate Microsoft Cloud SDRS Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn Security Code 1cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vCloud Tools vCSA vSAN Horizon Networking esxtop VVols HA Backup Book Photon VMworld vROPs Labs Fusion Cloud Computing SSD Client DRS OpenStack Comparison Workstation Blast SRM App Volumes Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK VTL Update iSCSI SDDC NSX Agent Virtual Appliance Whitepaper PowerShell Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Converter XenApp Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Director Migration Diagram Bug Troubleshooting Air API CLI Plugin DPM Memory Upgrade SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.