web-dev-qa-db-ja.com

LVM：リブート後にPVがない

私はいくつかのLVM論理ボリュームを持つサーバー（Ubuntu 18.04）を持っています。定期的な再起動後、そのうちの1つが戻らない。いくつかの調査の後、これは私がいるところです：

  • 物理ディスクはiSCSIデバイスであり、カーネルから/ dev/sdcとして認識されます（エラーはなく、正しいサイズ）

  • lvmdiskscan -vは/ dev/sdc上のPVを表示します

 
> lvmdiskscan -v 
 ... 
/dev/sdc [72.76 TiB] LVM物理ボリューム
  • blkidは、LVM構成でも確認できるUUIDを返します
 ... 
/dev/sdc：UUID = "fvUXXf-pVOF-EPnn-c8eg-tZ5S-iMVW-wsSFDy" TYPE = "LVM2_member"

  • このエントリには、システム上の他のLVが持っているPARTUUIDエントリがありません。これは手掛かりですか？私はこの情報を私をさらに助ける何かと全く結びつけることができませんでした。

  • pvscanが/ dev/sdcを報告しない

  • pvdisplayがこのPVを認識していないようです

> pvdisplay /dev/sdc
物理ボリューム「/ dev/sdc」が見つかりませんでした

私を正しい方向に向けることができる人はいますか？

Pvck -tの出力を追加するように編集

 pvck -t /dev/sdc
テストモード：メタデータは更新されず、ボリュームは（非）アクティブ化されません。
/dev/sdc、セクター1にラベルが見つかりました、type = LVM2 001 
テキストメタデータ領域が見つかりました：オフセット= 4096、サイズ= 1044480

また、このLVはもともとUbuntu 14.04で作成されており、Ubuntu 18.04では完全に問題なく動作していることを知るのにも役立ちます。

以下のlvmdiskscanからの追加の出力。この出力は、システム上の他のVGで得られるものと変わりません。 LVは最初は孤立しているように見え、次にVGに関連付けられ、使用可能になります。しかし、r3vgの場合、これは起こりません。

 lvm [7852]：デバイス/ dev/sdcからラベルを読み取ります
 lvm [7852]：オープンされた/ dev/sdc RO O_DIRECT 
 lvm [7852]：/ dev/sdc：ブロックサイズは4096バイトです
 lvm [7852]：/ dev/sdc：物理ブロックサイズは512バイトです
 lvm [7852]：/ dev/sdc： lvm2ラベルがセクター1で検出されました
 lvm [7852]：lvmcache/dev/sdc：VGの＃orphans_lvm2（＃orphans_lvm2）に0 mda（s）が追加されました。
 lvm [7852]：/ dev/sdc：PVヘッダー拡張バージョン2が見つかりました
 lvm [7852]：/ dev/sdc：r3vg（Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00）
 lvm [ 7852]：lvmcacheにVGID "r3vg"の情報がなく、VGID Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00。
 lvm [7852]：lvmcacheにvgname "r3vg"。
 lvm [7852]：lvmcache/devの情報がないsdc：1 mdaのVG r3vgになりました。
 lvm [7852]：lvmcache/dev/sdc：VG r3vg：VGIDをRpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00。
 lvm [7852]：lvmcache/devに設定します/ sdc：VG r3vg：作成ホストをleitrimに設定します。
 lvm [7852]： lvmcache/dev/sdc：VG r3vg：サイズ1015のメタデータチェックサム0x54affad5を保存しました。
 lvm [7852]：クローズ/dev/sdc
 lvm [7852]：/ dev/sdc：キャッシュサイズを使用156250918912セクター
 lvm [7852]：/ dev/sdc [72.76 TiB] LVM物理ボリューム
 lvm [7852]：7ディスク
 lvm [7852]：3パーティション
 lvm [7852]：1つのLVM物理ボリューム全体ディスク
 lvm [7852]：2つのLVM物理ボリューム
 lvm [7852]：グローバル/ notify_dbusを1 
に設定lvm [ 7852]：完了：lvmdiskscan -dddddd
linuxlvm
3
Giuseppe Vacanti

TelcoMによるコメントを読み、さらにログとマニュアルページを掘り下げた後、自分の質問に答えることができます。

何らかの理由で、PV/dev/sdcが属するVGに関する情報が再起動中に失われ、戻ってこなかった。

私は解決策を完全には理解していません（おそらく、詳細を追加できる人がいます）が、次のように機能しました。最初

