Azure Stack Hub 部署准备：DNS / 终结点 / Public IP / 边缘拓扑 / 身份 / Readiness / NTP

未经同意，请勿转载！

系列：第 2 篇（共 5 篇）— 部署前 1-2 周必读 对应 PPT：slide 6-11（终结点 / DNS / Public IP / 边缘部署 / 身份 / ReadinessChecker / NTP） 主题：Azure Stack Hub 部署前需要完成的所有"软"准备工作（网络规划已在 doc 01 完成） 责任团队：网络架构师 + 身份团队 + 运维团队 输出：NTP / DNS 集成 / 身份联邦 / ReadinessChecker 全 PASS / Public IP 段就绪

0. 这篇解决什么

问题：doc 01 完成了 IP / 段 / VLAN / BGP 的结构规划。但结构规划就绪不代表网络真正打通——本文解决部署前 1-2 周必须验证的 7 个"软"准备工作：

1. Azure Stack Hub 终结点能否从外部访问？（DNS 集成）
2. Public IP 地址块如何添加到 Azure Stack Hub？
3. 边缘部署的网络拓扑选哪种？
4. 身份提供者选 Microsoft Entra ID 还是 AD FS？
5. AD FS / Graph 联邦怎么与现有 AD 集成？
6. AzsReadinessChecker怎么用、怎么通过？
7. NTP 时间服务器怎么配置？

这 7 项任何一项遗漏，OEM 工程师到场当天都会发现"网络规划做了，但没真正打通"——延期 1-2 周。

1. ⭐ L1 / L2 / L3 三层决策框架

2. ⭐ L1 Azure Stack Hub 终结点与 DNS 集成

2.1 终结点清单

部署完成后，Azure Stack Hub 提供三类终结点（PPT slide 6）：

2.2 DNS 集成架构

Azure Stack Hub 内部 DNS 解析架构：

Tenant VM Infra Role (168.63.129.16) (168.63.129.16) │ │ └──────────────┬───────────────┘ ▼ iDNS proxy │ ▼ ┌────────────┴────────────┐ │ │ ▼ ▼ AZS-DC01 (递归解析) AZS-DNS01 (权威解析) │ │ ▼ ▼ *.azurestackhub.local sea.azurestackhub.external (内部区域) (外部权威区域) + Contoso.com (租户自定义) │ ▲ ▼ │ External DNS ───委派────── Azure Stack Hub DNS

关键点：

• Tenant VM 和 Infra Role使用168.63.129.16作为 DNS（Azure 内部 DNS 魔术 IP）
• iDNS proxy转发到 AZS-DC01（递归）和 AZS-DNS01（权威）
• External DNS收到外部查询后，通过委派转发到 AZS-DNS01
• 企业内部 DNS必须为<region>.<external-domain>子域添加NS 记录指向 AZS-DNS01

2.3 DNS 集成的可选方式 [L1]

[L1]Microsoft 文档并未限定必须用 NS 委派。企业可结合自己 DNS 架构选择：

采用 DNS Delegation 时，企业 DNS 配置示例：

<region>.<external-domain>. IN NS azs-dns01.<region>.<external-domain>. <region>.<external-domain>. IN NS azs-dns02.<region>.<external-domain>.

采用 Delegation 时的额外步骤：

1. 企业内部 DNS（如 Windows DNS / BIND / Infoblox）上添加 NS 记录
2. NS 记录对应的 A 记录（glue record）已配置（AZS-DNS01 / AZS-DNS02 的 Public VIP IP）
3. 委派生效后，从企业外部nslookup adminportal.<region>.<external-domain>应能解析到 Public VIP

2.4 DNS 集成 Checklist

至少满足以下一项：

• 企业 DNS 已将<region>.<external-domain>子域委派到 Azure Stack Hub 内部 DNS
• 企业 DNS 已为<region>.<external-domain>添加 Conditional Forwarder
• 企业 DNS 上已添加 Split DNS（内网 / 外网分别配置）
• External DNS 服务已配置指向 Azure Stack Hub

验证项：

• 从企业外部nslookup能解析<region>.<external-domain>子域
• 从企业外部能解析adminportal.<region>.<external-domain>
• 从企业外部能解析portal.<region>.<external-domain>

3. ⭐ L1 Public IP 地址管理

3.1 Public IP 添加流程

部署后，可以随时向 Azure Stack Hub 添加公共 IP 地址块：

① 从 ISP / 上游获得可路由的地址块 │ ▼ ② 添加到 Azure Stack Hub（管理员门户） │ ▼ ③ 验证 IP 不与现有范围重叠 │ ▼ ④ 完成添加

3.2 强制约束 [L1]

[L1]微软硬要求（PPT slide 7 原文）：

1. Azure Stack Hub 接受任何有效地址块，前提是：
   • 地址块有效（不是保留 / 测试段）
   • 不与现有地址范围重叠
