JP2024504171A - オペレーティングシステムベースのストレージ方法およびシステム - Google Patents

Abstract

利用されていない利用可能なＤＡＳを利用することで、信頼性の高いデータストレージ機能と、様々な条件や関心事に適応した柔軟性を提供することによって入手可能である、信頼性の高いデータストレージ機能及び様々な条件及び関心事に適応した柔軟性を提供できる、信頼性が高く、高速で、コスト効率が高く、包括的なソリューションを提供するために、利用されていない利用可能なハードウェアリソースを利用することを可能にする効率的なデータストレージシステム及び方法。前記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバ、データプレーン（ＤＰ）ネットワークを通してリモートリソース（複数可）にアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、及び各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、ターゲットサーバの記憶媒体の指定された部分がＤＰネットワークに公開されており、オーケストレータは、前記サーバの内部に組み込まれたオペレーティングシステムのストレージスタックコンポーネント（ＳＳ）及び標準ストレージスタック（ＳＳＳ）を調整することによって、記憶媒体の指定された部分を利用するように指定され、イニシエータサーバが、ＤＰネットワークを介してターゲットサーバと対話するように構成されるようにする。【選択図】図６

Description

本発明は、コンピュータデータの記憶方法およびシステムに関し、より詳細には、コンピュータデータ記憶管理効率およびハードウェアの冗長性を高めるための論理的なアーキテクチャの概念の使用および実装に関する。

現在のコンピューティングシステムは、ローカルであっても、リモートであっても、またはクラウドベース（コンテナパッケージ、プライベート／パブリック／マルチクラウドシステムなど）であっても、それらの適切な動作のためにこれまで以上に広範なデータストレージソリューションを必要とするため、データストレージとデータバックアップ機能の提供は重要な懸念事項である。通常、そのようなデータの提供と管理は、指定されたデータセンターによって行われ、提供され、従来、使用中または使用予定のデータストレージの提供は、物理的なデータ記憶コンポーネント、つまりハイブリッドハードディスクドライブ（ＨＨＤ）、ソリッドステートドライブ（ＳＳＤ）などをスタックすることによって提供されている。

該データ記憶コンポーネントをスタックすることにより、「ストレージアレイ」（またはディスクアレイ）と呼ばれるものが作成され、ブロックベースのストレージ、ファイルベースのストレージ、オブジェクトストレージなどに使用される。ストレージアレイは、サーバにデータを記憶するのではなく、ローカル／中央制御システムによって制御される、大量のデータを記憶できる複数のドライブを集合で使用する。

従来、ストレージアレイ制御システムは、容量、スペースの割り当て、ボリュームの管理、スナップショット、エラーの識別と追跡、暗号化、圧縮などを追跡するために複数のストレージサービスを提供する。この種のサービスは、大量のコンピューティング容量、メタデータ、データストレージ、アクセラレータなどが必要である。したがって、そのようなサービスには広範なインフラストラクチャの指定、予算枠、およびリソースが必要である。

一般に、ストレージアレイはシステムサーバの動作性から分離されており、専用のハードウェアでシステムとアプリケーションの動作を実装するように構成されている。例えば、一般的なストレージアレイのハードウェアアーキテクチャには、サーバスタック、ストレージアレイスタック、メディアＩ／Ｏデバイスが含まれる場合がある。Ｉ／Ｏデバイスは、ストレージスタックを介してサーバと通信するように構成されている。

従来のストレージアレイによって提供されるサービスの１つは、システム障害の場合にデータを保護するために、複数のＨＤＤまたはＳＳＤの異なる場所に同じデータを保存する方法として、独立ディスクの冗長アレイ（ＲＡＩＤ）を提供することである。ＲＡＩＤレベルは様々で、全体的なパフォーマンスの向上とストレージ容量の増加を目的としている場合があるが、すべてが冗長性を提供することを目的としているわけではない。

ＲＡＩＤ構成は通常、ストライピング、ミラーリング、またはパリティの技術を使用して、複数の汎用コンピュータＨＤＤから大規模で信頼性の高いデータストアを作成する。例えば、ＲＡＩＤ５は、分散型パリティを備えたブロックレベルのストライピングからなる。単一のドライブに障害が発生した場合、データが失われないように、分散型パリティから後続の読み取りを計算できる。ＲＡＩＤ６は、別のパリティブロックを追加することでＲＡＩＤ５を拡張する。したがって、それはすべてのメンバーディスクに分散された２つのパリティブロックによるブロックレベルのストライピングを使用する。通常、ＲＡＩＤ５／６は、パリティの計算に関連するオーバーヘッドにより、書き込み動作のパフォーマンスにペナルティが課される。現在のＲＡＩＤ５／６は、ＲＡＩＤアレイごとに１つのコアでのみ実行される。すべてのパリティの計算は単一のコアによって実行される。マルチコアでＲＡＩＤを使用するには、同じストリップへの並列書き込みを防ぐのにＩ／Ｏごとにロックする必要があるため、パフォーマンスが大幅に低下する。高帯域幅の新しいＳＳＤドライブは、システムにある１つのコアがパリティの計算を実行し、フル活用されているため、現在のＲＡＩＤ５／６で使用するとき書き込みパフォーマンスが制限される。マルチコアプロセッサは、あたかもコンピュータが複数のプロセッサを備えているかのように、それぞれがプログラム命令を読み取って実行する、コアと呼ばれる２つ以上の別個の処理ユニットを備えたコンピュータプロセッサ集積回路であることに留意されたい。最新のサーバには、サーバごとに１００を超えるコアが含まれる場合がある。一方、ＲＡＩＤは一般に、データの冗長性、パフォーマンスの向上、またはその両方を目的として、複数の物理ディスクドライブコンポーネントを１つ以上の論理ユニットに結合するデータストレージ仮想化テクノロジーと呼ばれる。

ＲＡＩＤ１は、パリティまたはストライピングのないデータミラーリングからなる。ＲＡＩＤ１アーキテクチャでは、データは２つのドライブに同一に書き込まれるため、ドライブの「ミラーリングされたセット」が作成される。少なくとも１つのドライブが機能している限り、アレイは動作し続ける。

論理ボリュームマネージャ（ＬＶＭ）は、ボリュームのスナップショットの提供、つまり、特定の時点でのデータのコピーの作成を可能にする。

リモートレプリケーションは、データの保護または災害復旧を目的として、生産データを遠隔地にあるデバイスにコピーするプロセスである。

リモートレプリケーションは同期または非同期のいずれかであり得る。同期レプリケーションは、プライマリサイトとセカンダリサイトに同時にデータを書き込む。特徴として、非同期レプリケーションは、セカンダリサイトへのデータの書き込みが遅くなりながら遅延が発生する。非同期レプリケーションは相対的に長い距離でも動作するように設計されており、必要な帯域幅が少ないため、これは、多くの場合、災害復旧により適しているオプションとなる。ただし、非同期レプリケーションでは、ターゲットデバイスのデータがソースデータと同期していないため、システム停止時にデータが失われるリスクがある。最近のほとんどのエンタープライズデータストレージベンダーは、ハイエンドおよびミッドレンジのストレージアレイにレプリケーションソフトウェアを搭載している。共通のハードウェアの動作の共通性を可能にするために、データ管理へのアプローチとしてソフトウェアデファインドストレージ（ＳＤＳ）の実践が確立され、それにおいて、データストレージリソースが基礎となる物理ストレージハードウェアから抽象化され、それによって利用可能なハードウェアおよびデータストレージリソースの柔軟な活用を提供することが可能になる。

ＳＤＳはまた、当技術分野ではハイパーコンバージドインフラストラクチャ（ＨＣＩ）とも呼ばれ、通常は商用の既製のサーバで実行される。従来のインフラストラクチャとＨＣＩの主な違いは、ＨＣＩでは、ストレージエリアネットワークと基盤となるストレージ抽象化の両方が、ハードウェアにおいて物理的ではなく仮想的にソフトウェアで実装されることである。ストレージアレイとＳＤＳソリューションは通常、データストレージとそのトラフィックを管理および制御するための統合ストレージソフトウェアスタックを含む。

該統合ソフトウェアスタックは、データの保護（例えば、バックアップ、冗長性、リカバリなど）、高可用性、スペースの割り当て、データの削減、データのバックアップ、データのリカバリなどのストレージ保守サービスを提供する。実際には、統合ソフトウェアスタックは、その制御、管理、施行、および保守用に専用のストレージアレイリソースを必要とする。このようなリソースでは、ストレージスタックコード、制御プロトコル、ノード相互接続プロトコル、障害ドメイン、パフォーマンス、スタックモデル、およびクラスタ内のノード数などの問題に対処する必要がある。これらのサービスと要件は従来、ストレージアレイごとにローカルに提供されており、更新、管理、全体的な管理が必要である。

上で開示した統合ソフトウェアの構築と保守は、とりわけ、数多くのクライアントに（メディア側とサーバ側の両方で）様々なサービスを提供する必要があるため、非常にコストがかかる可能性がある。統合ソフトウェアはまた高い信頼性を備えているべきであり、コードは効率的である必要がある。それにもかかわらず、現在のストレージアレイは、信頼性、品質、パフォーマンスにおいて課題に直面する傾向がある。

一般的な中央ストレージアレイは多数のクライアントにサービスを提供するように構成されているため、たとえ大きな計算能力がそれに割り当てられるとしても、その能力は該多数のクライアント間で分割される。その中心性により、ストレージアレイまたはスタッククラスタで発生するエラーや誤動作は、システム全体のパフォーマンスに直ちに影響を与える。現在のコンピューティングシステムでは、データストレージ専用のストレージアレイやスタッククラスタの数は、サーバシステム専用のリソースに比べて大幅に少なく、利用可能性も低く、その結果、業界は、データストレージのサービスではなくサーバのサービスで遥かに多くの「実績」を獲得している（例えば、サーバ関連のコードがより頻繁にデバッグされ、より効率的になり、そのため、エラーが少なくなる傾向にある）。

さらに、このような統合ソフトウェアの保守は、技術の進歩（複数可）に合わせた継続的な維持と更新が必要である。したがって、統合ソフトウェアスタック動作の現在の品質とパフォーマンスが常に最適であるとは限らない。

ＬｉｎｕｘやＷｉｎｄｏｗｓ Ｓｅｒｖｅｒなどの最新のオペレーティングシステムは、堅牢な内部ストレージコンポーネントの集合［（直接接続ストレージ－（ＤＡＳ））］を含み、それは、設計要件のため、あるいはストレージアレイまたはデータスタッククラスタに起因する欠点のため、中央ストレージシステムが必要でない、または望ましくないときに、直接ローカルサービス（暗号化、圧縮、ＲＡＩＤなど）を可能にする。

ストレージコンポーネントはカーネル層に実装されており、即時アクセスが保証されるため、ＯＳおよび／またはアプリケーションの高いパフォーマンスが保証される。ＤＡＳは、ＤＡＳに記憶されているデータへのアクセスを直接妨げるサーバ通信障害の直接的な悪影響による、固有の欠点があるため、ほとんどの場合、重要ではないアプリケーションに限定される。したがって、原則として、企業は重要なアプリケーションにＤＡＳを使用しない。それにもかかわらず、現在の最新のサーバおよびオペレーティングシステムは、ＤＡＳ機能をサポートするために必要なサービスを組み込むように設計されている。

オペレーティングシステムの成熟度により、企業での使用を目的とした安定したコンポーネントが提供されるが、ＤＡＳの信頼性の制限により、ストレージアレイへの依存が依然として高い優先度の検討事項となっている。

該直接ローカルサービス（暗号化、圧縮、ＲＡＩＤなど）を容易にするためにＯＳサーバシステムに含まれる原コンポーネントは、現在、基本的なオペレーティングシステムＤＡＳのアプリケーションにのみ使用されている。それにも関わらず、サービスを可能にするこのようなコンポーネントの多くがＯＳサーバに存在するが、今日では、それらは従来のストレージアレイシステムで利用できるデータ管理および制御サービスの完全なスイートを可能にしていない。

ストレージアレイとＳＤＳソリューションは通常、統合ストレージソフトウェアスタックを使用して構築される。また、それらはコントローラ間のリモートリソースを接続するために独自のプロトコルを一般的に使用する。

ＬｉｎｕｘやＷｉｎｄｏｗｓ Ｓｅｒｖｅｒなどの最新のオペレーティングシステムは、堅牢なストレージコンポーネントの集合を含んでいる。ストレージコンポーネントは通常、カーネル層に実装されるため、高いパフォーマンスが得られる。

同じサーバ内でローカルオペレーティングシステムコンポーネントをスタックすることは一般に実現可能である。ただし、他のサーバ位置するリモートリソースをスタックすることは、現時点では不可能である。

ＲＡＩＤは、データの冗長性、パフォーマンスの向上、またはその両方を目的として、複数の物理ディスクドライブコンポーネントを１つ以上の論理ユニットに結合するデータストレージ仮想化テクノロジーである。

従来、ホットスペアは、データを含まない完全に機能するドライブであるＲＡＩＤ１、ＲＡＩＤ５、またはＲＡＩＤ６ボリュームグループのスタンバイドライブとして機能する。現在のストレージシステムでは、ボリュームグループのドライブに障害が発生すると、コントローラは障害が発生したドライブからホットスペアにデータを自動的に再構築する。

ストレージアレイのドライブに障害が発生した場合、物理的なスワップを必要とせずに、ホットスペアドライブが、障害が発生したドライブと自動的に置き換えられる。ドライブに障害が発生したときにホットスペアドライブが使用可能な場合、コントローラは冗長データを使用して、障害が発生したドライブからホットスペアドライブにデータを再構築する。

ボリュームスナップショットは、特定の時点でのボリュームの内容を表すために使用される。スナップショットは通常、データの保護のために作成されるが、それらはアプリケーションソフトウェアのテストやデータマイニングにも使用できる。ストレージスナップショットは、人的ミスやデータの破損により情報が失われた場合の災害復旧にも使用できる。

整合性グループは、特定のストレージアレイのベースボリュームの集合である。スナップショットイメージのソースであるこれらのベースボリュームは、通常、整合性グループのメンバーボリュームと呼ばれる。整合性グループの目的は、複数のボリュームの同時スナップショットイメージを取得し、それにより特定の時点でのボリュームの集合のコピーを取得することである。

ほとんどのミッドレンジおよびハイエンドのストレージアレイは、ストレージアレイ内のボリューム内にスナップショット整合性グループを作成する。

ローカルスナップショットの取得は、単一ボリュームのローカルスナップショットを取得できる論理ボリュームマネージャ（ＬＶＭ）を含むサーバオペレーティングシステムによって可能になる。分散型ストレージシステムでは、ボリュームが複数のサーバおよび複数のＬＶＭに分散されているため、通常、整合性グループの取得または作成は不可能またはサポートされていない。

サービス品質（ＱｏＳ）は、マルチテナントまたはエンタープライズインフラストラクチャでビジネスにとって重要なアプリケーションに対して一貫したプライマリストレージパフォーマンスを提供したいと望んでいる企業やサービスプロバイダーにとって、重要な実現テクノロジーである。

複数の作業負荷が限られたリソースを共有する場合、ＱｏＳはそのリソースの共有方法を制御するよう補助し、最もノイズの多い近隣（アプリケーション）が同じシステムの他のすべてのアプリケーションのパフォーマンスを中断させるのを防ぐ。

ストレージアレイでは、帯域幅と１秒あたりの入出力操作（ＩＯＰＳ）を制限して、ボリュームごとにＱｏＳを設定できる。通常、分散型サーバを備えた共有ドライブストレージスタックでは、ストレージアレイのようにＱｏＳを実施できる単一のポイントはない。

