JP7279891B2 - 管理装置 - Google Patents

Description

本発明は、管理装置、管理方法、プログラム、情報処理装置に関する。

サーバとストレージ間など複数の情報処理装置間でデータ（フレーム）の送受信を行う場合、経路途中でのデータ破損などによりフレームエラーが生じることがある。

このようなフレームエラーを検出するための方法の一例として、例えば、特許文献１がある。特許文献１に記載されている方法では、データの送信装置は、転送データを分割して、分割した転送データについてwriteハッシュ値を生成し、分割した転送データとwriteハッシュ値とを送信する。また、データの受信装置では、受信した転送データに基づいてreadハッシュ値を生成し、writeハッシュ値とreadハッシュ値とを比較する。データの受信装置は、writeハッシュ値とreadハッシュ値とが一致しない場合、転送データに欠損があると認定する。

特許第５８５２６７４号

ストレージとサーバ間を高速に接続するための方法として、ＦＣ－ＳＡＮがある。また、ＦＣのうちクラス３のＦＣでは、通信に対してＡＣＫを返さない。このようなＡＣＫが存在しないクラス３のＦＣ－ＳＡＮの既存のプロトコルでは、連続して送信されるフレーム（データ）のうち、最終フレームがロストした場合、上位レイヤがタイムアウトすることによりエラーを検出している。その結果、上位レイヤがタイムアウトするまでの６０秒という非常に長い間、Ｉ／Ｏが停止していた。

このような問題に対して、特許第５８５２６７４号の技術を用いたとしても、経路の途中で最終フレームをロストした場合、writeハッシュ値とreadハッシュ値とを比較することが出来ず、上位レイヤがタイムアウトするまでの間フレームエラーを検出することが出来なかった。このように、連続してフレームを送信する際の最終フレームがロストした場合に、迅速にエラーを検出することが難しい、という課題が生じていた。

そこで、本発明の目的は、連続してフレームを送信する際の最終フレームがロストした場合に、迅速にエラーを検出することが難しい、という課題を解決する管理装置、管理方法、プログラム、情報処理装置を提供することにある。

かかる目的を達成するため本発明の一形態である管理装置は、
複数のフレームを送受信する通信を行うサーバ及びストレージと接続され、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
を有する
という構成をとる。

また、本発明の他の形態である管理方法は、
複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラが、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得し、
取得した前記受信情報に基づいて受信エラーが生じた通信を特定する
という構成をとる。

また、本発明の他の形態であるプログラムは、
複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラに、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
を実現するためのプログラムである。

また、本発明の他の形態である情報処理装置は、
複数のフレームを送受信する通信を複数行う情報処理装置であって、
フレームの受信エラーが生じた後に新たに受信したフレームを示す情報を受信情報として通知する通知部を有する
という構成をとる。

本発明は、以上のように構成されることにより、連続してフレームを送信する際の最終フレームがロストした場合に、迅速にエラーを検出することが難しい、という課題を解決する管理装置、管理方法、プログラム、情報処理装置を提供することが可能となる。

本発明の第１の実施形態における情報処理システムの全体の構成の一例を示す図である。 情報処理システムにおいて行われるクラス３のＦＣ通信の一例について示す図である。 図１で示すサーバの構成の一例を示すブロック図である。 図１で示すストレージの構成の一例を示すブロック図である。 図１で示すＦＣ－ＳＷの構成の一例を示すブロック図である。 図１で示す管理コントローラの構成の一例を示すブロック図である。 図６で示す管理テーブルの一例を示す図である。 管理テーブルにエントリを追加する際の一例を示す図である。 管理テーブルからエントリを削除する際の一例を示す図である。 エラーを検出する処理の一例を説明するための図である。 エラーを検出する処理の一例を説明するための図である。 エラーを検出する処理の一例を説明するための図である。 エラーを検出する処理の一例を説明するための図である。 エラーを検出する処理の一例を説明するための図である。 エラーを検出する処理の一例を説明するための図である。 エントリを追加する際の処理の一例を示すフローチャートである。 エントリを削除する際の処理の一例を示すフローチャートである。 エラーを検出する際の処理の一例を示すフローチャートである。 本発明の第２の実施形態における管理装置の構成の一例を示すブロック図である。

［第１の実施形態］
本発明の第１の実施形態を図１から図１８までを参照して説明する。図１は、情報処理システム１０の全体の構成の一例を示す図である。図２は、情報処理システム１０において行われるクラス３のＦＣ（Fibre Channel）通信の一例について示す図である。図３は、サーバ２０の構成の一例を示すブロック図である。図４は、ストレージ３０の構成の一例を示すブロック図である。図５は、ＦＣ－ＳＷ（switch）４０の構成の一例を示すブロック図である。図６は、管理コントローラ５０の構成の一例を示すブロック図である。図７は、管理テーブル５１の一例を示す図である。図８は、管理テーブル５１にエントリを追加する際の一例を示す図である。図９は、管理テーブル５１からエントリを削除する際の一例を示す図である。図１０から図１５までは、エラーを検出する処理の一例を説明するための図である。図１６は、エントリを追加する際の処理の一例を示すフローチャートである。図１７は、エントリを削除する際の処理の一例を示すフローチャートである。図１８は、エラーを検出する際の処理の一例を示すフローチャートである。

第１の実施形態では、サーバ２０とストレージ３０が、ＦＣ－ＳＷ４０を経由するファブリック接続により相互接続された情報処理システム１０について説明する。情報処理システム１０では、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０が、ＬＡＮ６２を経由して管理コントローラ５０に接続されている。後述するように、管理コントローラ５０は、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０のうちのいずれかからエラー通知を受信すると、サーバ２０、ストレージ３０に対して受信確認要求を発行する。また、サーバ２０とストレージ３０とは、受信確認要求の受付後にフレームを受信すると、受信したフレームに応じた受信確認通知を管理コントローラ５０に送信する。このような構成により、管理コントローラ５０は、サーバ２０やストレージ３０から受信確認通知を受信した結果として、受信確認通知を受信できない通信を判別することが出来る。その結果、管理コントローラ５０は、連続してフレームを送信する際の最終フレームがロストしていた場合でも、どの通信でエラーが発生したのか迅速に判断することが可能となる。

