特表 2024-544646 クラウドインフラストラクチャにおける動的なシステム作業負荷配置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-03

(54)【発明の名称】クラウドインフラストラクチャにおける動的なシステム作業負荷配置

(51)【国際特許分類】

   G06F 9/50 20060101AFI20241126BHJP

【ＦＩ】

G06F9/50 150Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024532511

(86)(22)【出願日】2022-11-29

(85)【翻訳文提出日】2024-07-11

(86)【国際出願番号】 US2022051208

(87)【国際公開番号】W WO2023101945

(87)【国際公開日】2023-06-08

(31)【優先権主張番号】63/284,528

(32)【優先日】2021-11-30

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

２．ｉＯＳ

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ヒギンソン，アントニー・スティーブン

(72)【発明者】

【氏名】ボストック，クライブ

(57)【要約】

システム、方法、および機械可読媒体は、ソースシステムからターゲットシステムへのデータおよびアプリケーションのマイグレーションにおいて、ソースシステムの作業負荷を配置することができる。第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取り、分析することができる。ソースシステムからターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することができる。配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み得る。プラガブル環境またはクラスタ化された環境をパッキングすることは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合、ソースノードからターゲットノードに作業負荷を配置することと、ターゲットノードの第２の数がソースノードの第１の数よりも少ない場合、ソースノードからの作業負荷はターゲットノードに配置されないこととを含み得る。

【特許請求の範囲】

【請求項1】

１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステムであって、
１つまたは複数の処理デバイスと、前記１つまたは複数の処理デバイスと通信可能に連結されるとともに前記１つまたは複数の処理デバイスによって読み出し可能であるメモリとを備え、
前記メモリは、前記１つまたは複数の処理デバイスによって実行されると、前記１つまたは複数の処理デバイスに動作を実行させる、プロセッサ可読命令を含み、前記動作は、
第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることと、
前記第１の数のソースノードおよび前記第２の数のターゲットノードに関するデータを分析することと、
１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することと、を含み、
前記配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み、前記プラガブル環境または前記クラスタ化された環境をパッキングすることは、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合、前記ソースノードから前記ターゲットノードに作業負荷を配置することと、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも少ない場合、前記ソースノードからの前記作業負荷は前記ターゲットノードに配置されず、１つまたは複数のロールバック動作が実行されることと、を含み、
前記マイグレーション計画によるマイグレーションを実行することをさらに含み、
前記マイグレーションは、ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合に、前記作業負荷を前記ソースノードから前記ターゲットノードに配置することを含む、システム。

【請求項2】

前記１つまたは複数のターゲットシステムはクラウドインフラストラクチャに対応し、前記作業負荷の前記配置は、前記クラウドインフラストラクチャにおいて前記作業負荷を配置することに対応する、請求項１に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項3】

前記動作は、前記作業負荷の前記配置が、少なくとも部分的に、ベクトルを増大させることができる１つまたは複数の次元に基づくように、スケーラブルである、請求項２に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項4】

前記ベクトルは、入出力（ＩＯ）メトリック、中央処理装置（ＣＰＵ）メトリック、および／またはメモリメトリックのうちの１つまたは複数に対応するメトリックの次元を含む、請求項３に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項5】

前記ベクトルは時間の関数である、請求項４に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項6】

前記動作は、
前記作業負荷に対応する統合された時系列データ信号を取得することと、
前記統合された時系列データ信号を分析し、前記統合された時系列データ信号をターゲットビンの合計と比較して、無駄を削減するためにエラスティック化によってさらなる効率を得ることができるか否かを判定することとを、さらに含む、請求項５に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項7】

前記動作は、
前記ターゲットビンをエラスティックにすることをさらに含み、
前記ターゲットビンは、クラウド構成のノードに対応する、請求項６に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項8】

前記マイグレーションサービスはクラウドベースである、請求項７に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置するシステム。

【請求項9】

１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法であって、
マイグレーションインフラストラクチャが、第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることを含み、
前記マイグレーションインフラストラクチャは、前記第１の数のソースノードからリモートに位置し、マイグレーションサービスを提供するように構成され、
前記方法は、
前記マイグレーションインフラストラクチャが、前記第１の数のソースノードおよび前記第２の数のターゲットノードに関する前記データを分析することと、
前記マイグレーションインフラストラクチャが、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することと、を含み、
前記配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み、前記プラガブル環境または前記クラスタ化された環境をパッキングすることは、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合、前記ソースノードから前記ターゲットノードに作業負荷を配置することと、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも少ない場合、前記ソースノードからの前記作業負荷は前記ターゲットノードに配置されず、１つまたは複数のロールバック動作が実行されることと、を含み、
前記方法は、
前記マイグレーションインフラストラクチャが、前記マイグレーション計画によるマイグレーションを実行することをさらに含み、
前記マイグレーションは、ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合に、前記作業負荷を前記ソースノードから前記ターゲットノードに配置することを含む、方法。

【請求項10】

前記１つまたは複数のターゲットシステムはクラウドインフラストラクチャに対応し、前記作業負荷の前記配置は、前記クラウドインフラストラクチャにおいて前記作業負荷を配置することに対応する、請求項９に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項11】

前記方法は、前記作業負荷の前記配置が、少なくとも部分的に、ベクトルを増大させることができる１つまたは複数の次元に基づくように、スケーラブルである、請求項１０に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項12】

前記ベクトルは、入出力（ＩＯ）メトリック、中央処理装置（ＣＰＵ）メトリック、および／またはメモリメトリックのうちの１つまたは複数に対応するメトリックの次元を含む、請求項１１に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項13】

前記ベクトルは時間の関数である、請求項１２に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項14】

前記方法は、
前記作業負荷に対応する統合された時系列データ信号を取得することと、
前記統合された時系列データ信号を分析し、前記統合された時系列データ信号をターゲットビンの合計と比較して、無駄を削減するためにエラスティック化によってさらなる効率を得ることができるか否かを判定することとを、さらに含む、請求項１３に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項15】

前記方法は、
前記ターゲットビンをエラスティックにすることをさらに含み、
前記ターゲットビンは、クラウド構成のノードに対応する、請求項１４に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項16】

前記マイグレーションサービスはクラウドベースである、請求項１５に記載の、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、前記１つまたは複数のソースシステムの作業負荷を配置する方法。

【請求項17】

１つまたは複数の処理デバイスによって実行されると、前記１つまたは複数の処理デバイスに動作を実行させる、機械可読命令を有する１つまたは複数の非一時的機械可読媒体であって、前記動作は、
第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることと、
前記第１の数のソースノードおよび前記第２の数のターゲットノードに関する前記データを分析することと、
１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することと、を含み、
前記配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み、前記プラガブル環境または前記クラスタ化された環境をパッキングすることは、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合、前記ソースノードから前記ターゲットノードに作業負荷を配置することと、
ターゲットノードの前記第２の数がソースノードの前記第１の数よりも少ない場合、前記ソースノードからの前記作業負荷は前記ターゲットノードに配置されず、１つまたは複数のロールバック動作が実行されることと、を含み、
前記マイグレーション計画によるマイグレーションを実行することをさらに含み、
前記マイグレーションは、ターゲットノードの前記第２の数がソースノードの前記第１の数よりも多い場合に、前記作業負荷を前記ソースノードから前記ターゲットノードに配置することを含む、１つまたは複数の非一時的機械可読媒体。

【請求項18】

前記１つまたは複数のターゲットシステムはクラウドインフラストラクチャに対応し、前記作業負荷の前記配置は、前記クラウドインフラストラクチャにおいて前記作業負荷を配置することに対応する、請求項１７に記載の１つまたは複数の非一時的機械可読媒体。

【請求項19】

前記方法は、前記作業負荷の配置が、少なくとも部分的に、ベクトルを増大させることができる１つまたは複数の次元に基づくように、スケーラブルである、請求項１８に記載の１つまたは複数の非一時的機械可読媒体。

【請求項20】

前記ベクトルは、入出力（ＩＯ）メトリック、中央処理装置（ＣＰＵ）メトリック、および／またはメモリメトリックのうちの１つまたは複数に対応するメトリックの次元を含む、請求項１９に記載の１つまたは複数の非一時的機械可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２１年１１月３０日に出願された米国仮特許出願第６３／２８４，５２８号の通常出願であって、その優先権を主張するものであり、あらゆる目的のために参照により本明細書に組み込まれる。

【0002】

技術分野
本開示は、一般に、システム作業負荷（ワークロード）配置のシステムおよび方法に関し、より詳細には、クラウドインフラストラクチャにおける動的なシステム作業負荷配置のためのシステムおよび方法に関する。

【背景技術】

【0003】

背景
キャパシティ（容量）計画は、任意のマルチサーバコンピュータシステムの調達および日々の運用において不可欠な活動である。作業負荷配置は、周知の問題であり、さまざまなシェイプの作業負荷を配置するために、どこで、いつ、どれだけのリソースが必要であるか（消費されるリソース）を知るというキャパシティ計画問題に対処するのに役立つ、いくつかの解決法がある。作業負荷配置問題に対処するために、ビンパッキングアルゴリズムが広く使用され得る。

【0004】

しかしながら、従来の作業負荷配置は多くの問題および難題をはらんでいる。たとえば、煩雑であり計算のエラーを回避することができないスプレッドシートの手作業による構築、複雑なスプレッドシート変換を必要とするベンチマーク（たとえば、ＳＰＥＣＩｎｔ、Ｍ－Ｖａｌｕｅｓベンチマーク）を使用するチップセットの変換、設計者しか理解することができない複雑なスプレッドシート、アルゴリズムがリポジトリに照会することによって作業負荷を配置することができるときに、設計／計画を完了するために数日間／数週間が必要である自動化レベルの低さ、標準化されていない特注のスプレッドシート、配置仕様および設計が安全で監査可能なクラウドリポジトリに格納されていないために安全でないことなどにより、不正確さおよび非効率性が生じる可能性がある。このような問題は、システムがマルチテナントアーキテクチャを使用してサーバスプロールをマージするかまたは削減している統合型サービス、作業負荷がすでに配置されているかまたはスコープが定義されているマネージドクラウドサービス、作業負荷が統合されるあらゆるクラウド製品など、さまざまなタイプのサービスに影響を及ぼす可能性がある。さらに、現在のビンパッキングアルゴリズムは、クラスタリングなどの高可用性（ＨＡ：High Availability）を採用するシステムを考慮しておらず、「兄弟（sibling）」作業負荷で構成される作業負荷とは対照的に、作業負荷を個々に扱うことが多い。

【0005】

したがって、複雑性に対処し、効率を向上させ、エラーを減少させ、速度を上昇させ、他の方法でデータベースまたはアプリケーションの作業負荷配置を改善する、システムおよび方法が必要とされている。これらおよび他のニーズは、本開示によって対処される。

【発明の概要】

【課題を解決するための手段】

【0006】

簡単な概要
本開示の実施形態は、一般に、システム作業負荷配置のシステムおよび方法に関し、より詳細には、クラウドインフラストラクチャにおける動的なシステム作業負荷配置のシステムおよび方法に関する。

【0007】

１つの態様では、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、１つまたは複数のソースシステムの作業負荷を配置するシステムを開示する。本システムは、１つまたは複数の処理デバイスと、１つまたは複数の処理デバイスと通信可能に連結されるとともに１つまたは複数の処理デバイスによって読み出し可能であるメモリとを備えることができ、メモリは、１つまたは複数の処理デバイスによって実行されると、１つまたは複数の処理デバイスに、以下のうちの１つまたは組み合わせを含み得る動作を実行させる、プロセッサ可読命令を含む。第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることができる。マイグレーションインフラストラクチャは、第１の数のソースノードからリモートに位置することができ、マイグレーションサービスを提供するように構成することができる。第１の数のソースノードおよび第２の数のターゲットノードに関するデータを分析することができる。１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することができる。配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み得る。プラガブル環境またはクラスタ化された環境をパッキングすることは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合、ソースノードからターゲットノードに作業負荷を配置することと、ターゲットノードの第２の数がソースノードの第１の数よりも少ない場合、ソースノードからの作業負荷はターゲットノードに配置されず、１つまたは複数のロールバック動作を実行することを含み得る。マイグレーション計画によるマイグレーションを実行することができる。マイグレーションは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合に、作業負荷をソースノードからターゲットノードに配置することを含み得る。

【0008】

別の態様では、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、１つまたは複数のソースシステムの作業負荷を配置する方法を開示する。本方法は、以下のうちの１つまたは組み合わせを含み得る。マイグレーションインフラストラクチャによって、第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることができる。マイグレーションインフラストラクチャは、第１の数のソースノードからリモートに位置することができ、マイグレーションサービスを提供するように構成することができる。マイグレーションインフラストラクチャによって、第１の数のソースノードおよび第２の数のターゲットノードに関するデータを分析することができる。マイグレーションインフラストラクチャによって、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することができる。配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み得る。プラガブル環境またはクラスタ化された環境をパッキングすることは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合、ソースノードからターゲットノードに作業負荷を配置することと、ターゲットノードの第２の数がソースノードの第１の数よりも少ない場合、ソースノードからの作業負荷はターゲットノードに配置されず、１つまたは複数のロールバック動作を実行できることとを含み得る。マイグレーションインフラストラクチャによって、マイグレーション計画によるマイグレーションを実行することができる。マイグレーションは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合に、作業負荷をソースノードからターゲットノードに配置することを含み得る。

【0009】

さらに別の態様では、１つまたは複数の処理デバイスによって実行されると、１つまたは複数の処理デバイスに、以下のうちの１つまたは組み合わせを含み得る動作を実行させる、機械可読命令を有するものとして、１つまたは複数の非一時的機械可読媒体を開示する。第１の数のソースノードおよび第２の数のターゲットノードに関するデータを受け取ることができる。マイグレーションインフラストラクチャは、第１の数のソースノードからリモートに位置することができ、マイグレーションサービスを提供するように構成することができる。第１の数のソースノードおよび第２の数のターゲットノードに関するデータを分析することができる。１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することができる。配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み得る。プラガブル環境またはクラスタ化された環境をパッキングすることは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合、ソースノードからターゲットノードに作業負荷を配置することと、ターゲットノードの第２の数がソースノードの第１の数よりも少ない場合、ソースノードからの作業負荷はターゲットノードに配置されず、１つまたは複数のロールバック動作を実行することを含み得る。マイグレーション計画によるマイグレーションを実行し得る。マイグレーションは、ターゲットノードの第２の数がソースノードの第１の数よりも多い場合に、作業負荷をソースノードからターゲットノードに配置することを含み得る。

【0010】

さまざまな実施形態において、１つまたは複数のターゲットシステムはクラウドインフラストラクチャに対応することができ、作業負荷の配置は、クラウドインフラストラクチャにおいて作業負荷を配置することに対応することができる。さまざまな実施形態において、動作および方法は、作業負荷の配置が、少なくとも部分的に、ベクトルを増大させることができる１つまたは複数の次元に基づくことができるように、スケーラブルであり得る。さまざまな実施形態において、ベクトルは、入出力（ＩＯ）メトリック、中央処理装置（ＣＰＵ）メトリック、および／またはメモリメトリックのうちの１つまたは複数に対応するメトリックの次元を含み得る。さまざまな実施形態において、ベクトルは時間の関数であり得る。さまざまな実施形態において、作業負荷に対応する統合された時系列データ信号を取得することができる。統合された時系列データ信号を分析することができ、統合された時系列データ信号をターゲットビンの合計と比較して、無駄を削減するためにエラスティック化によってさらなる効率を得ることができるか否かを判定することができる。さまざまな実施形態において、ターゲットビンをエラスティックにすることができる。ターゲットビンは、クラウド構成のノードに対応することができる。さまざまな実施形態において、マイグレーションサービスはクラウドベースであり得る。

【0011】

本開示のさらなる適用可能性の範囲は、以下に提供する詳細な説明から明らかになるであろう。詳細な説明および具体的な例は、さまざまな実施形態を示しているが、単に例示を目的とするように意図されており、本開示の範囲を必ずしも限定するように意図されていないことが理解されるべきである。

【0012】

本開示による実施形態の性質および利点のさらなる理解は、以下の添付図と併せて本明細書の残りの部分を参照することによって実現することができる。

【図面の簡単な説明】

【0013】

【図1】本開示により開示される実施形態に応じた、分散システムの簡略図である。

【図2】本開示により開示される実施形態に応じた、システムの１つまたは複数のコンポーネントによって提供されるサービスをクラウドサービスとして提供することができるシステム環境の１つまたは複数のコンポーネントの簡略化されたブロック図である。

【図3】本開示により開示される実施形態に応じた、例示的なコンピュータシステムを示す図である。

【図5】本開示により開示される実施形態に応じた、システムが提供することができるさまざまな構成および作業負荷複雑性の例を示す図である。

