亚马逊AWS官方博客

Tag: 网络和内容发布

新增 – 通过 IP 地址在 AWS 和本地资源间实现应用程序负载均衡

作者:Jeff Barr / 原文链接 去年,我介绍了有关新型 AWS 应用程序负载均衡器的信息,并展示了如何针对 EC2 实例以及在容器中运行的微服务,用它进行第 7 层 (应用程序) 路由。 在向 AWS 迁移的这个漫长过程中,有些客户会构建混合应用程序。这些客户告诉我们,他们希望使用单个应用程序负载均衡器,在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中,在同一实例上托管 IP 地址不同但端口号相同的多项服务,并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例,同时使用多个界面和安全组来实施精细访问控制。 这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。 路由到 IP 地址 应用程序负载均衡器现在可以将流量直接路由到 IP 地址,以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink),或者位于 VPN 连接或 AWS […]

Read More

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

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

Read More

使用AWS Application Load Balancer实现基于主机名的路由分发

负载均衡器在应用架构设计中是重要的组件,负责接收来自客户端的流量,将流量按一定的算法转发给后端的一组实例,并将后端实例的响应再返回给客户端。AWS提供一款托管的负载均衡服务, Elastic Load Balancer(简称ELB),ELB除了能够做负载均衡分发流量之外,还能对后端的实例健康检查,并将流量仅转发给通过健康检查的实例,同时ELB还能与自动扩展组(Auto Scaling Group)以及监控服务(CloudWatch)配合,设置根据后端实例CPU使用率的高低,流量大小,处理时间长短等指标,自动完成添加或缩减实例数量。 ELB又分两种,Classic ELB和Application Load Balancer(简称ALB),ELB的一个重要组件是侦听器,前者支持4层和7层的协议和端口(TCP,SSL,HTTP,HTTPS),对后端实例按轮询(TCP协议)或者最少未完成请求数(HTTP协议)的算法对后端实例进行流量转发。 ALB是应用层负载均衡器,支持HTTP/HTTPS的协议,与Classic ELB不同的是,ALB支持基于请求路径的分发,即根据HTTP标头的请求URL路径的不同,分发给后端不同的目标组(Target Group)。目标组是一个或多个目标(这里的“目标”可以是EC2实例)的集合,通常一组目标运行相同的应用或服务,一个目标可以注册到一个或多个目标组中。在目标组中可以配置运行状况检查,实例监控,等待连接耗尽及粘性会话等等。ALB中的规则决定了如何将流量路由到后端不同的目标组,每条规则对应一个目标组、条件及优先级,一旦匹配规则,则执行相应的流量路由,比如将请求URL中路径是/api的请求路由给运行api服务的目标组,将请求URL中路径是/mobile的访问路由给mobile的目标组。 两者的转发模型可见下图。 过去ALB仅支持基于请求路径的流量分发,客户为了实现基于主机名的分发往往使用多组Classic ELB或Classic ELB + Nginx集群的方式,现在ALB提供了新功能,即可以基于主机名进行路由分发,详情请参考: https://aws.amazon.com/cn/elasticloadbalancing/applicationloadbalancer/ 接下来,我们将详细介绍如何使用ALB完成基于主机名的流量分发。 本例中我们将创建以下资源: (1)1个ALB; (2)5个目标组,分别为api-prod,api-sandbox,mobile-prod,mobile-sandbox,default; (3)每个目标组注册不同的EC2实例,其中api-prod目标组将注册两个EC2实例; (4)一个侦听器; (5)创建基于主机名和路径的分发规则,实现流量的分发。 1、创建目标组 2、输入目标组名称,选择协议(HTTP/HTTPS)及端口,ALB所在的VPC,配置运行状况检查(协议,路径,阈值等)。此处我们选择了默认HTTP,路径/。 3、注册实例 目标组的重要实体是目标(比如说EC2实例),在此将实例注册到目标组下面,注意选中实例后点击”添加到已注册”,然后保存。此处我们选中了该目标组对应的实例ALBDemo_api_prod,ALBDemo_api_prod_2两个实例。您可以向一个或多个目标组注册多个目标实例以便满足需求。只要注册过程完成且新注册的目标实例通过初始运行状况检查,负载均衡器就会开始将请求路由至此目标。同样,您也可以从目标组取消目标注册。 同理创建api-sandbox,mobile-prod,mobile-sandbox,default目标组,此处省略创建过程。 创建完成后,选中目标组,在目标页我们可以看见注册到该目标组的实例的状态,healthy表示实例正常,另外该状态还有unhealthy(实例未通过健康检查),initial(实例注册中),unused(无流量传入,该目标组未注册到ALB)等。 4、创建负载均衡器 下面我们来创建ALB 5、选择ELB类型 这里我们选择应用程序负载均衡器ALB 6、配置负载均衡器 输入ALB名称,模式可选择该ALB面向Internet或是内部使用;配置侦听器协议,端口,根据需要可以配置多个侦听器,此处我们选择HTTP/80;同时选择ALB部署在哪个可用区及子网,建议多可用区方式部署,同样将应用部署在多可用区,达到高可用的设计目标。 7、配置安全设置 如果侦听器配置了HTTPS,需要配置证书。使用HTTPS,ELB可以完成与客户端的SSL安全连接的建立与SSL卸载,减轻后端服务器的压力。 如果从ACM(AWS Certificate Manager)申请过证书,则可以直接选择该证书,也可以自己上传证书到IAM或者在此上传证书。由于此次我们仅配置了HTTP 80端口侦听器,此处将不配置证书。配置安全证书的截图如下: 8、配置安全组 安全组的概念及用法此处不做复述,我们可以为ALB配置安全组,仅允许指定的协议、端口及来源的流量进入ALB 9、配置路由 这里可以选择”现有目标组”,选择我们前面的创建的default目标组。此处只能选择一个目标组,我们可以在创建完成后,对此ALB添加编辑规则的时候对应路由规则添加目标组。 10、注册目标 11、审核 创建完成后,可以在负载均衡器的控制台看到该ALB的相关描述与信息。 12、配置规则 选中该ALB,在页面下方的侦听器下按端口选择“查看/编辑规则”。 13、添加/编辑规则 […]

