EBS和S3的区别

Posted 2020-10-11

---

最大的区别是：EBS是块存储，S3是对象存储。EBS仅能与EC2实例结合使用。你可以把EBS想象成EC2的硬盘，如果EC2的实例挂掉，那么用来建立EC2的那个EBS卷也会挂掉（想像一下你装了windows然后把windows格了，那么C盘的内容就没了，当然，还有一个EBS保护的选项，打开之后即使EC2挂了，这个EBS卷的内容也都还在），而别的EBS卷，即使挂载到EC2上，它会仍然存在，而S3无此限制，你可以把S3就想象成一个网盘...收费：EBS的卷存储按每月预置的GB量计费，无论使用与否，而S3按照实际使用GB量收费；请求：EBS按卷的I/O请求进行收费，S3对GET及所有其他请求按次数进行收费，对于小文件S3的请求费用甚至会高于传输费用；数据传出：两者数据传出至Internet的费用目前一致；S3的数据存储相对更为可靠，S3通过冗余方式将数据同步到多个设备，而EBS卷的持久性取决于您的卷大小和自上次快照后数据更新的比例，因此EBS提高持久性需定期快照至S3

---

AWS　EBS与AWS　S3均为AWS提供的数据存储服务，

　　两者的异同在于：
　　①EBS仅能与EC2实例结合使用，而S3无此限制；
　　②数据传出：两者数据传出至Internet的费用目前一致；
　　③S3可与CloudFront(CDN)结合使用，在某些情况下提高访问速度；
　　④存储：EBS的卷存储按每月预置的GB量计费，无论使用与否，而S3按照实际使用GB量收费；
　　⑤请求：EBS按卷的I/O请求进行收费，S3对GET及所有其他请求按次数进行收费，对于小文件
　　S3的请求费用甚至会高于传输费用；
　　⑥S3的数据存储相对更为可靠，S3通过冗余方式将数据同步到多个设备，而EBS卷的持久性取
　　决于您的卷大小和自上次快照后数据更新的比例，因此EBS提高持久性需定期快照至S3；

---

基于AWS用户的反馈，列出了（亚马逊弹性计算云，的核心及基础，提供非常弹性的实例管理）的五项问题，它们不仅不好解决而且还会迫使用户另寻它物。
　　共享EBS卷EBS（ElasticBlockStore，弹性块存储）为提供永久存储。
　　由于去除了对速度缓慢的亚马逊S3（另一个云计算产品）的依赖，它在2009年一经推出就得到了高度评价。
　　许多工程师只要加载一个AmazonEC2实例，就会马上附加一个EBS卷，并将长期需要的数据移动过去。
　　然而四年过去了，EBS需求最旺盛的功能——将同一个EBS卷附加到多个EC2实例上还尚未实现。
　　AWS鼓励在一个loadbalancer（负载平衡器）后台运行多个实例来获得最佳的性能。
　　然而仅在一个EC2实例上运行应用不是个好主意。
　　大多数和媒体驱动的应用程序依赖于共享的存储。
　　当这些系统都迁移到AWS并放在一个ELB（ElasticLoadBalancing，弹性）之后，没有简单的策略使得在运行相同应用程序的EC2实例之间来共享内容。

---

原文连接：http://sysadmin.blog.51cto.com/83876/1071122

在这篇文章我们解决了几个问题：

1、amazon的存储产品比较；介绍不同存储的使用场景分析；

2、s3-hosted images 和EBS-backed images的比较分析；

3、持久化存储和非持久存储在amazon中的体现；

一、EBS和S3概述

在正式讨论不同的存储服务之前，我们大概了解一下Amazon提供存储产品S3和EBS。

1、  EBS（Elastic Block Storage）产品首页的概述。

     EBS提供块级别的存储卷给EC2 实例使用，EBS卷通过网络连接，独立于虚拟机实例生命周期。EBS提供高可用，高可靠，可预期的存储卷给正在运行的虚拟机，并呈现为一个虚拟机设备。EBS尤其适合于数据库应用、文件系统应用，或要求访问裸块级别存储的应用。

