Создание кластера Azure Stack HCI с помощью Windows PowerShell

Область применения: Azure Stack HCI версии 22H2

Предупреждение

Инструкции по развертыванию, приведенные в этой статье, относятся к старой версии Azure Stack HCI версии 22H2. Для новых развертываний рекомендуется использовать последнюю общедоступную версию Azure Stack HCI версии 23H2. Инструкции по развертыванию см. в статье о развертывании Azure Stack HCI версии 23H2.

В этой статье вы узнаете, как использовать Windows PowerShell для создания гиперконвергентного кластера Azure Stack HCI, использующего Локальные дисковые пространства. Если вы предпочитаете использовать мастер создания кластера в Windows Admin Center для создания кластера, см. статью "Создание кластера с помощью Центра администрирования Windows".

Примечание.

Если вы выполняете установку одного сервера Azure Stack HCI 21H2, используйте PowerShell для создания кластера.

У вас есть выбор между двумя типами кластеров:

• Стандартный кластер с одним или двумя узлами сервера, которые находятся на одном сайте.
• Растянутый кластер с по крайней мере четырьмя узлами сервера, охватывающими два сайта, с двумя узлами на сайт.

Для сценария с одним сервером выполните те же инструкции для одного сервера.

Примечание.

Кластеры Stretch не поддерживаются в одной конфигурации сервера.

В этой статье мы создадим пример кластера с именем Cluster1, состоящий из четырех узлов сервера с именем Server1, Server2, Server3 и Server4.

Для сценария растянутого кластера мы используем ClusterS1 в качестве имени и используем те же четыре узла сервера, растянутые на сайтах Site1 и Site2.

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

Чтобы протестировать Azure Stack HCI с минимальным или без дополнительного оборудования, вы можете ознакомиться с руководством по оценке Azure Stack HCI. В этом руководстве описано, как испытать Azure Stack HCI с помощью вложенной виртуализации на виртуальной машине Azure. Или попробуйте создать лабораторию на основе виртуальных машин для Azure Stack HCI , чтобы создать собственную частную лабораторию с помощью вложенной виртуализации на сервере выбранного сервера для развертывания виртуальных машин под управлением Azure Stack HCI для кластеризации.

Подготовка к работе

Прежде чем начать, убедитесь, что вы:

• Чтение и понимание требований к системе Azure Stack HCI.
• Чтение и понимание требований к физической сети и требований к сети узла для Azure Stack HCI.
• Установите ОС Azure Stack HCI на каждом сервере в кластере. См. статью "Развертывание операционной системы Azure Stack HCI".
• Убедитесь, что все серверы находятся в правильном часовом поясе.
• У вас есть учетная запись, которая входит в группу локальных администраторов на каждом сервере.
• У вас есть права на создание объектов в Active Directory.
• Для растянутых кластеров настройте два сайта заранее в Active Directory.

Использование Windows PowerShell

PowerShell можно запустить локально в сеансе RDP на хост-сервере или удаленно запустить PowerShell с компьютера управления. В этой статье рассматривается удаленный параметр.

При запуске PowerShell с компьютера управления включите -Name или -Cluster параметр с именем сервера или кластера, которым вы управляете. Кроме того, может потребоваться указать полное доменное имя (FQDN) при использовании -ComputerName параметра для узла сервера.

Вам нужны командлеты средств удаленного администрирования сервера (RSAT) и модули PowerShell для кластеризации Hyper-V и отработки отказа. Если командлеты и модули еще не доступны в сеансе PowerShell на компьютере управления, их можно добавить с помощью следующей команды: Add-WindowsFeature RSAT-Clustering-PowerShell

Шаг 1. Настройка серверов

Сначала подключитесь к каждому из серверов, присоедините их к домену (тот же домен, в который находится компьютер управления), а также установите необходимые роли и компоненты.

Шаг 1.1. Подключение к серверам

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

Откройте PowerShell и используйте полное доменное имя или IP-адрес сервера, к которому вы хотите подключиться. После выполнения следующей команды на каждом сервере появится запрос на ввод пароля.

В этом примере предполагается, что серверы называются Server1, Server2, Server3 и Server4:

