3    クラスタ別名サブシステムの管理

クラスタの管理者は,クラスタ別名の数,各クラスタ別名のメンバシップ,およびクラスタ別名の各メンバの属性を制御します。また,/etc/clua_services ファイル内でポートに割り当てられたクラスタ別名属性を制御します。

この章では次の項目について説明します。

クラスタ別名の構成には cluamgr コマンドと SysMan Menu の両方を使用できます。

3.1    クラスタ別名の特長についての要約

TruCluster Server 『クラスタ概要』のクラスタ別名に関する章で,クラスタ別名の概念について説明しています。クラスタ別名属性またはサービス属性を修正する前に,この章を参照してください。

次に,クラスタ別名の重要な特長についてまとめます。

3.2    構成ファイル

クラスタ別名およびサービスを管理するには,次の構成ファイルを使用します。

/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 を使用します。

3.3    一般的な設計に関する考慮事項

クラスタでどのようにクラスタ別名を構成するかを設計するときには,次の事項を検討します。

3.4    クラスタ別名の作成準備

cluamgr コマンドを使用して,クラスタ別名の指定およびクラスタ別名へ参加する前に,次の手順を実行します。

  1. 各クラスタ別名については,サイトが使用する hosts テーブル (たとえば /etc/hosts,BIND (Berkeley Internet Name Domain),または NIS (Network Information Service)) でクラスタ別名の IP アドレスがホスト名に関連付けられていることを確認します。

    注意

    クラスタからのパスワード保護なしのログインとリモート・シェルを許可するようにクライアント上の .rhosts ファイルを修正する場合は,クラスタの各メンバのホスト名ではなく省略時のクラスタ別名を,ホスト名として使用します。これによってクラスタからのログイン要求では,送信元アドレスとして省略時のクラスタ別名が使用されます。

  2. クラスタ別名の IP アドレスが仮想サブネット上に存在する場合,ローカルのルータには該当するサブネットを登録します (仮想サブネット内には実際のシステムを置くことができないことに注意してください)。

  3. クライアントからの NFS 要求に応答するために,省略時のクラスタ別名以外に別名が必要な場合は,その名前を/etc/exports.aliases に追加します。

  4. 固定ポートが割り当てられたサービスについては,/etc/clua_services 内でそのインターネット・サービスのエントリを調べます。新しい別名でアクセスされる追加のサービスがあれば,/etc/clua_services にそのサービスのエントリを追加します。

3.5    クラスタ別名の指定と参加

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> という状態が表示されます。

クラスタ別名を指定する場合とクラスタ別名に参加する場合は,次の手順を実行します。

  1. 別名のホスト名と IP アドレスを取得します。

  2. 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
     
    

  3. メンバ上で該当する 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 に登録されているインターネット・サービスに関連付けられているサービス・ポート属性を変更するには,次の手順を実行します。

  1. clua_services(4) の情報を使用して,/etc/clua_services 内のエントリを変更します。

  2. このファイルを cluamgr に再度読み取らすために,クラスタの各メンバ上で次のコマンドを入力します。

    # cluamgr -f
     
    

注意

clua_services ファイルを再度読み込んでも,現在実行中のサービスには影響しません。構成ファイルを再度読み込んだ後,サービスを停止して再起動する必要があります。

たとえば,telnet サービスは /etc/inetd.conf から inetd が起動します。clua_services にある telnet のサービス属性を変更した場合は,cluamgr -f を実行してから,inetd を停止した後再起動して変更が有効になるようにしなければなりません。そうしなければ,次にリブートするまで変更が有効になりません。

3.7    クラスタ別名のモニタ

このクラスタ・メンバが認識しているクラスタ別名の状態を表示するには,たとえば次にように 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
 

3.8    クラスタ別名からのメンバの削除

参加先のクラスタ別名からクラスタ・メンバを削除するには,そのメンバ上で次のコマンドを入力します。

# 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 ファイルからではなく,カーネル内の別名リストからその情報を取得します。したがって,ファイルから別名エントリを削除して,別名デーモンを再起動するか,または別名ルーティングを再起動しても,別名は削除されません。

クラスタ別名を削除するには,次の手順に従います。

注意

