リソースの負荷バランシング

著者らは特許

G06F9/50 - リソースの割り当て,例.中央処理装置(CPU)

の所有者の特許 JP2016528617:

ヴイエムウェア インコーポレイテッドVMware,Inc.

 

本開示において実施形態は、分散リソースシステム内の異なるタイプの多次元の組のリソースのバランシングのための技術を提示する。リソースを提供する各ホストコンピュータは、ゲストクライアントによる現在のリソース使用量についてのステータスを発行する。ローカルアンバランスの識別時に、ホストコンピュータは、リソース使用量におけるばらつきを最小化するようリソースコンテナへまたはリソースコンテナからマイグレーションを行なうソース作業負荷を判定する。さらに、新たなリソース作業負荷の配置時に、ホストコンピュータは、さらにリソース使用量をバランシングするためにばらつきを最小化するリソースコンテナを選択する。

 

 

分散システムにより、ネットワーク内の多数のクライアントが共有リソースのプールへアクセスすることが可能である。例えば、分散ストレージシステムにより、ホストコンピュータのクラスタが、各ホストコンピュータ内に位置するか、または、それに取り付けられたローカルディスク(例えば、SSD(Solid State Drive)、PCI(Peripheral Component Interconnect)ベースのフラッシュストレージ、SATA(Serial AT Attachment)、またはSAS(Serial Attached SCSI)磁気ディスク)を集約してストレージの単一または共有のプールを作成することが可能となる。このストレージのプール(本開示では時に「データストア」または「ストア」とも称される)は、クラスタ内の全てのホストコンピュータによりアクセス可能であり、ストレージエンティティの単一名前空間として存在し得る(ファイルの場合の階層ファイルシステム名前空間、オブジェクトの場合の一意識別子のフラットな名前空間、等のように)。ホストコンピュータ上で生成された仮想マシン等のストレージクライアントは、データストアを使用し得、例えば、仮想マシンによりその動作中にアクセスされる仮想ディスクを格納する。データストアを形成する共有ローカルディスクは異なる性能特性(例えば、容量、毎秒入力/出力オペレーションまたはIOPS(Input/Output Per Second)能力、等)を有し得るため、仮想ディスクまたはその一部を格納するためのこのような共有ローカルディスクの使用量は、各所与の仮想マシンのニーズに基づいて仮想マシン間で分散され得る。
このアプローチは、企業に費用効率の高い性能を提供する。例えば、プールされたローカルディスクを使用する分散ストレージは、安価でありかつ高度にスケーラブルであり、比較的に管理が簡単である。このような分散ストレージは、クラスタ内の市販ディスクを使用可能であるので、企業は追加のストレージインフラストラクチャに投資する必要がない。しかしながら、このアプローチに伴う1つの問題は、リソース使用量のばらつきである。すなわち、リソースタイプ間の大きいばらつきは、全体として非効率的な使用量という結果をもたらす。分散ストレージシステムの例を続けると、システムが仮想マシンを作成する場合、システムは、仮想マシンの要件に基づいて新たな仮想マシンに一組のリソース(例えば、容量、性能、可用性、等)を提供し得る。共有データストアの特定のパーティションが、1つ以上のリソースのタイプにおいてオペレーション等の高い消費量を有し、別のタイプにおいて容量等のはるかにより低い消費量を有すると、システムは、利用可能な容量があるにもかかわらず、そのパーティションを仮想マシンに割り当てることができないことがあり得る。1つのリソースタイプの消費量がデータストア内の特定のパーティションについて高いが、データストアの残りについては全て低い場合も、リソースの分散が非効率的であるので問題となる。
本開示の1つ以上の実施形態は、分散リソースシステム内の複数のリソースタイプを有する分散リソースの多次元の組への作業負荷を有するストレージオブジェクトの分散方法を提供する。本方法は概して、分散リソースシステムの各ノードにより発行されたリソースコンテナ内の複数のリソースタイプの各々のリソース使用量のステータスを取得することを含む。本方法はまた概して、ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することを含む。各候補リソースコンテナは、複数のリソースタイプのリソース使用量間の元のばらつきを有する。本方法はまた概して、各候補リソースコンテナについての複数のリソースタイプのリソース使用量間の期待ばらつきを判定することを含む。本方法はまた概して、元のばらつきよりも低い期待ばらつきを伴う少なくとも1つの候補リソースコンテナのうちの1つに多次元の組の分散リソースを配置することを含む。
本開示の別の実施形態は、分散リソースシステム内の複数のリソースタイプを有する分散リソースの多次元の組のリバランシング方法を提供する。本方法は概して、分散リソースシステムの各ノードにより発行されたリソースコンテナ内の複数のリソースタイプの各々のリソース使用量のステータスを取得することを含む。本方法はまた概して、リソースコンテナのうちの第1のリソースコンテナにおけるリソース使用量のアンバランスを生じさせるソースオブジェクトコンポーネントを識別することを含む。本方法はまた概して、ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することを含む。各候補リソースコンテナは、複数のリソースタイプのリソース使用量間の元のばらつきを有する。本方法はまた概して、各候補リソースコンテナについての複数のリソースタイプのリソース使用量間の期待ばらつきを判定することを含む。本方法はまた概して、期待ばらつきに基づいて元のばらつきを低減する1つ以上の候補リソースコンテナのうちの1つにソースオブジェクトコンポーネントを再配置することを含む。
他の実施形態は、限定するわけではないが、処理ユニットに本開示の方法の1つ以上の態様を実装させ得る命令を含むコンピュータ可読媒体、ならびに、本開示の方法の1つ以上の態様を実装するよう構成された、プロセッサ、メモリおよびアプリケーションプログラムを有するシステムを含む。
一実施形態に係る、例示的なコンピューティング環境を示す。 一実施形態に係る、仮想ディスクを表すオブジェクトストア内に編成されたオブジェクトの例示的な階層構造を示す。 一実施形態に係る、仮想ストレージエリアネットワークオブジェクトレイアウトの例示的抽象化を示す。 一実施形態に係る、VSAN(Virtual Storage Area Network)モジュールを示す。 一実施形態に係る、変動するリソース使用量を伴う3つの例示的ディスク群を示す。 一実施形態に係る、ディスク群内の作業負荷を別のディスク群にマイグレーションさせる、例示的な特定用途のケースを示す。 一実施形態に係る、作成の間の仮想マシンのコンポーネント作業負荷の負荷バランシング方法を示す。 一実施形態に係る、ディスク群間の作業負荷のリバランシング方法を示す。
本開示の実施形態は、ネットワーク接続されたクラスタ内のリソースを提供する個別のホストコンピュータに亘るおよびその内部の多次元の組の分散リソースの使用量のばらつきをバランシングするための技術を提供する。本開示の技術は、比較的にバランスのとれたリソース使用量およびシンプロビジョニングのためのリソースにおける十分なヘッドルームをもたらす。一実施形態において、新たな作業負荷の分散リソースへの割り当てにおいて、または、システムの各個別ノードにおける既存の使用量のばらつきのアンバランスの調整において、バランシング(またはリバランシング)が生じる。各ノードは、各リソースコンテナごとにリソースタイプによる集約リソース使用量データを発行する。クラスタに亘る発行データを使用して、各ノードは、ワークフローを配置またはマイグレーションするために候補リソースコンテナを識別する。各候補について、ノードは、期待ばらつきを判定する。期待ばらつきに基づいて、ホストノードは、結果としてリソース使用量における適切なバランスとなるマイナスばらつきを有するランダム化された配置(またはマイグレーション)を選択する。
例えば、本開示の技術は、分散ストレージシステムに適用し得る。適用可能な分散ストレージシステムの一例は、集約「オブジェクト」ストアを提供するためにクラスタ内のホストサーバがそれぞれその市販ローカルストレージリソース(例えば、ハードディスクおよびソリッドステートドライブの両方か、少なくともいずれか一方)に寄与するノードとして活動するソフトウェアベースの「仮想ストレージエリアネットワーク」(VSAN)である。各ホストサーバは、オブジェクトストア内のオブジェクトのために特定された所定ストレージポリシーに基づいてストレージ管理ワークフローを自動化する(例えば、オブジェクトストア内にオブジェクトを作成する、等)およびオブジェクトストア内のオブジェクトにアクセスを提供する(例えば、オブジェクトストア内のオブジェクトへのI/Oオペレーションを取り扱う、等)ために、ストレージ管理モジュール(本開示においてVSANモジュールとも称される)を含み得る。1つの特定の実施形態において、ホストサーバはさらに、VSANオブジェクトストアへのクライアントとして活動する仮想マシン(VM(Virtual machine))のインスタンス化をサポートする。このような実施形態において、オブジェクトストアにストアされた「オブジェクト」は、例えば、VM構成ファイルおよび仮想ディスク記述子ファイルを含み得るファイルシステムオブジェクト、ランタイムの間にVMによりアクセスされる仮想ディスクオブジェクト、等を含み得る。各ノードにおけるVSANモジュールは、ソリッドステートドライブIOPS(Input/Output Per Second)および容量ならびに磁気ディスクIOPSおよび容量等のリソースタイプ間でのローカルディスク群におけるリソース使用量をバランスさせることを目的とする。ソフトウェアベースのVSANにおいて、各個別ホストサーバにおいてリソース使用量ばらつきをバランスさせることは、仮想化クラスタに亘る仮想マシンがストレージリソースを効率的に消費し、利用可能時にリソースタイプへのアクセスが可能となることを確実とする。さらに、リソース消費量をモニタリングし、リソース作業負荷を再調整する個別のホストノードの分散アプローチは、クラスタに亘るリソースをバランスさせるための(例えば、管理アプリケーションまたはサーバを通じた)集中化アプローチの必要性を省く。
添付図面に示されたいくつかの実施形態、実施例への詳細な参照が以下になされる。なるべく同様または類似の参照符号が図面において使用され得、同様または類似の機能性を示し得ることに留意されたい。図面は、例示目的でのみ実施形態を示す。当業者であれば、本開示の原理から逸脱しなければ本開示に例示された構造および方法の代替的な実施形態が採用され得ることを、以下の記述より容易に理解するであろう。
以下において、VSANモジュールは、分散リソースシステムにおいて多数のリソースタイプを負荷バランシングするシステムの参照例として提供する。この参照例は、本開示の実施形態の理解の提供のために含まれる。しかしながら、コンピューティング環境のタイプにかかわらず、これらの実施形態が共有リソースの負荷バランシングに関する他の文脈において適用可能であることは、当業者にとって明らかであろう。例えば、実施形態は、ソフトウェア定義コンピュータ、ネットワークおよびストレージアレイに適用可能である。さらに、実施形態は、他の共有コンピューティングリソース(例えば、処理、メモリおよびネットワークリソース、等)のバランシングに適用可能である。
同様に、実施形態の全体的理解の提供のために、多数の特定の詳細が提供される。当業者であれば、これらの特定の詳細のいくつかを伴わずに実施形態が実行され得ることを理解するであろう。他の例において、本開示の新規態様の不必要な不明確化を避けるために、周知のプロセスオペレーションおよび実装の詳細は、詳細には記述されてはいない。
図1は、一実施形態に係る、コンピューティング環境100を示す。示されるように、コンピューティング環境100は、ノードで実行中の仮想マシン(VM)112に集約オブジェクトストア116を提供するために、クラスタ110のホストサーバまたはノード111に収容され、または直接に取り付けられた(以下、用語「収容された」または「に収容された」の使用は、収容され、または別様に直接に取り付けられたことの両方を包含するよう使用され得る)市販ローカルストレージを利用するVSAN環境である。ノード111に収容され、または別様に直接に取り付けられたローカル市販ストレージは、ソリッドステートドライブ(SSD(Solid State Drive))117および磁気もしくはスピニングディスク118のうち少なくともいずれか一方の組み合わせを含み得る。ある実施形態において、SSD117は、I/O性能向上のための磁気ディスク118の手前の読み出しキャッシュおよび書き込みバッファのうち少なくともいずれか一方として機能する。
仮想化管理プラットフォーム105は、ノード111のクラスタ110と関連付けられる。仮想化管理プラットフォーム105により、アドミニストレータがノード111でのVMの構成及び生成を管理することが可能となる。図1の実施形態に示されているように、各ノード111は、仮想化層またはハイパーバイザ113、VSANモジュール114、および(SSD117およびノード111の磁気ディスク118を含む)ハードウェア119を含む。ハイパーバイザ113を通じて、ノード111は、多数のVM112を立ち上げて実行することができる。ハイパーバイザ113は、部分的に、各VM112についてコンピューティングリソース(例えば、処理能力、ランダムアクセスメモリ等)を適切に割り当てるためにハードウェア119を管理する。さらに、後述するように、各ハイパーバイザ113は、その対応するVSANモジュール114を通じて、仮想ディスク(またはその一部)用のストレージとしての使用のためにハードウェア119に位置するストレージリソース(例えば、SSD117および磁気ディスク118)へのアクセスと、クラスタ110内の任意のノード111に存在する任意のVM112によりアクセスされ得る他の関連ファイルへのアクセスとを提供する。特定の実施形態において、ヴィエムウェア社(VMware, Inc.)のヴィ・スフィア・ハイパーバイザ(vSphere Hypervisor)が、ハイパーバイザ113としてノード111にインストールされ得、ヴィエムウェアのヴィ・センタサーバ(vCenter Server)が仮想化管理プラットフォーム105として使用され得る。
一実施形態において、VSANモジュール114はハイパーバイザ113内に「VSAN」デバイスドライバとして実装される。このような実施形態において、VSANモジュール114は、概念的「VSAN」115へのアクセスを提供し、VSAN115を介してアドミニストレータがオブジェクトストア116により支持される多数のトップレベル「デバイス」または名前空間オブジェクトを生成し得る。よくある状況の1つとして、デバイスオブジェクトの作成中、アドミニストレータは、デバイスオブジェクトのための特定のファイルシステムを規定し得る(このようなデバイスオブジェクトは以下、「ファイルシステムオブジェクト」とも称される)。例えば、一実施形態において、各ノード111内の各ハイパーバイザ113は、ブートプロセスの間、VSANモジュール114により露出される概念的グローバル名前空間のための/vsan/ルートノードを発見し得る。例えば、VSANモジュール114により露出されるAPIにアクセスすることにより、ハイパーバイザ113は、VSAN115にその時点で存在する全てのトップレベルファイルシステムオブジェクト(または他のタイプのトップレベルデバイスオブジェクト)を決定し得る。VM(または他のクライアント)がファイルシステムオブジェクトのうちの1つにアクセスしようと試みると、ハイパーバイザ113は、そのときのファイルシステムオブジェクトを動的に「自動マウント」し得る。VSAN115を通じてアクセス可能なファイルシステムオブジェクト(例えば、/vsan/fs_name1、等)は、例えば、VMへの同時アクセス中に同時実行制御を提供するよう設計された、ヴィエムウェアの分散またはクラスタ化ファイルシステム、VMFS(Virtual Machine File System)のような、特定のファイルシステムのセマンティクスをエミュレートするよう実装され得る。VSAN115が多数のファイルシステムオブジェクトをサポートするため、任意の特定のクラスタ化ファイルシステムの限定に縛られることなくオブジェクトストア116を通じたストレージリソースの提供が可能である。例えば、多くのクラスタ化ファイルシステム(例えば、VMFS等)は、ある量のノード111をサポートするためにだけスケール可能である。多数のトップレベルファイルシステムオブジェクトサポートを提供することにより、VSAN115は、このようなクラスタ化ファイルシステムのスケーラビリティ制限を克服する。
下記の図2の文脈における更なる詳述に示されるように、ファイルシステムオブジェクトは、それ自身、クラスタ110で実行中のVM112によりアクセス可能な多数の仮想ディスク記述子ファイル(例えば、ヴィ・スフィア(vSphere)環境における.vmdkファイル、等)へのアクセスを提供し得る。これらの仮想ディスク記述子ファイルは、仮想ディスクのための実際のデータを含むとともに、オブジェクトストア116により別個に支持される仮想ディスク「オブジェクト」への参照を含む。仮想ディスクオブジェクトは、それ自身、階層的または「複合」オブジェクトであり得、階層的または「複合」オブジェクトは、下記に説明されるように、仮想ディスクの最初の作成時にアドミニストレータにより生成される対応するストレージプロファイルまたはポリシーのストレージ要件(例えば、容量、可用性、IOPS等)を反映する「コンポーネント」オブジェクト(これもオブジェクトストア116により別個に支持される)によりさらに構成される。下記にさらに議論されるように、各VSANモジュール114は、(下記にさらに説明される実施形態において、クラスタレベルオブジェクト管理すなわち「CLOM(Cluster Level Object Manager)」サブモジュールを通じて)、他のノード111の他のVSANモジュール114と通信して、オブジェクトストア116内にストアされた種々のオブジェクト間の位置、構成、ポリシーおよび関係を記述するメタデータを含むメモリ内メタデータデータベース(例えば、各ノード111のメモリ内に、別個に、しかし、同期方式により維持された)を作成および維持する。このメモリ内メタデータデータベースは、例えば、アドミニストレータが最初にVMのために仮想ディスクを作成するとき、および、VMが実施中であり仮想ディスク上のI/Oオペレーション(例えば、読み出しまたは書き込み)を行う場合に、ノード111上のVSANモジュール114により利用される。図3の文脈で下記にさらに議論されるように、VSANモジュール114は、(下記にさらに説明される一実施形態において、ドキュメントオブジェクトマネージャすなわち「DOM(Document Object Manager)」サブモジュールを通じて)I/Oオペレーションの対象となる仮想ディスクの一部を支持する実際の物理ローカルストレージを収容するノード(または、ノード群)へのI/Oオペレーションリクエストを適切に送るために、メモリ内データベース内のメタデータを使用してオブジェクトの階層を横断する。
図2は、一実施形態に係る、仮想ディスクを表すオブジェクトストア116内に編成されたオブジェクトの例示的な階層構造を示す。上記において先に詳述されたように、1つのノード111にて実行中のVM112は、オブジェクトストア116内に階層的または複合オブジェクト200としてストアされた仮想ディスク上のI/Oオペレーションを実行し得る。ハイパーバイザ113は、VSANモジュール114を通じてVSAN115のアブストラクションとインターフェースすることにより(例えば、一実施形態において先に議論されたように、仮想ディスクオブジェクトに対応するトップレベルファイルシステムオブジェクトを自動マウントすることにより)、VM112に仮想ディスクへのアクセスを提供する。例えば、VSANモジュール114は、メモリ内メタデータデータベースのそのローカルコピーをクエリすることにより、仮想ディスクのための記述子ファイル210(例えば.vmdkファイル)を格納するVSAN115内にストアされた特定のファイルシステムオブジェクト205(例えば、一実施形態におけるVMFSファイルシステムオブジェクト、等)を識別することができる。ファイルシステムオブジェクト205が、仮想化環境をサポートする際に仮想マシン構成ファイル(例えば、vSphere環境における.vmxファイル、等)等の、その目的に沿った各種の他のファイルをストアし得ることが理解されるであろう。ある実施形態において、各ファイルシステムオブジェクトは、特定のVMに対応するそれらの仮想ディスク(例えば、「毎VM」ファイルシステムオブジェクト)のみをサポートするよう構成され得る。
記述子ファイル210は、オブジェクトストア116に別個にストアされ、仮想ディスクを概念的に表す(および本開示において時に仮想ディスクオブジェクトとも称され得る)複合オブジェクト200への参照を含む。複合オブジェクト200は、仮想ディスク作成時にアドミニストレータにより生成された対応ストレージプロファイルまたはポリシー内のストレージ要件(例えば、容量、可用性、IOPS、等)またはサービスレベルアグリーメント(SLA(Service Level Agreement))に適する仮想ディスクのストレージ編成または構成(本開示において仮想ディスク「ブループリント」と時に称される)を記述するメタデータを格納する。例えば、図2の実施形態において、複合オブジェクト200は、仮想ディスクの2つのミラーコピー(例えば、ミラー)がRAID(Redundant Arrays of Inexpensive Disks) 0構成内でさらにそれぞれストライプ化されるRAID 1構成を記述する仮想ディスクブループリント215を含む。したがって、複合オブジェクト225は、各仮想ディスクミラー内の各ストライプ(例えば、仮想ディスクのデータパーティション)に対応する、多数の「リーフ」または「コンポーネント」オブジェクト220に対する参照を含み得る。各コンポーネントオブジェクト220のための(例えば、各ストライプのための)メモリ内メタデータデータベースにおいてVSANモジュール114によりアクセス可能なメタデータは、ストライプ(およびこのような物理リソース内のストライプの位置)を実際に格納する物理ストレージリソース(例えば、磁気ディスク118、等)を収容するクラスタ110内の特定のノード111に対するマッピングを提供するか、または、別様に同特定のノード111を識別する。
図3は、一実施形態に係る、VSANモジュール114の構成要素を示す。前述のように、ある実施形態において、VSANモジュール114は、ハイパーバイザ113へのVSAN115のアブストラクションの露出するデバイスドライバとして実行し得る。VSANモジュール114の各種のサブモジュールは、異なる責務を取り扱い、このような責務に応じてユーザ空間315またはカーネル空間320のいずれかにおいて動作し得る。図3の実施形態に示されるように、VSANモジュール114は、ユーザ空間315で動作するクラスタレベルオブジェクト管理(CLOM:(CLOM:cluster level object management))サブモジュール325を含む。CLOMサブモジュール325は、アドミニストレータによる仮想ディスクの作成中に、仮想ディスクブループリントを生成し、このような仮想ディスクブループリントのために作成されたオブジェクトが、アドミニストレータにより設定されたストレージプロファイルまたはポリシー要件を満たすよう構成されることを確実にする。(例えば、仮想ディスクのための)オブジェクト作成中にアクセスされることに加えて、CLOMサブモジュール325は、(例えば、仮想ディスクブループリントまたはオブジェクトストア116内の実際の物理ストレージへの仮想ディスクブループリントのマッピングを動的に修正または別様に更新するために)オブジェクトに関するストレージプロファイルまたはポリシーへのアドミニストレータによりなされた変更の際、または、クラスタまたは作業負荷に対する変更が、現在のストレージプロファイルまたはポリシーに準拠しないオブジェクトを生じるときに、アクセスされ得る。
一実施形態において、アドミニストレータが、仮想ディスクオブジェクト200等の複合オブジェクトのストレージプロファイルまたはポリシーを作成すると、CLOMサブモジュール325は、各種の発見的アルゴリズムおよび分散アルゴリズムのうち少なくとも一方を適用して、ストレージポリシーを満たすか、または別様にストレージポリシーに適合するクラスタ110内の構成(例えば、ミラーリングを介した所望の冗長性およびストライピングを介したアクセス性能を達成するためのRAID構成:負荷バランシングを達成するために、どのノードのローカルストレージが、仮想ディスクのある部分/パーティション/ストライプを格納すべきか、等)を記述する仮想ディスクブループリント215を生成する。例えば、CLOMサブモジュール325は、一実施形態において、仮想ディスクが最初にアドミニストレータにより作成されたときに、図2における仮想ディスクオブジェクト200のRAID 1/RAID 0構成を記述するブループリント215の生成を担当する。上記において説明されたように、ストレージポリシーは、容量、IOPS、可用性および信頼性についての要件を規定し得る。ストレージポリシーはまた、作業負荷特徴(例えば、ランダムまたはシーケンシャルアクセス、I/Oリクエストサイズ、キャッシュサイズ、期待キャッシュヒット率、等)を規定し得る。さらに、アドミニストレータはまた、あるノード111(またはノード111に収容されたローカルディスク)を優先的に使用するためにVSANモジュール114への親和度を規定し得る。例えば、VMの新たな仮想ディスクの提供時に、アドミニストレータは、仮想ディスクが400GBの予備容量、150読み出しIOPSの予約、300書き込みIOPSの予約および99.99%の所望の可用性を有することを規定する仮想ディスクのストレージポリシーまたはプロファイルを生成し得る。生成されたストレージポリシーの受信時に、CLOMサブモジュール325は、生成されたストレージポリシーに適する複合オブジェクト(例えば、仮想ディスクオブジェクト)の仮想ディスクブループリントを生成する目的で、そのVSANモジュール114により維持されるメモリ内メタデータデータベースを調べてクラスタ110の現在の状態を判定する。下記においてさらに説明されるように、CLOMサブモジュール325は、その対応する分散オブジェクトマネージャ(DOM)サブモジュール340にブループリントを伝達し、分散オブジェクトマネージャ(DOM)サブモジュール340は、オブジェクト空間116と相互作用して、例えば、クラスタ110の各種ノード111内の物理ストレージ位置に複合オブジェクトのコンポーネントオブジェクト(例えば、ストライプ)を割り当てるか、または別様にマッピングすることにより、ブループリントを実施する。
CLOMサブモジュール325およびDOMサブモジュール340に加えて、図3にさらに示されるように、VSANモジュール114はまた、クラスタ110の状態についての情報をVSANモジュール114の他のサブモジュールに提供するために、上述のメモリ内メタデータデータベースを維持するとともに、クラスタ110内の各ノード111のステータス、アクセス可能性および可視性をモニタリングすることによりクラスタ110の全般的な「ヘルス」の追跡も行なう、クラスタモニタリング、メンバシップおよびディレクトリサービス(CMMDS(Cluster Monitoring, Membership, and Directory Services))サブモジュール335を含み得る。メモリ内メタデータデータベースは、各種ノード111、ノード111内に収容されたストレージリソース(SSD、磁気ディスク、等)およびその特性/能力、ノード111の現在の状態、および、それらの対応するストレージリソース、ノード111間のネットワーク経路、等のVSAN環境の物理インベントリを維持するディレクトリサービスとして機能する。先に説明されたように、物理インベントリを維持することに加えて、メモリ内メタデータデータベースはさらに、オブジェクトストア116にストアされるオブジェクトについてのメタデータのカタログ(例えば、どのような複合オブジェクト・コンポーネントオブジェクトが存在するか、どのようなコンポーネントオブジェクトがどのような複合オブジェクトに属するか、どのノードがいずれのオブジェクトへのアクセスを制御する「コーディネータ」または「オーナー」として機能するか、各オブジェクトについてのサービス品質要件、オブジェクト構成、オブジェクトの物理ストレージ位置へのマッピング、等)を提供する。先に説明されたように、VSANモジュール114内の他のサブモジュールは、更新目的でCMMDSサブモジュール335(図3において接続線で表される)にアクセスして、クラスタトポロジおよびオブジェクト構成における変更を学習し得る。例えば、先に説明されたように、仮想ディスク作成中、CLOMサブモジュール325は、仮想ディスクブループリントを生成するためにメモリ内メタデータデータベースにアクセスし、実行中のVM112からのI/Oオペレーションに対処する目的で、DOMサブモジュール340は、メモリ内メタデータデータベースにアクセスして、対応する複合オブジェクト(仮想ディスクオブジェクト)のコンポーネントオブジェクト(例えば、ストライプ)を格納するノード111、および、I/Oオペレーションを満たすためにそれらのノードが到達可能な経路を決定する。
上記において説明されたように、DOMサブモジュール340は、I/Oオペレーションの取り扱いの間、および、オブジェクト作成の間、DOMサブモジュール340が実行される特定のノード111のローカルストレージにストアされたオブジェクトストア116内のそれらのコンポーネントオブジェクト、および、そのノード111が現在「コーディネータ」または「オーナー」として指定され続けているある他の複合オブジェクトへのアクセスの制御およびそのオペレーションの取り扱いを実施する。例えば、VMからのI/Oオペレーションの取り扱い時に、ある実施形態における複合オブジェクトの階層的性質のため、目的の複合オブジェクト(例えば、I/Oオペレーションの対象となる仮想ディスクオブジェクト)のためのコーディネータとして機能するDOMサブモジュール340は、第2のノード111(またはノード群)内の異なるDOMサブモジュール340とのネットワークを介してさらなる通信を必要とし得る。第2のノード111(またはノード群)は、第2のノード111のローカルストレージにストアされ、かつI/Oオペレーションの対象である仮想ディスクの一部分である仮想ディスクオブジェクトの特定のコンポーネントオブジェクト(例えば、ストライプ等)についてのコーディネータとして機能する。I/Oオペレーションを発行するVMが、仮想ディスクオブジェクトのコーディネータとも異なるノード111上に存在すると、VMを実行中のノードのDOMサブモジュール340は、コーディネータのDOMサブモジュール340ともネットワークを介して通信する必要があるであろう。ある実施形態において、I/Oオペレーションを発行するVMが、I/Oオペレーションの対象となる仮想ディスクオブジェクトのコーディネータと異なるノード上に存在すると、2つのノードの2つのDOMサブモジュール340は、VMを実行中のノードに対して仮想ディスクオブジェクトのコーディネータの役割を変更するために互いに通信し得る(例えば、それにより、VMを実行中のノードと仮想ディスクオブジェクトについてのコーディネータとして機能するノードとの間のI/Oオペレーションを調整するのに必要なネットワーク通信の量が低減される)。
DOMサブモジュール340もまた同様に、オブジェクト作成中に互いに通信する。例えば、仮想ディスク作成中にCLOMモジュール325により生成された仮想ディスクブループリントは、どのノード111が仮想ディスクオブジェクトおよびその対応するコンポーネントオブジェクト(ストライプ等)についてのコーディネータとして機能すべきかを指定する情報を含み得る。このような指定されたノードについてのDOMサブモジュール340の各々には、オブジェクトに関するメタデータでメモリ内メタデータデータベースを更新する目的で、それらの各オブジェクトを作成し、このようなオブジェクトにローカルストレージを(必要に応じ)割り当て、それらのオブジェクトをそれらの対応するCMMDSサブモジュール335に通知するためのリクエストが発行される(例えば、実施形態に応じて、仮想ディスクオブジェクトについてのコーディネータとして指定されたDOMサブモジュール340により、または、仮想ディスクブループリントを生成するノードのDOMサブモジュール340により、等)。このようなリクエストを実施するために、DOMサブモジュール340は、そのノード111のローカルSSDおよび磁気ディスクとの通信を実際に行なうVSANモジュール114内のコンポーネントとして機能するログ構造化オブジェクトマネージャ(LSOM(Log Structured Object Manager))サブモジュール350と相互作用する。コンポーネントオブジェクトについてのローカルストレージの割り当て(およびそのノードがコーディネータとして機能する複合オブジェクトについてのポリシーおよび構成等の他のメタデータのストア、等)に加えて、LSOMサブモジュール350はさらに、そのノード111のローカルストレージへのI/Oオペレーションの流れをモニタリングする。
図3はまた、論理エンドポイント(例えば、ノード、オブジェクト、等)間の任意サイズのデータグラムを提供する高信頼データグラムトランスポート(RDT(Reliable Datagram Transport))サブモジュール345を示し、エンドポイントは潜在的に、多数の経路に渡り得る。一実施形態において、基礎となるトランスポートはTCP(Transmission Control Protocol)である。代替的に、RDMA(Remote Direct Memory Access)等の他のトランスポートが使用され得る。RDTサブモジュール345は、例えば、上記において先に説明されたようにオブジェクト作成またはI/Oオペレーション取り扱いのために、DOMサブモジュール340が互いに通信する時に、使用される。ある実施形態において、RDTモジュール345は、CMMDSモジュール335と相互作用することにより、メモリ内メタデータデータベース内の最新の位置情報を維持し、リンクヘルスステータスに基づいて接続を作成、除去または再確立するために、論理エンドポイントのアドレスを動的に解決する。例えば、CMMDSモジュール335がリンクがヘルシーでないと報告すると、RDTサブモジュール345は、よりよい状況でのリンクを好み、接続を切り得る。
図4は、一実施形態に係る、定義されたストレージポリシーに基づく仮想ディスクオブジェクト作成の方法フロー図を示す。例えば、ステップ400において、アドミニストレータは、容量、可用性およびIOPS要件(例えば、定義されたストレージポリシー)を有する仮想ディスクを作成するために、仮想管理プラットフォーム105のユーザインタフェースと相互作用し得る。一実施形態において、仮想管理プラットフォーム105は、ステップ405において「マスター」ノード111に仮想ディスクについてのオブジェクトを作成するようリクエストし得る。ステップ410において、このようなマスターノード111は、VSANモジュール内のそのCLOMサブモジュール325を通じて仮想ディスクブループリントを生成し得る。先に説明されたように、CLOMサブモジュール35は、CMMS(Computerized Maintenance Management System)サブモジュール335のメモリ内メタデータデータベースへのコンサルティングにより判定されたように、クラスタ110のステータスに基づいて仮想ディスクオブジェクト(例えば、複合オブジェクト)の作成のために仮想ディスクブループリントを生成する。仮想ディスクブループリントは、仮想ディスクオブジェクトのコーディネータまたはオーナーとして機能すべき特定のノードを識別し得る。ステップ415において、マスターノード111のDOMサブモジュール340は、識別されたノードのDOMサブモジュール340に仮想ディスクオブジェクトを作成するようリクエストし得る。ステップ420において、識別されたノードのDOMサブモジュール340は、例えば、その対応するLSOMサブモジュール350と通信することにより、リクエストを受信し、仮想ディスクオブジェクトを作成し、仮想ディスクオブジェクトを記述するメタデータをそのローカルストレージに持続的に格納する。ステップ425において、DOMサブモジュール340は、仮想ディスクオブジェクトブループリントに基づいて、仮想ディスクブループリント内の任意のコンポーネントオブジェクトについてのコーディネータまたはオーナーとして機能するよう指定されているクラスタ110内のそれらの他のノードを識別する。DOMサブモジュール340は、コンポーネントオブジェクトについてのコーディネータとして機能する他のノードのDOMサブモジュール340と(例えば、そのRTP(Real−time Transport Protocol)サブモジュール345を使用して)通信し、それらのローカルストレージ内にこのようなコンポーネントオブジェクトを支持するデータを格納する。このようなDOMサブモジュール340が、仮想ディスクオブジェクトのコーディネータのDOMサブモジュール340から各コンポーネントオブジェクトを作成するリクエストを受信すると、DOMサブモジュール340は、今度はステップ430において、コンポーネントオブジェクト(およびその関連するメタデータ)についてのローカルストレージを割り当てるために各モジュール350と通信する。ひとたびこのようなコンポーネントオブジェクトが作成されると、ステップ435において、それらのDOMサブモジュール340は、そのCMMSサブモジュール335のメモリ内メタデータデータベースにコンポーネントの作成を通知する。ステップ440において、仮想ディスクオブジェクトのコーディネータのDOMサブモジュール340はまた、メモリ内メタデータデータベースを更新するために、その作成をそのCMMDSサブモジュール335に通知し、最終的にはアドミニストレータに確認を送信する(例えば、マスターノードを介して仮想管理プラットフォーム105に通信し戻す)。
図5は、一実施形態に係る、変動するリソースコンポーネント作業負荷を伴う3つの例示的ディスク群を示す。VSAN環境において、経時的に、VSANモジュールは、関連する作業負荷を有する新たなコンポーネントをディスク群に加え、オブジェクトポリシーに基づいて他のディスク群に亘って他のコンポーネントをマイグレーションする。他の時点において、仮想マシン等のストレージクライアントは、より少ないリソースを予約し、ディスク群からの削除という結果となる。VSANモジュール114は、各配置およびマイグレーションでの各ディスク群におけるリソース使用量作業負荷をバランスすることを目的とするが、ディスク群へのこのような変化は時折、リソース使用量のばらつきを生み出す。ディスク群は、ディスク群内のディスクの数に基づいて多次元を含み得る。簡単にするために、示されたディスク群は、4つの次元を有し、すなわち、SSD IOPS、SSD容量、磁気ディスクIOPS、磁気ディスク容量である。実際には、ディスク群は、示されたものよりも多くのディスクを含み得る。
図5は、ディスク群505,510および515を各々、変動する消費量のリソース使用量を有するものとして示す。図に示された使用量は、クラスタ内の仮想マシンによる使用量に対応する。ディスク群505は、SSDオペレーション、SSD容量、磁気ディスクオペレーションおよび磁気ディスク容量に亘って、低く比較的に均一な使用量を表す。ディスク群515は、同様のリソースタイプに亘って、高く比較的に均一な使用量を示す。リソースタイプに亘る消費量におけるばらつきが小さいので、ディスク群505および515で採り上げられたケースが望ましい。すなわち、ディスク群505について、リソースタイプに亘るリソース使用量は低く、比較的にバランスが取れている。この構成により、VSANモジュール114が連続的な作業負荷をディスク群505に配置することが可能となる。さらに、ディスク群515内のリソース使用量は高いものの、リソースは効率的に消費されている。
しかしながら、ディスク群510において示されたリソース消費量のばらつきは、望ましいケースではない。ディスク群510は、SSD容量における高い消費量を伴う不均一なばらつきを示す。このケースでは、ディスク群510は、利用可能なSSD IOPS、磁気ディスクIOPSおよび磁気ディスク容量の相当な量を有するが、VSANモジュールは、ある作業負荷を伴う新たなコンポーネントをディスク群510に提供できないであろう。その理由は、そのコンポーネントに対して、SSD IOPSがほとんど利用不可能だからである。VSANモジュール114は、別の仮想マシンからの作業負荷をばらつきを低減するディスク群510へ(例えば、SSDオペレーション、磁気ディスクオペレーションおよび磁気ディスク容量の高い消費量を伴うもの)配置すること、または、両者におけるばらつきを低減するディスク群510からの作業負荷を別のディスク群へマイグレーションすることによりアンバランスを解消する。
各VSANモジュール114は、オブジェクトストア116における全ての個別のディスクに亘るリソース作業負荷をバランスさせることを目的とするものの、VSANモジュール114は、均一なリソース消費量を目的とはしないことに留意されたい。概して、VSANモジュール114は、別のリソースタイプがまだ豊富に利用可能であるのにディスクにおける1つのリソースタイプが尽きることを避けるために、消費量におけるばらつきを低減するオブジェクト配置またはマイグレーションを選択する。
さらに、シンプロビジョニング構成において、VSANモジュール114は、潜在的に必要とされるリソースに対して十分なヘッドルームが利用可能であることを確実とするであろう。例えば、各々が200GBディスク上に予約された100GBを各々が有する3つの仮想マシンA,BおよびCを想定する。A,BおよびCが全て同時に、提供された100GB全部を使用するわけではないであろうが、VSANモジュール114は、ディスクが肥厚化する(例えば、仮想マシンがより多くのリソース容量を使用する)につれて作業負荷をリバランシングし得る。
図6は、一実施形態に係る、ディスク群内に関連する作業負荷を有するコンポーネントオブジェクトを別のディスク群にマイグレーションさせる、特定用途のケースの例を示す。ランタイム時に、VSANモジュールは、高いリソース使用量を低減し、仮想化クラスタにおける個別のディスクに亘る適切なバランスをもたらすためにマイグレーション決定を行なう。VSANモジュールは、リソースをバランスさせることにおいて、予約されたリソースおよび予約を超えたリソースの実際の使用量を考慮する。この例において、仮想化クラスタが3つのディスク群を含むと想定する。もちろん実際には、VSANは、より多くのディスク群を含み得る。図6は、図6の上部において、3つのディスク群605,610および615を示している。
示されているように、ディスク群605は、2つのワークグループAおよびBを含む。ワークグループAは、全てのタイプに亘って概ね均一な量のリソース消費量を示す一方、ワークグループBは、SSD容量において高い使用量を、他のリソースタイプにおいて低い使用量を示す。SSD容量における高い使用量は、結果としてアンバランスを生じる。ディスク群610は、比較的に均一に多量のリソースを消費する作業負荷Cを含む。ディスク群615は、多量のSSDオペレーション、磁気ディスクオペレーションおよび磁気ディスク容量を消費しているが、SSD容量の消費は少量である作業負荷Dを含む。その結果、ディスク群615におけるリソースタイプ間のばらつきは大きい。
ディスク群605および615におけるリソースは、4つのリソースタイプ間の消費量に大きいばらつきがあるため、効率的に使用されていない。リソース間のアンバランスを検出すると、VSANモジュールは、リソースがより均一に分散されるようリソースをリバランシングする。ディスク群605,610および615は、リバランシング後のディスク群605,610および615を示す。示されているように、ワークグループBは、ディスク群605からディスク群615へとマイグレーションされ、結果として、ディスク群615となる。その結果、605,610および615は、より均一にバランシングされたディスク群を表す。リバランシング方法は、図8においてさらに詳細に記述される。
図7は、一実施形態に係る、クラスタに亘るリソース使用量の負荷バランシング方法を示す。示されているように、各ノード111内のCLOM(Cluster Level Object Manager)サブモジュール325は、ポリシーを、DOM(Document Object Manager)サブモジュール340がLSOM(Log Structured Object Manager)サブモジュール350を介してローカルコンポーネントオブジェクトに適用するリソース割り当ての組に変換し得る。例示のポリシーは、要件(例えば、オペレーション、容量、可用性、信頼性)および新しい仮想マシンに適した作業負荷特性(例えば、期待キャッシュヒット率、I/Oリクエストサイズ)の組を特定するかもしれない。特定のポリシーをリソース割り当てに変換することにおいて、CLOMサブモジュール325は、ディスク群におけるばらつきを低減する既存のディスク群におけるオブジェクト配置を決定する。
方法は、ステップ705において開始し、CLOMサブモジュール325は、ポリシーに一致する候補配置を識別する。例えば、仮想化クラスタにおけるローカルノードが新たな仮想マシンをローンチすると想定する。仮想マシンは、700オペレーションおよび500GB容量のストレージ要件を有する。従って、CLOMサブモジュール325は、要件を満たすことが可能なコンポーネントオブジェクト内のディスク群を識別する。これを行なうために、CLOMサブモジュール325は、要件に沿ったオブジェクトのためにCMMDS(Cluster Monitoring, Membership, and Directory Services)サブモジュール335内のディレクトリサービスにコンサルトする。
ひとたびCLOMサブモジュール325が候補配置の組を識別すると、各候補配置に対して、CLOMサブモジュール325は、配置からの結果となるであろう期待ばらつきを判定する(710において)。これは結果として、増大または低減したばらつきを有する候補配置となる。その後、ステップ715において、CLOMサブモジュール325は、新たなオブジェクトを配置するための候補のうちの1つを選択する。一実施形態において、CLOMサブモジュール325は、毎回、同じディスク群にコンポーネントを配置することを避けるために、候補配置をランダムに選択する。
図8は、一実施形態に係る、ディスク群間の作業負荷のリバランシング方法を示す。各ノード111のDOMサブモジュール340が、並列に、各ローカルディスクの現在の消費量ステータスを、LSOMサブモジュール350からこのようなステータスを取得した後に、発行することが理解されるであろう。各ノード111のローカルVSANモジュール114は、ストレージクライアントに何が提供されているかをモニタリングし、ストレージクライアントが実際に使用しているリソースの量もモニタリングする。時折、ディスク群に超過アンバランスが生じ得る。例えば、相対的に小さいばらつきを有するディスク群が、それにもかかわらず削除後にアンバランスとなり得る。すなわち、ストレージクライアントは、他のリソースタイプを依然として使用しつつ、利用可能な多量のリソースタイプを残したまま、リソースタイプ(例えば、予約されたオペレーション)の多量の消費を終了し得る。別の例として、以前の配置またはリバランシングが、予期せずしてより大きい消費量ばらつきにつながり得る。
ともかく、ローカルディスク群内の超過アンバランスの際に、CLOMサブモジュール325は、別のディスク群へのマイグレーションのための、関連する作業負荷を有するソースコンポーネントを識別する。ディスク群605のリバランシングにおいて例として図6を使用すると、CLOMサブモジュール325は、別のディスク群へのマイグレーションのために、作業負荷Bを選択し得る。ステップ805において、CLOMサブモジュール325は、各ディスク群におけるリソース使用量の現在のステータスを取得する。述べられたように、各ノード111のDOMサブモジュール340は、SSDおよび磁気ディスクについての集約容量、予約および使用量データを発行する。ステップ810において、CLOMサブモジュール325は、候補マイグレーションを識別するために、発行されたデータを使用する。続く例において、CLOMサブモジュール325は、ディスク群615がコンポーネント作業負荷Bを取り扱うのに利用可能なリソースを有する一方、ディスク群610は有しないために、ディスク群615をマイグレーション候補として識別し得る。ただし、マイグレーションは制約下にあり得ることに留意されたい。例えば、ディスク群605が別のディスク群を伴うRAID(Redundant Arrays of Inexpensive Disks)−1ミラーであれば、ディスク群605は、関連する作業負荷Bを有するコンポーネントをそのディスク群へとマイグレーションすることができない。
ステップ815において、ひとたびCLOMサブモジュール325が候補マイグレーションを識別すると、それは、各潜在的マイグレーションについて期待ばらつきを判定する。CLOMサブモジュール325は、ばらつきを増大させる候補マイグレーションを無視し、ばらつきを減少させるマイグレーションを選ぶ。ステップ820において、CLOMサブモジュール325は、マイグレーションを選択し、ソース作業負荷を配置する。1つの特定の実施形態において、CLOMサブモジュール325は、そのディスク群への他のマイグレーションを避けるために選択をランダム化する。ステップ830において、CLOMサブモジュール325は、関連する作業負荷を有するコンポーネントを選択されたディスク群へと割り当てる。
1つ以上の実施形態が理解を明確にするために詳細に記述されてきたが、特許請求の範囲内においてある変更および修正がなされ得ることは明らかである。従って、記述された実施形態は例示的であり制限するものではないと考えられるべきであって、特許請求の範囲は、本開示にて与えられた詳細に制限されるべきではなく、しかし特許請求の範囲およびその均等物内において修正され得る。例えば、前述の多数の実施形態は、仮想マシンをVSANモジュールにより提供される仮想ディスクにアクセスするクライアントとして記述したが、非仮想化ホストサーバおよびそこで実行中の非仮想化アプリケーションのうちの少なくとも一方のクラスタ等の任意のクライアントが、代替実施形態においてVSANモジュールを同様に利用し得ることが理解されるべきである。同様に、VSANモジュールの代替実施形態が、限定するものではないが、REST(REpresentational State Transfer)オブジェクト、ファイル、ファイルシステム、ブロブ(バイナリーラージオブジェクト)および他のオブジェクト等の、仮想ディスク以外の高レベルストレージオブジェクトを作成可能であり得る。同様に、上記実施形態で説明されて負荷バランシング技術は、主にローカルストレージグループの配置およびリバランシングのうちの少なくとも一方の取り扱いに関するものであったが、代替実施形態は、メモリ、プロセッシング、およびネットワークリソースのうちの少なくとも一つをリバランスする同様の技術を使用し得る。そのような実施形態において、DOMサブモジュール304は、分散クラスタにおける他のノードに対するCPU、メモリ、およびネットワーキングにおける使用量をモニタリングし、発行し得る。同様に、VSANモジュール114がハイパーバイザ113内に埋め込まれるとして概して記述されてきたが、代替実施形態は、例えば特別な仮想マシンまたは仮想アプライアンス、別個のアプリケーションまたは分散オブジェクトストアを提供および管理するためにコンピューティングプラットフォームに挿入可能な任意の他の「プラガブル(pluggable)」モジュールまたはドライバとして、ハイパーバイザ113とは別個のVSANモジュールを実装し得る。
説明したように、本明細書の記載は、ホストによる各種のリソースの作業負荷のバランシングを提供するものである。有利には、各ホストコンピュータは、ローカルリソースを個々にリバランシングするので、この分散型アプローチは、負荷バランシングのための集中アルゴリズムまたはソフトウェアを用いることを必要としない。更に、このアプローチでは、ストレージクライアントが分散リソースシステム全体に亘って利用可能なリソースを効果的に消費することができ、個々のディスクが別のリソースタイプがまだ豊富に利用可能であるのに1つ以上のリソースタイプが尽きて動作することがない。
一般的に言えば、本開示に記述された各種の実施形態は、コンピュータシステム内にストアされたデータを伴う各種のコンピュータ実装オペレーションを採用し得る。例えば、これらのオペレーションは、通常は物理量の物理マニピュレーションを要求し得るが、必ずしもではないものの、これらの量は電気的または磁気的信号の形態を取り得、そこでは、それら、あるいは、それらの代表値は、ストアされ、伝送され、結合され、比較され、または別様にマニピュレートされることが可能である。さらに、このようなマニピュレーションは、しばしば製造、識別、判定または比較の観点で参照される。1つ以上の実施形態の一部を形成する本開示で記述された任意のオペレーションは、有用なマシンオペレーションであり得る。さらに、1つ以上の実施形態はまた、それらのオペレーションを実行するためのデバイスまたは装置に関する。装置は、特定の要求目的のために特別に構築され得、または、コンピュータにストアされたコンピュータプログラムにより選択的に活性化され、または構成される汎用コンピュータであり得る。特に、各種の汎用マシンが、本開示の教示に従って書かれたコンピュータプログラムと共に使用され得、または、要求されるオペレーションの実行のためにより特別化された装置を構築することが、より都合がよい場合もあり得る。
本開示に記述された各種の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータ、等を含む他のコンピュータシステム構成で実践され得る。
1つ以上の実施形態は、1つ以上のコンピュータ可読媒体内に具現化された1つ以上のコンピュータプログラムとして、または、1つ以上のコンピュータプログラムモジュールとして実装され得る。用語「コンピュータ可読媒体」は、後にコンピュータシステムに入力され得るデータを格納することが可能な任意のデータストレージデバイスを指し、コンピュータ可読媒体は、コンピュータによりコンピュータプログラムを読み取り可能なようにコンピュータプログラムを具現化するための任意の既存のまたは将来開発される技術に基づき得る。コンピュータ可読媒体の例には、ハードドライブ、ネットワーク接続ストレージ(NAS:Network Attached Storage)、リードオンリーメモリ、ランダムアクセスメモリ(例えば、フラッシュメモリデバイス)、CD(コンパクトディスク)、CD−ROM、CD−RまたはCD−RW、DVD(デジタルバーサタイルディスク)、磁気テープ、および、他の光学および非光学データストレージデバイスが含まれる。コンピュータ可読媒体はまた、コンピュータ可読コードが分散方式でストアされ、実行されるように、ネットワーク結合コンピュータシステム上に分散され得る。
1つまたは複数の実施形態が理解の明確のために詳しく説明されたが、いくつかの変更と修正が本開示の範囲内でなされ得るということは明らかである。したがって、記載の実施形態は例示的であって制限的でないと考えるべきであり、特許請求の範囲は本明細書に記載された詳細に限定されなく、請求項の範囲と均等物内で修正され得る。特許請求の範囲において、要素および工程のうちの少なくとも一方は特許請求範囲に明示的に示されない限り動作の任意特定順序を意味しない。
さらに、記述された仮想化方法は概して、仮想マシンが特定のハードウェアシステムに沿ったインターフェースを提示するものとしてきたが、記述された方法は、任意の特定のハードウェアシステムに直接には対応しない仮想化と共に使用され得る。ホスト化実施形態、非ホスト化実施形態、または、その両者間の区別があいまいとなりがちな実施形態として実装される、各種の実施形態に係る仮想化システムが、全て想定される。さらに、各種の仮想化オペレーションが、全体としてまたは部分的にハードウェア内に実装され得る。例えば、ハードウェア実装は、非ディスクデータをセキュアにするためにストレージアクセスリクエストの修正のためのルックアップテーブルを採用し得る。
仮想化の程度にかかわらず、多くの変形、修正、付加および改良が可能である。仮想化ソフトウェアはそれゆえ、ホスト、コンソールまたは仮想化機能を実行するゲストオペレーティングシステムのコンポーネントを含み得る。複数のインスタンスが、単一のインスタンスとして本開示に説明されるコンポーネント、オペレーションまたは構造のために提供され得る。最後に、各種コンポーネント、オペレーションおよびデータストアの境界は、いくらか恣意的であり、特定のオペレーションは特定の例示的構成の文脈で例示される。機能性の他の割り当てが想定され、1つ以上の実施形態の範囲に収まり得る。一般に、例示の構成において別個のコンポーネントとして表される構造および機能性は、結合された構造またはコンポーネントとして実装され得る。同様に、単一のコンポーネントとして表される構造および機能性は、別個のコンポーネントとして実装され得る。これらのおよび他の変形、修正、付加および改良は、添付の請求項の範囲内に収まり得る。



  1. 作業負荷を有するストレージオブジェクトを、分散リソースシステム内の複数のリソースタイプを有する多次元の組の分散リソースに分散させる方法であって、
    前記分散リソースシステムの各ノードにより発行されたリソースコンテナ内の前記複数のリソースタイプの各々のリソース使用量のステータスを取得することと、
    前記ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することであって、各候補リソースコンテナは、前記複数のリソースタイプのリソース使用量間の元のばらつきを有する、識別することと、
    各候補リソースコンテナについての前記複数のリソースタイプのリソース使用量間の期待ばらつきを判定することと、
    前記元のばらつきを超えるような前記期待ばらつきの増大を最小化する少なくとも1つの候補リソースコンテナのうちの1つに前記多次元の組の前記分散リソースを配置することと
    を備える方法。

  2. 前記分散リソースシステムは、ソフトウェア定義ストレージエリアネットワークであって、前記リソースコンテナは、各ノードに存在するストレージディスクの群であり、前記作業負荷は仮想マシンストレージ作業負荷に対応する、請求項1に記載の方法。

  3. 各ノードは、前記リソース使用量のステータスを前記ソフトウェア定義ストレージエリアネットワーク内の他のノードに発行する、請求項2に記載の方法。

  4. 前記元のばらつきよりも小さい前記期待ばらつきを伴う少なくとも1つの候補リソースコンテナの1つは、ランダムに選択される、請求項1に記載の方法。

  5. 前記配置された候補リソースコンテナ内のリソース使用量の前記ステータスを各ノードへと発行することをさらに備える、請求項1に記載の方法。

  6. 前記ステータスに基づいて1つ以上の候補リソースを識別することは、
    リソースタイプにより前記作業負荷を測定することと、
    測定値および前記リソースコンテナの各々の前記リソース使用量のステータスに基づいて前記作業負荷をストアすることが可能な候補リソースコンテナを判定することと
    をさらに備える、請求項1に記載の方法。

  7. プロセッサ上で実行されたときに、作業負荷を有するストレージオブジェクトを、分散リソースシステム内の複数のリソースタイプを有する多次元の組の分散リソースに分散させるオペレーションを実行する命令をストアする、非一時的コンピュータ可読ストレージ媒体であって、前記オペレーションが、
    前記分散リソースシステムの各ノードにより発行されたリソースコンテナ内の前記複数のリソースタイプの各々のリソース使用量のステータスを取得することと、
    前記ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することであって、各候補リソースコンテナは、前記複数のリソースタイプのリソース使用量間の元のばらつきを有する、識別することと、
    各候補リソースコンテナについての前記複数のリソースタイプのリソース使用量間の期待ばらつきを判定することと、
    前記元のばらつきを超えるような前記期待ばらつきの増大を最小化する少なくとも1つの候補リソースコンテナのうちの1つに前記多次元の組みの分散リソースを配置することと
    を備える、非一時的コンピュータ可読ストレージ媒体。

  8. 前記分散リソースシステムは、ソフトウェア定義ストレージエリアネットワークであって、前記リソースコンテナは各ノードに存在するストレージディスクの群であり、前記作業負荷は仮想マシンストレージ作業負荷に対応する、請求項7に記載のコンピュータ可読ストレージ媒体。

  9. 各ノードは、前記リソース使用量のステータスを前記ソフトウェア定義ストレージエリアネットワーク内の他のノードに発行する、請求項8に記載のコンピュータ可読ストレージ媒体。

  10. 前記元のばらつきよりも小さい前記期待ばらつきを伴う少なくとも1つの候補リソースコンテナの1つは、ランダムに選択される、請求項7に記載のコンピュータ可読ストレージ媒体。

  11. 前記オペレーションが、前記配置された候補リソースコンテナ内のリソース使用量の前記ステータスを各ノードへと発行することをさらに備える、請求項7に記載のコンピュータ可読ストレージ媒体。

  12. 前記ステータスに基づいて1つ以上の候補リソースを識別することは、
    リソースタイプにより前記作業負荷を測定することと、
    前記測定および前記リソースコンテナの各々の前記リソース使用量のステータスに基づいて前記作業負荷をストアすることが可能な前記候補リソースコンテナを判定することと
    をさらに備える、請求項7に記載のコンピュータ可読ストレージ媒体。

  13. プロセッサと、
    アプリケーションをホストするメモリであって、前記プロセッサ上で実行されたときに、作業負荷を有するストレージオブジェクトを、分散リソースシステム内の複数のリソースタイプを有する多次元の組の分散リソースに分散させるオペレーションを実行するメモリと
    を備えるシステムであって、前記オペレーションが、
    前記分散リソースシステムの各ノードにより発行されたリソースコンテナ内の前記複数のリソースタイプの各々のリソース使用量のステータスを取得することと、
    前記ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することであって、各候補リソースコンテナは、前記複数のリソースタイプのリソース使用量間の元のばらつきを有する、識別することと、
    各候補リソースコンテナについての前記複数のリソースタイプのリソース使用量間の期待ばらつきを判定することと、
    前記元のばらつきに対して前記期待ばらつき増大を最小化する少なくとも1つの候補リソースコンテナのうちの1つに前記多次元の組の分散リソースの組を配置することと
    を備える、システム。

  14. 前記分散リソースシステムは、ソフトウェア定義ストレージエリアネットワークであって、前記リソースコンテナは各ノードに存在するストレージディスクの群であり、前記作業負荷は仮想マシンストレージ作業負荷に対応する、請求項13に記載のシステム。

  15. 前記元のばらつきよりも小さい前記期待ばらつきを伴う少なくとも1つの候補リソースコンテナの1つは、ランダムに選択される、請求項13に記載のシステム。

  16. 前記オペレーションが、前記配置された候補リソースコンテナ内のリソース使用量の前記ステータスを各ノードに発行すること、をさらに備える、請求項13に記載のシステム。

  17. 前記ステータスに基づいて1つ以上の候補リソースを識別することは、
    リソースタイプにより前記作業負荷を測定することと、
    前記測定および前記リソースコンテナの各々の前記リソース使用量のステータスに基づいて前記作業負荷をストアすることが可能な前記候補リソースコンテナを判定することと
    をさらに備える、請求項13に記載のシステム。

  18. 分散リソースシステムにおいて複数のリソースタイプを有する多次元の組の分散リソースをリバランシング方法であって、
    前記分散リソースシステムの各ノードにより発行されたリソースコンテナ内の前記複数のリソースタイプの各々のリソース使用量のステータスを取得することと、
    前記リソースコンテナのうちの第1のリソースコンテナにおける前記リソース使用量のアンバランスを生じさせるソースオブジェクトコンポーネントを識別することと、
    前記ステータスに基づいて各ノード内の1つ以上の候補リソースコンテナを識別することであって、各候補リソースコンテナは、前記複数のリソースタイプのリソース使用量間の元のばらつきを有する、識別することと、
    各候補リソースコンテナについての前記複数のリソースタイプのリソース使用量間の期待ばらつきを判定することと、
    前記期待ばらつきに基づいて前記元のばらつきを低減する前記1つ以上の前記候補リソースコンテナのうちの1つに前記ソースオブジェクトコンポーネントを再配置することと
    を備える方法。

  19. 前記分散リソースシステムは、ソフトウェア定義ストレージエリアネットワークであって、前記リソースコンテナは各ノードに存在するストレージディスクの群であり、作業負荷は仮想マシンストレージ作業負荷に対応する、請求項18に記載の方法。

  20. 各ノードは、前記リソース使用量のステータスをソフトウェア定義ストレージエリアネットワーク内の他のノードに発行する、請求項18に記載の方法。

 

 

