Category: 开发运维


云计算转型成熟度模型: 为您的上云行动制定有效策略的指南

云计算转型成熟度模型为帮助企业制定自己的上云之旅提供了指南。该模型定义了确定成熟阶段的特征,在进入下一阶段前必须完成的每个阶段的转型活动,以及在组织成熟度的四个阶段(包括项目,基础,迁移和优化)中实现的结果。

想了解您的企业目前处于云计算转型之旅的什么位置吗?下表可以帮您确定您的企业目前处于哪个阶段:

一旦您确定了目前处于哪个阶段,就可以遵循 AWS 入云框架(AWS CAF) 的指导开始您的下一步旅程了。CAF 可以为企业的入云之旅提供一个经济且高效的计划 。AWS CAF将复杂的迁移计划过程分解为可管理的重点领域, 无论您是需要帮助定义组织的云计算路线图,做应用程序开发的转型或大规模部署任务关键型工作负载,我们都可以按照AWS Cloud Adoption Framework的原则提供规范性的指导。

来自全面入云客户的建议

除了AWS CAF,我们也想分享来自不同行业的客户的建议,这些客户都已经决定将所有系统都迁移到AWS云平台之上(all-in on the AWS Cloud)。

 

“我们在入云之旅的沿途学到的一件事就是文化变革,文化变革可以将人们团结起来坚定地沿着这个旅程走下去,并且真正完成组织转型,不仅要说服人们我们选择的是正确的技术,重要的是要赢得民心,这样才能圆满地完成如云之旅。”

迈克·查普尔,IT服务交付高级主管,Notre Dame


“我们选取了一些系统部署在AWS上,因为可以在Amazon内部进行快速配置, 这些系统运行得更快。 这是一个巨大的成功。 这种成功使我们对取得更多类似的成功产生了浓厚的兴趣。 所以在开始使用POC验证了AWS功能后,我们立即开始扩展到其他系统,直到完全迁移到AWS 。”

埃里克·盖革,IT的副总裁行动,芝加哥联邦住房贷款银行


“对我们来说,最重要的一件事就是,AWS的确能满足我们业务增长的需要。这不仅需要从能力角度来看,还要从区域扩张的角度来看。 这可以帮助我们把我们的业务模式推广到整个地区,最终跨越全球。”

马尔切洛·韦瑟尔勒,CEO,新加坡邮政

 

原文链接:https://aws.amazon.com/cn/blogs/publicsector/cloud-adoption-maturity-model-guidelines-to-develop-effective-strategies-for-your-cloud-adoption-journey/

译者:刘育新

AWS云架构高级咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,专注于云迁移解决方案。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移的咨询设计和实施服务,在加入AWS之前有近20年的IT架构设计和项目管理经验。

使用Apache Kylin和Amazon EMR进行云上大数据OLAP分析

作者:史少锋 Kyligence资深架构师,Apache Kylin committer & PMC

 

公司简介

上海跬智信息技术有限公司 (Kyligence) 是由Apache Kylin (首个来自中国的 Apache 软件基金会顶级开源项目) 核心团队组建,专注于大数据分析领域创新的数据科技公司。Apache Kylin是近两年迅速崛起的开源分布式大数据分析引擎,它充分利用Hadoop MapReduce,HBase,Spark等成熟技术,对超大数据集进行预计算(构建Cube),从而当在线查询请求到来时,通过检索Cube以亚秒级低延迟返回结果,实现真正的大数据上的交互式分析。对于用户来说,Kylin屏蔽了底层平台的技术细节,用户只需要掌握多维模型、数据仓库、SQL等知识,就可以通过Kylin的Web界面进行建模,Kylin将自动生成任务对数据进行计算。计算完成后用户即可通过各类可视化工具连入Kylin进行分析,易用性非常高。今天,Apache Kylin已经在众多企业得到广泛应用,如今日头条等。

解决方案

Kyligence为各行各业的客户提供基于AWS公有云平台的Hadoop数据仓库解决方案。Elastic MapReduce (Amazon EMR) 是AWS推出的云上Hadoop方案,这一方案使得Hadoop的部署、监控、扩容变的非常灵活方便。Amazon EMR将计算和存储分离,可以使用S3做数据存储,用户可随需启停Hadoop而不用担心数据丢失,用户只需为运行时使用的资源付费,从而大大减少运维成本。以最近发布的Apache Kylin v2.0和Amazon EMR 5.5(海外版)为例,在AWS云上使用Kylin是非常简单快速的。

1. 启动EMR集群

如果您已经有在运行的,包含了HBase 1.x服务的EMR集群,那么这一步可以跳过,您可以使用现有集群进行此实验。

EMR的启动非常简单,登录AWS控制台,选择Amazon EMR服务,点击“Create Cluster”,选择最新的5.5版本,类型为HBase:

这里您可以选择合适的硬件配置;默认是m3.xlarge 3个节点,其中1个节点为master,另外两个为core节点。选择合适的EC2 key pair,随后点击“Create cluster”,AWS便会开始自动安装和配置Hadoop/HBase集群。

大约20分钟后,集群状态显示为“Waiting Cluster ready”,这意味着集群准备就绪可以使用了。

 

2. 安装Apache Kylin 2.0

Apache Kylin以Hadoop client的方式运行,使用标准协议/API与集群交互。您可以将它安装在集群的任意节点上,通常建议安装在一个单独的client节点上。在这里我们为了简单,就把Kylin安装在master节点上。

在AWS控制台上,您可以获取SSH到Amazon EMR的方法;点击“Master public DNS”旁边的SSH链接,即可获得,如下图所示:

SSH登录到master节点后,创建一个Kylin安装目录,下载并解压Apache Kylin 2.0的二进制包:

sudo mkdir /usr/local/kylin

sudo chown hadoop /usr/local/kylin

cd /usr/local/kylin

wget http://www-us.apache.org/dist/kylin/apache-kylin-2.0.0/apache-kylin-2.0.0-bin-hbase1x.tar.gz 

tar –zxvf apache-kylin-2.0.0-bin-hbase1x.tar.gz

如果下载速度较慢,可以至Kylin官网寻找并使用更接近的下载镜像。

由于一个已知的问题KYLIN-2587,您需要手动在Kylin里设置一个参数:用编辑器打开/etc/hbase/conf/hbase-site.xml,在其中寻找到“hbase.zookeeper.quorum”这个参数,然后将它以及它的值,拷贝到Kylin目录下的conf/kylin_job_conf.xml文件中。如下所示:

<property>
  <name>hbase.zookeeper.quorum</name>
  <value>ip-nn-nn-nn-nn.ap-northeast-2.compute.internal</value>
</property>

(注意请使用在您环境中真实获得的zookeeper地址)

3. 创建sample cube并启动Kylin

Kylin自带了一个小的数据集以及定义好的cube,只需要运行bin/sample.sh就可以将数据导入到Hive和HBase中:

export KYLIN_HOME=/usr/local/kylin/apache-kylin-2.0.0-bin

$KYLIN_HOME/bin/sample.sh

随后,就可以启动Kylin了:

$KYLIN_HOME/bin/kylin.sh start

大约若干秒以后,Kylin服务就会完成启动,在7070端口等待用户请求。

4. 修改安全组以允许访问Kylin

Amazon EMR默认创建了两个安全组,分别给Amazon EMR master和Amazon EMR core,要想从外网访问Kylin,需要设置相应规则;这里我们是将Kylin部署到了master节点,所以需要编辑master的安全组:

添加规则,允许7070端口从外面地址访问,为安全起见,建议只开放给最小的IP群,例如仅自己的地址:

接下来,在浏览器中输入http://<master-public-address>:7070/kylin,就会显示Kylin的登录页,使用默认账号ADMIN加密码KYLIN完成登录:

5. 构建Sample Cube

登录Kylin后,选择“learn_kylin”的项目,就会看到“kylin_sales”的样例Cube。此Cube模拟一个电商对其销售记录从多维度进行分析的场景,维度包括了时间(天,周,年)、区域、卖家、买家、商品分类等。

此时Cube只有定义,还没有加载数据,状态是“disabled”,需要触发一次Build。点击“Actions”,“Build”,然后选择一个时间范围,Kylin会以此条件从Hive加载数据进行一系列计算(样例数据已经导入到Hive):

所有的MapReduce, Spark, HBase操作,Kylin会自动生成并依次执行。大约七八分钟后,任务进度到100%构建完成,接下来此Cube就可以使用了:

6. 查询Cube

Cube构建完成后状态变更为“Ready”,可以使用SQL对其进行查询。虽然Kylin将原始数据构建成了多维Cube,但是对外的查询接口依旧是标准SQL,且表名、字段名依然是用原始的名称。这意味着用户一方面可以不用学习新的工具和语法,另一方面以前在Hive中执行的查询语句,基本上可以直接在Kylin中执行。

在Kylin主页点击“Insight”,切换到查询视图。此时页面的左导航处显示可以通过Cube进行查询的表和列。这里您可以尝试手写一条SQL,如下面的这条语句,按年计算交易总金额和记录数:

select YEAR_BEG_DT, sum(price), count(*) from kylin_sales inner join kylin_cal_dt on part_dt = cal_dt group by YEAR_BEG_DT;

点击“Submit”,Kylin随即执行并显示结果,如下图所示:

至此您已经完成了在AWS上运行Hadoop + Kylin的任务!从上图可以看出,Kylin的执行只耗费了0.61秒,接下来您使用可视化工具如Tableau, Excel, Saiku, Zeppelin, SmartBI等通过Kylin的ODBC/JDBC驱动连接Kylin server,体验交互式OLAP分析。

使用完以后,记得关闭Amazon EMR集群以节省费用。

成功案例

