城商行生产环境虚拟化资源池架构设计及应用迁移十个难点解读

Posted 2021-04-11 twt企业IT社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了城商行生产环境虚拟化资源池架构设计及应用迁移十个难点解读相关的知识，希望对你有一定的参考价值。

目前大多数城市商业银行都已经建设有自己的虚拟化资源池。但是虚拟化资源池在实际使用过程中，还存在不少的问题和难点，比如：如何规划虚拟化资源池、增加虚拟化资源池的冗余性、如何规避鸡蛋全部放在虚拟化资源池这个“篮子”里等问题。

在社区近期交流中，我们邀请到了某城商行与某国有银行的专家，以及来自浪潮商用机器的专家，来对城商行生产环境虚拟化资源池架构设计及应用迁移进行交流探讨，重点帮助大家解决如何规划虚拟化资源池、如何进行应用迁移等问题。

1、中小银行生产环境虚拟化是否需要资源池化？高可用性如何保障？

【问题描述】核心系统应用服务器来实现资源池化，那对企业的业务连续性要求非常高，当前资源池的高可用和稳定性是否能满足，预期故障如何应对，这应该是十分关键的。

@michael1983 某证券技术经理：

核心系统应用服务器，在应用架构设计层面，采用分布式部署，少量服务器节点故障不会对业务产生影响。基础资源池本身的高可用和稳定性，作为辅助，不能作为最后的依靠。

@陈炽卉浪潮商用机器企业云创新中心系统架构师：

就技术层面而言，虚拟化和资源池化是基础架构的必然趋势，反而言之，并没有绝对的理由拒绝虚拟化、资源池化所带来的优势，包括但不局限于：1 ）标准化 2 ）灵活性 3 ）更高的性价比 4 ）更好的业务弹性 5 ）更迅捷的业务响应等等；

在高可用性方面，参见问题本文《 Power 资源池保障高可用的技术方案有哪些？如何尽可能提高 Power 资源池容灾的投入产出比？》的回答。

主要要点在于：

1、 LPM 在线迁移虚拟系统

在业务系统运行无感知的情况下，实现虚拟系统从一台物理设备到另外一台物理设备的动态迁移，实现物理硬件常规的日常维护

2、 PowerHA应用高可用

对业务应用系统在资源池的两台物理设备上部署 PowerHA 高可用架构，在任意一台虚拟系统异常、导致业务服务异常的情况下 ( 包括操作系统、应用系统异常等 ) ，进行虚拟系统之间的切换，保证业务应用系统的可服务状态；

3、 Remote Restart重启

在资源池中的物理设备异常宕机的情况下，将故障设备所承载的虚拟系统在资源池中的其他资源上重新启动；

@BLACKFLAG 某国有银行系统架构师：

只要设计好了，资源池的高可靠、稳定性没问题，比如建行所有开放系统2013年上的，包括网银、手机银行、贷记卡等核心系统，比较稳定，没问题。

2、Power资源池保障高可用的技术方案有哪些？如何尽可能提高Power资源池容灾的投入产出比？

@colins 金融行业系统工程师：

针对虚拟机方面，可以采用LPM来完善业务的连续性。针对物理机方面，可以通过remote restart来降低宕机带来的停机时间，进而提高系统的可用性。

@李卫国浪潮商用机器企业云创新中心系统工程师：

关于资源池高可用的方案，常规方案包括：

1、 LPM 在线迁移虚拟系统

在业务系统运行无感知的情况下，实现虚拟系统从一台物理设备到另外一台物理设备的动态迁移，实现物理硬件常规的日常维护

2、 PowerHA应用高可用

3、 Remote Restart重启

在资源池中的物理设备异常宕机的情况下，将故障设备所承载的虚拟系统在资源池中的其他资源上重新启动；

至于如何尽可能提高 Power 资源池容灾的投入产出比？实际是提高资源利用率的问题，常规的方案一般包括：

1、建立 IP 层打通的跨数据中心的同城容灾双资源池，对于非数据库、非集群的业务逻辑层部署在容灾的两端，提高资源利用率；

2、采用 enterprise pool 解决方案提高容灾数据中心之间的 CPU/ 内存资源 license 共享；

