分享人：阿瑟   阿里云解决方案架构师

         何川   阿里云弹性计算高级产品经理

正文：本文从三方面来介绍服务器迁移的最佳实践，帮助大家更好地理解阿里云产品和解决方案。

Ÿ 最佳实践原理讲解

Ÿ 迁移工具SMC产品讲解

Ÿ 实践操作演示

一、最佳实践原理讲解

1）服务器迁移实践-场景描述

场景内适用将物理服务器、虚拟机以及其他云平台云主机，一站式地迁移到阿里云ECS，支持迁移主流Windows和Linux操作系统，包括从物理IDC环境迁移到ECS，从虚拟机环境或者云平台主机迁移到ECS。重点是服务器迁移涉及到数据库迁移，建议使用数据库迁移服务（DTS），对象存储的迁移使用对象存储在线迁移服务，那适用哪些客户呢？包括服务器规模在十台内（小微客户）、百台内（小型）、百台到千台级（中型客户）。

2）应用迁移常见路径

先概括一下中小企业上云的路径，前期需要做业务规划，包括从业务角度、系统角度、应用分析角度整体评估投入产出和收益。确定后开始进行云上规划，涉及到的网络、服务器、数据库、中间件等。哪些是在这个过程要优化的。应用、数据的迁移从准备到完成，是整个路径里花费时间最长的环节之一。上云后开始做相应的验证，特别是增量迁移的验证，数据一致性的校验等。最后做一个访问切换。

在这里数据应用迁移和数据迁移是最重要的环节，也是我们本实践重点实操的内容。在这里举个关于服务器迁移的例子，大家会关心服务器迁移会投入多长时间，

以小型业务平台为例，某一个客户从线下VMware vSphere虚拟机集群迁移到阿里云ECS，大概60台的规模，涉及到CentOS、Windows Server，大概一个人投入了一周的时间。

另个一个例子，一个500台左右的中型业务平台，从线下私有云迁移至阿里云ECS，这里涉及到虚拟机，还有少量的物理机，包括CentOS、Windows Server的这样的一个系统平台，大概1-2个人投入了2周的时间。

3）服务器迁移常见方式

关于服务器迁移，给大家做一个汇总和对比。

第一种方式最早大家接触最多的是通过重新部署迁移，在这种方式里操作容易度、迁移速度、系统还原度都是非常低的，特别是一些老系统、复杂的系统，这个方式成本会更高。

第二种方式是通过导出镜像的方式进行迁移，相比第一种方式来讲，操作容易度、迁移速度、系统还原度上都有一定提升，但是经常会遇到一些问题，包括客户反馈重启失败、不支持数据盘迁移等。

第三种方式是自动化的一个方式，基于阿里云提供的SMC迁移中心来完成，在操作易用性、迁移速度、系统还原度上都有大幅的提升。

4）服务器迁移最佳实践-注意事项

本次实践有哪些注意事项在这里给大家做一个说明。

Ÿ 客户如果关心查看跟踪迁移进度，可以在控制台概览页面查看所有迁移和迁移任务的状态，了解整体迁移进度，识别并排查迁移中出现的问题。

Ÿ 迁移到已有服务器时，迁移完成后，目标实例中的原数据将会被清除。因此，如果作为目标实例的ECS中存在重要数据，是不建议做为目标实例的。

Ÿ 如果目标实例数据盘数据量少于迁移源数据盘的数量，迁移源的数据盘将不会全部迁移，所以建议先在目标实例上挂载与迁移源等量的数据盘。

Ÿ 如果目标实例磁盘小于迁移源磁盘大小，建议先对目标实例的磁盘进行扩容升级，同时建议在迁移前先排除动态数据目录，包括大型数据库的数据目录等，等到业务暂停后再迁移，。

Ÿ Windows操作系统是不支持迁移至容器镜像的。

Ÿ 迁移周期时间长，时间长度和待迁移服务器的数量和实际数据量成正比，建议根据实际迁移测试演练进行评估。如何来提高或者加快迁移周期呢？一方面，选择离源服务器所在机房最近的地域作为目标地域，如果该地域不是的部署地域，可以在迁移完成之后再将镜像复制到最终地域。

第二点是增加公网带宽或者不迁移数据量大的数据盘。比如说超过100G的数据盘可能会比较耗时，盘的大小不影响迁移速度，实际数据量的大小才影响迁移速度。

Ÿ 关心迁移过程中是否收费，对于迁移服务中心，SMC是免费的服务，迁移过程中会涉及到少量的阿里云ECS资源，包括会涉及到的中转实例、云盘和快照（如开通）等会按量计费。

5）迁移实践-演练效果

本次实践会提供一个模拟场景，以阿里云服务器ECS实例间迁移为例，将华北1（青岛）的服务器实例，迁移到华东2（上海）为例。如图所示，会在阿里云模拟一个原环境，通过CADT快速拉起，利用服务器迁移中心SMC实现服务器的迁移，演示步骤会包括：

Ÿ 导入迁源

Ÿ 创建迁移任务

Ÿ 验证迁移结果

Ÿ 检验增量迁移

