标签: 迁移

AWS迁移案例之Oracle数据库迁移

项目背景

某安全APP是一款可以隐藏图片、视频等私人信息的安全类应用,运营超过10年,全球用户已超过1亿。

 

面临的挑战

随着业务的发展和移动端用户数量的快速增长,自建数据中心不能够很好的满足业务系统的需要,给该公司带来了很多IT挑战:Oracle 数据库的大小不断增长,要维护的数据库成本也在不断攀升,由此造成扩展难题,Oracle 数据库备份、可用性等问题。

 

迁移的难点

  • 人员有限

客户运维人员少,缺乏自动化迁移手段

  • 数据量大

Oracle数据库超过4.5TB,数据库表清理优化难度高;

  • 时间紧

需要在一个月内完成迁移

 

 

解决方案

神州泰岳的云迁移团队投入多名工程师驻场支持迁移,协助客户顺利的完成了POC测试和正式迁移

  • 脚本化操作

应用数据、Oracle数据库导出,上传,导入等操作都采用脚本化方式,保证迁移过程自动化和一致性,

  • 使用自研数据同步工具
使用泰岳自研的数据同步工具将4.5TB数据文件从自建数据中心上传到AWS云平台,解决数据传输难题
  • 短时间内完成

整个迁移过程在12个小时内完成,保证了在业务闲时完成整体迁移。

 

 

迁移上云获得的收益

在泰岳和客户团队一起努力下,从原来的物理机房迁移到AWS云平台,客户获得的第一个好处就是可以使用托管数据库服务,泰岳的云迁移团队将Oracle数据库迁移到了RDS Oracle数据库,RDS能够大幅降低数据库的运维成本,以前在自建数据中心困扰已久的数据库扩容、备份、可靠性问题在云上的托管数据库都可以轻松完成。其次是大幅度提升了系统的灵活性,可以快速应对业务的快速发展。过去每当业务快速增长,访问量激增时,都必须经过购买服务器、安装、测试、上架这样的繁复流程,不仅需要较长的时间才能完成系统扩容,而且一但访问量减少,备用服务器又会造成浪费,导致成本增加。利用Amazon EC2、Elastic Load Balancing和Auto Scaling可以自动根据业务量进行扩容,既增强了系统的灵活性,又降低了成本;迁移到AWS还给客户带来了一个额外好处,就是在神州泰岳技术专家的帮助下,重新梳理了整个系统架构,降低了系统的耦合性,大量使用spot实例让服务器成本降低90%,同时跨多个可用区的设计,使系统稳定性和可靠性得到大幅度提高。

使用的AWS服务包括Amazon EC2、Auto Scaling group、Amazon S3、Amazon RDS,Amazon ElastiCache,Amazon CloudWatch等;

 

为什么选择神州泰岳云业务

 

神州泰岳具有强大的技术实力:

计算机信息系统集成一级、ISO9001

国家信息安全服务二级、ISO27001

软件能力成熟度模型集成(CMMI)五级

ISO 20000、ITSS运维能力成熟度三级评估

全球分销商和高级咨询合作伙伴。2000+技术人员,200+认证人员

AWS迁移能力认证、DevOps能力认证、CMT技术认证

具备从迁移咨询规划到实施部署的全生命周期迁移服务能力

拥有跨多云平台迁移、IDC机房迁移等不同类型和规模的成功迁移经验

一对一实时客户在线技术支持,确保客户快速熟悉AWS并能够顺利使用

提供持续的架构优化服务,帮助客户降本增效

 

如需进一步协助或服务,请联系我们,泰岳云业务会提供成本分析工具及专业服务

陈汉卿

云业务事业部 | 高级系统架构师

神州泰岳软件股份有限公司·AWS战略合作伙伴

AWS Solution Provider | Migration | DevOps | Cloud Management Tools(CMT) ISV Partner

云战略常犯的十大错误

随着云计算的概念在疫情期间迅速的深入人心,云上很热闹,企业有烦恼。(这个热闹,上一篇《疫情中云上看热闹》中论述过了,不再赘述)。企业们无一例外的开始重新考虑他们的工作和运营方式。很多企业发现,发现他们的云战略需要调整,而那些从来没有制定过云战略的企业,更是压力巨大,迫切需要一个可行的战略。

那么什么是云战略呢?

Gartner关于云战略的定义如下:“云战略是关于云在组织中的角色的简明观点。它是一个活的文档,旨在在高级企业战略和云实现/采用/迁移计划之间架起一座桥梁。”不同于云采用或迁移计划,云战略更多是探索和定义云计算应在组织中扮演的角色。云战略并不是将所有内容迁移到云的计划。

显然,云战略很重要。如何建立一个正确的云战略呢?近期,Gartner云业务专家David Mitchell Smith通过总结对Gartner的数百份云战略文档,归纳出了10种常见错误,很有典型意义。现摘录如下:

错误1:假设它只是一种IT策略,并且不涉及业务,运营,法律,财务和采购

组织设计其云计算战略时最常见的错误是假定它仅涉及IT,而实际上云的采用会影响所有业务部门。IT外部的部门具有与企业的云战略相关的需求和知识,而IT专业人员可能没有。如果您已经设计了仅用于IT的云战略,请使用该策略的实时文档状态在下一次计划的更新中加入业务。

错误2:没有退出策略

如果需要,退出策略概述了有关使自己脱离云环境的注意事项。许多组织认为退出策略是不必要的,因为他们不希望从云中带回任何东西。但是,即使您可能永远不会使用退出策略,也要考虑这一点,这至关重要。此外,还应考虑更改云供应商的可能性,而不仅仅是考虑将工作负载恢复到本地。

错误3:将云战略与云实施计划结合或混淆

人们通常将云实施计划称为云战略,而实际上并非如此。常见的做法是,将云采用或迁移计划称为“云采用策略”,并且该计划试图同时兼顾两种角色(战略和实施)。它还可能非常详细,并且可能包含策略的某些方面。如果您已经创建了这样的文档,请将其重构为两个单独的文档:云战略和云实施计划。