ディスクのクローン作成は、パーティションまたはハードドライブ全体のイメージを作成するプロセスである。これは、ドライブを他のコンピュータにコピーすること、およびバックアップや復旧の目的で有用であり得る。

通常、コピーは、ホストがデータにアクセスし続けるときの特定の時点で行われる。ほとんどのミッドレンジおよびハイエンドのストレージアレイは、ストレージアレイ内のボリュームのクローンを作成する機能を含んでいる。ストレージアレイではなくサーバで管理されているボリュームには、ソースとターゲットが異なるエンティティに存在する可能性があるため、クローンを作成する機能がない。

論理ボリューム管理（ＬＶＭ）はストレージ仮想化の一種で、システム管理者に従来のパーティショニングよりも柔軟なディスクストレージ領域の管理方法を提供する。このタイプの仮想化ツールは、オペレーティングシステムのデバイスドライバスタック内にある。これは、物理ボリューム（ＰＶ）を物理エクステント（ＰＥ）に分割することによって機能する。ＰＥは論理エクステント（ＬＥ）にマッピングされ、その後論理エクステント（ＬＥ）はボリュームグループ（ＶＧ）にプールされる。これらのグループは、仮想ディスクパーティションとして機能する論理ボリューム（ＬＶ）に共にリンクされており、ＬＶＭを使用してそのように管理できる。

シックプロビジョニングは、一般的に行われているタイプのストレージ事前割り当てである。シックプロビジョニングでは、仮想ディスクの作成時に、仮想ディスクストレージ容量の全量が物理ストレージに事前に割り当てられる。シックプロビジョニングされた仮想ディスクは、データストアでそれに割り当てられたすべてのスペースを最初から消費するため、そのスペースを他のボリュームが使用することはできない。

シンプロビジョニングは、もう１つの一般的に行われているタイプのストレージ事前割り当てである。シンプロビジョニングされた仮想ディスクは、最初に必要なスペースのみを消費し、需要の増加に応じて時間の経過と共に大きくなる。シンプロビジョニングは、比較的小さなチャンクで割り当てられるシン割り当てのメタデータを保持するために、遥かに多くのＲＡＭを消費する。シンプロビジョニングは、ｂツリーデータ構造を経由する必要があるため、集中的なランダムアクセスを促進して論理アドレスを物理アドレスに変換するために必要なＩ／Ｏで遥かに多くのＣＰＵを消費する。共有ストレージは、複数のサーバによって共有またはアクセスされるストレージリソースの一種である。

Ｌｉｎｕｘのクラスタ化論理ボリュームマネージャ（ＣＬＶＭ）は、ＬＶＭに対するクラスタリング拡張機能のセットである。これらの拡張機能により、コンピュータのクラスタがＬＶＭを使用して共有ストレージ（ＳＡＮ上など）を管理できるようになる。ＣＬＶＭは、論理ボリュームの構成中に物理ストレージへのアクセスをロックし、クラスタ化されたロックサービスを使用して共有ストレージを管理することで、ユーザが共有ストレージに論理ボリュームを構成できるようにする。

通常、クラスタの構成と保守は複雑なタスクである。さらに、単一ノードの誤動作がクラスタ全体の健全性に影響を与える可能性がある。また、一般にＯＳディストリビューションでは、クラスタリング用のライセンス料金が別途必要になる。

スモールコンピュータシステムインターフェース（ＳＣＳＩ）は、コンピュータと周辺機器の間で物理的に接続してデータを転送するための一連の標準である。ｉＳＣＳＩはＩｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅの略である。ｉＳＣＳＩは、トランスポートコントロールプロトコル（ＴＣＰ）の上位で動作するトランスポート層プロトコルである。これにより、ＴＣＰ／ＩＰネットワークを介したｉＳＣＳＩイニシエータとストレージターゲットとの間のブロックレベルのＳＣＳＩデータ転送が可能になる。

論理ユニット番号（ＬＵＮ）は、ファイバーチャネル（ＦＣ）やｉＳＣＳＩなど、ＳＣＳＩプロトコルまたはＳＣＳＩをカプセル化するストレージエリアネットワークプロトコルによってアドレス指定されるデバイスである論理ユニットを識別するために使用される番号である。

新しいデバイスを追加する場合、バスで新しいデバイスを見つけるために再スキャンプロセスが必要である。再スキャンプロセスは、すべてのホストバスアダプタ（ＨＢＡ）を調べる必要がある。各ＨＢＡでは、すべてのＳＣＳＩターゲットを調べる必要がある。各ターゲットで、すべてのＬＵＮ番号を調べて、新しいデバイスが存在するかどうか確認を試みる必要がある。それぞれのＬＵＮの確認は、タイムアウトになるまで待ってから続行する必要がある。

再スキャンプロセスはまた、デバイスを取り外した時にも実行される。ＨＢＡ、ターゲット、ＬＵＮの数に応じて、通常、再スキャンプロセスには最大１０分かかることがある。

ＮＶＭｅ（不揮発性メモリエクスプレス）は、エンタープライズシステムおよびクライアントシステムとソリッドステートドライブ（ＳＳＤ）間のデータ転送を高速化するために作成されたホストコントローラインターフェースおよびストレージプロトコルである。

ＮＶＭｅ ｏｖｅｒ Ｆａｂｒｉｃｓ（ＮＶＭｅ－ｏＦ）は、ホストコンピュータとターゲットのソリッドステートストレージデバイスまたはシステムの間で、イーサネット、ファイバチャネル（ＦＣ）、またはＩｎｆｉｎｉＢａｎｄなどのネットワークを介して、データを転送するための不揮発性メモリのエクスプレスメッセージベースのコマンドを可能にするために設計されたテクノロジー仕様である。ＮＶＭｅバスには、ＳＣＳＩバスに関して実行されるのと同様の再スキャンプロセスが必要であり、同様に長いスキャン時間がかかる。

サーバは通常、ＮＶＭｅおよびＳＣＳＩ標準プロトコルを使用して、様々なＨＢＡおよびプロトコルテクノロジーを使用してネットワーク経由でリモートデバイスを接続し、一方で、リソースを公開するサーバは一般にターゲットと呼ばれ、リソースを消費するサーバはイニシエータと呼ばれる。

「自己暗号化ドライブ」（ＳＥＤ）という用語は通常、フルディスク暗号化が組み込まれたＨＤＤ、ＳＳＤなどの記憶媒体のテクノロジーを指すときに使用される。「ＯＰＡＬ」という用語は、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐによって開発された自己暗号化ドライブの一連の仕様を表すために一般的に使用されている。

現在入手可能な自己暗号化ＳＳＤ／ＨＤＤの多くは、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ（ＴＣＧ）によって開発された「ＯＰＡＬ ２．０」暗号化とエンタープライズ規格を実装している。ＴＣＧ規格のＥｎｔｅｒｐｒｉｓｅ ＳＡＳバージョンは、「ＴＣＧ Ｅｎｔｅｒｐｒｉｓｅ」ドライブと呼ばれる。規格に従って製造されたハードウェアは、相応にラベル付けがされている。

ドライブのロック解除は、オペレーティングシステムの実行中に、ソフトウェアユーティリティを使用して、起動前の認証環境で、または電源投入時にＢＩＯＳベースのＡＴＡパスワードを使用して実行できる。キーの管理はディスクコントローラ内で行われ、暗号化キーは通常１２８ビットまたは２５６ビットのＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ）である。

ＴＣＧ「ＯＰＡＬ２．０」標準仕様に準拠した自己暗号化ドライブ（最新の自己暗号化ドライブのほぼすべて）は、認証キーと第２レベルのデータ暗号化キーによるキーの管理を実装している。データ暗号化キーは、データが実際に暗号化／復号されるキーである。認証キーは、データ暗号化キーを復号する（次にデータを復号する）ユーザ向けの第１レベルのパスワード／パスフレーズである。このアプローチには次のような特有の利点がある。
● これにより、ユーザはディスクの既存の暗号化データを失うことなくパスフレーズを変更できる。
● セキュリティの脅威に迅速かつ簡単に対応し、侵害されたパスフレーズを取り消すことができ、それにより、セキュリティが向上する。それはまた、ほぼ瞬時の、暗号的に安全なディスク全体の消去を容易にする。

ハードウェアセキュリティモジュール（ＨＳＭ）は、強力な認証のためにデジタルキーを保護および管理し、暗号化処理を提供する物理コンピューティングデバイスである。これらのモジュールは従来、プラグインカード、またはコンピュータまたはネットワークサーバに直接的に接続される外部デバイスの形式で提供される。

サーバでキー用の特別なストレージを使用している場合でも、一度キーがサーバのメインメモリ内に存在しなければならないため、サーバでキーインメモリのエクスプロイトが実行される可能性がある。

トンネリングプロトコルは、あるネットワークから別のネットワークへのデータの移動を可能にする通信プロトコルである。これには、カプセル化と呼ばれるプロセスを通じて、プライベートネットワーク通信をパブリックネットワーク経由で送信できるようにすることが含まれる。

トンネリングでは、おそらく標準として暗号化と共に、トラフィックデータを別の形式に再パッケージ化することが関与するため、トンネルを通過するトラフィックの性質を隠すことができる。

通常、ストレージコントローラは、ストレージソフトウェアを実行するストレージアレイのコンピューティング部分である。ストレージコントローラに障害が発生すると、ストレージソフトウェアが実行できなくなり、アレイがオフラインになる。その結果、データのアクセス性を維持するために冗長ストレージコントローラは重要である。一般的なアクティブ／アクティブアプローチでは、ＬＵＮとボリュームをサポートするために両方のコントローラが利用できる。どちらのストレージコントローラにもＬＵＮを割り当てることができる。コントローラに障害が発生した場合、残っているコントローラはそれ自身と障害が発生したコントローラのＬＵＮをサポートできる。

ターゲットポートグループサポート（ＴＰＧＳ）とも呼ばれる非対称論理ユニットアクセス（ＡＬＵＡ）は、ＳＣＳＩデバイスのパスの優先順位付けを定めるＳＣＳＩの概念とコマンドのセットである。非対称名前空間アクセス（ＡＮＡ）は、ホストオペレーティングシステムのマルチパスＩ／Ｏ（ＭＰＩＯ）またはマルチパススタックへのパス状態を監視および通信するためのＮＶＭｅプロトコル機能であり、ＡＮＡ経由で通信される情報を使用して、イニシエータとターゲット間の複数のパスを選択および管理する。

通常、エンタープライズのハイエンドおよびミッドレンジのストレージアレイは、デュアルコントローラのグループで構築される。一方のコントローラは特定のボリュームに対してストレージスタック動作を実行でき、他方はＩＯを転送するだけである。ＩＯ転送はインターコネクトを使用して行われる。コントローラ間の専用リンクまたはネットワーク経由のいずれかによるものである。ホストは両方のコントローラに接続されている。コントローラは、ＡＬＵＡまたはＡＮＡを使用して、そのボリュームのサービングコントローラの優先パスについてホストを更新する。ストレージアレイは、デュアルコントローラ、相互接続、およびフェイルオーバーのサポートを含む統合ストレージスタックで構築されている。オペレーティングシステムには、このようなホストサービス用に設計および使用される、堅牢かつ複雑で高価なストレージスタックコンポーネントのセットが含まれている。

したがって、現在利用可能なストレージシステムの提示された欠点と機能制限／要件には、信頼性の高いデータストレージ機能と様々な条件や懸念事項に適応した柔軟性を提供し、したがってユーザの様々なニーズや利用可能なインフラストラクチャに合わせたリアルタイムの動作を提供することができる、信頼性が高く、高速で、コスト効率が高く、包括的なソリューションを提供する、より優れた、より効率的なデータストレージシステムおよび方法を提供する余地が残されている。

本発明は、信頼性の高いデータストレージ機能および様々な条件および懸念事項に適応した柔軟性を提供できる、信頼性が高く、高速で、コスト効率が高く、包括的なソリューションを提供するために、利用されていない利用可能なハードウェアリソースを利用することを可能にする効率的なデータストレージシステムおよび方法を提供する。

本発明の一態様によれば、そのようなシステムおよび方法は、信頼性の高いデータストレージ機能および様々な条件および懸念事項に適応した柔軟性を提供できる、信頼性が高く、高速で、コスト効率が高く、包括的なソリューションを提供するために、利用されていない利用可能なＤＡＳを活用することにより取得される。

以下の実施形態およびその態様は、範囲を限定するものではなく、例示および説明を意図するシステム、デバイス、および方法と関連して説明および図示される。様々な実施形態では、上述の問題のうちの１つまたは複数が軽減または解消されているが、他の実施形態は他の利点または改善を目的としている。

本発明の一態様によれば、データストレージが提供され、記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバ、データプレーン（ＤＰ）ネットワークを通してリモートリソース（複数可）にアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、および各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、ターゲットサーバの記憶媒体の指定された部分がＤＰネットワークに公開されており、オーケストレータは、イニシエータサーバが、ＤＰネットワークを介してターゲットサーバと対話するように構成されるように、前記サーバの内部に組み込まれたオペレーティングシステムのストレージスタックコンポーネント（ＳＳ）および標準ストレージスタック（ＳＳＳ）を調整することによって、記憶媒体の指定された部分を利用するように指定される。

本発明の別の態様によれば、データストレージが提供され、記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバ、データプレーン（ＤＰ）ネットワークを通してリモートリソース（複数可）にアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、および各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、オーケストレータは、記憶媒体の内部に記憶されたブロックデバイスをマッピングおよび認識するためにＣＰを利用するように構成され、ブロックデバイスは、オーケストレータによってＤＰネットワークに公開されるように構成され、オーケストレータは、ＤＰネットワークを介してブロックデバイスをイニシエータサーバに転送するように構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバ、記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してリモートリソース（複数可）にアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、および各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、結合された記憶媒体は、共有のドライブストレージスタックを形成し、オーケストレータは、共有ドライブストレージスタックの動作性と状態を監視および検査するためにＣＰを利用するように構成され、さらに、前記共有ドライブストレージスタックの内部に記憶されているブロックデバイス（複数可）の適切な動作を監視、記録および検査するように構成され、オーケストレータは、共有のドライブストレージスタックに影響を与える誤動作を特定するように構成され、オーケストレータは、共有ドライブストレージスタックを形成する少なくとも１つの動作可能なリモート記憶媒体の同時かつ調整された使用を管理することによる、非集中型の再構築手順を実行するように構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、ストレージボリュームを備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能で公開可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも２つのサーバ、各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、各サーバは、それ自身のＤＰコンポーネントを管理するように構成され、オーケストレータは、少なくとも１つの整合性グループスナップショットを取得するためにＣＰを利用するように構成され、特定の時点でボリュームの一貫するスナップショットを提供するために、ＩＯの一時停止と再開を管理するようにさらに構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、ストレージボリュームを備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能で公開可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも２つのサーバ、各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、少なくとも２つのストレージボリュームが分散型ストレージスタックを作成し、各サーバが独自のボリュームに由来するローカルＱｏＳ ＤＰを管理および実施するように構成され、オーケストレータは、分散型ストレージスタックの内部でＱｏＳ ＣＰ制限を集中的に調整および実施するように構成されている。

本発明の別の態様によれば、データストレージが提供され、記憶媒体ボリュームを備え、少なくとも１つのターゲットコンポーネントを使用してデータプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバ、記憶媒体ボリュームを備え、少なくとも１つのオーケストレータコンポーネントを使用してデータプレーン（ＤＰ）ネットワークを通して記憶されたデータにアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、および各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、オーケストレータは、ターゲットサーバに記憶されたボリュームのデータスナップショットを作成するように構成され、データスナップショットは、イニシエータコンポーネントを通じてターゲットサーバに公開されるよう構成され、ターゲットサーバのボリュームのクローンがイニシエータサーバのボリュームに作成されるように構成される。