3、容灾中心资源与研发、测试等环境共享，在需要时进行动态调配；

@BLACKFLAG 某国有银行系统架构师：

1、多网卡、多HBA卡做荣誉

2、2个vios做冗余，每个vios多个网卡和HBA卡，做虚拟卡给vioc使用

3、root盘用vSCSI，数据盘用NPIV

4、用LPM迁移

5、从架构上做多个集群、多个节点，比如RAC双节点

3、资源池计算资源扩容时，新加设备与老设备的兼容性问题如何解决？

在虚拟化资源池扩容时，新采购的服务器与原有的服务器存在代差，新老设备间的兼容性问题如何解决？

@BLACKFLAG 某国有银行系统架构师：

资源池最好是按扩容单元进行扩容，一次购买一个或多个扩容单元，后续采购不要加到之前的扩容单元中，仍然按扩容单元独立部署。如果非要放一起肯定要测试，要考虑能否放到一个集群中，vmotion会不会因为指令集不同而失败等

@李卫国浪潮商用机器企业云创新中心系统工程师：

一般情况下，对于Power资源池平台，从以下几个方面进行兼容性问题的考量：

1 、管理平台对纳管设备的兼容性要求

建议登陆 IBM 的官方网站：https://www.ibm.com/support/knowledgecenter/en/SSXK2N_1.4.0/com.ibm.powervc.standard.help.doc/powervc_planning_hmc.html ，调整相关的版本后，对软硬件的要求进行确认

对 Power 设备而言，关键的几点包括：

１） HMC 的版本要求；

２） VIOS 的版本要求；

３）支持的 Power 设备；

４）虚拟系统的版本要求；

2 、确认新旧设备的操作系统版本支持

参考：https://www-01.ibm.com/support/docview.wss?uid=ssm1platformaix ，确认各硬件平台对操作系统版本的支持

3、总体建议

１）总体而言，越高版本的操作系统，对硬件的支持总是更为完整，因此在部署实施时尽量选择较新的版本；

２）对于实在无法兼容的设备或版本，建议分别建立不同的 host group ，保证资源池功能的最大化。

4、什么应用适合放到什么类型的资源池里？数据库是否适合放到Power资源池？

@陈炽卉浪潮商用机器企业云创新中心系统架构师：

可以根据客户具体的业务场景来进行选择。开源数据库、中间件可以基于K1 OpenPOWER 服务器通过 PowerVC+KVM 方式整合。商业数据库以及企业级应用套件 / 中间件整合可以采用 PowerVM 资源池。

PowerVM 目前在金融行业已经有广泛应用，包括各类核心、外围、前置、数仓、 ERP 系统等等，性能、可靠性都经受住了严苛考验。针对不同客户的业务灵活性、性能需求， PowerVM 有众多虚拟化特性组合可供选择。对常见的虚拟化性能瓶颈点，如网络 IO 、磁盘 IO ，目前 PowerVM 都有了可靠的解决方案：

分配同等虚拟资源情况下，相对于同代 Power 物理服务器提供相当性能，并通过高端服务器整合提供更高的弹性性能和扩展性；
对于整合旧 UNIX 、 PC 服务器的场景，提供多倍于原系统的开放平台最高单核性能来加速应用，并提供更大的性能弹性和扩展性；
少数需要极致网络、磁盘 IO 性能，以及对响应时间极度敏感的应用，建议单独评估测试；可能需要评估优化 NPIV 组网架构、采用 vNIC/SRIOV 虚拟化方案等等；或考虑同时使用虚拟资源以及部分物理资源。

@BLACKFLAG 某国有银行系统架构师：

兼顾成本与高可用需求，建议web、ap用x86虚拟化，VMware和KVM都行；如果不差钱，db用PowerVM最好，成熟稳定，当然，db用x86可以进一步节省成本，mysql、Oracle19c多租户都可以。

5、在后续的维护当中，建立资源池和不建资源池维护有区别吗？

@陈炽卉浪潮商用机器企业云创新中心系统架构师：

