EBS与实例存储的好处（反之亦然）

Question

我不清楚我在Amazon EC2上为我的实例从EBS和实例存储中获得了什么好处。如果有的话，似乎EBS在成本相对较小的差异方面更有用（停止，开始，持续+更好的速度）......？此外，是否有更多人正在使用EBS，因为它仍然相对较新，是否有可用的指标？

Answer 1

最重要的是，你应该几乎总是使用EBS支持的实例。

这就是为什么

• 可以设置EBS支持的实例，以便它们不会（意外地）通过API终止。
• EBS支持的实例可以在您不使用时停止，并在您再次需要时恢复（例如暂停虚拟PC），至少使用我的使用模式可以节省比我花费几十GB更多的钱。 EBS存储。
• EBS支持的实例在崩溃时不会丢失实例存储（不是所有用户的要求，但可以更快地恢复）
• 您可以动态调整EBS实例存储的大小。
• 您可以将EBS实例存储转移到一个全新的实例（如果您运行的亚马逊上的硬件变得不稳定或死亡，这种情况确实很有用）
• 启动EBS支持的实例的速度更快，因为不必从S3获取图像。
• 如果您的EBS支持的实例的硬件为scheduled for maintenance，则停止并启动实例会自动迁移到新硬件。我还能够通过强制停止实例并再次启动它来在故障硬件上移动EBS支持的实例（您的里程可能因故障硬件而异）。

我是亚马逊的重度用户，并且在技术测试结束后，我将所有实例都转换为EBS支持的存储。我对结果非常满意。

EBS仍然可能失败 - 不是银弹

请记住，任何基于云的基础架构都可能随时出现故障。相应地规划基础架构。虽然与临时存储实例相比，EBS支持的实例提供了一定程度的持久性，但它们可能会失败。有一个AMI，您可以根据需要在任何可用区域中启动新实例，备份您的重要数据（例如数据库），如果您的预算允许，运行多个服务器实例以实现负载平衡和冗余（理想情况下在多个可用区域中） ）。

何时不

在某些时间点，在Instance Store实例上实现更快的IO可能更便宜。曾经有一段时间它确实是真的。现在有许多EBS存储选项，可满足许多需求。随着技术的变化，选项及其定价也在不断变化。如果您有大量实际可以丢弃的实例（如果它们刚刚消失，它们对您的业务影响不大），请对成本与性能进行比较。 EBS支持的实例也可能在任何时间点死亡，但我的实际经验是EBS更耐用。

Answer 2

99％的AWS设置都是可回收的。所以对我而言，如果我终止一个实例并不重要 - 永远不会丢失任何东西。例如。我的应用程序自动部署在SVN的实例上，我们的日志被写入中央系统日志服务器。

我看到的实例存储的唯一好处是节省成本。否则EBS支持的实例获胜。埃里克提到了所有的优势。

---

[2012-07-16]我今天会说这个答案有很多不同。

在过去一年左右的时间里，我对EBS支持的实例没有任何良好的经验。 AWS的最后停机时间也很糟糕。

我猜测像RDS这样的服务也使用某种EBS，这似乎在很大程度上起作用。在我们自己管理的实例中，我们尽可能地摆脱了EBS。

摆脱我们将数据库集群移回铁（=真实硬件）的延伸。我们基础架构中唯一剩下的部分是数据库服务器，我们将多个EBS卷分成软件RAID并每天备份两次。无论在备份之间丢失什么，我们都可以忍受。

EBS是一项有点过时的技术，因为它本质上是一个网络卷：一个从远程连接到服务器的卷。我并不否定用它完成的工作 - 这是一个了不起的产品，因为基本上无限的持久性存储只是一个API调用。但它很难适用于I / O性能至关重要的场景。

除了网络存储的行为方式外，所有网络都在EC2实例上共享。较小的实例（例如t1.micro，m1.small）越糟糕，因为实际主机系统上的网络接口在运行在其上的多个VM（=您的EC2实例）之间共享。

您获得的实例越大，更好当然。这里更好的意思是在理性。

当需要持久性时，我总是建议人们使用类似S3的东西来集中实例。 S3是一项非常稳定的服务。然后将您的实例设置自动化到可以启动新服务器的位置，并自行准备。然后，不需要具有比实例更长寿命的网络存储。

总而言之，我认为EBS支持的实例没有任何好处。我宁愿在bootstrap上加一分钟，然后用潜在的SPOF运行。

Answer 3

我们喜欢实例店。它迫使我们使我们的实例完全可循环使用，并且我们可以轻松地自动化在给定AMI上从头开始构建服务器的过程。这也意味着我们可以轻松换掉AMI。此外，EBS仍然会不时出现性能问题。

Answer 4

