Memo/AmazonWebServices/EC2

https://dexlab.net:443/pukiwiki/index.php?Memo/AmazonWebServices/EC2 		 

EC2(Elastic Compute Cloud) †

  • Spot InstanceではEBSインスタンスでもstopできず、start/terminateのみ可能
  • EBSインスタンスでEC2 > Create Imageを実行するとデフォルトでは自動的に再起動がかかるので注意。そうしたくない場合、オプションを外す。
↑

EBSの動的拡張 †

  • 条件が揃えば、root volumeでも動的拡張できる
    • gp2
    • 現行世代のインスタンス(m3以上？)
    • 2TB未満
  • パーティションは作成しない方が良い。
  • パーティションを作ってしまうと、growpart -> reboot -> resize2fsのような手順が発生する。
  • 参考 Memo/AmazonWebServices/awscli/EC2#l1d9fc56
↑

EBSのデバイス名 †

↑

暗号化 †

↑

インスタンスタイプ選定 †

  • dev環境: t2/t3
    • CPU使用率が低い。または、短時間のみ使用率が高い。
  • prod環境: m5
    • CPU使用率が高い状態が続く。
↑

WindowsServer †

↑

Private SubnetのEC2に接続する †

Private Subnet上のEC2はPublic IPを割り当てても通信できない。

↑

削除 †

↑

EBSのライフサイクル †

自動で定期スナップショットを取る事ができる。

↑

CPU stealが高い †

  • m3.mediumの場合、CPU stealが高く、プログラムの挙動が遅くなる時がある。他のインスタンスタイプへの移行を検討。
    • t2シリーズは普段はCPU利用率が低く、瞬間的にCPU利用率が上がる場合に適している。(開発用やbatch処理等)。CPUクレジットを使い切ると、バーストしなくなるので注意。
    • 常時CPU利用率が高い場合は、m4/m5のインスタンスを検討。large以上のみのため高い
  • 記事
↑

セキュリティグループ †

  • 別AWSアカウントのセキュリティグループも指定できる。
    • <AWS account ID>/sg-xxxx
    • 同一リージョンのみ
↑

EBSをLVMでストライピングしてIOPSを上げる †

↑

タグ付け †

  • 値が複数の場合の区切り文字: ";", ",", "|"
↑

EC2の強制停止 †

  • ホストのハードウェア故障等で、突然再起動したり、その後起動しない場合がある。
    • AWS管理コンソール上のステータスは0/2で正常に起動しない
    • AWS管理コンソールからstopを実行しても、stoppingのままで処理が進まない。
  • awscliで強制停止例 
    aws ec2 stop-instances --instance-id i-xxxx --force --profile default --region ap-northeast-1
↑

Public DNSとPrivate DNSの自動変換 †

↑

ベンチマーク †

↑

Marketplace codes may not be attached †

  • 例: CentOS 6.5 (x86_64) - Release Media から起動したEC2のrootボリュームはEBSに「製品コード: marketplace: xxxxxxx」と記載があり、rootボリューム(/dev/sda)以外にアタッチできない。
    これはrootボリュームから起動しなくなった場合のトラブルシュート時に困る事になる。
    AWS Supportに該当ボリュームのスナップショットを共有すると、制限を解除してくれる模様
↑

SSHログインできない場合 †

AWSの場合、ssh設定ファイルを間違えたり、iptablesを間違えたりするとsshログインできなくなる。
他のクラウドでは管理画面からターミナルを開けたりするので最悪そこから編集できる。

  1. 問題のEC2のEBSルートボリュームのスナップショットを作成。停止できるなら、停止してルートEBSを外しても良い
  2. 新規で調査用EC2を作成
  3. EBSスナップショットからEBSを作成し、調査用インスタンスにアタッチ
  4. 調査用EC2でマウントして、調査する
  5. 修正できるなら、問題のEC2のルートボリュームを作成したEBSと入れ替えて起動
↑

EBS/エフェメラルディスクのデバイス名 †

  • AMIによって開始名が異なる。AWS上では/dev/sda でもCentOS6では /dev/xvde として認識される。
  • エフェメラルディスクは /dev/sdb 〜 sde までの4台が予約されている。CentOS6では/dev/xvdf 〜 xvdi
  • EBSは /dev/sdf 〜 。CentOS6では/dev/xvdj 〜
↑

パーティション作成済みEBSを拡張する †

