业务迁移上云秘籍：从本地环境迁移到云端，不是一件容易的事情

本地数据中心的网络冗余，高可用方案，需要精通高级网络的工程师来进行配置和维护，网络上云之后，所有的这些都由 AWS 来进行维护，企业的维护人员具备简单的网络知识即可维护，降低了网络管理的门槛，也为企业节省开支。

工作负载迁移

我们把支撑业务运行的一些资源称之为工作负载，我们可以把虚拟机、数据库、应用等粗略的规划在工作负载层面，下面我们主要针对这几部分来说一下迁移过程中的情况，这也是我们整个迁移最重要的环节。

虚拟机迁移

将虚拟机转移到云端有助于避免会造成巨大财务压力的更新周期。准备就绪后，我们可以通过两种方式进行迁移，我们使用 Rehost 作为我们的迁移策略。

第一种：我们可以使用 AWS Server Migration Service 将虚拟机从本地或其他云平台直接迁移到 AWS。AWS SMS 是一项免费的服务，它可以帮我们把本地虚拟机增量复制为可在 Amazon EC2 上部署的云托管 Amazon 系统映像 (AMI)，整个复制过程，只需要支付迁移期间所使用的 S3 存储桶、EBS 卷和数据传输费用，以及所运行的 EC2 实例费用。

第二种：我们也可以使用 VMWare Cloud on AWS 解决方案将 VMware 虚拟机直接迁移到 AWS。 这意味着现有基于 VMware 的工作负载可从云端的性能、规模和安全性中获益，而无需在迁移时重写。

注意事项 因为是整体的搬迁服务器，要考虑到带宽是否满足，是否需要增加临时带宽。 复制过程中要考虑是否会用到临时的磁盘，存储空间是否足够。 防火墙的替换，共有云中没有物理防火墙，可以考虑使用 AWS 的安全组来替换。 价值体现 可以享受更高性价比以及更优化的配置。 多区域节点选择。 提高运维效率，将IT 运维重心转移到以业务为中心。

数据库服务迁移

本地数据中心的数据库服务，一般都是运行在物理机或者虚拟机上，由运维人员部署。针对数据库的迁移，我们主要有以下注意事项以及解决方案：

迁移策略：针对数据库，我们可以选择的迁移策略有 Rehost 和 Replatform。 针对 Rehost，我们可以直接使用 AWS SMS 来进行迁移。 针对 Replatform，就是我们把本地自建的数据库服务转换为 AWS 的数据库服务，AWS 的数据库很丰富，基本涵盖了市面上的所有数据库，包括关系型数据库和非关系型数据库。 注意事项 兼容性要求，如：文件格式，字符集的兼容性要求，引擎的兼容要求。 数据迁移的限制，如，服务商数据库名/表名保留字；是否影响业务及其程度；是否需要停服务以及停服务的时间。 迁移工具的便利性，服务商指导。好的迁移方案&工具应该是尽可能少人工操作，step by step，自动化。 数据完整性校验，在数据迁移完毕进行切换前，一定要进行数据完整性验证，以保证数据被正确、完整的迁移。如：部分服务商不能提供完整性校验，或者在校验存在不一致时无法给出具体信息，实际也无法定位。 价值体现 云数据库的高性能，高可靠性，扩展性，灵活性 大规模创新 兼具备份、扩容、迁移等功能 DBA 不用再去维护数据库的安装，运行，高可用，备份等，把精力集中在数据库优化业务上面。

对于 Rehost 的迁移，我们可以很方便地使用 AWS SMS 工具来完成，不过其中可能会有数据延迟，因为数据并不是实时同步的，所以我一般推荐大家使用云中的数据库，他具有我们传统自建数据库没有的一些优势。

AWS Database Migration Service (AWS DMS) 是一项云服务，可轻松迁移关系数据库、数据仓库、NoSQL 数据库及其他类型的数据存储。您可以使用 AWS DMS 将数据迁移到 AWS 云，在本地实例之间（通过 AWS 云设置）进行迁移，或者在云与本地设置的组合之间进行迁移，使用 DMS 服务，可以保证我们的源数据库和目标数据库数据实时同步，持续运行，使用这种模式，可以保证我们的数据库迁移零宕机。

对于一部分用户，他想在上云之后换一种数据库引擎，比如 Oracle 转换成 Aurora MySQL，遇到这种情况，我们可以借助 AWS Schema Conversion Tool 这项服务来帮助我们完成，在使用 SCT 的时候，比较消耗内存，提高内存性能可以提高转换速度，但会占用台式计算机的更多内存资源。

应用迁移

在实现应用迁移上云的过程中，一般会面临已有业务系统改造和新建业务系统两种场景。新建业务系统只需要按照应用上云的标准要求进行架构设计、研发、编码和测试即可，实现相对简单。已有业务系统迁移上云则需要对现有业务系统改造。

迁移策略：

对于 Rehost，使用 AWS SMS 服务可以方便地迁移整个应用程序技术栈上云，这种迁移相对来说比较简单，迁移完成之后，修改一下后端数据库信息，切换 DNS 服务即可上线。 对于 Refactor，这种情况会花费比较多的工作量，他需要用户重构应用程序代码，使其可以充分的去兼容云原生的一些服务，比如 Lambda，API GateWay，Elastic Beanstalk 等服务，以提高我们的应用程序的性能和安全。 注意事项 是否有相关的应用程序路线图 有哪些相关的成本与此应用程序有关系 有哪些改进选项可增强服务可用性 如果不改变这个应用程序，是否有相关风险 此应用是否与组织的技术目标互相一致 价值体现 可以使用云原生的服务 可以借助云中 DepOps 工具加速应用程序的测试与发布 运维开发人员不用再去管理应用环境的配置，专注于应用代码的开发，提升效率

对于应用程序上云，我们一般先在云中建立一套完整应用程序环境，等待程序测试无误之后，通过修改 DNS 来完成应用上云。应用稳定后，应用程序就可以逐步的有计划从本地中心移除。

容器迁移

随着近些年容器的流行，越来越多的公司会有一些服务运行在容器平台中。如果容器运行在单机上面，我们一般直接使用 docker 命令运行，或者使用 docker-compose，对于运行在多机器上面的容器服务，我们大部分使用的都是现在很流行的容器编排服务 Kubernetes。

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!