![Amazon EC2 上的冗余 NFS](https://linux22.com/image/572144/Amazon%20EC2%20%E4%B8%8A%E7%9A%84%E5%86%97%E4%BD%99%20NFS.png)
我有兴趣在 Amazon EC2 上构建两个具有故障转移功能的容错/冗余 NFS 服务器。我熟悉 DRBD、Heartbeat 等工具/技术。Amazon 是否提供了通过其平台实现此目的的任何具体方法?
一个合适的例子可能是将文件保存在单独的、冗余的 EBS 上——如果发生故障,则会从预先构建的 AMI 自动启动新实例,安装 EBS 卷,并且无缝转换 IP 地址。
这可能吗?有没有比亚马逊更好的平台?你能大致介绍一下我们正在讨论的实现这一目标的底层架构吗?
答案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 卷之间维护数据副本。
答案2
另一个选择是使用 Zadara Storage,这是一种“即服务”的 NFS。由于它是一种服务,因此您无需管理 NFS 服务器堆栈,并且默认情况下它是 HA。您甚至不需要为 NFS 服务器实例付费。您可以使用标准 NFS 将所有 EC2 计算机连接到您的共享。
披露:我是 Zadara Storage 的员工。