JP2015018579A - データストレージシステム、およびデータアクセス要求を処理する方法 - Google Patents

Abstract

【課題】ＺＦＳファイルシステムを作成またはサイズ変更するのに必要な時間および労力は、他のいくつかのシステムにおける容量操作よりも、新しいディレクトリを作成する時間および労力により近くなる。【解決手段】データストレージシステムは、複数のサーバと、これらのサーバのうち１つのサーバ上で各々展開された複数の外部インターフェイスプロバイダと、これらのサーバのうち１つのサーバ上で各々展開された複数のデータストレージコントローラとを含む。プロバイダの各々は、データアクセス要求を受信して、コントローラのうち要求を満たすことのできる１つのコントローラを識別し、識別されたコントローラに要求を転送するよう構成される。システムは、さらに、サーバから独立した複数のデータストレージモジュールを含む。プロバイダ、コントローラおよびモジュールは互いと通信する。【選択図】図１

Description

背景
コピー・オン・ライト（「ＣＯＷ」（Copy-on-write））はコンピュータプログラミングにおいて用いられる最適化戦略である。初めのうちは識別不可能なリソースの複数のリクエスタは、同じリソースに対する所与のポインタとなる。この戦略は、リクエスタがリソースのそのコピーを変更するよう試みるまで維持される。次いで、専用のコピーを作成して、如何なる変更も他のリクエスタから見えなくなるようにする。このような専用のコピーの作成はリクエスタにとってトランスペアレントである。リクエスタがリソースのコピーを変更しようとしない場合、専用のコピーは作成されない。

仮想メモリオペレーティングシステムはＣＯＷを用い得る。あるプロセスでそれ自体のコピーを作成する場合、プロセス（またはそのコピー）によって変更され得るメモリ内のページはＣＯＷと印付けされる。１つのプロセスでメモリを変更する場合、オペレーティングシステムのカーネルがオペレーションを遮ってメモリをコピーして、一方のプロセスのメモリ内の変更が他方のプロセスのメモリには見えなくなるようにしてもよい。

ＣＯＷはまた、動的なメモリ割当を実行するためにＣおよびＣ＋＋規格ライブラリにおいて提供されるｃａｌｌｏｃ関数で用いられてもよい。物理メモリのページはたとえばゼロで満たされてもよい。メモリが割当てられた場合、戻されるページはすべてゼロのページを指していてもよく、ＣＯＷと印付けされてもよい。このため、データが書込まれるまで、処理に割当てられた物理メモリの量は増えない。

メモリ管理ユニット（ＭＭＵ：memory management unit）は、ＣＯＷを実現するために、読出し専用としてのプロセスのアドレス空間におけるいくつかのページを処理するよう指示され得る。データがこれらのページに書込まれた場合、ＭＭＵは、カーネルが処理すべき例外を発生させる可能性がある。次いで、カーネルは、物理メモリにおいて新しい空間を割当てて、書込まれたページを物理メモリにおけるその新しい位置に対応させる。

ＣＯＷは、メモリの効率的な使用を可能にし得る。物理メモリの使用量は、データがそこに記憶される場合にのみ増大する。

カーネルの外部では、ＣＯＷはライブラリ、アプリケーションおよびシステムコードにおいて用いられてもよい。たとえば、Ｃ＋＋規格ライブラリによって与えられるストリングクラスはＣＯＷの実現を可能にする。ＣＯＷはまた、仮想ディスクストレージ用のＢｏｃｈｓ、ＱＥＭＵおよびＵＭＬなどの仮想化／エミュレーションソフトウェアにおいて用いられてもよい。これにより、（ｉ）複数の仮想機械（ＶＭ：virtual machines）が同じハードディスクイメージに基づき得る場合に所要のディスク空間を減らし、（ｉｉ）ディスク読出がＲＡＭにおいてキャッシュされ、後続の読出がキャッシュの外側にある他のＶＭに対して機能し得るのに応じて性能を高め得る。

ＣＯＷは、データベースサーバ上でインスタントスナップショットのメンテナンスに用いられてもよい。インスタントスナップショットは、基礎をなすデータが更新されると、データの変更前コピーを記憶することによってデータベースについての表示を静止させたまま保存する。インスタントスナップショットはテスト依存またはモーメント依存のレポートに用いられる。ＣＯＷはまた、論理ボリューム管理によって与えられるスナップショットのために、基礎をなすメカニズムとして用いられてもよい。

ＣＯＷは、ウェアレベリングを必要とするかまたは物理的に追記型光ディスクである媒体上での読出／書込ストレージをエミュレートするのに用いられてもよい。

ＺＦＳは、ソラリス（Solaris）オペレーティングシステム用にサン・マイクロシステムズ（Sun Microsystems）社によって設計されたファイルシステムである。ＺＦＳの特徴は、高い記憶容量、ファイルシステムおよびボリューム管理の概念の統合、スナップショットおよびＣＯＷクローン、オンライン保全性のチェックおよび修復、ならびにＲＡＩＤ−Ｚのためのサポートを含み得る。

単一のデバイス上に常駐し、このためボリュームマネージャが２つ以上のデバイスを用いることを必要とし得る従来のファイルシステムとは異なり、ＺＦＳファイルシステムはｚｐｏｏｌと称される仮想ストレージプールの上に構築される。ｚｐｏｏｌは、それら自体がブロックデバイス、すなわちファイル、ハードドライブ区画またはドライブ全体、で構成される仮想デバイス（ｖｄｅｖ）で構成される。

ｖｄｅｖ内のブロックデバイスは、利用可能な空間および必要に応じて、さまざまな方法で構成され得る。すなわち、２つ以上のデバイスのミラー（ＲＡＩＤ １）として、３つ以上のデバイスの（パリティに関するＲＡＩＤ ５と同様の）ＲＡＩＤ−Ｚグループとして、または、４つ以上のデバイスの（パリティに関するＲＡＩＤ ６と同様の）ＲＡＩＤ−Ｚ２グループとして、（ＲＡＩＤ ０と同様に）非冗長的に構成され得る。すべてのｖｄｅｖｓの記憶容量は、ｚｐｏｏｌにおけるすべてのファイルシステムインスタンスにとって利用可能であり得る。

