JP2009123201A - データを処理するためのサーバ‐プロセッサ・ハイブリッド・システムおよび方法 - Google Patents

Abstract

【課題】ウェブ３．０の特性を効率的に取り扱うシステム及び方法を提供する。
【解決手段】本発明は、（特に）１組の（１つ以上の）フロントエンド・サーバ（例えば、メインフレーム）と、１組のバックエンド・アプリケーション最適化プロセッサとを備えるサーバ‐プロセッサ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをコプロセッサとして使用することができる。
【選択図】図１

Description

本発明は、一般的には、データ処理に関する。特定的には、本発明は、より効率的なデータ処理のためのサーバ‐プロセッサ・ハイブリッド・システムに関する。

本願は、いくつかの局面において、同じ権利者が所有する２００７年１１月１５日出願の同時係属特許出願番号（追って補充）、名称「データを処理するためのプロセッサ‐サーバ・ハイブリッド・システム（ＰＲＯＣＥＳＳＯＲ‐ＳＥＲＶＥＲ ＨＹＢＲＩＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＤＡＴＡ）」、代理人整理番号ＥＮＤ９２００７０３７６ＵＳ１に関するものであり、その全体の内容を本願において参照するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年１０月２４日出願の同時係属特許出願第１１／８７７９２６号、名称「高帯域幅画像処理システム（ＨＩＧＨ ＢＡＮＤＷＩＤＴＨ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０３９８ＵＳ１に関するものであり、その全体の内容を本願において参照するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年６月２５日出願の同時係属特許出願第１１／７６７７２８号、名称「ハイブリッド画像処理システム（ＨＹＢＲＩＤ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１０ＵＳ２に関するものであり、その全体の内容を本願において参照するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年４月２３日出願の同時係属特許出願第１１／７３８７２３号、名称「異機種画像処理システム（ＨＥＴＥＲＯＧＥＮＥＯＵＳ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１０ＵＳ１に関するものであり、その全体の内容を本願において参照するものとする。また、本願は、いくつかの局面において、同じ権利者が所有する２００７年４月２３日出願の同時係属特許出願第１１／７３８７１１号、名称「異機種画像処理システム（ＨＥＴＥＲＯＧＥＮＥＯＵＳ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１１ＵＳ１に関するものであり、その全体の内容を本願において参照するものとする。

ウェブ１．０は、歴史的にはワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）と称され、元々は、コンピュータを接続して、コンピュータにとって技術をより効率的なものとすることに関するものであった。ウェブ２．０／３．０は、コンテキスト的な関係を構築するコミュニティおよびソーシャル・ネットワークを網羅するものとされ、知識の共有および仮想ウェブ・サービスを促進するものである。従来のウェブ・サービスは、非常に薄っぺらなクライアントであると考えることもできる。すなわち、ブラウザがサーバによって中継された画像を表示し、重要な各ユーザ・アクションがフロントエンド・サーバへ通信されて処理に供される。ウェブ２．０は、クライアントにおけるソフトウェア層からなる社会的な対話であるので、ユーザは迅速なシステム応答を得る。データのバックエンド記憶および取り出しが背景において非同期で行われるので、ユーザはネットワークを待つ必要がない。ウェブ３．０は、仮想世界におけるなどの３次元バージョンを目指している。これは、共有する３次元を使用して接続および共同するための新たなやり方を切り開くことができよう。このような方針に沿って、ウェブ３．０は、いくつかの別個のパスに沿ったウェブの使用法および対話の進化を表す。これには、ウェブのデータベースへの変換や、コンテンツをブラウザ以外の複数のアプリケーションによってアクセス可能にする動きが含まれる。

残念なことに、従来のサーバは、ウェブ３．０の特性を効率的に取り扱うことができない。この問題に対する既存の取り組みはない。以上に鑑み、この不備を解決する取り組みが必要である。

本発明は、（特に）１組の（１つ以上の）フロントエンド・サーバ（例えば、メインフレーム）と、１組のバックエンド・アプリケーション最適化プロセッサとを備えるサーバ‐プロセッサ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをサーバ機能に関するコプロセッサまたはアクセラレータとして機能させることができる。

