更多精彩，请点击上方蓝字关注我们！
向云迁移，这是企业数字化转型需要迈出的一大步。
云迁移通常是指将企业的应用、数据从本地迁移到云端或者从一个云平台迁移到另外一个云平台。云迁移意味着迁移到公有云上去。今年9月，爱分析发布的《中国云计算行业报告》显示，中国云计算场规模有望突破千亿元大关，但市场渗透率只有5%-7%，云计算市场仍处于发展的早期阶段。由此可见，云迁移的工作任重而道远。
企业上云是大势所趋，但企业上云切忌赶时髦或一窝蜂。同采用其他新技术一样，企业上云一定要从实际的需求出发，找到适合自己的时间、节奏，而不要人云亦云，看到其他企业上云取得了良好效果，便操之过急或东施效颦。每个企业的应用环境不一样，技术储备和能力不一样，业务转变的方向和途径也不一样，所以每个企业的上云之旅也一定是独特的。在上云之前，企业一定要对自己的需求和IT架构作到心知肚名，然后才能制定有效的全盘计划，并遵照既定的目标按部就班地实施云迁移。
企业上云要特别关注以下几点：是否需要采用全托管迁移到云的方式，以便达到方便快捷的效果；如何才能在上云的过程中最大程度地降低对业务运营的影响；通过什么样的途径实现数据的安全上云?
企业上云的迁移流程通常包括调研、评估与设计、迁移整合与验证、运维与优化。整个过程看起来好像十分简单，但其中涉及大量细小的技术环节。从相对熟悉的传统IT架构迁移到相对新鲜的云平台，企业用户有一个慢慢熟悉和适应的过程，在理念、技术工具、使用习惯、消费模式等方面要逐步转变。
走好云迁移这关键一步，才能在未来更广泛的云实践中逐渐积累实验，将数字化转型推向深入。
案例分析
快销行业云迁移之旅
爱茉莉太平洋（以下简称爱茉莉）是韩国美容化妆品集团，经营着33个保健、美容和个人护理品牌，包括爱丽小屋、悦诗风吟、兰芝等。集团成立于1945年，目前是韩国最大的化妆品公司，也是全球第14大化妆品公司。
除韩国外，爱茉莉近几年在中国市场的发展突飞猛进。随着中国消费者需求激增，爱茉莉过去几年在中国的营业额呈两位数增长。爱茉莉致力于通过其丰富的创新解决方案推动传统美容的发展。
爱茉莉在业务迅猛增长和实施公司扩张战略时，在IT方面遇到了以下几方面挑战。
首先，企业需优化现有IT环境，为企业的“2020愿景”战略夯实基础。爱茉莉“2020愿景”战略旨在赢得中国化妆品市场的前三名市场份额，到2020年在中国实现29亿美元的销售目标。基于其发展战略，爱茉莉意识到，他们必须重新调整其IT结构和IT资源，以满足业务增长的需求。
其次，企业传统的IT基础设施已经无法支持爱茉莉当前迅速发展的业务。由于爱茉莉在中国的品牌知名度提升和销售业绩大幅增长， 其当前的传统IT基础设施已经无法满足日益增长的业务需求。
爱茉莉在IDC中部署了30多个品牌的官方网站和电子商务业务应用程序，其中大部分都部署在海外IDC中。中国的消费者越来越多地选择网上购物。爱茉莉开始大力扩建其电子商务渠道，不仅自建电子商务网站，还在天猫、京东等第三方购物网站上开通了旗舰店，旗下7个化妆品品牌均有自己独立运营的电子商务平台。
然而，由于当前IT系统的可扩展性和可维护性差，爱茉莉的IT团队无法有效地将IT资源工作负载与业务需求进行映射，从而导致系统在品牌营销推广期间出现过崩溃并导致业务损失的情况。
由于爱茉莉在海外部署应用程序，面临着高昂的费用以及合规方面的问题。
最后，爱茉莉的数字转型战略需要云基础设施的支撑。爱茉莉定位于一家创新公司，积极落实数字化转型战略，其战略部门制定了详细的转型计划，以加速提升业务绩效。
爱茉莉已经建立了诸如CRM平台、大数据分析、AIChatbot等项目。爱茉莉多重转型项目的基础是基于云计算基础设施。然而，爱茉莉的IT团队并不具备云IT方面的系统知识和经验，因此迫切需要专业的云合作伙伴帮助他们解决遇到的诸多问题。
云MSP服务商Bespin提供的服务与软件相结合的端到端解决方案涵盖专业咨询、迁移服务、架构部署和运维管理，可以帮助爱茉莉实现业务云化。
2016年，Bespin帮助爱茉莉把中国区核心业务系统，包括电子商务系统，从海外总部迁移到中国。爱茉莉原有的电子商务系统托管在数据中心。电子商务系统是一种面向互联网消费者的应用，而传统IT架构下的电子商务系统存在建设成本高、运维成本高且效率低、无法快速应对互联网上大规模流量访问挑战等问题，所以Bespin把爱茉莉的电子商务系统从传统的基于Unix服务器的IT架构迁移到Azure中国区上，以解决传统IT带来的瓶颈。
除了云迁移项目，Bespin还整合了第三方的解决方案，为爱茉莉提供上云之后的安全、应用性能优化、数据库优化等方面的解决方案和服务。
迁移到Azure后，爱茉莉引入了Bespin SaaS型云管理平台OpsNow,部署了基于云原生的运维管理模式, 实现了运维效率的提升和运维成本的优化。
其于Bespin的完整解决方案和服务，爱茉莉不仅提高了业务应用的稳定性、IT运维质量，而且还可以把更多的资源投资于创新型应用的开发上。目前，爱茉莉的所有核心业务应用程序，包括所有品牌的官方网站、电子商务平台和AmorePay（爱茉莉自主开发的统一在线支付系统）都部署在Azure中国。另外，爱茉莉正在开发自己的CRM平台、大数据分析平台和AI Chatbot，这些也是其数字化转型路战略的一部分。下一步，爱茉莉计划在云上部署更多的应用程序。
Bespin帮助爱茉莉合理且高效地将IT资源工作负载与业务需求进行映射，打造了敏捷且高可用的基础架构平台，在前端应用程序中出现高峰流量时也能安然度过，并且通过优化其云基础设施满足了爱茉莉对ROI和管理TCO的要求，将运维成本降低30％，性能提升10倍。除了基础设施层面的需求外， 爱茉莉的业务稳定性和可靠性也在云化过程中得到了充分保障。通过Bespin的运维服务，爱茉莉得以避免消费者在所有爱茉莉品牌网站上访问和购买商品时的延迟，尤其是在促销/营销活动期间，同时还实现了架构的高可用性并保证运营服务级别协议（SLA）达到99.95％。
爱茉莉这样一个跨国企业积极地向云迁移，一个非常重要的原因就是，这是其业务发展的必然需求。因为业务的快速增长，以及业务高峰频繁出现，传统的IT单体架构成了业务发展的掣肘，在性能、灵活性、扩展性以及安全性等多方面拖了企业发展的后腿。分布式的云计算架构、灵活伸缩的云计算资源、简单便捷的云服务模式，为企业的业务创新和发展提供了新的平台和契机。向云迁移是大势所趋。云计算已经成了数字经济时代新的关键基础设施。
从爱茉莉的云迁移之旅中，我们看到了它全面转向云的决心，以及转型前与转型过程中的全面规划、分布实施，还有与云MSP的精诚合作，这些都是一个企业平滑过渡到云的不可或缺的保障。
案例分析
保险业用户轻松上云
在传统行业上云的过程中，金融用户是最具代表性的例子。因为金融业务的创新必须依靠信息技术的创新。但是另一方面，金融用户对于业务的安全稳定和高可用性的要求又是所有行业中最严苛的。所以，金融用户在上云的过程中保持平稳顺畅是非常重要的，不能因为采用新技术就忽视或者说放松了对业务业务连续性的要求。
那么，金融用户在向云迁移的过程中，应该注意些什么呢？下面，我们就分析一下阳光保险集团股份有限公司（以下简称“阳光保险”）的上云之路，希望对金融行业的用户有一定启发和借鉴。
阳光保险是中国500强企业、中国服务业100强，成立3年便跻身七大保险集团，如今积极布局互联网金融和不动产海外投资领域，并且成功进军医疗健康产业，成长速度非常快。截至目前，阳光保险旗下已拥有财产保险、人寿保险、信用保证保险、资产管理、医疗健康、互联网金融等多家专业子公司。依托集团的优势，阳光保险有效整合旗下资源，持续研发满足客户需求的产品，不断升级以“闪赔”“直赔”等为特色的服务，着力打造强大的市场拓展能力、卓越的客户服务能力、杰出的风险管控能力和专业的资产管理能力，实现健康、持续、快速的发展。
对于以传统保险业务为主的阳光保险来说，如今转投移动化营销，这是传统行业向移动互联网转型变革的一个开端，具有普遍性。
在这一转变过程中，阳光保险在IT方面面临诸多限制：传统服务器虚拟化稳定性不足，使得核心业务系统的可持续运行能力受限；服务器虚拟化单个集群规模较小，使得IT系统建设的可持续扩展能力受限；原有的集中式架构的性能瓶颈逐渐显现，性能扩张能力受限；传统架构自动化程度低、资源配置与调度的难度大且周期长；传统IT资源的利用率低，无法有效支撑业务系统由集中式向分布式的转变过程。
为改变现状，阳光保险希望打破传统IT架构的藩篱，迁移到云上。青云QingCloud帮助阳光保险设计了云计算平台，完善其IT系统，服务于生产数据中心和同城灾备数据中心。
具体的实施方案如下：将青云QingCloud云计算平台分别建设于亦庄生产数据中心和通州同城容灾数据中心，用来支撑核心业务系统与同城容灾业务系统的部署与运行；利用QingStor对象存储服务对所有NAS的存储数据进行同城数据备份，以及新OA类业务系统的支持；利用云计算平台的分布式存储和全虚拟化服务来支撑部署桌面云，服务于核心业务系统的日常运行；利用云计算平台完成对物理服务器的统一资源管理与调度，将基础资源平均使用效率提升至60%，部分资源的使用效率可达到80%以上；基于云计算平台上可交付的PaaS组件，将阳光保险IT人员从基层组件的部署和调试中解放出来，投入到业务系统的开发工作中，并且通过云计算平台的自动化运维，大幅提升业务组件的可持续运行时间；利用青云QingCloud大数据服务来进行实时流数据处理，服务于阳光保险多个业务系统的信用评估功能模块。
从整个的云迁移过程来看，阳光保险利用云计算、大数据等新技术改造了原有的IT系统架构，将传统的集中式IT基础设施中的NAS存储、服务器虚拟化、FC SAN逐步更新迭代成为以分布式存储、软件定义网络、云端应用中心为基础的云架构。云平台提供的虚拟化解决方案、丰富的PaaS服务、大数据平台、海量存储解决方案，使用起来更具弹性和灵活性。特别是在安全性方面，云平台内置了丰富的监控和安全防护组件，提升了安全运行水平，保证了从传统IT架构到云平台的业务连续性，并采用超融合设备，节省了阳光保险的基础设施成本，有效降低了IT投入。
金融用户上云整体来说是比较积极的，因为这是业务发展的必然需求和市场竞争的必然选择。但是，对于金融用户来说，掌握好新技术与业务连续性之间的平衡是非常关键的，向云的迁移千万不能影响业务的正常运行。所以，在选择具体的云模式，以及在实际迁移的过程中，金融用户必须有周密的事前计划和完备的实施细则，以保证迁移的万无一失。
案例分析
金融行业数据库跨国迁移
“连数据库都上云了，还有什么不能上云？”亚马逊的CTO Werner Vogels的这句话让人印象深刻。在各种应用向云迁移的过程中，数据库的迁移应该是最复杂和最能体现厂商技术和服务功底的。
数据库迁移往往是企业上云之旅的重点和难点。为此，AWS推出了AWS Database Migration Service，并且已在中国区落地。
AWS Database Migration Service是一种Web服务，可用于将数据从本地数据库、Amazon Relational Database Service (Amazon RDS)数据库实例上的数据库或 Amazon Elastic Compute Cloud (Amazon EC2)实例上的数据库迁移到AWS服务上的数据库。这些服务可以包括Amazon RDS上的数据库或Amazon EC2实例上的数据库。用户还可以将数据库从AWS服务迁移到本地数据库，并可在异构和同构数据库引擎之间迁移数据。
AWS DMS服务支持同构迁移（例如从Oracle迁移到Oracle），以及在不同数据库平台之间的异构迁移（例如从Oracle迁移到Amazon Aurora或从Microsoft SQL Server迁移到MySQL）。另外，它还支持客户从任意受支持的源位置（包括Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle、SAP ASE和SQL Server）将数据流式传输到Amazon Redshift，以便在PB级数据仓库中对数据进行整合和轻松分析。AWS Database Migration Service 还可用于连续数据复制，且高度可用。
光环有云利用AWS DMS将某企业客户的MySQL迁移至AWS RDS Aurora。该用户的业务系统原来运行在某云新加坡区域，因故需要迁移到其他公有云。最终，客户选择将其业务系统迁移至AWS东京区域，同时选择AWS高级咨询合作伙伴——光环有云作为咨询和实施服务提供商，完成AWS基础架构的部署和数据库迁移工作。
客户运营着一套类金融系统，由10+应用系统构成，超过40台虚拟服务器，采用MySQL 5.6数据库服务，数据量超过700GB+，日数据新增量约5GB，另有一个测试数据库。客户主要运营的业务系统对于安全性要求很高，出于业务连续考虑，预设迁移时间窗口有限，其业务系统依赖于事务处理，对延迟敏感。
光环有云利用AWS DMS将客户的MySQL迁移至AWS Aurora的具体过程如下。
第一，数据库迁移准备。
数据库信息准备工作包括生产库信息统计、生产库性能监控、日新增数据量统计、业务高峰期统计，以及生产数据库版本、参数、用户、存储过程、函数等信息记录。
在进行方案规划时，通过对客户业务场景、应用系统、数据库以及运营管理等多方面深入调研后，基于AWS数据迁移最佳实践和光环有云在数据库迁移的丰富经验，结合客户的具体需求和约束条件，提出了以MySQL复制+DMS同步和以MySQL主从复制+xtrabackup 增量还原两个方案规划。
MySQL主从复制+DMS同步方案，其主要步骤如下：搭建IPsec VPN，打通某云Singapore—AWS Tokyo；某云RDS创建物理全量备份，并将备份文件还原到一台新实例中，该实例将当做此次测试的Master库；在AWS环境中，新启一台EC2实例并安装MySQL服务，同时拉取备份文件到EC2实例中；将EC2中的备份文件还原到EC2 MySQL数据库里，当前MySQL将充当Slave服务器；在Master和Slave 之间建立主从复制；AWS Tokyo region的VPC中启动一台Aurora MySQL-5.6；在EC2 MySQL（Slave）和AWS RDS Aurora 之间配置DMS同步；等Master、Slave与AWS RDS Aurora同步完成后，校验数据完整性；导入一批测试数据到Master中，用作增量数据同步测试；校验Master、Slave与AWS RDS Aurora同步情况，并校验数据完整性。
MySQL主从复制+xtrabackup增量还原方案，其主要步骤如下：搭建IPsec VPN，打通某云Singapore—AWS Tokyo；某云RDS创建物理全量备份，并将备份文件还原到一台新实例中，该实例将当做此次测试的Master库；AWS环境中，新启一台EC2实例，安装MySQL服务，拉取备份文件到实例中；将EC2中的备份文件还原到EC2 MySQL数据库里，当前MySQL将充当Slave服务器；在Master和Slave 之间建立主从复制；在Slave中使用xtrabackup创建全备；将全备文件同步到一个AWS Tokyo region的S3存储桶A中；导入一批测试数据到Master中，用作增量数据同步测试；在Slave中在全备的基础上使用xtrabackup创建增量备份；使用AWS S3 Sync将增量数据同步到S3存储桶A中；将AWS Tokyo region 的S3存储桶A中的所有数据，还原到AWS RDS Aurora数据库中。
在迁移前，以较小数据量按照规划中的两种方案分别进行了模拟测试。测试结论显示，鉴于客户预设停机窗口有限，为保持良好的业务持续性，所以最终选择方案1作为主方案，方案2作为备用方案。在迁移实施时，两个方案同时进行。
第二，项目实施迁移。
迁移原则如下：满足迁移约束条件，方案验证可行；对迁移过程控制和识别风险并应对；业务影响最小，数据安全、完整、可用；最小可用权限，授权操作，不碰数据。
“结果很重要，过程须控制。”迁移是一件多风险、易出错的工作，协同工作的所有环节都可能出现错误，从而导致迁移的失败。光环有云对迁移过程十分重视，会同客户一起认真分析迁移的所有流程，并细化成指导迁移实施的指导性文档，作为迁移实施的过程控制文档，其中包括迁移详细计划、迁移流程、所有任务、RACI协作、任务详细文档（脚本、操作详细步骤）、任务耗时、任务异常处理等。
在使用AWS DMS进行迁移的过程中，可能会遇到如下挑战：数据库权限、目标库信息重建（用户、存储过程、视图、函数等）、DMS校验报错、字符集不一致、时区设置、DMS同步数据追平、DMS实例与迁移数据量、增量与时间窗口的平衡。
在实践中，光环有云发现使用AWS DMS进行迁移既有优势，也有其局限性。优势表现在：简单易用；在迁移过程中源数据库可持续运行；具有较小的业务中断窗口，可保持业务连续性；支持异构数据库迁移；可实现自动故障转移，十分可靠；在向Aurora迁移数据库时，可免费使用AWS DMS 特定实例 6个月。
其局限性表现在：DMS仅同步表中的数据；同步较大的数据增量时，耗时较长；AWS DMS自身校验机制耗时易报错。
总之，利用AWS DMS进行数据库迁移，可以轻松并安全地将数据库迁移至AWS。源数据库能够在迁移过程中全面保持运行，从而尽可能减少依赖该数据库的应用程序的停机时间。AWS DMS可以在广泛使用的开源商业数据库之间迁移数据。
不过还是要提醒用户注意，数据库迁移是一项十分复杂且有难度的工作，即使是有高效安全的迁移工具，还是需要一支有经验的技术团队作为迁移的支持，这样才能保证数据库迁移的安全、有序进行，避免差错；光环有云作为AWS专业服务商可以为客户提供从云迁移到运维管理的整套解决方案。
案例分析
灾备数据上云
时至今日，云安全的问题仍然是许多企业用户上云最大的绊脚石。数据上云过程中的安全，以及云中数据的保护、容灾是必须解决的问题。云备份、云容灾的一个核心问题就是数据迁移。
下面，我们将通过新华医院的案例具体分析一下数据云迁移。
新华医院是上海交通大学医学院附属医院，创建于1958年，是新中国成立以来上海自行设计建设的首家综合性医院。目前，它已成为上海市门急诊量最大的三级甲等医院，儿科和成人学科门类齐全，特色鲜明。
新华医院的业务系统均采用本地备份方式对各应用服务器系统进行数据备份，备份完全存放在本地硬盘中。但是，采用本地备份风险大，如果本地的主备存储一旦发生故障或数据中心灾难，数据将永久性丢失。数据采用一主一备传统的本地备份方式，面临着老旧设备不断更换、软件不断更新以及新老设备间数据迁移等问题。医院每年需要投入大量硬件资源和资金来保存历史数据。此外，各个诊室经常会有扩容的需求，而本地存储空间捉襟见肘，需要不断增加存储空间。而本地存储方案的软硬件性价比不高。
目前，新华医院在自建机房中拥有两组数据量较大的存储设备，总数据量近上百TB，且随着业务发展还会不断产生新的海量数据。但是，医院并没有对数据进行异地容灾保护，一旦数据丢失或损坏，后果不堪设想。
为了保证业务数据的安全，新华医院考虑采用云容灾的方式，实现海量数据文件亿级别的云上灾备；存储中存量数据文件的快速迁移；后续新增数据的增量同步；文件属性的迁移备份，保障用户云灾备数据还原后真实可用；用户数据的随时恢复和访问，保障生产端数据的安全；容灾备份服务进行时不能影响医院业务正常运行；运维服务及时有效。
为了实现上述既定目标，新华医院采用了混合云解决方案，建立外部数据容灾节点，实现异地冗余备份。整体规划目标为，本地业务上云，建立云容灾中心，对新华医院现有上百TB数据中心进行容灾；在数据中心数据出现无法访问的情况时，可以快速恢复，并在有必要时直接远程访问数据，保证业务连续性。
新华医院部署的英方容灾管理平台，通过部署在系统上的轻量级客户端模块，对需要保护的数据进行系统级I/O旁路监听，以细粒度的字节级增量数据捕捉方式，将生产端变化的数据迁移到云灾备中心，同时也可将变化的数据实时地传输到任意距离外的灾备站点，并通过特有的DOT数据序列化传输技术，严格保证生产系统和灾备中心数据的一致性和完整性。
在容灾过程中，以字节为数据捕捉的最小单位，而不是以传统方式中的文件或者数据块为单位，极大地缩小了复制的数据量，不仅节省了网络带宽资源，也提高了整个灾备系统的效率。通过旁路式截获生产系统的数据变化，在应用层对变化的数据进行缓冲、压缩、加密、发送、确认，并且可预先限制备份软件可使用的系统资源上限，从而保证了任何情况下都不会对现有生产系统的正常运行造成影响，且保证了数据在整个过程中的安全性。
云容灾说到底就是要保证数据在本地和云之间传输的及时、高效、一致性，以及可恢复性。随着云计算的兴起，云的备份、容灾将成为一种最基本的应用和数据的保护方式。
真有“逆向迁移”吗？
在轰轰烈烈的云迁移大潮中，我们也注意到了一些“不和谐”的因素，就是个别用户的“退云”现象。
退云是因为上云不成功吗？业内一家知名云MSP的专家告诉记者，其实并不是上云失败，而是因为企业业务在公有云上到达了一定程度和规模后，企业考虑如果自建云可能从各个方面来衡量都比公有云更划算，所以才选择从公有云上退出，转而自建专有云或采用混合云的方式。
这位专家分析说，公有云非常适合那些初创企业、快速成长型企业，以及希望在全球拓展业务的企业。那些想“退云”的企业，一定是其业务规模达到了非常可观的程度，企业开始担心这时如果所有业务还都在云上，成本、安全等方面会不可控，所以才重新评估，考虑以自建专有云的方式，能够更好地满足其全面可控、持续稳定和可靠的需求。
“退云”又被有些人称为逆向迁移。一些市场分析报告归纳出了以下几种逆向迁移的原因，比如上云后未能达到预期的财务目标，遇到了意外的安全性问题或棘手的合规问题，或者云与企业大量的遗留系统之间不能实现深层次的整合和协调一致。
在这里需要提醒用户注意的是，逆向迁移可能比上云存在更复杂的情况和更多的技术挑战。无论是上云还是逆向迁移，企业必须对自己的业务需求有清楚的认知，既不能盲目乐观，也不能因噎废食，谨慎而又目标明确，自己的努力加上外部的支持，这样才能在本地与云之间游刃有余，在云化的大潮中立于不败之地。
往期回顾
●你和云之间差了一个Cloud MSP的距离
●云迁移的来龙去脉
●记一次U2VL迁移实践
长按二维码识别关注云报
中国云报
小编微信：Taogebj
联系邮箱：[email protected]
继续阅读
阅读原文