是否建议将 Amazon EC2 用于持久的面向公众的网站？

Posted 2023-03-04

【中文标题】是否建议将 Amazon EC2 用于持久的面向公众的网站？

【英文标题】：Is Amazon EC2 recommended for a persistent public facing website?

【发布时间】：2011-08-13 10:44:15

【问题描述】：

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

我在亚马逊 AWS 网站上进行过研究，但必须承认，使用的大多数术语都令人困惑，谷歌搜索我的问题经常把我带到这里，所以我想我也应该在这里问我的问题，看看人们是否可以给我建议。

1) 让公众尽可能多地访问我们的网站至关重要（通常 99.9% 的正常运行时间适用）。 Amazon EC2 服务水平协议承诺 99.95% 的可用性，这很好，但如果我们达到 0.05% 的情况会发生什么？我们的 E2 实例会丢失吗？这些可以恢复吗？如果是这样，我们需要做些什么来确保我们恢复到不太旧的网站版本？

2) 我了解了 Amazon Elastic Block Store (EBS)，以及它如何独立于实例的生命周期而持续存在。如果我理解正确，EBS 就像有一个硬盘驱动器，所以如果实例丢失，我们可以使用我们的 EBS 启动一个新实例来恢复最新版本，而如果实例丢失，“本地实例存储”将丢失也是。对吗？

3) “保留实例”是更稳定的选择吗？即它们消失的可能性较小吗？如果它们仍然消失，它们会提供哪些恢复好处（如果有的话）？

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

非常感谢。

凯文

【问题讨论】：

预留实例对正常运行时间或稳定性没有优势。他们所做的只是支付更少的费用，但预先支付。如果正常运行时间小于 99.95，您的实例不会丢失，但如果任何其他机器不可用，情况就会如此。我们在 EC2 上托管我们的公司网站，它运行良好。

谢谢你，乔。我在保留实例上阅读了相当多的内容，但无法获得仅此价格的更多内容，而且似乎没有。很高兴知道:)

Amazon EC2 很棒。我当然可以做你描述的。由于您使用的是 Microsoft 产品，因此您可能还会考虑使用 Microsoft 的云 Azure。

【参考方案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

【讨论】：

关于您的实例丢失的注释。您应该将您的应用程序保持在源代码控制中，并定期备份您的生产数据。如果没有备份和确定性部署脚本，即使是最好、最可靠的解决方案也无法让您高枕无忧。

感谢荷马的信息。我的老板听说过实例是列表，尽管环顾四周，这似乎很少见，而且经常是用户错误。很高兴听到您在 2 年内没有看到任何此类问题。关于备份：您是否拍摄 EC2 实例的快照，如果有，您将它们存储在哪里？

不，我们没有。我们不在文件系统上存储任何用户数据。我们只将数据存储在亚马逊也托管的数据库中。我们只为简单的网络服务器部署创建图像。我们的应用程序代码都在源代码控制中，并且可以轻松部署到任何服务器，因为我们有一个构建脚本。

好的，很好。再次感谢您的帮助。

@QMKevin - 找到一些您可能有兴趣阅读的链接。请参阅上面的修改。

【参考方案2】：

AWS 的主要设计目标之一是提供容错服务，即可以从故障中恢复的服务。也就是说，他们在设计所有服务时都假设某事会在某些时候以某种方式发生故障，但是将会有冗余和其他机制来恢复避免那些不可避免的失败。

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

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

【讨论】：

感谢 C. Dragon 的解释。我将更多地研究 AWS ELB，因为负载平衡服务器可能对我们非常有用。我听说过 SharePoint 2010，如果用于高流量，可能需要每 3 个月左右重新启动一次，因此负载平衡系统在这种情况下会很有用。不过，我想我想了解更多有关备份的信息，尤其是异地（或在本例中为非云）备份的想法。理想情况下，我希望每天备份整个网站，这样如果发生最坏的情况，我们只需使用该备份重新启动一个新实例……如果这有意义的话。

【参考方案3】：

当我们发现以下情况时，SLA 等于没有：

实例和 EBS 卷确实丢失了

亚马逊需要超过 2 天的时间才能从灾难中恢复，甚至还没有完全恢复

我们很幸运，在不到 2 天的时间内就重新站起来了。其他公司陷入无法恢复的困境。

亚马逊推荐什么？ “不要相信我们的可靠性。在不同地区再购买 2 或 3 份系统副本，您就安全了。”

更多信息可以在这里找到：

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

【参考方案4】：

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

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

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

商品云硬件 - 我对所有“云硬件总是失败 - 它确实有风险且不可靠”的解释是，是的，AWS 硬件不如托管数据中心中的企业级组件可靠。这并不意味着它不可靠，它只是意味着你应该将失败作为一个选项加入到你的设计中。

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

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

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