Amazon EC2 上的冗余 NFS

Question

我有兴趣在 Amazon EC2 上构建两个具有故障转移功能的容错/冗余 NFS 服务器。我熟悉 DRBD、Heartbeat 等工具/技术。亚马逊是否提供了通过他们的平台实现这一目标的任何特定方式？

一个合适的例子可能是文件保存在一个单独的、冗余的 EBS 上——如果发生故障，一个新实例会自动从预先构建的 AMI 启动，安装 EBS 卷，并无缝转换 IP 地址。

这可能吗？有比亚马逊更好的平台吗？你能给我一个关于我们正在谈论的底层架构的广泛概念吗？

Answer 1

在 AWS 上，将 GlusterFS 与弹性负载均衡器和 Auto Scaling EC2 实例结合使用应该可以达到您的要求。我无法评论任何其他 IaaS。

亚马逊确实提供了实现目标所需的一些东西 - 并允许您实施其余部分。

亚马逊的 EC2 服务器本质上是 VPS——你可以在它们上设置 Heartbeat/Corosync/Pacemaker 等（虽然我上次检查过，你不能在他们的网络上使用广播——你可以使用单播——udpu）。

您提到了亚马逊分别（在某种程度上）提出的两个想法：容错和冗余。

EC2 上没有内置的冗余机制，但根据您的需求，有一些方法可以实现它。

• 从理论上讲，S3 的设计具有多层冗余，并且“旨在为给定年份的对象提供99.999999999% 的耐用性”。他们的 SLA 是每年99.9% 的可用性。如果您想为静态文件采用该路由，您可以使用 s3fuse 作为本地文件系统挂载 S3 存储桶。然而，这相当慢，对于大多数用途（代码、数据库、服务器软件等）来说并不是真正可取的。
• EBS 快照将为您提供 EBS 卷的压缩差异时间点映像。这些非常适合作为备份 - 您可以从快照启动新实例 - 但它们不是真正的冗余。
• 对于任何实际冗余的解决方案，您必须自己设置。针对此问题设计的一种方法是 GlusterFS。您可以将砖设置为分布式、复制或两者兼而有之，并且数据将分布在整个系统中 - 它对单个节点的移除具有弹性，并且它们具有预构建的 AMI，您可以从中启动多个实例来构建一个簇。

另一方面，亚马逊平台更好地提供了容错能力：

• EC2 网络提供多个区域和可用区——（理论上）提供隔离和/或地理上分离的数据中心以避免单点故障
• Amazon 提供对各种实例指标（CPU、网络、磁盘 I/O 等）以及自定义指标的监控（Cloudwatch）。这些可以用作从预先构建的 AMI 启动新实例的触发器，这个过程称为“自动缩放”。
• EC2 具有弹性 IP 地址 - 这些是公共 IP 地址，可以保留并根据需要快速重新映射到另一个实例，从而使您可以在实例出现故障时避免 DNS 传播延迟。
• 最后，Amazon 有弹性负载均衡器——这些应该被设计成避免单点故障，并随着传入流量进行扩展（它们不会受到作为负载均衡器的单个实例设置所受到的相同带宽限制的影响）到）。ELB 能够监控后端实例的“健康状况”，并与自动扩展一起工作以维持适当数量的实例。

除了上述之外，您还可以将自定义参数传递给新启动的实例，或者相当容易地检索有关当前正在运行的实例的信息 - 这可能允许您编写一些设置脚本（当然，AWS 确实有一个 API将让您编写他们提供的所有操作的脚本 - 包括重新映射弹性 IP 地址、启动新实例、分离/附加 EBS 卷等）。

您描述了“文件保存在一个单独的、冗余的 EBS 上......[然后] 安装”。首先，在 EC2 上，一个 EBS 卷一次只能附加到一个实例（因此要将数据复制到它，需要附加 EBS 卷）。由您来维护冗余（您可以设置 EBS 设备的 RAID 阵列，或执行其他任何操作）。但问题是，有时 EBS 卷在实例实际崩溃时不会分离 - 您可以强制分离它们（虽然成功率更高，但不是完美的），并且您可以对 EBS 卷进行快照，即使在使用中（这然后，您可以创建一个新的 EBS 卷并使用它启动 AMI）。不过，最好（恢复时间更短、更灵活等）跨多个实例维护数据副本，而不是跨同一实例上的多个 EBS 卷。