Amazon EC2是否适用于面向公众的持久性网站？

Question

我的公司即将在SharePoint中编写一个面向公众的新网站（因此Windows Server 2008 RC2，SQL Server 2008 RC2等），我们正在考虑使用Amazon EC2来托管它。我已经阅读并被告知实例可能会消失（通常是通过用户错误，但也是批量），所以我怀疑EC2对我们来说是最好的想法。

我已经在亚马逊AWS网站上做过研究，但必须承认所使用的大部分术语都令人困惑，谷歌搜索我的问题经常把我带到这里，所以我想我也会在这里问我的问题并看看是否有人可以告诉我。

1）我们的网站尽可能向公众开放至关重要（通常适用99.9％的上网时间）。 Amazon EC2服务水平协议承诺的可用性为99.95％，这很好，但如果我们达到0.05％的情况会怎样？我们的E2实例会丢失吗？这些可以恢复吗？如果是这样，我们需要做些什么才能确保我们恢复到不太旧版本的网站？

2）我读过有关亚马逊弹性块存储（EBS）的信息，以及它是如何独立于实例的生命周期而持久化的。如果我理解正确，EBS就像拥有一个硬盘驱动器，所以如果实例丢失，我们可以使用我们的EBS启动一个新实例来恢复最新版本，而如果实例丢失则“本地实例存储”将丢失同样。是吗？

3）“预留实例”是否更稳定？即他们不太可能消失？如果他们仍然消失，他们提供什么恢复福利，如果有的话？

我知道这些问题有点模糊，但希望你能够从基本信息中提供一个新手 - 足以让我指出正确的方向，至少进行更深入的研究。

非常感谢。

凯文

Answer 1

我们依赖AWS来支持我们的网络服务器。我不会用别的东西。它们具有高度可扩展性，易于配置且具有荒谬的正常运行时间。我从未经历过他们的停工期。我们和他们在一起已经两年了。

预留实例更便宜。如果您计划在一段时间内使用该实例，请获取它们。这只是一个成本/预算问题。

从未听说过有人失去EC2实例。

对EBS知之甚少，但S3是备份数据的好方法。

HTH

编辑：

遇到了一些可能有帮助的链接。欢呼声。

http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html

http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

Answer 2

AWS的主要设计目标之一是制定容错服务 - 即可以从故障中恢复的服务。也就是说，他们设计所有服务时假设某些事情会在某些时候以某种方式失败，但会有裁员和其他机制来恢复从那些不可避免的失败中解脱出来。

对于S3和SimpleDB等存储服务，主要通过在多个数据中心的多个节点（计算机）上复制数据来实现。因此，当一个节点遇到硬件故障或一个数据中心遇到断电时，没有真正的停机时间，因为副本仍然可以为请求提供服务。作为消费者，您甚至不知道向下节点或数据中心。

EC2的设计工作方式与此类似，但它并不像S3和SimpleDB那样封装，因此您需要自己规划一些工作。例如，如果您需要具有有保证的正常运行时间和可用性的Web服务，您将需要查看AWS ELB（Elastic Load Balancing）服务。这样，如果实例关闭，请求将自动路由到其他健康实例。对于您的数据，您可以将其存储在具有内置冗余的其他AWS服务（如S3和SimpleDB和EBS）中，也可以使用类似的冗余技术构建自己的解决方案。

Answer 3

当我们发现以下情况时，SLA无关：

1. 实例和EBS卷DID丢失

2. 亚马逊需要2天以上的时间才能从灾难中恢复过来，甚至还没有达到最大程度

我们是幸运儿，在不到两天的时间内重新站起来。其他公司陷入困境，没有恢复选择。

亚马逊推荐什么？ “不要相信我们的可靠性。在不同地区支付2到3份系统副本，然后你就会安全”。

可在此处找到更多信息：

http://www.zdnet.com/blog/saas/lightning-strike-zaps-ec2-ireland/1382

Answer 4

tldr：如果你知道自己在做什么，那么AWS是非常可靠的，如果你不知道，这是一个坏主意。

由于您不熟悉这些术语，因此非常快速的词汇表： AZ - 可用区，每个区域有几个可用区（例如爱尔兰的3个）。它们是物理隔离的数据中心，具有不同的电网，洪泛平原等。但具有内部网络质量速度连接。有可能AZ甚至可能在某些时候变得不可用，我不认为某个地区的所有AZ都曾经过一段时间。但

EBS / Instance Store - 这是实例可用的两种主要存储类型。描述它们的最佳方式是Instance Store相当于你通过sata插入主板的硬盘 - 它非常快。但是如果您关闭实例（或者如果主板出现故障）并希望立即启动另一块主板会发生什么？ （亚马逊完全隐藏了物理硬件设置）显然你不会等待工程师从一个服务器拔出驱动器到另一个服务器，所以他们甚至不提供这个。实例存储是快速但临时的并且与物理机器绑定不要存储任何重要的东西。然后，EBS可以替代它是一个非常低延迟的网络驱动器，任何服务器都可以连接到它，就好像它是本地的一样。你关闭服务器，改变大小并重新启动数据中心另一端的完全不同的服务器（再次隐藏物理内容），无论你的ebs没有去过任何地方（默认情况下它们也是多个）物理光盘）。

商品云硬件 - 我对所有'云硬件始终失败 - 的真正风险和不可靠'的解释是，硬件不像管理数据中心中的企业级组件那样可靠。这并不意味着它不可靠，它只是意味着您应该将失败作为设计的一个选项。

在谈论SLA时要注意的第一件非常重要的事情是，亚马逊非常清楚地表明，如果一个或多个AZ出现故障，SLA仅适用。因此，如果您不了解他们的服务如何工作，并且只在一个AZ中构建一个服务器而发电机或路由器发生故障，那就是您自己的错误。

至于恢复，这取决于 - 您的整个应用程序状态是否存储在一台服务器上 - 如果是，请不要打扰云。但是，如果您可以在多个服务器上群集您的状态，请将其存储在RDS或其他一些持久数据库中。或者，如果您的内容不经常更改，您可以使用定期副本到s3存储，您会没事的。您的故障策略（按优先顺序）可以是群集，故障转移或自动修复。对于第一个，您拥有群集服务器共享状态 - 如果丢失服务器或AZ则无关紧要。对于第二个，您只有一个实时服务器，但如果它发生故障，您将使用相同的内容进行故障转移。最后通过自动修复有两种可能的情况 - 如果您的数据仅在一个EBS驱动器上，您可以使用相同的驱动器启动另一个实例并继续。但是如果EBS驱动器或AZ出现故障，您需要准备好s3中的一些快照，以便全新的实例可以复制并启动。

预留实例不再可靠 - 它们是相同的硬件，你只是签订合同说我将拥有x年的x机器。这允许aws更好地计划，这对你来说更便宜。