Amazon EC2 上的冗余 NFS

Question 1

在 AWS 上，使用 GlusterFS 和 Elastic Load Balancer 以及自动扩展 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 拥有 Elastic Load Balancer - 这些均衡器的设计初衷是避免单点故障，并根据传入流量进行扩展（它们不会受到与设置为负载均衡器的单个实例相同的带宽限制）。ELB 能够监控后端实例的“健康状况”，并与自动扩展配合使用以维持适当数量的实例。

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

您描述了“文件保存在单独的冗余 EBS 上……[然后] 将其挂载”。首先，在 EC2 上，EBS 卷一次只能连接到一个实例（因此要将数据复制到该实例，需要连接 EBS 卷）。您需要自行维护冗余（您可以设置 EBS 设备的 RAID 阵列，或者执行几乎任何其他操作）。但问题是，有时当实例实际崩溃时 EBS 卷不会分离 - 您可以强制分离它们（成功率更高，但不是完美），并且您可以快照 EBS 卷，即使正在使用（然后您可以从中创建新的 EBS 卷并启动 AMI）。但最好在多个实例之间维护数据的副本，而不是在同一实例上的多个 EBS 卷之间维护数据副本。

Answer

在 AWS 上，使用 GlusterFS 和 Elastic Load Balancer 以及自动扩展 EC2 实例应该可以实现您的目标。我无法评论任何其他 IaaS。