(57)【特許請求の範囲】
【請求項１】
データを記憶する複数のドライブと、前記複数ドライブ上の記憶領域を管理する手段を有する記憶装置において、
インターネットプロトコルパケットの入出力を行う複数のポートと、ブロックデータ及びファイルデータの入出力処理手段と、ファイルデータとブロックデータの相互変換を行う機能を有するファイルシステムを備え、
前記記憶領域は、ブロックデータとして入出力されるデータを記憶する第一の記憶領域と、ファイルデータとして入出力されるデータを記憶する第二の記憶領域から成り、
前記ブロックデータ及びファイルデータの入出力処理手段は入出力されるデータがブロックデータかファイルデータかを識別し、ブロックデータあるいはファイルデータとして処理する機能を有しており、
ブロックデータはブロックデータ及びファイルデータの入出力処理手段と前記記憶領域を管理する手段を介して前記第一の記憶領域に対する書込みまたは読出しを行い、
ファイルデータは、ブロックデータ及びファイルデータの入出力処理手段と前記ファイルシステムと前記記憶領域を管理する手段を介して前記第二の記憶領域に対する書込みまたは読出しを行うことを特徴とする記憶装置。
【請求項２】
請求項１記載の記憶装置において、
前記ブロックデータ及びファイルデータの入出力処理手段は、
入出力されるデータに対してインターネットプロトコル処理を行い、インターネットプロトコルパケット内のＴＣＰパケット内に示されているポート番号により、ブロックデータ用のパケットか、あるいはファイルデータ用のパケットかを識別することを特徴とする記憶装置。
【請求項３】
請求項１記載の記憶装置において、
前記記憶装置の記憶領域を前記第一の記憶領域と前記第二の記憶領域に分割する手段を有し、かつ該手段は前記第一の記憶領域の一部を前記第二の記憶領域へ割当て換えする手段と、前記第二の記憶領域の一部を前記第一の記憶領域へ割当て換えする手段を有することを特徴とする記憶装置。
【請求項４】
請求項１記載の記憶装置において、
前記記憶装置の記憶領域は、前記第一の記憶領域と、前記第二の記憶領域と、前記第一及び第二の記憶領域のいずれにも属さない第三の記憶領域から成り、
前記記憶装置の記憶領域を前記第一の記憶領域と、前記第二の記憶領域と、前記第三の記憶領域に分割する手段を有し、かつ該手段は前記第三の記憶領域の一部を必要に応じて前記第一の記憶領域または前記第二の記憶領域に割当て換えする手段を有することを特徴とする記憶装置。
【請求項５】
請求項１記載の記憶装置と、該記憶装置のブロックデータの入出力を行うポートを介して接続された他のブロックデータを記憶する記憶装置との間でのファイルデータのバックアップ方法であって、
前記請求項１記載の記憶装置の前記記憶領域を管理する手段とブロックデータ及びファイルデータの入出力処理手段とインターネットプロトコルパケットの入出力を行うポートを介して、前記他のブロックデータを記憶する記憶装置に対し、前記請求項１記載の記憶装置のファイルデータを記憶する第二の記憶領域のデータの入出力を行うことを特徴とするファイルデータのバックアップ方法。
【請求項６】
第一の前記請求項１記載の記憶装置（以下、第一の記憶装置）と第二の前記請求項１記載の記憶装置（以下、第二の記憶装置）間でファイルデータのコピーを行うコピー方法であって、
予め前記インターネットプロトコルパケットの入出力を行うポートを介して、前記第一の記憶装置の前記ファイルシステムから前記第二の記憶装置の前記ファイルシステムへ、前記第二の記憶領域内のコピー対象となる部分を通知し、その後、前記記憶領域を管理する手段、ブロックデータ及びファイルデータの入出力処理手段、及びインターネットプロトコルパケットの入出力を行うポートを介して、前記第一の記憶装置から前記第二の記憶装置へ前記記憶領域のコピー対象部分をコピーすることを特徴とするファイルデータのコピー方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データをドライブに格納する記憶装置、より詳細にはブロックデータ形式でデータの入出力を行う記憶装置、及びファイルデータ形式でデータの入出力を行う記憶装置に関する。
【０００２】
【従来の技術】
現在の情報化社会では、インターネットを介した企業間電子商取引やサプライチェーンマネージメントに代表される企業間連携の普及によりデータ活用が企業戦略上重要な役割を担っている。
こうした背景の中、情報を蓄えるストレージシステムはITプラットフォームの中心的存在となっいる。
また、情報量の爆発的な増加に伴いストレージシステムの維持、管理に要するコストも急激に増加している。
このため、各企業はストレージシステム及びそれに繋がるサーバ群をデータセンターの中に集中化し、各種サーバからのデータ共有を可能にしてデータの一元管理を行うとともに、システム全体の運用、保守、管理を容易にし、ＴＣＯ（Ｔｏｔａｌ  Ｃｏｓｔ  ｏｆ  Ｏｗｎｅｒｓｈｉｐ）を削減する傾向にある。
【０００３】
各種サーバ群からストレージ群に蓄えられたデータを共有する方法としては、サーバとストレージ間を接続するインタフェースであるファイバチャネルとファイバチャネル用のスイッチを用いて、複数のサーバと複数のストレージ間を多対多で接続するストレージ専用のネットワークであるストレージ・エリア・ネットワーク（以下、ＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）と略す）が知られている。
サーバ上で実行されるアプリケーションは、データをファイル形式のデータとして扱う一方、ディスクアレイに代表されるＳＡＮに繋がるストレージはデータをブロック形式のデータとしてデータの入出力を行う。
したがって、サーバとストレージとの間でデータの入出力を行う際は、サーバ上のファイルシステムがファイル形式のデータをブロック形式のデータに変換し、ＳＡＮを介してストレージへの入出力を行う。
【０００４】
一方最近では、ネットワーク接続型ストレージ（以下ＮＡＳ（ＮｅｔｗｏｒｋＡｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）と略す）が、各種サーバからストレージに蓄えられたデータを共有する方法として急激に普及してきている。
ＮＡＳは、ストレージ内にファイルシステムを持ち、サーバとＮＡＳの間はファイル形式のデータとしてデータの入出力が行われ、ＮＡＳ内のファイルシステムにおいてファイル形式のデータをブロック形式のデータに変換してドライブに記憶する。
したがってＮＡＳは、サーバ間で通信を行う一般的なネットワークとして浸透しているＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続される。
上記のように、データを共有する手段としてＳＡＮ及びＮＡＳが普及してきており、図２に示すように、データセンタ内で、ＦＣ（ファイバチャネル）ベースのＳＡＮ２に繋がるディスクアレイ装置６に代表されるストレージとＬＡＮ３に繋がるＮＡＳ７が混在する環境が広まっている。
【０００５】
また、上記でＳＡＮはブロック形式のデータのやり取りを行うファイバーチャネルをベースとしたネットワークであると述べたが、現在、ＬＡＮ３を介して行われるホストサーバ１間の通信において一般的に使われているインターネットプロトコル（以下ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｃｏｌ）と略す）通信を利用して、ホストサーバとストレージ間のブロック形式のデータの入出力を行うための方式の標準化が進められており、将来的には、イーサネットをベースとしたＳＡＮ９が普及してくると考えられている。
この場合、図３に示すような形態でディスクアレイ装置６とＮＡＳ７が混在する環境になることが考えられる。
ＬＡＮ３に繋がっているＮＡＳ７は、ホストサーバ１との間で大量のデータのやり取りを行うため、ＬＡＮ３の負荷を圧迫し、重要なホストサーバ１間の通信を阻害する可能性が十分にある。
したがって、イーサネットベースのＳＡＮ９が普及した場合、図３に示すＮＡＳ７はイーサネットベースのＳＡＮ９の方に接続される形態が考えられる。
【０００６】
【発明が解決しようとする課題】
図２、図３に示すように、形態はそれぞれ異なるものの、データセンターの中でディスクアレイ装置６とＮＡＳ７が混在する環境が今後ますます普及していくと考えられている。このように異種システムが別個に存在する環境では、システムの保守・管理が複雑になるという問題がある。
また、ディスクアレイ装置６とＮＡＳ７どちらにおいても、ドライブに記憶するのはブロック形式のデータであるので、データを記憶するためのドライブを共用することは理論的に可能である。しかしながら、従来は別個のシステムであったためドライブを共用することが難しいという問題があった。
また、ＮＡＳでは他の記憶装置とのデータのやり取りにファイルシステムを介するため、ファイルシステムを介さないでブロック形式のデータを直接やり取りするディスクアレイ装置等の記憶装置に比べて、データのバックアップやコピーが遅いという問題があった。
本発明の目的は、ドライブ容量の有効利用が可能で、且つシステムの管理が容易な記憶装置を提供し、記憶装置のＴＣＯを削減することにある。
より具体的には、本発明の目的は、ディスクアレイ装置に代表されるブロック形式データの記憶装置とＮＡＳに代表されるファイル形式データの記憶装置の混在環境において、ドライブ容量の有効利用が可能で、且つ管理が簡単化された記憶装置を提供すること、また、ファイル形式データのバックアップ及びコピーを高速化可能な記憶装置を提供することにある。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明では、
データを記憶する複数のドライブと、前記複数ドライブ上の記憶領域を管理する手段を有する記憶装置において、
ブロックデータの入出力を行うポート、ファイルデータの入出力を行うポート、ブロックデータの入出力処理手段、ファイルデータの入出力処理手段、及びファイルデータとブロックデータの相互変換を行う機能を有するファイルシステムを備え、
前記ブロックデータの入出力を行うポートから入出力されるデータは、前記ブロックデータの入出力処理手段と前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行い、前記ファイルデータの入出力を行うポートから入出力されるデータは、前記ファイルデータの入出力処理手段と前記ファイルシステムと前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行うようにしている。
また、前記記憶装置の記憶領域は、ブロックデータとして入出力されるデータを記憶する第一の記憶領域と、ファイルデータとして入出力されるデータを記憶する第二の記憶領域から成っており、
前記記憶装置の記憶領域を前記第一の記憶領域と前記第二の記憶領域に分割する手段を有し、
前記記憶領域を分割する手段が、前記第一の記憶領域の一部を前記第二の記憶領域へ割当て換えする手段、及び前記第二の記憶領域の一部を前記第一の記憶領域へ割当て換えする手段を有するようにしている。
また、前記記憶装置の記憶領域は、ブロックデータとして入出力されるデータを記憶する第一の記憶領域、ファイルデータとして入出力されるデータを記憶する第二の記憶領域、及び前記第一及び第二の記憶領域のいずれにも属さない第三の記憶領域から成っており、
前記記憶装置の記憶領域を前記第一の記憶領域、前記第二の記憶領域、及び前記第三の記憶領域に分割する手段を有し、
前記記憶領域を分割する手段が、前記第三の記憶領域の一部を必要に応じて前記第一の記憶領域または前記第二の記憶領域に割当て換えする手段を有するようにしている。
また、前記記憶装置が有する前記ポートの総数は固定されており、その中でブロックデータの入出力を処理するポートの数、及びファイルデータの入出力を処理するポート数を可変とするようにしている。
また、データを記憶する複数のドライブと、前記複数ドライブ上の記憶領域を管理する手段を有する記憶装置において、
インターネットプロトコルパケットの入出力を行う複数のポート、ブロックデータ及びファイルデータの入出力処理手段、及びファイルデータとブロックデータの相互変換を行う機能を有するファイルシステムを備え、
前記複数のポートは、ブロックデータの入出力を行う第一のポートグループとファイルデータの入出力を行う第二のポートグループに分けられており、前記第一のポートグループから入出力されるデータは、前記ブロックデータ及びファイルデータの入出力処理手段と前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行い、前記第二のポートグループから入出力されるデータは、前記ブロックデータ及びファイルデータの入出力処理手段と前記ファイルシステムと前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行うようにしている。
また、データを記憶する複数のドライブと、前記複数ドライブ上の記憶領域を管理する手段を有する記憶装置において、
インターネットプロトコルパケットの入出力を行う複数のポート、ブロックデータ及びファイルデータの入出力処理手段、及びファイルデータとブロックデータの相互変換を行う機能を有するファイルシステムを備え、
前記ブロックデータ及びファイルデータの入出力処理手段は入出力されるデータがブロックデータかファイルデータかを識別し、ブロックデータあるいはファイルデータとして処理する機能を有しており、ブロックデータはブロックデータ及びファイルデータの入出力処理手段と前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行い、ファイルデータは、ブロックデータ及びファイルデータの入出力処理手段と前記ファイルシステムと前記記憶領域を管理する手段を介して前記記憶領域に対する書込みまたは読出しを行うようにしている。
【０００８】
【発明の実施の形態】
以下、本発明の実施例を図面を用いて説明する。
《実施例１》
図１、図４、及び図７に、本発明の一実施例を示す。
本実施例では、記憶装置の記憶領域を管理する単位が論理ボリュームである場合について述べる。他の場合についても、本実施例の考え方を適用することにより、同様の効果が得られる。
図１は記憶装置１の論理構成を示している。
記憶装置１は、４つのファイバチャネルポート５０、４つのイーサネットポート５２、ブロックデータ入出力処理部１０−ａ、ファイルデータ入出力処理部１０−ｂ、論理ボリューム管理部３０、ファイルシステム２０、論理ボリューム３５−ａ、ｂから構成される。
論理ボリューム３５−ａ、ｂは、論理ボリューム管理部３０により複数のドライブの物理アドレス上に形成され、論理ボリューム管理部３０はこの複数ドライブ上の記憶領域を管理し、論理ボリューム管理部３０内に論理ボリュームのアドレスとドライブ上の物理アドレスを対応づけるテーブル（以下、アドレス変換テーブルと略す）が保持される（図示していない）。
論理ボリュームは、ブロック形式のデータ（以下、ブロックデータと略す）記憶用の論理ボリューム３５−ａと、ファイル形式のデータ（以下、ファイルデータと略す）記憶用の論理ボリューム３５−ｂに分ける。
ここで、ファイバチャネルポート５０はこれに限らず、例えばＳＣＳＩポート等のブロックデータの入出力が可能なポートであれば問題ない。
また、イーサネットポートはこれに限らず、ファイルデータの入出力が可能なポートであれば問題ない。
【０００９】
図７に、図１の論理構成の主な実装構成例の１つを示す。
記憶装置１は、それぞれ１つのファイバチャネルポート５０を有する４つのＲＡＩＤモジュール４２と、４つのイーサネットポート５２を有する１つのファイルサーバ４０と、複数のドライブ４４から成る。
ファイルサーバ４０と４つのＲＡＩＤモジュール４２は４本のファイバチャネル４で接続される。
ここで、上記個数は一実施例に過ぎず、個数を上記に限定するものでは無い。
図１の論理構成と図７の実装構成との対応関係を説明すると、図１におけるブロックデータ入出力処理部（１０−ａ）と論理ボリューム管理部（３０）とが図７におけるＲＡＩＤモジュール（４２）にほぼ対応しており、図１におけるファイルデータ入出力処理部（１０−ｂ）とファイルシステム（２０）とが図７におけるファイルサーバ（４０）にほぼ対応しており、ファイルサーバ（４０）の出力はファイバチャネルによりＲＡＩＤモジュール（４２）に接続される。論理ボリューム（３５−ａ，３５−ｂ）がドライブ（４４）に対応している。
【００１０】
ここで、記憶装置の物理的サイズの制限から、記憶装置１が有するポートの総数は８つに固定されるが、ＲＡＩＤモジュール４２の数を増やすことで、ファイバチャネルポート５０の数を増やすことができる。
この場合、ファイバチャネルポートの増加分だけファイルサーバに繋がるイーサネットポート５２の数を減らす。
ファイバチャネルポート５０の数は、１つのＲＡＩＤモジュール４２に繋がるファイバチャネルポート５０の数を増やすことによっても増やせる。
逆に、ファイルサーバ４０に繋がるイーサネットポート５２の数を増やす場合、その増加分だけＲＡＩＤモジュール４２に繋がるファイバチャネルポート５０の数を減らす。
こうすることにより、ユーザの要求に応じて、ファイバチャネルポート５０の数とイーサネットポート５２の数を設定することが可能になる。
【００１１】
図１１に示すように、ＲＡＩＤモジュール４２は、ファイバチャネル４でファイバチャネルポート５０及び図１２に示すファイルサーバからのファイバチャネルに繋がる入出力コントローラ１５０と、ファイバチャネル４でドライブ４４に繋がるドライブコントローラ１６０と、論理ボリュームコントローラ１７０と、データバッファ１６５から成る。
入出力コントローラ１５０では、ブロックデータの入出力処理を行う。
またドライブコントローラ１６０では、ドライブへのブロックデータの書き込み及び読み出し処理を行う。
またデータバッファ１６５では、入出力コントローラ１５０とドライブコントローラ１６０間でのデータのバッファリングを行う。
また論理ボリュームコントローラ１７０では、論理ボリューム構成テーブルを保持し、そのテーブルにより要求されるブロックデータと論理ボリュームの対応付けを行う。また、ブロックデータの論理アドレスと物理アドレスの変換を行う。
【００１２】
図１２に示すように、ファイルサーバ４０は、イーサネット５でイーサネットポート５２に繋がる入出力コントローラ１５１と、ファイバチャネル４でＲＡＩＤモジュール４２に繋がる入出力コントローラ１５２と、プロセッサ１８０と、データバッファ１６６から成る。
入出力コントローラ１５１では、ファイルデータの入出力処理を行う。
また入出力コントローラ１５２では、ＲＡＩＤモジュール４２へのブロックデータの書き込み及び読み出し処理を行う。
またデータバッファ１６６では、入出力コントローラ１５１と入出力コントローラ１５２間でのデータのバッファリングを行う。
またプロセッサ１８０では、ＯＳとしてＵＮＩＸ（登録商標）が動作しており、そのファイルシステムとしてＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）が動作している。
このファイルシステムがホストサーバからアクセスされるファイルデータをブロックデータのアドレスに変換する処理を行う。
ここで、ＯＳはＵＮＩＸに限らず、またファイルシステムもＮＦＳに限らない。ホストサーバからファイルＩＯ（ファイル形式データの入出力要求）を受け取り、それをブロックＩＯ（ブロック形式データの入出力要求）に変換してＲＡＩＤモジュール４２へアクセスする機能を有していれば問題無い。
【００１３】
ブロックデータ用論理ボリューム３５−ａとファイルデータ用論理ボリューム３５−ｂの割当ては、記憶装置１内の構成情報を設定／管理するサービスプロセッサ（以下、ＳＶＰ（Ｓｅｒ‐ｖｉｃｅ Ｐｒｏｃｅｓｓｏｒ）と略す）から、各論理ボリュームの割当てを示す記憶装置１内の論理ボリューム構成テーブルを設定することにより行う。
サービスプロセッサとしては、例えば、記憶装置１とＬＡＮで接続するノートパソコンが利用できる。
サービスプロセッサは図１１に示す論理ボリュームコントローラ１７０にアクセスを行う。
記憶装置１の初期設定時には、総論理ボリュームの内、必要な数の論理ボリュームをブロックデータ用に、残りの数の論理ボリュームをファイルデータ用に割当てる。
記憶装置１を稼動後、例えばブロックデータ用論理ボリューム３５−ａの空きが無くなり、ファイルデータ用論理ボリューム３５−ｂに未使用の論理ボリュームがある場合、サービスプロセッサから論理ボリューム構成テーブルを書き換えることにより、未使用のファイルデータ用論理ボリューム３５−ｂの内、必要な数の論理ボリュームをブロックデータ用論理ボリューム３５−ａに割当て換える。
当然のことであるが、この逆の場合にも論理ボリューム構成テーブルを書き換えることにより、論理ボリュームの割当てを変更する。
【００１４】
以下、ブロックデータ及びファイルデータの書き込み及び読み出し時の各部の動作について示す。
ブロックデータを書き込む場合、ブロックデータはファイバチャネルポート５０から入力する。
次に、ブロックデータ入出力処理部１０−ａで、ファイバチャネルのプロトコル処理を行い、ファイバチャネル用のデータフォーマットから記憶装置１内部のデータフォーマットに変換する。
論理ボリューム管理部３０では、データといっしょに送られてきたアドレスからブロックデータを書き込むべき論理ボリューム３５−ａのアドレスを割り出す。
その後ブロックデータを、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスに書き込む。
【００１５】
ブロックデータを読み出す場合、ホストコンピュータから指定されたブロックデータのアドレスからブロックデータを読み出すべき論理ボリューム３５−ａのアドレスを割り出す。
その後、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスからデータを読み出し、ブロックデータ入出力処理部１０−ａで、記憶装置１内部のデータフォーマットからファイバチャネル用のデータフォーマットに変換し、ファイバチャネルのプロトコル処理を行った後、ファイバチャネルポート５０から出力する。
【００１６】
ファイルデータを書き込む場合、ファイルデータはイーサネットポート５２から入力する。
次に、ファイルデータ入出力処理部１０−ｂで、インターネットプロトコル処理を行い、ファイルシステム２０用のデータフォーマットに変換する。
ファイルシステム２０では、ファイルデータからデータを記憶する論理ボリューム３５−ｂのアドレスを割り出し、ファイルデータをブロックデータに変換する。
その後、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスに書き込む。
【００１７】
ファイルデータを読み出す場合、ファイルシステム２０ではホストコンピュータから指定されたファイルデータから論理ボリューム３５−ｂのアドレスを割り出す。
その後、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスからブロックデータを読み出し、ファイルシステム２０においてファイルデータに変換し、ファイルデータ入出力処理部１０−ｂで、ファイルシステム２０用のデータフォーマットからインターネットプロトコル用のデータフォーマットに変換し、イーサネットポート５２から出力する。
【００１８】
本実施例によれば、図２に示すディスクアレイ装置６とＮＡＳ７を１つのシステムの中で混在させ、ブロックデータとファイルデータを記憶するドライブを共用することが可能となるため、ドライブ容量の有効利用が可能となる。
また、それによりシステムの管理が簡単化される。
これらにより記憶装置のＴＣＯを削減することが可能となる。
【００１９】
また本実施例において、図４に示すような論理ボリュームの割当てを行うこともできる。
すなわち、論理ボリュームをブロックデータ記憶用の論理ボリューム３５−ａ、ファイルデータ記憶用の論理ボリューム３５−ｂ、及びどちらにも属さない論理ボリューム３５−ｃに分ける。
論理ボリュームの割当ては、図１において説明した方法と同様に、サービスプロセッサで論理ボリューム管理部３０内の論理ボリューム構成テーブルを設定することにより行う。
記憶装置１を稼動後、例えばブロックデータ用論理ボリューム３５−ａの空きが無くなった場合、サービスプロセッサから論理ボリューム構成テーブルを書き換えることにより、論理ボリューム３５−ｃの内、必要な数の論理ボリュームをブロックデータ用論理ボリューム３５−ａに割当て換える。
ファイルデータ用論理ボリューム３５−ｂの空きが無くなった場合も同様である。
また、サービスプロセッサから論理ボリューム構成テーブルを書き換えることにより、論理ボリューム３５−ａまたは３５−ｂの内、未使用の論理ボリューム、あるいは使用しなくなった論理ボリュームを論理ボリューム３５−ｃに割当て換えることもできる。
図４の割当て方法によれば、ブロックデータ用論理ボリューム３５−ａ及びファイルデータ用論理ボリューム３５−ｂの両方に空きがなくなった場合でも、新たに論理ボリュームを追加することが可能となる。
【００２０】
《実施例２》
図５及び図８に、本発明の他の実施例を示す。
本実施例では、記憶装置の記憶領域を管理する単位が論理ボリュームである場合について述べる。他の場合についても、本実施例の考え方を適用することにより、同様の効果が得られる。
図５は記憶装置１の他の論理構成を示している。
図５に示す記憶装置１の論理構成は、図１のブロックデータ入出力処理部１０−ａとファイルデータ入出力処理部１０−ｂが統合されブロックデータ及びファイルデータ入出力処理部となること、ポートとして４つのブロックデータ用イーサネットポート５４−ａと４つのファイルデータ用イーサネットポート５４−ｂを有することを除いて、実施例１の図１に示す構成と同様である。
イーサネットポートはこれに限らず、インターネットプロトコルパケットの入出力が可能なポートであれば問題ない。
【００２１】
図８に、図５の論理構成の主な実装構成例の１つを示す。
記憶装置１は、それぞれ１つのイーサネットポート５４−ａを有する４つのＲＡＩＤモジュール４３と、４つのイーサネットポート５４−ｂを有する１つのファイルサーバ４０と、複数のドライブ４４から成る。
ファイルサーバ４０と４つのＲＡＩＤモジュール４３は４本のイーサネット５で接続される。
ここで、上記個数は一実施例に過ぎず、個数を上記に限定するものでは無い。ここで、記憶装置の物理的サイズの制限から、記憶装置１が有するポートの総数は８つに固定されるが、ＲＡＩＤモジュール４３の数を増やすことで、イーサネットポート５４−ａの数を増やすことができる。
この場合、イーサネットポート５４−ａの増加分だけファイルサーバに繋がるイーサネットポート５４−ｂの数を減らす。
イーサネットポート５４−ａの数は、１つのＲＡＩＤモジュール４３に繋がるイーサネットポート５４−ａの数を増やすことによっても増やせる。
逆に、ファイルサーバ４０に繋がるイーサネットポート５４−ｂの数を増やす場合、その増加分だけＲＡＩＤモジュール４３に繋がるイーサネットポート５４−ａの数を減らす。
こうすることにより、ユーザの要求に応じて、イーサネットポート５４−ａの数とイーサネットポート５４−ｂの数を設定することが可能になる。
【００２２】
ＲＡＩＤモジュール４３の構成は、図１１に示すＲＡＩＤモジュール４２において、入出力コントローラ１５０に繋がるファイバチャネル４をイーサネット５に置き換えた構成となる。入出力コントローラ１５０は、イーサネットポート５４−ａからのブロックデータと、イーサネットポート５４−ｂからのファイルデータをファイルサーバ４０で変換して得られたブロックデータとを入力する。
そして、入出力コントローラ１５０にインターネットプロトコルパケットを処理する機能を新たに付加する。
入出力コントローラ１５０では、例えばｉＳＣＳＩのように、ブロックデータのやり取りを行うＳＣＳＩプロトコルのパケットを内部に載せたインターネットプロトコルパケットを処理し、インターネットプロトコル内のＳＣＳＩプロトコルのパケットを取り出したり、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケット上に載せる。
さらに、ＳＣＳＩプロトコルのパケット内のブロックデータの入出力処理を行う。
他の部位の処理はＲＡＩＤモジュール４２と同様である。
ファイルサーバ４０は、図１２に示す構成と同様である。
論理ボリュームの割当て方法は、実施例１と同様である。
【００２３】
以下、ブロックデータ及びファイルデータの書き込み及び読み出し時の各部の動作について示す。
ブロックデータを書き込む場合、ブロックデータはブロックデータ用イーサネットポート５４−ａから入力する。
次に、ブロックデータ及びファイルデータ入出力処理部１１で、インターネットプロトコル処理を行い、インターネットプロトコルパケットからＳＣＳＩプロトコルのパケットを取り出し、さらにＳＣＳＩプロトコルのパケット内からブロックデータを取り出し、記憶装置１内部のデータフォーマットに変換する。
その後の処理は、実施例１と同様である。
【００２４】
ブロックデータを読み出す場合、ブロックデータ及びファイルデータ入出力処理部１１で、インターネットプロトコル処理を行い、インターネットプロトコルパケットからＳＣＳＩプロトコルのパケットを取り出し、さらに読み出すブロックデータのアドレスを割り出す。
そのブロックデータのアドレスからブロックデータを読み出すべき論理ボリューム３５−ａのアドレスを割り出す。
その後、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスからデータを読み出し、ブロックデータ及びファイルデータ入出力処理部１１で、記憶装置１内部のデータフォーマットからＳＣＳＩプロトコルのデータフォーマットに変換し、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケットに載せ、イーサネットポート５４−ａから出力する。
【００２５】
ファイルデータを書き込む場合、ファイルデータはイーサネットポート５４−ｂから入力する。
次に、ブロックデータ及びファイルデータ入出力処理部１１で、インターネットプロトコル処理を行い、ファイルシステム２０用のデータフォーマットに変換する。
その後の処理は、実施例１と同様である。
【００２６】
ファイルデータを読み出す場合、ファイルデータ入出力処理部１０−ｂで行う処理をブロックデータ及びファイルデータ入出力処理部１１で行う以外は、実施例１と同様である。
本実施例によれば、図３に示すディスクアレイ装置６とＮＡＳ７を１つのシステムの中で混在させ、ブロックデータとファイルデータを記憶するドライブを共用することが可能となるため、ドライブ容量の有効利用が可能となる。
また、それによりシステムの管理が簡単化される。
これらにより記憶装置のＴＣＯを削減することが可能となる。
また本実施例においても、図４に示すような論理ボリュームの割当てを行うことができる。
【００２７】
《実施例３》
図６及び図１３に、本発明の他の実施例を示す。
本実施例では、記憶装置の記憶領域を管理する単位が論理ボリュームである場合について、述べる。他の場合についても、本実施例の考え方を適用することにより、同様の効果が得られる。
図６は記憶装置１の他の論理構成を示している。
図６に示す記憶装置１の論理構成は、ポートとして４つのブロックデータ及びファイルデータ共用のイーサネットポート５６を有することを除いて、実施例２の図５に示す構成と同様である。
イーサネットポートはこれに限らず、インターネットプロトコルパケットの入出力が可能なポートであれば問題ない。
【００２８】
図１３に、図６の論理構成の主な実装構成例の１つを示す。
記憶装置１は、４つのブロックデータ及びファイルデータ共用のイーサネットポート５６を有する１つのＩＰ（インターネットプロトコル）スイッチ４６と、４つのＲＡＩＤモジュール４３と、１つのファイルサーバ４０と、複数のドライブ４４から成る。
ＩＰスイッチ４６と４つのＲＡＩＤモジュール４３は４本のイーサネット５で接続される。
また、ファイルサーバ４０と４つのＲＡＩＤモジュール４３は４本のファイバチャネル４で接続される。
また、ＩＰスイッチ４６とファイルサーバ４０は２本のイーサネット５で接続される。
ＩＰスイッチ４６は、イーサネットポート５６から入力されたデータがブロックデータであるか、ファイルデータであるかを判定し、ブロックデータの場合にはＲＡＩＤモジュール４３に出力し、ファイルデータの場合にはファイルサーバ４０に出力する。ファイルサーバ４０ではファイルデータをブロックデータに変換しＲＡＩＤモジュール４３に出力する。
ここで、上記の個数は一実施例に過ぎず、個数を上記に限定するものではない。ＲＡＩＤモジュール４３は、実施例２で述べたＲＡＩＤモジュール４３の構成、機能と同様である。
ファイルサーバ４０は、図１２に示す構成と同様である。
論理ボリュームの割当て方法は、実施例１と同様である。
【００２９】
以下、ブロックデータ及びファイルデータの書き込み及び読み出し時の各部の動作について示す。
本実施例では、ブロックデータ及びファイルデータとも共用のイーサネットポート５６から入力する。
そして、ブロックデータ及びファイルデータ入出力処理部において、インターネットプロトコル処理を行い、インターネットプロトコルパケット内のＴＣＰパケット内に示されているポート番号により、ブロックデータ用のパケットか、あるいはファイルデータ用のパケットかを識別する。
その後の処理は、ブロックデータ、あるいはファイルデータのいずれかに応じて実施例２で示した動作と同様の動作を行う。
本実施例によれば、図３に示すディスクアレイ装置６とＮＡＳ７を１つのシステムの中で混在させ、ブロックデータとファイルデータを記憶するドライブを共用することが可能となるため、ドライブ容量の有効利用が可能となる。また、それによりシステムの管理が簡単化される。
これらにより記憶装置のＴＣＯを削減することが可能となる。
また、本実施例においても、図４に示すような論理ボリュームの割当てを行うことができる。
【００３０】
《実施例４》
図９に本発明におけるファイルデータの高速バックアップの方法を示す。
本実施例では、記憶装置の記憶領域を管理する単位が論理ボリュームである場合について、述べる。他の場合についても、本実施例の考え方を適用することにより、同様の効果が得られる。
図９は、実施例１で述べた図１の記憶装置１のファイルデータをＦＣ（ファイバチャネル）ベースのＳＡＮ２経由でテープ装置６０にバックアップする例を示している。
テープ装置６０はファイバチャネル４のインタフェースを有し、ブロックデータの書き込み／読み出しを行う。
ホストサーバ１はファイバチャネル４とイーサネット５の両方のインターフェースを有する。
ホストサーバ１は、ＬＡＮ３、イーサネットポート５２経由で、バックアップを行うファイルデータのディレクトリを指定してバックアップ要求を記憶装置１に対して発行する。
要求を受けたファイルシステム２０はバックアップ対象ファイルディレクトリからバックアップ対象の論理ボリュームを割り出し、論理ボリューム管理部３０へ対象ボリュームを通知し、ブロックデータとしてバックアップするよう要求を発行する。
その要求を受けた論理ボリューム管理部３０は、アドレス変換テーブルにより指定される要求論理ボリュームのドライブ上の物理アドレスからデータを読み出す。
読み出したデータをブロックデータ入出力処理部１０−ａで、記憶装置１内部のデータフォーマットからファイバチャネル用のデータフォーマットに変換し、ファイバチャネルのプロトコル処理を行った後、ファイバチャネルポート５０からＦＣベースのＳＡＮ２経由でテープ装置６０へ転送し、記録する。
【００３１】
本実施例の特徴は、図９に示すデータ経路１０１により、ファイルシステム２０を介さずにファイルデータのバックアップを行うことである。
一般的にテープ装置はブロックデータの書き込み／読み出ししかできないため、ファイルデータのバックアップを行う場合、ファイルシステムを有するサーバを介してブロックデータとしてテープ装置にデータをバックアップする必要があった。
図９により説明すると、ホストサーバ１がバックアップ対象のファイルデータをＬＡＮ３経由で記憶装置１から読み出し、ブロックデータとしてＦＣベースのＳＡＮ経由でテープ装置６０に書き込むという方法である。
【００３２】
本実施例によれば、サーバを介さずに直接テープ装置にデータをバックアップすることが可能となるため、ファイルデータの高速なバックアップが可能となる。
また、将来的にテープ装置がファイルシステムを有し、ファイルデータをバックアップすることが可能になった場合においても、本実施例によれば、ファイルデータをファイルシステムを介さずにテープ装置へバックアップすることが可能となるため、ファイルシステムにおける処理オーバヘッド分が削減され、ファイルデータのバックアップの高速化が可能となる。
実施例２及び実施例３の構成の記憶装置１においても、本実施例を実施する上で問題はなく、本実施例と同様の効果が得られる。
【００３３】
《実施例５》
図１０に本発明におけるファイルデータの高速リモートコピーの方法を示す。
本実施例では、記憶装置の記憶領域を管理する単位が論理ボリュームである場合について、述べる。他の場合についても、本実施例の考え方を適用することにより、同様の効果が得られる。
図１０は、実施例２で述べた図５の記憶装置１におけるファイルデータのリモートコピーの方法を示している。
リモートコピーは、あるサイトのディスクアレイ装置のデータを地理的に離れたサイトのディスクアレイ装置にコピーしてデータの二重化を行う技術である。
リモートコピー技術により、人災、自然災害等で１つのサイトのディスクアレイ装置がダウンした場合、そのディスクアレイ装置のデータを使用している業務を継続するために、データが二重化されているもう一方のサイトのディスクアレイ装置のデータを使用することが可能となり、システムの可用性が向上する。
【００３４】
記憶装置１−１、１−２は実施例２で述べた図５の記憶装置である。
記憶装置１−１と１−２は地理的に離れた場所にあるデータセンタ内にあり、それぞれが個々のイーサネットベースのＳＡＮ９−１、９−２に接続されている。
また、イーサネットベースのＳＡＮ９−１と９−２はインターネット８を介して互いに接続されている。
本実施例は従来のリモートコピー技術をベースとしており、記憶装置１−１と１−２間でのリモートコピーの制御方式は基本的に従来のリモートコピー技術と同じであり、ここでは、本実施例で必要な新たな処理１０５、及びリモートコピー時の記憶装置内でのデータの経路１０６についてのみ述べる。
【００３５】
記憶装置１−１から１−２へファイルデータをリモートコピーする場合について述べる。
ホストサーバ１−１はリモートコピーの対象とするファイルデータのディレクトリを指定してリモートコピー要求を、ファイルデータ用イーサネットポート５４−ｂを介して記憶装置１−１に対して発行する。
要求を受けた記憶装置１−１のファイルシステム２０−１は、リモートコピー対象のファイルディレクトリからリモートコピー対象の論理ボリュームを割り出し、イーサネットポート５４−ｂを介したＩＰ（インターネットプロトコル）通信により、ブロックデータ用のイーサネットポート５４−ａからファイルシステムを介さずに対象論理ボリュームをリモートコピーすることを、予め記憶装置１−２のファイルシステム２０−２に通知する（図中矢印１０５）。
通知を受けたファイルシステムは２０−２は、ファイルデータがファイルシステムを介さずにブロックデータ用のイーサネットポート５４−ａから入力されることと対象となる論理ボリュームを、論理ボリューム管理部３０−２に通知するとともに、ファイルシステム２０−１からの通知に対する了承をファイルシステム２０−１に返送する。
それを受けたファイルシステム２０−１は、論理ボリューム管理部３０−１へリモートコピー対象ボリュームを通知する。
【００３６】
以下に、上記リモートコピー要求が、記憶装置１−１から１−２へコピー対象ボリュームの全ファイルデータをコピーする要求と、コピー後に、記憶装置１−１のコピー対象ボリューム内のファイルデータが更新されたとき、記憶装置１−２に更新されたファイルデータの更新をする要求とを含む場合について、説明する。
論理ボリューム管理部３０−１は、通知されたリモートコピー対象ボリュームをドライブから読み出し、ブロックデータ及びファイルデータ入出力処理部１１−１で、記憶装置１内部のデータフォーマットからＳＣＳＩプロトコルのデータフォーマットに変換し、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケットに載せ、イーサネットポート５４−ａからイーサネットベースのＳＡＮ９経由で記憶装置１−２へ転送する。
リモートコピーのデータを受け取った論理ボリューム管理部３０−２は、データとともに送られる対象論理ボリュームのアドレスからファイルデータのリモートコピーであることを識別し、対象ボリュームのコピーをする。（図中矢印１０６）。
また、記憶装置１−１内のコピー対象となったボリューム内のデータが更新された場合には、更新された該当データをドライブから読み出し、ブロックデータ及びファイルデータ入出力処理部１１−１で、記憶装置１内部のデータフォーマットからＳＣＳＩプロトコルのデータフォーマットに変換し、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケットに載せ、イーサネットポート５４−ａからイーサネットベースのＳＡＮ９経由で記憶装置１−２へ転送する。
リモートコピーのデータを受け取った論理ボリューム管理部３０−２は、データとともに送られる対象論理ボリュームのアドレスからファイルデータのリモートコピーであることを識別し、対象ボリューム内の該当データを更新する（図中矢印１０６）。
【００３７】
本実施例によれば、記憶装置間でのファイルデータのリモートコピーを、ファイルシステムを介さずに行うことが可能となるため、ファイルシステムにおける処理オーバヘッド分が削減され、ファイルデータのリモートコピーを高速化することが可能となる。
実施例１及び実施例３の構成の記憶装置１においても、本実施例を実施する上で問題はなく、本実施例と同様の効果が得られる。
【００３８】
【発明の効果】
本発明によれば、ディスクアレイ装置に代表されるブロック形式データの記憶装置とＮＡＳに代表されるファイル形式データの記憶装置の混在環境において、ドライブ容量の有効利用が可能で、且つ管理が簡単化された記憶装置を提供することができる。
また、ファイル形式データのバックアップ及びコピーを高速化可能な記憶装置を提供することが可能となる。
【図面の簡単な説明】
【図１】本発明による記憶装置の論理構成を示す図である。
【図２】ディスクアレイ装置とＮＡＳの混在環境を示す図である。
【図３】ディスクアレイ装置とＮＡＳの他の混在環境を示す図である。
【図４】本発明による記憶装置の他の論理構成を示す図である。
【図５】本発明による記憶装置の他の論理構成を示す図である。
【図６】本発明による記憶装置の他の論理構成を示す図である。
【図７】図１に示す記憶装置の実装構成を示す図である。
【図８】図５に示す記憶装置の実装構成を示す図である。
【図９】本発明の記憶装置からテープ装置へのファイル形式データのバックアップ方法を示す図である。
【図１０】本発明の記憶装置間でファイル形式データのリモートコピーを行う方法を示す図である。
【図１１】図７に示すＲＡＩＤモジュールの構成を示す図である。
【図１２】図７に示すファイルサーバの構成を示す図である。
【図１３】図６に示す記憶装置の実装構成を示す図である。
【符号の説明】
１  記憶装置
２、９−１、９−２  ＳＡＮ
３  ＬＡＮ
８  インタ−ネット
１０−ａ  ブロックデータ入出力処理部
１０−ｂ  ファイルデータ入出力処理部
１１、１２  ブロックデータ及びファイルデータ入出力処理部
２０  ファイルシステム
３０  論理ボリューム管理部
３５−ａ、３５−ｂ、３５−ｃ  論理ボリューム
４０  ファイルサーバ
４２、４３  ＲＡＩＤモジュール
４４  ドライブ
４６  ＩＰスイッチ
６０  テープ装置
１５０、１５１、１５２  入出力コントローラ
１６５、１６６  データバッファ
１７０  論理ボリュームコントローラ
１８０  プロセッサ
【図１】
0004632574.tif 000002
【図２】
0004632574.tif 000003
【図３】
0004632574.tif 000004
【図４】
0004632574.tif 000005
【図５】
0004632574.tif 000006
【図６】
0004632574.tif 000007
【図７】
0004632574.tif 000008
【図８】
0004632574.tif 000009
【図９】
0004632574.tif 000010
【図１０】
0004632574.tif 000011
【図１１】
0004632574.tif 000012
【図１２】
0004632574.tif 000013
【図１３】
0004632574.tif 000014