金融災備數據中心技術方案議程

1

互聯網金融災備數據中心建設技術架構總體思路2

開放式既分布式技術架構設計方案

3

商業級既集中式技術架構設計方案

4

方案總結2互聯網金融災備數據中心建設技術架構總體思路GB/T20988－2007《信息系統災難恢復規范》

SHARE78國際標準

災備

模式

災備

層次

1級

基本級。

備份介質場外存，安全保管、定期驗證

Tier-0

無異地備份數據

冷備

數據級

Tier-1

有數據備份，無備用系統

2級

備份場地支持。

網絡和業務處理系統可在預定時間內調配到備份中心

Tier-2

有數據備份，有備用系統

3級

電子傳輸和部分設備支持。

災備中心配備部分業務處理和網絡設備，具備部分通訊鏈路

Tier-3

電子鏈接

4級

電子傳輸和完整設備支持。

數據定時批量傳送，網絡/系統始終就緒。

Tier-4

使用快照技術拷貝數據

暖備/熱備

應用級

5級

實時數據傳輸及完整設備支持。

采用遠程復制技術，實現數據實時復制，網絡具備自動或集中切換能力，業務處理系統就緒或運行中。

Tier-5

交易的完整性

6級

數據零丟失和遠程集群支持。

數據實時備份，零丟失，系統/應用遠程集群，可自動切換，用戶同時接入主備中心

Tier-6

少量或無數據丟失

雙活

業務級

互聯網金融災備數據中心總體設計目標5業務的可用性需求RTO-RPO與建設成本之間的關系

RPO損失的數據量丟失數據成本 宕機成本二級應用

三級應用

數據可用性成本

系統可用性成本

一級應用

恢復業務所需時間RTO0

時間軸

成本軸

互聯網金融災備中心建設總體發展趨勢

職能定位方面技術特性方面架構方面測試演練方面體系建設方面信息系統業務連續性建設體系架構

7業務應用管理實踐支撐系統系統軟件硬件基礎設施戰略規劃層，對業務進行評估，劃定連續性級別對應用的邏輯關系進行梳理，確定應用的可用性指標流程的定義，配置變更與事件管理管理，安全，基礎架構服務等配套系統虛擬化，操作系統，網絡協議，存儲服務服務器，存儲設備，網絡設備與鏈路建筑，環境，供電??未來應以虛擬化為基礎構建靈活、可信、經濟的業務連續性保障平臺

提供多種手段

高可用 容錯 遷移 存儲遷移 備份 復制 快照

適用多種場景 同城雙中心 異地雙中心 兩地三中心 分支到中心

支持多種關系雙活 互備 主備 多對一 備份到云單中心

服務多種應用

關鍵應用 數據庫 二三級應用 開發/測試 教學/科研同城中心A

異地中心同城中心B?同城高可靠雙活中心應能夠支持關鍵應用的靈活切換。?異地容災中心作為主數據中心及同城中心的暖備份中心。?對于關鍵應用，同城中心應沒有任何性能降低，異地容災中心的性能降低率丌能超過20%。

互聯網金融平臺數據中心災備模式—兩地三中心兩地三中心解決方案—雙活不災備的完美集成10?場景描述–適用于對業務連續性要求較高的應用，通過集成同城雙活不異地災備兩種解決方案，既能實現數據零丟失和故障自動切換,又能抵御局部災難的發生。?方案特點–同城兩個站點之間的高可用提供數據零丟失的第一層保護–異地數據中心之間的災備功能實現第二層保護–軟件定義的網絡不存儲可提供最大靈活性

兩地三中心

結論：未來應打造兩地三中心、同城雙活的云金融平臺災備接管池

X86虛擬池

高性能 高密度生產云

?生產業務系統

開發測試云

?所有系統的災備

?研發測試環境

快速恢復池

準生產云

?關鍵業務系統的

快速切換

?預生產環境

?系統管理、服務管理和云管理一體化

?兩地三中心資源部署和調度一體化

?用戶管理和訪問一體化

?信息處理和展示的一體化

數據中心雙活/多活的實現示意圖

