亚马逊AWS官方博客

EC2 可转换预留实例更新 – 新的 1 年 CRI,合并和拆分

我们在大约一年前推出了 EC2 的可转换预留实例。可转换 RI 为您提供了大幅折扣 (与按需相比通常为 54%),并允许您更改与 RI 相关联的实例系列和其他参数 (如果需要更改)。

今天,我们推出具有 1 年期的可转换 RI,这是对现有的 3 年期的补充。我们还允许您交换部分 RI 以及执行批量交换,从而使可转换预留实例模型更加灵活。

新的 1 年期可转换 RI
具有 1 年期的可转换预留实例现已推出。这将给您更多选项和更多灵活性;您现在可以根据需要购买 1 年期和 3 年期可转换预留实例 (CRI) 的组合。有财政约束的初创公司将会发现这一选项颇具吸引力,而其他可能无法做出运行超过一年的承诺的企业也会觉得有吸引力。

合并和拆分可转换 RI
假设您开始在 M4 实例上运行 Web 和应用程序服务器并使用可转换 RI 来节约资金。稍后,在有了优化实践后,您可以将应用程序服务器迁移到 C4 实例。随着今天的推出,您可以用您的部分 M4 可转换 RI 来交换 C4 可转换 RI。您还可以合并两个或更多 CRI (可能用于较小的实例),获得一个 CRI 以用于较大的实例。

可转换预留实例的交换模型基于拆分、交换和合并。比方说,我拥有一个 3 年预付部分费用 CRI 用于四个t2.micro 实例:

我的应用程序已更改,现在我想要使用一对 t2.micro 实例和单个 r4.xlarge。第一步是将此 CRI 拆分为我想要保留的部分和我想要交换的部分。我选择它并单击修改预留实例。然后我创建所需的配置,并单击“继续”:

我审核请求并单击提交修改

CRI 的状态发生变化,以表明它正被修改。过一会儿,它将被标记为停用,被已激活的一对替换:

现在我可以交换一个 2 实例 CRI。我选择它,并单击交换预留实例,然后为我的新 CRI 输入所需配置:

我单击查找产品以查看我的选项,并选择所需的选项,即 r4.xlarge 预付部分费用。正如您所看到的,在计算预付款时,控制台“进行数学运算”考虑了不必要 CRI 的剩余预付价值 (在本例中为 139.995 美元):

当我做好继续准备后,我单击交换。这将启动交换过程,并让我知道可能需要数分钟才能完成。

我还可以将两个或更多可转换预留实例合并到一起,然后将它们用作交换的起始点。为此,我仅需选择现有 CRI,单击操作,选择交换预留实例。我可以看到所选 CRI 的总剩余预付价值,并相应地继续操作:

您可以合并具有不同开始日期和/或期限长度的 CRI。合并后的 CRI 将具有离交换日期最远的 RI 的过期日期。将不同期限长度的 CRI 合并在一起,总是会产生 3 年 CRI。

您还可以使用 AWS 命令行界面 (CLI) 和 EC2 API 执行拆分、交换和合并操作。

现已推出
本文描述的所有功能和 1 年 CRI 现已推出,您可以立即开始使用它们。

Jeff

AWS 价目表 API 更新 – 新增查询和元数据函数

原始 AWS 价目表 API (如新增 – AWS 价目表 API中所述) 使您可以通过结构化 URL 访问 JSON 和 CSV 形式的价格。虽然这对某些类型的成本管理工具很有效,但文件的大小和复杂性使得它们难以下载,而且难以解析。今天,我们将要通过添加新函数来更新 API,使您可以执行精细价格查询,从而仅返回您需要的价格。这将使您能够在移动应用程序和基于浏览器的应用程序中使用这些价格。

新增函数
下面是新增函数:

DescribeServices – 返回用于定义服务中的产品的属性键集合。例如,为 EC2 返回的键将包括 physicalProcessormemoryoperatingSystemlocationtenancy

GetAttributeValues – 返回给定属性键的所有允许值。例如,operatingSystem 键的值包括 WindowsRHELLinuxSUSElocation 键的值包括 US East (N. Virginia)Asia Pacific (Mumbai)

GetProducts – 返回与基于服务名称和属性值的筛选条件表达式匹配的所有产品及其公开价格。

您可以从 AWS 开发工具包中访问这些函数。为了试用它们,我使用了 Python 和适用于 Python 的 AWS 开发工具包。我首先导入开发工具包并创建客户端:

import boto3
import json
import pprint

pricing = boto3.client('pricing')

下面是我如何列出所有服务和属性:

print("All Services")
print("============")
response = pricing.describe_services()
for service in response['Services']:
    print(service['ServiceCode'] + ": " + ", ".join(service['AttributeNames']))
print()

输出的开头部分如下所示:

All Services
============
SnowballExtraDays: productFamily, termType, usagetype, locationType, snowballType, feeDescription, servicecode, feeCode, location, operation
OpsWorks: productFamily, servicecode, termType, usagetype, locationType, location, operation, serverLocation, group
mobileanalytics: productFamily, servicecode, includedEvents, termType, usagetype, description, locationType, location, operation
IngestionServiceSnowball: productFamily, fromLocationType, termType, usagetype, locationType, toLocationType, toLocation, snowballType, servicecode, groupDescription, transferType, location, fromLocation, operation, group
IngestionService: productFamily, termType, usagetype, locationType, servicecode, groupDescription, dataAction, location, operation, group
ElasticMapReduce: productFamily, softwareType, instanceType, termType, usagetype, locationType, instanceFamily, servicecode, location, servicename, operation
datapipeline: productFamily, frequencyMode, termType, usagetype, locationType, description, executionFrequency, servicecode, location, operation, group, executionLocation
...

下面是我如何获取所有 EC2 定价属性的所有值:

print("Selected EC2 Attributes & Values")
print("================================")
response = pricing.describe_services(ServiceCode='AmazonEC2')
attrs = response['Services'][0]['AttributeNames']

for attr in attrs:
    response = pricing.get_attribute_values(ServiceCode='AmazonEC2', AttributeName=attr)

    values = []
    for attr_value in response['AttributeValues']:
        values.append(attr_value['Value'])

    print("  " + attr + ": " + ", ".join(values))

输出的开头部分如下所示:

Selected EC2 Attributes & Values
================================
  volumeType: Throughput Optimized HDD, Provisioned IOPS, Magnetic, General Purpose, Cold HDD
  maxIopsvolume: 500 - based on 1 MiB I/O size, 40 - 200, 250 - based on 1 MiB I/O size, 20000, 10000
  instanceCapacity10xlarge: 1
  locationType: AWS Region
  instanceFamily: Storage optimized, Micro instances, Memory optimized, GPU instance, General purpose, Compute optimized
  operatingSystem: Windows, SUSE, RHEL, NA, Linux
...

下面是我如何使用服务名称和属性值来获取在亚太 (孟买) 区域具有 64 vCPU、256 GiB 内存、预装 SQL Server Enterprise 的 EC2 实例的价格列表。每个价格都是一个 JSON 字符串:

print("Selected EC2 Products")
print("=====================")

response = pricing.get_products(
     ServiceCode='AmazonEC2',
     Filters = [
         {'Type' :'TERM_MATCH', 'Field':'operatingSystem', 'Value':'Windows'              },
         {'Type' :'TERM_MATCH', 'Field':'vcpu',            'Value':'64'                   },
         {'Type' :'TERM_MATCH', 'Field':'memory',          'Value':'256 GiB'              },
         {'Type' :'TERM_MATCH', 'Field':'preInstalledSw',  'Value':'SQL Ent'              },
         {'Type' :'TERM_MATCH', 'Field':'location',        'Value':'Asia Pacific (Mumbai)'}
     ],
     MaxResults=100
)

for price in response['PriceList']:
 pp = pprint.PrettyPrinter(indent=1. width=300)
 pp.pprint(json.loads(price))
 print()

输出的开头部分如下所示 (还有很多):

