背景
为了增强不同环境的隔离性、减少共享网络带来的卡顿、以及尽量避免业务规模发展后可能会遇到的安全性问题，我们计划将服务逐步迁移至阿里云 VPC 网络环境中。迁移之前，先在我们的测试环境上进行了尝试，以下是迁移的详细记录和遇到的问题。
要求
我们期望在迁移正式环境时做到无感知迁移，让终端用户感知不到服务的停顿。所以此次虽然是测试环境，为了给正式环境迁移提供更多的参考，也要尽可能地平滑，缩短停服时间。
迁移
迁移前后网络结构
我们的服务都是以 docker 容器的形式向外提供，每个容器都是无状态的，数据都放在 RDS。测试环境中，所有容器都跑在有一台双核16G的 ECS 上。在业务容器前面，有一个 nginx 容器。之前就考虑到了灵活替换 ECS 的问题，所以 nginx 容器是接在一个公网 SLB 之后的。具体的结构如图：
迁移到 VPC 后，最前端的公网 SLB（slb-p1）不会被替换，因为阿里云的公网 SLB 可以接经典网络 ECS，也可以接 VPC ECS（但不能同时接入这两种类型的 ECS）。SLB 之后的 ECS 和 RDS 都会被替换为 VPC 中的 ECS 和 RDS。迁移后的最终状态是这样的：
ECS ecs-v1 机器是用作 NAT 网关，因为阿里云 VPC NAT 网关服务资费的问题，我们选择了自建 NAT 网关。
自建 NAT 的好处在于成本更低，不足是不能做到多点冗余，当网关故障时，没有备用节点可用，只有等网关恢复整个网络才能访问外网。
流程
平滑迁移的主要瓶颈在于 RDS 的迁移。好在阿里云提供了数据传输服务（DTS）工具，支持经典网络和 VPC 之间的 RDS 数据同步。利用 DTS，可以将停服时间控制在秒级。对于容器的迁移，我们先将容器跑在 ecs-v2 上，在 RDS 迁移之前，让这些容器通过 VPN 继续读写经典网络的 RDS。待 RDS 迁移之后，再让这些容器读写 VPC RDS。
具体过程如图：
一，在 ecs-v2 上运行容器，读写经典网络 RDS
二，开启 DTS，同步 rds-c1 至 rds-v1
三，从 SLB 移除 ecs-c1，服务停止，确保 rds-c1 无数据写入
四，RDS 同步完成，切换 ecs-v2 容器的数据库配置，读写 rds-v1
五，加入 ecs-v2 到 SLB，服务恢复，迁移完成
实施
创建 VPC
阿里云的 NAT 服务收费比较贵，且只有按带宽收费一种模式，所以我们选择使用自建 NAT 服务。这样就需要两台机器，NAT网关节点（ecs-v1）和业务节点（ecs-v2）。
自建 NAT 网关
创建环境:
- 创建一个 VPC 实例，参考创建 VPC
- 创建一个 VSwitch，参考创建交换机
- 创建 EIP 实例，参考申请弹性公网 IP
- 创建 ECS 实例，参考创建 ECS 实例
创建两台 ECS：ecs-v1 和 ecs-v2。
ecs-v1 用作 NAT 网关，内网地址为 192.168.1.1。
ecs-v2 用于运行业务容器，内网地址为 192.168.1.2。
创建 EIP 地址。
操作步骤：
- ECS ecs-v1 绑定 EIP
- 开启 ip forward 功能
默认情况下，linux 会丢弃不属于自己的包。既然 ecs-v1 用作网关，就需要打开这个选项。
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf
- 配置 iptables
在 ecs-v1 上将 192.168.1.0/24 发出的包的源地址替换为 192.168.1.1
iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1
- 添加路由
在控制台添加一条路由，把发往 0.0.0.0/0 网段的包，发送给 ecs-v1（ECS ecs-v1 实例 ID）
这条命令的作用告诉路由器，把数据包全部交给 ecs-v1 处理。如果是发给内网 ECS 的包，会根据本机路由表，直接发给相应的 ECS。
搭建 VPN
搭建 VPN 的原因有两个：
- 为了平滑迁移，迁移过程中需要从 VPC 机器访问经典网络的 RDS
- docker registry 在经典网络中，VPC 需要从 registry 中 pull images
我们的方案中使用了 GRE 隧道来打通两个网络，因为两个网络在数据链路层就隔离，所以隧道只能走公网。
隧道的两端，一端为 ecs-v1，另一端为经典网络中的一台机器 ecs-c2
ecs-v1 公网地址表示为 1.2.3.4，内网地址表示为 192.168.1.1
ecs-c2 公网地址表示为 5.6.7.8，内网地址表示为 10.1.1.1
在 ecs-v1 上执行：
# 加载 gre 模块
modprobe ip_gre
# 创建一个隧道，命名为 tun1
ip tunnel add tun1 mode gre remote 5.6.7.8
# up interface tun1
ip link set tun1 up
# 为新建 interface 配置 vip
ip addr add 192.168.2.1 peer 192.168.2.2 dev tun1
# 增加一条路由，使得往经典网络的 remote vip 从这个隧道走。经典网络私网地址比较分散，所以这里设置成 10.0.0.0/8
route add -net 10.0.0.0/8 dev tun1
类似的，ecs-c2 上执行：
modprobe ip_gre
ip tunnel add tun1 mode gre remote 1.2.3.4
ip link set tun1 up
ip addr add 192.168.2.2 peer 192.168.2.1 dev tun1
route add -net 192.168.1.0/24 dev tun1
VPN 搭建成功，在 ecs-v2 中测试访问 rds-c1 （将它的ip表示为10.1.1.2）：
nc -nv 10.1.1.2 3306
ecs-c2 上运行容器
将测试环境的所有容器跑在 ecs-c2。此时 RDS 依然在经典网络中，要使运行在 ecs-c2 上的容器访问 rds-c1，几乎不需要多余的操作。因为 VPN，ecs-c2 可以透明地访问 rds-c1。要考虑的问题是，RDS 以域名的方式提供，在 VPC 中能否解析出经典网络 RDS 的域名。好在所有的 RDS 域名，都可以在阿里云任意一个网络中被成功解析。
唯一需要修改的是跑在 VPC 中的 nginx 容器，它的后端节点由 ecs-c1 变成了 ecs-v2 ，所以需要修改它的 upstream。
测试 VPC 容器
这一步保证运行在 VPC 上的容器都是可用的，以及它们能够正确地读写 rds-c1。
开启 DTS 同步
创建 VPC RDS（rds-v1）。并配置 DTS 开启 RDS 同步，DTS 会开始同步表结构、全量数据，然后持续同步增量数据。
停止服务
等待两边 RDS 数据基本一致时，删除 slb-p1 中的后端节点(ecs-c1)，确保 rds-c1 不再有新数据写入。
判断同步进度基本一致的指标是，看『延迟』时间。根据阿里云 DTS 官方文档，延迟是指目标 RDS 实例同步的最新数据的时间戳跟源 RDS 实例当前时间戳的时间差。也就是说，这个时间就是在停止对源的写入后，目标 RDS 与源 RDS 到达完全一致的时间。我们的测试环境数据量不大，我们在实际执行迁移时，DTS 的延时时间为 700ms。
这里之所以删除后端节点，而不是停止/替换公网 SLB。是因为替换公网 SLB 需要修改 DNS，DNS 生效的时间我们很不好控制。所以这一步的目的有两个：
- 停服，确保没有数据写入
- 移除 SLB 后端节点，后面会加入新的节点 ecs-v2
重定向数据源连接
在停服之后的几秒内，DTS 就能同步完 RDS 的数据，这时就可以恢复服务了。在服务恢复之前，需要确保服务不再读写 rds-c1，因为这时 RDS 已经迁移至 rds-v1。
我们的测试环境，一共有 50 多个容器，如果通过逐个修改容器配置来实现切换 RDS 读写，部署非常耗时。为了缩短停服时间，就不能采用这种方案。
我们最终采用的方案是使用 iptables 在 ECS 一层将所有对 rds-c1 的连接通过 DNAT 重定向到 rds-v1。这样不仅切换迅速，有问题也可以快速回滚。
iptables 匹配到 rds-c1 的连接，然后使用 DNAT 将 destination ip 改为 rds-v1 地址（192.168.1.19）
iptables -t nat -I PREROUTING --dest 10.1.1.2 -p tcp --dport 3306 -j DNAT --to-dest 192.168.1.19
这里有一个风险，规则中使用的 IP，而阿里云的 RDS 都是以域名方式提供的。所以可能会遇到 IP 地址变化的情况，这依赖于阿里云服务的内部实现。不过 RDS IP 变化的概率很低，以后在正式环境迁移时可以额外使用一个小脚本，在迁移过程中不断轮询 IP 是否变化，以便快速确定 IP 发生变化的问题。
停止经典网络数据源
当 VPC 容器数据库访问都已指向 rds-v1，就可以停止 rds-c1 了。停止 rds-c1 的原因有两个：
- 确保 VPC 容器不能再读写 rds-c1
- 上面的 iptable 规则仅仅对新建 TCP 连接有效，停止 rds-c1 可以将之前已经建立的连接强制断开重连
不过 RDS 实例并不能关闭，我们在控制台清除 rds-c1 白名单，保证任何节点都无法读写 rds-c1
恢复服务
将 ecs-c2 加入到 slb-p1 的后端节点，此时服务恢复。
修改容器 RDS 配置
此时每个容器中的 RDS 地址还是 rds-c1，只是通过 iptables 规则将其转发到 rds-v1。这一步我们将每个容器中的 RDS 地址修改为 rds-v1，重新部署一次。使容器直连 rds-v1。
移除重定向规则
容器直连 rds-v1 后，iptables 规则就不再需要了，将其移除：
iptables -t nat -L --line-numbers
iptables -t nat -D PREROUTING 1
关闭经典网络相关资源
迁移完毕，移除已经废弃的资源。
- 释放 DTS
- 释放 RDS
- 释放 ECS
预估停服时间
迁移之前预估的停服时间：
- 停止服务： 删除 slb-p1 中的后端节点 （开始停服）
- 重定向数据源连接 （预计耗时 5 秒）
- 停止 rds-c1：RDS 清除白名单 （预计耗时 30 秒）
- 恢复服务：将 ecs-v2 加入 slb-p1 后端，等待状态健康 （120 秒）
预计总停服时间 155 秒。
实际效果
整个迁移过程中，使用 bash 脚本循环监控站点的数据服务可用性：
while true
do
r=`curl -sS 'http://example.com/data' | grep 'ok'`
d=`date`
echo "${d}: ${r}"
sleep 0.5
done
实际迁移的停服时间符合预期。耗时两分半。
时间主要消耗在两个地方：
- 手动操作的时间，因为第一次执行迁移，整个过程没有脚本化。在控制台上用鼠标的一些点击操作，大约用了半分钟
- ecs-v2 加入 slb-p1 后，等待 SLB 状态变为健康的时间，大约两分钟。因为 SLB 不支持两个网络的后端共存，所以没有办法来绕过切换 SLB 后端带来的时间消耗。如果采用修改 DNS，即替换 SLB 的方案，倒是可以避免这个问题。但修改 DNS 的生效时间很长，两个 SLB（即两个网络）需要长时间同时提供服务。对于测试环境这不是大问题，但对于流量很大的正式环境，成本和风险都较高。
遇到的问题
VPN 中无法访问对端的 docker 端口
最初搭建 GRE VPN 网络时，我们将 GRE 隧道的两端，一端打在 ecs-c1，另一端打在 ecs-v1。
搭建完成后，在 ecs-v2 上使用命令测试到 ecs-c1 能够成功连通：
nc -zv 10.1.1.1 22
Connection to 10.1.1.1 22 port [tcp/ssh] succeeded!
但是 ecs-v2 却无法连通 ecs-c1 上 docker 暴露出来的端口：
nc -zv 10.1.1.1 53
TIMEOUT
这个问题困扰了我们很久，怀疑原因是 GRE 协议和 NAT 协议不兼容导致。因为 NAT 会修改数据包的 IP 地址，导致 GRE 收不到回包。因此，我们修改了方案，即使用经典网络中的另一台 ECS ecs-c2 和 ecs-v1 作为对端连接起来。这样在 ecs-v2 就可以访问 ecs-c1 上 docker 端口了，因为 ecs-v2 访问 ecs-c1，数据包实际上是先到 ecs-c2，再由 ecs-c2 到 ecs-c1。ecs-c2 到 ecs-c1 的访问对于 GRE 隧道来说是透明的，这样 ecs-v2 就可以访问 ecs-c1 上的 docker 端口了。
这样的解法带来的问题是，ecs-c1 就不能反向访问 VPC 网络了。但在实际迁移的时候，不会有 ecs-c1 回连 VPC 网络的需求。
关于这个问题，后来与阿里云的开发沟通过。阿里云方面给出的解法是，在 docker 容器中添加一条路由：
docker exec -ti --privileged=true <container_id> /bin/bash
ip route add 192.168.2.1/32 via 192.168.0.1 dev eth0
这个解法需要修改每一个容器，操作复杂，并且 docker 作为一个独立的容器，外部网络环境对其应该是透明的，没有理由去修改每一个容器自身的路由。所以我们最终没有采用这个方案。
DTS 同步错误
刚刚创建 DTS 同步任务之后，在第一步『结构同步』时遇到错误：
class java.lang.Exception: 请求创建缺失的数据库失败创建DB失败[{"message":"The specified DB instance name does not exist.","apiCode":"InvalidDBInstanceName.NotFound","requestId":"9446bbec-8b1f-4a72-9eab-aeceeb910b2e","data":null,"code":"404","success":false}]
给阿里云提交工单后，客服反馈原因是实例中包含带下划线的特殊库，需要手动在目标实例中创建，并给予对应的读写权限。经过反复尝试，最后手动创建了所有数据库（无论库名是否有下划线）才解决问题。
iptables 无法重定向来自容器的数据
其中使用 iptables 将所有经过 OUTPUT CHAIN 的数据转发到 VPC：
iptables -t nat -I OUTPUT --dest 10.1.1.2 -p tcp --dport 3306 -j DNAT --to-dest 192.168.1.19
是实际测试时，这个规则只对从 host 一层发出的连接有效。从容器中发出的连接，依然连向经典网络。
了解了数据包在 iptables 每个 table 和每个 chain 之间的流转链路，如下图。因为从容器出来的数据源地址不是本机，所以进入 FOWARD 链路。只有从 host 发出的数据包才会经过 OUTPUT CHAIN。
因此，要想对容器内发出的连接生效，就得设置 PREROUTING CHAIN：
iptables -t nat -I PREROUTING --dest 10.1.1.2 -p tcp --dport 3306 -j DNAT --to-dest 192.168.1.19
同时，loopback interface 会忽略 PREROUTING CHAIN，所以，如果想要对 host 和容器同时有效，就必须同时设置 PREROUTING 和 OUTPUT。
iptables 重定向后，对于已经建立的连接无效
上述的 iptables 规则只会影响新建立的连接，不会影响已经建立的连接。针对这一点，简单的改进点为：
在加入 iptables 规则后，恢复服务之前，关闭RDS（移除经典网络 RDS 的白名单）。
这样做的好处在于：
- 强制客户端重新建立数据源的连接，使 iptables 的重定向规则生效
- 确保被访问到的一定是 VPC 的数据源
iptables 重定向后，访问 VPC RDS 时出错
为了保证迁移的顺利，正式迁移之前，使用脚本测试 iptables 重定向连接的可用性， 该脚本从经典网络的 RDS 持续读出数据， 但在测试过程中发现使用 iptables 重定向到 VPC RDS 之后脚本报错，不能从 VPC RDS 读取任何数据。
原因是之前经典网络的 RDS 密码强度比较低，在创建 VPC RDS 时，阿里云强制要求了密码强度，所以密码和之前设置不一样。使用 iptables 重定向了 IP，但帐户使用的经典网络的账户密码，所以造成了读取错误。
使用该方法时，一定要保证两边的帐户密码一致。
迁移之前，我们将经典网络 RDS 的密码改为和 VPC 一致的强密码。该 RDS 帐户有 50 多个容器使用，如果要达到平滑修改，不中断服务的话，可以先新建一个临时帐户。将所有容器先改为临时帐户，然后再修改密码，最后将所有容器再修改为原来的帐户和新密码。为了在实施时减少工作量，我们中断了一段时间服务，直接修改密码。
私网 SLB 后端不能为 tcp 模式
我们尝试了在私网 SLB 后端添加 ecs-v2，如果监听模式为 http 时，可以正常工作。但如果监听模式为 tcp，就无法访问这个 SLB，表示为超时，即使其健康状态为『正常』。
该问题，阿里云客服反馈是网络的 bug，如果 client 和 SLB 后端 ECS 在同一个网段，并且 SLB 是 tcp 模式，那么访问可能会存在问题。暂时的解法是在 host 上将直连路由删除。并添加到 /etc/rc.local 下以免重启失效。
route del -net 192.168.1.0 netmask 255.255.255.0
经过实际测试，这条命令并不能解决问题，反而搞得 ecs-v2 掉线，服务不可用，ssh 登陆不上，最后只能从控制台重启。
这个问题我们发现提交工单的时间为2016年11月22日。但在写这篇帖子的时候(2017年1月3日)，又测试了该问题，发现已经解决。
容器中无法访问 RDS
在迁移完成时，将容器中的 RDS 配置改为了 VPC RDS。此时，出现了奇怪的问题，在容器中居然无法访问 RDS，以及所有 192.168.1.x 网段上除本机以外的所有机器。
这个问题期初怀疑是 GRE 和 NAT 网络造成的问题，可是断开 GRE VPN 后问题依旧。
最终定位该问题的原因是 host 上的路由表设置问题。这是其中两条路由：
192.168.0.0 * 255.255.240.0 U 0 0 0 docker0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
第一条路由子网掩码设是 255.255.240.0，在遇到类似 RDS 地址 192.168.1.19 时，会被计算为 192.168.0.0，使得本来该进入 eth0 的包却进入了 docker0。这就导致了在容器中无法访问RDS 的问题。
改为子网掩码即可：
192.168.0.0 * 255.255.255.0 U 0 0 0 docker0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
引起这个问题的原因是：docker 默认会在 172 网段创建 docker0，但新建的 ECS 默认会添加几条路由，其中一条为 172 网段。导致 docker 在 192.168 网段创建 docker0。结果和 VPC 的网段冲突。
结论
这次测试环境的迁移，我们遇到了很多问题，最后都一一解决或者绕过，停服时间也在之前预估的时间内。相比测试环境，正式环境的流量更大。迁移测试环境，我们对跑在 VPC 上的容器仅仅是用一个脚本简单地测试了其能否成功地读写 RDS。但在正式环境中，我们更希望引入真实流量来做灰度测试，这样可以防止当流量全部切到 VPC 产生一些未知的问题，但 SLB 并不支持同时接入两个网络的 ECS。
此次迁移还不能做到期望的完全无感知，但对于实现无感知迁移需要解决的问题，我们已经有了比较深的了解。主要障碍在于：
- RDS 切换
DTS 提供了良好的数据同步体验，其延迟可以低至几百毫秒。但是为了保证数据百分百同步到到目标 RDS，业务容器切换 RDS 之前还是得将切断服务确保源 RDS 没有新数据写入，对于大流量的服务尤其如此。切换 RDS 产生的停服似乎是无法避免的，但秒级的停服还能够接受。
- 经典网络/VPC 切换
- 阿里云公网 SLB 后端不能同时接入经典网络和 VPC 网络的 ECS，这导致 VPC ECS 在加入 SLB 之前，必须将经典网络 ECS 移除，而阿里云的 SLB 后端加入到通过健康检查的时间为分钟级。所以如果采用切换 SLB 后端的方式，那么分钟级的停服也是无法避免的。
- 而如果采用替换 SLB、修改 DNS 的方案，那么两个网络的 ECS 就不得不长时间同时提供服务。新旧 SLB 都会引入流量到经典网络和 VPC 的 ECS，其中 VPC ECS 会通过公网的 VPN 读写经典网络 RDS。这样做的风险在于，DNS 生效的时间我们无法掌握，也就不能很好地控制到 VPC 网络的流量。而且 VPC ECS 走公网读写经典网络 RDS 产生的带宽成本也不少。
上面提到的几点问题，很难绕过。我们希望能从阿里云基础设施一层解决，公网 SLB 如果能接入经典网络和 VPC 的 ECS，会有很大的帮助：
- 解决了切换后端带来的分钟级停服
- 两个网络共存，可以通过权重来分配到 VPC 的流量，达到灰度测试的目的。这样风险和成本都在可控的范围内。