1、 金融企業災備應用快速部署及持續同步方案 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66542643 1、背景 PAGEREF _Toc66542643 h 3 HYPERLINK l _Toc66542644 2、痛點分析 PAGEREF _Toc66542644 h 3 HYPERLINK l _Toc66542645 3、現狀介紹 PAGEREF _Toc66542645 h 3 HYPERLINK l _Toc66542646 4、災備建設需求及選型 PAGEREF _Toc66542646 h 5 HYPERLINK l _Toc66542647 4.1

2、 災備建設目標綜述 PAGEREF _Toc66542647 h 5 HYPERLINK l _Toc66542648 4.2 災備應用資源池建設需求 PAGEREF _Toc66542648 h 6 HYPERLINK l _Toc66542649 4.2.1 生產應用資源池部署情況 PAGEREF _Toc66542649 h 6 HYPERLINK l _Toc66542650 4.3 災備應用池測試及選型過程 PAGEREF _Toc66542650 h 8 HYPERLINK l _Toc66542651 5、結果展現及探討 PAGEREF _Toc66542651 h 12本文探討

3、了在金融企業云化轉型階段，如何利用云計算帶來的新技術、新特性，實現大規模災備應用分區的快速部署及應用持續自動同步。1、背景近些年大數據、云計算、移動互聯技術迅速發展，快速交付與靈活擴展的需求強烈增長，傳統豎井式的IT基礎架構已無法應對新型業務的需求。因此各大企業都在積極推動的云化轉型，但受制于傳統IT基礎架構體量，云化轉型的步伐顯然要沉重緩慢一些，代價也更大。在此階段建設災備系統有利有弊，不便之處是企業在架構轉型階段，基礎架構、應用架構復雜度更高，需要考慮的細節也更多；好的方面是可以利用云計算帶來的新技術、新特性解決災備中的一些關鍵問題，如：大規模災備應用分區的快速部署及應用持續自動同步，本文

4、主要就這兩個問題展開探討。2、痛點分析（以本文的背景項目為例）某大型保險公司采用以南中心為依托的全國信息系統大集中運行，需要在北京建立異地災備中心，實現核心生產系統的應用級容災。針對災備應用資源池建設，面臨現有問題如下：當前正在租用的北京IDC機房空間、電力資源快要耗盡，但本次項目時間緊、任務重，新建或租用新機房無法滿足要求；建設內容復雜，涉及100+個應用，總計1300+個應用虛擬機，更加需要注意的是災備系統建成后的虛擬機承載的應用如何與生產端保持持續同步；當前應用服務器根據業務需求采用小型機及x86平臺兩種部署方式，災備應用服務器需同時滿足性能及平臺兼容性要求；公司已有云管理平臺，新建應用

5、災備資源池須可以與云管理平臺對接，以滿足資源統一管理、批量分配的需求。3、現狀介紹（云平臺建設情況）云平臺項目于2014年下半年適時而起，其初期目標是建設功能全面的IaaS云平臺。在落地過程中，通過基于Openstack架構的云管理平臺實現對公司各個數據中心的物理層、虛擬化層和虛擬主機環境的端到端管理；提高多數據中心不同邏輯環境下的資源交付能力；扭轉無法對支撐業務運行的環境全面掌控的局面；保障業務的穩定運行、快速切換，持續優化 IT 系統的業務價值。圖1：云管理平臺功能與組件架構圖云平臺的建設為災備體系的快速形成打下了良好的基礎，體現在如下方面： 以Openstack為核心的云管理平臺，保證平

6、臺的先進性與可持續發展； 逐步實現對企業各級別虛擬化資源池的統一納管，降低資源管理復雜度； 通過重新制定資源交付流程，結合云平臺的工作編排引擎功能，提升資源交付效率； 通過定制的Portal門戶提供對外圍系統的接口支持，有效整合關聯IT資源管理平臺，實現對IT資源全生命周期的管理。圖2：云管理平臺建設功能4、災備建設需求及選型4.1 災備建設目標綜述根據“十三五規劃”相關內容以及銀保監會對于災備建設的相關要求，建成北京機房備份中心和研發測試環境，形成“南北互備”的格局，并在未來形成“兩地三中心”的格局。對于災備應用資源池來說，目前生產應用資源池已基本實現資源虛擬化及云化管理，實際災備建設中我們

7、一方面是在現有云管理平臺的基礎上通過引入新技術組件完善Iaas層平臺能力，為災備應用資源池的建設提供必要的組件功能支撐；另一方面通過構建Paas能力平臺，為應用提供簡化部署、監控、運維和治理等應用生命周期管理的能力，支撐應用完成微服務架構轉型及災備需求實現：圖3：基于云平臺的災備體系架構圖4.2 災備應用資源池建設需求4.2.1 生產應用資源池部署情況南中心承載著公司集中部署和分省部署的核心業務，涵蓋了公司承保、理賠、財務、渠道、再保及專項系統等業務類型，應用基礎架構采用虛擬化部署架構。根據應用系統訪問特征，建立了三類資源池：PowerBlade資源池。對于分省部署承保類應用，其生產特性為用戶

8、訪問量大，對快速計算要求高，Weblogic Server數量多，采用計算能力更強的Power blade 資源池；VMware資源池。對于分省部署單證、打印、數據字典等公共類或者理賠類相對承保及時性較低應用系統，快速計算要求相對承保低，Weblogic Server數量相對承保少；公共類服務系統接口多，日常有及時調整資源的情況相對較多，采用更靈活的VMware 資源池，更加適合快速部署虛機、在線動態遷移功能有效利用。Citrix資源池。對于集中部署的應用，及時性較低應用系統，快速計算要求相對承保低， Weblogic Server數量相對承保少；公共類服務系統接口多，日常有及時調整資源的情況

