詳解容災(zāi)恢復(fù)過程中跨數(shù)據(jù)中心級的關(guān)鍵故障切換

1.容災(zāi)設(shè)計需要進行故障切換的場景容災(zāi)設(shè)計過程當(dāng)中需要考慮的故障切換的場景有很多，數(shù)據(jù)中心內(nèi)部的高可用切換不在本次討論范圍之內(nèi)，我們討論的是容災(zāi)恢復(fù)過程中的關(guān)鍵跨數(shù)據(jù)中心級的故障切換場景，從網(wǎng)絡(luò)層到存儲層都會涉及到，其主要涉及如下幾個方面：①網(wǎng)絡(luò)層故障切換（路由、DNS、交換機、負(fù)載均衡）。②應(yīng)用服務(wù)計算層故障切換（應(yīng)用APP）。③數(shù)據(jù)庫服務(wù)實例層故障切換（數(shù)據(jù)庫Instance）。④數(shù)據(jù)副本層故障切換（數(shù)據(jù)副本）。2.網(wǎng)絡(luò)層的故障切換策略2.1網(wǎng)絡(luò)流量路徑分析如圖所示，來自客戶端的流量訪問會分為兩個過程：1、客戶端需要獲取到業(yè)務(wù)系統(tǒng)的地址信息。通過路由交換機找到域名解析設(shè)備得到業(yè)務(wù)地址信息。2、客戶端利用獲取地址和應(yīng)用服務(wù)端口與應(yīng)用服務(wù)建立Socket連接，然后交互通訊。2.2域名解析層主中心故障場景切換策略省略掉中間的交換機設(shè)備信息，我們將通常的AA容災(zāi)架構(gòu)的網(wǎng)絡(luò)層抽象為上圖所示框架?？蛻舳吮４鎯蓚€DNS地址，根據(jù)網(wǎng)絡(luò)線路的健康狀況，由客戶端操作系統(tǒng)選擇第一步地址請求的DNS服務(wù)器地址，每個數(shù)據(jù)中心的DNS服務(wù)器一般會通過HA方式來避免設(shè)備的單點故障。同時DNS服務(wù)能夠?qū)崿F(xiàn)智能動態(tài)解析，也就是說它可以根據(jù)負(fù)載均衡(LB)層的健康檢測信息來判斷解析結(jié)果是主數(shù)據(jù)中心地址還是備數(shù)據(jù)中心地址。對于LB層與物理應(yīng)用(APP)層的交互來講，一般是以數(shù)據(jù)中心為界劃分為兩個不同的LB資源池，相互不能在L2網(wǎng)絡(luò)層交互。這里大家可能有一個問題：為什么不把LB層規(guī)劃為一個大的資源池，增加資源選擇的靈活性（如下圖）？其實從容災(zāi)的角度來看，相互獨立的小集群LB資源池和跨數(shù)據(jù)中心的大集群LB在容災(zāi)切換功能都是合格的，APP節(jié)點故障無論是在大集群和小集群架構(gòu)下，都可以合理切換。但是如果建立跨中心的大集群會增加對跨數(shù)據(jù)中心L2網(wǎng)絡(luò)的過度依賴(L2的打通、橫向流量的控制、ACK數(shù)據(jù)流的控制等)，增加網(wǎng)絡(luò)架構(gòu)復(fù)雜度，而且LB之間的會話同步也無法得到像小集群那樣的質(zhì)量。