【図6】本開示により開示される実施形態に応じた、１つのシステムとして作用するように参加して、合わせて管理されるクラスタを示す図である。

【図7】本開示により開示される実施形態に応じた、ＣＰＵ使用率の態様を示す図である。

【図8】本開示により開示される実施形態に応じた、システムの開示する実施形態によって対処されるＲＡＣ作業負荷の複雑性の態様例を示す図である。

【図9】本開示により開示される実施形態に応じた、マルチテナントアーキテクチャを有するプラガブルデータベースの態様を示す図である。

【図10】本開示により開示される実施形態に応じた、ベクトルの態様を示す図である。

【図11】本開示により開示される実施形態に応じた、ノードリソースキャパシティの態様を示す図である。

【図12】本開示により開示される実施形態に応じた、作業負荷リソース需要の態様を示す図である。

【図13】本開示により開示される実施形態に応じた、システムが作業負荷の態様を判定する方法の別の例を示す図である。

【図14】本開示により開示される実施形態に応じた、システムが、データの異常を考慮して、統合された時間的作業負荷を分析する方法の一例を示す図である。

【図15】本開示により開示される実施形態に応じた、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションを促進する方法例を示す図である。

【図16A】本開示により開示される実施形態に応じた、ファーストフィット（first fit）によるターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す図である。

【図16B】本開示により開示される実施形態に応じた、最適なフィット（optimal fit）によるターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す図である。

【0014】

添付の図において、同様の構成要素および／または特徴は、同じ参照符号を有するものとする。さらに、参照符号の後に同様の構成要素を識別するダッシュおよび第２の符号が続くことによって、同じタイプのさまざまな構成要素を識別することができる。本明細書において第１の参照符号のみを使用する場合、その記載は、第２の参照符号に関係なく、同じ第１の参照符号を有する同様の構成要素のいずれか１つに対して適用可能である。

【発明を実施するための形態】

【0015】

詳細な説明
続く説明は、単に好ましい例示的な実施形態を提供するものであり、本開示の範囲、適用可能性、または構成を限定するようには意図されていない。むしろ、好ましい例示的な実施形態の続く説明は、当業者に、本開示の好ましい例示的な実施形態を実施することを可能にする説明を提供する。添付の特許請求の範囲に示すような本開示の趣旨および範囲から逸脱することなく、要素の機能および配置においてさまざまな変更を行うことができることが理解されるべきである。

【0016】

本開示によるさまざまな実施形態は、クラウドインフラストラクチャにおける動的なデータベース作業負荷配置のためのシステム、方法、および非一時的媒体を提供することができる。さまざまな実施形態は、ベクトルを作成するあるシェイプのリソースを消費する任意の作業負荷に対して機能することができる。ベクトルは、クラウドコンピューティングのＰａａＳ、ＳａａＳ、およびＤＢａａＳ層のアプリケーションに適用されるメトリックを含む、入出力（ＩＯ）メトリック（たとえば、入出力操作毎秒（ＩＯＰＳ））、メモリメトリック（たとえば、メモリ利用率）、中央処理装置（ＣＰＵ）（たとえば、ＣＰＵ利用率）などの任意のシェイプの測定基準（メトリック）であり得る。さまざまな実施形態は、Ｎ層（Ｎ－Ｔｉｅｒ）などのオンプレミスアーキテクチャも含み得る。

【0017】

ここで、図１から始まる添付の図を参照して、さまざまな実施形態についてより詳細に開示する。図１は、本開示に従い開示される実施形態を実施するための分散システム１００の簡略図を示す。図１に示す構成要素の選択および／または配置は、単に例として示すものであり、限定的であるように意図されていない。図示する実施形態では、分散システム１００は、１つまたは複数のクライアントコンピューティングデバイス１０２、１０４、１０６、および１０８を含み、これらは、１つまたは複数のネットワーク１１０を介して、ウェブブラウザ、プロプライエタリクライアント（たとえば、Oracle Forms）などのクライアントアプリケーションを実行および操作するように構成されている。サーバ１１２は、ネットワーク１１０を介して、リモートクライアントコンピューティングデバイス１０２、１０４、１０６、および１０８と通信可能に接続することができる。

【0018】

さまざまな実施形態において、サーバ１１２は、システムのコンポーネントのうちの１つまたは複数によって提供される１つまたは複数のサービスまたはソフトウェアアプリケーションを実行するように適合させることができる。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス１０２、１０４、１０６、および／または１０８のユーザに対して、ウェブベースサービスもしくはクラウドサービスとして、またはサービスとしてのソフトウェア（ＳａａＳ：Software as a Service）モデルの下で提供することができる。クライアントコンピューティングデバイス１０２、１０４、１０６、および／または１０８を操作するユーザは、次いで、サーバ１１２とインタラクトする１つまたは複数のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを利用することができる。

【0019】

図に示す構成では、システム１００のソフトウェアコンポーネント１１８、１２０、および１２２は、サーバ１１２上に実装されているものとして示されている。他の実施形態では、システム１００のコンポーネントのうちの１つまたは複数、および／またはこれらのコンポーネントによって提供されるサービスは、クライアントコンピューティングデバイス１０２、１０４、１０６、および／または１０８のうちの１つまたは複数によって実装してもよい。クライアントコンピューティングデバイスを操作するユーザは、次いで、１つまたは複数のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを使用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実装することができる。分散システム１００とは異なる場合がある、さまざまな異なるシステム構成が可能であることが理解されるべきである。したがって、図に示す実施形態は、システム実施形態を実装するための分散システムの１つの例であり、限定的であるように意図されていない。

【0020】

クライアントコンピューティングデバイス１０２、１０４、１０６、および／または１０８は、Microsoft Windows Mobile（登録商標）などのソフトウェア、および／またはｉＯＳ、Windows Phone、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ、Ｐａｌｍ ＯＳなどの種々のモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）、または他の通信プロトコルが使用可能である、ポータブルハンドヘルドデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえば、Google Glass（登録商標）ヘッドマウントディスプレイ）であり得る。クライアントコンピューティングデバイスは、例として、Microsoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行する、パーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用パーソナルコンピュータとすることができる。クライアントコンピューティングデバイスは、限定されないが、たとえばGoogle Chrome（登録商標） OSなどの種々のＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを含む、種々の市販のＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステムのうちの任意のものを実行するワークステーションコンピュータとすることができる。代替的に、または加えて、クライアントコンピューティングデバイス１０２、１０４、１０６、および１０８は、ネットワーク１１０を介して通信することができる、シンクライアントコンピュータ、インターネット対応ゲームシステム（たとえば、Kinect（登録商標）ジェスチャ入力デバイス付きまたはなしのMicrosoft Xbox（登録商標）ゲームコンソール）、および／またはパーソナルメッセージングデバイスなどの他の任意の電子デバイスであってもよい。

【0021】

例示的な分散システム１００は、４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートしてもよい。センサを有するデバイスなど、他のデバイスがサーバ１１２とインタラクトしてもよい。

【0022】

分散システム１００におけるネットワーク１１０は、限定されないが、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケットエクスチェンジ）、ＡｐｐｌｅＴａｌｋなどを含む、種々の市販のプロトコルのうちの任意のものを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであり得る。単に例として、ネットワーク１１０は、Ｅｔｈｅｒｎｅｔ（登録商標）、トークンリングなどに基づくものなどのローカルエリアネットワーク（ＬＡＮ）とすることができる。ネットワーク１１０は、広域ネットワークおよびインターネットとすることができる。ネットワーク１１０は、限定されないが、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、電気電子学会（ＩＥＥＥ）８０２．１１プロトコルスイート、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および／または他の無線プロトコルのうちの任意のものに基づいて動作するネットワーク）、ならびに／またはこれらおよび／もしくは他のネットワークの任意の組み合わせを含む、仮想ネットワークを含み得る。

【0023】

サーバ１１２は、１つまたは複数の汎用コンピュータ、専用サーバコンピュータ（例として、ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを含む）、サーバファーム、サーバクラスタ、または他の任意の適切な配置および／もしくは組み合わせから構成することができる。さまざまな実施形態において、サーバ１１２は、前述の開示で記載した１つまたは複数のサービスまたはソフトウェアアプリケーションを実行するように適合させることができる。たとえば、サーバ１１２は、本開示の実施形態に従って上述した処理を実行するためのサーバに対応してもよい。

【0024】

サーバ１１２は、上述したもののうちの任意のもの、および市販の任意のサーバオペレーティングシステムを含むオペレーティングシステムを実行することができる。サーバ１１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェース）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、種々の追加のサーバアプリケーションおよび／または中間層アプリケーションのいずれかを実行することもできる。例示的なデータベースサーバとしては、限定されないが、Oracle、Microsoft、Sybase、ＩＢＭ（International Business Machines）などから市販されているものが挙げられる。

【0025】

いくつかの実施態様において、サーバ１１２は、クライアントコンピューティングデバイス１０２、１０４、１０６、および１０８のユーザから受信したデータフィードおよび／またはイベントアップデートを分析および統合するための１つまたは複数のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、限定されないが、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデート、または１つまたは複数のサードパーティ情報ソースおよび連続したデータストリームから受信されるリアルタイムアップデートを含む場合があり、データフィードおよび／またはイベントアップデートとしては、センサデータアプリケーション、金融ティッカー、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを挙げることができる。サーバ１１２は、クライアントコンピューティングデバイス１０２、１０４、１０６、および１０８の１つまたは複数の表示デバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つまたは複数のアプリケーションも含み得る。

【0026】

分散システム１００は、１つまたは複数のデータベース１１４も含み得る。データベース１１４は、種々の場所に存在することができる。例として、データベース１１４のうちの１つまたは複数は、サーバ１１２に対してローカルな（かつ／またはサーバ１１２内に存在する）非一時的記憶媒体に存在してもよい。代替的に、データベース１１４は、サーバ１１２からリモートにあって、ネットワークベース接続または専用接続を介してサーバ１１２と通信してもよい。さまざまな実施形態において、データベース１１４は、ブロック、ファイル、またはオブジェクトストレージなど、ストレージエリアネットワーク（ＳＡＮ）、ＮＡＳ（Network Attached Storage）、またはクラウドストレージ機能に存在してもよい。同様に、サーバ１１２に帰属する機能を実行するために必要ないかなるファイルも、適宜、サーバ１１２上にローカルに格納し、かつ／または、リモートに格納してもよい。一組の実施形態では、データベース１１４は、Oracleによって提供されるデータベースなど、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、取り出すように適合した、リレーショナルデータベースを含んでもよい。

【0027】

図２は、本開示のいくつかの実施形態に応じた、システム環境２００の１つまたは複数のコンポーネントの簡略化されたブロック図であり、このシステム環境２００により、システムの１つまたは複数のコンポーネントによって提供されるサービスをクラウドサービスとして提供することができる。図示する実施形態では、システム環境２００は、ユーザが、クラウドサービスを提供するクラウドインフラストラクチャシステム１３０－１とインタラクトするために使用することができる、１つまたは複数のクライアントコンピューティングデバイス２０４、２０６、および２０８を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスを使用するために、クライアントコンピューティングデバイスのユーザがクラウドインフラストラクチャシステム１３０－１とインタラクトするために使用することができる、ウェブブラウザ、プロプライエタリクライアントアプリケーション（たとえば、Oracle Forms）、または他の何らかのアプリケーションなどのクライアントアプリケーションを動作させるように構成することができる。

【0028】

図に示すクラウドインフラストラクチャシステム１３０－１は、図示するコンポーネント以外のコンポーネントを有していてもよいことが理解されるべきである。さらに、図に示す実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの単なる１つの例である。他のいくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１は、図に示すものよりも多いかまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。

【0029】

クライアントコンピューティングデバイス２０４、２０６、および２０８は、１０２、１０４、１０６、および１０８について上述したものと同様のデバイスであり得る。例示的なシステム環境２００は、３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートしてもよい。センサを有するデバイスなどの他のデバイスが、クラウドインフラストラクチャシステム１３０－１とインタラクトしてもよい。

【0030】

ネットワーク２１０は、クライアント２０４、２０６、および２０８とクラウドインフラストラクチャシステム１３０－１との間の通信およびデータ交換を容易にすることができる。各ネットワークは、ネットワーク１１０について上述したものを含む、種々の市販のプロトコルのうちの任意のものを使用してデータ通信をサポートすることができる、当業者によく知られている任意のタイプのネットワークであり得る。クラウドインフラストラクチャシステム１３０－１は、サーバ１１２について上述したものを含み得る１つまたは複数のコンピュータおよび／またはサーバを含み得る。

【0031】

いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービスなど、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用することができるようになるサービスのホストを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリングすることができる。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンスを、本明細書では「サービスインスタンス」と呼ぶ。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用できるようになるいかなるサービスも、「クラウドサービス」と呼ぶ。通常、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、クライアント自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストすることができ、ユーザは、インターネットなどの通信ネットワークを介して、オンデマンドでこのアプリケーションをオーダーし、使用することができる。

【0032】

いくつかの例では、コンピュータネットワークのクラウドインフラストラクチャにおけるサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供されるかもしくは本技術分野において他の方法で既知であるような他のサービスへの、保護されたコンピュータネットワークアクセスを含む場合がある。たとえば、サービスは、インターネットを介してクラウド上のリモートストレージへのパスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク接続された開発者が私的に使用するための、ウェブサービスベースのホストされたリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされている電子メールソフトウェアアプリケーションへのアクセスを含み得る。

【0033】

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１は、セルフサービスの、サブスクリプションベースの、エラスティックにスケーラブルで、信頼性が高く、可用性が高く、セキュアな方法でクライアントに提供される、アプリケーション、ミドルウェア、およびデータベースサービス提供物一式を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本出願の譲受人が提供するOracle Public Cloudである。

【0034】

さまざまな実施形態において、クラウドインフラストラクチャシステム１３０－１は、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスに対するクライアントのサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合させることができる。クラウドインフラストラクチャシステム１３０－１は、異なるデプロイメントモデルを介してクラウドサービスを提供することができる。たとえば、サービスは、（たとえば、Oracleが所有する）クラウドサービスを販売する組織がクラウドインフラストラクチャシステム１３０－１を所有し、一般大衆または異なる業界企業がサービスを利用することができるようになる、パブリッククラウドモデルの下で提供してもよい。別の例として、クラウドインフラストラクチャシステム１３０－１が単一の組織のためだけに運用され、その組織内の１つまたは複数のエンティティにサービスを提供することができる、プライベートクラウドモデルの下で、サービスを提供してもよい。クラウドサービスは、クラウドインフラストラクチャシステム１３０－１およびクラウドインフラストラクチャシステム１３０－１によって提供されるサービスが、関連コミュニティ内のいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供してもよい。クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供してもよい。

【0035】

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスは、サービスとしてのソフトウェア（ＳａａＳ：Software as a Service）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ：Platform as a Service）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ：Infrastructure as a Service）カテゴリ、またはハイブリッドサービスを含む他のカテゴリのサービスの下で提供される、１つまたは複数のサービスを含み得る。クライアントは、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１３０－１によって提供される１つまたは複数のサービスをオーダーすることができる。その後、クラウドインフラストラクチャシステム１３０－１は、このクライアントのサブスクリプションオーダーのサービスを提供するための処理を実行する。

【0036】

いくつかの実施形態において、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスは、限定されないが、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含み得る。いくつかの例において、アプリケーションサービスは、ＳａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供することができる。ＳａａＳプラットフォームは、ＳａａＳカテゴリに含まれるクラウドサービスを提供するように構成してもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上でオンデマンドのアプリケーション一式を構築および提供する機能を提供することができる。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御することができる。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、クライアントは、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用することができる。クライアントは、別個のライセンスおよびサポートを購入する必要なしに、アプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスを提供することができる。例としては、限定されないが、販売実績管理、企業統合、および大規模組織向けのビジネス柔軟性のためのソリューションを提供するサービスが挙げられる。

【0037】

いくつかの実施形態において、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供することができる。ＰａａＳプラットフォームは、ＰａａＳカテゴリに含まれるクラウドサービスを提供するように構成することができる。プラットフォームサービスの例としては、限定されないが、組織（Oracleなど）が既存のアプリケーションを共有の共通アーキテクチャ上に統合することを可能にするサービス、およびプラットフォームによって提供される共有サービスを活用する新しいアプリケーションを構築する機能を挙げることができる。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御することができる。クライアントは、別個のライセンスおよびサポートを購入する必要なしに、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例としては、限定されないが、Oracle Java Cloud Service（ＪＣＳ）、Oracle Database Cloud Service（ＤＢＣＳ）などが挙げられる。

