本篇文章会详细介绍虚拟机存储策略,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群集建立时,就已经自动注册好了。
php
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、条带宽度=一、闪存读取缓存预留=0。这意味着VSAN将尝试建立仅具备一份副本的对象。不过,对象依然遵照对象空间预留(下面会详细介绍)的策略要求。
VSAN 在为对象查找位置时,不会仅仅下降没法知足的要求。例如,若是对象要求FTT=2,但该要求得不到知足,那么VSAN不会尝试 FTT=1,而是直接尝试 FTT=0。一样,若是要求是FTT=一、条带宽度=10,但VSAN没有足够的持久化盘容纳条带宽度=10,那么它将退回到 FTT=0、条带宽度=1,即使策略FTT=一、条带宽度=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等文章。在此一并致谢。