Налаштування наборів 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; це також полегшує міжкластерну міграцію віртуальних машин у межах Cluster Set.

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

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

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

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

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

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

Встановлено роль файлових служб у кожному з вузлів Member Cluster 1, Member Cluster 2 та Management Cluster:

Install-WindowsFeature Файлові служби -IncludeAllSubFeature –IncludeManagementTools –Перезавантажити

Створено інфраструктуру файлового сервера 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 на Member Cluster 1 і Member Cluster 2 відповідно і реєструю віртуальні машини в Cluster Set:

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 підтримується тільки ручне переміщення ресурсів з одного кластера в інший; навіть незважаючи на те, що автоматичне перемикання після відмови віртуальної машини продовжує функціонувати в межах однієї елементної області кластера.