基于 PowerVC 的资源池平台为日常维护提供了极大的便利性，其标准版所涵盖的功能包括且不局限于以下功能。如果没有管理平台，以下相关的管理工作将全部依赖手工完成或无法实现：

１）集成化的计算资源、存储资源、网络资源管理；

２）镜像管理；

３）池化、简易的统一系统管理；

４） VM 监控、管理和迁移；

５） VM 基于策略的部署；

６） VM 的自动资源动态调整；

@某银行系统工程师：

首先要弄清楚为什么要建立资源池，资源池划分的标准是什么，资源池的特征和特点是什么。我觉得如果规模合适，以资源池形式管理资源是非常好的，可以实现资源的标准化、自动化、批量化、自动化管理以及弹性扩展。

6、异构服务器资源池化以后，面临统一管理，请教下大家是否有经验可以分享？

@某银行系统工程师：

市面上没有一个云管平台可以很好的管理异构资源池，都是企业自研的，比如把PowerVM、VMware、x86数据库甚至是K8s整合到一个平台管理，必须自研。

@李卫国浪潮商用机器企业云创新中心系统工程师：

异构服务器资源池化后，面临的统一管理问题，一般是上升至云平台的管理范畴，如下图，是 IBM 的商业 ICP 云管平台架构图：

城商行生产环境虚拟化资源池架构设计及应用迁移十个难点解读

一般而言，解决方案可分为三类

1 ）商业解决方案：采用现有的 IBM ICP/IBM CAM /VMware(vRA/vRO) 等解决方案

2 ）利用资源池平台与开源组件进行结合的开源解决方案，例如， PowerVC 可以结合 ansible 、 chef 等开源组件，根据要求定制与 X86 平台相同的管理方式；

3 ）利用资源池平台 API 的接口方案，客户方自行根据本身的管理要求、特点、 OA 流程、权限管理等，进行定制开发。

7、池化之后网络的部分比较复杂，怎么做迁移，宿主机出现问题之后平滑过渡的流程是什么？

@陈炽卉浪潮商用机器企业云创新中心系统架构师：

池化之后，网络部分确实较为复杂，但万变不离其宗，抓住几个主要关键设计问题：

１）带外管理如何设计：HMC 和服务器的 FSP 的连接问题以及独立网络通道；

２）数据迁移通道如何设计：HMC 和 VIOS 之间的连接问题 ( 含 RMC ) 以及独立网络通道，包括网关路由设计、防火墙策略等；

３）不同虚拟业务系统的网络通道如何设计：各虚拟系统的对外桥接 VLAN 设计、相互间的隔离、与 HMC 的 RMC 通信和隔离问题 ( 网关路由设计、防火墙策略等 ) ；

４）网络性能评估是否满足需求：所承载业务对网络的带宽性能要求，网卡绑定策略，参数优化设置等；

如何做迁移：

１） NIM 备份、恢复是较为理想的方案；

２）手工 mksysb 备份、恢复；

３）数据的迁移可考虑存储数据复制或逻辑层面的备份和方案，看具体的应用系统要求， tar/cpio/rman/expdump 等

宿主机出现问题后平滑过渡的方案，这实际上是平台的高可用问题，在设计上有三个层面：

１）在应用逻辑层面，可使用 PowerHA 等高可用软件将应用逻辑切换至正常的宿主机；

２）在资源池层面，在故障不影响 LPM 的情况下，进行联机的虚拟系统迁移；

３）在宿主机意外宕机的情况下，资源池平台的 Remote Restart 支持在其他宿主机上重启虚拟系统；

8、如何降低虚拟化资源池管理的工作量？故障能否实现统一告警处理？

【问题描述】当前各城商行基本都进行了虚拟化，但是一般是一个功能区一个虚拟化资源池，多池管理比较复杂，难度加大。如何简化这方面的工作，提供运维能力，降低工作量？资源池内的物理机故障及虚拟机的故障能否实现实现统一告警处理？

@李卫国浪潮商用机器企业云创新中心系统工程师：

实际上，与资源池有关的工作量主要在于资源池的建设阶段，在这个阶段需要根据需求、规范等将各类资源根据规范有效地整合成资源池，满足业务系统的灵活需求。在资源池建设完成后，日常使用过程中相对反而简单；管理工作主要在于保持整个平台资源的稳定和可控，处理个别计算、存储、网络资源故障对整体资源池的影响。

