亚马逊AWS官方博客

十月

九月

八月

七月

六月

五月

四月

二月

一月

2016


如何在1个小时之内轻松构建一个Serverless 实时数据分析平台    30 Dec

AWS Limit Monitoring ——书到用时方恨少,资源提限需趁早!    29 Dec

Amazon Polly – 支持47种语音与24种语言的文本到语音转换服务  19 Dec

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

Amazon Lex – 构建对话语音与文本界面    15 Dec

如何在AWS上安装使用分布式TensorFlow    13 Dec

New feature launched to AWS China (BJS) region, operated by SINNET – Amazon RDS for SQL Server – Support for Native Backup/Restore to Amazon S3    5 Dec

由光环新网运营的AWS中国北京(BJS)区域现推出新RDS功能–支持SQL Server 本机备份/还原到Amazon S3   27 Nov

Amazon S3 和 Amazon Glacier 降价    27 Nov

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

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

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

GPU为 Amazon Graphics WorkSpaces 提供助力    21 Nov

Amazon QuickSight全面上线——更快更易用的大数据商务分析服务    21 Nov

Amazon EC2 产品价格调降通知(C4,M4, 和T2实例)    21 Nov

利用 CloudWatch 搭建无人值守的监控预警平台    16 Nov

一键搞定云端网络环境,让您轻松迁移至AWS!    9 Nov

程序员的深度学习入门指南    07 Nov

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

AWS的在线云计算专家,你用了吗?    31 Oct

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

使用DMT工具迁移北京区域的数据库    18 Oct

VPC中NAT的那点事     17 Oct

CloudWatch Events监控您应用的安全    8 Oct

Oracle数据库迁移到AWS云的方案    28 Sep

使用AWS的数据库迁移DMS服务    28 Sep

手把手教你使用Amazon EMR进行交互式数据查询    27 Sep

使用Oracle Data Pump将数据库迁移到AWS的RDS Oracle数据库    26 Sep

手把手教你快速部署流量压测工具 – Bees with Machine Guns    26 Sep

优秀的领导者如何更进一步迈向伟大?    24 Sep

现代IT高管已然化身首席变革管理官    24 Sep

利用云方案进行实验时的四要与四不要    24 Sep

来自成功云企业的十项诀窍    24 Sep

助你决胜云时代的人才其实近在眼前    13 Sep

手把手教你如何用Lambda + Alexa调用echo设备    01 Sep

AWS Kinesis的Javascript交互方法    25 Aug

基于AWS 平台跳板机配置    08 Aug

如何使用AWS 命令行分段上传大文件    02 Aug

我喜欢我的Amazon WorkSpaces    02 Aug

算法改变世界 - 从Prisma 的走红说开去    02 Aug

为员工进行云培训时的11条箴言    07 Jul

畅谈CIO该如何合并业务和技术    07 Jul

协同合作伙伴 合力加速上云战略    07 Jul

在云端试验时的“有所为和有所不为”    07 Jul

专线直连AWS建立混合IT环境实务指南    01 Jul

手把手教你调校AWS PB级数据仓库    20 Jun

Token Vending Machine:移动应用客户端安全访问AWS服务的解决方案    20 Jun

分布式神经网络框架 CaffeOnSpark在AWS上的部署过程    16 Jun

打造DIY版Echo:树莓派+ Alexa 语音服务    01 Jun

使用Docker封装IPSec安全网关    30 May

将VMware 中的Ubuntu 12.04 映像导入成Amazon EC2 AMI    30 May

如何使用AWS Auto-reboot和Auto-recovery进一步提升单机高可用    16 May

AWS CTO对过去十年的经验总结 – 十条军规    12 Apr

AWS上的游戏服务:Lumberyard + Amazon GameLift + Twitch    12 Apr

为AWS北京区管理控制台集成ADFS访问    12 Apr

AWS的十年创新之路    12 Apr

空荡的数据中心,120种妙用!    12 Apr

媒体洞察 | 让企业自由发展的云时代    12 Apr

亚马逊 风力发电厂在福勒岭启动了!    12 Apr241

Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试

背景

作者在实际的工作当中遇到越来越多关于S3的实践问题,其中被问的最多的也是使用最广泛的工具就是AWS S3 CLI命令行;AWS S3 CLI命令行工具对大文件提供了默认的分段上传下载的能力,同时支持并发上传下载多个文件;AWS S3 CLI 命令行不仅仅提供了高级抽象的cp、sync等操作同时还提供了相对底层的s3api相关的操作以帮助客户应对各种高度定制化的应用场景。

本文通过实验帮助大家更好地理解AWS S3 CLI常用命令的底层原理及在AWS EC2上使用该命令行工具与AMAZON S3交互场景下,影响性能的几个关键要素及几个常见EC2实例类型上的上传下载测试性能情况。

本文是AMAZON S3深度实践系列之一,接着作者会带着大家从AWS CLI探索到Python boto3 S3多线程应用开发实践,再到如何利用前面学到的知识,基于AWS平台利用托管服务构建一个实用的跨区域迁移S3数据的解决方案架构探讨及实践。

基本概念

并发上传vs 分段上传

刚刚使用AWS S3命令行工具的时候,总是混淆分段上传和并发上传的含义;分段上传是指将单个大文件切分成多个小数据块进行上传,而并发上传特指有多个待上传文件或小数据块的情况下,利用多线程同时并发上传多个文件或小数据块。

如下图所示,分段上传首先将文件切分成固定数量的小数据块,再利用多线程并发上传这些小数据块,等 S3收到该文件所有的数据块之后再将它们合并成原始的文件存放在存储桶里。分段上传功能默认会帮你实现并发上传;这样做的好处,显而易见,既可以充分利用网络带宽进行文件处理,同时还可以在网络带宽有限的情况下,减小因网络抖动导致的整个大文件需要重传的问题,即当分段上传中的某个数据块因各种异常没能上传成功时,只需要重新尝试上传该数据块即可。

分段上传vs 断点续传

AWS CLI S3命令行工具默认并没有帮大家实现断点续传的功能,也就是说哪怕我们用cp或sync命令上传一个文件的时候,默认后台会做文件分片进行分段并发上传,但如果由于网络抖动导致其中某些数据块传输失败,那么整个文件又得需要重头开始上传。

但同时我们可以利用 AWS CLI s3api底层接口非常容易地实现断点续传,后面章节我们再展开探讨。

AWS CLI S3 cp命令是如何工作的?

