5945543 ミドルウェアマシン環境を含むシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5945543

(24)【登録日】2016年6月3日

(45)【発行日】2016年7月5日

(54)【発明の名称】ミドルウェアマシン環境を含むシステム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20160621BHJP

   G06F 9/54 20060101ALI20160621BHJP

【ＦＩ】

   G06F9/46 462Z

   G06F9/46 480Z

【請求項の数】20

【全頁数】26

(21)【出願番号】特願2013-529312(P2013-529312)

(86)(22)【出願日】2011年9月15日

(65)【公表番号】特表2013-543169(P2013-543169A)

(43)【公表日】2013年11月28日

(86)【国際出願番号】US2011051697

(87)【国際公開番号】WO2012037310

(87)【国際公開日】20120322

【審査請求日】2014年6月6日

(31)【優先権主張番号】13/170,490

(32)【優先日】2011年6月28日

(33)【優先権主張国】US

(31)【優先権主張番号】13/167,636

(32)【優先日】2011年6月23日

(33)【優先権主張国】US

(31)【優先権主張番号】13/109,871

(32)【優先日】2011年5月17日

(33)【優先権主張国】US

(31)【優先権主張番号】13/109,849

(32)【優先日】2011年5月17日

(33)【優先権主張国】US

(31)【優先権主張番号】61/384,227

(32)【優先日】2010年9月17日

(33)【優先権主張国】US

(31)【優先権主張番号】61/383,285

(32)【優先日】2010年9月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】レバヌル，ナレシュ

(72)【発明者】

【氏名】ビハニ，バラブ

(72)【発明者】

【氏名】ラルセン，スタファン

(72)【発明者】

【氏名】リウ，スティーブン

(72)【発明者】

【氏名】ファン，レニー

(72)【発明者】

【氏名】オークス，スコット

(72)【発明者】

【氏名】トルステンソン，パトリック

(72)【発明者】

【氏名】メッシンガー，アダム

(72)【発明者】

【氏名】レイノルズ，ネイサン

(72)【発明者】

【氏名】オテンコ，オレクサンドル

(72)【発明者】

【氏名】ドーア，ジョシュア

(72)【発明者】

【氏名】キャメロン，ブラッド

(72)【発明者】

【氏名】トルドバッケン，オラ

(72)【発明者】

【氏名】バッタチャリヤ，パラブ

【審査官】 大塚 俊範

(56)【参考文献】

【文献】 特開２０１０−１２８９１１（ＪＰ，Ａ）

【文献】 特表２００８−５０７０３０（ＪＰ，Ａ）

【文献】 特開２００３−１９６２２９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／００９８１１９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００３／００７８９５８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／５４

(57)【特許請求の範囲】

【請求項1】

ミドルウェアマシンを提供するためのシステムであって、
１つ以上の高性能コンピューティングハードウェアシステムを備え、
各前記高性能コンピューティングハードウェアシステムは、１つ以上のプロセッサと、高性能メモリと、ネットワーキングとを含み、
前記ハードウェアシステム上で機能し、１つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境、および１つ以上のＪａｖａ（登録商標）仮想マシン（ＪＶＭ）を、さらに備え、各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含み、
前記アプリケーションサーバインスタンスは要求を処理するための複数の層を有し、当該アプリケーションサーバインスタンスが当該要求を受けたときに、
前記要求に関連付けられたデータが前記ＪＶＭに関連付けられたヒープスペースのバイト配列に格納され、各前記層は、１つ以上のバイトバッファを介してデータに対する変更を適用し、各前記バイトバッファは、前記Ｊａｖａ仮想マシンと前記アプリケーションサーバインスタンスによりアクセス可能であり、および前記データへのポインタを含み、
応答は、前記アプリケーションサーバインスタンスにより前記データを用いて生成され、および１つ以上のバイト配列から収集され、および、
前記応答は、送信キューにより複数のスレッドから受信されて、および、前記マルチプレクサを用いて、当該マルチプレクサに関連付けられた複数のパラレルチャネルを介して、異なる前記アプリケーションサーバインスタンスに転送する、システム。

【請求項2】

ミドルウェアマシンを提供するためのシステムであって、
１つ以上の高性能コンピューティングハードウェアシステムを備え、
各前記高性能コンピューティングハードウェアシステムは、１つ以上のプロセッサと、高性能メモリと、ネットワーキングとを含み、
前記ハードウェアシステム上で機能し、１つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境、および１つ以上のＪａｖａ仮想マシン（ＪＶＭ）を、さらに備え、各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含み、
前記アプリケーションサーバインスタンスは要求を処理するための複数の層を有し、当該アプリケーションサーバインスタンスが当該要求を受けたときに、
前記要求に関連付けられたデータが前記ＪＶＭに関連付けられたヒープスペースのバイト配列に格納され、各前記層は、１つ以上のバイトバッファを介してデータに対する変更を適用し、各前記バイトバッファは、前記Ｊａｖａ仮想マシンと前記アプリケーションサーバインスタンスによりアクセス可能であり、および前記データへのポインタを含む、システム。

【請求項3】

前記ミドルウェアマシンを提供するためのシステムは、さらに、
前記要求に対する応答を、前記アプリケーションサーバインスタンスにより前記データを用いて生成され、および１つ以上のバイト配列から収集する、請求項２に記載のシステム。

【請求項4】

前記ミドルウェアマシンを提供するためのシステムは、さらに、
前記応答を、送信キューにより複数のスレッドから受信し、
前記応答を、前記マルチプレクサを用いて、当該マルチプレクサに関連付けられた複数のパラレルチャネルを介して、異なる前記アプリケーションサーバインスタンスに転送する、請求項３に記載のシステム。

【請求項5】

前記ミドルウェアマシンを提供するためのシステムはさらに、
前記１つ以上のＪａｖａ仮想マシン（ＪＶＭ）および１つ以上のアプリケーションサーバインスタンスを含むユーザスペースを備え、
前記ＪＶＭが、前記データが格納されるヒープスペースの部分をピニングする、請求項１から４のいずれか１項に記載のシステム。

【請求項6】

前記ミドルウェアマシンを提供するためのシステムはさらに、
各々が１つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信する、請求項１から５のいずれか１項に記載のシステム。

【請求項7】

前記ミドルウェアマシンを提供するためのシステムはさらに、
各々が１つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、
前記複数のパラレルチャネルは、テンプレートからの属性のコピー、および属性におけるポート情報の上書きにより、テンプレートから生成された１つ以上のレプリケーションチャンネルを有する、請求項１または４に記載のシステム。

【請求項8】

前記ミドルウェアマシンを提供するためのシステムはさらに、
クライアントからセッションに関連付けられた要求を受けるように機能するプライマリアプリケーションサーバを備え、前記プライマリアプリケーションサーバは、クラスタされたサーバのレプリケーショングループから選択されて、前記セッションに関連付けられたセッション情報を保持し前記セッション情報に基づいて前記クライアントに応答し、
前記プライマリアプリケーションサーバからシリアライズされたセッション情報を受信し保持するように機能するセカンダリアプリケーションサーバを備え、前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバから受信した１つ以上のセッション更新に基づいて、前記シリアライズされたセッション情報を更新するように機能し、
前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバに障害が生じたときに限り、前記更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報を生成するように機能し、前記デシリアライズされたセッション情報に基づいてクライアントに応答する、請求項１から７のいずれか１項に記載のシステム。

【請求項9】

ミドルウェアマシンを提供するシステムにおいて実施される方法であって、
前記ミドルウェアマシンを提供するシステムは、
１つ以上の高性能コンピューティングハードウェアシステムを備え、
各前記高性能コンピューティングハードウェアシステムは、１つ以上のプロセッサと、高性能メモリと、ネットワーキングとを含み、
前記方法は、
前記ハードウェアシステム上に、１つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境、および１つ以上のＪａｖａ仮想マシン（ＪＶＭ）を準備するステップを備え、
各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含み、前記アプリケーションサーバインスタンスは要求を処理するための複数の層を有し、
前記方法は、当該アプリケーションサーバインスタンスが当該要求を受けたときに、
前記要求に関連付けられたデータを前記ＪＶＭに関連付けられたヒープスペースのバイト配列に格納するステップと、
各前記層により、１つ以上のバイトバッファを介してデータに対する変更を適用するステップと、を備え、
各前記バイトバッファは、前記Ｊａｖａ仮想マシンと前記アプリケーションサーバインスタンスによりアクセス可能であり、および前記データへのポインタを含み、
前記方法は、
応答を、前記アプリケーションサーバインスタンスにより前記データを用いて生成し、および１つ以上のバイト配列から収集するステップと、
前記応答を、送信キューにより複数のスレッドから受信するステップと
前記応答を、前記マルチプレクサを用いて、当該マルチプレクサに関連付けられた複数のパラレルチャネルを介して、異なる前記アプリケーションサーバインスタンスに転送するステップと、を備える、方法。

