VMware SDS 之四：VSAN的技术细节

本篇文章会详细介绍虚拟机存储策略，IO如何流动等技术细节。在介绍存储策略前，我们先来探讨一下支持存储策略必备的技术VASA。
目前占据存储市场主流的磁盘阵列，大多数都是在以vSphere为代表的服务器虚拟化出现之前就存在的。由于服务器虚拟化聚合了前端多个业务虚机的IO，使得阵列在性能、部署、管理上，面临着巨大的挑战。从2011年在vSphere 4.1开始引入的VAAI，到2013年在vSphere 5.0引入的VASA 1.0，再到2015年在vSphere 6.0引入的Virtual Volumes（简称vVOL）等技术，vmware就一直在发展相关技术，着力帮助用户化解这一存储难题。

1. VMware VASA

VASA，全称是VMware vSphere API for Storage Awareness，意指存储感知的vSphere API（编程接口）。它是供vSphere使用的API。
如果你以前用磁盘阵列为vSphere的虚机划分过存储空间，你会记得，我们需要告诉存储管理员，或者从存储管理员那了解LUN的特性，例如磁盘类型，是否分层，RAID级别，是否精简置备，是否设置了去重或压缩，等等。
然后由vSphere管理员识别LUN ID，做VMFS格式化，创建datastore，最后才能提供存储空间给虚机。整个过程，需多方配合，流程也很复杂。
如果虚机数量多，业务种类多，存储管理员或vSphere管理员还得维持一张大的表格，去记录每一个datastore所在的LUN的特性，方便未来的管理或变更。VASA的出现，就是为了解决用户的这个痛点。
存储供应商可以使用VASA为vSphere提供有关特定磁盘阵列的信息，包括磁盘阵列功能特性（例如快照、重复数据删除、复制状态、RAID级别、以及是精简置备还是厚置备）和状态（容量、运行状况、故障排除等）等信息。
以便在存储和虚拟基础架构之间实现紧密集成。这些信息可通过VMwarev Center Server传递给用户。在VMware的软件体系中，vVOL、VSAN和vSphere APIs for IO Filtering （简称VAIO）都用到了VASA，将其用作vSphere存储的单个统一控制层。
VASA Vendor Provider，简称VASA Provider（后面以此简称为主）或者Storage Provider，中文意思是存储提供程序，也称为VASA提供程序。是在vSphere环境中充当存储感知服务的软件。该提供程序可协调一端的vCenter Server和ESXi主机与另一端的存储系统之间的带外通信。 
VASA Provider可提供来自磁盘阵列（为vVOL）或VSAN的信息，以便存储功能可以显示在 vCenter Server 和vSphere Web Client 中。反过来，VASA Provider会将虚拟机对存储的要求推送给存储，管理员可以采用存储策略的形式定义这些要求。
以确保在存储层中分配的存储资源符合策略中设定好的要求。通常，存储供应商负责提供可与vSphere集成的VASA Provider，VASA Provider都必须经过VMware的认证并进行正确部署。如果后端存储是VSAN，VASA Provider会再VSAN群集创建时，就已经自动注册好了。

VSAN 的VASA Provider

VASA的出现，是虚拟化平台相关存储技术的一次飞跃

以往，业务虚机（及其用到的VMDK）与后端存储宛若隔开的两个世界，存储不知道上面运行的是什么虚机，状况如何？虚机不知道运行在什么样的存储资源上，更无法根据业务变化要求调整存储资源。只能依靠vSphere管理员和存储管理员介入和沟通。现在，通过VASA，就实现了虚机和存储的双向感知。

VASA 1.0的时候，信息流是单向的，存储只是将磁盘类型、RAID设置、容量、健康状态、配置等信息提供给vCenter，并且进行展现。vSphere管理员还是必须自己选择合适的存储来存放虚机。通俗一点说，就是虚拟服务器vSphere只能读取后端存储的元数据信息。下面两图分别是EMC VNX和DELL Compellent的VASA特性在vCenter上的呈现。

EMC VNX在VASA1.0时，在vCenter界面上的呈现

DELL Compellent在VASA 1.0时，在vCenter界面上的呈现

到了VASA 2.0，则实现了双向通信，vCenter可以将虚拟机对存储的要求向下推送到后端存储。管理员创建虚拟机时，可以根据与底层磁盘相关的容量、性能和功能方面的详细信息轻松选择最合适的存储资源。通俗一点说，就是虚拟服务器vSphere对后端存储的元数据信息可读可写。
VASA为VMware SPBM（基于存储策略的管理）实现策略驱动存储资源的部署和管理奠定了坚实的基础。

