windows共享文件夹高可用性核心是将其作为群集角色部署在故障转移群集上：常规文件服务器（主动-被动）适用于主文件夹、部门共享等通用场景；横向扩展文件服务器（sofs，主动-主动）适用于hyper-v、sql server等高性能场景，需csv和smb 3.0+支持。
要让 windows 共享文件夹具备高可用性，核心是把它作为群集角色（clustered file server）部署在 windows 故障转移群集（wsfc）上，而不是单独在某台服务器上共享。这样当一个节点故障时，共享自动切换到另一节点，客户端几乎无感知。
文件服务器群集角色类型要选对
Windows 支持两种高可用文件服务器模式，适用场景不同：
- 常规群集文件服务器（Active-Passive）：适合主文件夹、部门共享、文档等通用场景。同一时间仅一个节点提供服务，另一个待命。切换后客户端需重连（部分支持 SMB 3.0+ 的客户端可自动重试）。
- 横向扩展文件服务器（SOFS，Active-Active）：必须配合群集共享卷（CSV）和 SMB 3.0+，所有节点同时提供同一共享服务。适用于 Hyper-V 虚拟机存储、SQL Server 数据库文件等高性能、低延迟场景。
⚠️ 注意：SOFS 不支持传统 NTFS 权限继承的复杂 ACL 场景，且要求底层存储支持 CSV（如 S2D、SAN、vSAN），普通 NAS 或本地磁盘不可用。
共享磁盘或存储必须满足群集要求
群集依赖共享存储来存放共享文件和群集配置，常见合规方案包括：
- 使用 iSCSI 或 FC 连接的 SAN 存储，划分独立 LUN 并只映射给该群集所有节点
- Windows Server 2016+ 的存储空间直通（S2D），利用各节点本地 SSD/HDD 构建冗余池
- Azure VMware 解决方案 vSAN 上的 CAB（Cluster-Across-Box）架构
- 不推荐使用 DFS-N 或复制型 NAS——群集仲裁不支持 DFS，易引发脑裂
✅ 关键检查项：所有节点都能看到同一块磁盘（磁盘签名一致）、磁盘已联机并初始化为 GPT、未分配驱动器号（由群集自动管理）、启用了群集磁盘（在“故障转移群集管理器”中右键磁盘 → “启用群集磁盘”）
见证配置不能省略（尤其双节点）
两个节点的群集属于偶数节点，必须配置见证（Witness）防止网络分区导致脑裂：
-
文件共享见证（FSW）：最常用，需一个独立的、域内（或 Win Server 2019+ 支持工作组）SMB 2.0+ 文件服务器，创建专用空文件夹（如
\witnesswsfc-fsw），群集安装时指定路径即可 - 避免把见证放在群集节点或同机架设备上——物理隔离才有效
- 不要用 DFS 共享、OneDrive 或云同步文件夹做见证路径
DNS 和网络设置必须统一
群集名称（如 CLUSFILE）和文件共享名（如 \CLUSFILEDocs）依赖 DNS 正确解析。常见失败原因：
- 各节点主 DNS 后缀不一致（如
node1.contoso.comvsnode2.local） - DNS 后缀搜索列表顺序不同，导致 Kerberos 认证失败（日志报“状态 5”错误）
- 群集 IP 地址未在 DNS 中静态注册，或被 DHCP 动态覆盖
✅ 建议：所有节点使用相同域后缀；禁用“注册此连接的地址在 DNS 中”选项（网卡高级设置）；手动在 DNS 中添加 A 记录指向群集 IP，并勾选“仅允许由群集管理器更新”
创建与验证步骤要闭环
- 安装前确保两节点已加入同一域、时间同步（NTP）、防火墙开放群集端口（TCP 3343、SMB 445 等）
- 使用“故障转移群集管理器”运行验证向导（Validation Wizard），重点看“存储”和“网络”测试是否全绿
- 创建群集后，添加“文件服务器”角色，选择“常规文件服务器”或“横向扩展文件服务器”
- 添加共享资源时，指定群集磁盘上的卷（非本地盘），设置共享名、NTFS/SMB 权限、离线缓存策略
- 测试：手动逐个关闭节点，观察共享是否在 30 秒内自动上线；用
net use z: \CLUSFILEDocs验证映射连续性
不复杂但容易忽略细节
