JP2024506524A - 公表ファイルシステム及び方法 - Google Patents

Abstract

指定オーケストレータは、指定リーダサーバ（複数可）に公開されるように構成された複数のスナップショットデータバージョンを公表するように構成され、これにより、前のデータスナップショットが繰り返されている間に同時に実行することができるマルチタスクデータ書き込み能力が可能となる。【選択図】図３

Description

本発明は、コンピュータデータのレンダリング及び処理を行うシステム及び方法に関し、より具体的には、関連データの制御された公開を管理及び実行するように構成された指定オーケストレータの使用に関する。

現在のコンピューティングシステムは、ローカル、リモート、またはクラウド（コンテナ、プライベートクラウド／パブリッククラウド、マルチクラウドなど）のいずれのコンピューティングベースであっても、実際の使用だけでなく付随的な使用にも、大容量のデータストレージを要する。このようなデータの提供及び管理は、通常、指定されたデータセンタで行われる。従来、使用されるデータまたは使用が予想されるデータの提供は、例えばハイブリッドハードドライブ（ＨＨＤ）、ソリッドステートドライブ（ＳＳＤ）などの物理データ格納デバイスをスタッキングすることにより、可能になる。

このようなスタッキングにより、「ストレージアレイ」または「ディスクアレイ」と称される、ブロックベースストレージ、ファイルベースストレージ、オブジェクトストレージなどのデータストレージシステムが作られる。ストレージアレイは、サーバにデータを格納するのではなく、複数のストレージメディアの集合を使用し、これらは、相当量のデータを格納可能であり、ローカルの中央制御システムにより制御される。

従来、ストレージアレイ制御システムは、容量追跡、スペース割り当て、ボリューム管理、スナップショット、エラーの識別と追跡、暗号化、圧縮、及び／またはその他のサービスを維持するように、複数のストレージサービスを提供する。このような種類のサービスには、コンピューティング能力、メタデータ分類、データストレージ、アクセラレータなどが必要となるため、著しいインフラストラクチャの能力及びリソースならびに予算の能力及びリソースを指定することが求められる。

ストレージアレイは通常、システムサーバの運用性とは分離されており、これにより、専用ハードウェア上でシステム動作及びアプリケーション動作が実施される。

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

一般的なハードウェアーキテクチャは通常、サーバスタック、ストレージアレイスタック、及びメディアＩ／Ｏデバイスを含む。Ｉ／Ｏデバイスは、ストレージスタックを介して、サーバに通信される。

共通ハードウェアの動作の共通性を可能にするために、データ管理の共通の手法として、ソフトウェアディファインドストレージ（ＳＤＳ）の実践が確立されており、ＳＤＳでは、基盤となる物理ストレージメディアハードウェアからデータストレージリソースが抽象化され、これにより、利用可能なハードウェア及びデータストレージの柔軟な活用が可能となる。

ＳＤＳは、当技術分野ではハイパーコンバージドインフラストラクチャ（ＨＣＩ）とも称され、通常、民生サーバ上で実行される。従来のインフラストラクチャとＨＣＩの主な違いは、ＨＣＩでは、ストレージエリアネットワーク及び基盤となるストレージの両方の抽象化が、ハードウェアで物理的に実施されるのではなく、ソフトウェアで仮想的に実施されることである。

ストレージアレイ及びＳＤＳソリューションは通常、データストレージ及びそのトラフィックを管理及び制御するための統合ストレージソフトウェアスタックを含む。

このような統合ソフトウェアスタックは、データ保護（例えばバックアップ、冗長性、リカバリなど）、高可用性、スペース割り当て、データ削減、データバックアップ、データリカバリなどのストレージメンテナンスサービスを提供する。実際には、統合ソフトウェアスタックは、ストレージアレイのリソースを、その制御、管理、アドミニストレーション、及びメンテナンスの専用にする必要がある。

このようなリソースは、ストレージスタックコード、制御プロトコル、ノード相互接続プロトコル、障害ドメイン、パフォーマンス、スタックモデル、クラスタ内のノード数などの課題に、対処する必要がある。これらのサービス及び要件は、従来、ストレージアレイごとにローカルに提供され、通常、更新、管理、及び全体的アドミニストレーションが必要である。