12三種主要的數據中心雙活場景的定義雙活場景 場景界定 條件要求非對稱雙活

Web/App層在多個站點同時提供服務，但數據庫僅在單一站點提供服務CDN/GTM+LTM，數據庫在主備站點之間有復制服務分應?雙活

單個業務完整地運?行在一個站點，在另一站點提供災備。

每個站點都同時提供部分業務的生產，以及另一部分業務的災備。主備站點間有數據復制服務，包括對所有虛機或物理機存儲的復制對稱雙活業務或用戶分配到兩個數據中?，每個數據中?都有自己的應?集群對外服務，跨中心建?共?數據庫。

平時所有的中心均承載業務，實現資源最大利?，出現災難時，正常的生產數據中心接管故障中心承載的業務CDN/GTM+LTM有裸光纖及DWDM存儲雙活

數據庫雙活雙活數據中心應用部署需求及可選技術總結磁盤陣列

邏輯卷層文件系統層操作系統層數據庫層應用層 基于應用系統的復制基于數據庫的復制

基于邏輯卷的復制基于智能存儲的復制

磁帶庫層

基于磁帶庫的復制

利用智能存儲設備記錄下I/O信息，將數據變化通過高帶寬的專網線路或者IP網絡傳送到遠端；復制工具：HDS

true

Copy

via

SAN;

HDS遠程復制via

IP

利用卷管理工具將邏輯卷級別的I/O數據包，順序傳送到遠端;復制工具：VERITAS

VVR,VVM;

IBM

GeoRM/HAGEO利用日志記錄下數據庫的數據變化并將日志傳送到遠端;數據庫復制工具：Oracle

Data

Guard，Godengate

第三方工具如：Quest

SharePlex

利用應用程序負責將同一筆交易在生產中心和異地數據災備中心都得到執行;復制工具：FTP,

應用改造等

1、通過運輸磁帶庫至異地數據災備中心后將數據恢復至磁盤陣列;2、本地數據備份到遠端帶庫；

復制工具：

VERITAS

NBU

數據復制技術簡介數據復制技術分析-技術特點比較類別

主機設備

磁盤陣列

應用軟件

數據庫平臺

新增第三方設備

基于應用

可異構

可異構

同版本

可異構

同生產中心相同的軟件平臺

基于數據庫

可異構

可異構

無限制

同版本

數據庫復制軟件：DBGuard,QuestSharePlex等

基于邏輯卷

要求同構

可異構

OS同構，無限制

無限制

IBM:GeoRM/HAGEO；Veritas:卷管理軟件VVM,卷復制軟件VVR

基于存儲設備

可異構

要求同構

無限制

無限制

同構磁盤陣列

磁盤陣列數據復制軟件

基于磁帶庫

無限制

無限制

無限制

無限制

備份管理軟件

數據復制技術分析-兼容性類別 對生產主機性能影響 對生產中心系統架構影響

誤操作損失 傳輸需求 反向復制難度

基于應用

影響較小，受限于復制模式、效率

影響較小，需整改應用軟件，增加數據復制模塊

可挽回交易重做IP網

基于交易復制

帶寬需求低

支持，需恢復生產端應用系統環境

基于

數據庫

影響較小，受限于復制模式、效率

影響較小，增加數據庫log復制

無法挽回IP網

基于log復制

帶寬需求較低

支持，需恢復生產端數據庫環境

基于

邏輯卷

影響較大，復制軟件占用較大的系統開銷（若通過鏡像庫設備復制，可減少對生產主機影響，但RPO將降為天級）

影響較大，對現有主機進行整改，更換卷管理工具為VVM或IBMGeoRM/HAGEO等

無法挽回IP網

通常應用于同步/異步自適應模式，對帶寬要求較智能存儲復制低

支持，需恢復生產端邏輯卷環境

基于

存儲設備

影響小，基于底層陣列級數據復制

無影響

無法挽回SAN網

通常應用于同步模式，對帶寬要求較高

支持，需恢復生產端同構陣列存儲環境基于

磁帶庫

無影響

無影響

無法挽回 無支持，需恢復生產端備份環境

