もくじ
先に結論
2つの方法を検討する
- AMIからボリューム拡張した複製サーバを作成する
- EC2インスタンスを停止させてからEBS拡張する
例外として、
ローカルIPの変更が許されない場合に、スナップショットを取得したうえでEC2を動作させながらEBS拡張する。
理由として、シンプルに行うことがシステム稼働の安全につながる。
// 2017年頃のAWS EBSのアップデートにより、EC2稼働中のルートディスクも拡張できるようになっている
// VPCで作成されたEC2であれば、EC2のローカルIPは固定される。
一番安全な方法
- スナップショットからボリュームを複製してAMIから複製サーバを作る
- EIPを切り替える
最も安全な方法。
何が起こっても切り戻しができる
動かしながらがボリューム変更するのが良いでしょ?
EBSの拡張は問題なく出来るけれど、パーティションのリサイズで問題がでる場合がある。
- ディスクに書き込みが激しい場合は、アプリを止めないといけないので良くない場合がある
- 実際に動かしながら拡張できるかは環境による
サービスを運営をしながらで、常にディスクがビジーだと思うように作業ができないので危険。
ローカルIPの変更が許されない場合
- ボリュームの拡張前にスナップショットで複製してバックアップしておく
- インスタンスの停止からEBSを拡張する
以下はローカルIPの変更が許されない場合かつ、
- EC2インスタンスを停止してから拡張する場合
- EC2インスタンスを動かしたまま拡張する場合
※VPC内で構築していればローカルIP変更は起きない。
EC2インスタンスを停止してから拡張する場合
EC2インスタンスを停止してからAWSコンソールからEBSの拡張を行った。
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 476M 0 476M 0% /dev tmpfs 493M 0 493M 0% /dev/shm tmpfs 493M 392K 493M 1% /run tmpfs 493M 0 493M 0% /sys/fs/cgroup /dev/xvda1 30G 1.4G 29G 5% / tmpfs 99M 0 99M 0% /run/user/1000
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 30G 0 disk mqxvda1 202:1 0 30G 0 part /
拡張出来ている
簡単でいいね!
EC2インスタンスを動かしたまま拡張する場合
$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 979M 0 979M 0% /dev tmpfs 996M 0 996M 0% /dev/shm tmpfs 996M 404K 996M 1% /run tmpfs 996M 0 996M 0% /sys/fs/cgroup /dev/xvda1 8.0G 1.5G 6.6G 18% / tmpfs 200M 0 200M 0% /run/user/1000
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk mqxvda1 202:1 0 8G 0 part /
ここでAWSコンソールからEBSの拡張を行った
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 979M 0 979M 0% /dev tmpfs 996M 0 996M 0% /dev/shm tmpfs 996M 436K 996M 1% /run tmpfs 996M 0 996M 0% /sys/fs/cgroup /dev/xvda1 8.0G 1.5G 6.6G 18% / tmpfs 200M 0 200M 0% /run/user/1000
変わらない。
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 15G 0 disk mqxvda1 202:1 0 8G 0 part /
ディスク自体は拡張しているが、パーティションは変わっていない
# growpart /dev/xvda 1 CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=31453151,end=31457247
# resize2fs /dev/xvda1 resize2fs 1.42.9 (28-Dec-2013) resize2fs: Bad magic number in super-block while trying to open /dev/xvda1 Couldn't find valid filesystem superblock.
ルートディスクがXFSの場合はresize2fsは使えない時に出るエラー
ファイルシステムの確認
# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on devtmpfs devtmpfs 1001816 0 1001816 0% /dev tmpfs tmpfs 1019724 0 1019724 0% /dev/shm tmpfs tmpfs 1019724 436 1019288 1% /run tmpfs tmpfs 1019724 0 1019724 0% /sys/fs/cgroup /dev/xvda1 xfs 15716332 1499168 14217164 10% / tmpfs tmpfs 203948 0 203948 0% /run/user/1000
/dev/xvda1の/はXFSである
パーティションの拡張
# 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 3931643
確認する
# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 979M 0 979M 0% /dev tmpfs 996M 0 996M 0% /dev/shm tmpfs 996M 436K 996M 1% /run tmpfs 996M 0 996M 0% /sys/fs/cgroup /dev/xvda1 15G 1.5G 14G 10% / ←●ここ tmpfs 200M 0 200M 0% /run/user/1000
認識した