文章摘要：
  本文主要分享了内蒙农信银行关键业务系统基于浪潮K1 Power服务器构建同城容灾中基础设施云环境的经验和思考。从对现有环境下的需求分析到基础设施云的架构选型和设计，结合银行同城容灾建设，介绍建设的思路和整体建设效果，为银行关键业务混合多云管理提供敏捷、安全、高效的最佳应用实践。

作者简介： 王丰刚 内蒙古自治区农村信用社联合社信息科技部运维中心主管，主要负责同城双活数据中心建设和运维技术管理方面工作。

---

一、项目背景

  近些年来，随着国内云计算的快速发展，几乎所有金融机构均已经应用云计算技术，特别是基础设施层次的服务（基础设施即服务，IaaS）。2015 年，国务院在《关于积极推进“互联网+”行动的指导意见》中明确鼓励金融机构探索利用云平台开展业务，金融上云早就已经成为行业共识。当然，云计算技术本身的优势也是金融机构上云的重要原因，使用云计算技术使得IT资源利用率不断提升，便捷的管理也使得用户可将更多的精力专注于核心能力的竞争。

  同时，随着金融行业信息科技的发展，信息科技对于金融行业的作用也在不断增加。这些年来，中国人民银行和中国银行业监督委员会发布了包括《商业银行业务连续性监管指引》、《中国银行业信息科技“十二五”发展规划监管指导意见》、《银行业信息系统灾难恢复管理规范》等文件，要求金融机构建设自己的灾难恢复体系，提升金融机构业务连续性。

  鉴于行业发展的状况和监管要求，基于行内实际情况，近几年来我行不断完善同城容灾体系。本项目是基于以上背景，考虑我行关键业务系统容灾体系建设，通过更换运行多年的设备，并采用云计算技术为我行建设和完善数据中心的整体架构。

二、需求和痛点分析

  当前行内除了核心系统使用AS400服务器之外，其余关键业务系统主要使用浪潮K1 Power服务器，支撑了包括农信银，网银，超级网银、统一柜面、IC卡、信贷等支付相关的关键业务系统。本项目拟更换当前使用多年的  Power服务器，基于同城容灾的建设需求，构建基于浪潮K1 Power服务器的基础设施云环境。考虑当前生产中心的运行和同城中心的建设情况，统筹分析我行当前应用和基础设施架构存在的困扰和痛点。

  为满足同城容灾的应用级要求，各个业务系统的部署模式都将发生了变化，当前情况下基于浪潮K1 Power服务器承载应用均部署在生产中心，采用本地高可用的方式实现了业务系统连续性保护。

  因此，经过行内就此类关键业务系统的建设方案进行了深入的讨论和研究，因为涉及到的应用系统数量相对比较多，尽量在不改变原有版本的情况下将系统部署到两个中心，那么使用的存储如何考虑，数据库层如何部署，应用层是否采用集群模式，采用何种集群方式，以前网络访问方式等等同城灾备相关的问题都是需要详细考虑和讨论的，这些应用层相关技术方案的确定就会影响到基础设施硬件设备的新增数量和性能要求。

1. 如何将当前应用系统和数据库迁移到两个中心新增设备上，并且保证数据一致性、快速而高效，是本项目的重要关注点。当前应用系统和数据库均部署在生产中心，迁移可以考虑的方式有应用系统重新部署、数据库迁移技术、存储层卷拷贝、操作系统克隆等方法。此外，由于同城距离和带宽的因素，从生产中心迁移到同城中心还需要进一步考虑和测试才能制定出一个最佳的迁移方法。
2. 资源使用率涉及到建设的成本问题，也是一个需要考虑的问题。原生产环境使用的DLPAR(动态逻辑分区)方式部署服务器分区，每台服务器均固定划分2-4个分区，CPU或内存等资源虽然可以在物理服务器内进行适当调整，但是仍然存在资源使用不均衡的问题。部分服务器上的分区繁忙，部分服务器上的分区非常空闲。

  另外还要考虑有的业务需要跑批等问题。所以，在没有很好的办法时，采取较为粗犷的管理方式，只要资源没有出现不足的情况，就不做主动的调整，整体资源使用的效率不高。

  因此，综合考虑上述一些问题和需求，总结本项目需求如下：

（一）业务连续性

  在建设同城容灾中心过程中，业务连续性的需求是最重要的一个点，整体项目建成后需要提升行内各个应用系统的业务连续性。行内业务系统根据实际情况进行分级管理，根据应用系统实际情况来部署实现应用层、数据库层的架构，实现不同的业务实现不同的业务连续性需求。

（二）正确计算新增服务器资源

  经过对本项目中需要部署在浪潮K1 Power服务器上的应用系统进行准确计算，考虑数据库本地集群和复制所需资源、应用系统集群部署资源、未来几年业务所需资源增量以及Power服务器计算能力增长，综合考虑服务器计算资源。

