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

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

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

症状 推奨される処置
プライマリーサーバー上でリソースがIn Serviceとなっていない場合、左端のリソースアイコンでミラー固有のアクション (再開、一時停止、強制ミラーオンライン) を選択すると失敗する。 サーバー固有のアイコンを選択して操作を実行します。
GUIに[Wait to Resync]が表示される。 再同期処理は親リソースがIn Serviceになるまで待機します。LifeKeeperのログは、再同期処理の開始を妨げているリソースと、どのリソースが起動される必要があるかを示したメッセージを含みます。リソースが 単純に OSU になっているのであればリソースをIn Serviceにするか ログメッセージに記載されている mirror_action コマンドを実行してください。リソースがOSFの場合は、リソースをIn Serviceにする前に問題を解決することで、データの再同期が行われます。詳細については 再同期前のデータ検証 を参照してください。
LKCLIのエクスポート/インポート機能を用いて、DataKeeperリソースのミラーリング方式がノード毎に異なるようなリソースを作成することはできません GUIを用いてDataKeeperリソースを作成した場合、プライマリーからセカンダリー間を非同期転送、セカンダリーからプライマリー間を同期転送する設定が出来ますが、その構成をLKCLIでエクスポートした場合に別のクラスター構成にインポートすることはできません。

注意: この構成は、lkcliのエクスポート/インポート機能では利用できません。lkcliのエクスポートはエラーを返しませんが、lkcliのインポートは失敗します。
netraid ミラーに一意の識別子がないという警告メッセージ

一意の識別子を使用するには、設定をできるだけ早く変更する必要があります。

修復するための推奨手順は次の通りです。
1. すべてのノードでLifeKeeperを起動します。

2. 安全でないnetraidリソースと、各ノードの各リソースの元になるディスクを特定します。各ノードでマッピングが異なる場合があるため、これは各ノードで実施してください。

# ins_list -r netraid -f: | grep DEVNAME | grep -v mapper | cut -f4,5 -d:
datarep-test1:/dev/xvdb
datarep-test2:/dev/xvdc
datarep-filesys3:/dev/xvdd


注意: これは netraid「tag:ID」のリストです。以下の手順では、上記のデバイス名マッピングの一致を想定しています。

3. デバイスがGPTで設定されているかどうかを確認します。各デバイスについて、GPT getIdを実行します。

#/opt/LifeKeeper/lkadm/subsys/scsi/gpt/bin/getId -i /dev/xvdb

4757cd62-e065-4013-8514-1031b446aa24


4. getIdが一意のIDを返した場合は、インスタンスを更新します。

#ins_setid -t datarep-test1 -i “4757cd62-e065-4013-8514-1031b446aa24”

<GPTではないデバイスがある場合は、ステップ5に進んでください。>


5. 安全でないnetraidリソースに依存するリソースを特定します。

# ins_list -r netraid -f: | grep DEVNAME | grep -v mapper | cut -f4 -d: | while read entry; do dep_list -p $entry -f: 2>/dev/null | cut -f1 -d:; done
/test1
/test2
filesys3


注意: これは、netraidデバイスに関連付けられたファイルシステムの タグのリスト です。

6. ファイルシステムのマウントポイントを特定します。通常、ファイルシステムリソースのタグはマウントポイントと同じです。同じでない場合は次のコマンドを使用して、ファイルシステムタグをファイルシステムのマウントポイントと一致させることができます。

# ins_list -t filesys3 -f: | cut -d: -f5
/test3


7. すべてのアクティビティーを停止して、ファイルシステムリソースのみをnetraidデバイスでIn Serviceにします。

a. すべてのリソースをOut of Serviceにします。
b. 安全でないnetraidデバイス上のファイルシステムのみをIn Serviceにします。


安全でないデバイスについてのみ、以下の手順に従ってください。

8. リソースがIn Serviceで影響を受けるファイルシステム上のすべてのデータのバックアップを取得します。

9. すべてのクラスターノードですべてのリソースをOut of Serviceにします。

10. LifeKeeper構成のバックアップを取得します(lkbackup -c --cluster)。

11. 安全でない各netraidリソースに対して階層を削除します。

a. 階層に注意してください。影響を受けるアプリケーションは削除されます。
b. 複雑な構成では、階層が複数のブランチで構成されている複数の階層を削除する必要がある場合があります。


12. この時点で残っているのは、安全でないnetraidリソースとの依存関係がないリソースのみです。ほとんどの場合、それはIPリソース、EC2リソースなどです。
13. すべてのノードで lkstop を実行します。
14. 影響を受けるすべてのファイルシステムがアンマウントされていることを確認します。
15. 各ノードのデバイスをGPTパーティションテーブル(gdiskやpartedなどを使用)で再構成するか、LVMを使用します。
16. すべてのノードでLifeKeeperを起動します。
17. ファイルシステムごとにレプリケートされた新しいファイルシステムを作成し、各リソースをすべてのノードに拡張します。

• /dev/xvdb1 -> /test1
• /dev/xvdc1 -> /test2
• /dev/xvdd1 -> /test3


18. バックアップから各マウントポイントにデータをリストアします。データは自動的にターゲットに再同期されます。
19. ステップ11で削除したアプリケーション階層を再作成します。

DataKeeper ストレージ構成オプションの詳細については、SIOS製品ドキュメント を参照してください。

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

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

フェイルオーバー中のエラー デバイスのステータスを確認してください。再同期が進行中の場合、フェイルオーバーは実行できません。
プライマリーサーバーに障害が発生すると、セカンダリーサーバーの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が全体の再同期を実行します。

ビットマップを使用する場合 :

最終のバックアップであったサーバーを特定し、そのサーバーのリソースをサービス休止にする必要があります。その後、DataKeeperが部分的な再同期を実行します。
Core – 言語環境の影響 LifeKeeperの一部のスクリプトは Linux のシステムユーティリティーの出力を解析し、情報を抽出するために特定のパターンに依存します。英語圏以外のロケールで一部のコマンドが実行されている場合、予測されたパターンは変更され、LifeKeeperスクリプトは必要な情報の取得に失敗します。このため、 /etc/default/LifeKeeper では、言語環境変数 LC_MESSAGES が POSIX「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リソースの作成 (および拡張) に失敗する 特定の環境(IDEディスクエミュレーションを使用した仮想化環境、HP CCISSストレージを使用したサーバー、ソリッドステートデバイス(SSD)、Amazon EBSストレージなど)でDataKeeperを使用している場合、ミラー作成時にエラーが発生することがあります。



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

回避策: GUIDパーティションを作成し、一意のIDをパーティションに割り当てるか、LVMを使用してください。
アップグレード後、ターゲットの状態が「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つのシステム間のレプリケーションは、当初非同期レプリケーション用に構成されていたが、代わりに同期レプリケーションを要求される場合。 ミラーの拡張を解除して再度拡張し、Replication Typeを要求されたら「synchronous」を選択してください。
ターゲットが前のソースを待機中で、同期していない。 前のソースをクラスターに接続します。前のソースがタイムリーにクラスターに再参加できない場合は、現在のミラーソースで $LKROOT/bin/mirror_action <tag> fullresync <source> <target> コマンドを実行し、ターゲットを完全再同期で再接続してください。

フィードバック

お役に立ちましたか?

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

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

送信