【請求項10】

ミドルウェアマシンを提供するためのシステムにおいて実施される方法であって、
前記ミドルウェアマシンを提供するシステムは、
１つ以上の高性能コンピューティングハードウェアシステムを備え、
各前記高性能コンピューティングハードウェアシステムは、１つ以上のプロセッサと、高性能メモリと、ネットワーキングとを含み、
前記方法は、
前記ハードウェアシステム上で機能し、１つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境、および１つ以上のＪａｖａ仮想マシン（ＪＶＭ）を、準備するステップを備え、
各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含み、
前記アプリケーションサーバインスタンスは要求を処理するための複数の層を有し、
前記方法は、
当該アプリケーションサーバインスタンスが当該要求を受けたときに、
前記要求に関連付けられたデータを前記ＪＶＭに関連付けられたヒープスペースのバイト配列に格納するステップと、
各前記層は、１つ以上のバイトバッファを介してデータに対する変更を適用するステップと、を備え、
各前記バイトバッファは、前記Ｊａｖａ仮想マシンと前記アプリケーションサーバインスタンスによりアクセス可能であり、および前記データへのポインタを含む、方法。

【請求項11】

前記方法は、
応答を、前記アプリケーションサーバインスタンスにより前記データを用いて生成し、および１つ以上のバイト配列から収集するステップを、さらに備える、請求項１０に記載の方法。

【請求項12】

前記方法は、
前記応答を、送信キューにより複数のスレッドから受信するステップと
前記応答を、前記マルチプレクサを用いて、当該マルチプレクサに関連付けられた複数のパラレルチャネルを介して、異なる前記アプリケーションサーバインスタンスに転送するステップと、をさらに備える、請求項１１に記載の方法。

【請求項13】

前記ミドルウェアマシンを提供するためのシステムは、
前記１つ以上のＪａｖａ仮想マシン（ＪＶＭ）および１つ以上のアプリケーションサーバインスタンスを含むユーザスペースと、
前記ＪＶＭにアクセス可能な複数のバイトバッファおよび１つ以上のアプリケーションサーバインスタンスと、を備え、
前記方法は、
前記ＪＶＭが、データが格納されるヒープスペースの部分をピニングするステップを含む、請求項９から１２のいずれか１項に記載の方法。

【請求項14】

前記ミドルウェアマシンを提供するためのシステムはさらに、
各々が１つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信する、請求項９から１３のいずれか１項に記載の方法。

【請求項15】

前記ミドルウェアマシンを提供するためのシステムは、
各々が１つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、
複数のパラレルチャネルは、１つ以上のレプリケーションチャンネルを有し、
前記方法は、さらに、
テンプレートからの属性のコピー、および属性におけるポート情報の上書きにより、テンプレートから前記１つ以上のレプリケーションチャンネルを生成するステップを、含む、請求項９または１２に記載の方法。

【請求項16】

前記方法はさらに、
プライマリアプリケーションサーバを、クライアントからセッションに関連付けられた要求を受けるように機能させるステップを含み、前記プライマリアプリケーションサーバは、クラスタされたサーバのレプリケーショングループから選択されて、前記セッションに関連付けられたセッション情報を保持し前記セッション情報に基づいて前記クライアントに応答し、
セカンダリアプリケーションサーバを、前記プライマリアプリケーションサーバからシリアライズされたセッション情報を受信し保持するように機能させるステップを含み、前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバから受信した１つ以上のセッション更新に基づいて、前記シリアライズされたセッション情報を更新するように機能し、
前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバに障害が生じたときに限り、前記更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報を生成するように機能し、前記デシリアライズされたセッション情報に基づいてクライアントに応答する、請求項９から１５のいずれか１項に記載の方法。

【請求項17】

前記ミドルウェアマシンを提供するためのシステムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンドネットワークを提供する、満杯の、２分の１の、もしくは４分の１のラックとしてまたはその他の構成として準備される、請求項９から１６のいずれか１項に記載の方法。

【請求項18】

前記満杯の、２分の１の、もしくは４分の１のラックまたはその他の構成は、インフィニバンドネットワークを介して互いに通信する、１つ以上の計算ノード、インフィニバンドスイッチゲートウェイ、およびストレージノードまたはユニットを含む、請求項１７に記載の方法。

【請求項19】

前記ミドルウェア環境は、アプリケーションサーバ、ミドルウェア、ならびに、ウェブロジックサーバ、ジェイロキットまたはホットスポットＪＶＭ、オラクルリナックス（登録商標）またはソラリス、およびオラクルＶＭといったその他の機能を提供する、請求項９から１８のいずれか１項に記載の方法。

【請求項20】

１つ以上のコンピュータシステムにロードされこのシステムによって実行されたときに、請求項９から１９のいずれか１項に記載の方法を前記１つ以上のコンピュータシステムに実施させる、プログラム可読命令を含む、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を保有する。

【0002】

発明の分野
本発明は、概してコンピュータシステムおよびミドルウェアといったソフトウェアに関し、特にミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法に関する。

【背景技術】

【0003】

背景
どのような大きな組織でも、その中では、長年を経て、さまざまな異なるコンピュータハードウェア、オペレーティングシステム、およびアプリケーションソフトウェアを含むＩＴインフラストラクチャが無秩序に拡大していることが多い。このようなインフラストラクチャの個々の構成要素自体は巧みに設計され適切に維持管理されているかもしれないが、このような構成要素を相互に接続、または、リソースを共有しようとすると、それは困難な管理タスクであることが多い。近年、組織の関心は、仮想化およびストレージの集中化といった技術に向けられるようになっており、さらに近年では、共有インフラストラクチャの基礎を提供できるクラウドコンピューティングに向けられている。しかしながら、このような環境に特に適したオールインワンのプラットフォームはほとんどない。これらが、本発明の実施の形態が取組もうとしている一般的な分野である。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
本明細書では、ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法について説明する。ある実施の形態に従うと、このシステム（本明細書において実装形態によっては「エクサロジック（Exalogic）」と呼ぶ）は、高性能ハードウェアと、アプリケーションサーバまたはミドルウェア環境との組合せを含むことにより、完全なＪａｖａ（登録商標）ＥＥアプリケーションサーバ複合体を提供する。この複合体は、大規模並列処理インメモリグリッドを含み、素早くプロビジョニングすることができ、要求に応じて拡大縮小できる。ある実施の形態に従うと、このシステムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンド（InfiniBand）ネットワークを提供する、満杯の、２分の１の、もしくは４分の１のラックとしてまたはその他の構成として準備できる。これは、アプリケーションサーバの、ミドルウェアの、または、たとえばウェブロジック（WebLogic）サーバ、ジェイロキット（JRockit）ＪＶＭ、オラクルリナックス（Linux）（登録商標）、およびオラクルＶＭといった他の機能の実行をサポートする。このシステムのさらに他の特徴は、例として、ゼロバッファコピー（Zero Buffer Copy）、分散／収集（Scatter/Gather）Ｉ／Ｏ、Ｔ３接続、および遅延デシリアライゼーション（Lazy Deserialization）を含み得る。

【図面の簡単な説明】

【0005】

【図1】ある実施の形態に従うミドルウェアマシン環境の例を示す。

【図2】ある実施の形態に従うミドルウェアマシンプラットフォームまたは環境の別の例を示す。

【図3】ある実施の形態に従う、４分の１ラック構成として提供されるミドルウェアマシンの例を示す。

【図4】ある実施の形態に従う、２分の１ラック構成として提供されるミドルウェアマシンの例を示す。

【図5】ある実施の形態に従う、満杯ラック構成として提供されるミドルウェアマシンの例を示す。

