JP2016119110A - ストレージシステム及びリソース割当て方法 - Google Patents

Abstract

【課題】従来のユニファイドストレージシステムでは、ブロックストレージ用のI／Oおよびファイルストレージ用のI／OをシングルＯＳ上で区別せずに処理するため、迅速な障害検出やハードウェアの直接監視を通した性能チューニングのような性能向上のために行う処理を実施できない面があった。【解決手段】ブロックストレージ側ＯＳとブロックストレージ以外のファイルシステムを含む複数システムを管理するＯＳ群とに分けて共存させ、ブロックストレージ以外のファイルシステムを含む複数システムを管理するＯＳ群はハイパバイザによって仮想化されるように構成したストレージシステムにより、ブロックストレージマイクロ制御とハイパバイザの処理を協調して動作させる。【選択図】図１

Description

本発明は、ストレージシステム及びリソース割当て方法に関するものである。

従来から、ホスト計算機に対して大規模なデータストレージサービスを提供する計算機システムが存在する。このシステムは、ホスト計算機、ホスト計算機が接続するストレージ装置及びストレージ装置の管理装置を備えたものとして知られている。
ストレージ装置は、複数のハードディスクを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）等の記録或いは記憶媒体に格納することができる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

２０：管理装置
３０：ストレージ装置
３１：制御プロセッサ（ＣＰＵ）
３２：メモリ
３３：ディスクインターフェース
３４：物理デバイス
３５：ＨＢＡ
３６：ＮＩＣ
３７：バス
３９：保守管理インターフェース
１０１：クライアント機器
１０６，１０７：ネットワーク
１０８：管理ネットワーク

Claims (15)

1. ブロックストレージ側ＯＳと、
   該ブロックストレージ側ＯＳ以外のハイパバイザ上で動作する複数ＯＳを含む複数システムを管理するＯＳ群と、
   前記ブロックストレージ側ＯＳによって直接的に当該ブロックストレージ側ＯＳに割り当てられる第１のリソース部分と、前記ハイパバイザによって論理分割を使用して前記ＯＳ群中のいずれかのＯＳに割り当てられる第２のリソース部分と、を含むハードウェアリソースと
   から構成されることを特徴とするストレージシステム。
2. 請求項１記載のストレージシステムであって、
   前記第１のリソース部分は、前記ハイパバイザによる前記第２のリソース部分の割り当てに先立って優先的に割り当てられることを特徴とするストレージシステム。
3. 請求項１記載のストレージシステムであって、
   前記ブロックストレージ側ＯＳと該ブロックストレージ側ＯＳ以外の前記ＯＳ群を独立に、順番にブートすることを特徴とするストレージシステム。
4. 請求項１記載のストレージシステムであって、
   当該ストレージシステム全体の処理は前記ブロックストレージ側ＯＳが主導権をもって実行する
   ことを特徴とするストレージシステム。
5. 請求項１記載のストレージシステムであって、
   前記ハードウェアリソースの構成を設定するための情報に基づいて、前記ブロックストレージ側ＯＳに対して前記第１のリソース部分を確保するために該ブロックストレージ側ＯＳが作成する第１の構成管理テーブルと、
   前記ハイパバイザが前記ＯＳ群中のいずれかのＯＳに対して前記第２のリソース部分を確保するために、前記第１の構成管理テーブルに基づいて前記ハイパバイザが作成する第２の構成管理テーブルと
   を有することを特徴とするストレージシステム。
6. 請求項１記載のストレージシステムであって、
   前記ハードウェアリソースの構成を設定するための情報に基づいて、前記ブロックストレージ側ＯＳに対して前記第１のリソース部分を確保するために該ブロックストレージ側ＯＳが作成する第１の構成管理テーブルと、
   前記ハイパバイザが前記ＯＳ群中のいずれかのＯＳに対して前記第２のリソース部分を確保するために、前記ブロックストレージ側ＯＳから前記第１のリソース部分の情報を受け取ることにより前記ハイパバイザが作成する第２の構成管理テーブルと
   を有することを特徴とするストレージシステム。
7. 請求項５記載のストレージシステムであって、
   ハードウェアリソースを追加する時には、
   前記ブロックストレージ側ＯＳは、該追加するハードウェアリソースを認識して前記第1の構成管理テーブルを再構築して、該追加するハードウェアリソースの一部分が前記第１のリソース部分として使用される場合には該追加するハードウェアリソースの一部分を自らに対して確保し、
   前記ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを再構築して、前記追加するハードウェアリソースの残り部分を前記第２のリソース部分として自らが使用する
   ことを特徴とするストレージシステム。
8. 請求項５記載のストレージシステムであって、
   ハードウェアリソースを削除する時には、
   前記ブロックストレージ側ＯＳは、該削除するハードウェアリソースを認識して前記第1の構成管理テーブルを再構築して、該削除するハードウェアリソースを自らが確保している場合にはそれを使用不可の状態にし、
   前記ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを再構築して、前記削除するハードウェアリソースを自らが確保している場合にはそれを使用不可の状態にする
   ことを特徴とするストレージシステム。
