【编者按】

今天是元旦，祝大家在2016年里身心健康，六六大顺（2016=666+666+666+6+6+6），新年快乐！

如果您发现本篇文章有哪些不对的地方，或者不够严谨的地方，请告诉我，可以通过微信或者QQ(9269216)和我联系。提出的高质量问题或者好建议的话，还有机会获得礼品或红包: )

---Begin---

搭建一个VSAN集群（也可称为群集），至少要三个服务器节点（也即ESXi主机），其中两个主机存放副本，剩下一个主机存放“见证”（也即Witness，充当仲裁）组件，这样可以允许最多一个主机出故障，同时确保虚机无中断地持续运行（有时需要结合vSphere HA进行重启）。不过在VSAN 6.1新增的一个特性，也即远程分支办公室的场景下，Witness不一定要放在一台真实的物理服务器上，可以存放在ESXi虚机上，后面会有详细描述。注意，本文后面提到的副本（Replicas)数，就是包含原件和镜像在内的所有的数量，也就是说，n个副本意味着总共n份数据。

需要注意的是，尽管VSAN完全支持3个主机的配置，但如果可行，建议至少4个主机。这是因为，只有3个主机的VSAN集群，在发生故障时，有些情况下，VSAN无法在群集中的其他主机上重新构建（Rebuild）组件（Components）来允许另一次故障。同样，在3个主机配置下，VSAN不能在维护模式（Maintenance Mode）期间从主机迁移所有数据。

而4个主机的VSAN群集可以提供更高的灵活性。VSAN集群最多时可以支持64个主机。每台为VSAN提供存储资源的主机至少有一个SSD，及一个HDD。每台主机至少6GB内存。

下面我们依次介绍VSAN的配置、磁盘组、vsanDatastore、对象、组件和网络。

1. VSAN的两种配置–混合与全闪存

截止目前，VSAN最新的版本是6.1，是2015年9月发布的，对应的vSphere版本是ESXi6.0 Update 1。

VSAN 6.0以后，包含两种配置：

（1）混合配置（Hybrid）：缓存层为SSD，持久化层（也称为容量层）为HDD（机械磁盘）；

（2）全闪存配置（AllFlash）：缓存层和持久化层都是SSD；一般选取速度更快、耐久性更好的写密集型SSD做为缓存层；选取成本更低、容量更大的读密集型SSD做为持久化层。

需要注意的是，当我们计算存储容量时，只能计算持久化层的存储。缓存层只是用来做性能加速的。下图展现了混合配置下的VSAN体系结构图。

混合配置和全闪存配置都建议将“10% 的已占用容量”用于缓存层；然后再考虑NumberOfFailuresToTolerate（最大允许的故障数）。例如，用户计划置备 1000个虚拟机，每个虚拟机有 100GB 精简置备的逻辑地址空间。然而，他们预计一段时间内，每虚拟机占用的存储容量平均为20GB。这样，已占用容量就是按照20GB计算，此时20GBx1000x10%=2TB。而不是4TB（即便有两份副本）。需要注意的是，这个10%不是硬性要求的，主要还是取决于需要被缓存提速的那部分活跃数据有多少。

在混合配置中，缓存算法会尝试最大限度提高读写性能。缓存的70%为读缓存，用于存储频繁读取的磁盘块，从而最大限度减少对速度缓慢的磁盘的访问。缓存的30%为写缓存，用于执行写入操作，每个IO会先写入缓存层，再批量写入持久化层。如果可行，系统会合并多个写操作，并按顺序写入，从而再次最大限度提高磁盘性能。

在全闪存配置中，100% 的缓存都分配给写入操作，因为持久化层的SSD（固态硬盘）提供的读取性能绰绰有余。大量写入操作保存在缓存中，仅在需要时写入持久化层的SSD，从而延长持久化层的寿命。经常在写缓存里访问的热数据仍然留在缓存里，而很少被访问的冷数据就Destage（刷）到持久化层的SSD里。

混合配置下，强烈推荐使用支持直通（Pass-Through）模式的磁盘控制器。如果现有的磁盘控制器不支持直通模式，才考虑使用RAID-0，但需要注意的是，采用RAID-0配置HDD后，如果HDD出故障需要更换时，操作较为复杂，需要重新配置RAID-0。采用直通模式时，只需简单地插入新盘。

2. VSAN的磁盘组- DiskGroup

磁盘组是一组盘，每个磁盘组包含1个SSD做为缓存层，1~7个HDD或者SSD做为持久化层。缓存层的SSD为同一个磁盘组内的持久化层盘提供性能加速。磁盘组这种设计，在混合配置下，同时兼顾了性能和容量。

