VMware 虚拟化编程(13) — VMware 虚拟机的备份方案设计

简介: 目录目录前文列表备份思路备份算法备份细节连接到 vCenter 还是 ESXi如何选择快照类型是否开启 CBT如何获取备份数据如何提高备份数据的传输率备份厚置备磁盘和精简置备磁盘有什么区别Thin 精简置备虚拟磁盘Thick-Lazy 延...

目录

前文列表

VMware 虚拟化编程(1) — VMDK/VDDK/VixDiskLib/VADP 概念简析
VMware 虚拟化编程(2) — 虚拟磁盘文件类型详解
VMware 虚拟化编程(3) —VMware vSphere Web Service API 解析
VMware 虚拟化编程(4) — VDDK 安装
VMware 虚拟化编程(5) — VixDiskLib 虚拟磁盘库详解之一
VMware 虚拟化编程(6) — VixDiskLib 虚拟磁盘库详解之二
VMware 虚拟化编程(7) — VixDiskLib 虚拟磁盘库详解之三
VMware 虚拟化编程(8) — 多线程中的 VixDiskLib
VMware 虚拟化编程(9) — VMware 虚拟机的快照
VMware 虚拟化编程(10) — VMware 数据块修改跟踪技术 CBT
VMware 虚拟化编程(11) — VMware 虚拟机的全量备份与增量备份方案
VMware 虚拟化编程(12) — VixDiskLib Sample 程序使用

备份思路

  • 在目标虚拟机上创建临时快照
  • 从目标虚拟机上获取备份数据,并保存备份数据
  • 删除临时快照

备份算法

  • 连接到备份目标虚拟机所在的 VC/ESXi
  • 使用 vSphere WS API 开启备份目标虚拟机的 CBT (视情况而定)
  • 使用 vSphere WS API 的 CreateSnapshot_Task 创建备份目标虚拟机的临时快照,如果备份要求「应用一致性」那么需要设置参数 quiescent=True
  • 获取备份目标虚拟机的虚拟磁盘数据以及虚拟机配置信息
  • 使用 VDDK 打开并读取备份目标虚拟机的虚拟磁盘和快照文件数据
  • 将虚拟磁盘、快照文件、配置信息等数据一起复制到备份存储
  • 使用 vSphere WS API 删除临时快照

备份细节

连接到 vCenter 还是 ESXi?

VMware 官方建议备份应用程序选择与 vCenter 服务器建立通信,而非 ESXi 主机。最主要的原因在于 vCenter 服务器为使用 vSphere WS API 的开发者提供了目标对象定位的透明性。由 vCenter 服务器负责跟踪目标虚拟机在不同 ESXi 主机之间的迁移,并且会隐式的将 SDK 操作重定向到当前运行目标虚拟机的 ESXi 主机。

并且 VMware 官方建议开发者应该最小化连接或会话的数量,以降低 vSphere 的资源负载。对备份应用程序来说,最好只创建一个会话,并在所有需要和 vSphere 进行交互的模块中共享该会话。这就意味着如果你希望备份应用程序支持多线程,那么你应该引入访问控制块来对连接的访问进行互斥。

如何选择快照类型?

创建临时快照时,需要充分考虑虚拟机备份的级别,根据不同的级别来创建不同类型的临时快照。EXAMPLE:

  • 只关注磁盘数据完整性的备份级别 ==> 创建崩溃一致性快照
  • 需要关注业务系统一致性的备份级别 ==> 创建 Quiseced 快照

如果是后者的话,则需要将 CreateSnapshot_Task 的「quiesce」和「memory」参数均设置为 TRUE,前置会使 FileSystem 处于静置状态,后者则允许在快照中包含开启电源状态下的虚拟机内存状态,以此获得一个「静置快照」。否则,创建出的快照会存在过渡期的系统状态,还原这种状态下的快照数据很可能会破坏业务系统的运行时状态;