本発明によって、フロントエンド・サーバ管理および制御システム構成要素を再使用することができ、仮想ウェブまたはゲーム処理構成要素などのアプリケーションをアクセラレータまたはコプロセッサとして使用することができる。システム構成要素は、異なるオペレーティング・システムを使用して実行可能である。（複数の）フロントエンド・サーバは、通常のトランザクション・ベースの計算リソースとして機能するが、そのために、このようなトランザクションは、計算が極端に多い大規模なグラフィックス、レンダリング、または他の機能をトリガするものであってもよい。プロセッサは、そのような機能を取り扱うためにバックエンドに配置される。従来のトランザクション処理に加えて、（複数の）フロントエンド・サーバは、特定プロセッサ選択機能、ならびにセルのコプロセッサのセットアップ、制御、および管理機能をも行うことになろう。

本発明の第１の局面は、データを処理するためのサーバ‐プロセッサ・ハイブリッド・システムを提供するものであって、外部ソースからデータを受信するための１組のフロントエンド・サーバと、フロントエンド・サーバからデータを受信し、データを処理し、処理済みデータをフロントエンド・サーバへ返すための１組のバックエンド・アプリケーション最適化プロセッサと、少なくとも１組のフロントエンド・サーバ内であって、１組のネットワーク・インターコネクトを有し、１組のフロントエンド・サーバを１組のバックエンド・アプリケーション最適化プロセッサに接続するインターフェースとを備える。

本発明の第２の局面は、データを処理するための方法を提供するものであって、フロントエンド・サーバ上で外部ソースからデータを受信するステップと、フロントエンド・サーバからバックエンド・アプリケーション最適化プロセッサへ、１組のネットワーク・インターコネクトを有しかつフロントエンド・サーバにおいて具体化されるインターフェースを介してデータを送信するステップと、データをバックエンド・アプリケーション最適化プロセッサ上で処理して、処理済みデータを生じさせるステップと、フロントエンド・サーバ上でバックエンド・アプリケーション最適化プロセッサから処理済みデータを受信するステップとを含む。

本発明の第３の局面は、データを処理するためのサーバ‐プロセッサ・ハイブリッド・システムを実施するための方法を提供するものであって、フロントエンド・サーバ上で外部ソースからデータを受信し、フロントエンド・サーバからバックエンド・アプリケーション最適化プロセッサへ、１組のネットワーク・インターコネクトを有しかつフロントエンド・サーバにおいて具体化されるインターフェースを介してデータを送信し、データをバックエンド・アプリケーション最適化プロセッサ上で処理して、処理済みデータを生じさせ、フロントエンド・サーバ上でバックエンド・アプリケーション最適化プロセッサから処理済みデータを受信するように動作可能なコンピュータ・インフラストラクチャを提供することを含む。

本発明のこれらおよび他の特徴は、添付の図面とともに本発明の様々な局面の以下の詳細な説明から容易に理解されるだろう。

図面は、必ずしも一律の縮尺に従っていない。図面は、概略的な表現に過ぎず、本発明の具体的なパラメータを表すものではない。図面は、単に本発明の典型的な実施の形態を示すものであるので、本発明の範囲を限定するものとみなされるべきではない。図面において、同様の番号付けは、同様の要素を示す。

上記のように、本発明は、（特に）１組の（１つ以上の）フロントエンド・サーバ（例えば、メインフレーム）と、１組のバックエンド・アプリケーション最適化プロセッサとを備えるサーバ‐プロセッサ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをサーバ機能に関するコプロセッサまたはアクセラレータとして機能させることができる。