Selected EC2 Products
=====================
{'product': {'attributes': {'clockSpeed': '2.3 GHz',
                            'currentGeneration': 'Yes',
                            'dedicatedEbsThroughput': '10000 Mbps',
                            'ecu': '188',
                            'enhancedNetworkingSupported': 'Yes',
                            'instanceFamily': 'General purpose',
                            'instanceType': 'm4.16xlarge',
                            'licenseModel': 'No License required',
                            'location': 'Asia Pacific (Mumbai)',
                            'locationType': 'AWS Region',
                            'memory': '256 GiB',
                            'networkPerformance': '20 Gigabit',
                            'normalizationSizeFactor': '128',
                            'operatingSystem': 'Windows',
                            'operation': 'RunInstances:0102',
                            'physicalProcessor': 'Intel Xeon E5-2686 v4 (Broadwell)',
                            'preInstalledSw': 'SQL Ent',
                            'processorArchitecture': '64-bit',
                            'processorFeatures': 'Intel AVX, Intel AVX2, Intel Turbo',
                            'servicecode': 'AmazonEC2',
                            'servicename': 'Amazon Elastic Compute Cloud',
                            'storage': 'EBS only',
                            'tenancy': 'Shared',
                            'usagetype': 'APS3-BoxUsage:m4.16xlarge',
                            'vcpu': '64'},
             'productFamily': 'Compute Instance',
             'sku': '24GRA8RB2KZ9NPCS'},
 'publicationDate': '2017-10-07T00:26:55Z',
 'serviceCode': 'AmazonEC2',
...

响应的下一部分包含一组条款,每个条款都描述了购买实例的特定方式 (按需或多种类型的预留实例):

 'terms': {'OnDemand': {'24GRA8RB2KZ9NPCS.JRTCKXETXF': {'effectiveDate': '2017-09-01T00:00:00Z',
                                                        'offerTermCode': 'JRTCKXETXF',
                                                        'priceDimensions': {'24GRA8RB2KZ9NPCS.JRTCKXETXF.6YS6EN2CT7': {'appliesTo': [],
                                                                                                                       'beginRange': '0',
                                                                                                                       'description': '$30.88 per On Demand Windows with SQL Server Enterprise m4.16xlarge Instance Hour',
                                                                                                                       'endRange': 'Inf',
                                                                                                                       'pricePerUnit': {'USD': '30.8800000000'},
                                                                                                                       'rateCode': '24GRA8RB2KZ9NPCS.JRTCKXETXF.6YS6EN2CT7',
                                                                                                                       'unit': 'Hrs'}},
                                                        'sku': '24GRA8RB2KZ9NPCS',
                                                        'termAttributes': {}}},
           'Reserved': {'24GRA8RB2KZ9NPCS.38NPMPTW36': {'effectiveDate': '2017-04-30T23:59:59Z',
                                                        'offerTermCode': '38NPMPTW36',
                                                        'priceDimensions': {'24GRA8RB2KZ9NPCS.38NPMPTW36.2TG2D8R56U': {'appliesTo': [], 'description': 'Upfront Fee', 'pricePerUnit': {'USD': '374227'}, 'rateCode': '24GRA8RB2KZ9NPCS.38NPMPTW36.2TG2D8R56U', 'unit': 'Quantity'},
                                                                            '24GRA8RB2KZ9NPCS.38NPMPTW36.6YS6EN2CT7': {'appliesTo': [],
                                                                                                                       'beginRange': '0',
                                                                                                                       'description': 'Windows with SQL Server Enterprise (Amazon VPC), m4.16xlarge reserved instance applied',
                                                                                                                       'endRange': 'Inf',
                                                                                                                       'pricePerUnit': {'USD': '14.2400000000'},
                                                                                                                       'rateCode': '24GRA8RB2KZ9NPCS.38NPMPTW36.6YS6EN2CT7',
                                                                                                                       'unit': 'Hrs'}},
                                                        'sku': '24GRA8RB2KZ9NPCS',
                                                        'termAttributes': {'LeaseContractLength': '3yr', 'OfferingClass': 'standard', 'PurchaseOption': 'Partial Upfront'}},
...

阅读使用 AWS 价目表 API 以了解有关这些函数及其返回数据的更多信息。

现在提供
新增函数现已推出,您可以开始在美国东部 (弗吉尼亚北部)亚太 (孟买) 区域使用它们来访问所有公有 AWS 区域和 AWS GovCloud (美国) 的元数据和价格列表,它们是免费的。

要查看如何使用这些函数的真实示例,请在 AWS 管理工具博客上查看新博客文章通过月度预算策略来控制预计用户成本

Jeff

Amazon S3 深度实践系列之二:如何实现 S3 数据跨区域高效可靠传输

背景

Amazon S3 深度实践系列之一:S3 CLI深度解析及性能测试一文中,我们深度剖析了AWS CLI S3相关命令的实际工作原理及单机下载S3数据的基本性能测试情况。在实际工作场景中,很多客户会在AWS多个区域的S3桶里面存储大量数据,而且会遇到将数据批量从一个区域一次转移到另外一个区域的情形;因此,在本篇中,作者和大家一起来探讨下出现这样的需求我们如何进行架构设计及高效实现。

架构设计

存储在S3中的对象随着时间的推移,对象数量逐渐增加,而且总体的数据量也不断膨胀,如果碰到需要将数据从某一个区域的S3存储桶完全复制到另外一个S3存储桶里面,我们会遇到哪些挑战呢?

  • 网络传输带宽的限制
  • 存储桶里面所有对象的分析和列表
  • 源存储桶和目标存储桶权限的设定
  • 传输失败识别和重试的挑战
  • 如何利用并发来加速传输及降低成本
  • 如何判断目标存储桶中的对象和源存储桶中的对象差异及完整性

在通用架构设计环节,我们将复杂的问题分解成一系列的子问题进行分析,并讨论在不同场景下的具体实现时要考虑的因素。如下图所示,我们将该任务分解成独立的五个环节,从图上我们也可以看出来,如何实现大规模数据或任务的并发执行是每个环节能否高效完成的一个很关键的技术要求;而且,只有在步骤三执行数据传输任务时,才会涉及到具体场景中的技术限制,因此我们在执行数据传输任务章节来讨论,同区域不同存储桶之间,AWS海外不同区域存储桶之间,以及AWS海外和国内不同存储桶之间的具体技术考量点。

S3对象“清单”

了解源和目标存储桶里的S3 对象是非常重要的准备工作,该章节我们讨论,如何获得S3存储桶的所有对象列表,包含对象的基本的信息,比如最新版本的对象大小,ETag等等。

Amazon S3本身提供了存储桶管理功能之清单生成功能,该功能是一个异步的AWS后台定期执行,可以实现每天生成一个存储桶清单保存成Excel格式。

同时我们也看到很多用户提问,如何实现一个自定义的清单功能,满足大家对于对象变化比较频繁的存储桶对象的实时统计场景以及更多高级自定义的业务逻辑。

接下来我们来看看这两种方法的具体实现逻辑。

利用S3 CLI实现高效的清单功能

作者利用AWS S3 CLI实现高效的清单功能基于以下两个事实前提:

  1. s3api 的 list-objects-v2虽然文档中说明最多返回1000个对象,但实测可以获得所有对象列表
  2. 同样利用s3api 的 list-objects-v2的delimiter和prefix参数,我们可以实现类似文件夹目录逐级扫描功能

基于以上两个事实,我们实现桶清单的主要逻辑如下图所示:

  • 输入参数主要是:bucket,region和IAM 配置的profile名字,profile默认为default;另外depth控制扫描的“目录”层级
  • 当depth为零时,我们直接尝试利用list-objects-v2一次性获取存储桶中所有对象列表并生成一个json格式的文件(但当桶里面对象太多时,该操作会超时)
  • 当depth为零即单线程无法直接生成存储桶清单时,我们就尝试如下迭代逻辑:
    • 生成存储桶当前“目录”里面的所有对象和该目录中所有“子目录”列表
    • 遍历上一步的“子目录”列表,迭代生成该目录下的对象列表和“子目录”列表
    • 如果遍历的深度等于输入参数depth=n,或者“子目录”列表为空,那么停止遍历子目录,直接生成该层级“目录”里面所有的对象列表

以下是几个关键点实现的代码说明,首先,生成某个“目录”前缀下所有对象列表的AWS S3 CLI命令参考,如下命令将在操作系统后台执行并生成存储桶jason中“目录”前缀“qwikLabs/”下的所有对象列表(包括所有嵌套“子目录”中的所有对象):

$ nohup aws s3api list-objects-v2 --bucket "jason" --prefix "qwikLabs/" --profile bjs > 0.obj. 2>&1

其次,如下命令将仅仅生成指定“目录”前缀“qwikLabs/”下的对象列表(不包括嵌套“子目录“的对象)和所有下一层“子目录“列表,为了加强”子目录“输出格式,我们增加了query参数:

$ nohup aws s3api list-objects-v2 --bucket "jason" --prefix "qwikLabs/" --delimiter "/" --query "{Keys:Contents[].{Key: Key, Size: Size,ETag:ETag},CommonPrefixes:CommonPrefixes[].Prefix}" --profile bjs > 0.1.obj. 2>&1

另外,为了实现并发我们利用了迭代算法以及操作系统后台异步执行AWS S3 CLI命令的方法,最终程序会生成一系列的json文件结果,存储桶中所有的对象列表分布在这些文件当中。

S3自带的清单功能

在了解了我们通过AWS CLI S3命令行工具实现自定义的清单功能之后,我们再来对比下,Amazon S3自带的清单功能。

在存储桶页面,导航到“管理“标签,Amazon S3目前提供了四项S3管理功能,其中跟本文相关的是”清单“功能。该功能支持我们对某一个存储桶,定义多个清单,用户可以根据需要,定义针对不同S3对象前缀生成各自的清单列表,并可以存储在独立的存储桶中:

同时,自带清单功能还支持定义生成清单的频率及清单中包含的对象字段,检查并确定好清单选项之后,服务会帮助我们在保存清单的目标存储桶中设置好相应的IAM策略:

清单任务保存之后,后台会异步定期执行,每次都会按时间生成manifest.json 文件和一系列的清单文件,manifest.json 里面包含这次生成的所有清单文件列表:

S3对象清单小结

Amazon S3 存储桶已经内置了清单功能,基本可以满足我们的日常需求,我们不需要重复造轮子;本章节所讨论的利用AWS S3 CLI 命令行自定义实现清单功能,更多的是作者好奇的发现,AWS S3 CLI 本身非常好用,也可以帮助我们实现类似文件目录的逐级对象列表功能,提供给有特殊场景需求的用户参考。

对象清单分解成传输任务

有了存储桶中所有的对象清单,接下来,我们就看看如何设计传输任务。设计传输任务的原则如下:

  • 如果网络条件非常良好,比如同区域的不同存储桶之间,按照作者的测试,复制带宽平均可以达到xxMB/s,如此可以直接利用S3 cp命令
  • 尽可能将单进程的复制任务分解成多个子任务并发执行,任务分解后进入到Amazon SQS队列,这样将任务分解和任务执行进行解耦
  • 如果网络条件非常一般,比如平均在10KB/s并且网络抖动大的情况下,对于超过一定大小的文件需要切割成小文件,组成子任务并发执行

传输任务分解算法的设计,涉及到几个关键参数:

  • max_task_size_mb:单个任务的对象总大小上限,比如最大大小限制在100MB,那么单个任务最多有100MB的对象列表,或者该任务就一个对象,该对象本身大小就超过了100MB
  • max_task_objects:单个任务的对象数量上限,比如数量上限为50,那么单个任务中最多有50个对象需要传输
  • multipart_threshold及multipart_chunksize:对象太大时,需要分割成多个小对象传输任务,那么多大的对象需要进行分解?分段的单位大小是多少?比如阈值是10MB,单位大小是2MB,那么大于10MB的对象都需要再分解成2MB的多个子对象并发续传

Amazon SQS任务队列设计与实现

传输任务在设计时分成两大类,一种是本身对象就是小文件,我们按照max_task_size_mb 和 max_task_objects 进行分组,即每个任务总数据量大小不会超过max_task_size_mb,而且对象数量也不超过 max_task_objects ;这些任务我们会发送到自动创建的S3Task_NormalQueue开头的SQS队列中,每个队列的消息数量上限本文设为80000条;另外一类是,对象大小超过multipart_threshold 限制的,我们会进一步把该对象分解成 multipart_chunksize大小的独立对象,同样按照 max_task_size_mb 和 max_task_objects 的算法进行分组,但这些任务会保存到自动创建的以S3Task_BigSizeQueue开头的队列中。

另外遵循Amazon SQS操作的最佳实践,我们分别为这两类任务队列设定了同样的死信队列,当消息被读取10次而没被处理成功的会自动转移到S3Task_DeadQueue进行存储和后续处理。

执行数据传输任务

当任务队列产生之后,接下来,就到了如何高效执行如何多的传输任务的阶段,很多网络和客观条件的限制,我们都放到了如何分解传输任务的算法里面进行了实现,在执行数据传输任务环节,逻辑非常简单:

  • 读取一条SQS任务
  • 根据任务中的具体对象,每个对象利用独立线程进行复制或者下载再上传
  • 只有该任务中所有的对象都传输成功,才把该任务消息从SQS队列中删除

同区域S3数据复制

同区域不同S3存储桶之间数据复制,由于网络条件较好,IAM权限简单,可以尽量利用boto3的copy-object方法直接利用S3服务本身能力,进行快速数据复制,该方法数据无需经过命令执行的机器中转。因此在任务分解环节,multipart_threshold 的值需要设置一个比较大而且合理的值,避免大文件被分片之后,需要先下载后上传,这样会消耗更多的流量。

AWS海外不同区域S3数据复制

海外不同区域的S3存储桶之间复制,和同区域的不同存储桶复制场景类似,但由于跨区域传输,网络状况取决于两个区域的位置及它们之间的互联网状况。

AWS海外区域和BJS区域S3数据复制

该情况最复杂,AWS海外和国内是独立的区域,需要不同的账号权限体系,因此,对象需要先进行下载再上传,这样就需要占用执行命令的机器的内存和网络带宽;

  • 在任务分解时,需要尽量把大对象分解成小的片段比如2MB或者1MB的大小以提高单次数据传输的成功率。
  • 在任务执行时,需要尽量并发,以单任务小带宽累积成可以接受的总体平均传输速度,并充分AWS出口带宽的优势

数据跨区域迁移实践

基于我们之前的架构设计,那我们分阶段来具体动手实践一个具体场景, Amazon官网有很多公开的数据集,我们选定Next Generation Weather Radar (NEXRAD) 作为数据源,该数据源在美东(us-east-1)区域;目标存储桶我们选择在BJS区域。该实验仅仅为了验证技术可行性,完整的参考代码见s3deepdive github;代码不作为生产用途仅仅用来学习用途。

准备环境

为了简单地完成技术验证,我们所有的测试环境基于一台r4.2xlarge的Amazon Linux机型展开,系统需要准备好:

  • 在AWS Global 美东区域创建一台EC2实例
  • 关联一个IAM Role,需要有访问S3及SQS相关的管理权限
  • Python2.7.x
  • Boto3
  • 300GB gp2 EBS 磁盘

配置好目标存储桶的IAM Profile及修改默认获取IAM Role的临时Token的默认超时时间和重试次数:

[ec2-user@youserver]$ aws configure --profile bjs
AWS Access Key ID [None]: AKI***************A
AWS Secret Access Key [None]: 7j+R6*****************oDrqU
Default region name [None]: cn-north-1
Default output format [None]:
[ec2-user@youserver]$ vi ~/.aws/configure
[default]
region = us-east-1
metadata_service_timeout = 5
metadata_service_num_attempts = 5
[profile bjs]
region = cn-north-1
metadata_service_timeout = 5
metadata_service_num_attempts = 5

生成对象清单

Amazon公共数据集没有提供清单列表,因此,我们利用前文的逻辑,并尝试利用AWS S3 CLI命令生成该存储桶的对象清单。该数据集按照年月进行数据分区,我们设定对象的Prefix的迭代深度为3,后台执行以下命令,并观察执行日志:

[ec2-user@youserver]$ cd NEXRAD_Demo/inventory
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_inventory.py -b noaa-nexrad-level2 -r us-east-1 -d 3 > noaa-nexrad-level2.log 2>&1 & 

由于数据集非常大,该命令执行需要点时间,最终,3层的扫描帮助我们并发生成了2751个对象清单文件,总大小4.5GB:

[ec2-user@youserver]$ cd NEXRAD_Demo/inventory
[ec2-user@youserver]$ ls noaa-nexrad-level2.*obj* | wc –l
2751

设计并提交传输任务

由于该场景下,源存储桶和目标存储桶之间的单次传输的速度非常有限,实测该场景下大概在9KB/s左右,而且网络抖动比较厉害,因此,我们尽量缩小单个任务的总数据量大小,并设定大对象的大小阈值设置为2MB;具体参数需要在Python常量参数中修改:

由于清单文件太多,总数据量太大,因此,我们可以数据清单分成多个目录,分别进行计算,比如如下命令:

  • 我们把大小小于800000 bytes的文件放到目录./1/里面
  • 把大小小于2MB的文件放到./2/里面
  • 把大小小于6MB的文件放到./3/里面

大家可以根据自己的需要,分成不同的对象清单文件夹

[ec2-user@youserver]$ cd NEXRAD_Demo/inventory
[ec2-user@youserver]$ mkdir 1 2
[ec2-user@youserver]$ find ./ -size -800000c -print0 | xargs -0 -I {} mv {} ../1/
[ec2-user@youserver]$ find ./ -size -2M -print0 | xargs -0 -I {} mv {} ../2/
[ec2-user@youserver]$ find ./ -size -6M -print0 | xargs -0 -I {} mv {} ../3/
[ec2-user@youserver]$ cd NEXRAD_Demo/tasksubmit
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_task_submit.py -d ../inventory/1/ -r us-east-1 > noaa-nexrad-level2.task1.log 2>&1 &
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_task_submit.py -d ../inventory/2/ -r us-east-1 > noaa-nexrad-level2.task2.log 2>&1 &
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_task_submit.py -d ../inventory/3/ -r us-east-1 > noaa-nexrad-level2.task3.log 2>&1 &

为了演示,我们没有生成所有对象清单的传输任务,仅仅选取了其中某连个文件夹,生成的传输任务如下图所示,有些队列的消息数为0,表示我们后台还有传输任务消息没有发送到队列中:

我们来看看队列里面的一个任务的结构组成,S3Task_Bigsize*队列中的任务相比于普通队列中的任务多了一组分片的Range范围:

设计并执行传输任务

在并发执行数据传输任务之前,我们先看看单个任务执行情况,任务执行需要指明任务队列,源和目的存储桶以及访问目标存储桶的IAM Profile名:

[ec2-user@youserver]$ cd NEXRAD_Demo/taskexec
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_task_exec.py -q S3Task_NormalQueue15098144850121 -source_bucket noaa-nexrad-level2 -dest_bucket bjsdest -dest_profile bjs > S3Task_NormalQueue15098144850121.exec1.log 2>&1 &
[ec2-user@youserver]$ nohup python ../../s3deepdive/s3_task_exec.py -q S3Task_BigSizeQueue1 -source_bucket noaa-nexrad-level2 -dest_bucket bjsdest -dest_profile bjs > S3Task_BigSizeQueue1.exec1.log 2>&1 & 

从执行日志可以分析出,对于NormalQueue中的单个任务,由于是小对象,而且数量是10,因此我们的执行代码可以并发执行,总体执行时间是26秒;对比BigsizeQueue中的任务,虽然总体数据大小和NormalQueue差不多,但由于只有2个对象并发复制,该任务的总体执行时间是363秒。

关于并发任务执行,本质上是一个批处理的业务逻辑,假定有1000个任务列表,

  • 每个任务数据量上限20MB,如果传输速度在10KB/s那么一个任务需要大概需要2048秒即34分钟,但我们的的任务执行是多线程并发操作,按每个任务最多10个对象算,在10KB/s的速度下,一个任务最快需要执行3.4分钟左右(10个对象并发上传),最慢34分钟(一个对象的情况下)
  • 如果同时100个并发执行,完成所有任务,需要至少执行10次,总时长在34分钟到340分钟之间
  • 如果并发1000个,完成所有任务需要至少执行1次;总时长3.4分钟到34分钟之间

本实验为了学习的目的,我们在测试机r4.2xlarge的机器上,后台并发执行100个任务,并观察数据传输的实际状况,

[ec2-user@youserver]$ cd NEXRAD_Demo/taskexec
[ec2-user@youserver]$ vi parallel_run.sh
#!/bin/bash

for((i=2; i<52;i++))

do

  nohup python ../../s3deepdive/s3_task_exec.py -q S3Task_BigSizeQueue1 -source_bucket noaa-nexrad-level2 -dest_bucket bjsdest -dest_profile bjs > S3Task_BigSizeQueue1.exec_$i.log 2>&1 &

done

for((i=2; i<52;i++))

do

  nohup python ../../s3deepdive/s3_task_exec.py -q S3Task_NormalQueue15098144850121 -source_bucket noaa-nexrad-level2 -dest_bucket bjsdest -dest_profile bjs > S3Task_NormalQueue15098144850121.exec_$i.log 2>&1 &

done
[ec2-user@youserver]$ chmod +x parallel_run.sh
[ec2-user@youserver]$ ./parallel_run.sh

针对下面这两个队列,每个运行了50个并发任务,因此在SQS界面上,可以看到传输中的消息是50,也就是同时有50个消息任务正在被处理:

可以看到BigsizeQueue队列一次就成功完成的数据传输任务总数为 79949+50-79971=28;NormalQueue队列一次就成功完成的数据传输任务总数为79950+50-79958=42;我们定义任务的成功与否,为该任务中所有的对象都成功传输完成;该实验我们对于分段采取的大小是2MB,在9KB/s左右的互联网传输速度下,还是有点大,容易失败;普通队列上中的任务,对象大小都在几百KB左右,一次传输成功的概率大很多。

数据完整性检查

本文不对单个对象的完整性问题展开探讨,对于用户首先最关心的问题是,源存储桶的对象有没有完全迁移到目前存储桶中;因此,可以定期生成目标存储桶的对象清单,并比对源存储桶的对象清单,在自定义的清单程序中,我们是逐级生产对象清单文件,有一定的规律,如果两个存储桶使用同样的depth参数生成,生成的对象清单文件个数首先一致的;具体到识别出有没有遗漏的迁移对象,可以进一步对比清单中的对象列表。

总结

本文就跨区域S3数据迁移整体架构作了基本探讨,并在架构的基础上,学习和实践了利用AWS S3 CLI以及boto3库如何实现自定义的对象清单,传输任务分解及执行逻辑。现实的生产场景下,还需要更多细节的思考和实践,接下来,我们会继续在大规模批处理,大规模对象集的完整性校验方面和大家继续探讨。

 

作者介绍:

薛军

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

如何使用Amazon EC2 Systems Manager自动创建数据一致的EBS快照(Part 2)

作者:王宇

上一期我们讨论了如何在不关机的前提下实现AWS上实例的数据一致性快照问题,传送门:《如何使用Amazon EC2 Systems Manager自动创建数据一致的EBS快照(Part 1)

在本文的介绍中,我们将共同探索如何利用Amazon EC2 Systems Manager(SSM)和Microsoft VSS (Volume Shadow Copy Service)来创建数据一致的EBS快照。

SSM + VSS数据一致快照的原理

VSS (Volume Shadow Copy Service)是一个Windows操作系统内置的服务,用来协调与VSS兼容的应用程序(如SQL Server、Exchange Server等)的备份工作,如冻结或释放这些应用程序的I/O操作等。

VSS服务能够启动和监督副本拷贝的创建。“副本拷贝”是指一个逻辑卷在某一个时间点上的数据一致快照。比如:“C:”是一个逻辑卷,它与EBS快照不同。创建副本拷贝的步骤包括:

  • 请求方向VSS发出创建副本拷贝的请求。
  • VSS provider创建并维护副本拷贝。
  • VSS写入器(writer)保证数据的一致性。写入器负责在VSS provider创建副本拷贝之前固化临时数据并冻结I/O操作,并在VSS provider完成创建后释放I/O操作。通常情况下,会为每一个与VSS兼容的应用程序分配一个独立的写入器(writer)。

我们可以使用Run Command在windows实例中运行一个PowerShell脚本:

$EbsSnapshotPsFileName = "C:/tmp/ebsSnapshot.ps1"

$EbsSnapshotPs = New-Item -Type File $EbsSnapshotPsFileName -Force

Add-Content $EbsSnapshotPs '$InstanceID = Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/instance-id'

Add-Content $EbsSnapshotPs '$AZ = Invoke-RestMethod -Uri http://169.254.169.254/latest/meta-data/placement/availability-zone'

Add-Content $EbsSnapshotPs '$Region = $AZ.Substring(0, $AZ.Length-1)'

Add-Content $EbsSnapshotPs '$Volumes = ((Get-EC2InstanceAttribute -Region $Region -Instance "$InstanceId" -Attribute blockDeviceMapping).BlockDeviceMappings.Ebs |? {$_.Status -eq "attached"}).VolumeId'

Add-Content $EbsSnapshotPs '$Volumes | New-EC2Snapshot -Region $Region -Description " Consistent snapshot of a Windows instance with VSS" -Force'

Add-Content $EbsSnapshotPs 'Exit $LastExitCode'

首先创建了一个名为“ebsSnapshot.ps1”的PowerShell脚本文件,脚本中为实例的每一个EBS卷创建一个快照。

$EbsSnapshotCmdFileName = "C:/tmp/ebsSnapshot.cmd"

$EbsSnapshotCmd = New-Item -Type File $EbsSnapshotCmdFileName -Force

Add-Content $EbsSnapshotCmd 'powershell.exe -ExecutionPolicy Bypass -file $EbsSnapshotPsFileName'

Add-Content $EbsSnapshotCmd 'exit $?'

再创建第二个名为“ebsSnapshot.cmd”脚本文件,用来执行之前创建的PowerShell脚本。

$VssScriptFileName = "C:/tmp/scriptVss.txt"

$VssScript = New-Item -Type File $VssScriptFileName -Force

Add-Content $VssScript 'reset'

Add-Content $VssScript 'set context persistent'

Add-Content $VssScript 'set option differential'

Add-Content $VssScript 'begin backup'

$Drives = Get-WmiObject -Class Win32_LogicalDisk |? {$_.VolumeName -notmatch "Temporary" -and $_.DriveType -eq "3"} | Select-Object DeviceID

$Drives | ForEach-Object { Add-Content $VssScript $('add volume ' + $_.DeviceID + ' alias Volume' + $_.DeviceID.Substring(0, 1)) }

Add-Content $VssScript 'create'

Add-Content $VssScript "exec $EbsSnapshotCmdFileName"

Add-Content $VssScript 'end backup'

$Drives | ForEach-Object { Add-Content $VssScript $('delete shadows id %Volume' + $_.DeviceID.Substring(0, 1) + '%') }

Add-Content $VssScript 'exit'

第三个名为“scriptVss.txt”的文件包含了DiskShadow命令。DiskShadow是一个包含在Windows Server 2008及以上版本中的VSS工具。这个脚本在EBS上为每一个逻辑卷创建一个副本拷贝,再为这个EBS创建一个快照,最后删除副本拷贝来释放磁盘空间。

diskshadow.exe /s $VssScriptFileName
Exit $LastExitCode

最终,在脚本模式中来运行DiskShadow命令。

这个脚本将保存在一个新的SSM Document中并关联到一个维护窗口中,在每天的午夜时间在每一台标签“consistentsnapshot”等于“windowsvss”的实例上运行。

在AWS console中快速实践

1.  使用AWS CloudFormation快速创建一组资源,包括:

a)   VPC和互联网网关

b)   VPC中创建一个子网和一个新的路由表,来实现互联网连接和AWS APIs

c)   创建一个IAM角色来赋予EC2实例相应的权限