Enter-PSSession -ComputerName "Server1" -Credential "Server1\Administrator"

Вот еще один пример выполнения того же действия:

$myServer1 = "Server1"
$user = "$myServer1\Administrator"

Enter-PSSession -ComputerName $myServer1 -Credential $user

Совет

При выполнении команд PowerShell на компьютере управления может возникнуть ошибка, например WinRM, не может обработать запрос. Чтобы устранить эту проблему, используйте PowerShell для добавления каждого сервера в список надежных узлов на компьютере управления. Этот список поддерживает подстановочные знаки, например Server* .

Set-Item WSMAN:\Localhost\Client\TrustedHosts -Value Server1 -Force

Чтобы просмотреть список надежных узлов, введите Get-Item WSMAN:\Localhost\Client\TrustedHosts.

Чтобы очистить список, введите Clear-Item WSMAN:\Localhost\Client\TrustedHost.

Шаг 1.2. Присоединение к домену и добавление учетных записей домена

На предыдущем шаге, подключенном к каждому узлу сервера, с учетной записью <ServerName>\Administratorлокального администратора.

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

Enter-PSSession Используйте командлет для подключения к каждому серверу и выполните следующий командлет, заменив имя сервера, доменное имя и учетные данные домена:

Add-Computer -NewName "Server1" -DomainName "contoso.com" -Credential "Contoso\User" -Restart -Force  

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

Add-LocalGroupMember -Group "Administrators" -Member "king@contoso.local"

Шаг 1.3. Установка ролей и компонентов

Следующим шагом является установка необходимых ролей и компонентов Windows на каждом сервере кластера. Ниже приведены роли для установки:

• BitLocker
• Data Center Bridging
• Отказоустойчивая кластеризация
• Файловый сервер
• Модуль дедупликации FS-Data-Deduplication
• Hyper-V
• PowerShell для Hyper-V
• Модуль RSAT-Clustering-PowerShell
• Модуль RSAT-AD-PowerShell
• NetworkATC
• NetworkHUD
• Ограничение пропускной способности SMB
• Реплика хранилища (для растянутых кластеров)

Используйте следующую команду для каждого сервера (если вы подключены через удаленный рабочий стол, опустите -ComputerName параметр здесь и в последующих командах):

Install-WindowsFeature -ComputerName "Server1" -Name "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "FS-SMBBW", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "NetworkHUD", "Storage-Replica" -IncludeAllSubFeature -IncludeManagementTools

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

# Fill in these variables with your values
$ServerList = "Server1", "Server2", "Server3", "Server4"
$FeatureList = "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "NetworkHUD", "FS-SMBBW", "Storage-Replica"

# This part runs the Install-WindowsFeature cmdlet on all servers in $ServerList, passing the list of features in $FeatureList.
Invoke-Command ($ServerList) {
    Install-WindowsFeature -Name $Using:Featurelist -IncludeAllSubFeature -IncludeManagementTools
}

Затем перезапустите все серверы:

$ServerList = "Server1", "Server2", "Server3", "Server4"
Restart-Computer -ComputerName $ServerList -WSManAuthentication Kerberos

Шаг 2. Подготовка к настройке кластера

Затем убедитесь, что серверы готовы к кластеризации.

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

Используется Get-ClusterNode для отображения всех узлов:

Get-ClusterNode

Используется Get-ClusterResource для отображения всех узлов кластера:

Get-ClusterResource

Используется Get-ClusterNetwork для отображения всех сетей кластера:

Get-ClusterNetwork

Шаг 2.1. Подготовка дисков

Перед включением Локальные дисковые пространства убедитесь, что постоянные диски пусты. Выполните следующий скрипт, чтобы удалить старые секции и другие данные.

Примечание.

Исключите из скрипта все съемные диски, подключенные к узлу сервера. Если вы запускаете этот скрипт локально, например из узла сервера, вы можете не захотеть очищать съемный диск, который может использоваться для развертывания кластера.

# Fill in these variables with your values
$ServerList = "Server1", "Server2", "Server3", "Server4"