埃里克几乎把它钉了起来。我们（Bitnami）是流行的应用程序和开发框架的免费AMI的流行提供商（PHP，Joomla，Drupal，你明白了）。我可以告诉你，EBS支持的AMI比S3支持的更受欢迎。一般来说，我认为s3支持的实例用于分布式，限时工作（例如，大规模数据处理），如果一台机器发生故障，另一台机器就会被简化。 EBS支持的AMIS倾向于用于“传统”服务器任务，例如在本地保持状态的Web或数据库服务器，因此在崩溃的情况下需要数据可用。

我没有看到提到的一个方面是您可以在运行时拍摄EBS支持的实例的快照，从而有效地允许您对基础架构进行非常经济高效的备份（快照是基于块的和增量的）

Answer 5

EC2＆＃34;硬件＆＃34;

启动EC2实例时，会保留一个虚拟机以供该实例运行。该虚拟机具有特定的规格，具体取决于实例类型：32位或64位CPU，虚拟核心数，硬盘大小等。有关实例规范的详细信息，请访问http://aws.amazon.com/ec2/#instance。

当您的EC2实例处于＆＃34;运行＆＃34; state，这意味着它正在虚拟机上运行，​​这就是你需要付费的。

虚拟机的硬盘驱动器被视为＆＃34;短暂的＆＃34;。术语＆＃34;短暂的＆＃34;来自希腊词＆＃34; ephemeros＆＃34;这意味着＆＃34;只持续一天＆＃34;。这种硬盘上的任何东西都应该被视为暂时的。除非数据从硬盘驱动器复制，否则如果虚拟机停止，则数据将丢失。这包括数据，软件，甚至是驻留在这些硬盘上的操作系统。

Amazon Web Services为EC2实例提供两种类型的根设备：＆＃34; EBS支持＆＃34;和＆＃34;实例店＆＃34;。

＆＃34;实例商店＆＃34;实例

＆＃34;实例商店＆＃34; instance是一个EC2实例，其根设备驻留在虚拟机的硬盘上。创建实例时，基本AMI将复制到虚拟机的硬盘驱动器并启动。实例可以根据需要运行，但不能停止。由于实例的根设备是实际的硬盘驱动器，因此它被卡住了＃34;在硬件上，你唯一能做的就是终止实例。如果执行此操作，将删除该实例，永远不会恢复。您还冒着这样的风险：如果虚拟机的硬件出现故障，那么您也将丢失硬盘驱动器上的任何内容。

如果您启动＆＃34;实例商店＆＃34;例如，准备好让它一直运行直到你完全完成它。请注意，从实例启动到关闭实例，您将收取费用。

＆＃34; EBS后援＆＃34;实例

＆＃34; EBS支持＆＃34; instance是一个EC2实例，它使用EBS卷作为其根设备。 EBS卷是多余的，＆＃34;虚拟＆＃34;驱动器，不依赖于任何特定硬件，但它们仅限于特定的EC2可用区。这意味着EBS卷可以在同一可用区内从一个硬件移动到另一个硬件。您可以将EBS卷视为一种网络附加存储。

如果虚拟机的硬件出现故障，可以将EBS卷简单地移动到另一个虚拟机并重新启动。从理论上讲，你不会丢失任何数据。

另一个好处是，可以轻松备份和复制EBS卷。因此，您可以轻松备份卷的快照，创建新卷并根据这些重复的卷启动新的EC2实例。

可能是最大的优势＆＃34; EBS支持＆＃34;实例已超过＆＃34;实例存储＆＃34;实例是他们可以被阻止。执行此操作时，将关闭虚拟机并存储EBS卷以供以后检索。然后，硬件可供其他人使用。此外，在此期间，您不会向EC2实例收取运费。但是您需要为EBS存储付费。当您希望实例再次运行时，您只需再次启动它。保留一个新虚拟机，附加您的EBS卷，然后启动您的实例。

但虚拟机的硬盘怎么样？

是的，可以使用这些硬盘驱动器，即使您的EC2实例是＆＃34; EBS支持的＆＃34;。默认情况下，它们不可用。如果使用命令行程序启动实例，则可以使用＆＃34; -b＆＃34; ec2-run-instances命令上的选项用于附加＆＃34;实例存储＆＃34;驱动到您的EC2实例。

如果要存储临时数据，将这些驱动器提供可能是有益的。读取和写入访问应该比读取和写入EBS卷更快，因为您不通过网络发送数据。此外，您不需要为数据传输或数据存储付费。但这只有在数据可能随时丢失的情况下才有效。

来源：http://help.skeddly.com/amazon-web-services/ebs-backed-versus-instance-store

Answer 6

