Category: 迁移


加速您的云迁移和 IT 产品组合分析的 3 条捷径

一只脚踩在油门上,另一只脚踩在刹车上可能会让您哪里也去不成,而且肯定会烧毁汽车的重要部件。-Terry Savage

我最近发布了几个系列的文章,其中详述了我们在大规模的 IT 转型云迁移中看到的一些模式。2014 年,我已谈及“分析瘫痪”是我们看到过的阻碍大型组织利用云的最大障碍之一。今天,AWS 的 Ryan Hughes 详细介绍了他和他的团队在帮助许多大型组织迁移到云并避免分析瘫痪时确定的一些捷径…

最近,AWS ProServe 顾问团队一直在帮助我们最大的一些企业客户分析和优先考虑其应用程序产品组合,以帮助他们做好迁移到 AWS 的准备。有趣的是,我们发现,与整个迁移工作的其他阶段相比,这种分析 (也称为产品组合合理化或应用程序处置) 已经开始消耗不成比例的时间。

为什么?许多企业告诉我们,一旦他们深入研究从其配置管理数据库 (CMDB) 或资产管理系统等场所采集的现有 IT 产品组合信息,就会发现这些信息不准确或过时,这令人感到意外。这种不确定性会导致迁移过程延迟,我们发现,许多高管会暂停工作,直到他们更准确地了解其应用程序所带来的业务价值、他们使用的资源以及他们使用的许可证。

虽然我们认同通过分析来了解应用程序的基础组件 (例如开发语言、虚拟机大小、操作系统) 是确保应用程序有效迁移至云的重要步骤,但是许多企业错误地将所有此类信息作为利用云执行任何工作的先决条件 (分析瘫痪),而不是将产品组合分析视为其迁移的持续和迭代部分。

Cardinal Health 是在其云迁移计划的早期遇到此障碍的企业客户之一。作为医疗保健行业的财富 25 强企业,Cardinal Health 致力于提高其业务敏捷性,同时保持较低的 IT 成本。云在实现这两个目标上有独特的优势,而 Cardinal Health 最近要求我们将敏捷结构注入其产品组合分析中,以便他们能够:

1.     更轻松地确定他们首先应迁移的应用程序

2.   尽快迁移这些应用程序,同时他们并行地迭代剩余的产品组合分析工作 (这样他们就能更快地实现价值并开始学习)

3.    基于他们从迁移中学到的知识,反复地向产品组合分析过程提供反馈

通过与他们的过程工程师和云团队协作,我们获得了三个主要的加速器,我们现在称之为“捷径”。2016 年 12 月,Cardinal Health 在 AWS re:Invent 分享了其成果 (视频),并且我们已对许多其他客户使用这些捷径。

它们是:

第 1 条捷径 — 在做事之前,不要计划好一切

分析瘫痪?许多企业错误地将完整的产品组合分析视为开始其云迁移的先决条件。相反,我们建议企业快速地了解哪些应用程序是符合云资格的,云友好的或云原生的 (标准见下文),然后对一部分此类应用程序进行深入分析。

在基于应用程序的特征将其“嵌入”后,这些应用程序将在待办事项中被优先考虑 (请参阅有关云迁移过程的上一篇文章),以便迁移团队能够立即开始迁移至 AWS 的过程。利用这种及时处理待办事项的方法,迁移团队能够利用其不断积累的迁移经验来为产品组合分析团队提供经过验证的见解,以便在将来的迭代中更精确地选择应用程序。

第 2 条捷径 — 创新以促进成本降低

许多大型企业 (以 Capital OneGeneral Electric (GE) 和 Dow Jones 为例) 正在将其大部分  ( 有时候是全部 )  IT 产品组合迁移到云…这种做法不足为奇。事实证明,企业可以通过将工作负载从本地迁移至 AWS 来降低成本。虽然省钱永远不会过时,但我们最成功的客户不会只关注现有应用程序的大规模迁移。实际上,企业客户采用 AWS 服务的最常见模式 (称为“采用阶段”) 是从以创新为中心的小型项目开始的。

这些创新性项目致力于扩展企业 IT 人员的思维模式和技能组合,使其超出常见的数据中心约束。 基础设施即代码完全托管的云服务无服务器架构立即触手可及并且将充当助推组织的云知识的“光辉”典范。

创新项目远不止那些提升员工技能的科学实验。它们还为企业提供其他类型的财务激励。不同于仅负责通过大量现有工作负载迁移来降低成本的 IT 组织,IT 可以开始直接推动收入增长。

作为红利,创新项目掀起的云知识浪潮实际上充当了加速组织的大规模迁移计划的催化剂。

将这两种方法 (大规模迁移和创新) 结合使用一直是使顶级企业能够提高收入并降低整体 IT 成本的关键战略。

第 3 条捷径 — 重购:迁移的秘密武器

在分析产品组合时,许多组织会因与这些专有系统相关的复杂性而将大型企业应用程序 (例如 SAP、Teradata 和 Tableau 解决方案) 放入“重新访问”存储桶中。不过,其他几个客户看到了巨大的机会,可以通过利用预配置的云就绪解决方案 (由其当前软件供应商或类似的竞争供应商直接提供) 来快速地将这些解决方案转化为上述“绿色”云存储桶之一。

顶级企业发现,将其部分复杂环境迁移到云的最快方式是使用“重新购买”战略,而不是使用“重新托管”或“重构”迁移战略 (请参阅有关 迁移战略的 6 R 的上一篇文章)。现在,称为“重购”,并不意味着您应该抛弃当前的解决方案供应商。许多 AWS 合作伙伴已经朝着在云中提供其解决方案的方向前进了。

一个常见的例子是,将本地 SAP 开发和测试环境替换为 AWS Marketplace 中的部署。AWS 已与 SAP 合作以确保其可用的解决方案已经过测试和预配置,以便在 AWS 环境中运行。这会将企业的适用于这些类型的解决方案的云计划更多地转化为数据迁移和配置练习而不是全范围迁移。

对于 TeradataTableau 和来自 1100 多家供应商的其他 3000 多个软件解决方案,情况也是一样…客户发现,通过使用这些预配置的部署,大量应用程序迁移工作事先已经完成。这条捷径的力量促使许多企业在产品组合分析过程中,开始将“重购”迁移战略视为其云迁移的“首选”策略。

总之,通过使用这三条捷径,企业可以在决定先将哪些应用程序或业务功能迁移至云时缩短价值实现时间。此外,企业可访问 AWS 迁移合作伙伴解决方案页面来浏览经过验证的工具、服务以及在产品组合分析过程的不同类别 (包括发现、规划和应用程序分析) 中具备“迁移能力”的合作伙伴,从而进一步加快其云计划。

将应用程序迁移到云的 6 个策略

“移民的实际生活状况如何 — 嗯,这取决于很多因素:教育程度、经济状况、语言、入境地点以及在到达地所拥有的支持网络等。” -Daniel Alarcón

本文概述了我们看到客户实施的旨在将应用程序迁移到云的 6 个不同的迁移策略。这些策略基于 Gartner 在 2011 年在此处概括的 5 R。这是有关迁移的由三个部分组成的系列文章的最终部分。本系列的第一篇文章说明了大规模迁移的概念 (我们在整个系列中将其简称为“迁移”),本系列的第二篇文章介绍了大规模迁移到云的过程。虽然这些文章是各自独立的,但我相信通读它们会取得更好的效果。

