6    クラスタ別名

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

6.1    クラスタ別名の概要

クラスタ別名は,クラスタ内のシステムの一部またはすべてを,TCP (Transmission Control Protocol) および UDP (User Datagram Protocol) アプリケーションからは 1 つのシステムとして見えるようにするための IP アドレスです。図 6-1 は,クラスタ別名があるクラスタ・システムと,クラスタ別名がないクラスタ・システムが,ネットワーク・クライアントからどのように見えるかを示しています。

図 6-1:  クラスタ別名がある場合とない場合の,クライアントからのクラスタの見え方

クラスタ別名を使用すると,クライアントは,サービスを受けるために特定のクラスタ・メンバに接続する必要がなくなります。クライアントがさまざまなサービスを 1 つのホストに要求できるのと同じように,クライアントはさまざまなサービスをクラスタ別名に要求できます。たとえば,単独のホストの場合と同じように,telnetrlogin をクラスタ別名に対して実行できます。

1 つのクラスタが,複数のクラスタ別名を持つこともできます。1 つは,省略時のクラスタ別名です。この別名はクラスタのインストール時に作成され,この別名宛のパケットはすべてのメンバが受信できます。クラスタ管理者は,必要に応じて別名を追加できます。

クラスタ別名は,分散型で仮想的な,クラスタ単位のネットワーク・インタフェースと考えてください。その意味で,クラスタ別名は,1 つの物理ネットワーク・インタフェースが複数の IP アドレスに対して応答する ifconfig 別名と,概念的に似ています。

クラスタ内の各システムは,所属したい別名に明示的に参加します。別名に参加したシステムは,その別名のメンバになります。クラスタ別名が仮想的なネットワーク・インタフェース上のアドレスのようなものだとすると,別名への参加は,その別名インタフェースに対して ifconfig up コマンドを発行するようなものです。これで,そのメンバはその別名宛のパケットを受信できるようになります。

クライアントは,別名の IP アドレスに,TCP 接続要求または UDP メッセージを送信します。クラスタは,その要求またはメッセージを,その別名の現在のメンバであるクラスタ・ノードへ透過的にルーティングします。クラスタ内のホップでは,ネットワーク・ルーティングではなくクラスタ・インターコネクトが使用されます。

別名内に使用できないメンバがある場合,クラスタはそのメンバへのパケットの送信をやめ,その別名内のアクティブなメンバにパケットをルーティングします。別名内にアクティブなメンバが 1 つあれば,その別名は使用できます。

6.2    クラスタ別名の構成要素

クラスタ別名サブシステムの主な構成要素は,次のとおりです。

図 6-2 は,クラスタ別名サブシステムの構成要素の機能概要を示しています。

図 6-2:  クラスタ別名の機能概要

6.3    省略時のクラスタ別名

省略時のクラスタ別名は,特別な別名です。クラスタには,インストレーション時に名前が設定されます。この名前は,cluster_name 属性の値として /etc/sysconfigtab に格納されます。インストレーション・プロシージャは,/etc/hosts にエントリを追加します。このエントリは,クラスタ名と,ユーザ指定の省略時のクラスタ別名の IP アドレスを対応付けます。たとえば,クラスタの名前が deli で別名の IP アドレスが 16.140.112.209 である場合,インストレーション・プロシージャは次のエントリを /etc/hosts に追加します。

16.140.112.209   deli.zk3.dec.com   deli
 

各クラスタ・メンバは,省略時のクラスタ別名のメンバです。クラスタ・メンバを省略時のクラスタ別名に参加させるコマンド cluamgr は,各メンバの /etc/clu_alias.config ファイルにあります。ブート時に各クラスタ・メンバがその clu_alias.config ファイル内のコマンドを起動するため,すべてのクラスタ・メンバは自動的に省略時のクラスタ別名に参加します。

図 6-3 では,2 つのクラスタ別名を持つ 3 ノードのクラスタを示しています。省略時のクラスタ別名である別名 A にはすべてのメンバが属していますが,別名 B に属しているメンバは 2 つだけです。

図 6-3:  2 つの別名を使用するクラスタ

6.4    クラスタごとの別名の数

クラスタをインストールしたのち,そのクラスタに必要な数だけの別名を定義することができます。clua サブシステムの max_aliasid 属性の値は省略時で 8 で,最大値は 102,400 です。この上限は,実際にはメモリ容量で制限されますが,この範囲にあれば実用上おそらく問題にはなりません。

多くのクラスタでは,省略時のクラスタ別名により,クラスタのクライアントに対して十分なアクセスを提供できます。別名の追加がクラスタにとって有益かどうかは,クラスタの対称性 (ストレージとネットワーク) や,すべてのメンバでクライアントからのすべてのサービス要求を処理させたいかどうかによって異なります。別名の追加は,次のような場合に便利です。

省略時の別名をしばらく使った後で別名を追加した方がよいかどうか判断されるようお勧めします。多くの場合,省略時の別名だけで十分です。『クラスタ管理ガイド』 に 2 つの別名を使って負荷分散を行うケースが説明されていますので参考にしてください。

6.5    別名 IP アドレスの位置

