亚马逊AWS官方博客

Category: 大咖专栏

Amazon EC2 Systems Manager让你轻松管理AWS混合云

作者:王宇 摘要: Amazon EC2 Systems Manager(SSM)是一套资源管理、配置的工具集,它不仅能够帮助客户完成AWS云中资源的管理,还能够将客户私有云中的资源统一纳入管理范围,是混合云架构中的管理利器。 IT资源在混合场景下应该如何管理? 对于要不要使用公有云资源的问题对于今天的企业来说已经不再是一个问题了,问题变成了要怎么用,怎么管,以及怎么和现有的企业IT环境进行整合。当前,大量企业客户都存在着部分应用或资源已经上云,而企业自己的数据中心中仍然保留着一部分的应用或资源,如何将这两部分的资源统一管理起来,做到有效的协同,是一个关键问题。而传统的网管或资源管理系统往往还无法支撑这个混合场景下的管理需求。 AWS在云资源管理问题上有着完整的解决方案 AWS从云资源的准备、配置、监控、合规、优化这五个方面提供了完整的云资源管理闭环工具集,今天我们介绍的Amazon EC2 Systems Manager(SSM)是在配置管理环节中的一个最常用的管理工具集。 Amazon EC2 Systems Manager(SSM)工具集 Run Command –远程执行常规管理任务 State Manager –定义和维护操作系统和应用程序的一致配置 Parameter Store – 运维参数的集中管理,如密码和连接字符串 Maintenance Window -在明确定义的时间窗口中安排运维任务,以尽量减少停机时间 Inventory –收集,查询和审计详细的软件清单信息 Patch Management –使用自定义的规则和预先安排的维护窗口维护操作系统补丁程序 Automation –使用简化的工作流自动执行日常运维任务 Run Command Run Command能够通过远程发送命令的方式来管理AWS云以及客户自己数据中心中的IT资源。与以往的Run Command相比,现在还可以控制命令执行的并发数量。 这在远程执行命令时可以有效避免在同一时间使用太多共享资源的问题,例如内部更新或统一执行软件补丁程序。 State Manager State Manager通过“Document”的定义,能够定义和维护操作系统和应用程序的一致配置。 创建一个“Document”,将它与一组目标实例关联,然后创建一个关联策略来指定什么时间和什么频率来应用这个“Document”。 使用标签指定目标可使这个关联应用到未来创建的实例中,并允许它在动态的,自动缩放的环境中按预定义的方式工作。还可以通过选择它并点击Apply Association Now来立即运行这个关联: Parameter Store Parameter Store是一个数字词典,它简化了要分发到实例的许可证密钥,密码和其他数据的存储和管理。 […]

Read More

你需要知道的关于高IO EC2的事儿

