原文摘自《vSAN权威指南（第2版）》，经译者徐炯授权。
上几期分别是：
另外，文末有注册参加10月26日vForum大会的二维码，无法亲临现场的朋友，也可以参加在线虚拟大会的直播。
欢迎大家转发本篇文章，您的留言获赞数较多的，有机会同时获得《vSAN权威指南（第2版）》和《企业级数据中心现代化技术与实践》的两本或其中一本，机会多多。
---Begin---
5.5 vSAN I/O流
在接下去的几个段落中，我们将跟踪I/O流，看看一台部署到vSAN数据存储上的虚拟机，其客户操作系统中的应用程序进行读写操作时的I/O流是怎样的。我们将观察当条带宽带设置成2的时候的读操作，还将观测当允许的故障数（也即FTT值）为1的时候写操作都又是怎样的。这将有助于理解底层的I/O流，并帮助你了解在设定其他功能值时的I/O流。我们还将讨论回写到容量层的过程，因为这是也去重和压缩起作用的过程。在开始之前，让我们先来看看在I/O路径中闪存的角色。
5.5.1 缓存算法
混合配置和全闪存配置的缓存算法是不同的。概括来说，混合配置关心如何优化从缓存层到容量层的回写(destaging)，而全闪存配置关心的是如何确保热数据块（活动数据）保留在缓存层中而冷数据块（不被访问的数据块）保留在容量层中。
5.5.2 缓存层的角色
如前面的章节所述，当在混合配置中用作缓存层时，SSD（在这里此术语等同于闪存设备）对vSAN来说有2个用途：读缓冲和写缓存，这大幅提升了虚拟机的性能。在某些方面，vSAN可以比作是市场上大量的“混合” (Hybrid)存储解决方案，那些混合存储解决方案也使用了把SSD和磁盘组合在一起来增加I/O性能的方法，但是它们基于低成本的SATA或SAS磁盘驱动器，仅具有横向扩展容量的能力。
全闪存配置的vSAN没有读缓冲，缓存层仅用作写缓存。
-
读缓冲的目的
混合配置中读缓冲的目的是维护一个经常被虚拟机访问的磁盘块的列表。当缓冲命中的时候可以减少读I/O的延迟，缓冲命中的意思就是数据块位于缓冲区内，不需要从磁盘取回。虚拟机中应用程序正在读取的真正的数据块可能不在虚拟机运行的同一台主机上，在这种情况下，DOM为特定的读(基于offset)选择一个镜像并把它(读请求)发送给正确的(镜像)组件，然后它被发送给LSOM来判断数据块是否在缓存中。如果发生了缓冲未命中的情况，数据将会直接从磁盘取回，当然，这会引起延迟惩罚，并可能影响到vSAN每秒输入/输出操作的数量（IOPS）。这就是混合配置vSAN中读缓冲的目的，它减少了需要发往磁盘的IOPS数，其目标是读缓冲命中至少达到90%。vSAN还具有读缓冲预读优化功能，它将要读取的数据块附近的1MB数据也同时读进缓冲区内。
vSAN总是试图确保读请求是发往同一个镜像副本的，这样数据块只会在群集中被缓存一次；换句话来解释：它只存在于一个缓存设备的缓冲区内，这个缓存设备位于读请求发往的那个镜像副本所在的那台ESXi主机上。因为缓存空间是相对昂贵的，这个机制可以对vSAN所需的缓存进行优化。正确的设置vSAN缓冲的大小会对稳态下的性能产生非常显著的影响。
-
为什么全闪存配置vSAN中没有读缓冲
在全闪存配置vSAN中，因为容量层也同样是闪存，如果读缓冲没有命中，从容量层取回数据块的代价不会像混合配置要去磁盘中取回那样大。事实上，这是一个非常快的操作（通常小于1毫秒）。因此，对于全闪存配置vSAN来说完全没有必要再加入一个基于闪存的读缓冲，因为容量层就已经能够高效地处理读操作了。缓存层不用作读缓冲，还可以释放出缓存层的空间更多地用于写操作，进一步提高总体性能。
-
写缓存的目的
无论是全闪存还是混合配置vSAN中的写缓存表现为一种回写的缓存。写在进入缓存层中的闪存设备的准备阶段时被确认。事实上，在混合配置中对写操作使用闪存设备可以显著减少写入的延迟，因为写在被确认前不需要直接回写进容量层。
因为写会先进入缓存层闪存设备，我们必须确保这个数据块会有另外一个拷贝存放在vSAN群集的某个地方。vSAN中所有虚拟机都具有一个可用性策略设置来保证虚拟机数据至少另有一个可用的拷贝（除非管理员特别选择FFT=0来覆盖掉默认策略）。这个可用性策略包含写缓存的内容。一旦客户操作系统中的应用程序发起了写操作，这个动作就会同时写入到所有副本中。写会被缓存到VMDK存储对象的组件所在的磁盘组关联的缓存层闪存设备上。
这意味着当一台主机发生故障时，我们还另有一份缓存内的数据，所以不会发生数据丢失。虚拟机只需简单的重新使用这个被复制的缓存副本及其被复制的磁盘数据即可。
注意，全闪存配置vSAN继续利用缓存层作为写缓存，和混合配置一样，所有虚拟机的写都会先进入这个缓存设备。这里主要的算法变化是写缓存是如何被使用的。写缓存现在用来保存“热”数据块（处于变化状态的数据）。只有当数据块变“冷”（不再变更/被写入）的时候，才会被移动到容量层。
5.5.3 剖析混合vSAN中的读操作
对于vSAN数据存储中的对象来说，当使用RAID-1配置且虚拟机存储策略中的允许的故障数的值大于0的时候，是有可能存在多个副本的。此时，读可能跨副本发生。根据磁盘上的逻辑块地址（Logical BlockAddress, LBA）的不同，不同的读请求可能会被发往不同的副本。这保证了vSAN不会消耗不必要的读缓存，而且避免了把同一份数据缓存到多个地方。
举例来说，当虚拟机中的应用程序发起了一个读请求，就会先询问群集服务（CMMDS）来判断谁是数据的属主。属主使用LBA判断应由哪个组件来服务这个请求，并将请求发往那个组件。如果数据块位于读缓冲内，那么读请求就直接由那个读缓冲提供服务。如果读缓冲未能命中，那么说明数据块不在缓冲区内，下一步就会从磁盘读取数据，而对于混合vSAN来说，容量层是由磁盘构成的。
如前所述，对象的属主会把读请求分散到组成这个对象的各个组件上，这样一个给定的数据块就最多只会在1个节点上被缓存起来，这最大限度地有效利用了缓存层。很多情况下，数据存在另一台ESXi主机的存储上，就可能必须通过网络来进行传输。一旦数据被取回，就会反馈给请求者的ESXi主机并服务于应用程序。
图5-9给出的就是vSAN上读操作的相关步骤的示意图。这个特定的例子中，条带宽度设成了2，虚拟机存储对象的条带分布到了不同主机的磁盘上（用vSAN术语来说，每个条带都是一个组件）。注意，stripe-1a和stipe-1b位于同一台主机上，而stripe-2a和stripe-2b位于不同的主机上。在我们的例子中，需要从stripe-2b来读取数据。如果数据属主不拥有虚拟机上的应用程序试图读取的数据块，读请求将通过万兆以太网络来取回数据块。
图5-9 vSAN I/O流：允许的故障数=1 + 条带宽度=2
5.5.4 剖析全闪存vSAN中的读操作
因为全闪存vSAN配置中没有读缓冲，所以和混合配置中的读操作比起来，输入输出流有些细微的不同。在全闪存vSAN中，当读请求发起的时候，会先检查写缓存，看看（被请求的）数据块是否存在其中（也就是检查这是不是一个热数据块）。顺便说一句，混合配置中也有这个步骤。如果要读取的数据块在写缓存中，就会直接从那里取回。如果请求的数据块不在写缓存中，数据块将从容量层取回。记得在全闪存vSAN中，容量层也是由闪存组成的。所以读取延迟开销非常小，这就是为什么我们在全闪存vSAN配置中不实施读缓存而将所有缓存层都用于写缓存的原因。如前所述，通过不实施读缓存，我们可以将缓存层空间更多地用于写操作，从而提升整体的IOPS性能。
5.5.5 剖析混合vSAN中的写操作
现在我们知道了读的工作原理，让我们来看看写操作。当部署一台新的虚拟机的时候，组件是存储在多台主机上的。vSAN并没有数据本地化的意图，因此有可能出现虚拟机在esxi-01上运行（从CPU和内存角度来看）而其虚拟机存储组件实际上是存放在esxi-02和esxi-03上的。如图5-10所示。
图5-10 vSAN I/O流：写确认
当虚拟机中的应用程序发起一个写操作时，对象属主克隆这个写操作。并发的写请求同时通过万兆网络发往esxi-02和esxi-03上的写缓存（SSD闪存设备）。当数据写入缓存时，写就被确认了，此时SSD上的准备操作就完成了。属主等待所有2台主机的ACK信号后完成I/O。稍后这个写入会作为批量处理的一部分最终回写到磁盘上。各主机的回写操作都是相互独立的，也就是说，esxi-02的回写操作的时间可能和esxi-03不同。这无须协调一致因为不同主机的情况不同，例如缓存空间填满的速度、剩余空间的大小以及数据将存放在磁盘的什么地方都可能是不同的。
5.5.6 剖析全闪存vSAN中的写操作
全闪存vSAN中的写操作和混合vSAN中的非常相似。在混合配置中，只有30%的缓存层用于写缓存，其他70%被分配给了读缓冲。因为在全闪存配置中没有读缓冲，所有100%的缓冲层都被分配给了写缓存（在当前版本的vSAN中其上限为600GB）。不过，笔者觉得这个上限值在不久的将来应该会增大。
混合vSAN和全闪存vSAN的缓冲层的角色也有一些细微的差别。如同我们曾经提过的，混合vSAN配置中的写缓存提升了写的性能，因为写操作不需要直接写入由磁盘组成的容量层，从而改进了延迟值。在全闪存vSAN中，写缓存的目的是增加耐久度。全闪存vSAN的设计目标是将高耐久度的闪存设备用作缓存层，让它们来处理大多数的I/O。这使得容量层可以不需要和缓冲层一样处理大量的写操作，从而可以使用较低配置的闪存设备。
即使如此，全闪存配置的写操作仍然和混合配置非常相似，仍然是只有当数据块被写入到所有副本的写缓存中时，写才会被确认。
5.5.7 将写操作回写入磁盘
来自于vSAN中虚拟机的客户操作系统和应用程序的写入的数据随着时间的推移会慢慢在闪存层上累积起来。在混合vSAN配置中（也就是说配置使用闪存设备作为缓冲层而将磁盘作为容量层），vSAN采用电梯算法周期性地将缓存层内写缓存中的数据按照地址顺序“冲刷”进磁盘中。SSD中的写缓存被分割成大量的“贮存区”（Bucket）。数据块在写入的时候以逻辑块地址（LBA）增大的顺序分配给这些贮存区。当回写发生的时候，可能因为资源的限制，最老的贮存区内的数据会被先回写。
vSAN通过启用磁盘写缓存来最大限度地优化性能。不过写缓存中的数据仅仅在数据从SSD中丢弃之前被冲刷进磁盘。如前面所提及的，回写时vSAN会考虑I/O的位置。按照贮存区为单位累积起来的数据给磁盘提供了一个顺序的（物理位置上邻近的）工作负载。换而言之，它靠把逻辑块地址邻近的数据块组合在一起回写入磁盘来提升性能。事实上，邻近原则即使是对于写入全闪存vSAN配置容量层中的闪存设备也能够提升性能。
用于这个操作的探索算法是成熟的，它考虑了很多参数，例如进入I/O的速率、队列、磁盘利用率和最优的批次（Optimalbatching）。这是一个能进行自我调整的算法，它决定了SSD回写到磁盘的频率。
5.5.8 去重与压缩
vSAN 6.2中加入了2种新的数据简化特性：去重(deduplication)和压缩(compression)。当这2个特性在群集层面启用时，vSAN会试图在把数据块回写到容量层之前对每个块进行去重并压缩。这2个特性仅存在于全闪存vSAN中。压缩和去重不能分开启用，要么一起开启要么一起关闭。去重和压缩作用于磁盘组层面上。换句话说，只有部署在同一个磁盘组上的对象才可以利用这些特性来节省空间。如果完全相同的2台虚拟机被部署在了不同的磁盘组上，即使数据块完全相同也不会有去重发生。然而，去重和压缩特性是群集范围的特性，要么开启要么关闭，你无法选择对某一个虚拟机或某一个磁盘组来开启这2个特性。
对于部署在同一个磁盘组上的组件，如果开启了去重和压缩，那么去重将会在4KB数据块的粒度上实现。磁盘组上只会保留那个4KB数据块的一个拷贝而其他所有重复的数据块都会被清除，如图5-11所示。
图5-11 数据块去重
去重的过程在数据块从缓存层回写入容量层的时候发生，并使用哈希表来跟踪已去重的数据块。去重过的数据块和哈希表的元数据散布在组成此磁盘组的容量设备中。
同一磁盘组内不同的组件间的去重并没有什么不同——数据块去重可能发生在虚拟机主页名字空间、虚拟机交换文件、VMDK对象或快照增量对象上。
如果一个磁盘组的容量快被填满，vSAN会检查那些去重过的组件的构成，并将那些会对磁盘组容量产生最大变化的数据块移走。
不过请注意，如果去重和压缩被启用，那么磁盘组中的单个设备故障会使得整个磁盘组显示为不健康状态。
一旦数据块被去重，vSAN会试图将那个4KB的数据块压缩到2KB或更小。如果vSAN可以做到将那个数据块压缩到小于2KB，它将会保留那个压缩过的数据块，否则会保留未压缩过的数据块。
如图5-12所示，整个过程相对简单明了。第一步，虚拟机将数据写入vSAN的缓存层。当数据变“冷”需要被回写的时候，vSAN将这些数据块读入内存（第二步）。它将会计算哈希值，清除掉重复的块，并将剩余的数据块进行压缩，最后写入容量层（第三步）。
图5-12 去重和压缩过程
写给有兴趣的读者：vSAN现在使用SHA1作为去重哈希算法，并使用LZ4算法来压缩。当然这些在将来的版本可能会变。
5.5.9 数据本地化
一个常见的问题是：需要数据本地化么？缓存需要和虚拟机保持在同一台主机上吗？每当vSphere DRS因为计算资源的不平衡而迁移虚拟机的时候，该虚拟机的缓存以及VMDK存储对象需要和虚拟机一起移动吗？对于vSAN 6.2之前版本中标准的vSAN部署来说，答案是否定的，vSAN不存在数据本地化的概念。然而，自vSAN 6.2起，一些变化加入到了架构中：出现了不同的层面的缓存。让我们先列出这些缓存类型，再来解释哪些地方适用于“本地化”而又有哪些是不适用的。
• 基于闪存的写缓存
• 基于闪存的读缓冲（混合模式中）
• 基于内存的读缓冲
对于基于闪存的缓存来说不存在本地化原则。
原因很简单：考虑到读I/O网络传输最多只有一跳（one hop），万兆以太网引起的延迟比起其他延迟（例如闪存延迟甚至是内核延迟）小到可以忽略不计，而把数据迁来迁去带来的好处远远抵不上其耗费的成本。请特别考虑一下这样的事实：默认的vSphere DRS最小间隔是每5分钟就要运行一次，这可能导致虚拟机每5分钟就会迁移一次。考虑到闪存的成本和基于闪存的缓存的大小，将基于闪存的缓存层中的数据移来移去实在是很不经济。所以vSAN不会这么做，而是把注意力集中在对存储资源的负载均衡上，将它们用最高效和最优化的方法分布到群集中去，因为这对vSAN才是更有收益和成本有效的。
话又说回来，vSAN 版本6.2还有一个小小的内存读缓存（in-memory read cache）。小在这里的意思是主机内存容量的0.4%，且上限为每台主机1GB。这个内存读缓存是一个客户端的缓存，意思就是虚拟机的数据块被缓存在虚拟机所在主机的内存中。当虚拟机迁移时，因为客户端缓存不再有效，所以缓存需要被重新“激活” 。注意，尽管如此，大多数情况下热数据已经存在于闪存读取缓存或写缓存层中，因此对性能的影响很低。
如果由于特别的要求必须提供某种形式的数据本地化，我可以告诉你vSAN可以和CBRC（用于VMware View的内存读缓存）集成，因此你可以启用之，而完全不需要更改任何vSAN的配置。注意，CBRC不需要在vSAN数据存储上创建任何特殊的对象或组件，CBRC摘要存储在虚拟机主页名字空间对象中。
【以下是编者Peter Ye的备注】
数据本地化是一个美好的愿景，但是架构设计需要综合考虑付出的代价和取得的收益是否合算？ 有些技术实现的数据本地化，是要以数据复制和移动占用不少CPU、内存和网络的开销做为代价的，而这样的本地化只对第二次以后的读有些微（因为网络延迟在目前并不是瓶颈）的提升，对数据的写没有帮助。
因此，我个人以为，只有当网络延迟与其他延迟如闪存延迟相比，高到一定成程度，例如当NVDIMM这一类闪存（例如3D Xpoint的NVDIMM）商用并大规模普及，而且又有越来越多业务应用有迫切的低延迟需求时，这时考虑数据本地化或许有更高的投入产出比。然而，即使闪存延迟迅猛缩短，是的网络延迟的瓶颈开始凸显，此时仍有其他现成的技术，例如RDMA可以极大地降低网络延迟的瓶颈。详见：《InfiniBand支持VMware vSAN吗？》。vSAN在未来将支持RDMA。
【备注结束】
5.5.10 vSAN延伸群集中的数据本地化
关于数据本地化的处理有个特别值得一提的地方，就是在考虑vSAN延伸群集部署的时候。vSAN延伸群集是在vSAN 6.1引入的，它允许vSAN群集中的主机分布在地理上分散的不同站点。在vSAN延伸群集中，数据的一个镜像位于站点1而另一个镜像位于站点2（目前vSAN延伸群集只支持RAID-1）。之前我们提起过vSAN从镜像读取数据时采用轮询策略，这对于vSAN延伸群集来说是不合适的，因为这样的话50%的读就要从远端的站点传输过来。由于VMware在站点间允许的延迟最高可以达到5ms，这会对虚拟机性能产生负面影响。vSAN现在不再继续采用轮询和块偏移算法，而是可以智能地找出延伸群集中虚拟机所在的站点，并更改读算法，使得100%的读都从本地站点的镜像副本中获取，这意味着在稳定运行状态中不会有跨链路的读发生。这还意味着所有的缓存都位于本地站点，或者说甚至是位于使用了内存缓存的本地主机上。由于读不再需要通过跨站点的链路，从而避免了额外的延迟。注意，这不是基于每台主机的读本地化，而是基于站点的真正的本地化。在同一个站点，虚拟机的计算部分可以位于任何ESXi主机上，而其本地数据对象可以位于其他任何ESXi主机上。
---End
微信公众号-乐生活与爱IT 将连载vSAN架构细节的系列文章，本篇是
vSAN架构细节系列之五。上几期分别是：
赠书规则：
欢迎大家转发本篇文章，您的留言获赞数较多的，有机会同时获得《vSAN权威指南（第2版）》和《企业级数据中心现代化技术与实践》的两本或其中一本。至少5个名额，有两位名额可获取《vSAN权威指南（第2版）》和《企业级数据中心现代化技术与实践》两本书。有三位名额可获取一本《vSAN权威指南（第2版）》。留言获赞数是比较重要的参考指标，但不完全按照数量，也会适当结合留言是否有针对文章本身提出有价值的问题，或者感想、观点来综合评估。
关于vForum 2017：
2017年10月26-27日，VMware中国在北京-中国大饭店举办vForum 2017年度用户大会。欢迎扫描如下二维码报名参加，并亲临现场参与软件定义存储与超融合分会场，届时会有VMware存储及高可用性的全球总经理李严冰，以及vSAN中国团队的干货分享。您如果无法亲临现场，也欢迎您注册，参加线上虚拟大会的同步直播。
另外大会还提供了至少100多本《vSAN权威指南》第二版的书籍。
点击左下角 "阅读原文" ，可直接跳转到京东自营店购买《VMware Virtual SAN权威指南（原书第2版）》
963
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