d)   创建一个安全组,来允许来自internet的RDP访问,稍后将要通过远程登录到这个EC2实例中

e)   在子网中使用IAM角色创建和启动一个Windows实例,并分配好安全组

f)   创建一个包含上面例子中脚本的SSM document文件,来创建数据一致EBS快照

g)   创建另一个SSM document文件,其中的脚本来恢复逻辑卷中的数据,这些脚本将在下面的章节中详细说明

h)   创建一个能够生成Maintenance Windows的IAM role

2.  创建一个Maintenance Window

a)   在EC2 Console中选择:Systems Manager Shared Resources -> Maintenance Windows -> Create a Maintenance Window

b)   Name:ConsistentSnapshots

c)   Specify with:CRON/Rate expression

d)   CRON/Rate expression:cron(0 0 * * ? *)

e)   Duration:2 hours

f)   Stop initiating tasks:0 hour

g)   选择Create maintenance window

3.  为Maintenance Window关联一组目标:

a)   在Maintenance Window列表中选择刚刚创建的维护窗口

b)   在Actions中选择Register targets

c)   Owner information:WindowsVSS

d)   Select targets by:Specifying tags

e)   Tag Name:ConsistentSnapshot

f)   Tag Value:WindowsVSS

g)   选择Register targets

4.  给Maintenance Window分配一个任务