2、S3 （Simple Storage Service）产品首页概述

    S3是一个云存储（相应地EBS成为云硬盘也挺合适）。S3被设计成面向开发者易于进行规模扩展的产品。S3提供简单的web服务接口，可实现通过网络在任何时间、任何地点存储和获取任何数据。他给所有开发者使用与amazon用于运行自己的网站相同等级的可扩展、可靠、安全、快速、廉价的基础设施。这个服务的目标是最大化可扩展性优势，同时将这些优势交付给开发者。

关于产品的定义，可以从这些地方去查看：http://aws.amazon.com/ebs/

二、EBS vs S3 vs Instance Store

    我尝试着给Amazon提供的存储服务进行分类，首先分为两大类，一是块设备存储服务，二是对象存储服务。其中块设备存储服务包括本地存储服务和EBS 存储；对象存储服务是S3。AWS的Storage & Content Delivery产品列表上，你会发现S3是一项单独的服务，而EBS不在其中，EBS是基于EC2的一项子服务。两者服务对象不是同一级的。  下面对不同的存储做了简单对比。

	EBS	S3
服务对象	系统管理员	系统管理员/最终用户
服务场景	1、作为虚拟机硬盘，在虚拟机看来就像EBS就像本地的硬盘；当EC2实例失效时，EBS卷可以自动解除与该实例的关联，从而可以关联到新的实例。 2、存储EBS-backed Images。	1、存放S3-hosted Images。 2、用户可通过Http/REST API 存取文件。典型应用：网站可将静态文件存放到S3中，通过CDN网络分发到不同的区域中以提升性能； 2、可作为虚拟机EBS卷的backup &snapshot ；  快照：第一个快照是全量快照，而后的都是增量快照。一般使用快照作为新卷的起始点，所以当数据遭到破坏时就能通过回滚到某个快照来恢复数据。
连接类型	通过网络连接	通过网络连接。
服务机制	块设备，可格式化为任何OS可以识别的格式；	对象存储，桶--对象二级结构。无需在其上建文件系统，对象存储包括元数据、数据内容、数据属性。
Key features	Data availability from replication across an Availability Zone Data persistence independent of the life of the instance The ability to create snapshots and incremental backups
不足	多用户共享EBS存储带宽，服务质量（IO访问的性能）会有波动。 单个文件<1T。	单个文件<5G，高清视频搞不定。
优点	1、EBS提供了持久化的、具有独立于主机的生命周期的、高可用的块存储设备，在这一设备上可以创建支持POSIX语义的本地文件系统（或是Windows本地文件系统）。 2、可针对EBS卷做snapshot，EBS故障后可通过snapshot恢复EBS卷。	面向最终用户，可直接当成云网盘来使用。
容错设计	在不同的地方存放多份数据。	在不同的地方存放多份数据。

    物理宿主机使用的本地存储称为Instance Store，这个存储的典型特征是非持久。计划内或计划外的重启不会导致数据的丢失。当instance出现下述三种情况时，存储在instance store上的临时数据将会被清除。

1、Failure of an underlying drive （底层驱动出现故障）

2、Stopping an Amazon EBS-backed instance （使用EBS-backed作为root device的实例Stop时。）

3、Terminating an instance （虚拟机实例注销）

instance Store和instance的关系如下图所示，Host computer指的就是物理宿主机。

   在申请虚拟机时，如果你看到自己在使用ephemeral 存储就是指Instance Store这个非持久存储。Amazon为啥这样设计instance Store呢？其实你就要理解一下亚马逊的设计原则。当你关闭vm不使用，如果保留数据，那么还是占有资源，而Amazon的计费模式是关闭虚拟机就不计费的。所以亚马逊默认你关机就所有数据都丢失。

 三、s3-hosted images 和EBS-backed images的比较分析；

1、在EC2中创建虚拟机instance时，会提示选择Images的类型，有s3-hosted images和EBS-backed images两种,通俗地讲就是虚拟机镜像是存在S3或存在EBS两类。如果你使用了s3-Hosted images，Images需从S3存储copy到instance Store， Amazon通常会在物理宿主机缓存好被频繁使用的Image，因此很多时候你感觉不到启动S3-hosted images虚拟机因copy带来的延迟。完成虚拟机镜像copy后启动EC2 instance。

