【大話存儲】學習筆記（17章），數據容災

數據容災

數據備份系統只能保證明際上被安全複製了一份，若是生產系統故障，必須將備份數據儘快的恢復到生產系統中繼續生產，就叫容災。

容災能夠分爲四個級別：

• 數據級容災：只是將生產站點的數據同步到遠端。

• 與應用結合的數據級容災：保證對應應用數據一致性。

• 應用級容災：須要保證災難發生之後，須要保證原生成系統中的應用系統在災備站點可用。

• 業務級容災：除了保證數據、應用系統在災備站點可用，還要保證整個企業的業務系統仍對外可用，是最終層次的容災。

概述

若是要充分保證數據的安全，只是在本地作備份是不夠的，因此須要在遠程建另外一個系統，幷包含當前生產系統的所有數據，這個系統須

• 要保證主生產系統的數據實時的傳輸到遠程備份系統上。

• 主故障後，必須將應用程序切換到遠程備份系統上。

那麼備份和容災有什麼區別呢？生產系統就比如手機，備份就是把手機上的數據備份到電腦上，可是若是這個手機壞了呢？要恢復數據須要大量的時間。

那麼容災就是咱們有兩部手機，並且他們的數據是使用雲實時同步的，因此能夠無縫切換。

若是咱們預算充足，可使用一直兩臺手機，那還須要備份嗎？固然須要，好比某個時刻，咱們把手機裏面的某個聯繫人給誤刪了，由於容災的手機是實時同步的，很難說能經過另外一部手機找回來。可是若是以前有備份過數據，徹底能夠經過以前的備份進行恢復。

下面繼續談容災。對於一個企業IT生產系統，主要有4個組件：

• 生產資料：原始數據

• 生產工具：服務器等基礎架構

• 生產者：業務應用程序

• 產品：對外提供的服務信息

下面將對這四大組件的容災進行講解

生產資料容災

生產資源容災指的就是對原始數據進行容災。這最重要的，由於沒有生產資料一切等於從頭再來。
要設計這樣一套生產資料容災，須要注意的是

• 要把變化的實時同步到備用系統，方法是

  • 將某時刻的數據傳送到備用系統

  • 將此時候後變化數據同步到備用系統

  • 這樣就作了一次同步了，以後只須要在數據變化之後才把變化的數據傳送到備用系統。

• 數據必須至少保留額外一份。在容災的同時還須要數據備份（避免誤刪等邏輯錯誤）

以下爲相應的拓撲：

主備站點都有相同的生產工具，使用網絡相連。能夠經過兩種方式來進行同步：

• 經過前端網絡進行同步

• 經過後端SAN網絡進行同步。

經過前端網絡同步

• 經過路由器鏈接到專線或者Internet

• 變化的數據經過路由器傳送到備站點的路由器上。

• 經過交換機傳到備服務器上，寫入磁盤陣列

那麼到底選擇專線仍是Internet呢？專線能夠保證數據同步的實時性，可是不適合大數量的傳輸。若是實時性要求不高，並且數據量大的時候，能夠將主備站點接入100Mbps的Internet。

能夠看出這種方式通過了前端網絡，因此必須在每臺須要備份的服務器上安裝軟件進行同步，這種軟件能夠監視目錄中的數據變化，而後與遠端的軟件進行通訊，寫入相同的文件目錄中。

這種方式的同步通常都是文件級的同步，對底層卷的數據塊變化不作同步。

案例：DB2數據的HADR組件容災

DB2數據庫利用主備上的數據庫軟件模塊（HADR）來實現兩端的數據同步。並且同步的是不捲上的原始數據，而是對數據操做的描述，也就是日誌。這樣的好處是，不須要傳輸數據，備份機收到日誌之後，在備機的磁盤上重作操做便可。

HADR:High Availability Disaster Recovery，是數據庫級別的高可用性數據複製機制。須要兩臺數據庫服務器：primary , standby

