Azure Local 多机架（Rack Aware Cluster）部署（系列篇之二）

文档定位：基于 azloc-2606 官方部署文档（deploy-via-portal、deployment-azure-resource-manager-template、deploy/rack-aware-cluster-post-deployment、network-atc-overview、add-server、repair-server、host-network-requirements）。
适用版本：Azure Local 2510 及以后（azloc-2606 官方原文：Rack aware cluster 自 Azure Local 2510 起可用）。
配套：本文是连载 ①《规划篇》的执行章节。规划阶段产出物就绪后再启动部署。

1. 部署前清单（azloc-2606 官方硬要求）

1.1 Azure 侧

• Azure 订阅 + 资源组（azloc-2606 deploy-via-portal 原文）
• 注册 Arc、注册 RP 三个：Microsoft.HybridCompute / Microsoft.AzureStackHCI / Microsoft.GuestConfiguration（azloc-2606 部署前置）
• Service Principal（用于 Arc Resource Bridge） + Client secret
• Azure Local Resource Provider 的 Object ID：00001111-aaaa-2222-bbbb-3333cccc4444（azloc-2606 deployment-azure-resource-manager-template 原文）
• Key Vault（不能配 Private Endpoint—— azloc-2606 deploy-via-portal 原文 "Azure Local doesn't support deploying a cluster using an existing Azure Key Vault that has Private Endpoints enabled"）
• 区域在 8 个 public region 或 US Gov Virginia 或 China（21Vianet）之一

1.2 AD / 身份

• AD DS 域已准备（OU、AzureStackLCMUser、DEPLOYMENT 账户）
• 域 FQDN、OU 路径
• Local administrator 凭据（所有节点统一，14 字符以上、大小写+数字+特殊字符）
• 部署账户的 domain join 权限

1.3 节点侧

• OS 镜像：使用与现网同 solution version 的 OS image（azloc-2606 add-server 原文明示："For versions 2503 and later, you must use the OS image of the same solution as that running on the existing cluster"）。不要用 Azure portal 拉 image——portal 列表不全。
• 每节点 4 端口（2 mgmt+compute SET + 2 storage 独立）
• 物理布线和 TOR 全部按规划篇连通
• BIOS / TPM / Secure Boot 已按 OEM 规范设置

1.4 网络侧

• 跨房间 RTT 实测 ≤ 1 ms
• DCB（PFC + ETS）已在 TOR / spine 全部配置
• MSTP / LLDP / DCB TLV 全部启用
• VLAN 7 / 8 / 711 / 712 / 99 在所有 TOR / spine 已配置

2. 部署模式选择（azloc-2606 deploy-via-portal 原文）

portal 在 Basics 页第一个选项叫Cluster options：

• Standard= 单机架 cluster
• Rack aware cluster= 多机架 cluster（azloc-2606 deploy-via-portal 原文）

选错不可改。要重选只能销毁重建（azloc-2606 没说能转换，按现状理解为不可逆）。

azloc-2606 给出两种部署入口：

• Azure portal（deploy/deploy-via-portal）—— 推荐首套
• ARM template（deploy/deployment-azure-resource-manager-template）—— 文档原文："We recommend that you deploy a system via the Azure portal first, and then perform subsequent deployments via the ARM template"（先 portal，再 ARM）

真实场景：先 portal 跑通一个 2+2，验证布线 / 延迟 / 兼容性，再用 ARM 模板批量复制。混用 portal + template 在同一 cluster 改状态可能留脏数据。

3. Azure Portal 部署流程（azloc-2606 deploy-via-portal 原文步骤）

3.1 启动 wizard

1. Portal → 搜 "Azure Local" → 选 "Azure Arc | Azure Local"
2. Get started→Create instance

3.2 Basics 页

• 选 Subscription / Resource Group
• 输 Instance name
• 选 Region
• Cluster options → Rack aware cluster（关键选项）
• Identity provider（默认 AD+Key Vault；可选 Local identity with Key Vault）
• + Add machines→ 选已 Arc-registered 节点
• Install extensions（自动跑，等几分钟）
• Validate selected machines（绿色 ✓ 才继续）

Validation 失败的常见原因（azloc-2606 原文）：wrong extension version、symmetric network adapter 检查不过、OS version 不一致。

3.3 Configuration 页

• New configuration / Template spec / Quickstart template
• rack aware 推荐New configuration（不要在首套用 template spec）

3.4 Networking 页（重点）

第一个选择：storage 网络是否过 switch（azloc-2606 原文）：

• "No switch for storage"：节点间直连
• "Network switch for storage traffic"：走 TOR，rack aware 必须选这个

第二个选择：traffic grouping，azloc-2606 原文给出 4 种模式：

