AWS EC2高可用、高性能的运营经验

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

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

不夸张的说,AWS彻底改变了科技创业公司的经济运行模式。没有人意识到有多少公司正在使用AWS的EC2,直到它发生宕机“真相”才浮出水面。每个人使用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兼容的混合云方式。

你可能感兴趣的:(AWS EC2高可用、高性能的运营经验)