省略時のクラスタ別名を削除することはできません。クラスタの名前を変更する必要がある場合には,本書で説明されている手順を使用します。

  1. /etc/hosts ファイルからクラスタ別名のエントリを削除します (技術的には必要ありませんが,エントリを削除またはコメント・アウトすると管理上わかりやすくなります)。

  2. 各クラスタ・メンバで,cluamgr -s alias コマンドを実行して,この別名を認識しているクラスタ・メンバを判断します。

  3. この別名を認識している各クラスタ・メンバで,そのメンバの /etc/clu_alias.config ファイルからその別名に関連するエントリをすべて削除します (エントリを削除しておくと,システムのリブート時にその別名が確実に再構成されなくなります)。

  4. 1 度に 1 つづつ,削除する別名のメンバだった各クラスタ・メンバをリブートします。その別名を認識していたすべてのクラスタ・メンバがリブートされると,別名は削除されます。

3.10    アプリケーションの負荷分散

この節では,クラスタ別名のメンバ間でのアプリケーションの負荷分散について説明します。ネットワーク・インタフェースの負荷分散に役立つルーティング・デーモン構成オプションについての情報は,3.14 節を参照してください。

注意

負荷分散の概念は,/etc/clua_services ファイル内で in_multi サービス属性が割り当てられているサービスのみに適用されます。クラスタ別名サブシステムは,そのサービスが in_multi として明示的に定義されていない限り,in_single サービスとして扱います。in_single サービスに対するパケットと要求はすべて別名のメンバへ送られますが,同時に 2 つ以上の別名メンバへ送られることはありません。

クラスタ別名サブシステムは,クラスタの各メンバの性能を監視せず,in_multi のサービスの負荷分散も自動的に行いません。接続要求の分配を制御するには,クラスタ別名の各メンバに選択優先順位と選択重みを割り当てます。これらの属性の値はいつでも手作業で修正できます。

選択優先順位属性 selp=n は,別名のメンバが新しい接続要求を受信する順番を決定します。n の値は 1 以上 100 以下の整数でなければなりません。別名の選択優先順位を使用することで,別名内に階層を作成することができます。

たとえば,4 つのクラスタ・メンバがクラスタ別名に参加していて,別名に対し selp を次の値に設定しているとします。

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 を次の値に設定しているとします。

別名のすべてのメンバが同じ選択優先順位を持っているので,ラウンド・ロビン・アルゴリズムに従ってメンバ・リスト内からこれらのメンバが選択され,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_ftpclua_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    クラスタ単位のポート・スペースの拡張

サービス用にクラスタ全体で使用可能な一時 (動的) ポートの数は,サブシステム属性 inetipport_userreserved_min (省略時の値は 1024),および ipport_userreserved (省略時の値は 5000) によって決まります。

ポート・スペースがクラスタのすべてのメンバ間で共用されるので,複数のメンバが属しているクラスタでは,使用可能なポートの競合が起こる可能性があります。クラスタに 3 つ以上のメンバがある場合は,ipport_userreserved に最大許容値 (65535) を設定することをお勧めします (ipport_userreserved = 65535 にしても何ら悪影響はありません)。

ipport_userreserved に最大値を設定するには,次の手順に従います。

  1. クラスタの任意のメンバ上で,クラスタ単位の /etc/sysconfigtab.cluster ファイルに次の行を追加して,次のリブートで ipport_userreserved が 65535 に設定されるように構成します。

    inet:
     ipport_userreserved=65535
     
    

  2. クラスタの各メンバ上で sysconfig を実行して,ipport_userreserved の現在の値を変更します。

    sysconfig -r inet ipport_userreserved=65535
     
    