なお、ＦＣ通信では、エクスチェンジという単位で通信を実行する。また、エクスチェンジは、複数のシーケンスにより構成される。シーケンスは、１以上の任意の数のフレーム（データ）から構成することができ、各フレームには、送信対象のデータとフレームの番号を示すシーケンス番号（ＳＥＱ＿ＣＮＴ）などを含むフラグとを含むことが出来る。フラグには、例えば、エクスチェンジにおける最初のフレームであることを示す情報やエクスチェンジにおける最後のフレームであることを示す情報、シーケンスにおける最後のフレームであることを示す情報なども含むことが出来る。

図１は、情報処理システム１０の全体の構成の一例を示している。図１を参照すると、情報処理システム１０は、サーバ２０とストレージ３０とＦＣ－ＳＷ４０と管理コントローラ５０とを有している。サーバ２０とストレージ３０とは、ＦＣ６１とＦＣ－ＳＷ４０を介して、ファブリック接続により互いに通信可能なよう接続されている。また、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０のそれぞれは、ＬＡＮ６２を介して、互いに通信可能なよう管理コントローラ５０と接続されている。

なお、図１では、情報処理システム１０が２台のサーバ２０と２台のストレージ３０と１台のＦＣ－ＳＷ４０とを有する場合について例示している。しかしながら、情報処理システム１０が有するサーバ２０の数、ストレージ３０の数、ＦＣ－ＳＷ４０の数は、図１で例示する場合に限定されない。情報処理システム１０は、１台以上の任意の数のサーバ２０を有することが出来る。また、情報処理システム１０は、１台以上の任意の数のストレージ３０を有することが出来る。また、情報処理システム１０は、１台以上の任意の数のＦＣ－ＳＷ４０を有することが出来る。

本実施形態においては、情報処理システム１０は、クラス３のＦＣ－ＳＡＮ（Storage Area Network）を用いた通信を行う。ここで、一般的なクラス３のＦＣ通信の一例について、図２を参照して説明する。図２は、クラス３のＦＣ通信の一例を示している。図２を参照すると、サーバ２０は、エクスチェンジを開始する際、Ｆｉｒｓｔ＿ＳＥＱ＝１のフレームを送信する。つまり、サーバ２０は、エクスチェンジを開始する際、エクスチェンジにおける最初のフレームであることを示す情報を含むフレームを送信する。また、サーバ２０は、Ｌａｓｔ＿ＳＥＱ＝１のフレームをストレージ３０から受信することで、エクスチェンジの終了を認識することが出来る。つまり、サーバ２０は、エクスチェンジにおける最後のフレームであることを示す情報を含むフレームを受信することで、エクスチェンジの終了を認識する。

図２で示す場合において、例えば、ＳＥＱ＿ＣＮＴ＝１１のフレームにエラーが生じてストレージ３０に正常に届いていないとする。この場合、ストレージ３０は、ＳＥＱ＿ＣＮＴ＝１１のフレームを認識できない状態で、次のＳＥＱ＿ＣＮＴ＝１２のフレームを受信する。その結果、ストレージ３０は、ＳＥＱ＿ＣＮＴ＝１０のフレームの後にＳＥＱ＿ＣＮＴ＝１２のフレームを受信したと認識することとなる。これにより、ストレージ３０は、ＳＥＱ＿ＣＮＴ＝１１のフレームが欠落していることを検出することが出来る。このように、シーケンスの途中でフレームにエラーが生じた場合、後続のフレームを受信することによりフレームの番号に抜けが生じていることが判明するため、エラーを容易に検出できる。

一方、例えば、ＳＥＱ＿ＣＮＴ＝１２のフレームにエラーが生じた場合、次のフレームが存在しない。そのため、ストレージ３０は、エラー後のフレームを受信することができず、フレームの番号に抜けが生じていることを確認することが出来ない。このような場合、ストレージ３０で迅速にフレームの抜けを検出することができず、従来の方法だと、上位レイヤがタイムアウトすることによりエラーを検出していた。後述するように、本実施形態で説明する情報処理システム１０の場合、管理コントローラ５０を有することで、上記のような最終フレームが落ちた場合でも迅速にエラーを検出することを可能とする。

サーバ２０は、ストレージ３０との間でフレームの送受信を行う情報処理装置である。上述したように、サーバ２０とストレージ３０との間の通信は、エクスチェンジという単位で実行される。

図３は、本実施形態において特徴的なサーバ２０の構成の一例を示している。図３を参照すると、サーバ２０は、一般的なサーバが有する構成に加えて、例えば、エクスチェンジＩＤ登録部２１と、エクスチェンジＩＤ削除部２２と、エラー通知部２３と、受信確認通知送信部２４と、再送部２５と、を有している。

例えば、サーバ２０は、ＣＰＵなどの演算装置と記憶装置とを有している。サーバ２０は、例えば、記憶装置が記憶するプログラムを演算装置が実行することで、上述した各処理部を実現する。

エクスチェンジＩＤ登録部２１は、管理コントローラ５０が有する管理テーブル５１へのエントリの追加を要求する追加要求を管理コントローラ５０に対して発行する。

例えば、エクスチェンジＩＤ登録部２１は、サーバ２０がエクスチェンジの最初のフレームを送信する際にエントリの追加要求を管理コントローラ５０に対して発行する。具体的には、エクスチェンジＩＤ登録部２１は、エントリ追加コマンドとともに、送信元のサーバ２０自身のＩＰアドレス、フレームを送信するポートの識別情報であるＷＷＰＮ（World Wide Port Name）（Ｏ）、ストレージ３０がフレームを受信するポートの識別情報であるＷＷＰＮ（Ｒ）、送信するフレームのエクスチェンジＩＤ（エクスチェンジごとに異なる識別情報）、などを管理コントローラ５０に対して送信する。

なお、サーバ２０によるエクスチェンジの最初のフレームの送信と、エクスチェンジＩＤ登録部２１による追加要求の発行とは、いずれが先に行われても構わない。サーバ２０によるエクスチェンジの最初のフレームの送信と、エクスチェンジＩＤ登録部２１による追加要求の発行とは、並行して行われても構わない。

エクスチェンジＩＤ削除部２２は、管理テーブル５１のエントリ削除を要求するエントリの削除要求を管理コントローラ５０に対して発行する。

