我不太清楚在亚马逊EC2实例上,使用EBS和instance-store会带来哪些好处。如果说有什么区别的话,似乎EBS更加有用(可以停止、启动、保留数据以及速度更快),而且成本的差距也不大。此外,现在是否有任何指标表明更多的人正在使用EBS,考虑到它还比较新?
我不太清楚在亚马逊EC2实例上,使用EBS和instance-store会带来哪些好处。如果说有什么区别的话,似乎EBS更加有用(可以停止、启动、保留数据以及速度更快),而且成本的差距也不大。此外,现在是否有任何指标表明更多的人正在使用EBS,考虑到它还比较新?
我们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支持的实例没有任何好处。我宁愿增加一分钟的引导时间,也不想冒险使用潜在的单点故障。
我们喜欢使用实例存储。这迫使我们使我们的实例完全可回收,我们可以轻松自动化从给定的AMI开始构建服务器的过程。这也意味着我们可以轻松更换AMI。此外,EBS仍然偶尔存在性能问题。
Eric已经说得很好了。我们 (Bitnami) 是一个流行的提供免费 AMI 的服务提供商,针对常见应用程序和开发框架 (PHP、Joomla、Drupal 等)。我可以告诉你,EBS 支持的 AMI 比 S3 支持的使用更普遍。一般来说,S3 支持的实例用于分布式、有时限的任务 (例如大规模数据处理),其中如果一个机器失败,就会简单地启动另一个机器。 EBS 支持的 AMI 常用于“传统”的服务器任务,例如 Web 或数据库服务器,这些服务器需要在本地保留状态,因此需要在崩溃时使数据可用。
我没有看到提到的一个方面是,您可以在运行 EBS 支持的实例时拍摄快照,从而有效地获得成本效益高的基础设施备份。(快照是基于块的,增量更新)
我在上一份工作中也经历了和Eric完全相同的经历。现在在我的新工作中,我正在执行与上一份工作相同的过程……重新构建所有基于EBS支持的实例的AMI,并且可能是32位机器(更便宜,但无法在32位和64位机器上使用相同的AMI)。
基于EBS支持的实例启动速度足够快,您可以开始使用Amazon AutoScaling API,该API允许您使用CloudWatch指标触发启动额外实例并将其注册到ELB(弹性负载均衡器),并在不再需要时关闭它们。
这种动态自动缩放是AWS的关键 - 这是IT基础设施中真正节省成本的方法。使用旧的s3“InstanceStore”支持的实例几乎不可能正确地进行自动缩放。
我刚开始使用EC2,还不是专家,但Amazon的官方文档说:
对于临时数据,我们建议您使用本地实例存储; 对于需要更高耐久性的数据,我们建议使用Amazon EBS卷或将数据备份到Amazon S3。
以上为我的强调。
与 Web 托管相比,我更多地进行数据分析,因此持久性对我来说并不那么重要。鉴于亚马逊本身所做出的区别,我不会认为EBS适合每个人。
在我使用过两者之后,我会记得再发表评论。
EBS就像虚拟机的虚拟磁盘:
实例存储:
大多数人选择使用EBS支持的实例,因为它是有状态的。这是更安全的,因为你在其中运行和安装的所有内容都将在停止/启动或任何实例故障情况下保留。
实例存储是无状态的,在任何实例故障情况下,您会失去其中所有数据。但是,它是免费且更快的,因为实例卷绑定到运行VM的物理服务器上。
如果您运行多个实例并将AWS实例的计划服务分配为避免意外费用中的优先级之一,我建议不要使用实例存储。
根据EBS卷的文档和j2d3和Siddharth Sharma的回答,实例存储可以一直运行,但不能被停止。这意味着该服务无法通过自动启动/停止或实例恢复进行调度。总结,针对您问题的主要部分:
看起来 EBS 更加有用(停止、启动、持久化 + 速度更快),而成本差异相对较小……?
答案是是的,但如果您的实例是基于 EBS 的,则可以将其停止。它将保留在您的帐户中,您不会为此付费。只会收取卷的费用,但是EBS 按小时计费。您还可以考虑,在所有可用类型中,您可以灵活地调整 EBS 卷大小。
除了Eric已经列出的好处之外,还应该注意在成本方面S3可能比EBS更便宜或更贵。如果您始终在同一平台和应用程序架构中运行两种类型的实例,那么我同意成本上相差很小。然而,如果有场景在低成本服务上运行应用程序,则可以通过 管道 或 Lambda 在短时间内(<1小时/天)提取所有未处理的任务并将它们转移到 VPC/EBS,而这是使用实例存储时不可能做到的,那就是另一回事了。