JP2015164067A - 複製されたデータインスタンスのプロビジョニングおよび管理 - Google Patents

Abstract

【課題】複製されたデータインスタンスのプロビジョニングおよび管理を提供する。
【解決手段】異なるデータゾーンまたは地理的位置においてプロビジョン可能な１次および２次レプリカを提供する複製されたデータベースインスタンスをプロビジョンする。データベースを１次レプリカ上にインストールし、１次および２次レプリカの両方は、Ｉ／Ｏ操作が１次および２次レプリカの間で複製されることを可能にするインストールされたブロックレベル複製機構を有する。１次レプリカの障害または機能停止は、２次レプリカへのフェイルオーバ操作で解決する。ＤＮＳ名などの手法を用いて、ＤＮＳ名がフェイルオーバ時、２次レプリカにエイリアスする。したがって、「新規」１次レプリカを利用するにあたり、顧客側には特段の動作は必要ない。データベースの生成および複製されたインスタンスのプロビジョニングは、制御環境へのウェブサービスコールを用いて開始する。
【選択図】図３

Description

増加しつつある数のアプリケーションおよびサービスがインターネット等のネットワーク上で利用可能になるのにしたがい、増加しつつある数のコンテンツ、アプリケーション、および／またはサービスのプロバイダが、クラウドコンピューティング等の技術に目を向けつつある。一般に、クラウドコンピューティングは、ウェブサービス等の様々なサービスを通して電子リソースへのアクセスを提供する手法であり、クラウドコンピューティングにおいては、これらのサービスをサポートするために用いられるハードウェアおよび／またはソフトウェアは、任意の所与の時間におけるサービスの必要性を満たすために、動的にスケーラブルである。ユーザまたは顧客は、クラウドによりリソースにアクセスするにあたり、一般的に、レンタル、リース、または他の方法による支払を行い、そのために、これらのリソースに対するアクセスを提供するハードウェアおよび／またはソフトウェアを購入および維持する必要がない。

様々なアプリケーションおよびリソースの態様がクラウドにおいて調節および管理される可能性がある一方で、これらのアプリケーションおよびリソースが依存するデータリポジトリは、顧客または係るユーザにより同様に調節可能または容易に管理可能ではない。
一般的に、プロビジョニング、データストレージのスケーリング等のタスクを実行することは、煩瑣な手作業による手順であり、顧客は、その手順において、データベース管理者（ＤＢＡ）が設定が有効であるかを判定できるよう、ＤＢＡまたは同様のエキスパートユーザに設定情報および要件を提供しなければならない。さらに、顧客が、動的且つ／もしくは自動的に、データベースインスタンスに対するパラメータを調節し、またはデータリポジトリの他の係る態様を管理するための容易な方法はない。多くの場合、データインスタンスはバックアップ機構またはリカバリ機構を所定の位置に有することになるが、これらの機構は単一の位置またはエリアに存在する場合が多く、そのエリアにおける障害または機能停止に影響されやすい。

本開示に係る様々な実施形態が、以下の図面を参照して説明される。

様々な実施形態を実装することができる環境を示す図である。 様々な実施形態にしたがって用いることができるコントロールプレーンおよびデータプレーンの分離例を示す図である。 １つに実施形態にしたがって用いることができる複数のデータゾーンにわたって複製されたデータインスタンスを実行するための実装例を示す図である。 １つに実施形態にしたがって用いることができる複製されたデータインスタンスを生成するためのプロセス例を示す図である。 １つに実施形態にしたがって用いることができる１次レプリカを生成するためのプロセス例を示す図である。 １つに実施形態にしたがって用いることができる２次レプリカを生成するためのプロセス例を示す図である。

本開示の様々な実施形態に係るシステムおよび方法は、電子環境におけるデータストレージの様々な態様を管理するための従来の手法において経験される前述の欠陥および他の欠陥の１つまたは複数を克服する場合がある。特に、様々な実施形態は、ユーザがデータ環境またはコントロールプレーンの様々な態様を管理および／または変更することを可能とするために用いることができる、分離された制御環境またはコントロールプレーンを提供する。この「セルフサービス」機能性は一連のウェブサービスにより提供することができ、それにより、ユーザおよびコントロールプレーンは、仮想的なデータベース管理者（ＤＢＡ）としてともに機能することが可能となる。ユーザまたは顧客は、例えば、外部から可視である複数のアプリケーションプログラミングインターフェース（ＡＰＩ）のうちの１つを通して、リクエストをコントロールプレーンに発行することができる。様々なＡＰＩを、データ環境において、例えば、リレーショナルデータベース等のデータリポジトリに対して特定の機能を実行するために用いることができる。１つのＡＰＩにより受信されたリクエストを解析することにより、データストアまたはデータストレージインスタンスの動作パラメータまたは設定パラメータを調節する動作等の、データプレーンにおいて実行される所望の動作（単数または複数）を判定することができる。ワークフローコンポーネント等のコンポーネントは、動作に対する適切なタスクを決定し、適切な順序でタスクを実行することができる。リレーショナルデータベースの態様を調節する等の、これらのタスクのうちの少なくとも１つが、一般的に、データ環境において実行されるであろう。

特定の実施形態によると、係るシステムは、データ環境における複製されたデータインスタンスのプロビジョニングを提供することができる。このプロビジョニングは、１次・２次複製手法を利用することができる。なお、この１次・２次複製手法においては、１つまたは複数の別個のデータゾーン、別個の地理的位置、その他においてまたはわたって１次レプリカおよび２次レプリカの各々がプロビジョンされるものである。データベースレプリカは、それぞれが、複数のレプリカにわたって共有されない専用ブロックストレージボリュームにアタッチされた、別個のデータインスタンス上で実行可能である。

様々な実施形態において、複製は、オーストリア国ウィーンのＬｉｎｂｉｔ社のＤｉｓｔｒｉｂｕｔｅｄ Ｒｅｐｌｉｃａｔｅｄ Ｂｌｏｃｋ Ｄｅｖｉｃｅ（ＤＲＢＤ（登録商標））または米国ワシントン州シアトルのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．，社により提供されるＥｌａｓｔｉｃ Ｂｌｏｃｋ Ｓｔｏｒｅ（ＥＢＳ）等のブロックレベル複製機構を用いて実行することができる。これらのブロックレベル複製機構は、ブロックデバイスのコンテンツがサーバ間でミラーされ、冗長システム上でデータの同時複製が可能となる。それぞれのインスタンスは、データインスタンスに対するすべての入出力（Ｉ／Ｏ）操作を管理するためにインストールされたブロックレベル複製機構カーネルモジュールを有するカーネルを実行することができる。すべての読み出しおよび書き込みは、ブロックレベル複製機構が２次レプリカに情報を同時に複製しながら、１次レプリカにおいて実行することができる。

１次レプリカおよび２次レプリカの両方は、外向きＤＮＳ名を有する。顧客は、ＤＮＳ_ｐｒｉｍａｒｙ等のＤＮＳ名を用いて、現行の１次レプリカに到達することができる。
ＤＮＳ_ｐｒｉｍａｒｙ名は、（現行の）１次レプリカの外部ＤＮＳ名にエイリアスまたは「ｃｎａｍｅ」することができる。１次レプリカに障害が生じた場合または１次レプリカが他の方法で利用不可能となった場合、２次レプリカが新規１次レプリカに昇格またはフェイルオーバすることができる。それによって、ＤＮＳ_ｐｒｉｍａｒｙに対するｃｎａｍｅは、新規１次インスタンスのＤＮＳ名に更新することができる。すべての書き込みは現行の１次レプリカ上のデータベースに送られる。１次インスタンスが書き込みを受信すると、その情報は２次レプリカにも同時に書き込まれる。両方の位置において書き込みが成功した場合に、書き込みは成功であるとみなされる。様々な実施形態において、すべての読み出しも１次レプリカにおいてのみ実行される。

図１は、様々な実施形態に係る態様を実装する環境１００の１例を示す。理解されるであろうように、ウェブに基づく環境が説明のためにここでは用いられているが、様々な実施形態を実装するために、異なる環境が適宜用いられてもよい。図示の環境１００は、テストまたは開発部分（側）および生産部分の両方を備える。生産部分は、適切なネットワーク１０４上でリクエスト、メッセージ、または情報の送受信を実行し、デバイスのユーザに情報を戻すように伝えるために動作可能である任意の適切な装置を含むことができるとができる電子クライアントデバイス１０２を含む。係るクライアントデバイスの例は、パーソナルコンピュータ、携帯電話、携帯型メッセージ装置、ラップトップコンピュータ、セットトップボックス、携帯情報端末、および電子ブックリーダ等を含む。ネットワークは、イントラネット、インターネット、セルラネットワーク、ローカルエリアネットワーク、または任意の他の係るネットワークまたはこれらの組み合わせを含む任意の適切なネットワークを含むことができる。係るシステムに用いられるコンポーネントは、選択されたネットワークおよび／または環境の種類に少なくとも部分的に依存する。係るネットワークを介して通信するためのプロトコルおよびコンポーネントは周知であり、本明細書では詳細に説明しない。ネットワーク上の通信は、有線接続または無線接続およびこれらの組み合わせにより可能とすることができる。この例においては、この環境が、リクエストを受信しそれに応答してコンテンツをサーブするためにウェブサーバ１０６を含むため、ネットワークはインターネットを含むが、他のネットワークに対しては、当業者に理解されるように、同様の目的のために機能する代替的なデバイスが用いられる可能性がある。

図示的な環境は、少なくとも１つのアプリケーションサーバ１０８およびデータストア１１０を含む。チェーン構成されたまたは他の方法で構成され、且つ適切なデータストアからデータを取得する等のタスクを実行するよう相互作用する、いくつかのアプリケーションサーバ、層、もしくは他の要素、プロセス、またはコンポーネントが存在することができることが理解されるべきである。本明細書で用いられる場合「データストア」は、データを記憶、アクセス、および取得する能力を有し、任意の標準型、分散型、またはクラスタ環境において、任意の組み合わせ、かつ任意の個数のデータサーバ、データベース、データ記憶デバイス、およびデータ記憶媒体を含む、任意のデバイスまたはデバイスの組み合わせを指す。アプリケーションサーバは、クライアントデバイスに対して１つまたは複数のアプリケーションの態様を実行するために、アプリケーションに対する大部分のデータアクセスおよびビジネスロジックを処理する、必要に応じてデータストアと統合する任意の適切なハードウェアおよびソフトウェアを含むことができる。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供し、テキスト、グラフィック、オーディオ、および／またはビデオ等の、ユーザに転送される、ウェブサーバによりユーザにサーブされるコンテンツを生成することが可能である。なお、これらのコンテンツは、この例では、ＨＴＭＬ、ＸＭＬ、または他の適切な構造化言語の形でウェブサーバによりユーザにサーブされてもよい。すべてのリクエストおよび応答の取り扱いならびにクライアントデバイス１０２およびアプリケーションサーバ１０８の間のコンテンツの送達は、ウェブサーバにより取り扱うことができる。ウェブサーバおよびアプリケーションサーバは、本明細書の他の箇所において説明されるように、本明細書で検討する構造化されたコードが任意の適切なデバイスまたはホストマシン上で実行可能であるため、不可欠ではなく、単にコンポーネント例であることを理解すべきである。さらに、環境は、ユーザまたはアプリケーションがサブスクライブすることができるサービスとしてテストオートメーションフレームワークが提供されるよう、構成することができる。テストオートメーションフレームワークは、本明細書において説明および示唆されるように、様々な他の実装を用いることもできるが、本明細書で説明する様々なテストパターンのうちの任意の実装として提供することができる。

環境は、開発者、データ管理者、またはテスタ等のユーザがシステムにアクセスすることを可能とするユーザデバイス１１８を備える、開発および／またはテスト側を備えてもよい。ユーザデバイス１１８は、クライアントデバイス１０２に関して上述したもののように、任意の適切なデバイスまたはマシンとすることができる。環境は開発サーバ１２０も含む。なお、この開発サーバ１２０は、アプリケーションサーバ１０８と同様に機能すするが、一般的に、コードが製作側において展開および実行される前に開発およびテストの間にコードを実行し、外部ユーザにアクセス可能である。いくつかの実施形態において、アプリケーションサーバは、開発サーバとして機能することができ、分離された生産およびテストストレージは用いられなくてもよい。