【図6】ある実施の形態に従う、他のシステムおよびネットワークとのインターフェイスのために使用できるミドルウェアマシンプラットフォームまたは環境の例を示す。

【図7】ある実施の形態に従う、ゼロバッファコピーを提供するためのシステムを示す。

【図8】ある実施の形態に従う、ゼロバッファコピーの方法のフローチャートを示す。

【図9】ある実施の形態に従う、イーサネット（登録商標）プロトコルを利用するシステムを示す。

【図10】ある実施の形態に従う、ＩＰｏＩＢおよびパラレル多重化を利用するシステムを示す。

【図11】ある実施の形態に従う、分散／収集Ｉ／Ｏを提供する方法のフローチャートを示す。

【図12】ある実施の形態に従う、サーバ間のシングル接続を利用するシステムを示す。

【図13】ある実施の形態に従う、サーバ間のパラレル接続を利用するシステムを示す。

【図14】ある実施の形態に従う、クラスタ内のサーバ間におけるパラレル多重化を提供する方法のフローチャートを示す。

【図15】ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーション（replication）をサポートするシステムの例を示す。

【図16】ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするための代表的なフローチャートを示す。

【図17】ある実施の形態に従う、ロードバランサ（load balancer）を用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。

【図18】ある実施の形態に従う、プロキシプラグイン（proxy plug-in）を用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。

【図19】ある実施の形態に従う、サーバクラスタ間でのインメモリセッションレプリケーションをサポートするシステムの例を示す。

【発明を実施するための形態】

【0006】

詳細な説明
上記のように、どのような大きな組織でも、その中では、長年を経て、さまざまな異なるコンピュータハードウェア、オペレーティングシステム、およびアプリケーションソフトウェアを含むＩＴインフラストラクチャが無秩序に拡大していることが多い。このようなインフラストラクチャの個々の構成要素自体は巧みに設計され適切に維持管理されているかもしれないが、このような構成要素を相互に接続、または、リソースを共有しようとすると、それは困難な管理タスクであることが多い。近年、組織の関心は、仮想化およびストレージの集中化といった技術に向けられるようになっており、さらに近年では、共有インフラストラクチャの基礎を提供できるクラウドコンピューティングに向けられている。しかしながら、このような環境に特に適したオールインワンのプラットフォームはほとんどない。

【0007】

これに対し、本明細書では、ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法について説明する。ある実施の形態に従うと、このシステム（本明細書において実装形態によっては「エクサロジック」と呼ぶ）は、たとえば６４ビットプロセッサ技術、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキングといった高性能ハードウェアと、ウェブロジックスイート（WebLogic Suite）といったアプリケーションサーバまたはミドルウェア環境との組合せを含むことにより、完全なＪａｖａ ＥＥアプリケーションサーバ複合体を提供する。この複合体は、大規模並列処理インメモリグリッドを含み、素早くプロビジョニングすることができ、要求に応じて拡大縮小できる。ある実施の形態に従うと、このシステムは、アプリケーションサーバグリッドと、ストレージエリアネットワークと、インフィニバンドネットワークとを提供する、満杯の、２分の１の、もしくは４分の１のラックとしてまたはその他の構成として準備できる。ミドルウェアマシンソフトウェアは、アプリケーションサーバ、ミドルウェア、および、たとえばウェブロジックサーバ、ジェイロキットまたはホットスポット（Hotspot）ＪＶＭ、オラクルリナックスまたはソラリス（Solaris）、およびオラクルＶＭといった他の機能を提供できる。ある実施の形態に従うと、このシステムは、インフィニバンドネットワークを介して互いに通信する、複数の計算ノードと、インフィニバンドスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。

【0008】

ラック構成として実装される場合、ラックの未使用部分は、空のままでもフィラー（filler）によって占められてもよい。このシステムのさらに他の特徴は、例として、ゼロバッファコピー、分散／収集Ｉ／Ｏ、Ｔ３接続、および遅延デシリアライゼーションを含み得る。

【0009】

図１は、ある実施の形態に従うミドルウェアマシン環境１００の例を示す。図１に示されるように、各ミドルウェアマシンシステム１０２は、数個のミドルウェアマシンラック構成要素１０４を含み、ミドルウェアマシンラック構成要素１０４は各々、高性能ミドルウェアマシンハードウェアノード１０６（たとえば６４ビットプロセッサ、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキング）と、ミドルウェアマシンソフトウェア環境１０８との組合せを含む。これにより、数日または数カ月ではなく数分でプロビジョニングすることができ、要求に応じて拡大縮小できる、完全なアプリケーションサーバ環境を提供できる。

【0010】

ある実施の形態に従うと、各ミドルウェアマシンシステムは、満杯の、２分の１の、もしくは４分の１のラックとしてまたはラック構成要素からなるその他の構成として準備することができ、数個のミドルウェアマシンシステムを、ここでもインフィニバンドを用いて連結することにより、より大きな環境を作ることができる。各ミドルウェアマシンソフトウェア環境に、数個のアプリケーションサーバインスタンスまたはその他のソフトウエアインスタンスを設けることができる。たとえば、図１に示されるように、第１のアプリケーションサーバインスタンス１０９が、仮想マシン１１６と、オペレーティングシステム１２０と、仮想化層１２４と、アプリケーションサーバ層１２８（たとえば、サーブレット（Servlet）１３２、ＥＪＢ１３４、およびグリッドリンク（GlidLink）１３６それぞれのコンテナを含むウェブロジック）とを含み得るのに対し、第２またはその他のアプリケーションサーバインスタンス１１０は、仮想マシン１１６と、オペレーティングシステム１２０と、仮想化層１２４と、データグリッド層１４０（たとえばアクティブキャッシュ１４２を含むコヒーレンス（Coherence））とを含み得る。ある実施の形態に従うと、アプリケーションサーバインスタンスは各々、本明細書においてエクサロジック統合（integration）パックと呼ぶ、ミドルウェアマシン統合構成要素１５０を用いて、互いに通信でき、かつ、そのミドルウェアマシンハードウェアノードおよびその他のノード双方とも通信できる。ミドルウェアマシン統合構成要素１５０自体が、インフィニバンドおよびその他の特徴に対するサポートといったいくつかの最適化特徴を提供し、その各々については以下でさらに詳細に説明する。

【0011】

図２は、ある実施の形態に従うミドルウェアマシンプラットフォームまたは環境の別の例を示す。図２に示されるように、各アプリケーションサーバインスタンスは、ミドルウェアマシン環境内において送信側および／または受信側１６０、１６１いずれかとして機能し得る。ある実施の形態に従うと、各アプリケーションサーバインスタンスは、インフィニバンドネットワーク１６４を介してアプリケーションサーバインスタンスが他のアプリケーションサーバインスタンスと通信できるようにするマルチプレクサ１６２、１６３に関連付けられている。図２に示される例では、特定の実装形態に応じて、アプリケーションサーバインスタンスは、ソケットダイレクトプロトコル（sockets direct protocol）１６８を含み得るカーネルスペース（kernel space）１６２と、ユーザスペース１６４と、アプリケーションサーバ（たとえばウェブロジック）１６６と、ＪＶＭ（たとえばジェイロキット／ホットスポット層）１７０と、ＷＬＳコア１７２構成要素と、サーブレットコンテナ１７４構成要素と、ＪＳＰコンパイラ１７６構成要素とを含み得る。他の実装形態に従うと、ミドルウェアタイプのソフトウェアおよび構成要素の他の組合せが含まれていてもよい。さまざまな実施の形態に従い、マシン統合構成要素は、ゼロバッファコピー、分散／収集Ｉ／Ｏ、Ｔ３接続、および遅延デシリアライゼーション等の特徴を１つ以上提供することにより、共有されるインフラストラクチャの基礎を提供するとともにこのインフラストラクチャ内での性能を改善することもできる。上記特徴各々については以下でより詳細に説明する。

【0012】

当業者には容易にわかるように、本発明の機能ブロックを、ハードウェアによって、ソフトウェアによって、またはハードウェアとソフトウェアの組合せによって実現することにより、本発明の原理を実施してもよい。図面に記載された機能ブロックを組合わせるまたはサブブロックに分割することにより、上記本発明の原理を実現してもよいことが、当業者に理解される。したがって、本明細書における説明は、本明細書に記載の機能ブロックの任意の可能な組合せまたは分割またはさらに他の定義をサポートし得る。

