Q:金融机构如何解决新老设备间的兼容性问题?
我行在虚拟化资源池扩容时,新采购的服务器与原有的服务器存在代差,容易出现新服务器的CPU架构与原有服务器不同,可能导致虚拟机迁移或运行时的性能问题或不兼容;新服务器的内存类型、容量与原有服务器不同,可能导致虚拟机运行时的内存访问速度变慢或无法满足需求;新服务器的存储接口与原有服务器不同,可能导致虚拟机迁移或访问存储时的速度问题或不兼容等一系列问题,新老设备间的兼容性问题如何解决?
A:以下是解决新老设备间兼容性问题的一些方法:
1. 硬件兼容性检查:
在购买新服务器之前,进行充分的硬件兼容性检查。确保新服务器的硬件规格与原有服务器兼容,包括CPU架构、内存类型和大小、存储接口、网络接口等。
2. 操作系统和虚拟化软件的支持:
确保新服务器所使用的操作系统和虚拟化软件版本与原有服务器兼容。某些虚拟化平台可能对特定硬件有特定的支持要求。
3. 固件和驱动更新:
在将新服务器投入使用之前,更新新服务器的固件和驱动程序,以确保其与虚拟化平台和操作系统的兼容性。这可能涉及到BIOS/UEFI固件、RAID卡固件、网络和存储适配器的驱动程序等。
4. 迁移和转换工具:
如果存在不同硬件架构或操作系统版本之间的不兼容性,可以考虑使用迁移和转换工具来将虚拟机从旧服务器迁移到新服务器上。例如,CNware提供了迁移工具,用于在不同硬件之间迁移虚拟机。
5. 逐步迁移:
可以逐步将虚拟机从旧服务器迁移到新服务器上,以减少对整个资源池的影响。这可以通过在新服务器上创建新的虚拟机并将工作负载迁移过去,或者将虚拟机从旧服务器迁移到新服务器的方法来实现。
6. 测试和验证:
在将新服务器投入生产环境之前,进行充分的测试和验证。确保新服务器能够正常运行虚拟机,并且工作负载在新服务器上的性能表现符合预期。
通过采取以上各个方法,可以有效解决新老设备间的兼容性问题,确保虚拟化资源池的扩容顺利进行。
Q:虚拟化多池管理复杂,难度大,如何简化这方面的工作?
随着我行业务规模的扩展,IT数据中心逐渐庞大,随之也带来了一些日常使用过程的困惑,比如我行通过虚拟化进行资源池化有效管理资源时,一般是一个功能区一个虚拟化资源池,所以涉及到多池管理就比较复杂,业务量增大导致管理难度加大。如何简化这方面的工作,提高运维能力,资源池内的物理机故障及虚拟机的故障能否实现实现统一告警处理?从而达到提高效率,降低我们的工作量。
A:要简化虚拟化多池管理复杂、难度大的问题,需要根据实际情况进行管理
实际上,与资源池有关的工作量主要在于资源池的建设阶段,在这个阶段需要根据需求、规范等将各类资源根据规范有效地整合成资源池,满足业务系统的灵活需求。在资源池建设完成后,日常使用过程中相对反而简单;管理工作主要在于保持整个平台资源的稳定和可控,处理个别计算、存储、网络资源故障对整体资源池的影响。对于资源池已经建设完毕后,则需要根据整个IT数据中心和资源管理情况,进行逐一分析,根据实际情况进行适当的改造迁移。
当然,在多池的情况下,则是需要更高一层的云管平台进行整体资源的调度和分配,从更高维度提升运维能力、降低工作量。
关于故障的有效管理,不同的管理平台有着不同的侧重点和机制。就PowerVC而言,目前还主要关注于资源池级别的状态监控。更细粒度的、传统意义上的故障监控可管理,可借助于相关计算资源、网络资源、存储资源本身具有的网管功能实现,例如:HMC、VIOS、OS都提供了SNMP接口,也支持大部分的商业或开源监控产品或组件,例如tivoli,zabbix等。
Q:金融机构如何突破“两地三中心”传统模式,进一步提升故障恢复能力?
由于近年来我行电子化程度越来越高,数据越来越集中,我行采用“两地三中心”架构,作为“灾备”安全措施。然而,“两地三中心”架构有几个典型的不足,一是该架构要求同城双中心具备接近的机房容量以满足全量切换,二是该架构模式下异地容灾系统平时一般是“冷”的,并不真正承载业务流量,且灾难发生时很难接管全量业务。随着新建数据中心普遍集中在内蒙古、贵州等远离传统数据中心的地域,新老数据中心容量配比很不均衡等客观条件限制下,我行需要在运行架构上突破“两地三中心”的传统模式,进一步提升故障恢复的体系性能力。
A:要进一步提升故障恢复能力,当前演化方向是“异地多活”的单元化架构。
随着数字金融业务的快速发展,传统集中式生产环境已经很难满足需求。当前演化方向是“异地多活”的单元化架构,以单元化机房(后面简称为LDC)为基础运行单元,以满足快速发展的数字金融业务对基础设施扩展和容灾的高时效性、金融级安全性要求。
“异地多活架构”是指基于LDC单元化架构的扩展能力,在不同地域的IDC中部署LDC单元,并且每个LDC单元都是“活”的,是真正承接线上真实业务流量的,在发生故障时,可以进行LDC单元之间的快速切换。异地多活单元化架构解决了以下四个关键问题:
-
由于尽量减少了跨单元交互和使用异步化,使得异地部署成为可能。整个系统的水平可伸缩性大大提高,不再依赖同城IDC;
-
可以实现N+1的异地灾备策略,大大缩减灾备成本,同时确保灾备设施真实可用;
-
整个系统已无单点存在,大大提升了整体的高可用性;同城和异地部署的多个单元可用作互备的容灾设施,通过运维管控平台进行快速切换,有机会实现100%的持续可用率;
-
该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点,整体系统的可管控能力得到很大提升。基于该架构,线上压测、流量管控、灰度发布等以前难以实现的运维管控模式,现在能够十分轻松地实现。