NOTE:「quiesce」和「memory」标识有效的保证了备份虚拟机的文件系统一致性和应用一致性。

还有一点需要注意的是,在执行完备份之后,临时快照就无用了,切记将其删除。快照会影响到虚拟机的性能,以及占用存储空间。

是否开启 CBT?

CBT 是实现增量备份的底层支撑,如果你需要进行更加有利于节省存储空间增量备份的话,通常需要在第一个快照创建之前开启 CBT。但实际上 CBT 也存在着一些使用的限制,具体请浏览 《VMware 虚拟化编程(10) — VMware 数据块修改跟踪技术 CBT》

是否开启 CBT 的关键除了其自身使用上的限制之外,还要考虑备份目标虚拟机的重要性。如果备份目标虚拟机内运行的是核心业务系统,而且存储资源又比较充裕,那么我会建议关闭 CBT,选择使用完全备份。
1. CBT 会占用可测量的性能资源;
2. CBT 的稳定性存在着隐患;

如何获取备份数据?

获取虚拟机的备份数据需要集齐以下关键要素:

  • Snapshot MoRef:快照实际上就是虚拟磁盘的备份版本,通过 Snapshot MoRef 我们可以获取虚拟磁盘的名称和路径等信息。例如:从 Snapshot Managed Object 的 ConfigInfo 开始,能够查找到快照中所有虚拟磁盘的 BackingInfo,我们能够从这些 BackingInfo 中找到虚拟机所有虚拟磁盘相应的 changeId。所以尤其在多虚拟磁盘的场景中,如何有效的对不同的虚拟磁盘进行标识,是一个非常重要的前提条件。

  • VixDiskLib 库函数:在对虚拟磁盘进行了有效的标识之后,我们需要使用 VixDiskLib 所提供的「接口函数集」来获取实际的虚拟磁盘数据。之所以将其称之为「接口函数」,是因为 VixDiskLib 向开发者透明了虚拟磁盘操作的细节。例如,调用 VixDiskLib_Open 和 VixDiskLib_Read 函数时,VixDiskLib 允许以扇区为单位(in Sector)来访问虚拟磁盘数据,所以传输的数据总量是扇区大小的整数倍。可以看出,VixDiskLib 库函数的调用就犹如接口函数调用一般的简单直接。

  • Metadata:虚拟磁盘的元数据,是描述了虚拟磁盘配置信息的一系列键值对,包含了磁盘卷标、LUN、分区布局、链接个数、文件属性、RDM、锁等关键信息,在还原一个虚拟磁盘的时候起到了至关重要的作用。元数据信息可以通过 VixDiskLib_ReadMetadataKeys 和 VixDiskLib_ReadMetadata 来获得。

  • VixMntapi:VixMntapi 库可以获取虚拟磁盘中的 GuestOS 相关信息(如:操作系统类型等)。更重要的是 VixMntapi 支持将卷直接挂载到设备节点上,这样就能够执行面向文件的备份与还原了。

如何提高备份数据的传输率?

掌握以下使用要点,就能够有效的提高备份数据的传输率:

  • 在备份应用程序中选择使用增强型连接函数 VixDiskLib_InitEx 和 VixDiskLib_ConnectEx,增量型连接函数支持使用高级数据传输模式 SAN 和 SCSI HotAdd

  • 如果备份场景主需要读取虚拟磁盘数据,而无需修改磁盘数据的话。调用 VixDiskLib_ConnectEx 时候可以通过传入 readOnly=TRUE 来启用高性能只读访问。

  • 如果在 Linux 上使用 SAN 存储的场景中,可以选择「direct」直接读写模式 O_DIRECT,「direct」模式会阻止其他进程访问最新的虚拟磁盘数据,这意味着磁盘数据的读写都不会存在任何的缓存,这样能够避免提交写缓存前由于进程终止所造成的信息丢失。而且备份一个虚拟磁盘通常都是连续的读取不同扇区中的数据,开启 Cache 机制实际上反而降低了性能。如果备份应用按照下列原则进行读写操作,能够达到最佳的效率:

    • 在 SAN 中执行读写操作的数据偏移都应该是 Page Size 的整数倍。
    • 传输的长度应该是 Page Size 的整数倍。
    • 数据传输的缓冲区应该是页边界对齐的。

