production.log

株式会社リブセンスでエンジニアをやっている星直史のブログです。

トップ > 技術 > AWS EC2のルートボリューム(EBS)をダウンタイム0で拡張する方法

AWS EC2のルートボリューム(EBS)をダウンタイム0で拡張する方法

技術

概要

blog.naoshihoshi.com

サービスを公開したと同時に、mackerelを導入してみました。 CPU, Memory, filesystemのアラートをデフォルトの閾値で設定した結果、一瞬でfilesystemのアラートが鳴りました。

f:id:watasihasitujidesu:20180727130724p:plain

すぐさま対応できなかったので、とりあえずアラートを止めるために閾値を変えるというワークアラウンド対応をしました(白目)

ただ、ディスク容量の75%ほど使用していたので、根本的に対応しなければサービス断になると思われるため、ボリューム拡張をすることにしました。 今回はAWS EC2のルートボリューム(EBS)をダウンタイム0で拡張する方法について書こうと思います。

手順

AWSマネコンより、EBSのストレージ拡張

f:id:watasihasitujidesu:20180727132326p:plain
何はともあれ、AWS マネジメントコンソール > EC2 > ELASTIC BLOCK STORE > Volumes画面に行きましょう。 Actionsプルダウンを押下し、Modify Volumeを選択します。

f:id:watasihasitujidesu:20180727132331p:plain
続いて、任意のVolume TypeとSizeを選びます。 今回は、Volume Typeの変更はなく、Sizeを8GiBから16GiBに拡張します。 そして、Modifyボタンを押下。

f:id:watasihasitujidesu:20180727132337p:plain
すると、アラート的なものが表示されます。

Are you sure that you want to modify volume vol-xxxxxxxxxxxxx?
It may take some time for performance changes to take full effect.
You may need to extend the OS file system on the volume to use any newly-allocated space.
Learn more about resizing an EBS volume on Linux and Windows.

=> vol-xxxxxxxxxxxxxを変更してもよろしいですか？
=> パフォーマンスの変更が有効になるまでには時間がかかることがあります。
=> 新しく割り当てられた領域を使用するには、ボリューム上のOSファイルシステムを拡張する必要があります。
=> LinuxおよびWindowsでのEBSボリュームのサイズ変更の詳細については、こちらをご覧ください。

とのこと。Yes!!!

f:id:watasihasitujidesu:20180727132501p:plain
モーダルが閉じたところで、念のため、Sizeが変わったことを確認します。 また、Stateがin-use - completed(100%)になるまで少し待ちましょう。

AWS マネジメントコンソール上の操作は以上です。

EC2インスタンスにSSH接続し、コンソール上で変更の反映

さきほど出てきたアラートの通り、インスタンスにSSHアクセスし、コンソール上からボリューム拡張を反映させる必要があります。

使用しているファイルシステムの確認

file -sコマンドで使用しているファイルシステムを確認します。

$ sudo file -s /dev/xvd*
/dev/xvda:  DOS/MBR boot sector; ......
/dev/xvda1: Linux rev 1.0 ext4 filesystem data, .....

Linux ext4 ファイルシステムと DOS/MBR boot sectorというファイルシステムなのがわかりました。

物理ディスクの確認

インスタンスにアタッチされたブロックデバイスを確認するためにlsblkコマンドを使います。

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

おぉ〜、しっかり16Gibがアタッチされていますね。
この情報から、ルートボリュームである/dev/xvdf1 は、16 GiB のデバイス(/dev/xvda)に含まれる 8 GiB のパーティションでだということがわかります。
また、この/dev/xvdaはパーティションは/dev/xvdf1以外ありません。そのため、ボリュームの残りの領域を使用するために、パーティションのサイズを変更する必要があるということがわかります。

パーティションのサイズ拡張

growpartコマンドでパーティションのサイズ拡張をします。

$ sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=33550302,end=33554398

再び、lsblkコマンドで、意図した変更になっているか確認します。

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

良さそうですね。

ファイルシステム上のディスク領域の変更

このままでは、ディスクのパーティションが切れただけで、ファイルシステムに変更が反映されていません。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         488M   56K  488M    1% /dev
tmpfs            497M     0  497M    0% /dev/shm
/dev/xvda1       7.8G  5.5G  2.2G   72% /

Linux ext4 ファイルシステムの変更反映はresize2fsで行います。

$ 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 = 1, new_desc_blocks = 1
The filesystem on /dev/xvda1 is now 4193787 (4k) blocks long.

最後に変更がうまく行っているか、確認します。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         488M   56K  488M    1% /dev
tmpfs            497M     0  497M    0% /dev/shm
/dev/xvda1        16G  5.5G   11G   36% /

/dev/xvda1のサイズ16Gibになり、使用率が72% => 36%に下がりましたね！

まとめ

AWSマネジメントコンソール上でEBSのSizeをアップし、数分待つことで、容量が増えました。
また、EC2インスタンス上にSSH接続し、パーティションの容量変更とファイルシステムへの反映を行うだけで、インスタンスを停止せずにルートボリュームの拡張を行うことができました。
インスタンス停止せずにボリューム拡張できるのは素晴らしいですね！

mackerelのグラフも、ぴょこんと上がりました！ f:id:watasihasitujidesu:20180727140430p:plain