Azure Local 上的 SOFS + FSLogix 整理

一、核心定位

1.1 一个常被混淆的点（先讲清楚）

"Azure Local 上的 SOFS"在当前生态里有两种含义，需要分清：

第一类是 Azure Local 自身的数据平面，已经由 Azure Stack HCI OS 提供——它内部在跑 S2D、Cluster、SMB、CSVFS。

第二类才是本文的主题——用户可管理的、面向业务工作负载的 SOFS 文件服务器。这一类的部署位置由用户决定。

1.2 业务 SOFS 的部署位置选择

[官方]Azure Local 宿主 OS（Azure Stack HCI OS）是一个受管控的 OS，不支持用户在宿主上添加 Failover Clustering 角色、SOFS 文件服务器角色，或在其上创建用户可管理的 SMB 共享（宿主 OS 上的 SMB 端点专供虚机/CSV 使用，不对外开放为业务共享）。

[社区]因此 AzureLocal.cloud 给出的业务 SOFS 部署模式是：在 Azure Local 上跑一组 Guest VM，在 VM 内部署 WSFC + S2D + SOFS，形成"嵌套集群 / Guest Cluster"。

[分析]这个模式称为"guest cluster on hyperconverged"——在 VMware vSAN、Hyper-V on Windows Server、Nutanix 上跑 SOFS 时也用同样的范式，是行业里成熟做法。

评审注：原文写"唯一可行路径"过于绝对。准确说法是"当前微软支持、且经社区验证的业务 SOFS 部署方式"。未来不排除微软提供其他选择（例如原生的 Azure Local File Service、Storage Replica 集成等），但截至 2026-07 这些都还未发布。

二、整体架构

2.1 分层视图

2.2 Stacked Resiliency（堆叠弹性）

[社区]AzureLocal.cloud 称之为 Stacked Resiliency——两层独立镜像：

[分析]注意"单物理节点 down → 带走 1 个 SOFS VM"是建立在 Anti-Affinity 规则生效的前提下（见 §6.1）。如果两个 SOFS VM 落在同一物理节点，单节点故障会带走 2 台 VM，超出 guest 镜像的容忍能力，整个 FSLogix 服务可能中断——所以这一节的"零中断"承诺实际上是"Anti-Affinity 配置正确时的承诺"。

三、关键设计决策（社区经验）

AzureLocal.cloud 把架构选型拆成3 个独立维度，每维给出"推荐"和"可选"两档：

3.1 决策矩阵

[实践]Triple Layout 的三个卷通常对应：

• Profiles（用户 Profile Container）
• ODFC（Office Data File Container，Office 缓存）
• AppData（其他应用持久化数据）

3.2 决策组合（社区经验）

[分析]这些数字来自 AzureLocal.cloud 的经验建议，不是微软官方的 Windows Server 限制。实际选型应结合：用户数 × profile 大小 × IOPS 需求 × 节点硬件规格。

评审注：原文把这些数字说成"推荐"但未注明来源，已修正为"社区经验建议"。

四、组件规格

4.1 为什么 ReFS（不要再说"避免元数据开销"）

[官方]微软对 S2D 上用户卷的推荐是ReFS（Storage Spaces Direct 的 ReFS 集成特性）。原因不是"避免 NTFS 元数据开销"（这个说法没有官方依据），而是 ReFS 在 S2D 上提供了以下特性：

• Block Clone：VHDX/Profile Container 等稀疏文件场景下极大加速
• Accelerated VHDX Operations：配合 Hyper-V / FSLogix 的 .vhdx 文件操作
• Mirror-Accelerated Parity：在混合部署里提升性能
• Integrity Streams：端到端校验和保护
• Allocate-on-write Metadata：减少碎片
• Fast Extensible Checkpoint：快速备份/恢复

[实践]S2D 卷上不要用 NTFS，会失去上述特性。ReFS 是微软对 S2D 用户卷的明确推荐。

4.2 关于 SMB Encryption

[官方]Continuously Available (CA) Share≠SMB Encryption。

• CA（持续可用）：SOFS 默认启用。透明故障转移由多个 SMB3 机制共同实现：
  • Persistent Handle：客户端句柄在节点切换后仍有效
  • Witness Protocol：客户端被通知服务端拓扑变化
  • Transparent Failover：客户端无需重连、不中断 I/O
  • Continuous Availability：共享级别的可用性属性 Persistent Handle 是其中关键组成之一，但不是全部。
• SMB Encryption（加密数据）：是独立的功能，需要 Server 端或 Share 端策略显式启用。默认未开启。

