Category: 大咖专栏


你需要知道的关于高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

综合和特例

还有一些特殊的情况也值得拿出来说一下: 如果我们特别在意存储网络的带宽的限制,完全可以使用带有instance-storage的实例类型,比如i系列和d系列。存储在本地,通过本地总线连接,就没有这个存储网络的限制啦。

某些情况下,追求极致的IOPS,也可以考虑使用条带化技术将多个卷合起来一起使用。

另外,如果我们的流量模型为从磁盘上一次读出,在计算节点上向多个client分发,简单的说就是具有fan-out效果的话,碰到瓶颈的地方大概率应该在EC2 intance的流出限制之上,而不是存储网络限制。

总结

总结一下,要获得期望的高IO。你需要准备

  • a. 合适的磁盘类型,磁盘个数,保证你需要达到IO在单卷和总卷限制范围以内。
  • b. 足够快的从磁盘到EC2的高速网络
  • c. 足够大的机型,以带来足够的inbound/outbound。
  • d. 适当的存储队列,保证磁盘够忙

好了,需要知道的所有关于EC2的IO性能的秘籍都在这儿了,马上动手,去榨干你购买的EC2的所有潜能吧。

作者介绍:

焦杨,AWS解决方案架构师,IT行业老兵,在Moto,NEC,路透,汉柏,AWS等国内外企业从业10余年。2011年之前,从事过web container, EJB container 和大型网站的后台研发工作,醉心于OO和设计模式。2011开始着手基于oVirt和Openstack的私有云平台研发工作,并亲密接触SDN,关注点随之转移到基础架构、分布式和高可用,自此自诩全栈工程师。 2015年加入AWS,担任解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计工作。,

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 AgentGitHub 相关项目

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 ES集群。
  • 准备Amazon EC2实例。
  • 安装2.4.23版本的Apache HTTP服务器。
  • 在Apache HTTP服务器之上安装Amazon Kinesis Agent。
  • 准备ELB(弹性负载均衡)。
  • 创建Amazon ES索引和相应的日志对应关系。
  • 创建Amazon Kinesis Firehose发送系统。
  • 创建所有的IAM角色以及相应的权限规则。例如,Firehose需要将日志数据备份到S3中,那么就需要往目标S3桶上传数据的权限。
  • 为Firehose发送系统配置CloudWatch 日志流和日志组,以便在日志发送出现异常时进行排查。

EKK架构示意图:

要搭建本文中的EKK架构,你需要以下先决条件:

  • US West区域的Amazon EC2密钥对。
  • US West区域的S3桶。
  • US west区域的默认VPC。
  • 具有管理员权限的IAM角色,用来确保Amazon ES和Amazon S3通过Firehose获取到EC2上的日志数据

让我们开始吧:

从启动AWS CloudFormation模板开始创建整个系统

1. 在AWS CloudFormation控制台上,选择来 启动模板。请确保你在US West区域。

提示:如果你想下载这个模板并随后上传至AWS CloudFormation,你可以从随后给出的S3桶里面下载模板到你本地的电脑中。

2. 选择下一步

3. 在详细设置页面,提供以下信息:

a)软件栈名称:为你的EKK系统命名

b)实例类型:选择安装Apache HTTP服务器的EC2实例类型

c)密钥:选择US West区域的密钥对

d) SSH位置:可以通过SSH连接到EC2实例的IP地址范围,默认为0.0.0.0/0

e)web服务端口:Web服务器的监听端口,默认为80

4. 选择下一步

5. 在选项页面,为AWS CloudFormation模板提供你想要的可选信息,然后选择下一步。

6. 在回顾页面,检查模板的各项设置,点击确认然后选择创建系统。

整个创建过程大约耗时10-15分钟。

配置Amazon Kinesis Agent

等待AWS CloudFormation创建完整个EKK系统,然后开始配置Amazon Kinesis Agent。

1. 在AWS CloudFormation控制台中,选择资源标签页,找到Firehose发送系统的名称。你在随后的第3步中需要它来配置Agent。

2. 在输出标签页,找到并记录下Web服务器的公有IP地址。你随后需要通过它SSH登录到Web服务器上配置Agent。获得更多关于通过SSH连接EC2实例的信息,请参考通过SSH登录你的Linux实例.

3. 在Web服务器的命令行上,运行以下命令:

sudo vi /etc/aws-kinesis/agent.json

该命令会打开配置文件,agent.json,内容如下:

{ "cloudwatch.emitMetrics": true, "firehose.endpoint": "firehose.us-west-2.amazonaws.com", "awsAccessKeyId": "", "awsSecretAccessKey": "", "flows": [ { "filePattern": "/var/log/httpd/access_log", "deliveryStream": "", "dataProcessingOptions": [ { "optionName": "LOGTOJSON", "logFormat": "COMMONAPACHELOG" } ] } ] }

4. 将在资源标签页获得的Firehose发送系统名称填入deliveryStream栏目中,然后保存并退出。

5. 在命令行上运行以下命令:

sudo service aws-kinesis-agent restart

6. 在AWS CloudFormation 控制台中查看Amazon ES对应的逻辑ID域

7. 在AWS Elasticsearch服务页面中你可以查看到由AWS CloudFormation创建的ES集群

配置Kibana并分析日志数据

Amazon ES为每一个ES域都默认提供了Kibana的安装,你可以在域的展示页面找到Kibana endpoin的相关信息。

1. 在Amazon ES控制台,选择Kibana endpoin

2. 在Kibana中,为索引名称和模式选项键入logmonitor。该值是你为Web访问日志创建的AWS ES索引名称。来自AWS ELB的健康检查会产生Apache的访问日志,随后流经整个EKK数据线,最后在Kibana中被可视化展现出来供分析所用。

3. 在时间选择中,选择datetime

4. 在Kibana控制台,选择发现标签页来观察Apache日志。

Kibana提供了条形图、折线图、散点图、直方图、饼图等来对日志文件进行分析。

过去30天访问Web服务器的IP地址饼图

过去5分钟内访问Web服务器的IP地址条形图

你还可以将http响应、IP地址等各类信息绘制成图表,甚至组合它们,以此来提供对于Apache日志的更深洞见。

监控日志收集分析系统

在Firehose控制台上选择流数据,然后选择监控标签页来查询CloudWatch中针对Firehose发送系统的度量值。

当日志发送失败后,Amazon S3和Amazon ES上等日志会帮助你定位问题。比如,如下的截图显示了因为索引上的日期映射没有和源日志文件保持一致。

结论

本文中,我们展示了如何通过Amazon Kinesis Agent, Amazon ES和Firehose将Apache日志传输至Kibana并进行可视化分析。值得注意的是,Firehose会根据应用系统产生日志的速率来自动进行伸缩。获取更多如何扩展Amazon ES集群的信息,请参考Amazon ES 开发指南.

