亚马逊AWS官方博客

Tag: 开发运维

使用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 […]

Read More

云端开发工具: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 […]

Read More

自动化部署服务——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服务器一样在物理服务器上部署应用。 […]

Read More

手把手教你在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。 系统登录 […]

Read More

新上线!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 运行您在切换流量之前,对新版本应用程序进行测试。如果发现问题,您可以快速回滚到旧版本。 […]

Read More

从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 […]

Read More

开发者预览版——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硬件开发工具包 […]

Read More

构建健壮的混合云网络——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篇》 […]

Read More

构建健壮的混合云网络——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 […]

Read More

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

背景介绍: 近年来,随着公有云的普及,一方面,越来越多的用户选择利用公有云在弹性、灵活性等方面的优势,在云上部署新的应用系统,另一方面,大量的企业有很多现有的本地基础设施投资,所以企业上云的过程并不是一触而就的,期间势必存在云应用与本地数据中心应用并存的局面,为了更好的融合云与本地数据中心的应用环境,实现整体应用系统的稳定性和高可用性,构建一个健壮的混合云网络至关重要。 在AWS上,用来连接AWS与本地数据中心的方式主要有以下3种: 1.    纯VPN组网 2.    纯专线组网 3.    VPN与专线的混合组网 其中,对于AWS中国区来讲,由于AWS自身的VPN服务VGW目前尚未落地,客户急需要一个替代方案,能够达到类似于VGW的冗余及故障切换功能。 本篇主要讲述第一种组网方式,着眼点在于如何实现混合云网络的健壮性及故障自愈,并不会讲述太多的IPSec VPN知识。 对于第二,第三种组网方式的高可用实现,请参考: 《构建健壮的混合云网络——BJS DX篇》 《构建健壮的混合云网络——BJS DX+VPN篇》 对于如何实现对VPN流量的监控、故障告警及事件日志搜集,请参考: 《构建健壮的混合云网络——BJS DX+VPN篇》 拓扑图: Strongswan-1和Strongswan-2分别作为Region A两个AZ内的VPN设备,与客户本地站点的internet出口设为分别建立两条VPN隧道,Private-1和Private-2分别模拟Region A两个AZ中的两台内网设备。 本场景需要实现如下目的: 1.    Private-1,Private-2能够与本地站点内的设备通过私网互通 2.    AWS侧能够检测VPN连接的健康状态并实现自动的故障切换 3.    AWS侧能够检测VPN设备的健康状态并实现自动的故障切换 4.    本地站点侧能够检测VPN连接的健康状态并实现自动的故障切换 5.    本地站点侧能够检测VPN设备的健康状态并实现自动的故障切换 系统工作流程: 1.    Strongswan-1和Strongswan-2设置开机自动运行vpn_monitor.sh脚本,该脚本首先会将Private-1和Private-2去往本地站点的路由分别指向本AZ中的VPN设备,即:Strongswan-1和Strongswan-2 2.    接着Strongswan-1和Strongswan-2会通过互相ping来检测对端的可达性,同时通过ping本地站点VPN设备的tunnel地址来检测VPN连接的可达性。 3.    如果Strongswan-1的VPN连接发生故障,Strongswan-1会将Private-1路由的target从Strongswan-1修改为指向Strongswan-2,连接恢复后,Strongswan-1会将路由切换回自身 4.    如果Strongswan-1发生故障,Strongswan-2的ping检测失败,Strongswan-2会将Private-1路由的target从Strongswan-1修改为指向Strongswan-2 5.    Strongswan-2接着会对Strongswan-1做stop,start操作 6.    当Strongswan-1在另外一台物理机上启动后,自动运行的脚本会将Private-1路由从Strongswan-2修改为指向Strongswan-1 配置步骤: 1.    为Strongswan-1和Strongswan-2创建合适的角色并关联 由于Strongswan-1和Strongswan-2需要对VPC路由表及EC2实例做操作,所以需要创建合适的角色并与实例关联。 在IAM服务中选择策略->创建策略 选择创建您自己的策略 使用如下内容设置策略文档,并点击创建策略 […]

Read More