(57)【要約】      （修正有）【課題】メッセージレイテンシ及びロバスト性を更に改善するために、従来のデュアルバスアーキテクチャを超えてファブリック数を拡張する。【解決手段】第１の仮想ファブリック(220x)と第１の複数のファブリック(620x)のうちの１つとの間、及び第２のファブリック(220y)と第２の複数のファブリック(620y)のうちの１つとの間の現在のマッピングは、処理ノード(612,614)の各々に維持され、メッセージは、送信元ノードとして作用する複数の処理ノード(612,614)のうちの１つにより、宛先ノードとしての他の処理ノード(612,614)のうちの１つ又は２つ以上へ、送信元ノードに存在する宛先ノードについての現在のマッピングに従い、及び第１及び第２のファブリックの何れがI/Oサービスレイヤ512の要求で指定されているかに基づいて、送信される。【選択図】図６
2006053896.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムの複数の処理ノード(612,614)を接続するファブリックの個数を、第１の仮想ファブリック(220x)及び第２の仮想ファブリック(220y)からそれぞれ第１の複数のファブリック(620a)及び第２の複数のファブリック(620b)へと拡張する方法であって、
前記第１の仮想ファブリック(220x)と前記第１の複数のファブリック(620a)のうちの１つとの間、及び前記第２の仮想ファブリック(220y)と前記第２の複数のファブリック(620b)のうちの１つとの間の現在のマッピングを前記処理ノード(612,614)の各々においてそれぞれ維持し、
送信元ノードとしての前記処理ノード(612,614)のうちの１つ又は２つ以上から、宛先ノードとしての他の処理ノード(612,614)のうちの１つ又は２つ以上へ、前記送信元ノードの１又は２つ以上のI/Oサービスレイヤ(512)により要求されたトランザクションに応じてメッセージを送信し、該メッセージが、前記送信元ノードにより維持されている現在のマッピング、及び前記第１の仮想ファブリック(620a)及び前記第２の仮想ファブリック(620b)の何れが前記トランザクション要求により指定されるかに従って、前記第１の複数のファブリック(620a)及び前記第２の複数のファブリック(620b)の一方を介して送信される、
方法。
【請求項２】
所定のアルゴリズムに従って前記複数の処理ノード(612,614)のうちの１つ又は２つ以上における現在のマッピングを異なるマッピングに変更するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記送信元ノードの前記１つ又は２つ以上のI/Oサービスレイヤのうちの１つが、前記送信元ノードが特定の宛先ノードへ送信すべきメッセージを要求するのに経由する前記第１の仮想ファブリックと前記第２の仮想ファブリックとの間で切り換わる際に、現在のマッピングを変更する前記ステップが、前記特定の宛先ノードについて実行される、請求項２に記載の方法。
【請求項４】
各処理ノード(612,614)における前記マッピングが、前記送信元ノードとしての前記複数の処理ノード(612,614)のうちの１つと、宛先ノードとしての前記処理ノード(612,614)のうちの１つ又は２つ以上との間で、前記送信元ノードの前記１つ又は２つ以上のI/Oサービスレイヤ(512)により要求されたトランザクションを開始するネットワークサービスレイヤ(514)により保持される、請求項２に記載の方法。
【請求項５】
前記１つ又は２つ以上のI/Oサービスレイヤ(512)のうちの１つが、プロセッサノード(612)である前記複数の処理ノード(612,614)のうちの２つ又は３つ以上の間でプロセッサ間メッセージトランザクションを開始させるメッセージングシステムである、請求項２に記載の方法。
【請求項６】
コンピュータシステムの複数の処理ノード(612,614)を接続する第１の複数のファブリック(620x)及び第２の複数のファブリック(620y)を有し、該第１の複数のファブリック(620x)が第１の仮想ファブリック(220x)から拡張されたものであり、及び該第２の複数のファブリック(620y)が第２の仮想ファブリック(220y)から拡張されたものである、コンピュータシステムであって、
前記第１の仮想ファブリック(220x)と前記第１の複数のファブリック(620x)のうちの１つとの間、及び、前記第２の仮想ファブリック(220y)と前記第２の複数のファブリック(620y)のうちの１つとの間の現在のマッピングを、前記処理ノード(612,614)の各々でそれぞれ維持する手段(514)と、
送信元ノードとしての前記処理ノード(612,614)のうちの１つ又は２つ以上から、宛先ノードとしての前記処理ノード(612,614)のうちの１つ又は２つ以上へ、前記送信元ノードの１つ又は２つ以上のI/Oサービスレイヤ(512)により要求されたトランザクションに応じてメッセージを送信する手段(514,542,616)であって、該メッセージが、前記送信元ノードにより維持されている前記現在のマッピング、及び前記第１の仮想ファブリック(620x)及び前記第２の仮想ファブリック(620y)の何れが前記トランザクション要求において指定されているかに従って、前記第１の複数のファブリック(620x)及び前記第２の複数のファブリック(620y)の一方を介して送信される、メッセージを送信する手段(514,542,616)と
を備えている、コンピュータシステム。
【請求項７】
所定のアルゴリズムに従って、前記複数の処理ノードのうちの１つ又は２つ以上における前記現在のマッピングを異なるマッピングへ変更する手段(514)を更に備え、該所定のアルゴリズムが、前記第１の複数のファブリック及び前記第２の複数のファブリックにわたってほぼ均一にパケットを分散させるよう設計されたものである、請求項６に記載のコンピュータシステム。
【請求項８】
前記１つ又は２つ以上のI/Oサービスレイヤ(512)のうちの１つが、プロセッサノード(612)である前記複数の処理ノード(612,614)のうちの２つ又は３つ以上の間で、前記第１の仮想ファブリック(620x)及び前記第２の仮想ファブリック(620y)の一方を介してプロセッサ間メッセージトランザクションを開始させるメッセージングシステム(540)である、請求項６に記載のコンピュータシステム。
【請求項９】
前記１つ又は２つ以上のI/Oサービスレイヤ(512)が、コントローラノード(614)である前記複数の処理ノード(612,614)のうちの２つ又は３つ以上の間で、前記第１の仮想ファブリック(620x)及び前記第２の仮想ファブリック(620y)の一方を介してデータトランザクションを要求するストレージインタフェイスサービス及びドライバを含む、請求項８に記載のコンピュータシステム。
【請求項１０】
宛先の処理ノードの現在のマッピングを変更する前記手段が、送信元処理ノードの前記要求側のI/Oサービスレイヤによって前記ネットワークサービスレイヤへ呼び出されるAPIを更に備え、該APIが、前記宛先の処理ノードを識別するノードIDを指定する、請求項７に記載のコンピュータシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
この出願は、2004年6月7日に出願された米国仮出願第60/577,749号の利益を主張するものである。
【０００２】
ほぼ30年の間、大規模コンピュータシステムは、銀行業、データベース管理等のようなアプリケーションのオンライン（したがってリアルタイム）トランザクション処理を扱うよう設計され構築されてきた。これらのコンピュータシステムは、多くの場合、サーバと呼ばれ、ノンストップで実行するように設計されると同時に、高度な可用性及び信頼性（故障間の合間が長い）を提供する。これを達成するために、これらのサーバは、ハードウェア及びソフトウェアが高度なモジュール性及び冗長性を有するよう設計される。例えば、サーバの処理資源は、互いに並列に動作する多数の処理ノードにわたって分散される。処理ノードには、一般に、プロセッサノード（すなわちCPUプロセッサモジュール）、及び、入出力（I/O）コントローラノードの双方が含まれる。該I/Oコントローラノードは、ディスクドライブ、イーサネットアダプタカード等のI/Oデバイスを駆動するものである。特定の処理ノードの故障は、その作業負荷を残りの処理ノードにわたって再分散することを介して克服することができる。今日のノンストップサーバの処理能力は、並列に実行される文字通り数千個のCPUモジュール及び入出力（I/O）コントローラモジュールのクラスタリングを介して拡大させることができる。
【０００３】
最近まで、処理ノード（すなわちCPUモジュール）は、従来通り、プロセッサノード間でメッセージを伝送するプロセッサ間通信（IPC）バスを介して相互に接続されてきた。これらのメッセージは、その機能の中でもとりわけ、処理ノードのアクティビティを包括的な統一体へと調整する働きをする。ソフトウェアコンポーネント及びハードウェアコンポーネントの場合と同様に、IPCバスの複製を介してフォールトトレランスも達成される。このデュアルIPCバスは、総称して「X」及び「Y」バスと呼ばれてきており、具体的には、Tandem Computers社によって販売される製品の「Dynabus」を指す。双方のパスが動作している時、それら双方のバスが使用されるが、バスの一方が故障すると、サーバは、この障害を許容することができ、問題が突き止められて修復されるまで、１つのパスのみで実行を継続することができる。
【０００４】
初期のサーバ設計は、プロセッサ間通信（すなわちプロセッサノード間）用にのみデュアルIPCバスを使用しており、サーバの（I/O）コントローラモジュールとの通信用には使用していなかった。また、個別の冗長なI/Oバスも、CPUモジュールをI/Oコントローラに接続するのに使用されていた。典型的には、冗長性は、２つの別個のI/Oバスに接続されたデュアルポートI/Oコントローラノードを介して達成されていた。各I/Oバスは、プロセッサノードの異なる１つに接続されていた。より最近の設計は、「X」ファブリック及び「Y」ファブリックであるデュアルファブリックを有するシステムエリアネットワーク（SAN）上でプロセッサ間通信（すなわちメッセージトランザクション）及びI/O（データ転送）トランザクションを組み合わせてきた。複数のトランザクションタイプを共に組み合わせることによって、それらトランザクションタイプは、ハードウェア及びソフトウェアを共有し、これにより故障する可能性のあるパスが少なくなるため、全体の設計がよりローバストなものとなる。SANを使用してIPCデータトランザクション及びI/Oデータトランザクションを共に操作することに関する更なる背景については、「Fail-Fast, Fail-Functional, Fault-Tolerant Multiprocessor System」と題する米国特許第5,751,932号を参照されたい。
【０００５】
サーバの処理能力に対する要求が増加し続けるにつれて、これらのデュアルバス又はデュアルファブリックに接続される処理ノードの個数も増加し続けている。SANアーキテクチャの場合、プロセッサノード及びコントローラノードの双方を組み合わせることによって、ファブリックの帯域幅に対する要求が大幅に増加する。帯域幅は、増加の一途をたどるCPUモジュール及びI/Oモジュールの処理速度、及びメッセージの待ち時間を小さく維持する要望によって、更に増大する。この問題を更に悪化させるのが、デュアルバス／ファブリックアーキテクチャでは、双方のバス又はファブリックに接続された処理ノード間のトランザクションをサポートすべく帯域幅を２倍にするために該双方のバス又はファブリックに依存することができない、という事実である。この理由は、バスの１つ又はファブリックの１つの障害によって影響を受けずに実行するようにサーバを設計しなければならないからである。これは、サーバで実行されるプロセスのサイズを、バスの１つ又はファブリックの１つのみが動作した状態で実行されるように調整しなければならないことを意味する。別の言い方をすれば、第２のバス又は第２のファブリックは、性能のために「アイドルスタンバイ」となる責務を負わなければならない。
【０００６】
このため、バスの個数又はファブリックの個数を、このようなシステムで従来から使用されてきた２つを超えて拡張することが非常に望ましいとされてきた。これに対する障害は、デュアルバスアーキテクチャ又はデュアルファブリックアーキテクチャには、長年の間、非常に大量の時間及び資源がつぎ込まれてきたということである。処理ノード間の通信トランザクションの要求及び開始を調整するように記述されたソフトウェアは、それら処理ノードがCPUモジュール（メッセージングトランザクション）であろうと、I/Oコントローラ（データトランザクション）であろうと、２つのバス又は２つのファブリックしか考慮していないものである。これは、特にIPCメッセージに当てはまる。IPCメッセージのために、まさに最初のノンストップサーバが設計されて以来、デュアルバス（及び現在ではデュアルファブリック）が使用されてきた。その結果、バスの個数又はファブリックの個数を従来の２つを超えて拡張するには、ソフトウェア開発に膨大な作業が必要となる。
【０００７】
本発明の実施形態の詳細な説明では、添付図面への参照を行われる。
【発明を実施するための最良の形態】
【０００８】
［表記及び用語体系］
以下の説明全体にわたって、及び、特許請求の範囲において、特定の特徴、装置、プロシージャ、プロセス、及びそれらに起因するアクションを指すのに一定の用語が使用される。これに加えて、当業者は、装置、プロシージャ、プロセス、結果、及びそれらの特徴を異なる名前によって指すことができる。例えば、処理ノードという用語は、一般に、プロセッサ間通信（IPC）ファブリック又はバスに接続されたCPUモジュール及びI/Oコントローラの双方を示すのに使用されるが、プロセッサノード及びコントローラノードという用語は、各タイプをそれぞれ示すことを目的としている。本書は、名前が異なるが機能が異ならないコンポーネント、プロシージャ、又は結果を区別することを目的としていない。例えば、IPCバス及びIPCファブリックという用語は、本書では時に交換可能に使用することができる。IPCファブリックは、通常、一連のスイッチ又はルータを介して処理ノード（中央処理装置（CPU）モジュール及び入出力（I/O）コントローラの双方を含む）を接続して、システムエリアネットワーク（SAN）を形成するバスを示す。IPCバスは、通常、プロセッサノード（すなわちCPUモジュール）のみを接続する従来のデュアルバスアーキテクチャを指す。ファブリックとバスとを区別する努力はするが、それら２つの区別は、本書で開示する本発明にとって重要ではないことが当業者には認識されよう。以下の説明及び特許請求の範囲では、用語「含む」及び「備える」は、制限のない態様で使用され、したがって「含むが、これらに限定されるものではない」との意味に解釈されるべきである。
【０００９】
［詳細な説明］
以下の説明は、本発明の様々な実施形態を対象とするものである。これらの実施形態の１つ又は２つ以上が好ましいものとなり得るが、開示した実施形態は、本書に特に明白に指定がない限り、特許請求の範囲を含めてこの開示の範囲を限定するものと解釈されるべきではなく、また、それ以外に、限定するのに使用されるべきではない。これに加えて、以下の説明が幅広い用途を有し、どの特定の実施形態の説明も、その実施形態の例示を意味するものでしかなく、特許請求の範囲を含めて、この開示の範囲をその実施形態に限定することを暗示することを目的とするものでないことが当業者には理解されよう。例えば、様々な実施形態は、或るタイプのネットワークアーキテクチャ及び／又はトポロジーを使用することがあるが、本書に開示した発明は、他の全ての互換性のあるネットワークアーキテクチャ及びトポロジーに容易に適用できることが当業者には認識されよう。
【００１０】
図１は、デュアルプロセッサ間通信（IPC）のＸバス110及びＹバス112を含む従来のサーバアーキテクチャを示すコンピュータシステム100のブロック図である。これらのＸバス110及びＹバス112によって、プロセッサノード114a〜114dは通信接続される。双方のバスは、データの送受信について双方向である。コンピュータシステム100は、IPCバス110,112及びネットワーク（Net）インタフェイス120,122を介して他のこのようなシステムに接続されて、更に大きく更に強力なコンピュータシステムを形成することができる。プロセッサノード114a〜114dのそれぞれを備える中央処理装置（CPU）モジュールは、少なくとも１つのCPU118a〜118d、メモリ119a〜119d、及び入出力（I/O）プロセス（IOP）116a〜116dを含む。IOP116a〜116dは、図示するように、プロセッサノードと、当該プロセッサノードに接続されたI/Oコントローラ150との間の通信を円滑にするものである。
【００１１】
プロセッサノード114a〜114dのそれぞれで実行されるメッセージングシステムソフトウェアライブラリは、送信元プロセッサノードと宛先プロセッサノードとの間でデュアルバス110,112を介してメッセージトランザクションを開始する。各プロセッサノード114a〜114dには、ノード（識別子）IDが割り当てられ、メッセージングシステムは、パケットという形でメッセージをパッケージ化する。各メッセージは、トランザクションを送信する送信元処理ノード及びトランザクションを受信する宛先処理ノードの双方に対応するノードIDを含む。プロセッサノード114a〜114dの間で、デュアルバス110,112の一方を介して、メッセージトランザクションが開始され送信される。トランザクションは、２つのバス間で分割されることは決してない。これは、メッセージパケットは順番通りに配信されることになっており、所与の時刻における各バス上の輻輳量等の所与の変量にはかかる配信を保証することができないからである。最初に、プロセッサノードのそれぞれについて、２つのバスの一方への割り当てが行われる。メッセージングシステムは、特定のプロセッサノードの割り当てをデュアルバス110,112の一方から他方へ切り換えることが安全であると判断すると（例えば、肯定応答されていないメッセージが特定の宛先に対して開始されていなかった場合、又はエラーがメッセージ全体の再送信を必要とした後に「再試行」が開始する場合）、その切り換えを行うことができる。ノードID及びIPCバスの割り当ては、メッセージングシステムによって維持され、再割り当てが行われるたびに更新される。
【００１２】
図２は、ノンストップサーバアーキテクチャの最近の発展したものの実施形態を示している。このアーキテクチャでは、コンピュータシステム200の全ての処理ノード212a,212b,214a〜214d（例えばプロセッサノード及びI/Oコントローラノードの双方）を、システムエリアネットワーク（SAN）210を介して互いに接続することができる。SAN210は、図１の個別のIPC及びI/Oバスを２つのスイッチファブリックX0及びY0へとマージするのに役立つ。図２の例では、各ファブリックX0及びY0は、それぞれSANルータ216x,216yを介して、処理ノード212a,212bの全てと、I/Oコントローラノードの１つを除いた全てとを接続する。コントローラ214b,214cは、それぞれ１つのファブリックに接続されたものとして示されている。その理由は、コントローラノード214a,214bが接続されたI/Oデバイス218は基本的に２つのファブリック間で共有されるが、コントローラノードへのアクセスをファブリックの１つにのみ制限することが望ましいことがあるからである。更なる処理ノード（おそらくはシステム200と同様又は同一の別のコンピュータシステム）への拡張は、SANネットワーククラウド220x,220yへのルータ接続を介して行われる。これらの拡張接続は、図１のネットインタフェイス120,122によって行われたものと類似する。
【００１３】
図３は、図２のプロセッサノード212a〜212bの可能な一実施形態の簡単なブロック図である。デュアルCPU304a〜304bのそれぞれは、それ自体のキャッシュメモリ302a,302bをそれぞれ有する。CPU304a〜304bは、それらの間にある共通メインメモリ308を共有する。これら２つのCPU302a,302bは、CPU304a〜304bの一方が故障した場合に、互いにロックステップで同じ処理機能を実行して高速の障害復旧を提供する。処理パスの各々は共通のSANインタフェイス306に接続されている。この共通SANインタフェイス306は、CPU304a〜304b用のSAN210への物理インタフェイス及び接続ポイント、並びにCPUと共通メインメモリ308との間の物理インタフェイス及び接続ポイントを提供する。SANインタフェイス306は、CPU304a〜304bによって実行されるあらゆるSANオペレーションとメモリオペレーションとを比較して、それらが常に同一であることを確認する。SAN210に接続された他の処理ノードとの間のIPCメッセージ及びデータトランザクションの送受信はSANインタフェイス306を介して行われる。SANインタフェイス306は、２つのファブリックX0310及びY0312の各々に１つずつの２つの双方向出力ポートを提供する。プロセッサノード及びコントローラノードに関する更に詳細な内容は、本開示の必要な範囲外のものであることが当業者には理解されよう。
【００１４】
図１のプロセッサノード114a〜114dの構造は、図３のプロセッサノードと同様のものであることに留意されたい。しかし、図１のプロセッサノード114a〜114dは、図１に示すように、図３の単一の２ポートSANインタフェイス308ではなく、（Ｘバス及びＹバス用の）IPCへのデュアルポートインタフェイス、並びにI/Oコントローラデバイスへの個別の複数のI/Oインタフェイスを有する。双方のタイプのインタフェイス（すなわちプロセッサ間及びI/O）を単一の接続に組み合わせ、それによって、全てのタイプのトランザクション（すなわち、プロセッサノード対プロセッサノード、プロセッサノード対コントローラノード、及びコントローラノード対コントローラノード）について共通のハードウェア及びソフトウェアを使用できるようになることの利点が、当業者に認識されよう。
【００１５】
図２のシステム200を参照すると、起動時に、SAN210に取り付けられた各処理ノードは、一意のノードIDによって識別される。この一意のノードIDは、例えば20ビット長とすることができる。このIDは、ノードの「SANアドレス」とみなされ、SAN210にわたりノード間でI/O転送をルーティングするのに使用される。SAN IDは、システム起動中にサービスプロセッサ（SP）（図示せず）によって割り当てられる。起動中に、システム構成に関する情報を含む複数のシステムテーブルがSPにより生成されてシステムのプロセッサノードへロードされる。SPは、ハードウェアコンポーネントの構成（すなわちハードウェアコンポーネントのタイプ、及びハードウェアコンポーネントの他のハードウェアコンポーネントに対するロケーション）に基づいて、SANの論理トポロジーを決定する。SPは、システムのブートに先立ち、構成期間中にSANノードテーブル（SNT）を構築する。SNT及びその他のシステムテーブル内の情報は、システム200における全てのSAN処理ノードの構成（すなわちトポロジー）を記述する。各プロセッサノードのノードIDは、適当なSANインタフェイス306のハードウェアレジスタにロードされる。各SANルータ216x,216yにルータテーブルがロードされてルーティングストラテジーが実施される。
【００１６】
ルータ216x,261yの一実施形態を図４に示す。図示するように、ルータは、任意の入力を任意の出力に同時に接続できる６ポートクロスバースイッチ402である。ルータ216x,216yは、入力420のためのFIFOバッファと、ルーティングアービトレーション及びリンクレベルフロー制御のための論理回路422と、ルーティングテーブル424とを有する。ルーティングテーブルを起動時にロードするサービスプロセッサバス426が示されている。フロー制御やルートストラテジーといったルータ216x,216yの更なる細部は、この開示の必要な範囲を越えたものであることが当業者には理解されよう。
【００１７】
図５Ａは、図２のシステム200の処理ノード212a,212b,214a〜214d（並びにファブリック220x,220yのそれらのノード）の各々に存在してそれら各処理ノードにより実行されるソフトウェアプロセスの幾つかの実施形態を示している。同図から明らかなように、各レイヤがその上下のレイヤに対してトランスペアレントとなるようにレイヤ間の階層関係が作成される。これにより、他のレイヤに影響を与えることなく各レイヤを変更することが可能になる。アプリケーションサービスレイヤ511は、典型的には、最上位レベルで実行され、I/Oサービス512の要求を開始させるクライアントプロセスを含む。I/Oサービス512は、メッセージシステムサービス（例えばプロセッサ間通信）及びストレージインタフェイスサービス（例えばプロセッサノードにより開始されるコントローラノードを含むデータトランザクション）を含むことができる。ネットワークサービスレイヤ514は、I/Oサービスレイヤにより要求されたトランザクションを開始させる。ネットワークサービスレイヤ514は、要求されたトランザクションを構成するパケットをSAN210を介して適当な宛先ノード212a,212b,214a〜214d並びにファブリック220x,220yの宛先ノードへ物理的に送信するプロセスを操作する。
【００１８】
図５Ｂは、ソフトウェアプロセスの階層特性を更に示している。これらソフトウェアプロセスをインスタンス化したもの（instantiation）がプロセッサノードの各々に存在する。（プロセッサノードＡで実行される）クライアントプロセス530aがプロセッサ間メッセージトランザクションを要求したことに応じて、メッセージシステム540aは、該要求されたメッセージトランザクションをネットワークサービスレイヤ514aがSANハードウェア510を介して開始させることを要求する。メッセージングシステム540aからのこの要求は、送信元プロセッサノード及び宛先プロセッサノード（この場合にはそれぞれプロセッサノードＡ,Ｂ）並びにメッセージを送信するのに経由するファブリック（すなわちX0又はY0）のハンドル又はノードIDを含む。ネットワークサービスレイヤは、メッセージシステムレイヤ540aが対象とするSANパスを介して外部へのトランザクションを実際に開始することの詳細を取り扱う。典型的にはクライアントはプロセスであるが、他のオペレーティングシステムに関連するエンティティとすることも可能であることが当業者に理解されよう。
【００１９】
図１におけるようなアーキテクチャで使用されるメッセージシステムコードに対して大きな変更を行うことを回避するために、また、SANに関連する処理を別個の機能レイヤに隔離するために、メッセージシステムサービスは、実際には、２つのレイヤ、すなわち、メッセージシステムレイヤ540a,540bの一部であるメッセージシステムプロシージャと、メッセージシステムドライバレイヤ542a,542bの一部であるメッセージシステムドライバプロシージャとに細分される。メッセージシステムプロシージャは、プロシージャのライブラリであり、コンピュータシステム上で実行されるオペレーティングシステムの一部を成す。これらは、図１に示すようなデュアルバスアーキテクチャの上記実施態様のメッセージシステムに存在する基本的に同じプロシージャである。メッセージシステムドライバプロシージャは、プロシージャのライブラリであり、これもまたオペレーティングシステムの一部をなす。これらのプロシージャは、メッセージシステムプロシージャとネットワークサービスとの間のレイヤとして動作する。このレイヤは、ネットワークサービスレイヤ514a,514bを使用してメッセージを送受信するのに必要なSAN固有の知識を含む。
【００２０】
前述したように、メッセージレイテンシ及び更なるローバスト性に対する要望によって、従来のデュアルバスアーキテクチャを超えてファブリック数及びバス数を拡張することが高く要望されている。しかし、メッセージングシステムソフトウェアは、高度にインストールされてきており、更なるファブリックを操作するよう書き換えるのは極めて困難であると共に極めて多くの時間を要することになる。デュアルファブリック／バスアーキテクチャは、既存のコードに深く埋め込まれるようになってきたものである。
【００２１】
図６は、SAN610のファブリック数がn個のファブリックXi及びm個のファブリックYjに拡張されたコンピュータシステム600の一実施形態を示している（i＝1〜n、j＝1〜m、n,mは任意の整数）。ファブリックXiのための最小限n個のルータ616x（1〜n）及びファブリックYjのための最小限m個のルータ616x（1〜m）を使用して、各ファブリック毎に処理ノードが相互接続される。これらのルータは、実質的に図４に示すルータとして実施することができる。各プロセッサノード毎のSANインタフェイス（図示せず）は、現在、合計でn（Xiファブリック用）＋m（Yjファブリック用）個の双方向ポートを有していなければならない。更に、現在、ネットワーククラウドX1,X2,…,Xn及びY1,Y2,…,Ymによって示すように、ルータリンクを介してファブリックに追加することができる、他の処理ノードに対して利用可能となるn＋m個の追加のコネクタが存在する。コントローラノード614a,614bは、ファブリックの全てに接続されるが、コントローラノード614aのYjファブリックへのm個のリンクは、単純化のため１つのラインにまとめられており、コントローラノード614bのファブリックXjへのn個のリンクについても同様である。
【００２２】
コンピュータシステム600の一実施形態では、メッセージングシステムに対してファブリックの個数をトランスペアレントに拡張する技法が実施される。これを達成するために、多くのコンピュータシステムで使用されている仮想メモリを物理メモリへ変換する技法と同様の技法が使用される。図５Ａのレイヤのネットワークサービス514（処理ノード612a,612b,614a,614b並びにファブリック620x（1〜n）,620y（1〜m）の処理ノードに存在する）は、元の２つのファブリックX0,Y0（I/Oサービスレイヤ512はこれを初めに認識するようプログラミングされている）の各々と、拡張されたファブリックXi,Yjの１つとのそれぞれの間のマッピングを確立するよう変更されている。このマッピングは、個々の各ノード毎に、X0がファブリックXiの１つにマッピングされ、及びY0がファブリックYjの１つにマッピングされるように、SAN610に接続された処理ノード（又はプロセッサノードのみ）の各々毎に別個に実行することが可能である。
【００２３】
図７に示す一実施形態では、ネットワークサービスレイヤ514は、処理ノード1〜Zの各々毎にテーブル700に示すようなテーブルにシステム起動時の初期マッピングを確立する。図７の例では、n＝m＝4である。一実施形態では、送信元ノードSのテーブルは、考え得る各宛先ノード毎にエントリを１つずつ有することが可能である。該エントリは、ノードID並びにXi,Yjへの現在のマッピング割り当てを含む。例えば、仮想X0ファブリック（メッセージシステムは、現在、何が仮想X0ファブリックになっているかに気づいていない）を介して送信元ノードと宛先ノードとの間でメッセージトランザクションを開始することを図５Ｂのメッセージシステム540aが要求すると、ネットワークサービス514レイヤは、送信元ノードのマップに従って宛先ノードのノードIDが現在割り当てられている物理ファブリックXi上でトランザクションを単純に開始する。これと同じことが、Y0の仮想ファブリックのトランザクションを指定するメッセージシステムの場合にも当てはまる。ネットワークサービスレイヤは、実際には、送信元ノードのマップに従って宛先ノードが現在割り当てられている物理Yjファブリックを介してトランザクションを開始する。
【００２４】
図７の例では、テーブル700を維持する送信元ノードのメッセージシステムが、「仮想」Y0ファブリックを介して、ノードID＃3を有する宛先ノードへメッセージを送信することを要求すると、送信元ノードのネットワークサービスレイヤは、実際には、メッセージを構成するパケットを、実際のファブリックY3を介して、ID＃3が割り当てられた宛先ノードへ送信する。トランザクションが仮想ファブリックX0を介して要求された場合には、ネットワークサービスレイヤは、代わりに、X3ファブリックを介してトランザクションを開始することになる。
【００２５】
元の２つのファブリックの一方から複数の実際のファブリックのうちの１つへの上述のトランザクションプロセスは、各プロセッサノード毎のメッセージシステムのインスタンス化に対して完全にトランスペアレントである。このため、ファブリックの個数を拡張させるためにメッセージシステムレイヤをリエンジニアリングする必要がない。これと同じトランスペアレントなマッピングプロセスを、データ転送を実行するコントローラノードについても達成することが可能であることが、当業者には認識されよう。その理由は、I/Oサービスレイヤ（512,図５A）のこの部分もまた、ネットワークサービスレイヤ514から階層的に分離されているからである。また、上述したような各コントローラノードには、テーブルも保持することができ、全ての処理ノードにより維持されるテーブルのエントリは、宛先ノードエントリとしてプロセッサノード及びコントローラノードの双方を含むものとなる。更に、同じタイプのシングルパラメータAPIをデータトランザクションを要求するコードに挿入し、これにより、送信元ノードのネットワークサービスレイヤを呼び出して、該ネットワークサービスレイヤに、宛先コントローラノードのマッピングを変更することが安全であることを通知することが可能である。
【００２６】
一実施形態では、最初に、拡張されたファブリックのそれぞれへプロセッサノードの総数を均一に分散するように、マッピングを（起動時に）セットアップすることができる。拡張されたファブリックのそれぞれは、少なくとも、ノード間でメッセージをより均一に分散させる機会を提供する。例えば、n＝m＝2の場合、これは、最初に奇数番号のノードIDを有する全てのプロセッサノードをX1及びY1に割り当て、及び偶数番号のノードIDを有する全てのプロセッサノードをX2及びY2に割り当てることにより、達成することができる。図７に示すようにn＝m＝4である場合には、最初に４つのノード毎にX1,Y1〜X4,Y4を割り当てることができる。マッピングを最初に確立する方法は本発明にとって重要ではないことが当業者には理解されよう。
【００２７】
（おそらくはロードバランシングアルゴリズムに従って）ノード間のトラフィックをバランスさせるのを助けるために、マッピングを定期的に変更するのが有利である可能性がある。どの所与のノードに対しても、このマッピングの変更は、変更を行うことが安全である時に実行しなければならない。すなわち、メッセージがその宛先ノードへ転送中である間には現在のマッピング割り当て変更することはできない。その理由は、パケットが順序通りに受信されない危険性があるからである。マッピングを変更する安全な機会（例えば、メッセージの再送を要求する「再試行」トランザクションが要求された時）の幾つかの考え得る指標が存在する。
【００２８】
マッピングを変更する安全な機会を検出する最も簡単な方法は、メッセージシステムに、このような機会をネットワークサービスへ通知させることである。メッセージシステムは、それ自体の宛先ノードIDの割り当てを元の２つのファブリックX0,Y0間で変更する安全な機会を検出するよう設計されたコードパスを既に有している。このため、メッセージシステムがそれ自体の割り当てを変更するという事実のみにより、エントリの変更すら伴うことなく、現在のマッピング割り当てに従って、その現在の（例えば何らかのXiから何らかのYjへの）割り当て以外の物理ファブリックへ宛先ノードが再マッピングされる。しかし、Xファブリック内ならびにYファブリック内で現在の割り当てを変更することもまた有利であり、これにより、メッセージシステムが割り当てを変更していない場合であってもマッピングを全ての可能性にわたってローテートさせることができる。一実施形態では、メッセージシステムレイヤの安全な機会を検出するコードパス内に配置されたアプリケーションプログラムインタフェイス（API）を使用してネットワークサービスレイヤを呼び出し、これにより、マッピングの変更が安全である宛先ノードのノードIDをネットワークサービスに通知することができる。該通知が行われた時点で、ネットワークサービスレイヤは、その送信元処理ノードのテーブルエントリを、新たな割り当てXi及び／又はYjで更新することができる。
【００２９】
図７は、更に、ID＝0を有する宛先ノードについてテーブル700内に記憶されている時刻t＝t1に更新されたマッピングを有する送信元ノードSとして動作する処理ノードの１つに関するこのプロセスを示している。この新たな現在のマッピングは、X0からX2、及びY0からY3になっている。時刻t＝t2において、宛先ノード＃4についての新たな現在のマッピングは、X0からX1、及びY0からY4になる。元の（仮想）ファブリックの各々についてのマッピングは互いに独立したものであり、このため、更新中に一方が更新され他方が同じままとなる場合があり得る、ということが当業者には明らかであろう。t1及びt2で更新されたテーブルロケーションを図７に網掛けで示す。
【００３０】
特定のプロセッサノードについてのi＝j＝2のマッピングは、次の態様、すなわち、（X1→Y1→X2→Y2→X1…）又は（X1→Y2→X2→Y1→X1…）の一方で完全に循環できることが当業者には理解されよう。また、各処理ノードがそれ自体のマッピングをローカルに保持するため、送信元ノードとしての各処理ノードと宛先ノードとしての他のノードとの間のマッピングを各処理ノード毎に変化させることが可能であることも当業者には明らかであろう。別の言い方をすれば、宛先ノードとしてのノード＃3と通信する送信元ノードとしてのノード＃1により確立されたマッピングは、宛先ノードとしてのノード＃3と通信する送信元ノードとしてのノード＃2により確立されたマッピングと異なる可能性がある。
【００３１】
SANに関して上述したものと同じ態様で、拡張された個数のIPCバスでトランザクションを開始するのに使用されるソフトウェアサービスからメッセージシステムプロシージャを隔離させた状態に維持することにより、この技法を図１のデュアルバスアーキテクチャに適用できることが、当業者には理解されよう。図８は、図１のアーキテクチャに適用される本発明の一実施形態を示している。同図から分かるように、IPCバスの個数は、元の２つのIPCバスX110,Y112からバスX1〜Xn,Yj〜Ymへと拡張されている。ネットインタフェイス720,722は、該拡張された個数のバスを収容するために、図１のネットインタフェイス120,122よりも相応に拡大されている。
【００３２】
図９は、本発明の一実施形態のプロシージャフローを示している。これは、特定のプログラムのフローチャートではなく、上述したような２つ以上のソフトウェアプログラムレイヤにまたがることができる本発明の機能を特定するものであることが指摘されるべきである。ブロック910において、システムの幾つかの処理ノードがシステムプロセッサにより識別されてノードIDが割り当てられ、次いで、その情報を処理ノードの各々に提供することができる。処理はブロック912に進み、拡張された個数のファブリック又はバスを介して宛先ノードへ送信元として通信することになるシステムの各処理ノード毎に、宛先ノードへの初期マッピングが確立される。このプロセスは、ブロック910で生成された情報、並びにファブリックを介したメッセージの初期分散を提供するよう設計された何らかのアルゴリズムに基づくものとすることができるマッピング情報を、マッピングテーブルにロードするステップを含む。処理はブロック914に進み、送信元ノードとして動作する各処理ノード毎のネットワークサービスレイヤが、そのノードのI/Oサービスレイヤによる要求時に、送信元ノードにより維持されている現在のマッピングに従って、拡張されたファブリック又はバスの１つを介して、トランザクションを開始する。このプロセスの一部として、I/Oサービスレイヤ（例えばメッセージシステム）は、２つの元の又は仮想ファブリック／バスの何れを使用したいのかを指定することによって、メッセージパケットがXi又はYjファブリック又はバスの何れを介して送信されるのかを、その要求において指定することができる。ブロック916で、送信元ノードのI/Oサービスレイヤは、特定の宛先ノードのマッピングを変更することが安全であると判断すると、ブロック918でAPIを呼び出し、送信元ノードのネットワークサービスレイヤに、どの宛先ノードのマッピングの変更が安全であるかを通知する。APIが特定の宛先ノードについて呼び出されると、ブロック920で特定の宛先ノードのマッピングを変更することができる。処理はブロック914に戻って、送信元ノードのI/Oサービスによるトランザクション要求が、新たな現在のマッピングにより決定されたバス又はファブリックを介して開始される。
【００３３】
高度に分散されたフォールトトレラントコンピュータシステムのための、プロセッサ間メッセージング及びデータI/Oトランザクションを要求する既存のソフトウェアは、長年の間、従来のデュアルファブリック／バスアーキテクチャに深くつぎ込まれてきた。この既存のソフトウェアは、実際のファブリックの個数が任意の有利な個数の追加されたファブリック／バスへと拡張されている場合であっても、その２つのファブリック／バス環境内で依然として動作していると思うようにだますことができる。メッセージング及びI/Oサービスソフトウェアは、バス／ファブリックを介してそれらトランザクションを物理的に開始する役割を有するソフトウェアサービスから隔離することができるので、それら下位レベルのサービスは、上位レベルのメッセージング及びI/Oサービスに対する知識及び損害を伴うことなく、２つのファブリック／バスから、使用される実際の個数のバスへの、仮想→物理マッピングを実行することができる。このように、フォールトトレランスの改善や帯域幅を高くすること（これはメッセージ及びI/Oの待ち時間を短くする）といったバス／ファブリックの個数の拡張による利点は、多くの時間と費用を要する既存コードの再開発に頼ることなく達成することができる。
【図面の簡単な説明】
【００３４】
【図１】コンピュータシステムのプロセッサノード間のメッセージ転送に従来のデュアルIPCバスを使用するコンピュータシステムを示すブロック図である。
【図２】SANのデュアルファブリック上でメッセージ及びデータトランザクションを組み合わせる既知のコンピュータシステムを示すブロック図である。
【図３】図２のコンピュータシステムのプロセッサノードの一実施形態のブロック図である。
【図４】図２のコンピュータシステムのSANルータの一実施形態のブロック図である。
【図５Ａ】図２のコンピュータシステムのプロセッサノードのそれぞれで実行されるソフトウェアサービスレイヤの階層関係を示すブロック図である。
【図５Ｂ】図２のコンピュータシステムの処理ノードの２つで実行されるクライアントプロセス間のトランザクション要求を操作する際の様々なソフトウェアサービスの階層関係を示すブロック図である。
【図６】ファブリックの個数が本発明に従ってn個のファブリックXi及びm個のファブリックYjに拡張された図２のコンピュータシステムの一実施形態を示すブロック図である。
【図７】本発明による仮想から物理へのファブリックマッピングテーブルの一実施形態のブロック図表現である。
【図８】バスの個数が本発明に従ってn個のバスXi及びm個のバスYjに拡張された図１のコンピュータシステムの一実施形態を示すブロック図である。
【図９】本発明のマッピング及び変換プロセスの一実施形態を示すプロシージャフローチャートである。
【図１】
2006053896.tif 000003
【図２】
2006053896.tif 000004
【図３】
2006053896.tif 000005
【図４】
2006053896.tif 000006
【図５Ａ】
2006053896.tif 000007
【図５Ｂ】
2006053896.tif 000008
【図６】
2006053896.tif 000009
【図７】
2006053896.tif 000010
【図８】
2006053896.tif 000011
【図９】
2006053896.tif 000012
【外国語明細書】
2006053896000001.pdf