[实践]可根据合规要求启用 SMB Encryption；它会带来一定的 CPU 开销（一般 5–10%），高吞吐场景需评估。

评审注：原文写"默认开启"是事实错误。

五、跟微软官方"SOFS on S2D"实现的对照

微软 Learn 在 Windows Server 标准文档里描述的"SOFS on S2D"模式，通常场景是：

• 直接装在 Windows Server 物理机或 Tier-1 VM
• 宿主直接 S2D，没有"嵌套"

核心区别：Azure Local 上你必须处理S2D 嵌套——宿主层 S2D 在跑 CSV，guest VM 内再做一次 S2D。容量上双重折扣。

六、关键设计细节

6.1 Anti-Affinity（反关联）——强制

[社区] 必须：3 个 SOFS VM 必须落在 3 个不同物理节点。

[分析] 原因：如果不配置反关联，单物理节点故障可能带走 2 台甚至 3 台 SOFS VM，超出 guest 镜像（两路）的容忍能力，整个 FSLogix 服务中断——这违背了"高可用"初衷。

[官方] 实现方式：

• Azure Local 23H2+ / Windows Server 2025：New-ClusterAffinityRule+DifferentNode类型
• 旧版本：AntiAffinityClassNames兼容方案

6.2 节点数

[官方]微软 WSFC 一直支持 2 节点 + Witness 的配置（包括 Cloud Witness）。

[社区]AzureLocal.cloud推荐 3 节点——理由是 Stacked Resiliency 在双节点场景下不稳（任何一层都只有 2 副本，叠加后故障容忍反而比单层低）。

评审注：原文"三节点是底线"是错误表述。准确说法：微软支持 2 节点；社区推荐 3 节点。

6.3 Cloud Witness

[官方]Azure Storage Account Cloud Witness 是微软在 Azure / 云端部署场景下推荐的仲裁模式之一（另外还有 File Share Witness、Disk Witness）。

[实践] 优势：

• 不需要第三台 Witness VM 或文件共享
• 成本低
• 管理简单
• 跨站点部署方便

[分析] 关于"与 Azure Local 自己的 quorum 解耦"： 这句话表述不清。Guest Cluster 和 Host Cluster 本来就是两个独立的 WSFC，quorum 自然独立。Cloud Witness 并不是因为"解耦"才好，而是因为上面列的实际优势。

[分析] 适用边界：

• Azure / 混合云场景：Cloud Witness 优势明显，社区和微软均推荐
• 纯本地 Windows Server Cluster（无 Azure 订阅）：很多客户仍使用 File Share Witness
• 完全离网 / Disconnected Azure Local：Cloud Witness 需评估是否可用（依赖出站到 Azure Storage）

6.4 网络端口

SOFS VM 之间：

SOFS → AVD Session Hosts：

[实践]SOFS 与 AVD Session Host 建议在同一 VLAN / 同一 L2 域，减少路由跳数（影响登录/注销时延）。高吞吐场景可考虑为 SOFS VM 加第二块 NIC 隔离 S2D 复制流量（Azure Local 支持 RDMA）。

6.5 身份认证

[官方]当前 AzureLocal.cloud 方案中，所有 VM（含 SOFS Guest）需要加入AD 域。原因不是 SMB 端点本身需要 AD，而是：

• WSFC 需要 AD：Cluster Name Object (CNO)、Virtual Computer Object (VCO) 都是 AD 计算机对象
• Kerberos SPN：SOFS Client Access Point 的 SPN 注册在 AD
• CNO/VCO 生命周期：依赖 AD 域服务
• NTFS/SMB 授权：用户和组的 SID 来自 AD

[社区探索]AzureLocal.cloud 仓库里另有avd-fslogix-entra-kerberos-resolution.md探索Azure Files + Entra Kerberos路径，去掉传统 AD。但该方案只适用于 Azure Files SMB share，不适用于本地 SOFS Guest Cluster——本地 SOFS 仍然需要 AD。

评审注：原文归因"SMB Endpoint 需要 AD"是次要原因，主因是 WSFC 的 CNO/SPN。

七、容量规划

7.1 双重折扣

[分析]嵌套 S2D 的容量代价是两轮折扣叠加：

原始容量 × (1 / 宿主冗余率) × (1 / guest 冗余率) × 文件系统格式化开销 ≈ 可用容量

7.2 估算示例（社区示例，非硬指标）

[社区示例]两路 + 两路：

[分析] 有效利用率 ≈ 21%。

[实践]真实利用率受多种因素影响：

• VHDX 是否 Fixed / Dynamic
• Thin Provisioning 策略
• CSV Cache 大小
• ReFS Integrity Stream 是否启用
• 文件系统元数据占用

