阿裡雲雲伺服器（elastic compute service，簡稱 ecs）是一種簡單高效、處理能力可彈性伸縮的計算服務，幫助客戶快速建構更穩定、安全的應用，提升運維效率，降低 it 成本，使您更專注于核心業務創新。而阿裡雲塊存儲（block
storage），是阿裡雲為雲伺服器ecs提供的低延遲時間、持久性、高可靠的資料塊級随機存儲。塊存儲支援在可用區内自動複制資料，防止意外的硬體故障導緻資料不可用，以保護您的業務免于元件故障的威脅。就像對待硬碟一樣，客戶可以對挂載到ecs執行個體上的塊存儲做格式化、建立檔案系統等操作，并對資料持久化存儲。
對ecs來說，目前阿裡雲能提供的兩種雲服務的規格清單參數如下：
表1-1 ecs在專有雲和公共雲最大規格對比
最大cpu數
最大記憶體
網絡帶寬
最大雲盤數量
專有雲（v2）
16
64gb
萬兆網絡
4
公共雲
40
224gb
表1-2. 塊存儲規格對比
最大容量
最大吞吐量
最大iops
最小響應時間
專有雲本地ssd磁盤
800gb
>200mb/s
12000
0.5ms
專有雲
普通雲盤
2000gb
40mb/s
數百
5ms
ssd雲盤
2048gb
256mb/s
20000
高效雲盤
32768gb
80mb/s
3000
1ms
顯然，公共雲環境的雲資源的計算能力能力高于專有雲，而專有雲上運作一些對性能要求非常嚴格，且非常關鍵的應用，比如oracle資料庫，該如何在阿裡雲平台上提供對應的資源且保證容量、性能都能滿足業務需求呢？我們做了如下測試進行驗證。
我們在阿裡雲公共雲華東1區申請了5台ecs，模拟專有雲平台的環境進行測試。兼顧效率和與專有雲的環境的相容比對，這5台ecs的配置和用途分别是：1台16核cpu 64gb的ecs作為資料庫伺服器，3台2核8gb外加2個2tb ssd雲盤的ecs作為存儲伺服器，1台2核8gb的ecs作為壓力測試伺服器。
表2-1.測試環境系統配置
編号
配置
數量
用途
1
獨占執行個體，16c 64g，不帶系統盤
資料庫伺服器
2
非獨占執行個體，2c 8g，2tb ssd雲盤*2資料盤
3
存儲伺服器
非獨占執行個體，2c 8g，不帶資料盤
壓力測試伺服器
資料庫我們做單執行個體部署，同時因為專有雲暫時隻有2tb的最大單盤容量，是以我們需要在多台ecs搭建分布式存儲系統，為資料庫提供超出雲平台單台ecs所能挂載的塊存儲容量。
<b>阿裡雲塊存儲（雲盤）</b>基于盤古分布式檔案系統，資料儲存3份副本，具有99.9999999%的資料可靠性，且後端全部使用pc伺服器，廉價且易維護。阿裡雲公共雲提供單盤32tb的ssd磁盤，單個ecs最大可挂載4個雲盤，最終提供客戶128tb的高速大容量空間。
<b>glusterfs</b>是一個開源的分布式檔案系統，具有強大的橫向擴充能力，通過擴充能夠支援數pb存儲容量和處理數千用戶端。
<b>iscsi</b>是一種基于tcp/ip 的協定，用來建立和管理ip儲存設備、主機和客戶機等之間的互相連接配接，并建立存儲區域網絡（san）。san 使得scsi 協定應用于高速資料傳輸網絡成為可能，這種傳輸以資料塊級别（block-level）在多個資料存儲網絡間進行。
阿裡雲專有雲最新v2版本最大支援2tb的ssd雲盤單盤容量，預計會在v3版本開放支援32tb。是以，我們舍棄在公共雲上直接使用超過2tb ssd雲盤的方案。glusterfs和iscsi兩種開源方案我們也分别進行了測試：兩種檔案系統都能将分布在多台伺服器上的存儲資源（磁盤）集中到一台伺服器上，存儲容量最大支援到pb以上。glusterfs理論上更适合于存放不經常讀寫的大檔案，我們在實測中發現使用gluster搭建的存儲穩定性欠佳，資料檔案部署在glusterfs中在大規模并發讀寫下容易導緻資料庫hang住并頻繁報錯。而iscsi則是更成熟的方案，與傳統的資料庫使用的san存儲網絡更接近。最終，我們標明使用iscsi方案将3台存儲伺服器的6個2tb ssd雲盤通過網絡iscsi協定共享給資料庫伺服器，實作12tb大容量存儲。
測試方案架構最終确定：
圖2-1.測試環境系統架構
swingbench生成測試資料，然後模拟指定數量的用戶端對資料庫的并發通路壓力，最終記錄測試結果。swingbench可以通過多台伺服器對同一個資料庫同時加壓，本測試我們模拟使用1台并發加壓。
對于單個ssd雲盤直接挂載給ecs來說，其性能在官網已經給出很明确的sla說明：
圖2-2.ssd雲盤性能sla
但是我們的測試架構中，雲盤并不直接挂載給資料庫伺服器，而是通過iscsi協定走内網映射給資料庫伺服器，是以除了雲盤的最終性能表現還取決于iscsi target的内網的帶寬。對于外部使用者來說，ecs執行個體的内網帶寬根據不同規格是做了相應的限制的，是以我們有必要先做一個基準測試以确認ssd雲盤通過iscsi共享後的性能。
下圖2-3是單個存儲伺服器ecs tcp帶寬測試結果，平均大約100mb/s：
圖2-3 存儲伺服器ecs tcp網絡帶寬測試結果
基于對單個ecs的tcp網絡測試結果，我們在資料庫伺服器上使用oracle io校準工具先後測試挂載2台iscsi target和3台iscsi target時得到的存儲系統帶寬、iops的最大值。
當挂載2台iscsi target時，得到的最大iops大約12000，最大帶寬195mb/s：
圖2-4 2台iscsi存儲伺服器的io校準結果
當我們增加1台iscsi target接入到資料庫伺服器後，再次測試，得到的結果如下：
圖2-5 3台iscsi存儲伺服器的io校準結果
根據以上兩個測試，得出結論：我們實驗的環境中，網絡瓶頸在非獨占式ecs的内網帶寬，2cpu 8gb記憶體的這一規格ecs最大内網帶寬大約為100mb/s，16c 64gb記憶體這一規格獨占式ecs執行個體至少有超過300mb/s的内網帶寬。在資料庫伺服器内網帶寬瓶頸到來之前，需要提升oracle資料庫的io能力，可以橫向添加iscsi target存儲伺服器。
swingbench包含4種基準測試：
l <b>order entry </b>基于oracle 11g/12c的示例模式“oe”。同時進行了一些修改，不需要安裝sptial模式和intermedia模式。它可以持續運作，直到磁盤空間耗盡。它引入了少量表上的嚴重競争，用于互聯和記憶體的壓力測試。它可以通過bin目錄中的“oewizard”進行安裝。基準測試程式存在純jdbc版本和pl/sql版本（網絡負載更低）。
l <b>sales history</b>基于oracle 11g/12c的示例模式“sh”，用于測試針對大表的負載查詢的性能。表是隻讀的，并且大小能夠從1gb擴充到1tb。也可以使用自定義模式建立更小或者更大的模式。
l <b>calling circle</b>模拟一個線上電信應用的sql。它需要在每次運作之前生成資料檔案，并且從資料庫伺服器端複制到負載生成器，通常需要1gb到8gb磁盤空間。該基準測試是cpu密集型的。經驗表明，對于資料庫伺服器的每2個cpu，負載生成器至少需要1個cpu。它用于測試cpu和記憶體，不需要強大的i/o子系統。它可以通過bin目錄中的“ccwizard”進行安裝。
l <b>stress test </b>針對表的簡單随機插入、更新、删除以及查詢測試，讀寫比例為50/50。
我們選用order entry做測試模型，造資料腳本執行比較費時，分别造了100gb資料和1tb資料做兩批對比測試。在測試中，我們可以通過靈活調節每類業務操作的比重來平衡資料庫的update/insert/select/delete等dml操作。因為測試模型腳本是swingbench已經封裝好的，是以我們無法調整任何執行的sql語句，但是我們對資料庫系統本身及相關參數進行了基本優化，比如設定合理的sga、pga、log_buffer大小，調整redolog日志為2gb一個，以及session_cached_cursors從50調大到200等。
100gb資料量由swingbench自動生成，選擇建立完整索引，檢視各個表的記錄數情況參考表4-1。同樣，1tb資料則是這些表中資料量的10倍。事實上，我們觀察到，對于100gb的資料量，加上索引的使用空間，表空間的使用量達到了150gb以上。
表4-1 100gb下表資料量統計
表名
初始資料量
logon
238298400
customers
100000000
addresses
150000000
card_details
5
order_items
428924688
6
orders
142979000
7
orderentry_metadata
8
product_descriptions
1000
9
product_information
10
inventories
899927
11
warehouses
同樣，對于1tb的資料量來說，以上表格中的業務表的記錄數都是乘以10倍來計算的，參數表資料量則不發生變化。
每一輪測試，我們使用相同的參數，每次隻調整模拟并發使用者數，模拟使用者思考時間為0，每個場景運作至少20分鐘，中間收集伺服器性能資料、資料庫awr資料和swingbench的結果，最終我們以并發使用者數、tps、qps、系統iops和rt這5大名額來對測試結果進行統計和對比分析。
各類操作的比例關系，落到存儲上io讀和寫的比例大約為7:3，對io系統來說，主要考驗的是iops能力。
圖4-1 oe模型中讀寫混合場景各類操作的比例配比
首先，我們把收集到的完成測試資料列成表格。但是這并不直覺，如果希望觀察到趨勢而不太在意資料細節的，我們可以直接看下面的資料對比圖。請注意，本文中所有的縱軸都代表并發使用者數。
表4-2 讀寫混合場景測試結果
資料量
使用者數
平均tps
qps
iops
平均rt(ms)
100g
20
259
2745
1500
50
562
5957
3100
100
1258
13334
5200
200
2320
24592
8000
15
300
2350
24910
7900
1tb
236
2501
2500
14
574
6084
5600
1069
11331
9800
22
1599
16949
13000
53
1690
17914
14500
105
首先，我們看圖4-2，100gb基線資料，随着并發使用者數的增長，tps、qps以及iops都接近線性增長，rt也呈穩步增長趨勢。在我們的實驗中，當使用者數超過200後，tps的增長接近為0，但是rt出現了激增。這個現象與理論也是比對的：固定條件下，tps會随着并發線上使用者數的增長而增長，但是當超過某臨界值後，tps增長趨緩，甚至可能會下降。同時，響應時間（rt）在并發使用者突破臨界值後，也會出現急劇增長。
圖4-2 100gb資料量性能表現
同樣，我們觀察圖4-3，在1tb基線資料下，我們獲得了與圖4-1基本類似的性能視圖：tps、qps、iops随着并發使用者數上升而上升。并發使用者數超過200後，性能提升開始變得不太明顯。
圖4-3 1tb資料量性能表現
圖4-4 100gb和1tb資料tps與rt對比
我們把兩種資料基線的測試結果放到同一個圖4-3中來觀察，能看到一些存在差異的地方：在相同并發使用者數條件下，100gb基線的tps比1tb基線的要高；相反，1t基線的rt和iops比100gb極限的高。這也是很好了解的，更大的資料量意味着表的記錄數更多，而資料庫的各項操作掃描的資料塊也越多，自然iops更高，且需要的時間也更長。
讀寫混合的場景中，我們還有1個問題值得讨論：在基礎資料量100g時，當tps達到極限，為什麼iops還不到1萬？
圖4-5 100gb基線資料混合場景資料庫top5等待事件
這個問題我們對比着1tb基數的資料量來看，在後者的tps達到上限時，iops跑到15000左右，接近了系統的iops極限（16712）。同時，我們查詢當時的作業系統負載和oracle awr報告，發現當時cpu user%大約70%，有20%的wait%，awr中top5等待事件占比78.32%的排名第一事件為“db file sequential read”。該事件意味着oracle程序需要通路的資料塊不能從sga直接擷取，是以會等待資料塊從磁盤（i/o系統）中讀到記憶體sga中。在sga不增加且sql不能調整的情況下，磁盤的性能決定了整體性能。是以我們認為資料庫的資料量相對于存儲容量越接近，資料掃描時越能充分使用到磁盤的io能力。當資料量相對小的時候，由于資料分布的原因，資料庫整體性能表現将一定程度低于io系統的整體性能。
所謂“純讀”場景，隻有一種類型的業務，即使用者浏覽商品，因為執行的事務操作，是以依然會有很低比例的寫資料庫操作。為了友善了解，我們近似地認為落到存儲上io讀的比例幾乎為100%。
圖4-6 oe模型中讀寫純讀場景各類操作的比例配比
表4-3 純讀場景測試結果
349
2443
700
870
6090
1350
1734
42630
1750
3367
23569
1800
4717
33019
1400
400
5460
38220
500
5563
38941
320
31
344
2408
858
6006
1692
11844
5000
3184
22288
7200
4010
28070
28
4650
32550
6000
27
空缺
我們依然把表格用圖形的方式展示：
圖4-7 100gb資料量性能表現
圖4-8 1tb資料量性能表現
觀察以上圖4-7和4-8，純讀場景表現出對并發使用者數更好的支援能力，在rt控制在30ms左右時，資料庫能支撐500并發使用者通路，該場景下并發使用者的tps拐點提升到了300-400這個數值，比混合場景200使用者提升了幾乎一倍。同時，響應時間也控制在更好的水準，大部分測試案例中rt都在20ms以内，20ms是大多數oltp系統對資料庫響應的最大極限。同時，純讀場景磁盤iops也大大低于混合場景，甚至當tps超過一定數值後，iops還表現出了下降的趨勢。這個測試結果也是比較好了解的，我們使用的oltp業務場景進行測試，而純讀的業務主要滿足使用者的各種查詢需求，在一個良好的it系統中，使用者經常需要查詢的内容大部分是被各級緩存存儲的，最直接的就是資料庫的資料緩存，當然也可以将靜态資料存放在記憶體資料庫，以獲得更好的性能。随着系統測試地不斷往下進行，業務需要的資料被越來越多地“預熱”到sga中，是以需要從磁盤讀取的資料也随之減少，表現出來就是磁盤實體iops的降低。
圖4-9 100gb和1tb下tps與rt對比
我們把100gb和1tb兩個資料基線的測試結果放到同一個圖4-9中進行對比，自然100gb基線的資料表現要好于1tb資料基線的結果。但是在并發使用者數比較少時，兩種資料基線的tps性能是非常接近的，這意味着在并發使用者數不多的情況下，純讀的業務場景最依賴的是記憶體的容量，記憶體容量越大，那就可以緩存越多的資料，系統能支撐越大的業務量。這個結論也與我們的基本認知是一緻的。
圖5-1 100gb資料兩種場景的性能結果對比
最後，為了友善讀者閱讀，我們把所有的資料合并到一張圖裡5-1再進行觀察和總結。我們可以得出如下結論：
l 100gb基線資料，rt允許（≈20ms）的範圍内，混合場景最大tps為2320，最大qps為24590，此時有200名并發使用者；
l 1tb基線資料，rt允許（≈20ms）的範圍内，混合場景最大tps為1069，最大qps為11330，此時有100名并發使用者；
l 100gb基線資料，rt允許（≈10ms）的範圍内，查詢場景最大tps為4717，最大qps為33019，此時有300名并發使用者；
l 1tb基線資料，rt允許（≈10ms）的範圍内，查詢場景最大tps為1692，最大qps為11844，此時有100名并發使用者；
l 雲盤的讀性能好于寫性能，更适合大規模随機讀的業務場景；
l 系統可以通過增加雲盤的方式線性提升io的容量和性能。
我們對比表5-1三種方式，給出需要在阿裡雲上自建類似oracle或db2這樣的傳統商業資料庫的客戶選型和架構方案。
表5-1 三種存儲架構技術參數對比
大容量ssd雲盤
glusterfs
iscsi
容量
128tb每台ecs
>1pb每台ecs
成本
低
對ecs性能消耗
無
可靠性
99.9999999%
<90%
>99.9%
單盤20000
20000*磁盤數量，極限值受限于雲平台内網帶寬
吞吐量
單盤256mb/s
120~160mb/s
120mb/s*雲盤數量，極限值受限于雲平台内網帶寬
tps峰值
n/a
4717（受限條件）
tps峰值并發使用者
tps峰值響應時間
7ms
限制
專有雲v2不輸出
共享雲平台内網帶寬
l 阿裡雲支援使用者自建商業資料庫，為了業務的連續性，建議客戶至少搭建ha高可用資料庫系統，如果有能力最好搭建具有容災的資料庫系統。客戶需要自己解決license和運維問題，目前已有合作夥伴推出運維工具，可以在雲市場采購；
l 資料庫類應用系統，不要猶豫，請直接使用ssd雲盤；
l 公共雲上，業務存儲容量、iops和帶寬需求小于單個ssd雲盤規格的，直接使用ssd雲盤。任意一項不滿足的，可以申請最多4個ssd雲盤挂載使用；
l 無論是公共雲還是專有雲，如果出現超出單個ecs能直接挂載的ssd雲盤容量和性能的需求，建議使用iscsi将多個雲盤共享給資料庫伺服器，以橫向擴充io系統的容量和性能。這種架構中，需要提前考慮各個節點間的内網帶寬，以免因為内網帶寬而導緻無法充分發揮雲盤的能力；
l 雲盤的資料可靠性和可用性都是非常高的，如果需要更進階别的保障，在oracle資料庫中，可以考慮部署rac叢集，以及使用帶内部備援的asm存儲系統，在犧牲一部分性能和容量的前提下帶來極高的可靠性和可用性；
l 如果使用者對成本比較敏感，需要更精細地計算直接使用大容量ssd雲盤和iscsi分布式存儲架構的成本，根據自己的實際需求選用最經濟的方案。