【51CTO.com快譯】云計(jì)算不僅僅代表著近乎無(wú)限的資源，我們也需要了解其中可能存在的種種性能問(wèn)題。

以Amazon AWS與微軟Azure為代表的公有云服務(wù)屬于基于控制臺(tái)的編排方案，它們能夠幫助用戶(hù)運(yùn)轉(zhuǎn)并管理必需的基礎(chǔ)設(shè)施。此外，它們還提供大量功能與插件，從而構(gòu)建起各類(lèi)極具吸引力的最終解決方案。

在多數(shù)情況下，由于擁有強(qiáng)大的可擴(kuò)展能力，這些云方案似乎能夠提供無(wú)窮無(wú)盡的計(jì)算資源，我們幾乎永遠(yuǎn)不可能觸及其性能瓶頸。

然而作為用戶(hù)時(shí)常面對(duì)的性能問(wèn)題之一，磁盤(pán)或者說(shuō)存儲(chǔ)性能始終困擾著我們每位云服務(wù)支持者。

經(jīng)過(guò)一系列測(cè)試，AWS以及Azure都能夠在低延遲狀態(tài)下提供數(shù)千IOPS以及數(shù)百M(fèi)Bps磁盤(pán)傳輸能力。由此看來(lái)，此類(lèi)環(huán)境應(yīng)該能夠成為運(yùn)行要求高IOPS、高數(shù)據(jù)傳輸能力以及低延遲水平的高性能虛擬服務(wù)器——例如SQL服務(wù)器——的最佳平臺(tái)才對(duì)。

存儲(chǔ)故事：容量與IO，一對(duì)“歡喜冤家”

在說(shuō)起存儲(chǔ)方案時(shí)，IO性能總是先于存儲(chǔ)容量被工作負(fù)載所耗盡。從商業(yè)角度來(lái)看，這無(wú)疑是一種嚴(yán)重的資源浪費(fèi)。由于云環(huán)境需要由控制臺(tái)提供自動(dòng)化管理能力，并根據(jù)客戶(hù)意愿為其提供對(duì)應(yīng)的資源配置，這意味著整套環(huán)境在缺少規(guī)則與上限作為約束的情況之下，將遭遇到顯著的性能下降——而云服務(wù)供應(yīng)商則必須想盡辦法在不增加多余容量的同時(shí)實(shí)現(xiàn)IO交付。

也就是說(shuō)，對(duì)IOPS或者數(shù)據(jù)吞吐能力的渴求最終會(huì)將現(xiàn)有存儲(chǔ)方案榨干。如果存儲(chǔ)體系采用基于網(wǎng)絡(luò)的非本地設(shè)計(jì)，那么其數(shù)據(jù)吞吐過(guò)程還會(huì)嚴(yán)重影響到網(wǎng)絡(luò)交換機(jī)的性能。在這種情況下，云服務(wù)供應(yīng)商必須使用速度更快且配備更大緩存容量的交換機(jī)設(shè)備，從而實(shí)現(xiàn)吞吐能力提升并應(yīng)對(duì)突如其來(lái)的峰值狀況。

我們到底能夠在Amazon及Azure等主流云方案中前進(jìn)至怎樣的縱深位置?

以Azure為例，其官方說(shuō)明文檔當(dāng)中給出以下說(shuō)明：

在Premium Storage的幫助下，您的應(yīng)用程序可以擁有最高每虛擬機(jī)64 TB存儲(chǔ)容量并實(shí)現(xiàn)80000 IOPS(即每秒輸入/輸出操作)，外加每虛擬機(jī)每秒2000 MB磁盤(pán)吞吐速率，且配合極低的讀取操作延遲水平。

這意味著，接入該虛擬機(jī)的一塊P10 Premium Storage只能夠?qū)崿F(xiàn)最多每秒32 MB的數(shù)據(jù)傳輸能力，而達(dá)不到P10磁盤(pán)本身的每秒100 MB傳輸速率上限。同樣的，一套STANDARD_DS13虛擬機(jī)在立足于全部磁盤(pán)之上時(shí)能夠?qū)崿F(xiàn)最高每秒256 MB傳輸能力。目前，DS系列之上規(guī)模最大的虛擬機(jī)為STANDARD_DS14，其可以讓全部磁盤(pán)提供最高每秒512 MB的傳輸水平。而GS系列之上的最大規(guī)模虛擬機(jī)為STANDARD_GS5，其全磁盤(pán)最高數(shù)據(jù)傳輸能力為每秒2000 MB。