[分析]实测可用容量通常落在20%–28%区间，社区示例的 21% 是理论下限附近的值。具体设计应预留 buffer，不要按 21% 反推。

7.3 用户规模估算（社区经验，非官方指标）

[社区经验]：

[实践]用户实际 profile 大小差异极大（开发人员 50 GB 起、设计/视频用户 100 GB+），应按1.5× 平均用量规划。配合 FSRM（File Server Resource Manager）设置配额告警与自动清理。

八、部署流程（11 阶段）

Phase 0 ── 规划：决策矩阵选型 + 容量估算 + 变量文件 │ ├──── Azure / 宿主层 ────┐ Phase 1 ── 准备 Azure Local 宿主环境 Phase 2 ── 创建 3 个 SOFS Guest VM │ Phase 3 ── 配置 Anti-Affinity 规则 Phase 4 ── VM 加入 AD 域（Guest OS 层操作，与 Arc 无直接关系） Phase 5 ── 安装角色（Failover Clustering、FS-FileServer） Phase 6 ── 创建 Guest Failover Cluster Phase 7 ── 启用 S2D │ ├─ Phase 8A ── Single Layout（单卷 + 单共享） └─ Phase 8B ── Triple Layout（三卷 + 三共享，社区推荐） │ Phase 9 ── 配置 NTFS / SMB 权限（FSLogix 专用） Phase 10 ── 配置防病毒排除项 Phase 11 ── 验证测试

[社区] IaC 工具支持矩阵（2026-07 状态）：

评审注：原文 Phase 4 写"回到 Azure Arc 扩展"，Join Domain 是 Guest OS 内的标准操作，与 Arc 注册无直接依赖关系。

九、FSLogix 配置要点

9.1 Registry 设置（AVD Session Host）

HKLM\SOFTWARE\FSLogix\Profiles\Enabled = 1 HKLM\SOFTWARE\FSLogix\Profiles\VHDLocations = \\<SOFS-DAP>\FSLogix HKLM\SOFTWARE\FSLogix\Profiles\VolumeType = VHDX HKLM\SOFTWARE\FSLogix\Profiles\SizeInMBs = 30720 HKLM\SOFTWARE\FSLogix\Profiles\FlipFlopProfileDirectoryName = 1 HKLM\SOFTWARE\FSLogix\Profiles\DeleteLocalProfileWhenVHDShouldApply = 1 HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithFailure = 0 HKLM\SOFTWARE\FSLogix\Profiles\PreventLoginWithTempProfile = 0

9.2 NTFS 权限

[官方 + 实践]：

[实践]共享权限：Change（Domain Users）+Full Control（FSLogix Ops）。

9.3 防病毒排除

[实践]：

• \\<SOFS-DAP>\FSLogix\*整个共享树
• %ProgramFiles%\FSLogix\Apps\、%ProgramFiles%\FSLogix\Agent\
• 进程：frxsvc.exe、frxdrv.sys、frxccds.exe

十、技术分析：选型背后的"为什么"

这一节是本版本相对上一版最大的增量。前面各节给出"是什么"，这一节讲"为什么"。

10.0 为什么不在 Host CSV 上直接做 SMB 共享，而是再叠一层 Guest S2D

[分析] 这个问题的来源：很多读者第一反应是——Host 已经在跑 S2D 了，为什么不直接在 Host CSV 上挂 SMB 共享、给 FSLogix 用？答案是 Azure Local 宿主 OS 不允许这么做（见 §1.2）。但即使允许，社区和微软仍会推荐 Guest S2D，原因如下：

1. 故障域隔离：Host CSV 故障（损坏、Rebalance、Repair）会直接污染所有依赖它的业务；Guest S2D 在 VM 内部独立管理，故障被 VM 边界吸收
2. 生命周期隔离：Guest S2D 卷的创建、扩容、删除不影响 Host CSV；Host CSV 的 Rebalance 不影响 guest 卷的 IO
3. Guest 自主管理：Guest 集群管理员可以独立分配卷、配额、修复，无需触碰 Host 集群
4. SOFS 独立升级：SOFS 角色 / Windows 补丁升级可以在 Guest Cluster 上滚动进行，不影响 Host
5. 独立 Backup：FSLogix 数据的备份策略与 Host CSV 的备份策略解耦
6. 独立 Storage Ownership：Host S2D 拥有物理盘；Guest S2D 拥有 VM 内的 VHDX，存储所有权清晰，便于审计和配额

[分析] 取舍：代价是容量双重折扣（§7.2）和 CPU/内存开销（Guest VM 必须运行完整 WSFC + S2D）。这是业务隔离 / 弹性 / 可运维性与资源效率之间的权衡。

