最近接了一个不大不小的项目两台Hyper-V宿主机一台独立的存储服务器就是一台上层跑SMB文件服务、下层带几个盘位的普通服务器要求在上面部署SQL Server 2022故障转移集群实例FCI。听起来好像不难但真正动手才发现独立存储服务器这个前提让整套架构绕了好大一个弯。先说我的结论方案完全可行而且成本控制得很好但关键不在SQL Server那一层而在Hyper-V故障转移集群和共享存储的配合方式——也就是标题里提到的“熔断保护”到底怎么在每一层落实。这篇就完整复盘一下从存储准备、集群搭建、虚拟机配置到SQL FCI安装与故障注入验证的全过程。1. 为什么FCI需要“双份”故障转移以及独立存储服务器怎么接入1.1 先搞清楚FCI对存储的硬性要求SQL Server故障转移集群实例FCI和可用性组AG最大的区别在于存储模式FCI是实例级的高可用同一时刻只有一个节点拥有数据库文件所在的共享磁盘另有一个节点处于待机状态。这就要求底层存储必须能被两个节点“看见”并且只能是同一份数据不能各自一份副本。传统做法是给两个节点接同一个SAN或直连盘阵或者用双控制器存储设备这是最经典也最省心的路径。但现实是很多中小团队预算有限没有集中式SAN手头可能只有一台磁盘比较多的普通服务器。这台服务器能不能充当“独立存储”能但必须借助Hyper-V故障转移集群这一层把物理存储转化为虚拟机可见的共享存储。1.2 我的拓扑两层故障转移一份数据我最终采用的架构是业务客户端 | v SQL Server 2022 FCI运行在虚拟机里 | 集群Node1 / Node2 v Hyper-V故障转移集群两台宿主机 | 通过SMB 3.0访问存储服务器上的共享VHDX v 独立存储服务器Windows Server的SMB文件共享层 底层物理磁盘这里一共发生了两层故障转移宿主机挂了虚拟机在另一台宿主机上拉起SQL FCI节点挂了实例在另一台虚拟机上拉起。无论哪一层出问题最终结果都是客户端连接被顶到健康的节点上——这就是我要的“熔断”效果故障被隔离在当前层面不会穿透到下一层继续放大。1.3 为什么选择SMB共享VHDX而不是iSCSI直连当时在存储接入方式上我纠结了很久iSCSI直连、共享VHDX、SMB文件共享三条路都考虑过。最终选的是存储服务器上用SMB 3.0共享文件夹承载共享VHDX文件Hyper-V集群通过UNC路径引用VHDX。理由也很直接iSCSI直连是两个节点各自通过iSCSI发起会话访问同一个LUN链路和权限都要单独配置故障转移时对SCSI锁的处理比较复杂遇到网络抖动容易出堵锁问题。共享VHDXshared VHDX本身就为Hyper-V集群设计支持两个虚拟机同时附加同一份VHDX正好匹配SQL FCI的存储需求这是官方明确支持的路径。SMB 3.0支持透明故障转移通过存储服务器上的文件服务器角色实现和多通道独立存储节点的网卡带宽可以叠加性能不差。架构很棒但有个细节要特别强调Hyper-V宿主机上不要直接挂载存储服务器的盘符而是让虚拟机通过共享VHDX访问数据。这样宿主机只做计算层存储故障时不会把宿主机整体拖死。2. 存储服务器端磁盘初始化、SMB共享与物理隔离的完整配置2.1 物理磁盘的初始化细节存储服务器我用的Windows Server 2022数据中心版。开机后先认硬件两块4TB机械盘加两块1TB固态盘计划是机械盘做数据盘固态盘做日志或缓存。系统装完只认到一块系统盘剩下的盘需要手动初始化。打开磁盘管理对每块数据盘执行右键磁盘选择“联机”Online。初始化磁盘分区风格选择GPT别选MBR超过2TB的卷必须GPT。新建简单卷分配盘符文件系统NTFS分配单元大小64KB卷标如DATA01。64KB分配单元这个细节很多教程不会提但对数据库文件存放非常重要。数据库页大小是8KB如果分配单元太小比如4KB写入时会频繁跨簇对随机IO性能影响十分明显64KB能更好匹配SQL Server的文件I/O模式。虽然共享VHDX是在文件系统里再开一层底层的块大小依然会影响整体表现。2.2 添加SMB文件共享角色的关键步骤这一步不能只用“共享文件夹”右键必须配置为连续可用性Continuously Available, CA共享这样Hyper-V才能对该共享连接做透明的故障转移。具体操作服务管理器 → 添加角色和功能 → 文件服务器角色勾选“文件服务器”和“存储迁移服务”确认安装。打开“共享和存储管理”或直接用以下PowerShell创建共享$ErrorActionPreference Stop New-SmbShare -Name ClusterShare -Path E:\ClusterShare -FullAccess DOMAIN\HYPERV_HOSTS$ -ContinuouslyAvailable $true -CachingMode Manual -FolderEnumerationMode AccessBased注意几点-FullAccess给的是宿主机机器账号HypHav01$和HyperV02$不是人用的域账号。-ContinuouslyAvailable $true这个参数是CA共享的核心Missing了Hyper-V集群就认为共享不支持透明故障转移创建集群存储时会直接报错。-CachingMode Manual是数据库文件的推荐值不要开“自动缓存”或者“文档缓存”防止SMB客户端缓存与SQL Server自身缓冲机制冲突。权限方面还需要在文件系统层面的ACL里给两台宿主机的机器账号加上完全控制权限$acl Get-Acl E:\ClusterShare $rule New-Object System.Security.AccessControl.FileSystemAccessRule( DOMAIN\HyperV-Hosts, FullControl, ContainerInherit,ObjectInherit, None, Allow) $acl.AddAccessRule($rule) Set-Acl E:\ClusterShare $acl我遇到的一个小坑创建共享时冒号前面写的是域名后面是组名。当时图省事用的是本地Administrators组结果宿主机机器账号不在这个组里客户端连接一直是Access Denied。排查半天才意识到是机器账号权限问题不是密码错误。2.3 网络与链路的“熔断”隔离设计存储服务器的物理网卡我至少用了2块按用途分开管理口 心跳口1Gbps跑集群心跳和管理流量。存储口10Gbps或2块万兆做NIC Teaming只允许宿主机访问VLAN隔离。SMB多通道是SMB 3.0自带的只要存储服务器和宿主机之间有多条物理链路系统会自动做带宽聚合。但我强烈建议给存储流量单独划一个VLAN不要和业务流量混跑。什么原因“熔断保护”思想里最重要的一点是“故障域隔离”——存储网络风暴不能污染业务网络业务网络的拥塞也不能拖垮存储链路。我用的是交换机上的access端口隔离如果网络环境支持PVLAN效果更好。另外共享文件夹所在卷最好不要和系统卷放在同一块物理盘上否则磁盘缓存或IO饥饿会拖累系统分区。在我这个方案里E盘是独立的4TB机械盘。3. Hyper-V故障转移集群创建、验证与仲裁配置3.1 宿主机角色和网络配置的准备工作两台宿主机都是Windows Server 2022装完Hyper-V角色后需要加入同一个域。这一点不能说集群就不能在工作组环境搭但SQL FCI涉及多台虚拟机和域账户统一认证会省去大量权限配置灾难。所以我的步骤是两台宿主机加入域重命名成HYP-HV01、HYP-HV02。每台机器安装Hyper-V角色和故障转移群集功能Install-WindowsFeature -Name Hyper-V, Failover-Clustering -IncludeManagementTools -Restart虚拟交换机vSwitch设计外部交换机绑定物理网卡名称如“vSwitch-业务”。宿主机管理IP和虚拟机网络都走这个交换机心跳用单独一块1G网卡连接两台宿主机和存储服务器三层交换机上划分独立VLAN。3.2 集群验证这一步千万别跳直接建集群的前提是运行“验证配置向导”不通过才给建。我执行的是最大验证集Test-Cluster -Node HYP-HV01, HYP-HV02 -Include Storage, Network, Failover, Hyper-V第一次跑验证的时候网络验证报了个“网络绑定到多个vSwitch”的警告。原因是我把物理网卡的“Microsoft网络客户端”纠结在同一个vSwitch上做管理通信产生绑定冲突。后来我把管理流量改走专用虚拟交换机把业务网卡和存储网卡分开重新验证才通过。还有一个隐藏点集群验证里的“存储”测试对共享存储要求很高如果是直接跑FC或iSCSI的路径验证会很严格。我们走的是SMB路径验证阶段主要检查的是网络连通性和RDMA能力容易通过。但千万不要因此跳过验证后续一旦出问题验证日志能给你提供核心的排查线索。3.3 创建集群和配置仲裁见证验证通过后创建集群New-Cluster -Name CLU-HYPERV -Node HYP-HV01, HYP-HV02 -NoStorage然后用文件共享见证File Share Witness作为仲裁因为只有两个节点不加见证的话任意节点故障都可能导致仲裁丢失整个集群就停摆。文件共享见证要放在存储服务器之外的第三台设备上最好是另一台不参与集群的机器我这里正好有一台跳板服务器放一个空目录即可Set-ClusterQuorum -FileShareWitness \\JUMP-SRV\QuorumShare仲裁的本质作用就是“熔断决策”当两节点通信断开时谁能获得文件共享见证的投票谁才被允许继续提供服务。别小看这个设计它直接影响SQL FCI的可用性——如果仲裁配置不对故障转移会比预期慢很多。3.4 添加存储到集群SMB共享路径如何进入集群存储这一步容易被忽略。在故障转移集群管理器里不是直接“添加磁盘”而是右键“存储” → “添加共享存储”输入\\STORAGE-SRV\ClusterShare。共享若被识别为CA共享会显示为“Cluster Storage”并自动创建一个虚拟磁盘组。PowerShell等价操作Get-ClusterAvailableStorage -SharedVolumeName ClusterShare Add-ClusterSharedVolume -SharedVolumeName ClusterShare这一步如果之前共享创建时没有加-ContinuouslyAvailable $true会一直报“存储不支持”所以再强调一次CA参数是命脉。4. 在共享VHDX上跑SQL FCI虚拟机和磁盘的配合细节4.1 创建虚拟机并附加共享VHDX现在要为SQL FCI创建两台SQL节点虚拟机。每台虚拟机的基本规格4核CPU16GB内存一块系统盘独立的VHDX放在每个宿主机本地不共享再加一块共享VHDX作为SQL数据盘。共享VHDX创建方式存储服务器上在ClusterShare目录下创建VHDX文件比如SQLDATA.vhdx。在第一台虚拟机上添加虚拟硬盘选择“使用现有虚拟硬盘”指向\\STORAGE-SRV\ClusterShare\SQLDATA.vhdx。共享VHDX需要配置为“支持共享”在Hyper-V管理器里该磁盘的“高级功能”页勾选“启用虚拟硬盘共享”。关键规则共享VHDX只能放在集群共享卷CSV或SMB共享上不能放在某台宿主机的本地磁盘否则另一台宿主机无法访问。另外共享VHDX只支持VHDX格式不支持VHD和VHDX Set但Windows Server 2022里VHDX Set其实也支持兼容度更高这里为了简单直接选VHDX。虚拟机磁盘控制器里要把SCSI控制器搞对共享VHDX只能挂在SCSI总线上不能挂IDE。这个坑我们踩过一次后来检查磁盘树才找到原因——创建虚拟机时默认是加在IDE控制器上共享功能根本没法勾选。4.2 双节点虚拟机的HA设置第二台虚拟机的配置一模一样只需要将网络、CPU内存调成一致SQL Server FCI要求两个节点的硬件配置不必完全一样但资源紧张时会导致性能差异。创建完成后右键虚拟机 → 设置确保“自动启动操作”和“自动停止操作”符合预期。更核心的是把虚拟机加入“高可用”将虚拟机移动到可用的宿主机在集群管理器里对两台SQL节点虚拟机设置“首选所有者”分别对应不同宿主机。这才让“双层故障转移”有了真实意义如果HYP-HV02宕机上面运行的SQL节点虚拟机自动在HYP-HV01上启动同时如果SQL节点虚拟机的操作系统级集群发现节点不可用也会自动切到另一个FCI节点上。4.3 存储IO与SQL特性冲突的隐患共享VHDX方案性能一般可以接受但需要注意两个SQL Server 2022的存储特性数据库快照功能在使用共享VHDX时可能受限部分版本会有文件路径校验。混合缓冲区池Hybrid Buffer Pool要求持久化内存PMEM或RDMA-capable存储SMB路径下基本不可用不建议开启。我当时一开始加了个“使用可用的内存优化”配置结果SQL实例启动时日志报警“无法打开文件映射”查了很久才发现是SMB路径不支持某些性能特性。恢复默认配置后一切正常。所以如果你追求极致性能优先考虑iSCSI直连如果追求稳定和成本SMB共享VHDX完全够用。5. SQL Server 2022 FCI安装过程从准备到双节点回归5.1 安装前置组件与防火墙每台虚拟机安装SQL Server之前要准备.NET Framework 4.8Windows Server 2022自带。Windows更新补丁打全。SQL Server安装需要独立域账户我创建了sqlsvc服务账户密码设为复杂密码并在域策略中禁用了“密码永不过期”。防火墙入站规则开放TCP 1433SQL Server、TCP 5022可用性组端点等。不过FCI场景下客户端连接的是虚拟网络名称VNN所以还要在集群上处理VIP的问题。域账户权限看着不多但容易遗漏给sqlsvc在故障转移集群中的所有节点上“以服务方式登录”和“以批处理方式登录”的权利。SQL安装向导会报错但如果预先配好能少折腾半小时。5.2 在第一个节点上安装FCI执行安装过程的要点在可能出错的节点上点“安装” → “新建SQL Server故障转移集群”而不是“新建独立实例”。输入SQL Server安装密钥和版本避免用评估版到期后集群服务会自动停止。选择“SQL Server故障转移集群”角色安装路径指向共享VHDX数据目录、日志目录选择D:\SQLDATA挂在共享VHDX上系统数据库目录同样放到共享驱动器上。注意程序文件instance root最好放到共享驱动器上但实测也可以放在本机只要数据文件共享即可。“实例网络名称虚拟网络名称VNN”填SQLFCI客户端通过这个名字连接。集群资源组界面里会自动创建一个 SQL Server 资源和一个网络名称资源。安装完成后先不要急着加第二个节点先在故障转移集群管理器里确认 FCI 资源是否在线并尝试故障转移一次右键“SQL Server (实例名)”→ 移动到本机或另一节点确保基本可用。5.3 添加第二个节点在第二台虚拟机上再次运行SQL安装程序选“添加到故障转移集群”输入实例名并选择现有实例。安装程序会自动把二进制文件同步到第二台节点并把节点加入集群。整个过程中两个虚拟机必须能互相访问共享VHDX否则会报“无法附加数据库”。添加完成之后检查两个节点的状态SELECT * FROM sys.dm_os_cluster_nodes; SELECT * FROM sys.dm_hadr_cluster_members;如果看到status 0正常状态且返回两行记录说明FCI的两节点注册正常。5.4 连接字符串和登录名的成对配置FCI推荐客户端使用“虚拟网络名称VNN 端口”的方式连接比如SQLFCI,1433。如果某个虚拟机的网络名称和IP没被客户端解析到连接就会超时。另外要记得在实例上创建登录名和固定数据库角色因为故障转移不会迁移SQL登录名除非使用固定链接。这块内容很多教程不讲但生产环境无它就容易出事故。我见过把登录名只建在节点A上、节点B加完节点后登录名为空用户在故障转移后完全连不上的真实案例。6. “熔断保护”的实测故意让节点死看系统什么反应6.1 优雅故障转移测试先做最简单的测试在故障转移集群管理器中手动将SQL FCI资源从一个节点移动到另一个节点。观察SQL日志和集群事件转移时间通常在5秒以内因为SQL Server进程被停止后在新节点启动。客户端如果用了连接池会收到socket reset但重试后可以连接。这里要注意SQL Server 2022的FCI故障转移不需要在SQL层面做任何变更配置一切在服务级别完成。资源组中的磁盘转移到新节点SQL Server实例随即启动所有数据库文件由新节点接管。这种“单线程”的接管模式正是“熔断保护”的本质——同一时刻只有一台机器对数据文件进行操作。6.2 拔网线式故障注入手动转移太平顺直接shutdown当前SQL节点的虚拟机或干脆在宿主机上强制关机才更接近真实灾难。此时集群仲裁和FCI资源逻辑会启动集群检测到对端心跳丢失。拥有仲裁的一方检查自身的资源保持在线。资源组移动到另一个健康节点SQL Server在新节点的共享VHDX上拉起。实测第一次强制关机后SQL FCI的PFS故障转移时间大概在35秒到1分钟之间主要时间花在集群资源管理器等待旧节点状态变成“失去仲裁”之后的默认5-10秒超时再加上SQL Server实例启动和数据库恢复时间。那一次测试出了个插曲虚拟机A异常关闭后虚拟机B上的SQL实例报“数据库正在使用中无法独占”等了约20秒才恢复。这其实是共享VHDX的正常锁交接机制但如果你遇到这个错不要慌等它自动重试一般都能恢复。6.3 网络隔离Split-Brain模拟最复杂的测试是模拟节点间网络隔离但节点本身存活。这时两个节点都认为自己活着如果没有见证者就会出现“脑裂”——两边都想当作唯一活动节点这危险不仅会损坏数据还可能导致FCI同时在一侧和另一侧启动。处理这个问题的标准动作是配置仲裁见证。我的文件共享见证位于第三台机器上当节点间通信断开时每个节点都去抢文件共享见证只有能锁定见证的节点才能保持资源在线另一侧会自动静默。用Get-ClusterQuorum可以查看当前仲裁模式模拟时要观察“失去仲裁”事件。需要强调一个经验对于两个节点的Hyper-V集群文件共享见证必须放在不在任何集群节点上的远处。放在存储服务器上虽然便宜但一旦存储服务器故障仲裁也丢了整栈服务都会停。提前设计见证的宿主是必要的。最后补一个平时看不到的细节底层的存储服务器的网卡一旦故障SMB路径断了安装在虚拟机里的SQL FCI不会立刻切换因为Hyper-V集群可能认为存储共享处于降级状态SQL实例还会尝试等待I/O超时。这个I/O超时时间取决于SMB的默认超时和中断处理可以在SQL节点上修改HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\TimeOutValue来缩短等待时间。我把这个值从默认的60秒调到15秒实测存储故障时的切换明显加快。7. 回到落地这台独立存储服务器值不值得这么折腾实验做完总结一下实际收益和成本一套真正的SAN方案光入门级双控就要大几万甚至几十万而我这个方案只用了一台普通的4盘位服务器加两块10G网卡总成本不到SAN的十分之一对于非核心业务库、测试环境、以及可以容忍几十秒切换的内部系统性价比非常高。但如果要用在生产核心库上我建议在三个点做强化一是存储服务器的电源和风扇双冗余毕竟所有数据文件都靠它二是共享VHDX文件做好定期验证快照防止VHDX文件损坏三是给SQL FCI配置备份任务而不是只依赖故障转移因为存储数据本身的逻辑坏块不会因为FCI就自动消失。这个方案在动手过程中踩过的坑最值得记住的三条SMB共享忘了开CA集群存储永远加不进去共享VHDX挂到了IDE控制器上导致“共享”选项灰掉再就是登录名和连接字符串没提前配好故障转移后业务傻等超时。你们如果也打算这么搭尽量把这三条放在检查清单里能省出大半个周末的排错时间。