云战略应该放在首位。在决策阶段,您将决定云计算将在组织中扮演的角色(如果有)。接下来是云实施计划,使云战略生效。

错误4:认为制定云战略为时已晚

许多组织认为,如果他们已经在使用云计算,现在制定云战略已经为时已晚,但迟来总比不做要好。问问自己为什么使用云计算,以及它在组织中的作用。确定迄今为止的成就、错误和经验教训,并将其记录在您的云战略中,并参与正在进行的云之旅。毕竟,确保您的策略是一份生动活泼的文件,对于其成功至关重要。

错误5:将云战略等同于“我们将一切都移到云中”

假设您的云战略只是将所有内容都迁移到云的,这样的想法是错误的。它导致组织认为,他们随后将被迫将云计算用于企业的各个方面。云战略不仅涉及正在移动的工作负载,而且还涉及(或不)将要移动的负载。您应该先确定答案后再进行策略开发。

错误6: “我们的云战略就是我们的数据中心战略”或“这全有还是全无”

云战略和数据中心策略应保持分离且一致。如果您的组织决定合并或删除数据中心,则这尤其重要。

云战略决策是按工作负载划分的,而不是数据中心(全有或全无)的决策。尽管主要的云厂商现在帮助您“提升和转移”数据中心,但重要的是要认识到,这更像是执行数据中心策略,并不是云战略。

错误7:认为执行行政命令是一项战略

许多组织采用云计算是因为高管们认为这样会节省成本,或者因为一些其他不切实际的期望。这是一个非常常见的错误,并且是继续存在的许多云神话之一。

云计算并非总能省钱,仅这个目标就不应构成云战略的基础。您的策略基于实现目标业务成果和必要条件,而不是基于CEO告诉您如何做到这一点。将任务授权视为执行实际策略的任务授权。

错误8:对所有事物都采用单一供应商战略

盲目地由供应商带入云与有意而为的云战略并非一回事。前者没有考虑到现有的多种云服务类型,因为许多供应商并未提供云所能提供的所有功能,尤其是在软件即服务(SaaS)级别。

相反,需要考虑设计一种包括SaaS,平台服务(PaaS)和基础架构即服务(IaaS)的多重、混合、分布式和非云选项的策略。合格的云架构师将为您提供最适合您的组织的方法和建议。

错误9:云战略的外包开发

将您的云策略外包很有吸引力,但通常结果包含的度量更符合提供商的策略,而不是您自己的需求。使用第三方来实现——这甚至可以由云提供商实现。这是获得组织所需的稀缺云技能的一种成本效益高的方法。

错误10: “云优先”成为整体云战略

云优先的方法意味着,如果有人要求投资且符合相关标准,则他们构建或放置此新项目的默认位置是公有云。此外,应允许他们以充分的理由将其放到其他地方(比如IDC)。以云为先的原则不应强迫人们使用云。那是仅云战略。云计算优先只是总体云战略的一个方面,应允许其他工作。

最后,帮助大家总结一下

什么是好的云战略?

首先是简单明了(例如10至20页或幻灯片);

其次,是活的(应定期更新);

同时,也是为辅助企业整体战略而存在的。

缺少上述三特性,就是容易犯错的云战略。

第二波云迁移即将到来,您需要知道哪些?

原创:Sid Chatterjee和Chadd Schwartz,2019年11月18日

翻译:泰岳云业务

编者:关于云迁移,已经有很多文章进行了论述,但是关于第二波云迁移的特点您知道吗?这篇文章很好的阐述了第二波云迁移的特点,做为云从业者,你为此做好准备了吗?分析可见云业务的应用开发正在渐入佳境,云迁移不再是搬砖这么简单,为此我们需要付出更多的努力,让云真正的发挥其优势。

原文选自:52.83.57.155//cloud-computing.tmcnet.com/breaking-news/articles/443758-what-companies-need-know-the-second-wave-cloud.htm

真正具有开创性的技术常常会出现这样一种现象:它往往是一波接一波地到来。通常情况下,第一波是提供完成任务的最便宜和最简单的新方法。然而,第二波则将利用其先天优势形成新的一波浪潮。

我们现在看到的云计算也出现类似情况:第二波云迁移即将到来……

起初,企业希望以最快、最低成本、最简单的方式将应用程序和数据转移到云上。第一波“起起伏伏”的浪潮只是通过从本地重新托管虚拟机(VMs),并不那么关键、不那么复杂、同时也没有将真正战略意义的应用程序转移到云上。很多公司以前在传统数据中心中使用的是现在的云,但现在它作为公有云平台上的基础设施即服务(IaaS)模型运行,如Amazon Web Services (AWS)、Microsoft Azure或谷歌云平台(GCP)。

尽管云基础设施服务有时更便宜,但在技术上没有变化,没有应用程序增强或资源优化。向云的第一波迁移让许多企业不禁要问:“就这些吗?”或“为什么云上的成本与我的基础设施服务成本相同,甚至更高? ”或者 “在云中运行后,为什么没有以前那么高效和敏捷呢?”

云计算在最近几年有了很大的发展。随着第二波云计算浪潮的形成,企业现在希望利用新增的功能更快地将新想法和产品推向市场。

为了更好的从云服务中获益,您需要了解下面的一些内容。

 

第二波:云原生应用

云原生的关键是如何创建和部署应用程序,而不是在哪里。它是关于使用云原生服务开发新的现代应用程序,或者重新架构和重构现有应用程序,以利用云在基础架构级别之外提供的所有功能,包括功能性和非功能性服务。有了速度和规模,公司可以加快推向市场的时间,节省大量的开发成本,有时可以达到50%。

云的第二波的提示

创建路线图

与任何应用程序转换或迁移一样,需要一个可靠的计划和策略。确定哪些应用程序从整体的云主机应用迁移到云原生是关键。您将获得诸如成本节约、应用程序生命周期管理的效率、更快的部署和更多的特性等收益吗?请记住,对于您的整个应用程序组合来说,云原生的方法可能并不总是划算的。具有战略意义并与产品和服务相关的应用程序是可以投资并进入第二波的。非战略性应用程序可能没有足够的价值来保证第二波迁移。