例えば、サーバ２０がエクスチェンジの最後のフレームを受信すると、エクスチェンジＩＤ削除部２２は、エントリの削除要求を管理コントローラ５０に対して発行する。具体的には、エクスチェンジＩＤ削除部２２は、エントリ削除コマンドとともに、送信元のサーバ２０自身のＩＰアドレスを送信する。なお、エクスチェンジＩＤ削除部２２は、エントリ削除コマンドとともに、送信元のサーバ２０自身のＩＰアドレスと削除対象のエクスチェンジＩＤとを送信するよう構成しても構わない。

エラー通知部２３は、ストレージ３０から受信したフレームにエラーが生じていた場合、管理コントローラ５０に対してエラーが生じた旨を示すエラー通知を送信する。

例えば、ストレージ３０から受信したフレームが壊れており、正常に読み取れなかった場合に、エラー通知部２３は、エラー通知を管理コントローラ５０に対して送信する。つまり、エラー通知部２３は、フレームを受信したものの正常に読み取れず、受信したフレームからエクスチェンジＩＤなどを判別できなかった場合などに、管理コントローラ５０に対してエラー通知を送信する。

受信確認通知送信部２４は、ストレージ３０からフレームを受信すると、フレームを受信したことを示す受信確認通知を管理コントローラ５０に対して送信する。受信確認通知送信部２４による受信確認通知の送信は、例えば、管理コントローラ５０から受信確認要求を受け付けた後に開始され、管理コントローラ５０から受信確認要求の解除通知を受信するまで続けられる。

例えば、サーバ２０が管理コントローラ５０から受信確認要求を受け付けた後、ストレージ３０からフレームを受信したとする。すると、受信確認通知送信部２４は、管理コントローラ５０に対して受信確認通知を送信する。具体的には、例えば、受信確認通知送信部２４は、受信確認通知として、受信したフレームのエクスチェンジＩＤと受信したポートのＷＷＰＮとを含む情報を管理コントローラ５０に対して送信する。なお、受信確認通知送信部２４は、受信確認通知として、上記情報のいずれかのみを送信するよう構成しても構わないし、上記例示した情報以外を加えて送信するよう構成しても構わない。

再送部２５は、管理コントローラ５０から再送の指示を受信した場合、当該再送の指示に応じたエクスチェンジの再送を行う。

ストレージ３０は、サーバ２０との間でフレームの送受信を行う情報処理装置である。上述したように、サーバ２０とストレージ３０との間の通信は、エクスチェンジという単位で実行される。

図４は、本実施形態において特徴的なストレージ３０の構成の一例を示している。図４を参照すると、ストレージ３０は、一般的なストレージが有する構成に加えて、例えば、エラー通知部３１と、受信確認通知送信部３２と、を有している。

例えば、ストレージ３０は、ＣＰＵなどの演算装置と記憶装置とを有している。ストレージ３０は、例えば、記憶装置が記憶するプログラムを演算装置が実行することで、上述した各処理部を実現する。

エラー通知部３１は、サーバ２０から受信したフレームにエラーが生じていた場合、管理コントローラ５０に対してエラーが生じた旨を示すエラー通知を送信する。

例えば、サーバ２０から受信したフレームが壊れており、正常に読み取れなかった場合に、エラー通知部３１は、エラー通知を管理コントローラ５０に対して送信する。つまり、エラー通知部３１は、フレームを受信したものの正常に読み取れず、受信したフレームからエクスチェンジＩＤなどを判別できなかった場合などに、管理コントローラ５０に対してエラー通知を送信する。

受信確認通知送信部３２は、サーバ２０からフレームを受信すると、フレームを受信したことを示す受信確認通知を管理コントローラ５０に対して送信する。受信確認通知送信部３２による受信確認通知の送信は、例えば、管理コントローラ５０から受信確認要求を受け付けた後に開始され、管理コントローラ５０から受信確認要求の解除通知を受信するまで続けられる。

例えば、ストレージ３０が管理コントローラ５０から受信確認要求を受け付けた後、サーバ２０からフレームを受信したとする。すると、受信確認通知送信部３２は、管理コントローラ５０に対して受信確認通知を送信する。具体的には、例えば、受信確認通知送信部３２は、受信確認通知として、受信したフレームのエクスチェンジＩＤと受信したポートのＷＷＰＮとを含む情報を管理コントローラ５０に対して送信する。なお、受信確認通知送信部３２は、受信確認通知として、上記情報のいずれかのみを送信するよう構成しても構わないし、上記例示した情報以外を加えて送信するよう構成しても構わない。

ＦＣ－ＳＷ４０は、サーバ２０とストレージ３０の間で行われるフレームの送受信を中継するスイッチである。

図５は、本実施形態において特徴的なＦＣ－ＳＷ４０の構成の一例を示している。図５を参照すると、ＦＣ－ＳＷ４０は、一般的なファイバチャネルスイッチが有する構成に加えて、例えば、エラー通知部４１を有している。

例えば、ＦＣ－ＳＷ４０は、ＣＰＵなどの演算装置と記憶装置とを有している。ＦＣ－ＳＷ４０６、例えば、記憶装置が記憶するプログラムを演算装置が実行することで、上述した処理部を実現する。

エラー通知部４１は、中継するフレームにフレームエラーが生じていた場合、管理コントローラ５０に対してエラーが生じた旨を示すエラー通知を送信する。

例えば、サーバ２０、ストレージ３０間を中継するフレームが壊れており、正常に読み取れなかった場合に、エラー通知部４１は、エラー通知を管理コントローラ５０に対して送信する。つまり、エラー通知部４１は、フレームを受信したものの正常に読み取れず、受信したフレームからエクスチェンジＩＤなどを判別できなかった場合などに、管理コントローラ５０に対してエラー通知を送信する。

管理コントローラ５０は、管理テーブル５１などの管理を行うことでエラーが生じた通信の特定を行う情報処理装置である。上述したように、管理コントローラ５０は、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０のそれぞれと接続されており、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０のそれぞれと通信を行うことが出来る。

図６は、本実施形態において特徴的な管理コントローラ５０の構成の一例を示している。図６を参照すると、管理コントローラ５０は、例えば、管理テーブル５１と、受信確認用管理テーブル５２と、管理テーブルエントリ追加部５３と、管理テーブルエントリ削除部５４と、エラー通知受信部５５と、受信確認通知要求部５６と、受信確認通知受信部５７と、エラーエクスチェンジ特定部５８と、再送要求部５９と、を有している。