EBSではスナップショット作成後、スナップショットからより大きなEBSを作成できる。
しかし、パーティションが一つでもあると、resize2fsが失敗し、OSから拡張した部分が認識されない。
これを growpart コマンドで修正する。

非常に面倒で時間がかかるので、通常はパーティションを作成せずにフォーマットだけして利用する方が楽。

  • パーティションが無いEBS: /dev/xvdf 
    sudo mkfs.ext4 /dev/xvdf
  • パーティションが有るEBS: /dev/xvdf1 
    # fdiskやpartedでパーティションを作るとresize2fsが失敗するようになる。
sudo parted /dev/xvdf
sudo mkfs.ext4 /dev/xvdf1
  • CentOS 6.x 64bitの場合: 
    sudo yum install --enablerepo=epel cloud-utils-growpart parted

# パーティション1を拡張。結構時間がかかる
sudo growpart /dev/xvdf 1

# パーティションサイズが増えている事を確認
sudo parted -l

# resize2fsを実行。先にe2fsckを実行するように指示される。
sudo resize2fs /dev/xvdf1
Please run 'e2fsck -f /dev/xvdf1' first.

# e2fsckでチェック。これも結構時間がかかる
sudo e2fsck -f /dev/xvdf1

# OSからパーティションサイズが正しく認識されるように
sudo resize2fs /dev/xvdf1

sudo mkdir /mnt/ebs1
sudo mount /dev/xvdf1 /mnt/ebs1

# 必要であれば/etc/fstabにも追加
echo "/dev/xvdf /mnt/ebs1 ext4 defaults,nofail,comment=manual 0 0"

# OSから正しく認識されたか確認
df -h
  • rootボリュームの場合は再起動が必要
  1. パッケージを追加 
    sudo yum install cloud-init dracut-modules-growroot cloud-utils-growpart
  2. dracutで修正。この時現在のkernelしか指定できなかった。それ以外のinitramfsを指定すると起動しなくなった。 
    dracut --force --add growroot /boot/initramfs-$(uname -r).img
  3. cloud-initの設定で growpart を実行するように指定 
    cat /etc/cloud/cloud.cfg

resize_rootfs_tmp: /dev

cloud_init_modules:
 - growpart
 - resizefs
  4. AMIを作成。作成したAMIからEC2起動時に任意のrootボリュームサイズを指定して起動し、起動後にOSから正しくサイズが認識されているかを確認
  • cloud-utilsはインストールしない方が良い。依存関係でglusterfs(3.6.0.54-1.el6)がインストールされるが、/etc/logrotate.d/glusterfs にグローバル設定が書いてあり、/etc/logrotate.confの設定が上書きされてしまう。
↑

EC2:CentOS7でエフェメラルディスクのマウントに失敗し、起動しなくなる †

AMI: CentOS 7 (x86_64) with Updates HVM を使った場合、エフェメラルディスクがマウントできない時、EC2の起動ができなくなった。

  • EC2 インスタンスにインスタンスストアボリュームを追加する
    • m1シリーズのエフェメラルディスクはext3でフォーマット済み
    • I2/R3シリーズ等のTRIMをサポートしているSSDベースのエフェメラルディスクはフォーマットされていない
    • m3シリーズはSSDベースのエフェメラルディスクだが、TRIMをサポートしてないので、ext3でフォーマット済み。
  • /etc/fstab
    • OK: /dev/xvdb /mnt auto defaults,nofail 0 0
    • NG: /dev/xvdb /mnt ext3 defaults 0 0
↑

cloud-init: EC2起動時にコマンド実行 †

↑

グローバルIPを取得 †

↑

NTP †

↑

EBSスナップショットの別リージョンへのコピー †

今まで面倒だったEBSスナップショットのリージョン間のコピーが ec2-copy-snapshot で出来るようになった

↑

fdiskでEBSインスタンスのROOTデバイスを拡張 †

  • ManageMentconsoleから拡張して起動した場合 
    #  m1.largeの例
resize2fs /dev/xvde1
reboot
  • 上記でエラーが出るケースや、パーティションを切ってある場合
    • m1.largeの例。ManageMentconsole からROOTデバイスを40GBに拡張した場合 
      fdisk /dev/xvde
----
Command (m for help): p
...
Device Boot Start End Blocks Id System
/dev/xvde1 * 1 1044 8385898+ 83 Linux
----
Command (m for help): d 
Selected partition 1
----
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-5221, default 1): 
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-5221, default 5221): 
Using default value 5221
----
Command (m for help): p
...
Device Boot Start End Blocks Id System
/dev/xvde1 1 5221 41937651 83 Linux
----
Command (m for help): w
...
----
reboot