データストア１１０は、いくつかの別個のデータテーブル、データベース、または特定の態様に関するデータを記憶する他のデータ記憶機構および媒体を含むことができる。例えば、図示したデータストアは、生産側に対してコンテンツをサーブするために用いることができる、生産データ１１２およびユーザ情報１１６を記憶する機構を含む。データストアは、テスト側に対するユーザ情報とともに用いることができる、テストデータ１１４を記憶する機構も含むことが示される。任意の上述の機構に、適宜またはデータストア１１０における追加的機構に記憶することができる、ページ画像情報およびアクセス権情報に対する等の、データストアに記憶することができる、他の多数の態様が存在することができることを理解すべきである。データストア１１０は、これに関連するロジックを通して、アプリケーションサーバ１０８または開発サーバ１２０から命令を受信し、それに応答してデータを、取得、更新、または他の方法で処理するようするよう動作可能である。
１つの例において、ユーザは特定の種類の項目に対する検索リクエストを発行してもよい。この場合、データストアはユーザ情報にアクセスすることにより、ユーザの身元を確認してもよく、またカタログ詳細情報にアクセスすることにより当該種類の項目に関する情報を取得することができる。その後この情報は、ユーザデバイス１０２上のブラウザによりユーザが閲覧可能なウェブページ上にリストされる結果等として、ユーザ返すことができる。対象となる特定項目に関する情報は、ブラウザの専用ページまたはウィンドウにおいて閲覧可能である。

各サーバは、一般的に、そのサーバの一般的管理および操作のための実行可能プログラム命令を提供するオペレーティングシステムを含み、一般的に、サーバのプロセッサにより実行されるとサーバがその意図する機能を実行することを可能にする命令を記憶するコンピュータ可読媒体を含むであろう。オペレーティングシステムおよびサーバの一般的機能性に対する適切な実装は、周知または商業的に入手可能であり、特に本明細書の開示に照らし合わせると、当業者により容易に実装される。

１つの実施形態における環境は、１つまたは複数のコンピュータネットワークまたは直接接続を用いる通信リンクを介して相互接続されるいくつかのコンピュータシステムおよびコンポーネントを利用する、分散コンピューティング環境である。しかし、係るシステムは、図１に示すコンポーネントよりも少数または多数のコンポーネントを有するシステムにおいても同様に良好に動作可能であることが当業者には理解されるであろう。したがって、図１におけるシステム１００の描写は、図示的な性質のものであり、本開示の範囲を限定するものでないことを理解すべきである。

図１に示すもののような環境は、電子市場等のプロバイダに対して有用であり、複数のホストが、コンテンツのサーブ、ユーザの認証、決済トランザクションの実行、または多数の他の係るタスクのうちの任意のタスクの実行等の様々なタスクを実行するために用いられてもよい。これらのホストのうちのいくつかは同様の機能性を提供するよう構成されてもよい。一方、他のサーバは、少なくともいくつかの異なる機能を実行するよう構成されてもよい。係る場合における電子環境は、以下で詳細に説明する、図２の構成２００に図示されるものなどのような、追加的コンポーネントおよび／または他の機構を含んでもよい。

１つの実施形態に係るシステムおよび方法は、リレーショナルデータベースサービス（「ＲＤＳ」）を提供する。このＲＤＳは、開発者、顧客、または他の正規ユーザが、リレーショナルデータベースおよび他の係るデータソースを、容易且つ高いコスト効率で取得および設定することを可能とし、その結果、ユーザは、クラウド内のリレーショナルデータの組の記憶、処理、および照会等のタスクを実行することができる。この例は、インターネット、ウェブサービス、インターネットベースの技術に関連して説明されるが、様々な実施形態の態様を、電子環境におけるネットワーク上で利用可能または提供される任意の適切なサービスとともに用いることができることを理解すべきである。さらに、サービスは本明細書において「リレーショナルデータベースサービス」を指す一方で、係るサービスを、電子環境において任意の適切な種類のデータリポジトリまたはデータストレージとともに用いることができることを理解すべきである。この例におけるＲＤＳは、少なくとも１つのウェブサービスを含み、そのウェブサービスにより、ユーザまたは顧客は、展開、更新、パッチ管理、バックアップ、複製、フェイルオーバ、容量管理、スケーリング、およびデータ管理の他の係る態様の管理上の複雑さを心配することなく、容易にリレーショナルデータの組を管理することが可能となる。したがって開発者は、データベースのインフラストラクチャを管理する複雑さを心配することなく、高度なクラウドアプリケーションを開発する自由を得ることができる。

１つの実施形態におけるＲＤＳは、データストレージの様々な態様の管理に有用なコンポーネント（例えば、ハードウェアおよびソフトウェア）を含む別個の「コントロールプレーン」を提供する。１つの実施形態において、ユーザまたは顧客が、データストレージに関する特定のタスクを実行するように、ＲＤＳへのコールを生成することを可能にする１組のデータ管理アプリケーションプログラミングインターフェース（ＡＰＩ）または他の係るインターフェースが提供される。しかしながら、ユーザは、データリボジトリと通信するにあたり直接的インターフェースまたはＡＰＩを用いることもでき、データストレージを管理する必要があるときのみ、または同様のタスクを実行する必要があるときにのみ、コントロールプレーンのＲＤＳ専用のＡＰＩを用いることができる。

図２は、１つに実施形態にしたがって用いることができるＲＤＳ実装２００の１例を示す図である。この例において、エンドユーザの計算デバイス２０２は、データプレーン２１０のデータリポジトリをプロビジョンする等のタスクを実行するコールを、ネットワーク２０６を通してコントロールプレーン２０８に発行することが可能であるよう示されている。ユーザまたはアプリケーション２０４は、データプレーン２１０のインターフェースを通して、プロビジョンされたリポジトリに直接アクセスすることができる。エンドユーザの計算デバイスおよびアプリケーションが説明目的のために用いられているが、様々な実施形態において、任意の適切なユーザ、アプリケーション、サービス、デバイス、コンポーネント、またはリソースが、コントロールプレーンのインターフェース（単数または複数）および／またはデータプレーンに適宜アクセス可能であることを理解すべきである。さらに、コンポーネントはコントロールプレーンおよびデータプレーンに分割されているが、これは、それぞれの機能性を提供するために用いられる少なくともいくつかのリソース（例えば、ハードウェアおよび／またはソフトウェア）の事実上の分離または仮想的な分離を指すことができることを理解すべきである。

この例におけるコントロールプレーン２０８は、本質的に、プロビジニング、スケーリング、複製、その他等の制御動作および管理動作を取り扱うハードウェアおよびソフトウェアコンポーネントの仮想層である。この実施形態におけるコントロールプレーンはウェブサービス層２１２またはサービスティアを含み、このウェブサービス層２１２は、例えば、コンピュータ実行可能ソフトウェア、アプリケーションサーバ、または他の係るコンポーネントとともに、少なくとも１つのウェブサーバを含むことができる。ウェブサービス層は、ネットワーク２０６上からウェブサービスコールまたはリクエストを受信するための１組のＡＰＩ２３２（または他の係るインターフェース）も含むことができる。各ＡＰＩは、リレーショナルデータベースのインスタンスのプロビジョンする、スケールする、クローンする、またはハイバネートする等の、データ環境に関して実行される少なくとも１つの特定の動作のためのリクエストを受信するために提供することができる。ＡＰＩのうちの１つに対するリクエストを受信すると、ウェブサービス層は、リクエストを構文解析または他の方法で解析することにより、コールを実行または処理するために必要なステップまたは動作を判定する。例えば、データリポジトリ生成のリクエストを含むウェブサービスコールが受信される場合がある。この例において、ウェブサービス層はリクエストを構文解析することにより、生成されるデータリポジトリの種類、要求される記憶ボリューム、（必要に応じて）要求されるハードウェアの種類、または他の係る態様を判定することができる。リクエストに関する情報は、後続の処理のために、管理（「Ａｄｍｉｎ」）データストア２２２、または他の適切な記憶位置もしくはジョブ待ち行列に書き込むことができる。

１つの実施形態におけるウェブサービス層はスケーラブルな１組の顧客向きサーバを含む。なお、この顧客向きのサーバは、様々なコントロールプレーンＡＰＩを提供し、ＡＰＩ仕様に基づいて適切な応答を返すことができる。ウェブサービス層は少なくとも１つのＡＰＩサービス層も含むことができる。なお、このＡＰＩサービス層ヤは、１つの実施形態においては、ステートレスな、複製されたサーバからなり、これらのステートレスな複製されたサーバは外向きの顧客ＡＰＩを処理する。ウェブサービス層は、クレデンシャルに基づく顧客の認証、顧客の権限付与、ＡＰＩサーバに対する顧客のリクエストのスロットル、ユーザ入力の確認、リクエストおよび応答のマーシャルおよびアンマーシャル等のウェブサービスフロントエンド機能を受け持つことができる。ＡＰＩ層は、ＡＰＩコールに応答して、管理データストアへの／管理データストアからの、データベース設定データの読み取り／書き込みを実行することも受け持つことができる。多数の実施形態において、ウェブサービス層および／またはＡＰＩサービス層は、外部から可視である唯一のコンポーネント、すなわち制御サービスの顧客に可視であり且つ制御サービスの顧客によりアクセス可能な唯一のコンポーネントである。ウェブサービス層のサーバは、当該技術分野において既知であるように、ステートレス、かつ水平方向にスケールすることができる。
ＡＰＩサーバならびに永続的なデータストアは、１つの地理的領域内の複数のデータセンタに、または１つの地理的位置の近傍の複数のデータセンタにわたって分散することができる。それにより、例えば、これらのサーバは、単一のデータセンタの障害に対して回復力に優れる。

この実施形態におけるコントロールプレーンは、本明細書において「スイーパー」コンポーネント２１４と称されるコンポーネントを含む。スイーパーコンポーネントは、顕著なリクエストに応答してコントロールプレーンの様々なコンポーネントをポーリングするよう、すなわち実行される任意のタスクを他の方法で判定するよう動作する、任意の適切なコンポーネントとすることができる。この例においては、ウェブサービス層は、「データベース生成」リクエストに関する命令または情報を管理データストア２２２または同様のジョブ待ち行列に設置してもよい。次いで、スイーパーは顕著なジョブを求めて管理データストアを周期的に調べることができる。ウェブサービス層がジョブが存在するスイーパーに対して通知を送信する等の、当業者には明らかである様々な他の手法を用いることができる。スイーパーコンポーネントは「データベース生成」リクエストをピックアップし、リクエストに関する情報を用いて、リクエスト、コール、または他の係るコマンドを、リクエストに対する少なくとも１つのワークフローをインスタンス化するよう動作するワークフローコンポーネント２１６に送信することができる。１つの実施形態におけるワークフローは、本明細書の他の箇所で説明されるように、ワークフローサービスを用いて生成および維持される。一般にワークフローは、特定のジョブを実行するために実行されるべき一連のタスクである。ワークフローは、実際の操作ではなく、操作に関する情報および実行の流れを制御する操作の抽象化である。ワークフローは、実行中の任意の時間において処理状態を管理し、処理状態を返すことができる１つの状態マシンとしてみなすこともできる。１つの実施形態におけるワークフローコンポーネント（またはコンポーネントのシステム）は、リポジトリの生成、変更、ならびに削除、復元ならびにバックアップ、セキュリティグループの生成、削除、ならびに変更、ユーザのクレデンシャルの管理、およびキーローテーションならびにクレデンシャルの管理等のタスクに対するワークフローのホスティングおよび実行を管理および／または実行するよう動作することができる。
係るワークフローは、本明細書の他の箇所で説明されるように、ワークフローサービス上に実装することができる。ワークフローコンポーネントは、ＭｙＳＱＬ等の異なるデータベースエンジンに対して用いられるワークフローステップの間の差異を管理することもできる。なぜなら、下層のワークフローサービスが必ずしも変化するとは限らないからである。

