軟體定義儲存深度動手玩　ScaleIO功能實測（下）

I/O Priority

不論是Rebalance或Rebuild，Rebuild I/O針對SP下每個Device進行限制，ScaleIO很貼心地設計I/O Priority，它能細分現有I/O（包括APP I/O）以及Rebalance或Rebuild I/O，根據不同環境的政策，可能是SLA某些APP I/O必須有保證頻寬等。

現實中，同時有多個Rebalance與Rebuild I/O是很常發生的情況，舉例來說，一邊增加新的節點，一邊也更換掉損失的硬碟，此時就會有兩個Rebalance I/O發生，內部I/O稱為現有資料副本的管理，即Rebuild Rebalance、Rebuild I/O，外部I/O則可想像成新資料進入已建立的Volume中。

▲ 圖25 設定I/O Priority。

所以說QoS的設計真是一門學問，必須很清楚現況I/O分成哪些種類，並且了解它們各自所需的頻寬大小，其中要加入突發條件增加緩衝頻寬量。當然這裡介紹三種QoS的設計順序也是有原因，可以依照Protection Domain、Rebuild/Rebalance、Volume由大至小分流目前的頻寬，已達到最佳化Storage使用，如圖25所示。

以下四種政策可協助環境做更進階的管理I/O，分別加以說明：

1. No Limit

第一種是沒有限制的政策，可以發揮系統最大效能，讓不論是缺少一份或不平均的副本資料，以最快的速度達到系統保護水準。但是，全速支援Rebuild Rebalance、Rebuild I/O可能會影響現有的I/O。可能適用的情況是在PoC上或ScaleIO有過多的節點損失，系統必須快速回復正常的副本數量，如圖26所示。

▲ 圖26 Rebalance concurrent I/O limit。

2. Limit Concurrent I/O

考量到多個Rebuild、RebalanceI/O運行的數量，可以限定只允許若干個Rebuild、Rebalance I/O進行傳輸。

3. Favor Application I/O

此選項設計較多元，光看命名就了解是要先讓Application I/O通過，即Application I/O擁有較高優先權。前面提到的政策都只限定Rebuild Rebalance、Rebuild I/O數量，這次連頻寬也一起加入考慮。如圖26所示設定Rebalance concurrent I/O limit = 2，另外Rebalance bandwidth limit = 10240KB/s代表二組Rebalance的行動僅限定在10240KB/s頻寬工作。

4. Dynamic Bandwidth Throttling

這是Favor Application I/O加強版，可再增加IOPS的區間與延遲時間。官網對於IOPS範圍值為1～1024、頻寬的範圍值是1～102400KB/s、反應時間的範圍值則為10～60000毫秒（ms），如圖27所示。

▲ 圖27 Dynamic Bandwidth Throttling子項目。

Set Volume Limits

最後一個方法為Set Volume Limits，它的細度更小，可針對Volume限定IOPS值與頻寬，以下實驗並驗證效果：

選定Volume，然後按下滑鼠右鍵，開啟快速選單後點選【Set Volume Limits】，如圖28所示，左上方有限定IOPS值與頻寬欄位，本實驗以100MB/s為限制水準（圖29），最後觀察GUI，與之前全速22萬相比之下頻寬被限制在100MB/s，連帶IOPS也升至25000，如圖30所示。

▲ 圖28 Set Volume Limits。

▲ 圖29 Volume Limits設為100MB/s。

▲ 圖30 Volume的頻寬被限制在100MB/s。

結語

QoS和Fault Set善用與否，最主要的原因就在於設計！本篇分享Performance、Data Protection、QoS實作，發現光是QoS就有不同層級設定，不論是Data Protection、Storage Pool、Fault Set或Volume，都有自己的限流機制。

另外，更可以配合實體伺服器配製來設計Fault Set，依照應用服務、主機群或是機櫃打造專屬於自己的環境架構容錯保護，所以除了靠先天產品的賦予功能外，更重要的是靠後天架構來設計出好的架構。

＜本文作者：黃明偉，任職於QCT雲達科技，經歷Networking、vSphere、VMware VDI、EMC VNX，目前從事雲端應用服務研究，接觸各大廠軟體定義式儲存解決方案SDS Solution。＞