Відмовостійкий кластер Windows Server Microsoft Azure. Мережа

Передмова. Ця публікація — продовження теми створення відмовостійкого кластера 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.

New-Cluster -Name DEMOCLUSTER -Node node1,node2 -StaticAddress 10.0.0.7


Зверніть увагу:: Статичний IP адреса, призначений Cluster Object Name (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, так як він вже зайнятий самої віртуальною машиною.

image

Щоб це виправити, нам потрібно в налаштуваннях ресурсу поставити який-небудь інший незайнятий адресу з тієї ж підмережі, наприклад 10.0.0.7.

image

Після цього ми можемо активувати CNO ресурс.

image

Тепер, ми можемо додати другий вузол в наш кластер.

Коли наш кластер готовий, ми можемо додати в нього нову службу. Для цієї статті я використовую роль Файлового сервера, так як вона є одночасно однією з найбільш поширених і простих для розуміння.

Зверніть увагу:: Ми не радимо вам, насправді, використовувати кластеризованный файловий сервер в Azure з міркувань обмежень по продуктивності і вартості такого рішення.

На відміну від кластерів, які ви розгортаєте у себе локально, я рекомендую вам зупинити всі вузли і залишити активним тільки один. Це потрібно, щоб уникнути ситуації, коли роль переїжджає між вузлами із за того, що VCO (Virtual Computer Object) серверів буде автоматично отримувати той же IP-адресу, що й кластерний вузол, на якому він знаходиться і, таким чином, він буде відключатися з помилкою і переїжджати на наступний вузол. Ситуація повністю аналогічна тому, що ми обговорили для CNO.

На скріншоті нижче показаний результат (ми призначили IP адреса 10.0.0.8 нашому кластеру)

image

Пам'ятайте, що це все той же тимчасовий 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 регулярно опитує всі кластерні вузли через Зонд (інтервал перевірки за замовчуванням — 10 секунд). Ви повинні знати, які порти використовує додаток або служба, яку ви збираєтеся розмістити на вашому кластері, так як вам доведеться вказати ці порти в налаштуваннях endpoint, а потім додати туди Probe порт. Після цього вам потрібно додати в налаштування адреси VCO цей Probe порт. У підсумку, Load Balancer буде направляти трафік на відповідний порт сервера, на якому активний VCO.Все це треба зробити за допомогою PowerShell.

Зверніть увагу:: На момент написання цієї статті Microsoft підтримує тільки одну кластерну ресурсну групу в режимі ctive/Passive. Причина в тому, що VCO може використовувати тільки IP адреса хмарної служби (VIP) або IP адреса внутрішнього Load Balancer. Це обмеження досі в силі, незважаючи на те, що в хмарі тепер можна створити кілька VIP адрес.

На діаграмі нижче показана робота Internal Load Balancer (ILB):
image

У нашому прикладі ми створюємо файловий кластер, тому портом для endpoint буде 445. Адресою ILB ми виберемо 10.0.0.8. Давайте подивимося, як це налаштувати.

Крок 1: Додамо кластер в хмарну службу

Ці команди виконуються на тій машині, яку ви використовуєте для управління середовищем Microsoft Azure.

# Визначаємо змінні
$ServiceName = "demovm1-3va468p3" # ім'я хмарної служби, в якій знаходяться вузли кластера. Це ім'я є унікальним. Ви можете подивитися його на порталі або, як у прикладі нижче, з допомогою PowerShell командлет get-azurevm.

image
$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

image

Крок 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"}
}


image

Крок 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


У результаті повинно вийти щось схоже на це:
image

Вимкніть і знову ввімкніть кластерний ресурс 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). Пам'ятайте, що якщо ваш кластер доступний ззовні, то вам варто приділити більше уваги його налаштувань безпеки.

Відмінно! Ви створили свій кластер в середовищі Microsoft IaaS. Вийшло досить довго, але, сподіваюся, вам було цікаво і ви дізналися щось корисне. Можете задавати мені питання в коментарях.

Удачи з кластерами!

Mario Liu
Support Escalation Engineer
CSS Americas | WINDOWS | HIGH AVAILABILITY
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.