Read More

使用Amazon CloudFront签名URL+S3实现私有内容发布

前言 Amazon CloudFront 是一个全球性内容分发网络 (CDN),可实现网站、API、视频内容或其他 Web 资产的快速分发。用户可以使用CloudFront来加速分发保存在Amazon S3存储桶上的各种内容,比如文档、图片、媒体文件和软件安装包等。很多AWS客户在使用CloudFront+S3通过互联网向自己的最终用户提供内容下载的时候,也希望能够限制到只允许合法的用户下载,比如那些已经通过了身份认证或已经付费的用户,避免开放下载可能造成的数据安全和流量成本等问题。进一步,这些AWS客户还希望能够限制其最终用户可以执行下载操作的日期时间段,发起下载请求的来源IP地址范围等等。使用CloudFront的签名URL功能就可以帮助AWS客户实现其私有内容的安全发布。 CloudFront签名URL功能简介 CloudFront的签名URL功能通过在普通的Http或Https请求中添加经过哈西和签名认证的策略内容,来保护私有内容不受非法访问。当收到来自客户端比如浏览器、移动App或桌面应用对特定资源的访问请求后,CloudFront会首先利用保存的密钥解密请求中包含的签名部分内容,检查是否完整和正确。然后CloudFront继续分析解密出的权限策略内容,并根据权限策略定义的限制条件来决定是否向客户端提供请求资源。 AWS客户可以开发Web服务或工具软件来向自己的最终用户提供签名URL,就可以让这些最终用户在受限的条件下安全地访问通过CloudFront发布的内容,比如存储在S3中的图片。 AWS客户除了可以在签名URL的权限策略定义中直接限制资源请求客户端可以访问的资源种类、请求发生时间、来源IP地址范围以外,结合CloudFront既有功能还可以进一步限制其发出请求的协议类型(Http或Https)、访问域名类型(CloudFront自动分配域名或客户自有域名)。 整体技术方案 需求 在正式开始创建CloudFront私有内容发布之前,我们首先要明确在创建过程中的一些主要的选项。对于这些选项的不同设置会影响最终所创建的私有内容发布的效果。好在通过CloudFront发布私有内容的主要步骤基本类似,通过了解一个典型的CloudFront私有内容发布的完整过程就可以快速理解和掌握其他方式的发布过程。下面的表格列出了几个主要可选项和我们本次演示所做的选择。   选项 值域 本次选择 源站类型 S3存储桶, 普通Web服务器 S3存储桶 客户端到CloudFront的协议类型 Http, Https Https CloudFront到源站的协议类型 Http, Https Https CloudFront发布点的类型 Web发布点, RTMP发布点 Web发布点 CloudFront发布点的域名类型 CloudFront自动分配的域名, 客户自有域名 客户自有域名 签名类型 签名URL, 签名Cookie 签名URL 权限策略类型 Canned Policy, Custom Policy Custom Policy 架构 一般地,一个完整的高性能私有内容发布平台主要包括四部分:内容源站,加速CDN,身份认证和权限管理,资源请求客户端。基于上面的需求分析,我们可以明确本次介绍中的四部分组成: 内容源站:S3存储桶 加速CDN:CloudFront 身份认证和权限管理:签名URL生成器 […]