本発明のさらに別の態様によれば、データストレージが提供され、ＬＶＭストレージボリュームを備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能で公開可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも２つのサーバ、各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、サーバ間の同期が、クラスタリングを必要とせずに、オーケストレータを使用して実行され、オーケストレータは、並列動作をキューに入れ、１つのサーバに属するストレージボリュームのみが所定の時間に動作を実行するように構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、記憶媒体ボリュームを備え、少なくとも１つのターゲットコンポーネントを使用してデータプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのターゲットサーバ、少なくとも１つのイニシエータコンポーネントを使用してデータプレーン（ＤＰ）ネットワークを通して記憶されたデータにアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された少なくとも１つのイニシエータサーバ、および各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、オーケストレータは、ターゲットサーバ側およびイニシエータサーバ側を調整し、リモートデバイスのアタッチメントを再スキャン／バススキャンを必要とせずに実行するように構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、ストレージボリュームを備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能で公開可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つの暗号化サーバ、各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータ、を含み、オーケストレータは、キーがサーバとは別に記憶されるように、そのデータベースに少なくとも１つのキーを記憶することによって暗号化を管理するように構成され、オーケストレータは、キーをサーバに公開することなく、トンネルを使用してサーバにキーを配信するように構成されている。

本発明のさらに別の態様によれば、データストレージが提供され、ＲＡＩＤ１ストレージボリュームを備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能で公開可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも２つのサーバを含み、サーバは互いに遠隔に配置され、ＲＡＩＤ１は、少なくとも２つのサーバの２つのボリュームを接続した状態で、リモートレプリケーション手順に利用されるように構成される。

いくつかの実施形態によれば、少なくとも１つのイニシエータサーバは、マルチパス接続を使用して少なくとも２つのターゲットサーバと対話するように構成され、イニシエータサーバとターゲットサーバとの間の調整は、各サーバにインストールされたＣＰオーケストレータを使用して実行でき、ＤＰネットワーク経由でアクセス可能なターゲットサーバまたはイニシエータサーバとオーケストレータの間の通信は、各前記サーバにインストールされた指定されたソフトウェアコンポーネントを使用して実行され、イニシエータサーバは、複数のターゲットサーバで記憶媒体の複数の指定された部分に由来するデータ冗長性を提供するように構成された独立ディスク冗長アレイ（ＲＡＩＤ）ストレージスタックコンポーネント（ＳＳＣ）を利用するように構成され、ＲＡＩＤ ＳＳＣは、少なくとも２つのターゲットサーバの記憶媒体の指定された部分に由来する組み合わされた複数のイニシエータパスに由来するデータ冗長性を提供するように構成でき、ターゲットサーバは異なる場所に配置され得て、オーケストレーションは異なるレジリエンスドメイン全体に割り当てられ、異なるレジリエンスドメインを考慮しながら割り当てられたオーケストレーションはまた、システムバランスの維持を考慮し、オーケストレータは、管理プロトコルを使用してサーバと対話するように構成でき、記憶媒体の指定された部分は、論理ボリュームマネージャ（ＬＶＭ）ＳＳＣを使用して割り当てられ、記憶媒体は、ソリッドステートドライブ（ＳＳＤ）ベース、ストレージクラスメモリ（ＳＣＭ）ベース、ランダムアクセスメモリ（ＲＡＭ）ベース、ハードディスクドライブ（ＨＨＤ）ベース、物理コントローラまたはクラウドベースのサービス（ＳａａＳ）であることができる一方、各サーバの動作は、全体または部分的に、データ処理ユニット（ＤＰＵ）によって実装され得る。

本発明のいくつかの実施形態が、本明細書において、添付の図面を参照しながら説明される。この説明は、図面と共に、当業者に対して、いくつかの実施形態がどのように実施され得るかを明白にするものである。図面は例示的な説明を目的としており、本発明の基本的な理解に必要な以上に実施形態の構造の細部を詳細に示そうとしていない。

図面において、
従来のストレージアレイシステムの概略図となる。 従来のストレージアレイシステムの概略図となる。 従来のクラウドベースのデータ管理システムとなる。 いくつかの実施形態による、従来のストレージアレイシステムと本発明の主題であるデータストレージシステムとの間の一般的な比較の概略図となる。 および 本発明のいくつかの実施形態による、データストレージシステムの概略図となる。 本発明のいくつかの実施形態による、データストレージシステムの概略図となる。 本発明のいくつかの実施形態による、ストレージシステムの一般的なアーキテクチャの概略図となる。 本発明のいくつかの実施形態による、マルチパス接続をさらに備える従来のストレージアレイターゲットおよびイニシエータサーバの概略図となる。 本発明のいくつかの実施形態による、ストレージアレイ接続の概略図となる。 本発明のいくつかの実施形態による、図８および図９に示したストレージシステムによって実行されるサーバ間のリモートブロックデバイス接続のオーケストレーション手順の概略図となる。 ホットスペアを有する従来のＲＡＩＤ５の概略図となる。 ＲＡＩＤホットスペア再構築の概略図となる。 従来のホットスペアロジックアレイの交換手順の概略図となる。 本発明のいくつかの実施形態による、共有ドライブの監視および復旧動作、または非集中型再構築システムおよびプロセスの概要の概略図となる。 従来の整合性グループスナップショットシステムの概略図となる。 本発明のいくつかの実施形態による、分散型スナップショット整合性グループシステムの概略図となる。 ストレージアレイにおける従来のストレージＱｏＳの概略図となる。 ボリューム間の従来のストレージＱｏＳの概略図となる。 本発明のいくつかの実施形態による、共有のドライブストレージスタックの分散型ＱｏＳの概略図となる。 クローンを備えた従来のエンタープライズストレージアレイシステムの概略図となる。 未割り当てデータによるボリューム全体のクローン作成システムの概略図となる。 本発明のいくつかの実施形態による、リモートオンラインボリュームのクローンの分散型システムの概略図となる。 ボリューム部分を割り当てるように構成された従来の論理ボリュームマネージャＬＶＭの概略図となる。 ボリューム部分を割り当てるように構成された従来の論理ボリュームマネージャＬＶＭの別の概略図となる。 従来の論理ボリュームエクステントおよびメタデータシステムの概略図となる。 サーバ間の従来の共有ストレージの概略図となる。 従来のクラスタ化された論理ボリュームマネージャの概略図となる。 本発明のいくつかの実施形態による、クラスタのない分散型論理ボリュームマネージャの概略図となる。 ＳＣＳＩバスシステムの従来のレイアウトの概要の概略図となる。 従来の複数チャネルの論理ユニットシステムの概略図となる。 従来のＩＰネットワーク上のｉＳＣＳＩバスの概略図となる。 本発明のいくつかの実施形態による、再スキャンを伴わない調整されたリモートデバイスアタッチメントシステム／プロセスの概略図となる。 従来の自己暗号化ドライブ（ＳＥＤ）ロジックの概略図となる。 従来のプロトコルトンネルの概略図となる。 ２つのサーバ間のトンネルを使用する従来のペイロードカプセル化の別の表現の概略図となる。 本発明のいくつかの実施形態による、トンネルによるリモート自己暗号化ドライブ制御の概略図となる。 従来のＲＡＩＤ１－データミラーリングシステムの概略図となる。 従来の非同期レプリケーションシステムの概略図となる。 従来の同期レプリケーションシステムの概略図となる。 本発明のいくつかの実施形態による、ＲＡＩＤ１システムを使用する同期レプリケーションの概略図となる。 本発明のいくつかの実施形態による、ＬＶＭスナップショットおよびＲＡＩＤ１システムを使用する非同期レプリケーションの概略図となる。 本発明のいくつかの実施形態による、データストレージシステムの概略図となる。 マルチコアのスケーラブルなＲＡＩＤパリティの概略図となる。 サーバ間のボリュームのフェイルオーバーの概略図となる。

以下の詳細な説明では、本発明の完全な理解を提供するために、多くの具体的な詳細が述べられている。しかし、本発明がこれらの具体的な詳細を用いずに実施され得ることが、当業者により理解される。他の例では、周知の方法、手順、および構成要素、モジュール、ユニット、および／または回路は、本発明を曖昧にしないように、詳細には説明されていない。一実施形態に関して説明したいくつかの特徴または要素は、他の実施形態に関して説明した特徴または要素と組み合わせることができる。明確にするために、同じまたは類似の特徴または要素についての説明を繰り返さない場合がある。

本発明の実施形態はこの点に限定されないが、例えば、「処理する」、「計算する（ｃｏｍｐｕｔｉｎｇおよびｃａｌｃｕｌａｔｉｎｇ）」、「判定する」、「確立する」、「分析する」、「確認する」、「設定する」、「受信する」など用語を用いる記述は、コンピュータのレジスタおよび／またはメモリの内部で物理（例えば、電子）量として表されるデータを、コンピュータのレジスタおよび／またはメモリ、あるいは動作および／またはプロセスを実行する命令を記憶できる他の情報の非一時的記憶媒体内部の物理量として同様に表される他のデータに操作および／または変換する、コントローラ、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、または他の電子コンピューティングデバイスの動作（複数可）および／またはプロセス（複数可）を指し得る。

明示的に述べられていない限り、本明細書に記載される方法の実施形態は、特定の順番または順序に制約されない。さらに、記載された方法の実施形態またはその要素のいくつかは、同時に、同じ時点で、または並行して発生または実行され得る。

本明細書で使用される場合、「コントローラ」という用語は、中央処理装置（ＣＰＵ）またはマイクロプロセッサを備え、またいくつかの入出力（Ｉ／Ｏ）ポートを備えることができる任意のタイプのコンピューティングプラットフォームまたはコンポーネントを指す。

これより図１を参照すると、これは従来のストレージアレイシステム１０を概略的に示す。図示のように、ストレージアレイ１０２（例えば、Ｄｅｌｌ ＥＭＣデータストレージおよびバックアップアレイ、または他のいずれかの市販のデータストレージシステムであってもよい）は、データを記憶し、複数のサーバ１００へのデータアクセスを提供するように構成された複数の記憶媒体１０４を含む。いくつかの実施形態によれば、ストレージアレイ１０２は、ストレージアレイ１０２およびその中に組み込まれた記憶媒体１０４の動作を制御および管理するように指定された様々なストレージ／制御コンポーネントを含むオペレーティングシステムによって動作可能であり得る。

いくつかの実施形態によれば、該従来のストレージアレイシステム１０は、ストレージアレイ１０２の標準コントロールプレーン（ＣＰ）を使用して、サーバ１００にいずれかの追加のＣＰソフトウェアをインストールすることを回避するように構成され得る。いくつかの実施形態によれば、ストレージアレイ１０２にインストールされ、ストレージおよび制御コンポーネントを含むオペレーティングシステムは、例として、ＲｅｄＨａｔ、ＳｕＳＥなどＬｉｎｕｘベースのディストリビューション、またはＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓサーバであってもよい。

これより図２を参照すると、これは従来のストレージアレイシステム１０を概略的に示す。図示のように、ストレージアレイ１０２は、データを記憶し、複数のサーバ１００へのデータアクセスを提供するように構成された複数の記憶媒体スタック１０４を含む。いくつかの実施形態によれば、ストレージアレイ１０２は、データプレーンＤＰ１０６およびコントロールプレーンＣＰ１０８のコンポーネントおよびプロトコルを含み、ＣＰ１０８のコンポーネントおよびプロトコルは、ＤＰ１０６のコンポーネントおよびプロトコルの様々な動作を制御するように構成される。通常、ストレージソリューションのＤＰとＣＰは共に結合されるが、統合されたストレージソフトウェアが、データサービス、例えばデータの保護、高い可用性、スペースの割り当て、および／またはデータの削減を監視するだけでなく、ボリュームの作成、ドライブの障害の処理、スナップショットのロールバックなどの制御サービスも監視するこのような結合は、非効率性と欠点をもたらす。

これより図３を参照すると、これは従来のクラウドベースのデータ管理システム２０を概略的に示す。図示のように、様々なタスクを実行し、信頼性の高いデータの割り当てと記憶を確実にするために、様々なコンポーネントおよびプロトコルが指定されている。該コンポーネントおよびプロトコルは、技術の進歩に合わせて更新するだけでなく、恒常的なデバッグと保守を必要とする。したがって、統合されたクラウドベースのデータ管理システム２０の現在の質および性能は、大量なリソースの犠牲のもとで実現される。いくつかの実施形態によれば、クラウドベースのデータ管理システム２０は、ソリッドステートドライブ（ＳＳＤ）データセンターのソリューションであってもよく、これは、そのメディアストレージがクラウドベースのストレージアレイの一部を形成するＳＳＤスタッキングであることを意味する。

これより図４を参照すると、これは、いくつかの実施形態による、従来のストレージアレイシステム１０と、本発明の一態様であるデータストレージシステム３０との間の一般的な比較を概略的に示す。図示のように、また前に開示したように、従来のストレージアレイシステム１０は、複数のサーバ１００にデータを記憶し、データアクセスを提供するように構成された複数の記憶媒体スタック１０４を含むストレージアレイ１０２を備える。

いくつかの実施形態によれば、データストレージシステム３０は、サーバ２００の集合を指定し、それらの記憶媒体スタック２０４を利用して（ＯＳの機能性に悪影響を与えることなく、または実質的に影響を与えずに）エンタープライズストレージアレイとして動作するように構成され得、そのためデータストレージシステム３０は、従来ストレージアレイ１０２を使用して一般的なストレージアレイシステム１０によって提供されていたサービスを、該サーバ２００で直接提供することができる。

いくつかの実施形態によれば、データストレージシステム３０はまた、共通のストレージアレイではこれまで利用できなかったさらなる機能を追加するように構成されている。例えば、ストレージスタック２０４は、指定されたパーティションに分割することができ、各記憶媒体２０４が、様々なサーバ２００から生成されたデータを記憶し、そのデータへのアクセスを提供する専用の複数の指定領域を提供できるようにすることができ、記憶媒体スタック２０４は、サーバ２００の内部に組み込まれているため、ストレージアレイ１０２の必要性を排除し、結合されたＤＰネットワークがデータストレージシステム３０によって作成され、実装され、利用される。

これより図５Ａおよび図５Ｂを参照するが、これらは、いくつかの実施形態によるデータストレージシステム３０を概略的に示す。図示のように、また前に開示したように、データストレージシステム３０はサーバ２００の集合を備え、それらの記憶媒体スタック２０４を利用してエンタープライズストレージアレイとして動作するように構成される。

いくつかの実施形態によれば、データストレージシステム３０は、いずれかのサードパーティのソフトウェアコンポーネントまたはスクリプトをインストールすることなく、そのような目的を達成するように構成され得る。当該の取り組みは、専用のストレージアレイユニットの代わりにサーバ（複数可）２００のストレージスタック２０４を使用することによって得ることができる。

いくつかの実施形態によれば、少なくとも１つのオーケストレータ２０６が、該サーバ２００のそれぞれと対話するように構成され、ＤＰ２０８ネットワークのＣＰ２１０を制御するように指定される。いくつかの実施形態によれば、ＤＰ２０８は、各サーバ２００の内部に組み込まれた記憶媒体２０４に記憶される。