2、使用EBS-backed images的虚拟机启动要快得多，当然这不是最重要的，最重要的是当你关闭虚拟机后，虚拟机的数据还在EBS上，就如同你在使用自己的电脑一样，即使你关机了，数据仍在硬盘中。当然了，为此，你得支付更多的银子。

参考文档：

http://aws.amazon.com/ec2/faqs/#What_is_the_difference_between_using_the_local_instance_store_and_Amazon_Elastic_Block_storage_for_the_root_device

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/InstanceStorage.html

http://aws.amazon.com/documentation/

---

新闻

社交监测平台awe.sm的联合创始人Laurie发布了博客，对在AWS的使用体验做了总结，结论是喜忧参半。喜的是AWS让他们的平台运行更加简单，而且降低运营成本。但与此同时，EC2故障频发，EBS性能低下，而高性能EBS价格贵的离谱，Laurie总结出了一套高可用、高性能的运营经验。CSDN对其进行了摘译。

【CSDN编译】awe.sm从创立之初就采用了AWS平台，过去3年我们体验了AWS的优美和不足，并总结出一套最佳实践。

不夸张的说，AWS彻底改变了科技创业公司的经济运行模式。没有人意识到有多少公司正在使用AWS的EC2，直到它发生宕机“真相”才浮出水面。每个人使用AWS都可以从根本上实现非常简单的运行软件的方式，并节省大量硬件投资。

图：AWS的优势和缺陷让人既爱又恨

EC2是一种运行软件新的方式

首先，也是最重要的，EC2绝不仅仅是虚拟托管服务器。或者说，它就像雇佣了部分系统和网络管理员：代替一名昂贵的管理员，实现自动管理，你只需要为每个虚拟机支付一点点费用而已，并将产生的问题汇总。供电、网络拓扑、硬件成本、供应商选择以及网络存储系统——在2004年以前这些你都需要考虑。而通过AWS和其它竞争对手的努力，你不用再考虑这些，至少不用考虑这么多。

毫无疑问，弹性是使用EC2最大的优势和特色，我们只需要约5分钟就能建立一个虚拟机，这将让我们有更高的灵活性：

• 我们可以在新的硬件上进行大规模升级。当我们进行大规模升级时，可以完全建立全新的硬件以及设置和依赖关系，并把它们装入负载均衡器，然后重新设置负载均衡器即可。当然最后要把之前运行的虚拟机关机。你需要2倍的硬件来进行升级切换，但只需要使用24小时，绝对的廉价和简单。

• 对于一些非关键系统的备灾计划（这些非关键系统最长允许宕机1个小时），我们只要监测到宕机的虚拟机，然后新启动一个虚拟机然后做系统还原即可。

• 依照负载进行扩容绝对好过事先的判断：当监控到负载很高时，你可以开启额外的虚拟机，及时应对高负载。

• 我们根本不担心对虚拟机数量进行计算：我们总有用不完的虚拟机可供启动，如果我们出错了，可以很容易的关闭或者启动虚拟机。这样的硬件迭代就是AWS最棒的功能。

EC2为初创企业带来强大的财务支持

AWS的最明显的成本优势是硬件零安装成本：你使用与亚马逊相同的帐户从互联网上订购，按一下按钮，并启动服务器，按小时支付。你只需支付正在运行的硬件，以及实际使用的存储，这让你的启动成本达到最小。同时，这将鼓励在硬件层面实验：在现有的资源上增加10倍，运行负载测试，然后关闭这些增加的虚拟机，直到你真正需要它们。这不仅仅方便，而且是革命性的。

AWS能够降低运营成本。截至到2012年，我们的公司已经运营了2年多，我们甚至没有专业的运维人员。不过我们依然有一名的全职的运维人员负责管理数以百计的虚拟机，这是相当高的效率。我们根本不用考虑供电、网络等等。

当然，AWS并非完美，他的价格超过竞争对手不少。但借助定期的降价，10月份的18%，今年3月的10%。最后，如果长期使用，你可以预先支付费用，并获得最多50%的折扣。

但是EC2有一些问题

EC2有严重的性能和可靠性问题，重要的是要做到心中有数，并提前做出应对计划。

首先，AWS那臭名昭著的“可用地区”模式，这些分布在不同地区的物理设备彼此分离，包括网络、供电等。关于“可用地区”我们有几条非常重要的经验：

