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兼容的混合云方式。