ページの先頭行へ戻る
PRIMECLUSTER Global Disk Services  説明書 4.5
FUJITSU Software
付録D トラブルシューティング > D.1 トラブルへの対処方法 > D.1.6 サーバ間ミラーリングに関する異常
前次

D.1.6 サーバ間ミラーリングに関する異常

以下に該当する場合は、それぞれに記載されている対処を行ってください。

(1) ネットミラーボリュームを構成するネットミラースライスが INVALID 状態である。

説明

ネットミラーボリュームのスライスが INVALID 状態になる原因は、以下のいずれかです。

対処

  1. ノードが停止している場合は、起動します。

    ノード起動後、自動的に等価性コピーが実行され、等価性コピーが正常終了するとスライスが ACTIVE 状態に復旧されます。この場合、これで対処は完了です。
    復旧されていない場合、以降の手順を実施します。

  2. サーバ間ミラーリングで使用しているネットワークの状態を確認します。

    ネットワークに異常がある場合は、復旧します。
    ネットワークの復旧後、約 30 秒以内に自動的に等価性コピー処理が開始されます。すべての等価性コピー処理が完了するまで、すなわち COPY 状態のネットミラースライスが存在しない状態になるまで、待ってください。等価性コピーが正常終了するとスライスが ACTIVE 状態に復旧されます。この場合、これで対処は完了です。
    復旧されていない場合、以降の手順を実施します。

  3. クラスの状態を確認し、クラスが起動していない場合は復旧します。

    両ノードで以下のコマンドを実行し、クラスの状態を確認します。

    # /etc/opt/FJSVsdx/bin/sdxdcdown

    クラスの情報が表示されない場合、クラスは起動されていません。
    この場合、「D.1.4 クラス状態に関する異常」の「(2) システムの起動時にクラスが起動できない。」 の注意 「ノードのシャットダウン」 を参照して当該ノードを停止し、再起動してください。
    再起動後も情報が表示されない場合、「D.1.4 クラス状態に関する異常」の「(2) システムの起動時にクラスが起動できない。」 を参照して復旧してください。

  4. ディスクの状態を確認します。

  5. ディスクが故障していて、かつ、クラスが閉塞している場合、クラス閉塞を復旧します。

    5-1) 両ノードでクラスが閉塞していないか確認します。

    両ノードで以下のコマンドを実行します。DOWN フィールドに yes が表示されているクラスは閉塞しています。

    # /etc/opt/FJSVsdx/bin/sdxdcdown

    5-2)クラスが閉塞しているノードを再起動します。

    5-3) 閉塞していたクラスが登録されているクラスタアプリケーションが、このノード以外のノードで起動されている場合、このノードでネットミラーボリュームの起動ロックを解除します。

    # sdxattr -V -c クラス名 -v ボリューム名 -a lock=off

  6. ディスクが故障している場合、ディスクを交換します。

    ディスク交換手順については、「7.3.3 ネットミラーグループのディスク交換」を参照してください。

    ただし、以下のトラブルシューティングに記載された条件に該当する場合は、トラブルシューティングの「対処」に従って復旧を行います。

    上記のトラブルシューティングの「対処」に従って「物理ディスク復旧」 (sdxswap -I コマンド) を実行するとき、事前に「7.3.3 ネットミラーグループのディスク交換」に記載されている設定を行ってください。

  7. ディスクに異常がない場合、両ノードで sdxinfo -D コマンドを実行し、DEVNAM フィールドに物理ディスク名が正しく表示されているか確認します。

    一方のノードで DEVNAM フィールドにアスタリスク (*) が表示されている場合、「D.1.6 サーバ間ミラーリングに関する異常」の「(4) ネットワーク異常時にノードを再起動すると、再起動していないノードのスライスがINVALID状態になるか、または、業務が停止する。」に従って復旧します。

    両ノードで DEVNAM フィールドにアスタリスク (*) が表示されている場合、「D.1.6 サーバ間ミラーリングに関する異常」の「(6) 両ノード起動時に後に起動された方のノードでクラスが閉塞する。」に従って復旧します。

  8. 手順 1. ～ 7. を実施しても復旧しない場合、以下の異常が発生していないか確認し、対処を行ってください。

    • 間欠故障などにより、ネットワークまたはノードの異常と復旧が繰り返し発生している場合や、I/Oエラーとネットワークの復旧が連続して発生した場合
      システムログなどでネットワークとノードの状態を確認してください。異常が発生している場合は復旧し、ネットミラーボリュームの等価性コピーを実行するため、任意のノードで以下のコマンドを実行してください。

      # sdxcopy -B -c クラス名 -v ボリューム名

    • 両ノードのディスク間のデータの新旧が判断できない状態の場合
      この状態になる条件と復旧方法については、 「7.16.7 最新ディスクが自動選択できない場合の復旧方法」 を参照してください。

  9. 手順 1. ～ 8. を実施しても復旧しない場合、調査資料を採取して当社の技術員に連絡してください。

