Category: Compute*


现已推出 – Amazon EC2 的计算密集型 C5 实例

我很高兴地宣布,新的计算密集型 C5 实例今天在三个 AWS 区域推出,有六种大小规格!

这些实例专用于计算密集型应用程序,例如批处理、分布式分析、高性能计算 (HPC)、广告服务、高度可扩展的多人游戏和视频编码。新实例提供了比 C4 实例高 25% 的价格/性能改进,对于某些工作负载可超过 50%。它们还有额外的每 vCPU 内存,而且 (对于可以利用新 AVX-512 指令的代码) 对于向量和浮点工作负载有两倍的性能。

多年来,我们一直在不停地工作,为客户提供可能的最佳网络、存储和计算性能,长期专注于将许多类型的工作分流到由 AWS 设计和建造的专用硬件上。C5 实例类型包含了我们的最新一代硬件分流,另外还在添加一个与我们的硬件密不可分地一起运行的新管理程序方面又迈出了一大步。新的管理程序允许我们让您访问主机硬件提供的所有处理能力,同时也使性能更加一致,并进一步提高了安全性的门槛。我们将在 AWS re:Invent 分享很多关于它的技术细节。

新实例
C5 实例有六种大小:

实例名称 vCPU
RAM
EBS 带宽 网络带宽
c5.large 2 4 GiB 最高 2.25 Gbps 最高 10 Gbps
c5.xlarge 4 8 GiB 最高 2.25 Gbps 最高 10 Gbps
c5.2xlarge 8 16 GiB 最高 2.25 Gbps 最高 10 Gbps
c5.4xlarge 16 32 GiB 2.25 Gbps 最高 10 Gbps
c5.9xlarge 36 72 GiB 4.5 Gbps 10 Gbps
c5.18xlarge 72 144 GiB 9 Gbps 25 Gbps

每个 vCPU 都是 3.0 GHz Intel Xeon Platinum 8000 系列处理器上的硬件超线程。此自定义处理器针对 EC2 进行了优化,能让您在两个最大大小上完全控制 C 状态,从而能让您使用 Intel 睿频加速技术以最高 3.5 GHz 的速度运行单个内核。

从表中可以看出,四个最小实例大小提供的 EBS 和网络带宽比前一代计算密集型实例大得多。

由于所有网络和存储功能都是在硬件中实现的,因此 C5 实例需要包括 Elastic Network Adapter (ENA) 和 NVMe 的驱动程序的 HVM AMI。最新的 Amazon Linux、Microsoft Windows、Ubuntu、RHEL、CentOS、SLES、Debian 和 FreeBSD AMI 都支持 C5 实例。如果您正在进行机器学习推理或其他计算密集型工作,请务必检查最新版本的 Intel Math Kernel Library。它已针对 Intel® Xeon® Platinum 处理器进行了优化,并有可能大大加快您的工作。

为了与使用 Xen 管理程序的实例保持兼容,EBS 卷的设备名称将继续使用现有的 /dev/sd/dev/xvd 前缀。不使用在将卷附加到实例时提供的设备名称,因为 NVMe 驱动程序会分配其自己的设备名称 (阅读 Amazon EBS 和 NVMe 以了解更多信息):

nvme 命令显示有关每个卷的其他信息 (如果需要,可使用 sudo yum -y install nvme-cli 安装它):

输出中的 SN 字段可以通过在“vol”前缀后面插入“-”映射到 EBS 卷 ID (可惜,NVMe SN 字段的长度不足以存储整个 ID)。下面是一个使用此信息创建每个附加卷的 EBS 快照的简单脚本:

$ sudo nvme list | \
  awk '/dev/ {print(gensub("vol", "vol-", 1, $2))}' | \
  xargs -n 1 aws ec2 create-snapshot --volume-id

只需多做一点工作 (以及大量的测试),您可以创建一个脚本来扩展将要变满的 EBS 卷。

到达 C5
正如我前面提到的,我们将工作分流到硬件加速器的工作已经进行了相当长一段时间。概括如下:

CC1 – 在 2010 年推出,CC1 专用于支持横向扩展的 HPC 应用程序。它是第一个支持 10 Gbps 网络的 EC2 实例,也是第一个支持 HVM 虚拟化的实例之一。我们为 CC1 设计的网络结构 (基于我们自己的交换机硬件) 已成为所有 AWS 数据中心的标准。

C3 – 在 2013 年推出,C3 引入了增强型联网,并使用专用硬件加速器来支持每个 Virtual Private Cloud (VPC) 内部的软件定义网络。硬件虚拟化从管理程序中删除 I/O 堆栈,从而有利于来宾操作系统进行直接访问,因此提高性能并减少可变性。

C4 – 在 2015 年推出,C4 实例是在默认情况下通过专用网络连接优化的 EBS,并且还将 EBS 处理 (包括加密 EBS 卷的 CPU 密集型加密操作) 分流到硬件加速器。

C5 – 今天推出,驱动 C5 实例的管理程序允许将主机 CPU 的所有资源几乎专用于客户实例。ENA 网络和与 EBS 连接的 NVMe 接口都是由硬件加速器驱动的。这些实例不需要 (或支持) Xen 半虚拟化网络或块设备驱动程序 (两者都已被删除,以提高效率)。

展望未来,我们将使用此管理程序来驱动其他实例类型,并计划在一组 AWS re:Invent 会话中共享其他技术细节。

今天启动 C5
您可以今天在美国东部 (弗吉尼亚北部)美国西部 (俄勒冈)欧洲 (爱尔兰) 区域以按需和竞价形式 (预留实例也可用) 启动 C5 实例,其它区域则在准备中。

我离开之前的一个快速说明:当前的 NVMe 驱动程序没有针对高性能顺序工作负载进行优化,我们不建议将 C5 实例与 sc1st1 卷结合使用。我们知道这个问题,并一直在努力优化这个重要使用案例的驱动程序。

Jeff

如何使用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 EC2 P3 实例多达 8 个 NVIDIA Tesla V100 GPUs 提供支持

自从我们于 2006 年发布最初的 m1.small 实例以来,在客户需求的推动以及不断发展的先进技术的支持下,我们后续推出了各种强调计算能力、超频性能、内存大小、本地存储和加速计算的实例。

新的 P3
现在,我们正在打造下一代 GPU 加速的 EC2 实例,这些实例将会在 4 个 AWS 区域提供。P3 实例由多达 8 个 NVIDIA Tesla V100 GPU 提供支持,可用于处理计算密集型的机器学习、深度学习、计算流体动力学、计算金融学、地震分析、分子模拟和基因组学工作负载。

P3 实例使用运行速度可高达 2.7 GHz 的 Intel Xeon E5-2686v4 定制处理器。有三种大小的实例可供选择 (所有均仅限 VPC 和 EBS):

模型 NVIDIA Tesla V100 GPU GPU 内存 NVIDIA NVLink vCPU 主内存 网络带宽 EBS 带宽
p3.2xlarge 1 16 GiB 不适用 8 61 GiB 最高 10 Gbps 1.5 Gbps
p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps
p3.16xlarge 8 128 GiB 300 GBps 64 488 GiB 25 Gbps 14 Gbps

每个 NVIDIA GPU 都封装了 5,120 个 CUDA 核心和另外 640 个 Tensor 核心,最高可以提供 125 TFLOPS 的混合精度浮点、15.7 TFLOPS 的单精度浮点和 7.8 TFLOPS 的双精度浮点。在两种较大的实例上,GPU 通过以高达 300 GBps 的总数据速率运行的 NVIDIA NVLink 2.0 连接在一起。 这使 GPU 可以高速交换中间结果和其他数据,而不必使其通过 CPU 或 PCI-Express 结构进行。