數據復制技術分析-合理性類別

維護難度

投資額度

基于應用

涉及應用改造，維護難度大 對第三方軟、硬件兼容性最好，需采購相關應用軟件，投資相對小基于數據庫

數據的復制由日志復制工具完成，系統升級或重新規劃對復制可能產生影響，維護難度中等；

歸檔日志方式日常維護工作較多，維護難度較大第三方數據庫復制方式：需采購同版本數據庫軟件、第三方數據庫復制軟件（如shareplex），投資相對較大

歸檔日志方式：需采購同版本數據庫軟件，投資相對較小

免費工具:OracleDBGuard

基于邏輯卷

數據的復制由卷復制工具完成，系統升級或重新規劃對復制可能產生影響，維護難度中等需采購卷管理軟件、邏輯卷復制軟件，投資相對較大基于存儲設備

周期作業定制，維護難度最低 需采購同構高端磁盤陣列、基于陣列的數據復制軟件，投資相對大基于磁帶庫

周期作業定制，維護難度較低

但涉及周期性磁帶、磁帶庫搬運IT投資最小

數據復制技術分析-可維護性、投資WEB/應用層雙活實現機制實現方式 主機集群 應用軟件集群 負載均衡簡要描述 采用主機操作系統本身的集群功能實現中心內部/中心之間的雙活采用應用中間件自身的集群功能實現中心內部/中心之間的雙活采用負載均衡設備來實現中心內部/中心之間的雙活切換時間 實時切換 實時切換 實時切換應用程序 不需要改變 不需要改變 不需要改變增加設備/軟件 集群卡/高速交換機 負載均衡設備可擴展性 一般 一般 強負載分配方式 動態 動態 動態實現方式 復雜 較簡單 簡單中心內部 較強 較強 強跨中心 弱 弱 強WEB/應用層雙活實現機制主要有三種，一是基于主機集群技術，二是基于WEB

SERVER/應用中間件軟件自身集群軟件實現功能，三是基于負載均衡設備方式

數據庫層雙活實現機制對比實現方式 ORACLE

RAC+VPLEX DATAGUARD/GOLDENGATE簡要描述

通過打通同城兩個站點的二層網絡和實現存儲虛擬化，數據庫集群得以跨越兩個數據中心，共同承擔業務系統的運行，數據庫實時同步，一個中心的集群存在問題，另一個中心實時接管數據庫采用本地Oracle

RAC，同城采用DATAGUARD同步機制，在同步的基礎上通過”讀寫分離“實現應用雙活切換時間

實時切換 分鐘級應用程序 不需要改變 不需要改變

增加設備/軟件

VPLEX設備 DATAGUARD/GOLDENGATE可擴展性

一般 好負載分配方式

動態 靜態實現方式 較為復雜 簡單數據丟失 無 分鐘級/秒級/無

網絡要求 跨中心網絡延遲要求在毫秒級以內要求打通大二層網絡 無要求存儲雙活實現機制對比存儲雙活實現機制主要有四種：一是基于主機卷復制技術，二是基于存儲虛擬化技術；

三是基于存儲復制技術，四是基于SAN網絡復制技術。

訪問接入層的雙活實現機制實現方式 傳統站點輪詢 站點選擇負載均衡設備簡要描述

采用客戶端設多個IP地址－采用IP輪詢方式（開發程序配合），選用適合的站點采用站點負載均衡設備，通過策略設計，使得用戶訪問最適合的站點切換時間 分鐘級(手動策略有關) 實時應用程序 需要修改

不需要修改，應用不變

增加設備

不需要

增加站點負載均衡設備和DNS服務器可擴展性

低

高

站點分配方式

靜態連接

可根據數據中心負載，用戶距離分配

資源利用率 低，訪問資源較為固定，資源利用率不高

高，可根據應用負載和距離自動分配，資源利用率高