【0038】

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、クライアントは、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用することができるとともに、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスとしては、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、Oracle Fusion Middlewareサービス）、およびＪａｖａクラウドサービスを挙げることができる。１つの実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形態でクライアントにサービスとしてのデータベース（Database as a Service）を提供することを可能にする、共有サービスデプロイメントモデルをサポートすることができる。ミドルウェアクラウドサービスは、クライアントがさまざまなビジネスアプリケーションを開発およびデプロイするためのプラットフォームを提供することができ、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいてクライアントがＪａｖａアプリケーションをデプロイするためのプラットフォームを提供することができる。

【0039】

クラウドインフラストラクチャシステムにおいて、ＩａａＳプラットフォームによって、さまざまな異なるインフラストラクチャサービスを提供してもよい。インフラストラクチャサービスは、ストレージ、ネットワークなどの基礎となるコンピューティングリソース、ならびに、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用するクライアントのための他の基本的なコンピューティングリソースの管理および制御を容易にする。

【0040】

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１は、クラウドインフラストラクチャシステムのクライアントにさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース２３０も含み得る。１つの実施形態では、インフラストラクチャリソース２３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するための、サーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの、事前に統合され最適化された組み合わせを含み得る。いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１におけるリソースは、複数のユーザが共有し、要求毎に動的に再割り当てすることができる。さらに、リソースは、異なるタイムゾーンのユーザに割り当ててもよい。たとえば、クラウドインフラストラクチャシステム２３０は、第１のタイムゾーンにいる第１の組のユーザが、指定された時間数だけクラウドインフラストラクチャシステムのリソースを利用することができるようにし、その後、異なるタイムゾーンにいる別の組のユーザに対して同じリソースを再割り当てすることができるようにし、それによってリソースの利用率を最大化することができる。

【0041】

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１の異なるコンポーネントまたはモジュールによって共有されるとともに、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスによって共有される、複数の内部共有サービス２３２を提供することができる。これらの内部共有サービスとしては、限定されないが、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを挙げることができる。いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的な管理を提供することができる。１つの実施形態では、クラウド管理機能は、クラウドインフラストラクチャシステム１３０－１によって受信されたクライアントのサブスクリプションをプロビジョニング、管理、および追跡する機能などを含み得る。

【0042】

いくつかの実施形態では、図に示すように、クラウド管理機能は、オーダー管理モジュール２２０、オーダーオーケストレーションモジュール２２２、オーダープロビジョニングモジュール２２４、オーダー管理および監視モジュール２２６、ならびにアイデンティティ管理モジュール２２８などの１つまたは複数のモジュールによって提供することができる。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または他の任意の適切な配置および／もしくは組み合わせであり得る、１つまたは複数のコンピュータおよび／もしくはサーバを含むか、またはそれらを使用して提供することができる。

【0043】

例示的な動作２３４において、クライアントデバイス２０４、２０６、または２０８などのクライアントデバイスを使用するクライアントは、クラウドインフラストラクチャシステム１３０－１によって提供される１つまたは複数のサービスを要求し、クラウドインフラストラクチャシステム１３０－１によって提供される１つまたは複数のサービスのサブスクリプションのオーダーを行うことによって、クラウドインフラストラクチャシステム１３０－１とインタラクトすることができる。いくつかの実施形態では、クライアントは、クラウドユーザインターフェース（ＵＩ）、クラウドＵＩ２１２、クラウドＵＩ２１４、および／またはクラウドＵＩ２１６にアクセスし、これらのＵＩを介してサブスクリプションのオーダーを行うことができる。クライアントがオーダーを行うことに応じてクラウドインフラストラクチャシステム１３０－１が受信するオーダー情報は、クライアントを識別する情報と、クライアントがサブスクライブする予定のクラウドインフラストラクチャシステム１３０－１によって提供される１つまたは複数のサービスとを含み得る。

【0044】

クライアントによってオーダーが行われた後、オーダー情報は、クラウドＵＩ２１２、２１４、および／または２１６を介して受信される。動作２３６において、オーダーは、オーダーデータベース２１８に格納される。オーダーデータベース２１８は、クラウドインフラストラクチャシステム２１８によって運用され、他のシステム要素とともに運用されるいくつかのデータベースのうちの１つとすることができる。動作２３８において、オーダー情報は、オーダー管理モジュール２２０に転送される。場合によっては、オーダー管理モジュール２２０は、オーダーを確認し、確認後にオーダーを登録するなど、オーダーに関連する課金および会計機能を実行するように構成してもよい。

【0045】

動作２４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール２２２に伝達される。オーダーオーケストレーションモジュール２２２は、オーダー情報を利用して、クライアントによって発注されたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションすることができる。場合によっては、オーダーオーケストレーションモジュール２２２は、リソースのプロビジョニングをオーケストレーションして、オーダープロビジョニングモジュール２２４のサービスを使用するサブスクライブされたサービスをサポートしてもよい。

【0046】

いくつかの実施形態では、オーダーオーケストレーションモジュール２２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、オーダーがプロビジョニングに進むべきか否かを判定する。動作２４２において、新規のサブスクリプションに対するオーダーを受けると、オーダーオーケストレーションモジュール２２２は、サブスクリプションオーダーを遂行するために必要なリソースを割り当てて構成することを求める要求を、オーダープロビジョニングモジュール２２４に送る。オーダープロビジョニングモジュール２２４は、クライアントがオーダーしたサービスのためのリソースの割り当てを可能にする。オーダープロビジョニングモジュール２２４は、クラウドインフラストラクチャシステム１３０－１によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的な実装層との間の抽象化レベルを提供する。したがって、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または予めプロビジョニングされ、要求時にのみ割り付け／割り当てられるか否かなどの実施態様の詳細から、オーダーオーケストレーションモジュール２２２を隔離することができる。

【0047】

動作２４４において、サービスおよびリソースがプロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム１３０－１のオーダープロビジョニングモジュール２２４によって、クライアントデバイス２０４、２０６、および／または２０８のクライアントに送信することができる。動作２４６において、クライアントのサブスクリプションオーダーは、オーダー管理および監視モジュール２２６によって管理および追跡することができる。場合によっては、オーダー管理および監視モジュール２２６は、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムの稼働時間およびシステムのダウンタイムの量など、サブスクリプションオーダーにおけるサービスの使用統計を収集するように構成してもよい。

【0048】

いくつかの実施形態では、クラウドインフラストラクチャシステム１３０－１は、アイデンティティ管理モジュール２２８を含み得る。アイデンティティ管理モジュール２２８は、クラウドインフラストラクチャシステム１３０－１におけるアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成することができる。いくつかの実施形態では、アイデンティティ管理モジュール２２８は、クラウドインフラストラクチャシステム１３０－１によって提供されるサービスの利用を希望するクライアントに関する情報を管理することができる。このような情報は、そのようなクライアントのアイデンティティを認証する情報と、それらのクライアントが、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に関していずれの動作を行うことが許可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール２２８は、各クライアントに関する記述情報、およびその記述情報を誰がどのようにアクセスし、変更することができるかに関する記述情報の管理も含み得る。

【0049】

図３は、本発明のさまざまな実施形態を実装することができる、例示的なコンピュータシステム１３０を示す。システム１３０は、本明細書に記載するコンピュータシステムのうちの任意のものを実装するために使用することができる。図に示すように、コンピュータシステム１３０は、バスサブシステム３０２を介して複数の周辺サブシステムと通信する処理ユニット３０４を含む。これらの周辺サブシステムは、処理加速ユニット３０６、Ｉ／Ｏサブシステム３０８、ストレージサブシステム３１８、および通信サブシステム３２４を含み得る。ストレージサブシステム３１８は、有形のコンピュータ可読記憶媒体３２２とシステムメモリ３１０とを含む。

【0050】

バスサブシステム３０２は、コンピュータシステム１３０のさまざまなコンポーネントおよびサブシステムに、意図されたように互いに通信させるための機構を提供する。バスサブシステム３０２は、単一のバスとして概略的に示されているが、バスサブシステムの代替実施形態は、複数のバスを利用してもよい。バスサブシステム３０２は、さまざまなバスアーキテクチャのうちの任意のものを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のうちの任意のものであってもよい。たとえば、そのようなアーキテクチャとしては、業界標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バス、マイクロチャネルアーキテクチャ（ＭＣＡ：Micro Channel Architecture）バス、拡張ＩＳＡ（ＥＩＳＡ:Enhanced ISA）バス、ビデオエレクトロニクス規格協会（ＶＥＳＡ：Video Electronics Standards Association）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に準拠して製造されたメザニン（Mezzanine）バスとして実装することができるペリフェラルコンポーネントインターコネクト（ＰＣＩ：Peripheral Component Interconnect）バスを挙げることができる。

【0051】

１つまたは複数の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実装することができる処理ユニット３０４は、コンピュータシステム１３０の動作を制御する。処理ユニット３０４に、１つまたは複数のプロセッサを含めることができる。これらのプロセッサは、シングルコアプロセッサまたはマルチコアプロセッサを含み得る。いくつかの実施形態では、処理ユニット３０４は、各処理ユニットに含まれるシングルコアまたはマルチコアプロセッサを有する１つまたは複数の独立した処理ユニット３３２および／または３３４として実装することができる。他の実施形態では、処理ユニット３０４は、２つのデュアルコアプロセッサを単一のチップに統合することによって形成されるクアッドコア処理ユニットとして実装してもよい。

【0052】

さまざまな実施形態において、処理ユニット３０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、複数の同時に実行しているプログラムまたはプロセスを維持することができる。任意の所与の時点で、実行すべきプログラムコードの一部またはすべてが、プロセッサ３０４および／またはストレージサブシステム３１８に存在する場合がある。好適なプログラミングを通して、プロセッサ３０４は、上述したさまざまな機能を提供することができる。コンピュータシステム１３０は、さらに、処理加速ユニット３０６を含むことができ、この処理加速ユニット３０６は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサなどを含み得る。いくつかの実施形態では、処理加速ユニット３０６は、コンピュータシステムの機能を向上させるために、本明細書に開示するような加速エンジンを含むか、またはそのような加速エンジンとともに機能することができる。

【0053】

Ｉ／Ｏサブシステム３０８は、ユーザインターフェース入力デバイスおよびユーザインターフェース出力デバイスを含み得る。ユーザインターフェース入力デバイスは、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、データベース、キーパッド、音声コマンド認識システムを有する音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含み得る。ユーザインターフェース入力デバイスは、たとえば、ジェスチャおよび発話コマンドを使用するナチュラルユーザインターフェースを通して、ユーザが、Microsoft Xbox（登録商標）３６０ゲームコントローラなどの入力デバイスを制御し、それとインタラクトするのを可能にする、Microsoft Kinect（登録商標）モーションセンサなどのモーションセンシングおよび／またはジェスチャ認識デバイスを含み得る。ユーザインターフェース入力デバイスは、ユーザから目の活動（たとえば、写真撮影中および／またはメニュー選択中の「まばたき」）を検出し、目のジェスチャを入力デバイス（たとえば、Google Glass（登録商標））への入力として変換する、Google Glass（登録商標）まばたき検出器などのアイジェスチャ認識デバイスも含み得る。さらに、ユーザインターフェース入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）と対話するのを可能にする音声認識センシングデバイスを含んでもよい。

【0054】

ユーザインターフェース入力デバイスはまた、限定されないが、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルビデオカメラ、ポータブルメディアプレーヤ、ウェブカメラなどのオーディオ／ビジュアルデバイス、イメージスキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザ測距装置、ならびに視線追跡デバイスを含んでもよい。さらに、ユーザインターフェース入力デバイスは、たとえば、コンピュータ断層撮影装置、磁気共鳴画像装置、陽電子放出断層撮影装置、医療用超音波検査装置などの医療用画像入力装置を含んでもよい。ユーザインターフェース入力デバイスはまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力装置を含んでもよい。

【0055】

ユーザインターフェース出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するようなフラットパネル装置、投影装置、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という用語の使用は、コンピュータシステム１３０からユーザまたは他のコンピュータに情報を出力するためのすべてのあり得るタイプのデバイスおよび機構を含むように意図されている。たとえば、ユーザインターフェース出力デバイスは、限定されないが、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車用ナビゲーションシステム、プロッタ、音声出力デバイス、およびモデムなど、テキスト、グラフィック、およびオーディオ／ビデオ情報を視覚的に伝えるさまざまな表示デバイスを含み得る。

【0056】

コンピュータシステム１３０は、現在システムメモリ３１０内に位置しているように示されているソフトウェア要素を含む、ストレージサブシステム３１８を含み得る。システムメモリ３１０は、処理ユニット３０４にロード可能であり処理ユニット３０４で実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納することができる。コンピュータシステム１３０の構成およびタイプに応じて、システムメモリ３１０は、揮発性（ランダムアクセスメモリ（ＲＡＭ）など）および／または不揮発性（リードオンリメモリ（ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは、典型的には、処理ユニット３０４が即座にアクセス可能でありかつ／または現在操作し実行している、データおよび／またはプログラムモジュールを含む。いくつかの実施態様では、システムメモリ３１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。いくつかの実施態様では、ＲＯＭには、典型的には、起動中などでコンピュータシステム１３０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ）を格納することができる。限定ではなく例として、システムメモリ３１０はまた、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得るアプリケーションプログラム３１２と、プログラムデータ３１４と、オペレーティングシステム３１６とを示す。例として、オペレーティングシステム３１６は、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはＬｉｎｕｘオペレーティングシステム、種々の市販のＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステム（限定されないが、種々のＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Google Chrome（登録商標）OSなどを含む）、および／またはｉＯＳ、Windows（登録商標）Phone、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ ＯＳ、およびＰａｌｍ（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

【0057】

ストレージサブシステム３１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構成を格納するための、有形のコンピュータ可読記憶媒体も提供することができる。ストレージサブシステム３１８には、プロセッサによって実行されると上述した機能を提供するソフトウェア（プログラム、コードモジュール、命令）を格納することができる。これらのソフトウェアモジュールまたは命令は、処理ユニット３０４が実行することができる。ストレージサブシステム３１８は、本発明に応じて使用されるデータを格納するためのリポジトリも提供することができる。

【0058】

ストレージサブシステム１３０は、コンピュータ可読記憶媒体３２２にさらに接続することができるコンピュータ可読記憶媒体リーダ３２０も含み得る。システムメモリ３１０とともに、任意選択的に組み合わせて、コンピュータ可読記憶媒体３２２は、コンピュータ可読情報を一時的にかつ／またはより恒久的に格納し、記憶し、送信し、取得するための、リモート、ローカル、固定、および／またはリムーバブル記憶デバイスに記憶媒体を加えて、包括的に表すことができる。

【0059】

コード、またはコードの一部を含むコンピュータ可読記憶媒体３２２は、限定されないが、情報の格納および／または伝送のための任意の方法または技術で実装される、揮発性および不揮発性、リムーバルおよび非リムーバブル媒体などの記憶媒体および通信媒体を含む、本技術分野において既知であるかまたは使用されている任意の適切な媒体も含み得る。これは、ＲＡＭ、ＲＯＭ、電子的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または他の有形のコンピュータ可読媒体などの有形のコンピュータ可読記憶媒体を含み得る。これは、所望の情報を伝送するために使用することができ、コンピューティングシステム１３０がアクセスすることができる、データ信号、データ伝送、または他の任意の媒体などの、非有形のコンピュータ可読媒体も含み得る。

【0060】

例として、コンピュータ可読記憶媒体３２２は、非リムーバブル不揮発性磁気媒体から読み出すかまたは非リムーバブル不揮発性磁気媒体に書き込むハードディスクドライブ、リムーバブル不揮発性磁気ディスクから読み出すかまたはリムーバブル不揮発性磁気ディスクに書き込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、およびＢｌｕ－Ｒａｙ（登録商標）ディスク、または他の光学媒体などのリムーバブル不揮発性光ディスクから読み出すかまたはリムーバブル不揮発性光ディスクに書き込む光ディスクドライブを含み得る。コンピュータ可読記憶媒体３２２としては、限定されないが、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどが挙げられる。コンピュータ可読記憶媒体３２２としては、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤなどの揮発性メモリに基づくＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも挙げることができる。ディスクドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータシステム１３０のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージを提供することができる。

【0061】

通信サブシステム３２４は、他のコンピュータシステムおよびネットワークへのインターフェースを提供する。通信サブシステム３２４は、コンピュータシステム１３０からデータを受信し、コンピュータシステム１３０から他のシステムにデータを送信するためのインターフェースとして機能する。たとえば、通信サブシステム３２４は、コンピュータシステム１３０がインターネットを介して１つまたは複数のデバイスに接続するのを可能にすることができる。いくつかの実施形態では、通信サブシステム３２４は、（たとえば、携帯電話技術、３Ｇ、４Ｇ、５ＧもしくはＥＤＧＥ（enhanced data rates for global evolution）などの高度データネットワーク技術、Ｗｉ－Ｆｉ（ＩＥＥＥ ８０２．１１ファミリ規格、または他のモバイル通信技術、またはそれらの任意の組み合わせ）を使用する）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバコンポーネント、全地球測位システム（ＧＰＳ）受信機コンポーネント、および／または他のコンポーネントを含み得る。いくつかの実施形態では、通信サブシステム３２４は、無線インターフェースに加えてまたはその代わりに、有線ネットワーク接続性（たとえば、Ｅｔｈｅｒｎｅｔ）を提供することができる。

