11.7. ファイルシステムおよびストレージ

/boot ファイルシステムを LVM に配置することができません。

/boot ファイルシステムを LVM 論理ボリュームに配置することはできません。この制限は、以下の理由により存在します。

  • EFI システムでは、EFI システムパーティション が従来の /boot ファイルシステムとして機能します。uEFI 標準では、特定の GPT パーティションタイプと、このパーティションの特定のファイルシステムタイプが必要です。
  • RHEL 8 は、システムブートエントリーに Boot Loader Specification (BLS) を使用します。この仕様では、プラットフォームのファームウェアが /boot ファイルシステムを読み込める必要があります。EFI システムでは、プラットフォームファームウェアは uEFI 標準で定義された /boot 設定のみを読み取ることができます。
  • GRUB 2 ブートローダーでの LVM 論理ボリュームに対するサポートは完全ではありません。Red Hat は、uEFI や BLS などの標準があるので、この機能のユースケース数が減少しているため、サポートを改善する予定はありません。

Red Hat では、LVM での /boot のサポートを提供する予定はありません。代わりに、Red Hat は、/boot ファイルシステムを LVM 論理ボリュームに配置する必要がないシステムスナップショットおよびロールバックを管理するツールを提供します。

(BZ#1496229)

LVM で、複数のブロックサイズを持つボリュームグループが作成できません。

vgcreate または vgextend などの LVM ユーティリティーでは、物理ボリューム (PV) の論理ブロックサイズが異なるボリュームグループ (VG) を作成できなくなりました。別のブロックサイズの PV で基礎となる論理ボリューム (LV) を拡張するとファイルシステムがマウントに失敗するため、LVM はこの変更を採用しました。

ブロックサイズが混在する VG の作成を再度有効にするには、lvm.conf ファイルの allow_mixed_block_sizes=1 オプションを設定します。

(BZ#1768536)

接続されている LUN が過剰にあると、DM Multipath の起動に失敗する可能性があります。

システムに接続されている論理ユニット (LUN) が多過ぎると、multipathd サービスがタイムアウトし、起動に失敗する可能性があります。問題を引き起こす LUN の正確な数は、デバイスの数、ストレージアレイの応答時間、メモリーおよび CPU の設定、システムの負荷など、複数の要素によって異なります。

この問題を回避するには、multipathd ユニットファイルのタイムアウトの値を増やします。

  1. ユニットエディターで multipathd ユニットを開きます。

    # systemctl edit multipathd
  2. 以下の設定を入力し、タイムアウト値を上書きします。

    [Service]
    TimeoutSec=300

    Red Hat は、デフォルト値の 90 から 300 に値を増やすことを推奨しますが、90 を超える値をテストすることもできます。

  3. エディターでファイルを保存します。
  4. systemd ユニットを再度読み込んで、変更を適用します。

    # systemctl daemon-reload

結果、multipathd は、多数の LUN を使用して正常に起動できるようになりました。

(BZ#1797660)

LVM writecache の制限

writecache LVM キャッシュメソッドには以下の制限がありますが、cache メソッドには存在しません。

  • 論理ボリュームが writecache を使用している場合には、論理ボリュームのスナップショットを取得できません。
  • 論理ボリュームがアクティブな場合には、writecache の割り当てまたは割り当て解除ができません。
  • アクティブではない論理ボリュームに writecache を割り当てる場合は、既存のファイルシステムのブロックサイズに一致する writecache ブロックサイズを使用する必要があります。

    詳細は、man ページの lvmcache(7) を参照してください。

  • writecache がアタッチされている間は、論理ボリュームのサイズを変更することはできません。
  • writecache を使用するデバイスでは、pvmove コマンドは使用できません。
  • writecache を指定した論理ボリュームは、シンプールまたは VDO と組み合わせて使用できません。

(JIRA:RHELPLAN-27987, BZ#1798631, BZ#1808012)

LUKS ボリュームを格納する LVM mirror デバイスが応答しなくなることがあります。

セグメントタイプが mirror のミラーリング LVM デバイスで LUKS ボリュームを格納すると、特定の条件下で応答しなくなる可能性があります。デバイスが応答しなくなると、すべての I/O 操作を拒否します。

耐障害性のソフトウェア定義ストレージに、LUKS ボリュームをスタックする必要がある場合に、この問題を回避するには、Red Hat は セグメントタイプが mirror ではなく raid1 の LVM RAID 1 デバイスを使用することを推奨します。

raid1 のセグメントタイプは、デフォルトの RAID 設定タイプで、mirror の代わりに、推奨のソリューションとしてこのタイプが使用されます。

mirror デバイスを raid に変換するには、「ミラー リングされた LVM デバイスの RAID1 デバイスへの変換 」を参照してください。

(BZ#1730502)

NFS 4.0 パッチにより、オープンな高ワークロードでパフォーマンスが低下する可能性があります。

以前、場合によっては NFS のオープン操作で、サーバー上のファイルが削除されたり、名前が変更されたりするという事実を見落とすというバグが修正されています。ただし、この修正により、多くのオープンな操作が必要とるするワークロードのパフォーマンスが遅くなる可能性があります。この問題を回避するには、NFS バージョン 4.1 以降を使用します。これは、多くの場合においてクライアントに委譲を付与するように改善されています。このため、クライアントがローカルに素早く安全にオープン操作を実行できます。

(BZ#1748451)


このページには機械翻訳が使用されている場合があります (詳細はこちら)。