最關(guān)鍵的問題，這樣的架構(gòu)導(dǎo)致DNS或者LB提供的業(yè)務(wù)地址VIP只有一個，對于同樣地址的數(shù)據(jù)請求，客戶端如何知道該走哪個路由？除非客戶端是互聯(lián)網(wǎng)客戶端或者也是隧道技術(shù)框架的一個節(jié)點。接下如上圖，來看故障場景下的切換策略。1、如果DNS層發(fā)生單邊功能不可用，容災(zāi)切換機制是什么？這個故障可能是由單邊入口出口路由故障、單邊交換機故障、單邊DNS服務(wù)設(shè)備層導(dǎo)致，總而言之最終的結(jié)果就是客戶端到DNS地址不可達。那么這個時候就需要客戶端操作系統(tǒng)自身的域名解析機制來進行動態(tài)切換，把DNS解析服務(wù)地址切換到備用側(cè)，導(dǎo)致客戶端到DNS地址請求的數(shù)據(jù)量發(fā)生切換。2、如果LB層發(fā)生單邊資源池功能不可用，容災(zāi)切換機制是什么？這個故障可能是由單邊LB集群服務(wù)節(jié)點、單邊資源池節(jié)點等因素導(dǎo)致，總而言之最終的結(jié)果就是單邊LB集群的業(yè)務(wù)VIP服務(wù)不可用。這個功能層故障信息會反饋給上層的DNS層（兩個數(shù)據(jù)中心的DNS），無論是由誰來解析，一定能探測到下層LB資源的健康狀況，那么根據(jù)這個健康狀況來選擇將客戶端的業(yè)務(wù)請求指引到哪個數(shù)據(jù)中心，如果是LB層整體均健康，那么會有兩種選擇1或者是2（如圖）。這時候有一個新的問題：

如果是線路故障導(dǎo)致左邊數(shù)據(jù)中心DNS不可用的情況，雖然LB-Cluster-1資源池是健康的，如果把數(shù)據(jù)流引入的話，網(wǎng)絡(luò)路徑照樣不可達，業(yè)務(wù)就中斷了，如何解決？

這就要求DNS功能層不僅僅與下邊的LB具有健康聯(lián)動的能力，同時還要具備與上層線路的健康聯(lián)動能力。綜合這兩類健康信息才可以做出正確的判斷。這個時候可能又有新的問題了：

那DNS直接解析為自己數(shù)據(jù)中心的LB資源池就可以了，干嘛還要那么復(fù)雜，將數(shù)據(jù)流指向左邊數(shù)據(jù)中心的LB資源池？

