Memo/AmazonWebServices/EC2

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

EC2(Elastic Compute Cloud)

  • Spot InstanceではEBSインスタンスでもstopできず、start/terminateのみ可能
  • EBSインスタンスでEC2 > Create Imageを実行すると自動的に再起動がかかるので注意。Volume > snapshotでは再起動しない。調子の悪いインスタンス(retirement対象等)だと二度と起動しない場合もあるので、sshで入れるうちにエフェメラルディスク等にデータを置いてある場合は他の場所にコピーする事

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で強制停止例
    1. 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
    1. sudo mkfs.ext4 /dev/xvdf
  • パーティションが有るEBS: /dev/xvdf1
    1. # fdiskやpartedでパーティションを作るとresize2fsが失敗するようになる。
    2. sudo parted /dev/xvdf
    3. sudo mkfs.ext4 /dev/xvdf1
  • CentOS 6.x 64bitの場合:
    1. sudo yum install --enablerepo=epel cloud-utils-growpart parted
    2.  
    3. # パーティション1を拡張。結構時間がかかる
    4. sudo growpart /dev/xvdf 1
    5.  
    6. # パーティションサイズが増えている事を確認
    7. sudo parted -l
    8.  
    9. # resize2fsを実行。先にe2fsckを実行するように指示される。
    10. sudo resize2fs /dev/xvdf1
    11. Please run 'e2fsck -f /dev/xvdf1' first.
    12.  
    13. # e2fsckでチェック。これも結構時間がかかる
    14. sudo e2fsck -f /dev/xvdf1
    15.  
    16. # OSからパーティションサイズが正しく認識されるように
    17. sudo resize2fs /dev/xvdf1
    18.  
    19. sudo mkdir /mnt/ebs1
    20. sudo mount /dev/xvdf1 /mnt/ebs1
    21.  
    22. # 必要であれば/etc/fstabにも追加
    23. echo "/dev/xvdf /mnt/ebs1 ext4 defaults,nofail,comment=manual 0 0"
    24.  
    25. # OSから正しく認識されたか確認
    26. df -h
  • rootボリュームの場合は再起動が必要
  1. パッケージを追加
    1. sudo yum install cloud-init dracut-modules-growroot cloud-utils-growpart
  2. dracutで修正。この時現在のkernelしか指定できなかった。それ以外のinitramfsを指定すると起動しなくなった。
    1. dracut --force --add growroot /boot/initramfs-$(uname -r).img
  3. cloud-initの設定で growpart を実行するように指定
    1. cat /etc/cloud/cloud.cfg
    2.  
    3. resize_rootfs_tmp: /dev
    4.  
    5. cloud_init_modules:
    6.  - growpart
    7.  - 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起動時にコマンド実行

  • Linux インスタンスでの起動時のコマンドの実行
    • CentOS 7 with updates, Amazon Linux AMI等デフォルトでcloud-initが入っている
    • ログ:/var/log/cloud-init.log
    • user-dataの行頭が"#!"の場合はシェルスクリプト、"#cloud-config"の場合はcloud-initとして処理される
    • 1度目のテストをするには
      1. sudo rm -rf /var/lib/cloud/*
  • サンプル
    • 起動後にyum updateを実行しない
    • ホスト名を変更しない
    • ephemeral0 を /mnt にマウントさせない
    • swap 専用デバイス(m1.small, c1.mediumのみ)があれば付ける
    • デバッグログを /var/log/cloud-init-output.log に出力する
      1. #cloud-config preserve_hostname: True repo_upgrade: none mounts: - [ swap, none, swap, sw, 0, 0 ] - [ ephemeral0, null ] - [ ephemeral1, null ] - [ ephemeral2, null ] - [ ephemeral3, null ] mount_default_fields: [~, ~, 'auto', 'defaults,nofail', '0', '2'] output: { all : '| tee -a /var/log/cloud-init-output.log' }

グローバルIPを取得


NTP


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

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


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

  • ManageMentconsole?から拡張して起動した場合
    1. #  m1.largeの例
    2. resize2fs /dev/xvde1
    3. reboot
  • 上記でエラーが出るケースや、パーティションを切ってある場合
    • m1.largeの例。ManageMentconsole? からROOTデバイスを40GBに拡張した場合
      1. fdisk /dev/xvde
      2. ----
      3. Command (m for help): p
      4. ...
      5. Device Boot Start End Blocks Id System
      6. /dev/xvde1 * 1 1044 8385898+ 83 Linux
      7. ----
      8. Command (m for help): d
      9. Selected partition 1
      10. ----
      11. Command (m for help): n
      12. Command action
      13. e extended
      14. p primary partition (1-4)
      15. p
      16. Partition number (1-4): 1
      17. First cylinder (1-5221, default 1):
      18. Using default value 1
      19. Last cylinder, +cylinders or +size{K,M,G} (1-5221, default 5221):
      20. Using default value 5221
      21. ----
      22. Command (m for help): p
      23. ...
      24. Device Boot Start End Blocks Id System
      25. /dev/xvde1 1 5221 41937651 83 Linux
      26. ----
      27. Command (m for help): w
      28. ...
      29. ----
      30. reboot
      31.  
      32. resize2fs /dev/xvde1
      33. df -h
      34. Filesystem Size Used Avail Use% Mounted on
      35. /dev/xvde1 40G 2.6G 35G 7% /
      36. ...

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シリーズ

  • 特徴
    • バースト性能を持つ。(EBS General purposeタイプ)
    • メモリがt1より多い
    • 価格がt1より安い

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のインストール
    1. wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.zip
    2. unzip ec2-ami-tools.zip
    3. rm ec2-ami-tools.zip
    4. ln -s ec2-ami-tools-1.4.0.9 ec2-ami-tools
  2. instance storeのイメージをephemeral diskに作成
    1. export EC2_HOME=~/ec2-ami-tools
    2. ~/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に書き込み
    1. time dd if=/mnt/image of=/dev/sdf
    2. real    32m42.451s
    3.  
    4. fsck /dev/sdf
    5.  
    6. 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
    1. <Files healthcheck.txt>
    2.     Satisfy Any
    3.     Allow from 10.0.0.0/8
    4. </Files>

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

  1. # GETが無い場合、curl/wgetでも取得可能
  2. # 取得できる値一覧
  3. curl -s -m 1 http://169.254.169.254/latest/meta-data/
  4.  
  5. # availability-zone (ap-northeast-1a)
  6. curl -s -m 1 http://169.254.169.254/latest/meta-data/placement/availability-zone
  7.  
  8. # ユーザデータの取得
  9. curl -s -m 1 http://169.254.169.254/latest/user-data

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-08-17 (金) 14:26:05 (4d)