例えば、管理コントローラ５０は、ＣＰＵなどの演算装置と記憶装置とを有している。管理コントローラ５０は、例えば、記憶装置が記憶するプログラムを演算装置が実行することで、上述した各処理部を実現する。

管理テーブル５１は、情報処理システム１０で実行中のエクスチェンジを示す情報を有している。図７は、管理テーブル５１の一例を示している。図７を参照すると、管理テーブル５１は、ＩＰアドレスと、ＷＷＰＮ（Ｏ）と、ＷＷＰＮ（Ｒ）と、エクスチェンジＩＤと、受信確認情報と、を対応づけている。

ここで、ＩＰアドレスはサーバ２０のＩＰアドレスである。また、ＷＷＰＮ（Ｏ）は、サーバ２０がフレームを送信するポートの識別情報（ＷＷＰＮ）である。また、ＷＷＰＮ（Ｒ）は、ストレージ３０がフレームを受信するポートの識別情報（ＷＷＰＮ）である。また、エクスチェンジＩＤは、エクスチェンジを識別するための情報である。また、受信確認情報は、受信確認要求後にサーバ２０又はストレージ３０がフレームを受信したか否かを示す情報である。受信確認情報は、例えば、初期値が「false」であり、フレームの受信が確認されることで「true」に変更される。

ＩＰアドレスと、ＷＷＰＮ（Ｏ）と、ＷＷＰＮ（Ｒ）と、エクスチェンジＩＤと、は、上述したように、サーバ２０のエクスチェンジＩＤ登録部２１からエントリの追加要求として送信される。また、受信確認情報の初期値「false」は、管理テーブルエントリ追加部５３がエントリの追加を行う際に初期値として設定する。

受信確認用管理テーブル５２は、管理テーブル５１をコピーすることで生成される。受信確認用管理テーブル５２は、エラー通知受信部５５がエラー通知を受信するたびに生成される。また、受信確認用管理テーブル５２は、エラーエクスチェンジ特定部５８がエラーの通信を特定した後、または、特定できないことを確認した後に、削除される。

上述したように、受信確認用管理テーブル５２は、エラー通知受信部５５がエラー通知を受信するたびに管理テーブル５１をコピーすることで生成される。そのため、受信確認用管理テーブル５２は複数生成されることがある。また、受信確認用管理テーブル５２は、受信確認通知要求部５６が管理テーブル５１をコピーする際の管理テーブル５１の状態に応じた情報を有する。そのため、前回管理テーブル５１をコピーしてから新たに管理テーブル５１をコピーするまでの間に新たにエントリが追加された場合などにおいて、受信確認用管理テーブル５２が有するエントリの数やエントリの情報などが異なる場合がある。つまり、受信確認用管理テーブル５２は、複数種類生成されることがある。

管理テーブルエントリ追加部５３は、エクスチェンジＩＤ登録部２１から受信したエントリの追加要求に応じて、管理テーブル５１にエントリの追加を行う。

例えば、管理コントローラ５０がサーバ２０のエクスチェンジＩＤ登録部２１から発行されたエントリの追加要求を受信すると、管理テーブルエントリ追加部５３は、受信した追加要求に応じたエントリを追加する。つまり、管理テーブルエントリ追加部５３は、管理テーブル５１に、サーバ２０から受信した追加要求に含まれるＩＰアドレス、ＷＷＰＮ（Ｏ）、ＷＷＰＮ（Ｒ）、エクスチェンジＩＤを保持するエントリを追加する。また、管理テーブルエントリ追加部５３は、エントリの受信確認情報のフィールドに初期値「false」をセットする。

なお、管理テーブルエントリ追加部５３によるエントリの追加結果は、例えば、既に作成されている受信確認用管理テーブル５２には反映されない。つまり、管理テーブルエントリ追加部５３が管理テーブルのエントリを追加しても、受信確認用管理テーブル５２のエントリは増えない。

管理テーブルエントリ削除部５４は、エクスチェンジＩＤ削除部２２から受信したエントリの削除要求に応じて、管理テーブル５１からエントリの削除を行う。

例えば、管理コントローラ５０がサーバ２０のエクスチェンジＩＤ削除部２２から発行されたエントリの削除要求を受信すると、管理テーブルエントリ削除部５４は、削除要求に含まれる情報が示すエントリを管理テーブル５１から検索して削除する。つまり、管理テーブルエントリ削除部５４は、管理テーブル５１から、削除要求に含まれるＩＰアドレス（または、ＩＰアドレスとエクスチェンジＩＤ）を有するエントリを削除する。

また、管理テーブルエントリ削除部５４は、管理テーブル５１からエントリを削除するとともに、受信確認用管理テーブル５２からも同一のＩＰアドレス（または、ＩＰアドレスとエクスチェンジＩＤ）を有するエントリを削除するよう構成することが出来る。これは、エクスチェンジＩＤ削除部２２からエントリの削除要求が発行された場合、エクスチェンジが無事に完了していることになるため、エラー検出の対象とする必要がないからである。

エラー通知受信部５５は、サーバ２０、ストレージ３０、ＦＣ－ＳＷ４０から、エラー通知を受信する。すると、エラー通知受信部５５は、エラー通知を受信した旨を受信確認通知要求部５６に通知する。

受信確認通知要求部５６は、サーバ２０とストレージ３０に対して、フレームを受信した場合に管理コントローラ５０まで受信確認通知の送信を要求する受信確認要求を発行する。例えば、受信確認通知要求部５６は、エラー通知受信部５５からエラー通知を受信した旨の通知を受けると、サーバ２０とストレージ３０に対して受信確認要求を発行する。また、受信確認通知要求部５６は、サーバ２０とストレージ３０に対して受信確認要求を発行するとともに、管理テーブル５１をコピーして受信確認用管理テーブル５２を生成する。

なお、エラー通知受信部５５が複数回エラー通知を受信した場合、受信確認通知要求部５６が既に受信確認要求を発行してサーバ２０やストレージ３０から受信確認通知が通知される状態にあることがある。このような場合、受信確認通知要求部５６は、サーバ２０とストレージ３０に対する新たな受信確認要求の発行を行わずに、管理テーブル５１のコピーのみを実行するよう構成しても構わない。

