3. 雲端檔案系統架構
3.1. 複製備份
一般常見的雲端檔案系統架構,所採用的備份方式為直接複製備份,在這邊 定義符號 Rn,代表總共有 n 個副本被儲存在各個儲存位置,儲存成本為 n,其 中由於儲存成本的考量,一般 R2 與 R3 是廣泛被使用的兩種傳統架構。隨著副 本總數 n 的增長,異地備援所獲得的效益也會逐步上升,但是與之相對的,所需 要付出的儲存成本亦會隨之提高為 n 倍。
3.1.1. R1 系統架構
R1 架構即為資料只儲存一份在本地端,不再有其他備份的副本被儲存。可 視為不使用異地備援,僅單一本地端的雲端檔案系統架構。如圖 3–1 (a)所表示,
圖 3–1 R1 架構
(a) 單一 Block (b) 兩個 Blocks
S
lS
xB P
1S
lS
xB
1P
1B
2P
2資料以 B 來做代表;P 則代表各個儲存的機器節點;S 為底下機器對外的網路,
通常可視為路由器或交換器,Sl代表的是本地端網路;最上層 Sx代表外部雲端。
一般雲端檔案系統在儲存資料時都是以 Blocks 為單位來進行存取,當一份副本 有兩個 Blocks 時,可以利用分散儲存的方式,來加快資料的讀取速度,如圖 3–
1 (b)即為 R1 架構一份副本有兩個 Blocks 之儲存分配情形,在本地端底下不同的 機器節點各自儲存一個 Block,讀取資料時可以平行讀取 B1與 B2來加快速度。
3.1.2. R2 系統架構
R2 架構採取最簡單的複製備份方式,對資料進行異地備援的動作。為了確 保當本地端無法被進行存取時,仍舊可以繼續提供服務,在異地端亦儲存備份一 份副本。如圖 3–2 所示,本地端 Sl儲存一份資料 B,在異地端 Sr也備份一份資 料 B。Sr除了替 Sl備份一份資料 B,當 Sl發生錯誤或不可預期之意外,導致對外 連線中斷或無法繼續服務時,Sr之資料可以立刻代替 Sl繼續對外提供服務。
對一般雲端檔案系統來說,同樣的 R2 架構在兩個 Blocks 之狀況,也會利用 分散儲存的方式,來加快讀取速度。如圖 3–3 即為 R2 架構一份副本有兩個 Blocks 的範例,在本地端與異端端都一樣還是各儲存一份副本,藉由分散儲存的方式,
能夠有比圖 3–2 的架構獲得更快的讀取速度。將原本儲存在本地端的一份副本 分散儲存到本地端底下不同的機器節點 P1、P2,異地端所儲存的副本也一樣分散 儲存到異地端底下不同的機器節點 P3、P4,這樣存取資料 B 時便可以同時平行 讀取 B1與 B2,達到加快讀取速度的效果。
圖 3–2 R2 架構
S
lS
rS
xB P
1B
P
2此 R2 架構的優點,為既達到異地備援之效果,其儲存成本亦是最低的架構,
當 Sl之機器一發生錯誤或意外時,可以依靠異地端的 Sr來重建資料 B,同樣的 狀況反過來看亦是如此。但是考慮到本地端與異地端之間的傳輸效能,如果是單 一機器常發生異常之狀況,則將會造成所需付出的傳輸成本偏高。
3.1.3. R3 系統架構
R3 架構為一般 Hadoop 常見的資料備份架構,跟 R2 一樣是以複製備份的方 式來進行異地備援。與 R2 不同的是,除了在異地端備份一份資料外,在本地端 也會多儲存備份一份資料 B。如圖 3–4 所示,以 R2 的架構為基礎,在本地端 Sl底下節點 P2多複製一份資料 B。當 P1節點發生意外或錯誤時,R3 架構不需要 再透過異地端 Sr之資料 B,來還原毀損或遺失的資料,可直接使用在本地端 P2
節點的備份資料。
以 HDFS 架構其傳統的備份方式來看,P1與 P2可視為同一個 Rack 底下不同 圖 3–3 R2 架構:兩個 Blocks
S
lS
rS
xB
1P
1B
2P
2B
1P
3B
2P
4圖 3–4 R3 架構
S
lS
rS
xB P
1B P
2B
P
3的儲存機器,即本地端;P3則是在另一個不同的 Rack 底下之儲存機器,即異地 端。利用此架構方式備份資料,將三份備份資料分別儲存在這三個機器節點,此 方式能夠簡單達到異地備援之效果,並解決 R2 架構所產生的傳輸效能問題。
與 R2 架構使用兩個 Blocks 相同,R3 架構在兩個 Blocks 的狀況一樣能夠使 用分散儲存的方式,來加快系統對資料的讀取速度。如圖 3–5 即為 R3 架構兩 個 Blocks 的儲存方式,在本地端儲存兩份副本總共有四個 Blocks,分別都分散 儲存到本地端底下不同的機器節點 P1、P2、P3、P4,異地端所備份的副本一樣將 兩個 Blocks 分散儲存 P5、P6,如此一來在存取資料時,便能平行讀取 B1與 B2, 利用分散儲存的方式達到加快資料讀取速度之效果。
R3 架構與 R2 架構相比,所需花費的儲存成本相對增加,但是在本地端 Sl 經常有單一機器發生錯誤或意外之狀況,不需要如 R2 架構一樣付出比較高的傳 輸成本,考慮到 R4、R5 等後續的備份方式之架構,下一小節將整理以 Rn 架構 來說明與介紹。
3.1.4. Rn 系統架構
觀察 R2 與 R3 之架構,可簡單推論出各個 Rn 架構。Rn 系統架構分別在本 地端 Sl放置⌈n/2⌉個資料 B,異地端 Sr則備份⌊n/2⌋個資料 B,依據儲存的資料 B 之數量 n,將其分散在 n 台機器節點之上。
當 n 之值越大時,異地備援之效果亦會隨之提高,但是相對的,所需付出的 儲存空間成本亦會提升為 n 倍。因應各種不同的使用情形,n 之值並不一定是越
S
lS
rS
xB
2P
2B
1P
3B
1P
5B
2P
6B
2P
4B
1P
1圖 3–5 R3 架構:兩個 Blocks
大就越好,如果資料量本身已經十分龐大,則其 n 倍之儲存成本將會是一個難以 想像的數字。一般的雲端檔案系統在實際應用時,資金以及設備等相關因素會限 制住儲存成本的增加,考慮到 R4 或 R5 甚至是儲存成本更高的架構並不常被應 用,後續的分析將以 R2 以及 R3 為主作代表。