統合ソフトウェアスタックを構築し維持することは、特に、提供するサービスが多数あり、クライアント（メディア側ならびにサーバ側の両方）の数が多いため、高いコストを負担する場合があり、信頼性が非常に高くある必要があり、コードが効率的である必要があり、他の忠実度検討事項を考慮する必要がある。その結果、現在のストレージアレイは、その信頼性、品質、及びパフォーマンスに関して課題に直面している。

中央ストレージアレイは、通常、多数のクライアントにサービスを提供するように構成されているため、たとえ大きなコンピューティング能力が与えられたとしても、そのような能力は、当該多数のクライアント間で分割される。その中心性に起因して、ストレージアレイまたはスタッククラスタのエラーや誤動作は、即座に全体のパフォーマンスに影響を与える。データストレージ専用のストレージアレイまたはスタッククラスタの量／数は、サーバシステム専用のリソースに比べて、かなり少なく、可用性が低いため、実際のところ、業界では、サービスを提供するデータストレージよりも、サービスを提供するサーバで、より多くの「実績」が得られている（例えばサーバ関連コードがより頻繁にデバッグされ、より効率的になるため、エラーが少ない傾向に至る）。さらに、このような統合ソフトウェアのメンテナンスには、技術の進歩に合わせた継続的な維持及び更新が必要である。その結果、現在の統合ソフトウェアスタック動作の品質及びパフォーマンスは、十分に高くない。

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

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

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

当該ダイレクトローカルサービス（暗号化、圧縮、ＲＡＩＤなど）を促進するためにＯＳサーバシステムに含まれるローコンポーネント（ｒａｗ ｃｏｍｐｏｎｅｎｔｓ）は、現今では、基本的なオペレーティングシステムＤＡＳ用途にのみ使用される。それにもかかわらず、ＯＳサーバにはサービスを可能にするこのようなコンポーネントが多数存在するが、現今ではこのようなコンポーネントは、従来のストレージアレイシステムで利用可能なデータ管理及び制御サービスの一式に対応していない。

ＡＩ及びビッグデータアプリケーションの要件で提示されるような最新のファイルワークロードでは、非常に高い帯域幅、及び非常に高い入出力操作毎秒（ＩＯＰＳ）の仕様が設定される。現在、ネットワーク接続ストレージ及びクラスタ化ファイルシステムの２つのソリューション群が存在する。

ネットワーク接続ストレージ（ＮＡＳ）は、コンピュータネットワークに接続されたファイルレベルのコンピュータデータストレージサーバであり、異種クライアントグループにデータアクセスを提供する。

このようなＮＡＳを促進するために現在一般的に使用されているコントローラベースアーキテクチャは、ドライブとネットワークコンピュータとの間のボトルネックとなるため、実際には、帯域幅及びＩＯＰＳが非常に低い数値に制限される。

クラスタファイルシステムとは、複数のサーバに同時に搭載されることで共有されるファイルシステムである。このような構成では、複数のクライアントが同じファイルにアクセスして更新を試みる場合に、同時実行制御が問題となる。ゆえに、あるクライアントからのファイルの更新は、他のクライアントからのアクセス及び更新を妨げないように、調整される必要がある。この問題は、通常、同時実行制御またはロックプロトコルにより処理される。このようなロック動作及びロック解除動作は、比較的長い時間を費やし、帯域幅及びＩＯＰＳを低い数値に削減して、帯域幅及びＩＯＰＳに悪影響を及ぼす。このような比較的長時間及び比較的大きいリソースの消費は、小さなファイルへのランダムアクセスを実行する場合には、軽減され得る。

したがって、現在利用可能なファイルシステムの提示された欠点が存在することにより、より優れた、より効率的なファイル管理システム及び方法を提供する余地が残されており、このようなファイル管理システム及び方法により、信頼性の高いデータレンダリング及びオーケストレーション、ならびに様々な状況及び懸念事項に適応する柔軟性を提供し、ゆえにユーザの様々なニーズに合わせたリアルタイム動作を提供することができる、信頼性が高く、高速で、費用効果が高く、包括的なソリューションが提供される。

本発明は、ロックフリーであり、動作するのにコントローラを必要としない、低レイテンシのファイル公表システム構成を提供する。さらに、システムの独自の特性により、高度読み取り特化ワークロードが提供され、これにより、様々な複雑なアプリケーションを効率的に実行することが可能となる。