受信確認通知受信部５７は、サーバ２０やストレージ３０から受信確認通知を受信する。すると、受信確認通知受信部５７は、受信確認通知に応じたエントリの受信確認情報フィールドの値を、「false」から「true」に変更する。

具体的には、受信確認通知受信部５７が受信した受信確認通知には、フレームのエクスチェンジＩＤと受信したポートのＷＷＰＮ（サーバ２０の場合ＷＷＰＮ（Ｏ）、ストレージ３０の場合ＷＷＰＮ（Ｒ））とを示す情報が含まれている。そこで、受信確認通知受信部５７は、受信したエクスチェンジＩＤとＷＷＰＮとを用いて受信確認用管理テーブル５２を検索する。この際、受信確認通知受信部５７は、複数の受信確認用管理テーブル５２がある場合、それぞれの受信確認用管理テーブル５２を検索する。そして、受信確認通知受信部５７は、受信確認用管理テーブル５２のうち検索対象のエクスチェンジＩＤとＷＷＰＮとを有するエントリの受信確認情報フィールドの値が「false」の場合、受信確認情報フィールドの値を「true」に変更する。このような受信確認通知受信部５７の処理により、受信確認要求の発行後、サーバ２０やストレージ３０で新たに受信したフレームやエクスチェンジを管理コントローラ５０で管理することが出来る。

なお、受信確認通知は、サーバ２０やストレージ３０がフレームを受信することで送信される。そのため、受信確認通知受信部５７は、サーバ２０やストレージ３０がフレームを受信したことを示す受信情報として受信確認通知を受信する、ということも出来る。

エラーエクスチェンジ特定部５８は、受信確認用管理テーブル５２を参照することで、エラーの生じた通信を特定する。または、エラーエクスチェンジ特定部５８は、管理コントローラ５０では、エラーの生じた通信を特定できないことを確認する。

例えば、エラーエクスチェンジ特定部５８は、受信確認用管理テーブル５２を生成してから所定時間（例えば、１秒。そのほかの値でも構わない）経過した後に受信確認用管理テーブル５２を確認する。そして、エラーエクスチェンジ特定部５８は、受信確認情報フィールドの値が「false」になっているエントリを、エラーが生じたエントリであると特定する。このように、エラーエクスチェンジ特定部５８は、所定時間経過など所定の条件を満たした後の受信確認用管理テーブル５２の状態に応じて、エラーが生じた通信を特定する。換言すると、エラーエクスチェンジ特定部５８は、所定の条件を満たした後でも、サーバ２０やストレージ３０が新たなフレームを受信していないエクスチェンジにエラーが生じていると特定する。

なお、受信エラーがシーケンス途中のフレームで生じていた場合、エラーが生じたフレームに後続するフレームの通信が発生する。そのため、受信エラーがシーケンス途中のフレームで生じていた場合、受信確認用管理テーブル５２の受信確認情報フィールドの値はすべて「true」となる。このような場合、エラーエクスチェンジ特定部５８では、エラーの生じた通信を特定できない。そのため、エラーエクスチェンジ特定部５８は、エラーの生じた通信を特定できないことを確認して、エラーが生じた通信の特定は行わない。なお、このような場合、受信フレームのフレーム番号の不連続を、フレームを受信した装置で検出することが出来る。そのため、従来の方法でエラーの生じた通信を特定することが出来る。

また、エラーエクスチェンジ特定部５８は、エラーが生じた通信を特定した後、または、エラーの生じた通信を特定できないことを確認した後、エラーを特定した（または、特定できないことを確認した）受信確認用管理テーブル５２を削除する。また、エラーエクスチェンジ特定部５８は、受信確認用管理テーブル５２を削除した結果、受信確認用管理テーブル５２がなくなった場合、サーバ２０とストレージ３０に対して、受信確認要求の解除を指示する解除通知を送信する。

なお、エラーが生じた通信の特定をエラーエクスチェンジ特定部５８が行う際の条件は、受信確認用管理テーブル５２を生成してからの所定時間の経過に限定されない。例えば、エラーエクスチェンジ特定部５８は、受信確認情報フィールドの値が「false」であるエントリの数が１つになったなどの条件で、エラーが生じた通信を特定するよう構成しても構わない。また、エラーエクスチェンジ特定部５８は、最後に受信確認情報フィールドの値を「false」から「true」に変更してからの経過時間に応じて、エラーが生じた通信を特定するよう構成しても構わない。エラーエクスチェンジ特定部５８は、上記例示した条件を組み合わせても構わないし、それ以外の条件を用いても構わない。

再送要求部５９は、エラーが生じた通信をエラーエクスチェンジ特定部５８が特定した場合、エラーフレームの送信元に対して、エクスチェンジの再送を要求する再送要求を発行する。

続いて、図８から図１８までを参照して、情報処理システム１０で行われる各種動作について説明する。まず、図８、図１６を参照して、管理テーブル５１に新たなエントリを追加する処理の一例について説明する。なお、図８以下の説明では、説明を簡略化するため、ＦＣ－ＳＷ４０の記載を省略している。

図８では、ＩＰアドレスが「ＡＡＡ」であるサーバ２０からストレージ３０に対してエクスチェンジＩＤ「１」のフレーム送信を開始する際の一例を示している。また、図８では、サーバ２０のＷＷＰＮ（Ｏ）が「ＸＸＸ」であるポートからストレージ３０のＷＷＰＮ（Ｒ）が「ＹＹＹ」であるポートへとフレームの送信が行われる。

図８、図１６を参照すると、サーバ２０がエクスチェンジの最初のフレームを送信する際、エクスチェンジＩＤ登録部２１は、管理コントローラ５０に対して管理テーブル５１へのエントリの追加要求を発行する（図１６のステップＳ１０１）。具体的には、図８の場合、エクスチェンジＩＤ登録部２１は、エントリ追加コマンドとともに、ＩＰアドレス「ＡＡＡ」、ＷＷＰＮ（Ｏ）「ＸＸＸ」、ＷＷＰＮ（Ｒ）「ＹＹＹ」、エクスチェンジＩＤ「１」、を管理コントローラ５０に対して送信する。

