Sun Cluster の概念 (Solaris OS 版)

データサービス

「データサービス」という用語は、Oracle や Sun Java System Web Server など、単一のサーバーではなく、クラスタで動作するように構成されたアプリケーションを意味します。データサービスは、アプリケーション、専用の Sun Cluster 構成ファイル、および、アプリケーションの次のアクションを制御する Sun Cluster 管理メソッドからなります。

開始
停止
監視と訂正手段の実行

データサービスタイプについては、『Sun Cluster の概要 (Solaris OS 版)』の「データサービス」を参照してください。

図 3–4 に、単一のアプリケーションサーバーで動作するアプリケーション (単一サーバーモデル) と、クラスタで動作する同じアプリケーション (クラスタサーバーモデル) との比較を示します。これら 2 つの構成の唯一の違いは、クラスタ化されたアプリケーションの動作がより速くなり、その可用性もより高くなることです。

図 3–4 標準的なクライアントサーバー構成とクラスタ化されたクライアントサーバー構成

単一サーバーモデルでは、特定のパブリックネットワークインタフェース (ホスト名) を介してサーバーにアクセスするようにアプリケーションを構成します。ホスト名はその物理サーバーに関連付けられています。

クラスタサーバーモデルのパブリックネットワークインタフェースは「論理ホスト名」か「共有アドレス」です。「ネットワークリソース」は、論理ホスト名と共有アドレスの両方を表します。

一部のデータサービスでは、ネットワークインタフェースとして論理ホスト名か共有アドレスのいずれかを指定する必要があります。論理ホスト名と共有アドレスは相互に交換できません。しかし、別のデータサービスでは、論理ホスト名や共有アドレスをどちらでも指定することができます。どのようなタイプのインタフェースを指定する必要があるかどうかについては、各データサービスのインストールや構成の資料を参照してください。

ネットワークリソースは、特定の物理サーバーと関連付けられているわけではありません。ネットワークリソースは、ある物理サーバーから別の物理サーバーに移すことができます。

ネットワークリソースは、当初、1 つのノード (一次ノード) に関連付けられています。主ノードで障害が発生すると、ネットワークリソースとアプリケーションリソースは別のクラスタノード (二次ノード) にフェイルオーバーされます。ネットワークリソースがフェイルオーバーされても、アプリケーションリソースは、短時間の遅れの後に二次ノードで動作を続けます。

図 3–5 に、単一サーバーモデルとクラスタサーバーモデルとの比較を示します。クラスタサーバーモデルのネットワークリソース (この例では論理ホスト名) は、複数のクラスタノード間を移動できます。アプリケーションは、特定のサーバーに関連付けられたホスト名として、この論理ホスト名を使用するように設定されます。

図 3–5 固定ホスト名と論理ホスト名

共有アドレスも最初は 1 つのノードに対応付けられます。このノードのことを「広域インタフェースノード」といいます。共有アドレスは「広域インタフェース」といい、クラスタへの単一ネットワークインタフェースとして使用されます。

論理ホスト名モデルとスケーラブルサービスモデルの違いは、スケーラブルサービスモデルでは、各ノードのループバックインタフェースにも共有アドレスがアクティブに構成される点です。この構成では、データサービスの複数のインスタンスをいくつかのノードで同時にアクティブにすることができます。「スケーラブルサービス」という用語は、クラスタノードを追加してアプリケーションの CPU パワーを強化すれば、性能が向上することを意味します。

広域インタフェースノードに障害が発生した場合、共有アドレスは同じアプリケーションのインスタンスが動作している別のノードで起動できます。これによって、このノードが新しい広域インタフェースノードになります。または、共有アドレスを、このアプリケーションを実行していない別のクラスタノードにフェイルオーバーすることができます。

図 3–6 に、単一サーバー構成とクラスタ化されたスケーラブルサービス構成との比較を示します。スケーラブルサービス構成では、共有アドレスがすべてのノードに設定されています。アプリケーションは、特定のサーバーに関連付けられたホスト名として、この共有アドレスを使用するように設定されます。この方式は、フェイルオーバーデータサービスに論理ホスト名を使用する方法と似ています。

