某城商行通过Power虚拟化资源池转型+升级浪潮K1 Power S924一次性

【摘要】本文基于某行数据库服务器升级为浪潮K1 Power S924小型机的实践经验，从现有小型机的使用情况、数据库运行和运维过程中的痛点及需求、Power虚拟化资源池转型及服务器选型经验、Power虚拟化资源池方案规划及Power9升级经验和迁移过程、实践效果等方面进行了详细介绍，旨在举一反三，总结升级实践和经验，对以城商行为代表的中小金融企业有一定的借鉴价值和参考意义。

【作者】Halk，某城商行数据中心项目经理。长期专注于数据中心IT基础环境规划、建设和系统运维。主要涉猎有小型机、虚拟化、同城双活以及灾备体系。

一、某城商行小型机使用情况概况

某城商行生产环境总共部署了五、六十台Power6、Power7系列小型机，用于承载我行30多套Oracle数据库及部分关键应用节点的运行环境，涵盖了我行绝大部分的业务系统。然而近年来，随着我行业务系统的升级和改造，业务发展带来业务量的急剧增加，我行的小型机运维工作面临着较为严峻的问题。

二、数据库运行和运维过程中的痛点和升级需求

目前我行生产环境主要的小型机型号为P740、P720以及少量的Power6 570。这部分小型机设备与Oracle数据库主要的高可用架构和部署方式有以下三种：

1、HACMP+Oracle：HACMP+Oracle数据库主备的高可用架构主要部署于少量的Power6 570小型机上。

2、HACMP+OracleRAC：HACMP+RAC数据库双活的高可用架构主要部署于P720和P740小型机上。

3、ASM+RAC：ASM+RAC数据库双活的高可用架构主要部署于P740小型机上，并采用了逻辑分区的方式来实现。

以上三种Oracle数据库的高可用架构和部署方式在业务运行过程中，较为稳定，有力地保障了我行生产系统的稳定运行。然而随着业务的发展，对Oracle数据库的运行和维护提出了新的要求，采用现有的Oracle数据库部署方式遇到了诸多问题，主要体现在以下四个方面：

1、随着业务的快速发展，我行新系统上线的频率加快，对Oracle数据库的运行主机和对应的Oracle资源需求量大，而我行现有生产系统的Oracle数据库部署得较为集中，主机无法再分配新的资源。因此，需要采购新的Oracle主机等相关资源，但是采购流程和周期又相对较长，严重制约了新系统上线的效率，进而影响了业务的开展；

2、我行现有Oracle数据库大多版本较低，绝大部分都还停留在Oracle 10g、Oracle 11g，而官方已经在主推Oracle 19c。旧版本的Oracle数据库在补丁、运行效率和运维等方方面面临着挑战，我行亟需进行数据库升级，然而较为集中的部署方式同时也意味着数据库的升级风险也大大上升；

3、集中部署的方式，导致多套甚至数十套系统运行在同一套Oracle数据库内。这就导致了单套数据库数据量增长加快，数据量偏大，影响Oracle数据库的运行效率，且不利于开展数据库的备份，及备份恢复演练等工作；

4、我行现有设备存在老化现象，故障率高，进一步降低了Oracle数据库运行的稳定性和可用性，影响了业务系统的业务连续性。

三、Power虚拟化资源池转型及服务器选型

基于以上四个方面的原因，我行全面梳理了数据库的整体架构，并多方咨询厂商，借鉴同行的经验，开展了基于Oracle数据库资源池优化转型和服务器选型工作。考虑到新业务系统上线速度加快，而对应的采购流程和周期较长，因此本次优化转型的主要的思路是从原来物理机独立部署Oracle数据库的方式，优化为PowerVM虚拟化Oracle数据库资源池的方式。主要从以下三个方面来解决我行当前所面临的痛点：

1、采用PowerVM虚拟化技术，可以预留一部分CPU和内存资源，用于新系统的上线，可快速满足新系统上线所需求的Oracle主机资源；

