EBS和实例存储的优缺点比较（以及反之）

Question

EBS和实例存储的优缺点比较（以及反之）

388

我不太清楚在亚马逊EC2实例上，使用EBS和instance-store会带来哪些好处。如果说有什么区别的话，似乎EBS更加有用（可以停止、启动、保留数据以及速度更快），而且成本的差距也不大。此外，现在是否有任何指标表明更多的人正在使用EBS，考虑到它还比较新？

- HelloWorldy

1

http://alestic.com/2012/01/ec2-ebs-boot-recommended - Jeroen Ooms

如果您使用EBS支持的实例，才能使用“micro”。 - Ali

1

实例存储卷速度更快，不需要基于网络的存储！ - hookenz

我个人使用instance-store将正在运行的MongoDB集合转储到其中，并将其放在S3上，有两个原因。首先，它是分离的，不会降低我的10卷EBS RAID的写入速度。其次，它比EBS快得多，而且由于它与我的实例一起提供，所以我没有必要创建额外的EBS卷来进行转储，并在将它们放在S3上后销毁它们。希望这可以帮助你，而不是让你感到困惑。 - Maziyar

2

我已经看了 AWS 用户指南的一半（700页）。仔细阅读了有关 EBS 和实例存储的内容，但仍然无法理解它们之间的差异。更让人困惑的是，为什么实例存储相当于 S3，但名称不同。必须重新打开问题，以获得更多有用答案的贡献。 - Polymerase

@Polymerase实例存储是物理服务器的本地磁盘，与S3或EBS不同。实例存储是短暂的，因此在实例重新启动后，其中的任何内容都会丢失。 - paradroid

10个回答

70

我们AWS配置的99％可以回收利用。所以对我来说，终止实例并不重要 - 永远不会有任何损失。例如，我的应用程序会自动从SVN部署在实例上，我们的日志将写入到中央syslog服务器中。

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

[2012-07-16] 我今天会用完全不同的方式表达这个答案。

过去一年左右，我没有任何使用支持EBS的实例的好经验。 AWS上最后一次停机破坏了EBS。

我猜像RDS这样的服务也使用某种形式的EBS，并且这似乎在大部分情况下都有效。在我们自己管理的实例上，我们尽可能摆脱了EBS。

我们已经将数据库集群移回到钢铁（=真正的硬件）的程度。我们基础架构中仅剩的一个部分是我们将多个EBS卷条带化为软件RAID并每天备份两次的DB服务器。在备份之间丢失的任何内容，我们都可以接受。

由于它本质上是远程网络卷，因此EBS是一种有点不稳定的技术：连接到服务器的卷。我并不否认使用它所做的工作-这是一个惊人的产品，因为基本上无限的持久

存储只需调用API即可获得。但它几乎不适合I / O性能关键的场景。

除了网络存储行为如何之外，所有网络都在EC2实例上共享。实例越小（例如t1.micro，m1.small），情况就会变得越糟，因为您在实际主机系统上的网络接口被多个VM（=您的EC2实例）共享。

您获得的实例越大，当然就越好。这里的“更好”意味着“合理”。

当需要持久性时，我总是建议人们使用像S3这样的服务来在实例之间进行集中管理。S3是一个非常稳定的服务。然后将您的实例设置自动化到可以启动新服务器并且自行准备就绪的程度。那么就没有必要拥有比实例寿命更长的网络存储。

总的来说，我认为EBS支持的实例没有任何好处。我宁愿增加一分钟的引导时间，也不想冒险使用潜在的单点故障。

- Till

1

相对于标准卷，使用EBS IOPS类型的卷是否能够显著提高IO性能？假设上述情况也适用于EBS IOPS卷。 - honzajde

5

两种技术都在不断进化。我写这个评论是在2014年，当时我使用的是“Provisioned IOPS” EBS，但现在，“instance store”是SSD，比以前更快！临时存储始终在速度方面占优势。因此，我同时使用两者-将“持久性”的东西放在EBS上，将所有临时文件、日志、“TempDB”数据库、交换文件和其他东西放在Instance-store上。从中获益！ - Alex from Jitbit