緩存命中機(jī)制則不會(huì)受到所分配磁盤(pán)之IOPS/數(shù)據(jù)吞吐能力的限制。緩存方案的作用在于，當(dāng)我們使用數(shù)據(jù)磁盤(pán)并同時(shí)在一套DS系列虛擬機(jī)或者GS系列虛擬機(jī)當(dāng)中進(jìn)行只讀緩存設(shè)置時(shí)，讀取操作將由該緩存負(fù)責(zé)實(shí)現(xiàn)，而不再受到Premium Storage磁盤(pán)自身性能的影響。在這種情況下，只要對(duì)應(yīng)工作負(fù)載以讀取為主，那么我們就能夠在緩存的幫助下通過(guò)一塊磁盤(pán)獲得極高數(shù)據(jù)吞吐能力。不過(guò)需要強(qiáng)調(diào)的是，緩存本身亦會(huì)受到虛擬機(jī)層面上IOPS/數(shù)據(jù)吞吐能力的限制，也就是取決于虛擬機(jī)大小。系列虛擬機(jī)的IOPS在4000左右，而每個(gè)面向緩存與本地SSD IO的計(jì)算核心能夠?qū)崿F(xiàn)每秒33 MB數(shù)據(jù)傳輸速率。

因此，Azure其實(shí)是將IO限制與磁盤(pán)容量結(jié)合了起來(lái)，同時(shí)將虛擬機(jī)大小因素納入其中(例如每計(jì)算核心緩存命中次數(shù))。

如果大家繼續(xù)閱讀這份說(shuō)明文檔，就會(huì)發(fā)現(xiàn)每塊獨(dú)立磁盤(pán)的性能其實(shí)還要更低，特別在磁盤(pán)容量較小的情況下，這是因?yàn)榧词故歉咝阅躍SD也面臨著吞吐能力限制。這就讓問(wèn)題變得更加復(fù)雜，特別是在大家優(yōu)先將自己的應(yīng)用程序啟動(dòng)并運(yùn)行在云環(huán)境當(dāng)中時(shí)。

舉例來(lái)說(shuō)，一塊存儲(chǔ)容量為100 GiB的磁盤(pán)會(huì)被分類(lèi)為一個(gè)P10選項(xiàng)，并能夠?qū)崿F(xiàn)每秒500次IO操作以及最高每秒100 MB數(shù)據(jù)吞吐能力。同樣的，一塊容量為400 GiB的磁盤(pán)則會(huì)被分類(lèi)為一個(gè)P20選項(xiàng)，其每秒能夠執(zhí)行2300次IO操作并提供每秒150 MB數(shù)據(jù)吞吐能力。

輸入/輸出(簡(jiǎn)稱(chēng)I/O)的單位大小為256 KB。如果該數(shù)據(jù)以小于256 KB的大小進(jìn)行傳輸，則仍然會(huì)被視為一個(gè)單獨(dú)的I/O單元。如果I/O大小超出此范圍，則會(huì)被作為多個(gè)256 KB I/O單元進(jìn)行處理。舉例來(lái)說(shuō)，1100 KB I/O會(huì)被計(jì)為五個(gè)I/O單元。

Azure采用256 KB塊大小來(lái)定義IOPS，這更適合處理那些體積較大的塊IO。因此如果大家的SQL采用64 KB塊IO，則應(yīng)當(dāng)就IOPS進(jìn)行大小限定。

AWS又如何?

Amazon所采取的方法與之類(lèi)似，通過(guò)相當(dāng)說(shuō)明文檔，可以看到Amazon似乎更傾向于將性能與存儲(chǔ)空間相結(jié)合，且實(shí)際效果要優(yōu)于Azure。

在通用型SSD分卷中，在總體分卷容量總值小于等于170 GiB時(shí)，每個(gè)分卷的最大數(shù)據(jù)吞吐能力為每秒128 MiB。而對(duì)于分卷總體容量高于170 GiB的情況，這一上限則由每GiB每秒768 MiB提升至每秒160 MiB(在總體容量大于等于214 GiB的情況下)。

針對(duì)IPOS進(jìn)行過(guò)配置的SSD分卷在存儲(chǔ)容量方面處于4 Gib到16 TiB區(qū)間，大家可以將每個(gè)分卷的IOPS上限設(shè)定為20000。其中IOPS配置與分卷容量之間的比值最大可為30; 舉例來(lái)講，一個(gè)IOPS為3000的分卷，其最低存儲(chǔ)容量需要為100 GiB。

