(57)【特許請求の範囲】
【請求項１】
ブロックＩ／Ｏでアクセスする端末に接続される第１のインターフェースとファイルＩ／Ｏでアクセスする端末に接続される第２のインターフェースと、
制御プロセッサとメモリと記憶装置とを有し、
前記制御プロセッサとメモリは、ブロックＯＳとハイパバイザとのいずれでも利用可能なリソースとして管理され、
前記ブロックＯＳは、起動処理の際に、前記リソースから第１のリソース部分を確保し、
前記ハイパバイザは、前記起動処理の際に、前記第１のリソース部分以外の前記リソースから第２のリソース部分を確保し、確保された前記第２のリソース部分に基づいて少なくとも１の論理分割を生成し、前記少なくとも１の論理分割をファイルＯＳに割り当て、
前記ブロックＩ／Ｏでアクセスする端末から前記第１のインターフェースを介して第１のライト要求を受けると、前記ブロックＯＳは前記第１のリソースを用いて前記第１のライト要求に係るデータを前記ハイパバイザを介さずに前記記憶装置に格納し、
前記ファイルＩ／Ｏでアクセスする端末から前記第２のインターフェースを介して第２のライト要求を受けると、前記ファイルＯＳは、前記第２のリソースを用いて、前記第２のライト要求に基づいたコマンドを前記ハイパバイザを介して前記ブロックＯＳに送信し、前記ブロックＯＳは、前記第２のライト要求に係るデータを前記コマンドに従って前記記憶装置に格納する
ことを特徴とするストレージシステム。
【請求項２】
請求項１記載のストレージシステムであって、
前記第１のリソース部分は、前記ブロックＯＳに占有される
ことを特徴とするストレージシステム。
【請求項３】
請求項１記載のストレージシステムであって
前記ハイパバイザは、少なくとも２つの論理分割を生成し、前記２つの論理分割では異なる種類のＯＳが動作する
ことを特徴とするストレージシステム。
【請求項４】
請求項１記載のストレージシステムであって、 
前記リソースは、ポートを更に含む
ことを特徴とするストレージシステム。
【請求項５】
請求項１記載のストレージシステムであって、
前記ファイルＯＳは、
前記ファイルＯＳに割り当てられる前記メモリの部分に前記第２のライト要求を格納して、
前記第２のライト要求に係るデータを前記ハイパバイザを介して前記ブロックＯＳに送信する
ことを特徴とするストレージシステム。
【請求項６】
請求項１記載のストレージシステムであって、
前記ブロックＩ／Ｏでアクセスする端末から前記第１のインターフェースを介して第１のリード要求を受けると、前記ブロックＯＳは前記第１のリソースを用いて前記第１のリード要求に係るデータを前記ハイパバイザを介さず前記記憶装置から読み出し、
前記ファイルＩ／Ｏでアクセスする端末から前記第２のインターフェースを介して第２のリード要求を受けると、前記ファイルＯＳは、前記第２のリード要求に基づいたコマンドを前記ハイパバイザを介して前記ブロックＯＳに送信し、前記ブロックＯＳは、前記第２のリード要求に係るデータを前記コマンドに従って前記記憶装置から読み出し、前記読み出したデータを前記ハイパバイザを介して前記ファイルＯＳに送信する
ことを特徴とするストレージシステム。
【請求項７】
請求項６記載のストレージシステムであって、
前記ファイルＯＳは、
前記ファイルＯＳに割り当てられる前記メモリの部分に前記第２のリード要求を格納して、
前記格納された第２のリード要求に基づいて、前記ハイパバイザを介して前記第２のリード要求に基づいたコマンドを前記ブロックＯＳに送信する
ことを特徴とするストレージシステム。
【請求項８】
請求項１記載のストレージシステムであって、
前記ストレージシステムとしてそれぞれ構成される第１クラスタと第２クラスタを有する
ことを特徴とするストレージシステム。
【請求項９】
ストレージシステムにおけるデータ処理方法であって、
前記ストレージシステムは、ブロックＩ／Ｏでアクセスする端末に接続される第１のインターフェースとファイルＩ／Ｏでアクセスする端末に接続される第２のインターフェースと、記憶装置と、ブロックＯＳとハイパバイザとのいずれでも利用可能なリソースとして管理される制御プロセッサとメモリとを有し、
前記ブロックＯＳは、起動処理の際に、前記リソースから第１のリソース部分を確保し、
前記ハイパバイザは、前記起動処理の際に、前記第１のリソース部分以外の前記リソースから第２のリソース部分を確保し、確保された前記第２のリソース部分に基づいて少なくとも１の論理分割を生成し、ファイルＯＳに前記少なくとも１の論理分割を割り当て、
前記ブロックＯＳが、
前記ブロックＩ／Ｏでアクセスする端末から前記第１のインターフェースを介して第１のライト要求を受けるステップと、
前記第１のリソースを用いて前記第１のライト要求に係るデータを前記ハイパバイザを介さずに前記記憶装置に格納するステップと、
前記ファイルＯＳが、
前記ファイルＩ／Ｏでアクセスする端末から前記第２のインターフェースを介して第２のライト要求を受けるステップと、
前記第２のライト要求に基づいたコマンドを前記ハイパバイザを介して前記ブロックＯＳに送信するステップと、
前記ブロックＯＳが、
前記第２のライト要求に係るデータを前記コマンドに従って前記記憶装置に格納するステップと
を有することを特徴とするデータ処理方法。
【請求項１０】
請求項９記載のデータ処理方法であって、
前記第１のリソース部分は、前記ブロックＯＳに占有される
ことを特徴とするデータ処理方法。
【請求項１１】
請求項９記載のデータ処理方法であって、
前記ファイルＯＳが、
前記ファイルＯＳに割り当てられる前記メモリの部分に前記第２のライト要求を格納するステップと、
前記第２のライト要求に係るデータを前記ハイパバイザを介して前記ブロックＯＳに送信するステップと
を有することを特徴とするデータ処理方法。
【請求項１２】
請求項９記載のデータ処理方法であって、
前記ブロックＯＳが、
前記ブロックＩ／Ｏでアクセスする端末から前記第１のインターフェースを介して第１のリード要求を受けるステップと、
前記第１のリソースを用いて前記第１のリード要求に係るデータを前記ハイパバイザを介さず前記記憶装置から読み出すステップと、
前記ファイルＯＳが、
前記ファイルＩ／Ｏでアクセスする端末から前記第２のインターフェースを介して第２のリード要求を受けるステップと、
前記第２のリード要求に基づいたコマンドを前記ハイパバイザを介して前記ブロックＯＳに送信するステップと、
前記ブロックＯＳが、
前記第２のリード要求に係るデータを前記コマンドに従って前記記憶装置から読み出すステップと、
前記読み出したデータを前記ハイパバイザを介して前記ファイルＯＳに送信するステップと
を有することを特徴とするデータ処理方法。
【請求項１３】
請求項１２記載のデータ処理方法であって、
前記ファイルＯＳが、
前記ファイルＯＳに割り当てられる前記メモリの部分に前記第２のリード要求を格納するステップと、
前記格納された第２のリード要求に基づいて、前記ハイパバイザを介して前記第２のリード要求に基づいたコマンドを前記ブロックＯＳに送信するステップと
を有することを特徴とするデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージシステム及びリソース割当て方法に関するものである。
【背景技術】
【０００２】
従来から、ホスト計算機に対して大規模なデータストレージサービスを提供する計算機システムが存在する。このシステムは、ホスト計算機、ホスト計算機が接続するストレージ装置及びストレージ装置の管理装置を備えたものとして知られている。
ストレージ装置は、複数のハードディスクをRAID（Redundant  Array  of  Independent/Inexpensive  Disks）方式で管理する。そして、多数のハードディスクが有する物理的な記憶領域を論理化し、これを論理ボリュームとしてホスト計算機に提供する。ホスト計算機は論理ボリュームにアクセスしてデータのリード・ライトを要求する。
【０００３】
近年のトレンドとして、ストレージ装置の省スペース化、運用管理コスト低減（メンテナンスの容易化）、CPUなどのリソースの有効活用が課題となっている。これらを受けて、FC（Fibre  channel；ファイバー・チャネル）、iSCSI、FCoE（Fibre  Channel  over  Ethernet）、NAS（Network  Attached  Storage）など複数のプロトコルに対して１台で対応する一体型ストレージ装置、すなわち、ユニファイドストレージ装置に注目が集まっている。一体型にすることで要素が直結する構成となり、開発コストを抑えることができ、かつ、性能も確保できるメリットがある。
また、ネットワークに接続されファイルアクセスを受け付けるストレージ装置（例えば、ＮＡＳ）が有するハードウェアリソースを、論理的に分割して個々の論理区画（仮想的な記憶装置）を独立して動作させる技術も知られている（特許文献１）
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１２８７３３号公報                （米国特許公開２００５−０９１４５４）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来の一体型ストレージ装置では、ブロックストレージ用のI／Oもファイルストレージ用のI／OもシングルＯＳ上で区別せずに処理している。このため、従来のブロックストレージ装置は、性能向上のために行う処理を実施できない。例えば、ブロックストレージ装置では、リアルタイムＯＳによって障害を直ぐ検出することで高信頼性を実現したり、ハードウェアの動作を直接監視して性能チューニングを行っているが、シングルＯＳではそのような処理ができない。
そこで、ブロックストレージ装置の高性能なメリットを活かすストレージシステム及びそのリソース割当て方法を提供することを課題とする。
【課題を解決するための手段】
【０００６】
ブロックストレージ用のＯＳと、このブロックストレージ用のＯＳ以外のファイルシステム用のＯＳなどの複数のＯＳを用いたサービスを行うユニファイドストレージシステムを提供する。すなわち、ブロックストレージ用のＯＳによりブロックインターフェースによるサービスを提供するシステムであり、また、ファイルシステム用のＯＳなど（例えば、検索システムやWindowsなど）によりファイルインターフェースによるサービスを提供するシステムである。リアルタイムＯＳであるブロックストレージ用のＯＳとファイルシステム用のＯＳとに分けることが課題解決に向けたポイントである。
そして、複数のＯＳが１つの筐体内に共存するシステムであるため、複数ＯＳが協調して動作できるストレージ装置を提供する。
また、ハイエンドストレージ装置の高機能を活かしたユニファイドストレージシステムを実現するために、ハイエンドストレージ装置が動作するために必要な分のＣＰＵやメモリなどを割り当てる必要がある。そこで、ハイエンドストレージ装置側の性能を発揮できるようなハードウェアリソース定義（割当て）の仕方を提供する。
【０００７】
本発明では、複数ＯＳを共存する構成を提供する。まず、ブロックストレージマイクロ側制御マイクロ（ブロックストレージ側ＯＳ）とブロックストレージ以外のＯＳとに分け、ブロックストレージ以外のＯＳはハイパバイザ上に構成する。ハイパバイザは、複数の異なるＯＳを並列に実行する仮想環境を実現することを可能にするソフトウェアである。
ブロックストレージマイクロ制御とハイパバイザの処理を協調して動作させる。
データを格納するストレージ装置はハイエンドストレージ装置を構成し、ブロックストレージマイクロ制御が処理を行う。
【発明の効果】
【０００８】
本発明によるハードウェアリソース定義を行うことによって、リソースを無駄にすることなく、さらに、それぞれの処理の効率や性能を落とすことなく運用できる。
ブロックストレージマイクロの制御に先にリソースを割り当てるため、ブロックストレージマイクロ制御側の性能を確保できる。これは即ち装置全体の性能を確保することとなる。ブロックストレージマイクロ制御側の処理及び機能の能力を有効に活用できる。
【図面の簡単な説明】
【０００９】
【図１】図１は、ユニファイドストレージシステムにおいて、ハードウェアリソースを確保する方法の概念図である。
【図２】図２は、別のリソース確保方法の概念図である。
【図３】図３は、ストレージシステムのハードウェアの全体構成図の一例である。
【図４Ａ】図４Ａは、ユニファイドストレージシステムに第２のストレージ装置を接続した例である。
【図４Ｂ】図４Ｂは、ユニファイドストレージシステムがＳＡＮを介して第３のストレージ装置を接続した例である。
【図５】図５は、ストレージシステムの動作を説明するための、ハードウェアとソフトウェアのイメージ図である。
【図６】図６は、ブロックストレージ側へのＩ／Ｏ処理の流れの概要図である。
【図７】図７は、ブロックストレージ以外のＩ／Ｏ処理としてＦＯＳがＩ／Ｏを受けたときの処理の流れの概要図である。
【図８Ａ】図８Ａは、ハードウェアリソース管理テーブルの一例で、ブロックストレージマイクロ制御が持つハードウェアリソース管理情報である。
【図８Ｂ】図８Ｂは、ハードウェアリソース管理テーブルの一例で、ハイパバイザが持つハードウェアリソース管理情報である。
【図８Ｃ】図８Ｃは、ハードウェアリソース管理テーブルの一例で、ブロックストレージ以外の個々のＯＳが持つハードウェアリソース管理情報である。
【図９】図９は、ディレクトリデバイス情報テーブルの一例である。
【図１０】図１０は、ブロックストレージマイクロ制御側へのコマンド共有を説明するための図である。
【図１１Ａ】図１１Ａは、ハードウェアリソースをブロックストレージ装置側に割り当てる処理手順である。
【図１１Ｂ】図１１Ｂは、ハードウェアリソースをブロックストレージ以外のＯＳに割り当てる処理手順である。
【図１１Ｃ】図１１Ｃは、ハードウェアリソースを割り当てるための別の処理手順である。
【図１２】図１２は、リソースが追加された場合の構成定義手順である。
【図１３】図１３は、ブロックストレージのハードウェアリソースをブロックストレージ以外に動的に割り当てなおす処理を示すフローチャートである。
【図１４】図１４は、ブロックストレージ以外が使用しているハードウェアリソースをブロックストレージ側へ動的に割り当てなおす処理を示すフローチャートである。
【図１５】図１５は、ブロックストレージ側へのライト処理に係るフローチャートである。
【図１６】図１６は、ブロックストレージ側へのリード処理に係るフローチャートである。
【図１７】図１７は、ストレージ装置内に備えた障害プログラムの存在箇所を示した図である。
【図１８】図１８は、別の実施例に係るストレージシステムのハードウェアの全体構成図である。
【図１９】図１９は、ＦＯＳ側のライト処理に係るフローチャートである。
【図２０】図２０は、ＦＯＳ側のリード処理に係るフローチャートである。
【図２１】図２１は、ブロックストレージ側占有ハードウェアで発生した障害に関する図である。
【図２２】図２２は、ブロックストレージ側以外の共有ハードウェアで発生した障害に関する図である。
【図２３】図２３は、障害監視に係る情報を格納している情報管理テーブルを示した図である。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら本発明の実施の形態を説明する。ただし、本実施形態は、本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではない。また、各図において共通の構成については、同一の参照番号が付されている。
なお、以後の説明では「テーブル」という表現にて本発明の情報を説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくてもよい。例えば、「リスト」、「ＤＢ（データベース）」、「キュー」等のデータ構造やそれ以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために、「テーブル」、「リスト」、「ＤＢ」、「キュー」等については、単に「情報」と呼ぶこともできる。また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。
【００１１】
以後の説明では、「プログラム」を主語として説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては、専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムは、プログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００１２】
図１は、ユニファイドストレージシステムにおいて、ブロックストレージマイクロ制御側とブロックストレージマイクロ制御以外の制御側でハードウェアリソースを確保する方法の概念図である。ユニファイドストレージシステム内には複数のＯＳが共存している。ユニファイドストレージシステムに接続される全ハードウェアの「一部のハードウェア」を「優先」して、特定のＯＳへ割り当てる。この例では、特定のＯＳはブロックストレージマイクロ制御部である。ブロックストレージマイクロ制御部で割り当てられなかった残りのハードウェアを、ブロックストレージマイクロ制御部以外のＯＳへ割り当てる。
【００１３】
図１では、ブロックストレージマイクロ制御部以外のＯＳは複数あり、これら複数ＯＳを仮想化するソフトウェアとして、ハイパバイザによってハードウェアリソースの分配が行われる。この例では、論理分割技術である、ＬＰＡＲ（Logical  PARtitioning：論理分割）を使用して割り当てている。ハイパバイザは、割り当て可能なハードウェアリソースを対象となるＯＳに同時に割り当てる。
ハードウェアリソースには、例えば、制御プロセッサ（CPU）、ポート、障害監視用のハード、メモリ、記憶装置であるハードディクスなどのディスクがある。
【００１４】
従来、ストレージ装置にハードウェアリソースを割り当てる際は、認識するハードウェアのうち、確保する（以下では、使用するという場合もある）ものをストレージ装置が定義して登録すると、使用可能な状態となる。ストレージ装置が確保しない残りのリソースは、誰にも使用されていない「空き」状態として認識される。「空き」状態のリソースは、使用中のハードウェア要素に障害が発生した場合に代わりに使用したり、性能や容量が不足した場合の増設用として使用できる。
【００１５】
しかし、本発明のストレージシステムにおいては、ブロックストレージマイクロ制御が確保しなかったリソースは、ブロックストレージ装置のリソースではなくなり、また「空き」リソースではないため、後からブロックストレージマイクロ制御が使用することは原則できない。従来の装置構成では、このようなリソースの状態は発生せず、リソースはストレージ装置によって「空き」状態として認識させることはできなかった。
【００１６】
図２は、別のリソース確保方法の概念図である。複数ＯＳが共存するユニファイドストレージシステムの構成であり、例えば、ＯＳ１は１つで、ＯＳ２は１つ以上からなる。
説明では、ブロックインターフェースによってサービスを提供するものの例として、ブロックストレージマイクロ制御を示し、ファイルインターフェースによってサービスを提供するものの例として、ファイルシステム、検索システム、広くはWindowsなどを示す。ファイルインターフェースによってサービスを提供するものは、仮想化プログラム即ちハイパバイザ上で動作するものを示す。
【００１７】
図３は、ストレージシステムのハードウェアの全体構成図の一例である。
クライアント機器である１０１Ａ、１０１Ｂ、少なくとも１つの管理装置（管理計算機）２０、および、これらが接続される少なくとも１つのストレージ装置３０を有している。なお、ストレージ装置３０は、ストレージシステム、ストレージサブシステム、あるいはユニファイドストレージシステムと言うこともできる。
【００１８】
クライアント機器１０１Ａおよび１０１Ｂは、ストレージ装置３０を利用する外部計算機である。クライアント機器１０１Ｂは、ストレージ装置３０に対して、ファイルの書き込み、読み出し、生成を要求するファイルクライアント機器である。クライアント機器１０１Ａは、ストレージ装置３０の論理的な記憶資源にアクセスするブロッククライアント機器である。実際の機器としてはＰＣなどである。
【００１９】
また、クライアント機器１０１Ａ及び１０１Ｂは、入力デバイス、出力デバイス、ＣＰＵ、メモリ、ホストアダプタまたはネットワークアダプタを備える。このホストアダプタやネットワークアダプタは、ストレージ装置３０とネットワーク１０６、１０７を介してデータを送受信する。
クライアント機器１０１Aは、ブロックインターフェースであるFC（Fibre  Channel）やiSCSIを持つサーバ機器である場合もある。クライアント機器１０１Bは、ファイルインターフェースであるNFSやCIFSを持つ機器である場合もある。
【００２０】
管理装置２０は、ストレージ装置３０の記憶領域の構成を管理する。この管理装置２０は以下の要素から構成される。
入力デバイス２１０は、管理装置２０を操作する管理者等からの入力を受け付け、例えばキーボード等で構成される。出力デバイス２２０は、管理装置２０の状態や設定項目を表示し、例えば、ディスプレイ装置等で構成される。
【００２１】
ＣＰＵ２３０は、ディスクドライブ２６０に格納されている管理プログラムをメモリ２４０に読み込んで、そのプログラムに基づいて、ストレージ装置３０に対する管理処理を実行する。メモリ２４０は、例えばＲＡＭ等で構成され、プログラムやデータ等を格納する。
【００２２】
ネットワークアダプタ２５０は、クライアント機器１０１Ａ及び１０１Ｂ又はストレージ装置３０と、管理ネットワーク１０８を介してデータを送受信する。管理ネットワーク１０８は、例えばEthernet（登録商標）で構成される。ディスクドライブ２６０は、例えばハードディスク装置で構成され、データやプログラムを格納する。
【００２３】
ストレージ装置３０は、物理デバイス３４に設定された記憶領域にデータを格納する。
ストレージ装置３０は、その内部に、少なくとも１つの制御プロセッサ、メモリ、物理デバイス３４を有し、より具体的には、制御プロセッサである中央処理装置（ＣＰＵ：  Central  Processing  Unit）３１、メモリ３２、ディスクインターフェース３３、ＦＣインターフェースであるＨＢＡ（Host  Bus  adaptor）３５（ＨＢＡターゲットであり、ホストアダプタとも言う）、ＬＡＮインターフェースであるＮＩＣ（Network  Card）３６を備えている。
【００２４】
ＣＰＵ３１、メモリ３２、ＨＢＡ３５、ＮＩＣ３６およびディスクインターフェース３３は、相互にバス３７を介して接続されている。バスは例えば、ＰＣＩ−ＥＸであり、または、スイッチで構成されていてもよい。
【００２５】
ＣＰＵ３１は、メモリ３２に格納されている各種プログラム、モジュールを実行する演算処理装置である。このＣＰＵ（制御プロセッサ）３１は、物理デバイス３４に構成された記憶領域へのデータの格納を制御する。
【００２６】
メモリ３２は、いわゆる内部記憶装置であり、ＣＰＵ（制御プロセッサ）３１で動作するプログラムや構成情報等を格納する不揮発性メモリおよび演算処理結果を一時的に格納する揮発性メモリの双方を含む。メモリ３２内の不揮発性メモリは、ハードディスクやフラッシュメモリで構成される。メモリ３２内のキャッシュメモリ部分は、物理デバイス３４に読み書きされるデータを一時的に格納する。共有メモリ部分は、ストレージ装置３０や物理デバイス３４の構成情報を格納する。
ディスクインターフェース３３は、物理デバイス３４とメモリ３２等との間でデータを送受信する。
【００２７】
物理デバイス３４は、複数のディスク装置によって構成される。ディスク装置（記憶デバイス）は、例えばハードディスクドライブで構成され、主としてユーザデータを格納する。記憶デバイスとしては、フラッシュメモリなどの半導体メモリからなるドライブでもよい。
【００２８】
ＨＢＡ３５は、ネットワーク１０６に接続されており、データ転送に適したプロトコルによって、ブロッククライアント機器１０１Ａ（またはホスト計算機）との間でコマンド、データの授受を実行する。ネットワーク１０６は、例えばＦＣ（Fibre  Channel）、イーサネットなどである。
【００２９】
ＮＩＣ３６は、ネットワーク１０７に接続されており、ＮＦＳ、ＣＩＦＳなどのプロトコルによって、ファイルクライアント機器１０１Ｂとの間でコマンド、データの授受を実行する。ネットワーク１０７は例えばＬＡＮなどイーサネットである。
【００３０】
１つのＨＢＡ及びＮＩＣに対して複数ポートが設けられている。
クライアント機器１０１Ａ及び１０１Ｂは、管理ネットワーク１０８を介して管理装置２０との間でシステム管理上必要なデータ（管理情報）を送受信する。
【００３１】
ストレージ装置３０は、保守管理インターフェース３９を備える。バス３７とは異なるネットワーク３８を介して、制御プロセッサ３１と接続している。ネットワークの種類は例えばＬＡＮである。ストレージ装置３０内のＣＰＵ以外の部位において、障害が起こった場合、ＣＰＵ３１経由で障害情報を管理装置２０へ報告することができる。
プログラムは、メモリ３２の他、物理デバイス３４に格納されていてもよい。
【００３２】
図１８に、別の実施例に係るストレージシステムのハードウェアの全体構成図を示す。
別の実施例では、ストレージ装置３０内に、コントローラボード４１を２枚搭載している。コントローラボード４１A内に搭載された制御プロセッサ３１Aは、コントローラボード４１B内に搭載された制御プロセッサ３１Bとライン４２により接続されている。ライン４２は、例えば、専用線のバスやスイッチなどの接続機構である。例えば、このライン４２を介して制御プロセッサ３１Aから制御プロセッサ３１Bを経て相手方メモリ３２Bをアクセスすることを可能とする。
クラスタ５０は、コントローラボード４１、ホスト側インターフェースであるHBA３５、NIC３６、ディスクインターフェース３３、保守管理インターフェースであるNIC３９を含む。
クラスタ５０Aのブロックストレージマイクロ制御以外のハイパバイザ上で動作させるOSとクラスタ５０Bのブロックストレージマイクロ制御以外のハイパバイザ上で動作させるOSでは通常のクラスタサーバ構成を組む。例えば、ファイルシステムを使用するＯＳであるＦＯＳの場合、クラスタ５０AのあるFOSとクラスタ５０BのあるFOSで予めクラスタ構成を組み、正クラスタ５０A内のＦＯＳと副クラスタ５０B内のＦＯＳが例えば、ハートビートなどの手段によって、一定期間単位に常に相手が正常に稼働していることを確認する。正クラスタ５０A側のファイルシステムに障害が発生したことを副クラスタ５０B側のＦＯＳが検知した場合、クラスタ５０AのＦＯＳが障害をクラスタ５０Ｂが判断して、クラスタ５０ＢのＦＯＳがクラスタ５０ＡのＦＯＳの処理を肩代わりして稼働し続けるフェイルオーバ処理を実現する。このような構成をとることでシステム全体の信頼性を向上している。
ブロックストレージマイクロ制御３１４は、クラスタ５０Aとクラスタ５０Bにまたがり１つの共通した制御として動作する。即ち、１つの制御情報を参照してクラスタ５０Ａのプロセッサとクラスタ５０Ｂのプロセッサが動作する。
さらなるバリエーションとして、ライン４２は、制御プロセッサ３１Ａと制御プロセッサ３１Ｂ上のブロックストレージマイクロ制御３１４同士でのみ通信が可能であり、ブロックストレージマイクロ制御３１４Ａが使用するメモリ３１Ａとブロックストレージマイクロ制御３１４Ｂが使用するメモリ３２Ｂはブロックストレージマイクロ制御３１４Ａとブロックストレージマイクロ制御３１４Ｂの間で共有され、メモリ３１Ａとメモリ３１Ｂの内容は同じであってもよい。
【００３３】
図４は、ユニファイドストレージシステム全体構成のバリエーション例を示す。例えば、ユニファイドストレージシステムに外部ストレージシステムを接続してもよい（図４A）。
ユニファイドストレージシステム３０Aは、外部接続機能を備える。第２のストレージ装置３０Bは、この機能によってユニファイドストレージシステム３０Ａに外部接続されている。外部接続機能は、特許第４７０４６５９号明細書に記載がある。
【００３４】
ここで、外部接続機能について説明する。第２のストレージ装置３０Bは、ユニファイドストレージシステム３０Aと同じ機種でも異なる機種でもよい。また、ユニファイドストレージシステム３０Aは、図３に示すストレージ装置３０に対応する。
【００３５】
既に説明したように、ユニファイドストレージシステム３０Aは、１つ又は複数の論理ボリュームをサーバに提供する。各論理ボリュームは、サーバによって１つの記憶デバイスと認識される。例えば、ユニファイドストレージシステム３０Aが提供する論理ボリュームが、ユニファイドストレージシステム３０A内の物理デバイス３４（または物理デバイス３４から作成される仮想デバイス）に対応付けられる。その場合、ユニファイドストレージシステム３０Aは、論理ボリュームへのライトコマンドを受信すると、その論理ボリュームに対応付けられた物理デバイス３４にデータを格納する。
【００３６】
あるいは、ユニファイドストレージシステム３０Aが提供する論理ボリュームは、第２のストレージ装置３０B内の物理デバイス３４Bに対応付けられてもよい。この場合、ユニファイドストレージシステム３０Ａは、論理ボリュームへのライトコマンドを受信すると、その論理ボリュームに対応付けられた物理デバイス３４Bにデータを書き込むためのライトコマンドを生成する。ユニファイドストレージシステム３０Ａは、生成したライトコマンドを第２のストレージ装置３０Bに送信する。第２のストレージ装置３０Bは、ユニファイドストレージシステム３０Aから受信したライトコマンドに従って、データを物理デバイス３４Bに格納する。
【００３７】
このように、ユニファイドストレージシステム３０Aが提供する論理ボリュームに格納されるデータを、実際にはユニファイドストレージシステム３０Aの外部に接続された第２のストレージ装置３０Bに格納する機能が、外部接続機能と呼ばれるものである。
【００３８】
また、ユニファイドストレージシステム３０Aは、例えばＳＡＮなどの外部のネットワークに接続されていてもよい。図４Bは、ユニファイドストレージシステム３０Aは、ＳＡＮを介して第３のストレージ装置３０Ｃを外部接続している例である。
【００３９】
図５に、ストレージシステムの動作を説明するために、ハードウェアとソフトウェアのイメージ図を示す。簡略化するために、図３のハードウェア構成のうち、説明に必要な部分のみを記載した。
各ＯＳ及びブロックストレージマイクロ制御部は、制御プロセッサであるＣＰＵのコア上で動作する。実際には、ＯＳはプログラムであるためメモリ上に置かれ、ＣＰＵがそれを読み込んで動作するが、説明上、コアの上に各ＯＳを記載している。ＣＰＵ１枚のパッケージにコアは通常複数個あり、障害などに対応するための冗長性をもたせるため、パッケージは２枚単位で増減する。つまり、最小構成におけるパッケージ数は２枚である。プロセッサコアの使い方として、同じパッケージに同種類のＯＳを集中させても、物理的なパッケージに分割できるように分散してもよい。性能や可用性のうち、何を優先するかで設計できる。
【００４０】
ハイパバイザもソフトウェアであるため、メモリ上に格納されている。ハイパバイザは各ＯＳでそれぞれ動作するため、コアに対応するものではなく、図５のように、ブロックストレージマイクロ制御以外のＯＳを搭載する。図５では、ある制御プロセッサ３１、すなわちパッケージに複数のコアがあり、ＦＯＳ３１１Ａ、検索システム３１２、Windows３１５およびブロックストレージマイクロ制御３１４Ａ、３１４Ｂがコア毎に載っている。
【００４１】
ハイパバイザ３１３は、ＦＯＳ３１１Ａ、検索システム３１２およびWindows３１５それぞれに組み込まれている。ハイパバイザ３１３上で、ＦＯＳ３１１Ａと検索システム３１２およびWindows３１５を動作させる。他の制御プロセッサに、別のＦＯＳ３１１Ｂや他のシステム３１３が載っている場合もある。その場合は、ハイパバイザ３１３上でＦＯＳ３１１Ｂや他のシステムＯＳ３１３を動作させてもよいし、他のハイパバイザ３１３Ｂでもよい。ここで、ＦＯＳとは、ファイルシステムを使用するＯＳのことを指すものである。
または、ハイパバイザを特定のコア上で動作させてもよい。
【００４２】
メモリは、不揮発性、揮発性など特徴が異なるものが混在する場合もある。いずれにしても、冗長性を保つため２重化している。メモリには、ストレージ装置の構成情報や、要求コマンド、アドレスマッピング情報などの制御情報およびリードライトデータを格納するためのキャッシュメモリ的な要素であるものがある。
【００４３】
制御情報（または構成情報）を格納するメモリと、データを格納するキャッシュメモリ的な用途のメモリは、使用する領域が論理的または物理的に分かれていればよい。不揮発性メモリ、揮発性メモリなど種類が異なってもよい。制御情報を格納するメモリとキャッシュメモリ的な用途のメモリは、メモリを使用するブロックストレージマイクロ制御、ＦＯＳおよびその他のＯＳごとに、使用する領域が論理的または物理的に分かれていればよい。
【００４４】
図５に、メモリ３２の割り当て例を示す。メモリ３２は、物理的に分かれたメモリであり、制御情報を格納するメモリ３２１とデータを格納するメモリ３２２からなる。メモリ３２１、３２２は、アドレス空間によって使用するＯＳ毎に分割して使用している。各ＯＳは自らに割り当てられたメモリ空間しか認識できない。例えば、ＦＯＳ３１１Ａは、ＦＯＳ３２１１Ａの空間とＦＯＳ３２２１Ａしか認識しておらず、そこを使用できる。ＦＯＳ３２１１ＡおよびＦＯＳ３２２１ＡにはＦＯＳプログラムが格納されている。
【００４５】
メモリ３２１のブロックストレージマイクロ制御部３２１４には、プロセッサ３１によって読み込まれて実行される各種プログラムや、論理ボリュームの設定に関する構成情報、及び、プールの設定に関するプール情報を格納している。メモリ３２２のブロックストレージマイクロ制御部３２２４には、転送データなどを格納する。
【００４６】
制御プロセッサ３１によって読み込まれて実行される各種プログラムには、次のものがある。
コマンド制御プログラムは、クライアント機器１０１、又は管理装置２０からのコマンドを解釈し、そのコマンドに規定された処理を実行する。構成制御プログラムは、ストレージ装置３０の構成の設定、更新等の処理を実現する。ディスクＩ／Ｏプログラムは、物理デバイス３４へのアクセスを制御する。
【００４７】
構成情報は、仮想デバイス、論理デバイス、階層、ＲＡＩＤグループなどストレージ装置の環境設定に必要な情報である。また、構成情報として、アドレス管理テーブルおよび論理デバイス管理情報テーブルがある。
【００４８】
アドレス管理テーブルは、ターゲットデバイス、論理デバイス、仮想デバイスおよび物理デバイスとのアドレスのマッピング情報、ターゲットデバイスと論理デバイスのマッピング情報、そして、論理デバイスと仮想デバイスのマッピング情報、及び、仮想デバイスと物理デバイスのマッピング情報を格納している。
【００４９】
ストレージ装置３０は、このアドレス管理テーブルを参照することによって、ターゲットデバイスのアドレスがどの論理デバイスのどのアドレスに対応するかを知ることができる。また、論理デバイスのアドレスがどの仮想デバイスのどのアドレスに対応するかを知ることができる。また、仮想デバイスのアドレスがどのＲＡＩＤグループに属しており、どの物理デバイスのどのアドレスに対応するかを知ることができる。
【００５０】
データが物理的などの位置に格納されるのか、または、容量仮想化機能により格納されるのかは、ブロックストレージの制御に委ねる。
ブロックストレージ側のハードディスクを使用する際、ＦＯＳのＩ／Ｏかブロックかを区別して格納場所を決めてもよい。
【００５１】
図６は、ブロックストレージ側へのＩ／Ｏを受けたときの処理の流れの概要である。図１５のフローチャートに従って処理を説明する。
ブロッククライアント機器１０１Ａが、ライト要求をＨＢＡ３５の＃０のポートであるＰ＃１へ出す（Ｓ６１０）。以降の処理は、制御プロセッサ３１内のブロックストレージマイクロ制御３１４B部（プロセッサボード内の１つのコア）が実行する。制御プロセッサ３１には、他にもＦＯＳなどのブロックストレージ以外のＯＳが搭載されているが実行に関与しない。ブロックストレージマイクロ制御がコマンドの種類を認識する。ライトであればＳ６１２へすすみ、リードであればＳ６４２へ進む（Ｓ６１１）。
【００５２】
ＨＢＡ３５内のバッファ領域に前記要求が格納されると、ライト要求されたデータを格納すべきアドレス、すなわち、ブロックストレージが処理できる形態のコマンドに、ブロックストレージマイクロ制御が変換する。ここでは、ブロックストレージがサーバへ提供しているＬＵとアドレス番号に変換される（Ｓ６１２）。変換されたコマンドをブロックストレージマイクロ制御は自らのメモリ領域へ格納する（Ｓ６１４）。格納の際は２重化などの冗長化も行う。
【００５３】
コマンド制御プログラムは、ＬＵ−論理デバイス−仮想デバイスアドレス変換を行う（Ｓ６１６）。続いて、ライト対象アドレスがキャッシュメモリに確保されているか否かのヒットミス判定を行う（Ｓ６１７）。
ヒットミス（ライト対象アドレスに対してキャッシュメモリが確保されていない）と判定されれば（Ｓ６１７でＮｏの場合）、コマンド制御プログラムは、ライトデータを格納するためのキャッシュメモリ領域を確保する（Ｓ６１８）。
【００５４】
次いで、コマンド制御プログラムは、データの受領準備ができたことをブロッククライアント機器１０１Ａに報告する（Ｓ６２０）。
コマンド制御プログラムが、ブロッククライアント機器１０１Ａから転送データを受領すると、データを確保したキャッシュメモリに格納し（Ｓ６２４）、ライト完了報告をブロッククライアント機器１０１Ａに送信する（Ｓ６２６）。
【００５５】
ブロックストレージマイクロ制御は、要求を処理待ちキューに登録する（Ｓ６３０）。ブロックストレージマイクロ制御は、順次処理待ちキューから要求を取り出し、順番に処理をしていく。ここは、従来のブロックストレージのデータの流れと同じである。すなわち、コマンド制御プログラムは、仮想デバイス−物理デバイス／外部ＬＵアドレス変換（Ｓ６３２）を行い、ライト対象データを格納するメディアのアドレスを算出し（Ｓ６３４）、キャッシュメモリに格納したデータをこのメディアアドレスに対して書き込む（Ｓ６３６）。
【００５６】
メモリ３２１４Ｂには、要求コマンドを順番に処理するためにキューイングするＩ／Ｏキューが格納される。メモリ３２２４Ｂには、データ格納用であるキャッシュメモリ、ＣＰＵ作業用バッファなどが格納される。
【００５７】
リード処理も同様に行う。図１６にそのフローチャートを示す。
コマンド受け取りまではライト処理と同様である。
ブロッククライアント機器１０１Ａがリード要求を出す。Ｓ６４４からＳ６４８の処理は、先のＳ６１２からＳ６１６までの処理と同じである。
コマンド制御プログラムは、ＬＵ−論理デバイス−仮想デバイスアドレス変換を行い、リード対象アドレスのデータがキャッシュメモリ上にあるか否かのヒットミス判定を行う（Ｓ６５０）。
【００５８】
リード対象アドレスのデータがキャッシュ上にあれば（Ｓ６５０でＹｅｓの場合）、コマンド制御プログラムは、キャッシュ上のデータをブロッククライアント機器１０１Ａに転送し（Ｓ６６０）、ブロッククライアント機器１０１Ａに完了を報告する（Ｓ６６２）。
【００５９】
リード対象アドレスのデータがキャッシュ上に無ければ（Ｓ６５０でＮｏの場合）、コマンド制御プログラムは、仮想デバイス−物理デバイス／外部ＬＵアドレス変換を行い（Ｓ６５２）、リード対象データが格納されているメディアのアドレスを算出し（Ｓ６５４）、メディアアクセスプログラムを起動する。
【００６０】
メディアアクセスプログラムは、算出したメディアのアドレスからデータを読み出して、キャッシュに格納し（Ｓ６５６）、キャッシュに格納したことをコマンド制御プログラムに通知する（Ｓ６５８）。コマンド制御プログラムは、メディアアクセスプログラムからの通知を受領すると、キャッシュ上のデータをブロッククライアント機器１０１Ａに転送し（Ｓ６６０）。完了報告をする（Ｓ６６２）。
【００６１】
上記のとおり、ブロックストレージ側へのＩ／Ｏを処理する際には、ハイパバイザを介さない。これにより、ハイパバイザを介することで発生するオーバヘッドを無くし、性能低下を抑えられる。
【００６２】
図７に、ブロックストレージ以外へのＩ／Ｏの例として、ＦＯＳがＩ／Ｏを受けたときの処理の流れを示し、図１９のフローチャートとともに処理を説明する。
ファイルクライアント機器１０１Ｂが、ライト要求をポートに対して出す（Ｓ７１０）。     図の例では、ＮＩＣ３６の＃０のポートＰ＃２へ出す。ＦＯＳ３１１Ａがコマンドの種類を認識する。ライトであれはＳ７１２へすすみ、リードであればＳ７５２へ進む（Ｓ７１１）。要求の形態はファイルシステムへのライトなどがあり、または、ディレクトリ情報の形態での要求となる。 
【００６３】
ＮＩＣ３６の＃０のポートＰ＃２が割り当てたＯＳへ要求を渡す（Ｓ７１２）。図７では、ＦＯＳ３１１Ａがライト要求をＦＯＳ専用のメモリへ格納する。
ライトデータを格納するバッファエリアをメモリ３２２のＦＯＳ領域から確保する（Ｓ７１４）。確保できれば、ファイルクライアント機器１０１Ｂへ確保できたことを報告する（Ｓ７１６）。報告を受けたファイルクライアント機器１０１ＢはライトデータをＦＯＳへ転送する（Ｓ７１８）。
【００６４】
ハイパバイザが仮想的にＨＢＡを提供し、仮想ＨＢＡに前記要求を格納すると、ＦＯＳは、要求コマンドをＬＵ番号とアドレスに変換する（Ｓ７２０）。前記要求は、この変換後の形態でメモリへ格納される。 ここで、仮想ＨＢＡは、例えば、ＦＯＳ制御メモリ内に搭載されるソフトウェアである。要求を格納するメモリは、例えば、ブロックストレージマイクロ制御とＦＯＳの共有領域として定義しておき、ブロックストレージマイクロ制御とＦＯＳ両方からアクセスできるメモリ領域とする。そのようにすることで、格納された要求コマンドを直接ブロックストレージマイクロ制御が読み込んで処理を開始できる。別の方法として、共有する領域を持たずに、ＦＯＳは、要求をＦＯＳ領域からブロックストレージマイクロ制御領域へコピーしたり、ブロックストレージマイクロ制御とＦＯＳのメモリ領域をスイッチング（交換）する。
【００６５】
ＦＯＳ側の要求が共有領域に格納されたことをブロックストレージマイクロ制御側へ知らせるために、ＦＯＳ側からブロックストレージマイクロ制御部へ割り込みを上げるか、ブロックストレージマイクロ制御部が一定間隔で要求キューを見に行き、処理待ちコマンドがあれば要求を選択して処理をするなどの動作を行う（Ｓ７２２）。
【００６６】
以降の処理は、ブロックストレージマイクロ制御によるＳ６１６以降の処理と同様に、アドレス変換を行い（Ｓ７２４）、ヒットミス判定を行う（Ｓ７２６）。キャッシュが確保できていれば、ＦＯＳ側へデータを転送するように報告し（Ｓ７３０）、ＦＯＳからブロックストレージ側へデータを転送し（Ｓ７３２）、ブロックストレージマイクロ制御側のキャッシュへ格納する（Ｓ７３４）。
【００６７】
データ転送は、具体的には、データが格納されたＦＯＳが使用するメモリアドレスからブロックストレージが使用するメモリアドレスへメモリ間コピーを行う。または、管理するデータが格納されているメモリ領域とコピー先のブロックストレージマイクロ制御側のメモリ領域とのアドレスを交換する。物理的なデータ格納アドレスがコピー元とコピー先で同じ場合は、実質的なデータのコピー処理は発生しないというケースもある。このような場合は、ハイパバイザの中のプログラムが別の領域にデータがあり、コピーされているように見せかける処理を行う。
【００６８】
ブロックストレージ側のキャッシュメモリが確保され準備できれば、ＦＯＳ側へデータ転送を開始することを示す。ブロックストレージマイクロ制御からＦＯＳへ割り込みを上げるか、メッセージを送信する。
指示を受けたＦＯＳ側は、自らの領域のメモリ内に格納していればそのデータをブロック側メモリへコピーし、なければファイルクライアント機器からライトデータを送信してもらう。
【００６９】
ブロックマイクロストレージ制御側のキャッシュへライトデータが格納されれば、ＦＯＳ側へ完了報告をする（Ｓ７３６）。ＦＯＳは、ブロックストレージマイクロ制御側からの完了報告を受けて、ファイルクライアント機器へライト完了を報告する（Ｓ７３７）。
Ｓ７３８以下の処理は、図１５のＳ６３０以降の処理と同様である。
【００７０】
リード処理も同様に行う。図２０にそのフローチャートを示す。
コマンドの受け取りまではライト処理と同様である。
ファイルクライアント機器１０１Ｂがリード要求を出す。Ｓ７５４からＳ７６４の処理は、先のＳ７１２からＳ７２４までの処理と同じである。
コマンド制御プログラムは、ＬＵ―論理デバイス−仮想デバイスアドレス変換を行い（Ｓ７６４）、リード対象アドレスのデータがキャッシュメモリ上にあるか否か、ヒットミス判定を行う（Ｓ７６６）。
【００７１】
リード対象アドレスのデータがキャッシュ上にあれば（Ｓ７６６でＹｅｓの場合）、コマンド制御プログラムは、キャッシュ上のデータをＦＯＳに転送し（Ｓ７７６）、ＦＯＳに完了を報告する（Ｓ７８０）。
【００７２】
リード対象アドレスのデータがキャッシュ上に無ければ（Ｓ７６６でＮｏの場合）、コマンド制御プログラムは、仮想デバイス−物理デバイス／外部ＬＵアドレス変換を行い（Ｓ７６８）、リード対象データが格納されているメディアのアドレスを算出し（Ｓ７７０）、メディアアクセスプログラムを起動する。
【００７３】
メディアアクセスプログラムは、算出したメディアのアドレスからデータを読み出して、キャッシュに格納し（Ｓ７７２）、コマンド制御プログラムに対してキャッシュに格納したことを通知する（Ｓ７７４）。
コマンド制御プログラムは、メディアアクセスプログラムからの通知を受領すると、キャッシュ上のデータをＦＯＳに転送し（Ｓ７７６）、完了報告をする（Ｓ７８０）。
【００７４】
ＦＯＳ側へのデータ転送は、具体的にはメモリ間コピーとなる。ライト処理で記載したものと同様である。ＦＯＳは、データを転送された、すなわち、データが自らの領域に格納されたこと、またはメモリの共通領域に格納されたことを（ライト処理と同様の方法によって）知る（Ｓ７７８）。ＦＯＳは、ファイルクライアント機器１０１Ｂへデータを転送する（Ｓ７８２）。
【００７５】
別の実施例として、ブロックマイクロストレージ側だけではなく、ＦＯＳ側にもキャッシュメモリを設けた場合がある。その場合は、キャッシュのヒットミス判定をＦＯＳ側でも行う。ＦＯＳ側のキャッシュにデータが既にあれば、リード要求時はそのままデータを転送し、処理を完了できる。ライト要求の場合は、ＦＯＳ側のキャッシュにライトデータを格納した時点で処理を完了としてもよいし、ブロックストレージ側のキャッシュへライトデータが格納された時点で完了としてもよい。
【００７６】
図６および図７の処理で、ブロックストレージマイクロ制御部が処理する要求キューをまとめてもよい。Ｓ６１４にて格納する要求を、共有領域３２２０にあるキューに入れてもよい。また、Ｓ７３８で一旦共有領域３２２０に要求を格納した後に、ブロックストレージマイクロ制御３２１４Ａにある要求キューに登録してもよい。
【００７７】
通常のＦＯＳでは、ＨＢＡをハードウェアで保持し、ＳＣＳＩコマンドへ変換してＦＣＩ／ＦにてＳＡＮを介してストレージ装置側へアクセスしていた。前記のように、一体型のストレージシステム構成によると、価格の高いＨＢＡが不要となり、内部で直結するため、ＳＡＮを介することもなくコストが低減できるとともに、性能向上を実現できる。
【００７８】
図８に、ハードウェアリソース管理テーブルの例を示す。
この情報により、ハードウェアごとに稼働中か障害閉塞中かの状態、そのハードウェアを使用しているＯＳまたはブロックストレージがわかる。
【００７９】
図８Ａに、ブロックストレージマイクロ制御が持つハードウェアリソース管理情報８０１Ａを示す。ストレージ装置３０内に搭載されるハードウェアリソース全体の情報である。リソース名８０２ＡにＣＰＵ番号、ＣＰＵごとにＣｏｒｅ番号８０３Ａ、ブロックストレージ側で定義しているかの情報８０４Ａがある。
【００８０】
この８０４Ａには、ブロックストレージが使用するリソースには「定義」が登録され、使用しないリソースには「未定義」が登録される。ＣＰＵ１と２は、ブロックストレージが使用するため「定義」と登録される。ＣＰＵ３は、ブロックストレージマイクロ制御で確保していないため「未定義」と登録され、ブロックストレージマイクロ以外のＯＳで使用中という認識を持つ。通常は、未定義という情報だけであるが、バリエーションとして、ハイパバイザが使用するハードウェア情報をブロックストレージマイクロ以外（例えば、ハイパバイザまたは管理サーバまたは他の装置）から受け取って、リソース割り当て状況を具体的に登録してもよい。
【００８１】
８１２Ａにメモリのリソース名、８１３Ａにメモリ空間のアドレスが格納されている。各アドレスに対し、ブロックストレージマイクロ制御側が確保したか否かを８１４Ａに登録する。アドレス１００１〜は他のＯＳと共有している。例えば、図７で説明したリード／ライト要求処理の際、ブロックストレージマイクロ制御以外のＦＯＳなどの要求コマンドを変換する。ここで、上記アドレスは、ブロックストレージマイクロ制御へ処理を委託する場合に、変換したコマンドを格納するアドレスのことで、コマンドを変換するＦＯＳ側と変換したコマンドを参照して処理をするブロックストレージマイクロと、両方からアクセス可能な領域である。８１４Ａの情報では、共有しているか否かは管理せず、ブロックストレージが使えるか否かを管理する。
【００８２】
他のハードウェアリソースである、ポートやハードディスクについても、同様な管理を行う。ポートの場合、例えばＦＣポートとイーサネットポートとがあり、それぞれ番号を管理する。
【００８３】
テーブル８０１Ａのハードウェア全体の管理情報から、ブロックストレージに定義されたリソースのみのテーブルを作成する。例えば、図８Ａに示す８２１Ａや８３１Ａである。８２１Ａは、ブロックストレージが使用するＣＰＵの情報であり、ＣＰＵ１およびＣＰＵ２はブロックストレージが使用するＣＰＵであり、状態が使用中であることがわかる。使用状態８２３Ａには使用中や障害閉塞中などの情報を登録する。
８０１Ａは、ブロックストレージマイクロ制御とハイパバイザが参照するため、両方の制御が見ることができるメモリ領域へ格納する。
【００８４】
図８Bに、ハイパバイザが持つハードウェアリソース管理情報を示す。
ハードウェアリソース管理情報８０１Ｂ、８１１Ｂは、ハイパバイザが持つ情報であり、ハイパバイザが使用するメモリ領域に格納される。ブロックストレージマイクロ制御がもつ、全ハードウェアの管理情報である８０１Ａを参照し、使用状況が未定義のものだけを８０１Ｂ、８１１Ｂ（ポートは図示していない、ＨＤＤは使用しないため無し）に載せる。リソースが既に使用中である（すなわち、ブロックストレージマイクロ制御側で確保済みである）かどうかをまず登録し、その後、ＦＯＳなどの複数ＯＳへリソース分割して割り当てた結果を格納する。リソースごとに誰が使用しているかはハイパバイザが管理する。
【００８５】
メモリ内のアドレス１００１から２０００はブロックストレージと共有領域であるが、ハイパバイザの領域とする。
ハイパバイザは、ＦＯＳなどにハードウェアリソースを仮想化して見せるため、例えば、８２１Ｂに示すように、物理的には１つのＣＰＵ３を複数のＣＰＵであるＶＣＰＵ１から４にみせ、それぞれをハイパバイザの上にのるＯＳへ割り当てることをする。従って、後述する障害が発生し、検知した場合、物理的に障害が発生すると、どのＯＳへ障害の影響があるのかを調べて障害処理を行う必要がある。
【００８６】
図８Cのハードウェアリソース使用情報８０１Ｃは、ブロックストレージ以外の個々のＯＳが持つ情報であり、自らが使えるリソース情報のみを持つ。既述の、ブロックストレージマイクロ制御と共有な領域も自らが使用できるものであり、すなわち使用状態が使用中として管理する。
【００８７】
図９に、ＦＯＳ側の要求コマンドを変換するための情報として、ディレクトリデバイス情報テーブル９０１を示す。ディレクトリデバイス情報テーブル９０１は、ファイルシステム名またはディレクトリ情報と、それがマウントされている場所としてストレージ側から提供されるＬＵ情報との対応関係を示す。このテーブル情報はＦＯＳ側で持つ。本例では、ファイルシステムに対してＬＵを１：１でストレージ側から提供されている。別のバリエーションとして、ＬＵ情報だけではなく、ＬＵ内のアドレス情報との対応関係も格納される。
【００８８】
図１０により、ＦＯＳからブロックストレージマイクロ制御側へのコマンドを共有する方法を説明する。
９１３にコマンドに対して要求元を記載しておき、コマンドの処理が完了した際に、どこへ完了報告をすべきかを明確にしておく。例えば、ブロックストレージの場合、コマンド発行元と認識するのはポートとＬＵ番号であるため、これを情報として持つ。コマンドを処理する場合、要求元まで区別してスケジュールすることもあるので、SCSIのIDやWWＮをもつことで要求元を区別する。ブロック側の要求も同様に発生し、同じ要求コマンドキューへ書き込んでもよいし、別のメモリ領域に要求キューを持たせてもよい。別々の場合はキュー間で処理順序を決めるルールが必要である。コマンドが終了すれば、終了したことをブロックから報告する。
【００８９】
図１１Ａおよび図１１Ｂに、ハードウェアリソースをブロックストレージ装置側とそれ以外のＯＳに割り当てる処理手順を示す。
まず、ストレージ装置３０の電源を入れる（Ｓ１１１０）。ブロックストレージマイクロ制御のみ起動する（Ｓ１１１２）。このように筐体内の一部だけをブートすることは本装置の特徴である。ブロックストレージマイクロ制御は、初期状態（または構成ファイルが定義されていないことを検知する状態）では、最小構成を決定する（Ｓ１１１４）。最小構成とはブロックストレージ側の構成のことで、例えば、２ＰＫ（パッケージ）構成であって、最大で８ＰＫ構成まで組める。このように、デフォルトで一旦は最小構成で立ち上げている。最小構成で構築する際に使用する物理的なＣＰＵコアやメモリは予め決めておく。ここで構成を確定するために、一旦リブートする（Ｓ１１１５）。
【００９０】
ユーザが予め管理装置経由で、ブロックストレージ側の構成を考え、その装置構成において必要となるハードウェア部位の数を決定した情報を、構成ファイルに登録する（Ｓ１１１６）。構成ファイルに登録された構成に従ったブロックストレージ装置を構築する。ユーザは、ブロックストレージ装置を構成する各部位が必要とするハードウェアリソース数と、ブロックストレージ装置以外のＯＳ、ＦＯＳなどが必要とするリソースを考慮し、ＦＯＳなどで必要なリソースを残すようにその数を決める。ブロックストレージマイクロ制御は、リブートすれば、ストレージ装置３０内に接続されるハードウェアを認識し、８０１Ａの管理テーブルを構築する（Ｓ１１１７）。この情報は、最初に最小構成で立ち上げた時のメモリ領域に格納される。
【００９１】
次に、ユーザ定義構成ファイルの内容に従って、ブロックストレージ装置に接続されるハードウェアリソースを認識する（Ｓ１１１８）。認識したハードウェアは８０１Ａの管理テーブルに登録する。ユーザ定義構成ファイルの内容に従ったハードウェアリソースを確保し、構成を定義する（Ｓ１１２０）。具体的には、８０１Ａの使用状況に「定義」と登録する。使用するハードウェアリソースの情報である８２１Ａと８３１Ａを構築し、ブロックストレージマイクロ制御用に確保した制御メモリに格納する（Ｓ１１２２）。構成を確定するためにリブートする（Ｓ１１２３）。
【００９２】
さらに、ハイパバイザを起動する（Ｓ１１２４）。ハイパバイザは、ブロックマイクロ制御部と共有するメモリ領域に格納されたハードウェア管理情報８０１Ａを参照し、ハードウェア全体を認識する（Ｓ１１２６）。ハイパバイザは、使用状況が「未定義」の情報を自らのメモリ領域へ格納する（Ｓ１１２８）。ハイパバイザは、未定義のハードウェアリソースが使用可能であることを認識し、ハイパバイザ用ハードウェア管理情報テーブル８０１Ｂ、８１１Ｂを作成する（Ｓ１１３２）。ハイパバイザは、リブートして構成を確定する（Ｓ１１３４）。ハイパバイザはさらに、８２１Ｂを構築し、ハイパバイザにのる複数ＯＳへ割り当て、割り当てた情報を８１１Ｂ、８２１Ｂへ格納する（Ｓ１１３６）。
【００９３】
別の方法（図１１Ｃ）として、ハイパバイザを起動する（Ｓ１１４２）。ハイパバイザは、ストレージ装置３０内に接続された全てのハードウェアリソースを認識する（Ｓ１１４４）。ハイパバイザは、ブロックストレージマイクロ制御部に、自らが起動したことを報告する（Ｓ１１４６）。報告を受けたブロックストレージマイクロ制御部は、自らのメモリ内に格納した自らが使用するリソース情報をハイパバイザへ提供する（Ｓ１１４８）。ハイパバイザは、受け取った情報を自らのメモリ領域へ格納する（Ｓ１１５０）。ハイパバイザは、受け取った情報からどのハードウェアリソースが使用可能かを認識し、まずハイパバイザ用のメモリ領域を確保する（Ｓ１１５２）。
【００９４】
確保したメモリ領域に、ハイパバイザ用ハードウェア管理情報テーブルを作成して登録する（Ｓ１１５４）。ハイパバイザをリブートする（Ｓ１１５６）。使用可能なリソースをハイパバイザにのる複数ＯＳへ割り当てる（Ｓ１１５８）。割り当てた情報をそれぞれのＯＳが使用するメモリ領域へ格納する（Ｓ１１６０）。ここにおいて、ブロックストレージマイクロ制御部にハイパバイザ側のリソース割り当て情報を提供してもしなくてもよい。また、ブロックストレージマイクロ制御部からハイパバイザへ使用済みハードウェアリソース情報を受け渡す方法として、メモリ空間内コピー、または、アドレス情報を共有することで、情報を共有する方法もある。
【００９５】
Ｓ１１４６からＳ１１５０の処理が、従来のハイパバイザには無い処理である。ハイパバイザがゲストＯＳへリソース割り当てを行う処理は従来技術であるが、使用できるリソース情報を他のＯＳから受け取る処理、受け取った情報により使用するリソースを決定する処理は従来技術には無い処理である。
メモリの確保は、メモリ空間のアドレスまたは容量を指定することにより行われる。障害等を考慮して２重化した構成で確保する。
【００９６】
図１２は、リソースが追加された場合の構成定義手順を示すフローチャートである。
ハードウェアリソースが追加されれば、追加されたリソースを含めてユーザが管理装置において構成ファイルを作成しなおし登録する。ブロックストレージマイクロ制御はオン中のまま、ユーザが定義した構成ファイルに従って接続するハードウェアリソースを認識する。認識しなおすトリガーは、ユーザがストレージ装置３０へ指示を出してもよいし、ストレージ装置３０が検出する手段を持っていてもよい。図１１のフローチャートと同様に構成を定義する。原則として、追加されたハードウェアリソースを割り振る操作となり、既に使用しているリソースについては最初に割り当てたままとする。ハイパバイザ側の処理は、図１１ＢのＳ１１２６以降から同じである。
【００９７】
リソース追加の場合、原則、現状確保しているリソースはそのまま同じものを確保する。追加になったリソースをブロックストレージマイクロ制御側とそれ以外に割り当てる。
リソース追加では、ハイパバイザがリブートをせずに、ブロックストレージマイクロ制御のトリガによってリソース追加及び使用可能情報を取得し、ゲストＯＳへ割り当て処理を行う箇所が従来と異なる。
【００９８】
次に、リソースを減設、つまり、削除する場合の手順を以下に示す。
削除対象となるリソースがメモリ空間の場合、削除するメモリ容量をメモリ空間のどこにするかを決定する。削除するメモリ空間に格納されているデータ及び制御情報を削除しないメモリ空間へ退避する。次処理からはコピー先のデータを使用する。図１２のフローチャートと同様に、ユーザが管理装置経由にて削除したメモリ空間アドレスを構成ファイルに作成しなおし登録する。以降は図１２のフローと同様の処理となる。
【００９９】
削除対象となるリソースがプロセッサの場合、削除の指示が出れば、削除対象のプロセッサはしかかり中の処理を完了し終了させるまで、新規処理を開始しない。処理の切れ目で、削除するプロセッサがもっていた処理待ちキューなどのデータを他のプロセッサへ委託する。委託されたプロセッサはもともと持っていた処理キューとマージして、自らのメモリへその情報を登録する。削除するリソースの情報には使用不可（または閉塞など）状態を登録する。以降は、図１２のフローと同様の処理となる。
ディスクの削除については、ストレージシステムの従来方法と同様でよい。
【０１００】
図１３は、ブロックストレージのハードウェアリソースをブロックストレージ以外に動的に割り当てなおす処理を示すフローチャートである。
前述のリソース削除処理により、ブロックストレージ側で使用しているハードウェアのうち、削除対象となるリソースの使用をやめる。削除するリソースを使用不可などの状態とし、使用できない状態にする（Ｓ１３１０）。ユーザが構成ファイルを作成しなおす際、削除対象となるリソースを選択しないように指定する（Ｓ１３１２）。例えば、使用不可のメモリアドレスを指定しないなどがある。ユーザが作成しなおした構成ファイルに従って、接続するハードウェアリソースから確保し構成を定義する（Ｓ１３１６）。その後、使用不可の状態にしていたハードウェアの使用状態を使用可能とする（Ｓ１３１８）。以降の処理は、図１１ＢのＳ１１２６からＳ１１３６の処理と同様となる。
【０１０１】
図１４は、ブロックストレージ以外が使用しているハードウェアリソースをブロックストレージ側へ動的に割り当てなおす処理を示すフローチャートである。
例えば、ＦＯＳ側のファイルシステムを縮小する場合など、ハードウェア能力が余る場合、ＦＯＳ側からハードウェアを解放してブロックストレージ側に割り当てなおすことができる。
【０１０２】
ハードウェアリソースの削除処理は、前記に示した処理で行う。ハイパバイザが削除処理を起動し（Ｓ１４１０）、各ＯＳに削除処理を実行させる（Ｓ１４１２）。削除すれば、ハイパバイザが削除後の現状使用できるリソースを割り当てなおし（Ｓ１４１６）、ハイパバイザの情報へ登録する（Ｓ１４２０）。以降に続く、構成ファイルの作成しなおし及びブロックストレージ側への割り当てなおし（追加）については、図１２のフローに準ずることになる。
【０１０３】
ブロックストレージマイクロ制御とハイパバイザの協調処理の１つに、障害処理がある。従来、ストレージ装置の各筐体にＯＳが搭載され、ＯＳ毎に障害管理をするための環境系プログラムや共通ロジックプログラムなどを設けていた（例えば、図１７に示す障害プログラム３１６）。ハードウェア側で障害が発生したならば、各ＯＳへ障害報告を上げ、ＯＳ側で障害対処プログラムを起動して対応していた。
【０１０４】
本発明のストレージシステムにおいては、ＯＳ毎にあった環境系や共通ロジックをまとめる必要がある。なぜならば、障害が発生してそれぞれの障害プログラムを起動すると、例えばハイパバイザ側が管理するハードウェアに障害が発生した場合、可用性に対する許容度がブロックストレージ装置と異なることから、ハイパバイザの障害に対する判断を採用するとブロックストレージ装置の可用性が落ちてしまう、という事態が起こる。
【０１０５】
また、ブロックストレージマイクロ制御側の処理は、ハイパバイザを介することによりオーバヘッドがかかるため、ブロックストレージ装置側の処理性能がダウンする可能性がある。ブロックストレージ装置の可用性を落とさず、ハイパバイザと協調処理できるようにするために、障害処理の主導権をブロックストレージマイクロ制御側に持たせる。それにより、障害を検出した場合は、ブロックストレージマイクロ制御側にまず報告をあげる処理とする。
【０１０６】
ただし、ハイパバイザ側でのみ使用するハードウェアについては障害処理をする必要が無い場合がある。そのために、ブロックストレージとハイパバイザとで、障害処理を実施する対象となるリソースを切り分けておく（担当を決めておく）。そのリソースに障害が発生した際、障害が発生したことを示す情報（障害発生情報）を登録するメモリ領域を、 ハイパバイザ側かブロックストレージマイクロ制御部のどちらに設けるかを決める。そのリソースの障害がブロックストレージマイクロ制御部の障害処理に関連があれば、障害発生情報をブロックストレージマイクロ制御部側のメモリ領域へ格納してその情報を見るべき制御部の側に置く。 
【０１０７】
次に、障害処理について説明する。障害処理においても、ブロックストレージマイクロ制御とハイパバイザが協調して処理をする必要がある。
ストレージ装置３０内の各ハードウェアに障害が発生した場合、障害を検出するハードウェアである障害監視がそれを検出する。
【０１０８】
対象となるハードウェアリソースは、以下の４種類に分類される。
（１）ブロックストレージとブロックストレージ以外（ハイパバイザとハイパバイザ上で動作するＯＳ群）で共有されるリソース
（２）ブロックストレージで占有されるリソース
（３）ブロックストレージ以外のハイパバイザ上で動作するＯＳ間で共有されるリソース
（４）ブロックストレージ以外のハイパバイザ上で動作するＯＳで占有されるリソース
【０１０９】
各ハードウェアリソースは、あらかじめ設定された側へ障害を通知し、割り込みを上げる。上記（１）および（２）の場合は、図２１に示されるように、ブロックストレージマイクロ制御部へ障害を通知し割り込みを上げる。上記（３）の場合は、図２２に示されるように、ハイパバイザへ障害を通知し割り込みを上げる。上記（４）の場合は、各ＯＳへ障害を通知し割り込みを上げる。
【０１１０】
このために、各ハードウェアリソースには、どこへ障害を通知するかの通知先も登録する必要がある。メモリ３２１内に障害処理用の領域を確保し、全ハードウェアリソースの障害報告先を登録する情報管理テーブルに登録し、障害を検知した場合、前記情報管理テーブルを参照し、障害報告先へ障害発生を通知する。前記情報管理テーブルを図２３に示す。例えば、ＣＰＵの障害管理テーブル２３００の２３１４に格納する使用者情報が、障害通知先となる。使用者がブロックである場合はブロックストレージマイクロ制御側へ返信し、使用者がＦＯＳの場合はＦＯＳへ返信する。
【０１１１】
上記（１）の例として、ハードディスクの障害がある。ハードディスクはブロックストレージとＦＯＳなど種々のＯＳから使用される。従って、ハードディスクの障害が起こった際には、障害部位に格納されたデータがどのＯＳのデータであるかは、ディスク制御側で管理していないため、全体へ障害発生を通知する。
【０１１２】
また、図２３に示したメモリの場合、１枚のメモリ単位に障害か正常かの判定をする。このケースでは、メモリが共有されているため（上記（１）の場合）、メモリを使用しているブロックに障害を返信する。
【０１１３】
障害の検出方法として、ＣＰＵ、メモリ、ディスクなどは障害監視によってハードウェアが自らで障害を認識できる。ポートは自らが検出できないため、障害検出プログラム等が一定間隔で障害がないかどうか見に行くためのジョブを起こすなどによって対応する。障害を見つければ、前記障害報告先を登録する情報管理テーブルを参照し、報告先を検索して障害を報告する。ポートは、上記（２）又は（４）のどちらかに報告する。
【０１１４】
ハイパバイザ上で動作するＯＳの一つが占有するリソースに障害が発生し、かつ、そのＯＳがフェイルオーバする必要がある場合は、ＯＳがのっているハイパバイザからブロックストレージマイクロ制御部へ障害を通知する。
【０１１５】
従来、ハイパバイザは接続している全てのハードウェアリソースを認識し、障害についても検知しようとする。また、ブロックストレージにおいては、同様に全てのハードウェアリソースの障害を検知しようとする。しかし、ユニファイドストレージシステムにおいては、ハードウェアリソースをブロックストレージとハイパバイザ側とに分けて割り当てるために、障害処理も分けて行う。すなわち、それぞれのＯＳで閉じた処理はＯＳ内で行い、両方で共通して使用するものについての処理はどちらがやるかを決めておく必要がある。この方式により、障害処理の主導権はリカバリ能力の高いブロックストレージマイクロ制御側がもつが、ブロックストレージマイクロ制御側に関係がないハードウェアについては、各ＯＳまたはハイパバイザに処理を任せる。
【０１１６】
他の構成バリエーションとして、１番目は、ハイパバイザのみに障害プログラムを設け、ブロックストレージ制御側を含めてハイパバイザが管理する。ブロックストレージがストレージシステム内に存在しない構成の場合、ハイパバイザに障害報告をし、ハイパバイザの障害処理プログラムで対応する。サーバやファイルシステムに対応するレベルでの障害処理となる。
【０１１７】
２番目は、ブロックストレージマイクロ制御部のみに障害プログラムを設ける。ハイパバイザが最初から存在しない、もしくは、途中でハイパバイザを削除した場合に相当する。ブロックストレージレベルでの障害処理プログラムを起動する。途中でハイパバイザを削除する場合は、削除前処理として、ハイパバイザが担当していた障害処理をブロックストレージマイクロ制御部が引き継ぐ。
【０１１８】
なお、本発明は、実施形態そのままに限定されるものではなく、実施段階では、その要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１１９】
また、実施形態で示された各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能等を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid  State  Drive）等の記録或いは記憶装置、またはＩＣ（Integrated  Circuit）カード、ＳＤメモリカード、ＤＶＤ（Digital  Versatile  Disc）等の記録或いは記憶媒体に格納することができる。
【０１２０】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。
【符号の説明】
【０１２１】
２０：管理装置
３０：ストレージ装置
３１：制御プロセッサ（ＣＰＵ）
３２：メモリ
３３：ディスクインターフェース
３４：物理デバイス
３５：ＨＢＡ
３６：ＮＩＣ
３７：バス
３９：保守管理インターフェース
１０１：クライアント機器
１０６，１０７：ネットワーク
１０８：管理ネットワーク
【要約】
【課題】従来のユニファイドストレージシステムでは、ブロックストレージ用のI／Oおよびファイルストレージ用のI／OをシングルＯＳ上で区別せずに処理するため、迅速な障害検出やハードウェアの直接監視を通した性能チューニングのような性能向上のために行う処理を実施できない面があった。
【解決手段】ブロックストレージ側ＯＳとブロックストレージ以外のファイルシステムを含む複数システムを管理するＯＳ群とに分けて共存させ、ブロックストレージ以外のファイルシステムを含む複数システムを管理するＯＳ群はハイパバイザによって仮想化されるように構成したストレージシステムにより、ブロックストレージマイクロ制御とハイパバイザの処理を協調して動作させる。
【選択図】図１【図１】
0005877552.tif 000002
【図２】
0005877552.tif 000003
【図３】
0005877552.tif 000004
【図４Ａ】
0005877552.tif 000005
【図４Ｂ】
0005877552.tif 000006
【図５】
0005877552.tif 000007
【図６】
0005877552.tif 000008
【図７】
0005877552.tif 000009
【図８Ａ】
0005877552.tif 000010
【図８Ｂ】
0005877552.tif 000011
【図８Ｃ】
0005877552.tif 000012
【図９】
0005877552.tif 000013
【図１０】
0005877552.tif 000014
【図１１Ａ】
0005877552.tif 000015
【図１１Ｂ】
0005877552.tif 000016
【図１１Ｃ】
0005877552.tif 000017
【図１２】
0005877552.tif 000018
【図１３】
0005877552.tif 000019
【図１４】
0005877552.tif 000020
【図１５】
0005877552.tif 000021
【図１６】
0005877552.tif 000022
【図１７】
0005877552.tif 000023
【図１８】
0005877552.tif 000024
【図１９】
0005877552.tif 000025
【図２０】
0005877552.tif 000026
【図２１】
0005877552.tif 000027
【図２２】
0005877552.tif 000028
【図２３】
0005877552.tif 000029