用EBS卷创buildEC2实例的最佳实践方式是什么?

启动EC2实例时,似乎大多数社区AMI都附带有作为根驱动器附加的8GB EBS卷。 随着数据库规模的增长,我们肯定会需要大于8GB的空间。 什么是devise我们的系统的可取方法? 我看到的选项是:

  1. 使用8GB存储直到我们需要扩展,然后按照几个冗长的在线教程之一来扩大根驱动的大小。

  2. 将第二个EBS卷附加到较大的实例(例如60 GB),并存储此卷上的所有数据。 如果我想使用MongoDB或MySQL作为数据库,将数据库应用程序文件安装在根卷上是否容易,但将数据存储在另一个卷上?

什么是最佳实践解决scheme?

我认为其实有三个select:

  1. 扩展EBS卷 – 快照,创build所需大小的EBS卷,分离原始文件,附加新文件系统,调整文件系统大小非常容易,但它肯定可以在根卷上完成,但是我build议与选项2。
  2. 第二EBS卷 – 这是我个人的偏好(我不能保证它是一个'最佳做法')。 我将数据库保存在一个卷上(并将其挂载到/ var / data)和另一个卷上的web文件(并挂载到/ var / www / html),当然还有我的根卷。 这样做的好处是:a)可以独立调整每个驱动器的大小并对其进行快照,b)您有一定程度的独立读/写(仍受networking限制),c)假设根卷损坏(即软件升级不当,等等)数据很容易移动到一个新的实例(即使有快照,如果一切都在根卷上,也是如此)。
  3. 一个群集文件系统(例如gluster),允许您在多个卷上分发文件,并根据需要添加更多卷。 从本质上讲,你会select一个大小(比如10GB),当空间不足时,再增加10GB的容量等等.Gluster会将文件分配到卷上 – 这对于单个实例都是适用的(即多个卷连接到一个实例)或跨多个实例(即多个实例共享多个卷)。 虽然在这个设置中有一定程度的复杂性(和性能开销),尽pipe它在理论上提供了最好的多function性。

(有第四种select,但对于像数据库这样的东西实际上并不实用 – 可以将S3安装为熔丝文件系统 – 由于您不必在S3上预先分配空间,因此您将拥有增长的存储与EBS或临时存储相比,速度相当缓慢,其可靠性充其量也是值得怀疑的。)

除非您使用EBS支持的EC2实例,否则AMI映像将解压缩到实例启动时重新创build的10 GB驱动器映像。 我使用实例存储的EC2实例,而不是EBS支持的所有服务器实例。 然后,我可以简单地将EBS卷制作成我需要的任何一边,并将它们安装为辅助驱动器。

有了EBS卷,我发现使用xfs文件系统,只需使用整个EBS卷,没有任何分区是最好的行动。 为了在必要时增加音量,我将执行现有EBS音量的快照,然后根据快照创build一个新的更大的音量。 然后您只需分离现有的EBS卷并附上新的EBS卷。 一旦新卷被挂载,它将显示为当前卷大小,直到您运行必须在文件系统处于活动状态时运行的xfs扩展实用程序命令。 检查完成后的容量将显示新的更大的大小。

现在,如果您使用的是Ubuntu AMI,则可以安装ebsmount软件包,并在EBS卷上创build一个隐藏目录,并将系统configuration为在EBS卷连接到EC2实例时使用udev进行实际自动挂载。

通常情况下,最好的做法是让引导驱动器和数据驱动器成为不同的文件系统,例如,填满引导驱动器的过分热情的日志文件无法约束客户端上传内容的能力(反之亦然)。 我从来没有安装Mondo,但是使用MySQL,指定要存储数据的位置非常简单。 如果您需要再次扩展驱动器,使用rsync,configuration更改以及停机时间仅需几分钟,即可轻松移动数据。

如果你正在使用mysql路由,应该提到的是,Amazon的关系数据库服务在创build一个稳定的可伸缩数据库方面做得相当不错,没有pipe理你自己的麻烦。

把你的重要数据放在(至less一个)外部EBS卷上。 对于任何实际需要性能的任何内容,请在许多 EBS卷上使用Linux MD RAID-10。