このセクションでは、DataKeeper for Linux の使用時に遭遇する可能性がある問題に関する情報を示します。必要に応じて、エラーの原因およびエラー状態を解消するために必要な処置についても説明しています。

DataKeeper for Linux に固有のメッセージについては、DataKeeper メッセージカタログ を参照してください。他の SPS コンポーネントからメッセージが送出されることもあります。その場合は、総合メッセージカタログ を参照してください。から見つけることができます。これらのメッセージカタログには、SIOS Protection Suite for Linux の使用中に遭遇される可能性のあるすべてのエラーコード (操作、管理、および GUI に関するものを含む) の一覧があります。また、エラーコードの原因に関する追加の説明や、問題解決のために必要な処置についても、必要に応じて記載されています。この一覧から、受信したエラーコードを検索できます。また、該当する SPS コンポーネントの個別のメッセージカタログに直接アクセスすることもできます。

以下の表に、予測される問題と推奨される処置を示します。

症状
推奨される処置
DataKeeper リソースを削除した後に NetRAID デバイスが削除されない。 NetRAID デバイスがマウントされている場合、DataKeeper リソースを削除しても NetRAID デバイスは削除されません。以下のコマンドを使用して、手動でデバイスをアンマウントして削除することができます。

mdadm –S <md_device> (<md_device> を調べるには cat /proc/mdstat)

インストール/HADR rpm の失敗 これらのファイルを手動でインストールするための詳細手順については、インストール セクションを参照してください。
フェイルオーバ中のエラー デバイスのステータスを確認してください。再同期が進行中の場合、フェイルオーバは実行できません。
プライマリサーバに障害が発生すると、セカンダリサーバの DataKeeper リソースが ISP になります。ただし、プライマリサーバが再起動すると、両方のサーバで DataKeeper リソースが OSF になります。 DataKeeper リソース階層の作成時に選択した「スイッチバックタイプ」を確認してください。このリリースでは、DataKeeper リソースの自動スイッチバックはサポートされていません。リソースプロパティのウィンドウで、スイッチバックタイプを [Intelligent] に変更できます。
両方のサーバが動作不能になってからプライマリサーバが再起動したときに、リソースを ISP にすることができない。 セカンダリサーバよりも前にプライマリサーバが動作可能になった場合、DataKeeper リソースを強制的にオンラインにすることができます。このためには、リソースプロパティのダイアログを開き、 [Replication Status] タブ、 [Actions] ボタンを順にクリックし、次に [Force Mirror Online] を選択してください。 [Continue] をクリックして確認してから、 [Finish] をクリックしてください。
現在マウントしている NFS ファイルシステムに DataKeeper 階層を作成するときのエラー 現在 NFS がエクスポートしたファイルシステムに、DataKeeper 階層を作成しようとしています。エクスポートする前に、このファイルシステムを複製する必要があります。
DataKeeper の GUI のウイザードに、新しく作成したパーティションがリストされない。 Linux OS は、システムを次回再起動するまで、新しく作成したパーティションを認識しないことがあります。新しく作成したパーティションのエントリを調べるには、/proc/partitions ファイルを表示してください。新しく作成したパーティションがこのファイルに表示されない場合、システムを再起動する必要があります。
プライマリとバックアップの両方のサーバで、リソースが緑(ISP)で表示される。

これは、「スプリットブレイン」のシナリオで、一時的な通信障害により発生することがあります。通信の再開後、両方のシステムがそれぞれ、それ自体をプライマリと見なします。

いずれのシステムが最終のプライマリシステムであったかが不明なので、DataKeeper はデータを再同期しません。手動操作が必要です。

ビットマップを 使用しない場合 :

最終のバックアップであったサーバを特定し、そのサーバのリソースをサービス休止にする必要があります。その後、DataKeeper が全体の再同期を実行します。

ビットマップを使用している場合(2.6.18 以前のカーネル):

元のバックアップノードから始めて、両方のリソースをサービス休止にする必要があります。次に、以下のコマンドを実行して、プライマリノードのビットマップをダーティに設定する必要があります。 $LKROOT/lkadm/subsys/scsi/netraid/bin/bitmap -d /opt/LifeKeeper/bitmap_filesys

/opt/LifeKeeper/bitmap_filesys ハビットマップファイルの名前)。これにより、リソースがサービス中になると、全体の再同期が強制実行されます。次に、プライマリノードでリソースを in service にします。全体の再同期が開始されます。

ビットマップを使用する場合 (2.6.19 以降のカーネル、Red Hat Enterprise Linux 5.4 の 2.6.18-164 以降のカーネル、または Red Hat 5.4 以降のサポートする派生カーネル):