【0062】

いくつかの実施形態では、通信サブシステム３２４は、コンピュータシステム１３０を使用することができる１人または複数のユーザに代わって、構造化および／または非構造化データフィード３２６、イベントストリーム３２８、イベントアップデート３３０などの形態の入力通信を受け取ることもできる。例として、通信サブシステム３２４は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデート、リッチサイトサマリー（ＲＳＳ：Rich Site Summary）フィードなどのウェブフィード、および／もしくは１つまたは複数のサードパーティ情報源からのリアルタイムアップデートなど、ソーシャルネットワークならびに／または他の通信サービスのユーザからデータフィード３２６をリアルタイムで受信するように構成してもよい。

【0063】

さらに、通信サブシステム３２４は、明確な終わりがない本質的に連続的なまたは無限である可能性がある、リアルタイムイベントのイベントストリーム３２８および／またはイベントアップデート３３０を含み得る、連続データストリームの形態のデータを受け取るように構成することもできる。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融ティッカー、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを挙げることができる。通信サブシステム３２４は、構造化および／または非構造化データフィード３２６、イベントストリーム３２８、イベントアップデート３３０などを、コンピュータシステム１３０に連結された１つまたは複数のストリーミングデータソースコンピュータと通信することができる１つまたは複数のデータベースに出力するように構成することもできる。

【0064】

コンピュータシステム１３０は、ハンドヘルドポータブルデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、Google Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または他の任意のデータ処理システムを含む、さまざまなタイプのうちの１つとすることができる。コンピュータおよびネットワークの性質は常に変化するため、図に示すコンピュータシステム１３０の説明は、単に具体的な一例として意図されている。図に示すシステムよりも多いかまたは少ないコンポーネントを有する他の多くの構成が可能である。たとえば、カスタマイズされたハードウェアを使用してもよく、かつ／または、特定の要素を、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実装してもよい。さらに、ネットワーク入出力デバイスなどの他のコンピューティングデバイスへの接続を採用してもよい。本明細書で提供する開示および教示に基づいて、当業者であれば、さまざまな実施形態を実装するための他の様式および／または方法を理解するであろう。

【0065】

本明細書に記載するさまざまな方法は、コンピュータシステム１３０などのコンピュータシステムによって実装することができる。これらの方法の各ステップは、コンピュータシステム１３０が自動的に実行してもよい。さまざまな実施形態において、いくつかのステップは、ユーザが関与する入出力で提供してもよい。たとえば、ユーザは、方法の各ステップに対して入力を提供してもよく、これらの入力の各々は、そのような入力を要求する特定の出力に応じたものであってもよく、そこで、出力は、コンピュータシステム１３０によって生成される。さらに、入力は、ユーザから受け取り、データストリームとして別のコンピュータシステムから受け取り、メモリロケーションから取得し、ネットワークを介して取得し、ウェブサービスから要求するなどであってもよい。同様に、出力は、ユーザに提供し、データストリームとして別のコンピュータシステムに提供し、メモリロケーションに保存し、ネットワークを介して送信し、ウェブサービスに提供するなどであってもよい。さらに、本明細書に記載する方法の各々のいくつかの実施形態は、有形のソフトウェア製品を形成するために、有形の非一時的記憶媒体に格納された命令のセットとして実装してもよい。

【0066】

ほぼすべてのソフトウェアベースのシステムと同様に、データベースシステムは、新たなコンピューティング技術を利用するために、定期的なアップグレードを受けることが必要となることが多い。マイグレーションプロセスでは、１つまたは複数の古いデータベースシステムが、新たなデータベースシステムにマイグレーションされることがある。ソフトウェアまたはハードウェアが旧式化したため、または、新しいデータベースシステムによって提供される利点が、効率、コストの節約または他の利点を提供する可能性があるため、マイグレーションが必要となる場合がある。本開示の実施形態では、マイグレーションによって、データベースを維持しながら、既存のハードウェアのアップグレードを可能にし、かつ／またはレガシーデータベースサーバマシンのオペレーティングシステムを変更することができる。例として、既存のデータベースを、レガシーハードウェアから新たなデータベースマシン（たとえば、Exadata Database Machine）に移行することができる。

【0067】

ソースデータベースは、データベースインストールを指す場合があり、データベースインストールを格納して含む１つまたは複数のコンピュータシステムのグループ化に対応する場合がある。ソースデータベースは、取得、アップデート、および他の形態のデータベースクエリを遂行することができる。マイグレーションは、１つまたは複数のソースデータベース内のオブジェクトを１つまたは複数のターゲットデータベースに移動またはコピーすることを指す場合がある。したがって、マイグレーションの前は、データベースインストールは、ソースデータベースでのみ利用可能である可能性がある。マイグレーションに続き、データベースインストールは、ターゲットデータベースに存在し、場合によっては、ソースデータベースにも依然として存在する場合がある。ターゲットデータベースは、マイグレーションの後にデータベースインストールを格納する１つまたは複数のコンピュータシステムのグループ化を指す場合がある。そのため、ターゲットデータベースは、データベースインストールを含み、マイグレーションに続く、取得、アップデート、および他の形式のデータベースクエリを遂行することができる。

【0068】

図４は、本開示の実施形態に応じた、マイグレーション環境４００のいくつかの態様の概略ブロック図を示す。マイグレーション環境４００は、少なくとも部分的に、分散システム１００およびシステム環境２００に対応することができる。マイグレーション環境４００は、適応的マイグレーションインフラストラクチャ１３０であり得るか、または他の方法で適応的マイグレーションインフラストラクチャ１３０に対応することができる、システム１３０を含み得る。（本明細書では「適応的マイグレーションシステム」または「マイグレーションシステム」として参照する場合もある）適応的マイグレーションインフラストラクチャ１３０は、１つまたは複数のサーバ１１２および／または１つまたは複数のコンピュータシステム３００を含むことができ、いくつかの実施形態ではクラウドインフラストラクチャシステム２０２に対応することができる。

【0069】

クライアントＩＴインフラストラクチャが、１つまたは複数のソースシステム４０４（たとえば、データベースシステム）と１つまたは複数のターゲットシステム４０８（たとえば、データベースシステム）とを収容することができる。比較的大規模な企業の場合、クライアントＩＴインフラストラクチャは、地理的に複数の場所に分散している場合がある。比較的小規模なクライアントの場合、クライアントＩＴインフラストラクチャは、単一の施設に位置する場合がある。場合によっては、たとえば、ターゲットシステム４０８は、ソースシステム４０４と同じ部屋に存在することもある。

【0070】

いくつかの実施形態では、ターゲットシステム４０８は、リモートに位置する場合がある。いくつかの実施形態では、ターゲットシステム４０８は、クラウドストレージ設備が運用してもよい。この種のマイグレーションは、ターゲットシステム４０８の運用および保守の責任からクライアントを解放することができる。いくつかの実施形態では、ターゲットシステム４０８は、クラウドマイグレーションサービスを提供する同じエンティティと同じ場所に配置されるか、または同じエンティティによって共通して運用される場合がある。たとえば、ターゲットシステム４０８は、いくつかの実施形態において、クラウドサービスの、たとえばクラウドインフラストラクチャシステム２０２のリモート運用センターと統合してもよい。

【0071】

適応的マイグレーションインフラストラクチャ４０２は、ソースシステム４０４およびターゲットシステム４０８からリモートに位置する場合があり、ソースシステム４０４およびターゲットシステム４０８は、互いに遠隔に位置していてもいなくてもよいことが理解されよう。本明細書で使用する場合の「リモートに位置する」という用語は、地理的に遠いかまたは地理的に移動したことを意味するものと理解されよう。互いにリモートに位置するエンティティは、通常、互いに何マイルも離れた別個の施設に位置する。たとえば、互いにリモートに位置するエンティティは、少なくとも５マイル、１０マイル、１５マイル、１００マイルなどの距離だけ離れている場合がある。

【0072】

マイグレーションインフラストラクチャ４０２は、１つまたは複数のマイグレーション制御サーバシステム１００－１および１つまたは複数の自動化移行スイートデータベース１１４を含むことができ、可能な限り高度に自動化された方法で１つまたは複数のソースシステム４０４から１つまたは複数のターゲットシステム４０８へのマイグレーションを促進するように設計された自動化移行スイートを提供するように構成することができる。マイグレーションインフラストラクチャ４０２は、オンプレミスクラウド、パブリッククラウド、自律データベースなど、ターゲットシステム４０８のさまざまなターゲットへのマイグレーションのためのさまざまなマイグレーション方法をサポートする集中型構造に対応することができる。さらに、マイグレーションインフラストラクチャ４０２は、１つまたは複数のソースシステム４０４のコンポーネントを１つまたは複数のターゲットシステム４０８にマイグレーションする（たとえば、データベース、アプリケーションなどをマイグレーションする）ために、２つ以上の異なるマイグレーション配置方法を動的に切り替えるのを可能にすることができる。マイグレーションインフラストラクチャ４０２は、単一の手法にバンドルされたマイグレーションを実行するための多くの自動化されたサービスを提供するように構成することができる。さらに、マイグレーションインフラストラクチャ４０２は、１つまたは複数のソースシステム４０４から１つまたは複数のターゲットシステム４０８へのマイグレーションのための特定のマイグレーションシナリオのマイグレーション特性に応じて、１つまたは複数のサービスの最も適切なセットを動的に特定するように構成することができる。そうする際、マイグレーションインフラストラクチャ４０２は、特定のマイグレーションに最適な１つまたは複数の方法のセットを選択するように構成することができ、その選択は、本明細書に開示する複数の変数／要素に応じている。

【0073】

従来のマイグレーションとは逆に、マイグレーションインフラストラクチャ４０２によって促進されるマイグレーションでは、技術者は、ソースシステム４０８に接続し、それを構成し、必要なソフトウェアをインストールして、アクティベーションキーを取得することなどは必要とされない。自動化移行スイートを、集中型ホスト、たとえばいくつかの実施形態では仮想マシン上で、実行することができる。マシンは、１つまたは複数の制御サーバシステム１００－１に対応し得る。制御サーバシステム１００－１は、マイグレーションプロセスを開始し、制御することができる。ソースシステム４０４およびターゲットシステム４０８へのアクセスには、セキュア接続（たとえば、セキュアシェル（ＳＳＨ：Secure Shell）接続など）および／またはデータベース内のデータベースリンクを使用することができる。データトランスポートは、データベース間通信に依拠することができ、基礎となるオペレーティングシステムおよびストレージプラットフォームから完全に独立し得る。マイグレーションインフラストラクチャ４０２のネットワークインターフェースは、ＡＰＩを使用してソースシステム４０４および／もしくはターゲットシステム４０８に通信を送信しかつ／またはソースシステム４０４および／もしくはターゲットシステム４０８から通信を受信するための、１つまたは複数のＡＰＩインターフェースを含み得る。１つまたは複数のＡＰＩインターフェースは、ＡＰＩインターフェースを介してソースシステム４０４および／またはターゲットシステム４０８とインターフェースするためのプロトコルおよびルーチンを定義する１つまたは複数のＡＰＩを含み得る。ＡＰＩは、ソースシステム４０４および／またはターゲットシステム４０８との間のＡＰＩコールを指定し得る。さまざまな実施形態において、マイグレーションインフラストラクチャ４０２とソースシステム４０４および／またはターゲットシステム４０８との間の通信を容易にするために、セキュアシェル（ＳＳＨ：Secure Shell）および／または他の任意の好適なプロトコルを使用することができる。いくつかの実施形態では、システムデータを収集するために、マイグレーションインフラストラクチャ４０２は、１つまたは複数のスクリプトを実行し、１つまたは複数のデータベースを選択し、１つまたは複数のデータベースへの１つまたは複数の通信パイプを確立し、たとえばＩＰアドレスおよびＳＳＨによるトランスポート層を介するコマンドラインアクセスのために１つまたは複数のデータベースにログインし、１つまたは複数のデータベースからシステムデータを引き出すことができる。

【0074】

ソースシステム４０４およびターゲットシステム４０８におけるすべての手動ステップを排除することができる。このアーキテクチャにより、何百以上ものシステムをマイグレーションプロジェクトに含めることを可能にすることができ、単一のアプリケーションからすべてのマイグレーションを制御することを可能にする。制御サーバシステム１００－１の各サーバは、４、１０、２０、またはそれ以上の並列マイグレーションのためのすべてのプロセスを実行するのに十分なハードウェアリソースを有し得る。自動化移行スイートは、各マイグレーションで作成されたすべてのスクリプトおよびログファイルを、ファイルシステム上に及び自動送信スイートデータベース１１４に保存することができる。

【0075】

マイグレーションセットアップは、マイグレーションインフラストラクチャ４０２にソースシステムを最初に登録することと、ファイルからソースアクセス定義をロードし、すべてのシステムに対して定義を自動的に生成することによって、少なくとも部分的にマイグレーションインフラストラクチャ４０２によるアクセスのためにソースアクセス（たとえば、ソースＯＳアクセス）を構成することと、データベース分析を実行するために収集および／または分析エージェントをソースシステム４０４にデプロイすることと、システムにリモートアクセスするために必要なデータベースリンクおよびデータベースリンク情報を構成することと、構成されたソースシステム４０４に関する詳細情報を取得するためにソースシステム分析を実行することによってソースシステム４０４を分析することとを含み得る。開示する実施形態は、すべてのファイルをコピーし、エクスポートおよびインポートを行い、ユーザ権限を構成し、ソースシステムアクセスを構成するなどのために半日かかるのとは対照的に、数分間しかかからないように、セットアップの速度を向上させることができる。いくつかの実施形態では、ＣＳＶファイルを使用することができ、ＳＱＬパッケージをロードし、ディレクトリ、ファイルシステムを作成するなどのためにソースシステム４０４にログオンしなければならない代わりに、ファイルから情報をロードし、すべてをリモートで実行するために、インフラストラクチャ４０２によって提供される中央インスタンスにログインすることができる。ソースシステム４０４へのアクセスは、ソースシステム４０４の手動構成をスキップするために、データベースリンクを通じて提供され得る。このようなプロセス、たとえば、分析エージェントのデプロイ、および分析の実行を、バックグラウンドで実行することができる。これにより、他の活動を阻止し、妨害し、または他の方法で中断させることなく、多数のシステムをシームレスにテストすることを可能にする。

【0076】

マイグレーションインフラストラクチャ４０２は、任意の必要な権限（たとえば、任意のディクショナリの選択、制限されたセッション、接続、カタログロールの選択、データベースシステム管理者での実行などの権限）がエージェントに付与された後、分析を実行するために、ソースデータベース４０４上にエージェントを自動的にインストールすることができる。ソースシステム４０４に接続するためにデータベースを構成することは、マイグレーションパッケージをロードすることと、マイグレーションインフラストラクチャ４０２によってマイグレーションパッケージを実行することとを含み得る。その後、データベースリンクを通してリモートで分析を実行することができる。スイートは、データベースリンクを自動的に作成することができる。そうするために、ＴＮＳ構成は必要ではない場合があり、データベースリンクは、接続文字列（たとえば、ホスト名：ポート／ＳＩＤ）を使用して、ソースシステム４０４およびターゲットシステム４０８に接続する場合がある。クライアントは、ＴＮＳ固有のポートを使用するインバウンド接続がソースシステムに許可されるようにファイアウォールを構成することができる。特定のホストからの接続のみが構成される場合、ソースシステム４０４および／またはターゲットシステム４０８上でリスナー構成を更新してもよい。データベースリンク構成は、入力ファイルを使用して、ソースシステム４０４および／またはターゲットシステム４０８へのマッピングを容易にするように、ソースシステム４０４構成および／またはターゲットシステム４０８構成のホスト名およびデータベース名の組み合わせに対応するホスト名およびデータベース名の構文を有するデータベースリンク定義をロードするようにロードできる。ソースシステム４０４および／またはターゲットシステム４０８の分析により、データベースリンク構成についての検証の合格に進むことができる。

【0077】

