web-dev-qa-db-ja.com

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パーティションを別のインスタンスで使用することは可能ですか？.

11.04serveramazon-ec2
28
Sumant

答えは2つあります。

回避策：一時データには/ dev/xvdb（/ mnt）を使用します

これは、いわゆる Amazon EC2 インスタンスの一時ストレージであり、その特性は、他の場所で使用されている永続的な Amazon EBS ストレージとは大きく異なります。特に、この一時ストレージは停止/開始サイクルで失われ、は一般的になくなる可能性があります、したがって、そこに永続的な値を置くことは絶対にしたくない、つまり、temporaryデータを置くだけスワップファイルまたは計算中に使用される厳密に一時的なデータのように、簡単に紛失または再構築する余裕があります。もちろん、たとえば巨大なインデックスをそこに保存することもできますが、何らかの理由（インスタンスの再起動、ハードウェア障害など）でストレージがクリアされた後にこれらを再構築する準備をする必要があります。

解決策：/ dev/xvda1（/）のサイズを変更して、必要なストレージを取得します

これは、いわゆる ルートデバイスストレージAmazon EBS-backed EC2インスタンスであり、特に柔軟性と耐久性のために Amazon EBS を促進します。そこに置かれたデータは合理的に安全であり、インスタンス障害に耐えます。 EBSボリュームの定期的なスナップショットを作成して柔軟性と耐久性をさらに高めることができます。スナップショットは、よく知られている99.999999999％の耐久性を備えた Amazon S ​​に保存されます。

このスナップショット機能を使用すると、現在の8GB EBSルートストレージ（/ dev/xvda1）をお好みの大きさで置き換えることができる限り、問題を順番に解決できます。このプロセスの概要は、Eric Hammondの優れた記事 実行中のEBSブートEC2インスタンスでのルートディスクのサイズ変更 ：

EC2インスタンスのダウンタイムがわずか（数分）であれば問題ありませんが、新しいインスタンスを起動することなく、より大きなコピーでルートEBSボリュームを変更できます。

彼が説明する手順を適切に準備する場合（手順を理解するために最初にEC2インスタンスをスローしてテストするか、カスタマイズされたスクリプトを介して自動化することを強くお勧めします）、数回でプロセスを完了することができますほんの数分のダウンタイムだけです。

概説された手順のほとんどは AWS Management Console を介しても実行できます。これにより Amazon EC2 API Tools ;これは次のように要約されます。

  • eC2インスタンスを停止（終了しない！）
  • 停止したインスタンスからEBSボリュームをデタッチします
  • 切り離されたEBSボリュームのスナップショットを作成する
  • 作成されたスナップショットから新しい（より大きな）EBSボリュームを作成します
  • 新しいEBSボリュームをEC2インスタンスにアタッチします（Important！これがルートデバイスである場合は、インスタンスのルートデバイスとして正確に名前を付けてくださいたとえば、（/ dev/sda1）または（/ dev/xdva1）のように、ルートデバイスではなくブロックデバイスとして接続されます。ルートデバイスがリストされていないため、インスタンスを起動できません。インスタンスの場合。）
  • 実行中のインスタンスにSSHで接続し、df -ah [.____を介してすべての順序が正しいことを確認します。
    • システムがファイルシステムのサイズを自動的に変更していない場合は、Ericの記事で説明されているように、手動でこれを行う必要があります。

幸運を！

代替案

これらのEBSボリュームの汎用性と使いやすさを考えると、追加のオプションは、より多くのEBSボリュームをインスタンスにアタッチし、明らかに分離可能な懸念領域をそこに移動することです。

たとえば、いくつかの非常に重いJavaアプリケーションを使用しており、それぞれがバージョンごとに1〜2 GBのストレージを消費しています。バージョンのアップグレードを容易にし、一般的にこれらのアプリを自分の裁量で別のインスタンスに移動できるように、それぞれを専用のEBSボリュームに配置し、それらをインスタンスにマウントして、目的の場所にソフトリンクします。通常、/var/lib/<app>/<version>および/usr/local/<app>/<version>。

この方法では、ルートデバイスストレージがデフォルトサイズの8GB（ちょうどあなたのもの）のままEC2インスタンスを現在実行していますが、場合によってはさまざまなサイズ（1-15GB）のEBSボリュームも最大8つ接続されています。

ただし、これらのすべてのEBSボリュームがI/Oにまったく同じLANを使用している限り、潜在的なネットワークパフォーマンスの問題に注意する必要があります。これにより、それぞれのパフォーマンスが向上したり、極端な場合にネットワークが飽和したりする可能性があります。ユースケースと手元のワークロードについて。

26
Steffen Opel

うん、簡単な方法でfstabし、マウントして/ var/www/html/files2 /と言う

mkdir/var/www/html/files2/website次にln -s -d/var/www/html/website/var/www/html/files2/website

1
Daniel Chay

今日、同じ問題が発生しました。デフォルトでは、EBSが8GBである新しいec2のインスタンスを作成します。接続されたEBSのサイズを変更するには、新しいインターフェイスを作成したり、スナップショットを作成したり、EBSを切り離したりする必要がありません。以下の3つの手順を実行できます。

  1. EBSボリュームのサイズ変更
  2. パーティションのサイズ変更
  3. パーティションのサイズ変更最初のステップでは、AWSコンソールに移動して[EBS]をクリックし、目的のサイズを変更して[変更]をクリックします。

残りのステップについては、 この記事 に従ってください。質問がある場合は、お気軽にお問い合わせください。

ありがとう！

0
Narendra Sharma