七步教你搞定上云迁移

导读：

本文摘自于阿里云MVP、驻云科技运维总监乔锐杰撰写的《阿里云运维架构实践秘籍》一书，本文主要结合上云迁移最常见的运维热门需求，并通过真实的客户案例，向大家进一步分享云端运维架构的实践干货。

上云的诉求

上云迁移是在云端中比较常见的运维场景，伴随云计算的普及，越来越多的客户都将部署在物理硬件中的运行的业务运维迁移到云端。

客户背景：杭州某知名网上私人订制礼品购物平台2006年成立。

2014年12月的某日，该客户联系到我们。因为它的机房机柜于2015年2月到期，所以想把资源迁移上云。客户的需求很明确，希望我们根据平台已有的数据及特性，兼顾成本与性能，给予他们最佳的云架构/资源方案。

前期技术调研

经过我们前期的调研，初步了解到了客户的一些基本情况，如下所示。

• 运维团队规模（4人）：运维1人、运维架构师1人、网络工程师1人
• 客户研发/测试团队规模：30人
• 客户电信机房资源：
• 3个机柜
• 40台左右硬件服务器（DELL-R410为主，其中两台16核/96GB的内存用于XEN虚拟化）
• 200Mbps（独享）

IDC机房架构

由图可以看出传统电商的架构环境：

• 由于电商环境存在大量商品图片，所以CDN是必不可少的。
• 服务器端、前端采用Nginx + Varnish作为二级缓存，主要减少CDN回源访问的压力。
• 后端业务系统名称包括designe/kderp/search/res/seo/oc/img等十余项，采用的开发语言主要为Java、PHP、Python。操作系统主要为CentOs为主，少量Windows环境为辅。
• 图片源文件等，主要通过NFS进行磁盘挂载共享，图片数据量2T+。
• 数据库缓存端主要采用Redis作为数据库缓存，减少数据库压力。
• 数据库端主要为MySQL，采用硬件服务器上面部署MySQL主从。

三大运维痛点

从客户角度来讲，传统运维有三大痛点：

虽然云的确在成本、扩展、灵活性、快捷等方面有很大优势。但是，对云产品、云架构的灵活运用，是有一定技术门槛的。关于如何利用云资源设计出低成本高性能的架构，是个经验性的技术活。

由于客户没有7*24监控响应中心，往往导致出现报警情况时不能及时联系上运维，并立即响应解决，运维的7*24无法得到保障。

客户有4个运维人员，成本高昂也是最实质性的痛点。

通过洽谈，双方最终在12月底确定了合作意向。我们为客户提供上云架构方案+上云迁移+ 7*24监控+ 7*24运维服务（我方运维为主，客户运维为辅）来解决客户痛点。

上云迁移的挑战性

关于此客户上云迁移，我们主要遇到以下三大挑战：

挑战一：时间短。客户机房2月到期，而每年的2月14日（情人节）是一年中的业务高峰期。由于商务合作的时间点确定下来时已经到12月底了，所以项目排期比较紧，我们需要在1月中旬（仅两周）完成项目的上云迁移、测试及正式上线，并预留两周作为观察过渡期。

挑战二：业务系统及技术环境较多。通过梳理得知，客户有十余个业务系统，Nginx、Varnish、Tomcat、PHP、Python、Redis、MySQL等技术环境较多，这些大大增加了迁移难度。

挑战三：零配置文档、零规范。由这个挑战点可知，客户在某些方面是很不规范的。例如，一个经历了8年运维的系统，居然在运维配置文档、运维手册方面没有建立一份文档，仅仅有几张零碎的架构图。另外，在主机名、防火墙、配置文件规范等方面更是杂乱无章。在迁移期间还遇到过一件不可思议的事情—客户忘记了机房交换机密码，这给我们的迁移工作带来了极大的难度和挑战。

七步搞定上云迁移

2015年1月4日，作为运维负责人的我，和2名架构师、1名DBA、1名高级运维及2名中级运维，在当天下午开车前往杭州，进行项目周期为两周的上云迁移工作。

第一步：项目启动

2015年1月5日，这是来到客户公司正式开展工作的第一天。这一天我们的工作内容主要是确定双方参与项目人员的职责，制订项目通讯录，确定项目实施计划及项目周期（项目周期为12天）。

第二步：系统架构梳理及评估

接下来，进入项目迁移实施期间（时间节点：2016年1月6日—2016年1月7日），首先我们需要对原系统进行评估，并且制订云上架构。原系统评估的内容涉及系统架构、软件模块架构、业务架构、接口以及调用依赖关系、性能评估、上云迁移目标等。云上架构内容涉及上云后的系统架构、软件架构、业务架构、性能目标、上云难点等。

云上架构

云上架构与IDC架构的区别如下：

（1）加入SLB保障架构灵活扩展性

在前端我们加入了SLB负载均衡。在原IDC架构中，域名解析到不同的Nginx +

Varnish上，然后经过前端静态缓存，再转发到后端对应的业务服务器上。加入SLB后，此架构变得更加灵活。即将所有域名先绑定到SLB上，然后转到后端Nginx，通过Nginx做虚拟主机等七层更灵活的控制。

