Развертывание набора кластеров

Статья
10/06/2023

Область применения: Windows Server 2019

В этой статье содержатся сведения о развертывании набора кластеров для отказоустойчивых кластеров Windows Server с помощью PowerShell. Набор кластеров — это группа нескольких отказоустойчивых кластеров, кластеризованных вместе. С помощью набора кластеров можно увеличить количество узлов сервера в одном облаке программно-определяемого центра обработки данных (SDDC) по порядкам величины.

Наборы кластеров протестированы и поддерживаются до 64 узлов кластера. Однако наборы кластеров могут масштабироваться до гораздо больших ограничений и не жестко закодированы для ограничения.

Льготы

Наборы кластеров предлагают следующие преимущества:

Значительно увеличивает поддерживаемый масштаб облака SDDC для запуска высокодоступных виртуальных машин, объединяя несколько небольших кластеров в одну большую структуру, сохраняя границу сбоя программного обеспечения в одном кластере. Вы можете легко перенести виртуальные машины по набору кластеров.
Повышенная устойчивость. Наличие четырех 4-узловых кластеров в наборе кластеров обеспечивает лучшую устойчивость, чем один 16-узелный кластер в том, что несколько вычислительных узлов могут уменьшиться, и рабочая среда остается нетронутой.
Управление жизненным циклом отказоустойчивого кластера, включая подключение и выход из эксплуатации кластеров, не влияя на доступность виртуальной машины клиента.
Гибкость виртуальных машин в отдельных кластерах и наличие единого пространства имен хранилища.
Легко изменить соотношение рабочих нагрузок вычислений к хранилищу в гиперконвергентной среде.
Преимущества таких доменов и групп доступности Azure в отдельных кластерах при первоначальном размещении виртуальной машины и последующей миграции.
Может использовать даже если оборудование вычислений и хранилища между узлами кластера не идентично.
Динамическая миграция виртуальных машин между кластерами.
Такие группы доступности Azure и домены сбоя в нескольких кластерах.
Перемещение виртуальных машин SQL Server между кластерами.

Требования и ограничения

Существует несколько требований и ограничений для использования наборов кластеров:

Все кластеры-члены в наборе кластеров должны находиться в одном лесу Active Directory (AD).
Серверы-члены в наборе должны выполнять ту же версию операционной системы. Виртуальные машины нельзя перенести между разными операционными системами. У вас может быть набор кластеров, состоящий из одного, но не нескольких из следующих параметров:
- Отказоустойчивый кластер Windows Server 2019 и отказоустойчивый кластер Windows Server 2019
- Отказоустойчивый кластер Windows Server 2019 и Windows Server 2019 Локальные дисковые пространства
- Локальные дисковые пространства Windows Server 2019 и Windows Server 2019 Локальные дисковые пространства
Одинаковое оборудование процессора необходимо для всех серверов-членов для динамической миграции между кластерами-членами; В противном случае необходимо выбрать совместимость процессора ЦП в параметрах виртуальных машин.
Виртуальные машины набора кластеров должны переноситься вручную в кластеры. Они не могут автоматически выполнять отработку отказа.
служба хранилища реплика должна использоваться между кластерами-членами для реализации устойчивости хранилища к сбоям кластера. При использовании служба хранилища реплики следует учитывать, что пути UNC хранилища пространства имен не изменятся автоматически при отработке отказа реплики служба хранилища целевому кластеру реплика.
Локальные дисковые пространства не работает в кластерах-членах в наборе кластеров. Скорее, Локальные дисковые пространства применяется к одному кластеру, при этом каждый кластер имеет собственный пул носителей.

Архитектура

На следующей схеме показан набор кластеров на высоком уровне:

Ниже приведена сводка по каждому из отображаемых элементов:

Кластер управления

Кластер управления размещает высокодоступную плоскость управления и масштабируемый файловый сервер пространства имен (SOFS) для набора кластеров. Кластер управления логически отделен от отдельных кластеров членов, которые выполняют рабочие нагрузки виртуальной машины. Это делает плоскость управления набором кластера отказоустойчивой к любым локализованным сбоям на уровне кластера, таким как потеря мощности кластера-члена.