我在最后一个位置上和Eric有过完全相同的经历。现在，在我的新工作中，我将完成我在上一份工作中执行的相同流程...为EBS支持的实例重建所有AMI - 可能还有32位机器（更便宜 - 但不能在32和32上使用相同的AMI） 64台机器）。

EBS支持的实例启动得足够快，您可以开始使用Amazon AutoScaling API，它允许您使用CloudWatch指标触发其他实例的启动并将它们注册到ELB（Elastic Load Balancer），以及不再需要时关闭它们。

这种动态自动扩展就像AWS一样 - IT基础架构的真正节省可以发挥作用。使用旧的s3“InstanceStore”支持的实例进行自动缩放几乎是不可能的。

Answer 7

我刚开始使用EC2，所以不是专家，但是Amazon's own documentation说：

  

我们建议您将本地实例存储用于临时数据，用于需要更高级别持久性的数据，我们建议使用Amazon EBS卷或将数据备份到Amazon S3。

强调我的。

我比网络托管更多data analysis，因此持久性对我来说并不像对网站那么重要。鉴于亚马逊本身的区别，我不认为EBS适合所有人。

在我使用两者之后，我会记得再次称重。

Answer 8

EBS就像虚拟机的虚拟磁盘：

• 耐用，EBS支持的实例可以自由启动和停止（省钱）
• 可以在任何时间点进行快照，以获取时间点备份
• AMI可以从EBS快照创建，因此EBS卷成为新系统的模板

实例存储是：

• 本地，所以通常更快
• 非联网，在正常情况下，EBS I / O的代价是网络带宽（EBS优化实例除外，它们具有单独的EBS带宽）
• 每秒IOPS的I / O有限。即使配置的I / O最大也只有几千IOPS
• 脆弱。实例停止后，您将丢失实例存储中的所有内容。

以下是每个地方的使用方法：

• 使用EBS作为支持操作系统分区和永久存储（数据库数据，关键日志，应用程序配置）
• 将实例存储用于进程内数据，非关键日志和瞬态应用程序状态。示例：外部排序存储，临时文件等
• 当实例之间复制时（NoSQL DB，分布式队列/消息系统和带复制的DB），实例存储也可用于性能关键数据
• 将S3用于系统之间共享的数据：输入数据集和处理结果，或者每个系统在发布时使用的静态数据。
• 将AMI用于预烘焙的可启动服务器

Answer 9

大多数人选择使用EBS支持的实例，因为它是有状态的。它更安全，因为您在其中运行和安装的所有内容都将在停止/停止或任何实例故障后继续存在。

实例存储是无状态的，如果出现任何实例故障情况，您将使用内部的所有数据将其丢失。但是，它是免费且更快的，因为实例卷与运行VM的物理服务器相关联。

Answer 10

对于所有这一切的新手，如果不小心落在这里

截至目前，所有AMI的快速启动部分均为EBS支持

另外，official doc对 EBS 和实例商店

之间的区别有一个很好的解释

＆安培;这个图像几乎总结了它

Answer 11

如果您运行多个实例并将AWS实例的预定服务指定为Avoiding Unexpected Charges的优先级之一，我建议不要使用实例存储。

  

正如EBS Volumes的文档所解释   以及来自j2d3和Siddharth Sharma的答案   实例存储可以根据需要运行，但不能运行   停止即可。表示该服务无法由Automatic Start/Stop或Instance Recovery安排。

此外，对于这种方案，在 EBS Backed 上使用 Elastic Beanstalk 也没有任何好处，因为它旨在确保所有您需要的资源是keep running。它将始终自动重新启动您停止的任何服务。 在使用添加到all the rest的VPC，EBS和ELB， EC2-Classic的总费用中，对EC2-VPC进行了审核使用ELB 主要是最佳选择，与 EC2-Classic 不同，停止的实例retains与其关联的 Elastic IP addresses < / em>并且EBS卷自动为stored。

作为结论，取决于问题的主要部分：

  似乎EBS更有用（停止，开始，坚持+更好   速度相对较小的成本差异......？

答案是 是 ，但如果您的实例是基于EBS的，则可以停止。它将保留在您的帐户you will not be charged for it中。您只需收取EBS is charged hourly的费用。您也可以考虑在所有available types中Resize the EBS Volume，Eric。

除S3 may or may not be cheaper than EBS已列出的好处外，还应注意成本both types of instance。我同意，如果您始终在应用程序的同一平台和体系结构中继续运行pull all unhandled task，则成本差异相对较小。

但是，如果有方案可以通过 {{在{em> role them 上以低成本服务VPC/EBS和pipeline运行应用程序3}} 或 lambda 在短时间内说＆lt;每天1小时，使用实例存储时无法做到，那将是一个不同的故事。