Invoke-Command ($ServerList) {
    Update-StorageProviderCache
    Get-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -ErrorAction SilentlyContinue
    Get-StoragePool | ? IsPrimordial -eq $false | Get-VirtualDisk | Remove-VirtualDisk -Confirm:$false -ErrorAction SilentlyContinue
    Get-StoragePool | ? IsPrimordial -eq $false | Remove-StoragePool -Confirm:$false -ErrorAction SilentlyContinue
    Get-PhysicalDisk | Reset-PhysicalDisk -ErrorAction SilentlyContinue
    Get-Disk | ? Number -ne $null | ? IsBoot -ne $true | ? IsSystem -ne $true | ? PartitionStyle -ne RAW | % {
        $_ | Set-Disk -isoffline:$false
        $_ | Set-Disk -isreadonly:$false
        $_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false
        $_ | Set-Disk -isreadonly:$true
        $_ | Set-Disk -isoffline:$true
    }
    Get-Disk | Where Number -Ne $Null | Where IsBoot -Ne $True | Where IsSystem -Ne $True | Where PartitionStyle -Eq RAW | Group -NoElement -Property FriendlyName
} | Sort -Property PsComputerName, Count

Шаг 2.2. Проверка конфигурации кластера

На этом шаге убедитесь, что узлы сервера настроены правильно для создания кластера. Командлет Test-Cluster используется для выполнения тестов, чтобы проверить, подходит ли конфигурация в качестве гиперконвергентного кластера. В следующем примере используется -Include параметр с определенными категориями тестов, чтобы убедиться, что правильные тесты включены в проверку.

Test-Cluster -Node $ServerList -Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"

Шаг 3. Создание кластера

Теперь вы готовы создать кластер с узлами сервера, проверенными на предыдущих шагах.

При создании кластера может появиться предупреждение о том, что вы "There were issues while creating the clustered role that may prevent it from starting. For more information, view the report file below." можете безопасно игнорировать это предупреждение. Это предупреждение связано с отсутствием дисков, доступных для свидетеля кластера. Свидетель кластера создается на последующих шагах.

Примечание.

Если серверы используют статические IP-адреса, измените следующую команду, чтобы отразить статический IP-адрес, добавив следующий параметр и указав IP-адрес: -StaticAddress <X.X.X.X>;

$ClusterName="cluster1" 
New-Cluster -Name $ClusterName –Node $ServerList –nostorage

После создания кластера может потребоваться некоторое время для репликации имени кластера через DNS в домене, особенно если серверы рабочей группы добавляются в Active Directory. Хотя кластер может отображаться в Windows Admin Center, он может быть недоступен для подключения.

Убедитесь, что все ресурсы кластера находятся в сети:

Get-Cluster -Name $ClusterName | Get-ClusterResource

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

Шаг 4. Настройка сети узлов

Корпорация Майкрософт рекомендует использовать Network ATC для развертывания сетей узлов, если вы используете Azure Stack HCI версии 21H2 или более поздней. В противном случае ознакомьтесь с требованиями к сети узла для конкретных требований и сведений.

Сетевой ATC может автоматизировать развертывание предполагаемой конфигурации сети, если указать один или несколько типов намерений для адаптеров. Дополнительные сведения о конкретных типах намерений см. в статье " Типы сетевого трафика".

Шаг 4.1. Просмотр физических адаптеров

На одном из узлов кластера выполните проверку Get-NetAdapter физических адаптеров. Убедитесь, что каждый узел в кластере имеет те же именованные физические адаптеры, что и состояние "Вверх".

Get-NetAdapter -Name pNIC01, pNIC02 -CimSession $ClusterName | Select Name, PSComputerName

Если имя физического адаптера зависит от узлов в кластере, его можно переименовать с помощью Rename-NetAdapter.

Rename-NetAdapter -Name oldName -NewName newName

Шаг 4.2. Настройка намерения

В этом примере создается намерение, указывающее намерение вычислений и хранилища. Дополнительные примеры намерений см. в статье "Упрощение сети узлов с помощью ATC сети".

Выполните следующую команду, чтобы добавить типы намерений хранилища и вычислений в pNIC01 и pNIC02. Обратите внимание, что мы указываем -ClusterName параметр.

