JP2022517890A - コンポーザブルインフラストラクチャにおける記憶装置の故障耐性を維持するための方法とシステム - Google Patents

コンポーザブルインフラストラクチャにおける記憶装置の故障耐性を維持するための方法とシステム Download PDF

Info

Publication number
JP2022517890A
JP2022517890A JP2020573249A JP2020573249A JP2022517890A JP 2022517890 A JP2022517890 A JP 2022517890A JP 2020573249 A JP2020573249 A JP 2020573249A JP 2020573249 A JP2020573249 A JP 2020573249A JP 2022517890 A JP2022517890 A JP 2022517890A
Authority
JP
Japan
Prior art keywords
drive
server
drives
servers
storage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2020573249A
Other languages
English (en)
Inventor
ジー ハンコ、ジェイムス
アンケル、クリストファー
レミー、ジャン－フランソワ
Original Assignee
ツイッター インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ツイッター インコーポレイテッド filed Critical ツイッター インコーポレイテッド
Publication of JP2022517890A publication Critical patent/JP2022517890A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

計算装置（例えば、サーバー）がネットワークまたは他の通信メカニズムを介してストレージグループに編成されたディスクドライブにアクセスするコンポーザブルインフラストラクチャ、そのようなシステムを実装するための装置、そのようなシステムを構成し操作するための方法、及び本発明の方法またはそのステップについての任意の実施形態を実行するためのコードを（非一時的な方法で）格納するコンピューター読み取り可能媒体を備えるシステム（例えば、データセンター）である。通常、ストレージグループは、各ストレージグループのドライブに少なくとも１つの結合された障害メカニズムがあり、ドライブのストレージグループメンバーシップに従ってドライブがサーバーに割り当てられるように決定される（通常、データ項目もサーバーに配置される）。いくつかの実施形態では、サーバーからのデータは、例えば、ＲＡＩＤ技術に従って、少なくとも２つのドライブに冗長性を持たせた方法で格納される。【選択図】図１

Description