VSAN集群中，允许某些主机不提供存储资源，但一般不建议这么做。每个主机最多支持5个磁盘组。如果希望每个主机使用多块SSD，就需要创建多个磁盘组。一般而言，用于缓存层SSD的容量相对于持久化层的比率越高，能够用于IO加速的缓存就越多，性能就更有保障。

在VMware官网发布的《VMware Virtual SAN 6.0Performance - Scalability and Best Practices》白皮书中，我们可以了解到，测试的配置是：每个主机有两个LSIMegaRAID SAS控制器，每个控制器对应一个磁盘组，每个磁盘组配置1块400GB Intel S3700 SSD和4块900GB 1万转的SAS。测试的结果是，从4个到64个主机的不同集群里：

（1）4K大小IO，随机，100%读的时候，64个主机能达到740万IOPS（平均每个主机11.56万IOPS，每个主机的每个磁盘组为5.78万IOPS）；

（2）4K大小IO，随机，混合读写（70%读30%写，模拟OLTP应用）的时候，64个主机能达到200多万IOPS（平均每个主机3.1万IOPS，每个主机的每个磁盘组为1.55万IOPS）；

可以看出，在下图中，两个磁盘组相对于一个磁盘组，性能几乎线性增长。

在《VMware Virtual SAN 6.0 Design and Sizing Guide》白皮书里提到，VMware建议VSAN集群内的每个主机使用多个磁盘组。不仅是为了可能提高性能，同时也为了减小故障域。因为每个磁盘组的缓存层SSD只会影响该SSD所在的磁盘组的持久化盘，不影响同一主机的其他磁盘组。

如果 3 节点群集中每个主机只有一个磁盘组，当其中一个闪存缓存设备发生故障时，将无处重新构建磁盘组中的组件。

然而，如果每个主机有多个磁盘组，而且在某个闪存缓存设备发生故障时其他磁盘组中有充足的容量，VSAN将能够在剩余磁盘组中重新构建受影响的组件。这是在计划部署 3 节点 VSAN 群集时另一个需要注意的事项。

3. VSAN的存储池-vsanDatastore

VSAN聚合了集群内的SSD和HDD，形成一个共享的存储池，也即vsanDatastore被vSphere集群使用。这个vsanDatastore可以随着主机、磁盘组或盘的增减，动态地在线地扩大或缩小。这为业务（虚机）的弹性扩展奠定了坚实的基础。下图就是3个主机扩展为4个主机后的vsanDatastore，从4.86TB动态地在线地扩大为6.48 TB。

我们知道，以往的传统存储划分LUN给vSphere，做完VMFS格式化后，形成的datastore大小基本都是固定的，随着业务规模的变化，存储容量所需的在线调整很难实现，也即扩大和缩小比较复杂。

VSAN不仅支持分布式存储的在线横向扩展（Scale Out），也支持纵向扩展（Scale Up）。通过增加主机，提供存储容量的vsanDatastore可以在线扩大，同时整体的性能也线性增长。通过添加磁盘组，或者增加HDD，也可使得vsanDatastore得到在线扩大，这种在线的纵向扩展无需增加新主机，从而避免了计算资源的浪费。VSAN也支持在线移除磁盘组（建议先设置成维护模式- Maintenance Mode，虽然这不是必须），或者在剩余空间足够的情况下，移除SSD或HDD。下图可以查看到，VSAN提供了直观的图形界面，进行磁盘组或盘的添加或移除。这位用户对VSAN存储管理和维护，提供了极大的灵活性和便利。也为在线调整存储的空间和性能，奠定了坚实的基础。例如，通过增加SSD和磁盘组，或者通过依次将主机设置成维护模式，将主机的SASSSD更换成NVMe SSD（一种PCIe SSD），或者更换成UltraDIMM SSD（插在内存槽上的SSD），实现业务不停顿的情况下，来在线提升性能。

4. VSAN的对象–Object

需要清楚的是，VSAN不是分布式文件系统，是分布式对象存储系统。VSAN的对象，是指符合SCSI语义的单个存储块设备。从概念上讲，也可以被视为“卷”（Volume），即 Amazon EC2 和 OpenStack 中使用的术语。VSAN的对象取代原来传统存储中的LUN，成为VSAN的主要存储单元。VSAN的对象是带有叶子的RAID树。如下图所示，这是一颗副本数为2（也即最大允许故障数FTT=1），条带数（也即副本横跨的盘数）为2的RAID树，是一个VMDK对象。

在vsanDatastore上，虚拟机有5种不同类型的对象，每个虚拟机都是由这些对象的部分组合而成。如下图所示，这些对象是：