AWS S3 cp 命令是最常用的单文件和多文件复制方法,很多人使用过该命令,但大家知道该命令是如何帮我们执行文件复制的吗?

  • 该命令有帮我们自动做分段上传和下载吗?
  • 分段上传切分文件的依据是什么?每个数据块大小是多大?
  • 这么多数据块,有多线程并发上传吗?我们可以指定线程数量吗?
  • 多个文件的上传下载是如何工作的?

下面我们通过实验来观察和研究下这些问题,整个测试环境基于如下Amazon Linux上如下版本的AWS CLI命令行:

aws-cli/1.11.132 Python/2.7.12 Linux/4.9.51-10.52.amzn1.x86_64 botocore/1.5.95

AWS EC2机型是R4.2xlarge,挂载了一个500GB的gp2测试盘

本地单文件上传场景

第一步,我们首先生成一个48MB的本地测试文件,并通过cp命令上传到S3存储桶,并通过debug开关把详细的日志记录到本地的upload.log文件中,详细命令如下:

$ dd if=/dev/zero of=48Mfile bs=1M count=48
$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ > upload.log 2>&1
$ ls -lh
总用量 49M
-rw-rw-r-- 1 ec2-user ec2-user 48M 10月 18 00:26 48Mfile
-rw-rw-r-- 1 ec2-user ec2-user 13K 10月 18 00:31 upload.log

第二步,我们通过底层的s3api命令来了解存储到S3上的对象的基本情况,如下所示,通过head-object命令我们可以了解该文件的最后修改时间,对象大小以及一个用于完整性校验的ETag值,那我们如何知道该文件是否是分段上传的呢?

$ aws s3api head-object --bucket bjslabs --key s3/48Mfile
{
    "AcceptRanges": "bytes",
    "ContentType": "binary/octet-stream",
    "LastModified": "Wed, 18 Oct 2017 00:32:56 GMT",
    "ContentLength": 50331648,
    "ETag": "\"64db0c827ecffa128fa9440d3b04ff18-6\"",
    "Metadata": {}
}

要知道该文件是否是利用了分段上传,我们只需要在以上命令中加一个参数就可以判断,如下所示,如果该文件是利用分段上传的功能,通过head-object查询第一个数据块的基本信息就可以得到该文件一共包含多少个数据块,测试文件48Mfile一共包含6个数据块(PartsCount)。

$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile
{
    "AcceptRanges": "bytes",
    "ContentType": "binary/octet-stream",
    "LastModified": "Wed, 18 Oct 2017 00:32:56 GMT",
    "ContentLength": 8388608,
    "ETag": "\"64db0c827ecffa128fa9440d3b04ff18-6\"",
    "PartsCount": 6,
    "Metadata": {}
}

这里我们可以得知,默认情况下cp命令就会采用分段上传功能。而且从以上命令返回信息我们可以看出来,该文件第一个数据块分片大小是8388608 bytes(ContentLength)即8MB,48MB大小的文件一共被分了6个数据块,所以,可以大胆猜测默认的AWS CLI S3命令行工具默认的文件分片大小就是8MB。

第三步,我们已经判断出cp命令的默认是分段上传,接下来我们通过第一步保存的详细日志(该日志文件比较大,可以点击下载)来分析下,cp命令基本的工作流及它采用的多线程并发上传的具体情况:

通过该实验的日志,我们基本了解了cp命令的基本内部流程,因此,这里面有些参数肯定是可以通过配置来进行修改的,接下来我们来根据官方文档:http://docs.aws.amazon.com/cli/latest/topic/s3-config.html 的说明来试验下,修改相应配置,是否如我们所理解的那样运行,这几个参数是:

接下来我们修改参数并对比下,实验内容为同样大小的本地文件在不同参数条件下,通过cp上传到s3,两次运行的结果对比:

在AWS Configure配置文件中,指定S3的配置参数:

$ cat ~/.aws/config
[default]
region = cn-north-1
[profile dev]
region = cn-north-1
s3 =
  max_concurrent_requests = 5
  multipart_threshold = 10MB
  multipart_chunksize = 6MB

执行profile 为dev的上传测试命令:

$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ --profile dev > 2>&1

对比upload.log和upload2.log,我们可以看出,multipart_threshold和multipart_chunksize参数是对分段上传的影响是很好理解的,但 max_concurrent_requests参数与单个文件的分段上传的并发线程总数的关系,从日志中只能看出单文件的分段上传的并发线程总数受max_concurrent_requests参数影响,但并发线程的总数上限值还取决于文件分片后进入队列被消费者线程消耗的速度。

感兴趣的读者可以在以上实验的基础上,保持其他参数不变,只修改max_concurrent_requests参数,观察并发线程数的情况,作者在max_concurrent_requests参数值分别为8、15、20、30的情况下观察cp同样的文件的线程数情况如下:

$ aws --debug s3 cp 48Mfile s3://bjslabs/s3/ --profile dev > upload2.log 2>&1

对于单文件上传,我们经过前面的实验有了基本的认识,那我们接下来再看看cp命令在分段上传中途发生网络故障,能否实现类似断点续传的功能效果呢?

整个实验思路如下:

  •  利用dd命令产生一个26GB大小的文件
  • 在cp传送中途强行断开
  • 检查此时在S3桶里面的分片情况
  • 尝试再次上传并观察结果
$ dd if=/dev/zero of=26Gfile bs=1G count=26
$ aws --debug s3 cp 26Gfile s3://bjslabs/s3/ > upload.log 2>&1
$ Ctrl-Z(强行中止)

AWS CLI s3api提供了list-parts和list-multipart-uploads两个命令分别可以查看已经完成的分片上传及正在进行的分片上传:

$ aws s3api list-multipart-uploads --bucket bjslabs

list-multipart-uploads 命令会列出指定的bucket桶里面所有的正在进行上的分片信息,如上所示,对我们有帮助的是其中的UploadId的值,在执行list-parts命令时需要传入:

$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA-- > parts.info 2>&1

打开parts.info文件可以看到所有的已经上传好的分片信息,包含每个分片的最后修改时间,大小,ETag以及PartNumber:

接下来,我们看看如果再次运行同样的cp命令,会帮我们进行断点续传吗?判断逻辑有两点(1)两次的UploadId是否一致(2)同一个PartNumber的数据块的最后修改时间是否一致。先记录好目前的这两个值:

UploadId:

OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA—

选取PartNumber=1的数据块,该数据块最后修改时间是:

"2017-10-18T14:43:54.000Z"

重新执行一边cp命令并记录结果:

$ aws --debug s3 cp 26Gfile s3://bjslabs/s3/ > upload2.log 2>&1
$ Ctrl-Z(强行中止)
$ aws s3api list-multipart-uploads --bucket bjslabs > processing.info 2>&1

