クラスタの管理者は,クラスタ別名の数,各クラスタ別名のメンバシップ,およびクラスタ別名の各メンバの属性を制御します。また,/etc/clua_services
ファイル内でポートに割り当てられたクラスタ別名属性を制御します。
この章では次の項目について説明します。
クラスタ別名の特徴についての要約 (3.1 節)
クラスタ別名の構成と動作を制御するファイル (3.2 節)
一般的な設計に関する考慮事項 (3.3 節)
別名の作成準備 (3.4 節)
クラスタ別名の指定とクラスタ別名への参加 (3.5 節)
クラスタ別名属性とサービス・ポート属性の修正 (3.6 節)
クラスタ別名のモニタ (3.7 節)
クラスタ別名からのメンバの削除 (3.8 節)
クラスタ別名の削除 (3.9 節)
アプリケーションの負荷分散 (3.10 節)
クラスタ単位のポート・スペースの拡張 (3.11 節)
クラスタ別名の vMAC サポートの有効化 (3.12 節)
ルーティング構成のガイドライン (3.13 節)
ルーティング・デーモンと静的ルーティング・オプション (3.14 節)
クラスタ別名と NFS (3.15 節)
クラスタ別名と CAA (Cluster Application Availability) (3.16 節)
クラスタ別名の構成には
cluamgr
コマンドと SysMan Menu の両方を使用できます。
cluamgr
コマンド行インタフェースは,実行元のクラスタ・メンバを対象に,クラスタ別名関連のパラメータを構成します。パラメータはただちに有効になりますが,そのメンバの
clu_alias.config
ファイルにもコマンド行を追加しておかないと,リブートした後,無効になってしまいます。
SysMan Menu グラフィカル・ユーザ・インタフェース (GUI) は,クラスタのすべてのメンバを対象に,クラスタ別名関連の静的なパラメータを構成します。静的パラメータはメンバの
clu_alias.config
ファイルに書き込まれますが,次にブートし直すまでは有効になりません (新しいパラメータをただちに有効にしたい場合には,SysMan Menu がメンバの
clu_alias.config
ファイルに書き込んだコマンド行を手動で実行してください)。
TruCluster Server 『クラスタ概要』のクラスタ別名に関する章で,クラスタ別名の概念について説明しています。クラスタ別名属性またはサービス属性を修正する前に,この章を参照してください。
次に,クラスタ別名の重要な特長についてまとめます。
1 つのクラスタ内では,さまざまなメンバの集合から複数のクラスタ別名を作成できます。
クラスタには省略時のクラスタ別名が 1 つあります。省略時のクラスタ別名としてクラスタ名が使用されます。
クラスタ別名はドメイン・ネーム・システム (DNS) 名ではなく IP アドレスによって定義されます。クラスタ別名の IP アドレスとして,共通サブネットまたは仮想サブネット上の IP アドレスを使用できます。
クラスタのメンバは,クラスタ別名へのルートを公開するには,クラスタ別名を指定する必要があります。また,クラスタ別名宛の接続要求またはパケットを受信するには,クラスタ別名に参加しなければなりません。
クラスタ別名の管理はメンバ単位で行われます。1 つのメンバ上で
cluamgr
コマンドを入力すると,このコマンドはそのメンバのみに影響します。
クラスタ・メンバだけがクラスタ別名に参加できます。クラスタ別名と,クラスタ・メンバ上の特定のネットワーク・インタフェース・カード間には,1 対 1 の対応はありません。また,クラスタ別名と,1 つ以上のクラスタ・メンバ上の特定のアプリケーション間にも,1 対 1 の対応はありません。クラスタ別名は,クラスタの 1 つ以上のメンバが共通 IP アドレスに応答できるようにするための汎用メカニズムです。クラスタ別名と CAA (Cluster Application Availability) サブシステムとの違いについての説明は 3.16 節を参照してください。
/etc/clu_alias.config
ファイルは,メンバ固有のクラスタ別名構成ファイルを指すコンテキスト依存シンボリック・リンク (CDSL) です。ファイル内のコマンドは,ブート時に実行されます。各メンバのこのファイルには,次の処理をする
cluamgr
コマンドが記述されています。
省略時のクラスタ別名を指定して参加する。clu_create
および
clu_add_member
コマンドを使って,新しいメンバの
clu_alias.config
ファイルに次の行を追加する。
/usr/sbin/cluamgr -a selw=3,selp=1,join,alias=DEFAULTALIAS
(クラスタ別名サブシステムが,DEFAULTALIAS
キーワードをクラスタの省略時のクラスタ別名に自動的に対応させる。)
そのメンバがルートを公開するか参加するクラスタ別名があれば,その名前を指定する。
クラスタ別名属性を設定する。たとえば,ルーティング時の選択重みとルータ優先順位を設定する。
ブート時,クラスタの各メンバはそれぞれ固有の
clu_alias.config
を読み取るので,クラスタ別名の定義とメンバシップはリブートしても保持されます。このファイルの編集は手作業でも行うことができますが,SysMan Menu を使用して行うことを推奨します。SysMan Menu を使用して行った編集は,次のブート時まで有効になりません。新しい値を直ちに有効にするには,cluamgr
コマンド行を手動で実行します。
名前が
/etc/exports.aliases
ファイルの中に指定されているクラスタ別名のメンバは,その別名に宛てられたネットワーク・ファイル・システム (NFS) の要求を受け付けます。これにより,省略時のクラスタ別名とは異なる別名を NFS サーバとして使用できるようになります。詳細は,3.15 節を参照してください。
TruCluster Server バージョン 5.1B より前のリリースでは,ルーティング・デーモンとして
gated
をクラスタで実行する必要がありました。ogated
,routed
が使用できず,また,ルーティング・デーモンを使わない静的ルーティングのセットアップもできませんでした。バージョン 5.1B からは,gated
,routed
,または静的ルーティングが使用できます。ogated
は引き続き使用できません。ルーティング・オプションについては,3.14 節で説明しています。
省略時の構成では,クラスタ別名サブシステムは
gated
とルーティング情報プロトコル (RIP) を使用して,ホスト・ルートに別名アドレスを公開します。cluamgr
に
nogated
オプションを指定すると,この処理を無効にすることができます。例としては,routed -q
や
gated
をサイトごとにカスタマイズする構成ファイルで使用したり,または静的ルーティングを使用したりできます。
gated
がルーティング・デーモンとして使用されると,別名デーモンの
aliasd
は,必要に応じて,クラスタ・メンバの
/etc/gated.conf.membern
ファイルにホスト・ルート・エントリを追加します。別名デーモンはメンバの
gated.conf
ファイルを変更することはありません。
クラスタ別名経由でアクセスされるサービスが使用するネットワーク・ポートは,in_single
または
in_multi
を使って定義します。この定義は,サービスが同時に複数のクラスタ・メンバ上で実行されるかどうかには無関係です。この定義に従って,クラスタ別名サブシステムは次のように動作します。
サービスを
in_single
として指定すると,クラスタ別名の 1 つのメンバのみが,そのサービス宛の接続要求とパケットを受信する。そのメンバが使用できなくなった場合,クラスタ別名サブシステムは,そのサービス宛のすべての接続要求とパケットの受信先として,クラスタ別名の別のメンバを選択する。
サービスを
in_multi
として指定すると,クラスタ別名サブシステムは,そのサービス宛の接続要求とパケットをそのクラスタ別名の正式メンバすべてに送信する。
省略時の構成では,クラスタ別名サブシステムは,すべてのサービスを
in_single
とみなします。クラスタ別名サブシステムがサービスを
in_multi
とみなすようにするには,/etc/clua_services
ファイルを編集するか,clua_registerservice()
,clusvc_getcommport()
,または
clusvc_getresvcommport()
関数を呼び出して,そのサービスを
in_multi
として登録しなければなりません。
各クラスタ別名の識別に次の属性が使用されます。
クラスタ単位の属性:
IP アドレスとサブネット・マスク : クラスタ別名を識別する。
メンバ単位の属性:
ルータ優先順位 : 共通サブネット上でこの別名に対するプロキシ ARP (Address Resolution Protocol) 要求にどのクラスタ別名のメンバが応答するかを決定する。
選択優先順位 : クラスタ別名内でメンバに優先順位を付けて論理的にグループ化する。選択優先順位を使用することで,通常時に別名のどのメンバが要求を処理するかを制御することができる。選択優先順位の最も高いメンバが動作していれば,それより選択優先順位の低いメンバには要求が割り当てられない。選択優先順位は,別名メンバのフェイルオーバ順位を決める方法であると考えることもできる。
選択重み :
in_multi
が指定されている場合に,クラスタ別名のメンバ間の静的な負荷分散を制御する。これは,別名のどのメンバに最もよく接続を受け持たせるかを制御する単純な方法である。選択重みとは,接続を選択優先順位の同じ次の別名メンバへ回すまでにそのメンバが受け持つ (平均的な) 接続数を示す。
クラスタ別名およびサービスを管理するには,次の構成ファイルを使用します。
/sbin/init.d/clu_alias
これは,クラスタ別名サブシステムのブート時の起動スクリプトです。
/etc/clu_alias.config
これは,/sbin/init.d/clu_alias
スクリプトから呼び出されるメンバ固有の
clu_alias.config
ファイルへの CDSL です。各メンバの
clu_alias.config
ファイルには,ブート時に
cluamgr
コマンドを実行してそのメンバのクラスタ別名 (省略時のクラスタ別名を含む) を構成するとともに,そのクラスタ別名へ参加する指定が記述されています。
/etc/clua_services
これは,クラスタで提供されクラスタ別名でアクセスされるインターネット・サービス用のポート番号,プロトコル,および接続属性を定義するファイルです。cluamgr
コマンドは,このファイルをブート時に読み取り,各サービスをそれぞれの属性とともに登録します。
clua_services
ファイルを修正する場合は,クラスタの各メンバ上で
cluamgr -f
を実行します。詳細は,
clua_services
(4)cluamgr
(8)
/etc/exports.aliases
メンバの中に NFS 要求を受け付けるメンバがいるクラスタ別名を定義するファイルです (1 行に 1 つずつ定義します)。省略時の設定では,省略時のクラスタ別名だけが NFS の要求を受け付けることができます。NFS サーバとして他の別名を追加指定する場合は,/etc/exports.aliases
ファイルを使用します。
/etc/gated.conf.membern
省略時の設定では,クラスタの各メンバのクラスタ別名デーモン (aliasd
) は,メンバ固有の
/etc/gated.conf.membern
ファイルを作成します。このデーモンはその後
gated
を起動するとき,gated
の構成ファイルとしてこのファイルを使用します。メンバの構成ファイル
/etc/gated.conf
は使用しません。
cluamgr -r stop
を使ってクラスタのメンバによるクラスタ別名へのルーティングを停止した場合,クラスタ別名デーモンは
gated
を再起動するとき,gated
の構成ファイルとしてそのメンバの
gated.conf
を使用します。
クラスタでどのようにクラスタ別名を構成するかを設計するときには,次の事項を検討します。
クラスタがクライアント (たとえばメール・ハブ,アプリケーション・サーバ,NFS サーバなど) にどのようなサービスを提供するか。
クライアントからの要求に効果的に応答するには何個のクラスタ別名が必要か。
省略時のクラスタ別名のみで十分な場合もあります。しばらくの間,省略時のクラスタ別名のみを使用してみて,その後,自分の構成にとってクラスタ別名を追加する必要があるかどうかを決定します。
/etc/services
内に列挙されている一般的なインターネット・サービスがクラスタにある場合は,省略時のクラスタ別名で十分です。
省略時の設定では,クラスタがネットワーク・ファイル・システム (NFS) サーバとして設定されている場合,外部クライアントはクラスタによってエクスポートされたファイル・システムをマウントするときに,省略時のクラスタ別名を NFS サーバ名として使用しなければなりません。ただし,クラスタ別名を新しく作成してそれを NFS サーバとして使用することもできます。この機能は,本書の
3.15 節,『クラスタ概要』,および
exports.aliases
(4)
クラスタが多くのシステム・リソースを使用するサードパーティのアプリケーションを実行している場合は,そのアプリケーションに対するアクセス制御と負荷分散を行うために,クラスタ別名の追加が必要になります。
Web サーバとして使用されるクラスタで,2 つのクラスタ別名を使ってアクセス制御と冗長構成を実現する例を,3.10 節に示しています。
クラスタの外部ネットワーク・トポロジに基づいてルーティングのストラテジを決定する。使用可能なルーティング・デーモン・オプションについては,3.14 節で説明。
クラスタのどのメンバがどのクラスタ別名に属するか。
作成する別名に一部のクラスタ・メンバが参加しない場合に,その別名を経由してアクセスすると,その別名の少なくとも 1 つのメンバから対応するサービスを受けられることを確認してください。 次に例を挙げます。
別名を作成して NFS サーバとして使用する場合,そのメンバがすべて,エクスポートされるファイル・システムのあるストレージに直接接続されていることを確認してください。
CAAで制御するアプリケーションにクラスタ別名を経由してアクセスさせる場合,CAA の配置ポリシが,そのクラスタ別名のメンバではないクラスタ・メンバでサービスを開始しないようになっていることを確認してください。
各メンバは自分が指定するか参加する各クラスタ別名にどの別名属性を割り当てるか。
最初は属性の省略時の設定を使用して (rpri=1,selw=1,selp=1
),後から属性を変更することもできます。
サービス属性を追加する場合は,/etc/clua_services
内のインターネット・サービスのエントリにどの属性を関連付けるか (このファイルは,インターネット・サービスのストック・セットに対する省略時の別名ポート設定を提供する)。
クラスタ別名の IP アドレスは,既存の共通サブネット上に存在するか,仮想サブネット上に存在するか,あるいはその両方に存在するか。
共通サブネット上に存在する場合 : クラスタが接続されている既存のサブネットからクラスタ別名の IP アドレスを選択します。
注意
共通サブネット内のクラスタ別名に対してはプロキシ・アドレス解決プロトコル (ARP) が使用されるので,ローカル・エリア・ネットワーク (LAN) でプロキシ ARP をブロックするルータまたはスイッチが使用されている場合,そのクラスタ別名はローカル以外のセグメントからは見えません。したがって,共通サブネットの構成では,クラスタ別名のクライアントを接続するルータまたはスイッチの構成で,プロキシ ARP のブロックを有効にしてはなりません。
仮想サブネット上に存在する場合 : 仮想サブネット内のクラスタ別名のホスト・ルートは,クラスタ別名ソフトウェアによって自動的に構成されます。クラスタ・メンバは,メンバの指定または参加に際して
virtual
属性を追加する場合,その仮想サブネットへ至るネットワーク・ルートも公開します。
注意
nogated
オプションを指定すると,仮想サブネット上に存在する別名へのルートは公開されません。クライアント・システムが静的ルートをこの別名に対して構成していなければ,この別名は到達可能とはなりません。
サブネットの種類を選択するときは主に,既存のサブネット (つまり共通サブネット) 上にクラスタ別名に使用できる IP アドレスが十分にあるかどうかを検討します。既存のサブネット上にすぐに使用できる IP アドレス がない場合は,仮想サブネットの作成を考慮するとよいでしょう。ただし,クラスタが複数のサブネットに接続されている場合に,仮想サブネットを作成すると,クラスタに接続されているすべてのサブネットから同じアドレスを使ってその仮想サブネットへ到達できるようになる,という利点については,あまり考慮する必要がありません。この利点は,実質よりもスタイルの問題です。クラスタ別名用の IP アドレスを確保するためにはどちらの種類のサブネットを使用しても,実質的に大きな違いはありません。サイトで最適な方法を選択してください。
cluamgr
コマンドを使用して,クラスタ別名の指定およびクラスタ別名へ参加する前に,次の手順を実行します。
各クラスタ別名については,サイトが使用する hosts テーブル (たとえば
/etc/hosts
,BIND (Berkeley Internet Name Domain),または NIS (Network Information Service)) でクラスタ別名の IP アドレスがホスト名に関連付けられていることを確認します。
注意
クラスタからのパスワード保護なしのログインとリモート・シェルを許可するようにクライアント上の
.rhosts
ファイルを修正する場合は,クラスタの各メンバのホスト名ではなく省略時のクラスタ別名を,ホスト名として使用します。これによってクラスタからのログイン要求では,送信元アドレスとして省略時のクラスタ別名が使用されます。
クラスタ別名の IP アドレスが仮想サブネット上に存在する場合,ローカルのルータには該当するサブネットを登録します (仮想サブネット内には実際のシステムを置くことができないことに注意してください)。
クライアントからの NFS 要求に応答するために,省略時のクラスタ別名以外に別名が必要な場合は,その名前を/etc/exports.aliases
に追加します。
固定ポートが割り当てられたサービスについては,/etc/clua_services
内でそのインターネット・サービスのエントリを調べます。新しい別名でアクセスされる追加のサービスがあれば,/etc/clua_services
にそのサービスのエントリを追加します。
cluamgr
コマンドは,クラスタ別名の指定,参加,および管理用のコマンド行インタフェースです。クラスタのメンバ上でクラスタ別名を指定すると,そのメンバはクラスタ別名を認識し,その別名へのルートを公開できるようになります。クラスタのメンバ上でクラスタ別名への参加を指定すると,そのメンバはそのその別名宛の接続要求またはパケットの受信ができるようになります。
クラスタ別名属性すべてに省略時の値を使用するクラスタ別名を指定するには (しかし,参加はしない),次のコマンドを使用するのが最も簡単です。
# cluamgr -a alias=alias
このクラスタ・メンバで
cluamgr -r start
コマンドを使用して別名ルーティングを再起動すると,システムはその別名へのルートを公開して,ネットワークからパケットを取得し,それらを別名に参加している別名のメンバに転送することができます。このメンバで
cluamgr -s
alias
コマンドを実行すると,この別名に対して
<ENABLED>
という状態が表示されます。
すべての属性に省略時の値を使用するクラスタ別名を指定し,同時にその別名への参加を指定するには,次のコマンドを使用するのが最も簡単です。
# cluamgr -a alias=alias,join
このクラスタ・メンバで
cluamgr -r start
コマンドを使用して別名ルーティングを再起動すると,システムは別名へのルートを公開して,ネットワークからパケットを取得し,それらを別名に参加している別名のメンバに転送し,その別名宛ての接続要求またはパケットを受信できます。このメンバで
cluamgr -s
alias
コマンドを実行すると,この別名の
<JOINED,ENABLED>
という状態が表示されます。
クラスタ別名を指定する場合とクラスタ別名に参加する場合は,次の手順を実行します。
別名のホスト名と IP アドレスを取得します。
SysMan Menu を使ってクラスタ別名を追加します。クラスタ別名属性に省略時の値を使用しないときは,適切な値に変更します。たとえば,selp
または
selw
の値を変更します。
SysMan Menu は,メンバの
clu_alias.config
ファイルにコマンド行を書き込むだけです。メンバの
clu_alias.config
ファイルに別名を書き込むだけなので,その別名はすぐには有効とならず,次のブート後に初めて有効となります。
次の例は,クラスタの 1 つのメンバの
clu_alias.config
ファイルにある
cluamgr
コマンド行を示したものです。別名の IP アドレスはすべて共通サブネット内にあります。
/usr/sbin/cluamgr -a alias=DEFAULTALIAS,rpri=1,selw=3,selp=1,join /usr/sbin/cluamgr -a alias=clua_ftp,join,selw=1,selp=1,rpri=1,virtual=f /usr/sbin/cluamgr -a alias=printall,selw=1,selp=1,rpri=1,virtual=f
メンバ上で該当する
cluamgr
コマンドを手動で実行して,別名を指定するかまたは別名に参加した後,別名ルーティングを再起動します。たとえば,次のように実行します。
# cluamgr -a alias=clua_ftp,join,selw=1,selp=1,rpri=1 # cluamgr -a alias=printall,selw=1,selp=1,rpri=1 # cluamgr -r start
上記の例では,virtual
属性の省略値が
f
であるため,2つの別名に対して
virtual=f
を明示的には指定していません。cluamgr -r start
コマンドはカーネル・ルーティング情報を更新して,このメンバ上のクラスタ別名サブシステムが新しい別名に対してルーティングできるようにします。
前述したように,別名へ参加する場合に別名属性として省略値を使用するときは,次のコマンドで十分です。
# cluamgr -a alias=alias_name,join
次の例は,仮想ネットワーク内でクラスタ別名の指定および別名へ参加する方法を示しています。この構成方法は,共通サブネット内のクラスタ別名の構成方法とほとんど同じです。
# cluamgr -a alias=virtestalias,join,virtual,mask=255.255.255.0
この
cluamgr
コマンドを構成する要素は次のとおりです。
cluamgr -a alias=virtestalias
別名の指定。cluamgr -r start
コマンドを実行後,クラスタ・メンバが別名へのホスト・ルートの公開を開始する。
join
別名に参加。メンバは別名宛のパッケットを受信できる。
virtual
virtestalias
アドレスが属する仮想ネットワークへのネットワーク・ルートを公開する。
mask=255.255.255.0
サブネット・マスクを明示的に定義する。サブネット・マスクを指定しない場合,このメンバの別名デーモンは,仮想サブネットが公開されるこのシステムの最初のインタフェースのネットワーク・マスクを使用する。
クラスタのメンバが仮想サブネットのネットワーク・ルートを公開しないようにする場合には,仮想サブネット内の別名に対して
virtual
または
virtual=t
を指定しないでください。たとえば,あるクラスタ・メンバで次のコマンドを実行すると,そのクラスタ・メンバは
virtestalias
別名を指定し参加しますが,ネットワーク・ルートは公開しません。
# cluamgr -a alias=virtestalias,join
仮想サブネット内の別名の構成についての詳細は,
cluamgr
(8)3.6 クラスタ別名属性とサービス・ポート属性の変更
クラスタ別名属性を変更するために,クラスタの任意のメンバ上で
cluamgr
コマンドをいつでも実行できます。たとえば,クラスタ別名
clua_ftp
のメンバに対してその別名の選択重みを変更するには,そのメンバで次のコマンドを入力します。
# cluamgr -a alias=clua_ftp,selw=2
この変更がリブート後も有効であるようにするには,このメンバの
clu_alias.config
ファイルでこの別名のエントリを変更します。
クラスタ単位の
/etc/clua_services
に登録されているインターネット・サービスに関連付けられているサービス・ポート属性を変更するには,次の手順を実行します。
clua_services
(4)/etc/clua_services
内のエントリを変更します。
このファイルを
cluamgr
に再度読み取らすために,クラスタの各メンバ上で次のコマンドを入力します。
# cluamgr -f
注意
clua_services
ファイルを再度読み込んでも,現在実行中のサービスには影響しません。構成ファイルを再度読み込んだ後,サービスを停止して再起動する必要があります。たとえば,
telnet
サービスは/etc/inetd.conf
からinetd
が起動します。clua_services
にあるtelnet
のサービス属性を変更した場合は,cluamgr -f
を実行してから,inetd
を停止した後再起動して変更が有効になるようにしなければなりません。そうしなければ,次にリブートするまで変更が有効になりません。
このクラスタ・メンバが認識しているクラスタ別名の状態を表示するには,たとえば次にように
cluamgr -s all
コマンドを使用します。
# cluamgr -s all Status of Cluster Alias: deli.zk3.dec.com netmask: 0 aliasid: 1 flags: 7<ENABLED,DEFAULT,IP_V4> connections rcvd from net: 72 connections forwarded: 14 connections rcvd within cluster: 52 data packets received from network: 4083 data packets forwarded within cluster: 2439 datagrams received from network: 28 datagrams forwarded within cluster: 0 datagrams received within cluster: 28 fragments received from network: 0 fragments forwarded within cluster: 0 fragments received within cluster: 0 Member Attributes: memberid: 1, selw=3, selp=1, rpri=1 flags=11<JOINED,ENABLED> memberid: 2, selw=2, selp=1, rpri=1 flags=11<JOINED,ENABLED>
注意
netstat -i
を実行してもクラスタ別名は表示されません。
共通サブネット内のクラスタ別名の場合,各メンバ上で
arp -a
を実行して,どのメンバがクラスタ別名へのルーティングを行うかをチェックできます。たとえば,クラスタ別名と
permanent published
を検索するには,次のように実行します。
# arp -a | grep permanent deli (16.140.112.209) at 00-00-f8-24-a9-30 permanent published
参加先のクラスタ別名からクラスタ・メンバを削除するには,そのメンバ上で次のコマンドを入力します。
# cluamgr -a alias=alias,leave
ただし,別名へのルートを公開するように構成されているメンバは,削除された後もこの別名へのルートを公開できますが,この別名宛の接続要求とパケットは受信できなくなります。ただし,クラスタ別名が構成されると,クラスタは,その別名の最後のメンバが別名から削除された後でも,その別名宛てのパケットを拒否しません。クラスタ別名の削除についての詳細は,
3.9 節を参照してください。
3.9 クラスタ別名の削除
メンバの別名のカーネル・リストからクラスタ別名を削除する
cluamgr
コマンドはありません。その別名を認識しているすべてのクラスタ・メンバが別名から削除されても (cluamgr -a alias=alias,leave
),クラスタは引き続きその別名宛ての接続要求を受け付けます。
クラスタ・メンバが有効にされるか (cluamgr -a alias=alias
) または参加して (cluamgr -a alias=alias,join
),別名のルーティングが再起動される (cluamgr -r start
) と,aliasd
はその別名のエントリをメンバの
gated.conf.membern
ファイルに追加し,別名はそのメンバの別名のカーネル・リストに追加されます。
クラスタ・メンバがブートすると,カーネルはそのメンバの
/etc/clu_alias.config
ファイル内の情報からクラスタ別名のリストを構築します。aliasd
デーモンは,clu_alias.config
ファイルからではなく,カーネル内の別名リストからその情報を取得します。したがって,ファイルから別名エントリを削除して,別名デーモンを再起動するか,または別名ルーティングを再起動しても,別名は削除されません。
クラスタ別名を削除するには,次の手順に従います。
注意
省略時のクラスタ別名を削除することはできません。クラスタの名前を変更する必要がある場合には,本書で説明されている手順を使用します。
/etc/hosts
ファイルからクラスタ別名のエントリを削除します (技術的には必要ありませんが,エントリを削除またはコメント・アウトすると管理上わかりやすくなります)。
各クラスタ・メンバで,cluamgr -s
alias
コマンドを実行して,この別名を認識しているクラスタ・メンバを判断します。
この別名を認識している各クラスタ・メンバで,そのメンバの
/etc/clu_alias.config
ファイルからその別名に関連するエントリをすべて削除します (エントリを削除しておくと,システムのリブート時にその別名が確実に再構成されなくなります)。
1 度に 1 つづつ,削除する別名のメンバだった各クラスタ・メンバをリブートします。その別名を認識していたすべてのクラスタ・メンバがリブートされると,別名は削除されます。
この節では,クラスタ別名のメンバ間でのアプリケーションの負荷分散について説明します。ネットワーク・インタフェースの負荷分散に役立つルーティング・デーモン構成オプションについての情報は,3.14 節を参照してください。
注意
負荷分散の概念は,
/etc/clua_services
ファイル内でin_multi
サービス属性が割り当てられているサービスのみに適用されます。クラスタ別名サブシステムは,そのサービスがin_multi
として明示的に定義されていない限り,in_single
サービスとして扱います。in_single
サービスに対するパケットと要求はすべて別名のメンバへ送られますが,同時に 2 つ以上の別名メンバへ送られることはありません。
クラスタ別名サブシステムは,クラスタの各メンバの性能を監視せず,in_multi
のサービスの負荷分散も自動的に行いません。接続要求の分配を制御するには,クラスタ別名の各メンバに選択優先順位と選択重みを割り当てます。これらの属性の値はいつでも手作業で修正できます。
選択優先順位属性
selp=
n
は,別名のメンバが新しい接続要求を受信する順番を決定します。n
の値は 1 以上 100 以下の整数でなければなりません。別名の選択優先順位を使用することで,別名内に階層を作成することができます。
たとえば,4 つのクラスタ・メンバがクラスタ別名に参加していて,別名に対し
selp
を次の値に設定しているとします。
メンバ A および B は
selp=5
メンバ C および D は
selp=4
selp=5
のメンバのだれかが要求に応答できれば,要求が
selp=4
のメンバに送られることはありません。つまり,メンバ A または B が要求を処理できる場合,C と D がこの別名に宛てられたパケットや要求を受信することはありません。
この例では,選択優先順位を使用して,クラスタ別名のメンバ間にフェイルオーバの階層が作成されます。このタイプの階層を作成する 1 つの理由は,メンバ A と B が,クライアントがこのクラスタ別名でアクセスするストレージに直接接続されているためです。したがって,A と B にこの別名宛てのクライアント要求をサービスさせます。ほとんどの場合,C と D はクライアント要求を受信しませんが,A と B のどちらも応答できない場合には,引き受けることができます。
メンバがクラスタ別名に割り当てる選択重み
selw=n
は,そのメンバに送信される要求の平均数 (アプリケーション単位) に変換されます。変換された後,要求は同じ選択優先順位の次の別名メンバに送信されます。n
の値は,1 以上 100 以下の整数でなければなりません (selp
の値は,要求またはメッセージの受信に適したメンバの順番を決定し,selw
の値は,適切なメンバになったのち,そのメンバが受信する要求またはメッセージの数を決定します)。
たとえば,1 つのクラスタ別名に 4 つのクラスタ・メンバが参加しているものとします。4 つのクラスタ・メンバすべてが別名に対して同じ
selp
値を持ち,selw
を次の値に設定しているとします。
メンバ A および B は
selw=3
メンバ C および D は
selw=2
別名のすべてのメンバが同じ選択優先順位を持っているので,ラウンド・ロビン・アルゴリズムに従ってメンバ・リスト内からこれらのメンバが選択され,selw
に従って各メンバに順番に要求が分配されます (クラスタ別名サブシステムは,どのサービス・ポートで別名のどのクラスタ・メンバが待機しているかを追跡し,接続要求およびパケットを分散する方法を決める際にこの情報を使用します)。特定のサービス (たとえば,telnet
) に対してこの別名に宛てられたクライアント要求について,メンバ A は 3 つの要求を受信し,メンバ B は 3 つの要求を受信し,メンバ C は 2 つの要求を受信する,という具合に続きます。
クラスタ別名のメンバに選択重みを割り当てるときは,クラスタ別名経由でアクセスされるアプリケーションのリソースに最もよく一致するリソースを持つメンバに,他のメンバよりも高い選択重みを割り当てます。
注意
省略時のクラスタ別名は
selw
として3
を持っています。たとえば,Secure Shell (SSH) を使用するようないくつかのアプリケーションは,単一の接続を確立するために 2 つの接続を使用します。このため,SSH を使用する省略時のクラスタ別名への接続要求は,あるシステムは 2 つの接続を取得し,別のシステムは 1 つの接続を取得するように分散されますが,実際のところ,分散の不均衡はありません。接続要求は各クラスタ・メンバに割り当てられた選択重みに従って分散されています。省略時のクラスタ・メンバ間で SSH を分散させるように接続するためには,省略時のクラスタ別名のすべてのクラスタ・メンバで
selw
を任意の偶数に設定します。この変更を永続的なものにするため,次の行を各メンバの/etc/clu_alias.config
ファイルに追加します。/usr/sbin/cluamgr -a selw=4,selp=1,join,alias=DEFAULTALIAS
シェル・スクリプトに精通している管理者であれば,スクリプトを記述して,クラスタ・メンバの性能の監視と,その情報に基づく選択重みの増減を自動化することもできます。この場合の性能は,監視対象のメンバ上のアプリケーションに関連する要素すべてによって決まります。
今度は,次のような状況を仮定します。管理者は,ファイルのアーカイブ保存を主目的とする Web サイトとして,4 メンバ構成のクラスタを構成します。ユーザは,このサイトに接続し,大きなサイズのファイルをダウンロードします。クラスタは,共通ネットワークに接続されている 4 つのメンバで構成されます。クラスタ内では,メンバ A および B が 1 つのディスク・セットを共用し,メンバ C および D が別のディスク・セットを共用します。メンバ A および B のネットワーク・インタフェースは,大容量データ転送 (たとえば
ftp
転送) 用に調整されています。メンバ C および D のネットワーク・インタフェースは,短いタイムアウトと待ち時間 (たとえば Web からの接続) 用に調整されています。
この状況で,clua_ftp
と
clua_http
という 2 つのクラスタ別名を定義します。クラスタの 4 つのメンバはすべて両方のクラスタ別名に参加しますが,値は異なっています。
メンバ A および B の
/etc/clu_alias.config
ファイル内に次のような行があります。
/usr/sbin/cluamgr -a alias=clu_ftp,selw=1,selp=10,join /usr/sbin/cluamgr -a alias=clu_http,selw=1,selp=5,join
メンバ C および D の
/etc/clu_alias.config
ファイル内に次のような行があります。
/usr/sbin/cluamgr -a alias=clu_ftp,selw=1,selp=5,join /usr/sbin/cluamgr -a alias=clu_http,selw=1,selp=10,join
その結果,少なくともメンバ A と B の一方が稼働していれば,その稼働中のメンバがすべての
ftp
要求に応答します。同様に,少なくともメンバ C と D の一方が稼働していれば,その稼働中のメンバがすべての
http
要求に応答します。ただし,4 つのメンバすべてが両方のクラスタ別名に属しているので,どちらかの別名で 2 つの一次サーバがダウンしても,残りの別名メンバがクライアントからの要求に応答します (クォーラムが維持されていることが前提です)。
3.11 クラスタ単位のポート・スペースの拡張
サービス用にクラスタ全体で使用可能な一時 (動的) ポートの数は,サブシステム属性
inet
,ipport_userreserved_min
(省略時の値は 1024),および
ipport_userreserved
(省略時の値は 5000) によって決まります。
ポート・スペースがクラスタのすべてのメンバ間で共用されるので,複数のメンバが属しているクラスタでは,使用可能なポートの競合が起こる可能性があります。クラスタに 3 つ以上のメンバがある場合は,ipport_userreserved
に最大許容値 (65535) を設定することをお勧めします (ipport_userreserved = 65535
にしても何ら悪影響はありません)。
ipport_userreserved
に最大値を設定するには,次の手順に従います。
クラスタの任意のメンバ上で,クラスタ単位の
/etc/sysconfigtab.cluster
ファイルに次の行を追加して,次のリブートで
ipport_userreserved
が 65535 に設定されるように構成します。
inet: ipport_userreserved=65535
クラスタの各メンバ上で
sysconfig
を実行して,ipport_userreserved
の現在の値を変更します。
# sysconfig -r inet ipport_userreserved=65535
vMAC サポートを有効にすると,クラスタの 1 つのメンバがクラスタ別名のプロキシ ARP マスタになり,クラスタ別名の vMAC アドレスを生成します。vMAC アドレスは,接頭部 (省略時は
AA:01
) と 16 進形式のクラスタ別名の IP アドレスから構成されます。たとえば,クラスタ別名の IP アドレスが 16.140.112.209 であるとすると,省略時の vMAC アドレスは AA:01:10:8C:70:D1: になります。
省略時の vMAC 接頭部: AA:01 クラスタ別名 IP アドレス: 16.140.112.209 IP アドレス (16 進形式): 10.8C.70.D1 このアドレスの vMAC: AA:01:10:8C:70:D1
クラスタの別のメンバがこのクラスタ別名のプロキシ ARP マスタになると,vMAC アドレスはクラスタ別名とともに移動されるので,一貫した vMAC アドレスが各クラスタ別名の共通サブネット内に通知されます。
vMAC サポートを構成するときは,クラスタのすべてのメンバを同じ構成にします。この理由から,/etc/rc.config.common
内の vMAC 構成変数を設定する必要があります。
省略時の設定では,vMAC サポートは無効に設定されています。vMAC サポートを有効にするには,rcmgr
を使って
/etc/rc.config.common
に適切なエントリを追加します。
# rcmgr -c set VMAC_ENABLED yes
反対に vMAC サポートを無効にするには,次のように入力します。
# rcmgr -c set VMAC_ENABLED no
vMAC アドレスの省略時の接頭部 AA:01 を変更するには,次のように入力します。
# rcmgr -c set VMAC_PREFIX xx:xx
各クラスタ・メンバの vMAC サポートを手動で有効にするには
cluamgr
のルーティング・オプション
vmac
を使用し,無効にするには
novmac
を使用します。たとえば,クラスタ・メンバで vMAC サポートを手動で有効にするには,次のように入力します。
# cluamgr -r vmac
各クラスタ・メンバで vMAC サポートを手動で無効にするには,次のように入力します。
# cluamgr -r novmac
クラスタのすべてのメンバの vMAC の構成は同一にする必要があるので,vMAC サポートを有効にするときは,次の手順の実行をお勧めします。
クラスタの任意のメンバ上で,次のように入力します。
# rcmgr -c set VMAC_ENABLED yes
これにより,ブート時に vMAC サポートが自動的に有効になります。ただし,この変数の設定はメンバがリブートするときにのみ影響を与えるため,現在実行中のクラスタでは vMAC は有効になりません。
現在実行中のクラスタで vMAC サポートを手動で有効にするには,各クラスタのメンバで次のコマンドを入力します。
# cluamgr -r vmac
各クラスタ・メンバの
/etc/clu_alias.config
ファイルに
cluamgr -r vmac
コマンドを追加する必要はありません。各メンバ上で
cluamgr -r vmac
コマンドを手動で実行すると,vMAC サポートが有効になります。共用の
/etc/rc.config.common
ファイルで
VMAC_ENABLED
を
yes
に設定すると,すべてのクラスタ・メンバで,ブート時に vMAC のサポートが自動的に有効になります。
クラスタ・メンバが,alt ドライバ・バージョンが V2.07 より小さい DEGPA のギガビット・イーサネットのアダプタを使用して外部のネットワークに接続され,vMAC が有効である場合には,ネットワークのインタフェースが promiscuous モード (promisc
) に設定されていないと,メンバはクラスタの別名宛の外部からのパケットに応答しません (alt ドライバが V2.07 以降の DEGPA アダプタは,vMAC アドレスが構成されると,自動的に promiscuous モードを有効にします)。
次のコマンドを使って promiscuous モードを設定します。
# ifconfig alt0 promisc
ブート時にすべての DEGPA アダプタに対して promiscuous モードを自動的に有効にするには,各メンバの
/etc/inet.local
ファイルに次の行を追加します。
for i in `/usr/sbin/ifconfig -l` ; do case $i in alt*) ifconfig $i promisc ;; esac done
『クラスタ概要』では VMAC の概要を説明しています。
3.13 ルーティング構成のガイドライン
クラスタ別名操作を行う場合は,クラスタに接続されたすべてのサブネットに,機能するルータが含まれている必要があります。この条件が満たされていれば,手動でルーティングの構成を行わなくてもクラスタ別名で接続できます。接続されているサブネットにルータがない場合は,一部手動でルーティングの構成を行う必要があります。この理由は,クラスタ・メンバ上のクラスタ別名デーモンでは,考えられるすべてのルーティング・トポロジに対する正しい経路の特定や検証を行うことができないためです。
クラスタに接続されているサブネット内のルータを構成できない場合,たとえば,1 つのクラスタ・メンバが,非ルータしか含まれていない独立した LAN に接続されている場合は,そのサブネットに接続されていない各クラスタ・メンバ上で,そのサブネットへのネットワーク経路を手動で構成しなければなりません。ルータのないサブネットに接続されているメンバごとに,該当するサブネットへのネットワーク経路をそのメンバのクラスタ・インターコネクト・インタフェースに追加してください。
注意
同じ LAN 上にあるクラスタであれば,同じ仮想サブネットを使用できます。
このようにできるのは,同じ LAN 上にあるルータであれば,どのルータでもクラスタ別名ごとにその個別ホスト・ルートを認識して正しいクラスタへパケットを送信できるからです。LAN の外に対しては,公開されているネットワーク・ルートを用いて仮想サブネットを公開するので,その仮想サブネット内のクラスタ別名アドレスへ宛てたパケットは,その LAN のルータに送られます。要約すると,(1) ホスト・ルートが生成され,(2) クラスタが同じ LAN を共有していれば,各クラスタに対して別々の仮想サブネットを使用する必要はない,ということです。
ただし,クラスタがマルチホームの場合は,複数のクラスタに対して同じ仮想サブネットを使用する方が複雑です。たとえば,2 つのクラスタがあって,一方が LAN1 と LAN2 に,また,もう一方が LAN 1 と LAN 3 にそれぞれ接続されている場合,両方のクラスタに同じ仮想サブネットを使用すると,LAN 2 と LAN 3 に送られてくるパケットに対してうまく動作しません。マルチホームの場合は,LAN へ同じように接続している必要があります。
3.14 ルーティング・デーモンと静的ルーティングのオプション
バージョン 5.1B より前には,クラスタ別名サブシステムが
routed
や,静的ルートと効果的に共存していなかったので,クラスタ別名ルーティングを正しく処理するために,ルーティング・デーモンとして
gated
を使用する必要がありました。このリリースでは,正しく動作するために
gated
を必要としない
aliasd
デーモンが提供されます。
サポートされているルーティング・デーモンを以下で説明します。
gated
と
routed
ルーティング・デーモンがクラスタでサポートされています。また,静的ルーティングがサポートされています (ルーティング・デーモンを必要としません)。
aliasd
は
gated
用に最適化されているので,gated
が省略時の優先ルーティング・デーモンです。ただし,必ず必要ではなく,クラスタ・メンバでルーティングを構成する唯一の方法でもありません。例として,すべてのメンバが静的ルーティングを使用するクラスタを構成することも,あるメンバだけに
routed
を実行させることも,ルーティング・デーモンと静的ルーティングの組み合わせを使用することもできます。
ただし,ogated
の使用に関する既存の制限は,引き続き適用されます。クラスタで
ogated
をルーティング・デーモンとして使用しないでください。
注意
クラスタ・メンバは,同一のルーティング構成を持つ必要はありません。一般的には,すべてのクラスタ・メンバを同一に構成する方がより簡便ですが,経験を積んだクラスタの管理者であれば,メンバごとに別のルーティング・タスクを実行させるような構成を選んでもよい場合もあります。たとえば,メンバの
/etc/rc.config
ファイル内にCLUAMGR_ROUTE_ARGS="nogated"
と指定したり,完全に関連付けられた/etc/routes
ファイルを使うこともできます。または,メンバがnogated
とrouted -q
を使って動作することもできます。
別名デーモンは動的ルーティングか静的ルーティングのどちらかで,クラスタ・インターコネクトを介してクラスタ別名の IP アドレスをフェイルオーバします。たとえば,インタフェースが障害になった場合,aliasd
は,クラスタの別のメンバに別名のトラフィックを再ルーティングします。クラスタ・インターコネクトが機能している限り,クラスタ別名トラフィックは発着信できます。
サブネット単位の複数インタフェース (ネットワーク負荷分散)。
gated
では,この構成がサポートされませんが,静的ルーティングがサポートされているので,管理者はネットワークの負荷分散のために静的ルーティング (nogated
) を使えます。
省略時では,クラスタ別名サブシステムは
gated
とカスタマイズ
gated
構成ファイル (/etc/gated.conf.member<n>
) を使い,さらに別名アドレスのホスト・ルートを公開するために RIP を使います。この動作を無効にするには,cluamgr
の
nogated
オプションを使い,メンバ上で
cluamgr -r nogated
コマンドを実行するか,メンバの
/etc/rc.config
ファイルで
CLUAMGR_ROUTE_ARGS="nogated"
を設定します。
クラスタにとって,3 つの一般的なルーティング構成のシナリオがあります。
省略時の構成 :
aliasd
が
gated
を制御する動的ルーティング。
各メンバの
/etc/rc.config
ファイルに次の内容を設定する。
GATED="yes"
CLUAMGR_ROUTE_ARGS
がメンバの
/etc/rc.config
ファイルにある場合には,それをコメント・アウトするか,またはヌル文字に設定します。
必要であれば,静的ルートをそのメンバの
/etc/routes
ファイルに定義する。
注意
/etc/routes
ファイルの静的ルートのインストールは,ルーティング・デーモンを開始する前に行い,ルーティング・デーモンによって管理されます。
この構成では,aliasd
は
gated
のオペレーションを制御します。ホスト・ルートは RIP を経由して伝播され,aliasd
は,ネットワーク・インタフェース・カード (NIC) の障害のために孤立したノードの代わりに,gated
にクラスタから外に向かうパスを習得させることができます。aliasd
デーモンは,gated
を停止して再起動することができ,gated
からの干渉なしでルーティング・テーブルを変更することができます。
動的ルーティング (gated
および
aliasd
が独立して動作する)。
クラスタ別名サブシステムと
aliasd
はメンバの
gated
の実行とは依存関係はありません。管理者は
gated
と各メンバの
gated
構成ファイル
/etc/gated.conf
を総合的に管理します。IP 転送を可能にし,クラスタ・メンバを本格的なルータとして構成したい管理者にとってこの方法は有益です。
このポリシに従うメンバでは
/etc/rc.config
ファイルに次の内容を設定する。
GATED="yes" CLUAMGR_ROUTE_ARGS="nogated" ROUTER="yes" # if this member will be a full-fledged router
必要であれば,静的ルートをそのメンバの
/etc/routes
に設定する。
このシナリオでは,aliasd
は
gated
を使用してホスト・ルートを伝播することはできず,gated
に,クラスタ・ノードがクラスタから外に向かうパスの習得の手助けをさせることはできません。gated
デーモンは自身のルーティング・テーブルを保持しています。
静的ルーティング (1 つ以上のクラスタ・メンバがルーティング・デーモンを実行しない)。
静的ルーティングを使う各メンバでは
/etc/rc.config
ファイルに次の内容を設定する。
GATED="no" CLUAMGR_ROUTE_ARGS="nogated" ROUTED="no" ROUTED_FLAGS=""
メンバの
/etc/routes
ファイルに静的ルートを定義する。
この構成は,ルーティング・デーモンを実行したくないサイトで便利です。これは,ローカルの管理ポリシで RIP が禁止されていたり,サブネット内で複数の NIC を実行したい場合 (gated
はこれをサポートしない) にあてはまります。少なくとも 1 つの省略時のルートを設定する必要があります。aliasd
はルーティング・テーブルを制御し,NIC に障害が発生した場合に備えて,この省略時のルートを再構成することができます。これができない場合,ノードは孤立してしまいます。
クラスタを NFS サーバとして構成すると,NFS クライアントの出す要求は,省略時のクラスタ別名か,または
/etc/exports.aliases
の中に指定されている別名のいずれかに送信しなければなりません。クラスタ・メンバを個別に指定して NFS のマウント要求を送ると,その要求は拒否されます。
出荷時には,NFS クライアントの使用できる別名が省略時のクラスタ別名のみになるよう構成されていますが,独自のクラスタ別名も追加できます。/etc/exports.aliases
ファイルにクラスタ別名の名前を追加すると,その別名のメンバが NFS 要求を受け付けるようになります。この機能は,クラスタ内の一部のメンバが,エクスポートされたファイル・システムのあるストレージに直接接続していない場合に便利です。そのような場合,直接接続しているシステムのみをメンバとする別名を作成すれば,NFS の要求のサービスに必要な内部ホップの数を削減できます。
『クラスタ概要』で説明されているように,NFS 要求を受け付けて処理する別名のメンバは,エクスポートされているファイル・システムのあるストレージに直接接続していなければなりません。また,その別名のメンバでない他のクラスタ・メンバがこのストレージに直接接続している場合,エクスポートされているファイル・システムの要求をそのシステムが受け付けて処理しないようにする必要があります。このファイル・システムの要求を受け付けて処理できるのは,そのファイル・システムのアクセスに使用する別名のメンバに限られます。この制限に合わせる方法はいくつかありますが,そのひとつは,cfgmgr
を使用してファイル・システムを別名のメンバに手動で再配置するという方法です。また,ブート時に起動するスクリプトを作成して,どのメンバがファイル・システムを受け付けて処理するかを自動的に調べ,そのファイル・システムを必要に応じてその別名メンバへ再配置する,という方法もあります。
『クラスタ概要』の中に,NFS とクラスタ別名サブシステムが NFS に関連する TCP および UDP のトラフィックを処理する方法が説明されているので,NFS
サーバとして使用する別名を追加する前に,その説明も参照してください。また,
exports.aliases
(4)/etc/exports.aliases
ファイルの先頭にあるコメントも参照してください。
3.16 クラスタ別名と CAA (Cluster Application Availability)
ここでは,クラスタ別名サブシステムと CAA (Cluster Application Availability) サブシステムの違いについて簡単に説明します。
2 つのサブシステムには関係がまったくなく,相互に独立しています。CAA サブシステムは,アプリケーションの起動,リソースのモニタ,およびフェイルオーバを扱う,アプリケーション制御ツールです。一方,クラスタ別名サブシステムは,クラスタ別名に宛てられた接続要求およびパケットをルーティングするためのルーティング・ツールです。これらのツールは相互に機能を補い合っています。具体的には,次に説明するように,CAA がアプリケーションの動作場所を決定し,クラスタ別名サブシステムがその場所へ到達する方法を決定します。
CAA サブシステムは,一度に 1 つのクラスタ・メンバ上で動作するアプリケーションを対象に機能するよう設計されています。CAA サブシステムを使用すれば,必要なリソースをアプリケーションに関連付けておくことで,リソースを使用可能にしてからそのアプリケーションを起動するようにできます。また,アプリケーションを別のクラスタ・メンバ上にフェイルオーバし,そのメンバ上でそのアプリケーションを自動的に再起動させることもできます。
クラスタ別名サブシステムは受信した接続要求およびパケットをクラスタ内の複数のメンバに分配できるので,アプリケーションをクラスタ内の複数のメンバで動作させる場合に非常に有用です。このサブシステムは,クラスタ別名へ至るルートを公開し,その別名のメンバに接続要求とパケットを送信します。
混乱しやすいのが,シングル・インスタンス・アプリケーションという用語です。CAA サブシステムでは,この用語は,一度に 1 つのクラスタ・メンバ上でのみ動作するアプリケーションを意味します。しかし,クラスタ別名サブシステムでは,アプリケーションが
in_single
と指定されていると,そのアプリケーションに対応したポート上で受信待ちしているクラスタ別名のメンバの数に関係なく,そのアプリケーションの 1 つのインスタンスにのみ接続要求とパケットが送信されます。つまり,クラスタ別名サブシステムは,アプリケーションがクラスタのすべてのメンバ上で動作しているか 1 つのメンバ上で動作しているかに関係なく,ポート上で受信待機中のクラスタ別名のメンバから任意に 1 つのメンバを選択して,そのメンバにすべての要求を送信します。そのメンバが応答できなくなると,クラスタ別名サブシステムは残りのメンバの 1 つに要求を送信します。
サービスを
in_single
にするか
in_multi
にするかは,/etc/clua_services
で指定できます。/etc/clua_services
に登録して CAA サブシステムに制御させるサービスに対しては,通常,in_single
を指定する必要があります。ただし,そのサービスに対して
in_multi
を指定しても,次の理由から,そのサービスは正常に動作します。
CAA サブシステムの制御するアプリケーションは同時にはただ 1 つのクラスタ・メンバ上でしか動作しない。したがって,ポート上で動作状態になるリスナは 1 つのみである。
要求またはパケットが到着したとき,クラスタ別名サブシステムがクラスタ別名のメンバをすべてチェックするが,リスナになっているメンバが 1 つだけなので,すべての要求とパケットがそのメンバに送信される。
リスナが応答できなくなると,クラスタ別名サブシステムは別のリスナを見つけられないので,CAA デーモンが別のメンバ上でアプリケーションを起動するまで,すべてのパケットを廃棄するか,エラーを返す。別のメンバがリスナになると,クラスタ別名サブシステムは,その新しいポートにすべてのパケットを送信する。
省略時のクラスタ別名にはクラスタのすべてのメンバが属しています。これとは別に,クラスタの中から一部のメンバを集めて,任意のクラスタ別名を作成することができます。また,アプリケーションを起動または再起動するときに,CAA サブシステムの使用するメンバを制限することもできます (favored または restricted 配置ポリシ)。
クラスタ別名を作成した後,ユーザにこのクラスタ別名経由で CAA 制御下のアプリケーションへアクセスさせる場合は,アプリケーションの CAA 配置ポリシで選択されるメンバとそのクラスタ別名のメンバとが一致していることを確認する必要があります。一致していないと,そのクラスタ別名に属さないメンバ上でアプリケーションが起動されることがあります。この状況では,アプリケーションがクラスタ・メンバ上で実行されているにもかかわらず,クラスタ別名サブシステムはそのクラスタ・メンバへパケットを送信できません。
クラスタ別名およびサービス属性と CAA サブシステムとがどのように関わり合うかを,次の 4 つの例を使って示します。
シナリオ 1
この例では,アプリケーションは CAA の制御下にありません。クラスタ別名サブシステムが,どのクラスタ別名にどのクラスタ・メンバが参加しているかを認識しているものとします。今,クライアントから,ターゲットのホスト名としてクラスタ別名を指定したサービス要求が出されたとします。クラスタ別名サブシステムは,次の手順に従って,クラスタ別名の 1 つのメンバに要求を送信します。
要求されたサービスが
clua_services
に登録されている場合は,そこに指定されているポート属性の値を調べる。たとえば
in_multi
と
in_single
のどちらか,または
in_noalias
と
in_nolocal
のどちらかなど。この例では,サービスが
in_multi
として指定されているものとする。
各メンバが別名に割り当てた選択優先順位 (selp
) を調べる。
各メンバが別名に割り当てた選択重み (selw
) を調べる。別名サブシステムは調べた
selp
および
selw
の値を用いて,どの別名メンバにパケットと接続要求を受信する資格があるかを決定する。
その資格のあるメンバが,アプリケーションに対応したポート上で受信待ちをしているかどうかを調べる。
資格のあるメンバが受信を待っていれば,そのメンバに接続要求またはパケットを送信する。
資格のあるメンバが受信を待っていなければ,同じクラスタ別名内で
selp
と
selw
の条件を満たす次の別名メンバを調べる。
シナリオ 2
今度は,アプリケーションが CAA サブシステムに制御されているが,さらに状況を複雑にするために,clua_services
内でアプリケーションが
in_multi
サービスとして誤って指定されているものとします。この場合は次のようになります。
クラスタ別名サブシステムが接続要求またはパケットを受信する。
資格のあるクラスタ別名のメンバのうち,受信を待っているリスナは 1 つだけである (CAA が 1 つのクラスタ・メンバ上でだけアプリケーションを実行させているため)。
こうした状況で,クラスタ別名サブシステムは接続要求またはパケットの送信先が 1 つのメンバのみであると判断し,CAA がアプリケーションを実行しているメンバにその要求またはパケットを送信する (実質的には
in_multi
が無視される)。
シナリオ 3
このシナリオでは,アプリケーションが CAA サブシステムの制御下になく,複数のクラスタ・メンバ上で動作しているものとします。また,このアプリケーションのすべてのインスタンスは,同じ既知のポートにバインドされ,そのポート上で受信を待っているものとします。ただし,このサービスの
clua_services
内のエントリは
in_multi
として指定されていないものとします。この場合,クラスタ別名サブシステムはポートを
in_single
とみなします。この場合は,次のようになります。
クラスタ別名サブシステムが接続要求またはパケットを受信する。
ポートは
in_single
になっている。
クラスタ別名サブシステムは,接続要求またはパケットを受信するために,資格のある別名メンバを任意に 1 つ選択する。
クラスタ別名サブシステムは,そのメンバのダウン,アプリケーションのクラッシュ,またはその他の理由でこのメンバ上に動作状態のリスナがなくなるまで,そのメンバにのみ接続要求またはパケットを送信する。
シナリオ 4 (推奨しない)
最後に,CAA サブシステムとクラスタ別名サブシステムが適切に補い合って働かないシナリオを示します。
クラスタ・メンバ A および B がクラスタ別名に参加している。
CAA がアプリケーションを制御しているが,そのアプリケーションの配置ポリシは restricted になっており,クラスタ・ノード A またはノード C のいずれかで実行できる。ユーザは,クラスタ別名でサービスにアクセスする。
アプリケーションはノード A で実行されている。ノード A に障害が発生すると,CAA はアプリケーションをノード C に再配置する。
しかし,アプリケーションがノード C で実行されていても,ユーザは別名を通してアプリケーションにアクセスすることができない。