JP2007506157A - マルチノードシステムにおけるリソースの動的な割当の階層的管理 - Google Patents

Abstract

マルチノードデータベースサーバにより提供されるサービス間における、マルチノードデータベースシステムのリソースの動的な割当を、効率よく効果的に管理するための手法が用いられる。サービスは、データベースサーバ上でホストされる作業のカテゴリである。これらの手法は、異なるレベルでリソースの割当を管理する。特定のデータベースを使用するサービスに関し、このサービスによって実現される性能が監視される。データベースに割振られたリソースは、これらのサービスの各々についての性能の目標が確実に達成されるように、これらのサービス間で割当てられる。１クラスタのノードに割振られたリソースは、そのデータベースを使用するすべてのサービスについての性能の目標が確実に達成されるように、データベース間で割当てられる。１ファームのクラスタに割振られたリソースは、サービスレベルに関する合意およびバックエンドポリシーに基づき、クラスタ間で割振られる。この手法は、異なるレベルにおいてリソースを管理するために、ディレクタの階層を用いる。

Description

関連出願
本願は、ここに引用により援用される、２００３年８月１４日に出願された米国仮出願第６０／４９５，３６８号、「コンピュータリソースの供給（Computer Resource Provisioning）」の優先権を主張する。本願は、ここに引用により援用される、２００３年９月３日に出願された米国仮出願第６０／５００，０９６号、「分散型システムにおける、サービスベースの作業負荷の管理および測定（Service Based Workload Management and Measurement in a Distributed System）」の優先権を主張する。本願は、ここに引用により援用される、２００３年９月３日に出願された米国仮出願第６０／５００，０５０号、「データベースの自動的かつ動的な供給（Automatic And Dynamic Provisioning Of Databases）」の優先権を主張する。

本願は、以下の米国出願、すなわち、
ここに引用により援用される、２００４年８月１２日にベニー・サウダー（Benny Souder）他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「マルチノードシステムにおけるリソースの動的な割当の階層的管理（Hierarchical Management of the Dynamic Allocation of Resources in a Multi-Node System）（代理人整理番号第５０２７７−２３８２号）」と、
ここに引用により援用される、２００３年１１月２１日に出願された米国出願第１０／７１８，７４７号、「データベースの自動的かつ動的な供給（代理人整理番号第５０２７７−２３４３号）」と、
ここに引用により援用される、２００４年８月１２日にサンジャイ・カルスカー（Sanjay Kaluskar）他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「サーバ全体にわたる透過的なセッション移動（Transparent Session Migration Across Servers）（代理人整理番号第５０２７７−２３８３号）」と、
ここに引用により援用される、２００４年８月１２日にラクシミナラヤナン・チダムバラン（Lakshminarayanan Chidambaran）他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「サービスをホストするマルチノード環境における、サービスの性能グレードの計算（Calculation of Service Performance Grades in a Multi-Node Environment That
Hosts the Services）（代理人整理番号第５０２７７−２４１０号）」と、
ここに引用により援用される、２００４年８月１２日にラクシミナラヤナン・チダムバラン他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「マルチノードシステムにおけるインクリメンタルな実行時セッションの平均化（Incremental Run-Time Session Balancing in a Multi-Node System）（代理人整理番号第５０２７７−２４１１号）」と、
ここに引用により援用される、２００４年８月１２日にラクシミナラヤナン・チダムバラン他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「マルチノードシステムにおいて性能および可用性のレベルを実施するためのサービス配置（Service Placement for Enforcing Performance and Availability Levels in a Multi-Node System）（代理人整理番号第５０２７７−２４１２号）」と、
ここに引用により援用される、２００４年８月１２日にラクシミナラヤナン・チダムバラン他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「ノードおよびサーバインスタンスのオンデマンドな割当および割当解除（On Demand Node and Server Instance Allocation and De-Allocation）（代理人整理番号第５０２７７−２４１３号）」と、
ここに引用により援用される、２００４年８月１２日にラクシミナラヤナン・チダムバラン他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「マルチノードシステムにおける、回復可能な非同期メッセージ駆動型の処理（Recoverable Asynchronous Message
Driven Processing in a Multi-Node System）（代理人整理番号第５０２７７−２４１４号）」と、
ここに引用により援用される、２００４年８月１２日にキャロル・コルレイン（Carol Colrain）他により出願された米国出願第ＸＸ／ＸＸＸ，ＸＸＸ号、「サービスによる作業負荷の管理（Managing Workload by Service）（代理人整理番号第５０２７７−２３３７号）」とに関連する。

本願は、以下の国際出願、すなわち、
ここに引用により援用され、米国受理官庁（United States Receiving Office）においてオラクル・インターナショナル・コーポレイション（Oracle International Corporation）により２００４年８月９日に出願され、かつ、「データベースの自動的かつ動的な供給」と題された国際出願第ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ号と、
ここに引用により援用され、米国受理官庁においてオラクル・インターナショナル・コーポレイションにより２００４年８月１３日に出願された国際出願第ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ号、「サーバ全体にわたる透過的なセッション移動（代理人整理番号第５０２７７−２５９３号）」と、
ここに引用により援用され、米国受理官庁においてオラクル・インターナショナル・コーポレイションにより２００４年８月１３日に出願された国際出願第ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ号、「サーバ全体にわたるステートレスなセッションの透過的な移動（Transparent Migration of Stateless Sessions Across Servers）（代理人整理番号第５０２７７−２５９４号）」と、
ここに引用により援用され、米国受理官庁においてオラクル・インターナショナル・コーポレイションにより２００４年８月１３日に出願された国際出願第ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ号、「ノードおよびサーバインスタンスのオンデマンドな割当および割当解除（代理人整理番号第５０２７７−２５９５号）」とに関する。

発明の分野
この発明は、作業負荷の管理に関し、特に、マルチノードコンピュータシステム内における作業負荷の管理に関する。

発明の背景
企業は、データ処理システムのコストを削減し、効率を高める方法を探し求めている。一般的な企業のデータ処理システムは、企業のアプリケーションの各々に個別のリソースを割当てる。アプリケーションの、推定されるピーク負荷に対処するために、各アプリケーションには、十分な負荷が事前に割当てられる。各アプリケーションは、異なる負荷特性を有する。すなわち、アプリケーションによっては、日中に繁忙なものもあれば夜間に繁忙なものもあり、レポートによっては、週に一度稼動されるものもあれば月に一度稼動されるものもある。その結果、未使用の状態の多くのリソース容量が生じる。グリッド計算は、この未使用の容量の使用または解消を可能にする。実際に、グリッド計算は、計算の経済的側面を抜本的に変化させる態勢を整えている。

グリッドは、処理と、何らかの程度の共用記憶とを提供する計算素子の集合である。すなわち、グリッドのリソースは、そのクライアントの計算上の必要性および優先順位を満たすように動的に割当てられる。グリッド計算は、計算のコストを劇的に下げ、計算リソースの可用性を拡大し、より高い生産性と、より高い品質とを生じ得る。グリッド計算の基本的な理念は、電力グリッドまたは電話網に類似した、ユティリティとしての計算の概念である。グリッドのクライアントは、そのデータが存在する場所、または、計算が実行
される場所に関心を持たない。クライアントは単に、計算が行なわれることと、情報がクライアントの必要時にクライアントに配信されることとを望む。

これは、電気ユティリティが作動する態様に類似する。すなわち、顧客は、発電機が存在する場所、または、電気グリッドが配線される態様を知らない。顧客は単に、電気を所望して電気を得る。目標は、計算をユティリティにすること、すなわち、どこにでも存在する日用品にすることである。そのため、これはグリッド（Grid）という名前を有する。

ユティリティとしてのグリッド計算というこの観点は、当然ながら、クライアント側の観点である。グリッドは、サーバ側から、すなわち裏側から見ると、リソースの割当、情報の共有、および高可用性に関するものである。リソースの割当により、リソースを必要とするか、または要求するすべてのものが、必要なものを確実に獲得するようになる。リソースがアイドル状態に置かれない一方で、要求は、応対されない状態で置かれる。情報の共有により、クライアントおよびアプリケーションが必要とする情報は、この情報が必要とされる場所および時間に確実に利用可能となる。高可用性により、すべてのデータおよび計算は、ちょうどユティリティ企業が電力を常に提供するように、そこに常に必ず存在することが確実となる。

データベースに対するグリッド計算
グリッド計算から利益を得ることのできるコンピュータ技術の一領域が、データベース技術である。グリッドは、複数のデータベースをサポートし、リソースを必要時に動的に割当および再割当して、各データベースに対する現時点での需要をサポートすることができる。データベースに対する需要が増大するのに伴い、そのデータベースには、より多くのリソースが割当てられ、他のリソースは、別のデータベースから割当を解除される。たとえば企業のグリッドにおいて、データベースは、グリッド上の１つのサーバブレード上で稼動する１つのデータベースサーバにより提供されている。そのデータベースにデータを要求するユーザの数が増大する。この増大に応答して、別のデータベース用のデータベースサーバが或るサーバブレードから除去されて、そのサーバブレードに、増大したユーザ要求を受けているデータベース用のデータベースサーバが供給される。

データベース用のグリッド計算は、異なるレベルにおけるリソースの割当および管理を必要とする。１つのデータベースに対応するレベルにおいて、そのデータベースのユーザに提供される性能は、監視されなければならず、ユーザ間に割当てられるデータベースのリソースは、各ユーザについての性能目標が確実に満たされるように監視されなければならない。データベース間において、データベース間のグリッドのリソースの割当は、すべてのデータベースのユーザについての性能目標が確実に満たされるように管理されなければならない。これらの異なるレベルにおいてリソースの割当を管理し、このような管理を実行するのに必要とされる情報を管理する作業は、極めて複雑である。したがって、データベースシステムだけでなく、グリッド内において異なるレベルでリソースを割当てる他の種類のシステムのためのグリッド計算システムでは、リソースの管理を単純化し、かつ、リソースの管理に効率よく対処するメカニズムが必要とされる。

このセクションに記載する手法は追求可能な手法であるが、必ずしも、これまでに考案されたか、または追求された手法ではない。したがって、特に示さない限り、このセクションに記載する手法はいずれも、このセクションに含まれているが故に単に先行技術として限定されると考えられるべきではない。

この発明は、添付の図面において限定ではなく例示として示されており、これらの図面において、同様の参照番号は同様の要素を指す。

発明の詳細な説明
マルチノード環境においてリソースの割当を管理するための方法および装置を記載する。以下の記載では、説明のために、多数の特定の詳細を明示して、この発明の完全な理解を図る。しかしながら、これらの特定の詳細を用いなくてもこの発明を実施できることが明らかであろう。場合によっては、周知の構造および装置をブロック図の形で示し、この発明をむやみに分かりにくくすることを避ける場合もある。

ここでは、マルチノードデータベースシステムにより提供されるサービス間における、マルチノードデータベースシステムのリソースの動的な割当を、効率よく効果的に管理するために用いられる手法を記載する。サービスは、１つ以上のクライアントの便宜を図って実行される作業の特定の種類またはカテゴリである。サービスは、たとえば、ＣＰＵの処理時間、揮発性メモリへのデータの記憶およびそのデータへのアクセス、永続的な記憶装置（すなわちディスク記憶装置）からの読出およびその記憶装置への書込、ならびに、ネットワーク帯域幅またはバス帯域幅の使用を含む、コンピュータリソースのあらゆる使用または消費を含む。サービスは、たとえば、データベースサーバのクライアント上の特定のアプリケーションに対して実行される作業であり得る。

これらの手法は、異なるレベルにおいてリソースの割当を管理する。特定のデータベースを使用するサービスに関し、これらのサービスによって実現される性能は監視される。データベースに割振られたリソースは、サービス間で割当てられて、各々についての性能目標が確実に達成されるようにする。１クラスタのノードに割振られたリソースは、データベース間で割当てられて、それらのデータベースを使用するすべてのサービスについての性能目標が確実に達成されるようにする。

