es能够支持updatebyid吗 es insert update性能比较

本文提要

• VMware vSphere 共有 4 种快照模式：VMFSsparse 基础快照、SEsparse、vSANSparse 和 vVols/native snapshots。
• 除了 vVols/native snapshots，VMware vSphere 其他三种快照的性能取决于多种因素，包括 I/O 类型、数据位置、快照深度、redo-log 大小以及 VMDK 的类型等。
• 其中 VMFSsparse->SEsparse->vSANSparse 这几种快照的演变实际上是快照性能优化的过程：相比 VMFSsparse，SEsparse 通过 4KB 对齐场景优化降低了写放大和磁盘置零开销，vSANSparse 在此基础上又优化了内存缓存元数据，提高了快照 I/O 性能。但 vSANSparse 依旧无法完全避免快照遍历开销，同时快照深度增大、快照合并/删除还是会带来大幅的性能降低。
• 不同于基于 redo-log 文件和快照链结构的 VMware 快照技术，SMTX OS 快照拥有独立的元数据，避免遍历快照；快照元数据除了利用内存加速，同时做了持久化存储；使用更大的数据块进行存储，有效规避了多种影响快照性能的因素，降低时延、提升快照性能可恢复性。
• 同时，SMTX OS 内多组快照之间相互独立，删除快照无需合并操作，更快捷、简单。

相信使用过虚拟机的朋友，对快照功能肯定不陌生。在安装软件、变更系统配置等场景都会使用到快照，它可以帮助我们轻松地将虚拟机恢复到特定时刻的状态。快照功能无疑很方便，但使用 VMware vSphere 执行快照后经常会出现虚拟机性能下降、快照管理复杂等问题，十分影响业务效率。针对这一现象，本文浅析 VMware vSphere 中快照工作原理，并通过对比 VMware vSphere 和 SMTX OS（SmartX 超融合软件）内的快照机制和实测数据，说明快照执行对虚拟机 I/O 性能的影响。

VMware vSphere 中的快照技术浅析

1.VMware 对于快照的定义

快照可保存虚拟机在特定时刻的状态和数据。

• 状态包括虚拟机的电源状态（例如，打开电源、关闭电源、挂起）。
• 数据包括组成虚拟机的所有文件。这包括磁盘、内存和其他设备（例如虚拟网卡）。

虚拟机提供了多个用于创建和管理快照及快照链的操作。通过这些操作，用户可以创建快照、还原到链中的任意快照以及移除快照。

2.快照种类

目前 VMware vSphere 的虚拟机快照共有 4 种模式：

• VMFSsparseVMFSsparse 是 VMware 传统/基础的虚拟机快照模式，其快照运行原理类似 redo-log。在VMFS5 文件系统下，虚拟磁盘默认使用 VMFSsparse 格式（.vmdk 文件小于 2TB）。
• SEsparseSEsparse 运行原理与 VMFSsparse 类似，主要为了改进 VMware Horizon View（虚拟桌面场景）性能而推出的快照类型，并且支持空间回收技术。SEsparse 是 VMFS6 数据存储上所有增量磁盘的默认格式。在 VMFS5 上，SEsparse 用于大小为 2TB 及更大的虚拟磁盘。
• vSANSparsevSANSparse 格式利用新的 VirstoFS 文件系统 (v2) 磁盘格式的底层稀疏性和用于跟踪更新的新内存缓存机制，在保留现有的 redo-log 机制的同时提高了快照性能。vSANSparse 只用于 vSAN 集群，并要求虚拟机不包含 VMFSsparse 快照。
• vVols/native snapshots这种快照实现并不是由 VMware 层面实现的，而是需要依赖外部存储的快照功能，VMware 通过 VAAI 或者 vVols 将快照操作 Offload 到存储端执行。

本文将针对前三种快照模式进行分析。

3.快照原理

（1）VMFSsparse 基础快照

VMFSsparse 是在创建虚拟机快照或从虚拟机创建链接克隆时使用的虚拟磁盘格式。VMFSsparse 在 VMFS（VMware 专属的文件系统）之上实现，其本质上是一个重做日志（redo-log）文件，创建快照初时它是空的，当有数据变化就记录到该文件之上，直至文件增长到跟原来的虚拟磁盘一样的大小（当虚拟磁盘上的所有数据都发生了变化）。VMFSsparse 快照实质上是 VMFS 命名空间中的另一个文件，它随着虚拟机快照创建而产生，它与 VM 的虚拟磁盘文件（VMDK）一一对应，并记录虚拟磁盘执行快照后的数据变化。

a. 快照文件组成