図 3–6 固定ホスト名と共有アドレス

データサービスメソッド

Sun Cluster ソフトウェアでは、一連のサービス管理メソッドを提供しています。これらのメソッドは、Resource Group Manager (RGM) の制御下で実行されます。RGM はこれらのメソッドを使用して、クラスタノード上またはゾーン内のアプリケーションを開始、停止、および監視します。これらのメソッドとクラスタフレームワークソフトウェアおよび多重ホストデバイスにより、アプリケーションは、フェイルオーバーデータサービスやスケーラブルデータサービスとして機能します。

さらに、RGM は、アプリケーションのインスタンスやネットワークリソース (論理ホスト名と共有アドレス) といったクラスタのリソースを管理します。

Sun Cluster ソフトウェアが提供するメソッドのほかにも、Sun Cluster ソフトウェアは API やいくつかのデータサービス開発ツールを提供します。これらのツールを使用すれば、アプリケーション開発者は、独自のデータサービスメソッドを開発することによって、ほかのアプリケーションを Sun Cluster ソフトウェアの下で高可用性データサービスとして実行できます。

フェイルオーバーデータサービス

データサービスが実行されているノードまたはゾーン (主ノード) に障害が発生すると、サービスは、ユーザーによる介入なしで別の作業ノードまたはゾーンに移行します。フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (「論理ホスト名」) のコンテナである「フェイルオーバーリソースグループ」を使用します。論理ホスト名は、1 つのノードまたはゾーンで構成でき、あとで自動的に元のノードやゾーンに構成したり、別のノードやゾーンに構成することができる IP アドレスです。

フェイルオーバーデータサービスでは、アプリケーションインスタンスは単一のノードまたはゾーンでのみ実行されます。フォルトモニターは、エラーを検出すると、そのインスタンスを同じノードまたはゾーンで再起動しようとするか、別のノードまたはゾーンで起動 (フェイルオーバー) しようとします。出力は、データサービスの構成方法によって異なります。

スケーラブルデータサービス

スケーラブルデータサービスは、複数のノードまたはゾーンのアクティブインスタンスに対して効果があります。

スケーラブルサービスは、2 つのリソースグループを使用します。

「スケーラブルリソースグループ」には、アプリケーションリソースが含まれます。
フェイルオーバーリソースグループには、スケーラブルサービスが依存するネットワークリソース (「共有アドレス」) が含まれます。共有アドレスは、ネットワークアドレスです。このネットワークアドレスは、クラスタ内のノードまたはゾーンのすべてのスケーラブルサービスによってバインドできます。この共有アドレスにより、これらのスケーラブルサービスをノードまたはゾーンに拡張できます。クラスタには複数の共有アドレスを設定することができ、1 つのサービスは、複数の共有アドレスにバインドすることができます。

スケーラブルリソースグループは、同時に複数のノードまたはゾーンでオンラインにできます。その結果、サービスの複数のインスタンスを一度に実行できます。ただし、共有アドレスを使用してノード間のサービス負荷のバランスを取るスケーラブルなリソースグループは、1 つの物理ノード当たり 1 つのゾーンでのみオンラインにできます。スケーラブルなリソースグループはすべて負荷分散を使用します。スケーラブルサービスのホストとなるすべてのノードまたはゾーンは、サービスをホストするための同じ共有アドレスを使用します。共有アドレスのホストとなるフェイルオーバーリソースグループは、一度に 1 つのノードまたはゾーンでしかオンラインにできません。

サービス要求は、単一ネットワークインタフェース (広域インタフェース) を通じてクラスタに入ります。これらの要求は、事前に定義されたいくつかのアルゴリズムの 1 つに基づいてノードまたはゾーンに分配されます。これらのアルゴリズムは「負荷分散ポリシー」によって設定されます。クラスタは、負荷分散ポリシーを使用し、いくつかのノードまたはサービス間でサービス負荷分散をとることができます。ほかの共有アドレスをホストしている異なるノードまたはゾーン上には、複数の広域インタフェースが存在する可能性があります。

