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

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

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

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

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

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

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

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

負荷均衡ポリシー

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

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

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

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

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

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

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

  このポリシーは、ラウンドロビンではないことに注意してください。 ラウンドロビンポリシーでは、クライアントからの各要求が、 最初の要求はノード 1、2 番目の要求はノード 2 といったように常に異なるノードに送られます。

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

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