a)   在Maintenance Window列表中选择刚刚创建的维护窗口

b)   在Actions中选择Register targets

c)   在Document中选择此前创建的用于创建EBS快照的SSM document文件名

d)   在Target by中选择刚刚创建的目标

e)   在Role中,选择在CloudFormation中创建的IAM Role

f)   在Execute on中,Targets:1,Stop after:1 errors

g)   选择Register task

运维窗口和一致性快照操作已经创建完毕,你可以在Maintenance Windows窗口中的History页面查看每一次任务的执行情况。

如何将逻辑卷恢复到数据一致状态

在本文上面的例子中,我们会注意到,在给EBS进行快照的脚本中,我们实际上是先使用DiskShadow进行了副本拷贝操作,这个操作中已经包含了对I/O操作的冻结和释放,在此之后再进行了EBS的快照操作。而在这两个操作之间的瞬间如果数据发生改变,那么EBS快照中的数据就可能不能保持数据一致状态。

解决这个问题有两个方向,其一是自己创建一个VSS provider来创建EBS快照,而不是使用DiskShadow采用的windows内置的VSS provider来执行,在自己创建的VSS provider中做到先创建EBS快照再释放I/O操作,来保持数据一致性。

本文会介绍另一个解决方向,就是检查在EBS快照中的每一个逻辑卷数据,如果发现数据不一致的情况,就将其恢复到此前的副本拷贝(副本拷贝中的数据被VSS writer保持了数据一致性)。

