我们有一个 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 的资源依赖项,情况会恶化。