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

2023-10-06
Применяется к: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

Применимо к: Windows Server 2019

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

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

Преимущества

Кластерные наборы обладают следующими преимуществами:

Значительно увеличивает поддерживаемое масштабирование облака программно-определяемого ЦОД для запуска высокодоступных виртуальных машин (ВМ) за счет объединения нескольких небольших кластеров в одну большую структуру, сохраняя при этом границу программных сбоев в одном кластере. Вы можете легко переносить виртуальные машины в кластере.
Повышенная отказоустойчивость. Наличие четырех кластеров с 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) пространства имен для набора кластеров. Кластер управления логически отделен от отдельных кластеров-членов, в которых выполняются рабочие нагрузки виртуальных машин. Это делает плоскость управления набором кластеров устойчивой к любым локализованным сбоям на уровне кластера, таким как потеря питания кластера-члена.

Кластер набора имен ссылается на SOFS

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

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

Мастер набора кластеров

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

Членский кластер

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

Набор кластеров Worker

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

Домен сбоя

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

Набор доступности

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

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

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

Имя кластера	Наименование СОФС инфраструктуры
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Используйте клиентский компьютер управления под управлением Windows Server 2022 или Windows Server 2019.
Установите средства отказоустойчивого кластера на сервере кластера управления.
Создайте двух участников кластера с не менее чем двумя общими томами кластера (CSV) в каждом кластере.
Создайте кластер управления (физический или гостевый), который будет находиться между кластерами-участниками. Это гарантирует, что плоскость управления набором кластеров будет оставаться доступной, несмотря на возможные сбои кластера-члена.
Чтобы создать кластерный набор, выполните следующие действия.
```
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
```
Чтобы убедиться, что набор кластера содержит одну общую папку SMB (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, см. Move-VMStorage.

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

Set-VMHost -UseAnyNetworkForMigration $true

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

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

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

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

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

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

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

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

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

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

После создания набора кластеров можно использовать существующий объект компьютера AD в качестве корня пространства имен в кластере управления. При создании набора кластеров создается роль кластера Infrastructure SOFS в кластере управления или переименовывается существующая роль Infrastructure 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)

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

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

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

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

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

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

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

Дальнейшие шаги

Узнайте больше о Storage Replica (реплике хранилища).