いくつかの実施形態によれば、Ｌｉｎｕｘベースのオペレーティングシステムなどの様々なオペレーティングシステムがサーバ（複数可）２００にインストールされ、ＤＰ２０８またはＣＰ２１０に関連する様々なコンポーネントおよびプロトコルを含むことができる。オーケストレータ２０６は、サーバ（複数可）２００内にすでに組み込まれているコンポーネントおよびプロトコルを使用して、指定された外部ストレージアレイユニットなしに、データストレージおよびデータバックアップ機能を提供するために、これらのすでにインストールされているコンポーネントを調整するように構成され得る。

いくつかの実施形態によれば、サーバのストレージスタック２０４の制御インターフェース（複数可）は、標準インターフェース（複数可）、例えば、Ｌｉｎｕｘ用のセキュアシェルプロトコル（ＳＳＨ）、Ｗｉｎｄｏｗｓサーバ用のＰｏｗｅｒＳｈｅｌｌ Ｒｅｍｏｔｉｎｇ Ｐｒｏｔｏｃｏｌ（ＰＳＲＰ）などを介して動作可能であってもよい。

いくつかの実施形態によれば、ストレージデータ転送のためのサーバ（複数可）２００間の通信は、オペレーティングシステムの標準的なコンポーネントを利用する、ｉＳＣＳＩ、ファイバチャネル、ＮＶＭｅＯＦ、ＦＣ－ＮＶＭｅなどの標準プロトコルを使用して実行され得るが、これらに限定されない一方、オーケストレータ２０６は、そのようなプロトコルおよび他の標準的な利用可能なコンポーネントおよび機能を使用して、強化された動作性を提供するように構成されている。

いくつかの実施形態によれば、集中型または複数のオーケストレータ（複数可）２０６は、標準管理インターフェースを介して様々な異なるサーバ２００に接続するように構成され得る。いくつかの実施形態によれば、１つの集中型オーケストレータまたは複数のオーケストレータ２０６が、様々なストレージオーケストレーションタスクを実行するように特に適応され得る。

いくつかの実施形態によれば、オーケストレータ２０６の数は、データストレージシステム３０（例えば、大規模なデータセンターであってもよい）の一部を形成するサーバ２００の全体的な可能性に応じて、また該サーバ２００の必要な可用性の割合に応じて、決定され得る。

いくつかの実施形態によれば、オーケストレータ２０６は、様々な手段によって実装されてもよく、例えば、これは（１つ以上のサーバ２００の）サーバにインストールされたソフトウェアとして、仮想マシンとして、コンテナなどとして、実装され得る。

いくつかの実施形態によれば、オーケストレータ２０６は、ストレージオーケストレーションタスクの外部からの開始のために、公開されたアプリケーションプログラミングインターフェース（ＡＰＩ）を有し得、各記憶媒体２０４の健全性を定期的に監視し、ハードウェアの問題の特定などをするように構成され得る。いくつかの実施形態によれば、オーケストレータ２０６はまた、標準制御インターフェースを介して各記憶媒体２０４からのデータを表すカウンタによってパフォーマンスデータ（負荷、待ち時間、変動、関係など）を収集するように構成することもできる。

いくつかの実施形態によれば、サーバ（複数可）２００の各コンポーネントからの収集されたパフォーマンスカウンタは、将来の動作改善にフィードバックされるパフォーマンススナップショット（複数可）を提供するために集約される。オーケストレータ２０６の動作と集約されたパフォーマンスカウンタを組み合わせることで、独自のタスク管理、健全性の監視、およびシステムメンテナンスが可能になる。

これより図６を参照するが、これは、いくつかの実施形態によるデータストレージシステム４０を概略的に示す。図示のように、データストレージシステム４０は、記憶媒体３０４をさらに備え、オペレーティングシステム（例えば、Ｒｅｄ Ｈａｔ、ＳｕｓｅなどのＬｉｎｕｘベースのオペレーティングシステム）を実行するように構成され得る少なくとも１つのターゲットサーバ３００を含み得、該オペレーティングシステムは、ＤＰネットワークを介してアクセス可能なデータをホストするように指定されている。

いくつかの実施形態によれば、少なくとも１つのイニシエータサーバ３０２は、オペレーティングシステム（例えば、Ｒｅｄ Ｈａｔ、ＳｕｓｅなどのＬｉｎｕｘベースのオペレーティングシステム）を実行するように構成され得、それにおいて、該オペレーティングシステムは、ＤＰネットワーク経由でリモートリソース（複数可）にアクセスして公開されるように指定される。

いくつかの実施形態によれば、少なくとも１つのオーケストレータ３０６は、該ＤＰネットワークのＣＰを制御するために、該ターゲットサーバ（複数可）３００および／またはイニシエータサーバ（複数可）３０２のそれぞれと対話するように構成され得る。いくつかの実施形態によれば、ターゲットサーバ３００の一部を形成する記憶媒体３０４の指定された部分は、ＤＰネットワークに公開されてもよい、換言すれば、指定された物理空間は、ＤＰネットワークが使用する記憶空間に寄与するためにリザーブおよび指定される。

いくつかの実施形態によれば、オーケストレータ３０６は、該ターゲット／イニシエータサーバ（複数可）３００／３０２の内部に組み込まれたオペレーティングシステムのストレージスタック（ＳＳ）コンポーネントおよび標準ストレージスタック（ＳＳＳ）を調整することによって、記憶媒体の指定された部分を利用するように構成され、これにより、イニシエータサーバ３０２は、ＤＰネットワークを介してターゲットサーバ３００と対話するように構成される。

いくつかの実施形態によれば、データストレージシステム４０は、以下のステップを実行するように指定されてもよい。

● ターゲットサーバ３００の一部を形成するターゲットの記憶媒体３０４にインストールされ、ＤＰネットワークを介してアクセス可能なデータをホストするように指定されたオペレーティングシステムを使用し、該記憶媒体３０４が永続的な記憶媒質を利用するために使用される、
● 記憶媒体３０４を複数のパーティションに分割するためにオペレーティングシステムの論理ボリュームマネージャ（ＬＶＭ）を使用する、
● 少なくとも１つのイニシエータサーバ３０２にインストールされたオペレーティングシステムを使用して、ＤＰネットワークを介して記憶媒体３０４のパーティション（複数可）にアクセスして消費し、リモートメディアの容量およびパフォーマンスを利用する、
● 該ターゲットサーバ（複数可）３００およびイニシエータサーバ（複数可）３０２のそれぞれと対話するように構成されたオーケストレータ３０６を使用し、該オーケストレータ３０６が、該ＤＰネットワークのＣＰを制御するように指定される、
● オペレーティングシステムを使用して少なくとも２つのネットワークパスを結合し、マルチパスコンポーネントを作成することで単一の記憶媒体パーティションを単一のネットワークデバイスとして利用し、このように、冗長性と効率性の強化を可能にする。

いくつかの実施形態によれば、上で開示されたステップは、オペレーティングシステムによって実行され、例えばプロセッサコアおよび／またはメモリページ、および様々な種類の帯域幅などのリソースに関して競合する計算に影響を与えるように構成された動的割り当ておよび割り当て解除の機能を提供するために、リソース管理コンポーネント（複数可）を使用することをさらに含んでもよい。いくつかの実施形態によれば、上で開示したステップの目的は、利用可能な有限のリソースに従って応答性を最適化するようにリソースを割り当てることである。

いくつかの実施形態によれば、また上で開示したように、少なくとも１つのイニシエータサーバ３０２は、マルチパス接続を使用して少なくとも２つのターゲットサーバ３００と対話するように構成される。いくつかの実施形態によれば、マルチパス接続を使用して、接続の信頼性を向上および強化し、より広い帯域幅を提供することができる。

いくつかの実施形態によれば、イニシエータサーバ（複数可）３０２とターゲットサーバ（複数可）３００との間の調整、またはその逆は、ＣＰを管理するように構成され、さらに各サーバに物理的にインストールされるように構成されたローカルオーケストレータ３０７のコンポーネントを使用して実行され得る。いくつかの実施形態によれば、ローカルオーケストレータ３０７を各サーバにインストールすることは、データストレージシステム４０を利用する柔軟な方法を提供することができ、また、データストレージシステム４０にクライアントのサーバの内部ソフトウェアおよびプロセスへのアクセスを提供する必要性を排除することができる。いくつかの実施形態によれば、オーケストレータ３０６に関して本明細書で開示されている動作および機能はまた、ローカルオーケストレータ３０７に適用することができ、またその逆も同様である。

いくつかの実施形態によれば、オーケストレータ３０６と、ターゲットサーバ３００またはイニシエータサーバ３０２との間の通信は、該サーバの各々にインストールされた指定のソフトウェアコンポーネントを利用することによって、ＤＰネットワークを介して実行され得る。

いくつかの実施形態によれば、イニシエータサーバ３０２は、複数のターゲットサーバ３００の内部に組み込まれた記憶媒体３０４の複数の指定された部分に由来するデータの冗長性を提供するように構成された独立ディスク冗長アレイ（ＲＡＩＤ）ストレージスタックコンポーネント（ＳＳＣ）を利用するように構成されている。

いくつかの実施形態によれば、ＲＡＩＤ ＳＳＣは、少なくとも２つのターゲットサーバ３００の記憶媒体３０４の指定された部分に由来する複数のイニシエータパスの結合に由来するデータの冗長性を提供するようにさらに構成される。

いくつかの実施形態によれば、ターゲットサーバ３００は、異なる部屋、建物、さらには国などの異なる場所に配置されてもよい。この場合、オーケストレータ３０６によって実行されるオーケストレーション手順は、異なるレジリエンスドメインに亘って割り当てられる。例えば、オーケストレータ３０６は、サイバーセキュリティ、自然災害、財務予測などに関する様々なパラメータを考慮し、適宜データフローを迂回させることができる。いくつかの実施形態によれば、オーケストレータ３０６によって実行され、サーバの割り当てを利用するように構成された該オーケストレーション手順は、許容可能なシステムバランスパラメータを維持することを考慮して実行される。

いくつかの実施形態によれば、オーケストレータ３０６は、施行プロトコルを使用してサーバ（複数可）３００／３０２と対話するように構成され得る。いくつかの実施形態によれば、記憶媒体３０４の指定された部分は、論理ボリュームマネージャ（ＬＶＭ）ＳＳＣを使用して割り当てられ得る。いくつかの実施形態によれば、記憶媒体３０４は、ソリッドステートドライブ（ＳＳＤ）ベース、ストレージクラスメモリ（ＳＣＭ）ベース、ランダムアクセスメモリ（ＲＡＭ）ベース、ハードディスクドライブ（ＨＨＤ）ベースなどであってもよい。

いくつかの実施形態によれば、オーケストレータ３０６は、物理コントローラデバイスであってもよく、またはクラウドベースのサービス（ＳａａＳ）であってもよく、オーケストレータ３０６が物理デバイスであるか否かに関係なく、データストレージおよびトラフィックを相互接続されたサーバにおいて命令および配置するように構成され得る。

いくつかの実施形態によれば、各サーバ（複数可）３００／３０２の動作は、全体的または部分的に、データ処理装置（ＤＰＵ）によって実装されてもよく、該ＤＰＵは、加速カードなどの加速ハードウェアであってもよく、ハードウェア加速は、汎用の中央処理装置（ＣＰＵ）で実行されるソフトウェアと比較して、特定の機能をより効率的に実行するために使用され得るため、汎用ＣＰＵで実行されるソフトウェアで計算できるデータのいずれかの変換はまた、カスタムメイドのハードウェア、または何らかの両方の組み合わせで計算できる。

いくつかの実施形態によれば、データストレージシステム３０は、物理サーバと仮想サーバの両方で動作可能であるだけでなく、従来のＩＴシステム（サーバおよびデータセンターなど）、プライベートクラウド、パブリッククラウド、マルチクラウド環境、コンテナ、仮想マシン、ベアメタルシステム、およびそれらのいずれかの組み合わせで使用することができる。

いくつかの実施形態によれば、従来のＳＤＳの下では、ストレージスタックコードは独自のソフトウェアに依存し、別個の独立したインストールおよびメンテナンスを必要とするが、データストレージシステム３０／４０は、前述のオーケストレータ２０６／３０６を使用することと組み合わされる、既にインストールされているオペレーティングシステムの機能に依存するように構成される。

いくつかの実施形態によれば、従来のＳＤＳの下では、コントロールプロトコルは独自のソフトウェアに依存し、別個の独立したインストールおよびメンテナンスを必要とするが、データストレージシステム３０／４０は、前述のオーケストレータ２０６／３０６を使用するオペレーティングシステムの機能に依存するように構成される。

従来のＳＤＳの下では、ノード相互接続は独自のソフトウェアに依存することになるが、いくつかの実施形態によれば、データストレージシステム３０／４０は、上で論じたオーケストレータ２０６／３０６を使用して標準ストレージプロトコルに依存するように構成される。

従来のＳＤＳの下では、ストレージアレイシステム１０を制御するスタックモデルは単一の独自のコードを使用し、ＤＰとＣＰの両方をインターリーブするコンポーネントを有するが、いくつかの実施形態によれば、データストレージシステム３０／４０は、ＣＰをエミュレートし、（とりわけ）ＤＰ上でその実際の操作を実行するために、上で開示したオーケストレータ２０６／３０６を使用しながらダミーデータプレーンを実行するために、オペレーティングシステムを利用するように構成される。

上で開示された様々な実施形態のいくつかの利点は、例えば、データストレージシステム３０／４０の下では無制限であると予想されるクラスタ内のノードの数に関して、従来のＳＤＳ動作と比較した場合に、超高性能を促進することができる。

述べたように、ＳＤＮを含む従来のネットワークに実装する場合、ＤＰとＣＰをストレージと互いに結合することは、特定の欠点と非効率性がある。いくつかの実施形態によれば、ＳＤＮは、ＤＰをストレージから切り離し、ＣＰをストレージから切り離すように構成され得る。いくつかの実施形態によれば、ストレージシステムは、ネットワークのＣＰからデータを転送および保存するためのダミーデバイスを用いて構築され得、これはネットワークを介してトラフィックがどのように流れるかを制御する一方、ＳＤＮが、他のデカップリング手段よりも、はるかに安価な機器、機敏性および無制限のパフォーマンスを可能にするものと考えられる。さらなるデータプレーンリソースを柔軟に追加できるため、ＳＤＮを使用したこのようなデカップリングは、制限のないスケーラビリティと、処理されるクラスタへの限定的な影響に起因する生存率の向上を実現する。いくつかの実施形態によれば、データ容量、帯域幅、およびＩＯＰＳがＣＰサービスの使用率に影響しないため、単一のオーケストレータを提供して、巨大なクラスタにストレージサービスを提供することができる。このように分離されたＤＰは、プロトコル、ＲＡＩＤ、暗号化、ＱｏＳ制限、スペースの割り当て、データの削減などの様々なデータサービスに利用できる。一方、このように分離されたＣＰは、ボリュームのライフサイクル（作成、削除、サイズ変更など）、ストレージプール管理、スナップショット調整－整合性グループ、障害の監視、パフォーマンス監視、障害の処理などの様々なストレージサービスや調整に利用できる。

いくつかの実施形態によれば、データストレージシステム４０は、ＳＤＮベースのＣＰおよびＣＤ、ならびにストレージデカップリングを取得するために以下のステップを実行するように指定され得る。

サーバ３００のうちの１つのストレージＣＰ３０４を使用して、ストレージＤＰを作成する。サーバ３０２のストレージＣＰを使用して、ストレージＤＰを作成し、該サーバ３００に接続し、公開されたドライブチャンクを消費する。
● 別のサーバ３００のストレージＣＰを使用してストレージＤＰを作成する。
● サーバ３０２のストレージＣＰを使用して、ストレージＤＰｅを作成し、該別のサーバ３００に接続し、公開されたドライブチャンクを消費する。サーバ３０２のストレージｃＣＰを使用して、マルチパス、ＲＡＩＤ、暗号化、圧縮、重複排除、ＬＶＭ、およびレプリケーションサービスを含むストレージＤＰを作成する。

