1. 容災設計需要進行故障切換的場景
容災設計過程當中需要考慮的故障切換的場景有很多，資料中心内部的高可用切換不在本次讨論範圍之内，我們讨論的是容災恢複過程中的關鍵跨資料中心級的故障切換場景，從網絡層到存儲層都會涉及到，其主要涉及如下幾個方面：
① 網絡層故障切換（路由、 DNS、交換機、負載均衡 ）。
② 應用服務計算層故障切換（應用 APP ） 。
③ 資料庫服務執行個體層故障切換（資料庫 Instance ）。
④ 資料副本層故障切換（資料副本）。
2. 網絡層的故障切換政策
2.1 網絡流量路徑分析
如圖所示，來自用戶端的流量通路會分為兩個過程：
1、用戶端需要擷取到業務系統的位址資訊。通過路由交換機找到域名解析裝置得到業務位址資訊。
2、用戶端利用擷取位址和應用服務端口與應用服務建立 Socket連接配接，然後互動通訊 。
2.2 域名解析層主中心故障場景切換政策
省略掉中間的交換機裝置資訊，我們将通常的 AA容災架構的網絡層抽象為上圖所示架構。
用戶端儲存兩個DNS位址，根據網絡線路的健康狀況，由用戶端作業系統選擇第一步位址請求的DNS伺服器位址，每個資料中心的DNS伺服器一般會通過HA方式來避免裝置的單點故障。同時DNS服務能夠實作智能動态解析，也就是說它可以根據負載均衡(LB)層的健康檢測資訊來判斷解析結果是主資料中心位址還是備資料中心位址。對于LB層與實體應用(APP)層的互動來講，一般是以資料中心為界劃分為兩個不同的LB資源池，互相不能在L2網絡層互動。
這裡大家可能有一個問題：
為什麼不把LB層規劃為一個大的資源池，增加資源選擇的靈活性（如下圖）？
其實從容災的角度來看，互相獨立的小叢集LB資源池和跨資料中心的大叢集LB在容災切換功能都是合格的，APP節點故障無論是在大叢集和小叢集架構下，都可以合理切換。但是如果建立跨中心的大叢集會增加對跨資料中心L2網絡的過度依賴(L2的打通、橫向流量的控制、ACK資料流的控制等)，增加網絡架構複雜度，而且LB之間的會話同步也無法得到像小叢集那樣的品質。 最關鍵的問題，這樣的架構導緻DNS或者LB提供的業務位址VIP隻有一個，對于同樣位址的資料請求，用戶端如何知道該走哪個路由？除非用戶端是網際網路用戶端或者也是隧道技術架構的一個節點。
接下如上圖，來看故障場景下的切換政策。
1、如果DNS層發生單邊功能不可用，容災切換機制是什麼？
這個故障可能是由單邊入口出口路由故障、單邊交換機故障、單邊DNS服務裝置層導緻，總而言之最終的結果就是用戶端到DNS位址不可達。那麼這個時候就需要用戶端作業系統自身的域名解析機制來進行動态切換，把DNS解析服務位址切換到備用側，導緻用戶端到DNS位址請求的資料量發生切換。
2、如果LB層發生單邊資源池功能不可用，容災切換機制是什麼？
這個故障可能是由單邊LB叢集服務節點、單邊資源池節點等因素導緻，總而言之最終的結果就是單邊LB叢集的業務VIP服務不可用。這個功能層故障資訊會回報給上層的DNS層（兩個資料中心的DNS），無論是由誰來解析，一定能探測到下層LB資源的健康狀況，那麼根據這個健康狀況來選擇将用戶端的業務請求指引到哪個資料中心，如果是LB層整體均健康，那麼會有兩種選擇1或者是2（如圖）。
這時候有一個新的問題： 如果是線路故障導緻左邊資料中心DNS不可用的情況，雖然LB-Cluster-1資源池是健康的，如果把資料流引入的話，網絡路徑照樣不可達，業務就中斷了，如何解決？ 這就要求 DNS功能層不僅僅與下邊的LB具有健康關聯的能力，同時還要具備與上層線路的健康關聯能力。綜合這兩類健康資訊才可以做出正确的判斷。
這個時候可能又有新的問題了： 那DNS直接解析為自己資料中心的LB資源池就可以了，幹嘛還要那麼複雜，将資料流指向左邊資料中心的LB資源池？ 如果是左邊的DNS和右邊的LB發生的交叉故障，及時其他功能層都完好，那麼也會面臨業務中斷，整體的高可用性就會大打折扣。
3. 應用服務層的故障切換政策
我們讨論的應用服務層是不帶任何業務資料、緩存、狀态資訊的應用節點層 。如果是緩存，可以作為資料層元素單獨讨論，如果是由會話資料或者狀态資料需要保持的情況，可以通過應用改造或者考慮緩存架構放在資料層考慮 。如果是這種前提下，那麼應用服務節點的故障就沒有必要讨論了，因為在LB層的切換已經解決了這個問題。接下來我們探讨如果是網際網路架構下跨資料中心叢集架構場景：
這種環境下的容災，在應用層就不必擔心會話、狀态、緩存資訊的保留了 。因為 APP服務節點采用多個的原因在于負載的分擔，容災切換完全可以通過APP在VM叢集内部進行漂移。當然這種容災政策的可行性還需要兩個前提條件：
① 資料中心之間的L2層的打通，目前隧道技術相對比較成熟。
② 資料層的雙副本或者多副本技術（如分布式存儲技術），畢竟狀态、會話、緩存也是資料。
4. 資料庫服務執行個體層的故障切換政策
4.1 AS資料庫服務模式
對于類似 Oracle DB模式的AS服務模式，那麼一般會有兩種切換方式: Failover and Swithover 。Failover 是指主庫發生故障暫時不能恢複的情況下，主備庫進行的主備切換；Switchover一般是指計劃内的維護事件所需，将主備庫角色切換，資料同步方向切換。容災故障場合下的恢複切換一般是指Failover，是以我們探讨的也是Failover的情況。
如圖所示，主庫對外服務位址 10.8.120.101，備庫對外服務位址10.8.130.101；兩個服務位址網絡L3可達即可，用戶端位址到兩個服務位址也是L3可達即可，切換之後備庫角色變為主庫。
① 切換過程：備庫->切換->主庫->檢查狀态，原主庫脫離DG架構；
② 應用場合：當主庫發生嚴重故障不可逆轉的時候可以使用 Failover；
③ RPO ：如果用最大性能模式或者最大高可用模式配置的 DG，極有可能丢失資料 。具體的 RPO要看網絡之間的傳輸品質和傳輸的重做日志多少等因素。是以建議人工幹預這種操作。
④ 網絡條件：L3可達。
⑤ 應用切換請求方法：DB 域名連接配接方式，動态切換解析位址；資料連接配接用戶端配置動态資料庫連接配接（例如 Oracle ）。
4.2 HA資料庫服務模式
所謂 HA資料庫服務模式是指通過作業系統HA軟體結合資料庫服務實作的容災架構，架構設計之初是為了實作各類應用服務的本地伺服器高可用，但雙活容災技術興起之後，也常常被用來作為近距離（百公裡内範圍）雙活容災的資料庫服務架構 。例如 IBM的HACMP與DB2、Oracle結合、例如HP Service Guard與Oracle結合等。
如圖所示，資料庫服務對外提供服務的位址隻有一個 VIP，是跨中心組成HA的兩個執行個體節點的虛拟位址，借助跨資料中心L2的網絡環境，VIP可以漂移到任何一個實體節點上。
當主中心資料庫服務執行個體DB-instanceA側發生故障（網卡、伺服器、SAN連接配接）時，根據HA的叢集仲裁規則，DB-instanceA可以擷取到的仲裁資源（網絡心跳、磁盤心跳）一定小于DB-instanceP，這個時候，叢集會發生AP切換，叢集執行以下動作讓DB-instanceP接管資料庫服務：
1、将虛拟VIP綁定到DB-instance-P的實體網卡；
2、将共享存儲卷從 DB-instanceA上解除安裝，并在DB-instanceP上挂載；
3、将共享存儲卷上的服務在DB-instanceP上啟動并激活對外提供服務。
注意：這3個步驟，尤其是2&3兩個步驟是需要一定切換時間T的（分鐘級），這意味着RTO不會為零，應用會産生一定的中斷，是以整個容災架構的RTO>T，這是需要在設計時充分考慮的。
4.3 AA資料庫服務模式
所謂 AA模式的資料庫服務就是以Oracle RAC、DB2 pureScale為代表的雙活叢集架構，同樣它們的設計初衷也是為了解決資料庫服務本地高可用的解決方案，後來衍生為Extended RAC之類的容災架構 。從架構本身來看，與 HA架構有些類似，差異的地方在于AA模式是兩邊的節點都是Active狀态，都可以進行讀寫，并發控制由緩存同步及鎖機制來協調。
如圖所示，資料庫服務對外提供服務的位址隻有一個 VIP，是跨中心組成叢集的兩個執行個體節點的虛拟位址，借助跨資料中心L2的網絡環境，互相之間可以交換緩存資訊、鎖資訊以，進而保障兩個執行個體均可以激活狀态進行資料的讀寫。
當主中心資料庫服務執行個體DB-instanceA側發生故障（網卡、伺服器、SAN連接配接）時，根據叢集的叢集仲裁規則，DB-instanceA可以擷取到的仲裁資源（網絡心跳、磁盤心跳）一定小于DB-instanceB，這個時候，叢集不會發生任何切換，隻是将DB-instanceA置為離線狀态，不再接受任何讀寫事務。所有向DB-instanceA請求的事務均被叢集分發給DB-instanceB，這個過程對應用是無感覺的。是以我們基本認為RTO為零。
5. 存儲層的故障切換政策
5.1 存儲網關服務模式
所謂存儲網關模式，我們在《企業容災選型指南- 2 ：企業容災的資料複制技術》當中介紹過， 就是在實體存儲層之上增加一層網關技術，用以形成存儲資源透明抽象層 ，形成虛拟存儲卷對外提供服務。根據實體引擎的服務方式不同，又分為 HA和AA工作模式兩種。
但是因為他們對外提供的服務是存儲服務，對資料服務層和應用層沒有任何影響，存儲服務連接配接的位址SAN環境識别的存儲卷的WWN，而這個WWN是可以通過Service Instance-1&2上面的Port同時以多鍊路的方式提供給上層資料服務層，是以存儲網關層的故障切換對上層是透明的。
如圖所示，在這個問題讨論的時候，我們不在分别說明 HA和AA兩種模式下的網關節點切換。因為本質上他們都一樣，隻是在緩存的處理和存儲卷的控制權限上的政策有一些差別：
HA模式：首先，服務節點上的IO緩存一般可以做到實時同步，如果不能實時同步或者同步不完全，那麼緩存會有一些丢失，隻是需要在Service Instance-2激活之後，系統需要做一些恢複工作（通過事務日志等手段）；然後，将虛拟卷的讀寫控制權交給Service Instance-2，當它成為虛拟卷的Owner之後，負責後續的IO，根據兩邊儲存設備的健康狀況選擇雙邊落盤或者是單邊落盤。
AA模式：這種模式下沒有任何所謂的網關節點切換，隻是所有本來由Service Instance-1服務的IO需要重新排隊到Service Instance-2，中間幾乎沒有中斷，因為兩個節點的緩存本來就是全局緩存，連個節點對虛拟卷的讀寫權限本來就是共享開放的。隻是原來需要分擔給Service Instance-1服務的部分IO，這個時候需要自己跨中心寫入到主中心的實體存儲上，當然如果主中心的實體存儲也發生了故障，那麼就隻好單邊落盤了。
5.2 通過存儲媒體塊複制實作資料複制
對于存儲存儲底層的塊兒複制技術來講， 它的資料複制是完全脫離了 上層的 應用層、系統層、資料庫層。主要是依靠存儲層兩個 實體儲存設備 來完成源到目标 裝置 的 Block 複制。适合遠距離的傳輸模式，一般用來做異地的資料級别容災，是以一旦發生主資料中心災難後，那麼需要網絡層、應用層、資料層等一系列人工幹預之後，才能啟用災備中心的存儲卷，這裡就不再詳述。