(2) ノード再起動後、クラスタアプリケーションがFaultedまたはInconsistent状態になる。

説明

この現象は、ネットミラーボリュームに属している2つのスライスのうち、一方が ACTIVE または STOP 状態で、他方がそれ以外の状態の場合に、前者のスライスが存在するノードを再起動した場合に発生します。このとき、ネットミラーボリューム内に正当なデータを持つスライスが存在しない状態になります。このため、再起動していないノードのクラスリソースが OFF-FAIL 状態になり、クラスタアプリケーションが Faulted 状態または Inconsistent 状態になります。

再起動していないノードが以下の条件を満たすとき、クラスタアプリケーションが Inconsistent 状態になります。

上の条件に当てはまらない場合、クラスタアプリケーションが Faulted 状態になります。

対処

  1. ノードが停止している場合は、停止しているノードを起動します。

  2. 再起動していない方のノードでクラスが閉塞していないか確認します。

    再起動していない方のノードで以下のコマンドを実行します。DOWN フィールドに yes が表示されているクラスは閉塞しています。

    # /etc/opt/FJSVsdx/bin/sdxdcdown

  3. 手順 2 でクラスが閉塞していた場合、復旧します。

    クラスが閉塞していない場合、本手順は不要です。

    3-1) ディスクが故障している場合は、ディスク交換などにより復旧します。

    3-2) 両ノードが起動していることを確認し、再起動していない方のノードでクラス閉塞を復旧します。
    以下のコマンドを実行します。

    # sdxfix -C -c クラス名

    3-3) ネットミラーボリュームの起動ロックを解除します。
    両ノードで以下のコマンドを実行し、起動ロック属性を確認します。

    # sdxinfo -V -c クラス名 -e long

    起動ロック属性は、LOCK フィールドに表示されます。
    起動ロック属性が on の場合、そのノードで以下のコマンドを実行し、起動ロックを解除します。

    # sdxattr -V -c クラス名 -v ボリューム名 -a lock=off

    3-4) ネットミラーボリュームに INVALID 状態のスライスが存在する場合、等価性コピーを実行します。
    任意のノードで以下のコマンドを実行します。

    # sdxcopy -B -c クラス名 -v ボリューム名

    注意

    クラスタシステムの各ノードの時刻が一致していない場合、等価性コピーが実行されないことがあります。その場合、各ノードの時刻を合わせてから、両ノードを再起動することで、復旧できます。

  4. クラスタアプリケーションが Faulted 状態または Inconsistent 状態の場合、Faulted 状態または Inconsistent 状態をクリアします。

    Faulted 状態または Inconsistent 状態のクリア方法については、「PRIMECLUSTER 導入運用手引書」を参照してください。

  5. クラスリソースの状態を確認し、OFF-FAIL の場合は復旧します。

    • 起動されているクラスタアプリケーションが存在しない場合

      再起動していない方のノードでクラスタアプリケーションを起動します。

      再起動した方のノードでクラスタアプリケーションを起動したい場合は、再起動していない方のノードを再起動してください。

    • 起動されているクラスタアプリケーションが 1 つのみの場合

      待機ノードを再起動します。

    • 2 つ以上のクラスタアプリケーションが起動されている場合

      1) 一方のノードに運用ノードと待機ノードが混在している場合、再起動していないノードのみが運用ノードになるようにクラスタアプリケーションの切替えを行います。

      2) 必要に応じて、手順 1) で切り替えたクラスタアプリケーションの切戻しを行います。

