1、 雙活中心一般建議存儲異步還是同步，兩種模式對于雙中心距離要求為多少？

@bbaimm88 某城商行存儲架構師：

結合非重要業(yè)務與重要業(yè)務來看，不然領導覺得你是單純談技術，脫離了實際。

兩種模式各有特色，性價比與安全性各有特色。

@summit  某城商行系統(tǒng)架構師：

1 、雙活分應用級雙活還是數據庫也實現雙活，如果是全雙活的話，建議雙中心距離不要超過 100KM ，保障裸光纖鏈路質量不要超過 5ms 延遲。裸光纖鏈路質量是雙活的關鍵。

2 、如果只是應用級雙活的話，存儲和數據庫的架構決定你采用什么樣的復制關系。如果采用 ADG ，一般采用最大性能方式，存儲復制的話一般同步和異步都可以，如果裸光纖質量不好就采用異步復制方式。同步方式如果裸光纖發(fā)生抖動可能造成 IO 的短暫 hung ，會對業(yè)務造成影響。3 、存儲復制異步和同步主要依據你雙活的實現方式。

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

存儲雙活有三種塊、文件和對象。塊和文件雙活都是以數據同步為前提的，對象通常是保證 metadata 的同步，底層文件數據做異步傳輸。

同步模式下主要是看業(yè)務對延遲的最大容忍度是多少，通常存儲要求往返 5ms 延遲是做塊存儲雙活的底線，距離如果按照光速計算就很遠了。實際距離來說，歐洲有超過 500km 的 SAN 雙活實施，國內基本都是 50km 以內。主要受制于光纖鏈路的皮質，包括跳數、熔纖的質量、光纖的擺放等等。

異步模式下，對距離理論上沒有限制，因為對象存儲大多是存放非結構化數據，通常數據量較大，帶寬需要根據寫入數據量的規(guī)模和能夠容忍的 RPO 進行計算。

2、 兩地三中心雙活系統(tǒng)災備切換場景和數據補錄問題？

@bbaimm88 某城商行存儲架構師：

數據的 RPO0 應考慮一份存儲級別的雙活數據，或者異步復制的數據；不能全部依賴數據庫軟件高可用（物理 邏輯冗余）

雙活測試場景太多了，不同思路不同考慮，運營商鏈路，單點物理設備，系統(tǒng)級別，站點級別故障都要拉通測試，（分行、網點部分及全面故障）；應用系統(tǒng)分依賴關系（比如加密平臺，短信平臺失效）；還得同時考慮雙中心故障引起東西流量過大的風險。

綜合網絡鏈路；各個區(qū)域路由；系統(tǒng)隔離級別；應用交付調度策略，從底層一層一層來解決吧！這個太廣泛了，幾句說不完。

建議數據層：Vplex 雙活存儲 OracleExtendRAC ADG ；應用 F5 DNS 或者 vsphere 雙活存儲 網絡大二層；雙活存儲解決了你的數據補錄問題。

@huawei851120 某農信系統(tǒng)工程師：

根據我們農信多年的災備建設和切換經驗，向您提出一些建議：

1. 災備的目的：災備的目的不是為了備份，更不是為了實現技術上的成就，花這么多的錢根本上是實現銀行的業(yè)務連續(xù)性管理目標。

2. 雙活的目的：有次我參加一次講座，還沒講完，有家銀行的領導就問我：“ 切換？你們都雙活了還切換個啥？” 這個問題能代表很多人的疑惑。雙活這個技術手段為了實現的目標是更快的恢復業(yè)務，也就是說為實現更小的 RTO 和 RPO 而已。冷備切換要 2 個小時，雙活只需 10 分鐘。假如你不演練的話，怎么說明你的雙活建設的牛呢？你沒有在 10 分鐘內切換到災備接管業(yè)務，怎么說明你們銀行的錢花的值呢？冷備擺在那不是蠻好的嘛，還省錢。您想想是不是？

3. 雙活怎么切：雙活的系統(tǒng)，演練的時候優(yōu)先切換數據庫，再切換應用系統(tǒng)。切換數據庫是重點，如果失敗就不用再往下切換應用系統(tǒng)了。Oracle 數據庫的 ADG 切換效率很高，兩三分鐘的事情，但是你們要花 10 分鐘進行檢查（檢查工作遠比調度切換腳本更重要）。數據庫切換沒問題的話，再用 DNS 切換流量到災備中心，生產端的應用根本不用停。如果檢查沒有問題的話，就把生產端和災備端的應用交易日志取下來，留作監(jiān)管單位來審計用。到時候你可以給他們看看， “ 領導您看，這個時候生產端的日志已經不滾動了，災備端的交易日志還在滾動，災備還在承接業(yè)務，說明我們交易已經成功切換到了災備中心 ” 。你就這樣講就行了，所以生產端的應用你沒有必要停到，正好用來做日志對比說明你們的戰(zhàn)果。

