(57)【特許請求の範囲】
【請求項１】
クラスタ化されたコンピュータ・システムにおいて、前記クラスタを構成する処理ノードのそれぞれが備えるハイパーバイザが、通信チャネルのフェイルオーバを実行する方法であって、
前記ノードのファブリック・インターフェース・デバイスの第１のウィンドウを用いて通信チャネルを介したクラスタ・ファブリックへのクライアントのアクセスを確立するステップであって、前記第１のウィンドウが、前記クライアントに関する前記通信チャネルの状態を定義し、前記ウィンドウが、前記クライアントに割り当てられたメモリ・リソースと、前記ファブリック・インターフェース・デバイスの前記第１のウィンドウに割り当てられた第１のハードウェア・リソースとの間の複数のマッピングを含む、前記確立するステップと、
前記通信チャネルにおける障害を検出することに応じて、前記クライアントに割り当てられた前記メモリ・リソースを前記ファブリック・インターフェース・デバイスの第２のウィンドウに割り当てられた第２のハードウェア・リソースにマッピングするように前記複数のマッピングを更新することによって、前記第１のウィンドウによって定義された前記状態を前記第２のウィンドウに移すステップと、
前記第２のウィンドウを用いて前記通信チャネルを介した前記クラスタ・ファブリックへのクライアントのアクセスを復元するステップとを含む、方法。
【請求項２】
前記第１のウィンドウが、障害が起こったウィンドウを含み、利用可能なウィンドウのプールから、前記第２のウィンドウを選択する 、請求項１に記載の方法。
【請求項３】
前記ファブリック・インターフェース・デバイスが、ホスト・ファブリック・インターフェース（ＨＦＩ）デバイスを含む、請求項１に記載の方法。
【請求項４】
前記メモリ・リソースが、少なくとも送信キューおよび受信キューを含む、請求項１に記載の方法。
【請求項５】
前記状態を移すステップの前に、ページ・テーブルで前記第１のウィンドウに関連するページ・フォールトをアサートすることによって前記第１のウィンドウへのクライアントのアクセスを中断するステップと、
前記状態を移すステップの後に、前記ページ・テーブルが第２のウィンドウのレジスタを指すように更新することにより前記ページ・フォールトが解決され、前記第２のウィンドウへのクライアントのアクセスを可能にするステップとをさらに含む、請求項１に記載の方法。
【請求項６】
前記状態を移すステップの前に、前記第１のウィンドウに関連する少なくとも１つのハードウェア・キャッシュをフラッシュするステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記障害が検出された第１のウィンドウで保留中の割り込みについて、割り込みテーブルを更新して前記第１のウィンドウに関連する割り込みを更新するステップと、
前記第２のウィンドウで割り込みを施行するステップとをさらに含む、請求項１に記載の方法。
【請求項８】
クライアントのアクセスを復元するステップが、前記第２のウィンドウにクライアントのアクセスを再マッピングするステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記ファブリック・インターフェース・デバイスが、クライアントの保留中の作業が再開できるように、前記第２のウィンドウにクライアントのアクセスを再マッピングするステップの前に前記第２のウィンドウを有効化するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記第２のウィンドウにクライアントのアクセスを再マッピングするステップの後に前記第２のウィンドウへのクライアントのアクセスを有効化するステップをさらに含む、請求項８に記載の方法。
【請求項１１】
クライアントのアクセスを有効化するステップが、前記クライアントに関する保留中の作業が再開することを可能にし、前記方法が、前記クライアントに関する保留中の作業が再開した後、前記クライアントに前記フェイルオーバを通知するステップをさらに含む、請求項１０に記載の方法。
【請求項１２】
前記クライアントが前記フェイルオーバを通知された後、前記クライアントにおいて、少なくとも１つのピア・クライアントに前記第２のウィンドウを通知するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
装置であって、請求項１〜１２の何れか１項に記載の方法の各ステップをハードウェアによる手段として構成した、装置。
【請求項１４】
コンピュータ・プログラムであって、請求項１〜１２の何れか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項１５】
請求項１４に記載の前記コンピュータ・プログラムを、コンピュータ可読ストレージ媒体に記録した、ストレージ媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理システムに関し、特に、分散データ処理システムにおいて通信障害を処理することに関する。
【背景技術】
【０００２】
複数の個々の処理ユニットの処理能力を利用することによってより高いコンピュータ・システムの性能が実現され得ることは、コンピュータ技術の分野で広く認められている。マルチプロセッサ（ＭＰ）コンピュータ・システムは、いくつかの異なるトポロジーを実装する可能性があり、それらのトポロジーのうちのさまざまなトポロジーが、それぞれの応用の性能要件およびソフトウェア環境に応じて特定の応用により適する可能性がある。１つのよくあるＭＰコンピュータ・アーキテクチャは、それぞれが複数レベルのキャッシュの階層によってサポートされる複数の処理ユニットが、共有されたシステム相互接続（interconnect）に結合されることが多いシステム・メモリおよび入力／出力（Ｉ／Ｏ）サブシステムなどのリソースの共通プールを共有する対称型マルチプロセッサ（ＳＭＰ）・アーキテクチャである。
【０００３】
ＳＭＰコンピュータ・システムは、比較的単純なプロセッサ間通信およびデータ共有方法の使用を可能にするが、スケーラビリティが限られている。例えば、多くのＳＭＰアーキテクチャは、システムの規模が大きくなるにつれて、特にシステム・メモリである程度の帯域幅の制限を受ける。
【０００４】
不均等メモリ・アクセス（ＮＵＭＡ：non-uniform memory access）として知られる代替的なＭＰコンピュータ・システム・トポロジーも、ＳＭＰコンピュータ・システムのスケーラビリティおよび拡張性に対する制限に対処するために使用されてきた。通常のＮＵＭＡコンピュータ・システムは、それぞれが小規模なＳＭＰシステムとして実装され得る複数のノードが接続されるスイッチまたはその他のグローバルな相互接続を含む。ノードの処理ユニットは、処理ユニットのそれぞれのノードのローカルのシステム・メモリに含まれるデータに関しては比較的小さいアクセス・レイテンシを享受するが、リモート・ノードのシステム・メモリに含まれるデータに関してはずっと大きなアクセス・レイテンシを被る。したがって、システム・メモリに対するアクセス・レイテンシは、不均等である。各ノードが独自のリソースを有するので、ＮＵＭＡシステムは、ＳＭＰシステムよりも潜在的に高いスケーラビリティを有する。
【０００５】
ＳＭＰデータ処理システム・アーキテクチャが使用されるのか、ＮＵＭＡデータ処理システム・アーキテクチャが使用されるのか、またはその他のＭＰデータ処理システム・アーキテクチャが使用されるのかに関わりなく、各処理ユニットが、実アドレスを利用して関心のある記憶位置を特定することによって、（物理システム・メモリであるか、キャッシュ・メモリであるか、または別のシステム・リソースであるかに関係なく）メモリ・マップされた記憶位置に存在するデータにアクセスすることは、一般的である。実アドレスの重要な特徴は、それぞれのメモリ・マップされた物理的記憶位置に関して一意の実アドレスが存在することである。
【０００６】
メモリ・マップされた物理的記憶位置と実アドレスとの間の１対１の対応が、必然的に、ソフトウェアによって参照され得る記憶位置の数を制限するので、ほとんどの商用のＭＰデータ処理システムの処理ユニットは、アドレス指定可能な位置の数を大きくするためにメモリ仮想化を使用する。実際、仮想メモリ・アドレス空間のサイズは、実アドレス空間のサイズよりも数桁大きい可能性がある。したがって、通常のシステムにおいて、処理ユニットは、内部的に、仮想（または実効）アドレスによってメモリ位置を参照し、次いで、（多くの場合、１つまたは複数の中間的な論理アドレス空間を介して）仮想−実アドレス変換を実行して、実アドレスによって特定される物理メモリ位置にアクセスする。
【０００７】
上記のＭＰシステムが利用できことを前提として、データ処理テクノロジーの１つのさらなる発展は、並列コンピューティングの導入であった。並列コンピューティングによれば、複数のプロセッサ・ノードが、システム相互接続またはファブリックを介して互いに相互接続される。そして、これらの複数のプロセッサ・ノードは、特定のタスクを実行するために利用され、それらの特定のタスクは、個々の／独立したタスクであるか、または複数のタスクで構成される大きなジョブの一部である可能性がある。
【０００８】
そのようなシステムにおいては、複数のプロセッサ・ノード間の通信を調整することが、ワークロードの高速で効率的な処理を保証するために最も重要である。異なる計算ノードの調整プロセス（例えば、ユーザのジョブまたはＯＳのインスタンス）間の通信の喪失は、ジョブの進行の遅延／喪失、時間のかかるリカバリ、またはシステムの不安定化、あるいはこれらの組合せにつながることが分かっており、実質的に、計算リソース、電力を浪費し、最終結果を遅らせる。
【０００９】
さまざまなＭＰシステム・テクノロジーが、異なる種類の通信チャネルを利用して、調整プロセス間の通信をサポートする。例えば、ハイ・パフォーマンス・コンピューティング（ＨＰＣ）クラスタとして実装されるＭＰシステムにおいて、通信チャネルは、１つまたは複数のホスト・ファブリック・インターフェース（ＨＦＩ：Host Fabric Interface）アダプタで利用可能な「ウィンドウ」として実装され得る。その他の種類のＨＰＣクラスタにおいて、通信チャネルは、ホスト・チャネル・アダプタ（ＨＣＡ）のキュー・ペア（Queue Pair）として実装され得る。
【００１０】
潜在的な通信の喪失に対処するために、一部のＭＰシステムは、異なる計算ノードに計算ジョブの複数の同一のコピーをディスパッチする。しかし、そのようにすることは、ＣＰＵ／メモリ・リソースおよび帯域幅の使用量を倍にし、複数のソースから戻ってくる結果を合併／破棄することを必要とする。
【００１１】
その他のＭＰシステムは、アクティブ／アクティブ・ラウンド・ロビン構成で複数のアクティブな通信チャネルを利用する。しかし、そのようにすることは、エンド・クライアント（計算ジョブ）毎に割り振られる追加のチャネル・リソース、複数のチャネルを管理するための追加のリソース、および通信ストリームの合併を管理するためのユーザのジョブまたはＯＳのライブラリの追加のオーバーヘッドを必要とする。さらに、１つのチャネルの障害は長い間隔のソフトウェア・タイマーによってしか検出され得ないことが多いので、故障したハードウェアのキューに入れられたあらゆる操作が失われることが多い。
【００１２】
さらにその他のＭＰシステムにおいては、複数の通信チャネルが、アクティブ／パッシブ構成で利用され得る。しかし、そのような解決策は、エンド・クライアント（計算ジョブ）毎に割り当てられる追加のチャネル・リソースを必要とし、それらの追加のチャネル・リソースのほとんどは、使用されない。概して、追加のリソースは、複数のチャネルを管理するためにやはり必要とされ、概して、故障したハードウェアのキューに入れられたあらゆる操作は、失われる。加えて、概して、１つのチャネルの障害は、長い間隔のソフトウェア・タイマーによってしか検出され得ない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】米国特許第８，２７５，９４７号
【発明の概要】
【発明が解決しようとする課題】
【００１４】
したがって、ＨＰＣクラスタまたはその他のＭＰシステムにおいて通信チャネルの障害を処理する改善された方法、特に、フェイルオーバのための時間を削減し、破棄されるパケットの数を削減し、追加の専用リソースの必要性を削減し、または通常の手法よりも柔軟な構成を可能にし、あるいはこれらの組合せを行う、通信チャネルの障害を処理する方法に対する大きなニーズが、当技術分野に存在する。
【課題を解決するための手段】
【００１５】
本発明は、ハードウェア・ファブリック・インターフェース・デバイスに存在するウィンドウの間で通信チャネルの状態を移すクラスタ・ファブリックにおける通信チャネルのフェイルオーバを提供することによって、従来技術に関連するこれらのおよびその他の問題に対処する。フェイルオーバは、通信チャネルを利用するクライアントのフェイルオーバへの関与を最小化するかまたはなくすように、ホスト・メモリのメモリ・リソースとファブリック・インターフェース・デバイスのハードウェア・リソースとの間の複数のマッピングを更新することによって、概して、メモリ・リソースを修正することなく望ましく実施される。
【００１６】
したがって、本発明の一態様に準拠して、クラスタ化されたコンピュータ・システムにおける通信チャネルのフェイルオーバが、ファブリック・インターフェース・デバイスの第１のウィンドウを用いて通信チャネルを介したクラスタ・ファブリックへのクライアントのアクセスを確立することであって、第１のウィンドウが、クライアントに関する通信チャネルの状態を定義し、ウィンドウが、クライアントに割り当てられたメモリ・リソースと、ファブリック・インターフェース・デバイスの第１のウィンドウに割り当てられた第１のハードウェア・リソースとの間の複数のマッピングを含む、確立することと、通信チャネルにおける障害を検出することに応じて、クライアントに割り当てられたメモリ・リソースをファブリック・インターフェース・デバイスの第２のウィンドウに割り当てられた第２のハードウェア・リソースにマッピングするように複数のマッピングを更新することによって、第１のウィンドウによって定義された状態を第２のウィンドウに移すことと、第２のウィンドウを用いて通信チャネルを介したクラスタ・ファブリックへのクライアントのアクセスを復元することとによって実行される。
【００１７】
本発明を特徴付けるこれらのおよびその他の利点および特徴は、本明細書に添付され、本明細書のさらなる部分を形成する請求項に記載されている。しかし、本発明、およびそれを使用することによって達成される利点および目的をより深く理解するために、図面と、本発明の例示的な実施形態が説明される付随する記載とが参照されるべきである。
【図面の簡単な説明】
【００１８】
【図１】本発明に準拠した方法で通信チャネルのフェイルオーバを可能にするための、各ノードにホスト・ファブリック・インターフェース（ＨＦＩ）が設けられた例示的なマルチノード・データ処理システムを示す図である。
【図２】図１のデータ処理システム内のパーティションおよびノードへの単一のジョブのタスクの割り当てを示す図である。
【図３】図１のデータ処理システムにおいてＧＳＭの操作の処理のために利用される例示的な送信（開始）ノードおよび目標ノードの構成要素を示すブロック図である。
【図４】図１のデータ処理システムの例示的なＨＦＩウィンドウと、実（すなわち、物理）メモリ内の特定のメモリ位置へのウィンドウ・エントリの関連付けとの詳細な図である。
【図５】本発明に準拠した方法での通信チャネルのフェイルオーバの前の例示的なデータ処理システムを示すブロック図である。
【図６】図５のデータ処理システムで通信チャネルのフェイルオーバを実施するために使用される例示的な一連の操作を示す高レベルの流れ図である。
【図７】図５のデータ処理システムで通信チャネルのフェイルオーバを実施するために使用される例示的な一連の操作をより詳細に示す流れ図である。
【図８】図５のデータ処理システムで通信チャネルのフェイルオーバを実施するために使用される例示的な一連の操作をより詳細に示す流れ図である。
【図９】本発明に準拠した方法での通信チャネルのフェイルオーバの後の図５のデータ処理システムを示すブロック図である。
【発明を実施するための形態】
【００１９】
ここで、同様の番号がいくつかの図を通じて同様の部分を示す図面に目を向けると、図１が、本明細書の１つの例示的な実施形態による、本発明の機能的特徴の多くが実装され得る、それぞれのホスト・ファブリック・インターフェースを介して接続された２つのノードで構成される例示的なデータ処理システム１００の第１の図を示す高レベルのブロック図を示す。示されるように、データ処理システム１００は、データおよび命令を処理するための複数の処理ノード１０２Ａ、１０２Ｂ（集合的に１０２）を含む。処理ノード１０２は、１つまたは複数の相互接続またはネットワーク・プロトコル、あるいはこれらの組合せによって処理ノード１０２の間のデータ通信をサポートする相互接続ファブリック１１０にホスト・ファブリック・インターフェース（ＨＦＩ）１２０を介して結合される。相互接続ファブリック１１０は、例えば、１つまたは複数のバス、スイッチ、またはネットワーク、あるいはこれらの組合せを利用して実装され得る。複数のメカニズムのうちのいずれか１つが、相互接続１１０を介して通信するためにＨＦＩ１２０によって利用される可能性がある。例えば、限定することなく、ＨＦＩ１２０は、独自仕様のプロトコル、またはＩｎｆｉｎｉｂａｎｄ、イーサネット（Ｒ）、またはＩＰ（インターネット・プロトコル）などの業界標準のプロトコルによって通信し得る。
【００２０】
本明細書において利用されるとき、用語「処理ノード」（または単にノード）は、一貫性のある（coherent）オペレーティング・システム（ＯＳ）イメージのドメイン（domain）を形成する計算リソースの組として定義される。明確にするために、構成に応じて、単一の物理的システムが複数のノードを含む可能性があることを理解されたい。所与のシステムで展開される処理ノード１０２の数は、実装に依存し、例えば、数個のノードから数千個のノードまで幅広く変わり得る。
【００２１】
それぞれの処理ノード１０２は、例えば、命令およびデータを処理するための１つまたは複数の処理ユニット１０４（例えば、処理ユニット１０４Ａ、１０４Ｂ）を含む単一の集積回路チップ（例えば、システム・オン・チップ（ＳＯＣ））、マルチチップ・モジュール（ＭＣＭ）、または回路基板として実装され得る。さらに、各処理ユニット１０４は、実行の１つまたは複数のハードウェア・スレッドを同時に実行し得る。
【００２２】
示されるように、各処理ユニット１０４は、１つまたは複数のレベルのインライン・キャッシュ（in-line cache）またはルックアサイド・キャッシュ（lookasidecache）を含むキャッシュ・メモリ１１２によってサポートされる。当技術分野で知られているように、キャッシュ・メモリ１１２は、同じ処理ノード１０２Ａまたは（１つもしくは複数の）リモート処理ノード１０２Ｂ、あるいはこれらの組合せ内の（１つまたは複数の）ソースから受信された命令およびデータへの小さなレイテンシのアクセスを処理ユニット１０４に提供する。各処理ノード１０２内の処理ユニット１０４は、例えば、１つまたは複数のバスまたはスイッチ、あるいはこれらの組合せによって実装され得るローカル相互接続１１４に結合される。ローカル相互接続１１４は、処理ノード１０２Ａ、１０２Ｂの間のデータ通信をサポートするためのＨＦＩ１２０にさらに結合される。
【００２３】
図１にさらに示されるように、処理ノード１０２は、概して、少なくとも１つのメモリ・コントローラ１０６を含み、メモリ・コントローラ１０６は、それぞれの物理システム・メモリ１０８へのインターフェースを提供するためにローカル相互接続１１４に結合され得る。本発明の代替的な実施形態において、１つまたは複数のメモリ・コントローラ１０６は、ローカル相互接続１１４ではなく相互接続ファブリック１１０に、または直接処理ユニット１０４に結合される可能性がある。
【００２４】
メモリ・コントローラに加えて、各処理ユニット１０４は、実効アドレスを実（または物理）アドレスに変換するためのメモリ管理ユニット（ＭＭＵ）１０５も含む。これらのＭＭＵ１０５は、データ処理システム１００の処理ノード（例えば、ノード１０２Ａ）で実行されるタスクのためのＥＡ−ＲＡ変換を実行する。しかし、ローカル相互接続１１４に結合される別個のＭＭＵ１２１も、データ処理システム１００のリモート処理ノード（例えば、ノード１０２Ｂ）で動作するタスクから受信された操作に関するＥＡ−ＲＡ変換を実行するために使用され得る。プロセッサ構成の１つの実装において、ＭＭＵ１２１は、ＨＦＩ、またはＨＦＩを利用してグローバル共有メモリ（ＧＳＭ：global shared memory）の操作を完了するタスク、あるいはその両方によって必要とされるＥＡ−ＲＡアドレス変換をサポートするためにＨＦＩ１２０と統合される可能性がある。
【００２５】
以下で説明されるＨＦＩ１２０Ａおよびその機能構成要素は、処理ユニット１０４Ａ／１０４Ｂで実行される（１つまたは複数の）タスクが、共有されたグローバル・アドレス空間（ＧＡＳ）からのＥＡおよびＧＳＭを用いて並列ジョブのその他のタスクを実行しているその他のノードの物理メモリ１０８Ｂにアクセスする操作を生成することを可能にする。同様に、ＨＦＩ１２０Ｂは、特定の基準が満たされるとき、物理メモリ１０８Ｂにアクセスするための開始ノード１０２Ａの（１つまたは複数の）タスクによるアクセスを可能にする。
【００２６】
当業者は、図１のデータ処理システム１００が、相互接続ブリッジ、不揮発性ストレージ、ネットワークまたは付属のデバイスに接続するためのポートなどの、本明細書において示されていない多くの追加の構成要素を含み得ることを理解するであろう。そのような追加の構成要素は、本発明を理解するために必要ではないので、図１に示されておらず、本明細書においてさらに検討されない。
【００２７】
ＨＦＩを用いる例示的なデータ処理システム１００のノードの上述の物理的な表現は、ＧＳＭを用いるより大きなシステム内の複数のノードに並列ジョブに関連するタスクを分散することをサポートする。図２は、１つの例示的な実施形態による、データ処理システム１００のための例示的なソフトウェア環境内の並列ジョブの複数のタスクの処理の高レベルの図を示す。例示的な実施形態において、データ処理システム１００は、相互接続ファブリック１１０によって結合された（図１の処理ノード１０２Ａおよび１０２Ｂをそれぞれ提供する）少なくとも２つの物理的システム２００Ａおよび２００Ｂを含む。示される実施形態において、それぞれの物理的システム２００は、少なくとも２つの並列のノードを含む。つまり、物理的システム２００Ａは、オペレーティング・システム２０４Ａ１に対応する第１のノードと、オペレーティング・システム２０４Ａ２に対応する第２のノードとを含む。同様に、物理的システム２００Ｂは、オペレーティング・システム２０４Ｂ１に対応する第１のノードと、オペレーティング・システム２０４Ｂ２に対応する第２のノードとを含む。それぞれの物理的システム２００内で同時に実行されるオペレーティング・システム２０４は、同種であるかまたは異種である可能性がある。特に、簡単にするために、それぞれの物理的システムの１つのノードだけが、本明細書においてＧＳＭおよびＨＦＩ機能の説明で利用されるが、本発明の特徴は、（１つまたは複数の）その他の物理的システムのその他のノードの物理メモリにアクセスする、単一の物理的システムの複数のノードのいずれか１つで実行されるタスクに完全に適用可能である。
【００２８】
それぞれの物理的システム２００は、（仮想マシン・モニタ（ＶＭＭ）とも呼ばれる）ハイパーバイザ２０２のインスタンスをさらに含み得る。ハイパーバイザ２０２は、物理的システム２００のリソースの完全仮想化または準仮想化を管理し、オペレーティング・システムのスーパーバイザとして働くプログラムである。したがって、ハイパーバイザ２０２は、ノードの生成および破棄と、ノード間での物理的システム２００のリソースの割り当てとを管理する。
【００２９】
データ処理システム１００における並列ジョブの実行は、並列ジョブのタスクを実行する複数のノードが、本明細書においてはグローバル・アドレス空間（ＧＡＳ）と呼ばれる共有された実効アドレス空間にアクセスすることを可能にするグローバル共有メモリ（ＧＳＭ）をやはり利用し得る。したがって、データ処理システム１００は、複数の異なる種類のタスクを実行することができる。第１に、データ処理システム１００は、オペレーティング・システム２０４の下で独立して実行される通常の（個々の）タスクＣ、Ｆ、Ｇ、Ｋ、Ｌ、Ｐ、Ｑ、Ｔ、Ｖ、およびＷを実行することができる。第２に、データ処理システム１００は、単一のノードにとどめられるタスクを有するジョブ２などの並列ジョブを実行することができる。つまり、タスクＤおよびＥは、物理的システム２００Ａのオペレーティング・システム２０４Ａ１に対応するノード内で実行され、一貫してメモリを共有することができる。第３に、データ処理システム１００は、複数のノード、および複数の物理的システム２００にさえもまたがるジョブ１などの並列ジョブを実行することができる。例えば、示された動作シナリオでは、ジョブ１のタスクＡおよびＢは、オペレーティング・システム２０４Ａ１で実行され、ジョブ１のタスクＨおよびＪは、オペレーティング・システム２０４Ａ２で実行され、ジョブ１のタスクＭおよびＮは、オペレーティング・システム２０４Ｂ１で実行され、ジョブ１のタスクＲおよびＳは、オペレーティング・システム２０４Ｂ２で実行される。示されるように、複数の異なるジョブ（例えば、ジョブ１およびジョブ２）のタスクは、単一のノード内で同時に実行されることを許される。
【００３０】
標準的なタスク間操作によれば、同じノードで実行されるタスク、つまり、同じ物理デバイスに収容された（homed）タスクは、ＨＦＩを利用し、標準的なページ・テーブルを超えてＥＡ−ＲＡマッピングを解決することを必要としない。したがって、ＨＦＩまたはＭＭＵ構成要素、あるいはその両方の構成要素は、同じ物理的ノードでタスクをまたいで操作をやりとりするときには利用されない。しかし、タスクが異なる物理的ノードで実行されている場合、ＧＳＭの操作を発行しまたは受け取り、あるいはその両方を行うとき、特定のノードに収容されたタスクに関する正しいＥＡ−ＲＡ変換を可能にするために、ＭＭＵおよびＨＦＩの使用が必要とされる可能性がある。
【００３１】
任意で、追加のアプリケーションが、ジョブの生成および実行を容易にするためにオペレーティング・システム２０４の下で実行される可能性がある。例えば、図２は、オペレーティング・システム２０４Ａ１の下で実行される負荷レベラ（Load Leveler）などのジョブ管理プログラム２０６と、オペレーティング・システム２０４Ａ２の下で実行される並列動作環境（ＰＯＥ：Parallel Operating Environment）などのランタイム環境２０８とを示す。
【００３２】
ここで図３を参照すると、ＧＳＭ環境内の物理的ノードをまたがるＧＳＭの操作の生成、送信、受信、および処理のために必要とされるハードウェア（およびソフトウェア）構造を有する図１および２のデータ処理システム１００の別のより詳細な図が、示されている。第１のコンピュータ・ノード１０２Ａ（開始または送信ノード）および第２のコンピュータ・ノード１０２Ｂ（目標または受信ノード）は、それぞれ、ＨＦＩ１２０Ａ、１２０Ｂを含む。ＨＦＩ１２０は、（プロセッサ）チップ内の一貫性のあるファブリックに載ったハードウェア構造である。それぞれのＨＦＩ１２０は、並列ジョブの特定の実行されるタスクに割り当てられる１つまたは複数のウィンドウ４４５（および４４６）（図４参照）を提供する。
【００３３】
並列ジョブの実行されるタスクが初期化システム・コールを発行するとき、そのノードのオペレーティング・システム（ＯＳ）は、そのタスクのためのＨＦＩの専用ウィンドウを確立しようとする。操作が成功する場合、割り当てられたＨＦＩウィンドウの一部が、最初に、タスクのアドレス空間にマッピングする。メモリ・マップト入出力（ＭＭＩＯ：memory mapped input output）空間は、コマンド領域およびＦＩＦＯポインタを含む。タスクの実効アドレス空間の適切な部分が予約された（つまり、物理メモリにマッピングされた）後、オペレーティング・システムは、内向きの（つまり、相互接続からの）ＧＳＭコマンド内の実効アドレスが変換され得るように、そのタスクのためのページ・テーブルを指すようにウィンドウを設定する。
【００３４】
処理システム１００において、第１のノード１０２Ａは、送信／開始ノードを表し、ＭＭＩＯ４１１を介してアクセス可能であるメモリ４０５内の送信ＦＩＦＯ４０７によって示される。第２のノード１０２Ｂは、受信または目標ノードを表し、その第２のノード１０２Ｂのメモリ４０６内の受信ＦＩＦＯ４０８によって示される。たとえ非対称的な図が示されているとしても、両方の処理ノード１０２Ａと１０２Ｂとは、同様に構成され、送信ＦＩＦＯ４０７と受信ＦＩＦＯ４０８との両方を有し、各ノードは、送信機能と受信機能との両方を実行することができることが、理解される。処理システム１００内で、ＨＦＩ１２０は、相互接続へのアクセスを管理する主要なハードウェア要素である。概して、相互接続は、リンク４５５Ａ、４５５、ルーティング・スイッチ４１０、ならびに一連のスイッチ要素４５０Ａ、４５０Ｂ、および４６０によって表される。したがって、ＨＦＩ１２０Ａは、送信ノード（１２０Ａ）で実行されるタスクが、（送信先または目標がジョブＩＤ、ノードＩＤ、およびウィンドウＩＤによって特定されるようにして）受信／目標ノード１０２ＢにＧＳＭの操作を送信することを可能にする。
【００３５】
図３にさらに示されるように、処理ノード１０２は、ＨＦＩ１２０とそれぞれの物理システム・メモリ（ＤＩＭＭ）４３０との間のインターフェースを提供するための、ローカル・ファブリック４１４に結合される少なくとも１つのメモリ・コントローラ１０６を含む。処理ノード１０２は、ファブリック・バス４１４に結合されるＭＭＵ１２１も含む。ＭＭＵ１２１は、ＨＦＩ１２０の一部である（つまり、ＨＦＩ１２０に組み込まれる）可能性があり、ＨＦＩ１２０によるＧＳＭの操作の処理のために必要とされるＥＡ−ＲＡ変換を行う。ファブリック・バス４１４に結合されるのは、プロセッサ・キャッシュ４１２であり、さらに、プロセッサ・キャッシュ４１２は、中央プロセッサの処理ユニットに接続される。（実行されるタスクの観点で）さらに示されるのは、実行されるタスクに割り当てられた物理メモリ空間４０５へのＥＡのマッピングの図である。物理メモリのこの仮想的な図の中にあるのは、ＧＳＭの操作を生成するためにＨＦＩ１２０によって処理される前にタスクによって生成されたコマンドおよびデータを記憶するために使用される送信ＦＩＦＯ４０７である。さらに示されるのは、送信ＦＩＦＯ内の操作の数を追跡し、送信ＦＩＦＯ４０７から操作をいつ取り出すべきかをＨＦＩ１２０に知らせるために利用されるメカニズムであるＨＦＩドアベル（HFI doorbell）４０９である。同様に、目標ノード１０２Ｂの受信ＦＩＦＯ４０８は、物理メモリ４０６内に置かれ、物理メモリ４０６内で、ＥＡマッピング位置４０４が、参照のためにやはり特定される。
【００３６】
ＨＦＩウィンドウ４４５および４４６は、特定のタスクの実効アドレス空間に関して、コマンド内に含まれる実効アドレス（ＥＡ）が適切に変換されるためにＧＳＭコマンドが呼び出されることを可能にする、ノードのハードウェアをタスク・レベルで見ることを提供する。ＨＦＩウィンドウ４４５は、ＧＳＭの操作のために使用される基本的なシステム構造である。各ＨＦＩ１２０は、複数のウィンドウ４４５を含む可能性があり、各ウィンドウは、コンピュータ・ノード１０２で実行される１つまたは複数のタスクのうちの単一のタスクに割り当てられる。
【００３７】
例示的なＨＦＩウィンドウ４４５のさらなる機能的な特徴が、図４によって示される。ＨＦＩ１２０は、（ウィンドウ０からウィンドウＮまでの）複数のウィンドウを含む可能性があり、そのうちのＨＦＩウィンドウ２  ４４５が、例示的なウィンドウとして選択される。各ＨＦＩは、決まった数のウィンドウを有し、それらのウィンドウのそれぞれは、丁度１つのタスクに属することができるが、２つ以上のウィンドウが、タスクに割り振られ得る。タスクに割り振られたウィンドウは、タスクから生じるＧＳＭメッセージを送り出すことと、そのタスクの実効アドレス空間にアクセスする到着するメッセージを処理することとの両方のためにＨＦＩ１２０によって使用される。ＨＦＩウィンドウ２  ４４５は、ユーザ５５０、ＯＳ５５２、またはハイパーバイザ５５４、あるいはこれらのすべてを含む異なる機能レベルで生成され得るタスクによって生成されるコマンドによってアクセス可能である。
【００３８】
ＨＦＩウィンドウ４４５は、コマンド・エントリ、資格証明（credential）エントリ、アドレス変換エントリなどの複数の機能エントリと、メッセージの送信および受信を制御するためにＨＦＩによって使用されるデータ構造とを含む。特に、示されるように、ウィンドウ２  ４４５は、限定することなく、以下のエントリ、すなわち、ＨＦＩコマンド・カウンタ５１０、送信ＦＩＦＯ  ＥＡ５１４、送信リモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）ＦＩＦＯ  ＥＡ５１５、受信ＦＩＦＯ  ＥＡ５１６、エポック・ベクトル（epoch vector）ＥＡ５１８、資格証明５１２、およびフェンス（fence）カウンタ５２０を含む。例示的な実施形態において、資格証明５１２は、（本明細書においてはジョブ・キーとも呼ばれる）ジョブＩＤ、プロセスＩＤ、ＬＰＡＲ（論理パーティション）ＩＤ、およびＥＡキーを含む。ＨＦＩは、資格証明５１２を参照して、到着するＧＳＭトランザクションを、関連付けられたタスクの実効アドレス空間に対する操作を実行することを認可されているものとして正しく認証する。資格証明５１２の異なる構成要素が、ＨＦＩウィンドウ２  ４４５内で独自のエントリによって表される可能性もあることが、理解される。上記エントリのそれぞれは、タスクの実効アドレス空間内で指定されたエントリが記憶されるかまたは指定されたエントリが始まる（つまり、開始位置）メモリ位置の値を提供するレジスタである。これらの実効アドレスは、ＭＭＵ１２１によって、物理メモリ５３０内に収容される対応する実アドレスに変換される。ＨＦＩは、ウィンドウの内容の実効アドレスのうちの１つをＭＭＵ１２１に転送し、ＭＭＵ１２１は、実効アドレスを、資格証明によって特定されるタスクのＥＡがマッピングされる物理メモリ５３０に対応する実アドレスに変換する。したがって、ウィンドウ２  ４４５は、ＨＦＩと実（物理）メモリとの間の複数のマッピングを定義する。
【００３９】
ＨＦＩウィンドウ２  ４４５は、ローカル・フェンス操作およびグローバル・フェンス操作中にＧＳＭの操作の完了を追跡するための１つまたは複数のフェンス・カウンタ５２０も含む。ＥＡによって参照されるフェンス・カウンタ５２０は、タスクに割り振られた実メモリ位置内のフェンス・カウンタ５４０にマッピングされる。ローカル（タスクによって発行される）フェンス操作を助けるために、タスクに割り振られたＲＡ空間は、処理のためにＨＦＩウィンドウにわたる前に送信ＦＩＦＯ５３２に最初に記憶されるタスクによって発行されるコマンドの完了を追跡するためのｓｅｎｄ−ｏｐカウンタ５４２も含む。
【００４０】
したがって、さらに示されるように、送信ＦＩＦＯ  ＥＡ５１４は、タスクの送信ＦＩＦＯに関する開始実効アドレスを保有し、そのアドレスは、ＭＭＵ１２１によって、物理メモリ５３０内の送信ＦＩＦＯ５３２の始まり（実アドレス）を指すように変換され得る。同様に、受信ＦＩＦＯ  ＥＡ５１６は、タスクの受信ＦＩＦＯ５３４の開始ＥＡを保有し、そのアドレスは、ＭＭＵ１２１によって変換され、タスクの受信ＦＩＦＯ５３４の物理メモリ５３０内の開始アドレスを指す。同様に、送信ＲＤＭＡ  ＦＩＦＯ  ＥＡ５１５およびエポック・ベクトルＥＡ５１８は、ＭＭＵ１２１によって、それぞれ、送信ＲＤＭＡ  ＦＩＦＯ５３６およびエポック・ベクトル５３８の開始実アドレスを指すように変換され得る。送信ＦＩＦＯ５１４および受信ＦＩＦＯ５１６は、そのウィンドウが対応するタスクの実効アドレス空間内では連続している可能性がある一方、これらのＦＩＦＯ（５１４、５１６）は、実（物理）メモリ５３０内では不連続である可能性があることに留意されたい。
【００４１】
それぞれのＨＦＩウィンドウは、（特定のタスクに関する）実効アドレスを実アドレスに解決するために使用されるアドレス変換テーブルへのポインタを含む重要なリソースを含む。ＧＳＭ初期化操作のために割り当てられるＨＦＩ内のウィンドウ番号は、非透過的ハンドル（opaque handle）としてユーザに返され、その非透過的ハンドルは、実効アドレスとともに、ノードおよびウィンドウ番号の符号化（埋め込み）を含む可能性があり、グローバル・アドレス空間が、タスクの実効アドレス空間内で予約される。言語ランタイムは、各タスクのウィンドウの識別情報を、そのタスクにＧＳＭコマンドを発行したいすべてのその他のタスクに伝達する責任を負う。タスクが制御の複数のスレッドを有する場合、ＨＦＩウィンドウに対する原始性が、通常のタスク内のロックするプリミティブによるか、または各スレッドに独自の異なるＨＦＩウィンドウを割り振ることによるかのどちらかで保証されなければならない。最後に、そのウィンドウに基づくすべてのトラフィックに関するＨＦＩ性能カウンタ（HFI performance counter）も、タスクのアドレス空間にマッピングされる。これは、タスクが相互接続のトラフィックに関する統計を容易に監視することを可能にする。
【００４２】
ＨＦＩウィンドウは、１つまたは複数の論理パーティションの間で共有される可能性がある。単一のノードが分割される場合、パーティションで実行されるオペレーティング・システムは、サポートされるウィンドウの総数のうちのサブセットにのみアクセスし得る。さらに、ＯＳは、ＩＰデバイス・ドライバなどのカーネルのサブシステムのためにこれらのウィンドウのサブセットを予約する可能性がある。残りのウィンドウは、そのパーティション内で実行されるタスクによる使用のために利用可能である可能性がある。
【００４３】
ウィンドウがＨＦＩで割り当てられるとき、オペレーティング・システムは、タスクが属するジョブの識別情報でウィンドウをタグ付けする。ＧＳＭの操作の発行中に、すべての送出されるパケットは、自動的に、ＨＦＩによってジョブＩＤでタグ付けされる。また、送出されるパケットは、コンテキストのＧＳＭ実効アドレスが変換されなければならない送信先／目標ノードのＨＦＩ１２０Ｂの特定のウィンドウを指定する。ＨＦＩは、ＧＳＭパケットに含まれるジョブＩＤをウィンドウに含まれるジョブＩＤと比較する。ジョブＩＤが一致しない場合、パケットは、黙って破棄される。そのようなパケットを数える統計が、システムのユーザが、そのようなパケットでシステムを意図せずにかまたは悪意を持ってかのどちらかであふれさせることを穏やかに止めさせるために使用され得る。
【００４４】
したがって、グローバル共有メモリの操作中、タスクの実効アドレス空間への認可されていないアクセスは、許されない。タスクは、システム全体の任意の場所で実行される任意のジョブに属する任意のタスクにＧＳＭの操作を送信することができる。しかし、到着するＧＳＭコマンドが、コマンドがアドレス空間を操作するタスクと同じジョブに属する場合、かつその場合に限り、ＨＦＩは、目標とされるタスクの実効アドレス空間に対するＧＳＭの操作を実行する。ジョブＩＤをさらに細かくすることも可能であり、それによって、タスクは、ジョブ内で実行されるタスクのサブセットのみに特定の認可を与えることができる。これは、タスクのサブセットがそれらのタスクに異なるジョブＩＤが関連付けられることを要求し、そのジョブＩＤがこれらのタスクに関連するＨＦＩウィンドウに組み込まれるようにすることによって行われ得る。
【００４５】
ファブリックの相互接続を介してデータを伝達するためにウィンドウを使用することに関するさらなる詳細は、例えば、本出願と同じ譲受人に譲渡された、Arimilliらの米国特許第８，２７５，９４７号に見られる可能性があり、この米国特許は、参照により本明細書に組み込まれている。
【００４６】
概して、本発明の実施形態を実施するために実行されるルーチンは、オペレーティング・システムの一部として実装されるか、あるいは特定のアプリケーション、コンポーネント、プログラム、オブジェクト、命令のモジュールもしくはシーケンス、またはさらにはこれらのサブセットとして実装されるかに関係なく、本明細書においては「コンピュータ・プログラム・コード」または単に「プログラム・コード」と呼ばれる。概して、プログラム・コードは、コンピュータのさまざまなメモリおよびストレージ・デバイスにさまざまな時間に存在し、コンピュータの１つまたは複数のプロセッサによって読まれ、実行されるときにコンピュータに本発明のさまざまな態様を具現化するステップまたは要素を実行するために必要なステップを実行させる１つまたは複数の命令を含む。さらに、本発明は、完全に機能するコンピュータおよびコンピュータ・システムに関連して以降で説明されるが、当業者は、本発明のさまざまな実施形態がさまざまな形態のプログラム製品として配布され得ることと、本発明が配布を実際に実行するために使用されるコンピュータ可読媒体の特定の種類に関係なく等しく当てはまることとを理解するであろう。
【００４７】
そのようなコンピュータ可読媒体は、コンピュータ可読ストレージ媒体および通信媒体を含み得る。コンピュータ可読ストレージ媒体は、本質的に非一時的であり、コンピュータ可読命令、データ構造、プログラム・モジュール、またはその他のデータなどの情報を記憶するための任意の方法またはテクノロジーで実装された揮発性および不揮発性の取り外し可能なおよび取り外し不可能な媒体を含み得る。コンピュータ可読ストレージ媒体は、ＲＡＭ、ＲＯＭ、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、もしくはその他のソリッド・ステート・メモリ・テクノロジー、ＣＤ−ＲＯＭ、デジタル・バーサタイル・ディスク（ＤＶＤ）、もしくはその他の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、もしくはその他の磁気式ストレージ・デバイス、または所望の情報を記憶するために使用され得る、データ処理システムによってアクセスされ得る任意のその他の媒体をさらに含む可能性がある。通信媒体は、コンピュータ可読命令、データ構造、またはその他のプログラム・モジュールを具現化し得る。限定ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含み得る。上記の媒体のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれ得る。
【００４８】
以降で説明されるさまざまなプログラム・コードは、本発明の特定の実施形態でそのプログラム・コードが実装されるアプリケーションに基づいて特定され得る。しかし、以降のすべての特定のプログラムの用語が単に便宜的に使用されており、本発明がもっぱらそのような用語によって特定または示唆、あるいはその両方がなされるいかなる特定のアプリケーションにおける使用に限定されるべきでないことを理解されたい。さらに、コンピュータ・プログラムがルーチン、プロシージャ、メソッド、モジュール、オブジェクトなどへと編成され得る概して無数の方法と、プログラムの機能が通常のコンピュータ内に存在するさまざまなソフトウェア・レイヤ（例えば、オペレーティング・システム、ライブラリ、ＡＰＩ、アプリケーション、アプレットなど）の間に割り当てられ得るさまざまな方法とを考えると、本発明は、本明細書において説明されるプログラムの機能の特定の編成および割り当てに限定されないことを理解されたい。
【００４９】
加えて、本発明の実施形態は、図１〜４に関連して上で説明されたハードウェアおよびソフトウェア環境内で実施され得ることが理解されるであろう。しかし、本発明が多数の異なる環境で実施され得ることと、本発明の精神および範囲を逸脱することなく上述のハードウェアおよびソフトウェアの実施形態にその他の変更がなされ得ることとは、本開示の恩恵を受ける当業者によって理解されるであろう。したがって、本発明は、本明細書で開示される特定のハードウェアおよびソフトウェア環境に限定されない。
【００５０】
ハイ・パフォーマンス・コンピューティング（ＨＰＣ）ネットワークにおける通信チャネルのフェイルオーバ
本発明に準拠した実施形態は、例えば、ＨＰＣクラスタまたはその他のマルチプロセッサ分散データ処理システムで使用されるＨＰＣネットワークにおいて高速で効率的な通信チャネルのフェイルオーバを実装する。ＨＰＣクラスタにおいては、異なる計算ノードの調整プロセス（例えば、ユーザのジョブまたはＯＳのインスタンス）間の通信の喪失は、ジョブの進行の遅延／喪失、時間のかかるリカバリ、またはクラスタの不安定化、あるいはこれらの組合せにつながる可能性があり、実質的に、計算リソース、電力を浪費し、最終結果を遅らせる。さまざまなＨＰＣクラスタ・テクノロジーが、異なる種類の通信チャネルを利用して、調整プロセス間の通信をサポートする。
【００５１】
例えば、本出願の譲受人であるＩＢＭから入手され得るＰｏｗｅｒ７に基づくクラスタにおいては、通信チャネルが、１つまたは複数のホスト・ファブリック・インターフェース（ＨＦＩ）アダプタで利用可能なウィンドウによって特徴付けられる。ＨＦＩは、ユーザに上述のウィンドウを介した相互接続ファブリックへのアクセスを提供し、本発明の文脈のウィンドウは、ソフトウェア・クライアントまたは（例えば、プロトコル、論理パーティション、デバイス・ドライバ、ユーザ・レベルのジョブなどである可能性がある）エンドポイントが別のクライアントまたはエンドポイントと相互接続ファブリック上でメッセージおよびデータを交換することができる１組の構成可能なリソースであると考えられる。構成は、ＭＭＩＯでマッピングされたレジスタによって提供され、ＨＦＩハードウェアは、ソフトウェア・クライアントによって提供されるメモリ（例えば、ＦＩＦＯ、データ・バッファ）に直接アクセスすることができ、ハードウェアおよびソフトウェアによって共有されるレジスタおよびメモリの集合は、以降、「ウィンドウ・リソース」と呼ばれる。したがって、ウィンドウは、実質的に、所与の通信チャネルの状態を定義する。
【００５２】
しかし、本開示の目的のために、用語「ウィンドウ」は、ＨＦＩウィンドウと、その他の相互接続ファブリックで利用される、その他の種類のファブリック・インターフェース・デバイスに存在する同様の構造とを表すために使用される可能性がある。例えば、Ｉｎｆｉｎｉｂａｎｄクラスタにおいて、通信チャネルは、ホスト・チャネル・アダプタ（ＨＣＡ）のキュー・ペアによって定義され、したがって、本明細書において、用語ウィンドウは、Ｉｎｆｉｎｉｂａｎｄのキュー・ペア、または相互接続ファブリックに結合された対のエンドポイントの間の通信チャネルの状態を定義するために使用されるその他の分散データ処理システムの任意のその他のエンティティをやはり示すと考えられ得る。
【００５３】
概して、ウィンドウは、所与のエンドポイントに関連付けられ、別のエンドポイントに関連する別のウィンドウとの通信を通じてそのエンドポイントと別のエンドポイントとのインターフェースを取るために使用される。エンドポイントは、例えば、プロトコル、ユーザ・プログラム、オペレーティング・システム、ジョブ、タスクなどである可能性があり、ウィンドウは、例えば、送信および受信キュー、ならびに通信チャネルの状態を集合的に定義するその他のレジスタおよびデータを含む可能性がある。
【００５４】
以降で検討される実施形態においては、例えば、各ウィンドウは、それぞれがホスト・メモリ内のバッファおよび構成レジスタ（例えば、生産者（producer）および消費者（consumer）のオフセット、サイズ、アドレスなど）を含む、例えば、さまざまなＦＩＦＯを含む、状態を保有し、再始動されるために障害が起こったウィンドウから別のウィンドウに移され得る１組のリソースを含む可能性がある。ＦＩＦＯは、例えば、ウィンドウへのさまざまな種類の操作をキューに入れるためにソフトウェアによって使用される送信ＦＩＦＯと、ソフトウェアへの操作および完了をキューに入れるためにハードウェアによって使用される受信ＦＩＦＯと、ハードウェアへのデータ受信バッファを提供するためにソフトウェアによって使用される受信記述子ＦＩＦＯ（receive descriptor FIFO）と、ＲＤＭＡの完了通知パケットなどの（ただし、これに限定されない）送出される操作をキューに入れるためにハードウェアによって使用される保留／特殊ＦＩＦＯ（pending/special FIFO）とを含み得る。ウィンドウ・リソースは、ＲＤＭＡのフローのためにハードウェアによって使用され、ハードウェアによってキャッシュされるが、ホスト・メモリに記憶されるＲＤＭＡコンテキスト情報と、消費者進捗インジケータ（consumer progress indicator）として働き、ソフトウェア・クライアントがＭＭＩＯの読み取りを避けることを可能にするためにハードウェアによってホスト・メモリに書き込まれる完了ベクトル（completion vector）と、その他の静的な構成情報（例えば、メモリの変換で使用されるキーおよび保護情報などの保護情報）を有する追加のレジスタとをさらに含み得る。概して、ホスト・メモリ内のさまざまなＦＩＦＯに関する情報、例えば、先頭および末尾ポインタおよびサイズ情報が、ファブリック・インターフェース・デバイスのレジスタに保有される。
【００５５】
この文脈で、ウィンドウは、ファブリック・インターフェース・デバイス（例えば、ＨＦＩまたはＨＣＡ）およびホスト・メモリのそれぞれに存在するリソースを含み、前者は、本明細書において、ハードウェア・リソースと呼ばれ、後者は、メモリ・リソースと呼ばれる。加えて、示される実施形態において、ウィンドウの態様、例えば、メモリ・リソースの一部は、ハイパーバイザに存在する。さらに、本明細書において説明されるフェイルオーバのプロトコルの観点で、ウィンドウは、ＨＦＩまたはその他のファブリック・インターフェース・デバイスのハードウェア・レジスタおよびその他のハードウェア・リソースとホスト・メモリのメモリ・アクセス・レジスタおよびその他のメモリ・リソースとの間の複数のマッピングを含むとより広く考えられる可能性があり、これらのマッピングは、例えば、ＨＦＩがホスト・メモリのさまざまなキューへのメモリ転送およびホスト・メモリのさまざまなキューからのメモリ転送を実行することを可能にする。これらのマッピングは、例えば、送信ＦＩＦＯのマッピング、受信ＦＩＦＯのマッピング、ＲＤＭＡ  ＦＩＦＯのマッピングなどを含み得る。
【００５６】
本発明に準拠した実施形態は、フェイルオーバ・プロセスへのソフトウェア・スタックの関与を望ましく最小化するかまたはなくすフェイルオーバ・プロトコルを実装し、そのことは、通信チャネルのフェイルオーバからのリカバリを速める。一部の実施形態においては、保留が解かれるとすぐにクライアントが作業を再開し得るように、（例えば、ページ・フォールトをアサートすることによって）クライアントがウィンドウにアクセスすることを「保留する（hold off）」ことが望ましい。さらに、多くの実施形態においては、フェイルオーバの際にクライアントが求められるリカバリ・アクションが完全になくされない場合には削減されるように、ウィンドウに関連するソフトウェア領域を指すすべてのポインタを最小化することが望ましい。
【００５７】
障害は、例えば、レジスタのハードウェア・エラー、ファブリックへの通信の喪失、ハングし、送信もしくは受信キューを実質的に動かなくする状態機械、または別の理由が原因で起こる可能性がある。フェイルオーバは、障害が起こったウィンドウから新しいウィンドウへのウィンドウの状態の転送を部分的に組み込み、そのことは、新しいウィンドウおよび通信チャネルを一から確立する必要をなくすために、例えば、ＲＤＭＡの完了通知などの保留キューに関して同じレジスタ設定およびメモリ空間を新しいウィンドウが再利用することを可能にし、多くの場合、さらなるトラフィックが失われることを防止し、リカバリ時間を削減する。
【００５８】
図５に示されるように、一実施形態において、データ処理システム６００は、ハイパーバイザ６０２、ホスト・メモリ６０４、およびＨＦＩ６０６を含み得る。オペレーティング・システム、アプリケーション、ジョブ、タスク、またはデータ処理システム６００でエンドポイントとして働くことができるその他の適切なソフトウェア・エンティティである可能性があるソフトウェア・クライアント６０８は、構成要素６０２、６０４、および６０６を介して相互接続ファブリックにアクセスする。
【００５９】
ＨＦＩ６０６は、複数のウィンドウ、例えば、ウィンドウ６１０、６１２を含む。概して、すべてのハードウェア・ファブリック・インターフェース・デバイスは、例えば、ブート時に定義されるか、またはハードウェアで静的に定義された決まった数のウィンドウをサポートする。最初に、ソフトウェア・クライアント６０８が、ＨＦＩ６０６のウィンドウ６１２に結合されるが、この検討の目的のために、ウィンドウ６１０で障害が発生したことと、ウィンドウ６１２が現在いかなるその他のクライアントにも使用されていないこととが仮定される。ウィンドウ６１０、６１２は、それぞれが１組の静的な構成レジスタ６１４、６１６と、１組のＦＩＦＯに関連するレジスタ６１８、６２０とを含むものとして示されている。
【００６０】
ハイパーバイザ６０２内に、ウィンドウ６１０、６１２は、それぞれが部分的にファームウェアＭＭＩＯアドレス・データ６２６、６２８およびファームウェア割り込みデータ６３０、６３２を含むそれぞれのウィンドウ・データ構造６２２、６２４を有する。ハイパーバイザ６０２は、クライアント６０８に関する１組のＭＭＩＯおよび割り込みマッピング６３４、６３６も含む。さらにホスト・メモリ６０４に置かれるのは、１組の完了ベクトル６３８、ＲＤＭＡコンテキスト・データ６４０、および１組のＦＩＦＯ６４２である。
【００６１】
示される実施形態の相互接続ファブリックは、「ＩＳＲ＿ＩＤ」およびパケット番号によりパケットをルーティングする。クラスタ・ファブリックのあらゆるパケットは、送信元ＩＳＲ＿ＩＤ／ウィンドウ・ペアおよび送信先ＩＳＲ＿ＩＤ／ウィンドウ・ペアを含む。加えて、各ウィンドウに関してクライアントとハードウェアとの間で共有されるメモリは、メモリ管理ユニット（Ｉ／Ｏ  ＭＭＵ）によるアドレスの仮想化を利用することが仮定される。Ｉ／Ｏ  ＭＭＵは、共有されたメモリのためにクライアントが使用する仮想アドレス空間の、同じメモリのためにハードウェアが使用する物理アドレス空間へのマッピングを提供する。この例においては、ＦＩＦＯおよびその他のホスト・メモリの構造のために使用されるメモリが再マッピングされる必要がないように、障害が起こったウィンドウと新しいウィンドウとの両方が、同じＩＯ  ＭＭＵにアクセスする。
【００６２】
本発明に準拠した実施形態においては、ソフトウェア・クライアント６０８が、１つまたは複数のその他のクライアントへの通信チャネルを提供するためにＨＦＩ６０６のウィンドウ６１０を介してファブリック相互接続へのアクセスを最初に提供される。例えば、（図４に関連して上で検討された）物理メモリの送信および受信ＦＩＦＯならびにＲＤＭＡ  ＦＩＦＯなどの１つまたは複数のＦＩＦＯに関するマッピングを含む複数のマッピングが、レジスタ６１８によって指定される。
【００６３】
通信チャネルの障害を検出することに応じて、本発明に準拠した実施形態は、例えば、クライアントに割り当てられたＦＩＦＯを指すように新しいウィンドウ６１２のレジスタ６２０を更新することによって、クライアントに割り当てられたメモリ・リソースをファブリック・インターフェース・デバイスの第２のウィンドウに割り当てられた第２のハードウェア・リソースにマッピングするようにマッピングを更新することによって、ウィンドウ６１０によって定義された通信チャネルの状態を別のウィンドウ、例えば、ウィンドウ６１２に移す。そのような時点で、通信チャネルを介したクラスタ・ファブリックへのクライアントのアクセスは、第２のウィンドウを用いて復元され得る。
【００６４】
この例示的な実施形態においては、ＩＢＭから入手可能なＴｏｒｒｅｎｔ  Ｉ／Ｏ  Ｈｕｂで利用可能な既存のＨＦＩハードウェアが、本明細書において開示される機能を実装するために使用され得る。しかし、この手法は、実際には、（１）ハイパーバイザが読み取り可能なレジスタおよびホスト・メモリの構造にチャネルの状態を保有し、（２）チャネルが任意の状態で開始され得る任意のその他のＩ／Ｏハードウェアに関連して利用される可能性があることが理解されるであろう。
【００６５】
例えば、図６のルーチン６５０は、図５のデータ処理システムにおける通信チャネルの障害に関連して行われ得る操作の高レベルのフローを示す。ルーチン６５０は、例えば、（例えば、検出されたハードウェア・エラーまたはネットワークの再構成が原因である）通信の喪失の刺激に応答してトリガされる可能性があり、結果として、エラーがハイパーバイザにシグナリングされる。
【００６６】
ブロック６５２において、ハイパーバイザは、ウィンドウへのクライアントのＭＭＩＯアクセスを中断する可能性があり、ブロック６５４において、ウィンドウの状態を新しいウィンドウに移す可能性がある。クライアントのアクセスの中断は、例えば、ページ・フォールトをアサートすることによって実施される可能性があり、その結果、クライアントの観点から見て、クライアントは、そのクライアントがページ・フォールトが解決されるのを待っているかのように動作する。概して、ウィンドウの状態の転送は、障害が起こったウィンドウに関するハードウェア・レジスタを新しいウィンドウに関する対応するレジスタにコピーすることをともなう。
【００６７】
次に、ブロック６５６において、新しいウィンドウが有効にされ、それによって、ハードウェアが保留中の作業を再開することを可能にする（ブロック６５８）。したがって、例えば、送信または受信キュー内にある任意の保留中の作業は、直ちに再開可能であり、したがって、保留中の作業は、多くの通常の手法の場合のように破棄される必要がない。
【００６８】
それから、ブロック６６０において、古いウィンドウへのクライアントのアクセスが、新しいウィンドウに再マッピングされ、ブロック６６２において、ハイパーバイザが、クライアントに新しいウィンドウへのフェイルオーバを知らせ、クライアントが保留中の作業を再開することを可能にする（ブロック６６４）。例えば、ページ・テーブルが、新しいウィンドウのレジスタを指すように更新される可能性があり、それによって、ページ・フォールトが解決するようにし、クライアントが再開することを可能にする。加えて、クライアントへの通知は、クライアントによるすべての将来の通信が新しいウィンドウを参照することによって行われるように、古いウィンドウの障害および新しいウィンドウの識別子をクライアントに知らせることをともなう可能性がある。
【００６９】
その後、その他のクライアントが新しいウィンドウを使いはじめる（ブロック６６８）ように、ブロック６６６において、クライアントが、ピア・クライアントに新しいウィンドウへの変更を知らせ得る。それから、操作が、ブロック６７０で再開する。一実施形態においては、例えば、各ピア・クライアントがそれに応じてそのピア・クライアントのアドレスを更新し得るように、各ピア・クライアントにクライアントに関する古いおよび新しいアドレスを与えるために、特別なパケットの種類が定義され得る。そのようなクライアントへの通知は、ピアからのすべての失われたパケットが検出され、ピアによって再試行されることを可能にし得る。
【００７０】
一部の実施形態においては、現在のパケットが障害の原因であった場合に、作業がＦＩＦＯ内の次のパケットを用いて再開されるようにして、現在のパケットを再開することが省略され得るとき、通信チャネルは、パケットが再試行されることが原因で再びハングしない。
【００７１】
ここで図７および８に目を向けると、図５のデータ処理システム６００で通信チャネルのフェイルオーバを実施するためのハイパーバイザによる実行に好適なルーチン７００に関するより詳細な流れ図が提供される。
【００７２】
初めに、ブロック７０２において、新しい「送信先」ウィンドウが、利用可能なウィンドウのプールから選択される。選択されたウィンドウは、利用可能なウィンドウのプールから削除される。利用可能なウィンドウのプールは、例えば、ＬＰＡＲのブートの前に予め予約されること、ＬＰＡＲによって「示される」ことなどによって定義され得る。
【００７３】
次に、ブロック７０４において、障害が起こったウィンドウへのクライアントのＭＭＩＯアクセスが、ソフトウェアがハードウェアのレジスタ空間にさらにアクセスすることを防止するために中断され、ハードウェアの状態が変更されることなくハイパーバイザがフェイルオーバを処理することを可能にする。それから、ブロック７０６において、すべての進行中のＤＭＡが以下のステップの前に完了されることを保証するために、障害が起こったウィンドウが、無効にされる。ブロック７０８は、無効化が完了するまで待つ。
【００７４】
次に、ブロック７１０において、キャッシュされた情報が、フラッシュされる。ＨＦＩハードウェアおよびその他の通信デバイスは、性能を高めるために、ハードウェア内で頻繁に使用される（ＲＤＭＡコンテキストなどの）構造をキャッシュすることができる。この状態が転送される必要があるとき、ハードウェアのキャッシュをフラッシュすることが、開始されるときに送信先ウィンドウが現在の情報を有することをハイパーバイザが保証することを可能にする。ブロック７１２は、このフラッシュが完了するまで待つ。
【００７５】
次に、ブロック７１４において、キューおよびバッファのアドレスのすべて、生産者／消費者のオフセット、ならびにホスト・メモリの領域に記憶されない通信を管理するためにハードウェアが使用するその他の情報を含む重大なレジスタ情報が、障害が起こったウィンドウから読まれる。それから、ブロック７１６において、この重大なレジスタ情報が、選択された送信先ウィンドウに書き込まれる。
【００７６】
次に、ブロック７１８において、任意の割り込みが保留中であるかどうかが判定される。そうである場合、制御は、割り込みテーブルを更新するブロック７２０に移る。送信先ウィンドウからのすべてのハードウェア割り込みがソフトウェア・クライアントによって期待される同じ割り込みハンドルにルーティングされることを保証するために、割り込みルーティングのためのハイパーバイザの内部メモリ構造が、更新される。ハイパーバイザは、各ウィンドウに関する割り込み番号を記憶する（または計算することができる）。それから、いかなる割り込みも保留されていない場合、または割り込みテーブルが更新された後、制御は、新しいウィンドウで必要に応じて（１つまたは複数の）割り込みを施行するブロック７２２に移る。ブロック７１４で取り出されたハードウェアの状態が、未処理のまたは処理される必要がある割り込みが存在することを示す場合、新しいウィンドウが、ソフトウェア・クライアントが通知を受けることを保証するために（１つまたは複数の）同じ割り込みを施行するように設定される。
【００７７】
次に、ブロック７２４において、送信先ウィンドウが有効にされ、送信先ウィンドウができるだけ早くＦＩＦＯの保留中の作業を処理しはじめることを可能にする（ブロック７２６）。それから、ブロック７２８において、ソフトウェア・クライアントによるＭＭＩＯアクセスが、以降、障害が起こったウィンドウではなく送信先ウィンドウに到着するように、クライアントのＭＭＩＯアクセスが、障害が起こったウィンドウではなく送信先ウィンドウを指すように再マッピングされる。示された実施形態において、クライアントは、ページ・テーブルを更新するようにＯＳ／ハイパーバイザに求めるように要求されず、それは、これが透過的に行われるからである。
【００７８】
次に、ブロック７３０において、新しいウィンドウへのクライアントのＭＭＩＯアクセスが有効化され、ウィンドウへのＭＭＩＯアクセスが完了することを可能にし、ソフトウェア・クライアントにハードウェアとインタラクションさせる（ブロック７３２）。示された実施形態において、クライアントは、フェイルオーバにまだ気付いていない可能性があるが、それにもかかわらず、進行中の活動を新しいウィンドウを用いて再開し得る。したがって、ブロック７３４において、クライアントは、例えば、ハイパーバイザがフェイルオーバを示すメッセージをクライアントに送信することによってフェイルオーバを知らされる。メッセージは、新しいアドレス指定情報をクライアントに提供する、古いおよび新しいウィンドウを含む関連する情報を含み得る。その後、ブロック７３６において、クライアントは、例えば、帯域内ネットワーク・メッセージか、または別のネットワークもしくはジョブ制御管理による帯域外通信かのどちらかによって各ピアに新しいウィンドウを通知し得る。結果として、ピア・クライアントは、その後、新しいウィンドウを介してソフトウェア・クライアントに通信を送り（ブロック７３８）、その後、通常の動作が再開し得る（ブロック７４０）。
【００７９】
図９は、例えば、障害が起こったウィンドウ６１０から新しいウィンドウ６１２にフェイルオーバが行われた後の図５のデータ処理システムを示す。示されるように、ポインタおよびマッピングは、ソフトウェア・クライアント６０８の観点から見て、接続が新しいウィンドウ６１２を用いて進行し得るように更新される。
【００８０】
本発明に準拠した実施形態は、通常のフェイルオーバの手法に優るいくつかの利点を提供する。例えば、送信ＦＩＦＯで待機しているか、または（１つもしくは複数の）受信ＦＩＦＯでまだ処理されていない操作が、概して失われないが、通常の手法では、ＦＩＦＯのいずれかのパケットが、概して失われ、より長いソフトウェア・リカバリ時間およびジョブの中断、ならびにＨＰＣクラスタの不安定化につながり、電力および容量を無駄にする。したがって、本発明に準拠した実施形態は、概して、失われるパケットの数を削減し、それによって、長いソフトウェア・リカバリ時間を削減するかまたはなくす。
【００８１】
加えて、計算ジョブの複数のコピーに依拠する手法と比較して、概して、計算／通信リソースを二重化する必要がなく、管理のオーバーヘッドがより少なくなり、ＣＰＵ／メモリ・リソースを二重化すること、クラスタの帯域幅の使用を二重化すること、計算ジョブの複数のコピーの使用に通常関連する複数のソースから戻ってくる結果を合併／破棄する必要を避ける。
【００８２】
ラウンド・ロビンで動作する複数のアクティブなチャネルに依拠する手法と比較して、概して、リソースの消費がより少なく、概して、実行形路（performance path）に関するオーバーヘッドがより少ない。さらに、概して、追加のアクティブなウィンドウが割り当てられる必要がなく、それによって、その他のジョブのためにウィンドウを解放する。多くの場合、より少ないウィンドウは、キューおよびメモリ・マッピングのために使用されるクライアントおよびハイパーバイザのメモリをより少なくし、概して、複数のウィンドウにまたがるトラフィックを処理するためのプロセスの複雑さがより少ない。節約されたリソースは、メモリを食う計算ジョブに適用される可能性があるか、または同じシステムのその他の目的のための通信チャネルに適用される可能性があるかのどちらかである。さらに、概して、失われたメッセージのための長いソフトウェア・リカバリ時間は、やはり、ラウンド・ロビン構成の問題である。
【００８３】
加えて、アクティブ／パッシブ・モードで動作する複数のチャネルに依拠する手法と比較して、スタンバイ・ウィンドウが割り当てられる必要がなく、それらのウィンドウをその他のジョブのために解放するので、リソースの消費がやはりより少ない。より少ないウィンドウは、キューおよびメモリ・マッピングのために使用されるクライアントおよびハイパーバイザのメモリをより少なくし、概して、複数のウィンドウにまたがるトラフィックを処理するためのプロセスの複雑さがより少ない。節約されたリソースは、メモリを食う計算ジョブに適用される可能性があるか、または同じシステムのその他の目的のための通信チャネルに適用される可能性があるかのどちらかである。また、概して、失われたメッセージのための長いソフトウェア・リカバリ時間は、やはり、アクティブ／パッシブ・チャネル構成の問題である。
【００８４】
さまざまな追加の変更が、本発明の精神および範囲から逸脱することなしに、開示された実施形態になされ得る。
【図１】
0006328134.tif 000002
【図２】
0006328134.tif 000003
【図３】
0006328134.tif 000004
【図４】
0006328134.tif 000005
【図５】
0006328134.tif 000006
【図６】
0006328134.tif 000007
【図７】
0006328134.tif 000008
【図８】
0006328134.tif 000009
【図９】
0006328134.tif 000010