综上所述,使用类似Amazon ES和Amazon Kinesis Firehose这类的托管服务,让管理和维护日志收集分析系统变得十分轻松。更棒的是,你还可以通过在日志流数据上直接运行SQL语句来进一步提升EKK系统的性能和功能。而这一切都可以基于本文中给出的AWS CloudFormation 模板

 

译者介绍:

刘磊,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请7项国家发明专利。现任职于AWS中国专家服务团队,致力于为客户提供基于AWS服务的专业大数据解决方案、项目实施以及咨询服务。

利用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架构和私有云、混合云、公有云的解决方案融合。

 

搭建基于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 S3的EMR集群:

aws emr create-cluster --termination-protected --applications Name=Hadoop Name=Hive Name=HBase Name=Spark Name=Phoenix --ec2-attributes '{"KeyName":""}' --release-label emr-5.7.0 --instance-groups '[{"InstanceCount":1,"InstanceGroupType":"MASTER","InstanceType":"m3.xlarge","Name":"Master - 1"},{"InstanceCount":20,"BidPrice":"0.15","InstanceGroupType":"CORE","InstanceType":"m3.2xlarge","Name":"Core - 2"}]' --configurations '[{"Classification":"emrfs-site","Properties":{"fs.s3.consistent.retryPeriodSeconds":"1","fs.s3.consistent":"true","fs.s3.consistent.retryCount":"5","fs.s3.consistent.metadata.tableName":"YOUR_CONSISTENT_VIEW_TABLE_NAME"},"Configurations":[]},{"Classification":"hbase","Properties":{"hbase.emr.storageMode":"s3","hbase.emr.readreplica.enabled":"true"},"Configurations":[]},{"Classification":"hbase-site","Properties":{"hbase.rootdir":"s3:///"},"Configurations":[]}]' --service-role EMR_DefaultRole --name 'HBase Read Replica'

配置文件示例JSON

[ 
   { 
      "Classification":"hbase-site",
      "Properties":{ 
         "hbase.rootdir":"s3://{S3_LOCATION}",
      }
   },
   { 
      "Classification":"hbase",
      "Properties":{ 
         "hbase.emr.storageMode":"s3",
         "hbase.emr.readreplica.enabled":"true"
      }
   }
]

向主集群添加数据

需要特别注意的是,在使用HBase读备份集群时,你必须要确保主集群上所有的写操作都被刷新到S3桶的HFile中。读备份集群会读取这些HFile中的数据,任何没有从Memstore刷新到S3的数据都不能通过读备份集群访问。为了确保读备份集群总是读到最新的数据,请参考以下步骤:

  • 写入数据到主集群(大批量写入请使用Bulkload)
  • 确保数据被刷新到S3桶中(使用Flush命令)
  • 等待region 分割以及合并操作完成以确保HBase表的元数据信息保持一致性状态
  • 如果任何region发生了分割、合并操作,或者表的元数据信息发生了变化(表的增加和删减),请在从集群上运行refresh_meta命令
  • 当HBase表发生更新操作后,请在从集群上运行refresh_hfiles命令

从备份集群读区数据

你可以像往常一样从备份集群检索任何数据。

从主集群读取数据的截图:

从备份集群读取数据的截图:

可以看出,两个集群返回了同样的数据。

保持备份集群和主集群的一致性
为了保持备份集群数据和主集群的一致性,请参考以下建议:

在备份集群上:

1.运行refresh_hfiles命令:

  • HBase表中的数据发生变化时(增、删、改)

2.运行refresh_meta:

  • Region发生变化时(splits,compacts)或者集群中增加、删除了HBase表

在主集群上:

1.如果启用了compaction,运行compaction命令以避免Major Compation被触发引起数据的不一致性。

相关的属性和命令:
HBase属性:

Config Default Ex planation
hbase.meta.table.suffix “” Adds a suffix to the meta table name: value=’test’ -> ‘hbase:meta_test’
hbase.global.readonly.enabled False Puts the entire cluster into read-only mode
Hbase.meta.startup.refresh False Syncs the meta table with the backing storage. Used to pick up new tables or regions.

如果hbase.emr.readreplica.enabled被设置为true,那么上述属性会被自动设置好。

HBase命令:

Command Description
refresh_hfiles <Tablename Refreshes HFiles from disk. Used to pick up new edits on a read replica.
clear_block_cache <tablename> Clears the cache for the specified table.
refresh_meta Syncs the meta table with the backing storage. Used to pick up new tables/regions.

总结

现在你可以为HBase建立高可用的读备份集群,通过它,在主集群发生异常情况时,你仍然可以获取稳定的数据查询服务。

 

作者介绍

刘磊,AWS大数据顾问,曾供职于中国银联电子支付研究院,期间获得上海市科技进步一等奖,并申请7项国家发明专利。现任职于AWS中国专家服务团队,致力于为客户提供基于AWS服务的专业大数据解决方案、项目实施以及咨询服务。

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

作者:薛峰

上一篇文章中我们介绍了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 package 打包。

上传源文件

把buildspec.yml文件中的 <bucket-name> 等变量值替换成你的具体的值。

在当前目录下除了 md 文件的其它文件打包成 codebuild.zip,然后把这个 zip 文件上传你自己的 S3桶中。

配置 CodeBuild 项目

打开 CodeBuild 控制台

点击 Create project。

在 Configure your project 页

Project name 输入 serverlessCodebuild

Source provider 选择 Amazon S3

Bucket 栏选择我们的刚才上传 zip 文件的 S3 桶名称

S3 object key 输入 codebuild.zip。

Environment image 保持选择 Use an image managed by AWS CodeBuild

Operating system 选择 Ubuntu

Runtime 选 Node.js

Version 选择 aws/codebuild/nodejs:4.3.2

Artifacts type 选 Amazon S3

Bucket name 还选择我们的刚才上传 zip 文件的 S3 桶名称

确认 Create a service role in your account 已选中

Role name 输入 serverlessCodebuild

点击右下角 Continue 按钮

在 Review 页点击右下方的 Save and build 按钮。

创建成功后前进到 Build projects 列表页,此时刚刚新建的项目应该是选中的状态。点击左上角 Start build 按钮。

在 Start new build 页,直接点击右下角 Start build 按钮。

在 Build 页可以查看构建进行的进度信息。注意看 Phase details 下面的输出内容。 构建成功完成以后,可以到我们的 S3 桶中查看结果,可以看到创建出一个 serverlessCodebuild 目录,里面就是构建的成果—— output_codebuild.yaml 文件。我们把它下载到本地,就可以用它再执行 CloudFormation 部署。

使用 CloudFormation 部署

执行以下命令