(3) ネットワーク異常時にクラスタアプリケーションがFaultedまたはInconsistent状態になる。

説明

対処

  1. ネットワークを復旧します。

    ネットワークが復旧した後、自動的に等価性回復コピーが実行されます。

    クラス閉塞が発生している場合、コピー処理は失敗することがあります。

  2. 閉塞しているクラスを確認します。

    両ノードで以下のコマンドを実行します。DOWN フィールドに yes が表示されているクラスは閉塞しています。

    # /etc/opt/FJSVsdx/bin/sdxdcdown

  3. 手順 2 でクラスが閉塞していた場合、復旧します。

    クラスが閉塞していない場合、本手順は不要です。

    3-1) ディスクが故障している場合は、ディスク交換などにより復旧します。

    3-2) 等価性回復コピーが実行されている場合は、等価性回復コピーを中止します。

    クラス閉塞が発生していないノードで以下のコマンドを実行し、ネットミラーボリュームのスライスの状態を確認します。

    両ノードでクラスが閉塞している場合、本手順は不要です。

    # sdxinfo -S -c 閉塞しているクラス名

    ネットミラーボリューム内に COPY 状態のスライスが存在する場合は、等価性回復コピー中であるため、クラス閉塞が発生していないノードで以下のコマンドを実行してコピーを中止します。

    # sdxcopy -C -c 閉塞しているクラス名 -v ボリューム名

    3-3) クラス閉塞を復旧します。

    クラスが閉塞しているノードで以下のコマンドを実行します。

    # sdxfix -C -c 閉塞しているクラス名

    クラス閉塞の復旧処理において、等価性コピーが実行されます。ネットミラーボリュームの両スライスがすでに等価になっている場合であっても、ボリューム全体の等価性コピーが実行されます。

    3-4) 手順 3-3) で等価性コピーが実行されなかった場合、等価性コピーを実行します。

    任意のノードで以下のコマンドを実行します。

    # sdxcopy -B -c 閉塞していたクラス名 -v ボリューム名

    注意

    クラスタシステムの各ノードの時刻が一致していない場合、手順 3-3)、3-4) で等価性コピーが実行されないことがあります。その場合、各ノードの時刻を合わせてから、両ノードを再起動することで、復旧できます。

  4. 待機ノードのクラスタアプリケーションの状態を復旧します。

    Faulted 状態のクリア方法については、「PRIMECLUSTER 導入運用手引書」を参照してください。

    Inconsistent 状態の場合も、Faulted 状態の場合と同様の方法で復旧します。

  5. クラスリソースの状態を確認し、OFF-FAIL の場合は復旧します。

    • クラスタアプリケーションが 1 つのみの場合

      待機ノードを再起動します。

    • 複数のクラスタアプリケーションが存在する場合

      1) 一方のノードに運用ノードと待機ノードが混在している場合、クラスタアプリケーションの切替えを行って運用ノードと待機ノードが混在しない状態にします。

      2) 等価性コピー処理が実行されていて、かつ、待機ノードにコピー元のディスクが存在する場合、等価性コピー処理が完了するまで待ちます。

      3) 待機ノードを再起動します。

(4) ネットワーク異常時にノードを再起動すると、再起動していないノードのスライスがINVALID状態になるか、または、業務が停止する。

説明

ネットワーク異常時にノードを再起動すると、以下のいずれかの現象が発生します。

対処

  1. サーバ間ミラーリングで使用するネットワークに異常がある場合は復旧します。

  2. デバイスの状態を確認します。

    両ノードでsdxinfo -Dコマンドを実行します。

    ネットミラーグループに接続されているディスクについて、sdxinfo -Dコマンドの出力から以下の情報を確認して記録します。記録した情報は、手順7および手順8で使用します。

    • DEVNAMフィールド(物理ディスク名)にアスタリスク(*)が出力されているディスクのNAMEフィールド(SDXディスク名)の値(以下の実行例ではd2)

    • DEVNAMフィールド(物理ディスク名)にアスタリスク(*)が出力されたノード

    実行例

    # sdxinfo -D