本発明によって、フロントエンド・サーバ管理および制御システム構成要素を再使用することができ、仮想ウェブまたはゲーム処理構成要素などのアプリケーションをアクセラレータまたはコプロセッサとして使用することができる。システム構成要素は、異なるオペレーティング・システムを使用して実行可能である。（複数の）フロントエンド・サーバは、通常のトランザクション・ベースの計算リソースとして機能するが、そのために、これらのトランザクションは、計算が極端に多い大規模なグラフィックス、レンダリング、または他の機能をトリガするものであってもよい。プロセッサは、そのような機能を処理するためにバックエンドに配置される。従来のトランザクション処理に加えて、複数のフロントエンド・サーバは、特殊プロセッサ選択機能、ならびにコプロセッサのセットアップ、制御、および管理機能をも行うことになろう。理解すべきなのは、本明細書において使用されているように、データという用語は、マルチモードのデータ、すなわち、（ビデオ／データ）ストリーム、所定のブロック長、テキスト、グラフィックス、画像フォーマット、ｘｍｌ、ｈｔｍｌなど、任意の種類のデータを意味し得る。サーバをハイブリッド・システムのフロントエンドに有することによって、（特に）高いトランザクション・スループット、セル・プロセッサの作業負荷の管理、セル・プロセッサのリソース管理が優れたものとなる。

図１を参照すると、本発明に係る論理図が示されている。一般的に、本発明が提供するのは、サーバ‐プロセッサ・ハイブリッド・システム１１であって、１組の（１つ以上の）フロントエンド・サーバ１２と、１組のバックエンド・アプリケーション最適化プロセッサ（簡潔にするために、本明細書においてはプロセッサと称する）２０とを備える。図示のように、各サーバ１２は、典型的には、インフラストラクチャ１４（例えば、電子メール、スパム、ファイアウォール、セキュリティなど）と、ウェブ・コンテンツ・サーバ１６と、ポータル／フロントエンド１８（例えば、以下にさらに説明するようなインターフェース）とを含む。アプリケーション１９およびデータベース１８は、これらのサーバ上で動作する。このような場合、（複数の）サーバ１２は、典型的には、ニューヨーク州アーモンクのＩＢＭ社から販売されているＳｙｓｔｅｍ ｚサーバ（Ｓｙｓｔｅｍ ｚおよび関連の用語は、米国または他の国ならびにその両方におけるＩＢＭ社の商標である）となる。各プロセッサ２０は、典型的には、１つ以上のアプリケーション機能アクセラレータ２２と、１つ以上のデータベース機能アクセラレータ２４とを含む。そのような場合、（複数の）プロセッサ２０は、典型的には、ＩＢＭ社から販売されているｃｅｌｌ ｂｌａｄｅｓ（ｃｅｌｌ，ｃｅｌｌ ｂｌａｄｅ，および関連の用語は、米国または他の国ならびにその両方におけるＩＢＭ社の商標である）となる。さらに、（複数の）プロセッサ２０は、性能が最適かつ効率的であるように実行されているアプリケーション１９に基づいて最適化される。図示のように、サーバ１２は、典型的には通信方法（例えば、ＬＡＮ，ＷＬＡＮなど）を介して外部ソース１０からデータを受信する。そのようなデータは、サーバ１２のインターフェースを介して処理するためのプロセッサ２０へ通信される。処理済みデータは、その後、さらなる処理のために、プロセッサ２０に記憶されるか、または戻されるか、あるいはその両方が行われ、さらに外部ソース１０に記憶されるか、または戻されるか、あるいはその両方が行われ得る。図示のように、サーバ１２は、ハイブリッド・システム１１のフロントエンドを表し、プロセッサ２０は、バックエンドを表す。

本システムを、図２〜図３にさらに示す。図２は、（複数の）サーバ１２と通信する（複数の）外部ソース１０を示し、サーバ１２は、インターフェース２３を介して（複数の）プロセッサ２０と通信する。典型的には、インターフェース２３は、各サーバ１２内に実施される／含まれる入出力（Ｉ／Ｏ）ケージである。また、インターフェース２３は、ＰＣＩ（ｅｘｐｒｅｓｓ ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔｓ）２５などの１組のネットワーク・インターコネクトを含む。また、インターフェース２３は、上記包含された特許出願に示されるような他の構成要素を含んでもよい。

