云時代下雙活零切換實現(xiàn)與架構(gòu)設(shè)計

1、云時代下雙活零切換實現(xiàn)與架構(gòu)設(shè)計一、項目背景為了更好的保障業(yè)務(wù)系統(tǒng)運行，提高服務(wù)質(zhì)量，我們先后建立了高可用保障手段、應(yīng)急容災(zāi)系統(tǒng)等保護(hù)機制，但仍存在如下矛盾，并越來越突出：投資大，效益慢：如今年某系統(tǒng)擴(kuò)容需要約XXXX萬TPCC，XXXT存儲設(shè)備，需要同步對容災(zāi)系統(tǒng)擴(kuò)容。災(zāi)備端平時無法打開：災(zāi)備端的資源（尤其是存儲）平時無法打開使用，造成資源浪費嚴(yán)重。切換時間長：一般需要12小時以上才能起來。故障情況下切換決策難：有時切換時間決策時間災(zāi)難修復(fù)時間，難以決策，期間無法辦理業(yè)務(wù)。難以找到RTO、RPO都為0的0切換方案。流程復(fù)雜，維護(hù)難：系統(tǒng)切換需要一系列管理和技術(shù)流程，維護(hù)復(fù)雜，生產(chǎn)、容災(zāi)端都需

2、要維護(hù)。無法做到在線的系統(tǒng)升級遷移和新業(yè)務(wù)上線。這種情況下，我們急需探索在核心系統(tǒng)中引入容災(zāi)系統(tǒng)雙活零切換技術(shù)，基于如下考慮：可以從降低運行風(fēng)險、提高客戶滿意度等方面提升業(yè)務(wù)運營水平?？梢詮慕档蜆I(yè)務(wù)停機窗口、降低維護(hù)工作量等方面降低系統(tǒng)運維壓力。可以降低系統(tǒng)災(zāi)難處理壓力、最大限度降低業(yè)務(wù)中斷時間，從而提高客戶滿意度。使容災(zāi)側(cè)資源平時可用，達(dá)到雙活。降低演練測試的業(yè)務(wù)停頓窗口，提升演練質(zhì)量。（一）現(xiàn)有容災(zāi)系統(tǒng)架構(gòu)分析從系統(tǒng)架構(gòu)上看，容災(zāi)方案主要存在如下三種形式：主備模式、雙中心互備模式、雙活并行模式，而目前各省采用的前兩種形式，RTO均不為0，容災(zāi)端平時不可用，需要技術(shù)、流程保證切換，而雙活并行

3、模式，理論上在災(zāi)難發(fā)生時不影響業(yè)務(wù)，可以做到”0”切換。 主備模式：在一個中心部署生產(chǎn)系統(tǒng)，另一個中心部署備份容災(zāi)系統(tǒng)，通過存儲復(fù)制或邏輯復(fù)制手機實現(xiàn)保護(hù)，實現(xiàn)冷備切換，這種情況一般采取存儲底層的srdf、pprc復(fù)制技術(shù)，平時容災(zāi)端資源不成在對外應(yīng)用，數(shù)據(jù)庫不能打開，再出現(xiàn)故障時需要執(zhí)行定位、切換決策并執(zhí)行切換流程，故障恢復(fù)時間指標(biāo)RTO至少在半小時，故障恢復(fù)點指標(biāo)RTO可以根據(jù)采用的技術(shù)不同等于0或接近0。雙中心互備模式：在兩個中心機房各自部署一部分應(yīng)用，既部署生產(chǎn)又部署容災(zāi)，互為容災(zāi)備份機制，具體每個系統(tǒng)實現(xiàn)機制同主備模式，可以說是主備模式的擴(kuò)展，是為了解決容災(zāi)端資源閑置的臨時性方案，生

4、產(chǎn)和容災(zāi)同步技術(shù)和主備完全相同，計算資源可以通過虛擬化技術(shù)實現(xiàn)生產(chǎn)和容災(zāi)共享來節(jié)約資源，RTO、RPO指標(biāo)同主備模式。雙活并行模式：一種全新的容災(zāi)模式，相同系統(tǒng)在兩個中心均能打開使用，承載對外服務(wù)，任何一邊壞掉不影響業(yè)務(wù)，災(zāi)難情況下可以不需要決策和執(zhí)行切換，可以實現(xiàn)RTO接近0。（二）現(xiàn)有技術(shù)分析為研究雙活架構(gòu)，2015年根據(jù)總部統(tǒng)一部署和規(guī)劃，多個省份成立聯(lián)合項目組，結(jié)合CRM應(yīng)急保障體系，試點研究最優(yōu)的雙活技術(shù)架構(gòu)。方案1：基于數(shù)據(jù)邏輯復(fù)制軟件，如dsg、gg、shareplex、觸發(fā)器等。方案2：基于數(shù)據(jù)庫自身，如Oracle active Dataguard。方案3：基于遠(yuǎn)程卷管理軟件