本発明は、さらに、指定リーダサーバ（複数可）に公開されるように構成された複数のスナップショットデータバージョンを公表するように構成された指定オーケストレータを提供し、これにより、前のデータスナップショットが繰り返されている間に同時に実行することができるマルチタスクデータ書き込み能力が可能となる。ゆえに、本発明は、効率的なデータレンダリング及び処理能力、ならびに様々な状況及び懸念事項に適応する柔軟性を提供できる、信頼性が高く、高速で、費用効果が高く、包括的なファイル管理ソリューションを提供する。

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

本発明の一態様は、公表ファイルシステムまたは方法であって、データプレーン（ＤＰ）ネットワークのコントロールプレーン（ＣＰ）を制御するように指定された少なくとも１つのオーケストレータと、データの書き込み、オペレーティングシステムの実行、及びオーケストレータの制御を行うように構成されたライタサーバと、ライタサーバにより生成され、ＤＰネットワークを介してアクセス可能なデータをホストするように指定された少なくとも１つのストレージメディアと、ＤＰネットワークを介してストレージメディアへ読み取り専用アクセスを有するように指定された少なくとも１つのリーダサーバと、を備え、ライタサーバにより実行されるように構成された書き込みプロシージャは、少なくとも１つのデータスナップショットバージョンを生成し、オーケストレータは、リーダサーバがＤＰネットワークにアクセスしてデータスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、新たなデータバージョンは、ライタサーバにより更新され、別の公表コマンドがオーケストレータにより受け入れられるまで、リーダサーバから隠され得る。リーダサーバは、異なる場所に配置され得、異なるレジリエンシドメインにわたりオーケストレーションが割り当てられ、同時に、オーケストレーション割り当てでは、異なるレジリエンシドメインを考慮することで、さらにシステムバランスの維持が考慮され得ることが認識される。

本発明のいくつかの実施形態によれば、ＤＰネットワークを介してデータスナップショットを公開することにより、即座のシステム応答及び短縮したレイテンシが可能となる。さらに、少なくとも１つのメディアストレージは、読み取り専用のメディアストレージスタックであり得、及び／またはデータは、少なくとも２つのメディアストレージにバックアップされる。

本発明のいくつかの実施形態によれば、複数のデータスナップショットバージョンが書き込まれ得ると同時に、リーダサーバには、ＤＰネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される。

本発明のいくつかの実施形態によれば、オーケストレータは、ライタサーバにより作成された特定のスナップショットデータバージョンを認識するように構成され、よって、ＤＰネットワークを介して複数のリーダサーバに、均一かつ信頼性の高いデータスタックを提供するように構成される。本発明のいくつかの実施形態によれば、オーケストレータにより新たなデータスナップショットバージョンが公表されると、リーダサーバは、割り当てメタデータをリフレッシュするように構成される。本発明のいくつかの実施形態によれば、システムまたは方法は、データスナップショットバージョンを作成し、単一のライタサーバを使用して複数のリーダサーバ（複数可）による並列読み取りを可能にするために、ＬＶＭを使用するようにさらに構成される。本発明のいくつかの実施形態によれば、ライタサーバは、マルチパス接続を使用して少なくとも２つのリーダサーバとインタラクトするように構成され得る。あるいは、ＤＰネットワークを介してアクセス可能なリーダサーバまたはライタサーバと、オーケストレータとの通信は、当該デバイスのそれぞれにインストールされた指定ソフトウェアコンポーネントを使用して行われる。

本発明のいくつかの実施形態によれば、システムの通常使用は、リーダサーバ（複数可）により行われるＡＩトレーニングまたは他の大量計算のパフォーマンスを実行するために利用されるように構成される。

本発明のいくつかの実施形態によれば、メディアストレージへのパスはダイレクトであり、各メディアストレージは、ＲＡＩＤ、暗号化、論理ボリュームマネージャ（ＬＶＭ）、及びデータ削減などの必要なストレージスタックサービスを実行するように構成される。本発明のいくつかの実施形態によれば、ライタサーバは、ＲＡＩＤストレージスタックコンポーネント（ＳＳＣ）を利用するように構成され得、ＲＡＩＤ ＳＳＣは、ストレージメディアの複数の指定部分に由来するデータ冗長性を提供するように構成される。

本発明のいくつかの実施形態によれば、リーダサーバは、レイテンシを短縮するために、メタデータ及びデータをＲＡＭにキャッシュするように構成される。本発明のいくつかの実施形態によれば、データスナップショットを作成し、単一のライタサーバを使用して複数のリーダサーバ（複数可）による並列読み取りを可能にするために、シンプロビジョニング層を使用するように、さらなる構成が行われる。