いずれにせよ、（複数の）プロセッサ２０上でデータが（複数の）外部ソース１０から受信され、（複数の）インターフェース２３を介して（複数の）サーバ１２へ通信されることになる。一旦受信すると、（複数の）プロセッサ２０は、当該データを処理し、処理済みデータを（複数の）サーバ２０へ戻すことになり、（複数の）サーバ１２は、同データを（複数の）外部ソース１０へ戻すことができる。また、（複数の）プロセッサ２０は、ステージング記憶装置および処理済みデータ記憶装置を活用して、元データまたは処理済みデータあるいはその両方を記憶することができる。図３に示すように、各プロセッサ２０は、典型的には、電力処理要素（ＰＰＥ）３０と、ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）３２と、１組の（例えば、１つまたはそれ以上の）典型的には複数の特殊目的エンジン（ＳＰＥ）３４とを含む。ＳＰＥは、データを処理するための負荷を共有する。

図４を簡単に参照すると、ハイブリッド・システム１１内の構成要素の配置を示す、より具体的な図が示されている。図示のように、（複数の）サーバ１２は、外部ソースＡおよびＢからデータを受信／送信し、当該データを（複数の）プロセッサ２０へ転送して処理に供する。そのような処理の後、処理済みデータは、（複数の）サーバ１２および外部ソースＡおよびＢへ戻される。また、ハイブリッド・システム１１には、ステージング記憶装置３６と、処理済みデータ記憶装置３８とがある。ステージング記憶装置３６は、処理前、処理中、または処理後、あるいはそのすべてにおいて、データを記憶するために使用することができ、処理済みデータ記憶装置は、処理済みデータを記憶するために使用することができる。

今度は図５〜図８を参照して、本発明にかかる処理例のフロー図を説明する。簡潔にするために、発明を実施するための最良の形態において、以下、サーバ１２は「Ｓ」と称し、プロセッサ２０は「Ｃ」と称する。ステップＳ１において、外部ソース（Ａ）は、接続要求を行う。ステップＳ２において、接続要求は、サーバＳによる検証後にＣへ渡される。ステップＳ３において、Ｃは接続を受け付け、ＳはＡに接続設定完了を通知する。ステップＳ４において、ストリームＰがＡからサーバＳに到着する。ＳはＰ’＝Ｔ（Ｐ）を行う。式中、ＴはストリームＰに対する変換関数である。ステップＳ５において、Ｓはデータを記憶装置にセーブするか、またはそれを他の装置へ渡すか、あるいはその両方を行うことができる。ステップＳ６において、出力バイトが連続してＣへ渡される。ステップＳ７において、ＣはＰ”＝Ｕ（Ｐ’）を行う。式中、ＵはＣによって行われる変換関数である。ステップＳ８において、Ｐ”はＳへ転送して戻される。ＳはＰ^３＝Ｖ（Ｐ”）を行う。式中、ＶはステップＳ９においてサーバＳによって行われる変換関数である。ステップＳ１０において、Ｐ^３は連続してＢまたはＡへ転送される。加えて、ステップＳ１０において、Ａは接続終了パケット（Ｅ）を提示する。ステップＳ１１において、ＳはＥを受信し、Ｓ１２において、ＳはＥを検査する。ステップＳ１３において、Ｅは接続終了パケットであると判定される。ステップＳ１４において、入力サンプリングおよび計算が終了する。ステップＳ１５において、ＳはＣにストリーム完了を通知する。ステップＳ１６において、Ｃは計算を停止する。ステップＳ１７において、ＣはＳに計算終了を通知する。ステップＳ１８において、ＳはＢに接続終了を通知する。ステップＳ１９において、ＳはＡに対して計算完了であると応答する。

別途図示されてはいないが、以下は本発明において可能となった他の制御フローの一例である。この制御フローは、データがＡから来たりまたはＢへ転送たりすることなく、要求がＣに対して直接Ｓによってなされる場合に有用である。
１．Ｓは接続要求を行う。
２．接続要求は有効か？（Ｃによって行われる）
３．はいの場合、Ｃによって受け付けられる。
４．ストリームＰがＳからプロセッサＣに到着する（Ｐは単に、所定長を有する「ブロック」入力であってもよい）。
５．ＣはＴ（Ｐ）を行う。式中、ＴはストリームＰに対する変換関数である。
６．Ｔ（Ｐ）出力バイトが連続してＳへ転送されて戻される。
７．Ｓはファイル終了またはストリーム終了にあう。
８．Ｓは通信終了パケット（Ｅ）を提示する。
９．ＣはＥを検査する。
１０．Ｅは接続終了パケットか？
１１．はいの場合、Ｃにおけるサンプリング入力を停止し、計算を停止する。
１２．ＣはＳに対して計算終了であると応答する。

