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

以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性能與數據吞吐能力。

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

原文標題：Cloud Limits and Your Needs

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