vSAN架构解析与6.7功能介绍

内容来源：2018 年 7 月 17 日，VMware大中华区原厂高级技术讲师史峻在“VMware直播分享 第二期”进行《vSAN架构解析与6.7功能介绍》演讲分享。IT 大咖说经主办方和演讲者审阅授权转发。

阅读字数：6759 | 17分钟阅读

致歉信

亲爱的用户：

很抱歉，本期直播因客服未点击视频录制，导致现在才上线视频和文章，给各位带来不便深表歉意，感谢史峻老师百忙之中又重新录制视频。

嘉宾演讲视频回放，请复制：http://t.cn/RgrBuLP，粘贴至浏览器地址栏即可观看。

Overview of vSAN

About vSAN

vSAN的基础架构实际上就是将服务器的本地存储聚集起来打造成一个虚拟的共享存储，这也是vSAN的名称由来。所有的主机都位于vSAN集群中通过vSAN专用的网络来进行存储数据的传输。由于vSAN是基于对象的存储技术，因此vSAN Datastore中存储的都是虚拟机的对象。vSAN同时也是一个软件定义存储，在VMware环境中是通过策略来定义对象如何保存，可用性和性能目标都需要通过策略实现，而传统存储的性能和可靠性是在最底层磁盘等物理介质上来实现。

vSAN and object-based storage

前面提到过vSAN Datastore中存储的都是虚拟机的对象，那么什么是对象呢？vSAN Datastore的一个对象其实是文件的元数据和数据的集合。在传统存储中保存的是虚拟机的文件夹，文件夹中存放着虚拟机相关的文件，比如磁盘文件、配置文件、日志文件等。

在对象存储中这些文件都变成了对象，vSAN存储中虚拟机对象被分为了5类，第一类是虚拟机的Home Namespace对象，第二类是VMDK对象（也就是虚拟机的磁盘文件），第三类是Snapshot delta（快照差异对象），第四类是内存对象，第五类是虚拟机的Swap对象。后面这四个对象其实就是虚拟机文件夹中比较大的文件，其他的小文件包括虚拟机文件夹则是第一类对象。

我们知道vSphere环境中集群依赖于共享存储上VMFS文件系统，集群的一部分功能在设计之初都是依赖于这个文件系统的。而VM Home Namespace可以被看作是一个小的VMFS文件系统的实现，这样就可以使对象存储仍可以兼容VMFS内置的一些功能。

对象存储是基于策略来保存对象的，所以在进行数据I/O的时候不是直接将对象本身放在磁盘组的硬盘中，而是以组件（Compnent）的形式，根据存储策略定义的可用性和性能进行存取。

从图中可以看到vmware的vSAN紧密的和虚拟化环境结合在一起的，实际上是将虚拟机的文件通过策略存储在vSAN的存储上。整个vSAN datastore有默认的策略，也可以针对虚拟机指定不同的策略，甚至是将策略指定给单个VMDK。

Enterpeise Storage in a Native vSphere Architecture

Vmware vSAN是集成在虚拟化产品vSphere系统内部，所以不需要像其他产品一样需要准备存储的管理虚机来管理软件定义的存储。如果有这样的虚机，不仅要准备额外的CPU和内存，存储I/O的路径也会被延长，存储的I/O开销也会被放大。

vSAN是和Hypervisor集成在一起，所以虚机进行IO的时候是先到Hypervisor然后直接到SSD。分布式I/O流传输的时候，也是通过一台Hypervisor访问另一台Hypervisor，然后再去访问SSD。这样就能将管理本身的开销降到最低，没有额外的CPU和内存开销，也没有I/O路径的延长或者开销的放大。

vSAN可以匹配大多数业务场景，比如对于虚拟桌面的支持，我们知道虚拟桌面有大量的存储I/O访问，vSAN由于是分布式的存储，所以在存储访问的时候可以访问本地的SSD，也可以访问其他主机上的SSD。具体访问哪里，会根据负载均衡的算法来调度，但很有可能一部分I/O会落到本地，不用所有的I/O都走网络，这样在I/O的延时和速度上有很大的优势。

