EBS与实例存储的好处(反之亦然)

时间:2010-09-02 19:29:00

标签: amazon-ec2 amazon-web-services amazon-ebs

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

11 个答案:

答案 0 :(得分:286)

最重要的是,你应该几乎总是使用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更耐用。

答案 1 :(得分:66)

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运行。

答案 2 :(得分:40)

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

答案 3 :(得分:16)

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

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

答案 4 :(得分:16)

EC2"硬件"

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

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

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

Amazon Web Services为EC2实例提供两种类型的根设备:" EBS支持"和"实例店"。

"实例商店"实例

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

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

" EBS后援"实例

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

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

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

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

但虚拟机的硬盘怎么样?

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

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

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

答案 5 :(得分:15)

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

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

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

答案 6 :(得分:12)

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

  

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

强调我的。

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

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

答案 7 :(得分:7)

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

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

实例存储是:

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

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

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

答案 8 :(得分:3)

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

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

答案 9 :(得分:1)

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

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

enter image description here

另外,official doc EBS 实例商店

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

&安培;这个图像几乎总结了它 enter image description here

答案 10 :(得分:0)

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

  

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

此外,对于这种方案,在 EBS Backed 上使用 Elastic Beanstalk 也没有任何好处,因为它旨在确保所有您需要的资源是keep running。它将始终自动重新启动您停止的任何服务。 enter image description here 在使用添加到all the restVPCEBSELB 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 typesResize the EBS VolumeEric

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

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