aws cloudformation deploy \

   --template-file output_codebuild.yaml \

   --stack-name serverlessCodebuild \

   --capabilities CAPABILITY_IAM

顺利地话,会看到逐渐输出的返回结果

Waiting for changeset to be created..


Waiting for stack create/update to complete

Successfully created/updated stack - serverlessCodebuild

这时到 CloudFormation 的控制台已经创建出一个 serverlessCodebuild ,整个过程大约持续 1 到 2 分钟。

然后到 API Gateway 控制台,可以看到创建出的 serverlessCodebuild 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

点击它,打开一个新窗口,显示

“The time in Los Angeles is Mon Aug 07 2017 03:32:42 GMT-0700 (PDT)”
表示已经部署成功。

部署配置AWS CodePipeline

每次都要手工执行aws cloudformation deploy命令来部署仍然有些繁琐,而且手工部署难免会有人工的失误。下面我们使用AWS CodePipeline来最终实现完全自动化的部署。

AWS CodePipeline 是一个托管的持续集成与持续交付服务,可以实现快速而可靠的应用程序和基础设施更新。每次更改代码时,CodePipeline 都会根据我们定义的发布流程模型构建、测试和部署代码,就像管道一样逐个步骤的执行流程中的每一步操作,还支持可选的人工审核步骤。和CodeBuild一样, CodePipeline也是只按实际使用量付费,同样无需为预置的资源空闲付费。

我们下面这个例子,Lambda函数还是使用了time依赖库,仍然使用CodeBuild安装依赖库、CloudFormation进行部署,这次我们配置CodePipeline来完成构建和部署的全部流程,实现持续集成。

总的操作流程主要是以下几步:

  1. 在 github 上创建一个库存放源文件。
  2. 创建一个 CodeBuild 项目,用于构建无服务器应用。
  3. 创建一个 IAM 角色,用于 CloudFormation 部署无服务器应用。
  4. 创建一个 CodePipeline 项目,把上述若干步骤和资源组建成管道。

在 github 上创建一个库存放源文件

请在你自己的github新建一个存储库,名为 serverlessCodepipepline。

从以下git库下载源码。

https://github.com/xfsnow/serverless/blob/master/sam/codepipeline

放在我们自已的 serverlessCodepipepline 库的根目录下。

把 buildspec.yml 中的 <bucket> 更新成自己的桶名称,再 commit 到 git 库中。

配置 CodeBuild 项目

  • 打开 CodeBuild 控制台,点击 Create project。

在 Configure your project 页

Project name 输入 serverlessCodepipeline

Source provider 选择 Github

Repository 选择 Use a repository in my account

Repository URL 输入我们自己的库的路径,比如 https://github.com/xfsnow/serverlessCodepipepline

  • Environment image 保持选择 Use an image managed by AWS CodeBuild

Operating system 选择 Ubuntu

Runtime 选 Node.js

Version 选择 aws/codebuild/nodejs:4.3.2

Build specification 保持选中 Use the buildspec.yml in the source code root directory

Artifacts type 选 Amazon S3

Bucket name 还选择我们在 buildspec.yml 中指定的 S3 桶名称

确认 Create a service role in your account 已选中

Role name 输入 serverlessCodebuild,点击右下角 Continue 按钮。

  • 在 Review 页点击右下方的 Save and build 按钮。

创建成功后前进到 Build projects 列表页,此时刚刚新建的项目应该是选中的状态。点击左上角 Start build 按钮。

在 Start new build 页,直接点击右下角 Start build 按钮。

  • 在 Build 页可以查看构建进行的进度信息。注意看 Phase details 下面的输出内容。

构建成功完成以后,可以到我们的 S3 桶中查看结果,可以看到创建出一个 serverlessCodepipeline 目录,里面就是构建的成果—— output-codepipeline.yaml 文件。

我们可以把它下载到本地看一下,后续我们继续配置 CodePipeline 就是用它来做无服务器资源的部署。

配置 IAM 角色

登录 AWS 管理控制台。点击左侧导航链接中的 Roles,点击 Create new role 按钮。

  • 在 Select role type 页选择 AWS Service Role,找到 AWS Cloudformation Role 点击其右边的 Select 按钮。
  • 在 Attach Policy 页,选择 AWSLambdaExecute。点击 Next Step 按钮。
  • 在 Set role name and review 页, Role name 输入 cloudformation-lambda-execution,然后点击 Create role 按钮。
  • 打开刚才创建的角色,在 Permissions 选项卡下,点击 Inline Policies 展开之,然后选择 click here 链接。

选择 Custom Policy,然后选择 Select。

在 Policy Name 中,输入 cloudformation-deploy-lambda ,然后将以下内容中的 region account_id 替换成你自己的值,粘贴到 Policy Document 字段中:

{

    "Statement": [

        {

            "Action": [

                "s3:GetObject",

                "s3:GetObjectVersion",

                "s3:GetBucketVersioning"

            ],

            "Resource": "*",

            "Effect": "Allow"

        },

        {

            "Action": [

                "s3:PutObject"

            ],

            "Resource": [

                "arn:aws:s3:::codepipeline*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "lambda:*"

            ],

            "Resource": [

                "arn:aws:lambda:region:account-id:function:*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "apigateway:*"

            ],

            "Resource": [

                "arn:aws:apigateway:region::*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:GetRole",

                "iam:CreateRole",

                "iam:DeleteRole"

            ],

            "Resource": [

                "arn:aws:iam::account-id:role/*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:AttachRolePolicy",

                "iam:DetachRolePolicy"

            ],

            "Resource": [

                "arn:aws:iam::account-id:role/*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "iam:PassRole"

            ],

            "Resource": [

                "*"

            ],

            "Effect": "Allow"

        },

        {

            "Action": [

                "cloudformation:CreateChangeSet"

            ],

            "Resource": [

                "arn:aws:cloudformation:region:aws:transform/Serverless-2016-10-31"

            ],

            "Effect": "Allow"

        }

    ],

    "Version": "2012-10-17"

}    

点击 Validate Policy,然后点击 Apply Policy。

配置 CodePipeline 项目
打开 CodePipeline 控制台,点击 Create project。

  • 在 Step 1: Name 页

Project name 输入 serverlessCodepipeline,点击“Next Step” 按钮。

  • 在 Step 2: Source 页

Source provider 选择 Github,然后点击 Connect to GitHub 按钮,关联 GitHub 账号。按提示完成关联操作。

回到 AWS 页面后,Repository 选择前述我们自己创建的存储库。

Branch 选择 master ,点击“Next Step” 按钮。

  • 在 Step 3: Build 页

Build provider 选择 AWS CodeBuild

Configure your project 保持选中 Select an existing build project。

Project name 在下拉列表中选择我们前面创建的 serverlessCodepipeline 项目。

  •  在 Step 4: Deploy 页