クラウドサポートサービスの要素のうちの１つは、ネットワーク２１０上で通信モジュールを使用するセキュア接続を介してマイグレーションインフラストラクチャ４０２と通信するゲートウェイであり得る。マイグレーションインフラストラクチャ４０２およびそれによって利用可能なサービスとインターフェースするために、ＩＴインフラストラクチャは、マイグレーションインフラストラクチャ４０２によって提供され、ソースシステム４０４に関してローカルに動作する、ゲートウェイを含み得る。ゲートウェイ内の専用モジュールとして、エンタープライズマネージャを実装することができる。ゲートウェイは、ソースシステム４０４にアクセスすることができ、ソースシステム４０４に関する統計および情報を適応的マイグレーションインフラストラクチャ４０２に提供することができる、モジュールを含み得る。ゲートウェイは、クライアントデータセンターにインストールされたハードウェアおよび／または仮想ソフトウェアアプライアンスを含み得る。

【0078】

ゲートウェイは、ソースシステム４０４から、ターゲットシステム４０８にマイグレーションすべきデータオブジェクト、ソース／ターゲット情報、およびオペレーティングシステム構成に関する情報を含む情報を収集することができ、そのような情報をターゲットシステム４０８および／または適応的マイグレーションインフラストラクチャ４０２の両方に送信することができる。サポートゲートウェイは、ソースシステム４０４および／またはターゲットシステム４０８に関連するパフォーマンス情報および構成データを収集することができ、次いで、適応的マイグレーションインフラストラクチャ４０２は、そのパフォーマンス情報を使用してマイグレーション分析を実行し、マイグレーションスクリプトを生成し、クライアントＩＴインフラストラクチャ用にカスタマイズされたマイグレーション計画を生成し、次いで、マイグレーション計画を実行して、ソースシステム４０４をターゲットシステム４０８にマイグレーションすることができる。

【0079】

いくつかの実施形態では、マイグレーションおよびデータ分析は、クライアントシステムの統合された部分としてインストールされたゲートウェイによって実行することができる。ゲートウェイは、マイグレーションプロセスを管理および報告するために、本明細書に開示するマイグレーションインフラストラクチャ４０２およびポータルと通信することができる。開示する実施形態は、エンタープライズマネージャを利用して、一貫してかつ／または定期的に、データベースシステム４０４および／または４０８を監視およびモデリングすることができる。顧客のデータベースに関連するモデリングデータを収集および監視するために、エンタープライズマネージャエージェントを採用することができる。さらに、ソースシステムおよび／またはターゲットシステムに照会し、ソースシステムおよび／またはターゲットシステムを分析する、ＥＭプラグインまたはカスタムコレクタなどの顧客構成を使用することができる。この情報は、クライアントシステムに存在するゲートウェイを介して、マイグレーションインフラストラクチャ４０２のサービスにアップロードされ得る。次いで、マイグレーションインフラストラクチャ４０２のサービスは、特定のマイグレーションシナリオのためのデータを提供するために、エージェントによって記録されたデータに対して計算および分析を実行することができる。

【0080】

マイグレーションインフラストラクチャ４０２は、サービス提供を可能にするために、１つまたは複数のクライアントサイトへの／１つまたは複数のクライアントサイトからのアクセスを与えるゲートウェイが利用可能であるか否かを判定することができる。ゲートウェイが利用可能である場合、マイグレーションインフラストラクチャ４０２は、ゲートウェイの構成を検査して、ゲートウェイがエージェントを含んで適切に構成されていることを確実にすることができ、マイグレーションインフラストラクチャ４０２は必要に応じてゲートウェイおよびエージェントを構成する。ゲートウェイが利用可能でない場合、ゲートウェイはインストールのためにダウンロードされ得る。ゲートウェイは、クライアントサイトにインストールされ得て、サービスのワークフローを設定するために自動検出を使用してエージェントおよびプラグインとともに構成され得る。エージェントは、プリフライト段階で特定されたすべての関連するホストにデプロイされ得る。エージェントは、さまざまな実施形態において、ソースシステム４０４、ターゲットシステム４０８、および／またはマイグレーションインフラストラクチャ４０２に関して本明細書に開示する機能を実行するように構成されたボット、リスナー、プラグイン、および／または同様のソフトウェアコンポーネント／モジュールに対応し得る。

【0081】

とりわけ、本開示によるさまざまな実施形態は、複雑なクラウドインフラストラクチャへのシステム作業負荷の配置を容易にすることができる。システム作業負荷は、高度なリレーショナルデータベース管理システム（ＲＤＢＭＳ）アーキテクチャからのデータベース作業負荷を含む、アプリケーション作業負荷およびクラウド作業負荷を含み得る。さまざまな実施形態は、きめの細かい監視情報、および高可用性（ＨＡ）を可能にするクラスタ化されたOracleデータベースなどの高度なアーキテクチャを考慮する、データベース作業負荷をプロビジョニングするための新たなビンパッキング／作業負荷配置アルゴリズムを提供することができる。いくつかの実施形態において、本明細書に開示するシステム、方法、および非一時的媒体は、特定のクラウドに依存せず、クラウドベンダに一様であってもよく、かつ／または、ソースおよびターゲットがある限り、クラウド構成とは無関係に、リモート、オンプレミスなど、任意のアーキテクチャまたは構成で実装してもよい。

【0082】

さまざまな実施形態は、少なくとも部分的に、ビンパッキングアルゴリズムを利用することによって、データベース作業負荷の配置を容易にすることができ、このビンパッキングアルゴリズムは、上述した課題および問題に対処することができ、作業負荷がプラガブルデータベース構成からであるか、クラスタ化データベース構成からであるか、またはスタンバイデータベース構成からであるかに関わりなく、任意の次元の任意のベクトル（複数のメトリック）を正確に配置することができる。さまざまな実施形態は、ビンパッキングアルゴリズムの拡張機能を含むことができ、それは、クラスタリングなどの高度な計算アーキテクチャからの作業負荷、または季節性、傾向、および／またはショック（外因性またはその他）など、信号に複雑なデータパターンを示す作業負荷を扱うときに、必要とされ得る。これらの拡張機能は、作業負荷を統合する場合、たとえば、複数のデータベースを１つ（プラガブルデータベース）に統合して資産におけるデータベースサーバスプロールを低減させる場合に、特に必要となる可能性がある。クラスタ化された環境のためのビンパッキングを含む開示する実施形態により、さまざまな実施形態は、時間要素を導入する新たなアルゴリズムを利用するようにさらに構成され、作業負荷が合わせて統合されるときに要求されるリソースのより豊富なシステム認識を与え、高度なデータベース構成から得られる作業負荷の高可用性（ＨＡ）を保証する。開示する実施形態は、オンデマンドクラウドアーキテクチャにおけるプロビジョニングの無駄のリスクを低減させることができる。

【0083】

さらに、開示する実施形態は、以下のような利点を提供することができる。すなわち、最大可用性アーキテクチャから高可用性を低下させることなく、クラスタ化された作業負荷を配置すること、手動での技術者によるスプレッドシート手法を排除するか、またはそのような手法に必要な時間を数日間／数週間から数分間／数時間に短縮するハイエンド自動化、ＳＰＥＣＩｎｔ、Ｄｉｓｋ ＩＯなどのベンチマークを計算する際の人為的ミスを低減させること、配置されているビンパッキング作業負荷の中央リポジトリに格納することができる格納可能な計画／設計仕様を生成すること、実施形態が任意のベクトルに対して機能することができ、ＲＤＢＭＳと同様にアプリケーションに対しても使用することができるという点で、再帰的であること、スケーラブルであり、複数のメトリックに対してビンパッキングすることができるベクトル、ユーザ入力によるテンプレートとして機能することなどである。さらに、開示する実施形態は、クラスタ化された作業負荷を処理し得て、配置が割り当てられると、新たに作成された信号を再評価し、クラウドリソースのエラスティック化の必要性があるか否かを特定することができる。本明細書でさらに開示するように、さまざまな実施形態は、ＣＰＵ、メモリ、およびＩＯなどのメトリックからデータを追跡し、次いで、メトリックのｍａｘ＿ｖａｌｕｅ（最大値）を取得してベクトルを構築することができる、ソフトウェアアルゴリズムを採用することができる。さまざまな実施形態は、ベクトルがクラスタの一部であることを特定し、その後、クラスタのすべての兄弟を配置することができる。クラスタをターゲットクラウド環境に離散的に配置することができない場合、以前に配置されたいかなる兄弟作業負荷もロールバックすることができる。

【0084】

図５は、本開示による開示する実施形態に応じた、システム１３０が提供することができるさまざまな構成および作業負荷複雑性の例を示す。例に示すように、開示する実施形態に応じてリソースのベクトルを消費することができる、多くのタイプのデータベース構成がある。システム１３０によってサービスが提供される組織は、スタンバイデータベースを有する単一インスタンス構成５０５を含み得る構成の折衷的なセット５００を有する。各作業負荷は、スタンバイを含むベクトルを有する可能性があり、それは、スタンバイが、依然としてリソースを消費しており、通常、よりＩＯ利用率が高いためである。組織は、スタンバイを有するＲＡＣ構成５１０の手法に移行する傾向があり、クラスタ内の各インスタンスはリソースを消費することになる。ここで重要なことは、クラスタが不均一に動作するということである。したがって、ある作業負荷はクラスタ内の他の作業負荷よりも多くのリソースを消費することになる。ここで、プラガブル構成５１５により、コンテナデータベース内で作業負荷を分離および統合することができるが、１つの共通することは、個々のプラガブルデータベースが各々作業負荷を有するように、コンテナが作業負荷を有するということである。構成に関わらず、作業負荷はすべてベクトルを有し、クラウドに移行するかまたはすでにクラウドにある場合、いずれのベクトルがどこにあるのかを理解することが重要である。システムは種々のメトリックに対して影響を受けやすい可能性があるため（たとえば、ＣＰＵよりもＩＯを多用する可能性があるものがあるなど）、メトリックを追加することでベクトルも増大する可能性がある。

【0085】

要件を満足させるためにＩ．Ｔ．（情報技術）システムを採用する場合、そのタイプ、組み合わせ、または構成に関わらず、１つのことが常に共通しており、それは、マイグレーションの前であっても、リプラットフォーム、アップグレード、またはインストールのいずれの前であっても、消費量という課題である。一定期間にわたっていずれのリソースが必要であるかを理解することは、すべてのＩＴシステムの管理にとって重要である。たとえば、ハードウェアの仕様がパフォーマンスおよびキャパシティにおいて向上するに従い、実際の物理的なインフラストラクチャは減少するが、仮想化の採用により、サーバスプロールという課題は、間違いなく同じままである。システム分離のトレードオフは、作業負荷が結合されるかまたは同じインフラストラクチャを共有する必要がある真の統合と相反する。作業負荷の最適な適合法を知ることは課題であり、それは、常に解決すべき重要な課題であった。コンピューティングでは、ビンパッキングを使用して、より小さい作業負荷をより大きいインフラストラクチャ内に配置して、設定された数のタスクにリソースをいかに割り当てるべきかを確立することができる。しかしながら、ビンパッキングは、配置された作業負荷をクラスタ化しエラスティックにすることなど、高度なシステムアーキテクチャを扱う場合には、さらなる制約を必要とする。

【0086】

解決すべき課題は多面的である。配置の課題を分析すると、これらの面は相互に関連しており、すなわち、課題のすべての部分は、単なる個々の要素ではなく、ともに対処する必要があることが明らかになる。クラスタは、図６に示すように、通常、高可用性を提供するために、１つのシステムとして作用するように参加して、合わせて管理されるサーバ（ノードとしても知られる）のグループである。図６は、本開示によって開示される実施形態に応じた、１つのシステムとして作用するように参加して、合わせて管理されるクラスタ６００を示す。これらのクラスタ６００は、機能停止が発生するかまたはメンテナンスが必要になった場合に、別のサーバが引き継ぐのを可能にすることによって、ダウンタイムおよび機能停止を低減させることができる。データベースクラスタリングは、共有ストレージ、たとえば、ＳＡＮ（ストレージエリアネットワーク）、ＮＡＳ（ネットワークアタッチトストレージ）、ディスクアレイ、またはブロック、ファイル、もしくはオブジェクトストレージなどのクラウドストレージ機能に格納されているデータベースデータファイルにアクセスしながら、複数のサーバにわたってデータベース６０５を実行することである。図６において、ユーザは、任意のウェブサーバ６１０に対して、ＨＲ、販売、コールセンターのアプリケーションへのアクセスを要求することができる。技術スタックのネットサービス層は、クライアントアクセスを処理することができ、サービスが実行しているノードにユーザ接続を向けることができる（たとえば、販売はノード２から実行するように向けられる）。ノード間のハートビートにより、クラスタの整合性を確保することができ、ノードのうちの１つが反応しなくなるかまたはハートビートを生成しなくなった場合、サービスはフェイルオーバーし、ユーザ接続は残りのノードによって処理される。このタイプのアーキテクチャは、２４時間３６５日のＳＬＡを容易にすることができる。

【0087】

再び図５を参照すると、作業負荷は、ユーザによってサブミットされたタスクのコレクションを含み得る。いくつかの例では、作業負荷は、データベース、アプリケーション、またはさらには１つのコードである場合がある。タスクは、たとえばオンライントランザクション処理（ＯＬＴＰ）システムによって、ウェブアプリケーションにサービスを提供する、挿入、更新、および削除を実行するデータ修正言語（ＤＭＬ：Data Modification Language）ステートメントなどの小さい作業単位または個々のＳＱＬであってもよい。他の作業負荷には、定期的にデータベース内の情報を集約するバッチジョブ、たとえば、データウェアハウスにおける一般的な特徴である（たとえば、ＯＬＡＰ）、時間毎の販売データの日次、週次、または月次への集約など、より大きい作業単位が含まれる場合がある。別のタイプの作業負荷は、ＯＬＴＰとＯＬＡＰとの中間あたりと言うことができる、データマートである。データマートは、中程度のＯＬＡＰタイプの集約と、より小さいＤＭＬ ＯＬＴＰ作業単位の組み合わせで構成することができる。データマートは、月または年ではなく日および週の集約である、販売、ＨＲ、またはコールセンターなどのサブジェクト指向である大規模データウェアハウスのサブセットであり得る。これらの作業単位は、消費されるリソースの量が異なる場合があり、時系列フォーマットで分析すると、タスクを満足させるために消費されるリソースの消費がいつ行われるかは、タスクによって決まることが多い。これらのタスクがトレースを介して分析されるとき、システム１３０は、それらのリソース消費において異なるパターンを示すタスクを特定することができる。たとえば、図７は、本開示によって開示される実施形態に応じた、複雑なデータ構造を有するＣＰＵ使用率７００の態様を示す。図７では、ＣＰＵの４つの作業負荷が並んでいる。最初のタスク７０５、ＯＬＴＰは、微妙な繰り返しパターン（たとえば、季節性）を有する漸進的な傾向を示す。次の２つのタスク７１０、７１５は、それぞれＯＬＡＰおよびデータマートであり、ほとんど傾向のない繰り返しタスクのより決定的なパターンを示す。

【0088】

図８は、システム１３０の開示する実施形態によって対処されるＲＡＣ構成５１０の作業負荷８００の複雑性の態様例を示す。作業負荷８００を配置するとき、各時間間隔で各ノード上の各データベースインスタンスから各メトリックのピーク値を抽出し、それらをターゲットノードに配置することによって、各作業負荷８００を個別に処理することができる。これは、作業負荷８００が単数である（互いに独立し、単一ノード上で実行する）限り、十分に単純であり得る。作業負荷８００がクラスタ化されている場合、配置を開始するときに、ＨＡを損なうことなく作業負荷８００の配置を行わなければならないため、より複雑になる。したがって、１つのクラスタ化された作業負荷８００を配置するためには、クラスタ内のすべての作業負荷８００を配置しなければならない。クラスタ化された作業負荷８００が兄弟作業負荷なしで配置される場合、クラスタ化された作業負荷８００が単一作業負荷に低減するリスクがあり、その結果、高可用性が失われ、したがってＳＬＡが損なわれる。同じ理解が、データベースが単数のデータベースインスタンスから切り離され、別のクラスタ化されたデータベースインスタンスにプラグインされる可能性がある、プラガブルデータベースにも必要とされる。

【0089】

従来の技術の課題の一例として、ＲＡＣ構成５１０の作業負荷８００は、各ソースノードに分散される可能性がある。図８で示されるように、ＲＡＣ構成５１０の作業負荷８００は、十分なノードがない限り、同じターゲットノードに配置することができず、そのため、すべての作業負荷８００が離散的に配置される。従来の技術の課題の１つの例では、４つの作業負荷８００をクラウド内の３つのターゲットノード８０５に配置することができない。他のビンパッキングアルゴリズム（すなわち、本明細書で開示するもの以外）は、いずれも、作業負荷８００を配置するときに、この難問を解決することができない。すべての作業負荷８００を離散的に配置することができない場合、配置はロールバックされる可能性があり、配置する必要がある他の作業負荷８００にリソースが利用可能になり得る。ＯＣＩでは、３つのターゲットノード８０５を構成および構築することができるが、クラスタ内に４つの兄弟があるため、４つは３つに入らないために、ＭＡＡは機能することができない。ＲＡＣ構成５１０の作業負荷８００は、複数のノード８０５（ＭＡＡ）にわたって共有される場合がある。いくつかのノードが機能を実行するために分離されている場合にＱｏＳが採用される。したがって、各データベースインスタンスと消費されるリソースとが考慮されるべきである。この理由は、ノード８０５に障害が発生した場合に、いくつかのアプリケーションが他のアプリケーションよりもノードについての優先権が与えられるという、サービス品質があり得るからである。

