微软私有云分享(R2)4-为已运行群集添加新Hyper-V主机

对于正经公司来说,靠谱点的用微软产品的,都是用微软的故障转移群集来承载虚拟机了。业务发展是迅猛的,也许今天突然赚钱了,需要扩容故障转移群集,这个时候对于使用System Center 2012 R2管理虚拟机的你来说,就需要做一个小操作了。

将新的Hyper-V主机(Windows Server 2012 R2)添加到故障转移群集很简单:

  1. 添加Hyper-V主机到SCVMM2012 R2
  2. 将已添加的Hyper-V主机添加到故障转移群集

=======坑爹事情来了==============

但是一般情况下,用SCVMM2012 R2的向导做第2步操作基本都会失败,会卡在"验证群集"阶段

050714_0429_1.png

根据错误提示,去查看错误日志,会告诉你验证报告能说明一切

050714_0429_2.png

按图索骥,去看看错误日志,简直惨不忍睹,多处红的黄的报错。

050714_0429_3.png

存储基本全黄

050714_0429_4.png

网络部分可能会有黄的。在配置网络部分要说明一下,新加入的Hyper-V主机的逻辑网络和VM网络必须和群集中的主机完全一致。比如群集中有一个网卡叫做abc,那新的Hyper-V主机的网卡也必须有abc,如果新加的网卡叫做abcd,那恭喜你,网络这块必然报错。050714_0429_5.png

再看看系统部分,同样有黄的,基本是告诉你新加入的Hyper-V主机可能有哪些补丁没打,和之前主机的补丁不一致。

050714_0429_6.png

基本看到以上,就没心情去处理群集了。错误太多。但是果真如此么?

===认真你就输了============

造成以上的原因其实很简单,这和群集的工作机制有关。

群集使用共享存储,同一时间只能有一个人声明它的所有权,如果你想群集验证通过,那很简单,在现有群集每一个节点上卸载群集所使用的共享磁盘。但这么做用屁股想都知道,它会造成业务中断,而这是老板所不能接受的。

所以在配置群集存储时候,只要你确信,存储的连接和基础配置确认是无误的,那么就无需理会

另外一个容易出错的是网路部分,由于Hyper-V主机承载虚拟机和故障转移时,需要使用相同的VM网络,而在标准交换机的情况下,VM网络是和逻辑网络是一致的,因此只能提前安装Hyper-V服务、安装虚拟网络交换机。

还有容易报错的地方就是系统补丁了,这个没法说,其实补丁打不打都可以,只是会报警,但是不影响继续。建议是将新的Hyper-V主机补丁打全。



最终解决办法是这样的,四个字:





"跳过验证",就是这么简单。

050714_0429_7.png



你可能感兴趣的:(windows,server,R2,2012,九叔,SystemCenter)