本発明において、プッシュ・モデルおよびプル・モデルの両方を使用することができる。データ・メッセージを通常のデータ・パス上で送ると共に、制御メッセージを別個の制御パス上で送ることができる。ここで、２つの別個の接続ＩＤが必要となる。制御メッセージは、データ・メッセージと共に同一のパス上で送ることもできる。この場合には、１つの接続ＩＤのみが必要である。プッシュ・モデルおよびプル・モデルは共に、別個または統一されたデータ・パスおよび制御パスで実現可能である。プッシュ・モデルは、待ち時間が問題となる短いデータに有用である。制御メッセージは、通常、データ転送に関して待ち時間の制約を有する。これは、すべてのデータがプッシュされるまでデータ・ソースであるコンピュータ・プロセッサの関与を必要とする。プル・モデルは、通常、宛先のコンピュータがソースのプロセッサを関与させずにソースのメモリから直接データを読み出すことができる場合の大量のデータに有用である。ここで、データの位置およびサイズをソースから宛先へ通信する際の待ち時間は、データ転送全体にわたって容易に償却可能である。本発明の好ましい一実施の形態において、プッシュおよびプル・モデルは、交換すべきデータの長さによって選択的に呼び出される。

以下のステップは、プッシュ・モデルおよびプル・モデルがどのように動作するかを示す。
動的なモデル選択
（１）ＳおよびＣは、通信を望んでいる。送信者（ＳまたはＣ）は、以下の判断を行う。
ステップ１―データは所定長であり、プッシュ閾値（ＰＴ）より小さいか？
ステップ２―はいの場合、「プッシュ」を用いる。
ステップ３―いいえの場合、データは、既知のサイズのないストリーミング様のものである。Ｓはデータの位置アドレスなしでＣに対して「肩たたき（ｓｈｏｕｌｄｅｒ ｔａｐｓ）」する
プッシュ閾値（Ｐｕｓｈ Ｔｈｒｅｓｈｏｌｄ：ＰＴ）は、システムの設計者が所定のアプリケーションまたはデータ型（固定長またはストリーム）用に選択可能なパラメータである。
プッシュ・モデル
Ｓは（既知であれば）データ・ブロック・サイズを用いてＣに対して肩たたきする。
Ｓはアプリケーション通信レート要件（Ｒ）をルック・アップする。
Ｓは「リンク合算プール」（Ｎ）内のリンクの番号をルック・アップする。
ＳはＮを拡張または縮小することによってＲとＮとを一致させる［動的割り当て］。
ＳおよびＣはデータ転送に必要なリンク数を一致させる。
ＳはデータをＣにプッシュする。
すべてのデータ（サイズは既知）が送信されてジョブが完了すると、Ｓは接続を以下のようにして終わらせることができる。
ＳはＣに対して肩たたきすることによって接続を終わらせる。
プル・モデル
Ｓはデータ・ブロック・サイズ（既知であれば）を用いてＣに対して肩たたきする。
Ｓはアプリケーション通信レート要件（Ｒ）をルック・アップする。
Ｓは「リンク合算プール」（Ｎ）内のリンクの番号をルック・アップする。
ＳはＮを拡張または縮小することによってＲとＮとを一致させる［動的割り当て］。
ＳおよびＣはデータ転送に必要なリンク数を一致させる。
ＣはＳメモリからデータをプルする。
すべてのデータ（サイズは既知）が送信されてジョブが完了すると、Ｓは接続を以下のようにして終わらせることができる。
ＳはＣに対して肩たたきすることによって接続を終わらせる。