この例において、ワークフローは、データベースを生成しオリジナルのリクエストから抽出された情報を適用するためのワークフローテンプレートを用いて、インスタンス化することができる。例えば、リクエストが、Ｏｒａｃｌｅ（登録商標）リレーショナルデータベース管理システム（ＲＤＢＭＳ）または他の係るインスタンスではなく、ＭｙＳＱＬ（登録商標）ＲＤＢＭＳインスタンスに対するものである場合、特定のタスクがＭｙＳＱＬインスタンスに向けられたワークフローに加えられるであろう。ワークフローコンポーネントは、要求される記憶装置の量、任意の特定のハードウェア要件、または他の係るタスクに関する特定のタスクを選択することもできる。これらのタスクは、全般的なジョブに対して有用である実行順序で、ワークフローに加えられることができる。いくつかのタスクが並列的に実行することができるのに対し、他のタスクは、最初に完了することになっている以前のタスクに依存する。ワークフローコンポーネントまたはサービスは、ワークフローにおけるこの情報を含み、タスクは実行され、情報は必要に応じて伝えられることができる。

顧客に対する「データベース生成」ワークフロー例は、データ記憶インスタンスのプロビジョニング、オフインスタンス永続的記憶装置のボリュームの割り当て、永続的記憶装置ボリュームのデータ記憶インスタンスへのアタッチ、次いで、ＤＮＳアドレスまたは顧客がアクセスまたは他の方法で接続するために用いることができる他のアドレス、ポート、インターフェース、もしくは識別子の、データインスタンスへの割り当てならびにアタッチ等のタスクを含んでもよい。この例において、ユーザには、インスタンスへのアクセスに用いるための、ＤＮＳアドレスおよびポートアドレスが提供される。ワークフローは、特定のデータ記憶技術（例えば、ＭｙＳＱＬ）に対して用いられる任意のバイナリまたは他の情報をダウンロードおよびインストールするタスクも含むことができる。ワークフローコンポーネントは、これらのタスクおよび任意の関連するタスクまたは係るタスクの任意の他の適切な組み合わせの実行を管理することができ、「データベース生成」リクエストに応答して「データベース」の生成を示す応答を、リクエストに対して生成することができる。なお、この「データベース生成」リクエストは実際にデータプレーン２１０におけるデータ記憶インスタンスに対応し、インスタンスにアクセスするために用いられるＤＮＳアドレスを提供する。次いでユーザは、ＤＮＳアドレスおよびポートを用いて、コントロールプレーン２０８をアクセスまたは経由する必要なしに、直接的にデータ記憶インスタンスにアクセスすることができる。記憶装置を増大させるなどのために、１つまたは複数のデータ記憶インスタンスの削除、生成、または変更等の、同様のジョブを実行するための、様々な他のワークフローテンプレートを用いることができる。いくつかの実施形態においては、ワークフロー情報が記憶装置に書き込まれ、少なくとも１つの別個の実行コンポーネント（図示せず）が、ワークフロー情報に基づいて実行されるタスクを取得する、または他の方法でアクセスもしくは受信する。例えば、プロビジョニングタスクを実行する専用プロビジョニングコンポーネントが存在し、このコンポーネントはワークフローコンポーネントによりコールはされないが、多数の関連する明らかな方法のいずれかで、タスク待ち行列を監視することができる、またはプロビジョニングタスクに関する情報を受信することができる。

上述のように、様々な実施形態は、リポジトリのプロビジョニング等の、処理またはタスクの現状に関するリクエストまたはコールを受信すことができ、処理の現状を返すことができるワークフローサービスの利点を利用することができる。ワークフローコンポーネントおよび／またはワークフローサービスは、各タスクを実行する実際のコールまたはリクエストを生成しないが、その代わりにワークフローに関する状態情報および設定情報を管理する。なお、その情報は、コントロールプレーンのコンポーネントが、次に実行するタスクおよびそのタスクに必要な任意の情報を決定することを可能とし、その後、その状態情報を含むデータプレーンへの適切なコール（単数または複数）を生成する。それにより、データプレーンのコンポーネントが、当該のタスクを実行するコールを生成することができる。ワークフローおよびタスクは、処理能力を増し処理リソースを最大化するために、並列的にスケジュールすることができる。上述のように、タスクの実際の実行はデータプレーンで行われるが、タスクはコントロールプレーンから発することになる。例えば、ワークフローコンポーネントはホストマネージャと通信し、ホストマネージャはデータストアへのコールを生成することができる。したがって、所与のタスクに対して、特定のパラメータを伝えるワークフローサービスへのコールが生成されてもよい。それにより、ワークフローサービスはワークフローに関する一連のタスクを生成し、現在の状態に対するタスクを実行することができるように、現状を提供する。タスクが実行された（または、他の方法で解決あるいは完了された）後、ホストマネージャ等のコンポーネントは、サービスに応答することができる。次いで、サービスは、次のタスクを実行することができるように、ワークフローにおける次の状態に関する情報を提供することができる。ワークフローに関するタスクのうちの１つが実行される都度、サービスは、ワークフローが完了するまで、実行されるべき新規のタスクを提供することができる。さらに、ワークフローの処理を加速するために、異なるワークフローに対して複数のスレッドを並列的に実行することができる。

この実施形態におけるコントロールプレーン２０８は、少なくとも１つの監視コンポーネント２１８も含む。データインスタンスがデータプレーン内で生成されると、インスタンスに関する情報を、監視データストア２２０等のコントロールプレーン内のデータストアに書き込むことができる。監視データストアが別個のデータストアであってもよく、または、管理データストア２２２における異なる組のテーブルまたは他の適切なリポジトリ等の、別のデータストアの１部分であってもよいことを理解すべきである。監視コンポーネントは、監視データストア内の情報にアクセスすることができ、データプレーン２１０内のアクティブなインスタンス２３４を判定することができる。監視コンポーネントは、ウェブサービス層、ワークフローコンポーネント、スイーパーコンポーネント、および様々なホストマネージャ等の、コントロールプレーンおよび／またはデータプレーンの、複数のコンポーネントからのログ情報および／またはイベント情報の収集等の、他のタスクを実行することもできる。係るイベント情報を用いて、監視コンポーネントは、顧客向きのＡＰＩを実装する等の目的のために、顧客から可視であるイベントを公表することができる。監視コンポーネントは、コントロールプレーンに対する実行中の全リボジトリおよび／またはインスタンスの健康状態を常に監視し、これらのインスタンスのいかなる障害も検出し、適切な復元処理（単数または複数）を開始することができる。

データプレーンにおける各インスタンス２３４は、アクセスを提供するマシンに対して、少なくとも１つのデータストア２２６およびホストマネージャコンポーネント２２８を含むことができる。１つの実施形態におけるホストマネージャは、インスタンスおよび／またはソフトウェアの展開およびデータストア動作ならびにデータストアおよび／またはそれぞれのインスタンスの状態の監視等のタスクを管理するようにプログラムされたＴｏｍｃａｔまたはＪａｖａアプリケーションサーバ等のアプリケーションサーバ上で実行するアプリケーションまたはソフトウェアエージェントである。１つの実施形態におけるホストマネージャは、内部システムコンポーネントからのみ到達され、且つ顧客または他の外部のエンティティには利用不可能であるポートをリッスンする。いくつかの実施形態において、ホストマネージャは、コントロールプレーン層へのいかなるコールも開始することもできない。ホストマネージャは、論理ボリュームおよびファイルシステムの設定を含む新規リポジトリに対するインスタンスの設定、データベースバイナリおよびデータベースシードのインストール、ならびにリポジトリの開始または停止等の、タスクの管理および／または実行を受け持つことができる。ホストマネージャは、データストアの健康状態を監視すること、および、Ｉ／Ｏエラーまたはデータ記憶エラー等のエラー状況を求めてデータストアを監視することができ、必要に応じてデータストアを再起動することができる。ホストマネージャは、ソフトウェアパッチおよびデータストアおよび／またはオペレーティングシステムの更新のインストールを実行および／または管理することもできる。
ホストマネージャは、ＣＰＵ、メモリ、Ｉ／Ｏ仕様に関する場合があるものなどのような、関連するメトリックを収集することもできる。

監視コンポーネントは、各ホストの状態を判定するために、特定のリクエストを送信すること、またはホストマネージャからのハートビートを監視すること、等により、監視されたインスタンス２３４を求めて、各ホストマネージャ２２８と周期的に通信することができる。１つの実施形態において、監視コンポーネントは、特定のホストおよび／またはインスタンスの状態を取得する等のコマンドを各ホストマネージャに発行するよう構成された、１組のイベントプロセッサ（または監視サーバ）を含む。指定された回数の再試行の後、応答が受信されない場合、監視コンポーネントは、問題が発生したと判定する。そして、管理データストア２２２または他の係るジョブ待ち行列に情報を記憶することにより、問題を確認し、必要に応じてインスタンスを再プロビジョンするなどのような、インスタンスに対する動作を実行することができる。スイーパーはこの情報にアクセスし、インスタンスに対するリカバリワークフローを開始することにより、障害からの自動的な回復を試みることができる。ホストマネージャ２２８は、監視のためのプロキシおよびコントロールプレーンの他のコンポーネントとして動作し、コントロールプレーンのコンポーネントに代わって、インスタンスに対するタスクを実行することができる。自動的に解決不可能な、対応するホスト、インスタンス、ボリュームのクラッシュ、再起動、再開、その他等の問題が、インスタンスのうちの１つに関して生じる場合もある。１つの実施形態において、これらの顧客または他の顧客の可視性イベントをログ記録することができるログ記録コンポーネント（図示せず）が存在する。ログ記録コンポーネントは、インスタンスが一定期間利用不可能である場合、顧客が適切な「イベント」をコールするかまたはイベントに関する情報を取得するための同様のＡＰＩをコールすることができるよう、ＡＰＩまたは他の係るインターフェースを含むことができる。いくつかの場合において、リクエストは、インスタンスが失敗した場合、保留状態のままにおかれてもよい。この実施形態におけるコントロールプレーンは、データプレーンと分離されているため、コントロールプレーンはデータリクエストを受信することは決してなく、したがって、（いくつかの実施形態においては、この情報はコントロールプレーンに転送される可能性があるが）後続の発行のためのリクエストを待ち行列に入れることはできない。したがって、この実施形態におけるコントロールプレーンは、ユーザが必要に応じてリクエストを取り扱うことができるよう、障害に関する情報をユーザに提供する。

前述のように、インスタンスがプロビジョンされユーザにＤＮＳアドレスまたは他のアドレスもしくは位置が提供されると、ユーザは、Ｊａｖａ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）または、そのインスタンス２３４と直接相互作用するための他の係るクライアントを用いて、ネットワークを介して「直接的」にリクエストをデータプレーン２１０に送ることができる。１つの実施形態において、データプレーンは、コンピューティングクラウド環境すなわち「クラウド」すなわちハードウェアおよび／またはソフトウェアコンポーネントの動的ネットワーク上でデータ記憶およびアクセスを提供する１組のウェブサービスおよびリソースの形を取る（または、これを含むもしくはこれの１部分である）。ＤＮＳアドレスは、係る動的なクラウド環境において有益である。なぜなら、インスタンスまたは可用性の障害は、例えば、ＤＮＳアドレスを、使用のために任意の適切な代理インスタンスへと、プログラム的に再マッピングすることにより、隠される可能性があるためである。ユーザ２０２またはアプリケーション２０４から受信されたリクエストは、例えば、ネットワークアドレス変換（ＮＡＴ）ルータ２２４または他の適切なコンポーネントへと送られ、ついでＮＡＴルータ２２４または他の適切なコンポーネントは、実際のインスタンス２３４またはリクエストのＤＮＳに相当するホストへと、リクエストを送ることができる。上述のように、係る手法により、ユーザまたはアプリケーションがＤＮＳまたはインスタンスにアクセスするために用いられる他のアドレスを変える必要なしに、インスタンスが、動的に、移動、更新、複製、その他を実行されることが可能となる。上述のように、各インスタンス２３４は、ホストマネージャ２２８およびデータストア２２６を含むことができ、少なくとも１つのバックアップインスタンスまたはコピーを永続的記憶装置２３０に有することができる。係る手法を用いることにより、インスタンスがコントロールプレーンを通して設定されると、ユーザ、アプリケーション、サービス、またはコンポーネントは、コントロールプレーン２３２にアクセスする必要なしに、データプレーンへのリクエストを通して直接にインスタンスに相互作用することができる。例えば、ユーザは、インスタンスにおけるデータに関する構造化照会言語（ＳＱＬ）または他の係るコマンドを、ＤＮＳアドレスを通して直接発行することができる。
ユーザが、インスタンスの記憶容量を拡張すること等のタスクの実行を望む場合、ただコントロールプレーンにアクセスのみしなければならないことになる。少なくとも１つの実施形態においては、コントロールプレーン２０８の機能性は、少なくとも１つのサービスとしてプロバイダにより提供することができ。なお、当該のサービスは、データプレーン２１０のプロバイダに関連してもよく、または関連しなくてもよいが、単に第３者サービスであってもよい。なお、この第３者サービスは、データプレーンにおけるデータインスタンスをプロビジョンおよび管理するために用いられてもよく、且つ別個のデータプレーン２１０におけるこれらのインスタンスの可用性を監視および保証することができる。

