VMware 替代专题 | 浅析 VMware 与 SmartX 超融合 I/O 路径差异及其影响

不同的超融合软件，其读写机制有一定的差异性，I/O 路径也不尽相同，这使得他们在 I/O 读写效率以及资源占用上都有不同的表现。有兴趣着手构建超融合基础架构的用户，可能会希望了解更多关于 I/O 路径的细节，从而在实施之前，进行更充足的准备和更合理的规划（例如针对不同 I/O 路径选择更合适的网络带宽）。为了帮助读者更好地理解超融合架构 I/O 路径对集群性能的影响，本文将对比 VMware 和 SmartX 超融合 I/O 路径，分析不同场景下 I/O 读写的方式、发生概率及其对存储性能和集群的相关影响。

重点摘要

基于 SDS 的超融合架构中，I/O 既可能发生在主机内部的本地磁盘上，也有可能发生在外部的网络主机上。相同软硬件配置下，本地 I/O 操作时延更短。
在写入场景下，vSAN 至少有 1 个副本需要经过网络写入。在读取场景下，读 I/O 路径在正常状态下不会出现 100% 本地读取情况；在故障状态下仅有 25% 概率出现 100% 本地读取，其余情况均为 100% 远程读取，且易因故障恢复导致性能瓶颈。
在写入场景下，ZBS* 在正常状态下不会发生 100% 远程写入的情况，并针对虚拟机迁移后的 I/O 路径进行了优化，最大限度避免 100% 远程写入的情况。在读取场景下，正常状态时可确保 100% 本地读；数据恢复时优先进行本地恢复，并通过弹性副本恢复策略平衡恢复速度与业务 I/O。
在正常和数据恢复状态下，ZBS 的本地 I/O 访问概率比 vSAN 更高，理论上时延会更低；而在需要频繁迁移的场景下，vSAN 本地 I/O 访问概率更高。
即使超融合的整体 I/O 性能有富余，更多的远程 I/O 也可能引起网络资源争抢等问题。

*ZBS 是 SmartX 超融合软件 SMTX OS 中与 vSAN 对应的分布式块存储组件。

一、传统虚拟化架构与超融合架构的 I/O 路径对比

业务系统经过运算后生成了数据，并通过系统的 I/O 路径将数据传输到存储介质上（一般是磁盘）进行持久化存储。通常情况下，I/O 的持久化存储过程会经历不同的硬件设备和软件逻辑，而经过每一个硬件/软件都会占用一定的系统资源并增加处理时间（产生时延），因此 I/O 路径的设计优劣跟业务系统的整体运行效率是息息相关的。

1.传统虚拟化架构下的 I/O 路径

在传统三层式基础架构中，I/O 从虚拟机端发起，需要经过 hypervisor（虚拟化软件），然后通过主机的 FC HBA 卡，发送至 SAN 交换机，然后到 SAN 存储控制器，并最终将数据存储到物理磁盘当中。

图 1

I/O 路径中涉及的硬件设备和软件逻辑包括：

硬件设备：服务器主机 / SAN 存储网络交换机 / SAN 存储设备……
软件逻辑：虚拟机操作系统 / 虚拟磁盘 / 虚拟化软件 ……

2.超融合架构下的 I/O 路径

超融合架构将计算、网络和存储进行了融合，I/O 从虚拟机发起，同样需要经过 hypervisor，然后发送到软件定义存储（SDS），最终在本地或通过以太网络将数据存储到物理磁盘当中。

图 2

I/O 路径中涉及的硬件设备和软件逻辑包括：

硬件设备：服务器主机 / 以太网交换机……
软件逻辑：虚拟机操作系统 / 虚拟磁盘 / 虚拟化软件 / 软件定义存储……

使用 SAN 存储的场景中，虚拟机数据必须通过 SAN 网络存储到服务器外部的 SAN 存储设备上，也就是数据读写 100% 需要经过网络。而与此不同的是，超融合架构里面虚拟机的 I/O 是通过内置的 SDS 存储软件写入磁盘的，而 SDS 属于分布式架构，I/O 既可能发生在主机内部的本地磁盘上，也有可能发生在外部的网络主机之上。

其中不难理解的一点：在同样的软、硬件条件下，本地 I/O 操作显然要比远程主机上的 I/O 操作的响应时间更短，毕竟 I/O 需要经过网络传输到远程节点执行，势必会增加 I/O 操作的时延。即使网络交换机的速度越来越快，依然无法完全避免时延的增加。

二、vSAN 与 ZBS I/O 路径分析与对比

1.vSAN 的 I/O 路径

