城商銀行雙活容災建設方案設計三大難點

1、 城商銀行雙活容災建設方案設計三大難點 為幫助同業(yè)在雙活容災建設項目規(guī)劃和建設過程中提供一些啟示和幫助，TWT社區(qū)近期組織了銀行業(yè)雙活領域的數(shù)位專家，就系統(tǒng)架構集成、資源云化、存儲整合以及數(shù)據(jù)容災等多個關鍵方面詳細探討了同城雙活與容災規(guī)劃思路以及建設過程。下面由社區(qū)專家鄧毓對整個活動的主要內容進行總結，方便更多讀者參考。主要分為以下三個方面：1、同城雙活架構與容災架構改造方面2、雙活數(shù)據(jù)中心應用交互與流量分發(fā)方面3、雙活上線的標準、監(jiān)控及自動化運維工具等方面一、同城雙活架構與容災架構改造方面Q1、針對存儲級復制實現(xiàn)主備中心數(shù)據(jù)同步的架構，如何改造成雙活的模式？鄧毓 某農信系統(tǒng)工程師：這個雙活范

2、疇比較大，看您是想實現(xiàn)的什么樣的雙活，雙活的節(jié)點有沒有共享存儲數(shù)據(jù)等。最簡單的應用雙活，不共享數(shù)據(jù)的話，主備數(shù)據(jù)中心的架構，打通了大二層網(wǎng)絡，將應用節(jié)點部署于兩個站點，通過負載將請求分發(fā)到這些應用節(jié)點，實現(xiàn)應用節(jié)點的跨數(shù)據(jù)中心多活。其次是存儲雙活，這時需要專門的雙活存儲作為必要條件，或者通過能夠實現(xiàn)雙活的虛擬化網(wǎng)關來幫助原有的存儲實現(xiàn)雙活，存儲雙活后，對應用節(jié)點需要跨數(shù)據(jù)中心共享數(shù)據(jù)，有很大的便利。當然也可以作為數(shù)據(jù)庫雙活的后端存儲。最后是數(shù)據(jù)庫雙活，對能夠實現(xiàn)雙活的數(shù)據(jù)庫方案，跨兩個數(shù)據(jù)中心拉開的方案，如ORACLE EXTEND RAC、DB2 GDPC等，數(shù)據(jù)庫實現(xiàn)事務級的雙活Q2、Or

3、acle RAC+ADG的方式實現(xiàn)雙活是否有相關案例？災備從AS轉換到AA的建設有什么建議？鄧毓某農信系統(tǒng)工程師：oracle rac+dg是本地數(shù)據(jù)庫雙活+同城容災的架構，災備端只讀，真正的跨中心oracle數(shù)據(jù)庫雙活方案還是oracle extend rac+存儲雙活方案，存儲雙活要么采用兩套可雙活的存儲實現(xiàn)，要么基于不同存儲，搭建例如gpfs跨中心的并行文件系統(tǒng)實現(xiàn)。災備從ad到aa，在不改變底層存儲架構的基礎之上，最簡單的還是引入操作系統(tǒng)之上的并行文件系統(tǒng)和數(shù)據(jù)庫雙活技術Q3、銀行的容災架構，如何在保障業(yè)務高可用的前提下保障系統(tǒng)安全性？趙海 技術經理：我理解的這個安全是系統(tǒng)和數(shù)據(jù)的長久

4、安全。如果我們能保障業(yè)務的連續(xù)性前提下，底層基礎架構的選擇就要以系統(tǒng)的安全性為主要目標，不要盲目追求基礎架構的完美而賣下安全的風險，架構越復雜系統(tǒng)整體面臨的風險就越高。Q4、同城雙活架構當中，最關鍵的幾個技術點以及思路？pangluck 中鼎系統(tǒng)工程師：1、網(wǎng)絡層面，兩數(shù)據(jù)中心要實現(xiàn)二層打通。2、應用層面，虛擬化。3、數(shù)據(jù)層面，存儲復制+ADG。Q5、同城雙活架構當中，關于網(wǎng)絡二層打通的技術選型，VxLAN技術可行性？asdf-asdf cloudstone研究學者：大二層并不是必須vxlan，使用pvlan技術一樣完成大二層打通，但安裝技術vxlan是可行的。Q6、30km同城雙數(shù)據(jù)中心之間

5、的網(wǎng)絡延遲大致是多少？是否存在抖動？對雙活穩(wěn)定性可有影響？鄧毓某農信系統(tǒng)工程師：通常理論上，每100KM距離，RTT往返延遲為1MS，但通常一次通訊，可能涉及多次RTT，加上并發(fā)，所產生的延遲已經可以和存儲的IO響應時間相比較，性能較好的存儲通常IO響應時間都控制在5MS以下，所以距離帶來的延遲已經是不可忽略的了。抖動取決于鏈路質量，通常而言，我們都是租用的運營商的裸光纖，抖動或多或少是存在的，偶爾抖動一兩次，是可以接受的，延遲陡增，不至于引起網(wǎng)絡長時間超時，屬于可控范疇，真正要關注的無非是長時間，頻率較高的抖動，對于網(wǎng)絡和數(shù)據(jù)傳輸是致命的。目前防范抖動最好的方式還是通過TCP協(xié)議的數(shù)據(jù)同步，