制定迁移策略

企业通常在“迁移过程”的第二个阶段  (产品组合发现和规划) 开始考虑如何迁移应用程序。此时企业会确定其环境中存在的应用程序、这些应用程序的相互依赖性、哪些应用程序容易迁移、哪些应用程序难以迁移,以及如何迁移各个应用程序。

利用这些知识,组织可以草拟出一个方案 (在迁移和学习的过程中应该考虑其会受到哪些变更的影响),了解将如何迁移其产品组合中的每个应用程序以及以何种顺序迁移。

迁移现有应用程序的复杂性因架构和现有的许可安排而有所不同。如果要我考虑如何将大量的应用程序迁移到一个复杂性光谱,我会将虚拟化、面向服务的架构迁移到该光谱的低复杂性一端,将一体式大型机迁移到光谱的高复杂性一端。

我建议从复杂度较低的应用程序开始迁移,理由很明显,即迁移更容易完成 — 这将在您学习时为您提供一些直接的正面强化效果 (即“速效方案”)。

6 个应用程序迁移策略:“6 R”

我们看到的 6 个最常见的应用程序迁移策略是:

1.     重新托管 — 也称为“简单地搬运”。

我们发现许多早期云项目倾向于使用云原生功能的全新开发,但在大型传统迁移方案中,组织希望快速扩大迁移规模以满足业务需求,我们发现大多数应用程序都被重新托管。例如,GE Oil & Gas 发现,即使不实施任何云优化,该公司也能通过重新托管将成本降低大约 30%。

大多数重新托管可以通过工具自动进行 (例如,AWS VM 导入/导出Racemi),但一些客户更喜欢手动完成此操作,因为他们可以学习如何将旧系统应用于新的云平台。

我们还发现,如果应用程序已在云中运行,它们将更易于优化/重新构建。对此,一部分原因是您的组织在这方面的技能更熟练了,另一部分原因是困难的部分 (迁移应用程序、数据和流量) 已经完成了。

2. 平台重建 — 我有时称其为“修补再搬运”。

在这个阶段,您可能要进行一些云 (或其他) 优化以获得一些有形的收益,但您不能更改应用程序的核心架构。您可能希望通过以下方法缩短用于管理数据库实例的时间:迁移到数据库即服务平台,如 Amazon Relational Database Service (Amazon RDS),或将应用程序迁移到完全托管的平台,如 Amazon Elastic Beanstalk

我们合作的一家大型媒体公司将其在本地运行的数百个 Web 服务迁移到了 AWS,在这个过程中,它从 WebLogic (一个需要价格高昂的许可证的 Java 应用程序容器) 迁移到了 Apache Tomcat (一个开源的等效容器)。除了从迁移到 AWS 所获得的成本节省和敏捷性,这家媒体公司还节约了数百万元的许可成本。

3. 重新购买 — 迁移到另一个产品。

我最常将重新购买视为迁移到 SaaS 平台。将 CRM 迁移到 Salesforce.com,将 HR 系统迁移到 Workday,将 CMS 迁移到 Drupal,诸如此类。

4. 重新构建 — 重新设想如何构建和开发应用程序 (通常使用云原生功能)。

这通常由增加功能、扩大规模或提高性能的强大业务需求推动,而这些需求可能在应用程序的现有环境中难以实现。

您是否希望从单体架构迁移到面向服务 (或无服务) 的架构以改进灵活性或业务连续性 (我听说了一些在 e-bay 上订购大型机风扇皮带的故事)?这种模式往往是成本最高的,但如果您具有良好的产品-市场契合度,它也可能是最有益的。

5. 停用 — 丢弃。

发现环境中的所有应用程序后,您可能会询问哪个职能领域拥有哪个应用程序。我们发现有多达 10% (我发现有 20%) 的企业 IT 产品组合不再有用,可以直接关闭。这些节省可以提高业务绩效,让您的团队将原本不足的精力放在人们使用的产品上,并缩小您必须保护的表面面积。

6. 保留 — 这通常意味着“重新访问”或什么都不做 (就目前而言)。

您可能仍然能够承受一些折旧,没有准备好为最近升级的应用程序设定优先顺序,或者不打算迁移某些应用程序。您只应迁移对业务有意义的应用程序;并且,随着产品组合的倾向从本地变为云,您保留应用程序的理由可能会更少。
您的迁移经验是什么?请一定告诉我并发表在我的博客上!

不断构建
– Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

注:“迁移”是我在“云优先之旅”系列中写到的四个“采用阶段”中的第三个。第一个阶段是“项目”。第二个阶段是“基础”。“迁移”之后是“改造”。本系列遵循最佳

 

 

云迁移的21个最佳实践

作者:Sadegh Nadimi                翻译:郝森

在过去的几年里,AWS专业服务团队已经指导和帮助企业完成数百个迁移项目。今年,我们建立了一个专门的专家团队,称作专业服务大规模迁移团队,专注于协助客户开始大规模迁移(数百个应用)。

客户经常困惑有哪些最佳实践,使应用快速稳健的迁移到AWS. 虽然每个企业的组织架构和业务目标不同,但是大规模迁移团队已经掌握一些模式和实践,帮助每种类型的企业。以下是一个不完全的清单:

迁移前阶段

1. 为未来IT和业务交集的部分,制定一个清晰的愿景。想象这个愿景将怎样影响组织的战略;更广泛的宣传,使大家明确的知道战略对组织非常重要。

2. 规划并分享一个云治理模型。识别更广泛的团队的角色和职责,满足企业信息安全的最小访问特权和职责分立等原则,保障企业目标的达成将有很长的一段路要走。它同样使增强安全管控纳入到更好的控制。在使内部用户进入使用云服务的洪流之前,需要回答很多问题。我应该有多少AWS帐户?谁可以使用什么?你怎么样授予权限?在云治理来临时,AWS可以告诉你每种方法的最佳实践、优势、限制。

3. 在此过程中,尽早的培训员工。团队掌握AWS的相关知识越多,迁移就越顺畅;内部的云布道师越多,就更容易的消除障碍。在组织做一个决定,即决定在AWS之上的最终IT全景视图,这些工作应该尽早展开。

4. 花时间和精力规划AWS之上的运维管理。研究需要调整的流程,有帮助的云运维工具,以及增强团队力量的各级别运维管理培训。思考那些使你关注更宏观图景的运维管理,确保你的环境与业务战略更好的协同。

5.了解当前拥有的IT资产,以及每批迁移中都包含哪些资产。这使你完全量化和衡量你的成功入云过程。花时间找到正确的资产发现工具,更新你的应用清单。这些使迁移规划较为顺畅,使迁移过程中忽略关联关系的风险最小化。

6. 为迁移之旅选择合适的合作伙伴。应该寻找那些既有技术技能和实施经验,又有灵活方法和项目管理框架的合作伙伴。你可能已经有一个具备云能力的合作伙伴,在选择之前,留出时间对合作伙伴进行审查,要求提供参考案例。思考你计划采用的云运维模型,合作伙伴是否可以帮助协同这个模型(建设持续交付持续集成管道,管理服务)。

