データレプリケーション – 既知の問題と制限

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

非同期モードで作成し同期モードで拡張した DataKeeper リソースの構成はサポートされません

非同期モードで作成し同期モードで拡張した DataKeeper リソースでは、ミラーを読み書きしているプロセスがカーネル内でハングアップすることがあります。

DataKeeper リソースの同期モードの判定方法は、以下のコマンドを各ノードで実行してください。0 は同期モードで、非 0 は非同期モードです。全ノードで、全て同期モードもしくは全て非同期モードであれば問題ありません。いずれかのノードで、同期モードと非同期モードが混在している場合は、本問題が発生し得る構成です。
perl -nle 'my @x = split(/\x01/, $_); print "$x[0]:$x[3]";' /opt/LifeKeeper/subsys/scsi/resources/netraid/mirrorinfo_<md num>

回避策 : 直接回避する方法はありません。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 の非同期モードはサポートしていません。

LifeKeepe for Linux において DataKeeper リソースの非同期モード設定を使用すると、特定バージョンのカーネルでカーネルパニックが発生することが確認されています。本事象はカーネルに依存した問題であるため、LifeKeeper による根本的な解決方法はありません。DataKeeper の非同期モード設定をご利用いただくには、カーネルのアップデート、またはダウングレードが必要となります。

DataKeeper の非同期モードを利用できないカーネルバージョンは次の通りです。

　Red Hat Enterprise Linux / Oracle Linux / CentOS において、以下のバージョンのカーネルを使用している場合
　　3.10.0-693.24.1.el7.x86_64 以降の 3.10.0-693. 系カーネル
　　3.10.0-862.el7.x86_64 から 3.10.0-862.26.x.el7.x86_64 まで
　　3.10.0-957.el7.x86_64 から 3.10.0-957.3.x.el7.x86_64 まで

上記に該当する環境をご利用で、DataKeeper リソースを非同期モードでご利用の場合には以下のカーネル バージョンへのアップデート（またはダウングレード）を実施してください。

　Red Hat Enterprise Linux / Oracle Linux / CentOS において、以下のバージョンのカーネルを使用している場合
　　3.10.0-693.24.1.el7.x86_64 未満 の3.10.0-693. 系カーネル
　　3.10.0-862.29.1.el7.x86_64 以降
　　3.10.0-957.4.1.el7.x86_64 以降

カーネルのアップデート（またはダウングレード）が不可能である場合には、DataKeeper では非同期モードを利用しないようにしてください。

一部のカーネルバージョンでは Secure Boot 機能をサポートしていません

RHEL7 以降、CentOS7 以降、Oracle Linux7(非 UEK カーネルのみ) 以降で Secure Boot を有効にしていると、nbd モジュールのロードに失敗します。また、SUSE Linux Enterprise Server、Oracle Linux UEK kernel においても、一部のカーネルバージョンでは、Secure Boot を有効にしていると、md/raid1カーネルモジュールのロードに失敗します。

解決方法: 以下のいずれかの対応を行ってください。(1) を推奨します。また、いずれの方法も OS 再起動が必要です。
(1) Secure Boot を無効にする。
　　UEFI の設定で、Secure Boot を無効にしてください。
(2) 署名の検証を無効にする。
　　 “mokutil --disable-validation” コマンドを実行して、署名の検証を無効にしてください。詳細は mokutil のマニュアルを参照ください。