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

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

作者:UCloud赵欣瑜

2018年下半年，UCloud首尔数据中心因外部原因无法继续提供服务，需要在短时间内将所有机房搬离。为了不影响用户现网业务，我们放弃了离线迁移方案，选择了具有挑战性的机房整体热迁移。经过5个月的多部门协作，最终实现了既定目标，在用户毫无察觉的情况下，将所有业务完全迁移到同样位于首尔的新机房。

本文将详细介绍这个大项目中最困难的任务之一:通用组件和核心管理模块迁移的方案设计和实践过程。

计划

整个项目分为四个阶段:准备阶段、新机房建设、新旧迁移、旧机房裁撤和下线。就像有同事打了个比方，机房的热迁移相当于用户从一条高速高铁迁移到另一条。高铁是我们的机房，高铁上的用户是我们的事。为了使迁移可行，两列高速列车需要相对静止。一个办法是把两列高铁改成一列，这样两列的速度就一样了。UCloud机房热迁移采用类似的方案，逻辑上是把两个机房变成一个机房。为此，上层的业务逻辑要在新老机房无缝迁移，下面的管理系统要统一成一套。

其中，我们的SRE和应用运维团队主要负责以下工作:1)机房核心ZooKeeper服务的扩展和收缩；2)核心数据库中间层udatabase服务的部署和扩展；3)大多数管理服务的部署和迁移；4)核心数据库的部署和迁移。以上涉及前期规划、方案设计、项目实施、稳定性保证、变更验证等各个方面。

挑战

当我们第一次收到机房的整体热迁移需求时，我们有些头疼。首尔机房是较早部署的机房之一，相关的技术架构也比较陈旧。核心数据库、核心配置服务(ZooKeeper)、核心数据库中间层(udatabase)等服务都是重要的基础组件，旧架构可能会因为基础层的变化而出现复杂、大规模的异常，从而影响现有用户的日常使用。

幸运的是，SRE团队在过去的一年里全面梳理了各种服务的资源数据，我们开发了一个集群资源管理系统(Mafia-RMS)。系统通过动态服务发现、静态注册等手段，对存量和增量服务资源进行了梳理，记录了每个机房的服务和集群、集群中的服务器、每个实例的端口/状态/配置等信息。

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

通过SRE资源管理系统，我们可以清楚地知道首尔机房内部服务的集群信息和每个实例的状态。我们还在SRE资源系统的基础上建立了一个基于Prometheus的SRE监测系统。可以通过上图右侧的监控按钮跳转到监控页面，获取整个业务的实时运行状态。

有了这些资源数据，剩下的就是考虑如何扩展和迁移这些服务了。

动物园管理员服务的扩展和收缩

首先是内部服务注册中心ZooKeeper的扩张和收缩。

UCloud大规模使用ZooKeeper作为内部服务注册和服务发现中心。大多数服务访问都是通过使用ZooKeeper来获取服务注册地址。UCloud中广泛使用的Wiwoframework(C++)和uframework(Golang)都是基于主动状态机定期在ZooKeeper中注册自己的端点信息。具有相同端点前缀的服务属于同一个集群，因此对于某些服务的扩展，新节点只能使用相同的端点前缀。wiwo和uframework框架的客户端具有解析ZooKeeper配置的能力，通过解析端点可以获得真实的IP和端口信息。然后通过客户端负载均衡的方式，将请求发送到真实的业务服务实例，从而完成服务之间的相互调用。如下图所示:

图2:UCloud首尔机房部署呼叫和服务注册/发现路径图

首尔老机房的ZooKeeper集群是一个普通的集群，有三个节点(当时规模比较小，三个节点就够了)。但是首尔的新机房规模要大很多，所以新机房的ZooKeeper集群规模也要扩大。经过我们的评测，新机房的ZooKeeper集群已经扩展到5个节点，基本可以满足要求。

事实上，理想的迁移架构应该如图3所示。整个新机房使用与旧机房相同的技术架构(统一架构和版本)。新架构完全独立部署，和老机房没有数据交互。用户的商业服务(如UHost/UDB/EIP/VPC等。)能够以某种方式平滑地实现控制和管理方面以及物理位置的迁移。

图3:理想状态下旧机房服务迁移示意图