これより図７を参照すると、これは本発明のいくつかの実施形態によるストレージシステム３０／４０の一般的なアーキテクチャを概略的に示す。図示のように、様々なコンポーネントが対話し、ＤＰネットワーク上で分散型ストレージとバックアップ機能を提供するように構成されている。例えば、オーケストレーションのジョブは様々なスタックコンポーネントに影響を与える可能性があり、これらは次第に、ＳＳＨ、ＰＳＲＰ、Ａｍａｚｏｎ ＡＷＳ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ、またはＧｏｏｇｌｅ Ｃｌｏｕｄなどの様々なクラウドコンピューティングプラットフォーム／暗号化ネットワークプロトコル／アプリケーションプログラミングインターフェースを通じて変換され、利用される。

これより図８を参照すると、これは、ストレージアレイ５０を概略的に示し、図示のように、ターゲットサーバおよびイニシエータサーバ（図１０に示す）が、シングルパスまたはマルチパス接続を通じて通信するように構成される。いくつかの実施形態によれば、論理接続（垂直のチューブ状の線として示される）により、ターゲットサーバとイニシエータサーバは通信し、データストレージから論理ユニット番号（ＬＵＮ）を消費できるようになる。いくつかの実施形態によれば、イニシエータサーバは、ネットワークインターフェースカード（ＮＩＣ）または任意の適切なコンポーネント／プロトコルを使用してターゲットサーバからＬＵＮを消費するように構成される。いくつかの実施形態によれば、ＬＵＮの消費／転送に使用されるプロトコルは、ｉＳＣＳＩ、ＮＶＭｅなどといった標準的な通信プロトコルである。いくつかの実施形態によれば、ストレージアレイ５０は、両方のデータ方向を制御しながら、自動化されたオーケストレーション手順を使用することによって、このデータ転送を制御することを可能にする。いくつかの実施形態によれば、ブロックデバイス（複数可）／ＬＵＮを公開および消費する手順は、オーケストレータ７０２（図１０に示す）によって実行されるように指定される。

これより図９を参照すると、これは、ストレージアレイ５０の一部を形成することができるマルチパスストレージアレイ６０の様々な接続の概略図となる。図示のように、マルチパスストレージアレイ６０は、ホストバスアダプタ（ＨＢＡ）（または同等のＮＩＣ）を使用して転送ブロックデバイスを構成する様々なスイッチおよびアダプタを備える。いくつかの実施形態によれば、これは、複数のネットワーク接続を提供する２つのパスを形成することによって実行され得る。いくつかの実施形態によれば、両方のスイッチは互いに接続されてもよい（図示せず）。

これより図１０を参照すると、これは、ストレージシステム５０によって実行されるサーバ間の接続を介したリモートブロックデバイスのオーケストレーション手順７０となる。図示のように、１つのソースサーバ７００からのリモートブロックデバイス（複数可）は、別の宛先サーバ７０４に接続され、例えばスタッキング目的のために指定され得る一方、集中型オーケストレータ７０２は、リモートブロックデバイスの接続を調整するように構成される。

いくつかの実施形態によれば、リモートブロックデバイスは、マルチパス接続を使用してサーバ７０４に公開され、転送されるように構成される。いくつかの実施形態によれば、オーケストレータ７０２はまた、アラートを提供し、様々な障害を処理するように構成される。いくつかの実施形態によれば、コントローラ７０２は、ＲＡＩＤなどのスタッキングを可能にするために、サーバ７００または７０４のいずれかにおけるリモートブロックデバイスの特定のブロックデバイス名を識別するように構成される。

いくつかの実施形態によれば、サーバ７００は、サーバ７００が様々なプロトコルを使用して他のサーバに接続できるようにする通信プロトコルである、ネットワークのルールおよび接続性のルールデータベースを有するように構成される。いくつかの実施形態によれば、オーケストレーション手順７０は、使用しているオーケストレーション手順７０を形成するコンポーネントをオーケストレータ７０２にマッピングすることによって、特定のブロックデバイスをサーバ７０４に送信することを可能にする。いくつかの実施形態によれば、オーケストレータ７０２は、例えばＮＶＭｅ、Ｉｓｃｓｉなど、サーバ７００と７０４の間での通信を行う際に最も効率的である通信プロトコルを判定するために、該ネットワークのルールおよび接続性のルールを検討するように構成される。

いくつかの実施形態によれば、ネットワークのルールのセットは、データトラフィックに使用されるＩＰネットワークを識別するように指定される。いくつかの実施形態によれば、接続性のルールのセットは、サーバ７００と７０４の間の好ましいプロトコルを識別するように指定される。いくつかの実施形態によれば、オーケストレータ７０２は、各サーバの異なるネットワークのルールおよびそのアドレスを列挙するように構成されている。いくつかの実施形態によれば、オーケストレータ７０２は、列挙の情報、ネットワークのルール、および接続性のルールを使用して、各サーバでどのネットワークカードを使用するか、各サーバでどのアドレスを使用するか、およびどのストレージプロトコルを使用するかを決定するように構成される。

いくつかの実施形態によれば、ソースサーバ７００に記憶されたブロックデバイスは、ソースサーバ７００のＤＰネットワークへのストレージターゲットを有していながら、最初に公開されるように指定される。いくつかの実施形態によれば、宛先サーバ７０４のネットワークパスごとに複数のイニシエータが作成されるように構成される。いくつかの実施形態によれば、マルチパス接続は、宛先サーバ７０４のイニシエータを通して利用されるように構成される。

いくつかの実施形態によれば、オーケストレータ７０２は、宛先サーバ７０４のイニシエータおよびマルチパスコンポーネントのエラーを定期的に確認するように構成され、エラーが識別された場合、アラートがトリガされ、ユーザまたはアプリケーションによって処理される。

いくつかの実施形態によれば、宛先サーバ７０４のブロックデバイス名は、例えばＨＢＡアドレス、ＬＵＮなど、ソースターゲットアドレスからの情報を使用して識別されるように指定される。

いくつかの実施形態によれば、ストレージアレイ５０／６０／７０は、リモートサーバ間のリモート通信および識別を提供するように構成され、さらに、マルチパスの使用中にネットワークエラーを識別し、オーケストレータ７０２を利用しながらこの手順を実行するように構成されている。いくつかの実施形態によれば、ストレージアレイ５０は、シングルパス接続を使用することによって動作可能であり得る。

いくつかの実施形態によれば、オーケストレーション手順７０の監視は、監視の中央プロセスによって実行される。例えば、オーケストレータ７０２は、ストレージアレイ５０全体に関する誤動作を認識することができ、これにより、例えば、利用可能な二次データパス、冗長性の決定、バックアップの検討などが提供され得る。

いくつかの実施形態によれば、オーケストレーション手順７０は、システムを構成する様々なブロックデバイスの識別プロセスを可能にするように構成される。この手順は、ターゲットサーバ７００とイニシエータサーバ７０４の両方によって利用されるように構成されている。従来の方法は、再スキャン手順を実行することによってシステムに接続された新しいハードウェアを識別するために、長い認識プロセスを必要としているが、いくつかの実施形態によれば、オーケストレーション手順７０は、例えばオーケストレータ７０２に公開される様々なＩＰアドレスにより、デバイスを認識することを可能にする、迅速な再スキャン手順などを可能にする。いくつかの実施形態によれば、オーケストレーション手順７０は、ストレージシステム５０を制御および管理するために、様々な範囲または「ホワイトリスト」または「ブラックリスト」を提供するように構成される。いくつかの実施形態によれば、ＲＡＩＤフォルダなどのリモートドライブは、データの冗長性とバックアップサービスを提供するように構成されている。いくつかの実施形態によれば、ＲＡＩＤが分散化／非集中化されているため、いくつかのバックアップおよび冗長性のスキームが適用され得る。いくつかの実施形態によれば、オーケストレーション手順は、障害が生じたストレージの再構築を担う。

いくつかの実施形態によれば、ドライブの分散的な使用は、障害の検出、ホットスペアの割り当て、各ＲＡＩＤの再構築のプロセス、および各ＲＡＩＤからの不良なドライブのフェイルの際に、特別な調整を必要とする。

これより図１１を参照すると、これは、ホットスペア８０を有する従来のＲＡＩＤ５となる。図示のように、ＲＡＩＤ５にはパリティ（ストレージシステムのエラーを検出する一般的な方法）があり、影響を受けていない残りのディスクを結合することで、特定のストレージディスクを再構築できる。パリティは、様々な理由で失われた欠損データを再構築できる複数のディスク間の組み合わせであり、このようにデータ再構築機能を提供する。該システムは、スペアの空のデータを提供するように構成されたスペアディスクを含むこともできる。

これより図１２を参照すると、これは、従来のＲＡＩＤ５／ＲＡＩＤ１＋０ホットスペア再構築８１となる。図示のように、再構築プロセスは、ＲＡＩＤの全フォルダからのパリティを利用して実行される相互の読み取りを使用して再実行でき、ＲＡＩＤ１＋０では、データは二重に保存され、そのため、パリティは必要ではなく、読み取りが、関連データを保存するドライブを利用することにより実行される。

これより図１３を参照すると、これは、ＲＡＩＤシステム８２における従来の交換プロセスとなり、図示のように、ホットスペアディスクは、スペアディスクと交換するように構成されている。このプロセスには、交換用の空きのスペアディスクが必要である。

これより図１４を参照すると、これは、共有ドライブの監視および復旧動作または非集中型再構築システムおよびプロセス８３の概要となっており、図示のように、サーバ８００は、ディスク１およびスペアディスク２を備え、サーバ８０２は、ディスク３を備え、サーバ８０６は、ＲＡＩＤ（ボリューム）１を備え、サーバ８０８は、ＲＡＩＤ（ボリューム）２を構え、すべてが結合されて共有ドライブのストレージスタックを形成する。いくつかの実施形態によれば、オーケストレータ８０４は、故障の場合にディスク１およびディスク３を再構築するように指定される。例えば、ディスク１が故障した場合、ディスク２は、ＲＡＩＤに記憶されたデータを使用して再構築されるべきであり、この場合、サーバ８０６および８０８は、組み合わせられた調整動作を適用することによって、故障したディスク２を共にかつ同時に再構築するように構成される。

いくつかの実施形態によれば、サーバ８０６は、例えば「スポット」のデータ部分を構築し、サーバ８０８は「ストライプ」のデータ部分を構築する。いくつかの実施形態によれば、このプロセスは複雑であり、とりわけ他のステップがある中でも、故障したディスクを外し、スペアディスクを接続することを含む。

いくつかの実施形態によれば、システムおよびプロセス８３は、共有ドライブを使用する分散型ストレージが、組み合わせて調整された方法で故障したドライブを処理できるように構成されている。

いくつかの実施形態によれば、ドライブに亘り単一のＲＡＩＤコントローラを有するストレージアレイとは異なり、システムおよびプロセス８３は、異なるサーバで同じドライブを共有する複数のＲＡＩＤコンポーネントを有する分散型ストレージスタックを表す。

いくつかの実施形態によれば、該共有されたドライバのストレージスタックの分散された使用は、障害の検出、ホットスペアディスクの割り当て、各ＲＡＩＤの再構築のプロセス、および各ＲＡＩＤからの不良なドライブの故障などの際に、特別な調整を必要とし得る。

いくつかの実施形態によれば、共有ドライブのストレージスタックは、システムおよび動作８３によって提供され、ディスクの通常の動作を維持するように指定された集中型オーケストレータ８０４によって監視される。

いくつかの実施形態によれば、共有ドライブのストレージスタックが提供され、集中型オーケストレータ８０４は、故障したディスクを使用するように指定されたすべてのサーバ８００～８０８によって使用されるホットスペアディスクを割り当てるように構成される。

いくつかの実施形態によれば、共有ドライブのストレージスタックは、故障したディスクが検出されたときに、集中型オーケストレータ８０４を利用することによって、復旧アクションを実行するように構成される。

いくつかの実施形態によれば、ドライブの障害は、完全な障害である場合もあれば、特定の論理ブロックの範囲の障害である場合もある。システムおよび動作８３のように、複数のサーバ間でドライブを共有するように構成された分散型ストレージスタックでは、一部のサーバのみがエラーに遭遇し得、対して他のサーバはドライブを十分に機能しているものとみなす。

いくつかの実施形態によれば、システムおよび動作８３は、集中型オーケストレータ８０４によるサーバのイニシエータおよびＲＡＩＤレベルのそれぞれの監視を可能にし、ドライブが障害に遭遇した場合に単一の集中決定を下す能力を提供する。

いくつかの実施形態によれば、ストレージプールからのホットスペアディスクの割り当ては、集中型オーケストレータ８０４で、またはそれによって動作されるため、故障したドライブを使用するすべての異なるサーバ（８００～８０８）は、同じ新しいスペアディスクを使用することになる。

いくつかの実施形態によれば、例として、システムおよび動作８３によって利用されるように構成された再構築プロセスは、以下のステップを使用して実行され得る。
● 各サーバ（８００～８０８）のイニシエータ層は、ブロックデバイスの健全性（Ｉ／Ｏエラーや応答時間など）について監視される。
● オーケストレータ８０４は、全サーバのドライブの健全性の情報を蓄積するように構成されている。
● オーケストレータ８０４は、ドライブの障害を認識するように構成されている。
● オーケストレータ８０４は、ストレージプールから新しいホットスペアディスクを割り当てるように構成されている。
● オーケストレータ８０４は、選択されたスペアディスクを各ＲＡＩＤコンポーネントに追加するように各サーバ（８００～８０８）に指示するように構成されている。
● オーケストレータ８０４は、各サーバ（８００～８０８）に、各ＲＡＩＤコンポーネントの障害が発生したディスクをフェイルさせるように指示するように構成されている。
● 各サーバ（８００～８０８）のＲＡＩＤは、ドライブフェイルプロセスを実行し、有効なデータで新しいスペアドライブチャンクを再構築するように構成されている。有効なデータは、可能であればフェイルされたドライブから、またはＲＡＩＤミラー／パリティから使用されるように構成されている。
● オーケストレータ８０４は、各サーバＲＡＩＤコンポーネントの再構築プロセスを監視するように構成されている。
● 各サーバ（８００～８０８）のすべてのＲＡＩＤがフェイルされたドライブチャンク（複数可）の再構築を完了すると、フェイルされたドライブはオフラインになり、ユーザはそれを交換するように指示される。

整合性グループは、アプリケーションを表すボリュームのグループである。ウイルスによって引き起こされる可能性のある障害のインスタンスでは、整合性グループのスナップショットは、整合性グループのすべてのボリュームと一致する、障害が発生する前の正確な瞬間をキャプチャするように構成される。

これより図１５を参照すると、これは、従来の整合性グループスナップショットシステム８４の概要となる。図示のように、３つのボリュームｖ１、ｖ２、およびｖ３がグループ「ｃｇ１」を作成し、１つ以上のアプリケーションを表し得る１つの整合性グループに属する。特定の時点でスナップショットが取得され、すべてのボリュームグループのスナップショットである「ｓｇ２」が作成される。すべてのボリュームが同じ場所に配置されているため、スナップショットは集中型コントローラを使用して取得される。

これより図１６を参照すると、これは、本発明のいくつかの実施形態による、分散型スナップショット整合性グループシステム８５の概要となる。図示のように、各サーバ９００、９０２、および９０６は、それ自体のＤＰを管理するように構成され、それ自体のＬＶＮおよびメディアストレージを備える。言い換えれば、ＣＰは集中型であるが、ＤＰは集中型ではない。