> vgscan --cache 
メタデータタイプlvm2を使用してボリュームグループ「r3vg」が見つかりました

私のVG構成を見つけます。今PVは再び知られています

> pvs 
/dev/sdc r3vg lvm2 a-- 72.76t 26.39t

LVもまた既知ですが、非アクティブです

> lvscan 
非アクティブ '/ dev/r3vg/p0' [46.37 TiB]継承

そして最後に

> lvchange -ay r3vg/p0

それを戻す。

再起動時にVG構成が選択されないのはなぜかわかりません。誰かが何か提案があれば、コメントにそれらを追加してください。

4
Giuseppe Vacanti

Sudo vgscanおよびSudo vgchange -ayを実行すると、LVはマウント可能になりますか？これらのコマンドでエラーが発生する場合は、おそらく別の問題があり、おそらくそれらのエラーメッセージを元の投稿に追加する必要があります。

しかし、これらのコマンドの後でLVがマウントできるようになった場合は、次を読んでください...

/dev/mapper/vgNAME-lvNAMEのLVM論理ボリュームパス名（例：/etc/fstab）だけでは、ネットワークとiSCSIがアクティブ化されるまで、この特定のファイルシステムをマウントできないという手がかりはシステムに与えられません。

その手がかりがなければ、システムはファイルシステムがローカルディスク上にあると想定し、ネットワークがアクティブ化される前のできるだけ早い段階でマウントしようとしますが、iSCSI LUNで明らかに失敗します。だから、どうにかしてその手がかりを提供する必要があります。

1つの方法は、_netdevをそのファイルシステムのマウントオプションに/etc/fstabで追加することです。 このUbuntuヘルプページ から、Ubuntuでサポートされているようです。これにより、実際にvgscanまたは同様の新しいLVM PV（およびその他の役立つもの）の検出が、_netdevでマークされたファイルシステムのマウントを試みる直前にトリガーされる場合もあります。

別の方法は、systemd固有のマウントオプションx-systemd.requires=<iSCSI initiator unit name>を使用することです。 iSCSIイニシエーターが正常にアクティブ化されるまで、そのファイルシステムのマウントの試行を延期することにより、同じことを実現できます。

ISCSIイニシエーターがアクティブになると、構成されたすべてのLUNが自動的に使用可能になり、それらが使用可能になると、LVMはそれらのすべてのVGを自動アクティブ化する必要があります。したがって、マウントの試行が延期されると、それで十分です。

PARTUUIDの欠如は、ディスク/ LUNにGPTパーティションテーブルがないことの手がかりです。 /dev/sdcはTYPE="LVM2_member"としてリストされているため、実際にはパーティションテーブルはまったくありません。理論的には、これはLinuxに問題を引き起こさないはずですが、私はiSCSIストレージを備えたUbuntu 18.04システムを個人的にテストしたことがないため、確実に特定することはできません。

パーティションテーブルのないディスク/ LUNの問題は、他のオペレーティングシステムがLinux LVMヘッダーをディスクが使用中であることを認識せず、最小限のプロンプトで喜んで上書きすることです。 iSCSIストレージ管理者が誤って/dev/sdcに対応するストレージLUNを別のシステムに提示した場合、これが発生した可能性があります。

不足しているVGに対応する/etc/lvm/backupディレクトリでLVM構成バックアップファイルを見つけ、それを読んで、不足しているPVの予想されるUUIDを見つける必要があります。 blkidが報告する内容と一致する場合は、ストレージ管理者に依頼して、上記のような間違いがないか、最近の作業を再確認してください。 PVが他のシステムによって上書きされていることが判明した場合、LUN上の残りのデータは多かれ少なかれ破損している可能性が高く、新しいものを取得したら、バックアップから復元するのが最善です...iSCSI管理者からの保証された競合のないLUN。

/dev/sdcの実際のUUIDが予想と異なる場合は、誰かが誤ってpvcreate -f /dev/sdcを実行した可能性があります。それだけの場合は、比較的簡単に修正できます。 （注：man vgcfgrestoreの章を確認物理ボリュームの交換更新された手順-LVMツールは私のものより新しい場合があります。）最初にUUIDを復元します。

pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc

次に、VG構成を復元します。

vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>

この後、VGをアクティブ化できるはずです。他に損傷がなければ、その後ファイルシステムをマウントします。

4
telcoM