何以压缩服务器迁移的宕机时间,V动态迁移原理安详严整

把负载迁移到新服务器看起来很简单,但是这个过程中还是容易产生不少小问题。下面我们来列举一下当你准备执行这项任务前需要准备什么。

为了追赶上VMware虚拟化霸主的脚步,微软从Hyper-V
2.0开始支持物理机与虚拟机之间的动态迁移。动态迁移对于实验室来说,需求可能并不高;但对于企业来说,这却是虚拟化成熟度的一个分水岭。

服务器的认证。当负载被迁移的时候,新的服务器取代旧服务器的身份。尽管这个身份的转换主要可能是通过备份再建来完成的,但是最好在之前就记录好服务器本身特性的信息。

银河国际手机版最新,在开始之前,需要明确一个概念。

在服务器的计算机名和网络协议地址方面,这一点深有体会。当备份重建在不相似的新硬件上时,静态IP地址常常突然丢失。类似的是,我遇见过在新服务器能够完全加入功能之前,Active
Directory(活动目录)计算机账号必须得重置。

动态迁移Hyper-V Live Migration)并非故障状态下的非计划宕机。

你可以给新硬件起不同的名字,但是迁移过程会变得非常复杂。新计算机名使得数字证书无效化,导致映射网络驱动器失效。

该应用场景仅用于升级、硬件更换等计划宕机。

服务包级别和补丁。你也需要在迁移之前记录旧服务器的服务包和补丁。如果你试图迁移的新服务器正在运行一个可替代的服务包级别,
那么你可能会遇到很多问题。拿Exchange
Server为例,服务包级别影响你装载邮箱数据库的能力。

动态迁移步骤:

实验室测试。这是最关键的一环了,在实验室环境测试新硬件和迁移过程。我通常创建一个单独的实验室,然后重建在区域控制器、基础架构服务器(DNS、DHCP等等)以及其他任何必须得彻底测试迁移进程的备份

• 在源和目标计算机之间建议连接

通过以上测试,我可以把新的产品硬件加入到实验区域。这有很多理由。第一,可以让新硬件加入实验环境很好的磨合,如果能发现某个部件一直失效,那总比新服务器进了工作环境之后再失效好。

• 传送虚拟机配置及设备信息

第二个理由,那样做有利于发现一些硬件自带的小毛病,比如说,你可能会发现在新服务器的网卡上,TCP/IP卸载失效。

• 传送虚拟机内存

最小化宕机时间。你应该制定一条计划来减少迁移过程的宕机时间。如果你正要取代的某个服务器是一个正在工作中的群集一部分,可能这比较简单,把新服务器加入到群集中,然后溢出就得。但是在非群集环境,减少宕机时间更具有挑战性。

• 暂停挂起)源虚拟机并传送状态

减少宕机时间取决于负载类型。我喜欢在开始迁移之前,把最近的负载重建到新服务器,这是条普遍准则。到了迁移的时候,我先断掉旧
服务器的网络连接,然后最一个最终备份。等到新服务器已经就位好了,有了一个近期备份,我就重建最近的备份,这样会比较快,因为只需要更新最新的内容。

• 恢复目标虚拟机

支持软件。最后,记住关于在你的服务器上可能会运行的支持软件。
这包括杀毒软件和backup
agent。我发现支持软件可能会被过分讲究,这样在迁移之后肯能运行会不太正常。所以这也说明测试很重要。

一、在源和目标计算机之间建议连接

不过,在新服务器迁移负载到底要怎么样?这个答案得基于服务器负载和你自身的基础架构需求来分析。不过,在投入工作环境之前测试迁移进程无论如何都是必要的。整个测试过程中,确保所有必要的服务开始,在服务器上的任何数据库都正常,任何数据都可以访问。

该部分的通信涉及到两个WMI对群集中两个dll的调用:

clusres.dll

群集资源管理dll基本的网络、存储、WINS、DHCP、脚本。。)

vmclusres.dll

虚拟机群集资源管理dll

Live Migration从本质上来说还是群集的一种实现方式。

通信的速度与效率与源服务器和目标服务器的负载有关。

在源服务器或目标服务器负载过高情况下会出现WMI调用clusres.dll超时失败的情况。

该场景出现在PRO调用Live
Migration过程中,将会造成第4步,即暂停挂起)源虚拟机并传送状态卡死,导致虚拟机长时间处于挂起状态。

错误信息如下:

错误 (12711)

由于出现错误 [MSCluster_Resource.Name=”SCVMM XXX01 Configuration”]
,找不到元素,VMM 无法在服务器 HOST01.contoso.com 上完成 WMI 操作。

详细信息 (找不到元素(0x490))

微软提供的相关的补丁,需要在所有节点上部署:

二、传送虚拟机配置及设备信息

这里值得注意的是,该部分传送的并非虚拟机目录中的XML配置文件,仅仅是注册表中的信息。

以上两步完成的是迁移的准备工作,告知了目标服务器虚拟机所需的资源,并分配所需资源。

三、传送虚拟机内存

该部分是迁移的核心技术部分。不论是VMware还是Hyper-V来做迁移,都是无法逃避的问题。

那些销售所谓的服务不会断线,不过是传说。从技术的角度来说只是断线的时间由秒这个级别降低到了毫秒级而已。

我们来详细描述一下内存传送的过程:

1、锁定Guest主机内存,并将该部分的信息传送到目标服务器。

银河国际手机版最新 1

2、Guest主机继续运行,在Host主机中开启一个新的内存分区为Guest主机提供服务。该区域仅保存变更的内容。

银河国际手机版最新 2

3、新内存分区将继续分片锁定,并传送。

银河国际手机版最新 3

4、重复2~3,保证原HOST服务器与目标HOST服务器变更内存的差异在一个极小的时钟周期之内,直至操作1中的内存传送完成。

四、暂停挂起)源虚拟机并传送状态

这部分包含3个操作:

1、挂起源虚拟机

2、传送最后的源虚拟机内存变更片段

3、通知存储,将存储挂载至目标服务器

第四步是迁移时间消耗的关键。

而关键的关键是实时内存状态的保存。

在Hyper-V 1.0中Quick
Migration采取的方式是挂起源虚拟机,再处理内存的方式。

所以在迁移过程中会发现宕机的时间与虚拟机所消耗的内存量成正比。

而在Live Migration中,宕机时间不再由所迁移虚拟机消耗的内存来决定。

决定宕机时间的关键点内存大小是一个相对较小的变更内存片段。

根据实测,在Live
Migration操作中,ping包监视根据系统负载不同在丢包为2~6之间。

完全可以满足一般企业高可用的需求。

五、恢复目标虚拟机

这个部分与普通的恢复相同。不做详细说明。

2.0开始支持物理机与虚拟机之间的动态迁移。动态迁移对于实验室来说,需求可能并不高…

发表评论

电子邮件地址不会被公开。 必填项已用*标注