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のすべてのログファイルをクリーンアップします。
• サーバーから不要なファイルをすべて削除しました。
• ホームディレクトリのクリーンアップ。

しかし、それでも十分なスペースがありません。このインスタンスタイプは、8GB EBSのm1.largeです。今、/ dev / xvdbに十分なディスク容量があります。

私はいくつかのディスク領域を割り当てることができます方法はあり/からの/ dev / xvdbまたは任意の他の方法は。これの可能な解決策を提案してください。別のインスタンスで同じ/ dev / xvdbパーティションを使用することは可能ですか。

答えは2つあります。

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

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

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

これは、Amazon EBS-backed EC2インスタンスのいわゆるルートデバイスストレージです。これにより、特に柔軟性と耐久性のためにAmazon EBSが容易になります。Amazon S3に保存されているEBSボリュームのスナップショットを定期的に取得することにより、柔軟性と耐久性をさらに高めることができます。これは、99.999999999％の耐久性が知られています。

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

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

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

概説された手順のほとんどは、AWSマネジメントコンソールを介して実行することもできます。これにより、Amazon EC2 APIツールを扱う必要がなくなります。これは次のように要約されます。

• EC2インスタンスを停止（終了しない！）
• 停止したインスタンスからEBSボリュームをデタッチします
• 切り離されたEBSボリュームのスナップショットを作成する
• 作成されたスナップショットから新しい（より大きな）EBSボリュームを作成します
• 新しいEBSボリュームをEC2インスタンスにアタッチします（重要！これがルートデバイスである場合は、（/ 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を使用している限り、潜在的なネットワークパフォーマンスの問題に注意する必要があります。これにより、それぞれのパフォーマンスが向上したり、極端な場合にネットワークが飽和したりする可能性があります。ユースケースと手元の作業負荷について。

簡単な方法でfstabを実行し、次に/ var / www / html / files2 /と言うようにマウントします

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

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

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

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

ありがとう！