JP4805150B2 - オンデマンドノードならびにサーバインスタンス割当および割当解除 - Google Patents

Description

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

本願は以下の米国出願に関係する：
２００４年８月１２日にLakshminarayan Chidambaranらにより提出され、ここに引用により援用される、米国出願番号ＸＸＸ／ＸＸＸ，ＸＸＸ「オンデマンドノードならびにサーバインスタンス割当および割当解除（On Demand Node and Server Instance Allocation and De-Allocation）」（代理人番号５０２７７−２４１３）；
１１／２１／２００３に提出されここに引用により援用される米国出願第１０／７１８，７４７号「データベースの自動および動的提供（Automatic and Dynamic Provisioning
of Databases）」（代理人番号５０２７７−２３４３）；
Benny Souderらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「マルチノードシステムにおけるリソースの動的割当の階層的管理（Hierarchical Management of the Dynamic Allocation of Resources in a Multi-Node System）」（代理人番号５０２７７−２３８２）；
Sanjay Kaluskarらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「サーバにわたっての透明なセッション移動（Transparent Migration Across Servers）」（代理人番号５０２７７−２３８３）；
Lakshminarayan Chidambaranらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「サービスのホストとなるマルチノード環境におけるサービスパフォーマンスグレードの計算（Calculation of Service Performance Grades in a Multi-Node Environment That Hosts the Services）」（代理人番号５０２７７−２４１０）；
Lakshminarayan Chidambaranらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「マルチノードシステムにおける増分的ランタイムセッション平衡化（Incremental Run-Time Session Balancing in a Multi-Node System）」（代理人番号５０２７７−２４１１）；
Lakshminarayan Chidambaranらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「マルチノードシステムにおけるパフォーマンスおよびアベイラビリティレベルを実施するためのサービス配置（Service Placement for Enforcing Performance and Availability Levels in a Multi-Node System）」（代理人番号５０２７７−２４１２）；
Lakshminarayan Chidambaranらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸ「マルチノードシステムにおける回復可能非同期メッセージ駆動型処理（Recoverable Asynchronous Message Driven Processing
in a Multi-Node System）」（代理人番号５０２７７−２４１４）；および
Carol Colrainらにより２００４年８月１２日に提出されここに引用により援用される米国出願番号ＸＸ／ＸＸＸ，ＸＸＸの「サービスによる作業負荷管理（Managing Workload by Service）」（代理人番号５０２７７−２３３７）。

この出願は以下の国際出願に関係する：
２００４年８月９日にオラクル・インターナショナル・コーポレイション(Oracle International Corporation)により米国受理局にて提出されここに引用により援用される、「データベースの自動および動的提供（Automatic and Dynamic Provisioning of Databases）」（代理人番号５０２７７−２５７１）と称される国際出願番号ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ；
２００４年８月１３日にオラクル・インターナショナル・コーポレイションにより米国受理局にて提出されここに引用により援用される、「マルチノードシステムにおけるリソースの動的割当の階層的管理（Hierarchical Management of the Dynamic Allocation of
Resources in a Multi-Node System）」（代理人番号５０２７７−２５９２）と称される国際出願番号ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ；
２００４年８月１３日にオラクル・インターナショナル・コーポレイションにより米国受理局にて提出されここに引用により援用される、「サーバにわたっての透明なセッション移動（Transparent Migration Across Servers）」（代理人番号５０２７７−２５９３）と称される国際出願番号ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ；
２００４年８月１３日にオラクル・インターナショナル・コーポレイションにより米国受理局にて提出されここに引用により援用される、「サーバにわたっての、状態のないセッションの透明な移動（Transparent Migration of Stateless Sessions Across Servers）」（代理人番号５０２７７−２５９４）と称される国際出願番号ＰＣＴ／ＸＸＸＸ／ＸＸＸＸＸ。

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

発明の背景
多くの企業がそれらのデータ処理システムにおいてコストを低減し効率性を改善する方法を考えている。ある典型的な企業データ処理システムは個々のリソースをその企業のアプリケーションの各々に対して割当てる。十分なリソースが、各アプリケーションに対し、そのアプリケーションの推定されるピーク負荷を処理するよう得られる。各アプリケーションは異なる負荷特性を有し；いくつかのアプリケーションは日中使用中であり、いくつかの他のアプリケーションは夜使用中であり；いくつかのレポートは週１回実行され、いくつかの他のレポートは月１回実行される。その結果、利用されないで残る多くのリソースキャパシティが存在する。グリッド電算処理はこの利用されていないキャパシティの利用および削除を可能にする。実際、グリッド電算処理は電算処理の経済性を劇的に変えようとしている。

グリッドとは処理およびある度合の共有されたストレージを与える電算処理要素の集まりであり；グリッドのリソースは動的に割当てられてそのクライアントの電算上のニーズおよび優先事項を満たす。グリッド電算処理は、電算処理のコストを劇的に低減し、電算処理リソースのアベイラビリティを拡大し、より高い生産性およびより高い品質を与え得る。グリッド電算処理の基本的概念は電算処理をユーティリティとして考えることであり、それは電力グリッドまたは電話網に類似している。グリッドのクライアントはどこにそのデータがあるかまたはどこにおいて電算が実行されるかは構わない。クライアントが欲することは、電算がなされ情報がそのクライアントに対しそのクライアントが欲するときに送られることだけである。

それは電気ユーティリティが働く態様と類似しており；顧客はどこに発電機があるか、
またはどのように電気グリッドが結線されるかは知らない。顧客はただ電気を求めそれを得る。目的は電算処理をユーティリティ−−ユビキタスなコモディティ−−にすることである。したがってそれはグリッドという名を有する。

この、グリッド電算処理をユーティリティとする見方は、当然のことながら、クライアント側の見方である。サーバの側から、または裏方では、グリッドは、リソース割当、情報共有化、および高いアベイラビリティについてのものである。リソース割当は、確実に、リソースを必要とするかまたは要求するものすべてが、必要とするものを得るようにする。要求が処理されないままである間、リソースはアイドル状態ではいない。情報共有化は、クライアントおよびアプリケーションが必要とする情報が、その情報が必要とされる場所および時において利用可能であることを確実にする。高いアベイラビリティは、ちょうどユーティリティ会社が常に電力を供給しなければならないように、すべてのデータおよび電算が常にそこになければならないことを保証する。

データベースに対するグリッド電算処理
グリッド電算処理から恩恵を与り得るコンピュータ技術の１つの分野はデータベース技術である。グリッドは、複数のデータベースのサポートならびにリソースの動的割当および再割当を必要とされるように行なって各データベースに対する現在の要求をサポートし得る。データベースに対する要求が増大するにつれ、より多くのリソースがそのデータベースに対して割当てられ、一方、他のリソースは別のデータベースから割当を解除される。たとえば、ある企業グリッドにおいては、データベースはそのグリッド上の１つのサーバブレードにて動作している１つのデータベースサーバにより対応される。データベースからデータを要求するユーザの数が増大する。データベースに対する要求におけるこの増大に応答して、他のデータベースに対するデータベースサーバが１つのサーバブレードから取除かれ、増大したユーザ要求を経験しているデータベースに対するデータサーバがサーバブレードに供給される。

データベースに対するグリッド電算処理は異なるレベルでのリソースの割当および管理を必要とし得る。ある単一のデータベースに対応するレベルでは、データベースのユーザに対して与えられるパフォーマンスおよびリソースのアベイラビリティを監視し、データベースのリソースをユーザ間において割当てて、確実に各ユーザに対するパフォーマンスおよびリソースアベイラビリティが満たされるようにしなければならない。データベース間においては、グリッドのリソースの割当を管理してすべてのデータベースのユーザに対してパフォーマンスおよびリソースアベイラビリティ目標が満たされることを保証しなければならない。これら異なるレベルにおけるリソースの割当を管理する作業およびそのような管理を実行するべく必要とされる情報は非常に複雑である。したがって、データベース、およびグリッド内において異なるレベルでリソースを割当てる他のタイプのシステムに対するグリッド電算処理システムにおいてリソースの管理を単純にし効率的に取扱う機構が要求されている。

１つのそのような機構は「マルチノードシステムにおけるリソースの動的割当の階層的管理」（５０２７７−２３８２）に記載されるシステムであり、それはディレクタの階層を用いてリソースを異なるレベルにおいて管理する。ディレクタの１つのタイプであるデータベースディレクタは、あるデータベースのユーザ間においてそのデータベースに割当てられるリソースを管理する。たとえば、グリッドはデータベースに対するデータベースサーバの群のホストとなってもよい。その群におけるデータベースサーバはデータベースインスタンスと称される。各データベースインスタンスはユーザおよび１つ以上のサービスに対する多数のデータベースセッションのホストとなる。データベースディレクタはユ
ーザおよびサービス間においてデータベースに利用可能なリソースの割当を管理する。