1. Group all traffic（全合 SET，不推荐rack aware）
2. Group management and compute traffic（mgmt+compute 一组，storage 独立）←rack aware 推荐
3. Group compute and storage traffic（compute+storage 一组，mgmt 独立）
4. Custom configuration

rack aware 选 2：

• intent 1 = management + compute（用 mgmt NIC SET 队）
• intent 2 = storage（用 2 块独立 NIC）

每个 intent 给 2 块匹配 adapter（冗余 + SET）。

• storage intent 必须用高速 NIC（25 GbE 起步）
• storage intent 的VLAN ID填 TOR 上配的（711/712）
• Portal 不让手工指定 storage intent 的 IP（azloc-2606 原文："Portal deployment doesn't allow you to specify your own IPs for the storage intent"）。需要自定义 IP → 改走ARM template。
• 高级选项（azloc-2606 原文可调）：
  • Storage traffic priority（PFC priority）
  • System traffic priority（5/6/7）
  • Storage traffic bandwidth reservation（%）
  • Jumbo frame：1514 / 4088 /9014（iWARP 必须配 9216，9014 是 portal 选项下限）
  • RDMA protocol：iWARP / RoCE / RoCEv2 / disabled
• IP 分配：Manual 或 Automatic（DHCP）

3.5 Management 页

• Custom location name
• Storage account for cloud witness
  • 重要：rack aware 默认 cloud witness（azloc-2606 post-deployment 原文："By default, rack aware cluster uses a cloud witness"），可改为 local witness
• AD Domain FQDN
• OU 路径（不能放在顶级域）
• Deployment account 凭据
• Local administrator 凭据

3.6 Security 页

• Recommended（azloc-2606 默认）= Secured-core 最高
• Customized= 可关某些项
• rack aware 不建议改 → 选 Recommended

3.7 Advanced 页

• "Create workload volumes and required infrastructure volumes (Recommended)"
• "Create required infrastructure volumes only"（薄卷后续手动建）
• 重要提醒（azloc-2606 原文）："Don't delete the infrastructure volumes created during deployment"

Volume resiliency 自动规则（azloc-2606 deploy-via-portal 原文）：

rack aware 起步 2+2 = two-way mirror；3+3 / 4+4 = three-way mirror

重要边界：这是部署阶段默认创建的基础卷行为，不代表后续工作负载卷必须采用相同方式。post-deployment 阶段可以基于容量利用率、容错需求和业务等级选择 Two-way 或 Four-way（含 RLNM 4-way mirror）。

3.8 Validation + Deploy

• Start validation（约 15 分钟，节点多则更久）
• 验证成功 →Create触发部署
• 部署时长：azloc-2606 ARM 模板文档说"2.5 到 3 小时"；portal 略快
• 不要在 validation 任务运行时点 Try again（azloc-2606 原文警告）

4. ARM 模板部署（azloc-2606 deployment-azure-resource-manager-template 原文）

azloc-2606 ARM 文档给出 8 步，重要节点：

4.1 准备阶段

• Service principal + client secret for ARB（azloc-2606 原文）
• 拉取 Azure Local RP 的 Object ID：

  (Get-AzADServicePrincipal -ApplicationId "00001111-aaaa-2222-bbbb-3333cccc4444").Id

  az ad sp list --filter "appId eq '00001111-aaaa-2222-bbbb-3333cccc4444'" --query "[0].id" -o tsv

• 准备参数 JSON（azuredeploy.parameters.json）
• 模板版本选择：
  • 2503+：选create-cluster
  • 2411.3 及更早：选create-cluster-2411.3

4.2 部署模式

azloc-2606 ARM 模板有两个阶段（azloc-2606 原文）：

1. Validate模式：建 Azure 资源，验 readiness，约 10 分钟
2. Deploy模式：实际部署，2.5-3 小时

两个模式都跑：

• 先 Validate
• 成功后再Redeploy切到 Deploy

4.3 ARM 模板关键参数（rack aware 关注项）

模板默认对 storage 网络会做 SMB 加密（smbClusterEncryption）。如果对 RDMA 吞吐要求极致，先评估性能影响再决定是否关。官方未给数字。

4.4 ARM 模板的 storage intent IP

• ARM 模板能指定 storage intent 的 IP（portal 不能）
• 节点多 / 子网分段时必须用 ARM

5. 部署后必做事项（azloc-2606 rack-aware-cluster-post-deployment 原文）

5.1 验证 cluster 形态

• Azure portal → Azure Local 资源 → Properties →Cluster type = "Rack aware cluster"（不是 "Standard" 才算成功）
• Infrastructure → Machines →按 local availability zone 分组显示

5.2 验证 quorum witness

• 默认是 cloud witness（azloc-2606 原文）
• 如果业务要求全本地化，手动改为 local witness