この手法は、異なるレベルにおいてリソースを管理するために、ディレクタの階層を用いる。ディレクタの一種であるデータベースディレクタは、データベースおよびそのデータベースインスタンスを使用するサービス間で、データベースに割当てられるリソースを管理する。データベースディレクタは、サービス間でのデータベースインスタンスの割当を管理する。クラスタディレクタは、そのデータベースサーバがクラスタ上でホストされるデータベース間において、１クラスタのノードのリソースを管理する。さらに別のディレクタであるファームディレクタは、クラスタ間で割当てられるリソースを管理する。

図１は、この発明の一実施例を実現するために使用され得るマルチノードコンピュータシステムを示す。図１を参照すると、図１は、クラスタファーム１０１を示す。クラスタファームは、クラスタと呼ばれるノードのグループに編成される１組のノードである。クラスタは、そのクラスタ内のノード間において、何らかの程度の共用記憶（１組のディスクドライブへの共用アクセス等）を提供する。

クラスタファーム内のノードは、ネットワークを介して相互接続されたコンピュータ（ワークステーション、パーソナルコンピュータ等）の形態を取り得る。代替的に、ノードは、グリッドのノードであり得る。グリッドは、ラック上で他のサーバブレードと相互接続されたサーバブレードの形態を取ったノードで構成される。各サーバブレードは、１つのマザーボード上にプロセッサ、メモリ、ネットワーク接続および関連する電子機器を備えた包括的なコンピュータシステムである。一般に、サーバブレードは、（揮発性メモリ以外に）オンボードの記憶装置を含まず、ラック内の電源、冷却システム、および配線に加え、記憶装置（共用ディスク等）を共有する。

クラスタファーム内のクラスタの決定的な特徴は、１つのクラスタから別のクラスタに
ノードを物理的に再接続する必要なしに、クラスタのノードがファーム内のクラスタ間でソフトウェア制御を介して自動的に転送され得ることである。クラスタは、ここではクラスタウェアと呼ばれるソフトウェアユティリティによって制御および管理される。クラスタウェアを実行して、クラスタからノードを除去すること、および、クラスタにノードを提供することが可能である。クラスタウェアは、人間の管理者からの要求を受取るコマンドラインインターフェイスを設けて、管理者が、クラスタにノードを提供し、クラスタからノードを除去するコマンドを入力し得るようにする。これらのインターフェイスは、アプリケーションプログラムインターフェイス（Application Program Interface（「ＡＰＩ」））の形態も取り得、ＡＰＩは、クラスタファーム内で実行されている他のソフトウェアによって呼出され得る。クラスタウェアは、ファーム内のクラスタの構成を規定するメタデータを使用および保存する。このメタデータは、どの特定のノードがクラスタ内に存在するかを含む、ファーム内のクラスタのトポロジーを規定するクラスタ構成のメタデータを含む。メタデータは、クラスタファーム内のクラスタに対してクラスタウェアが行った変更を反映するように変更される。クラスタウェアの一例が、Oracle（登録商標）により開発されたソフトウェア、たとえば、オラクル９ｉリアルアプリケーションクラスタ（Oracle9i Real Application Cluster）またはオラクルリアルアプリケーションクラスタ１０ｇ（Oracle Real Application Cluster 10g）である。オラクル９ｉリアルアプリケーションクラスタは、マイク・オールト（Mike Ault）およびマドフ・トゥーマ（Madhu
Tumma）による、オラクル９ｉＲＡＣ：オラクルリアルアプリケーションクラスタの構成および本質、第２版（２００３年８月２日）に記載されている。

クラスタファーム１０１は、クラスタ１１０、１２０、および１３０を含む。クラスタの各々は、データベースへのアクセスを提供および管理する１つ以上のマルチノードデータベースサーバをホストする。

クラスタおよびマルチノードデータベースサーバ
図２は、この発明の一実施例に従ったクラスタ１１０を示す。クラスタの決定的な特徴は、クラスタが、当該クラスタのクライアントによって単一のユニットまたはエンティティとして扱われる点である。なぜなら、より詳細に説明するように、クライアントが、どの特定の１つまたは複数のノードが要求を実行するのかを指定せずに、クラスタによってホストされるサービスの要求を発行するためである。

クラスタ１１０は、マルチノードデータベースサーバ２２２、２３２、および２４２を含む。マルチノードデータベースサーバ２２２、２３２、および２４２は、クラスタ１１０の１つ以上のノード上に存在する。マルチノードサーバ等のサーバは、統合されたソフトウェア構成要素と、プロセッサ上の統合されたソフトウェア構成要素を実行するためのメモリ、ノード、およびノード上のプロセス等の計算リソースの割当との組合せであり、ソフトウェアと計算リソースとの組合せは、専ら、１つ以上のクライアントのために特定の機能を実行する。マルチノードサーバは、データベース管理の他の機能の中でも、特定のデータベースへのアクセスを統制して容易にし、クライアントによる要求を処理してデータベースにアクセスする。マルチノードサーバ２２２、２３２、および２４２はそれぞれ、データベース２２０、２３０、および２４０へのアクセスを統制および提供する。サーバの別の例がウェブサーバである。

マルチノード計算システム内の複数のノードからのリソースは、サーバのソフトウェアを稼動するために割当てられ得る。ソフトウェアと、ノードからのリソースの割当との組合せの各々は、ここで「サーバインスタンス」または「インスタンス」と呼ばれるサーバである。したがって、マルチノードデータベースサーバは、複数のノード上で稼動し得る複数のサーバインスタンスを含む。マルチノードデータベースサーバのいくつかのインスタンスは、実際に同一ノード上で稼動し得る。マルチノードデータベースサーバは、複数
の「データベースインスタンス」を含み、各データベースインスタンスは、ノード上で稼動し、特定のデータベースへのアクセスを統制して容易にする。したがって、各インスタンスは、ここで、特定のデータベースのデータベースインスタンスと呼ぶことができる。クラスタは、マルチノードデータベースサーバをホストするためにしばしば使用される。

クラスタ１１０に加え、マルチノードデータベースサーバ２２２、２３２、および２４２のクライアントは、クライアント２０３および２０５を含む。クライアント２０３および２０５は、たとえばネットワークを介してクラスタ１１０に相互接続されたコンピュータ上のアプリケーションを実行する。アプリケーションは、この用語のここでの使用時には、サーバと対話し、かつ、サーバの機能を使用するように構成されるソフトウェアの単位である。一般に、アプリケーションは、統合された機能と、１組の関連する機能を実行するソフトウェアモジュール（機械実行可能なコードまたは解釈可能なコードで構成されるプログラム、動的にリンクされるライブラリ等）とで構成される。

クライアント２０３は、たとえば、ＦＩＮアプリケーションおよびＰＡＹアプリケーションを実行するコンピュータプロセスを含む。ＦＩＮアプリケーションは、企業の会計上および財務上の情報を生成および分析するソフトウェアを含む。ＰＡＹアプリケーションは、企業の従業員の給与に関する情報を生成および追跡する。

データベースサーバ２２２、２３２、および２４２のクライアントは、ネットワークを介してクラスタ１１０に相互接続されるコンピュータに限定されない。たとえば、データベースサーバ２２２は、データベースサーバ２３２のクライアントであり得る。

データベース、たとえばデータベース２２０、２３０、および２４０は、データベースオブジェクトの集合である。データベースオブジェクトは、構造化データのどのような形態をも含む。構造化データは、構造を規定するメタデータ記述に従って構造化されたデータである。構造化データは、リレーショナルテーブル、オブジェクトテーブル、オブジェクト−リレーショナルテーブル、拡張可能マークアップ言語（Extensible Markup Language「ＸＭＬ」）に従って構造化されたデータの本体、たとえばＸＭＬ文書を含む。

セッション
クライアントがクラスタ１１０上のデータベースサーバと対話するために、そのクライアントに対してセッションが確立される。セッション、たとえばデータベースセッションは、クライアントのために、データベースインスタンス等のサーバに対して確立された特定の接続であり、クライアントは、この接続を介して一連の要求（データベースステートメントの実行の要求）を発行する。データベースインスタンス上に確立された各データベースセッションに関し、データベースセッションの現状を反映するセッション状態データが保存される。このような情報には、たとえば、セッションが確立されたクライアントの身元、および、データベースセッション内でソフトウェアを実行するプロセスにより生成された一時的数値変数が含まれる。

クライアントは、データベース接続要求をクラスタ１１０に送信することにより、データベースセッションを確立する。

クラスタ１１０のクライアント、たとえばクライアント２０３および２０５は、クライアントと同じコンピュータ上に存在するクライアント側のインターフェイス構成要素を介して、クラスタ１１０と対話することができる。クライアント側のインターフェイス構成要素は、クライアント２０３および２０５により実行されるアプリケーションによって呼出されるＡＰＩ機能を含む。データベースサーバへの接続が割振られると、ノードを識別する接続情報が、クライアント側のインターフェイス構成要素によって受取られて使用さ
れ、クライアントによる以降の要求をノードに送信する。

クライアントに割振られたデータベースセッションは、別のデータベースインスタンスに移動され得る。データベースセッションの移動は、別のノード上に新規のデータベースセッションを作成することを必然的に伴う。移動および接続に関する情報がクライアント側のインターフェイス構成要素に送信されている間、アプリケーションはこの情報にアクセスすることができず、アプリケーションはこの移動に「気付かない」。このようにして、移動は、アプリケーションにとって透過的に実行される。以前のデータベースセッションに関連する要求は、新規のデータベースセッション内で実行される。このようにしてデータベースセッションを移動するための技術は、「サーバ全体にわたる透過的なセッション移動（５０２７７−２３８３）」に記載されている。

サービス
以前に述べたように、サービスは、１つ以上のクライアントの便宜を図って実行される特定の種類またはカテゴリの作業である。クラスタ１１０は、クライアント２０３および２０５に対し、データベース２２０にアクセスするためのデータベースサービスと、データベース２３０にアクセスするためのデータベースサービスと、データベース２４０にアクセスするためのデータベースサービスとを提供する。一般に、データベースサービスは、クライアントのために、データベースサーバによって実行される作業であり、この作業は一般に、データベースへのアクセスを要求するクエリーの処理および／または計算を行なう作業を含む。ここで使用されるクエリーという用語は、データベース言語、たとえばＳＱＬに適合するデータベースステートメントを指しており、データを追加、削除、または変更するための演算を指定し、あるいは、テーブル、オブジェクトビュー、および実行可能なルーチン等のデータベースオブジェクトを作成および変更するデータベースステートメントを含む。

データベースサービスは、どのようなサービスとも同様に、さらにサブカテゴリに分割または類別することができる。データベース２２０に対するデータベースサービスは、さらに分割されてＦＩＮサービスおよびＰＡＹサービスとなる。ＦＩＮサービスは、ＦＩＮアプリケーションのためにデータベースサーバ２２２によって実行されるデータベースサービスである。一般に、このサービスは、ＦＩＮアプリケーションについてのデータベースデータを記憶するデータベース２２０上のデータベースオブジェクトにアクセスすることを伴う。ＰＡＹサービスは、ＰＡＹアプリケーションのためにデータベースサーバ２２２によって実行されるデータベースサービスである。一般に、このサービスは、ＰＡＹアプリケーションについてのデータベースデータを記憶するデータベース２２０上のデータベースオブジェクトにアクセスすることを伴う。

クラスタによる作業がサービスのカテゴリおよびサブカテゴリに分割または類別され得るさまざまな態様が存在し、この発明は、どのような特定の態様にも限定されない。たとえば、作業は、その作業が実行されるユーザまたはユーザのグループ（企業、企業内の部門）に基づいてサービスに分割され得る。