迁移阶段

7. 从较小的和简单的开始。换句话说,选择一些速赢的方案。你的员工对使用AWS服务越舒服,那么干系人就会越快看到收益,那么在内部推动上就越容易。你需要做到持续和透明,我们已经看到很多组织通过一系列速赢方案而实现成功。

8. 自动化。云灵活性的实现有赖于自动化。花时间重新审视那些流程,并建立一些新的在迁移过程中有用的流程。如果不是所有的方面都能自动化,仔细决定哪些可以,让团队完成。

9. 把云当作转型。通过调整内部流程,使其拥抱技术变化。运用天然的转型优势,与干系人就新的工作模式达成协同。质疑那些总是说“我们一直这样做”的人。

10. 在可能的情况下,更多的运用全托管服务。比如包括Amazon RDS, AWS Directory Service, 和Amazon DynamoDB。由AWS处理日常的维护活动,使你的团队专注于你的客户事务。

迁移后阶段

11. 全面监控。当你的应用实现健壮的架构,综合监控战略将确保你得到所有的细节。考虑到效率和成本的相互制约,你的环境运行状况如何,数据驱动的洞察力将使你做出更聪明的业务决策。

12. 使用云原生的监控工具。在AWS上,有很多工具都可以提供应用级别的洞察和监控能力。运用最适合业务的工具,从长期看,运维人员将会感谢你,业务负责人也会拥有更清晰的数据为决策提供支持。

13. 采用AWS企业支持服务。AWS技术客户经理和帐单管家,是企业支持服务包的一部分,是非常有价值的资源。他们可以是你虚拟云团队的一部分,提供一个AWS中心接触点,和事件升级路径,同时也是技术信息和指导的宝贵资源。

大规模迁移(一次性迁移数百个应用)

14. 建立一个以迁移活动为中心,由团队、工具和流程组成的健壮的迁移工厂。在第一批迁移工作之前,记录并向组织分享相关细节。采用一个灵活的模式,加速应用迁移到AWS的过程;采用一个合适的保障措施,保障关键迁移里程碑的执行,防范相关风险,例如员工休假,或为特殊负载设计的工具发生故障。

15. 提供领导力以及设定迁移工厂的相关标准。考虑建立项目管理团队,总体管理迁移活动,保障合适的交流和沟通,以及变更过程。建立一个云卓越中心,作为撬动整个迁移工程的支点组织。卓越中心提供技术指导,或者更清晰的规定,它的成员自身也要参加迁移工程。总之,伴随迁移工厂,必须设立项目管理团队和卓越中心,确保迁移项目成功。

16. 在整体项目开始后,制定一个新团队成员加入流程。这其实是另外一种形式的培训。需要建立一个专门团队,评估和批准迁移工厂所用的工具。为了优化迁移结果,考虑任命一个更小的团队,在卓越中心之上,寻找对于自我环境中独特的工作效能和模式。鉴于敏捷批次的范围和节奏的不同,迁移可能是数月,甚至是数年才能完成。应该把迁移工厂看作持续发展和进步的一个有机体。

17. 明智的将有天赋的专家分布于敏捷批次团队。对于AWS服务和数据中心应用,确保有足够宽度上和广度上的能力,处理敏捷批次中遇到的小问题。如果在一个敏捷批次中没有合适的资源,可能导致不统一的决策,进而在后续敏捷迁移批次中产生混乱。

18. 当为一个特殊应用决定迁移策略时,考虑不同的标准。如考虑业务目标、路线图、风险情况、成本等。在高阶层次上,你可以决定保持现状平移应用入云,或者在模式上做一些调整。无论是哪种选择,尽可能采纳弹性和节约成本的最佳实践,并对支撑基础架构进行抽象。有一些共同选择是自动扩展、负载均衡、多可用区场景和准确容量估算的EC2实例。如果有意义,随时让你的团队采用AWS最佳实践,并尽快开始优化。

19. 找到模式并设计蓝图。在团队进行规划活动时,基于选定的战略,迁移模式将是确定的。针对这些模式,设计可重用的蓝图,将加快工作负载迁移的速度。不要忘记与迁移团队分享这些蓝图。这可以帮助进行迁移活动的同事,使他们专注于速度和效率,而不用为决定如何迁移有相似特征的应用而担心。

20. 应用测试。迁移工厂的一个关键活动是整合和验证部署到云端的工作负载。每一个应用组件将通过一系列预定义的和文档记录的测试。如果要求应用负责人在项目的早期就提供测试计划,将会比较顺利的得到业务负责人的签字通过。理想情况下,应该有一个模板,以供所有应用负责人提出特定的测试需求。这将帮助验证活动顺利执行,使业务负责人放心,他们的应用在AWS上运行与在数据中心中运行是类似的,甚至是更好的。

21. 确保将充分交流的文化灌输给所有相关团队。所有迁移决定需要清晰的文档记录和签字确认。提醒组织内的团队一个事实,即使是不直接和迁移相关的团队,系统会出现故障,以及潜在的新IP地址/URL直接引发流量。不要忘记通知可能访问该系统的任何第三方。

数据库迁移服务DMS——手把手教你玩转MongoDB到DynamoDB之间数据库迁移

1. 前言

AWS最近刚刚宣布了一项关于数据库迁移的新feature,支持Mongodb数据库作为源端,迁移到目标端Dynamodb中,这样可以使MongoDB的用户充分利用DynamoDB数据库提供的技术优势,譬如完全托管服务,高性能低延迟(毫秒级),精细化粒度控制等等。由于最近项目中涉及很多数据库迁移的事情,同时也对NOSQL数据库异构平台迁移非常感兴趣,写了这篇文档供大家参考。

2. DMS服务介绍

DMS作为数据迁移服务支持下面三种迁移类型:

  • 迁移源库中存在的数据到目标库
  • 迁移源库中存在的数据并且复制新增加的数据到目标库
  • 只复制新增加的数据库

数据迁移时源端和目标端设置

  • MongoDB作为源端

AWS DMS支持Mongodb作为源端的版本为2.6.x和3.0.x,MongoDB 作为一个基于文档存储的数据库,数据模式非常灵活,支持JSON和BJSON格式进行存储。当前AWS DMS 支持MongoDB作为源端以两种模式进行迁移,它们分别是文档模式和表模式。在文档模式中,需要设置参数extractDocID=true和nestingLevel=none,在复制时不支持collection的重命名。在表模式中需要启用表模式需要设置nestingLevel=one,另外在选择CDC时它不支持添加新的collection和重名collection。

  • DynamoDB作为目标端

使用Dynamodb作为目标端时需要配置partion key和Object mapping。

具体注意事项请参考官方文档链接:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html

3. 配置步骤

3.1 安装Mongodb

安装Mongodb的方式有多种方法,可以选择Marketplace或者AWS提供的cloudformation以及手动下载Mongodb软件进行安装,我选择手动安装Mongodb2.6.12版本。

A、登录EC2,获取如下软件:

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-mongos_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-tools_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-server_2.6.12_amd64.deb

ubuntu@ip-172-31-60-214:~$ wget http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/mongodb-org-shell_2.6.12_amd64.deb

B、安装软件包:

ubuntu@ip-172-31-60-214:~$ sudo dpkg -i mongodb-org*

C、创建数据目录和日志目录:

ubuntu@ip-172-31-60-214:~$ sudo mkdir /data /log

D、启动mongodb数据库服务:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –logpath /log/mongodb.log –smallfiles –oplogSize 50 –fork

打开mongodb的shell, 验证服务启动成功。

ubuntu@ip-172-31-60-214:~$ mongo

MongoDB shell version: 2.6.12

connecting to: test

如下图所示:

3.2 通过脚本生成数据

for (var i = 1; i <= 793308; i++) {

               db.testData.insert( { x : i , name: "MACLEAN" , name1:"MACLEAN", name2:"MACLEAN", name3:"MACLEAN"} )

db.contacts.insert( { name: "Amanda", status:

"Updated" } )

db.contacts.insert( { name: "tom", status: "Updated" } )

db.contacts.insert( { name: "jack", status: "Updated" } )

db.contacts.insert( { name: "jack1", status:    "Updated" } )

db.contacts.insert( { name: "steph", status:    "Updated" } )

3.3 验证数据生成

运行如下命令:

3.4配置mongodb的副本集

A、启动mongodb数据库

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork

如下图:

B、登录到mongodb中,进行副本的初始化,如下图所示:

ubuntu@ip-172-31-60-214:~$ mongo localhost

MongoDB shell version: 2.6.12

connecting to: localhost

>

rs.initiate()

C、验证部署配置

> rs.conf()

D、创建管理员角色

rs0:PRIMARY> use admin

switched to db admin

rs0:PRIMARY> db.createUser(

…   {

…     user: “root”,

…     pwd: “rootpass”,

…     roles: [ { role: “root”, db: “admin” } ]

…   }

… )

如下图所示:

E、停止mongodb,然后重启mongodb:

ubuntu@ip-172-31-60-214:~$ sudo mongod –dbpath /data –replSet rs0 –logpath /log/mongodb.log –smallfiles –oplogSize 50 -fork –auth

如下图所示:

至此,Mongodb的数据库准备工作完成。

3.5 使用global账号登录到DMS服务,如下图所示:

A、创建复制实例:

指定Name,Instance class,Allocated storage,VPC选择创建,如下图所示:

创建mongodb源端的Endpoint,输入Endpoint identifier,Source engine指定为mongodb,Servername为Mongodb数据库主机IP,Port,Authentication mode,username等信息,如下所示:

注意在高级设置中指定extraDocID=true;nestingLevel=none

点击test connection验证连接成功。

点击创建完成。

B、创建目标端DynamoDB的endpoint

在endpoint console中选择create endpoint,并输入信息:Endpoint identifier,Endpoint type为Target,Target engine为dynamodb,指定Service Aceess Role ARN,并在advanced中设置:extractDOcID=true;nestingLevel=none

如下图所示:

点击test connection,验证成功,选择create 完成创建。

此处主要角色的设置需要指定:dms-vpc-role,同时attached 3个policy,如下图所示:

endpoint创建完成,如下所示:

C、创建task

点击create task,输入如下信息:task name,source endpoint,target endpoint,migrate type,Enable loging,同时根据实际需求进行相应的任务设置。

创建table mappings,点击json tab,进行手动输入设置:

注意,json文件内容需要根据各自创建的表进行手动创建。

点击创建任务,任务创建完成。

D、验证数据导入成功

返回任务列表,选择table statistics,查看表的导入是否成功,如下图所示:

MongoDb记录成功导入到dynamodb中,选择log可以通过cloudwatch查看DMS导入过程的记录。

登录到DynamoDb中,发现表成功创建,并且导入成功,如下图:

至此整个利用DMS进行Mongodb到Dynamodb的数据库迁移完成。

关于如何设置Table mapping 请参阅官方文档:

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.DynamoDB.html

附录

测试中我使用的Table Mapping json内容如下:

{

            "rules": [

                        {

                                    "rule-type": "selection",

                                    "rule-id": "1",

                                    "rule-name": "1",

                                    "object-locator": {

                                                "schema-name": "test",

                                                "table-name": "%"

                                    },

                                    "rule-action": "include"

                        },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "contacts"

        },

        "target-table-name": "contacts",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "3",

          "rule-name": "TransformToinventory",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "inventory"

        },

        "target-table-name": "inventory",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToEC2test",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "ec2Test"

        },

        "target-table-name": "ec2Test",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            },

            {

          "rule-type": "object-mapping",

          "rule-id": "2",

          "rule-name": "TransformToDDB",

          "rule-action": "map-record-to-record",

          "object-locator": {

            "schema-name": "test",

            "table-name": "testData"

        },

        "target-table-name": "testData",

        "mapping-parameters": {

        "partition-key-name": "id",

        "exclude-columns": [

        "_id"

        ],

        "attribute-mappings":[

          {

            "target-attribute-name": "id",

            "attribute-type":"scalar",

            "attribute-sub-type":"string",

            "value": "${_id}"

          }

        ]

        }

            }

  ]

}

 

作者介绍

王友升

AWS解决方案架构师,拥有超过13年的IT从业经验,负责基于AWS的云计算方案架构咨询和设计,推广AWS云平台技术和各种解决方案。在加入AWS之前,曾在中地数码,浪潮,惠普等公司担任软件开发工程师,DBA和解决方案架构师。在服务器,存储,数据库优化方面拥有多年的经验,同时对大数据,Openstack及AI方面也进行一定的研究和积累。

AWS Snowball Edge——更多存储容量、本地端口与Lambda函数

正如在之前的文章中已经提到,我们于去年推出了AWS Snowball服务(AWS Import/Export Snowbal——利用Amazon提供的存储设备一周内传输1 PB数据),并随后对各项相关更新进行了整理。总体而言,Snowball服务最初是一台50 TB数据传输设备,其设计目标在于强调物理接入及数据安全等要求。一年之后,这项服务的存储容量有所提升,目前达到80 TB,同时还增加了任务管理API、HIPAA认证、HDFS导入与S3适配机制,同时亦可用于更多AWS服务区。

不过最重要的是,这些改进并不会影响该设备的基本特性。一年以来,众多AWS客户将初代Snowball应用于不同类型的物理环境当中,并借此实现包括大数据、基因组学以及数据收集在内的各类工作负载的迁移工作。我们发现这款设备还拥有更为广泛的施展空间。

很多客户掌握着规模庞大且增长速度极快的数据集(通常达数百TB),而其网络连接能力无法将这些数据及时上传至云端,同时现有物理环境则几乎达到极限。客户们希望收集产生自农田、工厂、医院、飞机乃至油井中的数据——从车间监控到视频摄制再到物联网设备信息收集。客户希望能够利用单一模式实现高度简化的数据存储与转发,并在数据到达时进行本地处理。他们希望在数据到达时对其进行过滤、清理、分析、组织、追踪、总结以及监测。他们希望扫描输入数据以掌握其模式或者存在的问题,而后在发现特定情况时快速发出通告。

全新Snowball Edge

现在,我们将Snowball Edge正式加入AWS阵容。这款设备扩展了Snowball的适用范围,其中包含了更多连接方式、存储资源、集群化横向可扩展性,可立足现有S3与NFS客户端进行接入的存储端点以及Lambda支持下的本地处理功能。

