某银行如何通过 PowerVM+PowerHA 实现高可用和同城灾备
【摘要】Power 小型机在城商行、农商行和省农信等银行机构中占有很大比重，Power 云化是IT基础架构云化过程中的重要环节。虚拟化是云计算的基石，那么如何利用好现有的强大的 Power 服务器产品，利用其 PowerVM 虚拟化技术，最大化地利用相关的硬件资源，将变得尤为重要。与此同时，传统的 Power 物理机高可用技术是否依旧能够顺应虚拟化浪潮，在 PowerVM 环境下依旧表现稳定可靠？本文将从某银行 PowerVM+PowerHA 的实践案例为出发点，详细介绍相关技术实现方案和实践效果。
【作者】社区ID：Dongxin，某银行系统工程师，负责Power运维工作，有多年运维经验
一、背景
现如今，云计算发展如火如荼，从 IaaS、PaaS 再到 SaaS，新技术的发展时时刻刻在给我们的数据中心带来新的惊喜。Power 小型机作为银行数据中心现阶段仍不可或缺的一项重要计算资源，因其出色的 RAS 特性，在中小银行，尤其是城商行、农商行和省农信等银行机构中依旧占有很大比重。为增强业务弹性，提升资源敏捷性，强化资源统一管控能力，需要对整个IT 基础架构进行云化、建设多云架构，而 Power 云化也顺理成为了 IT 基础架构云化过程中的重要环节。另外，虚拟化是云计算的基石，通过虚拟化技术把硬件资源最大化利用，那么如何利用好现有的强大的 Power 服务器产品，利用其 PowerVM 虚拟化技术，最大化地利用相关的硬件资源，将变得尤为重要。与此同时，传统的 Power 物理机高可用技术是否依旧能够顺应虚拟化浪潮，在 PowerVM 环境下依旧表现稳定可靠，防范各类风险于未然，也将成为今天本文的主题。下面笔者将从某银行 PowerVM+PowerHA 的实践案例为出发点，详细介绍相关技术实现方案和实践效果，希望对各位同行有所帮助和借鉴。
二、技术方案
1、PowerVM 方案
PowerVM 技术在某银行运用非常广泛，在生产数据中心和同城灾备数据中心的Power 服务器上成为标配，从 Power7、Power8 到新购的K1 Power9 都按照标准规范搭建了 PowerVM，目前每台小型机的主流配置为 24C，1024/512G，每台服务器配置 4 张网卡（2 个千兆电口+2 万兆光口） 和 4 张 HBA 光纤卡。具有以下几个方面的特点：
（1） 双 VIOS 设计: 所有 Power 小型机均是双 VIOS 设计，一个 VIOS 安装于做了 RAID10 的内置磁盘，一个 VIOS 安装于外置存储，通过 SAN Boot 的方式引导启动，这样的目的在于规避 RAID 卡故障，保证异常时，也有一个 VIOS 存活， 持续提供网络和存储 I/O 服务。
（2） 双 SEA 设计: 业务与管理网络隔离。每个 VIOS 配置两块网卡，并创建了 2 个 SEA（SEA HA 模式为：auto），一个 SEA 用于业务，一个 SEA 用于带内管理。业务的 SEA 通过一组 EtherChannel 连通物理千兆网络环境，带内管理的 SEA 通过一组 EtherChannel 连通物理万兆网络环境。如下图所示， 其中千兆EtherChannel 通过两个网卡的三个电口绑定，形成主主备模式（模式为：8023ad， 哈希模式为：src_dst_port），能够提供最大带宽 2Gb，千兆 TOR 交换机的两个主主端口需配置 LACP 链路聚合；万兆 EtherChannel 通过两个网卡的两个光口绑定，形成主备模式（模式为：standard，哈希模式为：default），能够提供最大带宽 10Gb。通过该方式实现了业务网络和带内管理网络充分隔离，带内管理网络主要用于数据传输和管理，例如 GPFS 并行文件系统、DB2 HADR、备份、网络心跳、数仓抽数等等。这样对于交易类的业务而言，单台 Power 计算节点能够提供的最大带宽，可以满足银行现阶段单台计算节点虚拟机的业务流量总和要求；对于数据管理而言，充足的万兆带宽可以满足大量数据的吞吐量要求，并减少传输时间。
（4） 双 VIOS 的 AA 和 AS 模式: 根据以上的配置，对于网络而言，无论是业务网络还是带内管理网关，所有虚拟机均通过同一个 VIOS 所配置的网卡连通外部网络，因此双 VIOS 的网络为 AS 模式，真实 VIOS 间 SEA 主备切换，将造成虚拟机短暂的网络丢包；对于存储访问而言，由于所有虚拟机均通过两个 VIOS 的物理 HBA 光纤卡端口连接存储，所有的 NPIV 多路径均为活动状态，因此通过双 VIOS 访问存储为 AA 模式。
2、本地 PowerHA 方案
在以上 PowerVM 环境下，某银行大量采用了 PowerHA SystemMirror 7.1.2 Enterprise Edition，来为交易类业务系统数据库和其所在的虚拟机提供高可用性和灾难恢复解决方案，选择该方案的主要原因包含三个方面:
一是银行大量采用了 DB2 数据库，较少的 Oracle 数据库采用了 RAC 双活，而 DB2 PureScale 双活方案需要专用的 RoCE 卡和交换机，大规模推广存在一定阻力；
二是 PowerHA 方案在 Power 环境下稳定性高，高可用机制全面，且和底层硬件结合较为紧密， 采用其他高可用方案，例如 TSA 或者 KeepAlive 等，纯软件方案，高可用机制不全面，多节点对底层存储的共享通常需要借助第三方软件实现，例如并行文件系统。
三是 PowerHA 方案拥有进一步拓展方案，实现两个站点间的灾备恢复。因此， 银行选择 PowerHA 来作为主要高可用软件，通常每套数据库采用两个 Power 虚拟机，通过外置存储共享同一套数据库存储，并由其中一个拥有 HA 资源组的虚拟机对外提供服务，本地 PowerHA 具有以下几个方面的特点：
（1） 双网络心跳： PowerVM 环境下的 PowerHA 节点全部采用双网络，配置了两个虚拟网络适配器，一个虚拟适配器通过业务 VLAN ID 与业务SEA 网络连通， 接入外部千兆网络；一个虚拟适配器通过管理 VLAN ID 与带内管理SEA 网络连通， 接入外部万兆网络。PowerHA 节点间通过双网络、双网络接口和双 IP 互联互通， 形成两个网络心跳，互相探测对方存活状况。解决本地单网络故障时发生脑裂的风险隐患。
（2） NETMON 探测： 在双网络全部故障时，为防范脑裂风险，针对性的在PowerHA 配置中增加了 NETMON 探测，将以一定时间频率探测业务 VLAN ID 所在网段的网关虚拟地址。当某个 PowerHA 节点故障时，另一个节点到该故障节点的双网络心跳也将全部中断，此时通过 NETMON 探测将发现哪个节点是存活节点，PowerHA 所有资源组将切换到该存活节点。通过这种方式和双网络心跳结合，能够区分出是节点故障还是节点间单网络故障，并通过合理的机制，进行故障转移。如果是节点间双网络故障，也就是所有千兆交换机和万兆交换机均同时故障，这时 NETMON 也无法探测成功，将有可能发生脑裂（在该故障场景，将通过 PowerHA 灾难恢复方案来解决，详见 PowerHA 扩展方案）。
（3） Concurrent VG： 本地 PowerHA 节点共享同一个外置存储 VG，并将 VG 卷组设置为 Concurrent VG 模式，所有节点均识别了外置存储盘并 Varyon VG, 但仅有主节点能够对该 VG 进行读写，其他节点的 VG 权限为：passive-only。通过这种方式尽量减少挂盘动作和启用卷组动作带来的时间开销，减少 PowerHA 节点间故障转移的时间。
3、本地同城双数据中心 PowerHA 扩展方案
为了实现两个数据中心 PowerVM 环境下，多 Power 虚拟机间的高可用和灾难恢复，某银行在本地 PowerHA 架构的基础之上，结合两个数据中心存储间的远程复制技术， 进一步拓展升级为 PowerHA Extended Disaster Recovery （ 简称PowerHA/XD）架构。下图为 PowerHA SystemMirror 7.1 Enterprise Edition 支持的远程存储复制技术：
充分利用 PowerHA SystemMirror 7.1 企业版，通过接口实现对 SVC Metro Mirror 一致性组的管理能力，联动跨数据中心的多 PowerHA 节点和其各自底层的存储卷，切换 SVC PPRC 关系，能够让灾备站点可以在主站点发生故障时，让主站点释放 PowerHA SystemMirror 管理的资源组，灾备站点接管资源组， 同时保证切换前后，两个站点间数据的一致性，最终实现站点级故障转移。下图所示为分布式应用+PowerHA/XD 架构数据库的部署架构图示例，其中数据中心 A 部署了两个应用节点、两个数据库节点（PowerVM 环境）和一套双节点的 SVC 集群，数据中心 B 部署了两个应用节点、一个数据库节点（PowerVM 环境）和另一套双节点的 SVC 集群，四个应用节点由前端的负载设备实现请求均衡，所有应用节点通过 PowerHA 虚拟服务 IP 访问拥有资源组的主数据库节点。具有以下几个方面的特点：
（1） Link Cluster： PowerHA/XD 的架构需要采用 Link Cluster 来 Link 两个站点的 PowerHA 节点，相较于 PowerHA6.1 版本,PowerHA7.1 下的 PowerHA/XD 方案在每个站点都有自己的 CAA 存储库磁盘，由 CAA 在站点之间自动复制，来保证两个站点所有集群拓扑相关的信息的一致性。另外，Link 的集群站点使用单播而不是多播进行通信。但是本地站点内部仍然使用多播，多播仍需要在每个站点的网络中启用。
（2） SVC 集群间远程复制关系和一致性组： 生产和灾备站点各自部署了一套 SVC 集群，这两套 SVC 集群间通过 Metro Mirror 实现卷的远程实时同步，多个卷也可以以卷组的方式，实现同步一致性组，来保证在该卷组中的所有卷均以相同的时间戳进行同步，避免因时间戳不一致导致切换后数据逻辑性不一致问题。另外，在配置 PowerHA/XD 时，需要在 PowerHA 中定义 SVC PPRC，并将定义后的 SVC PPRC 一致性组加入 PowerHA 的资源组配置中，定义的内容包括两个站点 SVC 集群的信息、SVC PPRC 关系的定义和 SVC PPRC 一致性组的定义，这些定义必须和SVC 上的真实配置和关系完全一致，否则将无法通过PowerHA 同步校验。
（3） PowerHA 节点至两个 SVC 集群的 SSH 互信： 所有 PowerHA 节点均需建立到两个数据中心两套 SVC 集群的 SSH 互信关系，PowerHA SystemMirror 通过SSH 互信，来访问和控制两套 SVC 集群的远程复制关系和一致性卷组，但这种控制仅仅体现在该 PowerHA 配置中定义的 SVC PPRC 关系和一致性卷组，其他PowerHA 中定义的卷组和 PPRC 关系不受控制，完全隔离。
（4） 双网络心跳与 NETMON 探测防脑裂： 灾备的 PowerHA 节点也按照本地两个 PowerHA 节点的方式一样，建立两个虚拟网络适配器，通过业务和管理两个SEA 接入外部网络，并通过一对 DWDM 波分复用设备与生产端两个 PowerHA 节点通讯，实现双网络心跳。同样为了防止两个站点间链路中断导致 PowerHA 脑裂， 所有 PowerHA 节点均配置了 NETMON 探测，每间隔一段时间探测生产端网关的虚拟地址。当两站点间链路中断时，灾备端 PowerHA 节点与生产端的双网络心跳全部中断，此时网关只在生产端能通，由于防脑裂保护机制，灾备站点的 PowerHA 将自动重启以停止 PowerHA 服务，生产端将赢得或继续保持资源组；当生产站点故障时，网关虚拟地址将漂移到灾备站点，灾备的 PowerHA 将存活，赢得资源组。
三、实践效果
自 2013 年以来，在 IT 基础架构方面，某银行一直致力于 Power 虚拟化和云化转型，并不断完善 Power 高可用性和同城灾备建设，向着大同城和双活数据中心目标不断迈进。现如今，在 PowerVM 环境下，针对生产交易类业务系统数据库和小部分关键性应用，某银行已实现超过 80 套 PowerHA 架构向 PowerHA/XD 架构的升级拓展。同时利用该架构技术，顺利将银行生产业务系统数据库切换至同城灾备中心，实现原生产数据中心和同城灾备数据中心的职能转换，新数据顺利投产运行。经过 PowerVM+PowerHA 的顺利实践，取得较好的效果。总结起来，体现在以下三个方面：
1） 进一步夯实了银行交易类系统数据库本地高可用和同城灾备架构，实现了数据库站点级故障转移自动化，完成了 RPO=O，RTO<5 分钟的即定目标；
2）借助 Power 虚拟化，提升了硬件资源利用率和纵向扩展弹性，进一步提升了运维敏捷性；
3）通过对 Power 服务器进行虚拟化，为 IT 基础架构云化转型升级打好了坚实的基础，实现了生产和同城灾备双数据中心云。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
PowerVM最佳实践与案例分享
http://www.talkwithtrend.com/Document/detail/tid/428719
Power Enterprise Pool结合PowerHA的高可用技术实践
http://www.talkwithtrend.com/Article/245979
欢迎关注社区 "K1 Power 服务器" 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：
http://www.talkwithtrend.com/Topic/247
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场