OBJ    NAME    TYPE   CLASS   GROUP   DEVNAM  DEVBLKS  DEVCONNECT       STATUS
------ ------- ------ ------- ------- ------- -------- ---------------- -------
disk   d1      netmirror cl1  mdg1    sda      1015808 node1:node2      ENABLE
disk   d2      netmirror cl1  mdg1    *        1015808 *                ENABLE

  3. iSCSIデバイス情報を修復します。

    手順2.でネットミラーグループに接続されているディスクのDEVNAMフィールドにアスタリスク(*)が出力されたノードで、以下のコマンドを実行します。

    # /etc/opt/FJSVsdx/bin/sdxiscsi_ctl -F -e init

  4. 両ノードでクラス閉塞の有無を確認し、閉塞している場合は復旧します。

    詳細は、「D.1.4 クラス状態に関する異常」を参照してください。

  5. ネットミラーボリュームの起動ロックを解除します。

    両ノードで以下のコマンドを実行し、起動ロック属性を確認します。

    # sdxinfo -V -c クラス名 -e long

    起動ロック属性は、LOCKフィールドに表示されます。

    起動ロック属性がonの場合、そのノードで以下のコマンドを実行し、起動ロックを解除します。

    # sdxattr -V -c クラス名 -v ボリューム名 -a lock=off

  6. 両ノードでiSCSIデバイス情報を削除します。

    # rm /var/opt/FJSVsdx/log/.sdxnetmirror_disable.db
# rm /var/opt/FJSVsdx/log/.sdxnetmirror_timestamp

  7. スライスの状態を確認します。

    任意のノードで以下のコマンドを実行し、DISKフィールド(SDXディスク名)の値が手順2で記録した値と同じスライスのSTATUSフィールドの値を確認します。以下の実行例では、スライスの状態はINVALIDです。

    実行例

    # sdxinfo -S
OBJ    CLASS   GROUP   DISK    VOLUME  STATUS
------ ------- ------- ------- ------- --------
slice  cl1     mdg1    d1      m1      STOP
slice  cl1     mdg1    d2      m1      INVALID

  8. 手順7で確認したスライスに ACTIVE または STOP 状態のものが存在する場合、以下の手順を実行します。

    8-1) 手順7 で確認したスライスに INVALID 状態のものが存在し、そのスライスが手順2 で記録した以外のノードのディスクに属している場合、RMS を停止します。
    任意の 1 ノードで以下のコマンドを実行します。

    # hvshut -a

    8-2) 手順2 で記録したノードを再起動します。

    8-3) 手順8-1) でRMSを停止した場合は、RMS を起動します。任意の 1 ノードで以下のコマンドを実行します。

    # hvcm -a

  9. ネットミラーボリューム内に INVALID 状態のスライスが存在する場合は、復旧します。

    任意のノードで以下のコマンドを実行します。

    -dオプションでは、INVALID 状態のスライスが存在するディスクを指定します。どのノードでもボリュームが起動していない場合、ボリュームが起動する際に等価性コピーが実行されます。

    # sdxswap -O -c クラス名 -d ディスク名
# sdxswap -I -c クラス名 -d ディスク名

  10. クラスタアプリケーションの状態を復旧します。

    Faulted 状態のクリア方法については、「PRIMECLUSTER 導入運用手引書」を参照してください。

    Inconsistent 状態の場合も、Faulted 状態の場合と同様の方法で復旧します。

  11. クラスリソースの状態を確認し、OFF-FAIL の場合は復旧します。

    • 起動されているクラスタアプリケーションが存在しない場合

      再起動していない方のノードでクラスタアプリケーションを起動します。

      再起動した方のノードでクラスタアプリケーションを起動したい場合は、再起動していない方のノードを再起動してください。

    • 起動されているクラスタアプリケーションが 1 つのみの場合

      待機ノードを再起動します。

    • 2 つ以上のクラスタアプリケーションが起動されている場合

      1) 一方のノードに運用ノードと待機ノードが混在している場合、再起動していないノードのみが運用ノードになるようにクラスタアプリケーションの切替えを行います。

      2) 必要に応じて、手順 1) で切替えたクラスタアプリケーションの切戻しを行います。

  12. 業務が停止している場合、必要に応じて、業務を再開します。