（三）管理便捷性

  浪潮K1 Power服务器一直采用HMC对机器进行分区、资源配置等管理操作，但是无法进行一些更便捷的操作，每次创建一个新的环境也需要较多的操作步骤，特别对于虚拟化环境的管理，还需要在VIOS中进行一些配置操作，确实比较繁琐。为了能够解决这类应用环境交付的效率不高的问题，本项目建成后应该具备更便捷的管理能力，让管理员将更多的精力投入到核心竞争力的提升上，不再一直做重复性工作。

（四）资源池化

  资源化池是云计算中的一个重要特性和优势，资源池化后可以使得资源的整体利用率大大提升，另外也能够使得资源的管理和调配更加便捷。通过一定的隔离手段和自动化功能，也可以实现资源的动态调度，解决资源使用不均衡的问题。

三、基于Power云架构设计的技术路线选择与实施

  目前行内生产中心和同城中心均在运行中，两中心光纤链路约100km，项目实施前关键业务系统大部分部署在生产中心，建成后要求同城中心与当前生产中心将同时提供生产服务，前端通过负载均衡的方式对关键业务系统进行访问。关于Power云架构设计阶段的技术路线选择，行内技术人员和专家经过多次讨论和研究，主要有以下几个关键点：

一是采用资源池化方案，或部分采用资源池化方案
  关于使用基于PowerVM技术的Power服务器资源池来支撑关键业务系统是一个比较一致的选择，行内多年来一直使用PowerVM在测试环境、部分生产环境中部署，已经积累了大量的实践经验。但是，对于最核心的几个数据库系统仍然相对保守的使用DLPAR（动态逻辑分区）的方式来部署，确保资源的专用型。因此最终采用了    DLPAR分区和虚拟分区并存的方式进行部署。

二是如何管理生产和同城中心的资源池
  PowerVC是管理Power资源池的云管理平台，PowerVC在行内的应用已经有3年以上的使用，主要用于测试环境，经过这几年的使用和测试，行内对于PowerVC的使用便捷性和稳定性均比较认可，因此本项目中将 PowerVC引入到生产中心和同城中心的生产环境上。
  那么是使用同一个PowerVC来管理两个中心，还是两个中心分别管理是方案讨论的主要焦点。考虑到Power-VC本身并不具备灾备管理能力，本项目最终选择的是分别在两个中心搭建2套PowerVC管理平台，分别管理两个中心的资源池。另外，分别为PowerVC管理平台在对端搭建备份分区，确保PowerVC本身的灾备切换。

三是数据复制和灾备切换方式选择
  常见的数据复制主要是存储层复制和数据库层复制，考虑到两个中心的距离和链路等实际情况，我们选择采用数据库复制ADG和少量存储卷异步复制相结合的方式。同时在应用层，如果应用系统可支持集群部署即可在两个中心部署集群，如果不支持就在对端部署备份分区。配合两个中心打通的网络系统和负载均衡，这样就整体实现了应用层的灾备体系。

四是软件版本的选择问题
  项目中涉及面最广的就是操作系统版本和数据库版本的选择，本次项目涉及面很大针对每个系统迁移的同时又进行大版本的升级是不现实的，因此整体方向上是只做必要性的升级。特别是AIX操作系统方面，原先使用较低版本在新的硬件上是不支持的，因此小版本上进行一定的升级，满足硬件要求的同时避免低版本操作系统的一些  BUG问题。

五是性能测试
  行内就浪潮K1 Power服务器多个型号和行内现有POWER8服务器针对最常见8C处理器的分区进行了数据库性能对比测试，通过K1 Power多型号的对比选择了中高端浪潮K1 Power E950服务器，通过对比行内现有 POWER8服务器的性能，准确评估性能值对本项目中新增服务器的数量做了准确的计算。

六是关于云管理平台
  云架构中云管平台的作用非常关键，本项目中PowerVC本身就是一个云管理平台，但是它有一些局限性，不能满足所有用户的云管理需求。它提供了基于 OpenStack 的 REST API 接口，可对接行内的高级云管平台；但是经过深入考虑实际运维管理情况，暂不进行PowerVC与高级云管理平台的集成工作。

  经过近一年的项目实施，已完成数十套支付类关键业务系统的部署和迁移，共计200个分区，应用层部分采用集群部署模式，数据库层本地实现Oracle RAC并采用ADG实现数据复制。实施过程紧张而有序，因为经过充分的技术讨论和设计，总体过程相对顺利，总结了一些关键点供大家参考。

一是操作系统版本方面
  行内使用的AIX操作系统版本比较多，主要以AIX7.1为主，少量AIX 6.1和AIX 7.2，经过本次的实施，实现了对操作系统小版本方面的基本统一，根据厂商建议尽量使用AIX 最新TL的次新SP版本。另外，由于AIX 6.1 已经停止服务，而AIX 7.1也即将停止更新，所以后续还是逐步会进行系统的大版本升级，建立操作系统版本基线的管理手段，将行内使用的操作系统版本统一管理起来。