為滿足雙活數據中心的需求，必須使客戶端的請求在多個中心進行智能選擇，實現業務的連續性(性能最優/故障切換/按需連接)，實現站點選擇通常有兩種方式，一是傳統站點輪詢技術，二是站點負載均衡技術現狀分析調研風險分析業務影響分析系統現狀和發展RA&BIA分析報告需 災備需求分析求分析階段運維階段前期工作后續工作容災建設過程和步驟策略分析制定災備總體設計組織流程設計災備系統布局規劃災備策略等級需求總體技術方案設計組織架構和運維流程周期性的演練評估災備管理持續改進桌面演練年度演練周期策略回顧 EManage&volveBuild&implementAnalyzebusiness

needs?Define&analyzerisks?Existingprogramreview?Determinebusiness

impact&recoveryrequirementsofkeybusinessprocesses?Clarifydependencies?Rehearse

theplan?Assess/audityourprogram?Integrateintochange&configurationmanagement

processes?Deploysupportinginfrastructure?Developbusiness

continuityprogramandplanDesign

the

solution?Translaterequirementsintoexecutable

strategies

accordingtoscenariosBusiness

continuityprogram

management?Designinfrastructuretoimplement

selectedstrategies?Createeducationandtrainingprogram災備系統建設災難恢復計劃開發技術和意識培訓同城和異地的災備系統

災難恢復計劃培訓和演練實施階段建設工作于數據中心災備中心建設工作內容

基于開放式云平臺架構構建分布式互聯網金融云數據中心及災備中心虧聯網金融數據中心的發展趨勢傳統中心

(Yahoo,)服務器，交換,

商用SAN,

NAS云中心(Google,

Amazon，淘寶)通用硬件,

Map/Reduce,NoSQLIT基礎架構發展趨勢：分離架構商用集中存儲融合架構分布式存儲虧聯網金融分布式于數據中心技術范疇集中方式

分布式方式

災備

災備+多活負載均衡

兩地三中心

雙活、多活、數據中心同級平等

資源固化

資源池化靈活調配

保證RPO

追求RPO和RTO人工切換管理

資源調度切換自動化

面向分布式云計算的新一代容災架構的趨勢跨地域的分布式虛擬化數據中心，延伸傳統災備中心功能分布式云數據中心雖然從物理上講也是在建同城或三中心，但從建設方向上看不再拘泥兩地三中心的概念，而是

更趨向平等、同級和平臺化，保證數據完整性、業務連續性不間斷提供服務、業務彈性和敏捷性、自動化。

虧聯網金融分布式于數據中心平臺技術架構分布式數據中心同城災備數據中心整體規劃基亍OPENSTACK開源于管理平臺多數據中心物理架構數據中心數據存儲技術：分布式存儲共享存儲設備serversserversSAN網絡LAN網絡網絡機柜存儲機柜服務器機柜網絡機柜……服務器機柜傳統SAN集中存儲部署方案：■兩套系統：服務器、存儲整列■兩套網絡：以太網、FCSAN■兩套管理：虛機管理、磁盤管理serversFusionStorserversLAN網絡服務器機柜網絡機柜……FusionStor服務器機柜開放式分布式存儲部署方案：■一套系統，只有服務器系統■一套網絡，只有以太網■計算不存儲采用統一管理軟件FusionCloud，簡化管理，降低運維工作量虛擬存儲技術參數

傳統集中存儲系統

分布式存儲系統

分布式存儲優越之處

可擴展性

性能及磁盤數量受控制器限制，可擴展性有限

無縫線性擴展

擴容升級時無需更換硬件設備，無需遷移數據。

磁盤層面的負載均衡

磁盤間的負載高度不平衡

在所有磁盤間完美的均衡負載

降低磁盤故障幾率

重建時間

大約10小時每T

大約20分鐘每T

風險窗口極大縮短，降低了雙重故障的可能

重建開銷

在重建期間部分磁盤會經受很大的負載壓力

重建的負載壓力均勻分布于整個系統

降低了雙重故障的風險

改進了重建期間的性能

保護方式

一般在同一磁盤托架中

相同副本數據位于不同的設備模塊之中

降低了雙重故障的風險

控制器(模塊)故障

時的系統行為

單主控故障緩存機制失效，性能大幅下降。同時面臨雙重故障風險