如果是左邊的DNS和右邊的LB發(fā)生的交叉故障，及時其他功能層都完好，那么也會面臨業(yè)務(wù)中斷，整體的高可用性就會大打折扣。3.應(yīng)用服務(wù)層的故障切換策略我們討論的應(yīng)用服務(wù)層是不帶任何業(yè)務(wù)數(shù)據(jù)、緩存、狀態(tài)信息的應(yīng)用節(jié)點層。如果是緩存，可以作為數(shù)據(jù)層元素單獨討論，如果是由會話數(shù)據(jù)或者狀態(tài)數(shù)據(jù)需要保持的情況，可以通過應(yīng)用改造或者考慮緩存架構(gòu)放在數(shù)據(jù)層考慮。如果是這種前提下，那么應(yīng)用服務(wù)節(jié)點的故障就沒有必要討論了，因為在LB層的切換已經(jīng)解決了這個問題。接下來我們探討如果是互聯(lián)網(wǎng)架構(gòu)下跨數(shù)據(jù)中心集群架構(gòu)場景：這種環(huán)境下的容災(zāi)，在應(yīng)用層就不必?fù)?dān)心會話、狀態(tài)、緩存信息的保留了。因為APP服務(wù)節(jié)點采用多個的原因在于負(fù)載的分擔(dān)，容災(zāi)切換完全可以通過APP在VM集群內(nèi)部進行漂移。當(dāng)然這種容災(zāi)策略的可行性還需要兩個前提條件：①數(shù)據(jù)中心之間的L2層的打通，目前隧道技術(shù)相對比較成熟。②數(shù)據(jù)層的雙副本或者多副本技術(shù)（如分布式存儲技術(shù)），畢竟?fàn)顟B(tài)、會話、緩存也是數(shù)據(jù)。4.數(shù)據(jù)庫服務(wù)實例層的故障切換策略4.1AS數(shù)據(jù)庫服務(wù)模式對于類似OracleDB模式的AS服務(wù)模式，那么一般會有兩種切換方式:FailoverandSwithover。Failover是指主庫發(fā)生故障暫時不能恢復(fù)的情況下，主備庫進行的主備切換；Switchover一般是指計劃內(nèi)的維護事件所需，將主備庫角色切換，數(shù)據(jù)同步方向切換。容災(zāi)故障場合下的恢復(fù)切換一般是指Failover，因此我們探討的也是Failover的情況。如圖所示，主庫對外服務(wù)地址10.8.120.101，備庫對外服務(wù)地址10.8.130.101；兩個服務(wù)地址網(wǎng)絡(luò)L3可達即可，客戶端地址到兩個服務(wù)地址也是L3可達即可，切換之后備庫角色變?yōu)橹鲙?。①切換過程：備庫->切換->主庫->檢查狀態(tài)，原主庫脫離DG架構(gòu)；②應(yīng)用場合：當(dāng)主庫發(fā)生嚴(yán)重故障不可逆轉(zhuǎn)的時候可以使用Failover；③RPO：如果用最大性能模式或者最大高可用模式配置的DG，極有可能丟失數(shù)據(jù)。具體的RPO要看網(wǎng)絡(luò)之間的傳輸質(zhì)量和傳輸?shù)闹刈鋈罩径嗌俚纫蛩亍Ｒ虼私ㄗh人工干預(yù)這種操作。④網(wǎng)絡(luò)條件：L3可達。⑤應(yīng)用切換請求方法：DB域名連接方式，動態(tài)切換解析地址；數(shù)據(jù)連接客戶端配置動態(tài)數(shù)據(jù)庫連接（例如Oracle）。4.2HA數(shù)據(jù)庫服務(wù)模式所謂HA數(shù)據(jù)庫服務(wù)模式是指通過操作系統(tǒng)HA軟件結(jié)合數(shù)據(jù)庫服務(wù)實現(xiàn)的容災(zāi)架構(gòu)，架構(gòu)設(shè)計之初是為了實現(xiàn)各類應(yīng)用服務(wù)的本地服務(wù)器高可用，但雙活容災(zāi)技術(shù)興起之后，也常常被用來作為近距離（百公里內(nèi)范圍）雙活容災(zāi)的數(shù)據(jù)庫服務(wù)架構(gòu)。例如IBM的HACMP與DB2、Oracle結(jié)合、例如HPServiceGuard與Oracle結(jié)合等。如圖所示，數(shù)據(jù)庫服務(wù)對外提供服務(wù)的地址只有一個VIP，是跨中心組成HA的兩個實例節(jié)點的虛擬地址，借助跨數(shù)據(jù)中心L2的網(wǎng)絡(luò)環(huán)境，VIP可以漂移到任何一個物理節(jié)點上。當(dāng)主中心數(shù)據(jù)庫服務(wù)實例DB-instanceA側(cè)發(fā)生故障（網(wǎng)卡、服務(wù)器、SAN連接）時，根據(jù)HA的集群仲裁規(guī)則，DB-instanceA可以獲取到的仲裁資源（網(wǎng)絡(luò)心跳、磁盤心跳）一定小于DB-instanceP，這個時候，集群會發(fā)生AP切換，集群執(zhí)行以下動作讓DB-instanceP接管數(shù)據(jù)庫服務(wù)：1、將虛擬VIP綁定到DB-instance-P的物理網(wǎng)卡；2、將共享存儲卷從DB-instanceA上卸載，并在DB-instanceP上掛載；3、將共享存儲卷上的服務(wù)在DB-instanceP上啟動并激活對外提供服務(wù)。注意：這3個步驟，尤其是2&3兩個步驟是需要一定切換時間T的（分鐘級），這意味著RTO不會為零，應(yīng)用會產(chǎn)生一定的中斷，因此整個容災(zāi)架構(gòu)的RTO>T，這是需要在設(shè)計時充分考慮的。4.3AA數(shù)據(jù)庫服務(wù)模式所謂AA模式的數(shù)據(jù)庫服務(wù)就是以O(shè)racleRAC、DB2pureScale為代表的雙活集群架構(gòu)，同樣它們的設(shè)計初衷也是為了解決數(shù)據(jù)庫服務(wù)本地高可用的解決方案，后來衍生為ExtendedRAC之類的容災(zāi)架構(gòu)。從架構(gòu)本身來看，與HA架構(gòu)有些類似，差異的地方在于AA模式是兩邊的節(jié)點都是Active狀態(tài)，都可以進行讀寫，并發(fā)控制由緩存同步及鎖機制來協(xié)調(diào)。如圖所示，數(shù)據(jù)庫服務(wù)對外提供服務(wù)的地址只有一個VIP，是跨中心組成集群的兩個實例節(jié)點的虛擬地址，借助跨數(shù)據(jù)中心L2的網(wǎng)絡(luò)環(huán)境，相互之間可以交換緩存信息、鎖信息以，從而保障兩個實例均可以激活狀態(tài)進行數(shù)據(jù)的讀寫。當(dāng)主中心數(shù)據(jù)庫服務(wù)實例DB-instanceA側(cè)發(fā)生故障（網(wǎng)卡、服務(wù)器、SAN連接）時，根據(jù)集群的集群仲裁規(guī)則，DB-instanceA可以獲取到的仲裁資源（網(wǎng)絡(luò)心跳、磁盤心跳）一定小于DB-instanceB，這個時候，集群不會發(fā)生任何切換，只是將DB-instanceA置為離線狀態(tài)，不再接受任何讀寫事務(wù)。所有向DB-instanceA請求的事務(wù)均被集群分發(fā)給DB-instanceB，這個過程對應(yīng)用是無感知的。因此我們基本認(rèn)為RTO為零。5.存儲層的故障切換策略5.1存儲網(wǎng)關(guān)服務(wù)模式所謂存儲網(wǎng)關(guān)模式，我們在《企業(yè)容災(zāi)選型指南-2：企業(yè)容災(zāi)的數(shù)據(jù)復(fù)制技術(shù)》當(dāng)中介紹過，就是在物理存儲層之上增加一層網(wǎng)關(guān)技術(shù)，用以形成存儲資源透明抽象層，形成虛擬存儲卷對外提供服務(wù)。根據(jù)物理引擎的服務(wù)方式不同，又分為HA和AA工作模式兩種。但是因為他們對外提供的服務(wù)是存儲服務(wù)，對數(shù)據(jù)服務(wù)層和應(yīng)用層沒有任何影響，存儲服務(wù)連接的地址SAN環(huán)境識別的存儲卷的WWN，而這個WWN是可以通過ServiceInstance-1&2上面的Port同時以多鏈路的方式提供給上層數(shù)據(jù)服務(wù)層，因此存儲網(wǎng)關(guān)層的故障切換對上層是透明的。如圖所示，在這個問題討論的時候，我們不在分別說明HA和AA兩種模式下的網(wǎng)關(guān)節(jié)點切換。因為本質(zhì)上他們都一樣，只是在緩存的處理和存儲卷的控制權(quán)限上的策略有一些區(qū)別：HA模式：首先，服務(wù)節(jié)點上的IO緩存一般可以做到實時同步，如果不能實時同步或者同步不完全，那么緩存會有一些丟失，只是需要在ServiceInstance-2激活之后，系統(tǒng)需要做一些恢復(fù)工作（通過事務(wù)日志等手段）；然后，將虛擬卷的讀寫控制權(quán)交給ServiceInstance-2，當(dāng)它成為虛擬卷的Owner之后，負(fù)責(zé)后續(xù)的IO，根據(jù)兩邊存儲設(shè)備的健康狀況選擇雙邊落盤或者是單邊落盤。AA模式：這種模式下沒有任何所謂的網(wǎng)關(guān)節(jié)點切換，只是所有本來由ServiceInstance-1服務(wù)的IO需要重新排隊到ServiceInstance-2，中間幾乎沒有中斷，因為兩個節(jié)點的緩存本來就是全局緩存，連個節(jié)點對虛擬卷的讀寫權(quán)限本來就是共享開放的。只是原來需要分擔(dān)給ServiceInstance-1服務(wù)的部分IO，這個時候需要自己跨中心寫入到主中心的