5.3 验证 workload volumes

azloc-2606 post-deployment 原文给出RLNM（Rack Level Nested Mirror）验证命令：

spaceutil get-space -name <volume-name>

输出关键字段：

RLNM 提供 2-way 与 4-way 两种创建方式，应基于容量利用率、容错需求和业务等级选择（azloc-2606 post-deployment 原文只给出 New-Volume 命令示例，未明示"推荐"配置）。创建命令（azloc-2606 原文）：

# 4 路 fixed New-Volume -FriendlyName "FourCopyVolumeFixed" -StoragePoolFriendlyName "SU1_Pool" ` -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror ` -PhysicalDiskRedundancy 3 -ProvisioningType Fixed # 4 路 thin New-Volume -FriendlyName "FourCopyVolumeThin" -StoragePoolFriendlyName "SU1_Pool" ` -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror ` -PhysicalDiskRedundancy 3 -ProvisioningType Thin # 2 路 fixed New-Volume -FriendlyName "TwoCopyVolumeFixed" -StoragePoolFriendlyName "SU1_Pool" ` -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror ` -PhysicalDiskRedundancy 1 -ProvisioningType Fixed # 2 路 thin New-Volume -FriendlyName "TwoCopyVolumeThin" -StoragePoolFriendlyName "SU1_Pool" ` -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror ` -PhysicalDiskRedundancy 1 -ProvisioningType Thin

-PhysicalDiskRedundancy 3= 4 路镜像 = RLNM
-PhysicalDiskRedundancy 1= 2 路镜像 = 2-way with RLNM
ReFS 在 rack aware 上是默认且官方推荐

5.4 创建 storage path

每个 workload volume 必须配 storage path 才能跑 Azure Local VM（azloc-2606 原文）。具体命令见manage/create-storage-path-azure-local。

6. 用 Network ATC 手工配置（azloc-2606 network-atc-overview 原文）

若不走 portal/ARM 模板，用 Network ATC 手工配置。关键 cmdlet：

# 定义 mgmt+compute intent（SET） Add-NetIntent -Name "Mgmt_Compute" ` -Management ` -Compute ` -AdapterName "Ethernet1","Ethernet2" ` -VlanName "MGMT_VLAN" -VlanID 7 ` -VlanName "COMPUTE_VLAN" -VlanID 8 # 定义 storage intent（独立 NIC，不走 SET） Add-NetIntent -Name "Storage1" ` -Storage ` -AdapterName "Ethernet3" ` -VlanID 711 Add-NetIntent -Name "Storage2" ` -Storage ` -AdapterName "Ethernet4" ` -VlanID 712

azloc-2606 network-atc-overview 原文："Storage intent 可以定义在一个 intent 里最多一个"。两个 storage intent 用两块独立 NIC 是官方推荐。
azloc-2606 还说："Stretch：Adapters are set up similarly to a storage intent, except RDMA can't be used with stretch intents"——这是历史 HCI 22H2 的 stretch 概念，rack aware 不用 stretch intent（rack aware 用普通 storage intent）。

7. 节点增删（azloc-2606 add-server / repair-server 原文）

7.1 扩容规则（azloc-2606 add-server 原文）

azloc-2606 add-server 文档对普通 cluster的扩规则是：

• 1→2 / 2→3 / 3→N 节点
• 每次加 1 个
• 存储重平衡自动跑

但对rack aware来说（azloc-2606 rack-aware-cluster-overview 原文）：

• 必须成对加：2+2 → 3+3 → 4+4
• 不允许 2+3、2+4 这种非对称
• 上限 4+4

重要边界：Add-Servercmdlet本身支持一次加一个节点（azloc-2606 add-server 原文）。上述"成对加"是Rack Aware Topology 的 Validation 限制，而不是 PowerShell cmdlet 的限制——即 cmdlet 会执行，但 rack aware 拓扑验证会拒绝非对称配置。

7.2 加节点命令（azloc-2606 add-server 原文）

在新节点上：

1. 装 OS（与 cluster 同 solution version）
2. Arc register（与现网同 Resource Group / Region / Subscription / Tenant）
3. 赋权限：Azure Stack HCI Device Management Role + Key Vault Secrets User

在现网某节点上：

$HostIpv4 = "<新节点 IPv4>" $Cred = Get-Credential Add-Server -Name "<新节点名>" -HostIpv4 $HostIpv4 -LocalAdminCredential $Cred

记下输出的 operation ID，监控：

$ID = "<Operation ID>" Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID

存储重平衡会跑几天（azloc-2606 原文："can run for multiple days depending on the number of the nodes and the storage used"）。验证：

Get-VirtualDisk | Get-StorageJob

空输出 = 重平衡完成。