図４において、サーバ１２（「Ｓ」）およびプロセッサ２０（「Ｃ」）は、ステージング記憶装置３６に対するアクセスを共有する。ＳがデータセットＤをＣへ転送する必要がある場合には、以下のステップが生じなければならない。すなわち、（ｉ）ＳはＤを読み出して、（ｉｉ）リンクＬ上でＤをＣへ転送しなければならない。代わりに、Ｓは、Ｃにデータセットの名前を通知することもでき、Ｃは、ステージング記憶装置３６から直接このデータセットを読み出すこともできる。これが可能なのは、ＳおよびＣがステージング記憶装置３６を共有しているからである。これに必要なステップは、以下に列挙するとおりである（繰り返すが、簡潔にするために、サーバ１２およびプロセッサ２０を称するのに「Ｓ」および「Ｃ」をそれぞれ使用する）。
ステップ１―Ｓはデータセットの名前および位置（データセット・デスクリプタ）を制御パスに沿ってＣに提供する。これが「肩たたき」としての役割を果たす。Ｃは、Ｓから「プッシュ」されたデータに対してポーリングすることによってこの情報を受信する。
ステップ２―Ｃはデータセット・デスクリプタを使用してＤからデータを読み出す。
ステップ１―プッシュまたはプルの実施が可能となる。
ステップ２―プルまたはプッシュの実施が可能となる。
ステップ１（プッシュ）―「制御パス」
Ｓは（既知であれば）データセットの名前および位置を用いてＣに対して肩たたきする（書き込む）。
ステップ１（プル）―「制御パス」
Ｓは（既知であれば）データ・ブロック・サイズを用いてＣに対して肩たたきする。
ＣはデータをＳメモリからプルする。
ステップ２（プル型）―「データ・パス」
ステージング記憶装置３６は、データセットの名前およびデータセットのブロック位置と共にテーブルを記憶する。
Ｃはデータセットの名前Ｄを用いてステージング記憶装置３６に対して読み出し要求を行う。
ステージング記憶装置３６は、ブロックのリストを提供する。
Ｃはステージング記憶装置３６からブロックを読み出す。
Ｃはデータセットの終了にあう。
Ｃは接続を終わらせる。
ステップ２（プッシュ型）―「データ・パス」
ステージング記憶装置３６は、データセットの名前およびデータセット・ブロック位置と共にテーブルを記憶する。
Ｃはデータセットの名前Ｄを用いてステージング記憶装置３６に対する読み出し要求を行う。
ステージング記憶装置３６の記憶コントローラは、Ｄのディスク・ブロックを直接Ｃメモリへプッシュする。
Ｄは、接続を終了する。

本発明の様々な局面の上記説明は、図示および説明という目的のためになされてきた。これは、網羅的でもなく、本発明を開示されたのと同一の形式に限定するものでもなく、数多くの変形および変種が可能であることは明らかである。当業者にとって明白であるようなそのような変形および変種は、添付の請求項によって規定されるような本発明の範囲内に含まれることになる。

本発明に係るサーバ‐プロセッサ・ハイブリッド・システムの構成要素を示す箱図を示す。 本発明に係る図１のシステムのより詳細な図を示す。 本発明に係るハイブリッド・システムの（複数の）バックエンド・アプリケーション最適化プロセッサのより具体的な図を示す。 本発明に係るサーバ‐プロセッサ・ハイブリッド・システム内の通信フローを示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。

符号の説明

１０ クライアント―社内および外部
１１ サーバ‐プロセッサ・ハイブリッド・システム
１２ フロントエンド・サーバ
１４ インフラストラクチャ―メール、スパム、ファイアウォール、セキュリティ
１６ ウェブ・コンテンツ・サーバ
１７ ポータル／フロントエンド
１８ データベース
１９ アプリケーション
２０ バックエンド・アプリケーション最適化プロセッサ
２２ アプリケーション・アクセラレータ
２４ データベース関数アクセラレータ

Claims (19)

