Memo/AmazonWebServices/EC2

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

EC2(Elastic Compute Cloud) †

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

AZ毎の違い †

  • AWSアカウント毎に、AZ表記(ZoneName)とZoneIDは違う。ランダムにして、特定AZのリソースの偏りを防ぐため？
  • ZoneID毎に作成できるインスタンスタイプが異なる
  • ZoneID: apne1-az[1,2,4]を推奨。az3は作成できない。2020-04時点で
    • apne1-az1: t3a, m5aNG
    • apne1-az2: 旧世代, m5d等NG
    • apne1-az4: t3a含むすべてOK
  • ZoneNameとZoneIDの確認 
    aws ec2 describe-availability-zones --profile example --region ap-northeast-1

{
    "AvailabilityZones": [
        {
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "ZoneId": "apne1-az4",
            "GroupName": "ap-northeast-1",
            "State": "available",
            "NetworkBorderGroup": "ap-northeast-1",
            "ZoneName": "ap-northeast-1a",
            "RegionName": "ap-northeast-1"
        },
...
↑

EC2の休止(ハイバネート) †

  • ハイバネート: メモリの内容をDiskへ保存
  • サスペンド: メモリの内容をそのまま保存
  • Linux インスタンスの休止 - Amazon Elastic Compute Cloud
    • メモリ内容をEBSに保存する事で、起動が速い。
    • 事前にEC2を足しておきたいが、プロセスの起動に時間がかかるようなケースで有用。
    • 対応したAMI, インスタンスのみ
    • EBS、Elastic IPの料金はかかる。
↑

Auto Scaling †

↑

Spot Instance: RIより安いが、指定価格によって終了する †

  • Amazon EC2 スポットインスタンス | AWS
    • 指定した価格よりスポットインスタンスの価格が上がった場合は、EC2が終了する。
    • 終了2分前に中断の通知が発生する
    • Spot InstanceではEBSインスタンスでもstopできず、start/terminateのみ可能
    • EC2はステートレスな利用に向いている
    • ログはS3/CloudWatchに保存するようにする。fluentdを使えば、プロセス終了時にflushできる
↑

トラブルシューティング †

  • EC2のステータスがpending
    • EBSが問題の場合
      • EC2からVolumeをクリック -> 「○○前からボリュームがアタッチ中のまま動いていません。」->ケース作成で、サポートに英語でissueが作成できる。サポートプランがbasicでもOK。
↑

kernel panic: †

↑

EBS operational issueの場合 †

  • 現象
    • EC2がpendingのまま起動しない。
      • 該当EBSのページを表示すると、「○○前からボリュームがアタッチ中のまま動いていません。」->ケース作成で、サポートに英語でissueを作成できる。basicプランでも。
    • Linux上で該当EBSにアクセスするとレスポンスが無い
  • 解決方法：スナップショットを作成し、既存EBSと入れ替える。
  1. EC2をstop
  2. 問題のEBSを選択し、右クリック > スナップショット作成 わかりやい名前を付ける。(<hostname>-root, <hostname>-ebs1等)
    • snapshot作成に失敗する場合があった。「An internal error has occurred」
  3. 古いEBSは削除
↑

Instance Connect: SSHの接続をIAMで管理 †

  • Public IPが必要。
  • 接続元〜EC2へ22/tcpが疎通可能な事。
  • 特定のLinuxディストリビューション
    • Amazon Linux 2, Ubuntu 16.04移行
↑

Nitoro世代インスタンスとNVMeデバイス †

m5, t3シリーズ等。

  • 変更点
    • AMIが対応していないと起動できない。kernelにNVMeドライバが含まれているか。
      • NG: CentOS 6公式
      • OK: CentOS 7公式
    • EBSのデバイス名が違う。CentOS 7公式の場合 
      /dev/nvme0n1p1 / (root volume)
/dev/nvme1n1   /mnt/ebs0
/dev/nvme2n1   /mnt/ebs1
    • fstypeを調べるコマンド 
      sudo file -s /dev/nvme?n*
↑

暗号化 †

↑

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

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

WindowsServer †

↑

Private SubnetのEC2に接続する †

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

↑

削除 †

↑

CPU stealが高い †

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

セキュリティグループ †

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

タグ付け †

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

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の自動変換 †

↑

ベンチマーク †

↑

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

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

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

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>
↑

instance metadata: 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: 2020-05-29 (金) 19:10:35 (7d)