前に開示したように、システム８５は、複数のサーバにおけるボリュームのディストリビューションが整合性グループでスナップショットを形成し、特定の時点でのボリュームの集合のコピーを確保することを可能にする。

いくつかの実施形態によれば、オーケストレータ９０４は、スナップショットの取得を調整するように構成され、ＣＰを使用して整合性グループのスナップショットの取得を調整することができる。いくつかの実施形態によれば、Ｉ／Ｏの一時停止および機能性の再開が、整合性のあるスナップショットを実施するために使用され得る。

いくつかの実施形態によれば、図１６に示す整合性グループ８５では、サーバ９００はボリューム１を備え、９０２はボリューム２を備え、９０６はボリューム３を備える。例えば、オーケストレータ９０４は、ボリューム１とファイルシステム間のＩ／Ｏの動作を停止するように構成され得る。

いくつかの実施形態によれば、そのような例示されたコンステレーションにおける整合性グループのスナップショットを取得することは、以下のステップを含むことになる。
● オーケストレータ９０４は、ボリューム１へのＩ／Ｏを一時停止するようにサーバ９００に指示することができる。
● オーケストレータ９０４は、ボリューム２へのＩ／Ｏを一時停止するようにサーバ９０２に指示することができる。
● オーケストレータ９０４は、ボリューム３へのＩ／Ｏを一時停止するようにサーバ９０６に指示することができる。
● オーケストレータ９０４は、すべてのサーバが一時停止を確認するまで待機するように構成されており、短いタイムアウト後にサーバが応答しなかった場合、スナップショットはキャンセルされ、Ｉ／Ｏは再開される。
● オーケストレータ９０４は、サーバ９００のＬＶＭにボリューム１のスナップショットを作成するように指示することができる。
● オーケストレータ９０４は、サーバ９０２のＬＶＭにボリューム２のスナップショットを作成するよう指示することができる。
● オーケストレータ９０４は、サーバ９０６のＬＶＭにボリューム３のスナップショットを作成するよう指示することができる。
● オーケストレータ９０４は、すべてのサーバがスナップショットを確認するまで待機し得、短いタイムアウト後にサーバが応答しなかった場合、スナップショットはキャンセルされ、スナップショットは削除され、Ｉ／Ｏは再開される。
● オーケストレータ９０４は、サーバ９００のボリュームに、ボリューム１へのＩ／Ｏを再開するように指示する。
● オーケストレータ９０４は、サーバ９０２のボリュームに、ボリューム２へのＩ／Ｏを再開するように指示する。
● オーケストレータ９０４は、サーバ９０６のボリュームに、ボリューム３へのＩ／Ｏを再開するように指示する。

いくつかの実施形態によれば、いくつかの該動作は、スナップショットの時間を短縮するために並行して実行され得る。

いくつかの実施形態によれば、すべてのボリューム（図１６のボリューム１、２、および３）でＩ／Ｏが一時停止され、その後にのみスナップショットが取得されるため、整合した時点を有するスナップショットが生成される。これは、従来のシステムでは集中型アレイのみにリザーブされていた分散型ボリュームの機能性を作成することによって実現される。

いくつかの実施形態によれば、オーケストレータ９０４は、サーバの１つが誤動作するかタイムアウトした場合に、整合性グループスナップショットからバックオフすることができる。

いくつかの実施形態によれば、オーケストレータ９０４は、分散型ボリュームの整合性グループのスナップショットを削除する、分散型ボリュームの整合性グループのスナップショットをロールバックする、整合性グループを有する分散型ボリュームのスナップショットをスケジュールするなどを行うように構成される。

これより次に図１７を参照すると、これは、ストレージアレイシステム８６における従来のストレージＱｏＳの概要となる。図示のように、図面の右側には３つのボリュームが表示されており、それぞれがストレージオブジェクト／ボリュームを制御するＱｏＳを提供する異なるＩＯＰＳレート管理を有し、その結果、すべてのアプリケーション／ボリュームは、システムのパフォーマンスの向上につながる可能性のあるシステムリソースの管理対象部分を受け取る。図面の左側には、ＱｏＳのないシステムが表示され、このシステムでは、すべてのアプリケーション／ボリュームが一般的な管理を行わずに共通のリソースを消費するため、システム全体のパフォーマンスに悪影響を与える可能性がある。

これより図１８を参照すると、これは、ボリューム間の従来のストレージＱｏＳシステム８７の概要となる。図示のように、ＱｏＳがないと、すべてのアプリケーション／ボリュームが一般的な管理を行わずに共通リソースを消費するため、システム全体のパフォーマンスに悪影響を与える可能性がある。ＱｏＳを使用すると、すべてのアプリケーション／ボリュームがシステムリソースの管理対象部分を受け取り、システムのパフォーマンスの向上につながる可能性がある。

これより図１９を参照すると、これは、共有ドライブを備えた分散型ストレージスタックにおいてＱｏＳを強化するための設計を提供する共有のドライブストレージスタックの分散型ＱｏＳシステム８８の概要となる。図示のように、共有ボリュームは、様々なボリュームまたはサーバ１０００、１００２、および１００６から構築される。いくつかの実施形態によれば、各サーバは、分散型ＱｏＳ制限（ターゲットとＬＶＭとの間にインストールされる）を備え、集中型オーケストレータ１００４は、各サーバのＱｏＳによって適用される数学的制限を制御するように構成される。

いくつかの実施形態によれば、書き込み手順が実行されると、ＱｏＳの制限には複雑な計算が必要であり、オーケストレータ１００４は、例えば、ＲＡＩＤスキームに従って該計算を実行することによって、このタスクを提供するように適合される。

いくつかの実施形態によれば、オーケストレータ１００４は、ＱｏＳ ＣＰを調整するように構成され、一方、各サーバはローカルＱｏＳ ＤＰを実施する。いくつかの実施形態によれば、共有のドライブストレージスタックが提供され、従来の集中型ストレージアレイと同等のＱｏＳ機能性を可能にする。

いくつかの実施形態によれば、共有のドライブストレージスタックは、オーケストレータ１００４が各ジャンクションにおけるＱｏＳ制限を調整するように構成される設計で提供される。

いくつかの実施形態によれば、特定のボリュームに対してＱｏＳを実施することが要求されると、オーケストレータ１００４は、そのボリュームに使用されるＲＡＩＤスキームに基づいて、各バックエンドドライブの必要なＱｏＳを計算するように構成され、その後、オーケストレータ１００４は、使用されるＣＰに、各サーバ１０００、１００２、および／または１００６の各ドライブ／ボリュームのＱｏＳ制限を分散させる。

いくつかの実施形態によれば、ＲＡＩＤ０、ＲＡＩＤ１、およびＲＡＩＤ５は、異なるＱｏＳの計算を必要とする。以下の例は、ＲＡＩＤスキームに基づいた計算を表している。
● ＲＡＩＤ０では、ＩＯＰＳと帯域幅はアレイのドライブ要素の数で除算される。
● ＲＡＩＤ１では、要求に応じて各ドライブに対してＩＯＰＳと帯域幅が設定される。
● ＲＡＩＤ１０では、ＩＯＰＳと帯域幅はアレイのドライブ要素の数で除算され、レジリエンスセットで除算される。
● ＲＡＩＤ５では、帯域幅はドライブ数で除算して１を減算した値になる。ＩＯＰＳはドライブ数で除算して３を乗算する。

いくつかの実施形態によれば、サーバ１０００、１００２、および１００６のボリュームが共有ボリュームグループの一部である場合、オーケストレータ１００４は、グループの各ボリューム要素のＩＯＰＳおよび帯域幅制限を合計するように構成される。いくつかの実施形態によれば、結合された数は、バックエンドドライブ／ボリュームに適用されるように構成される。いくつかの実施形態によれば、ボリューム制限を実施するために、別のＱｏＳ層をローカルサーバに追加することができる。

いくつかの実施形態によれば、ボリュームが共有されたボリュームグループに追加されると、オーケストレータ１００４は、制限を再計算し、各ＱｏＳ要素を更新するように構成される。いくつかの実施形態によれば、ボリュームが共有されたボリュームグループから削除されると、オーケストレータ１００４は、制限、および各ＱｏＳ要素の更新を再計算するように構成される。

いくつかの実施形態によれば、複数のイニシエータが、各サーバ１０００、１００２、および１００６へのネットワークパスごとに作成されるように構成される。

これより図２０を参照すると、これは、従来のクローンシステムを備えたエンタープライズストレージアレイ８９の概要となる。図示のように、サーバ１００７は、スナップショットのクローン作成を実行し、クローンサーバ１００８に記憶されるスナップショットバージョンを作成するようにさらに構成されたアプリケーションデータを使用してデータのクローンを作成するように構成された生産サーバである。ディスクのクローン作成は、パーティションまたはハードドライブ全体のイメージを作成するプロセスである。これは、ドライブを他のコンピュータにコピーすること、およびバックアップや復旧の目的で有用であり得る。

これより図２１を参照すると、これは、未割り当てデータによるボリューム全体のクローン作成システム９０の概要となる。図示のように、左から右にクローン作成されるボリュームは部分的に空になり、クローンが作成されると、クローンのボリュームの一部も空のままである。

これより図２２を参照すると、これは、本発明のいくつかの実施形態による、リモートオンラインボリュームのクローンの分散型システム９１の概要となる。図示のように、システム９１は、ネットワークを通して、あるソースサーバ１００９から別の宛先サーバ１０１１へのボリュームのクローン作成を可能にするが、一方で、ボリュームがオンラインであり、オーケストレータ１０１０が両方のサーバにＣＰを通してクローンプロセスを調整するように構成され、ソースボリューム（サーバ１００９に属する）の割り当てられたブロックのみがコピーされている。

いくつかの実施形態によれば、オーケストレータ１０１０は、データ割り当てをクエリし、それをコピービットマップとして宛先サーバ１０１１に渡すように構成される。いくつかの実施形態によれば、オーケストレータ１０１０は、ＣＰを介してサーバ間のボリュームクローン作成を調整するように構成される。いくつかの実施形態によれば、オーケストレータ１０１０は、サーバ１００９のソースボリューム上の割り当てられたブロックをクエリし、コピーするブロックを宛先サーバ１０１１に指示するように構成されている。

いくつかの実施形態によれば、サーバ１００９のソースボリューム内の割り当てられたブロックのみがコピーされる。オーケストレータ１０１０は、割り当てデータをクエリし、それをコピービットマップとして宛先サーバ１０１１に渡すように構成されている。いくつかの実施形態によれば、オンラインボリュームのクローンを作成するために、ソースサーバ１００９の論理ボリュームマネージャ（ＬＶＭ）を使用して、ソースボリュームのある時点のスナップショットを作成する。

いくつかの実施形態によれば、ＲＡＩＤ１は、ゼロコピーで変換された変更ビットマップを使用して、ボリュームのカーネル内コピーに使用することができる。いくつかの実施形態によれば、ユーザ空間コマンドはまた、コピーに使用することができる

いくつかの実施形態によれば、例として、図２２に示されるシステム９１は、以下のステップを使用してリモートクローンを実行および実証するように構成され得る。
● オーケストレータ１０１０は、サーバ１００９のＬＶＭコンポーネントにソースボリュームのある時点のスナップショットを作成するよう要求する。
● オーケストレータ１０１０は、サーバ１００９のターゲットコンポーネントにソースボリュームのスナップショットをネットワーク経由で公開するよう要求する。
● オーケストレータ１０１０は、サーバ１０１１のイニシエータコンポーネントに対して、ネットワーク経由で第１のアダプタを介して公開されたボリュームに接続するように要求する。
● オーケストレータ１０１０は、サーバ１０１１のイニシエータコンポーネントに対して、ネットワーク経由で第２のアダプタを介して公開されたボリュームに接続するように要求する。
● オーケストレータ１０１０はサーバ１０１１のマルチパスコンポーネントに、２つのイニシエータを介してソースボリュームスナップショットへの信頼できる接続を作成するよう要求する。
● オーケストレータ１０１０はサーバ１０１１に、空の宛先ボリュームの作成を要求する。
● オーケストレータ１０１０は、カーネル内でのレプリケート用のＲＡＩＤ１の作成をサーバ１０１１に要求する。リモートソースボリュームスナップショットとローカル宛先はＲＡＩＤ１メンバーとして追加できる。
● オーケストレータ１０１０は、ソースボリュームのスナップショットの割り当てチャンクをサーバ１００９にクエリする。
● オーケストレータ１０１０は、ソースボリュームのスナップショットの割り当てチャンクを、ＲＡＩＤ１レプリケーションへのビットマップとしてサーバ１０１１に渡す。
● オーケストレータ１０１０は、サーバ１０１１のＲＡＩＤ１コンポーネントの進行状況を監視する。
● オーケストレータ１０１０は、サーバ１０１１のＲＡＩＤ１のコピーが完了するのを待機する。
● オーケストレータ１０１０はサーバ１０１１にＲＡＩＤ１コンポーネントの削除を要求する。
● オーケストレータ１０１０はサーバ１０１１にマルチパスコンポーネントの削除を要求する。
● オーケストレータ１０１０はサーバ１０１１にアダプタ１のイニシエータを削除するよう要求する。
● オーケストレータ１０１０はサーバ１０１１にアダプタ２のイニシエータを削除するよう要求する。
● オーケストレータ１０１０は、サーバ１００９に対して、公開されたソースボリュームのスナップショットのターゲットを削除するように要求する。
● オーケストレータ１０１０は、サーバ１００９に、ＬＶＭボリューム１のスナップショットの削除を要求する。

これより図２３を参照すると、これは、ボリューム部分を割り当てるように構成された従来の論理ボリュームマネージャ（ＬＶＭ）９２を概略的に示す。図示のように、論理ボリュームから物理ボリュームへの変換中に割り当てとデータ転送が実行され、同じサーバで接続および使用されるＬＶＭを作成する。

これより図２４を参照すると、これは、ボリューム部分を割り当てるように構成された従来のＬＶＭ９２の別の図（９３として記されている）を概略的に示す。図示のように、論理ボリュームから物理ボリュームへの変換中に割り当ておよびデータ転送が実行され、同じサーバで接続および使用されるＬＶＭを作成する。

これより図２５を参照すると、これは、従来の論理ボリュームエクステントおよびメタデータシステム９４を概略的に示す。図示のように、Ｉ／Ｏは物理エクステントをＬＥからＰＥにマッピングし、論理チャンクと物理チャンクの間の内部マッピングを担うように構成されている。

これより図２６を参照すると、これは、システムサーバ９５間の従来の共有ストレージを概略的に示す。

これより図２７を参照すると、これは、従来のクラスタ化された論理ボリュームマネージャ９６を概略的に示す。図示のように、同じ共有ストレージを共有するサーバのバッチ、それらの間の同期は、クラスタシステムを使用して実行される。

これより図２８を参照すると、これは、いくつかの実施形態による、クラスタのない分散型論理ボリュームマネージャシステム９７を概略的に示す。図示のように、分散型ＬＶＭは、クラスタリングの動作を必要としない共有ストレージに提供される。

いくつかの実施形態によれば、集中型オーケストレータ１０１７は、共有ストレージの分散型論理ボリュームマネージャに亘るエクステントの割り当てを制御するように構成される。

いくつかの実施形態によれば、システム９７は、クラスタを使用せずに共有バックエンドストレージでＬＶＭ１０１８などを適用し、実行する間に、該サーバ間でメタデータの整合性を維持するように構成される。