从结果我们发现,有两个正在上传的数据分片,一个是我们前一次命令产生的,一个是最近一次cp命令被中断产生的。

$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA-- > parts2.info 2>&1
$ aws s3api list-parts --bucket bjslabs --key s3/26Gfile --upload-id 7P10pMiJ.Tj.xsogV7JeG99G4Ev6kV_5SqsdcEBKXzVi9Kg1SgvcWkTmay0wpB2WYsdnXtsFyofRIjOMfu9hZnh6DXmggVzSpyiKbAgw0qSyZDHVt5OdkcqpfX52uHpM5tc9BQUkIVD3dWu29xUeyg-- > parts3.info 2>&1

我们会发现执行两次cp命令对同一个文件,会帮我们保留两个UploadId及其对应的已经上传的分段数据,根据complete-multipart-upload的文档说明,我们知道,分段上传在合并分段数据的时候,是根据UploadId进行合并的,两个不同的UploadId说明AWS CLI cp命令不会智能帮我们判断已经上传的分段之后开始续传我们的文件分片即没有直接支持断点续传。

一个文件如果经过分段上传了一部分数据但没有传完的情况下,已经传完的数据块和正在进行上传的数据块占用的存储是需要收费的,因此,我们需要清除掉这些无用的数据块,一种办法是通过命令,另外一种方式可以利用AMAZON S3的生命周期管理定期自动删除掉这样的数据块。

$ aws s3api abort-multipart-upload --bucket bjslabs --key s3/26Gfile --upload-id OwKKv3NOfXiOq7WwdBt0vYpKGVIXxzrGkxnSwSFGv8Lpwa94xzwj4IDgPvpw9Bp1FBjqUeRf2tEtL.SMCgLPhp23nw4Ilagv7UJDhPWQ0AalwwAC0ar4jBzfJ08ee4DKLd8LroSm0R7U_6Lc8y3HgA--
$ aws s3api abort-multipart-upload --bucket bjslabs --key s3/26Gfile --upload-id 7P10pMiJ.Tj.xsogV7JeG99G4Ev6kV_5SqsdcEBKXzVi9Kg1SgvcWkTmay0wpB2WYsdnXtsFyofRIjOMfu9hZnh6DXmggVzSpyiKbAgw0qSyZDHVt5OdkcqpfX52uHpM5tc9BQUkIVD3dWu29xUeyg--

S3下载到本地单文件场景

该场景下,我们关注的点主要是,对于在S3桶里面的对象,cp命令都会自动帮我分段分片下载吗?

首先尝试通cp直接下载上一个章节通过cp命令上传到S3桶里面的对象:

$ aws --debug s3 cp s3://bjslabs/s3/ . > download.log 2>&1

从日志文件里面可以看出,cp命令确实是默认采用了分段下载,调用GetObject接口,在Header里面设置range值并通过多线程并发下载;似乎非常完美,但等等,我们还忘了一个场景,假如文件上传到S3桶的时候没有使用分段上传呢?我们试验一下:

  • 还是利用本地dd出来的48Mfile的文件
  • 修改AWS CLI S3的参数,将multipart_threshold改到50MB,这样对于小于50MB的文件上传就不会采用分段上传
  • cp上传该文件并确认该文件没有被分段上传
  • cp 下载,看看是否是分段下载

第一步,修改aws configure配置文件:

第二步,通过cp上传该文件,并通过head-object命令发现该文件没PartsCount 信息即没有被分片分段上传(因为前面我们设置了自动分片的最小文件大小是50MB,该文件48MB小于50MB)

$ aws s3 cp ./48Mfile s3://bjslabs/s3/48Mfile_nonparts --profile dev
upload: ./48Mfile to s3://bjslabs/s3/48Mfile_nonparts
$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile_nonparts
{
"AcceptRanges": "bytes",
"ContentType": "binary/octet-stream",
"LastModified": "Wed, 18 Oct 2017 15:52:34 GMT",
"ContentLength": 50331648,
"ETag": "\"f6a7b2f72130b8e4033094cb3b4ab80c\"",
"Metadata": {}
}

第三步,通过cp下载该文件,并分析日志文件

$ aws --debug s3 cp s3://bjslabs/s3/48Mfile_nonparts . > download2.log 2&>1

$ aws s3api head-object --part-number 1 --bucket bjslabs --key s3/48Mfile_nonparts
{
"AcceptRanges": "bytes",
"ContentType": "binary/octet-stream",
"LastModified": "Wed, 18 Oct 2017 15:52:34 GMT",
"ContentLength": 50331648,
"ETag": "\"f6a7b2f72130b8e4033094cb3b4ab80c\"",
"Metadata": {}
}

透过日志,我们可以看到,虽然我们上传该文件是没有使用多文件上传,但利用cp命令在默认的S3参数的情况下也会自动分片分段下载我们的对象。

本地目录与S3批量上传下载场景

前面两个小节,我们通过实验深度探索了,单文件通cp操作的一些细节;本小节我们一起来看看,在本地批量上传文件到S3及从S3批量下载文件的场景。对于性能这块我们放到后面章节,本小节主要探讨:

1.    max_concurrent_requests参数对于文件并发上传下载的影响

2.    cp命令中的一些高级特性

第一步,随机生成20个100MB的测试数据文件,并准备aws configure 配置文件,修改最大并发数的参数值,保持其它参数默认,并通过不同的profile指定不同的max_concurrent_requests的参数值:

$ seq 20 | xargs -i dd if=/dev/zero of={}.data bs=1M count=100
$ vi ~/.aws/config

第二步,跑测试命令,记录详细日志:

顺序分析dev1.log到dev30.log日志文件,可以观察到Thread数量变化,最大编号分别为Thread-7,Thread-9,Thread-14,Thread-18,Thread-26,Thread-36; 为了观察最大的线程数量,作者增加测试了max_concurrent_requests分别为100,1000的结果:

由上表可见,当我们逐渐增大max_concurrent_requests参数值的时候,实际的并发线程数是随着线性增长的,直到一个合理的线程数量,此案例里面256个8MB的数据分片,AWS CLI cp命令使用到309个线程就足够速度消费添加到队列里面的上传任务。

同理,我们从S3批量下载的情况,执行如下命令:

$ aws --debug s3 cp s3://bjslabs/s3/data1000/ ./data1000 --recursive --profile dev1000 > dev1000.log 2>&1
$ aws --debug s3 cp s3://bjslabs/s3/data100/ ./data100 --recursive --profile dev100 > dev100.log 2>&1

从日志文件中分析出,max_concurrent_requests为100或1000时,cp命令并发下载的线程数最大编号为107和275。