2. 虚拟机存储策略
截止版本6.1，VSAN的虚拟机存储策略有5种功能，或者说5种规则（Rule）。从各家磁盘阵列厂商对Virtual Volumes的支持，我们可以看到VMware SPBM所涵盖的规则要比VSAN的5个规则丰富得多，随着VSAN在数据服务（Data Services，也即存储功能）的不断发展，未来会支持更多的规则。例如，在2015年9月VMword大会看到VSAN6.2预览版的去重、纠删码、QoS（IOPS Limit），相信将来也会逐渐放到存储策略里。
在VSAN里，每个定义好的策略其实就是5种规则的组合，也即规则集（Rule-Set）。下图我们可以看到这5种规则，后面会按照图中下拉列表的从上至下的顺序详细介绍各个规则的含义。

虚拟机存储策略之条带宽度
在混合配置中，条带分散在磁盘中。在全闪存配置中，可能会在构成持久化层的SSD中进行条带化。
需要强调的是，VSAN目前主要是靠缓存层的SSD，来确保性能。所有的写操作都会先写入缓存层的SSD，因此增大条带宽度，不一定就带来性能的提升。只有混合配置下的两种情况，能确保增加条带宽度可以增加性能：一是写操作时，如果存在大量的数据从SSD缓存层Destage（刷）到HDD；二是读操作时，如果存在大量的数据在SSD缓存层中没有命中。因为，多块HDD的并发能在这两种情况下提升性能。
默认值为 1。最大值为 12。VMware不建议更改默认的条带宽度。
2）闪存读取缓存预留
Flash read cache reservation (%) ：闪存读取缓存预留是指作为虚拟机对象的读取缓存预留的闪存容量，数值为该虚拟机磁盘(VMDK) 逻辑大小的百分比，这个百分比的数值最多可以精确到小数点后4位，例如2 TB的VMDK，如果预留百分比为0.1%，则缓存预留的闪存容量是2.048 GB。预留的闪存容量无法供其他对象使用。未预留的闪存在所有对象之间公平共享。此选项应仅用于解决特定性能问题。
全闪存配置不支持此规则，因此在定义虚拟机存储策略时，您不应更改其默认值。VSAN仅支持将此属性用于混合配置。
无需设置预留即可获取缓存。默认情况下，VSAN将按需为存储对象动态分配读取缓存。这是最灵活、最优化的资源利用。因此，通常无需更改此参数的默认值 0。
如果在解决性能问题时要增加该值，请小心谨慎。如果在多个虚拟机之间过度分配缓存预留空间，则需小心是否可能导致SSD空间因超额预留而出现浪费，且在给定时间无法用于需要一定空间的工作负载。这可能会影响一些性能。
默认值为 0%。最大值为 100%。

3）允许的故障数（FTT）

Number of failures to tolerate ：允许的故障数（以后简称为FTT）定义了虚拟机对象允许的主机和设备故障的数量。如果FTT为 n，则创建的虚拟机对象副本数为 n+1，见证对象的个数为n，这样所需的用于存储的主机数为副本数+见证数 = n+1 + n = 2n+1。
前面多次提到的副本数为2，表示的就是最多允许一台主机出故障，也即FTT值为1，此时主机数最少为3。截止VSAN 6.1版，FTT的最大值为 3，也即最多4份副本。
为虚拟机分配存储资源时，如果未选择存储策略，则VSAN将使用默认的虚拟机存储策略，默认策略规定了FTT为1。下图就是FTT=1的示意图。
 