Read More

如何在AWS上构建基于 OpenSwan 的软件 VPN 解决方案

概述 随着云的普及以及即用即付的模式,正在被大家逐渐接受,那么在初期从原始数据中心到云迁移的过程中,为了保证数据的平稳迁移,并不推荐将应用以及数据库一次性的迁移到云中。所有项目都应该分阶段来进行,阶段迁移的情况下就必须要将云资源与本地数据中心的资源互连互通。 要做到互连互通,有三种备选方案,互联网,专线直连(DX)和 VPN。从三个方面比较下这三种解决方案,安全,稳定性以及费用。DX 服务无疑是最优的一种解决方案,提供安全稳定的网络性能,高吞吐量。由于国内专线铺设所带来的高昂费用,所以在初期阶段,DX 并不是一个最优的。这里面互联网是最便宜的,因为本身数据中心就已经支付了这部分费用,只要保证云中的资源可以上互联网就可以了,但互联网面临的问题是网络依赖互联网,互联网的网络性能并不是可控的,另外一方面是互联网的安全性。VPN 呢是基于互联网的服务,虽然不能保证网络性通的可控,但可以做到数据的安全。 就以上比较而言,在初期阶段,VPN 无疑是一种高性比的安全以及节约成本的方案。考虑到目前北京区域并不支持硬件VPN的服务,即Global区域的VPN Connection。那么有没有可以替代的方案呢?答案是肯定的,一切问题都难不倒我们伟大的开源组织,开源方案如 OpenSwan (今天的主角),StrongSwan,Raccoon等等了。除了开源的解决方案外,还有一些商业解决方案,比如Sanfor 深信服,Hillstone 山石,Checkpoint , Cisco CSR1000v等也可以部署,有兴趣的可以与相应的软件提供商联系。 前面说了那么多关于VPN的各种软件,那么该如何选择呢?这里我们从使用上来划分下吧,将VPN主要划分为两类,一类是工作于客户端到服务端的模式,像OpenVPN,SSL VPN,L2TP,PPTP这些都是需要客户端主动发起连接,拨到Server端在两者之间建立一个逻辑上的隧道 (tunnel)进行通信。这种方式一般适用于个人到总部场景。服务器是无法主动发起连接到客户端。 另外一种就是站点到站点(site-to-site)的模式,像OpenSwan,StrongSwan, Raccoon 等软件,这种情况下两端会各有一个设备负责来建立两个站点之间安全通信的隧道,任何需要到对端的通信都会触发设备来建立安全隧道通信。 那么公司原有数据中心与云通信都是双向通信,所以站点到站点更合理。 实际上这里说的 VPN 即是指 IPsec VPN,IPsec 是一种工业标准,只要支持这种标准的设备都可以互相协商建立一个安全的隧道出来,比如支持的硬件设备有路由器,防火墙以及专业的 VPN 设备。 说了这么多,下面我们就以 AWS 端为 OpenSwan 与 Cisco 的路由器之间的配置为例。 场景及拓扑 拓扑如上图,AWS端建立一个VPC(CIDR:192.168.0.0/16),包含两个子网,一个可以上互联网的Public子网192.168.1.0/24以及私有子网Private 192.168.2.0/24。在公有子网上会配置一台OpenSwan实例与公司的Cisco设备做VPN连接。 OpenSwan的EIP地址为54.223.152.218 子网:192.168.1.0/24 Cisco设备的公网地址为54.223.170.5 子网:10.1.2.0/24 目标:实现AWS上私有子网192.168.2.0/24和数据中心10.1.2.0/24双向互通 详细配置步骤 1.配置 VPC 基础环境 1.1 创建 VPC 在AWS […]