在各類(lèi)EBS存儲(chǔ)分卷當(dāng)中，磁性存儲(chǔ)分卷?yè)碛凶畹偷拿縂B使用成本，而且這些分卷的平均IOPS大約在100左右，峰值IOPS則可達(dá)到數(shù)百。另外，其存儲(chǔ)容量區(qū)間在1 Gib到1 TiB之間。

大家可以將多個(gè)分卷綁定為同一RAID配置，從而實(shí)現(xiàn)更大的容量總值并獲得更出色的性能表現(xiàn)。

針對(duì)IOPS進(jìn)行配置的SSD分卷對(duì)于每IOPS的數(shù)據(jù)傳輸速率有著明確限制，最低為256 KiB，最高則可為每秒320 MiB(在1280 IOPS情況下)。

因此在使用Amazon云時(shí)，大家往往能夠在同樣的磁盤(pán)容量規(guī)格基礎(chǔ)上獲得更出色的性能表現(xiàn)。

在配置存儲(chǔ)容量較低且虛擬機(jī)規(guī)格較差的情況下，客戶(hù)要如何獲得更高IO?

我們的云服務(wù)同樣擁有標(biāo)準(zhǔn)上限。舉例來(lái)說(shuō)，常規(guī)VPS中每100 GB磁盤(pán)的IPOS軟上限為1000或者2000。IO限制同時(shí)也取決于計(jì)算核心數(shù)量以及虛擬內(nèi)存分配量。

我們與客戶(hù)進(jìn)行協(xié)作，旨在幫助他們配置自己的虛擬服務(wù)器與應(yīng)用程序，并借此獲得理想的性能水平。我們的目標(biāo)是為客戶(hù)提供最理想的使用體驗(yàn)及服務(wù)，從而在長(zhǎng)遠(yuǎn)角度留住客戶(hù)并幫助其實(shí)現(xiàn)業(yè)務(wù)增長(zhǎng)。

下面讓我們具體看看。

這里我們假設(shè)配置有兩套不同的中端性能八計(jì)算核心/12 GB內(nèi)存SQL虛擬服務(wù)器，每一套都配備相對(duì)較小的數(shù)據(jù)存儲(chǔ)磁盤(pán)——空間約在300 GB左右。這些SQL服務(wù)器難于讀取，而且在64 k塊IO條件下存在嚴(yán)重的IO吞吐能力不足問(wèn)題。二者在配置上完全相同，但具體面對(duì)的需求卻存在差異——其一數(shù)據(jù)吞吐能力不足，其二IOPS不足。

這意味著兩套虛擬機(jī)都受到了限制。

不過(guò)在這種情況下，我們可以想辦法同客戶(hù)合作，從而確保其虛擬機(jī)不會(huì)遭遇瓶頸亦不至由于過(guò)度配置而超出既有預(yù)算。我們不考慮特殊情況下的流量峰值，并認(rèn)為兩套虛擬機(jī)有能力最大程度發(fā)揮其配置上限。

另外，這種上限是全局性的，因此具備可預(yù)測(cè)性; 當(dāng)客戶(hù)處理隨機(jī)IO時(shí)，無(wú)需相關(guān)應(yīng)用的配合即可確定其上限處于同樣的水平。類(lèi)似的狀況在Azure中也存在，其中緩存命中機(jī)制所能實(shí)現(xiàn)的性能上限要高于由磁盤(pán)實(shí)現(xiàn)的IO操作。

我們還會(huì)對(duì)客戶(hù)的IO塊大小模式進(jìn)行分析，并以此為基礎(chǔ)設(shè)定IOPS上限——而非一股腦為全部VPS都設(shè)定同樣的IO塊大小。

關(guān)于這兩套虛擬機(jī)，最有趣的一點(diǎn)是其IOPS并不是很高，真正被全部占用的其實(shí)是其數(shù)據(jù)吞吐能力，而且二者都會(huì)積極耗盡這項(xiàng)資源。此類(lèi)虛擬機(jī)在服務(wù)供應(yīng)商眼中通常是麻煩的根源，因?yàn)樗鼈儠?huì)相安無(wú)事SAN與網(wǎng)絡(luò)傳輸能力，特別是在面對(duì)隨機(jī)與高吞吐率IO峰值時(shí)。

MSSQL 1

MSSQL 2

我們可以將以上圖表理解為：