前述のように、コントロールプレーンの機能性をウェブサービスまたは他の係るサービスとして提供することの１つの利点は、コントロールプレーンが仮想的なデータベース管理者（ＤＢＡ）として機能し、人間のＤＢＡがデータのプロビジョン等のタスクを実行する必要性が回避されることである。データをプロビジョンすることは、現時点においては、煩瑣な手作業による手順であり、ＤＢＡが必要な設定情報を受け取り、設定が有効であるかどうかを判定し、インスタンスを最適化またはチューニングし、他の係るタスクを実行することが要求される。これらは、著しい量の時間および労力を必要とするものである。さらに、係る手法は、エラーを生ずる多くの機会を提供し、係るエラーはデータ損失後まで発見されないこともある。本明細書に記載のコントロールプレーンまたはサービスを用いることにより、ユーザまたは顧客は、その代わりに、ハードウェアの種類およびデータベース製品のバージョン等の情報を含むコールを発行することができる。コントロールプレーンまたはサービスは、次いで、データストアまたはデータストレージインスタンスを生成、削除、変更、拡張、または他の方法で変更するために必要なタスクを実行することができる。コントロールプレーンは、ＤＢＡがそれぞれのデータベースエンジンに関して熟達する必要なしに、一貫した方法で、いくつかの異なるデータベースエンジンに対応することもできる。一度プロビジョンされると、ユーザはデータインスタンス（単数または複数）に対してネイティブアクセスを有し、既存のアプリケーション（ＭｙＳＱＬアプリケーション等）をＤＮＳアドレスまたは特定インスタンスのための他の位置情報に対して、単純にポイントすることができる。照会モデルまたは他の係る機能性に制限または変更はない。なぜなら、ユーザはＭｙＳＱＬ、Ｏｒａｃｌｅ、または他のデータベース技術上に構築されたアプリケーションを継続して使用することができるためである。

様々な実施形態に係るシステムおよび方法により、顧客はウェブサービスまたは同様の係る手法を利用することにより、クラウドコンピューティング環境または同様の環境において１つまたは複数の複製されたデータベースインスタンスを生成することができ、それにより、高い耐久性および高い可用性を有するデータソリューションが提供される。顧客が複製された様々な実施形態におけるデータベースインスタンスを生成すると、顧客データは、１次・２次複製モデルを用いて、同時に複製される。いくつかの実施形態において、レプリカは、異なるデータゾーン等の異なる物理的位置に配置することができる。各データ「ゾーン」は、例えば、特定の地理的エリア内に配置された、異なる地理的位置にまたは地理的位置の周囲に配置された異なるゾーンを有する、１つまたは複数のデータセンタまたはデータサーバ群を指すことができる。かくしてＲＤＳインスタンスは、データゾーンのうちの１つに障害が発生した場合、その障害に対して耐性を有することができる。
なぜなら、異なる地理的位置における他のデータゾーンにおいては、大規模な破局的事象の場合を除いて、その障害が回避される可能性があるためである。いくつかの場合においては、データセンタは複数のデータゾーンにまたがるが、所与のデータゾーン内のデータレプリカは異なるゾーンにおいてインスタンス化することができる。重複するゾーン、複数の地理的位置におけるゾーン、その他等の多数の他の変化例が可能である。１次レプリカに障害が発生するかまたは他の方法で利用不可能となった場合、ＲＤＳシステムは、迅速且つ自動的に、２次レプリカにフェイルオーバし、その結果、ダウンタイムすなわちデータ利用不能状態は極めて短くてすむ。

１つの実施形態において、顧客は、図２を参照して説明したものなどのようなコントロールプレーンのウェブサービス層の特定されたウェブサービスのインターフェースをコールするにより、複製されたデータベースインスタンスを生成することができる。顧客が複製されていないデータインスタンスを生成するとき、例えば、顧客は、インスタンスクラス、割り当てられたストレージ、データベースエンジン、その他等の態様を指定する「ＣｒｅａｔｅＤＢＩｎｓｔａｎｃｅ」ＡＰＩをコールすることができる。複製されたインスタンスを生成するとき、顧客は、生成されたインスタンスが複製されるべきであることを示す「ｔｒｕｅ」または任意の他の適切な値に設定された値を有する「Ｒｅｐｌｉｃａｔｅｄ」または同様のパラメータ等の、少なくとも１つの追加的パラメータを含むことができる。いくつかの実施形態において、値は、顧客により特に指定されないかぎり複製されていないインスタンスが生成されるよう、デフォルトで「ｆａｌｓｅ」に設定される。いくつかの実施形態において、特定レベルのサービスに対して支払う顧客等の特定の顧客のみが複製されたインスタンスを生成する能力を有する。

いくつかの実施形態において、顧客は、２次レプリカが１次レプリカとは異なるデータゾーンにおいて生成されるかどうかを選択することもできる。顧客は、いくつかの実施形態においては、インスタンスに対して１つまたは複数の特定のデータゾーン、または、例えば、順序立てられたリストを選択することを許可することができるが、一方、他の実施形態においては、顧客は少なくとも１次レプリカに対してはデータゾーンを選択できない。例えば、顧客が２つのデータゾーンを指定し、データゾーンのうちの１つが長期間にわたり利用不可能となる場合、いくつかの実施形態においては、耐久性要件により、他のレプリカが第３のデータゾーン等において生成されることとなるであろう。これにより、複数の顧客に対するデータゾーンリストの順序を管理および更新することが要求する可能性もある。このことは、ユーザ経験を複雑なものとするのみで、顕著な利点はまったくもたらさない。さらに、いくつかのアプリケーションフリートが２次レプリカとして同一のデータゾーンに配置されるよう、アプリケーションが関連するアプリケーションフリートを複数のデータゾーンにわたって分散させるほうがより容易となる可能性がある。

いくつかの実施形態において、顧客は複製されたデータインスタンスに対して「ＤｅｓｃｒｉｂｅＤＢＩｎｓｔａｎｃｅ」または同様のＡＰＩをコールすることができる。それにより、ＲＤＳは、１次レプリカのエンドポイントＤＮＳ名および１次レプリカが現在は位置されているデータゾーン等の情報をリストすることができる。顧客は、単一のデータゾーンに対して用いられる従来の手法を用いて、ＲＤＳインスタンスと通信することができる。なぜなら、ＲＤＳインスタンスの状態が例えば「Ａｖａｉｌａｂｌｅ」となりエンドポイントＤＮＳ名を用いてインスタンスに接続されると直ちに顧客はデータストアのエンドポイントＤＮＳ名を受信することができるためである。レプリカの障害の場合、ＲＤＳは、データベースを対応する２次レプリカにフェイルオーバすることができ、エンドポイントＤＮＳ名は新規の１次レプリカにエイリアスされるであろう。データベースのエンドポイントＤＮＳ名は、多くの実施形態において、一定に保たれ、複製されたインスタンスの存続期間の間、変化しない。

いくつかの実施形態において、例えば、「ｔｒｕｅ」に設定された複製パラメータを有する「ＭｏｄｉｆｙＤＢＩｎｓｔａｎｃｅ」または同様のＡＰＩをコールすることにより、顧客は複製されていないインスタンスを複製されたインスタンスに変換する能力が提供される可能性がある。これにより、データベースは、次のメンテナンスウィンドウの間、またはリクエストの直後等の適切な時間において、ＡＰＩコールパラメータ等に依存するよう、複製されたインスタンスに変換することができる。

様々な実施形態は、ブロックデバイスのコンテンツをサーバ間でミラーリングするシェアナッシング複製記憶ソリューションを実装するカーネルモジュール等のブロックレベル複製機構を利用する。ブロックレベル複製機構「ＢＬＲＭ」は、ブロックデバイス（すなわち、ハードディスクまたは論理ボリューム）上で動作することができる。ブロックレベル複製機構はプライマリ・スレーブ複製アーキテクチャを利用し、このアーキテクチャにおいては、１次レプリカがすべての更新を下層のブロックデバイスに送る。ブロックデバイスに対するすべての入出力（Ｉ／Ｏ）リクエストは、すべての書込操作が同時且つ自動的に複製される状態で、ＢＬＲＭカーネルモジュールにより傍受される。ＢＬＲＭは、ピアデバイスの固有の障害検出を提供し、ピアノードが到達不可能である場合、適切なリカバリハンドラーを発動させる。ＢＬＲＭは、１次レプリカにおけるデータアクセスと干渉することなく、一時的に利用不可能となったノードをバックグラウンドでデータの最新版に自動的に再同期することができる。ＢＬＲＭは、世代識別子（「ＧＩ」）を利用することにより、複製されたデータの世代を特定することができる。それにより、ＢＬＲＭは、２つのノードが同一のレプリカペアのメンバであるかどうか、バックグラウンドの再同期（もし必要である場合）の方向、および部分的なまたは完全な再同期が必要であるかどうか等の態様を判定することができる。ＢＬＲＭドライバは、レプリカペアの初期化時、切断された待機レプリカが１次レプリカに切替えられるとき、またはプライマリロールのリソースが２次レプリカから切断されるとき等の任意の適切な時間において、新規世代を開始することができる。本明細書においてはブロックレベル複製機構が説明のために１例として用いられているが、任意の他の適切なブロックレベル技術または機構を、様々な実施形態の範囲内で、用いることができることを理解すべきである。

前述のように、様々な実施形態におけるＲＤＳデータインスタンスは、１つまたは複数のシステムまたはプラットフォーム上で構築することができる。例えば、インスタンスは、顧客がウェブサービスまたは他の適切な手法を用いることにより様々なオペレーティングシステムでインスタンスを起動することおよびこれらのインスタンスを管理することを可能とする仮想コンピューティング環境上で構築することができる。係る仮想コンピューティング環境を提供するウェブサービスの１つの例は、Ａｍａｚｏｎ．ｃｏｍ， Ｉｎｃ．社が提供する、Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ（ＥＣ２）サービスである。データインスタンスは、インスタンスの存続期間に関わらず永続するオフインスタンスストレージを提供することができるブロックレベルストレージ機構上でも構築することができる。ブロック記憶機構は、インスタンスにアタッチすることができ、かつインスタンス内のデバイスとして公開される可能性がある、ストレージボリュームを提供することができる。ブロック記憶プラットフォームの１例が、２００８年８月８日に出願された、「Ｍａｎａｇｉｎｇ Ａｃｃｅｓｓ ｏｆ Ｍｕｌｔｉｐｌｅ Ｅｘｅｃｕｔｉｎｇ Ｐｒｏｇｒａｍｓ ｔｏ ａ Ｎｏｎ−Ｌｏｃａｌ Ｂｌｏｃｋ Ｄａｔａ Ｓｔｏｒａｇｅ」を発明の名称とする、同時係属中の米国特許出願第１２／１８８，９４９号において提供され、この米国特許出願第１２／１８８，９４９号は、参照により本明細書に組み込まれる。論理ボリューム（例えば、ＬＶＭ層）は、顧客データベースをＬＶＭ／ファイルシステム層上で実行することができるように、ブロックストレージボリュームおよび適切なファイルシステムの上に構築することができる。１つの実施形態における複製されたデータベースに対して、ＢＬＲＭはＬＶＭ層上で実行することができる。係る実施形態におけるＢＬＲＭは、すべてのＩ／Ｏリクエストを傍受し、これらのリクエストを論理ボリュームに送信する。次いで、この論理ボリュームはこれらのリクエストを複数のブロックストレージボリュームにわたって分割することができる。論理ボリュームを用いることにより、複数のブロックストレージＥボリュームを取り扱う能力、ならびに、ストレージを容易に拡張する能力、その他が提供される。ＢＬＲＭをＬＶＭ上に層状にすることにより、書込操作を複数のレプリカにわたって複製することも可能となる。