【0013】

図３は、ある実施の形態に従う、４分の１ラック構成として提供されるミドルウェアマシンの例を示す。図３に示されるように、４分の１ラック構成２０２として提供される場合、ミドルウェアマシンは、Ｘ４１７０ Ｍ２サーバノード等の、複数の高性能サーバと、ＮＭ２−ＧＷノード等の、１つ以上のインフィニバンドスイッチ／ゲートウェイ（Switch/Gateway）と、Ｍａｇｕｒｏ ＲＷ−２ノード等の、１つ以上のストレージ構成要素と、Ｃｉｓｃｏ４９４８スイッチ等の、１つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。

【0014】

図４は、ある実施の形態に従う、２分の１ラック構成として提供されるミドルウェアマシンの例を示す。図４に示されるように、２分の１ラック構成２１６として提供される場合、ミドルウェアマシンは、同じく、Ｘ４１７０ Ｍ２サーバノード等の、多数の高性能サーバと、ＮＭ２−ＧＷノード等の、１つ以上のインフィニバンドスイッチ／ゲートウェイと、Ｍａｇｕｒｏ ＲＷ−２ノード等の、１つ以上のストレージ構成要素と、Ｃｉｓｃｏ４９４８スイッチ等の、１つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。ハードウェア構成要素は、その数がより多いものの、それ以外の点は４分の１ラック構成のハードウェア構成要素と同一である。

【0015】

図５は、ある実施の形態に従う、満杯のラック構成として提供されるミドルウェアマシンの例を示す。図５に示されるように、満杯のラック構成２２２として提供される場合、ミドルウェアマシンは、より数が多い、Ｘ４１７０ Ｍ２サーバノード等の、高性能サーバと、ＮＭ２−ＧＷノード等の、１つ以上のインフィニバンドスイッチ／ゲートウェイと、Ｍａｇｕｒｏ ＲＷ−２ノード等の、１つ以上のストレージ構成要素と、Ｃｉｓｃｏ４９４８スイッチ等の、１つ以上の管理スイッチとを含み得る。ここでも、ハードウェア構成要素は、その数がより多いものの、それ以外の点は４分の１ラック構成および２分の１ラック構成のハードウェア構成要素と同一である。

【0016】

図６は、ある実施の形態に従う、他のシステムおよびネットワークとのインターフェイスのために使用できるミドルウェアマシンプラットフォームまたは環境の例を示す。図６に示されるように、ミドルウェアマシン２３０の構成が４分の１ラックであるか２分の１ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェア２３２は、Ｘ４１７０ Ｍ２サーバノード等の、複数の高性能サーバと、ＮＭ２−ＧＷノード等の、１つ以上のインフィニバンドスイッチ／ゲートウェイと、Ｍａｇｕｒｏ ＲＷ−２ノード等の、１つ以上のストレージ構成要素と、Ｃｉｓｃｏ４９４８スイッチ等の、１つ以上の管理スイッチとを含み得る。これらは、インフィニバンドを用いて連結され、管理ネットワーク２３４を用いて管理できる。ある実施の形態に従うと、ＮＭ２−ＧＷノード等のインフィニバンドスイッチ／ゲートウェイを用いて、１つ以上のデータセンターサービスネットワーク２３６への１０Ｇｂイーサネット接続を与えることができる。１つ以上の管理スイッチたとえばＣｉｓｃｏ４９４８スイッチを用いて、１つ以上のデータセンター管理ネットワーク２３６への１Ｇｂイーサネット接続を与えることができる。インフィニバンドネットワークを用いて、ミドルウェアマシンを他のミドルウェアマシンにまたはエクサデータ（Exadata）マシン２４０等の他のマシン環境に接続することもできる。

【0017】

ある実施の形態に従うと、ミドルウェアマシン２３０の構成が４分の１ラックであるか２分の１ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェアおよび／またはソフトウェア環境は、ミドルウェアマシンの性能を改善する、たとえばゼロバッファコピー、分散／収集Ｉ／Ｏ、Ｔ３接続、および遅延デシリアライゼーションといったさらに他の特徴を含み得る。

【0018】

ゼロバッファコピー
ある実施の形態に従うと、このシステムは、ウェブロジックサーバ（ＷＬＳ）、ジェイロキットまたはホットスポットＪＶＭ、オラクルリナックスまたはソラリス、およびオペレーティングシステム（ＯＳ）等の構成要素におけるバッファコピーを回避するゼロバッファコピーを使用することができる。従来、システムの各層（たとえばサーバ層、ＪＶＭ層、ＯＳ層など）は、他の層、アプリケーション、およびプロセスがアクセスできない専用メモリスペースを保有する。これは、外部システムが重要なメモリスペースおよびデータを破壊してシステムクラッシュの原因となることがないようにすることによって、システムの全体的な安定性を守るためである。したがって、要求と応答の処理の間、要求および応答に関連するデータは、層と層の間で、専用メモリスペースから専用メモリスペースに、コピーされる。すなわち、所与の層は、データを処理した後、このデータを次の層に押出し、この、次の層は、データをその専用メモリスペースにコピーし、これに対して処理を行ない、次の層に押出す。他の層と層の間でも同じことが行なわれる。しかしながら、本発明の実施の形態は、さまざまな層を密に統合することにより、システムの安定性にとっての危険を高めることなく、これらの層が安全にメモリスペースを共有できるようにする。したがって、このことは、ユーザおよびカーネルスペースにおけるＣＰＵの利用を減らし、故にレイテンシを短縮する。

【0019】

図７は、ある実施の形態に従う、ゼロバッファコピーを提供するためのシステム３００を示す。図７に示されるように、アプリケーションサーバ３０２、ユーザスペース３０４、およびカーネルスペース３０６各々に、多数の異なる特徴を与えることができる。サーバレベルでは、バイトバッファを、静的バイト配列および一時バッファの代わりに使用することができる。たとえば、ＪＳＰコンパイラは、静的バイト配列の代わりにバイトバッファを使用することができる３０８。バイトバッファは、補助バイト配列をラップすることによって作成できる。バイトバッファおよび補助バイト配列のうちいずれか一方に対して行なわれた変更は他方に反映される。したがって、処理を行なう各層に対して新たなバイト配列を作成してからこのバイト配列をコピーして次の層のための新たなバイト配列にするのではなく、１つのバイト配列を保存しバイトバッファをこのバイト配列にラップすればよい。各層はバイト配列に対して処理を行なうので、変更はバイト配列に対して適用される。これは、必要なコピーの量を制限し、性能を改善する。同様に、サーブレットコンテナは、一時バッファにコピーする代わりにバイトバッファを使用することができ３１０、サーバコアは、カーネルレベルチャンクストリームの代わりにバイトバッファ認識ストリーム（byte buffer-aware streams）を使用することができ３１２、ＪＶＭが、コピーの代わりに固有のメモリをＷＬＳバッファにピニング（pinning)できるようにする３１４。メモリをピニングすることにより、ＪＶＭは、確実に、メモリがごみ集め（garbage collection）の対象となったり他のプロセスによって使用されたりしないようにする。このように、データ処理における各段階で、メモリ内のデータへのポインタまたはリファレンスを、各段階でデータをコピーする代わりに、使用することができる。これらの改良により、サーバ層３１６におけるゼロコピーを実現し、ＣＰＵサイクルを少なくし性能を改善する。

【0020】

ある実施の形態に従うと、プラットフォームは、ユーザスペースで実行するＪＶＭからカーネルスペースのネットワークスタックへのバイトバッファデータのコピーを回避するソケットダイレクトプロトコル（ＳＤＰ）の使用もサポートする３１８。これにより、ＨＴＴＰ要求に応じながら、バッファコピーの数をさらに減じる。コピーを回避することにより、ＣＰＵサイクルがユーザおよびカーネルスペース双方において少なくなり、したがってＨＴＴＰトラフィックのレイテンシが短くなる。

【0021】

