test

Sun Cluster 3.0 の概念

データサービス

データサービスという用語は、単一サーバーではなくクラスタでの実行用に構成されたアプリケーション (Apache Web Server など) を表します。データサービスには、アプリケーションソフトウェアと、そのアプリケーションの起動、停止、監視を行う Sun Cluster ソフトウェアが含まれます。

Sun Cluster には、クラスタ内のアプリケーションを制御して監視するために使用されるデータサービス方式があります。これらの方式は、クラスタノード上のアプリケーションの起動、停止、および監視にこれらの方式を使用する、リソースグループマネージャー (RGM) の制御のもとで実行されます。これらの方式を、クラスタフレームワークソフトウェアおよび多重ホストディスクとともに使用すると、アプリケーションは可用性の高いデータサービスになります。可用性の高いデータサービスとなったアプリケーションは、クラスタ内で単一の障害が発生した後で起こる深刻なアプリケーション割り込みを防止できます。障害は、ノード、インタフェースコンポーネント、またはアプリケーションそのものに対して発生する可能性があります。

RGM は、アプリケーションとネットワークリソース (論理ホスト名と共有アドレス) のインスタンスを含め、クラスタ内のリソースも管理します。

Sun Cluster には、アプリケーションプログラマが、他のアプリケーションを可用性の高いデータサービスとして Sun Cluster で実行するのに必要なデータサービス方式を開発するための API とデータサービス開発ツールもあります。

リソースグループマネージャー (RGM)

Sun Cluster は、アプリケーションの可用性を高めるか、またはスケーラブルにするための環境を提供します。RGM は、リソースに対して作用します。リソースは、次のいずれかを行える論理コンポーネントです。

RGM は、データサービス (アプリケーション) を、リソースタイプの実装によって管理されるリソースとして制御します。これらの実装は、Sun によって提供されるか、開発者によって、汎用データサービステンプレート、DSDL API (データサービス開発ライブラリ API)、Sun Cluster RMAPI (リソース管理 API) のどれかを使用して作成されます。クラスタ管理者は、リソースグループと呼ばれるコンテナにリソースを作成して管理します。これは、フェイルオーバーとスイッチオーバーの基本ユニットになります。RGM は、クラスタメンバーシップの変更に応じて、指定ノードのリソースグループを停止および開始します。

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

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

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

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

スケーラブルデータサービスは、複数ノードのアクティブインスタンスに対して効果があります。スケーラブルサービスは、スケーラブルリソースグループを使用して、アプリケーションリソースを含め、フェイルオーバーリソースグループを使用して、スケーラブルサービスが依存するネットワークリソース (共有アドレス) を含めます。スケーラブルリソースグループは、複数のノードでオンラインにできるため、サービスの複数のインスタンスを一度に実行できます。共有アドレスのホストとなるフェイルオーバーリソースグループは、一度に 1 つのノードでしかオンラインにできません。スケーラブルサービスのホストとなるすべてのノードは、同じ共有アドレスを使用して、サービスに対するホストとなります。

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

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

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

注 -

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

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

図 3-4 フェイルオーバーリソースグループとスケーラブルリソースグループの例

Graphic

スケーラブルサービスの構造

クラスタネットワーキングの主な目的は、データサービスにスケーラビリティを提供することにあります。スケーラビリティとは、サービスに提供される負荷が増えたときに、新しいノードがクラスタに追加されて新しいサーバーインスタンスが実行されるために、データサービスがこの増加した負荷に対して一定の応答時間を維持できるということを示します。スケーラブルデータサービスの例としては、Web サービスがあります。通常、スケーラブルデータサービスはいくつかのインスタンスからなり、それぞれがクラスタの異なるノードで実行されます。これらのインスタンスはともに、そのサービスの遠隔クライアントの観点から見て 1 つのサービスとして動作し、サービスの機能を実現します。たとえば、いくつかのノードで実行されるいくつかの httpd デーモンからなるスケーラブル Web サービスがあります。どの httpd デーモンもクライアント要求に対応できます。要求に対応するデーモンは、負荷均衡ポリシーによって決められます。クライアントへの応答は、その要求にサービスを提供する特定のデーモンではなく、サービスによるもののようにみえるため、単一サービスの外観が維持されます。

スケーラブルサービスは、次のものからなります。

次の図は、スケーラブルサービスの構造を示しています。

図 3-5 スケーラブルサービスの構造

Graphic

広域インタフェースのホストではないノード (プロキシノード) には、そのループバックインタフェースでホストされる共有アドレスがあります。GIF に入るパケットは、構成可能な負荷均衡ポリシーに基づいて、他のクラスタノードに分配されます。次に、構成できる負荷均衡ポリシーについて説明します。

負荷均衡ポリシー

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

スケーラブルデータサービスには、pure と sticky の 2 つのクラスがあります。pure サービスとは、そのいずれかのインスタンスがクライアント要求に応答できるサービスをいいます。sticky サービスとは、クライアントが同じインスタンスに要求を送るサービスをいいます。これらの要求は、別のインスタンスには変更されません。

pure サービスは、ウェイト設定した (weighted) 負荷均衡ポリシーを使用します。この負荷均衡ポリシーのもとでは、クライアント要求は、デフォルトで、クラスタ内のサーバーインスタンスに一律に分配されます。たとえば、3 ノードクラスタでは、各ノードに 1 のウェイトがあるものと想定します。各ノードは、そのサービスに代わって、クライアントからの要求の 3 分の 1 のサービスを提供します。ウェイトは、scrgadm(1M) コマンドインタフェースを使用し、管理者がいつでも変更できます。

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

ordinary sticky サービスを使用すると、クライアントは、複数の同時 TCP 接続で状態を共有できます。単一ポートを待機しているそのサーバーインスタンスという点で、そのクライアントは sticky であると呼ばれます。クライアントは、インスタンスが起動していてアクセス可能であり、負荷分散ポリシーがサーバーのオンライン時に変更されていなければ、すべての要求が同じサーバーのインスタンスに送られることを保証されます。

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

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

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

wildcard sticky サービスは、動的に割り当てられたポート番号を使用しますが、クライアント要求がやはり同じノードに送られるものと想定します。クライアントは、同じ IP アドレスという点で、ポートに対して sticky wildcard です。

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

これらの各 sticky ポリシーでは、ウェイト設定した (weighted) 負荷均衡ポリシーがデフォルトで有効であるため、クライアントの最初の要求は、負荷均衡によって指定されたインスタンスにリダイレクトされます。インスタンスが実行されているノードとクライアントが関係を確立すると、そのノードがアクセス可能で、負荷分散ポリシーが変更されない限り、今後の要求はそのインスタンスに送られます。

次に、各負荷均衡ポリシーの詳細について説明します。

フェイルバック設定

リソースグループは、ノードからノードへ処理を継続します。リソースグループが処理を別のノードに継続する場合、以前実行していたノードがクラスタに戻ってから、元のノードにフェイルバックするように指定できます。このオプションは、Failback リソースグループプロパティによって設定できます。

特定のインスタンスでは、たとえば、リソースグループをホストする元のノードに障害が生じて繰り返し再起動する場合、フェイルバックを設定すると、リソースグループの可用性が低下することがあります。

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

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