备份厚置备磁盘和精简置备磁盘有什么区别?

厚置备磁盘在 Datastore 中会直接占用其分配的所有数据空间,而精简置备磁盘只会消耗其实际使用了的数据空间,所以备份精简置备磁盘的速度会更快。

需要注意的是,厚置备磁盘又细分为「即时清零厚置备磁盘」和「延迟清零厚置备磁盘」。对于前者的全量备份而言,是否开启 CBT 的影响并不大,因为始终都会备份其所分配的容量。但对于后者的全量备份而言就有区别了,如果在全量备份一个「延迟清零厚置备磁盘」前没有开启 CBT 的话,VixDiskLib 会读取虚拟磁盘所有的扇区,并将实际没有使用到的空扇区(本来会被延迟清零的扇区)中的脏数据全部重置为 0,然后再进行备份。也就是说如果「延迟清零厚置备磁盘」在进行全量备份之前没有开启 CBT 的话,其备份数据量上是与「即时清零厚置备磁盘」一样的,而且还损耗了置零的时间,使用这样的备份数据恢复出来的虚拟磁盘类型也是「即时清零厚置备磁盘」。所以建议在对「延迟清零厚置备磁盘」进行全量备份前开启 CBT 功能,实际上如果是增量备份的场景,无论是什么类型的虚拟磁盘,都应该建议开启 CBT。

还有一点需要注意的是,精简置备虚拟磁盘的数据空间是动态的,所以其很可能不是一片连续的数据空间,其在数据存储中实际的数据空间是在第一次写入数据时才被创建的(created on first write)。所以与使用 NBD/NBDSSL/HotAdd 的厚置备磁盘相比,精简置备磁盘在首次写入时需要额外的数据块分配性能开销,不过一旦精简置备磁盘的数据空间被创建之后,其性能就与厚置备类型相差无几了。重要的是,在虚拟机对精简置备磁盘进行随机 I/O 或写操作的同时进行备份的话,即便开启的 CBT,所备份出来的数据量也很可能会大于预期的数据量。对于这种情况,进行虚拟磁盘碎片整理可能会有助于减小备份的数据量。

Thin 精简置备虚拟磁盘

在保护之前不存在 Snapshot (changeId == '*'),开启 CBT 并执行增量保护所保护的数据量是「实际已使用」的数据空间。
在保护之前已经存在 Snapshot (changeId != '*'),开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。

Thick-Lazy 延迟置零的厚置备虚拟磁盘

在保护之前不存在 Snapshot (changeId == '*'),开启 CBT 并执行增量保护所保护的数据量是「实际已使用」的数据空间。
在保护之前已经存在 Snapshot (changeId != '*'),开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。

Thick-Eager 立即置零的厚置备虚拟磁盘

在保护之前不存在 Snapshot (changeId == '*'),开启 CBT 并执行增量保护所保护的数据量是「已分配」的数据空间。
在保护之前已经存在 Snapshot (changeId != '*'),开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。

有什么磁盘类型是无法进行备份的?

一般来说,RDM 类型的虚拟磁盘是无法进行备份的,因为物理兼容的 RDM 磁盘设备无法进行快照。备份应用应该忽略这些无法进行快照的独立磁盘,如果创建快照,就会抛出错误。