One Management Plane – A Common Framework

vSAN 6.7对管理界面进行了升级，主要是将web界面逐渐的迁移到HTML 5上，原先的flash界面因为技术原因需要一定的加载时间，HTML 5 消除了这一加载过程，同时支持大多数的浏览器，目前已经实现了70%-80%的功能。

vSAN Architecture

Modern Object Based Storage for vSphere

上图中有一个700G的VMDK的硬盘需要进行存储。VMDK进行I/O的时候实际上是以组件的形式去写入到存储上，默认情况下组件最大是255G。而我们现在有700G文件需要存储，所以它会被均分成3个组件来写入到存储中。

又因为是RAID-1所以每个组件会有两份拷贝保存到存储上，另外还会有一台主机来存放仲裁组件。可以发现如果要做vSAN的话，一般情况下最少需要3台主机。

图中的FTT等于1表示的是组件容忍出现的故障，比如容忍故障为1就需要准备两个副本，如果FTT等于0就是没有副本。

vSAN Object Compliance Status

vSAN的存储中为组件设计了3种状态，第一种状态叫Absent；第二种状态叫Degraded；最后是Stale。

组件如果有多个副本，副本之间在写数据的时候这些数据都是最新的。RAID-1写的时候，数据就会同时写到多个主机上，如上图的这两台主机的数据都是最新的，如果某台主机损坏，就无法访问其中的数据。这里的无法访问具体情况有这几种，Absent状态下是主机在没有发出任何消息的情况下，主机的存储就突然无法访问。Degraded状态下是主机明确发出消息，比如硬盘损坏导致无法访问。既然有问题那么就需要修复，关于修复这三种状态对应的策略也不一样。

这些状态都可以在HTML 5的界面中看到，类似上图能够看到存储策略、组件状态、分布的主机。一旦无法访问active就会变成Absent、Degraded、Stale其中之一。

网络

在6.6之前的版本中部署vSAN的时候网络是多播环境，从6.6之后就开始支持单播。只有一个集群的情况下多播影响不大，多个集群的时候可能会要在不同的网络中修改多播地址，因此单播的开销相对多播要低一些。

现在的网络有IPV6和IPV4，vSAN对于纯IPV6和纯IPV4以及他们的混合网络都支持。另外对于vSAN的冗余我们也提供了更快的故障倒换的机制，假设现在有两个vSAN网络（物理上完全隔开），相当于创建了多个vSAN的vmknics，每个vmknics实际上是位于完全独立的网络中，无论是软件还是物理层面，并且交换机之间也没有连接在一起，当一个网络断开之后可以快速的切换到另一个上。

vSAN's Distributed Object Manager at a Glance

CLOM，集群对象管理器，它以进程的形式，运行在用户空间，根据存储策略确定对象的位置分布。

DOM，分布式对象管理器，位于主机内核空间，它没有对应的进程，分为DOM Client与DOM Owner，DOM Client位于主机上，每主机一个；DOM Owner则针对对象，每对象一个。所有的对象处于DOM层面，由DOM控制I/O，它保证所有的副本处于一致状态。

DOM Client将I/O给到DOM Owner，DOM Owner将之给到对象组件所在主机的DOM Comp.Mgr（DOM组件管理器）上，然后DOM Comp.Mgr和主机本地的LSOM通信，由LSOM访问物理的存储适配器进行数据的I/O。

vSAN Architecture — LSOM

主机本地I/O实际上就是对硬盘数据进行存取。写的时候数据流从上层组件发送到LSOM的时候，LSOM会先将数据写到缓存盘中，然后同步到存储节点上。读的时候是先从内存缓存中读，（若前面未命中）再从硬盘缓存中读，（若前面未命中）最后读容量盘。这里需要注意一下，可以看到图中右边的绿色线条实在写缓冲和读缓存中间，实际上在硬盘缓存区域中会先探查写缓冲然后再探查读缓存最后再去探查容量盘。