サービスを提供する参加者
図３は、データベース２２０に対するさまざまなサービスを提供することに携わるクラスタ１１０およびマルチノードデータベースサーバ２２２の構成要素を示す。図３を参照すると、マルチノードデータベースサーバ２２２は、データベースインスタンス３２２、３３２、３４２、３５２、および３６２を含み、これらのデータベースインスタンスは、それぞれノード３２０、３３０、３４０、３５０、および３６０上に存在して、データベース２２０へのアクセスを管理する。データベースインスタンスは、インスタンス管理アプリケーションを用いて特定のノードに供給されるか、または特定のノードから除去され
得る。インスタンス管理アプリケーションは、たとえば、オラクル９ｉリアルアプリケーションクラスタまたはオラクルリアルアプリケーションクラスタ１０ｇの一部として利用可能である。インスタンス管理アプリケーションは、ノードにデータベースインスタンスを供給するか、またはノードからデータインスタンスを除去するために、管理者またはクライアントによって呼出され得るコマンドラインインターフェイスまたはＡＰＩを提供する。

マルチノードデータベースサーバ２２２のデータベースインスタンスは、特定のサービスに割当てられる。データベースインスタンス３２２および３３２は、サービスＦＩＮに割当てられる。データベースインスタンス３４２および３５２は、サービスＰＡＹに割当てられる。インスタンス３６２は、どのようなサービスにも割当てられない。サービスは、このサービスを実行するためにインスタンス、ノード、もしくはクラスタが割当てられたときに、インスタンス、ノード、もしくはクラスタを稼動するか、インスタンス、ノード、もしくはクラスタ上に存在するか、または、インスタンス、ノード、もしくはクラスタによりホストされると称される。したがって、ＦＩＮサービスは、データベースインスタンス３２２、３３２、およびノード３２０、３３０を稼動するか、またはこれらの上に存在すると称される。

リスナー３９０は、クラスタ１１０上で稼動し、クライアントのデータベース接続要求を受取り、クラスタ１１０内のデータベースインスタンスにそれらの要求を方向付けるプロセスである。受取られたクライアントの接続要求は、サービス（サービスＦＩＮ、ＰＡＹ等）に関連する。クライアントの要求は、当該サービスをホストするデータベースインスタンスに方向付けられ、そこで、データベースセッションがクライアントに対して確立される。以前に述べたように、セッションは、別のデータベースインスタンスに移動され得る。リスナー３９０は、アプリケーションに対して透過的な態様で、特定のデータベースインスタンスおよび／またはノードに要求を方向付ける。リスナー３９０は、クラスタ１１０上のどのようなノード上でも稼動し得る。クライアントに対してデータベースセッションが一旦確立されると、クライアントはさらに別の要求を発行することができ、この要求は、関数か、または遠隔プロシージャの呼出の形態を取り得、トランザクションの実行開始、クエリーの実行、更新および他の種類のトランザクション動作の実行、トランザクションのコミットまたは終了、およびデータベースセッションの終了の要求を含む。

作業負荷の監視
リソースは、性能のレベルと、リソースに関するカーディナリティの制約とを満たすように割当および再割当が行なわれる。特定のサービスに対して確立された性能のレベルおよびリソースの可用性は、ここで、サービスレベルに関する合意と呼ばれる。一般にマルチノードシステムに該当し、必ずしも特定のサービスに該当しない、性能のレベルおよびリソースについてのカーディナリティの制約は、ここで、ポリシーと呼ばれる。たとえば、サービスＦＩＮについてのサービスレベルに関する合意は、性能のレベルとして、サービスＦＩＮに対する平均トランザクション時間が所定のしきい値を上回らないことを要求し、かつ、可用性の要件として、少なくとも２つのインスタンスがサービスＦＩＮをホストすることを要求することが考えられる。ポリシーは、どのようなノードのＣＰＵ利用率も８０％を上回らないことを要求することが考えられる。

ポリシーは、ここで、バックエンドポリシーとも呼ばれ得る。なぜなら、これらのポリシーが、バックエンド管理者によって使用されてシステム全体の性能を管理しており、１組のサービスすべてのサービスレベルに関する合意を満たすにはリソースが不十分であると考えられる場合に、その１組のサービス間でリソースを割当てるためである。たとえば、ポリシーは、或るデータベースに対し、別のデータベースよりも高位の優先順位を割当てる。両方のデータベースのサービスの、サービスレベルに関する合意を満たすには十分
なリソースが存在していないときに、より高位の優先順位を有するデータベース、およびそのデータベースを使用するサービスは、リソースの割当時に優遇される。

サービスレベルに関する合意を満たすために、さまざまなリソース上に配置された作業負荷を監視および測定するメカニズムが必要とされる。作業負荷のこれらの測定値を用いて、サービスレベルに関する合意が満たされているかどうかを判断し、必要な場合、このサービスレベルに関する合意を満たすようにリソースの割当を調節する。

作業負荷モニタ、たとえば作業負荷モニタ３８８は、クラスタのノード上で稼動してクラスタの作業負荷を監視および測定して「性能メトリクス」を生成する、分散された１組のプロセスである。作業負荷モニタ３８８は、クラスタ１１０上で稼動する。性能メトリクスは、性能の測定値に基づき、１つ以上のリソースまたはサービスに関する性能のレベルを示すデータである。これらの機能を実行するための手法は、「サービスによる作業負荷の測定（５０２７７−２３３７）」に記載されている。以下により詳細に説明するように、サービスレベルに関する合意を満たすようにリソースの割当を管理する責任を負う、マルチノードデータベースサーバ２２２内のさまざまな構成要素は、生成されたこの情報にアクセスすることができる。

性能のレベルまたは作業負荷を示す特徴または状態を測定するために使用され得る特定の種類の性能メトリクスは、ここで、性能測定値と呼ばれる。性能測定値には、たとえば、トランザクションの実行時間またはＣＰＵの利用率が含まれる。一般に、性能のレベルを必要とする、サービスレベルに関する合意は、性能測定値に基づくしきい値および基準により規定され得る。

たとえば、トランザクションの実行時間は、性能測定値である。この測定値に基づいた、サービスレベルに関する合意は、サービスＦＩＮに対するトランザクションが、３００ミリ秒以内で実行されるべきであるというものである。さらに別の性能測定値が、ノードのＣＰＵ利用率である。この測定値に基づいたバックエンドポリシーは、ノードが、８０％を上回る利用率を生じないようにするというものである。

性能メトリクスは、クラスタの性能、および、クラスタ上で稼動するサービスか、クラスタ内のノードか、または特定のデータベースインスタンスの性能を示し得る。サービスに特有の性能メトリクスまたは測定値は、ここで、サービスの性能メトリクスまたは測定値と呼ばれる。たとえば、サービスＦＩＮに対するサービス性能測定値は、サービスＦＩＮに対して実行されるトランザクションについてのトランザクション時間である。

階層的なリソースの割当
グリッド計算は、サービスレベルに関する合意を満たすようにコンピュータリソースを動的に割当てることを必要とする。一実施例において、コンピュータリソースは、１つ以上のレベルのリソースの割当の階層において平均化または調節される。階層の各レベルは、使途（サービス等）間で割当てられる、一組の異なるリソースプールを有する。リソースプールは、特定の種類のリソースのグループであり、たとえば、サービスにとって利用可能なノードおよびデータベースインスタンスか、データベースにとって利用可能なノードか、または、クラスタにとって利用可能なノードである。リソースの割当における３つのレベルが、データベースレベル、クラスタレベル、およびファームレベルである。

データベースレベル
データベースレベルにおいて、割当てられるリソースプールは、特定のデータベース用に現時点で使用されているものであり、データベースのデータベースインスタンスと、これらのデータベースインスタンスをホストするノードとを含む。データベースレベルのリ
ソースプール（すなわち、そのデータベースレベルにおいて割当てられ得るリソース）は、サービスレベルに関する合意を満たすようにデータベースのサービス間で割当てられる。一般に、このことは、インスタンス上にサービスを配置すること、およびインスタンス上にセッションを配置することを必要とする。

セッションは、いくつかの態様で配置され得る。第１の態様は、ここで、接続時間の平均化と呼ばれる。リスナー３９０は、接続時間の平均化の際に、特定のサービスを要求するデータベース接続要求をデータベース２２０のインスタンスに方向付けることにより、サービスインスタンス間の作業負荷を平均化する。たとえば、データベースインスタンス３２２上のサービスＦＩＮが、他のインスタンスよりも良好なサービス性能を提供していると想定されたい。リスナー３９０は、これに応じて、ＦＩＮサービスを要求するデータベース接続要求のより大きな部分を、データベースインスタンス３２２に方向付ける。

セッションを配置する第２の態様は、実行時セッションの平均化と呼ばれる。データベースセッションは、実行時セッションの平均化の際に、或るデータベースインスから別のデータベースインスタンスに移動される。データベースセッションは、透過的なセッション移動を用いて移動される。以前に述べたように、このことを実行するための技術は、「サーバ全体にわたる透過的なセッション移動」に記載されている。

サービスの配置は、サービスの拡張および縮小を必然的に伴う。データベースインスタンスは、サービスの拡張および縮小時に、ホストするサービスに割当てられるか、または、ホストするサービスから割当を解除される。サービスをホストするようにデータベースインスタンスが割当てられるときに、そのインスタンス上のそのサービスに対してより多くのデータベースセッションが作成され得、そのため、そのサービスに関連し、かつ、そのサービス用に利用することのできるデータベースセッションの数が増大する。たとえば、サービスＦＩＮについてのサービスレベルに関する合意を満たすために、インスタンス３２２および３３２は、サービスＦＩＮを稼動するように割当てられる。サービスに対する需要が増大するのに伴い、サービスレベルに関する合意が満たされなくなる。サービスレベルに関する合意が満たされないときに、サービスレベルに関する合意は、違反されたと称される。このサービスレベルの違反に応答して、ＦＩＮサービスには、さらに別のインスタンス、すなわちインスタンス３４２が割当てられる。１つのインスタンスは、２つ以上のサービスを稼動し得る。例示のため、１つのインスタンスは１つのサービスしか稼動していない。したがって、ＦＩＮがインスタンス３４２に追加されると、サービスＰＡＹはインスタンス３４２から「休止状態にされ」、すなわち、インスタンス３４２は、ＰＡＹサービスのために使用されるリソースとして割当を解除され、インスタンス上のサービスは中止される。

クラスタレベル
クラスタレベルにおいて、クラスタに現時点で割当てられているリソースは、サービスレベルに関する合意を満たすように、データベース（すなわちデータベースサービス）間で平均化される。このレベルで平均化されるリソースプールは、データベースインスタンスと、これらのデータベースインスタンスをホストするノードとである。一般に、このレベルでリソースを平均化することは、クラスタ内の既存のノード間でインスタンスを供給することおよび休止状態にすることを必要とする。たとえば、サービスレベルの違反に応答してサービスレベルに関する合意を満たすために、インスタンス３６２が、ノード３６０、すなわち、マルチノードデータベースサーバ２２２用のクラスタ内に既に存在するノードに供給される。

ファームレベル
このレベルにおいて、サービス間で割当てられ得るリソースは、クラスタ内のノードで
ある。クラスタ用のノードのプールは動的である。たとえば、サービスレベルの違反に応答して、ノード３７０が、マルチノードデータベースサーバ２２２のクラスタに追加される。

リソースの割当を調節するためのアクションの階層
一般に、リソースの割当の階層のより低位のレベルにおけるリソースの調節は、より高位のレベルにおけるリソースの調節ほど混乱を招かない。データベースレベルにおいて、稼動中のインスタンス間でデータベースセッションおよびサービスを移動することは、クラスタレベルにおいて、新規のデータベースインスタンスを供給するか、または休止状態にすることほど混乱を招かず、費用もかからない。リソースが既に割振られたエンティティ間で、割振られたリソースを入換えることは、より高位のレベルからより多くのリソースを割振る要求ほど費用がかからない。データベースレベルにおけるサービスの配置およびセッションの移動は、クラスタレベルにおける、データベース用のデータベースインスタンスの数の変更ほど費用がかからない。データベースレベル内において、セッションを移動して、サービスを既にホストしているインスタンス間でそれらのセッションを入換えることは、サービスの拡張および縮小ほど費用がかからない。なぜなら、後者がサービスのトポロジーに影響を与え、負荷の分配に対して全体的により大きな影響を及ぼし得るためである。

