(58)【調査した分野】(Int.Cl.,DB名)
前記満杯の、2分の1の、もしくは4分の1のラックまたはその他の構成は、インフィニバンドネットワークを介して互いに通信する、1つ以上の計算ノード、インフィニバンドスイッチゲートウェイ、およびストレージノードまたはユニットを含む、請求項17に記載の方法。
前記ミドルウェア環境は、アプリケーションサーバ、ミドルウェア、ならびに、ウェブロジックサーバ、ジェイロキットまたはホットスポットJVM、オラクルリナックス(登録商標)またはソラリス、およびオラクルVMといったその他の機能を提供する、請求項9から18のいずれか1項に記載の方法。
【発明を実施するための形態】
【0006】
詳細な説明
上記のように、どのような大きな組織でも、その中では、長年を経て、さまざまな異なるコンピュータハードウェア、オペレーティングシステム、およびアプリケーションソフトウェアを含むITインフラストラクチャが無秩序に拡大していることが多い。このようなインフラストラクチャの個々の構成要素自体は巧みに設計され適切に維持管理されているかもしれないが、このような構成要素を相互に接続、または、リソースを共有しようとすると、それは困難な管理タスクであることが多い。近年、組織の関心は、仮想化およびストレージの集中化といった技術に向けられるようになっており、さらに近年では、共有インフラストラクチャの基礎を提供できるクラウドコンピューティングに向けられている。しかしながら、このような環境に特に適したオールインワンのプラットフォームはほとんどない。
【0007】
これに対し、本明細書では、ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法について説明する。ある実施の形態に従うと、このシステム(本明細書において実装形態によっては「エクサロジック」と呼ぶ)は、たとえば64ビットプロセッサ技術、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキングといった高性能ハードウェアと、ウェブロジックスイート(WebLogic Suite)といったアプリケーションサーバまたはミドルウェア環境との組合せを含むことにより、完全なJava EEアプリケーションサーバ複合体を提供する。この複合体は、大規模並列処理インメモリグリッドを含み、素早くプロビジョニングすることができ、要求に応じて拡大縮小できる。ある実施の形態に従うと、このシステムは、アプリケーションサーバグリッドと、ストレージエリアネットワークと、インフィニバンドネットワークとを提供する、満杯の、2分の1の、もしくは4分の1のラックとしてまたはその他の構成として準備できる。ミドルウェアマシンソフトウェアは、アプリケーションサーバ、ミドルウェア、および、たとえばウェブロジックサーバ、ジェイロキットまたはホットスポット(Hotspot)JVM、オラクルリナックスまたはソラリス(Solaris)、およびオラクルVMといった他の機能を提供できる。ある実施の形態に従うと、このシステムは、インフィニバンドネットワークを介して互いに通信する、複数の計算ノードと、インフィニバンドスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。
【0008】
ラック構成として実装される場合、ラックの未使用部分は、空のままでもフィラー(filler)によって占められてもよい。このシステムのさらに他の特徴は、例として、ゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーションを含み得る。
【0009】
図1は、ある実施の形態に従うミドルウェアマシン環境100の例を示す。
図1に示されるように、各ミドルウェアマシンシステム102は、数個のミドルウェアマシンラック構成要素104を含み、ミドルウェアマシンラック構成要素104は各々、高性能ミドルウェアマシンハードウェアノード106(たとえば64ビットプロセッサ、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキング)と、ミドルウェアマシンソフトウェア環境108との組合せを含む。これにより、数日または数カ月ではなく数分でプロビジョニングすることができ、要求に応じて拡大縮小できる、完全なアプリケーションサーバ環境を提供できる。
【0010】
ある実施の形態に従うと、各ミドルウェアマシンシステムは、満杯の、2分の1の、もしくは4分の1のラックとしてまたはラック構成要素からなるその他の構成として準備することができ、数個のミドルウェアマシンシステムを、ここでもインフィニバンドを用いて連結することにより、より大きな環境を作ることができる。各ミドルウェアマシンソフトウェア環境に、数個のアプリケーションサーバインスタンスまたはその他のソフトウエアインスタンスを設けることができる。たとえば、
図1に示されるように、第1のアプリケーションサーバインスタンス109が、仮想マシン116と、オペレーティングシステム120と、仮想化層124と、アプリケーションサーバ層128(たとえば、サーブレット(Servlet)132、EJB134、およびグリッドリンク(GlidLink)136それぞれのコンテナを含むウェブロジック)とを含み得るのに対し、第2またはその他のアプリケーションサーバインスタンス110は、仮想マシン116と、オペレーティングシステム120と、仮想化層124と、データグリッド層140(たとえばアクティブキャッシュ142を含むコヒーレンス(Coherence))とを含み得る。ある実施の形態に従うと、アプリケーションサーバインスタンスは各々、本明細書においてエクサロジック統合(integration)パックと呼ぶ、ミドルウェアマシン統合構成要素150を用いて、互いに通信でき、かつ、そのミドルウェアマシンハードウェアノードおよびその他のノード双方とも通信できる。ミドルウェアマシン統合構成要素150自体が、インフィニバンドおよびその他の特徴に対するサポートといったいくつかの最適化特徴を提供し、その各々については以下でさらに詳細に説明する。
【0011】
図2は、ある実施の形態に従うミドルウェアマシンプラットフォームまたは環境の別の例を示す。
図2に示されるように、各アプリケーションサーバインスタンスは、ミドルウェアマシン環境内において送信側および/または受信側160、161いずれかとして機能し得る。ある実施の形態に従うと、各アプリケーションサーバインスタンスは、インフィニバンドネットワーク164を介してアプリケーションサーバインスタンスが他のアプリケーションサーバインスタンスと通信できるようにするマルチプレクサ162、163に関連付けられている。
図2に示される例では、特定の実装形態に応じて、アプリケーションサーバインスタンスは、ソケットダイレクトプロトコル(sockets direct protocol)168を含み得るカーネルスペース(kernel space)162と、ユーザスペース164と、アプリケーションサーバ(たとえばウェブロジック)166と、JVM(たとえばジェイロキット/ホットスポット層)170と、WLSコア172構成要素と、サーブレットコンテナ174構成要素と、JSPコンパイラ176構成要素とを含み得る。他の実装形態に従うと、ミドルウェアタイプのソフトウェアおよび構成要素の他の組合せが含まれていてもよい。さまざまな実施の形態に従い、マシン統合構成要素は、ゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーション等の特徴を1つ以上提供することにより、共有されるインフラストラクチャの基礎を提供するとともにこのインフラストラクチャ内での性能を改善することもできる。上記特徴各々については以下でより詳細に説明する。
【0012】
当業者には容易にわかるように、本発明の機能ブロックを、ハードウェアによって、ソフトウェアによって、またはハードウェアとソフトウェアの組合せによって実現することにより、本発明の原理を実施してもよい。図面に記載された機能ブロックを組合わせるまたはサブブロックに分割することにより、上記本発明の原理を実現してもよいことが、当業者に理解される。したがって、本明細書における説明は、本明細書に記載の機能ブロックの任意の可能な組合せまたは分割またはさらに他の定義をサポートし得る。
【0013】
図3は、ある実施の形態に従う、4分の1ラック構成として提供されるミドルウェアマシンの例を示す。
図3に示されるように、4分の1ラック構成202として提供される場合、ミドルウェアマシンは、X4170 M2サーバノード等の、複数の高性能サーバと、NM2−GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイ(Switch/Gateway)と、Maguro RW−2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。
【0014】
図4は、ある実施の形態に従う、2分の1ラック構成として提供されるミドルウェアマシンの例を示す。
図4に示されるように、2分の1ラック構成216として提供される場合、ミドルウェアマシンは、同じく、X4170 M2サーバノード等の、多数の高性能サーバと、NM2−GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、Maguro RW−2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。ハードウェア構成要素は、その数がより多いものの、それ以外の点は4分の1ラック構成のハードウェア構成要素と同一である。
【0015】
図5は、ある実施の形態に従う、満杯のラック構成として提供されるミドルウェアマシンの例を示す。
図5に示されるように、満杯のラック構成222として提供される場合、ミドルウェアマシンは、より数が多い、X4170 M2サーバノード等の、高性能サーバと、NM2−GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、Maguro RW−2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ここでも、ハードウェア構成要素は、その数がより多いものの、それ以外の点は4分の1ラック構成および2分の1ラック構成のハードウェア構成要素と同一である。
【0016】
図6は、ある実施の形態に従う、他のシステムおよびネットワークとのインターフェイスのために使用できるミドルウェアマシンプラットフォームまたは環境の例を示す。
図6に示されるように、ミドルウェアマシン230の構成が4分の1ラックであるか2分の1ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェア232は、X4170 M2サーバノード等の、複数の高性能サーバと、NM2−GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、Maguro RW−2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。これらは、インフィニバンドを用いて連結され、管理ネットワーク234を用いて管理できる。ある実施の形態に従うと、NM2−GWノード等のインフィニバンドスイッチ/ゲートウェイを用いて、1つ以上のデータセンターサービスネットワーク236への10Gbイーサネット接続を与えることができる。1つ以上の管理スイッチたとえばCisco4948スイッチを用いて、1つ以上のデータセンター管理ネットワーク236への1Gbイーサネット接続を与えることができる。インフィニバンドネットワークを用いて、ミドルウェアマシンを他のミドルウェアマシンにまたはエクサデータ(Exadata)マシン240等の他のマシン環境に接続することもできる。
【0017】
ある実施の形態に従うと、ミドルウェアマシン230の構成が4分の1ラックであるか2分の1ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェアおよび/またはソフトウェア環境は、ミドルウェアマシンの性能を改善する、たとえばゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーションといったさらに他の特徴を含み得る。
【0018】
ゼロバッファコピー
ある実施の形態に従うと、このシステムは、ウェブロジックサーバ(WLS)、ジェイロキットまたはホットスポットJVM、オラクルリナックスまたはソラリス、およびオペレーティングシステム(OS)等の構成要素におけるバッファコピーを回避するゼロバッファコピーを使用することができる。従来、システムの各層(たとえばサーバ層、JVM層、OS層など)は、他の層、アプリケーション、およびプロセスがアクセスできない専用メモリスペースを保有する。これは、外部システムが重要なメモリスペースおよびデータを破壊してシステムクラッシュの原因となることがないようにすることによって、システムの全体的な安定性を守るためである。したがって、要求と応答の処理の間、要求および応答に関連するデータは、層と層の間で、専用メモリスペースから専用メモリスペースに、コピーされる。すなわち、所与の層は、データを処理した後、このデータを次の層に押出し、この、次の層は、データをその専用メモリスペースにコピーし、これに対して処理を行ない、次の層に押出す。他の層と層の間でも同じことが行なわれる。しかしながら、本発明の実施の形態は、さまざまな層を密に統合することにより、システムの安定性にとっての危険を高めることなく、これらの層が安全にメモリスペースを共有できるようにする。したがって、このことは、ユーザおよびカーネルスペースにおけるCPUの利用を減らし、故にレイテンシを短縮する。
【0019】
図7は、ある実施の形態に従う、ゼロバッファコピーを提供するためのシステム300を示す。
図7に示されるように、アプリケーションサーバ302、ユーザスペース304、およびカーネルスペース306各々に、多数の異なる特徴を与えることができる。サーバレベルでは、バイトバッファを、静的バイト配列および一時バッファの代わりに使用することができる。たとえば、JSPコンパイラは、静的バイト配列の代わりにバイトバッファを使用することができる308。バイトバッファは、補助バイト配列をラップすることによって作成できる。バイトバッファおよび補助バイト配列のうちいずれか一方に対して行なわれた変更は他方に反映される。したがって、処理を行なう各層に対して新たなバイト配列を作成してからこのバイト配列をコピーして次の層のための新たなバイト配列にするのではなく、1つのバイト配列を保存しバイトバッファをこのバイト配列にラップすればよい。各層はバイト配列に対して処理を行なうので、変更はバイト配列に対して適用される。これは、必要なコピーの量を制限し、性能を改善する。同様に、サーブレットコンテナは、一時バッファにコピーする代わりにバイトバッファを使用することができ310、サーバコアは、カーネルレベルチャンクストリームの代わりにバイトバッファ認識ストリーム(byte buffer-aware streams)を使用することができ312、JVMが、コピーの代わりに固有のメモリをWLSバッファにピニング(pinning)できるようにする314。メモリをピニングすることにより、JVMは、確実に、メモリがごみ集め(garbage collection)の対象となったり他のプロセスによって使用されたりしないようにする。このように、データ処理における各段階で、メモリ内のデータへのポインタまたはリファレンスを、各段階でデータをコピーする代わりに、使用することができる。これらの改良により、サーバ層316におけるゼロコピーを実現し、CPUサイクルを少なくし性能を改善する。
【0020】
ある実施の形態に従うと、プラットフォームは、ユーザスペースで実行するJVMからカーネルスペースのネットワークスタックへのバイトバッファデータのコピーを回避するソケットダイレクトプロトコル(SDP)の使用もサポートする318。これにより、HTTP要求に応じながら、バッファコピーの数をさらに減じる。コピーを回避することにより、CPUサイクルがユーザおよびカーネルスペース双方において少なくなり、したがってHTTPトラフィックのレイテンシが短くなる。
【0021】
代表的な実施の形態では、アプリケーションサーバ(たとえばウェブロジックサーバ)を変形することにより、HTTP要求に応えながらゼロバッファコピーを実現することができる。ウェブロジックサーバJSPコンパイラは、静的JSPコンテンツを直接Java New I/O(NIO)バイトバッファに書込むことができる。実行時に、ウェブコンテナは、これらバイトバッファを直接、コピーせずに、バイトバッファ認識ウェブロジックサーバIOストリームに送ることができる。これらバイトバッファを次に、集合書出し(gathered write)を用いてNIOマルチプレクサによって直接書き出すことができる。エクサロジック上で実行するJVM(たとえばジェイロキットまたはホットスポットJVM)は、これらバイトバッファをメモリにピニングし、データを固有のメモリにコピーすることを回避する。
【0022】
図8は、ある実施の形態に従う、ゼロバッファコピーの方法のフローチャートを示す。ステップ400で、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムが与えられる。ステップ402で、Java仮想マシン(JVM)と1つ以上のアプリケーションサーバインスタンスとを含むユーザスペースが与えられる。ステップ404で、JVMにアクセス可能な複数のバイトバッファおよび1つ以上のアプリケーションサーバインスタンスが与えられる。ステップ406で、第1のアプリケーションサーバインスタンスが要求を受ける。ステップ408で、この要求に関連付けられたデータが、JVMに関連付けられたヒープ(heap)スペースに格納される。ステップ410で、JVMは、データが格納されているヒープスペースの一部をピニングする。ステップ412で、データは、第1のアプリケーションサーバインスタンスがアクセスする第1のバイトバッファに押出される。ステップ414で、第1のアプリケーションサーバがデータを用いて応答を生成する。ステップ416で、第1のアプリケーションサーバがこの応答を送信する。
【0023】
ある実施の形態に従うと、
図8に示される方法はさらに、ソケットダイレクトプロトコル(SDP)に対するサポートを含むカーネルスペースを与えるステップと、カーネルスペースおよびユーザスペースにアクセス可能な、1つ以上の、バイトバッファ認識ストリームを与えるステップとを含み得る。加えて、
図8に示される方法において、各バイトバッファはJava New I/Oバイトバッファであってもよい。さらに、要求はHTTP要求であってもよい。また、
図8に示される方法において、第1のバイトバッファはヒープスペース内のどこにデータが格納されているかを示すリファレンスを含んでいてもよい。
【0024】
分散/収集I/O
ある実施の形態に従うと、システムは、ネットワークパケットの細分化を最小にする分散/収集I/Oを用いることにより、OSがJava New I/O(NIO)の使用に基づいて細分化を行なうことができるようにする。加えて、ある実施の形態に従うと、システムは、最大転送単位(MTU)が64KBであるインフィニバンド上のインターネットプロトコル(Internet Protocol over InfiniBand (IPoIB))プロトコルを使用する。比較として、イーサネットのMTUは1.5KBである。IPoIBを用いることにより、アプリケーションサーバ、たとえばウェブロジックサーバは、一度により多くのデータを書込むことができる。加えて、典型的なイーサネット接続は約1Gb/sという速度を提供するが、インフィニバンドネットワークを用いることにより、上り速度40Gb/sを利用できる。これにより、フレキシビリティが増し、この接続を通してより多くのデータを送ることができる。理想的なのは、このような接続を利用するシステムが、ネットワークを通してより多くのデータを押出すことにより、利用できる帯域幅を飽和させ効率的に使用できるようにすることである。
【0025】
図9は、ある実施の形態に従う、イーサネットプロトコルを利用するシステムを示す。イーサネットネットワーク500を利用するシステムでは、データは比較的小さい部分にしか書込むことができない。
図9に示されるように、サーバ502はイーサネットネットワーク500を介してサーバ504に接続される。これら2つのサーバはシングルマルチプレクサ506および508を用いてシングルチャネルを通して通信する。
図9に示されるように、データ送信は、サーバに対して4KBのチャンクで通信することを強いるイーサネット接続によって、制限される。一度にこれよりも多くのデータを送信しようとすると、ネットワークの容量を超えてしまう。このため、カーネルレベルでより多くの作業を実施しなければならなくなる。具体的には、カーネルレベルは、データをより小さな単位に分割し、オンザフライのフロー制御を強要する。これは、時間およびリソースの浪費となる可能性がある。
【0026】
図10は、ある実施の形態に従う、IPoIBおよびパラレル多重化を利用するシステムを示す。上記のように、インフィニバンドネットワークは、典型的なイーサネット接続よりも大きい帯域幅を提供する。このより大きな帯域幅のおかげで、より大きなMTUを使用できる。
図10に示されるように、サーバ506はインフィニバンドネットワーク510上でサーバ508に接続される。インフィニバンドを通して利用できるより大きな帯域幅を用いることにより、システムは、イーサネットと比較して遥かに大きい64KBのチャンクでデータを押出すことができる。このようなシステムでは、カーネルレベルは帯域幅が増したことを認識しより大きなデータ単位を、データをより小さな単位に分割してフロー制御を強要するという追加の作業を実施することなく、押出す。
【0027】
ある実施の形態に従うと、クラスタ内では、複数のパラレル論理接続すなわちチャネルを、サーバ間で使用できる。そのため、より多くのデータを同時にサーバ間で送ることができるので、複数のスレッドを並列に実行できる。
図10に示されるように、各サーバはパラレルマルチプレクサ512、514を利用する。パラレルマルチプレクサは、さまざまな接続を管理することにより、確実に、複数のスレッドが互いに干渉またはブロックしないようにする。このため、利用できる帯域幅の使用がさらに改善され、サーバ間のデータ転送効率が改善される。
【0028】
図11は、ある実施の形態に従う、分散/収集I/Oを提供する方法のフローチャートを示す。ステップ600で、1つ以上の高性能コンピューティングシステムのクラスタが与えられる。各高性能コンピューティングシステムは、1つ以上のプロセッサと高性能メモリとを含み得る。クラスタは、インフィニバンドネットワーク上で通信できる。ステップ602で、クラスタ上で実行し1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境が与えられる。ステップ604で、複数のマルチプレクサが与えられる。各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含む。ステップ606で、第1のアプリケーションサーバインスタンス上の第1のマルチプレクサが、高性能メモリ内の複数の場所からデータを集める。ステップ608で、第1のマルチプレクサは、第2のアプリケーションサーバ上の第2のマルチプレクサにデータをまとめて転送する。
【0029】
ある実施の形態に従うと、
図11に示される方法はさらに、各マルチプレクサによって、複数のパラレルチャネルを通してデータを送信する複数のスレッドを管理することを含み得る。ユーザは、この複数のパラレルチャネルの中に含まれるパラレルチャネルの数を設定することができる。加えて、上記のように、各マルチプレクサはNew I/Oマルチプレクサであってもよい。さらに、各データ転送に分散/収集データ処理を用いてもよい。
【0030】
T3接続(パラレル多重化)
特に、本明細書に記載のように、システムおよび方法は、クラスタ内のサーバ間でのパラレル多重化のために提供される。1つのこのようなシステムは、各々が1つ以上のプロセッサと高性能メモリとを含む、1つ以上の高性能コンピューティングシステムのクラスタを含み得る。クラスタはインフィニバンドネットワーク上で通信する。システムはまた、クラスタ上で実行し1つ以上のアプリケーションサーバインスタンスを含む、ミドルウェア環境を含む。このシステムは複数のマルチプレクサをさらに含み得る。各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含む。各マルチプレクサは、情報を複数のスレッドから受け、異なるアプリケーションサーバインスタンス上の異なるマルチプレクサに、インフィニバンドネットワーク上で複数のパラレルチャネルを用いて送ることができる。
【0031】
図12は、ある実施の形態に従う、サーバ間のシングル接続を利用するシステムを示す。
図12に示されるように、典型的なクラスタ化シナリオでは、シングル接続700がサーバ702とサーバ704の間に設けられる。たとえば、サーバ702からの通信はシングルマルチプレクサ706に送られ、この通信はシングル接続700を通してサーバ704に送信される。サーバ704の対応するシングルマルチプレクサ708は、この通信をそれぞれの適切な宛先に送る。しかしながら、このシングル接続は、インフィニバンド(IB)ネットワーク内で利用できる帯域幅をすべて使用することができない。
【0032】
図13は、ある実施の形態に従う、サーバ間のパラレル接続を利用するシステムを示す。
図13に示されるように、複数のパラレル接続710をサーバ712とサーバ714の間で維持できる。各サーバは、パラレルマルチプレクサ716、718を含み、サーバ間の複数の接続を通して通信を並列に送る。ある実施の形態に従うと、T3または同様のプロトコルを変形して複数の接続を設けることができ、そうすれば、接続毎のボトルネックは回避され、インメモリセッションレプリケーションといった特徴のためにネットワーク帯域幅をより有効に利用できる。これにより、利用できるIB帯域幅をより有効に使用することができ、ピア(peer)間で、速度をほとんど低下させずにより効率的な通信を行なうことができる。
【0033】
上記のように、ある実施の形態に従うと、プラットフォームは、バックプレーンで、インフィニバンド上のインターネットプロトコル(IPoIB)ネットワークをサポートし、IBのネットワーク帯域幅は25Gbpsである。ウェブロジックサーバのT3のようなシングル接続はクラスタ通信に対しIB帯域幅を十分に利用できないので、複数の接続が並列に作成されてネットワーク帯域幅をより有効に利用している。複数の接続は、セッションレプリケーションネットワークトラフィックの拡大に役立つ。
【0034】
ある実施の形態に従うと、サーバ、たとえばT3プロトコルを用いるウェブロジックサーバは、すべてのスレッドからのメッセージを、シングルスレッドによってネットワーク上に一度に送出される単一の送信キューに集めることができる。複数のプロセスが、同一のロックが行なわれることを要求した場合、ロックコンテンションが生じ得る。たとえば、ロックコンテンションは、メッセージを送信キューに追加しようと試みているスレッド間で生じ得る。複数の接続を並列に作成することにより、ロックコンテンションは複数の接続に分散するため、1つの接続当たりのロックコンテンションは少なくなる。また、複数の送信スレッドがメッセージを遠隔のサーバインスタンスに送ると、ワークフローの並列化が生じる。
【0035】
ある実施の形態に従うと、暗黙レプリケーションチャネルを、ClusterMBean上に構成されたレプリケーションチャネルをテンプレートとして用いて作成することができる。作成される暗黙チャネルの数は、ServerMBean.getReplicationPorts ()属性に基づく。暗黙チャネルは、ClusterMBean. ReplicationChannelsからの属性付きのものすべてをコピーする一方で、ポート情報をオーバライドすることにより固有にしておく。オーバライドポート情報は、ServerMBean.getReplicationPorts ()から得られる。加えて、システムは、複数のチャネルを構成するか否か判断するのに使用できるユーティリティ機能を含み得る。このユーティリティは、構成の変更に応じて、および/またはユーザの指示に従って、この判断を一度、自動的に等間隔で、行ない、その結果を、後のコールに備えてキャッシュすることができる。システムはさらに、構成された各レプリケーションチャネルに対し排他的RMIスタブを作成することができる(各接続に割当てられるスタブ)。システムは、セッションIDをハッシュすることにより、たとえばラウンドロビンまたはその他同様のバランシングアルゴリズムを用いて、すべてのスタブ間でレプリケーション要求をバランシングする。このシステムはまた、レプリケーションコールを、サーバのために構成されたレプリケーションチャネルのうち1つで確実に受けることができるようにする。
【0036】
ある実施の形態に従うと、インフィニバンドの使用によって従来のシステムよりも大きな帯域幅が得られるので、データを送信できるより大きなパイプが効果的に与えられる。このより大きなパイプをより有効に利用するために、複数のパラレル論理接続すなわちチャネルを、シングル論理接続の代わりに使用することができる。複数の接続は、互いにブロックし合うさまざまな実行スレッドなしで、同時性がより高いアクティビティの実行が可能であることを意味する。これは、たとえばクラスタリングに、すなわち、複数のサーバがクラスタ内で互いに通信する場合に、役立ち得る。クラスタ内では、サーバ間のセッションデータレプリケーションが重要な特徴である。セッションデータは、たとえば、ウェブサイトへの特定の訪問またはセッションに特有のショッピングカートまたはその他のユーザデータである。クラスタ内のサーバ間に複数の接続を用いることにより、各サーバへのインメモリセッションレプリケーションをより確実にかつより効率的に行なうことができる。これは、サーバの障害に備えてセッションデータを格納し、エンドユーザおよびサービスプロバイダの経験を改善する。
【0037】
図14は、ある実施の形態に従う、クラスタ内のサーバ間におけるパラレル多重化を提供するための方法のフローチャートを示す。ステップ800で、1つ以上の高性能コンピューティングシステムのクラスタが与えられる。高性能コンピューティングシステムは各々、1つ以上のプロセッサと高性能メモリとを含み得る。加えて、クラスタはインフィニバンドネットワーク上で通信できる。ステップ802で、クラスタ上で実行するミドルウェア環境が与えられる。ミドルウェア環境は、1つ以上のアプリケーションサーバインスタンスを含み得る。ステップ804で、複数のマルチプレクサが与えられる。各アプリケーションサーバインスタンスは、少なくとも1つのマルチプレクサを含み得る。ステップ806で、第1のアプリケーションサーバインスタンスの第1のマルチプレクサが、情報を複数のスレッドから受信し、第2のアプリケーションサーバインスタンスの第2のマルチプレクサに送信する。ステップ808で、この情報は、インフィニバンドネットワーク上で、複数のパラレルチャネルを用いて、第2のマルチプレクサに送信される。
【0038】
ある実施の形態に従うと、
図14に示される方法はまた、ユーザからの入力に基づいて、複数のパラレルチャネルに含まれるパラレルチャネルの数を設定することを含み得る。加えて、送信される情報は、セッションデータを含み得る。さらに、各マルチプレクサはNew I/O(NIO)マルチプレクサであってもよい。
図14に示される方法は、さらに、複数のパラレルチャネル各々についてRMIスタブを作成することを含み得る。
【0039】
サーバクラスタ内でのインメモリセッションレプリケーション
ある実施の形態に従うと、システムは、遅延デシリアライゼーションという方法を用いて、サーバクラスタ内でのインメモリセッションレプリケーションをサポートすることができる。ミドルウェアマシンプラットフォームまたは環境は、アプリケーションサーバの1つ以上のクラスタを含み得る。システムは、ミドルウェアマシンプラットフォームが高い可用性を提供できるように、使用中の障害から回復することができる。ある実施の形態に従うと、セッション状態をミドルウェアマシンプラットフォームにおいて用いて、重要なユーザセッション情報を記憶する。システムは、インメモリレプリケーション(in-memory replication)およびJDBCベースの永続性(JDBC-based persistence)といった異なる方法を用いて、クラスタ間で、ユーザサービス要求に関連するセッション状態をレプリケートすることができる。システムは、インメモリレプリケーションを使用して、セッション状態を、あるサーバインスタンスから別のサーバインスタンスにコピーする。プライマリアプリケーションサーバは、クライアントが最初に接続するサーバ上にプライマリセッション状態を作成し、クラスタ内の別のサーバインスタンス上にセカンダリレプリカを作成する。レプリカは、プライマリアプリケーションサーバたとえばサーブレットをホストするサーバに障害が生じた場合に使用されることができるよう、最新状態に保たれる。JDBCベースの永続性の場合、システムは、セッション状態たとえばサーブレットまたはJSPのセッション状態を、ファイルベースまたはJDBCベースの永続性を用いて保持する。JDBCベースの永続性は、ワイドエリアネットワーク(WAN)内でのセッション状態レプリケーションにも使用される。
【0040】
ある実施の形態に従うと、システムは、シリアライズステップを行なうことにより、プライマリセッションデータをデータ送信のために変換することができる。シリアライズステップは、データのパラレルな配置といった複雑なデータ構造をシリアル形式に変換するプロセスである。データのパラレルな配置では、一度に多数のビットをパラレルチャネルに沿って送信する。一方、シリアル形式は一度に1ビットずつ送信する。シリアライズセッションデータは、セッション状態のレプリケーションのために何らかのオーバヘッドを導入する。オーバヘッドはシリアライズされるオブジェクトのサイズが大きいほど大きくなる。たとえば、ユーザがHTTPセッションの中で非常にサイズが大きなオブジェクトを作成しようと計画している場合、サーブレットの性能をテストして性能が許容範囲にあることを保証する必要がある。
【0041】
ある実施の形態に従うと、セッションのインメモリレプリケーションをサポートするためには、セッション状態がシリアライズ可能である必要がある。オブジェクトがシリアライズ可能であるとみなされるためには、オブジェクト内のすべてのフィールドが、シリアライズ可能または一時的である必要がある。たとえば、HTTPセッション状態内のすべてのサーブレットおよびJSPセッションデータがシリアライズ可能でなければならない。サーブレットまたはJSPが、シリアライズ可能なオブジェクトとシリアライズ不能なオブジェクトの組合せを使用する場合、システムはシリアライズ不能なオブジェクトのセッション状態をレプリケートしないことがある。
【0042】
ある実施の形態に従うと、セッション状態は、システムが提供する機能を用いて変更できる。たとえば、特殊機能であるHttpSession.setAttribute ()を用いて、javax.servlet.http.HttpSessionを実装するHTTPサーブレット内のセッションオブジェクトにおける属性を変更することができる。ユーザがsetAttributeを用いてセッションオブジェクトにおける属性を設定する場合、オブジェクトおよびその属性は、インメモリレプリケーションを用いてクラスタ内でレプリケートされる。ユーザが他の設定方法を用いてセッション内でオブジェクトを変更する場合、システムはこういった変更をレプリケートしないことがある。セッション内のオブジェクトに変更がなされる度に、setAttribute()を呼び出してそのオブジェクトをクラスタ間で更新することができる。同様に、removeAttribute()を用いて属性をセッションオブジェクトから削除することができる。
【0043】
図15は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。
図15に示されるように、クライアント901は、プライマリアプリケーションサーバ902とセカンダリアプリケーションサーバ903とを含むサーバクラスタ900と対話できる。プライマリアプリケーションサーバは、ステップ921で、クライアントからセッション911に関連付けられた要求を受け、このセッションに関連付けられたセッション情報912を保持する。プライマリアプリケーションサーバは、セッション情報に基づいてクライアントに対して応答することもできる。さらに、セカンダリアプリケーションサーバは、ステップ922で、プライマリアプリケーションサーバからシリアライズされたセッション情報913を受けて保持するように機能する。
【0044】
ある実施の形態に従うと、クライアントとプライマリアプリケーションサーバとの対話中、プライマリアプリケーションサーバで保持されているセッション情報をステップ924で変更することができる。実行時に、プライマリアプリケーションサーバはこれらセッション更新904をステップ925でセカンダリアプリケーションサーバに送信することができる。また、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けたセッション更新に基づいて、格納されているシリアライズされたセッション情報を更新するように機能する。
【0045】
ある実施の形態に従うと、シリアライズされたセッションデータを、バイナリフォーマットで、たとえば、バイト配列として、セカンダリアプリケーションサーバに格納することができる。システムは、異なるロジックを適用して、シリアライズされたバイナリセッションデータを効率的に更新することができる。ある実施の形態では、システムが、特定のセッション更新の影響を受ける、セカンダリアプリケーションサーバ内のバイト配列におけるエントリを検出する。次にシステムは、バイト配列内のシリアライズされたセッションデータ全体を置換しなくても、直接、バイト配列内の影響を受けたエントリを更新することができる。これは特に、格納されたシリアライズされたセッションデータのサイズが大きいときに有用である。
【0046】
ある実施の形態に従うと、プライマリアプリケーションサーバに障害が生じると、セカンダリアプリケーションサーバが、ステップ923で、更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報914を生成するように機能する。セカンダリアプリケーションサーバまたはミドルウェア環境内の別のアプリケーションサーバは、デシリアライズされたセッション情報を用いステップ926でクライアントに応答することができる。
【0047】
ある実施の形態に従うと、システムは、プライマリアプリケーションサーバに障害が生じた場合に限り、デシリアライズステップを実行することによって、インメモリセッションレプリケーションプロセスを最適化することができる。この最適化によって、プライマリアプリケーションサーバが動作している場合には、デシリアライズ動作を防止する。このような最適化により、システムは、すべてのセッション更新について、特にセッション更新が頻繁である場合にCPU利用コストおよびレイテンシオーバヘッドの点で費用がかかる、シリアライズステップをプライマリアプリケーションサーバで行ないデシリアライズステップをセカンダリアプリケーションサーバで行なうことを、回避できる。
【0048】
ある実施の形態に従うと、ユーザはさらに、レプリケーショングループを用いて、セカンダリ状態が位置する場所を制御することができる。レプリケーショングループは、セッション状態のレプリカを格納するのに使用されるクラスタ化されたサーバの優先順リストである。ユーザは、サーバを、レプリケーショングループと、サーバ上に作成されたプライマリHTTPセッション状態のシリアライズされたレプリカをホストするための好ましいセカンダリレプリケーショングル―プとに、割当てることができる。クライアントがクラスタ内のサーバに接続されプライマリセッション状態を作成すると、プライマリ状態をホストしているサーバは、クラスタ内の他のサーバを順位付けして、どのサーバがセカンダリをホストすべきか決定する。サーバの順位は、サーバの場所(プライマリアプリケーションサーバと同じマシン上にあるか否か)と、プライマリアプリケーションサーバの優先レプリケーショングループのメンバーであるか否かの組合せを用いて、割当てられる。
【0049】
図16は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするための代表的なフローチャートを示す。
図16に示されるように、プライマリアプリケーションサーバは、ステップ1001で、セッションに関連付けられた要求をクライアントから受ける。プライマリアプリケーションサーバはまた、セッションに関連付けられたセッション情報を保持し、セッション情報に基づいてクライアントに応答する。次に、ステップ1002で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバからシリアライズされたセッション情報を受けて保持することができる。ステップ1003で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けた1つ以上のセッション更新に基づいて、シリアライズされたセッション情報をさらに更新できる。最後に、ステップ1004で、プライマリアプリケーションサーバに障害が生じた場合に限り、更新されたシリアライズされたセッション情報をデシリアライズすることができ、アプリケーションサーバはこのデシリアライズされたセッション情報に基づいてクライアントに応答できる。
【0050】
HTTPセッションレプリケーション
クラスタ内でのサーブレットおよびJSPの自動レプリケーションおよびフェイルオーバをサポートするために、システムは、HTTPセッション状態を保持する2つのメカニズム、すなわちハードウェアロードバランサとプロキシプラグインをサポートすることができる。
【0051】
ある実施の形態に従うと、プライマリアプリケーションサーバに障害が発生したとき、ロードバランシングハードウェアは、クライアントからの要求を、アプリケーションサーバクラスタ内で使用可能な任意のサーバに、単純にリダイレクトすればよい。このクラスタは、クライアントのHTTPセッション状態のレプリカを、クラスタ内のセカンダリアプリケーションサーバから、取得できる。
【0052】
図17は、ある実施の形態に従う、ロードバランサを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。
図17に示されるように、ステップ1121で、ウェブアプリケーションのクライアント1101が、パブリックIPアドレスを用いてサーブレットを要求すると、ロードバランサ1110は、その構成済みのポリシーに従って、クライアントの接続要求を、アプリケーションサーバクラスタ1100に転送する。ステップ1122で、システムは、この要求を、クライアントのサーブレットセッション状態のプライマリホストとして機能するアプリケーションサーバA1102に転送する。ステップ1123で、システムは、順位付けシステムを用いて、セカンダリアプリケーションサーバB1103を、セッションに関連するシリアライズされたセッション状態をホストするサーバとして選択する。
【0053】
ステップ1124で、クライアントは、アプリケーションサーバインスタンスAおよびB双方の場所をローカルクッキー1111に記録することができる。クライアントがクッキーを許可しなければ、プライマリおよびセカンダリアプリケーションサーバの記録は、URL書換を介してクライアントに戻されるURLに記録できる。
【0054】
クライアントがクラスタに対してさらに要求を行なう場合、ロードバランサは、クライアント側のクッキーにある識別子を用いて、確実に、この要求が、クラスタ内の別のサーバにロードバランスされるのではなく、引続きアプリケーションサーバAに送られるようにする。これにより、クライアントは確実に、セッションが終了するまで、プライマリセッションのオブジェクトをホストしているサーバとの関係を維持する。
【0055】
接続に障害が発生すると、ステップ1125で、ロードバランシングハードウェアは、その構成済みのポリシーを用いて、要求を、クラスタ内で使用可能なサーバに送る。上記の例では、サーバAに障害が発生すると、その後、ロードバランサがクライアントの要求をアプリケーションサーバC1104に送ると想定している。クライアントがサーバCに接続すると、サーバはクライアントのクッキー内の情報を、または、URL書換が使用される場合はHTTP要求内の情報を用いて、サーバBに接続する。アプリケーションサーバCはさらに、ステップ1126で、サーバB上のシリアライズされたセッション状態をデシリアライズすることによってセッション状態をさらに取得することができる。このフェイルオーバプロセスは、クライアントに意識させることはない。デシリアライズステップは、接続障害後一度実行するだけでよい。サーバCはクライアントのプライマリセッション状態の新ホストとなり、サーバBは引続きシリアライズされたセッション状態のホストでありステップ1127でサーバCからセッション更新を受ける。この、プライマリおよびセカンダリホストに関する新情報は、クライアントのクッキー内でまたはURL書換で再び更新される。
【0056】
ある実施の形態に従うと、アプリケーションサーバプロキシプラグインは、クラスタ化されたサーブレットまたはJSPのホストであるアプリケーションサーバインスタンスのリストを保持し、ラウンドロビン方式を用いてHTTP要求をそれらのインスタンスに転送する。このプラグインは、アプリケーションサーバインスタンスに障害が生じた場合に、クライアントのHTTPセッション状態のシリアライズされたレプリカの位置を求めるのに必要なロジックも提供する。
【0057】
図18は、ある実施の形態に従う、プロキシプラグインを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。
図18に示されるように、ステップ1221でHTTPクライアント1201がサーブレットを要求すると、HTTPサーバ1210上のHttpClusterServlet1212がプロキシとして機能し、この要求をアプリケーションサーバクラスタ1200に転送する。HttpClusterServletは、クラスタ内のすべてのサーバのリストと、クラスタにアクセスするときに使用するロードバランシングロジックとを保持する。上記の例では、HttpClusterServletは、ステップ1222でクライアントのサーブレットセッションをホストするプライマリアプリケーションサーバになるアプリケーションサーバA1202上でホストされているサーブレットに、クライアント要求を送ることができる。
【0058】
サーブレットのフェイルオーバサービスを提供するために、プライマリアプリケーションサーバは、ステップ1222で、シリアライズされたクライアントのサーブレットセッション状態を、クラスタ内のセカンダリアプリケーションサーバに送る。上記の例では、アプリケーションサーバB1203が、セカンダリアプリケーションサーバとして選択される。
【0059】
サーブレットページは、HttpClusterServletを通してクライアントに返すことができ、クライアントブラウザは、ステップ1224で、サーブレットセッション状態のプライマリおよびセカンダリの場所のリストを有するクッキー1211に書込むよう指示される。クライアントブラウザがクッキーをサポートしないのであれば、アプリケーションサーバはその代わりにURL書換を用いることができる。
【0060】
プライマリアプリケーションサーバAに障害が発生すると、HttpClusterServletは、クライアントのクッキー情報を用いて、セッション状態のレプリカをホストするセカンダリアプリケーションサーバの場所を特定することができる。HttpClusterServletは、ステップ1225で、クライアントの次のHTTP要求をセカンダリアプリケーションサーバに自動的にリダイレクトすることができる。このフェイルオーバはクライアントに意識させることはない。ステップ1226で、サーバBはシリアライズされたセッション状態をデシリアライズすることができ、セッション状態を取得する。
【0061】
この障害後、サーバBがサーブレットセッション状態をホストするプライマリアプリケーションサーバになり、新たなセカンダリを、たとえばアプリケーションサーバC604上に作成することができる。ステップ1227で、サーバCは、シリアライズされたセッション状態をホストし、サーバBからセッション更新を受けることができる。HTTP応答では、プロキシはクライアントのクッキーを更新して新たなプライマリおよびセカンダリアプリケーションサーバを反映させ、今後のフェイルオーバの可能性に備える。
【0062】
クラスタ間でのセッションレプリケーション
ある実施の形態に従うと、アプリケーションサーバは、クラスタ内のサーバ間でのHTTPセッション状態レプリケーションに加えて、複数のクラスタ間でHTTPセッション状態をレプリケートする機能を提供する。これにより、クラスタを複数の地理的領域、送電網、およびインターネットサービスプロバイダに分散させることによって、高い可用性および耐障害性が改善される。
【0063】
図19は、ある実施の形態に従う、サーバクラスタ間でのインメモリセッションレプリケーションをサポートするシステムの例を示す。
図19に示されるように、クラスタ間でのレプリケーションをサポートするネットワーク構成において、グローバルロードバランサ1302は、クラスタ1305とクラスタ1306との間でHTTP要求をバランシングする役割を果たす。ステップ1311で、クライアント1301からの要求を受けると、グローバルロードバランサは、各クラスタが現在扱っている要求の数に基づいて、要求をいずれのクラスタに送るかを決定する。次に、要求は、ステップ1312または1313で、選択されたクラスタのローカルロードバランサ1303または1304に送られる。ローカルロードバランサは、グローバルロードバランサからHTTP要求を受けると、ステップ1314または1315で、クラスタ内のサーバ間でHTTP要求をバランシングする役割を果たす。
【0064】
セッションデータを1つのクラスタから別のクラスタにレプリケートするために、レプリケーションチャネル1310を、プライマリクラスタからセカンダリクラスタにセッション状態情報を伝えるように構成することができる。レプリケーションチャネルは、クラスタ間のレプリケーショントラフィック専用のネットワークチャネルであってもよい。クラスタ内のサーバに障害が発生すると、ローカルロードバランサは、要求をクラスタ内の他のサーバに転送する役割を果たす。クラスタ全体に障害が生じた場合、ローカルロードバランサはHTTP要求をグローバルロードバランサに返す。グローバルロードバランサは次にこの要求を他のローカルロードバランサにリダイレクトする。
【0065】
本発明は、1つ以上のプロセッサ、メモリ、および/または本開示の教示に従いプログラムされたコンピュータ可読記憶媒体を含む、従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを1つ以上用いて、適宜実現し得る。適切なソフトウェアコーディングは、熟練したプログラマが本開示の教示に基づいて容易に準備できる。これはソフトウェア技術の当業者には明らかであろう。
【0066】
実施の形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された記憶媒体または(1つまたは複数の)コンピュータ可読記憶媒体であるコンピュータプログラムプロダクトを含む。この記憶媒体は、フロッピーディスク(登録商標)、光ディスク、DVD、CD−ROM、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム(分子メモリICを含む)、または、命令および/またはデータを記憶するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。
【0067】
本発明に関するこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって当業者が本発明のさまざまな実施の形態および意図している実際の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は、以下の特許請求の範囲およびその均等物によって定められることが意図されている。