4. 數據補錄問題：我能熟練背誦很多監(jiān)管文件，人行、銀監(jiān)、省金融辦的文件里只是要求我們演練要以真實業(yè)務場景為前提進行切換（杜絕一些銀行用桌面演練應付監(jiān)管審計），從來沒有哪一家監(jiān)管單位要求我們非要做計劃外的切換。計劃外的切換，我建議你們千萬不要做，就算你想做，你們行長同意嗎？真出了問題，太嚴重，尤其現在很多交易都是 24 小時交易，通過自助設備接入完成的。如果數據真的有損失，后果不堪設想，補錄非常非常麻煩。

3 、如何降低同城雙活存儲對廣域網的依賴性？當雙活存儲間的廣域網線路抖動或者一些鏈路報錯時，如何排查原因？由于雙活存儲的延時，如何判斷哪些業(yè)務支持雙活存儲應用環(huán)境？

@bbaimm88 某城商行存儲架構師：

第一問：雙活存儲主要依賴裸纖 SAN 級聯網絡， 仲裁網依賴 廣域網，也有的雙活仲裁采用 fc 網絡；仲裁建議部署第三站點來降低依賴與風險。

第二問：廣域網線路抖動，也是運管上光纖不穩(wěn)定吧；一是采用多級光纖線路，二是需要 san 交換機支持 光衰大，不穩(wěn)定時 自動屏蔽；思科的 san 支持。排查原因主要交給網路鏈路監(jiān)控；以及 san FC 監(jiān)控告警；

第三問：雙活存儲的延時 一般 2-3ms 以內 業(yè)務都可用吧， 要是你的

存儲延時很高，恐怕距離太遠，或者集成質量很差；這種場景一般要避免；既然存儲雙活了。理論業(yè)務都可以用。

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

DWDM 設備能夠檢測到鏈路抖動并自動報警。

SAN 光纖交換機配置 “ Port Fencing ” 功能，自動檢測鏈路抖動并關閉 FC 端口，從而隔離鏈路抖動。

IP 網絡設備應用 “ 快速收斂實現檢測（ BFD ） ” 技術，自動檢測并關閉抖動鏈路口，從而隔離鏈路抖動。

存儲虛擬化網關的 WAN COM I/O 模塊能夠自動檢測鏈路抖動并關閉端口，從而隔離鏈路抖動。

4、存儲雙活仲裁架構設計的關鍵點有哪些？

@bbaimm88 某城商行存儲架構師：

采用第三站點仲裁最佳；方式有 IP 網絡與 FC 網絡。

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

主要是兩個問題：

1 、仲裁位置的擺放，最好是第三站點，這在極端故障情況下更能夠最大限度保障存儲可用；

2 、網絡問題，雙活仲裁有些是通過管理網絡實現的，比如 DELLEMC 的雙活，只要 IP 網絡通就行了，但是有一些是通過存儲虛擬化的方式來實現，這就需要 SAN 網絡通，當然可以采用 IPSAN 的這折中方式，但是從實際經驗看，存儲虛擬化方式對帶寬的需求略大。有客戶處有 DELLEMC 和友商的雙活同時跑的情況，同樣的帶寬大小， DELLEMC 的雙活仲裁正常進行，友商的就不斷報錯，最后通過升級帶寬解決了問題。

5、存儲雙活如何管控，如何制定匹配制度？

@bbaimm88 某城商行存儲架構師：

雙活管理的確是個難題，我們也存人手不夠，通過補充對口技術人才，執(zhí)行 AB 角互備，數據庫、存儲、主機、應用負載、網路、安全各司其職；同時我上了一套容災切換軟件專門解決 oracleExtendRAC 切換及 AIX 個別應用容災切換；釋放 DBA 排錯壓力，專注監(jiān)控定位，提供指引；

應用切換基于 DNS 不需要太多人工干預；存儲雙活建有第三站點來保障仲裁；減少疑難場景仲裁人工分析。但也只能僅僅滿足現狀，無法應對互聯網金融業(yè)務發(fā)展，這個要上 devops ，推行 IAAS 解決方案來釋放人力壓力

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

災備建設是一個系統(tǒng)工程，這個工程中最難的不是技術問題，是管理和溝通問題，特別是與非科技背景的高級別領導展示、解釋的問題。

就像您說的管理問題，很多行采用了類似的技術架構但是采用了不同的管理方法，為什么？因為每個行的情況都不相同，管理很大程度是跟領導風格相掛鉤的，要形成有效的管理不能簡單看別人穿什么衣服的問題，大多數時候是需要量體裁衣。這也是為什么很多行在做災備咨詢。除了專業(yè)技能，咨詢更多的是幫助溝通。

6、存儲雙活后，備份的數據如何有效的開展定期的恢復驗證工作？

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

