UCloud首尔机房整体热迁移是这样炼成的

  • 时间:
  • 浏览:0
  • 来源:5分彩平台-5分彩网投平台_5分彩投注平台

作者:UCloud 赵新宇

2018 年下5天,UCloud首尔数据中心因內部意味着着无法继续提供服务,还要在很短时间内将机房删改迁走。为了不影响用户现网业务,大伙儿放弃了离线迁移方案,取舍了非常有挑战的机房整体热迁移。经过 5 个月的多部门媒体公司合作 ,终于完成了既定目标,在用户无感知下,将所有业务删改迁移到同样处于首尔的新机房内。

本文将详述你你这个 大项目中最有难度的工作之一:公共组件与核心管理模块迁移的方案设计和实践历程。

计划

整个项目划分为六个大阶段:准备阶段、新机房建设、新旧迁移和旧机房裁撤下线。正如一位同事的打比方,机房的热迁移,相当于把百公里高速行驶高铁上的用户迁移到另百公里高速行驶的高铁上,高铁是大伙儿的机房,高铁上的用户是大伙儿的业务。要让迁移可行还要两辆高铁相对静止,有一六个最好的办法是把两辆高铁变成百公里,可以不可以 两者强度就一致了。UCloud机房热迁移采用类式方案,把有一六个机房在逻辑上变成有一六个机房。为此,上层的业务逻辑要在新老机房间无缝迁移,下面的管理系统也要统一成一套。

其中,大伙儿SRE和应用运维团队主要负责以下几个工作:1)机房核心ZooKeeper服务的扩缩容服务;2)核心数据库上边层udatabase服务的部署和扩容;3)大部分管理服务的部署和迁移;4)核心数据库的部署和迁移。以上涉及到前期规划、方案设计、项目实施、稳定性保证、变更校验等所有方面。

挑战

大伙儿刚接到机房整体热迁移需求时,实在其他头疼,首尔机房属于较早期部署的机房之一,相关的技术架构比较老旧。而核心数据库、核心配置服务(ZooKeeper)、核心数据库上边层(udatabase)等几个服务都是比较重要的基础组件,老旧架构意味着着会意味着着基础层面的变动处于错综复杂的大范围异常,从而影响到存量用户的日常使用。

幸好SRE团队在过去一年里,针对各种服务的资源数据进行了全面的梳理,大伙儿开发了一套集群资源管理系统(Mafia-RMS) ,该系统通过动态服务发现、静态注册等多种手段,对存量和增量的服务资源进行了整理,每有一六个机房有有哪些服务和集群,某个集群有有哪些服务器、每有一六个实例的端口/情况报告/配置等信息,都记录到了大伙儿的资源管理系统中,如下图所示:

图1: UCloud SRE资源管理系统-集群管理功能

通过SRE资源管理系统,还还要清楚地知道首尔机房存量內部服务的集群信息、每个实例的情况报告。大伙儿基于SRE资源系统还构建了基于Prometheus的SRE监控体系,通过上图右侧Monitor按钮就还还要跳转到监控页面,获取整个业务的实时运行情况报告。

有了有有哪些资源数据完后 ,剩下的要是考虑为何会么会进行有有哪些服务的扩容和迁移工作。

ZooKeeper服务的扩缩容

首先是內部服务注册中心ZooKeeper的扩缩容。

UCloud內部大规模使用ZooKeeper作为內部服务注册和服务发现中心,大部分服务的互访都是通过使用ZooKeeper获取服务注册地址,UCloud內部使用较多的wiwo框架(C++) 和 uframework (Golang) 都是基于主动情况报告机定时将我本人的Endpoint信息注册到ZooKeeper中,相同Endpoint前缀的服务属于同有一六个集群,有然后对于其他服务的扩容,新节点使用相同的Endpoint前缀即可。wiwo和uframework有一六个框架的客户端具备了解析ZooKeeper配置的能力,还还要通过对Endpoint的解析获取到真实的IP和端口信息。有然后通过客户端负载均衡的最好的办法,将请求发送到真实的业务服务实例上去,从而完成服务间的相互调用。如下图所示:

图2:UCloud 首尔机房部署调用及服务注册/发现路径图

首尔老机房的ZooKeeper集群是有一六个具有 3 个节点的普通集群(当时规模相对较小, 3 个节点足够)。 然而首尔新机房的规模要大不多不多,有然后新机房ZooKeeper的集群规模也要扩充,经过大伙儿的评估,将新机房的ZooKeeper集群扩充到 5 个节点,基本上还还要满足所需。

实在,有一六个理想的迁移架构应该是如图 3 所示,整个新机房使用和老机房相同的技术架构(架构和版本统一),新架构删改独立部署,与老机房不可以否不可以 数据交互工作,而用户的业务服务(如UHost/UDB/EIP/VPC等)通过三种最好的办法平滑的实现控制和管理面的迁移,以及物理位置的迁移工作。

图3:理想情况报告下的老旧机房服务迁移示意图

有然后理想情况报告在现实中无法达到,內部架构和代码逻辑的限制,意味着着业务实例无法平滑实现逻辑和控制层面的迁移,更何况物理层面的迁移。新部署的管理服务还要和老机房的管理服务进行通信,有然后,大伙儿调整了新机房服务的部署架构,并适配实际情况报告分别使用三种部署模式,如图 4 和图 5 所示:

图4: 同集群扩容模式的跨机房服务部署

图5: 新建集群灰度迁移模式的跨机房服务部署

无论是图 4 的同集群扩容模式,还是图 5 的新建集群灰度迁移模式,在ZooKeeper层面还要让新旧机房的ZooKeeper集群处于一体的情况报告,还要有一六个集群的数据一致、实时同步。有然后在ZooKeeper的技术层面,还要将这有一六个集群变成有一六个集群,将原有的 3 节点的ZooKeeper集群,经过异地机房扩容的最好的办法扩充到 8 个节点( 1 个leader, 7 个follower),可以不可以 你你这个 模式下数据才不用可以保持一致性和实时性。

而对于新机房新部署的还要注册的服务来说,大伙儿的配置文件中对于ZooKeeper地址的配置,却都是新建的 8 个IP的列表,要是只配置新机房 5 个IP的列表。从前新老机房的后端服务使用同一套ZooKeeper,有然后配置的却是不同的IP,从前做的目的,是为了后续老机房下线裁撤时,所有新机房的服务不还要意味着着ZooKeeper集群的缩容而重启更新配置,只要将集群中老机房所在的 3 个节点下线,剩余 5 个节点的配置更新重新选主即可。

有然后在ZooKeeper的机房扩容方案上,大伙儿采用了先同集群扩容后拆分的模式。ZooKeeper的扩容是整个机房扩建的第一步,后续所有的服务都是依托于该操作新建的 5 个节点的ZooKeeper配置;而ZooKeeper集群的缩容是最后的操作,待所有的服务都扩容完成,所有业务实例迁移完成完后 ,将ZooKeeper集群进行缩容重新选主,从前即可完成整个机房的裁撤。

数据库上边层udatabase的迁移

接下来是数据库上边层udatabase的迁移工作。

图 4 和图 5 三种模式对于ZooKeeper的防止最好的办法是相同的,不同点在于后端对于內部管理和控制面服务的扩容迁移最好的办法。udatabase迁移使用图 4 模式,你你这个 模式下相当于在原有的集群进行异地机房扩容,扩容的新实例使用和原有集群相同的Endpoint前缀,也要是说它们是属于同有一六个集群,当服务启动后,新扩容的实例的情况报告会与原有集群的实例相同,框架(wiwo或uframework)层会通过客户端最好的办法从ZooKeeper中发现到该集群节点的变化(新增),同时使用三种负载均衡算法将请求流量路由到新的节点上。从前属于同有一六个集群,但却处于有一六个地址位置的实例都是部分流量,而进行缩容的最好的办法要是直接将老机房同集群的服务下线即可,从前客户端就会将所有该集群的流量都转发到新机房扩容的节点上,从而完成平滑的服务扩容。udatabase通过从前的最好的办法完成了集群的迁移过程。