【0090】

統合とは、いくつかの作業負荷をノードの共有コレクション上で実行することであると説明することができる。サーバ、クラスタ、データベース、または作業負荷の数のいずれであるかに関わらず、システムの簡素化またはサーバスプロールの削減など、統合にはいくつかの推進要因がある。サーバスプロールとは、サーバがフル稼働まで使用されておらず、スペース、電力、および冷却の面で著しい無駄が生じることになり、最終的に組織に多大なコストがかかることになる状況として説明することができる。データベースの統合は、単一またはクラスタ化されたコンテナＤＢＭＳ（インスタンスを構成するメモリ構造）からデータベースを切り離し、すでに複数のデータベースがプラグインされている別のコンテナＤＢＭＳにプラグインすることができる、プラガブルデータベースの開発によって容易になった。プラガブルデータベースを切り離し接続することによって、プラガブルデータベース（およびそれに関連するデータファイル）を別のサーバに移し、別のデータベースインスタンス（ＤＢＭＳ）によって管理されるようにすることができる。

【0091】

これを図９に示し、ＨＡとともに機能しているときに抽象化のさらなる層を追加する。図９は、本開示によって開示される実施形態に応じた、マルチテナントアーキテクチャ９００を有するプラガブルデータベース９０５の態様を示す。クラスタ内の各ノード８０５はクラスタ化されたコンテナも収容しており、各クラスタ化コンテナ内にはプラガブルデータベース９０５がある。このアーキテクチャ９００は、１つのデータベースインスタンスがＨＡを達成しながら複数のプラグインデータベース９０５にサービスを提供することができる場合に、１つのデータベースにサービスを提供するデータベースインスタンスのサポートオーバーヘッドを除去する。しかしながら、配置の実行にとりかかるときに、どこでリソースが消費されるかを理解することは困難になる。簡素化の目的のために、プラガブルデータベース９０５は同じデータベースインスタンスで処理することができるが、プラガブルデータベース９０５をそれ自体のエンティティとして分離し、それ自体が作業負荷を所有するものとして処理することができない理由はない。

【0092】

システム１３０によって解決される課題の一部は、以下のように考えることができる。いくつかはクラスタ化されている作業負荷８００のコレクションと、計算ノード８０５のコレクションとを想定する。各作業負荷８００は、いくつかのメトリックを使用して定義されたリソースに対する時間的に変化する需要を有し、各サーバは、同じメトリックを使用して定義されたキャパシティを有する。タスクは、クラスタ化された作業負荷８００によって課される制約を尊重しながら、作業負荷８００によって課される要求が常にノード８０５のキャパシティ内に収まるように、作業負荷８００をノード８０５に割り当てることである。従来のビンパッキングアルゴリズムでは、個々のサーバに割り当てられたアプリケーションの多様なタイプを考慮していない。

【0093】

クラウドコンピューティングでは、ユーザが任意のシェイプのリソース（ベクトル）に任意の場所からアクセスすることができ、依然として最適化されていることが要求されるため、無駄を削減することを目的とした最適なリソース使用の必要性がいっそう明らかになっている。図１０に示すように、ベクトルは、１つの単一のメトリックではなく、シェイプを構成する複数のメトリック（たとえば、ＩＯＰＳ、メモリ利用率、ＣＰＵ利用率など）を定義することができる。各作業負荷は、１つまたは複数のベクトルによって定義することができる。クラスタ化された環境におけるビンパッキング手法を使用したベクトル配置に関しては、同じクラスタ上で実行しているいくつか作業負荷がフルであるか、またはそれらのアルゴリズムを終了させる可能性のある分類の組み合わせである可能性がある。優先度が異なる作業負荷がクラスタ内のｘノードから実行する可能性がある、クラスタ化された作業負荷では、ＳＬＡの強制が必要であった。ベクトルビンパッキングにより、作業負荷の合計が任意の所与の時点でビンの合計を超えないことを確実にすることができる。図示する例では、空のターゲットにともに配置すべき３つのベクトル（ベクトル１、２、３）がある。ベクトル１および２がともに配置される場合、ビンの合計を超えるため適合しないが、それはベクトル１および３には当てはまらない。ベクトルは、経時的な作業負荷のピークおよびトラフを考慮するためにシステム１３０が使用することができる複数のメトリックに対応することができる。システム１３０は、作業負荷の将来の使用率を予測することができ、作業負荷が統合されると無駄を特定することができる。ベクトルは、動的であってもよく、より多くのメトリックを追加することによってそのサイズを増大させることができる。

【0094】

基本的なビンパッキングの課題は、体積の異なる物品を、使用されるビンの数を最小化する方法で有限数のビン（箱）に詰め込むプロセスである。実際には、近似、特に発見的アルゴリズムが使用されることが多い。ビンパッキングには、First-Fit Decreasing（ＦＦＤ）、Next-Fit（ＮＦ）、Best-Fit（ＢＦ）など多くの手法がある。First Fit Decreasingを考慮すると、プロビジョニングされているすべての作業負荷は、等しい優先度を持つものとして扱われる可能性がある。エラスティックリソースプロビジョニング（ＥＲＰ：Elastic Resource Provisioning）は、すべての作業負荷を１つのビンに割り当て、配置されている作業負荷の周囲に適合するようにビンをエラスティックにすることである。さまざまな実施形態により、ＦＦＤを改善して、クラスタ化された作業負荷などの複雑なアーキテクチャに取り組み、それらを実験的に経験的に評価することができる。

【0095】

First Fit Decreasing配置（ＦＦＤ）
本明細書においてビンパッキングを説明するために使用する表記法を、表１に列挙し、図１１および図１２に示す。図１０は、本開示によって開示される実施形態に応じた、ノードリソースキャパシティ１０００の態様を示す。図１２は、本開示によって開示される実施形態に応じた、作業負荷リソース需要１２００の態様を示す。利用可能なリソースは、ノードのセットとして表すことができ、ノードの各々は、ＣＰＵ、メモリ使用率、論理入出力操作毎秒などを含み得るメトリックのセットを使用して定義されたキャパシティを有する。ビンパッキングタスクは、ノードに作業負荷のセットを割り当てることであり得る。各作業負荷に関連する需要は、ノードを説明するために使用するものと同じメトリックに関して定義することができるが、需要は、一連の時間にわたって変化する場合がある。時間的に変化する需要は、たとえば、キャパシティ計画のためにデータベース作業負荷をモデリングする時系列分析技術を使用する、測定または予測された負荷に基づく場合がある。

【0096】

【表1】

【0097】

作業負荷のソート
First fid decreasingは、作業負荷が最大のものから先に割り当てることができるように、作業負荷をソートすることができ、したがって、大きさの概念が必要である。ここでは、順序は、各メトリックについての総使用率に従って正規化する、異なるメトリックにわたる需要の項目に関して定義され得る。各メトリック（ＣＰＵ、ＩＯＰＳ、メモリ、ストレージ）についての全体的な需要は、各作業負荷の需要から以下のように得ることができる。

【0098】

【数1】

【0099】

次に、作業負荷ｗの正規化された需要は、すべてのメトリックにわたるその需要の正規化された合計であり得る。

【0100】

【数2】

【0101】

次に、作業負荷を、それらの正規化された需要によってソートすることができる。実際には、クラスタ化された作業負荷を割り当てる場合、クラスタは、それらの最も需要の高い作業負荷の需要の順に考慮することができ、その後、クラスタ内の作業負荷も局所的にソートすることができる。

【0102】

ノードキャパシティ
時間ｔにおけるメトリックｍについてのノードｉのキャパシティは、ノードの元のキャパシティからノードに割り当てられた作業負荷のリソース使用率を差し引いたものとすることができる。

【0103】

【数3】

【0104】

適合
常にすべてのメトリックについてのキャパシティがある場合、作業負荷ｗをノードｎに追加することができる。

【0105】

ｆｉｔｓ（ｗ，ｎ）＝∀ｍ∈Ｍｅｔｒｉｃｓ∀ｔ∈Ｔｉｍｅｓ
Ｄｅｍａｎｄ（ｗ，ｍ，ｔ）≦ｎｏｄｅ＿ｃａｐａｃｉｔｙ（ｎ，ｍ，ｔ） （４）
表１からのクラスタ化された作業負荷ｉｓＣｌｕｓｔｅｒｅｄは、図６に示すように、互いに兄弟であるデータベースインスタンス（作業負荷）であり得る。ノードは、Ｗ_ｉが実行されるべきノードの数である場合があり、ｗ∈ＣｌｕｓｔｅｒｅｄＷｏｒｋｌｏａｄは、ターゲットノードに離散的に割り当てられる必要がある作業負荷のセットであり得る。クラスタがパッキングされたと言われる前に、すべてのＳｉｂｌｉｎｇｓを離散的なターゲットノードにパッキングしなければならないルールが強制される可能性がある。任意の時点で、Ｓｉｂｌｉｎｇｓのうちの１つを離散的なターゲットノードにパッキングしそこなった場合、すべての兄弟がロールバックされる可能性があり、リソースがｎｏｄｅ＿ｃａｐａｃｉｔｙに解放される可能性がある。

【0106】

ＦＦＤおよび本明細書で開示する定義に基づく技術を使用して、システム１３０は、クラスタ化されたワークフローをサポートするターゲットクラウドインフラストラクチャ（たとえば、Oracle Cloud Infrastructure（ＯＣＩ））にデータベース作業負荷を配置することができる。システム１３０は、金銭的な（従量課金制）コストおよびリソースをクラウドプールに戻して他の場所で利用するためのコストの両方の削減を達成することができる。

【0107】

作業負荷配置アルゴリズム
アルゴリズム１に概要説明を示す。クラスタ化された構成を採用しているコンピューティング資産における作業負荷の配置の主な課題の１つは、クラスタ化されたワークフローを全体として配置しなければならないか、まったく配置してはならないかを考慮することである。作業負荷がクラスタ化されていること、およびノード数を特定することは、作業負荷を目標のクラウド構成に配置するために重要である可能性がある。

【0108】

【表2】

【0109】

最初に、システム１３０は、入力としてキー情報を抽出し、需要によって作業負荷を順序付けることができる。キー構成データは、作業負荷がクラスタ化されているか否かを格納する中央リポジトリに格納することができる。作業負荷がクラスタの一部である場合、システム１３０は、その特定の作業負荷のフラグ（表１においてｉｓＣｌｕｓｔｅｒｅｄで表す）を設定することができ、表１のＳｉｂｌｉｎｇｓを使用して、クラスタ化されている作業負荷のフルセットを取得することができる。

【0110】

作業負荷を配置するとき、作業負荷ｗが単一のデータベースインスタンスからのものである場合、システム１３０は、作業負荷が利用可能なノードに適合する（ｆ ｉｔｓ（式５））か否かを判断し、適合する場合、そのノードのＡｓｓｉｇｎｍｅｎｔに追加する。システム１３０は、（Ａｓｓｉｇｎｍｅｎｔによって）適合されたすべての作業負荷と、（ＮｏｔＡｓｓｉｇｎｅｄによって）適合されなかった作業負荷とを、ユーザに報告することができる。しかしながら、作業負荷がクラスタ化されている場合、システム１３０は、クラスタ内の関連するＳｉｂｌｉｎｇ作業負荷を中央リポジトリから抽出してもよく、それは、Oracle Enterprise ManagerシステムおよびＯＥＭインテリジェントエージェントを使用して、データベースインスタンスに関連するすべてのパフォーマンスおよび構成データを取得することができるためである。ＯＥＭは、作業負荷に関連する情報を保持するためにデータベーススキーマを利用することができる。データベースインスタンスおよびこの情報は、グローバル一意識別子（ＧＵＩＤ：Global Unique Identifier）を介して扱うことができる。

【0111】

クラスタ化された作業負荷の適合
クラスタ化された作業負荷の適合は、作業負荷が適合されたことを報告することができる前に、すべての作業負荷をクラスタに配置することによって、高可用性を強制することを目的とする場合がある。たとえば、図６に記載するように、クラスタ化された作業負荷が３つのノードを有し、各ノード上でデータベースインスタンスが実行している場合、作業負荷を離散的なターゲットノードに配置することができ、または、すでに配置されたものをロールバックする（これは、いくつかの実施形態において、ユーザインターフェースを介した適切な通知を伴う、プロセスフローにおける以前の判定ポイントに戻ることを含み得る）。これをアルゴリズム２に示す。

【0112】

【表3】

【0113】

最初に、システムは、クラスタ（１、２、・・・、Ｎ）ノードを構成するノードの数を判定することができ、これにより、必要なターゲットノードの数が示される。３つのノードからのクラスタ化された作業負荷を２つのターゲットノードに適合させることができない場合、システム１３０は、必要な数のターゲットノードが利用可能であることを確実にするためのテストを実行することができる。十分な数のターゲットノードがない場合、システム１３０は、クラスタの兄弟が離散的なターゲットノードに割り当てられることを保証して、すべての作業負荷をループすることができる。割り当てが行われるたびに、ターゲットノードのリソース量が、作業負荷のベクトルによって減少する可能性がある。最後に、システム１３０は、いかなる作業負荷が各ターゲットノードに割り当てられたかを報告することができる。

【0114】

適合された配置の評価
すべてのデータベースインスタンスからの作業負荷が割り当てられ、それらのターゲットノードに配置されると、各作業負荷を、時間周波数（毎時）で重ね合わせて、作業負荷が統合されたときの既存のデータ信号（ピークおよびトラフ）を理解することができる。時間毎およびメトリック毎の単純なｇｒｏｕｐｂｙ（Σ）により、新たに統合されたデータ信号を示すことができる。従来のビンパッキングの実行では、メトリックのｍａｘ＿ｖａｌｕｅを取ることができ、ビンパッキングは、その値に基づくことができる。しかしながら、ピークが、たとえばパターンがない、単数である場合、オーバープロビジョニングが明らかになる可能性がある。新たなトレースがＸ、Ｙ上に表示される（積み重ねられる）場合、統合された作業負荷は、季節性、傾向、ビンの閾値限界に対するショックなど、それらの複雑な特性を示す可能性がある。この手法は、統合された作業負荷をより緊密に適合させるために、ビンに対して実行することができるさらなるエリシテーションの実行を明らかにし、可能であれば、それを実施するかまたはそれに反映させることができる。

【0115】

さまざまな作業負荷を、ベアメタル構成を有するOracle Cloud Infrastructureなどの複雑なターゲットクラウド構成に適合させることを目的として、クラスタリングおよびプラガブルデータベースなどの高度な技術を採用するデータベースに対して、First-Fit Decreasingアルゴリズムを利用するベクトルビンパッキングを実行するように、さまざまな実施形態を構成することができる。大部分のクラウドプロバイダは、ＩＯＰＳ、ストレージ、ＣＰＵ、およびメモリなど複数の次元でプロビジョニングを行うため、作業負荷をクラウド構成に配置する場合、ベクトル手法が必要となる場合がある。クラウドコンシューマがクラウドプロバイダでもある場合、ベクトルは、数が増加する可能性があり、クラウド技術の他の領域、たとえばほんの数例を挙げればネットワークスループット、ＮＩＣ帯域幅、またはＶＮＩＣ構成をカバーする。

【0116】

作業負荷がアーキテクチャを移行すると、特に時系列形式で分析した場合、その作業負荷に関連するメトリックのｍａｘ＿ｖａｌｕｅの信号が経時的に変化する可能性がある。したがって、パターンまたは傾向が繰り返されているか否かを判定することなく、ある期間にわたるメトリックのｍａｘ＿ｖａｌｕｅが無分別に許容される場合、オーバープロビジョニングの危険性があり得る。最初にプロビジョニングされたものは、作業負荷が配置され、統合され、ターゲットノードから累積信号が取得されると、必ずしも必要でなくなる可能性がある。

【0117】