• 虚拟设备不可能像硬件设备那样长久：根据我们在过去3年的观察，虚拟机的平均生命周期约为200天。这之后的“退休”将经历非常高的风险，AWS的“退休机制”根本不可控：有些时候提前10天通知你虚拟机将被关闭；有时候虚拟机已经关闭2小时后，才收到通知邮件。频繁的硬件更迭并不是太大的问题，毕竟你可以很轻松的启动新的虚拟机来替代，但重要的是你应该意识到，要尽早进行自动部署，以减少更换虚拟机所需的时间。

• 你需要是在一个以上的区域进行部署，并建立冗余。这一直是我们的经验，你可能失去整个区域，而不是一个虚拟机。如果你的系统有单点故障，你不能从故障虚拟机中获取备份或设置信息，如果整个区域不可用，你甚至连这个虚拟机都看不到，更别提恢复数据了。

• 多区域故障也可能发生，因此，如果你能负担得起，也要部署多个区域。美国东部是故障频发的地区（因为历史最长，价格最便宜），2012年6月、2012年3月，以及最引人注目故障是在2011年。AWS的不稳定性似乎有相同的根本原因。

为了保持较高的正常运行时间 我们已经不再相信EBS

这就是我们的经验和亚马逊的市场建议最冲突的地方。AWS期望EBS是使用EC2的基础：AWS希望你将所有的数据托管在EBS卷上，一旦实例故障，你能立刻将EBS卷迁移到新的硬件上，这一过程很轻松。AWS还希望你使用EBS快照来对数据库备份并恢复。AWS同样希望你在EBS卷上运行操作系统，即EBS备份实例。但根据我们的经验，EBS有几大挑战：

• EBS卷的I/O性能太差。虚拟化的硬件的I/O性能显然不如纯粹的硬件，但我们的经验却相反，EBS卷的性能远不如本地存储（AWS称之为“短暂存储”）。EBS卷本质上是网络存储，所以性能不会非常好。AWS试图游说用户使用定制IOPS，这是一种更高性能的EBS卷，但它的价格会拒你千里之外。

• EBS基于地区的可用性。基于我们的经验，EBS有两个特性：所有的卷可用，或都不可用。在前文提到的3起地区性的EC2事故中，2起是由EBS故障从一个地区扩展到其它地区引起的。如果你的故障恢复计划建立在EBS卷基础上，当遇到EBS故障引起的宕机，你就要倒大霉了。悲催的是，这种情况我们已经遇到好几次了。

• 基于Ubuntu的EBS故障十分严重，因为EBS卷实际上通过网络驱动伪装成块设备，这与Linux系统不兼容。我们曾经遇到由此引发的严重事故，EBS卷故障导致整个虚拟机锁定，无法迁移，甚至对任何磁盘需求都不予响应。

因此，大约半年前开始，我们完全放弃了EBS。我们付出了相当大的代价（主要是围绕如何执行备份和恢复系统）。截至到目前看，这么做绝对值得。

请注意：其他AWS服务依赖于EBS

由于一些的AWS增值服务是建立在EBS中，当EBS故障时，他们也随即失效，包括弹性负载均衡ELB、关系数据库RDS、EB（Elastic Beanstalk）以及其它。在我们的经验中，EBS总是位于故障的中心。所以，如果EBS发生故障，你需要迅速的将流量转换到其它地区，但很遗憾，你根本无法完成切换，因为负载均衡就运行在EBS上。同时，你也不能启动新的设备，因为AWS提供的控制台服务也是运行在EBS上的。所以，我们爱EC2（以及真的真的爱S3），但我们不用AWS提供的任何附加服务。这么做的好处是，我们可以相对简单地切换到其他托管服务提供商，而不是密切的锁定在AWS。

吸取的经验教训

如果我们明天再次启动awe.sm，我会不加思索的继续使用AWS。对于一个小团队而言，你只有很少的预算，还需要迅速作出反应，AWS就像一部高性能的全自动相机。Joyent、Rackspace等IaaS提供商正加紧追赶，我们期待着与他们的合作。当我们从100多台虚拟机增长到1000台后，必须引入更多的供应商，或者使用Carpathia的与AWS兼容的混合云方式。（编译/包研 责编/仲浩）