启动 EC2 实例时，似乎大多数社区 AMI 都附带一个 8GB EBS 卷作为根驱动器。随着数据库大小的增长，我们肯定会需要大于 8GB 的空间。设计我们的系统的建议方法是什么？我看到的选项是：
使用 8GB 存储空间直到我们需要扩展，然后按照在线的几个冗长的教程之一来扩展根驱动器的大小。
将第二个 EBS 卷附加到更大的实例（例如 60 GB），并将所有数据存储在此卷上。如果我想使用 MongoDB 或 MySQL 作为数据库，是否可以很容易地将数据库应用程序文件安装在根卷上，但将数据存储在另一个卷上？
最佳实践解决方案是什么？
答案1
除非您使用的是 EBS 支持的 EC2 实例，否则 AMI 映像将被提取到 10GB 驱动器映像中，该映像在启动实例时重新创建。对于我的所有服务器实例，我都使用实例存储的 EC2 实例，而不是 EBS 支持的实例。然后，我只需将 EBS 卷设置为我需要的任何一侧，然后将它们安装为辅助驱动器。
对于 EBS 卷，我发现使用 xfs 文件系统并直接使用整个 EBS 卷而不进行任何分区是最佳做法。为了在必要时增加卷，我会对现有 EBS 卷执行快照，然后根据快照创建一个新的更大卷。然后，您只需分离现有 EBS 卷并附加新卷即可。安装新卷后，它将显示为当前卷大小，直到您运行 xfs expand 实用程序命令（该命令必须在文件系统处于活动状态时运行）。完成后检查容量将显示新的更大大小。
现在，如果您使用的是 Ubuntu AMI，则可以安装 ebsmount 包并在 EBS 卷上创建一个隐藏目录，并将系统配置为在 EBS 卷连接到 EC2 实例时使用 udev 实际自动挂载。
答案2
我认为实际上有 3 个选择：
- 扩展 EBS 卷非常容易 - 快照、创建所需大小的 EBS 卷、分离原始卷、附加新的卷、调整文件系统大小，当然可以在根卷上完成，但我建议最好采用选项 2。
- 第二个 EBS 卷 - 这是我的个人偏好（我不能保证它是“最佳实践”）。我将数据库保存在一个卷上（并将其挂载到 /var/data），将 Web 文件保存在另一个卷上（并将其挂载到 /var/www/html），当然还有我的根卷。优点是 a) 您可以独立调整每个驱动器的大小和快照，b) 您具有某种程度上的独立读取/写入（仍然受网络限制），c) 即使假设根卷已损坏（即软件升级不良等），数据也可以轻松移动到新实例（即使使用快照，如果所有内容都在根卷上，情况就不一样了）。
- 集群文件系统（例如 gluster）允许您将文件分布在多个卷上，并根据需要添加更多卷。本质上，您需要选择一个大小（例如 10GB），当空间不足时，再添加一个 10GB 的卷，等等。Gluster 将在您的卷上分布文件 - 这既适用于单个实例（即连接到一个实例的多个卷），也适用于多个实例（即多个实例共享的多个卷）。尽管这种设置理论上提供了最佳的多功能性，但存在一定程度的复杂性（和性能开销）。
（还有第四种选择，但对于数据库之类的东西来说，它实际上并不实用 - 您可以将 S3 安装为保险丝文件系统 - 而且由于您不必在 S3 上预先分配空间，因此您的存储空间会随着您的需求而增长。然而，与 EBS 或临时存储相比，它的速度相当慢，而且它的可靠性充其量是值得怀疑的。）
答案3
无论如何，通常最好的做法是将启动驱动器和数据驱动器设置为不同的文件系统，这样，例如，填满启动驱动器的过分繁琐的日志文件就不会影响客户端上传内容的能力（反之亦然）。我从未安装过 Mondo，但使用 MySQL，可以非常轻松地指定要存储数据的位置。如果您需要再次扩展驱动器，甚至可以稍后使用 rsync、配置更改和几分钟的停机时间轻松地移动数据。
如果您选择 mysql 路线，那么可能应该提到，Amazon 的关系数据库服务在创建稳定可扩展的数据库方面做得相当不错，而且您无需为管理自己的数据库而头疼。
答案4
将重要数据放在（至少一个）外部 EBS 卷上。对于任何你真正需要性能的东西，请在很多EBS 卷。