|
一、同城雙活架構(gòu)與容災(zāi)架構(gòu)改造方面 Q1、針對(duì)存儲(chǔ)級(jí)復(fù)制實(shí)現(xiàn)主備中心數(shù)據(jù)同步的架構(gòu)，如何改造成雙活的模式？ @鄧毓 某農(nóng)信系統(tǒng)工程師： 這個(gè)雙活范疇比較大，看您是想實(shí)現(xiàn)的什么樣的雙活，雙活的節(jié)點(diǎn)有沒有共享存儲(chǔ)數(shù)據(jù)等。 最簡(jiǎn)單的應(yīng)用雙活，不共享數(shù)據(jù)的話，主備數(shù)據(jù)中心的架構(gòu)，打通了大二層網(wǎng)絡(luò)，將應(yīng)用節(jié)點(diǎn)部署于兩個(gè)站點(diǎn)，通過負(fù)載將請(qǐng)求分發(fā)到這些應(yīng)用節(jié)點(diǎn)，實(shí)現(xiàn)應(yīng)用節(jié)點(diǎn)的跨數(shù)據(jù)中心多活。 其次是存儲(chǔ)雙活，這時(shí)需要專門的雙活存儲(chǔ)作為必要條件，或者通過能夠?qū)崿F(xiàn)雙活的虛擬化網(wǎng)關(guān)來幫助原有的存儲(chǔ)實(shí)現(xiàn)雙活，存儲(chǔ)雙活后，對(duì)應(yīng)用節(jié)點(diǎn)需要跨數(shù)據(jù)中心共享數(shù)據(jù)，有很大的便利。當(dāng)然也可以作為數(shù)據(jù)庫雙活的后端存儲(chǔ)。 最后是數(shù)據(jù)庫雙活，對(duì)能夠?qū)崿F(xiàn)雙活的數(shù)據(jù)庫方案，跨兩個(gè)數(shù)據(jù)中心拉開的方案，如ORACLE EXTEND RAC、DB2 GDPC等，數(shù)據(jù)庫實(shí)現(xiàn)事務(wù)級(jí)的雙活 Q2、Oracle RAC ADG的方式實(shí)現(xiàn)雙活是否有相關(guān)案例？災(zāi)備從AS轉(zhuǎn)換到AA的建設(shè)有什么建議？ @鄧毓 某農(nóng)信系統(tǒng)工程師： oracle rac dg是本地?cái)?shù)據(jù)庫雙活 同城容災(zāi)的架構(gòu)，災(zāi)備端只讀，真正的跨中心oracle數(shù)據(jù)庫雙活方案還是oracle extend rac 存儲(chǔ)雙活方案，存儲(chǔ)雙活要么采用兩套可雙活的存儲(chǔ)實(shí)現(xiàn)，要么基于不同存儲(chǔ)，搭建例如gpfs跨中心的并行文件系統(tǒng)實(shí)現(xiàn)。災(zāi)備從ad到aa，在不改變底層存儲(chǔ)架構(gòu)的基礎(chǔ)之上，最簡(jiǎn)單的還是引入操作系統(tǒng)之上的并行文件系統(tǒng)和數(shù)據(jù)庫雙活技術(shù) Q3、銀行的容災(zāi)架構(gòu)，如何在保障業(yè)務(wù)高可用的前提下保障系統(tǒng)安全性？ @趙海 技術(shù)經(jīng)理： 我理解的這個(gè)安全是系統(tǒng)和數(shù)據(jù)的長(zhǎng)久安全。如果我們能保障業(yè)務(wù)的連續(xù)性前提下，底層基礎(chǔ)架構(gòu)的選擇就要以系統(tǒng)的安全性為主要目標(biāo)，不要盲目追求基礎(chǔ)架構(gòu)的完美而賣下安全的風(fēng)險(xiǎn)，架構(gòu)越復(fù)雜系統(tǒng)整體面臨的風(fēng)險(xiǎn)就越高。 Q4、同城雙活架構(gòu)當(dāng)中，最關(guān)鍵的幾個(gè)技術(shù)點(diǎn)以及思路？ @pangluck 系統(tǒng)工程師： 1、網(wǎng)絡(luò)層面，兩數(shù)據(jù)中心要實(shí)現(xiàn)二層打通。 2、應(yīng)用層面，虛擬化。 3、數(shù)據(jù)層面，存儲(chǔ)復(fù)制 ADG。 Q5、同城雙活架構(gòu)當(dāng)中，關(guān)于網(wǎng)絡(luò)二層打通的技術(shù)選型，VxLAN技術(shù)可行性？ @asdf-asdf 研究學(xué)者： 大二層并不是必須vxlan，使用pvlan技術(shù)一樣完成大二層打通，但安裝技術(shù)vxlan是可行的。 Q6、30km同城雙數(shù)據(jù)中心之間的網(wǎng)絡(luò)延遲大致是多少？是否存在抖動(dòng)？對(duì)雙活穩(wěn)定性可有影響？ @鄧毓 某農(nóng)信系統(tǒng)工程師： 通常理論上，每100KM距離，RTT往返延遲為1MS，但通常一次通訊，可能涉及多次RTT，加上并發(fā)，所產(chǎn)生的延遲已經(jīng)可以和存儲(chǔ)的IO響應(yīng)時(shí)間相比較，性能較好的存儲(chǔ)通常IO響應(yīng)時(shí)間都控制在5MS以下，所以距離帶來的延遲已經(jīng)是不可忽略的了。抖動(dòng)取決于鏈路質(zhì)量，通常而言，我們都是租用的運(yùn)營(yíng)商的裸光纖，抖動(dòng)或多或少是存在的，偶爾抖動(dòng)一兩次，是可以接受的，延遲陡增，不至于引起網(wǎng)絡(luò)長(zhǎng)時(shí)間超時(shí)，屬于可控范疇，真正要關(guān)注的無非是長(zhǎng)時(shí)間，頻率較高的抖動(dòng)，對(duì)于網(wǎng)絡(luò)和數(shù)據(jù)傳輸是致命的。目前防范抖動(dòng)最好的方式還是通過TCP協(xié)議的數(shù)據(jù)同步，利用TCP的重傳機(jī)制，保證數(shù)據(jù)的在一定時(shí)間窗口還是能夠傳輸過去。 二、雙活數(shù)據(jù)中心應(yīng)用交互與流量分發(fā)方面 Q1、如何從整體規(guī)劃設(shè)計(jì)應(yīng)用節(jié)點(diǎn)同城雙活的請(qǐng)求分發(fā)與請(qǐng)求引流？ @鄧毓 某農(nóng)信系統(tǒng)工程師： 目前而言，主流應(yīng)用負(fù)載有以下兩種： 軟件負(fù)載：HAProxy、IHS、Zookeeper、Apache、Nginx等 硬件負(fù)載：F5、信安世紀(jì)負(fù)載、深信服等 如果是應(yīng)用節(jié)點(diǎn)同城雙活，那么需要考慮應(yīng)用訪問請(qǐng)求如何如何引流至兩個(gè)數(shù)據(jù)中心的應(yīng)用節(jié)點(diǎn)的問題： 有兩種方式： 生產(chǎn)請(qǐng)求，生產(chǎn)和同城應(yīng)用節(jié)點(diǎn)均衡響應(yīng)，請(qǐng)求從單數(shù)據(jù)中心進(jìn)，響應(yīng)從單數(shù)據(jù)中心出（本地負(fù)載，跨中心分發(fā)）的方式，應(yīng)用負(fù)載部署于主數(shù)據(jù)中心，將請(qǐng)求均衡/優(yōu)先級(jí)、權(quán)重等方式分發(fā)至兩個(gè)數(shù)據(jù)中心的多個(gè)應(yīng)用節(jié)點(diǎn)，多適用于內(nèi)網(wǎng)業(yè)務(wù)系統(tǒng)。 生產(chǎn)和同城請(qǐng)求，生產(chǎn)或同城應(yīng)用節(jié)點(diǎn)分別均衡響應(yīng)，請(qǐng)求從兩個(gè)數(shù)據(jù)中心進(jìn)，響應(yīng)從兩個(gè)數(shù)據(jù)中心出，例如通過智能DNS域名解析，將公網(wǎng)請(qǐng)求按運(yùn)營(yíng)商/地域的不同進(jìn)行引流，兩個(gè)數(shù)據(jù)中心的應(yīng)用節(jié)點(diǎn)處理不同類型的流量，這種方式多適用于互聯(lián)網(wǎng)類的業(yè)務(wù)系統(tǒng)。內(nèi)網(wǎng)業(yè)務(wù)系統(tǒng)也可以采用全局DNS的方式進(jìn)行流量分發(fā)。 Q2、業(yè)務(wù)系統(tǒng)的整體同城雙活建設(shè)方案之外，如何考慮與其他業(yè)務(wù)系統(tǒng)的互聯(lián)互通，尤其是跨中心的業(yè)務(wù)間訪問？ @趙海 技術(shù)經(jīng)理： 這個(gè)問題其實(shí)可以這么看，業(yè)務(wù)沒有中心之分，只有業(yè)務(wù)接口之分。每一個(gè)業(yè)務(wù)接口對(duì)應(yīng)的是相應(yīng)的域名和端口，至于域名解析到哪一個(gè)地址，落到哪個(gè)數(shù)據(jù)中心，完全是基礎(chǔ)架構(gòu)的設(shè)計(jì)。所以我們?cè)谧鲭p活方案的時(shí)候，以具體應(yīng)用為粒度在應(yīng)用負(fù)載均衡設(shè)計(jì)當(dāng)中形成獨(dú)立的跨中心應(yīng)用資源池就可以了。 Q3、如何進(jìn)行同城主備中心的流量分擔(dān)？ @趙海 技術(shù)經(jīng)理： 一個(gè)非常重要的判斷標(biāo)準(zhǔn)就是基礎(chǔ)架構(gòu)的配置，同配置情況下，我們希望是完全的均衡模式。如果配置不一樣，那么我們希望可以按照基礎(chǔ)架構(gòu)配置來調(diào)整流量比例，這個(gè)可以在負(fù)載分發(fā)層來定制策略。 另外一個(gè)非常重要的標(biāo)準(zhǔn)是以業(yè)務(wù)點(diǎn)的分布為基準(zhǔn)，以不同數(shù)據(jù)中心對(duì)業(yè)務(wù)點(diǎn)響應(yīng)的時(shí)間來作為客戶端引流的標(biāo)準(zhǔn)，這個(gè)需要通過域名解析與業(yè)務(wù)點(diǎn)相關(guān)屬性定制化相關(guān)策略來實(shí)現(xiàn)。 三、雙活上線的標(biāo)準(zhǔn)、監(jiān)控及自動(dòng)化運(yùn)維工具等問題 Q1、做雙活的標(biāo)準(zhǔn)怎么判斷？比如做過的企業(yè)，哪些業(yè)務(wù)做了，哪些業(yè)務(wù)沒有做，原因是什么？ @趙海 技術(shù)經(jīng)理： 直接關(guān)系到柜面渠道、電子渠道等這些對(duì)客戶業(yè)務(wù)系統(tǒng)，要做雙活必須把它們列在其中。 一起內(nèi)部業(yè)務(wù)，跟對(duì)客戶業(yè)務(wù)關(guān)系不是非常密切的，可以考慮不做或者降級(jí)。 核心系統(tǒng)不僅要做而且要考慮到雙重保險(xiǎn)。 個(gè)人觀點(diǎn)，參考。 Q2、為了實(shí)現(xiàn)雙活，對(duì)于自動(dòng)化運(yùn)維監(jiān)控，運(yùn)維工具雙活的要求和實(shí)施方案？ @趙海 技術(shù)經(jīng)理： 如果實(shí)現(xiàn)了雙活架構(gòu)，那么對(duì)于運(yùn)維最大的挑戰(zhàn)就是跨數(shù)據(jù)中心級(jí)的部署，包括應(yīng)用的發(fā)版以及運(yùn)維變更及工具部署等等。如何保障版本的一致性和工作的自動(dòng)化高效化是我們應(yīng)該考慮的首要問題。 從兩個(gè)方面發(fā)來考慮，第一個(gè)方面就是我們建設(shè)的時(shí)候需要考慮基礎(chǔ)架構(gòu)本身，變更對(duì)象在變更、測(cè)試、上線之間可以通過自動(dòng)化腳本去調(diào)用負(fù)載均衡資源池的接口完成這些動(dòng)作，而不是手工去進(jìn)行操作。第二個(gè)方面就是運(yùn)維工具的設(shè)計(jì)，人工的操作就會(huì)產(chǎn)生差異，同一個(gè)業(yè)務(wù)不同節(jié)點(diǎn)上的變更有可能存在差異，為了避免這個(gè)風(fēng)險(xiǎn)我們可能需要投入很多人力在晚上去做測(cè)試和確認(rèn)。但是如果是自動(dòng)化工具去做這些事兒，最起碼可以保障這個(gè)差異會(huì)沒有或者概率很小。唯一需要保障的就是編寫在自動(dòng)化工具里面的任務(wù)是否正確。 相關(guān)推薦：
|
|
|
