colins
作者colins2019-09-26 18:15
系统工程师, 金融行业

城商行生产环境虚拟化资源池架构设计及应用迁移交流探讨总结

字数 9554阅读 3728评论 0赞 3

随着银行业务的发展和创新,银行对服务器和存储等硬件资源的需求不断增加,随着而来,对机房的规模及管理费用的持续增高,管理日渐复杂。怎样最大化地利用硬件资源,如何有效地降低管理难度,怎样才能简化城市商业银行的 IT 架构 , 怎样才能避免 IT 架构的非必要扩张,这些已经成为了所有城市商业银行面临的棘手问题。 因此,很多城商行开始摸索虚拟化资源池建设,来解决这些问题。

基于上述目的, twt 社区专门开展了城商行生产环境虚拟化资源池架构设计最佳实践的交流活动, 并特别邀请了城商行项目经理 colins ,大型国有银行数据中心高级工程师 BLACKFLAG ,以及浪潮商用机器技术支持部资深工程师李卫国分享关于虚拟化资源池架构设计和应用迁移等内容,帮助大家解决虚拟化资源池建设过程中遇到的难点和问题。以下是本次活动的核心议题:

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

  2. 什么应用适合放到什么类型的资源池里?数据库是否适合放到 Power 资源池?

  3. 统一的资源池里, Power 资源池和 x86 的资源池可否做到资源互通、共享?如何实现?

以下是本次交流的总结:****

一、虚拟化资源池方案建设相关

1、统一的资源池里,Power资源池和x86的资源池可否做到资源互通、共享?如何实现?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

在物理层面,对于 CPU 、内存等计算资源,实际上对于完全不同指令集架构的资源池平台,例如 Power 平台和 X86 平台资源池,目前暂无法实现资源的互通和共享,或者转换。

但就业务系统的逻辑层面而言,则是有机会实现互通、共享的,关键看业务平台的设计。例如跨平台的 Java 应用、大数据平台、 GPFS 共享文件系统、 Tomcat 中间件负载均衡、 Kubernets 的容器编排等,实际上是软件层面的无平台差异化性,实现了对 Power 资源池和 X86 资源池的资源互通或共享。

在管理层面上,可以实现 Power 资源池和 x86 的资源池统一的调度管理。

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

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

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

1) 带外管理如何设计: HMC 和服务器的 FSP 的连接问题以及独立网络通道;

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

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

4) 网络性能评估是否满足需求:所承载业务对网络的带宽性能要求,网卡绑定策略,参数优化设置等;

如何做迁移:

1) NIM 备份、恢复是较为理想的方案;

2) 手工 mksysb 备份、恢复;

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

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

1) 在应用逻辑层面,可使用 PowerHA 等高可用软件讲应用逻辑切换至正常的宿主机;

2) 在资源池层面,在故障不影响 LPM 的情况下,进行联机的虚拟系统迁移;

3) 在宿主机意外宕机的情况下,资源池平台的 Remote Restart 支持在其他宿主机上重启虚拟系统;

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

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

关于资源池高可用的方案,常规方案包括:

1 、 LPM 在线迁移虚拟系统

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

2 、 PowerHA 应用高可用

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

3 、 Remote Restart 重启

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

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

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

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

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

4、虚拟化工作是否应该一步到位,服务器、存储、网络虚拟化同步进行的风险点在哪里?

BLACKFLAG 系统架构师 , 某国有银行

可以一步到位,也可以分开建设,主要看契机与投入,比如说很多单位革新,IT要搞新一代,很多应用系统要重构,借这种机会把基础设施也重构了,由竖井式变为云化。当然如果没有大的契机,可以先从计算虚拟化做起,最能体现价值,原来一台机器给一个系统使用,现在可以把粒度变小,给多个系统使用。

同步进行最大的风险点就是领域间融合以及配套工具的开发上,一般工具开发不是短期的事情,需求总在变化,方案总在演进,需要持续投入

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

实际上,在目前的基础架构中,服务器、存储、网络已全部使用了虚拟化技术。 服务器层面是 PowerVM,VMware,Xen 等;存储层面广泛使用存储虚拟网关;网络层面早已使用 vlan 技术等,本质而言都是各种资源的虚拟化技术;

而风险在于统一的资源池管理平台是否能够进行统一的、安全可靠的管理,而且同时涉及上述三个领域;目前 OpenStack 是业界较为成熟的解决方案,已逐渐成为事实上的业界标准;

资源池管理平台,最大风险应该在于权限的管控上,毕竟作为管理平台,能够一键删除相关正运行的系统和资源,这一点在日常维护中需要高度重视,做好用户、角色、权限的粒度管理。

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

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

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

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

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

主要要点在于:

1 、 LPM 在线迁移虚拟系统

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

2 、 PowerHA 应用高可用

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

3 、 Remote Restart 重启

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