当写数据放到SSD的写缓冲之后会向后台进行同步（我们称此动作为de-stage），在6.7版本中我们对这个同步的性能进行了增强。比如原来的窗口大小是64k，现在被增加到了256k，数据同步的窗口增大之后，de-stage吞吐性能有了显著的提升，大概在30%-40%左右（注意这里不是指vSAN的总体性能，指的是从缓存到容量盘的同步吞吐性能的提升，非正式评估数据）。

vSAN Data Placement and Management

Caching and Capacity Tiers

前面提到过数据写的时候是先写缓冲再写同步至容量盘，读的时候也是先读缓存区域再读容量盘。这里如果是全闪存结构，SSD的所有容量都会被用来做写缓冲，因为这种架构下写有收益而读没有。从图中可能有人已经发现了，缓存SSD中还是有着读操作的，其实在数据没有被同步到容量盘之前，仍然是可以在写缓冲中读取到命中数据。

混合部署架构中，缓存区域的分布是，读写是三七开，容量盘是机械盘，缓存盘是SSD，数据写入到写缓冲即返回写成功，可以从读缓存中读取命中的缓存数据。

Disk Groups

vSAN集群中硬盘被放置在磁盘组中。每个主机上最多5个磁盘组，最少1个磁盘组，1个磁盘组中有且只有一个SSD作为缓存盘，最多7个容量盘（可以是机械盘也可以是SSD）。

很多人喜欢问vSAN的容量，举个例子来说，假如集群有8台主机，每台主机5个满配磁盘组，容量盘单盘容量4TB，那么该vSAN集群理论最大容量为，5（DG）* 7（容量盘）* 4TB * 8Host，约等于1.1PB。

对于缓存盘，需要注意的是，vSAN迄今为止，支持的缓存大小最大为600GB，如果缓存盘大小超过600GB，有效使用的缓存空间，仍为600GB，但更大的容量（超过600GB），仍具有其价值，会增加该缓存盘的耐受度和寿命。

The different types of storage traffic in vSAN

vSAN的流量被分为两类。第一类为虚拟机的前端流量，指的是虚拟机和存储之间的访问流量。另一类为存储的后端流量，比如主机之间（因为策略变更产生的）复制流量，组件转移流量，重平衡流量，重构流量等。

在对流量进行分类之后，我们可以直接在管理界面中看到流量的细分类型，从图中很轻易的看到他们的IOPS情况。

I/O Management of Resyncs

在存储I/O密集甚至拥塞的时候，我们需要对某些流量进行保障和控制。一个是存储的Resync流量，另一个是虚拟机对于存储的访问流量。

如上图所示，一开始数据组件都是正常的，没有故障，也就没有产生后端Resync流量，某个时间点有某台主机的磁盘组发生了故障，要对组件进行修复复制，就会产生Resync流量，并且根据数据量的多少，带宽的使用也不定。图中蓝线表示的是前端流量，橙线是后端Resync流量，可以看到在2-4阶段，他们带宽分布情况是相对的，后端流量起来之后，前端会相对下降。需要注意的是如果两者流量都达到了100%，那么前端最多下降到80%，后端最多提升到20%，只有在不存在竞争的情况下后端Resync才有可能会超过20%。

An Example of how Resync Traffic is Generated

这里我们具体来看下Resync的操作过程。图中的硬盘有2个副本以及1个仲裁组件，其中某个副本发生故障需要在另外一台主机上重新生成该副本，这时就会产生Resync流量。

在Absent状态下不会立刻产生Resync流量，而是会等待60分钟。Degraded状态下，会立刻产生Resync流量。

Better Balance of Data as Maximum Capacity Nears

后台存储流量中有一种叫做Rebalance。在上图中有三个组件分别写入到了三个SSD，这三个组件未必来自同一对象，有可能是不同对象的不同组件，所以在大小并不一定相等。这里就出现了一个问题，比如前面两个组件来自同一个对象，消耗了SSD的70%存储，第三个组件则来自于一个更大的对象，消耗了SSD的85%存储，可以看到他们在存储空间的消耗上较不均匀。