サービスレベルの違反を是正するために、リソースの割当は、リソースの割当の階層の最下位のレベルから調節される。このようにすることで、サービスレベルの違反は、それほど混乱を招かず、かつ、それほど費用のかからない態様で一般に是正される。データベースレベルにおいてリソースの割当を調節することによってサービスレベルの違反が解消され得る場合、より高位のレベルのリソースの割当には頼らない。サービスレベルの違反によっては、全レベルまたはいくつかのレベルにおける調節を必要とするものがある。

休止状態のサービスＰＡＹが、ＰＡＹについてのサービスレベルに関する合意を違反していない場合に限り、サービスレベルの違反に応答して、ＦＩＮがインスタンス３５２に供給され、ＰＡＹは、同じインスタンスから休止状態にされる。それ以外の場合、サービスＦＩＮは別のデータベースインスタンスに拡張される。しかしながら、サービスＦＩＮを供給するために利用可能なインスタンスが存在しない場合、新規のインスタンスが供給される。このことは、クラスタレベルにおいて割当を行なうこと、すなわち、新規のインスタンス３６２をノード３６０に、すなわち、クラスタ内に既に存在するノードに供給することにより行なわれる。次に、データベースレベルにおいてサービスＦＩＮをインスタンス３６２に拡張することにより、割当が行なわれ得る。インスタンス３６２は、サービスが供給された時点において、データベース２２０に既に割当てられていたインスタンスである。

ディレクタの階層
一実施例に従うと、分散型ディレクタと呼ばれる分散型システムの構成要素は、各レベルにおけるリソースの作業負荷およびリソースの割当を管理する責任を負う。システム構成要素は、ここでその用語が使用されているように、ソフトウェアと、データと、そのソフトウェアを実行し、かつ、そのデータを使用および保存して特定の機能を実行する１つ以上のプロセスとの組合せである。分散型システムの構成要素は、複数のノード上で実行される。必ずしもそうでなくてよいが、好ましくは、ディレクタは、データベースインスタンスのシステム構成要素であり、データベースインスタンスの制御下で作動する。分散型ディレクタは、クラスタファーム１０１の複数のノード上で実行されるディレクタを含む。

一実施例に従うと、ディレクタは、リソースの割当の階層の１つ以上のレベルにおける
リソースの割当を管理する責任を負う。具体的に、ディレクタは、各データベースに対し、データベースレベルにおけるリソースの割当を管理するデータベースディレクタとして機能する。データベースの他のデータベースインスタンスは、待機中のデータベースディレクタとして機能するディレクタを有することが考えられ、待機中のデータベースディレクタは、現時点で「活動中の」データベースディレクタが、たとえばシステム故障によりこの役割を果たすことができなくなった場合に、この活動中のデータベースディレクタを引き継ぐ準備を整えている。

ディレクタは、各クラスタに対し、クラスタディレクタとして機能する。クラスタディレクタは、クラスタに対し、クラスタレベルにおけるリソースの割当を管理する責任を負う。クラスタ内の他のディレクタは、待機中のクラスタディレクタとして機能する。

最後に、ディレクタはファームディレクタとして機能する。ファームディレクタは、ファームレベルにおけるリソースの割当を管理する責任を負う。クラスタ内の他のディレクタは、待機中のファームディレクタとして機能する。

ディレクタは、ディレクタの対応するレベルにおいて作業負荷を管理するのに必要とされる情報を受取り、保存し、生成する。

図３を参照すると、ディレクタ３８０は、データベースインスタンス３４２上で稼動する。ディレクタ３８０は、データベース２２０に対するデータベースディレクタ、クラスタ１１０に対するクラスタディレクタ、およびクラスタファーム１０１に対するファームディレクタとして機能する。他のディレクタはそれぞれ、データベース２３０および２４０に対するデータベースディレクタとして、ならびに、それぞれクラスタ１２０および１３０に対するクラスタディレクタとして機能する。

一般に、サービスレベルの違反を解消するために、リソースの割当の階層の全レベルにおけるディレクタが、この違反の是正に携わることが考えられる。データベースディレクタは、データベースレベルにおけるリソースの割当を調節することによってサービスレベルの違反の是正を試みる。サービスレベルの違反が、リソースの割当の階層の次に高位のレベル、すなわちクラスタレベルにおける調節を必要とする場合、データベースディレクタは、このサービスレベルの違反の解消を、クラスタディレクタに上げる。サービスレベルの違反がリソースの割当の階層の最高位のレベル、すなわちファームレベルにおける調節を必要とする場合、クラスタディレクタは、このサービスレベルの違反の解消を、ファームディレクタに上げる。サービスレベルの違反の是正は、全ディレクタによるリソースの割当の調節を必要とすることが考えられる。

ディレクタは、メッセージ待ち行列を用いて互いに通信する。一実施例に従うと、メッセージ待ち行列は、ディレクタをホストするデータベースインスタンスのデータベース内に記憶されるテーブルである。テーブルのレコードまたは行は、メッセージ待ち行列に対応する。このレコードは、その種のメッセージに応答する責任を負うディレクタによってメッセージに応答して行なわれた、どのようなアクションの状態をも示す。たとえば、データベースディレクタは、クラスタディレクタにデータベースインスタンスを要求し得る。この要求は、待ち行列に追加される。クラスタディレクタは、このメッセージ待ち行列を走査し、要求を検出し、この要求に従って機能し、その要求に応答するために着手されたアクションを反映するために、そのレコードを更新する。クラスタディレクタは、データベースディレクタにメッセージを送信し、このメッセージは、データベースディレクタのメッセージ待ち行列内に配置される。

データベース２２０内のテーブルを使用する利点は、マルチノードデータベースサーバ
２２２等のトランザクション指向のデータベースシステムの電力および機能を利用して、メッセージ待ち行列を永続的にかつ回復可能に記憶することができる点である。活動中のデータベースディレクタ、クラスタディレクタ、またはファームディレクタが故障すると、その地位に介入する待機中のディレクタは、ディレクタが故障時にメッセージを残した態様と整合性を有する状態で、メッセージ待ち行列にアクセスすることができる。このようなメッセージ待ち行列およびその使用は、「マルチノードシステムにおける、回復可能な非同期メッセージ駆動型の処理（５０２７７−２４１４）」に記載されている。

データベースディレクタ
データベースディレクタは、サービスレベルに関する合意が確実に満たされるようにサービスのサービス性能を監視し、データベース２２０のデータベースインスタンスからサービスを拡張または縮小し、データベース２２０のデータベースインスタンス間においてデータベースセッションを移動する責任を負う。データベースディレクタはまた、データベースを用いる各サービスについてのサービスの性能メトリクスおよびサービスレベルに関する合意へのアクセスを有し、それらを記憶する。データベースディレクタは、これらのサービスの性能メトリクスおよびサービスレベルに関する合意に基づき、サービスレベルに関する合意が以下の２つの態様で満たされるようにする。すなわち、（１）リスナーに対し、当該リスナーによるサービスインスタンス間での作業負荷の平均化を可能にする情報を生成および送信することにより、サービスレベルに関する合意にサービス性能が準拠することを維持し、（２）サービスレベルの違反を是正するために、サービスレベルの違反を検出してリソースの割当に対する調節を開始することによってサービスレベルの違反を是正する態様で、サービスレベルに関する合意が満たされるようにする。

サービスレベルに関する合意にサービス性能が準拠することを維持するために、接続時間の平均化が用いられる。具体的には、ディレクタ３８０が、ここでは性能グレードと呼ばれる情報をリスナー３９０に生成および提供する。性能グレードは、作業負荷を平均化するときにリスナー３９０を案内して、サービス性能の準拠を維持する。性能グレードは、他のインスタンスを基準とした、或るインスタンス上のサービスの相対的なサービス性能を示す。リスナー３９０は、この性能グレードに基づき、より良好なサービス性能を提供するデータベースインスタンスに対し、サービスに対する接続ユーザ要求の分配を変更する。性能グレードを生成するための技術および性能グレードに基づいてこのような態様でユーザ要求を分配するための技術は、「サービスをホストするマルチノード環境における、サービスの性能グレードの計算（５０２７７−２４１０）」に記載されている。

サービスレベルの違反を是正することは、サービスレベルの違反を検出することを必要とする。ディレクタ３８０は、サービスの性能メトリクスとサービスレベルに関する合意とを比較することにより、サービスについてのサービスレベルの違反を検出する。たとえば、ディレクタ３８０は、作業負荷モニタ３８８から、サービスＦＩＮについての平均トランザクション時間が３０ミリ秒を上回ることを示す、サービスの性能メトリクスを受取る。サービスＦＩＮについてのサービスレベルに関する合意は、平均トランザクション時間が２０ミリ秒を上回らないことを要求する。ディレクタ３８０は、実際の平均トランザクション時間とサービスレベルに関する合意とを比較することにより、サービスレベルの違反を検出する。

データベースディレクタがサービスについてのサービスレベルの違反を検出すると、データベースディレクタは、リソースの割当の階層に従い、より混乱を招きかつ費用のかかるリソースの割当の調整を試みる前に、最も混乱を招かず最も費用のかからないリソースの割当の調節を試みる。このため、データベースディレクタはまず、サービスに割当てられたデータベースセッションを、サービス性能がより良好な別のデータベースインスタンスに移動することによって、そのサービスを既にホストしているインスタンス間で作業負
荷を平均化することにより、サービスレベルの違反が是正できるかどうかを判断する。移動されるデータベースセッションの数は、サービスインスタンス間で平均化された負荷を得ることを目標とする態様で選択される。

データベースディレクタが、既存のサービスインスタンス間で負荷の均衡を取戻すことによりサービスレベルの違反が解消されないと判断した場合、ディレクタ３８０は、サービスを拡張することにより、すなわち、ここではターゲットデータベースインスタンスと呼ばれる既存の別のデータベースインスタンスを、サービスにホストするように割当てることにより、サービスレベルの違反の是正を試みる。ターゲットデータベースインスタンスがサービスをホストしていない場合、サービスは、サービスにホストするようにターゲットデータベースインスタンスを割当てることによって拡張される。ターゲットデータベースインスタンスが別のサービスをホストしている場合、データベースディレクタは、それを行なうことによって他のサービスについてのサービスレベルの違反を生じないと判断した場合に、そのサービスを休止状態にすることができる。

図４は、さらに別のデータベースインスタンス（「ターゲットデータベースインスタンス」）にサービスを拡張するために、当該ターゲットデータベースインスタンス上のサービスが最初に休止状態にされなければならないときに、データベース２２０に対するデータベースディレクタとしてのディレクタ３８０が辿るプロセスのフロー図を示す。例示のために、サービスＰＡＹはデータベースインスタンス３４２、３５２、および３６２によってホストされ、データベースインスタンス３６２は、ノード３６０上に存在する。サービスＦＩＮは、データベースインスタンス３４２に拡張されている。インスタンス３４２上で稼動するサービスＰＡＹのサービスインスタンスは、休止状態にされている。

図４を参照すると、ステップ４１０において、ディレクタ３８０は、リスナー３９０にブロッキングメッセージを送信する。このブロッキングメッセージは、リスナー３９０に対し、サービスＰＡＹに対するユーザ要求を、ターゲットデータベースインスタンス３４２に分配することを中止するように指示する。

