數據容災

數據備份系統只能保證實際上被安全復制了一份，如果生產系統故障，必須將備份數據盡快的恢復到生產系統中繼續生產，就叫容災。

容災可以分為四個級別：

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

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

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

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

概述

如果要充分保證數據的安全，只是在本地做備份是不夠的，所以需要在遠程建另一個系統，並包含當前生產系統的全部數據，這個系統須

• 要保證主生產系統的數據實時

  的傳輸到遠程備份系統上。

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

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

那麽容災就是我們有兩部手機，而且他們的數據是使用雲實時同步的，所以可以無縫切換。

如果我們預算充足，可以使用一直兩臺手機，那還需要備份嗎？當然需要，比如某個時刻，我們把手機裏面的某個聯系人給誤刪了，因為容災的手機是實時同步的，很難說能通過另一部手機找回來。但是如果之前有備份過數據，完全可以通過之前的備份進行恢復。

下面繼續談容災。對於一個企業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傳輸方式，接入到用戶端的時候，一般將信號調制成E1、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：每個節點都有自己的數據拷貝，若損壞，可切換到另外的節點，不影響應用，不停機。修復後的節點可以重新加入容災系統。

• 軟硬成本

  • 共享：需要外接磁盤陣列，為了保證數據訪問速度，必須自身實現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軟件來執行腳本，或者調用相應的接口來啟動備份機的應用的。

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