（2）采用TCP层SLB保障性能

在实践中，面对高并发性能要求的场景时，我们发现HTTP层的负载均衡，相比TCP层的负载均衡，在性能上面有很大差距。HTTP层负载均衡只能达到万级别并发，而TCP层的负载均衡能达到几十万级，甚至上百万级的并发量。所以在电商等网站应用中，对于SLB，我们优先选择TCP层。

（3）采用低成本高效率的按量带宽

在IDC机房，200Mbps的独享电信带宽，一年的成本大概是1Mpbs/100元/月×12个月×200 = 24万。而在云端，采用1Gpbs峰值的BGP多线SLB带宽，在带宽质量上面提升了几个量级。另外，带宽费用采用按量付费，大大降低了成本。

（4）数据库优先采用RDS，低成本高效率

在IDC硬件上采用MySQL主从手动部署并维护的模式，使得后期的维护管理成本很大。即我们要监控及维护主从状态，并且在出现问题时需要及时处理，保障业务对数据库读写的连续性。在采用RDS后，这些问题都可以自动化解决。即对数据库主从的监控、备份、后期维护、故障切换等，都是全自动。

第三步：迁移方案

在进行系统架构梳理及评估的同时，我们还对迁移方案进行了确认（时间节点：2016年1月6日—2016年1月7日），即如何将应用、数据迁移至云端。同时我们还确认了系统割接上线的流程及对应的时间节点。最后，在迁移方案中，我们确认了客户云上资源清单（23台ECS、2台RDS、1台SLB）及具体的服务器配置。

关于迁移方案，具体的实践要点内容如下。

• 上云实践1：云计算的优势在于分布式

在实践中很多用户喜欢把单台云主机跟同等配置的传统物理服务器相比较，其结果往往是用户抱怨云主机的性能如何的糟糕。但是传统物理服务器，在多核高频CPU等方面的性能，真的可以把云主机比下去吗？不一定。何为“云计算”，关键字在于“云”，即“分布式”是“云计算”最大的优势。所以在实践中，我们不要只追求单台机器的性能，而是要通过分布式的设计思想来保障业务的高性能。在此项目中，服务器的标准配置都是4核8GB，也有大多数服务器采用2核4GB的配置。我们通过分布式充分压榨了单台服务器的资源，从而最大限度地保障了最终的低成本（后面会详细给出相关费用）。

在迁移方案中，图片文件迁移的方案具有一定的难度。一方面，线下图片数据目录的数据量有2T多，而线上单块磁盘最多只能支持1T的容量（当前官网单块磁盘支持32T）。另一方面，2T的图片主要是小文件，数量特别多。那么，如何把这些文件迁移到云端呢？在上云实践2和上云实践3中，将介绍LVM + Rsync在云端中的应用。

• 上云实践2：LVM在磁盘管理方面的应用

在云端迁移方案中，我们购买了四块1T数据盘（每台ECS最多只能挂四块数据盘），通过LVM逻辑卷将其虚拟成一块4T磁盘，这样就在云端保障了大于2T存储数据量的冗余空间。

其实，官方是不推荐使用LVM的。因为阿里云的快照主要是针对单块磁盘，并不能针对几块磁盘进行同时快照。而LVM主要是在多块磁盘（物理卷）的基础上，抽象成为逻辑卷的。LVM的读写针对的是逻辑卷，而数据则被分散存储在最底层的物理卷（磁盘）上。如果某块磁盘数据损坏，但是想通过快照恢复这块磁盘的数据，我们是无法保障LVM逻辑卷整体数据的完整性的。而LVM主要是能够提升磁盘I/O，比如我们需要购买100GB的数据盘，若按常规配置，买一块100GB的数据盘即可；而我们也可以购买4块25GB的数据盘，然后通过LVM虚拟化成为一块100GB的磁盘。在功能性上面都能满足其需求，但在磁盘I/O性能上面，LVM至少能将I/O性能提升20%～40%。

这里采用LVM方案也是特殊情况，一方面碍于当时磁盘空间的限制，需要通过相应的技术手段，获得更大的磁盘空间。另一方面，这时候的磁盘类型只有普通云盘，我们需要想办法提升I/O性能。最终考量下来，我们决定优先采用LVM方案。即图片服务器采用LVM管理云盘，同时图片服务器也是NFS Server，通过NFS挂载以供客户端使用。但在这种情况下，图片服务器需要每天面对三百万PV的业务量，普通云盘的I/O性能是不能达到要求的。所以前端我们采用CDN（电商的标配）来减少后端静态资源请求的压力，并且在后端我们还部署了Varnish做二次缓存，再进一步减少对后端静态资源的访问压力。所以最终凭借普通云盘的I/O性能，满足一个三百万PV量的电商业务也算是一个非常好的实践了。

• 上云实践3：Rsync在云端的应用