模塊故障后系統冗余迅速重建，重建期間性能無下降。

降低了雙重故障的風險

故障期間仍然保持高性能。

建設成本

需要HBA卡、FC交換機，服務器磁盤浪費。

充分利用服務器本地磁盤，無需HBA及FC設備。

總體成本低

數據中心數據復制技術：分布式存儲與傳統集中存儲的比較分布式存儲架構說明

VM

重要應用

X86

ServerVM

普通應用1

VM

普通應用2

VM

數據庫

VM

重要應用

X86

ServerVM

普通應用1

VM

普通應用2

VM

數據庫

網絡虧聯

VM

重要應用

X86

ServerVM

普通應用1

VM

普通應用2

VM

數據庫

基亍X86的分布式存儲系統

架構特點：第一是計算不存儲的融合；第二是滿足大數據對每個節點存儲需求的線性增長；第三是滿足每個節點IO性能需求的線性增長。分布式存儲為外部主機提供存儲的自動負載均衡

虛擬機

x86物理主機

虛擬機

x86物理主機

虛擬機

x86物理主機

虛擬機

x86物理主機IPSAN?每次IO由多路徑軟件選擇承載該次IO的存儲節點（負責存儲系統與發起該IO的應用服務器之間的通信），實現網絡負載均衡、節點間均衡負載?在存儲系統內，系統根據忙閑程度選擇具體承載某IO的副本節點，獲得最佳性能的I/O負載平衡分布式存儲架構具備超強的故障恢復能力以空閑的硬盤作為熱備,多對一重構，且參不重構的硬盤數通常丌超過10塊。熱備盤傳統RAID組Sparechunks分布式存儲重構時間

可靠性 性能傳統RAID組 10小時/TB左右

重構期間無保護，易造成數據丟失。重構期間讀性能大幅降低。分布式存儲 20分鐘/TB左右

分布式存儲大大降低風險窗口。性能無影響。任意一塊磁盤故障，剩余全部磁盤都參不重構，多對多重構，過程無瓶頸。zone1zone2zone3site2?支持將所有的zone劃分至丌同的site?數據寫入時，將丌同副本分布在丌同的site中?允許同一個site整體故障而丌影響業務的正常運行分布式存儲多數據中心解決方案zone1zone2zone3site1zone1zone2zone3site3數據中心計算技術：OPENSTACK

NOVA主流虛擬化平臺調度技術OpenstackOS云系統

OpenStackNovavCenter`ESXIVMVMVM`ESXIVMVMVM`ESXIVMVMVMCVM`CVKVMVMVM`CVKVMVMVM`CVKVMVMVMXenCenter`XenServerVMVMVM`XenServerVMVMVM`XenServerVMVMVMKVM`kvmVMVMVM`kvmVMVMVM`kvmVMVMVMCASplug-in VMwarePlug-in CitrixPlug-in KVMOpenstack

OS云操作系統能夠同時調度業界主流虛擬化平臺

CAS VMware Citrix KVM原理：通過為不同的虛擬化軟件開發特定的插件，實現對異構虛擬化平臺的調度；

創建虛擬機

刪除虛擬機

重啟虛擬機

更改虛擬機

向用戶交付虛擬機時，屏蔽底層虛擬化差異

2核/4G/50GWindowsServer2008分布式數據中心基亍OPENSTACK開源于管理平臺單數據中心部署功能模塊數據中心網絡虧聯技術：建網模式的選擇數據中心網絡虧聯技術：建網模式的選擇網絡資源池化：交換矩陣（vFabric）交換矩陣混合Overlay模型

vSwitch支持VTEP功能，使VM接入VXLAN網絡。物理機接入VXLAN網絡，通過支持VTEP功能的Leaf設備來實現。其它Leaf無需支持VTEP。

N:1的核心（Spine）備份

分布式IP網關SpineLeafL2L3L3ECMPvSwitch管控平臺vSwitch vSwitchVM VM VMSpineLeafL2L3L3ECMP管控平臺vSwitch vSwitchVM VM網絡Overlay模型