ステップ４２０において、データベースディレクタ３８０は、ターゲットデータベースインスタンス上のデータベースセッションを、サービスＦＩＮをホストする他のデータベースインスタンスに移動する。これらのデータベースセッションは、他のデータベースインスタンス間で作業負荷を平均化する態様で、他のデータベースインスタンス間で分配される。

ステップ４３０において、ディレクタ３８０は、リスナー３９０にサービス起動メッセージを送信する。サービス起動メッセージは、リスナー３９０に対し、サービスＦＩＮがインスタンス３６２上で稼動していることを通知する。

ステップ４４０において、ディレクタ３８０は、実行時の平均化を用いて、サービスＦＩＮが稼動しているインスタンス（すなわち、インスタンス３２２、３３２、および３４２）間で作業負荷を平均化する。

場合によっては、ターゲットインスタンスについてのサービスレベルに関する合意に違反せずに、縮小して別のサービスを拡張するための場所を提供し得るサービスが存在しないとディレクタ３８０が判断することがある。この場合、ディレクタ３８０は、どのようなサービスもまだホストしていないデータベースインスタンスに、このサービスを拡張することを選択することができる。どのデータベースインスタンスも利用できない場合、ディレクタ３８０は、クラスタディレクタに１つのデータベースインスタンスを要求する。クラスタディレクタは、それに応答して、要求された別のデータベースインスタンスを供
給し、ディレクタ３８０に通知する。ディレクタ３８０は、この新規のデータベースインスタンスにサービスを拡張する。

サービスレベルに関する合意は、サービスのカーディナリティを制限し得る。たとえば、サービスＦＩＮについてのサービスレベルに関する合意は、少なくとも１つであるが３つを超えないデータベースインスタンスがサービスＦＩＮをホストすること、および、サービスＰＡＹが少なくとも３つのデータベースインスタンスによってホストされることを要求する。

サービスは、別のサービスを拡張するためにデータベースインスタンスを利用可能にすること以外の理由で、休止状態にされ得る。たとえば、サービスＦＩＮについてのカーディナリティの制約は、１日の時間に基づいて変化し得る。通常の営業時間中では、サービスＦＩＮのカーディナリティが、３の大きさであることが考えられるが、非営業時間中において、カーディナリティは１よりも大きくならないことが考えられる。非営業時間の開始時には、３個のデータベースインスタンスがサービスＦＩＮをホストしている。データベースディレクタ３８０は、データベースインスタンスのうちの２つのインスタンス上のサービスを休止状態にすることにより、サービスＦＩＮを縮小する。

データベースディレクタは、クラスタディレクタにより行なわれた要求に応答しなければならないことが考えられる。このようなアクションは、クラスタディレクタによる要求に応答して、データベースインスタンスを休止状態にすること、すなわち、データベースインスタンスにより現時点でホストされているサービスを休止状態にすることを含む。このステップは、クラスタディレクタが、或るデータベース用のデータベースインスタンスを、別のデータベース用のデータベースインスタンスで置き換えたいと望むときに必要とされる。

クラスタディレクタ
クラスタディレクタは、クラスタ内の既存のノードにデータベースインスタンスを供給し、これらの既存のノードからデータベースインスタンスを除去する責任を負う。クラスタディレクタはまた、データベースレベルのポリシーを実施する。データベースレベルのポリシーは、たとえば、データベース用のデータベースインスタンスのカーディナリティが、最小値および／または最大値以内に入ることを要求し、または、サービスレベルに関する合意のすべてを満たすのに十分なリソースが存在しないときに、クラスタディレクタが、リソースの割当に関してより高位の優先順位を有すると指定されたデータベースに、データベースインスタンスの割当を変更することを要求する。データベース間における、このような態様での変更はまた、より高位の優先順位が付けられたデータベースを用いるサービスに、リソースの割当を変更する。クラスタディレクタは、データベース間のリソースの割当についての優先順位を指定するデータへのアクセスを有し、そのデータを記憶する。このようなデータは、クラスタの管理者により構成され得る。

クラスタディレクタは、データベースインスタンスに対するデータベースディレクタの要求（「NEED-INSTANCE」要求）に応答してデータベースインスタンスを供給し、データベースインスタンスを除去する。データベースインスタンスをホストしていないノード（「自由ノード」）がクラスタ内に存在する場合、クラスタディレクタは、その自由ノードにデータベースインスタンスを供給することにより、データベースに別のノードを割当てる。

クラスタ内に自由ノードが存在しない場合、クラスタディレクタは、ファームディレクタに「NEED-NODE」要求を発行することにより、ファームディレクタに１つのノードを要求することができる。ファームディレクタが１つのノードを提供し得ない場合、クラスタ
ディレクタは、クラスタによってホストされるデータベース間でデータベースインスタンスの割当を調停する。この調停は、クラスタ内のノードからデータベースのデータベースインスタンスを除去し、NEED-INSTANCE要求が生成されたデータベース用のデータベースインスタンスを供給することを必然的に伴う。

図５は、データベース間でのデータベースインスタンスの割当を調停するためのプロセスを示すフロー図である。データベース２２０に対するデータベースディレクタは、別のデータベースインスタンスがサービスに必要とされていることを判断し、ディレクタ３８０であるクラスタディレクタに、NEED-INSTANCE要求を生成する。ディレクタ３８０は、クラスタディレクタとしてのその機能において、別のデータベース用のデータベースインスタンスがクラスタ１１０内のノードから除去されることにより、そのノードを用いて、データベース２２０用の別のデータベースインスタンスを供給することができると判断する。

図５を参照すると、ステップ５１０において、クラスタディレクタとしてのディレクタ３８０は、要求を行なうデータベースディレクタ（すなわち、NEED-INSTANCE要求を発行するディレクタ）以外のデータベースディレクタに、「VOLUNTEER-TO-QUIESCE」要求を送信する。VOLUNTEER-TO-QUIESCE要求の目的は、データベースディレクタに対し、データベースディレクタが、データベースインスタンスを休止状態にし得るかどうか、すなわち、ディレクタのデータベース用のデータベースインスタンスのカーディナリティを下げることができるかどうかを尋ねるものである。データベースのデータベースディレクタは、申し出ること、すなわち、データベース用のデータベースインスタンスが休止状態にされ得ることを示すメッセージを送信することにより、応答し得る。データベースディレクタは、データベースインスタンスを休止状態にすること、すなわち、データベースインスタンスのカーディナリティを下げることを断り得る。データベースディレクタが、その要求を断るメッセージを送信し得る１つの理由は、サービスについての可用性の要件を満たすために、ディレクタのデータベースインスタンスのすべてが必要とされるためである。

データベースディレクタ３８０が、データベースディレクタから、データベースインスタンスが休止状態にされ得ることを断言する少なくとも１つのメッセージを受取った場合、すなわち、２つ以上のデータベースディレクタが申し出た場合、ステップ５２０において、ディレクタ３８０は、申し出たデータベースの中からデータベースを選択する。リソースの割当の、より高位の優先順位を有するデータベースを優遇するために、リソースの割当の、より低位の優先順位を有するデータベースが選択され得る。例示のために、ディレクタ３８０は、データベース２４０を選択する。クラスタディレクタ３８４は、データベース２４０のデータベースディレクタにメッセージを送信し、データベース２４０のデータベースインスタンスをホストするノードから、このデータベースインスタンスを休止状態にする。

データベースディレクタ３８０が、データベースインスタンスが休止状態にされ得ないことを断言するメッセージをデータベースディレクタから受取らない場合、すなわち、どのデータベースディレクタも申し出ない場合、ステップ５３０において、ディレクタ３８０は、リソースの割当のより低位の優先順位を有するデータベースを選択する。ディレクタ３８０は次に、選択したデータベースのデータベースディレクタにメッセージを送信し、データベースインスタンスを休止状態にする。データベースインスタンスを選択して休止状態にするための技術は、「ノードおよびサーバのオンデマンドな割当および割当解除（５０２７７−２４１３）」において、より詳細に記載されている。

ステップ５４０において、データベース２４０のデータベースディレクタは、ノード上のデータベースインスタンスを休止状態にして、クラスタディレクタ、すなわちディレク
タ３８０に対し、データベースインスタンスが休止状態にされたという通知（「INSTANCE-IDLE」通知）を送信する。ステップ５５０において、ディレクタ３８０は通知を受取る。

ステップ５６０において、クラスタディレクタ３８０は、そのノードからデータベースインスタンスを除去し、たとえば、クラスタウェアのＡＰＩを供給するインスタンスを用いて、そのノードに対し、データベース２３０用のデータベースインスタンスを供給する。

データベース間においてデータベースインスタンスの割当を調停した結果、ノードを放棄したデータベースによって提供されるサービスが、サービスレベルの違反を被るおそれがある。より詳細に説明するように、クラスタ内のノードのカーディナリティが増大し得ることから自由ノードが利用可能となり得、これらの自由ノードを用いて、このようなサービスレベルの違反を是正することができる。クラスタディレクタとしてのディレクタ３８０は、クラスタ構成のメタデータを監視して、より多くの自由ノードが利用可能になる時点を検出し、それらの自由ノードを、サービスレベルの違反を被るデータベースに割当てることができる。たとえば現在の例において、データベース２２０に対するデータベースディレクタは、データベースインスタンスを放棄した後に、サービスレベルの違反を引続き検出し、それに応答して、そのクラスタディレクタ、すなわちディレクタ３８０にNEED-INSTANCE要求を送信する。結果的に、ディレクタ３８０は、より多くの自由ノードがクラスタ１１０に追加されたことを検出した後に、その自由ノードにデータベースインスタンスを供給することにより、要求の１つに応答することができる。

ファームディレクタ
ファームディレクタは、クラスタファーム内のクラスタ間におけるノードの割当、すなわち、１つのクラスタからノードを除去してそのノードを別のクラスタに供給することにより、クラスタ間においてノードを再編成する責任を負う。クラスタディレクタはまた、クラスタワイドなポリシーも実施する。クラスタワイドなポリシーは、たとえば、クラスタ内のノードのカーディナリティが、最小値および／または最大値以内に入ることを要求し得る。

ファームディレクタは、クラスタディレクタからのNEED-NODE要求に応答して、クラスタにノードを供給し、クラスタのサービスレベルに関する合意の影響下にある別のクラスタから自由ノードを除去する。ファームディレクタは、クラスタファーム内のクラスタディレクタと通信し、ノードの割当を調停する。このプロセスは、クラスタディレクタに「RELINQUISH-NODE」要求を送信することを必然的に伴い、クラスタディレクタは、ノードを放棄し得るか否かを示すために応答する。ファームディレクタは、これらの応答に基づいてクラスタを選択して、選択したクラスタのクラスタディレクタと対話し、クラスタからノードを除去する。クラスタからのノードの除去は、データベースインスタンスを休止状態にすることを必然的に伴い得る。データベースインスタンスが一旦休止状態にされると、ファームディレクタは、選択したクラスタからノードを除去し、この目的で提供されたＡＰＩを用いるクラスタウェアを呼出すことによって、このノードを必要とするクラスタに、このノードを供給する。

加えて、ファームディレクタは、各クラスタ上で作動する作業負荷モニタから受取った性能メトリクスを用いて、クラスタファーム内のクラスタの性能を監視する。クラスタが、そのクラスタについてのサービスレベルに関する合意に違反した状態で作動していること、または、他のクラスタほど作動していないことを性能メトリクスが示した場合、ファームディレクタは、より良好に作動するクラスタから最も作動していないクラスタに、１つ以上のノードをシフトする。

ディレクタの選択
以前に述べたように、データベースのデータベースインスタンス内には、活動中のデータベースディレクタまたは待機中のディレクタとして働き得る複数のディレクタが存在する。したがって、どのディレクタが活動中のディレクタであるかを決定するためのメカニズムが必要とされる。さらに、活動中のディレクタの故障時に、待機中のデータベースディレクタを選択して活動中のデータベースディレクタにする必要がある。同種の必要性が、クラスタディレクタおよびファームディレクタにも存在する。活動中のディレクタを選択するプロセスを、ここで、ディレクタ選択と呼ぶ。

