この章では,次の事項について説明します。
CAA (Cluster Application Availability) サブシステムの概要 (5.1 節)
CAA アーキテクチャの説明 (5.2 節)
リソース・プロファイルとその使用方法 (5.4 節)
CAA (Cluster Application Availability) サブシステムは,シングル・インスタンス・アプリケーションの可用性を高め,他のタイプのリソース (ネットワーク・インタフェース,テープ・デバイス,メディア・チェンジャ・デバイスなど) の状態を監視します。シングル・インスタンス・アプリケーションは,クラスタ上の 1 つのメンバで動作し,同時に複数のメンバで動作することはできません。Tru64 UNIX で動作可能なすべてのシングル・インスタンス・アプリケーションは,CAA のあるクラスタでは可用性を高めることができます。たとえば,クラスタでは,BIND (named
),DHCP (joind
),ネットワーク・ロック (rpc.lockd
および
rpc.statd
) のデーモンが,CAA によって管理されています。
CAA の制御下で動作する各アプリケーションには,アプリケーションのリソース要件と,そのアプリケーションを別のクラスタ・メンバに再配置できる状況を示す,リソース・プロファイルがあります。CAA はクラスタ・メンバとリソースを監視して,各アプリケーションが,そのリソース要件を満たすメンバで動作することを保証します。リソース・プロファイルは,コマンド行インタフェースまたはグラフィカル・ユーザ・インタフェース (GUI) のいずれかを使用して作成および管理することができます。
必須のリソース,または現在のメンバ自体が動作できなくなった場合,CAA は自動的にアプリケーションを他のクラスタ・メンバに再配置します。この機能はアプリケーション自体の変更を必要とせず,どのようなシングル・インスタンス・アプリケーションでも使用できます。また,CAA では,リソースを監視して,リソース障害のためにオフラインにされていたアプリケーション・リソースを再起動できるようにすることができます。
さらに,CAA では,アプリケーション・リソースの配置の再評価を定期的にスケジュールされた時刻に行うことも,または管理者が手動によるアプリケーションの負荷分散を行うときにもできます。負荷分散は,負荷を考慮して行うのではなく,CAA の標準配置決定メカニズムを使用して行います。最適なクラスタ・メンバに配置されなかったアプリケーションは,最も好ましいクラスタ・メンバに再配置されます。
注意
CAA によるリソースの監視やアプリケーションの再起動機能は,以前の TruCluster 製品でのユーザ定義サービスのために ASE (Available Server Environment) によって提供されていたタイプのアプリケーションの可用性に対して強化された機能です。
メンバの障害により 2 番目のメンバにアプリケーションがフェイルオーバされる方法を,図 5-1
に示します。クライアントがクラスタ別名を使用してアプリケーションにアクセスしている場合,クラスタ別名サブシステムは,接続要求を自動的に 2 番目のメンバに転送します。
図 5-1: CAA によるアプリケーションのフェイルオーバ
CAA サブシステムには,次の構成要素があります。
リソースとは,エンド・ユーザまたは別のソフトウェア構成要素に対してサービスを提供するクラスタのソフトウェアまたはハードウェア構成要素であり,クライアントに対するサービスを高可用にするために CAA が使用します。CAA では,次のタイプのリソースをサポートしています。つまり,アプリケーション,ネットワーク・インタフェース,テープ・ドライブ,メディア・チェンジャです。
リソース・マネージャは,CAA サブシステムのすべての構成要素,接続マネージャおよびイベント・マネージャ (EVM) と通信を行います。
リソース・マネージャは,クラスタ・メンバ上で実行されるすべての CAA デーモンからなります。各 CAA デーモン (caad
) は,必須のリソース,アプリケーション自体,またはクラスタ・メンバに障害が発生した場合に,アプリケーション・リソースの起動,停止,再配置,再起動を行います。各クラスタ・メンバは,CAA デーモンを実行します。これらのデーモンは独立していますが,相互に通信を行い,リソースの状態に関する情報を共有します。いずれかの
caad
デーモンで障害が発生した場合,Essential Services Monitor デーモンである
esmd
が障害の発生した
caad
デーモンを再起動するので,リソースの管理を継続することができます。
リソース・マネージャは,リソース・モニタを使用して,特定のタイプのリソースの状態の監視も行います。
リソース・モニタは,/var/cluster/caa/monitors
にあるシェアード・ライブラリであり,ブート時に,リソース・マネージャ
caad
によってロードされます。各タイプのリソース (アプリケーション,テープ,メディア・チェンジャ) に対して 1 つのリソース・モニタがあります。
リソース・プロファイルには,リソース・マネージャとリソース・モニタがアプリケーションの再配置の管理とリソースの監視に使用する情報が含まれています。
リソース・プロファイルには,リソース,(アプリケーション・リソースに対する) 依存関係,および CAA によるリソースの管理方法を定義する,キーワードと値からなる属性が含まれています。caa_register
でリソースを登録すると,リソース・マネージャがリソース・プロファイルを使用できるようになります。
リソース・プロファイルは,caa_profile
コマンドおよび SysMan で作成することも,任意のテキスト・エディタで作成することもできます。テキスト・エディタで作成または変更したプロファイルは,caa_profile
-validate
によって検証し,正しい構文であることを確認する必要があります。構文エラー以外のエラーは,登録時に検出されます。この 2 段階の検証により,現在,オフライン状態や,これから作成するリソースとの依存関係を使用して,プロファイルを作成することが可能になります。
リソース・プロファイルは,/var/cluster/caa/profile
ディレクトリにあります。リソース・プロファイルのファイル名は,resource_name.cap
という形式です。
処理スクリプトは,CAA がアプリケーションの起動,停止,およびチェックに使用するコマンドのセットです。アプリケーションの処理スクリプト名は,アプリケーションのリソース・プロファイル内で定義されます。
処理スクリプトは,コマンド行インタフェース,SysMan,またはテキスト・エディタで作成や更新ができます。
処理スクリプトでは,CAA で利用できる変数を使用できます。すべてのプロファイル属性の値は,処理スクリプトで使用できます。理由コードの変数は,処理スクリプトが実行される理由を示します。処理スクリプトが実行される環境のロケール変数の多くは,処理スクリプトで使用できます。また,ユーザ定義属性も処理スクリプトで使用できます。
オプションで,処理スクリプトの標準出力をスクリプトを起動するコマンドの標準出力にリダイレクトすることができます。省略時の設定では,この標準出力のリダイレクトは行われません。
処理スクリプトは,/var/cluster/caa/script
ディレクトリにあります。処理スクリプトのファイル名は,resource_name.scr
という形式です。
CAA サブシステムには,リソースの管理と監視を行う,caa_profile
,caa_register
,caa_unregister
,caa_start
,caa_stop
,caa_relocate
,caa_balance
,caa_report
,caa_stat
コマンドがあります。CAA
の全リファレンス・ページのリストについては,
caa
(4)
コマンド行インタフェースは,リソース・プロファイル,処理スクリプト,リソース・マネージャと連携して動作します。
SysMan Menu および SysMan Station には,クラスタ,クラスタ・メンバ,CAA アプリケーションのシステム管理作業を実行するための,グラフィカル・ユーザ・インタフェース (GUI) があります。GUI を使用して CAA アプリケーションのシステム管理作業を実行する方法についての詳細は,sysman
(8) と,SysMan Menu および SysMan Station のオンライン・ヘルプを参照してください。
CAA の GUI は,コマンド行インタフェースを呼び出して,リソース・プロファイル,処理スクリプト,リソース・マネージャと連携して動作します。
接続マネージャとイベント・マネージャは CAA サブシステムの一部ではありませんが,CAA サブシステムではこれらの機能を広い範囲で使用しています。
図 5-2
は,CAA のアーキテクチャを図示しています。
図 5-2: CAA のアーキテクチャ
リソースとは,エンド・ユーザまたは他のソフトウェア構成要素にサービスを行う,クラスタのハードウェア構成要素またはソフトウェア構成要素です。リソースは,クライアントに対するサービスを高可用にするために CAA が使用する構成要素です。CAA では,次のタイプのリソースをサポートしています。
アプリケーション
実行可能プログラム。
アプリケーション・リソースでは,別のアプリケーション・リソースを含め,他のリソースに対する依存関係を持つことができます。アプリケーション・リソースを定義するリソース・プロファイルでは,これらの依存関係は必須の
REQUIRED_RESOURCES
,またはオプションの
OPTIONAL_RESOURCES
として定義されます。
リソースを必須リソースとして定義し,その必須リソースが利用できなくなった場合,CAA はそのアプリケーションを停止します。そして CAA は,その必須リソースを持つ他のメンバでアプリケーションを再起動しようとします。他のメンバがダウンしていたり,配置ポリシによってそのメンバからのアプリケーションの起動が禁止されているために,CAA が他のメンバでアプリケーションを再起動できない場合,アプリケーションは停止されます。CAA は,すべての必須リソースが利用できるようになるまで,そのアプリケーションを再起動しません。
オプションのリソースは,必須リソース,およびアプリケーションを起動する最適なシステムを判断するための再配置ポリシと組み合わせて使用されます。オプション・リソースが使用できなくなっても,アプリケーションはフェイルオーバされません。
ネットワーク
ネットワーク・インタフェース。 クラスタのメンバはすべて,任意のメンバに接続されている任意のネットワークに,間接的にアクセスできます。他のクラスタ・メンバ上で利用できるネットワーク接続を長時間に渡って利用するアプリケーションでは,クラスタ・インターコネクトへのトラフィックが増加する可能性があり,アプリケーションとクラスタの両方の性能を低下させることがあります。ネットワーク・リソースをアプリケーションの必須リソースとして定義することは,特定のネットワークに直接接続されているメンバでアプリケーションを実行させたい場合に便利です。
ネットワーク・リソースをアプリケーションの必須リソースとして定義していて,ネットワーク・インタフェース・アダプタに障害が発生した場合,CAA はリソースの再配置ができなければ,アプリケーションを再配置または停止します。
ネットワーク・リソースをアプリケーションのオプション・リソースとして指定すると,CAA はサブネットに直接接続されているメンバ上でアプリケーションを起動します。サブネット・アダプタに障害が発生すると,アプリケーションは,間接的にネットワークにアクセスする状態に戻ります。
テープ
またはチェンジャ
テープ・ドライブまたはメディア・チェンジャ。 テープ・リソースまたはメディア・チェンジャ・リソースをアプリケーションの必須リソースとして定義すると,そのアプリケーションは必ず,テープ・デバイスまたはチェンジャに直接接続されているクラスタ・メンバで実行されます。デバイスに障害が発生すると,CAA はアプリケーションを再配置しようとし,再配置ができなければ,アプリケーションを停止します。
テープ・リソースまたはメディア・チェンジャ・リソースをアプリケーションのオプションのリソースとして定義すると,CAA はそのアプリケーションを直接接続されているメンバで実行しようとしますが,デバイスに直接接続されていないメンバでそのアプリケーションを実行することもあります。性能を最大限に向上させるには,テープ・デバイスに直接接続されているメンバで実行することが望まれます。
各リソースにはリソース・プロファイルがあります。このプロファイルでは,リソースの定義,その依存関係のリスト,CAA
によるリソースの管理方法を定義しています。リソース・プロファイルは,キーワードと値のペアのリストが格納されたテキスト・ファイルで,
caa
(4)/var/cluster/caa/profile
ディレクトリに置かれています。
CAA でリソースの監視と管理を行うには,caa_register
コマンドを使用して,リソース・プロファイルを登録する必要があります。
以降の各項で,リソース・プロファイルの 2 つのタイプについて説明します。
アプリケーション・リソースの場合,リソース・プロファイルにはアプリケーションのタイプ,名前,チェック間隔,監視のしきい値,リソースの依存関係 (必須リソース),オプションのリソース,ホスト・メンバ・リスト,配置ポリシ,再起動試行,フェイルオーバ遅延,自動起動およびアクティブ配置に関する設定値,負荷分散を行う時間や,処理スクリプトの名前が含まれます。いくつかのキーワードはオプションです。たとえば,次の
named.cap
というリソース・ファイルのサンプルでは,アクティブ配置を設定していません。これは,メンバがブートしてクラスタに組み込まれた際に,アプリケーションの配置は再評価されないということです。
# cat named.cap TYPE = application NAME = named DESCRIPTION = BIND Server CHECK_INTERVAL = FAILURE_THRESHOLD = 0 FAILURE_INTERVAL = 0 REQUIRED_RESOURCES = OPTIONAL_RESOURCES = HOSTING_MEMBERS = PLACEMENT = balanced RESTART_ATTEMPTS = FAILOVER_DELAY = AUTO_START = ACTION_SCRIPT = named.scr
プロファイルおよびキーワードの各タイプについての詳細は,
caa
(4)caa_profile
(8)
アプリケーション・プロファイルは,ユーザ定義属性を使用して拡張できます。これらの属性値は,アプリケーション・プロファイルまたは CAA コマンドのコマンド行で定義できます。これらの属性値は,処理スクリプトで使用し,リソースの起動,停止,チェック時における処理スクリプトの実行をカスタマイズできます。ユーザ定義属性はアプリケーション・タイプ定義ファイル内のすべてのアプリケーション・リソースに対して定義できます。詳細は,『クラスタ高可用性アプリケーション・ガイド』 を参照してください。
この項の以降の部分では,配置ポリシ,ホスト・メンバ,アクティブ配置,障害しきい値,および障害間隔について,その概要を説明します。処理スクリプトについては,5.5 節で説明します。
アプリケーションの配置ポリシは,どこでアプリケーションを起動するかを決定します。
サポートされているポリシは,balanced
,favored
,restricted
です。
balanced
CAA は,現在稼働しているアプリケーション・リソースが最も少ないメンバ上で,アプリケーション・リソースの起動または再起動を行います。オプションのリソースによる配置が最初に考慮されます。次に,実行中のアプリケーションが最も少ないホストが選択されます。この基準で優先されるクラスタ・メンバがない場合は,利用可能な任意のメンバが選ばれます。
favored
CAA は,リソース・ファイルの
HOSTING_MEMBERS
属性のメンバ・リストを参照します。このリストにあって,必須リソースを満足するクラスタ・メンバだけが配置に適するメンバとして考慮されます。オプションのリソースによる配置が最初に考慮されます。オプションのリソースに基づいてメンバを選択できない場合,ホスト・メンバの順番により,そのアプリケーション・リソースを実行するメンバが決められます。ホスト・メンバ・リストにあるどのメンバも利用できない場合には,CAA は,実行しているアプリケーション・リソースが最少のメンバ上にそのアプリケーション・リソースを配置します。
favored 配置ポリシを選択した場合は,ホスト・メンバ・リストを指定しなければなりません。
restricted
このポリシは favored 配置ポリシと似ていますが,利用できるメンバがホスト・メンバ・リスト中にない場合に,CAA がアプリケーション・リソースの起動や再起動を行わない点が異なります。restricted 配置ポリシでは,手動でリソースを再配置しないかぎり,リストに載っていないメンバ上でリソースが実行されることはありません。
restricted 配置ポリシを選択した場合は,ホスト・メンバ・リストを指定しなければなりません。
ホスト・メンバとは,アプリケーションの (a) 起動時に考慮するメンバ,または (b) 再配置時に考慮するメンバを優先順位の順に並べたものです。ホスト・メンバ・リストは,favored 配置ポリシまたは restricted 配置ポリシの場合にのみ使用されます。
アクティブ配置では,新規クラスタ・メンバがクラスタに追加されるか,またはリブートされると,CAA はアプリケーションの配置を再評価します。より高い優先度のクラスタ・メンバがクラスタに参加したときに,アクティブ配置がオンになっている場合,アプリケーションは現在のメンバ上で停止して,より優先度の高いメンバ上で再起動します。
時刻に基づいてアプリケーションをフェールバックさせたい場合は,アクティブ配置の代わりに
REBALANCE
プロファイル属性を使用できます。アプリケーションは,クラスタ・メンバがクラスタに復帰したときではなく,指定した時間に優先メンバに再配置されます。
障害しきい値および障害間隔時間は,繰り返し障害の発生しているアプリケーションを停止させるために,一緒に使用されます。障害間隔時間内にアプリケーションが何度も失敗すると,そのアプリケーションは再起動されません。これらの値は,アプリケーションのチェックが失敗した場合にのみ考慮され,最初の起動の際には考慮されません。
再起動試行回数は,1 つのクラスタ・メンバ上で,アプリケーションの起動試行が失敗したとみなされるまでに実行するアプリケーションの起動または再起動の最大試行回数を定義します。
5.4.2 非アプリケーション・リソース・プロファイル
現在サポートされているリソースの他のタイプ (ネットワーク,テープ,メディア・チェンジャ) には,監視するリソースを定義し,障害しきい値および障害間隔時間を指定するリソース・プロファイルがあります。障害間隔時間の間に,非アプリケーション・リソースに何度も障害が発生すると,そのリソースの監視は停止します。
テープ・リソースおよびメディア・チェンジャ・リソースについては,デバイス名により監視するテープを定義し,ネットワーク・リソースについては,サブネットを定義する必要があります。
リソース・プロファイルの内容と作成についての詳細は,『クラスタ高可用性アプリケーション・ガイド』,
caa_profile
(8)caa
(4)5.5 処理スクリプト
処理スクリプトは,CAA がアプリケーションの起動,停止,チェックを行うために使用するコマンドのセットです。アプリケーション・リソースだけが処理スクリプトを持つことができます。処理スクリプトの名前は,アプリケーションのリソース・プロファイルに
ACTION_SCRIPT
値として指定されています。
省略時の設定では,処理スクリプトは
/var/cluster/caa/script
ディレクトリに置かれていますが,クラスタ・ファイル・システム上の別のディレクトリに置くこともできます。処理スクリプトのファイル名は,resource_name.scr
という形式をしています。
『クラスタ高可用性アプリケーション・ガイド』に,処理スクリプトの例があります。
機能としては,処理スクリプトは,ASE (Available Server Environment) スクリプト,および
/sbin/init.d
ディレクトリにあるシステム初期化スクリプトに似ています。
処理スクリプトには,アプリケーション・リソースの起動または停止が必要な場合に CAA コマンドから実行されるエントリ・ポイントが複数あります。start
エントリ・ポイントは,caa_start
と
caa_relocate
がアプリケーションの起動のために使用し,stop
エントリ・ポイントは
caa_stop
と
caa_relocate
がアプリケーションの停止のために使用します。check
エントリ・ポイントは,リソース・マネージャがアプリケーションが実行中であることを確認するために使用されます。
アプリケーション・リソース・プロファイルには,各処理スクリプトに対応するタイムアウト値が定義されています。処理スクリプトの実行がこの時間内に終わらなかった場合,CAA は起動失敗と見なし,アプリケーションを別のメンバで起動するか,完全な障害とします。
オプションで,処理スクリプトの標準出力をスクリプトを起動する CAA コマンドの標準出力にリダイレクトすることができます。
caa_profile
コマンドと SysMan の一連のアプリケーションはどちらも,リソース・プロファイルを作成する際に簡単な処理スクリプトを作成するために使用できます。アプリケーションの起動,停止,およびチェック処理をカスタマイズするために,これらの処理スクリプトを編集しなければならないことがあります。