作者:焦杨 故事背景 笔者长期在AWS从事架构师工作,人送焦导的外号。经常遇到客户抱怨:“我选了比原来大的机器,比原来快的硬盘,可EC2的IO怎么就是上不去,到底卡在哪里了啊?你们架构师到底怎么干活的啊?”,好了,今天我也不想再背这个锅了,我们一起把这个事儿好好说道说道。 基本原理 一开始,我们先来看看磁盘上的数据是怎么到达外网的。 第一步操作系统接到IO命令,然后驱动磁盘,从磁盘上读入数据到内存处理, 最后从网卡送出,通过交换机路由器送出到外部网络。 要更好的IO性能,硬件层面上看无非三板斧 换个更块的硬盘 换个更快的网卡和交换机 更快的CPU、足够的内存、足够优化的 那到了AWS上,又变成什么样了呢? 云上的图 你可能看出来了: 物理机变成了EC2 instance。 磁盘为了更灵活和更可靠,把它从机器里拿出来变成了EBS。 外部的交换机/路由器由于VPC的存在,对用户变成透明的了。 稍微想想,发现实质完全没有变化。那是不是我们就可以用原有的三板斧解决性能问题了呢? 焦导的回答是:“完全没错,但是不足够”。 大家知道,公有云服务商为了保证服务质量,避免所谓的“吵闹的邻居”问题,也为了避免意外操作导致的超额费用,引入了大量的QoS特性。这里边既有我们熟悉的各个service的hard和soft的limit,也有对外暴露的各种配置选项。为了要实现高IO的目的,我们有必要对这些QoS特性有清晰的了解。 还是上边的那个图,把其中的关键部分标上号,下边一一说明 列举分析 1. EC2网络 AWS向客户提供SDN的VPC网络,屏蔽了交换机、路由器等网络基础设施。但是对单个EC2 实例的网络出口带宽是有明确的限制的。 你可能会说这不就是网卡限制吗?多加几个网卡不就行了。 请注意,增加多个网卡并不能增加单个EC2的总出口带宽。 更加详细的数据请查看这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 2 存储网络 默认情况下,刚才提到的EC2总带宽,包含了进出EC2实例的所有流量。熟悉网络的同学应该知道,这里边包含了EC2间的计算流量、访问存储设备的存储流量等的各种流量。 要优化性能,拿出单独的网络来走存储流量就可以了。这也就是我们通常说的计算、存储流量分离技术。在AWS里,我们把这个叫做”EBS优化“。 当然了,对于一些早期机型(i2,c3等),在使用了万兆网络的情况下。因为这根管子已经足够粗,流量混在一起问题也不是很大。 EC2机型EBS优化的更多信息,可以在这里找到http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-ec2-config.html 3 磁盘性能 要想获得高IO,选择合适的磁盘应该是最基本的了吧。是看重IOPS而选择SSD型,还是看重连续读写的磁盘吞吐而选择HDD,这是你要做出的关于磁盘的第一个决定。 这里要特别注意的几个点: 单卷IOPS的具体值和容量正相关,对于GP2而言,基准值为3IOPS/GB 对单卷有IOPS和吞吐量的限制, 两个因素同时起作用 对连接了多个卷的实例,总体IOPS和吞吐量也分别有限制 另外需要注意的是,对于使用最多的GP2类型SSD,存在着读写突增特性(链接),无论多小的磁盘短时间内IOPS都可以到达3000,具体就不再展开说了。 参考这里http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/EBSVolumeTypes.html 4 存储队列 卷存储队列是指等待设备处理的 I/O 请求的队列,它的长度表明了有多少I/O请求还没有得到执行。队列过长,读写延迟加大,队列过短,读写任务不饱满。要让EBS全速工作起来,需要有足够的任务,也就是说要让EBS始终处于忙碌的状态。 基于这个认识,有必要根据工作负载的具体状况,实时观察存储队列长度的情况。对工作负载进行适当调整,以便发挥底层设备的最大能力。 这个指标可以通过Cloudwatch的VolumeQueueLength 来观察。 http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-io-characteristics.html […]

Read More

EKK—基于AWS托管服务的日志收集分析系统