5、（主機虛擬化），如賽門鐵克、卷管理、Oracle ASM等。方案4：基于存儲虛擬化設(shè)備（SAN虛擬化），如emc vplex，IBM svc，華為vis等。方案5：基于存儲自身（存儲虛擬化），如HDS、HP等（剛發(fā)布）。方案6：基于存儲HA機制，如IBM powerswap，日立HA等。二、方案分層介紹和傳統(tǒng)主備方式不同，實現(xiàn)雙活需要整個系統(tǒng)架構(gòu)做改造，即接入層、應(yīng)用層、數(shù)據(jù)層、基礎(chǔ)架構(gòu)層等分別考慮：接入層：需要借助DNS、全局負(fù)載均衡等技術(shù)實現(xiàn)雙活接入和智能路由，流量調(diào)配。應(yīng)用層：基于互聯(lián)網(wǎng)化能力開放分布式集群架構(gòu)，采用ebus服務(wù)總線技術(shù)對外統(tǒng)一接入。數(shù)據(jù)層：需要構(gòu)建雙中心同時可讀寫的機制

6、，例如Oracle Extend RAC?；A(chǔ)架構(gòu)層：網(wǎng)絡(luò)上對穩(wěn)定性和帶寬吞吐性能要求更高，甚至需要打通跨中心的二層網(wǎng)絡(luò)。存儲方面，則需改變一主一備的讀寫機制，實現(xiàn)同時可讀寫。下面各層進(jìn)行仔細(xì)介紹。（一）數(shù)據(jù)層1、雙活技術(shù)架構(gòu)數(shù)據(jù)庫層雙活部署目前業(yè)界主要有三種方式：A/S（Active-Standby）方式，Oracle RAC集群實（Active-Active）方式和通過第三方數(shù)據(jù)復(fù)制軟件方式。1）Active-Standby方式：基于Oracle ADG技術(shù)，采用從主庫向備庫傳輸redo日志方式，備庫恢復(fù)數(shù)據(jù)過程可以用只讀方式打開進(jìn)行查詢操作，實現(xiàn)了部分雙活功能，在主節(jié)點故障后可以將備節(jié)點

7、切為主節(jié)點，平實備節(jié)點可以提供只讀操作。2）Active-Active方式：通過Oracle Extend RAC實現(xiàn)多個集群節(jié)點同時對外提供業(yè)務(wù)訪問。該方式做到故障無縫切換，提升應(yīng)用系統(tǒng)整體性能。3）數(shù)據(jù)復(fù)制軟件方式：通過實時抽取在線日志中的數(shù)據(jù)變化信息，然后，通過網(wǎng)絡(luò)將變化信息投遞到目標(biāo)端，最后在目標(biāo)端還原數(shù)據(jù)，從而實現(xiàn)源和目標(biāo)的數(shù)據(jù)同步。2、基于數(shù)據(jù)庫-ORACLE ADG技術(shù)特點：通過網(wǎng)絡(luò)從生產(chǎn)向容災(zāi)傳輸歸檔或redo日志，容災(zāi)端恢復(fù)方式同步數(shù)據(jù)。Oracle 11g以后容災(zāi)庫可打開為只讀模式，容災(zāi)切換時能快速alter為讀寫狀態(tài)。該方式數(shù)據(jù)同步效率較高，對硬件資源要求低，支持可以線性

8、擴(kuò)展而不對生產(chǎn)系統(tǒng)造成影響，且底層存儲支持異構(gòu)，正常情況兩邊數(shù)據(jù)延遲不大。一般啟用場景：1）作為應(yīng)急或容災(zāi)：只有生產(chǎn)側(cè)可以讀寫，容災(zāi)側(cè)只讀，雙活讀，非雙活讀寫。按照測試，數(shù)據(jù)庫切換時間在30S左右。2）作為讀寫分離機制：分?jǐn)偵a(chǎn)端壓力，降低生產(chǎn)負(fù)載。只讀查詢業(yè)務(wù)分離（ADG側(cè)平時運行從生產(chǎn)庫遷移過來的查詢業(yè)務(wù)）數(shù)據(jù)庫備份（使用RMAN進(jìn)行全備和歸檔備份到帶庫）經(jīng)分?jǐn)?shù)據(jù)實時抽?。ó?dāng)前通過BCV抽取非實時數(shù)據(jù)）DB變更前數(shù)據(jù)庫快照備份（大版本升級時同步到BCV工作）承載BCV庫功能，可下線BCV庫，釋放高端存儲給生產(chǎn)使用3）作為數(shù)據(jù)保護(hù)手段：如在ADG庫上啟用Flash DB特性，需要時可以執(zhí)行閃