Read More

Amazon CloudFront常见错误配置及解决方法

很多的用户在最初使用CloudFront做Web类内容分发的时候遇到无法调通的情况,本文总结了用户在配置过程中遇到的常见错误,内容涵盖了大部分用户遇到的情况。 错误一  源访问权限未放开 这种错误常见于用S3做源的情况, 引起这种错误的原因是s3的访问控制没有对CloudFront开放。从浏览器中返回的错误通常类似于下图: 更具体些,可分为以下两个场景: 场景1. CloudFront使用了Restrict Bucket Access 在创建distribution的时候选择了Restrict Bucket Access 为yes, 但 Grant Read Permissions on Bucket, 选择的是”No, I Will Update Permissions”, 而用户事后却没有在s3的桶里更新policy。如下图所示。 解决方法: 方法1, 在S3中增加桶的策略,使该桶允许该CloudFront访问,以下是policy示例,其中标黄部分需要替换成用户自己的信息。 {                 “Version”: “2008-10-17”,                 “Id”: “PolicyForCloudFrontPrivateContent”,                 “Statement”: [                                 {                                                 “Sid”: “1”,                                                 “Effect”: “Allow”,                                                 “Principal”: {                                                                 “AWS”: “arn:aws:iam::CloudFront:user/CloudFront Origin Access […]

Read More

VPC中NAT的那点事

NAT就在那里 下图 是EC2实例通过IGW(Internet网关) 接入到Internet的示意图。熟悉AWS的读者会知道,这里EC2实例和Internet通信的两个方向上,实际上发生了如下的转换: 从EC2实例发出的前往Internet的IP包,其源地址10.0.0.10在经过IGW时,会被转换为与实例关联的公网地址 54.232.0.1; 从Internet发给54.232.0.1的IP包,经过IGW时其目的地址会转换为ENI对应的内网地址10.0.0.10并被送到 EC2实例; 可以看到,这里Internet网关就是起到实例的内网地址和公网地址一对一的基本 NAT(网络地址转换)的功能。 相比于没有NAT的场景,大部分的应用、软件不需要任何改变就能在基本NAT的场景下继续工作,例如基于HTTP协议的Web应用等;但是对于某些应用,例如FTP、VoIP等,网络地址转换会给应用带来一些意想不到的挑战。今天我们以历史悠久的FTP协议为例,来和大家探讨一下NAT给FTP这样的应用带来什么样的挑战,以及FTP应用和协议又是如何演进去适应它。 被动模式下的FTP 我们重温一下FTP的工作过程。客户端连接服务端TCP 21端口建立命令通道后,输入用户名密码完成登录;随后的每一次数据传输都需要另外建立数据通道进行; 如果数据通道由客户端发起,服务端接受,我们称之为被动模式;反之,如果数据通道由服务端发起,客户端接受,则称之为主动模式。 为简化讨论,我们以被动模式为例。 同一个私网内 我们在EC2实例10.0.0.10上搭建了一台FTP服务器,它监听在21端口。现在我们从同一个VPC里的另外一台EC2上运行FTP客户端;那么整个过程会很顺利。 从Internet访问 现在我们从位于Internet某处的一台PC上运行FTP客户端。 这里连接超时的原因显而易见,FTP服务端发送给客户端的IP地址是服务端的私有地址。位于Internet上的客户端无法建立与位于VPC内部的私有地址10.0.0.10直接通讯。 解决这个问题有多种方法,我们由简单到复杂分别叙述。 增强协议适配NAT FTP协议针对NAT和其他因素,对协议进行了增强,提供了增强版的被动模式EPSV命令[1]。 下面的例子里,服务端不再显式指定IP地址,只提供数据通道的端口号。客户端默认与控制通道相同的IP地址建立数据通道。 可以看到,解决方案很优雅。实际上如果你在阅读本文的时候,绝大部分FTP服务端和客户端都已经实现了EPSV,而且优先使用它,所以FTP应用目前在EC2上是可以称之为开箱即用的。当然这需要客户端和服务端都支持增强的协议才能达成;如果我们不修改协议,能否解决这个问题呢。 放开那协议!我来! 有些时候,修改协议和实现需要多方协调和很长的时间才能完成。在RFC2428标准化之前,一些FTP实现就已经通过修改实现来适配基本NAT,而非修改协议。 以vsftpd为例,它允许通过配置文件vsftpd.conf中的配置项 pasv_address=54.232.0.1 告知服务端,在PASV被动模式下,应当指示客户端连接到配置项指定的IP(而不是服务端的私有IP)来适配基本NAT。 其他的一些常见应用例如VoIP类应用,也有类似的机制去适配基本NAT;例如引入STUN/TURN/ICE等方式[2]适配各种更加复杂的NAT穿越场景;但是针对部署在EC2上的基本NAT环境,也有通过实现上的简单调整,例如开源VoIP应用Asterisk就支持通过在配置文件/etc/asterisk/sip.conf里指定本机的公网地址和本地网段的方式来适配基本NAT。 nat=yes externaddr=54.223.0.1 localnet=10.0.0.0/16 协议和实现我都不想动! 作为一枚任性的读者,如果您既不想动协议也不想动实现,这里笔者给读者介绍一种剑走偏锋的方式,读者若有兴趣,可以轻松愉快的在AWS上试一试,看看能否解决你的应用适配基本NAT。下面是一段shell脚本,当然是运行在Linux操作系统上的。           #从EC2 实例元数据服务获取本实例的公网IP(如有)、私网IP           public_ipv4=`curl -s http://169.254.169.254/latest/meta-data/public-ipv4`           local_ipv4=`curl -s http://169.254.169.254/latest/meta-data/local-ipv4`           #配置私网地址段,这里应为EC2实例所在VPC的地址范围           local_net=10.0.0.0/16           if [ […]

Read More

使用Docker封装IPSec安全网关

随着云成为新常态,越来越多的客户开始采用AWS云服务,使用VPN隧道安全的连接到AWS成为一个常见的场景。本文介绍一种仅需少量交互与配置即可与多个AWS VPC建立动态路由VPN连接并在各个互联VPC之间转发流量的方案。该方案主要使用了Docker、IPSec套件strongSwan、动态路由软件BIRD,并在此基础上,使用AWS SDK for Python( Boto 3)、docker-py等实现快速建立与AWS VPC的动态VPN。 项目中使用的Dockerfile、相关的shell脚本以及Python应用等源文件均已经在这里开放,做为一种快速部署Customer Gateway的方法,供各位读者参考。 本文假定读者从概念上理解AWS VPC、IPSec VPN以及动态路由协议BGP。如果希望了解更多如何与AWS VPC建立VPN连接的信息,读者可以参考 AWS VPC 网络管理员指南。 如何使用 我们从最基本的场景开始,假定您需要将本地网络与单个AWS VPC通过IPSec隧道互联。 图中Customer Gateway应为一台可以访问Internet且IP固定的 Linux服务器, 这台服务器将作为IPSec网关和BGP路由器,将内部网络与AWS VPC通过IPSec隧道和BGP动态路由协议连接起来。 在Customer Gateway上执行如下预备工作: 一、我们需要 预先安装和配置好docker引擎; 二、我们的脚本使用了Python和一些第三方库,所以需要安装Python 2.7或更新版本以及Python包管理工具,例如pip 三、通过pip安装如下软件包; a. boto3 —— AWS SDK for Python,用于获取VPN连接的配置信息 b. xmltodict —— 便于python处理XML格式的数据 c. docker-py —— 用于连接docker engine并创建、运行容器 四、配置boto3连接AWS的 IAM凭证,需要注意使用的IAM用户需要拥有执行describe_vpn_connections API所需的权限。 $ cat  ~/.aws/credentials [default] […]

Read More