詳細な説明
以下の説明では、本発明の実施例が十分に理解されるようにするために、説明の目的で具体的詳細を記載する。しかし、これらの具体的詳細がなくてもさまざまな実施例を実施できることは明らかであろう。図面および説明は、限定的であるよう意図されるものではない。
本発明の特定の実施例は、クラウドインフラストラクチャシステムによって提供されるサービスのプロビジョニング、管理および追跡を自動化するための技術を提供する。
特定の実施例では、クラウドインフラストラクチャシステムは、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様で顧客に与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウドである。
クラウドインフラストラクチャシステムは、クラウドインフラストラクチャシステムにおいてサービスおよびリソースについての顧客のサブスクリプションをプロビジョニング、管理および追跡する機能、クラウドインフラストラクチャシステムにおいてサービスを利用する顧客に予測可能な作業費用を提供する機能、クラウドインフラストラクチャシステムにおいて顧客のデータのロバストなアイデンティティドメインの分離および保護を提供する機能、クラウドインフラストラクチャシステムの設計の透過的なアーキテクチャおよび制御を顧客に提供する機能、データ保護の保証とデータプライバシ基準および規制の順守とを顧客に提供する機能、クラウドインフラストラクチャシステムにおいてサービスを構築およびデプロイするための統合された開発経験を顧客に提供する機能、ならびにクラウドインフラストラクチャシステムにおいてビジネスソフトウェア、ミドルウェア、データベースおよびインフラストラクチャサービスの間のシームレスな統合を顧客に提供する機能を含むがこれらに限定されない多くの機能を提供することができる。
特定の実施例では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどの、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用可能な多数のサービスを含み得る。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドインフラストラクチャシステムによって提供されるサービスの具体的なインスタンス化は、本明細書ではサービスインスタンスと称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用可能なサービスはいずれも、クラウドサービスと称される。一般に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なっている。例えば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得て、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。
コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーションまたは他のサービスへの保護されたコンピュータネットワークアクセスを含む。例えば、サービスは、インターネットを介したクラウド上のリモートストレージへの、パスワードによって保護されたアクセスを含んでいてもよい。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含んでいてもよい。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含んでいてもよい。
図1Aは、本発明の一実施例に係るクラウドインフラストラクチャシステムの論理図である。クラウドインフラストラクチャシステム100は、クラウドまたはネットワーク化された環境を介してさまざまなサービスを提供し得る。これらのサービスは、ソフトウェア・アズ・ア・サービス(Software as a Service:SaaS)カテゴリ、プラットフォーム・アズ・ア・サービス(Platform as a Service:PaaS)カテゴリ、インフラストラクチャ・アズ・ア・サービス(Infrastructure as a Service:IaaS)カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される1つ以上のサービスを含んでいてもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスをオーダーし得る。次いで、クラウドインフラストラクチャシステム100は、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。
クラウドインフラストラクチャシステム100は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。例えば、サービスは、クラウドインフラストラクチャシステム100が(例えばオラクルによって所有される)クラウドサービスを販売する組織によって所有され、サービスが一般的な公営企業またはさまざまな産業企業が利用可能であるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム100が単一の組織のために単独で運営され、当該組織内の1つ以上のエンティティにサービスを提供することができるプライベートクラウドモデルの下で提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム100およびシステム100によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。また、クラウドサービスは、2つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。
図1Aに示されるように、クラウドインフラストラクチャシステム100は、クラウドインフラストラクチャシステム100によって提供されるサービスのプロビジョニングを可能にする、連携して動作する複数のコンポーネントを備えていてもよい。図1Aに示される実施例では、クラウドインフラストラクチャシステム100は、SaaSプラットフォーム102と、PaaSプラットフォーム104と、IaaSプラットフォーム110と、インフラストラクチャリソース106と、クラウド管理機能108とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
SaaSプラットフォーム102は、SaaSカテゴリに入るクラウドサービスを提供するように構成される。例えば、SaaSプラットフォーム102は、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給するための機能を提供し得る。SaaSプラットフォーム102は、SaaSサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。SaaSプラットフォーム102によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム100上で実行されるアプリケーションを利用することができる。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。
さまざまな異なるSaaSサービスが提供され得る。例としては、大きな組織に販売実績管理、企業統合およびビジネスの柔軟性などのためのソリューションを提供するサービスが挙げられるが、これに限定されるものではない。一実施例では、SaaSサービスは、顧客関係管理(Customer Relationship Management:CRM)サービス110(例えばオラクルクラウドによって提供されるフュージョンCRMサービス)、人材管理(Human Capital Management:HCM)/才能管理サービス112などを含んでいてもよい。CRMサービス110は、顧客への販売活動サイクルの報告および管理に向けられるサービスなどを含んでいてもよい。HCM/才能サービス112は、顧客へのグローバルな労働力ライフサイクル管理および才能管理サービスの提供に向けられるサービスを含んでいてもよい。
標準化された、共有の、弾性的にスケーラブルなアプリケーション開発およびデプロイメントプラットフォームにおけるPaaSプラットフォーム104によって、さまざまな異なるPaaSサービスが提供され得る。PaaSサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを(オラクルなどの)組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する機能が挙げられ得るが、これらに限定されるものではない。PaaSプラットフォーム104は、PaaSサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。顧客は、顧客が別個のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム100によって提供されるPaaSサービスを取得することができる。PaaSサービスの例としては、オラクルJava(登録商標)クラウドサービス(Java Cloud Service:JCS)、オラクルデータベースクラウドサービス(Oracle Database Cloud Service:DBCS)などが挙げられるが、これらに限定されるものではない。
PaaSプラットフォーム104によって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム100によってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施例では、クラウドインフラストラクチャシステム100によって提供されるPaaSサービスは、データベースクラウドサービス114と、ミドルウェアクラウドサービス(例えばオラクルフュージョンミドルウェアサービス)116と、Javaクラウドサービス117とを含んでいてもよい。一実施例では、データベースクラウドサービス114は、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートし得て、ミドルウェアクラウドサービス116は、さまざまなビジネスアプリケーションを開発およびデプロイするために顧客にプラットフォームを提供し、Javaクラウドサービス117は、クラウドインフラストラクチャシステム100においてJavaアプリケーションをデプロイするために顧客にプラットフォームを提供する。図1Aに示されるSaaSプラットフォーム102およびPaaSプラットフォーム104におけるコンポーネントは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例では、SaaSプラットフォーム102およびPaaSプラットフォーム104は、クラウドインフラストラクチャシステム100の顧客に追加のサービスを提供するための追加のコンポーネントを含んでいてもよい。
IaaSプラットフォーム110によってさまざまな異なるIaaSサービスが提供され得る。IaaSサービスは、SaaSプラットフォームおよびPaaSプラットフォームによって提供されるサービスを利用する顧客のために、ストレージ、ネットワークおよび他の基礎的な演算リソースなどの基本的な演算リソースの管理および制御を容易にする。
特定の実施例では、クラウドインフラストラクチャシステム100は、クラウドインフラストラクチャシステム100の顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース106を含む。一実施例では、インフラストラクチャリソース106は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め統合された、最適化された組み合わせを含む。
特定の実施例では、クラウド管理機能108は、クラウドインフラストラクチャシステム100においてクラウドサービス(例えばSaaS、PaaS、IaaSサービス)の包括的な管理を提供する。一実施例では、クラウド管理機能108は、クラウドインフラストラクチャシステム100によって受取られた顧客のサブスクリプションをプロビジョニング、管理および追跡するための機能などを含む。
図1Bは、本発明の実施例に係るクラウドインフラストラクチャシステム100を実現するために使用され得るハードウェア/ソフトウェアスタックの簡略ブロック図である。図1Bに示される実現例は、図1Bに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図1Bに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム100は、図1Bに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。特定の実施例では、最適な性能を提供する垂直統合を提供するようにハードウェアおよびソフトウェアコンポーネントが積層される。
さまざまなタイプのユーザがクラウドインフラストラクチャシステム100と対話し得る。これらのユーザは、例えば、デスクトップ、モバイル機器、タブレットなどのさまざまなクライアント装置を使用してクラウドインフラストラクチャシステム100と対話し得るエンドユーザ150を含んでいてもよい。また、ユーザは、さまざまな統合された開発環境(integrated development environment:IDE)を介して、および他のアプリケーションを介して、コマンドラインインターフェース(command line interface:CLI)、アプリケーションプログラミングインターフェース(application programming interface:API)を使用してクラウドインフラストラクチャシステム100と対話し得る開発者/プログラマ152を含んでいてもよい。また、ユーザは、オペレーションスタッフ154を含んでいてもよい。これらは、クラウドサービスプロバイダのスタッフまたは他のユーザのスタッフを含んでいてもよい。
アプリケーションサービス層156は、クラウドインフラストラクチャシステム100によって提供され得るさまざまなクラウドサービスを特定する。これらのサービスは、サービス統合および連結層158を介してそれぞれのソフトウェアコンポーネント160(例えばJavaサービスを提供するためのオラクルウェブロジックサーバ、データベースサービスを提供するためのオラクルデータベースなど)にマッピングされるか、または関連付けられ得る。
特定の実施例では、クラウドインフラストラクチャシステム100のさまざまなコンポーネントまたはモジュールおよびクラウドインフラストラクチャシステム100によって提供されるサービスによって共有されるいくつかの内部サービス162が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよび回復サービス、IDEにおいてクラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。
ランタイムインフラストラクチャ層164は、さまざまな他の層およびコンポーネントが構築されるハードウェア層を表わす。特定の実施例では、ランタイムインフラストラクチャ層164は、ストレージ、処理およびネットワーキングリソースを提供するための1つのオラクルのExadataマシンを備えていてもよい。Exadataマシンは、さまざまなデータベースサーバ、ストレージサーバ、ネットワーキングリソース、およびクラウドサービス関連のソフトウェア層をホストするための他のコンポーネントから構成され得る。特定の実施例では、Exadataマシンは、ストレージ、演算、ネットワークおよびソフトウェアリソースの集合体を提供するエンジニアド・システムであるOracle Exalogicと連携するように設計され得る。ExadataおよびExalogicの組み合わせは、クラウドサービスを提供するための高性能で、高可用性で、スケーラブルで、安全な、管理されたプラットフォームを与える完全なハードウェアおよびソフトウェアエンジニアドソリューションを提供する。
図2は、本発明の実施例に係る図1Aに示されるクラウドインフラストラクチャシステムを実現するためのシステム環境の簡略ブロック図である。示される実施例では、システム環境230は、クラウドインフラストラクチャシステム100と対話するためにユーザによって使用され得る1つ以上のクライアント演算装置224,226および228を含む。クライアント装置は、クラウドインフラストラクチャシステム100によって提供されるサービスを利用するためにクラウドインフラストラクチャシステム100と対話するようにクライアント装置のユーザによって使用され得る、ウェブブラウザ、プロプライエタリクライアントアプリケーション(例えばOracle Forms)またはその他のアプリケーションなどのクライアントアプリケーションを動作させるように構成され得る。
図2に示されるクラウドインフラストラクチャシステム100は、図2に示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図2に示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、クラウドインフラストラクチャシステム100は、図2に示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。
クライアント演算装置224,226および228は、汎用パーソナルコンピュータ(一例として、マイクロソフトウィンドウズ(登録商標)および/またはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む)、(マイクロソフトウィンドウズモバイルなどのソフトウェアを実行し、インターネット、電子メール、SMS、ブラックベリーまたは使用可能な他の通信プロトコルである)携帯電話もしくはPDA、さまざまな市販のUNIX(登録商標)もしくはUNIXのようなオペレーティングシステム(さまざまなGNU/Linux(登録商標)オペレーティングシステムを含むがこれに限定されるものではない)のいずれかを実行するワークステーションコンピュータ、またはその他の演算装置であってもよい。例えば、クライアント演算装置224,226および228は、ネットワークを介して通信することができるシン・クライアントコンピュータ、インターネットへの接続が可能なゲーム機および/またはパーソナルメッセージング装置などのその他の電子装置であってもよい。例示的なシステム環境230が3つのクライアント演算装置とともに示されているが、いかなる数のクライアント演算装置がサポートされてもよい。センサを有する装置などの他の装置がクラウドインフラストラクチャシステム100と対話してもよい。
ネットワーク232は、クライアント224,226および228とクラウドインフラストラクチャシステム100との間でのデータの通信および交換を容易にし得る。ネットワーク232は、TCP/IP、SNA、IPX、AppleTalkなどを含むがこれらに限定されるものではないさまざまな市販のプロトコルのいずれかを使用してデータ通信をサポートし得る、当業者になじみのある任意のタイプのネットワークであってもよい。単に一例として、ネットワーク232は、イーサネット(登録商標)ネットワーク、トークン・リング・ネットワークなどのローカルエリアネットワーク(local area network:LAN)、広域ネットワーク、仮想プライベートネットワーク(virtual private network:VPN)を含むがこれに限定されるものではない仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網(public switched telephone network:PSTN)、赤外線ネットワーク、無線ネットワーク(例えばIEEE802.1Xの一連のプロトコル、当該技術分野において公知のブルートゥース(登録商標)プロトコルおよび/またはその他の無線プロトコルのいずれかの下で動作するネットワーク)、ならびに/または、これらのおよび/もしくは他のネットワークの任意の組み合わせであってもよい。
クラウドインフラストラクチャシステム100は、汎用コンピュータ、特化サーバコンピュータ(一例として、PCサーバ、UNIXサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式のサーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な配置および/もしくは組み合わせであり得る1つ以上のコンピュータおよび/またはサーバを備えていてもよい。クラウドインフラストラクチャシステム100を構成する演算装置は、HTTPサーバ、FTPサーバ、CGIサーバ、Javaサーバ、データベースサーバなどを含む、オペレーティングシステムまたはさまざまな追加のサーバアプリケーションおよび/もしくは中間層アプリケーションのいずれかを実行し得る。例示的なデータベースサーバとしては、オラクル、マイクロソフト、サイベース、IBMなどから市販されているものが挙げられるが、これらに限定されるものではない。
さまざまな実施例では、クラウドインフラストラクチャシステム100は、クラウドインフラストラクチャシステム100によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。一実施例では、図2に示されるように、クラウドインフラストラクチャシステム100におけるコンポーネントは、アイデンティティ管理(Identity Management:IDM)モジュール200と、サービスモジュール202と、テナント自動化システム(Tenant Automation System:TAS)モジュール204と、サービスデプロイメントインフラストラクチャ(Service Deployment Infrastructure:SDI)モジュール206と、エンタープライズマネージャ(Enterprise Manager:EM)モジュール208と、ストアユーザインターフェース(user interface:UI)210、クラウドユーザインターフェース(UI)212およびサポートユーザインターフェース(UI)216などの1つ以上のフロントエンドウェブインターフェースと、オーダー管理モジュール214と、販売スタッフ218と、オペレータスタッフ220と、オーダーデータベース222とを含む。これらのモジュールは、汎用コンピュータ、特化サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な配置および/もしくは組み合わせであり得る1つ以上のコンピュータおよび/またはサーバを含んでいてもよく、またはそれらを使用して提供されてもよい。一実施例では、これらのモジュールのうちの1つ以上は、クラウドインフラストラクチャシステム100におけるクラウド管理機能108またはIaaSプラットフォーム110によって提供され得る。図2に示されるクラウドインフラストラクチャシステム100のさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図2に示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。
例示的なオペレーションにおいて、(1)において、クライアント装置224または226などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム100によって提供されるさまざまなサービスをブラウズし、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスについてのサブスクリプションのオーダーを行うことによって、クラウドインフラストラクチャシステム100と対話し得る。特定の実施例では、顧客は、ストアUI210またはクラウドUI212にアクセスし、これらのユーザインターフェイスを介してサブスクリプションオーダーを行い得る。
顧客がオーダーを行ったことに応答してクラウドインフラストラクチャシステム100によって受取られるオーダー情報は、顧客と、顧客がサブスクライブする予定の、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスとを特定する情報を含んでいてもよい。単一のオーダーは、複数のサービスのオーダーを含んでいてもよい。例えば、顧客は、クラウドUI212にログインして、同一のオーダーにおいてCRMサービスおよびJavaクラウドサービスについてのサブスクリプションを要求し得る。
さらに、オーダーは、オーダーされたサービスについての1つ以上のサービスレベルも含んでいてもよい。本明細書で使用され、以下でより詳細に説明されるように、サービスについてのサービスレベルは、ストレージの量、演算リソースの量、データ転送設備などの、サブスクリプションの文脈において要求されたサービスを提供するために割り当てられるリソースの量を決定する。例えば、ベーシックなサービスレベルは、最小レベルのストレージ、データ伝送またはユーザの数を提供することができ、より高いサービスレベルは、さらなるリソースを含み得る。
また、いくつかの例では、クラウドインフラストラクチャシステム100によって受取られるオーダー情報は、顧客レベルおよびサービスが求められる期間を示す情報を含んでいてもよい。顧客レベルは、サブスクリプション要求を行う顧客の優先度を規定する。一例では、優先度は、顧客とクラウドサービスのプロバイダとの間で合意されたサービスレベル合意書(Service Level Agreement:SLA)によって規定されるようにクラウドインフラストラクチャシステム100が顧客に保証または約束するサービスの質に基づいて決定され得る。一例では、さまざまな顧客レベルは、ベーシックレベル、シルバーレベルおよびゴールドレベルを含む。サービスの期間は、当該サービスの開始日および時刻と、当該サービスが求められる期間とを規定し得る(例えばサービス終了日および時刻が規定されてもよい)。
一実施例では、顧客は、ストアUI210を介して新たなサブスクリプションを要求するか、またはクラウドUI212を介してトライアルサブスクリプションを要求し得る。特定の実施例では、ストアUI210は、サービスプロバイダの電子商取引ストアフロントに相当し得る(例えばオラクルクラウドサービスのためのwww.oracle.com/store)。クラウドUI212は、サービスプロバイダのためのビジネスインターフェースに相当し得る。顧客は、クラウドUI212を介して、利用可能なサービスを調査し、関心のあるサービスにサインアップすることができる。クラウドUI212は、クラウドインフラストラクチャシステム100によって提供されるトライアルサブスクリプションをオーダーするのに必要なユーザ入力を取込む。また、クラウドUI212は、アカウント機能を閲覧し、クラウドインフラストラクチャシステム100内に位置するランタイム環境を構成するために使用され得る。新たなサブスクリプションのオーダーを行うことに加えて、ストアUI210は、サブスクリプションのサービスレベルの変更、サブスクリプションの期間の延長、サブスクリプションのサービスレベルの向上、既存のサブスクリプションの終了などの他のサブスクリプション関連のタスクを顧客が実行できるようにもし得る。
(1)につきオーダーが行われた後、(2)において、ストアUI210またはクラウドUI212のいずれかを介して受取られるオーダー情報がオーダーデータベース222に格納され、当該オーダーデータベース222は、クラウドインフラストラクチャシステム100によって操作されて他のシステム要素と連携して利用されるいくつかのデータベースのうちの1つであり得る。オーダーデータベース222は図2では単一のデータベースとして論理的に示されているが、実際の実現例では、これは1つ以上のデータベースを備えていてもよい。
(3)において、オーダーはオーダー管理モジュール214に送られる。オーダー管理モジュール214は、オーダーの検証および検証時のオーダーの予約などのオーダーに関連する課金およびアカウンティング機能を実行するように構成される。特定の実施例では、オーダー管理モジュール214は、契約管理モジュールと、インストールベースモジュールとを含んでいてもよい。契約管理モジュールは、クラウドインフラストラクチャシステム100との顧客のサービスレベル合意書(SLA)などの顧客のサブスクリプションオーダーに関連付けられた契約情報を格納し得る。インストールベースモジュールは、顧客のサブスクリプションオーダーにおけるサービスの詳細な説明を含み得る。オーダー情報に加えて、インストールベースモジュールは、サービスに関連するインストールの詳細、製品状態およびサービスに関連するサポートサービス履歴を追跡し得る。顧客が新たなサービスをオーダーするかまたは既存のものをアップグレードすると、インストールベースモジュールは、新たなオーダー情報を自動的に追加し得る。
(4)において、オーダーに関する情報は、TASモジュール204に通信される。一実施例では、TASモジュール204は、顧客によって行われたオーダーについてのサービスおよびリソースのプロビジョニングをオーケストレート(orchestrate)するためにオーダー情報を利用する。(5)において、TASコンポーネント204は、SDIモジュール206のサービスを使用してサブスクライブされたサービスをサポートするために、リソースのプロビジョニングをオーケストレートする。(6)において、TASモジュール204は、SDIモジュール206から受取られた、プロビジョニングされたオーダーに関連する情報をサービスモジュール202に提供する。いくつかの実施例では、(7)において、SDIモジュール206は、顧客のサブスクリプションオーダーを実現するために必要なリソースを割り当てて構成するために、サービスモジュール202によって提供されるサービスも使用し得る。
(8)において、サービスモジュール202は、オーダーの状態に関する通知をクライアント装置224,226および228上の顧客に送る。
特定の実施例では、TASモジュール204は、互いに関連付けられたビジネスプロセスを管理し、ビジネスロジックを適用してオーダーがプロビジョニングに進むべきか否かを判断するオーケストレーションコンポーネントとして機能する。一実施例では、新たなサブスクリプションのオーダーを受取ると、TASモジュール204は、リソースを割り当てて、当該サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、SDIモジュール206に要求を送る。SDIモジュール206は、顧客によってオーダーされたサービスのためのリソースの割り当てを可能にする。SDIモジュール206は、クラウドインフラストラクチャシステム100によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。したがって、TASモジュール204は、サービスおよびリソースがオンザフライで実際にプロビジョニングされるか否か、または予めプロビジョニングされて要求時に単に配分/割り当てられるか否かなどの実装詳細から切離され得る。
特定の実施例では、ユーザは、オーダー管理モジュール214と直接対話して、オーダーの検証および検証時のオーダーの予約などの課金およびアカウンティング関連機能を実行するためにストアUI210を使用し得る。いくつかの実施例では、顧客がオーダーを行う代わりに、(9)において、オーダーはその代わりに、顧客のサービス担当者または販売担当者などの顧客を代表する販売スタッフ218によって行われてもよい。販売スタッフ218は、オーダーを行うためまたは顧客に見積もりを提供するためにオーダー管理モジュール214によって提供されるユーザーインターフェース(図2には図示せず)を介して、オーダー管理モジュール214と直接対話し得る。例えば、これは、オーダーがオーダー管理モジュール214を介して顧客の販売担当者によって行われ得る大口顧客のためになされ得る。販売担当者は、顧客を代表してサブスクリプションを準備し得る。
EMモジュール208は、クラウドインフラストラクチャシステム100における顧客のサブスクリプションの管理および追跡に関連するアクティビティをモニタリングするように構成される。EMモジュール208は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップ時間およびシステムダウン時間の量などのサブスクリプションオーダーにおけるサービスについての使用統計を収集する。(10)において、クラウドインフラストラクチャシステム100のプロバイダの従業員であってもよいホストオペレータスタッフ220は、サービスがクラウドインフラストラクチャシステム100内でプロビジョニングされるシステムおよびリソースを管理するために、エンタープライズマネージャユーザインターフェース(図2には図示せず)を介してEMモジュール208と対話し得る。
アイデンティティ管理(IDM)モジュール200は、クラウドインフラストラクチャシステム100においてアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成される。一実施例では、IDMモジュール200は、クラウドインフラストラクチャシステム100によって提供されるサービスを利用したい顧客についての情報を制御する。このような情報は、このような顧客のアイデンティティを認証する情報、および、さまざまなシステムリソース(例えばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してそれらの顧客がどのアクションを実行することが認可されるかを表わす情報を含み得る。また、IDMモジュール200は、各顧客についての記述的情報および当該説明的情報がどのようにして誰によってアクセスおよび修正され得るかについての記述的情報の管理を含み得る。
一実施例では、アイデンティティ管理モジュール200によって管理される情報は、別個のアイデンティティドメインを作成するために分割可能である。特定のアイデンティティドメインに属する情報は、全ての他のアイデンティティドメインから切離されることができる。また、アイデンティティドメインは、複数の別個のテナントによって共有可能である。各々のこのようなテナントは、クラウドインフラストラクチャシステム100においてサービスにサブスクライブする顧客であり得る。いくつかの実施例では、顧客は、1つまたは多くのアイデンティティドメインを有することができ、各アイデンティティドメインは、1つ以上のサブスクリプションに関連付けられ得て、各サブスクリプションは、1つまたは多くのサービスを有する。例えば、単一の顧客は大規模事業体に相当し得て、この大規模事業体内の部門/部署についてアイデンティティドメインが作成されてもよい。さらに、EMモジュール208およびIDMモジュール200は、クラウドインフラストラクチャシステム100において顧客のサブスクリプションを管理および追跡するために、それぞれ(11)および(12)においてオーダー管理モジュール214と対話し得る。
一実施例では、(13)において、サポートUI216を介してサポートサービスも顧客に提供され得る。一実施例では、サポートUI216は、サポートスタッフが(14)においてサポートサービスを実行するようにサポートバックエンドシステムを介してオーダー管理モジュール214と対話することを可能にする。クラウドインフラストラクチャシステム100におけるサポートスタッフおよび顧客は、サポートUI216を介して、バグ報告を提出し、これらの報告の状態を確認することができる。
図2に図示されない他のインターフェイスもクラウドインフラストラクチャシステム100によって提供されてもよい。例えば、アイデンティティドメイン管理者は、ドメインおよびユーザアイデンティティを構成するためにIDMモジュール200へのユーザインターフェイスを使用し得る。また、顧客は、利用したい各サービスのための別個のインターフェイスにログインし得る。特定の実施例では、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスにサブスクライブしたい顧客は、さまざまな役割および任務も割り当てられ得る。一実施例では、顧客に割り当てられ得るさまざまな役割および任務は、バイヤ、アカウント管理者、サービス管理者、アイデンティティドメイン管理者、またはクラウドインフラストラクチャシステム100によって提供されるサービスおよびリソースを利用するユーザの役割および任務を含んでいてもよい。さまざまな役割および任務は、以下の図4にさらに十分に示されている。
図3Aは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるTASモジュールによって実行され得る処理を示す簡略化されたフローチャート300を示す。図3Aに示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(例えばコード、命令、プログラム)、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、(例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の)メモリに格納されてもよい。図3Aに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図3Aに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図3Aに示される処理は、図3Bに詳細に示されるように、TASコンポーネント204における1つ以上のコンポーネントによって実行され得る。
302において、顧客のサブスクリプションオーダーが処理される。当該処理は、一例ではオーダーの認証を含んでいてもよい。オーダーの認証は、顧客がサブスクリプションの代金を支払ったことを保証すること、および、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、(CRMサービスの場合など)許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。また、処理は、クラウドインフラストラクチャシステム100によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。
304において、オーダーに関連付けられたビジネスプロセスが特定される。いくつかの例では、複数のビジネスプロセスがオーダーについて特定され得る。各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。一例として、第1のビジネスプロセスは、オーダーのための物理的リソースのプロビジョニングに関連する1つ以上のステップを特定し得て、第2のビジネスプロセスは、オーダーについての顧客アイデンティティとともにアイデンティティドメインを作成することに関連する1つ以上のステップを特定し得て、第3のビジネスプロセスは、ユーザについての顧客記録の作成などのバックオフィス機能の実行、オーダーに関連するアカウンティング機能の実行などに関連する1つ以上のステップを特定し得る。特定の実施例では、オーダーにおけるさまざまなサービスを処理するためにさまざまなビジネスプロセスも特定されてもよい。例えば、CRMサービスおよびデータベースサービスを処理するためにさまざまなビジネスプロセスが特定されてもよい。
306において、304でオーダーについて特定されたビジネスプロセスが実行される。オーダーに関連付けられたビジネスプロセスの実行は、ステップ304において特定されたビジネスプロセスに関連付けられた一連のステップのオーケストレートを含んでいてもよい。例えば、オーダーのための物理リソースのプロビジョニングに関連するビジネスプロセスの実行は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成するために、SDIモジュール206に要求を送ることを含んでいてもよい。
308において、プロビジョニングされたオーダーの状態に関する通知が顧客に送られる。ステップ302,304,306および308の実行に関連するさらなる説明については、図3Bに詳細に記載されている。
図3Bは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるTASモジュールにおける1つ以上のサブモジュールの簡略化された高レベル図を示す。一実施例では、図3Bに示されるモジュールは、図3Aに示されるステップ302〜308に記載された処理を実行する。示される実施例では、TASモジュール204は、オーダー処理モジュール310と、ビジネスプロセス識別子312と、ビジネスプロセスエクセキュータ316と、超過フレームワーク322と、ワークフロー特定モジュール324と、バンドルされたサブスクリプション生成モジュール326とを備える。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図3Bに示されるTASモジュールのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図3Bに示されるものよりも多くのまたは少ないモジュールを含んでいてもよい。
一実施例では、オーダー処理モジュール310は、顧客からのオーダーを1つ以上の入力ソース321から受取る。例えば、オーダー処理モジュール310は、一実施例ではクラウドUI212またはストアUI210を介してオーダーを直接受取ってもよい。代替的に、オーダー処理モジュール310は、オーダー管理モジュール214またはオーダーデータベース222からオーダーを受取ってもよい。次いで、オーダー処理モジュール310は、オーダーを処理する。特定の実施例では、オーダーの処理は、サービスタイプ、サービスレベル、顧客レベル、リソースのタイプ、サービスインスタンスに割り当てられるリソースの量、およびサービスが求められる期間などのオーダーについての情報を含む顧客記録の生成を含む。処理の一部として、オーダー処理モジュール310は、オーダーが有効なオーダーであるか否かも判断する。これは、顧客が同一の名前を備えたサブスクリプションをまだ有していないことを保証すること、または、(フュージョンCRMサービスの場合など)許可されないサブスクリプションタイプについて同一のアイデンティティドメインにおいて同一タイプの複数のサブスクリプションを顧客が作成しようと試みていないことを保証することを含む。
また、オーダー処理モジュール310は、オーダーについてのさらなる処理を実行し得る。処理は、クラウドインフラストラクチャシステム100によって処理されている各オーダーについてのオーダーの状態の追跡を含んでいてもよい。一実施例では、オーダー処理モジュール310は、オーダーに関係するいくつかの状態を特定するために各オーダーを処理し得る。一例では、オーダーのさまざまな状態は、初期化状態、プロビジョニング状態、アクティブ状態、管理が必要な状態、エラー状態などであり得る。初期化状態は、新たなオーダーの状態を指し、プロビジョニング状態は、オーダーについてのサービスおよびリソースがプロビジョニングされた時点のオーダーの状態を指す。オーダーがTASモジュール204によって処理され、その趣旨の通知が顧客に与えられると、オーダーはアクティブ状態になる。問題を解決するために管理者による介入が必要な場合、オーダーは管理が必要な状態である。オーダーを処理できない場合、オーダーはエラー状態である。オーダー進捗状態の維持に加えて、オーダー処理モジュール310は、プロセスの実行中に遭遇するいかなる障害についても詳細な情報を維持する。他の実施例では、以下で詳細に記載されるように、オーダー処理モジュール310によって実行されるさらなる処理は、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、サブスクリプションの期間の延長、およびサブスクリプションのキャンセルまたはサブスクリプションにおけるさまざまな期間にわたるさまざまなサービスレベルの指定も含んでいてもよい。
オーダーがオーダー処理モジュール310によって処理された後、オーダーがプロビジョニングに進むべきか否かを判断するためにビジネスロジックが適用される。一実施例では、オーダーのオーケストレートの一部として、ビジネスプロセス識別子312は、処理されたオーダーをオーダー処理モジュール310から受取って、ビジネスロジックを適用して、処理中のオーダーで使用されるべき特定のビジネスプロセスを特定する。一実施例では、ビジネスプロセス識別子312は、オーダーで使用されるべき特定のビジネスプロセスを決定するために、サービスカタログ314に格納されている情報を利用し得る。一実施例では、図3Aに示されるように、オーダーについて複数のビジネスプロセスが特定されてもよく、各ビジネスプロセスは、オーダーのさまざまな局面を処理するための一連のステップを特定する。別の実施例では、上記のように、CRMサービスまたはデータベースサービスなどのさまざまなタイプのサービスまたはサービスの組み合わせについてさまざまなビジネスプロセスが規定されてもよい。一実施例では、サービスカタログ314は、オーダーを特定のタイプのビジネスプロセスにマッピングする情報を格納し得る。ビジネスプロセス識別子312は、処理中のオーダーについての特定のビジネスプロセスを特定するためにこの情報を使用し得る。
ビジネスプロセスが特定されると、ビジネスプロセス識別子312は、実行されるべき特定のビジネスプロセスをビジネスプロセスエクセキュータ316に通信する。次いで、ビジネスプロセスエクセキュータ316は、クラウドインフラストラクチャシステム100における1つ以上のモジュールと連携して動作することによって、特定されたビジネスプロセスのステップを実行する。いくつかの実施例では、ビジネスプロセスエクセキュータ316は、ビジネスプロセスに関連付けられたステップを実行するためのオーケストレータの役割を果たす。例えば、ビジネスプロセスエクセキュータは、オーダーに関連するワークフローを特定して、オーダーにおけるサービスの超過を判断するか、またはオーダーに関連するサービスコンポーネントを特定するビジネスプロセスにおけるステップを実行するようにオーダー処理モジュール310と対話し得る。
一例では、ビジネスプロセスエクセキュータ316は、サブスクリプションオーダーにおいて要求されたサービスのためにリソースを割り当ててプロビジョニングするためのビジネスプロセスにおけるステップを実行するようにSDIモジュール206と対話する。この例では、ビジネスプロセスにおける各ステップごとに、ビジネスプロセスエクセキュータ316は、リソースを割り当てて、特定のステップを実現するために必要なリソースを構成するために、SDIコンポーネント206に要求を送り得る。SDIコンポーネント206は、リソースの実際の割り当てを担当する。オーダーのビジネスプロセスの全てのステップが実行されると、ビジネスプロセスエクセキュータ316は、サービスコンポーネント202のサービスを利用することによって、処理されたオーダーの通知を顧客に送り得る。通知は、処理されたオーダーの詳細を有する電子メール通知を顧客に送ることを含んでいてもよい。また、電子メール通知は、顧客がサブスクライブされたサービスにアクセスすることを可能にするための、オーダーに関連するデプロイメント情報も含んでいてもよい。
特定の実施例では、TASモジュール204は、TASモジュール204がクラウドインフラストラクチャシステム100における他のモジュールと対話し、他のモジュールがTASモジュール204と対話することを可能にする1つ以上のTASアプリケーションプログラミングインターフェース(Application Programming Interface:API)318を提供し得る。例えば、TAS APIは、顧客のサブスクリプションオーダーのためのリソースをプロビジョニングするために、非同期シンプル・オブジェクト・アクセス・プロトコル(Simple Object Access Protocol:SOAP)ベースのウェブサービスコールを介してSDIモジュール206と対話するシステムプロビジョニングAPIを含んでいてもよい。一実施例では、TASモジュール204は、システムおよびサービスインスタンスの作成および削除を達成し、サービスインスタンスを向上したサービスレベルに切替え、サービスインスタンスを関連付けるためにも、システムプロビジョニングAPIを利用し得る。この一例は、安全なウェブサービス通信を可能にするためのフュージョンアプリケーションサービスインスタンスへのJavaサービスインスタンスの関連付けである。また、TAS APIは、処理されたオーダーを顧客に通知するためにサービスモジュール202と対話する通知APIも含んでいてもよい。特定の実施例では、TASモジュール204は、サブスクリプション情報、機能停止および通知(例えば計画されたダウンタイム)もサービスコンポーネント202に定期的に伝える。
特定の実施例では、TASモジュール204は、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などのプロビジョニングされたサービスの各々についての使用統計をEMモジュール208から定期的に受取る。超過フレームワーク322は、サービスの過剰使用が生じたか否かを判断し、生じた場合には超過に対してどれぐらい課金されるかを判断するために当該使用統計を利用し、この情報をオーダー管理モジュール214に提供する。
特定の実施例では、TASモジュール204は、顧客のサブスクリプションオーダーの処理に関連付けられた1つ以上のワークフローを特定するように構成されるオーダーワークフロー特定モジュール324を含む。特定の実施例では、TASモジュール204は、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスについてのサブスクリプションオーダーを顧客が行うと顧客のためにサブスクリプションオーダーを生成するためのサブスクリプションオーダー生成フレームワーク326を含んでいてもよい。一実施例では、サブスクリプションオーダーは、当該サブスクリプションオーダーにおいて顧客によって要求されたサービスを提供することを担当する1つ以上のサービスコンポーネントを含む。
さらに、TASモジュール204は、もしあれば顧客が利用可能な履歴情報を考慮に入れながら、顧客によってサブスクライブされた1つ以上のサービスのためのリソースのプロビジョニングを可能にするために、テナント情報システム(Tenant Information System:TIS)データベース320などの1つ以上のさらなるデータベースとも対話し得る。TISデータベース320は、顧客によってサブスクライブされたオーダーに関係する履歴オーダー情報および履歴使用情報を含んでいてもよい。
TASモジュール204は、さまざまなデプロイメントモデルを使用してデプロイされ得る。特定の実施例では、デプロイメントは、1つ以上の分散されたコンポーネントと遣り取りする中心コンポーネントを含む。分散されたコンポーネントは、例えばさまざまなデータセンタとしてデプロイされてもよく、したがってデータセンタコンポーネントとも称されてもよい。中心コンポーネントは、クラウドインフラストラクチャシステム100においてオーダーを処理してサービスをまとめるための機能を含み、データセンタコンポーネントは、サブスクライブされたサービスにリソースを提供するランタイムシステムをプロビジョニングして動作させるための機能を提供する。
図4は、本発明の実施例に係るTASモジュールの例示的な分散型デプロイメントを示す。図4に示される実施例では、TASモジュール204の分散型デプロイメントは、TAS中心コンポーネント400と、1つ以上のTASデータセンタ(Data Center:DC)コンポーネント402,404および406とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
一実施例では、TAS中心コンポーネント400の任務は、顧客オーダーを受取って、新たなサブスクリプションの作成、サブスクリプションにおけるサービスのサービスレベルの変更、サブスクリプションに含まれるサービスの変更、およびサブスクリプションの期間の延長、またはサブスクリプションのキャンセルなどのオーダー関連のビジネスオペレーションを実行するための集中型コンポーネントを提供することを含むが、これに限定されるものではない。また、TAS中心コンポーネント400の任務は、クラウドインフラストラクチャシステム100によって必要とされるサブスクリプションデータを維持および供給すること、ならびに、全てのバックオフィスインタラクションに対処するためにオーダー管理モジュール214、サポートUI216、クラウドUI212およびストアUI210と遣り取りすることも含んでいてもよい。
一実施例では、TAS DC402,404および406の任務は、顧客によってサブスクライブされた1つ以上のサービスのためのリソースのプロビジョニングをオーケストレートするためのランタイムオペレーションを実行することを含むが、これに限定されるものではない。また、TAS DC402,404および406は、サブスクリプションオーダーのロッキング、アンロッキング、イネーブルまたはディスエーブル、オーダーに関連するメトリクスの収集、オーダーの状態の判断、およびオーダーに関連する通知イベントの送信などのオペレーションを実行するための機能も含む。
図4に示される分散型TASシステムの例示的なオペレーションでは、TAS中心コンポーネント400は、最初に、クラウドUI212、ストアUI210を介して、オーダー管理システム214を介して、またはオーダーデータベース222を介して、顧客からオーダーを受取る。一実施例では、顧客は、財務情報ならびにサブスクリプションをオーダーおよび/または変更するための権限を有するバイヤに相当する。一実施例では、オーダー情報は、顧客、顧客がサブスクライブしたいサービスのタイプ、および要求への対処を担当するアカウント管理者を特定する情報を含む。特定の実施例では、アカウント管理者は、クラウドインフラストラクチャシステム100によって提供される1つ以上のサービスへのサブスクリプションについてのオーダーを顧客が行うと、顧客によって任命され得る。オーダー情報に基づいて、TAS中心コンポーネント400は、オーダーが発生するアメリカ、EMEAまたはアジア太平洋などの世界のデータ領域、およびオーダーをプロビジョニングするためにデプロイされる特定のTAS DC(例えば402,404または406)を特定する。一実施例では、オーダーをプロビジョニングするためにデプロイされる(例えばDC402,404または406の中からの)特定のTAS DCは、要求が発生した地理的なデータ領域に基づいて決定される。
次いで、TAS中心コンポーネント400は、オーダー要求についてのサービスをプロビジョニングするためにオーダー要求を特定のTAS DCに送る。一実施例では、TAS DC402,404または406は、特定のTAS DCにおいてオーダー要求を処理することを担当するサービス管理者およびアイデンティティドメイン管理者を特定する。サービス管理者およびアイデンティティ管理者は、サブスクリプションオーダーにおいて特定されるアカウント管理者によって任命され得る。TAS DC402,404または406は、オーダーのための物理リソースのプロビジョニングをオーケストレートするためにSDIモジュール204と通信する。それぞれのTAS DC402,404または406におけるSDIコンポーネント206は、リソースを割り当てて、サブスクリプションオーダーを実現するために必要なそれらのリソースを構成する。
特定の実施例では、TAS DC402,404または406は、サブスクリプションに関連付けられたアイデンティティドメインを特定する。SDIコンポーネント206は、既存のアイデンティティドメインの特定または新たなアイデンティティドメインの作成のためにアイデンティティドメイン情報をIDMコンポーネント200(図2に図示)に提供し得る。オーダーがそれぞれのTAS DC402,404または406におけるSDIモジュールによってプロビジョニングされると、TAS中心コンポーネント400は、サポートシステムにおけるプロビジョニングされたリソースに関する情報をサポートUI216を介して配置し得る。情報は、例えばサービスに関連するリソースメトリクスおよびサービスの使用統計の表示を含んでいてもよい。
オペレーション時に、各データセンタにおいて、EMモジュール208は、当該データセンタにおいてプロビジョニングされたプロビジョニングされたサービスの各々について、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などの使用統計を定期的に収集する。これらの統計は、EMモジュール208にローカルな(すなわち、同一のデータセンタにおける)TAS DCに提供される。実施例では、TAS DCは、サービスの過剰使用が生じたか否かを判断し、生じた場合には超過に対してどれぐらい課金されるかを判断するために使用統計を使用し、課金情報をオーダー管理システム214に提供し得る。
図5は、本発明の実施例に係るクラウドインフラストラクチャシステムにおける1つ以上のモジュールとのSDIモジュールのインタラクションを示す簡略ブロック図である。一実施例では、SDIモジュール206は、TASモジュール204によって受取られたサブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするためにTASモジュール204と対話する。特定の実施例では、図5に示されるモジュールのうちの1つ以上は、クラウドインフラストラクチャシステム100内のモジュールであってもよい。他の実施例では、SDIモジュール206と対話するモジュールのうちの1つ以上は、クラウドインフラストラクチャシステム100の外側にあってもよい。また、代替的な実施例は、図5に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。
一実施例では、SDIモジュール206におけるモジュールは、クラウドインフラストラクチャシステム100内のSaaSプラットフォーム102およびPaaSプラットフォーム104における1つ以上のモジュールを含んでいてもよい。さまざまなサービスのためのリソースのプロビジョニングを行うために、SDIモジュール206は、各々が特定のタイプのサービスのためのリソースのプロビジョニングに役立つようにカスタマイズされるさまざまな他のモジュールと対話し得る。例えば、図5に示されるように、SDIモジュール206は、JavaクラウドサービスをプロビジョニングするためにJavaサービスプロビジョニング制御モジュール500と対話し得る。一実施例では、Javaサービスプロビジョニング制御コンポーネント500は、Javaクラウドサービスをプロビジョニングするために実行される一組のタスクを含むSDIモジュール206によって規定されるJavaクラウドサービス(Java Cloud Service:JCS)アセンブリをデプロイし得る。次いで、インフラストラクチャリソース106は、Javaクラウドサービスをプロビジョニングするために必要なリソースを決定する。
他の例として、SDIモジュール206は、バーチャル・アセンブリ・ビルダ(Virtual Assembly Builder:VAB)モジュール502、アプリケーション・エクスプレス(Application Express:APEX)デプロイヤモジュール504、仮想マシン(Virtual Machine:VM)モジュール506、IDMモジュール200およびデータベースマシンモジュール118などの1つ以上のモジュールと対話し得る。VABモジュール502は、完全な複数層アプリケーション環境を構成およびプロビジョニングするための機能を含む。一実施例では、VABモジュール502は、VMモジュール506によって提供されるサービスを使用してクラウドインフラストラクチャシステム100においてミドルウェア(Middleware:MW)サービスをプロビジョニングするために、SDIモジュール206によって規定されるMWサービスアセンブリをデプロイする。APEXデプロイヤモジュール504は、データベースサービスを構成およびプロビジョニングするための機能を含む。一実施例では、APEXデプロイヤモジュール504は、インフラストラクチャリソース106によって提供されるリソースを使用してクラウドインフラストラクチャシステム100においてデータベースサービスをプロビジョニングするために、SDIモジュール206によって規定されるデータベースサービスアセンブリをデプロイする。SDIモジュール206は、クラウドインフラストラクチャシステム100において複数のアプリケーションにまたがるアクセス管理などのアイデンティティサービスを提供するためにIDMモジュール200と対話する。
図6は、本発明の実施例に係るSDIモジュールのサブモジュールの簡略化された高レベル図を示す。図6に示される実施例では、SDIモジュール206は、SDI−ウェブサービス(Web Service:WS)モジュール600と、SDI要求コントローラモジュール602と、SDIタスクマネージャモジュール604と、SDIモニタリングモジュール606と、SDIデータアクセスモジュール608と、SDI共通ライブラリモジュール610と、SDIコネクタモジュール612とを含む。これらのモジュールは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。図6に示されるSDIモジュール206およびそのさまざまなモジュールは、単に例示の目的で示されており、本発明の実施例の範囲を限定することを意図したものではない。代替的な実施例は、図6に示されるものよりも多くのまたは少ないモジュールを有していてもよい。これらのモジュールおよびそれらの機能については、以下で詳細に説明する。
SDI−WSモジュール600は、TASコンポーネント204のビジネスプロセスエクセキュータ316から、オーダーに関連付けられたビジネスにおけるステップを受取るための機能を含む。一実施例では、SDI−WSモジュール600は、ビジネスプロセスの各ステップを構文解析し、当該ステップをSDIモジュール206によって使用される内部表現に変換する。一実施例では、オーダーに関連付けられたビジネスプロセスの各ステップは、SDI−WSモジュール600へのSOAP要求の形態で、ウェブサービス処理層を介して(例えば図3Bに示されるシステムプロビジョニングAPIを介して)到着する。
SDI要求コントローラモジュール602は、SDIモジュール206における内部要求処理エンジンであり、非同期要求処理、同時要求処理、同時タスク処理、オーダー要求に関連するフォールト・トレラントな回復およびプラグインサポートを実行するための機能を含む。一実施例では、SDI要求コントローラモジュール602は、オーダーに関連付けられたビジネスプロセスの各ステップをSDI−WSモジュール600から受入れ、当該ステップをSDIタスクマネージャモジュール604に提出する。
SDIタスクマネージャモジュール604は、ビジネスプロセスにおいて規定された各ステップを、特定のステップをプロビジョニングするための一連のタスクに変換する。特定のステップのための一組のタスクがプロビジョニングされると、SDIタスクマネージャモジュール604は、特定のステップを実現するためにプロビジョニングされたリソースの詳細を有するオーダーペイロードを含むオペレーション結果により、TASモジュール204におけるビジネスプロセスエクセキュータ316に応答する。SDIタスクマネージャモジュール604は、オーダーに関連付けられた特定のビジネスプロセスの全てのステップが完了するまで、このプロセスを繰返す。
特定の実施例では、SDIタスクマネージャモジュール604は、SDIコネクタモジュール612のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。SDIコネクタモジュール612は、オーダー要求に関連する1つ以上のサービスをプロビジョニングするために、SDIタスクマネージャモジュール604によって規定されるタスクのデプロイメントに対処するための1つ以上のコネクタを含む。特定の実施例では、コネクタのうちの1つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、SDIコネクタモジュール612は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム100における外部モジュール(図5に図示)のうちの1つ以上と遣り取りする一組のコネクタ(ラッパーAPI)を含む。例えば、アプリケーション・エクスプレス(APEX)コネクタ614は、データベースサービスをプロビジョニングするために、APEXデプロイヤモジュール504と遣り取りする。ウェブセンタコネクタ616(Web Center Connector:WCC)は、ウェブサービスをプロビジョニングするために、クラウドインフラストラクチャシステム100におけるウェブセンタモジュールと遣り取りする。ウェブセンタモジュールは、ユーザエンゲージメントプラットフォームであり、クラウドインフラストラクチャシステム100において人々と情報とのコネクティビティを与えるための機能を含む。
特定の実施例では、ミドルウェアアプリケーション(Middleware Application:MA)コネクタ618は、ミドルウェアアプリケーションサービスをプロビジョニングするために、クラウドインフラストラクチャシステム100におけるVABモジュール502と遣り取りする。NUVIAQコネクタ620は、Javaサービスをプロビジョニングするために、VABモジュール502と遣り取りする。IDMコネクタ622は、クラウドインフラストラクチャシステム100においてサービスおよびリソースにサブスクライブするユーザにアイデンティティおよびアクセス管理を提供するために、IDMモジュール200と遣り取りする。バーチャル・アセンブリ・ビルダ(VAB)コネクタ624は、完全な複数層アプリケーション環境を構成およびプロビジョニングするために、クラウドインフラストラクチャシステム100におけるVABモジュール502と遣り取りする。プラグインコネクタ626は、クラウドインフラストラクチャシステム100におけるコンポーネントを管理およびモニタリングするために、EMモジュール208と遣り取りする。HTTPサーバコネクタ628は、クラウドインフラストラクチャシステム100においてユーザに接続サービスを提供するために、PaaSプラットフォームにおける1つ以上のウェブサーバと遣り取りする。
SDIモジュール206におけるSDIモニタリングモジュール606は、Java管理拡張(Java Management Extensions:JMX)要求を受取るためのインバウンドインターフェースを提供する。また、SDIモニタリングモジュール606は、クラウドインフラストラクチャシステム100においてアプリケーション、システムオブジェクトおよび装置を管理およびモニタリングするためのツールも提供する。SDIデータアクセスモジュール608は、Javaデータベースコネクティビティ(Java Database Connectivity:JDBC)要求を受取るためのインバウンドインターフェースを提供する。SDIデータアクセスモジュール608は、クラウドインフラストラクチャシステム100において、データアクセスをサポートし、オブジェクト関係マッピング、javaトランザクションAPIサービス、データアクセスオブジェクトおよび接続プーリングを提供する。SDI共通ライブラリモジュール610は、SDIモジュール206におけるモジュールのための構成サポートを提供する。
上記の図6の実施例は、本発明の実施例に係るSDIモジュールにおけるモジュールを記載している。図7Aは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるSDIモジュールのモジュールによって実行され得る処理を示す簡略化されたフローチャート700を示す。図7Aに示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(例えばコード、命令、プログラム)、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、(例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の)メモリに格納されてもよい。図7Aに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図7Aに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図7Aに示される処理は、図6に詳細に示されるSDIモジュール206における1つ以上のモジュールによって実行され得る。
702において、サブスクリプションオーダーに関連付けられたビジネスプロセスが受取られる。一実施例では、SDIモジュール206におけるSDI−WSモジュール600は、サブスクリプションオーダーに関連付けられたビジネスプロセスにおける1つ以上のステップをビジネスプロセスエクセキュータ316から受取る。704において、ビジネスプロセスにおける各ステップは、サブスクリプションオーダーのためのリソースをプロビジョニングするための一連のタスクに変換される。一実施例では、SDIモジュール206におけるSDIタスクマネージャモジュール604は、SDIコネクタモジュール612のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換する。706において、サブスクリプションオーダーは、一連のタスクに基づいてプロビジョニングされる。一実施例では、図6に示されるように、SDIコネクタモジュール612は、サブスクリプションオーダーにおけるサービスのためのリソースをプロビジョニングするために、SDIタスクマネージャモジュール604によって規定されるタスクのデプロイメントに対処するための1つ以上のコネクタを含む。
図6に関して上記したように、SDIタスクマネージャモジュール604は、SDIコネクタモジュール612のサービスを利用することによって、ビジネスプロセスにおいて規定された各ステップを一連のタスクに変換し、SDIコネクタモジュール612は、オーダー要求に関連する1つ以上のサービスをプロビジョニングするために、SDIタスクマネージャモジュール604によって規定されるタスクのデプロイメントに対処するための1つ以上のコネクタを含んでいてもよい。コネクタのうちの1つ以上は、特定のサービスタイプに特有のタスクに対処することができ、他のコネクタは、さまざまなサービスタイプにわたって共通のタスクに対処することができる。一実施例では、SDIコネクタモジュール612は、オーダー要求に関連するサービスおよびリソースをプロビジョニングするためにクラウドインフラストラクチャシステム100における外部モジュール(図5に図示)のうちの1つ以上と遣り取りする一組のコネクタ(ラッパーAPI)を含む。例えば、NUVIAQコネクタ620は、JavaサービスをプロビジョニングするためにVABモジュール502と遣り取りする。
図7Bは、本発明の実施例に係るNuviaqシステム710および他のクラウドインフラストラクチャシステムとのその関係の高レベルアーキテクチャを示す簡略ブロック図を示す。図7Bに示されるNuviaqシステム710は、図7Bに示されるもの以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図7Bに示される実施例は、本発明の実施例を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施例では、Nuviaqシステム710は、図7Bに示されるものよりも多くのまたは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。
特定の実施例では、Nuviaqシステム710は、PaaSオペレーションをオーケストレートするためのランタイムエンジンを提供するように構成され得る。Nuviaqシステム710は、他の製品およびサービスとの統合を容易にするためにウェブサービスAPIを提供し得る。また、Nuviaqシステム710は、システムプロビジョニング、アプリケーションデプロイメントおよび関連付けられたライフサイクルオペレーションにおける複雑なワークフローのためのサポートを提供し、管理およびモニタリングソリューションと統合する。
図7Bに示される実施例では、Nuviaqシステム710は、Nuviaqプロキシ712と、Nuviaqマネージャ714と、Nuviaqデータベース716とを備える。特定の実施例では、Nuviaqマネージャ714は、Nuviaqシステム710へのエントリポイントを提供し、ウェブサービスAPIを介してPaaSオペレーションへの安全なアクセスを提供する。内部では、Nuviaqマネージャ714は、データベースにおいてシステム状態を追跡し、ワークフローエンジン上でのジョブの実行を制御する。パブリッククラウドでは、Nuviaqマネージャ714は、プロビジョニングオペレーションおよびデプロイメントオペレーションをそれぞれ駆動するために、テナントプロビジョニングシステム(SDI206)およびテナントコンソールによってアクセスされ得る。
一実施例では、Nuviaqマネージャ714は、内部ワークフローエンジンを介して非同期にジョブを実行する。ジョブは、所与のPaaSワークフローに特有のアクションのシーケンスであってもよい。アクションは、順番に実行されてもよく、任意のステップにおける障害は、結果としてジョブ全体の障害になる。多くのワークフローアクションは、EMコマンドラインインターフェース(cli)などのワークフローに関連する外部システムに権限を委任する。一実現例では、Nuviaqマネージャ714アプリケーションは、ファイアウォール内で実行される関連付けられたHTTPサーバ(例えばオラクルHTTPサーバまたはOHS)インスタンスを有する2ノードウェブロジッククラスタにおいてホストされ得る。
特定の実施例では、Nuviaqプロキシ712は、Nuviaq APIへのパブリックアクセスポイントである。一実施例では、パブリックAPIのみがここで公開され得る。プロキシ712によって受取られた要求は、Nuviaqマネージャ714に送られ得る。一実施例では、Nuviaqプロキシ712はファイアウォールの外側で実行される一方、マネージャ714はファイアウォール内で実行される。一実現例では、Nuviaqプロキシ712アプリケーションは、ファイアウォールの外側で実行されるウェブロジッククラスタ上で実行される。
特定の実施例では、Nuviaqデータベース716は、プラットフォームインスタンス、デプロイメント計画、アプリケーション、ウェブロジックドメイン、ジョブ、アラーとなどであるがこれらに限定されないさまざまなドメインエンティティを追跡する。必要に応じて、主キーがサービスデータベースと整合させられてもよい。
一実施例では、プラットフォームインスタンス718は、所与のテナントのためのウェブロジックサービスに必要な全てのリソースを含んでいてもよい。
Nuviaqシステム710は、ウェブロジッククラウドサービスによって使用されるワークフローを実行するために、クラウドインフラストラクチャシステム100のさらなるシステムに依拠し得る。これらの依存性は、SDI206、IDM200、ウイルススキャンシステム、サービスデータベース、CRMインスタンスなどへの依存性を含んでいてもよい。例えば、Nuviaqシステム710は、SDI206におけるアセンブリデプロイヤによって実行される機能に依存し得る。一実施例では、アセンブリデプロイヤは、OVAB(Oracle Virtual Assembly builder:オラクルバーチャル・アセンブリ・ビルダ)およびOVM(Oracle Virtual Machine:オラクル仮想マシン)とのインタラクションを管理するためのシステムである。Nuviaqシステム710によって使用されるアセンブリデプロイヤの機能は、アセンブリをデプロイするための機能、アセンブリをアンデプロイするための機能、アセンブリデプロイメントを説明するための機能、アプライアンスをスケーリングするための機能などを含み得るが、これらに限定されるものではない。一実現例では、Nuviaqシステム710は、ウェブサービスAPIを介してアセンブリデプロイヤにアクセスする。
特定の実施例では、セキュリティポリシは、アプリケーションにデプロイされる前に特定のアーティファクトがウイルススキャンされることを必要とし得る。クラウドインフラストラクチャシステム100は、この目的でウイルススキャンシステムを提供し得て、パブリッククラウドの複数のコンポーネントのためのサービスとしてスキャンを提供する。
特定の実施例では、パブリッククラウドインフラストラクチャは、テナント(例えば顧客)およびそれらのサービスサブスクリプションについての情報を含むサービスデータベースを維持し得る。Nuviaqワークフローは、テナントもサブスクライブする他のサービスに対するクライアントとしてウェブロジックサービスを適切に構成するために、このデータにアクセスし得る。
Nuviaqシステム710は、そのセキュリティ統合のためにIDM200に依存し得る。特定の実施例では、Javaサービスインスタンスは、CRMインスタンスに関連付けられ得る。当該関連付けにより、Javaサービスインスタンスにデプロイされたユーザアプリケーションは、ウェブサービスコールを介してCRMインスタンスにアクセスできる。
Nuviaqシステム710によって提供されるサービスをさまざまなエンティティが使用し得る。Nuviaqシステム710のこれらのクライアントは、プラットフォームインスタンス上でアプリケーションを管理するために顧客がアクセスし得る管理サーバ(例えばオラクル管理サーバ)ベースのユーザインターフェイスであるテナントコンソールと、アプリケーションライフサイクル管理オペレーションへのアクセスを提供するように拡張されたオラクルIDE(JDeveloper、NetBeansおよびOEPE)などのいくつかのIDEと、プラットフォームインスタンス上のライフサイクルオペレーションにアクセスするために利用可能な1つ以上のコマンドラインインターフェース(Command Line Interface:CLI)とを含んでいてもよい。
Nuviaqシステム710についてのプロビジョニング使用事例、すなわちプロビジョニングプラットフォームインスタンスの使用事例は、Nuviaq APIの作成プラットフォームインスタンスオペレーションによって実現される。クラウドインフラストラクチャシステム100の文脈では、Nuviaqシステムに対するサービスインスタンスは、Nuviaqプラットフォームインスタンスに対応する。プラットフォームインスタンスは、このインスタンスに関連する全ての後続のオペレーション上で使用される独自の識別子を割り当てられる。作成プラットフォームインスタンスアクションに提供されるプラットフォームデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにプラットフォームインスタンスの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい:
プロパティ#1:oracle.cloud.service.weblogic.size
値:ベーシック、標準、エンタプライズ
説明:サブスクリプションタイプを規定する。これは、サーバの数、データベース限度およびサービス設定の質に影響を及ぼす。
プロパティ#2:oracle.cloud.service.weblogic.trial
値:真、偽
説明:これがトライアルサブスクリプションであるか否かを示す。
プロパティ#3:oracle.cloud.service.weblogic.crm
値:CRMサービスID
説明:このウェブロジックサービスインスタンスに関連付けられるべきCRMサービスを特定する。
図7Cは、本発明の実施例に係るNuviaqシステムを使用するプロビジョニングプロセスのステップを示す例示的なシーケンス図を示す。図7Cに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。
インストール/更新アプリケーションの使用事例、すなわちインストールアプリケーションオペレーションは、アプリケーションアーカイブがパブリッククラウドのセキュリティ要件を満たすことを確認した後に、実行中のウェブロジックサーバにアプリケーションをデプロイする。一実施例では、インストールアプリケーションアクションに提供されるアプリケーションデプロイメント記述子により、テナントのサブスクリプション要件を満たすようにアプリケーションの構成を修正するプロパティを設定することができる。これらのプロパティは、例えば以下を含んでいてもよい:
プロパティ:oracle.cloud.service.weblogic.state
値:実行、停止
説明:デプロイメント後のアプリケーションの初期状態を規定する。
図7Dは、本発明の実施例に係るNuviaqシステムを使用するデプロイメントプロセスのステップを示す例示的なシーケンス図を示す。図7Dに示されるシーケンス図は、一例に過ぎず、限定的であるよう意図されるものではない。
図2に戻って、特定の実施例では、協働して動作するTAS204およびSDI206は、クラウドインフラストラクチャシステム100によって提供される一組のサービスから顧客によってオーダーされた1つ以上のサービスのためにリソースをプロビジョニングすることを担当する。例えば、一実施例では、データベースサービスをプロビジョニングするために、自動化されたプロビジョニングフローは、有料サブスクリプションについては以下のようなものであってもよい:
(1)顧客は、ストアUI210を介して、サービスの有料サブスクリプションのオーダーを行う。
(2)TAS204がサブスクリプションオーダーを受取る。
(3)サービスが利用可能であると、TAS204は、SDI206のサービスを使用することによってプロビジョニングを開始する。TAS204は、ビジネスプロセスのオーケストレーションを実行してもよく、関連のビジネスプロセスを実行してオーダーのプロビジョニング局面を完了する。一実施例では、TAS204は、プロビジョニングに関わるステップをオーケストレートして、ライフサイクルオペレーションを処理するために、BPEL(ビジネスプロセス実行言語:Business Process Execution Language)プロセスマネージャを使用し得る。
(4)一実施例では、データベースサービスをプロビジョニングするために、SDI206は、要求を行っている顧客にスキーマを関連付けるようにCLOUD_UIにおけるPLSQL APIを呼出し得る。
(5)顧客へのスキーマの関連付けが成功した後、SDIはTASに知らせて、TASは、データベースサービスが現在顧客によって使用可能な状態にあるという通知を顧客に送る。
(6)顧客は、(例えばcloud.oracle.comなどのURALを使用して)クラウドインフラストラクチャシステム100にログインし、サービスを起動し得る。
いくつかの実施例では、顧客は、トライアルベースでサービスにサブスクライブすることも許可されてもよい。例えば、このようなトライアルオーダーは、(例えばcloud.oracle.comを使用して)クラウドUI212を介して受取られ得る。
特定の実施例では、クラウドインフラストラクチャシステム100は、顧客またはテナント同士の間で基本的なハードウェアおよびサービスインスタンスが共有されることを可能にする。例えば、データベースサービスは、一実施例では、図7Eに示されるようにプロビジョニングされ得る。図7Eは、複数のExadata演算ノード730および732を示し、演算ノード730および732の各々が、データベースサービスのためにプロビジョニングされたデータベースインスタンスを提供する。例えば、演算ノード730は、データベースサービスのためのデータベースインスタンス734を提供する。各々のExadata演算ノードは、複数のデータベースインスタンスを有していてもよい。
特定の実施例では、各データベースインスタンスは、複数のスキーマを備えていてもよく、当該スキーマは、異なる顧客またはテナントに関連付けられてもよい。例えば、図7Eでは、データベースインスタンス734は、2つのスキーマ736および738を提供し、スキーマ736および738の各々は、それ自体の表を有する。スキーマ736は、データベースサービスにサブスクライブする第1の顧客またはテナントに関連付けられ得て、スキーマ738は、データベースサービスにサブスクライブする第2の顧客またはテナントに関連付けられ得る。各テナントは、完全に切離されたスキーマを得る。各スキーマは、関連付けられたテナントについての表、ビュー、格納されたプロシージャ、トリガなどを含むデータベースオブジェクトを管理できる容器のように動作する。各スキーマは、1つの専用の表領域を有し得て、各々の表領域は、1つのデータファイルを有する。
このように、単一のデータベースインスタンスは、複数のテナントにデータベースサービスを提供することができる。これは、基本的なハードウェアリソースの共有を可能にするだけでなく、テナント同士の間でのサービスインスタンスの共有も可能にする。
特定の実施例では、このようなマルチテナンシシステムは、IDM200によって容易になり、これにより、各々がそれ自体の別個のアイデンティティドメインを有する複数の別個の顧客が、クラウドにおいて共有されるハードウェアおよびソフトウェアを使用することが有利に可能になる。その結果、各顧客が自身の専用のハードウェアまたはソフトウェアリソースを有する必要がなくなり、場合によっては、特定の時点で一部の顧客によって使用されていないリソースが、他の顧客によって使用可能になり、それによってそれらのリソースが無駄になることを防止する。例えば、図7Eに示されるように、データベースインスタンスは、各々がそれぞれのアイデンティティドメインを有する複数の顧客に供給されることができる。各々のこのようなデータベースサービスインスタンスは、多くの別個のアイデンティティドメインの中で共有される単一の物理的なマルチテナントデータベースシステムの別個の抽象化またはビューであり得るが、各々のこのようなデータベースサービスインスタンスは、各々の他のデータベースサービスインスタンスが有するものとは別個の、場合によっては異なるスキーマを有することができる。したがって、マルチテナントデータベースシステムは、顧客指定のデータベーススキーマとそれらのデータベーススキーマが関係するアイデンティティドメインとの間のマッピングを格納し得る。マルチテナントデータベースシステムは、特定のアイデンティティドメインのためのデータベースサービスインスタンスに、当該特定のアイデンティティドメインにマッピングされるスキーマを使用させ得る。
また、マルチテナンシは、Javaサービスなどの他のサービスに拡張可能である。例えば、複数の顧客は、それぞれのアイデンティティドメイン内に配置されたJAVAサービスインスタンスを有し得る。各々のこのようなアイデンティティドメインは、ハードウェアの仮想的な「スライス」と見なされることができるJAVA仮想マシンを有し得る。一実施例では、ジョブモニタリングサービス(例えばハドソン)は、各々の別個のアイデンティティドメインがJAVAエンタプライズ版プラットフォームのそれ自体の別個の仮想的な「スライス」を有することを可能にするように、クラウドにおけるJAVAエンタプライズ版プラットフォーム(例えばオラクルウェブロジック)と組み合わせられてもよい。このようなジョブモニタリングサービスは、例えばオペレーティングシステムの時間ベースのジョブスケジューラによって実行されるソフトウェアプロジェクトまたはジョブの構築などの繰返されるジョブの実行をモニタリングし得る。このような繰返されるジョブは、ソフトウェアプロジェクトの連続的な構築および/またはテストを含んでいてもよい。さらにまたは代替的に、このような繰返されるジョブは、ジョブモニタリングサービスが実行されるマシンから離れたマシン上で実行されるオペレーティングシステム起動ジョブの実行のモニタリングを含んでいてもよい。
ポッドプロビジョニングおよびサービスプロビジョニング
いくつかの実施例に従うと、SDIは、サービスのために別個のPODプロビジョニングおよびサービスプロビジョニングを調整することができる。PODは、以下のうちの1つを表わし得る論理エンティティである:(Javaサービスの場合と同様に)予めプロビジョニングされた匿名のシングルテナントデプロイメント;または、(データベースサービスの場合と同様に)複数のテナントのために機能するマルチテナントスタック(物理的または仮想的)。例えば、PODは物理的なスタック上へのサービスのデプロイメントである。PODは1つ以上のサービスインスタンスを収容することができる。PODは先験的に作成することができるか、または、サービスインスタンスが所与の顧客のために作成されるときにオンデマンドで作成することができる。
いくつかの例においては、PODは、サービスを実行させるためのソフトウェアスタックのインスタンス化である。このため、PODを用いてサービスを実行する。例えば、Javaサービスに対応するPODは仮想マシンのスタックを含んでもよい。別の例として、データベースサービスのためのPODは、データベースのインスタンスを含んでもよい。PODは、サービスをホストすることのできるサブシステムと見なされてもよい。異なるポッドを異なるサービスのために用いてもよい。
サービスのためのPODを作成するタスクはPODプロビジョニングと称される。図8Bに示されるように、PODプロビジョニングは、SDIモジュール206によって容易にされ得る。PODプロビジョニングは、ソフトウェアコンポーネントの匿名インスタンスを作成する動作である。インフラストラクチャの観点から、PODは完全にインストールされて有線接続されてもよい。PODは、顧客特有の構成データまたは統合を有さない(例えば、いかなる顧客ストライプにも接続されない)。
物理的なPODプロビジョニングは3つの広範囲の局面を含み得る。
1.サービスの物理的なフットプリントを定義するためのPOD定義スキーマ;
2.サービス特有のプラグインを取込むためのサービス定義スキーマ;ならびに
3.エンタプライズ管理(EM:Entreprise Management)、アイデンティティ管理(IDM:Identity Management)、ユニフォーム・リソース・ロケータ(URL:Uniform Resource Locator)ルーティング、および他のサービス特有の構成を取込むためのサービス構成スキーマ。
各々のサービスのために異なるPODが作成されてもよい。例えば、Javaサービスの場合、PODは、ミドルウェア技術を実行する(例えば、フュージョンミドルウェアを実行する)一組のVMにマップし得る。PODプロビジョニングのために、SDIモジュール206によって別々の自動化フローが用いられてもよい。いくつかの例においては、PODはほぼ完全に仮想的な概念にもなり得る。
PODの一例として、特定の顧客に特定のサービスを提供するためにともに有線接続された一組のデータセンタリソースを含み得る。PODは、共有されるインフラストラクチャにおいて専用のリソースを含み得る。例えば、オラクル・バーチャル・アセンブリ・ビルダ(OVAB:Oracle Virtual Assembly Builder)技術などのVAB技術を用いてデプロイされるサービスの場合、OVABアセンブリはPODである。PODの別の例として、ドメインにJavaアセンブリを構成するVMのコアセットを含み得る。フュージョンアプリケーションの場合、PODは、データベースおよびVMを含み得るフュージョンアプリケーションを特定的にインストールするためだけの一組の仮想マシンであり得る。データベースサービスのために、PODはExadataと、当該Exadata上にDBインスタンスとをともに含み得る。
図8Aは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるSDIモジュール206によって実行され得る処理を示す簡略化されたフローチャート800を示す。図8Aに示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(例えばコード、命令、プログラム)、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、(例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の)メモリに格納されてもよい。図8Aに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図8Aに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図8Aに示される処理は、図6に詳細に示されるSDIモジュール206における1つ以上のモジュールによって実行され得る。
フローチャート800は、予めプロビジョニングされた各PODアセンブリのために実行され得る。SDIモジュール206は、管理アルゴリズムおよび選択アルゴリズムを用いてPODをバックグラウンドにおいてプロビジョニングし、次いで、要求が受取られると、特定のテナントのためのPODを決定することができる。例えば、図8Bに示されるように、SDIモジュール206は、顧客オーダーを受取る前にPODを予めプロビジョニングすることができる。サービス要求が受取られると、SDIモジュール206は、次に、図8Aに示されるように、PODに顧客情報を追加し、要求に基づいてPODをカスタマイズすることができる。
802において、SDIモジュール206は、一組のサービスからサービスを特定する、顧客からのサブスクリプションオーダー情報を格納することができる。例えば、サブスクリプションオーダー情報は、ストアUI 210からの、データベースサービスについての顧客要求であってもよい。サブスクリプションオーダー情報は顧客特有の構成を含み得る。
804において、SDIモジュール206は、サブスクリプションオーダー情報に関連付けられたサービスを決定することができる。例えば、SDIモジュール206は、顧客オーダーがデータベースサービスのためのものであると判断することができる。したがって、顧客オーダーが受取られると、SDIモジュール206は、顧客特有のPODを顧客要求にマッピングするために要求されたサービスのタイプを決定する。
806において、SDIモジュール206は、予めプロビジョニングされた匿名のデプロイメントをサブスクリプションオーダー情報にマッピングすることができる。予めプロビジョニングされた匿名のデプロイメントはPODであり得る。この明細書中において記載されるように、PODは、特定のサービスのために予めプロビジョニングされ、作成され得る。
サービスは、特定の顧客のサブスクリプションにマップすることができる。例えば、サービスは特定の顧客のためのJavaインスタンスであってもよい。サービスインスタンスは、Javaサービスなどの特定のタイプのサービスのための特定のサブスクリプションIDである。サービスインスタンスは特定の顧客に属し得るものであって、ポッド上に存在する。1つのサービスインスタンスだけがシングルテナントPOD上に存在し、複数のインスタンスは複数のテナントPOD上に存在し得る。さらに、サービスインスタンスは常にPODに存在しているが、2つのポッドにまたがることはない。他方で、サービスインスタンスは、単にPODが存在する以上のことを必要とする可能性がある。
808において、SDIモジュール206は、予めプロビジョニングされた匿名のデプロイメントを顧客特有の構成で構成することによって、顧客のために特定的にサービスインスタンスを作成することができる。例えば、SDIモジュール206は、パーソナリティインジェクション(personality injection)を用いて顧客特有の構成をPODに導入することができる。サービスプロビジョニングは特定の顧客を特定のPODに結合するプロセスである。これにより、顧客特有の構成がPODに導入される(例えばパーソナリティインジェクション)。PODは、1つ以上のテナントを同時にサポートしてもよい(シングルテナントまたはマルチテナント)。複数のテナントをサポートするPODの場合、複数のパーソナリティがPODにインジェクションされ、それぞれのパーソナリティが、サポートされた各テナントに対応し得る。
別の実施例に従うと、特定のサービスは複数のPODを用いることができる。例えば、Javaサービスが要求され得る。SDIモジュール206は予めプロビジョニングされた複数のJavaPODを有し得る。要求されたサイズのサービスに基づいて、SDIモジュール206は、要求されたサービスをサポートするために複数のPODが必要であると判断し得る。
サービスプロビジョニングおよびPODプロビジョニングのプロセスは別個のものであり、互いとは無関係であり、SDIモジュール206によって調整される。これにより、例えば、バックグラウンドにおいてPODプロビジョニングを実行することが可能となる。ポッドの予備的なプール化は、将来の需要を予想するために管理者構成可能なオプションに基づいて行われてもよい。サービスプロビジョニングは、一般に、PODプロビジョニングよりもはるかに高速であり、SDIがTASからオーダーを受取るとオンデマンドで発生する。SDIは、プール化およびレジストレーションを処理している間も、PODプロビジョニングおよびサービスプロビジョニングを調整する。
ポッドを予めプロビジョニング
いくつかの実施例に従うと、SDIによって処理される完全に自動化されたPODプロビジョニングは、TASからの要求なしにソフトウェアコンポーネントのインスタンスを作成し得る。これは、顧客オーダーに先立って実行されるバックグラウンドアクティビティであり得る。PODをゆっくりと立ち上げることができるので、PODプロビジョニングは事前に完了してしまい、このため、顧客がサービスをオーダーすると、この顧客は、オーダーを速やかに(例えば数秒以内または数分以内に)受取ることができる。PODは、1つ以上のテナントを同時にサポートし得る(シングルテナントまたはマルチテナント)。これらのプロセスは、PODプロビジョニングがバックグラウンドにおいて実行され得るように独立している。ポッドの予備的なプール化は、将来の需要を予想するために管理者構成可能なオプションに基づいている。
リソースが少なくなれば、SDIモジュール206は新しいPODを作成することができる。後に説明されるように、Min_Usedしきい値を用いることにより、SDIモジュール206は使用および割り当てをモニタリングすることができる。モニタリングに基づいて、SDIは新しいPODを予めプロビジョニングすることができる。
例えば、SDIタイマジョブが実行され、所与のサービスサイズ(ベーシック、標準、エンタプライズ)のための自由なアセンブリの数が現在の構成において規定されるMin_Usedしきい値を下回ったことをSDIモジュール206に通知すると、しきい値に達するまで追加のアセンブリを予めプロビジョニングすることができる。
図8Bは、本発明の実施例に係るクラウドインフラストラクチャシステムにおけるSDIモジュール206によって実行され得る処理を示す簡略化されたフローチャート850を示す。図8Bに示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(例えばコード、命令、プログラム)、ハードウェアまたはそれらの組み合わせで実現されてもよい。ソフトウェアは、(例えばメモリ装置、非一時的なコンピュータ読取可能記憶媒体上の)メモリに格納されてもよい。図8Bに示される特定の一連の処理ステップは、限定的であるよう意図されるものではない。他のステップのシーケンスも代替的な実施例に従って実行されてもよい。例えば、本発明の代替的な実施例は、異なる順序で上記のステップを実行してもよい。さらに、図8Bに示される個々のステップは、個々のステップに適切であるようにさまざまなシーケンスにおいて実行され得る複数のサブステップを含んでいてもよい。さらに、特定のアプリケーションに応じて、さらなるステップが追加または削除されてもよい。当業者は、多くの変更例、変形例および代替例を認識するであろう。一実施例では、図8Bに示される処理は、図6に詳細に示されるSDIモジュール206における1つ以上のモジュールによって実行され得る。
フローチャート850は、各々の予めプロビジョニングされたアセンブリのために実行することができる。アセンブリはPODの一種である。例えば、アセンブリは、作成のためにOVABによって用いられる特有の技術である。OVABはアセンブリを作成するかまたはアセンブリをデプロイする。Min_usedしきい値に達するまで、または、タイマジョブがオペレータによって中断されるまで、無期限にPODを予めプロビジョニングし続けることができる。
加えて、障害がいずれかのステップで起これば、先行するオペレーションを巻き戻すことができる。次いで、SDIモジュール206はシーケンスを再試行することができる。
852において、SDIモジュール206は、PODアセンブリを予めプロビジョニングするためにIPアドレスを獲得することができる。例えば、8つのIPアドレス(例えばFRONTENDから4つ、BACKENDから4つ)は、SDIデータベースに保存することができる。オペレーションはアトミックレベルであり得る。いくつかの例においては、システムが十分なIPアドレスを有していない場合、管理者はより多くの容量を環境に追加することができる。
854において、SDIモジュールは、バーチャル・アセンブリ・ビルダ・ホーム(例えばオラクルバーチャル・アセンブリ・ビルダ(OVAB))を作成することができる。例えば、新しいディレクトリはルート(例えばovab.virtual.root)ディレクトリ下で作成することができ、さまざまなsymlinkは、ホームディレクトリ(例えばovab.master.home)まで作成し直すことができる。ホームディレクトリは、シングルデプロイメントのためにバーチャル・アセンブリ・ビルダ・ホームとして用いることができる。これにより、ロッキング問題を起こすことなく、SDIモジュール206がバーチャル・アセンブリ・ビルダ(例えばOVAB)オペレーションを並行して実行することが可能となる。
856において、SDIモジュール206は、新しいバーチャル・アセンブリ・ビルダ(例えばOVAB)ホームにデプロイメントプラン(例えばdeploymentPlan.xml)ファイルを作成することができる。デプロイメントプランは、デプロイメントのためにバーチャル・アセンブリ・ビルダ(例えばOVAB)によってデプロイされた仮想マシン(VM)にインジェクションされることとなるIPアドレス、ネットワークファイル共有(NFS:network file sharing)マウント、およびVMブリッジ名などの、但しこれらに限定されない構成情報を含み得る。
858において、SDIモジュール206はZFSボリュームを作成することができる。ZFSは複合型ファイルシステムおよび論理ボリュームマネージャである。ZFSの特徴は、データ破損からの保護、高記憶容量のサポート、ファイルシステムおよびボリューム管理の概念の統合、スナップショットおよびコピー・オン・ライトクローン、連続的な完全性のチェックおよび自動修復を含む。例えば、3ボリューム分がデプロイメントのためにZFSファイラにおいて作成される。これらボリュームはこのデプロイメントの一部としてブートされた各々のVMに搭載される。
860において、SDIモジュール206は、アセンブリをデプロイするためのデプロイコマンド(例えば、abctl deploy)を発行し得る。例えば、デプロイコマンドはVMマネージャによって1つ〜4つのVMをブートすることができる。
862において、SDIモジュール206は、SDIデータベースにおいてアセンブリをフリーに設定することができる。例えば、SDIモジュール206は、PRE_PROV_JAVA_ASSEMBLY行のためにUSED=0を設定することができる。これは、PODアセンブリが、サービスインスタンスに割り当てられるように読み出されることを示す。
先に述べたように、PODをゆっくりと立ち上げることができるので、PODアセンブリは事前に完了し、このため、顧客がサービスをオーダーすると、この顧客は、オーダーを速やかに(例えば、数秒以内または数分以内に)受取ることができる。ポッドの予備的なプール化は、将来の需要を予想するために管理者構成可能なオプション(例えば、Min_Usedしきい値)に基づいている。
サービスインスタンスの作成
SDIモジュール206はサービスインスタンスの作成および破壊を自動化し、また、試行期間満了などの特定のビジネス活動をサポートするためにサービスインスタンスのモニタリング能力を提供する。
サービスインスタンス作成APIは、新しいシステムおよび/またはサービスインスタンスを作成するために用いることができる。サービスインスタンス作成APIは、そのシステムに属する1つ以上のサービスインスタンスとともに新しいシステムを作成するのに用いることができるか、または、既存のシステムに対する1つ以上のサービスインスタンスを作成するのに用いることができる。APIは非同期であり得る。なぜなら、APIは、実施に関する我々の決断と、解決するのに手動での介入を必要とする潜在的な障害とに応じて数分または数時間かかる長期間続くオペレーションとなる可能性があるからである。したがって、このAPIはその引数のうちの1つとしてコールバックアドレスを採用することができる。コールの即時リターン値は、単に、要求の履行期間にわたる特定のための要求を特定する要求IDであってもよい。要求の結果は、提供されるアドレスにコールバックすることによって与えることができる。コールバックが応答本体でなされると、要求によって作成されたシステムおよびサービスインスタンスは完全に操作可能となり使用の準備ができた状態になり得る。
コールバックアドレスおよびサービスオーダードキュメントはサービスインスタンス作成APIのための入力である。コールバックアドレスはオペレーションが完了したときにTASにコールバックするためのアドレスであり得る。サービスオーダードキュメントは、TASシステムによって処理されるオーダーを記述するXMLドキュメントであり得る。サービスオーダードキュメントは以下の情報を与えることができる:
・コールバックアドレス:オペレーションが完了したときにTASにコールバックするためのアドレス。
・システム名:新しいシステムまたは既存のシステムについての名前。システム名は、この値が共有のIDMインスタンス内でテナンシ名に用いられることとなるので、クラウドアーキテクチャ全体にわたって一意的であり得る。
・新しいシステムインジケータであるか:これが新システムを作成するオーダーであるかまたはサービスインスタンスを既存のシステムに追加するオーダーであるかどうかを示すブール値。
・(任意)システム管理ユーザ名:新しいシステムが作成されている場合に作成されるべきシステム/テナンシ管理者アカウントの名前。
・サービスインスタンスオーダーのリスト:1−Nシステムインスタンスオーダー。この場合、各々のシステムインスタンスオーダーは以下を含む。
−サービスインスタンス名:作成されるべきサービスインスタンスの名前。
システムインスタンス名は、所与のシステム内において一意的である。
−管理ユーザ名:このサービスインスタンスのために作成されるべきサービスインスタンス管理者アカウントの名前。
−サービスインスタンスタイプ:FA CRM、FA HCM、Java、WCC、APEXなどの作成されるべきサービスのタイプ。
−サービスインスタンスサイズ:小/中/大。全てのサービスインスタンスはここではサイズについての何らかの概念を有する。
−サービス特有のプロパティ:作成されているサービスのタイプに特有の一組のプロパティ。
サービスオーダー履行ドキュメントはサービスインスタンス作成APIのための出力であり得る。上述のように、この非同期コールからのリターン値は、その持続期間中にこの要求を追跡するために用いることができる要求idであり得る。要求に対する応答は、入力として与えられるコールバックアドレスに対してコールバックとして送ることができる。サービスオーダー履行ドキュメントは以下の情報を含むXMLドキュメントであり得る。
・要求id:元のAPIコールに同期的に戻される要求id。
・システム名:この要求によって生成または追加されるシステム名。
・(任意)システム/テナンシ管理ユーザ名および仮パスワード:この要求により新しいシステムが作成された場合、これらの値は応答の一部として返すことができる。これらの値は、要求により結果的に単に既存のシステムに新しいサービスが追加されただけであった場合には返されない可能性がある。
・(任意)システムIDMコンソールURL:この要求により新しいシステムが作成される場合、このシステムのためのIDMコンソールについてのURLを返すことができる。
・サービスインスタンスオーダーのリスト:各々のサービスインスタンスオーダーは以下を含む。
−サービスインスタンス名:作成されたサービスインスタンスの名前。
−サービスインスタンス管理ユーザ名および仮パスワード:サービスインスタンス管理アカウント情報。
−(任意)サービスインスタンス管理URL:サービスのために適用可能である場合、サービスインスタンスのための管理コンソールに対するURL。例えば、Javaサービスの場合、これは、JavaサービスのためのEMコンソールにつながるURLとなるはずである。
−サービスインスタンスURL:ユーザをそれらの新しく作成されたサービスインスタンスに導くURL。
加えて、SDIモジュール206は、サービスインスタンスを予めデプロイして関連付ける能力を有し得る。さまざまなサービスインスタンスをデプロイするのに必要な時間の長さに応じて、アセンブリがこれらのサービスのために予めデプロイされてもよい。したがって、ユーザがサービスインスタンスを要求する場合、SDIモジュール206が行うべきことは、いずれかのユーザ特有の「パーソナリティ」をアセンブリに入れてそれをユーザに返すことである。
要求フローのプロビジョニング
顧客がオーダーを要求すると、SDIプロビジョニング要求が、単一のSOAPオペレーション時にTASによって要求される。プロビジョニング要求は、1バンドルのシステム/サービス作成、読出、更新および削除(CRUD)オペレーションを含み得る。プロビジョニング要求は、その要求Idによって一意的に特定することができる。
図9はいくつかの実施例に係るプロビジョニング要求フローを示す。例えば、プロビジョニング要求は、TASモジュール204によって開始させることができる。902において、TASモジュール204は、関連するプロビジョニングSOAPオペレーション(CRUD)を呼び出し、SOAP要求を送ることによって要求idを設定することができる。904において、SOAP要求を受取ると、SDIは、HTTP202コードで応答することができ、要求を非同期的に処理し始める。加えて、906において、SDIモジュール206は、最初に、これが、要求Idによって決定され得る新しい要求であるかどうかをチェックすることができる。906でチェックすることにより、同じ要求(すなわち同じ要求Idを備えた要求)が再処理されるのを防ぐ(例えば、要求が再提出されると、アドレスに「対する応答」および「相関ID」値(TASコールバックのために用いられる)がその最新のSOAP要求の値に更新される)。
要求が新しくない場合、908において、SDIモジュール206は、(例えば既存のSDIデータベースエントリからの)要求状態をチェックする。例えば、状態が「完了している」場合、要求はそのときまでに処理できている。次いで、910において、SDIモジュール206は関連するTAS「orderCompleteCallback」を呼び出すことができる。代替的には、状態が「キャンセルされる」場合、要求はそのときまでには処理できていない。次いで、912において、SDIモジュール206は、障害情報で、関連するTAS「onFaultCallback」を呼び出すことができる。
要求が新しい場合、914において、要求が引き続き処理される。TASモジュール204は、処理がいつ完了するかを通知することができる。SDIモジュール206は要求を確認することができる。例えば、入力確認、状態確認および確認のロックなどの3つの確認カテゴリがあってもよい。916において、要求が無効であれば、SDIモジュール206は、関連する障害情報でTAS「onFaultCallback」を呼び出すことができる。
要求が有効であれば、918において、SDIモジュールは新しい要求を作成し、状態を設定して準備する。SDIモジュール206は要求の実行を開始し、実行し続ける。例えば、タスクキューにおける次のタスクが実行され、その後、次のタスクが実行されるなどして、全てのタスクが完了するまで続けられる。
920において、この要求に関連付けられる全てのタスクが実行できた場合、SDIモジュール206は、オーダーの履行により、関連するTAS「orderCompleteCallback」を呼び出すことができる。
エラーシナリオにおいては、要求が完了せず、シングルタスクが失敗した場合、要求中のそれ以降のタスクが実行されない可能性がある。922において、SDIモジュール206は、エラーが回復可能であるかどうかを判断することができる。924において、エラーが回復不可能である場合、要求状態がキャンセルされた状態に変更され、SDIモジュール206は、関連する障害情報でTAS「onFaultCallback」を呼び出すことができる。加えて、SDIモジュール206は、内部エラーキューにエントリを追加することができる。このキューは、ダッシュボードを更新して管理者に警告電子メールを送るために、EMモジュール208によってポーリングされることとなる。926において、エラーが回復可能である場合、SDIモジュール206は、状態を一時停止状態に変更し、その状態から停止された状態に変更することができる。加えて、SDIモジュール206は、内部エラーキューにエントリを追加することができる。このキューは、ダッシュボードを更新して管理者に警告電子メールを送るために、EMモジュール208によってポーリングされることとなる。
サービスについての新しい要求がSDIモジュール206によって受取られて確認されると、SDIモジュール206が要求されたサービスをプロビジョニングする。図10は、いくつかの実施例に係るプロビジョニング例の詳細なフローを示す。プロビジョニングプロセスはSDIモジュール206によって管理される。
例えば、TASは、BPELプロセス内からシステムプロビジョニングモジュールと統合することができる。具体的には、システムプロビジョニングインターフェイスを非同期的なSOAPベースのWebサービスコールとして公開することができ、さまざまなライフサイクルオペレーションのためのTAS BPELプロセスが直接システムプロビジョニングエンドポイントをコールしてプロビジョニングタスクを実行することができる。
加えて、システムプロビジョニングは、コールバックAPIを用いて、成功についての結果をBPELプロセスに送信することができるか、または、オペレーションが障害のために失敗したことをBPELプロセスに通知することができる。コールバックを受取ると、BPELプロセスは、その結果を用いてその通常のフローを継続するか、または障害を処理する障害ポリシーに従う。
Javaサービスおよびデータベースサービスのプロビジョニング例
図10は、顧客のためにJavaサービスおよびデータベースサービスをともにプロビジョニングするエンド・ツー・エンドフローを示す。例えば、1050において、顧客は試験的なサブスクリプションをオーダーすることができる。クラウドUIを用いる顧客は、サインアップしてJavaサービスを無料で試用することができる。クラウドUIは、PLSQLコールを行ってオーダーを提出することができる。この場合、このコールは、Javaサービスサブスクリプションおよびデータベースサービスサブスクリプションを含む2つの異なるサブスクリプションのためのものであってもよく、PLSQLを介してTASモジュール204に提出され得る。
1055において、オンボードを開始することができ、TASモジュールはテナントコールを作成することができる。テナントにおいて、サービスタイプおよびサイズがパスされ得る。この例においては、オーダーがJavaおよびデータベースサービスのためのものあるので、2つのタイプが存在し得る。トライアル用の対応するサイズは等しく小さいものであってもよい。代替的には、オーダーが支払済みオーダーであった場合、サイズがより大きくてもよい。作成テナントコールはプロビジョニングのためのSDIモジュール206に渡される。
1060において、ローカルの候補マシンのループコールにより、SDIモジュール206が利用可能なリソースを参照して、場合によっては、予めプロビジョニングされたPODを見つけることを可能にする。サービスタイプに応じて、リソースは予めプールされて、既に大部分がセットアップされていた可能性がある。代替的には、サービスが予めプロビジョニングされていなかった場合、SDIモジュール206は要求されたサービスをプロビジョニングするために最初から始めなければならないかもしれない。例えば、Javaサービスの場合、SDIモジュール206は、PODを予めプロビジョニングすることをサポートすることができる。この場合、仮想マシンを作成し、これらを立ち上げる作業は全て事前に終わっている。したがって、顧客要求を受取ると、SDIモジュール206は、単に、パーソナリティインジェクションというより小さなステップを有するだけとなる。パーソナルインジェクションは、ランタイムで、予めプロビジョニングされたPODを特定の顧客のための構成でカスタマイズすることを含む。データベースサービスのために、SDIモジュール206は顧客フットプリントをオンデマンドで作成することができる。他方では、顧客フットプリントは、データベースサービスが既存のデータベース内のスキーマを用いているので、極めて仮想的なフットプリントになり得る。フュージョンアプリケーションの場合、パーソナリティインジェクションは、特定の顧客の詳細と一致させるために構成を接続し直すことを含み得る。この例においては、SDIモジュール206は、Javaサービスのために予めプロビジョニングされた既存のVMを選択し得るか、または、新しいJavaサービスをプロビジョニングし得るが、これは、新しいVMを立ち上げるために十分なリソースを有するラックの選択を含む。
1065においては、SDIモジュール206はレジストリを更新し得る。SDIモジュール206は、基礎をなす仮想マシンマネージャおよび仮想マシンプールを追跡し続けるために物理的なハードウェアリソースをオンボードで記録することができる。加えて、SDIモジュールは、作成されたアセンブリおよびVMを全て追跡し続けることができ、かつ、それらが、例えば、特定の顧客サブスクリプションに結合される顧客またはアセンブリには割り当てられていない匿名のアセンブリであるかどうかを追跡し続けることができる。
1070において、ビルドIDはオンボード層に戻っていく。これにより、特定の要求のためにシステムまたはサービスが作成されていることをTASモジュール204に通知することができる。TASモジュールは、プロビジョニングが完了しているかどうかを非同期的に判断することができる。1075において、TASモジュール204は、SDIモジュール206をポーリングし、特定の要求が完了しているかどうかをチェックすることができる。代替的には、TASモジュール204による非同期的なSOAP要求により、TAS204がコールバックを待っている場合に要求が完了しているかどうかを判断することもできる。
1080において、SDIモジュールは、API(例えばOVAB Java API)を用いて、ウェブロジックサーバ(WLS)アセンブリをデプロイすることができる。例えば、OVABは、アセンブリにおいて個々のVMを作成するために、内部でVMマネージャにコールすることができる。加えて、OVABは、全体的なWLSドメイントポロジーをVMにサポートさせるために、複数のVMをインターフェイスするための複数のVMがある場合に追加のロジックを有することができる。1080および1085において、SDIモジュール206は、WLSマシンプールおよびDBマシンプールを作成することができる。WLSアセンブリが実際にデプロイされて、VMマネージャを介して、さらにOVABを介して戻すことができれば、SDIモジュールは匿名のアセンブリが作成されたと判断することができる。
加えて、匿名のアセンブリはNuviaqベースのパーソナリティインジェクションに組込むことができる。例えば、SDIモジュール206は、Nuviaqコネクタをコールし、物理的な詳細および顧客特有の詳細を渡して、Nuviaqが実行中のVMに対してランタイムコールを行えるようにすることができる。Nuviaqは、顧客特有の情報(例えば、顧客によって選択された、URLへのアイデンティティドメイン名)と一致させるためにウェブロジックドメインを再構成することができる。
1085において、SDIモジュール206はデータベースサービスをプロビジョニングすることができる。例えば、データベースサービスは、Exadataハードウェア上に予め構成することができるExadataハードウェア・データベース・インスタンスによって支援され得る。図12にさらに記載されるように、各々のインスタンスは多くの顧客をサポートすることができる。SDIモジュール206は、DBサービス自体にExadataを登録し、ExadataPODを管理することができる。さらに、SDIモジュール206は、APEXコネクタを用いて、データベースサービスをプロビジョニングすることができる。APEXはデータベースの上にあるアプリケーション・エクスプレス・プログラミング・エンジンである。SDIモジュール206は、データベースをプロビジョニングするために、データベースサービスのサイズ、顧客アイデンティティドメイン名などの関連情報をAPEXコネクタに渡すことができる、次いで、APEXコネクタは、実行中に顧客のために追加のスキーマおよびテーブル領域を割り当てることができる。加えて、特定のExadataマシンは、負荷、サイジングなどに基づいて選択されてもよい。実際のスキーマは、スキーマに対する接続情報を含み得るSDIモジュール206に戻される。SDIモジュール206は、ランダムなクレデンシャルを生成し、このクレデンシャルをTASモジュール204に返す。
1090において、SDIモジュール206はソフトHTTPサーバ(例えばOHS)の再始動を開始させることができる。SDIモジュール206は、OHSのソフトな再始動を必要とし得る特有の顧客のために特有の結合でもって構成ファイルを動的に生成し得る。ソフトな再始動により、全てのインフライト要求が再始動前に完了することを可能にする。OHSが再開されると、ルーティング層を介するPODへのインバウンド・トラフィックが実現可能となる。
1095において、要求されたサービスおよび生成されたパスワードのために、応答が、URLでもってTASモジュール204に送り返される。パスワードは、サービス管理者であってもよく、または、サービス環境にアクセスするための電子メールを介して顧客に与えることができるアイデンティティドメイン管理者パスワードであってもよい。
Javaクラウドサービスインスタンスをプロビジョニングするサービス
図11Aは、一実施例に係るJavaクラウドサービスインスタンスのプロビジョニングを示す。JavaクラウドサービスインスタンスのプロビジョニングはJavaサービスプロビジョニング制御(JSPC:Java Service Provisioning Control)によって実行することができる。例えば、プロビジョンプラットフォームインスタンス使用事例は、制御APIをプロビジョニングするJavaサービスの作成プラットフォームインスタンスオペレーションによって実現することができる。パブリッククラウドの文脈においては、JavaクラウドサービスインスタンスはJSPCプラットフォームインスタンスに対応する。プラットフォームインスタンスには、このインスタンスに関する以降の全オペレーションに対して用いることができる固有の識別子が割り当てられる。
作成プラットフォームインスタンス動作に対して提供されるプラットフォームデプロイメント記述子は、テナントのサブスクリプション要件を満たすためにプラットフォームインスタンスの構成を変更するプロパティを設定することを可能にする。プロパティは以下の目的のために用いることができる:サブスクリプションタイプ/サイズを規定する(サブスクリプションタイプ/サイズは、サーバの数、データベース限度およびサービス設定の質に影響を及ぼす可能性がある);これがトライアルサブスクリプションであるか否かを示す;このウェブロジックサービスインスタンスに関連付けられるべきCRMサービスを特定する。
一実施例に従うと、SDIモジュール206は構成マネージャとして連続的な統合サーバ(例えばハドソン)を用いることができる。連続的な統合サーバは、ビルドおよびデプロイメントを自動化することを可能にする。加えて、連続的な統合サーバは、ユーザがリソース利用を向上させ、メンテナンス・オーバーヘッドを低減させ、突然のシステム負荷スパイクに自動的に応答することができるように、クラウドサービスおよび仮想化技術とのインターフェイスを可能にし得る。
図11Bは、一実施例に係るJavaクラウドサービスインスタンスのプロビジョニングおよびフュージョンアプリケーションの関連付けのためのさまざまなインタラクションの高レベル概略図を示す。Javaサービスのプロビジョニングは、顧客またはテナントの要件に基づいてVMをパーソナライズし得るプロセスであり得る。図11Bに示されるように、JavaサービスはフュージョンアプリケーションSaaS環境を拡張させることができる。
図11Bは、匿名のアセンブリがテナントの個別化情報でどのようにハイドレートされるかを説明する。例えば、JavaサービスVM画像はOVABアセンブリとして提供することができる。このようなアセンブリのデプロイメントにより、結果として、匿名のインスタンスが得られる。図8Bにおいて言及されるように、SDIモジュールはサービスの匿名のインスタンスを予めプロビジョニングすることができる。匿名のインスタンスはライブのVMであるが、いずれのテナントにも関連付けられていない。先に記載されたように、SDIモジュール206は、テナント環境またはサービスインスタンスを作成するプロセスを促進するために匿名のVMを予めプロビジョニングすることができる。
1101において、TASモジュール204は、Javaサービスについてのテナント要求をSDIモジュール206に送ることができる。1102において、SDIモジュール206は、アセンブリ・ビルダ・コネクタを介してアセンブリ・ビルダに対して匿名のアセンブリを要求することができる。1103において、アセンブリ・ビルダは、OVMを用いて、匿名のアセンブリをデプロイすることができる。1104において、匿名のアセンブリがSDIモジュール206に送られる。1105において、SDIモジュール206はIDMコネクタを介してIDMスライスを作成することができる。1106において、IDMはSDIモジュール206にIDM座標を返すことができる。1107において、SDIモジュール206は、データベースコネクタを介してデータベーススライスを作成することができる。1108において、データベースはSDIモジュール206にデータベース座標を返すことができる。いくつかの例においては、データベースはAPEXデータベースサービスであってもよい。
1109において、SDIモジュール206は、Nuviaqコネクタを介して、受取られたIDM、データベースおよびEM座標でJavaサービスを構成するよう要求することができる。1110において、Nuviaqは、Nuviaqデータベースに全てのサービスインスタンスデータを格納することができる。1111において、Nuviaqは、EMエージェントの開始をも含み得るJavaサービスインスタンスを構成することができる。いくつかの例においては、NuviaqはJavaサービスオーケストレータであってもよい。
さらに、フュージョンアプリケーション(FA:Fusion application)SaaS環境を用いる場合、JavaサービスをFA SaaSテナントに従って適切にプロビジョニングすることが必要になる可能性がある。したがって、図11Bに記載されたプロビジョニングプロセスでは、アイデンティティ管理に関するいくつかの相違の原因を明らかにしなければならないかもしれない。
典型的なクラウドPaaS(例えばJavaサービス、データベースサービス)プロビジョニング環境においては、全てのテナントに対処する単一の共有IDMがあってもよい。各々のテナントのセキュリティ情報は、他のテナントから隔てておくことのできるIDMストライプ(例えばアイデンティティドメイン)で分離させることができる。FA SaaSの場合、IDMが異なっていてもよく、各々のSaaSインスタンス専用とされてもよい。したがって、JavaサービスおよびFAサービスを統合すると、シングルサインオンのような機能をサポートするためにIDM同士の間にインタラクションを存在させることが必要となる可能性がある。
いくつかの実施例に従うと、関連付けられたサービスのプロビジョニング中、SDIモジュールは、SaaSサービスとPaaSサービスとの間で共有のIDMを用いることができる。SaaSサービスとPaaSサービスとの間の共有のIDMに基づいて、以下にサポート可能な使用事例を示す:FAウェブサービスと統合されるJavaクラウドサービスにおけるパートナー/顧客構築アプリケーション;FAに埋め込まれたユーザインターフェイスを有するJavaクラウドサービスにおけるパートナー/顧客構築アプリケーション;テストインスタンスおよび生成インスタンスによる影響;テストインスタンスと生成インスタンスとの間のマイグレーション;オンプレミスとのユーザの統合;ならびに、他のユーザのためのクラウド・アイデンティティ・ストアを用いた、何人かのユーザのためのオンプレミスとの実際のユーザの統合。
図11Cは、本発明のいくつかの実施例に係るPaaSおよびSaaSサービス関連付けプロセスを示す。PaaS(例えばJava)サービスおよびSaaS(例えばFA)サービス関連付けプロセスは、PaaS環境ハイドレーションを含み得る。例えば、JavaサービスPaaS環境は、プロビジョニング中に呼び出されるハイドレーションスクリプトを含み得る。スクリプトは、PaaSドメインなどを構成するようなさまざまなタスクを実行することができる。タスクは、PaaSインタラクションおよびSaaSインタラクションを可能にするようファイアウォールルールを変更すること;認証サーブレットフィルタに必要な変更を調査すること;ハイドレーション中に実行するのに必要なフックをパペットリポジトリに追加すること;共有されるIDM統合;ならびに、ウェブサービス構成変更;を含み得る。
データベースクラウドサービスをプロビジョニングするサービス
図12は、いくつかの実施例に係るデータベースクラウドサービスの高レベル論理図を示す。クラウドデータベースサービスはSDIモジュール206によってプロビジョニングすることができる。データベースクラウドサービスは3つの主要なコンポーネントを有し得る:単純なURIによってデータベースクラウドサービスにおけるデータにアクセスすることを可能にするウェブサービスアクセス;ブラウザベースの環境において多種多様なアプリケーションを全て作成およびデプロイするためのアプリケーション・エクスプレス;ならびに、(例えば数クリックだけで)容易にインストールすることができる一組のビジネス生産能率アプリケーション。
マルチテナントに共有されるアーキテクチャのいくつかの主要な属性は以下を含み得る:各々のテナントは完全に切離されたスキーマを獲得する;各々のExadata演算ノードは複数のデータベースインスタンスを有する;各々のインスタンスは複数のスキーマ(例えばテナント)を有する;各々のスキーマ/テナントは、表、ビュー、格納されたプロシージャ、トリガを含むデータベースオブジェクトを管理できる容器である;各々のスキーマは1つの専用の表領域を有する;各々の表領域は1つのデータファイルを有する。
図7Eと同様の図12は、同じ物理的なマシン内に複数の演算ノード(例えば、EXADATA演算ノード1202、EXADATA演算ノード1204)を有する例を示す。加えて、データベースインスタンス1206は各々の演算ノード内に常駐することができる。さらに、2つの別個のスキーマ(例えばスキーマ1208、スキーマ1210)は各々のデータベースインスタンス1206内に含めることができる。別の実施例に従うと、3つ以上のスキーマを1つのデータベースインスタンスに含めることができる。各々のスキーマ(例えばスキーマ1208、スキーマ1210)は異なる顧客のためのものであってもよい。したがって、いくつかの実施例においては、別々の顧客に関連付けられる複数のスキーマは同じデータベースインスタンス内に常駐することができる。
このデータベース実現例においては、一人の顧客だけが各々のデータベースインスタンス内に常駐することができる。したがって、複数の顧客は複数のデータベースインスタンスを必要とする。代替的には、本発明の実施例に従うと、複数のスキーマが1つのデータベースインスタンスに含まれているので、データベースインスタンスは複数の顧客の間で共有することができる。各々のスキーマはテナントを表わすことができ、このため、1つのデータベースインスタンスは複数のテナントを有することができる。
例えば、フュージョンアプリケーションおよびJavaサービスはシングルテナントサービスである。シングルテナントサービスは一人の顧客に割り当てられる。データベースサービスはマルチテナントサービスである。データベースサービスのためのPODはラックについての2、3個のデータベースインスタンスを備えたExadataラックである。この場合、多くの顧客が1つのPODを用いることができる。したがって、PODが複数の顧客を有することができるので、データベースサービスはマルチテナントサービスとなる。これにより、PODを一度セットアップし、次いで、SDIモジュール206によるランタイムプロビジョニングを行って、ランタイムで複数のテナントをPODに追加することが可能となる。
図13は、いくつかの実施例に係るマルチテナントデータベースサービスのためのサービスプロビジョングフロー1300を示す。図12に示されるように、データベースサービスはマルチテナントサービスの一例である。というのも、1つのデータベースインスタンスが、異なる顧客に関連付けられた複数のスキーマを有し得るからである。
1302において、顧客は、トライアルサービスに関してクラウドUI212にデータベースサービスを要求する。代替的には、顧客は、支払済みのサービスに関してストアUI210にデータベースサービスを要求することができる。1304において、クラウドUI212がTASモジュール204に顧客要求を送る。1306において、TASモジュール204は、BPELを介してSDIモジュール206をコールすることによってプロビジョニングを開始することができる。いくつかの例においては、サービスが利用可能である場合にのみTASモジュール204はプロビジョニングを開始することができる。1308において、SDIモジュール206は、要求している顧客に関するスキーマを関連付けるためにCLOUD_UIにおけるPLSQL APIをコールすることができる。1310において、関連付けが成功した後、SDIモジュール206はTASモジュール204に通知することができ、TASモジュール204は(例えば電子メールで)顧客に通知することができる。その後、顧客はウェブサーバにログインし、データベースサービスを始動させる。
別の実施例に従うと、フュージョンアプリケーションのためのサービスプロビジョニングが実現され得る。例えば、新しいフュージョンアプリケーションサブスクリプションオーダーはSDIモジュール206によって受取られる。オーダーが承認されると、フュージョンアプリケーションPODがプロビジョニングされる。顧客(例えばテナント)は、テナントをそのポッドにおいてセットアップできるようにするための重要な情報を提供する。初期のユーザが作成されると、フュージョンアプリケーションクラウドサービスは、初期のユーザにユーザIDおよびパスワードを電子メールで送る。さらに、割り当てポッドにプロビジョニングするテナントは、オンプレミスの顧客が採用するであろう標準的なセットアッププロセスのサブセットである。
図15は、本発明の実施例に係る予めプロビジョニングされたポッド1500の物理的アーキテクチャを例示する。図15に示されるように、複数のポッドは、クラウドインフラストラクチャによって提供される1つ以上のサービスのために予めプロビジョニングされてもよい。例えば、図15に示されるように、一組のポッド1505は、JAVAサービスのために予めプロビジョニングされてもよく、一組のポッド1510はデータベースサービスのために予めプロビジョニングされてもよい。
上述のように、ポッドは、特定のサービスを提供するためにともに有線接続されているリソース(例えば、処理リソース、ネットワーキングリソース、メモリリソース)のモジュールアセンブリである。例えば、図15に示されるように、予めプロビジョニングされたポッド1500は、Javaサービス1505のための1つ以上の仮想マシン(例えばオラクル仮想マシン(OVM))および1つ以上のデータベースリソース1510(例えばオラクルExadataデータベース)を論理的にグループ分けしたものであり得る。データベースリソースはストレージ、インフラストラクチャおよびネットワークコンポーネントを含んでもよい。予めプロビジョニングされたポッドは、シングルテナンシサービスまたはマルチテナンシサービス用に構成されてもよい。
ポッドは、当該ポッドが用いられるであろうサービスを要求するサブスクリプションオーダーを受取る前に作成されるので、予めプロビジョニングされているものと見なされる。一実施例においては、特有のサービスのために、各々の予めプロビジョニングされたポッドは、一定のポッドサイズまたは一組のリソース、例えば、一定数の仮想マシン、管理されたサーバ、およびデプロイされたサーバなどを有し得る。1つのサービス用に予めプロビジョニングされたポッドは別のサービス用に予めプロビジョニングされたポッドとは異なる可能性がある。これは、1つのサービス(例えばJAVAサービス)を提供するのに用いられるリソースのタイプおよび数が、別のサービス(例えばデータベースサービス)を提供するのに用いられるリソースのタイプおよび数とは異なる可能性があるからである。例えば、JAVAサービス用に予めプロビジョニングされたポッド1505は互いに似ている可能性があるが、これらはデータベースサービス用に予めプロビジョニングされたポッド1510とは異なる可能性がある。
クラウドインフラストラクチャシステム100は、予めプロビジョニングされたポッド1500のプールを作成し得る。このようなポッドを作成することにより、サービスについての顧客からのサブスクリプションオーダーに応答してリソースをプロビジョニングするのに必要な処理の量を低減させる。これにより、サブスクリプションオーダーで要求されたサービスのためのリソースをプロビジョニングするのに必要な時間の量を低減させる。サービスについての顧客のサブスクリプションオーダーに応答して顧客用の新しいサービスインスタンスを作成するのに必要な時間を短縮させる。
サービスを要求する顧客からオーダーを受取ると、クラウドインフラストラクチャシステム100は、そのサービスのために予めプロビジョニングされたポッドの予めプロビジョニングされたプールから1つ以上のポッドを用いることができる。いくつかの実施例においては、サービスオーダーに応答して、そのサービス用の予めプロビジョニングされたポッドが選択され、次いで、顧客特有の情報(例えば、顧客オーダーから決定された顧客特有の情報)がインジェクションされて、顧客用のカスタマイズされたポッドが作成されるようにしてもよい。顧客のために、新しいサービスインスタンスが、このようなカスタマイズされたポッドのうち1つ以上のポッドから作成されてもよい。
特定のサービス要求のために選択されかつ顧客用にカスタマイズされたサービス特有の予めプロビジョニングされたものの数は、要求されたサービスのサイズに左右される可能性がある。いくつかの実施例においては、サービス要求に割り当てられた予めプロビジョニングされたポッドの数が、要求されたサービスのサイズに正比例する。さらに、顧客の要求が大きくなる(例えば、テナントサービスレベル合意(SLA:service level agreement)要件が増大する)と、追加の予めプロビジョニングされたポッドが選択されて、顧客に割り当てられ(すなわち、顧客のためにカスタマイズされ)得る。
サービスについての新しいオーダーが受取られて処理されると、および/または、顧客サービス要件が増大すると、ますます多くの予めプロビジョニングされたポッドがそれらのオーダーのためにカスタマイズされ得る。これにより、そのサービスのためのポッドのうち予めプロビジョニングされた利用可能なプールにおけるポッドの数が激減する可能性がある。一実施例においては、クラウドインフラストラクチャシステム100は、予めプロビジョニングされたポッドの数がサービスについての一定のユーザ構成可能な最小しきい値を下回ると、バックグラウンドにおいてそのサービスのための新しい予めプロビジョニングされたポッドを作成するように構成されてもよい。このようなしきい値は、クラウドインフラストラクチャシステム100によって提供されるさまざまなサービスのために定義され得る。
図16は、本発明の実施例に係るサービスインスタンス作成のための予めプロビジョニングされたポッドの顧客特有のカスタマイズ(顧客パーソナリティの割り当て(customer personality assignment)と称されることもある)の例を示す。例えば、サブスクリプションオーダーは、JAVAサービスおよびデータベースサービスを要求する顧客「弊社」から受取られていてもよい。オーダーに応答して、クラウドインフラストラクチャシステム100は、「弊社」が要求した要求済みJAVAサービスを提供するためにJavaインスタンスを作成するのに単一の予めプロビジョニングされたJAVAサービスポッドが必要であると判断し、同様に、要求されたデータベースサービスを提供するためにデータベースサービスインスタンスを作成するのに単一の予めプロビジョニングされたデータベースサービスポッドが必要であると判断し得る。図16に示されるように、JAVAサービスのための予めプロビジョニングされたポッドのプール1505からの予めプロビジョニングされたポッド(予めプロビジョニングされたJAVAポッド#1)が選択され、顧客「弊社」によって要求されるようにJAVAサービスを提供するために顧客「弊社」に割り当てられた。加えて、データベースサービスのための予めプロビジョニングされたポッドのプール1510からの予めプロビジョニングされたポッド(予めプロビジョニングされたDBポッド#1)が選択され、顧客「弊社」によって要求されるように、データベースサービスを提供するために顧客「弊社」に割り当てられた。予めプロビジョニングされたJAVAポッド#1は、JAVAサービスのために顧客用にパーソナライズされたポッド#1 1605を作成するために「弊社」特有の情報(例えば構成情報)をポッドにインジェクションすることによって、顧客「弊社」用にパーソナライズされた。このような態様で、顧客「弊社」にJAVAサービスを提供するように構成されたJAVAサービスインスタンスが、予めプロビジョニングされたJAVAサービスポッドを用いて作成され得る。データベースサービスに関して、予めプロビジョニングされたDBポッド#1は、データベースサービスのために顧客用にパーソナライズされたDBポッド#1 1610を作成するために、「弊社」特有の情報(例えば構成情報)をポッドにインジェクションすることによって、顧客「弊社」用にパーソナライズされた。このような態様で、顧客「弊社」のためのデータベースサービスを提供するように構成されたデータベースサービスインスタンスが、予めプロビジョニングされたデータベースサービスポッドを用いて作成され得る。
図17は、一実施例に係る、予めプロビジョニングされたポッドを用いてパーソナライズされたJAVAサービスポッドまたはサービスインスタンスおよびパーソナライズされたデータベースサービスポッドまたはインスタンスを作成するための方法の例を示す。
いくつかの実施例においては、ポッドを予めプロビジョニングする場合、SDIモジュール206によって実行されてもよい。例えば、SDIモジュール206は、事前にリソースを保存して有線接続する(例えば、仮想マシンを作成して立ち上げる)ことによって、予めプロビジョニングされた各々のJAVAサービスポッドを作成するように構成されてもよい。次いで、予めプロビジョニングされたJavaサービスポッドのこのプールは、顧客が要求したJAVAサービスを提供するための顧客特有のサービスインスタンスを作成するために、SDIモジュール206によって用いられてもよい。顧客サービス要求を受取ると、SDIモジュール206は、これらの予めプロビジョニングされたポッドを用いて、顧客特有のパーソナリティをこれらポッドにインジェクションすることによってこれらポッドを顧客特有のものにする。パーソナリティインジェクションは、ランタイムで、予めプロビジョニングされたポッドを特定の顧客特有の構成情報でカスタマイズすることを含み得る。データベースサービスのために、SDIモジュール206は顧客フットプリントをオンデマンドで作成することができる。
一実施例においては、図17に示されるように、1705において、TASモジュール204はSDIモジュール206にサービスオーダードキュメントを提出し得る。先に述べたように、サービスオーダードキュメントは、コールバックアドレス;システム名;新しいシステムインジケータについてのブール値;システム管理者ユーザ名;およびサービスインスタンスオーダーのリストなどの情報を含み得る。サービスインスタンスオーダーのリストはさらに、サービスインスタンス名;管理者ユーザ名;サービスインスタンスタイプ;サービスインスタンスサイズ;サービス特有のプロパティを含み得る。図16に示された例に関して、サービスオーダードキュメントにおける要求されたサービスインスタンスタイプは、JAVAサービスインスタンスおよびデータベースサービスインスタンスであってもよい。
1710において、サービスオーダードキュメントを受取った後、SDIモジュール206は、サービスオーダードキュメントにおいて規定された要件を満たすのに必要な予めプロビジョニングされたポッドの数を決定し得る。一実施例においては、この決定は、サービスインスタンスタイプ、サービスインスタンスサイズおよびサービス特有のプロパティに基づいてなされ得る。
1715において、サービスオーダードキュメント内のデータに基づいて、SDIモジュール206は、顧客のためにパーソナライズされたサービスインスタンスを作成するために、SDIコネクタモジュール612を用いて、予めプロビジョニングされたポッドのうち1つ以上のポッドをカスタマイズし得る。予めプロビジョニングされたポッドのカスタマイズは、顧客オーダーから受取ったパーソナリティ情報(例えば、コールバックアドレス、システム名、システム管理者ユーザ名)を予めプロビジョニングされたポッドにインジェクションすることを含み得る。
この例においては、サービスオーダードキュメントに基づいて、特有のSDIコネクタモジュール612は、データベースサービスインスタンス1610を作成するためのAPEXコネクタ614およびJAVAサービスインスタンス1605を作成するためのNUVIAQコネクタ620であってもよい。
1720において、パーソナライズされたサービスインスタンス(例えば、JAVAサービスインスタンス1605、データベースサービスインスタンス1610)が作成されると、SDIモジュール206はTASモジュール204にサービスオーダー履行ドキュメントを提出し得る。先に述べたように、サービスオーダー履行ドキュメントはXMLドキュメントであってもよく、このXMLドキュメントは、要求識別子;システム名;システム/テナンシ管理者ユーザ名およびパスワード;システムIDMコンソールURL;ならびに、オーダーされたサービスのリストを含み得る。さらに、各々のオーダーされたサービスに関して、サービスオーダー履行ドキュメントは、サービスインスタンス名;サービスインスタンス管理者ユーザ名およびパスワード;サービスインスタンス管理URL;サービスインスタンスURLを含み得る。
図14は、本発明の実施例に従って使用され得る演算システム1000の簡略ブロック図である。例えば、クラウドインフラストラクチャシステム100は、1つ以上の演算装置を備えていてもよい。図14に示されるシステム1000は、1つのこのような演算装置の一例であってもよい。バス1024を介して電気的に結合され得るハードウェア要素を備えるコンピュータシステム1000が示されている。コンポーネントは、1つ以上の処理ユニット1002、入力サブシステム1004、出力サブシステム1006、記憶装置1008、コンピュータ読取可能記憶媒体1010に接続されたコンピュータ読取可能記憶媒体リーダ1012、通信サブシステム1014、処理加速サブシステム1016、およびワーキングメモリ1018を含み得る。
バスサブシステム1024は、所期のとおり、さまざまなコンポーネントとコンピュータシステム1000のサブシステムとを互いに通信させるための機構を提供する。バスサブシステム1024は単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施例は複数のバスを利用してもよい。
入力サブシステム1004は、マウス、キーボード、ポインティング・デバイス、タッチパッドなどの1つ以上の入力装置を含み得る。概して、入力サブシステム1004は、コンピュータシステム1000に情報を入力するためのいかなる装置または機構をも含み得る。
出力サブシステム1006は、コンピュータシステム1000から情報を出力するための1つ以上の出力装置を含み得る。出力装置の例は、表示装置、プリンタ、投影装置などを含むが、これらに限定されない。概して、出力サブシステム1006は、コンピュータシステム1000から情報を出力するためのいかなる装置または機構をも含み得る。
処理ユニット1002は、1つ以上のプロセッサ、プロセッサの1つ以上のコア、これらの組み合わせなどを含み得る。いくつかの実施例においては、処理ユニット1002は、汎用の主要プロセッサ、ならびに、1つ以上の専用コプロセッサ、例えば、グラフィックスプロセッサ、デジタル信号プロセッサなどを含み得る。いくつかの実施例においては、いくつかまたは全ての処理ユニット1002は、特定用途向け集積回路(ASIC:application specific integrated circuit)またはフィールドプログラマブルゲートアレイ(FPGA:field programmable gate array)などのカスタマイズされた回路を用いて実現することができる。いくつかの実施例においては、このような集積回路は、回路自体に格納される命令を実行する。他の実施例においては、処理ユニット1002は、ワーキングメモリ1018または記憶装置1008に格納された命令を実行することができる。さまざまな実施例においては、処理ユニット1002は、さまざまなプログラムまたはコード命令を実行することができ、同時に実行される複数のプログラムまたはプロセスを維持することができる。如何なる所与のときにも、実行されるべきプログラムコードのうちのいくつかまたは全ては、システムワーキングメモリ1018、記憶装置1008内および/またはコンピュータ読取可能記憶媒体1010上に常駐し得る。適切なプログラミングによって、処理ユニット1002は、イベントストリーム関連の処理を実行するために上述のさまざまな機能を提供することができる。いくつかの実施例においては、コンピュータシステム1000はまた、デジタル信号プロセッサ(DSP:digital signal processor)、専用プロセッサなどを含み得る処理加速ユニット1016を含んでもよい。
記憶装置1008は、ディスクドライブ、光学記憶装置、およびソリッドステート記憶装置、例えば、プログラム可能、フラッシュ更新可能などであり得るランダムアクセスメモリ(RAM:random access memory)および/またはリードオンリメモリ(ROM:read-only memory)などの記憶装置を含んでいてもよい。上述の機能を提供するよう処理ユニット1002によって実行されるソフトウェア(プログラム、コードモジュール、命令)が記憶装置1008に格納されてもよい。記憶装置1008はまた、本発明の実施例に従って用いられるデータを格納するためにリポジトリを提供し得る。
さらに、コンピュータ読取可能記憶媒体リーダ1012は、ともに(および任意に、記憶装置1008と組み合わせて)一時的および/またはより永久的にコンピュータ読取可能な情報を含むためのリモートの、ローカルの、固定されたおよび/または取外し可能な記憶装置プラス記憶媒体を包括的に表わすコンピュータ読取可能記憶媒体1010に接続可能である。
通信システム1014は、ネットワークおよび/またはその他のコンピュータとデータを遣り取りすることを可能にし得る。通信サブシステム1014は、コンピュータシステム1000のうち他のシステムに対するデータの受信および送信のためのインターフェイスとしての役割を果たす。この通信は、有線プロトコルまたは無線プロトコルを用いて提供され得る。例えば、通信サブシステム1014は、コンピュータ1000がインターネットを介してクライアントデバイスに接続することを可能にし得る。通信サブシステム1014は、モデム、ネットワークカード(無線または有線)、赤外線通信装置、GPS受信機などを含み得る。
ワーキングメモリサブシステム1018は、プログラム実行中に命令およびデータを格納するためのメインランダムアクセスメモリ(RAM)と、一定の命令が格納されるリードオンリメモリ(ROM)とを含むいくつかのメモリを含み得る。オペレーティングシステム1020、および/または、(クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、RDBMSなどであり得る)アプリケーションプログラムなどの他のコード1022などのソフトウェア要素はワーキングメモリ1018に格納されてもよい。例示的な実施例では、ワーキングメモリ1018は、実行可能なコードと、上述のとおりイベントを処理し、可変期間のウインドウ処理を可能にするために使用される関連付けられたデータ構造(キャッシュなど)とを含んでいてもよい。
コンピュータシステム1000の代替的な実施例は、上記のものからの多数の変更例を備えたコンポーネントを多少とも有し得ることが理解されるべきである。例えば、カスタマイズされたハードウェアも使用されてもよく、および/または、特定の要素がハードウェア、(アプレットなどの高移植性ソフトウェアを含む)ソフトウェアまたはそれら両方で実現されてもよい。さらに、ネットワーク入力/出力装置などの他の演算装置への接続が利用されてもよい。
図18は、本発明の実施例に係る電子デバイス1800の簡略化されたブロック図である。電子デバイス1800は、第1のリソースアセンブリセット作成ユニット1802を含む。第1のリソースアセンブリセット作成ユニット1802は、1つ以上の演算装置を含むクラウドインフラストラクチャシステムによって提供される複数のクラウドサービスから第1のサービスのための1つ以上のリソースアセンブリの第1の組を作成するように構成される。リソースアセンブリの第1の組における各リソースアセンブリは、第1のサービスを提供するための1つ以上のリソースを含む。電子デバイス1800はさらに受取ユニット1804を含む。受取ユニット1804は、作成後、顧客からサブスクリプションオーダー情報を受取るように構成される。サブスクリプションオーダー情報は、顧客特有の構成および第1のサービスのためのオーダー要求を含む。電子デバイス1800はさらに第1のリソースアセンブリ選択ユニット1806を含む。第1のリソースアセンブリ選択ユニット1806は、サブスクリプションオーダー情報に基づいて、顧客に第1のサービスを提供するためにリソースアセンブリの第1の組から第1のリソースアセンブリを選択するように構成される。電子デバイス1800はさらに、第1の顧客特有リソースアセンブリ作成ユニット1808を含む。第1の顧客特有リソースアセンブリ作成ユニット1808は、第1のリソースアセンブリを顧客特有の構成で構成することによって、顧客に第1のサービスを提供するために第1の顧客特有リソースアセンブリを作成するように構成される。
一例においては、サブスクリプションオーダー情報は、クラウドインフラストラクチャシステムによって提供される複数のクラウドサービスに第2のサービスを要求する。電子デバイス1800はさらに、第2のリソースアセンブリセット作成ユニット1803を含む。第2のリソースアセンブリセット作成ユニット1803は、クラウドインフラストラクチャシステムによって提供される複数のクラウドサービスから第2のサービスのためのリソースアセンブリの第2の組を作成するように構成される。リソースアセンブリの第2の組における各リソースアセンブリは、第2のサービスを提供するための1つ以上のリソースを含む。リソースアセンブリの第2の組の作成は、顧客からサブスクリプションオーダー情報を受取る前に実行される。電子デバイス1800はさらに、第2のリソースアセンブリ選択ユニット1805を含む。第2のリソースアセンブリ選択ユニット1805は、顧客に第2のサービスを提供するために、サブスクリプションオーダー情報に基づいて、リソースアセンブリの第2の組のうちの第2のリソースアセンブリを、1つ以上の演算装置から選択するように構成される。電子デバイス1800はさらに、第2の顧客特有リソースアセンブリ作成ユニット1807を含む。第2の顧客特有リソースアセンブリ作成ユニット1807はさらに、第2のリソースアセンブリを顧客特有の構成で構成することによって顧客に第2のサービスを提供するために第2の顧客特有リソースアセンブリを作成するように構成される。電子デバイス1800はさらに、統合ユニット1809を含む。統合ユニット1809は、第1の顧客特有リソースアセンブリおよび第2の顧客特有リソースアセンブリに関連付けられた1つ以上のファイアウォールを調整することによって、第1の顧客特有リソースアセンブリと第2の顧客特有リソースアセンブリとの間のデータフローを可能にするために、第1の顧客特有リソースアセンブリと第2の顧客特有リソースアセンブリとを統合するように構成される。
一例においては、第1のサービスはデータベースサービスであり、第1の顧客特有リソースアセンブリ作成ユニット1808はさらに、バーチャル・アセンブリ・ビルダを用いて、1つ以上の仮想マシン(VM)を備えたデータベースサービスのために特定的にプロビジョニングされた第1のリソースアセンブリを作成し;バーチャル・アセンブリ・ビルダを並行して動作させることを可能にするためにバーチャル・アセンブリ・ビルダに関連付けられるバーチャル・アセンブリ・ビルダ・ホームを作成し;デプロイメント・プラン・ファイルを作成するように構成される。デプロイメント・プラン・ファイルは、顧客特有の構成を1つ以上のVMにインジェクションするための構成情報を含む。
一例においては、リソースアセンブリの第1の組における各リソースアセンブリはマルチテナントサービスのために構成される。
一例においては、第1のサービスはデータベースサービスである。複数のスキーマが第1のリソースアセンブリに含まれる。複数のスキーマは、第1の顧客に関連付けられた第1のスキーマと、第1の顧客とは異なる第2の顧客に関連付けられた第2のスキーマとを含む。
一例においては、リソースアセンブリの第1の組における各リソースアセンブリがシングルテナントサービスのために構成される。
一例においては、サブスクリプションオーダー情報はサービスインスタンスサイズを含む。電子デバイス1800はさらに、サービスインスタンスサイズに基づいて、リソースアセンブリの第1の組から、顧客のために用いられるべきリリソースアセンブリの数を決定するように構成された決定ユニットを含む。
一例においては、電子デバイス1800はさらに、第1のサービスのためにプロビジョニングされたリソースアセンブリの第1の組を追跡し続けるためにレジストリを格納するように構成された格納ユニットを含む。レジストリはさらに、顧客特有にされた1つ以上のリソースアセンブリを追跡するように構成される。
なお、点線によって示されるユニットは任意である。本明細書に開示されているさまざまなユニットは、ハードウェア、ソフトウェアまたはそれらの組み合わせで実現されてもよく、またはそれらによって実行されてもよい。それらは、本明細書に記載されている機能を実行するように設計された汎用シングルチップもしくはマルチチッププロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(application specific integrated circuit:ASIC)、フィールド・プログラマブル・ゲート・アレイ(field programmable gate array:FPGA)もしくは他のプログラマブルロジックデバイス、ディスクリートゲートもしくはトランジスタ論理回路、ディスクリートハードウェアコンポーネント、またはそれらの任意の組み合わせで実現されてもよく、またはそれらによって実行されてもよい。汎用プロセッサは、マイクロプロセッサ、または任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。また、プロセッサは、演算装置の組み合わせ、例えばDSPとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサの組み合わせ、DSPコアと併用した1つ以上のマイクロプロセッサの組み合わせ、またはその他のこのような構成として実現されてもよい。いくつかの実現例では、当該ユニットは、所与の機能に特有の回路によって実現されてもよい。
本発明の特定の実施例について説明してきたが、さまざまな変形例、変更例、代替的な構成および等価物も本発明の範囲内に包含される。本発明の実施例は、特定の具体的なデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自由に動作できる。さらに、特定の一連のトランザクションおよびステップを使用して本発明の実施例について説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されるものではないということが当業者に明らかであるべきである。
さらに、ハードウェアおよびソフトウェアの特定の組み合わせを使用して本発明の実施例について説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本発明の範囲内であることが認識されるべきである。本発明の実施例は、ハードウェアのみで実現されてもよく、またはソフトウェアのみで実現されてもよく、またはそれらの組み合わせを使用して実現されてもよい。この明細書中に記載されるさまざまなプロセスは、同じプロセッサ上で、または任意に組み合わせされたさまざまなプロセッサ上で実現することができる。したがって、コンポーネントまたはモジュールがいくつかのオペレーションを実行するように構成されるものと記載されているが、このような構成は、例えば、オペレーションを実行するように電子回路を設計することによって、オペレーションを実行するようにプログラム可能な電子回路(マイクロプロセッサなど)をプログラミングすることによって、またはこれらを組み合わせることによって、達成することができる。プロセス同士は、プロセス間通信のための従来の技術を含むがこれらに限定されないさまざまな技術を用いて通信することができ、異なる対のプロセスは異なる技術を用いてもよく、または、同じ対のプロセスは異なる時間に異なる技術を用いてもよい。
したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかし、特許請求の範囲に記載されているより広範な精神および範囲から逸脱することなく、追加、削減、削除ならびに他の変形および変更がそれに対してなされてもよいということは明白であろう。このように、特定の発明の実施例を記載してきたが、これらは制限するようには意図されるものではない。さまざまな変更例および同等例は添付の特許請求の範囲内にある。