9、回，以恢復(fù)誤操作等導(dǎo)致的生產(chǎn)庫上的數(shù)據(jù)丟失。技術(shù)特征：通過dsg、goldengate等邏輯復(fù)制技術(shù)實現(xiàn)跨中心數(shù)據(jù)庫的相互復(fù)制，共同提供對外服務(wù)，互為備份。支持跨異構(gòu)環(huán)境，對系統(tǒng)負(fù)載影響很低，對交易型數(shù)據(jù)做實時抓取、路由、轉(zhuǎn)換和傳遞支持多線程，提供旁路順流模式，不影響生產(chǎn)庫性能其中：兩個數(shù)據(jù)中心各建一套數(shù)據(jù)庫，物理獨立基于數(shù)據(jù)庫日志準(zhǔn)實時復(fù)制數(shù)據(jù)ROWID映射表機制（對應(yīng)源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫的數(shù)據(jù)記錄），通過ROWID來實現(xiàn)記錄的定為，在數(shù)據(jù)裝載效率方面有提升需手工干預(yù)故障3、對于ADG和數(shù)據(jù)復(fù)制雙活方案對比4、基于OracleExtended RAC雙活架構(gòu)技術(shù)特征：Oracle Exten

10、ded RAC以跨中心共享存儲為基礎(chǔ)，通過共享存儲資源和Oracle Clusterware數(shù)據(jù)庫集群管理，實現(xiàn)各個中心節(jié)點對數(shù)據(jù)庫并行訪問。共享存儲可以采用存儲自身數(shù)據(jù)復(fù)制技術(shù)，存儲虛擬網(wǎng)關(guān)或遠(yuǎn)程卷管理等技術(shù)，下圖是采用的Oracle ASM存儲管理，實現(xiàn)數(shù)據(jù)的雙向?qū)崟r復(fù)制。ASM支持對本地磁盤的優(yōu)先讀取，避免跨數(shù)據(jù)中心的數(shù)據(jù)讀取，從而提高I/O性能并減少網(wǎng)絡(luò)流量；關(guān)鍵實施要點：兩個數(shù)據(jù)中心分別部署一套存儲，各提供一套LUN設(shè)備給全部數(shù)據(jù)庫主機。存儲的SAN網(wǎng)絡(luò)和RAC心跳網(wǎng)絡(luò)需使用低延遲、高帶寬的DWDM光纖鏈路。配置ASM磁盤組。每個磁盤組配置兩個失效組，每個失效組對應(yīng)來自一套存儲的LU

11、N設(shè)備。在第三個站點部署用于RAC的第3個投票盤，使用NFS的方式掛載到所有數(shù)據(jù)庫主機。與管理普通的RAC系統(tǒng)類似，需要重點加強對站點間光纖鏈路情況的監(jiān)控與應(yīng)急。一般啟用場景：由于在兩個數(shù)據(jù)中心部署了兩套存儲和主機設(shè)備，因此能夠提供對數(shù)據(jù)中心級別故障的全方位容災(zāi)，比如停電、地震等。出現(xiàn)故障時恢復(fù)時間極短，理論上可以達(dá)到RTO和RPO為零。作為同城容災(zāi)的解決方案，并具有最高效的資源使用率。5、內(nèi)存數(shù)據(jù)庫雙活技術(shù)實現(xiàn)技術(shù)特征：將數(shù)據(jù)常駐在內(nèi)存中直接操作的數(shù)據(jù)庫。相對于磁盤，內(nèi)存的數(shù)據(jù)讀寫速度要高出幾個數(shù)量級，將數(shù)據(jù)保存在內(nèi)存中相比從磁盤上訪問能夠極大地提高應(yīng)用的性能，目前在BOSS系統(tǒng)內(nèi)存庫已被廣

12、泛用于實時計費，主要廠商有Oracle Times Ten，Altibase等。內(nèi)存庫集群部署主要有HA主備模式，雙活模式，線性拆分和分布式集群四種模式。1）HA模式：在兩個數(shù)據(jù)中心，備庫只讀，具備故障轉(zhuǎn)移和容災(zāi)備份功能。主備之間日志同步或異步同步，數(shù)據(jù)同步延遲比較嚴(yán)重。適合物理庫較小，內(nèi)存容量不大非關(guān)鍵業(yè)務(wù)場景擴(kuò)展性差2）雙活模式：兩套內(nèi)存庫部署在兩個數(shù)據(jù)中心，支持雙讀寫，具備故障轉(zhuǎn)移和容災(zāi)備份功能。數(shù)據(jù)庫之間基于日志采用同步或異步相互同步，但相互之間數(shù)據(jù)同步存在沖突問題，造成數(shù)據(jù)不一致問題。3）線性拆分模式：針對物理庫較大，受內(nèi)存容量限制問題，在HA基礎(chǔ)上將物理庫按地市或業(yè)務(wù)線性拆分成多套