本発明のいくつかの実施形態によれば、オーケストレータは、アドミニストレーションプロトコルを使用して各サーバとインタラクトするように構成され得、ストレージメディアは、ソリッドステートドライブ（ＳＳＤ）ベースであり得、ストレージメディアは、ストレージクラスメモリ（ＳＣＭ）ベースであり、ストレージメディアは、ランダムアクセスメモリ（ＲＡＭ）ベースであり得、ストレージメディアは、ハードディスクドライブ（ＨＨＤ）ベースであり得、オーケストレータは、物理コンポーネントであり得、オーケストレータは、クラウドベースサービス（ＳａａＳ）であり得、及び／または各サーバ上の動作は、全体的または部分的に、データ処理ユニット（ＤＰＵ）により実施され得る。

本発明のいくつかの実施形態は、本明細書にて添付の図面を参照して説明される。図面を伴った説明により、いくつかの実施形態がどのように実施され得るかが、当業者に明らかになる。図面は例示的な説明を目的としており、本発明の基本的理解に必要とされる以上に詳細に、実施形態の構造詳細を示す試みは行われていない。

ネットワーク接続ストレージ（ＮＡＳ）の概略図を成す。 クラスタ化ファイルシステム（ＣＦＳ）の概略図を成す。 本発明のいくつかの実施形態による、公表ファイルシステム（ＰＦＳ）の概略図を成す。 本発明のいくつかの実施形態による、ＰＦＳの一般的なアーキテクチャの概略図を成す。

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

本発明の実施形態は以下に限定されないが、例えば、「処理する（ｐｒｏｃｅｓｓｉｎｇ）」、「演算する（ｃｏｍｐｕｔｉｎｇ）」、「計算する（ｃａｌｃｕｌａｔｉｎｇ）」、「決定／特定する（ｄｅｔｅｒｍｉｎｉｎｇ）」、「確立する（ｅｓｔａｂｌｉｓｈｉｎｇ）」、「分析する（ａｎａｌｙｚｉｎｇ）」、「確認する（ｃｈｅｃｋｉｎｇ）」、「設定する（ｓｅｔｔｉｎｇ）」、または「受信する（ｒｅｃｅｉｖｉｎｇ）」などの用語を使用する論述は、コンピュータのレジスタ及び／またはメモリ内の物理量（例えば電子量）で表されるデータを、コンピュータのレジスタ及び／またはメモリ、あるいは動作及び／またはプロセスを実行する命令を格納し得る他の情報非一時的ストレージメディア内の物理量で同様に表される他のデータに、処理する及び／または変換するコントローラ、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、または他の電子コンピューティングデバイスの動作（複数可）及び／またはプロセス（複数可）を指し得る。

明示的に述べられない限り、本明細書で説明される方法の実施形態は、特定の順序または連続に制約されない。さらに、説明される方法の実施形態またはその要素のうちのいくつかは、同時に、同時点に、または並行して、起こり得るまたは実行され得る。

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

ここで図１を参照すると、図１は、従来のネットワーク接続ストレージ（ＮＡＳ）１０を概略的に示す。図示されるように、ＮＡＳ１０は、サーバ（複数可）１００とストレージメディア（複数可）１０４との間の接続を仲介し、規制し、管理するように指定された少なくとも１つのコントローラ１０２を備える。ファイルサービスがコントローラ１０２により提供され、コントローラ１０２は、例えば、ストレージメディア１０４に格納されている任意の特定のファイルの位置を特定し、ファイルを圧縮／抽出し、サーバ１００へ／サーバ１００からファイルを送信し、またはファイルのレンダリング及び制御に関する任意の必須演算を実行し得る。コントローラ１０２は、一定かつ高速のデータ転送速度を提供するために、その能力が制限されていることから、ＮＡＳ１０のパフォーマンスを低下させる「ボトルネック」コンポーネントとして機能する。