相关文章
|
28天前
|
Ubuntu 网络安全 虚拟化
VMware虚拟机ping不通原因排查及分析
下面以 VMware 虚拟机为例进行介绍。
413 3
|
2月前
|
存储 网络安全 虚拟化
虚拟化数据恢复—VMware ESX Server数据恢复案例
虚拟化数据恢复环境: 某企业信息管理平台, 几台VMware ESX Server主机共享一台存储设备,大约有几十台虚拟机。 虚拟化故障&原因: Vcenter报告虚拟磁盘丢失。管理员通过ssh远程到ESX中执行fdisk -l命令查看磁盘,发现STORAGE已经没有分区表了。重启所有设备后,ESX SERVER均无法连接到存储设备中的STORAGE。
|
1月前
|
存储 SQL 数据库
虚拟化数据恢复—Vmware虚拟机误还原快照的数据恢复案例
虚拟化数据恢复环境: 一台虚拟机从物理机迁移到ESXI虚拟化平台,迁移完成后做了一个快照。虚拟机上运行了一个SQL Server数据库,记录了数年的数据。 ESXI虚拟化平台上有数十台虚拟机,EXSI虚拟化平台连接了一台EVA存储,所有的虚拟机都存放在EVA存储上。 虚拟化故障: 工组人员误操作将数年前迁移完成后做的快照还原了,也就意味着虚拟机状态还原到数年前,近几年数据都被删除了。 还原快照相当于删除数据,意味着部分存储空间会被释放。为了不让这部分释放的空间被重用,需要将连接到这台存储的所有虚拟机都关掉,需要将不能长时间宕机的虚拟机迁移到别的EXSI虚拟化平台上。
106 50
|
1月前
|
存储 网络安全 虚拟化
虚拟化数据恢复—VMware ESX SERVER数据恢复案例
虚拟化数据恢复环境&故障: 某单位信息管理平台,数台VMware ESX SERVER共享一台某品牌DS4100存储。 vc报告虚拟磁盘丢失,管理员ssh到ESX中执行fdisk -l查看磁盘,发现STORAGE中的分区表不见了。重启所有设备后,ESX SERVER均无法连接到DS4100存储中的STORAGE。
|
1月前
|
存储 持续交付 虚拟化
|
2月前
|
存储 运维 虚拟化
虚拟化数据恢复——Hyper-V虚拟化故障导致虚拟机文件丢失的数据恢复案例
在Windows Server上部署的Hyper-V虚拟化环境中,因存储中虚拟机数据文件丢失导致服务瘫痪。北亚企安数据恢复工程师通过物理检测、操作系统及文件系统检测,确定为人为格式化造成,并通过镜像硬盘、重组RAID、分析并恢复文件索引项等步骤,成功恢复数据,最终在新Hyper-V环境中验证并迁移所有虚拟机,确保用户业务恢复正常运行。
|
2月前
|
安全 虚拟化 数据中心
Xshell 连接 VMware虚拟机操作 截图和使用
Xshell 连接 VMware虚拟机操作 截图和使用
64 4
|
2月前
|
Linux 虚拟化
vmware虚拟机安装2024(超详细)
vmware虚拟机安装2024(超详细)
358 6
|
2月前
|
虚拟化 网络虚拟化 网络架构
虚拟机 VMware Workstation 16 PRO 的网络配置
虚拟机 VMware Workstation 16 PRO 的网络配置
90 2
|
3月前
|
存储 SQL 数据挖掘
虚拟化数据恢复—VMware虚拟机vmdk文件被误删除的数据恢复案例
虚拟化数据恢复环境: 某品牌服务器(部署VMware EXSI虚拟机)+同品牌存储(存放虚拟机文件)。 虚拟化故障: 意外断电导致服务器上某台虚拟机无法正常启动。查看虚拟机配置文件发现这台故障虚拟机除了磁盘文件以外其他配置文件全部丢失,xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。管理员联系VMware工程师寻求帮助。VMware工程师尝试新建一个虚拟机来解决故障,但发现ESXi存储空间不足。于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除,然后重建一个虚拟机并且分配固定大小的虚拟磁盘。