Japan
サイト内の現在位置を表示しています。
ディスクの交換後にLVM論理ボリュームが認識されなくなった時の解決方法と回避策(Linux)
CLUSTERPRO オフィシャルブログ ~クラブロ~はじめに
今回はLVMの論理ボリュームを含むディスクを交換した後に、論理ボリュームが認識されなくなった場合の再認識方法と、回避策をご紹介します。
Linux OSではOS領域用のディスクとは別に2台目以降のディスクを接続すると、OS起動のタイミングでディスクの認識順序が前後することで、デバイスファイル名が入れ変わるデバイスファイルずれの問題が発生することがあります。CLUSTERPRO X for Linuxではディスクリソースやミラーディスクリソース等のディスク系リソースの設定においてデバイスファイル名を指定するため、ずれが発生するとリソースの起動に失敗します。この問題を回避する一つの方法としてLVMの論理ボリュームを使用することが推奨されています。詳細は以下のFAQをご参照ください。
一方で、データ復旧などの理由からLVM論理ボリュームを含むディスクを交換をした後、特定の環境では新しいディスクの論理ボリュームが認識されない現象が発生することがあります。本記事ではこの現象の発生条件と対処方法について説明します。
この記事の内容
1. 発生する現象
LVMの論理ボリュームは、正常に認識されているときは、次の方法で確認することができます。今回の構成ではvg1というボリュームグループと、その下にclusterおよびdataの2つの論理ボリュームがあることがわかります。
■ 論理ボリュームの一覧
$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/vg1/cluster
LV Name cluster
VG Name vg1
:
:
--- Logical volume ---
LV Path /dev/vg1/data
LV Name data
VG Name vg1
:
:
■ ブロックデバイスの一覧
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 10G 0 disk
├─nvme0n1p1 259:1 0 1M 0 part
├─nvme0n1p2 259:2 0 200M 0 part /boot/efi
├─nvme0n1p3 259:3 0 1G 0 part /boot
└─nvme0n1p4 259:4 0 8.8G 0 part /
nvme1n1 259:5 0 10G 0 disk
└─nvme1n1p1 259:7 0 10G 0 part
├─vg1-cluster 253:0 0 1G 0 lvm ★ 論理ボリューム1
└─vg1-data 253:1 0 9G 0 lvm ★ 論理ボリューム2
この論理ボリュームを含むディスク(今回はnvme1n1)の交換後、環境によっては次のように論理ボリュームが認識されず、一覧の出力から確認できなくなる場合があります。
■ 論理ボリュームの一覧
$ sudo lvdisplay
(当該論理ボリュームの情報が出力されない)
■ ブロックデバイスの一覧
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 10G 0 disk
├─nvme0n1p1 259:1 0 1M 0 part
├─nvme0n1p2 259:2 0 200M 0 part /boot/efi
├─nvme0n1p3 259:3 0 1G 0 part /boot
└─nvme0n1p4 259:4 0 8.8G 0 part /
nvme1n1 259:5 0 10G 0 disk
└─nvme1n1p1 259:7 0 10G 0 part
(当該論理ボリュームの情報が出力されない)
2. 発生原因と条件
論理ボリュームの情報が認識・表示されなくなる現象は、LVMのデバイスファイル機能が有効になっているために発生している可能性があります。LVMのデバイスファイル機能が有効になっている場合、PVの認識は/etc/lvm/devices/system.devicesファイルを参照して行われますが、このファイルに書き込まれる情報はデバイスの認識順の変化が考慮されていないため、デバイスずれに相当する事象が発生する可能性があります。
LVMの設定で、デバイスファイル機能が有効になっているかどうかは、次のコマンドで確認可能です。
$ sudo lvmconfig --type full devices/use_devicesfile
実行の結果、use_devicesfile=1と出力された場合はデバイスファイル機能が有効になっています。0であれば無効になっています。
- ※設定ファイル(/etc/lvm/lvm.conf)のuse_devicesfileの値を確認する方法もありますが、ディストリビューションによって記載が省略されていることもあるため、lvmconfigコマンドで確認するのが確実です。
Red Hat Enterprise Linux 9、Oracle Linux 9ではuse_devicesfile=1(有効)、Amazon Linux 2ではuse_devicesfile=0(無効)になっています。ただし、Microsoft AzureのRed Hat Enterprise Linux 9では設定ファイルでuse_devicesfile=0(無効)に設定されているなど環境によっても既定値が異なるため、必ず実機での設定をご確認ください。
3. 解決方法
ディスク交換後に本現象が発生した場合の、論理ボリュームを再認識させるための手順について説明します。
デバイスファイル機能が有効になっている時は、/etc/lvm/devices/system.devicesのファイルに列挙されたデバイスのみが表示および使用可能となります。ディスク交換後の新しいデバイス情報は自動的にはこのファイルに登録されないため、コマンド実行によりファイルに反映することで論理ボリュームの情報を再度認識・表示するようになります。
- 1.ボリュームグループのすべてのデバイスをsystem.devicesファイルに追加します。
$ sudo vgimportdevices --all
- ※他の方法として、'sudo lvmdevices --update --refresh' を実行しても同様の結果となります。
- 2.ボリュームグループの活性化を行います。
$ sudo vgchange -ay
- 3.lvdisplayおよびlsblkコマンドで論理ボリュームが認識されていることを確認します。
$ sudo lvdisplay
$ lsblk
もしもこの方法でうまく認識されない場合は、sudo vgchange -an で一度非活性化するか、またはサーバーの再起動を行います。その後、再度sudo vgchange -ay による活性化を実行することで再認識される可能性があります。
4. 本現象の回避策
本現象の回避策として、予めデバイスファイル機能を無効化することで、ディスク交換後に新しいデバイスおよび論理ボリュームが自動的に認識されるようになり、再認識操作が不要となります。
- 1.設定ファイル(/etc/lvm/lvm.conf)のuse_devicesfileの値を0に変更することでデバイスファイル機能を無効にします。設定ファイルに記載がない場合は、次の一行を追記します。
use_devicesfile=0
- 2.サーバーを再起動します。
- 3.再起動後、デバイスファイル機能が無効(use_devicesfile=0)になっていることを確認します。
$ sudo lvmconfig --type full devices/use_devicesfile
まとめ
今回、CLUSTERPROとLVMを利用した運用環境において知っておいた方がよい情報としてデバイスファイル機能に起因した問題と解決方法を取り上げました。必要があれば本記事を参考にLVM論理ボリュームを含むディスク交換時の再認識手順を把握し、本番環境での運用に備えていただけますと幸いです。
お問い合わせ
本記事に関するお問い合わせは、
お問い合わせ窓口までお問い合わせください。