NOS跨分區災備設計與實現

本文來自網易雲社區

做者：王健

摘要

NOS（網易對象存儲）在實現多機房（杭州機房，北京機房等）部署後，容許一個用戶在建桶時選擇桶所屬機房。在此基礎上，咱們實現了跨機房的數據複製，進一步實現了跨機房的數據災備方案。用戶能夠：

1. 經過簡單的配置，便可讓本身上傳的數據異步準實時地同步到另外一個機房，實現跨機房的數據複製

2. 在發生重大災難致使整個機房沒法訪問時，能夠將桶的上傳下載操做切換到災備機房，極大提高服務可用性

3. 災備恢復服務切回主機房後，災備期間全部上傳到災備機房的數據都會同步回主機房，主機房有用戶全量的數據

4. 經過接入NOS的子服務NCDN和WanProxy，整個災備過程能夠對用戶徹底透明

本文主要討論NOS多機房部署、跨機房數據複製以及跨機房災備的設計與實現。

1. 多機房部署

NOS實現多機房部署的出發點有兩個：

1. 可讓用戶自主選擇將桶建立在哪一個機房（杭州機房，北京機房等）。用戶能夠根據本身服務器的地址就近選擇桶所屬機房，提升上傳下載速度；

2. 能夠進一步實現跨機房的數據災備，提升災難狀況下的系統可用性

NOS多機房部署圖以下所示：

如圖，兩個機房間除了極少許的信息（桶信息）須要同步外，各自都至關於一套獨立的NOS集羣。

多機房部署狀況下，CDN的回源地址也須要根據桶所屬的分區來進行配置，以下圖所示：

2. 跨機房數據複製

跨機房的數據複製是跨機房災備的基礎，經過實現數據的機房間冗餘，才能在一個機房故障時，將服務切到另外一個機房並繼續提供讀寫服務。

跨機房數據複製的核心設計以下圖：

基本邏輯是：

1. 當一個桶配置了跨分區災備的屬性後，該桶的全部更新操做，均會記錄在NOS_Sync表中（爲了保證主從分區數據的一致性，寫入NOS_Sync表必須同原更新操做放在一個事務中）

2. NosSyncer同步程序按期將NOS_Sync表中的數據讀出，進行聚合處理後，將數據同步到指定的分區

跨分區數據複製有一些問題值得討論：

1. 爲何選擇將同步信息放在數據庫中？
   其實，最初想到的辦法並非將同步信息寫到數據庫中，而是在更新操做完成後，記錄一條日誌，並經過日誌收集，日誌處理，處理結果上傳到隊列服務，再由NosSyncer從隊列服務中得到待同步的任務並執行數據複製。這種實現方式的好處是，整個數據同步的邏輯是離線的，線上的服務只須要輸出一條日誌便可，跨分區數據複製邏輯不會對當前的線上業務產生影響。
   而該方案有兩個明顯的問題：
   1）NOS支持覆蓋寫操做，例如兩個用戶能夠同時上傳一個名爲A的對象，後上傳成功的會覆蓋先上傳的。所以，同步信息的順序應該同實際插入的順序一致，才能保證同步到災備分區時也是一樣的操做順序，保證主從分區的數據一致性。而採用日誌這種方式，多個NOS服務器上的日誌收集順序是沒法保證前後的（即便日誌帶時間戳）。該問題能夠經過抓取binlog日誌來保證順序性。
   2）該方案須要依賴日誌收集，日誌處理，隊列等一系列外部的服務，須要的部署和運維精力較大。同時，在咱們設計該系統時，這些服務的可靠性還有待驗證，暫時不適用於咱們的服務。

2. 爲何將插入NOS_Sync表的操做同更新操做放在同一個事務裏？
   這主要是爲了保證全部的更新操做和NOS_Sync表中的同步信息一一對應，而同步信息按順序插入，同步程序只須要順序讀取同步信息並以此執行便可，這能夠保證複製操做的執行順序和實際更新順序一致。

3. 數據複製的邏輯能夠進行什麼優化？
   數據複製優化有兩個方向：1) 併發複製； 2）減小複製數據量；
   具體作法是，在取出一組同步信息後，首先在內存中對同步信息進行處理：
   1）過濾沒必要要的同步操做（例如：上傳A(file1)，上傳A(file2)，上傳A(file3) 能夠合併爲 上傳A(file3)）
   2）確認哪些操做能夠併發執行（例如：上傳A(file1)，上傳B（file2）直接能夠併發執行）
   在進行數據複製時，首先調用去重操做，若是能夠去重上傳，則不傳輸數據。

3. 跨機房數據災備

3.1. 災備狀況分析

從用戶的視角來看，NOS跨機房災備須要考慮上傳下載等多種狀況：

如圖：

1. 下行災備狀況一：用戶過CDN下載，災備時直接切換CDN回源地址，災備過程對客戶端透明（災備切換時間約5分鐘）

2. 下行災備狀況二：有邏輯的客戶端，在感知到主分區故障後，主動切換訪問到災備分區，災備過程須要客戶端配合

3. 下行災備狀況三：無邏輯的客戶端（如瀏覽器），若要災備則須要切換域名，因爲切換域名生效時間太久，線上基本不會操做

4. 上行災備狀況一：用戶過WanProxy進行上傳，災備時WanProxy自動將上傳切換到災備機房，災備過程對用戶透明

5. 上行災備狀況2、狀況三：客戶端依賴產品的上傳服務器來進行上傳，當發生災備時，須要上傳服務器切換（或通知用戶切換）上傳地址，災備過程須要上傳服務器配合

基於以上的討論，咱們將來推薦的方式將是，客戶端經過WanProxy進行上傳，經過CDN進行下載，將災備的邏輯通通交給NOS來作。

3.2. 災備切換

災備切換邏輯以下：

如圖，涉及災備的主要是兩個數據庫字段：

1. 災備分區 —— 主機房發生災難時服務切到哪裏，正常狀態下，數據從主機房複製到災備機房

2. 是否切換 —— 主機房發生災難時，經過該字段設置主備切換

3.3. 使用建議

若是用戶對本身的數據有極高的可用性要求，能夠嘗試開啓災備服務，此處有幾個建議：

1. 因爲硬件條件限制（機房間無專線，數據傳輸走公網），所以不建議對大對象（如視頻）實施災備服務。

2. 用戶能夠將本身的數據按照重要程度放在多個桶中（如視頻，圖片，重要文件等），並對最重要的桶開啓災備服務，保證災難狀態時能夠提供最基本的服務。

3. 逐漸將產品的上傳切到WanProxy上傳服務，將下載切到NCDN服務，從而透明地實現跨機房災備。

網易雲對象存儲服務NOS 支持標準 RESTful API 接口，並提供豐富的數據在線處理服務，一站式解決互聯網時代非結構化數據管理難題。

網易雲免費體驗館，0成本體驗20+款雲產品！

更多網易研發、產品、運營經驗分享請訪問網易雲社區。

相關文章：
【推薦】 網易雲安全DDoS高防全新上線 ，遊戲防禦實力領先