Strikingly基于AWS公有云和Kylin搭建了大数据解决方案。Strikingly (https://strikingly.com/)是一个简单、易用、美观的Web建站平台,产品中有一个面向用户的 Web Analytics Dashboard,它从各个维度以及不同时间尺度上展现了用户网站包括 Unique View, Geo Distribution 等数据,如下图所示。

用户数据查询的类型主要集中于对于各个维度数据的 group by 和 count distinct,都是比较耗时的查询操作。随着数据规模不断增长,以往的解决办法面临性能瓶颈。研究之后,Strikingly采用了Kylin + Amazon EMR的方案:每隔5分钟将原始数据备份到指定的S3 bucket上。通过预先定义好的Lambda函数对原始数据进行处理,转换成Kylin + Amazon EMR可以处理的数据格式,然后交由Kylin + Amazon EMR计算。通过引入Kylin,成功将数据查询的延迟从5~10秒降低到了1秒以内。当数据量增加的时候,可以通过Amazon EMR控制台动态添加core machine横向扩展服务,提高吞吐能力,这保证了可以对未来一段时间内可以预见的数据规模增加提供足够的技术支撑。

总结

借助于独有的分布式预计算技术,Apache Kylin比其它各类OLAP引擎能提供更高的查询性能和并发能力,并且随着数据量增加,查询延迟依旧可以保持在亚秒级(参考Kylin的SSB测试:https://github.com/Kyligence/ssb-kylin)。近些年云计算技术日趋成熟,越来越多的企业正在将大数据分析迁移到云上,AWS无疑是很热门的选择,而在选择大数据OLAP方案时,低延迟、高并发、可扩展是重要的考虑因素,Kylin结合Amazon EMR可以使云上的大数据分析变得简单而强大。
想要了解Apache Kylin的更多信息,您可以参考Apache Kylin官网(https://kylin.apache.org);如需要了解具体解决方案、商业版及专业服务,请联系Kyligence。

 

作者介绍

史少锋,Kyligence 技术合伙人&资深架构师。高级软件架构师,Apache Kylin核心开发者和项目管理委员会成员(PMC),专注于大数据分析和云计算技术。曾任eBay全球分析基础架构部大数据高级工程师,IBM云计算部门软件架构师;曾是IBM公有云Bluemix dev&ops团队核心成员,负责平台的规划、开发和运营。

云端开发工具:AWS CodeStar

概述

2017年4月旧金山的AWS全球峰会上,一项名为CodeStar的新服务闪亮登场,他帮助您在AWS上快速开发、构建和部署应用程序。从此,AWS对软件开发生命周期的支持,向开发者那端又迈进了一步。

下图为DevOps相关的AWS服务:

AWS CodeStar的主要功能包括:

1. 快速开发:可选多种项目模版和编程语言,快速开发基于Amazon EC2、AWS Lambda 和 AWS Elastic Beanstalk 的Web应用程序、微服务和Alexa技能。

2. CI & CD:与其他AWS DevOps服务或第三方工具集成,您可以在几分钟内建立起持续集成和持续部署工具链,从而以更快的速度发布代码。

3. 团队协作:集中管理项目组成员的权限,这些权限被自动应用到项目中所有使用到的服务,无须额外创建复杂的IAM策略。

4. 项目管理:通过Dashboard可以看到项目的整体状况,最新的项目活动(例如最近一次代码变更、编译和发布的结果),还可以与Atlassian JIRA集成以便跟踪和管理问题。

接下来,我们谈一谈如何快速上手这款好用的服务。

前提条件

使用CodeStar之前,需要做一些准备工作,包括:

1. 用户:创建或使用您已有的一个AWS用户,登录控制台,并确认您拥有该用户的access key和secret key。

2. 权限:如果希望该用户可以创建CodeStar项目,则需要赋予他AWSCodeStarFullAccess权限。如果该用户已经被加入其他CodeStar项目,则他已经被分配了相应的权限。

3. 证书:为了将本地的代码变化递交到CodeStar项目,您需要生成一个HTTPS Git证书,用以连接您在云端的私有Repository。请参阅:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/getting-started.html#git-credentials

4. 密钥对:如您希望访问CodeStar项目创建的EC2资源,则需要创建或使用一个已有的密钥对。

5. Git:在本地安装Git工具。请参阅:https://git-scm.com/downloads

好了,准备工作完毕,现在开始创建您的第一个CodeStar项目吧!

开始使用

目前CodeStar仅在EU (Ireland)、US East (N. Virginia)、US East (Ohio)和US West (Oregon)四个区域可用,选择CodeStar服务后,出现如下画面:

第一次使用时,会提示您创建CodeStar的service role,该服务角色将以您的名义创建、管理所选择的资源,并在仪表板中展示资源的信息。

然后,我们会看到CodeStar提供给您丰富的项目模版。本例选择使用Node.js在EC2上搭建一个Web应用程序。

接下来给项目起个名字(自动生成项目ID);然后勾选“AWS CodeStar would like permission to administer AWS resources on your behalf”,将service role赋予CodeStar,从而创建项目和资源;最后还可以点击“Edit Amazon EC2 Configuration”,选择EC2实例类型、所在VPC和子网。

点击下一步之后,会让您选择一个用于登录EC2的密钥对。

首次使用CodeStar的用户,需要输入昵称和电子邮件。

接下来选择您偏爱的IDE工具,包括:Visual Studio,Eclipse和命令行工具。我们暂时选择Skip略过,在后面的“特点:与IDE集成”中详细介绍。

至此,CodeStar项目创建完毕。您可以在Dashboard右侧的CodePipline窗口中看到,程序被自动递交到CodeCommit做代码管理,并通过CodeDeploy自动部署于EC2实例,同时给出了访问Web应用的Endpoint。关于CodePipline服务,请参考:https://aws.amazon.com/cn/codepipeline/

点击CodeStar左侧菜单栏中的Code选项,转向CodeCommit服务,可以看到代码管理的详细信息。关于CodeCommit服务,请参考:https://aws.amazon.com/cn/codecommit/

点击CodeStar左侧菜单栏中的Deploy选项,转向CodeDeploy服务,可以看到应用部署的详细信息。关于CodeDeploy服务,请参考:https://aws.amazon.com/cn/codedeploy/

在浏览器中通过Endpoint访问Web应用,成功显示如下页面。

若要修改代码,点击CodeStar左侧菜单栏中的Code选项,转向CodeCommit服务。点击Clone URL,选择HTTPS,拷贝Repository链接。

在本地打开命令行窗口,更改至目标目录,运行“git clone 上一步拷贝的链接“将代码复制到本地。然后在本地编辑代码,本例对index.html的Header文字做了修改。最后在命令行窗口中运行下述命令,将变化递交到Repository:

git add index.html

git commit -m "Changed title. "

git push

//注:有两种方法可以递交代码变化,除了这里介绍的Git客户端,还可以通过IDE。第二种方法会在后面的“特点:与IDE集成”中详细介绍。

回到CodeStar Dashboard,在右侧可以看到代码已成功递交到CodeCommit,同时自动部署到EC2。

重新刷新页面,我们发现Header文字已变更。细心的观众还注意到,这个页面的背景颜色会随时间变化。怎么样,CodeStar的使用是不是很简单呢?

特点

最后,说几个AWS CodeStar为人称道,也非常实用的特性。

1. 快速开发:提供给您多种项目模板(Web应用程序、微服务和Alexa技能),您可以选择自己喜爱的编程语言(Java、JavaScript、PHP、Ruby 和 Python),CodeStar会帮助您在Amazon EC2、AWS Lambda 和 AWS Elastic Beanstalk上搭建起相应的运行时环境和应用程序框架。

2. CI & CD:与AWS或第三方DevOps工具集成,迅速搭建持续集成和持续部署工具链。AWS的DevOps服务包括:

与AWS紧密合作的第三方DevOps工具包括:

本文的CI & CD流程和使用的服务如下图所示:

3. 与IDE集成:CodeStar可以与您喜爱的IDE集成,在IDE中进行开发,代码变化将被递交到CodeStar项目中,并自动触发CI & CD流程。接下来以Eclipse为例说明;关于与Visual Studio的集成,请参阅:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/setting-up-ide-vs.html

推荐使用Neon/Mars/Luna版本的Eclipse IDE for Java EE Developers,他包含了Elastic Beanstalk 需要的Eclipse Web Tools,以及Amazon SimpleDB需要的Eclipse Data Tools。

在Eclipse中安装AWS Toolkit for Eclipse插件。

输入URL:https://aws.amazon.com/eclipse,选择所有插件,点击Next后按提示安装。

安装完毕后,在偏好设置中输入您的access key和secret key(如果曾用AWS CLI设置过,则自动显示于此),以便Eclipse可以访问您的AWS资源。

导入CodeStar项目。

导入时需要指定用户和区域,选择项目,输入用于HTTPS登录CodeCommit的用户名和密码。点击Next后按提示完成。

开始编辑代码,完成后对修改的文件右键,选择Team->Commit。

在弹出的Git Staging窗口中输入递交信息,然后点击Commit and Push,确认无误后点击OK。

返回CodeStar,从左侧菜单栏中打开CodePipline,可以看到修改后的代码已被递交到云端Repository,应用程序被自动部署到EC2实例。通过Endpoint访问网页,发现修改成功。

4. 团队协作:您可以将团队成员添加到项目中,并通过指定他们的角色,轻松管理访问权限。一共有三种角色可供选择:

角色名称 项目仪表盘和状态 访问或修改项目资源 增加或删除团队成员 删除项目
所有者 X X X X
贡献者 X X
观察者 X

在Dashboard左侧菜单栏中点击Team,即可增加团队成员。

您可以随时调整他们的角色,例如:张三离开项目组,改去做PMO;通过控制台或CLI,可将张三从贡献者改为观察者,并拒绝张三远程访问。此外,一个团队成员可以同时属于多个项目,在不同项目内可以拥有不同角色。

5.       项目管理:Dashboard中,除了右侧的CI & CD信息,还提供Team Wiki、代码变更履历、应用程序性能监控等信息。

还可以与大名鼎鼎的Atlassian JIRA集成,实现问题跟踪功能,您可以轻松跟踪项目进度、待办事项和最新发布。关于Atlassian JIRA软件,请参阅:https://www.atlassian.com/software/jira

先在JIRA中创建项目。

然后将JIRA与CodeStar相关联,即可在Dashboard中进行问题管理。

6. 成本:使用AWS CodeStar不收取任何额外费用。您只需为用于开发和运行应用程序所预置的 AWS 资源付费。

参考

官方文档:http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/welcome.html

作者介绍

何鹏

AWS解决方案架构师,14年软件开发、系统集成、移动应用和云计算解决方案经验。曾任NEC中国高级项目经理、摩托罗拉系统中国有限公司高级解决方案架构师。多年为国内外零售与物流行业大客户构筑其IT系统,此外还拥有丰富的面向金融服务、HFT(高频交易)初创企业的IT解决方案设计经验。目前在AWS中国负责推广针对初创企业的最佳云计算架构实践。

自动化部署服务——AWS CodeDeploy 快速入门

作为DevOps和微服务的深入践行者,Amazon在内部积累了许多持续集成、交付和部署的自动化工具和平台。其中, Apollo作为代码部署的自动化平台,每年进行超过5000万次部署。

为了能够让广大开发者和企业用户使用到功能丰富且久经考验的代码部署平台,在Apollo的经验基础上,AWS发布了自动化部署服务——CodeDeploy。

平台介绍

AWS CodeDeploy旨在帮助用户完成应用的快速部署,按照用户指定的策略将代码部署在一组EC2服务器上。用户策略可以包括集群部署速度、部署事件通知、警报处理策略等。此外,CodeDeploy还可以和弹性负载均衡(Elastic Load Balancer)、自动扩展组(Auto Scaling Group)等服务结合,完成无缝升级和动态部署。

为方便有效地组织部署任务,CodeDeploy设立了三个概念:应用(Application)、部署(Deployment),以及部署配置(Deployment Configuration)。

1)应用程序(Application)

应用程序是部署的核心,由部署组(Deployment Group)和代码修订(Revisions)组成。一个应用可以包含多个部署组,一个部署组又可以包含多台EC2服务器。同时,一个服务器也可以属于多个部署组,因为一个服务器可能同时运行多个应用。

1.1)部署组

创建或修改部署组时,如果添加EC2服务器,可以通过标签(Tag)对已有的EC2服务器进行筛选。所以,在创建EC2时一定要打上标签(Tag),便于在创建应用的部署组时找到对应业务的服务器。

此外,部署组还可以添加自动扩展组(Auto Scaling Group),以及用户自己机房的主机(On-Premise Instance)。

1.2)代码修订