管理コントローラ５０は、エントリの追加要求を受信する。すると、管理コントローラ５０の管理テーブルエントリ追加部５３は、エクスチェンジＩＤ登録部２１から受信したエントリの追加要求に応じてエントリを作成する（図１６のステップＳ２０１）。また、管理テーブルエントリ追加部５３は、エントリの受信確認情報のフィールドに初期値「false」をセットする（図１６のステップＳ２０２）。つまり、図８の場合、管理テーブルエントリ追加部５３は、管理テーブル５１に、ＩＰアドレス「ＡＡＡ」、ＷＷＰＮ（Ｏ）「ＸＸＸ」、ＷＷＰＮ（Ｒ）「ＹＹＹ」、エクスチェンジＩＤ「１」、受信確認情報「false」を保持するエントリを追加する。

以上が、管理テーブル５１に新たなエントリを追加する処理の一例である。続いて、図９、図１７を参照して、エントリを削除する際の処理の一例について説明する。

図９、図１７を参照すると、サーバ２０がエクスチェンジの最後のフレームを受信する（図１７のステップＳ３０１）。すると、エクスチェンジＩＤ削除部２２は、管理コントローラ５０に対して、後述する管理テーブル５１へのエントリの削除要求を発行する（図１７のステップＳ３０２）。具体的には、図９の場合、エクスチェンジＩＤ削除部２２は、エントリ削除コマンドとともに、ＩＰアドレス「ＡＡＡ」とエクスチェンジＩＤ「１」とを管理コントローラ５０に対して送信する。

管理コントローラ５０は、エントリの削除要求を受信する。すると、管理コントローラ５０の管理テーブルエントリ削除部５４は、エクスチェンジＩＤ削除部２２から受信したエントリの削除要求に応じてエントリを削除する（図１７のステップＳ４０１）。つまり、図９の場合、管理テーブルエントリ削除部５４は、管理テーブル５１のうちＩＰアドレス「ＡＡＡ」エクスチェンジＩＤ「１」であるエントリを削除する。

以上が、エントリを削除する際の処理の一例である。続いて、図１０から図１５までと図１８を参照して、エラーを検出する処理の一例について説明する。

図１０から図１５まででは、サーバ２０－１、サーバ２０－２の２台のサーバと、ストレージ３０－１、ストレージ３０－２の２台のストレージ３０との間でフレームを送信する場合について例示する。図１０で示す場合、サーバ２０－１からストレージ３０－２に対して、エクスチェンジＩＤ「１」のフレームを送信する。また、サーバ２０－２からストレージ３０－２に対して、エクスチェンジＩＤ「２」のフレームを送信する。また、ストレージ３０－１からサーバ２０－２に対して、エクスチェンジＩＤ「３」のフレームを送信する。

図１０は、エラー発生前の様子の一例を示している。図１０で示すように、ファブリックでは、エクスチェンジＩＤ「１」、「２」、「３」の３つの通信（エクスチェンジ）が実行されている。そのため、管理コントローラ５０が保持する管理テーブル５１には、３つのエントリが存在する。例えば、管理テーブル５１には、ＩＰアドレス「ＡＡＡ」、ＷＷＰＮ（Ｏ）「ＸＸＸ」、ＷＷＰＮ（Ｒ）「ＳＳＳ」、エクスチェンジＩＤ「１」、受信確認情報「false」のエントリと、ＩＰアドレス「ＢＢＢ」、ＷＷＰＮ（Ｏ）「ＹＹＹ」、ＷＷＰＮ（Ｒ）「ＴＴＴ」、エクスチェンジＩＤ「２」、受信確認情報「false」のエントリと、ＩＰアドレス「ＣＣＣ」、ＷＷＰＮ（Ｏ）「ＺＺＺ」、ＷＷＰＮ（Ｒ）「ＵＵＵ」、エクスチェンジＩＤ「３」、受信確認情報「false」のエントリと、がある。

このような状態で、図１１で示すようなエラーが生じたとする。図１１では、ストレージ３０－２で受信エラーが生じた場合について例示している。図１１で示す場合、ストレージ３０－２は、壊れたフレームのエクスチェンジが何であるのか判別できない、何らかの壊れたフレームを受信する。そこで、ストレージ３０－２のエラー通知部３１は、管理コントローラ５０に対して、エラー通知を送信する（図１８のステップＳ５０１）。

管理コントローラ５０のエラー通知受信部５５は、ストレージ３０からエラー通知を受信する。すると、エラー通知受信部５５は、エラー通知を受信した旨を受信確認通知要求部５６に通知する。

図１２は、受信確認通知要求部５６がエラー通知受信部５５からエラー通知を受信した旨の通知を受け取った際の処理の一例を示している。図１２を参照すると、受信確認通知要求部５６は、エラー通知を受信した旨の通知をエラー通知受信部５５から受信すると、管理テーブル５１をコピーして受信確認用管理テーブル５２を生成する（図１８のステップＳ６０１）。これにより、図１０を参照して説明した各エントリを有する管理テーブル５１のコピーが生成される。また、受信確認通知要求部５６は、サーバ２０とストレージ３０に対して、受信確認要求を発行する（図１８のステップＳ６０２）。

なお、ステップＳ６０１の処理とステップＳ６０２の処理は、いずれを先に行っても構わない。また、ステップＳ６０１の処理とステップＳ６０２の処理は、並行して行われても構わない。

図１３は、サーバ２０－１、サーバ２０－２、ストレージ３０－１、ストレージ３０－２のそれぞれが受信確認要求を受け付けた後の状態の一例を示している。図１３では、ストレージ３０－２は、受信確認要求を受け付けた後、エクスチェンジＩＤ「２」のフレームを受信している。また、サーバ２０－２は、受信確認要求を受け付けた後、エクスチェンジＩＤ「３」のフレームを受信している。

図１３を参照すると、ストレージ３０－２の受信確認通知送信部３２は、エクスチェンジＩＤ「２」のフレームを受信する（図１８のステップＳ５０２、Ｙｅｓ）と、管理コントローラ５０に対して受信確認通知を送信する（図１８のステップＳ５０３）。具体的には、例えば、受信確認通知送信部３２は、受信確認通知として、エクスチェンジＩＤ「２」と受信したポートのＷＷＰＮとを含む情報を管理コントローラ５０に対して送信する。