怎样将线下数据在不停机的情况下实时地迁移到云端？Rsync是文件增量同步迁移最优方案。只不过在此项目中，一方面数据传输要走公网，另一方面数据量也较大。初步统计下来，完成数据增量迁移至少需要一周多的时间。由于这方面的数据迁移时间周期较长，为了避免影响整体迁移进度，我们需要提前开展这部分工作。

第四步：迁移实施

20多台云主机牵扯到Nginx、PHP、Tomcat、Redis、Varnish等环境的部署，而我们需要通过自动化的部署手段来保障部署的最大效率。线上23台服务器环境的部署，在半个小时内就可以完成（时间节点：2016年1月6日—2016年1月7日）。

• 上云实践4：域名备案要先行

上云的最后一步，是需要将域名的IP解析到SLB公网IP（或ECS公网IP）上。但需要提前在阿里云上对域名进行备案，如果到最后域名解析到阿里云上后才发现域名被拉黑，业务访问被拒绝，这将会变得非常麻烦。因此我们需要提前通过阿里云进行域名备案，或者已经在其他供应商进行备案，那么只需要将域名备案转接入阿里云即可。

• 上云实践5：通过镜像提升云端部署效率

刚开始我们开通了一台ECS，并对这台ECS做了运维规范方面的系统调优、安全加固等措施。然后我们又把这台ECS做成了一个基础镜像，批量开通了22台同样环境的服务器，大大提升了部署效率。

• 上云实践6：自动化运维工具的应用

关于对应软件的安装脚本，我们内部团队都统一存在在内部的GitLab中。我们通过Ansible工具，定制对应的PlayBook，推送对应的安装脚本到目标机器上。5分钟内完成了对应Java、PHP、Python等环境的安装。

随后，我们也迎来了迁移工作中最难熬的时期。因为运维配置手册、运维文档的缺失，所以在我们将应用代码部署到已经搭建好的环境中后，需要对每一项参数、每一个配置仔细进行调试。3名运维人员和客户运维人员及研发团队一起经过了一天一夜的努力工作，才完成所有代码以及对应配置文件的调试。至此，我们完成了大部分的迁移工作。后续的核心工作主要集中在功能测试、性能测试及上线割接上。

第五步：迁移测试

此阶段的工作内容主要为功能测试、性能测试，其主要集中在客户的测试团队（时间节点：2016年1月9日—2016年1月11日）。

第六步：上线割接

在上线割接前，我们需要做好客户及公司内部的维护通告。而在正式迁移的时候，由于客户数据库较多，无法做到实时迁移，所以我们采取了保守的做法，即停机迁移。迁移的最后一步是将域名解析至阿里云，这点在前面提到过，域名是需要提前备案的（时间节点：2016年1月13日—2016年1月15日）。

至此，我们是不是完成了最终的迁移呢？答案是否定的。虽然域名已经解析到最新的IP上，而且当前万网刷新最新的解析记录的最短时间周期为10分钟。但是由于我们无法把控客户端本地的DNS缓存，即还是会有部分客户访问到老的站点。所以要完成最后的迁移，我们还差一步上云实践7。

• 上云实践7：Nginx反向代理将老用户请求引流至阿里云

由于DNS解析切换，部分用户由于本地DNS缓存的原因，导致请求访问的仍旧是老的IDC环境，而出现异常错误提示等。所以我们需要在IDC机房前端Nginx上做302重定向跳转，将依旧访问IDC的客户引流到阿里云，这将大大提高用户的访问体验性。值得注意的是，由于Nginx是七层负载均衡，因此需要匹配域名。这里Nginx的server_name和跳转的链接配置的域名是同一个，所以为了确保跳转的域名解析到阿里云，我们可以在Nginx所在服务器的Hosts配置中强制地将域名的解析IP设置为阿里云对应的IP。

第七步：项目交付及后期监控运维

后续便是项目交付了，主要内容为文档的编写总结。此项目我们总共汇总了30余个文档，主要包含系统软件架构、系统架构、迁移方案、运维实施配置文档、运维维护手册、故障处理文档、资源清单等。在文档交付后，将进入后续7*24日常监控及运维阶段，这里不再过多概述。

上云前后的对比

在我面对的成百上千的实践中，这个客户的上云实践项目是“最佳”的，是我体会最深刻的，具体对比如表1所示。

表1　IDC与云端资源配置费用清单

随着云计算的到来，传统IT已经向大数据（DT）时代变革。云计算的低成本、高效率、灵活扩展等诸多优点，已经逐渐代替传统IDC的IT模式。以迁云的对比表格中的“成本”来说，迁云前，客户有四名运维人员；迁云后，客户是没有运维人员的。在上云的第一年，客户仅保留了一名运维来处理日常琐事。到了第二年，客户公司将剩下的一名运维人员也裁掉了。从某方面来讲，云时代给运维行业带来不小的冲击，很多运维人员将面临失业。因为传统中小型互联网公司不再需要运维人员来做一些琐事，这些问题在云平台中都能得以解决。从另一方面来讲，云时代也将给我们带来新的机遇及挑战，这就要求技术人员的知识要更加全面。这也是很多人说DevOps是未来之路的根本原因！

本文摘自于《阿里云运维架构实践秘籍》，经出版方授权发布。