当然，在多池的情况下，则是需要更高一层的云管平台进行整体资源的调度和分配，从更高维度提升运维能力、降低工作量。

关于故障的有效管理，不同的管理平台有着不同的侧重点和机制。就 PowerVC 而言，目前还主要关注于资源池级别的状态监控。更细粒度的、传统意义上的故障监控可管理，可借助于相关计算资源、网络资源、存储资源本身具有的网管功能实现，例如：HMC 、 VIOS 、 OS 都提供了 SNMP 接口，也支持大部分的商业或开源监控产品或组件，例如 tivoli,zabbix 等。

@某银行系统工程师：

多池、异构资源池的管理要靠盖个大帽子-云平台来管理。底层监控产品可以用一些开源或者商业产品，在上面做一层报警事件的整合平台，可以实现报警过滤、自动化处置、聚合报警等

9、服务器资源池化之后的安全策略方面的规划，应该要如何做？

@李卫国浪潮商用机器企业云创新中心系统工程师：

服务器资源池虚拟化之后，对安全策略方面的规划，提出了更高的要求，

1）首先是资源池的规划设计要满足对业务安全的规划设计

资源池在整体资源上的配置和隔离，要满足业务系统安全规划，针对不同的业务安全区域进行不同的配置和规划；

2）存储数据的安全性方面

数据的分配、隔离、备份、恢复、容灾等各个环节的规划都需要详细的定制和确认，包括但不限于：

（1）双 VIOS 冗余设计

（2） VIOS 内冗余通道设计

（3）存储 pool 的使用规划，隔离措施；

（4）存储高可用设计：本地双存储镜像

（5）存储同城 / 异地容灾设计

（6）数据备份 / 恢复 / 导入 / 导出设计；

3）网络的安全性方面

（1）带外管理的通道的设计和隔离；

（2）业务网络通道的设计和隔离；

（3）数据迁移通道的设计和隔离；

（4） VLAN 的设计和规划，相关的网络隔离；

4）操作系统层面的安全策略规划及如何部署和实施

小型机和 X86 运行不同的操作系统，其安全规范的制定及如何部署实施差别较大，需要相关平台予以统一设计和支持：

（1）统一 Nim 的部署管理维护

（2）Asible/chef 的使用，以及与 Power 平台 PowerVC 及 X86 其他管理平台的融合；

@BLACKFLAG 某国有银行系统架构师：

安全无底线，安全的问题最难回答，而且个人认为安全不是资源池化考虑的重点，安全考虑更多的是划分互联或外联DMZ隔离区，外围采用IDS、DDOS、WAF等防护，内部网络用防火墙控制，资源池内部可以使用vmware的nsx做微分段，或者类似公有云的安全组来做同网段虚机间的隔离，甚至可以用iptables来做访问控制。

10、如何将容量管理更好的融入虚拟化平台中？

【问题描述】容量管理已经成为城商行科技管理中重要的一环了，如何能成体系的将容量管理融入到虚拟化平台中呢？本身虚拟化平台可以实现容量管理的部分功能，但从容量管理的整体来看还是有很多不足，很多事物需要人工进行分析和移植数据，无法完全满足容量管理的要求，是否有第三方软件可以接入？

@陈炽卉浪潮商用机器企业云创新中心系统架构师：

1 、总体而言，资源池的一个重要的特性是能够根据业务的实际负载进行资源的动态调整，因此做好资源池整体资源的容量规划是首先的要点；

2 、做好资源池整体的资源监控是日常维护的重点，确保有一定的资源冗余度；

1 ）宏观而言，在整个资源池层面，在设计容量以及进行系统部署时，需要保证在设定的容错范围内，任意一个节点故障后，其上所承载的系统能有效地转移至其他节点；

2 ）微观层面，针对单个虚拟机，则需要进行有效性能评估后进行合理资源配置，很重要的一点是进行必要的业务压力测试；

3 ）综合考量业务系统的性质、重要程度等，采用不同冗余系数。