JP6198737B2 - トラフィックディレクタ環境におけるリソースサーバの動的な発見のためのシステムおよび方法ならびに構成 - Google Patents

Description

著作権表示
この特許文書の開示の一部は、著作権の保護下にある内容を含む。著作権所有者は、特許商標庁の特許ファイルまたはレコードに現れるのであれば、誰でも当該特許文書または特許開示を複製することについて異議はないが、そうでなければ如何なる場合でもすべての著作権を留保する。

優先権主張
この出願は、２０１１年９月２７日に出願された「SYSTEMS AND METHODS FOR USE WITH AN APPLICATION SERVER TRAFFIC DIRECTOR(CORE FEATURES）」という名称の米国仮特許出願番号第６１／５３９，８８６号と、２０１１年９月２７日に出願された「SYSTEMS AND METHODS FOR USE WITH AN APPLICATION SERVER TRAFFIC DIRECTOR(ADMIN FEATURES)」という名称の米国仮特許出願番号第６１／５３９，９００号と、２０１２年８月３１日に出願された「SYSTEM AND METHOD FOR PROVIDING ACTIVE-PASSIVE ROUTING IN A TRAFFIC DIRECTOR ENVIRONMENT」という名称の米国特許出願番号第１３／６０１，０８７号と、２０１２年８月３１日に出願された「SYSTEM AND METHOD FOR SURGE PROTECTION AND RATE ACCELERATION IN A TRAFFIC DIRECTOR ENVIRONMENT」という名称の米国特許出願番号第１３／６０１，４２８号と、２０１２年８月３１日に出願された「SYSTEM AND METHOD FOR DYNAMIC DISCOVERY OF ORIGIN SERVERS IN A TRAFFIC DIRECTOR ENVIRONMENT」という名称の米国特許出願番号第１３／６０１，５３０号と、２０１２年８月３１日に出願された「SYSTEM AND METHOD FOR PROVIDING FLEXIBILITY IN CONFIGURING HTTP LOAD BALANCING IN A TRAFFIC DIRECTOR ENVIRONMENT」という名称の米国特許出願番号第１３／６０１，６３２号と、２０１２年９月２４日に出願された「SYSTEM AND METHOD FOR DYNAMIC CACHE DATA DECOMPRESSION IN A TRAFFIC DIRECTOR ENVIRONMENT」という名称の米国特許出願番号第１３／６２５，７１６号とへの優先権の利益を要求する。その各々の出願は、本願明細書において参照により援用される。

発明の分野
本発明は一般的に、アプリケーションサーバ、ミドルウェアマシンまたは他のコンピュータ環境における使用のためのロードバランサまたはトラフィックディレクタに関し、より特定的には、トラフィックディレクタまたは他の環境においてアクティブ−パッシブルーティング、サージ保護およびレートアクセラレーション、発信元サーバの動的な発見、ｈｔｔｐロードバランシングを構成することにおける柔軟性、および／または動的なキャッシュデータ復元を提供するためのシステムおよび方法に関する。

背景
典型的なエンタープライズレベルのコンピューティング環境は、多くの異なるタイプのコンピューティングリソース（たとえばウェブサーバ、アプリケーションサーバ、データベースサーバ、または他のタイプのリソースサーバ）を含み得る。これらのコンピューティングリソースは、他のコンピュータによってまたはユーザがさまざまな異なるタイプのコンピューティング装置を操作することによってネットワーク（たとえば会社の内部イーサネット（登録商標）ネットワークまたはインターネット）上でアクセスされることが意図される。よく知られる例は、ユーザがインターネットを介してウェブサーバにアクセスし得るウェブブラウザアプリケーションを備えるラップトップのようなクライアントコンピュータの使用である。

今日の組織は、いつでもほとんどどのような位置からでも容易に利用可能な、高いレベルの性能を有するコンピューティングリソースにますます依存している。このようなリソースを確実に効率的に割り当てるタスクはしばしば、その配信ポリシーに従った適性な態様でクライアントからの要求を目標のリソースに配信するようロードバランシング装置の使用を必要とする。これらは、本発明の実施例とともに使用することができるタイプの環境である。

概要
ロードバランサまたはトラフィックディレクタとともに用いられるシステムおよび方法ならびにその管理が本願明細書において記載される。ある実施例に従うと、本願明細書におけるいくつかの実施例において「オラクルトラフィックディレクタ（Oracle Traffic Director（ＯＴＤ））」として言及されるトラフィックディレクタは、ソフトウェアベースのロードバランサとして設けられる。当該ソフトウェアベースのロードバランサは、インターネットおよび他のトラフィックをロードバランシングするために速く、確実で、スケーラブルで、かつ安全なプラットホームをウェブサーバ、アプリケーションサーバ、または他のリソースサーバといったバックエンドの発信元サーバに送達するよう用いられ得る。

トラフィックディレクタの実施例は、Ｏｒａｃｌｅ ＷｅｂＬｏｇｉｃおよびＥｘａｌｏｇｉｃ環境のような、アプリケーションサーバ、ミドルウェアマシン、および同様の高性能なエンタープライズレベルのコンピューティング環境において特に有用である。

ある実施例に従うと、当該システムは、１つ以上のトラフィックディレクタインスタンスを有し、サーバの１つ以上のプールを有する発信元サーバにクライアントからの要求を受け取って通信するよう構成されるトラフィックディレクタを含む。ある実施例に従うと、システムは、要求を受け取る際に発信元サーバによる使用のための通信プロトコルまたはソケットを提供する高速ネットワークインフラストラクチャと、通信プロトコルまたはソケットとの使用のための１つ以上のプロトコルターミネータ／エミュレータと、要求を発信元サーバのうちの特定のものに通信する際にどのターミネータ／エミュレータをトラフィックディレクタが用いるべきかを一緒に示すインバウンドソケット構成およびアウトバンドソケット構成とを含む。

ある実施例に従うと、発信元サーバのプールは、当該プール内のサーバの少なくとも１つ以上がプライマリサーバとして割り当てられるとともに、当該プール内のサーバの少なくとも１つ以上の他のものが、バックアップサーバとして割り当てられるように構成される。トラフィックディレクタは、当該プールにおけるプライマリサーバの可用性を判断し、プールが十分な数の利用可能なプライマリサーバを含む間はプライマリサーバにのみ要求を方向付けするよう構成される。

ある実施例に従うと、トラフィックディレクタにおけるトラフィックモニタが、トラフィックディレクタインスタンスと発信元サーバ内のリソースサーバの１つ以上の間との、接続の数を含むトラフィックを監視する。トラフィックディレクタは、接続の数を含むトラフィックを制御するトラフィックレートをセットし得、サージ保護またはレートの高速化／低速化を提供する。

ある実施例に従うと、ヘルスチェックサブシステムは、当該プール内の発信元サーバとして構成される任意の新しいサーバインスタンスに要求を送り、適切な応答を受け取り、かつそれに従って構成を更新することにより、その構成されるリソースサーバのヘルスを周期的にチェックし、さらに１つ以上のプールにおける変更を検出するよう試みる。

ある実施例に従うと、システムは、要求を受け取る際に発信元サーバによる使用のための通信プロトコルまたはソケットを提供する高速ネットワークインフラストラクチャと、通信プロトコルまたはソケットとの使用のための１つ以上のプロトコルターミネータ／エミュレータと、要求を発信元サーバのうちの特定のものに通信する際にどのターミネータ／エミュレータをトラフィックディレクタが用いるべきかを一緒に示すインバウンドソケット構成およびアウトバンドソケット構成とを含む。

ある実施例に従うと、トラフィックディレクタは、そのキャッシュに格納されるデータを圧縮し、発信元サーバからのコンテンツを圧縮データとして提供することによってか、または特定のクライアントがデータの非圧縮のバリアントを受け取ることを望む場合は、提供の前に当該データを動的に復元することによってクライアントからの要求に応答するよう構成され得る。ある実施例に従うと、トラフィックディレクタは、さらにそのデータ圧縮および復元の性能を向上するよう、ハードウェア支援圧縮プリミティブを使用するよう構成され得る。

ある実施例に従った、ロードバランサまたはトラフィックディレクタを含むコンピュータ環境を示す図である。 ある実施例に従った、１つ以上のプールまたは発信元サーバとのトラフィックディレクタの使用を示す図である。 ある実施例に従ったトラフィックディレクタアーキテクチャを示す図である。 ある実施例に従ったトラフィックディレクタ管理環境およびインターフェイスを示す図である。 ある実施例に従ったトラフィックディレクタにおけるアクティブ／パッシブルーティングの使用を示す図である。 ある実施例に従ったトラフィックディレクタにおけるアクティブ／パッシブルーティングの使用をさらに示す図である。 ある実施例に従ったトラフィックディレクタにおいてアクティブ／パッシブルーティングを提供するための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタにおけるサージ保護の使用を示す図である。 ある実施例に従ったトラフィックディレクタにおけるレートの高速化の使用を示す図である。 ある実施例に従ったトラフィックディレクタにおけるサージ保護を提供するための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタにおけるレートの高速化を提供するための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタにおける発信元サーバの動的な発見を示す図である。 ある実施例に従ったトラフィックディレクタにおける発信元サーバの動的な発見をさらに示す図である。 ある実施例に従ったトラフィックディレクタにおける発信元サーバの動的な発見を提供するための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタにおける発信元サーバの動的な発見を提供するための別の方法のフローチャートである。 ある実施例に従ったトラフィックディレクタの使用を示す図である。 ある実施例に従ったトラフィックディレクタを用いるための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタ環境における動的なＨＴＴＰ復元の使用を示す図である。 ある実施例に従ったトラフィックディレクタ環境において動的なＨＴＴＰ復元を提供するための方法のフローチャートである。 ある実施例に従ったトラフィックディレクタ環境における動的なＨＴＴＰ復元との使用のためのハードウェアプリミティブのためのサポートを示す図である。

詳細な説明
上述したように、今日の組織は、いつでもほとんどどのような位置からでも容易に利用可能な、高いレベルの性能を有するコンピューティングリソースにますます依存している。このようなリソースを確実に効率的に割り当てるタスクはしばしば、その配信ポリシーに従った適性な態様でクライアントからの要求を目標のリソースに配信するようロードバランシング装置の使用を必要とする。

ロードバランサまたはトラフィックディレクタとともに用いられるシステムおよび方法とその管理とが本願明細書において記載される。ある実施例に従うと、本願明細書のいくつかの実施例において「オラクルトラフィックディレクタ（Oracle Traffic Director（ＯＴＤ））」として言及されるトラフィックディレクタは、ソフトウェアベースのロードバランサとして設けられる。当該ソフトウェアベースのロードバランサは、インターネットおよび他のトラフィックをロードバランシングするために速く、確実で、スケーラブルで、かつ安全なプラットホームをウェブサーバ、アプリケーションサーバ、または他のリソースサーバといったバックエンドの発信元サーバに送達するよう用いられ得る。

トラフィックディレクタの実施例は、Ｏｒａｃｌｅ ＷｅｂＬｏｇｉｃおよびＥｘａｌｏｇｉｃ環境のような、アプリケーションサーバ、ミドルウェアマシン、および同様の高性能なエンタープライズレベルのコンピューティング環境において特に有用である。

ある実施例に従うと、トラフィックディレクタは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）およびハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）要求のようなトラフィックのためのエントリポイントとして機能する。ハイパーテキスト転送プロトコル（ＨＴＴＰ）およびハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）要求は、リソースまたは発信元サーバとして作用するリソースサーバのバックエンドへの通信のためにクライアントまたはクライアントデバイスから受け取られる。各トラフィックディレクタは、リスナー、発信元サーバ、フェイルオーバグループ、およびログのようなインスタンスのさまざまな要素についての情報を提供する構成によって規定される１つ以上のトラフィックディレクタインスタンスを含む。

システムとともに用いられ得るタイプのクライアントの例は、コンピュータサーバ、ラップトップコンピュータ、スマートフォンのようなポータブルデバイス、および他のタイプのコンピューティング装置を含む。そのいくつかはたとえば、ウェブサーバにアクセスするためのウェブブラウザアプリケーションを含んでもよい。

発信元サーバとして用いられ得るタイプのリソースの例は、軽量ディレクトリアクセスプロトコル（lightweight directory access protocol（ＬＤＡＰ））サーバ、ウェブサーバ、マルチメディアサーバ、アプリケーションサーバ、データベースサーバ、および他のタイプのリソースを含む。

ある実施例に従うと、トラフィックディレクタは、１つ以上のロードバランシング方法に基づき発信元サーバへの要求を配信すること、特定されたルールに基づき要求をルーティングすること、頻繁にアクセスされたデータをキャッシュすること、トラフィックに優先順位を付けること、およびサービス品質を制御することといったタスクを行い得る。

性能の観点から、実施例に従うと、トラフィックディレクタは、低いレイテンシーで大量のトラフィックを扱うことを可能にするアーキテクチャを含み得る。たとえば、実施例は、たとえばOracle Exalogic Elastic Cloudのような高性能なコンピューティング環境内での使用に最適化され得るか、またはたとえばインフィニバンドのような高性能通信ファブリックを用いるバックエンドにて発信元サーバと通信し得る。ある実施例に従うと、高い可用性をサポートするために、トラフィックディレクタは、アクティブ―パッシブまたはアクティブーアクティブフェイルオーバを提供するトラフィックディレクタインスタンスのフェイルオーバグループを認識し得る。ネットワークへのトラフィック量が増加すると、トラフィックディレクタ環境は、要求をルーティングし得る付加的なバックエンドサーバでトラフィックディレクタを再構成するかまたはトラフィックが通信されるレートを修正することによりスケーリングされ得る。

管理の観点から、ある実施例に従うと、トラフィックディレクタはインストール、構成、および使用が容易であるよう設計されており、トラフィックディレクタインスタンスを管理する際のアドミニストレータによる使用のために、シンプルなウィザードドリブンのグラフィカルインターフェイスと、堅牢なコマンドラインインターフェイスとを含み得る。任意の特定の組織の場合、トラフィックディレクタを用いて要求をバランスしたいバックエンドアプリケーションの数と、セキュリティなどの内部要求と、使用したいトラフィックディレクタ機能といったビジネス要件に依存して、トラフィックディレクタトポロジーが当該組織のニーズに対応するよう変動され得る。たとえば、シンプルなトラフィックディレクタトポロジーはまず、専用のコンピューティングノード上で実行されるとともにバックエンドのサーバのプールにクライアント要求を配信する単一のトラフィックディレクタインスタンスを用い得る。シングルポイント障害を回避するために、アドミニストレータは、異なるノード上で実行されるとともにアクティブ―パッシブフェイルオーバーペアを形成する２つの同種のトラフィックディレクタインスタンスを構成し得る。リソースの活用を改善するために、アドミニストレータは、２つの仮想ＩＰアドレスを用いてアクティブ―アクティブモードにおける２つのトラフィックディレクタインスタンスを構成し得る。

用語集
ある実施例に従うと、以下の用語が本願明細書において使用される。他の実施例に従うと、付加的および／または異なる用語が用いられ得るということが明らかであろう。
「構成」：トラフィックディレクタインスタンスのランタイム挙動を決定する構成可能な要素（たとえばメタデータ）の集合。ある実施例に従うと、典型的な構成は、トラフィックディレクタが要求をリッスンするべきリスナー（たとえばＩＰアドレスおよびポートの組合せ）についての定義と、要求が送られるべきバックエンドでのサーバについての情報とを含む。トラフィックディレクタは、トラフィックディレクタインスタンスが開始するとともにクライアント要求を処理する間に当該構成を読み出し得る。
「インスタンス（トラフィックディレクタインスタンス）」：構成からインスタンス化されるとともに管理ノードまたは管理サーバ上で展開されるトラフィックディレクタサーバ。
「クラスタ」：同じ構成から作製される２つ以上のトラフィックディレクタインスタンスの集合。
「フェイルオーバグループ」：仮想ＩＰアドレス（ＶＩＰ）によってグループ化された２つ以上のトラフィックディレクタインスタンス。ある実施例に従うと、フェイルオーバグループは、アクティブ―パッシブモードにおいて高い可用性を提供する。要求は、ＶＩＰにて受け取られるとともにプライマリインスタンスとして指定されるインスタンスにルーティングされる。プライマリインスタンスが到達可能でなければ、要求はバックアップインスタンスにルーティングされる。ある実施例に従うと、アクティブ―アクティブフェイルオーバについて、２つのフェイルオーバグループが必要とされる。各フェイルオーバグループは、一意のＶＩＰを有するが、両者は、プライマリの役割とバックアップの役割とが反転された同じノードを含む。フェイルオーバグループにおける各インスタンスは、１つのＶＩＰについてプライマリインスタンスとして指定され、他のＶＩＰについてバックアップとして指定される。
「管理サーバ」：アドミニストレータがトラフィックディレクタ構成を作り出し得る管理コンソールおよびコマンドラインインターフェイスを含むインターフェイスをホスティングする特別に構成されるトラフィックディレクタインスタンスは、管理ノードに対するインスタンスとして展開し、インスタンスを管理する。
「管理ノード」：アドミニストレータがトラフィックディレクタインスタンスを展開し得るホストとして指定される物理的なサーバ。実施例に従うと、所与のノード上で、アドミニストレータは、ある構成の１つのみのインスタンスを展開し得る。
「ＩＮＳＴＡＮＣＥ＿ＨＯＭＥ」：トラフィックディレクタインスタンスに関する構成データおよびバイナリファイルが保存される、管理サーバまたは管理ノード上のアドミニストレータの選択のディレクトリ。
「ＯＲＡＣＬＥ＿ＨＯＭＥ」：アドミニストレータがトラフィックディレクタバイナリをインストールするアドミニストレータの選択のディレクトリ。
「管理コンソール」：アドミニストレータがトラフィックディレクタインスタンスを作成、配置、および管理するよう用い得る管理サーバ上のウェブベースのグラフィカルインターフェイス。
「クライアント」：ある実施例に従うと、要求（たとえばＨＴＴＰおよびＨＴＴＰＳ要求）をトラフィックディレクタインスタンスに送るエージェント（たとえばウェブブラウザまたはアプリケーション）。当該システムとともに用いられ得るタイプのクライアントの例は、コンピュータサーバ、ラップトップコンピュータ、スマートフォンのようなポータブルデバイス、および他のタイプのコンピューティング装置を含む。当該他のタイプのコンピューティング装置のいくつかは、たとえばウェブサーバにアクセスするためのウェブブラウザアプリケーションを含んでもよい。
「発信元サーバ」：ある実施例に従うと、トラフィックディレクタがクライアントから受け取った要求をそこに転送するとともに、クライアント要求への応答をそこから受け取る、バックエンドのリソースまたはサーバ。発信元サーバとして用いられ得るタイプのリソースの例は、軽量ディレクトリアクセスプロトコル（ＬＤＡＰ）サーバ、ウェブサーバ、マルチメディアサーバ、アプリケーションサーバ、データベースサーバ、および他のタイプのリソースを含む。
「発信元サーバプール」：同じアプリケーションまたはサービスをホスティングするとともに、トラフィックディレクタを用いることによりアドミニストレータがロードバランスし得る発信元サーバの集合。ある実施例に従うと、トラフィックディレクタは、プールについて特定されるロード分散方法に基づき、クライアント要求を発信元サーバプールにおけるサーバに配信する。
「仮想サーバ」：トラフィックディレクタが１つ以上のドメインについての要求を供給し得る一意のＩＰアドレス（またはホスト名）およびポートの組合せを提供する、トラフィックディレクタサーバインスタンス内の仮想のエンティティ。ある実施例に従うと、ノード上のトラフィックディレクタインスタンスは複数の仮想サーバを含み得る。アドミニストレータは、各仮想サーバに特定の入力接続の最大数のような設定を構成し得るとともに各仮想サーバが要求をどのように扱うかをカスタマイズし得る。

図１は、ある実施例に従った、ロードバランサまたはトラフィックディレクタを含むコンピューティング環境を示す。図１に示されるように、ある実施例に従うと、トラフィックディレクタ１００（本願明細書のいくつかの実施例においてオラクルトラフィックディレクタ（Oracle Traffic Director（ＯＴＤ））として言及される）は、１つ以上の物理的なコンピュータサーバ１０１（またはプロセッサ（ＣＰＵ）、メモリ、およびストレージを含む同様のコンピューティング装置）上に配置され、１つ以上のトラフィックディレクタインスタンス１０２，１０４を含み得る。トラフィックディレクタインスタンス１０２，１０４は、高い可用性のハートビートまたは類似の手段１０６を用いて互いに通信し得る。

任意の特定の組織の場合、トラフィックディレクタを用いて要求をバランスしたいバックエンドアプリケーションの数、セキュリティなどの内部要求、使用したいトラフィックディレクタ機能といったビジネス要件に依存して、トラフィックディレクタトポロジーが当該組織のニーズに対応するよう変動され得る。バックエンドは１つ以上の発信元サーバ１１０を含み得る。その例は、ＬＤＡＰサーバ１１４、ウェブサーバ１１８、マルチメディアサーバ１２２、アプリケーションサーバ１２６、およびデータベースサーバ１２８を含み得る。ある実施例に従うと、アプリケーションサーバはＷｅｂＬｏｇｉｃサーバ（ＷＬＳ）であり得る。他のタイプの発信元サーバおよびアプリケーションサーバが組織の特定の必要性に依存して用いられ得る。発信元サーバの各々は、イーサネットネットワークのような内部ネットワーク１３０を介して、互いにかつトラフィックディレクタと通信し得る。

ある実施例に従うと、トラフィックディレクタは、外部ネットワーク１３６と、インターネット１３８と、多くの組織の場合ファイアウォール１３９とを介してクライアント１３４から要求を受け取り得る。当該システムとともに用いられ得るタイプのクライアントの例は、コンピュータサーバ、ラップトップコンピュータ、スマートフォンのようなポータブルデバイス、および他のタイプのコンピューティング装置を含む。当該他のタイプのコンピューティング装置のいくつかは、たとえばウェブサーバにアクセスするためのウェブブラウザアプリケーションを含んでもよい。

図２は、ある実施例に従った、１つ以上のプールまたは発信元サーバを有するトラフィックディレクタの使用を示す。図２に示される例において、トラフィックディレクタは、ここではＡ１７２、Ｂ１７４、Ｃ１７６、Ｄ１７８として示される４つのアプリケーションサーバを有するアプリケーションサーバの（第１の）プール１７０と、ここではＡ１８２、Ｂ１８４、Ｃ１８６として示される３つのウェブサーバを有するウェブサーバの（第２の）プール１８０とを含む２つのプールとともに用いられる。他の実施例および例に従うと、組織の特定の必要性に依存して、他のタイプおよび他の数のプールおよびサーバが用いられ得る。

図２に示される例において、トポロジーは、アクティブ―パッシブフェイルオーバグループ１５０を形成するとともにクライアント要求の受け取りのための単一の仮想ＩＰアドレス１９０を含む２つのトラフィックディレクタインスタンス（１０２および１０４）を含む。アクティブインスタンス（この例ではインスタンス１０２）は、要求１９０，１９２，１９４を受け取ると、当該プールについて特定されるロード分散方法に基づき、要求が送られるべきサーバプールを決定し、要求１９７，１９８を当該プールにおけるサーバの１つに転送する。

図２に示される例は、バックエンドでの２つのサーバプールの使用を示しているが、アドミニストレータは、要求を複数のプールにおけるサーバにルーティングするようトラフィックディレクタを構成し得る。図２に示されるアクティブ―パッシブセットアップにおいて、フェイルオーバグループにおける１つのノードは任意の時点において冗長である。ある実施例に従うと、リソースの活用を改善するために、アドミニストレータは、２つの仮想ＩＰアドレスを用いてアクティブ−アクティブモードにおける２つのトラフィックディレクタインスタンスを構成し得る。この場合、各インスタンスは、１つの仮想ＩＰアドレス上で受け取られる要求に応え、他のインスタンスをバックアップする。

図３は、ある実施例に従ったトラフィックディレクタアーキテクチャを示す。ある実施例に従うと、トラフィックディレクタは、低いレイテンシーで大量のトラフィックを扱うことを可能にするアーキテクチャを含み得る。実施例はさらに、高性能のコンピューティング環境における使用のために最適化され得るか、または高性能の通信ファブリックを用いてバックエンドの発信元サーバと通信し得る。

図３に示されるように、ある実施例に従うと、トラフィックディレクタは、１つ以上のネットスケープポータブルランタイム（ＮＳＰＲ）レイヤー２０２と、ネットワークセキュリティサービス（ＮＳＳ）レイヤー２０６とを含み得る。ある実施例に従うと、トラフィックディレクタはさらに、１つ以上のアクセス制御２１２、ログ２１４、ＨＴＴＰ圧縮２１６、Ｉ／Ｏフィルタ２１８、エラー処理２２０、レート調整２２２、侵入検出２２４、または他のコンポーネントを有するＨＴＴＰエンジン２１０と、１つ以上のｈｔｔｐクライアント２３２、応答クライアント２３４、ヘルスチェック２３６、ルーティングポリシー２３８、ロード制御２４０、ロードバランサ２４４、ＷＬＳサポート２４６、スティッキールーティング２４８、または他のコンポーネントを有するリバースプロキシコンポーネント２３０とを含み得る。ある実施例に従うと、トラフィックディレクタは、１つ以上のａｃｃｅｐｔｏｒスレッド２５２、ｗｏｒｋｅｒスレッド２５４、ｋｅｅｐ−ａｌｉｖｅスレッド２５６、または他のコンポーネントを有するＨＴＴＰ接続ハンドラ２５０をさらに含み得る。ある実施例に従うと、トラフィックディレクタはさらに、１つ以上のＴＣＰスレッド２６２、ロードバランサ２６４、または他のコンポーネントを有するＴＣＰ接続ハンドラ２６０を含む。ある実施例に従うと、トラフィックディレクタはさらに、１つ以上のイベントスケジュール２７０、動的構成２７２、監視２７４、または他のコンポーネントを含み得る。

他の実施例に従うと、付加的および／または異なるコンポーネントが用いられ得るということが明らかであろう。

図４は、ある実施例に従ったトラフィックディレクタ管理環境およびインターフェイスを示す。管理の観点から、トラフィックディレクタはインストール、構成、および使用が容易であるよう設計されており、トラフィックディレクタインスタンスを管理する際のアドミニストレータによる使用のために、シンプルなウィザードドリブンのグラフィカルインターフェイスと、堅牢なコマンドラインインターフェイスとを含み得る。図４に示されるように、ある実施例に従うと、トラフィックディレクタは、１つ以上のトラフィックディレクタインスタンス２８０，２８１，２８２を含み得る。インスタンスの少なくとも１つは、管理サーバ（２８０）として指定され、他のインスタンスは管理ノード（２８１，２８２）として指定される。

ある実施例に従うと、管理環境２８４は、管理インターフェイス２８５を含む。管理インターフェイス２８５は、管理コンソール（ＧＵＩ）２８６および／またはコマンドラインインターフェイス２８８の１つ以上を含む。これにより、アドミニストレータ２９０が２９２にてトラフィックディレクタまたはそのインスタンス２９４，２９６を構成またはそうでなければ管理することを可能にする。

アクティブ−パッシブルーティング
いくつかのアクティブ／パッシブルーティング方法では、ロードバランサがプライマリ（すなわちアクティブ）クラスタとしてサーバの第１のクラスタを維持し、バックアップ（すなわちパッシブ）クラスタとしてサーバの別のクラスタを維持する。これは障害復旧状況において有用であり、これによりプライマリデータセンタがダウンした場合、トラフィックは自動的にバックアップデータセンタにルーティングされる。ある実施例に従うと、トラフィックディレクタは、トラフィックディレクタがアクティブノードのすべてがダウンした後にのみバックアップノードをピックアップする微妙に異なるアプローチを取る。

ある実施例に従うと、サーバプール内では、発信元サーバのいくつかはプライマリサーバとして特定され得る一方、他の発信元サーバはバックアップサーバとして特定され得る。トラフィックディレクタは、少なくとも１つのプライマリサーバが利用可能である場合に、非バックアップサーバに（すなわちプライマリサーバ）に要求をルーティングすることになる。しかしながら、プライマリサーバが利用可能でなければ、トラフィックディレクタは当該要求をプールにおけるバックアップサーバにルーティングすることになる。任意のプライマリサーバが再び利用可能になると、トラフィックディレクタは要求をバックアップサーバに送ることを停止し、その後の要求をプライマリサーバにルーティングする。

図５は、ある実施例に従ったトラフィックディレクタにおけるアクティブ／パッシブルーティングの使用を示す。図５に示されるように、アクティブ／パッシブ環境は、要求を発信元サーバ３４６にルーティングするのに使用するために、１つ以上のトラフィックディレクタインスタンス３４２を有するトラフィックディレクタ３４０を含み得る。発信元サーバは、サーバの１つ以上のプール（ここではプールＡ３４８およびプールＢ３５４として示される）として構成され得る。各プールは、１つ以上のプライマリサーバ３５０，３５７、および１つ以上のバックアップサーバ３５６，３５８とを有する。

図５に示されるように、トラフィックディレクタは、任意の特定のプール（たとえばプールＡ）について、少なくとも１つのプライマリサーバが当該プールにおいて利用可能であれば、元々トラフィックディレクタが要求３４４を非バックアップサーバ（すなわちプライマリサーバ）にルーティングし、要求をバックアップサーバ（説明のためここでは斜線が付けられる）にルーティングしないように構成され得る。

ある実施例に従うと、ある期間の後、１つ以上のプライマリサーバはおそらく障害により利用不可能となり得るが、トラフィックディレクタは、少なくとも１つのプライマリサーバが利用可能であれば、要求３６０を当該プールにおけるプライマリサーバにルーティングし続けるのみである。

別の期間の後、ある実施例に従うと、当該プールにおけるプライマリサーバのすべてが利用不可能になると、トラフィックディレクタは、要求３６４を当該プールにおけるバックアップサーバにルーティングする。

図６はさらに、ある実施例に従ったトラフィックディレクタにおけるアクティブ／パッシブルーティングの使用を示す。図６に示されるように、当該プールにおけるプライマリサーバのすべてが未だ利用不可能であれば、トラフィックディレクタは、要求３６６を当該プールにおけるバックアップサーバにルーティングし続ける。

プライマリサーバ３６８が再び利用可能になると、当該構成に依存して、トラフィックサーバは、トラフィックを（新しいまたはそうでなければ現在利用可能な）プライマリサーバに転送を開始する前に、ある期間の間、遅延し得る。この場合、トラフィックディレクタは、ある期間の間、要求をバックアップサーバに３７０にてルーティングし続け、まだ要求をプライマリサーバ（ここでは説明のために斜線が付けられる）にルーティングしない。

その後、少なくとも１つのプライマリサーバが再び完全に利用可能になると、トラフィックディレクタは再び、要求３７４を非バックアップサーバ（すなわちプライマリサーバ）にのみルーティングし、少なくとも１つのプライマリサーバが利用可能であれば、要求をバックアップサーバにルーティングしない。

ある実施例に従うと、スティッキールーティングが構成される場合、プライマリサーバが利用不可能になれば、サーバに対してスティッキーなすべてのその後の要求が拒否されないことになるが、プライマリサーバが利用可能でなければ他のプライマリサーバまたはバックアップサーバにルーティングされることになる。移行先の発信元サーバはスティッキー要求について格納されるセッション情報を有し得ないので、この場合セッションはおそらく不良になる。しかしながら、新しい供給サーバは、送り手にチャレンジを送信し、それらのスティッキー要求について新しいセッションを確立する。バックアップサーバは、すべてのプライマリサーバが利用可能でない場合のみ、ルーティングのために用いられることになる。

ある実施例に従うと、トラフィックディレクタとの使用のためにアクティブ／パッシブルーティングを構成するよう、「backup-server」と呼ばれる要素が、バックアップサーバを特定するためにserver.xmlファイルにおける＜origin-server＞という要素に加えられ得る。そのパラメータおよび例は、テーブル１およびリスティング１においてそれぞれ提供される。

図７は、ある実施例に従ったトラフィックディレクタにおいてアクティブ／パッシブルーティングを提供するための方法のフローチャートである。図７に示されるように、ステップ３８０では、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、サーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が提供される。ステップ３８２では、１つ以上のプライマリサーバおよび１つ以上のバックアップサーバが、アクティブ／パッシブ構成においてプールに割り当てられる。ステップ３８４では、トラフィックディレクタは、プールにおけるプライマリサーバの可用性を判断し、プールが十分な数の利用可能なプライマリサーバを含む間は、要求をプライマリサーバにのみ方向付ける。ある実施例に従うと、トラフィックディレクタは、少なくとも１つのプライマリサーバが利用可能であれば、非バックアップサーバ（すなわちプライマリサーバ）にのみ要求をルーティングする。ステップ３８６では、当該プールにおいてプライマリサーバの数が不十分である（ある実施例に従うと１未満、すなわちプライマリサーバが存在しない）場合、トラフィックディレクタは、上記数のプライマリサーバが再び利用可能になるまで、要求をプールにおけるバックアップサーバに方向付ける。その点において、当該構成に依存して、トラフィックディレクタは再び、プールが十分な数のサーバを含む間にプライマリサーバにのみ要求を方向付け得る。

サージ保護
ロードバランサは、たとえば発信元サーバへのトラフィックの予期しないサージによって引き起こされていたであろうサーバの停止を防止することを補助し得る。ある実施例に従うと、トラフィックディレクタは、トラフィックがあるサージ限界を超えないように、発信元サーバへのトラフィックを監視するとともに必要に応じて接続をキューに入れることによってサージ保護のインテリジェントフォームを提供する。

ある実施例に従うと、サージ保護が有効にされると、トラフィックディレクタは、構成されるキャパシティよりも多くのサーバへの同時接続を開かない。この限界または最大キャパシティは、＜max-connections＞という要素によって特定され得る。発信元サーバがその最大接続キャパシティに到達すると、新しい接続を要求する要求が、その既存の接続のいくつかが解放されるまで、このサーバにルーティングされない。すべての発信元サーバが自身の接続キャパシティに到達した場合、新しい接続を必要とするその後の要求は拒否され、エラーメッセージが送られる。

図８は、ある実施例に従ったトラフィックディレクタにおけるサージ保護の使用を示す。図８に示されるように、１つ以上のトラフィックディレクタインスタンス４０２を有するトラフィックディレクタ４００と、サーバ４２２の１つ以上のプールを有する発信元サーバ４２０とを含むトラフィックディレクタ環境が提供される。サーバの各プールは、１つ以上のリソースサーバ４２４を含み得る。

ある実施例に従うと、トラフィックディレクタはトラフィックモニタ４０４を含む。トラフィックモニタ４０４は、トラフィックディレクタが、発信元サーバ内のトラフィックディレクタインスタンスとリソースサーバの１つ以上との間の、接続の数４０６を含むトラフィックを監視することを可能にする。ある実施例に従うと、トラフィックディレクタはさらに、接続をキューに入れるよう用いられ得る接続キュー４０８を含む。

動作中、クライアントからの要求が発信元サーバに通信されている間、トラフィックモニタは、トラフィックディレクタとリソースサーバとの間の、接続の数を含むトラフィックを示すフィードバック４３０を受け取る。トラフィックモニタが、トラフィックディレクタと特定のリソースサーバとの間の、接続の数を含むトラフィックが当該リソースサーバについて可能とされる最大量を超えると判断すると、トラフィックディレクタは、その後のトラフィックおよび接続をリソースサーバから離れるよう接続キュー４３４に一時的に方向付け得る。これには、当該リソースサーバに流れるトラフィックの量を４３６にて一時的に低減または制限する効果がある。

ある実施例に従うと、トラフィックディレクタは、４４０にて情報メッセージ４４２をたとえばログファイルまたはアドミニストレータに随意に提供し得、これによりこれらにトラフィックサージを知らせて、処置が取られる。トラフィックモニタは必要に応じて、接続キューへのその後の調節のために、発信元サーバへのトラフィック／接続を監視し続け得る。

レート調整（高速化／低速化）
ある実施例に従うと、トラフィックディレクタはさらに、要求レートの高速化をサポートする。これにより、大量のトラフィックでそれらのサーバを圧倒しないように、新しく加えられたサーバへのトラフィックを徐々に加速することによって、発信元サーバプールへのサーバの適切な追加が可能になる。要求レートの高速化は、アクティブな接続の数または現在の負荷、接続の最大数または発信元サーバのキャパシティのような多くの動的に監視されるパラメータを組み込み得るので、適応可能である。この機能は、要求−レートの低速化を提供するよう拡張され得、これによりトラフィックディレクタは、発信元サーバに方向付けられるトラフィックを効果的に減少させ得るので、そのトラフィックがたとえば計画保守の目的のために完全に休止される際に、アドミニストレータが発信元サーバをオフラインにし得る。一緒に、レートの高速化および低速化の両方が、発信元サーバへのトラフィックのレートを調節するよう用いられ得る。

ある実施例に従うと、発信元サーバがオンラインになると、トラフィックディレクタはその全キャパシティで直ちに要求をサーバに送らず、ある期間に亘って送信レートを徐々に増すことになる。これは、以下のいくつかの利点を提供し得る。たとえば、発信元サーバは、スタートアップの際、データをロードしてさまざまなリソースを割り当てるある期間を必要とする。このウォームアッププロセスの間、発信元サーバの応答時間は遅くなり得、多数の要求をサーバに送ることで、サーバ性能をさらに悪化させ、サーバの予期しない挙動を引き起こし得る。さらに、発信元サーバは、問題があれば、要求のいくつかまたはほとんどに応答する際に機能しなくなり得、その状態は、「ＵＰ」状態と「ＤＯＷＮ」状態との間で頻繁に変更し得る。このようなサーバの場合、その「ＵＰ」状態の開始時に多くの要求を当該サーバに送らないほうがよい。さらに、リースト・コネクション・カウント(least connection count)のようなロードバランシングアルゴリズムを用いる場合、トラフィックディレクタは、多くの要求を新しいサーバに送り得、開始時においてサーバに多くの要求が殺到し得る。なぜならば新しいサーバの接続数が０だからである。レート高速化により、この問題が緩和し得る。

ある実施例に従って、トラフィックディレクタは、当該レートがサーバの構成される最大レート（最大接続）に到達するまで、新しいサーバへのトラフィックレートを徐々に増加させる。レート高速化は、接続キャパシティの調節を介して達成され得、キャパシティの調節は、時間ベース（すなわち単位時間について固定された値だけ接続キャパシティを増加する）またはウィンドウベース（すなわちある数の応答を受け取った後で、ある値だけ接続キャパシティを増加する）かのいずれかであり得る。

図９は、ある実施例に従ったトラフィックディレクタにおけるレート高速化の使用を示す。図９に示されるように、１つ以上のトラフィックディレクタインスタンス４５２を有するトラフィックディレクタ４５０と、サーバ４７２の１つ以上のプールを有する発信元サーバ４７０とを含むトラフィックディレクタ環境が再び設けられる。サーバの各プールは、１つ以上の（既存の）リソースサーバ４７４を含み得る。トラフィックディレクタはまた、トラフィックディレクタが、トラフィックディレクタインスタンスと発信元サーバ内のリソースサーバの１つ以上との間の、接続の数４５６を含むトラフィックを監視することを可能にするトラフィックモニタ４５４を含む。

ある実施例に従うと、トラフィックディレクタは最初に、トラフィックディレクタインスタンスと発信元サーバ内の１つ以上の（既存の）リソースサーバとの間の、接続の数４７６を含むトラフィックを制御するトラフィックレート４５８をセットし得る。

その後、トラフィックモニタは、トラフィックディレクタがトラフィックを方向付け得る発信元サーバ内の付加的な（新しい）リソースサーバ４８０の存在４８１を判断すると、ある期間の間、待機し得、いくつかの場合ではトラフィックをその初期レート４８２に維持してから、トラフィックレート４８４を徐々に調整または調節してトラフィックディレクタインスタンスとそれらの新しいリソースサーバ４８６との間のトラフィック／接続を方向付ける。

要求レート調整（高速化／低速化）は、上記のサージ保護機能とは異なる。すなわち、両方のメカニズムは、要求トラフィックを制限するよう用いられ得るが、異なる基準に基づいている。特に、レート調整は、要求のプロパティに基づき制限動作を取り、サージ保護は発信元サーバへの同時接続の量に一次的に基づく。

ある実施例に従うと、接続キャパシティ調節のための時間ベースの方法と、「上昇時間」と呼ばれる構成パラメータとが用いられ得る。これにより、トラフィックディレクタがサーバの構成されたキャパシティまで送信レートを上昇させるのにどれだけ長くかかるかを特定する。
Adjusted-Connection-Capacity = MAX{(max-connections * MIN{1, server-up-time/ramp-up-time}), 1}

要求レート高速化が有効にされると、構成されるハード限界（最大接続）の代わりに、調節されたキャパシティが、ルーティングの決定を行うよう、トラフィックディレクタによって用いられ得る。上述したように、すべてのサーバが調節された接続キャパシティに到達するならば、新しい要求が拒否されることになる。

実施例に従うと、サージ保護と要求レート高速化とをトラフィックディレクタとの使用のために構成するために、「max-connections」という要素および「ramp-up-time」という要素が、所望のリソースサーバについてのserver.xmlファイルにおける<origin-server>という要素に加えられ得る。そのパラメータおよび例は、テーブル２およびリスティング２にそれぞれ提供される。

図１０は、ある実施例に従った、トラフィックディレクタにおいてサージ保護を提供するための方法のフローチャートである。図１０に示されるように、ステップ４９０では、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、サーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が提供される。ステップ４９２では、トラフィックディレクタにおけるトラフィックモニタは、トラフィックディレクタインスタンスと発信元サーバ内の１つ以上のリソースサーバとの間の、接続の数を含むトラフィックを監視する。ステップ４９４では、トラフィックモニタが、トラフィックディレクタと特定のリソースサーバとの間の、接続の数を含むトラフィックが当該リソースサーバについて可能とされる最大量を超えると判断すると、トラフィックディレクタは、その後のトラフィックおよび接続をリソースサーバから離れるよう接続キューに一時的に方向付ける。ステップ４９６では、トラフィックディレクタは、トラフィックサージを通知するよう、たとえばログファイルまたはアドミニストレータに情報メッセージを随意に提供し得、必要に応じて、接続キューへのその後の調節のために、発信元サーバへのトラフィック／接続を監視し続ける。

図１１は、ある実施例に従ったトラフィックディレクタにおいてレート高速化を提供するための方法のフローチャートである。図１１に示されるように、ステップ５０２では、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、サーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が再び提供される。ステップ５０４では、トラフィックモニタからの情報を用いてトラフィックディレクタは、トラフィックディレクタインスタンスと発信元サーバ内の１つ以上の（既存の）リソースサーバとの間の、接続の数を含むトラフィックを最初に制御するトラフィックレートをセットし得る。ステップ５０６では、トラフィックモニタは、トラフィックディレクタがトラフィックを方向付けし得る発信元サーバ内に付加的な（新しい）リソースサーバの存在を判断し得る。ステップ５０８では、トラフィックディレクタはある期間の間、待機してからトラフィックレートを徐々に調整または調節し、これにより、トラフィックディレクタインスタンスとそれらの新しいリソースサーバとの間のトラフィック／接続を方向付ける。

図１１には示されていないが、上述したように、ある実施例に従うと、同様の技術は、既存のリソースサーバへのトラフィックを減速するよう、トラフィックレートを監視および徐々に調整または調節するために用いられ得るので、たとえばそのトラフィックが完全に休止される場合、サーバがオフラインにされ得る。

発信元サーバの動的な発見
ある実施例に従うと、トラフィックディレクタは、発信元サーバを動的に発見するとともにそれらのサーバタイプおよび／または他のプロパティを検出することにより、アドミニストレータに容易に発信元サーバをサーバプールに追加させる。

たとえば、ある実施例に従うと、アドミニストレータが動的な発見を有効にすると、トラフィックディレクタは、サーバプール内のサポート／認識されるアプリケーションサーバを動的に発見し得る。トラフィックサーバの観点から、それが一般アプリケーションサーバタイプに対してプロキシ（すなわち代理）として動作しているか、または代替的にはＷｅｂＬｏｇｉｃサーバのような認識されたサーバタイプであるかどうかを知ることは、サーバタイプに固有のルーティング、スロットリング、および他の最適化を適用するようトラフィックディレクタを補助する点で有用である。このような最適化は、アドミニストレータによるさらに別の手動構成の必要なく、自動的にシステムによって適用され得る。

クライアントがバックエンドの発信元サーバへの要求を行う観点から、トラフィックサーバによって発信元サーバへそれらの要求が若干トランスペアレントにルーティングされるが、発信元サーバタイプを発見するとともにサーバに固有の最適化を適用するトラフィックディレクタの能力が、認識されるサーバタイプが用いられる際はいつでも性能の利点を提供する。

ある実施例に従うと、アドミニストレータが、認識される管理されるサーバタイプ、たとえばＷｅｂＬｏｇｉｃサーバのクラスタを示す発信元サーバプールを作製したい場合、当該クラスタにおいて発信元サーバとして、各管理されるサーバを特定する必要がない。その代わり、管理されるサーバのいずれか１つを、当該プールにおいて発信元サーバとして特定することで十分である。次いで、トラフィックディレクタは、クラスタにおける他のＷｅｂＬｏｇｉｃサーバインスタンスの存在を動的に発見し得、発信元サーバとして構成される管理されるサーバと、同じクラスタにおける動的に発見される管理されるサーバとの両方にクライアント要求を配信する。

同様に、動的な発見が有効にされる際に、当該クラスタにおける管理されるサーバのいずれかが、停止、追加、または除去されるならば、アドミニストレータは、発信元サーバプールの定義を更新する必要はない。

ＷｅｂＬｏｇｉｃサーバを用いる実施例に従って、各Ｗｅｂｌｏｇｉｃサーバインスタンスは、バックエンドアプリケーションサーバへの入力ＨＴＴＰトラフィックを代理し得るとともに、ヘルスチェック要求に応答してＷｅｂｌｏｇｉｃに固有の応答ヘッダーを提供し得るその自身のリバースプロキシモジュールまたはプラグインを含む。たとえば、x-weblogic-jvmid応答ヘッダーは、現在のＷｅｂＬｏｇｉｃサーバノードのＪＶＭＩＤを示し得る。x-weblogic-cluster-hash応答ヘッダーは、ＷｅｂＬｏｇｉｃクラスタノードのハッシュ値を提供し得るとともに、したがってクラスタが修正されるたびに示し得る。x-weblogic-cluster-list応答ヘッダーは、クラスタにおけるそれらのＷｅｂｌｏｇｉｃサーバに対応するＪＶＭＩＤのリストを返し得る。

ＷｅｂＬｏｇｉｃ環境における発信元サーバプールについて動的な発見が有効にされると、トラフィックディレクタは以下のように、プールにおける残っているＷｅｂＬｏｇｉｃ発信元サーバを発見し得る。

まず、トラフィックディレクタインスタンスは、スタートすると、プールにおいて特定される発信元サーバがＷｅｂＬｏｇｉｃが管理するサーバであるかどうかと、クラスタに属するかどうかとを、当該サーバがＨＴＴＰヘルスチェック要求を各構成された発信元サーバに送ることによりチェックする。任意の特定の発信元サーバプールについて、トラフィックディレクタが動的な発見のために送るＨＴＴＰリクエストタイプは、そのプールについて現在構成されているヘルスチェック要求タイプであり得る。発信元サーバの応答は、上で記載したものと同様の応答ヘッダーを用いて、当該サーバがＷｅｂＬｏｇｉｃが管理するサーバであるかどうかを示す。発信元サーバがクラスタに属するＷｅｂＬｏｇｉｃが管理するサーバである場合、応答はさらに、クラスタにおける管理されるサーバのリストを含むことになる。

ある実施例に従うと、トラフィックディレクタがx-weblogic-cluster-hashおよびx-weblogic-cluster-list応答ヘッダーを有する応答を受け取ると、トラフィックディレクタはまず、ハッシュ値応答ヘッダーを用いて当該クラスタが修正されているかどうか決定し、その場合はたとえば、

といった残りの応答ヘッダーをパースする。これにより、クラスタにおいて新しく加えられたＷｅｂＬｏｇｉｃサーバについてのＪＶＭＩＤ、ポート、付加的な情報を決定し、次いでこれらをサーバプールに加える。

次に、トラフィックディレクタは発信元サーバからの応答における情報を用いて、発見された管理サーバについてのその構成を更新する。ある実施例に従うと、当該動的に発見された発信元サーバは、たとえば、構成された発信元サーバについて特定される重みまたは最大接続といったプロパティのすべてを受け継いでいる。

その後、発信元サーバプールについて構成される各周期的なヘルスチェック間隔で、トラフィックディレクタは、動的な発見ヘルスチェック要求を、プールにおける発信元サーバとして構成されるＷｅｂＬｏｇｉｃサーバインスタンスに送ることにより、クラスタにおける変更を検出するのを試みる。管理されるサーバの除去または追加のような、応答が以前のヘルスチェックからのクラスタの変更を示す場合、トラフィックディレクタは、動的に発見された発信元サーバの新しいセットで当該構成を更新する。

上記の記載は説明としてＷｅｂＬｏｇｉｃを用いるが、他の実施例に従うと、同様の技術が、サーバプール内の他のタイプのサポート／認識される発信元サーバを発見するよう用いられ得る。動的に発見された発信元サーバは、インスタンスの構成の発信元サーバプールの定義において、永続的に格納されない。したがって、トラフィックディレクタインスタンスが再起動されると、そのインスタンスによる動的な発見のプロセスが新たにスタートする。

ある実施例に従うと、動的な発見機能は、デフォルトでは有効にされていない。アドミニストレータは、管理コンソールまたはコマンドラインインタフェース（ＣＬＩ）のいずれかの使用により、動的な発見を有効にし得る。発信元サーバプールが修正されると、これは実際に構成を修正しているので、任意の更新された発信元サーバプールのセッティングを実施するために、対応する構成は再配置されるべきである。

図１２は、ある実施例に従った、トラフィックディレクタにおける発信元サーバの動的な発見を示す。図１２に示されるように、アドミニストレータ２９０が、２９２にて管理インターフェイス２８５を用いてトラフィックディレクタ６００と対話および管理し得る。管理インターフェイス２８５は、管理コンソール（ＧＵＩ）および／またはコマンドラインインターフェイスの１つ以上を含む。トラフィックディレクタは、１つ以上のトラフィックディレクタインスタンス６０２を含み得、サーバ６１０の１つ以上のプールを有する発信元サーバ６０８への要求を通信し得る。サーバの各プールは、リソースサーバＡ６１２のような１つ以上の（既存の）リソースサーバを含み得る。

ある実施例に従うと、トラフィックディレクタは、ヘルスチェックサブシステム６０４と、構成６０６とを含む。当該構成は、リスナー、発信元サーバ、フェイルオーバグループ、およびログといった、トラフィックディレクタインスタンスのさまざまな要素についての情報を提供する。

当該構成は、特定の発信元サーバプールが特定のリソースサーバを含むことを示すよう、アドミニストレータが最初に修正し得る。当該発信元サーバプールについて構成される各周期的なヘルスチェック間隔にて、ヘルスチェックサブシステムは次いで、たとえばＨＴＴＰヘルスチェック要求６１３を送るとともに、リソースサーバＡからの適切な応答６１４を受け取ることにより、その構成されたリソースサーバの各々のヘルスをチェックする。

ある実施例に従うと、動的な発見が有効にされると、発信元サーバプールについて構成される各周期的なヘルスチェック間隔で、トラフィックディレクタも、動的な発見ヘルスチェック要求６１６を、当該プールにおける発信元サーバとして構成される任意の新しいサーバインスタンスに送るとともに適切な応答６１７を受け取ることにより、リソースサーバＢ６１５のようなプールにおける変更を検出することを試みる。動的に発見されたサーバは、ノードが発見されたサーバプールのみにより適用される。トラフィックディレクタは次いで、動的に発見された発信元サーバのこの新しいセット６２０で、６１８にてその構成を更新する。

ＷｅｂＬｏｇｉｃサーバインスタンスを用いる実施例に従うと、動的な発見が発信元サーバプールについて有効にされると、ヘルスチェックサブシステムは、プールにおいて特定される発信元サーバがＷｅｂＬｏｇｉｃが管理するサーバであるかどうか、および当該サーバがクラスタに属するかどうかチェックする。上述したように、発信元サーバの応答ヘッダーは、当該サーバがＷｅｂＬｏｇｉｃサーバが管理するサーバであるかどうかを示し得、発信元サーバがクラスタに属するＷｅｂＬｏｇｉｃが管理するサーバである場合、応答は当該クラスタにおける管理サーバのリストを含むことになる。

図１３はさらに、ある実施例に従った、トラフィックディレクタにおける発信元サーバの動的な発見を示す。上述したように、動的な発見が有効にされると、発信元サーバプールについて構成される各周期的なヘルスチェック間隔にて、トラフィックディレクタは、動的な発見ヘルスチェック要求を任意の新しいサーバインスタンスに送るとともに、動的に発見される発信元サーバの新しいセットでその構成を更新することにより、その構成されるリソースサーバの各々のヘルスをチェックし、プールにおける変更を検出するよう試みる。

図１３にさらに示されるように、当該構成は、この例ではリソースサーバＡのプロパティ６２２を含む、プールにおける各構成される発信元サーバについてのプロパティを含み得る。ある実施例に従うと、当該動的に発見された発信元サーバは、たとえば、構成された発信元サーバについて特定される重みまたは最大接続といったプロパティのすべてを受け継いでいる。たとえば、トラフィックディレクタは、そのプロパティ６２３が構成されたリソースサーバＡのプロパティを引き継ぐ（同じとなるように）ように、発信元サーバとして動的に発見されるリソースサーバＢを構成し得る。

その後、その後のヘルスチェック６２５，６２６により、トラフィックディレクタがプールにおいて、新しいリソースサーバＣ６２４のようなさらに別の変更を検出すると、トラフィックディレクタは、そのプロパティ６２７も構成されるリソースサーバＡのプロパティを引き継ぐ（当該プロパティと同じである）ように、リソースサーバＣを発信元サーバとして同様に構成し得る。

ある実施例に従うと、構成または発見されるリソースサーバに関連付けられ得るタイプのサーバプロパティの例は、以下のものを含む。すなわち、
「重み」：発信元サーバは異なるロードの重みを有するよう構成され得る。この構成された重みに依存して、トラフィックディレクタがこのサーバへの入力要求ロードを方向付ける。
「上昇時間」：発信元サーバは、入力要求ロードが直ちに発信元サーバに方向付けされないように上昇時間を有するように構成され得る。
「最大接続」：発信元サーバは同時接続の最大数をサポートするよう構成され得る。
「バックアップ」：プール内の発信元サーバは、バックアップとして構成され得る。その場合、トラフィックディレクタは、プールにおいてバックアップとして示されていないすべての他のサーバがオフラインとマークされなければ、当該サーバに要求をルーティングしない。

ＷｅｂＬｏｇｉｃを用いる実施例に従うと、発信元サーバの応答が当該サーバがＷｅｂＬｏｇｉｃが管理するサーバであり、あるクラスタに属することを示していれば、応答はクラスタにおける管理されるサーバのリストを含むことになる。トラフィックディレクタは、発信元サーバからの応答における情報を用いて、その構成を発見された管理されるサーバで更新する。たとえば、特定の発信元サーバプールが以下の構成を有する場合、

、そしてトラフィックディレクタが'nsapi.us.oracle.com:7012'にて実行されるＷｅｂｌｏｇｉｃサーバノードを発見する場合、'nsapi.us.oracle.com:7011'のプロパティと同じ（すなわち引き継がれた）プロパティで当該発信元サーバを構成する。

図１４は、ある実施例に従った、トラフィックディレクタにおける発信元サーバの動的な発見を提供するための方法のフローチャートである。図１４に示されるように、ステップ６３２では、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、サーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が提供される。ステップ６３４では、トラフィックディレクタ（ある実施例に従うと、そのヘルスチェックサブシステム）はスタートアップ時および／または周期的に、アドミニストレータが以前に構成した発信元サーバ内のそれらのリソースサーバのヘルスチェックを要求する。ステップ６３６では、トラフィックディレクタのヘルスチェックサブシステムは、発信元サーバにて１つ以上の動的に発見されたリソースサーバ（たとえばＷｅｂＬｏｇｉｃサーバ）からヘルス応答を受け取る。ステップ６３８では、トラフィックディレクタは動的に発見されたリソースサーバから受け取った情報を用いて、トラフィックディレクタ構成を更新する。この更新には、適切な場合、以前に構成された発信元サーバからプロパティを引き継ぐことを含む。

図１５は、ある実施例に従ったトラフィックディレクタにおける発信元サーバの動的な発見を提供するための別の方法のフローチャートである。特に図１５は、動的な発見が発信元サーバプールについて有効にされると、トラフィックディレクタは、当該プールにおいて新しいまたは付加的なＷｅｂＬｏｇｉｃ発信元サーバを発見し得るようにＷｅｂＬｏｇｉｃサーバを用いる実施例を示す。

図１５に示されるように、ステップ６４２では、トラフィックサーバが起動しヘルスチェックサブシステムを呼び出して（ステップ６４３）、構成されたプールに対するヘルスチェックを行う（ステップ６４４）。

ステップ６４５では、ヘルスチェックが完了すると、当該システムは、既存の構成をロードするか（ステップ６４６，６４７）、新しい構成をロードするか（ステップ６４８，６５０）、または動的再構成を行う（ステップ６４９）かのいずれかを行うよう、進み得る。

ステップ６５１では、発信元サーバがＷｅｂＬｏｇｉｃサーバであって、クラスタとして構成される場合（ステップ６５３）、当該プロセスは、クラスタリスト（ステップ６５６）を比較し、適切な場合、新しいノードで構成を更新する（ステップ６５７，６５９）。別の態様では、サーバは、オンラインにマークされ得、当該プロセスが進み得る（ステップ６５２，６５４，６５８）。

ある実施例に従うと、トラフィックディレクタとの使用のための動的な発見ルーティングに対して、「dynamic-server-discovery」という要素は、そのサーバについて特定され得る。その例がテーブル３に提供される。

高性能コンピュータ環境を用いたロードバランシングの構成
ある実施例に従うと、高速のインフィニバンドネットワークインフラストラクチャを有するＥｘａｌｏｇｉｃミドルウェアマシンのような高性能コンピュータ環境のためのローカルのロードバランサとして用いられる際、トラフィックディレクタのロードバランシングは、当該環境のネットワークアーキテクチャとシームレスに動作するよう設計され得る。

インフィニバンドは、ポイント・ツー・ポイントの双方向シリアルリンクを提供するスイッチドファブリック通信リンクであり、ディスクのような高速周辺機器とのプロセッサの接続のために一般的に設計されている。異なるプロトコルがインフィニバンドファブリック上で通信を行うよう用いられ得る。その例は、インターネット・プロトコル・オーバ・インフィニバンド（ＩＰｏＩＢ）およびソケットダイレクトプロトコル（ＳＤＰ）を含む。

ＩＰｏＩＢプロトコルは、インフィニバンドレイヤーの上のインターフェイスとして用いられ、ソケットベースのアプリケーションがホストのＴＣＰ／ＩＰプロトコルスタックを利用することを可能にする。次いで、ＴＣＰ／ＩＰプロトコルスタックは、アプリケーションに対してトランスペアレントな態様でネイティブのインフィニバンドに翻訳される。ＳＤＰプロトコルは、ソケットベースのインターフェイスの最適化であり、システムがＴＣＰ／ＩＰスタックをバイパスして、その代わりに、リモートダイレクトメモリアクセス（remote direct memory access（ＲＤＭＡ））動作を用いて、既存のＴＣＰストリームソケットセマンティクスを維持しながらソケットベースのパケットを直接的にインフィニバンドレイヤーに翻訳することを可能にする。ＳＤＰプロトコルは、ＩＰｏＩＢをサポートするのに必要ないくつかのソフトウェアレイヤーをバイパスする利点を有し、この結果ＳＤＰはＩＰｏＩＢよりも良好なレイテンシーおよび処理量を有することになる。

ある実施例に従うと、トラフィックディレクタは、インバウンド接続としてたとえばインバウンドのイーサネット・トラフィック・エミュレーテッド・オーバ・ＩＢ（Ethernet traffic emulated over IB（ＥｏＩＢ））を終了し得、アウトバウンドの接続としてＩＰｏＩＢまたはＳＤＰのようなプロトコルを用いてインフィニバンドネットワーク上で発信元サーバと通信し得る。トラフィックディレクタの統合されたＨＴＴＰキャッシングおよび圧縮能力は、Ｅｘａｌｏｇｉｃのような高性能コンピューティング環境の可変のエグレスおよびイングレス帯域幅要件に特に好適にされる。

図１６は、ある実施例に従った、トラフィックディレクタの使用を示す。図１６に示されるように、１つ以上のトラフィックディレクタインスタンス６７２を有するトラフィックディレクタ６７０は、高速のインフィニバンドネットワークインフラストラクチャ６８２を有するミドルウェアマシン（たとえばＥｘａｌｏｇｉｃ）６８０のような高性能コンピューティング環境と組み合されて用いられ得る。

ある実施例に従うと、トラフィックディレクタは、１つ以上のプロトコルターミネータ／エミュレータ６７４（たとえば、１つ以上のＩＰｏＩＢおよび／またはＳＤＰターミネータ／エミュレータ）と、インバウンドソケット構成６７６と、アウトバウンドソケット構成６７７とを含む。発信元サーバ６８３がサーバ６８４，６８５の１つ以上のプールとして設けられ得、各サーバプールは、１つ以上のリソースサーバ６８６，６８８を含む。組織の特定の必要性に依存して、サーバの各プールが、当該プール内の発信元サーバは要求をトラフィックディレクタから受け取る従来のＩｎｅｔソケットのような通信プロトコル／ソケット、または代替的にはＩＰｏＩＢもしくはＳＤＰのような高速プロトコルを用いるよう構成され得る。図１６に示される例において、サーバプール６８４における発信元サーバはＳＤＰ６８７を用いるよう構成される一方、サーバプール６８５における発信元サーバはＩｎｅｔ６８９を用いるよう構成される。他の実施例および例に従って、他のタイプのプロトコル／ソケットが用いられ得る。

特定の発信元サーバに方向付けられる要求６９０が受け取られると、トラフィックディレクタがその構成を用いて適切なターミネータ／エミュレータを決定し、その構成されるプロトコル／ソケット６９３の上の発信元サーバへの通信のために高速インフィニバンドネットワークインフラストラクチャに要求６９２を通信する。

ある実施例に従うと、インバウンド接続を構成するよう、ｈｔｔｐリスナー構成がserver.xmlファイル内に提供され得る。そのパラメータおよび例がそれぞれ、テーブル４およびリスティング４に提供される。

ある実施例に従うと、アウトバンド接続を構成するよう、ｈｔｔｐプロトコル構成がserver.xmlファイル内に提供され得る。そのパラメータおよび例がそれぞれ、テーブル５およびリスティング５において提供される。リバースプロキシ要素下で、サーバプールのリストが提供され得、その各々は、発信元サーバのプールの定義である。各サーバプールは、複数の発信元サーバ要素を含み得る。ファミリー要素が、発信元サーバに接続するよう用いられるソケットファミリーを示す。ある実施例に従うと、可能な値は、たとえばデフォルト、Ｉｎｅｔ、Ｉｎｅｔ６、またはｉｎｅｔ−ＳＤＰソケットを含む。

図１７は、ある実施例に従った、トラフィックディレクタを用いるための方法のフローチャートである。図１７に示されるように、ステップ６９４では、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、サーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が提供される。ステップ６９５では、１つ以上の発信元サーバが、高速（たとえばインフィニバンド）ネットワークを有するミドルウェアマシン（たとえばＥｘａｌｏｇｉｃ）のような高性能コンピューティング環境に展開される。ステップ６９７では、トラフィックディレクタは、高速ネットワークとの通信のために、１つ以上のインバウンドおよびアウトバウンド接続とプロトコルターミネータ／エミュレータとを有するよう構成される。ステップ６９８にて、トラフィックディレクタはインバウンド（たとえばＥｏＩＢ）接続を終了させ、構成されるアウトバンド接続とターミネータ／エミュレータとを用いてクライアントからの要求を発信元サーバに通信する。

動的なキャッシュデータ復元
ある実施例に従うと、トラフィックディレクタは、圧縮データとして発信元サーバからのコンテンツを提供するか、または特定のクライアントが圧縮されていないデータのバリアントを受け取ることを望む場合、提供前に当該データを動的に復元するかのいずれかにより、クライアントからの要求に応答するよう構成され得る。

ある実施例に従うと、その圧縮または復元されたフォーマットのいずれかのデータを提供するかどうかについての決定が、最初のクライアント要求において、たとえば柔軟性および相互運用性を提供するＨＴＴＰヘッダーの使用を通じて提供され得る。このようなデータの圧縮および復元が、トラフィックディレクタのビルトインのＨＴＴＰキャッシング機能性とともに行われるよう構成され得る。

図１８は、ある実施例に従った、トラフィックディレクタ環境における動的なＨＴＴＰ復元の使用を示す。図１８に示されるように、ある実施例に従うと、トラフィックディレクタ９００は、クライアント要求を発信元サーバ９１０に配信するための、リソースサーバ９１４の１つ以上のプール９１２を含む１つ以上のトラフィックディレクタインスタンス９０２を含み得る。

ある実施例に従うと、トラフィックディレクタは、発信元サーバの１つ以上との使用のために有効にされ得るキャッシュ９０４を含む。いくつかのトラフィックディレクタインスタンスによって共有される単一のキャッシュとして図１８に示されるが、ある実施例に従うと、いくつかのこのようなキャッシュが用いられ得、および／または各トラフィックディレクタインスタンスが自身のキャッシュを有し得る。

ある実施例に従うと、キャッシングが有効にされ、クライアント要求が９２０にて発信元サーバに通信され、当該要求に応答してコンテンツが９２２にてそれらの発信元サーバから返されると、トラフィックディレクタは、その構成に従ってそのキャッシュ内に発信元サーバコンテンツに対応するデータの１つ以上のセットをキャッシュし得る。例示的な例としては、特定の発信元サーバは、画像ファイル（たとえばＧＩＦファイル）および他のコンテンツをクライアントに提供するよう構成されてもよく、トラフィックディレクタは、ある特定の期間の間、そのキャッシュ内に特定の発信元サーバから受け取った画像ファイルをキャッシュするよう構成されてもよい。

ある実施例に従うと、トラフィックディレクタはインメモリデータベースとして動作する。これは、データをキャッシュすることには、コンピュータメモリの使用が必要であり、システムコストおよび性能の両方に影響を与えるということを意味する。これに対処するために、ある実施例に従うと、トラフィックディレクタが、そのキャッシュに格納されるようデータを圧縮してから、圧縮データ９２６，９２７，９２８をキャッシュする。これにより、必要な全体的なキャッシュサイズが低減され、したがってメモリ要件が低減され、および／または特定のキャッシュサイズ内により多くの数のデータエントリが格納されることが可能になる。

ある実施例に従うと、キャッシュされたデータは次いで、クライアントの必要性に依存して、その圧縮フォーマットまたは復元フォーマットのいずれかでクライアントからの要求に応答してクライアントに提供され得る。

たとえば、いくつかの（たとえば、ブラウザ）クライアントが応答内の圧縮データを受け入れ得る間、他のクライアント（たとえば携帯電話）は、非圧縮フォーマットで提供されるべき応答データを必要とし得る。

図１８に示されるように、ある実施例に従うと、クライアントＡ９３０は、応答が圧縮データ９３２を含み得るということをトラフィックディレクタに示し得る。ある実施例に従うと、この指示は、要求コンポーネント（たとえばＨＴＴＰトラフィックの場合はＨＴＴＰ要求ヘッダー）の一部として、トラフィックディレクタにクライアントによって通信され得る。これに応答して、トラフィックディレクタは、応答を得るために発信元サーバに要求を通信するか、またはトラフィックディレクタがデータのコピーが現在キャッシュ内に圧縮フォーマット（たとえば圧縮データＡ９２６）で格納されていると判断する場合、９３６にて圧縮フォーマットでクライアントに当該データを返し得る。

さらに図１８に示されるように、ある実施例に従うと、クライアントＢ９４０は、応答が圧縮データ９４２を含み得ない（すなわち非圧縮データのみが受け入れ可能である）ことをトラフィックディレクタに示し得る。ある実施例に従うと、この指示は、たとえばＨＴＴＰ要求ヘッダーといった要求コンポーネントの一部としてクライアントによってトラフィックディレクタに同様に通信され得る。これに応答して、トラフィックディレクタは再び、応答を得るために要求を発信元サーバに通信するか、またはトラフィックディレクタがデータのコピーが現在そのキャッシュに圧縮フォーマットで格納されている（たとえば圧縮データＢ９２７）と判断する場合、そのデータ９４４を復元し、データの復元されたバリアント９４６をクライアントに返し得る。

たとえばＨＴＴＰ要求ヘッダーの使用を通じたクライアントからの肯定的な指示として図１８に示されるが、実施例に従うと、当該システムは、デフォルトも認識し得、たとえば、デフォルトでは非圧縮データのみがクライアントに受け入れ可能であると考えられるべきであると、クライアントがそうではないことを示していなければ、それに従って動作することがデフォルトであると認識し得る。

上記の機能性を用いて、キャッシュは、異なるクライアントの必要性に適合するようデータを２つの異なる（たとえば、圧縮と非圧縮）フォーマットで格納する必要がないが、その代わりに単一の圧縮データインスタンス／フォーマットのみが当該キャッシュ内に格納される必要があり、当該要求を行った特定のクライアントの必要性に依存して、必要に応じて復元されるデータが格納される。

図１９は、ある実施例に従った、トラフィックディレクタ環境における動的なＨＴＴＰ復元を提供するための方法のフローチャートである。図１９に示されるように、ステップ９５０にて、１つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタと、リソースサーバの１つ以上のプールを有する発信元サーバとを含むトラフィックディレクタ環境が提供される。ステップ９５２では、トラフィックディレクタは、発信元サーバから受け取ったコンテンツまたはデータのキャッシングおよび圧縮を行うよう有効にされ、クライアントからの要求を処理する間、１つ以上の圧縮データをトラフィックディレクタのキャッシュに格納する。ステップ９５４では、トラフィックディレクタはクライアントから、特定のコンテンツまたはデータについて要求と、クライアントが圧縮データとして応答を受け入れ得るかどうかおよび／または復元データを必要としているかどうかについての指示とを受け取り得る。ステップ９５６では、必要とされるコンテンツがキャッシュ内にあれば、トラフィックディレクタは、キャッシュに格納されるデータを用いて、クライアントが復元されたデータについて必要性を示す場合には、動的にキャッシュのデータを復元することを、応答を準備することの一部として含めて、応答をクライアントに提供し得る。

ハードウェア支援圧縮プリミティブについてのサポート
ある実施例に従うと、トラフィックディレクタは、ハードウェア支援圧縮プリミティブ、たとえばインテル（登録商標）のインテグレーテッド・パフォーマンス・プリミティブ（Integrated Performance Primitives（ＩＰＰ））を使用して、上記のＨＴＴＰキャッシングおよび動的な復元機能を含むそのデータ圧縮および復元の性能をさらに向上するよう構成され得る。

ある実施例に従うと、プロセッサのようなコンピュータハードウェアが圧縮／復元ライブラリに関連付けられ得る。圧縮／復元ライブラリは、あるプロセッサに対して圧縮および復元動作の性能を向上するよう用いられ得る。たとえば、いくつかのコンピュータハードウェア製造は、それらの製品（たとえばインテルはスタートアップの間にシステムにプレロードされ得るそのＩＰＰライブラリを提供する）との使用のためにｚｌｉｂライブラリを提供する。ある実施例に従うと、圧縮／復元ライブラリが利用可能であれば、トラフィックディレクタは当該ライブラリを使用してその圧縮および復元動作の性能を向上し得る。

図２０は、ある実施例に従った、トラフィックディレクタ環境における動的なＨＴＴＰ復元との使用のためのハードウェアプリミティブのついてのサポートを示す。図２０に示されるように、ある実施例に従うと、トラフィックディレクタは、プロセッサ９７２を含むコンピュータサーバ９７０上に設けられ得る。ある実施例に従うと、システムは、圧縮／復元ライブラリ９７４（たとえばｚｌｉｂライブラリ）を含む。クライアントに応答して、トラフィックディレクタがコンテンツまたはデータを圧縮または復元する必要がある場合、たとえばキャッシュデータを復元する際に、９８０，９８２にて圧縮／復元ライブラリを利用し得、プロセッサによって提供されるハードウェア支援圧縮プリミティブを活用する。

本発明は、１つ以上のプロセッサ、メモリ、および／または本開示の教示に従ってプログラムされたコンピュータ可読記憶媒体を含む１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティング装置、マシン、またはマイクロプロセッサを用いて簡便に実施され得る。ソフトウェア技術の当業者には明らかであるように、適切なソフトウェアコーディングは、熟練したプログラマによって本開示の教示に基づき容易に用意され得る。

いくつかの実施例では、本発明は、本発明の処理のいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令を格納した一時的でない記憶媒体またはコンピュータ可読媒体であるコンピュータプログラムプロダクトを含む。当該記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気または光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／またはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。

本発明の上記の記載は、例示および説明目的で与えられている。網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。記載された実施例のいくつかはオラクルトラフィックディレクタ環境の文脈で機能を記載しているが、記載される特徴は他のコンピューティング環境の文脈でも用いられ得る。当業者にとっては、多くの修正例および変形例が明確であろう。上記の実施例は、本発明の原理およびその実際的な適用をもっともよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に好適なさまざまな修正例を考慮して、さまざまな実施例について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によって定義されることが意図される。

Claims (15)

1. トラフィックディレクタを含むコンピューティング環境における使用のためのシステムであって、
   マイクロプロセッサおよびコンピュータメモリと、
   前記マイクロプロセッサおよびコンピュータメモリで動作する一つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタとを備え、前記トラフィックディレクタは、クライアントから要求を受信し発信元サーバへ通信するように構成されており、
   一つ以上のプライマリサーバおよびバックアップサーバを含む発信元サーバの第１プールを備え、
   前記トラフィックディレクタは、前記第１プールにおける前記一つ以上のプライマリサーバの可用性を判断し、前記第１プールにおける前記少なくとも一つのプライマリサーバが利用可能である間に、前記第１プールのために前記トラフィックディレクタによって受信される全ての要求を前記第１プールにおける前記一つ以上のプライマリサーバのみに向けるように構成されており、
   いずれのプライマリサーバも前記第１プールで利用可能でない場合に、前記第１プールにおける少なくとも一つの前記プライマリサーバが再び利用可能になるまで、前記トラフィックディレクタは、前記第１プールのために前記トラフィックディレクタによって受信される全ての要求を前記第１プールにおける一つ以上のバックアップサーバに向けるように構成されている、システム。
2. 一つ以上のプライマリサーバと一つ以上のバックアップサーバを含む発信元サーバの第２プールをさらに備え、
   前記トラフィックディレクタは、前記第２プールにおける前記一つ以上のプライマリサーバの可用性を判断し、前記第２プールにおける前記少なくとも一つのプライマリサーバが利用可能である間に、前記第２プールのために前記トラフィックディレクタによって受信される全ての要求を前記第２プールにおける前記一つ以上のプライマリサーバのみに向けるように構成されており、
   いずれのプライマリサーバも前記第２プールで利用可能でない場合に、前記第２プールにおける少なくとも一つの前記プライマリサーバが再び利用可能になるまで、前記トラフィックディレクタは、前記第２プールのために前記トラフィックディレクタによって受信される全ての要求を前記第２プールにおける一つ以上のバックアップサーバに向けるように構成されている、請求項１に記載のシステム。
3. トラフィックディレクタを含むコンピューティング環境における使用のためのシステムであって、
   １つ以上のトラフィックディレクタインスタンスを有し、複数のサーバの１つ以上のプールを有する発信元サーバにクライアントからの要求を受け取って通信するよう構成されるトラフィックディレクタと、
   ヘルスチェックサブシステムおよび構成とを含み、前記構成は、発信元サーバを含む、前記トラフィックディレクタインスタンスのさまざまな要素についての情報を提供し、
   前記ヘルスチェックサブシステムは、前記プールに属する複数のサーバのヘルスを周期的にチェックし、前記１つ以上のプールにおける前記複数のサーバのいずれかの状態の変更を検出し、前記プール内において発信元サーバとして構成される任意の新しいサーバインスタンスに要求を送り、適切な応答を受け取り、前記構成をそれにより更新し、
   前記複数のサーバのうちのプライマリサーバが利用可能である場合に、前記トラフィックディレクタは、全ての要求を前記プライマリサーバに送信し、前記プライマリサーバが利用可能でない場合に、前記トラフィックディレクタは、前記全ての要求を前記複数のサーバのうちのバックアップサーバに送信する、システム。
4. 当該ヘルスチェックの要求は、ＨＴＴＰヘルスチェック要求である、請求項３に記載のシステム。
5. 前記サーバがクラスタに属することを発信元サーバの応答が示していれば、当該応答は前記クラスタにおける管理されるサーバのリストを含む、請求項３または４に記載のシステム。
6. 前記更新される構成は、動的に発見された発信元サーバが、構成されるリソースサーバについて特定されるプロパティを引き継ぐことを含む、請求項３〜５のいずれか１項に記載のシステム。
7. 発信元サーバの１つ以上は、ＷｅｂＬｏｇｉｃサーバであり、各Ｗｅｂｌｏｇｉｃサーバインスタンスは、ヘルスチェックの要求に応答してＷｅｂｌｏｇｉｃに固有の応答ヘッダーを提供することが可能である、請求項３〜６のいずれか１項に記載のシステム。
8. トラフィックディレクタを含むコンピューティング環境における使用のための方法であって、
   一つ以上のトラフィックディレクタインスタンスを有するトラフィックディレクタを準備するステップを備え、前記トラフィックディレクタは、クライアントから要求を受信し発信元サーバへ通信するように構成されており、
   一つ以上のプライマリサーバおよびバックアップサーバを含む発信元サーバの第１プールを準備するステップと、
   前記トラフィックディレクタを用いて、前記第１プールにおけるプライマリサーバの可用性を判断するステップと、
   前記少なくとも一つのプライマリサーバが利用可能である間に、前記第１プールのために前記トラフィックディレクタによって受信される全ての要求を前記第１プールにおける前記一つ以上のプライマリサーバのみに向けるステップと、
   いずれのプライマリサーバも前記第１プールで利用可能でない場合に、前記第１プールにおける少なくとも一つの前記プライマリサーバが再び利用可能になるまで、前記第１プールのために前記トラフィックディレクタによって受信される全ての要求を前記第１プールにおける一つ以上のバックアップサーバに向けるステップとを備える、方法。
9. 一つ以上のプライマリサーバと一つ以上のバックアップサーバを含む発信元サーバの第２プールを準備するステップと、
   前記トラフィックディレクタを用いては、前記第２プールにおける前記一つ以上のプライマリサーバの可用性を判断するステップと、
   前記第２プールにおける前記少なくとも一つのプライマリサーバが利用可能である間に、前記第２プールのために前記トラフィックディレクタによって受信される全ての要求を前記第２プールにおける前記一つ以上のプライマリサーバのみに向けるステップと、
   いずれのプライマリサーバも前記第２プールで利用可能でない場合に、前記第２プールにおける少なくとも一つの前記プライマリサーバが再び利用可能になるまで、前記第２プールのために前記トラフィックディレクタによって受信される全ての要求を前記第２プールにおける一つ以上のバックアップサーバに向けるステップとをさらに備える、請求項８に記載の方法。
10. トラフィックディレクタを含むコンピューティング環境における使用のための方法であって、
    １つ以上のトラフィックディレクタインスタンスを有し、複数のサーバの１つ以上のプールを有する発信元サーバにクライアントからの要求を受け取って通信するよう構成されるトラフィックディレクタを提供するステップと、
    ヘルスチェックサブシステムおよび構成とを提供するステップとを含み、前記構成は、発信元サーバを含む、前記トラフィックディレクタインスタンスのさまざまな要素についての情報を提供し、
    前記ヘルスチェックサブシステムは、前記プールに属する複数のサーバのヘルスを周期的にチェックし、前記１つ以上のプールにおける前記複数のサーバのいずれかの状態の変更を検出し、前記プール内において発信元サーバとして構成される任意の新しいサーバインスタンスに要求を送り、適切な応答を受け取り、前記構成をそれにより更新することによって、前記１つ以上のプールにおける変更を検出し、
    前記複数のサーバのうちのプライマリサーバが利用可能である場合に、前記トラフィックディレクタは、全ての要求を前記プライマリサーバに送信し、前記プライマリサーバが利用可能でない場合に、前記トラフィックディレクタは、前記全ての要求を前記複数のサーバのうちのバックアップサーバに送信する、方法。
11. 当該ヘルスチェックの要求は、ＨＴＴＰヘルスチェック要求である、請求項１０に記載の方法。
12. 前記サーバがクラスタに属することを発信元サーバの応答が示していれば、当該応答は前記クラスタにおける管理されるサーバのリストを含む、請求項１０または１１に記載の方法。
13. 更新された前記構成は、動的に発見された発信元サーバが、構成されるリソースサーバについて特定されるプロパティを引き継ぐことを含む、請求項１０〜１２のいずれか１項に記載の方法。
14. 発信元サーバの１つ以上は、ＷｅｂＬｏｇｉｃサーバであり、各Ｗｅｂｌｏｇｉｃサーバインスタンスは、ヘルスチェックの要求に応答してＷｅｂｌｏｇｉｃに固有の応答ヘッダーを提供することが可能である、請求項１０〜１３のいずれか１項に記載の方法。
15. 請求項８〜１４のいずれかに記載の方法をコンピュータに実現させる、コンピュータプログラム。