对于我在 Amazon EC2 上的实例,我不清楚我从 EBS 与实例存储中获得了什么好处。如果有的话,EBS 似乎更有用(停止、启动、持续 + 更好的速度),而成本差异相对较小......?此外,考虑到 EBS 仍然相对较新,是否有更多的人在使用 EBS 时是否有任何衡量标准?
10 回答
底线是您应该几乎总是使用 EBS 支持的实例。
这就是为什么
- 可以设置 EBS 支持的实例,以便它们不会(意外)通过 API 终止。
- EBS 支持的实例可以在您不使用它们时停止,并在您再次需要它们时恢复(例如暂停虚拟 PC),至少与我在几十 GB EBS 存储上花费的相比,我的使用模式节省了更多的钱。
- EBS 支持的实例在崩溃时不会丢失其实例存储(不是所有用户都需要,但可以更快地恢复)
- 您可以动态调整 EBS 实例存储的大小。
- 您可以将 EBS 实例存储转移到一个全新的实例(如果您在 Amazon 上运行的硬件出现故障或死机,这种情况时有发生,这很有用)
- 启动 EBS 支持的实例会更快,因为不必从 S3 获取图像。
- 如果您的 EBS 支持的实例的硬件计划进行维护,则停止和启动实例会自动迁移到新硬件。我还能够通过强制停止实例并再次启动它来在故障硬件上移动 EBS 支持的实例(您的里程可能因故障硬件而异)。
我是 Amazon 的重度用户,并且在该技术推出测试版后立即将我的所有实例切换到 EBS 支持的存储。我对结果非常满意。
EBS 仍然可能失败 - 不是灵丹妙药
请记住,任何基于云的基础架构都可能随时出现故障。相应地规划您的基础架构。虽然与临时存储实例相比,EBS 支持的实例提供了一定程度的持久性,但它们可能而且确实会失败。拥有一个 AMI,您可以根据需要在任何可用区启动新实例,备份重要数据(例如数据库),如果您的预算允许,运行多个服务器实例以实现负载平衡和冗余(最好在多个可用区中) )。
什么时候不
在某些时间点,在 Instance Store 实例上实现更快的 IO 可能会更便宜。曾经有一段时间它肯定是真的。现在 EBS 存储有多种选择,可满足多种需求。随着技术的变化,选项及其定价会不断变化。如果您有大量真正一次性的实例(如果它们消失,它们不会对您的业务产生太大影响),请计算成本与性能。EBS 支持的实例也可能随时死亡,但我的实践经验是 EBS 更耐用。
我们 99% 的 AWS 设置都是可回收的。所以对我来说,如果我终止一个实例并不重要——什么都不会丢失。例如,我的应用程序自动部署在 SVN 的实例上,我们的日志被写入中央系统日志服务器。
我看到的实例存储的唯一好处是节省成本。否则,由 EBS 支持的实例获胜。埃里克提到了所有的优点。
[2012-07-16] 今天我会用不同的方式来表达这个答案。
在过去一年左右的时间里,我对 EBS 支持的实例没有任何好的经验。AWS 上的最后一次停机也几乎破坏了 EBS。
我猜像 RDS 这样的服务也使用某种 EBS,而且这似乎在大多数情况下都有效。在我们自己管理的实例上,我们尽可能摆脱了 EBS。
摆脱我们将数据库集群移回铁(=真正的硬件)的扩展。我们基础设施中唯一剩下的部分是数据库服务器,我们将多个 EBS 卷条带化到软件 RAID 中并每天备份两次。无论备份之间会丢失什么,我们都可以忍受。
EBS 是一种有点古怪的技术,因为它本质上是一个网络卷:从远程连接到您的服务器的卷。我并没有否定它所做的工作——它是一个了不起的产品,因为基本上无限的持久存储只是一个 API 调用。但它几乎不适合 I/O 性能是关键的场景。
除了网络存储的行为方式之外,所有网络都在 EC2 实例上共享。实例越小(例如 t1.micro、m1.small)就越糟糕,因为您在实际主机系统上的网络接口在多个在其上运行的虚拟机(=您的 EC2 实例)之间共享。
你得到的实例越大,它当然就越好。这里的更好是指在合理范围内。
当需要持久性时,我总是建议人们使用 S3 之类的东西在实例之间集中。S3 是一个非常稳定的服务。然后将您的实例设置自动化到可以启动新服务器并自行准备好的程度。那么就没有必要拥有比实例寿命更长的网络存储。
所以总而言之,我认为 EBS 支持的实例没有任何好处。我宁愿在引导程序中增加一分钟,然后以潜在的 SPOF 运行。
我们喜欢实例存储。它迫使我们使我们的实例完全可回收,并且我们可以轻松地自动化在给定 AMI 上从头开始构建服务器的过程。这也意味着我们可以轻松更换 AMI。此外,EBS 仍然不时出现性能问题。
埃里克几乎做到了。我们(Bitnami)是流行的应用程序和开发框架(PHP、Joomla、Drupal,你懂的)的免费 AMI 的流行提供商。我可以告诉您,由 EBS 支持的 AMI 比由 S3 支持的 AMI 更受欢迎。一般来说,我认为 s3 支持的实例用于分布式的、有时间限制的作业(例如,大规模数据处理),如果一台机器发生故障,另一台机器就会简单地启动。EBS 支持的 AMIS 倾向于用于“传统”服务器任务,例如将状态保持在本地的 Web 或数据库服务器,因此需要在崩溃的情况下提供数据。
我没有看到提到的一个方面是,您可以在运行时拍摄由 EBS 支持的实例的快照,从而有效地让您对基础架构进行非常经济高效的备份(快照是基于块的和增量的)
我在上一个职位上的经历与 Eric 完全相同。现在在我的新工作中,我正在经历我在上一份工作中执行的相同过程......为 EBS 支持的实例重建所有 AMI - 并且可能作为 32 位机器(更便宜 - 但不能在 32 和64 台机器)。
EBS 支持的实例启动速度足够快,您可以开始使用Amazon AutoScaling API,该 API 允许您使用 CloudWatch 指标来触发其他实例的启动并将它们注册到 ELB(弹性负载均衡器),并在何时关闭它们不再需要。
这种动态自动扩展就是 AWS 的全部意义所在 - IT 基础设施的真正节省可以发挥作用。使用旧的 s3“InstanceStore”支持的实例进行自动缩放几乎是不可能的。
EBS 就像 VM 的虚拟磁盘:
- 经久耐用,由 EBS 支持的实例可以自由启动和停止(省钱)
- 可以在任何时间点进行快照,以获得时间点备份
- AMI 可以从 EBS 快照创建,因此 EBS 卷成为新系统的模板
实例存储为:
- 本地,所以通常更快
- 非联网,在正常情况下,EBS I/O 以网络带宽为代价(EBS 优化实例除外,它们具有单独的 EBS 带宽)
- 每秒 IOPS 的 I/O 有限。甚至预置的 I/O 也能达到几千 IOPS
- 脆弱的。一旦实例停止,您将丢失实例存储中的所有内容。
以下是每个的使用位置:
- 将 EBS 用于支持操作系统分区和永久存储(数据库数据、关键日志、应用程序配置)
- 将实例存储用于进程内数据、非关键日志和瞬态应用程序状态。示例:外部排序存储、临时文件等。
- 当实例之间存在复制(NoSQL 数据库、分布式队列/消息系统和具有复制的数据库)时,实例存储也可用于性能关键数据
- 将 S3 用于系统之间共享的数据:输入数据集和处理结果,或者用于每个系统在启动时使用的静态数据。
- 将 AMI 用于预烘焙、可启动的服务器
大多数人选择使用 EBS 支持的实例,因为它是有状态的。它更安全,因为您在其中运行和安装的所有内容都将在停止/停止或任何实例故障后继续存在。
实例存储是无状态的,如果发生任何实例故障情况,您可以将其与内部的所有数据一起丢失。但是,它是免费且速度更快的,因为实例卷与运行 VM 的物理服务器相关联。
如果您运行多个实例并将 AWS Instance 的计划服务分配为避免意外费用的优先事项之一,我建议不要使用 instance-store。
正如EBS 卷的文档以及j2d3和Siddharth Sharma 的回答中所解释的那样,实例存储可以根据需要运行,但不能停止。表示无法通过自动启动/停止或实例恢复来安排服务。
此外,对于这种方案,使用基于Elastic Beanstalk的EBS也没有任何好处,因为它旨在确保您需要的所有资源保持运行。它总是会自动重新启动您停止的任何服务。
回顾所有其余部分,在使用添加到EC2-Classic的VPC、EBS和ELB的总费用中,带ELB的EC2-VPC主要是最佳选择,与EC2-Classic不同,停止的实例保留其关联的Elastic IP 地址并自动存储EBS 卷。
作为结论,以您问题的主要部分为例:
似乎 EBS 更有用(停止、启动、持续 + 更好的速度),而成本差异相对较小......?
答案是肯定的,但如果您的实例是基于 EBS 的,则可以停止它。它将保留在您的帐户中,不会向您收取任何费用。您将只按量收费,但EBS 按小时收费。您还可以考虑在所有可用类型中,您可以灵活地调整 EBS 卷的大小。
除了Eric已经列出的好处之外,它还应该知道,在成本方面,S3 可能比 EBS 便宜,也可能不便宜。我同意,如果您始终在同一平台和应用程序架构中运行这两种类型的实例,则成本差异相对较小。
但是,如果有在低成本服务上运行应用程序的场景,请在短时间内通过管道或lambda将所有未处理的任务拉到VPC / EBS中,比如每天不到 1 小时,当您使用 instance-store,那将是一个不同的故事。