ＺＦＳはＣＯＷトランザクションのオブジェクトモデルを用いる。ファイルシステム内のブロックポインタはすべて、ブロックの読出し時に確認される２５６ビットチェックサムの目標ブロックを含んでいてもよい。アクティブデータを含むブロックは、所定の位置には上書きされない。代わりに、新しいブロックが割当てられ、変更されたデータがそこに書込まれると、これを参照するいずれのメタデータブロックも同様に読出され、再度割当てられ、書込まれる。このプロセスのオーバーヘッドを減じるために、複数回の更新がトランザクショングループにグループ化されてもよい。同期書込みのセマンティクスが必要であればインテントログが用いられてもよい。

ＺＦＳが新しいデータを書込んだ場合、古いデータを含むブロックが保持されて、ファイルシステムのスナップショットバージョンを維持することが可能となり得る。スナップショットを構成するデータがすべて既に記憶されているので、ＺＦＳスナップショットが直ちに作成され得る。これらのＺＦＳスナップショットはまた、不変のデータがいずれもファイルシステムおよびそのスナップショットの間で共有されるので、空間効率が良くなり得る。

書込み可能なスナップショット（「クローン」）も作成可能であり、結果として、１セットのブロックを共有する２つの独立したファイルシステムが得られるだろう。クローンファイルシステムのうちのいずれかに変更が加えられると、それらの変更を反映するように新しいデータブロックが作成され得る。如何に多くのクローンが存在するとしても、不変のブロックはいずれも共有され続ける。

ＺＦＳは、スループットを最大限にするようすべてのデバイスにわたって動的なストライピングを採用する。付加的なデバイスがｚｐｏｏｌに追加されると、それらを含むようにストライプ幅が自動的に広がる。このように、プールにおけるディスクがすべて用いられると、それらのディスクにわたって書込み負荷のバランスがとられる。

ＺＦＳは、最大１２８キロバイトまでの可変サイズのブロックを用いる。現在利用可能なコードは、いくつかの作業負荷が大きなブロックで十分に動作し得ない場合に用いられる最大のブロックサイズをアドミニストレータが調整することを可能にする。

データ圧縮が可能であれば、可変ブロックサイズが用いられる。ブロックをより小さなブロックサイズに適合させるよう圧縮することができる場合、ディスク上でより小さなサイズを用いて、使用されるストレージを減らし、Ｉ／Ｏスループットを改善させる（但し、圧縮動作および復元動作のためにＣＰＵ使用量が増えるという犠牲を払うこととなる）。

ＺＦＳにおいては、ストレージプール内でのファイルシステム操作が、従来のファイルシステム内での容量操作ほど複雑ではない可能性がある。たとえば、ＺＦＳファイルシステムを作成またはサイズ変更するのに必要な時間および労力は、他のいくつかのシステムにおける容量操作よりも、新しいディレクトリを作成する時間および労力により近くなる。

概要
データストレージシステムは、複数のサーバと、これらのサーバのうち１つのサーバ上で各々展開される複数の外部インターフェイスプロバイダと、これらのサーバのうちの１つのサーバ上で各々展開される複数のデータストレージコントローラとを含む。プロバイダの各々は、データアクセス要求を受信し、コントローラのうち要求を満たすことのできる１つのコントローラを識別し、識別されたコントローラに要求を転送するよう構成される。システムはさらに、サーバから独立した複数のデータストレージモジュールを含む。プロバイダ、コントローラおよびモジュールは互いと通信する。コントローラの各々は、モジュールのうち少なくとも１つのモジュールにおけるデータ内容の一部を排他的に管理し、少なくとも１つのモジュールにおけるデータ内容の当該一部にアクセスすることによって、プロバイダから受信したデータアクセス要求を満たす。

データアクセス要求を処理する方法は、サーバ上で展開された外部インターフェイスプロバイダにおいて、データアクセス要求を受信するステップと、別のサーバ上で展開され要求を満たすことのできるデータストレージコントローラを識別するステップと、識別されたコントローラに要求を転送するステップとを含む。識別されたコントローラは、サーバから独立した少なくとも１つのデータストレージモジュールにおけるデータ内容の一部を排他的に管理する。当該方法はさらに、識別されたコントローラにおいて、転送された要求を受信するステップと、受信した要求に応答して、少なくとも１つのモジュールにおけるデータ内容の当該一部にアクセスして要求を満たすステップとを含む。

データストレージシステムは、複数のサーバと、これらのサーバのうち１つのサーバ上で各々展開された複数の外部インターフェイスプロバイダと、これらのサーバのうち１つのサーバ上で各々展開された複数のデータストレージコントローラとを含む。プロバイダの各々は、データアクセス要求を受信し、コントローラのうち要求に対処することのできる１つのコントローラを識別し、識別されたコントローラに要求を配送するよう構成される。システムはさらに、サーバから独立した複数のデータストレージモジュールを含む。モジュールのうち少なくとも１つは、書込データアクセス要求に含まれるデータをバッファして、データの不揮発性ストレージを提供するよう構成される。モジュールのうち少なくとも別の１つのモジュールは、上記少なくとも１つのモジュールよりも実質的に大きな容量を有する。プロバイダ、コントローラおよびモジュールは、リモートダイレクトメモリアクセスプロトコルを介してピアとして互いと通信する。コントローラの各々は、モジュールのうち少なくとも１つにおけるデータ内容の一部を排他的に管理し、プロバイダからデータアクセス要求を受信し、要求の受信に応答して少なくとも１つのモジュールにおけるデータ内容の当該一部にアクセスして要求に対処するよう構成される。

本発明に従った実施例が例示および開示されるが、このような開示は本発明を限定するものと解釈されるべきでない。さまざまな変更例および代替的な設計が本発明の範囲から逸脱することなく実施され得ることが予想される。

ストレージシステムの実施例を示すブロック図である。 ストレージシステムの別の実施例におけるデータフローを示すブロック図である。 グローバル管理システムの実施例におけるデータフローを示すブロック図である。

詳細な説明
ストレージアレイの性能は、磁気ディスクドライブの機械的待ち時間、半導体メモリのコストおよび揮発性、ならびに、性能、容量および相互接続のスケーリングに本質的に制限された集中化されたアーキテクチャを含むいくつかの要因によって制限される可能性がある。