図３は、複製されたＲＤＳインスタンスを提供する１次・２次複製モデルを実装する機構３００の１例を示す。この例において、１次レプリカ３１０および２次レプリカ３１２は、データプレーン３０８またはデータベース環境の異なるデータゾーン（１および２）に配置される。各レプリカは、 各レプリカに対するブロックストア３２０および３２２へのＩ／Ｏを管理するためのＢＬＲＭ層３１８および３２２としてここで図示されるブロックストレージ機構上に構築される。図２を参照して説明されたのと同様である場合があるもののようなコントロールプレーン３０６のコンポーネントは、設定コマンドを、例えば必要なセットアップ操作を実行することができるローカルホストマネージャ３１４および３１６に発行することにより、複製されたＲＤＳインスタンスを生成することができる。図面に見られるように、ＢＬＲＭ３１８および３２２等のブロックレベル機構は、ブロックデバイスレベルにおいてすべてのＩ／Ｏリクエストを傍受し、リクエストに関する情報をローカルディスクおよび遠隔ディスク３２０および３２４に書き込むよう、配置される。この例において、データベース３１８（例えば、ＳＱＬ）は、１次レプリカ３１０においてのみ実行され、すべてのクライアント３０２は、１次レプリカ３１０で（適切なネットワーク３０４を介して）、それらのデータベーストランザクションを実行する。データベース３１８は２次レプリカ３１２上では実行されず、ファイルシステムも２次レプリカ上にマウントされない。なぜなら、データベースは一般に下層デバイスにおける更新を認識しないからである。

各データベースクライアント３０２は、ＲＤＳデータベースＤＮＳエンドポイント名を用いることにより、現在の１次レプリカ自動的に発見することができる。なお、このＲＤＳデータベースＤＮＳエンドポイント名は、１次レプリカ３１０のホスト名にエイリアスすることができる。ＤＮＳを用いて現在の１次レプリカを発見することにより、例えばネイティブなＭｙＳＱＬクライアント、ＪＤＢＣ、ＰＨＰ、Ｃ＃、およびＨａｓｋｅｌｌ等の既存のデータベースクライアントとの互換性を維持することができる。ＤＮＳキャッチングは、潜在的に顧客を古い一時レプリカに接続するように試行させ、顧客は、第２レプリカと接続することにより、第２レプリカではデータベースが実行されていないので、データベースと対話することができないようになる。次いで、顧客は適切なＤＮＳ情報を取得することを知ることができる。

１つの実施形態に係る、顧客に対する複製されたＲＤＳインスタンスを生成するプロセス４００の１例が、図４に示される。本明細書において用語「顧客」は、データの「所有者」、またはＲＤＳシステムによりホストされるデータストアもしくはインスタンスを指すために用いられるが、用語・顧客は単に１つの例であり、任意の適切なユーザまたは開発者は、様々な実施形態において、コントロールプレーンおよびデータプレーンへアクセスすることが許可されていることを理解すべきである。さらに、データ環境の制御に関する実施形態が説明されるが、同様の手法を、制御環境から分離された環境における様々な他のコンポーネント、デバイス、アプリケーション、サービス、または他の係るリソースを制御および／または管理するために用いることができることを理解すべきである。このプロセスのステップが、特定の実施形態に対する例として提示される。しかし、様々な実施形態の範囲内で、追加のステップ、より少ないステップ、および／または代替的なステップを、異なる順序で、および／または並列的にまたは同時に、実行することができることを理解すべきである。

この例において、顧客はＣｒｅａｔｅＤＢＩｎｓｔａｎｃｅまたは同様のＡＰＩをコールし（４０２）、ウェブサービスティアのコンポーネントは、コールを解析し、顧客により供給されたデータベース生成パラメータを管理データストアに記憶させること（４０４）ができる。データベースのライフサイクルは、データベースを生成するタスクまたはジョブがスイーパーコンポーネントによりピックアップされるように、記録が「ＰＥＮＤＩＮＧ」の変化状態とともに管理データストアに正常にコミットされたとき、「ＣＲＥＡＴＩＮＧ」等の値により標識される可能性がある。ウェブサービスティアは、動作を起動し、その後ワークフローがタスクを開始したかどうかを確認する、２つの位相のタスクを避けるため、この実施形態においては、ワークフローシステムを直接的にコールすることにより、動作を開始することはない。スイーパーにより取得されるリクエストを単に保存することにより、ワークフロー動作はまったく失われない。

前述のように、スイーパーは新規ジョブを求めて管理データストアを周期的にポーリングする。例えば、ライフサイクルとＣＲＥＡＴＩＮＧおよびＰＥＮＤＩＮＧの変化状態とを有するデータベースレコードが存在すると、スイーパーは「ＣｒｅａｔｅＤａｔａｂａｓｅ」または同様のワークフローを起動することができる（４０６）。ワークフローの初期タスクとして、データベースの変化状態を「ＡＰＰＬＹＩＮＧ」等の値に更新することができる。それにより、他のスイーパーは変化が進行中であることを認識する。ワークフローの他の１次タスクは、１次レプリカとして動作するインスタンスを生成すること（４０８）と、１次レプリカから２次レプリカを生成すること（４１０）と、２次レプリカを１次レプリカに接続すること（４１２）とを含む。一度レプリカが接続され利用可能となると、ＲＤＳインスタンスは顧客に公開され、ＤＮＳ名を用いてアクセス可能となる（４１４）。様々な実施形態において、２次レプリカに対するスケール計算が「舞台裏」で実施され、それにより、２次レプリカは、複製および／またはフェイルオーバのためにレプリカを接続する前に、スケーリングすることができる。

図５は、一実施形態にしたがって１次レプリカを生成するために用いることができる係るプロセスの部分５００の１例を示す図である。前述のように、ワークフローは、ＲＤＳインスタンスを構成するすべてのリソースをプロビジョンする初期ステップを取ることができる。例えば、ＲＤＳ特有のマシンイメージを用いて、１次ホストに対するデータインスタンスが生成される（５０２）。ブロックストレージボリュームは、１次ホストに対して割り当てられアタッチすることができる（５０４）。ボリュームは、個々のボリュームの最大サイズおよびボリュームの望ましい最小個数等の態様を指定する設定情報に少なくとも部分的に基づいてリクエストされる可能性がある。予約済みＩＯＰＳが保証される場合、単一のボリュームが用いられる可能性がある。一度コアリソースのそれぞれが利用可能となると、ワークフローは１次レプリカに割り当てられたデータインスタンスにブロックストレージボリュームをアタッチする。

いくつかの実施形態において、顧客データベースに対してファイアウォールと同様の機能を実行するセキュリティグループが生成される。セキュリティグループは、顧客がデータベースと通信できる、またはどのデータインスタンスがデータベースと通信できるかを定義することができ、例えば、インターネットプロトコル（ＩＰ）アドレス等のアドレスを定義することを可能にすることができる。

ワークフローは、ホストマネージャをダウンロードし、チェックサムを確認または他の方法でダウンロードを確証し、次いで、ＴｏｍｃａｔインストールアプリケーションＡＰＩ等の適切なインストールインターフェースをコールすること等により、ホストマネージャがインストールされ開始されること（５０６）を可能にする。一度ホストマネージャがインストール後に正常に開始されると、データインスタンスは、データベースエンジンをインストールし顧客データベースを設定するのに必要な機能性を有することができる。

一度１次レプリカが実行されると、ワークフローは、ホストマネージャにより１次レプリカに対して実行される様々な動作をリクエストすることができる。例えば、ホストマネージャは、ブロックストレージボリュームがマウントされ、ファイルシステムが準備されること（５０８）をリクエストすることができる。特定の実施形態において、ブロックストレージボリュームのマウントおよびファイルシステムの構築は、２つのロールすなわちバイナリロールおよびデータロールのそれぞれに対して実行される。１つの実施形態において、コントロールプレーンは、マウントポイントと各ロールに対して用いられるボリュームとに関する情報をホストマネージャに提供するストレージ設定ファイル（例えば、ＸＭＬファイル）を送信する。この情報を用いて、ホストマネージャは、所与のロールに対してプロビジョンされたすべてのボリュームに対する物理デバイスを生成し、各ロールに対してこれらのデバイスにわたるデータをストライプする論理ボリュームを生成することができる。一度、論理ボリュームが生成されると（５１０）、ホストマネージャは、それ自体を唯一のレプリカとして、ＢＬＲＭ設定ファイルをインストールし、ＢＬＲＭカーネルモジュールを開始することにより、ＢＬＲＭ設定情報を生成することができる。一度、ＢＬＲＭが設定情報を用いて開始されると（５１２）、ＢＬＲＭは自動的にデータボリュームに対するすべてのＩ／Ｏアクセスを処理することができる。

次いで、ワークフローは１次レプリカに対するホストマネージャにパケットマネージャ（例えば、ＲＰＭ）公開署名鍵、または他のセキュリティ機構をインストールすることができる。次いで、１次レプリカに対するホストマネージャは、データインスタンス上のホストマネージャが、署名された情報をダウンロードおよび確認した後、パッケージの開梱、インストール、および起動すること等により、データベースエンジンをダウンロードおよびインストールすることができる（５１４）。続いて、１次レプリカに対するホストマネージャは、顧客データベースの基礎として用いられる空白データベースをインストールすることができる。ＲＤＳ特有の空白データベースを用いて開始することにより、管理のために用いられる許可およびテーブルが容易に適用される。ホストマネージャは、顧客リクエスト内に指定されるように、顧客データベースを生成し、データベースに対するルートパスワードを変更し、マスターデータベースユーザを生成することができる（５１６）。次いで、ワークフローはデータベース（例えば、ＭｙＳＱＬ）を開始することができる（５１８）。

データベースが開始されると、ＢＬＲＭリソースが切断され、ビットマップがクリアされる。ワークフローにより、１次ホストのブロックストレージボリュームに対するスナップショットがキャプチャされ、１次インスタンスのホストマネージャは新規の一般インスタンスを生成するよう命令される可能性がある。次いで、ホストマネージャは、２次ホスト名を有する新規ＢＬＲＭ設定ファイルをインストールするよう命令され、ホストマネージャは設定情報をリロードすることができる。

一度少なくともいくつかの上述のワークフロー例のタスクが完了されると、ワークフローは、２次レプリカの構築に関するタスクに移行することができる。図６は、様々な実施形態にしたがって用いることができる少なくとも１つの２次レプリカまたは待機レプリカを生成するためのプロセス例６００のステップを示す。第１タスクとして、ブロックストレージボリュームは１次レプリカに対するデータボリュームのブロックストレージスナップショットから生成され（６０２）、ボリュームをバイナリに対して生成することができる。次いで、ワークフローにより、データインスタンスが起動され、割り当てられたボリュームがアタッチされる（６０４）。上述のように、スケール計算が、１次レプリカと接続される前に、２次レプリカに対して実行される。次いで、ホストマネージャが、２次レプリカに対して起動される（６０６）。一度ホストマネージャが２次レプリカに対して実行されると、ワークフローは、２次インスタンスを設定するよう、ホストマネージャをコールすることができる。設定プロセスの間、ホストマネージャはボリュームを設定し（６０８）、ＢＬＲＭ設定ファイルを適切な１次レプリカおよび２次レプリカ設定を用いてインストールし（６１０）、ＢＬＲＭがインストールされたかどうかを判定し、カーネルモジュールを開始し、その後ＢＬＲＭハンドラを始動することができる（６１２）。この時点において、１次レプリカおよび２次レプリカは接続され、クリアビットマップコールが発行された時点から同期すべきである。次いで、ワークフローは、管理データストアにおいてデータベースに「Ａｖａｉｌａｂｌｅ」と標識することができ、顧客に対してインスタンスを利用可能とすることができる（６１４）。

