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

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

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

症状
推奨される処置
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. ステップ9で削除したアプリケーション階層を再作成します。

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_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 リソースの作成 (および拡張) に失敗する

特定の環境(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> コマンドを実行し、ターゲットを完全再同期で再接続してください。

フィードバック

お役に立ちましたか?

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

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

送信