译者:刘磊 应用系统日志的收集分析对于运维来说是至关重要的。一个可靠、安全、可扩展的日志收集分析解决方案在分析应用系统异常终止原因时能够让一切都变得轻松起来。 在这篇博文里,我们会探讨除了流行的ELK(Elasticsearch, Logstash, and Kibana)解决方案之外的另一种选择,EKK解决方案(Amazon Elasticsearch Service, Amazon Kinesis, and Kibana)。EKK架构最大的好处是使得你不再需要自己亲自安装、部署、管理以及扩展日志收集分析系统,而将精力集中在分析日志,排除应用系统异常上面。 下面我们会介绍如何使用EKK架构来收集和分析Apache web服务器的日志,先来看看EKK架构的组成部分。 Amazon Elasticsearch Service是一个流行的搜索和分析引擎,主要用来提供实时的应用系统日志和点击类流量的分析服务。本文中我们会利用Amazon ES将Apache的日志存储并索引起来,作为一项托管服务,Amazon ES可以很轻松地在AWS云上进行部署、操作和扩展。此外使用托管服务,还能大大减轻管理上的工作,例如打补丁、异常监测、节点恢复、备份、监控等等。因为Amazon ES自身内部已经和Kibana进行了集成,所以省去了安装和配置等工作。获取Amazon ES的更多信息,请参考Amazon Elasticsearch Service。 Amazon Kinesis Agent 是一个易于安装的单机版Java应用程序,它负责收集和发送日志数据。它会持续监控Apache web服务器的日志文件,并且将新的数据不断地发送到传输数据流中。同时它还负责文件回滚、生成检查点、异常发生后的重试,以及以时间序列为准可靠地发送日志文件。获取更多利用Amazon Kinesis Agent的信息,请参考Amazon Kinesis Agent和 GitHub 相关项目。 Amazon Kinesis Firehose提供了往AWS中加载流式数据的捷径。本文中,Firehouse会获取并自动加载日志的流式数据到Amazon ES里,随后在S3中还会再进行一次备份。获取Amazon Kinesis Firehose的更多信息,请参考Amazon Kinesis Firehose。 有了AWS CloudFormation的帮助,你只需要使用一个模板就能快速实现EKK架构。模板里准备了Apache web服务器,并使用Amazon Kinesis Agent和Firehose将它的访问日志发送给Amazon ES集群,同时在S3中备份日志数据,最后使用Amazon ES Kibana endpoint来对你的日志进行可视化分析。 AWS CloudFormation template帮你快速完成如下工作: 准备Amazon […]

Read More

利用AWS混合云容灾架构实现企业级IT的云转型(一)

作者:王宇 摘要:AWS混合云容灾架构不但能够实现企业级的应用云容灾,还能够帮助企业级客户平滑实现企业IT的云转型。 在我们谈论容灾时,我们在谈些什么? 容灾是一个非常传统的话题,是在产生IT系统的第一天开始就必须要考虑的问题。总的来说它主要是指“数据中心灾难、区域性灾难和人为误操作”三个方面造成对IT系统的灾难时的恢复工作。 在中国,“两地三中心”的容灾架构已经广泛的被企业级用户认可,成为企业级容灾架构的标准,但由于建设成本高,周期长等原因,实际按照此标准建设的企业少之又少。而AWS的混合云容灾架构,就是在AWS的云环境中实现“两地三中心”,同时利用AWS云中资源的弹性大幅度降低资源成本和建设以及运维的复杂性。 软件定义一切,AWS云容灾解放企业IT生产力 如果企业客户已经在自己的数据中心中完成了容灾环境的搭建,势必消耗了大量了资源,包括机架空间、电力、IT资源、人力资源等等,而容灾环境本身是一个并不产生经济效应的保障性系统,对企业资源的占用巨大。AWS云资源池通过软件定义的方式,能够打造与企业内部完全相同的复杂IT环境,实现企业级应用的完整镜像,随着应用容灾系统迁移至AWS云中,可以将企业现有的容灾中心转变成生产中心,从而扩大客户自建数据中心的承载能力,或大幅降低IT资源的运营成本。 随时容灾演练,确保备用环境可用性 在传统的容灾环境中,容灾演练是一个令人头疼的大问题,因为容灾环境的建设不是“一锤子买卖”,随着生产环境和数据的不断变化,容灾环境必须跟随生产环境改变,否则在发生灾难时就无法实现业务的快速切换和启动,因此,定期的容灾演练是必须的。而传统环境中的容灾演练要配合硬件和软件厂商,耗时耗力,效果还往往不尽如人意。在AWS云环境中,能够轻松实现容灾环境的复制,从而与生产环境并行的实现容灾环境的测试演练,通过实际的演练来验证容灾环境的可用性以及数据的完整性,在演练结束后可以随时将演练环境删除或关停,演练成本和复杂程度都大幅降低。 AWS云容灾实现秒级回滚,解决人为错误 在生产环境中,由于人为的误操作、系统升级、补丁等操作造成的对IT系统以及数据的破坏很难防范,尤其是有一些操作和BUG导致系统在运行一段时间后才能发现故障,而此时容灾环境的数据有可能已经被覆盖,难以恢复。在AWS云中实现的容灾环境能够借助数据快照、数据日志等功能,除了能够保存最新的业务数据意外,还能够实现数据的秒级回滚。在发现系统出现故障后,不但能够切换到容灾环境中的最新数据,还能够选择过去24小时中的任意时间点进行恢复,从而解决了容灾系统中的脏数据问题。 利用AWS容灾环境切换,实现生产系统的平滑上云 现有的IT生产系统环境往往错综复杂且数据量大,让这样的系统上云往往需要冗长的数据搬迁和环境搭建时间,生产系统面临长时间的停机,无法接受。AWS容灾解决方案能够与生产系统并行地传输生产数据,并在云中搭建与企业内部结构相同的生产系统镜像环境,待云中数据与生产中心数据同步一致后,以容灾切换的方式使生产业务切换至AWS云上,最大限度地降低了生产环境的停机时间,实现了平滑上云。 AWS云中容灾,只为实际使用量买单 从容灾系统的TCO上看,AWS容灾解决方案更是具备明显优势。无需前期对硬件、软件的采购和安装,省去了大量前提投入成本。更重要的是,容灾方案中AWS云中资源可以选择不开机或只开启少量小机型资源,对于不开机的资源将完全不收取EC2虚拟机资源的费用,又能保持EC2虚拟机的状态和后台数据的增量更新。经过我们的测算,一个典型的容灾系统项目,以5年为周期进行计算,TCO只需花费原有私有云容灾环境的1/3,而第一年的投入资金更是传统项目的1/10. 总结 容灾虽然是一个非常古老和传统的IT业务,但随着云计算技术的不断成熟和普及,它恰恰成为了一个非常适合率先在公有云中实现的业务。首先它的建设风险低,与生产系统完全并行,前期投入小,无需提前采购,而且它还能够成为企业上云过程中建设自身团队云能力的一个绝好机会,经过云容灾项目之后,企业对AWS云资源、云技术都会有一个全面的了解,且能够利用这个机会验证AWS云环境承载企业生产系统的能力到底如何,再逐步实现企业级IT环境的云转型。 (未完待续) 本次分享的内容先到这里,今后我们会继续针对AWS混合云容灾架构中的诸多关键技术要点进行细致的分享,敬请期待! 如对AWS混合云容灾架构解决方案感兴趣,请联系我们: yuwangcn@amazon.com   作者介绍: 王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。  

