联想集团IT基于OpenStack的双活私有云建设
举报
菜鸟级攻城狮
发表于 2021/04/08 15:18:13
2021/04/08
【摘要】 联想集团IT基于OpenStack的双活私有云建设
背景介绍
本文来自联想集团基础架构和云服务（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，这样的物理线路长度，也可以提供作为数据实时同步时的低时延基础。
中心间的通讯是本次方案需要关注的重点。数据实时复制不但对时延有严苛的要求，对带宽和可靠性也是。为了避免出现“保障千千万，挖掘机一铲”的尴尬情况，ICS在两个数据中心间建立了两条互备的裸光纤，数据层使用光波复用（DWDM）技术提升带宽和裸纤的使用率。由此带来的性能数据非常可观，数据中心间带宽可达160GBps，在虚拟化层实测RTT<0.9ms。落盘数据和网络数据运行在不同波长的光波，以避免出现存储和网络互相抢占带宽的情况。
网络层双活
在网络建设层面，ICS的双活数据中心利用DCI做到大二层互通。这样的好处是虚拟机实例在数据中心间漂移时，其IP不会发生变更，进一步减少业务因基础设施层发生切换导致中断的场景。
单个数据中心内（无状态）的设备都是双多活工作模式，比如路由器、Spine-Leaf交换机、负载均衡器。在单台设备故障的情况下，网络的中断成本小到可以忽略不计。比较特殊的是硬件防火墙，其上保存了很多会话，单中心内的硬件防火墙是Active-Standby高可用集群。
同时，两个机房的公网出口是多线且相互独立的，在应对站点级故障时，通常使用两种方法，一种是成本较低的全局负载均衡器，需要应用做部署架构改造，当一侧站点发生故障时，负载均衡器会判断链路是否可用，将不可用的流量调度至另一侧站点；第二种则是路由收敛，在上线初期通常通过人工操作将故障站点的流量收敛至对侧，拥有完善的故障演练和经验后，成长为自动化操作。
存储层双活
存储的硬件层面，ICS使用联想凌拓的DE系列存储服务器搭建FC-SAN全闪集群，两中心存储服务器的规格和容量完全相同。上层使用存储虚拟化，对接OpenStack Cinder驱动。
前面提到，此次双活云在存储层的设计目标是实时复制，与异步复制不同的地方在于，同步复制要求在两端数据都落盘（或写入缓存层）后，IO才算是成功。由此可能会带来IOPS性能问题，但链路层与网络层的性能与高可用支撑，可以最大化减轻此种方式带来的影响。
在满足读写性能的同时，存储可靠性高低带来的影响，可谓是核弹级别。近些年来，因存储集群宕机导致的大规模区域性故障屡见不鲜，影响范围广，时间长。ICS采用的存储方案，则是最大可应对站点级故障而不中断存储服务。写操作在两个站点都写入后才算成功，所以RPO=0。读操作则是在本地站点进行，以提升性能。
此种方案的另一个特点是，即使当一侧站点完全不可用时，面向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、机器学习，在商务层面也更乐意将方案和产品对外输出，帮助行业和客户专注交付自身业务，以更加敏捷和低成本的方式创造更多价值。
推荐
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）