ログを一時的にローカルに溜める必要があったため、Amazon Linux2023ベースのEC2にアタッチされたEBSボリュームのサイズを拡張しました。
その際に実施した手順と、わたしの勘違いを紹介します。
EC2のボリュームサイズを拡張してみた
■わたしの勘違い
わたしは今までWindowsServerのディスクサイズ変更しかやったことがなく、EC2インスタンスのボリュームサイズはコンソール上で変更すれば完全に適用されるものだと勘違いしていました。
今回ボリュームサイズを増やす作業でAWS公式ドキュメントを見てみると、以下の追加作業を実施しなければいけないことを初めて知ったのです。
- パーティションの拡張作業：
ボリュームの物理的なサイズは拡張されても、その上にあるパーティションは自動的には拡張されません。
Linuxの場合、通常はgrowpartコマンドを使用してパーティションを拡張します。このステップにより、パーティションはボリュームの新しいサイズを認識し、全容量を使用できるようになります。
- ファイルシステムの拡張作業：
パーティションが拡張された後、ファイルシステムも新しいサイズに合わせて拡張する必要があります。
Linuxで最も一般的なファイルシステムの一つであるext4の場合、resize2fsコマンド、xfsの場合、xfs_growfsコマンドを使用します。このステップにより、ファイルシステムはパーティション全体を利用できるようになり、OSは新しい容量を認識し利用できるようになります。
この2つのステップを完了することで、EBSボリュームのサイズ拡張が完全に完了し、新しい容量をフルに活用できるようになります。
それでは、実際の手順を見ていきましょう。
■手順
ボリュームサイズを拡張するためのステップは3つです。
↓
↓
実際に試してみましょう。
■事前準備
実際に試す前に、以下のことに気をつけて実施してください。
- データの安全のため、ボリュームのスナップショットを作成すること
■現在のボリュームの状態確認
まずは現在のボリュームサイズを確認します。
↓コンソール画面で見ると、"8"と表示されています。
インスタンスに接続し、コマンドで見てみると、
[ec2-user@ip-10-0-8-54 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 1.6G 448K 1.6G 1% /run
/dev/nvme0n1p1 8.0G 1.6G 6.5G 20% /
tmpfs 3.9G 0 3.9G 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
tmpfs 782M 0 782M 0% /run/user/0
[ec2-user@ip-10-0-8-54 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
├─nvme0n1p127 259:2 0 1M 0 part
└─nvme0n1p128 259:3 0 10M 0 part /boot/efi
サイズは8gですね。
■ステップ1:AWSコンソールでのサイズ変更
実際に変更していきます。
↓AWSマネジメントコンソールにログインし、「EC2」ダッシュボードに移動から、「Elastic Block Store」セクションの「Volumes」を選択します。
↓サイズを変更するボリュームを選択し、[アクション]メニューから[ボリュームの変更]を選択します。
↓新しいサイズを指定し、[変更]をクリックします。
↓
↓確認ダイアログで[変更]を選択します。
ステップ1:AWSコンソールでのサイズ変更は以上です。
■ステップ2:OSでの変更の反映
[わたしの勘違い]でもお話しした通り、ボリュームサイズをコンソール上で変更すると、見た目上は増えたように思えます。しかし、システムから見ると、パーティションが追加されただけで、現在利用しているパーティションは拡張されていません。
したがって、サイズ変更後は、オペレーティングシステムに別途変更を反映させる必要があります。これはEC2インスタンスのOSに依存します。今回はAmazon Linux2023のAMIを利用しているので、Linuxでの手順で変更を実施ていきます。
↓インスタンスに接続し、以下のコマンドでボリュームのパーティション構造を確認します。
lsblk
[ec2-user@ip-10-0-8-54 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 16G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
├─nvme0n1p127 259:2 0 1M 0 part
└─nvme0n1p128 259:3 0 10M 0 part /boot/efi
↓つぎにパーティションの拡張を行います。以下のコマンドを実行してください。
sudo growpart /dev/nvme0n1 1
[ec2-user@ip-10-0-8-54 ~]$ sudo growpart /dev/nvme0n1 1
CHANGED: partition=1 start=24576 old: size=16752607 end=16777183 new: size=33529823 end=33554399
続いて、ファイルシステムの拡張を行います。使用しているファイルシステムを確認するために、以下のコマンドを実行してください。
df -hT
[ec2-user@ip-10-0-8-54 ~]$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs tmpfs 1.6G 448K 1.6G 1% /run
/dev/nvme0n1p1 xfs 8.0G 1.6G 6.5G 20% /
tmpfs tmpfs 3.9G 0 3.9G 0% /tmp
/dev/nvme0n1p128 vfat 10M 1.3M 8.7M 13% /boot/efi
tmpfs tmpfs 782M 0 782M 0% /run/user/0
"/"にマウントされているファイルシステムを拡張したいので、xfsファイルシステムを拡張するコマンドを実行します。
sudo xfs_growfs -d /
[ec2-user@ip-10-0-8-54 ~]$ sudo xfs_growfs -d /
meta-data=/dev/nvme0n1p1 isize=512 agcount=2, agsize=1047040 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1
data = bsize=4096 blocks=2094075, imaxpct=25
= sunit=128 swidth=128 blks
naming =version 2 bsize=16384 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=4096 sunit=4 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2094075 to 4191227
※xfsファイルシステムを使用していて、resize2fsコマンドを実行すると、以下のエラーが出ます。
[ec2-user@ip-10-0-8-54 ~]$ sudo resize2fs /dev/nvme0n1p1
resize2fs 1.46.5 (30-Dec-2021)
resize2fs: Bad magic number in super-block while trying to open /dev/nvme0n1p1
Couldn't find valid filesystem superblock.
ステップ2:OSでの変更の反映は以上です。
■ステップ3:変更の確認
さいごに変更されたか確認しましょう。以下のコマンドを実行してください。
df -h
[ec2-user@ip-10-0-8-54 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 1.6G 448K 1.6G 1% /run
/dev/nvme0n1p1 16G 1.6G 15G 10% /
tmpfs 3.9G 0 3.9G 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
tmpfs 782M 0 782M 0% /run/user/0
今回のハンズオンは以上です。
■注意点
ボリュームサイズの拡張作業はステップ数が少なく、簡単な作業に思えますよね。一応注意点がありますので、参考にしてください。
- ボリュームのサイズを増やすことはできますが、サイズを小さくできない
- 作業中はデータのバックアップを取ること
- ボリュームタイプによっては、サイズ変更後にパフォーマンスが最適化されるまでに時間がかかることがある
■パーティションとファイルシステムの違い
今回の作業では、「パーティション」と「ファイルシステム」という用語が出てきました。私の中でいみがごっちゃになっているので、まとめておきます。
-
パーティション
パーティションは、物理的なハードドライブを複数の独立したセクションに分割することです。
これにより、1つの物理ドライブ上に複数の「仮想」ドライブを作成できます。たとえば、1つのハードドライブを「Cドライブ」と「Dドライブ」に分けることができます。
各パーティションは、異なるオペレーティングシステムをインストールしたり、特定の種類のデータを分離して保存したりするのに使用できます。
パーティションは、ドライブの物理的な構造を定義しますが、それ自体はデータの保存方法を定義しません。 -
ファイルシステム
ファイルシステムは、データがストレージデバイス（ハードドライブ、SSDなど）上にどのように保存され、組織化されるかを定義します。
ファイルシステムは、ファイルの名前、サイズ、作成日時などのメタデータを管理し、ファイルの保存場所を追跡します。
一般的なファイルシステムには、NTFS、FAT32、exFAT、ext3、ext4などがあります。
ファイルシステムは、オペレーティングシステムがファイルにアクセスし、管理する方法を提供します。
簡単に言うと、パーティションは「物理的なスペースの分割」であり、ファイルシステムは「そのスペースにデータをどう保存するか」です。
まとめ: EC2のEBS拡張 ~Amazon Linux 2023で実践してみた~
AWSの現場で1年以上やってきて、ボリュームサイズ拡張は初めて実施した作業でした。
一旦増やすと元に戻すのが大変なので、コストと相談して実施してみましょう。
参考サイトリンク：AWS公式ドキュメント
↓ほかの協栄情報メンバーのEBSについての記事を公開しています。ぜひ参考にしてみてください。
■EBSボリュームサイズ拡張ハンズオン: EC2 インスタンスのパーティション変更(ishii.shota)
https://cloud5.jp/shota-ebs-partition/
■DLMでEBSのスナップショットを自動的に作成して、EC2インスタンスを復元する方法(higa)
https://cloud5.jp/dlm-snapshot-ami/
■EBSボリューム gp2 から gp3 に変更手順(hebiishi)
https://cloud5.jp/ebs-type-gp2-gp3/
■EC2のEBS拡張後の操作について(dapeng)
https://cloud5.jp/ec2-ebs-extend/