resize2fs /dev/xvde1
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvde1 40G 2.6G 35G 7% /
...
↑

IAM ROLEを使う †

↑

AMIをPVからHVMへ変換 †

仮想化方式の違いで、PV, HVMがある。

  • PV(paravirtual, 準仮想化): AKI(kernel), ARI(ramdisk)を使う方式(Amazonが用意したkernel+ramdisk)と、PV-GRUBを使う方式(PV-GRUB用AKIを使って、grub.confに書いたkernelを読む)がある
  • HVM(Hardware-assited VM, 完全仮想化): 物理マシンとほぼ同じ。ブート領域(GPT, MBR) + ブートローダ(GRUB)が必要。XENのモジュール追加は必要。T2インスタンスはHVMのAMIのみに対応
↑

t2/t3シリーズ †

  • 特徴
    • バースト性能を持つ。(EBS General purposeタイプ)
    • メモリがt1より多い
    • 価格がt1より安い
  • t3シリーズ
    • CPUのバーストパフォーマンスのデフォルトがunlimited 。 高負荷が永続するような使い方では、他の固定パフォーマンスのようが安くなる場合もある。
↑

Root Deviceをinstance storeからEBSに変換する †

試行錯誤の結果、rsyncでは失敗し以下の方法で成功した。
EC2起動に失敗する場合、EC2起動時のstatus checkが1/2等になっていた。

  • 例
    • AWS ACCOUNT ID: 000000000000
    • AWS pk: ~/.aws/pk.pem
    • AWS cert: ~/.aws/cert.pem
    • / : root device 10GB
    • /mnt: ephemeral disk 160GB
  1. 移行対象サーバにec2-ami-toolsのインストール 
    wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.zip
unzip ec2-ami-tools.zip
rm ec2-ami-tools.zip
ln -s ec2-ami-tools-1.4.0.9 ec2-ami-tools
  2. instance storeのイメージをephemeral diskに作成 
    export EC2_HOME=~/ec2-ami-tools
~/ec2-ami-tools/bin/ec2-bundle-vol -r x86_64 -e /mnt -d /mnt/ -k ~/.aws/pk.pem -c ~/.aws/cert.pem -u 000000000000
  3. 新しいEBS volumeを作成し、インスタンスにattach
    • AZ: インスタンスと同じ
    • device: /dev/sdf
    • size: 10GB
  4. イメージからEBSに書き込み 
    time dd if=/mnt/image of=/dev/sdf
real    32m42.451s

fsck /dev/sdf

rm -f /mnt/{image,image.*}
  5. EBSをdetach
  6. EBSからsnapshotを作成
  7. snapshotからAMIを作成
    • Kernel ID: aki-xxxxxxxx, RAM Disk ID: ari-xxxxxxxx を元のEC2と同じに合わせる必要がある。特に指定が無い場合は default
  8. AMIからEC2インスタンスを起動
  9. 使い終わった10GBのEBSは削除して良い
↑

EC2 AMI作成時に"The parameter iops is not supported for standard volumes." †

  • ManagementConsoleから下記構成のEBSインスタンスのAMIを取ろうとすると、"The parameter iops is not supported for standard volumes."が発生した 
    Type Device    Snapshot ID Size Volume Type IOPS Delete on Termination
Root /dev/sda1             8    standard         true
EBS  /dev/sdf              10   standard         false
  1. 他の同じ構成のインスタンスでは発生せず。このインスタンスだけ
  2. AMI 作成時に10GB EBSをRemoveすると作成できた
  3. 作成したAMIからEC2を起動し、後からEBS 10GBを付与したインスタンスに対して、AMI作成はできた
↑

EC2でELBのヘルスチェックを許可 †

  • EC2 apache 
    <Files healthcheck.txt>
    Satisfy Any
    Allow from 10.0.0.0/8
</Files>
↑

EC2インスタンス内で取得できる値 †

# GETが無い場合、curl/wgetでも取得可能
# 取得できる値一覧
curl -s -m 1 http://169.254.169.254/latest/meta-data/

# availability-zone (ap-northeast-1a)
curl -s -m 1 http://169.254.169.254/latest/meta-data/placement/availability-zone

# ユーザデータの取得
curl -s -m 1 http://169.254.169.254/latest/user-data
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-06-06 (木) 14:31:29 (10d)