13、內(nèi)存庫，所有內(nèi)存庫支持同時分片讀寫，客戶端請求都通過前端統(tǒng)一接口路由進(jìn)行分發(fā)和處理。主備間基于日志同步或異步同步；系統(tǒng)擴(kuò)展性較強，但維護(hù)難度較大；支持不同地市或業(yè)務(wù)雙活讀寫。4）分布式集群模式：采用分布式內(nèi)存庫，基于x86分布式集群部署，如：思特奇iDMDB。主備庫基于日志同步或異步同步支持雙活讀寫（前提數(shù)據(jù)層和存儲層實現(xiàn)雙活）支持分布式自動加載和路由能力數(shù)據(jù)自動冗余，RPO=0支持在線擴(kuò)展，路由自動調(diào)整，便于維護(hù)。開放化，標(biāo)準(zhǔn)化，支持sql92，ODBC,JDBC等6、雙活技術(shù)優(yōu)缺點比較（注：應(yīng)根據(jù)實際情況選擇合適的方案，只有Extended RAC為真正的雙讀雙寫）（二）存儲層1、雙活技術(shù)

14、架構(gòu)存儲層作為整個系統(tǒng)核心基礎(chǔ)架構(gòu)平臺，其雙活技術(shù)在整個架構(gòu)中起到關(guān)鍵作用，目前基于存儲層雙活方案主要有下面三種：基于遠(yuǎn)程卷管理軟件的虛擬化，如：Symantec SF，IBM LVM等基于存儲網(wǎng)關(guān)虛擬化，如：EMC vplex， IBM SVC基于存儲自身卷鏡像技術(shù)，HDS GAD1）卷管理軟件虛擬化：通過安裝在主機上卷管理軟件的邏輯卷鏡像技術(shù)實現(xiàn)底層數(shù)據(jù)邏輯同步。2）存儲網(wǎng)關(guān)虛擬化：在每個站點新增存儲虛擬化網(wǎng)關(guān)設(shè)備組成跨站點集群，并對存儲卷進(jìn)重新行封裝，對外提供主機I/O訪問。3）存儲卷鏡像技術(shù)：將兩套磁盤陣列組成一個集群，兩臺存儲上的LUN被虛擬化為一個虛擬卷，主機寫操作通過卷虛擬化鏡像

15、技術(shù)同時寫入兩個數(shù)據(jù)中心的存儲設(shè)備，保證站點之間數(shù)據(jù)實時同步。 2、基于遠(yuǎn)程卷管理軟件技術(shù)特征：數(shù)據(jù)同步：底層數(shù)據(jù)復(fù)制采用遠(yuǎn)程卷管理軟件，如賽門鐵克的Torage Foundation（SF）、IBM的GPFS等，通過邏輯卷鏡像技術(shù)實現(xiàn)底層數(shù)據(jù)邏輯同步。上層應(yīng)用采用Oracle Extended RAC方案實現(xiàn)遠(yuǎn)程4節(jié)點RAC,使生產(chǎn)和容災(zāi)節(jié)點都處于在線狀態(tài)，應(yīng)用邏輯訪問的是同一個數(shù)據(jù)庫。數(shù)據(jù)讀寫：支持雙讀寫。數(shù)據(jù)一致性：完全一致。遠(yuǎn)程卷管理軟件改造前后變化：改造前： 主機只需識別當(dāng)前中心存儲可使用任意卷管理軟件如LVM、ASM等正常狀態(tài)下容災(zāi)存儲只讀IO讀寫都訪問本地存儲，數(shù)據(jù)復(fù)制由存儲底層

16、完成改造后：主機需識別當(dāng)前中心存儲和遠(yuǎn)端存儲只能使用SF的卷管理軟件兩地存儲都為讀寫狀態(tài)數(shù)據(jù)復(fù)制由主機卷鏡像完成，寫IO以遠(yuǎn)端寫確認(rèn)為準(zhǔn)，讀IO優(yōu)先本地存儲3、案例分析某省方案：IBM GPFS+Oracle 11g應(yīng)用情況：測試了接近一年，2013年在客服資料數(shù)據(jù)庫上線，基于gpfs+oracle 11g rac。效果：容災(zāi)端資源平時可以對外服務(wù)或查詢，無需專門切換步驟，故障時只需要檢查即可。（注：容災(zāi)端數(shù)據(jù)庫實例也可以作為統(tǒng)計分析庫）前提條件：一、跨數(shù)據(jù)中心大二層網(wǎng)路建立，二、完善的仲裁機制，第三中心最好，建議環(huán)狀雙平面的網(wǎng)絡(luò)架構(gòu)，三、中心間需要高帶寬，否則會影響性能。缺點：架構(gòu)更加復(fù)雜；

