【摘要】

某银行基于小型机的私有云自建设以来，已在生产环境为上线业务系统持续提供PowerVM资源支撑，当前生产环境PowerVM虚拟机的规模已近千台。本文从基于浪潮K1 Power小型机私有云的项目背景及技术方案选型、应用架构设计、及实践经验等方面进行展开，分享了基于VIOS+HMC模式管理，LPM日常维护，小型机资源池跨机房搬迁，PowerHA高可用方案，基于PowerVCREST API自动化等方面的实践经验。

一、项目建设背景

根据银监会十三五规划指导意见要求，为适应互联网环境下计算资源弹性变化和快速部署等需求，开展云计算架构规划，制定云计算应用策略。探索构建私有云平台，采用成熟度高、开放性强的计算虚拟化、容器虚拟化、分布式存储、网络虚拟化等技术，建立资源池，形成资源弹性供给、灵活调度和动态计量的私有云平台。我行考虑到业务发展，业务系统上线量持续增多，以前传统的服务器部署模式，已无法适应业务的发展需求，同时考虑到缩减人力投入成本、设备投入成本等因素，我行决定推进小型机资源池建设。

二、银行选择应用PowerVC技术方案的考量分析

我行推进生产资源池建设以来，上线系统中半数应用基于AIX的操作系统开发，小型机的比重与PC服务器的比重基本对半开。而且考虑到浪潮K1 Power小型机稳定性高，因此我行的重要信息系统基本部署在浪潮K1 Power小型机上。过去很多部署在AIX平台下的应用系统采用小型机全分区的部署模式，采用中低端的设备，这就导致了设备采购数量大，消耗大量的机房空间、电力，资源整体使用率比较低，装机工作量大等问题凸显。为了灵活适应业务需求，缩短上线周期，我行决定推进小型机私有云建设，搭建PowerVC平台。

相比传统的物理机部署，基于PowerVC平台小型机私有云，极大降低了物理资源池设备数量，显著减轻机房空间、电力压力，降低成本，节能减排，显著缩短了装机时间，为实现标准化、规范化、自动化打下基础。

三、银行PowerVC技术应用架构设计

我行小型机私有云采用基于VIOS+HMC模式管理PowerVM系统的部署模式，小型机私有云的设计中很重要的特点就是高可用的冗余设计，每台宿主机的双VIOS设计，每个VIOS双网卡、双光纤链路配置。VIOS本身的操作系统盘rootvg也是做mirror，做双份拷贝。另外每台宿主机由两台HMC进行纳管，两台HMC一主一备。由于PowerVC的指令需通过HMC进行下发，因此双HMC的设计，也可保证PowerVC调度的高可用。在存储层，根据我行已有资源池的特点，PowerVC对存储的接管主要分为两种方式。一种是通过SVC接管底层存储，底层存储两两之间互为拷贝，实现存储的高可用。另外一种接管方式则是通过provider接管VMAX的高端存储，高可用性则由VMAX高端存储自身的高可用性做保证。

• 虚拟机高可用

多台服务器构建资源池

双VIOS/IO通道冗余/数据镜像

rootvg实现数据镜像

datavg 做SRDF远程复制

PowerHA 双机高可用

DRO 动态资源优化

IP地址自动分配

• 管理平台高可用

HMC：

双HMC冗余及网络通道冗余

双FSP实现FSPfailover

PowerVC：

日常数据备份和恢复机制

基于Vmware 虚拟化部署

四、银行Power私有云的实践经验及应用效果分享

（1） PowerVC平台中HMC管理设备带来的一些限制