但是，理想状态在现实中是达不到的。由于内部架构和代码逻辑的限制，业务实例无法顺利实现逻辑和控制层的迁移，更不用说物理层的迁移了。新部署的管理服务需要与旧机房的管理服务进行通信。因此，我们调整了新机房服务的部署架构，适应实际情况分别使用两种部署模式，如图4和图5所示:

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

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

无论是图4所示的相同集群扩展模式，还是图5所示的新集群灰度迁移模式，新老机房的ZooKeeper集群都必须在ZooKeeper级别处于集成状态，两个集群的数据需要保持一致并实时同步。所以在ZooKeeper的技术层面，需要把这两个集群变成一个集群，通过异地扩展机房，把原来的3节点ZooKeeper集群扩展到8个节点(1个首领，7个随从)。只有在这种模式下，数据才能保持一致和实时。

但是对于新机房新部署的需要注册的服务，他们配置文件中ZooKeeper地址的配置并不是新创建的8个IP的列表，而是新机房只有5个IP的列表。这样一来，新老机房的后端服务使用的是同一套ZooKeeper，只是配置了不同的IP。这样做的目的是，当旧机房离线或被废除时，所有新的机房服务都不需要因为ZooKeeper集群的收缩而重新启动和更新配置，只要集群中旧机房的三个节点离线，其余五个节点的配置就可以更新和重新选择。

所以在ZooKeeper的机房扩展方案中，我们采用了先扩展同一个集群，再拆分的模式。ZooKeeper的扩展是整个机房扩展的第一步，后续的所有服务都将依赖于该 *** 作创建的五个新节点的ZooKeeper配置；ZooKeeper集群的收缩是最后的 *** 作。在所有服务被扩展，所有业务实例被迁移后，ZooKeeper集群将被收缩并重新选择，这样整个机房都可以被废除。

数据库中间层数据库的迁移

下一步是数据库中间层udatabase的迁移。

图4和图5所示的两种模式以相同的方式处理ZooKeeper，但区别在于后端内部管理和控制平面服务的扩展和迁移。Udatabase迁移使用图4所示的模式，相当于在原集群的不同地方扩展机房。扩展的新实例使用与原始集群相同的端点前缀，也就是说，它们属于同一个集群。当服务启动后，新扩展的实例将与原来的集群实例具有相同的状态，框架(wiwo或uframework)层将通过客户端从ZooKeeper中发现集群节点的变化(增加)，同时使用某种负载均衡算法。这样，属于同一个集群，但是位于两个地址的实例都有部分流量，降低容量的方法就是直接将旧机房和集群的服务下线，这样客户端就会将集群的所有流量转发到新机房扩容的节点，从而完成平滑的服务扩容。Udatabase以这种方式完成集群的迁移过程。

创建新的群集灰度迁移模式

实际上，图4所示的模式对于大多数服务都是可行的，但是为什么会出现图5所示的新的集群灰度迁移模式呢？因为在某些场景下，图4会不可控。如果新建的实例(比如图4中的服务A实例2)出现软件稳定性和可靠性问题，比如配置异常、软件版本异常、网络异常，可能会导致路由到新节点的请求出现问题，直接影响在线业务。影响的程度由集群中扩展节点占总节点的比例决定。对于我们1:1的扩展模式，如果出现服务问题，50%的请求可能直接异常。Udatabase使用图4所示的方案，是因为它的代码稳定性比较高，功能和配置比较简单，主要依赖于它的高性能转发能力。

然而，对于一些具有复杂功能逻辑的企业(如ULB/CNAT)，使用更安全的图5模型。由于业务层支持跨集群迁移，可以构建一个全新的没有业务流量的集群。ZooKeeper中这个集群的端点路径的前缀和原来的集群不同，所以使用了一个全新的路径。然后，在业务层面，可以通过迁移平台或工具按需迁移后端服务或实例。整个过程是可控的。我们的通用灰度迁移平台SRE迁移如图6所示。

图6内部通用业务迁移系统SRE-在ucloud中迁移

机房部署平台SRE-小行星

UCloud产品线和产品名称里有很多服务。无论是图4还是图5中的方案，都需要大量的服务部署工作。SRE团队在2018年年中推动的机房部署优化项目，意在解决UCloud新机房建设(国内和海外数据中心、专有云、私有云等)中交付时间长、人力成本巨大等问题。).2018年底，项目成功商用，覆盖主机、网络等核心业务近百项服务的部署管理，解决了配置管理、部署规范、软件版本等一系列问题。首尔机房迁移也利用这一成果在短时间内完成了近100个新集群的部署或扩展。图7显示了我们新的机房部署平台SRE-小行星。

