#概要
こんにちわ!OCEAN'Sの大庭です。
今回は本番で稼働しているEBSの使用量が99%を超えたのでダウンタイムゼロでボリュームを拡張します。
そもそも可能か?
2017年にEBSがUPDATEされ、それ以降はダウンタイム無しでボリューム変更が可能になりました
#サービス稼働中の本番サーバーでボリューム拡張する
まずはじめにWEBサーバーにログインし容量を確認します
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 400G 0 disk
└─xvda1 202:1 0 400G 0 part /
# df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.4G 60K 7.4G 1% /dev
tmpfs 7.4G 0 7.4G 0% /dev/shm
/dev/xvda1 394G 390G 4.2G 99% /
・現在EBSのボリュームサイズ400Gを利用しています。
・使用量99%
・空き容量が4.2G
Aws Management Console上から
EBS→ボリューム→アクション→ボリューム変更を選択
内容を確認し「はい」を選択。
Statusが黄色から、グリーンになれば完了です。
実際に400G→800Gに変更が完了するのに約2時間かかりました。
OS上から確認します
ルートボリュームである、xvdaのSIZEが800Gになっていますが、まだパーティション(xvda1)のサイズは400Gのままです。
※余談ですが2時間まっている間に使用量が100%になりました。急ぎましょう。
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 800G 0 disk
└─xvda1 202:1 0 400G 0 part /
# df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.4G 60K 7.4G 1% /dev
tmpfs 7.4G 0 7.4G 0% /dev/shm
/dev/xvda1 394G 390G 3.8G 100% /
ボリュームに紐づくパーティション(xvda1)の拡張を行います
# growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=838856670,end=838860766 new: size=1677717470,end=1677721566
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 800G 0 disk
└─xvda1 202:1 0 800G 0 part /
# df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.4G 60K 7.4G 1% /dev
tmpfs 7.4G 0 7.4G 0% /dev/shm
/dev/xvda1 394G 390G 3.7G 100% /
└─xvda1 のSizeが800Gになりました
※df -kh のコマンド結果がまだ394Gのままです。
最後にresize2fsコマンドにて、ファイルシステムのサイズを新しいボリューム容量に変更します。
# resize2fs /dev/xvda1
resize2fs 1.43.5 (04-Aug-2017)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 25, new_desc_blocks = 50
The filesystem on /dev/xvda1 is now 209714683 (4k) blocks long.
成功しました。確認します
[root@nadia tmp]# df -kh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.4G 60K 7.4G 1% /dev
tmpfs 7.4G 0 7.4G 0% /dev/shm
/dev/xvda1 788G 390G 398G 50% /
無事に拡張されました!
所感
今回は本番サーバー稼働中にボリュームを拡張しましたが、ダウンタイムはもちろん負荷なども含めサービスへの影響はなく拡張することができました。
ディスクサイズがこれだけ容易に拡張できるとはいい時代になったなとしみじみ思います。