• .vmdk 和 -delta.vmdkVMware 虚拟机上的每个虚拟磁盘都是以 .vmdk 命名的，在执行快照后，虚拟磁盘 .vmdk 文件会对应生成 -delta.vmdk 文件。而 .vmdk 和 -delta.vmdk 文件的集合都会连接到虚拟机。-delta.vmdk 文件可称为子磁盘文件。当虚拟机再次执行快照时，这些子磁盘可以被视为未来的子磁盘的父磁盘。在原始父磁盘中，每个子磁盘都将构建一个还原点：提供从虚拟磁盘的当前状态回退到原始状态的服务。
• .vmsd.vmsd 文件是虚拟机快照信息的数据库（也可以理解为快照的元数据），并且是快照管理器信息的主要来源。该文件包含一些行条目，这些条目定义了快照之间以及每个快照的子磁盘之间的关系。

b. 快照链

如下图，原始虚拟磁盘（parent）在示意图的最下方，它包含未执行快照之前完整的数据块。第一次执行快照后（示意图下方起第二层）生成子磁盘（child1）文件，该快照文件只会记录执行快照后修改过的数据，未被修改过的数据块不会记录在子磁盘文件，而是访问父磁盘对应的数据块，因此它是一个稀疏的磁盘文件。当第二次执行快照时（示意图下方起第三层）生成子磁盘（child2）文件，原理跟首次快照类似，只是 child2 的父磁盘变为 child1，child2 将记录第二次快照后的数据变化，如此类推。

 图片来源：了解 vSphere 中的虚拟机快照 (1015180)

c. 快照 I/O 原理

如前面提到的，VMFSsparse 快照是在 VMFS 文件系统之上实现的，其中快照重做日志（-delta.vmdk 文件）除了记录了已变化的数据，还同时维护自身的元数据，以便实现重做日志上的数据块的寻址。

重做日志的块大小是 512 字节（刚好是一个扇区大小），使得其读写粒度可以小到一个扇区。当从一台带快照的虚拟机发出 I/O 时，VMware 需要通过元数据信息确定数据是在基础虚拟磁盘（vmdk）上，还是在快照重做日志（-delta.vmdk）上，使得 I/O 能从正确的位置进行服务。快照的性能取决于多种因素，包括 I/O 类型、数据位置、快照深度、redo-log 大小以及 VMDK 的类型等。

d. VMFSsparse 快照对 I/O 性能影响

1）I/O 类型

当虚拟机执行快照后，读、写两种 I/O 类型的性能变化是明显不同的：

 图片来源：vsanSparse Snapshots

其中，读 I/O 由快照文件和原始磁盘文件共同提供服务；执行快照后修改过的数据将从 redo-log 上读取，未修改过的数据则从原始 VMDK 上读取，这种机制使得部分顺序读取的 I/O 变成随机读取，这种情况对机械磁盘并不友好。

对于写 I/O，如果是快照后首次写入的数据块，它将直接写入 redo-log，并需要同时更新 redo-log 上的元数据以标记该数据块的物理位置；已存在 redo-log 的数据则会直接覆盖。

2）快照深度

当虚拟机拥有多个快照时，读取数据的时候可能需要遍历每一层快照文件，查询多个快照文件中的元数据，并造成 I/O 性能明显下降。

下图是 VMware vSAN 官方给出的快照深度性能测试示意，可以看到性能随着快照数量增加而递减，执行 32 个快照后性能下降至接近 0，而且性能并不会恢复。

 图片来源：VMware Virtual SAN Snapshots in VMware vSphere 6.0

3）VMDK 格式

基础虚拟磁盘（.vmdk）格式也会影响 I/O 的性能。在基础虚拟磁盘（.vmdk）的格式为 thin（精简磁盘）且空间未完全分配的情况下，在执行快照后，写入基础精简 VMDK 中的未分配块将导致两个操作：1）对基础 thin 虚拟磁盘（.vmdk）分配空间以及数据块进行置零操作（VMware 避免出现残留数据的机制）；2）将真实数据写入快照文件（-delta.vmdk）。这种场景下 I/O 性能将明显下降。

（2）SEsparse 快照

SEsparse 是一种类似 VMFSsparse（redo-log）的虚拟磁盘格式，并提供一些新功能以及特定场景下的性能优化。SEsparse 与 VMFSsparse 的区别之一是 SEsparse 的块大小为 4KB，而 VMFSsparse 的块大小为 512 字节。上面讨论的关于 VMFSsparse 的大多数性能影响因素——I/O 类型、快照深度、数据的物理位置、基本 VMDK 类型等也适用于 SEsparse 格式。除了块大小的变化，SEsparse 虚拟磁盘格式的主要变化在于空间效率。SEsparse 虚拟磁盘在 VMTools 的配合下（开启 umap 功能），客户端的文件系统删除数据后，自动通知 SEsparse 删除数据块的映射并回收空间，使得膨胀后的 VMDK 再次收缩，以达到节省存储空间的目标。