一度インスタンスに対する１次レプリカおよび２次レプリカが実行され顧客に対して利用可能となると、顧客は、インスタンスに関するいくつかの動作のうちの任意のものを実行することができる。例えば、顧客は、１つまたは複数のデータベースを記述するために、リクエストをウェブサービス層のＡＰＩまたはコマンドラインツールに送ることができる。ウェブサービスは、リクエストにより指定された顧客データベース（単数または複数）の現在状況を求めて管理データストアを照会することにより、リクエストを直ちに実現することができる。ペンディング状態の更新の場合、現在値および変更値は、顧客に表示される可能性がある。

いくつかの状況において、顧客は顧客データベースを再起動するために「ＲｅｂｏｏｔＤＢＩｎｓｔａｎｃｅ」ＡＰＩ等のＡＰＩをコールしてもよい。１つの実施形態においては、このＡＰＩは、顧客がデータベースエンジンを再起動することを可能にするのみで、ＲＤＳインスタンスを再起動することを可能にはしない。ウェブサービス層は、情報を管理データストア（または他の係るジョブ待ち行列）に記憶することができる。それにより、スイーパーはワークフローを開始するための情報をピックアップすることができる。ワークフローは、データベースをリスタートするために１次レプリカのホストマネージャをコールすることができる。様々な実施形態におけるこのＡＰＩの実装は、複製されたインスタンスと複製されていないインスタンスとの間で異ならない。

顧客は、例えば、ＡＰＩまたはコマンドラインツールを用いて、顧客データベースを削除するリクエストを送信してもよい。それにより、コントロールプレーンのコンポーネントは、削除を準備するよう命令される可能性がある。クレデンシャルおよびリクエストパラメータを確認した後、ウェブサービスティアのコンポーネントは、例えば、顧客データベースを、ライフサイクルが生成または削除状態にないなどのような現時点において削除することができることを確認することができる。コンポーネントは、管理データストアにおける顧客データベースに対する適切な記録を、削除のライフサイクル状態およびペンディングの変化状態へと更新することもできる。完了されるべきタスクを求めて周期的にポーリングを行うワークフロースイーパーは、ペンディングの変化状態により、データベースが削除されるべきことを識別することができ、削除を完了するために、ワークフローインスタンスを起動することができる。ワークフローの第１動作またはタスクは、他のスイーパーが、変化が進行中であることを認識するよう、データベースの変化状態をＡＰＰＬＹＩＮＧに更新することができる。

ワークフローインスタンスは、任意の残余のイベントログを取得し、１次レプリカおよび２次レプリカに対して割り当てられたリソースを開放することができる。例えば、ワークフローは、ＲＤＳイベントプロセッサに、ＲＤＳインスタンスからイベントを取得させ、次いで、データベースを停止させ、１次レプリカにおけるファイルシステムをアンマウントする。ワークフローは、最終スナップショットが顧客によりリクエストされる場合、またはポリシーにより別段の指示がある場合、データベースのスナップショットが取得されるように導く。インスタンスは、ＲＤＳイベントプロセッサＡＰＩをコールして、イベントプロセッサシステムがインスタンスを以後確実に監視しないようにすることにより、登録が取り消される。ＤＮＳ名を削除し、ブロックストレージボリュームおよびデータインスタンスを開放することができる。ワークフローは、管理データストアにおけるこの顧客データベースに対する記録をＤＥＬＥＴＥＤ状態へと更新することにより、削除を完了することができる。それにより、記録は記録アーカイブに移動され削除される。

顧客がストレージをスケーリングし、および／またはインスタンスに割り当てられた容量を計算することが必要である、または望ましい可能性もある。ストレージをスケーリングする場合、例えば、ボリュームは、ＬＶＭが拡張された状態で、１次レプリカおよび２次レプリカの両方に加えることができる。１次レプリカ上で、ＢＬＲＭハンドラがブロックデバイスの制御下で新規ボリュームを含むためにブロックデバイスを拡張するようコールすることができ、ファイルシステムはリサイズすることができる。

特に、新規ブロックストレージボリューム（単数または複数）は、１次レプリカおよび２次レプリカの両方に対して、現在のボリューム設定パラメータにしたがってプロビジョンすることができる。「ＳｃａｌｅＳｔｏｒａｇｅ」または同様のＡＰＩを両方のインスタンス上のホストマネージャに対して発動することができ、それが、物理デバイスが生成させ、新規ボリュームを既存のボリュームグループに加えさせることができる。ホストマネージャは、例えば、ＬＶＭの物理的範囲を１つの物理的ボリューム（例えば、ブロックストレージボリューム）から別の物理的ボリュームへと移動させることによるなどのようにして、ボリュームグループ内のスペースのバランスを回復することができる。論理ボリュームは、新規スペースを含むよう拡張されてもよい。一度ＳｃａｌｅＳｔｏｒａｇｅ機能が完了すると、ワークフローは、１次インターフェース上のホストマネージャに対して「ｐｒｉｍａｒｙＳｃａｌｅＳｔｏｒａｇｅ」ＡＰＩ等のインターフェースをコールすることができる。それにより、ＢＬＲＭブロックデバイス層は、新規スペースを使用するよう拡張される。一度ＢＬＲＭのリサイズが完了すると、ファイルシステムはリサイズすることができる。残存する更新がもはや存在しなくなると、管理データストアにおける顧客データベースに対する記録は、「ＡＶＡＩＬＡＢＬＥ」のライフサイクル状態に設定することができ、変化状態が「ＮＯＮＥ」に更新される。次いで、リサイズされたインスタンスは、顧客により利用することができる。１次レプリカまたは２次レプリカが、スケーリングプロセスの間に到達不可能である場合、ワークフローは中断されて、例えば、「ＭＯＤＩＦＹＩＮＧ」の状態に保たれる可能性があり、後でリトライすることができる。

計算能力をスケーリングするとき、様々な実施形態は、各クラスに特定の計算能力が割り当てられるよう、顧客がインスタンスに対する「計算クラス」を調節することを可能にする。特定の実施形態においては、２次レプリカが最初にスケーリングされ、次いで、システムは、例えば、フェイルオーバプロセスを用いること等により、２次レプリカに切替えられる。それにより、２次レプリカは新規の１次レプリカとなる。次いで、旧１次レプリカの計算ｏｄｅは必要に応じてスケーリングすることができ、旧１次レプリカは新規２次レプリカとして機能することができる。２次レプリカを最初にスケーリングし、フェイルオーバをステージングすることにより、例えば、複製されたインスタンスはより短いダウンタイムを経験することができる。これは、単一のデータゾーンにおいてインスタンスクラスをスケールする場合に、別法により生じる場合がある。

以下の記載は、データベースインスタンスをスケーリングするためのプロセスの特定の例を提供する。なお、この例においては、複製されたインスタンスが１次レプリカＰおよび２次レプリカＳを有する。新規インスタンスクラスを有し、かつ既存のインスタンスと同一のセキュリティグループを有する新規インスタンス（例えばＰ_ｎｅｗおよびＳ_ｎｅｗ）を１次レプリカおよび２次レプリカの両方に対してプロビジョンすることができる。
Ｐ_ｎｅｗおよびＳ_ｎｅｗは、それぞれ、ＰおよびＳと同一のデータゾーンに生成することができる。管理データストアにおけるＲＤＳインスタンスの状態は、「ＩＮ＿ＭＯＤＩＦＩＣＡＴＩＯＮ」等の値に更新することができる。インスタンス識別子は、ワークフローによりスケーリングのためにデータベースが停止されるとき、１次レプリカおよび／または２次レプリカの回復がトリガされないよう、イベントプロセッサから登録を取り消すことができる。２次インスタンスの状態は、「ＩＮ＿ＭＯＤＩＦＩＣＡＴＩＯＮ」等の値に更新することができる。２次レプリカ上において、ホストマネージャは、例えば、データベースを停止し、（例えば、ＢＬＲＭ切断コマンドを発行することにより）１次インスタンスから切断し、すべてのファイルシステムをアンマウントし、すべてのボリュームグループを不活性化すること等により、既存のブロックストレージ機構の使用を停止するようリクエストすることができる。ブロックストレージボリュームは、Ｓからデタッチされ、Ｓ_ｎｅｗにアタッチされる。次いで、ホストマネージャはＳ_ｎｅｗ上にインストールされ、ボリュームグループを活性化するよう要求することができる。次いで、１次レプリカが、例えば、データベースをシャットダウンし、ボリュームをアンマウントすること等により、停止することができ、すべてのブロックストレージボリュームをデタッチすることができる。Ｓ_ｎｅｗへのフェイルオーバは、データベースエンドポイントをＳ_ｎｅｗにポイントすることにより開始することができる。これにより、Ｓ_ｎｅｗが新規１次レプリカとなる。Ｓ_ｎｅｗ上のホストマネージャがファイルシステムをマウントするよう要求される可能性があり、クレデンシャル（例えば、ＲＰＭ公開鍵）は新規インスタンス上のホストマネージャに送られる可能性がある。次いで、Ｓ＿ｎｅｗ上のホストマネージャがデータベースを開始するよう要求される可能性があり、データベースはＡＶＡＩＬＡＢＬＥと標識される可能性がある。この段階で、２次が生成途中であるにも関わらず、データベースの使用準備が整ったことになる。次のステップとして、Ｐ_ｎｅｗインスタンスを開始することができ、以前ＰにアタッチされていたブロックストレージボリュームをＰ_ｎｅｗにアタッチすることができる。ホストマネージャをＰ_ｎｅｗ上にインストールすることができ、ＢＬＲＭ設定ファイルがインストールされる。この実施形態においては、いかなるファイルシステムも、この時点ではＰ_ｎｅｗにマウントされていない。次いで、Ｓ_ｎｅｗをＰ_ｎｅｗに接続し接続状態を確認するコマンドを、Ｓ_ｎｅｗ上のホストマネージャに対して発行することができる。次いで、スケーリングされたレプリカを、顧客によるアクセスのために提供することができる。

実施形態は、例えば、スナップショットまたは他のポイントインタイムバックアップを生成すること等により、ユーザがユーザのインスタンスに情報をバックアップすることも可能にすることができる。例えば、ＲＤＳは、顧客が、顧客のインスタンスのスナップショットを生成すること、およびこれらのスナップショットから新規インスタンスを生成することを可能にすることができる。スナップショットは、複製されたデータベースに対してポイントインタイムリカバリを実行するためにも用いることができる。複製されていないインスタンスのスナップショットを生成するために、ワークフローはデータベースボリュームに対するＩ／Ｏを効果的にサスペンドし、インスタンスにアタッチされたボリュームのブロックストレージレベルスナップショットを取得し、ボリュームのサスペンドを停止する。複製されたインスタンスに対するスナップショットを生成するとき、スナップショットは２次レプリカにおいて取得することができる。このため、２次レプリカを一時的に切断することができ、すべてのブロックストレージボリュームのスナップショットが取得される。スナップショットが取得された後、２次レプリカは再接続することができる。
バックアップを有効化することにより、顧客は、時間が過去Ｘ日以内であるかぎり、所与の時間ポイントにインスタンスをリストアする能力を有する。なおここで、Ｘは顧客に対する保持期間である。

顧客が複製されていないインスタンスにおいてバックアップを有効化すると、バックアップウィンドウの間、毎日等の定期的間隔においてインスタンスに対してスナップショットを取得することができ、ログ記録は５分毎等の他の間隔においてバックアップすることができる。顧客がインスタンスを、例えばｔ₁等の時間ポイントにリストアすることを望むと、インスタンスは、所望時間に最も近接するが、しかし所望の時間ポイントより前の時間のスナップショットから生成され、ログ記録は、状態がその時間ポイントをミラーするようロールフォワードするように用いることができる。複製されたインスタンスにおいて、ログ記録が１次レプリカからバックアップされる一方で、スナップショットは２次レプリカ上で取得することができる。