Leaf支持VTEP功能，VM和物理機都通過Leaf設備來接入VXLAN網絡。

N:1的核心（Spine）備份

分布式IP網關名稱

支持者

方案簡述

產品形式

網絡虛擬化方式

數據新增

報頭長度

技術特點VXLAN

Cisco、VMware、HP、Citrix、RedHat、Broadcom

L2over

UDP

Cisco:N1000VBCM:Trident2其他：OpenvSwitch

VXLAN報頭

24bit

VNI

50Byte

不改變L2~L4報文結構，現有網絡設備即可支持多路徑負載均衡。NVGRE

微軟、HP、Broadcom、

Dell、Emulex、Intel

L2over

GRE

微軟:Hyper-VvSwitchBCM:TridentEmulex:網卡

其他：OpenvSwitch

NVGRE報頭

24bit

VSI

42Byte

問題：改變了GRE報文頭，需要升級網絡設備才能支持多路徑負載均衡。

STT

Nicira(被Vmware收購)

無狀態TCP

vSwitch

STT報頭

64bitContext

ID

58~76Byte

問題：改變了TCP報文頭，當前無商用芯片支持，僅VMware純虛擬化環境可用，產業生態脆弱。Cisco也不支持

Overlay三大技術流派，以VXLAN最為成熟，產業鏈極為健壯，是事實上的標準。服務器機房vSwitch vSwitch

vSwitch網絡機房分布式IP網關：混合Overlay模型SpineLeafL2L3L3ECMPvSwitchVM

業務1-網關

業務2-網關

業務3-網關

業務4-網關IP：

MAC:0011-1111-22220011-1111-33330011-2222-33330011-2222-5555VM VM VM

Leaf交換機屬于所有的業務區域

業務的IP網關——VM的IP網關存在于所有的vSwitch上，物理服務器的IP網關在支持VTEP功能的Leaf交換機上

Leaf交換機下的服務器服務于所有的業務區域。也就是說，服務器的部署位置丌受網絡的限制。

業務部署靈活，不位置無關。服務器資源池化業務1、業務2、業務3、業務4可在任意位置部署L2L3VCF控制器混合overlay模型中，Leaf交換機屬于所有的業務區域，業務的IP網關—VM的IP網關存在于所有的vSwitch上，物理服務器的IP網關在支持VTEP功能的Leaf交換機上，Leaf交換機下的服務器服務于所有的業務區域。也就是說，服務器的部署位置不受網絡的限制。業務部署靈活，與位置無關。

網絡機房服務器機房分布式IP網關—網絡Overlay模型SpineLeafL2L3L3ECMP

業務1-網關

業務2-網關

業務3-網關

業務4-網關IP：

MAC:0011-1111-22220011-1111-33330011-2222-33330011-2222-5555

Leaf交換機屬于所有的業務區域

業務的IP網關——VM和物理服務器的IP網關都在Leaf交換機上

Leaf交換機下的服務器服務于所有的業務區域。也就是說，服務器的部署位置丌受網絡的限制。

業務部署靈活，不位置無關。vSwitchVMvSwitchVMvSwitchVMvSwitchVM服務器資源池化業務1、業務2、業務3、業務4可在任意位置部署業務的IP網關—VM和物理服務器的IP網關都在Leaf交換機上，Leaf交換機下的服務器服務于所有的業務區域。也就是說，服務器的部署位置不受網絡的限制。業務部署靈活，與位置無關

雙活數據中心客戶端切換技術方式1：智能DNS全局站點選擇（GSS）GSS和負載均衡，后者對服務器健康檢查并通知GSSLayer3CoreISPA

Intranet ISPBAccessAggAccessDCA

DCBVLANA

00

00

GSSSNAT SNATL2Links

(GEor10GE)L3Links

(GEor10GE)ACE

ACE

基于“名字”：智能DNS解析

GSS）

基于“地址”：位置與地址分離協議（LISP）

L2Links

(GEor10GE)L3Links

(GEor10GE)Layer3CoreISPA

Intranet ISPBAccessAggAccessAggDCA

DCBVLANA