Read More

搭建基于S3的HBase读备份集群

作者:刘磊 当前aws的很多客户已经从将s3作为HBase的存储中获益,这当中包括更低的存储花费、更好的数据可靠性、更容易的扩展操作等待。比如FINRA就通过将HBase迁移到s3上将在存储上的花费降低了60%,此外还带来了运维上的便利,以及架构上的重大优化:将s3作为统一的存储层,实现了更彻底的存储和计算分离。在s3上部署HBase集群,可以让你在集群启动后立即进行数据查询操作,而不用等待漫长的快照恢复过程。 随着Amazon EMR 5.7.0的发布,现在你可以在集群层面进一步提升数据的高可用性和高可靠性,方法是基于同一个s3存储桶建立多个HBase的读备份集群。这会让你的数据通过读备份集群及时地被用户访问,即使在主集群遇到问题关闭的时候,当然你还可以通过在多个可用区中部署读备份集群来进一步增加数据访问服务的可靠性。 接下来的文章将告诉你如何在s3上建立HBase的读备份集群。 HBase 简介 Apache HBase是Apache Hadoop生态体系中的大规模、可扩展、分布式的数据存储服务。同时它还是开源的,非关系型的版本数据库,默认情况下运行在HDFS之上。它的设计初衷是为包含了数百万个列的数十亿行记录提供随机的、强一致性的、实时访问。同时它还和Apache Hadoop、Apache Hive和Apache Pig等大数据服务紧密结合,所以你可以轻易地为并行数据处理提供快速的数据访问。HBase数据模型、吞吐量、和容错机制能很好地为广告、web分析、金融服务和基于时间序列数据的应用等工作负载提供支持。 和其他很多Nosql数据库类似,HBase中的表设计直接影响着数据的查询和访问模式,根据这些模式的不同,查询的性能表现也会有非常大的差异。 HBase on S3 在建立基于S3的HBase读备份集群之前,你必须先学会HBase on S3的部署方法,本段为那些不熟悉HBase on S3架构的人提供了一些基本信息。 你可以通过将S3作为HBase的存储层,来分离集群的存储和计算节点。这使得你可以根据计算需求来规划集群,从而削减开支,毕竟你不再需要为HDFS上存储的3备份数据支付费用了。 HBase on S3架构中的默认EMR配置使用内存和本地磁盘来缓存数据,以此来提升基于S3的读性能。你可以在不影响底层存储的情况下任意地对计算节点进行伸缩,或者你还可以关闭集群来节省开支,然后快速地在另一个AZ中重新进行部署。 HBase on S3读备份集群应用案例 使用HBase on S3架构使得你的数据被安全、可靠地存储起来。它将数据和集群隔离进行存储,消除了因为集群异常终止带来数据丢失的可能性。尽管如此,在一些特殊情况下,你还是会希望数据能获得更高的可用性,比如集群异常终止或者整个AZ失效。另外一个情况是,通过多个集群访问一个S3上的根目录,你可以隔离HBase集群的读写操作,从而来降低集群的压力,提供更高SLA的查询服务。尤其是在主集群因为bulk load、heavy write、compaction等操作变得异常繁忙的时候。 下图展示了没有读备份的HBase on S3架构,在这个场景下,诸如集群终止和AZ失效等异常情况会使得用户无法访问数据。 S3上的HBase根目录,包含了HFile和表的原数据信息。 EMR 5.7.0之前的版本,无法将多个HBase集群指向同一个S3上的根目录,为了获得更高的可用性,你需要在S3上创建多个数据副本,并管理它们之间的一致性。 随着EMR 5.7.0的发布,现在你可以启动多个读备份集群并指向S3桶上同一个根目录,保证了你的数据通过读备份集群它们总是可达的。 下面是一些使用HBase读备份集群的例子,展示了启用前后的一些对比情况。 处于同一个AZ的HBase读备份集群: 处于不同AZ的HBase读备份集群: 基于S3的HBase读备份集群的另一个好处是可以更加灵活地根据具体的工作负载来规划你的集群。比如,虽然你的读负载很低,但还是想要获得更高的可用性,那么就可以启动一个由较小实例组成的规模较小的集群。另一个例子是当你遭遇bulk load时,在高峰期集群需要扩张到很大以满足计算需求,在bulk load结束后,集群可以立即缩减以节省开支。在主集群伸缩的时候,读备份集群可以维持一个固定的规模以对外提供稳定的查询服务。 步骤 使用下列的步骤来启动基于S3 的HBase读备份集群,这项功能只针对EMR 5.7.0之后的版本。 创建使用HBase on […]

