我不清楚我在Amazon EC2上为我的实例从EBS和实例存储中获得了什么好处.如果有的话,似乎EBS在成本相对较小的差异方面更有用(停止,开始,持续+更好的速度)......？此外,是否有更多人正在使用EBS,因为它仍然相对较新？
最重要的是,你应该几乎总是使用EBS支持的实例.
这就是原因
可以设置EBS支持的实例,以便它们不会(意外地)通过API终止.
当您不使用它们时可以停止EBS支持的实例,并在您再次需要它们时重新启动(例如暂停虚拟PC),至少使用我的使用模式可以节省比我在几十GB的EBS存储上花费更多的钱.
EBS支持的实例在崩溃时不会丢失实例存储(不是对所有用户的要求,而是使恢复更快)
您可以动态调整EBS实例存储的大小.
您可以将EBS实例存储转移到一个全新的实例(如果您运行的亚马逊硬件变得不稳定或死亡,这种情况很有用)
启动EBS支持的实例更快,因为不必从S3获取图像.
如果计划维护 EBS支持的实例的硬件,则停止和启动实例会自动迁移到新硬件.我还能够通过强制停止实例并再次启动它来在故障硬件上移动EBS支持的实例(您的里程可能因故障硬件而异).
我是亚马逊的重度用户,一旦技术出现测试版,就将我的所有实例转换为EBS支持的存储.我对结果非常满意.
EBS仍然可能失败 - 而不是银弹
请记住,任何基于云的基础架构都可能随时出现故障.相应地规划基础架构.虽然与临时存储实例相比,EBS支持的实例提供了一定程度的持久性,但它们可能会失败.有一个AMI,您可以根据需要在任何可用区域中启动新实例,备份您的重要数据(例如数据库),如果您的预算允许,运行多个服务器实例以实现负载平衡和冗余(理想情况下在多个可用区域中) ).
什么时候不
在某些时间点,在实例存储实例上实现更快的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)越糟糕,因为实际主机系统上的网络接口在运行在其上的多个VM(=您的EC2实例)之间共享.
你得到的实例越大,当然越好.这里更好意味着理性.
当需要持久性时,我总是建议人们使用类似S3的东西来集中实例.S3是一项非常稳定的服务.然后将您的实例设置自动化到可以启动新服务器的位置,并且它可以自行准备.然后,不需要具有比实例更长寿命的网络存储.
总而言之,我认为EBS支持的实例没有任何好处.我宁愿添加一分钟到bootstrap,然后运行潜在的SPOF.
我们喜欢实例店.它迫使我们使我们的实例完全可循环使用,并且我们可以轻松地自动化在给定AMI上从头开始构建服务器的过程.这也意味着我们可以轻松换掉AMI.此外,EBS仍然不时出现性能问题.
埃里克几乎把它钉了起来.我们(Bitnami)是流行的应用程序和开发框架的免费AMI的流行提供商(PHP,Joomla,Drupal,你明白了).我可以告诉你,EBS支持的AMI比S3支持的更受欢迎.一般来说,我认为s3支持的实例用于分布式,限时工作(例如,大规模数据处理),如果一台机器发生故障,另一台机器就会被简化.EBS支持的AMIS倾向于用于"传统"服务器任务,例如在本地保持状态的Web或数据库服务器,因此需要在崩溃的情况下提供数据.
我没有看到提到的一个方面是,您可以在运行时拍摄EBS支持的实例的快照,从而有效地允许您对基础架构进行非常经济高效的备份(快照是基于块的和增量的)
我在上一个职位上和Eric有过完全相同的经历.现在,在我的新工作中,我将完成我在上一份工作中执行的相同流程...为EBS支持的实例重建所有AMI - 可能还有32位机器(更便宜 - 但不能在32和32上使用相同的AMI) 64台机器).
EBS支持的实例启动速度足够快,您可以开始使用Amazon AutoScaling API,它允许您使用CloudWatch指标触发其他实例的启动并将它们注册到ELB(Elastic Load Balancer),并在以后关闭它们.不再需要.
这种动态自动扩展就像AWS一样 - IT基础架构的真正节省可以发挥作用.使用旧的s3"InstanceStore"支持的实例进行自动缩放几乎是不可能的.
我刚开始使用EC2,所以不是专家,但亚马逊自己的文档说:
我们建议您将本地实例存储用于临时数据,对于需要更高级别持久性的数据,我们建议使用Amazon EBS卷或将数据备份到Amazon S3.
强调我的.
我做的数据分析比网络托管更多,所以持久性对我来说并不像对网站那么重要.鉴于亚马逊本身的区别,我不认为EBS适合所有人.
我会尝试记住在使用两者之后再次称重.
EBS就像VM的虚拟磁盘:
EBS支持的持久实例可以自由启动和停止(节省资金)
可以在任何时间点进行快照,以获得时间点备份
可以从EBS快照创建AMI,因此EBS卷成为新系统的模板
实例存储是:
本地,所以一般更快
非网络,在正常情况下,EBS I/O以网络带宽为代价(EBS优化实例除外,它具有单独的EBS带宽)
每秒IOPS的I/O有限.即使配置的I/O最高也只有几千IOPS
脆弱.实例停止后,您将丢失实例存储中的所有内容.
使用EBS作为后备操作系统分区和永久存储(数据库数据,关键日志,应用程序配置)
将实例存储用于进程内数据,非关键日志和瞬态应用程序状态.示例:外部排序存储,临时文件等
当实例之间有复制时(NoSQL DB,分布式队列/消息系统和带复制的DB),实例存储也可用于性能关键数据
将S3用于系统之间共享的数据:输入数据集和处理结果,或者用于每个系统在运行时使用的静态数据.
将AMI用于预烘焙,可启动的服务器
京公网安备 11010802040832号 | 京ICP备19059560号-6 