ここで図２を参照すると、図２は、従来のクラスタ化ファイルシステム（ＣＦＳ）２０を概略的に示す。図示されるように、ＣＦＳ２０は、少なくとも１つのストレージメディア（複数可）２０４を備え、これは、ブロックストレージ２０２内にスタックされ、少なくとも１つのサーバ２００に接続され得る。ＣＦＳ２０は、複数のサーバを同じＤＰネットワークで同時に動作させることが可能であり得る。このような同時動作を可能にするために、ＣＦＳ２０は、「ロック」の複雑なプロトコルを管理し、言い換えると、ＣＦＳ２０により実行された、または実行されているすべての動作が確実に調整されるように指定された特定のロックが解除された後にのみ、データを変更／読み取ることができる。当該システムは、通常、ハイパフォーマンスコンピューティング（ＨＰＣ）構成で実施され、適切なパフォーマンスを提供する。それにもかかわらず、このようなシステムは、頻繁にロックを作成する必要性から大幅なレイテンシが生じるため、ＡＩトレーニング及び複雑な分析の規制及び調整にはあまり効果的ではない。さらに、参加しているすべてのサーバからロック許可を要求して取得する必要があるため、かなりの量のコンピューティングリソースを要し、したがってＣＦＳ２０のパフォーマンス及び速度が低下する。

ここで図３を参照すると、図３は、いくつかの実施形態による、本発明の主題である公表ファイルシステム（ＰＦＳ）３０を概略的に示す。図示されるように、ＰＦＳ３０は、少なくとも１つのメディアストレージ３０８と、読み取り専用構成に構成された少なくとも１つのリーダサーバ３００と、少なくとも１つのオーケストレータ３０６を制御するように構成されたライタサーバ３０２とを備え、次に、オーケストレータ３０６は、ＰＦＳ３０の様々なコンポーネント間のデータを仲介、規制、及び管理するように指定される。いくつかの実施形態によれば、ＰＦＳ３０は、ロックフリーであり、動作するのにコントローラを必要としない低レイテンシ構成を可能にする。さらに、システムの独自の構成により、高度読み取り特化ワークロード能力が提供され、これにより、様々な複雑なアプリケーションを効率的に実行することが可能となる。

いくつかの実施形態によれば、リーダサーバ３００との通信は、オーケストレータ３０６を使用して行われ、各リーダサーバ３００との通信は有効化されていない。上記に開示されたように、リーダサーバ３００は、読み取り専用構成に構成されており、新たなデータを書き込むことはできない。この構成により、ＡＩモデルのトレーニングが、例えばモデルに膨大なデータセットを公開して複数回の反復を実行することにより、可能となる。

いくつかの実施形態によれば、オーケストレータ３０６は、リーダサーバ（複数可）３００にアクセス可能なデータプレーン（ＤＰ）ネットワークのコントロールプレーン（ＣＰ）を制御するように指定され得る。いくつかの実施形態によれば、ライタサーバ３０２は、オペレーティングシステムを実行するように、及び、例えばデータ管理及びデータ調整に関する様々なタスクを実行するようにオーケストレータ３０６に命令することにより、オーケストレータ３０６を制御するように構成され得る。

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

いくつかの実施形態によれば、ユーザ３０４は、ライタサーバ３０２を使用してデータを書き込むことができ、例えば、ユーザ３０４は、リーダサーバ（複数可）３００などを使用してＡＩモデルをトレーニングするように指定された参照データセットを作成するために、様々な画像にラベル付けを行い得る。

いくつかの実施形態によれば、少なくとも１つのストレージメディア３０８は、ライタサーバ３０２により生成され、ＤＰネットワークを介してアクセス可能なデータをホストするように指定される。いくつかの実施形態によれば、ストレージメディア３０８は、ソリッドステートドライブ（ＳＳＤ）ベース、クラスメモリ（ＳＣＭ）ベース、ランダムアクセスメモリ（ＲＡＭ）ベース、ハードディスクドライブ（ＨＨＤ）ベースなどであり得る。

いくつかの実施形態によれば、ライタサーバ３０２は、データを書き込み、少なくとも１つのデータスナップショットバージョンを形成するように構成され得、例えば、ユーザ３０４は、ライタサーバ３０２を使用してデータのラベル付けを行い、書き込み及び準備などが完了した現在のデータのスナップショットバージョンを記録し得る。

いくつかの実施形態によれば、オーケストレータ３０６は、ライタサーバ３００により送信される公表コマンドを受け入れるように構成され得、当該コマンドにより、リーダサーバ（複数可）３００は、ＤＰネットワークにアクセスするため、リーダサーバ（複数可）３００に、ストレージメディア３０８に現在格納されている当該データスナップショットバージョンを公開することが可能となり得る。

いくつかの実施形態によれば、リーダサーバ（複数可）３００は、ＤＰネットワークを介したストレージメディア３０８への読み取り専用アクセスを有するように指定され、例えば、複数のリーダサーバ３００は、ＡＩモデルのトレーニングなどの一環として、メディアストレージ３０８に格納されたデータに基づいて、サンプリング及び多数の反復を行い得る。