Read More

用无服务器应用模型部署无服务器应用 (二)使用无服务器应用模型的持续集成

作者:薛峰 上一篇文章中我们介绍了AWS 无服务器应用模型和SAM模板的基本功能和特性,并带领大家用一个实例体验了通过CloudFormation部署SAM模板。在这一篇中,我们仍然结合实例讲解,为大家继续介绍使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。 部署配置AWS CodeBuild 如果我们的Lambda函数使用了依赖库时,我们可以通过AWS CodeBuild来把依赖库编译进Lambda函数的部署包里。 AWS CodeBuild  是一个完全托管的构建服务,可用于编写源代码、运行测试并生成可立即部署的软件包。CodeBuild基于AWS管理的容器,从而实现用户无需配置、管理和扩展自己的构建服务器。CodeBuild 可持续缩放和并行处理多个生成任务,因此构建任务不必在队列中等待。使用CodeBuild,我们只需要按构建时使用计算资源的分钟数付费,从而无需为预置的构建服务器的空闲时间付费。 除了常见的Java之类的程序源码的构建,CodeBuild还可用于Lambda函数部署前的构建。下面我们用一个例子来具体说明。 请先从以下git库下载源码。 https://github.com/xfsnow/serverless/tree/master/sam/codebuild 这个例子中的Lambda函数需要Node.js 依赖库 time,我们使用CodeBuild在构建时安装这个这个time库,把它加入到 Lambda 函数的包中。 index.js 文件中以下这行,表示需要依赖库 time。 var time = require(‘time’); buildspec.yml 中 install: commands: – npm install time 表示在构建的安装步骤把 time 库安装进来。 build: commands: – aws cloudformation package –template-file codebuild.yaml –s3-bucket <bucket-name> –output-template-file output_codebuild.yaml 这段其实就是使用在上一章节我们介绍过的aws cloudformation […]