我行的小型机云平台基于VIOS+HMC模式管理PowerVM系统，一台物理机有两台HMC管理，其中一个HMC为主，一个HMC为备的管理模式。当HMC纳管的设备超过20台时，HMC的内存及CPU消耗较大，因此根据官方推荐及实践经验，在基于VIOS+HMC模式管理PowerVM系统情况下，建议纳管的宿主机设备数量建议不超过20台。另外本身8.8.6版本及以上版本提供了可以开启宿主机性能收集的功能，HMC的性能消耗也会更大，因此要注意HMC纳管设备的数量。在纳管近30台设备的情况下，多次出现HMC系统夯住的情况，比如在资源池迁移的时候，PowerVC上已提示虚拟机已迁走，但HMC上仍显示分区迁移中的假象。这种时候，往往只能通过重启解决。我行的小型机资源池宿主机的规模近百台的情况下，通过搭建多个PowerVC的方式，一个PowerVC管理两台HMC的方式进行宿主机的管理，进而解决单台HMC纳管宿主机的数量上限的问题。我行当前在三个机房搭建了小型机资源池，由于网络部署区域及机房物理上的隔离考虑，不同机房的宿主机由不同的PowerVC进行管理。网络部署区域的隔离则通过不同的RMC网段及不同的业务网段进行区分，比如生产区的集群对应的业务网段为SC_IP，RMC网段为GL_IP，网银互联网区域的集群的业务网段为WY_DMZ_SC，WY_DMZ_GL。一般一台HMC上配置的网卡有四个管理网口，其中一个配置HMC自身的管理地址后，还有3个网卡可以配置三个网段的地址，用于与各网络区域通信，因此一套HMC（一主一备）最多可管理三个网络区域的宿主机，这也是一个限制因素，在进行PowerVC纳管规划时需进行考虑。

（2）关于HMC/PowerVC对分区迁移的支持

资源池具备LPM（分区在线迁移）的能力，是资源池的一项重要能力，在我行的实践过程中，该功能在处理非宕机性的硬件更换及VIOS升级维护中最常被使用。另外未来老旧设备的替换，也将使用到这一功能。我行在使用PowerVC的LPM过程中一些实践经验：

• HMC对分区迁移的支持
  可以使用硬件管理控制台（HMC）将活动或非活动逻辑分区从一台服务器迁移到另一台服务器；
  PowerVM EE，HMC 最低版本要求：Version 7,Release 7.1, or later；
  由于HMC始终迁移上一个激活的配置文件，因此无法迁移从未激活的非活动逻辑分区。
• PowerVC对分区迁移的支持
  在PowerVC 1.4.4之前的版本中，只支持ActivePartition Migration，即LPM；
  PowerVC 1.4.4 开始支持非活动分区的迁移(Inactive Partition Migration)。
• 如果使用HMC V9.1.920或更早版本来管理源服务器和目标服务器，则不能执行双向和并发的实时分区移动性，例如以下情形：
  将移动分区从源服务器移动到目标服务器时，不能将另一个移动分区从目标服务器迁移到源服务器；
  将移动分区从源服务器移动到目标服务器时，不能将另一个移动分区从目标服务器迁移到其他服务器。
• LPM时的数据压缩和加密
  我行基于浪潮K1 Power建立的小型机资源池上既有Power8，也有Power9的设备，但根据原厂推荐基本分开搭建集群，主要也有提升LPM性能方面的考虑。对于Power9服务器，Hypervisor自动压缩和加密迁移数据，提高迁移性能并增加了数据安全。LPM时的数据压缩和加密的前提是，源服务器及目标服务器都需为Power9服务器。对应一个50G内存的无业务虚拟机的测试结果如下：
  
• 如果目标服务器上存在相同名称的逻辑分区，则无法迁移逻辑分区。
• HMC为目标服务器上的移动分区创建与逻辑分区的当前配置匹配的迁移配置文件。在迁移期间，HMC将与移动分区关联的所有配置文件迁移到目标服务器。在迁移过程中，仅使用当前分区配置文件进行配置。
• LPM分区上的所有I / O适配器必须是虚拟设备。
• 具有专用适配器的分区可以进行非活动分区移动；但是，专用适配器将从分区配置文件中被删除。因此，在非活动迁移之后，逻辑分区将仅使用虚拟I/O资源进行引导。
• 勿在业务高峰期/内存变动高峰期进行LPM操作。
• PowerHA环境注意事项
  PowerHA的CAA 和Group Services的DMS机制起作用，导致进行LPM操作的节点被重启；
  PowerHA的DMS机制未起作用，在LPM冻结期间PowerHA的机制起作用，但误判导致了资源的调度和接管，产生脑裂；
  对于CAA DMS机制，在LPM之前将node_timeout时间设为最大值600秒(10分钟)，避免CAA DMS机制起作用导致节点的重启，在LPM之后在调整为正常值；对于组服务的DMS机制，关闭相关服务避免节点的可能重启,在LPM之前关闭组服务，在LPM之后再开启；对于PowerHA的接管机制，以不影响应用方式取消接管资源组，避免脑裂,在LPM之前，以unmanage resource group方式关闭PowerHA(clstop)，在LPM之后，重新启动PowerHA服务。

（3）跨机房搬迁实践经验总结

