ディスクとファイルシステムの問題

共用ボリューム・グループに対する varyon 操作中に AIX ボリューム・グループ・コマンドが失敗する

問題

/var/hacmp/log/hacmp.out ファイルは、ネットワーク・ファイル・システム (NFS) マウントされたファイルシステムの強制的なアンマウントを実行したときに、cl_nfskill コマンドが失敗したことを示します。 NFS には、cl_nfskill コマンドによる強制的なアンマウントの影響を受けないファイルシステムの特定レベルのロックがあります。

解決方法

共用ボリューム・グループを構成する場合、 「システム再始動時にボリューム・グループを自動的に活動化しますか?」 を設定します。 SMIT システム管理 (C-SPOC) > PowerHA SystemMirror 論理ボリューム管理 > 共用ボリューム グループ > 共用ボリューム グループの作成パネルで、このフィールドを no に設定します。 別のクラスター・ノードの共用ボリューム・グループをインポートした後、以下のコマンドを使用して、各ノードのボリューム・グループが「autovaryon at boot」に設定されていないことを確認します。

chvg -an vgname

varyonvg コマンドがボリューム・グループで失敗する

このセクションでは、ボリューム・グループで失敗する varyonvg コマンドによって示されるさまざまな問題について 説明します。

問題 1

PowerHA® SystemMirror® ソフトウェア（ /var/hacmp/log/hacmp.out ファイル）は、ボリュームグループで変動しようとしたときに varyonvg コマンドが失敗したことを示しています。

解決方法

ボリューム・グループが、いずれのノード上でも「autovaryon」に設定されていなくて、ボリューム・グループ (コンカレント・アクセス・モードでない場合) が別のノードによりオンにまだ変更されていないことを確認します。

lsvg -o コマンドを使用して、共用ボリューム・グループがアクティブであるかどうかを判別します。 ボリューム・グループが活動化されている ノードで lsvg volume_group_name と入力し、「自動オン」フィールドを調べて、ボリューム・グループが自動的にオンに設定されているかどうかを判別します。 「自動オン」フィールドが「yes」に設定されている場合、chvg -an volume_group_name コマンドを使用して値を変更できます。

問題 2

ディスク上のボリューム・グループ情報がデバイス構成データベースの情報と異なっています。

解決方法

以下のように、情報が誤っているノードのデバイス構成データベースを訂正します。

1. smit exportvg 高速パスを使用して、ボリューム・グループ情報をエクスポートします。 ボリューム・グループ情報はデバイス構成データベースから削除されます。
2. smit importvg 高速パスを使用して、ボリューム・グループをインポートします。 ディスク上の情報から新規デバイス構成データベース・エントリーが直接作成されます。 ボリューム・グループをインポートした後、次のシステム再始動時にボリューム・グループが「autovaryon」に設定されていないことを確認します。
3. SMITで、 Problem Determination Tools > Recover From PowerHA System Mirror Script Failureを選択します。 clruncmd コマンドが実行され、クラスター・マネージャーがクラスターの処理を再開します。

問題 3

PowerHA SystemMirror ボリュームグループが見つからない可能性があるため、 varyonvg コマンドが失敗しました。

解決方法

ボリューム・グループがシステムに定義されていません。 新規ボリューム・グループが作成およびエクスポートされる場合、または mksysb システム・バックアップがリストアされた場合は、そのボリューム・グループをインポートする必要があります。 「 問題 2.2 」で説明されているステップに従って、正しいボリューム・グループ名が参照されていることを確認してください。

問題 4

PowerHA SystemMirror ソフトウェアは、論理ボリュームが不完全なため、 varyonvg コマンドが失敗したことを示しています。

解決方法

強制variage on属性がSMITでボリュームグループに設定されており、強制variage on操作が実行されたときに、 PowerHA SystemMirror 、ボリュームグループの指定された論理ボリュームの完全なコピーが見つからないため、 varyonvg コマンドが失敗します。 また、強制 vary on 操作を要求しましたが、ミラーリングされた論理ボリュームに対して super strict 割り振りポリシーを指定しなかった可能性があります。 この場合、vary on 操作が成功しない可能性があります。