クラスタ別名の IP アドレスは (省略時のクラスタ別名の IP アドレスも含む),クラスタのクライアントがアクセスできるネットワーク上になければなりません。つまり,クライアントからの要求をこのサブネットにルーティングできる必要があります。このため,クラスタ別名の IP アドレスを,クラスタ・インターコネクト (クラスタが内部通信用に使用するサブネット) に置くことはできません。

クラスタ別名のアドレスは,次の 2 種類のサブネットのどちらかにあります。

共通サブネット

1 つ以上のクラスタが物理的なネットワーク・インタフェースで接続されたサブネット。

クラスタ別名に共通サブネットを使用すると,クラスタが接続されているローカル・エリア・ネットワークが 1 つだけであり,そのネットワークが単一の IP アドレス・ドメインとして管理されている場合にうまく動作します。

共通サブネットでのクラスタ別名のルーティングは,プロキシ ARP (Address Resolution Protocol) のサポートに基づいて行われます。各別名に対して,1 つのクラスタ・メンバがその別名に対するプロキシ ARP マスタとして動作します。

仮想サブネット

クラスタ別名のアドレスがどの物理インタフェースにも対応しないサブネットにある場合,そのクラスタ別名は仮想サブネット内にあります。仮想サブネットは,gated (ゲートウェイ・ルーティング・デーモン) によって,物理的なネットワークから見ることができます。

cluamgr コマンドを使用して virtual オプションを別名アドレスに割り当てる場合,このコマンドが実行されるクラスタ・メンバは,別名へのホスト・ルートとネットワーク・ルートの両方を公開します。

同じ LAN 上の複数のクラスタは,同一の仮想サブネットを使用できます。

警告

仮想サブネットは,その中に実際のシステムがあってはなりません。

サブネット・タイプの選択は,主に,クラスタが接続されている既存のサブネット (つまり,共通サブネット) にクラスタ別名用として利用できるアドレスが十分にあるかどうかで決まります。既存のサブネットでアドレスが利用できないようであれば,仮想サブネットの作成を検討してください。クラスタが複数のサブネットに接続されている場合に,仮想サブネットを構成すると,接続されているすべてのサブネットから一様に到達できるという利点がある,ということはあまり考慮する必要はありません。ただし,この利点は,実質よりもスタイルの問題です。クラスタ別名アドレスにどのタイプのサブネットを使用するかについては,実際のところ大きな違いはないので,サイトに一番適したサブネットを使用してください。

サブネットは,そのタイプにかかわらず,クライアントからのパケットが別名アドレスにルーティングされるように構成しなければなりません。これらの別名アドレスが,クライアントから到達できない仮想サブネットまたは共通サブネット上にある場合,クラスタ別名を使用するサービスにはアクセスできません。

クラスタ別名アドレスは,ブロードキャスト・アドレスやマルチキャスト・アドレスであってはなりません。また,クラスタ別名アドレスは,クラスタ・インターコネクトで使うサブネット内のアドレスであってもなりません。クラスタ別名に割り当てた IP アドレスが RFC 1918 で定義されている専用アドレス空間にある場合でも,cluamgr -r resvok コマンドを使って,別名サブシステムにその別名アドレスに至るルートを公開させなければなりません (resvok フラグの使用と,/etc/rc.config.common にエントリを追加してルートの公開がリブート後も保持されるようにする方法については, cluamgr(8) を参照してください)。

6.6    別名 IP アドレスへのルーティング

ここでは,別名に至るルートの公開方法と別名宛てパケットのルーティング方法について説明します。

ここで使用する次の用語は用語集に定義されています。これらの用語をよく知らない場合は,用語集でその意味を調べてから先に進んでください。

6.6.1    別名へのルートの公開

別名ルータは,クラスタの別名アドレスをネットワーク上に公開してその別名への着信パケットを受信する,クラスタ・メンバです。省略時の設定により,クラスタ・メンバはすべて,ブート時にそのクラスタ別名の別名ルータとして構成されます。どのクラスタ・メンバでも,別名へのホスト・ルートやネットワーク・ルートを公開するように構成することができます。

注意

省略時の設定では,クラスタ・メンバは汎用ルータとして構成されないため,クラスタ別名宛のトラフィックしかルーティングしません。あるサイトでクラスタ・メンバを 1 つ以上構成して別名宛以外のトラフィックをルーティングさせるかどうかは,そのサイトのネットワーク管理者の仕事です。

クラスタ・メンバは,別名のメンバでなくても,その別名にルーティングすることができます。次の例では,クラスタ・メンバは alias1alias2 を指定するとともに alias2 へ参加しています。その結果,クラスタ・メンバは alias1 または alias2 宛てパケットをルーティングしますが,alias2 宛の要求およびパケットしか受信しません。

/usr/sbin/cluamgr -a alias=alias1
/usr/sbin/cluamgr -a alias=alias2,join
 

6.6.2    共通サブネットでの別名のルーティング

省略時の設定では,クラスタ別名を指定またはクラスタ別名に参加したクラスタ・メンバは,gated を使って,その別名へ至るホスト・ルートを公開します。 aliasd デーモンは /etc/gated.conf.membern を自動的に構成し,/etc/clu_config.alias にある情報に基づいてブート時にホスト・ルートを公開できるようにします。