Rebalance的作用就是让空间的消耗更加均衡，将磁盘空间使用超过80%（触发Rebalance的临界值）的容量盘中的较大的组件（如C3）打散成更小的两部分组件（如C3+C4）甚至更多的组件，分别放到不同的磁盘中。

这种Break up（我称之为打散）机制，最多能够将大组件打散成8份更小的组件。

Faster Resynchronizations in Transient Outages

现在有这样一种情况，图中第一台主机损坏导致需要在第四台上创建新的副本（C1、C2、C3），当新的C1副本刚创建完成时第一台主机又恢复了。

vSAN从6.6开始有了一种新的机制，用来对此种情形进行选择，是继续生成新的副本，抑或使用现有的副本。在图中的情况下，会放弃生成第四台主机上的C1，转而使用第一台主机上的旧的副本，当然这些副本数据会同步至最新状态。如果第四台主机已经快复制完成了，就不会再去使用旧的副本。这就是智能Rebuild的操作过程。

Opportunistic Repairs to Regain Resilience

上图结构有3个副本和2个仲裁组件，可以看到有两台主机已经损坏，但是只有一台空闲主机。此时我们会尽可能多的修复组件，最后的空闲主机会用来复制副本，其中一个仲裁组件所在的主机也会用来放置副本，原先的仲裁组件被移除。当损坏的主机重新上线之后，仲裁组件会被放入其中。

Resilient Repairs during Transient Outages

我们日常下载中经常会应用到断点续传的技术，vSAN中也有类似的处理机制。上图的场景中由于第一台主机损坏后又重新上线了，于是需要从第二台主机上同步最新副本至第一台主机，在同步了一部分之后网络突然断开了。在原先的版本中这种情形是需要重新同步的，而现在则可以在网络恢复后，接着同步后续的部分。这就是Resumable Resync技术。

Degraded Device Handling（DDH）

vSAN有一个很好的特性叫做故障的主动探测。当硬盘出现故障或者被判断为将来会出现故障的时候，该设备会被列为怀疑设备。如果设备有副本就会在副本所在的主机上将副本标为已消失，然后再找一个新的设备进行Resync。如果不存在副本则会主动的将组件给转移到其它的主机上。

vSAN Caching and I/O Path Explained

Anatomy of a write

如上图所示的，在写数据的时候，Guest OS将写操作发送到VMDK，VMDK会先将任务交给控制器，然后控制器转到DOM Client，接着由DOM Client转到DOM Owner。DOM Owner会根据存储策略克隆写操作，向多台主机分发，数据被写入到主机SSD缓存中（Log），然后返回写成功，最后两台主机从缓存向容量盘同步数据。

Anatomy of a Read（All flash）

Guest OS执行了一个读操作，DOM Owner根据负载均衡策略，可以从众多个节点中选取一个主机上的副本进行读取，同一个Block始终从同一个主机上的副本读取，如果只有本地副本，则会直接读取，略过负载均衡机制。

读操作到达主机后，首先探查的是主机的内存缓存，内存缓存最多只能用到0.4%或1GB。然后探查SSD的写缓冲或者读缓存，如果还是没有的话就去容量盘中探查读取，任何一步命中后，数据返送到Owner，然后返送到VM。

vSAN Caching Algorithm

在集群级别，尽量提高flash的利用率，获取缓存收益。

做VM迁移的时候尽量只迁移虚拟机的内存数据，尽量避免存储的迁移。

关注延时问题，读数据的时候，如果是直接从本地的缓存（Flash）中读取，延时是微秒级别的。而数据要是通过网络读取的话，延迟会达到毫秒级别（5-50）。由于vSAN的存储是分布式的，所以在迁移的时候如果附带存储，就需要进行跨网络的读取，此时它的延迟相对本地SSD I/O要大很多。

我们都知道延伸集群可以将vSAN扩展到两个数据中心，类似于双活存储。这时数据在进行I/O的时候本地和远程的主机都有可能被读取，而远程主机的读取延时是比较高的，所有在这种延伸集群中我们可以让vSAN 100%读取本地，以避免高延时，保障性能。

以上为今天的全部分享内容，谢谢大家！