Category: Amazon EC2*


T2 Unlimited – 以高性能突破突发限制

第一次撰写关于 T2 实例的文章是在 2014 年夏季,在该文章中我讨论了有多少工作负载对持续计算能力有适度的需求但偶尔需要更多的计算能力。该模型引起了我们客户的共鸣;T2 实例非常受欢迎,现在用于托管微服务、低延迟交互式应用程序、虚拟桌面、构建和暂存环境、原型等等。

新的 T2 Unlimited 实例
今天我们正在扩展突发模式,该模式首先在 T2 上得以应用,使您能够在任何期望的时间内维持高 CPU 性能,同时仍然保持尽可能低的成本。您只需在启动实例时启用此功能即可;您也可以为已经运行的实例启用此功能。如果平均 CPU 利用率在 24 小时时段内低于基线,则每小时 T2 实例价格将涵盖使用中的所有临时峰值。如果实例在较长时间内以较高的 CPU 利用率运行,则会产生一小笔小时费用。例如,如果您运行的 t2.micro 实例在 24 小时内的平均使用率为 15% (比基线高出 5%),则将额外收取 6 美分 (每个 vCPU 小时 5 美分 * 1 个 vCPU * 5% * 24 小时)。

要从 EC2 控制台启动 T2 无限实例,请选择任意 T2 实例,然后单击 T2 Unlimited 旁边的 Enable

下面介绍了如何将正在运行的实例从 T2 标准实例切换到 T2 Unlimited 实例:

背景知识
正如我在原来的博客文章中所介绍的那样,每个 T2 实例在运行时积累 CPU 点数,并在全速运行时消耗 CPU 点数,当供应的点数用完时会减速到基线水平。T2 Unlimited 实例能够借用一整天的未来点数,这使它们能够执行额外的突发。这种借用的点数是使用新的 CPUSurplusCreditBalance CloudWatch 指标来跟踪的。当这个剩余额度上升到代表一整天未来点数的水平时,该实例会继续提供全核心性能,对于 Linux 的收费为每小时 0.05 美元,对于 Windows 的收费为 0.096 美元。这些收费的额外点数是使用新的 CPUSurplusCreditBalance CloudWatch 指标来跟踪的。如果您在指定的小时内耗尽了额外点数,则将以毫秒为单位对突发的部分小时数进行计费 (进一步降低您的成本)。

任何剩余的 CPUSurplusCreditBalance 的费用将在实例终止或配置为 T2 标准实例时处理。在转换到 T2 标准期间将结转任何累积的 CPUCreditBalance

T2 Unlimited模型旨在让您省去观察 CloudWatch 指标的麻烦,但是 (如果您和我一样),无论如何您都会这样做。让我们快速浏览一下 t2.nano,并且观察点数随时间的变化。首先,CPU 利用率增长到 100%,实例每 5 分钟消耗 5 个点数 (一个点数相当于一 VCPU 分钟):

CPU 点数剩余额度保持为 0,因为点数以相同的速率产生和消耗。额外点数剩余额度 (通过 CPUSurplusCreditBalance 指标来跟踪) 追加至 72,这代表从未来借入的点数:

一旦额外点数剩余额度达到 72,就无法再从未来借用,并且在 1 小时结束时会收取任何进一步的 CPU 使用费,该费用使用 CPUSurplusCreditsCharged 指标来跟踪。实例每 5 分钟消耗 5 个点数,赚取 0.25,导致每 5 分钟突发的净收费为 4.75 VCPU 分钟:

您可以随时在 T2 标准实例和 T2 Unlimited 实例之间来回切换您的每个实例;除 CPUSurplusCreditsCharged 之外的所有点数剩余额度都会保留并结转。由于 T2 Unlimited 实例有能力在任何时候突发,因此它们不会收到为新启动的 T2 标准实例提供的 30 分钟点数。此外,由于每个 AWS 账户每天只能启动有限数量的带初始 CPU 点数的 T2 标准实例,因此 T2 Unlimited 实例可能更适合在 Auto Scaling 组以及每天启动并运行大量实例的其他场景中使用。

现已推出
您目前可以在美国东部 (弗吉尼亚北部)美国东部 (俄亥俄)美国西部 (加利福尼亚北部)美国西部 (俄勒冈)加拿大 (中部)南美洲 (圣保罗)亚太区域 (新加坡)亚太区域 (悉尼)亚太区域 (东京)亚太区域 (孟买)亚太区域 (首尔)欧洲 (法兰克福)欧洲 (爱尔兰)欧洲 (伦敦) 区域中启动 T2 Unlimited 实例。

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