特許 7553206 ストレージシステム及びストレージシステムにおけるＩ／Ｏリクエスト処理方法

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

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

(11)【特許番号】

(24)【登録日】2024-09-09

(45)【発行日】2024-09-18

(54)【発明の名称】ストレージシステム及びストレージシステムにおけるＩ／Ｏリクエスト処理方法

(51)【国際特許分類】

   G06F 13/10 20060101AFI20240910BHJP

   G06F 3/06 20060101ALI20240910BHJP

【ＦＩ】

G06F13/10 330C

G06F3/06 301F

G06F13/10 340A

【請求項の数】 8

(21)【出願番号】P 2023029495

(22)【出願日】2023-02-28

(65)【公開番号】P2024122129

(43)【公開日】2024-09-09

【審査請求日】2023-08-04

(73)【特許権者】

【識別番号】524132520

【氏名又は名称】日立ヴァンタラ株式会社

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】中浜 慧

(72)【発明者】

【氏名】揚妻 匡邦

(72)【発明者】

【氏名】鈴木 啓介

(72)【発明者】

【氏名】宮田 裕章

(72)【発明者】

【氏名】勝長 達平

【審査官】豊田 真弓

(56)【参考文献】

【文献】特開２０１６－５７８７６（ＪＰ，Ａ）

【文献】特開２００５－２７６１３５（ＪＰ，Ａ）

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

【文献】特開２０２３－０１５４８８（ＪＰ，Ａ）

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

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

Ｇ０６Ｆ １３／１０

Ｇ０６Ｆ ３／０６

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

【請求項1】

クラウドベースのストレージであるクラウドストレージと、該クラウドストレージに対するＩ／Ｏリクエストを処理するストレージノードと、を有するストレージシステムであって、
前記ストレージノードのプロセッサは、
前記Ｉ／Ｏリクエスト及び該Ｉ／Ｏリクエストに対して前記クラウドストレージから送信されたＩ／Ｏ応答に係る処理に用いる情報及びバッファを含むＩ／Ｏ資源を保持するＩ／Ｏ処理スレッドと、応答待機処理スレッドと、を実行し、
前記プロセッサは、
前記Ｉ／Ｏ処理スレッドによって、
ホストからの要求に応じて前記クラウドストレージに対して前記Ｉ／Ｏリクエストを送信し、
前記Ｉ／Ｏリクエストを前記クラウドストレージに対して送信してから第１のタイムアウト時間が経過するまで、該Ｉ／Ｏリクエストに対する前記Ｉ／Ｏ応答の受信を待機する待機処理を行い、
前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信した場合に、該Ｉ／Ｏ応答を前記ホストに転送し、
前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信しなかった場合に、前記Ｉ／Ｏ資源を前記応答待機処理スレッドに移動させて保持させ、
前記応答待機処理スレッドによって、
前記Ｉ／Ｏ処理スレッドから移動され前記応答待機処理スレッドに保持される前記Ｉ／Ｏ資源を用いて、前記クラウドストレージに対して前記Ｉ／Ｏ応答を要求する応答確認を送信し、前記Ｉ／Ｏ処理スレッドに代えて前記待機処理を行う
ことを特徴とするストレージシステム。

【請求項2】

請求項１に記載のストレージシステムであって、
前記プロセッサは、
前記Ｉ／Ｏ処理スレッドによって前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信しなかった場合に、
前記クラウドストレージの状態を、新規の前記Ｉ／Ｏリクエストを受け付け可能な通常状態から、新規の前記Ｉ／Ｏリクエストを受け付け不可能かつ前記応答確認のみ受け付け可能な仮閉塞状態に移行させる
ことを特徴とするストレージシステム。

【請求項3】

請求項２に記載のストレージシステムであって、
前記プロセッサは、
前記クラウドストレージの状態を前記仮閉塞状態にした回数を計測し、
前記回数が上限回数に到達した場合に、前記クラウドストレージを前記ストレージシステムから切り離す
ことを特徴とするストレージシステム。

【請求項4】

請求項２に記載のストレージシステムであって、
前記プロセッサは、
前記応答待機処理スレッドによって、
前記応答確認を前記クラウドストレージに対して送信してから第２のタイムアウト時間が経過するまで前記待機処理を行い、
前記第２のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信した場合に、
受信した前記Ｉ／Ｏ応答を前記ホストに転送し、
前記応答待機処理スレッドに保持される該Ｉ／Ｏ応答に係る前記Ｉ／Ｏ資源を開放する
ことを特徴とするストレージシステム。

【請求項5】

請求項４に記載のストレージシステムであって、
前記プロセッサは、
前記応答待機処理スレッドによって前記第２のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信した場合に、
前記クラウドストレージの状態を、前記仮閉塞状態から前記通常状態に移行させ、
前記クラウドストレージのデータを復元する差分リビルド処理を実行する
ことを特徴とするストレージシステム。

【請求項6】

請求項４に記載のストレージシステムであって、
前記プロセッサは、
前記応答待機処理スレッドによって前記第２のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信しなかった場合に、
前記クラウドストレージの状態を、前記仮閉塞状態から、前記Ｉ／Ｏリクエスト及び前記応答確認を受け付け不可能な閉塞状態に移行させ、
前記応答待機処理スレッドに保持される前記Ｉ／Ｏ応答に係る前記Ｉ／Ｏ資源を開放する
ことを特徴とするストレージシステム。

【請求項7】

請求項１に記載のストレージシステムであって、
前記応答待機処理スレッドは、待機リクエストキューと、待機リソースキューと、を有し、
前記プロセッサは、
前記応答待機処理スレッドによって、
前記Ｉ／Ｏ処理スレッドから移動された前記Ｉ／Ｏ資源を前記待機リクエストキューに保持し、
前記待機リクエストキューから前記待機リソースキューに前記Ｉ／Ｏ資源を移動させて、該Ｉ／Ｏ資源を用いる前記Ｉ／Ｏ応答に係る前記待機処理を実行する
ことを特徴とするストレージシステム。

【請求項8】

クラウドベースのストレージであるクラウドストレージと、該クラウドストレージに対するＩ／Ｏリクエストを処理するストレージノードと、を有するストレージシステムが実行するストレージシステムにおけるＩ／Ｏリクエスト処理方法であって、
前記ストレージノードのプロセッサは、
前記Ｉ／Ｏリクエスト及び該Ｉ／Ｏリクエストに対して前記クラウドストレージから送信されたＩ／Ｏ応答に係る処理に用いる情報及びバッファを含むＩ／Ｏ資源を保持するＩ／Ｏ処理スレッドと、応答待機処理スレッドと、を実行し、
前記プロセッサが、
前記Ｉ／Ｏ処理スレッドによって、
ホストからの要求に応じて前記クラウドストレージに対して前記Ｉ／Ｏリクエストを送信し、
前記Ｉ／Ｏリクエストを前記クラウドストレージに対して送信してから第１のタイムアウト時間が経過するまで、該Ｉ／Ｏリクエストに対する前記Ｉ／Ｏ応答の受信を待機する待機処理を行い、
前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信した場合に、該Ｉ／Ｏ応答を前記ホストに転送し、
前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信しなかった場合に、前記Ｉ／Ｏ資源を前記応答待機処理スレッドに移動させて保持させ、
前記応答待機処理スレッドによって、
前記Ｉ／Ｏ処理スレッドから移動され前記応答待機処理スレッドに保持される前記Ｉ／Ｏ資源を用いて、前記クラウドストレージに対して前記Ｉ／Ｏ応答を要求する応答確認を送信し、前記Ｉ／Ｏ処理スレッドに代えて前記待機処理を行う
ことを特徴とするストレージシステムにおけるＩ／Ｏリクエスト処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストレージシステム及びストレージシステムにおけるＩ／Ｏリクエスト処理方法に関する。