あるクラスタ別名に対する ARP (Address Resolution Protocol) 要求には,同時に 1 つの別名メンバしか応答できません。応答できるメンバは,その別名のプロキシ ARP マスタです。このシステムに障害が起こると,別のメンバが選ばれてプロキシ ARP マスタの役割を引き継ぎます。

注意

プロキシ ARP は,共通サブネット (物理的なネットワーク) 上に構成されている別名アドレスだけに適用されます。

クラスタ別名アドレスが複数定義されている場合は,rpri 別名属性を使用して,別名アドレスごとに異なるクラスタ・メンバに最も高いルーティング優先順位を与えれば,受信負荷を少しだけ軽減することができます。別名が 1 つだけでしかも ARP ベースのルーティングを行っている場合は,一度に 1 つのメンバだけが別名ルータとして動作します (6.8 節にルータ優先順位の属性 rpri の説明があります)。

ただし,別名を知っているそれぞれのクラスタ・メンバは gated を使って,各クラスタ別名へのホスト・ルートを自分のネットワーク・インタフェースに設定します。ARP で使うインタフェース・ルートよりホスト・ルートが優先されるため,ルート・デーモンを実行しているクラスタと同じサブネット内であれば,どのクライアントも,ホスト・ルートを見ることができます。どのクラスタ・メンバがどの順番でブートされるかはその時々で異なるため,クライアントが異なれば,最初に見るクラスタ・メンバのホスト・ルートも異なってきます。したがって,それぞれのクライアントが,クラスタ別名へのルートとして異なるクラスタ・メンバを使うこともあります (これは,ホスト・ルート情報がすべてのクライアントに配布されているとは限らないためです。クライアントがクラスタより前にブートされている場合は,公開した最初のクラスタ・メンバを調べ,そこから得たホスト・ルートを使用します)。routedgated のようなルート・デーモンを実行していないクライアント・システムでは,ARP プロトコルを使ってクラスタ別名を調べ,そこへ向けて送信します。これはプロキシ ARP マスタを通してルーティングされます。

つまり,クライアントが別名へのルートを解決するために,ホスト・ルートではなく ARP を使用している場合,ARP に応答するクラスタ・メンバは,着信パケットが最初に送られて,トンネルするシステムになります。クライアントがホスト・ルートを使用する 場合 (ルータは通常そうします),rpri 設定は,着信パケットがたどるパスには影響を及ぼしません。

6.6.3    仮想サブネットでの別名のルーティング

省略時の設定では,クラスタ別名を指定またはクラスタ別名に参加したクラスタ・メンバは,gated を使って,その別名へ至るホスト・ルートを公開します。別名デーモン aliasd は,各クラスタ・メンバに対して /etc/gated.conf.membern ファイルを作成します。別名構成処理では,仮想サブネット内の各別名アドレスをホスト・ルートとして公開するために,この構成ファイルをあらかじめ変更しています。手動による変更は不要です。各メンバの別名デーモンが,そのメンバの /etc/gated.conf.membern ファイルを自動的に変更し,そのメンバ上の各ネットワーク・インタフェースを介して,各クラスタ別名ホスト・アドレスへのルートを公開します。

cluamgr コマンドで別名アドレスに virtual オプションを指定すると,クラスタ・メンバはその別名の存在する仮想サブセットへのネットワーク・ルートを公開します。ネットワークに仮想サブネットの位置を確実に知らせるためには,少なくとも 1 つ,可能ならばすべてのメンバが,各仮想サブネット内の少なくとも 1 つの別名に対してvirtual=t オプションを指定して cluamgr を実行するようにしてください。

共通サブネットのルートの公開と同様に,ルーティングの負荷を複数のクラスタ・メンバに分散させることができます。ただし,どの程度分散できるかは,クライアントがどの順番でルートの公開情報を見るかによって異なります。

6.6.4    共通サブネットおよび仮想サブネット上の別名に対するルーティングのまとめ

表 6-1 に,省略時のルーティング・デーモン構成 (gated を制御する aliasd) で,共通サブネットおよび仮想サブネット上のクラスタ別名に対して公開されるルートのタイプを,まとめて示します。

表 6-1:  共通サブネットおよび仮想サブネット上の別名に対するルーティングのまとめ

サブネットのタイプ アドレスのドメイン プロキシ ARP gated 経由のホスト・ルート gated 経由のネットワーク・ルート
共通 クラスタが接続しているサブネット [脚注 1] [脚注 2] ×
仮想 物理的に接続していないサブネット (クラスタの「背後」に存在して見える) × [脚注 2] [脚注 3]

注意

クラスタ・メンバに対する省略時のルーティング・デーモン構成は gated デーモンで,そのメンバの /etc/gated.conf.membern デーモン構成ファイルを使用します。クラスタ・メンバは,クラスタ別名へのホスト・ルート (virtual が指定された場合には仮想ネットワークのネットワーク・ルートも) を自動的に公開します。標準の gated 構成ファイル (/etc/gated.conf) を使用する場合,別のルーティング・デーモン (routed) を使用する場合,またはいずれのルーティング・デーモンも使用しない場合,クライアントがクラスタ別名にアクセスできるように静的ルートを指定する必要があります。