Главный мастер набора кластеров

Обмен данными между кластерами-членами слабо связан и координируется ресурсом master набора кластеров (CS-Master). Как и другие ресурсы набора кластеров, CS-Master является высокодоступным и устойчивым к сбоям отдельных кластеров-членов или сбоям узлов кластера управления. Через поставщик WMI набора кластеров CS-Master предоставляет конечную точку управления для всех действий управления набором кластеров.

Кластер-член

Кластер-член запускает виртуальную машину и Локальные дисковые пространства рабочие нагрузки. Несколько кластеров-членов участвуют в развертывании набора кластеров, формируя большую облачную структуру SDDC. Кластеры-члены отличаются от кластера управления в двух ключевых аспектах: кластеры-члены участвуют в конструкциях домена сбоя и группы доступности, а кластеры-члены имеют размер для размещения виртуальной машины и Локальные дисковые пространства рабочих нагрузок. По этой причине виртуальные машины, перемещающиеся по кластерам-членам, не размещаются в кластере управления.

Рабочая роль набора кластеров

CS-Master взаимодействует с ресурсом кластера в кластерах-членах, называемым рабочей ролью набора кластеров (CS-Worker). CS-Worker отвечает на запросы CS-Master, включая размещение виртуальных машин и инвентаризацию ресурсов. Существует один экземпляр CS-Worker для каждого кластера-члена.

Домен сбоя

Домен сбоя — это группа оборудования и программного обеспечения, которая может завершиться сбоем. Хотя вы можете назначить один или несколько кластеров в качестве домена сбоя, каждый узел может участвовать в домене сбоя в группе доступности. Границы домена сбоя основаны на топологии центра обработки данных, сетевой архитектуре и других соображениях.

Группа доступности

Группа доступности используется для настройки требуемой избыточности кластеризованных рабочих нагрузок в доменах сбоя путем группировки и развертывания рабочих нагрузок. Для двухуровневого приложения необходимо настроить по крайней мере две виртуальные машины в группе доступности для каждого уровня, что гарантирует, что при сбое домена в группе доступности приложение будет иметь по крайней мере одну виртуальную машину на каждом уровне, размещенном в другом домене сбоя.

Создание набора кластеров

Используйте PowerShell в следующем примере рабочего процесса для создания набора кластеров с помощью двух кластеров. Имя набора кластера — CSMASTER.

Имя кластера	Имя SOFS инфраструктуры
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Используйте клиентский компьютер управления под управлением Windows Server 2022 или Windows Server 2019.
Установите средства отказоустойчивого кластера на сервере кластера управления.
Создайте два члена кластера и по крайней мере два общих тома кластера (CSVs) в каждом кластере.
Создайте кластер управления (физический или гостевой), который перестраивает кластеры-члены. Это гарантирует, что плоскость управления набором кластеров продолжает быть доступна, несмотря на возможные сбои кластера-члена.
Чтобы создать набор кластеров, выполните следующие действия.
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Примечание.

Если вы используете статический IP-адрес, необходимо включить -StaticAddress x.x.x.x в команду New-ClusterSet .

Чтобы добавить члены кластера в набор кластера, выполните следующие действия.

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

Чтобы перечислить все кластеры-члены в наборе кластеров:
```
Get-ClusterSetMember -CimSession CSMASTER
```
Чтобы перечислить все кластеры-члены в наборе кластеров, включая узлы кластера управления:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Чтобы перечислить все узлы сервера из всех кластеров-членов:
```
Get-ClusterSetNode -CimSession CSMASTER
```
Список всех групп ресурсов в наборе кластеров:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup
```
Чтобы проверить набор кластеров, содержит одну общую папку S МБ (ScopeNameимя файлового сервера инфраструктуры) в инфраструктуре SOFS для каждого тома CSV-файла кластера:
```
Get-SmbShare -CimSession CSMASTER
```
Просмотрите файлы журнала отладки набора кластеров для набора кластеров, кластера управления и каждого члена кластера:
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Настройте Kerberos с ограниченным делегированием между всеми элементами набора кластера.
Настройте тип проверки подлинности динамической миграции виртуальной машины между кластерами в Kerberos на каждом узле в наборе кластеров:
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```
Добавьте кластер управления в группу локальных администраторов на каждом узле сервера-члена кластера в наборе кластеров:
```
foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }
```