2. 地址块必须可路由（不是 RFC 1918 私有段）
3. 不得与 Azure Stack Hub 所连接的外部网络重叠
4. ⚠️添加范围后无法删除——必须提前规划，保留足够的 Public VIP 空间

3.3 Public IP 容量规划

[L3]推荐规划（Microsoft 未给固定大小，参考经验）：

实际 Public VIP Network 大小应以官方容量规划、Stamp 规模、未来扩容需求为准。Microsoft 官方文档未规定固定大小，本表仅作参考。

预留原则：每多 10 个公共终结点（API 服务 / VPN Gateway / Load Balancer）预留 1 个 VIP；管理类终结点（adminportal / portal / adminmanagement）也消耗 VIP。

3.4 Public IP 添加 Checklist

• Public IP 段是 ISP 已分配的可路由段
• Public IP 段与现有 Azure Stack Hub 内部 IP 段不重叠
• Public IP 段与外部网络（企业网 / 上游）不重叠
• Public IP 段已通过 ISP / 上游 BGP 广播
• 一次性提交所有 Public IP 段（添加后无法删除）

4. ⭐ L1 边缘部署网络拓扑

4.1 两种典型场景

[L1]微软定义两种边缘部署模式：

场景 1：防火墙在边界之上（推荐用于大型数据中心）

Internet │ ┌─────────────┴─────────────┐ ▼ ▼ Firewall 1 Firewall 2 (HA 互联) (HA 互联) │ │ └──────────┬────────────────┘ ▼ ┌──────────┴──────────┐ ▼ ▼ Border 1 Border 2 │ │ └──────────┬──────────┘ ▼ ┌──────────┴──────────┐ ▼ ▼ TOR 1 ◄──MLAG──► TOR 2 │ (Peer Link) │ └──────────┬──────────┘ ▼ Azure Stack Hub (含 BMC 网络)

支持：

• ✅ 主动-主动防火墙配置
• ✅ 主动-被动防火墙配置
• ✅ BGP / 静态路由

场景 2：边界路由器作为统一入口（中小型 / 简化部署）

Internet │ ▼ Edge Router ┌──┴──────┐ ▼ ▼ Firewall 1 Firewall 2 (HA 互联) (HA 互联) │ │ └────┬────┘ ▼ ┌─────┴─────┐ ▼ ▼ TOR 1 ◄──MLAG──► TOR 2 │ (Peer Link) │ └─────┬─────────┘ ▼ Azure Stack Hub

支持：

• ✅ 仅主动-主动防火墙配置
• ⚠️ 依赖 ECMP + BGP 故障转移

4.2 选型决策树

大型企业数据中心？ （≥ 2 个 ISP + 多 AZ） │ ┌─────┴─────┐ Yes No │ │ ▼ ▼ 场景 1（Border） 中小型？ （≤ 1 个 ISP） │ ┌────┴────┐ Yes No │ │ ▼ ▼ 场景 2 场景 1 (Edge) (Border)

4.3 关键约束 [L1]

[L1]微软硬要求：

1. TOR 交换机之间必须有 MLAG Peer Link（多机箱链路聚合）
2. TOR 交换机之间必须有 IBGP Backup Link（内部 BGP 备份链路）
3. TOR 与 BMC直连（带外管理）
4. 不得修改已验证的 Azure Stack Hub 网络配置——简单调整可能允许，但任何重大修改都可能破坏 OEM 认证

[L3]推荐：

• 双 ToR + 双 Border + 双 Firewall 全冗余
• BGP ASN 用私有范围（64512-65534），避免与上游冲突
• 配置 ECMP（等价多路径），依赖 BGP 自动故障转移

5. ⭐ L1 身份提供者选择

5.1 两种身份提供者

[L1]微软强制：部署前必须决定，且部署后不可切换。

5.2 决策 Checklist

• 企业是否能联网 Azure？（决定 Entra ID vs ADFS）
• 是否有 Azure 订阅？（Entra ID 必填）
• 是否有企业 AD 联邦需求？（ADFS 必填）
• 合规要求是否要求本地身份？（可能强制 ADFS）
• 谁是 Entra ID Global Administrator？（Entra ID 部署时必填）

5.3 Entra ID 部署的注意事项

[L3]Entra ID 部署需要：

1. 一个 Microsoft Entra ID 租户（不能是默认的microsoft.onmicrosoft.com）
2. 该租户有Global Administrator权限的账户
3. 部署后，需要在 Azure Portal 中授予 Azure Stack Hub 应用权限
4. 计费订阅与 Entra ID 租户不一定是同一个（在 doc 05 注册时讨论）

5.4 ADFS 部署的注意事项

[L1]ADFS 部署需要：

1. 一个企业 AD 域（Azure Stack Hub 会创建自己的 ADFS 场）
2. ADFS 与现有 AD 通过联合信任（federation trust）集成
3. Graph 服务与现有 AD 通过LDAP集成（用于 RBAC）
4. 现有 AD 用户的 UPN 必须能在 Azure Stack Hub 域中解析