【背景技術】

【0002】

近年、パブリッククラウド、プライベートクラウド、及びオンプレミスの各環境を組合せて利用するハイブリッドクラウドが普及しつつある。例えばパブリッククラウドに構築したクラウドベースのストレージであるクラウドストレージと、プライベートクラウド又はオンプレミスに構築したホストとを含んで構成されたシステムがある。かかるシステムにおいて、クラウドストレージは、ホストからのＩ／Ｏ（Input／Output）要求に対してＩ／Ｏ応答の遅延を生じやすく、Ｉ／Ｏ応答のタイムアウトの発生によりＩ／Ｏ性能が低下する場合がある。

【0003】

そこで特許文献１に開示されるように、ホストからのＩ／Ｏリクエストに対してクラウドストレージからのＩ／Ｏ応答が遅延する際、ホストに対するＩ／Ｏ応答のタイムアウト前にホストにＩ／Ｏを再発行させてタイムアウトを抑止する技術が考案されている。

【先行技術文献】

【特許文献】

【0004】

【文献】米国特許第１０４８１８０５号明細書

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかし、上述の従来技術では、ホストに対するＩ／Ｏ応答のタイムアウトを抑止できるものの、Ｉ／Ｏリクエストのタイムアウトの抑止中は他のＩ／Ｏリクエストが受け付けられず待機状態となるため、Ｉ／Ｏ性能が低下してしまうという問題があった。

【0006】

本発明の目的は、上述の従来技術の課題を考慮し、クラウドストレージにおいて、ホストからのＩ／Ｏリクエストに対するＩ／Ｏ応答のタイムアウトを抑止しつつＩ／Ｏ性能の低下を抑制することである。

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

【0007】

かかる課題を解決するため本発明の一態様では、クラウドベースのストレージであるクラウドストレージと、該クラウドストレージに対するＩ／Ｏリクエストを処理するストレージノードと、を有するストレージシステムであって、前記ストレージノードのプロセッサは、前記Ｉ／Ｏリクエスト及び該Ｉ／Ｏリクエストに対して前記クラウドストレージから送信されたＩ／Ｏ応答に係る処理に用いる情報及びバッファを含むＩ／Ｏ資源を保持するＩ／Ｏ処理スレッドと、応答待機処理スレッドと、を実行し、前記プロセッサは、前記Ｉ／Ｏ処理スレッドによって、ホストからの要求に応じて前記クラウドストレージに対して前記Ｉ／Ｏリクエストを送信し、前記Ｉ／Ｏリクエストを前記クラウドストレージに対して送信してから第１のタイムアウト時間が経過するまで、該Ｉ／Ｏリクエストに対する前記Ｉ／Ｏ応答の受信を待機する待機処理を行い、前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信した場合に、該Ｉ／Ｏ応答を前記ホストに転送し、前記第１のタイムアウト時間が経過するまでに前記クラウドストレージから前記Ｉ／Ｏ応答を受信しなかった場合に、前記Ｉ／Ｏ資源を前記応答待機処理スレッドに移動させて保持させ、前記応答待機処理スレッドによって、前記Ｉ／Ｏ処理スレッドから移動され前記応答待機処理スレッドに保持される前記Ｉ／Ｏ資源を用いて、前記クラウドストレージに対して前記Ｉ／Ｏ応答を要求する応答確認を送信し、前記Ｉ／Ｏ処理スレッドに代えて前記待機処理を行うことを特徴とする。

【発明の効果】

【0008】

本発明によれば、クラウドストレージにおいて、ホストからのＩ／Ｏリクエストに対するＩ／Ｏ応答のタイムアウトを抑止しつつＩ／Ｏ性能の低下を抑制できる。

【図面の簡単な説明】

【0009】

【図1】ストレージシステムの構成の一例を示す図。

【図2】ストレージノードの構成の一例を示す図。

【図3】ストレージノードのメモリの構成の一例を示す図。

【図4】ストレージノードの機能構成の一例と、実施形態の概要を示す図。

【図5】待機リクエストキューテーブルの構成の一例を示す図。

【図6】待機リソースキューテーブルの構成の一例を示す図。

【図7】Ｉ／Ｏ処理スレッドテーブルの構成の一例を示す図。

【図8】応答待機処理スレッドテーブルの構成の一例を示す図。

【図9】クラウドストレージ状態管理テーブルの構成の一例を示す図。

【図10】クラウドストレージの状態遷移の一例を示す図。

【図11】リビルド要求フラグテーブルの構成の一例を示す図。

【図12】クラウドストレージの応答タイムアウト時間テーブルの構成の一例を示す図。

【図13】クラウドストレージ仮閉塞回数テーブルの構成の一例を示す図。

【図14】クラウドストレージ仮閉塞上限回数テーブルの構成の一例を示す図。

【図15】Ｉ／Ｏリクエスト処理の一例を示すシーケンス図。

【図16】リビルド処理の一例を示すフローチャート。

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

【0010】

以下、図面を参照して本願開示に係る一実施形態を説明する。実施形態は、図面も含めて本願を説明するための例示である。実施形態では、説明の明確化のため、適宜、省略及び簡略化がされている。特に限定しない限り、実施形態の構成要素は単数でも複数でもよい。また、ある実施形態と他の実施形態を組み合わせた形態も、本願開示に係る実施形態に含まれる。

【0011】

以下の説明では、同一又は類似の構成要素には、同一の符号を付与し、後出の実施形態及び実施例では、説明を省略する、又は差分を中心とした説明のみを行う場合がある。また、同一又は類似の構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。また、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。各構成要素の数は、特に断りがない限り単数でも複数でもよい。

【0012】

以下の説明では、テーブルやキュー等の形式で各種情報を説明するが、各種情報はテーブルやキュー以外のデータ構造で表現されていてもよい。「ＸＸテーブル」や「ＸＸキュー」等は、データ構造に依存しないため、「ＸＸ情報」と呼ぶことができる。各種情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらは互換可能である。

【0013】

実施形態において、プログラムが行う処理について説明する場合がある。コンピュータは、プロセッサ（例えばＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit））により、主記憶装置のメモリ等を用いながら、プログラムで定められた処理を行う。そのため、プログラムを実行して行う処理の主体を、プロセッサとしてもよい。プロセッサがプログラムを実行することで、処理を行う機能部が実現される。

【0014】

同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であればよく、特定の処理を行う専用回路を含んでいてもよい。専用回路は、例えばＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等である。

【0015】

プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読取り可能な非一時的な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源（ストレージ）を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、実施形態において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

【0016】