Deployment provider 选择 AWS CloudFormation。

Action mode 选择 Create or replace a change set。

Stack name 输入 serverlessCodepipeline。

Change set name 输入 serverlessCodepipelineChangeSet。

Template file 输入 buildspec.yml 中指定的构建结果文件名 output-codepipeline.yaml。

Capabilities 选择 CAPABILITY_IAM。

Role name 选择我们前面创建的 IAM 角色 cloudformation-lambda-execution。 点击 Next Step 按钮。

  • 在 Step 5: Service Role 页

点击 Create Role 按钮,在弹出的 IAM AWS CodePipeline is requesting permission to use resources in your account 页面,直接点击右下角 Allow 按钮,返回后点击 Next Step 按钮。

  • 在 Step 6: Review 页面,直接点击右下角 点击右下角的 Create Pipeline 按钮。最后来到 serverlessCodepipeline 项目详情页。
  • 增加测试部署阶段 在 serverlessCodepipeline 详情页点击 Edit 按钮。

在 Staging 阶段下面点击 +Stage 链接。

在 Stage name 栏输入 Beta,然后点击其下面的 +Action 按钮。

在 Action category 中,选择Deploy。

在 Action name 中,输入 executeChangeSet。

在 Deployment provider 中,选择 AWS CloudFormation。

在 Action mode: 中,选择 execute a changeset。前一步我们已经创建了 ChangeSet,将 SAM 模板转换为完整的 AWS CloudFormation 格式,现在我们要使用 deployChangeSet 部署 AWS CloudFormation 模板了。

在 Stack name:中,输入 serverlessCodepipeline。

在 Change set name:中,输入 serverlessCodepipelineChangeSet。

选择 Add Action。

回到页面顶部点击 Save pipeline changes。

选择 Save and continue。

查看结果

我们在 serverlessCodepipeline 项目详情页稍等10秒左右,Pipeline 会自动开始第一次部署。可以随时查看到各个步骤的执行情况,比如:

Source
GitHub
Succeeded 2 min ago
d24ff81
最后等到 Beta 步骤也完成,这时到 CloudFormation 的控制台查看已经创建出一个 serverlessCodepipeline ,整个过程大约持续 3到5 分钟。

然后到 API Gateway 控制台,可以看到创建出的 serverlessCodepipeline 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

复制此 URL,打开一个新窗口,粘贴进地址栏,然后在后面再输入 /time,组成形如

https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod/time

的链接再访问之,显示

“The time in Los Angeles is Mon Aug 07 2017 03:31:39 GMT-0700 (PDT)”
表示已经部署成功。

然后我们模拟代码更新,把你自己的 github 存储库中的 README.md 文件编辑一下,然后 git commit 到 github 上去。 然后再回到 serverlessCodepipeline 详情页,稍等一会我们会看到从 Source 开始整个管道会再次执行一遍。

执行到每一步时,我们都可以点击 Detail 链接到相关服务的详情页查看具体进度。比如 CloudFormation 会创建出一个新的 serverlessCodepipelineChangeSet 来执行变更。

最后到 API Gateway 的 serverlessCodepipeline API,选择一个 Stage ,再点选 Deployment History 可以看到 Deployment date时间更新了。

小结

今天我们继续结合实例,为大家讲解了使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。这些也是基于AWS 无服务器应用模型和SAM模板,再与其它AWS运维的服务集成,共同实现无服务器应用的自动化运维。

相关资源链接

Serverless Application Model (SAM):
https://github.com/awslabs/serverless-application-model

无服务器服务官网:

AWS Lambda: https://aws.amazon.com/lambda

Amazon API Gateway: https://aws.amazon.com/api-gateway

运维相关的服务:

CloudFormation: https://aws.amazon.com/cloudformation

CodeBuild: https://aws.amaz.com/codebuild

CodePipeline: https://aws.amazon.com/codepipeline

 

作者介绍:

薛峰,亚马逊AWS解决方案架构师,AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

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

作者:薛峰

背景介绍

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:

          Type: Api

          Properties:

            Path:
/{proxy+}

            Method: ANY 

  ListTable:

    Type:
AWS::Serverless::SimpleTable 

最上面是模板格式的版本号和Transform声明。Transform声明告诉 CloudFormation这是一个 SAM 模板,需要转换成标准模板再执行。它的值取固定值,这里是 AWS::Serverless-2016-10-31,告诉CloudFormation这个模板里的声明都是无服务器应用的描述,以及进行相应的转换。

其余的两段其实都是 Resources 节点的子节点。这2段就是具体资源的声明:

GetHtmlFunction 段,Type: AWS::Serverless::Function,意思是创建一个Lambda函数,它有若干属性,如CodeUri指定函数的代码在S3的URL,Runtime 指定运行时的语言和版本,Policies 指定它的 IAM策略,以赋给它处理下游资源的权限。

Events 段,声明Lambda函数要响应的事件源。这里只有一个事件源,即创建一个 API Gateway 的 API,它有几个 API 相关的属性,比如路径、请求方式。

ListTable 这个资源Type是 AWS::Serverless::SimpleTable ,现在实际上是创建一个DynamoDB 表格。这里没有额外属性,就是以默认的容量规模创建,DynamoDB表容量默认值是每秒5次读写。

SAM 模板功能特性

可以和其它非SAM CloudFormation资源混用在同一个模板里 。SAM模板只增加了3种新资源,Lambda函数、API 和 SimpleTable,我们还可以使用其它标准CloudFormation资源,比如 S3 桶, Kinesis流,Step Function等等。

其它CloudFormation的标准功能SAM模板都支持,比如使用参数、映射和输出等,允许我们在CloudFormation执行时动态传入参数等, CloudFormation的内置函数我们在SAM也都可以使用,如连接字符串、拆分字符串等等。ImportValue也可使用,允许我们从现有架构中直接调取参数值,可以不再使用参数、映射等方式。总之这些标准功能使SAM模板可以和CloudFormation模板一样享受动态化的便利。

SAM 基于 CloudFormation,所以也是支持YAML 和JSON两种格式。

SAM 模板特有资源类型

SAM 模板新增3个特有资源类型,前面的简单例子已经展示了 ,即:AWS::Serverless::Function,AWS::Serverless::Api,AWS::Serverless::SimpleTable。这是当前Transform版本为 AWS::Serverless-2016-10-31所支持的特有资源类型。将来还有可能增加更多资源类型,到时请注意升级换用相应的Transform版本号。

第1个特有资源AWS::Serverless::Function 就是声明Lambda函数,模板中的包括Lambda函数所有的属性,如Handler、运行时、代码地址、描述等等。Events用来声明事件源,同一函数可以支持多个事件源。 Policies 声明IAM策略。Environment 可以声明环境变量,可用于传递给 Lambda函数。另外还有 Tags声明标签,这是 AWS 管理资源的通用功能,比如用于资源分组,账单和成本分解等。