1. データを処理するためのフロントエンド・サーバ‐プロセッサ・ハイブリッド・システムであって、
   外部ソースから前記データを受信するための１組のフロントエンド・サーバと、
   前記１組のフロントエンド・サーバから前記データを受信し、前記データを処理し、処理済みデータを前記１組のフロントエンド・サーバへ返すための１組のバックエンド・アプリケーション最適化プロセッサと、
   前記１組のフロントエンド・サーバのうちの少なくとも１つのサーバ内にあり、１組のネットワーク・インターコネクトを有し、前記１組のフロントエンド・サーバを前記１組のバックエンド・アプリケーション最適化プロセッサに接続する、インターフェースと
   を備える、システム。
2. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項１に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
3. 前記インターフェースは、１組の前記フロントエンド・サーバの各々で具体化される、請求項１に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
4. 前記１組のバックエンド・アプリケーション最適化プロセッサの各プロセッサは、
   電力処理要素（ｐｏｗｅｒ ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ：ＰＰＥ）と、
   前記ＰＰＥに結合された要素インターコネクト・バス（ｅｌｅｍｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ ｂｕｓ：ＥＩＢ）と、
   前記ＥＩＢに結合された１組の特殊目的エンジン（ｓｐｅｃｉａｌ ｐｕｒｐｏｓｅ ｅｎｇｉｎｅｓ：ＳＰＥ）と
   を備える、請求項１に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
5. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項４に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
6. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、アプリケーション・アクセラレータ、およびデータベース・アクセラレータをさらに備える、請求項１に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
7. ステージング記憶装置と、
   処理済みデータ記憶装置と
   をさらに備える、請求項１に記載のフロントエンド・サーバ‐プロセッサ・ハイブリッド・システム。
8. データを処理するための方法であって、
   フロントエンド・サーバ上で外部ソースから前記データを受信するステップと、
   前記フロントエンド・サーバからバックエンド・アプリケーション最適化プロセッサへ、１組のネットワーク・インターコネクトを有しかつ前記フロントエンド・サーバにおいて具体化されるインターフェースを介して前記データを送信するステップと、
   前記データを前記バックエンド・アプリケーション最適化プロセッサ上で処理して、処理済みデータを生じさせるステップと、
   前記フロントエンド・サーバ上で前記バックエンド・アプリケーション最適化プロセッサから前記処理済みデータを受信するステップと
   を含む、方法。
9. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項８に記載の方法。
10. 前記バックエンド・アプリケーション最適化プロセッサは、
    電力処理要素（ＰＰＥ）と、
    前記ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）と、
    前記ＥＩＢに結合された１組の特殊目的エンジン（ＳＰＥ）と
    を備える、請求項８に記載の方法。
11. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項１０に記載の方法。
12. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、アプリケーション・アクセラレータ、およびデータベース・アクセラレータをさらに備える、請求項８に記載の方法。
13. データを処理するためのサーバ‐プロセッサ・ハイブリッド・システムを配備するための方法であって、
    フロントエンド・サーバ上で外部ソースから前記データを受信し、
    前記フロントエンド・サーバからバックエンド・アプリケーション最適化プロセッサへ、１組のネットワーク・インターコネクトを有しかつ前記フロントエンド・サーバにおいて具体化されるインターフェースを介して前記データを送信し、
    前記データを前記バックエンド・アプリケーション最適化プロセッサ上で処理して、処理済みデータを生じさせ、
    前記フロントエンド・サーバ上で前記バックエンド・アプリケーション最適化プロセッサから前記処理済みデータを受信する
    ように動作可能なコンピュータ・インフラストラクチャを提供することを含む、方法。
14. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項１３に記載の方法。
15. 前記インターフェースは、前記１組のフロントエンド・サーバのうちの少なくとも１つのサーバおいて具体化される、請求項１３に記載の方法。
16. 前記バックエンド・アプリケーション最適化プロセッサは、
    電力処理要素（ＰＰＥ）と、
    前記ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）と、
    前記ＥＩＢに結合された１組の特殊目的エンジン（ＳＰＥ）と
    を備える、請求項１３に記載の方法。
17. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項１３に記載の方法。
18. ステージング記憶装置と、
    処理済みデータ記憶装置と
    をさらに備える、請求項１３に記載の方法。
19. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、アプリケーション・アクセラレータ、およびデータベース・アクセラレータをさらに備える、請求項１３に記載の方法。

Images