１つの実施形態において、ホストマネージャへのすべての通信チャンネルは、セキュアソケット層（ＳＳＬ：ｓｅｃｕｒｅ ｓｏｃｋｅｔ ｌａｙｅｒ）上でハイパーテキスト転送プロトコルを用いてセキュアにされる。ホストマネージャアプリケーションをホストする各アプリケーションサーバは、インスタンスの起動時にスクリプトを用いてスタートすることができる。アプリケーションサーバエンジンをスタートする前に、自己署名証明書を生成し、証明書をインストールしてＳＳＬ通信チャンネル（単数または複数）を有効化するスクリプトが実行することができる。ＳＳＬ通信は、１つの実施形態においては、通信チャンネルを暗号化するために使用され、クライアント認証を暗号化するためには使用されない。代わって、クライアント認証は、各リクエストに埋め込まれた公開／秘密鍵署名により達成される。それにより、１つの実施形態において、すべてのクライアントは秘密鍵を用いて照会文字列パラメータを署名する。この署名は、カスタムインターセプタにより確認することができ、このインターセプタは、ホストマネージャに対するアプリケーションサーバとともに配置することができる。さらに、セキュリティグループ（すなわち、ファイアウォールルール）を、データプレーンにおいて、監視されたインスタンスのそれぞれに対して設定することができる。その結果、所定のネットワークまたはセキュアグループに属するホストのみが、ホストマネージャポートを用いて通信できる。セキュア情報およびクレデンシャル（秘密鍵等）は、鍵管理およびローテーション等の機能性を提供することができる適切な鍵ストアに記憶することができる。

上述のように、ログファイルも同様の方法でバックアップすることができる。ログ記録は、データファイルのリストアが必要な場合に様々なトランザクションをリプレイする等のタスクを実行するために用いることができる。エンジンログ記録を、以前にバックアップされたログファイルが簡単なリストコマンドを用いて獲得することができるように、適切なストレージ位置にコピーすることができる。ホストマネージャはこの結果を用いて、コピーする必要があるログ記録が存在するかどうかを判定する。例えば、ホストマネージャは、最後のシーケンスをバックアップすることができるように、書き込まれたログファイルのリストを取得するために、バケットリストを要求することができる。新規ログファイルが生成された場合、ログ記録がデータベースエンジンにより動的でなく書き込まれていることがまず判定され、次いで、ログ記録はコピーされ、コピーが正常に実行されたことが確認される。

上述のように、様々な実施形態は広範囲の様々な動作環境において実装することができる。なお、この動作環境は、いくつかの場合においては、１つまたは複数のユーザコンピュータ、計算デバイス、または多数のアプリケーションのうちの任意のものを動作するために用いることができる処理デバイスを含むことができる。ユーザまたはクライアントデバイスは、標準的なオペレーティングシステムを実行するデスクトップまたはラップトップコンピュータの他に、モバイルソフトウェアを実行し、多数のネットワークおよびメッセージングプロトコルをサポートすることができるセルラ、無線、ハンドヘルドデバイス等の、多数の汎用パーソナルコンピュータのうちの任意のものを含むことができる。係るシステムは、商業的に入手可能な様々なオペレーティングシステムのうちの任意のもの、および開発もしくはデータベース管理等の目的の他の既知のアプリケーションを実行する多数のワークステーションも含むことができる。これらのデバイスは、ダミーターミナル、シンクライアント、ゲーム用システム、および、ネットワークを介して通信する能力を有する他のデバイス等の、他の電子装置も含むことができる。

様々な態様も、少なくとも１つの、サービス指向アーキテクチャの一部であってもよいものなどのようなサービスまたはウェブサービスの一部として、実装することができる。
ウェブサービス等のサービスは、拡張可能マークアップ言語（ＸＭＬ）形式において、かつＳＯＡＰ（「Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ」に由来する）等の適切なプロトコルを用いて交換されるメッセージを用いること等により、任意の適切な種類のメッセージングを用いて、通信を行うことができる。係るサービスにより提供または実行されるプロセスは、ウェブサービス記述言語（ＷＳＤＬ）等の、任意の適切な言語で書き込むことができる。ＷＳＤＬ等の言語を用いることにより、様々なＳＯＡＰフレームワークにおけるクライアント側コードの自動生成等の機能性が可能になる。

大部分の実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋ等の、様々な商業的に入手可能なプロトコルの任意のものを用いて通信をサポートするために、当業者に周知である、少なくとも１つのネットワークを利用する。ネットワークは、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびこれらの任意の組合せとすることができる。

ウェブサーバを利用する実施形態において、ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａサーバ、およびビジネスアプリケーションサーバを含む、様々な任意のサーバまたはミッドティアアプリケーションを実行することができる。サーバ（単数または複数）は、例えば、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃、もくしはＣ＋＋、または、Ｐｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬ等の任意のスクリプト言語、ならびにこれらの組み合わせ等の任意のプログラム言語で書かれた１つまたは複数のスクリプトまたはプログラムとして実装された、１つまたは複数のウェブアプリケーションを実行する等により、ユーザデバイスからのリクエストに応答して、プログラムまたはスクリプトを実行する能力を有する。サーバ（単数または複数）は、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）から商業的に入手可能なサーバを非限定的に含むデータベースサーバも含んでもよい。

環境は、上述のように、様々なデータストアおよび他のメモリ媒体および記憶媒体を含むことができる。これらは、１つまたは複数のコンピュータに対してローカルである（および／または１つまたは複数のコンピュータ内に常駐する）記憶媒体、またはネットワーク上のすべてのコンピュータのうちの任意のものまたは全部から遠隔にある記憶媒体等の、様々な位置に常駐することができる。特定の組の実施形態においては、情報は、当業者に周知であるストレージエリアネットワーク（「ＳＡＮ」）に存在する。同様に、コンピュータ、サーバ、または他のネットワークデバイスに帰属する機能を実行するために必要なファイルは、適宜、ローカルおよび／またはリモートに記憶されてよい。システムがコンピュータ化されたデバイスを含む場合、係るデバイスはそれぞれは、ハードウェア要素を含むことができる。なお、これらのハードウェア要素は、バスを介して電気的に接続されてもよく、それらの要素は、例えば、少なくとも１つの中央処理装置（ＣＰＵ）、少なくとも１つの入力装置（例えば、マウス、キーボード、コントローラ、タッチスクリーン、またはキーパッド）、および少なくとも１つの出力装置（例えば、ディスプレイ装置、プリンタ、またはスピーカ）を備えるものである。係るシステムは、例えば、ディスクドライブ、光記憶装置、および、ランダムアクセスメモリ（「ＲＡＭ」）または読み出し専用メモリ（「ＲＯＭ」）等の固体記憶装置の他に、着脱可能な媒体デバイス、メモリカード、フラッシュカード、その他等の、１つまたは複数の記憶装置も備えてもよい。

係るデバイスは、コンピュータ可読記憶媒体リーダ、通信デバイス（例えば、モデム、ネットワークカード（無線および有線）、赤外線通信デバイス、その他）、および上述のワーキングメモリも含むことができる。コンピュータ可読記憶媒体リーダは、コンピュータ可読ストレージ媒体と接続することができ、またはコンピュータ可読記憶媒体を受容するよう構成することができる。なお、コンピュータ可読記憶媒体は、リモート、ローカル、固定、および／または着脱可能記憶装置の他に、一時的に、および／または、より永続的に、コンピュータ可読情報を含む、記憶する、転送する、および取得する記憶媒体を指す。システムおよび様々なデバイスは、一般的に、オペレーティングシステムおよびクライアントアプリケーションまたはウェブブラウザ等のアプリケーションプログラムを含む、少なくとも１つのワーキングメモリデバイス内に配置された、いくつかのソフトウェアアプリケーション、モジュール、サービスまたは他の要素を含むであろう。代替的な実施形態が上述したものからの多数の変化例を有してもよいことを理解すべきである。例えば、カスタマイズされたハードウェアも用いられてもよく、および／または、特定の要素がハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）、またはその両方で実装されてもよい。さらに、ネットワーク入出力デバイス等の他の計算デバイスへの接続が用いられてもよい。

コードまたはコードの一部を収容するための記憶媒体およびコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、または所望の情報を記憶することができ、システムデバイスによりアクセスすることができる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータ等の情報の記憶および／または伝送のために任意の方法または技術で実装された、揮発性および不揮発性、ならびに着脱可能および着脱不能の媒体などのような、しかしこれらに限定されない、記憶媒体および通信媒体を含む、当該分野で周知または用いられる任意の適切な媒体を含むことができる。本明細書に提供された開示および教示に基づいて、当業者は、様々な実施形態を実装する他の手法および／または方法を理解するであろう。

したがって、本明細書および図面は、限定的な意味よりもむしろ例示的な意味においてとらえられるべきである。しかしながら、特許請求の範囲において説明される本特許の広範な精神および範囲から逸脱することなく、様々な変更例および変化例がそこになされてもよいことは明白であろう。

（付記項１）
制御環境の１つまたは複数のセルフサービスウェブサービスを用いて、データベース環境において、複製されたリレーショナルデータベースインスタンスをプロビジョニングするための、コンピュータ実装された方法であって、
実行可能命令により設定された、１つまたは複数のコンピュータシステムの制御下で、 それぞれが前記ユーザにウェブサービスリクエストを制御環境に発行することを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、別個のデータベース環境において、前記ユーザに対してリレーショナルデータベースに関して実行される所望の動作に対応する、提供することと、
前記複数のＡＰＩの内の第１ＡＰＩを通しての、前記ユーザから前記制御環境へのウェブサービスリクエストの受信に応答して、
１次インスタンスレプリカを前記データベース環境の第１データゾーンにおいてプロビジョンすること、
前記１次レプリカインスタンスにデータベースエンジンをインストールすることと、 ２次インスタンスレプリカを、前記１次インスタンスレプリカの１つまたは複数のスナップショットを用いて、前記データベース環境の第２データゾーンにおいてプロビジョンすること、および
前記１次インスタンスレプリカに対する任意の読み出しおよび書き込みを傍受し、前記１次インスタンスレプリカに対する任意のデータ更新を前記２次インスタンスレプリカに対して同時に更新するよう構成された、ブロックレベル複製機構を１次インスタンスレプリカおよび２次インスタンスレプリカのそれぞれに接続すること、
のタスクを含むワークフローをインスタンス化することと、
前記ユーザが前記１次レプリカインスタンスにインストールされた前記データベースエンジンと相互作用することを可能にし、前記１次インスタンスレプリカの障害時に前記ユーザが前記２次インスタンスレプリカと相互作用することができるよう更新可能である、エイリアス名を前記ユーザに提供することと、
を含む方法。

（付記項２）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれは、前記データベース環境において別個のデータインスタンス上で実行され、各データインスタンスは１つまたは複数の専用ブロックストレージボリュームにアタッチされる、付記項１に記載のコンピュータ実装された方法。

（付記項３）
前記ブロックレベル複製機構は、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカの前記１つまたは複数の専用ブロックストレージボリュームの間でデータを同時に複製するよう動作可能である、付記項２に記載のコンピュータ実装された方法。

（付記項４）
ユーザが、データベース環境において、別個の制御環境を用いて、複製されたデータベースインスタンスを生成することを可能にするための、コンピュータ実装された方法であって、
実行可能命令により設定された、１つまたは複数のコンピュータシステムの制御下で、 それぞれが前記ユーザにウェブサービスリクエストを前記制御環境に発行することを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記データベース環境において、前記ユーザに対するデータベースに関して実行される所望の動作に対応する、提供することと、
前記複数のＡＰＩの内の１つを通しての、前記ユーザから前記制御環境へのウェブサービスリクエストの受信に応答して、データベースに対する第１インスタンスレプリカおよび第２インスタンスレプリカが前記データベース環境においてプロビジョンされるようにし、ブロックレベル複製機構が、前記１次インスタンスレプリカにおける前記データベースに対する任意の書込操作を傍受し、前記書込操作に対する変化が同時に前記２次インスタンスレプリカに複製されるように構成されるようにすることと、
前記ユーザが、前記１次インスタンスレプリカを介して、前記データベースにアクセスすることを可能にすることと、
を含む方法。

（付記項５）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカは、単一のデータゾーンにおいて、別個の地理的位置における別個のデータゾーンにおいて、複数の地理的位置にわたる単一のデータゾーンにおいて、または単一の地理的領域内の複数のデータゾーンにわたって、プロビジョンされる、付記項４に記載のコンピュータ実装された方法。

（付記項６）
前記制御環境は、前記１次インスタンスレプリカが利用不可能となった場合、前記２次インスタンスレプリカへのフェイルオーバ操作を自動的に実施するよう構成された、付記項４に記載のコンピュータ実装された方法。

