Восстановление сервера в Azure Stack HCI версии 23H2

Статья
02/26/2024

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

В этой статье описывается восстановление сервера в кластере Azure Stack HCI.

Сведения о серверах восстановления

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

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

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

Рабочий процесс восстановления сервера

На следующей схеме потоков показан общий процесс восстановления сервера.

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

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

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

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

Поддерживаемые сценарии

Восстановление сервера приводит к повторному просмотру образа сервера и его возврату в кластер с предыдущим именем и конфигурацией.

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

Важно!

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

Параметры устойчивости

В этом выпуске для восстановления сервера определенные задачи не выполняются на томах рабочей нагрузки, созданных после развертывания. Для восстановления сервера только необходимые тома инфраструктуры и тома рабочей нагрузки восстанавливаются и отображаются в качестве общих томов кластера (CSV).

Другие тома рабочей нагрузки, созданные после развертывания, по-прежнему сохраняются, и их можно обнаружить, выполнив Get-VirtuaDisk командлет . Вам потребуется вручную разблокировать том (если на томе включен BitLocker) и создать CSV-файл (при необходимости).

Требования к оборудованию

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

Компонент	Проверка проверка
ЦП	Убедитесь, что новый сервер имеет одинаковое количество ядер ЦП или более. Если ядра ЦП на входящем узле не соответствуют этому требованию, отображается предупреждение. Однако операция разрешена.
Память	Убедитесь, что на новом сервере установлен тот же объем памяти или больше. Если память на входящем узле не соответствует этому требованию, выводится предупреждение. Однако операция разрешена.
Диски	Убедитесь, что на новом сервере имеется одинаковое количество дисков с данными, доступных для Локальные дисковые пространства. Если количество дисков на входящем узле не соответствует этому требованию, сообщается об ошибке, а операция блокируется.

Замена сервера

Вы можете заменить весь сервер:

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

Во время замены сервера поддерживаются следующие сценарии:

Сервер	Диск	Поддерживаются
Новый сервер	Новые диски	Да
Новый сервер	Текущие диски	Да
Текущий сервер (переосмыслено)	Текущие диски переформатированы *	Нет
Текущий сервер (переосмыслено)	Новые диски	Да
Текущий сервер (переосмыслено)	Текущие диски	Да

**Диски, которые использовались Локальные дисковые пространства, требуют надлежащей очистки. Переформатирования недостаточно. Узнайте, как очистить диски.

Важно!

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

Процесс замены компонентов

В кластере Azure Stack HCI компоненты без горячей замены включают следующие элементы:

системная плата, контроллер управления основной платой (BMC), видеоконтроллер;
Контроллер диска или адаптер шины узла (HBA)/backplace
Сетевой адаптер
Единица обработки графики
диски данных (диски, которые не поддерживают оперативную замену, например платы расширения PCI-e).

Фактические шаги по замене компонентов без горячей замены зависят от поставщика оборудования изготовителя оборудования (OEM). Если требуется ремонт сервера для компонентов без горячей замены, ознакомьтесь с документацией поставщика oem.

Предварительные требования

Перед восстановлением сервера необходимо убедиться в том, что:

AzureStackLCMUser активен в Active Directory. Дополнительные сведения см. в статье Подготовка Active Directory.
Войдите в систему от имени AzureStackLCMUser или другого пользователя с эквивалентными разрешениями.
Учетные данные для AzureStackLCMUser не изменились.

При необходимости переведите определенный сервер для восстановления в автономный режим. Выполните указанные ниже действия.

Восстановить сервер

В этом разделе описывается, как восстановить сервер с помощью PowerShell, отслеживать состояние Repair-Server операции и устранять неполадки.

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

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

Установите операционную систему и необходимые драйверы. Выполните действия, описанные в статье Установка операционной системы Azure Stack HCI версии 23H2.

Примечание

Также необходимо установить необходимые роли Windows.
Зарегистрируйте сервер с помощью Arc. Выполните действия, описанные в разделе Регистрация в Arc и настройка разрешений.

Примечание

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

Выполните следующие действия на другом сервере, который входит в тот же кластер Azure Stack HCI.

Перед добавлением сервера обязательно получите обновленный маркер проверки подлинности. Выполните следующую команду:
```
 Update-AuthenticationToken
```
Войдите на сервер, который уже является членом кластера, с учетными данными пользователя домена, указанными во время развертывания кластера. Выполните следующую команду, чтобы восстановить сервер входящей почты:
```
$Cred = Get-Credential 
Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred
```
Запишите идентификатор операции в качестве выходных данных командой Repair-Server . Позже вы используете его для отслеживания хода выполнения Repair-Server операции.

Мониторинг хода выполнения операции

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

Выполните следующий командлет и укажите идентификатор операции из предыдущего шага.
```
$ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID 
```
После завершения операции задание перебалансирования фонового хранилища продолжит выполняться. Дождитесь завершения задания повторного балансировки хранилища. Чтобы проверить ход выполнения этого задания перебалансирования хранилища, используйте следующий командлет:
```
Get-VirtualDisk|Get-StorageJob
```
Если задание перераспределения хранилища завершено, командлет не вернет выходные данные.

Сценарии восстановления

Для восстановления сервера приведены следующие сценарии восстановления и рекомендуемые действия по устранению рисков:

Описание сценария	Меры по снижению риска	Поддержка
Операция восстановления сервера завершилась сбоем.	Чтобы завершить операцию, изучите сбой. Повторно запустите неудачную операцию с помощью `Add-Server -Rerun`.	Да
Восстановление операции сервера выполнено частично, но пришлось начать с новой установки операционной системы.	В этом сценарии оркестратор (также известный как Lifecycle Manager) уже обновил свое хранилище знаний новым сервером. Используйте сценарий сервера восстановления.	Да

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

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

Войдите с учетными данными пользователя домена, указанными во время развертывания кластера. Запишите проблему в файлах журнала.
```
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
```
Чтобы повторно выполнить неудачную операцию, используйте следующий командлет:
```
Repair-Server -Rerun
```

Дальнейшие действия

Узнайте больше о том, как добавить сервер.