:>/dev/null

ラガードエンジニアの不撓不屈の精神/unlearning/go beyond

AWS EC2インスタンスのEBSボリュームディスク拡張

AWS EC2インスタンスのEBSボリュームディスクが不足したので拡張した時の学習メモ。
対象インスタンスにアタッチ済みボリューム拡張を↓この辺を参考にして事前に済ませておく。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/console-modify.htmldocs.aws.amazon.com

参考に手順を記載。
EC2→対象インスタンス→ルートデバイス→アタッチ済みEBS→(EBS画面へ推移)→アクション→ボリューム変更→変更後のボリュームサイズ指定

事前確認

fdisklsblkで現状確認

$ sudo fdisk -l
GPT PMBR size mismatch (16777215 != 209715199) will be corrected by w(rite).
ディスク /dev/xvda: 100 GiB, 107374182400 バイト, 209715200 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 33E98A7E-CCDF-4AF7-8A35-DA18E704CDD4

デバイス     開始位置 最後から   セクタ サイズ タイプ
/dev/xvda1       4096 16777182 16773087     8G Linux ファイルシステム
/dev/xvda128     2048     4095     2048     1M BIOS 起動


$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
└─xvda1 202:1    0    8G  0 part /

パーティション拡張

growpartを使ってパーティションを拡張

$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=209711071,end=209715167

パーティションが正常に拡張したか確認

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk
└─xvda1 202:1    0  100G  0 part /

ファイルシステム拡張

xfs_growfsを使ってxfsのファイルシステムも拡張を行う (ファイルシステム毎に実行コマンドが違う為、注意)
Amazon Linux (ext4)

$sudo resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 2
The filesystem on /dev/xvda1 is now 7863803 (4k) blocks long.

Amazon Linux 2 (xfs)

$ sudo xfs_growfs /dev/xvda1
meta-data=/dev/xvda1             isize=512    agcount=4, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=2096635, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2096635 to 26213883

インスタンスにアタッチ済みボリュームの拡張が認識されているかOSから確認

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         2.0G     0  2.0G    0% /dev
tmpfs            2.0G     0  2.0G    0% /dev/shm
tmpfs            2.0G  556K  2.0G    1% /run
tmpfs            2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/xvda1       100G  6.0G   94G    6% /
tmpfs            395M     0  395M    0% /run/user/1000
tmpfs            395M     0  395M    0% /run/user/0

まとめ

小さく初めて徐々に容量圧迫が発生するので、無停止でボリューム拡張が出来るのは助かる。
この辺の拡張が手軽に出来るのはPublicCloudの利点だと実感出来る。

また、今回では採用してないですが、「Amazon Web Services実践入門」では下記のボリュームを切り離す方法が説明されてます。

  • EC2インスタンスを停止する
    • 試してみましたが、インスタンスを停止しないと、後に実施する追加ボリュームの切り離しができなかったです。
  • 容量追加する対象ボリュームのスナップショットを取得
  • 対象ボリュームのスナップショットから新規ボリュームを作成する
    • サイズを変更する
    • EC2インスタンスと同じAvailability Zone(AZ)を選択する
  • 元のボリュームを切り離す(デタッチする)
  • サイズ変更した新ボリュームをアタッチする

ref)
https://qiita.com/foursue/items/bb288f32135ec8abac93