从物理角度讲,Snowball Edge的设计目标在于提供一套适用于工业、航空航天、农业以及军事类用例的环境。其新的外形设计亦可实现机架内安装,从而帮助大家发挥其中新增的集群化功能。

下面就让我们看看Snowball Edge带来的各项新特性!

更多连接选项

Snowball Edge拥有出色的连接能力,允许大家从多种高速选项中做出选择。在网络方面,大家可以使用10GBase-T、10或25 Gb SFP28或者40 Gb QSFP+。您的物联网设备能够利用3G蜂窝网络或者Wi-Fi向其中上传数据。如果这还不够,Snowball Edge还提供了一个PCIe扩展端口。

如此丰富的连接选项允许大家以高达每秒14 Gb的速度将数据复制至Snowball Edge当中; 这意味着复制100 TB数据仅需要19小时左右。而从开始到结束,整个导入周期(即由初始数据传输到数据实现S3内可用)大约需要一周,其中包括设备寄送及后续处理的时间。

更高存储容量

Snowball Edge包含100 TB存储容量。

通过集群化方式实现横向扩展

大家可以轻松将两台或者更多Snowball Edge设备配置至单一集群当中,从而提升存储容量及耐用性,同时继续通过单一端点访问全部存储内容。举例来说,将六台设备进行集群化对接将能够提供一套存储容量达400 TB的集群,其耐用性可达99.999%。这意味着大家能够移除其中两台设备而数据仍受到严格保护。

大家还可将该集群扩展至PB级别,并通过简单移除及接入设备实现规模伸缩。此类集群拥有自我管理能力,大家不需要考虑其软件更新或者其它维护工作。

要构建这样一套集群,大家只需要在设置任务时勾选“Local compute and storage only(只使用本地计算与存储)”选项并随后勾选“Make this a cluster(将此创建为集群)”即可,具体如下图所示:

新的存储端点(S3与NFS)

如果您已经拥有某些备份、归档或者数据传输工具,例如S3或者NFS,那么大家可以利用其直接立足Snowball Edge实现数据存储及访问。如果大家创建一套包含两台或者更多设备的集群,则同一端点将可适应于其中全部设备; 这意味着大家能够将这类集群视为本地网络附加型存储资源。

Snowball Edge支持一组强大的S3 API子集,其中包括LIST、GET、PUT、DELETE、HEAD以及Multipart Upload。其同时支持NFS v3与NFS 4.1。

在利用Snowball Edge作为文件存储网关并通过NFS进行访问时,文件与目录元数据(包括对应权限、所有关系以及时间戳)都将被映射至S3元数据,并在数据被存储至S3内时得以保留。大家可以利用这一特性进行数据迁移、引导AWS Storage Gateway(存储网关)或者存储内部文件以在各内部应用间实现共享。

Lambda支持的本地处理

大家现在可以利用Python编写AWS Lambda函数并利用其处理通过Snowball Edge上传至S3存储桶内的数据。

这些函数能够(正如之前所提到)在数据到达时对其进行过滤、清理、分析、整理、追踪以及总结。Snowball Edge允许大家向数据收集及数据处理系统当中添加智能化与高复杂度功能。

我们初步支持S3 PUT操作,且大家可以将同一条函数应用于每个存储桶。各函数必须由Python编写,且运行在配置有128 MB内存的Lambda环境当中。

在订购Snowball Edge的同时,大家即可进行函数配置:

我们建议大家首先在云端对函数进行测试,而后再将其加入订单。

价格与上线时间

Snowball Edge在设计上允许进行即插即用式部署。您的现场同事不需要对其进行额外配置或者管理。其配备的LCD显示面板能够提供状态信息并播放设置视频。内置代码能够自动更新; 意味着其不需要进行例行软件维护。大家可以通过AWS管理控制台(亦可通过API及CLI访问)检查其状态并对已部署设备进行最新配置变化查询。

每台Snowball Edge的服务周期价格为300美元,寄送成本另计。大家保留每台设备的最长时限为10天; 在此之后,您需要每天支付30美元。大家可以以本地方式运行Lambda函数而不必承担任何费用。

原文链接:

https://aws.amazon.com/cn/blogs/aws/aws-snowball-edge-more-storage-local-endpoints-lambda-functions/

使用DMT工具迁移北京区域的数据库

在前面的blog《将Oracle数据库迁移到AWS云的方案》中谈到了多种将Oracle数据库从数据中心迁移到AWS云中的方法。其中 使用DMS服务迁移的方法简单实用,也支持异构数据库的迁移,很多朋友都想使用这种方法完成迁移。但是在北京区域不支持DMS服务,如何实现类似的迁移工作呢?其实在北京区域支持使用Database Migration Tool(DMT)来迁移数据库,DMT工具是DMS服务的前身,它是安装在Windows上的一个软件,迁移前只需要获取DMT工具的AMI,然后简单的配置后,就可以进行数据迁移了。本文主要讨论如何使用DMT将Oracle迁移到Amazon RDS数据库,示例的场景如下图所示:

在建立客户本地数据中心与AWS连接的时候,考虑到安全性问题,我们建议您通过VPN或者企业专线来建立数据库之间的连接,您只需确保您本地数据库端口(例如Oracle端口1521)对外可访问。如果您的业务对安全性要求较高,需要传输的数据量较大,同时,要求以较快速度传输的时候,可以采用专线迁移,但是这种方法成本较高,您需要根据您的业务需求来选择是通过VPN还是企业专线迁移。

在介绍DMT数据库迁移之前,我们首先介绍一下DMT迁移工具支持的数据库类型以及对源和目标数据库的限制:DMT目前支持将Oracle、SQL Server、MySQL、SAP Sybase以及PostgreSQL作为源或目标数据库,您也可以将Amazon Redshift作为您的目标数据库。同时,DMT也支持异构数据库的迁移,例如将Oracle迁移到MySQL。

DMT工具为我们迁移数据库提供了巨大的便利,然而,它也有一些限制条件,下表主要介绍DMT支持的三种常用关系型数据库版本以及相关限制条件。如果您需要了解更多有关DMT迁移数据库信息,请参考DMT用户手册:

https://s3.cn-north-1.amazonaws.com.cn/rdmt/RDS+Migration+Tool+User+Guide.pdf

使用DMT迁移主要有下面几个步骤:

(1)获取DMT的AMI

(2)启动DMT的AMI

(3)登陆DMT服务器

(4)配置服务器

(5)访问DMT工具

(6)迁移数据

1.获取DMT的AMI

如果您有数据库数据需要导出或者导入到AWS 北京区域中,首先您需要获取DMT的AMI镜像,然后根据镜像启动EC2服务器。获取DMT的镜像有两种方式:

(1)和支持您当前AWS账号的商务人员联系,他能帮您在后台申请访问DMT AMI的权限。

(2)您也可以自己在Support Center 中开case。在AWS Console中访问Support Center的方式如下图所示:

2.启动DMT的AMI

当您有能访问DMT的AMI以后,登陆您的AWS账号,进入Services->EC2->AMI的界面,选择“Private images”列表,就可以看到有一个Amazon_RDS_Migration_Tool的记录,这就是最新的迁移工具,如下图所示:

选择DMT点击上方的“Lunch”按钮,启动一个已经安装好DMT工具的服务器。接下来您需要配置您实例的类型、大小、实例所在VPC以及安全组和密钥等信息。具体配置步骤请参考官方文档:http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EC2_GetStarted.html

需要注意的是:

(1)在选择DMT服务器所在VPC的时候,尽量选择源或者目标数据库所在的VPC创建DMT服务器,这样可以加快迁移的速度。

(2)在配置安全组的时候,您的安全组应该允许RDP协议和https协议。由于DMT服务器是Windows Server服务器,因此您需要使用Windows远程桌面连接访问,此时需要RDP协议,source指定当前需要连接客户端的IP或者IP段。DMT工具可以通过浏览器来访问,因此需要设置https协议的安全组,如下图所示:

3.登陆DMT服务器

启动DMT服务器,并下载私钥后,就可以登陆DMT服务器了,如下图所示,当您的服务器状态显示为running,并且通过健康检查后,您的服务器就可以正常访问了。如下图所示:

选择您的DMT服务器,然后点击Connect,显示如下界面:

在此步骤中,您需要根据下载的私钥获取登陆Windows的密码。点击 get Password,显示如下图所示界面:

输入您前面下载的私钥的文件全部内容,点击 Decrypt Password后,您在界面上可以看到Administrator的密码,请记录下这个密码。下面就可以登陆服务器了。

本例中是使用MAC的Windows远程终端软件来访问DMT服务器,如果您使用Windows客户端,访问过程类似,输入远程DMT服务器的DNS名称,输入用户名和密码并连接。

连接上DMT终端后,您会看到Windows Server 2012的桌面如下图所示,桌面上有DMT工具。

连接到远程终端后,您可以根据需要修改访问Windows的密码,修改密码可以在控制面板中完成,界面如下:

4. 配置服务器

登陆到DMT服务器后,在界面上有Database Migration Tool Documentation的目录,进入目录并下载QuickStart Guide.下载过程中如果出现如下错误,请添加授信站点或者配置服务器解决错误。

下载Quick Start Guide和PDF阅读软件。

打开QuickStart Guide如下图所示,您可以按照您数据库的类型(Oracle, MySQL等)选择相应的驱动程序。

本例中由于迁移的是Oracle数据库,安装Oracle的驱动和客户端相对复杂,下面会详细解释如何安装Oracle驱动,其他驱动的安装请参考文档。点击Quick Start Guide中的Oracle Instant Client后面的链接后,出现如下界面(需要您有Oracle账号才能下载软件):

下载Instant Client Package-Basic: All files required to run OCI….的文件,也就是上图第一个黄色方框中的文件。

下载Instant Client Package-ODBC驱动,如上图第二个黄色方框。由于DMT安装在Windows Server上,因此有很多安全的限制,如果遇到禁止下载的错误,可以参照下图:

选择Internet,然后点击Customer level。

选择Downloads,然后Enable下载,就可以正常下载Oracle的软件了。

下载完成后,basic和odbc的包如上图所示。

创建 c:\oracle目录,将目录作为解压的目录,选中 basic-windows的文件,然后解压到oracle目录,如下图示:

选中odbc的压缩包,然后解压到c:\oracle

解压后的文件目录结构大致如下:

选中 odbc_install.exe并运行,如下图:

选择run,默认没有反应是正常状态 。

将变量 C:\oracle\instantclient_12_1添加到Path变量中,如下图所示:

增加TNS_ADMIN变量如下图所示:

在本例中,增加的变量TNS_ADMIN和变量Path的值相同。

5.访问DMT工具

先使用界面上的工具Stop Amazon RDS Migration Service停止DMT服务。这样避免刚才设置的环境变量没有应用DMT工具中。

在点击在桌面点击下面图标启动DMT服务。

启动后,如果见到下面的窗口:

表示启动成功。

选择图标就可以启动DMT的Web访问客户端,如下图所示:

见到Console的界面,表示DMT服务启动成功。DMT的console可以在服务器上访问,也可以在客户端访问,在外网访问只需要获取到DMT服务器的Public DNS,使用下面格式URL从外网访问DMT console。

https://your-public-dns/AmazonRDSMigrationConsole

访问console后,会弹出如下界面,输入访问windows的用户名和密码。

输入登陆系统的用户名和密码并登陆,显示如下界面:

在界面中使用Manage Database创建Source和Target数据库,创建Task就可以开始迁移您的数据库了。

6.使用DMT迁移数据

当您通过前面的步骤能够正确地访问DMT工具,说明配置基本成功,下面就可以通过DMT迁移您的数据库了。

Step1: 配置源数据库连接信息

点击上图中的Manage Databases->Add Database,输入数据库类型为Oracle,填好具体URL及数据库的Role信息,示例信息如下:

参数说明:

Name:给需要迁移的数据库定义一个名称,可以根据需要定义。

Description:给需要迁移的数据库一个详细的描述。

Role:需要迁移数据库的角色,如果是迁移中的源数据库,则选择SOURCE,如果是迁移中的目标数据库,则选择TARGET.

Connection String:对于传统Oracle数据库的格式为 ip:port/sid

User name:数据库连接的用户名

Password:数据库连接的密码

Step2: 配置目标RDS数据库连接信息

配置目标RDS数据库信息如下:

RDS的Connection String的格式为:

<database-name>.<rds-endpoint>:<port>/<sid>

Step 3:检查Source和Target数据库的归档模式和Supplemental Log

由于DMT工具可以捕捉数据库日志,将源数据库的变化复制到目标数据库,这种复制方式要求源和目标数据库都是归档的数据库,并且需要Supplemental Log的设置。

使用SQL PLUS连接源数据库,如果数据库处于非归档模式,则将数据库改为归档模式。

运行下面语句,修改Supplemental Log设置:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

使用Oracle SQL Developer或者其他客户端工具连接RDS目标数据库,运行下面的语句:

exec rdsadmin.rdsadmin_util.alter_supplemental_logging(‘ADD’);

Step 4:创建Task

在主界面上点击“New Task”,如下图所示:

Task options: 定义复制的类型,Full Load表示将当前的表和数据拷贝到目标数据库。Apply Changes表示将当前时刻到停止复制前的日志变化同步到目标数据库。如果两个都选择,表示同步数据,并将捕捉到的数据库变化复制到目标数据库。

Step 5:定义Task

将Source和Target数据库的图标,拖入到左边的流程图中,如下图所示,我们定义了将OracleSourceDB复制到RDSDatabase中。

定义好流程后,点击Table Selection选择需要复制哪些表。如下图所示:

在此图中,我们复制的是TEST.T_USERS表。您也可以使用Patterns的方式匹配表名。

点击Task中的Run按钮,很快数据库就开始迁移了。

7. 错误诊断

(1)如果在测试数据库时出现oci.dll无法加载的错误,如下图所示:

这个错误一般说明你没有将instance client的路径配置到path变量中去。此时只需要配置好变量,然后停止并启动DMT服务就可以了。

(2)ORA-12170: TNS: Connect timeout occurred [122307] OCI error.