（ストレージシステムＳの構成）
図１は、ストレージシステムＳの構成の一例を示す図である。ストレージシステムＳは、ストレージノード１、クラウドストレージ２、ホスト３、及び管理サーバ４を含んで構成される。ストレージノード１、クラウドストレージ２、及びホスト３のそれぞれの数は、任意である。

【0017】

ストレージノード１は、ホスト型、ハイパーバイザ型、コンテナ型等の仮想マシンで構成した仮想サーバであり、クラウドストレージ２上のデータのＩ／Ｏ及び管理に係る処理を行う各種プロセスを実行する。ストレージノード１同士は、Internode-Subnetを介して接続されている。

【0018】

クラウドストレージ２は、クラウド環境に構築されたクラウドベースの不揮発ストレージであり、仮想ボリューム又は物理ディスクを含んで構成される。各ストレージノード１には、１又は複数のクラウドストレージ２が接続されており、各ストレージクラスタが構成されている。

【0019】

ホスト３は、クラウドストレージ２に対するＩ／Ｏリクエストを、ネットワークＮ（Compute-Subnet）を介して送信する。ホスト３は、Ｉ／Ｏリクエストに対するＩ／Ｏ応答を、ネットワークＮ（Compute-Subnet）を介してクラウドストレージ２から受信する。

【0020】

管理サーバ４は、管理者が、ネットワークＮ（Management-Subnet）又は管理用ネットワーク（不図示）を介してストレージノード１及びクラウドストレージ２の保守管理等を行うためのサーバである。管理サーバ４は、クラウドストレージ２と直接接続されていてもよい。

【0021】

なお上述のCompute-Subnet、Internode-Subnet、及びManagement-Subnetは、同一でも異なっていてもよい。またCompute-Subnet、Internode-Subnet、及びManagement-Subnetは、Ethernet（登録商標、以下同様）／InfiniBand（登録商標、以下同様）／無線の何れでもよい。またネットワーク網や通信線は、冗長化されていてもよい。

【0022】

（ストレージノード１の構成）
図２は、ストレージノード１の構成の一例を示す図である。ストレージノード１は、プロセッサ１１、メモリ１２、ストレージ１３、及び通信インターフェース１４を含んで構成される。プロセッサ１１は、ストレージ１３からプログラムを読み出し、メモリ１２と協働して後述の各スレッド及び処理機能部を実現する。

【0023】

通信インターフェース１４は、１つ以上のＨＢＡ（Host Bus Adapter）と、１つ以上のＮＩＣ（Network Interface Card）を含む。ＨＢＡは、データサービスネットワーク（Fiber Channel／Ethernet／InfiniBand等の何れか）の通信インターフェースである。ＮＩＣは、バックエンドネットワーク（上述のCompute-Subnet、Internode-Subnetに該当し、Fiber Channel／Ethernet／InfiniBand等の何れでもよい）の通信インターフェースである。

【0024】

（ストレージノードのメモリの構成）
図３は、ストレージノード１のメモリ１２の構成の一例を示す図である。メモリ１２には、Ｉ／Ｏ処理・死活監視委譲処理プログラム１２ａ、Ｉ／Ｏ資源管理処理プログラム１２ｂ、応答遅延対応処理プログラム１２ｃ、死活監視処理プログラム１２ｄ、及びリビルド処理プログラム１２ｅがストレージ１３からロードされ格納されている。これらのプログラムの処理機能は、図１５及び図１６を参照して後述する。

【0025】

またメモリ１２には、待機リクエストキューテーブル１２Ｔ１、待機リソースキューテーブル１２Ｔ２、Ｉ／Ｏ処理スレッドテーブル１２Ｔ３、応答待機処理スレッドテーブル１２Ｔ４、及びクラウドストレージ状態管理テーブル１２Ｔ５が格納されている。またメモリ１２には、リビルド要求フラグテーブル１２Ｔ６、応答タイムアウト時間テーブル１２Ｔ７、クラウドストレージ仮閉塞回数テーブル１２Ｔ８、及びクラウドストレージ仮閉塞上限回数テーブル１２Ｔ９が格納されている。これらのテーブルは、ストレージ１３からロードされ、メモリ１２に格納されている。これらのテーブルの詳細は、図５～図１４を参照して後述する。

【0026】

（ストレージノード１の機能構成と、実施形態の概要）
図４は、ストレージノード１の機能構成の一例と、実施形態の概要を示す図である。ストレージノード１は、Ｉ／Ｏ処理スレッド１０１、応答待機処理スレッド１０２、クラウドストレージゲートウェイ１０３、及び周期処理基盤１０４を有する。

【0027】

Ｉ／Ｏ処理スレッド１０１は、プロセッサ１１がメモリ１２と協働し、ストレージ１３からメモリ１２（図２）にロードしたＩ／Ｏ処理・死活監視委譲処理プログラム１２ａ（図３）を実行したインスタンスである。

【0028】

Ｉ／Ｏ処理スレッド１０１は、ホスト３からのＩ／Ｏリクエストをクラウドストレージ２に転送し、Ｉ／Ｏリクエストに対するクラウドストレージ２からのＩ／Ｏ応答をホスト３に転送する。Ｉ／Ｏ処理スレッド１０１は、コンテキストＩＤ１２１１とバッファ１２１２とを有するＩ／Ｏ資源１２１をキューに格納している。コンテキストＩＤ１２１１は、バッファ１２１２に格納されているＩ／Ｏ資源１２１を用いてＩ／Ｏ処理を実行し、後述の応答待機処理スレッド１０２にＩ／Ｏ資源１２１を移動させた移動元のＩ／Ｏ処理スレッド１０１の識別情報である。バッファ１２１２は、Ｉ／Ｏデータを格納する格納領域である。

【0029】

応答待機処理スレッド１０２は、プロセッサ１１がメモリ１２と協働し、ストレージ１３からメモリ１２（図２）にロードしたＩ／Ｏ資源管理処理プログラム１２ｂ（図３）を実行したインスタンスである。

【0030】

応答待機処理スレッド１０２は、待機リクエストキューテーブル１２Ｔ１と、待機リソースキューテーブル１２Ｔ２と、を有する。応答待機処理スレッド１０２は、Ｉ／Ｏ処理スレッド１０１から移動されたＩ／Ｏ資源１２１を、待機リクエストキューテーブル１２Ｔ１に保持する。また応答待機処理スレッド１０２は、待機リクエストキューテーブル１２Ｔ１から待機リソースキューテーブル１２Ｔ２にＩ／Ｏ資源１２１を移動させて保持し、待機リソースキューテーブル１２Ｔ２に保持されるＩ／Ｏ資源１２１を用いてＩ／Ｏ応答を待機する。

【0031】

クラウドストレージゲートウェイ１０３は、プロセッサ１１がメモリ１２と協働し、ストレージ１３からメモリ１２（図２）にロードした応答遅延対応処理プログラム１２ｃと死活監視処理プログラム１２ｄ（図３）を実行したインスタンスである。

【0032】

クラウドストレージゲートウェイ１０３は、Ｉ／Ｏ処理スレッド１０１、応答待機処理スレッド１０２、及び周期処理基盤１０４と連携してクラウドストレージ２に対して各種処理を実行する。