二、服务器迁移最佳实践-核心产品讲解

1）传统迁移方式痛点明显

正如前面所提到的，其实核心的问题和很多企业客户所担心的问题是迁移，服务器迁移和业务迁移所带来的困扰和挑战。对于一些传统的迁移方式，包括重新部署、镜像制作、导入的方式，其实都会伴随着明显的问题和挑战。

Ÿ 操作起来可能会比较复杂，同时由于企业客户在迁移的过程中，它对云可能是一个初次接触和并不是很熟悉的过程，导致了整个学习过程和它的一个技术挑战是非常大的。同时伴随着由于企业的业务系统比较复杂，而且有一些比较相对来说老旧的业务系统，它的应用可能如果要是在云端进行重新部署是很难进行还原的。

Ÿ 由于复杂度和挑战可能会导致的问题是整个迁移过程中周期会拉的比较长，甚至迁移这个项目的进度不容易把握的，在中间出现的各种异常情况都有可能会影响项目的进展，进而影响到业务上的进展。

Ÿ 传统的迁移方式可能会涉及到大量的人力的投入，同时会有手工的环节，就伴随着会有一些人工的错误和一些误操作带来的一些风险。这方面就构成了我们传统的一些迁移方式，给业务和客户带来的一些挑战，所以应运而生，服务器迁移中心这个产品就伴随着解决这些问题的使命而诞生。

那么如果我们去总结服务器迁移中心这个产品，它今天给客户带来的价值和解决客户的问题，会有三个关键词：

Ÿ 高度成熟化。SMC适用于各种迁移场景，包括从物理机的上云迁移、虚拟机的上云迁移、从云到云的云间迁移。同时对于不同的操作系统，包括Window、常用的Linux的操作系统，像CentOS、Ubuntu等这些操作系统，都是能够很好的进行支持，同时在网络环境的适配性上，比如通过普通的公网传输，如果有专线的打通，可以进行专线的一个传输，保证它的网络传输的速率和稳定性。

Ÿ 高度自动化。首先服务器迁移中心在应对挑战核心提供的价格是提高迁移的效率，自动化是能够更高、更彻底的云解决效率问题，从单台服务器的迁移，是可以通过一行命令或者是手动下发，或者自动下发的方式进行迁移。如果要是多台服务器是可以进行批量的迁移，做到无人值守，高度自动化。阿里云也提供了SMC控制台，让用户实时查看整体的迁移进度，如果客户有自己的云管平台，有自己的运维平台，也可以接入阿里云提供的OPEN API进行统一的管控，这个体系是能够完全自动化的。

Ÿ 高度智能化，体现在两点：一是自动检测，二是自动修复。自动检测是迁移后生成的目标实例和目标镜像，可以进行自动检测，保证迁移后常规的应用、进程没有提起来，网络配置等是不是能通过检测。如果有问题能及早发现，并且再次重启迁移。自适应修复包括一些驱动的修复，包括cloud-init等这些云上必备的工具的安装。这是能够保证企业客户在迁移，不仅实现自动化，还在自动化后善后的工作也能在迁移过程中一次性覆盖掉。

2）持续增强的企业级迁移方案

我们很明确的感受是，近年来企业级客户对迁移方案的诉求是越来越强烈的，所以从2017年SMC推出后，我们持续的迭代和功能的增强。目前已经帮助超过3000家的企业级客户进行上云的迁移，对于大批量的迁移也能提供很好的支持，

目前广义口径统计迁移的成功率是97%，可能包括由于网络不稳定导致的失败，也包括像初次使用的时候不熟悉导致的失败，当然由于操作系统和应用的环境千差万别，不能保证100%整体迁移的成功率，这里面涉及两点：一是不断去优化产品，并且提供很好的文档和FAQ的工作，能够帮助客户更好的使用这个产品，同时我们在不断的进行产品优化，对于很多非常细节的方面，我们帮助客户提供更好更稳定的迁移的成功率。

三、实践操作演示

本次实践重点模拟阿里云内部的迁移实践内容，将华北1服务器迁移到上海，在这个迁移过程中，我们基于CADT快速搭建云服务器，部署相关的迁移工具，以及创建迁移登陆任务台去查看任务的情况、检验、验证结果，重点看一下原服务器增量迁移效果是否一致，接下来参考CADT快速拉起服务器。

CADT提供了相应的模版，可以直接保存去创建，本次实践是台区青岛的服务器，在这里做相应的修改，这里以新购为例。

选择对应的交换机。规划相应的网段。

这里选择对应的服务器，服务器名称，这里可以参考模版，不做相应的修改，重点把登陆的密码设置一下，保存。

然后做相应的部署，部署过程分为资源验证、检验通过。

这里面会提供价格的参考，在做架构选型过程中，可以辅助使用的工具。

接下来进入相应的部署，部署不成功会自动地释放，勾选相应的协议，开始创建相应的资源。

创建资源会依赖于创建的时间，等待几分钟。创建成功之后可以在资源控制台查看创建的情况，大家可以通过模版入口进入找到相应Demo的模版。

也可以修改做相应的操作。

