Налаштування наборів Microsoft Cluster на Dell PowerEdge

Набори кластерів, запроваджені у Windows Server 2019 (WS19), покращують гнучкість і відмовостійкість SDDC (Software Defined Data Center). Набір кластерів – це технологія, яка дозволяє адміністраторам об'єднувати кілька кластерів Windows 2019 в одну парасольку кластерів.

Існуючі відмовостійкі кластери можуть вміщувати максимум 64 вузли. Технологія Cluster Sets об'єднує кілька кластерів WS19 в одному домені, причому кожен з цих кластерів підтримує до 64 вузлів WS19. У порівнянні з відмовостійким кластером, Cluster Set має більшу відмовостійкість. Наприклад, 4-вузловий відмовостійкий кластер може пережити відмову 2 вузлів. З одним і тим же 4-вузловим кластером, якщо ми розділимо на два 2-вузлові кластери і сформуємо з нього кластер, він може пережити один збій кластера плюс відмову одного вузла від кластера, що залишився. Так, він може пережити 3 відмови вузлів загалом.

Огляд функцій кластерних наборів у Server 2019 можна знайти в розділах «Вступ до кластерних наборів-у-windows-server-2019» і «Набори кластерів». Кластерні набори набувають своєї гнучкості завдяки використанню базової технології, яка називається Infrastructure Scale-Out File Server; це також полегшує міжкластерну міграцію віртуальних машин у межах кластерного набору.

Налаштування лабораторної роботи для розгортання набору кластерів на PowerEdge

Використовувані сервери: Два PowerEdge R730XD і два PowerEdge R740XD

Створено перший кластер за допомогою двох R730XD і названо S2D13G54 (під назвою Member Cluster 1).

Створено другий кластер за допомогою двох R740XD і названо S2D14G54 (називається Member Cluster 2).

Створено по два томи CSV на кожному з вищезгаданих створених кластерів.

Створено віртуальну машину 'vm1' на кластері-члені 1 і віртуальну машину 'vm2' на кластері-члені 2. Потім я об'єднав ці дві віртуальні машини, щоб створити Management Cluster (під назвою mgClus54) для набору кластерів. Під час створення кластера керування потрібне спільне сховище.

Встановлено роль File-Services у кожному з вузлів Member Cluster 1, Member Cluster 2 та Management Cluster:

Install-WindowsFeature File-Services -IncludeAllSubFeature –IncludeManagementTools –Restart

Створено інфраструктурний файловий сервер SOFS на Member Cluster 1, Member Cluster 2 та Management Cluster:

add-ClusterScaleOutFileServerRole -ім'я <SOFS> інфраструктури -інфраструктура

 

Створено набір кластерів з іменем CLUSSET54:

New-ClusterSet -Name CLUSSET54 -NamespaceRoot <Management Cluster Ім'я> SOFS -CimSession <Сеанс CIM до кластера> керування

 

А потім додаємо створені S2D14G54 і S2D13G54 Cluster в кластер в ClusterSet:

Add-ClusterSetMember -ClusterName S2D14G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Ім'я SOFS, створеного на S2D14G54 кластері>

 

Add-ClusterSetMember -ClusterName S2D13G54 -CimSession <Cim Session to ClusterSet> -InfraSOFSName <Ім'я SOFS, створеного на S2D13G54 кластері>

 

 

 

Потім я розгортаю дві віртуальні машини V213G і V214G на кластері-члені 1 і кластері 2 відповідно і реєструю віртуальні машини в наборі кластерів:

get-ClusterSetMember -ClusterName <Ім'я> кластера | register-clusterSetVM -VMName <ім'я віртуальної машини>

 
Для тестування живої міграції між кластерами я спробував перенести віртуальну машину "V213G" до Member Cluster 2. Перш ніж виконувати міграцію між кластерами, нам потрібно врахувати наступні моменти:

1. 1. Налаштування віртуальної машини, Сумісність процесорів має бути ввімкнено.
   2. Налаштування обмеженого делегування Kerberos (KCD) між усіма парами вузлів між кластерами
      1. Інструкції з обмеженого делегування від команди продукту Microsoft Hyper-V стануть у нагоді для налаштування.
      2. Налаштуйте тип автентифікації міграції віртуальної машини між кластерами в реальному часі на Kerberos на кожному вузлі набору кластерів.

foreach($h in $hosts){Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -computerName $h }

1. 1. 3. Додайте кластер керування до групи локальних адміністраторів на кожному вузлі набору кластерів.

foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }

 

Для виконання будь-якої діяльності з обслуговування кластера в наборі кластерів перенесіть усі віртуальні машини, які є частиною кластера, до інших кластерів у наборі кластерів, а потім видаліть кластер із набору кластерів:

 

Remove-ClusterSetMember -ClusterName ClusterName <> -CimSession <Сеанс, створений для ClusterSet>

 

Після виконання дії з технічного обслуговування додайте кластер назад до набору кластерів.

 

У разі несподіваного збою кластера-члена, набір кластерів недостатньо розумний, щоб впоратися з аварійним ремонтом. У Windows Server 2019 підтримується лише ручне переміщення ресурсів з одного кластера до іншого, навіть незважаючи на те, щовідмовостійкість віртуальної машини продовжує функціонувати в межах одного кластера-учасника.

 

 

 

 

 

 

 

 

 

 

 

Існуючі відмовостійкі кластери можуть вміщувати максимум 64 вузли. Технологія Cluster Sets об'єднує кілька кластерів WS19 в одному домені, причому кожен з цих кластерів підтримує до 64 вузлів WS19. У порівнянні з відмовостійким кластером, Cluster Set має більшу відмовостійкість. Наприклад, 4-вузловий відмовостійкий кластер може пережити відмову 2 вузлів. З одним і тим же 4-вузловим кластером, якщо ми розділимо на два 2-вузлові кластери і сформуємо з нього кластер, він може пережити один збій кластера плюс відмову одного вузла від кластера, що залишився. Так, він може пережити 3 відмови вузлів загалом.

Після виконання дії з технічного обслуговування додайте кластер назад до набору кластерів.

 

У разі несподіваного збою кластера-члена, набір кластерів недостатньо розумний, щоб впоратися з аварійним ремонтом. У Windows Server 2019 підтримується тільки ручне переміщення ресурсів з одного кластера в інший; навіть незважаючи на те, що автоматичне перемикання на відмову віртуальної машини продовжує функціонувати в межах однієї елементарної області кластера.