不揮発性半導体メモリの技術、たとえばＮＡＮＤフラッシュは、性能および電力がビット毎のロー容量およびコストに優先される用途では磁気ディスクに取って代わられる可能性がある。この技術の既存の実現例は、磁気ドライブと同じコマンドセット、同じ通信プロトコル、およびしばしば同じ物理的寸法を用いることによって、磁気ディスクの実現例を模倣してきた。しかしながら、この明細書中に開示されるいくつかの実施例が得られる前提として挙げられることは、フラッシュ技術の利点、たとえば、機械的待ち時間がないこと、並行アクセスや、その不利点の軽減、たとえば、書込み前の消去、書込みサイクルの消耗の制限などが、磁気ディスク用に設計された分割および相互接続方式では達成され得ないことである。

既存の高性能のストレージプラットフォームは、集中化され共有された制御および半導体キャッシュに依拠する。この設計上の選択により、磁気ディスクの待ち時間が軽減され、それらのアーキテクチャの規定時に低い帯域幅の相互接続技術が利用可能となる。しかしながら、この設計上の選択により、結果として、エントリレベルシステムのコストと、達成され得る最大サイズおよび性能との間に妥協が生じる可能性がある。

高性能コンピュータおよび好適なファイルシステム技術のコンテキスト内におけるＮＡＮＤフラッシュおよび現代の低レイテンシ／高帯域の相互接続規格を用いることにより、この明細書中に開示されるいくつかの実施例は、１秒当たり業界最高レベルの小ブロック入出力操作（ＩＯＰＳ）、ストレージシステム毎の総ＩＯＰＳ、ＩＯＰＳ毎のコスト、ＩＯＰＳ毎の床面積、およびＩＯＰＳ毎の電力についての可能性を有し得る。

多くのトランザクション処理およびデータベースシステムは、極めて高速で、小ブロックのランダムなデータアクセス要求を生成する。これらのアプリケーションを実行するプロセッサの半導体技術が改善するのに従って、この速度は高くなる。ディスク容量および瞬間的なデータレートが増大し続ける。しかしながら、機械的探索および回転待ち時間の遅延は比較的一定のままであるため、ディスクＩＯＰＳの数の増加が緩やかになる。これにより、さらにより大きくより高価なディスクシステムを採用する必要が生じる可能性がある。しかしながら、ディスクドライブで達成できるよりも高いアクセス密度を提供するシステムは、適切な代替例となり得る。フラッシュメモリでは、ディスクの場合よりも、ストレージのＧＢ毎にサポートされるＩ／Ｏレートがより高くなる（または、アクセス密度がより高くなる）。フラッシュメモリではまた、ＲＡＭ技術の場合よりも、ストレージのＧＢ毎のコストがより低くなる可能性がある。この明細書中に開示されるいくつかの実施例は、これらの属性を利用する可能性があり、このため、所望される企業クラスの信頼性、利用可能性およびサービス保守性を提供するスケーラブルでコスト効率の良いストレージシステムを提供し得る。

従来のディスクドライブは、フラッシュメモリ技術を活用するためにソリッドステートディスク（ＳＳＤ：Solid-State Disks）と置換えられる可能性がある。これにより、Ｉ／Ｏレートが改善される可能性がある。しかしながら、これらの高速ＳＳＤは、現在ではディスクドライブの低いＩ／Ｏレートによって隠されているシステムの障害を晒す可能性がある。コントローラにおけるディスクコマンドプロトコルスタックのオーバーヘッドおよびＳＳＤにおけるディスクコマンド／状態処理時間は、小ブロック転送のためのデータ転送時間の発展を妨げる可能性がある。ディスクコマンドプロトコルはまた、フラッシュコントローラからデータ使用情報を隠し、制御部から消耗および故障情報を隠す可能性がある。

ディスクアクセスハードウェアおよびディスクドライブの相互接続は、コントローラのキャッシュ付近で、ディスクコントローラ内に位置するフラッシュメモリハードウェアと置換えられてもよい。高性能設計では、コントローラ内にフラッシュメモリを置く可能性がある。これは、フラッシュストレージの量を制限する可能性がある。フラッシュメモリの位置にかかわらず、従来のディスク管理プロセスは、フラッシュメモリの固有の要件に対処するようには見えない。ホストディスクアドレスが実際の「ディスクドライブ」（フラッシュストレージ）に静的にマッピングされると、ホストの書込みアクセスパターンにおけるホットスポットが、関連するフラッシュストレージの早すぎる消耗を招く可能性がある。フラッシュストレージへのわずかなランダム書込みにより、フラッシュブロック全体を空けるように、フラッシュコントローラが強制的にデータのページを周囲に移動させ得る。これにより、消去可能なフラッシュメモリの最小部分が得られる。これは性能に影響を及ぼし、耐用年数を低減させる可能性がある。

この明細書中に開示されるいくつかの実施例は、現在のディスクベースのアーキテクチャのシステム障害のうち少なくともいくつかを回避し、基礎をなすフラッシュ技術の限界に対処する性能および価値を有するスケーラブルなストレージシステムをもたらし得る。これらの実施例は以下を含み得る。

（ｉ）複数の独立したＺＦＳインスタンス。その各々は容量全体のうち一部を管理することに関与し得る。ＺＦＳインスタンスは、ホストインターフェイスポートをも含むサーバのプールにわたって広がり得る。

（ｉｉ）受信ポートから、要求されるブロックに関与するＺＦＳインスタンスへの各Ｉ／Ｏ要求のリダイレクション。一例においては、これは、１つのＩ／Ｏサーバ上のホストポートから別のＩ／Ｏサーバ上のＺＦＳインスタンスへのリダイレクションである。このリダイレクションステージは、いずれのポートからも容量のいずれの部分に到達することを可能にし得る。次いで、ＺＦＳインスタンスは、フラッシュおよび／または不揮発性ＲＡＭ（ＮＶＲＡＭ）に対して必要な直接トランザクションを発行して要求を完了し得る。次いで、確認応答またはデータが発信元ポートを介してホストに転送し返され得る。

