当前位置: 首页>>技术教程>>正文


AWS实例中的磁盘空间’/’没有足够的空间

, , ,

问题描述

我在AWS云上为我的Web服务器运行Ubuntu 11.04实例,现在我得到服务器的/分区中没有磁盘空间。 df -ah说这个

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  7.8G   97M  99% /
proc                     0     0     0   -  /proc
none                     0     0     0   -  /sys
fusectl                  0     0     0   -  /sys/fs/fuse/connections
none                     0     0     0   -  /sys/kernel/debug
none                     0     0     0   -  /sys/kernel/security
none                  3.7G  112K  3.7G   1% /dev
none                     0     0     0   -  /dev/pts
none                  3.7G     0  3.7G   0% /dev/shm
none                  3.7G   80K  3.7G   1% /var/run
none                  3.7G     0  3.7G   0% /var/lock
/dev/xvdb             414G   16G  377G   4% /mnt

现在我已经尝试了这些东西以在/分区上获得一些额外的空间

  • 清理Apache的所有日志文件。

  • 从服务器中删除了所有不必要的文件。

  • 主目录清理。

但是我仍然没有足够的空间。此实例类型为m1.large,具有8GB EBS。现在,我在/dev /xvdb中有足够的磁盘空间。

有没有一种方法可以将一些磁盘空间分配给/dev /xvdb或其他任何方式。请为我建议可能的解决方案,是否可以将相同的/dev /xvdb分区用于另一个实例。

最佳解决思路

答案是双重的。

解决方法:将/dev /xvdb(/mnt)用于临时数据

这就是您的Amazon EC2实例的所谓临时存储,它的特性与在其他地方使用的持久性Amazon EBS存储的特性有很大的不同。特别是,这种临时存储会在停止/启动周期中丢失,并且通常会消失,因此,您绝对不希望在其中放置任何持久价值的东西,即,只在其中放置临时数据,您可以轻松地丢失或重建它们,例如交换文件或在计算过程中使用的严格临时数据。当然,例如,您可能会在其中存储巨大的索引,但必须准备好在由于某种原因(实例重新启动,硬件故障等)清除存储后重建这些索引。

解决方案:调整/dev /xvda1(/)的大小以获取所需的存储空间

这就是您的Amazon EBS-backed EC2实例的所谓Root Device Storage,它特别有利于Amazon EBS的灵活性和持久性,即,存放在那里的数据相当安全,并且可以在实例故障后幸存;您可以通过定期对EBS卷进行快照来进一步提高灵活性和耐用性,这些快照存储在Amazon S3中,具有99.999999999%的耐用性。

此快照功能使您可以依次解决问题,在此范围内,可以用所需的更大或更少的容量替换当前的8GB EBS根存储(/dev /xvda1)。 Eric Hammond的出色文章Resizing the Root Disk on a Running EBS Boot EC2 Instance概述了该过程:

As long as you are ok with a little down time on the EC2 instance (few minutes), it is possible to change out the root EBS volume with a larger copy, without needing to start a new instance.

如果您正确地准备了他描述的步骤(我强烈建议您先使用扔掉的EC2实例对其进行测试,以熟悉该过程,或者甚至通过定制的脚本将其自动化),那么您应该能够完成其中的一些步骤分钟停机时间确实如此。

概述的大多数步骤也可以通过AWS Management Console执行,从而避免了Amazon EC2 API Tools的处理;归结为:

  • 停止(不终止!)EC2实例

  • 从停止的实例中分离EBS卷

  • 创建分离的EBS卷的快照

  • 从创建的快照创建一个新的(更大)EBS卷

  • 将新的EBS卷附加到EC2实例(重要!如果这是您的根设备,请确保将其准确命名为该实例的根设备,例如(/dev /sda1)或(/dev /xdva1)否则它将作为一个块设备而不是一个根设备连接,并且您将无法启动该实例,因为该实例将没有列出根设备。)

  • SSH进入正在运行的实例,并通过df -ah确认一切正常

    • 如果您的系统没有自动调整文件系统的大小,则需要按照Eric的文章中所述手动进行操作

祝好运!


Alternative

鉴于这些EBS卷的多功能性和易用性,另一种选择是将更多EBS卷附加到您的实例上,并在该实例上移动明显可分离的关注区域。

例如,我们使用了几个非常重量级的Java应用程序,每个应用程序每个版本消耗1-2GB的存储空间;为了简化版本升级并通常能够自行决定将这些应用程序移动到不同的实例,我将它们分别放置在专用的EBS卷上,将它们安装到实例上并将它们软链接到所需的位置,例如通常是/var/lib/<app>/<version>/usr/local/<app>/<version>

使用此方法,我们当前正在运行EC2实例,其根设备存储仍保持其默认大小8GB(与您的默认大小相同),但有时最多还连接8个EBS卷,且大小不同(1-15GB)。

但是,您需要意识到潜在的网络性能问题,因为所有这些EBS卷都使用相同的LAN进行I /O,这甚至可能产生各自的性能提升,或者在极端情况下会使网络饱和-因此,这通常取决于关于用例和手头的工作量。

参考资料

本文由Ubuntu问答整理, 博文地址: https://ubuntuqa.com/article/7234.html,未经允许,请勿转载。