• 當主數據庫發生事務性操做，將日誌經過TCP/IP傳送到備數據庫，而後備機對日誌文件進行重放Replay，從而保持數據的一致性。

• 當主數據庫故障，備機能夠接管主數據庫，而客戶端應用程序的數據庫鏈接能夠經過自動客戶端從新路由（Automatic Client Reroute）轉移到新的主服務器。

• 當原來的主數據庫服務器修復了，做爲新的備用數據庫加入HADR。

須要注意的是處於備用角色的數據庫不能被訪問。

經過後端網絡實現同步

經過後端網絡進行同步，數據不會流經前端網絡，而所有經過後端網絡傳輸到備份的存儲上。因此須要將主站點和備站點的後端網絡設施鏈接起來。要麼直接拉光纖，要麼用專線。

若是用專線的話，須要增長額外的協議轉換設備，如今電信部門的光纖專線通常爲SDH傳輸方式，接入到用戶端的時候，通常將信號調製成E一、OC3等編碼方式。

上圖中，FC協議，通過FCIP網關，變成基於以太網的IP協議，（FC over IP over ETH）。通過E1/以太網轉換器，承載到了E1協議上，而後多路E1信號匯聚到光端機，經過一條或者多條光纖，傳輸給電信部門的SDH交換設施進行傳輸。

這樣咱們就將主站點和備站點的後端網絡打通了，此時主服務器就能夠訪問到備份的磁盤陣列，也就是說主站點的服務器能夠同時操做本地磁盤和備站點的磁盤陣列了。

咱們來看一下這種方式的路徑：

本地磁盤+SAN交換——本地服務器內存——SAN網絡交換——電信部門網絡——遠端SAN網絡交換——遠端磁盤陣列

數據到了遠端SAN不須要再通過服務器，由於有了對方存儲設備的直接訪問權。可是整個過程當中，仍然至少須要一臺服務器，服務器上須要安裝一個軟件，能夠將數據從本地卷A提取出來，而後直接經過SAN網絡寫到位於備份站點的卷B上。

可是試想一下，若是數據直接在內存中生成的，那麼同時在A和B上各寫一份，速度豈不是更快，這種方式又叫「卷鏡像」，由於能夠時時刻刻保持兩個卷徹底相同，它能保證數據同步的實時性，可是不適合大規模遠距離的數據同步。

同時還須要注意的是，卷鏡像的的同步軟件工做在卷這一層，能夠感知數據塊的變化，而不是文件的變化。缺點在於對網絡速度要求更高，因此成本也更高。

經過數據存儲設備實現同步

以前講的經過前端網絡和經過後端網絡的方式，都使用了一個泵來提供動力。而若是將數據同步軟件安裝在存儲設備上，豈不是更省事。並且這樣完全解放了服務器，全部工做都由磁盤陣列完成。

這種方式的同步，不會識別捲上的文件系統，因此同步的是塊。並且要求主和備的存儲設備型號一致。由於不一樣廠家的產品沒法實現直接同步。

這種方法的缺點是不能保證數據對應用程序的可用性。

由於存儲設備與應用程序之間還有操做系統這一層，操做系統也有本身的緩存機制，全部有可能形成數據的不一致性。

總結：

• 使用前端網絡進行同步，路徑最長，可是成本也最低。

• 使用後端網絡進行同步，實時性強，可是對後端鏈路要求也高。不適合於數據量多的時候。

• 使用存儲設備直接進行同步，路徑最短，不佔用服務器。可是仍然不適合於遠距離低速鏈路環境。並且還不能數據對應用程序的可用性。

容災中數據的同步複製和異步複製

同步複製

下圖是基於存儲設備的自主同步環境。

• 主向磁盤發出IO請求，向某LBA寫入數據，待寫數據入緩存，此時控制器不會給主的HBA驅動程序發送成功