17、san網(wǎng)絡(luò)復(fù)雜；軟件兼容性考慮很多；RTO=3分鐘。實現(xiàn)要點：網(wǎng)絡(luò)改造：需要打通兩個中心間大二層網(wǎng)絡(luò)。底層存儲鏈路改造：需要認(rèn)到對端機房存儲，帶寬要求高。卷管理軟件改造：從現(xiàn)有主機自帶LVM遷移到遠(yuǎn)程卷管理Oracle extended RAC搭建提供可靠性較高的二層網(wǎng)絡(luò)（心跳網(wǎng)絡(luò)）提供可靠性較高的共享存儲（投票盤）對底層鏈路和距離要求高：距離太遠(yuǎn)會導(dǎo)致響應(yīng)變慢，官方建議50KM之內(nèi)。使用場景：容災(zāi)演練時不需要進(jìn)行數(shù)據(jù)庫的切換，只需應(yīng)用切換，甚至不用切換?？煞?jǐn)偖?dāng)前生產(chǎn)端壓力，降低生產(chǎn)負(fù)載按業(yè)務(wù)梳理進(jìn)行壓力分?jǐn)倲?shù)據(jù)庫備份只需要在單中心進(jìn)行備份經(jīng)分?jǐn)?shù)據(jù)可實時從生產(chǎn)抽?。ㄍㄟ^BCV抽取非實時數(shù)據(jù)）

18、提升系統(tǒng)硬件冗余度，提升了系統(tǒng)高可用能力4、基于存儲網(wǎng)關(guān)虛擬化技術(shù)特征：實現(xiàn)原理：將存儲虛擬化技術(shù)（EMC的vplex）和Oracle的遠(yuǎn)程rac技術(shù)結(jié)合，實現(xiàn)跨中心的數(shù)據(jù)雙活訪問?？缰行牡膬蓚€存儲虛擬成一個對外訪問，內(nèi)部實時同步，保持?jǐn)?shù)據(jù)的一致性，平時兩邊主機分別訪問本地存儲，故障情況下可跨中心訪問對方存儲。5、基于存儲虛擬化設(shè)備VPLEX存儲管理機制：VPLEX對存儲卷進(jìn)行封裝后，讓主機的I/O通過VPLEX來訪問存儲。封裝后的VPLEX卷只是指針集，所有數(shù)據(jù)的訪問還是通過這個指針指到后端存儲上，原來存儲上的卷的各種屬性都不會改變原先存儲卷所具有的各種屬性，比如raid保護(hù)，快照、克隆等在

19、存儲內(nèi)的各種設(shè)置對VPLEX透明，VPLEX不感知也不干涉。被VPLEX接管了的存儲卷只能通過VPLEX訪問，不能再直接map給其他主機。對于同一個數(shù)據(jù)塊的讀寫沖突機制，是由RAC來保證的。同步中斷后所有數(shù)據(jù)改變信息都會記錄在保持活動的VPLEX一端的log卷中，只要log卷不滿，就不會發(fā)生全同步，都是增量同步；VPLEX在設(shè)置的時候會配置log卷，確保不論多長時間都不會發(fā)生全同步的。具備腦裂預(yù)防服務(wù)器“witness”： witness是VPLEX的仲裁裝置；IBM、華為等也有類似VPLEX的存儲網(wǎng)關(guān)實現(xiàn)方式，原理有些差異，但因為應(yīng)用較少，不再介紹。案例：某省基于存儲網(wǎng)關(guān)虛擬化通過VPLEX

20、虛擬化技術(shù)實現(xiàn)存儲及數(shù)據(jù)的雙活，在兩個數(shù)據(jù)中心同為生產(chǎn)并服務(wù)于不同主機，實現(xiàn)雙活雙中心架構(gòu)通過Oracle跨站點集群技術(shù)提高應(yīng)用層面的業(yè)務(wù)連續(xù)性，實現(xiàn)應(yīng)用及業(yè)務(wù)的雙活兩站點主機各自使用本地存儲資源，確保性能和效率，提高資源利用率雙中心心跳網(wǎng)要單獨組網(wǎng)，防止腦烈6、基于存儲HA機制未有應(yīng)用案例，目前有IBM的powerHA HyperSwap、日立的HAM技術(shù)等，原理基本一樣。技術(shù)特征：需要采用IBM或日立高端存儲設(shè)備，利用其虛擬化軟件。主機實現(xiàn)兩邊并發(fā)對外訪問，就近原則，存儲有一端需要遠(yuǎn)程讀寫，效率較低。上層需要結(jié)合Oracle遠(yuǎn)程rac實現(xiàn)雙活7、基于存儲自身卷鏡像目前還未有應(yīng)用案例，HDS