6. ⭐ L1 AD FS / Graph 联邦

6.1 联邦架构

Azure Stack Hub ADFS 企业 AD │ │ │ Federation Trust │ ├──────────────────────────────┤ │ （证书互信 / SAML） │ │ │ │ LDAP (Graph) │ ├──────────────────────────────┤ │ （用户查找 / RBAC） │ │ │ ▼ ▼ Azure Stack Hub 用户 企业 AD 用户 （来自 ADFS 信任） （主数据源）

6.2 集成步骤

[L1]必填步骤：

1. 导出 ADFS 元数据：从 Azure Stack Hub 部署完成后导出的 ADFS 元数据 XML
2. 建立联合信任：在企业 ADFS 上添加 Azure Stack Hub 为信赖方（relying party）
3. 配置 LDAP 查找：Graph 服务通过 LDAP 查询企业 AD 的用户 / 组
4. 测试用户登录：用企业 AD 用户登录 Azure Stack Hub 门户

6.3 联邦 Checklist

• Azure Stack Hub ADFS 元数据已导出
• 企业 ADFS 已添加 Azure Stack Hub 为信赖方
• 企业 ADFS 与 Azure Stack Hub ADFS 证书互信
• LDAP 服务账户已配置（对 AD 有读权限）
• 测试用户能从企业 AD 登录 Azure Stack Hub 门户

7. ⭐ L2 AzsReadinessChecker 工具

7.1 工具作用

[L2]AzsReadinessChecker 是 Dell OEM 工程师必跑的工具（实际上所有 OEM 部署流程都建议跑）。它验证：

7.2 安装与使用

# 安装模块 Install-Module -Name Microsoft.AzureStack.ReadinessChecker -Repository PSGallery # Microsoft Entra ID 就绪检查 Invoke-AzsReadinessChecker -Location <region-name> ` -AzureDirectoryTenant <tenant-id> ` -AzureDirectoryId <entra-app-id> ` -Password <secure-password> # AD FS 就绪检查（部署后从 ERCS 运行） Invoke-AzsReadinessChecker -Location <region-name> ` -AadTenant <tenant-id> ` -AadAdminCredential <pscredential>

7.3 输出解读

7.4 ReadinessChecker Checklist（部署前 1 周）

• 模块已安装（Install-Module完成）
• Microsoft Entra ID 路径：所有验证项 ✅ PASS
• AD FS 路径：所有验证项 ✅ PASS
• 失败项已修复并重跑至全部 PASS
• 验证报告存档（部署后审计用）

8. ⭐ L1 NTP 时间服务器

8.1 为什么 NTP 关键

[L1]时钟不同步会导致：

1. Kerberos 票据失败——内部服务之间认证失败
2. 证书验证失败——PKI 证书链的时间戳校验失败
3. 日志分析失败——跨节点日志时间不一致
4. 复制 / 同步失败——内部数据同步协议超时

8.2 NTP 要求 [L1]

[L1]强制要求：

1. 解析为两个或多个 NTP 服务器 IP 地址的主机名（推荐 2-4 个）
2. 使用IP 地址（而非主机名）以避免 DNS 依赖循环
3. 联网部署：可使用 Internet 上的公共 NTP（如time.windows.com）
4. 离线部署：必须用企业内部的 NTP 服务器（可达）
5. 必须支持 NTP v4

[L1]非 Windows NTP 服务器特殊要求：

如果 NTP 服务器不是 Windows 服务器，必须在 IP 末尾追加 ",0x8" 示例：10.1.1.123,0x8

8.3 NTP 影响范围

Azure Stack Hub 内部以下组件依赖 NTP：

8.4 NTP 配置 Checklist

• NTP 服务器 IP 列表已就绪（≥ 2 个）
• NTP 服务器可达性已验证（w32tm /query /status）
• 非 Windows NTP 已加,0x8后缀
• Azure Stack Hub 内部所有节点都能访问 NTP 服务器
• 部署完成后用 PEP 验证：Get-AzsTimeServer（参考 doc 04 §5）

9. 部署准备 Checklist 总览

完成本文 7 项 + doc 01 的 12 项后，OEM 工程师到场前需要：

全部 ☐ → ✅才能进入 doc 03 证书管理与 doc 04 安装部署。

10. 一句话总结

doc 01 完成"网络结构规划"，本文完成"网络真正打通 + 身份就绪 + NTP 就绪"——7 项软准备工作全部 ✅ 后，OEM 工程师到场就有完整的ConfigurationData.json+ 就绪的环境 + 通过的 Readiness 报告，部署当天不会卡壳。

11. 下一步

进入证书管理，覆盖：

• §1 推荐证书策略（PKI / SAN / 信任链）
• §2 就绪性检查器 8 项验证
• §3 证书与密钥轮换（30 天预警）

附录 A：本篇对应 PPT slide 索引