金融企业灾备应用快速部署及持续同步方案.docx

金融企业灾备应用快速部署及持续同步方案 目 录1、背景32、痛点分析33、现状介绍34、灾备建设需求及选型54.1 灾备建设目标综述54.2 灾备应用资源池建设需求64.2.1 生产应用资源池部署情况64.3 灾备应用池测试及选型过程85、结果展现及探讨12本文探讨了在金融企业云化转型阶段，如何利用云计算带来的新技术、新特性，实现大规模灾备应用分区的快速部署及应用持续自动同步。1、背景近些年大数据、云计算、移动互联技术迅速发展，快速交付与灵活扩展的需求强烈增长，传统竖井式的IT基础架构已无法应对新型业务的需求。因此各大企业都在积极推动的云化转型，但受制于传统IT基础架构体量，云化转型的步伐显然要沉重缓慢一些，代价也更大。在此阶段建设灾备系统有利有弊，不便之处是企业在架构转型阶段，基础架构、应用架构复杂度更高，需要考虑的细节也更多；好的方面是可以利用云计算带来的新技术、新特性解决灾备中的一些关键问题，如：大规模灾备应用分区的快速部署及应用持续自动同步，本文主要就这两个问题展开探讨。2、痛点分析（以本文的背景项目为例）某大型保险公司采用以南中心为依托的全国信息系统大集中运行，需要在北京建立异地灾备中心，实现核心生产系统的应用级容灾。针对灾备应用资源池建设，面临现有问题如下：1. 当前正在租用的北京IDC机房空间、电力资源快要耗尽，但本次项目时间紧、任务重，新建或租用新机房无法满足要求；2. 建设内容复杂，涉及100+个应用，总计1300+个应用虚拟机，更加需要注意的是灾备系统建成后的虚拟机承载的应用如何与生产端保持持续同步；3. 当前应用服务器根据业务需求采用小型机及x86平台两种部署方式，灾备应用服务器需同时满足性能及平台兼容性要求；4. 公司已有云管理平台，新建应用灾备资源池须可以与云管理平台对接，以满足资源统一管理、批量分配的需求。3、现状介绍（云平台建设情况）云平台项目于2014年下半年适时而起，其初期目标是建设功能全面的IaaS云平台。在落地过程中，通过基于Openstack架构的云管理平台实现对公司各个数据中心的物理层、虚拟化层和虚拟主机环境的端到端管理；提高多数据中心不同逻辑环境下的资源交付能力；扭转无法对支撑业务运行的环境全面掌控的局面；保障业务的稳定运行、快速切换，持续优化 IT 系统的业务价值。图1：云管理平台功能与组件架构图云平台的建设为灾备体系的快速形成打下了良好的基础，体现在如下方面： 以Openstack为核心的云管理平台，保证平台的先进性与可持续发展； 逐步实现对企业各级别虚拟化资源池的统一纳管，降低资源管理复杂度； 通过重新制定资源交付流程，结合云平台的工作编排引擎功能，提升资源交付效率； 通过定制的Portal门户提供对外围系统的接口支持，有效整合关联IT资源管理平台，实现对IT资源全生命周期的管理。图2：云管理平台建设功能4、灾备建设需求及选型4.1 灾备建设目标综述根据“十三五规划”相关内容以及银保监会对于灾备建设的相关要求，建成北京机房备份中心和研发测试环境，形成“南北互备”的格局，并在未来形成“两地三中心”的格局。对于灾备应用资源池来说，目前生产应用资源池已基本实现资源虚拟化及云化管理，实际灾备建设中我们一方面是在现有云管理平台的基础上通过引入新技术组件完善Iaas层平台能力，为灾备应用资源池的建设提供必要的组件功能支撑；另一方面通过构建Paas能力平台，为应用提供简化部署、监控、运维和治理等应用生命周期管理的能力，支撑应用完成微服务架构转型及灾备需求实现：图3：基于云平台的灾备体系架构图4.2 灾备应用资源池建设需求4.2.1 生产应用资源池部署情况南中心承载着公司集中部署和分省部署的核心业务，涵盖了公司承保、理赔、财务、渠道、再保及专项系统等业务类型，应用基础架构采用虚拟化部署架构。根据应用系统访问特征，建立了三类资源池： PowerBlade资源池。对于分省部署承保类应用，其生产特性为用户访问量大，对快速计算要求高，Weblogic Server数量多，采用计算能力更强的Power blade 资源池； VMware资源池。对于分省部署单证、打印、数据字典等公共类或者理赔类相对承保及时性较低应用系统，快速计算要求相对承保低，Weblogic Server数量相对承保少；公共类服务系统接口多，日常有及时调整资源的情况相对较多，采用更灵活的VMware 资源池，更加适合快速部署虚机、在线动态迁移功能有效利用。 Citrix资源池。对于集中部署的应用，及时性较低应用系统，快速计算要求相对承保低， Weblogic Server数量相对承保少；公共类服务系统接口多，日常有及时调整资源的情况相对较多，采用更灵活的Citrix 资源池，更加适合快速部署虚机、在线动态迁移功能有效利用。4.2.2 灾备应用资源池建设原则完整性原则：保证灾难发生而导致生产中心不可用的情况下，核心及其外围系统在北京备份中心可以得到完整的应用功能的恢复。开放性原则：系统符合具备优良的可扩展性、可升级性和灵活性，对现有技术具有普适能力，可以广泛支持开放系统平台，运行于现有或即将成为标准的各种存储相关技术上。兼容性原则：与现有系统需要完全兼容，各个构成子系统必须紧密衔接，高度集成，构成整体。安全性原则：确保应用系统的安全运行和故障恢复机制。可管理性原则：可以对系统进行集中管理和监控。成熟性原则：在满足所有需求的前提下，选择最合适的设备及管理软件，使系统具有较好的性能价格比和稳定性。前瞻性原则：选择的软硬件技术，需要满足未来两地三中心各阶段建设的需要，实现平滑过渡。投资保护原则：系统建设充分考虑目前已实施系统的实际情况，充分利用原有系统资源，保护原有系统的投资。4.2.3 灾备应用资源池建设目标遵循灾备建设原则，参照金融行业灾备建设模型，本次灾备应用资源池的建设目标为：图4：金融业灾备建设模型 实现企业内部100多个核心（每个省一套，30多个省）关键业务系统的灾备能力建设； 计算能力与生产环境相当（Power、x86两种）； 计算能力基于项目当年业务规模，可支撑未来2年业务发展； 满足RPO、RTO灾备切换时间要求；图5：灾备项目建设的场景与需求设定4.3 灾备应用池测试及选型过程4.3.1 选型基本思路灾备平台基础要求: 成熟稳定的硬件平台 具有良好的兼容性 可以节省空间/电力灾备平台进阶要求: 与现有云管平台无缝融合 可以快速搭建大规模的灾备环境 灾备端可以自动检测并批量更新应用程序4.3.2 选型测试要点 当前应用服务器根据业务需求采用小型机及x86平台两种部署方式，灾备应用服务器需同时满足性能及平台兼容性要求； 公司已有云管理平台，新建应用灾备资源池须可以与云管理平台对接，以满足资源统一管理、批量分配的需求； 用户核心应用目前以Weblogic为主，目前weblogic官方有服务的最低版本weblogic10和最新的weblogic12版本均有使用；且由于历史原因，部分应用还在使用Weblogic 9.2.3（已经退市，官方无服务），短期内无法替换，灾备服务器操作系统必须支持weblogic 9.2.3。4.3.3 选型考虑在对国内、外多个大型服务器厂商，各种高、中、低端设备测试选型后，本次灾备系统应用服务器最终选用基于LinuxONE开放架构平台的解决方案。LinuxONE采用与IBM System Z相同的硬件架构，本次灾备系统只使用了2台LinuxONE服务器就解决了1200+灾备应用服务器的需求；其高密度整合能力，有效规避了本次项目建设中机房空间、电力消耗有限的问题；与Openstack云管理架构集成，与现有云管理平台无缝衔接，通过云管理平台的资源批量分配功能实现了1200+灾备应用服务器的批量快速部署；通过对LinuxONE资源池的部署功能的深度定制开发，在云管理平台中实现了应用的自动部署及自动同步更新能力，保证了灾备系统建成后应用长期持续同步，为灾备系统业务连续性提供了保障。4.3.4 功能测试 测试场景 1- 利用Openstack自动部署灾备环境基础架构图6：OpenStack自动部署功能实现逻辑1. Openstack快速克隆SLES11 sp 4 + Weblogic 9.2.32. 自动从FTP上下载Weblogic 应用包和自动部署脚本文件3. 自动启动Weblogic创建Weblogic域，节点和数据源4. 自动部署Weblogic应用 测试场景 2- 利用Ansible自动检测，批量更新Weblogic应用程序图7：Ansible自动检测功能逻辑1. Ansible自动从FTP上下载Weblogic 应用包和自动部署脚本文件2. Ansible自动根据不同的分组批量更新不同的应用程序3. Ansible自动判断应用程序是否更新，如果没有更新则不会做任何更改4. 可将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版本的控制节点进行集成，实现云平台的统一纳管。图9：基于云平台的多资源池管理遇到的问题：我们在测试过程中选取了客户车险承保应用中的用户，单点和数据字典3个子应用作为试点进行了测试，通过脚本定制实现了应用自动部署、自动同步更新测试，但像这样的应用客户有好几百个，如何以更加自动、更智能的方式实现所有应用的自动部署及自动同步更新，是我们接下来面对的重点问题。图10：应用试点测试场景需要进一步探讨：思路1.基于已有的Openstack+Ansible的模式思路2.基于DevOps研发运维一体化过程方法