本発明は、計算装置（サーバー）がネットワークまたは他の通信メカニズムを介して（サーバーの外部の）ディスクドライブにアクセスする方法およびシステム、ならびにそのような方法およびシステムを実装するためのデバイスに関する。いくつかの実施形態によれば、ディスクドライブはストレージグループに編成され（例えば、各ストレージグループ内のドライブが少なくとも１つの結合された故障メカニズムがあるようなグループ）、ドライブはライブのストレージグループメンバーシップに従ってサーバーに割り当てられる（そして通常、データ項目はまた、サーバーに収納される）。
以下の定義は、特許請求の範囲を含め、本明細書全体に適用される。
「記憶装置」は、データを保存し及び読み出すように構成された装置（例えば、ディスクドライブまたはフラッシュメモリ）を意味する。通常、記憶装置には、論理ブロックアドレス（ＬＢＡ）といくつかのブロックを使用してアクセスする。論理ブロックは、合計ストレージ容量の固定サイズのチャンクである（例えば、５１２バイト又は４０９６バイト）。
「ディスクドライブ」（又は「ドライブ」）は、バルクデータ記憶装置を意味する。ディスクドライブの例として、回転磁気媒体又はフラッシュメモリセルを含むドライブ、又は少なくとも１つの他のデータストレージテクノロジーを実装するドライブが含まれる（ただし、これらに限定されない）。
「ＪＢＯＤ」（又はＪｕｓｔ ａ Ｂｕｎｃｈ Ｏｆ Ｄｉｓｋｓ）は、少なくとも２台のディスクドライブのセットを含むエンクロージャーを示す。エンクロージャーには通常、冗長電源とデータ通信接続が含まれる。
「コンポーザブルインフラストラクチャ」とは、サーバー（それぞれが少なくとも１つの計算要素を実装している）とディスクドライブを含むシステム（データセンターなど）を設計するための技術を意味し、ディスクドライブはサーバーの外部にあり（データネットワークその他の通信メカニズムを使用してサーバーに接続又は結合されていて）、ディスクドライブのサブセットは、個々のサーバーに配分可能（割り当て可能）であり、そして各サーバーは、外部にあって、それに割り当てられているディスクドライブの少なくとも１つを使用する（例えば、データを保存する）ことができる。通信メカニズムは、本明細書では（コンポーザブルインフラストラクチャを有するシステムの）「通信サブシステム」と呼ばれることがある。各サーバーは、少なくとも１つの内部ディスクドライブを含む（例えば、直接含む）こともあるが、そのような内部ディスクドライブ（存在する場合）は、先に記載した（外部にあって割り当て可能な）ディスクドライブの１つではない。例えば、サーバーの少なくとも１つは、そのオペレーティングシステムを起動するためだけに使用される内部ディスクドライブ（本明細書では「ブート」ドライブと呼ばれることもある）を含むことがある。別の例として、サーバーの少なくとも１つに内部ディスクドライブが含まれていない場合がある。別の例として、サーバーの少なくとも１つには、サーバーのオペレーティングシステムの起動以外の少なくとも１つの操作にサーバーが使用する内部ディスクドライブ（例えば、ＤＡＳディスクドライブ）が含まれる場合があるが、これは外部の割り当て可能なドライブの１つではない。ここでは、内部ディスクドライブ（サーバー内部にある）がサーバーのシャーシ内に含まれている場合もあれば、サーバーのシャーシ内に含まれていなくても、サーバーの計算要素（計算サブシステム）に直接配線されている場合もある。上述（この段落）の技術に従って設計されたシステム（例えば、データセンター）は、コンポーザブルインフラストラクチャ（又はコンポーザブルアーキテクチャ）、又はコンポーザブルインフラストラクチャ（又はコンポーザブルアーキテクチャ）を有するシステムと呼ばれることがある。コンポーザブルインフラストラクチャを備えたシステムのドライブは、通常（必ずしもそうとは限らないが）「生の」記憶装置として直接アクセスされるが（サーバー自体によって提供される場合を除いて）、ＮＡＳ及びＳＡＮ環境で従来から利用可能な、ＲＡＩＤ、スナップショット処理、重複排除サービスなどを提供する機能はない。いくつかの実施形態では、コンポーザブルインフラストラクチャを備えるシステムのドライブには、ドライブ上にコンポーザブルインフラストラクチャのサーバーからのデータを保存するために、「生の」記憶装置としてＲＡＩＤコントローラーにより直接アクセスされる。
「サーバー」とは、アプリケーションを実行し、通常はネットワーク（又は他の通信メカニズム）を介して記憶装置（例えば、ディスクドライブ）にアクセスし使用して、データ（例えば、ファイル及び／又はアプリケーション）を保存し及び取り出すように構成された計算装置（コンピューター又はプロセッサー）を意味する。サーバーには通常、アプリケーションを実行するために、プログラム及び／又は構成された少なくとも１つの計算サブシステム（ここでは「計算要素」と呼ぶこともある）が含まれる。
「アダプター」は、記憶装置（例えば、ディスクドライブ）、又は２つ以上の記憶装置を具備する記憶システム（例えば、２つ以上のディスクドライブを含むＪＢＯＤ）を、コンポーザブルインフラストラクチャを備えたシステムの通信サブシステム（例えば、ネットワーク）に接続するように構成された装置を意味する。アダプターの例が、「コンバージドネットワークにおける記憶データトラフィックのバランスをとるための方法及びシステム」と題された米国特許第９，７９４，１１２号に記載されている。
「サーバーインターフェース」は、サーバーを、コンポーザブルインフラストラクチャを備える通信サブシステム（例えば、ネットワーク）と通信させる要素を意味し、「アダプタインターフェース」は、アダプターを、コンポーザブルインフラストラクチャを備えるシステムの通信サブシステム（例えば、ネットワーク）と通信させるアダプターの要素を意味する。サーバーインターフェース（又はアダプタインターフェース）の例として、物理デバイス（つまり、ネットワークインターフェースコントローラー（ＮＩＣ））及び複数のＮＩＣのソフトウェアデファインドラッパー（リンクリンクアグリゲーションの場合）がある。本発明のいくつかの実施形態では、サーバーインターフェース（又はアダプタインターフェース）は、コンバージドネットワーク内にそれ自体のインターネットプロトコル（ＩＰ）アドレスを有するハードウェア又はソフトウェア要素である。
コンポーザブルアーキテクチャの「コンピューティングラック」は、サーバーのラックを意味する。通常、各サーバーには大容量ストレージ用のディスクドライブは含まれず（多くの場合、オペレーティングシステムを起動するためのディスクドライブが含まれている）。
サーバーの「ＤＡＳ」（又は「直接接続ストレージ」）は、（サーバーの）計算要素のバルクストレージ用の１つ以上のディスクドライブを意味し、このような各ディスクドライブ（「ＤＡＳドライブ」と呼ばれることもある）は、サーバーの計算要素（計算サブシステム）に直接配線されている。通常、サーバーの各ＤＡＳドライブは、サーバーのシャーシ内に含まれている。有線接続する例として、ＳＡＴＡ、ＳＡＳ、及びＮＶＭｅが含まれる（ただし、これらに限定されない）。
「データノード」は、スケールアウトアプリケーション（Ｈａｄｏｏｐなど）のストレージ操作を実行するように構成されたサーバー（又はサーバーによって実装された仮想マシン、又はサーバーの他の要素）を意味する。
「スケールアウトアプリケーション」とは、サーバーの動作を、（データネットワーク又は他の通信メカニズムを使用して）このサーバーに接続又は結合された他のサーバーの動作と調整するためにサーバーが実行するように構成されているアプリケーション（通常、サーバーはアプリケーションを実行するソフトウェアでプログラムされている）を意味し、このサーバーは、他のサーバーの少なくとも１つと連携して、（例えば、分散方式で問題を解決するための処理操作を）実行することができる。例えば、分散方式で問題を解決するために、すべてのサーバー（それぞれが同じスケールアウトアプリケーションを実行するように構成されている）は、それらの動作を調整するスケールアウトアプリケーションを実行できる。
「Ｈａｄｏｏｐ」は、Ａｐａｃｈｅ Ｆｏｕｎｄａｔｉｏｎが提供するスケールアウトアプリケーションを意味する。
アプリケーション（例えば、スケールアウトアプリケーション）の「データ配置ポリシー」は、アプリケーションを実行しているサーバーがデータ項目を配置する（例えば、データ項目を１つ以上の他のサーバーに送信する）及び／又はデータ項目を（例えば、サーバーの外部のディスクドライブに）保存する規則を意味する。「データ複製ポリシー」とは、サーバーがこのサーバー外部のディスクドライブに冗長な方法でデータ項目を保存する規則に従うデータ配置ポリシーを意味する。
「ＮＡＳ」（又は「ネットワーク接続ストレージ」）は、外部ファイルサーバーが（つまり、少なくとも１つの他のサーバーの計算要素に）ファイル形式のデータへのアクセスを提供するデータストレージアーキテクチャを意味する。ＮＡＳシステムは通常、ＤＡＳよりもはるかに高いコストではあるが、故障耐性、重複排除、及びスナップショットサービスを提供する。
「ＲＡＩＤ」（元々は「安価なディスクの冗長アレイ」を意味する）、又は「ＲＡＩＤ技術」又は「ＲＡＩＤ機能」は、ここでは、信頼性の高いストレージメカニズムを作成するために、複数のディスクドライブに冗長な方法でデータを保存することで、ディスクドライブ（例えば、信頼性の低いディスクドライブ）を結合する（又は結合する操作を行う）ための技術を意味する。ＲＡＩＤ技術又はＲＡＩＤ機能によって、又は従って、データ項目に（冗長な方法で）データを保存するディスクドライブは、ここでは「ＲＡＩＤアレイ」又は「ＲＡＩＤセット」と呼ぶ。
「ＳＡＮ」（又は「ストレージエリアネットワーク」）は、外部ストレージヘッドがストレージへのブロックレベルのアクセスを提供する（つまり、サーバーの計算要素に提供する）ストレージアーキテクチャを意味する。ＳＡＮシステムは通常、ＤＡＳよりもはるかに高いコストではあるが、故障耐性、重複排除、及びスナップショットサービスを提供する。
「ソフトウェアデファインドストレージ」とは、ソフトウェアモジュール又はシステムが記憶要素を持つサーバーのプロビジョニング（各サーバーの計算要素の提供など）を担当するインフラストラクチャを意味する。
「ストレージグループ」とは、割り当てプール（例えば、交換プール）を提供できる、ディスクドライブのグループ（例えば、プログラムされた計算装置により１つのセットにまとめられたグループ）を意味し、少なくとも１つの一般的な障害シナリオに対応するように構築された場合に、サーバー（又はアプリケーション）のデータ項目へのアクセスが障害から抜け出すことができる。ここで、（サーバー用の）割り当てプールは、サーバーへの割り当てに使用できるドライブのグループを意味する。割り当ての一例としては、ドライブ（以前にサーバーに割り当てられていた）に障害が発生した場合、サーバーへ（障害が発生したドライブの代わりとして）別のドライブを割り当てることが割り当てのインスタンスであり、障害のあるドライブの「交換」と呼ばれることもあるという意味で、交換である。ストレージグループの例として、１つ以上のＪＢＯＤ内のすべてのドライブ、及び１つ以上のストレージラック内のすべてのドライブが含まれる。
ディスクドライブの「一般的な障害」（例えば、ドライブに関連する「一般的な障害」のリスク、懸念のモード、又はシナリオなど）は、ドライブの共通の依存関係の結果として、すべてのドライブが一緒に障害を起こすことを意味する。例えば、単一のラックに設置されたディスクドライブ（ラックがネットワークに接続され、電源接続とネットワークスイッチのセットがラックに接続されている場合）は、ラックの状況に対して共通する依存関係があるため、通常はラックの障害が原因ですべてのドライブに障害が発生する（つまり、ネットワーク経由でアクセスできなくなる）という一般的な障害リスクがある。１つの一般的な障害のリスクが生じるすべてのドライブのセット（又は一般的な障害リスクの単一のセット）は、「コモンモードドメイン」と呼ばれることもある。
コンポーザブルアーキテクチャにおける「ストレージラック」は、ディスクドライブ及び／又はディスクドライブを含むＪＢＯＤのラック、及び随意的に、ドライブ（各ＪＢＯＤＳのドライブを含む）へのアクセスを提供するための装置（例えば、アダプター）を意味する。ストレージラックに（例えば、少なくとも１つのディスクドライブ及び／又はＪＢＯＤとともに）含まれる可能性のあるアダプターの例は、ＤｒｉｖｅＳｃａｌｅのストレージアダプターである。
ディスクドライブ（回転磁気媒体又はフラッシュメモリ）は、通常、コンピューターにバルクデータを保存するために使用される。個々のディスクドライブに障害が発生すると、ディスクドライブに保存されているすべてのデータが失われる可能性がある。重要なデータが１つのディスクドライブにのみ保存され、それに障害が発生した場合、ビジネスの運営に甚大な悪影響を与える可能性がある。その結果、１つの記憶装置に障害が発生してもデータを回復する機能が中断されないようにするために、さまざまな技術が使用されてきた。
歴史的には、計算サーバーのデータを保存するためのディスクドライブは、サーバーに直接接続されている（直接接続ストレージ又は「ＤＡＳ」と呼ばれる）か、又はネットワークを介してファイルサーバー（ネットワーク接続ストレージ又は「ＮＡＳ」）又はブロックストレージヘッド（ストレージエリアネットワーク又は「ＳＡＮ」）に接続されている。ＳＡＮストレージの場合、ブロックストレージヘッドをデータネットワークに接続し、計算サーバーをデータネットワークに接続することで、（データネットワークとは異なるストレージネットワークに接続された）ディスクドライブをブロックストレージヘッドを介してデータネットワークに接続する。各タイプの接続の技術は似ているが、詳細は接続タイプによって異なる。
単一システム上の直接接続ストレージ（ＤＡＳ）の場合、データ損失からのデータの保護は、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）ソフトウェアを実装するハードウェア又はソフトウェア要素のいずれかによって行われ、１つのディスクドライブの損失により、データの損失が生じないようにする。ＲＡＩＤ技術は、それぞれ、ＳＡＮ及びＮＡＳストレージを提供するために使用されるいわゆるストレージヘッド又はファイルサーバーでも同様に使用される。通常は、これらの技術により、データの損失を防止する。ただし、ほとんどの場合、単一のサーバー又はストレージヘッドに障害が発生すると、データへのアクセスを回復するのにかなりの時間がかかる可能性がある。
スケールアウトアーキテクチャと呼ばれる新しいアプリケーションアーキテクチャは、１台のコンピューターでは処理できない大きな問題を解決するために作成された。このようなアーキテクチャでは、多数のコンピューター（通常、それぞれが少なくとも１つのＤＡＳドライブを含む多数の安価なコンピューター）の各々のコンピューターがスケールアウトアプリケーションを実行し、作業の各部を複数のコンピューターに分散し、各部の結果を（例えば、１台のコンピューターに）併合することで求める答えを形成する。コンピューターはサーバーであり、通信メカニズム（例えば、データネットワーク）によって結合されており、各サーバーは、問題を解決するために動作を調整するスケールアウトアプリケーションを実行する。ただし、多くのコンピューターがソリューションに貢献しているため、通常、少なくとも１つが壊れているか、そうでなければ正しく動作していないインスタンスが多くある。多くの場合、壊れたコンピューターからしばらくしてからデータを復元することは可能であるが、一部のデータが利用できない間は、問題の全体的な答えを計算できない可能性がある。データの可用性の問題に対処するための当初のアイデアは、（多くのサーバーにインストールされ、それらの動作を調整する）アプリケーションにより、各サーバーがアイテムを（例えば、サーバーのＤＡＳディスクドライブに）保存し、いずれかのサーバーの障害（例えば、サーバーのＤＡＳディスクドライブの障害）によってデータが失われれないようにし、短期間でも利用できないようにすることを前提として、データの各アイテムが複数のそのようなサーバー（データノードと呼ばれることもある）に確実に提供されるようにすることであった。複数のサーバーのＤＡＳドライブにこのような冗長ストレージがある場合、１台のサーバー自体が失われると、その中で（又はそれに直接配線されたＤＡＳドライブで）複製されていたデータへのアクセスが失われるため、データ複製のための追加のストレージスペースのコストが発生し、個々のサーバー内の（又は直接配線された）ＤＡＳドライブでＲＡＩＤ技術を使用することは逆効果になる。
多くのサーバーとそのディスクドライブをデータセンターラックに設置できること、及び各ラックに電源接続及びネットワークスイッチ一式が備えられていることを認識したうえで、単一のデータセンターラックに設置した結果として一緒に故障する可能性のあるデバイスのグループを考慮に入れて、いくつかのスケールアウトアプリケーションが実装されている。ラックの電源又はネットワーク接続の障害が原因でデータへのアクセスが失われる可能性を回避するために、いくつかのスケールアウトアプリケーション（例えば、Ｈａｄｏｏｐ）では、データの各部分を複数のラックに確実に保存するために、データの各部分（ブロック）を異なるラックのサーバーに配置するデータ配置ポリシーを実装している。ただし、このような方法では、一般的な障害リスクを考慮に入れる方法（例えば、効率的な方法）でサーバーの外部にあるドライブを（例えば、コンポーザブルアーキテクチャの各サーバーに）どのように当てるかについての問題を認識又は対処せず、また、このような方法のデータ配置ポリシーでは、多くの一般的な障害リスクを考慮に入れることができない。例えば、ラック内にコンポーザブルアーキテクチャの装置の複数のセットがあり、各セットが別々の一般的な障害リスクを共有している場合、従来の方法では、そのような別々の共通の障害リスクを考慮に入れることができない。他の例として、従来の方法で単一のデータのコピーを複数のラックのサーバーに配置した場合でも、それらのサーバーすべてが一般的な障害リスクのあるドライブ（例えば、すべてが単一のＪＢＯＤにあるドライブ）にデータを保存している場合、一般的な障害（例えば、すべてのドライブの障害を含めて、単一のＪＢＯＤの障害）により、データにアクセスできなくなる可能性がある。
時間の経過とともに、従来のデータセンター環境は、計算要素と記憶要素を（ＤＡＳに従って）単一のデバイスに配置することで計算要素と記憶要素の相対的な需要が変化したときの調整が困難になったため、ＤＡＳから他の接続タイプ（ＮＡＳやＳＡＮなど）に移行した。スケールアウトアプリケーションのサーバーでＤＡＳストレージを使用すると、データセンターの全体的なコストを削減し、データセンターはＮＡＳとＳＡＮに基づく従来のデータセンターアーキテクチャよりも高いパフォーマンスが提供できたが、ＤＡＳが従来のデータセンターでほとんど放棄されることとなったのと同じような硬直性がもたらされた。
現代のデータセンターは、「コンポーザブルインフラストラクチャ」の新しい概念を使用し始めている。コンポーザブルインフラストラクチャでは、サーバー（データノード）の計算要素は、通信メカニズムを介してストレージ（少なくとも１つのディスクドライブ）に接続される。通信メカニズムは、ネットワーク（例えば、標準データネットワーク）とすることができ、又は、他の通信技術（例えば、ＰＣＩｅ、ここで、「ＰＣＩｅ」は、シリアルコンピュータ拡張バス標準であるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓを表す）を実装することができる。
通常、（コンポーザブルインフラストラクチャの）ディスクドライブの多くは、通信メカニズムを介して各ドライブにアクセスできるように、ＪＢＯＤ（Ｊｕｓｔ ａ Ｂｕｎｃｈ Ｏｆ Ｄｉｓｋｓ）と呼ばれるボックスに集められる。ＪＢＯＤ（又は複数のＪＢＯＤ）は、サーバーと同じラックにインストールすることも、ＪＢＯＤ（又は複数のＪＢＯＤ）とサーバーを別々のラックに配置することもできる。いくつかの点で、この配置は従来のＳＡＮに似ているが、コストを削減して性能を向上させるために、各リモートディスクドライブは、ＲＡＩＤなどの機能を提供できるストレージアレイの一部としてではなく、生のドライブとして提供される。上述したように、スケールアウトアプリケーションアーキテクチャ（各サーバーに少なくとも１つのＤＡＳドライブが含まれる）では、スケールアウトアプリケーションの個々のサーバー内のＤＡＳドライブに又は直接配線されたＤＡＳドライブにＲＡＩＤを実装することは逆効果になるので、（コンポーザブルインフラストラクチャ）のデータ接続メカニズムのＲＡＩＤ機構のラックにより、（スケールアウトアプリケーションアーキテクチャに比べ）欠点の無いコスト的な利点及び性能的な利点が得られる。
したがって、スケールアウトアプリケーションにコンポーザブルインフラストラクチャを使用するとＤＡＳの低コストと高性能を実現できる一方、ストレージと計算装置の比率の変化に対する柔軟な対応が損なわれる。ただし、コンポーザブルインフラストラクチャの従来の実装では、割り当て可能なストレージリソースのプールが十分に大きいことを確認しながら、装置に障害が発生した場合にデータへのアクセスが失われるのをどのように防ぐのかについての問題には対処していない。リソースの割り当てを効果的に行うには、割り当てるリソースのプールをできるだけ大きくすることが望ましい。そうしないと、データセンターはリソースサイロと呼ばれる問題を抱える危険がある。つまり、リソースをサイロに分割し、使用できるサイロを制限することで、必要な割り当てを行うのに十分なリソースが存在しているのにもかかわらず、操作のために使うことのできないサイロ内にそのリソースがあるという状態に陥ることがしばしば生じる。ただし、サーバーへのディスクドライブの割り当てに制約がない場合、１つの装置に障害が発生することで、データ項目が失われるという可能性がある。例えば、サーバーへのディスクドライブの割り当てに制約がなく、アプリケーション（Ｈａｄｏｏｐなど）が１つのデータのコピーを複数のラックのサーバーに配置し、コンポーザブルインフラストラクチャが１つのＪＢＯＤからこれらすべてのサーバーにディスクドライブを提供している場合、１つのＪＢＯＤボックスに障害が発生すると、データにアクセスできなくなる可能性がある（例えば、データを常にアクセス可能に保つというＨａｄｏｏｐの約束に違反する）。本願発明者らは、スケールアウトアプリケーション用のコンポーザブルインフラストラクチャでは、サーバーへのディスクドライブの割り当てに対する厳しい制約も大雑把な制約も望ましくないことを認識している（例えば、リソースサイロの問題その他の非効率をもたらす）、しかし、このような制約は、装置の障害に起因するデータの損失を防止するために必要である。
本発明の一般的な実施形態では、コンポーザブルインフラストラクチャにおけるソフトウェアデファインドストレージプロビジョニングの性能、コスト、及び柔軟性の利点を維持しながら、スケールアウトアプリケーションの耐久性及び可用性の要件を満たすことを保証する方法及びシステムを提供する。
本発明の好ましい実施形態の１つの態様は、ドライブに関連する少なくとも１つの結合された障害メカニズム（例えば、同じＪＢＯＤ内及び／又は同じラック内への設置）に従って、ストレージグループと呼ばれるコレクションへ、ディスクドライブを編成することである。ドライブの割り当てとデータ配置の決定は、ストレージグループの１つにある関連する各ドライブのメンバーシップによって導かれる（例えば、それに応じて行われる）。例えば、ドライブの第１のサブセットが第１の結合された障害リスクにさらされ、ドライブの第２のサブセットが第２の結合された障害リスクにさらされた場合、ドライブは（このドライブの第１のサブセットを構成する又は含む）第１のストレージグループ及び（このドライブの第２のサブセットを構成する又は含む）第２のストレージグループに編成することができ、また、このドライブをサーバーに割り当て、（サーバーによって第１のストレージグループのドライブに保存される）各データ項目の複製がこのサーバーから（ストレージグループのドライブによる記憶装置として）少なくとも１つの他のサーバー送ることを保証するため、またこの第１のサブセットに障害が発生してもデータ項目へのアクセスが排除されないことを保証するためにデータ配置ポリシーが実装される。多くのストレージラックを備えた大規模なデータセンターにおける有用な１つの好ましい実施形態では、ストレージグループは、１つの物理ラック内のすべてのドライブ及びＪＢＯＤで構成される。小規模なデータセンターで有用な別の好ましい実施形態では、各ストレージラック内のＪＢＯＤは、２つ以上のストレージグループに分割される。他の実施形態では、各ＪＢＯＤ、又は各ディスクドライブも、それ自体のストレージグループであるとして指定される。様々な大きさの各ストレージグループは別々の価値が得られるよう定められる。
実施形態の段階において、ドライブ（ストレージグループに編成されている）は、コンポーザブルインフラストラクチャを有するシステム（例えば、データセンター）内のサーバーと共に使用される。各サーバーは、少なくとも１つのアプリケーション（例えば、Ｈａｄｏｏｐ又は別のラック対応スケールアウトアプリケーションなどのスケールアウトアプリケーション）を実行するように構成（例えば、プログラム）される。ドライブは、ストレージグループ（例えば、サーバーごとに、このサーバーに割り当てられたすべてのドライブは、サーバーごとに１つのストレージグループに属する）内のドライブのそれぞれのメンバーシップに従って、（例えば、スケールアウトアプリケーションに従って、又はＲＡＩＤ技術を実装するアプリケーションに従ってＲＡＩＤセットを決定するために）少なくとも１つのサーバーに割り当てられる（つまり、割り振られる）。通常、少なくとも２台のサーバーは、各サーバーが割り当てられているドライブにはアクセスできるが、割り当てられていないドライブにはアクセスできない共通のアプリケーション（例えば、同一又は互換性のあるサーバーで実行されるスケールアウトアプリケーション）を実行し、共通アプリケーションのデータ配置ポリシーは、（例えば、アプリケーションに従って保存されたデータ又はその他のデータ項目の各ブロックが、少なくとも２つの異なるストレージグループに冗長性を持たせて保存されることを保証するために）サーバーに割り当てられたドライブのストレージグループのメンバーシップに従って設定される。例えば、共通アプリケーションがスケールアウトアプリケーションである場合、データ配置ポリシーでは、（最初のサーバーによって保存される）データ項目の複製を第１のサーバーから少なくとも１つの他のサーバーに（この他のサーバーにより保存するために）送信する必要があり、ここで、この他のサーバーは、データ項目が２つの異なるストレージグループ（例えば、ドライブ、ＪＢＯＤ、又はストレージラックの障害によりデータ項目へのアクセスが妨げられないことを保証するために）に冗長性を持たせて保存されることを保証するように選定される。
いくつかの実施形態では、ドライブ（ストレージグループに編成されている）は、コンポーザブルインフラストラクチャを有するシステム（例えば、データセンター）内のサーバー（及び任意的に、各サーバー及び各ドライブの外部にある少なくとも１つのＲＡＩＤコントローラー）と共に使用される。ドライブはサーバーの外部にあり、サーバーに割り当てることができる。サーバーの少なくとも１つ（又は少なくとも１つの前述のＲＡＩＤコントローラー）は、サーバー（又はＲＡＩＤコントローラー）がシステムのドライブを具備するＲＡＩＤセットにデータを保存するために（例えば、データ自体を保存するため、及び／又はデータを保存する少なくとも１つの他のサーバーに配置するために）、ＲＡＩＤ技術を実装できるようにするアプリケーション（例えば、スケールアウトアプリケーションではないアプリケーション）を実行するように構成される。通常、サーバー（又はサーバーと情報交換を行うＲＡＩＤコントローラー）には、少なくとも２つのストレージグループに属するディスクドライブが割り当てられ、サーバーからの冗長性を有するデータを保存する各ＲＡＩＤセット（例えば、ＲＡＩＤ－１又はＲＡＩＤ－１０セット）に、異なるストレージグループに属するドライブが含まれていることを保証する。各ＲＡＩＤセットのドライブには一般的な障害メカニズム（例えば、ＲＡＩＤセットには異なるＪＢＯＤのドライブが含まれ、可能な場合は異なるストレージラックが含まれる）を持たないドライブが含まれるように、ストレージグループを決定し、ドライブを割り当てることができる。いくつかのそのような実施形態では、ＲＡＩＤ技術を実装するために、サーバーのサブシステムは、ＲＡＩＤコントローラーとして機能することができ、サーバー上で実行されるアプリケーションは、ＲＡＩＤホストとして機能することができる。サーバー（又はサーバーの外部にあるＲＡＩＤコントローラー）は、保存されているデータ項目ごとに、異なるストレージグループのドライブがデータ項目のレプリカを保存するように（例えば、データ項目を保存するＪＢＯＤであってそのドライブが単一のストレージグループに属するＪＢＯＤの障害により、サーバーによるデータ項目へのアクセスを排除しないように）ＲＡＩＤセットを構築する。例えば、そのような実施形態では、ｎは、保存される各データ項目の複製係数（例えば、ｎ＝２又はｎ＝３）であり、ＲＡＩＤセットのドライブの数は、単一のストレージグループに属するドライブの１／ｎ以下になるように決定される。したがって、同じデータ項目のレプリカを保持するＲＡＩＤセットのｎ個のドライブは、異なるストレージグループに属す。
本発明のいくつかの実施形態は、コンポーザブルインフラストラクチャを有するシステム（例えば、データセンター）である。他の実施形態は、そのようなシステムを実装するのに有用なデバイス（例えば、サーバー）である。いくつかの実施形態では、システムは、通信メカニズム（例えば、ネットワーク）に結合されたサーバー及びディスクドライブを含み、このドライブは、（通常、ストレージグループの少なくとも１つが、障害メカニズムに少なくとも１つが結合されたドライブで構成されるか又は含むような）ストレージグループに編成され、いずれのディスクドライブもサーバーに直接含まれていない。通常、各サーバーは、アプリケーション（例えば、スケールアウトアプリケーション）を実行するように構成された（例えば、プログラムされた）計算要素であるか、又はそのような計算要素を含む。各サーバーは、ストレージグループ内の各ドライブのメンバーシップに応じて、（例えば、実行するアプリケーションによって）ドライブの別々のサブセットに割り当てられる。通常はまた、各サーバーの操作において（例えば、それが実行するアプリケーションに従って）、前記各サーバーは、（例えば、各サーバー上で実行されているアプリケーションによって実装されている）データ配置ポリシーに従って割り当てられた（すなわち、割り振られた）ドライブにデータを保存し、このデータ配置ポリシーは、（例えば、データの保存されたブロック又は他のアイテムが少なくとも２つの別々のストレージグループに保存されることを保証するために）前記各サーバーに割り当てられた各ドライブのストレージグループメンバーシップに従って設定されている。システムには、どのストレージグループにも含まれていない追加のディスクドライブが含まれることもある（例えば、このサーバーの少なくとも１つは、オペレーティングシステムを起動するために採用されるブートドライブを有するが、このようなブートドライブはストレージグループに編成されているディスクドライブではない）。
いくつかの実施形態では、システムは、管理アプリケーションを実行し、ストレージグループのメンバーシップに従ってシステムのサーバーにドライブを割り当てること、また通常はドライブが割り当てられたサーバーにデータ配置ポリシーを実装することを含む、管理プロセスを実装する管理アプリケーションを実行するアドミニストレーターを含む。アドミニストレーターは通常、管理アプリケーションを実行し、他のサーバー及び／又はシステムの少なくとも１つのＲＡＩＤコントローラーで実行されているアプリケーションと（例えば、ドライブを他のサーバーに割り当て、及び／又はデータ配置ポリシーに従って動作するように他のサーバーを構成する、及び／又はＲＡＩＤコントローラーを構成するために）情報交換するよう構成された（例えば、プログラムされた）サーバーである。
いくつかの実施形態では、サーバー（アドミニストレーターではない）は、コンポーザブルインフラストラクチャと連携して、ストレージグループ内のドライブのメンバーシップに従って、（例えば、他のサーバーごとに特定の使用事例を念頭に置いて）少なくとも１つの他のサーバーへのドライブの割り当てを開始する。これらの実施形態では、他のサーバーは、ドライブの割り当て（及びその後のリリース）を実行すること（及びデータの冗長性を有するストレージを確保するためのデータ配置ポリシーに従って別々のストレージグループにデータを配置すること）を含む、第１のサーバーによって割り当てられたタスクを実装することができ、例えば、第１のサーバーで実行されているソフトウェアフレームワーク（例えば、実行のために多数のサーバーに、多くの場合は短期間に、タスクを展開するためのオーケストレーションシステム）からの要求に応答する。いくつかの実施形態では、この第１のサーバー（アドミニストレーターではない）は、コンポーザブルインフラストラクチャのＲＡＩＤコントローラーによりデータ項目の保存を要求し、ＲＡＩＤコントローラーは、ＲＡＩＤ技術を実装することにより、データ項目を別々のストレージグループのドライブに冗長性を持たせて保存するよう動作する。
一般的な実施形態では、ストレージグループの構成を調整することによって、様々なレベルの故障耐性及びドライブ割り当て（ドライブ交換を含む）の柔軟性を実現することができる。
本発明のいくつかの実施形態では、最大リソース割り当ての柔軟性がデータセンターの主要な目標である場合、単一のアイテムの障害（ラックレベルまで）がデータ項目にアクセスできなくなるという制約を条件として、データセンターのすべてのストレージラックがデータセンターは、ドライブの数とストレージ容量がほぼ同じである２つのストレージグループに分割される。１つのストレージグループからデータセンターの各サーバーにすべてのドライブを割り当て、データ複製（配置）ポリシーを設定して（例えば、サーバーによって実行されているスケールアウトアプリケーションの調整可能なデータ複製ポリシーを調整して）、各データ項目が、（このデータ項目が少なくとも２つのストレージグループに存在するように）少なくとも２つの異なるストレージグループを使用して（少なくとも２つのコンピューティングラック内の）少なくとも２つのサーバーに複製されることを保証し、最大リソース割り当ての柔軟性という目標を実現することができる。ドライブに障害が発生した場合、そのドライブの交換は、故障耐性を失うことなく本質的にデータセンター内のドライブの半分の中から選択することができる（つまり、交換は、データセンターの半分を含むストレージグループ内の任意のＪＢＯＤから行うことができる）。
本発明のいくつかの実施形態では、故障耐性が主要な目標である場合、１つの項目（ラックレベルまで）の障害により、データ項目へのアクセスの可能性を、複数のコピーを用いることで低下させないという意味で、データセンター内のすべてのストレージラックは、ほぼ同じサイズの３つのストレージグループに分割でき、各データ項目は少なくとも３つのストレージグループに配置することができる。すべてが（任意の）１つのストレージグループからの各サーバーに、ドライブを割り当て、少なくとも３つの計算ラック内のサーバーにデータコピーを要求することにより、２つのドライブ、サーバー、ＪＢＯＤ、又はラックに障害が発生しても、データ項目へのアクセスを排除することができない。ドライブの交換が必要な場合、データセンター内のドライブの約３分の１は、データアクセスを損なうことなくドライブを交換することができる。
いくつかの実施形態では、サーバーに割り当てられたすべてのドライブは、同じストレージグループ内にある。これにより、サーバーによって保存された各データ項目が、そのサーバーがデータを保持するために選択したドライブに関係なく、ストレージグループに含まれるようになる。（サーバー上で実行されている）スケールアウトアプリケーションのデータ配置ポリシーも、各アイテムが少なくとも２つの別々のストレージグループに保存されるように、すべてのデータの項目が１つのサーバーにより少なくとも１つの他のサーバーに確実に送信（配置）されるように設定することが好ましい。
スケールアウトアプリケーションが（サーバーによるデータ項目の）データ配置をディスクドライブレベルに制御できるいくつかの実施形態では、このサーバーに割り当てられた（及びこのサーバーによって使用された）ドライブは、複数のストレージグループに属すことができる。別々のストレージグループのドライブがサーバーに割り当てられている場合、（サーバー上で実行されている）スケールアウトアプリケーションのデータ配置ポリシーを、１つの障害によって項目へのアクセスが妨げられることが無いように、各データ項目のコピーがストレージグループ間に広まるように（つまり、各項目が少なくとも２つのストレージグループの各々に保存されるように）設定することが好ましい。
いくつかの実施形態では、１つ以上のアダプターを使用して、（ＪＢＯＤ内の又は別の手段によって接続されている）ドライブをネットワークに結合し、サーバーもネットワークに結合される。ドライブは、アダプターの接続がドライブの障害特性と互換性があるように、ストレージグループに編成されている。本発明の態様では、アダプター、そのようなアダプターと統合されたディスクドライブ（又は他の記憶装置）、そのようなアダプターと統合されたＪＢＯＤ（又は他の記憶装置システム）、及び（プログラムされた及び／又は他の方法で構成された本発明の方法の実施形態を実施する）サーバーが含まれる。
いくつかの実施形態では、本発明は、コンポーザブルインフラストラクチャを有するシステムを構成するための方法であり、システムのディスクドライブが（通常、各ストレージグループのドライブに少なくとも１つの結合された障害メカニズムがあるような）ストレージグループに編成され、ドライブのストレージグループメンバーシップに従って、ドライブをシステムのサーバーに割り当てること（及び通常は、データ項目がサーバーに配置されるようにシステムのデータ配置ポリシーを設定すること）が含まれる。他の実施形態は、そのようなシステムのドライブにデータを保存するための方法（ドライブを含むＲＡＩＤアレイにデータを保存するためのＲＡＩＤ方法を含む）であり、システムのドライブに保存するためにそのようなシステムのサーバーにデータ項目を配置するための方法であり、及びそのようなシステムの装置（例えば、サーバー又はＲＡＩＤコントローラー）を構成又は制御する方法である。他の実施形態は、そのような方法を実行するように構成されたシステム、及びそのような方法を実装するように、又はそのようなシステムで使用するように構成された装置を含む。本発明の態様は、本発明のシステム、アダプター、ディスクドライブ、ＪＢＯＤ、サーバー、又は他の装置の実施形態での運用において実行される方法である。
本発明は、コンポーザブルインフラストラクチャでのソフトウェアデファインドストレージのプロビジョニングの性能、コスト、及び柔軟性の利点を維持しながら、スケールアウトアプリケーション（及びＲＡＩＤ技術を実装するアプリケーション）の耐久性及び可用性（すなわち、故障耐性）を保証するための方法及びシステムを提供する。本発明の代表的な実施形態に従って解決される技術的問題には以下を実装する方法が含まれる。
すなわち、故障耐性、高効率、したがって（つまり、割り当ての制限方法が非効率的であるため、使用可能なストレージが計算装置（サーバー）に割り当てられていない「リソースサイロ」のケースを削減又は排除することにより）コストの削減となる柔軟な（ディスクドライブストレージと計算装置との比率を調整可能な）スケールアウトアーキテクチャ、及び（各計算装置が高性能で動作するのに十分なストレージがあることを保証することによる）高性能を実装する方法である。スケールアウトアプリケーション（及びＲＡＩＤ技術を実装するアプリケーション）の耐久性と可用性（つまり、故障耐性）の要件は、コンポーザブルインフラストラクチャにこのアプリケーションを（本発明の実施形態によるストレージグループを使用して）実装することにより、コスト削減の条件を満たし、コンポーザブルインフラストラクチャでのソフトウェアデファインドストレージの性能と柔軟性を保持することができる。
そして、故障耐性を有し、効率を向上させ、それにより（つまり、割り当ての制限方法が非効率的であるために使用可能なストレージがサーバーに割り当てられない「リソースサイロ」のケースを削減又は排除することにより）コストを削減させたコンポーザブルインフラストラクチャを実装する方法である。（本発明の実施形態による）ストレージグループを使用してコンポーザブルインフラストラクチャを実装することにより、故障耐性、効率の向上、及びコストのメリットの削減という利点が得られ、それによりコンポーザブルインフラストラクチャのソフトウェアデファインドストレージプロビジョニングでの柔軟性（ストレージと計算装置の比率を調整可能）と高性能の利点を維持することができる。
コンポーザブルインフラストラクチャを有する本発明のシステムの実施形態のブロック図である。 本発明の方法又はそのステップの実施形態（例えば、実行するためのコード実行可能ファイル）を実行するためのコードの非一時的記憶装置を実装する、具体的なコンピューター読み取り可能媒体である。
コンポーザブルインフラストラクチャ（及び本発明の実施形態によるその構成及び運用において実行される方法）を有する本発明のシステムの実施形態の例を、図１を参照して説明する。
図１のシステム（データセンター）は、コンポーザブルインフラストラクチャを有する。図１のシステムにおいて、サーバー１、３、及び３０（及び任意的に他のサーバー）、アダプター２１、２３、及び２５（及び任意的に他のアダプター）、ディスクドライブ２８、及びＪＢＯＤ２７及び２９（及び任意的に、例えば、ストレージラック１２に含まれる、他のディスクドライブ及び／又はＪＢＯＤ）もネットワーク２０に結合される。ＪＢＯＤ２２は、アダプター２１によってネットワーク２０に結合され、ディスクドライブ２４は、アダプター２３によってネットワーク２０に結合され、ＪＢＯＤ２６はアダプター２５によってネットワーク２０に結合される。各ＪＢＯＤには複数のディスクドライブが含まれる。システムのいくつかの実施形態にはまた、ネットワーク２０に結合されたＲＡＩＤコントローラー４０が含まれる。
要素１、３、３０、及び４０のそれぞれは、アプリケーションソフトウェアを実行するようにプログラムされたサーバーである。具体的には、サーバー１は、アプリケーションサブシステム４を含むように構成され（例えば、実装したソフトウェアでプログラムされる）、従って、しばしば、アプリケーション４を実行するように構成されると記載される。サーバー３は、アプリケーションを含むように構成され（例えば、実装したソフトウェアでプログラムされる）、従って、しばしば、アプリケーション５を実行するように構成されると記載される。サーバー３０は、アプリケーションサブシステム３１を含むように構成され（例えば、実装したソフトウェアでプログラムされる）、従って、しばしば、アプリケーション３１を実行するように構成されると記載される。ＲＡＩＤコントローラー４０はアプリケーションサブシステム４１を含むように構成され（例えば、実装したソフトウェアでプログラムされる）、従って、しばしば、アプリケーション４１を実行するように構成されると記載される。各サーバーは、サーバーをネットワーク２０に接続するよう構成されたサーバーインターフェース（例えば、サーバー１のサーバーインターフェース１Ａ、サーバー３のサーバーインターフェース３Ａ、及びサーバー３０のサーバーインターフェース３０Ａ）を含む。各サーバーはまた、本発明のどのような実施形態によっても図１のシステムの他のサーバーに割り当てること（又は割り振ること）ができないディスクドライブ（例えば、起動のためにのみ使用されるドライブ）を含むことができる。
各アダプター（例えば、アダプター２１、２３、及び２５）には、アダプターをネットワーク２０に接続するように構成されたアダプタインターフェース（例えば、アダプターがアダプタインターフェイスサブシステムを実装するソフトウェアでプログラムされているか、実装するように構成されている）が含まれる。いくつかの実施形態では、図１のシステムの少なくとも１つの（例えば、各）アダプタインターフェース及び／又は少なくとも１つの（例えば、各）サーバーインターフェースは、物理デバイス（すなわち、ネットワークインターフェースコントローラ（「ＮＩＣ」）として実装することができ、又は、複数のＮＩＣのソフトウェアデファインドラッパー、及び／又は独自のインターネットプロトコル（ＩＰ）アドレスを持つハードウェア又はソフトウェア要素となる。
一般的には、図１システムのサーバーの少なくとも１つ（例えば、要素１、３、３０、及び４０のいずれか、又はネットワーク２０に結合された別のサーバー（図１には不図示））は、アドミニストレーターではないシステムの他のサーバーのアプリケーションサブシステムとは異なるアプリケーションサブシステムを持つアドミニストレーター（以下で説明）として実装される。
サーバー１及び３（及びオプションで他のサーバーも）はラック１０（サーバーのみが含まれているため「コンピューティングラック」）に取り付けられる。要素２１、２２、２３、２４、２５、及び２６は、ラック１１（「ストレージラック」、ディスクドライブとドライブのネットワークへのアクセスを可能にするためのアダプターが含まれているが、サーバーやＲＡＩＤコントローラーは含まれていないため）に取り付けられる。記憶装置２７、２８、２９及びサーバー３０（及び任意的に他の記憶装置及び／又はサーバーも）は、ラック１３に取り付けられる。
ネットワーク２０は、記憶データトラフィックと他の（非記憶データ）トラフィックの両方を伝送するネットワーク（「コンバージドネットワーク」と呼ばれることもあるタイプの）ネットワークである。１つの実施形態では、ネットワーク２０は、ネットワークに結合されたサーバー（例えば、サーバー１、３、及び３０、及びコントローラー４０）とネットワークに結合された記憶装置との間ですべてのトラフィックが送信されるイーサネットベースのネットワークである。このようなイーサネットベースのネットワークの要素（例えば、サーバー１、３、及び３０、コントローラー４０、及びアダプター２１、２３、及び２５）は、ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）ネットワークプロトコルに従ってネットワークを介して通信するように構成できる。いくつかの実施形態では、ネットワーク２０は、システムのサーバーと記憶装置とを、別のタイプの接続、例えば、ＲｏＣＥ、ファイバーチャネル、インフミバンド、ＰＣＩｅ、又は他の何らかの接続タイプによって結合する。代替的に、ネットワーク２０を、システムのサーバーと記憶装置とを一緒に結合する別の通信メカニズム（例えば、上述のＰＣＩＥ技術）によって置き換える。いくつかの記憶装置は、アダプター（例えば、アダプター２１、２３、及び２５）を介して要素２０に結合され、いくつかの記憶装置（例えば、ＪＢＯＤ２７、ディスクドライブ２８、及びＪＢＯＤ２９）は、アダプター又は個別に実装されたアダプターの使用せずに要素２０に結合される。
コンポーザブルインフラストラクチャのディスクドライブ（例えば、ドライブ２２、２４、２５、２７、２８、２９、及びラック１２のドライブ）は、ストレージグループに編成され、コンポーザブルインフラストラクチャのサーバー（例えば、サーバー１）に、ストレージグループ内のドライブのメンバーシップに従って割り当てることができる。ドライブを割り当てることが可能な各サーバー（例えば、サーバー１、３、及び３０のそれぞれ）は、スケールアウトアプリケーションを実行するようにプログラムされ（例えば、アプリケーション４、５、及び３１のそれぞれはスケールアウトアプリケーションである）、これは、例えば、Ｈａｄｏｏｐ又は別のラック対応スケールアウトアプリケーションとすることができる。スケールアウトアプリケーションに従って、各サーバーは、割り当てられたドライブの１つにデータを保存できる（ただし、割り当てられていないドライブには保存できない）。そのようなサーバーの少なくとも２つが共通のアプリケーションを実行している場合（つまり、サーバーによって実行されるスケールアウトアプリケーションが同一又は互換性のあるアプリケーションである場合）、共通アプリケーションのデータ配置ポリシーは、サーバーに割り当てられたドライブのストレージグループメンバーシップに従って（例えば、アプリケーションに従って保存された各データ又はその他のデータ項目は、冗長性のある方法で少なくとも２つの別々のストレージグループに保存することを補償するために）設定できる。したがって、各サーバーは（サーバーによって保存される）データ項目を、サーバーのそれぞれの１つに割り当てられたドライブ上のサーバーのそれぞれの１つによって、保存するために（例えば、データ項目が少なくとも２つの別々のストレージグループに冗長性を持たせて保存されるようにするため）、サーバーの少なくとも他の１つに（共通アプリケーションのデータ配置ポリシーに従って）配置することができる。
コンポーザブルインフラストラクチャのディスクドライブ（例えば、ドライブ２２、２４、２５、２７、２８、２９、及びラック１２内のドライブ）は、ＲＡＩＤコントローラー４０によって（すなわち、ＲＡＩＤ技術を実装するアプリケーション４１に従って）ストレージグループ内のドライブのメンバーシップに従って、ＲＡＩＤコントローラー４０がアプリケーション４１を実行してドライブのＲＡＩＤセットを（ストレージグループ内のドライブのメンバーシップに従って）決定し、ＲＡＩＤセットのドライブ上の任意のサーバーからのデータアイテムを保存する（又はストレージを発生させる）ように構成されているという意味で、コンポーザブルインフラストラクチャのサーバー（例えば、サーバー１、３、及び３０）に、割り当てることができる。
例えば、１つの実施形態では、サーバー１、３、及び３０のそれぞれにおいて、サーバーに割り当てられたすべてのドライブは、サーバーごとに単一のストレージグループに属する（すなわち、サーバー１に割り当てられたドライブは、第１のストレージグループに属し、サーバー３割り当てられたドライブは、第２のストレージグループに属し、サーバー３０に割り当てられたドライブは、第３のストレージグループに属する）。サーバー１、３、及び３０は共通のアプリケーションを実行し（つまり、アプリケーション４、５、及び３１は同一又は互換性のあるスケールアウトアプリケーション）、共通のアプリケーションのデータ配置ポリシーは（アプリケーションに従って保存されたデータの各ブロック又はその他のデータ項目が、冗長性を持たせた方法で、少なくとも２つの別々のストレージグループに保存されるようにするため）サーバーに割り当てられたドライブのストレージグループメンバーシップに従って設定される。具体的には、データ配置ポリシーは、サーバー１が（第１のストレージグループに属するサーバー１に割り当てられたドライブにサーバー１に保存すべき）データ項目の複製を（データ項目が、サーバー３によって第２のストレージグループに属するサーバー３に割り当てられたドライブに保存され、サーバー３０によって第３のストレージグループに属するサーバー３０に割り当てられたドライブにも保存されるように）サーバー３及び３０のそれぞれに送信することを要求することができる。ストレージグループは、システムのドライブ、ＪＢＯＤ、又はストレージラックに障害が発生しても、データ項目へのアクセスを排除できないことを保証するように、ストレージグループを決定することができる。
通常、コンポーザブルインフラストラクチャのサーバーの１つ（例えば、サーバー１、３、又は３０）は、アドミニストレーターとして動作するように構成（プログラム）される。一般的な実施形態では、アドミニストレーターは、ストレージグループメンバーシップに従ってシステムのサーバーにドライブを割り当てることや、通常は、（例えば、別々のストレージグループ内へ各データ項目を、冗長性を持たせて保存することを保証するために共通のアプリケーションが他のサーバーで実行される）ドライブが割り当てられているサーバーのデータ配置ポリシーを実行することを含む、管理プロセスを実行するアプリケーション（管理アプリケーション）を実行するようにプログラムされている。アドミニストレーターで実行されている管理アプリケーションは、ストレージグループメンバーシップに従ってデータセンターのサーバーにドライブを割り当てること（及び任意的に、データセンターのＲＡＩＤコントローラーに割り当て及びストレージグループの情報を通知すること）を含め、データセンターを構成（又は再構成）することができる。アドミニストレーターは通常、管理アプリケーションを実行し、他のサーバー及び／又はシステムの少なくとも１つのＲＡＩＤコントローラーで実行されているアプリケーションと情報交換するように（例えば、ドライブを他のサーバーに割り当てたり、他のサーバーがデータ配置ポリシーに従って動作したりするように、及び／又はＲＡＩＤコントローラーを構成するように）構成（例えば、プログラム）される。管理アプリケーション自体が、サーバーへの割り当てに使用できるドライブとドライブに関連する結合された障害リスクについての知識を持つように構成されている場合、ストレージグループを決定することができ、或いは、ユーザーが特定したストレージグループに従ってユーザーが操作するように構成することもできる。管理アプリケーションには通常、人間のユーザーがストレージグループの決定に制約を人が入力できるようにするユーザインターフェースがある。場合によっては、ユーザインターフェースを使用して、ユーザーがストレージグループを指定することができる。運用中、アドミニストレーターは各サーバーで実行されているアプリケーションと情報交換し、例えば、ストレージグループメンバーシップに従って、コンポーザブルインフラストラクチャのドライブを各サーバーに割り当てる。
例えば、（図１の）サーバー１、３、及び３０でそれぞれ実行されるアプリケーション４、５、及び３１、及びラック１０内の他のサーバーで実行されるアプリケーションは、従来のＨａｄｏｏｐアプリケーションによって実装されるものと同様の機能を、（例えば）管理アプリケーションとして実装されているアプリケーション４と共に（ＨａｄｏｏｐのＲｅｓｏｕｒｃｅＭａｎａｇｅｒ及びＮａｍｅＮｏｄｅと同様の機能を実装している）と共に実装することができる。従来のＨａｄｏｏｐアプリケーションとは異なり、管理アプリケーション（４）は、ストレージグループを決定し（本発明の実施形態による）、アプリケーション５及び３１（及びラック１０内の他のサーバーで実行されているもの）と情報交換し、ドライブがストレージグループメンバーシップに従ってサーバー３及び３０（及びラック１０内の他のサーバー）に割り当てられ、サーバー３及び３０（及びラック１０内の他のサーバー）が、割り当てられたドライブのストレージグループメンバーシップに従いデータ配置ポリシーを実装することを確認する。データ配置ポリシーでは、（１つのサーバー内の）データブロックを他の２つのサーバーにも配置して、３つのサーバーが少なくとも２つ（例えば３つ）の別々のストレージグループのドライブにデータブロックを保存するように要求することができる。アドミニストレーター（サーバー１）は、システムの他のどのサーバーが各データブロックを受信したかを追跡する。
いくつかの実施形態では、管理ソフトウェアは、単一のデバイス（例えば、サーバー）又は２つ以上の別個のデバイス（例えば、２つ以上のサーバー）に含まれることがある、２つ以上の別個の協同部分（例えば、ソフトウェアサブシステム）に分解することができる。したがって、いくつかの実施形態では、本発明のシステムのアドミニストレーターは、２つ以上の別個の装置（それぞれが管理ソフトウェアの別々のサブシステムを実行する）として実装することができる。
アドミニストレーター以外の（本発明のシステムの実施形態の）サーバーは、管理アプリケーションと互換性のあるアプリケーションを実行することができる。又は、アドミニストレーター（サーバー）と他のサーバーがすべて同じアプリケーションを実行していても、アドミニストレーターで実行されているアプリケーションが、他のサーバーで実行されているアプリケーションで有効になっていない（例えば、ストレージグループのメンバーシップに従ってドライブを割り当てる機能と権限、又はデータ配置ポリシーを決定する）特権を持つように（管理アプリケーションとして動作するように）構成されている。
本発明のシステムの実施形態のアドミニストレーターは、システムのサーバー上で実行されているアプリケーションと情報交換して、サーバーがＲＡＩＤ機能を実装することを義務付けることができる。サーバー自体がＲＡＩＤ機能を実行することもできる。あるいは、サーバーは、コンポーザブルインフラストラクチャのＲＡＩＤコントローラー（例えば、ＲＡＩＤコントローラー４０）を使用して、ＲＡＩＤ機能を実行することができる。通常、ＲＡＩＤコントローラー（例えば、ＲＡＩＤコントローラー４０のアプリケーションサブシステム４１）もアドミニストレーターによって設定される。サーバーは、（保存する）データをＲＡＩＤコントローラーに送信することによってＲＡＩＤコントローラーを使用でき、これにより、ＲＡＩＤコントローラーはＲＡＩＤアレイを構築し（ストレージグループのメンバーシップに従ってコンポーザブルインフラストラクチャのドライブを選択することを含む）、それにデータを保存する。
ＲＡＩＤ技術を実装する一般的な実施形態では、サーバー（例えば、図１のサーバー１、３、及び３０のいずれか）は、内部にＲＡＩＤ機能を実装し、コンポーザブルインフラストラクチャを介してアクセスする外部ドライブにデータを保存する（通常、ドライブは、コンポーザブルインフラストラクチャを介して生のドライブとしてサーバーからアクセスできる）。これは、ＲＡＩＤ機能がサーバー（直接接続ストレージの場合）又はストレージアレイコントローラー（ＮＡＳ及びＳＡＮの場合）のいずれかでディスクドライブの場所で実行される従来のシステム（コンポーザブルインフラストラクチャを持たない）とは対照的である。一般的な実施形態では、アドミニストレーターは、サーバー上で実行されるＲＡＩＤ機能（及び一般的には必要な故障耐性のレベル）についての命令をサーバーに（例えば、ネットワーク２０を介して）アサートすることができ、そして、サーバーは決定したＡＩＤアレイ機能を含む（例えば、単一障害点を除外するために、ストレージグループメンバーシップに従いコンポーザブルインフラストラクチャのドライブの選定を含む）ＡＩＤ機能を実装する。
ＲＡＩＤは、（ＰＣハードドライブ上のフォルダーのような）従来のファイルシステム構造でよく使用されるため、計算装置（例えば、サーバー）で実行されているアプリケーションは、データをローカルに保存する以外に、さらなる配置決定を行わず。「ファイルシステム」及び計算装置のＲＡＩＤコントローラー機能（ソフトウェアサブシステム）が、データを保存するためのＲＡＩＤ技術を実装する。本発明の１つの態様は、サーバー中の（通常はソフトウェアであるが、代替的にハードウェアアクセラレーションにより又は完全なハードウェアを使用する）ＲＡＩＤコントローラー機能の性能であり、又はコンポーザブルインフラストラクチャのリモートドライブ（ストレージグループに編成）を使用して、リモートドライブに冗長性を持たせて（ストレージグループ中のドライブのメンバーシップに従って）データ保存するサーバーの外部のＲＡＩＤコントローラー機能の性能である。ドライブは、コンポーザブルインフラストラクチャなので、使用可能であり割り当て可能である。
いくつかの実施形態では、サーバー（例えば、図１のサーバー１、３、又は３０のいずれか）からのデータは、ＲＡＩＤ技術を使用してリモートドライブに冗長性を持たせて（ストレージグループ情報を使用して）保存され、ＲＡＩＤコントローラー機能は装置（例えば、図１のＲＡＩＤコントローラー４０）によってサーバーの外部に実装され、ＲＡＩＤコントローラー、ドライブ、及びサーバーは、コンポーザブルインフラストラクチャの通信メカニズム（例えば、図１のネットワーク２０）を介して結合される。従来の外部ＲＡＩＤコントローラーには、既知の障害関係を持つドライブのセットが事前に割り当てられている。一方、ここで説明する実施形態によれば、ＲＡＩＤコントローラーは、ストレージグループ情報を用いて、コンポーザブルインフラストラクチャからドライブを識別し（そしてそれらを組み合わせてＲＡＩＤアレイを構築し）、ドライブ上に（例えば、障害の独立性を確保するために）、（サーバーからの）データの冗長性を持たせたＲＡＩＤストレージを実装する。これらの実施形態では、ＲＡＩＤコントローラーは、通常、ＲＡＩＤアレイを構築するために、ドライブのストレージグループについて（例えば、アドミニストレーターによって）通知される。例えば、ＲＡＩＤコントローラーは、提供されたストレージグループ情報を使用してＲＡＩＤアレイを構築するように適切にプログラムすることができる（例えば、適切にプログラムされたサーバーエージェントを含むことができる）。
一般的な実施形態では、各サーバーのアプリケーションサブシステム（例えば、サーバー１、３、又は３０のそれぞれのアプリケーションサブシステム４、５、又は３１）、又は（コンポーザブルインフラストラクチャを備えている）データセンターの一部のサーバーの各サーバーは、サーバーによるデータセンター（例えば、本発明の実施形態に従ってサーバーに割り当てられたディスクドライブ）の通信メカニズム（例えば、ネットワーク２０）に接続されたディスクドライブへのアクセスを開始するように構成され、そして、データセンターの少なくとも１つのＲＡＩＤコントローラーのアプリケーションサブシステム（例えば、アプリケーションデータセンターのＲＡＩＤコントローラー４０のサブシステム４１）は、データセンターの通信メカニズム（ネットワーク２０など）に結合されたディスクドライブにアクセスして、データセンターのサーバーからのデータを（ドライブのストレージグループメンバーシップに従って）冗長性を持たせてドライブＲＡＩＤアレイに保存するように構成されている。通常の操作では、システムのアドミニストレーターはシステムのドライブのストレージグループメンバーシップのアプリケーションサブシステムに通知している。
通常、サーバーにドライブを割り当てるためにコンポーザブルインフラストラクチャを使用するかどうかの決定は、サーバーの特定の使用例を念頭に置いて、アドミニストレーター（又はサーバーの外部にある別のデバイス）によって行われる。例えば、サーバー１のアプリケーションサブシステム４は、サーバー１（アドミニストレーターとして動作）がストレージグループ内のドライブのメンバーシップに従ってディスクドライブを図１システムの他のサーバーに割り当てる（通常はデータ配置ポリシーを決定及び／又は実装する）管理アプリケーションを実装する。しかしながら、本発明のいくつかの実施形態では、ドライブを１つ以上のサーバーに割り当てる（及び／又は、割り当てられたドライブを使用して１つ以上のサーバーがＲＡＩＤ技術を実装する）決定は、例えば、サーバー自体によって、例えば、ソフトウェアフレームワーク（例えば、多くの場合、短期間で実行される、タスクを多数のサーバーにデプロイして実行するためのオーケストレーションシステムである、Ｋｕｂｅｒｎｅｔｅｓ）による要求に応じて実行される。（例えば、Ｋｕｂｅｒｎｅｔｅｓ又は同様のソフトウェアによって）それに割り当てられたタスクを実行するために、サーバー（例えば、図１のサーバー１、３、及び３０のいずれか）は、（ストレージグループのメンバーシップに従って）タスクの割り当てに合致した１つ以上のサーバーへのディスクドライブの割り当てと解放を管理することができる。
従来のスケールアウトアプリケーションソフトウェアでは、サーバーは通常ＤＡＳドライブを持つものとしてモデル化されているため、個々のサーバーのドライブに一般的な障害ドメインは、それを含むサーバーのシャーシである。各サーバー（及びそこに含まれる各ＤＡＳドライブ）の障害ドメインは、サーバーが存在するラックに従って管理される場合があり、１つのラックのデータの冗長性を有するコピーが第２のラックに配置される。コンポーザブルインフラストラクチャ内のサーバーで使用される場合（サーバーの外部に割り当て可能なディスクドライブがある場合）、このようなスケールアウトアプリケーションソフトウェアは、スケールアウトアプリケーションのデータ配置ポリシーでは予期されない結合された障害を引き起こす可能性がある。しかしながら、本発明の実施形態に従って、そのような各サーバーにすべてのドライブを割り当てることによって（例えば、サーバーごとに単一のストレージグループのみからドライブを割り当てることによって）、結合された障害ドメインは、アプリケーションの一般的なデータ配置により守られることになる。
例えば、コンポーザブルインフラストラクチャを備えたデータセンターには、計算サーバーでいっぱいのラック（「コンピューティングラック」）と、ディスクドライブのＪＢＯＤでいっぱいのその他のラック（「ストレージラック」）が含まれることがある。各コンピューティングラック内のすべてのサーバーが特定のストレージラックからのドライブのみに割り当てられている場合、データが少なくとも２つに保存されるようにサーバーにデータを配置する、従来のデータ配置ポリシー（例えば、従来のＨａｄｏｏｐデータ配置ポリシー）は、データの少なくとも１つのコピーがサーバーに関連付けられたストレージラックの外部に存在することも保証する。したがって、単一のドライブ、サーバー、ＪＢＯＤ、コンピューティングラック、又はストレージラックに障害が発生しても、データへのアクセスを削除することはできない。本発明の実施形態による記憶グループの使用は、そのような操作を単純化することができ、例えば、各ストレージラック内のすべてのＪＢＯＤ（及びそれによるドライブ）を、ラックごとに一意的にストレージグループにグループ化する。次に、サーバーへのドライブの割り当ては、特定のストレージラック（つまり、ストレージグループ）からコンピューティングラック内のすべてのサーバーに（本発明の実施形態に従って）ドライブを割り当てるだけで簡略化される。本発明によるこの割り当ての例の利点は、スケールアウトアプリケーション（例えば、Ｈａｄｏｏｐ）のデータ配置メカニズムを変更する必要がないことである。ただし、この割り当ての例では、サーバーへのドライブの割り当てにおける柔軟性が制限される。例えば、各コンピューティングラックで必要なドライブが、ストレージラックから供給されるよりも多いか又は少ない場合、残りのリソースが無駄になる可能性がある。
いくつかのスケールアウトアプリケーション（例えば、Ｈａｄｏｏｐ）では、インストールでデータ配置アルゴリズムを変更してデータのコピーの配置を制限し、スケールアウトアプリケーションによって直接モデル化されていない他の結合された障害メカニズムを回避できる。このような機能の多くは、仮想マシン内に実装されたデータノードインスタンスを処理するために導入され、このようなデータノードインスタンスのいくつかは、単一の物理計算サーバーでホストすることができる。これらの機能を使用すると、データの配置に追加の制約を課して、単一のデータ項目の２つのコピーを指定されたデータノードのセット内のメンバー（例えば、物理サーバー上の２つの仮想マシン）に配置できないようにすることができる。スケールアウトアプリケーションにおける結合された障害を防止するために、（つまり、本発明の実施形態に従って新しい方法を使用し）これらの機能をストレージグループと組み合わせることができる一方、リソースの浪費を避けるために、サーバー及びドライブの割り当てに大きく柔軟性を持たせている。
例えば、多くのストレージラック及びコンピューティングラックを備えた大規模なデータセンターを想定する。さらに、ストレージグループは、多くのストレージグループが利用できるように、各ストレージグループが整数個のストレージラック全体（すなわち、「ｉ」番目のストレージグループはＮｉ個のストレージラック全体で構成され、ここで、Ｎｉは整数であり、インデックスｉはストレージグループの数の範囲である）であるように（本発明の実施形態に従って）決定されると仮定する。次に、１つのストレージグループからサーバーにすべてのディスクドライブを割り当て、（本発明の実施形態により）スケールアウトアプリケーションのデータ配置ポリシーを変更して、すべてのデータ項目を、各アイテムが少なくとも２つの異なるストレージグループに保存されるようにし、サーバーに送信するようにして、ドライブ、ＪＢＯＤ、又は、ストレージラックの障害によりデータ項目へのアクセスを排除できないようにすることを保証する。少なくとも２つのコンピュートラック内のサーバーにコピーがあることを保証するというスケールアウトアプリケーションの通常のポリシーと組み合わせると、ドライブ、サーバー、ＪＢＯＤ、ストレージラック、又はンピューティングラックの障害によって任意のデータ項目へのアクセスを排除できないことを保証することができる。加えて、各ストレージグループ内のストレージラックの数（Ｎｉ）の選択に応じて、サーバーに関連付けられた（割り当てられた、又は割り付けられた）ドライブは、必要な数（例えば、所定の多い数）のストレージラックに由来し、したがって、リソースの浪費の問題は本質的に排除される。
本明細書の記載から、（いずれか１つのラックが記憶装置と計算装置の両方を含むことを妨げるのではなく）個々のラック内の記憶装置と計算装置を組み合わせても本発明の適用性及び価値が変わらないことは当業者には明らかであろう。例えば、スケールアウトアプリケーションが小さな計算問題で使用され、すべての記憶リソース（ＪＢＯＤを含む）と計算リソースが１つのラック（例えば、図１のラック１１）に収まると仮定する。本発明は、（すべてのリソースを含むため）１つのラックの障害に対する保護を行うことはできないが、それでも、ラック内の任意の単一の要素の障害に直面しても、（十分なリソース、例えば、ＪＢＯＤやサーバーが利用可能なとき）ＪＢＯＤのセットを２つ以上のストレージグループに分割することで、データへのアクセス可能性を保証するために使用することができる。この環境では、１つのストレージグループ各サーバーのすべてのドライブが割り当てられる。次に、スケールアウトアプリケーションのデータ配置ポリシー（本発明の実施形態による）を構成して、データの各項目が少なくとも２つの別々のストレージグループを使用して少なくとも２つのサーバー上に複製されることを保証することにより、アドミニストレーターは、ラック内のサーバー、ドライブ、又はＪＢＯＤのいずれの障害においてもデータ項目へのアクセスが排除されることはないことを保証することができる。
通常のスケールアウトアプリケーションは、保存するデータがあるサーバーのみに基づいてデータ配置を決定するため、サーバーに割り当てられたすべてのドライブが同じストレージグループにあるストレージグループの使用例について説明した。これにより、サーバーがデータを保持するために選択したドライブに関係なく、サーバーによって保存された各データ項目がストレージグループに含まれることが保証される。このような例では、スケールアウトアプリケーションのデータ配置ポリシーは、すべてのデータ項目が１つのサーバーから少なくとも１つの他のサーバーに送信され、各項目が少なくとも２つの別々のストレージグループに保存されるように設定されることが好ましい。しかしながら、スケールアウトアプリケーションがデータ配置をディスクドライブレベルに制御する方法を有する場合、本発明のいくつかの実施形態は、サーバーによって使用されるドライブが複数のストレージグループ由来する（すなわち、属す）ことを可能にする。これらの実施形態では、スケールアウトアプリケーションのデータ配置ポリシーにより、障害が生じてもデータ項目へのアクセスが妨げられないことを保証するために、個々のデータ項目のコピーがストレージグループ間で分散される（すなわち、各項目が、少なくとも２つのストレージグループのそれぞれに保存される）ことを保証するよう（例えば、アドミニストレーターによって）設定される。したがって、いくつかの実施形態では、サーバーに割り当てられたドライブのいくつかは、異なるストレージグループにある。
いくつかの好ましい実施形態では、１つ以上のアダプター（例えば、図２のアダプター２１、２３、及び２５）は、（ＪＢＯＤ内の又は別の手段で接続されている）ドライブを、（サーバーも通信メカニズムに結合されている）コンポーザブルインフラストラクチャを備えたシステムの通信メカニズム（ネットワークなど）に結合するために使用され、そして、ドライブは、アダプターの接続がドライブの障害特性と互換性があるようにストレージグループに編成される。この場合、障害の独立性を維持するために、アダプターは、各アダプターが１つのストレージグループからのドライブのみにサービスを提供するようにアダプターを接続することができる（例えば、アダプター２１が１つのストレージグループからのドライブにサービスを提供するようにストレージグループを決定でき、アダプター２３が第２のストレージグループからのドライブ（ドライブ２４を含む）にサービスを提供し、アダプター２５が第３のストレージグループからのドライブにサービスを提供するようにストレージグループを決定できる）。例えば、各アダプターは１つ以上のＪＢＯＤに接続できるが、同じストレージグループにそのドライブがあるＪＢＯＤＳにのみ接続できる。たとえ１つのＪＢＯＤ又は複数のＪＢＯＤに接続されているそのようなアダプターが１つしかなくても、少なくとも２つの別々のストレージグループを用いて少なくとも２つのサーバーにデータの各項目が複製されているとすれば、アダプター（又は、いずれかのＪＢＯＤ）に障害が発生しても、そこに保存されているデータ項目へのアクセスを排除することはできない。しかしながら、（上述の米国特許番号９，７９４，１１２に記載されている通り）それに伴うアダプターの障害をさらに低減させ、アダプター間でのネットワークのトラフィックをバランスさせるために、ドライブのセットにアクセスさせる（すべて、ただ１つのストレージグループからの１つのドライブにサービスを提供する）複数のアダプターを用いることが好ましい。
少なくとも１つの記憶装置（例えば、ＪＢＯＤ）内の少なくとも１つのディスクドライブを、コンポーザブルインフラストラクチャを有するシステムの通信メカニズム（例えば、ネットワーク）に結合するために１つ以上のアダプターが使用されるいくつかの実施形態では、少なくとも１つのアダプターは、少なくとも１つのそのような記憶装置と統合されている。例えば、ＪＢＯＤ（例えば、図１のＪＢＯＤ２２）及び少なくとも１つのアダプター（例えば、図１のアダプター２１、及び任意的に、ネットワーク２０に結合されるように構成された別のアダプター）は、通信メカニズムに結合されるよう構成された単一のデバイス（アダプターと統合されたＪＢＯＤ）として実装することができる。本発明の一般的な実施形態の重要な利点の１つは、それらが、割り当て（例えば、置換）のために、従来のシステムよりも大きなプールにリソースをグループ化することを可能にすることである。例えば、サーバーのドライブは常に単一のＪＢＯＤから割り当てられ、ＪＢＯＤに障害が発生した場合にデータが失われないように、各データ項目を複数のＪＢＯＤに保持するスケールアウトアプリケーションを実装できることを想定する。しかしながら、本発明の一般的な実施形態に従ってストレージグループを定義する柔軟性がなければ、そのような配置は通常、リソースの割り当てを非効率にし、及び／又は障害のあるリソースの交換を困難にする。例えば、各ＪＢＯＤに１００台のディスクドライブが含まれ、各サーバーに１３台のドライブが必要であると仮定する。すべてのドライブが同じＪＢＯＤからのものでなければならない場合、ＪＢＯＤ内の９１台のドライブのみを使用することができる（つまり、最大で、７台のｌ３ドライブサブセットを７台のサーバーに割り当てることができる）。残りの９台のドライブは、基本的に無駄になる。しかしながら、（本発明の実施形態によれば）１３のＪＢＯＤからなるストレージグループが決定され、サーバーのドライブが、各サーバーのすべてのドライブが単一のストレージグループからのものでなければならないという制約の下で割り当てられた場合、ストレージグループ内の１３００台のドライブをサーバーに割り当てることができる。
別の例として、サーバーのドライブが常に単一のＪＢＯＤから割り当てられ、いずれかのＪＢＯＤに障害が発生した場合でもデータが失われないように、各データ項目を複数のＪＢＯＤに保持するようにスケールアウトアプリケーションを配置でき、各サーバーには１０台のドライブが必要であると仮定する。この例では、ＪＢＯＤ内のすべてのドライブを使用することが（つまり、サーバーに割り当てることが）できるが、１つのドライブ（サーバーに割り当てられた）１つのドライブに障害が発生した場合、それと置き換えるために、サーバーに割り当てることができるドライブはＪＢＯＤには無くなる。しかしながら、（本発明の実施形態によれば）２つ以上のＪＢＯＤからなるストレージグループが決定され、サーバーのドライブが、各サーバーのすべてのドライブが単一のストレージグループからのものでなければならないという制約の下で割り当てられた場合、ストレージグループ内の（サーバーに割り当てられた）１つのドライブに障害が発生した場合、障害が発生したドライブと置き換えるために、ストレージグループ内の別の装置を利用することができる。
本発明のいくつかの実施形態では、最大のリソースを割り当てる上での柔軟性が主な目標である場合、（ラックレベルまでの）単一の項目の障害によりデータアイテムにアクセスできなくならないようにするという制約を条件として、アドミニストレーター（例えば、管理アプリケーションを実行するように構成された図１のサーバー３、及び３０の内の１つ）は、データセンター（例えば、図１のシステム）内のすべてのストレージラックを、ほぼ同じ数のドライブとストレージ容量を持つ２つのストレージグループに分割することができる。１つのストレージグループのみから各サーバーにすべてのドライブを割り当て、（データ項目が少なくとも２つのストレージグループに存在することとなるように）少なくとも２つの異なるストレージグループを使用して（少なくとも２つのコンピューティングラック内の）少なくとも２つのサーバーに各データ項目を確実に複製させるために、サーバーによって実行されているスケールアウトアプリケーションのデータ配置ポリシーを（例えば、構成可能なデータ配置ポリシーを構成して）設定するすることで、データセンターはこの目標を達成する。ドライブに障害が発生した場合、このような交換は、故障耐性を失うことなく、基本的に、データセンター内のドライブの半分から選択できる（つまり、交換は、データセンターの半分を包含するストレージグループ内の任意のＪＢＯＤから行うことができる）。
代替的に、本発明のいくつかの実施形態では、データセンターの（ラックレベルまでの）任意の単一の項目の障害がデータ項目への近づきやすさを複数のコピーによって低下させないように故障耐性の制約が厳しくなされている場合、アドミニストレーター（例えば、管理アプリケーションを実行するように構成された図１のサーバー１、３、及び３０の内の１つ）は、データセンター（例えば、図１システム）内のすべてのストレージラックを３つのほぼ同じサイズのストレージに分割することができ、各データ項目を少なくとも３つのストレージグループに配置することを求めることができる。各サーバーに、すべてが（任意の）１つのストレージグループからのドライブを割り当て、少なくとも３つのコンピューティングラック内のサーバーにデータのコピーを要求することにより、ドライブ、サーバー、ＪＢＯＤ、又はラックのどの２つに障害が発生しても、データ項目へのアクセスを排除することはできない。ドライブの交換が必要な場合は、データセンターの約３分の１のドライブが、データアクセスの故障耐性を損なうことなく交換するために適切なものとなる。
いくつかの実施形態では、ドライブは、制約条件に基づく方法（本明細書では制約リゾルバと呼ばれることもある）に従ってサーバーに割り当てられ、その結果、（そして好ましくは、例えば、は管理ソフトウェアを実行するアドミニストレーターによって）割り当てを自動的に実装することができ、好ましくは、そのような割り当てにより、１つのラックの障害又はＪＢＯＤの障害によりデータ項目へのアクセスが妨げられるというようなことがないことを保証する。例えば、このようなドライブの割り当て方法には、（通常は管理ソフトウェアを実行しているアドミニストレーターによって自動的に実装される）以下の手順が含まれる。
１つのラックに障害が発生してもサーバーの所定の数又は所定の部分しか実質的な損失とはならないように十分な数のラックに分散している（つまり、マウントされている）サーバーを特定し、ドライブをそのサーバーに割り当てることである。例えば、このステップは、少なくともｎ個のラックに分散しているｓ台のサーバーを特定することで実装でき（ｓとｎは整数、通常はｎ≧２）、サーバーの「ｆｌｏｏｒ（ｓ／ｎ）」はラックの１つに配置し、ドライブをサーバーに割り当てる。ここで、「ｆｌｏｏｒ（ｘ）」はｘ以下の最大の整数を示す。
別の例として、このようなドライブ割り当て方法には、（通常は管理ソフトウェアを実行しているアドミニストレーターによって自動的に実装される）以下の手順が含まれる。
各サーバーに１つのストレージグループからのみドライブが割り当てられ、割り当てられるドライブが少なくともｍ個のストレージグループに分散されるという制約を受けるようにして、（ストレージグループに編成された）ドライブをサーバーに割り当てることである。ここで、ｍは整数（例えば、所定の整数）であり、また好ましくは、ドライブがｓ台のサーバーに割り当てられるとき、ｓは整数であり、ｆｌｏｏｒ（ｓ／ｍ）以下の台数のサーバーが任意の単一のストレージグループからドライブに割り当てられる。したがって、好ましくは、Ｓ台のサーバーにドライブが割り当てられているとき、このことがストレージグループからｆｌｏｏｒ（（ｓ＋１）／ｍ）を超える台数のサーバーにドライブが割り当てられることになる場合、次のサーバー（「ｓ＋１」番目のサーバー）にはどのストレージグループからもドライブが割り当てられることはない。
別の例として、このようなドライブ割り当て方法には、（通常は管理ソフトウェアを実行しているアドミニストレーターによって自動的に実装される）以下の手順が含まれる。
１つのラックに障害が発生してもサーバーの所定の数又は所定の部分しか実質的な損失とはならず、ドライブをそのサーバーに割り当てるのに十分な数のラックに分散しているサーバーを特定することである。例えば、このステップは、少なくともｎ個のラック（通常はｎ≧２）に分散しているｓ台のサーバーを特定することで実装でき、ｆｌｏｏｒ（ｓ／ｎ）台以下のサーバーが１つのラックにある。ここで、「ｆｌｏｏｒ（ｘ）」は、ｘ以下の最大の整数を表す。そして、
各サーバーに１つのストレージグループからのみドライブが割り当てられ、割り当てられるドライブが少なくともｍ個のストレージグループに分散されるという制約を受けるようにして、（ストレージグループに編成された）ドライブをサーバーに割り当てることである。ここで、ｍは整数であり、また好ましくは、ドライブがｓ台のサーバーに割り当てられるとき、ｓは整数であり、ｆｌｏｏｒ（ｓ／ｍ）以下の台数のサーバーが任意の単一のストレージグループからドライブに割り当てられる。
いくつかの実施形態では、ストレージグループ（又は２つ以上のストレージグループのそれぞれ）は、複数の結合された障害ドメインをカプセル化する。例えば、ストレージグループが複数のラックにまたがる（つまり、複数のラックのディスクドライブを含む）場合、ストレージグループ内のすべてのディスクに単一の結合された障害モードはない。その代わり、グループには、（複数のタイプ又はインスタンスの、結合された障害に対応することのある）ドライブの複数の独立した結合された障害ドメインが含まれる。そのような実施形態では、故障耐性を提供し、データセンターの管理をシンプルに維持しながら、（ドライブ割り当てを実装するときに）選択できる（従来のシステムで提供されるよりも）割り当て可能なドライブの大きなプールを提供することができる。従って、いくつかの実施形態では、ストレージグループにはすべてが１つの結合された障害モード（メカニズム）を共有するドライブが含まれる（又はこのようなドライブで構成され）、他の実施形態では、ストレージグループには、共通の結合された障害モード（メカニズム）を共有するドライブと、前記共通の結合された障害モード（メカニズム）を共有しない少なくとも１つの他のドライブとが含まれる。
本明細書の説明を考慮すれば、当業者には、ストレージグループの構成を調整することによって、（本発明の実施形態を実装するとき）様々なレベルの故障耐性及び割り当て及び交換の柔軟性を達成できることが明らかであろう。
次に、ＲＡＩＤ技術を実装する本発明のいくつかの実施形態のさらなる態様について説明する。
従来のＲＡＩＤ技術には、データへのアクセスの損失を回避するためにドライブ全体を他のドライブの複製として指定するものとして、ＲＡＩＤ-１（ミラーリング）とＲＡＩＤ-１０（ミラーリングとストライピング）の２つがある。コンポーザブルインフラストラクチャの個々のドライブが（サーバーの外部にあるドライブがサーバーの少なくとも１つのデータ項目を保存するためのＲＡＩＤセットを構成しているという意味で）サーバーに割り当てられている場合、一般的な障害に関係なく、それぞれＲＡＩＤセットのドライブ（例えば、両方のドライブ）の各々は、単一のＪＢＯＤから取得することができる。ＪＢＯＤに障害が発生した場合、サーバーが実行されたままであっても、サーバーはデータにアクセスしなくなる。ストレージグループは、本発明のいくつかの実施形態では、ＲＡＩＤ-１又はＲＡＩＤ-１０セットの各部分（例えば、半分）の（コンポーザブルインフラストラクチャの）ディスクドライブが異なるＪＢＯＤからのものであること、及び、可能な場合は、さまざまなストレージラックからのものであることを保証するために使用される。いくつかのそのような実施形態では、ｎが（サーバーからの）データをＲＡＩＤセット（ｎは通常２、場合によっては３）のディスクドライブに保存するための複製係数である場合、（ＲＡＩＤを実装するために利用可能なドライブの）ストレージグループセットが（好ましくは、各ストレージグループ内のドライブが少なくとも１つの結合された障害メカニズムを有するように、例えば、ドライブが１つのＪＢＯＤに含まれるように）決定され、ＲＡＩＤセットのドライブは単一のストレージグループに属する（ＲＡＩＤセットに割り当てられた）ドライブの１／ｎ以下になるように決定される。より具体的には、（サーバーのソフトウェア、ファームウェア、及び／又はハードウェアサブシステムであるか、又はサーバーの外部にある可能性がある）ＲＡＩＤコントローラーが、ＲＡＩＤセット内に含むドライブは、コントローラー（例えば、サーバーのコントローラーサブシステム）によって、（ＲＡＩＤセットの）ドライブの１／ｎ以下が単一のストレージグループに属するように、ストレージグループ内の各ドライブのメンバーシップに従って、（保存すべきデータを有する）サーバーに割り当てられる。したがって、記載した実施形態では、ＲＡＩＤセットは、サーバーからのデータがＲＡＩＤセットに保存されるときに、各単一データ項目の複製を保持するｎ個（ここでも通常は２個）のドライブが異なるストレージグループに属するように構築される。これにより、単一のストレージグループ内のドライブ又はＪＢＯＤに障害により、サーバーがデータにアクセスすることを妨げられることはなくなる。ストレージグループにストレージラック（又は２つ以上のストレージラック）内のすべてのドライブとＪＢＯＤが含まれている場合、ラック内のドライブ又はＪＢＯＤの障害（又は、少なくとも２つのストレージラックを含むストレージグループのすべてのストレージラックの障害）により、ＲＡＩＤセット内のデータにサーバーがアクセスすることを妨げられることはない。
次に、本発明のいくつかの実施形態に関する操作の態様を詳細に説明する。
本発明のいくつかの実施形態では、ＪＢＯＤ（したがって、それらに含まれるディスクドライブ）を、データセンターに最初に設置したときに、ストレージグループに自動的に割り当てることができる。１つの好ましい実施形態では、ユーザは（例えば、データセンターのアドミニストレーター上で実行されている管理アプリケーションのユーザインターフェースと情報交換することによって）又はデータセンターのアドミニストレーターは（アドミニストレーター上で実行されている管理アプリケーションの操作によって）、ラックごとに（又は、例えば、ディスクサブネットや共通の最初のネットワークスイッチのような他の親密さの手段ごとに）作成するストレージグループの数を決定するための、デフォルトポリシーを設定する。いくつかのそのような実施形態では、ＪＢＯＤは、作成された各ストレージグループ内のドライブの数及び容量のバランスをとろうとする方法で（ストレージグループに）割り当てられる。いくつかの実施形態では、データセンターの立案者はドライブ及び／又はＪＢＯＤのストレージグループを手作業で設計することができる。
本発明のシステムのいくつかの実施形態では、サーバー及びドライブは、ソフトウェアデファインドストレージシステムにおける制約条件に基づく選択メカニズム（例えば、コンポーザブルインフラストラクチャのアドミニストレーター上で実行されている管理アプリケーションによって実装される制約条件に基づく選択メカニズム）を使用することによって、すべてのドライブが目的の容量とタイプであり、すべてが単一のストレージグループからのものとなるように、コンポーザブルインフラストラクチャを介して接続可能な１つ以上のサーバー（要求された計算容量及びメモリ容量）にドライブを割り当てることによって、一緒に割り当てることができる。このようなメカニズムにより、アドミニストレーターは、お互いに接続しておくべき個々のサーバー及びドライブを識別する仕事（面倒な場合があります）から解放される。加えて、制約条件に基づく選択メカニズム（本明細書では制約リゾルバと呼ばれることもある）には、使用可能なサーバーとドライブ間の接続速度の変動のようなものについて、アドミニストレーターがそのような要素の考慮を明示的に要求することなく、暗黙の考慮事項として含めることができる。
本発明の一般的な実施形態により、データセンターがＤＡＳストレージの低コスト及び高性能、ならびにコンポーザブルインフラストラクチャの柔軟性を保持できるように、コンポーザブルデータセンターインフラストラクチャでスケールアウトアプリケーションを使用できるようにするための単純なメカニズムが提供され、また、データセンター内の単一の要素に障害が発生しても、データへのアクセスが妨げられないことが保証される。
本発明の一般的な実施形態は、すべての装置が単一のラックに収まる非常に小さなシステムから、記憶装置及び計算装置の多くのラックを備えたフルサイズのデータセンターにまでに及び、すべてが利用可能な故障耐性のレベルに到達することが保証される単一のメカニズムを備えている。
本発明の一般的な実施形態により、アドミニストレーターが、コンポーザブルインフラストラクチャの割り当ての柔軟性の利点を保持しながら、単純な高レベルの仕様を使用して、所望のレベルの障害／故障耐性を提供することができる。アドミニストレーターの一般的な実施形態を配置することにより、データ構造全体の障害／故障耐性状態を簡単に評価及び分析することができる。さらに、データセンターに導入された大規模なスケールアウトアプリケーションでの非常に複雑な相互接続のセットにおいても、故障耐性を検証することが非常に簡単になる。対照的に、このような実施形態を使用しない場合、コンポーザブルインフラストラクチャによって提供されるリソース割り当ての自由度が大きいので、大規模なスケールアウトアプリケーションの展開において、結合された障害の機会の組み合わが爆発的に増大する可能性がある。例えば、１つのドライブを（本発明の実施形態によるものではない方法で）他のドライブと交換することにより、特に数千のサーバーと数万のドライブが配備されている場合は、検出の難しい予期せぬ結合された障害の生じること可能性がある。
コンポーザブルインフラストラクチャに配備され、従来のアプリケーションの改善されたバージョンを実装する（例えば、ＲＡＩＤ技術を実装するための）本発明の実施形態により、従来のアプリケーション（及び他の利点）よりも優れた故障耐性を提供することができる。適切に設計された（ストレージグループメンバーシップに従って構築された）ＲＡＩＤセットと共に、従来のＲＡＩＤアプリケーションの改良バージョンを実装するものは（ＲＡＩＤ技術を使用することで）、双方のＲＡＩＤセットで唯一の共通装置がサーバー自体であることを保証することができる。したがって、各データストレージのすべての装置（例えば、ディスクドライブ、又はディスクドライブを含むＪＢＯＤ又はラック）にデータへのアクセスを妨げる可能性があるような障害がないことを検証するのは、すべての装置において（サーバー自身を除く）各データ保存経路が別個のものとなっているので、簡単となる。
本発明の一般的な実施形態は、ＪＢＯＤ、アダプター、又は他の特定の機器を使用して実施することができるが、それらを使用する必要はない。ＪＢＯＤＳがない場合は、個々のドライブを、懸念される特定の一般的な障害モードに対応するストレージグループに配置することができる。例えば、ストレージグループは、共通の電源装置又は共通のネットワーク接続を代理する場合がある。
いくつかの実施形態では、本発明のサーバー（例えば、アドミニストレーター又はＲＡＩＤコントローラーとして構成されたサーバー）は、本発明の方法又はそのステップの実施形態を含む、データに対する様々な操作を実行する、ソフトウェア又はファームウェアでプログラムされ、及び／又は他の方法で構成された、プログラム可能な汎用プロセッサ、デジタル信号プロセッサ、又はマイクロプロセッサであるか、又はそれらを含む。そのような汎用プロセッサは、入力装置、メモリ、及び条件を満たすデータに応答して本発明の方法（又はそのステップ）の実施形態を実行するようにプログラムされた（及び／又は他の方法で構成された）処理サブシステムを含むコンピュータシステムであるか、又はそれらを含むことができる。
本発明の他の態様は、本発明のシステムの任意の実施形態、又はその装置（例えば、ＲＡＩＤコントローラー、記憶装置、アドミニストレーター、又はサーバー）の動作において実行される方法である。
そのような方法の１つは、コンポーザブルインフラストラクチャを有するシステムにデータを保存するための方法であり、このシステムは、通信サブシステム、及び通信サブシステムに結合されたディスクドライブ及びサーバーを含み、このドライブは、前記ドライブに関係する少なくとも１つの結合された障害メカニズムに従ってストレージグループに編成され、前記方法は、以下のステップを含む。
少なくともいくつかのサーバーのセットの各サーバーに、前記ドライブのストレージグループメンバーシップに従った、別のドライブのサブセットを割り当てること、及び
前記セットのサーバーの１つで実行されているアプリケーションに従って、前記サーバーの１つに割り当てられているドライブの１つ以上にデータを保存するが、前記サーバーに割り当てられていないドライブのいずれにもデータを保存しない。
他のそのような方法は、コンポーザブルインフラストラクチャを有するシステムにデータを保存するための方法であり、このシステムは、通信サブシステム、及びこの通信サブシステムに結合されたディスクドライブ及びサーバーを含み、前記ドライブは、前記ドライブに関係する少なくとも１つの結合された障害メカニズムに従ってストレージグループに編成される。前記方法は以下を含む。
サーバーの１つで実行されているアプリケーションに従って、ＲＡＩＤセット内の各ドライブのストレージグループメンバーシップに従ってドライブのＲＡＩＤセットを決定することを含む、ＲＡＩＤ機能を実行し、このＲＡＩＤセットのドライブにデータを、冗長性を持たせて保存すること。
他のそのような方法は、コンポーザブルインフラストラクチャを有するシステムを構成するための方法であり、このシステムは、通信サブシステム、及び通信サブシステムに結合されたディスクドライブ及びサーバーを含み、前記ドライブは、前記ドライブに関係する少なくとも１つの結合された障害メカニズムに従ってストレージグループに編成される。前記方法は以下を含む。
サーバーの１つで実行されている管理アプリケーションに従って、少なくともいくつかのサーバーのセットの各サーバーに、前記ドライブのストレージグループメンバーシップに従ってドライブの別のサブセットを割り当てるステップ。及び／又は、
ＲＡＩＤ機能を実装するようにサーバーの少なくとも１つを構成するステップであって、このステップにはＲＡＩＤセット内の各ドライブのストレージグループメンバーシップに従ってドライブのＲＡＩＤセットを決定することも含まれる。
本発明の別の態様は、データの非一時的記憶を実装するための、そして本発明の方法又はそのステップの任意の実施形態を実行するためのコード（例えば、実行可能なコード）を（非一時的な方法で）記憶する、有形のコンピューター読み取り可能媒体（例えば、ディスク又は他の有形の記憶媒体）である。そのような有形の、コンピューター読み取り可能媒体の例が図２の、本発明の方法又は方法のステップの任意の実施形態を実行するためのコード（例えば、実行可能なコード）を（非一時的な方法で）保存する、コンピューター読み取り可能媒体５０（ディスク又は他の有形の記憶媒体とすることができる）である。
本発明の特定の形態がここに図解され及び記載されているが、本発明は、記載され及び図示された特定の実施形態又は記載された特定の方法に限定されないことを理解すべきである。方法を説明する請求項は、請求項に言語で明示的に記載されていない限り、特定の順序のステップを意味するものではない。