データベースディレクタが選択され得るさまざまな態様が存在する。第１の態様は、データベースのグローバルロックの使用を必要とする。データベースのグローバルロックは、データベースのすべてのデータベースインスタンスの制御下で稼動するプロセスを同期させるために使用される。データベースディレクタは、始動時に、排他的なロックを要求する。いずれのデータベースディレクタもロックを保持していない場合、データベースディレクタにロックが与えられ、このデータベースディレクタが、データベースディレクタの立場を取る。ロックをそれ以降に要求する他のディレクタにはロックが与えられず、仮にロックが与えられる場合も、ロックが与えられるまで待機中のディレクタの立場を取る。これらの要求は、要求者によって与えられるか、または無効にされるまで、保留の状態に置かれる。

マルチノードデータベースサーバは、データベースグローバルロックの保持者がシステム故障を被った時点を検出する。この場合、故障した保持者のデータベースグローバルロックは、取消されるか、または解放され、そのデータベースグローバルロックに対する保留中の要求が、待機中のデータベースディレクタに与えられる。ロックが与えられた待機中のデータベースディレクタは、その後、データベースディレクタの役割を果たす。

ディレクタ選択のための別の技術は、プロセスグループの使用を必要とする。プロセスグループは、クラスタ内のあらゆるノード上で実行されるプロセスが参加することのできるグループである。グループのメンバーには、別のメンバーが（たとえばシステム故障により）いつ稼動を停止するかまたはいつプロセスグループを離れるかが通知される。加えて、メンバーには、グループへの参加時にｉｄが割当てられる。

ディレクタが始動すると、ディレクタは、そのデータベース用のプロセスグループに参加する。参加した時点で、ディレクタが最高位のメンバーｉｄを有していた場合、そのディレクタは、そのデータベースに対してデータベースディレクタの立場を取る。活動中のディレクタが稼動を停止すると、プロセスグループのメンバーに通知され、最高位のメンバーｉｄを有する１つのメンバーが、データベースディレクタの役割を引き受ける。

クラスタディレクタの選択には、同様の技術を用いることができる。ディレクタの選択に、クラスタワイドなロックを使用することができ、または、クラスタ用のプロセスグループを使用することができる。

このような技術により、クラスタディレクタの役割を果たすディレクタが、以前の活動中のクラスタディレクタのデータベースとは異なるデータベースに対するディレクタとなり得ることも可能である。その結果、メッセージ待ち行列は、異なるデータベース上に存在し得る。データベース上のテーブルは、別のデータベースのデータベースインスタンス上に存在するプロセスよりも効率的に、そのデータベース用のデータベースインスタンス上に存在するプロセスによってアクセスされ得る。

活動中のディレクタの役割を果たす待機中のディレクタが、同じデータベース用のデータベースインスタンスによって確実にホストされるようにするために使用され得る技術が、静的データ指定技術である。この技術により、データベースは、クラスタに対するクラスタディレクタをホストする（すなわち、そのデータベースインスタンスがホストする）１つのデータベースとして指定される。そのデータベースに対するディレクタのみが、クラスタに対するクラスタディレクタの役割を果たす。これらのディレクタ間におけるディレクタの選択は、グローバルデータベースロックまたはデータベースに対するプロセスグループのいずれかを用いることにより実行され得る。

データベースは、このためにクラスタウェアによって設けられたインターフェイスを用いる管理者によって指定され得る。待機中のクラスタディレクタの可用性を高めるために、高位の優先順位と、高い、最小／最大のカーディナリティ要件とを有するデータベースを指定することができ、相対的に多数の待機中のディレクタを確保する。静的なデータベース指定の手法を用いて、活動中のファームディレクタを選択することができる。

ディレクタの階層を用いてファームクラスタ内のリソースの管理を組織化することにより、リソースの管理に必要とされる情報の生成および交換が容易になる。一般に、特定のデータベース内で稼動するプロセス（すなわち、特定のデータベース用のデータベースインスタンスのプロセス）は、このデータベース内に存在しないプロセスよりも効率的に、そのデータベース内にある他のプロセスと通信することができる。したがって、データベースに対するデータベースディレクタとして働き、かつ、そのデータベース内で稼動する１つ以上の作業負荷モニタからのサービスの性能メトリクスを獲得するディレクタは、他のデータベース内で稼動するディレクタよりも効率的に、そのデータを獲得することができる。加えて、データベース内には１つの活動中のデータベースディレクタしか存在しないため、データベースを稼動するサービスについての情報、たとえばサービスの性能メトリクス、サービスレベルに関する合意、メッセージ待ち行列のデータ等を獲得および生成する作業は、１つのディレクタによってのみ実行されることを必要とする。

クラスタディレクタについても同様に、クラスタ内の１つのディレクタのみが、メッセージ待ち行列にアクセスし、どのノードがクラスタ内に存在するか、および、どのデータベースのどのデータベースインスタンスをノードがホストしているかを追跡するのに必要とされる情報と、クラスタのサービスレベルに関する合意とを獲得する作業を実行しなければならない。

情報および情報の交換が分配される態様を用いて、ディレクタ自体がサービス性能を管理するために行なわなければならないアクションと、ディレクタが別のディレクタにどのアクションを上げるか、または委託するかとが規定される。たとえば、データベース間におけるデータベースインスタンスの再割当は、どのノードがクラスタ内で利用可能であるか、および、どのノードがどのデータベースインスタンスを有するか等の情報を認識していることを必要とする。したがって、このような情報を認識していないデータベースディレクタが、データベース間のデータベースインスタンスの再割当の形態を取ったアクションを要求するサービスレベルの違反を検出すると、データベースディレクタは、このような情報を認識するクラスタディレクタに、このアクションを上げる。

代替的な実施例の例
この発明の一実施例は、データベースサービス間およびデータベースサービスのサブカテゴリ間でマルチノードシステムのリソースを動的に割当てることによって示された。しかしながら、この発明はそれに限定されない。

たとえば、この発明の一実施例を用いて、アプリケーションサーバによって提供される
サービス間において、アプリケーションサーバをホストするマルチノードシステムのコンピュータリソースを割当てることができる。アプリケーションサーバは、たとえば、アプリケーションサーバがクライアントとデータベースサーバとの間に位置する３層アーキテクチャの一部である。このアプリケーションサーバは、アプリケーションコードを記憶し、アプリケーションコードへのアクセスを提供し、アプリケーションコードを実行するために主に使用され、データベースサーバは、アプリケーションサーバ用のデータベースを記憶し、アプリケーションサーバ用のデータベースへのアクセスを提供するために主に使用される。アプリケーションサーバは、データベースサーバにデータの要求を送信する。要求は、アプリケーションサーバに記憶されたアプリケーションコードを実行することに応答して、アプリケーションサーバにより生成され得る。アプリケーションサーバの一例が、オラクル９ｉアプリケーションサーバまたはオラクル１０ｇアプリケーションサーバである。ここに記載したマルチノードサーバの例と同様に、アプリケーションサーバは、複数のノード上で実行される複数のサーバインスタンスとして分配され得、サーバインスタンスは、サーバインスタンス間で移動され得る複数のセッションをホストする。

この発明はまた、同じソフトウェア製品または同じバージョンのソフトウェア製品の複製を実行するサーバインスタンスのみで構成される同種のマルチノードサーバに限定されない。たとえば、マルチノードデータベースサーバは、サーバインスタンスのいくつかのグループで構成され得、各グループは、異なるベンダからの異なるデータベースサーバソフトウェアを実行し、または、同じベンダからのデータベースサーバソフトウェアの異なるバージョンを実行する。

透過的なセッション移動
透過的なセッション移動により、クライアントは、最初のセッションが確立されたアプリケーションに対して透過的な態様で、或るサーバ上のセッションから別のサーバ上のセッションに切換えられ得る。移動という用語は、サーバ上の既存のセッションのクライアントが、既存のセッションから別のセッションに切換えられる動作を指し、既存のセッションが終了されること、および、クライアントが既存のセッションの代わりに別のセッションを使用することを可能にする。既存のセッションは、ここでは、移動されたと呼ばれる。「透過的な」という用語は、ソフトウェアのユニットに関し、そのユニット内で、動作を実行するように適合された命令の実行を必要としない態様で、動作を実行することを指す。したがって、クライアントは、透過的なセッション移動の下で、移動を行なうように適合されたアプリケーション命令を実行することなく、セッション間で切換えられる。その代わりに、それを介してアプリケーションがサーバと対話するクライアント側のインターフェイス構成要素が、移動の詳細に対処し、クライアント側のインターフェイス構成要素の内部状態を変更して移動を行なう。ここに記載する技術を開始するために、レガシーアプリケーションを変更する必要はない。

セッションを移動するために、セッションの状態が収集および復元される。セッションの状態の収集は、セッションのセッション状態の真の複製としてバイトのストリームを生成することを必然的に伴い、バイトのストリームは、オブジェクト、ファイル、または他の種類のデータ構造に記憶され得、セッションを復元するために後にアクセスされ得る。透過的なセッション移動の下で、クライアントのセッションはソースサーバ上で収集され、データ構造内で記憶されて宛先サーバに移送されるバイトのストリームを生成する。そして、そこで宛先サーバは、クライアントに対して確立された宛先サーバ上のセッションに、バイトのストリームをロードすることにより、セッションを復元する。

セッションの移動
データベースセッションは、今後のアプリケーション呼出が、先行のアプリケーション呼出によって生成されたセッション状態に依存するときに、「ステートフル」であると考
えられる。ステートフルなセッションのセッション状態に対して、今後のアプリケーション呼出が潜在的な依存性を有することにより、ステートフルなデータベースセッションの移動は、ソースインスタンスに記憶されたセッション状態の部分が、別のデータベースインスタンスに転送され得るかどうかを判断することを必然的に伴い、転送され得る場合は、ソースデータベースインスタンスと宛先インスタンスとの間でセッション状態の複製を転送することを必然的に伴う。一実施例において、ソースインスタンスに記憶されたセッション状態の部分が別のデータベースインスタンスに転送され得るかどうかを判断するために、さまざまな移動の確認が行なわれて、セッション状態が別のデータベースインスタンスに転送され得るかどうかを判断する。これらの移動の確認は、データベースセッションがトランザクション境界に存在するか、呼出の境界に存在するか、または構成要素の境界に存在するかを判断することを含む。

現時点で、そのセッションに対して実行されている活動中のトランザクションが存在しない場合、データベースセッションは、トランザクション境界に存在する。トランザクションは、原子単位として実行される作業の論理単位である。データベースシステムの場合、データベースは、トランザクションによって行なわれた変更のすべてを反映するか、または、トランザクションによって行なわれた変更のいずれをも反映せず、データベースの整合性を確保しなければならない。その結果、データベースには、トランザクションが完全に実行されるまで、トランザクションによって行なわれた変更が永続的に適用されない。トランザクションによって行なわれた変更が永続的なものになったときに、トランザクションは「コミットする」と言われる。トランザクションがコミットされないか、中断されないか、または終了されない場合、トランザクションは活動中である。

データベースインスタンスがクライアントの呼出の実行を終了している場合、セッションは、呼出の処理の中間ステージではなく、呼出の境界に存在する。たとえば、データベースインスタンスは、呼出を処理してデータベースステートメントを実行するために、その各々が特定の種類の演算に対応するステージを通過する。これらのステージは、（１）カーソルの作成、（２）データベースステートメントの構文解析および変数の結合、（３）データベースステートメントの実行、（４）クエリーに返すための行のフェッチ、および（５）カーソルの閉鎖である。これらのステージは、「オラクル８サーバの概念（Oracle8 Server Concepts）」、リリース（Release）８．０、第３巻(Volume) （この内容は、ここに引用により援用される）、第２３章において、より詳細に記載されている。中間ステージは、呼出の処理が完了する前に実行される演算である。中間ステージは、ステージ（１）〜（５）である。インスタンスが呼出に応答してステップ（５）を実行した後、ソースセッションは呼出の境界に存在する。

