Восстановление узла в локальной среде Azure
Область применения: Azure Local 2311.2 и более поздних версий
В этой статье описывается восстановление узла в локальном экземпляре Azure. В этой статье каждый сервер называется узлом.
Сведения о ремонтных узлах
Локальная служба Azure — это гиперконвергентная система, которая позволяет восстанавливать узлы из существующих систем. Возможно, потребуется восстановить узел в системе, если произошел сбой оборудования.
Прежде чем провести ремонт узла, уточните у поставщика решений, какие компоненты узла являются заменяемыми запасными частями, которые можно заменить самостоятельно, а для замены каких компонентов потребуется технический специалист.
Части, поддерживающие горячую замену, обычно не требуют повторного создания образа узла, в отличие от компонентов, таких как материнская плата, которые не поддерживают горячую замену. Обратитесь к изготовителю оборудования, чтобы определить, какие замены компонентов потребуют повторного создания образа узла. Дополнительные сведения см. в разделе "Замена компонентов".
Восстановление рабочего процесса узла
На следующей схеме потока показан общий процесс восстановления узла.
*Узел может не находиться в состоянии, когда завершение работы возможно или необходимо*
Чтобы восстановить существующий узел, выполните следующие высокоуровневые действия.
По возможности отключите узел, который требуется восстановить. В зависимости от состояния узла завершение работы может быть невозможным или ненужным.
Повторное управление узлом, который необходимо восстановить.
Выполните операцию восстановления узла. Операционная система Azure Stack HCI, драйверы и встроенное ПО обновляются в рамках операции восстановления.
Хранилище автоматически перебалансируется на восстановленном узле. Перебалансация хранилища — это задача с низким приоритетом, которая может выполняться в течение нескольких дней в зависимости от количества узлов и используемого хранилища.
Поддерживаемые сценарии
Повторное создание образа узла восстанавливает его и возвращает в систему с прежним именем и конфигурацией.
Восстановление одного узла приводит к повторному развертыванию с возможностью сохранения томов данных. Только системный том удаляется и подготавливается во время развертывания.
Внимание
Убедитесь, что у вас всегда есть резервные копии для рабочих нагрузок и не зависят только от устойчивости системы. Это особенно важно в сценариях с одним узлом.
Параметры устойчивости
В этом выпуске для операции восстановления узла определенные задачи не выполняются в томах рабочей нагрузки, которые были созданы после развертывания. Для операции восстановления узла только необходимые тома инфраструктуры и тома рабочей нагрузки восстанавливаются и отображаются как общие тома кластера (CSVs).
Остальные тома рабочей нагрузки, которые вы создали после развертывания, остаются доступными, и их можно обнаружить, выполнив командлет Get-VirtualDisk
. Вам потребуется вручную разблокировать том (если том включен BitLocker) и создать CSV-файл (при необходимости).
Требования к аппаратному обеспечению
При восстановлении узла система проверяет оборудование нового, входящего узла и гарантирует, что узел соответствует требованиям к оборудованию, прежде чем он будет добавлен в систему.
Компонент | Проверка соответствия требованиям |
---|---|
ЦП | Проверка того, что новый узел имеет одинаковое количество ядер ЦП или более. Если ядра ЦП на входящего узла не соответствуют этому требованию, появится предупреждение. Однако операция разрешена. |
Память | Убедитесь, что новый узел имеет тот же объем или больше памяти. Если память на входящем узле не соответствует этому требованию, появится предупреждение. Однако операция разрешена. |
Диски | Убедитесь, что новый узел имеет такое же количество дисков данных, доступных для Локальные дисковые пространства Direct. Если количество дисков на входящем узле не соответствует этому требованию, сообщается об ошибке и операция блокируется. |
Замена узла
Вы можете заменить весь узел:
- С новым узлом, который имеет другой серийный номер по сравнению со старым узлом.
- С текущим узлом после того, как вы его пересоздаёте.
Во время замены узла поддерживаются следующие сценарии:
Node | Диск | Поддерживается |
---|---|---|
Новый узел | Новые диски | Да |
Новый узел | Текущие диски | Да |
Текущий узел (переимыслить) | Текущие диски переформатированы ** | Нет |
Текущий узел (переимыслить) | Новые диски | Да |
Текущий узел (переимыслить) | Текущие диски | Да |
Диски, которые использовались в технологии Storage Spaces Direct, требуют правильной очистки. Переформатирование недостаточно. Узнайте, как очистить диски.
Внимание
При замене компонента во время восстановления узла не требуется заменить или сбросить диски данных. Если вы замените жёсткий диск или сбросите его, то он не будет распознаваться после подключения узла к системе.
Процесс замены компонентов
В локальном экземпляре Azure компоненты, не поддерживающие горячее переключение, включают следующие элементы:
- системная плата, контроллер управления основной платой (BMC), видеоконтроллер;
- Контроллер диска/адаптер шины хоста (HBA)/подложка
- Сетевой адаптер
- Единица обработки графики
- диски данных (диски, которые не поддерживают оперативную замену, например платы расширения PCI-e).
Фактические действия по замене компонентов, не поддерживающих горячую замену, зависят от поставщика вашего оригинального оборудования (OEM). Ознакомьтесь с документацией вашего поставщика OEM, если для компонентов, не поддерживающих горячую замену, требуется ремонт узла.
Предпосылки
Перед восстановлением узла необходимо убедиться в том, что:
-
AzureStackLCMUser
активен в Active Directory. Дополнительные сведения см. в статье "Подготовка Active Directory". - Войдите как
AzureStackLCMUser
или другой пользователь с эквивалентными разрешениями. - Учетные данные для
AzureStackLCMUser
не изменились.
При необходимости переведите узел, который вы определили для восстановления, в автономный режим. Выполните следующие действия.
Восстановление узла
В этом разделе описывается, как восстановить узел с помощью PowerShell, отслеживать состояние Repair-Server
операции и устранять неполадки, если возникли проблемы.
Убедитесь, что вы проверили предварительные требования.
Выполните следующие действия на узле, который вы пытаетесь восстановить.
Войдите на портал Azure с разрешениями администратора Azure Stack HCI.
Перейдите в группу ресурсов, используемую для развертывания локального экземпляра Azure. В группе ресурсов определите ресурс компьютера Azure Arc для неисправного узла, который требуется восстановить.
В ресурсах машины Azure Arc перейдите к Параметры > Замки. На правой панели отображается блокировка ресурсов.
Выберите блокировку, а затем щелкните значок корзины, чтобы удалить блокировку.
На странице Обзор ресурса машины Azure Arc в правой области выберите Удалить. Это действие должно удалить неисправный узел компьютера.
Установите операционную систему и необходимые драйверы на узле, который вы хотите восстановить. Выполните действия, описанные в статье "Установка операционной системы Azure Stack HCI версии 23H2".
Примечание.
При развертывании локального экземпляра Azure с помощью пользовательских IP-адресов хранилища необходимо вручную назначить IP-адреса сетевым адаптерам хранилища после восстановления узла.
Зарегистрируйте узел с помощью Arc. Выполните действия, описанные в разделе "Регистрация с помощью Arc", и настройте разрешения.
Примечание.
Для регистрации в Arc необходимо использовать те же параметры, что и существующие узлы. Например, имя группы ресурсов, регион, подписка и клиент.
Назначьте следующие права восстановленному узлу.
- Роль локального управления устройствами Azure
- Пользователь секретов Key Vault. Дополнительные сведения см. в разделе Назначение разрешений для узла.
Выполните следующие действия на другом узле, который является членом того же локального экземпляра Azure.
Если вы используете версию до 2405.3, выполните следующую команду, чтобы очистить конфликтующие файлы:
Get-ChildItem -Path "$env:SystemDrive\NugetStore" -Exclude Microsoft.AzureStack.Solution.LCMControllerWinService*,Microsoft.AzureStack.Role.Deployment.Service* | Remove-Item -Recurse -Force
Войдите в узел, который уже является членом системы, с учетными данными пользователя домена, предоставленными во время развертывания системы. Выполните следующую команду, чтобы восстановить входящие узлы:
$Cred = Get-Credential Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred
Примечание.
Имя узла должно быть именем NetBIOS. Параметр
LocalAdminCredential
по умолчанию — это встроенная учетная запись администратора, созданная установкой ОС Windows.Запишите идентификатор операции, выведенный командой
Repair-Server
. Это можно использовать позже для отслеживания выполнения хода операцииRepair-Server
.
Мониторинг хода выполнения операции
Чтобы отслеживать ход выполнения операции добавления узла, выполните следующие действия.
Выполните следующий командлет и укажите идентификатор операции из предыдущего шага.
$ID = "<Operation ID>" Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
После завершения операции задание перебалансирования фонового хранилища продолжит выполняться. Дождитесь завершения задания перебалансировки хранилища. Чтобы проверить ход выполнения этого задания перебалансирования хранилища, используйте следующий командлет:
Get-VirtualDisk|Get-StorageJob
Если задание повторного балансировки хранилища завершено, командлет не вернет выходные данные.
Сценарии восстановления
Следующие сценарии восстановления и рекомендуемые шаги по устранению проблем для восстановления узла представлены в таблице:
Описание сценария | Смягчение | Поддерживается? |
---|---|---|
Сбой операции ремонта узла. | Чтобы завершить операцию, изучите сбой. Повторно выполните неудачную операцию с помощью Repair-Server -Rerun . |
Да |
Операция восстановления узла завершилась частично, но должна была начаться с новой установки операционной системы. | В этом сценарии оркестратор (также известный как Диспетчер жизненного цикла) уже обновил свое хранилище знаний с новым узлом. Используйте сценарий восстановления узла. | Да |
Устранение неполадок
Если при восстановлении узла возникают сбои или ошибки, вы можете записать выходные данные сбоев в файле журнала.
Войдите с помощью учетных данных пользователя домена, предоставленных во время развертывания системы. Зафиксировать проблему в файлах журнала.
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
Чтобы повторно выполнить неудачную операцию, используйте следующий командлет:
Repair-Server -Rerun
Следующие шаги
Узнайте больше о том, как добавить узел.