10.1 为什么不建议把 SOFS VM 放在同一个 CSV

[分析]如果 3 个 SOFS VM 都依赖同一个 CSV：

• 宿主层只有一组镜像副本；CSV 不可用（损坏、Offline、Redirected、Pause、Repair 等）会同时影响所有 VM
• 失去了"节点级故障隔离"的语义——单节点故障变成 3 节点故障
• guest S2D 也救不了，因为底层 CSV 不可用

[实践]三卷布局下，单个 CSV 故障最多影响 1 个 VM，guest S2D 还能容忍，业务不中断。

10.2 为什么 Triple Layout 可以降低 Metadata Contention

[分析]FSLogix Profile / ODFC / AppData 三类 I/O 模式差异：

• Profile：读写混合，元数据密集（每次登录都要读 ntuser.dat 等）
• ODFC：写为主，顺序写为主（Office 缓存回写）
• AppData：读写混合，但访问频率低

[分析]全部放在一个共享时：

• 三类 I/O 在同一卷上争用 NTFS MFT / Change Journal
• 同时被多个 Session Host 访问时，元数据 I/O 热点（NTFS 元数据操作竞争）会显著上升
• ODFC 的大文件写会阻塞 Profile 的小文件元数据更新

[实践]三卷隔离后：

• 每个卷的元数据 I/O 独立
• ODFC 的大块写不会污染 Profile 的元数据流
• 便于独立监控每类工作负载的 IOPS / 延迟

10.3 为什么 Profile / ODFC / AppData 要拆开

[分析] 三大原因：

1. I/O 特性差异（见 §10.2）：大块顺序 vs 小文件元数据 vs 混合负载
2. 备份策略差异：Profile 关键、ODFC 可重建、AppData 业务相关
3. 配额管理独立：可对三类分别设 FSRM 配额和清理策略
4. 故障隔离：一个用户写满 ODFC 不会让所有 Profile 创建失败

10.4 为什么 Guest Cluster 不建议动态内存

[官方]微软长期建议 Cluster 节点（包括 SOFS Guest VM）使用 Static Memory，不在生产 Cluster 中使用 Dynamic Memory。

[分析] 经验层面的解释（非微软官方陈述，但与该建议一致）：

1. 可用内存不断变化：Dynamic Memory 会让 Guest VM 的可用内存动态调整，使 Cache（CSV Cache、Storage Bus Cache）和性能基线难以预测
2. CSV Cache 受内存影响：CSV Cache（默认 512 MB）依赖可用内存，动态内存波动会让 cache 大小不可预测
3. S2D 性能基线：S2D 的 storage bus cache（默认 1 GB / 总内存 8%）需要稳定内存才能有效去重/压缩

[实践]SOFS Guest VM建议固定内存，基线 8 GB 起步。

10.5 为什么不要把 CSV Cache 开太大

[分析]Azure Local Host CSV Cache：

• 默认 512 MB（推荐基线）
• CSV Cache 与 S2D Storage Bus Cache都会消耗宿主内存，需要综合规划内存分配
• 虚机场景下，cache 命中率受虚机内存压力影响，开太大反而 swap 增多

[实践]Microsoft 官方建议 CSV Cache 不超过2 GB（虚机场景）；物理机 SOFS 场景可适度调高，但要先做性能测试。

10.6 为什么 Guest S2D 推荐 Fixed VHDX

[分析]Dynamic VHDX 在 S2D 场景下的问题：

1. 碎片化：动态扩展造成物理块不连续，影响 I/O 局部性
2. 性能不可预测：扩容瞬间 I/O 延迟尖刺
3. 空间回收难：删除文件后动态 VHDX 不会自动 shrink，S2D 池利用率虚高
4. 镜像副本膨胀：两路/三路镜像下，动态 VHDX 的"已分配但未使用"空间也会被镜像复制

[实践]Guest S2D 数据盘推荐 Fixed VHDX；OS 盘可用 Dynamic（节省空间）。

10.7 为什么 SOFS VM OS 盘要和数据盘分开

[分析]：

1. OS 盘故障不应影响数据：如果 OS 盘和数据盘在同一 VHDX 上，OS 损坏会带走数据
2. 镜像开销：数据盘必须参加 guest S2D 镜像，OS 盘没必要参加
3. 备份策略：OS 盘备份（Azure Local 自带）和数据盘备份（FSR/Veeam）策略不同，分开后更清晰

10.8 为什么用 Storage Account Cloud Witness 而不是 SMB 文件共享

[分析]：

