亚马逊AWS官方博客

Category: 计算

新功能 – EC2 实例和 EBS 卷的每秒计费功能

在过去,如果您需要使用计算能力,则需要购买或租用服务器。当我们在 2006 年推出 EC2 时,使用一个实例一个小时只需支付一小时的费用是头条新闻。即付即用模式激励我们的客户思考开发、测试和运行所有类型的应用程序的新方法。 如今,AWS Lambda 等服务证明我们可以在短时间内完成大量有用的工作。我们的许多客户都在设计适用于 EC2 的应用程序,以便能够在更短的时间内 (有时仅为几分钟) 充分利用大量实例。 EC2 和 EBS 的每秒计费 于 10 月 2 日开始生效,以按需、预留和竞价形式发布的 Linux 实例的使用将按 1 秒的增量计费。同样,EBS 卷的预置存储也将按 1 秒的增量计费。 每秒计费功能也适用于 Amazon EMR 和 AWS Batch: Amazon EMR – 我们的客户增加了其 EMR 群集的容量以更快地获得结果。借助适用于群集中的 EC2 实例的每秒计费功能,添加节点要比以往任何时候都更经济高效。 AWS Batch – 我们的客户运行的许多批处理作业在 1 小时内即可完成。AWS Batch 已启动和终止竞价型实例;利用每秒计费功能,批处理将变得更划算。 Elastic GPUs – Elastic GPUs […]

Read More

使用AWS Lambda和AWS Step Functions轻松构建Serverless应用

作者: Vivian Zhang(张芸) Serverless(无服务器)应用可以说是当前的行业热点,用户无需预配置或管理服务器,只需要部署功能代码,AWS Lambda会在需要的时候执行代码并自动缩放, 从每天几个请求到每秒数千个请求,轻松地实现FaaS (Function as a Service)。无服务器应用的使用场景非常广阔,从微服务架构,到批处理、流处理、运维自动化和移动计算。 实现Serverless应用,除了AWS Lambda还需要什么? 我们来看一个典型的基于Lambda的无服务器应用。 当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉,可以看到下面这张图。 这张图上的箭头,就是上一张图里Lambda函数之间的流程,或者可以称为Lambda函数之间的“胶水”,它们起到了编排协调各个Lambda函数的作用。通常在应用中,我们会需要有这样的一些流程: 我想要顺序地执行方法。 我想要并行地运行这些方法。 我想要基于数据选择执行方法。 我想要重试某些方法。 我想要try/catch/finally。 我想要代码运行一定时间或者等待一段时间…… 通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数,实现流程。但是对于所采用的协调机制,我们都希望它具有以下功能: 可以自动伸缩; 不会丢失状态; 可以处理错误和超时; 可以简单的搭建和运维; 可以审计。 这里我们介绍一种方式,采用AWS Step Functions协调Lambda函数之间的流程。 AWS Step Functions AWS Step Functions是一个可视工作流服务,可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序,每个组件都执行一个特定的功能,也就是Task(可以采用Lambda函数实现)。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能,并且 提供了一个图形控制台,将应用程序的组件可视化为一系列步骤,它可以自动触发并跟踪每一个步骤,并在出现错误时重试,这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态,因此当事情出错时,用户可以快速地诊断和调试问题。 要使用Step Functions构建应用,首先我们需要在Step Functions里创建State Machine(状态机),也就是对应每一个应用的工作流程。可以采用以下8种蓝图,包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。 在每一个状态机里,我们需要定义一系列的State(状态),用来完成不同的功能: Task:在状态机中完成特定的功能,可以采用Lambda函数实现。 Choice:在各种执行分支中进行选择。 Fail和Success:停止一个执行,并设为Fail或者Success。 Pass:简单地将输入传给输出,或者注入一些数据。 Wait:提供一定时间的延迟,或者等待到特定的时间/数据。 Parallel:并行地执行分支。 可以看出,上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能,而其他状态用来处理功能之间的流程。比如说,下面是一个名为HelloWorld,执行Lambda函数的状态。 下图是一个拥有所有状态的状态机: 在Console里看到一个创建好的状态机是这样: 我们点击New Execution并且传入input数据,就可以启动该状态机的一次执行,并且可以从界面上查看执行的情况。 […]

Read More

新增 – 适用于 Windows 的 Amazon EC2 Elastic GPU