a. 4K 对齐改善写放大问题

前面提到过 VMFSsparse 的块大小为 512 字节，而实际 I/O 经过多层文件系统后，写操作放大问题是比较显著的。下面以从虚拟机操作系统（Guest OS）发出一个 4KB 的 I/O 作为例子，展示其经过 VMDK、VMFS 以及后端存储的过程中写放大的情况。

 图片来源：vsanSparse Snapshots

当虚拟机发出一个 4KB I/O，由于虚拟磁盘（VMFSsparse VMDK）的块大小是 512 字节，那么 4KB I/O 需要被拆成 8 个 512B I/O，写到 VMDK 文件的 8 个不同的数据块当中，因为不对齐的原因，4KB 的数据有可能打散到多个不连续的块当中；而 VMDK 文件又是存放在 VMFS 文件系统之上（VMFS 的块大小是 1MB），这些 VMDK 上的数据块分别映射到 VMFS 上的 8 个不同的数据块当中；而最终 VMFS 的 I/O 会写到存储阵列（或其他外部存储设备），使得 I/O 操作至少放大了 8 倍（仅当外部存储设备块大小为 4KB 时；如果不是 4KB，有可能放大的情况更严重）。

SEsparse 为了改善上述写放大的问题，将块大小调整为 4KB，那么从虚拟机发出的 4KB I/O 将对齐写入单个 VMDK 数据块，由于 VMFS 的块更大（1MB），因此最终也只会写入单个 VMFS 的数据块当中，最后写入外部存储设备时，只需要一次 I/O 操作就能完成（4KB 对齐），避免了写放大的情况。 

 图片来源：vsanSparse Snapshots

b. 4KB 对齐的优化效果

为证明 SEsparse 对于减少写放大的效果，针对三组对象执行快照，并使用 IOMeter 执行不同 I/O 块大小的测试：

 图片来源：SEsparse in VMware vSphere 5.5

注：Thin：原 VMDK 设置为精简置备。VMFSsparse：原 VMDK 设置为厚置备置零。SEsparse：原 VMDK 设置为厚置备置零。

从测试结果上可以看到：精简置备（Thin）随机写入性能在所有测试场景都是最低的，主要原因在于，精简置备场景下，需要首先将块置零，然后再写入实际数据。这是因为 VMFS 以 1MB 的粒度分配块，而该区域的一部分可能会被真实数据填充。置零可防止应用程序从分配的 1MB 物理介质中读取了残留数据。相反，当使用 SEsparse 和 VMFSsparse 格式时，空间分配发生在更小的块大小中，分别为 4KB 和 512 字节，因此当 I/O 大于或等于 4KB 并且是 4KB 对齐的，则无需将块置零（对于非对齐情况，需要执行“读-修改-写”操作），避免了置零的性能开销。

在随机写入测试中，SEsparse 的性能也明显优于 VMFSsparse 格式。这是因为 SEsparse 实现了智能 I/O 合并逻辑，避免写放大以获得更好的性能。（需要注意的一点：SEsparse 仅在 I/O 与 4KB 边界对齐的情况下执行，能获得与 VMFSsparse 相当或更好的性能。这是因为当 I/O 没有 4KB 对齐，写入操作可能会导致“读取-修改-写入”多次 I/O 操作，从而增加开销。但现实中几乎所有文件系统和应用程序都是 4KB 对齐的，因此 SEsparse 在常见场景中表现要比 VMFSsparse 更好。

（3）vSANSparse 快照

vSANSparse 是在 vSAN 6.0 中引入的一种新的快照格式，它利用内存缓存的快照的元数据提升性能；与 VMFSsparse 和 SEsparse 相比，vSANSparse 在多数情况下性能更好。

当读 I/O 请求到达 vSAN 时，vSANSparse 快照逻辑会遍历该虚拟机的快照树的各个级别，并自动组合 I/O 请求相关的 vSAN 对象和偏移量。然后，这个寻址信息会缓存在 vSAN 快照元数据缓存中（内存中）。快照元数据缓存在于内存中，对快照的读性能至关重要。因为一旦快照元数据缓存未命中，就必须通过遍历多级快照来获取地址信息，这将大幅增加 I/O 访问延迟（这与原来的  VMFSsparse 和 SEsparse 快照是类似的）。元数据缓存的大小是有限制的，并且缓存空间是 VMware 系统中所有打开虚拟机的全部 VMDK 之间共享。因此，当缓存已满时，会淘汰一部分已有的缓存信息。

