NOS跨分割槽災備設計與實現
本文來自網易雲社群
作者：王健
摘要
NOS（網易物件儲存）在實現多機房（杭州機房，北京機房等）部署後，允許一個使用者在建桶時選擇桶所屬機房。在此基礎上，我們實現了跨機房的資料複製，進一步實現了跨機房的資料災備方案。使用者可以：
-
通過簡單的配置，即可讓自己上傳的資料非同步準實時地同步到另一個機房，實現跨機房的資料複製
-
在發生重大災難導致整個機房無法訪問時，可以將桶的上傳下載操作切換到災備機房，極大提升服務可用性
-
災備恢復服務切回主機房後，災備期間所有上傳到災備機房的資料都會同步回主機房，主機房有使用者全量的資料
-
通過接入NOS的子服務NCDN和WanProxy，整個災備過程可以對使用者完全透明
本文主要討論NOS多機房部署、跨機房資料複製以及跨機房災備的設計與實現。
1. 多機房部署
NOS實現多機房部署的出發點有兩個：
-
可以讓使用者自主選擇將桶建立在哪個機房（杭州機房，北京機房等）。使用者可以根據自己伺服器的地址就近選擇桶所屬機房，提高上傳下載速度；
-
可以進一步實現跨機房的資料災備，提高災難情況下的系統可用性
NOS多機房部署圖如下所示：
如圖，兩個機房間除了極少量的資訊（桶資訊）需要同步外，各自都相當於一套獨立的NOS叢集。
多機房部署情況下，CDN的回源地址也需要根據桶所屬的分割槽來進行配置，如下圖所示：
2. 跨機房資料複製
跨機房的資料複製是跨機房災備的基礎，通過實現資料的機房間冗餘，才能在一個機房故障時，將服務切到另一個機房並繼續提供讀寫服務。
跨機房資料複製的核心設計如下圖：
基本邏輯是：
-
當一個桶配置了跨分割槽災備的屬性後，該桶的所有更新操作，均會記錄在NOS_Sync表中（為了保證主從分割槽資料的一致性，寫入NOS_Sync表必須同原更新操作放在一個事務中）
-
NosSyncer同步程式定期將NOS_Sync表中的資料讀出，進行聚合處理後，將資料同步到指定的分割槽
跨分割槽資料複製有一些問題值得討論：
-
為什麼選擇將同步資訊放在資料庫中？
其實，最初想到的辦法並不是將同步資訊寫到資料庫中，而是在更新操作完成後，記錄一條日誌，並通過日誌收集，日誌處理，處理結果上傳到佇列服務，再由NosSyncer從佇列服務中獲得待同步的任務並執行資料複製。這種實現方式的好處是，整個資料同步的邏輯是離線的，線上的服務只需要輸出一條日誌即可，跨分割槽資料複製邏輯不會對當前的線上業務產生影響。
而該方案有兩個明顯的問題：
1）NOS支援覆蓋寫操作，例如兩個使用者可以同時上傳一個名為A的物件，後上傳成功的會覆蓋先上傳的。因此，同步資訊的順序應該同實際插入的順序一致，才能保證同步到災備分割槽時也是同樣的操作順序，保證主從分割槽的資料一致性。而採用日誌這種方式，多個NOS伺服器上的日誌收集順序是無法保證先後的（即使日誌帶時間戳）。該問題可以通過抓取binlog日誌來保證順序性。
2）該方案需要依賴日誌收集，日誌處理，佇列等一系列外部的服務，需要的部署和運維精力較大。同時，在我們設計該系統時，這些服務的可靠性還有待驗證，暫時不適用於我們的服務。 -
為什麼將插入NOS_Sync表的操作同更新操作放在同一個事務裡？
這主要是為了保證所有的更新操作和NOS_Sync表中的同步資訊一一對應，而同步資訊按順序插入，同步程式只需要順序讀取同步資訊並以此執行即可，這可以保證複製操作的執行順序和實際更新順序一致。 -
資料複製的邏輯可以進行什麼優化？
資料複製優化有兩個方向：1) 併發複製； 2）減少複製資料量；
具體做法是，在取出一組同步資訊後，首先在記憶體中對同步資訊進行處理：
1）過濾不必要的同步操作（例如：上傳A(file1)，上傳A(file2)，上傳A(file3) 可以合併為 上傳A(file3)）
2）確認哪些操作可以併發執行（例如：上傳A(file1)，上傳B（file2）直接可以併發執行）
在進行資料複製時，首先呼叫去重操作，如果可以去重上傳，則不傳輸資料。
3. 跨機房資料災備
3.1. 災備情況分析
從使用者的視角來看，NOS跨機房災備需要考慮上傳下載等多種情況：
如圖：
-
下行災備情況一：使用者過CDN下載，災備時直接切換CDN回源地址，災備過程對客戶端透明（災備切換時間約5分鐘）
-
下行災備情況二：有邏輯的客戶端，在感知到主分割槽故障後，主動切換訪問到災備分割槽，災備過程需要客戶端配合
-
下行災備情況三：無邏輯的客戶端（如瀏覽器），若要災備則需要切換域名，由於切換域名生效時間過久，線上基本不會操作
-
上行災備情況一：使用者過WanProxy進行上傳，災備時WanProxy自動將上傳切換到災備機房，災備過程對使用者透明
-
上行災備情況二、情況三：客戶端依賴產品的上傳伺服器來進行上傳，當發生災備時，需要上傳伺服器切換（或通知使用者切換）上傳地址，災備過程需要上傳伺服器配合
基於以上的討論，我們未來推薦的方式將是，客戶端通過WanProxy進行上傳，通過CDN進行下載，將災備的邏輯統統交給NOS來做。
3.2. 災備切換
災備切換邏輯如下：
如圖，涉及災備的主要是兩個資料庫欄位：
-
災備分割槽 —— 主機房發生災難時服務切到哪裡，正常狀態下，資料從主機房複製到災備機房
-
是否切換 —— 主機房發生災難時，通過該欄位設定主備切換
3.3. 使用建議
如果使用者對自己的資料有極高的可用性要求，可以嘗試開啟災備服務，此處有幾個建議：
-
由於硬體條件限制（機房間無專線，資料傳輸走公網），因此不建議對大物件（如視訊）實施災備服務。
-
使用者可以將自己的資料按照重要程度放在多個桶中（如視訊，圖片，重要檔案等），並對最重要的桶開啟災備服務，保證災難狀態時可以提供最基本的服務。
-
逐漸將產品的上傳切到WanProxy上傳服務，將下載切到NCDN服務，從而透明地實現跨機房災備。
網易雲物件儲存服務NOS 支援標準 RESTful API 介面，並提供豐富的資料線上處理服務，一站式解決網際網路時代非結構化資料管理難題。
相關文章：
【推薦】 收集、分析線上日誌資料實戰——ELK