虚拟机存储策略之允许的故障数
如果已配置故障域，则需要 2n+1 个故障域，且这些故障域中具有可提供容量的主机。不属于任何故障域的主机会被视为其自己的单个主机故障域。
如果不希望VSAN保护虚拟机对象的单个镜像副本，则可以将FTT指定为 0。但是，主机在进入维护模式时，可能会出现异常延迟。发生延迟的原因是VSAN必须将该对象从主机中逐出才能成功完成维护操作。将FTT设置为 0 意味着您的数据不受保护，并且当VSAN群集遇到设备故障时，您可能会丢失数据。
VSAN的FTT默认值为 1。最大值为 3。
4）强制置备
Force provisioning ：如果强制置备设置为是（yes），则即使现有存储资源不满足存储策略，也会置备该对象。这样，在虚拟机Summary页和相关的虚拟机存储策略视图中，这台虚拟机会显示成不合规（Not Compliant），如下图所示。
虚拟机存储策略之强制置备，呈现出来的不合规（Not Compliant）
强制置备允许VSAN在虚拟机初始部署期间违反 FTT、条带宽度和闪存读取缓存预留的策略要求。VSAN将尝试找到符合所有要求的位置。如果找不到，它将尝试找一个更加简单的位置，即将要求降低到FTT=0、条带宽度=1、闪存读取缓存预留=0。这意味着VSAN将尝试创建仅具有一份副本的对象。不过，对象依然遵守对象空间预留（下面会详细介绍）的策略要求。
VSAN 在为对象查找位置时，不会仅仅降低无法满足的要求。例如，如果对象要求FTT=2，但该要求得不到满足，那么VSAN不会尝试 FTT=1，而是直接尝试 FTT=0。同样，如果要求是FTT=1、条带宽度=10，但VSAN没有足够的持久化盘容纳条带宽度=10，那么它将退回到 FTT=0、条带宽度=1，即便策略FTT=1、条带宽度=1 也许能成功。
使用强制置备虚拟机的管理员需要注意，一旦附加资源在群集中变得可用，如添加新主机或新磁盘，或者处于故障或维护模式的主机恢复正常，VSAN可能会立即占用这些资源，以尝试满足虚拟机的策略设置，也即朝着合规的方向努力。
默认值为否（no），这对于大多数生产环境都是可接受的。当不满足策略要求时，VSAN可以成功创建用户定义的存储策略，但无法置备虚拟机，如下图的警告信息表示，需要3台主机提供存储，而目前在集群里只发现两台。
 

5）对象空间预留
Object space reservation (%)：对象空间预留是指，部署虚拟机时应预留或厚置备的虚拟机磁盘(VMDK) 对象的逻辑大小百分比。默认值0意味着部署在VSAN上的所有对象都是精简置备的，一开始不占任何空间，只有当数据写入后，才会按存储策略动态占据vsanDatastore的空间。
默认值为 0%。最大值为 100%。当对象空间预留设置为100%时，虚拟机存储对空间的要求会被设为厚置备延迟置零（LZT，Lazy Zeroed Thick）格式。

3. 存储策略的使用
1）系统默认的存储策略
下图我们可以看到VSAN的5个规则在默认情况下表示的含义，分别是：
FTT=1，也即副本数为2，这样写满100GB的VMDK，实际要消耗200GB的存储空间；
条带宽度为1，也即每个副本只横跨一块持久化盘；
强制配置为否；
对象空间预留为0%（也即精简配置）；
闪存读取缓存预留为0.0000%（也即不预留）。

2） 分配虚机时选择存储策略
VMware的基于存储策略的管理，使得管理员可以更多地关注业务应用，围绕着业务应用/虚机为中心，而不是围绕着存储为中心，从上至下的自动化地分配存储资源。存储管理员可以从以往重复繁琐枯燥的卷管理、LUN映射、VMFS格式化、建Datastore的工作中解脱出来，专注在更高级的工作中，也即根据不同的工作负载对存储性能、可用性、容量的要求，创建存储策略。存储策略创建好后，能够适用于同类工作负载的不同虚机。
如下图，创建的存储策略有，Print Server，Tier 2 Apps，VDI-Desktops。当vSphere管理员需要创建虚机，或者给已有虚机创建新的VMDK时，就可以根据存储管理员事先创建好的存储策略，或者系统默认的存储策略，进行选择了。这样，就极大地减少了各个管理员交互的时间和工作量，使得存储资源的部署非常便捷。下图是创建虚机时，选择存储策略。

.分配虚机时选择VSAN的存储策略
3） 变更存储策略非常简单
我们知道，用户的业务应用种类很多，有些业务应用可能在某一个特定时间段需要通过变更存储资源，去应对高峰时刻或关键时刻所需的高性能、高可用性。传统存储需要好几个步骤，甚至需要停顿业务，才能变更存储策略。而VSAN非常简单，只需创建新存储策略，并施加到(Apply)虚机，即可。
 

变更存储策略：传统存储与VSAN的比较

4. VSAN的故障域（Fault Domain）
在VSAN 6.0里，新增了一个特性是Rack Awareness（机架感知），它可以为机架、主机、网络和磁盘提供故障恢复能力。无论磁盘、主机、网络发生硬件故障，甚至整个机架出故障，也不会造成停机或数据丢失。其实机架感知就是借助VSAN的故障域，与vSphere HA 和维护模式互操作来实现这一功能的。下图意指每个机柜设置成一个故障域，VMDK的两份副本一定会自动化分放在不同的机柜里，这样即使机架A出现故障（如断电），也不会停机或数据丢失。

