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

　　2018年下半年，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：理想状态下的老旧机房服务迁移示意图