【0033】

周期処理基盤１０４は、メモリ１２と協働し、ストレージ１３からメモリ１２（図２）にロードしたリビルド処理プログラム１２ｅ（図３）等を実行したインスタンスである。

【0034】

周期処理基盤１０４は、クラウドストレージ２に対して、クラウドストレージ２の仮閉塞状態から通常状態への復帰に伴うＲＡＩＤ（Redundant Array of Independent Disk）のデータ復元を実施するリビルド処理（図１６）を実行する。

【0035】

以下、図４を参照して、本実施形態の概要を説明する。

【0036】

Ｉ／Ｏ処理スレッド１０１が送信したＩ／Ｏリクエストに対して、クラウドストレージ２からのI／Ｏ応答の遅延（I／Ｏ応答遅延）が発生したとする。I／Ｏ応答遅延は、ストレージノード１とクラウドストレージ２を接続する通信経路及びクラウドストレージ２内の通信経路を含むクラウドネットワークのトラフィック遅延により発生する。I／Ｏ応答遅延は、トラフィック改善等により自然回復する場合がある。自然回復を待つために、Ｉ／Ｏ処理の対象となっていたクラウドストレージ２が一時的に仮閉塞状態にされる（図４の（１）参照）。仮閉塞状態とは、新規のＩ／Ｏリクエストを受け付け不可能であり、I／Ｏ応答遅延が発生している既存のＩ／Ｏリクエストに対するＩ／Ｏ応答の確認（応答確認）のみが受け付け可能の状態である。

【0037】

次に、クラウドストレージ２のＩ／Ｏ応答遅延が自然回復した場合にＩ／Ｏ処理を継続させるために、処理継続に必要なＩ／Ｏ資源１２１（コンテキストＩＤ１２１１及びバッファ１２１２）を委譲する。具体的には、処理継続に必要なＩ／Ｏ資源１２１を、Ｉ／Ｏ処理スレッド１０１とは別に用意した応答待機処理スレッド１０２内に存在する待機リクエストキューテーブル１２Ｔ１に移動し保持させる（図４の（２）参照）。

【0038】

待機リクエストキューテーブル１２Ｔ１は、キュー構造を取り、複数のＩ／Ｏ処理スレッドに応対し、各Ｉ／Ｏ処理スレッド１０１から委譲されたＩ／Ｏ資源１２１をキューイングする。応答待機処理スレッド１０２は、１つのストレージノード１に１つ存在する。Ｉ／Ｏ処理スレッド１０１は、１つのストレージノード１に複数存在する（図４にはＴｈ１～Ｔｈ５の５つＩ／Ｏ処理スレッド１０１が示されている）。

【0039】

クラウドストレージ２の応答遅延の自然回復を待機している間、待機するＩ／Ｏ応答に対応するＩ／Ｏ資源１２１は、頻繁に参照される。待機リクエストキューテーブル１２Ｔ１は、複数のＩ／Ｏ処理スレッド１０１からのキューのｐｕｓｈ操作を受け、アクセス頻度が高くなるという不都合が生じる。

【0040】

この不都合を回避し、待機リクエストキューテーブル１２Ｔ１のアクセス負荷を分散するため、待機リクエストキューテーブル１２Ｔ１とは別に、クラウドストレージ２のＩ／Ｏ応答遅延を監視する際に参照される待機リソースキューテーブル１２Ｔ２が設けられる。Ｉ／Ｏ処理の継続に必要なＩ／Ｏ資源１２１は、待機リクエストキューテーブル１２Ｔ１から待機リソースキューテーブル１２Ｔ２へ移動され、クラウドストレージ２からのＩ／Ｏ応答を待機する（図４の（３）参照）。

【0041】

その後応答待機処理スレッド１０２は、クラウドストレージ２のＩ／Ｏリクエストに対するＩ／Ｏ応答遅延が自然回復したことによって、クラウドストレージ２からのＩ／Ｏ応答を受信する。

【0042】

次に、クラウドストレージゲートウェイ１０３は、Ｉ／Ｏ応答遅延から復帰したクラウドストレージ２に対して第１のタイムアウト経過時とのデータの相違箇所を対象としたリビルドである差分リビルドを開始し、ＲＡＩＤのデータ復元を実施する（図４の（４）参照）。

【0043】

なお差分リビルドは、図４の（１）で仮閉塞状態にした同一のクラウドストレージ２に対して実行される。これは、異なるクラウドストレージ２に対して差分リビルドが実行されると、データの偏在が発生し、Ｉ／Ｏ性能が低下するためである。

【0044】

次に、クラウドストレージゲートウェイ１０３は、クラウドストレージ２の差分リビルドが完了（図４の（５）参照）すると、該当のクラウドストレージ２をＩ／Ｏ処理に復帰させる（図４の（６）参照）。また応答待機処理スレッド１０２は、該当のＩ／Ｏ資源１２１を待機リソースキューテーブル１２Ｔ２から解放する（図４の（７）参照）。

【0045】

（待機リクエストキューテーブル１２Ｔ１の構成）
図５は、待機リクエストキューテーブル１２Ｔ１の構成の一例を示す図である。待機リクエストキューテーブル１２Ｔ１は、応答待機処理スレッド１０２にて保持されるＩ／Ｏ資源１２１の格納用コンテナであり、キュー構造（ＦＩＦＯ形式のデータ構造）を取る。複数のＩ／Ｏ処理スレッド１０１から、応答遅延が発生しているクラウドストレージ２に係るＩ／Ｏ資源１２１が追加される。待機リクエストキューテーブル１２Ｔ１に格納されるＩ／Ｏ資源１２１の数は、任意である。

【0046】

待機リクエストキューテーブル１２Ｔ１は、「ＩＮＤＥＸ」「格納要素」の列を有する。「ＩＮＤＥＸ」は、該当レコードの識別情報である。「格納要素」は、Ｉ／Ｏ資源１２１を格納する。

【0047】

（待機リソースキューテーブル１２Ｔ２の構成）
図６は、待機リソースキューテーブル１２Ｔ２の構成の一例を示す図である。待機リソースキューテーブル１２Ｔ２は、応答待機処理スレッド１０２に保持されるＩ／Ｏ資源の格納用コンテナであり、キュー構造を取る。待機リクエストキューテーブル１２Ｔ１に格納されているＩ／Ｏ資源１２１を先頭から順番に取得して自身のキューに順番に追加する。待機リソースキューテーブル１２Ｔ２に格納されるＩ／Ｏ資源１２１の数は、任意である。

【0048】

待機リソースキューテーブル１２Ｔ２は、「ＩＮＤＥＸ」「格納要素」の列を有する。「ＩＮＤＥＸ」は、該当レコードの識別情報である。「格納要素」は、Ｉ／Ｏ資源１２１を格納する。

【0049】

（Ｉ／Ｏ処理スレッドテーブル１２Ｔ３の構成）
図７は、Ｉ／Ｏ処理スレッドテーブル１２Ｔ３の構成の一例を示す図である。Ｉ／Ｏ処理スレッドテーブル１２Ｔ３は、Ｉ／Ｏ処理スレッド１０１が実行する、ホスト３から送信されたＩ／Ｏリクエストを処理するＩ／Ｏ処理スレッド群を管理する。Ｉ／Ｏ処理スレッドテーブル１２Ｔ３は、ストレージノード１毎に１つ存在する。Ｉ／Ｏ処理スレッド１０１の数は、動作環境に応じて任意である。

