Win2008实战：Hyper-V 2.0中CSV功能体验

　　这几年虚拟化的热度已经毋庸多言，微软作为计算机软件业中世界顶尖的大公司，自然不甘落后。因此在Windows Server 2008开始，微软推出了Hyper-V，作为企业级虚拟化技术的第一个产品。Windows 2008中的Hyper-V还是1.0版本，很多方面的功能尚有不足之处，最为明显的一个就是共享磁盘资源的分配和使用。下面我们详细来看看。

　　笔者在一个项目中帮客户把生产环境的物理服务器向Hyper-V环境迁移，客户的Hyper-V环境使用的是HP的刀片服务器，两台服务器组成一个群集，安装Windows Server 2008 x64 with Hyper-V中文企业版，共享存储是HP的SAN。

　　当时用的Hyper-V还是1.0版本，因此我需要为每个虚拟机在SAN上划分一个LUN出来，以后也是如此，每要增加一个群集上的虚拟机都需要划分一个新的LUN，否则这台虚拟机就不能放在群集的共享存储了。客户起初要迁移的物理服务器是5台，因此请HP的技术人员划分了6个LUN(有一个用来做仲裁盘)，在使用SCVMM2008的P2V迁移了5台服务器后，客户觉得还应该增加一台虚拟机做监控服务器，这样就不得不再次麻烦HP的技术人员了。等HP的工程师来了后，告诉我们要划分新的LUN需要干掉原有的LUN重新划分(之前已经使用了所有空间)，数据自然就都没了。这样看起来要增减群集上的虚拟机会受到很大的物理条件制约，造成了很大的不便。这也是我体会到的1.0版本的最大不足之处。

　　另外就是在空间规划上，比如为存档服务器建立个60G大小的LUN，估计存档服务器的虚拟机用这么大就够了，可是随着系统运行时间推移，存档服务器需要更大的空间，虽然Hyper-V的磁盘编辑工具可以扩展磁盘，但60G大小的LUN是个物理限制，必须先扩大LUN才行，而我们都知道存储的空间改变是有不小风险的。

　　除此之外的另一个问题就是虚拟机常常需要资源调整等原因需要在物理机间转换，而一个虚拟机从一个节点到另一个节点会有几秒到几分钟的断线时间(具体时间根据运行的服务而不同)，这在像数据库这样的重要应用和OCS 2007R2前端服务器这样的连接敏感的应用中都是不允许的。

　　而幸运的是微软早已认识到这些不足，并且很快解决了它，这就是我们现在要说的Hyper-V 2.0了。

　　CSV(Cluster Shared Volume)，即群集共享卷，是Windows 2008 R2新增功能，可以说是专为Hyper-V 2.0而设计的。要使用CSV功能，必须先用Windows 2008 R2建立一个群集，然后在群集上配置群集共享卷。在R2中群集上的磁盘图标也不同了，如下图所示，M:和Q:是共享磁盘，图标和本地磁盘有明显区别。

　　在群集管理器中可以看到一个启用群集共享卷的菜单，启用时说明此功能只为Hyper-V设计，不支持其他应用。启用后在目录树中出现群集共享卷，右键选择添加存储，此时会列出可用存储，需要注意的是只有可用存储被列出，也就是不能被其他服务占用的存储。在添加了存储后，大家会看到被添加到共享卷的存储在两个节点上都不在作为磁盘显示出来了。也就是说两个节点都看不到这个磁盘了，那么它去哪里了呢?

　　大家在群集共享卷项下会看到一个路径，默认位置是系统盘的ClusterStorageVolume1目录，这个其实就是共享磁盘了。以后我们建立的虚拟机都会放在这个路径下，它看起来是在C:盘的，实则是群集的共享盘。如下图：

　　我们建议大家使用SCVMM2008R2来管理Hyper-V群集，很多功能是这个管理软件才提供的，比如P2V的功能。在SCVMM2008R2中添加了群集主机后，在群集属性的存储标签会看到这个群集共享卷。如下图：

　　在建立虚拟机的时候会选择放置路径，路径框中默认位置是C:ClusterStorageVolume1。创建出来的虚拟机由于放置在群集上而拥有了容错能力，其中一个群集节点出了故障的时候虚拟机会自动转移到另外一个节点继续运行。

　　虚拟机创建出来后，会在两个节点的C:ClusterStorageVolume1目录都看到这个虚拟机，并且在群集管理器中也会看到它。并且当创建更多虚拟机的时候也可以放在这个目录，只是会以虚拟机的名字新建文件夹而已。如下图，我建立三个虚拟机，分别以OCSFE1,OCSFE2和SQL2005来命名。这样我们就再也不必因为新建虚拟机而重新划分LUN了，现在只要空间允许，随便你增减虚拟机。

　　下面我们再来看看Windows Server 2008R2中的新增能力：Live Migration。中文译作实时迁移或活动迁移，系统中为实时迁移，我们以系统为准。在群集管理器中的服务和应用程序下点击某台虚拟机，我们会看到将虚拟机实时迁移到另一节点和将虚拟机快速迁移到另一节点的选项，从效果上来讲，两者是有区别的。实时迁移过程中虚拟机对外提供的服务不会中断(有Timeout延迟)，而快速迁移则不行，会有中断时间。

　　在实时迁移过程中我们用另外一台机器持续ping这台虚拟机，会看到timeout时间有所延迟，迁移完成后又恢复正常延迟。在迁移过程中虚拟机的状态一直是正在运行的状态，只是迁移中网络延迟较大。

　　而快速迁移则会出现一段时间内的服务中断，虚拟机的状态也会在正在运行->正在保存->已保存->正在启动->正在运行这几个状态间切换。根据应用不同，这几个状态需要花费的时间会有很大不同，比如一台纯净的虚拟机可能有15秒就可以完成，而一台运行了数据库的虚拟机可能要几分钟才能完成。这对于重要的企业应用来讲是很难接受的。

　　需要提醒大家的是这个功能不是为了群集节点故障时进行资源转移设计的，也就是说一个节点故障，所有群集资源自动转移到其他节点的时候并不会用到实时迁移。毕竟一个节点出故障，另外一个节点检测到故障并且抢占资源都是需要一些时间的。实时迁移是为了正常情况下我们在多个物理节点间切换虚拟机而设计的。

　　大家看到这个功能不错，可能会担心要求也会很高。其实不然，只要群集的节点是Windows Server 2008 R2，有共用存储就可以使用这个功能。有了群集共享卷，我们划分存储的时候只需要把仲裁资源外的所有空间划分成一个LUN，然后加入到群集共享卷中，在空间允许的情况下我们可以随意增加虚拟机，而不必在担心虚拟机空间占用高后重新规划LUN的问题。在进行物理服务器维护的时候我们也可以使用实时迁移的功能，把虚拟机迁移到一个节点上，对另一个节点进行维护、系统重启，甚至是重装系统等操作，而不必担心虚拟机切换会造成服务中断，而接到无数的投诉电话了。

　　总之，这个功能是Hyper-V 2.0中一个很大的亮点，有条件的话我们把它用起来吧。