步骤如下:

1.  在EC2 console中,选择Instances

2.  搜索获得EBS进行了快照的实例,注意这个实例所在的AZ

3.  选择Snapshots

4.  选择最新的快照,再选择Actions,Create Volume

5.  选择与此前相同的AZ,然后选择Create, Volumes

6.  选择刚刚创建的Volume,然后选择Actions, Attach Volume

7.  在Instances中选择进行了EBS快照的实例,然后选择Attach

8.  选择Run Command, Run a command

9.  在Command document中选择恢复EBS的脚本Document,在Target中选择这个Windows实例,然后选择Run

恢复EBS的脚本如下:

$OfflineDisks = (Get-Disk |? {$_.OperationalStatus -eq "Offline"})

foreach ($OfflineDisk in $OfflineDisks) {

  Set-Disk -Number $OfflineDisk.Number -IsOffline $False

  Set-Disk -Number $OfflineDisk.Number -IsReadonly $False

  Write-Host "Disk " $OfflineDisk.Signature " is now online"

}

$ShadowCopyIds = (Get-CimInstance Win32_ShadowCopy).Id

Write-Host "Number of shadow copies found: " $ShadowCopyIds.Count

foreach ($ShadowCopyId in $ShadowCopyIds) {

  "revert " + $ShadowCopyId | diskshadow

}

foreach ($OfflineDisk in $OfflineDisks) {

  $CurrentSignature = (Get-Disk -Number $OfflineDisk.Number).Signature

  if ($OfflineDisk.Signature -eq $CurrentSignature) {

    Set-Disk -Number $OfflineDisk.Number -IsReadonly $True

    Set-Disk -Number $OfflineDisk.Number -IsOffline $True

    Write-Host "Disk " $OfflineDisk.Number " is now offline"

  }

  else {

    Set-Disk -Number $OfflineDisk.Number -Signature $OfflineDisk.Signature

    Write-Host "Reverting to the initial disk signature: " $OfflineDisk.Signature

  }

}

通过比较,将数据不一致的逻辑卷恢复到了数据一致状态,这个EBS就回到了数据一致的状态。

本次的介绍就到这里。如对AWS混合云架构解决方案感兴趣,请联系我们:yuwangcn@amazon.com

 

作者介绍:

王宇,AWS企业容灾解决方案业务拓展经理,目前负责AWS中国区的混合云、容灾和DevOps产品和解决方案。曾服务于VMware等传统私有云厂商,熟悉传统IT架构和私有云、混合云、公有云的解决方案融合。

利用 Amazon CloudWatch 监控 GPU 利用率

深度学习需要进行大量的矩阵相乘和向量运算,而 GPU (图形处理单元) 可以并行处理这些运算,因为 GPU 拥有数以千计的核心。Amazon Web Services 为您提供的 P2 或 P3 实例非常适用于运行深度学习框架,如 MXNet,该框架强调加速部署大型深度神经网络。