いくつかの実施形態によれば、集中型オーケストレータ１０１７は、分散型ＬＶＭを管理する唯一のリソースとなるように構成される。オーケストレータ１０１７はさらに、分散型ＬＶＭの並列動作をキューに入れ、一度に１つの動作のみが実行されるのを確実にするように構成される。

いくつかの実施形態によれば、オーケストレータ１０１７は、バックエンドストレージおよびＬＶＭを共有するすべてのサーバ１０１５、１０１６、１０１８などにＬＶＭエクステント割り当てコマンドを送信し、ＲＡＭのキャッシュされたメタデータがすべてのサーバに亘って整合性があることを保証するように構成される。

いくつかの実施形態によれば、オーケストレータ１０１７は、ＬＶＭエクステントの割り当て／割り当て解除を必要とするすべての動作を次のように調整するように構成される。
● ボリュームの作成
● ボリュームの削除
● ボリュームのサイズ変更

システム９７は、すべてのサーバのＬＶＭを制御する集中型コントローラを示している。一方、ボリューム２のサイズがどのように変更されるかは、次のように示され得る。

● ボリューム２のサイズを変更する要求が、サーバ１０１６に送信される。
● オーケストレータ１０１７は、他のＬＶＭエクステント動作がオーケストレータ１０１７で応答を待機しているかどうかを確認する。
● ＬＶＭで実行されている待機中の要求がある場合、オーケストレータ１０１７は要求をキューに入れる。
● オーケストレータ１０１７は、ボリューム２のサイズを変更する要求をサーバ１０１６に送信する。
● オーケストレータ１０１７は、キャッシュされたメタデータが整合性があることを確実にするために、ボリューム２のサイズを変更する要求をサーバ１０１５に送信する。

いくつかの実施形態によれば、オーケストレータ１０１７は、キャッシュされたメタデータが整合性があることを確実にするために、ボリューム２のサイズを変更する要求をサーバ１０１８に送信するように構成される。

これより図２９を参照すると、これは、ＳＣＳＩバスシステム９８の従来のレイアウトの概要を概略的に示す。図示のように、論理バスはスキャンされるように構成されている。従来、これは時間のかかるプロセスである。

これより図３０を参照すると、これは、従来の複数チャネルの論理ユニットシステム９９を概略的に示す。図示のように、すべてのバスをスキャンする必要性を強調する別のバスシステムが示されている。この遅いプロセスは、新たな最新の分散型システムには適合しない。

これより図３１を参照すると、これは、ＩＰネットワーク１００に亘る従来のｉＳＣＳＩバスを概略的に示す。図示のように、ネットワークバスでは、すべてのバスをスキャンするために多くの遅いプロセスを実行する必要がある。

これより図３２を参照すると、これは、本発明のいくつかの実施形態による、再スキャンを伴わない調整されたリモートデバイスアタッチメントシステム／プロセス１０１を概略的に示す。図示のように、分散型システム１０１では、作業負荷がサーバからサーバに移動し得て、ボリュームもそれに伴って移動するはずである。オーケストレータ１０２１がシステムの両側、つまり公開側と消費側を制御するため、システム１０１は異なって実行することができる。例えば、オーケストレータ１０２１はサーバ１０１９に接続されており、そのバスパラメータを備えており、それが全サーバに接続されているため、再スキャンの必要なく、システムのすべてのサーバ（１０１９、１０２０、１０２２など）からバスの位置情報を特定して渡すことができる。

いくつかの実施形態によれば、システム１０１は、バススキャンを全く行わずに、リモートストレージデバイスを、別のサーバに、迅速に接続できるようにする。

いくつかの実施形態によれば、オーケストレータ１０２１は、デバイスのアタッチメントを調整し、特定のバスＩＤのターゲットをセットアップし、イニシエータに必要なバスＩＤを提供するように指定される。イニシエータはバスＩＤを使用してデバイスをオペレーティングシステムに接続する。いくつかの実施形態によれば、すべての情報がオーケストレータ１０２１から、またはこれによって保持され、提供されるため、スキャンは必要ない。

いくつかの実施形態によれば、デバイスが公開されていない場合、オーケストレータ１０２１は、特定のバスＩＤを有するターゲットからそれを削除するように構成され、特定のバスＩＤのデバイスをオペレーティングシステムから削除するようにイニシエータに指示する。

いくつかの実施形態によれば、リモートボリュームは、オーケストレータ１０２１によって調整されるイニシエータバススキャンなしで、ターゲットサーバ（１０１９、１０２０）によって公開され、イニシエータサーバ１０２２によって消費され得る。

いくつかの実施形態によれば、リモートボリュームは、オーケストレータ１０２１によって調整されるイニシエータバススキャンなしで、それぞれターゲットサーバ（１０１９、１０２０）およびイニシエータサーバ１０２２の内部に存在するターゲットおよびイニシエータによって削除され得る。

いくつかの実施形態によれば、オーケストレータ１０２１は、デバイスのアタッチメントを調整し、特定のバスＩＤのターゲットをセットアップし、イニシエータに必要なバスＩＤを提供するように構成される。いくつかの実施形態によれば、イニシエータはバスＩＤを使用してデバイスをオペレーティングシステムに接続する。すべての情報は既知であり、オーケストレータ１０２１から渡されるため、スキャンは必要ない。

いくつかの実施形態によれば、デバイスが公開されていない場合、オーケストレータ１０２１は、特定のバスＩＤを有するターゲットからそれを削除し、特定のバスＩＤのデバイスをオペレーティングシステムから削除するようにイニシエータに指示する。

いくつかの実施形態によれば、イニシエータサーバ１０２２のデバイス名は、例えば、その上に他のストレージコンポーネントをスタックすることを可能にするために、バスＩＤも使用して検出されるように構成される。

いくつかの実施形態によれば、システム１０１は、例えば、新しいリモートデバイスを接続するように構成されている。
● オーケストレータ１０２１はサーバ１０１９に接続し、そのターゲット構成を読み取る。
● オーケストレータ１０２１は、サーバ１０１９の構成でサーバ１０２２の空きの論理ユニット番号（ＬＵＮ）を見つける。
● オーケストレータ１０２１は、ＬＵＮ ＩＤを使用してサーバ１０２２に新しいターゲットを設定する。
● オーケストレータ１０２１はサーバ１０１９のＨＢＡのアドレスを確認する。
● オーケストレータ１０２１は、サーバ１０２２でサーバ１０１９のＨＢＡのアドレスのターゲットＩＤを見つける。
● オーケストレータ１０２１は、オペレーティングシステムで使用するために、ＬＵＮ ＩＤとターゲットＩＤを使用してサーバ１０２２に新しいデバイスをセットアップする。
● オーケストレータ１０２１は、ＬＵＮ ＩＤとターゲットＩＤを使用して、オペレーティングシステムによって使用されるブロックデバイス名を見つける。

いくつかの実施形態によれば、リモートボリュームは、イニシエータバススキャンを必要とせずに、オーケストレータ１０２１によって行われる調整により、ターゲットおよびイニシエータによって削除され得る。

いくつかの実施形態によれば、オーケストレータ１０２１は、ターゲット情報を使用して、イニシエータオペレーティングシステムによって使用されるブロックデバイス名を特定するように構成され得る。

これより図３３を参照すると、これは、従来の自己暗号化ドライブ（ＳＥＤ）ロジック１０２を概略的に示す。図示のように、従来のＳＥＤコンポーネントは、正しいパスワードが挿入されたときにドライブがキーを提供できるように構成されている。このように、従来のアーキテクチャでは、キーとパスワードはデータと共にドライブ内に記憶される。

これより図３４を参照すると、これは、従来のプロトコルトンネル１０３を概略的に示す。図示のように、暗号化されていないシステムでデータを安全に配信するために、暗号化されたトンネルは特定のポイントから別のポイントに開かれるように構成されている。

これより図３５を参照すると、これは、システム内の２つのポイントから暗号化されたデータを配信するように構成された、２つのサーバ間のトンネルを使用する従来のペイロードカプセル化の別の表現を概略的に示す。

これより図３６を参照すると、これは、本発明のいくつかの実施形態による、トンネルによるリモート自己暗号化ドライブ制御を概略的に示す。図示のように、開示されている分散型システムは、キーをドライブとは別に記憶するように構成されている。いくつかの実施形態によれば、データはサーバ１０２３に記憶され得て、キー／パスワードはオーケストレータ１０２４に記憶され得て、システムは、トンネルを開き、ドライブ（例えば、ドライブのＲＡＭなど）に記憶する必要なくトンネルを介してキーを配信することによって、暗号化されない。いくつかの実施形態によれば、該分散型システムは、複数のキーを記憶し、複数のドライブに亘って構成されることができる。いくつかの実施形態によれば、通信はＳＥＤプロトコルを使用して行われてもよい。

いくつかの実施形態によれば、前に開示したように、該システムおよび方法は、リモートサーバからネットワークを介してトンネリング自己暗号化ドライブ（ＳＥＤ）プロトコルを利用することを可能にし、この目標は、オーケストレータ１０２４の集中型の保護されたデータベースにキーを記憶することによって達成され得る一方で、ＳＥＤプロトコルは、暗号化トンネリングを使用してネットワーク上でカプセル化される。

いくつかの実施形態によれば、自己暗号化ドライブ（ＳＥＤ）は、ローカルサーバの制御ユーティリティを必要とせずに、ＳＥＤ動作用のトンネルを介して、リモートサーバにより制御される。いくつかの実施形態によれば、自己暗号化ドライブ（ＳＥＤ）のキーは、集中型キーデータベースに記憶され、提供される。

いくつかの実施形態によれば、自己暗号化ドライブ（ＳＥＤ）のキーは、サーバのキーインメモリのエクスプロイトに公開されることなく、トンネルを介してドライブに直接通過するように構成される。

いくつかの実施形態によれば、ＳＥＤプロトコルは、暗号化されたトンネリングを使用してネットワーク上でカプセル化される。例えば、Ｌｉｎｕｘ Ｓｅｃｕｒｅｄ Ｓｈｅｌｌ（ＳＳＨ）プロトコル、Ｗｉｎｄｏｗｓ ＰｏｗｅｒＳｈｅｌｌ Ｒｅｍｏｔｉｎｇ Ｐｒｏｔｏｃｏｌ（ＰＳＲＰ）を使用する。

いくつかの実施形態によれば、ＳＥＤ通信は、特別なツールを必要とせずに、ドライブと直接行われる。例えば、ドライブとのＲＡＷ通信にはＳＣＳＩドライブ用のＬｉｎｕｘｓｇ＿ｒａｗユーティリティを使用し、ＮＶＭｅドライブにはａｄｍｉｎ－ｐａｓｓｔｈｒｕコマンドでＬｉｎｕｘ ＮＶＭｅユーティリティを使用し、Ｗｉｎｄｏｗｓ ＩＯＣＴＬ＿ＡＴＡ＿ＰＡＳＳ＿ＴＨＲＯＵＧＨ＿ＤＩＲＥＣＴを使用する。

いくつかの実施形態によれば、この新しいアプローチは、例えば、現在サーバによって使用されているローカルのＳＥＤプロトコルに比べて多くの利点を有する可能性がある。例えば、
● ＳＥＤユーティリティ（オペレーティングシステムには標準としては存在しない）をインストールして保守する必要はない。
● ローカルサーバにハードウェアセキュリティモジュール（ＨＳＭ）は必要ない。
● キーはいかなる時点でもローカルサーバに公開されることはなく、攻撃者に漏洩する、または盗まれることはない。
● キーは、論理的および物理的に遥かに簡単に保護可能な集中データベースに保存される。

いくつかの実施形態によれば、該システムは、以下のステップを使用してリモート自己暗号化ドライブ制御を提供するように構成されている。
● オーケストレータ１０２４は、キーデータベースに新しいキーを生成する。
● オーケストレータ１０２４とサーバ１０２３との間にトンネルが作成される。
● 証明書がオーケストレータ１０２４に記憶される。
● オーケストレータ１０２４とドライブの間にトンネルが作成される。
● 証明書がオーケストレータ１０２４に記憶される。
● オーケストレータ１０２４の自己暗号化ドライブプロトコルハンドラは、トンネルを介してドライブＳＥＤプロトコルコンポーネントとリモート通信する。
● ＳＥＤプロトコルハンドラは、安全な暗号化チャネルを介してキーをドライブに渡す。
● ＳＥＤプロトコルハンドラはドライブのロックを有効にする。

いくつかの実施形態によれば、該システムは、以下のステップを使用してサーバ再起動プロセス後のリモート自己暗号化ドライブ制御を提供するように構成されている。
● オーケストレータ１０２４がサーバの再起動を検出する
● オーケストレータ１０２４は、キーデータベースからサーバドライブキーをフェッチする。
● オーケストレータ１０２４とリモートサーバの間にトンネルが作成される。
● 記憶されている証明書が検証される。
● オーケストレータ１０２４とドライブの間にトンネルが作成される。
● 記憶されている証明書が検証される。
● オーケストレータ１０２４の自己暗号化ドライブプロトコルハンドラが、トンネルを介してドライブＳＥＤプロトコルコンポーネントとリモート通信する。
● ＳＥＤプロトコルハンドラが、安全な暗号化チャネルを介してキーをドライブに渡す。
● ＳＥＤプロトコルハンドラがドライブのロックを解除する。

これより図３７を参照すると、これは、従来のＲＡＩＤ１－データミラーリングシステムを概略的に示す。図示のように、バックアップＲＡＩＤ１は、データの二重バックアップを複製して保存するように構成されている。

これより図３８を参照すると、これは、従来の非同期レプリケーションシステムを概略的に示す。図示のように、バックアップのプロセス中にデータが失われない。

これより図３９を参照すると、これは、従来の同期レプリケーションシステムを概略的に示す。図示のように、レプリケーションは過去の特定の時点に制限されているが、依然として一定期間が失われる可能性があり、それでも、レプリケーションは整合性があるはずである。

いくつかの実施形態によれば、標準的なＲＡＩＤ１コンポーネントを使用して、少なくとも１つのリモートサイトにデータを複製する。一般的なＲＡＩＤ１コンポーネントは、２つのドライブ間でデータをミラーリングするために設計、構築、および使用されるが、本発明は、コンポーネントにいずれかの実質的な変更を加えることなく、ＲＡＩＤ１を使用してデータをリモートサイトに複製することを提案する。いくつかの実施形態によれば、同期レプリケーションと非同期レプリケーションの両方を使用して、ＲＡＩＤ１コンポーネントに本発明を容易にさせることができる。

いくつかの実施形態によれば、標準のＲＡＩＤ１コンポーネントを使用してリモートサイトに複製されるストレージボリュームは、同期モードで動作する。

これより図４０を参照すると、これは、本発明のいくつかの実施形態による、ＲＡＩＤ１システムを使用する同期レプリケーションを概略的に示す。図示のように、オペレーティングシステムのコンポーネントは、すべての書き込みを２つに分割し、サーバ１０２５および１０２６に記憶するために利用される。このようにして、同期レプリケーションを実現できる。いくつかの実施形態によれば、オーケストレータ（図示せず）がこの動作を管理することができる。いくつかの実施形態によれば、該サーバは互いに実質的に遠隔に配置され得る。

いくつかの実施形態によれば、ストレージスタックは、ＲＡＩＤ１コンポーネントとの同期レプリケーションに使用され、ＲＡＩＤ１が元々設計されていたサーバ１０２６、１０２７の２つのドライブを接続する代わりに、１つの物理ドライブだけがＲＡＩＤ１に接続され、一方で、少なくとも別のドライブは、マルチパス、イニシエータ、およびターゲットコンポーネントにより例示されるようなストレージコンポーネントを介してリモートディスクに接続される。