设计一个详细的架构来利用云

将独立的云托管应用程序迁移到云原生微服务体系结构需要有原则的设计和体系结构。云原生应用程序交付模型的标准组件可用于实现以下概念:

  • 容器是一种将应用程序代码、配置和依赖项打包到单个对象中的方法。与标准虚拟机相比,它们提供了效率和速度。
  • 微服务是一种体系结构方法,通过这种方法可以将应用程序开发为更小的、可组合的服务的集合。每个组件实现特定的业务功能,运行自己的流程,可以以各种组合方式进行组装,并独立于其他服务进行通信。
  • 持续集成/持续交付(CI/CD)允许单个应用程序更改在准备就绪时被合并并发布,从而缩短了投放市场的时间。
  • DevOps是软件开发人员和IT操作人员之间共享的协作工具,其目标是自动化和简化软件交付过程。

让开发人员使用云原生方法

云原生应用程序在云平台上开发和部署的方式与传统的单个应用程序非常不同。通过使用像serverless这样的技术,开发人员不再需要担心他们部署应用程序的底层基础设施。现在,他们可以像对待一个真正的实用程序一样对待云——永远可用,可随时满足他们的需求。要将实现最有效的云原生系统,需要重新培训现有的开发人员、雇佣新的有经验的云原生开发人员,(和/或)从服务提供商引入有经验的资源。

云计算既是一种思维方式的转变,也是一种模式的转变

应该记住,仅仅将遗留应用程序和数据重新托管到公有云中并不会产生任何运营成本,也不会实现它们可用的效率的深度和广度。第二波云迁移即将到来,所以在一切还不太晚之前,要走在曲线和竞争的前面。不知不觉中,第三波云迁移即将到来。

云迁移的五大失败因素和五大成功因素

本文论述了云迁移过程中如何避免陷阱和收获回报

转载自:Andy PatrizioInfoWorld | 2019年11月18日)

对于大多数公司来说,迁移到云不再是“如果”而是“何时”的问题。通过将应用程序迁移到云上,可以提高安全性、数据访问、可伸缩性和IT灵活性,但这仅仅是开始,转移到云同时也可以帮助您省钱。

然而,请注意:并非所有云迁移都能够进展顺利。迁移的时间通常比预期的长,有的甚至会完全失败,导致时间和开销的浪费。有的应用程序移动到云上后,我们甚至会发现它在云上的表现不如在本地运行的好。结果可能只是另一次迁移——回到本地数据中心。

安全供应商Fortinet赞助、供应链专家IHS Markit最近进行的一项研究发现,许多公司(74%的受访者)在未能实现预期的好处后,已经将基于云的应用搬回了公司。

这不是一个新问题。通过谷歌搜索云迁移失败的案例,可以追溯到几年前的案例。这个问题已经被讨论了有一段时间了。追根溯源,迁移失败不是技术上的失败,往往是领导力的失败。

以下论述了导致云迁移失败的5个主要因素,以及如何才能成功。

云迁移失败#1:缺少一个好的合作伙伴

第一步是要意识到您不能单独做这件事,尤其是在开始的时候。您需要一个合作伙伴,不管是像埃森哲这样的全球性专业服务公司,还是当地的咨询公司。这是问题需要仔细考虑,包括考虑到一些外部因素。理想情况下,您在您的行业和地区能够找到帮助挑选合适的合作伙伴的一个网络顾问。

选择合作伙伴要小心。您需要一个非常有价值的合作伙伴,一个不仅有技术能力而且有变革管理能力的合作伙伴,”企业应用咨询公司总裁Joshua Greenbaum说。

一个好的云迁移专家可以帮助您确定要迁移的最佳应用程序,确定如何集成遗留系统和云服务,并计划和执行迁移。一个好的合作伙伴还可以帮助您制定一个有效的混合或多云策略。

云迁移失败#2:云上的不适症

公司最常犯的一个错误就是让他们的应用程序在云中运行,就像在本地运行一样。CIO咨询公司Avoa总裁蒂姆•克劳福德(Tim Crawford)表示,这是一个巨大而常见的错误。

Crawford说:“本地应用程序习惯于在高峰时消耗资源。“云被设计成在您需要资源的时候使用它们,在您不需要的时候把它们还给您。但传统的应用程序并没有充分利用云计算的自主权和编配能力。”

太多的客户忘记了他们在公有云上运行的每一个字节都是计量的,他们将不得不为此付费。他们让未经修改的应用程序全速运行,耗尽了计算周期,一个月后账单就来了。简单地将一款应用升级并转移到云端,很容易引起用户对账单方面的震惊。在最坏的情况下,您面临的是回退到本地数据中心。

云迁移失败#3:内部技能不足

如果您认为您可以使用ITIL框架、瀑布流程、单片应用程序、操作竖井等老的技术和方法来管理您的公有云或甚至混合云,那么您将会大吃一惊。

您需要能够管理动态基础设施、容器、自动化、微服务等方面技能的人。问题是,其他人也需要!新技术会有对运维有所帮助,但吸引、培训和留住高精尖的人才仍然至关重要。

分析公司Splunk的首席技术倡导者Andi Mann说:“云操作模型将传统的、静态的、单一的软件管理(使用独立的本地遗留工具和套件)转移到一个高度分布式、动态、原子化和抽象的服务环境,这些服务通常由基于云的多点解决方案管理。”“它需要具备管理云平台本身以及容器、微服务、API、SaaS系统等的新技能。”

云迁移失败#4:没有引入利益相关者

云迁移项目的良好治理将涉及到每一个被转移到云业务的相关者。然而,通常情况是,项目由IT部门驱动,然后他们在项目完成后告诉那些受影响的人。