21、/HP/ Huawei OceanStor V3等剛剛發(fā)布不久，完全基于存儲自身卷鏡像實現(xiàn)。技術(shù)特征：不需要額外軟硬件，需要采用特定高端存儲設(shè)備，如VSP、XP7以上才可以。存儲架構(gòu)沒有改變，易于實行。兩邊存儲可以同時讀寫。上層需要結(jié)合Oracle遠(yuǎn)程rac實現(xiàn)雙活8、雙活方案綜合分析（注：整體看紅色為最優(yōu)方案，但要根據(jù)各省實際情況選擇，上述方案均需要Extenmd RAC支持）（三）接入層1、基于DNS+全局負(fù)載均衡雙活架構(gòu)建設(shè)背景：隨著對訪問質(zhì)量和用戶感知的提升，對支撐系統(tǒng)穩(wěn)定性和業(yè)務(wù)連續(xù)性提出更高要求，從數(shù)據(jù)級容災(zāi)升級到應(yīng)用級容災(zāi)，如何減少應(yīng)用層數(shù)據(jù)中心切換時間，降低RT0-基于DNS+

22、全局負(fù)載均衡保障（GSLB）應(yīng)用層雙活保障架構(gòu)。應(yīng)用級雙活：當(dāng)單數(shù)據(jù)中心出現(xiàn)故障時，可以將請求引導(dǎo)向另一個可用的數(shù)據(jù)中心，實現(xiàn)雙活高可用。智能流量控制：GSLB根據(jù)后端服務(wù)器負(fù)載和鏈路狀況實現(xiàn)不同站點間流量調(diào)配，鏈路優(yōu)選，保證用戶訪問最佳性能服務(wù)器，確保訪問質(zhì)量，提升用戶感知。關(guān)鍵技術(shù)方案：面向應(yīng)用的智能流量控制互聯(lián)網(wǎng)業(yè)務(wù)多中心并行運行內(nèi)網(wǎng)基于IP地址發(fā)布的業(yè)務(wù)多中心并行突發(fā)業(yè)務(wù)流量處理應(yīng)用交付設(shè)備集群部署應(yīng)用優(yōu)化和安全應(yīng)用加速優(yōu)化數(shù)據(jù)庫快速復(fù)制七層DDoS和應(yīng)用層攻擊防護(hù)自動化運營一鍵備份數(shù)據(jù)庫的一鍵切換1）互聯(lián)網(wǎng)業(yè)務(wù)多中心并行模式：通過一組GSLB來對外提供服務(wù)，GSLB監(jiān)控服務(wù)的狀態(tài)，并

23、通知組內(nèi)其他設(shè)備，對于每一個DNS請求返回最佳結(jié)果，好的策略選擇和配置方式可以最大幅度提高客戶體驗。2）內(nèi)部業(yè)務(wù)多中心互備模式：對于內(nèi)網(wǎng)業(yè)務(wù)通過一組GSLB來提供服務(wù)，實現(xiàn)DNS解析，負(fù)載分發(fā)和故障切換。優(yōu)點：易于控制，可實現(xiàn)多種流量分布模型，主備、主主或者分應(yīng)用主備等模型維護(hù)方便，自成系統(tǒng)，與其他設(shè)備松耦合可根據(jù)地理位置分布、網(wǎng)絡(luò)距離或者應(yīng)用繁忙程度動態(tài)調(diào)配缺點：應(yīng)用必須采用DNS方式進(jìn)行訪問切換時間相對較長（取決于TTL時間），通常用于互聯(lián)網(wǎng)應(yīng)用5-10分鐘，內(nèi)網(wǎng)應(yīng)用30-60秒（四）應(yīng)用層1、應(yīng)用層設(shè)計雙活需要從接入、應(yīng)用層、數(shù)據(jù)連接等層面考慮實現(xiàn)，才能實現(xiàn)“零”切換。1）建議構(gòu)建統(tǒng)一管

24、理的接口層或采用服務(wù)總線技術(shù)：現(xiàn)狀：系統(tǒng)使用的協(xié)議眾多。難以做到每個對外服務(wù)接口均支持高可用性，無法實現(xiàn)對外服務(wù)的零切換容災(zāi)。網(wǎng)上營業(yè)廳、WAP使用 CICS協(xié)議；短信、VC、銀行等使用SOCKET協(xié)議；IVR、自助終端使用EASYCICS協(xié)議；一級BOSS 使用HTTPXML協(xié)議。 對此，需要做的是：建設(shè)統(tǒng)一的對外應(yīng)用接口平臺，或使用SOA架構(gòu)負(fù)責(zé)應(yīng)用路由/服務(wù)指向、對外/對內(nèi)接口協(xié)議的封裝和適配功能建議采用多實例負(fù)載均衡的部署模式，在多個服務(wù)器間分擔(dān)系統(tǒng)壓力建議實施時在各個中心建設(shè)適當(dāng)數(shù)量的服務(wù)器和網(wǎng)絡(luò)鏈路冗余，實現(xiàn)系統(tǒng)容災(zāi)的無縫切換2）實現(xiàn)應(yīng)用自動重連機制，確保自動切換，減少人工切換。3