数据科学家和开发人员在微调网络时,希望优化其 GPU 的利用率,以使用最适当的批处理大小。在这篇博文中,我将向您展示如何使用 Amazon CloudWatch 指标监控 GPU 和内存的使用情况。至于 Amazon 系统映像 (AMI),我们建议您的实例使用 Amazon Deep Learning AMI

要监控和管理已启用 GPU 的实例,目前常见的有益做法是使用 NVIDIA 系统管理接口 (nvidia-smi),这是一个命令行实用程序。用户可以利用 nvidia-smi 查询 NVIDIA GPU 设备的 GPU 利用率、内存消耗情况、风扇使用情况、功耗以及温度信息。

由于 nvidia-smi 的基础是 NVIDIA Management Library (NVML),所以我们可以使用这个基于 C 的 API 库捕捉相同的数据点,并作为自定义指标发送给 Amazon CloudWatch。如需了解有关此库的更多信息,请转至参考手册。在这篇博文中,我们将使用此库的 Python 包装程序 pyvnml

Amazon CloudWatch 可以非常出色地监控您在 EC2 实例上的工作负载,无需设置、管理,也无需为它扩展系统和基础设施。默认情况下 CloudWatch 可提供 CPU 利用率、磁盘读取操作、磁盘写入操作、网络输入和网络输出等指标。(点击此处了解适用于您的实例的完整指标列表)

除了提供这些指标,我们还能够使用 API、软件开发工具包或 CLI 通过 Amazon CloudWatch 自定义指标推送我们自己的数据点。我们将使用 Python Boto3 软件开发工具包。

(more…)

不要错过:了解 AWS 的一些最新发布

如此多的发布和云创新,正在以令人难以置信的速度接踵而来。这篇迟来的博文会概要介绍今年夏天直到九月底发布的一些非常棒的服务和功能。

今天我希望与您分享的发布和功能有:

  • 对 RDS MySQL 和 Amazon Aurora 的数据库用户使用 AWS IAM 进行身份验证
  • Amazon SES 声誉控制面板
  • Amazon SES 打开和单击跟踪指标
  • 解决方案构建器团队推出的无服务器映像处理程序
  • 解决方案构建器团队推出的 AWS Ops Automator

现在就让我们来深入了解一下吧!

对 RDS MySQL 和 Amazon Aurora 的数据库用户使用 AWS IAM 进行身份验证

您是否一直希望能够使用 AWS IAM 管理对 Amazon RDS 数据库实例和集群的访问权限?现在您的梦想成真了。Amazon RDS 已发布了这个功能,您可以使用 IAM 管理对 Amazon RDS for MySQL 和 Amazon Aurora 数据库的访问权限。

对于这个全新服务功能,最令我欣喜的是它非常容易上手。要使用 IAM 对数据库用户进行身份验证,您需要在创建、修改或还原您的数据库实例或集群时选择启用 IAM 数据库身份验证复选框。您可以使用 RDS 控制台、AWS CLI 和/或 Amazon RDS API 启用 IAM 访问。

对数据库进行 IAM 身份验证配置后,客户端应用程序可提供由 IAM 安全令牌服务生成的临时安全凭证,从而对数据库引擎进行身份验证。可以使用这些凭证代替向数据库引擎提供密码。

您可以查看 Amazon RDS 用户指南,进一步了解如何使用 IAM 针对 MySQL 和 Aurora 提供权限并进行身份验证。

Amazon SES 声誉控制面板

我非常激动地宣布,我们发布的声誉控制面板可以针对电子邮件发送情况提供综合报告,从而帮助 Amazon Simple Email Service 客户更好地利用发送电子邮件的最佳实践指南。该控制面板有助于主动管理所发送的电子邮件,使得客户能够全面掌握账户的运行状况、发送指标、合规性以及执行状态。

声誉控制面板将提供以下信息:

  • 账户状态:账户运行状态的说明。
    • 正常 – 目前没有影响账户的问题。
    • 试用 – 账户处于试用状态;必须解决导致账户处于试用状态的问题,才能避免账户暂停
    • 试用结束决策待处理 – 您的账户处于试用状态。在采取行动前,Amazon SES 团队成员必须检查您的账户。
    • 关闭 – 您的账户已关闭。无法使用 Amazon SES 发送电子邮件。
    • 关闭待处理 – 您的账户处于试用状态;导致账户处于试用状态的问题未解决。
  • 退回邮件率:被退回的已发送电子邮件百分比,以及退回邮件率状态消息。
  • 投诉率:在已发送电子邮件中,收件人报告为垃圾邮件的百分比,以及投诉率状态消息。
  • 通知:与账户声誉相关的其他消息。

Amazon SES 打开和单击跟踪指标

Amazon SES 最近新增的另一项激动人心的功能是,支持电子邮件打开和单击跟踪指标。现在,SES 客户可以利用电子邮件打开和单击跟踪指标功能跟踪他们发送的电子邮件何时被打开,并跟踪电子邮件中的链接何时被单击。使用此 SES 功能,您可以更好地跟踪电子邮件营销活动的参与度及效果。

该功能的工作原理?

如果使用电子邮件打开跟踪功能,SES 会在您选择跟踪的电子邮件中添加一个微型透明图像。当这封电子邮件被打开后,邮件应用程序客户端会加载上述跟踪标记,从而触发 Amazon SES 的打开跟踪事件。对于电子邮件单击 (链接) 跟踪,电子邮件和/或电子邮件模板中的链接应替换为自定义链接。自定义链接被单击后,SES 中会记录一个单击事件,自定义链接会带电子邮件用户转到原始电子邮件中的链接目的地。

您可以在 SES 中新建配置集,或更改现有配置集,从而使用全新的打开跟踪和单击跟踪功能。您可以选择 Amazon SNSAmazon CloudWatchAmazon Kinesis Firehose 作为接收“打开和单击指标”的 AWS 服务,然后只需要选择一个新的配置集,就可以针对您要发送的任何电子邮件成功启用这些新功能。

AWS 解决方案:无服务器映像处理程序和 AWS Ops Automator

AWS 解决方案构建器团队一直在努力工作,帮助所有用户解决常见的体系架构问题,从而更轻松地在 AWS 上生成并运行应用程序。您可以在 AWS Answers 页面上找到这些解决方案。今年初秋在 AWS Answers 上发布的两种全新解决方案是无服务器映像处理程序AWS Ops Automator
开发无服务器映像处理程序是为了提供一种解决方案,以帮助客户动态地处理、操作并优化在 AWS 云中对映像的处理。这个解决方案结合了用作缓存的 Amazon CloudFront,动态检查映像及修改映像的 AWS Lambda,以及用于存储映像的 Amazon S3 存储桶。此外,无服务器映像处理程序还可利用开源映像处理套件 Thumbor 进行额外的映像操作、处理和优化。

AWS Ops Automator 解决方案可使用基于时间和基于事件的触发器帮助您将手动任务自动化,从而实现快照调度等任务的自动化。该解决方案可以提供自动化任务的架构,并包括任务审计跟踪、日志记录、资源选择、扩展、并发处理、任务完成处理以及 API 请求重试。该解决方案包括以下 AWS 服务:

  • AWS CloudFormation:一个模板,用于启动微服务核心框架,和由解决方案生成的任务配置
  • Amazon DynamoDB:存储任务配置数据的表,用于定义事件触发器、资源,并保存操作结果和错误。
  • Amazon CloudWatch Logs:提供日志,用于跟踪警告和错误消息
  • Amazon SNS:向订阅电子邮件地址发送消息的主题,解决方案会向该地址发送日志记录信息

祝您探索和编程愉快。

Tara

全新 – AWS Direct Connect 网关 – 跨区域 VPC 访问

准备写这篇文章时,我回顾了一下 2012 年当我们推出 AWS Direct Connect 时我写过的博客文章。应企业客户的要求,我们创建了 Direct Connect 让他们建立到 AWS 区域的专用连接,以追求更高的私密性、更多数据传输带宽和更易预测的数据传输性能。从开始时的一个 AWS 区域、一个 colo,Direct Connect 现在遍布每个公有 AWS 区域,并且可从分散在全球各地的数十个 colo 进行访问 (上次统计超过 60 个位置)。我们的客户现已全心投入于 Direct Connect,我们也添加了一些功能,例如 链接聚合Amazon EFS 支持CloudWatch 监控HIPAA 资格。仅在过去五周内,我们就已在休斯顿 (德克萨斯州)、温哥华 (加拿大)、曼彻斯特 (英国)、堪培拉 (澳大利亚) 和 珀斯 (澳大利亚) 增加了 Direct Connect 位置。