最終のバックアップであったサーバを特定し、そのサーバのリソースをサービス休止にする必要があります。その後、DataKeeper が部分的な再同期を実行します。

Core - 言語環境の影響 LifeKeeper の一部のスクリプトは Linux のシステムユーティリティの出力を解析し、情報を抽出するために特定のパターンに依存します。英語圏以外のロケールで一部のコマンドが実行されている場合、予測されたパターンは変更され、LifeKeeper スクリプトは必要な情報の取得に失敗します。このため、 /etc/default/LifeKeeper では、言語環境変数 LC_MESSAGESPOSIX「C」のロケール (LC_MESSAGES=C) に設定されています。言語を英語にして Linux をインストールする必要はありません (インストールメディアで使用できる任意の言語を選択可能)。 /etc/default/LifeKeeper の LC_MESSAGES の設定は LifeKeeper にのみ影響します。 /etc/default/LifeKeeper の LC_MESSAGES の値を変更する場合は、LifeKeeper の動作に悪影響を及ぼす可能性があることに注意してください。悪影響は、メッセージカタログがさまざまな言語とユーティリティに対応してインストールされているかどうか、および LifeKeeper が予期していないテキスト出力をそれらが生成するかどうかに左右されます。 
GUI - GUI の終了後に Web ブラウザから再接続したときに、GUI のログインプロンプトが再表示されないことがある。

GUI アプレットを終了するか切断してから、同じ Web ブラウザのセッションから再接続しようとすると、ログインプロンプトが表示されないことがあります。

回避策: Web ブラウザを閉じ、Web ブラウザを開き直してからサーバに接続します。Firefox ブラウザを使用している場合は、Firefox のウィンドウをすべて閉じてから、開き直します。

DataKeeper の Create Resource が失敗します

特定の環境 (例: IDE ディスクエミュレーションを使用した仮想環境、HP CCISS ストレージを使用したサーバ、またはSSD) で DataKeeper を使用する場合、ミラーを作成すると以下のエラーが発生することがあります。


    ERROR 104052: Cannot get the hardware ID of the device “dev/hda3”

これは、LifeKeeper が問題のディスクを認識せず、一意の ID を取得してそのデバイスに関連付けることができないためです。

回避策:GUIDパーティションを作成してパーティションに固有のIDを割り当ててください。GUIDパーティションが作成できない場合は、DEVNAME device_pattern ファイルに、ディスクのパターンを追加します。次に例を示します。


    cat /opt/LifeKeeper/subsys/scsi/resources/DEVNAME/device_pattern


    /dev/hda*


    /dev/fio*(Fusion IO SDD)


    /dev/hio*(PCI SSD)
マルチサイトクラスター構成で、一時停止、再開を行った場合、全同期が発生することがある。 ビットマップファイルの場所が間違っている可能性があります。ビットマップファイルは、マルチサイトクラスタでローカルノード間の共有ファイルシステム上にある必要があります。この共有ファイルシステムは、レプリケーションに使用される共有ファイルシステムと別でなければなりません。 一度DataKeeperリソースを削除して、正しいビットマップファイルの場所を使用してリソースを再作成してください。
アップグレード後、ターゲットの状態が「Out of Sync」になる

LifeKeeper 9.2.2 以降では NU デバイスの使用を推奨していないため、NU デバイスで構成された DataKeeper リソースが存在する環境では、このような症状が発生します。

NU デバイスを使用した環境で LifeKeeper 9.2.2 以降にアップグレードする場合には、 /etc/default/LifeKeeper に以下の設定を追加してください。

LKDR_ALLOW_NU=TRUE

NUデバイスの確認方法:

lcdstatus コマンドを実行し、ID に NU- で始まる文字列が含まれる場合は NU デバイスを使用した環境です。

ターゲットに拡張しても、非同期または同期を設定するための「Replication Type」の入力画面が表示されない。 ミラーが作成されると、[Enable Asynchronous Replication(非同期レプリケーションを有効にする)] で [No] が選択されます。ミラーを削除し、[Enable Asynchronous Replication(非同期レプリケーションを有効にする)] プロンプトが表示されたら [Yes] を選択してください。
レプリケーションタイプが同期ではなく非同期になっている。2つのシステム間のレプリケーションは、当初非同期レプリケーション用に構成されていたが、代わりに同期レプリケーションを要求される。 ミラーの拡張を解除して再度拡張し、接続を要求されたら「同期」を選択してください。
ターゲットが前のソースを待機中で、同期していない。 前のソースをクラスターに接続します。前のソースがタイムリーにクラスターに再参加できない場合は、現在のミラーソースで $LKROOT/bin/mirror_action <tag> fullresync <source> <target> コマンドを実行し、ターゲットを完全再同期で再接続してください。

フィードバック

お役に立ちましたか?

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

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

送信