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

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

【关键字】 城商行 服务器 Power9 升级

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

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

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

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

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

2 、 HACMP+Oracle RAC ： 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 、虚拟资源池的规划

• VIOS 和 VIOC 规划

本次 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 迁移过程

在我行新购买的 Power9 小型机上完成了 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 分钟。

五、 Power9 升级实践效果

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

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

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

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

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

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

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