对于批量操作,不可避免有时会有选择的上传和下载某些特征的文件,cp 命令可以通过include和exclude参数进行文件模式匹配,看以下几个例子:

通过以下命令仅仅下载所有 ”.data” 结尾的文件:

$ aws s3 cp s3://bjslabs/s3/data1000/ ./data1000 --recursive --profile dev1000 --exclude “*” --include “*.data”

通过以下命令上传当前目录中,除子目录 “data100” 之外的所有文件到存储桶:

$ aws s3 cp ./ s3://bjslabs/s3/data1000/ --recursive --profile dev1000 --exclude “data100/*”

S3到S3的复制场景

首先,我们先来看一个同区域的文件复制案例,执行如下命令并记录详细日志:

$ aws --debug s3 cp --source-region cn-north-1 s3://bjslabs/s3/data100/1.data s3://bjslabs/s3_2/ --profile dev100 > sameregion100.log 2>&1

查看日志文件,可以了解两点(1)默认也是支持分段并发的(2)每个分段是调用的upload-part-copy 接口执行复制操作的:

而如果不是S3到S3的复制的话,比如前面两个场景,源是本地目标地址是S3的话则cp命令最终会调用upload-part 方法进行上传,这两个命令有什么区别吗?

参见upload-part-copyupload-part在线文档,仔细对比如下两个命令最终的REST请求,可以看到,UploadPartCopy请求只需要将源数据指向源的对象(x-amz-copy-source)以及相应的数据范围(x-amz-copy-source-range);但UploadPart请求中必须要讲该分段的数据包含进去;也就是可以推断,S3到S3的复制不需要经过我们执行该命令的机器进行数据中转;

样例请求(UploadPartCopy):

样例请求(UploadPart):

本章小结

本章节,我们深度解析了cp命令在不同场景下的数据传输行为,基本的一些结论见下表;其中,S3到S3的复制,从底层API可以分析出不需要经过运行命令的机器进行中转,这样节约进出执行cp命令的机器流量;同时我们s3api提供了很多底层S3底层接口,基于这些接口,可以方便地在分段上传的基础上实现断点续传。

AWS S3 CLI上传下载性能测试

本章继续和大家一起来探讨下影响AWS S3 CLI进行数据传输的性能的基本因素以及实际场景下基于AWS EC2的一些数据传输性能测试情况。

同区域不同S3桶数据的复制性能测试

测试环境:

  • BJS区域
  • R4.2xlarge 跑cp命令
  • AWS CLI S3参数max_concurrent_requests为1000
  • 测试方法,脚本跑10次取平均时间

测试结果如下,时间单位是秒:

总体平均时间:(29+29+28+6+29+5+6+6+6+29)/10=17.3秒,root.img的大小为8.0GB,AWS北京区域不同桶之间的数据平均传输速度为473.52MB/s,最高速度可以达到1.6GB/s,最低282.48MB/s。

为了验证该场景下对网络的影响,我们截取了这阶段的网络方面的监控,我们观察到这段时间,该测试机的网络输出和网络输入有几个波峰,但峰值最高没超过12MB,从侧面验证了我们的前面的判断,即cp在S3到S3复制的场景下,数据不会经过命令行运行的机器转发,而是直接由S3服务直接完成:

S3桶数据到AWS EC2下载性能测试

测试环境(针对下面表格的场景一):

  • BJS区域
  • R4.2xlarge 跑cp命令,
  • EC2挂500GB的gp2 ssd磁盘
  • AWS CLI S3参数max_concurrent_requests为1000
  • 测试方法,脚本跑10次取平均时间

测试结果如下,时间单位是秒:

总体平均时间:(67+64+66+65+65+65+66+65+64+65)/10=65.2秒,root.img的大小为8.0GB,该测试场景的数据平均传输速度为125.64MB/s,下载速率比较平稳。

在继续试验之前,我们总结下,影响EC2虚机下载S3数据的速度的几个因素:

  • 磁盘的吞吐率(SSD还是实例存储还是HDD)
  • EBS带宽,是否EBS优化(EBS本身也是通过网络访问,是否有EBS优化为EBS I/O提供额外的专用吞吐带宽,否则和EC2网络共享带宽性能)
  • S3服务的带宽(通常我们认为S3服务不是性能瓶颈)

我们已经测试了R4.2xlarge的下载性能,接下来我们选择几个典型的虚机类型分别进行测试,由于测试时间跨度比较大,测试场景中的EC2操作系统层没有任何调优,测试结果仅供参考。所有场景测试都针对一块盘,进行同一个8GB的文件下载,下载10次,根据时间算平均下载速率。

通过简单的测试我们发现,

1.    虽然随着机型增大比如从R4.xlarge 到R4.4xlarge,同样是单块SSD磁盘的情况,磁盘就成为整个下载速度的瓶颈,因为R4.4xlarge EBS优化的专用吞吐量理论值可以达到437MB/s,而简单测试下来的下载速度最高到130MB/s左右;

2.    SSD磁盘在整个测试场景中,是最优的选择,而且SSD盘的大小无需到3TB就可以有很好的性能表现

3.    实例存储在没有预热(dd整个盘)的情况下表现很一般

4.    st1盘6TB左右的测试盘,下载测试性能不如500GB的SSD盘

5.    3334GB的SSD盘的表现跟比预期要差很多

6.    测试场景中EC2下载S3的平均速度没有超过150MB/s

以上表格中的虽然我们测试了不同系列的不同规格的机型,但是我们可以通过修改实例类型非常方便地切换,因此监控上我们可以看出测试时间跨度中,我们的机器资源使用情况。

整个测试过程中R4系列机器的CPU的利用率总体还算正常,在15%到60%之间浮动:

整个测试过程中500GB的gp2磁盘的写入带宽变化如下图所示:

整个测试过程中3334GB的gp2磁盘的写入带宽变化如下图所示:

整个测试过程中6134GB的st1磁盘的写入带宽变化如下图所示:

AWS S3 CLI的一些限制

S3 CLI提供的分段上传算法有些限制在我们实际使用的时候,特别要关注比如分段总大小不能超过10000,每个分段的数据块最小为5MB,分段上传最大的对象为5TB等等。详细情况请参考AWS官方文档

下一篇将要探讨和解决的问题

在了解AWS S3 CLI命令底层原理和影响基本性能的基本因素之后,我们接下来会继续来探讨,如何利用S3的底层API实现S3中的数据的跨区域可靠、低成本、高效传输。

总结

本文和大家一起深度研究了AWS S3 cp命令在各种场景中的底层实现原理,同时利用实验,总结了关于AWS EC2下载S3数据的基本性能测试结果,期待更多读者可以实践出更多的性能优化方法。随着大数据分析的蓬勃发展,存放在S3上的数据越来越多,本系列主要会和大家一起深度探讨S3数据复制迁移的最佳实践。