下图是关于快照缓存命中率与快照性能下降比例的对照图：

 图片来源：VMware Virtual SAN Snapshots in VMware vSphere 6.0

从测试结果观察到，当 vSAN 快照数量低于 19 个时，快照缓存的命中率维持在 98% 以上，这个时候快照的性能损失低于 5%，证明快照缓存空间充足的时候，vSANSparse 对于读操作的优化十分明显。但随着快照深度增大，缓存命中率进一步降低，到 32 个快照的时候，性能下降比例增至 56%。另外由于快照元数据位于内存当中，一旦主机重启，缓存会被清空，含有快照的虚拟机性能将明显下降。

当 VMDK 只包含一个快照的时候，VMFSsparse 与 vSANSparse 混合读写的性能对比如下：

 数据来源：VMware vSphere Snapshots: Performance and Best Practices

可以看到 vSANSparse 在快照深度等于 1 的场景下，其性能优化效果是比较明显的。

以下是 vSANSparse 混合读写在不同的快照深度下性能测试结果：

 4KB 顺序混合读写（50% 读，50% 写）测试

 4KB 随机混合读写（50% 读，50% 写）测试

图片来源：VMware vSphere Snapshots: Performance and Best Practices

从测试结果中观察到 vSANSparse 快照对顺序读写 I/O 的工作负载的性能影响比较小。而在随机读写 I/O 测试的场景下，结果与 VMFSsparse 是类似的，性能有较大幅度的下降。可以了解到当快照深度加大，vSANSparse 快照对于随机读写的优化效果并不明显。

4.VMware 快照的演进情况汇总

 vSANSparse 快照存在的性能问题：

• 随着快照数量和深度增加，元数据缓存无法避免快照的性能下降。
• 主机重启后，元数据缓存无法自动加载，快照遍历的情况依然存在，性能下降明显。
• 快照链结构导致删除快照时，可能需要进行多次快照合并操作，带来较大的性能损耗。

SMTX OS 中的快照技术浅析

1.SMTX OS 对于快照的定义

虚拟机快照可保存其特定时刻数据和配置信息。且虚拟机和虚拟机快照是独立的存在，它们并不互相依赖。

虚拟机快照包含以下信息：

• 虚拟机包含所有虚拟卷的快照（共享虚拟卷除外）。
• 虚拟机的配置信息，例如 vCPU 数量、内存大小、磁盘启动顺序、网络配置等。

SMTX OS 中虚拟机快照支持崩溃一致性快照1以及文件系统一致性快照2，但目前并不支持内存快照3。此外，虚拟机快照支持诸如：创建快照、还原任意快照以及单独移除任意时刻快照等快照管理操作。（VMware vSphere 中虚拟机快照无法单独删除位于快照链条中间的快照，必需完成此快照之后的多个快照合并操作，才能实现快照的删除）；SMTX OS 中虚拟机快照还可以支持通过某个时刻的快照实现重建（克隆）虚拟机的操作，这些都属于 SMTX OS 的虚拟机快照的特点之一。

2.快照原理

SMTX OS 的虚拟机快照与 VMware vSphere 的快照的运行原理并不相同。SMTX OS 的快照不是基于 redo-log 文件实现的，因此也不存在快照链条的结构，且多个快照之间没有依赖关系。

（1）快照组成

由于 SMTX OS 的虚拟机快照并没有类似 VMFS 文件系统或者 VMDK 文件这一层，它的组成更加简单，主要有两部分：

• 元数据虚拟磁盘（vDisk）和快照都有类似结构的元数据信息，而且同一个 vDisk 的多个快照分别拥有独立的元数据信息（包含快照相关的所有数据块的物理位置信息），该信息记录在 zbs-meta 分布式元数据服务数据库中。
• 数据块（extent） 快照的真实数据存储在数据块（extent，每个 extent 块大小为 256MB），快照数据一般由多个 extent 组成，快照后发生变化的数据将存放在独立的数据块（extent）中，而没有被修改的 extent 是快照和原 vDisk 共享的。

3.快照 I/O 原理