（ｉｉｉ）たとえば、フロントエンドポート、ＺＦＳインスタンス、ＮＶＲＡＭおよびフラッシュをともに繋ぎ得る低レイテンシのメモリマップドネットワーク。このネットワークは、サーバ間ではＩｎｆｉｎｉＢａｎｄで、そしてサーバとストレージユニットとの間では、Ｉ／Ｏサーバおよびストレージユニット内のＰＣＩ Ｅｘｐｒｅｓｓで実現され得る。サーバとストレージユニットとはピアとして通信し得る。リダイレクショントラフィックおよびＺＦＳ／メモリトラフィックはともに同じ構成を用いてもよい。

（ｉｖ）１つ以上のストレージユニットが、たとえば、フラッシュおよびＮＶＲＡＭをともに含み得る。これらのストレージユニットは、メモリカード、電源、冷却および相互接続のホットスワッピングおよび内部冗長性との高い可用性が得られるよう設計され得る。ＩｎｆｉｎｉＢａｎｄ外部相互接続は、２つのコンセントレータボードによって２つの独立したＰＣＩ Ｅｘｐｒｅｓｓツリーに変換され得る。システムは、こうして、フラッシュだけでなくＮＶＲＡＭにも高速でアクセスし得る。ＲＡＭは、電力の損失時に専用のフラッシュにバックアップすることによって不揮発性にされ得る。フラッシュカードとＮＶＲＡＭカードとを組合せるよう構成することができ、ともに、同じコネクタおよびボードプロファイルを用い得る。

（ｖ）グローバルフラッシュのウェアレベリング、構成変更、および障害回復のために、容量がＺＦＳインスタンス間で再び割当てられなければならない場合に介入する擬似静的な「ロータッチ（low touch）」アプローチでストレージシステムの動作を監視し得るグローバル管理機能（データストレージシステムマネージャ）。

個々のＺＦＳインスタンス間で容量を分割する「分割および征服（divide and conquer）」戦略は、性能、接続性および容量の高度なスケーラビリティを可能にし得る。より多くのサーバを水平に追加し、ＺＦＳインスタンス毎により少ない容量および／またはサーバ毎により少ないＺＦＳインスタンスを割当てることにより、付加的な性能が実現され得る。性能はまた、より高速のサーバを選択することによって垂直に基準化され得る。ホストポートは、サーバに利用可能なスロットを満たし、次いで付加的なサーバを追加することによって追加され得る。付加的なストレージユニットを追加し、新しい容量をＺＦＳインスタンスに割当てることによって付加的な容量が実現され得る。

ここで、図１を参照すると、ストレージシステム１０は、複数のＩ／Ｏサーバ１２ｎ（１２ａ、１２ｂなど）、たとえばブレードまたはスタンドアロンのサーバ、複数のスイッチユニット１４ｎ（１４ａ、１４ｂなど）、たとえばＩｎｆｉｎｉＢａｎｄの拡張可能なスイッチユニット、および、１つ以上のストレージユニット１６ｎ（１６ａ、１６ｂなど）を含み得る。他の好適な構成も実現可能である。外部インターフェイスプロバイダ１８ｎ（１８ａ、１８ｂなど）、データストレージコントローラ２０ｎ（２０ａ、２０ｂなど）およびグローバル管理システム（データストレージシステムマネージャ）２１ｎ（２１ａ、２１ｂなど）がサーバ１２ｎの各々上で展開され得る（プロバイダ１８ｎおよびコントローラ２０ｎは、当然、ハードウェアおよび／またはソフトウェアにおいて実現され得る）。

たとえば、図１のストレージユニット１６ｎは、たとえばＰＣＩ Ｅｘｐｒｅｓｓを介してコンセントレータボード２６ｎ（２６ａ、２６ｂ）に接続された複数のフラッシュボード２２ｎ（２２ａ、２２ｂなど）およびＮＶＲＡＭ２４ｎ（２４ａ、２４ｂ）を含み得る。ストレージユニット１６ｎの各々は、それ自体の内部冗長電源および冷却システムを備えた一体型のラックマウント式ユニットであってもよい。メモリボード、コンセントレータボード、電源および冷却などの能動部品はホットスワップ可能であり得る。

図１の実施例においては、プロバイダ１８ｎ、コントローラ２０ｎおよびボード２２ｎ、２４ｎは、スイッチユニット１４ｎを介して伝達されるリモートデイレクトメモリアクセス（ＲＤＭＡ）プロトコルを介してピアとして通信し得る。Ｉ／Ｏサーバ、たとえばＩ／Ｏサーバ１２ａ、はこのＲＤＭＡプロトコルを用いてボード２２ｎ、２４ｎと通信し得る。加えて、Ｉ／Ｏサーバ１２ｎの各々は、ＲＤＭＡプロトコルを用いて他のＩ／Ｏサーバ１２ｎのすべてと通信し得る。しかしながら、如何なる好適な通信方式が用いられてもよい。

プロバイダ１８ｎは、データアクセス要求を受信し（読取るかまたは書込み）、たとえばマッピングにより（異なるサーバ上で展開され得る）要求を処理することのできるコントローラ２０ｘを識別し、識別されたコントローラ２０ｘに要求を配送することができる。

コントローラ２０ｎは各々、ボード２２ｎ、２４ｎのうち少なくとも１つにおけるデータ内容の一部を排他的に管理し、それらのデータ内容にアクセスすることによってプロバイダ１８ｎから受信したデータアクセス要求を満たし得る。

ここで、同様の参照番号を有する要素が図１の記載と同様である図２を参照すると、外部インターフェイスプロバイダ１１８ａはホストからデータアクセス要求を受信し得る。プロバイダ１１８ａは、マッピングなどを介して、要求を満たすことのできる（この例においては、サーバ１１２ｂ上で展開される）コントローラ１２０ｘを識別し得る。次いで、プロバイダ１１８ａは、識別されたコントローラ１２０ｂに対して要求をリダイレクトし得る。識別されたコントローラ１２０ｂは、リダイレクトされた要求を受信し、次いで、これに応答して、要求を満たし得るボード１２２ｎ、１２４ｎのいずれかにおけるデータにアクセスし得る。（データストレージモジュール用のフラッシュメモリの使用を詳細に説明してきたが、磁気ディスクを含む他のメモリ技術が用いられてもよい。）
いくつかの実施例においては、以下のとおりである。