7.3 修节点（azloc-2606 repair-server 原文）

repair 触发场景：

• 主板 / BMC / HBA / NIC / GPU 故障
• 数据盘不支持热插拔时

流程（azloc-2606 原文）：

1. 确认健康 → Pause + Drain → Shut down
2. 删 Azure Arc resource 上的 lock + Delete
3. 装 OS（同 solution version）
4. Adapter 改名对齐（Rename-NetAdapter -Name "..." -NewName "Management"）
5. Arc register + 赋权限
6. 在现网某节点跑：

   $Cred = Get-Credential Repair-Server -Name "<节点名>" -LocalAdminCredential $Cred

7. 监控 operation ID
8. 等待 storage rebalance

7.4 节点允许的硬件差异（azloc-2606 add-server / repair-server 原文）

7.5 重跑失败

Add-Server -Rerun Repair-Server -Rerun

azloc-2606 原文："Starting with the 2508 release, validation runs after you execute the Add-Server command. If a test fails, the validator returns information to help you resolve the failure."

7.6 拉日志给 Support

azloc-2606 原文：

Get-ActionPlanInstance -ActionPlanInstanceID $ID | out-file log.txt Send-DiagnosticData # 在新加/修的节点上跑

8. SDN 与 rack aware

azloc-2606 software-defined-networking 文档原文："SDN isn't supported on stretched (multi-site) clusters"。

这条说的是跨数据中心stretched，不是rack aware。Rack aware 是个 cluster 内的两个 local availability zone，不跨站点，所以：

• SDN 在 rack aware 上支持（azloc-2606 reference-architecture 原文："This configuration supports environments with or without software defined networking (SDN) or Layer 2 virtual networks"）
• 官方参考架构建议把 NC（Network Controller）部署在 Azure Local Cluster 内部的 VM 上
• SLB / Gateway VM 也建议部署在 cluster 内（每个 AZ 至少 1 个）
• BGP peering 与 ToR 之间按 rack aware 拓扑配置

9. 部署后立刻要做的几件事

1. 登录 portal → Azure Local 资源 → 看 Cluster type（必须 "Rack aware cluster"）
2. 看 Machines 按 availability zone 分组（2+2 显示 2 节点 / 2 节点）
3. 跑spaceutil get-space验证 workload volume 是 RLNM 4-way mirror
4. 测跨房间延迟：用Test-NetConnection -Port 445测 SMB TCP RTT（这是 TCP 往返延迟，不是 RDMA latency），并配合 ntttcp / iperf3 / VMFleet 测 RDMA 路径的吞吐与延迟（RDMA 需用专门工具，PowerShellTest-NetConnection不能测 RDMA latency）
5. 测 SMB 吞吐（建议用diskspd或VMFleet）
6. 配置 witness 类型（如需 local witness 替换 cloud）
7. 配 backup（系统卷、工作负载卷分别配）
8. 创 Azure Local Insights（azloc-2606 monitor-cluster 路径）
9. 创 Update Manager 调度（azloc-2606 update-cluster 路径）
10. 演练 rack-level failover（azloc-2606 推荐"conduct live migration and failover testing"）

10. 部署阶段常见错误与恢复

11. 部署阶段交付物

• 部署模式记录（portal 还是 ARM）
• 模板 JSON（如果是 ARM）
• Cluster name / Arc resource ID / RP Object ID
• Key Vault 信息（确认无 Private Endpoint）
• storage account for witness
• Witness 类型（cloud / local）
• AD OU 路径
• Network ATC intent 列表（name / adapter / VLAN）
• Volume 列表（name / 4-way mirror / RLNM 验证输出）
• Storage path 列表
• Initial baseline（DiskSpd / VMFleet 性能基线）
• 跨房间 RTT 实测值
• 监控 / 备份 / 更新计划

12. Local Availability Zone 与 Fault Domain 的部署后约束

Rack Aware Cluster 的 Local Availability Zone 信息是在部署过程中根据 Rack 分布自动生成的：

• 部署完成后不建议手工修改 Fault Domain 结构（如手动调整 Rack 归属、改变 Storage Fault Domain 类型）
• 任何破坏性调整（如Get-StoragePool | Set-StoragePool改 FaultDomainTypeId）可能导致：
  • RLNM 4-way mirror 副本分布失效
  • CSV 重定向策略异常
  • 后续Add-Server/Repair-Server验证失败
• azloc-2606 部署流程对 Fault Domain 的创建是单向的——一旦生成，仅可通过重新部署 cluster 调整

规划阶段建议：

• 部署前反复确认Rack 划分与节点归属
• 第一次部署先在非生产环境跑通rack aware topology
• 部署后如确需调整 Fault Domain，完整备份数据后销毁重建