Linux

24時間365日稼働する本番DBやサービスサーバーのディスク使用率が90%を超えた際、メンテナンス停止を伴わずに **「オンライン状態で安全にディスクを拡張できるか」**は現場エンジニアの必須スキルです。 RHEL/Rocky Linux/CentOS (7 〜 9) や Ubuntu (20.04 〜 24.04 LTS) など、仮想化（VMware、KVM、Nutanix、SimpliVity）やクラウド環境において、サーバーの再起動やアンマウント（umount）を行わず、完全無停止でディスクを拡張する標準手順をまとめました。 1. 全体作業フロー（4ステップ） flowchart LR A["1. 仮想ディスク/ストレージ増設"] --> B["2. LinuxカーネルSCSI再スキャン"] B --> C["3. LVM拡張 (pvresize / lvextend)"] C --> D["4. ファイルシステム拡張 (xfs_growfs / resize2fs)"] 2. Step 1: SCSIバス再スキャンによる容量認識 ハイパーバイザ側でディスクサイズを拡張後（例: 100GB -> 200GB）、Linuxカーネルに再認識させます： # 対象ディスクが /dev/sdb の場合 echo 1 > /sys/class/block/sdb/device/rescan # 認識確認 lsblk /dev/sdb dmesg | tail -n 15 3. Step 2: パーティションテーブルの拡張（必要な場合） パーティション（/dev/sdb1）を切っている場合は growpart で拡張します（ディスク直PVの場合は不要）： ...

HPE SimpliVity with VME (VM Essentials) の2ノードクラスタを顧客先に導入する際、ほぼ確実に担当者から次のように要望されます： 「新しく導入した高スペックなSimpliVityサーバー2台の中に、Arbiter（仲裁者）VMも一緒に乗せて全部動かしてください。」 しかし、現場を知るインフラエンジニアであれば、この要望には 2つの重大なジレンマが存在することに即座に気づきます。 1. 現場のジレンマ：『鶏と卵の矛盾』と『ライセンスの罠』 ジレンマ1：SimpliVityストレージ作成前にArbiterが起動していなければならない 2ノードのSimpliVityクラスタは、展開ウィザードを実行する前にArbiter IPとの通信が確立していなければクラスタ作成を開始できません。まだノード初期化も終わっておらずストレージプールも存在しない状態で、SimpliVity上にArbiter VMを作成することは不可能です（鶏と卵の矛盾）。 さらに、Arbiterはスプリットブレインを防ぐ「審判」の役割を果たすため、自身が判定するストレージ基盤の内側に同居させることは絶対的な禁忌です。 ジレンマ2：VME GUIから作ると高額な有料ライセンスが請求される では、Arbiterはどこに配置すべきか？ 答えは VME Managerアプライアンスが稼働している外部管理ホスト（KVMベース）です。 しかし、ここでVME ManagerのWeb GUIコンソールから管理ホストを正式登録してVMを作成しようとすると、管理ホストの全物理CPUコアがVMEの有料ライセンス対象としてカウントされてしまいます！ わずか2コアの軽量なArbiter VMのために高価なライセンスを追加購入するのは現実的ではありません。 flowchart TD A["顧客要望: 『新規SimpliVityサーバーにArbiterも乗せて』"] --> B["ジレンマ: クラスタ展開前にArbiterが必須（鶏と卵）"] B --> C["解決策: 外部管理ホスト（VME Managerホスト）に配置"] C --> D{"VME ManagerのGUIから作成する？"} D -- "YES" --> E["❌ 警告: ホスト全CPUコアにVMEライセンス課金が発生！"] D -- "NO: エンジニアの現場ノウハウ" --> F["✅ KVM CLI(virt-install) + VNCでライセンス課金ゼロ構築！"] 2. 16年目エンジニアの実践的解決策：KVM CLI + VNCの組み合わせ 解決策は非常にシンプルです。 VME ManagerホストのOS（BaseOS）は 標準のLinux KVM / libvirt基盤です。 ...