6、异构服务器资源池化以后,面临统一管理,在这块想请教下大家是否经验可以介绍分享?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

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


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

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

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

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

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

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

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

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

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

8、powervm资源池的信息存放在哪里,做维护时会不会出现部分操作要求先解除资源池,操作完成后重建的操作?

BLACKFLAG 系统架构师 , 某国有银行

powervm资源池信息主要存在云平台以及hmc、vios上,hmc和vios的配置信息一定要在云平台有存放,否则一旦丢失后果比较严重,我们就发生过换主板把FSP搞坏的事情,vios和vioc的profile信息都丢了,幸好从备份中恢复了一部分,手工重建了一部分

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

Power 资源池的管理平台 PowerVC 本身维护着一个管理数据库,用以存放管理信息。在日常维护过程中,确实存在这样一种情况: PowerVC 数据库中记录的信息与 HMC 、存储、 VIOS 、 VM 本身信息不一致的情况,这时候,需要将相关资源从 PowerVC 平台中取消管理,而后重新纳管,以便保持信息的同步。

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

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

一般情况下,对于 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 设备而言,关键的几点包括:

1) HMC 的版本要求;

2) VIOS 的版本要求;

3) 支持的 Power 设备;

4) 虚拟系统的版本要求;

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

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

3 、 总体建议

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

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

10、在后续的维护当中,建立资源池和不建资源池维护有区别吗?

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

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

1) 集成化的计算资源、存储资源、网络资源管理;

2) 镜像管理;

3) 池化、简易的统一系统管理;

4) VM 监控、管理和迁移;

5) VM 基于策略的部署;

6) VM 的自动资源动态调整;

11、虚拟化资源异构平台间迁移?

如何在统一纳管异构平台虚拟化后,进行不同平台间的资源迁移?比如从 vmware 到 openstack 的虚拟机格式转换和平台间迁移,不停机或者缩短停机时间,减少应用影响?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

在物理层面,对于 CPU 、内存等计算资源,实际上对于完全不同指令集架构的资源池平台,例如 Power 平台和 X86 平台资源池,目前暂无法实现资源的互通和共享,或者转换。

但就业务系统的逻辑层面而言,则是有机会实现互通、共享的,关键看业务平台的设计。例如跨平台的 Java 应用、大数据平台、 GPFS 共享文件系统、 Tomcat 中间件负载均衡、 Kubernets 的容器编排等,实际上是软件层面的无平台差异化性,实现了对 Power 资源池和 X86 资源池的资源互通或共享。

对于相同的指令集的资源池平台,本质上是虚拟化格式的转换,如 VMware 和 KVM ,这些在 X86 平台上,相关工具也比较成熟。

涉及到停机或不停机的问题,实际上是有解决方式,可以进行快照的捕获,而后进行转换等。

12、(X86、小型机)服务器资源池化之后的安全策略方面的规划,应该要如何做?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

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

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

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

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

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

( 1 )双 VIOS 冗余设计

( 2 ) VIOS 内冗余通道设计

(3) 存储 pool 的使用规划,隔离措施;

(3 )存储高可用设计: 本地双存储镜像

(4 )存储同城 / 异地容灾设计

( 5 )数据备份 / 恢复 / 导入 / 导出设计;

3 ) 网络的安全性方面

(1) 带外管理的通道的设计和隔离;

(2) 业务网络通道的设计和隔离;

(3) 数据迁移通道的设计和隔离;

(4) VLAN 的设计和规划,相关的网络隔离;

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

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

(1) 统一 Nim 的部署管理维护

(2) Asible/chef 的使用,以及与 Power 平台 PowerVC 及 X86 其他管理平台的融合;

13、异构资源怎么分配?池化后如何解决应用对基础资源的异构需求?

不同的应用系统对资源的需求不同,特别是基础资源如底层操作系统版本, JDk 等。池化后如何解决应用对基础资源的异构需求。

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

实际上,这是基础架构的云演进路线问题,在 Power 资源池、 X86 资源池建设后,自然而然地将面对异构平台资源池的统一管理问题,实际上是需要向基础架构云的方向进行演进,能够根据业务系统的需要,一次性地在 Power 资源池和 X86 资源池部署出需要的基础架构系统;

二、资源池规划及容量管理

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

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

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

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

Ø 分配同等虚拟资源情况下,相对于同代 Power 物理服务器提供相当性能,并通过高端服务器整合提供更高的弹性性能和扩展性;

Ø 对于整合旧 UNIX 、 PC 服务器的场景,提供多倍于原系统的开放平台最高单核性能来加速应用,并提供更大的性能弹性和扩展性;

Ø 少数需要极致网络、磁盘 IO 性能,以及对响应时间极度敏感的应用,建议单独评估测试;可能需要评估优化 NPIV 组网架构、采用 vNIC/SRIOV 虚拟化方案等等;或考虑同时使用虚拟资源以及部分物理资源。

