細說 Azure Storage 的冗餘策略

sparkdev發表於2017-08-28

當我們想要把應用搬到雲端的時候,首先要關注的便是資料的安全性。當然所有的雲服務廠商都會對使用者資料承諾一個非常高的安全性,但萬一出現意外呢?我們是不是還要有適當的應對方案?比如今年的3月8日晚間,Azure 某個區域中的儲存幾乎全部不能訪問,持續達兩個多小時。當時最擔心的是:使用者的資料萬一丟掉怎麼辦?同時,我們是不是可以根據雲服務提供的資料服務的特點來最佳化程式的效能呢?基於如此種種的原因,我們需要了解雲端資料服務的一些特性的詳情,這將對我們很有幫助。本文將和大家一起探討 Azure Storage 的冗餘策略。

理解 Azure Storage 冗餘策略的好處

微軟針對不同的應用場景提供了不同的儲存冗餘策略。比如對可靠性要求很高的資料可以選擇多個異地的備份,而對訪問速度要求高的資料則可以使用高速的儲存裝置。當然,不同的方案成本也是不一樣的。我們可以針對應用的特點使用不同的儲存策略,這樣可以節省成本。還可以指定對應的容災備份以及災難恢復方案。

Azure Storage Account

需要注意的是,Azure Storage 儲存的冗餘策略是繫結在 Azure Storage Account 上的。Azure Storage 當前一共有四種資料的冗餘策略,分別是:

Locally Redundant Storage(LRS)

Zone Redundant Storage(ZRS)

Geo Redundant Storage(GRS)

Read-access Geo Redundant Storage(RA-GRS)

當我們建立 Storage Account 的時候就需要指定其對應的儲存的相關型別和策略:

Performance 選專案前有兩種選擇,分別是 "Standard" 和 "Premium"。準確的說,下面的 Replication 選項才是 Storage Account 的冗餘策略。可是,冗餘策略和效能選項是有關聯性的。比如,當 performance 為 "Standard" 時,Replication 可以選擇 ZRS, LRS, GRS, RA-GRS:

而 performance 為 "Premium" 時,Replication 則只能選擇 LRS:

下面我們將詳細的介紹這四種冗餘策略及常見用例。

Locally Redundant Storage

本地冗餘儲存(LRS),在單個資料中心裡有多個同步的資料複製。資料在彈性儲存單元中被複制三次,該彈性儲存單元託管在建立儲存帳戶的區域中的資料中心內。 僅在寫入所有三個副本後,才成功返回寫入請求。 這三個副本駐留在同一彈性儲存單元中的不同容錯域和升級域中。

彈性儲存單元是儲存節點的機架的集合。 容錯域 (FD) 是一組代表出錯的物理單元的節點,可將其視為屬於同一物理機架的節點。 升級域 (UD) 是一組在服務升級(推出)過程中一起升級的節點。 三個副本將分佈在同一彈性儲存單元中的 UD 和 FD 上,以確保即使在硬體故障影響單個機架時,或在推出期間升級節點時,資料也可用。

當看到這裡時,相信你已經感受到了,即便是 Azure Storage 中最基礎的 LRS 資料冗餘策略也遠高於我們自己維護的系統了!
LRS 的優點是成本最低,這裡說的低是和其它型別的冗餘策略相比。並且可以提高訪問的效能,比如選擇performance 為 “Premium” 時只能使用 LRS 策略。
但是它的缺點也很明顯,就是無法應對整個資料中心都 crash 的情況(火災、洪災、地震、技術故障等)。

Zone Redundant Storage

區域冗餘儲存(ZRS),除了儲存類似於 LRS 的三個副本外,還在一個或兩個區域內的資料中心之間非同步複製資料,從而提供比 LRS 更高的安全性。 在這種情況下,即使主資料中心不可用或不可恢復,儲存在 ZRS 中的資料也安全的。

需要注意的是,ZRS 僅能應用於 blob 型別的儲存。

Geo Redundant Storage

異地冗餘儲存(GRS),將資料複製到距主區域數百英里以外的輔助區域。如果 Storage Account 啟用了 GRS,即使在遇到區域完全停電或導致主要區域不可恢復的災難時,使用者的資料也是安全的。

對於啟用了 GRS 的 Storage Account,更新將首先提交到主要區域,並在其中複製三份。
然後,更新將非同步複製到次要區域(也是在其中複製三份)。
使用 GRS 時,主要和次要區域在一個彈性儲存單元內管理跨單獨容錯域和升級域的副本。

GRS 是一種價效比很高的選擇,對資料安全要求較高的使用者可以選擇這種冗餘策略。比如我們在一個 web 應用中儲存了使用者上傳的資料(文件、圖片、影片等)。為了保護使用者的資料,我們可以把這些檔案存放在設定為 GRS 的儲存中。當主區域發生問題時,至少可以把使用者的資料恢復回來。下面是筆者維護的一個使用了 GRS 的專案:

次區域是系統自動設定的,不支援使用者自由選擇。其實我們都沒有必要知道它的存在,只需要知道資料是安全的就可以了。

Read-access Geo Redundant Storage

除了 GRS 所提供的在兩個區域之間進行復制外,讀取訪問異地冗餘儲存 (RA-GRS) 還提供對輔助位置中的資料的只讀訪問許可權,從而最大限度地提高了 Storage Account 的可用性。

當設定為 RA-GRS 時,除了 Storage Account 的主終結點外,還可以透過訪問輔助終結點獲取資料。輔助終結點與主終結點類似,但會在帳戶名稱後面追加字尾 –secondary。例如,如果 Blob 服務的主終結點是 myaccount.blob.core.windows.net,輔助終結點則是 myaccount-secondary.blob.core.windows.net。 Storage Account 的訪問金鑰對於主終結點和輔助終結點是相同的。

對於 RA-GRS, 看起來可能很高大上,但是我們卻很難把這種能力加以應用。按照 Azure文件所說,這種策略主要的目的是高可用性。但是使用者又不能自由的指定次區域的位置,所以十分懷疑是否可以達到真正的目的。

總結

資料的安全永遠都是相對的,片面的追求資料安全肯定會為我們帶來不可承受的成本壓力。我們能做的就是針對不同型別的資料,尋找價格上可以接受的冗餘方案。而 Azure Storage 提供的豐富選項,則給我們的選擇帶來了很大的靈活性。

相關文章