云计算不仅仅代表着近乎无限的资源，我们也需要了解其中可能存在的种种性能问题。
以Amazon AWS与微软Azure为代表的公有云服务属于基于控制台的编排方案，它们能够帮助用户运转并管理必需的基础设施。此外，它们还提供大量功能与插件，从而构建起各类极具吸引力的最终解决方案。
在多数情况下，由于拥有强大的可扩展能力，这些云方案似乎能够提供无穷无尽的计算资源，我们几乎永远不可能触及其性能瓶颈。
然而作为用户时常面对的性能问题之一，磁盘或者说存储性能始终困扰着我们每位云服务支持者。
经过一系列测试，AWS以及Azure都能够在低延迟状态下提供数千IOPS以及数百MBps磁盘传输能力。由此看来，此类环境应该能够成为运行要求高IOPS、高数据传输能力以及低延迟水平的高性能虚拟服务器——例如SQL服务器——的最佳平台才对。
存储故事：容量与IO，一对“欢喜冤家”
在说起存储方案时，IO性能总是先于存储容量被工作负载所耗尽。从商业角度来看，这无疑是一种严重的资源浪费。由于云环境需要由控制台提供自动化管理能力，并根据客户意愿为其提供对应的资源配置，这意味着整套环境在缺少规则与上限作为约束的情况之下，将遭遇到显著的性能下降——而云服务供应商则必须想尽办法在不增加多余容量的同时实现IO交付。
也就是说，对IOPS或者数据吞吐能力的渴求最终会将现有存储方案榨干。如果存储体系采用基于网络的非本地设计，那么其数据吞吐过程还会严重影响到网络交换机的性能。在这种情况下，云服务供应商必须使用速度更快且配备更大缓存容量的交换机设备，从而实现吞吐能力提升并应对突如其来的峰值状况。
我们到底能够在Amazon及Azure等主流云方案中前进至怎样的纵深位置?
以Azure为例，其官方说明文档当中给出以下说明：
在Premium Storage的帮助下，您的应用程序可以拥有最高每虚拟机64 TB存储容量并实现80000 IOPS(即每秒输入/输出操作)，外加每虚拟机每秒2000 MB磁盘吞吐速率，且配合极低的读取操作延迟水平。
这意味着，接入该虚拟机的一块P10 Premium Storage只能够实现最多每秒32 MB的数据传输能力，而达不到P10磁盘本身的每秒100 MB传输速率上限。同样的，一套STANDARD_DS13虚拟机在立足于全部磁盘之上时能够实现最高每秒256 MB传输能力。目前，DS系列之上规模最大的虚拟机为STANDARD_DS14，其可以让全部磁盘提供最高每秒512 MB的传输水平。而GS系列之上的最大规模虚拟机为STANDARD_GS5，其全磁盘最高数据传输能力为每秒2000 MB。
缓存命中机制则不会受到所分配磁盘之IOPS/数据吞吐能力的限制。缓存方案的作用在于，当我们使用数据磁盘并同时在一套DS系列虚拟机或者GS系列虚拟机当中进行只读缓存设置时，读取操作将由该缓存负责实现，而不再受到Premium Storage磁盘自身性能的影响。在这种情况下，只要对应工作负载以读取为主，那么我们就能够在缓存的帮助下通过一块磁盘获得极高数据吞吐能力。不过需要强调的是，缓存本身亦会受到虚拟机层面上IOPS/数据吞吐能力的限制，也就是取决于虚拟机大小。系列虚拟机的IOPS在4000左右，而每个面向缓存与本地SSD IO的计算核心能够实现每秒33 MB数据传输速率。
因此，Azure其实是将IO限制与磁盘容量结合了起来，同时将虚拟机大小因素纳入其中(例如每计算核心缓存命中次数)。
如果大家继续阅读这份说明文档，就会发现每块独立磁盘的性能其实还要更低，特别在磁盘容量较小的情况下，这是因为即使是高性能SSD也面临着吞吐能力限制。这就让问题变得更加复杂，特别是在大家优先将自己的应用程序启动并运行在云环境当中时。
举例来说，一块存储容量为100 GiB的磁盘会被分类为一个P10选项，并能够实现每秒500次IO操作以及最高每秒100 MB数据吞吐能力。同样的，一块容量为400 GiB的磁盘则会被分类为一个P20选项，其每秒能够执行2300次IO操作并提供每秒150 MB数据吞吐能力。
输入/输出(简称I/O)的单位大小为256 KB。如果该数据以小于256 KB的大小进行传输，则仍然会被视为一个单独的I/O单元。如果I/O大小超出此范围，则会被作为多个256 KB I/O单元进行处理。举例来说，1100 KB I/O会被计为五个I/O单元。
Azure采用256 KB块大小来定义IOPS，这更适合处理那些体积较大的块IO。因此如果大家的SQL采用64 KB块IO，则应当就IOPS进行大小限定。
AWS又如何?
Amazon所采取的方法与之类似，通过相当说明文档，可以看到Amazon似乎更倾向于将性能与存储空间相结合，且实际效果要优于Azure。
在通用型SSD分卷中，在总体分卷容量总值小于等于170 GiB时，每个分卷的最大数据吞吐能力为每秒128 MiB。而对于分卷总体容量高于170 GiB的情况，这一上限则由每GiB每秒768 MiB提升至每秒160 MiB(在总体容量大于等于214 GiB的情况下)。
针对IPOS进行过配置的SSD分卷在存储容量方面处于4 Gib到16 TiB区间，大家可以将每个分卷的IOPS上限设定为20000。其中IOPS配置与分卷容量之间的比值最大可为30; 举例来讲，一个IOPS为3000的分卷，其最低存储容量需要为100 GiB。
在各类EBS存储分卷当中，磁性存储分卷拥有最低的每GB使用成本，而且这些分卷的平均IOPS大约在100左右，峰值IOPS则可达到数百。另外，其存储容量区间在1 Gib到1 TiB之间。
大家可以将多个分卷绑定为同一RAID配置，从而实现更大的容量总值并获得更出色的性能表现。
针对IOPS进行配置的SSD分卷对于每IOPS的数据传输速率有着明确限制，最低为256 KiB，最高则可为每秒320 MiB(在1280 IOPS情况下)。
因此在使用Amazon云时，大家往往能够在同样的磁盘容量规格基础上获得更出色的性能表现。
在配置存储容量较低且虚拟机规格较差的情况下，客户要如何获得更高IO?
我们的云服务同样拥有标准上限。举例来说，常规VPS中每100 GB磁盘的IPOS软上限为1000或者2000。IO限制同时也取决于计算核心数量以及虚拟内存分配量。
我们与客户进行协作，旨在帮助他们配置自己的虚拟服务器与应用程序，并借此获得理想的性能水平。我们的目标是为客户提供最理想的使用体验及服务，从而在长远角度留住客户并帮助其实现业务增长。
下面让我们具体看看。
这里我们假设配置有两套不同的中端性能八计算核心/12 GB内存SQL虚拟服务器，每一套都配备相对较小的数据存储磁盘——空间约在300 GB左右。这些SQL服务器难于读取，而且在64 k块IO条件下存在严重的IO吞吐能力不足问题。二者在配置上完全相同，但具体面对的需求却存在差异——其一数据吞吐能力不足，其二IOPS不足。
这意味着两套虚拟机都受到了限制。
不过在这种情况下，我们可以想办法同客户合作，从而确保其虚拟机不会遭遇瓶颈亦不至由于过度配置而超出既有预算。我们不考虑特殊情况下的流量峰值，并认为两套虚拟机有能力最大程度发挥其配置上限。
另外，这种上限是全局性的，因此具备可预测性; 当客户处理随机IO时，无需相关应用的配合即可确定其上限处于同样的水平。类似的状况在Azure中也存在，其中缓存命中机制所能实现的性能上限要高于由磁盘实现的IO操作。
我们还会对客户的IO块大小模式进行分析，并以此为基础设定IOPS上限——而非一股脑为全部VPS都设定同样的IO块大小。
关于这两套虚拟机，最有趣的一点是其IOPS并不是很高，真正被全部占用的其实是其数据吞吐能力，而且二者都会积极耗尽这项资源。此类虚拟机在服务供应商眼中通常是麻烦的根源，因为它们会相安无事SAN与网络传输能力，特别是在面对随机与高吞吐率IO峰值时。
MSSQL 1
MSSQL 2
我们可以将以上图表理解为：
这套网络的速度水平足以应对峰值情况。Webhosting.net利用Arista深层缓冲交换机以及Arista EOS平台的各种技术优势：
◆在40G与100G核心网络领域处于绝对的领先地位
◆拥有12.2%的核心数据中心交换与增长市场份额
◆最为稳定及灵活的网络操作系统，已经接受超过15年的实践检验
◆单一二进制镜像运行在整体交换机组合当中
◆能够根据客户自己的节奏逐步更新至SDN
◆能够在现代云网络当中以自动化方式降低总体持有成本与总体运营成本
◆Arista的EOS基于非专有开放标准
◆为数据中心网络带来可扩展能力，从而重新定义网络架构
◆显著提升性价比水平
◆VMware公司头号合作伙伴，Arista充当VMware vAirCloud平台的底层方案
我们通过引入由PernixData FVP软件实现的本地存储加速成效以保护SAN与整体网络。FVP能够处理本地SSD当中的存储内容读取与写入操作。这使得我们能够轻松向现有ESXi主机添加更多SSD，从而直接实现性能的向外扩展。它还能够从网络及SAN当中卸载I/O负载(详见下图)。
FVP还能够最大程度降低延迟水平。通过以本地方式处理存储读取与写入操作，我们得以显著削减延迟水平，从而提升虚拟机性能表现。举例来说，在我们的自有集群当中，Pernix帮助SAN与网络节约下相当一部分资源。
因此我们所做的基本上就是在原本所需的存储空间使用量之下，为客户提供必要的性能提升，而无需强迫他们使用X存储容量以实现Y IO，或者使用昂贵的SSD、特定数量的计算核心乃至内存。客户无需自行探究实际IO模式并据此进行计算，我们会代替其完成全部工作，包括审视应用程序性能以及后端延迟。
而着眼于Amazon与Azure：
在使用Amazon的情况下，客户可以运行虚拟机，但只能够以IOPS配置SSD分卷上实现。而我们之前没有强调的是，此类不设上限的虚拟机每300 GB磁盘空间能够提供450 MBps数据吞吐能力。相比之下，Amazon同等磁盘容量所能实现的数据吞吐速率为320 MBps。
而在使用Azure的情况下，尽管随机IO将由缓存机制而非磁盘所承担，并借此绕过磁盘容量与IO限制，但此类虚拟机并不能完全发挥由缓存实现的全部IO性能(值得强调的是，Azure读取操作由缓存实现而不涉及Premium Storage磁盘，因此其上限要更高一些; 不过最终当客户进行随机IO操作时，其仍然需要面对上限较低的普通磁盘)。
客户可能并不具备必要的技能、专业知识、动力或者时间来自行完成对不同云服务供应商及具体方案之间细微差别的研究与核算——毕竟作为客户，核心目标应该仅仅是让自己的应用程序运行在最具成本效益的环境当中。
实时增加资源
相较于物理部署型方案，云服务的一大关键性优势就是能够实时添加额外资源，例如增加CPU计算核心数量、内存容量乃至磁盘存储空间等等。
举例来说，当应用程序开始将负载交付至CPU时，后者需要立即使用额外计算核心。而如果操作系统本身支持多核心运行——目前多数操作系统都具备这种支持能力——webhosting.net会自动完成核心、内存或者磁盘存储空间添加工作，而无需进行任何中断或者重启，这就显著改善了应用程序正常运行时间并避免了停机事件的出现。
不过根据官方网站的说法，目前Azure尚没有亦无计划提供CPU或内存资源的实时添加功能。
另外，我们也可以通过实时方式将虚拟机迁移到速度更出色的资源之上。
一点额外服务
有一天，某位客户突然打电话来，说由于种种原因他的重要文件遭遇丢失，要么就是他的VPS出现问题而必须进行整体恢复。
在各类云服务协议当中，客户需要自行承担备份工作。不过有时候，他们可能根本没有采取备份方案或者其备份内容已经遭到入侵。
除了帮助这位客户备份其应用程序及虚拟服务器之外，我们还可以为其提供一点额外服务。我们可以利用自己的快照备份帮助其实现文件恢复，这一切都可以通过我们的备份恢复点实现，即使该客户并没有认购备份服务。很多时候，我们还需要偶尔帮客户恢复那些被意外删除的文件或者误以为没用而被删除的存在备份数据的虚拟服务器。
还记得Cloud Space披露的，某位攻击者控制其Amazon账户并将包括备份信息在内的全部数据删除一空的案例。在这种情况下，我们能够在短短几分钟之间就对几乎全部数据进行恢复——根据我们自己的备份内容。
总结来讲，我们需要量身定作自己的云解决方案
通过将VMware、高性能存储以及低延迟网络外加Pernix加速机制相结合，Webhosting.net的VMware云方案能够切实提供可观的IO性能、通过本地主机SSD提供存储服务并显著提升单位容量所能实现的IO上限。
结果就是，如果有必要，我们完全可以通过规模更小的虚拟机在无需迫使客户为过度配置的虚拟服务器付费的前提下，显著提高IO性能与数据吞吐能力。
总结陈词——每一套云解决方案都有自己的局限性，因此适合自己的才是最好的。
本文转自d1net（转载）