強制アンマウント操作の実行時に cl_nfskill コマンドが失敗する

問題

/var/hacmp/log/hacmp.out ファイルは、cl_nfskill コマンドが NFS マウントされたファイルシステムの強制的なアンマウント操作に失敗したことを示します。 NFS には、cl_nfskill コマンドによる強制的なアンマウント操作の影響を受けないファイルシステムの特定レベルのロックがあります。

解決方法

cl_nfskill コマンドを実行する前に、 /etc/locks ファイルのコピーを別のディレクトリーに作成します。 元の /etc/locks ファイルを削除し、cl_nfskill コマンドを実行します。 コマンドが成功した後、保存されたコピーを使用して /etc/locks ファイルを再作成してください。

cl_scdiskreset コマンドが失敗する

問題

cl_scdiskreset コマンドは、エラー・メッセージを /var/hacmp/log/hacmp.out ファイルに記録します。 SCSIデバイス上の1つのシステムが保持するリザーブを解除するには、 PowerHA SystemMirror ディスクユーティリティは、 cl_scdiskreset コマンドを発行します。 バックレベルのハードウェアが SCSI バス (アダプター、ケーブル、またはデバイス) に存在するか、SCSI ID 競合がバスに存在する場合、cl_scdiskreset コマンドは失敗することがあります。

解決方法

クラスタログファイルの使用トピックの該当するセクションを参照して、SCSIアダプタ、ケーブル、およびデバイスを確認します。 最新のアダプターおよびケーブルを使用していることを確認します。 各 SCSI デバイスの SCSI ID は、異なっている必要があります。

ブート時に fsck コマンドが失敗する

問題

ブート時に、 AIX は fsck コマンドを実行して、 check=true 属性を持つ /etc/filesystems にリストされているすべてのファイルシステムを検査します。 ファイル・システムを検査できない場合、 AIX はエラーを表示します。

解決方法

PowerHA SystemMirror によって制御されるファイル・システムの場合、このメッセージは通常、問題を示さない。 ファイルシステムの検査が失敗するのは、ファイルシステムを定義しているボリューム・グループがオンに変更されていないためです。 ブート手順は、 PowerHA SystemMirror- 制御されたボリュームグループで自動的に変化することはありません。

このメッセージを防ぐには、 PowerHA SystemMirror 制御下にあるすべてのファイルシステムの /etc/filesystems スタンザに check=true 属性がないことを確認する。 この属性を削除したり check=false に変更したりするには、/etc/filesystems ファイルを編集します。

指定のファイルシステムをシステムでマウントできない

問題

/etc/filesystems ファイルは論理ボリュームのログ名への変更を反映するように更新されません。 その論理ボリューム用のファイルシステムの作成後に、論理ボリューム名を変更すると、そのログの /etc/filesystems エントリーは更新されません。 ファイルシステムをマウントすると、PowerHA SystemMirror ソフトウェアでは、古いログ名から論理ボリューム名に関する必要な情報を取得しようとします。 この情報は更新されないため、ファイルシステムをマウントできません。

解決方法

論理ボリューム名を変更した後は、/etc/filesystems ファイルを更新してください。

クラスター・ディスクの交換操作が失敗する

問題

node_down イベントが原因でディスク交換操作が完了しませんでした。

解決方法

ノードがオンラインになった場合、ボリューム・グループをエクスポートしてから、このノードで PowerHA SystemMirror を開始する前にボリューム・グループをインポートしてください。

ファイルシステム変更がレイジー更新で認識されない

問題

ファイルシステム名を変更したり、ファイルシステムを除去してレイジー更新を実行する場合、レイジー更新は imfs コマンドを実行してから imfs -lx コマンドを実行します。 このアクションにより、フォールオーバー時に障害が発生したり、 PowerHA SystemMirror クラスター・サービスの再始動が正常に行われない場合があります。

解決方法

C-SPOC ユーティリティーを使用してファイルシステムを変更または除去し、 imfs コマンドの前に imfs -lx コマンドが実行され、クラスター内のすべてのノードで変更が更新されるようにします。

