南山行者
作者南山行者2020-08-18 15:19
系统工程师, 某银行

某城商行如何通过Power虚拟化资源池转型+升级浪潮K1 Power S924一次性解决数据库运行维护四大痛点

字数 5218阅读 3503评论 6赞 12

【作者简介】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 数据库,在运行过程中,明显感知部分业务系统的运行效率得到大幅提升,且日终备份的时间也大幅降低,明显提升了运行效率。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

12

添加新评论6 条评论

#liujiacai其它, 广州大厦
2020-08-28 16:10
思路清晰,需求明确。
#董志卫系统架构师, 李宁(中国)体育用品有限公司
2020-08-28 14:49
作者非常熟悉自身的业务场景和基础设施,做到了有针对性的改造升级替换,效果是非常明显的。对有类似场景的企业有一定的指导性作用,非常的不错。同时我这里有些思考的,可以大家探讨。 成本方面: 硬件成本+软件成本+人力成本 风险方面: 集中和分散 这里我大致的分析一下: 1. 风险方面 本次的项目基本上可以说从分散走向了集中,这就要求了硬件和平台的健壮性,否则有平台问题时,风险还是比较高的,毕竟是每台设备上承载的业务变多了。 2.成本方面 1)硬件方面 本项目采购的K1 20C的配置,我不知道价格具体如何,总的硬件成本应该也是一笔不菲的数字,还需要考虑3年以后的MA 成本,总体成本应该也不会太低,并且后续要持续的在这个专有平台的投入。 2) 软件方面: 软件的最大成本应该在于数据库的方面,从本次项目来看数据库的系统和数量并没有明显的减少,这一块的成本应该是变化不大 3)人力成本: 原先使用的通用的小型机平台,现在使用高配置的小型机硬件,基本上应该不会有太大的变化,相反对人员的专业能力要求的更高了,使用vios和npiv,整体环境其实变的更加复杂了。 结合以上几点来看,项目的升级改造的首要目标是要满足业务场景的需求,提供运维的便利性,可以说项目达到了逾期的目的,这个是需要得到肯定的,非常的不错。 另一种思路: 在IT环境日益成熟的前提下,是否可以走一下X86路线,不管是硬件的成本和性能已经得到长足的发展和进步(单机,一体机,超融合)等等方案,是否是可以满足日益长久的发展,总体的运维成本也在持续的降低,小型机的环境现在也是越来越走下坡路了。 以上仅仅是有关本项目的一点想法,一家之谈,仅供参考
#15305419779zxy网络工程师, 山东大正公司
2020-08-28 13:57
该篇文章对于业务系统的升级和改造,业务发展带来业务量的急剧增加, 小型机运维工作面临着较为严峻的问题对于大部分商业银行来说,面临的问题都很相似,如何面对同样的问题,找出符合自己的业务需求和安全部署方式显得尤为重要和关键。对于采用现有的 Oracle 数据库部署方式遇到了诸多问题,主要体现在 四个方面,写的非常到位和精辟。
#cpc1989存储工程师, 某保险公司
2020-08-27 10:32
通过Power虚拟化资源池来对旧设备进行整合这个方案值得学习和借鉴,我有一个疑问还希望能得到解答:VIO方式会共享网络和存储,对其性能都会有一定的影响,特别是数据库这样对IO敏感的应用。在这一点上,不知你们是怎么考虑来优化和规避这一影响的,有没有相关的测试和对比数据呢?
#light_hu86系统工程师, 某省金融
2020-08-26 16:08
设备由570、720、740这些Power7设备直接跳到Power9上,跨度较大;相比我行由740、750、770过渡到S824等Power8设备后才慢慢转向Power9,升级及迁移方式值得参考,具有一定的参考价值,但不同银行有不同的背景及业务状态,值得一定的借鉴。
#邓毓系统工程师, 江西农信
2020-08-26 13:56
结合了自身银行数据库服务器当前面临的痛点和需求,针对性地进行服务器选型、升级和迁移工作,同时列举了三种迁移方式,对其他银行有一定的参考价值,实践效果也是值得肯定的。
Ctrl+Enter 发表
相关推广
  • 某银行基于浪潮K1 Power架构设计实现分布式核心系统的实践
    本文以某城商行核心业务系统升级建设项目为背景,根据近十多年以来银行业业务发展的功能与非功能需求,建立短期以及中长期的核心系统改造目标,详尽设计核心系统的业务逻辑,基础架构和浪潮K1 Power小型机选型配置、高可用测试等多阶段、多维度项目实施和运维管理经验,为同业核心系统升级和改造提供可参考、可操作的真实案例和宝贵经验。
  • 核心数据库服务器选型优先顺序调查

    发表您的选型观点,参与即得50金币。