但是,如果提供的服务,假设sql服务器,MSDTC或任何其他服务,实际上是由VM映像和虚拟化操作系统提供的.因此,我认为虚拟层仍然存在一个未被考虑的失败点.虚拟机本身可能会发生物理集群无法解决的问题,对吗？在那种情况下,物理故障转移群集(Hyper-V)或VMWare主机无法进行故障转移,因为问题不在于物理群集中的某个服务器 – 通过物理节点进行故障转移不会有任何好处.
这是否需要在物理故障转移群集之上构建虚拟故障转移群集,或者这不是必需的吗？
或者,我想您可以跳过动态群集,只是在虚拟层(基于子级的故障转移群集)上进行群集,因为它仍然可以在物理故障中幸存.
请参见下图,其中显示基于父(左),基于子(右)和组合(中心).父母是根据您的需要去做的,还是基于孩子的更合适？
群集解决方案通常比应用程序层做得更多.
传统上,集群依赖图将包括以下内容：
>网络/ IP可用性检查
>存储/共享卷可用性.
在VM中运行其中一些检查非常困难.对于例如在Windows 2003群集中,它需要一个Quorum驱动器,它使用SCSI锁定以确保它是资源的所有者.在失败时,它还发送“毒性包”来获取该锁.如果没有RDM到LUN,几乎不可能实现所有这些功能.
所有这些“硬件检测”组件在VM中都会有很大的开销.(VM性能对于用户应用程序来说总是很好,但任何内核基础都会产生不同程度的开销).
所以在Microsoft Windows 2003集群的情况下(我必须虚拟化我使用你的’孩子’方法).
争取的理想之地是,
> VMware HA用于硬件故障检测.
> vSphere应用程序监控
其次是,
> VMware HA
>仅应用程序监视器(没有硬件依赖性)
>确保已配对的VM具有反关联性,因此DRS,HA永远不会重新启动相同主机上的节点！
最后
>儿童群集