代表的な実施の形態では、アプリケーションサーバ（たとえばウェブロジックサーバ）を変形することにより、ＨＴＴＰ要求に応えながらゼロバッファコピーを実現することができる。ウェブロジックサーバＪＳＰコンパイラは、静的ＪＳＰコンテンツを直接Ｊａｖa Ｎｅｗ Ｉ／Ｏ（ＮＩＯ）バイトバッファに書込むことができる。実行時に、ウェブコンテナは、これらバイトバッファを直接、コピーせずに、バイトバッファ認識ウェブロジックサーバＩＯストリームに送ることができる。これらバイトバッファを次に、集合書出し（gathered write）を用いてＮＩＯマルチプレクサによって直接書き出すことができる。エクサロジック上で実行するＪＶＭ（たとえばジェイロキットまたはホットスポットＪＶＭ）は、これらバイトバッファをメモリにピニングし、データを固有のメモリにコピーすることを回避する。

【0022】

図８は、ある実施の形態に従う、ゼロバッファコピーの方法のフローチャートを示す。ステップ４００で、各々が１つ以上のプロセッサと高性能メモリとを含む１つ以上の高性能コンピューティングシステムが与えられる。ステップ４０２で、Ｊａｖａ仮想マシン（ＪＶＭ）と１つ以上のアプリケーションサーバインスタンスとを含むユーザスペースが与えられる。ステップ４０４で、ＪＶＭにアクセス可能な複数のバイトバッファおよび１つ以上のアプリケーションサーバインスタンスが与えられる。ステップ４０６で、第１のアプリケーションサーバインスタンスが要求を受ける。ステップ４０８で、この要求に関連付けられたデータが、ＪＶＭに関連付けられたヒープ（heap）スペースに格納される。ステップ４１０で、ＪＶＭは、データが格納されているヒープスペースの一部をピニングする。ステップ４１２で、データは、第１のアプリケーションサーバインスタンスがアクセスする第１のバイトバッファに押出される。ステップ４１４で、第１のアプリケーションサーバがデータを用いて応答を生成する。ステップ４１６で、第１のアプリケーションサーバがこの応答を送信する。

【0023】

ある実施の形態に従うと、図８に示される方法はさらに、ソケットダイレクトプロトコル（ＳＤＰ）に対するサポートを含むカーネルスペースを与えるステップと、カーネルスペースおよびユーザスペースにアクセス可能な、１つ以上の、バイトバッファ認識ストリームを与えるステップとを含み得る。加えて、図８に示される方法において、各バイトバッファはＪａｖａ Ｎｅｗ Ｉ／Ｏバイトバッファであってもよい。さらに、要求はＨＴＴＰ要求であってもよい。また、図８に示される方法において、第１のバイトバッファはヒープスペース内のどこにデータが格納されているかを示すリファレンスを含んでいてもよい。

【0024】