什么是 Tensor 核心?
我在开始写这篇文章之前,从未听说过“Tensor 核心”这个词。根据 NVIDIA 博客上的这篇非常有帮助的文章的介绍,Tensor 核心是专为加快大型、深度神经网络的训练和推理而设计的。每个核心可以快速高效地将两个 4×4 半精度 (也称为 FP16) 矩阵相乘,然后将得到的 4×4 矩阵与另一个半精度或单精度 (FP32) 矩阵相加,最后将得到的 4×4 矩阵以半精度或单精度的形式存储起来。下面是摘自 NVIDIA 博客文章中的示意图:

此运算发生在深度神经网络训练进程的最内层循环中,这个出色的示例展示了如今的 NVIDIA GPU 硬件是如何为应对非常具体的市场需求而专门打造的。顺便提一下,有关 Tensor 核心性能的混合精度这个限定词意味着,它非常灵活,完全可以处理 16 位和 32 位浮点值组合使用的情况。

性能视角
我总是喜欢将原始的性能数字放入到实际生活视角中,这样,这些数字与生活的关系就会更加密切,并且更有意义 (希望如此)。考虑到单个 p3.16xlarge 上的 8 个 NVIDIA Tesla V100 GPU 可以每秒执行 125 万亿次单精度浮点乘法,要将它与现实相联系就变得异乎寻常地困难。

让我们回到微处理器时代之初,想想我在 1977 年夏天购买的 MITS Altair 中的 Intel 8080A 芯片。该芯片使用 2 MHz 时钟频率,每秒可以执行大约 832 次乘法 (我使用了此处的数据并更正为更快的时钟速度)。p3.16xlarge 比该芯片快了大约 1500 亿倍。然而,从那年夏天到现在才过去了 12 亿秒。换言之,我现在一秒钟所做的计算,比我的 Altair 在过去 40 年里可以完成的计算的 100 倍还要多!

1981 年夏季发布的 IBM PC 有一种可选配件,那就是创新型 8087 算术协同处理器,它的情况又如何呢?该处理器使用 5 MHz 时钟频率和专门打造的硬件,每秒可以执行大约 52,632 次乘法。从那时到现在已经过去了 11.4 亿秒,而 p3.16xlarge 要比它快 23.7 亿倍,因此,这台可怜的小 PC 在过去 36 年里完成的计算量勉强才达到现在 1 秒钟可完成的计算量的一半。

好了,Cray-1 又如何呢? 这台超级计算机最早出现在 1976 年,执行矢量运算的速度为 160 MFLOPS,p3.x16xlarge 比它快了 781,000 倍。在推出以后的这些年中,这台计算机针对某些有意思的问题迭代改进了 1500 次。

考虑到您可以将 P3 视作一台超级计算机中可以根据需要启动的分步重复组件,因此更难将 P3 与现在的横向扩展型超级计算机进行比较。

立即运行一个实例
要充分利用 NVIDIA Tesla V100 GPU 和 Tensor 核心,您需要使用 CUDA 9cuDNN7。这些驱动程序和库已经添加到最新版本的 Windows AMI 中,并且将会包含在计划于 11 月 7 日发布的更新的 Amazon Linux AMI 中。新的程序包已经在我们的存储库中提供,如果需要,您可以在您现有的 Amazon Linux AMI 上安装它们。

最新的 AWS Deep Learning AMI 将会预装在最新版本的 Apache MxNet、Caffe2 和 Tensorflow 中 (均支持 NVIDIA Tesla V100 GPU),并且在 Microsoft Cognitive Toolkit 和 PyTorch 等其他机器学习框架发布对 NVIDIA Tesla V100 GPU 的支持之后,AWS Deep Learning AMI 将会进行更新,以使用这些框架来支持 P3 实例。您也可以针对 NGC 使用 NVIDIA Volta Deep Learning AMI。

美国东部 (弗吉尼亚北部)美国西部 (俄勒冈)欧洲 (爱尔兰) 亚太地区 (东京) 区域,P3 实例以按需、竞价、预留实例和专用主机的形式提供。

Jeff