VMware 超融合中的存储软件 vSAN 本质上是对象存储，它将虚拟机磁盘文件（.vmdk 文件）以对象（object）的形式进行存储，并提供了包括 FTT=1（RAID1 Mirror/RAID5），FTT=2（RAID1 Mirror/RAID6）等多种数据冗余机制。下面以较为常用的 FTT=1（RAID1 Mirror）为例展开 I/O 路径的讨论（RAID5/6 只适用于全闪集群，实际上混合存储在超融合环境更为常见）。

在 FTT=1 的存储策略下，虚拟磁盘（.vmdk）的副本数量是 2，两个副本会分别放置在 2 台不同的服务器主机上。而 vSAN 中 object 默认大小是 255GB，条带数为 1。举个例子：当虚拟机创建了一个 200GB 的虚拟磁盘，vSAN 会创建一组镜像组件，它包含 2 个 object 组件（实际上还有 1 个见证组件，但不包含业务数据，暂不讨论），分别放置在 2 台不同的主机上。如果虚拟磁盘的容量大于 255GB，则以 255GB 为单位拆分为多个 object。

图 3

（1）写 I/O 路径

a. 正常状态下的 I/O 路径

前面提到在 SDS 当中，本地读写相比远程读写而言是一个更优的选择，因为它的时延更低，网络开销更少。vSAN 对于副本（object）的放置并没有优先写入本地的策略，而是随机写入两个节点。下面将分析 vSAN 在不同情况下的写 I/O 路径。

以 4 节点的集群为例，2 个副本的放置节点位置共有 6 种可能性，当中有 3 种情况（½ 的概率），虚拟机写入的两个 object 均不在虚拟机运行所在服务器主机，需要 100% 远程写入（两个副本都需要经过网络进行写入），其余 3 种情况都是有一个副本是本地写入（另外一个副本经过网络进行写入），显然后者是更优的路径选择（2 个副本，必然导致至少有 1 个副本需要经过网络写入）。

图 4

（2）读 I/O 路径

a. 正常状态下的 I/O 路径

根据 VMware World1 的技术资料透露，vSAN 的 I/O 读取会遵循 3 个原则：

副本间负载均衡读。
非必然发生的本地读（如果只剩下一个副本）。
确保同一数据块从同一个副本中读取。

vSAN 的平衡读机制，意味着即使虚拟机所在的主机本地有数据副本（图 4 中虚拟机本地拥有副本的概率为 ½），也将会有 50% 的读取是通过网络进行的。另外，有 ½ 概率虚拟机所在的节点没有任何一个本地副本，需要 100% 远程读取。总而言之，vSAN 在正常状态下是不会发生 100% 本地读。

图 5

图 6

b. 故障状态下的 I/O 路径

当集群中发生硬盘故障时，由于副本降级（其中 1 个副本由于硬盘故障而损失），无法再执行平衡读，所有读 I/O 将发生在同一个副本内。

其中，故障场景下将有 ¼ 概率发生 100% 本地读，这是相比正常状态更优的 I/O 路径。

图 7

剩余 ¾ 概率都是 100% 远程读。

图 8

当硬盘遭遇故障时，需通过读取（唯一）可用副本进行数据恢复。由于 vSAN 中 object 的默认大小为 255GB，条带为 1，这种设置使得虚拟机数据副本很容易集中到单一、两块硬盘当中。在数据恢复时触发的读取操作容易受限于单块硬盘的性能瓶颈，难以利用多块硬盘执行并发恢复。因此，VMware 会建议在存储策略中通过增加“条带数”配置，以便尽量利用多块硬盘的读能力。

2.ZBS 的 I/O 路径

SmartX 分布式块存储 ZBS 将虚拟磁盘切分为多个数据块（extent），并为数据块提供 2 副本或 3 副本的数据冗余保护。其中 2 副本在数据冗余保护级别与 vSAN 的 FTT=1（RAID1 Mirror）是相对应的，下面将以 2 副本策略分析 ZBS 的 I/O 路径。

在 2 副本存储策略下，虚拟磁盘由多个数据块（extent 大小为 256MB）组成，而 extent 以一组镜像（Mirror）的方式存在，默认条带数为 4。ZBS 支持数据本地化功能，可精准控制副本的位置：虚拟机运行所在主机放置一份虚拟磁盘的完整副本，另外一份副本则放置在远程主机。

（1）写 I/O 路径

a. 正常状态下的 I/O 路径

同样以 4 节点集群为例，由于 ZBS 可以保证虚拟机所在节点一定会有 1 个数据副本，写 I/O 操作可以一直保证 50% 写入发生在本地，50% 写入发生在远程，无论另外一个副本如何放置，都不会受到影响。因此，ZBS 在正常状态下不会发生 100% 远程写入的情况。

b. 虚拟机迁移后的 I/O 路径

数据本地化功能可确保虚拟机的一份数据副本完整存放在本地主机，从而降低 I/O 访问的时延。但大家可能会思考一个问题：如果虚拟机发生了在线迁移，离开了原有主机，那么数据本地化是否失效了？通常来讲，迁移后的虚拟机可能遭遇到以下 2 种情况：

