Dongxin
作者Dongxin2019-10-25 10:47
系统架构师, 某银行股份有限公司

某银行 PowerVM 环境下 PowerHA 最佳实践

字数 5774阅读 3251评论 3赞 11

一、背景

现如今,云计算发展如火如荼,从 IasS 、 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 计算节点能够 提供的最大带宽,可以满足银行现阶段单台计算节点虚拟机的业务流量总和要 求;对于数据管理而言,充足的万兆带宽可以满足大量数据的吞吐量要求,并减少传输时间。


(3) NPIV 多路径设计 : 每个 VIOS 配置两块 HBA 光纤卡,每个卡只用了一 个口,分别接入不同的 SAN 交换机 ( 支持 NPIV) ,所有 Power 虚拟机均建立了 四个虚拟 FC 适配器, 并与两个 VIOS 各两个物理 FC 适配器接口 ( 设置 fc_err_recov:fast_fail,dyntrk:yes) 建立一一映射,如下图所示。这样虚拟机总计拥有 8 条 NPIV 多路径连接外置存储,所有虚拟机的操作系统盘和数据 盘均由外置存储提供,通过 SAN BOOT 方式引导启动。


(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 的集群站点使用单 播而不是多播进行通信。但是本地站点内部仍然使用多播,多播仍需要在每个站 点的网络中启用。

(1) SVC 集群间远程复制关系和一致性组: 生产和灾备站点各自部署了一 套 SVC 集群,这两套 SVC 集群间通过 Metro Mirror 实现卷的远程实时同步,多 个卷也可以以卷组的方式,实现同步一致性组,来保证在该卷组中的所有卷均以 相同的时间戳进行同步,避免因时间戳不一致导致切换后数据逻辑性不一致问 题。另外,在配置 PowerHA/XD 时,需要在 PowerHA 中定义 SVC PPRC ,并将定义 后的 SVC PPRC 一致性组加入 PowerHA 的资源组配置中,定义的内容包括两个站 点 SVC 集群的信息、 SVC PPRC 关系的定义和 SVC PPRC 一致性组的定义,这些定 义必须和 SVC 上的真实配置和关系完全一致,否则将无法通过 PowerHA 同步校验。

(2) PowerHA 节点至两个 SVC 集群的 SSH 互信: 所有 PowerHA 节点均需建 立到两个数据中心两套 SVC 集群的 SSH 互信关系, PowerHA SystemMirror 通过SSH 互信,来访问和控制两套 SVC 集群的远程复制关系和一致性卷组,但这种控 制仅仅体现在该 PowerHA 配置中定义的 SVC PPRC 关系和一致性卷组,其他 PowerHA 中定义的卷组和 PPRC 关系不受控制,完全隔离。

(3) 双网络心跳与 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 基础架构云化转型升级 打好了坚实的基础,实现了生产和同城灾备双数据中心云。

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

11

添加新评论3 条评论

#xxjsb613数据库管理员, 泉州银行
2019-11-04 23:36
powerHA的优势在于简单稳定,劣势在切换会有中断,还是要根据业务系统等级来选择保护方式
#light_hu86系统工程师, 浙江农信
2019-11-01 13:46
TSA结合HADR的方法部署双机相比PowerHA的方式是否效果更好,优劣势各有哪些。
#iwantcomputer系统工程师, dg
2019-10-30 15:11
挺好的文章,感谢分享!

kingdanis@iwantcomputer 收藏,需要慢慢消化

2019-11-07 09:08
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30