また、サーバ２０－２の受信確認通知送信部２４は、エクスチェンジＩＤ「３」のフレームを受信する（図１８のステップＳ７０１、Ｙｅｓ）と、管理コントローラ５０に対して受信確認通知を送信する（図１８のステップＳ７０２）。具体的には、例えば、受信確認通知送信部２４は、受信確認通知として、エクスチェンジＩＤ「３」と受信したポートのＷＷＰＮとを含む情報を管理コントローラ５０に対して送信する。

また、管理コントローラ５０の受信確認通知受信部５７は、サーバ２０やストレージ３０から受信確認通知を受信する。すると、受信確認通知受信部５７は、受信確認通知に応じたエントリの受信確認情報フィールドの値を、「false」から「true」に変更する（図１８のステップＳ６０３）。その結果、図１３で示すように、エクスチェンジＩＤ「２」とエクスチェンジＩＤ「３」のエントリの受信確認情報フィールドの値は、「true」になる。

図１４で示すように、エクスチェンジＩＤ「１」は次のフレームが送信されない。そのため、ストレージ３０－２からエクスチェンジＩＤ「１」の受信確認通知は送信されない。その結果、エラーエクスチェンジ特定部５８は、例えば、所定時間（例えば、１秒）経過した後（図１８のステップＳ６０４、Ｙｅｓ）に受信確認用管理テーブル５２を確認する。そして、「false」のフィールドがある場合（図１８のステップＳ６０５）、エラーエクスチェンジ特定部５８は、受信確認情報フィールドの値が「false」になっているエントリを、エラーが生じたエントリであると特定する（図１８のステップＳ６０６）。これにより、再送要求部５９は、サーバ２０－１に対して、エクスチェンジＩＤ「１」の再送を要求する。

図１４で示す場合、エクスチェンジＩＤ「１」のエントリの受信確認情報フィールドの値が「false」のままとなる。そのため、エラーエクスチェンジ特定部５８は、エクスチェンジＩＤ「１」の通信にエラーが生じたと特定する。

また、エラーエクスチェンジ特定部５８は、エラーが生じた通信を特定した後、エラーを特定した受信確認用管理テーブル５２を削除する。また、エラーエクスチェンジ特定部５８は、サーバ２０とストレージ３０に対して、受信確認要求の解除を指示する解除通知を送信する（図１８のステップＳ６０７）。

なお、受信エラーがシーケンス途中のフレームで生じていた場合、図１５で示すように、エラーが生じたフレームに後続するフレームの通信が発生する。そのため、図１５の場合、エクスチェンジＩＤ「１」の受信確認情報フィールドの値も「true」となる。このような場合、受信確認情報フィールドの値が「false」のエントリはない（図１８のステップＳ６０５、Ｎｏ）ため、エラーエクスチェンジ特定部５８では、エラーの生じた通信を特定できない。そのため、エラーエクスチェンジ特定部５８は、エラーの生じた通信を特定できないことを確認して、エラーが生じた通信の特定は行わない。この場合、再送要求部５９による再送指示は行われず、エラーエクスチェンジ特定部５８による受信確認用管理テーブル５２の削除と受信確認要求の解除が行われる。

このように、管理コントローラ５０は、エラー通知受信部５５と、受信確認通知要求部５６と、受信確認通知受信部５７と、エラーエクスチェンジ特定部５８と、を有している。このような構成により、受信確認通知要求部５６は、エラー通知受信部５５が受信したエラー通知に応じて、サーバ２０とストレージ３０に対して受信確認要求を発行することが出来る。また、受信確認通知受信部５７は、受信した受信確認通知に応じて、受信確認要求の発行後に新たに受信したフレームやエクスチェンジを管理することが出来る。その結果、エラーエクスチェンジ特定部５８は、エラーの生じた通信を特定することが出来る。つまり、上記構成によると、上記レイヤによるタイムアウトを待つことなく、迅速にエラーの生じた通信を特定することが可能となる。

また、本実施形態の場合、受信確認通知要求部５６は、エラー通知を受信した旨の通知をエラー通知受信部５５から受信すると、管理テーブル５１をコピーして受信確認用管理テーブル５２を生成する。これにより、受信確認通知受信部５７は、受信確認用管理テーブル５２を用いた管理を行うことが出来る。その結果、例えば、エラーが連続したなどエラーの確認中に新たなエラーが生じた場合でも、エラーが発生した通信それぞれを特定することが可能となる。

なお、情報処理システム１０の構成は本実施形態で説明した場合に限定されない。例えば、本実施形態において説明した管理コントローラ５０の機能の少なくとも一部をサーバ２０やストレージ３０が有するなど、適宜変更例を選択して構わない。

［第２の実施形態］
次に、図１９を参照して、本発明の第２の実施形態について説明する。第２の実施形態では、管理装置７０の構成の概要について説明する。

管理装置７０は、複数のフレームを送受信する通信を行うサーバ及びストレージと接続される。図１９は、管理装置７０の構成の一例を示している。図１９を参照すると、管理装置７０は、取得部７１と、特定部７２と、を有している。

管理装置７０は、例えば、ＣＰＵなどの演算装置と記憶装置とを有している。例えば、管理装置７０は、記憶装置が記憶するプログラムを演算装置が実行することで、上述した各種処理部を実現する。

取得部７１は、フレームの受信エラーが生じた後にサーバ又はストレージでフレームを受信した旨を示す受信情報を取得する。取得部７１は、例えば、サーバ又はストレージが送信した受信情報を受信することで、受信情報を取得する。取得部７１は、上記例示した以外の方法により受信情報を取得しても構わない。

特定部７２は、取得部７１が取得した受信情報に基づいて受信エラーが生じた通信を特定する。

このように、管理装置７０は、取得部７１と特定部７２とを有している。このような構成によると、取得部７１は、受信情報を取得することが出来る。その結果、特定部７２は、取得部７１が取得した受信情報に基づいて受信エラーが生じた通信を特定することが出来る。つまり、連続してフレームを送信する際の最終フレームがロストした場合でも迅速にエラーを検出することが出来る。

また、上述した管理装置７０は、当該管理装置７０に所定のプログラムが組み込まれることで実現できる。具体的に、本発明の他の形態であるプログラムは、複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラに、フレームの受信エラーが生じた後にサーバ又はストレージでフレームを受信した旨を示す受信情報を取得する取得部７１と、取得部７１が取得した受信情報に基づいて受信エラーが生じた通信を特定する特定部７２と、を実現するためのプログラムである。