詳細は,『クラスタ管理ガイド』 を参照してください。

6.6.5    別名宛て接続要求およびパケットの受け付けとリダイレクション

通常のルーティングであれば,クラスタ別名に宛てられたパケットは必ず 1 つのクラスタ・メンバに到着します (1 つのパケットを複数のクラスタ・メンバが処理することはありません)。そのメンバは,次に示す情報および方法で,どの別名メンバがパケットの受信と処理を行うかを決めます。

次の表で,パケットがクラスタ内でどのようにリダイレクトされるかを説明します。

新規の TCP/IP 接続 パケットを参照し,ターゲット・ポートに合ったメンバのリストを作成する。加重ラウンドロビン・アルゴリズムを使用して,受信待ちメンバのリストからメンバを選択する。選択したメンバにパケットを転送する。
既存の TCP/IP 接続 どの別名メンバがこの接続を所有しているかを調べる。 そのメンバにパケットを転送する。
UDP

パケットを参照し,ターゲット・ポートに合ったメンバのリストを作成する。加重ラウンドロビン・アルゴリズムを使用して,受信待ちメンバのリストからメンバを選択する。そのメンバにパケットを転送する。

(クラスタ別名サブシステムで NFS over UDP がどのように処理されるかについ ての詳細は,6.11 節を参照。)

ICMP (ICMP パケットには,クラスタ別名コンテキストで処理しなければならないものもある) パケットを参照し,そのパケットを処理するか他のメンバに転送するかを判断する。

一例として,マルチ・インスタンス・サービスに対する TCP 接続要求のルーティングを考えてみます。クライアント・システムがクラスタ別名 IP アドレスに対して TCP 接続を行い,クライアントとクラスタ・メンバ間にルータがあるとします。

6.6.6    ルーティングの例

図 6-4 は,3 つのネットワーク,2 つの公用共通ネットワーク,1 つの専用仮想ネットワークのインタフェースを備えたクラスタを示しています。省略時のクラスタ別名の IP アドレスは,仮想サブネット上にあります。

図 6-4:  別名ルーティングの例

適切な cluamgr を使って別名を構成すれば,各ノードの gated デーモンが,接続しているすべてのネットワークで次の情報を公開します。

次の例では,cluamgr コマンドをホスト A とホスト B で実行して,仮想サブネット上のクラスタ別名へのルートを公開しています。

6.7    in_single および in_multi サービス

クラスタ別名を通してアクセスされるサービス・ポートは,in_single または in_multi のいずれかとして定義されます。これらのサービス・ポート属性は,アプリケーションへのネットワーク要求のルーティングを決定しますが,アプリケーションが複数のメンバで同時に実行できるかどうかは決定しません。クラスタ別名サブシステムから見ると,次のような処理が行われます。

省略時の設定では,クラスタ別名サブシステムは,すべてのサービスを in_single として処理します。クラスタ別名サブシステムがサービスのポートを in_multi として処理するようにするには,/etc/clua_services 内か,clua_registerservice() 呼び出しで,ポートを in_multi として登録しなければなりません。サービス・ポートの属性についての詳細は,6.9 節を参照してください。

ポートが in_multi として指定されているサービスでは,クラスタ別名の利点を生かして,別名メンバ間に着信 TCP 接続要求と UDP パケットを分散させることができます。別名サブシステムは,別名メンバ間に要求およびパケットを分散させる加重ラウンドロビン・アルゴリズムによって,負荷のバランスを調整します。クライアントの要求に応答できない別名メンバがある場合,クラスタ別名ソフトウェアは要求およびパケットを他の別名メンバに透過的に分散させます (アルゴリズムの重み付けの部分は,別名の各メンバがその別名に割り当てる選択の重み selw によって制御されます。選択の重みについての詳細は6.8 節を参照してください)。

注意

クラスタ別名と CAA は,補足し合う異なる機能を備えた独立したサブシステムです。CAA はアプリケーション制御ツールであり,クラスタ別名はルーティング・ツールです。CAA はアプリケーションが実行される場所を決定し,クラスタ別名はその場所へ到達する方法を決定します。CAA を使用してクラスタ内のルーティングを制御することはできません。また,クラスタ別名を使用して,クラスタ内のどこでアプリケーションを実行するかを制御することはできません。『クラスタ管理ガイド』 に,クラスタ別名と CAA の相違点についての詳しい説明があります。

次の 2 つの図は,クラスタ別名サブシステムが in_single サービスおよび in_multi サービスのクライアント要求を分配する方法を示しています。in_single サービスの場合 (図 6-5),要求はすべて,現在サービスを実行している別名メンバに送られます。in_multi サービスの場合 (図 6-6),要求はすべての別名メンバに分散されます。

図 6-5:  省略時のクラスタ別名を通してアクセスされる in_single サービス

図 6-6:  省略時のクラスタ別名を通してアクセスされる in_multi サービス

6.8    別名の属性

ここでは,別名の属性について一般的に説明し,ルータの優先順位 (rpri),選択の優先順位 (selp),および選択の重み (selw) について詳しく説明します。

