VMware vSphere 5.1 群集深入解析（二十一）- 存储I/O控制（SIOC）-阿里云开发者社区

第三部分 vSphere存储DRS

第三章存储I/O控制（SIOC）

当数据存储群集被建立，I/O度量值开启，通过存储DRS，存储I/O控制也同时开启。我们觉得用一章来说明存储I/O控制非常合适，最重要的是，存储DRS利用存储I/O控制的某些功能来决定数据存储的能力，在我们了解这些之前，让我们先讨论些基础知识。

介绍

存储I/O控制（SIOC）在资源争用期间，提供一个方法来公平的分配存储I/O资源，它启用后，管理员在高度整合的环境中来运行重要的工作流时，虚拟存储环境没有自己造成拒绝服务的风险，另外，它帮助阻止其它的情况下的干扰（同一个数据存储上的一台虚拟机能对另一台虚拟机造成负面的影响），SIOC利用虚拟机份额来达到公平分配存储资源，在SIOC发布之前，虚拟磁盘的份额被介绍的比较长，但是，SIOC介绍Datastore-Wide计划，主要的不同是在每个主机级别没有SIOC计划，尽管为SIOC计算相当复杂，开启和配置SIOC是不行的（图109），SIOC只需要几步就可以启用，当存储DRS使用I/O度量值选项，它将自动启用，在我们举例子之前，我们想确认每个人理解了一些关于此块的基本概念，以及没有SIOC会造成的影响。

图109：开启存储I/O控制

内部排队

当和许多我们的客户讨论SIOC，我们注意到有一些基本的概念混淆，关于怎样实际确认资源在所以的虚拟机和主机间被公平的分配，这个例子就包括它，但是原理可能没有那么明显，所以我们叫它一个特别的称呼：排队节流

在我们解释怎么排队节流工作之前，我们想简单的解释下不同的队列，当客户端系统初始化I/O，这是为了工作流和队列能相遇：

客户设备驱动队列深度（LSI=32，PVSCSI=64）
VHBA（hard code 限制LSI=128，PVSVSI=255）
Vmkernel设备驱动（FC=32,ISCSI=128，NFS=256，本地磁盘=256）
多路径SAN/阵列队列（包括端口缓冲区，端口队列，磁盘队列等）

这些值得注意的Disk.SchedNumReqOutstanding (DSNRO)没有提到，正常来说它在Vmkernel设备驱动后直接提到，但是，当SIOC开启，DSNRO就不再经常使用，自从SIOC保证了一定程度的公平。

考虑到你设置你为你的HBA设置了64的队列深度，虚拟机在数据存储上产生I/O，如果它只是数据存储上的单个虚拟机，增加到64的 I/O将立即结束设备驱动，但是，在大多数的环境中，LUNs被很多虚拟机共享，在大多数的场景中，这些虚拟机应该被平等对待，当同一数据存储上两个或者更多的虚拟机产生I/O，DSNRO将踢出它，但是，当Vmkernel检测到只有一个节流队列，计数器的阈值就达到了，计数器的名字叫做Disk.SchedQControlVMSwitched,默认设置为6，这意味着当手工I/O节流队列低于Disk.SchedNumReqOutstanding的值（默认是32）之前，Vmkernel需要检测6个虚拟机的交换机，（虚拟机交换机意味着需要检测6次，当前I/O不能来自之前虚拟机的同样I/O）

节流发生的原因是因为驱动已经产生I/O，Vmkernel不能控制顺序，只能想象你有VM-A产生了一些I/O，另一个VM-B刚刚也产生了I/O，VM-A将结束全天运行的大多数全深度队列，每次VM-B产生I/O，它将通过Vmkernel 调度器快速捡起（这是个不同的知识点），并尽快发送另外一个完成的给驱动，但是它不必要在VM-A 64的I/O的队列之后，因为它已经在队列中，这些通过VM-B将明显的添加到I/O延迟经历中，这是不可取的，通过限制未完成的请求，我们允许Vmkernel快速安排VM-B的I/O到VM-A的I/O流中，尽管为VM-B减少了延迟。

现在，带来第二部分的声明：我们是否应该设置Disk.SchedNumReqOutstanding的值和你们的队列深度一样么？OK，在这种情况中，你想你们的I/O过程尽可能快速，没有任何公平。但是，如果你在单个数据存储上有最小的工作负载，不想仅仅因为单个的虚拟机产生了过多的I/O，而招致你不想要的虚拟机过多延迟。

真的是这样吗？不，不完全是，有一些问题依然不能解答：

Disk.SchedNumReqOutstanding的场景中连续I/O会怎样？
VMkernel如何知道什么时候停止使用Disk.SchedNumReqOutstanding？