Claims (54)

  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. 前記サーバーは、前記ＲＡＩＤセットのドライブに互換性を持たせてデータを保存させることを含む、前記通信サブシステムに結合されたとき前記ＲＡＩＤ技術を実装するよう構成され、前記ＲＡＩＤセットは、前記ストレージグループの第１番目のドライブ及び前記ストレージグループの第２番目のドライブを含み、前記ストレージグループの第１番目のものは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含み、前記ストレージグループの第２番目のものは、前記結合された障害メカニズムを有するいずれのドライブも含まないことを特徴とする請求項２５に記載のサーバー。
  27. 前記システムはまた、前記通信サブシステムに結合された他のサーバーを含み、前記ドライブの少なくともいくつかは、前記他のサーバーの各々が、割り当てられているドライブの各々にアクセスすることができるが、割り当てられていないドライブのいずれにもアクセスすることができないように、前記他のサーバーに割り当て可能であり、少なくとも１つの前記アプリケーションは、各ドライブのストレージグループメンバーシップに従い前記ドライブのサブセットに前記他のサーバーの各々が割り当てられるように、前記他のサーバーに前記ドライブの少なくともいくつかを割り当てるように、構成されていることを特徴とする請求項２０に記載のサーバー。
  28. コンポーザブルインフラストラクチャを有するシステムを用いるよう構成されたアドミニストレーターであって、前記システムは通信サブシステムに結合されたディスクドライブ及びサーバーを含み、前記サーバーの各々が割り当てられているドライブの各々にアクセスすることができるが、割り当てられていないドライブのいずれにもアクセスすることができないように、前記サーバーに前記ドライブを割り当てることが可能であり、前記アドミニストレーターは、
    前記アドミニストレーターを前記通信サブシステムに結合するよう構成されたサーバーインターフェースと、
    前記ドライブに関連する少なくとも１つの結合された障害メカニズムに従いストレージグループに前記ドライブが編成されるよう、そして前記サーバーの各々に前記ドライブのサブセット内の各ドライブのストレージグループメンバーシップに従い前記ドライブのサブセットを割り当てるよう、前記ドライブを前記サーバーに割り当てるために少なくとも１つの管理アプリケーション動作させるよう結合され構成された少なくとも１つの計算サブシステムと、
    を含むことを特徴とするアドミニストレーター。
  29. 前記ストレージグループの少なくとも１つは、少なくとも１つの結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含むことを特徴とする請求項２８に記載のアドミニストレーター。
  30. 前記管理アプリケーションは、
    前記ドライブのストレージグループメンバーシップに従い設定されたデータ配置ポリシーをセットし、
    前記アドミニストレーターが前記通信サブシステム結合されたとき、前記サーバーの各々と情報交換し、前記サーバーの各々が前記データ配置ポリシーに従い動作するよう構成し、前記サーバーの各々が割り当てられた前記ドライブの１つにデータ項目を保存したとき、前記サーバーの各々はまた、前記データ配置ポリシーに従い前記システムの少なくとも１つの他のサーバーに前記データ項目を保存して、前記ストレージグループの少なくとも２つに、冗長性を持たせて前記データ項目が保存されることを保証し、前記２つのストレージグループの１つは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含み、前記２つのストレージグループの他の１つは、結合された障害メカニズムを有するいずれのドライブも含まないように構成されていることを特徴とする請求項２９に記載のアドミニストレーター。
  31. 前記計算サブシステムは、ドライブが配置された前記サーバーが十分な数のラックに分散され、前記ラックのいずれに障害が生じても前記サーバーの所定の数又は所定の部分しか実質的な損失とはならないように、前記ドライブを配置するよう構成されていることを特徴とする請求項２８に記載のアドミニストレーター。
  32. 前記計算サブシステムは、少なくともｎ個のラックに分散しているｓ台のサーバーに前記ドライブを割り当てるよう構成され、ｓ及びｎは整数であり、前記サーバーのｆｌｏｏｒ（ｓ／ｎ）以下の数の前記サーバーが前記ラックの１つに置かれ、ｆｌｏｏｒ（ｓ／ｎ）は、ｓ／ｎ以下の最大の整数を示し、
    前記計算サブシステムは、前記サーバーの各々が、前記ストレージグループの内の１つからのみドライブが割り当てられていて、割り当てられた前記ドライブは少なくともｍ個の前記ストレージグループに分散されるという制約を受けるよう、前記ドライブを割り当てるよう構成され、ｍは整数であることを特徴とする請求項２８に記載のアドミニストレーター。
  33. 前記計算サブシステムは、少なくともｎ個のラックに分散しているｓ台のサーバーに前記ドライブを割り当てるよう構成され、ｓ及びｎは整数であり、前記サーバーのｆｌｏｏｒ（ｓ／ｎ）以下の数の前記サーバーが前記ラックの１つに置かれ、ｆｌｏｏｒ（ｓ／ｎ）は、ｓ／ｎ以下の最大の整数を示すことを特徴とする請求項２８に記載のアドミニストレーター。
  34. 前記計算サブシステムは、前記サーバーの各々が、前記ストレージグループの内の１つからのみドライブが割り当てられていて、割り当てられた前記ドライブは少なくともｍ個の前記ストレージグループに分散されるという制約を受けるよう、前記ドライブを割り当てるよう構成され、ｍは整数であることを特徴とする請求項２８に記載のアドミニストレーター。
  35. 前記計算サブシステムは、ドライブがｓ台の前記サーバーに割り当てられたとき、ｓは整数であり、ｆｌｏｏｒ（ｓ／ｍ）以下の数の前記サーバーが、いずれか１つのストレージグループからドライブに割り当てられるように、前記ドライブを割り当てるよう構成され、ｆｌｏｏｒ（ｓ／ｍ）は、ｓ／ｍ以下の最大の整数を示すことを特徴とする請求項３４に記載のアドミニストレーター。
  36. コンポーザブルインフラストラクチャを有するシステムで用いるよう構成されたＲＡＩＤコントローラーであって、前記システムは、通信サブシステムに結合されたディスクドライブ及びサーバーを含み、前記ドライブは、前記ドライブに関連する少なくとも１つの結合された障害メカニズムに従いストレージグループに編成され、前記ドライブは、前記サーバーの各々が、割り当てられている前記ドライブの各々にアクセスすることができるが、割り当てられていないドライブのいずれにもアクセスすることができないように、前記サーバーに割り当てることが可能であり、前記ＲＡＩＤコントローラーは、
    前記ＲＡＩＤコントローラーを前記通信サブシステムに結合させるよう構成されたサーバーインターフェースと、
    ＲＡＩＤセット内の前記ドライブの各々のストレージグループメンバーシップに従い前記ドライブの前記ＲＡＩＤセットを決定することを含む、ＲＡＩＤ機能を実装するよう結合され構成されている、少なくとも１つの計算サブシステムと、
    を含むことを特徴とするＲＡＩＤコントローラー。
  37. 前記ＲＡＩＤコントローラーの前記計算サブシステムは、前記ＲＡＩＤコントローラーが前記通信サブシステムに結合されたとき、前記ＲＡＩＤセットの前記ドライブに前記サーバーの１つからデータを保存させることを含む、前記ＲＡＩＤ機能を実装するよう構成され、前記ＲＡＩＤセットは、前記ストレージグループの第１番目のドライブ及び前記ストレージグループの第２番目のドライブを含み、前記ストレージグループの第１番目のものは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなライブを含み、前記ストレージグループの第２番目のものは、前記結合された障害メカニズムを有するいずれのドライブも含まないことを特徴とする請求項３６に記載のＲＡＩＤコントローラー。
  38. 前記ＲＡＩＤコントローラーの前記計算サブシステムは、ｎが、保存される各データ項目の複製係数であり、前記ＲＡＩＤセットの前記ドライブの数は、１つの前記ストレージグループに属する前記ＲＡＩＤセットのドライブの１／ｎ以下になるように決定されるように、前記ＲＡＩＤ機能を実装するよう構成されることを特徴とする請求項３７に記載のＲＡＩＤコントローラー。
  39. コンポーザブルインフラストラクチャを有するシステムにデータを保存する方法であって、前記システムは、通信サブシステムと、前記通信サブシステムに結合されたディスクドライブ及びサーバーとを含み、前記ドライブは、前記ドライブに関連する少なくとも１つの結合された障害メカニズムに従いストレージグループに編成され、前記方法は、
    前記サーバーの少なくともいくつかで構成された１つのセットの各サーバーに、前記ドライブのストレージグループメンバーシップに従い前記ドライブの別々のサブセットを割り当てるステップと、
    前記セットのサーバーの１つで動作しているアプリケーションに従い、前記サーバーの１つに割り当てられているドライブの１つ以上にデータを保存し、前記サーバーの１つに割り当てられていないいずれのドライブにもデータを保存しないステップと、
    を含むことを特徴とする方法。
  40. 前記ストレージグループの少なくとも１つは、少なくとも１つの結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含むことを特徴とする請求項３９に記載の方法。
  41. 前記セットのサーバーで動作しているアプリケーションのデータ配置ポリシーに従い、前記ストレージグループの少なくとも２つに冗長性を持たせて少なくとも１つのデータ項目を保存し、前記２つのストレージグループの内の１つは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含み、前記２つのストレージグループの内の他の１つは、前記結合された障害メカニズムを有するいずれのドライブも含まないことを特徴とする請求項４０に記載の方法。
  42. 請求項３９に記載のアプリケーションを動作させるために、請求項３９に記載されたサーバーの１つにより実行可能なコードを非一時的に保存するコンピューター読み取り可能媒体。
  43. コンポーザブルインフラストラクチャを有するシステムにデータを保存する方法であって、前記システムは通信サブシステムと、前記通信サブシステムに結合されたディスクドライブ及びサーバーとを含み、前記ドライブは、前記ドライブに関連した少なくとも１つの結合された障害メカニズムに従い、ストレージグループに編成され、前記方法は、
    前記サーバーの１つで動作しているアプリケーションに従い、前記ＲＡＩＤセット内の前記ドライブの各々のストレージグループメンバーシップに従い前記ドライブのＲＡＩＤセットを決定することを含む、ＲＡＩＤ機能を実行し、前記ＲＡＩＤセットの前記ドライブに、冗長性を持たせてデータを保存することを含むことを特徴とする方法。
  44. 前記ストレージグループの少なくとも１つは、少なくとも１つの結合された障害メカニズムを有するドライブにより構成されるか又はこのようなドライブを含むことを特徴とする請求項４３に記載の方法。
  45. 前記ＲＡＩＤセットは、前記ストレージグループの第１番目のドライブ及び前記ストレージグループの第２番目のドライブを含み、前記ストレージグループの第１番目のものは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含み、前記ストレージグループの第２番目のものは、前記結合された障害メカニズムを有するいずれのドライブも含まないことを特徴とする請求項４３に記載の方法。
  46. 前記セットの前記サーバーの１つはＲＡＩＤコントローラーであり、前記ＲＡＩＤコントローラーは、前記サーバーの他の１つから前記通信サブシステムを介してアサートされた、保存された要求に応じて前記ＲＡＩＤ機能を実行することを特徴とする請求項４３に記載の方法。
  47. ＲＡＩＤセットのドライブに冗長性を持たせてデータを保存させるために請求項４３に記載のアプリケーションを動作させるために、請求項４３に記載されたサーバーの１つにより実行可能なコードを非一時的に保存するコンピューター読み取り可能媒体。
  48. コンポーザブルインフラストラクチャを有するシステムを構成する方法であって、前記システムは、通信サブシステムと、前記通信サブシステに結合されたディスクドライブ及びサーバーとを含み、前記ドライブは、前記ドライブに関連する少なくとも１つの結合された障害メカニズムに従いストレージグループに編成され、前記方法は、
    前記サーバーの１つで動作している管理アプリケーションに従い、前記サーバーの少なくともいくつかで構成された１つのセットの各サーバーに、前記ドライブのストレージグループメンバーシップに従い前記ドライブの別のサブセットを割り当てることを含むことを特徴とする方法。
  49. 前記ストレージグループの少なくとも１つは、少なくとも１つの結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含むことを特徴とする請求項４８に記載の方法。
  50. 前記サーバーの前記１つで動作している前記管理アプリケーションに従い、前記セットの前記サーバーの各々で動作しているアプリケーションのデータ配置ポリシーを決定するステップと、
    前記アプリケーションを動作させているとき前記データ配置ポリシーに従うよう前記セットの前記サーバーの各々を構成し、前記セットの前記サーバーの各々に保存されたデータが、前記ストレージグループの少なくとも２つに冗長性を持たせて保存されることを保証するステップと、を含み、前記２つのストレージグループの内の１つは、結合された障害メカニズムを有するドライブで構成されるか又はこのようなドライブを含み、前記２つのストレージグループの内の他の１つは前記結合された障害メカニズムを有するいずれのドライブも含まないことを特徴とする請求項４９に記載の方法。
  51. 前記セットの前記サーバーの各々で動作している前記アプリケーションは、前記セットの前記サーバーの各々によって、前記データ配置ポリシーに従いサーバーの前記セットの内の少なくとも１つの他のサーバーにデータを保存するよう構成されていることを特徴とする請求項５０に記載の方法。
  52. 前記サーバーの少なくとも１つを、前記ＲＡＩＤセット内の前記ドライブの各々のストレージグループメンバーシップに従い前記ドライブのＲＡＩＤセットを決定することを含む、ＲＡＩＤ機能を実装するよう構成することを特徴とする請求項４８に記載の方法。
  53. 前記サーバーの前記１つで動作している前記管理アプリケーションに従い、前記ドライブにより編成されているストレージグループを決定することも含むことを特徴とする請求項４８に記載の方法。
  54. 請求項４８に記載のアプリケーションを動作させるために、請求項４８に記載されたサーバーの１つにより実行可能なコードを非一時的に保存するコンピューター読み取り可能媒体。