(5) ネットミラーボリュームが存在するクラスのリソースが OFF-FAIL 状態になる。

説明

何らかの異常によってノードからネットミラーボリュームにアクセスできない状態になると、そのノードのクラスリソースが OFF-FAIL 状態になります。

対処

  1. 以下の条件に該当する場合は OFF-FAIL 状態のクラスリソースが存在するノードを再起動します。

    • 直前に両ノードを再起動した。かつ

    • 1 つ以上のネットミラーグループ内のすべてのディスクが以下のいずれかの状態である。

      • OFF-FAIL 状態のクラスリソースが存在するノードのディスクが SWAP 状態または DISABLE 状態である。

      • OFF-FAIL 状態のクラスリソースが存在するノードにおいて、sdxinfo -D コマンドの出力の DEVNAM フィールドにアスタリスク (*) が表示される。

  2. 以下のトラブルシューティングに従って、異常箇所を復旧します。

    「D.1.6 サーバ間ミラーリングに関する異常」の (1) ～ (4)

    「D.1.4 クラス状態に関する異常」

    「D.1.2 ディスク状態に関する異常」

    クラスリソースが正常な状態 (ON またはOFF-STOP) に復旧されたら、復旧は完了です。

    OFF-FAIL 状態のクラスリソースが存在する場合は、手順 3. 以降を実施してください。

  3. 両ノードに OFF-FAIL 状態のクラスリソースが存在する場合、以下の手順で復旧します。

    3-1) 再起動するノードを選択します。

    3-2) 再起動しない方のノードで、以下の条件を満たすクラスタアプリケーションを起動します。

    条件：再起動しない方のノードのクラスリソースが OFF-FAIL 状態である。

    3-3) ネットミラーボリューム内に ACTIVE 状態または STOP 状態のスライスが 1 つだけ存在し、そのスライスが手順 3-1) で選択したノードのディスク上のスライスである場合、そのネットミラーボリューム内の INVALID 状態または NOUSE 状態のスライスを復旧します。

    3-4) 手順 3-1) で選択したノードを再起動します。

  4. 一方のノードだけ OFF-FAIL 状態のクラスリソースが存在する場合、以下の手順で復旧します。

    手順 4a) ～ 4c) のいずれかの条件に従って復旧します。

    4a) すべてのクラスタアプリケーションが停止している場合

    以下のいずれかの手順で復旧します。

    • クラスリソースが OFF-FAIL 状態となっているクラスタアプリケーションを、そのノードで起動します。

    • クラスリソースが OFF-FAIL 状態となっているノードを再起動します。

    4b) OFF-FAIL 状態のクラスリソースが存在するノードが運用ノードである場合

    クラスリソースが OFF-FAIL 状態となっているクラスタアプリケーションを、そのノードで起動します。

    4c) OFF-FAIL 状態のクラスリソースが存在するノードが運用ノードではない場合

    以下の手順で復旧します。

    4c-1) ネットミラーボリューム内に ACTIVE 状態または STOP 状態のスライスが 1 つだけ存在し、そのスライスが、 OFF-FAIL 状態のクラスリソースが存在するノードのディスク上のスライスである場合、そのネットミラーボリューム内の INVALID 状態または NOUSE 状態のスライスを復旧します。

    4c-2) OFF-FAIL 状態のクラスリソースが存在するノードを再起動します。

(6) 両ノード起動時に後に起動された方のノードでクラスが閉塞する。

説明

サーバ間ミラーリングで使用するネットワークに異常が発生している状態で両ノードを起動すると、後に起動された方のノードでクラスが閉塞することがあります。