Read More

用无服务器应用模型部署无服务器应用 (一)无服务器应用模型入门

作者:薛峰 背景介绍 AWS无服务器架构也涉及到多个AWS服务,如AWS Lambda、Amazon API Gateway、Amazon DynamoDB等。如何把这些服务资源方便地管理起来呢?今天我们介绍的AWS 无服务器应用模型(AWS Serverless Application Model,以下简称AWS SAM)就是一种解决方案,它是一个开源的模型,结合AWS自动运维相关的服务如AWS CloudFormation 和AWS CodePipeline,统一管理多种资源,实现我们的无服务器应用的持续集成和部署。 我们从SAM开始,用几个具体例子为大家介绍使用AWS服务实现持续集成的具体方法,帮助大家快速上手,体验其强大和便捷。 SAM 简介 松鼠SAM是AWS Lamba和无服务器应用模型的吉祥物,寓意轻便、灵活、敏捷。它头顶的头盔上是希腊字母 lambda ,代表了AWS无服务器核心服务 Lambda。 SAM是 AWS 2016年11月发布的一个应用架构模型。遵循开源协议,是一个开放的说明文档。通过开源协议方式发布,也体现了AWS推动开源流动的努力。 官方的github地址如下: https://github.com/awslabs/serverless-application-model SAM实质上是一个AWS CloudFormation 的扩展,基于AWS CloudFormation 并且为无服务器做了优化,它简化了无服务器资源的管理,增加了无服务器相关的新资源类型。 SAM模板简介 AWS CloudFormation标准模板语法比较复杂,SAM模板提供了一套简化的语法,我们先来看一个简单的例子: AWSTemplateFormatVersion: ‘2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://sam-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: […]

Read More

挖掘EB级别数据的价值 – Redshift Spectrum介绍及最佳实践