整体迁移方案采用在目标机房搭建一套与原机房架构一致的PowerVC资源池，通过PowerVC+临时存储空间搭建初始的目标虚拟机环境，再通过存储复制方式将源虚拟机环境中的数据（SVC存储同步rootvg+datavg，VPLEX存储同步dbvg+caavg）复制到目标虚拟机环境，同步完成后在系统割接时断开复制关系，启动目标虚拟机环境，完成系统割接。搬迁方案将完全模拟生产环境架构进行：

原机房生产环境：

目标机房环境：

割接步骤：

每套源环境系统在正式割接前，应做如下信息收集和备份工作，内容包括但不限于：
1）操作系统备份，通过NIM或者mksysb方式进行备份
2）系统配置信息收集，供割接后的验证使用：

• 分区profile配置信息（lparstat-i输出）
• 系统主要参数信息（sys0、AIO参数及unlimit设置等）
• 卷组（rootvg/datavg/dbvg）信息，包括每个卷组包含的PV、PVID、varryon属性、lv及lv设备的属主权限信息等
• PV信息，包括每个PV对应的磁盘设备名、PVID、磁盘UUID新等
• 文件系统信息（/etc/filesystem）和挂载信息（mount -o）
• 系统引导设备信息（bootlist-o）
• 系统IP配置和路由信息（netstat -in）
• 主机名解析配置信息（/etc/hosts）
• 系统设备信息（lsdev输出）
  3）通过PowerHA的快照功能（snap）备份PowerHA集群的配置信息
  每一个待割接系统（源系统）在正式割接前，应做环境检查工作，内容包括但不限于：
  1）检查系统的errpt日志，确认系统健康状态
  2）检查PowerHA的hacmp.out日志，确认PowerHA集群健康状态
  3）检查存储底层磁盘卷复制关系和同步状态
  4）检查目标环境虚拟机的配置是否和源环境一致
  5）检查目标环境虚拟机是否处于未激活状态

每一个割接后系统（目标系统）在割接后，应做如下检查工作，内容包括但不限于：
1）系统启动后检查系统中是否存在define状态的设备（包括磁盘设备及网卡设备），如有则需要比对源与目标虚拟机Profile的配置，确认配置无误后对define状态的设备进行清除和重新扫描设备；
2）验证系统是否可以导入SVC同步过来的datavg；
3）验证系统是否可以导入VPLEX同步过来的dbvg和caavg；
4）通过之前收集的系统配置信息对割接后的系统进行比对，如发现问题需要及时调整修复；
5）检查系统是否出现故障报警（errpt输出），如有问题需要立即修复；
6）针对PowerHA环境，需要验证CAA集群状态；
7）启动PowerHA后，需要验证资源组是否正常在主节点上启动，服务IP是否生效，同时检查PowerHA的运行日志；
8）配合应用验证虚拟机上的数据库服务或应用服务可以联通和对外访问。

割接回退步骤：
1）关闭目标机房资源池中的目标虚拟机系统
2）启动原机房资源池中的源虚拟机系统
3）确认原虚拟机系统可以提供对外服务
4）记录回退时间

（4）PowerHA高可用方案的实践应用

小型机资源池的网络、光纤、VIOS层的双路高冗余，在网卡故障、光纤链路或网络单路故障、单VIOS故障等场景都不影响可用性，可通过迁移手段把对应服务器的虚拟机迁移走后进行维护。因此大部分场景下的故障，并不影响小型机资源池的可用性。但是若宿主机发生主板故障引发故障宕机时，故障宿主机上的虚拟机的可用性会受到影响，对外服务的虚拟机的业务连续性会受到影响。从小型机资源池的自身能力来说，只要保证集群的可分配空间至少为一台宿主机的CPU及内存总量，则宕机的宿主机的虚拟机可根据“remoterestart enable”的设定自动拉起操作系统。但是一台宿主机上通常有比较多的虚拟机，虚拟机从另外一个宿主机上启动时，仅会拉起操作系统。后续还需故障关联系统的维护人员手工拉起文件系统、数据库、应用程序。因此一台小型机宿主机故障宕机的风险是比较高的，进行故障恢复所需的时长也相对较长。

为了缩短单台小型机资源池宿主机故障恢复的时长，引入PowerHA高可用方案是最为高效可行的方案。单台宿主机宕机后，对应虚拟机的主机会自动切换至备机，并自动拉起卷组、文件系统、数据库、应用程序（在PowerHA可配置应用启停脚本）。我行自2018年来逐步开始推广PowerHA，到目前为止只要是主备模式部署在小型机资源池的虚拟机，都需配置PowerHA。在PowerHA的推广至日常运维中，也总结了一些事件经验：

