web-dev-qa-db-ja.com

EC2インスタンスの/ varディレクトリを/ mntに移動します

Ubuntu12.04を実行している一連のEC2インスタンスの標準構成で作業しようとしています。これらのサーバーは、主にRuby on RailsアプリケーションのWebサーバーになります。新しいラージインスタンスを構成すると、8GBのプライマリが与えられます。次に、/ mntにマウントされる400GBのエフェメラルストレージ。

成長する可能性のあるいくつかのディレクトリを/ mntディレクトリに移動することは私には論理的であるように思われます。私は特に、/var/wwwと/var/logについて考えていました。

私の質問は2つあります。

  1. これは良い考えですか、それとも私が見ることができない落とし穴がありますか？

  2. これが良い考えである場合、これをどのように構成すればよいですか。新しいインスタンスを構成し、古いインスタンスをダウンさせる機能はあります。私の懸念は長期的な構成に関するものであり、必ずしもダウンタイムについて懸念しているわけではありません。

私はDevOpsの経験がある開発者ですが、ドライブのマウントはこれまで直面したことのないものなので、明確な指示をいただければ幸いです。

ubuntuamazon-ec2mount
5
Geoff Lanotte

/var/wwwに何を保存しているかはわかりませんが、サーバーのコンテンツは「エフェメラル」とは言えません。これは、「いつでもなくなる可能性があり、あまり多くない」という意味だと理解しています。マインド"。それがAmazonの「エフェメラル」の意味ではない場合は、お詫び申し上げます。

/var/logについては、ログデータをまったく気にしないのであれば、そもそも収集しないでください。

あなたがそれを気にかけているが、それを一次ストレージに非常に長く保持する余裕がない場合、これはログ管理の問題ほどマウントの問題ではありません。 logrotateが利用できる場合はそれを使用し、毎週かそこらで古いログを/mntに移動するように構成したいと思います。そうすれば、古いログは（一時的なストレージがなくなるまで）そこにありますが、現在のログはプライマリストレージで安全です。

のようなログローテーションレシピ

/var/log/foo {
    olddir /mnt
    compress
    weekly
    rotate 1000
    postrotate
    /etc/rc.d/init.d/fooservice restart
    endscript
}

少なくともテンプレートとしては役立つかもしれません。

1
MadHatter

アプリケーションが蓄積する（ファイルシステム上の）データが貴重な場合は、400GBの無料ストレージを無視してEBSボリュームをマウントします。さもないと...

答えは、（a）アプリケーション、および（b）「スポット」または「予約済み」インスタンスによって異なりますが、

1）はい、それは良い考えです。明らかに、ディスク容量が不足する可能性が低いからです。それが可能性が高いかどうかは、あなたのRailsアプリの機能によって異なりますが、「あなたの」と「私の」を区別して明確に定義するために、すべての「私の」ものを/mntに置く傾向があります。 。手動でマウントする必要はありません。これはcd mntだけで実行できます。アクセス許可を少しいじると、問題なく克服できます。

しかしもちろん、このスペースは「一時的」であるため、サーバーが停止すると停止します。これにより、2番目の資格が得られます...

2）「スポット」または「予約済み」インスタンス？

スポットインスタンスがある場合は、リモートである可能性があることを受け入れる必要があります。最大価格が高値になり、サーバーが予期せず終了します。サーバー上のデータに価値がある場合、これは問題を引き起こします。

だが！ 「予約済み」インスタンスに割増料金を支払っている場合、これは（細字の免責事項をすべて読んだわけではありません;-/）サーバーが予期せず終了する脅威と、アプリケーションのデータの蓄積が非常に大きいことを意味します減少。 （S3への）定期的なバックアップをスケジュールし、EBSの追加費用なしで非常に簡単に眠ることができるかもしれません。

前述のように、長期的な場合は、最小限のダウンタイム（およびリスク）が目標です。したがって、ペニーを節約するために少しお金を払うよりも、/mntを無視して、EBSボリュームを作成してマウントする方法をよく理解してください。 allあなたのものをそこに置いてください。そうすれば、スリープを失うことなくサーバーを再起動できます。そのようなものが消えることはなく、サーバーインスタンスのサイクリングを必要とする災害が発生する前の状態に戻るのに「時間がかかる」こともありません。

0
John Mee

あなたが計画していることは、私のすべてのインスタンスに対して行うことと似ていますが、/ var/lib/mysqlとほとんどの/ etc/{Apache2、mysql、php}ディレクトリも含めています。これを行うので、何らかの理由でインスタンスが終了したときに構成が失われることはありません。

  1. データが失われることは決してないという点で優れたアイデアです。前述したように、インスタンスがダウンした場合、その情報は保持され、新しいインスタンスにマウントする必要があります。

  2. これを行う最も簡単な方法は、それらのディレクトリをEBSボリュームに移動してから、元の場所にそれらへのシンボリックリンクを作成することです。

0
Jim Ekleberry