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

Portal → 搜 "Azure Local" → 选 "Azure Arc | Azure Local"
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 种模式：

Group all traffic（全合 SET，不推荐rack aware）
Group management and compute traffic（mgmt+compute 一组，storage 独立）←rack aware 推荐
Group compute and storage traffic（compute+storage 一组，mgmt 独立）
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 原文）：

节点数	Volume Resiliency
Single machine	Two-way mirror
Two machines	Two-way mirror
Three machines +	Three-way mirror

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 原文）：

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

两个模式都跑：

先 Validate
成功后再Redeploy切到 Deploy

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

参数	含义	rack aware 注意点
deploymentMode	Validate / Deploy	必须分两步
keyVaultName	KV 名字	不开 Private Endpoint
clusterName	cluster 名称（云端）	不能与任何节点同名
witnessType	Cloud（2 节点）	rack aware 2+2=Cloud
clusterWitnessStorageAccountName	witness SA	共享 OK
localAdminUserName / Password	节点本地管理员	全节点一致
AzureStackLCMAdminUsername / Password	LCM admin	AD 账户
hciResourceProviderObjectID	RP Object ID	上面查的
arcNodeResourceIds	节点 Arc 资源 ID 数组	rack aware 4/6/8 个
domainFqdn	AD 域 FQDN
namingPrefix	部署对象名前缀
adouPath	OU 路径	不能顶级
securityLevel	Recommended / Customized	默认 Recommended
driftControlEnforced	安全默认值漂移控制
credentialGuardEnforced	Credential Guard
smbSigningEnforced	SMB 签名防 relay
smbClusterEncryption	集群内 SMB 加密	storage 网络上加密
bitlockerBootVolume / DataVolumes	BitLocker 加密
wdacEnforced	Application Control
streamingDataClient / euLocation / episodicDataUpload	遥测

模板默认对 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>

输出关键字段：

Configuration	NestedFdType	MaxFdType
4-way mirror with RLNM	Node	Rack
2-way mirror with RLNM	Unknown	Rack
No RLNM, Storage domain is set to RACK	(null)	Rack

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 原文）

在新节点上：

装 OS（与 cluster 同 solution version）
Arc register（与现网同 Resource Group / Region / Subscription / Tenant）
赋权限：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 原文）：

确认健康 → Pause + Drain → Shut down
删 Azure Arc resource 上的 lock + Delete
装 OS（同 solution version）
Adapter 改名对齐（Rename-NetAdapter -Name "..." -NewName "Management"）
Arc register + 赋权限

在现网某节点跑：

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

监控 operation ID
等待 storage rebalance

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

组件	合规检查	行为
CPU	同或更多核	不满足 → 警告但允许
内存	同或更大	不满足 → 警告但允许
盘	同数据盘数	不满足 → 错误，阻断

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. 部署后立刻要做的几件事

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

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

错误	原因	恢复
Validation 失败：wrong extension version	Arc extension 没装齐	重跑 Install extensions
Validation 失败：asymmetric NIC	网卡型号/速度不一致	换一致 NIC
Validation 失败：OS version mismatch	节点 OS 不一致	用同 solution version 镜像重装
Deploy 卡在 "Deploy Moc and ARB Stack"	RP/ARB 启动慢	正常，等 40-50 分钟（azloc-2606 原文）
Cluster type 显示 "Standard"	部署时选错 cluster options	不可改，需销毁重建
Storage IP 冲突	portal 默认 IP 与物理网冲突	改用 ARM 模板手工指定 IP
RDMA 性能不达标	DCB / PFC / ETS 没配齐	逐跳检查 TOR / spine
Storage pool 不可见	Pool 创建失败 / Cluster 创建失败 / Deployment Rollback / SBL 初始化失败	查`Get-StoragePool`/`Get-ClusterLog`定位

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 调整

规划阶段建议：