ビンパッキングは、ビンパッキング技術としてFirst-Fit Decreasing（ＦＦＤ）に焦点を当てたものなど、本明細書のいくつかの例で開示しているが、作業負荷配置機能は、以下のうちの任意のもののうちの１つまたは組み合わせで使用してもよい。ファーストフィット（first-fit）の実施態様は、大きさの降順で項目を順序付けた後、すべてのビンが満杯になるまで、最初のビンから順に進むことができる。ワーストフィット（worst-fit）の実施態様は、最小の負荷を有するビンに焦点を当て、項目を適合させようと試行することができる。項目は、適合することができる場合、配置することができる。そうでない場合、次のビンを、その項目が適合するか否かに関して評価することができる。ベストフィット（best-fit）の実施態様は、開放されている項目およびビンのリストを保持することができる。最大の負荷を有するビンを決定することができる。項目は、配置することができる場合、配置することができる。そうでない場合、新たなビンを開放することができる。ネクストフィット（next-fit）の実施態様は、最大から最小の順に項目を順序付けて、ビンを開放することができる。項目は、適合する場合、配置することができる。そうでない場合、フローは、項目が適合することができるまで、次のビンに移動することができる。項目は、適合することができない場合、配置することができない。改良型ファーストフィット（refined-first-fit）の実施態様は、ビンを大きさに従ってカテゴリに分類することができ、その後、項目を適合させることができる。これは、異なる大きさのビンを評価し、項目を配置することを含み得る。ハーモニック（harmonic）の実施態様は、項目を０、１として順序付けした後、項目を正確な数まで最小数のビンにパッキングすることができる。改良型ハーモニック（refined harmonic）の実施態様は、１／３に基づいて項目をビンに配置することができ、１／２である項目の無駄を低減させるように設計することができる。すなわち、２つの項目は、１／２よりも無駄の少ない２／３でビンに入ることができる。修正ハーモニック（modified harmonic）の実施態様は、改良型ハーモニック手法の派生物であり得る。ハーモニック＋１（harmonic +1）および＋＋（harmonic ++）の実施態様は、修正ハーモニック手法および改良型ハーモニック手法の派生物であり得る。Almost-worst fitの実施態様および他の実施形態も可能である。

【0118】

図１３は、本開示による開示する実施形態に応じた、システム１３０が作業負荷の態様を判定する方法の別の例を示す。３つの異なる作業負荷による、ＣＰＵ利用率対時間のプロット１３００を有するＣＰＵの例を示す。１３０５によって示すように、システム１３０は、信号全体からｍａｘ＿ｖａｌｕｅを取り出すことができ、その値に作業負荷を配置する。さらに、システム１３０は、１３１０によって示すように、無駄をもたらすような繰り返しパターンを検出することができる。１３１５によって示すように、システム１３０は予測を行うことができる。システム１３０は、ｍａｘ＿ｖａｌｕｅの和を求めることができる。したがって、作業負荷は、適合するように見えても、ともに統合され、時点の各々（毎時）が正しく測定されると、適合しない場合がある。他のビンパッキング配置アルゴリズムは、所与の数の観測（たとえば、毎時）のｍａｘ＿ｖａｌｕｅを取得することができるが、そうしたものは、繰り返しパターンではない可能性があり、これは、オーバープロビジョニングの確率が非常に高いことを意味する。

【0119】

図１４は、本開示によって開示される実施形態に応じた、システム１３０が、データの異常を考慮して、統合された時間的作業負荷を分析する方法の一例を示す。システム１３０が作業負荷をより深く分析する場合にのみ、システム１３０は、動的構成が必要であるか否か、またはさらなるエラスティック化が必要であるか否かを理解することができる。ＣＰＵ利用率対時間のプロット１４００を有するＣＰＵの例を示す。１４０５で示すように、利用率がかなり低い３つの作業負荷があり得る。１４１０によって示すように、統合された作業負荷は、３つの作業負荷１４０５をすべて統合することができる。１４１５により、エラスティック化を示す。１４２０によって示すように、システム１３０は、配置アルゴリズムを歪めた、データ内の異常を検出することができる。１４２５によって示すように、システム１３０は、すべての作業負荷が適合するように、ターゲットノードキャパシティを１００ＣＰＵから１４０ＣＰＵに引き上げることができる。１４３０によって示すように、配置アルゴリズムは各作業負荷から最大値のみを取るため、異常は無駄が生じる機会を引き起こしている。したがって、統合ラインとプロビジョンラインとの間にあるものはいずれも、使用されずにプロビジョニングされる。１４３５によって示すように、必要なものは、信号が決定されると、すべての作業負荷の統合信号の周りでエラスティック化することである。

【0120】

システム１３０は、プロビジョンの無駄を削減するためにエラスティック化によってさらなる効率を得ることができるか否かを確認するために、ターゲットビンの合計との比較（ノードはクラウド構成であるか否か）を含む、統合された時系列データ信号の分析を実行することができる。分析は、さらなる効率を達成するために「絞り込む」かまたはエラスティックにすることができるプロビジョニングを特定するために、傾向および季節性のあるＯＬＴＰタイプの作業負荷を考慮することができる。合わせて追加された作業負荷のセットの特定のインスタンスの作業負荷の合計は、ビンの合計を超える場合がある。ビンパッキングアルゴリズムは、配置するために与えられるものに基づいて配置して、ベクトルを配置するとき、直交している（静的に独立している）可能性がある。そのため、システム１３０は、予測（たとえば、将来のキャパシティ計画）を実行し、その後、配置設計を実行することができる。多くの場合、ビンパッキングは最大値に基づいて行われるが、最大値は、短い一過性のスパイク（または、場合によっては、再び発生する可能性が低い同様に少数のスパイク）を伴って、一度だけ発生した可能性がある。プロビジョニングがその一度だけのスパイクによって決定される場合、無駄の可能性が非常に高くなる。そのような無駄の状況は、システム１３０によって検出され、排除される。

【0121】

ＳＬＡを強制するためのレプリケーション（スタンバイデータベース）、分離（プラガブルデータベース）、またはクラスタリングなどの高可用性技術の普及、およびクラスタ化された作業負荷を考慮することができるビンパッキングアルゴリズムがないことを考慮すると、システム１３０は、異なるＦＦＤビンパッキングアルゴリズムを使用するように構成することができる。プラガブルデータベースの導入により、データベースインスタンスを単に１対１のマッピングとしてＶＭにマッピングする以外の異なる手法を、システム１３０によって採用することができる。作業負荷をともに統合することにより、システム１３０が適応することができる追加の複雑性が得られる。たとえば、プラガブルデータベースは、ユーザがある場所から別の場所にデータベースをより容易に切り離し接続することができるようにすることにより、分離およびアジリティを提供する一方で、リソースを消費しているグローバルデータベースメモリ構造に依然として接続することができる。プラガブルを単一のインスタンス作業負荷として扱うことにより、システム１３０のアルゴリズム内の複雑性を低下させることができ、それにより、プラガブルデータベースの配置が可能になる可能性がある。プラガブルデータベースをノードに割り当てることができ、プラガブルデータベースのコレクションをターゲットノードに割り当てることができ、それは、クラスタ化されたプラガブルデータベースを複数のターゲットノードにわたって共有することができるためである。したがって、システム１３０は、ソースデータベースの構成に関わりなく、任意のデータベース作業負荷に起因する単純なベクトル、複雑なベクトル、および非常に複雑なベクトルを配置するという点で多面的であり得る、アルゴリズムを使用するように構成することができる。

【0122】

プラガブルデータベースおよびスタンバイデータベースを単一のインスタンス作業負荷として扱うことにより、システム１３０は、数式にさらなる表記法を導入することなく、作業負荷配置を実行することができる。スタンバイデータベースは、通常、プライマリクラスタ内のすべてのノードからすべてのアーカイブログを適用する、リカバリモードにある可能性がある。したがって、スタンバイは、メモリまたはＣＰＵよりもＩＯリソースを多用する単一インスタンスである可能性がある。

【0123】

中央リポジトリ。システム１３０は、中央リポジトリを提供するように構成することができる。システム１３０は、監視－分析－計画－実行（ＭＡＰＥ：Monitor-Analyze-Plan-Execute）が可能なインテリジェントエージェントをスピンアップおよび使用して、メトリックデータおよび構成データを一元的に特定し、取得し、格納するように構成することができ、これにより、システム１３０は、作業負荷の時系列データを均一に整列させることができる。インテリジェントエージェントは、たとえば、ｓａｒまたはｉｏｓｔａｔなどのコマンドを特定の時点に実行することができ、コマンド結果は、たとえば、１つまたは複数のデータベース１１４とのデータベーススキーマ内の中央リポジトリに格納される。システム１３０は、メトリックデータに対して毎時の値への集計を実行することができ、これは、信号を平滑化する（時点を平均化する）という負の効果を有するが、図１１に示すように、任意の所与の期間における作業負荷の比較をより容易にすることができる可能性がある。図１１は、本開示によって開示される実施形態に応じた、ノードリソースキャパシティ１１００の態様を示す。作業負荷の一元的な分析により、システム１３０は、異なるマシンからの作業負荷のｓａｒおよびｉｏｓｔａｔなどの出力をはるかにより容易に特定することができ、（たとえば、Ｐａｎｄａｓ、ＮｕｍｐｙなどのＰｙｔｈｏｎライブラリによって）アプリケーション層で必要とされるデータラングリングの量を低減させることができる。

【0124】

ベンチマーク。あるＣＰＵモデルを別のＣＰＵモデルと比較することは難題である。システム１３０は、ベンチマークＳＰＥＣＩｎｔ ２０１７を使用して、あるアーキテクチャ上でＣＰＵを消費している作業負荷を、別のチップアーキテクチャ上で実行されている作業負荷と比較することができる。ベンチマークが利用可能でない場合、システム１３０は、上下に最も近いチップモデルからＳＰＥＣＩｎｔｓを選択してもよい。システム１３０は、ＳＰＥＣＩｎｔｓチップベンチマークを中央リポジトリに格納することができ、使用されるＣＰＵの５０％、これはピーク時のＳＰＥＣＩｎｔｓの５０％に等しい可能性がある、の計算を実行することができる。システム１３０はまた、トランザクション処理性能協議会（Transaction Processing Performance Council）のベンチマークに基づくストレージベンチマークを利用することもできる。しかしながら、ＲＤＢＭシステムは、多くの場合データベースのフェッチ動作をバイパスする複雑な記憶アルゴリズムを利用する可能性がある。たとえば、Oracle Exadata技術では、データベースパフォーマンスを支援するために、一般的に要求されるデータをメモリキャッシュにピン留めする場合がある。また、データベースファイルがマウントされたボリュームとして格納され、したがって、論理読み取りがメトリックとして解釈された複雑な技術を利用することもある、ブロック、ファイル、またはオブジェクトストレージなど、ＳＡＮ、ＮＡＳ、またはクラウドストレージ機能に、複雑性が追加される。しかしながら、本明細書に開示するアルゴリズムが、数を増やすことができる（すなわち、スケーラブルである）メトリック（すなわち、ベクトル）への配置を可能にすることを考慮すると、システム１３０が、物理的ＩＯＰＳまたは物理読み取りおよび物理書き込みの組み合わせを使用することができない理由はない。本明細書に開示する実施形態では、追加のメトリックを有するより大きいベクトルへの配置を行うことができる。

【0125】

テンプレート。システム１３０は、ユーザ入力を可能にするテンプレートを使用することができ、そこでは、ユーザは、単一、プラガブル、またはクラスタ化されたデータベースインスタンスのいずれかの作業負荷からのベクトルに割り当てることができるメトリックまたはメトリック群を選択する。これにより、クラウドのすべての面に作業負荷を配置するというクラウドサービスプロバイダのユースケースを容易にすることができる。システムは、ＣＰＵまたはディスクのアーキテクチャと同様に、ネットワーク層にもボトルネックが現れる、無数のパフォーマンスの課題の影響を受けやすい可能性がある。そのため、ユーザおよび／またはシステムが、配置すべきより多くのメトリックを追加することによってベクトルを拡張することができるようにすることが、重要である可能性がある。システムは、ビジネスサイロ内で異なる機能を果たすように求められるため、互いに異なるように挙動する。テンプレートを利用することにより、システム１３０は、アルゴリズムにベクトルを拡張する能力を与えることができる。

【0126】

自動化。作業負荷の配置の実行を手動で実施する手法では、技術者は、作業負荷をクラウドに配置するときにスプレッドシートの手法を採用する傾向がある。この手法は、煩雑である可能性があり、たとえば、ソースアーキテクチャとターゲットアーキテクチャとの間のＣＰＵ（ＳＰＥＣｉｎｔ）、ＩＯ速度、およびメモリを手作業で調査および変換し、スプレッドシートを作成することは、時間がかかる。多くの場合、これらのスプレッドシートは、複雑化し、個々の顧客に特注であり、柔軟性に欠くことになり、その結果、作成者しか理解できない「エキスパートフレンドリーな」分析となる。しかしながら、システム１３０の開示する実施形態は、技術者が手作業でスプレッドシートを構築するのに費やす労力のレベルを低下させ、特注のスプレッドシートで生じる可能性のある計算ミスによるエラーを低減させ、配置計画を完了するまでの時間を数週間／数カ月から数時間／数日間以下に短縮することを目的として、このプロセスを自動化することができる。

【0127】

開示するアルゴリズムを実行するシステム１３０の実施形態は、中央リポジトリから構成データおよびパフォーマンスデータを有効に取得することができる。たとえば、ＣＰＵのメーカー、モデル、およびそのＳＰＥＣＩｎｔ値を手作業で調査するのではなく、インテリジェントエージェントによって取得されるそれらのデータを抽出し、したがって、比較を実施し、そうした手作業での調査はすべて排除される。そして、アルゴリズムを実行する実施形態は、作業負荷の配置設計を、複雑な特注スプレッドシートのセットを有するのではなく、正規化されたデータベーススキーマに「計画」として迅速に配置および格納することができる。これにより、数日または数週間ではなく、数分間以下での配置アルゴリズムの実行を可能にすることができる。

【0128】

したがって、システム１３０は、特に、ＩａａＳ、ＰａａＳ、ＤｂａａＳ、またはＳａａＳなどのサービスをプロビジョニングするときに、それがオンプレミス、リモート、またはハイブリッドクラウドのいずれであっても、正確な作業負荷配置を提供するように構成することができる。しかしながら、クラスタリングなどの高度な作業負荷構成が採用される場合、標準的な手法または既製の手法では問題があるため、使用する配置アルゴリズムのうちの最適なアルゴリズムまたはコレクションのシステム選択が重要である。クラスタリングおよびプラガブルなどの高度なデータベースアーキテクチャにおけるFirst-Fit Decreasingビンパッキング法により、システム１３０の開示する実施形態は、特にクラスタがリソースを不均一に消費している場合に、クラスタ内の兄弟作業負荷に適応するようにＦＦＤアルゴリズムを拡張することができる。クラスタ化された作業負荷を順序付けるときに兄弟を考慮することにより、システム１３０は、作業負荷およびその兄弟を順序付けることができる。これは、リソースを不均一に消費するクラスタ内の兄弟を考慮するためである。クラスタ化されたインスタンス作業負荷が個々に列挙される場合、単純な順序付けの実行が行われると、クラスタ内の１つの作業負荷は、その兄弟と比較してかなり低い順位に位置する可能性がある。最終的に、ターゲットノードは、それらのリソースを使い果たし、配置は停止する。兄弟ノードが配置される前にターゲットノードが利用可能なリソースを使い果たした場合、システム１３０によってロールバックの実行が実施される可能性がある。したがって、クラスタおよびその兄弟に降順で順序付けることが重要である場合がある。システム１３０によって他のプロトコルを採用してもよく、それには、クラスタ毎に消費されるリソースの総量の累積的な手法、およびノードの数、次いで消費されるリソースに基づく順序付けを含めることができる。さらに、ユーザ定義の優先度割り当て機能がシステム１３０によって促進されてもよい。ユーザが定義する優先度を作業負荷に割り当てることにより、いくつかのシステムが他のシステムよりもクリティカルである可能性があるため、ライブシステム間の分離を可能にすることができる。システム１３０は、配置と組み合わせて作業負荷の将来のリソース消費を予測するために、時系列分析と結合された機械学習（教師あり）を活用することができ、これにより、システム１３０が、将来のリソース消費に基づいていずれのシステムを配置することができるかを判定するのをさらに容易にし得る。

【0129】

図１５は、本開示によった開示される実施形態に応じた、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションを促進する方法例１５００を示す。方法１５００は、上記で開示した方法および動作のすべてではないがいくつかの態様を表すものとして理解されるべきである。本開示の教示は、種々の構成で実装することができる。したがって、本明細書に開示する方法１５００および／または他の方法を構成するステップの順序は、任意の好適な方法で入れ替えるかまたは組み合わせてもよく、選択された実施態様によって決まってもよい。さらに、以下のステップは、説明のために分離されている場合があるが、いくつかのステップは、同時にまたは実質的に同時に実行される場合もあることが理解されるべきである。

【0130】

