IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ボリュームズ テクノロジーズ リミテッドの特許一覧

<>
  • 特表-公表ファイルシステム及び方法 図1
  • 特表-公表ファイルシステム及び方法 図2
  • 特表-公表ファイルシステム及び方法 図3
  • 特表-公表ファイルシステム及び方法 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-14
(54)【発明の名称】公表ファイルシステム及び方法
(51)【国際特許分類】
   G06F 16/28 20190101AFI20240206BHJP
   G06F 3/06 20060101ALI20240206BHJP
   G06F 16/172 20190101ALI20240206BHJP
【FI】
G06F16/28
G06F3/06 304F
G06F16/172
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023544651
(86)(22)【出願日】2022-01-25
(85)【翻訳文提出日】2023-07-25
(86)【国際出願番号】 IL2022050099
(87)【国際公開番号】W WO2022157782
(87)【国際公開日】2022-07-28
(31)【優先権主張番号】63/141,133
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,139
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,151
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,155
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,162
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,179
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,194
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,205
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,213
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,227
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,236
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,245
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,257
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,263
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】63/141,267
(32)【優先日】2021-01-25
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
2.WINDOWS
(71)【出願人】
【識別番号】523279534
【氏名又は名称】ボリュームズ テクノロジーズ リミテッド
(74)【代理人】
【識別番号】100114775
【弁理士】
【氏名又は名称】高岡 亮一
(74)【代理人】
【識別番号】100121511
【弁理士】
【氏名又は名称】小田 直
(74)【代理人】
【識別番号】100202751
【弁理士】
【氏名又は名称】岩堀 明代
(74)【代理人】
【識別番号】100208580
【弁理士】
【氏名又は名称】三好 玲奈
(74)【代理人】
【識別番号】100191086
【弁理士】
【氏名又は名称】高橋 香元
(72)【発明者】
【氏名】アミット,ジョナサン
【テーマコード(参考)】
5B175
【Fターム(参考)】
5B175AA02
5B175CA09
(57)【要約】
指定オーケストレータは、指定リーダサーバ(複数可)に公開されるように構成された複数のスナップショットデータバージョンを公表するように構成され、これにより、前のデータスナップショットが繰り返されている間に同時に実行することができるマルチタスクデータ書き込み能力が可能となる。
【選択図】図3
【特許請求の範囲】
【請求項1】
(i)データプレーン(DP)ネットワークのコントロールプレーン(CP)を制御するように指定された少なくとも1つのオーケストレータと、
(ii)データの書き込み、オペレーティングシステムの実行、及び前記オーケストレータの制御を行うように構成されたライタサーバと、
(iii)前記ライタサーバにより生成され、前記DPネットワークを介してアクセス可能なデータをホストするように指定された少なくとも1つのストレージメディアと、
(iv)前記DPネットワークを介して前記ストレージメディアへ読み取り専用アクセスを有するように指定された少なくとも1つのリーダサーバと、
を備える、公表ファイルシステムであって、
前記ライタサーバにより実行されるように構成された書き込みプロシージャは、少なくとも1つのデータスナップショットバージョンを生成し、
前記オーケストレータは、前記リーダサーバが前記DPネットワークにアクセスして前記データスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、
新たなデータバージョンは、前記ライタサーバにより更新され、別の公表コマンドが前記オーケストレータにより受け入れられるまで、前記リーダサーバから隠され得る、
前記システム。
【請求項2】
前記DPネットワークを介してデータスナップショットを公開することにより、即座のシステム応答及び短縮したレイテンシが可能となる、請求項1に記載のシステム。
【請求項3】
前記少なくとも1つのメディアストレージは、読み取り専用メディアストレージスタックである、請求項1に記載のシステム。
【請求項4】
前記データは、少なくとも2つのメディアストレージにバックアップされる、請求項1に記載のシステム。
【請求項5】
複数のデータスナップショットバージョンが書き込まれ得ると同時に、前記リーダサーバには、前記DPネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される、請求項1に記載のシステム。
【請求項6】
前記オーケストレータは、前記ライタサーバにより作成された特定のスナップショットデータバージョンを認識するように構成され、よって、前記DPネットワークを介して複数のリーダサーバに、均一かつ信頼性の高いデータスタックを提供するように構成される、請求項1に記載のシステム。
【請求項7】
前記オーケストレータにより新たなデータスナップショットバージョンが公表されると、前記リーダサーバは、割り当てメタデータをリフレッシュするように構成される、請求項1に記載のシステム。
【請求項8】
前記システムの通常使用は、前記リーダサーバ(複数可)により行われるAIトレーニングを実行するために利用されるように構成される、請求項1に記載のシステム。
【請求項9】
前記メディアストレージへのパスはダイレクトであり、各メディアストレージは必要なストレージスタックサービスを実行するように構成される、請求項1に記載のシステム。
【請求項10】
前記リーダサーバは、レイテンシを短縮するために、メタデータ及びデータをRAMにキャッシュするように構成される、請求項1に記載のシステム。
【請求項11】
データスナップショットバージョンを作成し、単一のライタサーバを使用して複数のリーダサーバ(複数可)による並列読み取りを可能にするために、LVMを使用するようにさらに構成される、請求項1に記載のシステム。
【請求項12】
データスナップショットを作成し、単一のライタサーバを使用して複数のリーダサーバ(複数可)による並列読み取りを可能にするために、シンプロビジョニング層を使用するようにさらに構成される、請求項11に記載のシステム。
【請求項13】
前記ライタサーバは、マルチパス接続を使用して少なくとも2つのリーダサーバとインタラクトするように構成される、請求項1に記載のシステム。
【請求項14】
前記DPネットワークを介してアクセス可能なリーダサーバまたはライタサーバと、前記オーケストレータとの通信は、前記デバイスのそれぞれにインストールされた指定ソフトウェアコンポーネントを使用して行われる、請求項1に記載のシステム。
【請求項15】
前記ライタサーバは、RAIDストレージスタックコンポーネント(SSC)を利用するように構成され、前記RAID SSCは、前記ストレージメディアの複数の指定部分に由来するデータ冗長性を提供するように構成される、請求項1に記載のシステム。
【請求項16】
少なくとも2つのリーダサーバは、異なる場所に配置され、前記オーケストレーションは、異なるレジリエンシドメインにわたり割り当てられる、請求項1に記載のシステム。
【請求項17】
異なるレジリエンシドメインを考慮しながら割り当てられる前記オーケストレーションは、システムバランスの維持をさらに考慮する、請求項16に記載のシステム。
【請求項18】
前記オーケストレータは、アドミニストレーションプロトコルを使用して各サーバとインタラクトするように構成される、請求項1に記載のシステム。
【請求項19】
前記ストレージメディアは、ソリッドステートドライブ(SSD)ベースである、請求項1に記載のシステム。
【請求項20】
前記ストレージメディアは、ストレージクラスメモリ(SCM)ベースである、請求項1に記載のシステム。
【請求項21】
前記ストレージメディアは、ランダムアクセスメモリ(RAM)ベースである、請求項1に記載のシステム。
【請求項22】
前記ストレージメディアは、ハードディスクドライブ(HHD)ベースである、請求項1に記載のシステム。
【請求項23】
前記オーケストレータは、物理コンポーネントである、請求項1に記載のシステム。
【請求項24】
前記オーケストレータは、クラウドベースサービス(SaaS)である、請求項1に記載のシステム。
【請求項25】
各サーバ上の動作は、全体的または部分的に、データ処理ユニット(DPU)により実施され得る、請求項1に記載のシステム。
【請求項26】
公表ファイルシステムの動作方法であって、
(i)データプレーン(DP)ネットワークのコントロールプレーン(CP)を制御するように指定された少なくとも1つのオーケストレータを使用するステップと、
(ii)データの書き込み、オペレーティングシステムの実行、及び前記オーケストレータの制御を行うように、ライタサーバを構成するステップと、
(iii)前記構成されたライタサーバにより生成されたデータをホストするように、少なくとも1つのストレージメディアを指定し、前記データを前記DPネットワークを介してアクセス可能にするステップと、
(iv)前記DPネットワークを介して前記ストレージメディアへ読み取り専用アクセスを有するように、少なくとも1つのリーダサーバを指定するステップと、
を含み、
前記ライタサーバにより実行されるように書き込みプロシージャを構成することは、少なくとも1つのデータスナップショットバージョンを生成することであり、
前記オーケストレータの前記指定は、前記リーダサーバが前記DPネットワークにアクセスして前記データスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、
新たなデータバージョンの更新は、前記ライタサーバにより実現され、別の公表コマンドが前記オーケストレータにより受け入れられるまで、前記リーダサーバから隠され得る、
前記方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピュータデータのレンダリング及び処理を行うシステム及び方法に関し、より具体的には、関連データの制御された公開を管理及び実行するように構成された指定オーケストレータの使用に関する。
【背景技術】
【0002】
現在のコンピューティングシステムは、ローカル、リモート、またはクラウド(コンテナ、プライベートクラウド/パブリッククラウド、マルチクラウドなど)のいずれのコンピューティングベースであっても、実際の使用だけでなく付随的な使用にも、大容量のデータストレージを要する。このようなデータの提供及び管理は、通常、指定されたデータセンタで行われる。従来、使用されるデータまたは使用が予想されるデータの提供は、例えばハイブリッドハードドライブ(HHD)、ソリッドステートドライブ(SSD)などの物理データ格納デバイスをスタッキングすることにより、可能になる。
【0003】
このようなスタッキングにより、「ストレージアレイ」または「ディスクアレイ」と称される、ブロックベースストレージ、ファイルベースストレージ、オブジェクトストレージなどのデータストレージシステムが作られる。ストレージアレイは、サーバにデータを格納するのではなく、複数のストレージメディアの集合を使用し、これらは、相当量のデータを格納可能であり、ローカルの中央制御システムにより制御される。
【0004】
従来、ストレージアレイ制御システムは、容量追跡、スペース割り当て、ボリューム管理、スナップショット、エラーの識別と追跡、暗号化、圧縮、及び/またはその他のサービスを維持するように、複数のストレージサービスを提供する。このような種類のサービスには、コンピューティング能力、メタデータ分類、データストレージ、アクセラレータなどが必要となるため、著しいインフラストラクチャの能力及びリソースならびに予算の能力及びリソースを指定することが求められる。
【0005】
ストレージアレイは通常、システムサーバの運用性とは分離されており、これにより、専用ハードウェア上でシステム動作及びアプリケーション動作が実施される。
【0006】
従来のストレージアレイにより提供されるサービスのうちの1つは、障害が発生した場合にデータを保護するために、同じデータを複数のHHDまたはSSDの異なる場所に格納する方法として、独立ディスク冗長アレイ(RAID)を提供することである。様々なRAIDレベルが存在し、すべてが冗長性を提供することを目的としているわけではないが、これらは、システムにおける全体的なパフォーマンスの向上及びストレージ容量の増加を指向し得る。
【0007】
一般的なハードウェアーキテクチャは通常、サーバスタック、ストレージアレイスタック、及びメディアI/Oデバイスを含む。I/Oデバイスは、ストレージスタックを介して、サーバに通信される。
【0008】
共通ハードウェアの動作の共通性を可能にするために、データ管理の共通の手法として、ソフトウェアディファインドストレージ(SDS)の実践が確立されており、SDSでは、基盤となる物理ストレージメディアハードウェアからデータストレージリソースが抽象化され、これにより、利用可能なハードウェア及びデータストレージの柔軟な活用が可能となる。
【0009】
SDSは、当技術分野ではハイパーコンバージドインフラストラクチャ(HCI)とも称され、通常、民生サーバ上で実行される。従来のインフラストラクチャとHCIの主な違いは、HCIでは、ストレージエリアネットワーク及び基盤となるストレージの両方の抽象化が、ハードウェアで物理的に実施されるのではなく、ソフトウェアで仮想的に実施されることである。
【0010】
ストレージアレイ及びSDSソリューションは通常、データストレージ及びそのトラフィックを管理及び制御するための統合ストレージソフトウェアスタックを含む。
【0011】
このような統合ソフトウェアスタックは、データ保護(例えばバックアップ、冗長性、リカバリなど)、高可用性、スペース割り当て、データ削減、データバックアップ、データリカバリなどのストレージメンテナンスサービスを提供する。実際には、統合ソフトウェアスタックは、ストレージアレイのリソースを、その制御、管理、アドミニストレーション、及びメンテナンスの専用にする必要がある。
【0012】
このようなリソースは、ストレージスタックコード、制御プロトコル、ノード相互接続プロトコル、障害ドメイン、パフォーマンス、スタックモデル、クラスタ内のノード数などの課題に、対処する必要がある。これらのサービス及び要件は、従来、ストレージアレイごとにローカルに提供され、通常、更新、管理、及び全体的アドミニストレーションが必要である。
【0013】
統合ソフトウェアスタックを構築し維持することは、特に、提供するサービスが多数あり、クライアント(メディア側ならびにサーバ側の両方)の数が多いため、高いコストを負担する場合があり、信頼性が非常に高くある必要があり、コードが効率的である必要があり、他の忠実度検討事項を考慮する必要がある。その結果、現在のストレージアレイは、その信頼性、品質、及びパフォーマンスに関して課題に直面している。
【0014】
中央ストレージアレイは、通常、多数のクライアントにサービスを提供するように構成されているため、たとえ大きなコンピューティング能力が与えられたとしても、そのような能力は、当該多数のクライアント間で分割される。その中心性に起因して、ストレージアレイまたはスタッククラスタのエラーや誤動作は、即座に全体のパフォーマンスに影響を与える。データストレージ専用のストレージアレイまたはスタッククラスタの量/数は、サーバシステム専用のリソースに比べて、かなり少なく、可用性が低いため、実際のところ、業界では、サービスを提供するデータストレージよりも、サービスを提供するサーバで、より多くの「実績」が得られている(例えばサーバ関連コードがより頻繁にデバッグされ、より効率的になるため、エラーが少ない傾向に至る)。さらに、このような統合ソフトウェアのメンテナンスには、技術の進歩に合わせた継続的な維持及び更新が必要である。その結果、現在の統合ソフトウェアスタック動作の品質及びパフォーマンスは、十分に高くない。
【0015】
Linux及びWindows Serverなどの最新のオペレーティングシステムは、堅牢な内部ストレージコンポーネント集合[(ダイレクトアタッチストレージ‐(DAS))]を含み、設計要件が原因で、またはストレージアレイまたはデータスタッククラスタによる欠点が原因で、中央ストレージシステムが不要である、または望ましくない場合には、DASにより、ダイレクトローカルサービス(暗号化、圧縮、RAIDなど)が可能となる。
【0016】
ストレージコンポーネントは、通常、カーネル層に実装され、即時アクセスが確保されるため、OS及び/またはアプリケーションの高パフォーマンスが確保される。DASは、サーバ通信障害の直接的な悪影響により、DASに格納されているデータへのアクセスが直接妨げられるというDAS固有の欠点があるため、ほとんどの場合、重要性の低いアプリケーションに限定される。したがって、原則として、企業は重要なアプリケーションにDASを使用しない。それにもかかわらず、現在の最新のサーバ及びオペレーティングシステムは、DAS機能に対応するために必要なサービスを含むように設計されている。
【0017】
オペレーティングシステムの成熟度により、企業での使用を目的とした安定したコンポーネントが提供されているが、DASの信頼性には限界があるため、ストレージアレイに依存することが、依然として優先度の高い検討事項である。
【0018】
当該ダイレクトローカルサービス(暗号化、圧縮、RAIDなど)を促進するためにOSサーバシステムに含まれるローコンポーネント(raw components)は、現今では、基本的なオペレーティングシステムDAS用途にのみ使用される。それにもかかわらず、OSサーバにはサービスを可能にするこのようなコンポーネントが多数存在するが、現今ではこのようなコンポーネントは、従来のストレージアレイシステムで利用可能なデータ管理及び制御サービスの一式に対応していない。
【0019】
AI及びビッグデータアプリケーションの要件で提示されるような最新のファイルワークロードでは、非常に高い帯域幅、及び非常に高い入出力操作毎秒(IOPS)の仕様が設定される。現在、ネットワーク接続ストレージ及びクラスタ化ファイルシステムの2つのソリューション群が存在する。
【0020】
ネットワーク接続ストレージ(NAS)は、コンピュータネットワークに接続されたファイルレベルのコンピュータデータストレージサーバであり、異種クライアントグループにデータアクセスを提供する。
【0021】
このようなNASを促進するために現在一般的に使用されているコントローラベースアーキテクチャは、ドライブとネットワークコンピュータとの間のボトルネックとなるため、実際には、帯域幅及びIOPSが非常に低い数値に制限される。
【0022】
クラスタファイルシステムとは、複数のサーバに同時に搭載されることで共有されるファイルシステムである。このような構成では、複数のクライアントが同じファイルにアクセスして更新を試みる場合に、同時実行制御が問題となる。ゆえに、あるクライアントからのファイルの更新は、他のクライアントからのアクセス及び更新を妨げないように、調整される必要がある。この問題は、通常、同時実行制御またはロックプロトコルにより処理される。このようなロック動作及びロック解除動作は、比較的長い時間を費やし、帯域幅及びIOPSを低い数値に削減して、帯域幅及びIOPSに悪影響を及ぼす。このような比較的長時間及び比較的大きいリソースの消費は、小さなファイルへのランダムアクセスを実行する場合には、軽減され得る。
【0023】
したがって、現在利用可能なファイルシステムの提示された欠点が存在することにより、より優れた、より効率的なファイル管理システム及び方法を提供する余地が残されており、このようなファイル管理システム及び方法により、信頼性の高いデータレンダリング及びオーケストレーション、ならびに様々な状況及び懸念事項に適応する柔軟性を提供し、ゆえにユーザの様々なニーズに合わせたリアルタイム動作を提供することができる、信頼性が高く、高速で、費用効果が高く、包括的なソリューションが提供される。
【発明の概要】
【0024】
本発明は、ロックフリーであり、動作するのにコントローラを必要としない、低レイテンシのファイル公表システム構成を提供する。さらに、システムの独自の特性により、高度読み取り特化ワークロードが提供され、これにより、様々な複雑なアプリケーションを効率的に実行することが可能となる。
【0025】
本発明は、さらに、指定リーダサーバ(複数可)に公開されるように構成された複数のスナップショットデータバージョンを公表するように構成された指定オーケストレータを提供し、これにより、前のデータスナップショットが繰り返されている間に同時に実行することができるマルチタスクデータ書き込み能力が可能となる。ゆえに、本発明は、効率的なデータレンダリング及び処理能力、ならびに様々な状況及び懸念事項に適応する柔軟性を提供できる、信頼性が高く、高速で、費用効果が高く、包括的なファイル管理ソリューションを提供する。
【0026】
下記の実施形態及びその態様は、システム、デバイス、及び方法と関連して説明及び図示され、これらは、範囲を限定するものではなく、例示及び図解を目的とする。様々な実施形態では、前述の問題のうちの1つ以上が軽減または除去されているが、別の実施形態は、別の利点または改善を目的としている。
【0027】
本発明の一態様は、公表ファイルシステムまたは方法であって、データプレーン(DP)ネットワークのコントロールプレーン(CP)を制御するように指定された少なくとも1つのオーケストレータと、データの書き込み、オペレーティングシステムの実行、及びオーケストレータの制御を行うように構成されたライタサーバと、ライタサーバにより生成され、DPネットワークを介してアクセス可能なデータをホストするように指定された少なくとも1つのストレージメディアと、DPネットワークを介してストレージメディアへ読み取り専用アクセスを有するように指定された少なくとも1つのリーダサーバと、を備え、ライタサーバにより実行されるように構成された書き込みプロシージャは、少なくとも1つのデータスナップショットバージョンを生成し、オーケストレータは、リーダサーバがDPネットワークにアクセスしてデータスナップショットバージョンを公開することを可能にする公表コマンドを受け入れるように構成され、新たなデータバージョンは、ライタサーバにより更新され、別の公表コマンドがオーケストレータにより受け入れられるまで、リーダサーバから隠され得る。リーダサーバは、異なる場所に配置され得、異なるレジリエンシドメインにわたりオーケストレーションが割り当てられ、同時に、オーケストレーション割り当てでは、異なるレジリエンシドメインを考慮することで、さらにシステムバランスの維持が考慮され得ることが認識される。
【0028】
本発明のいくつかの実施形態によれば、DPネットワークを介してデータスナップショットを公開することにより、即座のシステム応答及び短縮したレイテンシが可能となる。さらに、少なくとも1つのメディアストレージは、読み取り専用のメディアストレージスタックであり得、及び/またはデータは、少なくとも2つのメディアストレージにバックアップされる。
【0029】
本発明のいくつかの実施形態によれば、複数のデータスナップショットバージョンが書き込まれ得ると同時に、リーダサーバには、DPネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される。
【0030】
本発明のいくつかの実施形態によれば、オーケストレータは、ライタサーバにより作成された特定のスナップショットデータバージョンを認識するように構成され、よって、DPネットワークを介して複数のリーダサーバに、均一かつ信頼性の高いデータスタックを提供するように構成される。本発明のいくつかの実施形態によれば、オーケストレータにより新たなデータスナップショットバージョンが公表されると、リーダサーバは、割り当てメタデータをリフレッシュするように構成される。本発明のいくつかの実施形態によれば、システムまたは方法は、データスナップショットバージョンを作成し、単一のライタサーバを使用して複数のリーダサーバ(複数可)による並列読み取りを可能にするために、LVMを使用するようにさらに構成される。本発明のいくつかの実施形態によれば、ライタサーバは、マルチパス接続を使用して少なくとも2つのリーダサーバとインタラクトするように構成され得る。あるいは、DPネットワークを介してアクセス可能なリーダサーバまたはライタサーバと、オーケストレータとの通信は、当該デバイスのそれぞれにインストールされた指定ソフトウェアコンポーネントを使用して行われる。
【0031】
本発明のいくつかの実施形態によれば、システムの通常使用は、リーダサーバ(複数可)により行われるAIトレーニングまたは他の大量計算のパフォーマンスを実行するために利用されるように構成される。
【0032】
本発明のいくつかの実施形態によれば、メディアストレージへのパスはダイレクトであり、各メディアストレージは、RAID、暗号化、論理ボリュームマネージャ(LVM)、及びデータ削減などの必要なストレージスタックサービスを実行するように構成される。本発明のいくつかの実施形態によれば、ライタサーバは、RAIDストレージスタックコンポーネント(SSC)を利用するように構成され得、RAID SSCは、ストレージメディアの複数の指定部分に由来するデータ冗長性を提供するように構成される。
【0033】
本発明のいくつかの実施形態によれば、リーダサーバは、レイテンシを短縮するために、メタデータ及びデータをRAMにキャッシュするように構成される。本発明のいくつかの実施形態によれば、データスナップショットを作成し、単一のライタサーバを使用して複数のリーダサーバ(複数可)による並列読み取りを可能にするために、シンプロビジョニング層を使用するように、さらなる構成が行われる。
【0034】
本発明のいくつかの実施形態によれば、オーケストレータは、アドミニストレーションプロトコルを使用して各サーバとインタラクトするように構成され得、ストレージメディアは、ソリッドステートドライブ(SSD)ベースであり得、ストレージメディアは、ストレージクラスメモリ(SCM)ベースであり、ストレージメディアは、ランダムアクセスメモリ(RAM)ベースであり得、ストレージメディアは、ハードディスクドライブ(HHD)ベースであり得、オーケストレータは、物理コンポーネントであり得、オーケストレータは、クラウドベースサービス(SaaS)であり得、及び/または各サーバ上の動作は、全体的または部分的に、データ処理ユニット(DPU)により実施され得る。
【0035】
本発明のいくつかの実施形態は、本明細書にて添付の図面を参照して説明される。図面を伴った説明により、いくつかの実施形態がどのように実施され得るかが、当業者に明らかになる。図面は例示的な説明を目的としており、本発明の基本的理解に必要とされる以上に詳細に、実施形態の構造詳細を示す試みは行われていない。
【図面の簡単な説明】
【0036】
図1】ネットワーク接続ストレージ(NAS)の概略図を成す。
図2】クラスタ化ファイルシステム(CFS)の概略図を成す。
図3】本発明のいくつかの実施形態による、公表ファイルシステム(PFS)の概略図を成す。
図4】本発明のいくつかの実施形態による、PFSの一般的なアーキテクチャの概略図を成す。
【発明を実施するための形態】
【0037】
以下の発明を実施するための形態では、本発明の完全な理解を提供するために、多くの具体的な詳細が述べられている。しかしながら、これらの具体的な詳細がなくとも本発明を実践できることが、当業者には理解されよう。他の例を挙げると、周知の方法、プロシージャ、及びコンポーネント、モジュール、ユニット、及び/または回路は、本発明を曖昧にしないように、詳細には説明されていない。一実施形態に関して説明されるいくつかの特徴または要素は、別の実施形態に関して説明される特徴または要素と組み合わされてもよい。明確にするために、同じまたは類似の特徴または要素については、繰り返し論述されない場合がある。
【0038】
本発明の実施形態は以下に限定されないが、例えば、「処理する(processing)」、「演算する(computing)」、「計算する(calculating)」、「決定/特定する(determining)」、「確立する(establishing)」、「分析する(analyzing)」、「確認する(checking)」、「設定する(setting)」、または「受信する(receiving)」などの用語を使用する論述は、コンピュータのレジスタ及び/またはメモリ内の物理量(例えば電子量)で表されるデータを、コンピュータのレジスタ及び/またはメモリ、あるいは動作及び/またはプロセスを実行する命令を格納し得る他の情報非一時的ストレージメディア内の物理量で同様に表される他のデータに、処理する及び/または変換するコントローラ、コンピュータ、コンピューティングプラットフォーム、コンピューティングシステム、または他の電子コンピューティングデバイスの動作(複数可)及び/またはプロセス(複数可)を指し得る。
【0039】
明示的に述べられない限り、本明細書で説明される方法の実施形態は、特定の順序または連続に制約されない。さらに、説明される方法の実施形態またはその要素のうちのいくつかは、同時に、同時点に、または並行して、起こり得るまたは実行され得る。
【0040】
本明細書で使用される「コントローラ」という用語は、中央処理装置(CPU)またはマイクロプロセッサを備え得、またいくつかの入出力(I/O)ポートを備え得る任意の種類のコンピューティングプラットフォームまたはコンポーネントを指す。
【0041】
ここで図1を参照すると、図1は、従来のネットワーク接続ストレージ(NAS)10を概略的に示す。図示されるように、NAS10は、サーバ(複数可)100とストレージメディア(複数可)104との間の接続を仲介し、規制し、管理するように指定された少なくとも1つのコントローラ102を備える。ファイルサービスがコントローラ102により提供され、コントローラ102は、例えば、ストレージメディア104に格納されている任意の特定のファイルの位置を特定し、ファイルを圧縮/抽出し、サーバ100へ/サーバ100からファイルを送信し、またはファイルのレンダリング及び制御に関する任意の必須演算を実行し得る。コントローラ102は、一定かつ高速のデータ転送速度を提供するために、その能力が制限されていることから、NAS10のパフォーマンスを低下させる「ボトルネック」コンポーネントとして機能する。
【0042】
ここで図2を参照すると、図2は、従来のクラスタ化ファイルシステム(CFS)20を概略的に示す。図示されるように、CFS20は、少なくとも1つのストレージメディア(複数可)204を備え、これは、ブロックストレージ202内にスタックされ、少なくとも1つのサーバ200に接続され得る。CFS20は、複数のサーバを同じDPネットワークで同時に動作させることが可能であり得る。このような同時動作を可能にするために、CFS20は、「ロック」の複雑なプロトコルを管理し、言い換えると、CFS20により実行された、または実行されているすべての動作が確実に調整されるように指定された特定のロックが解除された後にのみ、データを変更/読み取ることができる。当該システムは、通常、ハイパフォーマンスコンピューティング(HPC)構成で実施され、適切なパフォーマンスを提供する。それにもかかわらず、このようなシステムは、頻繁にロックを作成する必要性から大幅なレイテンシが生じるため、AIトレーニング及び複雑な分析の規制及び調整にはあまり効果的ではない。さらに、参加しているすべてのサーバからロック許可を要求して取得する必要があるため、かなりの量のコンピューティングリソースを要し、したがってCFS20のパフォーマンス及び速度が低下する。
【0043】
ここで図3を参照すると、図3は、いくつかの実施形態による、本発明の主題である公表ファイルシステム(PFS)30を概略的に示す。図示されるように、PFS30は、少なくとも1つのメディアストレージ308と、読み取り専用構成に構成された少なくとも1つのリーダサーバ300と、少なくとも1つのオーケストレータ306を制御するように構成されたライタサーバ302とを備え、次に、オーケストレータ306は、PFS30の様々なコンポーネント間のデータを仲介、規制、及び管理するように指定される。いくつかの実施形態によれば、PFS30は、ロックフリーであり、動作するのにコントローラを必要としない低レイテンシ構成を可能にする。さらに、システムの独自の構成により、高度読み取り特化ワークロード能力が提供され、これにより、様々な複雑なアプリケーションを効率的に実行することが可能となる。
【0044】
いくつかの実施形態によれば、リーダサーバ300との通信は、オーケストレータ306を使用して行われ、各リーダサーバ300との通信は有効化されていない。上記に開示されたように、リーダサーバ300は、読み取り専用構成に構成されており、新たなデータを書き込むことはできない。この構成により、AIモデルのトレーニングが、例えばモデルに膨大なデータセットを公開して複数回の反復を実行することにより、可能となる。
【0045】
いくつかの実施形態によれば、オーケストレータ306は、リーダサーバ(複数可)300にアクセス可能なデータプレーン(DP)ネットワークのコントロールプレーン(CP)を制御するように指定され得る。いくつかの実施形態によれば、ライタサーバ302は、オペレーティングシステムを実行するように、及び、例えばデータ管理及びデータ調整に関する様々なタスクを実行するようにオーケストレータ306に命令することにより、オーケストレータ306を制御するように構成され得る。
【0046】
いくつかの実施形態によれば、オーケストレータ306は、物理コントローラデバイスであり得、またはクラウドベースサービス(SaaS)であり得、オーケストレータ306が物理デバイスであるか否かに関係なく、相互接続されたサーバにおけるデータストレージ及びトラフィックを命令及び調整するように構成され得る。
【0047】
いくつかの実施形態によれば、ユーザ304は、ライタサーバ302を使用してデータを書き込むことができ、例えば、ユーザ304は、リーダサーバ(複数可)300などを使用してAIモデルをトレーニングするように指定された参照データセットを作成するために、様々な画像にラベル付けを行い得る。
【0048】
いくつかの実施形態によれば、少なくとも1つのストレージメディア308は、ライタサーバ302により生成され、DPネットワークを介してアクセス可能なデータをホストするように指定される。いくつかの実施形態によれば、ストレージメディア308は、ソリッドステートドライブ(SSD)ベース、クラスメモリ(SCM)ベース、ランダムアクセスメモリ(RAM)ベース、ハードディスクドライブ(HHD)ベースなどであり得る。
【0049】
いくつかの実施形態によれば、ライタサーバ302は、データを書き込み、少なくとも1つのデータスナップショットバージョンを形成するように構成され得、例えば、ユーザ304は、ライタサーバ302を使用してデータのラベル付けを行い、書き込み及び準備などが完了した現在のデータのスナップショットバージョンを記録し得る。
【0050】
いくつかの実施形態によれば、オーケストレータ306は、ライタサーバ300により送信される公表コマンドを受け入れるように構成され得、当該コマンドにより、リーダサーバ(複数可)300は、DPネットワークにアクセスするため、リーダサーバ(複数可)300に、ストレージメディア308に現在格納されている当該データスナップショットバージョンを公開することが可能となり得る。
【0051】
いくつかの実施形態によれば、リーダサーバ(複数可)300は、DPネットワークを介したストレージメディア308への読み取り専用アクセスを有するように指定され、例えば、複数のリーダサーバ300は、AIモデルのトレーニングなどの一環として、メディアストレージ308に格納されたデータに基づいて、サンプリング及び多数の反復を行い得る。
【0052】
いくつかの実施形態によれば、新たなデータバージョンは、ライタサーバ302により更新され、別の公表コマンドがオーケストレータ306により受け入れられるまで、リーダサーバ300から隠され得る。いくつかの実施形態によれば、当該プロシージャは、最小レイテンシで実行されて、即時応答をもたらし得、これにより、システムのパフォーマンスが向上し、非常に高いデータ読み取り速度が提供され得る。
【0053】
いくつかの実施形態によれば、少なくとも1つのメディアストレージ308は、ストレージアレイ310(またはディスクアレイ)とも称され得る読み取り専用メディアストレージスタックであり、ブロックベースストレージ、ファイルベースストレージ、オブジェクトストレージなどに使用され得る。ストレージアレイ310は、サーバ上にデータを格納するのではなく、相当量のデータを格納できる複数のストレージメディア308の集合を使用し得る。
【0054】
いくつかの実施形態によれば、前に開示されたように、ストレージメディア308は、ストレージアレイ310を形成するようにスタッキングされ得、異なる種類のメディアでデジタルデータを保持またはアーカイブするタスクを実行し得る。ストレージメディアの主な種類には、ハードディスクドライブ(HDD)、ソリッドステートディスク(SSD)、光ストレージ、テープなどが含まれ、HDDは、磁気メディアでコーティングされた回転ディスクに対しデータを読み書きするように構成され、SSDは、不揮発性フラッシュメモリチップにデータを格納し、可動部品を有さない。光データストレージは、レーザを使用して、通常は回転光ディスクである光メディアへデータの格納、及び光メディアからデータの取得を行い、テープストレージは、磁気テープにデータを記録する。
【0055】
従来、ストレージアレイは、容量追跡、スペース割り当て、ボリューム管理、スナップショット、エラーの識別及び追跡、暗号化、圧縮などを維持するように、複数のストレージサービスを提供する制御システムを管理するように構成される。このような種類のサービスには、著しいコンピューティング能力、メタデータ、データストレージ、アクセラレータなどが必要である。
【0056】
通常、ストレージアレイは、システムサーバの運用性とは分離されており、専用ハードウェア上でシステム動作及びアプリケーション動作を実施するように構成される。例えば、一般的なストレージアレイハードウェアアーキテクチャには、サーバスタック、ストレージアレイスタック、及びメディアI/Oデバイスが含まれ得る。I/Oデバイスは、ストレージスタックを介してサーバと通信するように構成される。
【0057】
いくつかの実施形態によれば、ストレージスタック310は、オーケストレータ306により制御及び管理されるように構成され、よって、上記で開示されたような膨大なリソースを必要とする統合制御システムを必要としない。
【0058】
いくつかの実施形態によれば、ライタサーバ302により生成されたスナップショットバージョン(複数可)は、少なくとも2つのメディアストレージ308にバックアップされ得る。この冗長性により、データの整合性レベルが向上し、データ損失が発生したいずれの事例においても、適切な軽減手段が提供される。
【0059】
いくつかの実施形態によれば、ライタサーバ302により複数のデータバージョンが書き込まれ得ると同時に、リーダサーバ(複数可)300には、DPネットワークを介して、既に公表された別のデータスナップショットバージョンが公開される。例えば、データサイエンティスト304は、AIモデルをトレーニングするように指定された反復ボリュームを提供するために、複数の画像にラベル付けを行い、データセットを準備し得、次に、ライタサーバ302は、当該データセットのスナップショットバージョンをキャプチャして、オーケストレータ306にDPネットワークを介して当該バージョンを公表するように命令し得、次に、サーバ(複数可)300には当該バージョンが公開され得、同時にデータサイエンティストは、ライタサーバ302を自由に利用して別のタスクを実行し、やがてこれにもスナップショットが作成され、公表されるように指定された新たなスナップショットバージョンが作成される。
【0060】
いくつかの実施形態によれば、オーケストレータ306は、ライタサーバ302により作成された特定の書き込みデータバージョンを認識するように構成され得、よって、オーケストレータ306は、複数のリーダサーバ300がDPネットワークを介してアクセス可能な均一でデータ信頼性のあるストレージスタックを提供し管理するように構成され得る。
【0061】
いくつかの実施形態によれば、割り当て方法を使用して、ファイルがストレージメディア308及び/またはストレージスタック310に格納される方法が定義され得る。異なるファイルまたは多数のファイルは、同じディスクに格納され、または予備として別のディスクに保存される。ここで生じる主な問題は、メディアストレージを効率的に使用して、迅速なアクセスを可能にするように、これらのファイルの場所をどのように割り当てるかということである。
【0062】
いくつかの実施形態によれば、オーケストレータ306により新たなデータスナップショットバージョンが公表されると、リーダサーバ(複数可)300は、割り当てメタデータをリフレッシュするように構成され、よって、更新されたスナップショットバージョンの関連ファイルの場所に関する更新されたメタデータが提供され得る。
【0063】
いくつかの実施形態によれば、メディアストレージ308は、ダイレクトパスを有し得、各メディアストレージ308は、RAID、暗号化、論理ボリュームマネージャ(LVM)、データ削減などの必要なストレージスタックサービスを実行するように構成される。
【0064】
いくつかの実施形態によれば、リーダサーバ302は、レイテンシを短縮するために、メタデータ及びデータをRAMにキャッシュするように構成される。
【0065】
いくつかの実施形態によれば、PFS30は、データスナップショットを実行するために、LVMを使用し得、これにより単一のライタサーバ302による並列読み取りが可能となる。いくつかの実施形態によれば、PFS30は、データスナップショットを実行して、単一のライタサーバによる並列読み取りを可能にするために、シンプロビジョニング層を使用するように構成され得る。
【0066】
いくつかの実施形態によれば、上記で開示されたように、ライタサーバ302は、マルチパス接続を使用して少なくとも2つのターゲットサーバ300とインタラクトするように構成される。いくつかの実施形態によれば、マルチパス接続は、より広い帯域幅を提供する際の接続信頼性を改善し向上させるために、使用され得る。
【0067】
いくつかの実施形態によれば、オーケストレータ306と、ライタサーバ302またはリーダサーバ300との通信は、当該サーバのそれぞれにインストールされた指定ソフトウェアコンポーネントを利用することにより、DPネットワークを介して実行され得る。
【0068】
いくつかの実施形態によれば、ライタサーバ302は、ストレージメディア308の複数の指定部分に由来するデータ冗長性を提供するように構成された独立ディスク冗長アレイ(RAID)ストレージスタックコンポーネント(SSC)を利用するように指定され得る。いくつかの実施形態によれば、RAID SSCはさらに、組み合わされた複数のイニシエータパスに由来するデータ冗長性を提供するように構成される。
【0069】
いくつかの実施形態によれば、オーケストレータ306は、アドミニストレーションプロトコルを使用してサーバ(複数可)300/302とインタラクトするように構成され得る。いくつかの実施形態によれば、ストレージメディア308の指定部分は、論理ボリュームマネージャ(LVM)SSCを使用して割り当てられ得る。いくつかの実施形態によれば、ストレージメディア308は、ソリッドステートドライブ(SSD)ベース、クラスメモリ(SCM)ベース、ランダムアクセスメモリ(RAM)ベース、ハードディスクドライブ(HHD)ベースなどであり得る。
【0070】
いくつかの実施形態によれば、少なくとも2つのリーダサーバ300は、異なる部屋、異なる建物、さらには異なる国などの異なる場所に配置されてもよい。この場合、オーケストレータ306により実行されるオーケストレーションプロシージャは、様々なレジリエンシドメインにわたり割り当てられる。例えば、オーケストレータ306は、サイバーセキュリティ、自然災害、財務予測などに関する様々なパラメータを考慮し、適宜データフローを迂回させ得る。いくつかの実施形態によれば、オーケストレータ306により実行され、サーバの割り当てを利用するように構成された当該オーケストレーションプロシージャは、許容範囲のシステムバランスパラメータを維持することを考慮して実行される。
【0071】
いくつかの実施形態によれば、オーケストレータ306は、コントローラデバイスなどの物理コンポーネントであり得、またはクラウドベースサービス(SaaS)であり得、オーケストレータ306が物理デバイスであるか否かに関係なく、相互接続されたサーバにおけるデータストレージ及びトラフィックを命令及び調整するように構成され得る。
【0072】
いくつかの実施形態によれば、各サーバ(複数可)300/302上の動作は、全体的または部分的に、データ処理ユニット(DPU)により実施され得、当該DPUは、加速カードなどの加速ハードウェアであり得、汎用の中央処理装置(CPU)で実行されるソフトウェアと比較した場合にさらに効率的に特定の機能を実行するために、ハードウェア加速は使用され得、よって、汎用CPU上で実行されるソフトウェアで計算され得る任意のデータ変換は、カスタムメイドハードウェアによっても、または両方のいくつかの組み合わせによっても、計算され得る。
【0073】
ここで図4を参照すると、図4は、いくつかの実施形態による、PFS30の一般的なアーキテクチャ400を概略的に示す。図示されるように、様々なコンポーネントが、インタラクトし、DPネットワークを介して個別のスナップショットバージョンを公表する能力を提供するように構成される。例えば、オーケストレーションジョブは、様々なスタックコンポーネントに影響を及ぼし得、次に、SSH、PSRP、Amazon AWS、Microsoft Azure、及びGoogleクラウドなどの様々なクラウドコンピューティングプラットフォーム/暗号化ネットワークプロトコル/アプリケーションプログラミングインターフェイスを介して、変換され、利用される。
【0074】
特定の実施形態を参照して本発明が説明されたが、本説明には、限定的な意味で解釈される意図はない。開示された実施形態の様々な変更、ならびに本発明の代替的実施形態が、本発明の説明を参照すれば、当業者には明らかとなるであろう。したがって、添付の特許請求の範囲は、本発明の範囲に入るこのような変更を網羅することが企図される。
図1
図2
図3
図4
【国際調査報告】