Greenbaum说:“这种情况比任何人承认的都要普遍。”这其中有很多是基本的项目管理,检查指导委员会中是否有合适的人,并获得正确的信息。他们经常不被邀请,得到通知时,为时已晚。”

Greenbaum最近遇到的一个例子是一家公司在迁移到云的过程中对客户体验进行了重大的改变。不幸的是,他们没有考虑到对供应链的影响。因此,供应链团队并没有参与销售改革。迁移完成后,供应链组的成员才意识到发生了什么,并发现他们无法满足改造产生的新需求。

云迁移失败#5:不切实际的期望

迁移到云计算可以带来巨大的好处——速度、灵活性、成本降低、战略重点、可伸缩性、覆盖范围,等等——但它也会带来一定的风险。要从云部署中获得最大的优势,首先要避免天花乱坠的宣传,并对您所能实现的目标和潜在的新风险抱有现实的期望。

领导层特别希望通过云计算节省资金,但情况并非总是如此,特别是如果您没有重新构建您的应用程序,很容易遭遇失败因素#2所提及的问题。此外,云采纳者通常也希望能够在邻近地区少做很多工作,但是云基础设施只会替代服务器,而不是您的IT人员。

不要认为您可以迁移到云环境,从而摆脱所有DBA、安全操作人员、服务台工程师和其他软件专家。如果您像绝大多数企业一样运行混合云,那么您仍然需要硬件支持工程师来支持您所持有的物理资产。

云迁移成功因素#1:带领合格的团队,并要求您的合作伙伴也这样做

对云服务的需求超过了供应,而且缺乏高素质人才来完成需要完成的工作。Greenbaum说,他看到很多项目因为人手不足而搁浅。

Greenbaum说:“项目之所以成功,是因为客户把他们的团队带到网格中,并要求他们的系统集成商也把他们的团队带到网格中。”“如果您不把您最好的人放在上面,您就有可能得到一个较差的结果。”

云迁移成功因素#2:对云上的东西要挑剔

公司仍然会犯的一个常见错误是把所有东西都转移到云上,但并不是所有东西都属于云。Crawford说要把最标准的商业应用程序放到云里,并把独特的代码放在内部。

Crawford建议说:“如果这对您的业务没有什么区别的话,可以考虑将其转移,比如电子邮件和日历、ERP和HCM。”“核心后台功能至关重要,但这就是您的IP区别于竞争对手的地方吗?”“不。这些都是转向云计算的好机会”他这么说。

云迁移的成功步骤#3:创新和差异化

既然您应该为云重构应用程序,那么就把它当作您拥抱新方法和设计的机会吧。为云原生设计重新架构尽可能多的本地应用程序,其中的应用程序是有弹性的,可以根据需要进行伸缩。“容器化”您的应用程序,它运行在Docker上,由Kubernetes管理。所有主要的云提供商都提供服务来帮助Kubernetes实现在本地和云上的服务。

Mann说:“据我所知,最成功的组织已经利用云的本质进行创新,而不仅仅是复制——提供他们以前从未有过的新原型,将服务提升到客户从未期望的水平,并以新的方式为新市场开发新的应用程序。”

云迁移成功步骤#4:一个有凝聚力的策略

从战略上接近云意味着重新考虑预算、组织、流程、技能、安全、数据集成等等。技术只是一小部分,这需要一个有凝聚力的战略。一个成功的迁移包括做出有意识的投资组合决策,包括保持什么在本地数据中心,移动什么,坚持或放弃哪些平台,以及如何重构应用程序以利用云的优势。通过对通用的计算、存储和数据库平台进行标准化,可以降低复杂性和管理和操作的成本。

保持事情的简单也意味着避免过度复杂的迁移,并承担超出能力范围的工作。当项目的范围太大或时间范围或预算太少时,就容易失败。不要一次做完所有的事。应该把项目分成几个阶段,一次解决一个。采用迭代的、类似DevOps的方法。完成其中的一部分,确保它能正常工作,然后转移到项目的下一部分。

云迁移成功步骤#5:考虑全新的数据模型

向云的迁移意味着一个全新的数据模型的出现。将数据放到云中是将数据模型扩展到更广的模型的机会。例如,转移到更以客户为中心的模型可能意味着从许多不同的来源引入更多的数据。

旧的本地数据中心的数据可能有一个简单的客户输入,比如姓名和地址,但新的云数据可能来自社交媒体、物联网设备和其他来源。或者您甚至可以迁移到一个完全不同的数据分析平台。Amazon Redshift是与PostgreSQL兼容的,但是谷歌的BigQuery使用的类型与典型的SQL或PostgreSQL不同。Snowflake支持各种格式的半结构化数据。

Greenbaum说:“从理论上讲,您正在改变商业惯例,所以您需要的数据是不同的。数据质量的变化和其他任何事情一样,都是一个政治决定。这不仅仅是一个让我们把数据放到云端的简单问题,而是一个真正的管理变革问题。”

戏说云上日式搬家

声明

这不是一个搬家公司的广告,只是一个漂泊云上的挨踢狗的戏说。

前言

做为一个北漂,搬家就如同家常便饭,但是每次搬家仍然感觉是一次灾难:打包时发现纸壳箱各种不足,搬家过程的各种混乱,家具被磕磕碰碰,很多小物件从此消失不见,在搬家后,有那么几天,感觉生活停摆。做为一个云上挨踢狗,帮助更多的企业将系统搬迁上云也已经是日常工作的一部分。某日,在总结工作时,忽然发现两者居然是如此的类似,于是决定把二者合二为一来戏说下,给生活增添下乐趣。

第一次用公有云,很多人会发现,原来你在本地机房中繁琐的安装和配置工作,在云端只需要分发一个小程序,数秒内你部署在世界各地的系统就可以同步更新,系统迭代的速度大幅度提升。相信这是很多人喜欢上公有云的重要原因。但是,真正把系统搬迁到公有云,就会发现,一切并非那么简单。数据问题、存储问题、网络问题、接口系统、安全问题等等,各种问题就像那挡在你搬家道路上的障碍物,严重的时候让你的业务停摆。不合理的迁移是一场灾难,让你的上云信心大打折扣。