新建集群灰度迁移模式

实在图 4 模式对于大部分服务来说都是可行的,但为有哪些还突然出现了图 5 所示的新建集群灰度迁移模式呢?意味着着其他场景下图 4 会有一定的不可控性。只要新建的实例(如图 4 中Service A Instance 2)处于软件稳定性和可靠性的问题图片,比如配置异常、软件版本异常、网络异常,意味着着意味着着路由到新节点的请求突然出现问题图片,会直接影响在线业务,影响的规模由扩容的节点占集群总节点的比例决定,像大伙儿你你这个 1: 1 的扩容最好的办法,意味着着服务有问题图片意味着着60 %的请求就直接异常了。udatabase使用图 4 方案,是意味着着其代码的稳定性比较高,功能和配置比较简单,主要依托于其高性能的转发能力。

而对于其他功能逻辑都比较错综复杂的业务来说(如ULB/CNAT),就使用了更稳妥的图 5 模式,意味着着业务层面支持跨集群迁移,有然后还还要新建有一六个全新的无业务流量的集群,该集群在ZooKeeper中的Endpoint路径前缀和原有的集群不相同,使用有一六个全新的路径,有然后在业务层面,通过迁移平台或工具,将后端服务或实例按需迁移,整个过程可控,突然出现问题图片立刻回滚,是最安全的迁移方案。大伙儿通用的灰度迁移平台SRE-Migrate如图 6 所示。

图6 UCloud內部通用业务迁移系统SRE-Migrate

机房部署平台SRE-Asteroid

UCloud产品线和产品名下服务数量繁多,无论是图 4 还是图 5 的方案,都还要大量的服务部署工作。SRE团队在 2018 年中推进的机房部署优化项目,意在防止UCloud新机房建设(国内及海外数据中心、专有云、私有云等)交付时间长和人力成本巨大的问题图片, 2018 年底该项目成功产品化落地,覆盖主机、网络等核心业务近百余服务的部署管理,防止了配置管理、部署规范、软件版本等一系列问题图片。首尔机房迁移也正是利用了你你这个 成果,才不用可以在很短的时间内完成近百个新集群的部署或扩容工作,图 7 所示要是大伙儿的新机房部署平台 SRE-Asteroid。

图7 UCloud內部机房部署平台SRE-Asteroid

核心数据库的部署和迁移

最后,是核心数据库层面的部署和迁移工作怎样才能进行。UCloud內部服务所使用的数据库服务为MySQL, 內部MySQL集群采用物理机/虚拟机在管理网络内自行建设,以有一六个主库、有一六个高可用从库、有一六个只读从库和有一六个备份库的最好的办法部署,使用MHA+VIP的最好的办法防止主库的高可用问题图片,使用BGP/ECMP+VIP的最好的办法防止从库的负载均衡和高可用问题图片,大体的架构如图 8 所示:

图8 UCloud內部MySQL服务架构图

首尔新老机房使用的內部MySQL数据库集群的架构跟上图类式,为了进行新老机房的集群切换,大伙儿设计了如下的方案,如图 9 所示:

图9 首尔集群內部数据库集群迁移示意图

整体来说,为了保证核心数据库集群不用可以稳定完成迁移工作,大伙儿抛下了双主库、双写的切换方案,防止意味着着网络或其他因素意味着着新老集群的数据不一致、同步异常等问题图片。大伙儿采用了最简单的防止方案,在业务低峰期停止Console服务,直接修改数据库上边层配置切换的方案。