二是关于系统迁移的方法
  在正式实施之前，为了实现加快系统迁移的效率，行内组织了服务器和存储的厂商进行了操作系统整体迁移方案的验证和测试，解决包括存储复制后的卷能否正常被PowerVC识别，PowerVC部署的操作系统如何替换rootvg磁盘等不确定因素，实现将部分现有操作系统进行直接搬迁的方式进行迁移。涉及无法直接进行系统搬迁方式的分区，只能采用重新部署应用系统和数据库本身的迁移方法进行。

三是PowerVC与存储的兼容
  PowerVC可以实现Power虚拟机资源的高效管理，统一管理服务器、交换机和存储等资源。那么，PowerVC对于存储的支持有两种方式，集成驱动方式和可插拔存储驱动方式。本项目中采用的存储无法支持集成驱动的方式，因此选择了基于OpenStack Cinder Driver的插拔存储驱动的方式。此前行内已经在测试环境中使用了这种驱动方式，验证了该品牌存储与PowerVC的兼容性。

四是利旧设备的实施
  本项目中涉及到了部分利旧的POWER8和POWER7服务器也需要同时被纳管，特别是POWER7的服务器是相对比较老的PowerLinux机器，经过检查兼容性、升级微码等工作，最终也将其成功纳管到PowerVC云管理平台中。

四、整体实施效果及经验总结

  经过整体架构的调整和建设，目前行内基于浪潮K1 Power服务器的关键业务系统架构如下所示。

  生产中心和灾备中心均部署一套PowerVC和HMC管理节点，构建客户统一云管理平台。通过浪潮K1 Power E950和POWER8利旧设备进行部署其核心数据库和应用业务，根据行内业务实际需求每台服务器通过PowerVM设置4个LPAR，2个VIOS，10-15个微分区，承载其农信银支付清算系统、银联前置系统、统一柜面系统、网上跨行支付清算、支付密码核验系统、票据业务系统等业务，在保证性能的前提下，保证最优的资源利用率和资源调度的弹性支撑。

  每两台数据库服务器中的DLPAR分区和大部分虚拟分区通过Oracle RAC保证业务连续性，部分虚拟分区部署应用系统，可使用PowerVM的LPM功能在线迁移。此外，还将行内原有的2路PowerLinux服务器也通过PowerVC进行纳管，搭载Linux操作系统部署相关系统。

  存储设备采用高端存储采用存储双活方案，承载关键应用和数据库系统；中端存储主要承载测试系统及其他边缘系统的数据。

• 通过基于Power云架构的同城双中心建设完成后，除达到了应用级同城灾备建设的需求外，还实现Power资源的统一管理。
    两个中心分别实现了Power服务器资源、存储资源的统一管理，采用PowerVC可实现高级虚拟化管理、虚拟机捕获与快速部署、虚拟机在线迁移、基于策略的工作负载部署、工作负载优化及快速配置等虚拟化全生命周期管理功能，大大减少了管理员的工作量，可以将时间投入到其他更重要的事情上，提升人员的核心竞争力。
• 解决了老旧Power服务器的故障率的问题
    使用新购置的Power服务器可解决老旧Power服务器因为使用年限过久导致的高故障率隐患的问题，降低设备部件老化风险。POWER9服务器仍然具有很长的生命周期，硬件设备和服务质量都有足够保障。Power 服务器稳定可靠，一次采购可稳定支撑系统运行超过 7 年，其在线使用寿命很有优势。
• 实现资源快速交付
    通过PowerVC云计算平台，资源申请、设备申请等流程的自动配置和流转，大大缩短了环境准备、人员人场、应用软件安装等环节所需要的时间。即提升单台服务器利用率也可以通过快速添加服务器的方式实现资源池横向扩容。通过资源池分级管理、标准化的申请管理和自动化软件部署，大大降低了IT资源的部署时间。
• 实现动态资源扩展
    资源池化后有效的消除竖井式架构，后续如果需要进行硬件资源的扩容，可以动态实现服务器、存储、网络的横向扩展。

经过本项目的实施，为行内基于Power云架构的应用实践提供了一些宝贵的经验，总结如下：
  （一）实践检验真理，生产环境使用的技术需经过严格的测试。本项目中使用的PowerVM和PowerVC相关技术在测试环境中经过了长时间的测试，确保在生产环境中使用的产品和技术都是经过验证的，而不是直接使用厂商最新技术产品。

  （二）实事求是，在技术方案选型中根据行内实际情况，比如同城灾备中心距离，行内多年应用部署模式，网络虚拟化实践等，选择适合行内的双中心PowerVC云架构方案。

  （三）技术手段与管理手段相结合。任何一个商业产品不可能至善至美，也不可能完美契合一个用户的所有需求，使用其合适的功能达到用户的需求，取其精华，结合管理手段达到最终目标。