web-dev-qa-db-ja.com

実行中のEC2インスタンスでEBSボリュームとローカルボリュームを識別する方法

実行中のEC2インスタンスで、EBSボリュームとローカルディスクを識別するにはどうすればよいですか？シェルからそれらを識別したいと思います。

fdisk、lsblkはEBSボリュームのみを特定するのに役立ちません。

20個のidentifyebsストアのうち、合計20個のディスクがあるとします。

助言がありますか？

linuxamazon-web-serviceshard-drivediskmanagement
5
Chucks

すべてのEC2インスタンスは、そのインスタンスに関するメタデータへのアクセスを提供するリンクローカルアドレスhttp://169.254.169.254のRESTエンドポイントにアクセスできます。

EBSとインスタンスストアボリュームのブロックデバイスマッピングは、そこで利用可能ないくつかのプロパティの1つであり、「curl」などのツールを使用して、シェルとスクリプトからデータに簡単にアクセスできます。

http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

これはおそらく、探しているものを見つけるための「最も正しい」方法です。

更新：この機能を実証するために、すばやく非常に汚れたワンライナーを打ち出しました。これが製品品質のコードであること、または特に十分に文書化されていることを示唆するつもりはありませんが、確実に機能します。

上記のエンドポイントは、インターフェースのいくつかの「バージョン」を提供しているようです。これらのほとんどはバージョンのリリース日を使用していますが、「最新」のバージョンを使用することもできます。このサンプルコードは、インターフェイスが変更されても引き続き機能するように、バージョン「2012-01-12」を選択します。

シェル変数$ METAURLにリンクを格納し、そこで利用可能なマッピングのリストをcurlで取得してから、各マッピングをbashfor/do/doneループ（ここでもcurl）で繰り返してブロックデバイスを見つけます。次に、Perlを使用して整理し、特定のインスタンスがデバイス名に使用するように「sdX」を「xvdX」に書き換え、最後にsortを使用して字句順に並べ替えます。

bash$ METAURL="http://169.254.169.254/2012-01-12/meta-data/block-device-mapping/"
bash$for bd in `curl -s $METAURL`; do curl -s $METAURL$bd | \
         Perl -pe 'BEGIN { $d = shift } s/^(\/dev\/)?(sd)?(.*)$/\/dev\/xvd$3 is $d\n/' $bd; \
         done | sort

出力例：

/dev/xvda1 is AMI
/dev/xvda1 is root
/dev/xvdb is ephemeral0
/dev/xvdf is ebs2
/dev/xvdg is ebs1
/dev/xvdh is ebs5

それはなめらかで、比較的無痛でした。

しかし、小さな問題が1つあります 私の答えで。

block-device-mapping/ebsN

Amazon EBSボリュームに関連付けられている仮想デバイス（存在する場合）。この値は、起動時に存在する場合にのみメタデータで使用できます。

— http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html#instancedata-data-categories

このソリューションでは、インスタンスの起動後にマウントされたEBSボリュームについては通知されません。エフェメラルディスクは起動時にのみ追加でき、後で追加することはできないため、エフェメラルボリューム情報は常に利用可能であるため、これで問題ない場合があります。したがって、ボリュームがエフェメラルである場合は、この方法でいつでも検出できるはずです。ここにない場合は、エフェメラルディスクではありません。

これに照らして、 EC2 API または aws cli ユーティリティ（EC2 APIを呼び出す）は、本当にすべてを知る必要がある場合に使用する必要があるものです。インスタンスに何がアタッチされているかを知る必要があります。そこにはもっと多くのデータがありますが、スクリプトで利用するのは少し難しいでしょう。古典的なトレードオフだと思います。

9
Michael - sqlbot

Michaelの回答は、AWSインスタンス内のEBSボリュームからインスタンスディスクを区別する方法がないように思われることを示しています。実際、diff -r /sys/block/xvd{f,g}と比較できるインスタンスとEBSディスクのカーネル情報は、書き込み統計とデバイス名を除いて同じです。また、ディスクはsmartctlに応答しません。

しかし、私はそれに気づきました：

  • 新しいEBSボリュームは、パーティションテーブルがまったくない状態で表示されるようです。

  • 新しい一時ディスクはextフォーマットされているようで、「mount count」スーパーブロックパラメータが0に設定されており、どこにもマウントされたことがないことを反映しています。

これを使用する方法の1つは、マシンが初めて起動するときに、ext形式でフォーマットされているデバイスを探すスクリプトを実行することです。

tune2fs -l $dev | grep "Mount count"

0を返します。そのようなディスクのリストをインスタンスのどこかに保存し、他のすべてのディスクをEBSとして扱います。

もちろん、Amazonはいつでもこのすべてを予告なしに変更する責任があります。しかし、それは今のところうまくいくようです。

1
andrew.n