[实践]Azure Local 场景下，Cloud Witness 是微软和社区都推荐的选择。

十一、Entra ID Kerberos 探索（独立路径）

来自同一仓库的avd-fslogix-entra-kerberos-resolution.md（2026-03-21 实操记录）。注意：这一段是Azure Files + Entra Kerberos，不是 SOFS 本体。

11.1 验证结果

✅Azure Files + Entra Kerberos（AADKERB）可工作，不依赖传统 AD。

11.2 三个易漏的必需步骤（任一缺失 → 0x0000052E 登录失败）

11.3 关键认知

• kerb1 对称密钥不需要手动同步到 App Registration；它正确放在 Service Principal 的keyCredential（type: Symmetric, usage: Encrypt），不是Application 的passwordCredential
• Graph API 拒绝手动passwordCredentials[].secretText（只读），by design
• 故障现象：Error 0x0000052E（ERROR_LOGON_FAILURE）+Error 1265（ERROR_CANT_ACCESS_DOMAIN_INFO）

11.4 适用性外推到 SOFS

⚠️ 这套 Entra Kerberos 路径是给Azure Files SMB share用的，不是给本地 SOFS guest cluster 用的。本地 SOFS guest cluster 仍然需要 AD（WSFC 的 CNO/SPN 依赖 AD，见 §6.5）。

要彻底去掉 AD，技术上需要等其他演进（例如 Azure Local 原生 SMB 服务、Storage Replica 与 Entra 集成等）。

十二、与云原生方案的对比

[官方]对 Azure 公有云 AVD 场景，微软通常优先推荐 Azure Files 或 Azure NetApp Files；对于Azure Local 离线部署 / Disconnected 场景，本地 SOFS 是主要选择。

评审注：原文写"Azure Files > ANF > 本地 SOFS"是微软推荐的简化表述，但容易误导。实际上不同部署模式（公有云 vs Azure Local）推荐路径不同。

十三、待办与坑点

13.1 设计阶段

• ⚠️Anti-Affinity 必须显式声明，Azure Local 默认调度不保证跨节点
• ⚠️CSV 不要承载 OS 盘：SOFS VM 的 OS 盘和数据盘要分开（见 §10.7）
• ⚠️ReFS 必备：guest S2D 上用 NTFS 会失去 Block Clone 等优化（见 §4.1）
• ⚠️Guest VM 内存固定：不要用动态内存（见 §10.4）
• ⚠️数据盘用 Fixed VHDX：不要用 Dynamic（见 §10.6）

13.2 容量阶段

• ⚠️容量双折扣：两路 + 两路 ≈ 20–28% 可用（见 §7.2）
• ⚠️FSLogix 容器大小：默认 30 GB，ODFC 另算；按 1.5× 平均用量规划
• ⚠️预留 30% buffer：用户增长、profile 膨胀、metadata 增长

13.3 性能阶段

• ⚠️SMB Encryption 按需启用：默认未开启，启用后性能下降 5–10%（见 §4.2）
• ⚠️AVD Session Host 反向：Session Host 不应承载过多并发 profile 操作，避免 noise neighbor
• ⚠️CSV Cache 不超过 2 GB（虚机场景）（见 §10.5）

13.4 安全与运维

• ⚠️AV 与 FSLogix 进程必须排除（见 §9.3）
• ⚠️FSRM 配额 + 自动清理：防止单个用户撑爆共享
• ⚠️监控：CSV 延迟、guest S2D 卷性能、SMB session 数、FSLogix 登录耗时

十四、参考资料

官方（Microsoft Learn）

• Azure Local 概览：Azure Local documentation - Azure Local | Microsoft Learn
• Storage Spaces Direct：Storage Spaces Direct overview | Microsoft Learn
• Scale-Out File Server：Scale-Out File Server for application data overview for Windows Server | Microsoft Learn
• FSLogix Profile Container：https://learn.microsoft.com/en-us/fslogix/profile-container-configuration-reference
• FSLogix on AVD：https://learn.microsoft.com/en-us/azure/virtual-desktop/fslogix-profile-container-configure-azure-files
• Azure Files Entra Kerberos：Microsoft Entra Kerberos Authentication for Azure Files | Microsoft Learn

社区（AzureLocal.cloud）

• 方案首页：SOFS & FSLogix on Azure Local | Azure Local
• 仓库：https://github.com/AzureLocal/azurelocal-sofs-fslogix
• 架构：https://github.com/AzureLocal/azurelocal-sofs-fslogix/blob/main/docs/architecture/overview.md
• 部署：https://github.com/AzureLocal/azurelocal-sofs-fslogix/blob/main/docs/deployment/prerequisites.md