このセクションでは、DataKeeper for Linux の使用時に遭遇する可能性がある問題に関する情報を示します。必要に応じて、エラーの原因およびエラー状態を解消するために必要な処置についても説明しています。
DataKeeper for Linux に固有のメッセージについては、DataKeeper メッセージカタログ を参照してください。他の SPS コンポーネントからメッセージが送出されることもあります。その場合は、総合メッセージカタログ を参照してください。これらのメッセージカタログには、SIOS Protection Suite for Linux の使用中に遭遇される可能性のあるすべてのエラーコード (操作、管理、および GUI に関するものを含む) の一覧があります。また、エラーコードの原因に関する追加の説明や、問題解決のために必要な処置についても、必要に応じて記載されています。この一覧から、受信したエラーコードを検索できます。また、該当する SPS コンポーネントの個別のメッセージカタログに直接アクセスすることもできます。
以下の表に、予測される問題と推奨される処置を示します。
| netraid ミラーに一意の識別子がないという警告メッセージ | 一意の識別子を使用するには、設定をできるだけ早く変更する必要があります。 修復するための推奨手順は次の通りです。 2. 安全でない netraid リソースと、各ノードの各リソースの元になるディスクを特定します。各ノードでマッピングが異なる場合があるため、これは各ノードで実施してください。 datarep-test1:/dev/xvdb datarep-test2:/dev/xvdc datarep-filesys3:/dev/xvdd 注記: これは netraid「tag:ID」のリストです。以下の手順では、上記のデバイス名マッピングの一致を想定しています。 3. デバイスが GPT で設定されているかどうかを確認します。各デバイスについて、GPT getId を実行します。
4. getId が一意の ID を返した場合は、インスタンスを更新します。
5. 安全でない netraid リソースに依存するリソースを特定します。 /test1 /test2 filesys3 注記: これは、netraid デバイスに関連付けられたファイルシステムの タグのリスト です。 6. ファイルシステムのマウントポイントを特定します。通常、ファイルシステムリソースのタグはマウントポイントと同じです。同じでない場合は次のコマンドを使用して、ファイルシステムタグをファイルシステムのマウントポイントと一致させることができます。 /test3 7. すべてのアクティビティを停止して、ファイルシステムリソースのみを netraid デバイスで In Service にします。
安全でないデバイスについてのみ、以下の手順に従ってください。 8. リソースが In Service で影響を受けるファイルシステム上のすべてのデータのバックアップを取得します。 9. すべてのクラスターノードですべてのリソースを Out of Service にします。 10. LifeKeeper 構成のバックアップを取得します（lkbackup -c --cluster）。 11. 安全でない各 netraid リソースに対して階層を削除します。
12. この時点で残っているのは、安全でない netraid リソースとの依存関係がないリソースのみです。ほとんどの場合、それは IP リソース、EC2 リソースなどです。
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 はデータを再同期しません。手動操作が必要です。
|
| 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> コマンドを実行し、ターゲットを完全再同期で再接続してください。 |
このトピックへフィードバック