亚马逊AWS官方博客

Tag: 迁移

加速您的云迁移和 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 分享了其成果 (视频),并且我们已对许多其他客户使用这些捷径。 它们是: 第 […]

Read More

将应用程序迁移到云的 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。 我们合作的一家大型媒体公司将其在本地运行的数百个 […]

Read More

云迁移的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上运行与在数据中心中运行是类似的,甚至是更好的。 […]

Read More

数据库迁移服务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 […]

Read More

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 […]

Read More

使用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 […]

Read More

使用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 […]

Read More

使用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.总结 […]

Read More

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将数据导入到目标数据库。数据量较大或数据少的库都可以使用这种方式。 […]

Read More