未经同意请勿转载本篇定位面向 Azure Stack Hub 一线运维 / SOC / 监控 / 故障响应工程师。本文承接上篇《Azure Stack Hub 网络服务从物理拓扑到租户 SDN 完整图谱》中网络模型部分重点展示如何在生产中观测、运维、排错 Azure Stack Hub 的网络栈。上篇回顾上篇讲的是网络是怎么搭的——物理拓扑 / SDN 逻辑网络 / 租户 IaaS 对象 / DNS / Gateway / 混合连接。本篇讲的是出问题时怎么查、怎么改、怎么监控——四类核心组件的监控、容量告警、四类典型故障VIP 连通 / 出栈 / DNS / VPN的排查手法、以及最后一公里的日志收集。版本基础与上篇一致基于azs-1901 至当前主流 azs 版本的 Azure Stack Hub Operator 文档整理。不同 OEM 集成系统以及不同 azs 版本之间可能存在差异当版本与本文表述不一致时以当期版本 Azure Stack Hub Operator 文档为准。本文不展开的边界① 物理网络交换机 / ToR / BMC 的故障更换流程 ② Az PowerShell 模块的完整安装步骤 ③ Microsoft 内部 Support 工单流程 ④ 与 Azure 公有云一致的通用网络理论OSI / TCP / DNS / DHCP 等不在本文逐条展开修订说明本篇为Azure Stack Hub 网络服务管理与排错的新章首发基于材料内训课程 - Azure Stack Hub 网络服务中排错章节整理按档编写准则做工程化改写。修订类别关键变更历史视角显式标注全文明确标注基于内训材料整理四层原则落地区分L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践本文 L1 多为组件角色定义L3 多为排错流程排错流程诊断→定位→恢复→复盘四段式本文在每类故障前都加诊断流程图与复盘 Checklist避免读完排错步骤仍不知道下一步点哪里避免硬要求措辞按当前准则保留作为客观约束如SLB 只支持 TCP/UDPPing 必然失败是事实但不夸大为必须 / 绝对量化数字审慎容量告警阈值 70%/90%/100%保留——属于L0 版本事实Microsoft 官方明确说明的告警阈值VPN 设备兼容性的边界明确本文保留这些参数因属 Microsoft 默认值但显式标注设备兼容性清单与 Azure 公有云共用Azure Stack Hub 不独立维护 VPN 设备清单——这是 L0 官方事实公开技术原则全文使用四层技术事实分类等通用术语不引用内部积累的写作准则日志收集 cmdlet 显式说明Get-AzureStackLog -OutputPath ... -FilterByRole NRP,NC,SLB,Gateway显式标注这是 Microsoft 内部运维 cmdlet租户场景通常不需要执行此命令——遇到网络问题联系 OEM Support / 微软 Support——避免租户误用新增故障前 / 故障中 / 故障后运维节奏本文加入上线前 / 日常巡检 / 故障处置 / 复盘归档的运维节奏让文章从排错手册升级为运维节奏指南新增四个常见误判信号实操里最常见的假象——① VIP PING 失败 ≠ 故障 ② VPN 状态断开连接≠ 故障 ③ DNS 解析失败 ≠ DNS 故障 ④ 静态路由让公共 IP 失效。这是 L3 最佳实践层面的常见误判补足目录Azure Stack Hub 网络栈的四类核心组件网络服务管理工具的能力矩阵网络健康监控告警门户怎么显示 怎么修公共 IP 池容量告警70% / 90% / 100%故障前的预防清单四类检查故障现象 1VIP 连通性失败故障现象 2出栈 NAT 无法访问 Internet故障现象 3DNS 解析失败故障现象 4边缘网关 / VPN 异常四个常见误判信号日志收集Get-AzureStackLog运维节奏上线 / 巡检 / 处置 / 复盘下篇小结1. Azure Stack Hub 网络栈的四类核心组件Azure Stack Hub 把网络栈的责任切给了四个核心组件。理解这个分工是看懂后续监控告警、排错流程的基础。1.1 四个核心组件角色速查组件角色主要负责故障时表现为NRPNetwork Resource Provider网络资源提供者接收 ARM API 调用把资源对象转换为底层配置管 vNet / NSG / UDR / PIP / SLB租户无法创建 / 修改网络资源PIP 显示异常NCNetwork Controller网络控制器SDN 控制面统一管理 SDN 转发面VM 网络失联 / SLB 健康检查失败SLBSoftware Load Balancer MUX软件负载均衡4 层负载均衡数据面把 VIP 流量分发到 Instance-level IPVIP 不通VIP 通但不向后端转发GatewayEdge Gateway边缘网关S2S VPN / 跨数据中心互连VPN 状态异常本地资源不通1.2 责任划分控制面 vs 数据面[用户 / 租户] └─ ARM API ─► [NRP] ─► [NC] ─► [SLB MUX / vSwitch / Gateway] │ │ │ │ │ │ │ └─ 数据面实际转发流量 │ │ └─ SDN 控制面调度 健康检查 │ └─ 资源对象生命周期管理 └─ 用户入口为什么要分清楚数据面故障如 SLB MUX 进程崩溃→网络转发中断但新资源创建不受影响控制面故障如 NC 失联→所有 SDN 转发降级或停止资源管理面故障如 NRP 失联→新资源无法创建 / 修改已有资源仍可工作。1.3 基础设施角色与租户资源的关系L2 微软实现Azure Stack Hub 把 NC / SLB MUX / Gateway 等组件作为基础设施角色Infrastructure Role运行租户看不到这些组件本身——只能在 Operator 门户的区域管理 / 系统运行状况里看到它们的状态。这个分层是 L0 官方设计选择租户只能通过 NRP 与 SDN 间接使用这些能力。2. 网络服务管理工具的能力矩阵三个层次的能力矩阵资源可用性 / 系统监控 / 网络服务提供者对应三个工具集合。2.1 三层工具矩阵速查工具层关注对象工具入口能力资源可用性已创建的网络对象 / 租户Operator 门户 / PowerShell创建 / 删除 / 修改 / 查询 vNet / NSG / UDR / PIP / SLB系统监控及报警基础设施组件NC / SLB / GatewayOperator 门户 - 区域管理健康监控告警状态查询根本原因建议网络服务提供者资源提供程序自身NRP / NC / SLB / Gateway故障恢复容量增减底层状态变更2.2 工具集合的具体形态L0 版本事实工具用途何时使用Operator 门户可视化管理 / 状态查询日常巡检容量告警处理Operator PowerShellAz PowerShell自动化 / 大规模操作批量创建 / 排错脚本Get-AzureStackLog日志收集含网络栈四大组件提交 Support 工单前管理员 REST API程序化集成自定义自动化Wireshark / Network Monitor数据面抓包深度排错数据面3. 网络健康监控告警门户怎么显示 怎么修3.1 健康告警的呈现位置L0 版本事实——明确表述网络服务的健康监控告警显示在Operator 门户 → 区域管理中告警内容包含系统运行状况警报—— 哪个组件失联 / 异常如何修复建议—— Microsoft 内置的 runbook给出修复操作指引允许服务管理员通过管理门户自行修复—— 这是 Microsoft 设计哲学常见问题让运营商自助修复只把复杂 / 硬件级问题升级到 Support。3.2 健康告警的典型场景告警来源典型症状修复建议NCNetwork Controller失联租户无法创建 / 修改网络资源重启 NC VM检查证书SLB MUX 失败VIP 不通但 VM 本身可达重启 MUX 进程检查 MUX 与 NC 通讯Gateway 失败VPN 状态显示未连接重启 Gateway VM检查本地 VPN 设备存储网络拥塞VM 实时迁移失败 / 性能降级检查 S2D 链路联系 OEM3.3 ⚠️ 门户说告警的常见误用L3 最佳实践不要直接根据告警点击修复按钮——先看告警描述判断是临时抖动还是持续异常多次出现的同类告警才算持续问题单次抖动通常无需干预告警 ≠ 故障——某些告警是为了提醒如NC 证书将在 7 天后过期而不是已出故障。4. 公共 IP 池容量告警70% / 90% / 100%精确的容量告警阈值表——这是 L0 官方事实Microsoft 在 Operator 文档中明确给出的阈值本文保留。4.1 三级容量告警阈值阈值告警级别Description修复指引70%Warning利用率 70%如达到 100%租户将无法创建 VM 或公共 IP添加公共 IP 段——从 ISP 获取新 IP 段 → 登录 Operator 门户 → 容量管理 → 公共 IP 池 → 扩展操作90%Warning利用率 90%如达到 100%租户将无法创建 VM 或公共 IP同 70% 流程但更紧急100%Critical利用率 100%租户已无法创建 VM / 公共 IP必须立即扩容——已经没有缓冲4.2 为什么是 70% / 90% / 100% 三档L0 官方事实直接原因由于获取公共 IP 地址块需要时间因此在 70%、90% 和 100% 阈值处会有警报。70% 第一次提醒你有时间——从 ISP 申请新 IP 段需要走流程合同 / 路由通告 / BGP 重配 / 防火墙白名单可能耗时数天到数周90% 第二次提醒很紧急——剩余 10% 很快耗光100% Critical已经出故障——租户开始无法创建资源。4.3 容量告警处置流程[1] Operator 门户 - 区域管理 - 容量管理 │ ▼ [2] 公共 IP 池 - 查看使用率 │ ├── 70% → 归档关闭无需操作 ├── ≥ 70% → 从 ISP 申请新 IP 段建议至少 /24 ├── ≥ 90% → 紧急申请标记为 P1 工单 └── 100% → Critical立即扩容参考已有 PPT 输出指标 │ ▼ [3] 扩容操作 扩展操作 → 提供新 IP 段CIDR 起始 IP→ 提交 │ ▼ [4] NRP 自动把新 IP 段加入公共 IP 池 │ ▼ [5] 验证Operator 门户 - NRP - 公共 IP 使用情况 - 利用率下降4.4 ⚠️ 静态路由环境的容量扩容陷阱关键陷阱与上篇 §8.3 对应如果网络拓扑里选择了静态路由而不是 BGP 路由公共 IP添加新公共 IP 段后必须为每个新 IP 在数据中心交换机上手动添加静态路由——这是上篇 §8.3 的延续扩容前先确认客户是 BGP 还是静态路由——这是容量规划阶段的遗留问题新建系统建议 BGP。5. 故障前的预防清单四类检查L3 最佳实践预防 排错。在生产上线前 / 容量变更前 / 版本升级前应做四类检查5.1 物理网络巡检检查项方法频率BMC 网络可达性从 HLH ping 每个物理机的 iDRAC IP每周ToR 双链路状态登录 ToRshow interface status每周MLAG 状态show mlag detail每周5.2 SDN 资源健康检查项方法频率NC VM 状态Operator 门户 - 区域管理 - 角色每日SLB MUX 状态同上每日公共 IP 池使用率Operator 门户 - 容量管理每日重点DNS 解析测试从 DVMResolve-DnsName internal.azurestack.local每日5.3 容量预警检查项阈值公共 IP 池70% / 90% / 100% 三档详见 §4SLB VIP 池视部署规模NSG 规则数每 NSG 默认上限5.4 版本与补丁检查项备注当前 azs 版本检查 Update 状态OEM 固件 / 驱动版本与 Support Matrix 比对Microsoft 公告是否有未处理的已知问题6. 故障现象 1VIP 连通性失败最常见故障之一VIP 是租户对外服务的唯一入口VIP 不通意味着所有外部访问都受影响。6.1 故障诊断流程图[租户报告我的网站打不开了] │ ▼ [1] 验证 VIP 自身可达性 测试方法Test-NetConnection -ComputerName VIP -Port Port │ ├── TCP 端口通 → VIP 工作正常转查后端 ├── TCP 端口失败 → 继续 │ │ │ ▼ │ [2] 验证后端 VM 自身是否在运行 │ Operator 门户 / SCVMM - 检查 VM 状态 │ │ │ ├── VM 停止 → 启动 VM │ ├── VM 运行 → 继续 │ │ │ ▼ │ [3] 验证后端 VM 的端口是否在监听 │ RDP 到 VMnetstat -an | findstr :port │ │ │ ├── 不监听 → 检查应用配置 / 服务状态 │ ├── 监听 → 继续 │ │ │ ▼ │ [4] 验证 NSG / 后端 ACL 是否允许 │ 检查 Backend NSG 的入站规则 │ │ │ ├── 拒绝 → 修正 NSG │ ├── 允许 → 继续 │ │ │ ▼ │ [5] 验证 SLB 后端池是否健康 │ Operator 门户 / PowerShell - SLB 健康探测 │ │ │ ├── 不健康 → 检查 health probe 配置 │ └── 健康 → 检查 NSG / 入栈 NAT 规则 │ │ │ └─→ 进入下篇 §数据面抓包 │ └── PING 失败 → 【正常】SLB 不支持 ICMP详见 §106.2 五步定位表步骤检查项检查方法失败时①托管服务的 VM 是否已启动并运行Operator 门户 - VM 状态启动 VM②VM 监听的端口RDP 到 VMnetstat -an或Get-NetTCPConnection检查应用配置③从 DVM / 控制台 VM 用 Test-NetConnection 探测端口Test-NetConnection -Port port排除 DVM 自身网络问题④VM 本地防火墙Get-NetFirewallProfile调整防火墙规则⑤NSG 入站 NAT 规则Operator 门户 - NSG修正 NSG6.3 关键事实避免误判L1 微软硬要求VIP 由 SLB 管理只支持 TCP / UDP不支持 ICMP——这是关键提示所以即使一切配置正确从外部 PING VIP 也会失败不要把 PING 失败当成VIP 不通正确的连通性测试是Test-NetConnection -Port而不是Ping。6.4 修复常见模式失败点修复方法VM 已停止启动 VMVM 启动但应用未启动启动应用 / 配置自动启动VM 本地防火墙拒绝关闭防火墙生产建议改规则不建议关闭或添加允许规则NSG 入站拒绝添加 NSG 入站规则允许该端口SLB 后端池不健康修正 health probe 端口 / 协议入站 NAT 规则错误重新配置 NAT 规则7. 故障现象 2出栈 NAT 无法访问 Internet7.1 故障诊断流程图[租户报告我的 VM 访问不了 Internet] │ ▼ [1] VM 是否有 Public IP Operator 门户 → VM → 网络接口 → IP 配置 │ ├── 有 PIP → 用自己的 PIP 出栈参照 §14 上篇 ├── 无 PIP → 继续 │ ▼ [2] 该 VM 所在 vNet 是否有 vNet NAT IP Operator 门户 → NRP → vNet → 出栈配置 │ ├── 有 NAT IP → 用 vNet NAT IP 出栈 │ │ │ └─→ 检查是否真的访问了 Internettracert 看路径 │ │ │ └── 路径过 ToR → 出栈正常问题可能在远程端 │ ├── 无 NAT IP → 继续 │ ▼ [3] 公共 IP 池是否耗尽 Operator 门户 → 容量 → 公共 IP 池 │ ├── 100% Critical → 立即扩容详见 §4 ├── 100% → 继续 │ ▼ [4] 默认出栈 NAT 是否被关闭罕见 Operator 门户 → NRP → vNet → 出栈 NAT 开关 │ ├── 关闭 → 打开出栈 NAT └── 开启 → 检查 vSwitch / NSG7.2 关键问题清单关键问题用途租户是否无法通过 DNS 名称到达对端但能到达 IP 地址区分 DNS 故障 vs 出栈故障尝试从遇到问题的 VM 上的命令行向外部端点运行 Tracert查看第一跳出栈路径如果数据包已通过 ToR 交换机那么问题很可能在数据中心网络而非 Azure Stack Hub 内部区分内部 vs 外部故障7.3 出栈 NAT 的两个常见误判L3 最佳实践没配网关怎么出去—— 上篇 §4 已说明Azure Stack Hub默认启用vNet 级出栈 NAT租户不需要配置网关PING 公网 IP 不通 ≠ 出栈故障—— 即使出栈正常公网也会因为防火墙 / ICMP 过滤而不响应 PING。应该用curl https://www.bing.com或Test-NetConnection bing.com -Port 443来验证出栈。8. 故障现象 3DNS 解析失败8.1 故障诊断流程图[租户报告我的 VM 解析不了域名] │ ▼ [1] 验证 ping IP 通不通 │ ├── IP 通 → 出栈正常问题在 DNS ├── IP 不通 → 转 §7 出栈 NAT │ ▼ [2] 验证 DNS 服务器是 168.63.129.16 来自 VMipconfig /all │ ├── 自定义 DNS如租户手填→ 临时改为 168.63.129.16 重试 ├── 默认 → 继续 │ ▼ [3] 测试到 MAS-DNS 的连通性 Test-NetConnection 168.63.129.16 -Port 53 │ ├── 通 → DNS 服务器响应 ├── 不通 → 继续 │ ▼ [4] 查询名称类型 │ ├── Azure Stack Hub 内部名称如 *.azurestack.local │ → iDNS 应能解析 ├── 外部名称如 www.bing.com │ → 检查 DNS 转发器 / 数据中心上游 DNS │ ▼ [5] 如果是 Azure Stack 内部名称 → 检查 iDNS Forwarder 配置 如果是外部名称 → 检查数据中心上游 DNS / DNS 转发器可达性8.2 关键问题清单关键问题处置租户 DNS 设置是否被手动改过应回退到 168.63.129.16MAS-DNS 端口 53 是否可达Test-NetConnection 168.63.129.16 -Port 53要解析的名称是 Azure Stack 内部还是外部内部iDNS外部DNS 转发器8.3 DNS 排错的常见误判L3 最佳实践租户手改 DNS 服务器 → 失败—— 默认指向 168.63.129.16添加自定义 DNS作为 vNet 设置 → 可能丢 iDNS 递归解析—— 自定义 DNS 仅在租户 VM 内生效iDNS 的递归 DNS 解析能力丢失外部名称解析失败 ≠ Azure Stack Hub 故障—— 可能是上游 DNS 转发器问题。9. 故障现象 4边缘网关 / VPN 异常9.1 故障诊断流程图[租户报告VPN 隧道断了 / 本地资源访问不了] │ ▼ [1] VPN 连接对象是否已创建 Operator 门户 - 网络 - VPN 连接 │ ├── 未创建 → 创建 Local Network Gateway VPN Connection ├── 已创建 → 继续 │ ▼ [2] 网关 VIP 是否已分配 Operator 门户 → VPN 连接 - 网关 IP │ ├── 未分配 → 上篇 §11.3 提示在创建连接前不会分配 VIP这是预期行为 ├── 已分配 → 继续 │ ▼ [3] 本地 VPN 设备是否已配置 │ ├── 未配置 → 参考 §9.3 设备兼容性 / 9.4 IPSec 参数 ├── 已配置 → 继续 │ ▼ [4] IKE 阶段 1 / 阶段 2 协商成功 Operator 门户 - VPN 连接状态 / 本地 VPN 设备日志 │ ├── IKE 失败 → 检查 Pre-Shared Key / IKE 版本 / IPSec 算法匹配 ├── IKE 成功 → 继续 │ ▼ [5] 数据流测试 从 Azure Stack Hub VM 测试到本地网络 IP 从本地网络测试到 Azure Stack Hub VM IP9.2 VPN 排错的两类常见陷阱L3 最佳实践VPN 状态显示未连接 ≠ 故障在创建连接资源之前不会获得 VIP上篇 §11.3 已说明即使配置完成有实际流量前状态可能显示断开连接——这是正常行为不要因状态显示断开就直接重启 Gateway——会让客户 VPN 隧道意外中断。VPN 带宽瓶颈 ≠ Azure Stack Hub 限制上篇 §13.1 已说明 S2S VPN 带宽受隧道最大吞吐量带宽限制但微软未给出固定数字实操建议业务规划阶段实测避免被纸面参数误导。9.3 VPN 设备兼容性L0 官方事实Azure Stack Hub 的VPN 设备兼容性与 Azure 公有云共用同一份清单——参考 https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices。Azure Stack Hub 不独立维护 VPN 设备清单实操影响① 客户 VPN 设备不在该清单里时Azure Stack Hub 也不支持② 自定义 IPSec / IKE 策略的可用算法与 Azure 公有云一致。9.4 IPSec / IKE 默认策略精确表L0 版本事实——PPT 直接给出Main Mode 策略默认值参数取值DiffieHellmanGroupGroup2IntegrityAlgorithmSHA256EncryptionAlgorithmAES256SALifeTimeSeconds1234SALiftimeKiloBytes2000Quick Mode 设置参数取值PerfectForwardSecrecyPFS2048AuthenticationTransformationConstantSHA256128CipherTransformationConstantDES3SALifeTimeSeconds1233IdleDisconnectSeconds500SALifeTimeKiloBytes2000使用方式本地 VPN 设备配置时这三组参数必须与 Azure Stack Hub VPN 一致否则 IKE 阶段 1 协商就会失败。10. 四个常见误判信号没有明说但实操里最频繁导致误操作的四个假象。本文作为补足。10.1 误判 1VIP PING 失败 故障L1 客观事实 L3 最佳实践真实现象VIP PING 永远会失败因为 SLB 不支持 ICMP详见 §6.3正确动作用 TCP 端口测试代替 PING——Test-NetConnection -Port避坑不要给客户VIP 通或VIP 不通的判断除非用端口测试。10.2 误判 2VPN 显示未连接 故障L3 最佳实践真实现象见 §9.2 上篇 §11.3——未创建连接前无 VIP创建完成但无流量也可能显示未连接正确动作先看是否有实际流量需求再决定是否重启 Gateway避坑重启 Gateway 短暂中断所有 VPN 隧道非必要不要做。10.3 误判 3DNS 解析失败 DNS 故障L3 最佳实践真实现象可能是 DNS 服务器故障也可能是上游 DNS 转发器问题还可能是 vNet 配置了自定义 DNS导致 iDNS 失效详见 §8.3正确动作用 168.63.129.16 当 DNS 临时回退测试避坑不要先重启 DNS 服务——大概率问题不在 DNS 服务本身。10.4 误判 4静态路由 公共 IP 失效 公共 IP 异常L0 官方事实 L3 最佳实践真实现象上篇 §8.3 已说明——静态路由模式下每个新公共 IP 都需要为数据中心交换机添加静态路由正确动作扩容公共 IP 后先查数据中心交换机路由表再下结论避坑这是容量变更最容易踩的坑——扩容了公共 IP 但忘了手动配静态路由结果公共 IP 加了但访问不了。11. 日志收集Get-AzureStackLog11.1 日志收集的 cmdletL1 微软硬要求PPT 给出精确的日志收集命令Microsoft 内部运维 cmdletGet-AzureStackLog -OutputPath C:\AzureStackLogs -FilterByRole NRP,NC,SLB,Gateway11.2 四个目标角色角色含义NRPNetwork Resource Provider 网络资源提供者NCNetwork Controller 网络控制器SLBSoftware Load Balancer 软件负载均衡器GatewayEdge GatewayS2S VPN Gateway网关11.3 适用场景场景是否触发租户报网络资源创建失败一般不需要——是 NRP 问题先看 Operator 门户告警VIP 不通已排除 §6 的所有步骤需要收集日志VPN 隧道异常已排除 §9 的所有步骤需要收集日志Azure Stack Hub 系统级问题需要收集日志11.4 ⚠️ 重要边界L1 客观边界这是 Microsoft 内部运维 cmdlet通常在以下情况执行OEM Support 工程师在客户现场调试时执行微软 Support 工程师通过远程会话执行租户 / 企业 IT 通常不需要执行——遇到网络问题联系 OEM Support 或微软 Support。租户在使用 Operator 门户时通常不会用到此 cmdlet——这是 Microsoft 内部运维的一环不应被租户当成日常维护工具使用。11.5 日志收集后的流程[1] 在 DVM 或 ERCS VM 上执行 Get-AzureStackLog │ ▼ [2] 收集到的日志以 zip 形式保存到 OutputPath │ ▼ [3] 上传到 OEM Support / 微软 Support 案件 │ ▼ [4] Support 工程师分析后给出修复建议12. 运维节奏上线 / 巡检 / 处置 / 复盘本文全生命周期运维节奏把单点排错升级为可重复的运维流程。12.1 上线前检查项工具 / 阈值BMC 网络可达性HLH → 每个 iDRACToR 双链路状态show interface statusMLAG 状态show mlag detailAz PowerShell Operator 端点可达Add-AzEnvironment AzS-ERCS01DNS 默认指向 168.63.129.16登录各 VMipconfig /allNSG 模板准备默认规则审计公共 IP 池容量≥ 一个 /24预留 30%12.2 日常巡检检查项频率工具NC / SLB / Gateway 健康每日Operator 门户 - 区域管理公共 IP 池利用率每日Operator 门户 - 容量管理DNS iDNS 解析测试每日Resolve-DnsName internal.azurestack.localBMC 网络 ping每周HLH物理交换机端口错误每周show interface counters errors过期事件 / 公告每月Microsoft 公告 OEM 通报12.3 故障处置 SOP标准模板[1] 故障接收工单系统记录现象、时间、影响范围 │ ▼ [2] 故障定位参见 §6-§9 流程图 │ ▼ [3] 故障处置执行相应修复VM 启动 / NSG 修正 / Gateway 重启等 │ ▼ [4] 故障验证用端口测试 / PING IP / DNS 测试 等核对 │ ▼ [5] 故障归档纳入知识库 │ ▼ [6] 故障复盘4 个问题 ├── 根本原因是什么 ├── 为什么之前没被发现 ├── 怎么做能预防下次 └── 是否需要变更流程12.4 ⚠️ 运维红线绝对禁止L1 微软硬要求红线后果修改 ToR 配置OEM 验证的集成网络被破坏可能引发整个集群降级改 BMC 网络配置失去带外管理硬件故障无法修复删除 NRP / NC VM整个网络栈崩溃需要 OEM 重部署直接 Reboot ERCS VM错误操作会破坏升级状态在 NRP 关闭状态强制恢复仅微软 Support 可操作删除公共 VIP 网络在用段正在用 PIP 的所有 VM 立即失联13. 下篇小结Azure Stack Hub 网络栈的管理与排错可以分成三个层次13.1 监控层§3-§4网络健康监控告警Operator 门户 - 区域管理告警本身不等于故障公共 IP 池容量告警70% / 90% / 100% 三档阈值——这是 L0 官方事实租户请勿拖延到 100%四个核心组件的角色NRP / NC / SLB / Gateway——出问题先看是哪个角色。13.2 排错层§5-§10排错方法学先看现象是否真的存在避开四个常见误判信号再按诊断流程图逐项排除四类典型故障VIP 连通 / 出栈 NAT / DNS 解析 / VPN 异常——每类都有现象 → 五步检查 → 修复流程关键背景SLB 不支持 ICMP VIP PING 永远失败 ≠ 故障VPN 状态显示未连接可能是预期行为。13.3 运维层§11-§12日志收集Get-AzureStackLog -FilterByRole NRP,NC,SLB,Gateway—— 主要是 OEM / 微软 Support 工具运维节奏上线前 / 日常巡检 / 故障处置 / 故障复盘——四个阶段都需要 SOP运维红线不修改 OEM 验证的物理 / 网络配置不擅自重启 ERCS VM不在生产时段做破坏性变更。13.4 与上篇的连接上篇讲网络是怎么搭的——本文讲网络是怎么查的上篇区分的L0/L1/L2/L3四层在排错时仍适用L1 客观约束如SLB 不支持 ICMP——理解约束比绕过约束更重要L3 最佳实践如公共 IP 用 BGP 宣告——建设阶段就避免常见问题。维护说明维护版本v1.02026-07-27 首发核心来源 内训资料 Azure Stack Hub 网络服务版本基础azs-1901 至 azs-2503 当前主流版本如版本与本文表述不一致以当期版本 Azure Stack Hub Operator 文档为准上篇文件名azure-stack-hub-network-overview-and-tenant-services.md文末引用本文严格区分四层L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践容量告警阈值 70%/90%/100% 保留原值——属 L0 官方事实VPN Main Mode / Quick Mode 默认参数保留——属 Microsoft 官方默认值不写任何未经微软权威来源认证的性能数字