エラー報告機能は、クラスター全体におけるボリューム・グループ状態の矛盾に関して、詳細な情報を提供します。 エラー報告機能が動作した場合、手動で修正措置を取る必要があります。 ファイルシステムの変更がすべてのノード上で更新されない場合、この情報を使用して手動でノードを更新します。

clam_nfsv4 アプリケーション・モニター障害

問題

clam_nfsv4 アプリケーション・モニターが完了するまでの時間が 60 秒を超えました。 モニターは応答せず、停止しました。 そのため、ネットワーク・ファイルシステム (NFS) ノードでフォールオーバーが起こりました。 このフォールオーバーは、通常、アプリケーション・モニターをホストするシステムのパフォーマンス・ワークロードが高いときに発生します。

解決方法

この問題を修正するには、システムのワークロードを減らす必要があります。 また、システムに APAR IV08873 を適用して、clam_nfsv4 アプリケーション・モニター・スクリプトの実行にかかる時間を短縮することもできます。

LVM 分割サイト・ミラーリングのトラブルシューティング

問題

PowerHA SystemMirror および LVM には、ミラー・プールの定義時に指定された情報以外の、ディスクの物理ロケーションに関する情報がありません。

解決方法

以下の情報を検討して、LVM 分割サイト・ミラーリングの問題に関する可能な解決策を確認します。

• コマンド行から smitty cl_mirrorpool_mgt と入力し、 「Show Mirror Pools for a Volume Group (ボリューム・グループのミラー・プールの表示)」を選択して、ミラー・プールへのディスクの割り当てを確認します。
• コマンド行から smitty cl_lv と入力し、「Show Characteristics of a Logical Volume (論理ボリューム特性の表示)」を選択して、個々のファイルシステムおよび論理ボリュームのミラーリングが正しいことを検証します。
• コマンド行から smitty cl_vgsc と入力し、「ボリューム・グループの特性を変更/表示」を選択して、ボリューム・グループが非常に厳密であることを検証します。
• 再同期が失敗した場合は、AIX エラー・ログで、ボリューム・グループのディスクに関連した問題を調べます。 コマンド行から smitty cl_syncvg と入力し、 「Synchronize LVM Mirrors by Volume Group (ボリューム・グループごとに LVM ミラーを同期化する)」を選択することにより、ボリューム・グループを手動で再同期化することができます。

リポジトリー・ディスクのトラブルシューティング

問題

クラスター内のいずれかのノードがリポジトリー・ディスクのエラーまたはディスク・アクセス中の障害を検出した場合、クラスターは限定された、すなわち、制限された操作モードになります。 この操作モードでは、トポロジー関連の操作の大部分は実行できず、再始動したノードはいずれもクラスターに再結合できません。

解決方法

リポジトリー・ディスクに障害が起こると、ディスク障害通知が出されます。 PowerHA SystemMirror は、リポジトリのディスク障害が解決されるまで通知し続けます。 リポジトリー・ディスクにどのような問題が起こっているかを判別するには、以下のログ・ファイルを調べてください。

• hacmp.out
• AIX エラー・ログ (errpt コマンドを使用)

例: hacmp.out ログ

次に示すものは、リポジトリー・ディスクに障害が起こった場合に hacmp.out エラー・ログ・ファイルに書き込まれるエラー・メッセージの一例です。ERROR: rep_disk_notify : Tue Jan 10 13:38:22 CST 2012 : Node "r6r4m32"(0x54628FEA1D0611E183EE001A64B90DF0) on Cluster r6r4m31_32_33_34 has lost access to repository disk hdisk75.

例: AIX エラー・ログ

ノードがリポジトリー・ディスクにアクセスできなくなると、問題のあるノードごとに AIX エラー・ログに項目が立てられます。 次に示すものは、リポジトリー・ディスクに障害が起こった場合にエラー・ログ・ファイルに書き込まれるエラー・メッセージの一例です。

注: AIX エラー・ログを表示するには、 errpt コマンドを使用する必要があります。

LABEL:          OPMSG
IDENTIFIER:     AA8AB241

