JP4187403B2 - データ記録システム、データ記録方法およびネットワークシステム - Google Patents
データ記録システム、データ記録方法およびネットワークシステム Download PDFInfo
- Publication number
- JP4187403B2 JP4187403B2 JP2000387497A JP2000387497A JP4187403B2 JP 4187403 B2 JP4187403 B2 JP 4187403B2 JP 2000387497 A JP2000387497 A JP 2000387497A JP 2000387497 A JP2000387497 A JP 2000387497A JP 4187403 B2 JP4187403 B2 JP 4187403B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- node
- nodes
- storage area
- write
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク環境におけるデータ記録システムおよびデータ記録方法に関し、特に複数のプロトコルが混在するネットワーク環境にアタッチされるデータ記録システムのスループットおよび信頼性を向上する技術に関する。
【０００２】
【従来の技術】
インターネットあるいはＬＡＮ（local area network）に代表されるコンピュータネットワークの一般化およびコンピュータシステムの性能向上を背景として、より大きな容量のストレージ装置に対するニーズが高まっている。たとえばネットワークファイルあるいはウェブキャッシュとして大容量なデータストレージシステムが利用される。
【０００３】
ネットワークシステムにアタッチされるストレージシステムの一つとして、ＲＡＩＤ（redundant arrays of inexpensive disk）等のディスクアレイが知られている。ディスクアレイはたとえばＳＣＳＩ（small computer system interface）で接続されるためディスクアレイとネットワークとを接続するノードが用いられる。
【０００４】
また、一般にネットワークに接続される複数のコンピュータシステムでは異なるネットワークＯＳ（operating system）やＬＡＮアプリケーションが用いられる。このため、ネットワークに接続されるノードは、ネットワークＯＳやＬＡＮアプリケーションごとに相違するプロトコルに対応するようにしている。たとえば、Ｗｉｎｄｏｗｓ ＮＴ／９８（Ｗｉｎｄｏｗｓ及びＷｉｎｄｏｗｓ ＮＴはマイクロソフトコーポレーションの米国及びその他の国における商標）クライアントからノードにファイルアクセスを行う場合にはたとえばＣＩＦＳ（common internet file system）が用いられ、ＵＮＩＸ（Ｔｈｅ Ｏｐｅｎ Ｇｒｏｕｐがライセンスしている米国及びその他の国における登録商標）クライアントからのファイルアクセスではたとえばＮＦＳ（network file system）が用いられる。また、ウェブ環境におけるウェブキャッシュとして使用する場合にはＨＴＴＰ（hyper text transfer protocol）が用いられる。これら複数のプロトコルに対応できるノードとして前記したノードが構成される。
【０００５】
【発明が解決しようとする課題】
ところが、ネットワーク上でのファイルアクセス要求が増加し、また、ディスクアレイの総記録容量が増加するに従い、ノードへのトラフィックロードが増加する。単一のノードでは、ＣＰＵの速度、内部メモリの容量、バスバンド幅などの制限により処理スピードに限界がある。このためノードを複数設けてノードあたりの負荷を軽減する方策が採られる。
【０００６】
ノードを複数設ける方策の一つに、ディスクアレイをクラスタ化し、各ノード間でこのクラスタ化されたディスクアレイを共有する方法がある。しかしながらこの場合、ノード毎にアドレスを持つことになる。つまりネットワークに接続されるストレージシステムとして複数のアドレスを持つことになり、クライアントは各々アクセスポイントの管理を行う必要が生じる。このようなアクセスポイント管理（アドレス管理）はクライアントユーザにとって極めて不便であることは明らかである。
【０００７】
ノードを複数設ける他の方策に、各ノード間を高速バスで相互接続し、それぞれのノードをネットワークに接続する方法がある。しかしながらこの場合、前記した複数アドレス（アクセスポイント）管理の問題に加えて、キャッシュのヒット率低下の問題が生じる。つまり、ノードには階層化されたメモリシステムを有し、書込みあるいは読出しデータが一旦キャッシュに記録される。既にキャッシュされているデータと相違するプロトコルに従うデータが受け入れられた場合、アクセスパターンの相違等によりキャッシュのヒット率が低下する。この結果、ストレージシステム全体のパフォーマンスを低下させる原因となる。さらに、本方策の場合、高速バスでのデータ転送自体がボトルネックになる可能性もある。
【０００８】
本発明の目的は、ノードのロードを分割する場合においても、単一のアドレスで特定できるネットワークストレージシステムを提供することにある。
【０００９】
また、本発明の目的は、ノードのキャッシュヒット率を向上し、ネットワークストレージシステム全体のパフォーマンスを向上することにある。
【００１０】
また、本発明の目的は、ネットワークストレージシステム全体の信頼性を向上することにある。
【００１１】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、本発明のデータ記録システムでは、ネットワークのフロントエンドに位置するイーサネットスイッチによりプロトコル毎にデータを振り分け、同一プロトコルに従うデータは同一のサービスノードに振り分けるようにする。このようにサービスノードを特定プロトコルの処理に特化することにより、ノード内でのキャッシュのヒット率を高め、スループットとスケイラビリティを同時に実現する。また、ネットワークストレージは単一のフロントエンドスイッチでネットワークに接続されるため、クライアントは単一のアドレスを管理するだけで本ネットワークストレージシステムを利用することができ、ユーザのアドレス管理（ポート管理）を不要にして、ユーザの利便性を向上できる。
【００１２】
また、本データ記録システムでは、ノード間を高速バスで接続したクラスタ構造を実現する。そしてピアノードの不揮発性ストレージ間で同じ書込みデータを保持（ミラーリング）することにより、障害発生時のノードのリスタートを信頼性良く行う。これにより、システムの信頼性を向上できる。
【００１３】
なお、本発明を具体的に列記すれば以下の通りである。本発明のデータ記録システムは、異なる複数のプロトコルに従うデータを受け取り、プロトコル毎にデータの伝送先を切り換えるフロントエンドスイッチと、フロントエンドスイッチに接続され、複数のプロトコルのうち少なくとも一種類のプロトコルに適合する複数のノードと、ノードを介してデータの読み書きを行うデータストレージ装置とを有する。このとき、前記データのヘッダにはプロトコルの各々に対応付けられたポートＩＤを含み、ポートＩＤによりデータの伝送先を切り換えることができる。また、複数のノードの各々に不揮発性ストレージ領域を含み、不揮発性ストレージ領域が他のノードの不揮発性ストレージ領域と接続され、不揮発性ストレージ領域には、ノードへの書込みデータと他のノードへの書込みデータとが記録することができる。
【００１４】
また、本発明のデータ記録方法は、特定のプロトコルに関連付けられた識別情報を含むデータを受け取るステップと、識別情報を参照して、データが送付されるノードを切り換えるステップと、ノードを介してデータをデータストレージ装置に記録するステップと、を含む。このとき、識別情報は、プロトコル毎に関連付けられているポートＩＤとすることができる。また、データが書込みデータであるかを判断するステップと、判断が真の場合にはノードの不揮発性ストレージ領域、および、不揮発性ストレージ領域に接続された他のノードの不揮発性ストレージ領域にデータを書き込むステップと、データストレージ装置への書込みデータの書込み処理が終了した時には、不揮発性ストレージ領域、および、他のノードの不揮発性ストレージ領域に記録された書込みデータのデータ領域を開放するステップと、をさらに含むことができる。また、書込みデータの処理中にエラーが検出された時には、エラーが検出されたノード以外の不揮発性ストレージ領域に記録された書込みデータを、その不揮発性ストレージ領域を含むノードを経由してデータストレージ装置に記録することができる。
【００１５】
なお、前記データ記録システムを構成要素とするネットワークシステムとして本発明を把握することができるのは勿論である。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００１７】
図１は、本発明の一実施の形態であるデータストレージシステムとデータストレージシステムが接続されたネットワークシステムの一例を示した全体構成図である。本実施の形態のネットワークシステムは、コンピュータシステム１〜３とデータストレージシステム４とがイーサネット５でネットワーク接続された構成を有する。
【００１８】
コンピュータシステム１〜３は、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ(Random Access Memory)）、不揮発性記憶装置（ＲＯＭ(Read Only Memory)）等がバスで相互に接続された一般的なコンピュータシステムである。前記バスにはコプロセッサ、画像アクセラレータ、キャッシュメモリ、データ入出力のためのインタフェイス等が接続され、インタフェイスにはハードディスクドライブ等の外部記憶装置、キーボード、マウス等の入出力装置、液晶表示装置、ＣＲＴ（cathode ray tube）等の表示装置、通信制御装置等が接続される。通信制御装置は、たとえば以下に説明するイーサネット規格に適合し、データを高速に通信することができる。その他一般的なコンピュータシステムに備えられるハードウェア資源を備えることができることは勿論である。なお、本実施の形態のコンピュータシステム１〜３は、適当な通信回線あるいは前記イーサネット５を介してインターネットあるいはイントラネットに接続することが可能である。通信回線には、無線、有線、専用線、公衆回線等あらゆる通信手段が含まれる。
【００１９】
また、本実施の形態のコンピュータシステム１〜３は各々異なるＯＳで動作し、各々のＯＳでサポートする通信プロトコルが相違する。たとえばコンピュータシステム１ではＯＳとしてＷｉｎｄｏｗｓ ＮＴ／９８で動作し、データストレージシステム４に対してクライアントとして機能する際にはＣＩＦＳプロトコルが適用される。また、コンピュータシステム２ではＯＳとしてＵＮＩＸが動作し、データストレージシステム４に対して共有データアクセスを行う際にはＮＦＳプロトコルが適用される。また、コンピュータシステム３の適当なＯＳ上でウェブ（ＷＷＷ）に対するＨＴＴＰリクエストが生じた時には、データストレージシステム４に対してネットワークからリクエストがルーティングされる。この時通信プロトコルにはＨＴＴＰが適用される。すなわち、コンピュータシステム１〜３では異なる通信プロトコルをサポートし、イーサネット５上では複数の通信プロトコルが混在する。
【００２０】
イーサネット５は、ＩＥＥＥ８０２．３で規定された伝送規格であり、ＯＳＩ（open system interconnection）参照モデルでは物理層（第１層）およびデータリンク層（第２層）に相当する。なお、本実施の形態ではイーサネットを例示するが、トークンリング（ＩＥＥＥ８０２．５）、ＦＤＤＩ（fiber distributed data interface）、ＴＰＤＤＩ（twisted pair distributed data interface）、ローカルトーク（ＲＳ−４２２）等ＯＳＩ参照モデルで物理層およびデータリンク層に相当する他の伝送規格を用いることも可能である。
【００２１】
データストレージシステム４には、フロントエンドスイッチ６、複数のノード７、ＲＡＩＤ装置８が含まれる。
【００２２】
フロントエンドスイッチ６は、イーサネット５およびノード７に接続され、イーサネット５から伝送されたデータをプロトコル毎に割当てられたノード７に振り分ける機能を持つ。フロントエンドスイッチの詳細については後述する。
【００２３】
ノード７は、フロントエンドスイッチ６によって割り振られたデータを受け取り、ＲＡＩＤ装置８にデータをインタフェイスする。ノード７は、複数プロトコルに適応可能なようにプロトコル毎の処理手段を有する。但し、ネットワークで使用される全てのプロトコルをサポートする必要はなく、単一のプロトコルを処理するものであっても良い。ノード７にはたとえばバッテリでバックアップされた不揮発性のメモリ領域であるＮＶＳ（Non Volatile Storage）９を有し、各ノード７のＮＶＳ９は高速バス１０で相互に接続される。高速バスにはＳＣＩ（Scalable Coherent Interface）を例示できる。なお、図１では３つのノード７を例示するがそれ以上のノードが設けられても良い。ノード７の詳細については後に説明する。
【００２４】
ＲＡＩＤ装置８は、たとえばハードディスクアレイ１１で構成された記録装置であり、ノード７とファイバーチャネル１２でリング状に接続される。ＲＡＩＤ装置８にはハードディスクアレイ１１を制御するＲＡＩＤコントローラ１３が含まれる。なお、図１では複数のＲＡＩＤ装置８を例示するが、ＲＡＩＤ装置８は１台でも構わない。
【００２５】
図２は、フロントエンドスイッチの詳細を示したブロック図である。本実施の形態のフロントエンドスイッチには、ポート１〜ｎを持つイーサネットインタフェイス１４、ＭＡＣ（media access control）インタフェイス１５、入力キュー１６、出力キュー１７、ファブリックインタフェイス１８、スイッチファブリック１９を有し、ポートルックアップテーブル２０、フレーム転送エンジン２１、データバッファ２２を備える。
【００２６】
ポート１〜ｎは、図１におけるイーサネット５およびノード７に接続するポートである。イーサネットインタフェイス１４はノード内部とイーサネット５とのインタフェイスを行い、ＭＡＣインタフェイス１５ではたとえばＩＰアドレスとメディア固有のＭＡＣアドレスとの対応付けを行う。入力キュー１６および出力キュー１７では、各々データの入力および出力の待ち行列を制御し、ファブリックインタフェイス１８では入出力キュー１６，１７とスイッチファブリック１９とのインタフェイスを行う。スイッチファブリック１９は、データのルーティングを行う伝送先切り換え手段であり、フレーム転送エンジン２１によって制御される。
【００２７】
ポートルックアップテーブル２０は、特定のプロトコルに関連付けられているポートＩＤと、プロトコル毎に割当てられる特定の物理ポートとを対応付けたテーブルである。図３は、ポートルックアップテーブルの一例を示した表図である。本実施の形態のネットワークストレージシステムの場合、同じデスティネーションアドレスであっても、第４層（トランスポート層）でのアプリケーション（プロトコル）が相違する場合には、異なる物理ポートにルーティングする。たとえば「１．２２２．３３３．４４」のデスティネーションアドレスでＮＦＳのポートＩＤが指定されて受け入れられたデータは物理ポート「０」にルーティングされる。同様にＣＩＦＳのポートＩＤから受け入れられたデータは物理ポート「１」にルーティングされる。ＨＴＴＰについても同様である。なお、ポートルックアップテーブル２０には他のデスティネーションアドレスが含まれても良いことは勿論である。
【００２８】
フレーム転送エンジン２１は、フレーム単位で受け入れたデータのポートＩＤを識別し、ポートルックアップテーブル２０を参照して転送先を決定する手段である。スイッチファブリック１９と協働してデータのルーティングを行う。データバッファ２２にはデータがバッファされる。
【００２９】
図４は、ノードの詳細を示したブロック図である。本実施の形態のノード７は、ＣＰＵ２３、メモリバスコントローラ２４、ＣＰＵメモリ・データバッファ２５、ファームウェア・フラッシュＲＯＭ２６、ＧＰＩＯ（General Purpose Input Output）２７、ネットワークコントローラ２８、ギガビットイーサネットインタフェイス２９、ストレージデバイスコントローラ３０、ファイバチャネルインタフェイス３１、フロントエンドスイッチコントローラ３２、ＮＶＳコントローラ３３、およびＮＶＳ９を含む。
【００３０】
ＣＰＵ２３はノードを制御する計算やメモリ間のデータ転送等を制御する中央演算処理装置である。単一のプロセッサあるいは複数プロセッサからなる。メモリバスコントローラ２４は、各種メモリ間のデータ転送をＣＰＵを介さずに直接行う制御装置である。高速なデータ転送が実現できる。ＣＰＵメモリ・データバッファ２５はたとえばＤＲＡＭ（Dynamic Random Access Memory）で構成され、ＣＰＵ２３に入力されるプログラムあるいはデータが記録されるほか、データのバッファリングにも利用される。ファームウェア・フラッシュＲＯＭ２６には、ノードを制御するプログラムが記録される。ＣＰＵ２３からファームウェア・フラッシュＲＯＭ２６に対して直接プログラムを読み出す他、一旦ＣＰＵメモリ・データバッファ２５にプログラムが転送され、ＣＰＵからはＣＰＵメモリ・データバッファ２５上のプログラムを読み出すこともできる。ＧＰＩＯ２７は、各種構成スイッチの読み取り、および状態表示用ＬＥＤのインタフェイス機能を持つ。
【００３１】
ネットワークコントローラ２８、ストレージデバイスコントローラ３０、フロントエンドスイッチコントローラ３２は、各々ネットワーク（イーサネット５）、ＲＡＩＤ装置８、フロントエンドスイッチ６を制御する。ギガビットイーサネットインタフェイス２９は、ネットワークコントローラ２８とイーサネット５とをインタフェイスし、ファイバチャネルインタフェイス３１はストレージデバイスコントローラ３０とＲＡＩＤ装置８をインタフェイスする。ＮＶＳコントローラ３３は、ＮＶＳ９を制御し、ピアノードのＮＶＳコントローラに接続される。
【００３２】
次に、前記したネットワークストレージシステムを用いてデータを記録する方法について説明する。図５は、フロントエンドスイッチ６での処理の一例を示したフローチャートである。
【００３３】
コンピュータシステム１〜３から発せられたデータ（フレーム）がイーサネット５を介してフロントエンドスイッチ６に伝送され、フロントエンドスイッチ６がこのフレームを受取ることにより処理が開始する（ステップ４０）。フレームは図２に示すフロントエンドスイッチのポートから受信され、受信されたフレームはイーサネットインタフェイス１４を介してＭＡＣインタフェイス１５に送られる。
【００３４】
ＭＡＣインタフェイス１５では、受取ったデータのヘッダに含まれるＩＰアドレスから機器固有のＭＡＣアドレスに従ってフレームを入力キュー１６に転送する（ステップ４１）。なお、ＭＡＣアドレスとＩＰアドレスとの対応は、ＡＲＰテーブルとしてネットワーク内のルータ等に記録されており、フロントエンドスイッチ内のデータバッファにも同じテーブルを保持している。また、ネットワーク内のＩＰアドレスにはローカルアドレスを用いることができる。
【００３５】
次に、フレーム転送エンジン２１がフレームヘッダからポート番号を抽出する（ステップ４２）。ポート番号は、アプリケーションに関連付けて通常同じプロトコルでは同じポートを開いてデータの送受信を行うために付される。たとえばＨＴＴＰではポート番号は８０、ｎｅｔｂｉｏｓ−ｎｓではポート番号１３７のポートが開かれる。
【００３６】
次に、ヘッダから抽出されたポート番号とポートルックアップテーブル２０を参照して、フレームの転送先物理ポートをサーチする（ステップ４３）。そして、フレーム転送テーブル（図示せず）に転送先の物理ポートを指定し（ステップ４４）、フレームを出力キュー１７に転送する（ステップ４５）。
【００３７】
その後、フレームは出力キュー１７の処理に従って物理ポートからノードに転送されることになる（ステップ４６）。
【００３８】
前記した通り、フロントエンドスイッチ６の物理ポートには何れかのノード７が接続されているので、特定のノードには特定のプロトコルに従うデータが転送されることになる。このように特定のノードには、特定のプロトコルに従うデータ（フレーム）が転送されるので、後に説明するノードでの処理において、キャッシュヒット率が向上する。すなわち、通常プロトコルによってディレクトリ構造やアクセスパターンが相違するが、本実施の形態のシステムによればノードにおいては結果的に常に同一プロトコルのファイルアクセス処理を行うことになる。常に同一のアクセスパターンあるいはディレクトリ構造のデータ処理をノードにおいて行うこととなり、必然的にキャッシュヒット率が向上することになる。これによりノードでの処理のスループットを向上し、システム全体のパフォーマンスを向上することができる。
【００３９】
また、本実施の形態のフロントエンドスイッチ６は単一のＩＰアドレスで指定される。つまりユーザは自己の使用するプロトコルを意識することなく、単一のフロントエンドスイッチ６のアドレスを指定してファイルシステムを利用できる。これにより、ユーザに煩雑なアドレス管理を強いることなく、スケーラビリティと高いスループットが実現されたファイルシステムを実現できる。
【００４０】
次に、ノードでの処理をフローチャートを用いて説明する。図６は、ノードにおけるデータ記録処理の一例を示したフローチャートである。
【００４１】
前記したフロントエンドスイッチ６での処理の後、ノード７にデータ（フレーム）が転送されてくる（ステップ４７）。その後、フレームを受取ったノード７は、まずＩＰ層（ネットワーク層）の処理を行い（ステップ４８）、続いてＴＣＰあるいはＵＤＰ層（トランスポート層）での処理を行う（ステップ４９）。ＩＰ層での処理は、主に、径路制御、ネットワークコネクションの確立、多重化とフロー制御、データパケットの分割・統合等を行う。ＴＣＰあるいはＵＤＰ層では、主に、上位層であるセッション層（ＯＳＩ参照モデルにおける第５層以上）に透過的なデータを提供し、多重化制御、フロー制御、再送制御（ＴＣＰの場合）等を行う。
【００４２】
次に、上位プロトコルの識別を行い（ステップ５０）、プロトコルに従った処理を行う（ステップ５１〜５３）。たとえばＣＩＦＳの場合にはＣＩＦＳに応じた処理を行い（ステップ５１）、ＨＴＴＰの場合はＨＴＴＰに応じた処理を行う（ステップ５２）。ＩＰ層の処理の場合はそれに応じた処理を行う（ステップ５３）。なお、本実施の形態では、複数のプロトコルに対応可能なノードを例示しているが、たとえばＣＩＦＳにのみ対応するノードであっても良い。この場合、ステップ５０をパスしてステップ５１を実行する。
【００４３】
次に、ファイルシステムの処理を行う（ステップ５４）。ファイルシステム処理では、ＲＡＩＤ装置８へのデータ転送のための各種の計算等を行う。
【００４４】
次に、現在処理しているデータが書込みデータであるかを判断する（ステップ５５）。書込みデータである場合（ステップ５５の判断がＹｅｓの時）にはＮＶＳ９へのデータ転送を行う（ステップ５６）。その後データバッファ２５等のキャッシュにデータを転送し（ステップ５７）、さらにキャッシュからストレージデバイスコントローラ３０を介してファイバチャネルにデータを転送する（ステップ５８）。なお、書込みデータである際の処理は後に詳しく説明する。
【００４５】
一方、ファイルシステム処理が読込みデータを必要とする場合（ステップ５５の判断がＮｏの時）、キャッシュ内部の有効データを検索し（ステップ５９）、キャッシュヒットか否かの判断を行う（ステップ６０）。キャッシュヒットの場合はこのデータをネットワークコントローラを経由してネットワークにデータ転送を行う（ステップ６２）。キャッシュミスの場合はファイバチャネルからストレージデバイスコントローラを経由してデータバッファ内のキャッシュにデータを転送し（ステップ６１）、キャッシュからネットワークコントローラを経由してネットワークにデータ転送を行う（ステップ６２）。
【００４６】
以上ノードにおける処理はフラッシュＲＯＭ２６に記録されたファームウェアに従ってＣＰＵ２３の制御のもとに行われる。上記処理において、あるノード７に受け入れられるデータのプロトコルは前記した通りフロントエンドスイッチ６によって同じプロトコルに振り分けられている。このため、ファイルシステム層での処理において、キャッシュされたデータの利用率つまりキャッシュヒット率が高くなる。このため複数ノードを用いてファイルシステムの処理負担を軽減しつつ、各ファイルシステムでの処理効率（スループット）を向上できる。
【００４７】
図７は、ノードにおいて書込み処理が行われる時の処理の一例を示したフローチャートである。まず、ネットワークコントローラ２８からデータバッファ２５にデータが転送される（ステップ６３）。次にネットワークコントローラ２８からＮＶＳ９にデータが転送される（ステップ６４）とともに、ピアノードのＮＶＳにデータが転送される（ステップ６５）。つまり、書込み操作時に、書込み操作を行っているノードのＮＶＳとピアノードのＮＶＳとに同一データが書込まれ、ある書込み操作における書込みデータは常にコピーを持つことになる。
【００４８】
図８は、書込み動作時のノード間でのＮＶＳデータをコピーする操作について説明した図である。ノードＡのＮＶＳコントローラ３３−１によってノードＡが処理する書込みデータをノードＡのＮＶＳ９−１に書き込むとともに、ノードＡのＮＶＳコントローラ３３−１からノードＢのＮＶＳコントローラ３３−２に同じ書込みデータが転送され、ノードＢのＮＶＳコントローラ３３−２を介してノードＢのＮＶＳ９−２にノードＡが処理する書込みデータを書き込む。つまり、ノードＡとノードＢとはピアノードを構成し、ノードＡの書込みデータは、ノードＡのＮＶＳ９−１に書込まれるとともに、ノードＢのＮＶＳ９−２にもコピーが保持される。同様に、ノードＢの書込みデータはノードＣのＮＶＳにコピーが保持され、順次サイクリックにピアノード間で書込みデータのコピーが保持され、最後はノードｎの書込みデータがノードＡのＮＶＳ９−１に保持される。
【００４９】
このように、書込みデータを自己のノードＮＶＳだけでなく、ピアノードのＮＶＳにもコピーを保持することにより、後に説明するようにノードに障害を生じた時の復帰がしやすくなる。すなわち、安定したノードのリスタートを実現でき、システム全体の信頼性を向上することができる。
【００５０】
上記のようにＮＶＳへのデータ転送を行った後、ノードはファイルシステム層での書込み処理を完了する（ステップ６６）。
【００５１】
次に、データバッファ２５からストレージデバイスコントローラ３０にデータが転送され、ファイバチャネルインタフェイス３１を介してストレージ（ＲＡＩＤ装置８）にデータが送出される（ステップ６７）。ストレージからのライトコンプリートの信号を受信すればストレージでの書込み処理の完了を確認する（ステップ６８）。
【００５２】
書込み処理の完了後、自己ノードのＮＶＳおよびピアノードのＮＶＳに記録されたデータの記憶領域を開放（あるいはデータを消去）する（ステップ６９）。以上のようにして書込み処理が完了する。
【００５３】
次に、ノードで障害が発生した時の処理について説明する。図９はノードエラーを生じた時の処理の一例を示したフローチャートである。
【００５４】
エラー時の復帰処理は、ノードでのエラー検出で開始する（ステップ７０）。エラーが検出された時、ピアノードがあるかを判断する（ステップ７１）。
【００５５】
ピアノードがある場合には、ピアノードのＮＶＳにコミットされていないデータがあるかをチェックする（ステップ７２）。コミットされていないデータがある場合、このデータをピアノードを経由してストレージにステージング（書き込み）処理を行う（ステップ７３）。なお、ステージング処理については前記の通りである。ストレージからの書込み完了信号の受信により書込み処理が完了し（ステップ７４）、書込み処理の完了後、障害の発生したノードのリスタート処理を行う（ステップ７５）。その後通常の処理に復帰する（ステップ７６）。
【００５６】
一方、ピアノードがない場合、ノードのリスタート処理および通常の処理を停止し（ステップ７７）、ＮＶＳ上にコミットされていないデータがあるかをチェックする（ステップ７８）。その後、コミットされていないデータについて、ＮＶＳからそのノードのストレージデバイスコントローラ３０にデータを転送し（ステップ７９）、ストレージでの書込み処理の完了を確認する（ステップ８０）。そして通常動作に復帰する（ステップ７６）。
【００５７】
すなわち、ピアノードがある場合には障害が発生したノードとそのピアノードについてのみ特別のリスタート処理を行い、ピアノードがない場合には全てのノードについてリスタート処理を行う。前記の通り、本実施の形態のストレージシステムでは原則的に何れのノードにおいてもピアノードに書込みデータのコピーデータを保持するため、何れのノードに障害を生じた場合でもそのノードとピアノードの処理を一時停止するのみであり、他のノードには障害の影響を及ぼさない。この結果、ノードに障害を生じてもシステム全体を停止することなく、冗長性が高くつまり信頼性の高いシステムを構築できる。
【００５８】
なお、ＮＶＳ上にコミットされていないデータが発見されない場合には、障害の発生以前に全てのステージング処理は正常に完了しており、ノードをリスタートする等の処理のみを行う。
【００５９】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【００６０】
たとえば、前記実施の形態では、ファイルシステム（ＲＡＩＤ装置８）へのインタフェイスとしてファイバーチャネルを例示したが、ＦＤＤＩ、ＡＴＭ（asynchronous transfer mode）であっても良い。
【００６１】
また、前記実施の形態では、アプリケーションによるプロトコルの相違をポート番号で識別したがこれに限られず、その他ヘッダに含まれる識別情報を用いることも可能である。
【００６２】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、ノードのロードを分割する場合においても、単一のアドレスで特定できるネットワークストレージシステムを提供できる。また、ノードのキャッシュヒット率を向上し、ネットワークストレージシステム全体のパフォーマンスを向上できる。ネットワークストレージシステム全体の信頼性を向上することができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるデータストレージシステムとデータストレージシステムが接続されたネットワークシステムの一例を示した全体構成図である。
【図２】フロントエンドスイッチの詳細を示したブロック図である。
【図３】ポートルックアップテーブルの一例を示した表図である。
【図４】ノードの詳細を示したブロック図である。
【図５】フロントエンドスイッチでの処理の一例を示したフローチャートである。
【図６】ノードにおけるデータ記録処理の一例を示したフローチャートである。
【図７】ノードにおいて書込み処理が行われる時の処理の一例を示したフローチャートである。
【図８】書込み動作時のノード間でのＮＶＳデータをコピーする操作について説明した図である。
【図９】ノードエラーを生じた時の処理の一例を示したフローチャートである。
【符号の説明】
１〜３…コンピュータシステム、４…データストレージシステム、５…イーサネット、６…フロントエンドスイッチ、７…ノード、８…ＲＡＩＤ装置、９（９−１〜９−ｎ）…ＮＶＳ、１０…バス、１１…ハードディスクアレイ、１２…ファイバーチャネル、１３…ＲＡＩＤコントローラ、１４…イーサネットインタフェイス、１５…ＭＡＣインタフェイス、１６…入力キュー、１７…出力キュー、１８…ファブリックインタフェイス、１９…スイッチファブリック、２０…ポートルックアップテーブル、２１…フレーム転送エンジン、２２…データバッファ、２３…ＣＰＵ、２４…メモリバスコントローラ、２５…ＣＰＵメモリ・データバッファ、２６…ファームウェア・フラッシュＲＯＭ、２７…ＧＰＩＯ、２８…ネットワークコントローラ、２９…ギガビットイーサネットインタフェイス、３０…ストレージデバイスコントローラ、３１…ファイバチャネルインタフェイス、３２…フロントエンドスイッチコントローラ、３３（３３−１〜３３−ｎ）…ＮＶＳコントローラ。
【発明の属する技術分野】
本発明は、ネットワーク環境におけるデータ記録システムおよびデータ記録方法に関し、特に複数のプロトコルが混在するネットワーク環境にアタッチされるデータ記録システムのスループットおよび信頼性を向上する技術に関する。
【０００２】
【従来の技術】
インターネットあるいはＬＡＮ（local area network）に代表されるコンピュータネットワークの一般化およびコンピュータシステムの性能向上を背景として、より大きな容量のストレージ装置に対するニーズが高まっている。たとえばネットワークファイルあるいはウェブキャッシュとして大容量なデータストレージシステムが利用される。
【０００３】
ネットワークシステムにアタッチされるストレージシステムの一つとして、ＲＡＩＤ（redundant arrays of inexpensive disk）等のディスクアレイが知られている。ディスクアレイはたとえばＳＣＳＩ（small computer system interface）で接続されるためディスクアレイとネットワークとを接続するノードが用いられる。
【０００４】
また、一般にネットワークに接続される複数のコンピュータシステムでは異なるネットワークＯＳ（operating system）やＬＡＮアプリケーションが用いられる。このため、ネットワークに接続されるノードは、ネットワークＯＳやＬＡＮアプリケーションごとに相違するプロトコルに対応するようにしている。たとえば、Ｗｉｎｄｏｗｓ ＮＴ／９８（Ｗｉｎｄｏｗｓ及びＷｉｎｄｏｗｓ ＮＴはマイクロソフトコーポレーションの米国及びその他の国における商標）クライアントからノードにファイルアクセスを行う場合にはたとえばＣＩＦＳ（common internet file system）が用いられ、ＵＮＩＸ（Ｔｈｅ Ｏｐｅｎ Ｇｒｏｕｐがライセンスしている米国及びその他の国における登録商標）クライアントからのファイルアクセスではたとえばＮＦＳ（network file system）が用いられる。また、ウェブ環境におけるウェブキャッシュとして使用する場合にはＨＴＴＰ（hyper text transfer protocol）が用いられる。これら複数のプロトコルに対応できるノードとして前記したノードが構成される。
【０００５】
【発明が解決しようとする課題】
ところが、ネットワーク上でのファイルアクセス要求が増加し、また、ディスクアレイの総記録容量が増加するに従い、ノードへのトラフィックロードが増加する。単一のノードでは、ＣＰＵの速度、内部メモリの容量、バスバンド幅などの制限により処理スピードに限界がある。このためノードを複数設けてノードあたりの負荷を軽減する方策が採られる。
【０００６】
ノードを複数設ける方策の一つに、ディスクアレイをクラスタ化し、各ノード間でこのクラスタ化されたディスクアレイを共有する方法がある。しかしながらこの場合、ノード毎にアドレスを持つことになる。つまりネットワークに接続されるストレージシステムとして複数のアドレスを持つことになり、クライアントは各々アクセスポイントの管理を行う必要が生じる。このようなアクセスポイント管理（アドレス管理）はクライアントユーザにとって極めて不便であることは明らかである。
【０００７】
ノードを複数設ける他の方策に、各ノード間を高速バスで相互接続し、それぞれのノードをネットワークに接続する方法がある。しかしながらこの場合、前記した複数アドレス（アクセスポイント）管理の問題に加えて、キャッシュのヒット率低下の問題が生じる。つまり、ノードには階層化されたメモリシステムを有し、書込みあるいは読出しデータが一旦キャッシュに記録される。既にキャッシュされているデータと相違するプロトコルに従うデータが受け入れられた場合、アクセスパターンの相違等によりキャッシュのヒット率が低下する。この結果、ストレージシステム全体のパフォーマンスを低下させる原因となる。さらに、本方策の場合、高速バスでのデータ転送自体がボトルネックになる可能性もある。
【０００８】
本発明の目的は、ノードのロードを分割する場合においても、単一のアドレスで特定できるネットワークストレージシステムを提供することにある。
【０００９】
また、本発明の目的は、ノードのキャッシュヒット率を向上し、ネットワークストレージシステム全体のパフォーマンスを向上することにある。
【００１０】
また、本発明の目的は、ネットワークストレージシステム全体の信頼性を向上することにある。
【００１１】
【課題を解決するための手段】
本願の発明の概略を説明すれば、以下の通りである。すなわち、本発明のデータ記録システムでは、ネットワークのフロントエンドに位置するイーサネットスイッチによりプロトコル毎にデータを振り分け、同一プロトコルに従うデータは同一のサービスノードに振り分けるようにする。このようにサービスノードを特定プロトコルの処理に特化することにより、ノード内でのキャッシュのヒット率を高め、スループットとスケイラビリティを同時に実現する。また、ネットワークストレージは単一のフロントエンドスイッチでネットワークに接続されるため、クライアントは単一のアドレスを管理するだけで本ネットワークストレージシステムを利用することができ、ユーザのアドレス管理（ポート管理）を不要にして、ユーザの利便性を向上できる。
【００１２】
また、本データ記録システムでは、ノード間を高速バスで接続したクラスタ構造を実現する。そしてピアノードの不揮発性ストレージ間で同じ書込みデータを保持（ミラーリング）することにより、障害発生時のノードのリスタートを信頼性良く行う。これにより、システムの信頼性を向上できる。
【００１３】
なお、本発明を具体的に列記すれば以下の通りである。本発明のデータ記録システムは、異なる複数のプロトコルに従うデータを受け取り、プロトコル毎にデータの伝送先を切り換えるフロントエンドスイッチと、フロントエンドスイッチに接続され、複数のプロトコルのうち少なくとも一種類のプロトコルに適合する複数のノードと、ノードを介してデータの読み書きを行うデータストレージ装置とを有する。このとき、前記データのヘッダにはプロトコルの各々に対応付けられたポートＩＤを含み、ポートＩＤによりデータの伝送先を切り換えることができる。また、複数のノードの各々に不揮発性ストレージ領域を含み、不揮発性ストレージ領域が他のノードの不揮発性ストレージ領域と接続され、不揮発性ストレージ領域には、ノードへの書込みデータと他のノードへの書込みデータとが記録することができる。
【００１４】
また、本発明のデータ記録方法は、特定のプロトコルに関連付けられた識別情報を含むデータを受け取るステップと、識別情報を参照して、データが送付されるノードを切り換えるステップと、ノードを介してデータをデータストレージ装置に記録するステップと、を含む。このとき、識別情報は、プロトコル毎に関連付けられているポートＩＤとすることができる。また、データが書込みデータであるかを判断するステップと、判断が真の場合にはノードの不揮発性ストレージ領域、および、不揮発性ストレージ領域に接続された他のノードの不揮発性ストレージ領域にデータを書き込むステップと、データストレージ装置への書込みデータの書込み処理が終了した時には、不揮発性ストレージ領域、および、他のノードの不揮発性ストレージ領域に記録された書込みデータのデータ領域を開放するステップと、をさらに含むことができる。また、書込みデータの処理中にエラーが検出された時には、エラーが検出されたノード以外の不揮発性ストレージ領域に記録された書込みデータを、その不揮発性ストレージ領域を含むノードを経由してデータストレージ装置に記録することができる。
【００１５】
なお、前記データ記録システムを構成要素とするネットワークシステムとして本発明を把握することができるのは勿論である。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００１７】
図１は、本発明の一実施の形態であるデータストレージシステムとデータストレージシステムが接続されたネットワークシステムの一例を示した全体構成図である。本実施の形態のネットワークシステムは、コンピュータシステム１〜３とデータストレージシステム４とがイーサネット５でネットワーク接続された構成を有する。
【００１８】
コンピュータシステム１〜３は、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ(Random Access Memory)）、不揮発性記憶装置（ＲＯＭ(Read Only Memory)）等がバスで相互に接続された一般的なコンピュータシステムである。前記バスにはコプロセッサ、画像アクセラレータ、キャッシュメモリ、データ入出力のためのインタフェイス等が接続され、インタフェイスにはハードディスクドライブ等の外部記憶装置、キーボード、マウス等の入出力装置、液晶表示装置、ＣＲＴ（cathode ray tube）等の表示装置、通信制御装置等が接続される。通信制御装置は、たとえば以下に説明するイーサネット規格に適合し、データを高速に通信することができる。その他一般的なコンピュータシステムに備えられるハードウェア資源を備えることができることは勿論である。なお、本実施の形態のコンピュータシステム１〜３は、適当な通信回線あるいは前記イーサネット５を介してインターネットあるいはイントラネットに接続することが可能である。通信回線には、無線、有線、専用線、公衆回線等あらゆる通信手段が含まれる。
【００１９】
また、本実施の形態のコンピュータシステム１〜３は各々異なるＯＳで動作し、各々のＯＳでサポートする通信プロトコルが相違する。たとえばコンピュータシステム１ではＯＳとしてＷｉｎｄｏｗｓ ＮＴ／９８で動作し、データストレージシステム４に対してクライアントとして機能する際にはＣＩＦＳプロトコルが適用される。また、コンピュータシステム２ではＯＳとしてＵＮＩＸが動作し、データストレージシステム４に対して共有データアクセスを行う際にはＮＦＳプロトコルが適用される。また、コンピュータシステム３の適当なＯＳ上でウェブ（ＷＷＷ）に対するＨＴＴＰリクエストが生じた時には、データストレージシステム４に対してネットワークからリクエストがルーティングされる。この時通信プロトコルにはＨＴＴＰが適用される。すなわち、コンピュータシステム１〜３では異なる通信プロトコルをサポートし、イーサネット５上では複数の通信プロトコルが混在する。
【００２０】
イーサネット５は、ＩＥＥＥ８０２．３で規定された伝送規格であり、ＯＳＩ（open system interconnection）参照モデルでは物理層（第１層）およびデータリンク層（第２層）に相当する。なお、本実施の形態ではイーサネットを例示するが、トークンリング（ＩＥＥＥ８０２．５）、ＦＤＤＩ（fiber distributed data interface）、ＴＰＤＤＩ（twisted pair distributed data interface）、ローカルトーク（ＲＳ−４２２）等ＯＳＩ参照モデルで物理層およびデータリンク層に相当する他の伝送規格を用いることも可能である。
【００２１】
データストレージシステム４には、フロントエンドスイッチ６、複数のノード７、ＲＡＩＤ装置８が含まれる。
【００２２】
フロントエンドスイッチ６は、イーサネット５およびノード７に接続され、イーサネット５から伝送されたデータをプロトコル毎に割当てられたノード７に振り分ける機能を持つ。フロントエンドスイッチの詳細については後述する。
【００２３】
ノード７は、フロントエンドスイッチ６によって割り振られたデータを受け取り、ＲＡＩＤ装置８にデータをインタフェイスする。ノード７は、複数プロトコルに適応可能なようにプロトコル毎の処理手段を有する。但し、ネットワークで使用される全てのプロトコルをサポートする必要はなく、単一のプロトコルを処理するものであっても良い。ノード７にはたとえばバッテリでバックアップされた不揮発性のメモリ領域であるＮＶＳ（Non Volatile Storage）９を有し、各ノード７のＮＶＳ９は高速バス１０で相互に接続される。高速バスにはＳＣＩ（Scalable Coherent Interface）を例示できる。なお、図１では３つのノード７を例示するがそれ以上のノードが設けられても良い。ノード７の詳細については後に説明する。
【００２４】
ＲＡＩＤ装置８は、たとえばハードディスクアレイ１１で構成された記録装置であり、ノード７とファイバーチャネル１２でリング状に接続される。ＲＡＩＤ装置８にはハードディスクアレイ１１を制御するＲＡＩＤコントローラ１３が含まれる。なお、図１では複数のＲＡＩＤ装置８を例示するが、ＲＡＩＤ装置８は１台でも構わない。
【００２５】
図２は、フロントエンドスイッチの詳細を示したブロック図である。本実施の形態のフロントエンドスイッチには、ポート１〜ｎを持つイーサネットインタフェイス１４、ＭＡＣ（media access control）インタフェイス１５、入力キュー１６、出力キュー１７、ファブリックインタフェイス１８、スイッチファブリック１９を有し、ポートルックアップテーブル２０、フレーム転送エンジン２１、データバッファ２２を備える。
【００２６】
ポート１〜ｎは、図１におけるイーサネット５およびノード７に接続するポートである。イーサネットインタフェイス１４はノード内部とイーサネット５とのインタフェイスを行い、ＭＡＣインタフェイス１５ではたとえばＩＰアドレスとメディア固有のＭＡＣアドレスとの対応付けを行う。入力キュー１６および出力キュー１７では、各々データの入力および出力の待ち行列を制御し、ファブリックインタフェイス１８では入出力キュー１６，１７とスイッチファブリック１９とのインタフェイスを行う。スイッチファブリック１９は、データのルーティングを行う伝送先切り換え手段であり、フレーム転送エンジン２１によって制御される。
【００２７】
ポートルックアップテーブル２０は、特定のプロトコルに関連付けられているポートＩＤと、プロトコル毎に割当てられる特定の物理ポートとを対応付けたテーブルである。図３は、ポートルックアップテーブルの一例を示した表図である。本実施の形態のネットワークストレージシステムの場合、同じデスティネーションアドレスであっても、第４層（トランスポート層）でのアプリケーション（プロトコル）が相違する場合には、異なる物理ポートにルーティングする。たとえば「１．２２２．３３３．４４」のデスティネーションアドレスでＮＦＳのポートＩＤが指定されて受け入れられたデータは物理ポート「０」にルーティングされる。同様にＣＩＦＳのポートＩＤから受け入れられたデータは物理ポート「１」にルーティングされる。ＨＴＴＰについても同様である。なお、ポートルックアップテーブル２０には他のデスティネーションアドレスが含まれても良いことは勿論である。
【００２８】
フレーム転送エンジン２１は、フレーム単位で受け入れたデータのポートＩＤを識別し、ポートルックアップテーブル２０を参照して転送先を決定する手段である。スイッチファブリック１９と協働してデータのルーティングを行う。データバッファ２２にはデータがバッファされる。
【００２９】
図４は、ノードの詳細を示したブロック図である。本実施の形態のノード７は、ＣＰＵ２３、メモリバスコントローラ２４、ＣＰＵメモリ・データバッファ２５、ファームウェア・フラッシュＲＯＭ２６、ＧＰＩＯ（General Purpose Input Output）２７、ネットワークコントローラ２８、ギガビットイーサネットインタフェイス２９、ストレージデバイスコントローラ３０、ファイバチャネルインタフェイス３１、フロントエンドスイッチコントローラ３２、ＮＶＳコントローラ３３、およびＮＶＳ９を含む。
【００３０】
ＣＰＵ２３はノードを制御する計算やメモリ間のデータ転送等を制御する中央演算処理装置である。単一のプロセッサあるいは複数プロセッサからなる。メモリバスコントローラ２４は、各種メモリ間のデータ転送をＣＰＵを介さずに直接行う制御装置である。高速なデータ転送が実現できる。ＣＰＵメモリ・データバッファ２５はたとえばＤＲＡＭ（Dynamic Random Access Memory）で構成され、ＣＰＵ２３に入力されるプログラムあるいはデータが記録されるほか、データのバッファリングにも利用される。ファームウェア・フラッシュＲＯＭ２６には、ノードを制御するプログラムが記録される。ＣＰＵ２３からファームウェア・フラッシュＲＯＭ２６に対して直接プログラムを読み出す他、一旦ＣＰＵメモリ・データバッファ２５にプログラムが転送され、ＣＰＵからはＣＰＵメモリ・データバッファ２５上のプログラムを読み出すこともできる。ＧＰＩＯ２７は、各種構成スイッチの読み取り、および状態表示用ＬＥＤのインタフェイス機能を持つ。
【００３１】
ネットワークコントローラ２８、ストレージデバイスコントローラ３０、フロントエンドスイッチコントローラ３２は、各々ネットワーク（イーサネット５）、ＲＡＩＤ装置８、フロントエンドスイッチ６を制御する。ギガビットイーサネットインタフェイス２９は、ネットワークコントローラ２８とイーサネット５とをインタフェイスし、ファイバチャネルインタフェイス３１はストレージデバイスコントローラ３０とＲＡＩＤ装置８をインタフェイスする。ＮＶＳコントローラ３３は、ＮＶＳ９を制御し、ピアノードのＮＶＳコントローラに接続される。
【００３２】
次に、前記したネットワークストレージシステムを用いてデータを記録する方法について説明する。図５は、フロントエンドスイッチ６での処理の一例を示したフローチャートである。
【００３３】
コンピュータシステム１〜３から発せられたデータ（フレーム）がイーサネット５を介してフロントエンドスイッチ６に伝送され、フロントエンドスイッチ６がこのフレームを受取ることにより処理が開始する（ステップ４０）。フレームは図２に示すフロントエンドスイッチのポートから受信され、受信されたフレームはイーサネットインタフェイス１４を介してＭＡＣインタフェイス１５に送られる。
【００３４】
ＭＡＣインタフェイス１５では、受取ったデータのヘッダに含まれるＩＰアドレスから機器固有のＭＡＣアドレスに従ってフレームを入力キュー１６に転送する（ステップ４１）。なお、ＭＡＣアドレスとＩＰアドレスとの対応は、ＡＲＰテーブルとしてネットワーク内のルータ等に記録されており、フロントエンドスイッチ内のデータバッファにも同じテーブルを保持している。また、ネットワーク内のＩＰアドレスにはローカルアドレスを用いることができる。
【００３５】
次に、フレーム転送エンジン２１がフレームヘッダからポート番号を抽出する（ステップ４２）。ポート番号は、アプリケーションに関連付けて通常同じプロトコルでは同じポートを開いてデータの送受信を行うために付される。たとえばＨＴＴＰではポート番号は８０、ｎｅｔｂｉｏｓ−ｎｓではポート番号１３７のポートが開かれる。
【００３６】
次に、ヘッダから抽出されたポート番号とポートルックアップテーブル２０を参照して、フレームの転送先物理ポートをサーチする（ステップ４３）。そして、フレーム転送テーブル（図示せず）に転送先の物理ポートを指定し（ステップ４４）、フレームを出力キュー１７に転送する（ステップ４５）。
【００３７】
その後、フレームは出力キュー１７の処理に従って物理ポートからノードに転送されることになる（ステップ４６）。
【００３８】
前記した通り、フロントエンドスイッチ６の物理ポートには何れかのノード７が接続されているので、特定のノードには特定のプロトコルに従うデータが転送されることになる。このように特定のノードには、特定のプロトコルに従うデータ（フレーム）が転送されるので、後に説明するノードでの処理において、キャッシュヒット率が向上する。すなわち、通常プロトコルによってディレクトリ構造やアクセスパターンが相違するが、本実施の形態のシステムによればノードにおいては結果的に常に同一プロトコルのファイルアクセス処理を行うことになる。常に同一のアクセスパターンあるいはディレクトリ構造のデータ処理をノードにおいて行うこととなり、必然的にキャッシュヒット率が向上することになる。これによりノードでの処理のスループットを向上し、システム全体のパフォーマンスを向上することができる。
【００３９】
また、本実施の形態のフロントエンドスイッチ６は単一のＩＰアドレスで指定される。つまりユーザは自己の使用するプロトコルを意識することなく、単一のフロントエンドスイッチ６のアドレスを指定してファイルシステムを利用できる。これにより、ユーザに煩雑なアドレス管理を強いることなく、スケーラビリティと高いスループットが実現されたファイルシステムを実現できる。
【００４０】
次に、ノードでの処理をフローチャートを用いて説明する。図６は、ノードにおけるデータ記録処理の一例を示したフローチャートである。
【００４１】
前記したフロントエンドスイッチ６での処理の後、ノード７にデータ（フレーム）が転送されてくる（ステップ４７）。その後、フレームを受取ったノード７は、まずＩＰ層（ネットワーク層）の処理を行い（ステップ４８）、続いてＴＣＰあるいはＵＤＰ層（トランスポート層）での処理を行う（ステップ４９）。ＩＰ層での処理は、主に、径路制御、ネットワークコネクションの確立、多重化とフロー制御、データパケットの分割・統合等を行う。ＴＣＰあるいはＵＤＰ層では、主に、上位層であるセッション層（ＯＳＩ参照モデルにおける第５層以上）に透過的なデータを提供し、多重化制御、フロー制御、再送制御（ＴＣＰの場合）等を行う。
【００４２】
次に、上位プロトコルの識別を行い（ステップ５０）、プロトコルに従った処理を行う（ステップ５１〜５３）。たとえばＣＩＦＳの場合にはＣＩＦＳに応じた処理を行い（ステップ５１）、ＨＴＴＰの場合はＨＴＴＰに応じた処理を行う（ステップ５２）。ＩＰ層の処理の場合はそれに応じた処理を行う（ステップ５３）。なお、本実施の形態では、複数のプロトコルに対応可能なノードを例示しているが、たとえばＣＩＦＳにのみ対応するノードであっても良い。この場合、ステップ５０をパスしてステップ５１を実行する。
【００４３】
次に、ファイルシステムの処理を行う（ステップ５４）。ファイルシステム処理では、ＲＡＩＤ装置８へのデータ転送のための各種の計算等を行う。
【００４４】
次に、現在処理しているデータが書込みデータであるかを判断する（ステップ５５）。書込みデータである場合（ステップ５５の判断がＹｅｓの時）にはＮＶＳ９へのデータ転送を行う（ステップ５６）。その後データバッファ２５等のキャッシュにデータを転送し（ステップ５７）、さらにキャッシュからストレージデバイスコントローラ３０を介してファイバチャネルにデータを転送する（ステップ５８）。なお、書込みデータである際の処理は後に詳しく説明する。
【００４５】
一方、ファイルシステム処理が読込みデータを必要とする場合（ステップ５５の判断がＮｏの時）、キャッシュ内部の有効データを検索し（ステップ５９）、キャッシュヒットか否かの判断を行う（ステップ６０）。キャッシュヒットの場合はこのデータをネットワークコントローラを経由してネットワークにデータ転送を行う（ステップ６２）。キャッシュミスの場合はファイバチャネルからストレージデバイスコントローラを経由してデータバッファ内のキャッシュにデータを転送し（ステップ６１）、キャッシュからネットワークコントローラを経由してネットワークにデータ転送を行う（ステップ６２）。
【００４６】
以上ノードにおける処理はフラッシュＲＯＭ２６に記録されたファームウェアに従ってＣＰＵ２３の制御のもとに行われる。上記処理において、あるノード７に受け入れられるデータのプロトコルは前記した通りフロントエンドスイッチ６によって同じプロトコルに振り分けられている。このため、ファイルシステム層での処理において、キャッシュされたデータの利用率つまりキャッシュヒット率が高くなる。このため複数ノードを用いてファイルシステムの処理負担を軽減しつつ、各ファイルシステムでの処理効率（スループット）を向上できる。
【００４７】
図７は、ノードにおいて書込み処理が行われる時の処理の一例を示したフローチャートである。まず、ネットワークコントローラ２８からデータバッファ２５にデータが転送される（ステップ６３）。次にネットワークコントローラ２８からＮＶＳ９にデータが転送される（ステップ６４）とともに、ピアノードのＮＶＳにデータが転送される（ステップ６５）。つまり、書込み操作時に、書込み操作を行っているノードのＮＶＳとピアノードのＮＶＳとに同一データが書込まれ、ある書込み操作における書込みデータは常にコピーを持つことになる。
【００４８】
図８は、書込み動作時のノード間でのＮＶＳデータをコピーする操作について説明した図である。ノードＡのＮＶＳコントローラ３３−１によってノードＡが処理する書込みデータをノードＡのＮＶＳ９−１に書き込むとともに、ノードＡのＮＶＳコントローラ３３−１からノードＢのＮＶＳコントローラ３３−２に同じ書込みデータが転送され、ノードＢのＮＶＳコントローラ３３−２を介してノードＢのＮＶＳ９−２にノードＡが処理する書込みデータを書き込む。つまり、ノードＡとノードＢとはピアノードを構成し、ノードＡの書込みデータは、ノードＡのＮＶＳ９−１に書込まれるとともに、ノードＢのＮＶＳ９−２にもコピーが保持される。同様に、ノードＢの書込みデータはノードＣのＮＶＳにコピーが保持され、順次サイクリックにピアノード間で書込みデータのコピーが保持され、最後はノードｎの書込みデータがノードＡのＮＶＳ９−１に保持される。
【００４９】
このように、書込みデータを自己のノードＮＶＳだけでなく、ピアノードのＮＶＳにもコピーを保持することにより、後に説明するようにノードに障害を生じた時の復帰がしやすくなる。すなわち、安定したノードのリスタートを実現でき、システム全体の信頼性を向上することができる。
【００５０】
上記のようにＮＶＳへのデータ転送を行った後、ノードはファイルシステム層での書込み処理を完了する（ステップ６６）。
【００５１】
次に、データバッファ２５からストレージデバイスコントローラ３０にデータが転送され、ファイバチャネルインタフェイス３１を介してストレージ（ＲＡＩＤ装置８）にデータが送出される（ステップ６７）。ストレージからのライトコンプリートの信号を受信すればストレージでの書込み処理の完了を確認する（ステップ６８）。
【００５２】
書込み処理の完了後、自己ノードのＮＶＳおよびピアノードのＮＶＳに記録されたデータの記憶領域を開放（あるいはデータを消去）する（ステップ６９）。以上のようにして書込み処理が完了する。
【００５３】
次に、ノードで障害が発生した時の処理について説明する。図９はノードエラーを生じた時の処理の一例を示したフローチャートである。
【００５４】
エラー時の復帰処理は、ノードでのエラー検出で開始する（ステップ７０）。エラーが検出された時、ピアノードがあるかを判断する（ステップ７１）。
【００５５】
ピアノードがある場合には、ピアノードのＮＶＳにコミットされていないデータがあるかをチェックする（ステップ７２）。コミットされていないデータがある場合、このデータをピアノードを経由してストレージにステージング（書き込み）処理を行う（ステップ７３）。なお、ステージング処理については前記の通りである。ストレージからの書込み完了信号の受信により書込み処理が完了し（ステップ７４）、書込み処理の完了後、障害の発生したノードのリスタート処理を行う（ステップ７５）。その後通常の処理に復帰する（ステップ７６）。
【００５６】
一方、ピアノードがない場合、ノードのリスタート処理および通常の処理を停止し（ステップ７７）、ＮＶＳ上にコミットされていないデータがあるかをチェックする（ステップ７８）。その後、コミットされていないデータについて、ＮＶＳからそのノードのストレージデバイスコントローラ３０にデータを転送し（ステップ７９）、ストレージでの書込み処理の完了を確認する（ステップ８０）。そして通常動作に復帰する（ステップ７６）。
【００５７】
すなわち、ピアノードがある場合には障害が発生したノードとそのピアノードについてのみ特別のリスタート処理を行い、ピアノードがない場合には全てのノードについてリスタート処理を行う。前記の通り、本実施の形態のストレージシステムでは原則的に何れのノードにおいてもピアノードに書込みデータのコピーデータを保持するため、何れのノードに障害を生じた場合でもそのノードとピアノードの処理を一時停止するのみであり、他のノードには障害の影響を及ぼさない。この結果、ノードに障害を生じてもシステム全体を停止することなく、冗長性が高くつまり信頼性の高いシステムを構築できる。
【００５８】
なお、ＮＶＳ上にコミットされていないデータが発見されない場合には、障害の発生以前に全てのステージング処理は正常に完了しており、ノードをリスタートする等の処理のみを行う。
【００５９】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【００６０】
たとえば、前記実施の形態では、ファイルシステム（ＲＡＩＤ装置８）へのインタフェイスとしてファイバーチャネルを例示したが、ＦＤＤＩ、ＡＴＭ（asynchronous transfer mode）であっても良い。
【００６１】
また、前記実施の形態では、アプリケーションによるプロトコルの相違をポート番号で識別したがこれに限られず、その他ヘッダに含まれる識別情報を用いることも可能である。
【００６２】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、ノードのロードを分割する場合においても、単一のアドレスで特定できるネットワークストレージシステムを提供できる。また、ノードのキャッシュヒット率を向上し、ネットワークストレージシステム全体のパフォーマンスを向上できる。ネットワークストレージシステム全体の信頼性を向上することができる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるデータストレージシステムとデータストレージシステムが接続されたネットワークシステムの一例を示した全体構成図である。
【図２】フロントエンドスイッチの詳細を示したブロック図である。
【図３】ポートルックアップテーブルの一例を示した表図である。
【図４】ノードの詳細を示したブロック図である。
【図５】フロントエンドスイッチでの処理の一例を示したフローチャートである。
【図６】ノードにおけるデータ記録処理の一例を示したフローチャートである。
【図７】ノードにおいて書込み処理が行われる時の処理の一例を示したフローチャートである。
【図８】書込み動作時のノード間でのＮＶＳデータをコピーする操作について説明した図である。
【図９】ノードエラーを生じた時の処理の一例を示したフローチャートである。
【符号の説明】
１〜３…コンピュータシステム、４…データストレージシステム、５…イーサネット、６…フロントエンドスイッチ、７…ノード、８…ＲＡＩＤ装置、９（９−１〜９−ｎ）…ＮＶＳ、１０…バス、１１…ハードディスクアレイ、１２…ファイバーチャネル、１３…ＲＡＩＤコントローラ、１４…イーサネットインタフェイス、１５…ＭＡＣインタフェイス、１６…入力キュー、１７…出力キュー、１８…ファブリックインタフェイス、１９…スイッチファブリック、２０…ポートルックアップテーブル、２１…フレーム転送エンジン、２２…データバッファ、２３…ＣＰＵ、２４…メモリバスコントローラ、２５…ＣＰＵメモリ・データバッファ、２６…ファームウェア・フラッシュＲＯＭ、２７…ＧＰＩＯ、２８…ネットワークコントローラ、２９…ギガビットイーサネットインタフェイス、３０…ストレージデバイスコントローラ、３１…ファイバチャネルインタフェイス、３２…フロントエンドスイッチコントローラ、３３（３３−１〜３３−ｎ）…ＮＶＳコントローラ。
Claims (4)
- 単一のＩＰアドレスで指定され、異なる複数のプロトコルに従うデータを受け取り、前記プロトコル毎に前記データの伝送先を切り換えるフロントエンドスイッチと、
前記フロントエンドスイッチに接続され、前記複数のプロトコルのうち少なくとも一種類のプロトコルに適合する複数のノードと、
前記複数のノードのうち何れかのノードを介して前記データの読み書きを行う、前記複数のノードに共通のデータストレージ装置とを有し、
前記複数のノードの各々は、前記データストレージ装置に書き込むデータ及び前記データストレージ装置から読み出したデータを記憶するキャッシュと、不揮発性ストレージ領域とを含み、
各ノードの不揮発性ストレージ領域はピアノードの不揮発性ストレージ領域に接続され、前記各ノードの不揮発性ストレージ領域には、そのノードへの書込みデータと前記ピアノードへの書込みデータとが記録され、前記書込みデータが前記データストレージ装置に書き込まれると、前記不揮発性ストレージ領域において前記書込みデータのデータ領域が開放される、
データ記録システム。 - 各々異なるプロトコルに従ってデータを送受信する複数のコンピュータシステムと、
単一のＩＰアドレスで指定され、前記データを受け取り、前記プロトコル毎に前記データの伝送先を切り換えるフロントエンドスイッチと、がネットワークに接続され、
前記プロトコルのうち少なくとも一種類のプロトコルに適合する前記フロントエンドスイッチに接続された複数のノードと、
前記複数のノードのうち何れかのノードを介して前記データの読み書きを行う、前記複数のノードに共通のデータストレージ装置とを有し、
前記複数のノードの各々は、前記データストレージ装置に書き込むデータ及び前記データストレージ装置から読み出したデータを記憶するキャッシュと、不揮発性ストレージ領域とを含み、
各ノードの不揮発性ストレージ領域はピアノードの不揮発性ストレージ領域に接続され、前記各ノードの不揮発性ストレージ領域には、そのノードへの書込みデータと前記ピアノードへの書込みデータとが記録され、前記書込みデータが前記データストレージ装置に書き込まれると、前記不揮発性ストレージ領域において前記書込みデータのデータ領域が開放される、
ネットワークシステム。 - 単一のＩＰアドレスで指定され、異なる複数のプロトコルに従うデータを受け取り、前記プロトコル毎に前記データの伝送先を切り換えるフロントエンドスイッチと、前記フロントエンドスイッチに接続され、前記複数のプロトコルのうち少なくとも一種類のプロトコルに適合する複数のノードと、前記複数のノードのうち何れかのノードを介して前記データの読み書きを行う、前記複数のノードに共通のデータストレージ装置と、を有するデータ記録システムにおけるデータ記録方法であって、
前記フロントエンドスイッチが、前記プロトコルに関連付けられた識別情報を含む前記データを受け取るステップと、
前記フロントエンドスイッチが、前記識別情報を参照して、前記複数のノードのうち前記プロトコルに適合するノードに前記データを送信するステップと、
前記データが送信されたノードが、前記データを前記データストレージ装置に記録するステップとを含み、
前記複数のノードの各々は、前記データストレージ装置に書き込むデータ及び前記データストレージ装置から読み出したデータを記憶するキャッシュと、不揮発性ストレージ領域とを含み、前記不揮発性ストレージ領域がピアノードの不揮発性ストレージ領域と接続され、
前記データが送信されたノードが、前記データが書込みデータであるかを判断するステップと、
前記判断が真の場合、前記データが送信されたノードが、前記不揮発性ストレージ領域および前記ピアノードの不揮発性ストレージ領域に前記データを書き込むステップと、
前記データストレージ装置への前記書込みデータの書込み処理が終了した時には、前記データが送信されたノードが、前記不揮発性ストレージ領域および前記ピアノードの不揮発性ストレージ領域に記録された前記書込みデータのデータ領域を開放するステップと、
をさらに含むデータ記録方法。 - 前記ピアノードがあるかを判断するステップと、
前記判断が真の場合には、
前記ピアノードに含まれる不揮発性ストレージ領域に未処理のデータがあるかを検査するステップと、
前記未処理のデータを前記ピアノードを経由して前記データストレージ装置に記録するステップと、
前記エラーが検出されたノードのリスタート処理を行うステップと、
をさらに含む請求項３記載のデータ記録方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000387497A JP4187403B2 (ja) | 2000-12-20 | 2000-12-20 | データ記録システム、データ記録方法およびネットワークシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000387497A JP4187403B2 (ja) | 2000-12-20 | 2000-12-20 | データ記録システム、データ記録方法およびネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002215554A JP2002215554A (ja) | 2002-08-02 |
| JP4187403B2 true JP4187403B2 (ja) | 2008-11-26 |
Family
ID=18854419
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000387497A Expired - Fee Related JP4187403B2 (ja) | 2000-12-20 | 2000-12-20 | データ記録システム、データ記録方法およびネットワークシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4187403B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7797392B2 (en) * | 2002-11-26 | 2010-09-14 | International Business Machines Corporation | System and method for efficiently supporting multiple native network protocol implementations in a single system |
| US20050114595A1 (en) * | 2003-11-26 | 2005-05-26 | Veritas Operating Corporation | System and method for emulating operating system metadata to provide cross-platform access to storage volumes |
| JP5045229B2 (ja) * | 2007-05-14 | 2012-10-10 | 富士ゼロックス株式会社 | ストレージシステム及びストレージ装置 |
| JP5427245B2 (ja) * | 2009-09-01 | 2014-02-26 | 株式会社日立製作所 | マルチコアプロセッサを有する要求処理システム |
| JP5900096B2 (ja) | 2012-03-28 | 2016-04-06 | 富士通株式会社 | レプリケーションシステム、レプリケーションプログラム及びレプリケーション構成の再構築方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000242434A (ja) * | 1998-12-22 | 2000-09-08 | Hitachi Ltd | 記憶装置システム |
| US6321298B1 (en) * | 1999-01-25 | 2001-11-20 | International Business Machines Corporation | Full cache coherency across multiple raid controllers |
-
2000
- 2000-12-20 JP JP2000387497A patent/JP4187403B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002215554A (ja) | 2002-08-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11140084B2 (en) | TCP/UDP acceleration | |
| US6687758B2 (en) | Port aggregation for network connections that are offloaded to network interface devices | |
| JP4448719B2 (ja) | ストレージシステム | |
| US7424519B2 (en) | Distributed storage system, storage device and method of copying data | |
| US6389432B1 (en) | Intelligent virtual volume access | |
| US9357030B2 (en) | Clustered cache appliance system and methodology | |
| US7328223B2 (en) | Storage management system and method | |
| US8560631B2 (en) | Storage system | |
| US6985956B2 (en) | Switching system | |
| US7089293B2 (en) | Switching system method for discovering and accessing SCSI devices in response to query | |
| US6085234A (en) | Remote file services network-infrastructure cache | |
| JP4014923B2 (ja) | 共有メモリ制御方法および制御システム | |
| US20030105931A1 (en) | Architecture for transparent mirroring | |
| US20040210584A1 (en) | Method and apparatus for increasing file server performance by offloading data path processing | |
| US20040078419A1 (en) | Switching system | |
| US7003556B2 (en) | Storage system and a method for unilaterally administering data exchange with the storage system | |
| NO331320B1 (no) | Balansering av nettverksbelastning ved bruk av informasjon om vertsmaskin-status | |
| JP4106014B2 (ja) | 少なくとも１つの不揮発性データ記憶装置を含む複数ノード・データ処理システムにおける通信方法およびプログラム | |
| WO2002037225A9 (en) | Switching system | |
| JP4187403B2 (ja) | データ記録システム、データ記録方法およびネットワークシステム | |
| JP4028627B2 (ja) | クライアントサーバシステムおよびクライアントサーバシステムの通信管理方法 | |
| US7539711B1 (en) | Streaming video data with fast-forward and no-fast-forward portions | |
| Tan et al. | Layer 4 fault tolerance: Reliability techniques for cluster system in internet services | |
| JP4284837B2 (ja) | 負荷分散サーバシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050202 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050428 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050509 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050802 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060307 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060606 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060615 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060907 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061107 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20061117 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070307 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070410 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080902 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080909 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110919 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |