不同的超融合软件,其读写机制有一定的差异性,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.png

图 1

 

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

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

 

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

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

2.png

图 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.png

图 3

 

(1)写 I/O 路径

 

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

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

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

4.png

图 4

 

(2)读 I/O 路径

 

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

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

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

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

5.png

图 5

6.png

图 6

 

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

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

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

7.png

图 7

 

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

8.png

图 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 支持数据本地化功能,可精准控制副本的位置:虚拟机运行所在主机放置一份虚拟磁盘的完整副本,另外一份副本则放置在远程主机。

9.png

 

(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%);

10.png

 

情况 2:迁移后,虚拟机移动到对应的副本位置,50% 远程写入(触发概率 33.3%);

11.png

 

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

 

(2)读 I/O 路径

 

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

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

12.png

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

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

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

13.png

 

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

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

14.png

 

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

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

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

三、小结

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

15.png

 

从对比表格上看到,无论在正常还是数据恢复的状态下,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 网络),也许这并不是用户所期望的。

 

2.写在最后

超融合在选型和规划上有许多值得关注的细节,充分了解和重视细节可以帮助用户最大程度发挥超融合架构的优势。后续我们将与读者探讨更多关于超融合基础架构的技术话题。

 

推荐阅读:

VMware 与 SmartX 分布式存储缓存机制浅析与性能对比

VMware 与 SmartX 快照原理浅析与 I/O 性能对比

生产级 VMware 虚拟化方案替换路线与评估

 

1 VMworld 2016: STO7875 – A Day in the Life of a vSAN I/O.

https://www.youtube.com/watch?v=oxi1_Eb7vxA

 

点击了解 完整版 VMware 替代方案

 
继续阅读