代码修订保存了当前应用涉及到得所有代码,代码的存放位置可以在S3或Github。

如果用户自建代码托管,当需要部署时,可以在工作机上同步代码到本地,然后使用AWS命令行进行打包上传。

aws deploy push --application-name <MyAppName> \

      --s3-location s3://<MyBucketName>/<MyNewAppBundleName> \

      --source <PathToMyBundle>

上面的命令可以将运行目录下得代码打包上传到S3,同时显示在关联应用的代码修订一栏中。

2)部署(Deployment)

每一次部署都有唯一的ID标记,并保存所有信息,如代码来源、部署时间、目标服务器、部署结果等。并且针对每一台服务器,都可以详细查看部署过程中的事件(如下载程序、安装前检查、 程序启动、安装后检查等7个事件),以便追踪部署的各个步骤。当部署出错时,可以快速定位和排查。

3)部署配置(Deployment Configuration)

部署配置存放了一次部署的服务器台数或百分比,在发起部署时需要指定所需配置。CodeDeploy默认提供了三种配置:一次部署一台、一次部署一半数量的服务器,以及一次完成全部部署。部署发起后,CodeDeploy会按照上述策略进行工作,指导完成部署组内全部服务器的更新。

如果用户要自定义部署策略,建议使用命令行完成。比如下面的例子创建的配置就是一次完成20%的服务器部署。

aws deploy create-deployment-config --deployment-config-name ThreeQuartersHealthy --minimum-healthy-hosts type=FLEET_PERCENT,value=20

此外,CodeDeploy还可以管理物理主机(或第三方主机)。只要在物理主机上安装和配置CodeDeploy Agent,Agent向CodeDeploy注册完成后,CodeDeploy就可以像管理 EC2服务器一样在物理服务器上部署应用。

服务器配置

CodeDeploy是通过与部署在服务器上的Agent通信,实现代码部署的。

1)服务器角色

由于Agent需要访问S3下载代码,所以EC2服务器需要配置角色(Role)以保证Agent对S3的读取权限。创建一个IAM Policy包含如下内容,在创建所需的角色关联这个Policy。然后,在创建EC2服务器时,关联此角色。

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Action": [

        "s3:Get*",

        "s3:List*"

      ],

      "Effect": "Allow",

      "Resource": "*"

    }

  ]

}

2)Agent安装

Agent可以在创建EC2时通过User Data安装,也可以登录到服务器上安装。

如果使用User Data安装,模板如下:

#!/bin/bash
yum -y update
yum install -y ruby
yum install -y aws-cli
cd /home/ec2-user
aws s3 cp s3://bucket-name/latest/install . --region region-name
chmod +x ./install
./install auto

其中,关于bucket-name和region-name,请查阅下面链接,找到对应Region的替换名称。

https://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-set-up-new-instance.html

例如,北京Region的User Data是:

#!/bin/bash
yum -y update
yum install -y ruby
yum install -y aws-cli
cd /home/ec2-user
aws s3 cp s3://aws-codedeploy-cn-north-1/latest/install . --region cn-north-1
chmod +x ./install
./install auto

如果是选择先创建EC2服务器,再安装Agent,请注意使用sudo以root权限安装。详情请见:

https://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-run-agent-install.html

部署完成后,使用如下命令检验Agent是否工作正常。

sudo service codedeploy-agent status

用户端配置