• 主磁盤陣列將變化的數據從緩存中寫入LUN A，此時主的數據同步引擎感知，將變化的數據塊從緩存中經過SAN交換機發送到備的緩存中。

• 備磁盤陣列運行的同步引擎接收到數據後，在FC協議隱式的發一個ACK或者經過上層顯試的發給主站點

• 主收到應答，向服務器發一個FC協議的隱式ACK。服務器上的FC HBA驅動程序探測成功。

  若備站點遲遲未收到數據，則不會返回成功，應用程序會等待。若是此時應用程序使用的是同步IO，則相關進程會掛起，稱爲IO等待。

  因此同步複製的特色是主站點必須等待備份站點的成功信號，保持嚴格的同步，一榮俱榮，一損俱損。

異步複製

相對於同步複製，兩邊的步調不須要一致，要保證重要的事情先作完，因此會存在必定的數據不一致。

• 主向磁盤發出IO請求，待寫數據進入控制器緩存，若是此時

  • 主控制器設置爲Write Back模式：則馬上返回應答。

  • 主控制器設置爲Write Through模式，則先寫入LUN A之後，再返回ACK。

• 主站點將數據經過SAN網絡發送到備站點的緩存。

• 備站點磁盤成功接收，則返回成功。

生產者容災——應用程序容災

以前講的都是生產資料的容災，也就是整個系統最重要的數據的容災。而對於生產者，無疑就是服務器上的應用程序，若是主發生故障，須要在備站點從新運行這些應用程序。最直觀的想法是，在備站點預備應用程序的安裝文件，必定主出現故障，在備上配置這些應用程序，可是實際上應用程序安裝和配置須要大量的時間。因此能夠將備份站點預裝應用程序，可是不工做，這樣就可保證同一時刻整個IT系統只有一個站點的生產者處理一份數據

既要求處理同一份數據，又要求發生事故的時候，備份站點的生產者當即啓動，要作到這點，須要讓備份站點的應用程序感知到主站點的應用程序狀態，一旦發現故障，當即啓動開始生產。

在以前的章節中，咱們說到了高可用羣集，在容災系統領域，羣集的範圍擴大到了異地，主備可能相隔很遠，交換運行狀態的數據量很小，最好使用專線，這樣能夠很好的保證QoS。

傳統的HA軟件是使用共享存儲的方式來做用的，即在HA系統中，共享一份物理存儲，無論誰來操做這份數據，最終只有一份，並且是一致，有上下文邏輯關係的。

因此HA軟件是基於資源切換的，把組件看做是資源，好比應用、IP地址、存儲卷等。
當故障時，

• 備份機HA軟件會檢測到對方的故障，

• 而後強行將資源遷移到本地，好比在備份機上修改網卡的IP地址，併發出ARP廣播來刷新全部廣播域的客戶端以及網關的ARP記錄

• 掛載共享存儲設備上的卷，

• 最後啓動備份應用系統。

這樣應用系統能夠訪問共享卷，客戶端也可使用原來的IP地址來訪問服務器，這樣生產就能夠繼續下去。

可是在異地容災系統中，主備站點各有一份數據，因此必須保證數據的同步。這也是爲何兩個站點同時只有一個在工做，這樣的話才能以一邊數據爲準，另外一邊與之同步。

本地容災

本地HA系統中，多個節點若是共同擁有同一個卷，可是同一時刻只有一個節點能掛載它，這種模式叫共享存儲模式

與之對應的是Share-Nothing模式，每一個節點都有本身獨佔的存儲卷，怎麼進行數據共享呢？能夠經過同步複製技術同步到全部節點上。若某節點發生故障，這個節點對應的備份節點啓動應用程序。由於以前的數據已經同步過了，因此數據必定是一致的。

在Share-Nothing模式下，不存在任何的接管問題，因此客戶端須要感知服務端羣集這種切換動做，經過客戶端進行配置的切換便可。

