前言:
今天小伙伴们对“vmware 故障转移”大致比较关心,各位老铁们都想要知道一些“vmware 故障转移”的相关文章。那么小编同时在网上搜集了一些有关“vmware 故障转移””的相关知识,希望大家能喜欢,兄弟们一起来学习一下吧!在 VMware 虚拟化替代场景中,除了虚拟化平台的选型之外,虚拟机迁移也是很多用户关注的重点:跨虚拟化平台的迁移是如何进行的?整个过程是否平稳?迁移时间受制于哪些条件?跨平台之间的兼容性是否会对业务运行带来影响?......解决这些问题在整个替换工作中至关重要,否则用户无法平滑完成 VMware 替换。
以下,我们将结合使用 SmartX 免费的迁移工具 SMTX 迁移工具进行迁移的情况,深入介绍虚拟机跨平台迁移的原理和整体过程,以及如何保障迁移可靠性、兼容性并降低业务影响。最后,我们也将提供多家行业用户实现 VMware 虚拟机规模化迁移的具体实践经验,供用户参考。
下载阅读《VMware 虚拟化迁移指南「链接」》和《VMware 升级替代专题「链接」》,进一步了解 VMware 虚拟化替代方案与用户实践。
Q&A:跨平台迁移的稳定性、可靠性、兼容性和业务影响
Q1:虚拟机跨平台迁移的原理是什么?
不同厂商提供的跨平台工具迁移原理不尽相同,以 SMTX 迁移工具为例,主要利用虚拟机快照功能进行数据的传输和同步:
对源端虚拟机执行快照并进行全量数据传输:迁移工具会先对虚拟机执行快照,记录虚拟机当前状态,然后在线执行全量的数据拷贝,这一过程中源端虚拟机可以保持在线,因此不会影响 VMware 集群中虚拟机的正常运行。对源端虚拟机执行增量数据同步至目标端虚拟机:全量数据传输过程中,虚拟机是正常运行的,数据状态也同步发生变化。在全量数据传输完成后,用户可以选择手动同步(不停机)增量数据,或者直接关闭源虚拟机以执行增量数据同步。采用手动同步的好处是:可在虚拟机保持在线的情况下,完成绝大部分增量数据的复制,将大幅减少停机同步时间。源端虚拟机关机后,除了完成必要的数据增量同步外,迁移工具也会自动完成对目标端虚拟机的驱动注入、必要的系统配置等。完成相关工作后就可以在新集群中启动已完成迁移的虚拟机。由于迁移过程涉及短暂停机,因此需要合理安排停机窗口。
欲深入了解跨平台迁移原理与流程,请阅读:VMware 虚拟机向国产虚拟化平台迁移?一文了解 SMTX 迁移工具原理与实践 SmartX。
Q2:迁移的整体安排是什么样的?
除了正式的迁移任务,从 VMware 虚拟化平台迁移虚拟机至其他平台的整个项目,还涉及跨平台迁移可行性的评估、迁移规划、环境设置与检查、预迁移等多个环节,如下图所示:
Q3:所有虚拟机都可以进行跨平台迁移吗?
以 SMTX 迁移工具为例,部分虚拟机不适合通过迁移工具执行迁移,如:
带共享虚拟磁盘的虚拟机(如 Oracle RAC 等):SMTX 迁移工具以及 vMotion 都无法支持共享磁盘的迁移。VDI 桌面虚拟机(如 Horizon View、Citrix XenDesktop 等):这类虚拟机也无法通过 SMTX 迁移工具或者 vMotion 迁移。AD 域控制器虚拟机:由于这类型虚拟机严格绑定硬件信息,v2v 迁移后可能会导致 AD 服务运作不正常。不兼容的操作系统:一些过于老旧的操作系统或者比较小众的操作系统可能无法通过 SMTX 迁移工具直接完成迁移,具体可参考 SMTX OS 的 Guest OS 兼容列表。
这类虚拟机需要进行手动迁移,除此之外的大部分虚拟机均可使用 SMTX 迁移工具完成跨平台迁移。
Q4:将虚拟机从 VMware 迁移至其他平台,整个过程对业务有什么影响?
如 Q1 所述,全量数据传输和手动同步增量数据时,源端虚拟机可正常运行,只有在最后的增量同步时需要关闭源端虚拟机,因此需要安排停机窗口:
测试类虚拟机可在工作时间启动迁移任务。正式虚拟机尽可能安排在非繁忙时间启动迁移任务,以避免数据传输对业务带来性能下降的影响。为有效减少业务系统的停机及最终交割时间,可以在全量数据传输完成后,选择手动执行虚拟机增量迁移(增量迁移的时间间隔可以根据业务需求和网络条件进行调整),将源端虚拟机产生的增量数据同步至目标端。最后阶段需要停机执行切换,需计划合理的停机时间。使用 SMTX 迁移工具进行迁移时,大部分情况下停机同步时间不会超过 30 分钟,但如果增量数据较多可能导致停机同步时间延长(停机同步时间根据数据增量和网络传输效率决定,数据增量指从触发迁移的时间点到全量同步完成的时间点之间发生的数据变化量)。
整体而言,迁移过程中的全量传输阶段业务可正常提供服务,但性能可能会略有下降;在增量同步阶段,执行最后一次快照前业务虚拟机需要停机,但停机时间较短,只需要合理安排停机窗口(非业务时间切换),可将业务影响降至最低。
Q5:跨平台迁移会遇到兼容性问题吗?对迁移工具有哪些要求?
由于迁移工具同时关联 VMware 环境和新平台环境,迁移工具对 vCenter/ESXi 版本、虚拟机操作系统、服务器架构、VMware 网络连接等方面的兼容支持,是保证迁移能够顺利进行的关键。目前,一些国内厂商的迁移工具无法支持基于 vSphere Distributed Switch(VDS,分布式交换机架构)的迁移,仅支持标准交换机架构(VSS),而将虚拟机从 VSS 迁移到 VDS 有可能会引起业务网络中断,因此会对用户的迁移场景带来一定的限制。
目前,SMTX 迁移工具对源端和目标端环境的兼容支持能力,可满足绝大部分用户的跨平台迁移需求,具体如下:
1. 对 vCenter 版本/ESXi 版本的兼容能力
SMTX 迁移工具可支持关联 vCenter 或者 ESXi 主机(没有部署 vCenter 的场景)作为源站点执行虚拟机迁移。但在迁移前需要确认当前 VMware 集群的 vCenter 版本或者 ESXi 版本是否在 SMTX 迁移工具的支持范围。以 SMTX 迁移工具 1.5 版本为例,该版本对 vSphere 版本兼容列表如下:
SMTX 迁移工具对 ESXi 版本的兼容要比 vCenter 的版本更丰富一些,当计划为版本比较老的 VMware 集群执行迁移时,可通过关联 ESXi 主机解决 vCenter 无法兼容的问题。
2. 对虚拟机操作系统(Guest OS)兼容能力
SMTX 迁移工具已针对企业常用的操作系统进行适配和验证(包括 CentOS、Windows Server、Redhat、Linux、Ubuntu 等),在迁移前请确认待迁移的虚拟机操作系统是否在兼容支持列表当中。如果操作系统不在兼容列表中,需要与 SmartX 技术人员进行沟通。
3. 对服务器芯片的兼容能力
SMTX 迁移工具支持源端(VMware 集群)为 Intel x86_64 架构芯片,目标端(SmartX 超融合集群)则支持 Intel x86_64 架构芯片和 Hygon x86_64 架构芯片。
另外,SMTX 迁移工具也可支持基于 vSphere Distributed Switch 架构的虚拟机迁移,满足更多迁移场景需求。
Q6:虚拟机跨平台迁移的效率如何?如何提升迁移速率?
迁移速率会受到多种因素影响,包括迁移网络带宽、并发任务数量、迁移工具的部署位置等。
以 SMTX 迁移工具为例,SMTX 迁移工具可通过虚拟机的形式在原有的 VMware 集群或新建的 SMTX OS 超融合集群进行部署,迁移工具同时关联 VMware 集群和 SMTX OS 集群,经过网络将 VMware 虚拟机磁盘数据拷贝到新建 SMTX OS 集群,因此迁移效率会受到集群之间的网络带宽以及磁盘性能等因素影响。以下是 SMTX 迁移工具在 1GbE 迁移网络环境下的迁移效率测试,供用户参考。
测试 1:迁移工具部署位置不变(部署位置均为 VMware 集群),不同存储介质下(源端)的迁移速度对比:
测试 2:源端存储介质不变(存储介质均为 SSD),v2v 迁移工具位于不同部署位置的迁移速度对比:
此外,SMTX 迁移工具可选择接入 2 块虚拟网卡,其中一块网卡(必须)用于连接 VMware 集群管理网络和 SMTX OS 集群管理网络,另外一块网卡(可选)可接入存储网络用于提升数据传输速度,可有效缩短迁移时间。
Q7:如何制定 VMware 虚拟机迁移计划?
制定迁移计划之前,需要了解企业当前 VMware 虚拟机的基本情况。从 VMware vCenter 中可以导出虚拟机的清单信息,具体操作为:登录 vSphere Client - 选择全局清单列表 - 单击虚拟机选项卡以显示所有虚拟机的列表,然后根据实际情况选择筛选的信息。一般需要收集的信息包括:CPU、内存、内存使用率、置备空间、已用空间、网卡数量、端口组等。该环节的目的是了解虚拟化环境的总体资源需求,而新建集群可根据待迁移虚拟机的资源需求总量进行配置,确保有足够资源运行所有待迁移的虚拟机。
在确认迁移时间窗口和兼容性后,可制定详细的迁移日程。目前 SMTX 迁移工具执行迁移任务最大并发数为 5,并可设定任务队列。在实际迁移中,需根据迁移带宽控制迁移并发数量,当带宽利用率过高有可能导致迁移中断或者失败。当迁移网络带宽为 1G,建议并发数是 1-2;当前迁移网络带宽为 10G,可设置并发数为 5(并发数量还需要考虑原有集群性能影响)。
迁移顺序可按照虚拟机对应的业务的重要程度从低到高、磁盘空间从小到大进行排序。此外,建议在正式迁移之前安排一次预迁移(虚拟机不包含真实业务),熟悉和打通整个迁移流程。
Q8:如何保障迁移过程的可靠性?
除了上面提到的确认虚拟机是否适合利用迁移工具进行自动迁移、确认虚拟机信息、迁移工具兼容性、迁移时间窗口等,用户还需要进行环境检查和预迁移以保证迁移的顺利进行。
1. 环境检查
确认网络连通性:主要是 v2v 迁移工具与 vCenter 以及 ESXi 主机的网络连通性,例如,如果它们之间有防火墙,需提前开通相关端口。确认 vCenter 与 ESXi 主机之间是否通过 DNS 域名进行关联:如果是,需要确保迁移工具、新平台集群主机都能正常解释 DNS 域名。确认待迁移的虚拟机是否包含快照:如有快照需先删除快照再执行迁移。清理待迁移的虚拟机上非必要的虚拟外设,如 USB 直通设备、ISO 镜像等。卸载待迁移的虚拟机 VMware VMTools。
2. 预迁移
用户可选择 VMware 集群中常用的虚拟机模板,通过迁移工具迁移到新平台的新建集群。通过预迁移可以验证整个迁移流程是否通畅。在预迁移过程中,用户可记录虚拟机磁盘容量、迁移速度、迁移时间等信息,作为正式迁移的参考。
Q9:正式迁移时具体需要执行哪些操作?
以从 VMware 迁移至 SmartX 超融合集群为例,正式迁移的具体步骤包括:
选择待迁移虚拟机:根据迁移计划选择待迁移的虚拟机(一台或多台并发)。选择迁移目标集群和主机:如果环境中有多个 SMTX OS 集群,根据资源利用情况选择合适的集群作为目标集群。选择虚拟网络:一般选择与原虚拟机相同的子网。如有多张虚拟网卡,则根据需一一对应,以确保迁移完成后虚拟网络的正常通讯。虚拟机数据传输:数据传输阶段需通过网络完整拷贝虚拟机的磁盘数据,整个过程耗时较长。如传输过程中发生网络中断,可使用 SMTX 迁移工具的断点续传功能,无需重新开启迁移任务。虚拟机数据增量同步:当数据传输完成后,用户可以选择手动同步增量数据,再对源虚拟机执行关机操作。关机后,迁移工具会自动完成剩余增量数据同步、执行必要的驱动注入和系统配置操作。虚拟机检查:迁移完成后,需对新迁移到 SMTX OS 集群的虚拟机进行必要的检查,确保操作系统可正常登录、网络可正常通讯、虚拟磁盘全部已正常挂载,并检查关键的应用程序是否能够正常启动。
Q10:迁移过程中出现“意外”应如何应对?
SMTX 迁移工具支持断点传输功能和迁移回退方案,并针对兼容问题提供了更多解决方案。
1. 操作系统不在迁移工具兼容性范围
如果虚拟机的操作系统不在 SMTX 迁移工具兼容支持范围内(但 GuestOS 在 SMTX OS 兼容范围),可尝试先通过 SMTX 迁移工具迁移到 SMTX OS 集群。若迁移结束后出现无法正常进入操作系统的情况,请参考以下检查步骤,初步定位原因,并制定下一步解决方案。
无法找到启动设备:虚拟机启动后提示无法找到启动设备,可能因为虚拟磁盘 Virtio 驱动无法成功注入,导致启动分区无法识别。该情况下,可通过虚拟机控制台进入紧急模式确认是否能识别虚拟磁盘,可尝试安装驱动以及修改启动配置信息进行修复。无法启动图形界面:Linux 虚拟机可正常进入操作系统,但无法启动图形界面,有可能因为虚拟显卡的配置文件不匹配,可通过重置配置文件进行修复。
2. 迁移回退
如虚拟机无法正常完成迁移,或在迁移后业务无法正常工作,可以采取回退手段。回退流程如下:
登录 CloudTower 管理界面,将 SMTX OS 集群中已迁移的虚拟机执行关闭操作。登录原有 VMware vCenter,找到原有业务虚拟机,重新开启该虚拟机检查虚拟机是否可正常登录,以及业务是否能正常服务。
行业用户实践:以 SMTX 迁移工具实现 VMware 虚拟化替代
某保险用户:一期项目迁移 500+ 虚拟机,同时实现 VMware 和 Nutanix 替代
某头部保险机构原采用 Nutanix 超融合(集成 VMware vSphere 虚拟化)承载生产业务系统,而随着 Nutanix “退出”中国以及 IT 基础架构国产化转型的深入开展,用户希望以 SmartX 超融合对 Nutanix 超融合进行国产化替代。SmartX 超融合内置原生虚拟化 ELF(后文简称“SmartX ELF 虚拟化平台”),欲深入了解虚拟化特性,请阅读:SmartX 超融合虚拟化与虚拟机管理特性解读合集。
为确保 Nutanix 超融合上的业务虚拟机可顺利迁移至 SmartX ELF 虚拟化平台,用户先对 SMTX 迁移工具进行了测试。结果显示,基于 Windows Server、Redhat Enterprise Linux、CentOS 等常用的操作系统并结合业务部署的虚拟机,均可完整迁移至 SmartX ELF 虚拟化平台。在测试过程中,迁移工具经过用户实际生产迁移场景的严格考验,在功能性、易用性、兼容性、可靠性及迁移效率方面均获得客户认可:
操作界面一目了然,用户可根据运维经验快速理解界面的各种功能。迁移时源端和目标端的选定也十分简单,用户只需要简单指定好两端,点击“开始”即可启动迁移。迁移过程中无需人工干预,即使迁移失败也不影响源端数据,待条件允许重新发起迁移任务即可。迁移任务发起后,支持手动触发增量数据迁移以缩短迁移过程中虚拟机停机时长。
基于以上测试,用户计划使用 SMTX 迁移工具将 VMware 集群的 700+ 业务虚拟机和 300+ 开发测试虚拟机分批次迁移至 SmartX ELF 虚拟化平台。用户将虚拟机迁移项目拆分为两期,第一期将运行寿险和财险的相关业务系统、运维管理类业务系统、集团管理类系统和办公系统等 200+ 业务虚拟机和 300+ 开发测试虚拟机迁移至 SmartX ELF 虚拟化平台。鉴于当前集群资源无法完全承载 700+ 业务虚拟机,待集群扩容完成后,计划在第二期迁移剩余所有业务虚拟机。
为确保迁移工作的顺利进行,每次迁移任务前,SmartX 工程师都会与用户核对本次迁移任务的虚拟机情况:如确认虚拟机操作系统严格符合兼容性列表,核对虚拟机的名称与 IP 信息、虚拟磁盘置备容量的大小、计算资源使用情况、具体变更时间,以及检查客户操作系统内是否存在自动挂载的网络存储(迁移前取消 NAS 存储自动挂载,迁移完成后重新恢复)。此外,迁移任务安排在业务闲时进行,以确保迁移工作不会对用户的正常业务带来负面影响。SmartX 工程师也严格按照每台虚拟机 20 分钟的停机时间的标准,完成虚拟机增量同步和开机验证,并在用户确认业务可正常运行后,该批次迁移任务才算完成(具体迁移操作与上文 Q8 部分一致,此处不再赘述)。
目前,第一期项目的 200+ 业务虚拟机已顺利完成迁移,开发测试虚拟机也完成 200+ 台迁移,剩余迁移工作正在如期进行中。用户对整体迁移过程的控制、迁移效率、任务成功率以及在有效控制迁移停机时间等方面都比较满意。伴随迁移流程的持续优化,在项目后期,SmartX 工程师不仅在规定停机窗口内完成迁移任务,更多的情况是提前完成,为用户减少停机时间。
上海绿地:迁移 SAP 应用虚拟机,避免应用授权迁移后失效
作为酒店旅游行业头部企业,上海绿地原采用“VMware 虚拟化 + 集中式 SAN 存储”的传统架构承载核心生产业务系统。由于原有设备老化以及集团数字化转型需求,上海绿地希望以 SmartX 超融合(采用原生虚拟化 ELF)对 VMware 虚拟化架构进行整体替换,并采用 SMTX 迁移工具进行虚拟机跨平台迁移。
用户首先对 SMTX 迁移工具的迁移速率以及系统兼容性进行了验证,确认迁移工具的可行性。在进一步探讨迁移细节时,用户提出了关于业务系统授权方面的担忧:在将虚拟机迁移至新平台后,由于业务系统绑定的硬件信息发生变化,软件授权是否会失效,以至于业务系统无法使用?为规避业务系统许可失效风险,SmartX 技术人员提前与用户充分探讨,并在进行一系列相关测试后,验证了可通过移植网卡 MAC 信息结合手工修改业务系统绑定信息的方式,解决许可在迁移后失效的问题。用户对这一方案充分认可,认为可以避免软件厂商反复沟通以及重新授权等繁琐流程,既简单又节约时间。
在相关应用迁移之前,SmartX 工程师与客户运维团队以及业务团队进行了详细的沟通与规划:确认业务虚拟机信息以及资源使用情况、合理安排迁移启动时间、根据虚拟机数据量、预期迁移速度合理与业务团队协商停机窗口,并制定迁移超时的应急预案。迁移详细操作步骤如下:
迁移任务选择在业务闲时启动,避免执行快照时对业务性能产生影响。在迁移向导中选择为源端虚拟机保留网卡 MAC 地址,确保迁移后网卡信息不变。虚拟机完成全量复制后,将源端虚拟机关机,执行增量数据同步。增量数据传输完成后,对虚拟机进行开机验证,确认虚拟机和系统可正常运行。对虚拟机进行关机,修改虚拟硬件信息。重新开机, 待客户确认业务可正常提供服务后后,该虚拟机迁移工作正式完成。
目前,上海绿地已经完成了所有 VMware 虚拟机的迁移工作,将承载 SAP、BI、OA 办公等业务系统的近 30 台虚拟机全部迁移至 SmartX ELF 虚拟化平台。用户对整体迁移过程的便捷性和迁移稳定性表示高度认可。
更多用户迁移实践
此外,锦江国际集团财务公司也利用 SmartX 迁移工具,将生产环境 VMware 超融合平台上 100+ 虚拟机全部迁移至 SmartX ELF 虚拟化平台。整体迁移工作在一周内完成,迁移数据量超 40TB,迁移期间业务虚拟机全部保持在线状态(重启仅需 5 分钟)。中再保险、ConnectWave 等企业用户,也使用 SMTX 迁移工具成功替换 VMware 虚拟化。欲深入了解用户实践,请阅读:VMware 升级替代案例合集:20+ 行业用户实践分享。
想获取更多 VMware 替代和迁移资料?欢迎下载阅读电子书《VMware 虚拟化迁移指南「链接」》和《VMware 升级替代专题「链接」》!(现已收录 2024 年最新资料)
标签: #vmware 故障转移 #vmware 故障转移配置