【0050】

Ｉ／Ｏ処理スレッドテーブル１２Ｔ３は、「スレッド番号」「スレッドＩＤ」の列を有する。「スレッド番号」は、Ｉ／Ｏ処理スレッドテーブル１２Ｔ３の各レコードの識別情報である。「スレッドＩＤ」は、各Ｉ／Ｏ処理スレッド１０１の識別情報である。

【0051】

（応答待機処理スレッドテーブル１２Ｔ４の構成）
図８は、応答待機処理スレッドテーブル１２Ｔ４の構成の一例を示す図である。応答待機処理スレッドテーブル１２Ｔ４は、応答待機処理スレッド１０２が実行する応答待機処理スレッドを管理する。

【0052】

応答待機処理スレッドテーブル１２Ｔ４は、「スレッド番号」「スレッドＩＤ」の列を有する。「スレッド番号」は、応答待機処理スレッドテーブル１２Ｔ４のレコードの識別情報である。「スレッドＩＤ」は、応答待機処理スレッド１０２の識別情報である。

【0053】

なお本実施形態では、応答待機処理スレッド１０２は、１つのストレージノード１あたり１つである。よって図８に例示する応答待機処理スレッドテーブル１２Ｔ４は、１レコードである。しかし応答待機処理スレッドは、１つのストレージノード１あたり複数でもよい。

【0054】

（クラウドストレージ状態管理テーブル１２Ｔ５の構成）
図９は、クラウドストレージ状態管理テーブル１２Ｔ５の構成の一例を示す図である。図１０は、クラウドストレージの状態遷移の一例を示す図である。

【0055】

クラウドストレージ状態管理テーブル１２Ｔ５は、「クラウドストレージＩＤ」「状態」の列を有する。「クラウドストレージＩＤ」は、クラウドストレージ２の識別情報である。「状態」は、「クラウドストレージＩＤ」に対応するクラウドストレージ２の“状態”である。

【0056】

図１０を参照して、クラウドストレージ２の“状態”について説明する。図１０に示すように、最初、クラウドストレージ２がストレージノード１に認識されたタイミングではNORMAL状態（状態１２Ｔ５２）である。NORMAL状態は、クラウドストレージ２が正常状態であり、ホスト３からＩ／Ｏリクエストを受け付けている状態である。

【0057】

NORMAL状態（状態１２Ｔ５２）のクラウドストレージ２にＩ／Ｏ応答遅延が発生すると、TEMPORARY BLOCKADE状態（仮閉塞状態）（状態１２Ｔ５３）に遷移する（状態遷移１２Ｔ５４）。TEMPORARY BLOCKADE状態では、ホスト３からのＩ／Ｏリクエストを受け付けていないが、ストレージノード１からの応答要求は受け付けている。クラウドストレージ２は、Ｉ／Ｏ応答遅延が自然回復するケースでは、リビルド処理を実行することでNORMAL状態（状態１２Ｔ５２）に復帰することができる（状態遷移１２Ｔ５５）。

【0058】

TEMPORARY BLOCKADE状態（状態１２Ｔ５３）では、クラウドストレージ２は、Ｉ／Ｏ応答遅延がタイムアウト時間以内に解消されなかった場合、BLOCAKDE状態（閉塞状態）（状態１２Ｔ５６）に遷移する（状態遷移１２Ｔ５７）。BLOCAKDE状態の時、クラウドストレージ２はホスト３からのＩ／Ｏリクエストもストレージノード１からの応答要求も受け付けない。

【0059】

（リビルド要求フラグテーブル１２Ｔ６の構成）
図１１は、リビルド要求フラグテーブル１２Ｔ６の構成の一例を示す図である。リビルド要求フラグテーブル１２Ｔ６は、「クラウドストレージＩＤ」「フラグ値」の列を有する。

【0060】

「クラウドストレージＩＤ」は、クラウドストレージ２の識別情報である。「フラグ値」は、クラウドストレージ２毎に管理されるフラグ値であり、trueは該当のクラウドストレージ２のリビルド処理の要求ありを示し、falseは要求なしを示す。周期処理基盤１０４（図４）は、任意の周期でリビルド要求フラグを監視し、リビルド要求フラグがtrueであるクラウドストレージ２に対してリビルド処理を実行する。

【0061】

（クラウドストレージの応答タイムアウト時間テーブル１２Ｔ７）
図１２は、クラウドストレージの応答タイムアウト時間テーブル１２Ｔ７の構成の一例を示す図である。応答タイムアウト時間テーブル１２Ｔ７は、クラウドストレージ２から得られる応答に関するタイムアウト時間を管理する。応答タイムアウト時間テーブル１２Ｔ７は、１つのストレージシステムＳあたりで１つ又は複数個である。

【0062】

応答タイムアウト時間テーブル１２Ｔ７は、「タイムアウト種別」「タイムアウト時間」の列を有する。「タイムアウト種別」には、“最大応答待ち時間（第１のタイムアウト時間）”と“最大応答遅延回復待ち時間（第２のタイムアウト時間）”がある。

【0063】

“最大応答待ち時間”は、ストレージノード１のＩ／Ｏ処理スレッド１０１がＩ／Ｏリクエストを発行し、Ｉ／Ｏリクエストに対してクラウドストレージ２から送信されたＩ／Ｏ応答がＩ／Ｏ処理スレッド１０１に受信されるまでの最大待ち時間を表す。Ｉ／Ｏ処理スレッド１０１がＩ／Ｏリクエストを発行してから“最大応答待ち時間”を超過してもＩ／Ｏ応答がＩ／Ｏ処理スレッド１０１に受信されない場合、該当のクラウドストレージ２は応答遅延が発生していると判定される。そして該当のクラウドストレージ２は、クラウドストレージゲートウェイ１０３により仮閉塞状態へと遷移させられる。“最大応答待ち時間”は、任意の時間が設定される。

【0064】

“最大応答遅延回復待ち時間（第２のタイムアウト時間）”は、仮閉塞状態であるクラウドストレージ２の応答遅延が自然回復するまでの最大待ち時間を表す。応答待機処理スレッド１０２が応答確認要求を送信してから“最大応答遅延回復待ち時間”を経過しても、クラウドストレージ２のＩ／Ｏ応答の遅延が自然回復しないときには、Ｉ／Ｏ応答は応答待機処理スレッド１０２に受信されない。この場合には、該当のクラウドストレージ２を閉塞状態にさせる。“最大応答遅延回復待ち時間（第２のタイムアウト時間）”は、任意の時間が設定される。

【0065】

なお応答タイムアウト時間テーブル１２Ｔ７は、個別のストレージノード１及びクラウドストレージ２に関わらず一律の値でも、ストレージノード１又はクラウドストレージ２毎に異なる値でもよい。

【0066】