第2个特有资源是 AWS::Serverless::Api,用于声明 API Gateway,关于API的详细定义,在 DefinitionUri 指定的swagger.yml里。其余的属性不多,主要是:StageName 阶段名称、CacheClusterEnabled 是否启用API Gateway的缓存,以及 CacheClusterSize缓存的容量。最后的Variables是传递给API 的参数,比如阶段参数,也是用来灵活部署的。

第3个特有资源是AWS::Serverless::SimpleTable,用于创建 DynamoDb 表。我们需要做的就是声明一下主键、类型,以及配置的容量规模。

AWS::Serverless::Function 事件源
在SAM模板中AWS::Serverless::Function资源下 Events 节点声明事件源。我们知道AWS Lambda 是事件驱动的无服务器函数服务,所以事件源也是部署Lambda函数的重要属性。事件源可以有很多种,大体分为3类:

  • 数据状态变化,如S3对象的新增、删除。
  • 请求端点,这里主要指的是通过 API  Gateway 暴露为对外服务的 HTTP API 接口。
  • 资源状态变化,如EC2实例的启动、停止等状态。

具体产生的事件源来自这些服务:S3、SNS、Kinesis、DynamoDB、Schedule、CloudWatchEvent、AlexaSkill。各事件源的各种事件及属性全部支持。具体这里不再赘述,大家可以参考各服务的事件部分相关文档。

Lambda环境变量

Lambda环境变量是可以动态传递给我们的函数的键值对,比如IAM的验证凭据,API的密钥等等。Lambda环境变量是Lambda服务本身的功能,在无服务器应用模型SAM里,我们可以方便地把环境变量管理起来。在SAM模板中以 Parameters 节点来声明环境变量。可以通过标准环境变量API使用,如 Node.js 的process.env 或 Python的os.environ,即Lambda的环境变量会添加到Node.js 的process.env 里,方便咱们开发时使用。下面我们看一个环境变量的具体例子。

使用SAM模板管理Lambda环境变量

请先从以下git库下载源码。

https://github.com/xfsnow/serverless/tree/master/sam/parameters

我们打开 parameters.yaml,看下面这个片段。

Parameters:

  MyEnvironment:

    Type: String

    Default: testing

    AllowedValues:

      - testing

      - staging

      - prod

    Description: Environment of this stack of resources

这里我们声明了一个Lambda环境变量,变量名是MyEnvironment。它的属性都可以顾名思义,类型是字符串,默认值是testing,可取值是testing、staging和 prod。最后还有一个描述。我们建议给各种变量和资源添加描述,以清楚说明它们具体的使用情况。

ApiHelloFunction:

    Type: AWS::Serverless::Function

    Properties:

      Handler: index.handler

      Runtime: nodejs6.10

      Environment:

        Variables:

          S3_BUCKET: !Ref MyEnvironment

然后在声明Lambda函数时在 Variables: 段声明一个环境变量S3_BUCKET,它的值使用CloudFormatioin内置函数!Ref读取SAM模板中的环境变量MyEnvironment。

var bucketName = process.env.S3_BUCKET;

相应地,在我们的Lambda函数代码中,index.js 中上述这段就可以通过全局变量process.env 获取到S3_BUCKET这个环境变量值了。

用CloudFormation部署SAM模板

我们还使用上述Lambda环境变量这个例子,具体介绍一下CloudFormation部署的方法。

以下操作流程使用 AWS CLI 命令执行。准备环境及了解 AWS CLI 基本功能请参见 https://aws.amazon.com/cn/cli/

请先从以下git库下载源码。

https://github.com/xfsnow/serverless/tree/master/sam/parameters

把下面命令中的 <bucket-name> 等变量值替换成你的具体的值。

在当前目录下执行以下命令,把文件上传到S3并打包成可用于 CloudFormation 的模板文件。

aws cloudformation package \

    --template-file parameters.yaml \

    --s3-bucket <bucket-name> \

    --output-template-file packaged_parameters.yaml

确认已经生成 packaged_parameters.yaml 文件。

执行以下命令。–parameter-overrides MyEnvironment=prod 表示部署时为 CloudFormation 的模板参数指定值为 prod。

aws cloudformation deploy \

   --template-file output_parameters.yaml \

   --stack-name parameters \

   --capabilities CAPABILITY_IAM \

   --parameter-overrides MyEnvironment=prod

顺利地话,会看到逐渐输出的返回结果。

Waiting for changeset to be created..

Waiting for stack create/update to complete

Successfully created/updated stack - lambdaProxy

这时到 CloudFormation 的控制台已经创建出一个 lambdaProxy,整个过程大约持续 1 到 2 分钟。 然后到 API Gateway 控制台,可以看到创建出的 lambdaProxy 的 API,点击其 Stages 下的 Prod 链接,可以看到形如下面的调用 URL: Invoke URL: https://xxxxxxxxx.execute-api.my-region.amazonaws.com/Prod

点击它,打开一个新窗口,显示

{“bucketName”:”prod”}

表示已经部署成功。

再执行一次 aws cloudformation deploy,把 MyEnvironment 参数变成 testing

aws cloudformation deploy \

   --template-file output_parameters.yaml \

   --stack-name parameters \

   --capabilities CAPABILITY_IAM \

   --parameter-overrides MyEnvironment=testing

等待执行完毕后,刷新刚才的调用 URL,可以看到内容已经更新成了

{“bucketName”:”testing”}

这个例子演示了我们在SAM模板中定义的环境变量在具体部署时可以灵活赋成不同的值,然后部署出相应的效果。

小结

今天我们介绍了AWS 无服务器应用模型和SAM模板的基本功能和特性,并带领大家用一个实例体验了通过CloudFormation部署SAM模板。随着无服务器应用开发逐渐复杂,规模越来越大,涉及的服务和资源也会越来越多,SAM确实为我们提供了一种使用AWS服务进行统一管理的方法,希望大家多多体验。

下一篇中,我们将进一步为大家讲解使用AWS CodeBuild 构建 Lambda函数以及使用AWS CodePipeline实现自动化持续集成。

 

作者介绍:

薛峰,亚马逊AWS解决方案架构师,AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内和全球的应用和推广,在大规模并发应用架构、移动应用以及无服务器架构等方面有丰富的实践经验。在加入AWS之前曾长期从事互联网应用开发,先后在新浪、唯品会等公司担任架构师、技术总监等职位。对跨平台多终端的互联网应用架构和方案有深入的研究。