方法１５００は、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションにおいて、１つまたは複数のソースシステムの作業負荷を配置するための、ディスカバリ、キャパシティ計画、モデリング、および決定サービスを含む、システム１３０によって提供されるサービス例を示し得る。方法１５００は、マイグレーションを促進するために、１つまたは複数のターゲットシステムにおける１つまたは複数のソースシステムの作業負荷の配置を計画することを含み得る。方法１５００は、機械学習および人工知能を組み込んで作業負荷をモデリングし、ターゲットシステムにおける作業負荷の配置を計画し、ビンの配置および対応する作業負荷を予測し、かつ／またはクラスタ化された環境をパッキングする配置仕様を作成することができる。

【0131】

ブロック１５０５によって示すように、システム１３０は、ソースディスカバリ動作を実行することができる。ソースディスカバリ動作は、本明細書で開示するように、マイグレーションセットアップ動作、ソースシステム上にデプロイされ、ディスカバリ動作を促進するように構成された収集および／または分析エージェント、ディスカバリ動作を促進するように構成されたゲートウェイなどによって促進することができる。したがって、システム１３０は、第１の数のソースノードに関連するデータを受け取ることができる。ソースディスカバリ動作は、システム１３０がオンプレミス作業負荷の属性をディスカバリすることを含み得る。システム１３０は、１つまたは複数の作業負荷タイプ（たとえば、データベース、ＲＤＢＭＳ、アプリケーション、ＳａａＳなど）を決定することができる。ソースディスカバリ動作は、システム１３０が作業負荷の特徴（たとえば、アーキテクチャ、ＲＡＣ、プラガブルなど）を決定することを含み得る。システム１３０は、ビンパッキングアルゴリズムを使用して、プロビジョニングタスクの効率および精度を向上させることができる。データ収集を実施する際、システム１３０は、自動化されたコレクタ／エージェント（たとえば、ＥＭおよびＡＷＲの抽出、変換、およびロード（ＥＴＬ）など）を使用し、主要なメトリックを収集し、データを安全に伝送することができる。

【0132】

ブロック１５１０によって示すように、システム１３０は、ターゲットディスカバリ動作を実行することができる。ターゲットディスカバリ動作は、マイグレーションセットアップ動作、ソースディスカバリ動作によって収集されたデータの分析、および／または１つまたは複数のソースシステムの要件に関するシステム１３０の決定によって促進することができる。したがって、システム１３０は、第２の数のターゲットノードに関連するデータを受け取ることができる。ターゲットディスカバリ動作は、システム１３０がＯＣＩターゲットビンを決定することを含み得る。システム１３０は、システム１３０が作業負荷を適合させることができる１つまたは複数のビンを特定することができる。

【0133】

ブロック１５１５によって示すように、システム１３０は、機械学習および人工知能を使用して、ソース（すなわち、現行の）作業負荷をターゲットにマイグレーションするためのマッピングおよびモデリングを実行することができる。データ分析を実行する際、システム１３０のプロセスは、スタックに対する各層について自動化することができ、将来のリソース消費を予測するための機械学習を含むことができ、作業負荷がマイグレーションするに従い進捗を追跡するための反復可能なプロセスによる継続的な分析を含み得る。システム１３０は、機械学習を使用して、統合が実行される際にビンおよびビンパッキングを予測することができる。

【0134】

システム１３０は、キャパシティ計画を実行することができる。これを行うために、システム１３０は、機械学習を使用して、オンプレミス作業負荷のリソース消費および作業負荷メトリックを分析し、少なくとも部分的に、分析されたリソース消費に基づいて、将来の使用量の予測を行うことができる。システム１３０は、一定期間にわたる最大値から取得されたリソース（ＣＰＵ、メモリ、ストレージ／ＩＯＰＳ）からなる基本作業負荷を使用することができる。システム１３０は、ビンおよびそのキャパシティの合計を考慮することができる。次いで、システム１３０は、サイズ／要件および／または優先度に基づいて、シェイプを順序付けることができる。新たなランドスケープを設計する際、システム１３０は、サービスの期間中に継続的に更新される自動化されたＵＩを促進することができる。

【0135】

システム１３０は、１つまたは複数のソースの特徴を１つまたは複数のターゲットにマッピングするための特徴マッピング構成を生成してもよい。このような動作は、配置計画の作成を容易にすることができ、または配置計画に含めることができる。システム１３０のマッピング技術は、自動化されたルックアップ、自動化されたマッピング、および正しい作業負荷が正しいターゲット構成で合わせて満足されることを確実にするためのビンパッキングアルゴリズムを含み得る。システム１３０は、ビンパッキングを容易にするためにモデリングを実行してもよい。これは、作業負荷の適合を指定するためのビンパッキング仕様の作成を含み得る。システム１３０は、ＯＣＩにおいて作業負荷を合わせて適合させるための最良のモデルを決定することができる。このような動作は、ソースの特徴をターゲットにマッピングすることを含むか、または少なくとも部分的に、そうしたマッピングに基づいてもよい。したがって、システム１３０は、第１の数のソースノードおよび第２の数のターゲットノードに関連するデータを分析することができ、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を指定するマイグレーション計画を作成することができる。

【0136】

ブロック１５２０によって示すように、システム１３０は、利用可能なシェイプに適用可能なサイズおよび優先度に基づいて、ファーストフィット、最適なフィット、および／またはエラスティック化に従って、シェイプを正しいターゲットビンに適合させることができる。図１６Ａは、本開示によって開示される実施形態に応じた、ファーストフィットによるターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す。図１６Ｂは、最適なフィットによる、ターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す。ビンが十分に大きくない場合、システム１０３は、作業負荷に適応するためにプロビジョニングをエラスティックにすることができる。システム１３０は、優先度、作業負荷の特性、特徴、エラスティック化対プロビジョニングの金銭的報告、最適な適合によって排除された無駄など基づく最適なビンに関する報告を生成することができ、システム１３０は、この報告を、ＵＩを介してかつ／またはネットワーク伝送を介して、１つまたは複数のエンドポイントデバイスに通信することができる。

【0137】

システム１３０は、マイグレーション計画によるマイグレーションを実行することができる。配置は、プラガブル環境またはクラスタ化された環境をパッキングすることを含み得る。作業負荷配置アルゴリズムおよびクラスタ化された作業負荷の適合に関して本明細書に開示するように、システム１３０は、テストを実施することを含み得る作業負荷配置アルゴリズムを利用することができる。プラガブルデータベースは、クラスタ化された環境のような分離度を提供し、本明細書で開示する実施形態は、上記で開示したように、兄弟作業負荷をインスタンスとして扱うため、クラスタ化およびプラガブル複合環境を処理するように構成することができる。システム１３０は、個々の作業負荷に対して最小のプロビジョニングをインテリジェントにプロビジョニングするように構成することができるだけでなく、複数の兄弟がある場合、兄弟作業負荷を合わせて配置するように構成することもできる。これは、最大の作業負荷および一度に１つの作業負荷のみの配置のためにしかプロビジョニングすることができず、その結果、兄弟作業負荷が互いに関連する各兄弟作業負荷間で多くの無駄が生じる、従来の手法に対する改善となることができる。したがって、開示する実施形態は、上記で詳細に開示したように、無駄を削減し、そのような関連する作業負荷を処理することができる。

【0138】

ターゲットノードの数がソースノードの数よりも多い場合、作業負荷はソースノードからターゲットノードに配置することができる。ターゲットノードの数がソースノードの数よりも少ない場合、ソースノードからの作業負荷はターゲットノードに配置されず、１つまたは複数のロールバック動作を実行することができる。これにより、システム１３０は、サービス品質（いくつかのノードに別のノードよりも優先権が与えられる場合がある）およびＳＬＡなどの重要な属性に対するその設計を維持することを確実にすることができる。ＳＬＡは、システム「全体」の比較的重要でない部分にスイッチオフされる可能性があるいくつかのノードに対応することができる。したがって、マイグレーションは、ターゲットノードの数がソースノードの数よりも多い場合に、ソースノードからターゲットノードに作業負荷を配置することを含み得る。

【0139】

さらに、本明細書に開示するように、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへの作業負荷の配置を含むマイグレーション動作は、少なくとも部分的に、作業負荷の配置がベクトルを増大させることができる１つまたは複数の次元に基づくように、スケーラブルであり得る。ベクトルは、１つまたは複数のＩＯメトリック、ＣＰＵメトリック、メモリメトリックなどに対応するメトリックの次元を含むことができ、時間の関数であり得る。システム１３０は、作業負荷に対応する統合された時系列データ信号を取得することができる。システム１３０は、統合された時系列データ信号を分析し、統合された時系列データ信号をターゲットビンの合計と比較して、無駄を削減するためにエラスティック化によってさらなる効率を得ることができるか否かを判定し、そうである場合、システム１３０は、ターゲットビンをエラスティックにすることができる。

【0140】

ブロック１５２５によって示すように、システム１３０は、マイグレーションが継続するに従い、かつマイグレーションの１つまたは複数の部分／段階が完了した後に、強化学習を用いてマイグレーションを継続的に評価することができる。プロセスフローは、たとえば、１５０５に戻って循環してもよい。システム１３０は、少なくとも部分的に、各シェイプが必要とされる時間であるものとして時間の要素を追加することによって、時間的複雑性に適合することができる。作業負荷は、ターゲットにマイグレーションされるに従い、変化する可能性が高く、したがって、システム１３０が、機械強化学習（ＭＲＬ）を含む継続的なモデリング動作を実施して、最良の統合を確実にすることができる。再帰的分析を実施する際、システム１３０は、作業負荷が移動するに従い、強化学習とＡＩおよびＭＬの継続的評価（たとえば、ＭＤＰ）とを利用して、構成の信頼性を確保し、必要に応じてターゲットクラウドを調整することができる。

【0141】

前述の説明では、説明の目的で、本発明のさまざまな実施形態の完全な理解を提供するために、多数の具体的な詳細を記載した。しかしながら、当業者には、本発明の実施形態は、これらの具体的な詳細のうちのいくつかがなくても実施することができることが明らかとなろう。他の場合では、周知の構造およびデバイスは、ブロック図形式で示されている。

【0142】

前述の説明は、単に例示的な実施形態を提供するものであり、本開示の範囲、適用性、または構成を限定するようには意図されていない。むしろ、例示的な実施形態の前述の説明は、例示的な実施形態を実装するための可能な説明を当業者に提供する。添付の特許請求の範囲に示すような本発明の趣旨および範囲から逸脱することなく、要素の機能および配置においてさまざまな変更を行ってよいことが理解されるべきである。

【0143】

具体的な詳細は、前述の説明において、実施形態の徹底的な理解を提供するために与えている。しかしながら、当業者であれば、これらの具体的な詳細なしに実施形態を実施することができることが理解されよう。たとえば、回路、システム、ネットワーク、プロセス、および他の構成要素は、不必要な詳細で実施形態を不明瞭にしないために、ブロック図形式の構成要素として示している場合がある。他の例では、周知の回路、プロセス、アルゴリズム、構造、および技術が、実施形態を不明瞭にすることを避けるために、不必要な詳細なしに示している場合がある。

【0144】

また、個々の実施形態について、フローチャート、フロー図、データフロー図、構造図、またはブロック図として描かれるプロセスとして説明している場合があることに留意されたい。フローチャートは、動作を逐次的なプロセスとして説明している場合があるが、動作の多くは並列にまたは同時に実行することができる。加えて、動作の順序を再配置してもよい。プロセスは、その動作が完了したときに終了するが、図に含まれていない追加のステップを有する可能性もある。プロセスは、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応することができる。プロセスが関数に対応する場合、その終了は、呼び出し元の関数またはメイン関数へのその関数の戻りに対応することができる。

【0145】

「コンピュータ可読媒体」、「（複数の）コンピュータ可読媒体」、「プロセッサ可読媒体」、「（複数の）プロセッサ可読媒体」、「機械可読媒体」、および「（複数の）機械可読媒体」という用語は、限定されないが、命令および／またはデータを格納し、収納し、または搬送することができる携帯型または固定型の記憶デバイス、光記憶デバイス、無線チャネル、および他のさまざまな媒体を含む。コードセグメントまたは機械実行可能命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラムステートメントの任意の組み合わせを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを渡しかつ／または受け取ることによって、別のコードセグメントまたはハードウェア回路に連結することができる。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク伝送などを含む任意の好適な手段を介して、渡し、転送し、または伝送することができる。

【0146】

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせによって実装することができる。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装される場合、必要なタスクを実施するためのプログラムコードまたはコードセグメントは、機械可読媒体に格納することができる。プロセッサが、必要なタスクを実行することができる。

【0147】

前述の明細書では、本発明の態様をその具体的な実施形態を参照して説明したが、当業者であれば、本発明はそれらに限定されないことを認識するであろう。上述した本発明のさまざまな特徴および態様は、個々にまたは共同で使用することができる。さらに、実施形態は、本明細書のより広い趣旨および範囲から逸脱することなく、本明細書に記載したものを超える任意の数の環境および用途において利用することができる。したがって、本明細書および図面は、制限的ではなく例示的なものとみなされるべきである。

【0148】

さらに、例示の目的で、方法を特定の順序で説明した。代替実施形態では、方法は、記載した順序とは異なる順序で実施してもよいことが理解されるべきである。また、上述した方法は、ハードウェアコンポーネントによって実施してもよく、機械実行可能命令のシーケンスに具現化してもよく、この機械実行可能命令は、その命令でプログラムされた汎用もしくは専用プロセッサまたは論理回路などの機械に、そうした方法を実施させるために使用することができる、ということが理解されるべきである。これらの機械実行可能命令は、ＣＤ－ＲＯＭもしくは他のタイプの光ディスク、フロッピー（登録商標）ディスケット、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、フラッシュメモリ、または電子命令を格納するのに好適な他のタイプの機械可読媒体などの１つまたは複数の機械可読媒体に格納することができる。代替的に、本方法は、ハードウェアとソフトウェアとの組み合わせによって実施してもよい。

【0149】

また、特許請求の範囲における用語は、特許権者によって明示的かつ明確に定義されない限り、平易な通常の意味を有する。特許請求の範囲において使用する場合の不定冠詞「ａ」または「ａｎ」は、本明細書において、特定の冠詞が導入する１つまたは複数の要素を意味するものと定義され、その後の定冠詞「ｔｈｅ」の使用は、その意味を否定するように意図されていない。さらに、特許請求の範囲における異なる要素を明確にするための「第１」、「第２」などの序数の用語の使用は、序数の用語が適用されている要素に対して、一連の特定の位置、または他の任意の連続的な文字または順序を付与するように意図されていない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【手続補正書】

【提出日】2024-07-31

【手続補正1】

【補正対象書類名】明細書

【補正対象項目名】００１３

【補正方法】変更

【補正の内容】

【0013】

【図1】本開示により開示される実施形態に応じた、分散システムの簡略図である。

【図2】本開示により開示される実施形態に応じた、システムの１つまたは複数のコンポーネントによって提供されるサービスをクラウドサービスとして提供することができるシステム環境の１つまたは複数のコンポーネントの簡略化されたブロック図である。

【図3】本開示により開示される実施形態に応じた、例示的なコンピュータシステムを示す図である。

【図4】 本開示の実施形態に応じた、マイグレーション環境４００のいくつかの態様 の概略ブロック図である。

【図5】本開示により開示される実施形態に応じた、システムが提供することができるさまざまな構成および作業負荷複雑性の例を示す図である。

【図6】本開示により開示される実施形態に応じた、１つのシステムとして作用するように参加して、合わせて管理されるクラスタを示す図である。

【図7】本開示により開示される実施形態に応じた、ＣＰＵ使用率の態様を示す図である。

【図8】本開示により開示される実施形態に応じた、システムの開示する実施形態によって対処されるＲＡＣ作業負荷の複雑性の態様例を示す図である。

【図9】本開示により開示される実施形態に応じた、マルチテナントアーキテクチャを有するプラガブルデータベースの態様を示す図である。

【図10】本開示により開示される実施形態に応じた、ベクトルの態様を示す図である。

【図11】本開示により開示される実施形態に応じた、ノードリソースキャパシティの態様を示す図である。

【図12】本開示により開示される実施形態に応じた、作業負荷リソース需要の態様を示す図である。

【図13】本開示により開示される実施形態に応じた、システムが作業負荷の態様を判定する方法の別の例を示す図である。

【図14】本開示により開示される実施形態に応じた、システムが、データの異常を考慮して、統合された時間的作業負荷を分析する方法の一例を示す図である。

【図15】本開示により開示される実施形態に応じた、１つまたは複数のソースシステムから１つまたは複数のターゲットシステムへのデータおよび／またはアプリケーションのマイグレーションを促進する方法例を示す図である。

【図16A】本開示により開示される実施形態に応じた、ファーストフィット（first fit）によるターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す図である。

【図16B】本開示により開示される実施形態に応じた、最適なフィット（optimal fit）によるターゲットビンへの作業負荷の統合およびビンパッキング例のいくつかの態様を示す図である。

【国際調査報告】