（クラウドストレージ仮閉塞回数テーブル１２Ｔ８の構成）
図１３は、クラウドストレージ仮閉塞回数テーブル１２Ｔ８の構成の一例を示す図である。クラウドストレージ仮閉塞回数テーブル１２Ｔ８は、ストレージノード１毎に、配下の各クラウドストレージ２の仮閉塞回数を管理する。

【0067】

クラウドストレージ仮閉塞回数テーブル１２Ｔ８は、「クラウドストレージＩＤ」「仮閉塞回数」の列を有する。「クラウドストレージＩＤ」は、クラウドストレージの識別情報である。「仮閉塞回数」は、該当のクラウドストレージ２がＩ／Ｏ応答遅延を発生させる毎にカウントアップされるので、過去にＩ／Ｏ応答遅延を発生し仮閉塞状態に遷移した回数を示す。

【0068】

（クラウドストレージ仮閉塞上限回数テーブル１２Ｔ９）
図１４は、クラウドストレージ仮閉塞上限回数テーブル１２Ｔ９の構成の一例を示す図である。クラウドストレージ仮閉塞上限回数テーブル１２Ｔ９は「クラウドストレージＩＤ」「上限回数」の列を有する。

【0069】

「クラウドストレージＩＤ」は、クラウドストレージの識別情報である。「上限回数」は、クラウドストレージ２が仮閉塞状態に移行される上限回数である。クラウドストレージ２は、I／Ｏ応答遅延を引き起こした際に、「仮閉塞回数」が「上限回数」に到達した場合に、仮閉塞状態に遷移させずに、該当のクラウドストレージ２はストレージシステムＳから切り離される。

【0070】

（実施形態に係るＩ／Ｏリクエスト処理）
図１５は、Ｉ／Ｏリクエスト処理の一例を示すシーケンス図である。

【0071】

以下で説明するステップＳ１２、Ｓ１６、Ｓ１７、Ｓ２３、及びＳ２４は、Ｉ／Ｏ処理・死活監視委譲処理プログラム１２ａ（図２）による処理である。またステップＳ２５、Ｓ２６、Ｓ２７、Ｓ２８、Ｓ２９、Ｓ３５、Ｓ３６、Ｓ３７、Ｓ４０、及びＳ４１は、Ｉ／Ｏ資源管理処理プログラム１２ｂ（図２）による処理である。またステップＳ１３、Ｓ１４、Ｓ１５、Ｓ１８、Ｓ１９、Ｓ２０、Ｓ２１、及びＳ２２は、応答遅延対応処理プログラム１２ｃ（図２）による処理である。またステップＳ３０、Ｓ３１、Ｓ３２、Ｓ３３、Ｓ３４、Ｓ３８、及びＳ３９は、死活監視処理プログラム１２ｄ（図２）による処理である。

【0072】

先ずステップＳ１１では、ホスト３は、Ｉ／Ｏリクエストの要求をＩ／Ｏ処理スレッド１０１（図４）に送信する。次にステップＳ１２では、Ｉ／Ｏ処理スレッド１０１は、ホスト３からのＩ／Ｏリクエスト要求に応じて、クラウドストレージ２に対してＩ／Ｏリクエストを送信する。次にステップＳ１３では、クラウドストレージゲートウェイ１０３は、Ｉ／Ｏ処理スレッド１０１から受信したＩ／Ｏリクエストをクラウドストレージ２へ転送する。

【0073】

ステップＳ１４では、クラウドストレージゲートウェイ１０３は、クラウドストレージ２から、ステップＳ１３で転送したＩ／Ｏリクエストに対するＩ／Ｏ応答を、最大応答待ち時間内（図１２）に受信したかを判定する。クラウドストレージゲートウェイ１０３は、Ｉ／Ｏ応答を最大応答待ち時間内に受信した場合（ステップＳ１４ＹＥＳ）にステップＳ１５に処理を移し、最大応答待ち時間内に受信できなかった場合（ステップＳ１４ＮＯ）にステップＳ１８に処理を移す。

【0074】

ステップＳ１５では、クラウドストレージゲートウェイ１０３は、受信したＩ／Ｏ応答をＩ／Ｏ処理スレッド１０１に転送する。

【0075】

次にステップＳ１６では、Ｉ／Ｏ処理スレッド１０１は、ステップＳ１２で発行したＩ／Ｏリクエストに対するＩ／Ｏ応答を、最大応答待ち時間内（図１２）に受信したかを判定する。Ｉ／Ｏ処理スレッド１０１は、Ｉ／Ｏ応答を最大応答待ち時間内に受信した場合（ステップＳ１６ＹＥＳ）にステップＳ１７に処理を移し、最大応答待ち時間内に受信できなかった場合（ステップＳ１６ＮＯ）にステップＳ２３に処理を移す。

【0076】

なおステップＳ１２とステップＳ１３は、同時と見なしてよい。またステップＳ１４とステップＳ１６は、同時と見なしてよい。

【0077】

ステップＳ１７では、Ｉ／Ｏ処理スレッド１０１は、ステップＳ１６で受信したＩ／Ｏ応答をホスト３に転送する。ステップＳ１５及びＳ１７が終了すると、Ｉ／Ｏリクエスト処理は終了する。

【0078】

ステップＳ１８では、クラウドストレージゲートウェイ１０３は、仮閉塞回数のカウンタ変数値≧上限回数（図１４）かを判定する。クラウドストレージゲートウェイ１０３は、仮閉塞回数のカウンタ変数値≧上限回数の場合にステップＳ１９に処理を移し、仮閉塞回数のカウンタ変数値＜上限回数の場合にステップＳ２０に処理を移す。

【0079】

ステップＳ１９では、クラウドストレージゲートウェイ１０３は、ステップＳ１４で最大応答待ち時間内（図１２）にＩ／Ｏ応答を受信できなかった該当のクラウドストレージ２をストレージシステムＳから切り離す。具体的には、クラウドストレージゲートウェイ１０３は、該当するクラウドストレージ２をデータのＩ／Ｏ及び管理対象から抹消し、ストレージノード１との接続を切断する。該当するクラウドストレージ２に対応する情報をクラウドストレージ状態管理テーブル１２Ｔ５（図９）から消去してもよい。

【0080】

次にステップＳ２０では、クラウドストレージゲートウェイ１０３は、仮閉塞回数のカウンタ変数値に１を加算する。次にステップＳ２１では、クラウドストレージゲートウェイ１０３は、ステップＳ１４で最大応答待ち時間内（図１２）にＩ／Ｏ応答を受信できなかった該当のクラウドストレージ２の状態を、通常状態から仮閉塞状態に状態遷移させる。

【0081】

次にステップＳ２２では、クラウドストレージゲートウェイ１０３は、Ｉ／Ｏ処理スレッド１０１に対して第１のタイムアウト応答を送信する。第１のタイムアウトとは、ステップＳ１４で最大応答待ち時間内（図１２）にＩ／Ｏ応答を受信できなかったことをいう。

【0082】

次にステップＳ２３では、Ｉ／Ｏ処理スレッド１０１は、クラウドストレージゲートウェイ１０３から第１のタイムアウト応答を受信する。

【0083】

