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

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

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

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

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

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

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

Восстановление рабочего процесса сервера

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

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

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

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

2. Повторное управление сервером, который необходимо восстановить.

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

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

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

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

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

Внимание

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

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

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

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

Требования к аппаратному обеспечению

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

Необходимые компоненты

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

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

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

  • Убедитесь, что сервер работоспособен перед его отключением в автономном режиме.
  • Приостановка и очистка сервера.
  • Завершите работу сервера.

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

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

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

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

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

   Примечание.

   Если кластер использует выделенное намерение ATC сети для хранения, и вы используете пользовательские IP-адреса хранилища, необходимо настроить IP-адреса на сетевых адаптерах хранилища перед выполнением операции Repair-Server. Если кластер использует намерение ATC общей сети для хранения и другого типа трафика, например вычислений и управления, необходимо вручную настроить IP-адреса на виртуальных сетевых адаптерах хранилища после восстановления сервера.

2. Зарегистрируйте сервер с помощью Arc. Выполните действия, описанные в разделе "Регистрация с помощью Arc", и настройте разрешения.

   Примечание.

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

3. Назначьте следующие разрешения восстановленным узлу:

   • Роль Управление устройствами Azure Stack HCI
   • Дополнительные сведения см. в разделе "Назначение разрешений для сервера".

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

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

    Update-AuthenticationToken
   

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

   $Cred = Get-Credential 
   Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred
   

   Примечание.

   Имя сервера должно быть именем NetBIOS.

3. Запишите идентификатор операции в качестве выходных Repair-Server данных команды. Это можно использовать позже для отслеживания Repair-Server хода выполнения операции.

Примечание.

При развертывании кластера Azure Stack HCI с помощью пользовательских IP-адресов хранилища необходимо вручную назначить IP-адреса сетевым адаптерам хранилища после восстановления сервера.

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

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

1. Выполните следующий командлет и укажите идентификатор операции из предыдущего шага.

   $ID = "<Operation ID>" 
   Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID 
   

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

   Get-VirtualDisk|Get-StorageJob
   

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

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

Следующие сценарии восстановления и рекомендуемые шаги по устранению рисков табуляции для восстановления сервера:

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

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

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

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

  Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
  

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

  Repair-Server -Rerun
  

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

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