（ｉ）２つ以上のサーバがフォールトトレランスを与え得る。１つのサーバが故障した場合、別のサーバが、故障したサーバによって行なわれていた作業を引継ぎ得る。同様に、２つ以上のデータストレージモジュールがフォールトトレランスを与え得る。

（ｉｉ）ＮＶＲＡＭボードは、フラッシュメモリボードよりも高速（より低いアクセスレイテンシ）でデータにアクセスし得るが、容量がより低くなる（このため、ストレージのビット毎のコストが高くなる）という犠牲が生じる。

（ｉｉｉ）サーバは、以下のサービスのうち１つ以上を提供し得る。ホストインターフェイス接続、適切なサーバへのデータアクセス要求の配送、データアクセス要求の処理、１セットのデータストレージモジュールおよび／または不揮発性メモリカードに記憶されたデータの管理、個々のサーバに対するデータおよび記憶空間の割当ての管理、グローバルウェアレベリングのための１つのサーバから別のサーバへのデータの移行、作業負荷のバランスのより適切な均衡化、または、システム構成変更、構成要素の消耗もしくは構成要素の故障および交換への対処。

（ｉｖ）サーバおよびストレージ（たとえば、データストレージモジュールおよび／または不揮発性メモリカード）は、サーバ間、サーバとストレージとの間、および／またはストレージ間での通信を可能にする相互接続構造を介して互いと通信し得る。

（ｖ）データの特定のブロックについてのすべてのＩ／Ｏアクセス要求を、そのデータのブロックの記憶に関与するサーバに配送するプロセスは、各々のホストＩ／Ｏ要求に関してサーバ同士の同期を必要とすることなく、すべてのホストインターフェイスにわたって記憶されたデータについての一貫したビューを提供し得る。

（ｖｉ）データストレージモジュールインターフェイスは別個のセットに分割されてもよく、各々のセットが唯一のサーバによって用いられ得る。このようにインターフェイスを分割することにより、２つ以上のサーバが単一のインターフェイスを共有する必要がなくなり、これらのサーバが単一のインターフェイスを使用する場合の調整が不要になり得る。単一のデータストレージモジュールで１つのインターフェイスまたは複数のインターフェイスが提供され得る。

（ｖｉｉ）各々の不揮発性メモリカードにおけるデータストレージは別個の領域に細分されてもよく、単一のサーバが１つの領域を排他的に使用し得る。これにより、複数のサーバが、不揮発性メモリカードによって提供される記憶空間を使用する際の調整を行なう必要なしに、単一の不揮発性メモリカード内にデータを記憶することが可能となり得る。

（ｖｉｉｉ）データストレージモジュールおよび／または不揮発性メモリカードに記憶されたデータを管理するプロセスは、データストレージモジュールに書込まれる更新されたデータを再位置決めし、各々のデータブロックのうち直前に書込まれたインスタンスの位置を識別するマッピング情報を維持するステップを含む。このプロセスは、各々のデータストレージモジュール内の記憶空間にわたって書込み動作を分散させ、複数のデータストレージモジュールにわたって書込み動作を分散させ得る。書込み動作をこのように分散させることにより、ウェアレベリングが提供され得る。このウェアレベリングは、消去され繰り返しプログラムされた後にデータストレージセルが消耗してしまうフラッシュメモリデバイスにとっては重要であり得る。

（ｉｘ）相互接続構造は、ディスクコマンドプロトコルではなく、メモリブロック転送プロトコル、たとえば、ＩｎｆｉｎｉＢａｎｄおよび／またはＰＣＩ Ｅｘｐｒｅｓｓを採用し得る。これは、サーバおよび不揮発性メモリカードの両方におけるディスクコマンドプロトコルスタックのオーバーヘッドを排除するので、不揮発性メモリカードへのアクセスには有益であり得る。データストレージモジュールはＲＤＭＡプロトコルを用いて、メモリブロック転送プロトコル相互接続を効率的に活用し、かつ、記憶媒体のニーズに最適に適合させるためにデータ転送動作をスケジューリングする柔軟性をデータストレージモジュールに与え得る。

フラッシュベースのストレージは、ディスクの機械的遅延をなくし、かつ、多数のフラッシュチップを同時にアクティブに維持することによって、高いアクセス密度の必要性に対処し得る。これにより、ディスクと比べて、ストレージのＧＢ毎に劇的により高いＩ／Ｏレートが得られる可能性がある。低オーバーヘッドのメモリアクセスプロトコルを用いて低レイテンシの相互接続構造を介してフラッシュストレージにアクセスし、フラッシュストレージユニット毎に複数のフラッシュコントローラを提供することにより、アクセスされるフラッシュチップの数を最大にして、高容量ＳＳＤよりもはるかに高いアクセス密度を平行にもたらし得る。

共用リソースの使用を調整することにより、Ｉ／Ｏ要求を実行するプロセスにオーバーヘッドが追加され得る。ディスクアクセス時間に対して相対的に小さくなり得るオーバーヘッドは、フラッシュアクセス時間と比べて極めて重要になり得る。中央のキャッシュ、さまざまなデータ経路およびディスクインターフェイスへのアクセスを共有するシステムにおいては、これらおよび他の共用リソースの使用を調整するには、ロッキングおよび連続した実行が必要になる可能性がある。これにより、コントローラにおける重要なタイミング経路に遅延が追加される可能性があり、これらの遅延は、システムのサイズが増大し、リソース利用のレベルが高まるのに応じて大きくなる可能性がある。重要なタイミング経路からこれらの調整遅延をなくすために、この明細書中に開示されるいくつかのコントローラアーキテクチャは、ＺＦＳの独立したインスタンスを実行する複数の独立したサーバを用い得る。システムのストレージはこれらのＺＦＳインスタンスにわたって広がっているため、各々のＺＦＳインスタンスは、フラッシュストレージのその割当てられた部分およびそのキャッシュの管理について単独で関与することとなる。次いで、サーバは、各々の（ホスト）アクセス要求をＺＦＳの適切なインスタンスに配送し、結果として得られるデータおよび完了状態をこのＺＦＳインスタンスから発信元ホストポートに配送し返し得る。このようなＺＦＳインスタンスに対するストレージおよび作業負荷の割当ては、たとえば何百万ものＩ／Ｏ動作の期間にわたって変化しないままであるかもしれない。時折、サーバ上で実行されるグローバル管理サービスは、たとえばウェアレベリングまたは負荷バランシングのために、必要に応じて、１つのＺＦＳインスタンスから別のＺＦＳインスタンスにデータおよび作業負荷を移動させてもよい。