不知道大家是否看过日本人搬家公司的搬家过程,可以说全过程追求细节的保护与服务,策划、打包、搬运、归位、清洁,一站式服务,搬家变得更加有条不紊,更加安全。做为一个资深运维专家,神州泰岳在结合了AWS的相关最佳实践,以及本身的迁移经验基础上,提出了五步迁移法,使得上云迁移服务就如同日式搬家服务一样,提升了用户的云端感受。

五步迁移法

下图为AWS给出的最佳经验。神州泰岳在上云迁移方面遵循了五步法,同时通过自身经验,对五步法进行了完善,形成了泰岳上云五步法,就是我们后面想要戏说的云上的日式搬家法。

AWS五步迁移方法论

下面开始我们的戏说吧,看看日式的云上搬家会是什么样子的呢?

第一步:定目标

其实准确来说,真实生活中的搬家目标是比较清晰的,而云上的搬家目标则非常复杂。即使是在一个公司,由于职位不同,大家对云上迁移的目标也不尽相同。例如,就CFO而言,云上搬迁可能解决的是本地数据中心的投资问题,其自然希望搬迁后成本能够更加优化;而业务人员可能更多的是希望搬迁的速度更快,业务能够更少受到影响;运维人员可能更多的是希望搬迁更加简单便捷而不是带来更多的工作量和风险;做为安全人员则更多的是希望迁移不要带来更多的安全风险。因此,由于迁移目标的不同,所选择的迁移方法的差异很大,迁移的成本也将会有很大差距,所以,迁移目标的确定在迁移之初是非常重要的。这一点已经远远超出了生活中的搬家。

正是由于制定目标是决定整体迁移活动的关键,AWS在总结经验的基础上,给出了从6个视角来重新审视业务和技术的框架,名为AWS云采用框架(简称AWS CAF)。该框架可以帮助客户更加全面的进行评估,确定合适的目标,从而更快、更低风险地实现采用云带来的可度量的业务收益。框架所涉及的访谈客户上到CTO、CFO,下至系统维护人员,可以说是相当的全面。

实践证明此方法论下,最终确定的目标是科学的,也是得到了用户的一致认可的。目标的确定往往最终与搬迁的结果和搬迁后的效益直接相关。

第二步:策划

一般的搬家公司来了就搬,没有这一步骤,所以往往你也记不清楚到底搬了多少件东西,即使你数清了大件,往往还有很多小件被遗忘。而日式搬家的第一步就是将物品分门别类,然后列出一份一张详细清单,之后按照你家具物品的数量和种类,为你规划出一套最划算、最周全的搬家方案。如果其中有非常贵重的钢琴或者大穿衣镜,将受到额外隆重的待遇。

云上的迁移也是从基础设施和应用的调研开始的。收集客户当前基础设施的性能、使用情况、部署情况,进行记录(包括业务的闲忙时及该期间的使用情况);了解业务应用的优先级,系统间的相互依赖度;列出应用程序基础设施清单。在这方面有很多类似的工具进行现有系统和设备的配置收集。

当处理一个重大的项目时,最具挑战性的部分是决定从哪里开始。如果客户有明确的选择,这一步会相对简单;但是,如果客户的基础设施分布在多个数据中心或多个团队中,没有一组用于评估应用程序的统一度量标准,则很难确定哪个APP最适合第一波迁移。

第一波迁移的项目,我们会希望是那些对业务影响较小,且迁移后效果明显的项目。行业研究表明,多达30%的本地服务器都是僵尸(在6个月或更长时间内没有显示出有用的计算活动的迹象),超过35%的服务器显示活动的时间少于5%。此类应用对业务的影响一般情况下会比较小,首先进行迁移,且在云上正确调整部署的大小,就能够使用户明显感受到迁移到云端的高性价比。毫无疑问,这是云端迁移最佳的撬动点。

事实证明,寻找的与其他应用依赖性少,服务器冗余多,且当前容量有浪费的应用做为首次迁移的应用,会很快让你的客户尝到迁移的甜头,后续的迁移会更加顺利。如果碰巧需要迁移那种大型的,已经无法招待开发人员的应用,则让你的迁移困难重重。

不同的业务,如何迁移上云呢?错误的规划,往往会直接影响到迁移的成败。在云上迁移过程中,我们也会根据用户的业务特性,遵循AWS的6R法则,帮助客户确定,哪些应用是可以直接迁移的(Rehost),哪些是需要修改后迁移的(Replatform),哪些需要重构后再迁移的(Refactor),哪些是不能迁移的(Retain),哪些是停用的(Retire),哪些是需要重新购买服务的(Repurchase)。

当然,最终迁移规划的制定往往也是与财务、公司规划等方面直接相关的,经过各方面的协商,最终才会得出一个被大家认可的迁移计划。

第三步:打包(设计)

从这一步就能够看出来,云上的迁移远远比现实中的搬家复杂的多。当业务真正搬到云端,需要考虑的问题较之前要更加全面,比如安全传输问题,数据的安全存储问题。原来你没有意识到的问题,纷至沓来。公有云与生俱来的弹性扩展、简单易用的高可用性和容灾方案等,只有在真正使用起来才能够发挥其强大的功效,如果只是将物理机上的配置简单搬迁到云端,没有合理的使用这些特点,仍然无法真正实现公有云的优势。因此,优秀的云上良好框架的设计,是云端迁移的基础,也是为什么很多企业请求专业公司协助进行迁移的主要原因。

良好框架的建立除了要求熟悉云端计算,也要求对用户的业务应用情况和应用的相关软件技术非常熟悉。因此,在设计阶段,客户的业务和技术人员也是需要全程参与的。

在架构设计方面,我们遵循AWS的良好框架要求。对设计的合理性,一般在迁移中,挑选部分简易的应用进行验证,然后再根据验证结果进行设计修改。因此,第三步与第四步是循环往复的。

第四步:搬家(迁移和验证)