次にステップＳ２４では、Ｉ／Ｏ処理スレッド１０１は、Ｉ／Ｏ応答に係るＩ／Ｏ資源１２１（図４、図５）をＩ／Ｏ処理スレッド１０１内のキューから応答待機処理スレッド１０２に移動させる。これにより、Ｉ／Ｏ処理スレッド１０１は、Ｉ／Ｏ応答の受信を待機する待機処理を応答待機処理スレッド１０２に委譲する。

【0084】

ステップＳ２５では、応答待機処理スレッド１０２は、応答待機処理スレッド１０２内の待機リソースキューテーブル１２Ｔ２（図４、図６）にＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエストが存在するかを判定する。応答待機処理スレッド１０２は、待機リソースキューテーブル１２Ｔ２にＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエストが存在する場合（ステップＳ２５ＹＥＳ）にステップＳ２８に処理を移す。一方応答待機処理スレッド１０２は、待機リソースキューテーブル１２Ｔ２にＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエストが存在しない場合（ステップＳ２５ＮＯ）にステップＳ２６に処理を移す。

【0085】

ステップＳ２６では、応答待機処理スレッド１０２は、応答待機処理スレッド１０２内の待機リクエストキューテーブル１２Ｔ１（図４、図５）に、ステップＳ２４で移動されたＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエストが存在するかを判定する。応答待機処理スレッド１０２は、待機リクエストキューテーブル１２Ｔ１にＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエストが存在する場合（ステップＳ２６ＹＥＳ）にステップＳ２７に処理を移す。一方応答待機処理スレッド１０２は、待機リクエストキューテーブル１２Ｔ１にＩ／Ｏ資源１２１が格納されているＩ／Ｏリクエスト存在しない場合（ステップＳ２６ＮＯ）にステップＳ２５に処理を戻す。

【0086】

ステップＳ２７では、応答待機処理スレッド１０２は、待機リクエストキューテーブル１２Ｔ１から先頭のＩ／Ｏ資源１２１を取り出し、待機リソースキューテーブル１２Ｔ２の末尾に追加する。

【0087】

ステップＳ２８では、応答待機処理スレッド１０２は、待機リソースキューテーブル１２Ｔ２から先頭のＩ／Ｏ資源１２１を取得する。次にステップＳ２９では、応答待機処理スレッド１０２は、ステップＳ２８で取得したＩ／Ｏ資源１２１を用いるＩ／Ｏ応答を該当のクラウドストレージ２に要求する応答確認要求を送信する。

【0088】

次にステップＳ３０では、クラウドストレージゲートウェイ１０３は、応答待機処理スレッド１０２からの応答確認要求に応じて、クラウドストレージ２に対してＩ／Ｏ応答を要求する応答確認を送信する。次にステップＳ３１では、クラウドストレージゲートウェイ１０３は、待機リソースキューテーブル１２Ｔ２からステップＳ２８と同様のＩ／Ｏ資源１２１を取得し、Ｉ／Ｏ応答の待機処理を開始する。クラウドストレージゲートウェイ１０３は、ステップＳ３０及びＳ３１を、応答確認に係るＩ／Ｏ応答を受信するまで、又は最大応答遅延回復待ち時間が経過するまでに、一定間隔で繰り返す。

【0089】

次にステップＳ３２では、クラウドストレージゲートウェイ１０３は、クラウドストレージ２から、ステップＳ３０で送信した応答確認に係るＩ／Ｏ応答を、最大応答遅延回復待ち時間内（図１２）に受信したかを判定する。クラウドストレージゲートウェイ１０３は、応答確認に係るＩ／Ｏ応答を、最大応答遅延回復待ち時間内に受信した場合（ステップＳ３２ＹＥＳ）にステップＳ３３に処理を移し、受信できなかった場合（ステップＳ３２ＮＯ）にステップＳ３８に処理を移す。

【0090】

ステップＳ３３では、クラウドストレージゲートウェイ１０３は、ステップＳ３２で受信したＩ／Ｏ応答を応答待機処理スレッド１０２に転送する。次にステップＳ３４では、クラウドストレージゲートウェイ１０３は、リビルド要求フラグテーブル１２Ｔ６（図１１）において該当のクラウドストレージ２に対応するリビルド要求フラグに“true”をセットする。

【0091】

ステップＳ３５では、応答待機処理スレッド１０２は、ステップＳ３３でクラウドストレージゲートウェイ１０３から転送されたＩ／Ｏ応答を、最大応答遅延回復待ち時間内に受信したかを判定する。応答待機処理スレッド１０２は、Ｉ／Ｏ応答を最大応答遅延回復待ち時間内に受信した場合（ステップＳ３５ＹＥＳ）にステップＳ３６に処理を移し、受信できなかった場合（ステップＳ３５ＮＯ）にステップＳ４０に処理を移す。

【0092】

なおステップＳ２９とステップＳ３０は、同時と見なしてよい。またステップＳ３２とステップＳ３５は、同時と見なしてよい。

【0093】

ステップＳ３６では、応答待機処理スレッド１０２は、ステップＳ３５で受信したＩ／Ｏ応答をホスト３に転送する。次にステップＳ３７では、応答待機処理スレッド１０２は、ステップＳ３５で受信したＩ／Ｏ応答の処理に係るＩ／Ｏ資源１２１を待機リソースキューテーブル１２Ｔ２（図６）から削除する。

【0094】

一方ステップＳ３８では、クラウドストレージゲートウェイ１０３は、ステップＳ３２で最大応答遅延回復待ち時間内（図１２）にＩ／Ｏ応答を受信できなかったクラウドストレージ２の状態を仮閉塞状態から閉塞状態に状態遷移させる。次にステップＳ３９では、クラウドストレージゲートウェイ１０３は、応答待機処理スレッド１０２に対して第２のタイムアウト応答を送信する。第２のタイムアウトとは、ステップＳ３２で最大応答遅延回復待ち時間（第２のタイムアウト時間）内（図１２）にＩ／Ｏ応答を受信できなかったことをいう。

【0095】

次にステップＳ４０では、応答待機処理スレッド１０２は、クラウドストレージゲートウェイ１０３から受信した第２のタイムアウト応答をホスト３に転送する。次にステップＳ４１では、応答待機処理スレッド１０２は、ステップＳ４０で受信した第２のタイムアウトに係るＩ／Ｏ資源１２１を待機リソースキューテーブル１２Ｔ２（図６）から削除する。

【0096】

（実施形態に係るリビルド処理）
図１６は、リビルド処理の一例を示すフローチャートである。リビルド処理は、周期処理基盤１０４（図４）によるリビルド処理プログラム１２ｅ（図３）の周期的実行によって実現される。

【0097】

先ずステップＳ５１では、周期処理基盤１０４は、リビルド要求フラグテーブル１２Ｔ６（図１１）のリビルド要求フラグを確認する。次にステップＳ５２では、周期処理基盤１０４は、各クラウドストレージＩＤのクラウドストレージ２について、ステップＳ５１でリビルド要求フラグが“true”であると確認されたかを判定する。周期処理基盤１０４は、ステップＳ５１でリビルド要求フラグが“true”（ステップＳ５２ＹＥＳ）であると確認されたクラウドストレージ２についてはステップＳ５３に処理を移す。一方周期処理基盤１０４は、リビルド要求フラグが“false”（ステップＳ５２ＮＯ）であると確認されたクラウドストレージ２については本リビルド処理を終了する。