25、）采用全局負(fù)載均衡、DNS等技術(shù)實現(xiàn)靈活接入。4）建議雙中心部署相同的應(yīng)用集群方式。我們的項目背景和方案中的各個分層，那么下篇就云化下的雙活，分享雙活技術(shù)關(guān)鍵點和一些試點效果。三、云化下的雙活1、云化后的雙活考慮云化后，一是出現(xiàn)虛擬化技術(shù)，二是應(yīng)用實現(xiàn)集群化和x86化，難以沿用原有的設(shè)計方式，而需要考慮集群化的業(yè)務(wù)連續(xù)性雙活方案。場景1：第三代中EBUS跨中心雙活集群第三代CRM引入分布式服務(wù)總線一層，即企業(yè)及服務(wù)總線，由于EBUS為服務(wù)集群，需要做較多的配置，對集群一致性要求較高，建議引入分布式協(xié)調(diào)機制實現(xiàn)雙活設(shè)計。場景2：基于VMware虛擬化平臺雙活設(shè)計基于存儲陣列雙活和VMware 跨

26、站點集群功能實現(xiàn)虛擬化平臺數(shù)據(jù)中心容災(zāi)解決方案，在陣列雙活技術(shù)支撐下，通過VMware Cluster 的HA高可用功能實現(xiàn)故障業(yè)務(wù)切換保護(hù)，從而達(dá)到保證業(yè)務(wù)連續(xù)性的要求?；A(chǔ)架構(gòu)層：網(wǎng)絡(luò)站點間二層互聯(lián)，采用波分傳輸，存儲實現(xiàn)雙活為上層提供共享存儲；將兩個數(shù)據(jù)中心服務(wù)器配置為一個集群，通過HA和DRS實現(xiàn)高可用和資源動態(tài)智能分配；服務(wù)器之間建議通過萬兆以太網(wǎng)提供心跳服務(wù)與vMotion遷移流量，集群內(nèi)的所有服務(wù)器需符合集群的兼容性規(guī)則。關(guān)鍵技術(shù)：Vmware HA高可用1）跨站點集群高可用；2）自動監(jiān)控和檢測服務(wù)器故障，自動重啟VM無須人工干預(yù)。VMware Vmonitor動態(tài)遷移實時在線遷

27、移，不中斷業(yè)務(wù)情況下硬件維護(hù)。Vmware DRS分布式資源調(diào)度1）自動計算和平衡資源，提高硬件資源利用率；2）跨資源池資源自動、智能優(yōu)化。四、雙活技術(shù)關(guān)鍵點關(guān)鍵點1：大二層網(wǎng)絡(luò)除了方案4外，均需要采用跨中心間大二層網(wǎng)絡(luò)，需要確定最優(yōu)的方案。方案1：采用OTV技術(shù)把二層vlan跨三層打通方案2：采用二層光纖直連技術(shù)打通方案3：采用基于MPLS網(wǎng)絡(luò)的VPLS互聯(lián)幾種大二層方案優(yōu)缺點分析：建議直連方案效率最高，其次 overlay方式，再次MPLS。關(guān)鍵點2：GoldenGate雙活方案數(shù)據(jù)同步優(yōu)化關(guān)鍵點基于數(shù)據(jù)復(fù)制軟件Oracle GoldenGate 性能瓶頸在數(shù)據(jù)同步環(huán)節(jié)：實際使用中發(fā)現(xiàn)Go

28、ldenGate主要性能瓶頸在復(fù)制進(jìn)程Replicat入庫速度，因為在容災(zāi)端恢復(fù)數(shù)據(jù)過程是執(zhí)行邏輯SQL，非常消耗資源，總的來說GG性能因素包括：CPU，內(nèi)存，磁盤I/O，網(wǎng)絡(luò)和DB性能，下面針對數(shù)據(jù)同步關(guān)鍵環(huán)節(jié)優(yōu)化建議。抽取進(jìn)程（Extract） ：DB Log平均生成速度在3050GB/h，CPU占用1.9% ，該進(jìn)程主要瓶頸在于LCR轉(zhuǎn)換為UDF環(huán)節(jié)，主要優(yōu)化建議：拆分Extract進(jìn)程，建議同一個schema下表盡量在一個進(jìn)程組中優(yōu)化進(jìn)程參數(shù)如eofdelay何flushsecs等I/O部分建議增加日志讀取間隔3s，增加內(nèi)存刷新時間3s投遞進(jìn)程（Pump）：DB Log平均生成速度=在