サービスとは、１つ以上のクライアントのためにホスト対応されるある特定のタイプまたはカテゴリの作業である。サービスの一部として実行される作業はコンピュータリソースの任意の使用または消費を含み、たとえば、ＣＰＵ処理時間、揮発性メモリにおけるデータの記憶およびアクセス、永久的なストレージ（つまりディスク空間）に対する読出および書込、ならびにネットワークまたはバス帯域幅の使用を含む。サービスは、たとえば、データベースサーバのあるクライアントにおいてある特定のアプリケーションに対し実行される作業であってもよい。

データベースに対しては、データベースインスタンスの群の部分集合がある特定のサービスを与えるよう割当てられる。サービスを与えるよう割当てられたデータベースインスタンスはここにおいては「サービスのホストとなる」と称される。データベースインスタンスは２つ以上のサービスのホストとなってもよい。データベースのデータベースインスタンスがホストとなるサービスはここにおいては「データベースがホストとなる」と称される。

データベースがホストとなるサービスにより実現されるパフォーマンスおよびリソースのアベイラビリティは時としてパフォーマンスおよびリソースのアベイラビリティに対する要件を満たさないかもしれない。この状況が生じた場合、そのデータベースのホストとなる別のデータベースインスタンスおよびノードをグリッド内においてそのデータベースに割当ててもよい。しばしば、データベースに割当てるべく利用可能なノードの唯一のプールは既に他のデータベースおよびサービスに対して用いられている。ノードをデータベースに割当てることはしたがってノードを別のデータベースから割当解除することを必要とし、それは他のデータベースにおいてホスト対応されているサービスにより実現されるパフォーマンスおよびリソースのアベイラビリティに影響を与える。

前述のことに基づき、データベースの組に対して既に割当てられているノードのプールからあるノードを割当解除することを、そのデータベースの組がホストとなっているサービスのユーザに対するパフォーマンスおよびリソースアベイラビリティに対応するような態様で行なう方策を有することが望ましい。

このセクションにおいて記載される方策は追及され得る方策ではあるが、必ずしも、これまでに構想または追及されてきた方策ではない。したがって、特段の指示がない限り、このセクションにおいて記載される方策のいずれも、単にそれらがこのセクションに含まれるため、先行技術として適格である、と仮定されるべきではない。

この発明は、添付の図面の図において例示的に示されるものであって、限定的に示されるものではなく、そこにおいて同様の参照番号は同様の要素を示す。

発明の詳細な説明
リソースの割当をマルチノード環境において管理するための方法および装置を記載する。以下の記載においては、説明の目的で、数多くの具体的な詳細を述べてこの発明が十分に理解されるようにする。しかしながら、この発明はこれらの具体的な詳細なしに実施されてもよい。他の例においては、周知の構造および装置をブロック図形式で示すことにより、この発明を不必要に曖昧にすることを避ける。

ここに記載されるのはデータベースインスタンスおよびノードをデータベース間において効率よくかつ動的に割当および割当解除するための方策である。この方策は、この機能
を、複数のデータベースがホストとなるサービスのユーザに対応するような態様で実行する。

図１はこの発明のある実施例を実現するよう用いられてもよいマルチノードコンピュータシステムを示す。図１を参照して、それはクラスタファーム１０１を示す。クラスタファームとは、クラスタと称されるノードの群に組織化されたノードの組である。クラスタはある度合の共有されたストレージ（たとえばディスクドライブの組に対する共有されるアクセスなど）をクラスタにおけるノード間に与える。クラスタファーム１０１はクラスタ１１０、１７０および１８０を含む。クラスタの各々はデータベースに対するアクセスを与え管理する１つ以上のマルチノードデータベースサーバのホストとなる。

クラスタファームにおけるノードはネットワークを介して相互接続されるコンピュータ（たとえばワークステーション、パソコンなど）の形式であってもよい。代替的に、ノードはグリッドのノードであってもよい。グリッドはラック上の他のサーバブレードと相互接続されるサーバブレードの形式におけるノードからなる。各サーバブレードは包含的なコンピュータシステムであり、プロセッサ、メモリ、ネットワーク接続、および関連の電子機器を単一のマザーボード上に伴っている。典型的には、サーバブレードはオンボードのストレージ（揮発性メモリ以外）を含まず、それらはストレージユニット（たとえば共有されるディスクなど）をラック内における電源、冷却システムおよびケーブル配線とともに共有する。

