Memo/AmazonWebServices/EC2/EBS

EBS(Elastic Block Store) †

• 記事

---

EBS snapshotを他AWSアカウントと共有 †

• Amazon EBS スナップショットを他の AWS アカウントと共有する - Amazon EBS

  aws ec2 modify-snapshot-attribute \
      --snapshot-id snap-0abcdef1234567890 \
      --attribute createVolumePermission \
      --operation-type add \
      --user-ids 123456789012 111122223333

---

汎用SSD: gp3 †

• 汎用 SSD ボリューム (gp3)
  • ec2のみで、RDS等はまだ。
  • IOPS: 3000 、スループット: 125MB/sが容量以外の無料範囲。それ以上だと追加コストがかかる
  • 無料範囲でもIOPSの向上、コスト削減効果(AWS Cost Optimization Hubで提案される)がある

• gp2からgp3へ変換
  • 旧世代インスタンスでも gp3 EBS ボリュームが利用可能になりました - サーバーワークスエンジニアブログ
  • AWS CLI で EBS ボリュームタイプを gp2 から gp3 に変更してみた #reinvent | DevelopersIO

• 記事
  • EBS ボリュームタイプを gp2 から gp3 に変更する際に検討したこと #reinvent | DevelopersIO
  • 【速報】低コストでプロビジョニング可能！新しいEBSボリュームのgp3が発表されました！#reinvent | DevelopersIO

---

バックアップ †

AWS Backupとがある。

• Backup: 定期バックアップ用途。削除、保護、対応リソースが多い。
• EBS snapshot: S3にバックアップを作るので、多少時間はかかるが安め。
• EBS Volume Clones: 高速にEBS cloneを作りたい時。EBS料金+データ量の従量
  • [アップデート] EBSボリュームのクローンを高速に作成できるようになりました | DevelopersIO

• AWS DLM~: backupができたので使わなくて良い。

記事

• [アップデート] EBSボリュームのクローンを高速に作成できるようになりました | DevelopersIO
• [AWS] EBS の Fast Snapshot Restore（FSR）を DLM で管理する ｜ Developers.IO

1台のEBSを複数のEC2へマルチアタッチ †

今の所使い道に困る機能。

• 2台以上のEC2から、同じEBSをアタッチできる。
• 同じファイルを2台のEC2から、同時に見えない。

記事:

• [アップデート]Amazon EBSの複数インスタンスへのアタッチが可能になりました！(プロビジョンドIOPS io1ボリュームに限る) ｜ Developers.IO

---

EBSの自動拡張 †

• 記事
  • AWS Step Functions と AWS Systems Manager を使用して、Amazon EBS ボリュームのサイズ変更を自動化する | Amazon Web Services ブログ

---

EBSの動的拡張 †

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

• 記事
  • EC2 Windowsのストレージ(EBSボリューム)の容量を拡張する手順 | Developers.IO
  • lsblk が更新されないときに調べること ｜ DevelopersIO
  • ご存知でしたか？EC2インスタンスは再起動なしにディスクサイズ(EBSボリュームサイズ)を増やせます ｜ DevelopersIO

---

EBSのデバイス名 †

• Linux インスタンスの Amazon EBS および NVMe - Amazon Elastic Compute Cloud
  • t3, m5等 NVMe EBS 対応のインスタンスタイプ + 対応OS(CentOS 7.x) ではEBSデバイス名が「/dev/nvme[0-26]n1」になる
  • t2, m4等のEBSデバイス名は「/dev/sdf 〜」

---

EBSのライフサイクル †

• Memo/AmazonWebServices/Backup EBS, RDS, DynamoDB等複数を対象
• Memo/AmazonWebServices/EC2/DLM EBSのみ対象

---

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

• 記事
  • EC2インスタンスで利用するLVMの基本 – サーバーワークスエンジニアブログ

---

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

• Linux インスタンスでのデバイスの名前付け

• 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ボリュームの場合は再起動が必要

• /dev/xvda1 等のパーティションがあるAMI(CentOS 6 (x86_64) - with Updates HVM)で、resize2fsがうまくいかない場合。

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の設定が上書きされてしまう。

---

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

• 記事
  • Amazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください | Developers.IO

---

Marketplace codes may not be attached †

• インスタンスへの Amazon EBS ボリュームのアタッチ
  • EBSにMarketplace 製品コードがある場合、同一AMIインスタンスがstopしていればアタッチできるようになった。
  • デタッチする場合も、EC2を停止する必要があった

• 記事
  • ルートデバイスにアタッチされたボリュームをスナップショットから作成したボリュームに入れ替える方法 ｜ DevelopersIO
  • AWS Marketplace AMIから起動したインスタンスのRootVolumeを他インスタンスにアタッチする方法 | cloudpack.media
  • EC2 に SSH できない時の対処法、あるいは Marketplace の AMI を気軽に選ぶべきでない理由 · takus's blog

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

---

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

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

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

• 記事
  • CentOS7の/etc/fstabのnofailオプション（あるいはsystemd） - Qiita ディスクのマウントに失敗してもブートしてほしいときには、/etc/fstabでnofailオプションを付けます。

• /etc/fstab
  • OK: /dev/xvdb /mnt auto defaults,nofail 0 0
  • NG: /dev/xvdb /mnt ext3 defaults 0 0

Software

• 自作ソフト
• wiki自作プラグイン
• 利用規定
• ランキング
• 雑誌等掲載履歴

Programming

Game

雑記

連絡先

---

• MenuBar
• RightBar
• :admin
  

人気の10件

最新の10件

---