Date/Time:       Tue Jan 10 13:38:22 CST 2012
Sequence Number: 21581
Machine Id:      00CDB2C14C00
Node Id:         r6r4m32
Class:           O
Type:            TEMP
WPAR:            Global
Resource Name:   clevmgrd

Description
OPERATOR NOTIFICATION

User Causes
ERRLOGGER COMMAND

        Recommended Actions
        REVIEW DETAILED DATA

Detail Data
MESSAGE FROM ERRLOGGER COMMAND
Error: Node 0x54628FEA1D0611E183EE001A64B90DF0 has lost access to repository disk hdisk75.

障害または破損のあるリポジトリー・ディスクの交換

リポジトリー・ディスクに障害が発生した場合、すべてのクラスターの動作を回復するために、そのリポジトリー・ディスクを異なるディスク上で復旧する必要があります。 ご使用のクラスター環境およびリポジトリー・ディスクの障害のタイプによって、リポジトリー・ディスクの復旧に使用可能な方法は異なります。

自動リポジトリー・ディスク置換 (ARR)

PowerHA SystemMirror バージョン 7.2.0、またはそれ以降では、CAAのARR機能（ AIX Version 7.2、またはそれ以降、または AIX バージョン 7.1 テクノロジーレベル4、またはそれ以降）を使用して、リポジトリのディスク障害を処理します。 ARR は、障害が発生したリポジトリー・ディスクを自動的にバックアップ・リポジトリー・ディスクに置換します。 ARR 機能は、 PowerHA SystemMirror を使用してバックアップリポジトリディスクを構成した場合にのみ使用できます。 ARR について詳しくは、「 リポジトリー・ディスクの障害 」トピックを参照してください。

ARR はディスクにアクセスできない場合に、そのディスクをクリーンアップしないため、障害が発生したリポジトリー・ディスクのクリーンアップはユーザーが行う必要があります。 障害のあるリポジトリー・ディスクをクリーンアップするには、次のコマンドを使用します。

CAA_FORCE_ENABLED=true rmcluster -r <disk name>

以下に、リポジトリー・ディスクに障害が発生した場合の 2 つのシナリオ、およびそのリポジトリー・ディスクを新しいストレージ・ディスク上で復旧する方法について示します。

リポジトリー・ディスクに障害が発生したが、クラスターは作動可能である

このシナリオでは、クラスター内の 1 つ以上のノードでリポジトリー・ディスクのアクセスが失われているとします。 この障害が発生すると、 Cluster Aware AIX (CAA) は、メモリー内にキャッシュされているリポジトリー・ディスク情報を使用して、制限付きモードで動作を続行します。 CAA がクラスター内の 1 つのノードでアクティブなままである場合、古いリポジトリー・ディスクからの情報を使用して、新しいリポジトリー・ディスクを再ビルドすることができます。

障害の発生後にリポジトリー・ディスクを再ビルドするには、CAA がアクティブになっているノードから以下の手順を実行します。

1. lscluster -c コマンドを使用し、次に lscluster -m コマンドを使用して、ノード上で CAA がアクティブであることを確認します。
2. 「 SMIT によるリポジトリー・ディスクの交換 」トピックの手順を実行して、リポジトリー・ディスクを交換します。 PowerHA SystemMirror は問題を認識し、CAAとやりとりして新しいストレージディスク上にリポジトリディスクを再構築する。
   注： このステップでは、 PowerHA SystemMirror 構成データに格納されているリポジトリ情報を更新します。

   ARR 機能が使用可能な場合は、 ステップ 1 および ステップ 2を実行する必要はありません。

3. SMITインタフェースから ［クラスタ・ノードとネットワーク ］>［ クラスタ構成の確認と同期］を選択して、PowerHA SystemMirror クラスタ構成情報を同期します。

リポジトリー・ディスクに障害が発生し、クラスター内のノードが再始動した