2、采用PowerVM虚拟化技术，将高配的主机虚拟为十几台虚拟机，将原有集中部署的Oracle数据库主机进行拆分，分散到不同的虚拟机当中，每台虚拟机承载一至三套业务系统，分散风险，降低集中度，同时提升单套Oracle数据库的业务处理效率；

3、采用资源池横向扩展的方式，部署多台资源池物理主机，每套Oracle数据库集群均匀地部署在不同的2台物理机上，提升Oracle数据库的高可用性和稳定性，确保业务系统的业务连续性。

鉴于我行本次PowerVM虚拟化Oracle数据库资源池的建设规模需要等同于现有生产环境8台P740的处理能力，用于现网Oracle数据库的迁移。因此需要对小型机的型号选型进行认真分析和评估。通过浪潮商用机器有限公司官方提供的rPerf值列表，我行主要对比了现有Power7和Power9系列小型机的rPerf值，来开展本次的选型工作。下图一为Power7系列小型机的rPerf值列表。下图二为Power8、Power9系列小型机的部分rPerf值列表。

图一

图二

由以上两张图对比可知，配置20C的浪潮K1 Power S924的rPerf值大约是配置16C的P740的3倍，大约是配置16C的P740（P7+）的2倍多。考虑到现有生产环境运行的主要是P740，结合经济成本，本次我行PowerVM虚拟化Oracle数据库资源池考虑采用4台配置20C/2TB 的浪潮K1 Power S924来构建，大约等同于现有10台P740的处理能力，一方面将满足现网8台P740处理能力的要求。另一方面也冗余了等同于2台P740的处理能力，来用于新系统的投产和上线。

四、Power虚拟化数据库资源池方案规划及Power9升级过程和经验

1、虚拟资源池的规划

本次PowerVM虚拟化数据库资源池是由4台配置20C/2TB的浪潮K1 Power S924构成。每台物理机均配置双VIOS进行相互冗余，每台VIOS的资源配置为1C/16GB；预先划分8台2C/128GB的VIOC，2台1C/64GB的VIOC。

每台浪潮K1 Power S924配置8张双口万兆电口卡、8张双口16GB的光纤通道卡。每个VIOS分配4张双口万兆电口卡、4张双口16GB光纤通道卡。其中，每个VIOS的2张物理网卡用于Oracle的数据传输网络，2张用于Oracle的心跳网络，两两之间跨物理网卡做Etherchannel绑定。

在操作系统层，采用vscsi的方式实现。在给VIOC分配rootvg的时候，分别在双VIOS上映射给VIOC同一个rootvg LUN，并做LVM镜像，实现VIOC分区rootvg的冗余，如下图所示；对于Oracle的数据存储层，则采用NPIV的方式，从存储端直接分配到VIOC分区，减少IO损耗，提升IO性能。

2、Power9升级经验

本次升级过程中浪潮服务器虚拟化，主要积累有以下经验点：

在项目实施过程中，发现Power9微码版本过低。然而从IBM官网下载的补丁却无法应用。后经咨询浪潮商用机器有限公司工程师，在其指导下从浪潮官网下载了新的微码补丁，并得以成功升级补丁。因此需要注意：浪潮K1 Power微码升级需要从浪潮官网下载。

Power9目前支持的操作系统版本是AIX 6.1 TL9、AIX 7.1 TL4、TL5，以及AIX7.2。低于AIX 6.1 TL9版本（主要存在于Power7系列小型机上）的操作系统无法支持和兼容。因此，在迁移前，需要考虑操作系统兼容性问题，若达不到要求的话，需提前做好升级工作后再行迁移。

3、Power9迁移过程