日式搬家当天,为了不损害大楼墙壁、设备等,工作人员会在搬动前铺设保护垫。算你家是公寓楼,他们也会一路从大楼门口、电梯、楼梯、走廊一路贴到你家地板,以免搬运过程中碰到你的物品。

此外,让人印象最深的是,为了不使衣服在搬运时弄皱,搬家公司会准备像类似简易的移动衣柜的衣架箱,短袖、短裙会塞进小纸箱中,大衣、外套则会放进大纸箱中;鞋子在搬运中不会被挤变形,因为搬家公司会准备专门的简易鞋柜;至于易碎物品,搬家公司也会准备专用的“缓冲气垫包装箱”逐个隔开放。

云上迁移中,我们也是小心翼翼的。有的项目中,在用户预算允许的情况下,为了不影响业务的持续运行,采用了CI/CD的迁移方式。在迁移中,使用AWS CloudFormation模板构建框架,派生出未来的环境;使用AMI和Puppet或Chef等自动化配置管理工具等自动化的迁移手段更是迁移的首选。在迁移过程中,我们也将根据用户的业务和系统的需求,进行迁移工具的选择,如服务器和数据库迁移工具,数据迁移工具等。就如同那些大小的纸箱,完全根据用户的业务要求进行选择。

为了帮助一些初创企业更加顺利的完成迁移,我们更是帮助他们向AWS进行优惠政策的申请,以更低的成本完成迁移。

第五步:清扫归位(优化)

日式搬家的后续清扫和归位,也是让人印象深刻的一个地方。大件物品工人会按照主人要求摆放。小型物件会依照原样,摆放在之前的位置。连鞋子和衣架箱里的衣服,工作人员都会帮你挂回相应的地方。待物品都按照主人的指令归位后,他们还不会离开,还会再重新打扫一次。

而云上业务的迁移完成后,我们的架构师也会对系统进行一段时间的观察,保证业务正常进行的同时,检查哪些系统运行较为低效并提出优化建议。通过不断调整和优化,将系统和运营调整到最佳状态,才最终完成整个迁移过程。这就如同日式搬家最终的清扫和归位,云上的优化不仅仅是归位,更多的是为了达到系统状态的最优,达到对业务的促进。

以上关于搬家的内容,参考了一些搬家公司的宣传手册,由于是戏说,云上部分较为笼统,如有兴趣,请留言进行咨询。

 

AWS迁移五步法

AWS五步迁移法

根据AWS推荐的最佳实践,已经以往的迁移经验,从本地数据中心或其他云迁移到AWS可以分为下面五步:

图1 AWS推荐的迁移步骤

第1阶段:迁移准备和业务规划

  1. 现状评估:与客户沟通Key Person沟通并了解系统部署情况,存在的问题或不足
  2. 用户目标:业务发展的要求,用户的希望通过迁移解决什么问题,有什么收益?
  3. 差距分析:目标和现在的差异是什么?
  4. 制定行动计划

第2阶段:产品组合发现和规划

当处理一个重大的项目时,最具挑战性的部分是决定从哪里开始。

如果客户已经开始了迁移项目,有明确的选择,这一步会相对简单;但是,如果客户的基础设施分布在多个数据中心或多个团队中,没有一组用于评估应用程序的统一度量标准,则很难确定哪个APP最适合第一波迁移。

我们需要结合正确的数据和正确的专业知识可以帮助客户完成这个阶段。

具体步骤如下:

步骤一:调研当前基础设施情况

  • 收集客户当前基础设施的性能、使用情况、部署情况,进行记录。(包括业务的闲忙时及该期间的使用情况。)
  • 了解业务应用的优先级,系统间的相互依赖度
  • 列出应用程序基础设施清单

步骤二:确定首批迁移的应用

建议首批迁移的应用如下:

  • 与其他业务应用依赖关系最少的应用。这样避免因为迁移原因影响其他业务,造成损失;同时也可以使在迁移的过程中逐步提升对AWS技术的了解和信心,为后续更复杂的应用的迁移打好基础。
  • 从供应过剩或空闲资源最多的应用开始。行业研究表明,多达30%的本地服务器(包括物理服务器和虚拟服务器)都是僵尸(在6个月或更长时间内没有显示出有用的计算活动的迹象)。最重要的是,超过35%的服务器显示活动的时间少于5%。只要在AWS上正确调整云部署的大小,这些应用在迁移之后将看到最大的价格/性能改进。

易于迁移且容易看到效果的应用有以下特点:

  • 应用间依赖关系少
  • 应用服务器有冗余
  • 服务器上的应用程序容量有浪费

迁移过程有挑战的应用有以下特点:

  • 大型的、遗留的应用程序(找不到开发人员或无技术支持的应用)
  • 需要与本地文件系统低延迟连接的应用程序
  • 应用中含有专用设备的应用

步骤三:确定迁移策略

一旦确定了最终状态和将要开始的应用程序,就必须确定迁移策略。根据工作负载情况、应用程序和业务单元,可能有多种不同的策略选择。

实际工作中比较常用的包括:

  • 重新托管(Rehost)。这种方法允许保持应用程序的原样,并在AWS上运行时进行任何必要的调整。这是最快的方法之一,有许多迁移工具可以帮助这个过程。一般情况下,用户首次迁移,又希望快速完成一般建议采用此方法。
  • 修补后迁移。Rehost策略是最简单、最快的方法,也是将其第一个应用程序迁移到AWS的公司最常用的方法。但是,使用这种方法,无法在AWS上看到显著的成本节约,因为无法使用AWS的一些成本节约服务,比如Auto Scaling、托管数据库等等。因此,在这种情况下,一般选择修补后迁移的方式(Replatform),通过选择托管数据库或者将应用程序迁移到 AWS Elastic Beanstalk 等完全托管的平台,以此来减少管理数据库实例花费的时间,获得更大的收益。
  • 部分重构。应用程序的某些方面可以保持原样,但其他部分可能需要重新构建才能在AWS上正常运行。部分重构还可以保留现有的应用程序,并在其上构建额外的支持服务。
  • 完整的重构。重新构建应用程序是最耗时的方法,但它也代表了利用AWS云的灵活性和可用性的最大机会。这也是将应用程序分解为微服务或构建基于容器的体系结构的好机会。很多传统企业上云的时候,由于其应用重新紧耦等原因,需要进行解耦将程序分解成微服务,再进行迁移。