サーバは、フォールトトレラントであり停電中にデータを保存するストレージに対して、小ブロックの書込みトラフィックを直ちにコミットすることができなければならないかもしれない。フラッシュストレージユニットにおけるＮＶＲＡＭモジュールは、サーバにとってワード書込み可能なメモリであるように見える可能性がある。これらのＮＶＲＡＭモジュールへのミラーリング書込みにより、小ブロックの書込みトランザクションを行なう最も高速な手段が提供され、これにより、コントローラが、書込み動作が終了したとホストに報告することができるようになる。

多くのプログラム/消去サイクル後、フラッシュメモリセルが消耗して、セルに記憶されたデータを保持する能力を失う可能性がある。フラッシュメモリの頻繁な書込み部分のせいで起こる早すぎる消耗を防ぐために、ストレージシステムの実施例ではウェアレベリング戦略を採用してもよい。これは、フラッシュメモリ位置に対するホストディスクアドレスの動的なマッピングを必要とする可能性がある。（たとえば、ディスクアドレスをフラッシュメモリページに変換する単一の大きなマップが十分にスケーリングしていない可能性がある。）これらの実施例は、たとえば、フラッシュ管理階層におけるさまざまなレベルで作用する３つのウェアレベリング戦略を採用してもよい。一例として、各々のＺＦＳインスタンスは、完全なＲＡＩＤストライプを書込むことができるようにＣＯＷを用いて、そのＺＦＳインスタンスが所有するフラッシュストレージの領域にわたって自動的に書込みトラフィックのバランスをとってもよい。フラッシュチップと同様に、各々のフラッシュメモリコントローラは、それ自体の小さなマッピングテーブルを管理しながら、それが制御するフラッシュチップのためのウェアレベリングを実行してもよい。いくつかの実施例がＺＦＳのインスタンスによって処理される書込み動作における長期的な不均衡を可能にした場合、最もアクティブなＺＦＳインスタンスが所有するフラッシュストレージがあまりにも早く消耗する可能性がある。これを防ぐために、システムのグローバル管理サービスは、書込まれたデータをＺＦＳの１つのインスタンスから別のインスタンスへと頻繁に移行させて、グローバルな書込みのバランスをとってもよい。複数の独立したＺＦＳインスタンスによって管理されるフラッシュストレージの別個のプールを用いる場合の性能およびスケーラビリティの利点は、データ移行時に時折起こるオーバーヘッドに勝っている可能性がある。

フラッシュメモリセルはソフトエラーを被る可能性がある。フラッシュチップは余分なセルをもたらす可能性があり、ここに、フラッシュコントローラが最も頻繁なエラー事例を改善するエラー訂正コードを記憶し得る。各々のＺＦＳインスタンスは、複数のフラッシュストレージボードにわたってそのデータを広げてもよく、これにより、訂正不可能なエラー、フラッシュチップの故障またはフラッシュストレージボード全体の交換のせいで失われるデータを回復させることができるようになる。ＺＦＳの多くのインスタンスを平行に実行させることを可能にするために、各々のＺＦＳインスタンスは、いずれかの１つのフラッシュストレージボードにおけるストレージの一部だけにアクセスし、この一部だけを管理する役割を果たし得る。これにより、ＺＦＳインスタンスがそれらのアクセスを調整する時間を費やす必要がなくなるように、各フラッシュストレージボードが複数の独立したアクセス制御を行なうことが必要になる可能性がある。

上述のとおり、データストレージシステムのいくつかの実施例に付随するホストによって生じる書込み動作は、ストレージシステムが保持するすべてのデータにわたって不均一に分散される可能性がある。ＺＦＳの１つのインスタンスに割当てられたデータのうちいくつかの部分は、他のＺＦＳインスタンスによって管理されるデータの残りの部分よりもはるかに頻繁に書込まれる可能性がある。これにより、そのＺＦＳインスタンスによって管理されているフラッシュストレージが時期尚早に消耗する可能性がある。

ウェアレベリングは、一般にＳＳＤ内で実行され得る。ＳＳＤを採用するデータストレージシステムにおいては、このウェアレベリングは、特にストレージシステムがＳＳＤアドレスへのホストデータアドレスの静的なマッピングを用いる場合、またはＳＳＤが独立したファイルシステムによって管理される場合、ＳＳＤ間の書込み動作における不均衡に対処し得ない。このため、大規模なストレージシステム内において、このシステム内の他のＳＳＤよりもかなり前に、いくつかのＳＳＤが消耗してしまう可能性がある。

Ｌｕｓｔｒｅなどの分散されたデータストレージシステムにおいては、データストレージシステム内におけるコンピュータに対するホストアドレス空間の一部の割当てが静的に行われる可能性がある。データにアクセスするホストの能力を阻害することなく、１つのコンピュータから別のコンピュータにデータを移動させるための準備はなされていない。この明細書中に開示されるいくつかの実施例においては、グローバル管理システムは、使用情報、たとえば、データストレージ消耗率、作業負荷分散の歪み（負荷分散のバランスが取られる程度、歪みが小さければ小さいほど、負荷バランシングがより均一になり、歪みが大きければ大きいほど、負荷バランシングが不均一になる、など）、書込み動作、および残りの耐用年数などを、データストレージシステム内の独立したファイルシステムから集め得る。次いで、この情報を用いて、データを１つのファイルシステムから別のファイルシステムにいつ移動させるかと、どのデータを移動させるかとについて決定し得る。さらに、この情報を用いてデータストレージシステムの構成を動的に調整して、作業負荷分散のデータストレージ消耗率および歪みを制御し得る。