如果出现此错误,说明DMT工具连接数据库超时,此时请检查RDS数据库的Security Group是否开启了DMT服务器的1521端口的访问,或者检查数据库的防火墙等网络设置,确保DMT服务器能够正常访问Oracle服务器。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

杨婉洁

亚马逊AWS解决方案架构师实习生,喜欢编程,熟悉Java、C++、JSP、HTML以及关系型数据库。曾在学校和企业参与数据分析项目,熟悉各类数据分析的算法。热爱大数据、云计算。

使用Oracle Data Pump将数据库迁移到AWS的RDS Oracle数据库

1.Oracle数据库的迁移方法

如何将Oracle数据库从数据中心迁移到AWS云上是DBA经常遇到的问题,迁移Oracle数据库有多种方式:

(1)使用AWS DMS服务迁移

(2)使用Oracle SQL Developer迁移

(3)使用Oracle Data Pump迁移

(4)使用Oracle Export/Import迁移

(5)使用Oracle SQL Loader迁移

如果需要了解不同的迁移方法,可以参考 博客《Oracle数据库迁移到AWS云的方案》 。

2.使用Oracle Data Pump迁移

本文主要讨论使用Oracle Data Pump将Oracle数据库迁移到RDS数据库。示例数据库的信息如图。

 

下面是模拟在数据中心的Oracle11g源数据库中创建用户和表,并将源数据库迁移到AWS云中RDS Oracle 11g数据库的全过程。

步骤一:初始化源数据库并使用Data Pump导出

(1)使用SQL Plus登录源Oracle数据库

sqlplus / as sysdba

(2)创建用户test

create user test identified by welcome1;

(3)为新创建用户grant权限(实际使用请给用户grant合适的权限)

grant dba to test;

(4)为用户test创建表

create table test.aa(id varchar(20) not null primary key,name varchar2(30));

(5)为表插入数据并commit

SQL> insert into test.aa values(‘1111′,’1111name’);

1 row created.

SQL> insert into test.aa values(‘2222′,’2222name’);

1 row created.

SQL> commit;

Commit complete.

(6)在源数据库所在的Linux上逐级创建下面文件目录

mkdir /home/oracle/datapump/datafiles

(7)在SQLPlus中创建数据库Directory

create directory dpump_dir as ‘/home/oracle/datapump/datafiles’;

grant read,write on directory dpump_dir to test;

(8)使用expdp命令导出test用户的所有表

expdp test1/welcome123 directory=dpump_dir dumpfile=test.dmp

expdp test1/welcome123 directory=dpump_dir dumpfile=test1.dmp

步骤二:使用SQL Plus连接RDS数据库,并创建数据库目录对象

(1)在源数据库上配置RDS数据库的tnsnames

cd $ORACLE_HOME/network/admin

vi tnsnames.ora

输入tnsnames的内容如下:

ORARDS=(description=(address_list=(address = (protocol = TCP)(host =    RDS_HOST_NAME)(port = RDS_PORT)) )(connect_data =(SID=RDS_SID)))

(2)使用SQLPLUS连接远程RDS数据库

sqlplus oracle/welcome1@ORARDS

(3)使用tnsping检查RDS连接信息

如果连接有错误,可以使用下面命令查看通讯是否正常

tnsping “(description=(address_list=(address = (protocol = TCP)(host = RDS_HOST_NAME)(port = RDS_PORT)))(connect_data =(SID= RDS_SID)))”

tnsping应该返回“OK (xx msec)”类似文字。

如果tnsping不通请检查RDS对应的security group,RDS的security group中应当允许当前服务器通过TCP协议访问RDS数据库的端口。

(4)创建目标RDS的directory对象

exec rdsadmin.rdsadmin_util.create_directory(‘dpump_dir1’);

创建成功后退出连接RDS的SQL Plus客户端。

步骤三:将源数据库Data Pump导出的文件上传到RDS数据库

(1)连接源数据库并创建database link

create database link to_rds connect to oracle identified by welcome1 using ‘(description=(address_list=(address = (protocol = TCP)(host = RDS_HOST_NAME)(port = RDS_PORT)))(connect_data =(SID=RDS_SID)))’;

(2)运行DBMS_FILE_TRANSFER包将数据传输到RDS服务器的目录

BEGIN

DBMS_FILE_TRANSFER.PUT_FILE(

source_directory_object       => ‘dpump_dir1’,

source_file_name              => ‘test.dmp’,

destination_directory_object  => ‘dpump_dir1’,

destination_file_name         => ‘test.dmp’,

destination_database          => ‘to_rds’

);

END;

步骤四:通过impdp命令将远程的RDS数据库文件导入

(1)在源数据库服务器上运行impdp命令导入数据

impdp  oracle@ORARDS dumpfile=test.dmp directory=dpump_dir1 full=y

执行完毕检查test用户和相关的表。

3.    总结

从上面的过程我们可以看到,将一个Oracle数据库迁移到RDS的过程并不复杂,如果源数据库很大,由于需要导出数据、将数据上传到RDS的Data Pump目录、导入数据,迁移的过程也会比较长。上述过程假设了我们生产数据库的业务有足够的停机时间,在迁移过程中数据不会变化。如果迁移过程中,源数据库会发生变化,那么我们就需要同步数据中心和RDS数据库间的日志了。

如果源数据库很大,我们也可以在AWS上启动一台中间服务器,并在中间服务器上安装Oracle的客户端软件,将源数据库的Data Pump导出文件分片然后scp复制、Tsunami UDP加速上传等方式将文件上传到中间服务器,然后上传到RDS的Data Pump目录,这样能加速迁移的过程。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

使用AWS的数据库迁移DMS服务

前面博客《Oracle数据库迁移到AWS云的方案》介绍了AWS数据库迁移的几种基本方法,本文主要介绍如何使用AWS的DMS服务完成数据库的迁移。

1.DMS服务介绍

为了使用户更容易的将数据库迁移到云中,AWS已经在海外区域推出了AWS Database Migration Service服务,如果您的数据库在海外,DMS可以在源数据库不停机的情况下,帮您将数据迁移到AWS云中。DMS的功能非常强大,支持同构数据库的迁移(如Oracle迁移到Oracle),也支持异构数据库直接的迁移,如Oracle到Mysql等)。在数据库迁移期间,源数据库无需停机,并且能将迁移期间数据的更改持续复制到目标数据库。因此迁移完成后,您只需在短暂的停机时间内直接切换数据库,从而保证业务数据的完整性。
在中国BJS区域,还没有推出DMS服务,但是提供了Database Migration Tool(DMT)工具,您可以使用DMT工具来完成数据库迁移。

2.使用DMS完成迁移

使用DMS服务必须确保源或目标数据库有一个在AWS云中。 使用DMS服务的步骤如下:

步骤一:Create migration

登陆AWS全球区域的Console,选择DMS,点击“Create migration”,我们便来到了“welcome”界面,从该界面我们可以看到,通过DMS进行数据迁移我们至少需要一个源数据库、目标数据库和复制实例。当然,DMS 也支持多个源数据库向一个目标数据库的迁移以及单个源数据库向多个目标数据库的迁移。迁移时,数据通过一个运行在复制实例上的任务将源数据库复制到目标数据库。点击“Next”进行复制实例的创建。

步骤二:创建“Replication Instance”