別名とその属性は,cluamgr コマンドと SysMan Menu によって管理されます。SysMan Menu は,必要に応じて cluamgr を呼び出します。

別名の属性は,メンバに固有です。クラスタ・メンバによって,別名の見え方が異なります。たとえば,クラスタ・メンバによっては,別名へルーティングできても,その別名のメンバでないことがあります。また,他のクラスタ・メンバは,その別名へルーティングが可能で,同時にその別名宛の要求またはメッセージの最終受信者となることもあります。同様に,別名の属性は別名にも固有です。クラスタ・メンバは,同時に 2 つの別名のメンバとなり,それぞれの別名に異なる選択の重みを割り当てることができます。そうすることでメンバ・システムは,選択の重みがより大きい方の別名に宛てられた接続を,もう一方の別名より多くの割合で受けることができます。

次の属性は,接続要求およびパケットの,別名のメンバへのルーティングと分配の方法を制御します。この説明は, cluamgr(8) の説明を書き換えたものです。このリファレンス・ページには,この他の別名属性についても説明があります。

ルータの優先順位

ルータの優先順位 (rpri) は,共通サブネット上の別名に対する,プロキシ ARP ルータの選択を制御します (このオプションは,アドレスが仮想サブネット内にある別名に対しては関係ありません)。

共通サブネット内の各別名について,その別名に対するルータ優先順位が最も高いクラスタ・メンバが,ARP 要求に応答します。このオプションは,どのメンバが別名のホストやネットワーク・ルートをブロードキャストするかを制御するわけではありません。

クラスタに複数のクラスタ別名がある場合,ルータの優先順位を使用して,別名のプロキシ ARP 応答オーバヘッドをクラスタ・メンバ間に分散させることができます。

選択の優先順位

選択の優先順位 (selp) によって,新しい接続要求を受け付ける別名のメンバのサブセットが決まります。

選択の優先順位によって,別名のメンバが階層化されます。接続要求は,選択の優先順位の値が最も高いメンバ間に分散されます。別名にメンバが 3 つあり,2 つが selp=10 で 1 つが selp=5 である場合,selp=10 のメンバがどちらか使用できるかぎり,selp=5 のメンバに接続要求やメッセージが渡されることはありません。

選択の優先順位の値を使用すると,特定のクラスタ別名のメンバに対して,フェイルオーバの順序を設定できます。

選択の優先順位は in_multi サービスとして登録されているアプリケーションにだけ適用されます (選択の優先順位は,ラウンドロビン・プロセスでノードのセットを束縛し,ラウンドロビン・プロセスだけがマルチ・インスタンス・アプリケーションに適用されます)。in_single サービスの接続要求の分散に対しては何の影響も及ぼしません。

選択の重み

選択の重み (selw) を使うことで,別名のどのメンバに接続を最も多く受けさせるかを,簡単でしかも固定的に制御することができます。

選択の重みは,selp 値が同じ次の別名メンバに接続が渡されるまでにそのメンバに渡される接続の数 (平均) を示します。selp の値により,要求やメッセージを受け取るメンバを選択する順序が決まります。selw の値により,選択された後に 1 つのメンバが受け取る要求またはメッセージの数が決まります。

ノード A がノード B より処理能力があって,ノード B より 50 % 多く接続を処理できる場合,たとえば,ノード A 上の別名に selw=3 を,また,ノード B 上の別名に selw=2 をそれぞれ割り当てます。

選択の重みは,in_multi サービスとして登録されたアプリケーションにのみ適用されます。in_single サービスのトラフィックはすべて,そのサービスを実行しているクラスタ・メンバに渡されなければなりません。

選択の重みとルーティングの優先順位は,負荷分散に関する 2 つの問題を解決します。選択の重みは,クラスタ内でのアプリケーションのオーバヘッドの負荷分散を行い,ルータの優先順位は,クラスタ内でのプロキシ ARP 応答のオーバヘッドの負荷分散を行います。

一般には,省略時の優先順位で十分な性能が得られます。選択の重みが役立つのは,大規模なシステムと小規模なシステムが混在するクラスタ内でアプリケーションの負荷分散を行う場合です。

6.9    サービス・ポートの属性

/etc/clua_services ファイルはすべてのクラスタ・メンバによって読まれる共用ファイルです。このファイルの概念と構文は,/etc/services ファイルに似ています。clua_services ファイルにより,別名に関連する属性と,サービスに使用するポート番号とを対応させることができます (アプリケーションのソース・コードでは,clua_registerservice() 関数が同じ目的で使用されます)。ポート割り当てが固定のサービスは,/etc/clua_services 内にエントリを置くことができます。

以下の属性を,サービスのポートに対応させることができます。

in_single

クラスタ別名から見ると,一時点では 1 つのクラスタ・メンバのみで実行され,アクティブなサービスの障害時には,他のメンバ上のそのサービスのインスタンスにフェイルオーバするサービス。ここでいう「アクティブ」は,クラスタ別名宛のメッセージのみに関連します。サービスのインスタンスはすべて,in_nolocal 属性が設定されていないかぎり,ノードのローカル IP アドレスに対しては常にアクティブです。各サービスがアプリケーションのポートにバインドされるたびに,最初のインスタンスがその別名に対してアクティブになり,その他は非アクティブになります。アクティブなサービスに障害が発生すると,非アクティブなサービス・デーモンのいずれかがアクティブとしてマークされます。