這套網(wǎng)絡(luò)的速度水平足以應(yīng)對(duì)峰值情況。Webhosting.net利用Arista深層緩沖交換機(jī)以及Arista EOS平臺(tái)的各種技術(shù)優(yōu)勢(shì)：

◆在40G與100G核心網(wǎng)絡(luò)領(lǐng)域處于絕對(duì)的領(lǐng)先地位

◆擁有12.2%的核心數(shù)據(jù)中心交換與增長(zhǎng)市場(chǎng)份額

◆最為穩(wěn)定及靈活的網(wǎng)絡(luò)操作系統(tǒng)，已經(jīng)接受超過(guò)15年的實(shí)踐檢驗(yàn)

◆單一二進(jìn)制鏡像運(yùn)行在整體交換機(jī)組合當(dāng)中

◆能夠根據(jù)客戶(hù)自己的節(jié)奏逐步更新至SDN

◆能夠在現(xiàn)代云網(wǎng)絡(luò)當(dāng)中以自動(dòng)化方式降低總體持有成本與總體運(yùn)營(yíng)成本

◆Arista的EOS基于非專(zhuān)有開(kāi)放標(biāo)準(zhǔn)

◆為數(shù)據(jù)中心網(wǎng)絡(luò)帶來(lái)可擴(kuò)展能力，從而重新定義網(wǎng)絡(luò)架構(gòu)

◆顯著提升性?xún)r(jià)比水平

◆VMware公司頭號(hào)合作伙伴，Arista充當(dāng)VMware vAirCloud平臺(tái)的底層方案

我們通過(guò)引入由PernixData FVP軟件實(shí)現(xiàn)的本地存儲(chǔ)加速成效以保護(hù)SAN與整體網(wǎng)絡(luò)。FVP能夠處理本地SSD當(dāng)中的存儲(chǔ)內(nèi)容讀取與寫(xiě)入操作。這使得我們能夠輕松向現(xiàn)有ESXi主機(jī)添加更多SSD，從而直接實(shí)現(xiàn)性能的向外擴(kuò)展。它還能夠從網(wǎng)絡(luò)及SAN當(dāng)中卸載I/O負(fù)載(詳見(jiàn)下圖)。

FVP還能夠最大程度降低延遲水平。通過(guò)以本地方式處理存儲(chǔ)讀取與寫(xiě)入操作，我們得以顯著削減延遲水平，從而提升虛擬機(jī)性能表現(xiàn)。舉例來(lái)說(shuō)，在我們的自有集群當(dāng)中，Pernix幫助SAN與網(wǎng)絡(luò)節(jié)約下相當(dāng)一部分資源。

因此我們所做的基本上就是在原本所需的存儲(chǔ)空間使用量之下，為客戶(hù)提供必要的性能提升，而無(wú)需強(qiáng)迫他們使用X存儲(chǔ)容量以實(shí)現(xiàn)Y IO，或者使用昂貴的SSD、特定數(shù)量的計(jì)算核心乃至內(nèi)存?？蛻?hù)無(wú)需自行探究實(shí)際IO模式并據(jù)此進(jìn)行計(jì)算，我們會(huì)代替其完成全部工作，包括審視應(yīng)用程序性能以及后端延遲。

而著眼于Amazon與Azure：

在使用Amazon的情況下，客戶(hù)可以運(yùn)行虛擬機(jī)，但只能夠以IOPS配置SSD分卷上實(shí)現(xiàn)。而我們之前沒(méi)有強(qiáng)調(diào)的是，此類(lèi)不設(shè)上限的虛擬機(jī)每300 GB磁盤(pán)空間能夠提供450 MBps數(shù)據(jù)吞吐能力。相比之下，Amazon同等磁盤(pán)容量所能實(shí)現(xiàn)的數(shù)據(jù)吞吐速率為320 MBps。

而在使用Azure的情況下，盡管隨機(jī)IO將由緩存機(jī)制而非磁盤(pán)所承擔(dān)，并借此繞過(guò)磁盤(pán)容量與IO限制，但此類(lèi)虛擬機(jī)并不能完全發(fā)揮由緩存實(shí)現(xiàn)的全部IO性能(值得強(qiáng)調(diào)的是，Azure讀取操作由緩存實(shí)現(xiàn)而不涉及Premium Storage磁盤(pán)，因此其上限要更高一些; 不過(guò)最終當(dāng)客戶(hù)進(jìn)行隨機(jī)IO操作時(shí)，其仍然需要面對(duì)上限較低的普通磁盤(pán))。

