vlambda博客
学习文章列表

联想集团IT基于OpenStack的双活私有云建设

云技术
传播新技术,关注云计算、雾计算、边缘计算、量子计算、物联网、5G、人工智能、大数据、虚拟化、安全、区块链、DevOps、存储、SDN、职场、招聘等领域,分享资讯、经验、技术、坚持干货。
918篇原创内容
Official Account


背景介绍

本文来自联想集团基础架构和云服务(Infrastructure and Cloud Services)部门,隶属于联想IT组织,以下简称ICS。

随着公司业务对连续性和数据可靠性的要求越来越高,ICS在疫情肆虐的2020年成功上线基于OpenStack的双活私有云,实现了多个应用的100%可用性。本文将从数据中心、网络、存储、计算、服务5个层面展开,结合基础设施建设与应用改造,介绍如何打造RTO(Recovery Time Objective)≈0,RPO(Recovery Point Objective)=0的私有云。
 

站点双活

作为云计算的载体,构建双活云的第一步需要进行合适的数据中心选址。存在于网络上的很多资料中,通常会写到两地三中心中的“同城双中心”距离在100KM以内。其含义是将同城双中心作为生产数据中心-灾备数据中心的模式来使用,而联想私有云需要数据在双中心间实时复制,以做到真正的“双活(Active-Active)”,即便如此以来会在性能上做出一定牺牲。

ICS选择了同城直线距离在25KM左右的两个数据中心,分别位于北京两个行政区,经测算双中心间的线路距离为55KM,这样的物理线路长度,也可以提供作为数据实时同步时的低时延基础。

联想集团IT基于OpenStack的双活私有云建设


中心间的通讯是本次方案需要关注的重点。数据实时复制不但对时延有严苛的要求,对带宽和可靠性也是。为了避免出现“保障千千万,挖掘机一铲”的尴尬情况,ICS在两个数据中心间建立了两条互备的裸光纤,数据层使用光波复用(DWDM)技术提升带宽和裸纤的使用率。由此带来的性能数据非常可观,数据中心间带宽可达160GBps,在虚拟化层实测RTT<0.9ms。落盘数据和网络数据运行在不同波长的光波,以避免出现存储和网络互相抢占带宽的情况。
 

网络层双活

在网络建设层面,ICS的双活数据中心利用DCI做到大二层互通。这样的好处是虚拟机实例在数据中心间漂移时,其IP不会发生变更,进一步减少业务因基础设施层发生切换导致中断的场景。
 
单个数据中心内(无状态)的设备都是双多活工作模式,比如路由器、Spine-Leaf交换机、负载均衡器。在单台设备故障的情况下,网络的中断成本小到可以忽略不计。比较特殊的是硬件防火墙,其上保存了很多会话,单中心内的硬件防火墙是Active-Standby高可用集群。
 
同时,两个机房的公网出口是多线且相互独立的,在应对站点级故障时,通常使用两种方法,一种是成本较低的全局负载均衡器,需要应用做部署架构改造,当一侧站点发生故障时,负载均衡器会判断链路是否可用,将不可用的流量调度至另一侧站点;第二种则是路由收敛,在上线初期通常通过人工操作将故障站点的流量收敛至对侧,拥有完善的故障演练和经验后,成长为自动化操作。


存储层双活

存储的硬件层面,ICS使用联想凌拓的DE系列存储服务器搭建FC-SAN全闪集群,两中心存储服务器的规格和容量完全相同。上层使用存储虚拟化,对接OpenStack Cinder驱动。
 
前面提到,此次双活云在存储层的设计目标是实时复制,与异步复制不同的地方在于,同步复制要求在两端数据都落盘(或写入缓存层)后,IO才算是成功。由此可能会带来IOPS性能问题,但链路层与网络层的性能与高可用支撑,可以最大化减轻此种方式带来的影响。
 
在满足读写性能的同时,存储可靠性高低带来的影响,可谓是核弹级别。近些年来,因存储集群宕机导致的大规模区域性故障屡见不鲜,影响范围广,时间长。ICS采用的存储方案,则是最大可应对站点级故障而不中断存储服务。写操作在两个站点都写入后才算成功,所以RPO=0。读操作则是在本地站点进行,以提升性能。


联想集团IT基于OpenStack的双活私有云建设


此种方案的另一个特点是,即使当一侧站点完全不可用时,面向OpenStack计算实例的LUN(Logical UnitNumber)ID不会发生变更。由此带来的好处是,运维端可以在用户无任何感知的情况下,将其计算实例漂移至对侧站点,且单就存储层来讲,性能不会产生任何影响。


计算层双活

OpenStack项目诞生至今已有十余年,截止2021年初,已有22个大版本(目前最新为Victoria)发布。覆盖了网络、虚拟化、OS、存储等多个方面,并有大量用于生产实践的案例。
 
