web-dev-qa-db-ja.com

Amazon EC2-EBSデバイスとルートインスタンスストアデバイスを交換する

ルートデバイスとして「インスタンスストア」デバイスを持つEC2インスタンスがあります。次に、同じインスタンスにEBSボリュームをアタッチします。 それは ルートデバイス。それは可能ですか？そのような場合、インスタンスストアデバイスはどうなりますか？

前もって感謝します

amazon-ec2amazon-web-servicescloudamazon-ebs
52
Sug

実行中のインスタンスをEBSがサポートするAMIに移行できます。以下がその方法です。

  • 通常のS3 AMIでバックアップされたインスタンスを起動します（または、満足のいくインスタンスを既に持っているので、それを使用します）
  • ルートsda1パーティションと同じサイズのEBSボリュームを作成します（現在、m1.smallおよびその他の場合のデフォルトは10Gです）
  • ウェブコンソールまたはコマンドラインツール（/ dev/sddなど）を使用して、そのEBSボリュームをインスタンス上の空きブロックデバイスに接続します
  • インスタンス上のサービスを停止します（例：/etc/init.d/mysql stopなど）
  • エフェメラルルートボリュームをEBSボリュームにコピーします。

dd bs = 65536 if =/dev/sda1 of =/dev/sdd

  • EBSボリュームの一貫性を確認します。

fsck/dev/sdd

  • EBSボリュームをインスタンスにマウントします。

マウント/ dev/sdd/root/ebs-vol

  • EBS volのfstabから/ mntエントリを削除します。

vim/root/ebs-vol/etc/fstab

  • EBSボリュームの展開：

/ dev/sddをマウント解除します

  • AWS管理コンソール（またはコマンドラインAPIツール）を使用してEBSボリュームのスナップショットを作成します
  • スナップショットIDをメモします
  • スナップショットイメージをAWSに登録し、登録するときに生成されたAMI IDをメモします。カーネルとRAMディスクイメージを指定することを忘れないでください（現在のインスタンスで使用されているものと同じである必要があります）：

ec2-register -s snap-12345 -a i386 -d "AMIの説明" -n "イメージ名" -k aki-12345 -r ari-12345

  • 10Gを超える永続ストレージを持つインスタンスを作成するには、cliツールを使用する必要があります。例えば20G用

ec2-run-instances AMI-54321 -t m1.small -n 1 -g default --availability-zone = eu-west-1a -k ec2-key1 -b/dev/sda1 = snap-12345：20：false

  • これらのAMIのいずれかに基づいて、デフォルトのボリュームサイズでインスタンスを起動する場合、起動後にファイルシステムのオンラインサイズ変更を実行できます。

resize2fs/dev/sda1

79
AlexM

これは、新しいAMIを作成したり、新しいインスタンスを起動したりせずに実行できます。完了すると、元のルートボリュームは/ dev/sda1（または元々マウントされていた場所）に接続されたままになります。/dev/sda1は多くのAMIのデフォルトです。元のルートボリュームはファイルシステムにマウントされません。「mount」コマンドを使用して自分で行う必要があります。

この手法には、10.04および10.10リリースで実行される最新のUbuntuカーネルが必要です。これらのUbuntuリリースの最新のAMI IDについては、 alestic.com をご覧ください。これらの最近のカーネルは、ボリュームラベルが「uec-rootfs」である接続デバイスから起動するように構成されています。これらのカーネルのいずれかを実行している場合は、現在の（インスタンスストア）ルートボリュームのボリュームラベルを別のものに変更し、新しいルートのボリュームラベルをuec-rootfsに変更してから再起動するだけです。これらのカーネルのいずれかを実行していない場合、この手法は使用できません。

これがコードです。これをインスタンスのファイル（reroot.sh）に配置します。

#! /bin/bash
device=$1
# change the filesystem labels
e2label /dev/sda1 old-uec-rootfs
e2label $device uec-rootfs

まず、利用可能なデバイス/dev/sdf../dev/sdpのいずれかに、新しいルートとして機能させるEBSボリュームを接続します。これは、直接EC2 API呼び出し、 EC2コマンドラインAPIツール （ec2-attach-volume）、または boto などのライブラリ、または経由で実行できます。 AWSマネジメントコンソールUI。

次に、rootとしてreroot.shスクリプトを実行し、次のように新しいルートボリュームを接続したデバイスを提供します。

Sudo reroot.sh /dev/sdp

これは汚い仕事をします。次に、単に再起動します。

Sudo shutdown -r now

ビオラ。

これをテストするには、適切に起動することがわかっているEBSボリュームを作成する必要があります。上記のUbuntu AMIからEBS-backed AMIのルートボリュームのスナップショットを作成することで、これを行うのが好きです。そのスナップショットから、任意のアベイラビリティーゾーンに新しいブート可能なEBSボリュームを作成できます。実行中のインスタンスの元のルートボリュームと新しいEBSルートボリュームの違いを確認できることを確認します。上記のルート変更手順を実行する前に、古いルートボリュームに「マーカー」ファイルを配置できます。

cd
touch this-is-the-original-root-volume

次に、ルートを変更して再起動すると、そのファイルがホームディレクトリに存在する場合、元のルートボリュームで実行されたままになります。存在しない場合は、再ルートと再起動が機能しました。

この手法の2つの使用例と、詳細な説明を次に示します。

http://shlomoswidler.com/2011/02/play-chicken-with-spot-instances.html

http://shlomoswidler.com/2011/02/recapture-unused-ec2-minutes.html

13
Shlomo Swidler

また、次のツールを使用して、インスタンスストアAMIをebs-boot AMIに変換することもできます。 https://cloudyscripts.com/tool/show/2

6
elasticsecurity

AlexMは良い手順を思いつきました。

このリンクをチェックすることにも興味があります： http://coderslike.us/2009/12/07/Amazon-ec2-boot-from-ebs-and-AMI-conversion/

EDIT：別のリンク： http://www.elastician.com/2009/12/creating-ebs-backed-AMI-from -s3-backed.html

1
Gnanam

既存のインスタンスを変換するのがどれほど簡単かはわかりませんが、Amazonは現在、新しいインスタンスを作成するときに EBSボリュームから直接起動する機能 を提供しています。

0
gareth_bowles

ここでの他の長いコメントの代わりに、次のコマンドを使用してこれを行いました。

ec2-register --snapshot snap-9eb4ecf6 --architecture i386 --name "centOS上のZenoss Enterprise 3.0 beta 2" --description "これは、両方ともバージョン3.0のzenoss core beta 1およびzenoss enterprise beta 2のインストールによるものです。または内部的に2.5.70 217）。ebsブロックデバイスが接続され、ファイルシステムが再同期され、ebsのスナップショットが作成され、これに基づいています。」 --root-device-name/dev/sda1 --kernel aki-9b00e5f2

0
user368678