(57)【要約】【課題】情報技術インフラストラクチャを動的にプロビジョニングする方法を提供する。【解決手段】プロビジョニング資源および管理資源が資源全体をプールした中から引き出される。リクエストされたオンデマンド管理機能を確実に実行するために管理資源および被管理資源がネットワーク上で動的に関連する。管理され、プロビジョニングされるデバイス相互間のネットワークを管理システムが制御するので、資源相互をリンクしても最少量のネットワーク・オーバーヘッドしか引き起こさない。プロビジョニング資源はそれ自体動的に構築され、被管理資源と自動的に関連するので、管理のオーバーヘッドが顕著に減少する。【選択図】図２
2008004092.tif 000002
【特許請求の範囲】
【請求項１】
オンデマンド・データ処理サービスを提供する方法であって、
データ処理システム構成を求めるオンデマンド・プロビジョニング・リクエストを受取る中央管理資源を提供するステップと、
グループ単位で配設された複数のプロビジョニング可能なデータ処理システム資源を提供するステップと、
前記中央管理資源に応答し、前記プロビジョニング可能なデータ処理システム資源を複数のオンデマンド・リクエストに個別にまたは前記グループ単位で動的に割り当てることができる少なくとも１個のプロビジョニング・サーバーを提供するステップと
を含む方法。
【請求項２】
前記複数のプロビジョニング可能なデータ処理システム資源が管理サーバーを含む請求項１に記載の方法。
【請求項３】
前記オンデマンド・サービスがネットワーク・サービス・プロトコルを介して提供される、請求項１に記載の方法。
【請求項４】
前記プロトコルがシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）である、請求項３に記載の方法。
【請求項５】
前記オンデマンド・サービスが事前予約機能を含む、請求項１記載の方法。
【請求項６】
前記オンデマンド・サービスが事前スケジューリング機能を含む、請求項１に記載の方法。
【請求項７】
追加の資源がネットワーク・サービス・プロトコルを介して定義される、請求項１に記載の方法。
【請求項８】
前記プロビジョニング・サーバーが複数個ある、請求項１に記載の方法。
【請求項９】
前記プロビジョニング・サーバーがオンデマンド・リクエストのための資源としても利用できる、請求項８に記載の方法。
【請求項１０】
前記プロビジョニング・データ処理システム資源が保守モードにあると識別される、請求項１に記載の方法。
【請求項１１】
前記プロビジョニング可能なデータ処理システム資源が、プロビジョニング、管理、または管理される資源として使用される、請求項１に記載の方法。
【請求項１２】
前記オンデマンド・サービスがリモート立ち上げ機能を含む、請求項１に記載の方法。
【請求項１３】
オンデマンド・サービスを提供するためのデータ処理システムであって、
データ処理システム構成を求めるオンデマンド・プロビジョニング・リクエストを受取る中央管理資源と、
複数の未使用の資源と、
プロビジョニング資源および他の管理資源を含む少なくとも１個の管理資源と、
複数個の管理される資源と、
前期中央管理資源が、前記管理される資源、前記管理資源、および前記他の管理資源に前記未使用の資源を動的に割り当てることができる少なくとも１個のプロビジョニング・サーバーと
を含むデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概略、コンピュータ・ネットワーク・ベースのクライアント・サーバー・アクティビティに関し、特にクラスタ化された環境ないしグリッド環境において資源（リソース）をプロビジョニングするための方法に関する。
【背景技術】
【０００２】
オンデマンドの必要性が生じたために、情報技術（ＩＴ）組織(organizations)は、増加しつつある予算意識の心配事により設定されるコストの限界内で組織への資源（リソース）のプロビジョニングに取り組みつつある。データ処理動作のオンデマンド・モードは必要となった際にユーザーに資源を約束する。ユーザーは資源がタイミングよく利用できるようになることを期待し、またその資源上の情報が安全であることを期待する。ユーザーが特定のタスクに専用の資源を益々要求するようになってくる環境では、小さな配備窓の中でのいろいろなユーザー・コミュニティのための複数の資源の管理が一層難しくなってくる。
【０００３】
多くのＩＴ組織は今も手作業により、時分というより週日で測れるような時間消費プロセスで資源を組んでいる。もっと洗練された組織は自動的に「マシンを構築する(build machines)」ツールに依存し、それが時間の単位で使用できるようにしているが、これでさえ難しい。何故ならその需要が更に増加してゆく時間の窓を駆り立てるからである。ここで用いられるように、「マシンを構築する」ということは、クライアントのオンデマンド・リクエストに合致するように使用される環境のマシンおよびソフトウエア資源を識別し、アセンブルし、割り当てし、相互接続するというような、オンデマンドのデータ処理環境で取る挙動に関する。ＩＴユーザーの広範に変化するデマンドあるいは動的なデマンドに対処するためには、以下の３つの原則に従って資源がおおまかに配備される。
１．資源ができるだけ早く配備されること。
２．資源が安全であり、従って各ユーザーのコミュニティの構成並びに各ユーザーのデータが他のユーザーやユーザー・コミュニティには使用できないこと。
３．ユーティリティの資源のコスト効率を確保するように管理オーバーヘッドをできるだけ小さくして資源が配備されること。
これらの基本的な原則はインフラストラクチャを動的に構築する際にＩＴ最適化を下支えする。
【０００４】
ＩＴインフラストラクチャの動的な構成の従来技術は各ツールが特定の１つまたは複数の資源を構築する役割を有する複数のツールの組に依存する。「プロビジョニング(provisioning)」と一般に名づけられる、この資源の構築(resource building)には、相互接続され得る多数のオープン・スタンダードに基づく技術を用いる。この相互接続性により管理システム中のサーバー上で稼動するツールの階層を確立することができる。その階層の一番上で、管理サーバーはどの資源がプロビジョニングされる必要があるかをプロビジョニング・サーバーに教示する役割がある。次のレベルでは、プロビジョニング・サーバー上の一組のツールが一組の資源の実際のプロビジョニングを行う役割がある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は（従来と）異なるプロビジョニング・パラダイム（規範）を提供する。上記で定義したプロビジョニング・モデルは、プロビジョニングされる資源とともにプロビジョニング・サーバーを緊密に結合する。しかし、ここに示す「ダイナミック（動的な）プロビジョニング・モデル」はインフラストラクチャ中で何か適用できる機能があれば全ての資源を使用可能とみる。このことは管理資源およびプロビジョニング資源がそれと関連する資源に最早恒久的に専用とするのではないことを意味する。
【課題を解決するための手段】
【０００６】
本発明では、プロビジョニングおよび管理の資源が資源全体をプールした中から引き出される。リクエストされたオンデマンド管理機能をセキュアに実行するために管理資源および被管理資源がネットワーク上で動的に関連する。管理され、プロビジョニングされるデバイス相互間のネットワークを管理システムが制御するので、資源相互をリンクしても最少量のネットワーク・オーバーヘッドしか引き起こさない。プロビジョニング資源はそれ自体動的に構築され、管理されている資源と自動的に関係付けられるので、管理のオーバーヘッドが顕著に減少する。標準のロギングおよびメトリクス（評価指標）が管理システム中に集められていれば、それを、任意の時点でどれだけの数のプロビジョニング・サーバーが必要とされるかを決定するための簡単なタスクに能力プランニングがしてしまう。その任意の時点で必要な機能を実行するのに必要な期間の間だけ資源の各夫々の組が割り当てられる。この技法は前述の所望の３つの基準全てに合致する。
１．資源が迅速に配備される
このソリューション（解決策）がその自動化されたインフラストラクチャを活用し、全ての所望のタスクを実行するように管理資源と被管理資源とを動的に関連付けるので、最適のペアリング（組み合わせ）が達成可能である。こうして、プロビジョニング中の資源の数、タイプ、スケジューリング要求に最も適合するように管理資源の選別を選択することができる。
２．資源がセキュアにプロビジョニングされる
そのプロビジョニング・プロセスの役割を有する管理資源がそのプロビジョニング・プロセスの期間中に個別のユーザー・コミュニティの構成の所望の側面のインスタンス化への排他的なアクセスを許される。従って、製品の使用前、使用中および使用後もその構成はセキュアである。特定のコミュニティがそれらを使用してきた後、一組の資源をスクラビングする必要があれば、これらの資源は全てのユーザー・コミュニティから切り離されて、管理資源と関連付けられ、「スクラビング(scrubbing)」プロビジョニング・タスクを実行する。
３．管理資源が最適化される
管理資源が「ジャスト・イン・タイム」のプロビジョニング・モデルを用いる需要に合致するように動的に配備される。これは従来の「ジャスト・イン・ケース（念のため）」あるいは「最悪の場合」のプロビジョニング・モデルで用いられる静的な割り当てとは反対である。こうして、専用の管理資源の数が大幅に減少される。
【０００７】
本発明とみなせる主題を抽出しそれを特許請求の範囲に明記するが、本発明はその構成およびそれを実施する方法の両方について、その更なる目的および利点とともに、添付図面と関連する以下の説明を参照することで最もよく理解できよう。
【発明を実施するための最良の形態】
【０００８】
図１は管理資源と管理される資源との間の関係を示す。図１において管理サーバー１００は資源３００の特定のセットをどのようにプロビジョニングするかをプロビジョニング・サーバー２００に教示する。このプロビジョニング・サーバー２００が特定のセットの資源の責任を負っているので、それはこれらの資源を直接制御する。このモデルは一セットの資源を制御するのに効果的である。何故ならプロビジョニング・サーバーに割り当てられた資源の数が効率を維持するためにロックされるからである。プロビジョニング・サーバーは或る数の資源を効率的に管理することができるだけである。もしあまりにも多くの資源を制御しようとすると、プロビジョニング・プロセスにエラーを注入してしまう。もしあまりにも少しの資源しかプロビジョニング・サーバーと協働(associatedwith)しないなら、全ての資産（アセット）は完全には活用されないことになる。更に、図１に示すプロビジョニング・サーバーはプロビジョニングだけのジョブ専用である。何故なら、それらはそれらの上に多数の構成を有するからであり、ユーザーのコミュニティによってアクセスされることはできないからである。効果的には、これらのサーバーはオンデマンド環境内で使用される資源のもとで変化する。これらは資源を効果的に管理するのに必要であるがその生産環境では使用できない。こうして、このモデルは迅速で安全であることによって最初の２つの原理を効果的に守っているが、幾分無駄であり、第３の原理には関係ない。 多くの企業環境の場合、管理される資源が幾分小さいときこれは大きな問題ではない。しかし、 資源のプールが大きくなるにつれ、管理のオーバーヘッドの不所望の程度がますます大きくなってくる。この問題は３つの全ての原理を満たす態様でその資源をどのようにプロビジョニングするかである。本発明のソリューションは今日利用できるバーチャル化の技法を十分活用して、そのソリューションの中で論理的にモデル化されたデータセンタまたはその一部を管理する。
【０００９】
前述の課題に対する管理的なソリューションは、たとえば以下の管理機能のうちの一つまたは複数を提供する。
（１）モデル化されたデータセンタ環境とデータセンタ環境中での資源のリアルワールドでのインスタンス化との間のリンクを提供するプロセス重視の実行エンジン。
（２）リアル・タイム環境への変化をインタラクティブに生じさせるプロセス重視の実行エンジン、ワークフロー・エンジン。
（３）その物理的な環境に変化を反映させるようにモデルを同時的に更新するワークフロー・エンジン。
前述のモデルは、仮想化したネットワーク接続を介して相互接続され、またデータセンタの消費者資源をプロビジョニングしかつ構成するのに用いられる専用の静的な管理資源として扱われる種々の資源を含む。この役割では、これらの資源はこれらがプロビジョニングする消費者資源の論理的な（物理的でない）延長と見られる。これはもっと多くの専用の管理資源を必要とし、またその資源を最適化しないソリューション、そしてその企業における資源のもっともコスト効果の大きい管理ではないソリューションを実行してしまう。 
【００１０】
本発明により提供される一実施例のソリューションは、直前に開示したモデルにおける変化を導入する。従来の多くの専用の静的な管理資源を動的にプロビジョニング可能な資源そのものに再定義することによって、もっと大きな粒度（細分度）レベルがこのプロビジョニング・プロセスに適用される。このソリューションを実行するには、もっと成熟し完成したデータセンタ・モデルを含む。
【００１１】
本発明の一実施例は外部の管理機能、例えば事前予約およびスケジューリングのサブシステムの統合または企業内での任意の他の所望の管理機能およびサブシステムへの統合を行えるようにウエブ・サービス‐ＳＯＡＰ（ソープ、Simple Object Access Protocol）インターフェースを実装する。このＳＯＡＰプロトコルはサーバー環境相互間でオープンスタンダードの通信フローが行われるのを確保する。
【００１２】
外部管理機能との統合を通じてその導入態様を拡張し易くするために本発明のプロセス中でカスタム・プロセスが導入される。これらのカスタム・プロセスは、その環境に新しく導入される資源を包含するためそのソリューションを拡張するようにＳＯＡＰインターフェースを外部的に呼び起こす。この新しく定義された資源はそこでモデル化され、プロビジョニングされ、企業の広範な管理スキーマの中にもたらされる。
【００１３】
ＳＯＡＰインターフェースおよびその派生体が、単一の全てを包含する企業の管理スキーマ中に所望のソリューションの別々のインスタンス化を統合する能力を機能的にも提供する。
【００１４】
このソリューションの一実施例は或るコアなテクノロジを含み、導入している。このソリューションが用い統合しているこの物理的かつ論理的なエレメントは以下の例を含む。（一実施例では、このソリューションは以下のコア・テクノロジを含み、導入し、統合している。）
機能的なＴＣＰ／ＩＰが導入される必要がある。このネットワークは分散された管理およびプロビジョニング機能(provisioningfunction)を導入するための背骨となるトランスポート機構として働く。
アクション要求がワークフロー・プロセス・エンジンに多数の異なるメソッドによって与えられる。
１．ウエブ・サービス‐ＳＯＡＰがワークフロー・プロセスを引き起こすように提出される。
２．プロビジョニング・マネジャのアドミニストレーティブ・ユーザ・インターフェースから引き起こされる。
３．オートメーション・ルーチンがウエブ・サービス‐ＳＯＡＰ要求を介してワークフロー・プロセスを引き起こす。
【００１５】
一旦、アクション要求がプロビジョニング・タスクを実行するために提出されると、マスタ・プロビジョニング・ワークフローが引き起こされる。このマスタ・プロビジョニング・ワークフローはそのプロビジョニング要求を評価し、そのデータセンタ・モデルに対して全ての要求されたデータ・センタ・コンポーネントを検証する。もしその要求が成功裡に検証され、そのデータセンタ・モデル中に定義された有効な資源のみを含むならば、そのアクション要求が更に処理される。このマスタ・プロビジョニング・ワークフローはサブプロセス・ワークフローへの呼び出しを行う。これらのサブプロセス・ワークフローは個別のＩＴ資源および集合的なＩＴ資源ならびにそのときの要求の一部としてプロビジョニングされるべきコンポーネントに対する特定のプロビジョニング・タスクを実行するように設計される。  
【００１６】
その全体のプロビジョニング・プロセスはワークフローの階層によって究極的には実行される。これらのワークフローはマスタ・プロビジョニング・プロセスによって引き起こされ、モニタ（監視）される。これらのサブプロセス・ワークフローはＩＴ資源コンポーネントと非常にアトミックな態様で相互作用するように設計されていて、その導入された設計が最終的にはモジュラー設計になっている。個々のプロセスは、その下にあるテクノロジがデータセンタ環境の中で進化し変化するので、容易に加えられ、更新されまたは除去される。これらのワークフロー・プロセスはＩＴ資源上をプロビジョニングし構成化タスクを実行し、そしてその後その資源の新しい状態を反映するようにデータセンタ・モデルを更新する。プロビジョニング・プロセス中およびプロビジョニング・プロセス解除中に生じるこれらの種々の状態変化は使用可能であり、割り当てられ、そして移行中とすることができる。
【００１７】
通常のビジネス事業を行う間にデータセンタのスタッフによってＩＴコンポーネントが再構成される際、時には保守動作を行い、特定の資源を動的なプロビジョニングのソリューションとして使用できないようにしたいことがある。このシナリオはサポートされ、そしてＩＴ資源を「保守」モードに必要な時間枠だけ移行し、一旦全ての保守手順が完了したらそれらを使用可能状態に戻すというようなワークフロー・プロセスが全ての標準的な方法によって引き起こされる。
【００１８】
図２は管理環境(management environment)と管理される資源（被管理資源）(resources being managed)との間の非常に異なる関係を示す。本発明では未使用の資源がプロビジョニング資源、管理資源または被管理資源のいずれかとして使用される。プロビジョニング資源プール２５０および管理資源プール２６０中に或る小さな確立された資源の組があるが、この環境に於けるサーバーの数は必要性に応じて変化する。従って、プロビジョニング・サーバーの必要性が増すと、未使用の資源がプロビジョニング資源プール２５０の中にプロビジョニングされる。プロビジョニング資源プール２５０中にプロビジョニング・サーバーが一旦置かれると、他の未使用資源が未使用資源プール３５０から引かれ、プロビジョニング資源プール２５０中にサーバーによってプロビジョニングされ、被管理資源プール３６０に移行される。プロビジョニングの必要性が一旦なくなると、プロビジョニング資源プール２５０中の資源が未使用資源プール３５０に戻され、そこではプロビジョニング資源、管理資源、または被管理資源のいずれかとして使用できるようになる。
【００１９】
抽象的なコマンドを用いてネットワーク制御を行う能力を有する完全に構成可能な層２／層３ネットワーク切換え機構が望ましい。このネットワーク・インフラストラクチャにより進展することができるセキュアな環境が可能となり、これが異なるユーザー・コミュニティのために別々の異なるセキュアな環境を提供することができる。このソリューションは、セキュアな動作環境を維持しながらネットワーク中でネットワーク設定を再構成し、資源を再配置するカスタム・プロセスを導入する。
【００２０】
遠隔でサーバーを立ち上げることができ、完全に導入されたコマンド・ラインＡＰＩ（Application Program Interface）を備え、被管理サーバー資源のインバンド管理、アウトオブバンド管理の両方をサポートするプレブート実行環境（ＰＸＥ）テクノロジが本件ソリューションの非常に望ましいエレメントである。このソリューションは、コンシューマ資源を管理し、プロビジョニングすると同時に、現在の需要に合わせるのに必要なとおりに動的に管理され、プロビジョニングされる、そのソリューションのエレメントとしてこれらの管理資源を定義するようにこれらの管理エレメントを使用する。
【００２１】
このソリューションの実施例はオートノミック理論を活用し、（ｃｌｕｓｔｅｒ  Ｓｙｓｔｅｍｓ  Ｍａｎａｇｅｒ（商品名）または  Ｘｃａｔ（商品名）のような）別個のサービスがクラスタまたはグリッド・ノードの実際の導入および構成を管理することができるようにする。何故ならばノードの導入および構成がサービスに権限委譲され、管理ソリューションがそのモデルの効果的な管理を導入することに焦点をおいているからである。このソリューションはネットワーク・ルーティング・プロトコルを管理するためのスイッチング環境ならびに構築環境および各時点の製品配備を操作するセキュリティ内容とともに相互作用する。更に、サーバー管理は、ユーザー管理のためのＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）および暗号化されたアクセスのためのＳＳＨ（Ｓｅｃｕｒｅ  Ｓｈｅｌｌ）を用いてセキュアな実行を介して達成される。
【００２２】
このソリューションのプロビジョニング・サーバー管理コンポーネントはＷｅｂＳｐｈｅｒｅ（商標名）アプリケーションの上で構築され、管理された環境のモデルを記憶するようにＤＢ２（商標名）データべースを用いる。モデルおよびその真のカウンターパートを操作することによって、その実施例ではプロビジョニング資源および生産資源の配備が制御される。
【００２３】
本発明を或る好適な実施例に従ってここで詳細に説明したが、多くの変形および変更を当業者が為すことができる。従って、本発明の真の趣旨および範疇の中にそのような全ての変形や修正が包含されることを意図している。
【図面の簡単な説明】
【００２４】
【図１】従来のプロビジョニング構造のブロック図である。
【図２】本発明で用いられる動的プロビジョニング構造のブロック図である。
【符号の説明】
【００２５】
１５０  中央管理資源
２５０  プロビジョニング資源プール
２６０  管理資源プール
３５０  未使用資源プール
３６０  被管理資源プール
【図１】
2008004092.tif 000003
【図２】
2008004092.tif 000004