實戰EMC ScaleIO部署捲起袖子玩軟體定義儲存

2016-02-02

黃明偉

軟體定義的儲存（SDS）突破傳統儲存架構困境，將儲存走向開放、統合的境界，讓儲存也能擁有伺服器虛擬化對運算所帶來的簡化、效率及節省成本。近年不少大廠紛紛推出自有解決方案搶攻市場，EMC也不遑多讓推出ViPR、Isilon、ECS以及ScaleIO，本文將分享ScaleIO架構與實際部署經驗。

Performance（Massive I/O parallelism）

傳統的Storage會搭載兩個Controller承載所有的 I/O，而ScaleIO可將I/O分流至所有的Server，某種程度上也是拜Rebalance所賜，資料越分散，使得平行處理效率更高。

ScaleIO元件簡介

以下先說明ScaleIO的架構及階層關係，然後講解環境準備與注意事項。

ScaleIO架構說明

圖5展示一套ScaleIO系統的解決方案，該架構中包括三個安裝ScaleIO套件的伺服器，三個大方框代表實體伺服器，裡面包含SDS、SDC、MDM等角色。接著，分別介紹其中各個元件的角色與功能。

▲圖5 ScaleIO架構圖。（圖片來源：EMC）

Mete Data Manager（MDM）
Mete Data Manager（MDM）可配置和監控ScaleIO系統主要核心。MDM擁有Primary MDM、Secondary MDM、Tie Breaker等三個成員，構成一個集群模式（Cluster），因此部署ScaleIO至少需要三台伺服器。

不過，也有另一種選擇，亦即開啟單一模式（Single-mode），將原本三個角色節省為一個，僅安裝到一台伺服器，但這也增加了系統毀損（Crash）的風險。因此，原廠建議部署時預設為安裝三台SDS建立一個MDM Cluster。

Primary MDM
主要MDM角色，其實也是安裝在某個SDS裡面，讓SDS多一個主要中控者的功能，就像是一般Storage Array裡面的Controller，負責管理所有的配置和監控。

Secondary MDM
次要MDM角色，功能與Primary MDM一樣且安裝在某一台SDS內。若要建立的ScaleIO是MDM Cluster架構，它的角色就是Primary MDM的備援，基本上兩個MDM是資料同步的。因此，當Primary MDM失效時，Secondary MDM會即刻接手，讓ScaleIO服務不中斷。

Tie Breaker
了解Primary MDM、Secondary MDM之後，應該會好奇它們是如何得知對方是否仍然正常運作，何時該切換MDM？所以，Tie Breaker（TB）的工作是偵察MDM Cluster中若有失效或中斷的情形，它會立即切換主控權給適當的MDM角色，不論是主要或次要的切換都會聽從TB的命令，因此可以把它當作是一個「仲裁者」。

ScaleIO Data Server（SDS）
ScaleIO Data Server（SDS）就像是一台伺服器的管家角色，假設環境有多台機器，SDS軟體就必須安裝在ScaleIO系統內所有的伺服器，伺服器才能分享自已底層的資源出來。SDS是總管單台伺服器的容量並供給前端資料存取的管理單元。換句話說，它能接管實體機內的儲存媒體，通常包括HDD、SSD等等，然後透過SDS集中伺服器內所有的資源再分享給SDC存取。

ScaleIO Data Client（SDC）
ScaleIO Data Client（SDC）是一個輕量化（Light-weight）的設備驅動程式（Driver）用於SDS溝通。安裝SDS Driver後，所有的I/O都將由SDC來傳送。另一個重要功能是，存取ScaleIO建立出來的Volume，將其轉換成Block Device。當然，EMC也提供適合各種OS或Hypervisor專用的SDC Driver，原始套件中包含Linux、Windows，更提供Open Stack。

ScaleIO階層關係

圖6說明ScaleIO的階層，由9台Servers組成的ScaleIO，設計包含3個Protection Domain、2個Storage Pool 、2個Fault Set 。接著，說明其中的運作方式。

▲圖6 ScaleIO階層關係。（圖片來源：EMC）

Protection Domain（PD）
Protection Domain（PD）是邏輯空間的概念，它可以包含多個Storage Pool（SP），每一個Storage Pool僅能屬於一個Protection Domain。ScaleIO最上層的資料保護單元是Protection Domain，第二層為Storage Pool，所有的資料會隨機儲存成兩份在儲存媒體內。

當然，在部署環境時也可以選擇設定資料覆寫（Replication）指定複本（Copy）儲存的位置，因此可以在PD下面設計Storage Pool與Fault Set，以便在指定的PD區域內形成資料保護圈。基本上，在同一個PD底下的Storage Pool就有Two-copy機制保護，預設SP是可以相互備份達成Data Protection。

Storage Pool（SP）
Storage Pool（SP）是由多個實體HDD或SSD組成的集合。而每個實體伺服器會被歸納到指定的Storage Pool內，因此要掛載Volume空間給Server時，必須在Storage Pool層級建立Volume並映射（Mapping）至指定的Server，此時Storage Pool會即時將資料打散到各個底層Device當中。

Fault Set（FS）
先前已提到ScaleIO是以Two-copy機制保護資料，資料A與A'分別儲存在不同的硬碟上，當A資料寫入後，會另外儲存一份A'在另一顆硬碟上。看起很完美的保護，事實還是存在風險。舉例說來，有一種情況會造成資料無法救回，假設Server損壞又剛好Two-copy資料均撒在同一個Server裡的兩顆硬碟，此時資料皆無法正常救回。

為了避免此種情況發生，ScaleIO設計Fault Set（FS）群體，將Server加入不同的群體以群體為單位的方式隔開，使彼此相互備援。假設系統有FS01、FS02、FS03三個Fault Set群體。同一個群體（FS01）內，Server複本的資料不會撒在相同的（FS01）群體內，只會往其他的群體（FS02、FS03）丟，如此就可以避免單點失效造成的資料遺失。

環境準備與注意事項

運作環境所需的系統要求，以及筆者採用的Server規格，如表1所示。

表1 系統需求與筆者的Server規格