いくつかの実施形態によれば、新たなデータバージョンは、ライタサーバ３０２により更新され、別の公表コマンドがオーケストレータ３０６により受け入れられるまで、リーダサーバ３００から隠され得る。いくつかの実施形態によれば、当該プロシージャは、最小レイテンシで実行されて、即時応答をもたらし得、これにより、システムのパフォーマンスが向上し、非常に高いデータ読み取り速度が提供され得る。

いくつかの実施形態によれば、少なくとも１つのメディアストレージ３０８は、ストレージアレイ３１０（またはディスクアレイ）とも称され得る読み取り専用メディアストレージスタックであり、ブロックベースストレージ、ファイルベースストレージ、オブジェクトストレージなどに使用され得る。ストレージアレイ３１０は、サーバ上にデータを格納するのではなく、相当量のデータを格納できる複数のストレージメディア３０８の集合を使用し得る。

いくつかの実施形態によれば、前に開示されたように、ストレージメディア３０８は、ストレージアレイ３１０を形成するようにスタッキングされ得、異なる種類のメディアでデジタルデータを保持またはアーカイブするタスクを実行し得る。ストレージメディアの主な種類には、ハードディスクドライブ（ＨＤＤ）、ソリッドステートディスク（ＳＳＤ）、光ストレージ、テープなどが含まれ、ＨＤＤは、磁気メディアでコーティングされた回転ディスクに対しデータを読み書きするように構成され、ＳＳＤは、不揮発性フラッシュメモリチップにデータを格納し、可動部品を有さない。光データストレージは、レーザを使用して、通常は回転光ディスクである光メディアへデータの格納、及び光メディアからデータの取得を行い、テープストレージは、磁気テープにデータを記録する。

従来、ストレージアレイは、容量追跡、スペース割り当て、ボリューム管理、スナップショット、エラーの識別及び追跡、暗号化、圧縮などを維持するように、複数のストレージサービスを提供する制御システムを管理するように構成される。このような種類のサービスには、著しいコンピューティング能力、メタデータ、データストレージ、アクセラレータなどが必要である。

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

いくつかの実施形態によれば、ストレージスタック３１０は、オーケストレータ３０６により制御及び管理されるように構成され、よって、上記で開示されたような膨大なリソースを必要とする統合制御システムを必要としない。

いくつかの実施形態によれば、ライタサーバ３０２により生成されたスナップショットバージョン（複数可）は、少なくとも２つのメディアストレージ３０８にバックアップされ得る。この冗長性により、データの整合性レベルが向上し、データ損失が発生したいずれの事例においても、適切な軽減手段が提供される。

いくつかの実施形態によれば、ライタサーバ３０２により複数のデータバージョンが書き込まれ得ると同時に、リーダサーバ（複数可）３００には、ＤＰネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される。例えば、データサイエンティスト３０４は、ＡＩモデルをトレーニングするように指定された反復ボリュームを提供するために、複数の画像にラベル付けを行い、データセットを準備し得、次に、ライタサーバ３０２は、当該データセットのスナップショットバージョンをキャプチャして、オーケストレータ３０６にＤＰネットワークを介して当該バージョンを公表するように命令し得、次に、サーバ（複数可）３００には当該バージョンが公開され得、同時にデータサイエンティストは、ライタサーバ３０２を自由に利用して別のタスクを実行し、やがてこれにもスナップショットが作成され、公表されるように指定された新たなスナップショットバージョンが作成される。

いくつかの実施形態によれば、オーケストレータ３０６は、ライタサーバ３０２により作成された特定の書き込みデータバージョンを認識するように構成され得、よって、オーケストレータ３０６は、複数のリーダサーバ３００がＤＰネットワークを介してアクセス可能な均一でデータ信頼性のあるストレージスタックを提供し管理するように構成され得る。

いくつかの実施形態によれば、割り当て方法を使用して、ファイルがストレージメディア３０８及び／またはストレージスタック３１０に格納される方法が定義され得る。異なるファイルまたは多数のファイルは、同じディスクに格納され、または予備として別のディスクに保存される。ここで生じる主な問題は、メディアストレージを効率的に使用して、迅速なアクセスを可能にするように、これらのファイルの場所をどのように割り当てるかということである。