【0098】

ステップＳ５３では、周期処理基盤１０４は、リビルド要求フラグが“true”に該当するクラウドストレージ２に対して差分リビルド処理を実施する。

【0099】

なお本リビルド処理では、周期処理基盤１０４は、Ｉ／Ｏリクエスト処理（図１５）におけるステップＳ３２～Ｓ３４のクラウドストレージ２の仮閉塞状態からのＩ／Ｏ応答の復活を契機として、ステップＳ５３で差分リビルドを実施している。このため、クラウドストレージ２は、冗長度の回復をより短時間で行うことができる。周期処理基盤１０４は、Ｉ／Ｏリクエスト処理におけるステップＳ３８のクラウドストレージ２の閉塞状態への状態遷移を契機としてクラウドストレージ２に含まれる全データのリビルドであるフルリビルドを実施してもよい。しかし、クラウドストレージ２の仮閉塞状態からのＩ／Ｏ応答の復活を契機とする差分リビルトと比較して、冗長度の回復にさらに時間がかかることになる。

【0100】

（実施形態の効果）
上述の実施形態では、Ｉ／Ｏ処理スレッド１０１は、ホスト３からのＩ／Ｏリクエストに対して、第１のタイムアウト時間が経過するまでにクラウドストレージ２からＩ／Ｏ応答を受信しなかった場合、Ｉ／Ｏ資源１２１を応答待機処理スレッド１０２に移動させる。そして応答待機処理スレッド１０２は、移動されたＩ／Ｏ資源１２１を用いて、クラウドストレージ２に対してＩ／Ｏ応答を要求する応答確認を送信し、Ｉ／Ｏ処理スレッド１０１に代えてＩ／Ｏ応答の待機処理を行う。

【0101】

よって実施形態によれば、Ｉ／Ｏ応答遅延が発生しているクラウドストレージ２をＩ／Ｏ処理スレッド１０１の処理対象から除外し、応答待機処理スレッド１０２によってＩ／Ｏ応答の受信待機を継続するので、ホスト３に対するＩ／Ｏ性能の低下を抑制できる。

【0102】

また上述の実施形態では、Ｉ／Ｏ処理スレッド１０１は、第１のタイムアウト時間が経過するまでにクラウドストレージ２からＩ／Ｏ応答を受信しなかった場合、クラウドストレージ２の状態を遷移させる。すなわち、新規のＩ／Ｏリクエストを受け付け可能な通常状態から、新規のＩ／Ｏリクエストを受け付け不可能かつ応答確認のみ受け付け可能な仮閉塞状態に移行させる。

【0103】

よって実施形態によれば、Ｉ／Ｏ応答遅延が発生しているクラウドストレージ２に対して新たなＩ／Ｏリクエストを受け付けさせずＩ／Ｏ応答に集中させることで、ホスト３に対するＩ／Ｏ性能の低下を一層抑制できる。

【0104】

また上述の実施形態では、クラウドストレージ２の状態を仮閉塞状態にした回数が上限回数に到達した場合に、該当のクラウドストレージ２をストレージシステムＳから切り離す。

【0105】

よって実施形態によれば、頻繁にＩ／Ｏ応答遅延が発生するクラウドストレージ２をストレージシステムＳから除外することで、Ｉ／Ｏ応答遅延の頻発を回避することができる。

【0106】

また上述の実施形態では、応答待機処理スレッド１０２は、第２のタイムアウト時間が経過するまでにクラウドストレージ２から受信したＩ／Ｏ応答をホスト３に転送し、応答待機処理スレッド１０２に保持されるＩ／Ｏ応答に係るＩ／Ｏ資源１２１を開放する。

【0107】

よって実施形態によれば、応答待機処理スレッド１０２がＩ／Ｏ応答の受信を待機する時間に制限を設けることで、Ｉ／Ｏ応答の受信待機が無制限に滞留することを防止できる。

【0108】

また上述の実施形態では、応答待機処理スレッド１０２は、第２のタイムアウト時間が経過するまでにクラウドストレージ２からＩ／Ｏ応答を受信した場合、クラウドストレージ２の状態を仮閉塞状態から通常状態に移行させ、差分リビルド処理を実行する。

【0109】

よって実施形態によれば、クラウドストレージ２がＩ／Ｏ応答遅延から復帰した際に、差分リビルドによって、早期に冗長度を回復させることができる。

【0110】

また上述の実施形態では、応答待機処理スレッド１０２は、第２のタイムアウト時間が経過するまでにクラウドストレージ２からＩ／Ｏ応答を受信しなかった場合、クラウドストレージ２の状態を遷移させる。すなわち、仮閉塞状態から、Ｉ／Ｏリクエスト及び応答確認を受け付け不可能な閉塞状態に移行させる。すなわち、応答待機処理スレッド１０２が制限時間内にＩ／Ｏ応答を受信できないクラウドストレージ２を閉塞状態にしてフルリビルドが実行されるようにする。

【0111】

よって実施形態によれば、応答待機処理スレッド１０２がＩ／Ｏ応答を待機し続けるよりも早期にストレージシステムＳを正常状態に復帰させることができる。

【0112】

また上述の実施形態では、応答待機処理スレッド１０２は、待機リクエストキュー（待機リクエストキューテーブル１２Ｔ１）と、待機リソースキュー（待機リソースキューテーブル１２Ｔ２）と、を有する。そして応答待機処理スレッド１０２は、Ｉ／Ｏ処理スレッド１０１から移動されたＩ／Ｏ資源１２１を待機リクエストキューに保持し、待機リクエストキューから待機リソースキューに移動させたＩ／Ｏ資源１２１を用いてＩ／Ｏ応答に係る待機処理を実行する。

【0113】

よって実施形態によれば、Ｉ／Ｏ応答の応答確認及び受信待機の際に、Ｉ／Ｏ資源１２１を保持するキューへのアクセスの負荷分散を図り、Ｉ／Ｏ応答の受信待機処理を遅滞なく行い、クラウドストレージ２のＩ／Ｏ応答遅延からの早期復帰を実現できる。

【0114】

以上、本願開示に係る一実施形態について詳述したが、本願開示は上述の実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、上述の実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また上述の実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0115】

また上述の各構成、機能部、処理部、処理手段、スレッド等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また上述の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

【0116】

また上述の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。例えば、実際には殆ど全ての構成が相互に接続されていると考えてもよい。

【0117】

また上述したストレージシステムＳ、ストレージノード１、及びクラウドストレージ２の各機能及びデータの配置形態は一例に過ぎない。各機能及びデータの配置形態は、ハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最適な配置形態に変更し得る。

【符号の説明】

【0118】

１：ストレージノード、２：クラウドストレージ、３：ホスト、４：管理サーバ、１１：プロセッサ、１２：メモリ、１２Ｔ１：待機リクエストキューテーブル、１２Ｔ２：待機リソースキューテーブル、１０１：Ｉ／Ｏ処理スレッド、１０２：応答待機処理スレッド、１２１：Ｉ／Ｏ資源、Ｓ：ストレージシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】