CA AppLogic の使用 › グリッド ユーザ ガイド › 高可用性 › アプリケーションとサービスの自動復旧 › サーバ障害 › サーバ障害によって劣化したボリュームと自動ボリューム修復

サーバ障害によって劣化したボリュームと自動ボリューム修復

サーバ障害の後、障害が発生したサーバ上にミラーがあった CA AppLogic ボリュームは劣化します（他の利用可能なサーバ上にボリュームのミラーがある場合）。 CA AppLogic 2.7 以降では、劣化したボリュームは自動的に修復されます。 以前のバージョンの CA AppLogic では、ボリューム修復はユーザまたはグリッド管理者が手動で行う操作でした。 CA AppLogic ボリュームは、以下の優先順位で自動的に修復されます。これにより、重要なボリュームが先に修復されるため、アプリケーション/グリッドのダウンタイムのリスクが軽減されます。

1. システム ボリューム（boot、meta、impex）
2. アプリケーション ユーザ ボリューム
3. アプリケーション ローカル カタログ ボリューム
4. グローバル カタログおよび _GLOBAL ボリューム
5. volcache ボリューム
6. 他のすべてのボリューム

サーバ障害の後、CA AppLogic は 4 時間待機してから、サーバ障害によって劣化したボリュームの修復を試みます。 これにより、サーバを復旧する機会が与えられ、ボリュームのストリームが割り当てられた元のサーバ上で劣化したボリュームを復旧できるようになっています。 障害が発生したサーバが 4 時間以内に復旧されない場合、CA AppLogic はグリッド内の他のサーバを使用して劣化したボリュームを修復します。 ユーザは、サーバ障害の後でただちに修復する必要があるボリュームを vol repair vol_name --force コマンドを使用して開始できます。

CA AppLogic の自動ボリューム修復は 6 時間ごとに 1 回実行され、劣化したボリュームのリストを収集し、それらのボリュームに対して修復を開始します。 CA AppLogic ユーザは、劣化したボリュームを修復するために何もする必要はありません。ボリューム修復は自動的に行われるようになりました。 ユーザは、vol check を実行して劣化したボリュームの最新のリストを取得するように CA AppLogic に指示できます。この機能を使用することにより、劣化したボリュームの最新のリストに対して修復のスケジュールを設定できます。

修復する必要がないボリュームがある場合や、修復を遅らせる必要がある場合は、以下で説明する vol suspend コマンドを使用して、特定のボリュームまたはすべてのボリュームの修復を一時停止できます。 ボリューム修復を一時停止できる期間は、最大 1 週間です。 グリッド管理者は、ボリュームの最大一時停止期間を設定できます。 詳細については、自動ボリューム修復の設定に関するトピックを参照してください（このトピックはグリッド管理者のみが参照できます）。

CA AppLogic では、ユーザは自動ボリューム修復に加えて以下のボリューム メンテナンス操作を実行できます。

• 特定のボリュームに対してただちに修復を開始する： vol repair vol_name --force
• 特定のボリュームの修復を指定した期間一時停止する： vol repair vol_name --suspend time=time
• 一時停止したボリュームの修復をただちに再開する： vol repair vol_name --resume
• 特定のボリュームの現在の修復ステータスを取得する： vol repair vol_name --status
• 劣化したボリュームすべての現在の状態を取得し、修復スケジュールを設定する： vol check

注： 一時停止、再開、およびステータス操作でボリューム名を省略すると、すべてのボリュームが操作の対象になります。 詳細については、vol repair の CLI リファレンスを参照してください。