挖掘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, CSV, TSV, Sequence, Avro, RegexSerDe等等。这意味着我们无需再做数据加载和转化,同时也消除了存储重复数据带来的成本浪费。第五,通过对开放数据格式的支持,客户的不同团队也可以借助其他的AWS服务访问同一组S3上的数据,实现协同办公。拥有上述这些优势的同时,因为Redshift Spectrum 是 Amazon Redshift的内置功能,客户同时也享受了与Amazon Redshift同级别的端到端的安全、合规、以及安全认证。

Redshift Spectrum最佳实践

使用Redshift Spectrum时,我们建议可以从数据分区,列数据结构和数据压缩这几个关键点出发实现S3上数据查询效率的提升以及降低查询成本。数据分区方面,按照日期、时间或其他客户自定义的key来对数据进行分区可以帮助Redshift Spectrum 在查询中动态的移除不相关分区以减少扫描的数据量。数据结构方面,我们推荐使用列存储,比如Parquet格式,这样Redshift Spectrum只需扫描要查询的列而不是整个数据,这可以进一步减少扫描的数据量。数据压缩方面,如果数据可以预先用Redshift Spectrum支持的压缩格式压缩,我们同样可以再次减少扫描的数据量。

另外,从数据访问频率来看,我们建议将频繁访问的数据放到Amazon Redshift集群中,以获得Redshift作为数据仓库服务带来的众多优势。同时,更多的海量数据可以以多种开放数据格式存储在S3上,比如历史数据或近期数据,利用Redshift Spectrum 将S3变成一个可随时支持SQL查询的数据湖。

下边再列举六个具体使用时的技巧:

  1. 使用多个临时Redshift 集群提升并发:Redshift Spectrum支持多个Redshift集群访问同一组S3上的数据,我们可以考虑在业务高峰期时临时开启多个Redshift集群,提升并发支持更多的查询任务。因为数据庞大的表我们可以放在S3上,所以这些临时Redshift集群本地只需存储相对少量的数据即可胜任,在高峰期过后可以关闭这些临时集群。这样客户用相对较小的几个集群就可以轻松应对高峰的大并发。
  2. 列存储文件的分区应尽量基于常用的数据列:常用来做filter、join等操作的数据列是分区的首选。另外,分区的粒度过细可能会使读取分区信息花费更多时间,但同时也会极大减少数据查询时的数据量。客户可以根据自己的实际情况权衡。最后,S3上的数据文件大小应尽量平均,例如10个256MB的文件要比1个1GB+6个256MB的文件读取更高效。
  3. 合理配置Redshift集群以优化Redshift Spectrum的性能:在Redshift Spectrum查询S3上的数据时,其并行线程取决于两个因素:(1) Query层面 – 每个slice上每个query可并行执行查询的线程数 (上限是每个slice每个query最多10个线程) (2) 节点层面 – 每个节点拥有的slice数量,不同类型节点的slice数量也不同。所以做一个简单的数学运算:当数据文件总数 ≤ (1) × (2),则在集群内部署更多的节点并不会提升性能。这个方法可以帮我们基于数据文件数量配置大小合理的Redshift 集群,从而在保证性能的同时减少资源浪费。
  4. 单表筛选、聚合类的查询在Redshift Spectrum上更有性能优势:这类没有join的查询任务通常性能瓶颈在I/O层面,比如数据扫面速度,这方面往往Redshift Spectrum可以比Redshift做的更快。
  5. 通过推送predicate类操作到Redshift Spectrum 提升对数据查询速度:Redshift Spectrum对S3上数据的扫描,投影,筛选,聚合等操作是独立于Redshift集群的。这类操作同时也不会占用Redshift集群的资源。常用的这类指令操作例如group by, like, count, sum, avg, min, max, regex_replace等等。我们可以善用这类操作减少Redshift集群的负载,提升查询效率
  6. 基于表的尺寸合理分配存储:我们建议尽量将大尺寸的表分成多个文件(诸如包含原始数据)放在S3上,而只将中小尺寸的表放入Redshift集群。这样在进行常规join查询时可以取得比较均衡的性能表现。

通过上述的介绍,希望大家对Redshift Spectrum有一个基本的了解。通过高度的并行处理,查询的优化以及对EB级别数据的复杂查询支持,相信Redshift Spectrum 能真正帮助企业客户挖掘海量数据的价值,在大数据分析上更进一步。

作者介绍

刘宁,致力于AWS数据库云服务的应用和推广。在加入AWS之前,他曾任微软中国企业服务部产品营销经理,华侨银行科技部IT产品经理,对企业应用设计及架构有着深刻了解。

原文链接:

https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-spectrum-extends-data-warehousing-out-to-exabytes-no-loading-required/

https://aws.amazon.com/cn/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/

动态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 ConfigAWS 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” : [ Applications, … ],
“BootstrapActions” [ Bootstrap Actions, … ],
“Configurations” : [ Configurations, … ],
“Instances” : JobFlowInstancesConfig,
“JobFlowRole” : String,
“LogUri” : String,
“Name” : String,
“ReleaseLabel” : String,
“ServiceRole” : String,
“Tags” : [ Resource Tag, … ],
“VisibleToAllUsers” : Boolean
}
}

在AWS中AWS Service Catalog可用于分配经批准的产品(服务器,数据库,网站)。 这为IT管理员在哪些用户可以访问哪些产品的方面,提供了更多的灵活性。 AWS Service Catalog还使他们有能力根据业务标准执行合规性。

AWS IAM用于控制哪些用户可以访问哪些AWS服务和资源。 通过使用IAM角色,你可以避免在代码中使用root凭证来访问AWS资源。
在这个示例中,我们给予团队领导者完全的EMR访问包括控制台和API访问(不在此处介绍),并为开发者提供只读访问并且不提供控制台访问权限。 如果开发者想要运行这个任务,开发者只需要PEM文件。

IAM策略

以下策略使团队领导者拥有的完全的EMR访问:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“cloudwatch:*”,
“cloudformation:CreateStack”,
“cloudformation:DescribeStackEvents”,
“ec2:AuthorizeSecurityGroupIngress”,
“ec2:AuthorizeSecurityGroupEgress”,
“ec2:CancelSpotInstanceRequests”,
“ec2:CreateRoute”,
“ec2:CreateSecurityGroup”,
“ec2:CreateTags”,
“ec2:DeleteRoute”,
“ec2:DeleteTags”,
“ec2:DeleteSecurityGroup”,
“ec2:DescribeAvailabilityZones”,
“ec2:DescribeAccountAttributes”,
“ec2:DescribeInstances”,
“ec2:DescribeKeyPairs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeSecurityGroups”,
“ec2:DescribeSpotInstanceRequests”,
“ec2:DescribeSpotPriceHistory”,
“ec2:DescribeSubnets”,
“ec2:DescribeVpcAttribute”,
“ec2:DescribeVpcs”,
“ec2:DescribeRouteTables”,
“ec2:DescribeNetworkAcls”,
“ec2:CreateVpcEndpoint”,
“ec2:ModifyImageAttribute”,
“ec2:ModifyInstanceAttribute”,
“ec2:RequestSpotInstances”,
“ec2:RevokeSecurityGroupEgress”,
“ec2:RunInstances”,
“ec2:TerminateInstances”,
“elasticmapreduce:*”,
“iam:GetPolicy”,
“iam:GetPolicyVersion”,
“iam:ListRoles”,
“iam:PassRole”,
“kms:List*”,
“s3:*”,
“sdb:*”,
“support:CreateCase”,
“support:DescribeServices”,
“support:DescribeSeverityLevels”
],
“Resource”: “*”
}
]
}