图7ucloud内部机房部署平台SRE-小行星

核心数据库的部署和迁移

最后，如何部署和迁移核心数据库。UCloud内部服务使用的数据库服务是MySQL。内部MySQL集群由管理网络中的物理机/虚拟机构建，以一个主库、一个高可用从库、两个只读从库和一个备份库的形式部署。MHA+VIP用于解决主库的高可用问题，BGP/ECMP+VIP用于解决从库的负载均衡和高可用问题。一般架构如图8所示:

图8UCloud内部MySQL服务架构图

首尔新老机房使用的内部MySQL数据库集群的架构类似于上图。为了在新旧机房之间进行切换，我们设计了如下方案，如图9所示:

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

综合来看，为了保证核心数据库集群能够稳定地完成迁移工作，我们放弃了双主数据库双写的切换方案，以防止网络或其他因素造成的新旧集群之间的数据不一致和不正常同步。我们采用了最简单的方案，在业务低峰期停止控制台服务，直接修改数据库中间层的配置切换方案。

在部署阶段，我们在首尔的新机房部署了同样高可用架构的MySQL集群，导入旧机房数据库的逻辑备份，将新旧机房的集群做成级联模式(图9绿色虚线)。新机房的主库作为旧机房的从库，数据同步采用MySQL异步同步(binlog)。我们使用pt-table-checksum工具定期检查两个集群的数据一致性，确保新老机房的数据完全一致。同时利用内部开发的拓扑分析工具，明确确认所有调用旧集群数据库主从数据库的业务情况(主要是哪些udatabase集群)。

部署完成后，通过级联保证数据一致性和实时性。udatabase仍然在老机房访问MySQL主库的VIP(图9中蓝色虚线)。此时没有业务通过直连写入新机房主库(为保证数据一致性，新机房主库暂时设置为只读模式)。

迁移时间和迁移方案确定后，在某个业务高峰期宣布用户后，首尔机房整个控制台的运行会停止一段时间(在此期间首尔机房的API请求可能会失败)。在低流量的前提下，通过修改udatabase集群中数据库主从数据库VIP的配置，将业务从旧机房的MySQL集群切换到新机房的MySQL集群。此时，该业务的所有请求都会流入新集群(图9中的红色虚线为了防止旧集群仍然有业务写入或读取，我们将旧集群的主库设置为只读，然后通过tcpdump继续分析旧集群上可能的请求并手动处理，最终确保所有业务都使用新的MySQL集群。

由于主机、网络、存储、监控等几项业务需要分簇进行切换，为了保证互不影响，采用了逐簇处理，整体切换和检测时间将近一个小时。

在整个机房切换过程中，只有数据库集群是有状态业务，所以其重要性和危险性都比较高。服务切换完成后，宣布最重要的环节，剩下的业务级别(UHost/UDB/EIP等。)可以由每个业务团队进行迁移。

关闭

所有业务实例最终迁移完成后，理论上就可以完成这个机房的迁移了。但是仍然需要监控旧机房中仍在运行的实例的流量，在确认没有流量后再注销停止服务。最后，监控旧机房的ZooKeeper集群(旧机房的三个ZooKeeper节点)的请求和连接，确认没有来自本机房和新机房的请求(不包括ZooKeeper集群的自主同步)。确认完成后，进行最终的ZooKeeper集群变更，整个集群(八个节点)分为旧机房(三个节点)和新机房(五个节点)。旧机房的集群直接停止服务，而新机房的新ZooKeeper集群完成新主选择 *** 作以确认正常同步和服务。

写在最后

完成上述所有 *** 作后，整个首尔机房的迁移就完成了。整个项目历时5个月，大部分时间用于业务实例的迁移，主要是针对不同的用户确定不同的迁移策略和迁移时间；内部管理服务的迁移和部署仍然需要更少的时间。UCloud对此次迁移的每一步都做了详细的规划，包括服务依赖分析、 *** 作步骤、验证方法、切换风险、回滚计划等。为了完成如此巨大的新机房热迁移，团队投入了充足的人力和时间。首尔新机房有更好的建设规划、硬件配置和软件架构，可以为用户提供更好的服务。我们认为所有这些都是有价值的。