如果您需要一个分布式数据库，需要以分布式和持久的方式存储其数据，那么如果实例存储不是持久的，您不需要EBS吗？ - CMCDragonkai

@CMCDragonkai 当然了。现在有很多选择，例如AWS开始提供基于SSD的存储。我建议您研究一下这些，并重新进行分析（单个与RAID等）。此外，由于网络吞吐量的原因，我还建议您尽可能获取最大的实例。对于像t1.micro这样的实例，EBS仍然是一个问题。 - Till

1

这个回答关于网络性能的部分已经相当过时了 - 目前已经存在多种实例可以通过支付少量额外费用来进行“EBS优化”，还有一些默认就是这样（没有附加费用），它们具有专用于EBS的网络接口，参见http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html。 - Josip Rodin

42

我们喜欢使用实例存储。这迫使我们使我们的实例完全可回收，我们可以轻松自动化从给定的AMI开始构建服务器的过程。这也意味着我们可以轻松更换AMI。此外，EBS仍然偶尔存在性能问题。

- sehugg

6

Netflix也会提供类似的推荐。 - Kingz

2

那么你把基于块的持久文件存储在哪里？ - CMCDragonkai

18

Eric已经说得很好了。我们 (Bitnami) 是一个流行的提供免费 AMI 的服务提供商，针对常见应用程序和开发框架 (PHP、Joomla、Drupal 等)。我可以告诉你，EBS 支持的 AMI 比 S3 支持的使用更普遍。一般来说，S3 支持的实例用于分布式、有时限的任务 (例如大规模数据处理)，其中如果一个机器失败，就会简单地启动另一个机器。 EBS 支持的 AMI 常用于“传统”的服务器任务，例如 Web 或数据库服务器，这些服务器需要在本地保留状态，因此需要在崩溃时使数据可用。

我没有看到提到的一个方面是，您可以在运行 EBS 支持的实例时拍摄快照，从而有效地获得成本效益高的基础设施备份。(快照是基于块的，增量更新)

- Daniel Lopez

S3具有内置的冗余功能。EBS没有，因此您需要在其上部署冗余软件。 - Pacerier

2

@Pacerier，这是不正确的，根据官方文档http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html。 - Josip Rodin

16

我在上一份工作中也经历了和Eric完全相同的经历。现在在我的新工作中，我正在执行与上一份工作相同的过程……重新构建所有基于EBS支持的实例的AMI，并且可能是32位机器（更便宜，但无法在32位和64位机器上使用相同的AMI）。

基于EBS支持的实例启动速度足够快，您可以开始使用Amazon AutoScaling API，该API允许您使用CloudWatch指标触发启动额外实例并将其注册到ELB（弹性负载均衡器），并在不再需要时关闭它们。

这种动态自动缩放是AWS的关键 - 这是IT基础设施中真正节省成本的方法。使用旧的s3“InstanceStore”支持的实例几乎不可能正确地进行自动缩放。

- j2d3

13

我刚开始使用EC2，还不是专家，但Amazon的官方文档说：

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

以上为我的强调。

与 Web 托管相比，我更多地进行数据分析，因此持久性对我来说并不那么重要。鉴于亚马逊本身所做出的区别，我不会认为EBS适合每个人。

在我使用过两者之后，我会记得再发表评论。

- isomorphismes

10

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

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

实例存储：

本地存储，通常更快
非网络化，在正常情况下，EBS I / O会牺牲网络带宽（除了具有单独EBS带宽的EBS优化实例之外）
IOPS每秒的I / O受到限制。即使是已规划的I / O也会达到几千个IOPS的上限
脆弱。一旦实例停止，您就会失去实例存储中的所有内容。

以下是各自使用的方法：

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

- BobMcGee

5

大多数人选择使用EBS支持的实例，因为它是有状态的。这是更安全的，因为你在其中运行和安装的所有内容都将在停止/启动或任何实例故障情况下保留。

实例存储是无状态的，在任何实例故障情况下，您会失去其中所有数据。但是，它是免费且更快的，因为实例卷绑定到运行VM的物理服务器上。

