Azure Stack Hub 补丁与更新：从服务策略到日志分析（下篇）

未经同意请勿转载本文聚焦Azure Stack Hub 一体机的补丁与更新全流程—— 服务策略、Microsoft 更新包 / Dell OEM 扩展包、版本控制、上传到存储、安装 / 恢复、日志分析、Dell Patch Update Automation 工具构成完整的更新操作蓝图。版本基础本文基于azs-1901 至当前主流 azs 版本的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异当版本与本文表述不一致时以当期版本 Azure Stack Hub Operator 文档 当期 OEM Support Matrix 为准。修订说明本篇为Azure Stack Hub 监控与更新三篇系列 · 补丁与更新篇首发版基于内训材料《Azure Stack Hub 监控与更新》中补丁与更新章节整理按四层原则做工程化改写。目录Azure Stack Hub 更新的全流程图服务策略与版本支持窗口Microsoft 更新 vs Dell OEM 扩展包Microsoft 软件更新类型更新包版本控制与命名规范更新包文件结构与 metadata.xml更新研发与发布流程更新顺序规则下载更新包在线 vs 离线上传更新包管理员门户的 6 步流程开始更新管理员门户操作开始更新PowerShell 操作查看更新进度PEP 与管理员门户恢复失败的更新Dell OEM PU硬件侧的更新工具链Dell Patch Update Automation 工作流分析更新日志其他日志Get-AzureStackLog四个常见误判信号四条更新场景红线下篇小结补丁与更新的工程化整合1. Azure Stack Hub 更新的全流程图L1 微软硬要求Azure Stack Hub 的补丁与更新是一条严格的线性流程——它的每一步都是上一一步的前置条件。下面先给出完整流程图再分章节展开每一段。1.1 完整流程图[Step 1] 服务策略判断 ├─ 当前版本是否在 N-2 支持窗口内 └─ 不在 → 升级到至少支持的最低版本 ↓ [Step 2] 选择更新包类型 ├─ Microsoft 软件更新完整 / 快速 / 修补程序 └─ Dell OEM 扩展包硬件固件 / 驱动 / HLH ↓ [Step 3] 下载更新包 ├─ 在线Microsoft Update Catalog默认 └─ 离线aka.ms/azurestackupdatedownload ↓ [Step 4] 上传到存储 ├─ 管理员门户 → 存储账户 → updateadminaccount → Blob 容器 └─ 三件套.exe / .bin / metadata.xml ↓ [Step 5] 启动更新 ├─ 管理员门户更新磁贴 → 立即更新 └─ PowerShellInstall-AzsUpdate ↓ [Step 6] 监控更新进度 ├─ 管理员门户更新运行详细信息 └─ PEPGet-AzureStackUpdateStatus ↓ [Step 7] 处理失败 / 恢复 ├─ 管理员门户恢复按钮 └─ PEPResume-AzureStackUpdate ↓ [Step 8] 日志分析 ├─ 更新运行日志JSON └─ 全栈日志Get-AzureStackLogL3 最佳实践每一步操作都应被记录为运维工单——一体机更新是涉及全节点的破坏性变更需要全链路审计。2. 服务策略与版本支持窗口L1 微软硬要求Azure Stack Hub要在支持配置内必须在 Microsoft 明确指定的时间间隔内持续更新。2.1 核心策略原则维度L0 版本事实L1 微软硬要求支持窗口Microsoft 文档明确 N-2 保留窗口客户必须维持在支持窗口内更新延迟容忍至多三个版本不更新落后三个版本以上 不合规不合规的后果失去支持失去支持典型合同后果最小支持版本由 Microsoft 公告必须升级到至少最小支持版本L2 微软实现当前主流版本azs-2XXX 期间与之类似180x PPT 示例仅作演示 | 1809最新 | ✅ 支持 | 1808次新 | ✅ 支持 | 1807最底限 | ✅ 支持最小支持版本 | 1805过老 | ❌ 不支持L3 最佳实践管理员应定期查看 Microsoft 当期公告确认一体机处于最新 / 次新 / 最底限三个支持版本之内。当前主流版本号以 Microsoft 公告为准——不要直接套用 PPT 里的 180x 演示。2.2 落后三个版本以上的实际后果L1 微软硬要求当一体机落后三个版本以上时不提供厂商支持—— 微软 Support 团队可能不会接收你的 case 或仅接收故障转移类 case不接收新更新包—— 部分新版本可能要求最低起点版本MinVersionRequired若版本过老甚至无法直接升级必须先做过渡新功能 / 安全补丁无法获取—— 已知漏洞没有官方修复。L3 最佳实践建立月度版本审计机制——管理员每月初对照 Microsoft 当期公告确认一体机版本号仍在 N-2 窗口内。3. Microsoft 更新 vs Dell OEM 扩展包L1 微软硬要求 L2 OEM 实现Azure Stack Hub 集成系统有两种类型的更新包两者必须配套使用缺一不可。3.1 两种更新包的对照维度Microsoft 软件更新Dell OEM 扩展包提供方MicrosoftDellOEM更新对象Azure Stack Hub 软件栈HRP / NRP / ACS / Windows Server Core 等缩放单元节点驱动程序、固件、HLH、MGMTVM、Secure Connect Gateway、网络交换机部署入口Azure Stack Hub 管理员门户Azure Stack Hub 管理员门户流程一致性同样的上传 → 安装 → 监控流程同样的上传 → 安装 → 监控流程研发责任Microsoft 研发Dell 实验室 Microsoft 联合认证配套关系通常先 Microsoft 更新后 OEM 扩展通常在 Microsoft 更新后做3.2 Dell 提供的两类补丁L2 Dell 实现Dell 还提供独立的补丁与更新工具Dell Patch and Update Automation / Dell PUDell 工具内容下载位置Dell PU 工具Dell Patch and Update AutomationHLH / 戴尔网络交换机更新包括 HLH 固件、HLH / MGMTVM OS、戴尔交换机固件Dell 支持按产品页面Dell Customer Toolkit服务器偏移配置 / 硬件监控实时清单 / 交换机 QoS 配置等 Dell 管理软件Dell Customer ToolkitL3 最佳实践这两类补丁应在 Microsoft 更新完成后做——固件更新和 HLH 更新通常会在 Azure Stack Hub 更新后最后完成。4. Microsoft 软件更新类型L0 官方分类Microsoft 软件更新按覆盖范围分为三类类型说明维护窗口完整更新Full Update更新缩放单元中的物理主机操作系统需要更大的维护时段长数小时到半天快速更新Express Update作用域有限不更新基础物理主机操作系统维护时段较短短数十分钟到 1 小时修补程序Hotfix解决特定问题通常是预防性或时间敏感极短几分钟4.1 Microsoft 发布节奏L0 版本事实频率Microsoft 每年定期发布多个完整和快速软件更新包通常在每月的第四个星期二发布。有些月份可能没有更新——这是 L0 事实不是漏发修补程序单独发布不绑定月节奏。4.2 三种类型的工程含义L3 最佳实践完整更新计划在生产低峰期如周末或节假日午夜窗口执行快速更新可在工作时间内执行前提是业务容忍更广的服务降级修补程序通常由 Microsoft Support / OEM Support 主动推荐应按建议立即执行。5. 更新包版本控制与命名规范L0 版本事实Microsoft 更新程序包的命名约定非常关键——版本号既是身份识别也是升级路径判断的依据。5.1 命名规范L0 版本事实产品主版本. YYMM. 次要版本. 内部版本号 例1.2008.13.88 ──┬── └ YY 年20 2020 ──|── MM 月08 8 月 ──|── ─┬── 次要版本 13 ───|── ─┬── 内部版本号 885.2 命名规则的解读字段含义举例主版本当前固定为 1Azure Stack Hub 主版本号1YYMM年 月标识月份2008 2020 年 8 月次要版本同月份内的迭代序号13内部版本号同次要版本内的小修正885.3 命名约定的工程含义L3 最佳实践2008 月份发布的更新包1.2008.X.Y2008 月份发布的修补程序版本号递增次要版本和内部版本号例如1.2008.20.102——不要再开新的 YYMM保持在同月跨月升级1.2008.x.y→1.2009.x.y—— YYMM 必须单调递增完整文档参考http://aka.ms/azurestackupdate6. 更新包文件结构与 metadata.xmlL0 版本事实更新包通常由三类文件组成.exe自解压执行、.bin关联负载压缩包、.xml元数据。6.1 三类文件说明文件类型用途内容.exe自解压包名称包含更新的有效负载如 Windows Server 最新累积更新.bin关联负载压缩与 .exe 文件配套的压缩负载.xmlmetadata.xml包含更新的基本信息发布者、名称、先决条件、大小、支持路径 URL6.2 metadata.xml 的关键字段L0 版本事实/UpdatePackageManifest UpdateNameAzS Update - 1.1809.0.90/UpdateName Version1.1809.0.90/Version PackageSizeInMb2379/PackageSizeInMb DescriptionAzS Update 1.1809.0.90/Description KBLinkhttps://aka.ms/azurestackupdate/KBLink MinVersionRequired1.1808.5.110/MinVersionRequiredL1 微软硬要求管理员必须检查MinVersionRequired是否 ≤ 当前一体机版本否则不应上传——这会在上传时被系统拒绝。6.3 metadata.xml 是审计源L3 最佳实践metadata.xml 是更新包的身份证——管理员在变更窗口前可读这个文件确认支持路径 URLKBLink—— 失败时应该去的文档包大小—— 与实际下载大小对比验证传输完整性发布者 / 名称—— 验证未被篡改不应使用非 Microsoft / OEM 签名的更新包。7. 更新研发与发布流程L2 微软实现7.1 研发流程L2 微软实现 L2 OEM 实现Microsoft Dell ┌──────┐ ┌──────┐ │ 构建 │ → 发布候选 (RC) → │ 部署验证 │在 Dell 实验室 10 节点规模 └──────┘ └──────┘ ┌────────────────────────┐ │ 持续集成和验证 │ └────────────────────────┘7.2 多节点验证L1 微软硬要求PPT 强调**10个多节点系统**——意味着 Microsoft 在实验室部署 10 节点集群做集成验证。这是L1 微软硬要求意味着一体机上的更新已经经过多节点全栈验证不是仅经过单元测试客户现场遇到的问题通常是边界场景而不是基本集成问题管理员对常见更新失败应优先走诊断流程而非直接怀疑包损坏。8. 更新顺序规则L1 微软硬要求8.1 三条核心规则规则含义N-2 维护Microsoft Azure Stack 客户必须维护 N-2 Microsoft 版本以保持在受支持的配置中顺序安装Microsoft 修补程序和更新必须按顺序安装包括之前和之后的修补程序文档优先客户必须遵循 Microsoft Azure Stack 文档中概述的说明8.2 顺序安装的工程含义L3 最佳实践按顺序安装看似简单但实际生产中容易踩坑场景 A当月修补程序 当月完整更新 —— 哪个先通常当月修补程序先因为它可能在前置基础上叠加场景 B落后 3 个版本 —— 跳过中间版本直接升级绝对不可以——必须按顺序逐版本过渡场景 COEM 扩展包与 Microsoft 更新冲突通常 Microsoft 更新在先——但具体顺序以 Microsoft 当期文档为准。8.3 Dell 端的对应流程L2 OEM 实现必须安装对应的 Dell 更新扩展包与使用管理门户的 Microsoft Azure Stack 更新使用相同的安装流程固件更新和 HLH 更新通常会在 Azure Stack Hub 更新后最后完成客户应遵守 Dell Technologies 支持网站上的修补程序和更新指南。9. 下载更新包在线 vs 离线L1 微软硬要求 L0 官方行为9.1 在线默认L0 版本事实管理员门户会自动检查 Microsoft Update Catalog是否有新更新当管理员门户显示有新更新时客户端从 Microsoft 后台下载在线模式需要一体机具有出栈到 Microsoft Update 服务的网络能力。9.2 离线 / 带外L0 版本事实适用于没有 Internet 或 Internet 连接较弱的环境下载工具https://aka.ms/azurestackupdatedownloadAzure Stack Hub Update Downloader发行说明https://docs.microsoft.com/en-us/azure-stack/operator/release-notesL3 最佳实践气隙 / 离线环境下应预先下载几个版本的离线包到本地存储介质作为应急储备。10. 上传更新包管理员门户的 6 步流程L1 微软硬要求下载 Microsoft 更新包后必须将更新包上传到 Azure Stack Hub 环境。OEM 更新包也需要上传。上传流程是标准的 6 步10.1 上传流程表步骤入口操作校验1. 选存储账户管理员门户 → 更多服务 → 数据 存储 → 存储账户或在筛选器框键入存储账户找到updateadminaccount存储账户确认 account 名称正确2. 进 updateadminaccount在筛选器框中键入update选择updateadminaccount存储账户进入存储账户详情确认是 admin update 用 account3. 进 Blob在存储账户详细信息下服务 → Blob进入 Blob 服务页4. 创建容器在 Blob 服务下选 容器输入名称如Update-1802→ 确定容器创建成功容器名规范项目方自定5. 上传包在容器内选 上传浏览到更新包的.exe文件 → 打开 → 上传包文件上传完成通知右上角铃铛显示上传已完成6. 重复 4-5同样路径上传PackageName.bin和metadata.xml或一次选择多个文件三件套上传完毕三个文件都在容器内10.2 上传后的可见性L0 版本事实上传完成后回到管理员门户的更新磁贴磁贴会自动指示有可用更新。单击磁贴可查看新添加的更新包。L3 最佳实践上传完成后先在更新磁贴上确认包状态 Ready再开始安装。Ready 状态意味着元数据校验通过 文件完整性确认。11. 开始更新管理员门户操作L1 微软硬要求11.1 标准操作流程步骤动作1单击更新磁贴查看更新的详细信息2选择标记为就绪的包3右键单击该包 → 选择立即更新或单击顶部附近的立即更新操作4安装过程中可在更新运行详细信息区域中查看状态5在更新运行详情区单击下载完整日志以下载日志文件主动备份日志是 L3 最佳实践6更新完成后更新磁贴将显示更新的 Azure Stack Hub 版本号11.2 关键观察点L3 最佳实践就绪状态→ 包已上传 metadata 校验通过更新运行状态→ 管理员应在更新开始后 5-10 分钟内再次确认状态避免看似开始但实际卡在第一步的误判完成后版本号→ 与 metadata.xml 的Version字段应一致——不一致说明包与元数据不匹配。12. 开始更新PowerShell 操作L0 版本事实如果管理员门户不可用、或者管理员偏好脚本化操作可以用 PowerShell cmdlet 启动和监视更新状态。12.1 四个核心 cmdlet 速查Cmdlet用途Get-AzsUpdateLocation检索 region 更新摘要区域状态、可用更新数Get-AzsUpdate列出 Azure Stack Hub 可用更新Install-AzsUpdate -Update Update Version应用指定更新例如Install-AzsUpdate -Update Microsoft1.1907.0.10Get-AzsUpdateRun检索特定 Azure Stack Hub 更新的进度和状态12.2 安装示例# 列出可用更新 Get-AzsUpdate # 安装指定更新 Install-AzsUpdate -Update Microsoft1.1907.0.10 # 检索更新运行进度 Get-AzsUpdateRun -UpdateName Microsoft1.1907.0.10L3 最佳实践版本号字符串格式应严格匹配 metadata.xml 中的UpdateName字段。错把 1907 写成 1908 会导致安装失败。13. 查看更新进度PEP 与管理员门户L1 微软硬要求可以使用特权终结点PEP监视 Azure Stack Hub 更新运行的进度并在Azure Stack Hub 门户不可用时从上一个成功步骤恢复失败的更新运行。13.1 两套查看路径路径适用场景推荐度管理员门户更新磁贴 → 更新运行详细信息日常 / 首选✅ 建议使用PEPGet-AzureStackUpdateStatus管理员门户不可用 / 应急⚠ 仅作为兜底13.2 PEP 会话建立的标准步骤# 1. 配置可信主机 Set-Item WSMan:\localhost\Client\TrustedHosts -Value IP Address of Privileged Endpoint -Concatenate # 2. 获取凭据 $cred Get-Credential # 3. 新建 PEP 会话 $pep New-PSSession -ComputerName IP_address_of_ERCS -ConfigurationName PrivilegedEndpoint -Credential $cred -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US) # 4. 进入 PEP 会话 Enter-PSSession $pep # 5. 获取更新状态 Get-AzureStackUpdateStatus13.3 Get-AzureStackUpdateStatus 输出L0 版本事实Get-AzureStackUpdateStatuscmdlet 返回当前正在运行、已完成或失败的更新的状态。它提供更新操作的高级状态InProgress / Completed / FailedXML 文档描述当前步骤和相应状态——这是分步骤的状态报告每个子步骤都有自己的状态。13.4 PEP 与管理员门户的边界L3 最佳实践维度管理员门户PEP典型使用日常运维应急排查可观察的细节高层级更新状态 子步骤摘要同等甚至更细因为 XML 全文可触发恢复是恢复按钮是Resume-AzureStackUpdate需要 Token通常不需要通常不需要会话管理无HTTPPowerShell Remoting Session14. 恢复失败的更新L1 微软硬要求如果更新失败可以通过门户或 PEP 从中断的位置恢复更新。在某些情况下可能需要先完成缓解步骤然后才能恢复更新。14.1 两条恢复路径的对照维度管理员门户PEP PowerShell入口导航到更新运行详细信息的窗格 → 点击 恢复Resume-AzureStackUpdatecmdlet操作单击按钮触发恢复从失败点恢复当前更新安装代码示例N/AGUI见下方14.2 PEP 恢复 PowerShell 示例# 1. 建立 PEP 会话 $pepSession New-PSSession -ComputerName Azs-ERCS01 -ConfigurationName PrivilegedEndpoint -Credential (Get-Credential) # 2. 在 PEP 会话中执行恢复 Invoke-Command -Session $pepSession -ScriptBlock { Resume-AzureStackUpdate }14.3 恢复前的缓解步骤L3 最佳实践在某些情况下必须先完成缓解步骤才能恢复更新。常见的缓解步骤类型磁盘空间不足—— 清理 updateadminaccount 存储中旧版本包网络瞬断—— 检查 PEP 到 ERCS 网络可达性被 earlier 失败阻塞—— 重启被卡的服务PEP cmdlet 由微软支持 / 故障排查团队执行。L1 微软硬要求Resume-AzureStackUpdate不能跳过被标为失败的子步骤——它从失败点继续但不会重跑已经成功的步骤。这保证幂等但也意味着前面失败原因必须先解决。15. Dell OEM PU硬件侧的更新工具链L2 OEM 实现Dell OEM 的更新与 Microsoft 更新使用不同的工具但最终仍在管理员门户中体现。Dell 提供两类工具域15.1 Dell 管理工具的工具域工具内容下载位置Dell 修补程序和更新自动化Dell Patch and Update AutomationHLH 和戴尔网络交换机更新HLH 固件、HLH / MGMTVM OS、戴尔交换机固件Dell 支持按产品页面Dell Customer Toolkit服务器偏移配置 / 硬件监控实时清单 / 交换机 QoS 配置等 Dell 管理软件Dell Customer Toolkit 和 Dell 支持按产品页面15.2 两类工具的工程边界L3 最佳实践Dell Patch and Update AutomationDPUA—— 它处理硬件层的更新节点 firmware、HLH OS、MGMTVM OS、Secure Connect Gateway 设备软件、交换机固件Dell Customer Toolkit—— 它处理配置层的更新QoS、硬件监控清单、服务器偏移配置等两者不重叠——DPUA 不动配置DCT 不动固件 / 驱动。16. Dell Patch Update Automation 工作流L2 Dell 实现Dell Patch Update Automation 有两个工作流程。16.1 两个工作流的关系[工作流 1: 预检查] ├─ 扫描系统组件 ├─ 与已下载的 Dell Customer Toolkit 对比 ├─ 显示每个组件的可用更新如果有 └─ 输出有可用更新 / 无可用更新 ↓如果有则进入 [工作流 2: 升级] ├─ 启动升级工作流 ├─ 按顺序更新所有有可用更新的组件 ├─ **管理员无法取消选择工作流中的任何步骤** ├─ 完成后展示摘要窗口 └─ 输出成功 / 部分失败 ↓所有修补和升级工作流完成后 [总结] └─ 应用产品版本Product Version16.2 预检查工作流的细节L2 Dell 实现扫描对象HLH 固件、HLH OS、MGMTVM OS、Dell-MGMTVM 上的 Secure Connect Gateway、戴尔交换机固件、Dell 服务器固件比对对象Dell Customer Toolkit 中已下载的最新版本输出每个组件的当前版本 / 最新版本 / 是否需要更新三栏视图。16.3 升级工作流的边界L2 Dell 实现升级顺序固定—— 预检查列出的有更新组件按预定义顺序升级管理员无法干预不可跳过—— 即使管理员临时想跳过某个组件的更新工具不接受这种操作原子化视图—— 升级过程全程只展示摘要不暴露每个子步骤详情。L3 最佳实践升级工作流的不可干预特性既是优点也是风险——管理员在启动前应在预检查阶段多次确认避免启动后无法中断。17. 分析更新日志L0 版本事实Azure Stack Hub 允许下载每次更新运行的所有成功和失败更新的日志文件。17.1 日志类型与解析L0 版本事实日志文件本身是一个JSON 文件。要使其更具可读性使用 PowerShell 解析$json Get-Content C:\Updatelogs_4848628f-0f78-4b3f-9258-50728254a202.json | ConvertFrom-Json # Get top-level steps $json.properties.progress.steps.steps17.2 日志字段解读L0 版本事实name : PreUpdate Cloud description : Copy packages to NugetStore. errorMessage : # ← 关键字段有内容则说明此步有错 status : Success # ← Success / Failed / InProgress startTimeUtc : 2018-01-04T06:30:32.471Z endTimeUtc : 2018-01-04T06:43:20.758Z steps : {} # ← 子步骤17.3 日志分层视图L3 最佳实践实际生产里更新日志的层至少分四层层内容何时需要L1 元数据更新包本身的信息时间、版本、组件日常审计L2 子步骤 XML/JSON更新运行的步骤树如上方示例失败诊断L3 错误码 / 详细报错每个失败步骤的错误码、堆栈深度诊断 / 联系 Support 时必带L4 全栈日志一体机所有组件的日志Get-AzureStackLog跨组件问题 / 长期排查L3 最佳实践分析失败时至少收集 L1 L2 L3。给 Support 团队提 case 时L4 才是关键——但上传带宽很大应在确实跨组件问题时才收集。18. 其他日志Get-AzureStackLogL1 微软硬要求若要收集其他日志跨组件、可以使用门户或 PEP 中的Get-AzureStackLog。18.1 PEP 收集的标准示例# 1. 建立 PEP 会话 $pepSession New-PSSession -ComputerName Azs-ERCS01 -ConfigurationName PrivilegedEndpoint -Credential (Get-Credential) # 2. 在 PEP 会话中执行 Get-AzureStackLog Invoke-Command -Session $pepSession -ScriptBlock { Get-AzureStackLog -OutputDir \\accessible\path }L0 版本事实上面的示例将收集所有与 Azure Stack Hub 相关的日志文件并将其写入网络共享路径。18.2 与专门日志的边界L3 最佳实践维度更新日志§17Get-AzureStackLog§18聚焦对象单次更新运行一体机全栈NRP / NC / SLB / Gateway / HRP / Storage ...触发时机更新完成后下载一体机出现跨组件问题时典型大小几 MB 到几十 MB几 GB 到几十 GB使用对象客户管理员主要给微软 / OEM Support很少客户自己看L1 微软硬要求Get-AzureStackLog是 Microsoft 内部 / OEM 运维 cmdlet ——客户运维不经常直接调用通常由 Support 团队远程触发。19. 四个常见误判信号管理员初次接触更新流程时容易误判。下面补充四条 L3 最佳实践层面的常见误判补足19.1 上传更新包到 updateadminaccount ≠ 自动安装不少新管理员会以为上传包 自动安装。实际上上传只是把包放到存储仍需要在更新磁贴点击立即更新。管理员看到包出现在更新磁贴上才说明上传成功。19.2 安装时报包无效 ≠ 应换包包无效通常意味着MinVersionRequired 不匹配或包文件损坏——但不一定是包本身问题。管理员应先检查当前一体机版本是否 ≥ MinVersionRequired。19.3 恢复失败 ≠ 包本身有问题恢复失败的常见原因是底层问题没有先被缓解如磁盘满、网络断、证书过期。管理员不应立即怀疑包本身而是先按 PEP 输出诊断底层状态。19.4 Update Run 卡在某步 ≠ 系统严重故障Update Run 在某个步骤停留长时间特别是 PreUpdate / Update SeedRing 等环节可能是正常的资源调度节奏——管理员应在至少观察 1 小时之后才判定为卡住。20. 四条更新场景红线L3 最佳实践 L1 微软硬要求更新场景的绝对不能这么做的红线20.1 红线 1不得使用 offline update URL 越过微软后台Offline Update Downloader 工具的目的是支持气隙 / 弱网环境而不是为了避开微软的版本管理。所有更新仍要走 Microsoft / OEM 官方通道aka.ms/azurestackupdatedownload / aka.ms/azurestackupdate不应使用非官方 URL。20.2 红线 2不得在升级期间关闭 adminportaladminportal是 HRP 的可视化入口。关闭 adminportal 不能停止升级进程——升级由 ERCS 控制面管理停止 adminportal 仅让管理员看不到进度升级进程仍在跑但管理员失去观测手段。20.3 红线 3不得手工覆盖 S2D 在升级窗口内的状态升级期间 S2D 可能处于 degraded 状态节点重启、rebalance 等。手工覆盖 S2D会破坏升级的预期恢复路径。20.4 红线 4不得擅自降级到比 MinVersionRequired 低的版本降级操作不被支持——一旦降级可能失去微软 / OEM Support且不能保证数据完整性。如果一体机版本过老、走不到新版本必须按 N-2 顺序逐版本升级。21. 下篇小结补丁与更新的工程化整合本文围绕 PPT 中补丁与更新章节slide 20-46展开了Azure Stack Hub 补丁与更新的全流程§1-2阐述更新全流程图与服务策略N-2 窗口§3-8拆解 Microsoft 更新与 Dell OEM 扩展包、Microsoft 更新类型、版本命名规范、metadata、更新顺序§9-14展开下载 → 上传 → 安装 → 监控 → 恢复的标准流程§15-16阐述 Dell PU Automation 工作流§17-18给出日志分析与 Get-AzureStackLog 的双层方法§19-20补充四条常见误判信号与四条更新场景红线。三篇系列收束本文是监控与更新三篇系列的第 3 篇。本系列三篇按告警机制 → ITSM 集成 → 补丁与更新完整呈现 Azure Stack Hub 一体机的运维主线上篇《监控理念与告警机制》——告警是怎么生成的、谁负责调度、HRP 的中央角色中篇《监控与集成》——告警如何流入 SCOM / Nagios / ITSM 等企业栈下篇本文《补丁与更新》——告警如何通过更新流程收敛——这是告警的最终修复路径。参考与延伸阅读微软 Azure Stack Hub 服务策略https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-servicing-policy微软 Azure Stack Hub 更新文档http://aka.ms/azurestackupdate微软 Azure Stack Hub 更新下载程序离线版https://aka.ms/azurestackupdatedownload微软 AzureStack-Tools - Infrastructurehttps://github.com/Azure/AzureStack-Tools/tree/master/InfrastructureAzure Stack Hub Operator 文档当期 azs 版本为准当期 OEM Support MatrixDell Patch Update Automation / Dell Customer Toolkit 等