JP2020573249A 2018-06-28 2019-06-03 コンポーザブルインフラストラクチャにおける記憶装置の故障耐性を維持するための方法とシステム Pending JP2022517890A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/021,189 2018-06-28
US16/021,189 US11436113B2 (en) 2018-06-28 2018-06-28 Method and system for maintaining storage device failure tolerance in a composable infrastructure
PCT/US2019/035175 WO2020005468A1 (en) 2018-06-28 2019-06-03 Method and system for maintaining storage device failure tolerance in a composable infrastructure

Publications (1)

Publication Number Publication Date
JP2022517890A true JP2022517890A (ja) 2022-03-11

Family

ID=68985179

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020573249A Pending JP2022517890A (ja) 2018-06-28 2019-06-03 コンポーザブルインフラストラクチャにおける記憶装置の故障耐性を維持するための方法とシステム

Country Status (8)

Country Link
US (2) US11436113B2 (ja)
EP (1) EP3814871A4 (ja)
JP (1) JP2022517890A (ja)
KR (1) KR20210022121A (ja)
CN (1) CN112703462A (ja)
DE (1) DE202019005816U1 (ja)
TW (1) TW202018462A (ja)
WO (1) WO2020005468A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10540496B2 (en) * 2017-09-29 2020-01-21 International Business Machines Corporation Dynamic re-composition of patch groups using stream clustering
US11379246B2 (en) * 2019-07-24 2022-07-05 EMC IP Holding Company LLC Automatic configuration of multiple virtual storage processors
US11082505B2 (en) * 2019-07-29 2021-08-03 Cisco Technology, Inc. Dynamic discovery of available storage servers
US11416180B2 (en) * 2020-11-05 2022-08-16 International Business Machines Corporation Temporary data storage in data node of distributed file system
CN114721585A (zh) * 2021-01-06 2022-07-08 伊姆西Ip控股有限责任公司 存储管理方法、设备和计算机程序产品
US12013974B2 (en) 2021-03-31 2024-06-18 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Provisioning a computing subsystem with disaggregated computing hardware resources selected in compliance with a physical location requirement of a workload
US11632337B1 (en) * 2021-10-11 2023-04-18 Cisco Technology, Inc. Compute express link over ethernet in composable data centers

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003084923A (ja) * 2001-09-06 2003-03-20 Hitachi Ltd クラスタ型ディスクアレイ装置の構成方法
WO2017023461A1 (en) * 2015-08-06 2017-02-09 Drivescale, Inc. Method and system for balancing storage data traffic in converged networks
US20170329648A1 (en) * 2016-05-12 2017-11-16 Futurewei Technologies, Inc. Worker node rebuild for parallel processing system
US20180081768A1 (en) * 2016-09-16 2018-03-22 Oracle International Corporation Hierarchical fault tolerance in system storage
US20180150244A1 (en) * 2016-11-30 2018-05-31 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Selection of fabric-attached storage drives on which to provision drive volumes for realizing logical volume on client computing device within storage area network

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7389312B2 (en) 1997-04-28 2008-06-17 Emc Corporation Mirroring network data to establish virtual storage area network
US6438141B1 (en) 1998-04-20 2002-08-20 Sun Microsystems, Inc. Method and management of communications over media of finite bandwidth
US6556541B1 (en) 1999-01-11 2003-04-29 Hewlett-Packard Development Company, L.P. MAC address learning and propagation in load balancing switch protocols
US6868062B1 (en) 2000-03-28 2005-03-15 Intel Corporation Managing data traffic on multiple ports
WO2002015018A1 (en) * 2000-08-11 2002-02-21 3Ware, Inc. Architecture for providing block-level storage access over a computer network
US20020165942A1 (en) * 2001-01-29 2002-11-07 Ulrich Thomas R. Data path accelerator with variable parity, variable length, and variable extent parity groups
US6996741B1 (en) * 2001-11-15 2006-02-07 Xiotech Corporation System and method for redundant communication between redundant controllers
US7134040B2 (en) 2002-04-17 2006-11-07 International Business Machines Corporation Method, system, and program for selecting a path to a device to use when sending data requests to the device
US20050050187A1 (en) 2003-09-03 2005-03-03 International Business Machines Corporation Method and apparatus for support of bottleneck avoidance in an intelligent adapter
US20050216552A1 (en) * 2004-03-24 2005-09-29 Samuel Fineberg Communication-link-attached persistent memory system
US7760626B2 (en) 2004-03-31 2010-07-20 Intel Corporation Load balancing and failover
US7590775B2 (en) 2004-08-06 2009-09-15 Andrew Joseph Alexander Gildfind Method for empirically determining a qualified bandwidth of file storage for a shared filed system
US7876689B2 (en) 2005-06-29 2011-01-25 Hewlett-Packard Development Company, L.P. Method and apparatus for load balancing network interface adapters based on network information
US20070156879A1 (en) 2006-01-03 2007-07-05 Klein Steven E Considering remote end point performance to select a remote end point to use to transmit a task
US8635376B2 (en) 2006-02-22 2014-01-21 Emulex Design & Manufacturing Corporation Computer system input/output management
JP2007328611A (ja) 2006-06-08 2007-12-20 Hitachi Ltd ストレージ仮想化システム及び方法
JP2008083939A (ja) 2006-09-27 2008-04-10 Hitachi Ltd 計算機システム及び動的ポート割当方法
US9430297B2 (en) 2008-12-15 2016-08-30 International Business Machines Corporation Load balancing of adapters on a multi-adapter node
US8155518B2 (en) 2009-03-30 2012-04-10 Lsi Corporation Dynamic load balancing of fibre channel traffic
US9124423B2 (en) 2010-05-14 2015-09-01 International Business Machines Corporation Iterative data secret-sharing transformation
DE112011103123B4 (de) * 2010-09-16 2023-08-10 Iii Holdings 2, Llc Performance und leistungsoptimierte Computersystemarchitekturen und -verfahren, die eine leistungsoptimierte Tree-Fabric-Verdrahtung wirksam einsetzen
US9652343B2 (en) * 2011-09-21 2017-05-16 Kevin Mark Klughart Raid hot spare system and method
CN105843557B (zh) * 2016-03-24 2019-03-08 天津书生云科技有限公司 冗余存储系统、冗余存储方法和冗余存储装置
US11474704B2 (en) 2012-05-18 2022-10-18 Atto Technology, Inc. Target path selection for storage controllers
US9613656B2 (en) * 2012-09-04 2017-04-04 Seagate Technology Llc Scalable storage protection
US9417997B1 (en) * 2012-09-28 2016-08-16 Emc Corporation Automated policy based scheduling and placement of storage resources
US9401862B2 (en) 2013-02-07 2016-07-26 Dell Products L.P. Optimized internet small computer system interface path
US9781041B2 (en) 2013-07-24 2017-10-03 Dell Products Lp Systems and methods for native network interface controller (NIC) teaming load balancing
US20150100826A1 (en) * 2013-10-03 2015-04-09 Microsoft Corporation Fault domains on modern hardware
US9641615B1 (en) 2014-03-31 2017-05-02 EMC IP Holding Company LLC Allocating RAID storage volumes across a distributed network of storage elements
US10209898B2 (en) 2014-04-03 2019-02-19 International Business Machines Corporation Estimation of performance utilization of a storage device
US9582355B2 (en) * 2014-07-09 2017-02-28 Qualcomm Incorporated Systems and methods for reliably storing data using liquid distributed storage
US10084648B2 (en) * 2015-03-12 2018-09-25 International Business Machines Corporation Creating new cloud resource instruction set architecture
US10466913B2 (en) 2015-04-29 2019-11-05 EMC IP Holding Company LLC Method and system for replicating and using grid level metadata in a storage system
US10291707B1 (en) * 2015-05-18 2019-05-14 Twitter, Inc. Systems and methods for balancing storage resources in a distributed database
US9851906B2 (en) 2015-06-16 2017-12-26 Vmware, Inc. Virtual machine data placement in a virtualized computing environment
CN104965677B (zh) * 2015-06-26 2018-04-13 北京百度网讯科技有限公司 存储系统
CN105068836A (zh) * 2015-08-06 2015-11-18 北京百度网讯科技有限公司 一种基于sas网络的远程可共享的启动系统
US20190068466A1 (en) * 2017-08-30 2019-02-28 Intel Corporation Technologies for auto-discovery of fault domains
US20190095296A1 (en) * 2017-09-27 2019-03-28 Hewlett Packard Enterprise Development Lp Reading or Reconstructing Requested Data from RAID Volume
US10452503B2 (en) * 2017-09-29 2019-10-22 Hewlett Packard Enterprise Development Lp Bidirectional replication
US10534629B1 (en) * 2017-10-31 2020-01-14 EMC IP Holding Company LLC Virtual data management services
US10587463B2 (en) * 2017-12-20 2020-03-10 Hewlett Packard Enterprise Development Lp Distributed lifecycle management for cloud platforms
US11520506B2 (en) * 2018-01-31 2022-12-06 Salesforce.Com, Inc. Techniques for implementing fault domain sets
US10860211B2 (en) * 2018-02-06 2020-12-08 Western Digital Technologies, Inc. Modularized multi-purpose storage system
US20190251279A1 (en) * 2018-02-13 2019-08-15 Pure Storage, Inc. Storage layer data security
US10802753B2 (en) * 2018-02-15 2020-10-13 Seagate Technology Llc Distributed compute array in a storage system
US10732995B2 (en) * 2018-02-27 2020-08-04 Portworx, Inc. Distributed job manager for stateful microservices
US10887416B2 (en) * 2018-05-07 2021-01-05 International Business Machines Corporation Efficient high availability and storage efficiency in a multi-site object storage environment
US10871922B2 (en) * 2018-05-22 2020-12-22 Pure Storage, Inc. Integrated storage management between storage systems and container orchestrators
US20190394088A1 (en) * 2018-06-25 2019-12-26 Hewlett Packard Enterprise Development Lp Network device configuration versioning

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003084923A (ja) * 2001-09-06 2003-03-20 Hitachi Ltd クラスタ型ディスクアレイ装置の構成方法
WO2017023461A1 (en) * 2015-08-06 2017-02-09 Drivescale, Inc. Method and system for balancing storage data traffic in converged networks
US20170329648A1 (en) * 2016-05-12 2017-11-16 Futurewei Technologies, Inc. Worker node rebuild for parallel processing system
US20180081768A1 (en) * 2016-09-16 2018-03-22 Oracle International Corporation Hierarchical fault tolerance in system storage
US20180150244A1 (en) * 2016-11-30 2018-05-31 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Selection of fabric-attached storage drives on which to provision drive volumes for realizing logical volume on client computing device within storage area network