いくつかの実施形態によれば、オーケストレータ３０６により新たなデータスナップショットバージョンが公表されると、リーダサーバ（複数可）３００は、割り当てメタデータをリフレッシュするように構成され、よって、更新されたスナップショットバージョンの関連ファイルの場所に関する更新されたメタデータが提供され得る。

いくつかの実施形態によれば、メディアストレージ３０８は、ダイレクトパスを有し得、各メディアストレージ３０８は、ＲＡＩＤ、暗号化、論理ボリュームマネージャ（ＬＶＭ）、データ削減などの必要なストレージスタックサービスを実行するように構成される。

いくつかの実施形態によれば、リーダサーバ３０２は、レイテンシを短縮するために、メタデータ及びデータをＲＡＭにキャッシュするように構成される。

いくつかの実施形態によれば、ＰＦＳ３０は、データスナップショットを実行するために、ＬＶＭを使用し得、これにより単一のライタサーバ３０２による並列読み取りが可能となる。いくつかの実施形態によれば、ＰＦＳ３０は、データスナップショットを実行して、単一のライタサーバによる並列読み取りを可能にするために、シンプロビジョニング層を使用するように構成され得る。

いくつかの実施形態によれば、上記で開示されたように、ライタサーバ３０２は、マルチパス接続を使用して少なくとも２つのターゲットサーバ３００とインタラクトするように構成される。いくつかの実施形態によれば、マルチパス接続は、より広い帯域幅を提供する際の接続信頼性を改善し向上させるために、使用され得る。

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

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

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

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

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

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

ここで図４を参照すると、図４は、いくつかの実施形態による、ＰＦＳ３０の一般的なアーキテクチャ４００を概略的に示す。図示されるように、様々なコンポーネントが、インタラクトし、ＤＰネットワークを介して個別のスナップショットバージョンを公表する能力を提供するように構成される。例えば、オーケストレーションジョブは、様々なスタックコンポーネントに影響を及ぼし得、次に、ＳＳＨ、ＰＳＲＰ、Ａｍａｚｏｎ ＡＷＳ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ、及びＧｏｏｇｌｅクラウドなどの様々なクラウドコンピューティングプラットフォーム／暗号化ネットワークプロトコル／アプリケーションプログラミングインターフェイスを介して、変換され、利用される。

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

Claims (26)

1. （ｉ）データプレーン（ＤＰ）ネットワークのコントロールプレーン（ＣＰ）を制御するように指定された少なくとも１つのオーケストレータと、
   （ｉｉ）データの書き込み、オペレーティングシステムの実行、及び前記オーケストレータの制御を行うように構成されたライタサーバと、
   （ｉｉｉ）前記ライタサーバにより生成され、前記ＤＰネットワークを介してアクセス可能なデータをホストするように指定された少なくとも１つのストレージメディアと、
   （ｉｖ）前記ＤＰネットワークを介して前記ストレージメディアへ読み取り専用アクセスを有するように指定された少なくとも１つのリーダサーバと、
   を備える、公表ファイルシステムであって、
   前記ライタサーバにより実行されるように構成された書き込みプロシージャは、少なくとも１つのデータスナップショットバージョンを生成し、
   前記オーケストレータは、前記リーダサーバが前記ＤＰネットワークにアクセスして前記データスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、
   新たなデータバージョンは、前記ライタサーバにより更新され、別の公表コマンドが前記オーケストレータにより受け入れられるまで、前記リーダサーバから隠され得る、
   前記システム。