（付記項７）
ホストマネージャが前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対してインストールされ、各ホストマネージャが、前記制御環境と通信し、前記データベース環境において１つまたは複数のタスクを実行するように操作可能にすること
をさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項８）
前記２次インスタンスレプリカに対する２次ブロックストレージボリュームは、前記１次インスタンスレプリカに対する前記１次ブロックストレージボリュームのスナップショットを用いて生成される、付記項４に記載のコンピュータ実装された方法。

（付記項９）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカは、前記ユーザから受信された前記ウェブサービスリクエストが、複製されたインスタンスが生成されることを示す複製パラメータ値を含む場合、前記データベース環境においてプロビジョンされる、付記項４に記載のコンピュータ実装された方法。

（付記項１０）
前記ユーザにエイリアス名が提供され、前記エイリアス名は、フェイルオーバ操作により前記２次レプリカが新規の現在の１次インスタンスレプリカとなった場合を含んで、前記ユーザが現在の１次インスタンスレプリカと通信することを可能にする、付記項４に記載のコンピュータ実装された方法。

（付記項１１）
前記複数のＡＰＩの内の１つを通して前記制御環境に対して発行されたウェブサービスリクエストを用いて、前記ユーザが、複製されていないインスタンスを複製されたインスタンスに変換することを可能にすることをさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項１２）
前記複数のＡＰＩの内の１つを通してのウェブサービスリクエストの受信に応答して、前記データベースの、１つまたは複数のスナップショットをキャプチャすることをさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項１３）
前記スナップショットは、前記２次インスタンスレプリカにおいて取得される、第１２節に記載のコンピュータ実装された方法。

（付記項１４）
前記ウェブサービスリクエストに応答して、、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカを前記データベース環境において、プロビジョニング、設定、および接続するための、タスクを含むワークフローを、前記制御環境において実行することをさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項１５）
前記制御環境の少なくとも１つの監視コンポーネントを用いて、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカの健康情報を監視することをさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項１６）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカの設定情報を前記制御環境におけるデータストアに記憶することをさらに含む、付記項４に記載のコンピュータ実装された方法。

（付記項１７）
前記複製技術はデータベースエンジンに対して独立的である、付記項４に記載のコンピュータ実装された方法。

（付記項１８）
ユーザが、データベース環境において、別個の制御環境を用いて、複製されたデータベースインスタンスを生成することを可能にするためのシステムであって、
プロセッサと、
前記プロセッサにより実行されると、前記プロセッサに
それぞれが前記ユーザにウェブサービスリクエストを前記制御環境に発行することを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記データベース環境において、前記ユーザに対するデータベースに関して実行される所望の動作に対応するように、提供させ、
前記複数のＡＰＩの内の１つを通した、前記ユーザから前記制御環境へのウェブサービスリクエストの受信に応答して、データベースに対する第１インスタンスレプリカおよび第２インスタンスレプリカが前記データベース環境においてプロビジョンされるようにし、ブロックレベル複製機構が、前記１次インスタンスレプリカにおける前記データベースに対する任意の書込操作を傍受し、前記書込操作に対する変化が同時に前記２次インスタンスレプリカに複製されるよう構成されるようにさせ、
前記ユーザが、前記１次インスタンスレプリカを介して、前記データベースにアクセスすることを可能にさせる、
ようにさせる命令を含むメモリデバイスと、
を備えるシステム。

（付記項１９）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカは、単一のデータゾーンにおいて、別個の地理的位置における別個のデータゾーンにおいて、複数の地理的位置にわたる単一のデータゾーンにおいて、または単一の地理的領域内の複数のデータゾーンにわたって、プロビジョンされる、付記項１８に記載のシステム。

（付記項２０）
実行されると、前記命令は、前記プロセッサに、
前記ウェブサービスリクエストに応答して、プロビジョンするための、設定するための、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカを前記データベース環境において接続するための、タスクを含むワークフローを、前記制御環境において実行させる、
ようにさらにさせる、付記項１８に記載のシステム。

（付記項２１）
実行されると、前記命令は、前記プロセッサに、
ホストマネージャを前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対してインストールさせ、各ホストマネージャを、前記制御環境と通信し、前記データベース環境において１つまたは複数のタスクを実行するように作動可能にさせる、
ようにさらにさせる、付記項１８に記載のシステム。

（付記項２２）
ユーザが、データベース環境において、別個の制御環境を用いて、複製されたデータベースインスタンスを生成することを可能にするための命令を記憶するためのコンピュータ可読記憶媒体であって、前記命令は、プロセッサにより実行されると、前記プロセッサに、
それぞれが前記ユーザにウェブサービスリクエストを前記制御環境に発行することを可能にする、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を提供することであって、各ＡＰＩは、前記データベース環境において、前記ユーザに対してデータベースに関して実行される所望の動作に対応するように、提供し、
前記複数のＡＰＩの内の１つを通しての、前記ユーザから前記制御環境へのウェブサービスリクエストの受信に応答して、データベースに対する第１インスタンスレプリカおよび第２インスタンスレプリカが前記データベース環境においてプロビジョンされるようにし、ブロックレベル複製機構が、前記１次インスタンスレプリカにおける前記データベースに対する任意の書込操作を傍受し、前記書込操作に対する変化が同時に前記２次インスタンスレプリカに複製されるよう構成されるようにし、
前記ユーザが、前記１次インスタンスレプリカを介して、前記データベースにアクセスすることを可能にする、
ようにさせる、コンピュータ可読記憶媒体。

（付記項２３）
前記第１インスタンスレプリカおよび前記第２インスタンスレプリカは、単一のデータゾーンにおいて、別個の地理的位置における別個のデータゾーンにおいて、複数の地理的位置にわたる単一のデータゾーンにおいて、または単一の地理的領域内の複数のデータゾーンにわたって、プロビジョンされる、付記項２２に記載のコンピュータ可読記憶媒体。

（付記項２４）
前記命令は、実行されると、前記プロセッサに対して、
前記ウェブサービスリクエストに応答して、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカを前記データベース環境においてプロビジョンするための、設定するための、接続するための、タスクを含むワークフローを、前記制御環境において実行させる、
ようにさらにさせる、付記項２２に記載のコンピュータ可読記憶媒体。

（付記項２５）
前記命令は、実行されると、前記プロセッサに対して、
ホストマネージャが前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対してインストールされること、および各ホストマネージャを、前記制御環境と通信し、前記データベース環境において１つまたは複数のタスクを実行するように操作可能にさせること、
をさらにさせる、付記項２２に記載のコンピュータ可読記憶媒体。

Claims (8)

1. 複製されたデータベースのストレージをスケーリングする、コンピュータ実装された方法であって、
   実行可能命令により設定された、１つまたは複数のコンピュータシステムであって、データレポジトリまたはデータストレージを含むデータ環境と、前記データ環境とは別個の制御環境であって、前記データ環境の態様の管理に有用なコンポーネントを含む制御環境とを有するコンピュータシステムの制御下で、
   サービスリクエストを前記制御環境に発行することを可能にするインターフェースを提供することであって、各サービスリクエストは、前記データ環境において、データベースに関して実行される特定の動作に対応する、提供することと、
   前記インターフェースを通しての、前記複製されたデータベースのストレージをスケーリングするための前記サービスリクエストの受信に応答して、
   前記複製されたデータベースの第１インスタンスレプリカおよび第２インスタンスレプリカに対する前記ストレージをスケーリングするためのワークフローを決定し、
   前記第１インスタンスレプリカおよび前記第２インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローを実行し、
   前記第１インスタンスレプリカの書込操作を前記第２インスタンスレプリカに適用するように構成された、前記複製されたデータベースのブロックレベル複製機構が、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対する新しい設定にしたがって、リサイズされるようにし、
   前記第１インスタンスレプリカに関連するドメインネームシステム（ＤＮＳ）名またはネットワークアドレス情報が、前記第１インスタンスレプリカの障害時に前記第２インスタンスレプリカに関連するようにすることと
   を含む方法。
2. 前記サービスリクエストは、ユーザ要求、ユーザ選択、または設定情報の少なくとも１つに基づく、請求項１に記載の方法。
3. 前記第１インスタンスレプリカおよび前記第２インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローは、１つまたは複数のワークフロータスクを含み、前記１つまたは複数のワークフロータスクは、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれのブロックストレージボリュームの個数を新たな個数に変更すること、前記新たな個数のブロックストレージボリュームに従って、１つまたは複数の前記ブロックストレージボリュームをリバランスさせること、前記新たな個数のブロックストレージボリュームに従って、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対する１つまたは複数の論理ボリュームをリサイズさせること、および、前記新たな個数のブロックストレージボリュームに従って、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれに対するファイルシステムをリサイズさせること、のうちの少なくとも１つを含む、請求項１に記載の方法。
4. 前記第１インスタンスレプリカおよび前記第２インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローを実行することは、
   前記第１インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローの実行を開始する前に、前記第２インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローを実行して完了させることと、
   前記第２インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローの実行の完了に応じて、
   前記第１インスタンスレプリカを前記第２インスタンスレプリカにフェイルオーバさせること、および、
   前記第１インスタンスレプリカに対する前記ストレージをスケーリングする前記ワークフローを実行することと
   を含む請求項１に記載の方法。
5. 複製されたデータベースの計算能力をスケーリングする、コンピュータ実装された方法であって、
   実行可能命令により設定された、１つまたは複数のコンピュータシステムであって、データレポジトリまたはデータストレージを含むデータ環境と、前記データ環境とは別個の制御環境であって、前記データ環境の態様の管理に有用なコンポーネントを含む制御環境とを有するコンピュータシステムの制御下で、
   サービスリクエストを前記制御環境に発行することを可能にするインターフェースを提供することであって、各サービスリクエストは、前記データ環境において、データベースに関して実行される特定の動作に対応する、提供することと、
   前記インターフェースを通しての、少なくとも第１インスタンスレプリカおよび第２インスタンスレプリカを有する前記複製されたデータベースの計算能力をスケーリングするための前記サービスリクエストの受信に応答して、
   前記複製されたデータベースの第３インスタンスレプリカおよび第４インスタンスレプリカが、前記データ環境において、特定の計算クラスに従ってプロビジョンされるようにし、
   ブロックレベル複製機構が、前記第３インスタンスレプリカの前記複製されたデータベースに対する書込操作を前記第４インスタンスレプリカに適用するようにし、
   前記第１インスタンスレプリカに関連するドメインネームシステム（ＤＮＳ）名またはネットワークアドレス情報が、前記第３インスタンスレプリカに関連するようにし、
   前記第３インスタンスレプリカに関連する前記ＤＮＳ名または前記ネットワークアドレス情報が、前記第３インスタンスレプリカの障害時に前記第４インスタンスレプリカに関連するようにすることと
   を含む方法。
6. 前記サービスリクエストは、ユーザ要求、ユーザ選択、または設定情報の少なくとも１つに基づく、請求項５に記載の方法。
7. 前記複製されたデータベースの計算能力をスケーリングするワークフローは、１つまたは複数のワークフロータスクを含み、前記１つまたは複数のワークフロータスクは、前記第３インスタンスレプリカおよび前記第４インスタンスレプリカのそれぞれを前記特定の計算クラスに従ってインスタンス化させること、１つまたは複数のブロックストレージボリュームを前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれからデタッチさせること、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれのファイルシステムをアンマウントさせること、前記第１インスタンスレプリカおよび前記第２インスタンスレプリカのそれぞれの１つまたは複数の論理ボリュームを不活性化させること、前記１つまたは複数のブロックストレージボリュームを前記第３インスタンスレプリカおよび前記第４インスタンスレプリカにそれぞれアタッチさせること、前記第３インスタンスレプリカおよび前記第４インスタンスレプリカのそれぞれのホストマネージャをインストールし、開始させること、前記１つまたは複数の論理ボリュームを前記第３インスタンスレプリカおよび前記第４インスタンスレプリカに対してそれぞれ活性化させること、および、前記ファイルシステムを前記第３インスタンスレプリカおよび前記第４インスタンスレプリカに対してそれぞれマウントさせること、のうちの少なくとも１つを含む、請求項５に記載の方法。
8. 前記第３インスタンスレプリカは、前記第４インスタンスレプリカに先立ってプロビジョンされ、
   前記方法は、前記第３インスタンスレプリカの障害時に、前記第１インスタンスレプリカを前記第３インスタンスレプリカにフェイルオーバさせることをさらに含む、請求項５に記載の方法。

Images