Also Published As

Publication number Publication date
KR20210022121A (ko) 2021-03-02
WO2020005468A1 (en) 2020-01-02
TW202018462A (zh) 2020-05-16
CN112703462A (zh) 2021-04-23
US20200004650A1 (en) 2020-01-02
US11436113B2 (en) 2022-09-06
DE202019005816U1 (de) 2022-05-18
EP3814871A1 (en) 2021-05-05
EP3814871A4 (en) 2022-03-16
US20220413976A1 (en) 2022-12-29

Similar Documents

Publication Publication Date Title
JP2022517890A (ja) コンポーザブルインフラストラクチャにおける記憶装置の故障耐性を維持するための方法とシステム
JP4634812B2 (ja) 複数のコントローラ間に仮想ストレージセグメントを割り当てる能力を有するストレージシステム
US8051262B2 (en) Storage system storing golden image of a server or a physical/virtual machine execution environment
US9262087B2 (en) Non-disruptive configuration of a virtualization controller in a data storage system
US20140115579A1 (en) Datacenter storage system
US8972657B1 (en) Managing active—active mapped logical volumes
JP5973089B2 (ja) ストレージシステムの移行方式および移行方法
US8972656B1 (en) Managing accesses to active-active mapped logical volumes
JP2005216306A (ja) データを移動することなく仮想ストレージデバイス群を移動させる能力を含むストレージシステム
WO2021247166A1 (en) Balancing resiliency and performance by selective use of degraded writes and spare capacity in storage systems
US10884622B2 (en) Storage area network having fabric-attached storage drives, SAN agent-executing client devices, and SAN manager that manages logical volume without handling data transfer between client computing device and storage drive that provides drive volume of the logical volume
JP2006285808A (ja) ストレージシステム
JP2010271808A (ja) ストレージ装置及びデータコピー方法
US11422893B2 (en) Storage system spanning multiple failure domains
US10268419B1 (en) Quality of service for storage system resources
WO2016151584A2 (en) Distributed large scale storage system
US8756370B1 (en) Non-disruptive drive firmware upgrades
Dufrasne et al. IBM XIV Storage System Architecture and Implementation
WO2020023638A1 (en) Methods for managing workloads in a storage system and devices thereof
Ra et al. Ioarbiter: Dynamic provisioning of backend block storage in the cloud
Dufrasne et al. IBM DS8880 Architecture and Implementation (Release 8.51)
US20240220101A1 (en) Cluster management in large-scale storage systems
Pethe Technology Case Study in Storage Area Networks
Bruni et al. DB2 9 for z/OS and Storage Management
EP1828905A2 (en) System and method for flexible physical-to-logical mapping in raid arrays

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A529

Effective date: 20210226

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20210709

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220325

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230329

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230404

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20231031