前阵子在客户机房里熬到凌晨两点就为了把一套 Windows Server 故障转移群集从验证报告一片红调到全部绿灯。真正卡住我的不是群集本身而是最底下的 iSCSI 共享磁盘——两个节点同时看到同一块 LUN磁盘签名互相打架一会儿联机一会儿掉线群集服务跟着反复重启。后来把链路、认证、MPIO、磁盘签名这条线全部重捋一遍才算彻底顺下来。这篇就把整套Windows Server 部署 iSCSI 共享磁盘搭建故障转移群集的完整过程拆开讲从存储侧的角色安装到节点侧的 Initiator 连接、磁盘初始化再到群集验证、仲裁配置、角色创建和故障转移实测每一步都会说清楚为什么这么做、不做会出什么幺蛾子。不管你是刚接触 Windows Server 高可用的新手还是已经搭过几套群集、但每次走到磁盘那一步就心里没底的老手都能照着走一遍。1. 先把需求想清楚为什么故障转移群集非要共享磁盘很多人第一次搭群集卡壳的地方不是命令敲错而是脑子里对共享这两个字的理解偏了。有人以为共享磁盘就是把一台机器的磁盘通过共享文件夹开放出去另一台机器映射个网络驱动器——这条路走不通后面所有排查都会跑偏。所以先把概念掰开揉碎后面动命令行才不会发虚。1.1 群集共享的到底是什么故障转移群集的核心目标是让一组节点对外表现得像一台机器。当节点 A 因为硬件故障、系统更新或者人为重启而倒下时节点 B 能在几十秒内接管 A 身上承载的资源包括 IP 地址、网络名、共享文件夹、SQL Server 实例、文件服务器角色等等。客户端那边基本无感最多是断一下重连。这里有个绕不过去的前提B 接管时必须能读到 A 原本正在写的那批数据。如果数据只躺在 A 的本地磁盘上B 就算接管了 IP 和计算机名也没有数据可用接管就是空的。所以群集要求数据放在一个两个节点都能同时看到、但同一时刻只由一个节点写入的地方。这正是共享磁盘的定义。它强调两点第一物理上或逻辑上必须是同一份数据不是 A 复制一份给 B第二同一时刻只能有一个节点拥有写入权否则两边各写各的文件系统和数据库直接就废了。群集服务会通过 SCSI-3 持久保留Persistent Reservation这类机制来仲裁写入权谁拿到保留谁就是主人这是 Windows Server 群集比普通文件共享硬核的地方也是很多人用普通共享文件夹替代共享磁盘后一测就崩的根本原因。理解了这一点你就能明白为什么验证配置Validate a Configuration里会专门有一项检查磁盘是否符合群集要求为什么会出现磁盘未通过验证这种让人抓狂的报错——它检查的就是这块盘有没有能力做写入权仲裁。1.2 三条共享存储路线怎么选搭 Windows 故障转移群集共享存储不止一种走法。实际项目里见得最多的是这三条路各自的适用面差别很大。方案接入方式成本适用场景主要痛点FC SAN光纤 HBA 卡 光交高核心数据库、对延迟极敏感需要专用交换机和 HBA布线复杂门槛高iSCSI普通以太网卡 软件 Initiator中低中小规模业务、虚拟化、文件服务依赖网络质量配置细节多SMB 3.0 文件共享直接 UNC 路径低文件服务器、SQL 2014、Hyper-V对 SMB 版本和网络要求高部分老应用不认iSCSI 之所以在中小项目里出镜率最高理由很朴素它把 SCSI 命令封装进 TCP/IP 报文里走的是你本来就有的以太网不需要额外买 HBA 卡和光纤交换机。Windows Server 从 2008 开始就自带 iSCSI 发起程序从 2012 开始自带 iSCSI 目标服务器角色等于说你手里只要有几台服务器和一台交换机就能自己攒出一套共享存储环境做完实验还能直接上生产。代价也很明确iSCSI 的性能和可靠性完全押在网络上。网卡跑满、交换机丢包、MTU 配错、链路没有冗余任何一环出问题表现都是磁盘掉线、群集资源失败。所以第 2 章的网络规划部分别跳过。1.3 iSCSI 里的角色和数据怎么走iSCSI 的术语第一次看确实绕用快递柜打个比方就好懂了Target目标提供存储的那一端相当于快递柜本身背后接着真正的硬盘。Initiator发起程序要使用存储的那一端相当于取件人。Windows 节点就是 Initiator 角色。LUN / 虚拟磁盘快递柜里的一个格子就是一块可被挂载的磁盘。IQN每个 Initiator 和 Target 各有一个全球唯一的身份串格式类似iqn.1991-05.com.microsoft:server01。Target 靠 IQN 来判断这个请求是谁发的访问控制就建立在这上面。Portal门户Target 的接入地址通常是IP:32603260 是 iSCSI 的标准端口。Session会话Initiator 和 Target 之间建立起来的一条连接多路径就是同一个 LUN 开多条会话。数据流是这样的节点上的应用发起一次写操作文件系统转成 SCSI 命令iSCSI Initiator 把 SCSI 命令封进 TCP 包通过存储网发到 Target 的 3260 端口Target 解包还原成 SCSI 命令写进本地的虚拟磁盘文件或物理卷完成后原路返回。整个过程对上层完全透明在磁盘管理器里看到的就是一块普通磁盘。2. 开工前的规划地址、网络与角色分工跳过规划直接动手最后大概率要推倒重来。我自己第一套环境就是因为 Initiator 和 Target 挤在同一张业务网里跑压力测试的时候共享磁盘延迟飙到几百毫秒群集直接判磁盘超时。下面这几件事最好在装系统之前就定好。2.1 网络分区别把鸡蛋放一个网卡里一套正经的群集环境网络至少要分成三块网络用途承载流量建议说明管理网远程桌面、域认证、管理流量1Gbps 起日常运维走这张别混存储业务网客户端访问、群集 IP1Gbps 或更高群集角色对外提供服务存储网iSCSI 流量万兆优先千兆可用独立网段独立网卡心跳网节点互相探测可与管理网复用有条件单独走一张网卡心跳网的作用是节点之间互相打招呼确认对方还活着。如果心跳流量和 iSCSI 存储流量挤在一张网卡上一旦存储大量读写把带宽吃满心跳包发不出去群集就会误判节点宕机触发不必要的故障转移——这种假故障在生产里很致命。我的习惯是每台节点至少三张网卡一张管理兼心跳一张业务一张存储。如果有条件存储网卡上两张做组队NIC Teaming或者接两台交换机做冗余这样单张网卡或单台交换机挂掉不会导致存储中断。IP 规划上存储网一定要用独立的网段比如10.10.10.0/24并且不要配默认网关避免存储流量跑到业务网关上去。2.2 角色怎么分Target 放哪台机器实验环境里通常三台机器一台做 iSCSI Target两台做群集节点。生产环境我更推荐 Target 独立部署不要拿群集节点兼职理由有三群集节点可能随时重启或故障转移Target 跟着重启另一台节点直接丢盘节点上的 CPU 和内存要留给业务跑 Target 服务会抢资源故障排查时存储侧和计算侧分开定位问题快得多。如果你手上只有两台物理机那就用一台虚拟机做 Target宿主资源分够就行。我在测试环境里用 4 核 8G、一块 SSD 做 Target跑文件服务器群集完全够用。2.3 系统版本、补丁和域环境版本这块Windows Server 2016、2019、2022 都支持 iSCSI Target 角色和故障转移群集功能差异不大。需要注意的是所有节点必须加入同一个域工作组的机器做不了群集所有节点的系统版本和补丁级别尽量一致跨大版本混搭比如 2016 和 2022 混虽然理论支持但排查问题时变量太多时间必须同步域内节点默认跟域控走确认一下w32tm /query /status的输出域名解析要正常正向反向都能解析群集创建时要用到。另外提醒一句网上流传的各种产品密钥来路不明正版授权走正规渠道这既是合规问题也关系到后续能不能正常打补丁。3. Target 端用 Windows Server 自己搭 iSCSI 目标服务器Target 这一侧的工作量不大但每一步都直接影响后面节点能不能连上、能不能通过验证。我按顺序来。3.1 安装 iSCSI 目标服务器角色图形界面走服务器管理器 → 添加角色和功能 → 文件和存储服务 → 文件和 iSCSI 服务 → iSCSI 目标服务器。命令行更省事Install-WindowsFeature -Name FS-iSCSITarget-Server -IncludeManagementTools装完之后服务器管理器里会多出iSCSI节点iscsitarget服务也会自动启动。可以用下面这条命令确认服务在跑Get-Service -Name WinTarget Get-WindowsFeature -Name FS-iSCSITarget-Server注意如果这台机器同时装了文件服务器角色不冲突但别在同一块物理盘上既做 Target 存储又做共享文件夹IO 会互相拖累。3.2 建虚拟磁盘、建目标、做 IQN 映射iSCSI Target 端的对象关系是虚拟磁盘Virtual Disk→ 目标Target→ 发起程序Initiator。一个 Target 可以挂多个虚拟磁盘一个虚拟磁盘也可以分配给多个 Target做多路径时用得上。先建两个虚拟磁盘一块做数据盘一块做仲裁盘后面讲仲裁时会用到# 创建存放虚拟磁盘的目录 New-Item -Path D:\iSCSI\VHD -ItemType Directory -Force # 数据盘200GB 固定大小 New-IscsiVirtualDisk -Path D:\iSCSI\VHD\ClusterData.vhdx -Size 200GB # 仲裁盘1GB 就够 New-IscsiVirtualDisk -Path D:\iSCSI\VHD\ClusterQuorum.vhdx -Size 1GB这里我用 VHDX 而不是直接映射物理卷原因是 VHDX 便于备份、便于扩容、也便于迁移。生产环境如果对性能要求极高可以直接用New-IscsiVirtualDisk的物理磁盘模式但管理灵活性会下降。接着建 Target 并把虚拟磁盘挂上去New-IscsiServerTarget -TargetName ClusterTarget -InitiatorIds (IQN:iqn.1991-05.com.microsoft:node01.corp.local,IQN:iqn.1991-05.com.microsoft:node02.corp.local) Add-IscsiVirtualDiskTargetMapping -TargetName ClusterTarget -Path D:\iSCSI\VHD\ClusterData.vhdx Add-IscsiVirtualDiskTargetMapping -TargetName ClusterTarget -Path D:\iSCSI\VHD\ClusterQuorum.vhdx节点的 IQN 怎么拿在两个节点上分别执行Get-InitiatorPort就能看到或者打开 iSCSI 发起程序界面在配置标签页里直接显示。把它复制到 Target 的-InitiatorIds里即可。为什么要逐个 IQN 指定而不是用一个通配符因为 iSCSI 的访问控制是基于 IQN 白名单的。你指定了哪些 IQN就只有这些机器能看到这块 LUN。如果图省事不限制或者放开任意 IQN同网段里任何一台机器只要扫到这个 Portal就能挂载你的群集磁盘直接把数据搞坏。这是安全底线不是可选项。3.3 CHAP 认证要不要开CHAP 是 iSCSI 的一种身份认证方式分单向和双向。它的作用是防止非授权的 Initiator 连接 Target。我的实际体会是在物理隔离的独立存储网段里CHAP 可以不开因为 IQN 白名单已经拦住了绝大多数误连而且 CHAP 配置出错会导致节点连不上盘排查起来很烦。但如果你的 iSCSI 流量跑在和其他业务共享的网段上或者有合规要求那就必须开而且建议开双向 CHAP。开启方式是在 Target 上设置然后在节点的 Initiator 里填对应的用户名和密码Set-IscsiServerTarget -TargetName ClusterTarget -EnableChap -ChapUserName clusterchap -ChapSecret YourStrongSecret123!注意CHAP 密钥有长度限制12 到 16 个字符最稳妥太长或太短都可能被拒。另外密钥里别用特殊符号有些版本的 Initiator 解析会有问题我吃过这个亏。4. 节点端Initiator 连接与磁盘初始化这一章是整套流程里最容易翻车的地方。两个节点连接同一个 LUN稍不注意就会出现磁盘签名冲突磁盘处于脱机状态无法联机因为正在使用中这类报错。我一步步来。4.1 发现门户并连接目标先确认两个节点都能 ping 通 Target 的存储网 IP。然后打开 iSCSI 发起程序命令行敲iscsicpl最快在发现标签页点发现门户输入 Target 的 IP 和端口 3260。在目标标签页里你应该能看到名为iqn.1991-05.com.microsoft:target-server-clustertarget的目标状态是不活动。选中后点连接勾上将此连接添加到收藏目标列表这样重启后会自动重连。命令行等价操作# 添加门户 New-IscsiTargetPortal -TargetPortalAddress 10.10.10.10 -TargetPortalPortNumber 3260 # 查看可用目标 Get-IscsiTarget # 连接目标启用多路径 Connect-IscsiTarget -NodeAddress iqn.1991-05.com.microsoft:target-server-clustertarget -TargetPortalAddress 10.10.10.10 -IsPersistent $true -IsMultipathEnabled $true # 确认会话 Get-IscsiSession | Format-List TargetNodeAddress,IsConnected,NumberOfConnections提示New-IscsiTargetPortal重复执行会报错如果之前加过先用Remove-IscsiTargetPortal清掉再重加。4.2 MPIO 安装与 DSM 配置单条 iSCSI 链路意味着单点故障网卡坏、交换机端口坏、Target 网卡坏共享磁盘立刻掉线群集跟着失败。多路径MPIO的思路是让节点同时建立多条到同一 LUN 的会话走不同的物理链路一条断了另一条顶上。先在两个节点上安装 MPIO 功能Install-WindowsFeature -Name Multipath-IO -IncludeManagementTools安装完成后必须重启MPIO 的服务才会真正生效。重启之后打开 MPIO 控制面板在发现多路径标签页里勾选添加对 iSCSI 设备的支持然后重启一次节点是的MSDSM 需要二次重启才能接管设备。命令行方式Enable-MSDSMAutomaticClaim -BusType iSCSI Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy LeastQueueDepth Restart-Computer负载均衡策略怎么选策略说明适用场景Round Robin所有路径轮流发 IO链路性能接近时最均衡Least Queue Depth发给队列最短的路径我常用的默认值适应性好Least Blocks发给待处理块数最少的路径大块顺序写场景Weighted Path按权重分配链路带宽不一致时我的习惯是先用LeastQueueDepth跑起来后用性能监视器看各条路径的 IO 分布如果不均衡再调。配置完 MPIO 之后回到 Target 端给同一个 LUN 再挂一个目标或者用同一个 Target 的第二个门户地址让节点能建立第二条会话。执行Get-IscsiSession时如果NumberOfConnections显示为 2说明多路径生效了。4.3 初始化磁盘并规避签名冲突这是整套流程里最关键、也最容易踩坑的一步。当两个节点都连上同一个 LUN两边都会在磁盘管理器里看到这块盘默认状态是脱机、只读旁边标个红色小箭头。绝对不能两个节点同时初始化、同时格式化。正确姿势是只在一个节点上操作另一个节点保持脱机等群集创建完成后由群集统一管理。在一个节点上用 diskpart 处理diskpart list disk select disk 2 attributes disk clear readonly online disk noerr create partition primary format fsntfs quick labelClusterData assign letterD这里有几个细节必须说清楚第一attributes disk clear readonly和online disk noerr的顺序不能颠倒先清只读再联机否则联机按钮是灰的。加noerr参数是为了在磁盘有保留冲突时不弹错误中断脚本。第二不要随便执行clean。clean会把磁盘上的签名和分区表全部抹掉如果这块盘之前被别的群集用过里面有数据一执行就没了。只有在确认是空盘时才用。第三关于磁盘签名冲突。有些场景下两个节点同时联机了同一块 LUNWindows 会给其中一份分配新签名弹窗提示磁盘冲突。解决方法是只保留一个节点联机另一个节点立即脱机然后在保留节点上执行diskpart里的uniqueid disk idxxxx重新指定签名的操作或者直接重新走一遍脱机联机流程。第四分区对齐。Windows Server 2008 之后默认就是 1MB 对齐不用手动管。但如果你用的是老旧存储设备或者从旧环境迁移过来的磁盘可以用wmic partition get StartingOffset,Name看一眼起始偏移不是 1048576 的倍数就说明没对齐会影响性能。4.4 两个节点看到同一块盘的一致性校验数据盘处理完之后把仲裁盘也做同样的处理但它可以更简单不用格式化甚至不用联机群集创建时自己会处理。仲裁盘只需要两个节点都能看到就够了。另一个节点怎么处理在服务器管理器 → 文件和存储服务 → 磁盘里你会看到那块盘处于脱机保留状态。什么都不要做保持原样。此时去磁盘管理器里右键会发现联机是灰的这不是故障是 SCSI-3 保留了说明机制正常工作。验证两个节点确实是同一块盘可以对比磁盘的序列号Get-Disk | Where-Object BusType -eq iSCSI | Select-Object Number,FriendlyName,SerialNumber,OperationalStatus,PartitionStyle两个节点输出的SerialNumber应该完全一致。如果不一样说明连到的不是同一个 LUN回去检查 Target 的映射关系。实操心得做完这一步先别急着建群集在两个节点上分别跑一次Get-PhysicalDisk和Get-Disk把结果截图存下来。后面万一出现磁盘掉线有基线可以对比排查速度快一倍。5. 建群集把共享磁盘挂上去到这一步准备工作基本做完了。剩下的流程在 Windows 里其实相当顺畅报错基本都集中在验证阶段。5.1 安装功能并跑验证两个节点都装故障转移群集功能Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools然后从任一节点运行验证。图形界面在故障转移群集管理器 → 验证配置命令行Test-Cluster -Node node01,node02 -Include Inventory,Network,Storage,System Configuration -ReportName C:\ClusterReport验证报告是一份 HTML一定要打开逐项看。常见的几类结果磁盘 2 未通过验证多半是磁盘没联机、或者两个节点一个联机一个脱机。回到 4.3 检查。网络只有单条路径多路径没配好或者两个节点之间只有一张网卡互通。节点未安装相同更新补丁级别不一致打齐补丁再测。未通过 System Configuration 检查 - 域控未同步时间时间同步问题处理完再测。注意验证配置这个步骤在很多教科书里说是可选的我强烈建议每次建群集前都跑。它能在建群集之前把 90% 的问题暴露出来比建到一半失败再回滚省事得多。5.2 创建群集与仲裁配置验证通过后创建群集New-Cluster -Name Cluster01 -Node node01,node02 -StaticAddress 192.168.1.100 -NoStorage这里的-NoStorage是故意的先把群集建起来再把磁盘加进去。这样做的原因是如果磁盘有问题群集本身不会因为磁盘失败而创建失败排查边界更清晰。群集建好后的第一件事是配仲裁。仲裁的本质是当节点之间联系中断时怎么决定哪一边继续服务。奇数个投票成员是理想状态两个节点的情况比较特殊需要仲裁资源来投票。两个节点的群集推荐配置配置方式说明推荐度节点多数 磁盘见证用一块小的共享磁盘做见证2 节点场景最稳推荐节点多数 文件共享见证用一个共享文件夹做见证适合没有多余 LUN 的情况推荐仅节点多数2 节点群集下等于各 1 票谁都不占优极易脑裂不推荐配置磁盘见证Set-ClusterQuorum -NodeAndDiskMajority Cluster Disk 2配置完成后确认一下Get-ClusterQuorum5.3 添加磁盘、创建角色把数据盘加进群集Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterResource加进来之后磁盘资源默认由群集管理所有者是当前节点。你可以用Move-ClusterGroup手动把它挪到另一个节点试试能正常切换说明链路是通的。接着创建角色。以文件服务器为例Add-ClusterFileServerRole -Name FS01 -Storage Cluster Disk 1 -StaticAddress 192.168.1.101执行完之后群集管理器里会多出一个组里面包含网络名、IP 地址、共享磁盘三个资源全部显示联机所有者在 node01。此时从客户端访问\\FS01应该能正常打开。在共享磁盘上建个共享文件夹再创建一个测试文件然后执行手动故障转移Move-ClusterGroup -Name FS01 -Node node02转移完成后客户端重新访问\\FS01刚才那个测试文件应该还在。这一步验证通过说明整套共享磁盘 群集是真正跑通了。5.4 故障转移实测别只看手动手动转移成功只是第一关。真正有价值的是模拟故障直接在 node01 上按电源键强制关机或者Stop-Computer -Force然后观察客户端表现。正常的话客户端大概会在 30 到 60 秒内恢复访问群集管理器里 FS01 的所有者变成 node02事件日志里能看到清晰的转移记录。如果超过两分钟还没恢复去看群集的资源和网络里有没有失败的资源以及系统日志里的FailoverClustering事件。常见原因是共享磁盘在 node02 上没能在超时前完成联机多半是存储网性能问题或者 MPIO 没生效。6. 排查实录我踩过的坑与速查表这一章是我自己几套环境攒下来的排查经验按现象分类遇到问题直接对照查。6.1 验证配置阶段的报错现象可能原因处理方式磁盘未通过验证磁盘未联机、只在一个节点可见检查两个节点是否都能看到 LUN确认 IQN 白名单提示磁盘不支持持久保留磁盘是网络映射盘或 SMB 共享换成真正的 iSCSI LUN别用映射驱动器网络验证提示延迟过高心跳和存储流量挤在一起拆分网卡给心跳单独链路节点时间不同步未与域控同步重启时间服务检查 w32time 配置防火墙阻断验证节点间端口不通群集功能安装时会自动加规则手动改过防火墙的要放行6.2 磁盘连接与联机类问题磁盘脱机右键联机是灰的这是 SCSI-3 保留在起作用说明另一个节点已经持有保留。如果你确定另一个节点已经脱机可以在持有保留的节点上执行diskpart→select disk X→offline disk然后再切回来联机。如果两个节点互相认为对方持有保留那就重启其中一个节点的 iSCSI 服务或者断开重连会话。iSCSI 会话频繁断开重连优先看网络。检查交换机端口有没有 CRC 错误网卡有没有丢包MTU 是否一致。如果配了巨型帧Jumbo Frame 9000必须从网卡到交换机端口全链路一致有一处是 1500 就会出问题——这是非常典型的坑。磁盘能连上但读写极慢三个方向查。一是多路径是否生效Get-IscsiSession看连接数二是负载均衡策略换成 RoundRobin 试三是存储网卡是否有中断绑核问题可以在设备管理器里把 RSS接收端缩放打开。6.3 群集服务与仲裁类问题群集服务无法启动先看是不是仲裁丢失。两个节点群集如果没有配置见证资源一次短暂的心跳中断就可能导致双方都认为对方挂了。解决办法是配好磁盘见证或文件共享见证。如果已经配了检查仲裁盘是否可访问。创建群集时提示节点无法访问检查 DNS 解析正向反向都要能解析对方。还要确认两个节点在同一个域、防火墙没拦 RPC 端口。资源组一直在两个节点之间来回跳这是典型的资源争夺。看群集的日志多半是某个资源有周期性失败触发了自动转移。常见的是 IP 地址冲突或者共享文件夹权限问题。6.4 性能相关SQL Server 跑在群集上内存占用异常这是很多人问过的问题。SQL Server 默认会尽可能吃满可用内存在故障转移群集里如果每个节点都跑一个实例加上群集服务本身的开销内存会显得很紧张。解决办法是给每个 SQL 实例设置 max server memory留出足够余量给操作系统和群集服务。群集磁盘 IO 延迟波动大在性能监视器里加PhysicalDisk\Avg. Disk sec/Read和Avg. Disk sec/Write正常应该在 5ms 以内超过 20ms 就要警惕超过 50ms 群集可能直接判磁盘失败。同时监控iSCSI相关计数器和网卡的Packets Received Errors。实操心得把这些关键计数器做成一个数据收集器集长期跑着出问题的时候直接调历史数据比临时抓数据快得多。我给每个群集环境都配了这么一套后来几次定位到是存储网交换机某个端口的背板问题靠的就是历史曲线。7. 上线之后的加固与运维群集搭起来只是开始真正决定它能不能扛住生产考验的是后续的运维习惯。7.1 网络和 MPIO 的持续调优上生产之前建议做一次故障注入演练拔掉存储网的一张网卡看共享磁盘是否无缝切换、IO 是否中断拔掉业务网的网卡看群集 IP 是否正常拔掉心跳网卡看是否触发假转移。只有真拔过你才知道这套环境的冗余到底有没有生效。MPIO 这边定期用mpclaim -s -d看一下路径状态确认没有路径长期处于 standby 或者 failed。另外如果 Target 端有多张网卡确认它们接的是不同交换机否则交换机挂掉照样中断。7.2 备份策略和容量管理共享磁盘的数据备份有一个容易忽略的点备份软件必须在群集层面感知资源归属不能简单地从一个节点去备份 LUN否则故障转移之后备份任务会失败。Windows Server Backup 支持群集感知备份第三方软件需要确认是否支持。容量管理方面iSCSI 虚拟磁盘建议用固定大小Fixed而不是动态扩展Dynamically Expanding。动态盘在写入时会有性能抖动而且容量超配会导致 Target 端磁盘写满两个节点同时 IO 失败后果很严重。用固定盘容量规划清楚心里有底。7.3 补丁、巡检和定期演练打补丁是群集运维里最考验流程的环节。原则是一次只动一个节点把资源转移到另一个节点打补丁、重启、验证再动第二个。千万不要两个节点同时重启那等于主动制造停机。日常巡检我一般看这几项# 群集整体状态 Get-Cluster | Select-Object Name,QuorumType,QuorumResource Get-ClusterNode | Select-Object Name,State Get-ClusterGroup | Select-Object Name,State,OwnerNode Get-ClusterResource | Where-Object State -ne Online | Select-Object Name,State,OwnerGroup # 存储状态 Get-Disk | Where-Object BusType -eq iSCSI | Select-Object Number,OperationalStatus,HealthStatus Get-IscsiSession | Select-Object TargetNodeAddress,IsConnected,NumberOfConnections再配上群集事件日志里Microsoft-Windows-FailoverClustering的告警每周扫一遍基本能在问题爆发前发现苗头。7.4 关于跨版本升级的一点提醒如果未来要把 2016 的群集升级到 2022标准做法是滚动升级先加一个高版本节点进群集把资源迁过去淘汰一个低版本节点重复这个过程。整个过程可以在线完成但前提是群集的功能级别要先升到位。这个操作的风险点在于共享磁盘的兼容性——低版本节点和高版本节点同时访问同一块 LUN某些存储驱动可能会有兼容问题升级前一定要在测试环境完整跑一遍。最后分享一个我自己一直在用的小技巧给每个群集环境的配置做一份快照文档内容包含每个节点的 IQN、Target 的映射关系、IP 规划表、仲裁配置、以及验证报告的截图。等到半年后需要加节点或者排查问题时这份文档能省下你至少半天时间。我见过太多环境因为当初只有一个人清楚配置细节人一走整个环境就成了黑盒动都不敢动。