スケーラブルサービスの場合、アプリケーションインスタンスはいくつかのノードまたはゾーンで同時に実行されます。広域インタフェースのホストとなるノードまたはゾーンに障害が発生すると、広域インタフェースは別のノードまたはゾーンで処理を続行します。動作していたアプリケーションインスタンスが停止した場合、そのインスタンスは同じノードまたはゾーン上で再起動しようとします。

アプリケーションインスタンスを同じノードまたはゾーンで再起動できず、別の未使用のノードまたはゾーンがサービスを実行するように構成されている場合、サービスはその未使用ノードまたはゾーンで処理を続行します。そうしないと、サービスは残りのノードまたはゾーン上で動作し続け、サービスのスループットが低下することがあります。

注 –

各アプリケーションインスタンスの TCP 状態は、広域インタフェースノードではなく、インスタンスを持つノードで維持されます。したがって、広域インタフェースノードに障害が発生しても接続には影響しません。

図 3–7 に、フェイルオーバーリソースグループとスケーラブルリソースグループの例と、スケーラブルサービスにとってそれらの間にどのような依存関係があるのかを示します。この例は、3 つのリソースグループを示しています。フェイルオーバーリソースグループには、可用性の高い DNS のアプリケーションリソースと、可用性の高い DNS および可用性の高い Apache Web Server (SPARC ベースのクラスタに限って使用可能) の両方から使用されるネットワークリソースが含まれます。スケーラブルリソースグループには、Apache Web Server のアプリケーションインスタンスだけが含まれます。リソースグループの依存関係は、スケーラブルリソースグループとフェイルオーバーリソースグループの間に存在します (実線)。また、Apache アプリケーションリソースはすべて、共有アドレスであるネットワークリソース schost-2 に依存します (破線)。

図 3–7 SPARC: フェイルオーバーリソースグループとスケーラブルリソースグループの例

負荷均衡ポリシー

負荷均衡は、スケーラブルサービスのパフォーマンスを応答時間とスループットの両方の点で向上させます。スケーラブルデータサービスには 2 つのクラスがあります。

pure
sticky

pure サービスでは、任意のインスタンスがクライアント要求に応答できます。sticky サービスでは、クライアントは同じインスタンスに応答を送信できます。これらの要求は、別のインスタンスには変更されません。

pure サービスは、ウェイト設定した (weighted) 負荷均衡ポリシーを使用します。この負荷均衡ポリシーのもとでは、クライアント要求は、デフォルトで、クラスタ内のサーバーインスタンスに一律に分配されます。負荷は指定されたウェイト値に従って各種のノードに分配されます。たとえば、3 ノードクラスタにおいて、各ノードのウェイトが 1 だとします。各ノードは、そのサービスに対する任意のクライアントからの要求を 1/3 ずつを負担します。クラスタ管理者は、管理コマンドまたは Sun Cluster Manager によって、いつでもウェイト値を変更できます。

ウェイト設定した負荷分散ポリシーは、Load_balancing_weights プロパティーに設定された LB_WEIGHTED 値を使用して設定されます。ウェイトがノードについて明示的に設定されていない場合は、デフォルトで 1 が設定されます。

ウェイト設定したポリシーは、一定の割合のクライアントトラフィックを特定ノードに送るためのものです。たとえば、X=「ウエイト」、A=「すべてのアクティブノードの合計ウエイト」であるとします。アクティブノードは、新しい接続数の合計の約 X/A がこのアクティブノード宛てに送られると予測できます。ただし、接続数の合計は十分に大きな数である必要があります。このポリシーは、個々の要求には対応しません。

このウェイト設定したポリシーは、ラウンドロビンではないことに注意してください。ラウンドロビンポリシーでは、常に、同じクライアントからの要求はそれぞれ異なるノードに送られます。たとえば、1 番目の要求はノード 1 に、2 番目の要求はノード 2 に送られます。

sticky サービスには「ordinary sticky」と「wildcard sticky」の 2 種類があります。