いくつかの実施形態によれば、サーバのボリュームから発生する各書き込み動作は、図３９に示すスタックを介してローカルディスクとリモートディスクの両方に書き込まれる。ＲＡＩＤ１ロジックは、通常、ディスク間でデータをミラーリングするように設計されているのに対し、本発明による変更は、２番目のディスクがリモートターゲットとしてローカルに設定されるため、このような動作によく適している。

いくつかの実施形態によれば、ネットワークの切断の場合、ＲＡＩＤ１ビットマップは、同期していなかった変更を追跡し、リモートサーバが接続されたときにそれらを同期し直す。このような動作は、事実上、ミラードライブの引き抜きに対して動作するＲＡＩＤ１と同じになる。

本発明の別の実施形態では、リモートサイトに複製されるストレージボリュームは、非同期モードで、ＲＡＩＤ１コンポーネントと結合されたＬＶＭスナップショットを使用する。

これより図４１を参照すると、これは、本発明のいくつかの実施形態による、ＬＶＭスナップショットおよびＲＡＩＤ１を使用するサーバ１０２７と１０２８との間の非同期レプリケーション手順を概略的に示す。

いくつかの実施形態によれば、非同期レプリケーションに使用されるストレージスタックはＲＡＩＤ１コンポーネントである。スナップショットには論理ボリュームマネージャ（ＬＶＭ）が使用される。スナップショットは、特定の時点での変更をグループとして同期するために必要である。いくつかの実施形態によれば、以前の同期からの変更は、ＬＶＭスナップショットの差分によって、またはストレージスタック追跡層、例えば、Ｌｉｎｕｘにおけるｄｍ－ｅｒａなどによって追跡される。

いくつかの実施形態によれば、以前の同期からの変更はＲＡＩＤ１ビットマップに変換され、ＲＡＩＤ１コンポーネントに送信される。

いくつかの実施形態によれば、同期レプリケーションと同様に、ＲＡＩＤ１の１つのレッグはローカルＬＶＭスナップショットに接続され、少なくとも別のドライブは、マルチパス、イニシエータ、およびターゲットコンポーネントによって例示されるようなストレージコンポーネントを介してＬＶＭスナップショットを削除するために接続される。

いくつかの実施形態によれば、ＲＡＩＤ－１が再同期を試みるとき、ビットマップ情報により、ＲＡＩＤ１はローカルスナップショットから変更されたデータを読み取り、それをサーバ２のリモートスナップショットに書き込むことができる。非同期レプリケーションネットワークが切断された場合、ビットマップがＲＡＩＤ１のコンポーネントによって更新され続けるので、再開することができる。いくつかの実施形態によれば、リモートサイトのスナップショットにより、完了しなかった部分的なレプリケーションのロールバックが可能になる。いくつかの実施形態によれば、ＲＡＩＤ１およびＬＶＭコンポーネントのカーネル実装は、コピーゼロ、高い帯域幅、低いＣＰＵ使用率、およびコンテキストスイッチがなく、ネットワークを介して１つのローカルボリュームスナップショットとリモートボリュームスナップショットを接続することを保証する。

いくつかの実施形態によれば、非同期レプリケーション手順は、ＬＶＭスナップショットデルタメタデータまたは変更追跡情報を使用して、最後の非同期レプリケーションからの変更を追跡するように構成される。変更リストをＲＡＩＤ１ビットマップに変換し、最後の非同期動作からの変更のみを複製する。

本発明の別の態様によれば、ＬＶＭにおけるスペースの割り当ては、シック割り当てエクステントグループが割り当てられながら、一般に実施されるシンプロビジョニングと同様の漸進的な方法で実行されるように構成される。このような構成では、シック割り当てに一般的に起因する低いＲＡＭ使用量と低いＣＰＵリソースの利点を享受すると同時に、シン割り当てを使用したプログレッシブな割り当てに一般的に関連する利点も享受する。

いくつかの実施形態によれば、２層のＬＶＭスタックが提案される。１つは物理ドライブの上位に位置するシック割り当てを有する。もう１つは、ボリュームの下位にあるシン割り当ての下位の論理ボリュームマネージャである。いくつかの実施形態によれば、ＬＶＭの下位層の空きスペースを監視するコントローラが提供され、これにより、オーケストレータが上位層（複数可）により多くのエクステントを自動的に割り当てることができるようになる。一般にクラウドＬＶＭはシック動作でのみデータを割り当てるが、提案された構成の使用はクラウド管理ストレージにも適用でき、そのため、パブリッククラウドで使用された容量のみの支払いが可能になることが理解されよう。このような２層のＬＶＭスタックにより、下層のボリュームはすべてのスペースを参照できるようになるが、上層のＬＶＭは容量の一部のみを割り当てる。

本発明の別の態様によれば、ＲＡＩＤパリティ動作に複数のプロセッサコアを使用し、新しいＳＳＤドライブを最大帯域幅まで利用することができ、それにより関連するＲＡＩＤをロックや同期なしにコア間でスケール変更できる。いくつかの実施形態によれば、コアおよびＲＡＩＤ構成により、すべてのコアを並列に使用できるだけでなく、標準的なパリティＲＡＩＤが実行されるため、ＲＡＩＤのサイズを変更する機能も可能になる。マルチコアのスケーラブルなＲＡＩＤパリティはまた、故障したドライブの特別な処理、スペアの交換、および健全性の監視も必要とするが、いくつかの実施形態によれば、そのような構成はコアインスタンスに亘って集約される。いくつかの実施形態によれば、ロックなしで複数のコアでスケール変更および実行するパリティＲＡＩＤが提供される。いくつかの実施形態によれば、オンラインでサイズ変更できるマルチコアパリティＲＡＩＤが提供される。

マルチコアのスケーラブルなＲＡＩＤパリティの例を示す図４３を参照する。ＬＶＭは、各ドライブをサブドライブのボリュームに分割するために使用される。各ドライブが分割されるサブドライブボリュームの数は、ＲＡＩＤロジックに並行して使用されるコアの数である。図４３に例示のように、ＲＡＩＤには３つのコアが使用されるため、各ドライブは３つの論理ボリュームに分割される。レベル５または６の個別のパリティＲＡＩＤが各コアに作成される。図４３に例示のように、３つのコアは３つの個別のＲＡＩＤ５のインスタンスを作成する。各インスタンスは、各物理ボリュームから１つずつ、サブドライブボリュームで実行される。コアのパリティＲＡＩＤは、ホストが別のＬＶＭを使用して使用できるように、単一のボリュームにマージされる。このような例示的な設計および構成により、すべてのコアを並行して使用できるだけでなく、標準パリティＲＡＩＤと同様にＲＡＩＤのサイズを変更する機能も可能になる。

ＲＡＩＤのサイズを変更するために、次の手順を実行できる。
● ＬＶＭの下位層が、物理ボリュームを拡張する。
● ＬＶＭの下位層では、追加のサイズをコア数で除算した分だけ、各サブドライブボリュームを拡張する。
● 各コアのＲＡＩＤ５が拡張される。
● ＬＶＭの上位層が、各コアの各物理ボリュームを拡張する。
● ＬＶＭの上位層が、ボリュームサイズを拡張する。

本発明の別の態様によれば、標準的なオペレーティングシステムを実行する２つのサーバのセットがデュアルストレージコントローラとして設定され、標準的なオペレーティングシステムコンポーネントを使用して相互接続転送チャネルが２つのサーバ間に作成される。いくつかの実施形態によれば、ボリュームサービングノードの優先順位は、オペレーティングシステムターゲットを使用してホストに公開される。いくつかの実施形態によれば、オペレーティングシステムのＮＶＭｅイニシエータコンポーネントのコンポーネントを使用して、ボリュームサービスサーバからボリューム転送サーバへのフェイルオーバーが実行される。オペレーティングシステムのストレージターゲットコンポーネントは１つのサーバで使用され、別のサーバのストレージイニシエータコンポーネントと組み合わせて相互接続を作成する。相互接続は、エンタープライズストレージアレイで実行されるのと同様のトラフィックを転送するために使用されるが、いくつかの実施形態によれば、オペレーティングシステムのマルチパスドライバは、別のノードにフェイルオーバーしながらトラフィックをキューイングするという異なる目的に対して再利用される。マルチパスドライバは、パス障害のサポート用に設計されたキューを含む。

例として、オペレーティングシステムのデバイスマッパー「リニア」は、ボリュームストレージスタックとインターコネクト転送の間の切り替えという別の目的に対して再利用される。「リニア」デバイスマッパーを適用することは有利である、なぜならスタッキングコンポーネントはそれらすべてを削除しないといずれの変更もできないからである。「リニア」デバイスマッパーを使用すると、その上位のコンポーネントを変更せずにスタックコンポーネントを変更できる。ボリュームサービングサーバが変更された場合、またはサーバ障害が発生した場合に、フェイルオーバーが発生する可能性がある。

図４４を参照すると、次のステップを使用したサーバ１からサーバ２へのボリュームのフェイルオーバーを示している。
● マルチパスドライバを使用してサーバ１でＩＯをキューに入れる。
● マルチパスドライバを使用してサーバ２でＩＯをキューに入れる。
● サーバ１の共有ドライブからボリュームスタックを削除する。
● サーバ２の共有ドライブからボリュームスタックを作成する。
● サーバ１のスイッチを変更して、デバイスマッパーリニアを使用してインターコネクト経由で転送を実行する。
● サーバ２のスイッチを変更して、デバイスマッパーリニアを使用してボリュームスタックを実行する。
● サーバ１のターゲットを変更して、非優先パスを公開する。
● サーバ２のターゲットを変更して、優先パスを公開する。
● サーバ１のキューを解放する。
● サーバ２のキューを解放する。

本発明を特定の実施形態を参照して説明してきたが、この説明は限定的な意味で解釈されることを意図したものではない。開示された実施形態の様々な変更、および本発明の代替実施形態は、本発明の説明を参照すると、当業者には明白である。したがって、付属の請求項は、本発明の範囲に入るそのような変更を網羅することが企図される。

Claims (20)

1. データストレージシステムであって、
   （ｉ）記憶媒体を備え、データプレーン（ＤＰ）ネットワークを通してアクセス可能なデータをホストするように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのターゲットサーバと、
   （ｉｉ）前記データプレーン（ＤＰ）ネットワークを通してリモートリソース（複数可）にアクセスして公開するように指定されたオペレーティングシステムを実行するように構成された、少なくとも１つのイニシエータサーバと、
   （ｉｉｉ）各前記サーバと対話するように構成され、前記ＤＰネットワークのコントロールプレーン（ＣＰ）を制御するように指定された、少なくとも１つのオーケストレータと、を含み、
   前記ターゲットサーバの前記記憶媒体の指定された部分が、前記ＤＰネットワークに公開されており、
   前記オーケストレータが、前記イニシエータサーバが前記ＤＰネットワークを介して前記ターゲットサーバと対話するように構成されるように、前記サーバの内部に組み込まれた前記オペレーティングシステムのストレージスタックコンポーネント（ＳＳ）及び標準ストレージスタック（ＳＳＳ）を調整することによって、前記記憶媒体の前記指定された部分を利用するように指定される、前記システム。
2. 少なくとも１つのイニシエータサーバが、マルチパス接続を使用して少なくとも２つのターゲットサーバと対話するように構成されている、請求項１に記載のシステム。
3. 前記イニシエータサーバと前記ターゲットサーバとの間の前記調整が、各サーバにインストールされたＣＰオーケストレータを使用して実行される、請求項１に記載のシステム。
4. 前記ＤＰネットワークを介してアクセス可能なターゲットサーバまたはイニシエータサーバと、前記オーケストレータとの間の通信が、各前記サーバにインストールされた指定のソフトウェアコンポーネントを使用して行われる、請求項１に記載のシステム。
5. 前記イニシエータサーバが、複数のターゲットサーバの前記記憶媒体の複数の指定された部分に由来するデータの冗長性を提供するように構成された独立ディスク冗長アレイ（ＲＡＩＤ）ストレージスタックコンポーネント（ＳＳＣ）を利用するように構成されている、請求項１に記載のシステム。
6. 前記ＲＡＩＤ ＳＳＣが、少なくとも２つのターゲットサーバの前記記憶媒体の前記指定された部分に由来する複数のイニシエータパスの結合に由来するデータの冗長性を提供するように構成されている、請求項５に記載のシステム。
7. 前記ターゲットサーバが異なる場所に配置され、前記オーケストレーションが異なるレジリエンスドメインに亘って割り当てられる、請求項６に記載のシステム。
8. 異なるレジリエンスドメインを考慮しながら割り当てられる前記オーケストレーションがまた、システムバランスの維持を考慮する、請求項７に記載のシステム。
9. 前記オーケストレータが、管理プロトコルを使用して前記サーバと対話するように構成されている、請求項１に記載のシステム。
10. 前記記憶媒体の前記指定された部分が、論理ボリュームマネージャ（ＬＶＭ）ＳＳＣを使用して割り当てられる、請求項１に記載のシステム。
11. 前記記憶媒体が、ソリッドステートドライブ（ＳＳＤ）ベースである、請求項１に記載のシステム。
12. 前記記憶媒体が、ストレージクラスメモリ（ＳＣＭ）ベースである、請求項１に記載のシステム。
13. 前記記憶媒体が、ランダムアクセスメモリ（ＲＡＭ）ベースである、請求項１に記載のシステム。
14. 前記記憶媒体が、ハードディスクドライブ（ＨＨＤ）ベースである、請求項１に記載のシステム。
15. 前記オーケストレータが、物理コントローラである、請求項１に記載のシステム。
16. 前記オーケストレータが、クラウドベースのサービス（ＳａａＳ）である、請求項１に記載のシステム。
17. 各サーバの前記動作が、全体的または部分的に、データ処理ユニット（ＤＰＵ）によって実装され得る、請求項１に記載のシステム。
18. データストレージシステムを動作させる方法であって、
    （ｉ） 少なくとも１つのイニシエータサーバ及び少なくとも１つのターゲットサーバと対話するように構成された少なくとも１つのオーケストレータを使用するステップであって、前記オーケストレータがコントロールプレーン（ＣＰ）ネットワークを制御するように指定されている、前記ステップと、
    （ｉｉ）前記オーケストレータの内部に組み込まれ、様々なシステムの動作パラメータの前記選択を最適化するように構成されたリソース管理計算を使用するステップと、
    （ｉｉｉ）前記オーケストレータを使用して、データプレーン（ＤＰ）ネットワークを介してアクセス可能なデータをホストする前記ターゲットサーバにインストールされたオペレーティングシステムを制御するステップであって、前記ターゲットサーバが永続的な記憶媒質を利用するために記憶媒体を備える、前記ステップと、
    （ｉｖ）前記オペレーティングシステムのＬＶＭを使用し、前記記憶媒体を複数のパーティションに分割するステップと、
    （ｖ）前記ＤＰネットワークを介して前記記憶媒体のパーティション（複数可）にアクセスして消費するよう指定された少なくとも１つのイニシエータサーバにインストールされたオペレーティングシステムを使用して、リモートメディアの容量及びパフォーマンスを利用するステップとを含む、前記方法。
19. 前記記憶媒体が、永続的な記憶媒質を利用するように構成されている、請求項１８に記載の方法。
20. 前記オペレーティングシステムが、マルチパスコンポーネントを利用することによって単一の記憶媒体パーティションを単一のネットワークデバイスとして利用するために、少なくとも２つのネットワークパスをマージするように構成されている、請求項１８に記載の方法。
    
    

Images