なぜ本番サーバーでは固定パーティションではなくLVMを採用すべきなのか？
監視システムからアラートが届きます。150GBのMySQLデータベースを格納している/dataパーティションのディスク使用率が95%に達しました。従来のGPTやMBRによる静的パーティション構成の場合、頭の痛い課題に直面することになります。メンテナンス時間を確保してサービスを停止し、ディスクをアンマウントした上でGParted等を用いてリサイズしなければなりません。サービス停止を余儀なくされるだけでなく、データ破損のリスクも伴います。
LVM（Logical Volume Manager）はこの問題をスマートに解決します。LVMは物理ストレージとファイルシステムの間の抽象化レイヤーとして機能します。ディレクトリを特定の固定パーティションに直接紐付けるのではなく、複数のストレージドライブをまとめて共有リソースプール（Storage Pool）として扱います。このプールから、実際の需要に応じて柔軟に容量を割り当てることができます。
サーバーを再起動することなく、柔軟に容量を拡張可能です。サービスは稼働し続け、ゼロダウンタイム（無停止）を実現します。
設定を始める前に、LVMの中核となる3層のアーキテクチャを理解しておく必要があります：
- Physical Volume (PV): 物理ストレージデバイスまたはrawパーティション（例:
/dev/sdb、/dev/nvme1n1）。LVMは管理のためにディスクの先頭にメタデータを書き込みます。 - Volume Group (VG): 1つ以上のPVを束ねて構築されたストレージプール。プール内のサービスを中断することなく、いつでも新しいドライブをVGに追加できます。
- Logical Volume (LV): VGから切り出された論理パーティション。このLV上にファイルシステム（ext4、xfs）を作成（フォーマット）し、標準的なディスクと同様にOSへマウントします。
Ubuntu Serverでの環境準備
標準的なUbuntu Server 20.04/22.04/24.04環境には、LVMツールセットがデフォルトでインストールされています。ただし、AWS、Linode、HetznerなどのMinimalイメージを使用している場合は、lvm2パッケージの有無を確認し、必要に応じてインストールしてください：
sudo apt update && sudo apt install -y lvm2既存のブロックデバイス一覧を確認します：
lsblkここでは、50GBの空きディスク/dev/sdbがサーバーに新たに追加されたと想定します。このディスクを使用して、本番環境向けの完全なLVM環境をセットアップしていきます。
実践：ステップ・バイ・ステップでのLVM作成と構成
1. Physical Volume (PV) の初期化
ブロックデバイス/dev/sdbをLVM管理下のPVとして初期化します：
sudo pvcreate /dev/sdb画面に確認メッセージが表示されます：Physical volume "/dev/sdb" successfully created.
2. Volume Group (VG) へのディスク追加・プール作成
先ほど初期化した/dev/sdbを基に、vg_dataという名称のVolume Groupを作成します：
sudo vgcreate vg_data /dev/sdbこれで、vg_dataという50GBのストレージプールが準備できました。将来的に100GBのハードディスク/dev/sdcを追加した場合は、sudo vgextend vg_data /dev/sdcコマンドを実行するだけで、プール容量が即座に150GBへ拡張されます。
3. Logical Volume (LV) の作成とファイルシステムのフォーマット
最初から全容量を割り当てる必要はありません。将来の拡張用として30GBを予備に残し、まずはvg_dataからアプリケーション用パーティション（lv_app）として20GBを切り出します：
sudo lvcreate -L 20G -n lv_app vg_data切り出したパーティション上にext4ファイルシステムを作成します：
sudo mkfs.ext4 /dev/vg_data/lv_appマウントポイントを作成し、ディレクトリツリーにマウントします：
sudo mkdir -p /mnt/data
sudo mount /dev/vg_data/lv_app /mnt/dataサーバー再起動時にも自動マウントされるよう設定します。blkid /dev/vg_data/lv_appコマンドでLVのUUIDを確認し、/etc/fstabファイルに追記します：
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/data ext4 defaults 0 24. ディスク逼迫時のオンラインLogical Volume拡張
3ヶ月の運用を経てアプリケーションのデータが増加し、/mnt/dataの空き容量が残りわずかになったとします。vg_dataに残っている空き領域から15GBを追加拡張する必要があります。
-r（resizefs）オプションを指定してlvextendコマンドを実行します：
sudo lvextend -L +15G /dev/vg_data/lv_app -rこの-rフラグが極めて重要です。LVMに対して論理パーティションを拡張するよう指示すると同時に、マウントされたままのファイルシステム（ext4およびXFSの両方に対応）のリサイズ処理も自動で実行します。別途resize2fsやxfs_growfsコマンドを実行する手間はかかりません。
VG内の残りの空き容量をすべてこのパーティションに割り当てたい場合は、以下の構文を使用します：
sudo lvextend -l +100%FREE /dev/vg_data/lv_app -rデータベースやWebサーバーのI/O処理はそのまま継続されます。接続が切断されることも、サービスが停止することもありません。
効率的なLVMの運用と監視
システム管理者は、各レイヤーを迅速かつ詳細に確認できる3つの基本コマンドセットを押さえておく必要があります：
- Physical Volume: 概要確認には
pvs、Physical Extent (PE) の詳細確認にはpvdisplayを使用します。 - Volume Group: 空き容量（VFree）の確認には
vgs、PEチャンクサイズ（デフォルト4MB）の確認にはvgdisplayを使用します。 - Logical Volume: 各ボリュームのパラメータ確認には
lvs、詳細なmapperパスの確認にはlvdisplayを使用します。
sudo vgs
sudo lvsOS上で認識されているサイズを確認します：
df -hT /mnt/dataアンマウント操作を一切行うことなく、ディスク容量が即座に35GBへ拡張されていることが確認できます。
アラート設定のベストプラクティス：df -hによる使用率（%）の監視だけで済ませてはいけません。LVM環境では、Prometheus Node Exporter等を用いてVolume GroupのVFreeフィールドを監視メトリクスに組み込むことを推奨します。VGの空き容量が15%を下回った段階で早期アラートを発報するように設定しておけば、本番パーティションが枯渇する前にインフラエンジニアが余裕を持って追加ディスクを増設できます。