情况 1：迁移后，两个副本都不在本地，100% 远程写入（触发概率 66.6%）；

情况 2：迁移后，虚拟机移动到对应的副本位置，50% 远程写入（触发概率 33.3%）；

从分析中可以看到，当虚拟机迁移后，发生 100% 远程写入的概率比较高。ZBS 针对这类场景提供了专门的 I/O 路径优化：当虚拟机迁移后，新写入的数据将直接存放在本地新节点，并且会在 6 小时后，将虚拟机原有节点上对应的数据副本移动到新节点，重新形成数据本地化，同时可以解决迁移后远程读的问题。

（2）读 I/O 路径

a. 正常状态下的 I/O 路径

虚拟机运行所在的主机总是拥有一份完整的副本，可以一直确保 100% 本地读。

b. 数据恢复状态下的 I/O 路径

场景 1：虚拟机所在节点发生硬盘故障

I/O 访问从本地快速切换到远程节点维持正常业务的运行，同时触发数据恢复，优先在本地的可用空间进行恢复，并重新形成数据本地化。

场景 2：虚拟机远程节点发生硬盘故障

I/O 读取依然保持本地访问，并同时触发数据恢复。数据恢复的 I/O 流是从本地可用副本读取，然后向远程节点写入恢复数据。

大家可能会意识到：在数据恢复过程中，唯一可用的副本需要同时响应业务的正常 I/O 读写和数据恢复读访问，是否会给存储系统造成较大的压力？

ZBS 针对故障恢复场景也有专门的优化方案：

ZBS 的数据块划分相比 vSAN 更小（vSAN object 大小为 255GB，ZBS extent 大小为 256MB），加上条带化策略，使得虚拟机的数据更容易分散在多个硬盘，利用多个硬盘的读取能力以及多个硬盘的写入能力，有效提升数据恢复速度，避免单个硬盘性能成为瓶颈。
内置弹性副本恢复策略：ZBS 支持自动感知当前业务压力并根据压力调整数据恢复速度。当节点 I/O 繁忙，恢复速度下降至最低水平；节点负载下降，系统会逐步提升恢复速度，以求平稳、快速地恢复数据副本级别。

三、小结

根据上面的 I/O 路径分析，我们汇总和对比 vSAN 与 ZBS 在不同状态的 I/O 路径情况，其中以 100% 本地访问为最优，50% 远程访问为次之，100% 远程访问为再次之。

从对比表格上看到，无论在正常还是数据恢复的状态下，ZBS 的本地 I/O 访问的概率都要比 vSAN 更高，理论上时延会更低；而 vSAN 在绝大部分情况下都会有远程 I/O 发生，换言之，对网络的占用要更高一些。在虚拟机发生在线迁移的场景下，ZBS 的本地 I/O 的概率有所下降，而 vSAN 的 I/O 路径显得要更好一些，随着 ZBS 重新完成数据本地化，这种情况会有所改善（至少需要几个小时）。

基于以上的分析，ZBS 在不频繁发生虚拟机在线迁移（几小时就发生一次迁移）的环境下具有明显的优势，反之，vSAN 会有一定优势。而在实际生产环境下，频繁的在线迁移并不常见。

1.I/O 路径对于集群的其他影响

文章上面提到过，在超融合场景中，本地 I/O 发生概率越大，理论上存储的性能也会更好。但同时也会有另外一种声音：如果超融合的整体 I/O 性能是有富余的，那么是否就不需要考虑本地读写的优势呢？答案依然是否定的，因为更多的远程 I/O，除了增加了时延，还额外占用了网络资源。在集群正常状态下，或许这些网络的开销未必会造成很大的压力，但针对部分特定场景，这部分影响还是无法忽略的，如：

虚拟机高密度部署
当虚拟机发生远程 I/O 的比例比较高的时候，虚拟机部署密度增大，远程 I/O 的流量也会剧增，有可能最终无法满足虚拟机的 SLA 要求。
数据平衡
当集群容量使用率较高时，系统一般会触发数据平衡（执行数据迁移），平衡过程中通常都会涉及主机之间的数据复制，这时候网络带宽的压力会较大。此时，数据平衡和虚拟机的远程 I/O 容易造成网络资源争抢的情况，使得数据平衡完成的时间延长，甚至带来不必要的风险。
数据恢复数据恢复与数据平衡类似，需要依赖网络完成数据复制，但通常情况下，数据恢复需要更多的网络带宽，对业务的影响更大。一旦出现资源争抢的情况，将延长数据恢复时间，引入更大的风险。

最终，为了避免网络资源争抢的问题，用户可能需要付出额外的成本（如切换至 25G 网络），也许这并不是用户所期望的。