如今,我们通过增加 Direct Connect 网关让 Direct Connect 变得更简单但更强大。我们还在为所有区域中的 Direct Connect 客户提供创建公有虚拟接口的能力,公有虚拟接口可以接收我们的全局 IP 路由,并且可以访问我们的服务的公有终端节点和更新 Direct Connect 定价模型。

下面我们来了解一下上述每项功能。

新的 Direct Connect 网关
您可以用新的 Direct Connect 网关跨越分布在多个 AWS 区域的 Virtual Private Cloud (VPC) 建立连接,而不再需要为每个 VPC 建立多个 BGP 会话,从而减少了您的管理工作负担和网络设备负载。

使用此功能,您还可以从任意 Direct Connect 位置连接到参与连接的任何 VPC,进一步降低跨区域使用 AWS 服务所产生的成本。

下图显示了借助 Direct Connect 网关 (每个“锁”图标表示一个虚拟专用网关) 可以实现的简化。简化前:

简化后:

引用特定 Direct Connect 网关的 VPC 的 IP 地址范围一定不能重叠。现在,这些 VPC 必须全在同一 AWS 账户中;我们计划以后提高此要求的灵活性。

每个网关都是一个跨所有公有 AWS 区域存在的全局对象。区域间通过网关进行的所有通信都跨 AWS 骨干网进行。

创建 Direct Connect 网关
您可以通过以下方式创建 Direct Connect 网关:使用 Direct Connect 控制台或通过从代码中调用 CreateDirectConnectGateway 函数。我要使用控制台!

首先,我打开 Direct Connect 控制台并单击 Direct Connect Gateways

列表是空的,因为现在还没有网关。我单击 Create Direct Connect Gateway 改变这一状况:

为网关指定一个名称,输入我的网络的私有 ASN,然后单击 Create。ASN (自治系统编号) 必须位于在 RFC 6996 中定义为私有的某个范围内:

我的新网关稍后会显示在其他 AWS 区域中:

我在俄亥俄州有一个 Direct Connect 连接,我将用它来创建 VIF:

现在我创建一个私有 VIF,它引用该网关和连接:

几秒后就可以用了:

我已经有了一对 CIDR 不重叠的 VPC,每个还挂载了一个虚拟专用网关。这些是 VPC (为方便演示,我会将它们显示在同一区域中):

下面是虚拟专用网关:

我返回 Direct Connect 控制台并导航到 Direct Connect Gateways。选择我的网关,然后从 Actions 菜单中选择 Associate Virtual Private Gateway

然后选择我的两个虚拟专用网关并单击 Associate

如果我的 VPC 在不同的 AWS 区域中 (通常如此),同样的过程适用。在本篇文章中,向您演示一次操作就够了。

虚拟网关关联大约在一分钟左右完成 (状态开始为 associating):

当状态变为 associated 时,您的本地网络和 VPC 之间就可以通过 AWS Direct Connect 连接通信了,无论 VPC 在哪个 AWS 区域。

用于服务终端节点的公有虚拟接口
现在您可以创建公有虚拟接口,这些接口允许您通过 Direct Connect 访问在任意 AWS 区域 (AWS 中国区域除外) 运行的 AWS 服务的 AWS 公有服务终端节点。这些接口 (通过 BGP) 接收 Amazon 的全局 IP 路由。您可以在 Direct Connect 控制台中创建这些接口,第一步是选择 Public 选项:

更新定价模型
鉴于 AWS 区域和 AWS Direct Connect 位置的不断增加,数据传输现在基于 Direct Connect 和源 AWS 区域的位置进行定价。与基于 AWS Direct Connect 位置的旧模型相比,新定价模型更为简单。

现在提供
这一新功能现已推出,您可以立即开始使用。您可以免费创建和使用 Direct Connect 网关;只需根据端口小时和数据传输支付日常 Direct Connect 价格

Jeff

Apache MXNet 版本添加了对新的 NVIDIA Volta GPU 和 Sparse Tensor 的支持

我们对 Apache MXNet 版本 0.12 的发布感到很兴奋。MXNet 社区的参与者密切合作,为用户带来了新的增强功能。在此版本中,MXNet 添加了两项新的重要功能:

  • 对 NVIDIA Volta GPU 的支持,这使用户能够大大减少神经网络模型的训练和推理时间。
  • 对 Sparse Tensor 的支持,这使用户能够以最有利于存储和计算的方式使用稀疏矩阵训练模型。

对 NVIDIA Volta GPU 架构的支持

MXNet v0.12 版本添加了对 NVIDIA Volta V100 GPU 的支持,这使客户训练卷积神经网络的速度比 Pascal GPU 的速度快 3.5 倍。训练神经网络涉及数万亿次的浮点数 (FP) 乘法与加法运算。这些计算通常已使用单精度 (FP32) 完成以实现较高的准确度。但是,最近的研究表明,用户可以通过使用半精度 (FP16) 数据类型的训练获得与使用 FP32 数据类型的训练相同的准确度。

Volta GPU 架构引入了 Tensor Core。每个 Tensor Core 每个时钟周期可执行 64 次乘法和加法混合运算,约为每个 CUDA 核心在每个时钟周期内执行的 FLOPS 的四倍。每个 Tensor Core 执行如下所示的运算:D = A x B + C,其中 A 和 B 是半精度矩阵,而 C 和 D 可以是半精度或单精度矩阵,从而执行混合精度训练。利用新的混合精度训练,用户可以通过对网络的大多数层使用 FP16 并在必要时使用更高精度的数据类型来获得最佳训练绩效,且不会降低精度。

MXNet 使用户能够轻松使用 FP16 训练模型以利用 Volta Tensor Core。例如,您只需在 MXNet 中通过将以下命令选项传递到 train_imagenet.py 脚本即可启用 FP16 训练。

--dtype float16

最近,我们宣布推出一套新的 AWS Deep Learning AMI,它们预安装了针对 Amazon EC2 P3 实例系列中的 NVIDIA Volta V100 GPU 进行了优化的各种深度学习框架,其中包括 MXNet v0.12。只需在 AWS Marketplace 中单击一下鼠标即可开始;或者,您也可以按照此分步指南操作,开始使用您的第一个笔记本

(more…)

混合云架构顿悟时刻

每周,我都会与好几个高管会面,他们正在使用云改变技术为其业务带来价值的方式。开始使用云的动机各不相同,但在我的谈话中,一个始终如一的主题是云可让组织将更多的资源投放在其核心业务上、更快地移动且更安全。

这种转变不会在一夜之间发生,我经常将这个过程称为旅程。在此期间,您的企业仍然需要运营现有 IT 资产以保持业务正常运行。虽然我提及的大多数企业都正在将其 IT 项目组合中的部分或全部项目迁移到云,但他们也意识到,云并不是一个“全有或全无”的价值主张。当每个企业都意识到这一点时,他们就能够将其本地 IT 资产与云联系起来,并利用这种联系逐渐将其 IT 项目组合的重心迁移到云。

去年,我写了有关云中的混合架构的三个神话的文章,时至今日,我在与高管讨论混合云架构时仍会遇到这些问题。如果您仍在梳理有关您的组织的混合云架构的观点,我建议您考虑一下我在那篇文章中提到的要点。

这篇文章的其余内容详述了当我担任 Dow Jones 的首席信息官以及我们首次实现混合云架构时,我的团队和我的“顿悟”时刻。

混合顿悟时刻

2012 年,我的老板 (随后成为了 Dow Jones 的首席执行官) 提出了一个假设,我们都认为这是一个巨大的商机:如果华尔街日报 (Dow Jones 旗舰 B2C 产品之一) 的所有订户拥有全球大部分财富,Factiva 和 Dow Jones Newswires (Dow Jones 的 B2B 产品) 的所有订户管理全球大部分财富,那么我们可以为他们提供一种用于相互联系和通信的机制来创建一个有价值的平台。

我们从零开始,并且想快速行动。我们组建了一个非常小的工程师和设计师团队来构建这个概念,让他们能够自由地选择他们认为可以完成这项工作的工具。6 周后,通过几个开源的自动化 AWS 服务以及大量的艰苦工作,我们便启动并运行了一个高可用性且不受灾难影响的应用程序。我们新发现的将技术交付给业务的能力很快成为了我们的“英雄”项目,并帮助我们鼓励我的团队和管理层利益相关者与我们一起踏上旅程。

