EC2インスタンスのボリューム拡張をダウンタイムなしで実施した話
お久しぶりです
多忙であまり書けてませんでした。
弊社で利用しているjenkinsサーバー(AWS EC2インスタンス)にて、アタッチしているEBSの空き容量がカツカツになってきたので拡張したいと思います。
参考にしたのはこちら
前準備
前準備というよりは確認ですね。
## ブロックデバイスを表示するコマンド
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
abcdn1 259:0 0 150G 0 disk
├─abcdn1p1 259:1 0 150G 0 part /
└─abcdn1p128 259:2 0 1M 0 part
## 対象のデバイス
## 150GBしかない状態
$ df -h | grep abcdn1
/dev/abcdn1p1 150G 125G 26G 83% /
ほんとカツカツ。
不要なジョブの削除などを行って対応してましたが、ボチボチしんどくなってきたのでストレージ拡張を提案した次第です。
「ダウンタイムなし」とは言ったものの、流石にバックアップは取りたい。
- 対象インスタンスにSSHログインし、dockerなどを停止
- AWSのコンソールにて、対象のEC2インスタンスを停止
- ルートデバイスとして表示されている「/dev/xvda」のスナップショット作成開始
- 2,3分で完了
- 対象インスタンスを起動
- SSHログイン後、dockerなどを起動し各種サービスを手動で起動
とりあえずスナップショットは取得しました。
ちなみに業務時間中のお昼休みに作業を行ったので、
$$誰も利用していない = 利用されてないからダウンしていない$$
ってことにしておきます。
集計バッチとかは、当日であればいつ動作しても支障がないように組んであるので問題ありませんでした。
EBSのサイズ拡張
- AWSコンソールにて
- EC2→インスタンス→対象インスタンスを選択
- [説明]→ルートデバイスに表示されているEBS IDからデバイスを開く
- アクション→ボリュームの変更→サイズを変更
- デバイスの容量拡張開始 → 完了まで1時間ほどかかりました
150GB → 500GBへの拡張で約１時間ほど要しました。
想定よりも長かったです。
## 「abcdn1」デバイスの容量が500GBになったが、
## パーティションの容量はまだ150GBのまま
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
abcdn1 259:0 0 500G 0 disk
├─abcdn1p1 259:1 0 150G 0 part /
└─abcdn1p128 259:2 0 1M 0 part
デバイスの容量は増やしたのでパーティションの領域を拡張
## ルートボリューム「abcdn1」の「abcdn1p1」パーティションを拡張
$ sudo growpart /dev/abcdn1 1
CHANGED: partition=1 start=4096 old: size=314568671 end=314572767 new: size=1048571871,end=1048575967
## 「abcdn1p1」パーティションが拡張された
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
abcdn1 259:0 0 500G 0 disk
├─abcdn1p1 259:1 0 500G 0 part /
└─abcdn1p128 259:2 0 1M 0 part
## しかし、まだストレージ自体は150GBしかない状態
$ df -h | grep abcdn1
/dev/abcdn1p1 150G 125G 26G 83% /
ファイルシステムの拡張を行わないといけない模様。
## 「/dev/abcdn1p1」のファイルシステムを拡張
$ sudo xfs_growfs /dev/abcdn1p1
data blocks changed from 39321083 to 131071483
## 正常に認識されました
$ df -h | grep abcdn1
/dev/abcdn1p1 500G 125G 376G 25% /
docker、及びdocker-composeが動作している状態でもEBSの拡張ができました。
とはいえ保険としてバックアップは必要で、バックアップ時にはインスタンス停止させるんですけども。