您在进行数据库迁移过程中的第一个任务是创建具有足够存储空间和处理能力的复制实例,通过复制实例来执行您分配的任务并将数据从您的源数据库迁移到目标数据库。此实例所需的大小取决于您要迁移的数据和您需要执行的任务量。具体配置参数见下表1。

如果您需要为网络和加密设置值,请选择高级选项卡。具体参数见表2。

步骤三:创建数据库连接

当您在创建复制实例时,您可以指定源和目标数据库。源数据库和目标数据库可以在AWS的EC2上,也可以是AWS的关系数据库服务(RDS)的DB实例或者本地数据库。在设置源和目标数据库时,             具体参数可以参见表3。您也可以通过高级选项卡来设置连接字符串和加密密钥的值。

等图示上部分的显示变成”Replication instance created successfully”并且“Run test“按钮变成正常,然后测试,确保测试结果为”Connection tested Successfully”,由于需要从AWS服务端连接测试数据库,因此需要设置好security group,设置的security group必须确保复制实例能够访问源和目标数据库。需要的话,可以短暂的将security group 1521 的访问设置为 0.0.0.0/0,测试成功后,点击”Next”按钮。

步骤四:创建“task”

当源数据库和目标数据库建立连接后,您需要创建一个任务来指定哪些表需要迁移,使用目标架构来映射数据并且在目标数据库中创建新表。作为创建任务的一部分,您可以选择迁移类型:迁移现有数据、迁移现有数据并复制正在进行的更改,或只复制更改的数据。

如果选择”Migrate existing data and replicate data changes”选项需要打开Task Settings 中的supplemental loging开关。在Table Mapping中Schema to Migrate选择“Oracle”,点击“Create Task”。

当您创建的task状态从creating变为ready的时候,您的task便创建好了。点击该“task”并点击上方的“Start/Resume”,您数据迁移任务便开始了!

数据库迁移完成后,目标数据库在您选择的时间段内仍会与源数据库保持同步,使您能够在方便的时候切换数据库。

3.总结

从上面过程我们可以看到,只需要简单的配置,DMS就可以帮助我们完成数据库的迁移任务,并且DMS服务是免费的,迁移过程中用到的资源是收费的。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

Oracle数据库迁移到AWS云的方案

当前云已经成为常态,越来越多的企业希望使用云来增加基础设施的弹性、减轻基础设施的维护压力,运维的成本等。很多企业使用云碰到的难题之一是如何将现有的应用迁移到云上,将现有应用的中间件系统、Web系统及其他组件迁移到云上相对容易,一般只需要重新部署或复制即可,但如何将数据库迁移到AWS云中,是很多企业需要面对的一个难题。由于数据库的种类繁多,本文将以Oracle数据库为例,介绍将数据中心的Oracle迁移到云中的基本知识,不同方法涉及的迁移过程,请参考后续的博客。

1.云中数据库的模式

如果要在云中使用Oracle数据库,有两种选择:

  • EC2服务器模式

使用AWS的EC2服务器,在EC2服务器上手工安装Oracle数据库软件,用户需要自己准备Oracle的License,这和用户自己在机房安装Oracle数据库类似。如果在中国以外的区域,用户也可以使用AWS Marketplace里面的不同版本的Oracle镜像,直接初始化Oracle数据库,这种情况你也需要自己准备Oracle的License。

  • RDS模式

Amazon Relational Database Service (Amazon RDS) 是一种 AWS提供的Web 服务,可以让我们更轻松地在云中设置、 操作和扩展关系数据库,减少管理关系型数据库复杂的管理任务。RDS包括了Oracel、SQL Server、My SQL,等多种数据库引擎,你可以根据需要选择数据库的类型。

根据我们使用模式的不同,能选择的迁移方式也不同。

2.逻辑迁移和物理迁移

数据库的迁移可以分为逻辑迁移和物理迁移两种方式:

  • 逻辑迁移

逻辑迁移一般只是迁移数据库表、视图及其它数据库对象,不要求源库和目标库在底层的存储及表空间完全一致。逻辑迁移适用于EC2服务器模式和RDS模式。

逻辑迁移一般使用Dump/Load+Log Apply的方式,使用Dump工具将数据库对象从源数据库导出,然后Load到目标数据库,最后根据需要同步数据库日志。

  • 物理迁移

物理迁移可以让迁移的源库和目标库在底层的存储文件、存储介质、表空间、用户等信息完全一致。物理迁移适用于EC2服务器模式。

物理迁移(Oracle)一般是使用RMan等物理备份+Log Apply的方式,使用RMan等工具备份数据库,然后在目标系统还原数据库,最后根据需要同步日志。

3.日志同步

在迁移数据库过程中,如果我们的业务有足够停机时间,可以将源数据库设置成只读数据库,然后使用Dump/Load或者备份/还原的方式来创建目标库。因为源库是只读的,迁移过程中源库不会发生变化,因此只需要根据源库数据创建目标库,无需日志的同步。

在迁移数据库过程中,如果我们的业务没有足够的停机时间,此时除了要使用Dump/Load或备份还原的方式迁移已有数据,还需要将迁移过程中变化的数据同步到目标数据库,此时需要日志同步的工具。

4.Oracle数据库同步的方法

将Oracle数据库迁移到AWS云中主要有下面几种方法:

迁移Oracle数据库有多种方式,本文主要介绍以下五种,这五种方式都是逻辑迁移:

(1)使用AWS DMS服务迁移

AWS在中国以外的区域提供了数据库迁移DMS服务,支持同构和异构数据库间的迁移,也支持日志的同步。在中国区可以使用AWS提供的DMT(Database Migration Tool)工具完成同构或异构数据库间的迁移。

DMS适合于迁移中小型的数据库。

(2)使用Oracle SQL Developer迁移

Oracle提供的SQL Developer工具里面提供了迁移功能,适合于迁移数据较少的数据库。SQL Developer可以在Oracle的官网里免费下载。

(3)使用Oracle Data Pump迁移

使用Oracle Data Pump工具将数据库导出,复制数据到目标平台,最后使用Data Pump将数据导入到目标数据库。数据量较大或数据少的库都可以使用这种方式。

(4)使用Oracle Export/Import迁移

这种方式和Oracle Data Pump方式类似,需要使用Oracle导入/导出实用工具。

(5)使用Oracle SQL Loader迁移

使用Oracle SQL Loader的方式可以让数据导入的过程更快、效率更高。

5.日志同步的方法

如果要实现不停机的迁移,就需要使用日志同步的工具,Oracle数据库支持多种不同的工具同步日志:

  • DMS同步日志

AWS的DMS服务有同步日志的选项,可以使用DMS来同步日志。

  • GoldenGate工具

可以使用Oracle的GoldenGate工具,支持同步日志到EC2上的Oracle服务器和RDS数据库。

  • 其它第三方日志复制工具

根据数据库的使用情况,我们也可以尝试其他第三方的同步工具,如SharePlex等。

6.总结

我们在将数据库从数据中心迁移到AWS云的时候,需要根据数据库的大小、业务允许的停机时间、网络的带宽等多种因素选择我们的迁移方案,每种迁移的具体步骤请参考后续博客。

作者介绍:

蓝勇

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。