分散／収集Ｉ／Ｏ
ある実施の形態に従うと、システムは、ネットワークパケットの細分化を最小にする分散／収集Ｉ／Ｏを用いることにより、ＯＳがＪａｖａ Ｎｅｗ Ｉ／Ｏ（ＮＩＯ）の使用に基づいて細分化を行なうことができるようにする。加えて、ある実施の形態に従うと、システムは、最大転送単位（ＭＴＵ）が６４ＫＢであるインフィニバンド上のインターネットプロトコル（Internet Protocol over InfiniBand (IPoIB））プロトコルを使用する。比較として、イーサネットのＭＴＵは１．５ＫＢである。ＩＰｏＩＢを用いることにより、アプリケーションサーバ、たとえばウェブロジックサーバは、一度により多くのデータを書込むことができる。加えて、典型的なイーサネット接続は約１Ｇｂ／ｓという速度を提供するが、インフィニバンドネットワークを用いることにより、上り速度４０Ｇｂ／ｓを利用できる。これにより、フレキシビリティが増し、この接続を通してより多くのデータを送ることができる。理想的なのは、このような接続を利用するシステムが、ネットワークを通してより多くのデータを押出すことにより、利用できる帯域幅を飽和させ効率的に使用できるようにすることである。

【0025】

図９は、ある実施の形態に従う、イーサネットプロトコルを利用するシステムを示す。イーサネットネットワーク５００を利用するシステムでは、データは比較的小さい部分にしか書込むことができない。図９に示されるように、サーバ５０２はイーサネットネットワーク５００を介してサーバ５０４に接続される。これら２つのサーバはシングルマルチプレクサ５０６および５０８を用いてシングルチャネルを通して通信する。図９に示されるように、データ送信は、サーバに対して４ＫＢのチャンクで通信することを強いるイーサネット接続によって、制限される。一度にこれよりも多くのデータを送信しようとすると、ネットワークの容量を超えてしまう。このため、カーネルレベルでより多くの作業を実施しなければならなくなる。具体的には、カーネルレベルは、データをより小さな単位に分割し、オンザフライのフロー制御を強要する。これは、時間およびリソースの浪費となる可能性がある。

【0026】

図１０は、ある実施の形態に従う、ＩＰｏＩＢおよびパラレル多重化を利用するシステムを示す。上記のように、インフィニバンドネットワークは、典型的なイーサネット接続よりも大きい帯域幅を提供する。このより大きな帯域幅のおかげで、より大きなＭＴＵを使用できる。図１０に示されるように、サーバ５０６はインフィニバンドネットワーク５１０上でサーバ５０８に接続される。インフィニバンドを通して利用できるより大きな帯域幅を用いることにより、システムは、イーサネットと比較して遥かに大きい６４ＫＢのチャンクでデータを押出すことができる。このようなシステムでは、カーネルレベルは帯域幅が増したことを認識しより大きなデータ単位を、データをより小さな単位に分割してフロー制御を強要するという追加の作業を実施することなく、押出す。

【0027】

ある実施の形態に従うと、クラスタ内では、複数のパラレル論理接続すなわちチャネルを、サーバ間で使用できる。そのため、より多くのデータを同時にサーバ間で送ることができるので、複数のスレッドを並列に実行できる。図１０に示されるように、各サーバはパラレルマルチプレクサ５１２、５１４を利用する。パラレルマルチプレクサは、さまざまな接続を管理することにより、確実に、複数のスレッドが互いに干渉またはブロックしないようにする。このため、利用できる帯域幅の使用がさらに改善され、サーバ間のデータ転送効率が改善される。

【0028】

図１１は、ある実施の形態に従う、分散／収集Ｉ／Ｏを提供する方法のフローチャートを示す。ステップ６００で、１つ以上の高性能コンピューティングシステムのクラスタが与えられる。各高性能コンピューティングシステムは、１つ以上のプロセッサと高性能メモリとを含み得る。クラスタは、インフィニバンドネットワーク上で通信できる。ステップ６０２で、クラスタ上で実行し１つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境が与えられる。ステップ６０４で、複数のマルチプレクサが与えられる。各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含む。ステップ６０６で、第１のアプリケーションサーバインスタンス上の第１のマルチプレクサが、高性能メモリ内の複数の場所からデータを集める。ステップ６０８で、第１のマルチプレクサは、第２のアプリケーションサーバ上の第２のマルチプレクサにデータをまとめて転送する。

【0029】

ある実施の形態に従うと、図１１に示される方法はさらに、各マルチプレクサによって、複数のパラレルチャネルを通してデータを送信する複数のスレッドを管理することを含み得る。ユーザは、この複数のパラレルチャネルの中に含まれるパラレルチャネルの数を設定することができる。加えて、上記のように、各マルチプレクサはＮｅｗ Ｉ／Ｏマルチプレクサであってもよい。さらに、各データ転送に分散／収集データ処理を用いてもよい。

【0030】

Ｔ３接続（パラレル多重化）
特に、本明細書に記載のように、システムおよび方法は、クラスタ内のサーバ間でのパラレル多重化のために提供される。１つのこのようなシステムは、各々が１つ以上のプロセッサと高性能メモリとを含む、１つ以上の高性能コンピューティングシステムのクラスタを含み得る。クラスタはインフィニバンドネットワーク上で通信する。システムはまた、クラスタ上で実行し１つ以上のアプリケーションサーバインスタンスを含む、ミドルウェア環境を含む。このシステムは複数のマルチプレクサをさらに含み得る。各アプリケーションサーバインスタンスは少なくとも１つのマルチプレクサを含む。各マルチプレクサは、情報を複数のスレッドから受け、異なるアプリケーションサーバインスタンス上の異なるマルチプレクサに、インフィニバンドネットワーク上で複数のパラレルチャネルを用いて送ることができる。

【0031】

図１２は、ある実施の形態に従う、サーバ間のシングル接続を利用するシステムを示す。図１２に示されるように、典型的なクラスタ化シナリオでは、シングル接続７００がサーバ７０２とサーバ７０４の間に設けられる。たとえば、サーバ７０２からの通信はシングルマルチプレクサ７０６に送られ、この通信はシングル接続７００を通してサーバ７０４に送信される。サーバ７０４の対応するシングルマルチプレクサ７０８は、この通信をそれぞれの適切な宛先に送る。しかしながら、このシングル接続は、インフィニバンド（ＩＢ）ネットワーク内で利用できる帯域幅をすべて使用することができない。

【0032】

図１３は、ある実施の形態に従う、サーバ間のパラレル接続を利用するシステムを示す。図１３に示されるように、複数のパラレル接続７１０をサーバ７１２とサーバ７１４の間で維持できる。各サーバは、パラレルマルチプレクサ７１６、７１８を含み、サーバ間の複数の接続を通して通信を並列に送る。ある実施の形態に従うと、Ｔ３または同様のプロトコルを変形して複数の接続を設けることができ、そうすれば、接続毎のボトルネックは回避され、インメモリセッションレプリケーションといった特徴のためにネットワーク帯域幅をより有効に利用できる。これにより、利用できるＩＢ帯域幅をより有効に使用することができ、ピア（peer）間で、速度をほとんど低下させずにより効率的な通信を行なうことができる。

【0033】

上記のように、ある実施の形態に従うと、プラットフォームは、バックプレーンで、インフィニバンド上のインターネットプロトコル（ＩＰｏＩＢ）ネットワークをサポートし、ＩＢのネットワーク帯域幅は２５Ｇｂｐｓである。ウェブロジックサーバのＴ３のようなシングル接続はクラスタ通信に対しＩＢ帯域幅を十分に利用できないので、複数の接続が並列に作成されてネットワーク帯域幅をより有効に利用している。複数の接続は、セッションレプリケーションネットワークトラフィックの拡大に役立つ。

【0034】

ある実施の形態に従うと、サーバ、たとえばＴ３プロトコルを用いるウェブロジックサーバは、すべてのスレッドからのメッセージを、シングルスレッドによってネットワーク上に一度に送出される単一の送信キューに集めることができる。複数のプロセスが、同一のロックが行なわれることを要求した場合、ロックコンテンションが生じ得る。たとえば、ロックコンテンションは、メッセージを送信キューに追加しようと試みているスレッド間で生じ得る。複数の接続を並列に作成することにより、ロックコンテンションは複数の接続に分散するため、１つの接続当たりのロックコンテンションは少なくなる。また、複数の送信スレッドがメッセージを遠隔のサーバインスタンスに送ると、ワークフローの並列化が生じる。

【0035】

ある実施の形態に従うと、暗黙レプリケーションチャネルを、ClusterMBean上に構成されたレプリケーションチャネルをテンプレートとして用いて作成することができる。作成される暗黙チャネルの数は、ServerMBean.getReplicationPorts ()属性に基づく。暗黙チャネルは、ClusterMBean. ReplicationChannelsからの属性付きのものすべてをコピーする一方で、ポート情報をオーバライドすることにより固有にしておく。オーバライドポート情報は、ServerMBean.getReplicationPorts ()から得られる。加えて、システムは、複数のチャネルを構成するか否か判断するのに使用できるユーティリティ機能を含み得る。このユーティリティは、構成の変更に応じて、および／またはユーザの指示に従って、この判断を一度、自動的に等間隔で、行ない、その結果を、後のコールに備えてキャッシュすることができる。システムはさらに、構成された各レプリケーションチャネルに対し排他的ＲＭＩスタブを作成することができる（各接続に割当てられるスタブ）。システムは、セッションＩＤをハッシュすることにより、たとえばラウンドロビンまたはその他同様のバランシングアルゴリズムを用いて、すべてのスタブ間でレプリケーション要求をバランシングする。このシステムはまた、レプリケーションコールを、サーバのために構成されたレプリケーションチャネルのうち１つで確実に受けることができるようにする。

【0036】

ある実施の形態に従うと、インフィニバンドの使用によって従来のシステムよりも大きな帯域幅が得られるので、データを送信できるより大きなパイプが効果的に与えられる。このより大きなパイプをより有効に利用するために、複数のパラレル論理接続すなわちチャネルを、シングル論理接続の代わりに使用することができる。複数の接続は、互いにブロックし合うさまざまな実行スレッドなしで、同時性がより高いアクティビティの実行が可能であることを意味する。これは、たとえばクラスタリングに、すなわち、複数のサーバがクラスタ内で互いに通信する場合に、役立ち得る。クラスタ内では、サーバ間のセッションデータレプリケーションが重要な特徴である。セッションデータは、たとえば、ウェブサイトへの特定の訪問またはセッションに特有のショッピングカートまたはその他のユーザデータである。クラスタ内のサーバ間に複数の接続を用いることにより、各サーバへのインメモリセッションレプリケーションをより確実にかつより効率的に行なうことができる。これは、サーバの障害に備えてセッションデータを格納し、エンドユーザおよびサービスプロバイダの経験を改善する。

【0037】

図１４は、ある実施の形態に従う、クラスタ内のサーバ間におけるパラレル多重化を提供するための方法のフローチャートを示す。ステップ８００で、１つ以上の高性能コンピューティングシステムのクラスタが与えられる。高性能コンピューティングシステムは各々、１つ以上のプロセッサと高性能メモリとを含み得る。加えて、クラスタはインフィニバンドネットワーク上で通信できる。ステップ８０２で、クラスタ上で実行するミドルウェア環境が与えられる。ミドルウェア環境は、１つ以上のアプリケーションサーバインスタンスを含み得る。ステップ８０４で、複数のマルチプレクサが与えられる。各アプリケーションサーバインスタンスは、少なくとも１つのマルチプレクサを含み得る。ステップ８０６で、第１のアプリケーションサーバインスタンスの第１のマルチプレクサが、情報を複数のスレッドから受信し、第２のアプリケーションサーバインスタンスの第２のマルチプレクサに送信する。ステップ８０８で、この情報は、インフィニバンドネットワーク上で、複数のパラレルチャネルを用いて、第２のマルチプレクサに送信される。

【0038】

ある実施の形態に従うと、図１４に示される方法はまた、ユーザからの入力に基づいて、複数のパラレルチャネルに含まれるパラレルチャネルの数を設定することを含み得る。加えて、送信される情報は、セッションデータを含み得る。さらに、各マルチプレクサはＮｅｗ Ｉ／Ｏ（ＮＩＯ)マルチプレクサであってもよい。図１４に示される方法は、さらに、複数のパラレルチャネル各々についてＲＭＩスタブを作成することを含み得る。

【0039】

サーバクラスタ内でのインメモリセッションレプリケーション
ある実施の形態に従うと、システムは、遅延デシリアライゼーションという方法を用いて、サーバクラスタ内でのインメモリセッションレプリケーションをサポートすることができる。ミドルウェアマシンプラットフォームまたは環境は、アプリケーションサーバの１つ以上のクラスタを含み得る。システムは、ミドルウェアマシンプラットフォームが高い可用性を提供できるように、使用中の障害から回復することができる。ある実施の形態に従うと、セッション状態をミドルウェアマシンプラットフォームにおいて用いて、重要なユーザセッション情報を記憶する。システムは、インメモリレプリケーション（in-memory replication）およびＪＤＢＣベースの永続性（JDBC-based persistence）といった異なる方法を用いて、クラスタ間で、ユーザサービス要求に関連するセッション状態をレプリケートすることができる。システムは、インメモリレプリケーションを使用して、セッション状態を、あるサーバインスタンスから別のサーバインスタンスにコピーする。プライマリアプリケーションサーバは、クライアントが最初に接続するサーバ上にプライマリセッション状態を作成し、クラスタ内の別のサーバインスタンス上にセカンダリレプリカを作成する。レプリカは、プライマリアプリケーションサーバたとえばサーブレットをホストするサーバに障害が生じた場合に使用されることができるよう、最新状態に保たれる。ＪＤＢＣベースの永続性の場合、システムは、セッション状態たとえばサーブレットまたはＪＳＰのセッション状態を、ファイルベースまたはＪＤＢＣベースの永続性を用いて保持する。ＪＤＢＣベースの永続性は、ワイドエリアネットワーク（ＷＡＮ）内でのセッション状態レプリケーションにも使用される。