步骤四:团队建设,确定全面的业务计划

许多用户都认为AWS是“容易的”。用户可以在几分钟内启动一个新的AWS实例,但是要构建和管理一个不断增长的AWS环境,则需要与管理任何复杂系统的人员相同的专业知识的专业团队。因此,我们在帮助客户完成迁移的同时,也同样需要帮助用户培训现有技术团队,将经验输出给用户团队,与用户内部技术团队密切配合下构建、迁移和管理用户的云架构。

组建迁移团队后,甲乙双方项目经理将一同对后续的迁移进行计划,并制作预算,计划和预算通过后,双方签订合同,开始正式迁移工作。

在合同签订前,我们的售前工程师将需要根据用户的迁移计划进行后续的服务选型,如选择哪种实例类型,如何最大化投资等等。根据选择的实例类型和服务类型,进行预算,然后提交给客户讨论并确定

第3阶段:迁移设计

在此阶段,项目组的架构设计师将根据用户的业务情况,帮助用户进行以下设计:

整体架构设计

    1. 应该使用哪些实例类型,以及在哪些配置中使用? 查看用于服务器的CPU、内存、网络和磁盘的历史性能数据,以及用于存储的跨吞吐量、容量和IO的性能数据。
    2. 决定希望为每个资产提供多少“可用空间”,然后查看跨这些指标的实际最小、最大和平均使用量,以确定哪种实例类型在AWS上最有意义。当CPU需求在任何1小时的1%以上达到70%以上的峰值时,就会认为虚拟机的大小过小。另一方面,如果在7天的时间内,CPU需求在30%以下的时间内超过1%,则虚拟机被认为是超大的。查看30天的历史记录就足够了,因为如果需要,可以很容易地扩展云上的资源。在进行此过程时,对不同代的物理基础设施进行规范化是至关重要的。确定应该购买哪些保留实例来最大化投资回报率?
    3. 设计AWS体系结构,包括体系结构图和建议服务列表,包括EC2实例、EBS卷、VPC等,以及相关成本。

系统可靠性设计

  1. 收集业务方面对RTO和RPO的要求
  2. 设计系统的高可用性和弹性,可以考虑多AZ部署和Auto Scaling等技术
  3. 数据备份方面需求,进行备份设计
  4. 了解用户对容灾的需求,根据用户的实际情况和经济情况,进行容灾设计

系统安全性设计

  1. 与用户的安全工程师一起设计整体架构的安全性,如果有合规性要求,则同样要求进行合规性设计。
  2. 进行MFA账号设计
  3. 安全组策略设计
  4. 密钥保护设计
  5. 数据安全设计
  6. 操作审计设计

上云后运维管理设计

  1. 运维体系设计
  2. 运维工具设计
  3. 监控指标设计
  4. 自动运维设计

成本设计

  1. 资源购买方式设计
  2. 资源容量选择设计
  3. 自动伸缩设计
  4. 总体拥有成本评估

与甲方的Key Person进行沟通,汇报设计情况,在获得甲乙双方对设计的一致认可情况下,才运行进入后面的迁移实施阶段。

第4阶段:迁移和验证

理想情况下,该过程遵循以下模式:

  • 实施工程师在AWS CloudFormation中构建已批准的架构,这是一个架构模板工具,允许 “构建”一次,然后立即派生出未来的环境
  • 使用AWS提供的机器映像(AMI),并使用Puppet或Chef等自动化配置管理工具为每个应用程序进一步配置
  • AWS CloudFormation模板和Puppet或Chef脚本一起保存在代码存储库(Git)中,并像软件一样进行版本控制和更新
  • 服务器、数据库和数据通过internet(这需要相当多的时间)或AWS迁移服务迁移到AWS
  • 云工程师开始初始测试过程,在此过程中,基础设施可以通过CloudFormation被无数次地拆除/重建。
  • 其他团队测试和验证应用程序性能、安全性、合规性等。

不推荐使用CLI或控制台手动构建AWS资源,会使未来测试/开发环境的构建变得复杂,并导致长期管理问题。

第5阶段:运营及优化

虽然在迁移过程中确定了许多具有成本效益的迁移的关键元素,但是在AWS平台上获得长期成功的关键是不断优化。

在迁移阶段,必然会遇到一些低效的情况。当在测试环境中更改实例以满足应用程序的需求时,将会产生一些意想不到的成本。迁移之后,我们需要有专门的时间对系统进行整体Review,检查这些低效性,提出优化建议。

只有通过在新的基础上进行迭代、关闭旧系统,并向现代化运行模式不断迭代。才能使运营的人员、流程和技术会始终保持最佳状态。

本文参考文献:

1、AWS Migration Whitepaper

Azure迁移到AWS实战

综述

本文记录了将Azure中运行的虚机迁移到AWS中EC2运行的实战过程。

原理

使用 VM Import/Export 将虚拟机 (VM) 映像VHD文件,作为 Amazon 系统映像 (AMI) 从虚拟化环境导入到 Amazon EC2 中,并用于启动实例。

步骤

1、查询限制条件

在开始之前,需要了解 VM Import/Export 支持的操作系统和映像格式,以及实例和卷的导入限制。参考:

https://docs.aws.amazon.com/zh_cn/vm-import/latest/userguide/vmie_prereqs.html

2、环境中增加中转机

新增Window EC2设备,用于从Azure侧下载镜像VHD文件。

3、Azure VDH文件下载(解决镜像文件大下载不成功问题)

下载Microsoft Azure Storage Explorer,使用Azure 管理员账户登陆,选择需要迁移的虚拟机,执行VHD文件下载。