このとき、先に起動されたノードでも、クラスリソースが OFF-FAIL 状態になることがあります。この場合、クラスタアプリケーションが起動されません。

対処

クラスタアプリケーションが起動されているかどうかと、ネットワークがすぐ復旧できるかどうかで、対処方法が異なります。

(a) クラスタアプリケーションが起動されている場合

  1. クラスが閉塞しているノードを停止します。

  2. サーバ間ミラーリングで使用するネットワークを復旧した後、「7.16.6 1ノードのみで運用した後、2ノード運用に復旧する方法」の「復旧手順」を実行します。

(b) クラスタアプリケーションが停止していて、ネットワークがすぐ復旧できる場合

  1. サーバ間ミラーリングで使用するネットワークを復旧します。

  2. 両ノードを再起動します。

(c) クラスタアプリケーションが停止していて、ネットワークがすぐ復旧できない場合

  1. 以下のどちらの方法で復旧するか選択します。

    • ネットワークを復旧してから業務を再開する。
      ネットワークを復旧した後、両ノードを再起動することで、復旧できます。
      データのリストアは行わず、クラスが閉塞しているノードのディスクに格納されている最新データを使用して業務が再開されます。

    • バックアップからデータをリストアして業務を再開する。
      この場合、手順 2. 以降を実行します。

  2. クラスが閉塞しているノードを停止します。

  3. スライスの INVALID 状態を復旧します。
    以下のコマンドを実行します。-d オプションでは、ネットミラーグループに属しているディスクのうち、そのノードに接続されているディスクのディスク名を指定します。

    # sdxfix -V -c クラス名 -v ネットミラーボリューム名 -d ディスク名 -e force -x NoRdchk

  4. ネットミラーボリュームを起動します。

    # sdxvolume -N -c クラス名 -v ネットミラーボリューム名 -e unlock

  5. ネットミラーボリュームのデータをリストアします。

  6. ネットミラーボリュームを停止します。

    # sdxvolume -F -c クラス名 -v ネットミラーボリューム名

  7. クラスタアプリケーションが Faulted 状態になっている場合は、 Faulted 状態をクリアします。
    Faulted 状態のクリア方法については、「PRIMECLUSTER 導入運用手引書」を参照してください。

  8. クラスタアプリケーションを強制起動します。
    クラスタアプリケーションの強制起動の方法については、「PRIMECLUSTER 導入運用手引書」を参照してください。

  9. サーバ間ミラーリングで使用するネットワークを復旧した後、「7.16.6 1ノードのみで運用した後、2ノード運用に復旧する方法」の「復旧手順」を実行します。

(7) ディスクの活性交換の作業中にノードが再起動されてしまった【RHEL6】。

説明

RHEL6 環境において、サーバ間ミラーリングで使用しているディスクに対し、「7.3.3.1 活性交換(RHEL6)」の作業中にノードが再起動されてしまった場合、以下の対処を行ってください。

対処

対処方法は、再起動されたノードがディスクを交換するノードかどうかによって異なります。

ディスクを交換するノードが再起動された場合の復旧方法

ディスクを交換するノードが再起動されてしまった場合、以下の対処を行います。

以下に記載されている手順の番号は、「7.3.3.1 活性交換(RHEL6)」の手順の番号です。

再起動のタイミング

対処

手順1実行中

ノードが再起動された後、交換対象のスライスの状態を確認します。
NOUSE 状態の場合、手順2以降を実行します。(*1)
NOUSE 以外の状態の場合、手順1以降を実行します。(*1)

手順1完了後、または、手順2～5実行中

手順2以降を実行します。(*1)

手順5完了後、または、手順6実行中

ノードが再起動された後、ディスク交換が完了していない場合、手順2以降を実行します。
ディスク交換が完了している場合、手順7以降を実行します。

手順6完了後、または、手順7, 8実行中

ノードが再起動される前に実行していた手順の続きを実行します。

手順8完了後、または、手順9～13実行中

手順11以降を実行します。

手順13完了後、または、手順14実行中