随着我们将此应用程序集成到我们的更多产品中,我们发现还需要将它与我们的一些仅限内部使用的身份管理系统集成。这些系统中的一些系统不会 (也不应) 公开到 Internet 上,因此无法通过我们的在公共 Internet 中的 AWS 上运行的应用程序进行访问。

我们的网络、基础设施和开发团队的工程师已开始寻找解决这个问题的方法。经过一番研究,我们发现我们可利用 Amazon VPC 在我们内部的 IP 地址空间内创建一个虚拟网络并将我们的应用程序放入 VPC 中。

在阅读 AWS 文档并决定我们如何使用我们的内部防火墙规则管理 AWS 安全组的集成之后,团队便开始工作了。在 45 分钟内,他们创建了 VPC、为我们在公共 Internet 上运行的实例拍摄了快照,使实例出现在 VPC 中 (在其中为实例分配了内部子网中的 IP 地址)、将入站流量路由至新实例、实现了从实例到内部身份系统的连接并完成了迁移。

我们对于此过程如此简单感到惊讶,而让我们感到更惊讶的是,我们发现有机会通过在云中构建的系统来增强和扩展现有的旧系统。

在接下来的几年里,我们的开发运营团队 (也称为我们的云卓越中心) 通过实现 VPC 创建和监管的自动化,将我们从此练习中学到的知识编入到一些参考架构中以用于我们的各个业务方面。借助这个简单而强大的策略,我们使用此混合架构模型在云中构建和增强所有现有系统,而无需立即迁移所有系统。

从那时起,我已与拥有类似的“顿悟”时刻的高管进行了谈话。一旦他们意识到无需放弃所有现有的基础设施投资并且仍可利用云,就会产生大量的可能性。这使其团队有时间进行学习,安全实施现有投资/折旧计划,并且仍从云的弹性、敏捷性、安全性和成本特性中受益。

您在设置您的混合架构时是否有顿悟时刻?请一定告诉我!

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

注:实现混合架构是我在企业云之旅系列文章中撰写的第 6 个最佳实践 (共 7 个最佳实践)。其他 6 个最佳实践为:提供执行支持给您的员工培训创造试验文化吸引合作伙伴创建云卓越中心和实施云优先策略。请保持关注以了解有关每个最佳实践的更多信息,并查阅此处的电子书集合

 

向员工传授云知识时需要考虑的 11 个注意事项

告诉我,我会忘掉。教导我,我会记住。让我参与,我能掌握。- Benjamin Franklin

我在上一篇文章中提到,只要让员工接受适当的教育,您就拥有了充分发挥云技术优势所需的资源。

那么,您 (首席变更管理官) 该如何教育员工,以便他们能够加快您的云之旅?每个组织的云之旅都将是独一无二的,但根据我的观察,取得成功的组织还是有一些共通之处的。以下是有关这些共通之处的 11 个注意事项:

1. 从有意义但很基本的事情做起。

当您的团队完成对业务至关重要的事情后,他们会即刻明白云技术的实际优势。我见过有些公司将工作重点放在了无足轻重的小事上面,结果,他们取得的进展比预想的要慢。当然,您肯定不希望在头几个项目上冒太大的风险,但您需要从足够重要、能够展示业务收益的项目开始。这样的项目有很多 — 简单的网站、移动应用程序、简化数据访问的 API 或文件备份/灾难恢复改进项目。如果将团队教育扎根于实际应用之中,他们就能更快地将学到的知识应用于更多的项目。

2. 利用 AWS 培训

我在以前的文章中提到过 AWS 提供的几个很好的培训项目。这些项目帮助了成百上千家公司掌握了云技能。AWS 将每次培训合作都当成是改进的机会,开发了多样化的课程和各种授课机制,允许组织定制满足其特定需求的培训。我在道琼斯工作时,我们团队里的几乎每一位技术人员都接受过培训,这些培训内容后来汇总成了 AWS 技术基础知识课程。除了帮助我们的员工获得新技能以外,这些培训还打消了他们刚刚踏上云之旅时出现的莫名恐惧感。

3. 给团队一些时间进行试验。

营造试验文化是云之旅的下一条最佳实践,在激励员工学习时,这一点非常有用。创新来自于试验。借助云技术,您不必进行大量前期投资就能尝试各种新想法,这可帮助您的团队创造出颠覆性的行业产品。给您的团队一些自由度,让他们以新的方式实现现有项目。

4. 设定鼓励学习和试验的目标。

大多数公司会为员工设定目标和/或关键绩效指标,并将这些目标与绩效挂钩。这些现有机制是强化您的策略并产生您所期望的行为的良好途径。您可以围绕各种主题设置目标,例如:相关培训课程的完成度、释放了多少预算、采用适当的云架构后运营卓越性有多大改善等。这样做可以传递“领导层真心希望为每个人创造试验和学习机会”的信号。

5. 设定时间限制和前进步伐。

当您转向试验文化时,这一点尤为重要。毕竟,结果才是最重要的。您可以通过设定每个项目的截止日期来帮助团队成员在试验和运用其已学到的知识之间取得平衡。有时,您的团队可能会因为这些约束而作出妥协。随着云之旅进程的深入,您需要制定一个应对此类妥协的机制。但是,您的团队将一刻不停地学习和提高技能,以便为下一个项目做好准备。

6. 发现并消除变革阻力。

所有这些注意事项都旨在为员工提供帮助他们获得成功所需的工具,以减少员工对变革的抵制。但即使做好所有这一切,您的组织中还是会有人继续抵制变革。在阐明目的一文中,我对这一挑战作了说明。您需要理解团队的忧虑,心平气和地看待做得好和做得不好的地方,并迅速消除不必要的摩擦。这引出了我要讲述的下一个要点。

7. 不要害怕赋予员工新的角色。

以有意义的方式迁移到云不仅仅是技术转型,同样也是一场文化变革。我发现,给予员工担任新角色的机会可以帮助他们克服对变革的抵制。我一直偏向于首先检视公司内部,因为系统知识非常宝贵,通常是不必要的损失。在 Bloomberg 的 11 年任期里,我担任过六种差异极大的角色。拥有如此多的机会是我一直呆在 Bloomberg 的主要原因之一。寻找为员工提供新机会的方法可加强他们的参与感,有助于留住员工。

8. 向员工指明其在组织整体蓝图中的作用。

当您知道自己在组织大局中的作用时,很容易对自己的工作感到兴奋。请务必考虑到每一个角色,并传达其在团队中的重要作用。我再强调一下,了解组织如何将其目标与部门和/或个人目标协调一致,并找到一种方法来针对每个角色进行调整。

9. 参加行业活动,了解他人在做些什么。

大多数人可从他人的成功和失败经历中学到很多东西。到目前为止,我从事为大型公司制定云支持技术战略的工作已经五年多了。但令我惊讶的是,每次出席 AWS re:Invent、AWS 峰会及其他技术活动,我还是能学到不少的知识。请给您的员工一些时间,让他们梳理知识、了解新思想。了解各种各样的想法 (即使是您确定不会赞同的想法) 是创造教育机会和加强您的策略的良好途径。

10. 向您的合作伙伴学习。

AWS 合作伙伴网络中有成千上万家组织。您可能已经与其中的许多组织建立了稳定的合作伙伴关系,但总会有一些新的合作伙伴值得您学习。据我观察,有非常多的大型企业越来越倾向于与“在云中诞生”的小型、新创办的系统集成商 (如 Cloudreach2nd Watch  Minjar) 合作,以加快自身的云战略进程并革新其 IT 文化。

接下来是最后一个要点。

11. 在组织中建立适合自身的培训制度。

随着云迁移进程的逐步深入,您会发现组织中的一些团队或个人希望与他人分享自己学到的知识。理想情况下,这个组织会是您的云卓越中心 (这是云之旅的另一条最佳实践,稍后我会详细解释这一点)。我在道琼斯工作时,我们的 DevOps 团队会定期举办“DevOps Days”交流会,以便该团队与组织中的其他人分享其开发的云最佳实践、框架和管理模式。我曾与其他几家“财富 500 强”企业交流过,他们也都制定了适合自己组织的类似计划。

您认为还有什么需要补充的吗?请一定告诉我!

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