Patent trol of patentswamp
類似の特許
コマンド命令管理 // JP2016528566
コマンドバッファのメモリユニットのチェーンのメモリユニットにコマンドを書き込むための技法について説明する。本技法はコマンドを書き込み得、書込み中に、十分な空間がメモリユニットのチェーン中にないと決定された場合、本技法は、前に確認されたコマンドをフラッシュし得る。書込みの後に、本技法が、コマンドに関連付けられたハンドルのために十分な空間が割振りリスト中にないと決定した場合、本技法は、前に確認されたコマンドをフラッシュし得る。
【選択図】 図4
オーバーレイネットワーク内の消費者仮想マシンのために制作者仮想マシンをリースするプロセス及びシステムを開示する。消費者仮想マシンの消費者ホストは、一組のリースエージェントと通信して、サービスへのアクセスを消費者仮想マシンに提供可能な複数の制作者仮想マシンの識別情報を取得することができる。消費者仮想マシンが制作者システムとの通信を試みると、消費者ホストは、対象となる制作者仮想マシンをホストする制作者ホストを特定し、当該制作者ホストにサービス要求を転送することができる。
【選択図】図11
顧客は、仮想マシンインスタンスを実体化するハードウェア仕様を含む選好設定のセットを提起する。仮想コンピュータシステムサービスは、使用可能な物理的ホストコンピュータシステムの仕様を評価し、いずれかの物理的ホストコンピュータシステムが選好設定のセットに準拠するかどうかを判断するように構成される。仮想コンピュータシステムサービスは、使用可能な物理的ホストコンピュータシステムを評価し、使用可能な物理的ホストコンピュータシステムが既存の仮想マシンインスタンスを実体化するために使用可能なスロットを備えているかどうかを判断する。使用可能な物理的ホストコンピュータシステムが使用可能なスロットを備えている場合、仮想コンピュータシステムサービスは、顧客の要求を満たすために、既存の仮想マシンインスタンスを使用可能な物理的ホストコンピュータシステムに移動する。
【選択図】図1
一実施形態では、システムは、複数のプロセッサと、当該複数のプロセッサをさまざまな動作点の間で切り替えるように構成される自動電力状態コントローラ(APSC)とを含んでもよい。当該複数の動作点は、APSC内にプログラムされるデータによって記述されてもよく、APSCは、記述されている動作点の中からプロセッサのためのターゲット動作点を特定するターゲット動作点要求をプログラム可能なレジスタを含んでもよい。動作点を記述するデータは、また、動作点において同時にアクティブになっていてもよいプロセッサの数が制限されているか否かについての表示を含んでもよい。当該表示及びアクティブなプロセッサの数に基づいて、APSCは、要求動作点を低減動作点と置き換えてもよい。いくつかの実施形態では、デジタル電力推定器(DPE)がプロセッサの動作を監視してもよく、高い消費電力が検出されると、プロセッサに対してスロットリングを行ってよい。
データセンタにおいて計算インスタンスを事前準備するためのシステム、方法およびコンピュータ可読媒体が記述される。データセンタに関連するサービスプロバイダは、計算インスタンスについての要求を予測し、データセンタ内のコンピューティングリソースを事前設定することによって、計算インスタンスを事前起動することができる。そのようなものとして、ユーザが計算インスタンスをリクエストすると、サービスプロバイダは、事前準備された計算インスタンスをユーザに割り当てることによって、リクエストを満たすことができる。
ハドゥープアプリケーションおよび仮想環境内で実行される他の作業負荷の高弾力性マルチテナントプラットホームを提供する分散計算アプリケーションについて説明する。ハドゥープなどの分散計算フレームワークの複数のインスタンスは同時に実行され得る。中央集中型マネジャは、メモリおよびCPUなどの計算資源の競合により、タスクが、所与のホスト上で実行するVM上でより遅く実行される時を検知し、かつ検知された資源競合に基づきクラスタを拡大または縮小する。
コンピューティング・リソースの機器構成がユーザの代わりに仮想マシンを実行して暗号的に証明されるかあるいは確認することができるようにする手法。ユーザが、仮想マシンをプロビジョニングしてもらうことを要求するとき、仮想化されたコンピューティング環境のオペレータは仮想マシンの2段階立ち上げを開始することができる。第1段階では、オペレータは、ホスト・コンピューティング・デバイス上の仮想マシンをプロビジョニングし、ホスト・コンピューティング・デバイス上のソフトウェア及び/またはハードウェアのリソースの暗号測定を得る。その後、オペレータは、仮想マシンを要求したユーザにこれらの暗号測定を提供することができる。ユーザが暗号測定を承認すれば、オペレータは第2段階を始めて、実際に、ホスト上で仮想マシンを立ち上げることができる。ある場合には、オペレータは、暗号測定と承認された測定のリストとを比較してホスト・コンピューティング・デバイスが仮想マシンのホスティングに受け入れ可能かどうかを判断することができる。
【選択図】図6
異なるテナンシーセットを有する複数のデーターセンターからのアプリケーション起動エンドポイントを提供するためのエンドポイントブローカー。ユーザーに対するアプリケーション起動エンドポイント接続に対する要求にアクセスする際に、ブローカーは、異なるテナンシーセットを有する複数のデーターセンターの中から、要求の満足のためとしてエンドポイントを提供するためのものであるデーターセンターを選択する。エンドポイントブローカーは、エンドポイントを、選択されるデーターセンターから識別し、次いで、識別されるエンドポイントをユーザーに関連付ける。ユーザーは次いで、関連付けを使用して、識別されるエンドポイントへのアクセスを提供される。したがってユーザーは、単一のデーターセンターからのエンドポイントを有することに制約されない。1つのデーターセンターからのエンドポイントを提供することに関して懸念が存在するならば、エンドポイントは、別のデーターセンターから、ユーザーに意識されない様式で提供され得る。
プロデューサシステムへのコンシューマシステムアクセスをリースするプロセス及びシステムを開示する。コンシューマシステムは、1組のリースエージェントと通信して、サービスへのアクセスをコンシューマシステムに提供することができるいくつかのプロデューサシステムの識別情報を取得することができる。各リースエージェントは、一定期間にわたってプロデューサシステムへのアクセスをコンシューマシステムに提供し得る。コンシューマシステムが特定のプロデューサシステムへの更なるアクセスを必要とする場合、コンシューマシステムは、リースの更新を、プロデューサシステムの最初のリースをコンシューマシステムに提供したリースエージェントに要求することができる。
【選択図】図2
To top