随着数据存储技术的快速发展,众多企业客户可以以低成本存储PB级别甚者EB级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源,又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力,但很多数据并不能被有效的分析甚至根本未作任何分析,形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。 作为一个托管的数据仓库服务,Amazon Redshift从它发布至今已经帮助全球成千上万的客户解决了PB级别数据的分析能力,实现了复杂SQL的快速查询。但随着数据的飞速增长,我们看到越来越多的客户数据开始逼近EB级别。对于这样体量的大数据,虽然Redshift也可以支持快速的复杂SQL查询,但毕竟我们需要启动更多的Redshift集群,消耗更多的CPU和存储成本,同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在S3上,通过EMR集群也可以实现快速低成本的数据清理,但针对复杂的(诸如Join类)的查询速度会很慢,不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。 为了真正摆脱数据分析的瓶颈、消灭暗数据,我们的客户需要既能高效执行复杂的查询,又能享受高度可扩展的数据并行处理,也能利用近乎无限的低成本的S3存储资源,还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务Redshift Spectrum的使命。 Redshift Spectrum 介绍 Redshift Spectrum可以帮助客户通过Redshift直接查询S3中的数据。如同Amazon EMR,通过Redshift Spectrum客户可以方便的使用多种开放数据格式并享有低廉的存储成本,同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum采用了无服务器架构,所以客户不需要额外配置或管理任何资源,而只需为Redshift Spectrum的用量付费。使用方面,Redshift Spectrum享有和Amazon Redshift一样的复杂查询的优化机制、本地数据的快速读取以及对标准SQL的支持。结合上述功能特点,Redshift Spectrum可以在几分钟内完成对EB级别的数据的复杂查询,这使它在众多大数据分析服务中脱颖而出。我们做了一个实验,在对一个EB的数据做涉及四个表的join,filter和group的查询时,1000个节点的Hive集群预估需要耗时5年,而Redshift Spectrum只用了173秒。 另外Redshift Spectrum 是Amazon Redshift的一个内置功能,所以使用Redshift Spectrum 对Redshift客户现有的查询服务和BI工具不会有任何影响。在Redshift Spectrum的底层,我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配,前端的客户无需做任何资源部署和配置。Redshift Spectrum也很好的支持了高并发 – 客户可以通过任何多个Amazon Redshift集群同时访问S3上的数据。 Redshift Spectrum 上一个查询任务的生命周期 一切从Redshift Spectrum的查询任务提交给Amazon Redshift集群的领导节点开始。首先,领导节点负责优化、编译、并推送查询任务给Amazon Redshift集群的计算节点。然后,计算节点从外部表获得数据目录,并基于查询任务里的join和filter动态移除不相关的数据分区。这些计算节点同时也会检测在Redshift本地是否已有部分查询数据,从而只从S3上扫描本地没有的数据以提升效率。 接下来,Amazon Redshift的计算节点会基于需要处理的数据对象生成多个查询需求,并行提交给Redshift Spectrum,Redshift Spectrum再据此启动上千个工作线程。 这些工作线程进一步从S3上扫描、筛选并聚合数据,将处理好的结果数据传回Amazon Redshift集群。最后,传回的结果数据在Redshift 集群本地作join和merge操作,然后将最终结果返回给客户。 Redshift Spectrum 的优势 Redshift Spectrum的架构设计有很多优势。第一,剥离计算与S3上的存储,使计算资源可以独立弹性扩展。第二,大幅提升了并发效率,因为客户可以用多个Redshift集群访问同一组S3上的数据。第三,Redshift Spectrum沿用了Amazon Redshift的查询优化机制,可以生成高效的查询规划,即便面对诸如多表join或者带统计函数(window function)的复杂查询也能胜任。第四,可以对多种格式的数据源直接查询 – Parquet, RCFile, […]

Read More

动态DevOps环境中的IT治理