以下策略使开发人员拥有只读访问:

{

“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“elasticmapreduce:Describe*”,
“elasticmapreduce:List*”,
“s3:GetObject”,
“s3:ListAllMyBuckets”,
“s3:ListBucket”,
“sdb:Select”,
“cloudwatch:GetMetricStatistics”
],
“Resource”: “*”
}
]
}

这些是IAM管理的策略。如果要更改权限,你可以创建自己的IAM自定义策略

监测

尽可能使用AWS CloudTrailAmazon CloudwatchAmazon VPCAmazon S3Elastic Load Balancing提供的日志。 你可以使用AWS Config,Trusted Advisor和CloudWatch的事件和警报来监控这些日志。
AWS CloudTrail可用于在AWS中记录API调用。 它可以帮助你解决问题,确保你的环境安全,并生成审核报告。 例如,您可以使用CloudTrail日志来识别谁启动了那些r3.8xlarge实例。

AWS Config可用于跟踪和执行规则,这些规则检查你的AWS资源的配置是否符合要求。你还可以根据你配置的规则一目了然地了解你的环境的合规性情况。
Amazon CloudWatch可用于对配置不正确的资源进行监控和报警。 CloudWatch的实体,包括监控指标,警报,日志和事件可帮助你监视AWS资源。使用监控指标(包括自定义的监控指标),你可以监控资源并获取可自定制的小控件的仪表板。 Cloudwatch日志可以用于从AWS提供的日志和你的系统日志中传输数据,这有助于问题修复和审核。
CloudWatch事件可以帮助你针对变更采取行动。 VPC流日志,S3和ELB日志为你提供数据,以便你在修复问题或优化环境时做出更明智的决定。
AWS Trusted Advisor分析你的AWS环境,并提供四个方面的最佳实践建议:成本,性能,安全性和容错能力。这个在线资源优化工具还包括有关AWS资源限制的警告。
我们将使用Trusted Advisor来确保这种资源限制不会成为启动100个实例的瓶颈:

问题修复

根据违规情况以及监控和展现资源配置的能力,你可能想要在发现配置不正确的资源导致安全性冲突时采取行动。 重要的是修复问题不会导致没有预期的后果,并且为你的执行的操作维护可审计的记录。

你可以使用AWS Lambda自动化一切。 当你使用Lambda与Amazon Cloudwatch 事件来修复问题时,你可以采取终止实例行动或者将新实例添加到 Auto Scaling 。你可以针对任何AWS API调用采取行动。 你还可以使用AWS Config托管规则和自定义规则进行问题修复。 在根据AWS Config规则获取有关环境的信息时,你可以使用AWS Lambda针对这些规则执行操作。 这有助于自动化的问题修复。

AWS Config查找运行中实例的类型

要解决我们示例中的问题,你可以实现AWS Config的自定义规则和触发器(例如,如果实例的类型大于.xlarge或被拆除出EMR群集,则该实例会被关机)。

审计

你做为审计员,将会希望在年底或季度末准备一份审计报告。你可以使用AWS Config资源自动化你的报表系统。
你可以查看AWS资源配置和历史记录,以便查看r3.8xlarge实例集群何时启动或者应用了哪个安全组。 你甚至可以搜索哪些被终止的实例。

AWS Config 资源

 

更多控制,监测和问题修复的示例

来自AWS专业服务团队的Armando Leite创建了一个利用Cloudwatch Events和AWS Lambda的治理框架示例来强制执行一组控件(无操作系统root的访问,无远程登录)。 当违规被注意到(监测)时,自动化措施会被采取来响应事件,并在必要时恢复到之前的良好状态(问题修复)。

  • 通过AWS Config的自定义规则或AWS CloudWatch事件去触发工作流,来进行修复(例如,关闭实例)
  • 监视用户的操作系统活动。 随着事件的发展,新的Lambda功能动态地启用更多的日志和订阅日志数据以实现进一步的实时分析。
  • 如果监测的结果是适合,将系统恢复到之前的良好状态。

 

译者

殷实,AWS专业服务咨询顾问,专注于企业客户在AWS上的运维和DevOps的评估,架构,设计和实施。

在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 HANA工作负载的各种计算选项。对于在线分析处理(OLAP)工作负载(例如,HANA上的SAP Business Warehouse,SAP BW / 4HANA,数据集市等),您可以垂直扩展,从244 GiB到2 TB,水平扩展一直到14 TB,并被SAP完全支持。还要注意,我们已经在AWS实验室中成功测试了多达25个节点的部署或总共50 TB的RAM。对于在线交易处理(OLTP)工作负载(例如,HANA上的SAP Business Suite,SAP S4 / HANA,SAP CRM等),您现在可以从244 GiB垂直扩展到2 TB。随着AWS继续推出具有最新CPU代数的新实例类型,我们将与SAP密切合作,为SAP HANA工作负载的这些实例类型进行认证。通过SAP认证和支持的SAP HANA硬件目录中的“认证IaaS平台”页面,查看可用于SAP HANA工作负载的生产中的所有经过认证的AWS实例类型。在非生产工作负载的给定实例系列中,您可以随时使用较小的实例大小,例如r3.2xlarge,r4.2xlarge等,以降低总体拥有成本(TCO)。请记住,这些是云原生实例,使您可以灵活地将SAP HANA系统的内存空间从64GB无缝更改为2 TB,反之亦然,几分钟内即可实现SAP HANA实施的前所未有的灵活性。

以下图表总结了我刚刚描述的内存和计算选项。

注 – 对于SAP Business One,所适用的SAP HANA的版本,以及可以使用其他实例和内存大小。 请参考关于这个话题的另一个博文。

存储