作者介绍:

薛军

AWS 解决方案架构师,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证。负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在互联网金融、保险、企业混合IT、微服务等方面有着丰富的实践经验。在加入AWS之前已有接近10年的软件开发管理、企业IT咨询和实施工作经验。

将 AWS 认证工程师的数量从零增加到数百个的 12 步计划

“不要总希望得到您还未得到的;这会使您看不到目前拥有的可能性”

作为 AWS 企业战略家,我拥有与全球各地面对着各种业务和技术难题的高管们会面的特权。每个客户都是独一无二的。但是,许多难题,如同历史一样,往往具有规律性。

其中一个规律是,市场中的技能难题以及“不在相应岗位上配备合适的人员就会妨碍您提高行动速度、节省资金和在云上拓展业务”这一想法。可以肯定的是,随着人们认识到让 AWS 完成基础设施领域的无差别的繁重工作的好处,包含单词“AWS”和“云”的招聘广告显著增加了。但是,我认为这种不断增加的需求或者您没能获得所需人才的感觉并不会阻碍您的企业在云方面获得成功。

AWS 企业战略部主管 Stephen Orban 在一篇最新文章中就这一问题有力地指出,“您已经拥有成功实现云迁移所需的人才。”而且,为了加强这一说法的说服力,我想要分享我本人遇到一个主要技能难题时发生的故事。事情要追溯到 2014 年,我的云之旅才刚刚开始。

当时我在英国的 Capital One 担任首席技术官,然后,我发现自己在深入思考我在我的工程师身上发现的技能差距。这些工程师确实很有才华,但他们只是精通传统的内部技术;因此,他们掌握的大部分是孤立的基础设施技能。

为了寻求改变,我随后又犯了一个经常犯的错误:创建一个独角兽式的工作规范并自以为是地将它应用于外部就业市场。当我发现在收件箱中没有收到任何对这则招聘广告的回应时,我感到十分惊讶和失望。

很明显,我漏掉了一个重要的事实。

我拥有的技能高超、积极主动且全心投入的团队就是我需要的团队。只不过,团队成员们需要一个途径、一个动机以及一个善于倾听和帮助他们消除自身与生俱来的对未知技术恐惧的人。

有关人才转型的这种认识和企业云之旅为我积累了大量最佳实践,也让我更深刻地了解人类。但我必须说实话;在这个过程中,我们犯了很多错误并且浪费了很多时间。但是我们还是找到了一条途径,最终发挥了作用并且为 Capital One 在英国的成功做出贡献。这帮助 Capital One 将全球的技术人才提升到了极高的水平。实际上,所有 AWS 认证开发人员中现在足足有 2% 的人在 Capital One 工作

在说明优势之后,下面将介绍适合我们的 12 个步骤 —

步骤 1 — 接受

心理健康专家们表示,接受是走向恢复的第一步;这种说法在此处也完全适用。您的工程师们必须接受他们有能力学习 AWS 云技能并成为专家的事实。接受这一事实对于您组织内的技术主管来说也同样非常重要。正如 Stephen Orban 在文章中所述以及我在 Capital One 任职期间的经历所表明的那样,您拥有的人才就是您需要的人才。这些是在开发和运行您的现有系统方面拥有多年的重要经验的人员。

步骤 2 — 培训

在接受之后,您应该迅速开始 AWS Technical Essentials 课程。此课堂教学课程能让人大开眼界并愉快地一窥无限可能的艺术。对此,AWS 自己的培训团队或我们的其中一位获批培训合作伙伴可以起到很大的推动作用。

步骤 3 — 动手实践时间

对于经验的获得,没有任何捷径可言。因此,现在需要进行动手实践。即使略显笨拙,工程师也需要花费这些时间并在一个安全的位置实施配置。此外,目前似乎有数百万个实现这种可能性的方法,并且这些方法都有点难以掌控。您的工程师可能会非常兴奋,也可能会有点垂头丧气。识别每个人经历的正常变化曲线 (有些人的很短,有些人的很长 — 因人而异) 非常重要。持续激励也很重要。

步骤 4 — 创建您的双比萨团队

您组建的第一个工程团队应彻底包含各项核心技能的组合 — 网络、数据库、Linux 服务器、应用程序、自动化、存储和安全性。该团队将取得一些进步。它可能着眼于 Terraform 之类的工具以及其他东西。它还将编写一些 CloudFormation 代码。该团队会犯错。这是非常自然的事情。

步骤 5 — 引进一些专家

对于经验的获得,没有任何捷径可言 (续)。现在,您应该引进一些真正的专家。事实上,增加一些乐意分享经验教训和最佳实践的专家级工程师是目前至关重要的事。在英国的 Capital One,我与 CloudReach 密切合作,引进大量具有专业认证且经过现场证实的 AWS 工程师来达到此目的。我将这些专业工程师分配到不同的团队来满足他们对专业知识的需求。这一举措产生了变革性的影响。员工们通过观察、提问和“照着做”来互相学习。更好的一点是,工程师们喜欢向工程师同事学习。此外,由于在小型团队中工作,他们有机会提出问题并尝试在课堂环境下不会尝试的事情。我们甚至将这一过程所需的时间缩短至一天。在这样短的时间内,一位新工程师加入了团队,与一位专家结成搭档,然后通过 CloudFormation 和已出现的关联的持续集成/持续开发 (CI/CD) 最佳实践展示了自己。

步骤 6 — 实现目标

在这个阶段,敏捷双比萨团队的目标应是构建真实的环境并投入生产。这可能是用于托管小型应用程序和相关网络设置的基本 Amazon 系统映像 (AMI)。目的是找出对于着手工作来说很重要但并非关键的东西。设定在数周内而不是数月内完成这一目标。跟踪进度。展示好处。设置演示截止时间。随时查看进度以及最终结果。一句忠告 — 切忌让团队好高骛远。仅使用所需的 AWS 构建块。(您无需从一开始就掌握所有 90 多个构建块。)以后将有大量时间来扩展到其他构建块,因为您的解决方案会需要它们。实验的好处很关键,在学习过程中可以根据需要不断地丢弃然后重新开始,就像 AWS 在教您“走路”一样自然。

步骤 7 — 利用“细胞核分裂”推广学习成果

