亚马逊 AWS T2 一种能累积计算积分的EC2实例类型.pdfVIP

亚马逊 AWS T2 一种能累积计算积分的 EC2实例类型 如果您打算在AWS云端运行一个小型的 WebServer，或是一个小型的数据库，平时并没 有大量的工作负载，在绝大多数时间里，您的实例并不需要消耗大量的CPU资源。但是， 再不怎么受欢迎的博客也可能会有突然被追评的那几分钟，再小型的数据库也可能会有数据 加载时那忙碌的几十分钟， BuildServer在Build代码时自然也希望有“请勿打扰”的时刻。 面对这种平时CPU 负载非常低，但有时CPU 资源却在短时间内捉襟见肘的情况。因该选 择什么实例类型才最经济？ 好比您租了一个可供4 人居住的房间，平时却只有您1人居住，但却支付着4 人份的租金； 节假日突然有6 个亲戚同时登门拜访，但您却只能提供4 人的空间。此刻您的心情可以理 解，首先是十分地郁闷，其次您会发觉是否可以这样操作：把平时多支付的3人份房租累 积起来，变成一种“积分”，当空间需求突然紧张时，立即使用您的“积分”来兑换一个更大的 空间而无需支付额外的费用！ 2014 年7 月1 日，我们推出了一种崭新的低成本EC2 实例类型：T2，目前该类型有三种 size，分别是micro、small和medium。T2 实例具有一种新的CPU积分功能，它可将您平 时没有占用的CPU 资源累积起来，用来应付将来的负载高峰。想像一下，一个4 人的房间， 在高峰期能动态地容纳7 人，无需额外成本，因为您平时已经在为没有使用的3人空间付 费了，为什么不能让您享受这样的福利呢？为什么不呢？ 以下是T2 实例的一些规格 （以美国东部区域为例），请留意第3 列和第5 列－Baseline Performance和CPUCredits ／Hour： Baseline Performance表示实例占用的物理CPU周期百分比。CPUCredits ／Hour代表实 例每小时的CPU积分速率。如果实际CPU利用率低于Baseline Performance 的百分比， CPU积分就会得到累积，积分是一种使用超过Baseline Performance 阈值的CPU 资源的 能力，在实例需要这种额外运算能力时积分会自动抵扣。累积的CPU积分会在24 小时后 过期。也就是说t2.micro 最高144 分、t2.small最高288 分、以及t2.medium最高576 分。 如果您发现您总是在浪费积分，也就是实例的CPU积分总处于最高值，或许您需要使用更 小的实例从而更加节省成本。 究竟何为CPU积分？一个CPU积分表示能够使用100% 满负荷物理CPU周期1分钟。 例如，一个t2.micro 实例在占用CPU10%以下的情况下运行了10 小时，这样它就赢得了使 用100%CPU 1小时的积分 （60分，请参考规格表，以每小时6 分累积）。 如果您的业务流程会在每个工作日的开始和结束时有突发计算量，将此应用运行在T2 实例 上，通过使用在非负载高峰期累积的CPU积分可以使您迅速且经济有效地应付负载高峰期 的运算载荷。 当一个T2实例的CPU积分耗尽时，它的性能会在一个15分钟的窗口中逐步回到基准水平。 配套地，有两个新的CloudWatch指标随之引入，分别是CPUCreditUsage和 CPUCreditBalance，前者关注积分的消费，后者关注积分的累积。 另外，还有一个好消息是每个T2 实例初始启动时就带初始的积分，如果与SSD 的EBS 存 储组合使用这将使T2 的启动速度明显比它的前辈快。 来观察一个T2 实例编译Linux 内核的简单例子，该实例是刚刚初始启动的： 可以看到编译共费时23分钟，通过AWSConsole 里的CloudWatch监控我们可以看到积 分积攒和消费的情况： 图中橙线表示CPU积分的消费，波峰出现在内核编译时。蓝线显示积分值，正好与橙线的 走向相反。需要额外说明的是积分 （蓝线）初始并不为0，并且在开始编译前处于累积阶段， 在整个编译过程中始终没有低于15 分，说明实例拥有的积分完全可以应付编译过程，就像 是科幻电影里的战舰护盾没有在敌人的攻击下失效，船体仍然完好。而且，在编译结束后的 半小时内CPU积分又回升到了25 分。 再来观察一下CloudWatch在同一时段上的有关CPU使用率的报告： 可以清楚地看到在编译的23 分钟里CPU使用率为100%，这是用积分换来的计算能力而不 是额外购买得来的。 接下来通过阶段性的反复编译模拟一个长期的场景，眼前的实例是否可以应付变化的工作负 载，读者您可以给出答案吗？ 虽然不够确切，但还是可以给出一个T2 家族与上一代实例的近似对应关系： • 上一代t1.mi