Azure Local 上的 SOFS + FSLogix 整理

一、核心定位1.1 一个常被混淆的点先讲清楚Azure Local 上的 SOFS在当前生态里有两种含义需要分清术语含义谁在用Azure Local 宿主层的 SMB/CSVAzure Local 物理节点本身在跑 S2D Cluster Service SMB CSVFS给虚机提供共享卷微软官方Azure Local 内核用户业务用的 SOFS 文件服务器用 SOFS 角色对外提供 SMB 共享、跑 FSLogix用户业务侧第一类是 Azure Local 自身的数据平面已经由 Azure Stack HCI OS 提供——它内部在跑 S2D、Cluster、SMB、CSVFS。第二类才是本文的主题——用户可管理的、面向业务工作负载的 SOFS 文件服务器。这一类的部署位置由用户决定。1.2 业务 SOFS 的部署位置选择[官方]Azure Local 宿主 OSAzure 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——两层独立镜像层保护故障容忍Azure Local 宿主CSV 镜像社区示例用两路单物理节点 / 单盘故障Guest S2DGuest 镜像社区示例用两路单个 SOFS VM 故障合计堆叠单物理节点 down → 带走 1 个 SOFS VM → guest S2D 自动转移零中断[分析]注意单物理节点 down → 带走 1 个 SOFS VM是建立在 Anti-Affinity 规则生效的前提下见 §6.1。如果两个 SOFS VM 落在同一物理节点单节点故障会带走 2 台 VM超出 guest 镜像的容忍能力整个 FSLogix 服务可能中断——所以这一节的零中断承诺实际上是Anti-Affinity 配置正确时的承诺。三、关键设计决策社区经验AzureLocal.cloud 把架构选型拆成3 个独立维度每维给出推荐和可选两档3.1 决策矩阵维度社区推荐可选方案选择依据宿主 CSV 布局三卷每 VM 一个单卷所有 VM 共享节点级故障隔离 vs 磁盘节省Guest S2D 镜像两路镜像三路镜像容量代价 vs 弹性共享模型Triple Layout3 卷 3 共享Single Layout1 卷 1 共享工作负载隔离 vs 简化[实践]Triple Layout 的三个卷通常对应Profiles用户 Profile ContainerODFCOffice Data File ContainerOffice 缓存AppData其他应用持久化数据3.2 决策组合社区经验环境规模宿主卷镜像共享模型 50 用户单/三两路Single/Triple50–500 用户三卷两路Triple500 用户三卷两路Triple极致弹性三卷三路Triple[分析]这些数字来自 AzureLocal.cloud 的经验建议不是微软官方的 Windows Server 限制。实际选型应结合用户数 × profile 大小 × IOPS 需求 × 节点硬件规格。评审注原文把这些数字说成推荐但未注明来源已修正为社区经验建议。四、组件规格项目社区示例值说明SOFS VM 数量3见 §6.2 关于节点数VM OSWindows Server 2025 Datacenter:Azure Edition Core(Gen2)AzureLocal.cloud 推荐——微软也支持普通 Datacenter CoreVM 规格基线4 vCPU / 8 GB RAM社区示例需按实际负载调集群Windows Failover Cluster[官方]Guest 存储Storage Spaces Direct[官方]镜像两路 / 三路社区推荐两路文件系统ReFS见 §4.1网络SMB3[官方] CA share 透明故障转移见 §4.2 完整机制仲裁Azure Storage Account Cloud Witness[官方] 推荐4.1 为什么 ReFS不要再说避免元数据开销[官方]微软对 S2D 上用户卷的推荐是ReFSStorage Spaces Direct 的 ReFS 集成特性。原因不是避免 NTFS 元数据开销这个说法没有官方依据而是 ReFS 在 S2D 上提供了以下特性Block CloneVHDX/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/OContinuous 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没有嵌套维度标准 SOFS on S2D[官方]Azure Local guest[社区]宿主 OSWindows ServerAzure Stack HCI OSSOFS 部署位置物理机 / Tier-1 VMTier-2 Guest VMS2D 层数单层嵌套双层镜像单层两路/三路宿主两路 guest 两路社区示例仲裁File Share / Disk WitnessCloud Witness社区推荐物理隔离天然必须显式 Anti-Affinity核心区别Azure Local 上你必须处理S2D 嵌套——宿主层 S2D 在跑 CSVguest VM 内再做一次 S2D。容量上双重折扣。六、关键设计细节6.1 Anti-Affinity反关联——强制[社区] 必须3 个 SOFS VM 必须落在 3 个不同物理节点。[分析] 原因如果不配置反关联单物理节点故障可能带走 2 台甚至 3 台 SOFS VM超出 guest 镜像两路的容忍能力整个 FSLogix 服务中断——这违背了高可用初衷。[官方] 实现方式Azure Local 23H2 / Windows Server 2025New-ClusterAffinityRuleDifferentNode类型旧版本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 本来就是两个独立的 WSFCquorum 自然独立。Cloud Witness 并不是因为解耦才好而是因为上面列的实际优势。[分析] 适用边界Azure / 混合云场景Cloud Witness 优势明显社区和微软均推荐纯本地 Windows Server Cluster无 Azure 订阅很多客户仍使用 File Share Witness完全离网 / Disconnected Azure LocalCloud Witness 需评估是否可用依赖出站到 Azure Storage6.4 网络端口SOFS VM 之间端口协议用途445TCPSMBS2D 复制、CSV redirected I/O5445TCPSMB over QUIC如果启用5985-5986TCPWinRM / PSRemoting135TCPRPC Endpoint Mapper49152-65535TCPRPC 动态端口3343UDPCluster Network DriverSOFS → AVD Session Hosts端口协议用途445TCPSMB / FSLogix profile 访问[实践]SOFS 与 AVD Session Host 建议在同一 VLAN / 同一 L2 域减少路由跳数影响登录/注销时延。高吞吐场景可考虑为 SOFS VM 加第二块 NIC 隔离 S2D 复制流量Azure Local 支持 RDMA。6.5 身份认证[官方]当前 AzureLocal.cloud 方案中所有 VM含 SOFS Guest需要加入AD 域。原因不是 SMB 端点本身需要 AD而是WSFC 需要 ADCluster Name Object (CNO)、Virtual Computer Object (VCO) 都是 AD 计算机对象Kerberos SPNSOFS Client Access Point 的 SPN 注册在 ADCNO/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 估算示例社区示例非硬指标[社区示例]两路 两路项目数值原始容量3 VM × 4 盘 × 1 TB 12 TB宿主两路后6 TBGuest 两路后3 TBReFS 格式化后≈ 2.55 TB[分析] 有效利用率 ≈ 21%。[实践]真实利用率受多种因素影响VHDX 是否 Fixed / DynamicThin Provisioning 策略CSV Cache 大小ReFS Integrity Stream 是否启用文件系统元数据占用[分析]实测可用容量通常落在20%–28%区间社区示例的 21% 是理论下限附近的值。具体设计应预留 buffer不要按 21% 反推。7.3 用户规模估算社区经验非官方指标[社区经验]用户数Profile ContainerODFC Container推荐总容量含 buffer50 用户30 GB × 50 1.5 TB5 GB × 50 250 GB≈ 3 TB 原始500 用户30 GB × 500 15 TB5 GB × 500 2.5 TB≈ 30 TB 原始1000 用户30 GB × 1000 30 TB5 GB × 1000 5 TB≈ 60 TB 原始[实践]用户实际 profile 大小差异极大开发人员 50 GB 起、设计/视频用户 100 GB应按1.5× 平均用量规划。配合 FSRMFile 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 状态工具状态PowerShell✅ TestedBicep In ProgressTerraform⚠️ UntestedARM JSON⚠️ UntestedAnsible⚠️ Untested评审注原文 Phase 4 写回到 Azure Arc 扩展Join Domain 是 Guest OS 内的标准操作与 Arc 注册无直接依赖关系。九、FSLogix 配置要点9.1 Registry 设置AVD Session HostHKLM\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 09.2 NTFS 权限[官方 实践]对象ACE权限共享根目录Domain UsersModify共享根目录FSLogix Ops 组Full Control用户目录动态创建SYSTEMFull Control用户目录AdministratorsFull Control用户目录Creator OwnerFull Control仅子对象[实践]共享权限ChangeDomain UsersFull ControlFSLogix 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原因如下故障域隔离Host CSV 故障损坏、Rebalance、Repair会直接污染所有依赖它的业务Guest S2D 在 VM 内部独立管理故障被 VM 边界吸收生命周期隔离Guest S2D 卷的创建、扩容、删除不影响 Host CSVHost CSV 的 Rebalance 不影响 guest 卷的 IOGuest 自主管理Guest 集群管理员可以独立分配卷、配额、修复无需触碰 Host 集群SOFS 独立升级SOFS 角色 / Windows 补丁升级可以在 Guest Cluster 上滚动进行不影响 Host独立 BackupFSLogix 数据的备份策略与 Host CSV 的备份策略解耦独立 Storage OwnershipHost 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 个 VMguest 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 要拆开[分析] 三大原因I/O 特性差异见 §10.2大块顺序 vs 小文件元数据 vs 混合负载备份策略差异Profile 关键、ODFC 可重建、AppData 业务相关配额管理独立可对三类分别设 FSRM 配额和清理策略故障隔离一个用户写满 ODFC 不会让所有 Profile 创建失败10.4 为什么 Guest Cluster 不建议动态内存[官方]微软长期建议 Cluster 节点包括 SOFS Guest VM使用 Static Memory不在生产 Cluster 中使用 Dynamic Memory。[分析] 经验层面的解释非微软官方陈述但与该建议一致可用内存不断变化Dynamic Memory 会让 Guest VM 的可用内存动态调整使 CacheCSV Cache、Storage Bus Cache和性能基线难以预测CSV Cache 受内存影响CSV Cache默认 512 MB依赖可用内存动态内存波动会让 cache 大小不可预测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 场景下的问题碎片化动态扩展造成物理块不连续影响 I/O 局部性性能不可预测扩容瞬间 I/O 延迟尖刺空间回收难删除文件后动态 VHDX 不会自动 shrinkS2D 池利用率虚高镜像副本膨胀两路/三路镜像下动态 VHDX 的已分配但未使用空间也会被镜像复制[实践]Guest S2D 数据盘推荐 Fixed VHDXOS 盘可用 Dynamic节省空间。10.7 为什么 SOFS VM OS 盘要和数据盘分开[分析]OS 盘故障不应影响数据如果 OS 盘和数据盘在同一 VHDX 上OS 损坏会带走数据镜像开销数据盘必须参加 guest S2D 镜像OS 盘没必要参加备份策略OS 盘备份Azure Local 自带和数据盘备份FSR/Veeam策略不同分开后更清晰10.8 为什么用 Storage Account Cloud Witness 而不是 SMB 文件共享[分析]维度Cloud WitnessSMB File Witness第三方 VM 依赖无需要一台额外 Windows VM跨站点天然支持需要 VPN / ExpressRoute成本极低几个 GB 的 blobVM 维护延迟一般blob write取决于网络微软推荐度Azure 场景推荐纯本地场景仍常用[实践]Azure Local 场景下Cloud Witness 是微软和社区都推荐的选择。十一、Entra ID Kerberos 探索独立路径来自同一仓库的avd-fslogix-entra-kerberos-resolution.md2026-03-21 实操记录。注意这一段是Azure Files Entra Kerberos不是 SOFS 本体。11.1 验证结果✅Azure Files Entra KerberosAADKERB可工作不依赖传统 AD。11.2 三个易漏的必需步骤任一缺失 → 0x0000052E 登录失败缺失项原因Admin consentforopenid / profile / User.ReadMicrosoft Graph delegatedAADKERB App Registration 请求这些权限但 tenant 没授权Kerberos 交换拿不到用户身份声明kdc_enable_cloud_group_sidstagon App Registrationcloud-only 身份默认 Kerberos ticket 不含组 SID没有这个 tag → 基于组的 RBAC 无法评估DefaultSharePermissionon storage accountcloud-only 身份不能用 NTFS-style 单用户权限必须有 share-level fallback11.3 关键认知kerb1 对称密钥不需要手动同步到 App Registration它正确放在 Service Principal 的keyCredentialtype: Symmetric, usage: Encrypt不是Application 的passwordCredentialGraph API 拒绝手动passwordCredentials[].secretText只读by design故障现象Error 0x0000052EERROR_LOGON_FAILUREError 1265ERROR_CANT_ACCESS_DOMAIN_INFO11.4 适用性外推到 SOFS⚠️ 这套 Entra Kerberos 路径是给Azure Files SMB share用的不是给本地 SOFS guest cluster 用的。本地 SOFS guest cluster 仍然需要 ADWSFC 的 CNO/SPN 依赖 AD见 §6.5。要彻底去掉 AD技术上需要等其他演进例如 Azure Local 原生 SMB 服务、Storage Replica 与 Entra 集成等。十二、与云原生方案的对比方案优点适用场景SOFS guest cluster on Azure Local本文完全本地、低延迟、强合规、离网可工作合规要求 / 低延迟 / 大规模 AVD 500 用户/ Disconnected 部署Azure Files AADKERB无 AD、云端可扩、跨 region 复制Cloud Cachecloud-only 场景、 1000 用户Azure NetApp Files高 IOPS、企业级大块顺序读写Azure Blob FSLogix Cloud Cache冷存便宜极少使用[官方]对 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.613.2 容量阶段⚠️容量双折扣两路 两路 ≈ 20–28% 可用见 §7.2⚠️FSLogix 容器大小默认 30 GBODFC 另算按 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.513.4 安全与运维⚠️AV 与 FSLogix 进程必须排除见 §9.3⚠️FSRM 配额 自动清理防止单个用户撑爆共享⚠️监控CSV 延迟、guest S2D 卷性能、SMB session 数、FSLogix 登录耗时十四、参考资料官方Microsoft LearnAzure Local 概览Azure Local documentation - Azure Local | Microsoft LearnStorage Spaces DirectStorage Spaces Direct overview | Microsoft LearnScale-Out File ServerScale-Out File Server for application data overview for Windows Server | Microsoft LearnFSLogix Profile Containerhttps://learn.microsoft.com/en-us/fslogix/profile-container-configuration-referenceFSLogix on AVDhttps://learn.microsoft.com/en-us/azure/virtual-desktop/fslogix-profile-container-configure-azure-filesAzure Files Entra KerberosMicrosoft 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