适用于:Azure Local 2311.2 及更高版本
本文介绍如何修复 Azure Local 实例上的节点。 在本文中,每个服务器都被称为一个节点。
关于修复节点
Azure Local 是一个超聚合的系统,可用于修复现有系统中的节点。 如果出现硬件故障,则可能需要修复系统中的节点。
在修复节点之前,请务必与你的解决方案提供商联系,确定节点上的哪些组件是可以自己更换的现场可更换单元 (FRU),哪些组件需要技术人员更换。
支持热插拔的部件通常不要求你重新映像节点,这与主板等非热插拔组件不同。 请咨询硬件制造商,以确定哪些组件更换需要对节点重置映像。 有关详细信息,请参阅 组件替换。
修复节点工作流
以下流程图显示了修复节点的整个过程。
*节点可能处于无法关闭或不需要关闭的状态*
若要修复现有节点,请执行以下步骤:
如果可能,请关闭要修复的节点。 根据节点的状态,可能不可能或不需要关机。
重新映像需要修复的节点。
运行修复节点操作。 Azure Stack HCI 操作系统、驱动程序和固件作为修复操作的一部分进行更新。
存储会在重新映像的节点上自动重新平衡。 存储重新平衡是一项低优先级任务,根据节点数量和使用的存储,可能会运行数天。
支持的方案
如果修复节点,则会重新映像该节点并使用以前的名称和配置将其恢复到系统。
修复单个节点会导致重新部署,并可以选择保留数据卷。 部署期间仅删除并新预配系统卷。
重要说明
确保始终对工作负荷进行备份,不要仅仅依赖于系统复原能力。 这在单节点方案中尤其重要。
复原能力设置
在此版本中,对于修复节点操作,不会在部署后创建的工作负荷卷上执行特定任务。 对于修复节点操作,仅还原所需的基础结构卷和工作负荷卷,并将其显示为群集共享卷 (CSV)。
部署后创建的其他工作负荷卷仍会保留,这些卷可以通过运行 Get-VirtualDisk
cmdlet 来发现。 你需要手动解锁卷(如果卷已启用 BitLocker),并创建 CSV(如果需要)。
硬件要求
修复节点时,系统会验证新的传入节点的硬件,并确保该节点在添加到系统之前满足硬件要求。
组件 | 合规性检查 |
---|---|
中央处理器 | 验证新节点是否具有相同数量或更多的 CPU 核心数。 如果传入节点上的 CPU 核心数不符合此要求,则会显示警告。 但允许进行此操作。 |
内存 | 验证新节点是否安装了相同数量或更多的内存。 如果传入节点上的内存不符合此要求,则会显示警告。 但允许进行此操作。 |
驱动器 | 验证新节点是否具有相同数量的可用于存储空间直通的数据驱动器。 如果传入节点上的驱动器数量不符合此要求,则会报告错误并阻止操作。 |
节点更换
可以更换整个节点:
- 新节点与旧节点相比具有不同的序列号。
- 使用当前节点(在完成重新映像后)。
节点更换期间支持以下方案:
节点 | 磁盘 | 支持 |
---|---|---|
新节点 | 新磁盘 | 是 |
新节点 | 当前磁盘 | 是 |
当前节点(已重新镜像) | 新磁盘 | 是 |
当前节点(已重新镜像) | 当前磁盘 | 是 |
当前节点(已重新镜像) | 重新格式化的当前数据磁盘 | 否 |
重要说明
如果在节点修复期间更换组件,则不需要更换或重置数据驱动器。 如果更换或重置驱动器,那么一旦节点加入系统,该驱动器将无法被识别。
组件更换
在 Azure Local 实例上,非热插拔组件包括以下项:
- 母板/基板管理控制器 (BMC)/视频卡
- 磁盘控制器/主机总线适配器 (HBA)/后端
- 网络适配器
- 图形处理单元
- 数据驱动器(不支持热交换的驱动器,例如 PCI-e 外接卡)
非热插拔组件的实际更换步骤因原始设备制造商 (OEM) 硬件供应商而异。 如果需要对非热插拔组件进行节点修复,请参阅 OEM 供应商的文档。
先决条件
在修复节点之前,必须确保:
-
AzureStackLCMUser
在 Active Directory 中处于活动状态。 有关详细信息,请参阅 “准备 Active Directory”。 - 以
AzureStackLCMUser
身份或以具有同等权限的其他用户身份登录。 AzureStackLCMUser
的凭据没有改变。
如果需要,请将你确定要修复的节点脱机。 请按照此处的步骤操作:
修复节点
本节介绍如何使用 PowerShell 修复节点,监视 Repair-Server
操作的状态,并在出现任何问题时进行故障排除。
确保已查看 先决条件。
在试图修复的节点上执行以下步骤。
在您要修复的节点上安装操作系统和所需的驱动程序。 按照 安装 Azure Stack HCI 操作系统版本 23H2 中的步骤进行操作。
将节点注册到 Arc。按照 Arc 注册和权限设置指南中的步骤进行。
注意
必须使用与现有节点相同的参数才能向 Arc 注册。例如:资源组名称、区域、订阅和租户。
为修复后的节点分配如下权限:
- Azure Local 设备管理角色
- Key Vault 机密用户有关详细信息,请参阅 向节点分配权限。
在属于同一 Azure Local 实例的另一个节点上执行以下步骤。
如果运行的是 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
命令输出的操作 ID。 稍后你将使用此项来监视Repair-Server
操作的进度。
监视操作进度
要监视添加节点操作的进度,请按照这些步骤操作:
运行以下 cmdlet,并提供上一步中的操作 ID。
$ID = "<Operation ID>" Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
操作完成后,后台存储重新平衡作业将继续运行。 等待存储重新平衡作业完成。 要验证此存储重新平衡作业的进度,请使用以下 cmdlet:
Get-VirtualDisk|Get-StorageJob
如果存储重新平衡作业已完成,cmdlet 将不会返回输出。
恢复方案
下面列出了修复节点的恢复方案和建议的缓解步骤:
方案描述 | 缓解措施 | 支持? |
---|---|---|
修复节点操作失败。 | 要完成操作,请对故障进行调查。 使用 Repair-Server -Rerun 重新运行失败的操作。 |
是 |
修复节点操作部分成功,但必须重新安装操作系统。 | 在此方案中,业务流程协调程序(也称为生命周期管理器)已经使用新节点更新了其知识存储。 使用修复节点方案。 | 是 |
故障排除
如果在修复节点时遇到失败或错误,可以在日志文件中捕获失败的输出。
使用在系统部署期间提供的域用户凭据登录。 在日志文件中捕获问题。
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
若要重新运行失败的操作,请使用以下 cmdlet:
Repair-Server -Rerun
如果在修复节点作期间遇到问题,并且需要Microsoft支持部门提供的帮助,可以按照 Azure 本地(预览版)收集诊断日志 中的步骤收集诊断日志并将其发送到Microsoft。
可能需要从正在修复的节点提供诊断日志。 请确保从此节点运行 Send-DiagnosticData
cmdlet。
后续步骤
详细了解如何 添加节点。