3.12    クラスタ別名の vMAC サポートの有効化

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 サポートを有効にするときは,次の手順の実行をお勧めします。

  1. クラスタの任意のメンバ上で,次のように入力します。

    rcmgr -c set VMAC_ENABLED yes
     
    

    これにより,ブート時に vMAC サポートが自動的に有効になります。ただし,この変数の設定はメンバがリブートするときにのみ影響を与えるため,現在実行中のクラスタでは vMAC は有効になりません。

  2. 現在実行中のクラスタで vMAC サポートを手動で有効にするには,各クラスタのメンバで次のコマンドを入力します。

    cluamgr -r vmac
     
    

    各クラスタ・メンバの /etc/clu_alias.config ファイルに cluamgr -r vmac コマンドを追加する必要はありません。各メンバ上で cluamgr -r vmac コマンドを手動で実行すると,vMAC サポートが有効になります。共用の /etc/rc.config.common ファイルで VMAC_ENABLEDyes に設定すると,すべてのクラスタ・メンバで,ブート時に 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 とカスタマイズ gated 構成ファイル (/etc/gated.conf.member<n>) を使い,さらに別名アドレスのホスト・ルートを公開するために RIP を使います。この動作を無効にするには,cluamgrnogated オプションを使い,メンバ上で cluamgr -r nogated コマンドを実行するか,メンバの /etc/rc.config ファイルで CLUAMGR_ROUTE_ARGS="nogated" を設定します。

クラスタにとって,3 つの一般的なルーティング構成のシナリオがあります。

3.15    クラスタ別名と NFS

クラスタを 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 つのクラスタ・メンバ上でのみ動作するアプリケーションを意味します。しかし,クラスタ別名サブシステムでは,アプリケーションが in_single と指定されていると,そのアプリケーションに対応したポート上で受信待ちしているクラスタ別名のメンバの数に関係なく,そのアプリケーションの 1 つのインスタンスにのみ接続要求とパケットが送信されます。つまり,クラスタ別名サブシステムは,アプリケーションがクラスタのすべてのメンバ上で動作しているか 1 つのメンバ上で動作しているかに関係なく,ポート上で受信待機中のクラスタ別名のメンバから任意に 1 つのメンバを選択して,そのメンバにすべての要求を送信します。そのメンバが応答できなくなると,クラスタ別名サブシステムは残りのメンバの 1 つに要求を送信します。

サービスを in_single にするか in_multi にするかは,/etc/clua_services で指定できます。/etc/clua_services に登録して CAA サブシステムに制御させるサービスに対しては,通常,in_single を指定する必要があります。ただし,そのサービスに対して in_multi を指定しても,次の理由から,そのサービスは正常に動作します。

省略時のクラスタ別名にはクラスタのすべてのメンバが属しています。これとは別に,クラスタの中から一部のメンバを集めて,任意のクラスタ別名を作成することができます。また,アプリケーションを起動または再起動するときに,CAA サブシステムの使用するメンバを制限することもできます (favored または restricted 配置ポリシ)。

クラスタ別名を作成した後,ユーザにこのクラスタ別名経由で CAA 制御下のアプリケーションへアクセスさせる場合は,アプリケーションの CAA 配置ポリシで選択されるメンバとそのクラスタ別名のメンバとが一致していることを確認する必要があります。一致していないと,そのクラスタ別名に属さないメンバ上でアプリケーションが起動されることがあります。この状況では,アプリケーションがクラスタ・メンバ上で実行されているにもかかわらず,クラスタ別名サブシステムはそのクラスタ・メンバへパケットを送信できません。

クラスタ別名およびサービス属性と CAA サブシステムとがどのように関わり合うかを,次の 4 つの例を使って示します。

シナリオ 1

この例では,アプリケーションは CAA の制御下にありません。クラスタ別名サブシステムが,どのクラスタ別名にどのクラスタ・メンバが参加しているかを認識しているものとします。今,クライアントから,ターゲットのホスト名としてクラスタ別名を指定したサービス要求が出されたとします。クラスタ別名サブシステムは,次の手順に従って,クラスタ別名の 1 つのメンバに要求を送信します。

シナリオ 2

今度は,アプリケーションが CAA サブシステムに制御されているが,さらに状況を複雑にするために,clua_services 内でアプリケーションが in_multi サービスとして誤って指定されているものとします。この場合は次のようになります。

シナリオ 3

このシナリオでは,アプリケーションが CAA サブシステムの制御下になく,複数のクラスタ・メンバ上で動作しているものとします。また,このアプリケーションのすべてのインスタンスは,同じ既知のポートにバインドされ,そのポート上で受信を待っているものとします。ただし,このサービスの clua_services 内のエントリは in_multi として指定されていないものとします。この場合,クラスタ別名サブシステムはポートを in_single とみなします。この場合は,次のようになります。

シナリオ 4 (推奨しない)

最後に,CAA サブシステムとクラスタ別名サブシステムが適切に補い合って働かないシナリオを示します。