我的客户让我做一个项目，但我对这个项目并没有什么万无一失的答案。
他使用 Amazon EC2 来托管服务器 - 也就是说，他使用现货请求。如果您以前使用过 EC2 现货请求，您就会知道，实例终止后，其数据就会丢失。
为了解决这个问题，他想要连接并安装一个外部 EBS 卷。他提供了他想要持久化的目录列表。他坚持要我找到一种方法来做到这一点，但我几乎可以肯定这是不可能的。
我能够移动一些根目录，没有任何不良副作用（我将它们移动到已安装的 EBS 并创建指向正确位置的符号链接）。/home 很容易移动，/var、/usr 和其他几个目录也很容易移动。然而，他坚持认为 /bin、/sbin、/lib、/lib64 和 /etc 必须位于 EBS 卷上。
在我看来，这显然行不通，因为 EBS 卷必须在某个时候挂载。据我所知，我能够挂载它的最早时间点是通过 /etc/fstab。如果你将 /etc 存储在外部驱动器上，那么你将如何挂载它？如果你无法挂载它，你将如何访问 /etc/fstab......这是一个悖论。
那么，我的假设正确吗？无论我是否正确，请帮助我提供足够的信息来向他解释情况。我的直觉立即对这个想法大喊“不”，但老实说，我没有一个单一的、宏观的、坚实的论据来支持自己。
谢谢！
附加信息：
他说他希望我找到一种方法，将所有核心、必要的文件保存在根驱动器上，同时将其他任何内容存储在 EBS 卷上。
请告诉我我没有疯，这只是完全疯了。
答案1
是的，这有点疯狂，至少是不必要的。听起来客户端不了解 AMI 的工作原理。如果 /bin、/sbin 等目录嵌入到您启动的 AMI 中，它们就不会“丢失”。
正确的做法是：
- 使用运行应用程序所需的基本配置构建 AMI。
- 添加一个脚本，该脚本附加一个 EBS 卷，该卷在启动后包含所有易失性数据。例如，如果您需要让 /var 分区持久化（用于日志），则可以将此软链接到 EBS 卷。
- 将此 AMI 指定为要为 Spot 请求启动的 AMI。
当然，您的应用程序必须能够处理这样一个事实：它可以随时终止而无需通知，因此它需要有某种事务检查点，以便知道成功写入持久 EBS 分区的内容。