Создание виртуальных машин набора кластеров

После создания набора кластера необходимо создать виртуальные машины. Перед выполнением следующих проверка необходимо выполнить следующие проверка:

Проверка доступной памяти на каждом узле сервера кластера
Проверка свободного места на каждом узле сервера кластера
Проверьте все определенные требования к хранилищу виртуальных машин с точки зрения скорости и производительности

Команда Get-ClusterSetOptimalNodeForVM определяет оптимальный кластер и узел в наборе кластеров, а затем развертывает виртуальную машину на ней. В следующем примере создается новая виртуальная машина:

Доступно 4 ГБ
Один виртуальный процессор
Доступно 10 % минимального ЦП

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

По завершении отобразится узел кластера, на котором развернута виртуальная машина. В приведенном выше примере он будет отображаться следующим образом:

State         : Running
ComputerName  : 1-S2D2

Если для добавления виртуальной машины недостаточно памяти, емкости ЦП или дискового пространства, вы получите следующую ошибку:

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

После создания виртуальной машины он отображается в диспетчере Hyper-V на определенном узле. Чтобы добавить ее в качестве виртуальной машины набора кластеров и добавить ее в кластер, используйте следующую команду:

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

По завершении выходные данные:

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

Если вы создали кластер с помощью существующих виртуальных машин, необходимо зарегистрировать виртуальные машины в наборе кластеров. Чтобы зарегистрировать все виртуальные машины одновременно, используйте:

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

Затем добавьте путь виртуальной машины к пространству имен набора кластеров.

Например, предположим, что существующий кластер добавляется в набор кластеров с предварительно настроенными виртуальными машинами, расположенными на локальном общем томе кластера (CSV). Путь к VHDX будет примерно таким же C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

Требуется миграция хранилища, так как пути CSV создаются локально в один кластер-член и поэтому недоступны для виртуальной машины после их переноса в кластеры-члены.

В этом примере CLUSTER3 добавляется в набор кластеров, используя Add-ClusterSetMember масштабируемый файловый сервер SOFS-CLUSTER3. Чтобы переместить конфигурацию и хранилище виртуальной машины, выполните следующую команду:

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

После завершения вы можете получить предупреждение:

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

Это предупреждение может игнорироваться, так как в конфигурации хранилища ролей виртуальной машины не было никаких физических изменений. Фактическое физическое расположение не изменяется; выполняются только пути конфигурации.

Дополнительные сведения см. в Move-VMStorageразделе "Перемещение виртуальной машины служба хранилища".

Динамическая миграция виртуальной машины в наборе кластеров включает в себя следующее:

Set-VMHost -UseAnyNetworkForMigration $true

Затем для перемещения виртуальной машины набора кластера из CLUSTER1 в NODE2-CL3 в CLUSTER3, например, команда будет:

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

Эта команда не перемещает хранилище виртуальных машин или файлы конфигурации и не требуется, так как путь к виртуальной машине остается как \\SOFS-CLUSTER1\VOLUME1. После регистрации виртуальной машины в пути к общей папке файлового сервера инфраструктуры диски и виртуальная машина не требуют наличия на том же узле, что и виртуальная машина.

Создание масштабируемого файлового сервера инфраструктуры

В кластере существует одна роль кластера SOFS инфраструктуры. Роль SOFS инфраструктуры создается путем указания -Infrastructure параметра switch в Add-ClusterScaleOutFileServerRole командлет. Например:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Каждый том CSV, созданный автоматически, активирует создание общей папки S МБ с автоматически созданным именем на основе имени тома CSV. Нельзя напрямую создавать или изменять общие папки S МБ в роли SOFS, кроме использования тома CSV, создания и изменения операций.