また、上述した管理装置７０により実行される管理方法は、複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラが、フレームの受信エラーが生じた後にサーバ又はストレージでフレームを受信した旨を示す受信情報を取得し、取得した受信情報に基づいて受信エラーが生じた通信を特定する、という方法である。

上述した構成を有する、プログラム、又は、管理方法、の発明であっても、上記管理装置７０と同様の作用・効果を有するために、上述した本発明の目的を達成することが出来る。

＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明における管理装置などの概略を説明する。但し、本発明は、以下の構成に限定されない。

（付記１）
複数のフレームを送受信する通信を行うサーバ及びストレージと接続され、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
を有する
管理装置。
（付記２）
付記１に記載の管理装置であって、
前記特定部は、前記受信情報に基づいて、フレームの受信エラーが生じた後に新たにフレームを受信していない通信に受信エラーが生じたと特定する
管理装置。
（付記３）
付記１または付記２に記載の管理装置であって、
前記特定部は、前記受信情報に基づいて、フレームの受信エラーが生じた後に、実行中の全ての通信で新たなフレームを受信した場合、受信エラーが生じた通信を特定しない
管理装置。
（付記４）
付記１から付記３までのいずれか１項に記載の管理装置であって、
前記サーバ又は前記ストレージから、前記サーバ又は前記ストレージで受信エラーが生じた旨を示すエラー通知を受信するエラー通知受信部と、
受信したエラー通知に応じて、前記サーバと前記ストレージに対して、フレームを受信した場合に受信確認を送信するよう要求する受信確認要求を発行する受信確認要求部と、
を有し、
前記取得部は、前記受信確認要求部が発行した前記受信確認要求に応じて送信される前記受信確認を前記受信情報として取得する
管理装置。
（付記５）
付記４に記載の管理装置であって、
前記管理装置は、前記サーバと前記ストレージとの間の通信を中継する中継装置と接続され、
前記エラー通知受信部は、前記中継装置から前記エラー通知を受信する
管理装置。
（付記６）
付記４又は付記５に記載の管理装置であって、
実行中の通信を示す情報を有する管理テーブルを有し、
前記特定部は、前記受信情報と前記管理テーブルが示す情報とに基づいて受信エラーが生じた通信を特定する
管理装置。
（付記７）
付記６に記載の管理装置であって、
前記管理テーブルは、前記エラー通知受信部が前記エラー通知を受信するたびにコピーされ、
前記特定部は、前記受信情報と前記管理テーブルをコピーした結果が示す情報とに基づいて受信エラーが生じた通信を特定する
管理装置。
（付記８）
付記７に記載の管理装置であって、
前記サーバ又は前記ストレージから、実行中の通信が完了した旨を示す情報を取得すると、前記管理テーブルと前記管理テーブルをコピーした結果とから完了した通信を示す情報を削除する削除部を有する
管理装置。
（付記９）
付記１から付記８までのいずれか１項に記載の管理装置であって、
受信エラーが生じた通信を特定した場合に、前記サーバ又は前記ストレージに対して通信の再送を要求する再送要求部を有する
管理装置。
（付記１０）
複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラに、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
を実現するためのプログラム。
（付記１１）
複数のフレームを送受信する通信を行うサーバ及びストレージと接続される管理コントローラが、
フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得し、
取得した前記受信情報に基づいて受信エラーが生じた通信を特定する
管理方法。
（付記１２）
複数のフレームを送受信する通信を複数行う情報処理装置であって、
フレームの受信エラーが生じた後に新たに受信したフレームを示す情報を受信情報として通知する通知部を有する
情報処理装置。

なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されていたりする。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。

以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。

１０ 情報処理システム
２０ サーバ
２１ エクスチェンジＩＤ登録部
２２ エクスチェンジＩＤ削除部
２３ エラー通知部
２４ 受信確認通知部
２５ 再送部
３０ ストレージ
３１ エラー通知部
３２ 受信確認通知部
４０ ＦＣ－ＳＷ
４１ エラー通知部
５０ 管理コントローラ
５１ 管理テーブル
５２ 受信確認用管理テーブル
５３ 管理テーブルエントリ追加部
５４ 管理テーブルエントリ削除部
５５ エラー通知受信部
５６ 受信確認要求部
５７ 受信確認受信部
５８ エラーエクスチェンジ特定部
５９ 再送要求部
６１ ＦＣ
６２ ＬＡＮ
７０ 管理装置
７１ 取得部
７２ 特定部

Claims (3)

1. 複数のフレームを送受信する通信を行うサーバ及びストレージと接続され、
   フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
   前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
   実行中の通信を示す情報を有する管理テーブルと、
   を有し、
   前記特定部は、前記受信情報と前記管理テーブルが示す情報とに基づいて最終フレームの受信エラーが生じた通信を特定し、
   前記特定部は、前記受信情報に基づいて、フレームの受信エラーが生じた後に、実行中の全ての通信で新たなフレームを受信した場合、受信エラーが生じた通信を特定しない
   管理装置。
2. 複数のフレームを送受信する通信を行うサーバ及びストレージと接続され、
   フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
   前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
   を有し、
   前記特定部は、前記受信情報に基づいて、フレームの受信エラーが生じた後に、実行中の全ての通信で新たなフレームを受信した場合、受信エラーが生じた通信を特定しない
   管理装置。
3. 複数のフレームを送受信する通信を行うサーバ及びストレージと接続され、
   フレームの受信エラーが生じた後に前記サーバ又は前記ストレージでフレームを受信した旨を示す受信情報を取得する取得部と、
   前記取得部が取得した前記受信情報に基づいて受信エラーが生じた通信を特定する特定部と、
   前記サーバ又は前記ストレージから、前記サーバ又は前記ストレージで受信エラーが生じた旨を示すエラー通知を受信するエラー通知受信部と、
   受信したエラー通知に応じて、前記サーバと前記ストレージに対して、フレームを受信した場合に受信確認を送信するよう要求する受信確認要求を発行する受信確認要求部と、
   を有し、
   前記取得部は、前記受信確認要求部が発行した前記受信確認要求に応じて送信される前記受信確認を前記受信情報として取得する
   管理装置。

Images