グローバル管理システムの実施例は、たとえば、システム構成が最初に規定されるときにデータの最初の配置を決定し得る。次いで、ファイルシステムおよび／もしくはストレージユニットに新しいデータストレージを割当てることにより、ファイルシステムおよび／もしくはストレージユニットから未使用のデータストレージを除去することにより、または、１つのファイルシステムおよび／もしくはストレージユニットから別のファイルシステムおよび／もしくはストレージユニットに（もしくはストレージユニット内に）データを移動させることにより、ストレージシステム構成要素の追加もしくは除去に起因するかまたは構成要素の故障および交換に起因する構成の変化に対応し得る。グローバル管理システムのいくつかの実施例は、データストレージシステム内のサーバ／コンピュータのうち１つ以上の上で実行させるソフトウェアおよび／またはハードウェアとして実現されてもよい。

グローバル管理システムの実施例は、以下の動作のうち１つ以上を実行し得る。すなわち、ストレージシステムのホストアクセスアドレス空間を区画に分割し、個々のファイルシステムインスタンスにこれら区画を割当てる；システム内のデータストレージ空間を区画に分割し、これら区画を個々のファイルシステムに割当てて、優れたシステム性能をもたらし、かつ、データストレージデバイスの故障または（データストレージシステム内またはデータストレージシステム外の）他の故障に起因する性能への影響およびデータ損失のリスクを制限する；データアクセス要求が適切なファイルシステムインスタンスに配送され得るように、システムのアドレス空間のどの部分が各ファイルシステムインスタンスに割当てられるかを記述するマップを分散させる；システム内のデータストレージ空間のうち、そのファイルシステムインスタンスが使用することのできる部分について各ファイルシステムに通知する；ウェアレベリングを改善するかまたは作業負荷のバランスを取って障害を抑制するために、１つのファイルシステムインスタンスから別のファイルシステムインスタンスに移動させるべきデータを識別する；あるファイルシステムから別のファイルシステムに移動させるデータのマッピングを記述するために、分散されたマップを更新する；システム構成要素の追加もしくは除去（システムアップグレード）に起因するかまたは構成要素の故障および交換に起因するデータストレージシステムの構成変更についての通知を受信する；１つのファイルシステムから別のファイルシステムに移動させるべきデータと、ファイルシステムインスタンスへの物理的なストレージの割当てに対する適切な変更とを識別する；ファイルシステムインスタンスに命令して、データを移動させ、かつ構成変更に適応するよう物理的なストレージ割当てを調整し、分散されたマップを適宜更新する；故障したか、その耐用年数の末期に達したか、または耐用年数の末期に近づいているストレージ構成要素を交換するために、いつストレージシステムを保守点検しなければならないかを決定する；他の理由で機械の保守点検が必要な場合に、耐用年数の末期に近づいているストレージ構成要素について報告して、そのサービスコール中にこれらのストレージ構成要素を交換して、以降のサービスコールにかかるコストを排除できるようにする。

ここで図１および図３を参照すると、グローバル管理システム２１ａの実施例はデータコレクタ２８ａ、ポリシーエンジン３０ａおよび構成マネージャ３２ａを含み得る。データコレクタ２８ａ、ポリシーエンジン３０ａおよび構成マネージャ３２ａは、ハードウェア／ファームウェア／ソフトウェア／など、またはこれらのいずれか組合せで実現され得る。図１の他のグローバル管理システム２１ｂなどは、グローバル管理システム２１ａと同様に構成されてもよい。しかしながら、いくつかの実施例においては、これらの他のグローバル管理システム２１ｂなどのポリシーエンジン３０ｂなどは、以下に説明するように停止していてもよい。

それぞれのデータコレクタ２８ｎの各々は、公知の方法で、それらが展開されているサーバ１２ｎの動作に関連付けられるリソース利用情報を集める。データコレクタ２８ａは、たとえば、データストレージ消耗率、作業負荷分散の歪み、書込み動作、残りの耐用年数などを集め得る。このリソース利用情報は、ポリシーエンジン３０ｎのうちの１つに転送（または１つによって要求）され得る。

図１および図３の実施例においては、ポリシーエンジン３０ａは稼動しており、他のポリシーエンジン３０ｎ（たとえば３０ｂなど）が停止している間に主ポリシーエンジンとしての役割を果たし得る。結果として、データコレクタ２８ａによって集められた利用情報が、ポリシーエンジン３０ａに転送される。データコレクタ２８ｂによって集められた利用情報も、ポリシーエンジン３０ａなどに転送される。この方式により、単一のポリシーエンジン３０ａがデータストレージシステム１０のために構成変更を開始することが可能となる。単一の主ポリシーエンジン３０ａを選択し、そして、選択された主ポリシーエンジン３０ａと通信するであろうデータコレクタ２８ｎにこのような選択の結果を分散させるために公知の技術が用いられてもよい。他の実施例においては、データコレクタ２８ｂによって集められた利用情報が、データコレクタ２８ａに転送され、次いで、主ポリシーエンジン３０ａに転送され得る。他のシナリオも実現可能である。

ポリシーエンジン３０ａは、上述のとおり、いくつかの消耗率および作業負荷の分散ポリシーを特定し得る。例示的なポリシーは、フラッシュボード２２ａの除去を可能にするようにフラッシュボード２２ｎのうちの１つ（たとえばフラッシュボード２２ａ）からフラッシュボード２２ｎのうちの別の１つ以上（たとえば、フラッシュボード２２ｂおよび２２ｃ、別のストレージユニットにおけるフラッシュボードなど）にデータを移行することを特定し得る。別の例示的なポリシーは、作業負荷分散の歪み（または均一性）に依存するフラッシュボード２２ｎについての最大消耗率を特定し得る。最大消耗率は、作業負荷分散の歪みが増加／減少するのに応じて上昇／低下し得る。しかしながら、別の例示的なポリシーは、フラッシュボード２２ｎの消耗率に依存する作業負荷分散の最大の歪みを特定し得る。作業負荷分散の最大の歪みは、フラッシュボード２２ｎの消耗率が上昇／低下するのに応じて増大／減少し得る。これらの例示的なポリシー（たとえば、ストレージユニットなどに向けられるポリシー）は、グローバル管理システム２１ａが消耗率を犠牲にして、作業負荷分散の均一性を向上させるか、または、作業負荷分散の均一性を犠牲にして消耗率を改善することを可能にし得る。たとえば、予想される作業負荷および消耗率分散で行なわれる長期間にわたる動作がフラッシュボード２２ｎの早すぎる消耗をもたらし得る程度にまで作業負荷分散が概して均一であり、フラッシュボード２２ｎにわたる消耗率分散が不均一である場合、グローバル管理システム２１ａは、作業負荷分散の均一性を低下させて消耗率などを向上させるように構成の変更を開始し得る。逆に、消耗率分散が概して均一であり、作業負荷分散がかなり不均一である場合、グローバル管理システム２１ａは、作業負荷分散の均一性を向上させるために、消耗率をより不均一に分散させることを可能にし得る。