セッションの「データベース構成要素」の各々が、そのそれぞれの構成要素の境界に存在する場合、セッションは構成要素の境界に存在する。データベース構成要素は、特化されかつ関連する機能を提供する、データベースサーバ上の１組のソフトウェアモジュールである。構成要素のセッション状態は特に、データベース構成要素によって生成および使用される。一実施例に従うと、セッション状態は、構成要素のセッション状態の合併または組合せとして見ることができる。以下の内容は、データベース構成要素の例である。カーソル構成要素は、データベースインスタンス内のカーソルを管理する。カーソルは、構文解析されたデータベースステートメントに関する情報と、データベースステートメントの処理に関連する他の情報とを記憶するために使用されるメモリの領域である。ＰＬ／ＳＱＬ構成要素は、ＰＬ／ＳＱＬ、すなわち、オラクル・コーポレイション（Oracle Corporation）により公表された手続データベース言語で書かれたコード（プロシージャ等）を実行する責任を負うデータベース構成要素である。セッションパラメータ構成要素は、セッションに関連する呼出および要求がどのように処理されるかを包括的に制御する属性を管理する責任を負うデータベース構成要素である。これらの属性は、構成要素のセッショ
ン状態に記憶される。たとえば、セッションパラメータは、クエリーの実行により返された結果に関して特定の人間言語を制御する属性を含み得る。Java（登録商標）構成要素は、Java（登録商標）で書かれたコード（クラスおよびオブジェクトメソッド等）を実行する責任を負うデータベース構成要素である。Java（登録商標）構成要素は、構成要素のセッション状態を用いて、Java（登録商標）コードの実行に関連する情報を記憶する。

データベース構成要素の構成要素のセッション状態が別のセッションに移動され得る場合、データベースセッションは、特定のデータベース構成要素に関する構成要素の境界に存在する。データベース構成要素は、データベース構成要素のそれぞれの構成要素のセッション状態が移動され得るか否かを示す値を返す関数を提供する。データベースセッションの構成要素セッション状態が移動されないかもしれない理由は、構成要素のセッション状態が、オープンファイルのファイル記述子を含むためである。ファイル記述子は、データベースセッションをホストするインスタンスにとってのみ有効な情報を含む。

関数は、各データベース構成要素によってサポートされるコールバック関数のインターフェイスの一部である。これらの関数は、構成要素のセッション状態を収集および復元するためだけでなく、構成要素のセッション状態が、セッションの移動を可能にするかどうかを判断するために呼出される。

性能メトリクスの生成
性能メトリクスは、１つ以上のリソースに関してサービスによって実現されるサービスの品質を示すデータである。バックグラウンドプロセスは、データベースインスタンス上でホストされる各セッションおよびサービスに対して生成される性能の統計値から性能メトリクスを生成する。性能の統計値は、性能メトリクスと同様に、性能の品質を示し得る。しかしながら、性能の測定値は一般に、特定のリソースの特定の使用についてのより詳細な情報を含む。性能の統計値には、たとえば、セッションによってどれだけの時間、ＣＰＵ時間が使用されたか、呼出の速度、セッションが行なった呼出の数、セッションに関し、呼出を完了するのに必要とされた応答時間、セッションのためのクエリーを構文解析するのにどれだけのＣＰＵ処理時間が使用されたか、クエリーを実行するためにどれだけのＣＰＵ処理時間が使用されたか、セッションに対していくつの論理読出および物理読出が実行されたか、ならびに、さまざまなリソースに対する入出力動作に対する待ち時間、たとえば特定の１組のデータブロックを読出すか、または書込むための待ち時間が含まれる。セッションに対して生成された性能の統計値は、セッションに関連付けられたサービスによって集計される。

データベースインスタンス上で確立された各セッションに対し、データベースインスタンス上でセッションを確立する動作の一部として、セッションオブジェクトが作成される。セッションオブジェクトは、セッションを管理するためにデータベースインスタンスによって使用される情報の項目を含む。情報のこれらの項目の中には、セッションに対して規定されるサービス識別子がある。一例において、サービスｉｄは、サービスのサービス名から生成されたハッシュ値である。

性能の統計値は、セッション内で要求された作業を実行するプロセスによって生成および集計される。たとえば、データベースセッションは、クエリーを実行する要求を送信するクライアントに対して確立される。そのセッションに対するプロセスは、データベースサーバのソフトウェアを実行し、クエリーを構文解析して、クエリーを並列に計算するための実行プランを考案する。データベースクエリーを構文解析し、実行プランを考案し、クエリーを計算するデータベースサーバのソフトウェアはまた、性能の統計値を生成および集計する。データベースサーバのソフトウェアは、セッションおよびそのセッションのサービスにより性能の統計値を集計する。この性能の統計値は、性能の統計値のリポジト
リに記憶され、このリポジトリは、たとえば、セッションに関連するか、または、いずれかのセッションから接続を解除されたサービスに関連するインメモリ固定テーブルであり得る。セッションに関する性能の統計値は、そのセッションのためのインメモリテーブル内で集計および記憶される。サービスに関する性能の統計値は、そのサービスのためのインメモリテーブル内で集計および記憶される。

セッションは、たとえばサービスＰＡＹに関連する。セッションに割当てられたデータベースプロセスは、クエリーを計算するために０．４秒のＣＰＵ時間を使用する。このプロセスは、サービスＰＡＹのためのインメモリテーブル内の小計に０．４を加算する。

作業負荷モニタは、定期的に（５秒ごとに等）、性能の統計値のリポジトリにアクセスして性能メトリクスを生成し、その生成した性能メトリクスを性能メトリクスのリポジトリに記憶する。性能メトリクスのリポジトリは、好ましくは、インメモリデータベーステーブルである。作業負荷モニタは、性能の統計値のリポジトリに５秒ごとにアクセスして、性能グレードを含む性能メトリクスを生成することができる。性能グレードは、接続時間の平均化のためにリスナーに送信される。リスナーは、この性能グレードを用いて、接続時間の平均化を実行し、サービスに対してより良好な性能を提供するデータベースインスタンス上のサービスに対する接続要求に対し、セッションを確立する。

作業負荷モニタはまた、生成された性能メトリクスを比較して、サービスレベルに関する合意の違反を検出することができる。サービスに関する性能の違反が検出されると、作業負荷モニタは、サービスレベルの違反に応答する責任を負うディレクタ（データベースディレクタ等）に警告するためにメッセージを送信する。

サービスおよびそのさまざまな属性と、サービスの品質（サービスレベルに関する合意等）とは、規定される必要がある。一実施例に従うと、データベースサーバは、人間の管理者からコマンドを受取り、そしてデータベースサーバのサービスについての定義を作成および変更するコマンドラインインターフェイスを設ける。これらの定義は、「サービスプロファイル」としてのデータベース内のディクショナリに、データベース構成データとして記憶される。

ハードウェアの概観
図６は、この発明の一実施例が実現され得るコンピュータシステム６００を示すブロック図である。コンピュータシステム６００は、バス６０２または情報を通信するための他の通信メカニズムと、バス６０２に結合されて情報を処理するためのプロセッサ６０４とを含む。コンピュータシステム６００は、バス６０２に結合されてプロセッサ６０４が実行する命令および情報を記憶するためのメインメモリ６０６、たとえばランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置も含む。メインメモリ６０６は、プロセッサ６０４が実行する命令の実行中に、一時的数値変数または他の中間情報を記憶するためにも使用され得る。コンピュータシステム６００は、バス６０２に結合されてプロセッサ６０４に対する静的情報および命令を記憶するための読出専用メモリ（ＲＯＭ）６０８または他の静的記憶装置をさらに含む。磁気ディスクまたは光学ディスク等の記憶装置６１０が設けられてバス６０２に結合され、情報および命令を記憶する。

コンピュータシステム６００は、コンピュータユーザに情報を表示するためのディスプレイ６１２、たとえば陰極線管（ＣＲＴ）に、バス６０２を介して結合され得る。英数字キーおよび他のキーを含む入力装置６１４がバス６０２に結合されて、情報およびコマンド選択をプロセッサ６０４に通信する。別の種類のユーザ入力装置が、方向情報およびコマンド選択をプロセッサ６０４に通信してディスプレイ６１２上のカーソルの動作を制御するためのカーソル制御装置６１６、たとえばマウス、トラックボール、またはカーソル
方向キーである。この入力装置は一般に、２つの軸、すなわち第１の軸（ｘ等）および第２の軸（ｙ等）において２自由度を有し、これによって入力装置は平面上で位置を特定することができる。

この発明は、この明細書に記載された技術を実現するためにコンピュータシステム６００を用いることに関する。この発明の一実施例によると、これらの技術は、メインメモリ６０６に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ６０４が実行することに応答して、コンピュータシステム６００により実行される。このような命令は、別のコンピュータ読取可能な媒体、たとえば記憶装置６１０からメインメモリ６０６内に読出すことができる。メインメモリ６０６に含まれる命令のシーケンスを実行することにより、プロセッサ６０４はこの明細書に記載されたプロセスのステップを実行する。代替的な実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せて結線回路を用いて、この発明を実施することができる。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアのいずれかの特定の組合せに限定されない。

この明細書で用いられる「コンピュータ読取可能な媒体」という用語は、プロセッサ６０４に対して実行のために命令を提供することに携わる、いずれかの媒体を指す。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含む多くの形態を取り得るが、これらに限定されない。不揮発性媒体には、たとえば記憶装置６１０等の光学または磁気ディスクが含まれる。揮発性媒体には、メインメモリ６０６等の動的メモリが含まれる。伝送媒体には、同軸ケーブル、銅線、および光ファイバが含まれ、バス６０２を有するワイヤが含まれる。伝送媒体は、電波データ通信および赤外線データ通信の間に生成されるもの等の音波または光波の形態を取り得る。

コンピュータ読取可能な媒体の一般的な形態には、たとえばフロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、他のいずれかの磁気媒体、ＣＤ−ＲＯＭ、他のいずれかの光学媒体、パンチカード、紙テープ、孔のパターンを有する他のいずれかの物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のいずれかのメモリチップもしくはカートリッジ、以下に述べる搬送波、またはコンピュータが読出すことのできる他のいずれかの媒体が含まれる。

プロセッサ６０４に対して実行のために１つ以上の命令の１つ以上のシーケンスを搬送することに対し、コンピュータ読取可能な媒体のさまざまな形態が関与し得る。たとえば、命令は、最初に遠隔コンピュータの磁気ディスクで搬送され得る。遠隔コンピュータはそれらの命令をそれ自体の動的メモリにロードして、それらの命令を、モデムを用いて電話回線経由で送信することができる。コンピュータシステム６００に対してローカルなモデムが電話回線上のデータを受信して、赤外線送信機を用いてそのデータを赤外線信号に変換することができる。赤外線信号によって搬送されたデータは赤外線検出器によって受信され得、適切な回路がそのデータをバス６０２上に出力することができる。バス６０２はそのデータをメインメモリ６０６に搬送し、そこからプロセッサ６０４が命令を取り出して実行する。メインメモリ６０６が受信した命令は、プロセッサ６０４による実行前または実行後のいずれかに、記憶装置６１０に状況に応じて記憶され得る。

コンピュータシステム６００は、バス６０２に結合された通信インターフェイス６１８も含む。通信インターフェイス６１８は、ローカルネットワーク６２２に接続されたネットワークリンク６２０に対する双方向のデータ通信結合を提供する。たとえば通信インターフェイス６１８は、対応する種類の電話回線に対するデータ通信接続を設けるための統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであり得る。別の例として、通信インターフェイス６１８は、互換性を有するローカルエリアネットワーク（ＬＡＮ）にデータ通信接続を設けるためのＬＡＮカードであり得る。無線リンクもまた実現することが
できる。このようなどの実現例においても、通信インターフェイス６１８は、さまざまな種類の情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送受信する。

