Предисловие. Эта публикация — продолжение темы создания отказоустойчивого кластера Windows Server в облаке Microsoft Azure. На этот раз разговор пойдёт про сеть.
Привет, фанаты кластеров. В своей предыдущей статье я рассказал о том, как обойти ограничения среды Microsoft Azure IaaS при подготовке хранилища данных для отказоустойчивого кластера Microsoft Windows. Давайте теперь поговорим о другой важной части создания кластера — сети.
Перед тем как начать, давайте перечислим несколько базовых понятий относящихся к сетям в Azure. Вот термины, которые нам потребуются для статьи о создании кластера:
VIP (Virtual IP address): Публичный IP адрес облачной службы. Он также используется балансировщиком нагрузки Azure, который распределяет трафик до его направления на виртуальную машину.
DIP (Dynamic IP address): Внутренний IP адрес полученный виртуальной машиной от Microsoft Azure DHCP.
Internal Load Balancer: Внутренний балансировщик Microsoft Azure распределяющий трафик между виртуальными машинами внутри VNET или облачного сервиса.
Endpoint: Ассоциирует VIP/DIP + порт на виртуальной машине с портом на Azure Load Balancer для внешнего трафика или на Internal Load Balancer для трафика внутри VNET (или облачного сервиса).
Вы можете найти больше информации об этих терминах и сетях Azure в этом блоге:
VIPs, DIPs and PIPs in Microsoft Azure
http://blogs.msdn.com/b/cloud_solution_architect/archive/2014/11/08/vips-dips-and-pips-in-microsoft-azure.aspx
ОК, достаточно теории. Хранилище данных готово и мы знаем как работают сети в Azure. Готовы ли мы создать кластер? Да!
Вместо использования Failover Cluster Manager, я рекомендую использовать командлет New-Cluster и указать статичный IP адрес при создании кластера. Используя этот метод, вы можете добавить все узлы кластера и проще разобраться с настройками IP адреса не совершая дополнительных действий через Failover Cluster Manager.
Обратите внимание: Статичный IP адрес, назначенный Cluster Name Object (CNO) не предназначен для обмена данными по сети. Он нужен, чтобы выполнить зависимость необходимую для активации CNO. Поэтому вы не можете, например, пропинговать этот адрес, не можете разрешить DNS имя и не можете использовать CNO для управления, так как его адрес не доступен.
Если по каким-либо причинам вы не хотите использовать PowerShell или если вам привычнее использовать Failover Cluster Manager, вам придётся совершить несколько дополнительных шагов. Разница при использовании Failover Cluster Manager вместо PowerShell в том, что вам придётся создать кластер с одним узлом и добавить второй позже. Причина в том, что CNO не может быть активирован, так как он не может получить уникальный IP адрес от Azure DHCP. Вместо этого CNO, при создании через Failover Cluster Manager, имеет тот же IP адрес, что и узел на котором находится ресурс CNO. Этот адрес не позволит активировать кластер, так как он будет считаться дубликатом (ведь получится, что в сети два объекта с таки адресом). Чтобы решить эту проблему, вам придется, как было сказано выше, создать кластер с одним узлом, а затем вручную задать новый адрес для CNO.
Пример:
CNO DEMOCLUSTER не активен из за того, что IP адрес, от которого он зависит, не доступен. Причина в том, что CNO получает конфликт на адресе 10.0.0.4, так как он уже занят самой виртуальной машиной.
Чтобы это исправить, нам нужно в настройках ресурса задать какой-нибудь другой незанятый адрес из той же подсети, например 10.0.0.7.
После этого мы можем активировать CNO ресурс.
Теперь, мы можем добавить второй узел в наш кластер.
Когда наш кластер готов, мы можем добавить в него новую службу. Для этой статьи я использую роль Файлового сервера, так как она является одновременно одной из самых распространенных и простых для понимания.
Обратите внимание: Мы не рекомендуем вам, на самом деле, использовать кластеризованный файловый сервер в Azure из соображений ограничений по производительности и стоимости такого решения.
В отличие от кластеров, которые вы разворачиваете у себя локально, я рекомендую вам остановить все узлы и оставить активным только один. Это нужно, чтобы избежать ситуации, когда роль переезжает между узлами из за того, что VCO (Virtual Computer Object) серверов будет автоматически получать тот же IP адрес, что и кластерный узел, на котором он находится и, таким образом, он будет отключаться с ошибкой и переезжать на следующий узел. Ситуация полностью аналогична тому, что мы обсудили для CNO.
На скриншоте ниже показан результат (мы назначили IP адрес 10.0.0.8 нашему кластеру)
Помните, что это всё тот же временный IP адрес, который мы используем для того, чтобы активировать кластер. Ни одна виртуальная машина в нашей сети, кроме самого кластерного узла, не сможет получить доступ к кластеру по этому адресу. Сеть Azure работает таким образом что весь трафик с виртуальной машины возвращается к ней обратно.
Начинается самое интересное. Нам нужно использовать Azure Load Balancer, чтобы этот адрес можно было использовать для связи клиентов с нашим кластером.
Load Balancer это сетевой ресурс в Azure, который распределяет трафик между различными виртуальными машинами. Адрес Load Balancer может быть как внешний VIP, так и внутренний DIP. У каждой виртуальной машины должен быть свой endpoint, на который будет направлять трафик Load Balancer. Endpoint имеет два типа портов. Первый — Regular порты для клиент-серверного взаимодействия. Например, 445 порт для SMB на файловом сервере или 80 порт HTTP на Web сервере. Вторым типом портов являются Probe (по умолчанию порт 59999). Задача этого порта — определение того, который из узлов кластера является активным держателем VCO. Load Balancer регулярно опрашивает все кластерные узлы через Probe (интервал проверки по умолчанию — 10 секунд). Вы должны знать какие порты использует приложение или служба, которую вы собираетесь разместить на вашем кластере, так как вам придется указать эти порты в настройках endpoint, а затем добавить туда Probe порт. После этого вам нужно добавить в настройки адреса VCO этот Probe порт. В итоге, Load Balancer будет направлять трафик на соответствующий порт сервера, на котором активен VCO.Всё это нужно сделать с помощью PowerShell.
Обратите внимание: На момент написания этой статьи Microsoft поддерживает только одну кластерную ресурсную группу в режиме ctive/Passive. Причина в том, что VCO может использовать только IP адрес облачной службы (VIP) или IP адрес внутреннего Load Balancer. Это ограничение до сих пор в силе, несмотря на то, что в облачной службе теперь можно создать несколько VIP адресов.
На диаграмме ниже показана работа Internal Load Balancer (ILB):
В нашем примере мы создаём файловый кластер, поэтому портом для endpoint будет 445. Адресом ILB мы выберем 10.0.0.8. Давайте посмотрим как это настроить.
Шаг 1: Добавим кластер в облачную службу
Эти команды выполняются на той машине, которую вы используете для управления средой Microsoft Azure.
Шаг 2: Настроим endpoint для каждого узла, использующего ILB.
Эти команды выполняются на той машине, которую вы используете для управления средой Microsoft Azure.
Шаг 3: Обновим параметры IP адреса VCO выбранным Probe портом.
Эти команды выполняются на узле кластера. Вариант для Windows Server 2008 R2:
Вариант для Windows Server 2012/2012 R2:
В результате должно получиться что-то похожее на это:
Отключите и вновь включите кластерный ресурс IP адреса и запустите кластерную роль.
Теперь ваш ILB связан с IP адресом VCO. Последнее, что вам нужно сделать, это настроить WIndows Firewall. Вам нужно настроить правила разрешающие соединение по порту 59999 (или тому, который выбрали вы) на всех узлах вашего кластера. На этом всё. Ваш кластер готов к работе. Обратите внимание, что первое подключение к VCO или попытка подключиться к нему сразу после перевода ролей с одного узла на другой может занять до 10 секунд. Это связано со значением параметра ProbeIntervalInSeconds, который мы задали ранее.
В нашем примере мы выбрали для VCO внутренний IP адрес 10.0.0.8. Если вы хотите сделать ваш VCO доступным извне, вы можете использовать внешний IP адрес облачной службы (VIP). Шаги будут теми же и адже проще, так как вы сможете пропустить шаг 1 (Azure Load Balancer и так используется для VIP). Вам нужно только создать endoint с нужными портами на каждом кластерном узле (Шаг 2) и настроить IP адрес VCO (Шаг 3). Помните, что если ваш кластер доступен извне, то вам стоит уделить больше внимания его настройкам безопасности.
Отлично! Вы создали свой кластер в среде Azure IaaS. Получилось довольно длинно, но, надеюсь, вам было интересно и вы узнали что-то полезное. Можете задавать мне вопросы в комментариях.
Удачи с кластерами!
Mario Liu
Support Escalation Engineer
CSS Americas | WINDOWS | HIGH AVAILABILITY
Привет, фанаты кластеров. В своей предыдущей статье я рассказал о том, как обойти ограничения среды Microsoft Azure IaaS при подготовке хранилища данных для отказоустойчивого кластера Microsoft Windows. Давайте теперь поговорим о другой важной части создания кластера — сети.
Перед тем как начать, давайте перечислим несколько базовых понятий относящихся к сетям в Azure. Вот термины, которые нам потребуются для статьи о создании кластера:
VIP (Virtual IP address): Публичный IP адрес облачной службы. Он также используется балансировщиком нагрузки Azure, который распределяет трафик до его направления на виртуальную машину.
DIP (Dynamic IP address): Внутренний IP адрес полученный виртуальной машиной от Microsoft Azure DHCP.
Internal Load Balancer: Внутренний балансировщик Microsoft Azure распределяющий трафик между виртуальными машинами внутри VNET или облачного сервиса.
Endpoint: Ассоциирует VIP/DIP + порт на виртуальной машине с портом на Azure Load Balancer для внешнего трафика или на Internal Load Balancer для трафика внутри VNET (или облачного сервиса).
Вы можете найти больше информации об этих терминах и сетях Azure в этом блоге:
VIPs, DIPs and PIPs in Microsoft Azure
http://blogs.msdn.com/b/cloud_solution_architect/archive/2014/11/08/vips-dips-and-pips-in-microsoft-azure.aspx
ОК, достаточно теории. Хранилище данных готово и мы знаем как работают сети в Azure. Готовы ли мы создать кластер? Да!
Вместо использования Failover Cluster Manager, я рекомендую использовать командлет New-Cluster и указать статичный IP адрес при создании кластера. Используя этот метод, вы можете добавить все узлы кластера и проще разобраться с настройками IP адреса не совершая дополнительных действий через Failover Cluster Manager.
New-Cluster -Name DEMOCLUSTER -Node node1,node2 -StaticAddress 10.0.0.7
Обратите внимание: Статичный IP адрес, назначенный Cluster Name Object (CNO) не предназначен для обмена данными по сети. Он нужен, чтобы выполнить зависимость необходимую для активации CNO. Поэтому вы не можете, например, пропинговать этот адрес, не можете разрешить DNS имя и не можете использовать CNO для управления, так как его адрес не доступен.
Если по каким-либо причинам вы не хотите использовать PowerShell или если вам привычнее использовать Failover Cluster Manager, вам придётся совершить несколько дополнительных шагов. Разница при использовании Failover Cluster Manager вместо PowerShell в том, что вам придётся создать кластер с одним узлом и добавить второй позже. Причина в том, что CNO не может быть активирован, так как он не может получить уникальный IP адрес от Azure DHCP. Вместо этого CNO, при создании через Failover Cluster Manager, имеет тот же IP адрес, что и узел на котором находится ресурс CNO. Этот адрес не позволит активировать кластер, так как он будет считаться дубликатом (ведь получится, что в сети два объекта с таки адресом). Чтобы решить эту проблему, вам придется, как было сказано выше, создать кластер с одним узлом, а затем вручную задать новый адрес для CNO.
Пример:
CNO DEMOCLUSTER не активен из за того, что IP адрес, от которого он зависит, не доступен. Причина в том, что CNO получает конфликт на адресе 10.0.0.4, так как он уже занят самой виртуальной машиной.
Чтобы это исправить, нам нужно в настройках ресурса задать какой-нибудь другой незанятый адрес из той же подсети, например 10.0.0.7.
После этого мы можем активировать CNO ресурс.
Теперь, мы можем добавить второй узел в наш кластер.
Когда наш кластер готов, мы можем добавить в него новую службу. Для этой статьи я использую роль Файлового сервера, так как она является одновременно одной из самых распространенных и простых для понимания.
Обратите внимание: Мы не рекомендуем вам, на самом деле, использовать кластеризованный файловый сервер в Azure из соображений ограничений по производительности и стоимости такого решения.
В отличие от кластеров, которые вы разворачиваете у себя локально, я рекомендую вам остановить все узлы и оставить активным только один. Это нужно, чтобы избежать ситуации, когда роль переезжает между узлами из за того, что VCO (Virtual Computer Object) серверов будет автоматически получать тот же IP адрес, что и кластерный узел, на котором он находится и, таким образом, он будет отключаться с ошибкой и переезжать на следующий узел. Ситуация полностью аналогична тому, что мы обсудили для CNO.
На скриншоте ниже показан результат (мы назначили IP адрес 10.0.0.8 нашему кластеру)
Помните, что это всё тот же временный IP адрес, который мы используем для того, чтобы активировать кластер. Ни одна виртуальная машина в нашей сети, кроме самого кластерного узла, не сможет получить доступ к кластеру по этому адресу. Сеть Azure работает таким образом что весь трафик с виртуальной машины возвращается к ней обратно.
Начинается самое интересное. Нам нужно использовать Azure Load Balancer, чтобы этот адрес можно было использовать для связи клиентов с нашим кластером.
Load Balancer это сетевой ресурс в Azure, который распределяет трафик между различными виртуальными машинами. Адрес Load Balancer может быть как внешний VIP, так и внутренний DIP. У каждой виртуальной машины должен быть свой endpoint, на который будет направлять трафик Load Balancer. Endpoint имеет два типа портов. Первый — Regular порты для клиент-серверного взаимодействия. Например, 445 порт для SMB на файловом сервере или 80 порт HTTP на Web сервере. Вторым типом портов являются Probe (по умолчанию порт 59999). Задача этого порта — определение того, который из узлов кластера является активным держателем VCO. Load Balancer регулярно опрашивает все кластерные узлы через Probe (интервал проверки по умолчанию — 10 секунд). Вы должны знать какие порты использует приложение или служба, которую вы собираетесь разместить на вашем кластере, так как вам придется указать эти порты в настройках endpoint, а затем добавить туда Probe порт. После этого вам нужно добавить в настройки адреса VCO этот Probe порт. В итоге, Load Balancer будет направлять трафик на соответствующий порт сервера, на котором активен VCO.Всё это нужно сделать с помощью PowerShell.
Обратите внимание: На момент написания этой статьи Microsoft поддерживает только одну кластерную ресурсную группу в режиме ctive/Passive. Причина в том, что VCO может использовать только IP адрес облачной службы (VIP) или IP адрес внутреннего Load Balancer. Это ограничение до сих пор в силе, несмотря на то, что в облачной службе теперь можно создать несколько VIP адресов.
На диаграмме ниже показана работа Internal Load Balancer (ILB):
В нашем примере мы создаём файловый кластер, поэтому портом для endpoint будет 445. Адресом ILB мы выберем 10.0.0.8. Давайте посмотрим как это настроить.
Шаг 1: Добавим кластер в облачную службу
Эти команды выполняются на той машине, которую вы используете для управления средой Microsoft Azure.
# Определяем переменные
$ServiceName = "demovm1-3va468p3" # имя облачной службы, в которой находятся узлы кластера. Это имя уникально. Вы можете посмотреть его на портале или, как в примере ниже, с помощью PowerShell командлета get-azurevm.
$ILBName = "DEMOILB" # имя для новогоILB
$SubnetName = "Subnet-1" # имя подсети для наших виртуальных машин
$ILBStaticIP = "10.0.0.8" # статический IP адрес для ILB
# Создаём ILB, используя заданные параметры
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP
# Проверяем результат
Get-AzureInternalLoadBalancer –servicename $ServiceName
Шаг 2: Настроим endpoint для каждого узла, использующего ILB.
Эти команды выполняются на той машине, которую вы используете для управления средой Microsoft Azure.
# Определяем переменные
$VMNodes = "DEMOVM1", “DEMOVM2" # имена кластерных узлов, через запятую
$EndpointName = "SMB" # имя для нового endpoint
$EndpointPort = "445" # public port для endpoint (в нашем случае - порт SMB)
# Добавляем endpoint с портом 445 и probe портом 59999 для каждого кластерного узла. Эта операция займёт некоторое время. Обратите внимание на параметр ProbeIntervalInSeconds. Именно он определяет с какой частотой Load Balancer будет опрашивать кластерные узлы.
ForEach ($node in $VMNodes)
{
Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName-LB" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
}
# Проверяем результат
ForEach ($node in $VMNodes)
{
Get-AzureVM –ServiceName $ServiceName –Name $node | Get-AzureEndpoint | where-object {$_.name -eq "smb"}
}
Шаг 3: Обновим параметры IP адреса VCO выбранным Probe портом.
Эти команды выполняются на узле кластера. Вариант для Windows Server 2008 R2:
# Определяем переменные
$ClusterNetworkName = "Cluster Network 1" # имя сети кластера (используйте командлет Get-ClusterNetwork или GUI, чтобы найти это имя)
$IPResourceName = “IP Address 10.0.0.0" # the IP Address resource name (Use get-clusterresource | where-object {$_.resourcetype -eq "IP Address"} or GUI to find the name)
$ILBIP = “10.0.0.8” # IP адрес ILB
# Обновим настройки IP адреса VCO, для работы с ILB
cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$ILBIP probeport=59999 subnetmask=255.255.255.255
Вариант для Windows Server 2012/2012 R2:
# Определяем переменные
$ClusterNetworkName = "Cluster Network 1" # имя сети кластера (используйте командлет Get-ClusterNetwork или GUI, чтобы найти это имя)
$IPResourceName = “IP Address 10.0.0.0" # имя ресурса IP адреса (используйте командлет get-clusterresource | where-object {$_.resourcetype -eq "IP Address"} или GUI, чтобы найти это имя)
$ILBIP = “10.0.0.8” # IP адрес ILB
$params = @{"Address"="$ILBIP";
"ProbePort"="59999";
"SubnetMask"="255.255.255.255";
"Network"="$ClusterNetworkName";
"OverrideAddressMatch"=1;
"EnableDhcp"=0}
# Обновим настройки IP адреса VCO, для работы с ILB
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple $params
В результате должно получиться что-то похожее на это:
Отключите и вновь включите кластерный ресурс IP адреса и запустите кластерную роль.
Теперь ваш ILB связан с IP адресом VCO. Последнее, что вам нужно сделать, это настроить WIndows Firewall. Вам нужно настроить правила разрешающие соединение по порту 59999 (или тому, который выбрали вы) на всех узлах вашего кластера. На этом всё. Ваш кластер готов к работе. Обратите внимание, что первое подключение к VCO или попытка подключиться к нему сразу после перевода ролей с одного узла на другой может занять до 10 секунд. Это связано со значением параметра ProbeIntervalInSeconds, который мы задали ранее.
В нашем примере мы выбрали для VCO внутренний IP адрес 10.0.0.8. Если вы хотите сделать ваш VCO доступным извне, вы можете использовать внешний IP адрес облачной службы (VIP). Шаги будут теми же и адже проще, так как вы сможете пропустить шаг 1 (Azure Load Balancer и так используется для VIP). Вам нужно только создать endoint с нужными портами на каждом кластерном узле (Шаг 2) и настроить IP адрес VCO (Шаг 3). Помните, что если ваш кластер доступен извне, то вам стоит уделить больше внимания его настройкам безопасности.
Отлично! Вы создали свой кластер в среде Azure IaaS. Получилось довольно длинно, но, надеюсь, вам было интересно и вы узнали что-то полезное. Можете задавать мне вопросы в комментариях.
Удачи с кластерами!
Mario Liu
Support Escalation Engineer
CSS Americas | WINDOWS | HIGH AVAILABILITY
Поделиться с друзьями