让我们先处理连续I/O的问题，默认情况下，VMkernel在队列中的虚拟机上产生8个连续的命令（由Disk.SchedQuantum控制），当它正常的从其它虚拟机上调用I/O看起来很公平，这样做是为了保护虚拟机工作负载的连续状态，I/O发生的扇区邻近之前被调用的I/O，它的顺序比I/O扇区快，—10X是不经常的，当包括缓存影响或者当缓存对比磁盘尺寸太小。但是，连续需要考虑哪些呢？如果下一次I/O比当前少于2000扇区，I/O考虑连续，这个距离在高级参数Disk.SectorMaxDiff中进行控制。

现在，如果其中一台虚拟机变成空闲状态，你将非常期望你的活动虚拟机去再次使用全队列深度，这是Disk.SchedQControlSeqReqs的作用。默认情况下，Disk.SchedQControlSeqReqs被设置为128，意味着当一台虚拟机已经产生了128条命令且没有任何交换，Disk.SchedQControlVMSwitches将再次将它重置为0，活动虚拟机能再次使用64的全队列深度。通过之前的例子，想法是这样的，如果VM-B产生了非常少的I/O（每128从其它虚拟机中少于1），此时我们将让VM-B付出高处罚的延迟，推测起来，它不是任何形式的磁盘绑定。

在我们继续之前，让我们确信清楚了这些混淆的概念，当SIOC开启，DSNRO将不适用，SIOC适用公平，它基于发生延迟而不是VM交换数量，换句话说，如果延迟阈值没有被超过，SIOC不会节流队列。

当SIOC启用，它将请求每设备最大的设备队列深度，并设置它们为最大，SIOC试图设置队列深度到256。在大多数的场景中，尽管它是设置成32，原因是大多数的维护人员使用了该默认值。这给我们带来一些设计原则。

基本设计原则

一旦SIOC在争用期间负责公平申请，确保你的阵列的可用性和咨询你的存储供应商，并在合适的事情请他们支持，设置队列深度最小为64

如果延迟阈值超过了（这个状态每4秒计算一次），SIOC基于他们的在阵列级别上I/O slot配额，动态节流主机的队列，注意当我们谈到延迟（等待时间），SIOC考虑设备延迟，设备延迟是从所有主机连接的数据存储上观测的平均延迟。

SIOC怎样确定每个虚拟机和最终每个主机的配额，PAPDA白皮书（讨论SIOC研发的学术文章）描述如下：

引用

资源分配通过份额值被指定，它是标记虚拟机消耗的I/O资源，一个虚拟机有权去消耗分配的存储阵列资源，它指定关联I/O请求对比其他虚拟机的重要性，I/O共享与主机的是一种简单的关系，每个虚拟机共享的全部数量统计为所有的虚拟机，合适的份额公平的被定义，提供存储阵列服务给适合他们份额的主机。

问题是，怎样让每个主机知道延迟被其它主机观察到？

通信原理

SIOC是用的原理类似于HA：数据存储上的一个共享文件夹，这个共享文件，iormstats.sf(图 110)，通过多个主机同步能够进入，每个主机定期的为数据存储上的文件，写入它的平均延迟和I/O数量，这些开启了所有主机读取该文件，计算数据存储的平均延迟，它改变为每个主机基于I/O slot配额，而是允许计算队列深度。

图110：通信原理

我们意识到这听起来十分复杂，所有我们尝试逻辑化，SIOC怎样工作在下面的部分中我们分场景进行描述。

本地磁盘调度

本地磁盘调度，一些时候被当做SFQ（start-time fair queuing）,它是负责一些事情，但是，正如它的名字所透露的，所有关联的主机的调度，除此之外标记每个虚拟机在资源争用时间公平的共享I/O资源，当IOPS限制被定义，本地磁盘调度还负责限制虚拟机。

本地磁盘调度影响主机级别的优先级，针对同一个ESXi主机所有运行的虚拟机，通过本身，当一定数量的虚拟机需要比其它虚拟机高一些优先级，它有比较大的价值，但它同时也威胁到虚拟机的平等，当3个虚拟机拥有平等的份额，接下来的图表描述了这个场景，但VM1和VM2收到较少的带宽，因为它们运行不同的主机上。

图111：本地磁盘调度

Datastore-Wide磁盘调度

Datastore-wide磁盘调度有点类似于本地磁盘调度，它将虚拟机的调度优先于其它依靠自身磁盘的调度，它通过计算I/O slot 权限，但只当配置的延迟阈值被超过时。

一个例子将可能描述它是怎样工作的，接下来的图片（图112）描述了延迟阈值被超过，主机被节流的场景。

图112：Datastore-wide 磁盘调度