作者:Randall | 原文链接 今天,我们高兴地宣布,适用于 Windows 的 Amazon EC2 Elastic GPU 正式推出。Elastic GPU 是一种 GPU 资源,可以挂载到 Amazon Elastic Compute Cloud (EC2) 实例来提升应用程序的图形性能。Elastic GPU 提供 medium (1GB)、large (2GB)、xlarge (4GB) 和 2xlarge (8GB) 几种大小,可以作为 G3 或 G2 等 GPU 实例类型 (用于 OpenGL 3.3 应用程序) 的成本更低的替代方案。您可以将 Elastic GPU 用于多种实例类型,灵活地为应用程序选择适当的计算、内存和存储资源,使之达到平衡。您现在就可以在 us-east-1 和 us-east-2 区域预配置 Elastic GPU。 对于 eg1.medium,Elastic GPU 的起始价仅为每小时 […]

Read More

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 无服务器应用模型和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

如何使用 AWS Lambda 为 AWS Service Catalog 产品启动创建审批流程

利用 AWS Service Catalog,组织可以集中管理通常部署的 IT 服务,实现一致的监管以及帮助满足合规性要求。AWS Service Catalog 可为产品配置提供标准化环境。用户浏览其有权访问的产品 (服务或应用程序) 的列表,找到要使用的产品并自行将其作为已配置产品启动。AWS Service Catalog API 还提供对所有用户操作的编程控制。 假设您需要为用户的启动请求构建一个审批工作流。许多解决方案都可以使用 AWS Service Catalog API 来构建复杂的自定义工作流 (例如,ServiceNow)。在本博客文章中,我将从 AWS Service Catalog 管理员的角度介绍如何使用 AWS Lambda、Amazon API Gateway、AWS CloudFormation 和 Amazon Simple Notification Service (Amazon SNS) 构建简单的工作流审批流程。 为构建此审批流程,我将使用 WaitCondition 和 WaitHandle 等 AWS CloudFormation 功能,并使用 AWS Lambda 作为自定义资源来创建简单的审批工作流。如果您正在寻找 AWS 原生解决方案来扩展现有 AWS Service Catalog […]

Read More

光环新网运营的AWS中国(北京)区域HPC集群创建

在上个博客“在AWS云上快速搭建高性能计算(HPC)集群”中,我们介绍了高性能计算的使用场景,框架和如何在AWS Global创建HPC集群,但在光环新网运营的AWS中国(北京)区域并不支持使用CFNCluster直接创建HPC,因此我们需要使用CloudFormation手工创建集群,整个过程并不复杂。步骤如下: 1.进入光环新网运营的AWS中国(北京)区域的Console,然后进入CloudFormation的服务。如下图: 2.点击 “Create New Stack”后,弹出下面的界面。 3.在界面中制定CloudFormation的模板文件如下。 https://s3.cn-north-1.amazonaws.com.cn/cfncluster-cn-north-1/templates/cfncluster.cfn.json 4.在后续界面中下面参数必须定义: Stack name:要创建HPC集群的名称 AvailablityZone:指定要在那个可用区创建HPC集群 VPCId:指定需要创建集群的VPCId MasterSubnetId:指定Master节点的子网ID KeyName:指定EC2服务器访问的key Scheduler:指定高性能计算的管理框架,默认是SGE,有Openlava,Torque等可以选择。 5.可选参数定义: InitialQueueSize:HPC集群的初始节点数 ComputeInstanceType:集群计算节点的类型 MasterInstanceType:Master节点的类型 MaxQueueSize:集群最大节点数 PlacementGroup:节点的放置组 对于全部的配置参数说明,可以参考下面链接: http://cfncluster.readthedocs.io/en/latest/configuration.html 6.点击Next后,输入集群的tag。 7.点击左下方的checkbox运行AWS Cloudformation帮助创建资源,然后点击创建。 8.等待当前HPC集群的创建状态变为COMPLETE,查看下方的Outputs消息输出,找到HPC Master节点的IP。 9.使用前面Output中的Master节点的IP或去Console中的EC2里面找到刚才创建的Master节点的机器,通过ssh连接,然后运行HPC的命令。 总结 在AWS中国区,你可以使用CloudFormation快速的创建HPC集群,AWS提供了丰富的服务器类型供你选择,你可以选择基于CPU或GPU等不同类型的服务器,也可以选择SGE,OpenLava等分布式资源管理软件来调度你的程序,如果我们不配置,默认的资源管理软件是SGE。 作者介绍 蓝勇,AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在DR解决方案、数据仓库、RDS服务、企业应用、自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。

Read More