【0040】

ある実施の形態に従うと、システムは、シリアライズステップを行なうことにより、プライマリセッションデータをデータ送信のために変換することができる。シリアライズステップは、データのパラレルな配置といった複雑なデータ構造をシリアル形式に変換するプロセスである。データのパラレルな配置では、一度に多数のビットをパラレルチャネルに沿って送信する。一方、シリアル形式は一度に１ビットずつ送信する。シリアライズセッションデータは、セッション状態のレプリケーションのために何らかのオーバヘッドを導入する。オーバヘッドはシリアライズされるオブジェクトのサイズが大きいほど大きくなる。たとえば、ユーザがＨＴＴＰセッションの中で非常にサイズが大きなオブジェクトを作成しようと計画している場合、サーブレットの性能をテストして性能が許容範囲にあることを保証する必要がある。

【0041】

ある実施の形態に従うと、セッションのインメモリレプリケーションをサポートするためには、セッション状態がシリアライズ可能である必要がある。オブジェクトがシリアライズ可能であるとみなされるためには、オブジェクト内のすべてのフィールドが、シリアライズ可能または一時的である必要がある。たとえば、ＨＴＴＰセッション状態内のすべてのサーブレットおよびＪＳＰセッションデータがシリアライズ可能でなければならない。サーブレットまたはＪＳＰが、シリアライズ可能なオブジェクトとシリアライズ不能なオブジェクトの組合せを使用する場合、システムはシリアライズ不能なオブジェクトのセッション状態をレプリケートしないことがある。

【0042】

ある実施の形態に従うと、セッション状態は、システムが提供する機能を用いて変更できる。たとえば、特殊機能であるHttpSession.setAttribute ()を用いて、javax.servlet.http.HttpSessionを実装するＨＴＴＰサーブレット内のセッションオブジェクトにおける属性を変更することができる。ユーザがsetAttributeを用いてセッションオブジェクトにおける属性を設定する場合、オブジェクトおよびその属性は、インメモリレプリケーションを用いてクラスタ内でレプリケートされる。ユーザが他の設定方法を用いてセッション内でオブジェクトを変更する場合、システムはこういった変更をレプリケートしないことがある。セッション内のオブジェクトに変更がなされる度に、setAttribute()を呼び出してそのオブジェクトをクラスタ間で更新することができる。同様に、removeAttribute()を用いて属性をセッションオブジェクトから削除することができる。

【0043】

図１５は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図１５に示されるように、クライアント９０１は、プライマリアプリケーションサーバ９０２とセカンダリアプリケーションサーバ９０３とを含むサーバクラスタ９００と対話できる。プライマリアプリケーションサーバは、ステップ９２１で、クライアントからセッション９１１に関連付けられた要求を受け、このセッションに関連付けられたセッション情報９１２を保持する。プライマリアプリケーションサーバは、セッション情報に基づいてクライアントに対して応答することもできる。さらに、セカンダリアプリケーションサーバは、ステップ９２２で、プライマリアプリケーションサーバからシリアライズされたセッション情報９１３を受けて保持するように機能する。

【0044】

ある実施の形態に従うと、クライアントとプライマリアプリケーションサーバとの対話中、プライマリアプリケーションサーバで保持されているセッション情報をステップ９２４で変更することができる。実行時に、プライマリアプリケーションサーバはこれらセッション更新９０４をステップ９２５でセカンダリアプリケーションサーバに送信することができる。また、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けたセッション更新に基づいて、格納されているシリアライズされたセッション情報を更新するように機能する。

【0045】

ある実施の形態に従うと、シリアライズされたセッションデータを、バイナリフォーマットで、たとえば、バイト配列として、セカンダリアプリケーションサーバに格納することができる。システムは、異なるロジックを適用して、シリアライズされたバイナリセッションデータを効率的に更新することができる。ある実施の形態では、システムが、特定のセッション更新の影響を受ける、セカンダリアプリケーションサーバ内のバイト配列におけるエントリを検出する。次にシステムは、バイト配列内のシリアライズされたセッションデータ全体を置換しなくても、直接、バイト配列内の影響を受けたエントリを更新することができる。これは特に、格納されたシリアライズされたセッションデータのサイズが大きいときに有用である。

【0046】

ある実施の形態に従うと、プライマリアプリケーションサーバに障害が生じると、セカンダリアプリケーションサーバが、ステップ９２３で、更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報９１４を生成するように機能する。セカンダリアプリケーションサーバまたはミドルウェア環境内の別のアプリケーションサーバは、デシリアライズされたセッション情報を用いステップ９２６でクライアントに応答することができる。

【0047】

ある実施の形態に従うと、システムは、プライマリアプリケーションサーバに障害が生じた場合に限り、デシリアライズステップを実行することによって、インメモリセッションレプリケーションプロセスを最適化することができる。この最適化によって、プライマリアプリケーションサーバが動作している場合には、デシリアライズ動作を防止する。このような最適化により、システムは、すべてのセッション更新について、特にセッション更新が頻繁である場合にＣＰＵ利用コストおよびレイテンシオーバヘッドの点で費用がかかる、シリアライズステップをプライマリアプリケーションサーバで行ないデシリアライズステップをセカンダリアプリケーションサーバで行なうことを、回避できる。

【0048】

ある実施の形態に従うと、ユーザはさらに、レプリケーショングループを用いて、セカンダリ状態が位置する場所を制御することができる。レプリケーショングループは、セッション状態のレプリカを格納するのに使用されるクラスタ化されたサーバの優先順リストである。ユーザは、サーバを、レプリケーショングループと、サーバ上に作成されたプライマリＨＴＴＰセッション状態のシリアライズされたレプリカをホストするための好ましいセカンダリレプリケーショングル―プとに、割当てることができる。クライアントがクラスタ内のサーバに接続されプライマリセッション状態を作成すると、プライマリ状態をホストしているサーバは、クラスタ内の他のサーバを順位付けして、どのサーバがセカンダリをホストすべきか決定する。サーバの順位は、サーバの場所（プライマリアプリケーションサーバと同じマシン上にあるか否か）と、プライマリアプリケーションサーバの優先レプリケーショングループのメンバーであるか否かの組合せを用いて、割当てられる。

【0049】

図１６は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするための代表的なフローチャートを示す。図１６に示されるように、プライマリアプリケーションサーバは、ステップ１００１で、セッションに関連付けられた要求をクライアントから受ける。プライマリアプリケーションサーバはまた、セッションに関連付けられたセッション情報を保持し、セッション情報に基づいてクライアントに応答する。次に、ステップ１００２で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバからシリアライズされたセッション情報を受けて保持することができる。ステップ１００３で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けた１つ以上のセッション更新に基づいて、シリアライズされたセッション情報をさらに更新できる。最後に、ステップ１００４で、プライマリアプリケーションサーバに障害が生じた場合に限り、更新されたシリアライズされたセッション情報をデシリアライズすることができ、アプリケーションサーバはこのデシリアライズされたセッション情報に基づいてクライアントに応答できる。

【0050】

ＨＴＴＰセッションレプリケーション
クラスタ内でのサーブレットおよびＪＳＰの自動レプリケーションおよびフェイルオーバをサポートするために、システムは、ＨＴＴＰセッション状態を保持する２つのメカニズム、すなわちハードウェアロードバランサとプロキシプラグインをサポートすることができる。

【0051】

ある実施の形態に従うと、プライマリアプリケーションサーバに障害が発生したとき、ロードバランシングハードウェアは、クライアントからの要求を、アプリケーションサーバクラスタ内で使用可能な任意のサーバに、単純にリダイレクトすればよい。このクラスタは、クライアントのＨＴＴＰセッション状態のレプリカを、クラスタ内のセカンダリアプリケーションサーバから、取得できる。

【0052】