4、VHD文件上传S3

4.1、创建 S3 存储桶

通过以下网址打开 Amazon S3 控制台:https://console.aws.amazon.com/s3/

选择 Create Bucket。

在 Create a Bucket (创建存储桶) 对话框中,执行以下操作:

对于 Bucket Name,键入azuremigration您的存储桶的名称。

对于 Region,为您的 AMI 选择一个区域。

选择 Create。

4.2、创建服务角色

  1. 利用以下策略创建名为 trust-policy.json 的文件:
  2. {
  3. “Version”: “2012-10-17”,
  4. “Statement”: [
  5. {
  6. “Effect”: “Allow”,
  7. “Principal”: { “Service”: “vmie.amazonaws.com” },
  8. “Action”: “sts:AssumeRole”,
  9. “Condition”: {
  10. “StringEquals”:{
  11. “sts:Externalid”: “vmimport”
  12. }
  13. }
  14. }
  15. ]

}

使用 create-role 命令创建名为 vmimport 的角色,并向 VM Import/Export 提供对该角色的访问权。请确保指定 trust-policy.json 文件的完整路径,并且为路径添加 file:// 前缀。

aws iam create-role –role-name vmimport –assume-role-policy-document “file://trust-policy.json”

创建名为 role-policy.json 的文件并编写下面的策略,其中,disk-image-file-bucket为存储磁盘映像的存储桶:

  1. {
  2. “Version”:”2012-10-17″,
  3. “Statement”:[
  4. {
  5. “Effect”:”Allow”,
  6. “Action”:[
  7. “s3:GetBucketLocation”,
  8. “s3:GetObject”,
  9. “s3:ListBucket”
  10. ],
  11. “Resource”:[
  12. “arn:aws:s3::: azuremigration“,
  13. “arn:aws:s3::: azuremigration/*”
  14. ]
  15. },
  16. {
  17. “Effect”:”Allow”,
  18. “Action”:[
  19. “ec2:ModifySnapshotAttribute”,
  20. “ec2:CopySnapshot”,
  21. “ec2:RegisterImage”,
  22. “ec2:Describe*”
  23. ],
  24. “Resource”:”*”
  25. }
  26. ]

}

使用下面的 put-role-policy 命令将策略挂载到之前创建的角色。请务必指定 role-policy.json 文件位置的完整路径。

aws iam put-role-policy –role-name vmimport –policy-name vmimport –policy-document “file://role-policy.json”


4.3、将映像上传到 Amazon S3

安装AWS CLI,执行命令:aws s3 cp xxx.vhd s3://azuremigration/,完成镜像上传。

4.4、导入 VM镜像

将您的 VM 映像文件上传到 Amazon S3 后,使用 AWS CLI 导入该映像。

aws ec2 import-image –description “bishuiyuantest” –disk-containers “file://containers.json”

下面是一个 containers.json 示例文件。

[

{

“Description”: “bishuiyuantest-1”,

“Format”: “vhd”,

“UserBucket”: {

“S3Bucket”: “azuremigration”,

“S3Key”: “jiayuefeng0320190509094710.vhd”

}

},

{

“Description”: “bishuiyuantest-2”,

“Format”: “vhd”,

“UserBucket”: {

“S3Bucket”: “azuremigration”,

“S3Key”: “jiayuefeng03-disk-0-20190509094710.vhd”

}

}

4.5检查导入任务的状态

使用 describe-import-image-tasks 命令返回导入任务的状态。

包括的状态值如下:

  • active — 正在运行导入任务。
  • deleting — 正在取消导入任务。
  • deleted — 导入任务已取消。
  • updating — 导入状态正在更新。
  • validating — 正在验证导入的映像。
  • validated — 已验证导入的映像。
  • converting — 正在将导入的映像转换成 AMI。
  • completed — 导入任务已完成,并且 AMI 已准备就绪,随时可以使用。

aws ec2 describe-import-image-tasks


5、启动VM

基于当前镜像文件启动对应的VM,完成业务节点迁移。

神州泰岳获得AWS迁移能力认证

7月17日,神州泰岳作为AWS Advance级别的合作伙伴、AWS全球战略合作伙伴,获得AWS迁移能力(AWS Migration Competency)认证。

AWS迁移能力认证是AWS在云迁移方面的最高级能力认证。全球通过认证企业仅有数十家。

AWS迁移能力认证需要经过专业AWS能力认证专家团队和国外第三方专业审查机构的严格评审,对AWS合作伙伴取得专业认证的团队规模、迁移方法论、迁移案例复杂度与规模,良好架构设计、优秀性能效率、出众成本优化以及迁移过程中领导力等指标的考核,具有最严苛的要求。

虽然要求极其严苛,但是泰岳的云团队具有丰富的云迁移经验,其能力和经验在各方面完全超越审查标准,国外第三方专业审查机构给予泰岳“最优秀的迁移团队之一”评价,这得益于泰岳的强大实力:

国内知名大型企业,具有专业的技术团队,具备AWS代售资质、DevOps资质,2019年全国第一家通过DevOps能力成熟度评估的软件服务企业

专注于大数据、物联网和人工智能领域,在各个领域都有优秀案例

具备大型项目的迁移成功案例,单次迁移服务器数量数百台

迁移案例在架构设计,安全性、可靠性、持久性等多方面全部获得满分

拥有从竞争伙伴迁移AWS的经典案例,也具备从本地数据中心迁移上云的大型案例

具有成熟迁移方法论,规范化迁移流程,统一化登陆区设计

合理迁移工具使用,明确迁移阶段定义,一致化迁移过程文档,结合迁移测试与验证、运维集成、成本优化等。迁移工作各方面能力得到审查机构完全认可

迁移项目客户评价均为满分,说明了客户对泰岳迁移服务的满意度,获得了评审老师的高度评价

能够顺利通过审查获得AWS迁移能力认证,证明泰岳在云计算方面的整体实力、迁移解决方案的专业性以及丰富实践经验得到了AWS的官方认定!