2、虚拟化的冗余资源计算问题?

在做系统虚拟化时,池化的资源池一般都会配置冗余设备,请问,按照什么原则配置冗余资源?比如应该配置几台冗余机器?冗余的机器在资源池里空闲等待接管,还是可以把虚拟机分布到所有的机器上?实际使用的 CPU 、内存与需要配置的 CPU 、内存之间的比例应该如何?

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

需要综合考量业务系统的性质、重要程度来决定业务冗余度;重要的分区可以采用更高的冗余度,比如 PowerHA + Remote Restart 方式部署。

基于成本考虑,没有必要配置专门的冗余机器;但通常建议确保每台机器有一定的冗余度,以保证资源动态调整灵活性。

就 PowerVM 分区而言,实际配置的期望 CPU ( EC )数应当能满足日常业务峰值需求,而 VCPU 数应当能满足业务最大峰值需求;内存动态调整速度略慢,通常建议尽量足额配置。

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

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

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

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

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

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

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

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

4、生产数据中心虚拟化资源池的合理规划?

虚拟化资源池的规范管理面临下面的问题:

1 、金融行业的资源池一般按照业务功能区划分:比如核心区、外联区、互联网区等

每个区的随着业务的增长,资源池的服务器都会进行扩容,扩容就会面临品牌、型号、生产日期的不同,这样就会出现多个资源集群,不同的资源集群就会出现资源浪费、无法热迁移等问题,怎样规避这些问题?基于这种现象有没有什么优化调整的建议?

2 、对于资源池里面网络风暴怎么预防和处理?在网络架构设计方面需要注意哪些?

3 、网络功能区的设计造成不同资源池的应用跨网络访问,对防火墙的性能要求就提出了挑战,对网络规划有什么好的建议?数据库和应用采用一个网段好呢?还是不同网段好呢?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

虚拟化资源池的规范管理面临下面的问题:

1 、金融行业的资源池一般按照业务功能区划分:比如核心区、外联区、互联网区等

每个区的随着业务的增长,资源池的服务器都会进行扩容,扩容就会面临品牌、型号、生产日期的不同,这样就会出现多个资源集群,不同的资源集群就会出现资源浪费、无法热迁移等问题,怎样规避这些问题?基于这种现象有没有什么优化调整的建议?

答复: 由于业务功能区的划分,确实是存在多个资源池的可能。但资源池管理平台一般都支持资源的纳管和剔除。例如 PowerVC ,通过简单的资源取消管理、资源重新纳管等调度措施,可以很方便地实现资源在不同资源池之间的剔除和加入。

2 、对于资源池里面网络风暴怎么预防和处理?在网络架构设计方面需要注意哪些?

答复: 实际上网络风暴与资源池建设并没有直接的关系。在早期的虚拟化建设过程中,在网络层面,若设计不合理、实施不规范,特别是对于 VIOS SEA VLAN 、优先级的配置,确实有潜在的网络风暴风险。近几年,随着虚拟化技术的不断完善,在 Power 资源池实施过程中,已基本不会出现网络风暴的问题。

3 、网络功能区的设计造成不同资源池的应用跨网络访问,对防火墙的性能要求就提出了挑战,对网络规划有什么好的建议?数据库和应用采用一个网段好呢?还是不同网段好呢?

答复: 网络规划确实是资源池建设过程中重要的组成部分。包括:

1) 网络性能需求分析

2) 高可用设计考虑

3) Vlan 隔离设计

需要充分考虑所承载的业务特点。一般而言,不会对同一个业务系统的数据库和应用进行网段隔离,除非有特别的安全考虑,否则从业务逻辑和性能角度出发,一般是同一个网段。

三、灾备建设问题

1、如何做到应用及数据级同城和异地灾备?

高中端存储可池化混用? NAS 呢?

LLWWGG 系统工程师 , 浪潮商用机器企业云创新中心

实际上,个人感觉这个问题实际上是在问:同城和异地灾备如何实现? 是在应用层面实现还是在数据层面实现。

不同的应用系统、数据库系统、厂家存储各有着不同的实现方式,关键在于机制的成熟度和有效案例。

在灾备建设过程中,应重视以下几个问题:

• 灾备中心的定位与双活的考量

• 业务系统在生产端 / 容灾端的承载方式

• 所采用的数据复制技术

– 生产数据

– 关键配置信息

• 切换方式的选择

• 充分认识同城 / 异地容灾建设是个逐步完善的过程

2、资源池化以后应用系统的灾备问题?

资源池化后如何实现灾备,从灾备中心实现快速恢复,从而验证备份数据的可用性。

colins 系统工程师 , 金融行业

目前来说,在存储底层实现存储双活或异步复制,基本上是虚拟资源池实现灾备比较常用的方式。

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

3

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

作者其他文章

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