ノードが再起動された後、交換対象のスライスの状態を確認します。
NOUSE 状態の場合、手順14を実行します。
NOUSE 以外の状態の場合、手順は終了です。

(*1) 「物理ディスク交換」(または sdxswap -O コマンド)を実行したデバイスが作成されなかった場合、手順2, 4, 6は不要です。

ディスクを交換しないノードが再起動された場合の復旧方法

ディスクを交換しないノードが再起動されてしまった場合、正常にアクセスできるディスクが存在しなくなり、ディスク交換を行うネットミラーグループに属するボリュームにアクセスできなくなります。

以下の手順で復旧を行います。

  1. 「D.1.6 サーバ間ミラーリングに関する異常」の「 (2) ノード再起動後、クラスタアプリケーションがFaultedまたはInconsistent状態になる。」の「対処」のうち、クラスリソースの復旧(手順5)以外の手順を実行します。

    ただし、ディスク交換(手順3-1)は行わないでください。

  2. 必要に応じて、ボリュームにアクセスする業務を再開します。

  3. ディスクを交換します。

    ディスク交換手順は、ディスクを交換しないノードが再起動されたタイミングによって異なります。

    以下に記載されている手順の番号は、「7.3.3.1 活性交換(RHEL6)」の手順の番号です。

    再起動のタイミング

    ディスク交換手順

    手順1実行中

    ノードが再起動された後、交換対象のスライスの状態を確認します。
    NOUSE状態の場合、手順2以降を実行します。
    NOUSE以外の状態の場合、手順1以降を実行します。

    手順1完了後、または、手順2, 3実行中

    手順2を実行してから、ノードが再起動される前に実行していた手順の続きを実行します。

    手順3完了後、または、手順4～8実行中

    ノードが再起動される前に実行していた手順の続きを実行します。

    手順8完了後、または、手順9, 10実行中

    ノードが再起動される前に実行していた手順の続きを実行します。
    手順11完了後、ディスクを交換しないノードでデバイス削除(*1)を実行します。
    手順12完了後、GDSのデバイス情報を更新します(*2)。

    手順10完了後、または、手順11～13実行中

    ノードが再起動される前に実行していた手順の続きを実行します。

    手順13完了後、または、手順14実行中

    ノードが再起動された後、交換対象のスライスの状態を確認します。
    NOUSE状態の場合、手順14を実行します。
    NOUSE以外の状態の場合、手順は終了です。

    GDS : Global Disk Services

    (*1) 以下のコマンドを実行します。iSCSIデバイス名には「物理ディスク交換」(または sdxswap -O コマンド)を実行したデバイスを指定します。

    # echo offline > /sys/block/iSCSIデバイス名/device/state
# echo 1 > /sys/block/iSCSIデバイス名/device/delete

    (*2) 以下のコマンドを実行します。iSCSIデバイス名には「物理ディスク交換」(または sdxswap -O コマンド)を実行したデバイスを指定します。

    # /etc/opt/FJSVsdx/bin/sdx_by_id replace iSCSIデバイス名

  4. 「D.1.6 サーバ間ミラーリングに関する異常」の「 (2) ノード再起動後、クラスタアプリケーションがFaultedまたはInconsistent状態になる。」の「対処」のうち、クラスリソースの復旧(手順5)を実行します。

(8) ディスクの活性交換の作業中にノードが再起動されてしまった【RHEL7】。

説明

RHEL7 環境において、サーバ間ミラーリングで使用しているディスクに対し、「7.3.3.3 活性交換(RHEL7)」の作業中にノードが再起動されてしまった場合、以下の対処を行ってください。

対処

対処方法は、再起動されたノードがディスクを交換するノードかどうかによって異なります。

ディスクを交換するノードが再起動された場合の復旧方法

ディスクを交換するノードが再起動されてしまった場合、以下の対処を行います。

以下に記載されている手順の番号は、「7.3.3.3 活性交換(RHEL7)」の手順の番号です。

再起動のタイミング

対処

手順1実行中