在这里可以查看相应部署的状态，也可以导出相应的架构图，给客户提供一个架构图的参考，也可以导出架构图给到架构，还可以导出部署的报告和价格清单。

已经部署好了，在这里可以查看部署的情况。

创建的VPC和交换机的情况，VPC是可用状态，已经完成了一台交换机的创建，还有ECS。

大家在这里记录一下公网地址。

公网IP，下载可以在控制台上获取最新版本的，Demo里有，我直接拷贝过去。

下载完之后，可以看到我们下载的迁移工具，

需要对SMC客户端进行解压，这里面会提供多个版本，X86-64中64位的，386是32位的，本次我们用到的服务器是Linux 64位的，需要再进一步解压。

完成相应的解压之后，我们可以看到相应的文件内容，登陆到解压的文件。

可以看一下包含这些文件，这些文件是做什么的呢？其中go2aliyun client是我们的命令行主程序，user config-json是迁移源和迁移目标的配置文件，这个Excludes文件夹排除不迁移目录的配置文件，比如涉及到一些存储文件，暂时不需要迁移的可以在这里做一些配置。

Client_data是迁移数据文件，包含ECS中转实例信息和迁移进度可以来这里查看。

有哪些不迁移的在相应的文档里做相应的备注就好了。

接下来，导入迁移源，进入所在的目录，使用root权限，把文档里的信息拷贝过来，要注意一些下划线和格式。

这里面会输入相应的AK，就是我们的密钥控制台。

有个AK管理。

在这里去创建一个AK，创建用户，通过编程方式，填写信息，确认。

这里我已经提前创建好了，我们看一下，创建之后要加入相应的权限，包容管理云服务器的权限、管理专有网络的权限、管理迁移工具SMC的权限。

创建好之后，下载帐号的信息，记录AK。

大家看到镜像已经创建，开始进行迁移。

去SMC控制台，去看下迁移记录，我们可以看到已经在线。

接下来创建迁移任务，我们按规划会迁移到上海，这里根据业务判断是否启动块复制、目标类型，如果客户已经有了服务器可以选择已有服务器，容器化改造也可以将原服务器内容迁移到容器镜像里面，这些要提前准备好，本次实践选择云服务器镜像，开启自动增量同步，默认配置，确定。

可以看到已经是准备中。

开始准备启动。

接下来可以查看相应的日志，运行端口提示开始的时候，表示任务已经启动了。在这里面运行程序需要在后台打开，才能关闭终端。也可以通过tail-f./nohup.out命令去查看迁移的任务。

在这个任务中我们可以登陆控制台去查看相应的任务，迁移的任务和数据量、带宽有关系，所以会花点时间。

在这里默认是单线程的，如果需要加速传输的话可以开启多线程，通过编辑相应的命令cd go2aliyun_client2.5.0_linux_x86_64 vim client_data参数。

这里边Number为1，修改为非1的数，改成Number4为多线程，加速迁移的进度。

接下来去验证迁移的结果，控制台可以看到验证迁移过程，现在看到迁移过程已经验证完成。

这时候可以创建相应的实例来去做相应的操作，同时模拟一个增量的环节，我们在原来服务器的基础上新增一个MySQL来看一下效果，拷贝dnf -y install @mysql。

可以看到版本是8.0。

运行以下命令确认MySQL已启动，可以看到是在运行中。

我们刚才在设计增量的迁移过程中是一个小时，我们等待一个小时之后，可以看到同步时间已经做了相应的同步。

接下来我们检验增量同步是否已经同步过来，这里创建实例，为了快速拉起相应的环境，我们在这里选用CADT模版，这个可以直接使用。

在这里面，唯一要修改的是对应的镜像内容，选择自定义镜像，选择SMC生成的镜像内容，在这里要注意磁盘容量要大于原磁盘容量，输入登陆密码，保存。

开始相应的部署，这个部署和刚才的步骤是一样的，完成相应的价格清单，相应的资源的部署。

在创建过程中我们登陆原服务器，去看一下原服务器的文件数量以及MySQL是

否正常启用。大家可以记住这个数量，我们再做较验。

我们查看一下目标服务器，接下来较验增量迁移的相关数据。需要较验服务器上的文件数量是否一致，增量过程中新增的MySQL是否已经安装，MySQL是否处于启动状态。

接下来登陆到服务器，可以看到原服务器的数量是56320，可以看到目标服务器的数量是一致的。看一下MySQL的版本，大部分安装MySQL的版本是8.0.21，这个是一致的。

查看MySQL是否处于启动状态，可以看到MySQL状态是已经启动中。

以上就完成了服务器迁移和增量迁移验证的过程。

我们再做一个简单的回顾，本次服务器迁移重点是面向业务上云中对业务服务器迁移的一个过程，实践操作这个环节会给大家提前做一些准备，重点演示了以阿里云内部服务器迁移为例，做了相应的服务器迁移的过程。这个过程可以通过控制台线查看进度，自助简单地完成服务器迁移的任务，同时支持增量迁移、迁移到云服务器、迁移到镜像、容器镜像等，是一种非常便捷的方式。