いくつかの実施例においては、ポリシーエンジン３０ａは、データコレクタ２８ｎによって集められたデータにおける履歴傾向を追跡し、そして、ポリシーエンジン３０ａが予想し構成の変更に起因することとなるデータストレージシステム１０の動作の改善規模によって正当化された場合に構成の変更を開始し得る。ポリシーエンジン３０ａは、一方では、所望の消耗率または作業負荷分散を達成し、他方では、構成の変更を実行することに起因するデータストレージシステム１０の動作に及ぼす影響を最小限にするという矛盾した目標のバランスをとり得る。

データコレクタ２８ｎから集められた情報の評価、およびデータストレージシステム１０の現在の構成に基づき、実施されているポリシーに鑑みて、ポリシーエンジン３０ａが、データストレージシステム１０についての構成変更を開始し得る。構成変更がサーバ１２ｎのうちの１つ、たとえば１２ａ、によって管理されるデータストレージシステム１０の部分に適用される／影響を及ぼすなどの場合、構成変更要求が、対応する構成マネージャ３２ａに向けられてもよい。

構成マネージャ３２ｎは、データストレージシステム１０内の消耗率および作業負荷分散の両方を制御するように、ポリシーエンジン３０ａによって開始された構成変更を実現し得る。たとえば、構成変更は、フラッシュカード２２ａの消耗率を低下させるようにフラッシュカード２２ａからフラッシュカード２２ｂおよび２２ｃに頻繁に書込まれた何らかのデータの移動を特定し得る。

本発明の実施例を例示および記載してきたが、これらの実施例は本発明の実現可能なすべての形態を例示および記載するよう意図されたものではない。たとえば、この明細書中に記載されるいくつかの実施例をＺＦＳの文脈内で論じてきたが、ログ構造のファイルシステム、動的にマップされたデータ管理システムなどの他の実施例もさまざまな文脈において実現可能であり得る。明細書中で用いられる用語は限定ではなく説明のためのものであり、本発明の精神および範囲から逸脱することなくさまざまな変更が可能であることが理解される。

Claims (13)

1. データストレージシステムであって、
   複数のサーバと、
   サーバのうちの１つのサーバ上で各々展開された複数の外部インターフェイスプロバイダと、
   サーバのうちの１つのサーバ上で各々展開された複数のデータストレージコントローラとを含み、プロバイダの各々は、（ｉ）データアクセス要求を受信し、（ｉｉ）コントローラのうち要求を満たすことのできるコントローラを識別し、（ｉｉｉ）識別されたコントローラに要求を転送するよう構成され、前記データストレージシステムはさらに、
   サーバから独立した複数のデータストレージモジュールを含み、プロバイダ、コントローラおよびモジュールは互いと通信し、コントローラの各々は、（ｉ）モジュールのうち少なくとも１つにおけるデータ内容の一部を排他的に管理し、（ｉｉ）少なくとも１つのモジュールにおけるデータ内容の前記一部にアクセスすることによって、プロバイダから受信したデータアクセス要求を満たすよう構成される、データストレージシステム。
2. モジュールのうち少なくとも１つは、データの不揮発性ストレージを提供するために書込データアクセス要求に含まれるデータをバッファするよう構成される、請求項１に記載のシステム。
3. モジュールのうち少なくとも別の１つは、前記少なくとも１つのモジュールよりも実質的に大きい容量を有する、請求項２に記載のシステム。
4. プロバイダ、コントローラおよびモジュールはリモートダイレクトメモリアクセスプロトコルを介して互いと通信する、請求項１から３のいずれかに記載のシステム。
5. モジュールのうち少なくとも１つにおけるデータ内容の一部を排他的に管理することは、コピー・オン・ライトを実行することを含む、請求項１から４のいずれかに記載のシステム。
6. プロバイダ、コントローラおよびモジュールはピアとして互いと通信する、請求項１から５のいずれかに記載のシステム。
7. コントローラの各々はフォールトトレランスのためにデータ冗長性を与える、請求項１から６のいずれかに記載のシステム。
8. 少なくとも１つのモジュールにおけるデータ内容の前記一部にアクセスすることは、データアクセス要求において要求されるデータ内容を検索することを含む、請求項１から７のいずれかに記載のシステム。
9. 少なくとも１つのモジュールにおけるデータ内容の前記一部にアクセスすることは、データアクセス要求に含まれるデータを記憶することを含む、請求項１から８のいずれかに記載のシステム。
10. すべてのモジュールが不揮発性データストレージを提供する、請求項１から９のいずれかに記載のシステム。
11. データアクセス要求を処理する方法であって、
    サーバ上で展開された外部インターフェイスプロバイダにおいて、
    データアクセス要求を受信するステップと、
    要求を満たすことのできる別のサーバ上で展開されたデータストレージコントローラを識別するステップとを含み、識別されたコントローラは、サーバから独立した少なくとも１つのデータストレージモジュールにおけるデータ内容の一部を排他的に管理し、前記方法はさらに、
    識別されたコントローラに要求を転送するステップと、
    識別されたコントローラにおいて、
    転送された要求を受信するステップと、
    受信された要求に応答して、少なくとも１つのモジュールにおけるデータ内容の前記一部にアクセスして要求を満たすステップとを含む、方法。
12. データの不揮発性ストレージを提供するために、少なくとも１つのモジュールにおける書込データアクセス要求に含まれるデータをバッファするステップをさらに含む、請求項１１に記載の方法。
13. サーバから独立した少なくとも１つのデータストレージモジュールにおけるデータ内容の一部を排他的に管理するステップは、コピー・オン・ライトを実行するステップを含む、請求項１１または１２に記載の方法。

Images