VM Home（虚拟机主页），或称“名字空间目录"；

VM swap（交换文件对象），如果虚机处于开机状态；

VMDK（虚拟磁盘），VSAN 5.5时，最大2TB，而VSAN 6.0时最大62TB；

Snapshots（快照），也即增量盘，建立快照之后每个对象都有；

Memory（vmem，虚拟机内存文件），VSAN5.5时，当快照创建时，虚拟机内存以文件形式存放在VM Home里。而在VSAN 6.0时，虚拟机内存在vsanDatastore里实例化为独立的对象。

5. VSAN的组件– Components(含Witness)

组件是对象的RAID树上的叶子，分布在VSAN集群中的各个主机上。其实，组件是按照两种主要的技术分布的：Striping（条带），即RAID 0；和Mirroring（镜像），即RAID 1。注意，RAID的构成和组件的分布取决于最初创建的存储策略。下图是副本为2，条带为2的组件分布情况。

每个组件都是存放在一个特定的“缓存层（SSD）+持久化层（如HDD）"的组合上，也即磁盘组上。组件如同对象一样，是一个逻辑概念。以混合配置为例，组件所对应的真实数据，最终都是要落到HDD的。不过，某一时刻，应用对它的读写发生在SSD，还是HDD，取决于写数据时，SSD的数据是否Destage（刷）到HDD上。或者读数据时，是否从HDD复制到了SSD。主机的组件不仅包括开机状态下，还包括处于关机状态下的虚拟机的组件。

VSAN5.5 目前支持每台主机最多包含 3000 个组件，VSAN 6.0可达9000个组件。

容量大于255GB的对象会自动被分为多个组件。我们知道，VSAN6.0 现在支持 62TB 的VMDK。然而，考虑到VSAN集群支持的最大组件数，需要谨慎衡量应用程序是否真的需要这么大的VMDK。以单个62TBD VMDK为例，假设副本数为2时，按照255GB拆分，需要消耗约500个组件。

此外，如果设定的每个对象的条带数超过默认值 1，则每个条带将计为一个单独的组件。

简而言之，条带即组件。

为了方便管理员详细的了解VMDK对象各个组件的分布位置，VMware提供了vSphere Web Client图形界面，可以清晰直观地查看对象的构成和组件的分布。

需要注意的是，无论组件如何分布，为了确保可用性，VSAN绝不会让不同的副本（镜像）组件共用同一台主机。

在VSAN 5.5中创建的每个组件，元数据会占用额外的2MB空间，此时磁盘格式为1.0，对应的磁盘文件系统是VMFS-L。而在VSAN 6.0

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种规则，后面会按照图中下拉列表的从上至下的顺序详细介绍各个规则的含义。

VSAN的虚拟机存储策略的5种规则
1）每个对象的磁盘带数（SW）
Number of disk stripes per object ：每个对象的磁盘带数（Stripe Width，简写为SW）是指，虚拟机对象的每个副本所横跨的持久化层的盘的数量，也即每个副本的条带宽度。值如果大于 1，则可能产生较好的性能，但也会导致使用较多的系统资源。下图是条带宽度为2的示意图。

虚拟机存储策略之条带宽度
在混合配置中，条带分散在磁盘中。在全闪存配置中，可能会在构成持久化层的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%（也即不预留）。

VSAN虚拟机存储策略的默认值

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等文章。在此一并致谢。

【编者按】

写文章不容易，尤其是技术细节，需要查证很多资料。本篇文章花了很长时间才撰写完成。如果您觉得好，请帮忙转发、点赞。您的鼓励是微信公众号"乐生活与爱IT"能够持续不断分享干货的动力。

另外，欢迎大家投稿，请联系我的微信或者QQ号：9269216 。

---Begin--

本篇文章会详细介绍虚拟机存储策略，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种规则，后面会按照图中下拉列表的从上至下的顺序详细介绍各个规则的含义。

VSAN的虚拟机存储策略的5种规则

1）每个对象的磁盘带数（SW）

Number of disk stripes per object ：每个对象的磁盘带数（Stripe Width，简写为SW）是指，虚拟机对象的每个副本所横跨的持久化层的盘的数量，也即每个副本的条带宽度。值如果大于 1，则可能产生较好的性能，但也会导致使用较多的系统资源。下图是条带宽度为2的示意图。

虚拟机存储策略之条带宽度

在混合配置中，条带分散在磁盘中。在全闪存配置中，可能会在构成持久化层的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%（也即不预留）。

VSAN虚拟机存储策略的默认值

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等文章。在此一并致谢。