由于第一个团队达到了一定的 AWS 熟练度并且交付了一款产品,您现在需要观察这第一个团队的细胞核分裂。此外,您还需要逐渐但有意识地将已获得经验和最佳实践的这第一个团队分为两个全新的 4 人团队,然后为每个团队再引进 4 位工程师。这项工作将会很困难,应该小心处理。坦诚对待团队成员并肯定他们的共同成果将至关重要。此外,还要请求成员帮助您将经验教训和最佳实践传递给新的队友。采用这种细胞核分裂式方法继续拆分和重组团队,直到所有工程师融合成一个技术水平相当的团队。

步骤 8 —认证

通过与 AWS 技术培训或我们的其中一位出色的合作伙伴合作,您现在可以开启认证之路。鼓励使用 A Cloud Guru 之类的服务还可以为工程师提供让他们根据自己的时间和节奏通过认证的流程。我提倡从助理级认证开始,然后逐渐提升到专家级认证。我在这里要暂停一下来重点说明这一点。对于这个经常被忽视的步骤,无论我怎么强调其重要性都不过分。在 Capital One,我们在工程师认证、应用程序的迁移以及 AWS 上的新系统构建之间发现了一种直接关联。Capital One 甚至为一个用于度量转型的过程申请了专利。工程师的认证过程展示出显而易见的专业上的进步,它还使通用 AWS 语言能够传播并形成支持解决方案开发的事实方法。

步骤 9 — 推广认证和相关领导力

Capital One 本身的经验、与我们许多客户的合作经验以及科学研究表明,在网络效应产生作用之前,您的拥护平台的工程师需要达到 10% 的临界数量。因此,将这种学习和认证推广到您的 10% 的工程师是您的云之旅中的重大里程碑。从这个阶段开始,您将获得强有力的晕轮效应,这种效应将开始影响外部人员看待您公司的方式,而不只是影响内部人员。您组织外的那些仅希望与原生云公司合作的工程师将开始认真考虑为您工作。因此,随着您吸引更多人才或将原有人才转变为具有云素养的人,您转型的速度将呈指数级提高。

步骤 10 — 认可并奖励专业知识 (以非常公开且自豪的方式!)

作为 IT 主管,您的目标是公开宣布通过每个认证考试的每个工程师的姓名。以您能力范围内的任何方式奖励并认可技术进步。这包括宴请、优惠券、饮品、特别团队岗位、新奇的奖励,总之就是您能够想到的各种奖励。在 Capital One,我们拥有一份包含所有员工姓名以及他们获得的所有 AWS 认证的全球花名册。认证被视为一种有形的发自内心取得的成就。我遇见的几乎每一位工程师都渴望得到同行的尊重,而认证以及您获得的成就将为社区荣誉做出贡献。

步骤 11 — 挑战自我

当我在市政厅会议上表彰和奖励取得进步的工程师时,听众席中的一位言辞尖锐的人大声地说:“既然您如此热情洋溢地相信认证,那么您将在什么时候参加考试?”这很直接地打断了我的话。我有很长一段时间没有参加过行业考试了。但是,正如喜欢实践我宣扬的理论的人一样,我走进了考场。然后,我通过了 AWS 助理架构师认证考试。现在,我也能骄傲地站在这个舞台上!参加考试对我而言是一种极好的强迫机制,进而确保我获得了对关键 AWS 构建块的广泛但足够详细的了解。

步骤 12 — 创建统一的同类职业组合

最后,在适当的时候,您需要为您的技术员工提供具体的同类职业跟踪。以下是英国的 Capital One 在 IT 中创建的一些同类职业跟踪 —

技术项目经理 (TPM) — 通常负责敏捷执行、版本系列一致性和团队相互依赖性。

AWS 基础设施工程师 (IE) — 之前的数据中心系统工程师,过去通常负责 Linux/Wintel/Network 等。现在负责根据产品团队的需要创建用于不同的 AWS 构建块的 CloudFormation 代码。AWS 专家。

软件开发工程师 (SDE) — 编写逻辑并处理采用各种软件语言的数据结构。

软件质量工程师 (SQE) — 使用测试驱动型设计原则。确保在整个生命周期中都考虑并执行测试。

安全工程师 — 确保安全问题的全面性。

工程经理 — 该经理负责设计意图以及管理由上述技能团体的工程师组成的团队。

在您采用此途径时,应注意一些无形的晋升障碍可能会被打破。具体来说,不负责管理人员的工程师现在能够晋升到非常高的职位 (包括主管或主管以上职位) ,并且仍然不需要管理人员。这些晋升应考虑技术深度和相关能力发展以及逐渐提高的技术领导力成熟度。作为领导者,看到员工攀升到新的高度并获得来之不易的晋升始终是在该职位上令人欣慰的事情。我的团队中抓住绝佳机会的很多成员都自豪地获得了晋升。我们还自行打破了这种无形的障碍,而当我从英国 Capital One 离职时,我最自豪的时刻之一就是将我们的云卓越中心中的一位创始成员提升到了基础设施工程部门主管级别。这个人一直是一个独立贡献者和动手实践 AWS 专家,同时也是大家的好朋友。

将上述 12 个步骤作为人才转型的途径可以发挥您的团队成员的潜力,让他们为您的客户带来巨大的成果。

记住 — “您的所有假定的限制条件都是可辩驳的。”

Jonathan Allen
@jonathanallen02
jnatall@amazon.co.uk
EMEA 企业战略家和推广者

介绍 Gluon 这一易于使用的灵活深度学习编程接口

原文链接 | 今天,AWS 和 Microsoft 发布了一项新规范,该规范旨在为所有开发人员改进机器学习技术的速度、灵活性和可访问性,而无论他们选择什么样的深度学习框架。这种合作的第一项成果是全新的 Gluon 接口,这是 Apache MXNet 中的一个开源库,让所有技能级别的开发人员都能够设计深度学习模型的原型、构建该模型以及开展训练。该接口极大地简化了创建深度学习模型的过程,而不会影响到训练速度。

下面是 Gluon 的四大优势以及演示这些优势的代码示例:

(1) 简单、容易理解的代码

在 Gluon 中,您可以使用简单、清晰和简洁的代码定义神经网络。您将获得一整套即插即用的神经网络构建块,包括预定义的层、优化程序和初始化程序。利用这些构建块,您无需再纠缠于各种各样复杂的底层实施细节。下面的示例说明了如何使用短短几行代码定义一个简单的神经网络:

# 第一步是初始化您的模型
net = gluon.nn.Sequential()
# 接下来,定义您的模型架构
with net.name_scope():
    net.add(gluon.nn.Dense(128, activation="relu")) # 第一层 - 128 个节点
    net.add(gluon.nn.Dense(64, activation="relu")) # 第二层 - 64 个节点
    net.add(gluon.nn.Dense(num_outputs)) # 输出层

下表说明了神经网络的体系结构:

有关更多信息,请转到本教程,了解如何使用 Gluon 神经网络构建块来构建一个称为多层感知器 (MLP) 的简单神经网络。对于更高级的使用案例来说,从头开始编写神经网络的各个部分也是非常容易的。使用 Gluon,您可以在神经网络中混用和匹配预定义组件和自定义组件。

(more…)

Gluon 简介:AWS 和 Microsoft 合作推出的新机器学习库

作者:Matt Wood 博士

针对云迁移的 21 个最佳实践

熟能生巧。-Bobby Robson

在过去几个月里,我花了很多时间与各种 AWS 客户和团队合作来打造帮助企业加快云迁移工作的全面计划。此计划包含许多方面,包括 (但不限于) AWS 服务 (例如,AWS Database Migration Service、AWS Snowball、VM Import/Export)、一个由 AWS 专业服务打造的迁移方法、一个即将推出的“迁移到 AWS”培训计划以及与工具提供商和咨询商店建立的合作伙伴关系 (旨在加快各行各业各种规模的企业的云迁移速度)。

今天,我很高兴介绍由本公司的员工 Sadegh Nadimi 编写的一篇客座文章,此人详细说明了我们在执行到 AWS 的大型迁移的企业中观察到的 21 个最佳实践。言归正传 . . .

-Stephen
orbans@amazon.com
@stephen

(more…)

在使用云进行试验时,4 件要做的事情和不要做的事情

“证明一根木棒是弯木棒的最佳方法不是争论或花时间去抨击,而是将一根直木棒放在它旁边”― D.L. Moody

在我的上一篇文章中,介绍了云如何使所有类型和规模的公司能够以更低的成本更轻松地进行试验且风险更小。公司越是意识到这一点,就越有更多的试验文化成为在今天的市场中保持竞争力的筹码。 试验引发创新,从来没有这么好的机会实施新想法。

您从何处开始?下面是在您的组织内打造试验文化时要考虑和避免的四件事。

1. 需要管理期望

虽然并不是每个试验都将提供您预想的结果,但每个试验都是一个了解和改善运营的机会。如果您的组织不习惯“未能学习”这个概念,请从小事做起,确保每个人都摘掉您考虑试验的项目。通过清楚了解实验目的、预期结果、测量和测试结果的方式以及您希望从中学到的知识来管理您的利益相关者的期望。我发现,如果大多数高管知道组织更乐意进行试验并学习知识,他们将欣赏那些结果不确定的试验。

不要从每个人都有一个特定结果的项目开始

如果您充当尝试打造试验文化的变革代理,请不要在您的旅程中过早地试验您的利益相关者期望获得特定结果的项目。我不是建议您开始试验年末账单运行 (举例来说)。我曾经为其工作的一位首席执行官告诉我,失败是可以接受的 (除非没有失败)。要对逐步积累的进展感到满意,并慢慢地增加你所进行的试验的数量,但不要超过组织。

2. 需要鼓励您的团队计划试验

每个组织都有自己的方法来确定哪些项目获得了技术资源。不幸的是,一些组织现在将技术或 IT 部门视为成本中心,并且已将理念推到离实现位置太远的地方了。好的想法可以来自任何地方,当然,当它涉及外部项目时,大多数技术专家都有一个独特的观点。这在刚开始使用云的组织内尤为如此 - 对项目使用云的个人处于计划试验的最佳位置,这些试验利用云的独特功能来使业务受益。帮助支持您的团队的计划,并安置好您的员工以影响高层管理团队所投资的项目。

在知道如何测量试验之前不要进行试验

您希望将时间花在正确的试验上,并确保从中学到的经验将改善您的运营和产品。在您让您的团队向前推进试验之前,您应同意他们将在试验期间测量的内容和测量方法。如果您正在测试网站上的新功能,哪些指标将使测试成功?页面视图?单击次数?放弃?这种小而重要的尽职调查将迫使您的团队去思考为什么他们要首先计划一个试验。它还将强制您的团队设定正确试验的优先级。

3. 需要考虑开发运营使试验制度化

开发运营文化是一种将试验融入组织中的强有力的方式。通过将运行您构建的内容与自动化相结合,可以大大减少发布更改所花的时间,从而允许您更频繁地发布更改并在失效时更快地回滚更改。成熟的开发运营组织还开发了 A/B 测试框架,这些框架可使其在不同的用户群中尝试不同的用户体验以了解什么是最有效的。

不要怀疑您的团队

怀疑是对团队造成打击并打开失败之门的最有力的方法之一。当您学会适当地审视试验、测量试验并对其进行快速迭代时,您应会发现在需要怀疑之前,您能够适应您的方法。确保您的团队正在考虑正确的方法来测量试验并提出尖锐的问题是正常的,但您应考虑帮助团队解决问题而不是怀疑他们的交付能力。 人们倾向于追随那些相信他们会成功的领导者

4. 需要鼓励整个组织进行参与

当您开始通过试验更快地交付结果时,组织的其他方面将被您的方法吸引。吸引这些人的参与。尝试一个包含不同业务领域的黑客马拉松,让您的利息相关者帮助确定测量试验的方式,并询问组织他们一直想要进行试验的领域。虽然不是每家公司都会选择为其员工提供试验时间,但这些公司通常会将它宣传为竞争优势。至少,这些具有包容性的活动可以提高员工士气和员工保留率。在 Amazon 的短暂任期内,我发现任何能够写作进行思考和表达试验的人员通常都会有机会进行尝试。这是我们的文化的一个特殊部分,也是吸引和留住创新者和建设者的出色工具。

不要让试验减速或停止交付

不要让您的团队仅因某件事是一个试验而逃脱责任。虽然失败和学习是允许的,但在试验中无法交付是不允许的。软件仍需要交付测试;它通常需要用实际的生产流量来进行测量。仅仅因为这是一个实验并不意味着您应稍后开始测量它,或者让其质量受到影响。毕竟,您仍在运营业务。

您的组织通过什么来支持试验文化?请一定告诉我!

不断前进,
-Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/

注:打造试验文化是我在企业云之旅系列文章中撰写的七个最佳实践中的第三个最佳实践。其他六个最佳实践是:提供高管支持对员工进行培训寻找合作伙伴创建云卓越中心实施混合架构和实施云优先策略。请保持关注以获得每条最佳实践的更新。

 

Amazon Linux AMI 2017.09 现已推出

我很高兴地宣布,Amazon Linux AMI 的最新版本 (2017.09) 现可供所有 AWS 区域中当前一代的所有 EC2 实例使用。此 AMI 包含受支持和维护的 Linux 映像,该映象旨在为 EC2 上运行的应用程序提供稳定、安全和高性能的环境。