PublicNetworkPrefix RouteLocator10.10.10.1 A,B10.10.10.2 A,B… …10.10.10.5 C,

D10.10.10.6 C,

DIngress

Tunnel

IP_DA=AC,D321IP_DA=D 3客戶端切換技術方式2：在地址和路由上實現資源重定位（LISP：Locator-ID

Separation

Protocol）

基于“名字”：智能DNS解析

GSS）

基于“地址”：位置與地址分離協議（LISP）

基于傳統商業級集中式技術架構構建互聯網金融云數據中心及災備中心雙控制器

metroCluster

Active-ActiveESX備份代理城域互聯RTT<5msFC集中存儲陣列集中監控控制臺核心路由器/交換機ESX ESX ESX ESX ESX備份代理IP/BGP基亍NetappMetrocluster同城存儲級雙活+VmwareHA、FT主機高可用平臺級雙活實現機制DWDMDWDM雙控制器

metroClusterActive-Active

Agg1

Agg2

Agg3

Agg4

Agg1

Agg2

Agg3

Agg4

基亍NetappMetroCluster同城存儲層雙活數據syncmirror同步復制工作機制51DataCenter#1DataCenter#2

Host1Host2DC1Primary DC2PrimaryDC2MirrorFAS1 FAS2DC1MirrorWindow1VmwareESX1VmwareWindow2 ESX2光纖交換機

FCSwitch存儲控制器

光纖交換機

存儲控制器

FCSwitch距離小于100公里

FC磁盤柜

FC磁盤柜

光纖交換機

FCSwitch存儲系統控制器和磁盤柜均互為鏡像，完全物理冗余，并且互為失敗切換，為關鍵業務應用提供最好的高可用性。

FC FCFC FCFC FC52對于非RPO=0的業務系統，推薦使用

VMware

vCenter

Site

RecoveryManager

(SRM)

與

NetApp

存儲的Snapmirror異步數據復制技術，能夠顯著縮短恢復時間目標

(RTO)

和恢復點目標

(RPO)

基亍Netapp

Snapmirror同城存儲級數據異步復制機制+Vmware

SRM站點自動恢復實現同城災備切換1、現網絡設備采用Juiper設備，通過單第三方ISP上聯到level3運營商2、現網采用靜態路由方案與ISP進行互聯3、現網無DNS負載，DNS負載由運營商實現災備中心網絡架構-現有網絡架構災備中心網絡架構-采用JUIPER

MPLS二層VPN

VPLS技術構建SiSi SiSi內聯區Internet接入區外聯區三大運營商Internet主中心 災備中心SiSi SiSi內聯區Internet接入區外聯區EBGP EBGPEBGP EBGP核心交換區生產應用區核心交換區生產應用區VPLSVPLS可以同時

支持同IP的VM遷移以及雙活

VM的應用層

同步。網絡

采用VPLS方式進行

支撐，網絡

自適應軟件

架構。

容災網絡架構演進—新網絡架構特點網絡架構新特性：

1、Internet雙節點異地接入；

2、新增Internet邊界路由器，使用EBGP方案與第三方運營商對接。

3、新增全局DNS負載設備。

優勢：

1、互聯網接入雙級冗余，提高可用性。

2、采用EBGP

方案對接，實現靈活調度控制、提高網絡自愈能力。

3、GSLB實現業務級靈活調度，提高整體業務級自愈能力。

4、高擴展架構、實現網絡及業務分級解耦。未來擴展將十分簡單。

容災網絡架構GSLB

容災網絡架構演進-Internet

出口流量切換總結（互聯網金融災備數據中心建設技術建議）總體災備建設技術演進思路59積極采用不同層面的災備技術分步驟分層次滿足網金控股各業務系統基于未來互聯網金融云數據中心的建設戰略

首先應充分挖掘并利用已有核心設備的潛力去構建主數據中心和災備數據中心的災備基礎架構

對于未來新業務的快速部署以及大幅降低采購成本，應積極采用開源分布式云計算基礎架構部署模式逐步替換基于集中式存儲模式的災備部署模式

1）對于核心業務系統，建議采用Netapp