Datastore-Wide磁盘调度为数据存储上虚拟机的每个VMDK文件统计磁盘份额，在ESXi-01的情况中，它是2000，在ESXi-02的情况中是1000，接下来，datastore-wide磁盘调度将基于主机级别的共享计算I/O slot配置，它将节流队列。在这个例子中，每一个虚拟机被分配了33%的存储资源，如果你同图111的场景进行比较，你能理解为什么建议在所有的数据存储上开启SIOC，即使不需要提高优先级。

基本设计原则

即使虚拟机不需要比其它虚拟机更高的优先级，开启存储I/O控制是有利的，它能帮助阻止自身造成的拒绝服务攻击。

另外一个例子

所有的虚拟机有平等的份额，这个例子比较公平，但是，不同份额的场景，将使其变得复杂，我们像提供额外的例子来确保每个人理解这个基本的概念，在这个场景中，有3个虚拟机（图113），2个虚拟机（VM2和VM3）被授予了500份额，VM1有1500份额，VM1被分配了60%的可用I/O slot，VM2和VM3每个被分配了20%，通过加上所有的份额这个计算比较简单，通过结果可以区分每虚拟机的份额，在VM1的情况下，计算公式如下：

VM1 / (VM1+VM2+VM3)

或者

1500/(1500+500+500)=60%

如展示的，VM1被分配了60%的I/O slot ，VM2和VM3被分配了20%

图113：SIOC 场景2

自动延迟阈值计算

在vSphere 5.0中延迟阈值是指定用户设置的，默认是30毫秒，但是这个时间不适合所有的数据存储类型，因为SIOC支持多种类型的设备，一个中间的阈值被设置，某些设备如SSD命中自然争用点早于其它，它请求用户在指定的数据存储上配置较低的阈值。但是，手工决定正确的阈值非常困难，为了阻止错误的延迟阈值设置，SIOC在vSphere 5.1中自动为每个设备决定了延迟阈值。

自动延迟阈值计算模拟设备的吞吐量，设置延迟记录，允许虚拟架构调用有利于设备的全部性能，用户接口提供控制依据峰值的IOPS的百分比来影响自动计算；用户接口还提供手动设置延迟的机会。

图114：配置存储I/O控制

手工延迟阈值建议

在vSphere 5.1中提供新的自动阈值设置，如果有可能的场合，必须要手工设置阈值，它产生的建议为不同类型的磁盘来设置不同的阈值（见表25）

它应该指出，但是，当SIOC用来配合存储DRS，存储DRS I/O延迟阈值应该设置得比SIOC延迟阈值低，通过节流队列深度，SIOC被定位用来阻止短暂的延迟高峰，存储DRS被定位用来解决失衡和通过迁移工作负载降低数据存储的平均延迟。SIOC观察设备延迟，存储DRS观察全部的延迟，包括设备延迟和kernel延迟。这意味着，当SIOC延迟阈值低于存储DRS I/O延迟，它将不会对存储DRS的建议产生影响，因为存储DRS考虑设备延迟和kernel延迟，通过本章节解释的Datastore-wide 磁盘调度，延迟不会被消失，它移动到一个不同的层，我们做到了，但是，建议设置存储DRS I/O延迟值为SIOC的一半，这样SIOC将迁移延迟峰值和存储DRS将阻止热点。

表25：建议延迟阈值

注入

另一个我们没有接触的组件是注入，它是做什么的？它为谁提供服务？注入在vSphere 5.0中被介绍过，它是SIOC的一部分来决定数据存储的性能特性，我们已经在第22章节简明的接触了性能特性，基于可用性和类似性能来对数据存储群集上聚合的数据存储生成建议，在大多数的环境中，管理员小心的定义它们的存储的层次，但大多数不能意识到，每个数据存储上的备份磁盘的数量不同，会造成性能行为上的不同，即使磁盘数量（7 VS 9）有一点点不同，可能引起性能上非常大的不同。总而言之，一些阵列使用大磁盘池和条带LUN通过这些池，在那些场景中，本地磁盘可能产生不同的性能特性，尽管VASA曝光了类似于RAID的一些存储特性，但它当前还是不能提供性能特性。

为了确保存储DRS I/O平衡放置，不仅仅是基于阈值和延迟观察，SIOC还通过注入随机I/O描绘数据存储的特性，在大家担心注入会干涉他们的工作负载之前，我们想强调的是注入只有当数据存储处于空闲状态时才变成活动的，如果I/O被检测到来自于其它资源，注入将停止描述特性，并稍后重试，总之，注入I/O只是读I/O，为了描述设备的特性，不同数量的I/O被使用，延迟被监控，换句话说，随机读I/O被注入，每次I/O的数量也不同。图115中结果可以简单的描绘，图的斜坡表明了数据存储的性能。

引用

“在数学中，斜坡或者梯度线描述陡峭，倾斜和等级，较高的斜坡值表面更陡峭的斜坡。

图115：使用不同数量的磁盘进行设备建模