2. 前記ＤＰネットワークを介してデータスナップショットを公開することにより、即座のシステム応答及び短縮したレイテンシが可能となる、請求項１に記載のシステム。
3. 前記少なくとも１つのメディアストレージは、読み取り専用メディアストレージスタックである、請求項１に記載のシステム。
4. 前記データは、少なくとも２つのメディアストレージにバックアップされる、請求項１に記載のシステム。
5. 複数のデータスナップショットバージョンが書き込まれ得ると同時に、前記リーダサーバには、前記ＤＰネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される、請求項１に記載のシステム。
6. 前記オーケストレータは、前記ライタサーバにより作成された特定のスナップショットデータバージョンを認識するように構成され、よって、前記ＤＰネットワークを介して複数のリーダサーバに、均一かつ信頼性の高いデータスタックを提供するように構成される、請求項１に記載のシステム。
7. 前記オーケストレータにより新たなデータスナップショットバージョンが公表されると、前記リーダサーバは、割り当てメタデータをリフレッシュするように構成される、請求項１に記載のシステム。
8. 前記システムの通常使用は、前記リーダサーバ（複数可）により行われるＡＩトレーニングを実行するために利用されるように構成される、請求項１に記載のシステム。
9. 前記メディアストレージへのパスはダイレクトであり、各メディアストレージは必要なストレージスタックサービスを実行するように構成される、請求項１に記載のシステム。
10. 前記リーダサーバは、レイテンシを短縮するために、メタデータ及びデータをＲＡＭにキャッシュするように構成される、請求項１に記載のシステム。
11. データスナップショットバージョンを作成し、単一のライタサーバを使用して複数のリーダサーバ（複数可）による並列読み取りを可能にするために、ＬＶＭを使用するようにさらに構成される、請求項１に記載のシステム。
12. データスナップショットを作成し、単一のライタサーバを使用して複数のリーダサーバ（複数可）による並列読み取りを可能にするために、シンプロビジョニング層を使用するようにさらに構成される、請求項１１に記載のシステム。
13. 前記ライタサーバは、マルチパス接続を使用して少なくとも２つのリーダサーバとインタラクトするように構成される、請求項１に記載のシステム。
14. 前記ＤＰネットワークを介してアクセス可能なリーダサーバまたはライタサーバと、前記オーケストレータとの通信は、前記デバイスのそれぞれにインストールされた指定ソフトウェアコンポーネントを使用して行われる、請求項１に記載のシステム。
15. 前記ライタサーバは、ＲＡＩＤストレージスタックコンポーネント（ＳＳＣ）を利用するように構成され、前記ＲＡＩＤ ＳＳＣは、前記ストレージメディアの複数の指定部分に由来するデータ冗長性を提供するように構成される、請求項１に記載のシステム。
16. 少なくとも２つのリーダサーバは、異なる場所に配置され、前記オーケストレーションは、異なるレジリエンシドメインにわたり割り当てられる、請求項１に記載のシステム。
17. 異なるレジリエンシドメインを考慮しながら割り当てられる前記オーケストレーションは、システムバランスの維持をさらに考慮する、請求項１６に記載のシステム。
18. 前記オーケストレータは、アドミニストレーションプロトコルを使用して各サーバとインタラクトするように構成される、請求項１に記載のシステム。
19. 前記ストレージメディアは、ソリッドステートドライブ（ＳＳＤ）ベースである、請求項１に記載のシステム。
20. 前記ストレージメディアは、ストレージクラスメモリ（ＳＣＭ）ベースである、請求項１に記載のシステム。
21. 前記ストレージメディアは、ランダムアクセスメモリ（ＲＡＭ）ベースである、請求項１に記載のシステム。
22. 前記ストレージメディアは、ハードディスクドライブ（ＨＨＤ）ベースである、請求項１に記載のシステム。
23. 前記オーケストレータは、物理コンポーネントである、請求項１に記載のシステム。
24. 前記オーケストレータは、クラウドベースサービス（ＳａａＳ）である、請求項１に記載のシステム。
25. 各サーバ上の動作は、全体的または部分的に、データ処理ユニット（ＤＰＵ）により実施され得る、請求項１に記載のシステム。
26. 公表ファイルシステムの動作方法であって、
    （ｉ）データプレーン（ＤＰ）ネットワークのコントロールプレーン（ＣＰ）を制御するように指定された少なくとも１つのオーケストレータを使用するステップと、
    （ｉｉ）データの書き込み、オペレーティングシステムの実行、及び前記オーケストレータの制御を行うように、ライタサーバを構成するステップと、
    （ｉｉｉ）前記構成されたライタサーバにより生成されたデータをホストするように、少なくとも１つのストレージメディアを指定し、前記データを前記ＤＰネットワークを介してアクセス可能にするステップと、
    （ｉｖ）前記ＤＰネットワークを介して前記ストレージメディアへ読み取り専用アクセスを有するように、少なくとも１つのリーダサーバを指定するステップと、
    を含み、
    前記ライタサーバにより実行されるように書き込みプロシージャを構成することは、少なくとも１つのデータスナップショットバージョンを生成することであり、
    前記オーケストレータの前記指定は、前記リーダサーバが前記ＤＰネットワークにアクセスして前記データスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、
    新たなデータバージョンの更新は、前記ライタサーバにより実現され、別の公表コマンドが前記オーケストレータにより受け入れられるまで、前記リーダサーバから隠され得る、
    前記方法。

Images