译者:殷实,AWS专业服务咨询顾问 |原文链接 动态DevOps环境中的IT治理 治理涵盖安全和生产力运营的协调,其目的是确保公司实现业务目标。 正在迁移到云端的客户可能处于实现治理的各个阶段。 每个阶段都有自己的挑战。 在这篇博文中(系列中的第一篇文章),我将讨论四步走的方法来自动化AWS服务的治理。 治理和DevOps环境 具有DevOps和敏捷思维的开发人员负责构建和运营服务。他们经常依靠中央安全小组制定和实施安全策略,寻求安全审查和批准,或实施最佳实践。 这些安全策略和规则并没有得到安全小组的严格执行。它们被视为开发人员为获得更多的使用AWS的灵活性而遵循的准则。然而,由于时间限制或重视度不足,开发人员可能并不总是遵循最佳实践和标准。如果这些最佳实践和规则得到严格执行,安全小组就可能成为瓶颈。 对于迁移到AWS的客户,这篇博文中描述的自动化治理机制将为开发人员保留灵活性,同时为安全团队提供控制。 在动态开发环境中,以下是一些常见的挑战: 通过捷径完成任务,例如将安全凭证硬编码在代码中。 成本管理,例如控制启动的实例的类型。 知识传递。 手动流程。 治理步骤 四步走的自动化治理方法: 在治理开始的时候,你需要实施一些(1)高风险操作的控制。在控制就绪后,你需要(2)监控你的环境,以确保你正确地配置了资源。监控将帮助你发现想要(3)尽快修复的问题。你还将需要定期地生成一份(4)审核报告,以展示所有内容都符合要求。 这篇博文中的例子协助阐明了四步走的自动化治理方法:中央IT团队允许其Big Data团队运行一个基于Amazon EMR集群的测试环境。该团队在100个t2.medium实例运行EMR任务,但是当一个团队成员使用100个r3.8xlarge实例来更快地完成任务时,业务会产生意外的费用。 中央IT团队关心治理,采取一些措施来防止这种情况再次发生: 控制要素:团队使用CloudFormation来限制实例的数量和类型,并使用AWS身份和访问管理来允许只有某个组可以修改EMR集群。 监控要素:团队使用AWS标记,AWS Config和AWS Trusted Advisor来监控EMR实例限制,并确定是否有人超额使用了被允许的实例数。 修复:团队创建一个自定义的AWS Config规则来终止那些不是指定类型的EMR实例。 审核:团队在AWS Config中审查EMR实例的生命周期。 控制 你可以通过标准化配置(通过AWS CloudFormation),限制配置的选项(通过AWS服务目录)和控制权限(通过IAM)来防范错误。 AWS CloudFormation可以帮助你在单个软件包中控制工作流环境。 在这个示例中,我们使用CloudFormation模板来限制实例的数量和类型,使用AWS标记来控制环境。 例如,团队可以通过使用限制了实例类型和数量的CloudFormation来阻止选择r3.8xlarge实例类型的选用。 CloudForamtion模板示例 包含标记的EMR集群 { “Type” : “AWS::EMR::Cluster”, “Properties” : { “AdditionalInfo” : JSON object, “Applications” : [ […]

Read More

在AWS上部署SAP HANA – 您的选项是什么?

作者:Sabari Radhakrishnan, Amazon Web Services(AWS)的合作伙伴解决方案架构师 译者:戴俊, Amazon Web Services(AWS)的专业服务团队SAP顾问 | 原文链接 您是否计划将SAP应用程序迁移到SAP HANA平台或使用SAP HANA启动新的实施? 如果是这样,您可能会想知道Amazon Web Services(AWS)提供什么选项来运行SAP HANA工作负载。 在这篇博文中,我想讨论SAP HANA所需的核心基础架构组件以及AWS提供的构建模块,以帮助您构建AWS上的SAP HANA虚拟设备。 我希望这些信息可以帮助您了解概念层面的部署选项。 这是我们将在AWS主题上发布各种SAP的一系列博文中的第一篇,因此请经常回来看看。 如果您遵循SAP HANA定制数据中心集成(TDI)模式,内存,计算,存储和网络是SAP HANA所需的四个关键基础架构组件。 其中,内存是唯一取决于您的数据大小的变量。 计算,存储和网络的要求是从内存大小预设或派生的。 例如,根据内存大小,SAP已经有了标准的CPU核数到内存比的要求,以确定您需要进行计算的CPU核心数量。 关于存储,无论内存大小如何,您需要能够满足SAP HANA硬件配置检查工具(HWCCT)指南中规定的不同块大小和其他KPI的特定吞吐量要求。 最后,对于网络,特别是对于横向扩展情况,不论内存大小,您都需要能够在SAP HANA节点之间至少支持9.5 Gbps的网络吞吐量。 在过去的几年中,AWS与SAP紧密合作,以验证在AWS平台上运行SAP HANA工作负载的计算和存储配置。 我们如何实现这个目标的呢? 答案是,AWS已经设计了具有不同内存大小的Amazon Elastic Compute Cloud(Amazon EC2)实例,以满足SAP对SAP HANA的所有严格的性能要求,包括适用于计算的CPU核心到内存比例。 此外,Amazon Elastic Block Store(Amazon EBS)在许多情况下满足了TDI模型的存储KPI。 最后,EC2实例的网络带宽满足或超过了横向扩展模式下节点间通信的9.5 Gbps要求。 我们来仔细看看这些构建模块和配置选项。 内存和计算 AWS提供了几种EC2实例类型来支持不同类型的工作负载。有两个EC2实例系列非常适合SAP HANA工作负载:内存优化的R3和R4实例以及高内存X1实例。这些实例系列是针对内存中的工作负载(如SAP HANA)专门制定的。这些实例系列及其包含的实例类型为您提供了运行SAP […]

Read More