clua_services ファイル内で in_multi と明示されていないポートや,clua_registerservice() 関数の呼び出しで in_multi として登録されていないポートは,in_single として処理されます。

in_multi

2 つ以上のクラスタ・メンバで同時に実行できるサービスを示します。UDP を使用するサービスの場合,各パケットは別の別名メンバに転送されることがあります。TCP を使用するサービスの場合,各接続はいずれかの別名メンバにバインドされます。ただし,同じクライアントからのそのサービスへの別の接続は,別の別名メンバ上で確立されることがあります。

in_multi サービスは,/etc/clua_services ファイル内か,clua_registerservice() 関数によって,明示的に登録しなければなりません。

in_noalias

別名アドレスへの接続要求を受け付けないポートであることを示します。

in_nolocal

別名でないアドレスへの接続要求を受け付けないポートであることを示します。TCP の場合,ポートは接続を受け付けません。UDP の場合,ポートはメッセージをドロップします。

out_alias

ポートがデスティネーションとして使用されるときに,ソース・アドレスとして省略時のクラスタ別名を使用することを示します。通常,発信接続 (または UDP メッセージ) では,クライアントが実行されているクラスタ・メンバのローカル IP アドレスを使用します。クラスタからの発信トラフィックのソース・アドレスとして,クラスタ別名アドレスを使用した方が便利な場合があります (たとえば,認証が簡単になる)。telnetlogin などの標準のインターネット・サービスには,省略時のクラスタ別名を発信パケットのソース・アドレスとして使用するものがあります。

out_alias 属性は,接続 (UDP ではなく TCP) がクラスタから開始された場合にのみ適用されます。つまり,クラスタがクライアントとなります。クラスタ・メンバ上で実行しているプロセスが発信接続を開始し,クラスタの /etc/clua_services ファイル内でデスティネーション・ポート (クラスタ内にない側の接続を表すポート) に out_alias のフラグが付けられている場合,接続のソース・アドレスとして省略時の別名を使用します。

発信トラフィックが UDP 送信である場合にも,同じことが言えます。これは,各送信を小さな接続と見なすことができるためです。

static

このポートが,動的ポートとして割り当てられないことを示します。このオプションは,ブート時に必ず起動される既知のマルチ・インスタンス・ネットワーク・サービスが使う 512 〜 1024 のポートに割り当てられます。

out_alias 属性を除き,これらの属性は,どのクラスタ別名を通してアクセスされるサービスにも適用されます。クラスタからの接続のみに適用される out_alias 属性は,省略時のクラスタ別名に固有の属性です。

in_multiin_singlein_noalias 属性は,互いに排他的です。in_nolocalin_noalias 属性は,互いに排他的です。これらの属性の使用方法についての詳細は, clua_services(4) および clua_registerservice(3) を参照してください。

6.10    vMAC サポート

クラスタ別名 IP アドレスが共通サブネット内で構成されている場合,そのサブネット内のクラスタ・メンバが別名のプロキシ ARP マスタとして動作し,その別名に宛てられたローカルな ARP 要求に応答します。別名の他のメンバがプロキシ ARP マスタを引き継いだ場合は,その新しいマスタが無償の (gratuitous) ARP パケットをブロードキャストし,その別名の IP アドレスに関連付けられているハードウェアのメディア・アクセス制御 (MAC) アドレスを他のシステムに通知します。他のローカル・システムは,この新しいクラスタ別名と MAC との関連を反映するように ARP テーブルを更新します。

ただし,このブロードキャスト・パケットは,無償の ARP パケットを理解しないシステムにとっては問題となります。このようなシステムでは,ARP テーブルの通常のタイムアウト間隔が経過するまで,クラスタ別名と MAC の関連付けに変更があったことを認識しないまま,無効となった MAC アドレスへ別名のトラフィックを送り続けます。この問題の解決方法は,各クラスタ別名の仮想ハードウェア・アドレス (vMAC アドレス) を提供することです。

仮想 MAC アドレスは,各別名 IP アドレスに対して自動的に作成される一意のハードウェア・アドレスです。別名 vMAC アドレスは,必要に応じて,クラスタ別名プロキシ ARP マスタの移動に合わせてノードからノードへ移動します。どのクラスタ・マスタが別名に対してプロキシ ARP としてサービスを行っているかには関係なく,その別名の vMAC アドレスは変わりません。

クラスタ別名に対する vMAC サポートを有効にする方法については,『クラスタ管理ガイド』 を参照してください。

6.11    NFS とクラスタ別名

クラスタが NFS サーバとして構成されている場合,NFS クライアントの出す要求は,省略時のクラスタ別名または /etc/exports.aliases の中に指定されている別名へ送る必要があります。宛先としてクラスタ・メンバを個別に指定して NFS マウントを要求すると拒否されます。

