☰

USBドライブを接続してLVM構成をブートトレラントにするにはどうすればいいですか

tag-icon • tag-icon hard-drive lvm boot
USBドライブを接続してLVM構成をブートトレラントにするにはどうすればいいですか

セットアップ: DELL PowerEdge R520、oVirt Node 4.4.1 x86_64

# pvs
  PV         VG          Fmt  Attr PSize    PFree   
  /dev/sda2  onn_ovirt01 lvm2 a--   105.26g   20.77g
  /dev/sda3  VG_he_nfs   lvm2 a--  <100.00g  <10.00g
  /dev/sda4  VG_data_nfs lvm2 a--    <1.50t <206.00g

# lsblk
...

sdb                                                            8:16   0   1.4T  0 disk 
└─sdb1                                                         8:17   0   1.4T  0 part /exports/nfs/backups

問題: システムを再起動すると、SATA-USB に接続された 1.4T バックアップ ドライブが sda になり、lvm は物理ボリュームに必要なパーティションを見つけられません。その後、システムはレスキュー モードで起動します。このモードでは、接続されたモニター/キーボードからログインし、SATA-USB ドライブをアンマウントして取り出し、fstab からそのエントリをコメントアウトし、プラグを抜いて、システムを再起動する必要があります。その後、正しいデバイスを sda として適切に起動したら、SATA-USB デバイスを使用してレスキュー モードで行ったすべての操作を元に戻す必要があります。

すべては、UUID または /dev/mapper/ でマウントするように fstab ですでに定義されています。

質問: どのデバイスが sda になるかに関係なく、システムに適した物理ボリュームを取得するように LVM 構成を変更することは可能ですか? 再作成と移行なしで可能ですか (システム データはホット スペア付きの RAID 1 (ミラーリング) にあるため、シャーシ内に交換用ドライブ配置のためのスペースはありません)? データの削除や交換用の新しい RAID 配置の作成を必要としないソリューションであれば、どのようなものでも構いません。それが不可能な場合は、実際には何でも構いません。または、予期せず再起動するたびにレスキュー モードで整理を続けるだけです。

答え1

  1. LVM はデバイス パスを保存しません。コンポーネント UUID は LVM スーパーブロックに保存され、これらの UUID はコンポーネント (PV、VG、LV) を識別するためだけに使用されます。LVM は、使用可能なすべてのブロック デバイスをスキャンし (どのデバイスをスキャンできるかは /etc/lvm/lvm.conf で設定)、物理ボリュームを検出し、それらからボリューム グループを組み立てます。この時点では、物理ボリュームのタイプ/デバイス パスは確認しません。デバイスの再インデックス作成などに対して非常に堅牢です。そのため、ボリュームを /dev/cciss/cXdYpZ (古い HP/Compaq SmartArray ブロック ドライバーがこのようなデバイスを作成します)、/dev/hdXY、/dev/sdXY、/dev/mapper/... (DM 上に構築されたものはすべて、暗号、マルチパスなどのデバイス ノードをそこに配置します)、/dev/md/... (Linux MD RAID) などに移動すると、データが見つかります。あなたの懸念は間違っており、問題は別のところにあります。

  2. 問題の原因は、USB の遅さにあるかもしれません。USB には大きなレイテンシがあり、外付けハード ドライブの起動も非常に遅いです (これは、スピンアップ中の電力使用量の急増を制限するためです)。USB はパフォーマンスではなく、経験の浅いユーザーの手による堅牢性に関するものです。そのため、初期化が遅くなります。USB デバイスがスピンアップして安定するのに十分な時間を確保できるように、init スクリプト (おそらく initramfs init スクリプト) を構成して、大きな遅延/タイムアウトを許可する必要があります。

  3. もう一つの典型的な原因は、ブートローダの設定が間違っていることです。たとえば、ブートローダは「最初のハードドライブの最初のパーティション」にデータがあることを期待しますが、「最初のハードドライブ」が間違ったデバイスである場合、ブートするための設定とカーネルイメージがないため、ブートローダーレスキューシェル。カーネルのコマンドラインやinitramfsに入力されたものが特定のデバイスパスに結び付けられている可能性があり、デバイスのスワッピングにより/が見つからなくなり、インストールレスキューシェル。これらは違う救助シェルと理解どれわかりますか？が重要です。

  4. スペア付き RAID0 は矛盾した表現です。RAID0 には冗長性がなく、劣化状態も定義されておらず、デバイス障害からアレイを最適な状態に回復するものがないため、スペアが役に立つ可能性はまったくありません。コンポーネント デバイスに問題が発生すると、通常、アレイ全体が直接障害状態に移行します。他の RAID レベルには冗長性があり、コンポーネント障害が発生するとまず劣化状態に移行するため、スペアのメリットが得られますが、RAID0 にはそれがありません。

答え2

問題は解決しました。次のフィルターに sdb パーティションを追加するだけで済みました/etc/lvm/lvm.conf。

だった：

filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "r|.*|"]

変更後:

filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "a|^/dev/sdb2$|", "a|^/dev/sdb3$|", "a|^/dev/sdb4$|", "r|.*|"]

これを試す人は、変更を確認してキャッシュを再生成してください。vgscan

初めてやってみました（|の後のを忘れました$）:

[root@host lvm]# vgscan
  Invalid separator at end of regex.
  Invalid filter pattern "a|^/dev/sdb2$".
  Failed to create regex device filter

2回目の挑戦:

[root@host lvm]# vgscan
  Found volume group "VG_data_nfs" using metadata type lvm2
  Found volume group "VG_he_nfs" using metadata type lvm2
  Found volume group "onn_ovirt01" using metadata type lvm2

SATA-USB ドライブは依然として sda として表示されますが、これは問題ではありません。LVM は sda に何も見つからない場合、sdb パーティションにスキップします。SATA-USB ドライブを手動でマウントする必要がありましたが、/etc/fstab正しくマウントされているため、 を発行するだけで済みましたmount -a。この問題は後で解決して、とりあえずこれで勝利を収めます。

関連情報