在部署阶段,大伙儿在首尔新机房部署了相同高可用架构的MySQL集群,老机房的数据库逻辑备份导入,将新老机房的集群做成级联模式(图 9 中绿色虚线),新机房的主库作为老机房的从库,通过MySQL异步同步的最好的办法(binlog)进行数据同步。大伙儿使用pt-table-checksum工具,定期对有一六个集群的数据一致性进行校验,以保证新老机房的数据删改一致。与此同时使用內部开发的拓扑分析工具,将所有调用老集群数据库主从库的业务情况报告确认清楚(主要是有哪些udatabase集群)。

部署完成后,数据一致性和实时性通过级联得到保障,udatabase仍然访问老机房的MySQL主库的VIP(图 9 深紫色 虚线),此时不可以否不可以 业务通过直连的最好的办法写入新机房的主库(为保证数据的一致性,新机房的主库暂时设置成只读模式)。

在取舍迁移时间和迁移方案完后 ,在某个业务低峰期的时间点,公告用户后,首尔机房整个console的操作停止一段时间(期间首尔机房的API请求意味着着会失败),在取舍流量很低的前提下,通过修改数据库上边层(udatabase cluster)中数据库主从库VIP的配置,将业务从老机房MySQL集群切换到新机房MySQL集群,此时该业务所有的请求都是流入到新集群(图 9 红色虚线)。为了防止老集群仍然有业务写入或读取,大伙儿将老集群主库设置为只读,有然后继续通过tcpdump抓包分析老集群上意味着着处于的请求并手动防止,最终保证所有业务都使用新的MySQL集群。

意味着着还要对主机、网络、存储和监控等几个业务都进行集群切换,为保证不互相影响,使用逐个集群防止的最好的办法,整体切换加检测的时间耗时近 1 个小时。

在整个机房切换的过程中,可以不可以 数据库集群是有情况报告的业务,有然后重要性和危险性也比较高,该服务切换完成后,最重要的有一六个环节也签署完成,剩下的业务层面(UHost/UDB/EIP等)的迁移工作由各个业务团队自行完成即可。

收尾

最终所有业务实例完成迁移后,理论上就还还要完成本次机房迁移工作了,不过还是要对老机房仍然运行的实例进行流量监测,确认可以不可以 流量后进行下线,停止服务。最后对老机房的ZooKeeper集群(老机房的 3 个ZooKeeper节点)进行请求监测和连接监测,确认可以不可以 本机房以及新机房发来的请求(排除ZooKeeper集群自主同步的情况报告),在完成确认后,进行最后的ZooKeeper集群变更,将整个集群( 8 个节点)拆分成老机房( 3 个节点)和新机房( 5 个节点),老机房的集群直接停止服务,而新机房的新的ZooKeeper集群完成新的选主操作,确认同步正常和服务正常。

写在最后

经历了上文所述的一切操作后,整个首尔机房的迁移工作就完成了,整个项目历经 5 个月,其中大部分时间用于业务实例的迁移过程,主要是针对不同的用户要取舍不同的迁移策略和迁移时间;內部管理服务的迁移和部署所花费的时间还是比较少的。UCloud內部针对本次迁移的每有一六个步骤都制定了删改的方案规划,包括服务依赖分析、操作步骤、验证最好的办法、切换风险、回滚方案等,为了完成可以不可以 巨大的新机房热迁移工作,团队投入了充足的人力和时间。首尔新机房具有更好的建设规划、硬件配置和软件架构,不用可以为用户提供更好的服务,大伙儿相信你你这个 切都是很有价值的。

本文由站长之家用户投稿,未经站长之家同意,严禁转载。如广大用户大伙儿,发现稿件处于不实报道,欢迎读者反馈、纠正、举报问题图片(反馈入口)。

免责声明:本文为用户投稿的文章,站长之家发布此文仅为传递信息,不代表站长之家赞同其观点,不对对内容真实性负责,仅供用户参考之用,不构成任何投资、使用建议。请读者自行核实真实性,以及意味着着处于的风险,任何后果均由读者自行承担。