ネットワークリンク６２０は一般に、１つ以上のネットワーク経由で他のデータ装置に対してデータ通信を提供する。たとえば、ネットワークリンク６２０は、ローカルネットワーク６２２経由で、ホストコンピュータ６２４か、またはインターネットサービスプロバイダ（Internet Service Provider）（ＩＳＰ）６２６により運営されるデータ装置に接続を提供することができる。ＩＳＰ６２６は次いで、現在一般に「インターネット」６２８と呼ばれるワールドワイドパケットデータ通信網を介してデータ通信サービスを提供する。ローカルネットワーク６２２およびインターネット６２８はともに、デジタルデータストリームを搬送する電気信号、電磁信号、または光信号を用いる。さまざまなネットワークを経由する信号と、ネットワークリンク６２０上の、通信インターフェイス６１８経由の信号とは、コンピュータシステム６００との間でデジタルデータを搬送し、情報を運ぶ搬送波の例示的形態である。

コンピュータシステム６００は、ネットワーク、ネットワークリンク６２０、および通信インターフェイス６１８を介してメッセージを送信して、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ６３０は、インターネット６２８、ＩＳＰ６２６、ローカルネットワーク６２２、および通信インターフェイス６１８経由で、アプリケーションプログラムに対して要求されたコードを送信することができる。

受信されたコードは、受信されたときにプロセッサ６０４によって実行され得、および／または後の実行のために記憶装置６１０もしくは他の不揮発性記憶装置に記憶され得る。このようにして、コンピュータシステム６００は搬送波の形でアプリケーションコードを得ることができる。

上述の明細書では、この発明の実施例を実現例ごとに異なり得る多数の特定の詳細を参照して説明してきた。したがって、この発明が何であるか、およびこの発明を目指して出願人が何を意図しているかを排他的に示す唯一のものが、この出願に由来する一組の請求項であり、このような請求項の結果、特有の表現形式となり、今後のどのような補正をも含む。このような請求項に含まれる用語に対してここで明示されたどのような定義も、請求項で用いられる用語の意味を決定するものとする。したがって、請求項に明示的に記載されていない限定、要素、特性、特徴、利点または属性は、このような請求項の範囲を決して限定しない。したがって、明細書および図面は限定的な意味ではなく例示的な意味で捉えられるべきである。

この発明の一実施例が実現され得るマルチノードコンピュータシステムを示すブロック図である。 この発明の一実施例に従った１クラスタのノードを示すブロック図である。 この発明の一実施例に従った、１クラスタのノードと、データベースにさまざまなサービスを提供することに携わるマルチノードデータベースサーバとの構成要素を示すブロック図である。 ターゲットデータベースインスタンスにサービスを拡張し、ターゲットデータベースインスタンス上のサービスを休止状態にするための手続きを示すフロー図である。 ２段階の休止を行なうための手続きを示すフロー図である。 この発明の一実施例で使用され得るコンピュータシステムのブロック図である。

Claims (21)

1. マルチノードコンピュータシステムのコンピュータリソースを動的に割当てるための方法であって、
   前記マルチノードコンピュータシステム上で稼動する複数のサービスにより実現される性能を監視する、コンピュータにより実現されるステップを含み、前記複数のサービスは、第１のサービスおよび第２のサービスを含み、前記方法はさらに、
   複数のサービスの前記性能を監視する前記ステップに基づき、前記複数のサービスの各サービスにより実現される性能を示す性能メトリクスを生成する、コンピュータにより実現されるステップと、
   前記性能メトリクスに基づき、前記マルチノードコンピュータシステムが、前記第１のサービスについてのサービスレベルに関する合意の違反を検出する、コンピュータにより実現されるステップと、
   前記マルチノードコンピュータシステムが、前記サービスレベルに関する合意の前記違反を検出することに応答して、前記第１のサービスと前記第２のサービスとの間で前記マルチノードシステムのコンピュータリソースの割当を調節する、コンピュータにより実現されるステップとを含む、方法。
2. リソースの割当を調節する前記ステップは、前記第１のサービスをホストするために前記マルチノードシステムの別のノードを割当てるステップを含む、請求項１に記載の方法。
3. 第１のサーバは、前記マルチノードシステムの第１のノード上で稼動し、リソースの割当を調節する前記ステップは、前記第１のサーバに前記第１のサービスを拡張するステップを含む、請求項１に記載の方法。
4. リソースの割当を調節するステップは、前記第１のサーバに前記第１のサービスを拡張する前記ステップを実行するために、前記第１のノードに前記第１のサーバを供給するステップを含む、請求項３に記載の方法。
5. 前記マルチノードシステムは、第１のノードおよび第２のノードを含み、
   第１のグループのセッションは、前記第１のノード上の前記第１のサービスに対して確立され、
   第２のグループのセッションは、前記第２のノード上の前記第１のサービスに対して確立され、
   リソースを割当てるステップは、前記第２のグループから前記第１のノードに少なくとも１つのセッションを移動するステップを含む、請求項１に記載の方法。
6. 前記コンピュータリソースは、リソースのプールを含み、
   コンピュータリソースの割当を調節する前記ステップは、前記第１のサービスに対し、階層内においてより高位の、リソースの第２のプールの割当を調節することを試みる前に、前記階層内においてより低位の、リソースの第１のプールの割当を調節することにより、前記性能の違反を解消することを試みるステップを含み、
   リソースの前記プールは、リソースの第１のプールとリソースの第２のプールとを含む、請求項１に記載の方法。
7. リソースの前記プールは、リソースの前記第１のプールとしてのサーバの第１のプールと、リソースの前記第２のプールとしてのノードの第２のプールとを含み、
   前記性能の違反を解消することを試みる前記ステップは、前記第１のサービスをホストするために前記第２のプールから別のノードを追加することを試みる前に、前記第１のサ
   ービスをホストするために前記第１のプールから別のサーバを割当てることを試みるステップを含む、請求項６に記載の方法。
8. 前記ステップはさらに、前記別のノードを追加することに応答して、前記別のノードに別のサーバを供給するステップを含む、請求項７に記載の方法。
9. 第１のマルチノードサーバは、第１のサーバ、第２のサーバ、および第３のサーバを含み、
   前記第１のサーバは、前記第１のサービスに対する複数のセッションをホストし、
   前記性能の違反を解消することを試みる前記ステップは、前記第１のサービスをホストするために前記第３のサーバを割当てる前に、前記第２のサーバに前記複数のセッションの少なくとも１つを移動することを試みるステップを含む、請求項６に記載の方法。
10. 前記複数のサービスの各サービスは、前記マルチノードシステムにより実行される作業のカテゴリであり、
    前記マルチノードシステムのコンピュータリソースの割当を調節する前記ステップは、作業の前記複数のカテゴリの各カテゴリに対するコンピュータリソースの割当を調節するステップを含む、請求項１に記載の方法。
11. ソフトウェアの複数のユニットは、前記マルチノードシステムに相互接続された１組のクライアントコンピュータ上で実行され、
    作業の各カテゴリは、前記複数のユニットの中のソフトウェアの特定のユニットに対応する、請求項１０に記載の方法。
12. 作業の各カテゴリは、前記複数のユニットの中のソフトウェアの或る特定のユニットより生成された要求に応答して実行される作業に対応する、請求項１１に記載の方法。
13. 第１の組のノードおよび第２の組のノードを含むマルチノードコンピュータシステムのコンピュータリソースを動的に割当てるための方法であって、
    性能メトリクスを生成するために、前記マルチノードシステム上でホストされる複数のサービスの性能を監視するステップと、
    複数のサービスの前記性能を監視する前記ステップに基づき、前記複数のサービスの各サービスにより実現される性能を示す性能メトリクスを生成するステップとを含み、
    前記マルチノードシステムは、第１の組のノードおよび第２の組のノードを含み、前記方法はさらに、
    前記第１の組のノード上で第１のマルチノードサーバおよび第２のマルチノードサーバを稼動するステップを含み、
    前記複数のサービスは、前記第１のマルチノードサーバによりホストされる第１のサービスおよび第２のサービスを含み、前記方法はさらに、
    前記第１の組のノード上で稼動する第１のシステム構成要素が、前記性能メトリクスに基づき、前記第１のサービスと前記第２のサービスとの間での前記第１のマルチノードサーバのリソースの割当を調節するステップと、
    前記第１の組のノード上で稼動する第２のシステム構成要素が、前記性能メトリクスに基づき、前記第１のマルチノードサーバと前記第２のマルチノードサーバとの間での前記第１の組のノードのリソースの割当を調節するステップとを含む、方法。
14. 前記ステップはさらに、
    前記第１のシステム構成要素が、前記第１のサービスについてのサービスレベルの違反を検出するステップと、
    前記第１のサービスについての前記サービスレベルの違反を検出することに応答して、
    前記第１のシステム構成要素が、前記第１のマルチノードサーバと前記第２のマルチノードサーバとの間で前記第１の組のノードのリソースの割当を調節するために、前記第２のシステム構成要素に第１の要求を送信するステップとを含む、請求項１３に記載の方法。
15. 前記第２のシステム構成要素が前記第１のマルチノードサーバと前記第２のマルチノードサーバとの間で前記第１の組のノードのリソースの割当を調節する前記ステップは、前記第２のシステム構成要素が前記第１のマルチノードサーバと前記第２のマルチノードサーバとの間でノードを割当てるステップを含む、請求項１３に記載の方法。
16. 前記ステップはさらに、
    前記第１のシステム構成要素が、前記第１のサービスについてのサービスレベルの違反を検出するステップと、
    前記第１のサービスについての前記サービスレベルの違反を検出することに応答して、前記第１のシステム構成要素が、前記第１のサービスと前記第２のサービスとの間で前記第１のマルチノードサーバのリソースの割当を調節するステップとを含む、請求項１３に記載の方法。
17. 前記第１のマルチノードサーバは、第１のサーバインスタンスおよび第２のサーバインスタンスを含み、
    前記第１のマルチノードサーバのリソースの割当を調節する前記ステップは、前記第２のサーバに前記第１のサービスをホストさせるステップを含む、請求項１６に記載の方法。
18. 前記第１のマルチノードサーバは、第１のサーバインスタンスおよび第２のサーバインスタンスを含み、
    前記第１のサーバインスタンスは、前記第１のサービスに対する少なくとも１つのセッションをホストし、
    前記第２のサーバインスタンスは、前記第１のサービスに対する少なくとも１つのセッションをホストし、
    前記第１のマルチノードサーバのリソースの割当を調節する前記ステップは、前記第１のサーバインスタンスと前記第２のサーバインスタンスとの間で前記第１のサービスに対するセッションの均衡を調節するステップを含む、請求項１６に記載の方法。
19. 前記第１の要求を受取ることに応答して、前記第２のシステム構成要素は、前記第１のマルチノードサーバの別のサーバインスタンスを別のノードに供給する、請求項１４に記載の方法。
20. 前記第１の組のノードは、少なくとも１つの永続的な記憶装置へのアクセスを共有するノードの第１のクラスタであり、
    前記第２のシステム構成要素は、別のノードを要求するために、前記マルチノードシステム上で稼動する第３のシステム構成要素に第２の要求を送信し、
    前記第３のシステム構成要素は、前記性能メトリクスに基づき、前記マルチノードシステム内の前記第１のクラスタと別のクラスタとの間でノードを割当てる、請求項１９に記載の方法。
21. 別のサーバインスタンスを供給することにより、前記別のサーバインスタンスが利用可能であることを示すために前記第１のシステム構成要素に対してメッセージを前記第２のシステム構成要素に送信させる、請求項１９に記載の方法。

Images