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

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

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

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

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

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

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