浅谈XX系统跨平台迁移（测试环境）

一概述

XX系统目前运行在XX-A的云平台上，计划将其迁移至XX-B的云平台。

XX系统是java开发，中间组件涉及nginx+keepalived实现各个业务系统之间的高可用，kafka，zookeeper、redis等组件用于消息处理协调及缓存工作，数据存储有postgres、fastdfs、hbase。针对数据接入，有各个基站数据发送至数据处理服务器再转发至网关接入系统。数据迁移过程中，上层业务系统及中间组件迁移事项比较单一，进行再部署，配置修改即可。针对数据处理服务器（即目前使用的抓包服务器）涉及修改数据转发目的地址至XX-B的新地址，难点存在于数据存储部分的迁移事项。

二网络

方案1：

VPN（Strongswan）

方案分析：

搭建VPN的方式对公网带宽有一定的影响，若vpn带宽用的过大，则会影响到线上用户对系统的访问；若VPN带宽用的过小，则会对数据同步速度造成影响，本次测试未考虑此方面的问题。

方案实现（亲测）：

flexgw镜像使用指南：http://source.docs.cloudcare.cn/support/image/others/others_16/?spm=5176.730006-cmjj006981.102.10.ZjE3eJ

strongswan：https://help.aliyun.com/document_detail/57412.html?spm=5176.product51933.6.556.s0PPxP

注意：

在VPN搭建完毕之后，需要对hbase添加访问白名单，在其中注明源地址的IP段；
在源设备中添加静态路由指向VPN设备地址；
在NAT映射设备中需要添加路由指定目标网段访问指向到vpn所在设备；

三数据存储-fastdfs

方案1：

针对fastdfs的迁移，其中主要存储图片数据，需要先将postgres数据库及数据导入之后，再进行fastdfs数据导入，因为在fastdfs导入的时候会将每个图片生成一个链接地址存储在postgres中，供其他业务系统调用。

方案分析：

数据迁移不会对原线上系统造成影响。

方案实现：

/usr/bin/fdfs_upload_file /etc/fdfs/client.conf /file/need/to/be/import

四数据存储-postgres

postgres有业务系统数据及轨迹数据，其中轨迹数据需postgis轨迹插件支持。

方案1：

通过使用ECS服务器实例搭建相同版本postgres及相同版本插件，首先关闭postgres写入，再将postgres数据dump到本地，再使用sql命令导入dump下来的文件。

方案分析：

考虑线上环境postgres数据量大，dump时间+数据传输时间+数据导入时间=T远大于实际能接受的范围，故此方案排除；

方案实现：

通过pg dump命令对数据进行下载及导入。

方案2(优选方案)：

通过使用ECS服务器搭建相同版本postgres及相同版本插件，并对原系统postgres及XX-B上postgres配置进行修改，配置主从postgres数据同步，待数据同步完毕之后，进行主备切换。

方案分析：

此方案能够满足线上系统几乎不影响用户使用，在增加此同步postgres之后，对原有系统网络性能会造成一定的影响，故建议在夜间用户访问量较少的情况下进行。

方案实现：

参考我博文（亲测）：

Postgres配置主从流复制：http://www.cnblogs.com/cf532088799/p/7560842.html

Postgres主从切换：http://www.cnblogs.com/cf532088799/p/7592253.html

方案3：

通过使用XX-B的RDS数据库服务中的postgres数据库，使用DTS数据同步工具对测试环境postgres数据进行同步。

方案分析：

由于XX-B的DTS数据同步工具对postgres版本支持9.4及以上，测试环境及实际云环境中postgres版本均为9.1，所以此方案排除；

方案实现（若版本在9.4及以上可采用此方案，由于不符项目实际情况，未经测试）：

DTS PG迁移手册：https://help.aliyun.com/document_detail/26624.html

方案4（若能实现，则为优选方案）：

通过在测试环境搭建9.4版本的postgres，再对9.4版本psotgres与9.1版本postgres做主从同步，之后再通过XX-B的DTS数据同步工具来同步测试环境中的9.4版本的数据并使用XX-B云平台上RDS中的postgres服务。

方案分析：

此方案未经过测试，实际是否可行未作验证。

方案实现：

无　　

五数据存储-hbase

测试环境中仅仅对表H_DSE_TRACE进行导入/同步等测试，其大小在3.15G左右。

方案1：

通过对表进行快照备份，再将快照导出至目标集群，再通过数据恢复（快照恢复方式）。

方案分析：

对整个表进行快照备份，考虑到线上实际环境数据量大，表快照生成时间+表快照导出时间+表快照导入时间=T大于一天，故此方案不可取。

方案实现：

参考我博文（亲测）：

使用hbase快照将数据输出到互联网区的临时Hbase集群：http://www.cnblogs.com/cf532088799/p/7445942.html

方案2：

通过采用XX-B云平台数据集成工具，通过数据集成脚本配置，根据rowkey来分批次导入。

方案分析：

在实际数据集成脚本配置过程中，需要配置表列族下面的列名，由于本项目中列名是由程序中截取协议ID+时间生成，列名及数量不定，不能采用此种方案。

方案实现（若条件符合列名及列名数量固定可采用此方案，由于不符项目实际情况，未经测试）：

数据集成脚本模式：https://help.aliyun.com/document_detail/56231.html

数据集成reader：https://help.aliyun.com/knowledge_detail/54189.html

数据集成writer：https://help.aliyun.com/knowledge_detail/54191.html

方案3（优选方案）：

通过hbase原生CopyTable来进行数据同步，可根据rowkey值范围分批次进行导入。

方案分析：

此方案对网络要求较高，在导入之前需要先将表split一下再导入，否则写入速度提不上去。

方案实现（亲测）：

使用CopyTable同步Hbase数据：https://yq.aliyun.com/articles/176546?spm=5176.doc57695.2.2.c9ycjG

hbase shell 客户端：https://m.aliyun.com/doc/document_detail/52056.html?spm=5176.product49055.3.9.aEeFqx

（未完待续...）