ノードが再起動された後、交換対象のスライスの状態を確認します。
NOUSE 状態の場合、手順2以降を実行します。(*1)
NOUSE 以外の状態の場合、手順1以降を実行します。(*1)

手順12完了後、ディスクを交換したノードを再起動してから手順13を実行します。

手順1完了後、または、手順2～6実行中

手順2以降を実行します。(*1)
手順12完了後、ディスクを交換したノードを再起動してから手順13を実行します。

手順6完了後、または、手順7実行中

ノードが再起動された後、ディスク交換が完了していない場合、手順2以降を実行します。(*1)
ディスク交換が完了している場合、手順8以降を実行します。
手順12完了後、ディスクを交換したノードを再起動してから手順13を実行します。

手順7完了後、または、手順8, 9実行中

ノードが再起動される前に実行していた手順の続きを実行します。
手順12完了後、ディスクを交換したノードを再起動してから手順13を実行します。

手順9完了後、または、手順10～12実行中

手順10以降を実行します。

手順12完了後、ディスクを交換したノードを再起動してから手順13を実行します。

手順12完了後、または、手順13,14実行中

手順13以降を実行します。

手順14完了後、または、手順15実行中

ノードが再起動された後、交換対象のスライスの状態を確認します。
NOUSE 状態の場合、手順15を実行します。
NOUSE 以外の状態の場合、手順は終了です。

(*1) 「物理ディスク交換」(または sdxswap -O コマンド)を実行したデバイスが作成されなかった場合、手順2, 4, 5, 6は不要です。

ディスクを交換しないノードが再起動された場合の復旧方法

ディスクを交換しないノードが再起動されてしまった場合、正常にアクセスできるディスクが存在しなくなり、ディスク交換を行うネットミラーグループに属するボリュームにアクセスできなくなります。

以下の手順で復旧を行います。

  1. 「D.1.6 サーバ間ミラーリングに関する異常」の「 (2) ノード再起動後、クラスタアプリケーションがFaultedまたはInconsistent状態になる。」の「対処」のうち、クラスリソースの復旧(手順5)以外の手順を実行します。

    ただし、ディスク交換(手順3-1)は行わないでください。

  2. 必要に応じて、ボリュームにアクセスする業務を再開します。

  3. ディスクを交換します。

    ディスク交換手順は、ディスクを交換しないノードが再起動されたタイミングによって異なります。

    以下に記載されている手順の番号は、「7.3.3.1 活性交換(RHEL6)」の手順の番号です。

    再起動のタイミング

    ディスク交換手順

    手順1実行中

    ノードが再起動された後、交換対象のスライスの状態を確認します。
    NOUSE 状態の場合、手順2以降を実行します。
    NOUSE 以外の状態の場合、手順1以降を実行します。

    手順1完了後、または、手順2～4実行中

    手順2を実行してから、ノードが再起動される前に実行していた手順の続きを実行します。

    手順4完了後、または、手順5～10実行中

    ノードが再起動される前に実行していた手順の続きを実行します。

    手順10完了後、または、手順11～14実行中

    ノードが再起動される前に実行していた手順の続きを実行します。

    手順14完了後、または、手順15実行中

    ノードが再起動された後、交換対象のスライスの状態を確認します。
    NOUSE 状態の場合、手順15を実行します。
    NOUSE 以外の状態の場合、手順は終了です。

  4. 「D.1.6 サーバ間ミラーリングに関する異常」の「 (2) ノード再起動後、クラスタアプリケーションがFaultedまたはInconsistent状態になる。」の「対処」のうち、クラスリソースの復旧(手順5)を実行します。

(9) 両ノード停止時にアンマウントに関するメッセージが出力される。

説明

両ノード停止時、ネットミラーボリューム上のファイルシステムの Fsystem リソースについて、以下の RMS ウィザード (RMSWT) のメッセージが /var/log/messages ファイルに出力されることがあります。

NOTICE: umount マウントポイント failed with error code 1

WARNING: The file system マウントポイント was not unmounted.

対処

本メッセージが出力されても、システムへの影響はありません。対処は不要です。

前次
Copyright FUJITSU LIMITED 2017-2019