29、1530 GB/hCPU占用7% ，帶寬1GB DB Log/分鐘為1015Mb/s。主要瓶頸在帶寬和I/O兩個部分，優(yōu)化建議：1）帶寬優(yōu)化：復(fù)制的表最好有主鍵或唯一索引，減少生產(chǎn)日志量數(shù)據(jù)傳輸過程啟用數(shù)據(jù)壓縮特性，減少帶寬需求量適當(dāng)增大TCP緩存2）I/O部分優(yōu)化：增加隊列讀取間隔為3s，內(nèi)存刷新時間為5s復(fù)制/應(yīng)用進(jìn)程（Replicat）：結(jié)合運維經(jīng)驗單進(jìn)程處理速度為1GB隊列/h，該環(huán)節(jié)出現(xiàn)性能問題較多，需要重點優(yōu)化：合并小交易減少事物數(shù)量，減少寫checkpoint file/table次數(shù)大交易拆分（maxtransops參數(shù)），提高寫入速度基于表或Range等拆分replicat進(jìn)

30、程關(guān)鍵點3：Oracel ADG雙活方案數(shù)據(jù)同步性能分析對于Oracle 11g ADG 雙活方案數(shù)據(jù)同步時延分析，系統(tǒng)環(huán)境如下：日志產(chǎn)生量（采集于2015年4月初）日均產(chǎn)生歸檔量 1300 GB，其中節(jié)點 600 GB，2節(jié)點 700 GB。1天日志的峰值為 1705 GB，節(jié)點峰值 811 GB，2節(jié)點峰值 911 GB。單個小時日志峰值為 183 GB，1節(jié)點峰值 90 GB，2節(jié)點峰值 96 GB。網(wǎng)絡(luò)流量采用千兆網(wǎng)，傳輸日志平均占用帶寬為 16.24 MB/s，單個小時內(nèi)峰值為52 MB/s應(yīng)用時延（Transport Lag + Apply Lag）異步方式傳送日志，平均延時 0.

31、65 秒，正常業(yè)務(wù)處理期間時延小于10秒；生產(chǎn)庫中產(chǎn)生大量I/O的維護(hù)操作，比如添加數(shù)據(jù)文件，會導(dǎo)致目標(biāo)庫應(yīng)用時延相應(yīng)增加，可通過調(diào)整維護(hù)作業(yè)時間窗口加以避免。關(guān)鍵點4：Oracle Extended RAC雙活方案關(guān)鍵參數(shù)基于Oracle 11g Extended RAC+IBM GPFS A-A 雙活方案數(shù)關(guān)鍵參數(shù)：注意：關(guān)于RAC仲裁和GPFS仲裁，保證RAC的磁盤仲裁要晚于GPFS的仲裁，使得在網(wǎng)絡(luò)故障情況下GPFS提前RAC做出判定。所有網(wǎng)絡(luò)均采用Load Balance模式的EtherChannel，并且網(wǎng)絡(luò)間做到二層隔離關(guān)鍵點5：內(nèi)存數(shù)據(jù)庫數(shù)據(jù)同步性能Oracle和TT內(nèi)存庫幾種

32、模式下數(shù)據(jù)同步性能分析：1）Oracle 到TT庫同步：結(jié)合運維經(jīng)驗和Oracle官方理論，只要Oracle端性能滿足，TT端Cache就能夠滿足同步要求，實際中刷新間隔時間30秒內(nèi)，基表約為600MB，當(dāng)Oracle更新數(shù)據(jù)量小于15萬行記錄時，均能在刷新間隔內(nèi)完成，但對于當(dāng)Oracle批量業(yè)務(wù)，Oracle到TT端的同步效能將呈非線性（近指數(shù)）下降的趨勢，建議將大批量業(yè)務(wù)拆成小事務(wù)處理，分批提交。2）TT主備異步模式同步：結(jié)合測試和運維經(jīng)驗主備同步極限能力大約為1GB/分鐘，當(dāng)大于1GB時同步出現(xiàn)積壓。3）TT主備同步模式：同步性能和事物大小及設(shè)置超時時間有關(guān)系，當(dāng)主節(jié)點事物較大（測試中10萬行35M左右），會出現(xiàn)提交超時，同步友好模式下，備節(jié)點事務(wù)超時，主節(jié)點將會提交，結(jié)束該事務(wù)并繼續(xù)下一個事務(wù)處理；非同步友好模式下，備節(jié)點事務(wù)