VSAN支持机架感知（Rack Awareness）

VSAN故障域功能将使VSAN副本分散到各个不同故障域中的主机上。
故障域构造时必须至少定义三个故障域，每个故障域可能包含一个或多个主机。故障域定义必须确认可能代表潜在故障域的物理硬件构造，如单个机柜。如果可能，建议使用至少四个故障域。原因与之前建议VSAN至少4个主机做为集群类似。另外，建议向每个故障域分配相同数量的主机，使用具有统一配置的主机。如果启用故障域，VSAN将根据故障域而不是单个主机应用虚拟机存储策略。根据计划分配给虚拟机的存储策略中规定的“允许的故障数”属性，计算群集中的故障域数目：
Number of fault domains=2*Number of failures to tolerate(即FTT) +1

VSAN的故障域
5. VSAN I/O流
在理解VSAN I/O的读写机制前，我们需要明确一个前提，就是VSAN是分布式对象存储。当VMDK对象的第一笔横跨各个条带的数据按照存储策略写入盘后，实际上该VMDK对象在VSAN集群会存放在哪些主机的哪些盘上，就已经固定下来了，也就是说，之后新增的数据，仍会遵循同样的部署方式，按照条带分段大小（1MB）以增量的方式去消费盘上的空间，体现出来的是对象容量在增长。直到对象增长超过255GB，此时VSAN会新建一个组件。这也是有时我们发现某个副本实际的组件数会比条带宽度大的原因。

VSAN的条带是按照1MB的增量进行扩大的
1） 剖析写I/O
写I/O在混合配置和全闪存配置下是一样的。假设：
FTT=2（也即两份副本）；
虚机vm运行在主机01上；
主机01是vm的VMDK对象的属主；
该对象有两份副本，分别在主机02和主机03上；
我们来剖析一下写I/O的步骤：
步骤1，虚机vm发起写操作；
步骤2，VMDK对象的属主（也即主机01）触发写操作到虚拟磁盘；
步骤3，主机01克隆写操作，主机02和主机03各自独立地执行；
步骤4，主机02和主机03各自在自己的缓存层（SSD）的log上执行写操作；
步骤5，缓存写完，主机02和主机03分别立刻发确认信息给属主；
步骤6，属主收到了两个主机都完成I/O并确认的消息后；
步骤7，属主将一批已经确认过的写I/O合并，Destage到持久化层的盘；

剖析VSAN的写I/O

2） 将缓存的写I/O刷进持久化层
混合配置中的持久化层是HDD，HDD在顺序写情况下表现良好。VSAN使用电梯算法（Elevator Algorithm）异步地将来自不同虚机的，缓存内的，按照每块HDD物理地址相邻的数据，批量地Destage（刷）进磁盘中，以此来提升性能。如果写缓存还有充足的空间时，VSAN不会频繁开启Destage的操作，这样就避免了对同一个数据的多次改写，屡屡刷进HDD里。
全闪存配置中的持久化层是SSD，被频繁写的数据（也即热数据）仍然停留在缓存层，而那些较少访问的数据才会被刷进持久化层（也即提供容量的SSD）。

3） 剖析读I/O
首先需要注意的是，读可能跨副本发生。

先来看混合配置下的读I/O：

步骤1，虚机vm发起对VMDK对象的读操作；
步骤2，VMDK属主（主机01）根据如下原则选取从哪个副本读：
1) 通过跨越不同副本实现负载均衡
2) 不一定要从属主所在主机的副本读
3) 一个给定的块，其上的数据会只从同一个副本读；
步骤3，如果在读缓存里，直接读；
步骤4，否则，从HDD读到读缓存，取代某些冷数据；
步骤5，将数据返回给属主；
步骤6，完成读操作，将数据返回给虚机vm；
剖析VSAN的读I/O （混合配置下）

再来看全闪存配置下，它的读I/O大部分与混合配置下一样，只是在步骤3和步骤4有所不同：
步骤3，如果数据在写缓存里（注意是写缓存，不是读缓存！），直接读；
步骤4，否则，直接从持久化层的SSD里读数据（无需复制到缓存层！）；

VMware SDS系列，未完待续……，欢迎持续关注和转发 : )

本篇文章参考了《VSAN权威指南》、VMware官方网站和VSAN 6.0 Design and Sizing Guide等文章。在此一并致谢。

本文转自学海无涯博客51CTO博客，原文链接http://blog.51cto.com/549687/1747492如需转载请自行联系原作者

520feng2007