• 定期发布操作系统及PowerHA推广矩阵
  由于我行的软件技术目录里的操作系统版本会定期更新，同时PowerHA的版本也会定期推出新版本及补丁版本，因此在日常管理维护中，考虑操作系统及PowerHA维护软件生命周期,需定期发布操作系统及PowerHA推广矩阵，当然需事先查阅操作系统与PowerHA版本的兼容性。
  
  PowerHA软件的生命周期
  
  
  PowerHA软件的生命周期
• PowerHA风险应对
  我行在部署的PowerHA的应用系统，也碰到过一些关于PowerHA相关的一些故障，主要是发生过一次脑裂、一次误切换。AIX6.1TL09SP00到AIX6.1TL09SP06版本区间、AIX7.1TL03SP00到AIX7.1TL03SP06版本区间、AIX7.1TL04SP00、AIX7.1TL04SP01、AIX7.2TL00SP00、AIX7.2TL00SP01版本操作系统存在HA脑裂缺陷（bug），需升级操作系统进行修复，原厂商建议至少升级至AIX 7.1TL05SP04。CAA是在AIX操作系统内集成的Cluster功能，CAA通过心跳包在节点间的发送接收方式来对IP网络、SAN网络、NODE进行状态监控并将结果反馈给PowerHA以简化PowerHA的集群管理任务；在CAA的网络监控中，一旦网络通讯中断超过可容忍的时间（网络失败检测，简称FDT），将会把该状态通报给PowerHA的核心进程，同时产生PowerHA的network_down或interface_down事件，进而触发HA网络切换或节点级别的切换。有一套系统CAA的FDT设置为5秒，由于网络发生偶然性抖动，出现了8秒的网络中断，引发了HA的误切换。AIX7.1.4版本以前，FDT最大为5秒。AIX 7.1.4之后版本，CAA FDT的默认值为20秒，可修改范围为5-580，增加FDT的值可以增大CAA对网络波动和中断的容忍度，在一定程度上可以规避发生network down或interface down事件时触发资源组或节点切换的HA行为发生。当前我行将FDT设置为20秒。
  
• PowerHA升级整改
  根据以上的PowerHA的风险描述可见，AIX操作系统版本及PowerHA的版本都尤为关键，因此针对所有部署PowerHA的应用系统需进行AIX操作系统版本及PowerHA版本的排查，并制定升级改造的方案。根据PowerHA配置规范，编写了PowerHA检查脚本，检查脚本共有31个检查项，如下：
  
  

在对PowerHA的风险项进行整改过程中，基本上遵循几个原则，其一是“成熟一套，恢复一套”：对所有已上线PowerHA的系统进行排查，列出各套系统的整改项，当解决方案整理出来并验证测试通过后，则立马进行该套系统的PowerHA整改；其二是“强化规范”：碰见风险项，及时进行分析排查，并将相应的标准补充至PowerHA配置规范中；其三是“反复多次演练”：在PowerHA升级整改过程完成后，需多次反复切换演练验证，针对新上线系统，也在配置完PowerHA后反复进行切换演练；其四是“强化培训”：持续提升运维人员PowerHA运维能力。已对应用系统相关已知的风险进行了排查并整改，总体运行稳定。

（5）基于PowerVC API实现自动化的实践

在PowerVC的日常维护中，有时候会考虑如何拉取PowerVC上的虚拟机信息，这部分工作很多时候都手工去浏览器上拷贝并贴到excel中手动处理。另外在部署虚拟机时，资源池管理人员需手工指定虚拟机的操作系统模板，虚拟机名称，计算模板大小，网络区域选择，及挂载磁盘的名称、大小及数量，进而进行虚拟机的部署。通过PowerVC的REST API，我们可通过执行python脚本一键自动拉取多个PowerVC上的所有虚拟机信息（包括虚拟机名称、管理IP、生产IP及宿主机信息），我行还通过这种方式将信息自动推给CMDB配置库。

在部署虚拟机的时候，我行定制好了固化的申请表单，由申请单位自己选择操作系统版本、计算模板、数据盘的大小、网络部署区域等，通过自动化脚本可将这些需求解析为PowerVC REST API的执行参数，并调用PowerVC REST API实现虚拟机的自动化批量部署。