在我行新购买的浪潮K1 Power S924小型机上完成了PowerVM虚拟化资源池的搭建后，我行开展了业务系统Oracle数据库从Power6、Power7环境迁移至Power9环境的实施工作。通过对我行现有Oracle数据库架构和环境进行缜密摸排后，结合不同的业务系统场景，制定了多种不同的迁移方案，并开始实施数据库运行环境的迁移。主要有以下三种方案：

主要适用于新的PowerVM资源池环境和原有Power物理机环境没有共用的SAN网络和存储，或者同一套Oracle数据库中运行了多个业务系统。我行通过对原有数据库环境进行了数据库级辅助了部分表级备份，再在新的PowerVM VIOC环境中重新搭建Oracle运行环境，并进行数据库数据的全量恢复，待业务系统停机窗口到达后，再将新增的数据通过活动日志前滚的方式追加至新的Oracle数据库中，实现数据库数据和运行环境的全部迁移。

主要适用于新的PowerVM资源池环境和原有Power物理机环境有共用的SAN网络和存储。这种方式较上一种方案更为简单快速，首先在新的VIOC上重建Oracle的运行环境，待业务系统停机窗口一到，直接停止业务应用、数据库，并卸载数据盘，挂载到新的VIOC上，顺序启动数据库和应用，业务系统完成Power9服务器升级。

主要适用于新的PowerVM资源池环境和原有Power物理机环境没有共用的SAN网络和存储，但停机时间窗口比较紧张的业务系统。我行有些非常重要的业务系统，停机时间窗口控制比较严格。若采用数据库备份恢复的方案，时间窗口不好控制。因此，我行采用了Oracle DG的数据库复制和切换技术来帮助完成这类系统的服务器升级切换。首先还是在新的VIOC上搭建好Oracle运行环境，然后直接将全量备份文件恢复到VIOC的数据存储卷上，并建立与原环境的Oracle DG复制关系，进行数据的同步传输。待停机时间窗口后，直接停应用并切换Oracle DG，实现主从关系的反转，最后将应用连数据库的IP地址指向配置文件进行更改，启动应用后恢复业务的运行，总的停机耗时不超过30分钟。

五、浪潮K1 Power S924升级实践效果

通过我行浪潮K1 Power S924升级项目的建设，完成了集中部署数据库的拆分和迁移，在运维和新系统投产的过程中，逐渐凸显出较好的效果，主要体现在以下三个方面：

1、保障了新系统的快速上线。

PowerVM虚拟化数据库资源池投产后，我行恰好有一套新的重要业务系统需要上线，需要部署一套独立的新版本Oracle数据库。我行仅耗时几小时，就直接在预留的Power9资源池里分配了新的资源，并快速实施和部署Oracle RAC数据库交付使用，有力地支撑了新系统的快速上线。我行之后也将再搭建一套PowerVC云平台，通过自动化的方式在Power9资源池中动态地增减和修改资源，进一步加速新系统的上线进度。

2、降低了数据库补丁升级风险。

我行之前有几套Oracle数据库的补丁版本存在缺陷，需要离线进行补丁升级，在之前的集中部署模式下，考量因素多、多业务系统停机的风险大，导致不敢升级，补丁升级一拖再拖。然而通过本次浪潮K1 Power S924升级项目的建设，实现了集中部署模式的有效拆分，现每套数据库承载不超过3套业务系统，大大降低了补丁升级过程所带来的影响面和风险点，升级的压力大幅降低，现我行所有数据库补丁版本均得到有效升级。

3、提升了数据库运行效率。

我行之前的数据库集中部署模式浪潮服务器虚拟化，多业务系统在同一套数据库中相互抢占主机资源，相互影响，且数据库数据总量巨大，通过常规的Oracle RMAN备份总时间非常长，日终备份可能第二天白天都无法完成，进而影响了日间业务的执行效率。然而通过本次浪潮K1 Power S924升级项目的建设，我行发现，现有分散式部署的Oracle数据库，在运行过程中，明显感知部分业务系统的运行效率得到大幅提升，且日终备份的时间也大幅降低，明显提升了运行效率。