业务支撑系统云化基础架构设计.docVIP

业务支撑系统云化基础架构设计 　　一、概述 　　黑龙江移动早已在2010年，在业务支撑系统中引入服务器虚拟化技术，同时，将业务支撑系统逐步迁入云管理平台中进行管理。在传统的虚拟化方案中，云平台的高可用、稳定性主要由基础架构决定，如高可用、系统在线迁移、资源动态调度等机制，都依赖于特定厂商的特定解决方案。 　　虚拟化技术解决了传统的应用竖井架构所带来的资源利用率低等问题，但也又出现了新的瓶颈：在系统持续运行过程中，如何匹配计算资源与存储资源，减少集群内的资源碎片化，需要设计、运维部门进行持续优化与调整。 　　为解决上述问题，本文通过分析，提出了新的基础架构设计方案，谨供各?\营商在业务支撑系统云化演进过程中参考。 　　二、传统方案存在的问题 　　（一）基础架构竖井 　　业务支撑系统在实施虚拟化之前，各个子系统拥有单独计算、存储资源，是典型的竖井式架构，存在资源利用率低下的问题。 　　在虚拟化过程中，普遍使用了VMware（一种虚拟化软件产品）虚拟化集群，事实上，形成新的集群竖井：资源调度边界为虚拟化集群，集群间的计算资源、存储资源无法实现共享。如集群内可以计算资源比较富余，但由于外置存储容量不足，而无法加载新的应用实例（虚拟机），形成计算资源碎片。 　　（二）虚拟化高可用 　　在VMware虚拟化集群中，采用了高可用机制，需要昂贵的外置存储资源。当一个服务器节点出故障，如系统崩溃、或宕机时，虚拟机恢复需要长达几分钟之久，这意味着业务也会中断相应的时间。 　　（三）虚拟化调度 　　在VMware虚拟化集群中，当服务器资源紧张时，传统的动态资源调度机制会迁移虚拟机至空闲服务器，会引起短暂的网络流量增加，导致资源争用。在手工迁移虚拟机时，或动态资源调度触发的迁移操作，对于业务量较大，读写频繁的虚拟机，在切换时会有长达几十秒钟的挂起时间，直接影响业务系统终端用户的使用满意度。 　　三、业务云化对应用的要求 　　为解决基础架构层虚拟化环境现存弊端，需要在业务层进行云化。业务层云化过程中，需要对应用系统进行改造。 　　（一）分布式处理能力 　　在基础架构层虚拟化改造后，每个子系统的计算能力仍依赖于虚拟机的CPU（Central Process Unit）/内存配置，计算能力的提升需要进行纵向扩展。分布式计算为应用系统提供了水平扩展能力：通过运行多个应用实例（虚拟机、虚拟化容量、或物理机），并发处理业务需求。 　　（二）应用与数据分离 　　应用与数据分离的目的是实现应用实例的无状态化：对应用实例进行同质化改造，临时数据、持久化数据独立于应用实例进行保存，保持应用实例的最小化。 　　如业务处理过程中的会话数据，独立于W e b服务器、应用服务器，单独保存在Memcached、Redis等分布式缓存系统；应用系统、操作系统日志汇集于集中的日志服务器，进行归档与分析。 　　（三）资源动态弹性伸缩 　　在应用系统具备了分布式处理能力后，为提高资源利用率，引入资源弹性伸缩机制，根据应用对资源的需求进行动态匹配，实现系统动态扩容、闲置资源回收、隔离故障等功能。 　　（四）去厂家绑定化 　　由云管理平台Paas（Platform as a Service，平台即服务）组件实现弹性调度机制，自动控制应用实例的部署、启动、停止、删除。应用系统的健壮性不再依赖于虚拟化平台的高可用、动态资源调度等特性，从而减少因购买虚拟化平台所产生的高额许可费用。 　　四、基础架构设计 　　（一）基础架构层 　　业务云化应用架构部分由云管理平台Paas组件实现，主要有应用集群的定义、资源调度、弹性伸缩、健康监控、故障隔离等功能。为适应业务云化改造，本文提出Iaas（Infrastructure as a Service，基础架构即服务）层基础架构层设计方案。 　　1.高可用及资源调度 　　在云管理平台上，提供应用实例的弹性扩展与收缩能力，包括提供虚拟机、计算虚拟化容器、物理机的弹性扩展与收缩能力，在基础架构层，不再提供高可用设计，高可用及资源调度。 　　2.去集群化 　　构建虚拟化集群的目的，是为了在基础架层实现虚拟机的高可用转移、动态资源调度，上述功能已被云管理平台弹性资源调度代替，因此，基础架构层应不再做集群化配置，减化系统设计复杂度与运维工作量。 　　（二）计算资源架构 　　1.资源池化 　　在基础架构层，取代虚拟化集群的是计算资源池。系统分为物理机资源池、虚拟化资源池、容器资源池、大数据资源池四个在用资源池，同时，系统中配置一个空闲资源池。在每个在用资源池中，服务器独立运行，对于每个子业务，由云管理平台在应用层进行管理，将应用集群部署于在用资源池中。 　　2.资源池弹性调度 　　类似应用集群弹性调度，资