我们有一个 Microsoft 故障转移群集，其中的动态磁盘由 Veritas Storage Foundation 管理。今天，系统管理员为 SQL Server 添加了新磁盘，但卷上的群集大小错误，因此我发出了快速格式化来更改它。
磁盘卷发生故障，SQL Server 组也发生故障，集群变得无响应。几分钟后，我设法将故障转移到被动节点。
SAN 管理员说这是我的错，因为我不应该从 Windows 格式化小程序来格式化磁盘，而应该使用 Veritas Enterprise Administrator。
格式化操作能用这种方式使整个集群组脱机吗？
相关错误信息：
从事件日志中：
The cluster resource host subsystem (RHS) stopped unexpectedly.
An attempt will be made to restart it. This is usually due to a
problem in a resource DLL. Please determine which resource DLL is
causing the issue and report the problem to the resource vendor.
来自 cluster.log
ERR [RCM] rcm::RcmResControl::DoResourceControl:
ERROR_RESOURCE_CALL_TIMED_OUT(5910)' because of 'Control(STORAGE_GET_DISK_INFO_EX)
to resource 'NameOfTheDiskGroup' timed out.'
Veritas 文档：
摘录自Symantec 的文档：
注意：在手动创建资源之前，您必须使用 VEA GUI 将群集共享卷格式化为 NTFS，然后将其安装到您尝试创建资源的节点上。
这是否意味着磁盘无法从 Windows 格式化？我不这么认为。
顺便说一下，我以前使用 Windows 小程序格式化过许多磁盘，并没有发生任何不好的事情。
答案1
鉴于它是一个共享卷，集群节点似乎已经在尝试使用它，因此使用 VEA GUI 将是最好的方法。他们的文档中没有提到，但他们很可能做了一些与 Windows GUI 不同的事情（即使它只是运行 VEA 的机器对 CSV 的临时写锁，以便它确实可以格式化卷，告诉节点使用不同的磁盘等）。
此外，我怀疑更大的问题是：
笔记： 您必须确保新群集共享卷的选定驱动器号可用，且未在任何群集节点上使用。
听起来你的磁盘在格式化时正在使用中。使用 Windows 将磁盘格式化为 NTFS 可能很简单，但磁盘正在使用这一事实和您没有使用 VEA GUI（可以说它可以避免一些问题），但这就是导致这种情况的原因。
答案2
是的。如果磁盘已配置为 SQL Server 的依赖项（并且要使用磁盘，磁盘必须是 SQL Server 资源的依赖项），按照 WSFC 的工作方式，您可能已经造成了所谓的“故障”，导致磁盘资源脱机，并会升级为整个角色脱机。这可能不是问题，但这是集群的角度。我从来没有事后格式化磁盘并看到它会产生什么影响。
也可能是因为 Symantec/Veritas 不是 NTFS，所以你配置它的方式搞砸了，磁盘资源在格式化时脱机。同样，如果配置为 SQL Server 的资源依赖项，情况会恶化。