建议AWS命令行工具(https://aws.amazon.com/cn/cli/),作为开发流程工具,CodeDeploy的功能可以通过命令行快速完成,而不必使用图形界面。安装完成后的配置方法请参考:https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html

如前文所述,用户可以通过aws deploy push命令来完成代码打包上传。但打包内容除了应用程序代码外,还包含了一个AppSpec.yml文件和一些用于处理安装中一个或多个事件的脚本。

AppSpec.yml脚本不仅定义了代码部署的路径,而且指定了部署过程中相关事件的处理脚本。部署事件有7个,可以按需选择指定。

用户把代码、AppSpec.yml、事件脚本通过aws deploy push命令打包上传后,用户就可以通过CodeDeploy图形化平台选择对应的代码修订(Revision)进行部署了。当然,继续使用命令行进行部署,更是高效的方法。

此外,CodeDeploy还可以和常见的持续集成工具协同工作,如Jenkins、Travis CI等。

案例分享

GILT是一家专注服饰的电商平台,成立于2007年,总部位于纽约,员工超过1000人。 2016年1月,GILT以2亿5千万美金的价格被收购。

GILT的特色业务之一就是促销,并且是在每天中午开售。为了能够灵活、快速地应对业务压力,GILT的DevOps团队基于微服务来设计和部署平台,并采用了Docker提高平台的弹性。其部署平台经历过数次演化,目前是第五代平台NOVA(代码已开源)。CodeDeploy在最新一代的平台中,结合Cloudformation完成核心部署工作,NOVA通过AWS API/SDK完成对CodeDeploy和Cloudformation的调用。

扩展阅读
The Story of Apollo – Amazon’s Deployment Engine

http://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

AWS Codedeploy plugin for Jenkins

https://wiki.jenkins-ci.org/display/JENKINS/AWS+Codedeploy+plugin

AWS CodeDeploy for Travis CI

https://docs.travis-ci.com/user/deployment/codedeploy

GILT NOVA

https://github.com/gilt/nova

 

作者介绍

代闻

AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在大规模后台架构、物联网应用、媒体行业转型、企业混合IT和自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。曾任IBM中国软件开发中心软件工程师,从事企业软件和移动平台的开发工作。

手把手教你在FPGA实例上运行“Hello World”

前言

在4月19号的旧金山AWS技术峰会上,亚马逊CTO Werner Vogels宣布了多项AWS新功能,其中就包括众人期待已久的FPGA实例F1。

F1 实例配有最新的 16 nm Xilinx UltraScale Plus FPGA,目前有f1.2xlarge和f1.16xlarge两种类型,其中f1.2xlarge配备有1个FPGA卡, f1.16xlarge配备有8个FPGA卡。

使用 F1 实例部署硬件加速在许多高性能计算 (HPC) 应用程序中非常有用,可解决需要高带宽、增强型联网和较高计算能力的复杂科学、工程和业务问题。F1 实例尤其适用于有时间要求的应用程序,如临床基因组学、实时视频处理和财务风险分析。

因为这段时间都在学习神经网络,所以F1实例最吸引我的是在FPGA上部署神经网络模型,神经网络的前向计算以高频脉冲的方式同时发生在门电路构成的神经网络单元上,想想都让人激动。

不过FPGA这个东西确实太专业了,入门学习曲线不是一般的陡,启动F1实例运行一个简单的Hello World都需要折腾一番。

所以在这里记录一下自己启动F1实例运行Hello World的过程,供各位参考,希望可以让大家开始开始FPGA的旅程。

启动f1实例

f1实例的启动过程和一般的EC2启动过程类似,有关AWS账号的准备,EC2创建过程的细节请大家参考相关技术文档。以下只列出一些需要注意的地方。

测试时我选择了“弗吉尼亚北部”这个区域,也就是us-east-1区域。

启动f1实例时强烈推荐使用 AWS FPGA Developer AMI 镜像, FPGA Developer AMI 包括一个预先打包的工具开发环境,其中含有用于模拟 FPGA 设计、编译代码及构建和注册 AFI 的脚本和工具。

在启动实例的第一步,选择系统镜像的时候选择“AWS Marketplace”,然后搜索“FPGA”就可以找到FPGA Developer AMI, 该镜像在弗吉尼亚北部区域的ID为:ami-3afc6f2c,镜像选择界面截图如下。

启动过程中注意给你的实例指定一个IAM Role, 后续使用AWS CLI命令行工具的时候就需要配置静态的Access Key和Secret Key了。

还有就是安全组配置,缺省的22号端口保留打开状态,另外建议开3389端口,后续如果你希望使用远程连接的方式使用图形化界面需要用到这个端口。

还有一个不需要再强调的就是你启动的f1实例需要有公有IP。

系统登录

在f1实例启动后在EC2控制台上找到这台实例的公有IP地址,然后通过ssh命令连接该实例,注意使用的用户名是centos, ssh命令样例如下:

ssh -i ~/.ssh/<mykey.pem> centos@<ip address>

登录以后可以看到下面的信息:

 ___ ___  ___   _     ___  _____   __    _   __  __ ___
| __| _ \/ __| /_\   |   \| __\ \ / /   /_\ |  \/  |_ _|
| _||  _/ (_ |/ _ \  | |) | _| \ V /   / _ \| |\/| || |
|_| |_|  \___/_/ \_\ |___/|___| \_/   /_/ \_\_|  |_|___|
AMI Version:        1.2.0
Readme:             /home/centos/src/README.md
GUI Setup Steps:    /home/centos/src/GUI_README.md
AMI Release Notes:  /home/centos/src/RELEASE_NOTES.md
Xilinx Tools:       /opt/Xilinx/
Developer Support:  https://github.com/aws/aws-fpga/blob/master/README.md#developer-support

注意这里提到的GUI设置说明文档: /home/centos/src/GUI_README.md,如果你后续希望使用图形化界面,请参考这个文档进行操作。

克隆AWS FPGA项目

在远程f1实例上创建一个工作目录,在该工作目录下执行以下命令克隆AWS FPGA 项目:

git clone https://github.com/aws/aws-fpga.git

执行完成以后可以看到一个aws-fpga目录

安装 FPGA SDK

进入aws-fpga目录,然后执行以下命令安装FPGA SDK:

source sdk_setup.sh

安装命令执行完以后会有以下输出,表示安装成功:

Done with SDK install.
Done with AWS SDK setup.

这个过程会安装好FPGA管理工具,通过这个管理工具可以查看FPGA卡的情况,列出FPGA卡上的镜像情况,还可以执行加载镜像等操作。

首先我们可以通过fpga-describe-local-image-slots命令查看FPGA卡的情况,这里就是FPGA的“image slot”的情况,具体命令请如下:

sudo fpga-describe-local-image-slots -H

在我的 f1.2xlarge 实例上有如下输出:

$ sudo fpga-describe-local-image-slots -H
Type  FpgaImageSlot  VendorId    DeviceId    DBDF
AFIDEVICE    0       0x1d0f      0x1042      0000:00:1d.0

这里列出的就是slot 0的情况,接着你可以使用fpga-describe-local-image-slots命令查看这个slot上的FPGA镜像情况:

sudo fpga-describe-local-image -S 0

其中参数 -S 用于指定希望查看的image slot,参数值就是FPGA image slot的编号。

如果你希望将新的FPGA镜像加载到一个image slot上, 你可以使用命令 fpga-load-local-image, 同时通过参数 -S指定image slot的编号,通过-I参数指定需要加载的FPGA镜像ID,如:

sudo fpga-load-local-image -S 0 -I agfi-0123456789abcdefg

有关FPGA管理工具的更多信息,请参考以下链接:

https://github.com/aws/aws-fpga/blob/master/sdk/userspace/fpga_mgmt_tools/README.md

安装FPGA HDK

安装好FPGA的SDK以后就需要安装FPGA HDK了,具体的安装命令如下:

source hdk_setup.sh

这个过程稍长一点,可能需要5到10分钟,执行的命令的时候输出结果中也有提示:

AWS FPGA-INFO:   This could take 5-10 minutes, please be patient!

如果一切正常,安装成功后会有如下信息:

AWS FPGA-INFO: DDR4 model build passed.
AWS FPGA-INFO: ATTENTION: Don't forget to set the CL_DIR variable for the directory of your Custom Logic.
AWS FPGA-INFO: AWS HDK setup PASSED.

如成功信息里提示的,如果你以后要构建自己的FPGA模块,需要将CL_DIR变量指向你的模块目录,我们在后续的步骤中会进行设置。

配置 AWS CLI

因为FPGA镜像创建过程需要使用AWS CLI命令行工具,所以我们需要提前配置好AWS CLI。

在我们使用的这个FPGA Developer AMI中AWS CLI命令行工具已经安装好了,如果你使用其它镜像需要手工安装AWS CLI的话请参考AWS CLI命令行工具的安装文档。

需要注意的时,虽然在FPGA Developer AMI中已经安装好了AWS CLI,但是这个版本不一定是最新的,所以建议通过以下命令先进行升级:

pip install --upgrade --user awscli

然后就通过以下命令启动AWS CLI配置过程:

aws configure

在配置AWS CLI的过程中一般需要提供Access Key和Secret Key,不过我们的f1实例在启动过程中制定了IAM Role, 而且我给这个IAM Role足够的权限,所以我们这里不需要配置静态的Access Key和Secret Key,我们要做的只是指定区域,这里我们指定区域为us-east-1。

$aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: us-east-1
Default output format [None]:

构建DCP

安装好HDK,配置好工具,就可以开始跑样例了,这里我们使用AWS FPGA项目里的hello world样例,该样例在aws-fpga中的以下目录中:

./hdk/cl/examples/cl_hello_world

如之前安装过程中提到的,如果我们使用目录./hdk/cl/examples/cl_hello_world中的样例,我们需要设置CL_DIR变量指向./hdk/cl/examples/cl_hello_world目录,具体命令如下:

cd ./hdk/cl/examples/cl_hello_world
export CL_DIR=$(pwd)

接下来的工作需要使用Xilinx Vivado工具,所以我们需要检查一下vivado工具是否安装正常,具体命令如下:

$ vivado -mode batch

正常的输出如下:

****** Vivado v2017.1 (64-bit)
  **** SW Build 1846317 on Fri Apr 14 18:54:47 MDT 2017
  **** IP Build 1846188 on Fri Apr 14 20:52:08 MDT 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
 
Sourcing tcl script '/opt/Xilinx/Vivado/2017.1/scripts/Vivado_init.tcl'
INFO: [Common 17-206] Exiting Vivado at Fri Apr 21 02:42:35 2017...

现在我们可以开始构建DCP了,构建命令在$CL_DIR/build/scripts中,文件名是aws_build_dcp_from_cl.sh,所以具体命令如下:

cd $CL_DIR/build/scripts
$ ./aws_build_dcp_from_cl.sh

需要注意的是,这个命令的运行时间比较长,需要几个小时的时间才能完成。为了避免ssh会话中断导致构建失败,样例的作者选择在后台运行建构过程。在我们运行aws_build_dcp_from_cl.sh命令之后,会马上获得以下输出,不过构建程序会在后台持续运行:

$ ./aws_build_dcp_from_cl.sh
AWS FPGA: Starting the design checkpoint build process
AWS FPGA: Checking for proper environment variables and build directories
Creating the reports directory
Creating the checkpointss directory
Creating the checkpoints\/to_aws directory
AWS FPGA: Environment variables and directories are present. Checking for Vivado installation.
AWS FPGA: Build through Vivado is running as background process, this may take few hours.
AWS FPGA: Output is being redirected to 17_04_21-025018.nohup.out
AWS FPGA: If you have set your EMAIL environment variable and -notify is specified, you will receive a notification when complete.
AWS FPGA:   (See $HDK_DIR/cl/examples/README.md for details)

在以上输出中我们可以注意到,构建日志会输出到文件xxxx.nohup.out中,所以我们可以定时查看这个日志文件从而了解构建进程.

当然,时不时跑过来看看日志文件看看是不是构建完成了并不是一个很有效的办法,如果你希望构建程序在结束的时候给你发一封邮件,可以使用-notify参数,使用-notify参数前需要通过以下命令设置SNS:

$ export EMAIL=your.email@example.com
$ ./$HDK_COMMON_DIR/scripts/notify_via_sns.py

有关-notify参数的更多信息请参考对应的READMD.md文件,本例中就不设置了,采用定时查看日志的笨办法。

在构建结束后,我们可以在xxxx.nohup.out文件中看到以下信息:

AWS FPGA: (07:00:53) Finished creating final tar file in to_aws directory.

然后你可以查看一下这个目录:$CL_DIR/build/checkpoints/to_aws,目录中会有打包好的tar文件,执行ls命令的结果如下:

$ ls checkpoints/to_aws
17_04_21-025018.Developer_CL.tar  17_04_21-025018.manifest.txt  17_04_21-025018.SH_CL_routed.dcp

上传文件到S3

在构建的dcp以后,我们需要将tar文件上传到S3上,然后才能通过AWS CLI命令构建FPGA image。

为了上传文件到S3上,我们需要创建对应的S3桶,这个过程可以通过AWS控制台完成,也可以使用AWS CLI命令行工具完成,有关S3的具体操作请参考相关文档。

本例使用AWS CLI来创建S3桶并上传文件,命令参考如下:

$ aws s3 mb s3://<bucket-name> --region us-east-1
$ aws s3 cp $CL_DIR/build/checkpoints/to_aws/*.Developer_CL.tar s3://<bucket-name>/<dcp-folder-name>/

接着我们还需要为日志文件创建一个目录,其实在S3上没有目录的概念,整个文件路径和文件名就是这个文件的key,所以样例中创建目录的方法就是直接上传一个空文件到我们需要的目录中,具体命令如下:

$ touch LOGS_FILES_GO_HERE.txt                    
$ aws s3 cp LOGS_FILES_GO_HERE.txt s3://<bucket-name>/<logs-folder-name>/

因为我们上传的tar文件最后会交由AWS对应账号完成构建工作,同时构建日志还需要由AWS对应账号写回到我们的S3桶中,所以我们需要为我们的S3桶设置桶访问策略,让AWS账号可以访问这些文件和目录。具体的访问策略样例如下,我们需要把下面的策略配置拷贝到我们的S3桶的“访问策略”设置中。注意样例中的 和 等内容,要把它们修改成真实的桶名和对应路径。

 {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Bucket level permissions",
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::365015490807:root"
                },
                "Action": [
                    "s3:ListBucket"
                ],
                "Resource": "arn:aws:s3:::<bucket-name>"
            },
            {
                "Sid": "Object read permissions",
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::365015490807:root"
                },
                "Action": [
                    "s3:GetObject"
                ],
                "Resource": "arn:aws:s3:::<bucket-name>/<dcp-folder-name>/<tar-file-name>"
            },
            {
                "Sid": "Folder write permissions",
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::365015490807:root"
                },
                "Action": [
                    "s3:PutObject"
                ],
                "Resource": "arn:aws:s3:::<bucket-name>/<logs-folder-name>/*"
            }
        ]
    }

设置完S3的桶访问策略以后我们需要验证一下策略写的对不对,不然策略写错了,AWS对应账号拿不到需要的tar文件,就不能成功构建FPGA image了,而且我们分析问题还不知道如何下手。

验证S3桶策略的脚本在下面这个文件里:

`aws-fpga/hdk/common/scripts/check_s3_bucket_policy.py`

如果执行出现INFO: Passed字样就表示策略设置正确。

不过在有些python环境下check_s3_bucket_policy.py运行会报下面这个错误:

AttributeError: PolicyStatement instance has no attribute 'principals_re'

发现这个错误的话需要手工改一下check_s3_bucket_policy.py文件。

用你习惯的编辑器打开文件check_s3_bucket_policy.py,然后找到下面的代码:

class PolicyStatement:
    def __init__(self, statement, principal=None):
        self.statement = statement
        self.process_policy_statement(statement, principal)
        self.principals_re = []
        self.actions_re = []
        self.notactions_re = []
        self.resources_re = []

然后把self.process_policy_statement(statement, principal)这句放到其它变量设置之后,像下面这样:

class PolicyStatement:
    def __init__(self, statement, principal=None):
        self.statement = statement
        self.principals_re = []
        self.actions_re = []
        self.notactions_re = []
        self.resources_re = []
 
  self.process_policy_statement(statement, principal)
然后就不会报错了,具体运行check_s3_bucket_policy.py命令的参考和对应输出如下:

$ check_s3_bucket_policy.py --dcp-bucket fpga.use1.damondeng.com --dcp-key fpgajarfile/17_04_21-025018.Developer_CL.tar

--logs-bucket fpga.use1.damondeng.com --logs-key logfile
INFO: Passed

一切准备好就可以开始运行 aws ec2 create-fpga-image 命令构建FPGA image了,命令参考如下:

$ aws ec2 create-fpga-image --name DamonFPGAOne

--description "Testing FPGA Image" --input-storage-location Bucket=fpga.use1.damondeng.com,Key=fpgajarfile/17_04_21-025018.Developer_CL.tar

--logs-storage-location Bucket=fpga.use1.damondeng.com,Key=logfile

如果你发现AWS CLI命令报下面这个错误,则你的AWS CLI版本不够,需要运行pip install --upgrade --user awscli进行升级:

Invalid choice: 'create-fpga-image', maybe you meant:
 
  * create-image
  *
运行正常的情况下你会获得类似这样的输出:

{
    "FpgaImageId": "afi-046ead8eb3a0e3112",
    "FpgaImageGlobalId": "agfi-06fdb0f3cea076195"
}

其中”FpgaImageId”是本区域唯一的image ID,”FpgaImageGlobalId”是全球唯一的image ID,后面我们加载FPGA image时要使用过的是全球唯一的”FpgaImageGlobalId”,以agfi开头。

开始构建FPGA image后需要等待一段时间,你可以查看你指定的保存日志的S3桶以了解进展。

如果你在日志目录里看到有个新目录产生,里面有个叫State的文件中出现{State=available} 字样就表明构建成功了。接着就可以加载你的FPGA image了。

在加载新的FPGA image之前记得先清除现有image:

sudo fpga-clear-local-image  -S 0

接着通过以下命令加载FPGA image:

sudo fpga-load-local-image -S 0 -I agfi-06fdb0f3cea076195

如之前描述的,这里-S参数用于指定image slot,-I参数用于指定FPGA image的镜像ID,注意是全球唯一,以agfi开头的镜像ID。

为了检查FPGA image是否加载成功,可以使用fpga-describe-local-image命令,执行输出的样例如下:

$ sudo fpga-describe-local-image -S 0 -R -H
Type  FpgaImageSlot  FpgaImageId             StatusName    StatusCode   ErrorName    ErrorCode   ShVersion
AFI          0       agfi-06fdb0f3cea076195  loaded            0        ok               0       0x04151701
Type  FpgaImageSlot  VendorId    DeviceId    DBDF
AFIDEVICE    0       0x1d0f      0xf000      0000:00:1d.0

其中可以看到镜像ID为agfi-06fdb0f3cea076195的状态是loaded,就是加载成功了。

最后我们就需要运行宿主机上的软件端来测试了,进入cd $CL_DIR/software/runtime/目录,这里有个写好的c的代码用于测试,运行以下命令编译软件测试端:

$ cd $CL_DIR/software/runtime/
$ make all

编译成功后通过./test_hello_world命令执行,以下是执行结果:

$ sudo ./test_hello_world
AFI PCI  Vendor ID: 0x1d0f, Device ID 0xf000
===== Starting with peek_poke_example =====
register: 0xdeadbeef
Resulting value matched expected value 0xdeadbeef. It worked!
Developers are encourged to modify the Virtual DIP Switch by calling the linux shell

command to demonstrate how AWS FPGA Virtual DIP switches can be used to change a CustomLogic functionality:
$ fpga-set-virtual-dip-switch -S (slot-id) -D (16 digit setting)
In this example, setting a virtual DIP switch to zero clears the corresponding LED, even if the peek-poke example would set it to 1.
For instance:
# fpga-set-virtual-dip-switch -S 0 -D 1111111111111111
# fpga-get-virtual-led  -S 0
FPGA slot id 0 have the following Virtual LED:
1010-1101-1101-1110
# fpga-set-virtual-dip-switch -S 0 -D 0000000000000000
# fpga-get-virtual-led  -S 0
FPGA slot id 0 have the following Virtual LED:
0000-0000-0000-0000

这个样例有两部分,一部分是peek_poke部分,就是寄存器的读写。样例为了说明FPGA寄存器的功能是否起作用,将输入的比特位做了交换。

./test_hello_world.c中的代码所描述的:

uint32_t value = 0xefbeadde;
uint32_t expected = 0xdeadbeef;
/* read it back and print it out; you should expect the byte order to be
* reversed (That's what this CL does) */

第二个部分是虚拟LED的使用,测试者可以通过FPGA管理工具设置virtual-dip开关,以类似掩码的形式影响虚拟LED的显示,比如,原来虚拟LED的输出是1010-1101-1101-1110我通过fpga-set-virtual-dip-switch 设置了 1111111100000000值, 虚拟LED的输出就是1010-1101-0000-0000

[centos@ip-172-31-8-87 runtime]$ sudo fpga-set-virtual-dip-switch -S 0 -D 1111111100000000
[centos@ip-172-31-8-87 runtime]$ sudo fpga-get-virtual-led  -S 0
FPGA slot id 0 have the following Virtual LED:
1010-1101-0000-0000

到这里我们的Hello World就成功啦,虽然比一搬的软件Hello World麻烦好多,但是要知道这里可是直接操控硬件喔。

后续工作

在跑完Hello World样例以后可能会有不少人想了解这个开发环境的图形化访问的问题。

如文中提到的,当你通过SSH登录到FPGA实例时,FPGA Developer AMI的欢迎文字中有提到GUI界面的设置。这里提到的方法概括起来就是在centos上启动xrdp,然后通过MS的远程桌面程序进行连接。

在centos端的命令拷贝如下:

sudo yum install -y kernel-devel # Needed to re-build ENA driver
sudo yum groupinstall -y "Server with GUI"
sudo systemctl set-default graphical.target
sudo yum -y install epel-release
sudo rpm -Uvh http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm
sudo yum install -y xrdp tigervnc-server
sudo systemctl start xrdp
sudo systemctl enable xrdp
sudo systemctl disable firewalld
sudo systemctl stop firewalld

设置完记得给centos用户设置一个密码,否则远程桌面登录不了:

sudo passwd centos

当你通过远程桌面登录centos后,就可以看到图形化界面了。更多可以参考Jeff Bar的博客https://aws.amazon.com/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/

以下是从该博客拷贝的远程图形界面截图:

最后希望大家可以在FPGA的世界里找到自己的方向,开始创建自己的芯片系统真是一件让人兴奋的事情。

 

作者介绍

邓明轩

AWS解决方案架构师;拥有15年IT 领域的工作经验,先后在IBM,RIM,Apple 等企业担任工程师、架构师等职位;目前就职于AWS,担任解决方案架构师一职。喜欢编程,喜欢各种编程语言,尤其喜欢Lisp。喜欢新技术,喜欢各种技术挑战,目前在集中精力学习分布式计算环境下的机器学习算法。

新上线!AWS CodeDeploy自动部署初相识

作为一个开发运维人员,您是否还在为:

1.    如何快速地将新版本应用部署到大批量服务器,无论其是云服务器EC2还是本地服务器?

2.    如何在部署过程中消除停机时间?

3.    如何规避易于出错的手工操作?

4.    在遇到问题时,如何快速回滚?并及时向您发送通知?

今天,我们很高兴地宣布:AWS的CodeDeploy服务能够助您一臂之力!它能够协助您将应用程序部署到 Amazon EC2 实例和/或非 Amazon EC2 实例的物理或虚拟设备。应用程序包扩:代码、Web 和配置文件、可执行文件、程序包、脚本等可部署的内容。AWS CodeDeploy 支持从 Amazon S3 存储桶和 GitHub 存储库部署应用程序。

您无需更改现有代码即可使用 AWS CodeDeploy。您可以使用 AWS CodeDeploy 控制跨 Amazon EC2 实例部署的速度,并定义要在每个阶段采取的操作。

AWS CodeDeploy 具备下列优势:

  • 自动部署。AWS CodeDeploy 可完全自动部署应用程序,并随您的基础设施进行扩展,让您能够部署到数千个实例。
  • 最大程度减少停机时间。AWS CodeDeploy 可以最大程度地提高应用程序的可用性。支持滚动部署和蓝/绿部署模式。并根据您配置的规则跟踪应用程序运行状况。
  • 停止并回滚。出现错误时,您可以自动或手动停止和回滚部署。
  • 易于采用。AWS CodeDeploy 与平台无关,适用于任何应用程序。您可以轻松重用设置代码。AWS CodeDeploy 还能与您的软件发布过程或持续交付工具链集成。

AWS CodeDeploy 支持如下2种部署模式

就地部署:对部署组中的实例依次执行脱机操作/更新应用/恢复联机的操作,完成滚动部署。

蓝绿部署:创建一组新的替换实例,并安装新版本的应用程序。成功后,切换流量到这些新实例,删除旧实例,完成部署。AWS CodeDeploy 运行您在切换流量之前,对新版本应用程序进行测试。如果发现问题,您可以快速回滚到旧版本。

此外,您还可以对蓝绿部署模式做更多控制:

  • 您可以选择是手工创建一组新实例,还是完全复制运行中的自动扩展组?
  • 您可以选择何时切换流量?按照什么比例切换流量?
  • 以及在部署完成后,是否删除旧实例?

下面,我们以一个具体示例来演示如何进行蓝绿部署。

第一步:启动部署向导,搭建测试应用。

步骤1:登录 AWS 管理控制台,选择AWS CodeDeploy 服务

步骤2:如果显示介绍页面,请选择 Get Started Now。如果显示 Applications 页面,请在 More info 中,选择 示例部署向导

步骤3:选择 Sample deployment

步骤4:选择 Blue/green deployment

步骤5: Key pair name 根据您账户中的设置选择,其它选项保持默认设置。

点击 Launch environment

此时,CloudFormation会为您创建一个堆栈 – 一个简单的Web网站:由一个ELB和3台Web服务器组成,并配置了自动扩展组。几分钟后,您将会看到Congratulations! Your environment is ready页面。

Sample application 部分,您可以点击http://BlueGreenLoadBalancer-xxx查看Web网站内容(注意背景色是蓝色)

在Sample blue/green deployment部分,记下新版本应用程序的S3地址 https://s3.cn-north-1.amazonaws.com.cn/aws-codedeploy-cn-north-1/samples/latest/SampleApp2_Linux.zip,后续步骤会用到。

第二步:修改部署模式为“蓝绿部署”

步骤1:在CodeDeploy控制台,选择  Applications -> BlueGreenDemoApplication(刚创建的应用程序) -> BlueGreenDemoFleet-xxx(刚创建的部署组)。在 Actions下拉菜单中,选择“Edit

步骤2:在新页面中,将 Deployment Type 设置为 Blue/green deployment,并点击 Save

注:在该页面中,您还可以设置更灵活的部署方式,是否发送通知,如何回滚等。

第三步:部署一个新版本

步骤1:在前一步返回的页面中,依旧选择之前的部署组 BlueGreenDemoFleet-xxx在 Actions下拉菜单中,选择 Deploy New Version

步骤2:在新页面中,在 Revision location* 中,填入之前记录的新版本应用程序所对应的S3地址:https://s3.cn-north-1.amazonaws.com.cn/aws-codedeploy-cn-north-1/samples/latest/SampleApp2_Linux.zip,并点击 Deploy

第四步:观察部署过程和结果

在接下来的页面中,您将会看到整个部署过程:

在EC2控制台,您会看到创建了3个新实例。

部署完毕后,在页面底部您可以看到新创建的3个实例接替了所有流量,原有的3个实例不再接收流量,并被终止。

您也可以随时在控制台的Applications -> Deployments 点击相应的部署ID查看详情。

使用浏览器重新刷新Web页面,背景色已变成绿色。

至此,蓝绿部署完毕。

测试完毕,为避免产生后续费用,请按照以下顺序清除所有资源:

  1. 替换环境的实例所属的 Auto Scaling 组。(删除 AWS CloudFormation 堆栈时,与原始环境中的实例关联的 Auto Scaling 组也将被删除。)
  2. 示例部署向导 创建的用于为蓝/绿部署提供原始环境的 CloudFormation 堆栈。
  3. 示例部署向导 创建的 AWS CodeDeploy 部署组和应用程序。

除了管理AWS 的EC2实例,AWS CodeDeploy还能够管理您本地数据中心的物理服务器和/或其它环境中的虚拟服务器,只需在其上安装相应的Agent即可实现混合云管理和部署。目前支持的操作系统包括:Amazon Linux/RHEL/Ubuntu/Windows。

如要获取更详细的帮助信息,请参考AWS CodeDeploy中文文档:http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html

 

作者介绍:

田明晶

AWS解决方案架构师,拥有18年IT、互联网工作经验,曾在中国联通互联网中心、Sun、Oracle等公司担任售后,售前工程师;2014加入AWS,担任云技术支持工程师,现任职解决方案架构师。在存储、数据库方面有多年经验;对大数据、容器和各种前沿技术(深度学习、AI等)有浓厚的兴趣和技术积累。

从IaaS到FaaS—— Serverless架构的前世今生

今天大多数公司在开发应用程序并将其部署在服务器上的时候,无论是选择公有云还是私有的数据中心,都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。假设我们不想在这些细节上花费精力,是否有一种简单的架构模型能够满足我们这种想法?这个答案已经存在,这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless(无服务器)架构。

什么是Serverless

如同许多新的概念一样,Serverless目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的:“无服务器架构是基于互联网的系统,其中应用开发不使用常规的服务进程。相反,它们仅依赖于第三方服务(例如AWS Lambda服务),客户端逻辑和服务托管远程过程调用的组合。”

最开始,“无服务器”架构试图帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”,而是指由第三方云计算供应商负责后端基础结构的维护,以服务的方式为开发者提供所需功能,例如数据库、消息,以及身份验证等。简单地说,这个架构的就是要让开发人员关注代码的运行而不需要管理任何的基础设施。程序代码被部署在诸如AWS Lambda这样的平台之上,通过事件驱动的方法去触发对函数的调用。很明显,这是一种完全针对程序员的架构技术。其技术特点包括了事件驱动的调用方式,以及有一定限制的程序运行方式,例如AWS Lambda的函数的运行时间默认为3秒到5分钟。从这种架构技术出现的两年多时间来看,这个技术已经有了非常广泛的应用,例如移动应用的后端和物联网应用等。简而言之,无服务器架构的出现不是为了取代传统的应用。然而,从具有高度灵活性的使用模式及事件驱动的特点出发,开发人员/架构师应该重视这个新的计算范例,它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。

Serverless的历史

Serverless这个概念并不容易理解。乍见之下,很容易让人混淆硬件服务器及软件上的服务与其所谓的“服务器”差别。在这里强调的所谓“无服务器”指的是我们的代码不会明确地部署在某些特定的软件或者硬件的服务器上。运行代码托管的环境是由例如AWS这样的云计算厂商所提供的。

Serverless这个词第一次被使用大约是2012年由Ken Form所写的一篇名为《Why The Future of Software and Apps is Serverless》的文章。这篇文章谈到的内容是关于持续集成及源代码控制等内容,并不是我们今天所特指的这一种架构模式。但Amazon在2014年发布的AWS Lambda让“Serverless”这一范式提高到一个全新的层面,为云中运行的应用程序提供了一种全新的系统体系结构。至此再也不需要在服务器上持续运行进程以等待HTTP请求或API调用,而是可以通过某种事件机制触发代码的执行,通常这只需要在AWS的某台服务器上配置一个简单的功能。此后Ant Stanley 在2015年7月的名为《Server are Dead…》的文章中更是围绕着AWS Lambda及刚刚发布的AWS API Gateway这两个服务解释了他心目中的Serverless,“Server are dead…they just don’t know it yet”。到了2015年10月份,在那一年的AWS re:Invent大会上,Serverless的这个概念更是反复出现在了很多场合。印象中就包括了“(ARC308)The Serverless Company Using AWS Lambda”及“(DVO209)JAWS: The Monstrously Scalable Serverless Framework”这些演讲当中。随着这个概念的进一步发酵,2016年10月在伦敦举办了第一届的Serverlessvconf。在两天时间里面,来自全世界40多位演讲嘉宾为开发者分享了关于这个领域进展。

在Serverless的世界里面,AWS扮演了一个非常重要的角色。但是AWS并不是唯一的Serverless架构服务的供应商。其他厂商,例如Google Cloud Functions、Microsoft Azure Functions、IBM OpenWhisk、Iron.io和Webtask等各种开源平台都提供了类似的服务。

Serverless与FaaS

微服务(MicroService)是软件架构领域业另一个热门的话题。如果说微服务是以专注于单一责任与功能的小型功能块为基础,利用模组化的方式组合出复杂的大型应用程序,那么我们还可以进一步认为Serverless架构可以提供一种更加“代码碎片化”的软件架构范式,我们称之为Function as a Services(FaaS)。而所谓的“函数”(Function)提供的是相比微服务更加细小的程序单元。例如,可以通过微服务代表为某个客户执行所有CRUD操作所需的代码,而FaaS中的“函数”可以代表客户所要执行的每个操作:创建、读取、更新,以及删除。当触发“创建账户”事件后,将通过AWS Lambda函数的方式执行相应的“函数”。从这一层意思来说,我们可以简单地将Serverless架构与FaaS概念等同起来。

FaaS与PaaS的比较

乍看起来,FaaS与PaaS的概念在某些方面有许多相似的地方。人们甚至认为FaaS就是另一种形式的PaaS。但是Intent Media的工程副总裁Mike Roberts有自己的不同看法:“大部分PaaS应用无法针对每个请求启动和停止整个应用程序,而FaaS平台生来就是为了实现这样的目的。”

FaaS和PaaS在运维方面最大的差异在于缩放能力。对于大部分PaaS平台,用户依然需要考虑缩放。但是对于FaaS应用,这种问题完全是透明的。就算将PaaS应用设置为自动缩放,依然无法在具体请求的层面上进行缩放,而FaaS应用在成本方面效益就高多了。AWS云架构战略副总裁Adrian Cockcroft曾经针对两者的界定给出了一个简单的方法:“如果你的PaaS能够有效地在20毫秒内启动实例并运行半秒,那么就可以称之为Serverless”。

Serverless架构的优点

  • 降低运营成本:

Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑,否则您就不得不自己来维护。由于这个服务使用者的数量会非常庞大,于是就会产生规模经济效应。在降低成本上包含了两个方面,即基础设施的成本和人员(运营/开发)的成本。

  • 降低开发成本:

IaaS和PaaS存在的前提是,服务器和操作系统管理可以商品化。Serverless作为另一种服务的结果是整个应用程序组件被商品化。

  • 扩展能力:

Serverless架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是,您只需支付您所需要的计算能力。

  • 更简单的管理:

Serverless架构明显比其他架构更简单。更少的组件,就意味着您的管理开销会更少。

  • “绿色”的计算:

按照《福布斯》杂志的统计,在商业和企业数据中心的典型服务器仅提供5%~15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着Serverless架构的出现,让服务提供商提供我们的计算能力最大限度满足实时需求。这将使我们更有效地利用计算资源。

Serverless的架构范式

移动应用后台Serverless参考架构

实时文件处理Serverless参考架构

Web应用Serverless参考架构

物联网应用后台参考架构

实时流处理Serverless参考架构

美丽新世界

技术上不可能有应用程序可以不依赖于服务器,必须要有某种硬件来支持应用程序。但是以AWS Lambda为代表的Serverless架构可以使得开发人员专注于程序功能本身,而让AWS处理与服务器部署、存储和数据库相关的所有复杂性工作。这听起来很简单,但是实现起来却并不简单。这种新的架构打破了人们的习惯思维,它让服务器不可见,并提供了一个极具成本效益的服务。Serverless架构仅有两年的历史,仍处于起步阶段。未来,这个领域还会有更大的进步,这将是非常有趣的。它给所有开发人员带来的是软件架构和应用程序部署的美丽新世界。

作者介绍:

费良宏

费良宏,AWS首席云计算技术顾问,拥有超过20年在IT行业以及软件开发领域的工作经验。在此之前他曾经任职于Microsoft、Apple等知名企业,任职架构师、技术顾问等职务,参与过多个大型软件项目的设计、开发与项目管理。目前专注于云计算以及互联网等技术领域,致力于帮助中国的开发者构建基于云计算的新一代的互联网应用。

开发者预览版——EC2实例(F1)携手可编程硬件

你是否曾经在通用型工具与专用型工具之间左右为难?通用型工具可以解决多种不同的难题,但却未必是特定问题的最佳解决选项。相反,专用型工具擅长处理特定问题,但工具的使用频率往往不会很高。

工程师们在设计架构及指令集时同样需要考虑这一问题。他们始终追求能在更加通用的工作负载范围内,提供更佳性能表现的解决方案。然而新型工作负载与工作条件不断涌现,只有定制化硬件才是性能最佳之选。这就要求我们在其中找到平衡点:是要极出色的性能水平,还是要保证以年甚至季度为周期进行衡量的开发生命周期?

走入FPGA时代

作为一种备受瞩目的解决方案,我们迎来了基于定制化硬件的现场可编程门阵列机制,或者简称为FPGA。相较于单纯着眼于一种特定功能的专用型芯片,FPGA拥有更为出色的灵活性。其能够在现场完成编程,而后再接入PC主板的插槽当中。每块FPGA中包含一组固定且数量可观的简单逻辑门。对FPGA进行编程“基本上”就是将这些逻辑门彼此对接,从而建立起必要的逻辑功能(包括AND、OR以及XOR等等)或者存储元素(触发器与移位寄存器)。不同于CPU的串行本质(即数个并行元素)以及固定大小的指令集与数据路径(通常为32位或64位),FPGA能够以编程方式并行执行更多操作,而这些操作本身几乎不设任何宽度或者规模限制。

这种高并行模式非常适合用于构建定制化加速器,从而处理计算密集型工作负载。在经过有针对性的编程之后,FPGA能够在基因组学、抗震分析、金融网络分析、大数据搜索以及加密算法及应用领域提供高达30倍的速度增量。

希望这些优势能够鼓励大家尝试利用FPGA加速您的应用程序!不过必须承认,要实现这样的效果,我们还需要克服一系列挑战。首先,FPGA从传统角度讲属于大规模专用型系统的一类组件。大家无法单纯购买一款并将其接入自己的台式机。相反,实现FPGA型解决方案要求我们完成硬件原型设计、硬件设备构建、大规模生产以及漫长的销售与部署周期等筹备工作。漫长的实现时间会限制FPGA的适用性,这也意味着摩尔定律指导下的CPU类解决方案也许更具成本效益。

但我们相信,我们能够在这方面做得更好!

全新F1实例

现在,我们发布了全新F1实例的开发者预览版。除了构建应用及服务供您自己使用之外,大家也可以将其进行打包并在AWS Marketplace中出售并进行复用。总体而言,大家将能够避免使用FPGA支持型解决方案所带来的高昂资本投入与时间消耗,我们提供的方案将带来与其它类型软件相同的商业模式。大家将能够通过云工具设计您自己的逻辑、模拟方案以及验证流程,而后在数天之内将其推向市场。

F1实例配备有英特尔Broadwell E5 2686 v4处理器(基本速度为2.3 GHz,Turbo模式下全核心可达2.7 GHz,Turbo模式下单核最高可达3.0 GHz),最多976 GiB内存、最高4 TB NVMe SSD存储以及一到八块FPGA,这意味着其能够为大家提供充足的资源以构建自己的核心FPGA逻辑。各FPGA专用于此实例,且以隔离方式确保在多租户环境下的不致相互影响。

下在来看该FPGA的具体规格(请注意,单一F1实例中最多可使用八块FPGA):

  • Xilinx UltraScale+ VU9P,采用16纳米制程工艺制造。
  • 64 GiB ECC保护内存,配合288位总线(四DDR4通道)
  • 专用PCIe x 16 CPU接口
  • 约250万逻辑元素
  • 约6800套数字信号处理(简称DSP)引擎
  • 提供虚拟JTAG接口用于调试

在包含超过一块FPGA的实例当中,专用PCIe架构允许各FPGA共享同一套内存寻址空间并通过PCIe Fabric以最高每秒12 GB的单工速率实现彼此通信。单一实例中的各FPGA共同接入一套400 Gbps双向环状结构以实现低延迟水平与高传输带宽(大家需要定义自有协议以使用这项高级功能)。

FPGA开发流程

作为这套开发者预览版中的组成部分,我们还提供FPGA开发者AMI。大家可以在内存优化型或者计算优化型实例当中启动该AMI,从而实现开发与模拟,而后利用F1实例进行最终调试及测试。

此AMI包含多款开发者工具,大家可以在AWS Cloud当中免费加以使用。您需要使用VHDL或者Verilog编写FPGA代码,而后利用Xilinx Vivado设计套件(当然也可以使用第三方模拟工具、高级语言编译器、图形编程工具以及FPGA IP库)对代码进行编译、模拟与验证。

下面来看一段简单8位计数器的Verilog代码示例:

虽然这些语言常被描述为使用类C语法,但这并不代表大家可以直接使用现有代码并通过重新编译将其应用于FPGA当中。相反,大家需要首先对FPGA编程模式进行深入了解,学习布尔代数,而后掌握传播延迟与时钟脉冲边沿等概念。在此基础之上,大家才能够开始考虑将FPGA引入您的业务环境。如果这些底层知识对您来说太过艰深,大家亦可使用各类现有高级综合工具,包括OpenCL等,进行FPGA编程。

在启动自己的实例后,我进行登录、安装多款软件包并设置许可管理器,而后即可运行Vivado工具。接下来,我RDP到桌面,打开一个终端窗口并以GUI模式启动Vivado:

我随后打开该示例项目(counter.xpr),这就是我初次尝试后的FPGA设计与开发成果:

在一番探索之后,我了解了如何建立自己的首个FPGA(其实我基本上就是到处点点并了解其作用; 我本人在这方面甚至连新手都算不上):

从这里开始,我可以测试自己的设计并将其打包为Amazon FPGA镜像(简称AFI),而后将其运用在自有应用或者发布至AWS Marketplace当中。我还将继续摸索,希望能用几周时间弄清一切并向大家汇报。

F1硬件开发工具包

在了解了F1实例之后,我的第一个问题是如何处理FPGA、CPU以及主内存之间的接口。F1硬件开发工具包(简称HDK)当中包含多款预配置I/O接口及示例应用,适用于包括主机到FPGA、FPGA到内存以及FPGA到FPGA等的多种通信方法。其还提供编译脚本、参考示例以及一套现场调试工具。这套工具包可供F1开发者预览版的各位用户随意使用。

总结评述

总体来讲,F1实例、云开发工具与相关功能的结合共同实现了独特且强大的FPGA型应用方案。FPGA模式的强大性能及灵活性如今已经可供每位AWS用户使用; 可以肯定,这将激发出前所未有的应用方式与企业业务实现途径。

预览版现已上线!

正如之前提到,全新 F1实例现已在美国东部(北弗吉尼亚州)区域推出开发者预览版(我们还将在2017年年初将该实例的正式版本推向其它服务区)。如果大家此前拥有FPGA编程经验并对F1实例很感兴趣,请访问:

https://aws.amazon.com/ec2/instance-types/f1/

马上报名加入。

-Jeff

原文链接:

https://aws.amazon.com/cn/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/

 

构建健壮的混合云网络——BJS DX+VPN篇

背景介绍:

近年来,随着公有云的普及,一方面,越来越多的用户选择利用公有云在弹性、灵活性等方面的优势,在云上部署新的应用系统,另一方面,大量的企业有很多现有的本地基础设施投资,所以企业上云的过程并不是一触而就的,期间势必存在云应用与本地数据中心应用并存的局面,为了更好的融合云与本地数据中心的应用环境,实现整体应用系统的稳定性和高可用性,构建一个健壮的混合云网络至关重要。

在AWS上,用来连接AWS与本地数据中心的方式主要有以下3种:

1.    纯VPN组网

2.    纯专线组网

3.    VPN与专线的混合组网

其中,对于AWS中国区来讲,由于AWS自身的VPN服务VGW目前尚未落地,客户急需要一个替代方案,能够达到类似于VGW的冗余及故障切换功能。

本篇主要讲述第三种组网方式,着眼点在于如何实现混合云网络的健壮性及故障自愈。

此外笔者始终认为“Network is not just ping success”,尤其对于大型企业来说,网络流量的监控,故障事件的告警,日志的搜集检索等功能并非可选项,所以本篇也会顺带介绍如何在AWS云上实现这些功能。

对于第一,第二种组网方式的高可用实现,请参考:

《构建健壮的混合云网络——BJS VPN篇》

《构建健壮的混合云网络——BJS DX篇》

注意:本篇以AWS中国区VGW尚未落地为前提,VPN部分以开源软件实现,但应用场景并不仅限于AWS中国区,如何客户需要一些VGW暂时无法满足的功能,同样可以在AWS Global利用本篇搭建符合自身需求的解决方案,具体可能的需求包括但不限于:

1.    需要使用VGW暂时不支持的加解密算法

2.    需要使用VGW暂时不支持的hash算法

3.    需要使用证书认证

4.    All in one解决方案,VPN设备除了提供VPN功能外,还需要提供防火墙,NAT等功能

拓扑图:

对于DX与VPN互备的场景,有如下几种情况:

1.    1条DX+1条VPN

2.    2条DX+1条VPN

3.    1条DX+2条VPN

4.    2条DX+2条VPN

对于1,2两种场景下,可以简单地通过调整Private-1,Private-2的路由表实现AWS侧的主备,即:流量优先选择DX专线,在专线故障时切换到VPN链路。

启用路由传递,路由表中会出现一条10.10.0.0/16,target为VGW的路由

设置一条静态路由10.0.0.0/8,target为VPN设备的eni

由于路由最长匹配的原则,默认去往本地站点10.10.0.0/16的流量会通过VGW走专线,当专线发生故障的时候,10.10.0.0/16的路由不会传递进入路由表,此时10.0.0.0/8的路由生效,流量切换到VPN链路。

对于3,4两种场景下,无法通过上述方式在两条VPN链路之间切换,需要部署拓扑图中的monitor设备来监控DX和VPN链路及VPN设备的健康状态并实现链路切换。

本例主要介绍monitor及Strongswan设备上的脚本功能,及如何与监控,告警相结合。

VPC基本配置,DX基本配置,Strongswan配置及本地站点切换方式请参考:

《构建健壮的混合云网络——BJS VPN篇》

《构建健壮的混合云网络——BJS DX篇》

1.    链路切换逻辑:

当专线链路正常时,设置服务器的路由指向VGW,流量通过专线传输,当监测到专线故障时,将服务器路由指向相同AZ中的Strongswan,并且开始监测Strongswan实例及VPN链路的健康状态,当一条VPN链路发生故障时,切换相应流量跨AZ传输给另一个AZ中的Strongswan,当其中一个AZ的Strongswan发送故障时,切换流量的同时,通过stop/start该Strongswan恢复实例。

2.    除了链路切换功能外,通过monitor及Strongswan上运行脚本能实现故障告警,VPN流量统计及事件日志收集检索功能:

SNS邮件及短信告警:

CloudWatch针对VPN流量监控:

Elasticsearch & Kibana做事件日志收集及检索:

可以针对site,dx,vpn做检索:

所有脚本可以从如下的github上下载得到:

3.    脚本功能说明:

3.1 monitor实例上运行的脚本:

monitor.sh:

 

1.    实现DX链路,VPN链路及VPN设备的健康检测并修改服务器路由切换流量

2.    发现故障后,产生告警通知,通过SNS服务邮件及短信通知相关运维人员

3.    本地产生故障日志,通过logstash输出到Elasticsearch服务存储

注:SNS短信通知目前BJS暂不支持,Elasticsearch & Kibana服务在BJS需要自己搭建

monitor实例需要对路由表做操作,并与SNS服务交互,所以需要赋予相关的角色

其中,monitor policy的配置如下:

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Action": [

                "ec2:DescribeInstances",

                "ec2:CreateRoute",

                "ec2:ReplaceRoute",

                "ec2:StartInstances",

                "ec2:StopInstances"

            ],

            "Effect": "Allow",

            "Resource": "*"

        }

    ]

}