9. 請求項５記載のストレージシステムであって、
   前記ブロックストレージ側ＯＳが確保しているハードウェアリソースを該ＯＳ以外に動的に割り当てなおす時には、
   前記ブロックストレージ側ＯＳは、該動的に割り当てなおす対象のハードウェアリソースを使用不可の状態にして、前記第１の構成管理テーブルを再構築した後に使用可能な状態に戻し、
   前記ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを再構築して、前記使用可能な状態のハードウェアリソースを確保する
   ことを特徴とするストレージシステム。
10. 請求項５記載のストレージシステムであって、
    前記ブロックストレージ側ＯＳ以外のＯＳ群中のいずれかのＯＳが確保しているハードウェアリソースを前記ブロックストレージ側ＯＳに動的に割り当てなおす時には、
    前記ハイパバイザは、前記ＯＳ群中のいずれかのＯＳが自ら確保していた前記ハードウェアリソースを使用不可の状態にして、前記第２の構成管理テーブルを再構築した後に使用可能な状態に戻し、
    前記ブロックストレージ側ＯＳは、前記第２の構成管理テーブルに基づいて前記第１の構成管理テーブルを再構築して、前記使用可能な状態のハードウェアリソースを確保することを特徴とするストレージシステム。
11. 請求項１記載のストレージシステムであって、
    前記ハードウェアリソースは、その障害発生時に、
    該障害発生したハードウェアリソースが前記ブロックストレージ側ＯＳまたは前記ＯＳ群中のいずれかのＯＳに占有されている場合には、該占有するＯＳへ該障害発生を通知し、
    該障害発生したハードウェアリソースが前記ブロックストレージ側ＯＳ、前記ハイパバイザおよび前記ハイパバイザ上で動作するＯＳ群に共有されている場合には、前記ブロックストレージ側ＯＳへ該障害発生を通知し、
    該障害発生したハードウェアリソースが前記ハイパバイザ上で動作する前記ＯＳ群中のいずれかのＯＳ間で共有されている場合には、前記ハイパバイザへ該障害発生を通知することを特徴とするストレージシステム。
12. ブロックストレージ側ＯＳと該ブロックストレージ側ＯＳ以外のファイルシステムを含む複数システムを管理するＯＳ群とが共存するストレージシステムにハードウェアリソースを割り当てる方法であって、
    前記ブロックストレージ側ＯＳを起動し、該ＯＳは、前記ハードウェアリソースの設定構成情報に基づいて第１の構成管理テーブルを構築して、自らが使用するハードウェアリソースを確保する第１のステップと、
    前記第１のステップの後に、前記ブロックストレージ以外のＯＳ群を仮想化するハイパバイザを起動し、該ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを構築して、前記ブロックストレージ側ＯＳが確保しなかったハードウェアリソースを自らが使用するハードウェアリソースとして確保する第２のステップと
    を有することを特徴とするリソース割当て方法。
13. 請求項１２記載のリソース割当て方法であって、
    ハードウェアリソースをさらに追加する時には、
    前記ブロックストレージ側ＯＳは、該追加するハードウェアリソースを認識して前記第1の構成管理テーブルを再構築して、自らが使用する場合には該追加するハードウェアリソースを確保する第３のステップと、
    前記第３のステップの後に、前記ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを再構築して、前記ブロックストレージ側ＯＳが前記追加するハードウェアリソースを確保しなかった場合には自らが使用するハードウェアリソースとして確保する第４のステップと
    を有することを特徴とするリソース割当て方法。
14. 請求項１２記載のリソース割当て方法であって、
    前記ブロックストレージ側ＯＳが確保しているハードウェアリソースを該ＯＳ以外に動的に割り当てなおす時には、
    前記ブロックストレージ側ＯＳは、該動的に割り当てなおす対象のハードウェアリソースを使用不可の状態にし、続いて前記第1の構成管理テーブルを再構築し、その後に使用
    可能な状態に戻す第５のステップと、
    前記第５のステップの後に、前記ハイパバイザは、前記第１の構成管理テーブルに基づいて第２の構成管理テーブルを再構築し、続いて前記使用可能な状態のハードウェアリソースを確保する第６のステップと
    を有することを特徴とするリソース割当て方法。
15. 請求項１２記載のリソース割当て方法であって、
    前記ブロックストレージ側ＯＳ以外のＯＳ群中のいずれかのＯＳが確保しているハードウェアリソースを前記ブロックストレージ側ＯＳに動的に割り当てなおす時には、
    前記ハイパバイザは、前記ＯＳ群中のいずれかのＯＳが自ら確保していた前記ハードウェアリソースを使用不可の状態にし、続いて前記第２の構成管理テーブルを再構築し、その後に使用可能な状態に戻す第７のステップと、
    前記第７のステップの後に、前記ブロックストレージ側ＯＳは、前記第２の構成管理テーブルに基づいて前記第１の構成管理テーブルを再構築し、続いて前記使用可能な状態のハードウェアリソースを確保する第８のステップと
    を有することを特徴とするリソース割当て方法。
    
    

Images