ICS使用集团自有的Think System SR系列高性能服务器与OpenStack作为基底搭建私有云计算平台。与常规OpenStack的使用方式不尽相同,基于二层互通、网络层和存储层的特性,计算虚拟化层可将资源看做同一个机房,以避免多OpenStack集群和多套组件协同工作的复杂性。
 
方案将OpenStack控制节点宿主机分布于两个站点的不同机柜、不同宿主机,在宿主机集群上,使用虚拟机挂载“双活卷”部署OpenStack服务,以应对站点故障。
 
部署方面使用社区的Kolla组件容器化部署OpenStack服务。OpenStack中的无状态服务,例如nova-api、nova-scheduler、glance-api等,服务的请求之间没有依赖关系,是完全独立的。对于此类服务,采取冗余实例KeepAlive+HAProxy的方式做到双多活。而对于有状态的服务,例如MariaDB和RabbitMQ,则分别采用多主Galera Cluster和RabbitMQ原生集群方案做高可用。
 
严格意义上计算实例的双多活,是以VMWare Fault Tolerance为代表的“镜像实例”,简单来说,这种方式的实现原理是通过实时或准实时的指令复制,使两个计算实例处于相同的状态,当容错发生时,“影子实例”立刻顶替而上。这种方案的好处是可以使应用程序实现零停机、零数据丢失,消除传统硬件或软件集群方案的复杂性,而对计算资源的成本则是成倍增加。ICS并未采用此种方式,而是围绕OpenStack社区和监控数据,做了大量的开发以保证虚拟机集群的可用性。
 
社区版本的服务器组(Server Group)的实现,只能将新申请的服务器加入已有的服务器组,已有实例则无法添加(这会破坏调度规则)。ICS自研了高可用服务器组引擎,使得任意虚拟机可加入已有或新建的服务器组,对于原有实例已经通过nova-scheduler完成的调度,用户可设置开关是否重新进行调度以满足亲和性规则,或在窗口时间进行亲和性巡检。从宿主机、机柜、站点等多个粒度进行高可用调度。
 
其次,ICS自研了Auto-Failover引擎,从网络、存储、宿主机等多个层面来判定故障发生,当判定故障发生时,会将实例疏散至指定的failover可用域。以96核1.5T规格的计算节点和2倍超分比为例,从分析监控数据、判定故障到整个宿主机节点的疏散可在分钟级完成。
 
在此基础上,ICS利用机器学习分析宿主机的能耗、温度、湿度等多个层面的数据,来预判宿主机故障的发生,提前将“即将发生故障”的宿主机上的实例进行热迁移,以此为切入点进入到AIOps时代。
 



总体来讲,从上层实现双多活,比从底层实现的成本更低,上层方案的产出物也更具普适性。毕竟还有很多系统的故障是来自于代码的bug和未覆盖的异常操作。此时底层实现高可用的方式也会将应用程序产生的“错误的指令”复制到“影子实例”上。


服务层双活

ICS部门在基础设施层面做到链路、网络、存储和计算多个层面的双活与高可用。但对于上层的应用开发人员来讲,想要做到从下至上的最佳实践还有一定距离。
 
以负载均衡服务为例,应用程序可以以分布式集群的形式部署在两个数据中心,集群复用上一节提到的计算实例亲和性规则。ICS在全球部署了多点全局负载均衡服务,当用户发起请求时,会自动判断健康的、负载最低的、路径最优的点进行响应。内部同样有服务器负载均衡服务,以确保更高的压力承载。
 
其实不止于负载均衡服务,ICS结合集团业务属性自研私有云产品与解决方案矩阵。例如,用户可以自服务的形式申请数据库集群,当这些集群被部署在双活私有云环境时,可按照亲和性规则智能调度数据库实例;用户申请MQ时,可交付MQ租户、独立集群、联邦等多种形式,而无需自行申请计算实例部署应用集群。这些服务目录仍在快速的扩张,以达到快速交付高可用应用的目的。
 
底层基础设施的高可用设计方案,同样适用于部署在物理机或虚拟机之上的Kubernetes集群,结合OpenStack Cinder也可以做到有状态服务的双多活。至此,方案已经提供从底层基础设施方案、私有云平台、虚拟机、容器到上层应用高可用集群的端到端方案。
 

结语

以上是ICS基于OpenStack搭建的私有云平台,从底层设计实施到上层软件集群的交付,达到的目的和初衷是一致的。在整个云计算平台设计和实施的过程中,技术和方案细节上的复杂程度远非文中所述如此轻松,但就像大家说的——你必须很努力,才能看起来毫不费力。不同公司的IT都在积极拥抱服务转型,联想也不例外,从技术层面拥抱潮流做出实践,如IoT、Serverless、AI、机器学习,在商务层面也更乐意将方案和产品对外输出,帮助行业和客户专注交付自身业务,以更加敏捷和低成本的方式创造更多价值。

来源:OpenStack


↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读:




更多文章请关注


文章好看点这里[在看]👇