最大的区别是: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兼容的混合云方式。(编译/包研 责编/仲浩)