クラスタファームにおけるクラスタの定義を行なう特性は、クラスタのノードは、ファーム内のクラスタ間において、ソフトウェア制御を介して、ノードを１つのクラスタから他のクラスタへ物理的に再接続する必要なく、自動的に転送されてもよい、というものである。クラスタファームはここにおいてはクラスタウェアと称されるソフトウェアユーティリティにより制御され管理される。クラスタウェアは、あるノードをあるクラスタから除去し、そのノードをあるクラスタに供給するよう実行されてもよい。クラスタウェアは人間の管理者から要求を受取るコマンドラインインターフェイスを与え、これにより管理者はコマンドを入力してノードをクラスタから与え除去することができる。インターフェイスはさらにアプリケーションプログラムインターフェイス（「ＡＰＩ」）の形式を取ってもよいが、それはクラスタファーム内において実行されている他のソフトウェアによって呼出されてもよい。クラスタウェアはファーム内においてクラスタの構成を定義するメタデータを使用し維持するが、それはクラスタ構成メタデータを含み、それはファームにおけるクラスタのトポロジーを定義し、どの特定のノードがそのクラスタにあるかということを含む。メタデータはクラスタウェアによりクラスタファームにおいてクラスタに対してなされる変更を反映するよう修正される。クラスタウェアの一例はOracle^TMにより開発されたソフトウェア、たとえばオラクル９ｉ・リアル・アプリケーション・クラスターズ（Oracle9i Real Application Clusters）またはオラクル・リアル・アプリケーション・クラスターズ・１０ｇ（Oracle Real Application Clusters 10g）などである。オラクル９ｉ・リアル・アプリケーション・クラスターズはMike AultおよびMadhu Tummaによるオラクル９ｉ・ＲＡＣ(Oracle9i RAC）：オラクル・リアル・アプリケーション・クラスターズ構成および内部（Oracle Real Application Clusters Configuration and Internals）、第２版（２００３年８月２日）に記載されている。

クラスタおよびマルチノードデータベースサーバ
クラスタ１１０、１７０および１８０は１つ以上のマルチノードデータベースサーバのホストとなる。クラスタ１１０はデータベース１５０に対するマルチノードデータベースサーバのホストとなり、そのマルチノードデータベースサーバはデータベースインスタンス１２３、１２５および１２７を含み、それらはノード１２２、１２４および１２６にお
いてそれぞれホスト対応される。クラスタ１１０は、さらに、データベース１６０に対するマルチノードデータベースサーバのホストとなり、そのマルチノードデータベースサーバはノード１３２、１３４および１３６においてそれぞれホスト対応されるデータベースインスタンス１３３、１３５および１３７を含む。

データベースサーバなどのようなサーバは、統合されたソフトウェア構成要素と、電算上のリソース、たとえばメモリ、ノード、およびそのノード上における、それら統合されたソフトウェア構成要素をプロセッサ上において実行するための処理などの割当との組合せであり、ソフトウェアと電算上のリソースとの組合せは１つ以上のクライアントのためにある特定の機能を実行することに捧げられる。データベース管理の中で、とりわけ、データベースサーバはある特定のデータベースに対するアクセスを支配しおよび容易にし、クライアントによるデータベースにアクセスする要求を処理する。

マルチノードコンピュータシステムにおける複数のノードからのリソースはある特定のサーバのソフトウェアを実行することに割当てられ得る。ソフトウェアとノードからのリソースの割当との各組合せはここにおいては「サーバインスタンス」または「インスタンス」と称されるサーバである。斯くして、マルチノードサーバは複数のノード上において動作し得る複数のサーバインスタンスを含む。マルチノードサーバのいくつかのインスタンスは同じノード上において動作しさえし得る。マルチノードデータバスサーバは複数の「データベースインスタンス」を含み、各データベースインスタンスはノード上にて動作し、ある特定のデータベースに対するアクセスを支配し容易にする。データベースインスタンス１２３、１２５および１２７は同じマルチノードデータベースサーバのインスタンスである。

サービス
先に言及したように、サービスとは１つ以上のクライアントのためにホスト対応されるある特定のタイプまたはカテゴリの作業である。１つのタイプのサービスはデータベースサービスである。クラスタ１１０は、あるデータベースサービスをデータベース１５０にアクセスすることのために与え、あるデータベースサービスをデータベース１６０にアクセスすることのために与える。一般に、データベースサービスとは、データベースサーバによりクライアントに対し実行される作業であり、典型的には、ある特定のデータベースに対するアクセスを必要とするクエリーを処理することを含む。

他のサービスと同様、データベースサービスはさらに分類されてもよい。データベースサービスはデータベース１５０に対してはさらにＦＩＮサービスおよびＰＡＹサービスに分類される。ＦＩＮサービスはデータベースインスタンス１２３および１２５によりＦＩＮアプリケーションに対して実行されるデータベースサービスである。典型的には、このサービスは、データベース１５０上において、ＦＩＮアプリケーションに対しデータベースデータを記憶するデータベースオブジェクトにアクセスすることを伴う。ＰＡＹサービスはデータベースインスタンス１２５および１２７によりＰＡＹアプリケーションに対して実行されるデータベースサービスである。典型的には、このサービスは、データベース１５０において、ＰＡＹアプリケーションに対してデータベースデータを記憶するデータベースオブジェクトにアクセスすることを伴う。

セッション
クライアントがクラスタ１１０上においてデータベースサーバとインタラクトするために、セッションがそのクライアントに対して確立される。セッション、たとえばデータベースセッションなどは、あるクライアントのためにサーバ、たとえばデータベースインスタンスなどに対して確立されるある特定の接続であり、それを介してクライアントは一連の要求（データベースステートメントの実行に対する要求）を発行する。データベースイ
ンスタンス上において確立される各データベースセッションごとに、データベースセッションの現在の状態を反映するセッション状態データが維持される。そのような情報は、たとえば、セッションが確立されるクライアントのアイデンティティ、およびデータベースセッション内においてソフトウェアを実行する処理により発生される一時的な可変値を含む。

クライアントは、データベースセッションの確立を、データベース接続要求をクラスタ１１０に送信することにより行なう。リスナ、たとえばリスナ１９０はデータベース接続要求を受取る。リスナ１９０は、クライアントデータベース接続要求を受けそれらの要求をクラスタ１１０内のデータベースインスタンスに向ける、クラスタ１１０上において実行される処理である。受取られたクラスタ接続要求はあるサービス（たとえばサービスＦＩＮおよびサービスＰＡＹ）に関連付けられる。クライアント要求はそのサービスのホストとなっているデータベースインスタンスに向けられ、そこにおいて、データベースセッションがそのクライアントに対して確立される。リスナ１９０はクライアントにとって透明な態様でその要求を特定のデータベースインスタンスおよび／またはノードに向ける。リスナ１９０はクラスタ１１０内におけるどのノードにおいて動作してもよい。一旦データベースセッションがクライアントに対して確立されると、クライアントはさらなる要求を発行してもよく、それらの要求は関数または遠隔手順呼出の形式であってもよく、トランザクションの実行を開始する要求、クエリーを実行する要求、更新および他のタイプのトランザクション動作を実行する要求、トランザクションを完遂またはそうでない場合には終了させる要求、およびデータベースセッションを終了させる要求を含む。

作業負荷を監視する
リソースは、パフォーマンスのレベルおよびそれらリソースに対する濃度制約を満たすよう割当および再割当される。ある特定のサービスに対して確立されるパフォーマンスのレベルおよびリソースアベイラビリティはここにおいてはサービスレベル取決めと称される。マルチノードシステムに一般に適用され、ある特定のサービスに対しては必ずしも適用されない、パフォーマンスのレベルおよびリソースに対する濃度制約はここにおいてはポリシーと称される。たとえば、サービスＦＩＮに対するサービスレベル取決めは、サービスＦＩＮに対する平均トランザクション時間はある所与のしきい値以下であるというパフォーマンスのレベルを必要とし、アベイラビリティ要件としては、少なくとも２つのインスタンスがサービスＦＩＮのホストとなることを必要としてもよい。あるポリシーは、任意のノードのＣＰＵ利用が８０％を超えてはならないことを必要としてもよい。

ポリシーはさらにここにおいてはバックエンドポリシーと称されてもよく、なぜならば、それらはバックエンドアドミニストレータにより用いられて、全体のシステムパフォーマンスを管理し、サービスの組の間におけるリソースの割当を、そのサービスの組すべてのサービスレベル取決めを満たすには十分なリソースがないと見なされる場合に行なうからである。たとえば、あるポリシーはより高い優先順位をあるデータベースに比して他のデータベースに割当てる。両方のデータベースのサービスのサービスレベル取決めを満たす十分なリソースがない場合、より高い優先順位を伴うデータベース、およびそのデータベースを用いるサービスが、リソースを割当てる際に優先される。

サービスレベル取決めを満たすため、ある機構が、さまざまなリソースに課せられる作業負荷を監視し測定するために必要とされる。作業負荷のこれらの測定を用いて、サービスレベル取決めが満たされているかを判断し、必要に応じてサービスレベル取決めを満たすようリソースの割当を調整する。

この発明のある実施例に従うと、作業負荷モニタが各データベースインスタンス上においてホスト対応され「パフォーマンスメトリクス」を発生させる。パフォーマンスメトリ
クスとはパフォーマンス測定に基づく１つ以上のリソースまたはサービスに対するパフォーマンスのレベルを示すデータである。これらの機能を実行するための方策が「サービスによる作業負荷の測定」（５０２７７−２３３７）に記載されている。発生した情報は、後でより詳細に記載される、サービスレベル取決めを満たすようリソースの割当を管理することを担う、マルチノードデータベースサーバ２２２内のさまざまな構成要素によってアクセス可能である。

パフォーマンスまたは作業負荷のレベルを示す特性または条件を評価するよう用いられ得るある特定のタイプのあるパフォーマンスメトリクスはここにおいてはパフォーマンス尺度と称される。パフォーマンス尺度は、たとえば、ＣＰＵ利用のトランザクション実行時間またはパーセントを示す。一般に、パフォーマンスのレベルを伴うサービスレベル取決めはパフォーマンス尺度に基づくしきい値および基準により定義され得る。

たとえば、トランザクションの実行時間はパフォーマンス尺度である。この尺度に基づくあるサービスレベル取決めは、トランザクションはサービスＦＩＮに対しては３００ミリ秒内で実行されなければならない、というものである。さらに別のパフォーマンス尺度はノードの百分率ＣＰＵ利用度である。この尺度に基づくバックエンドポリシーは、ノードは８０％以下の利用度を経験する、というものである。

パフォーマンスメトリクスは、クラスタのパフォーマンス、クラスタ、そのクラスタにおけるノード、またはある特定のデータベースインスタンスにおいて実行されるサービスのパフォーマンスを示し得る。あるサービスに特定のパフォーマンスメトリクスまたは尺度はここにおいてはサービスパフォーマンスメトリクスまたは尺度と称される。たとえば、サービスＦＩＮに対するあるサービスパフォーマンス尺度はサービスＦＩＮに対して実行されるトランザクションに対するトランザクション時間である。

ある実施例に従うと、サービスレベル取決めおよびバックエンドポリシーは以下に基づく。

サービスまたはデータベース濃度
サービスレベル取決めまたはバックエンドポリシーはある特定の使用に対して割当てられ得るリソースの数を制限し得る。そのような制約は濃度制約と称される。あるサービス濃度制約は、最小限および／または最大限の数のデータベースインスタンスがサービスのホストとなることを必要とし；あるデータベース濃度制約はあるデータベースに対する最小限および／または最大限の数のデータベースインスタンスが動作中であることを必要とする。濃度制約は、さらに、クラスタ内におけるノードの数も制限し得る。

サービスまたはデータ優先順位
あるサービスまたはデータベースは他のものよりも高い優先順位を有するものとして指定されてもよい。より高い優先順位のサービスまたはデータベースが優先されるのは、リソースを割当てるとき、特にリソースが不十分でサービスまたはデータベースの組のすべてのサービスレベル取決めが満たされないときである。優先順位情報をデータベースアドミニストレータによって供給してもよい。

Ｎ_cpu
ノードの百分率ＣＰＵ利用度。百分率ＣＰＵ利用度の計算は、ノード上にあるデータベースインスタンス上においてホスト対応されるサービスの百分率ＣＰＵ利用度を合計することによって行なわれてもよい。

Ｘ_cpu
ノードに対するしきい値ＣＰＵ利用度の形式におけるポリシー。説明のため、Ｘ_cpuはクラスタにおけるすべてのノードに対して一定である。しかしながら、それは、さまざまな要因、たとえばデータベースに対して動作しているデータベースインスタンスの数などに依存して可変であってもよい。

ＣＰＵ_aval
これはノード上における利用可能な未使用のＣＰＵ利用度であり、Ｘ_cpuとＮ_cpuとの間の差（つまりＸ_cpu−Ｎ_cpu）として定義される。

アベイラビリティ
アベイラビリティは、それが、ある特定の使用に対して利用可能であるはずの最小限の数のリソースであるという点において、濃度の下位分類である。たとえば、あるサービスアベイラビリティ要件は、あるサービスに対し少なくとも最小限の数のデータベースインスタンスがホストとなることを必要とする。

アベイラビリティはアベイラビリティモニタと称されるデーモン処理により監視される。アベイラビリティモニタ、たとえばアベイラビリティモニタ１９２などは、いつノードまたはデータベースインスタンスが非アベイラビリティ事象、たとえばシステムクラッシュなどのため利用不可能となるかを検出するデーモンである。ノードまたはデータベースインスタンスが利用不可能になったことを検出すると、アベイラビリティモニタはデータベースディレクタおよび／またはクラスタディレクタに対しその影響を受けたサービスまたはノードを知らせる。ディレクタは行動を開始してアベイラビリティ要件に対するコンプライアンスを達成する。たとえば、あるアベイラビリティ要件はＰＡＹが少なくとも２つのデータベースインスタンス上においてホスト対応されることを必要とする。アベイラビリティモニタ１９２は、インスタンス１２５がダウンしたことを検出し、データベースディレクタ１５２に知らせる。これに応答して、データベースディレクタ１５２はサービス拡張を起動してサービスＰＡＹを第２の動作しているデータベースインスタンス、つまりデータベースインスタンス１２３に拡張する。

ディレクタの階層
ディレクタの階層、たとえば「マルチノードシステムにおけるリソースの動的割当の階層的管理」（５０２７７−２３８２）などに記載されるようなものを用いて、クラスタファーム１０１内のリソースの割当を動的に調整してサービスレベル取決めを満たす。クラスタファーム１０１は、クラスタファーム１０１上においてデータベースサーバにより管理される各データベースに対するデータベースディレクタ、クラスタファーム１０１内における各クラスタに対するクラスタディレクタ、およびクラスタファーム１０１に対するファームディレクタを含む。

データベースディレクタ、たとえばデータベースディレクタ１５２および１６２などは、データベースのデータベースインスタンスがホストとなるサービス間においてデータベースのリソースの割当を動的に管理し調整する。データベースディレクタがこの責務を果たすべく用いる１つの手段は、「マルチノードシステムにおける増分的ランタイムセッション平衡化」（５０２７７−２４１１）に記載されるデータベースのデータベースインスタンス間における増分的ランタイムセッション平衡化を実行することである。増分的ランタイムセッション平衡化は、サービスのデータベースセッションを、サービスのホストとなっているデータベースインスタンス間で移動させる。データベースディレクタによって取られ得る別の手段はサービス拡張である。サービス拡張の下では、「マルチノードシステムにおけるパフォーマンスおよびアベイラビリティレベルを実施するためのサービス配置」（５０２７７−２４１２）に記載されるように、別のデータベースインスタンスをサービスのホストとなるように割当てる。

クラスタディレクタ、たとえばクラスタディレクタ１１２などは、データベース間におけるリソースの割当を調整する。クラスタディレクタがこの責務を果たすべく取る１つの手段は、ここにおいてさらに詳細に記載されるように、あるデータベースインスタンスを、あるデータベースのために、あるクラスタ内にあるある既存のノードに対して付加するかまたはそれから取除くことである。

ファームディレクタ、たとえばファームディレクタ１０２などは、クラスタ間におけるリソースの割当を管理し調整する。ファームディレクタがこの責務を果たすべく取る１つの手段は、ノードをクラスタに付加するかまたはそれから取除くことである。

ディレクタは、ここにおいてサービスレベル違反と称される、サービスレベル取決めの違反を検出する。たとえば、データベースディレクタ１５２は定期的な分析をパフォーマンスメトリクスに対して行ない、インスタンス１２５上におけるＦＩＮに対する平均トランザクション時間がこの尺度に対するサービスレベル取決めに違反することを判断するか、またはサービスＦＩＮに対するノード１２４上における百分率ＣＰＵ利用度がＣＰＵ利用度に対するポリシーに違反しているかどうかを判断する。

救済策の拡大によるサービスレベル取決めの違反の解消
ある実施例に従うと、データベースディレクタはそれが検出したサービスレベル違反の救済を、まずより問題が少なくコストのより小さいリソース割当に対する調整を行なった後でより大きな問題がありよりコストの大きいリソース割当に訴えることにより行なう。サービスのデータベースセッションを、サービスのホストとなっている、データベースのデータベースインスタンス間において移動させることは、一般に、サービスを別のデータベースインスタンスに拡張することよりもより問題およびコストが小さく；サービスを別のデータベースに拡張することは、一般には、データベースインスタンスを他のノードに供給することまたは他のノードをクラスタに付加することよりもより問題が少なくコストがより小さい。

図２は、サービスレベル違反を解消するべく用いられる救済策の拡大を管理すべく用いられてもよい手順を示す。この手順は、データベースディレクタにより、「ソース」データベースの「ソース」データベースインスタンスにおいてあるサービスに対するリソース警報を検出することに応答して開始される。あるリソース警報は、マルチノードコンピュータシステム内におけるリソース割当に対する注意を喚起する条件または事象の検出である。リソース警報は、特に、サービスレベル違反の検出を含む。たとえば、あるリソース警報は、ソースデータベースインスタンス１２５におけるサービスＦＩＮに対する平均トランザクション時間がこの尺度に対するサービスレベル取決めを超えることを検出することであり得る。

図２を参照してステップ２１０においてデータベースディレクタはまずランタイムセッション平衡化を試みるべきか否かを判断する。この判断は、セッション平衡化が実行され得るソースデータベースインスタンスにおいて候補サービスがあるかどうかを判断することによりなされる。セッション平衡化が実行されるべきであると判断されると、次いでステップ２１５においてセッション平衡化が、たとえば「マルチノードシステムにおける増分的ランタイムセッション平衡化」（５０２７７−２４１１）に記載されるように、実行される。

ステップ２０５において、リソース警報が持続しているかどうかの判断がなされる。手順の反復において呼出される救済策、たとえばステップ２１５におけるセッション平衡化などによってリソース警報の根本的な原因が解消されると、リソース警報はもはや持続し
なくともよい。この手順の実行は終了する。

しかしながら、リソース警報が持続する場合には、手順をさらに反復して別の救済策をとる。ステップ２０５を各反復の後に実行して、各反復においてとられた救済策がリソース警報を解消したか、または手順のさらなる反復が実行されるべきかを評価する。

ステップ２１０において、その判断が、ランタイムセッション平衡化が試みられるべきではないというものである場合には、手順は、ステップ２２０において、サービス拡張が試みられるべきかどうかを判断する。この判断は、「マルチノードシステムにおけるパフォーマンスおよびアベイラビリティレベルを実施するためのサービス配置」（５０２７７−２４１２）により詳細に説明されるように、ソースデータベースインスタンス上に拡張され得る候補サービスがあるかどうかを判断することにより行なわれる。その判断が、サービス拡張を実行すべきであるというものである場合には、ステップ２２５においてサービス拡張を実行し、手順はステップ２０５に戻る。

判断が、サービス拡張は実行され得ないというものである場合には、データベースディレクタは、リソース警報の解消をクラスタディレクタにまで拡大させてより高価な救済策、たとえば別のデータベースインスタンスをそのデータベースに対して割当て、必要である場合には、あるノードをそのクラスタに付加することなどを実現する。

ステップ２３０において、データベースディレクタは、そのデータベースディレクタに対しクラスタディレクタにより処理されている最中の未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ（インスタンス要求）要求があるかどうか判断する。あるＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求は別のノード上における別のデータベースインスタンスに対する要求である。ある未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求はたとえばクラスタディレクタにより現在処理されている最中のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求である。そのような処理は（後に詳細に記載されるように）データベースインスタンスに対してノードを見付けることまたはデータベースインスタンスをノードから取除いて別のデータベースインスタンスがそのノードに供給されることを含み得る。未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求がある場合には、ステップ２３５においてデータベースは待機し次いでステップ２０５に進む。リソース警報が持続する場合には、データベースディレクタは次の反復を実行する。新たなデータベースインスタンスが未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求の結果データベースに割当てられたかもしれない。前述の次の反復において、データベースディレクタはサービスをその新たに割当てられたデータベースインスタンスに対して拡張しリソース警報を軽減または救済してもよい。

ステップ２３０における判断が、データベースディレクタに対しクラスタディレクタにより処理されている最中の未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求がないというものである場合には、ステップ２４０においてデータベースディレクタは、別のデータベースインスタンスを割当てることがそのデータベースに対する最大濃度に違反するであろうか否かを判断する。データベースディレクタが、別のデータベースインスタンスを付加することがそのデータベースに対する最大濃度に違反するであろうと判断する場合には、実行はステップ２３５に進み、そこにおいて、データベースディレクタは、おそらく図２に示される手順のさらなる反復がおそらく実行されるよう進むまで待機する。

ステップ２４０において、データベースディレクタが、別のデータベースインスタンスを付加してもそのデータベースに対する最大濃度に違反しないであろうと判断する場合には、ステップ２４５においてデータベースディレクタは、リソース警報の解消の、クラスタディレクタへの拡大を、ＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求を送信することにより行なう。

手順におけるさまざまなステップを実行している一方、データベースディレクタはさまざまなアクションを非同期ジョブに委任し、次いでそのジョブにより実行されたさまざまなアクションの結果を待つ。たとえば、データベースディレクタは、サービスを拡張するよう（「マルチノードシステムにおけるパフォーマンスおよびアベイラビリティレベルを実施するためのサービス配置」（５０２７７−２４１２）参照）またはセッションを移動するよう（「マルチノードシステムにおける増分的ランタイムセッション平衡化」（５０２７７−２４１１）参照）それが発行した非同期ジョブの結果を待っていてもよい。加えて、データベースディレクタはクラスタディレクタに発行されるＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求の結果を待ってもよい。これらの場合において待機する間、データベースディレクタは実際にはアイドル状態ではなく、同時に他のリソース警報の処理を、図２に示される手順を実行することにより行なう。

別のサービスに対し別のリソース警報を処理する際、データベースディレクタはステップ２３０において未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求が未決であることを判断してもよい。未決のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求は先の反復において別のリソース警報に対しデータベースディレクタにより要求されていてもよい。

データベースインスタンスおよびノードのデータベースに対する割当の開始
図３は、「要求側データベースディレクタ」によりなされるＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求を処理することに応答してノードをデータベースに割当てることを開始するべくクラスタディレクタにより辿られる手順を示す。

図３を参照して、ステップ３０５において、クラスタディレクタは、そのクラスタディレクタが担うクラスタ内において、インスタンスが供給されてもよい自由なノードがあるかどうかを判断する。ある実施例においては、ノードが自由であるのは、データベースインスタンスがそのノードになく、クラスタディレクタがそのノードを別のデータベースベースインスタンスに割当てる（たとえば、データベースに対して発生されるＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求に応答してノードを割当てる）処理にないか、またはノードがある他の目的のためにクラスタウェアによって予約されている場合である。クラスタディレクタはクラスタウェアのＡＰＩを呼出して、何のノードがクラスタにあるか、およびデータベースインスタンスがそれらにあるかまたはなんらかの他の目的のためクラスタウェアにより予約されているかを判断してもよい。

ステップ３０５においてクラスタディレクタが、あるノードが自由であると判断した場合には、ステップ３１０においてクラスタディレクタはクラスタウェアのＡＰＩ関数を呼出してあるデータベースインスタンスをそのデータベースに対しその自由なノードにおいて開始してもよい。次に、クラスタディレクタはあるメッセージを要求側データベースディレクタに送って、そのデータベースディレクタに対し、そのデータベースに対するあるデータベースインスタンスがそのノードに供給された旨を知らせる。

ステップ３０５において、クラスタディレクタによりあるノードが自由であると判断される場合には、クラスタディレクタはクラスタ内において別のデータベース（「データベース犠牲」）に割当てられるノードを得ようと試みる。

ステップ３１５において、クラスタディレクタはデータベース犠牲候補を探し出す。この発明のある実施例に従うと、クラスタディレクタは、犠牲候補リストと称される、クラスタ内においてネスト化されたデータベースの、順序付けられたリストを発生させるが、それはデータベース優先順位に従って順序付けられる。より低い優先順位を伴うデータベースはリストの最初にあり、より高い優先順位を伴うデータベースはリストの終わりにあ
る。データベース犠牲候補を探し出すことはある関数を呼出すことにより実行され得る。この関数は１つ以上の候補犠牲を、その関数において実現されるポリシーに従って返す。関数はデータベース犠牲候補のリストを決定することに対するさまざまな方策およびポリシーを実現し得る。さらに、そのようなある関数はユーザにより供給され得るかもしれず、つまり、データベースサーバのネイティブなソフトウェアの一部ではないが、データベース候補犠牲のリストを決定するという目的のため呼出されるべくあるデータベースサーバに登録される関数であるかもしれない。

ステップ３２０において、クラスタディレクタはデータベースインスタンスをクエースするようボランティアを求めて犠牲リストのデータベースディレクタに懇請し、ボランティアを、ボランティア志願した１つ以上のデータベースディレクタ間から選択する。

クエースという語はサーバのクライアントの組によるそのサーバの使用を不能化することを指す。データベースのデータベースインスタンスをクエースすることは、データベースにアクセスするようにクライアントによるデータベースインスタンスの使用を不能化することを指す。サービスをクエースすることは、そのサービスに対するデータベースインスタンスの使用を不能化することを指す。より詳細に記載されるように、データベースインスタンスをクエースすることは、データベースインスタンスへの新たな接続を妨げ、クライアントに対し実行されている最中の作業を別のデータベースインスタンスに対したとえばセッション移動を介して転送することを必要とし得る。

ステップ３２０はさまざまな態様で達成されてもよい。
クラスタディレクタは犠牲候補リストにおける候補のデータベースディレクタのポーリングを１つずつ順に行なってもよい。ある候補のあるデータベースディレクタをポーリングするために、クラスタディレクタはＱＵＩＥＳＣＥ−ＶＯＬＵＮＴＥＥＲ（クエース−ボランティア）要求をデータベースディレクタに送信し、データベースディレクタはそれに応答して、データベースディレクタがクエースするようボランティア志願するかどうかを明記するメッセージを送信する。ポーリングされた候補がボランティア志願する場合には、クラスタディレクタは候補を犠牲として選択する。

代替的に、クラスタディレクタはクエース要求を犠牲候補リストにある候補のすべてのデータベースディレクタに対して同報通信する。次いでクラスタディレクタは、犠牲データベースの選択を、ディレクタがボランティア志願したもの、つまりデータベースディレクタがボランティア志願することを明記するメッセージを送信したものの中から行なう。

ボランティア志願するデータベースディレクタにより送信されるメッセージは、後でより詳細に説明されるように、クエースコストを示すデータを含んでもよい。クエースコストとはデータベースインスタンスをクエースするべく必要とされる作業の量である。

犠牲データベースの選択は、データベース優先順位、クエースコスト、またはこれらの要素の組合せに基づき得る。たとえば、クラスタディレクタは最も低いクエースコストまたは最も低いデータベース優先順位に関連付けられるデータベースを選択し得る。データベース優先順位に基づいて選択し、複数のデータベースが最も低い優先順位にを有する場合には、クラスタディレクタは複数のデータベースの中から最も低いクエースコストに関連付けられるものを選択する。

ステップ３２５において、犠牲が選択されたかどうかの判断がなされる。犠牲が選択されなかった場合には、ステップ３３０において、犠牲データベースの選択を、候補犠牲リストから、少なくとも２つのデータベースインスタンスを有する最も低い優先順位のデータベースを選ぶことにより行なう。実行はステップ３３５に進む。

ステップ３３５において、クラスタディレクタは非同期ジョブを発行する。このジョブは犠牲のデータベースディレクタにＱＵＩＥＳＣＥ−ＩＮＩＴＩＡＴＥ（クエース−開始）要求を送信して、データベースディレクタがデータベースインスタンスをクエースすることを要求する。

図３のステップの実行が終了する。
次いで、クラスタディレクタはＩＤＬＥ−ＩＮＳＴＡＮＣＥ（アイドル−インスタンス）メッセージを犠牲のデータベースディレクタから受取り、それに対してクラスタディレクタは応答してそのクエースされたインスタンスを遮断する。一方、クラスタディレクタは、他のＮＥＥＤ−ＩＮＳＴＡＮＣＥ要求を含む他の要求を処理する。

ＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージへの応答
図４はこの発明のある実施例に従ってＩＤＬＥ−ＩＮＳＴＡＮＣＥ要求に応答すべくクラスタディレクタにより辿られる手順である。ステップ４０５において、クラスタディレクタはＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージを受取る。このＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージは犠牲のデータベースディレクタによりクエースされる「犠牲データベースインスタンス」およびその犠牲データベースインスタンスがホスト対応されるノードのアイデンティティを含む。

ステップ４１０において、クラスタディレクタはＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージの妥当性を検証し、つまり、犠牲データベースが動作中であり遮断され得ることを検証する。犠牲データベースディレクタが犠牲データベースインスタンスをクエースした後、犠牲データベースインスタンスが遮断され（つまりそれ以上は動作しないようにされ）、別のデータベースインスタンスが起動されてたとえば高いアベイラビリティ事象に応答したという可能性がある。この場合、クラスタディレクタは他のデータベースインスタンスを遮断しはしない。犠牲データベースインスタンスがクエースしたノードにおいて動作しているデータベースインスタンスのアイデンティティを判断するため、クラスタディレクタはクラスタウェアのＡＰＩを呼出す。そのアイデンティティが犠牲データベースインスタンスのそれのアイデンティティと同じである場合には、ＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージは有効であり、実行はステップ４１５に進む。そうでない場合にはステップの実行は終了する。

ステップ４１５において、クラスタディレクタは犠牲データベースインスタンスを遮断する。ステップ４１８において、クラスタディレクタは新たなノードを待つ最も高い優先順位のデータベースディレクタ（つまりディレクタが新たなノードを待っている最も高い優先順位のデータベース）を判断する。ステップ４２０において、クラスタディレクタは要求されたデータベースインスタンスを最も高い優先順位の、待機中のデータベースに対して開始するが、それは元々ＮＥＥＤ−ＩＮＳＴＡＮＣＥメッセージをクラスタディレクタに対して提出したデータベースとは異なっていてもよい。この手順により、後で到着するより高い優先順位の要求は、インスタンスのクエースを起動したかもしれないより低い優先順位の要求に優先し得る。ステップ４１５および４２０の両方が、クラスタウェアのＡＰＩを呼出すことにより実行される。

ＱＵＩＥＳＣＥ−ＶＯＬＵＮＴＥＥＲ要求に対する応答
図５は、データベースディレクタがそのデータベースに対しデータベースインスタンスをクエースするようボランティア志願するかどうかを判断するための手順である。この手順は、「要求側クラスタディレクタ」により送られるＱＵＩＥＳＣＥ−ＶＯＬＵＮＴＥＥＲ要求に応答して実行される。

図５を参照して、ステップ５０５において、データベースディレクタは、データベースに対する最小限のデータベース濃度制約が、もう１つ少ないデータベースインスタンスをそのデータベースに対して割当てることにより違反されるであろうかどうかを判断する。データベースディレクタは別のデータベースインスタンスをクエースする処理にあるかもしれないという可能性がある。そのような場合には、データベースディレクタは、最小限のデータベース濃度制約が、もう１つ少ないデータベースインスタンスに、クエースされている最中という処理にあるかもしれない任意のデータベースインスタンスを加えたものを割当てることにより違反されるであろうかどうかを判断する。データベースディレクタが、最小限のデータベース濃度制約が違反されるであろうと判断する場合には、実行はステップ５３０に進み、そこにおいて、データベースディレクタは、要求側クラスタディレクタに対し、データベースディレクタはデータベースインスタンスをクエースするようボランティア志願してはいない旨を明記するメッセージを送る。そうでない場合、データベースディレクタが、最小限のデータベース濃度制約が違反されないであろうと判断する場合には、実行はステップ５１０に進む。

ステップ５１０において、データベースディレクタは、データベースにおいてホスト対応されるサービスのうち任意のサービスの最小限のサービス濃度がもう１つ少ないデータベースインスタンスをデータベースに対して割当てることにより違反されるであろかどうかを判断する。データベースにおいてホスト対応されるサービスのうち任意のサービスのサービス濃度制約に違反することなく存在し得るデータベースのインスタンスの最小限の濃度は、データベースにおいてホスト対応されるサービスのうち任意のサービスの最も大きい最小限のサービス濃度である。たとえば、データベース１５０においてホスト対応されるデータベースのうち、サービスＦＩＮおよびＰＡＹに対する最小限の濃度制約はそれぞれ１および２である。任意のホスト対応されるサービスの最も大きい最小限の濃度制約はしたがって２である。３つのデータベースインスタンスがデータベース１５０に対して存在する。あるデータベースインスタンスをデータベース１５０に対して取除くと残りは２となり、したがってどのような最小限のサービス濃度も違反されず、実行はステップ５１５に進む。一方、サービスＰＡＹに対する最小限の濃度制約が３である場合、サービスのうち任意のサービスの最も大きい最小限のサービス濃度は３であり、データベースインスタンスをデータベース１５０に対して取除くことはデータベース１５０においてホスト対応される少なくとも１つのサービスの最小限のサービス濃度に違反し、実行はステップ５３０に進み、そこにおいてデータベースディレクタは、要求側クラスタディレクタに対し、データベースディレクタはクエースすべくボランティア志願してはいない旨を明記するメッセージを送る。

ステップ５１５において、全体の利用可能なＣＰＵ利用度が、データベースのホストとなるノード、つまりデータベースのデータベースインスタンスのホストとなるノードに対して計算される。ある実施例に従うと、これはデータベースのホストとなるノードの各々のＣＰＵ_avalを合計することにより判断される。全体の利用可能なＣＰＵ利用度は、ノードの組の現在の作業負荷をもう１つ少ないノードで対処するようデータベースのホストとなるそれらノードの組の能力を示すものである。たとえば、ＣＰＵ_avalはノード１２２、１２４、１２６に対しては８０％より大きい。全体の利用可能なＣＰＵ利用度がＸ_cpuより大きい場合には、作業負荷に、もう１つ少ないノードで、しきい値に違反することなく対処するのに十分な全体の利用可能なＣＰＵ利用度がある。

ステップ５２０において、利用可能な全体の利用可能なＣＰＵ利用度が十分にあるかどうかが判断される。全体の利用可能なＣＰＵ利用度がＸ_cpuにＸ_cpuのファクタを加えたものより大きい場合には、利用可能な全体の利用可能なＣＰＵ利用度が十分にある。

計算される全体の利用可能なＣＰＵ利用度は、現在の作業負荷に、もう１つ少ないノー
ドで、ＣＰＵ利用度に対するサービスレベル取決めおよびポリシーに違反することなく対処するようデータベースのホストとなるノードの能力の推定に過ぎない。この推定は正確ではないかもしれないため、ファクタをＸ_cpuに加算することにより、残りのノードに負荷をかけ過ぎることを回避する。ファクタはたとえばＸ_cpuの５％であり得る。

ステップ５２０において、利用可能な全体の利用可能なＣＰＵ利用度が十分ではないと判断される場合には、実行はステップ５３０に進み、そこにおいて、データベースディレクタはそれがボランティア志願していない旨を明記するメッセージをおくる。そうでない場合には、ステップ５２５において、データベースディレクタはそれがボランティア志願していることを認めるメッセージを送る。

データベースディレクタがボランティア志願していることを認めるメッセージは、さらに、データベースインスタンスをデータベースに対してクエースすることのコストを示すデータを含み得る。そのようなデータは、任意のデータベースインスタンスにおけるデータベースセッションの最小限の数、データベースのホストとなる任意のノードの最小限の百分率ＣＰＵ利用度、および／またはデータベースに対する全体の利用可能なＣＰＵ利用度を含む。一般に、データベースインスタンスにおけるより大きな数のデータベースセッションは、インスタンスをクエースする、より大きなコストを示す。より高い全体の利用可能なＣＰＵ利用度は、インスタンスをクエースする、より低いコストを示す。ノードにおけるより低いＣＰＵ利用度は、データベースインスタンスをクエースする、より低いコストを示す。

図５の手順の実行が終了する。
ＱＵＩＥＳＣＥ−ＩＮＩＴＩＡＴＥ要求の処理
図６は、データベースのデータベースインスタンス間からあるデータベースインスタンスを選択しクエースするようそのデータベースに対しデータベースディレクタにより実行される手順を示す。この手順は、データベースインスタンスをクエースするようクラスタディレクタによって送られるＱＵＩＥＳＣＥ−ＩＮＩＴＩＡＴＥ要求に応答してデータベースディレクタにより実行される。

図６を参照して、ステップ６０５において、データベースディレクタはデータベースインスタンスを候補犠牲として選択し、その選択を、百分率ＣＰＵ利用度に基づく順序においてなす。より低いＣＰＵ利用度を伴うデータベースインスタンスが、より高いＣＰＵ利用度を伴うものの前に選択される。

ステップ６１０において、データベースディレクタはＢＬＯＣＫ−ＩＮＳＴＡＮＣＥ（ブロック−インスタンス）メッセージを候補犠牲のリスナに送る。このメッセージは、リスナに対し、データベース接続要求を選択された候補に向けることを停止するよう命ずる。したがって、リスナは任意のサービスに対するデータベース接続要求をそのサービスのホストとなっている別のデータベースインスタンスに向ける。

ステップ６１５において、データベースディレクタはデータベースセッションが移動可能であるかどうか、つまりデータベースセッションが別のデータベースインスタンスに移動され得るかどうかを判断する。たとえば、データベースセッションは、セッション状態に開いているファイルのファイル記述子が含まれる場合には移動可能ではないかもしれない。ファイル記述子は、あるセッションに対し、ソースインスタンスにおいて有効であるに過ぎず、宛先インスタンスにおいてはそうではない情報を含む。データベースセッションが移動され得るかどうかを判断する他の方法は「サーバにわたっての透明なセッション移動」（５０２７７−２３８３）に記載されている。セッションが移動可能でない場合には、ＵＮＢＬＯＣＫ−ＩＮＳＴＡＮＣＥ（ブロック解除−インスタンス）メッセージがリ
スナに対しステップ６３０において送られて、リスナに対して、それは接続要求を候補犠牲に向けてもよい旨を知らせる。別の候補犠牲がステップ６０５において選択される。

セッションが移動され得る場合、実行はステップ６２０に進む。この段階において、候補犠牲は、犠牲となる。

ステップ６２０において、セッションは犠牲からデータベースの他のデータベースインスタンスに移動される。セッションの移動は「マルチノードシステムにおける増分的ランタイムセッション平衡化」（５０２７７−２４１１）に記載される態様と同様の態様で行なわれてもよい。ここに記載されるように、セッションは、他のデータベースインスタンスに、サービスレベル違反により引起されるリソース警報に応答して移動される。あるサービスに対するデータベースインスタンス上のセッションは、リソース警報がもはや持続しなくなるまで、他のデータベースインスタンスに移動される。

同様の手順をステップ６２０に対して用いてもよい。データベースセッションは犠牲以外のデータベースインスタンスに対して移動される。リソース警報は、１つのサービスに対して適用されるのではなく、犠牲上のすべてのサービスに対して適用され、すべてのデータベースセッションが、その犠牲がホストとなるすべてのサービスに対して、その犠牲から移動されるまで、またはデータベースディレクタがデータベースセッションを移動しようとするその試みをアボートすると決めるまで、持続する。後者の場合、実行はステップ６３０に進み、そこにおいて、データベースディレクタはＮＢＬＯＣＫ−ＩＮＳＴＡＮＣＥメッセージをリスナに送る。図６の手順が再び行なわれるが、ただし、犠牲は再び犠牲としては選択されない。最後に、犠牲からのセッション移動が実行されている最中である間、セッションをその犠牲に移動しようとするすべての試みは妨げられる。

ステップ６２５において、データベースディレクタはクラスタディレクタにＩＤＬＥ−ＩＮＳＴＡＮＣＥメッセージを送る。

犠牲データベースのすべてのインスタンスは移動不可能なデータベースセッションを有することが可能である。この場合、データベースディレクタはあるインスタンスをある犠牲として選択し、移動可能なデータベースセッションを移動する。移動不可能なデータベースセッションに関しては、データベースディレクタはそれらが終了するかもしくは移動可能となり移動されるまで待機するか、またはそれらは新たなノードが必要とされるサービスに対しアドミニストレータおよび／または優先順位により明記されるポリシーに基づいて強制終了されてもよい。

代替的実施例の例
この発明のある実施例を、データベースサービスおよびデータベースサービスの下位分類間においてマルチノードシステムのリソースを動的に割当てることにより説明した。しかしながら、この発明はそのようには限定されるものではない。

たとえば、この発明のある実施例を用いて、アプリケーションサーバにより与えられるサービス間においてそのアプリケーションサーバのホストとなるマルチノードシステムのコンピュータリソースを割当ててもよい。あるアプリケーションサーバは、たとえば、アプリケーションサーバがクライアントとデータベースサーバとの間にある３層構造のアーキテクチャの一部である。アプリケーションサーバは主にアプリケーションコードを記憶し、それに対するアクセスを与え、およびそれを実行することのために用いられ、一方データベースサーバは主にそのアプリケーションサーバに対してデータベースを記憶しそれに対してアクセスを与えることのために用いられる。アプリケーションサーバはデータに対する要求をデータベースサーバに送信する。要求は、アプリケーションサーバ上に記憶
されるアプリケーションコードを実行することに応答して、そのアプリケーションサーバにより発生されてもよい。あるアプリケーションサーバの一例はオラクル９ｉアプリケーションサーバ（Oracle 9i Application Server）またはオラクル１０ｇアプリケーションサーバ（Oracle 10g Application Server）である。ここに記載されるマルチノードサーバの例と同様に、あるアプリケーションサーバを、複数のノードにおいて実行する複数のサーバインスタンスとして分散してもよく、サーバインスタンスはそれらサーバインスタンス間において移動されてもよい複数のセッションのホストとなってもよい。

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

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

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

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

ここで用いられる「コンピュータ読取可能媒体」という語は命令をプロセッサ７０４に実行のため与えることに与る任意の媒体を指す。そのような媒体は多くの形態を取り得、不揮発性媒体、揮発性媒体、および伝送媒体を含むがそれらに限定されるものではない。不揮発性媒体は、たとえば、光ディスクまたは磁気ディスク、たとえば記憶装置７１０などを含む。揮発性媒体は動的メモリ、たとえばメインメモリ７０６などを含む。伝送媒体は同軸ケーブル、銅線および光ファイバを含み、バス７０２を含むワイヤを含む。伝送媒体は、さらに、音波または光波の形態をとり得、たとえば無線波および赤外線データ通信中に発生されるものであり得る。

コンピュータ読取可能媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープもしくは任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、孔のパターンを伴う他の任意の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、他の任意のメモリチップもしくはカートリッジ、以下に記載される搬送波、またはコンピュータによって読取られ得る他の任意の媒体を含む。

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

コンピュータシステム７００は、さらに、バス７０２に結合される通信インターフェイス７１８を含む。通信インターフェイス７１８はローカルネットワーク７２２に接続されるネットワークリンク７２２に結合する２方向データ通信を与える。たとえば、通信インターフェイス７１８は、データ通信接続を対応するタイプの電話回線に与えるよう統合されたサービスデジタルネットワーク（ＩＳＤＮ）カードまたはモデムであってもよい。別の例として、通信インターフェイス７１８はデータ通信接続を互換可能なＬＡＮに与えるようローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクをさらに実現してもよい。任意のそのような実現例において、通信インターフェイス７１８はさまざまなタイプの情報を表現するデジタルデータストリームを搬送する電気信号、電磁信号または光信号を送受する。

ネットワークリンク７２０は典型的にはデータ通信を１つ以上のネットワークを介して他のデータ装置に与える。たとえば、ネットワークリンク７２０は接続をローカルネットワーク７２２を介してホストコンピュータ７２４またはインターネットサービスプロバイダ（ＩＳＰ）７２６によって操作されるデータ機器に与えてもよい。ＩＳＰ７２６は、次いで、データ通信サービスを、今では一般に「インターネット」７２８と称されるワールドワイドパケットデータ通信ネットワークを介して与える。ローカルネットワーク７２２およびインターネット７２８は両方ともデジタルデータストリームを搬送する電気信号、電磁信号または光信号を用いる。さまざまなネットワークを介する信号、ならびにコンピュータシステム７００との間でデジタルデータを搬送する、ネットワークリンク７２０上および通信インターフェイス７１８を介する信号は、情報を移送する搬送波の例示的形態である。

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

受取られたコードは、それが受取られる中、プロセッサ７２４によって実行されてもよく、および／または記憶装置７１０もしくは他の不揮発性ストレージに後の実行のため記憶されてもよい。この態様で、コンピュータシステム７００はアプリケーションコードを搬送波の形式で得てもよい。

前述の記載において、この発明の実施例の記載が、実施例ごとに変動し得る数多くの具体的な詳細を参照しながらなされてきた。斯くして、何がこの発明であるか、および何が出願人によりこの発明であるとして意図されるかを唯一かつ排他的に示すものはこの出願から出される、特定の形式におけるクレームの組であり、そこにおいてはそのようなクレームは任意の後の訂正を含んで出されるものである。そのようなクレームに含まれる用語に対しここで明示的に述べられる定義はすべてクレームにおいて用いられるとおりのそのような用語の意味を支配する。したがって、クレームにおいて明示的には記載されないどのような限定、要素、特性、特徴、利点または属性も、そのようなクレームの範囲をどのような態様においても限定するものではない。明細書およびクレームは、したがって、例示的な意味において見なされるべきであり、限定的な意味において見なされるべきではない。

この発明のある実施例を実現してよいマルチノードコンピュータシステムを示すブロック図である。 サービスレベル取決めの違反を解消するよう用いられる救済策の拡大を管理する手順を示すフローチャートである。 この発明のある実施例に従ってデータベースに対し別のデータベースインスタンスを得るよう要求に応答するための手順を示すフローチャートである。 この発明のある実施例に従ってノード上において別のデータベースインスタンスを遮断し取上げるための手順を示すフローチャートである。 この発明のある実施例に従ってクエースすることに対しデータベースインスタンスをボランティア志願するか否かを判断するための手順を示すフローチャートである。 この発明のある実施例に従ってデータベースインスタンスをクエースすることのために用いられる手順を示すフローチャートである。 この発明のある実施例において用いられてもよいコンピュータシステムのブロック図である。

Claims (16)

1. 複数ノードシステムにおいてリソースを管理するための方法であって、前記複数ノードシステムの各ノードは、少なくとも前記複数ノードシステムの他のノードと相互に接続された計算要素であり、
   前記複数ノードシステムのうちの一つのノードが、マルチノードサーバにおけるサービスレベル取決めの違反を検出するステップを含み、前記マルチノードサーバは第１の組のノードで動作するサーバインスタンスの組を含み、サーバは、ノードで動作する少なくとも１つのプロセスによって実行される統合されたソフトウェア構成要素を含み、前記方法はさらに；
   前記違反が検出されると、前記複数ノードシステムのうちの前記一つのノードが、前記マルチノードサーバの別のサーバインスタンスを動作させる、前記第１の組のノードのメンバーではないノードを用いて、前記違反を解消するかどうかを判断するステップと；
   前記第１の組のノードのメンバーではないノードを用いることによって前記違反が解消されると判断されると、前記複数ノードシステムのうちの前記一つのノードが、あるステップを実行することにより前記違反を解消するよう試みるステップとを含み、前記あるステップは：
   前記複数ノードシステムのうちの前記一つのノードが、前記マルチノードサーバの前記別のサーバインスタンスとしての第２のサーバインスタンスを動作させるべき第２のノードを見つけることを含み、第２のノードが見つけられた時に、第３のサーバインスタンスは、前記第２のノードで動作しており、前記あるステップはさらに；
   前記複数ノードシステムのうちの前記一つのノードは、前記第３のサーバインスタンス上の１つ以上のクライアントに対して確立される少なくとも１つのセッションを、前記複数ノードシステム上において動作する第１のサーバインスタンスに移動させること；および
   前記複数ノードシステムのうちの前記一つのノードが前記第２のノードをリブートすることなく、前記第２のノード上において前記マルチノードサーバの前記第２のサーバインスタンスを起動することを含む、方法。
2. 前記違反を解消するよう試みるステップは、前記複数ノードシステムのうちの前記一つのノードが前記第２のサーバインスタンスを起動する前に前記第３のサーバインスタンスを遮断することをさらに含む、請求項１に記載の方法。
3. 前記第２のノードを見つけることはさらに：
   前記第１の組のノードとは異なる別の組のノードがホストとなる別のマルチノードサーバに対応する候補の組を発生させること；および
   ノードの割当解除を行なう前記候補の組から犠牲を選択することを含む、請求項１に記載の方法。
4. 前記第２のノードを見つけることは、ノードにおけるサーバインスタンスの使用を不可能にする要求を、前記候補の組のうちのある候補に対応するマルチノードサーバに送信することを含み、
   犠牲を選択することは、複数のマルチノードサーバのうちのある候補から犠牲を選択することを含み、前記犠牲は、自発的に不可能にするメッセージを送信することによって、前記要求に応答する、請求項３に記載の方法。
5. 要求を前記マルチノードサーバに送信することは、前記要求を候補の組に同報通信することを含む、請求項４に記載の方法。
6. 複数のマルチノードサーバのうちのある候補から犠牲を選択することは、犠牲を１つ以上の要素に基づいて選択することを含み、前記１つ以上の要素は：
   ユーザにより供給され、前記複数のマルチノードサーバのうちのある候補の優先順位を前記複数のマルチノードサーバの他の候補に対して示す優先順位データ；および
   ノードにおいてサーバインスタンスの使用を不可能にすることに関連付けられるコストのうちの少なくとも１つを含む、請求項４に記載の方法。
7. 前記違反を解消しようと試みるステップは：
   要求を第２のマルチノードサーバに送信してサーバインスタンスに遮断に備えるようにすること；および
   第２のマルチノードサーバから、あるサーバインスタンスが遮断の準備ができていることを示すメッセージを受取ることを含む、請求項２に記載の方法。
8. サーバインスタンスが遮断の準備ができていることを示すメッセージは、第２のサーバインスタンスおよびノードを識別するデータをさらに含む、請求項７に記載の方法。
9. 複数ノードシステムにおいてリソースを管理するための方法を実現するためのプログラムであって、前記プログラムは、前記複数ノードシステムのうちの一つのノードのプロセッサに、
   マルチノードサーバにおけるサービスレベル取決めの違反を検出するステップを実行させ、前記マルチノードサーバは第１の組のノードで動作するサーバインスタンスの組を含み、サーバは、ノードで動作する少なくとも１つのプロセスによって実行される統合されたソフトウェア構成要素を含み、
   前記違反が検出されると、前記マルチノードサーバの別のサーバインスタンスを動作させる前記第１の組のノードのメンバーではないノードを用いて前記違反を解消するかどうかを判断するステップと；
   前記第１の組のノードのメンバーではないノードを用いることによって前記違反が解消されると判断されると、あるステップを実行することにより前記違反を解消するよう試みるステップとを実行させ、前記あるステップは：
   前記複数ノードシステムが、前記マルチノードサーバの第２のサーバインスタンスを動作させるべき第２のノードを見つけることを含み、第２のノードが見つけられた時に、第３のサーバインスタンスは、前記第２のノードで動作しており、前記あるステップはさらに；
   前記複数ノードシステムは、前記第３のサーバインスタンス上の１つ以上のクライアントに対して確立される少なくとも１つのセッションを、前記複数ノードシステム上において動作する第１のサーバインスタンスに移動させること；および
   前記複数ノードシステムが前記第２のノードをリブートすることなく、前記第２のノード上において前記マルチノードサーバの前記第２のサーバインスタンスを起動することを含む、プログラム。
10. 前記違反を解消するよう試みるステップは、前記複数ノードシステムが前記第２のサーバインスタンスを起動する前に前記第３のサーバインスタンスを遮断することをさらに含む、請求項９に記載のプログラム。
11. 前記第２のノードを見つけることはさらに：
    前記第１の組のノードとは異なる別の組のノードがホストとなる別のマルチノードサーバに対応する候補の組を発生させること；および
    ノードの割当解除を行なう前記候補の組から犠牲を選択することを含む、請求項９に記載のプログラム。
12. 第２のノードを見つけることは、前記候補の組のうちのある候補に対応するマルチノードサーバに、ノードのサーバインスタンスの使用を不可能にする要求を送信することを含み、
    犠牲を選択することは、複数のマルチノードサーバのうちのある候補から犠牲を選択することを含み、前記犠牲は、自発的に使用を不可能にするメッセージを送信することによって、前記要求に応答する、請求項１１に記載のプログラム。
13. 要求をマルチノードサーバに送信することは、前記要求を候補の組に同報通信することを含む、請求項１２に記載のプログラム。
14. 複数のマルチノードサーバのうちのある候補から犠牲を選択することは、犠牲を１つ以上の要素に基づいて選択することを含み、前記１つ以上の要素は：
    ユーザにより供給され、前記複数のマルチノードサーバのうちのある候補の優先順位を前記複数のマルチノードサーバの他の候補に対して示す優先順位データ；および
    ノードにおいてサーバインスタンスを停止することに関連付けられるコストのうちの少なくとも１つを含む、請求項１２に記載のプログラム。
15. 前記違反を解消しようと試みるステップは：
    要求を第２のマルチノードサーバに送信してサーバインスタンスに遮断に備えるようにすること；および
    第２のマルチノードサーバから、あるサーバインスタンスが遮断の準備ができていることを示すメッセージを受取ることを含む、請求項１０に記載のプログラム。
16. サーバインスタンスが遮断の準備ができていることを示すメッセージは、第２のサーバインスタンスおよびノードを識別するデータをさらに含む、請求項１５に記載のプログラム。

Images