能夠對共享存儲和Share-Nothing兩種存儲模式進行對比。

	共享存儲	Share-Nothing
數據自己是否容災	×	√
軟硬件成本	高	低
前端網絡資源消耗	低	高
管理難度	高	低
維護數據是否須要停機	√	×
實現的複雜度	高	低
是否須要第三方軟件	√	×
故障因素數量	3個	2個

• 數據自己是否容災

  • 共享存儲：數據損壞，必須使用鏡像進行還原。並且要停機。

  • Share-Nothing：每一個節點都有本身的數據拷貝，若損壞，可切換到另外的節點，不影響應用，不停機。修復後的節點能夠從新加入容災系統。

• 軟硬成本

  • 共享：須要外接磁盤陣列，爲了保證數據訪問速度，必須自身實現RAID，主機也須要安裝適配器。成本高。須要HA軟件

  • Share-Nothing:各個節點各自保存數據，不須要外接存儲系統，不須要額外的HA軟件

• 前端網絡耗費

  • 共享存儲：前端只須要交互控制信息，資源耗費較小。

  • Share-Nothing:數據同步靠前端，對資源消耗很大。
• 管理難度：

  • 共享：須要管理節點間的交互配置，還須要管理外部存儲，增長了管理難度

  • Share-Nothing:只須要管理節點配置。
• 是否停機

  • 共享：須要將數據從單機轉移到共享存儲供其餘節點使用，須要停機來保證一致性。

  • Share-Nothing：數據同步是動態的，不須要停機。
• 實現複雜度

  • 共享存儲：有三種基本元素：節點、節點間的交互、共享數據。若是使用共享存儲模式作容災，須要將數據移動到共享存儲上，增長額外的工做量和不可控因素

  • Share-Nothing：只有兩種元素 節點&節點交互
• 第三方

  • 共享存儲：備份節點須要經過HA軟件來監控主節點的狀態，發生故障的時候自動接管，如MSCS

  • share-Nothing：不須要第三方軟件參與
• 故障因素

  • 共享存儲：OS、應用程序、HA軟件

  • Share-nothing：OS、應用程序

異地容災

若是主站點和備站點不在同一個機房中，這樣備份應用程序須要跨越很遠的距離來與主程序交互狀態。只是說這種交互包很小，不須要擔憂延時的問題。

IP切換

在異地容災系統，主服務器和備服務器不大可能在同一個廣播域，因此須要經過網關來轉發IP包，正由於此不能用資源切換的方式來切換IP地址。

若是想故障後，客戶端繼續使用原來的IP地址鏈接備份服務器，那麼能夠在路由上作文章。動態修改路由器上的路由表，將IP包路由到備份站點而不是主站點。若是利用域名來訪問服務器，那麼能夠直接在DNS設備上修改IP指向記錄來實現。

卷切換

異地容災系統在主站點和備站點各有卷，兩個卷經過前端或者後端網絡進行同步。

若是備的HA軟件檢測到主站點通訊失敗，經過某種方式，斷開同步關係（若不斷開，卷會被鎖定而不可訪問）。而後就是從新掛載備站點的卷

此時同步引擎能夠是運行在存儲設備上，也能夠由HA來執行。

• 若是同步引擎是運行在存儲設備上的，必須由管理員手動利用存儲設備的配置工具來斷開同步關係。斷開了之後，本地的卷才能夠被訪問，而後HA軟件能夠在備份機上調用操做系統相關功能來掛載這個卷。

• 若是同步引擎原本就是HA來執行的，那麼HA軟件能夠自動斷開同步關係，在備份機上掛載對應的卷。

異地容災的應用切換

應用，也就是生產者的切換，是全部HA容災系統在故障發生後所執行的最後一步。與共享存儲式的HA容災同樣，異地容災的應用切換，是有備機的HA軟件來執行腳本，或者調用相應的接口來啓動備份機的應用的。