3.2 Strongswan实例上运行的脚本:

tunnel_init.sh:创建tunnel接口及路由相关流量到tunnel口

traffic_monitor.sh:收集进出tunnel口的VPN流量统计信息,通过自定义metric发送到CloudWatch中,实现VPN流量的监控

ipsec.conf/ipsec.secrets配置文件:Strongswan配置文件,建立ipsec vpn隧道

Strongswan实例需要收集VPN流量信息并与CloudWatch交互,所以需要赋予相关的角色

4.    脚本使用方法:

monitor.sh:运行在monitor实例上,monitor实例需要拥有操控路由表,SNS等

monitor.sh的如下脚本语句需要做相应的修改

VPN_ID1="i-0e1466e8a5dd4892c"

VPN_ID2="i-0430fe110cdec5835"

VGW_ID="vgw-078bcc55"

VPN_RT_ID1="rtb-468f5222"

VPN_RT_ID2="rtb-4b8f522f"

DX_IP="10.10.3.100"

Remote_IP1="169.254.100.1"

Remote_IP2="169.254.200.1"

logstash_site="Singapore"

litterbin=$(aws sns publish --region ap-southeast-1 --topic-arn "arn:aws:sns:ap-southeast-1:93870664XXXX:DCI-Status" --subject "Status of DCI between Singapore and Ireland Changed!" --message file://logfile)

litterbin=$(aws sns publish --region ap-southeast-1 --phone-number "+861860135XXXX" --message file://logfile)

其中VPN_ID1,VPN_ID2分别为Strongswan-1,Strongswan-2的instance id,VGW_ID为VGW的id,VPN_RT_ID1,VPN_RT_ID2分别为Private-1,Private-2关联的路由表id,DX_IP为DX链路的检测ip,通常为专线提供商MPLS VPN网络的PE设备或者是本地站点的出口路由器公网ip,Remote_IP1,Remote_IP2分别为本地站点两条VPN的隧道口ip,logstash_site为AWS站点标示,该值会体现在告警及日志中,用于区分多个AWS站点。

–region,–topic-arn,–phone-number根据需要修改,其中SNS的topic需要事先创建并且通过相关邮箱订阅来接收消息。

所有事件日志会先写入本地/tmp/logstash.txt文件中,通过logstash上传给elasticsearch。

 

修改/etc/logstash/conf.d/logstash.conf

input {

file {

         path => "/tmp/logstash.txt"

         codec => json

}

}

 

output {

elasticsearch {

         hosts => "http://search-test-cfwkwatg5unnpsgvbd5lyruquy.ap-southeast-1.es.amazonaws.com"

         index => "XXXX"

}

}

可以设置/etc/rc.d/rc.local文件,使monitor实例开机运行monitor.sh脚本

 

vpn_monitor.sh:运行在Strongswan实例上,创建VPN隧道接口及相关路由

traffic_monitor.sh:运行在Strongswan实例上,收集隧道接口的流量信息并以自定义metric的方式传输给CloudWatch服务

可以设置/etc/rc.d/rc.local文件,使Strongswan实例开机运行vpn_monitor.sh和traffic_monitor脚本

作者介绍:

余骏

亚马逊AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。

构建健壮的混合云网络——BJS DX篇

背景介绍:

近年来,随着公有云的普及,一方面,越来越多的用户选择利用公有云在弹性、灵活性等方面的优势,在云上部署新的应用系统,另一方面,大量的企业有很多现有的本地基础设施投资,所以企业上云的过程并不是一触而就的,期间势必存在云应用与本地数据中心应用并存的局面,为了更好的融合云与本地数据中心的应用环境,实现整体应用系统的稳定性和高可用性,构建一个健壮的混合云网络至关重要。

在AWS上,用来连接AWS与本地数据中心的方式主要有以下3种:

1.    纯VPN组网

2.    纯专线组网

3.    VPN与专线的混合组网

其中,对于AWS中国区来讲,由于AWS自身的VPN服务VGW目前尚未落地,客户急需要一个替代方案,能够达到类似于VGW的冗余及故障切换功能。

本篇主要讲述第二种组网方式,着眼点在于如何实现混合云网络的健壮性及故障自愈。

对于第一,第三种组网方式的高可用实现,请参考:

《构建健壮的混合云网络——BJS VPN篇》

《构建健壮的混合云网络——BJS DX+VPN篇》

对于如何实现对VPN流量的监控、故障告警及事件日志搜集,请参考:

《构建健壮的混合云网络——BJS DX+VPN篇》

拓扑图:

AWS与本地站点之间建立两条专线,为了保证一条专线故障后,剩下的专线能够承载所有的业务流量,建议使用主备模式,考虑到高可用,建议两条专线分别终结在SINNET和CIDS两个DX Location,并且可以使用两家专线提供商的链路。

配置步骤:

1.    申请专线

小于500M的专线由AWS APN Partner提供,这里以APN Partner方案为例,大于1G的专线接入请参考如下文档:

https://www.amazonaws.cn/en/documentation/directconnect/

向APN Partner申请链路,根据要求提供相关信息,通常包括用户AWS账号,专线带宽等信息。

2.    接受连接并创建virtual interface

当APN Partner建立好专线后,登入management console,选择Direct Connect服务,将可以看到相关的连接,需要选择接受连接。

创建Virtual Interface。

选择创建Private Virtual Interface,设置接口名称并与相关VPC的VGW关联

根据自己的需要设置互联地址及本地站点的AS号

3.    下载本地站点端路由器的配置

4.    修改本地路由器端BGP配置,实现主备冗余

a.    AWS侧出向流量主备通过AS-PATH属性实现

b.    本地站点侧出向流量主备通过Local-Preference属性实现

下面是本地站点侧,备份链路路由器上的参考配置:

route-map LOCAL-PRE permit 10

 set local-preference 50

!

route-map PREPEND permit 10

 set as-path prepend 1111 1111

router bgp 1111

 network 0.0.0.0

 neighbor 169.254.10.2 remote-as 17493

 neighbor 169.254.10.2 route-map LOCAL-PRE in

 neighbor 169.254.10.2 route-map PREPEND out

5.    确认接口up

6.    设置需要通过专线访问本地站点的路由表的下一跳为VGW

 

作者介绍:

余骏

亚马逊AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。