説明
カーネル 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 デーモンを手動で停止します (これにより、ミラーが切断されます)。ただし、このデッドロックを完全に防止する場合は、シンメトリックアクティブレプリケーションを推奨しません。
ミラーが切断され、 /var/log/messages にたくさんのエラーが記述されます

この問題は、(Red Hat EL 6.x や CentOS 6 で) 意図的に障害を発生させるストレステストを実行しているとき (特に、ミラーターゲットシステムで実行されている nbd_server プロセスを停止しているときに) にときおり見られます。ディストリビューションの最新カーネル (Red Hat EL 6.0 または 6.1 の場合は kernel-2.6.32-131.17.1 など) にアップグレードすると、この問題が発生するリスクの軽減に役立つ場合があります。ソースシステムを再起動すると、この問題はなくなります。 

CentOS 6 に付属のデフォルトカーネル (2.6.32-71) では、(ミラーの過負荷に過ぎない場合でも) この問題はさらに頻繁に発生する可能性があります。残念なことに、CentOS はこの状態を改善するカーネル (2.6.32-131.17.1) をまだリリースしていません。SIOS は、CentOS 6で入手可能になり次第、2.6.32-131.17.1 カーネルへのアップグレードを推奨しています。

注記: SPS 8.1 以降、Red Hat Enterprise Linux システムでカーネルのアップグレードを実行する際、インストールイメージから setup スクリプト(./setup ) を再実行する必要はなくなりました。カーネルが適切な Red Hat package (rpm ファイル) からインストールされている限り、モジュールはアップグレードしたカーネルで特別な操作を必要とせずに、自動的に使用可能になります。
大きなミラーサイズを備えた md_raid1 プロセスではトップで高い CPU 使用率がレポートされます

mdX_raid1 プロセス (X はミラー番号) では、非常に大きなミラー (500GB 以上) を操作している際に、一部の OS ディストリビューションで高い CPU 使用率がトップで報告されることがあります。

解決方法: CPU の使用率を減らすには、LifeKeeper 設定 LKDR_CHUNK_SIZE でチャンクサイズを 1024 に変更し、この新しい設定を使用するためにミラーを削除して再作成します。
DataKeeper リソースで lkbackup を使用する場合は、全同期が必要です

lkbackup では instancemirror_info ファイルを保存しますが、リソースが存在しないときにソースおよびターゲットの状態は保証されないため、lkbackup から restore した後で、DataKeeper ミラーの全同期を実行することがベストプラクティスです。
初期の Red Hat/CentOS 6.x のカーネルバージョンでは、LifeKeeper のログに「Failed to remove device」というメッセージを出してミラーの再同期がハングすることがあります

バージョン 2.6.32-131.17.1 より前のカーネルバージョン (更新前の RHEL 6.1 カーネルバージョン 2.6.32-131.0.15 など) では、レプリケーションに使用する md ドライバに問題があります。この問題によって、nbd デバイスがミラーから解放されなくなり、「Failed to remove device」メッセージが複数記録され、ミラーの再同期が中止されます。この状態を解消するには、システムの再起動が必要です。この問題は、ミラー作成後の最初の再同期中、およびミラーが高負荷のときに発生したことがあります。

解決方法: カーネル 2.6.32-131.17.1 にはこの問題の修正が含まれていることが確認されています。2.6.32-131.17.1 より前のカーネルバージョンの Red Hat または CentOS 6 で DataKeeper をお使いの場合は、このバージョンまたは最新のバージョンにアップデートすることを推奨します。
SLES11 SP4 および SLES12 SP1 以降でデータ圧縮機能を使用することはサポートしていません

パフォーマンスの問題があるため、SLES11 SP4 および SLES12 SP1 以降でデータ圧縮機能を使用することはサポートしていません。
DataKeeperミラーの非同期レプリケーションモードは、RHEL 7.4~7.6、CentOS 7.4~7.6、およびOracle Linux 7.4~7.6 OSディストリビューションの一部のカーネルではサポートされていません。

DataKeeperミラーの非同期レプリケーションモードは、システムパニックを引き起こすカーネルの問題があるため、次のカーネルではサポートされていません。

  • 以下のカーネルは サポートしていません
    • 3.10.0-693.51.1.el7 以前の 3.10.0-693.系カーネル
    • 3.10.0-862.29.1.el7 以前の 3.10.0-862.系カーネル
    • 3.10.0-957.10.1.el7 以前の 3.10.0-957.系カーネル
RHEL / CentOS / Oracle Linux では Secure Boot 機能をサポートしていません

RHEL7 以降、CentOS7 以降、Oracle Linux7 以降で Secure Boot を有効にしていると、nbd モジュールのロードに失敗します。そのため、DataKeeper を使用することができません。ただし、Oracle Linux で UEK を使用する場合は、Secure Boot を有効にすることができます。

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

nbd モジュールのパラメータ max_part のデフォルト値が、カーネル 4.13 で変更されました。このため、ミラーステータスは GUI および mirror_status コマンドで正しく表示されません。

解決方法: 以下の手順に従って、すべてのノードで nbd モジュールパラメーターを設定してください。
(1) ファイル /etc/modprobe.d/lifekeeper-nbd.conf で、「max_part=0」を「options nbd」を含む行に追加します。例:

options nbd nbds_max=128 max_part=0

(nbds_max はシステムによって異なる場合があるため、この設定は現在の値のままにしてください)

(2) 次のコマンドを実行して、nbd モジュールをリロードします。

modprobe -r nbd
modprobe nbd

スイッチオーバを行い、スイッチオーバ前のアクティブノードで手順1 と手順2 を実行します。

スイッチオーバして、元のアクティブ / スタンバイ状態に戻します。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信