CA AppLogic の使用 › グリッド ユーザ ガイド › 高可用性 › CA AppLogic グリッド コントローラの自動復旧 › グリッド コントローラ サーバの障害 › 概要

概要

CA AppLogic では、グリッド コントローラと物理サーバの両方の障害に自動的に対応できるだけでなく、グリッド コントローラ サーバ（グリッド コントローラが現在実行されている物理サーバで、プライマリ サーバとも呼ばれる）の障害にも対応できます。 グリッド内の他のサーバと同じように、コントローラ サーバに障害が発生する理由はいくらでもあります。

コントローラ サーバの障害に対する耐性を得るため、CA AppLogic はサーバの役割を使用して、障害発生時にグリッド コントローラを実行することができるグリッド内の一連のサーバ（バックアップ コントローラ サーバ）を定義します。 CA AppLogic は、グリッド内で以下のサーバの役割を使用します（これらは自動的に設定されますが、ユーザまたはグリッド管理者が指定することもできます）。

• プライマリ： CA AppLogic グリッド コントローラを現在実行しているサーバ
• セカンダリ： プライマリ コントローラ サーバに障害が発生したときに CA AppLogic グリッド コントローラを実行できるサーバ
• なし： CA AppLogic グリッド コントローラを実行せず、コントローラの高可用性に参加しないサーバ

デフォルトでは、すべての CA AppLogic グリッドに以下のサーバの役割が設定されます。

• 1 サーバのグリッド： 1 台のプライマリ サーバ。1 サーバのグリッドは、プライマリ サーバの障害に対して耐性がありません（グリッド コントローラ サーバの高可用性がありません）。
• 2 サーバのグリッド： 1 台のプライマリ サーバと 1 台のセカンダリ サーバ（および 1 台のリファレンス サーバ）。
• 3 サーバ以上のグリッド： 1 台のプライマリ サーバと 2 台のセカンダリ サーバ。グリッド内の残りのサーバは「なし」の役割を割り当てられ、コントローラ サーバの障害復旧に参加しません。

プライマリ サーバに障害（ハードウェア/ソフトウェアの障害や電源の切断など）が発生すると、いずれかのセカンダリ サーバが自動的にグリッドの新しいプライマリ サーバの役割を引き受けます。 正常な状態に戻った古いプライマリ サーバは、自動的に非プライマリ サーバ（セカンダリ サーバ）になります。 新しいプライマリ サーバがグリッド コントローラを開始し、リストアされたコントローラがグリッドの状態を自動的に再取得します。 物理サーバの障害の場合と同じように、CA AppLogic は障害が発生したプライマリ サーバ上で実行されていたアプライアンスも自動的に再起動します。 セカンダリ コントローラ サーバの使用とアプライアンスの自動再起動によって、CA AppLogic はプライマリ コントローラ サーバの障害に対する耐性を得ることができます。

ユーザは、srv list コマンドを使用して、グリッド内に割り当てられたサーバの役割を表示できます。 srv set コマンドを使用して、サーバの役割を変更することもできます。

2 台のサーバのみで構成されたグリッドでは、グリッド コントローラの HA を適切にサポートするために 3 つ目のリファレンス サーバが必要です。 デフォルトでは、2.7 以降のグリッドがインストールまたはアップグレードされている場合は、CA AppLogic インストーラが BFC サーバをグリッドのリファレンス サーバとして割り当てます。 同じ BFC サーバを、同じバックボーン上にあるすべてのグリッドのリファレンス サーバとして使用できます。

CA AppLogic のグリッド コントローラの高可用性に関して留意すべき重要な注意事項を以下にいくつか示します。

重要： グリッドをコントローラ サーバの障害から復旧するには、サーバ障害の発生時に少なくとも 2 台のセカンダリ サーバが稼働している必要があります。 この要件が満たされない（たとえば、プライマリ サーバの障害発生時にセカンダリ サーバが 1 台しかない）場合、グリッド コントローラは停止したままとなり、グリッド コントローラを正常な状態に戻すにはグリッド管理者の操作が必要です。 コントローラにこのタイプの障害が発生した場合は、サービス プロバイダにお問い合わせください。

• プライマリ サーバに障害が発生し、少なくとも 2 時間にわたってオンライン状態に戻らない場合、CA AppLogic はグリッド コントローラのフェールオーバ用に少なくとも 2 つのセカンダリ サーバを保持するため、グリッド内で新しいセカンダリ サーバを自動的に割り当てます。
• 一般に、comp start または app start でアプライアンスの開始スケジュールを設定すると、サーバの役割と利用可能なリソースの両方に基づいてアプライアンスのスケジュールがサーバに設定されます。 CA AppLogic は、最初に「なし」の役割を持つサーバ、次にプライマリ サーバ、最後にセカンダリ サーバ上でアプライアンスが実行されるようにスケジュールを設定しようとします。 必要な場合にコントローラを開始するための利用可能リソースが存在する可能性を高めるため、セカンダリ サーバはスケジューリングの最終手段として使用されます。
• セカンダリ サーバが新しいプライマリ サーバの役割を引き受けたときに、グリッド コントローラを開始するための十分な利用可能リソースがサーバ上にない場合、CA AppLogic は新しいプライマリ サーバ上で実行されているアプライアンスをグリッド内の他のサーバ上で再起動し、新しいプライマリ サーバ上でグリッド コントローラを開始できるようにします。 これにより、アプライアンスのフェールオーバ グループが壊れることがあります。 CA AppLogic がこれらのアプライアンスのいずれかを停止すると、フェールオーバ グループに対応するための十分なリソースがなくなり、別のサーバ上でアプライアンスを再起動できなくなることがあります。