6、利用TCP的重傳機制，保證數(shù)據(jù)的在一定時間窗口還是能夠傳輸過去。二、雙活數(shù)據(jù)中心應用交互與流量分發(fā)方面Q1、如何從整體規(guī)劃設計應用節(jié)點同城雙活的請求分發(fā)與請求引流？鄧毓某農信系統(tǒng)工程師：目前而言，主流應用負載有以下兩種：軟件負載：HAProxy、IHS、Zookeeper、Apache、Nginx等硬件負載：F5、信安世紀負載、深信服等如果是應用節(jié)點同城雙活，那么需要考慮應用訪問請求如何如何引流至兩個數(shù)據(jù)中心的應用節(jié)點的問題：有兩種方式：生產請求，生產和同城應用節(jié)點均衡響應，請求從單數(shù)據(jù)中心進，響應從單數(shù)據(jù)中心出（本地負載，跨中心分發(fā)）的方式，應用負載部署于主數(shù)據(jù)中心，將請求均衡/優(yōu)先級、權重

7、等方式分發(fā)至兩個數(shù)據(jù)中心的多個應用節(jié)點，多適用于內網(wǎng)業(yè)務系統(tǒng)。生產和同城請求，生產或同城應用節(jié)點分別均衡響應，請求從兩個數(shù)據(jù)中心進，響應從兩個數(shù)據(jù)中心出，例如通過智能DNS域名解析，將公網(wǎng)請求按運營商/地域的不同進行引流，兩個數(shù)據(jù)中心的應用節(jié)點處理不同類型的流量，這種方式多適用于互聯(lián)網(wǎng)類的業(yè)務系統(tǒng)。內網(wǎng)業(yè)務系統(tǒng)也可以采用全局DNS的方式進行流量分發(fā)。Q2、業(yè)務系統(tǒng)的整體同城雙活建設方案之外，如何考慮與其他業(yè)務系統(tǒng)的互聯(lián)互通，尤其是跨中心的業(yè)務間訪問？趙海 技術經理：這個問題其實可以這么看，業(yè)務沒有中心之分，只有業(yè)務接口之分。每一個業(yè)務接口對應的是相應的域名和端口，至于域名解析到哪一個地址，落到

8、哪個數(shù)據(jù)中心，完全是基礎架構的設計。所以我們在做雙活方案的時候，以具體應用為粒度在應用負載均衡設計當中形成獨立的跨中心應用資源池就可以了。Q3、如何進行同城主備中心的流量分擔？趙海 技術經理：一個非常重要的判斷標準就是基礎架構的配置，同配置情況下，我們希望是完全的均衡模式。如果配置不一樣，那么我們希望可以按照基礎架構配置來調整流量比例，這個可以在負載分發(fā)層來定制策略。另外一個非常重要的標準是以業(yè)務點的分布為基準，以不同數(shù)據(jù)中心對業(yè)務點響應的時間來作為客戶端引流的標準，這個需要通過域名解析與業(yè)務點相關屬性定制化相關策略來實現(xiàn)。三、雙活上線的標準、監(jiān)控及自動化運維工具等問題Q1、做雙活的標準怎么判

9、斷？比如做過的企業(yè)，哪些業(yè)務做了，哪些業(yè)務沒有做，原因是什么？趙海 技術經理：直接關系到柜面渠道、電子渠道等這些對客戶業(yè)務系統(tǒng)，要做雙活必須把它們列在其中。一起內部業(yè)務，跟對客戶業(yè)務關系不是非常密切的，可以考慮不做或者降級。核心系統(tǒng)不僅要做而且要考慮到雙重保險。個人觀點，參考。Q2、為了實現(xiàn)雙活，對于自動化運維監(jiān)控，運維工具雙活的要求和實施方案？趙海 技術經理：如果實現(xiàn)了雙活架構，那么對于運維最大的挑戰(zhàn)就是跨數(shù)據(jù)中心級的部署，包括應用的發(fā)版以及運維變更及工具部署等等。如何保障版本的一致性和工作的自動化高效化是我們應該考慮的首要問題。從兩個方面發(fā)來考慮，第一個方面就是我們建設的時候需要考慮基礎架

10、構本身，變更對象在變更、測試、上線之間可以通過自動化腳本去調用負載均衡資源池的接口完成這些動作，而不是手工去進行操作。第二個方面就是運維工具的設計，人工的操作就會產生差異，同一個業(yè)務不同節(jié)點上的變更有可能存在差異，為了避免這個風險我們可能需要投入很多人力在晚上去做測試和確認。但是如果是自動化工具去做這些事兒，最起碼可以保障這個差異會沒有或者概率很小。唯一需要保障的就是編寫在自動化工具里面的任務是否正確。Q3、應用層同城雙活中，自動化運維工具、監(jiān)控工具的實施方案有沒有什么推薦？趙海 技術經理：數(shù)據(jù)庫方面，感覺maxgauge不錯，不僅僅監(jiān)控，而且可以做優(yōu)化解決方案?？梢匝芯垦芯?。OEM如果加上DBA的精心設計，也不錯，可以實現(xiàn)很多個性化