出荷された時点で NFS クライアントが使用できる別名は,省略時のクラスタ別名だけです。これ以外の別名を NFS クライアントが使用できるようにする場合は,その別名を exports.aliases ファイルで指定します。この機能は,クラスタの一部のメンバがエクスポートされたファイル・システムのあるストレージに直接接続していない場合に有効です。その場合,ファイル・システムに直接接続しているメンバだけを別名に登録することにより,NFS 要求のサービスに必要な内部のルーティング・ホップ数を減らすことができます。

以下に,TCP と UDP NFS トラフィックの観点から,クラスタ別名サブシステムと NFS がどのように関わるかを説明します (できれば,ネットワーク・トランスポートに UDP を使用するようお勧めします)。説明では,クライアントがクラスタに対して行う最初のアクションとして,クラスタのエクスポートしたファイル・システムをマウントするものとします。また,すべてのクラスタ・メンバが共通ネットワークとストレージの両方に接続しているものとします。

6.11.1    ネットワークからのパケットの受信

TCP または UDP を使用して NFS の要求を送る場合,その要求は省略時のクラスタ別名,または,/etc/exports.aliases の中に名前の指定されている別名へ送られます。

省略時の設定では,クラスタ・メンバは,自分が指定したかまたは参加している各別名へのホスト・ルートを公開します。クライアントは,通常,最初に取得した別名へのホスト・ルートをキャッシュに置きます。そのため,そのルートが利用できる限り,クライアントは同じ別名宛のパケットをすべて同じクラスタ・メンバへ送ることになります。

着信方向では,すべてのパケットがこのメンバを通りますが,応答の送信方向では必ずしも通りません。そのため,応答パケットを伝送路に送り出すクラスタ・メンバはソース・アドレスとしてそのクラスタ別名アドレスを挿入します。その結果,クライアントは,パケットを送り出したその宛先別名から応答パケットを受信することができます。

6.11.2    マウント要求

マウント・デーモン mountd は,UDP および TCP のマウント要求を受け付けて処理するマルチ・インスタンス・サービスです。どの mountd インスタンス・サービスにマウント要求を処理させるかは,クラスタ別名サブシステムが決めます。マウント要求を処理するノードと NFS パケットを受信して処理するノードが同じノードになることもありますが,基本的には両者に関係はありません。

6.11.3    NFS over TCP

TCP の接続要求は,別名のラウンドロビン・アルゴリズムと別名の選択重みを基にして割り当てられます (接続要求の中にファイル・システムの情報がないため,クラスタは,その時点でファイル・システムの CFS サーバになっているメンバにその要求を送れません)。クライアントからそのファイル・システムへ向けて送られてくるそれ以降の TCP NFS パケットは,その接続に割り当てられているメンバが引き続き処理します。この関係は,ファイル・システムが再配置されても変わりません。

図 6-7 とその後にある流れの説明を読みながら,NFS TCP 接続のパスをたどってください。

図 6-7:  NFS over TCP

  1. クライアントにルートがキャッシュされているので,NFS の要求は,ほとんどの場合,マウント要求のときと同じメンバを通ります。

  2. TCP の接続が最初の要求ですでに確立されているので,伝送路からパケットを受信したメンバは,自動的にそのパケットをその接続を処理する NFS サーバのメンバへ回します (伝送路からパケットを受信したノードでは,CFS サーバの検索は行われません)。

    注意

    以下の手順では,NFS サーバとファイル・システムの CFS サーバが異なる場所にあると想定しています。

  3. NFS サーバは,インターコネクトを介して,CFS サーバになっているメンバへ CFS 要求を送ります。

  4. CFS サーバがストレージの入出力を処理します。

  5. CFS サーバは,インターコネクトを介して,NFS サーバ・メンバへ結果を返します。

  6. NFS サーバ・メンバがクライアントに応答します (ソース・アドレスとして別名アドレスを使用)。

6.11.4    NFS over UDP

UDP NFS パケットは,ファイル・システムのサービスを行っているクラスタ・メンバへリダイレクトされます。 そのファイル・システムに対する UDP NFS トラフィックはすべて,そのメンバ上で処理されます。 別のクラスタ・メンバがそのファイル・システムの CFS サーバになると,UDP パケットは新しいサーバにトンネルされます。 ファイル・システムに対する CFS サーバの位置が変われば,UDP パケットは必ず,その新しい位置へ送られます。

注意

PC など一部のクライアントは,NFS サーバを探す際に UDP 要求をブロードキャストします。クラスタは,省略時のクラスタ別名の IP アドレスを返して,これらの要求に応答します。これにより,その後の NFS クライアントの要求は省略時のクラスタ別名へ確実に送られます。

図 6-8 とその後にある流れの説明を読みながら,NFS over UDP で NFS 要求の通るパスをたどってください。