図１７は、ある実施の形態に従う、ロードバランサを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図１７に示されるように、ステップ１１２１で、ウェブアプリケーションのクライアント１１０１が、パブリックＩＰアドレスを用いてサーブレットを要求すると、ロードバランサ１１１０は、その構成済みのポリシーに従って、クライアントの接続要求を、アプリケーションサーバクラスタ１１００に転送する。ステップ１１２２で、システムは、この要求を、クライアントのサーブレットセッション状態のプライマリホストとして機能するアプリケーションサーバＡ１１０２に転送する。ステップ１１２３で、システムは、順位付けシステムを用いて、セカンダリアプリケーションサーバＢ１１０３を、セッションに関連するシリアライズされたセッション状態をホストするサーバとして選択する。

【0053】

ステップ１１２４で、クライアントは、アプリケーションサーバインスタンスＡおよびＢ双方の場所をローカルクッキー１１１１に記録することができる。クライアントがクッキーを許可しなければ、プライマリおよびセカンダリアプリケーションサーバの記録は、ＵＲＬ書換を介してクライアントに戻されるＵＲＬに記録できる。

【0054】

クライアントがクラスタに対してさらに要求を行なう場合、ロードバランサは、クライアント側のクッキーにある識別子を用いて、確実に、この要求が、クラスタ内の別のサーバにロードバランスされるのではなく、引続きアプリケーションサーバＡに送られるようにする。これにより、クライアントは確実に、セッションが終了するまで、プライマリセッションのオブジェクトをホストしているサーバとの関係を維持する。

【0055】

接続に障害が発生すると、ステップ１１２５で、ロードバランシングハードウェアは、その構成済みのポリシーを用いて、要求を、クラスタ内で使用可能なサーバに送る。上記の例では、サーバＡに障害が発生すると、その後、ロードバランサがクライアントの要求をアプリケーションサーバＣ１１０４に送ると想定している。クライアントがサーバＣに接続すると、サーバはクライアントのクッキー内の情報を、または、ＵＲＬ書換が使用される場合はＨＴＴＰ要求内の情報を用いて、サーバＢに接続する。アプリケーションサーバＣはさらに、ステップ１１２６で、サーバＢ上のシリアライズされたセッション状態をデシリアライズすることによってセッション状態をさらに取得することができる。このフェイルオーバプロセスは、クライアントに意識させることはない。デシリアライズステップは、接続障害後一度実行するだけでよい。サーバＣはクライアントのプライマリセッション状態の新ホストとなり、サーバＢは引続きシリアライズされたセッション状態のホストでありステップ１１２７でサーバＣからセッション更新を受ける。この、プライマリおよびセカンダリホストに関する新情報は、クライアントのクッキー内でまたはＵＲＬ書換で再び更新される。

【0056】

ある実施の形態に従うと、アプリケーションサーバプロキシプラグインは、クラスタ化されたサーブレットまたはＪＳＰのホストであるアプリケーションサーバインスタンスのリストを保持し、ラウンドロビン方式を用いてＨＴＴＰ要求をそれらのインスタンスに転送する。このプラグインは、アプリケーションサーバインスタンスに障害が生じた場合に、クライアントのＨＴＴＰセッション状態のシリアライズされたレプリカの位置を求めるのに必要なロジックも提供する。

【0057】

図１８は、ある実施の形態に従う、プロキシプラグインを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図１８に示されるように、ステップ１２２１でＨＴＴＰクライアント１２０１がサーブレットを要求すると、ＨＴＴＰサーバ１２１０上のHttpClusterServlet１２１２がプロキシとして機能し、この要求をアプリケーションサーバクラスタ１２００に転送する。HttpClusterServletは、クラスタ内のすべてのサーバのリストと、クラスタにアクセスするときに使用するロードバランシングロジックとを保持する。上記の例では、HttpClusterServletは、ステップ１２２２でクライアントのサーブレットセッションをホストするプライマリアプリケーションサーバになるアプリケーションサーバＡ１２０２上でホストされているサーブレットに、クライアント要求を送ることができる。

【0058】

サーブレットのフェイルオーバサービスを提供するために、プライマリアプリケーションサーバは、ステップ１２２２で、シリアライズされたクライアントのサーブレットセッション状態を、クラスタ内のセカンダリアプリケーションサーバに送る。上記の例では、アプリケーションサーバＢ１２０３が、セカンダリアプリケーションサーバとして選択される。

【0059】

サーブレットページは、HttpClusterServletを通してクライアントに返すことができ、クライアントブラウザは、ステップ１２２４で、サーブレットセッション状態のプライマリおよびセカンダリの場所のリストを有するクッキー１２１１に書込むよう指示される。クライアントブラウザがクッキーをサポートしないのであれば、アプリケーションサーバはその代わりにＵＲＬ書換を用いることができる。

【0060】

プライマリアプリケーションサーバＡに障害が発生すると、HttpClusterServletは、クライアントのクッキー情報を用いて、セッション状態のレプリカをホストするセカンダリアプリケーションサーバの場所を特定することができる。HttpClusterServletは、ステップ１２２５で、クライアントの次のＨＴＴＰ要求をセカンダリアプリケーションサーバに自動的にリダイレクトすることができる。このフェイルオーバはクライアントに意識させることはない。ステップ１２２６で、サーバＢはシリアライズされたセッション状態をデシリアライズすることができ、セッション状態を取得する。

【0061】

この障害後、サーバＢがサーブレットセッション状態をホストするプライマリアプリケーションサーバになり、新たなセカンダリを、たとえばアプリケーションサーバＣ６０４上に作成することができる。ステップ１２２７で、サーバＣは、シリアライズされたセッション状態をホストし、サーバＢからセッション更新を受けることができる。ＨＴＴＰ応答では、プロキシはクライアントのクッキーを更新して新たなプライマリおよびセカンダリアプリケーションサーバを反映させ、今後のフェイルオーバの可能性に備える。

【0062】

クラスタ間でのセッションレプリケーション
ある実施の形態に従うと、アプリケーションサーバは、クラスタ内のサーバ間でのＨＴＴＰセッション状態レプリケーションに加えて、複数のクラスタ間でＨＴＴＰセッション状態をレプリケートする機能を提供する。これにより、クラスタを複数の地理的領域、送電網、およびインターネットサービスプロバイダに分散させることによって、高い可用性および耐障害性が改善される。

【0063】

図１９は、ある実施の形態に従う、サーバクラスタ間でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図１９に示されるように、クラスタ間でのレプリケーションをサポートするネットワーク構成において、グローバルロードバランサ１３０２は、クラスタ１３０５とクラスタ１３０６との間でＨＴＴＰ要求をバランシングする役割を果たす。ステップ１３１１で、クライアント１３０１からの要求を受けると、グローバルロードバランサは、各クラスタが現在扱っている要求の数に基づいて、要求をいずれのクラスタに送るかを決定する。次に、要求は、ステップ１３１２または１３１３で、選択されたクラスタのローカルロードバランサ１３０３または１３０４に送られる。ローカルロードバランサは、グローバルロードバランサからＨＴＴＰ要求を受けると、ステップ１３１４または１３１５で、クラスタ内のサーバ間でＨＴＴＰ要求をバランシングする役割を果たす。

【0064】

セッションデータを１つのクラスタから別のクラスタにレプリケートするために、レプリケーションチャネル１３１０を、プライマリクラスタからセカンダリクラスタにセッション状態情報を伝えるように構成することができる。レプリケーションチャネルは、クラスタ間のレプリケーショントラフィック専用のネットワークチャネルであってもよい。クラスタ内のサーバに障害が発生すると、ローカルロードバランサは、要求をクラスタ内の他のサーバに転送する役割を果たす。クラスタ全体に障害が生じた場合、ローカルロードバランサはＨＴＴＰ要求をグローバルロードバランサに返す。グローバルロードバランサは次にこの要求を他のローカルロードバランサにリダイレクトする。

【0065】

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

【0066】

実施の形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された記憶媒体または（１つまたは複数の）コンピュータ可読記憶媒体であるコンピュータプログラムプロダクトを含む。この記憶媒体は、フロッピーディスク（登録商標）、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／またはデータを記憶するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。

【0067】

本発明に関するこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって当業者が本発明のさまざまな実施の形態および意図している実際の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は、以下の特許請求の範囲およびその均等物によって定められることが意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】