客戶(hù)可能并不具備必要的技能、專(zhuān)業(yè)知識(shí)、動(dòng)力或者時(shí)間來(lái)自行完成對(duì)不同云服務(wù)供應(yīng)商及具體方案之間細(xì)微差別的研究與核算——畢竟作為客戶(hù)，核心目標(biāo)應(yīng)該僅僅是讓自己的應(yīng)用程序運(yùn)行在最具成本效益的環(huán)境當(dāng)中。

實(shí)時(shí)增加資源

相較于物理部署型方案，云服務(wù)的一大關(guān)鍵性?xún)?yōu)勢(shì)就是能夠?qū)崟r(shí)添加額外資源，例如增加CPU計(jì)算核心數(shù)量、內(nèi)存容量乃至磁盤(pán)存儲(chǔ)空間等等。

舉例來(lái)說(shuō)，當(dāng)應(yīng)用程序開(kāi)始將負(fù)載交付至CPU時(shí)，后者需要立即使用額外計(jì)算核心。而如果操作系統(tǒng)本身支持多核心運(yùn)行——目前多數(shù)操作系統(tǒng)都具備這種支持能力——webhosting.net會(huì)自動(dòng)完成核心、內(nèi)存或者磁盤(pán)存儲(chǔ)空間添加工作，而無(wú)需進(jìn)行任何中斷或者重啟，這就顯著改善了應(yīng)用程序正常運(yùn)行時(shí)間并避免了停機(jī)事件的出現(xiàn)。

不過(guò)根據(jù)官方網(wǎng)站的說(shuō)法，目前Azure尚沒(méi)有亦無(wú)計(jì)劃提供CPU或內(nèi)存資源的實(shí)時(shí)添加功能。

另外，我們也可以通過(guò)實(shí)時(shí)方式將虛擬機(jī)遷移到速度更出色的資源之上。

一點(diǎn)額外服務(wù)

有一天，某位客戶(hù)突然打電話來(lái)，說(shuō)由于種種原因他的重要文件遭遇丟失，要么就是他的VPS出現(xiàn)問(wèn)題而必須進(jìn)行整體恢復(fù)。

在各類(lèi)云服務(wù)協(xié)議當(dāng)中，客戶(hù)需要自行承擔(dān)備份工作。不過(guò)有時(shí)候，他們可能根本沒(méi)有采取備份方案或者其備份內(nèi)容已經(jīng)遭到入侵。

除了幫助這位客戶(hù)備份其應(yīng)用程序及虛擬服務(wù)器之外，我們還可以為其提供一點(diǎn)額外服務(wù)。我們可以利用自己的快照備份幫助其實(shí)現(xiàn)文件恢復(fù)，這一切都可以通過(guò)我們的備份恢復(fù)點(diǎn)實(shí)現(xiàn)，即使該客戶(hù)并沒(méi)有認(rèn)購(gòu)備份服務(wù)。很多時(shí)候，我們還需要偶爾幫客戶(hù)恢復(fù)那些被意外刪除的文件或者誤以為沒(méi)用而被刪除的存在備份數(shù)據(jù)的虛擬服務(wù)器。

還記得Cloud Space披露的，某位攻擊者控制其Amazon賬戶(hù)并將包括備份信息在內(nèi)的全部數(shù)據(jù)刪除一空的案例。在這種情況下，我們能夠在短短幾分鐘之間就對(duì)幾乎全部數(shù)據(jù)進(jìn)行恢復(fù)——根據(jù)我們自己的備份內(nèi)容。

總結(jié)來(lái)講，我們需要量身定作自己的云解決方案

通過(guò)將VMware、高性能存儲(chǔ)以及低延遲網(wǎng)絡(luò)外加Pernix加速機(jī)制相結(jié)合，Webhosting.net的VMware云方案能夠切實(shí)提供可觀的IO性能、通過(guò)本地主機(jī)SSD提供存儲(chǔ)服務(wù)并顯著提升單位容量所能實(shí)現(xiàn)的IO上限。

結(jié)果就是，如果有必要，我們完全可以通過(guò)規(guī)模更小的虛擬機(jī)在無(wú)需迫使客戶(hù)為過(guò)度配置的虛擬服務(wù)器付費(fèi)的前提下，顯著提高IO性能與數(shù)據(jù)吞吐能力。

總結(jié)陳詞——每一套云解決方案都有自己的局限性，因此適合自己的才是最好的。

原文標(biāo)題：Cloud Limits and Your Needs

 【51CTO.com獨(dú)家譯文，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明出處】