Add-NetIntent -Name Cluster_ComputeStorage -Compute -Storage -ClusterName $ClusterName -AdapterName pNIC01, pNIC02

Команда должна немедленно вернуться после первоначальной проверки.

Шаг 4.3. Проверка развертывания намерения

Get-NetIntent Запустите командлет, чтобы просмотреть намерение кластера. Если у вас несколько намерений, можно указать Name параметр, чтобы просмотреть сведения только о конкретном намерении.

Get-NetIntent -ClusterName $ClusterName

Чтобы просмотреть состояние подготовки намерения, выполните Get-NetIntentStatus команду:

Get-NetIntentStatus -ClusterName $ClusterName -Name Cluster_ComputeStorage

Обратите внимание на параметр состояния, показывающий подготовку, проверку, успешность, сбой.

Состояние должно отображаться в течение нескольких минут. Если состояние успешного выполнения не происходит или отображается сбой параметра состояния, проверьте средство просмотра событий на наличие проблем.

Примечание.

В настоящее время сетевой ATC не настраивает IP-адреса для любого из управляемых адаптеров. После Get-NetIntentStatus завершения состояния отчетов необходимо добавить IP-адреса в адаптеры.

Шаг 5. Настройка сайтов (растянутый кластер)

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

Примечание.

Если вы заранее настроили сайты и службы Active Directory, вам не нужно создавать сайты вручную, как описано в следующем разделе.

Шаг 5.1. Создание сайтов

В следующем командлете ОшибкаDomain — это просто другое имя сайта. В этом примере в качестве имени растянутого кластера используется ClusterS1.

New-ClusterFaultDomain -CimSession $ClusterName -FaultDomainType Site -Name "Site1"

New-ClusterFaultDomain -CimSession $ClusterName -FaultDomainType Site -Name "Site2"

Get-ClusterFaultDomain Используйте командлет, чтобы убедиться, что оба сайта созданы для кластера.

Get-ClusterFaultDomain -CimSession $ClusterName

Шаг 5.2. Назначение узлов сервера

Затем мы назначаем четыре узла сервера соответствующим сайтам. В следующем примере сервер1 и сервер2 назначены сайту Site1, а Сервер3 и Server4 назначены сайту Site2.

Set-ClusterFaultDomain -CimSession $ClusterName -Name "Server1", "Server2" -Parent "Site1"

Set-ClusterFaultDomain -CimSession $ClusterName -Name "Server3", "Server4" -Parent "Site2"

С помощью командлета Get-ClusterFaultDomain убедитесь, что узлы находятся на правильных сайтах.

Get-ClusterFaultDomain -CimSession $ClusterName

Шаг 5.3. Настройка предпочтительного сайта

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

(Get-Cluster).PreferredSite = "Site1"

Указание предпочтительного сайта для растянутых кластеров имеет следующие преимущества:

• Холодный запуск — во время холодного запуска виртуальные машины размещаются на предпочтительном сайте.

• Голосование кворума

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

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

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

Шаг 5.4. Настройка растянутой кластеризации с помощью Сетевого ATC

После версии 22H2 можно использовать Сетевой ATC для настройки кластеризации Stretch. Network ATC добавляет Stretch в качестве типа намерения из версии 22H2. Чтобы развернуть намерение с помощью stretch clustering с помощью Network ATC, выполните следующую команду:

Add-NetIntent -Name StretchIntent -Stretch -AdapterName "pNIC01", "pNIC02"

Намерение stretch также можно объединить с другими намерениями при развертывании с помощью Сетевого ATC.

SiteOverrides

На основе шагов 5.1-5.3 вы можете добавить предварительно созданные сайты в намерение stretch, развернутое с помощью Сетевого ATC. Сетевой ATC обрабатывает это с помощью SiteOverrides. Чтобы создать SiteOverride, выполните следующую команду:

 $siteOverride = New-NetIntentSiteOverrides

После создания siteOverride можно задать любое свойство для siteOverride. Убедитесь, что свойство name объекта siteOverride имеет то же имя, что и имя сайта в ClusterFaultDomain. Несоответствие имен между ClusterFaultDomain и siteOverride приводит к тому, что siteOverride не применяется.