9、相對較多，采用更靈活的Citrix 資源池，更加適合快速部署虛機、在線動態遷移功能有效利用。4.2.2 災備應用資源池建設原則完整性原則：保證災難發生而導致生產中心不可用的情況下，核心及其外圍系統在北京備份中心可以得到完整的應用功能的恢復。開放性原則：系統符合具備優良的可擴展性、可升級性和靈活性，對現有技術具有普適能力，可以廣泛支持開放系統平臺，運行于現有或即將成為標準的各種存儲相關技術上。兼容性原則：與現有系統需要完全兼容，各個構成子系統必須緊密銜接，高度集成，構成整體。安全性原則：確保應用系統的安全運行和故障恢復機制。可管理性原則：可以對系統進行集中管理和監控。成熟性原則：在滿足所有需求的

10、前提下，選擇最合適的設備及管理軟件，使系統具有較好的性能價格比和穩定性。前瞻性原則：選擇的軟硬件技術，需要滿足未來兩地三中心各階段建設的需要，實現平滑過渡。投資保護原則：系統建設充分考慮目前已實施系統的實際情況，充分利用原有系統資源，保護原有系統的投資。4.2.3 災備應用資源池建設目標遵循災備建設原則，參照金融行業災備建設模型，本次災備應用資源池的建設目標為：圖4：金融業災備建設模型實現企業內部100多個核心（每個省一套，30多個省）關鍵業務系統的災備能力建設；計算能力與生產環境相當（Power、x86兩種）；計算能力基于項目當年業務規模，可支撐未來2年業務發展；滿足RPO、RTO災備切換時

11、間要求；圖5：災備項目建設的場景與需求設定4.3 災備應用池測試及選型過程4.3.1 選型基本思路災備平臺基礎要求:成熟穩定的硬件平臺具有良好的兼容性可以節省空間/電力災備平臺進階要求:與現有云管平臺無縫融合可以快速搭建大規模的災備環境災備端可以自動檢測并批量更新應用程序4.3.2 選型測試要點當前應用服務器根據業務需求采用小型機及x86平臺兩種部署方式，災備應用服務器需同時滿足性能及平臺兼容性要求；公司已有云管理平臺，新建應用災備資源池須可以與云管理平臺對接，以滿足資源統一管理、批量分配的需求；用戶核心應用目前以Weblogic為主，目前weblogic官方有服務的最低版本weblogic1

12、0和最新的weblogic12版本均有使用；且由于歷史原因，部分應用還在使用Weblogic 9.2.3（已經退市，官方無服務），短期內無法替換，災備服務器操作系統必須支持weblogic 9.2.3。4.3.3 選型考慮在對國內、外多個大型服務器廠商，各種高、中、低端設備測試選型后，本次災備系統應用服務器最終選用基于LinuxONE開放架構平臺的解決方案。LinuxONE采用與IBM System Z相同的硬件架構，本次災備系統只使用了2臺LinuxONE服務器就解決了1200+災備應用服務器的需求；其高密度整合能力，有效規避了本次項目建設中機房空間、電力消耗有限的問題；與Openstack

13、云管理架構集成，與現有云管理平臺無縫銜接，通過云管理平臺的資源批量分配功能實現了1200+災備應用服務器的批量快速部署；通過對LinuxONE資源池的部署功能的深度定制開發，在云管理平臺中實現了應用的自動部署及自動同步更新能力，保證了災備系統建成后應用長期持續同步，為災備系統業務連續性提供了保障。4.3.4 功能測試測試場景 1- 利用Openstack自動部署災備環境基礎架構圖6：OpenStack自動部署功能實現邏輯Openstack快速克隆SLES11 sp 4 + Weblogic 9.2.3自動從FTP上下載Weblogic 應用包和自動部署腳本文件自動啟動Weblogic創建Web

14、logic域，節點和數據源自動部署Weblogic應用測試場景 2- 利用Ansible自動檢測，批量更新Weblogic應用程序圖7：Ansible自動檢測功能邏輯Ansible自動從FTP上下載Weblogic 應用包和自動部署腳本文件Ansible自動根據不同的分組批量更新不同的應用程序Ansible自動判斷應用程序是否更新，如果沒有更新則不會做任何更改可將Ansible設置自動任務，應用程序更新后用戶只需將新的應用放到指定目錄即可實現災備的應用更新測試結果: 應用不做任何修改完全兼容,部署上線過程快捷。圖8：測試結果總結4.3.4 性能測試測試場景：以2014年某省分公司四季度性能測試環境為參考，選取相同的壓力模型，通過性能測試工具向應用環境發送相同的壓力。通過得到與X86基準單元相同的業務響應時間獲得LinuxONE的參考配置。測試過程數據統計：測試結論：交易響應時間相近，3顆IFL處理器可以提供2臺X440刀片服務器相同的計算能力。4.3.4 關鍵數據比對參考5、結果展現及探討云管理平臺通過調用標準OpenStack API，實現其對外服務，包括流程設計和管理、用戶門戶（Portal）和服務編排等。 云管平臺基于OpenStack Ocata版本開發完成。LinuxONE平臺通過Nova API與OpenStack Ocata版本的控制節點進行集成，實