ScaleIO 軟體定義儲存 VSAN Ceph SDS 儲存

實戰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規格

測試架構

使用3台Server與10Gb網路,每台Server均有安裝SDS與SDC,並且含有192.168.38.x及192.168.39.x兩個網段,作為管理LAN與資料LAN,Gateway角色安裝於第一台vSphere,如圖7所示。


▲圖7 測試架構圖。


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!