Свойства, которые можно задать для конкретного сайтаOverride: Name, StorageVlan и StretchVlan. Например, вы создадите 2 siteOverrides для двух сайтов — site1 и site2, используя следующее:

$siteOverride1 = New-NetIntentSiteOverrides
$siteoverride1.Name = "site1"
$siteOverride1.StorageVLAN = 711
$siteOverride1.StretchVLAN = 25

$siteOverride2 = New-NetIntentSiteOverrides
$siteOverride2.Name = "site2"
$siteOverride2.StorageVLAN = 712
$siteOverride2.StretchVLAN = 26

Вы можете запустить $siteOverride1в $siteOverride2 окне PowerShell, чтобы убедиться, что все свойства заданы соответствующим образом.

Наконец, чтобы добавить один или несколько siteOverrides в намерение, выполните следующую команду:

Add-NetIntent -Name StretchIntent -Stretch -AdapterName "pNIC01" , "pNIC02" -SiteOverrides $siteOverride1, $siteOverride2

Шаг 6. Включение Локальные дисковые пространства

После создания кластера используйте Enable-ClusterStorageSpacesDirect командлет, который включает Локальные дисковые пространства и выполняет следующие действия автоматически.

• Создайте пул носителей: создает пул носителей для кластера, который имеет имя, например "Пул носителей Cluster1".

• Создайте диск журнала производительности кластера: создает виртуальный диск журнала производительности кластера в пуле носителей.

• Создание томов данных и журналов. Создает том данных и том журнала в пуле носителей.

• Настройка кэшей Локальные дисковые пространства. Если для Локальные дисковые пространства доступно несколько типов носителей (дисков), это позволяет быстрее всего использовать устройства кэша (чтение и запись в большинстве случаев).

• Создание уровней: создает два уровня в качестве уровней по умолчанию. Один из них называется "Емкость", а другой — "Производительность". Командлет анализирует устройства и настраивает каждый уровень на основе типов устройств и устойчивости.

Для сценария с одним сервером единственным параметром FaultDomainAwarenessDefault является PhysicalDisk. Enable-ClusterStorageSpacesDirect командлет обнаруживает один сервер и автоматически настраивает FaultDomainAwarenessDefault в качестве физическогоDisk во время включения.

Для растянутых кластеров Enable-ClusterStorageSpacesDirect командлет также:

• Проверьте, настроены ли сайты
• Определение узлов, на которых находятся сайты
• Определяет, какое хранилище доступно каждому узлу
• Проверяет, установлена ли функция реплики хранилища на каждом узле
• Создает пул носителей для каждого сайта и идентифицирует его с именем сайта.
• Создание томов данных и журналов в каждом пуле носителей — по одному на сайт

Следующая команда включает Локальные дисковые пространства в кластере с несколькими узлами. Вы также можете указать понятное имя пула носителей, как показано ниже.

Enable-ClusterStorageSpacesDirect -PoolFriendlyName "$ClusterName Storage Pool" -CimSession $ClusterName

Ниже приведен пример отключения кэша хранилища в кластере с одним узлом:

Enable-ClusterStorageSpacesDirect -CacheState Disabled

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

Get-StoragePool -CimSession $ClusterName

После создания кластера

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

• Настройте свидетель кластера, если вы используете двухузловой или более крупный кластер. См. статью "Настройка свидетеля кластера".
• Создайте тома. См. раздел "Создание томов". При создании томов в кластере с одним узлом необходимо использовать PowerShell. См. статью "Создание томов с помощью PowerShell".
• Для растянутых кластеров создайте тома и настройте репликацию с помощью реплики хранилища. См. статью "Создание томов" и настройка репликации для растянутых кластеров.

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

• Зарегистрируйте кластер в Azure. См. статью "Подключение Azure Stack HCI к Azure".
• Выполните окончательную проверку кластера. См. статью " Проверка кластера Azure Stack HCI"
• Управление сетями узлов. См. раздел "Управление сетями узла с помощью ATC сети".