对于SAP HANA的持久性块存储,AWS提供多种选项。对于您的性能敏感数据和日志卷,以及针对SAP HANA备份的成本优化/高吞吐量磁性EBS卷(st1),我们有两种支持SSD的EBS卷类型(gp2和io1)。

  • 使用通用SSD(gp2)卷类型,您可以驱动高达每卷160 MB / s的吞吐量。为了实现TDI模型所需的最大吞吐量为400 MB / s,您必须为SAP HANA数据和日志文件分配三个卷。
  • 配置的IOPS SSD(io1)卷提供每卷最多320 MB / s的吞吐量,因此您需要至少分两个卷来实现所需的吞吐量。
  • 通过吞吐量优化的硬盘(st1)卷,您可以通过大尺寸块的顺序读写实现高达500 MB / s的吞吐量,这使st1成为存储SAP HANA备份的理想选择。

一个关键点是每个EBS卷都会在其AWS可用区域内自动复制,以保护您免受故障,提供高可用性和耐久性。因此,您可以在操作系统级别配置RAID 0阵列,以获得最佳性能,而不必担心您的卷的额外保护(RAID 10或RAID 5)。

网络

网络性能是SAP HANA的另一个关键因素,尤其是横向扩展系统。 每个EC2实例提供一定量的网络带宽,而像X1这样的一些最新实例系列可为您的SAP HANA需求提供高达20 Gbps的网络带宽。 此外,许多实例为Amazon EBS存储后端提供专用网络带宽。 例如,最大的X1实例(x1.32xlarge)提供20 Gbps的网络带宽和10 Gbps的专用存储带宽。 R4(r4.16xlarge)除了专用的12 Gbps存储带宽外还提供20 Gbps的网络带宽。 以下简要介绍了SAP认证实例的网络功能。

*网络和存储流量共享相同的10 Gbps网络接口

操作系统(OS)

SAP支持在SUSE Linux Enterprise Server(SLES)或Red Hat Enterprise Linux(RHEL)上运行SAP HANA。 AWS都支持这两种操作系统版本。 此外,您可以在AWS Marketplace中使用SAP HANA特定的SUSE和Red Hat映像来快速开始。 您还可以选择携带自己的操作系统许可证。 请在未来的博文中,查看有关SAP HANA在AWS上的操作系统选项的详细信息。

把以上内容搭建起来

您可能会问:“AWS提供与TDI类似的SAP HANA的这些构建模块非常好,但是如何将这些组件放在一起构建一个满足SAP对AWS要求的系统?”AWS客户几年前就问了这个问题,这就是为什么我们构建了AWS SAP HANA快速启动。此快速启动使用AWS CloudFormation模板(基础架构作为代码infrastructure as code)和自定义脚本来帮助配置AWS基础架构组件,包括存储和网络。快速启动有助于设置SAP HANA安装的操作系统先决条件,并且可以在携带自己的软件和许可证时安装SAP HANA软件。快速启动是可以在全球许多AWS地区使用的自助服务工具。在不到一小时的时间内,它们可以以一致,可预测和可重复的方式为您的SAP HANA系统提供基础设施,无论是单节点还是横向扩展系统。查看在SAP RE:Invent 2016会议期间与SAP联合提交的SAP HANA Quick Start的演示文稿

我们强烈建议您使用AWS快速启动为您的SAP HANA部署配置基础架构。 但是,如果无法使用快速启动(例如,因为要使用自己的操作系统映像),则可以手动配置SAP HANA环境,并将构建模块放在一起。 只需确保遵循快速入门指南中有关存储和实例类型的建议。 为了具体目的,我们还在“ SAP HANA on AWS 手动部署指南”中的SAP HANA中提供了分步说明。 (手动部署指南很快将会更新,以包括最新操作系统版本的说明,包括RHEL。)

备份和恢复

以可靠的方式备份和恢复SAP HANA数据库的能力对于保护业务数据至关重要。 您可以使用本机SAP HANA工具将数据库备份到EBS卷,并最终将备份的文件移动到Amazon Simple Storage Service(Amazon S3),以提高其耐用性。 Amazon S3是高度可扩展和耐用的对象存储服务。 Amazon S3中的对象可以冗余地存储在一个区域内的多个设施中,并提供11个9的耐久性。 您还可以选择使用与Amazon S3集成的企业级备份解决方案,如Commvault,EMC NetWorker,Veritas NetBackup和IBM Spectrum Protect(Tivoli Storage Manager)以及SAP HANA Backint界面。 这些合作伙伴解决方案可以帮助您将SAP HANA数据库直接备份到Amazon S3,并使用企业级软件管理备份和恢复。

高可用性(HA)和灾难恢复(DR)
HA和DR是在SAP HANA上运行的关键业务应用程序的关键。 AWS提供了几个构建模块,包括全球各个AWS区域和每个AWS区域内的多个可用区域,您可以根据RTO和RPO的要求设置HA和DR解决方案。 无论您是寻求基于成本优化的解决方案还是基于停机时间优化的解决方案,SAP HANA HA / DR架构都有一些独特的选择,请查看SAP HANA HA/DR 指南,以了解有关这些更多信息。 在未来的博文中,我们将深入探讨这一主题。

系统迁移

在实际迁移的时候,您可以使用SAP Software Provisioning Manager(SWPM)和Software Update Manager(SUM)的Database Migration Option(DMO)等标准SAP工具集,或第三方迁移工具来把在任何数据库上运行的SAP应用程序迁移到AWS上的SAP HANA。 SAP到AWS迁移过程与典型的本地迁移方案没有太大的不同。 在本地场景中,您通常将源和目标系统驻留在同一数据中心。 当您迁移到AWS时,唯一的区别是您的目标系统驻留在AWS上,因此您可以将AWS视为自己的数据中心的扩展。 还有一些选项可用于在迁移过程中将导出的数据从本地数据中心传输到AWS。 我建议您查看 Migrating SAP HANA Systems to X1 Instances on AWS,以更好地了解您的选项。

其他注意事项包括操作,调整大小,缩放,与其他AWS服务(如Amazon CloudWatch)的集成,以及大数据解决方案。 我们将在未来的博文中详细讨论这些。 同时,我们也鼓励您使用AWS SAP HANA快速入门来在AWS上使用SAP HANA。 要了解有关在AWS上运行SAP工作负载的更多信息,请参阅AWS网站上列出的白皮书

最后,如果您需要一个超出了目前可用规模的可扩展系统,请与我们联系。 我们很乐意与您讨论您的要求,并与您一起实施。

– Sabari

 

译者

戴俊,AWS中国专业服务团队SAP咨询顾问,在加入AWS之前,曾供职于SAP和EMC历任SAP技术顾问及SAP解决方案工程师,在SAP系统架构设计与迁移方面有着丰富的经验。现任职于AWS中国专业服务团队,主要为客户提供云上SAP系统架构设计,SAP上云迁移等咨询服务。

光环新网运营的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之前,在甲骨文中国担任资深售前工程师,负责售前方案咨询和架构设计,在数据库,中间件,大数据及企业应用方面有丰富经验。