sticky サービスを使用すると、内部状態メモリーを共有でき (アプリケーションセッション状態)、複数の TCP 接続でアプリケーションレベルの同時セッションが可能です。

ordinary sticky サービスを使用すると、クライアントは、複数の同時 TCP 接続で状態を共有できます。このクライアントを、単一ポートで待機するサーバーインスタンスに対して「sticky」であるといいます。

次の条件を満たす場合、このクライアントはすべての要求が同じサーバーインスタンスに送られることが保証されます。

インスタンスが動作中でアクセス可能であること。
サービスがオンラインの間、負荷分散ポリシーが変更されないこと。

たとえば、クライアント上の Web ブラウザは、3 つの異なるTCP 接続を使用して、ポート 80 にある共有 IP アドレスに接続します。そして、これらの接続はサービスでキャッシュされたセッション情報をお互いに交換します。

sticky ポリシーを一般化すると、そのポリシーは同じインスタンスの背後でセッション情報を交換する複数のスケーラブルサービスにまで及びます。これらのサービスが同じインスタンスの背後でセッション情報を交換するとき、同じノードで異なるポートと通信する複数のサーバーインスタンスに対して、そのクライアントは「sticky」であるといいます。

たとえば、電子商取引 Web サイトの顧客はポート 80 の HTTP を使用して買い物をします。そして、購入した製品をクレジットカードで支払うときには、ポート 443 の SSL に切り替えて機密データを送ります。

通常の sticky ポリシーでは、ポートの集合が、アプリケーションリソースの構成時に認識されます。このポリシーは、Load_balancing_policy リソースプロパティーの LB_STICKY の値を使用して設定されます。

Wildcard sticky サービスは、動的に割り当てられたポート番号を使用しますが、クライアント要求が同じノードに送りかえされると想定します。クライアントは、同じ IPアドレスを持っているポートに対して「sticky wildcard」であるといいます。

このポリシーの例としては、受動モード FTP があります。たとえば、クライアントはポート 21 の FTP サーバーに接続します。次に、サーバーは、動的ポート範囲のリスナーポートサーバーに接続し直すようにクライアントに指示します。この IP アドレスに対する要求はすべて、サーバーが制御情報によってクライアントに通知した、同じノードに転送されます。

sticky-wildcard ポリシーは、通常の「sticky」ポリシーの上位セットです。IP アドレスによって識別されるスケーラブルサービスでは、ポートはサーバーによって割り当てられます。したがって、事前に認識できません。ポートは変更されることがあります。このポリシーは、Load_balancing_policy リソースプロパティーの LB_STICKY_WILD の値を使用して設定されます。

このような各 sticky ポリシーでは、ウェイト設定した負荷均衡ポリシーがデフォルトで有効です。したがって、クライアントの最初の要求は、負荷均衡によって指定されたインスタンス宛てに送られます。インスタンスが動作しているノードとのアフィニティーをクライアントが確立すると、今後の要求はそのインスタンス宛てに送られます。ただし、そのノードはアクセス可能であり、負荷均衡ポリシーが変更されていない必要があります。

フェイルバック設定

リソースグループは、ノードまたはゾーンから別のノードまたはゾーンへ処理を継続します。このようなフェイルオーバーが発生すると、二次ノードが新しい主ノードになります。フェイルバック設定は、本来の主ノードがオンラインに戻ったときの動作を指定します。つまり、本来の主ノードを再び主ノードにする (フェイルバックする) か、現在の主ノードをそのままにするかです。これを指定するには、Failback リソースグループプロパティー設定を使用します。

リソースグループをホストしていた本来の主ノードまたはゾーンに障害が発生し、繰り返し再起動する場合は、フェイルバックを設定することよって、リソースグループの可用性が低くなる可能性もあります。

データサービス障害モニター

Sun Cluster の各データサービスには、データサービスを定期的に検査してその状態を判断するフォルトモニターがあります。フォルトモニターは、アプリケーションデーモンが動作しているかどうかや、クライアントにサービスが提供されているかどうかを検証します。探索によって得られた情報をもとに、デーモンの再起動やフェイルオーバーの実行などの事前に定義された処置が開始されます。