任何人都有一个合理的策略来在AWS上实现NFS,使其不是SPoF(单点故障),或者至少能够在实例崩溃时快速恢复？

我已经阅读了这篇SO post,关于与多个EC2实例共享文件的能力,但是它没有回答如何在AWS上使用NFS来确保HA的问题,只是可以使用NFS.

许多在线资产都表示AWS EFS可用,但它仍然处于预览模式,仅在俄勒冈州可用,我们的主要VPC位于N. Cali.,因此无法使用此选项.

其他在线资产表示GlusterFS是一种可行的方式,但经过一些研究后,由于竞争条件和性能问题,我对实施此解决方案感到不自在.

另一个选择是SoftNAS,但我想避免将未知的AMI引入严格控制的同质环境中.

这留下了NFS. NFS是我们在开发环境中使用的并且工作正常,但它是开发人员,所以如果它崩溃我们会在系统修复问题时获得几个啤酒,但在生产中,这显然是不行的.

此时我能想出的最佳解决方案是创建一个EBS和两个EC2实例.两个实例都将正常更新(通过puppet)以维护堆栈对齐(内核,nfs库等),但只有一个实例将安装EBS.我们在活动的NFS实例上设置了一个监视器,如果它关闭,我们会收到通知,我们会手动分离并附加到备份EC2实例.我想我们也创建了一个也可以解除连接的网络接口,所以我们只需要在DNS中维护一个IP.

虽然我认为我们可以使用keepalived自动执行此操作,并且IAM策略允许自动分离/重新附加.

–UPDATE–

看起来EBS卷与特定的可用区域相关联,因此无法重新连接到另一个AZ中的实例.我能想到的唯一其他选择是：

>在公共子网中的每个AZ中创建EC2(每个都有EIP)
>为TCP创建路由53 healthcheck：2049
>为nfs-1(AZ1)和nfs-2(AZ2)创建路由53故障转移策略

这里唯一的问题是,保持两个NFS服务器同步的最佳方法是什么？只是cron之间的rsync脚本？

还是有一种我完全失踪的最佳做法？

最佳答案 有几个选项可用于构建高可用性NFS服务器.虽然我更喜欢使用EFS或GlusterFS,因为所有这些解决方案都有其缺点.

a)DRBD
可以在DRBD的帮助下同步卷.这允许您镜像数据.在不同的可用区域中使用两个EC2实例以实现高可用性.缺点：配置和操作很复杂.

b)EBS快照
如果RPO超过30分钟是合理的,您可以使用定期EBS快照来从另一个可用区域中断恢复.这可以通过Auto Scaling Group运行单个EC2实例,用户数据脚本和用于定期EBS快照的cronjob来实现.缺点：RPO> 30分钟.

c)S3同步
可以将充当NFS服务器的EC2实例的状态与S3同步.备用服务器使用S3保持最新.缺点：许多小文件的S3同步将花费太长时间.

我建议在AWS re：Invent：https://youtu.be/xbuiIwEOCAs上观看此演讲