図 6-8:  NFS over UDP

  1. クライアントにルートがキャッシュされているので,NFS の要求は,ほとんどの場合,マウント要求のときと同じメンバを通ります。

  2. NFS UDP パケットに NFS の要求に必要なデータがすべて入っているので,伝送路からパケットを受信したメンバ上のクラスタ別名ソフトウェアは,どのファイル・システムにそのファイルがあるかを調べ,さらに,CFS コールアウトを実行して,どのメンバがそのファイル・システムの CFS サーバになっているかを知ることができます。

    注意

    以下の手順では,CFS サーバがそのパケットの宛先となっているクラスタ別名のメンバであると想定しています。

  3. パケットは,そのファイル・システムの CFS サーバでもある NFS サーバへトンネルされます。CFS サーバは,要求を自分のところで処理できます (TCP より UDP の方の性能がすぐれています。これは,UDP パケットがインターコネクトを 1 度しか通らないためです。また,NFS サーバが同時に CFS サーバにもなっているため,CFS の入出力処理で余分な通信が発生することもありません)。

  4. NFS サーバと CFS サーバの両方になっているメンバが入出力を処理します。

  5. NFS サーバと CFS サーバの両方になっているメンバがクライアントに直接応答します (ソース・アドレスとして別名アドレスを使用)。

注意

そのファイル・システムの CFS サーバが別名のメンバでなければ,受信ノードは,TCP 接続の要求を処理する場合と同様に,そのパケットをラウンドロビンで次へ回します。この場合,UDP の性能は TCP の場合より悪くなります。それは,TCP の場合,クライアントから入ってくるすべてのパケットがそのコネクションをサービスするノードへトンネルされ,結果として,同じクライアントからの同じファイルへの入出力がすべて同じノードで処理されるからです。これに対して UDP の場合は,CFS サーバがその別名のメンバでなければ,同じファイルのそれぞれの入出力要求が,異なるクラスタ・メンバで処理されることになります。この場合,CFS クライアントはデータをキャッシュすることができないため,お互いのキャッシュ内容を無効にしあって,CFS サーバ・ノードへそのたびに書き込みに行く結果になります。

6.12    RPC サービスとクラスタ別名

RPC サービスでは,clusvc_getcommport() 関数または clusvc_getresvcommport() 関数を呼び出して,ポートへのバインドを行います (ポート番号 0 〜 1023 の予約済み (特権) ポートへのバインドを行う場合は,clusvc_getresvcommport() を使用します)。どちらの関数も clua_registerservice() を呼び出して,ポートに CLUASRV_MULTI (in_multi) 属性を自動的に設定します。

clusvc_getcommport() および clusvc_getresvcommport() 関数は,次のような状況で使用します。

これらの 2 つの関数により,クラスタ別名でアクセスされる RPC アプリケーションを複数のクラスタ・メンバ上で実行できるようになります。この関数により,RPC アプリケーションの各インスタンスが同じ共通ポートを使用するだけでなく,アプリケーションがマルチ・インスタンスの別名アプリケーションであることを portmap デーモンに通知します。

これらの関数を使用せずにポートにバインドした場合でも,アプリケーションのインスタンスを複数実行することはできます。ただし,クラスタ別名宛の要求を受信するのは,そのインスタンスだけです。

6.13    ifconfig 別名とクラスタ別名

TruCluster Server バージョン 5.0 より前の TruCluster 製品では,asemgr コマンドを使用して,アプリケーションのフェイルオーバを制御していました。asemgr コマンドは ifconfig コマンドを実行して,必要に応じて IP 別名を作成していました。クラスタ別名サブシステムはクラスタ単位で別名の作成と管理を行うため,アプリケーションのフェイルオーバ時に ifconfig を使用して IP 別名を明示的に確立したり削除したりする必要はなくなりました。

クラスタ別名アドレスは,IP アドレスとサービスが 1 対 1 になるようには設計されていません。クラスタ別名は,クラスタ全体を表すアドレス (またはクラスタのサブセットを選んで特定の別名を定義したもの) であり,その設計概念の中心となるのは,複数のコピーを同時に走らせることのできるアプリケーションです (マルチ・インスタンス・サービス)。シングル・インスタンス・サービスが必要な場合は,CAA で最適に構成することにより,サービスのフェイルオーバを一層簡単に管理することができます。

ASE サービスの知識があれば,ifconfig alias を使い,CAA スクリプトでアプリケーションに固有なインタフェースの別名アドレスを定義することができます。こうして定義した別名はクラスタ別名に依存していないため,競合は起こりません。

省略時のクラスタ別名を使用する利点は,クラスタ内でアプリケーションを移してもアプリケーション・アドレスを移行させる必要がないということです。これは,すべてのアプリケーションが同じアドレス (省略時のクラスタ別名) を使っているということだけでなく,そのクラスタ別名のコードによって,アプリケーションがクラスタ内のどこで動作しているかが常に分かるからです。さらに,アプリケーションが (広範囲にわたる複数メンバで同時に) マルチ・インスタンスを動作させた場合,クライアントは,同じクラスタ別名を使用することにより,複数のメンバが関係することを意識しないですべてのインスタンスに透過的にアクセスすることができます。

ASE スタイルのサービス・インタフェースごとの別名 (スクリプトで定義し,スクリプトでサービスと一緒に移行したもの) を使用する利点の 1 つは,トラフィックが,常に,サービスを実行しているノードへ直接ルーティングされるということです (クラスタ別名の場合,トラフィックは,かなりの頻度でクラスタ内を 1 ホップかかって転送されます)。サービスごとにアドレスを定義してそれを手動で移行するほどこのホップを重要視するかどうかは,アプリケーションのスループット要求で決まります。