特定バージョンのカーネルでDataKeeperの同期に失敗する。 /var/log/messages に以下のログが繰り返し出力されます。 Apr 18 13:05:59 node1 nbd-client: Begin Negotiation Apr 18 13:05:59 node1 nbd-client: size = 53684994048 Apr 18 13:05:59 node1 nbd-client: Negotiation Complete Apr 18 13:05:59 node1 nbd-client: Ioctl/2 failed: Device or resource busy Apr 18 13:05:59 node1 kernel: block nbd1: Device being setup by another task RHEL8.0~8.2, Oracle Linux UEK R5 (kernel-4.14.35-*) をご利用の場合、それぞれRHEL8.3以降、UEK R6以降にアップデートしてください。 |
再同期中に 3 番目のノードへの拡張が失敗する DKリソース (ミラー) では、再同期の進行中にミラーを 3 番目のノードに拡張しようとすると、再同期の進行中にミラーを 「拡張」 できないため、3番目のノードへの拡張は失敗します。 次のようなエラーが発生します。 removing hierarchy remnants getId: /opt/LifeKeeper/lkadm/subsys/scsi/CPQARRAY/bin/getId -i “/dev/sdb1” returned “” getId: /opt/LifeKeeper/lkadm/subsys/scsi/device/bin/getId -i “/dev/sdb1” returned “360022480e2671ceb01246bb1c5d67ebd-1” mdadm: /dev/md0 is performing resync/recovery and cannot be reshaped Failed to grow array (1) |
RHEL 8.6 / 9.0 のカーネルではシンプロビジョニングされたディスクで DataKeeper 非同期モードをサポートしません
RHEL 8.6 / 9.0 のカーネルではカーネルパニックが発生することが確認されています。アップストリーム修正を含む更新されたカーネルを提供するために Red Hat と協力していますが、ディスクがシンプロビジョニングされている場合、RHEL 8.6 / 9.0 のカーネルでは非同期ミラーを構成しないことを推奨します。RHEL 8.6 / 9.0 のカーネルで LifeKeeper をインストールまたは更新すると、これについて警告が表示されます。 |
非同期モードで作成し同期モードで拡張した DataKeeper リソースの構成はサポートされません 非同期モードで作成し同期モードで拡張した DataKeeper リソースでは、ミラーを読み書きしているプロセスがカーネル内でハングアップすることがあります。 DataKeeper リソースの同期モードの判定方法は、以下のコマンドを各ノードで実行してください。0 は同期モードで、非 0 は非同期モードです。全ノードで、全て同期モードもしくは全て非同期モードであれば問題ありません。いずれかのノードで、同期モードと非同期モードが混在している場合は、本問題が発生し得る構成です。 回避策 : 直接回避する方法はありません。DataKeeper リソース階層を再作成して、作成・拡張時にどちらも同期モードを選択してください。 |
カーネル 4.12 以降を実行している場合、総セクタ数が奇数になるパーティションはサポートされません 総セクタ数が奇数になるパーティションの使用は、カーネル 4.12 以降を実行している環境の DataKeeper ミラーではサポートされていません。これは、ディスクの終端を超えて書き込みをしようとした場合に再同期が失敗するという問題に起因します。 |
LVM 構成における DataKeeper for Linux 非同期モードに関する注意事項 複数の非同期ミラー上に LVM を構成すると、データの整合性が保てず、さらには kernel panic が発生する場合があります。 DataKeeper 上に LVM を構成する場合には、DataKeeper ミラー 1 つだけ、または複数の同期ミラー、いずれかの構成でなければなりません。 |
両方のサーバに重要な I/O トラフィックを持つシンメトリックなアクティブ SDR 設定で、netraid デバイス (ミラー) にマウントされたファイルシステムが応答を停止し、結果的にシステム全体がハングします Linux バッファキャッシュの単一スレッドの特性により、バッファキャッシュフラッシングデーモンは、リモートでコミットする必要があるバッファをフラッシュアウトしようとしてハングする可能性があります。フラッシングデーモンがハングすると、クリアされていないバッファの数がシステムで許容されている上限 (/proc/sys/kernel/vm/bdflush で設定) を超えると、クリアされていないバッファを持つ Linux システムのすべてのアクティビティが停止します。 これは、リモートシステムがリモートバッファを消去できなくなるような事態でないかぎり、通常は深刻な問題ではありません。LifeKeeper はネットワークの障害を検出し、そのときにレプリケーションを停止するので、ハング状態は消去されます。ただし、リモートシステムがローカルシステムにもレプリケートされた場合 (つまり、相互がシンメトリカルにレプリケートされた場合)、両方のシステムでこのフラッシングデーモンのハング状態が発生すると、永久にデッドロックする可能性があります。 デッドロックを解除するには、両方のシステムの nbd-client デーモンを手動で停止します (これにより、ミラーが切断されます)。ただし、このデッドロックを完全に防止する場合は、シンメトリックアクティブレプリケーションを推奨しません。 |
大きなミラーサイズを備えた md_raid1 プロセスではトップで高い CPU 使用率がレポートされます mdX_raid1 プロセス (X はミラー番号) では、非常に大きなミラー (500GB 以上) を操作している際に、一部の OS ディストリビューションで高い CPU 使用率がトップで報告されることがあります。 解決方法: CPU の使用率を減らすには、LifeKeeper 設定 LKDR_CHUNK_SIZE でチャンクサイズを 1024 に変更し、この新しい設定を使用するためにミラーを削除して再作成します。 |
DataKeeper リソースで lkbackup を使用する場合は、全同期が必要です lkbackup では instance と mirror_info ファイルを保存しますが、リソースが存在しないときにソースおよびターゲットの状態は保証されないため、lkbackup から restore した後で、DataKeeper ミラーの全同期を実行することがベストプラクティスです。 |
SLES12 SP1 以降でデータ圧縮機能を使用することはサポートしていません パフォーマンスの問題があるため、SLES12 SP1 以降でデータ圧縮機能を使用することはサポートしていません。 |
特定バージョンのカーネルでは DataKeeper の非同期モードはサポートしていません。 LifeKeeper for Linux において DataKeeper リソースの非同期モード設定を使用すると、特定バージョンのカーネルでカーネルパニックが発生することが確認されています。本事象はカーネルに依存した問題であるため、LifeKeeper による根本的な解決方法はありません。DataKeeper の非同期モード設定をご利用いただくには、カーネルのアップデート、またはダウングレードが必要となります。 DataKeeper の非同期モードを利用できないカーネルバージョンは次の通りです。 カーネルのアップデート(またはダウングレード)が不可能である場合には、DataKeeper では非同期モードを利用しないようにしてください。 |
一部のカーネルバージョンでは Secure Boot 機能をサポートしていません RHEL7、RHEL8、およびそれらの互換OSで Secure Boot を有効にしていると、nbd モジュールのロードに失敗します。また、SUSE Linux Enterprise Server、Oracle Linux UEK kernel においても、一部のカーネルバージョンでは、Secure Boot を有効にしていると、md/raid1カーネルモジュールのロードに失敗します。 解決方法: 以下のいずれかの対応を行ってください。(1) を推奨します。また、いずれの方法も OS 再起動が必要です。 |
コミュニケーションパス復旧時にミラーリングが停止することがあります 通信障害から回復し再同期が行われる際、同期のためのプロセスが複数起動します。タイミングによっては、一方のプロセスの処理により、もう一方のプロセスの初期化がブロックされるため、再同期が停止状態となります。 通信障害から回復後、以下のような状況を全て満たす場合、本事象に該当します。
対処策 : DataKeeper リソースが In Service になっているノードを再起動する。 それでも直らない場合は、サポートにお問い合わせください。 |
このトピックへフィードバック