vDisk 拥有自身的元数据信息并记录了原始的数据块（extent）映射关系，当执行快照后，系统将生成独立的快照的元数据信息并记录快照相关的数据块（extent）映射关系（如下图）。当数据未发生任何变化时，快照与 vDisk 对应的 extent 是完全一致的，也就是快照与 vDisk 共享所有数据块，因此，这个时候快照并不额外占据任何存储空间。

 写 I/O 发生时，如果是快照后首次写入的数据块（该 extent 未被分配），它将被分配新数据块（new extent），并将数据直接写入新分配的 extent 中 ，并更新 vDisk 的元数据信息，将其映射关系指向新分配 extent。

 如果写入的数据块（extent）在原 vDisk 已经被分配，同样地，系统也将新分配数据块（extent C' 与被修改的 extent C 对应），并更新 vDisk 的元数据信息，将其映射关系指向新分配 extent C'。由于原 vDisk 的 extent 上已经有数据，写入操作可能会导致“读取-修改-写入”多次 I/O 操作。

 其中 extent 块大小是 256MB，而 block 是 extent 下面更小的数据块单位，block 的大小为 256KB，每个 extent 包含了 1024 个 block。

 当写入 I/O 小于 256KB，例如需要写入 4KB 数据，那么需先从原 extent C 上读取对应 block 的数据，修改数据后，将数据最终写入新创建 extent C' 上对应的 block。当对齐写入 256K I/O 时，则无需读取原 vDisk 上 block，直接写入新位置。

读 I/O 发生时，底层存储快照数据块和 vDisk 数据块共同提供服务；由于 vDisk 的元数据映射关系已经被更新，它包含当前状态所有数据块的最新映射关系，因此读取访问是无需遍历快照的，读取寻址的时延是比较低的。

SMTX OS 快照的元数据是存储在 ZBS 分布式存储元数据服务集群内，元数据位于内存中，有更好的响应速度，同时元数据也会持久化同步到 SSD 介质上，这样即使是主机重启后，也可以通过 SSD 快速加载元数据到内存当中，不会因为主机重启而降低快照性能。

SMTX OS 与 vSANSparse 的虚拟机快照对比

 实测对比快照性能

在同一硬件配置场景下，分别测试 SMTX OS 和 vSAN 在快照前后的性能表现。

 在 4K 随机写测试中，可以看到 vSAN 创建快照后，虚拟机性能下降接近 60%，并无法恢复。

 在同样的 4K 随机写测试中，可以看到 SMTX OS 创建快照后，虚拟机在短时间内有明显的性能下降，但可逐步恢复到快照前的性能水平（恢复时间约为 20 分钟）。

总结

通过对 VMware vSphere 和 SMTX OS 实现快照的原理的解读以及实测快照性能的对比验证，可以看出，SMTX OS 的快照技术规避了 I/O 类型、VMDK 格式等会对 I/O 性能产生影响的因素，显著改善了快照运行后 I/O 性能下降的时间和可恢复性；同时，SMTX OS 不存在快照链条的结构，能够保证多个快照间的独立性，从而方便运维人员对快照进行删除等操作和管理。

另外，当 SMTX OS 与 VMware vSphere 集成部署时，可支持文章前面提到过的 vVols/native snapshots 快照模式，使得 vSphere 虚拟机可以通过专用的 VAAI 插件将快照操作 Offload 到 SMTX OS 中完成，获得 SMTX OS 的快照特性。

崩溃一致性快照1：崩溃一致性快照仅记录已写入虚拟硬盘的数据。快照中不会捕获内存或待处理 I/O 操作中的任何数据。因此，此类型的快照无法保证文件系统或应用程序的一致性，您可能无法还原具有崩溃一致性快照的虚拟机。

文件系统一致性快照2: 除了虚拟硬盘上的数据之外，文件系统一致性快照还会记录内存和待处理 I/O 操作中的所有数据。在拍摄文件系统一致性快照之前，访客操作系统上的文件系统会进入静默状态，内存中的所有文件系统缓存数据和待处理 I/O 操作都会刷新到硬盘。

内存快照3: 内存快照是指虚拟机执行快照时，除了对硬盘数据执行快照之外，虚拟机会进入静默状态，内存也会同时执行快照，并持久化保存内存数据；当执行虚拟机快照恢复时，可加载内存快照数据。

参考文章：

1. 了解 vSphere 中的虚拟机快照 (1015180) https://kb.vmware.com/s/article/1015180?lang=zh_CN

2. vsanSparse Snapshots 

https://core.vmware.com/resource/vsansparse-snapshots#section1

3. VMware Virtual SAN Snapshots in VMware vSphere 6.0 https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vsan-snapshots-vsphere6-perf-white-paper.pdf 

4. SEsparse in VMware vSphere 5.5 https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/sesparse-vsphere55-perf-white-paper.pdf 

5. VMware vSphere Snapshots: Performance and Best Practices https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere-vm-snapshots-perf.pdf