備份和存儲雙活是相輔相成的兩條線，備份數據主要是聚焦在邏輯故障的恢復?；謴万炞C需要根據不同的場景指定不同的應對措施，數據庫可以通過腳本配合備份軟件拉起驗證。非結構化數只有人去驗證。DELLEMC 的 Datadomain 自身具備數據有效性的算法，內部自動檢備份數據是否有效。

@bbaimm88 某城商行存儲架構師：

上雙活了，建議配套上備份系統(tǒng)，從備份系統(tǒng)抽取數據來循環(huán)恢復驗證，若沒有備份系統(tǒng)，我只能告訴你，你們得自己寫腳本來熱備或者冷備，這個工程太大了，虧人力。我們使用備份系統(tǒng)，然后配置了數據庫自動恢復環(huán)境，一鍵恢復到驗證環(huán)境，虛擬機及也采用自動恢復，或者立即拉起。大大減少人力，效率大大提高。

7 、 雙活環(huán)境下，銀行夜間批量任務（含數據庫全表更新步驟）對交易成功率有較大直接影響，如何調優(yōu)？

@bbaimm88 某城商行存儲架構師：

批量屬于 OLAP 業(yè)務處理，交易屬于 OLTP 業(yè)務處理。在跑批期間影響交易，這個從底層 OS 、 DB 是無法完美解決，需要軟件的開發(fā)來設計，應對高峰的批量業(yè)務保障業(yè)務進行，很多跑批結算日是自定義日結切換時間，比如核心切換是每天 11 ：30 分，其他業(yè)務也隨之同步切換日切記賬。通過應用邏輯設計來規(guī)避數據表競爭，解決表競爭就能很好解決交易業(yè)務問題。這個涉及的業(yè)務改造就比較大，跑批涉及表可以適當引入分區(qū)表適當解決表競爭。

@呂峰 戴爾科技金融行業(yè)中國西區(qū)高級系統(tǒng)工程師：

個人理解交易成功率降低大概率是數據寫入出現了問題，首先采集數據庫、主機、網絡（主要是雙活同步網絡）和底層存儲的日志，然后分析跑批期間的有沒有出現資源利用率過高導致寫入受到嚴重影響的環(huán)節(jié)，具體分析后才能進行有效的調整。

所有的雙活和同步復制都要求寫數據在兩個設備的一致寫入，跑批期間有大量的過程數據寫入，都會面臨比較大的挑戰(zhàn)。我曾經碰到過一家行因為復制鏈路帶寬過低導致大量 IO 擁塞導致出現問題，通過帶寬擴容解決了問題。但是，前提還是前面說的，找到問題的原因才能優(yōu)化。

8 、雙中心二層網絡必要性？

【問題描述】銀行同城應用級災備或同城雙活級災備的場景下，在暫時不考慮多活數據中心的前提下，使用網絡大二層打通的架構是否合適？這種場景下網絡大二層打通是否還是架構的趨勢？

@bbaimm88 某城商行存儲架構師：

沒有全局負載均衡均衡調度的話，大二層還是可以的，雙活存儲 大二層 vsphere 虛擬化方案，是一種解決方案。

但是網絡壓力較大，最好還是建設居于 DNS 的雙活應用調度。大二層不是趨勢，是一種解決方案。

9 、如果想實現 oracle 數據庫同城雙活和存儲同城雙活，對 IP 網絡和 SAN 網絡有哪些硬性要求？通過哪些指標進行評估？ 

@bbaimm88 某城商行存儲架構師：

存儲同城雙活，硬性要求：1 、建議五大廠商選（推薦帶虛擬網關方案例如 vplex ）；2、機房選址不宜過遠（ 20KM 以內可保證光延時約 1ms ）；3、建設需要裸光纖（強烈建議）；4、最好自購波分設備，sSAN 網絡交換機帶光衰檢查判斷。

Oracle 數據庫同城雙活，這是個大難題，主要受限于網絡延時要越低越好，數據庫 TPS 小可以雙中心并行跑 RAC ， TPS 高的又要雙中心并行跑 RAC 對環(huán)境極為苛刻（心跳通信壓力很大）這種適合 3-5KM 以內（國外很多這種案例），這種建議選高端成熟解決方案，推薦全閃存。

若建設 ExtendRAC ，實現主中心 Active ，另一中心 RAC 節(jié)點 standby ，這個是一個折中選擇方案。可以保證 RPO 為 0 ， RTO 分鐘級別。

10 、跨中心應用雙活 web/app 的具體部署模式？

@bbaimm88 某城商行存儲架構師：

你這有 GSLB 實現跨中心分發(fā)，應用減少東西流量，盡量保持都是南北流量。雙中心間減少 web 與 app 的交叉訪問。除非系統(tǒng)故障出現?？缰行慕徊嬖L問對跨中心流量堆疊太高，不利于網絡管理。