В конфигурациях с гиперконвергентной инфраструктурой SOFS позволяет клиенту S МБ (узлу Hyper-V) взаимодействовать с непрерывным доступом (ЦС) к серверу S МБ инфраструктуры SOFS. Этот гиперконвергентный S МБ ЦС обратного цикла достигается виртуальными машинами, обращаюющимися к файлам виртуального диска (VHDX), в которых удостоверение виртуальной машины переадресовываются между клиентом и сервером. Это перенаправление удостоверений позволяет использовать списки управления доступом для VHDx-файлов так же, как и в стандартных конфигурациях гиперконвергированных кластеров, как и раньше.

После создания набора кластеров пространство имен набора кластеров использует SOFS инфраструктуры для каждого из кластеров-членов, а также инфраструктуру SOFS в кластере управления.

Во время добавления кластера-члена в набор кластеров можно указать имя SOFS инфраструктуры в этом кластере, если он уже существует. Если инфраструктура SOFS не существует, создается новая роль SOFS инфраструктуры в новом кластере-члене. Если роль SOFS инфраструктуры уже существует в кластере-члене, операция добавления неявно переименовывает ее в указанное имя по мере необходимости. Все существующие серверы S МБ или роли SOFS, отличные от инфраструктуры, в кластерах-членах, не используются набором кластеров.

При создании набора кластеров можно использовать существующий объект компьютера AD в качестве корневого каталога пространства имен в кластере управления. Создание набора кластеров создает роль кластера SOFS инфраструктуры в кластере управления или переименовывает существующую роль SOFS инфраструктуры. Инфраструктура SOFS в кластере управления используется в качестве реферала пространства имен кластера SOFS.

Создание доменов сбоя и групп доступности

Домены сбоя Azure и группы доступности можно настроить в наборе кластеров. Это полезно для первоначального размещения виртуальных машин и миграции между кластерами.

В приведенном ниже примере имеется четыре кластера в наборе кластеров. В наборе создается один домен сбоя с двумя кластерами, а второй домен сбоя создается с двумя другими кластерами. Эти два домена сбоя составляют группу доступности.

В приведенном ниже примере CLUSTER1 и CLUSTER2 находятся в домене сбоя FD1 и CLUSTER3 и CLUSTER4 находятся в домене сбоя FD2. Группа доступности — CSMASTER-AS.

Чтобы создать домены сбоя, выполните следующие команды:

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

Чтобы убедиться, что они были успешно созданы, Get-ClusterSetFaultDomain можно запустить с его выходными данными, отображаемыми для FD1:

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

Теперь, когда были созданы домены сбоя, создается группа доступности:

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

Чтобы проверить его, используйте:

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

При создании новых виртуальных машин используйте -AvailabilitySet параметр, чтобы определить оптимальный узел для размещения. Приведем пример:

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

Удаление кластера из набора

Существует время, когда кластеру необходимо удалить из набора кластеров. Рекомендуется переместить все виртуальные машины набора кластеров из кластера заранее. Это можно сделать с помощью Move-ClusterSetVM команд и Move-VMStorage команд.

Если виртуальные машины не перемещены из кластера, все остальные виртуальные машины, размещенные на удаленном кластере, станут высокодоступными виртуальными машинами, связанными с этим кластером, при условии, что у них есть доступ к хранилищу. Наборы кластеров также автоматически обновляют их инвентаризацию, не отслеживая работоспособность удаленного кластера и виртуальных машин, работающих на нем, а также путем удаления пространства имен и всех ссылок на общие папки, размещенные в удаленном кластере.

Например, команда удаления кластера CLUSTER1 из набора кластеров:

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Резервная копия состояния системы

Резервное копирование состояния системы будет выполнять резервное копирование состояния кластера и метаданных. С помощью резервного копирования Windows Server можно восстановить только базу данных кластера узла при необходимости или выполнить авторитетное восстановление для отката всей базы данных кластера на всех узлах. Для наборов кластеров рекомендуется сначала выполнить авторитетное восстановление для кластеров-членов, а затем для кластера управления. Дополнительные сведения о резервном копировании состояния системы см. в статье "Резервное копирование состояния системы" и "Без операционной системы".

Следующие шаги

Дополнительные сведения о реплике служба хранилища.