まれに、以下のシナリオのようにクリティカルな障害が連続して発生することにより、リポジトリー・ディスクへのアクセスが失われ、クラスター内のすべてのノードがリブートされるという最悪のケースとなる場合があります。 これにより、障害発生時にクラスター内のすべてのノードがオンラインではなくなるため、AIX オペレーティング・システムのメモリーからリポジトリー・ディスクを再ビルドすることはできません。 ノードが再びオンラインに戻っても、クラスター内にリポジトリー・ディスクが存在しないために、ノードは CAA を始動することができません。 この問題を修正するために理想的なのは、リポジトリー・ディスクを復旧し、クラスターを自己回復させることです。 この方法が不可能な場合、新しいストレージ・ディスク上にリポジトリー・ディスクを再ビルドし、そのリポジトリー・ディスクを使用して CAA クラスターを始動する必要があります。

リポジトリー・ディスクを再ビルドしてクラスター・サービスを開始するには、以下の手順を実行します。

1. クラスター内のノードで、「 SMIT によるリポジトリー・ディスクの交換 」トピックの手順を実行して、リポジトリーを再ビルドします。 PowerHA SystemMirror は問題を認識し、CAAとやりとりして新しいストレージディスク上にリポジトリディスクを再構築する。
   注意: この手順では、 PowerHA SystemMirror 構成データに格納されているリポジトリ情報を更新し、CAA クラスタ・キャッシュ・ファイルからリポジトリ・ディスクを再構築します。

   ARR機能が利用できる場合は、 ステップ1を実行する必要はなく、自動的にディスクが交換される。

   リポジトリー・ディスクが置換された後、検証操作および同期化操作を実行します。 一部のノードがダウンしている場合、検証操作および同期化操作がエラーで失敗する可能性があります。 検証操作および同期化操作を正常に実行するには、次のコマンドを入力します。

   #/usr/es/sbin/cluster/utilities/cldare -f -dr
   

   cl_rsh エラーは無視しても構いません。
2. 『クラスター・サービスの開始』トピック内のステップを実行して、リポジトリー・ディスクをホストするノードでクラスター・サービスを開始します。
3. クラスター内の他のすべてのノードは、元のリポジトリー・ディスクへのアクセス試行を続行します。 新しいリポジトリー・ディスクを使用するようにこれらのノードを構成して、CAA クラスター・サービスを開始する必要があります。 lscluster -m コマンドを使用して、これらのいずれのノードでも CAA クラスターがアクティブになっていないことを確認します。 CAA クラスターが非アクティブであるか、またはローカル・ノードがダウン状態である場合は、次のコマンドを入力して、古いリポジトリー・ディスクの情報を削除します。

   export CAA_FORCE_ENABLED=true
   clusterconf -fu

4. 他のノードを CAA クラスターに参加させるには、新規作成したリポジトリー・ディスクについて、アクティブなノードで次のコマンドを使用します。

   clusterconf -p

   AIX バージョン 7.1 (テクノロジー・レベル 4) 以降の場合は、 ステップ 3 および ステップ 4を実行する必要はありません。 ステップ 2を完了した後、リブートされたすべてのノードは、新しいリポジトリー・ディスクを使用するために約 10 分間待機する必要があります。

5. 最初に lscluster -c コマンドを使用し、次に lscluster -m コマンドを使用して、CAA がアクティブであることを確認します。
6. SMITインタフェースからクラスタノードとネットワーク > クラスタ構成の確認と同期を選択して、新しく作成したリポジトリディスクに関するPowerHA SystemMirror クラスタ構成情報を他のすべてのノードに同期します。
7. SMITインタフェースからシステム管理（C-SPOC） > PowerHA SystemMirror サービス > クラスタサービスの開始を選択して、すべてのノード（リポジトリディスクを作成した最初のノード以外）で PowerHA SystemMirror クラスタサービスを開始します。

スナップショットのマイグレーションおよびリポジトリー・ディスク

オンライン・クラスターでのスナップショットのマイグレーション・プロセスを行うには、スナップショットのクラスター情報がオンラインのクラスター情報と一致している必要があります。 この要件は、リポジトリー・ディスクにも適用されます。 リポジトリー・ディスクの構成を変更した場合、これらの変更を反映するためにスナップショットを更新してから、スナップショットのマイグレーション・プロセスを実行する必要があります。

ディスク・フェンシングのトラブルシューティング