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

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

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

然而作為用戶時常面對的性能問題之一，磁盤或者說存儲性能始終困擾著我們每位云服務(wù)支持者。

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

存儲故事：容量與IO，一對“歡喜冤家”

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

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

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

以Azure為例，其官方說明文檔當中給出以下說明：

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

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

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

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

如果大家繼續(xù)閱讀這份說明文檔，就會發(fā)現(xiàn)每塊獨立磁盤的性能其實還要更低，特別在磁盤容量較小的情況下，這是因為即使是高性能SSD也面臨著吞吐能力限制。這就讓問題變得更加復雜，特別是在大家優(yōu)先將自己的應用程序啟動并運行在云環(huán)境當中時。

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

輸入/輸出(簡稱I/O)的單位大小為256 KB。如果該數(shù)據(jù)以小于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似乎更傾向于將性能與存儲空間相結(jié)合，且實際效果要優(yōu)于Azure。

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

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

在各類EBS存儲分卷當中，磁性存儲分卷擁有最低的每GB使用成本，而且這些分卷的平均IOPS大約在100左右，峰值IOPS則可達到數(shù)百。另外，其存儲容量區(qū)間在1 Gib到1 TiB之間。

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

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

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

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

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

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

下面讓我們具體看看。

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

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

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

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

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

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

MSSQL 1

MSSQL 2

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

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

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

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

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

◆單一二進制鏡像運行在整體交換機組合當中

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

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

◆Arista的EOS基于非專有開放標準

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

◆顯著提升性價比水平

◆VMware公司頭號合作伙伴，Arista充當VMware vAirCloud平臺的底層方案

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

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

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

而著眼于Amazon與Azure：

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

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

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

實時增加資源

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

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

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

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

一點額外服務(wù)

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

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

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

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

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

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

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

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

原文標題：Cloud Limits and Your Needs

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