- mezi

3

如果你是新手并且无意间来到这里：

目前，快速入门部分中的所有AMI都是EBS支持的。

此外，在官方文档中有一个很好的解释，介绍了EBS和Instance store之间的区别。

这张图片基本上概括了一切：

- Aishwat Singh

0

如果您运行多个实例并将AWS实例的计划服务分配为避免意外费用中的优先级之一，我建议不要使用实例存储。

根据EBS卷的文档和j2d3和Siddharth Sharma的回答，实例存储可以一直运行，但不能被停止。这意味着该服务无法通过自动启动/停止或实例恢复进行调度。

此外，对于这种方案，使用EBS Backed在Elastic Beanstalk上也没有好处，因为它旨在确保您需要的所有资源都持续运行。它将始终自动重新启动任何停止的服务。

回顾其余部分，在使用VPC、EBS和ELB增加到EC2-Classic的总费用中，带有{{link11:ELB的EC2-VPC}}通常是最佳选择，与EC2-Classic不同，停止的实例保留其关联的弹性IP地址，并且EBS卷会自动存储。

总结，针对您问题的主要部分：

看起来 EBS 更加有用（停止、启动、持久化 + 速度更快），而成本差异相对较小……?

答案是是的，但如果您的实例是基于 EBS 的，则可以将其停止。它将保留在您的帐户中，您不会为此付费。只会收取卷的费用，但是EBS 按小时计费。您还可以考虑，在所有可用类型中，您可以灵活地调整 EBS 卷大小。

除了Eric已经列出的好处之外，还应该注意在成本方面S3可能比EBS更便宜或更贵。如果您始终在同一平台和应用程序架构中运行两种类型的实例，那么我同意成本上相差很小。

然而，如果有场景在低成本服务上运行应用程序，则可以通过管道或 Lambda 在短时间内（<1小时/天）提取所有未处理的任务并将它们转移到 VPC/EBS，而这是使用实例存储时不可能做到的，那就是另一回事了。

- eQ19

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eric J. · Accepted Answer

底线是，你几乎总是应该使用EBS支持的实例。

以下是原因：

可以设置EBS支持的实例，这样它们就不能通过API意外终止。
EBS支持的实例可以在您不使用它们时停止，并在需要时恢复（就像暂停虚拟PC一样），至少根据我的使用模式，节省的钱比我花费在几十GB的EBS存储上更多。
当EBS支持的实例崩溃时，它们不会失去其实例存储（并非所有用户都需要，但可以加快恢复速度）
您可以动态调整EBS实例存储。
您可以将EBS实例存储转移到全新的实例（如果Amazon上运行的硬件出现故障或死机，则非常有用）
启动EBS支持的实例速度更快，因为不必从S3获取映像。
如果EBS支持的实例所在的硬件计划维护, 停止和重新启动实例会自动迁移到新硬件。我还能够通过强制停止实例并再次启动它，在故障硬件上移动EBS支持的实例（在故障硬件上可能会有所不同）。

我是Amazon的重度用户，并在技术退出beta版后立即将所有实例切换到EBS支持的存储。我对结果非常满意。

EBS仍然可能会失败 - 不是万无一失的解决方案。

请注意，任何基于云的基础设施都可能随时发生故障。因此，请合理规划您的基础设施。虽然受EBS支持的实例与临时存储实例相比具有一定的耐久性，但它们也可能会失败。最好准备一个AMI，以便在任何可用区域根据需要启动新实例，备份重要数据（例如数据库），如果预算允许，则运行多个服务器实例以进行负载均衡和冗余（最好在多个可用区域中）。 什么情况下不使用 在某些时候，使用Instance Store实例可以更便宜地实现更快的IO。曾经有过这样的时间。现在有许多适应各种需求的EBS存储选项。随着技术变化，这些选项及其价格不断演变。如果您拥有大量真正可以丢弃的实例（它们如果消失了不会对您的业务产生太大影响），则需要考虑成本和性能之间的平衡。受EBS支持的实例也可能在任何时间点死亡，但我的实际经验是EBS更加耐用。