易于升级
只需运行以下两条命令然后重启,就可将现有实例升级:

$ sudo yum clean all
$ sudo yum update

好处多多
此 AMI 包含许多新功能,其中有很多都是应客户要求而添加的。总结如下:

Kernel 4.9.51 – 此内核以 4.9 稳定内核系列为基础,包括 ENA 1.3.0 驱动程序,还支持 TCP 瓶颈带宽和 RTT (BBR)。请阅读我的文章 Elastic Network Adapter – Amazon EC2 高性能网络接口,了解有关 ENA 的更多内容。要了解如何启用 BBR,请阅读发行说明

Amazon SSM 代理 – Amazon SSM 代理现已默认安装。也就是说,现在您可以使用 EC2 Run Command 在您的实例上配置并运行脚本,而无需进行其他设置。要了解更多内容,请阅读使用 Systems Manager Run Command 执行命令使用 EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

Python 3.6 – 现已包含 Python 最新版本,还可通过 virtualenvalternatives 进行管理。您可以使用如下方法安装 Python 3.6:

$ sudo yum install python36 python36-virtualenv python36-pip

Ruby 2.4 – 现已提供 Ruby 2.4 系列最新版本。安装方法如下:

$ sudo yum install ruby24

OpenSSL – 此 AMI 目前使用 OpenSSL 1.0.2k

HTTP/2 – 此 AMI 的 httpd24nginxcurl 程序包现已支持 HTTP/2 协议。

关系数据库 – 现已推出 Postgres 9.6MySQL 5.7,安装方法如下:

$ sudo yum install postgresql96
$ sudo yum install mysql57

OpenMPIOpenMPI 程序包现已由 1.6.4 升级到 2.1.1。已推出 OpenMPI 兼容包,可用于构建及运行较旧的 OpenMPI 应用程序。

更多 – 更新的其他程序包包括 Squid 3.5Nginx 1.12Tomcat 8.5GCC 6.4

立即启动
您现在就可以使用此 AMI 在所有 AWS 区域启动 EC2 实例。它适用于由 EBS 提供支持的实例和由实例存储提供支持的实例,还支持 HVM 和 PV 模式。

Jeff

Microsoft SQL Server 2017 在 Amazon EC2 上的实践

Microsoft SQL Server 2017 (几天前刚刚发布) 包含许多强大的新功能,包括支持图形数据库数据库自动优化,还能创建无集群 Always On 可用性组。它还能在 Linux 和 Docker 容器中运行。

在 EC2 上运行

我很高兴地在此宣布,现在,您可以启动运行 Windows Server 2016 以及 SQL Server 2017 的四个版本 (Web、Express、Standard 和 Enterprise) 的 EC2 实例了。今天,AMI (Amazon 系统映像) 已在所有 AWS 区域提供,可以在各种 EC2 实例类型上运行,包括全新的 x1e.32xlarge (具有 128 个 vCPU 和接近 4 TB 的内存)。您可以通过 [控制台] 或 [Marketplace] 启动这些实例。以下是它们在控制台中的样子:

以及在 AWS Marketplace 中的样子:

丰富的许可选项

对于 SQL Server 您拥有多种许可选项:

按需付费 – 如果您已经在运行旧版 SQL Server,希望升级,但不想购买许可,那么此选项很适合您。您不必进行调整、软件合规性审计或软件保障,也不需要长期购买。如果您运行的是 SQL Server 标准版,还可得益于我们最近的降价,最多可节省 52%。

许可证移动性 – 选择此选项可使用您的活跃软件保障协议,将现有许可证带到 EC2,还能在 Windows 或 Linux 实例上运行 SQL Server。

自带许可 – 选择此选项,您可利用现有许可证投资,尽量降低升级成本。您可以在 EC2 专用实例EC2 专用主机上运行 SQL Server,如果按内核许可 SQL Server,还有可能降低运营成本。使用此选项可在 EC2 Linux 实例上运行 SQL Server 2017 (支持 SUSE、RHEL 和 Ubuntu),还支持在 EC2 Windows 和 Linux 实例上运行的基于 Docker 的环境。要了解有关这些选项的更多详情,请阅读在 Linux 上安装 SQL Server 的指南使用 Docker 运行 SQL Server 2017 容器映像

了解更多

要了解有关 SQL Server 2017 的更多详情,并深入探索您的许可选项,请查看 AWS 上的 SQL Server 页面。如果您需要迁移规划方面的建议和指导,请与有能力处理 Microsoft 工作负载,且专注于数据库解决方案的合格 AWS 合作伙伴联系。Amazon RDS 计划于 11 月提供对 SQL Server 2017 的支持。届时将会向您提供完全托管选项。请安排时间在 PASS 峰会 (11 月 1-3 日,西雅图) 和 [re:Invent] (11 月 27 日到 12 月 1 日,拉斯维加斯) 与 AWS 团队见面。

Jeff 附言 – 特别感谢我的同事 Tom Staab (合作伙伴解决方案架构师) 对此篇博文的贡献!

使用 Amazon Polly 提供实时家居监控警报

这是 Y-cam Solution 高级开发人员 Siva K. Syamala 撰写的客座博客文章。用她自己的话说,“Y-cam 是高质量安保视频解决方案提供商,我们的愿景是让智能家居安防系统变得简单,方便所有人使用。” | 原文链接

家居安防是家庭自动化和物联网的重要组成部分。Y-cam Solutions Limited 在 Amazon 的大力支持下,提供了一个智能安防系统,该系统可通过智能手机在世界任何地方进行监视和控制。为了改进警报、通知和系统控制方式,Y-cam 使用 Amazon Polly 提供一流的 AI 服务。利用该服务,用户可通过语音与安防系统进行交互。

我们的服务的工作方式

当触发报警时,我们通过 Twilio 以语音电话的方式通知客户。在建立呼叫后,Twilio 将逐步执行 TwiML 指令,并使用从 Amazon Polly 检索的合成语音开始向客户传送信息。电话接听方通过按手机键盘上的按钮 (DTMF 代码) 来做出回应。根据具体的 DTMF 代码,我们的服务会采取指定的操作,并返回从 Amazon Polly 检索的合成语音所对应的 TwiML 指令。为了让用户听起来像一个真实的对话,Amazon Polly 必须快速做出回应。延迟和等待会让人不满,并更有可能会导致接听方挂断电话。

下面是触发警报时向客户拨打的电话的示例音频剪辑。

架构

 

呼叫 Amazon Polly

以下 Java 代码说明了从 Amazon Polly 请求合成语音并将其存储在 S3 存储桶中的过程。

(more…)