JP2017529628A - マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法 - Google Patents

Abstract

一実施形態に従うと、マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法が本明細書に記載される。当該システムは、１つ以上のパーティションを、テナントが使用するために当該テナントと関連付けることができ、パーティションはドメインのランタイムおよび管理の区分またはスライスである。パッチングプロセスは、アプリケーションサーバクラスタ化環境が提供する高可用性特徴を利用して、中断なしでまたはゼロのダウンタイムで動作するドメインの能力を維持する制御されたローリングリスタートにおいてパッチを適用することができる。当該プロセスを用いて、アプリケーションサーバ、アプリケーション、または他のソフトウェアコンポーネントの未パッチバージョンもしくは以前のバージョンを起こり得るロールバックのために保存すること、または回復不能エラーが起きた場合に自動復帰を提供することを含む、複雑なまたは長い実行タスクを自動化することができる。

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。

関連出願の優先権主張および相互参照：
本願は、２０１４年９月２４日に出願され「SYSTEM AND METHOD FOR MULTITENANT-AWARE PATCHING IN A MULTITENANT APPLICATION SERVER ENVIRONMENT（マルチテナントアプリケーションサーバ環境におけるマルチテナント認識型パッチングのためのシステムおよび方法）」と題された米国仮出願番号第６２／０５４，９０３号に基づく優先権の利益を主張するものであり、２０１５年１月２１日に出願され「SYSTEM AND METHOD FOR SUPPORTING MULTI-TENANCY IN AN APPLICATION SERVER, CLOUD, OR OTHER ENVIRONMENT（アプリケーションサーバ、クラウド、または他の環境においてマルチテナンシをサポートするためのシステムおよび方法）」と題された米国特許出願番号第１４／６０１，８８３号に関連する。上記の出願の各々は、引用により本明細書に援用される。

発明の分野：
本発明の実施形態は、概して、アプリケーションサーバおよびクラウドプラットフォーム環境に関し、特に、マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法に関する。

背景：
アプリケーションサーバおよび他のエンタープライズコンピューティング環境において、アドミニストレータにとっての一般的なタスクは、複数のドメインをサポートする一連のアプリケーションサーバインストールをパッチする必要性である。パッチは、特定の問題についての１回限りの解決、または周期的なバージョン更新を含み得る。なぜパッチをインストールする必要があるのかに係わらず、アドミニストレータは概して、アプリケーションダウンタイムを最小化しつつパッチをロールアウトするためにドメインの各ノード上の複雑な一連のステップを実行する必要があり、当該ステップは、パッチング環境が各ホスト上で最新であることを確実にすること；ホスト上で実行されているそれらのサーバをシャットダウンすること；ならびに、次に、アプリケーションサーバインスタンスをパッチおよびリスタートしてパッチが正確に機能するかどうかを検証することを含む。パッチングは複雑なプロセスであり、１つのアプリケーションサーバインスタンスについても何分も掛かることがあり、パッチがドメイン内のすべてのノードに適用される場合は数時間にもなり得るため、当該プロセスはシステムダウンタイムのリスクを冒すユーザにとって不安をもたらし得る。

概要：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法が本明細書に記載される。当該システムは、１つ以上のパーティションを、テナントが使用するために当該テナントと関連付けることができ、パーティションはドメインのランタイムおよび管理の区分またはスライスである。パッチングプロセスは、アプリケーションサーバクラスタ化環境が提供する高可用性特徴を利用して、中断なしでまたはゼロのダウンタイムで動作するドメインの能力を維持する制御されたローリングリスタートにおいてパッチを適用することができる。当該プロセスを用いて、アプリケーションサーバ、アプリケーション、または他のソフトウェアコンポーネントの未パッチバージョンもしくは以前のバージョンを起こり得るロールバックのために保存すること、または回復不能エラーが起きた場合に自動復帰を提供することを含む、複雑なまたは長い実行タスクを自動化することができる。

一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す図である。 一実施形態に従った、例示的なマルチテナント環境をさらに示す図である。 一実施形態に従った、パッチングのサポートを示す図である。 一実施形態に従った、セッション処理のサポートを含むパッチングのためのシステムをさらに示す図である。 一実施形態に従った、セッション互換性検出のサポートを含むパッチングのためのシステムをさらに示す図である。 一実施形態に従った、パッチングのためのシステムをさらに示す図である。 一実施形態に従った、パッチングのためのシステムをさらに示す図である。 一実施形態に従った、パッチングのためのシステムをさらに示す図である。 一実施形態に従った、パッチングのためのシステムをさらに示す図である。 一実施形態に従った、パッチングイベントダイヤグラムを示す図である。 一実施形態に従った、別のパッチングイベントダイヤグラムを示す図である。 一実施形態に従った、別のパッチングイベントダイヤグラムを示す図である。 一実施形態に従った、パッチングのための方法のフローチャートを示す図である。

詳細な説明：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法が本明細書に記載される。当該システムは、１つ以上のパーティションを、テナントが使用するために当該テナントと関連付けることができ、パーティションはドメインのランタイムおよび管理の区分またはスライスである。パッチングプロセスは、アプリケーションサーバクラスタ化環境が提供する高可用性特徴を利用して、中断なしでまたはゼロのダウンタイムで動作するドメインの能力を維持する制御されたローリングリスタートにおいてパッチを適用することができる。当該プロセスを用いて、アプリケーションサーバ、アプリケーション、または他のソフトウェアコンポーネントの未パッチバージョンもしくは以前のバージョンを起こり得るロールバックのために保存すること、または回復不能エラーが起きた場合に自動復帰を提供することを含む、複雑なまたは長い実行タスクを自動化することができる。

アプリケーションサーバ（たとえば、マルチテナント（Multi-Tenant：ＭＴ））環境
図１は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す。

図１に示されるように、一実施形態に従うと、アプリケーションサーバ（たとえばマルチテナント（ＭＴ））環境１００または他のコンピューティング環境は、ソフトウェアアプリケーションのデプロイメントおよび実行を可能にするものであって、アプリケーションサーバドメインを定義するために実行時に用いられるドメイン１０２の構成を含み、当該ドメイン１０２の構成に従って動作するように構成することができる。

一実施形態に従うと、アプリケーションサーバは、実行時に使用されるよう定義される１つ以上のパーティション１０４を含み得る。各々のパーティションは、グローバルユニークパーティション識別子（identifier：ＩＤ）およびパーティション構成と関連付けることができ、さらに、リソースグループテンプレートの参照１２６および／またはパーティション特有のアプリケーションもしくはリソース１２８とともに、１つ以上のリソースグループ１２４を含み得る。ドメインレベルのリソースグループ、アプリケーションおよび／またはリソース１４０も、任意にはリソースグループテンプレートの参照とともに、ドメインレベルで定義することができる。

各々のリソースグループテンプレート１６０は、１つ以上のアプリケーションＡ１６２、Ｂ１６４、リソースＡ１６６、Ｂ１６８および／または他のデプロイ可能なアプリケーションもしくはリソース１７０を定義することができ、リソースグループによって参照することができる。たとえば、図１に示されるように、パーティション１０４におけるリソースグループ１２４は、リソースグループテンプレート１６０を参照する（１９０）ことができる。

概して、システムアドミニストレータは、パーティション、ドメインレベルのリソースグループおよびリソースグループテンプレート、ならびにセキュリティ領域を定義することができるとともに、パーティションアドミニストレータは、たとえば、パーティションレベルのリソースグループを作成するか、アプリケーションをパーティションにデプロイするかまたはパーティションについての特定の領域を参照することによって、それら自体のパーティションのアスペクトを定義することができる。

図２は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。

図２に示されるように、一実施形態に従うと、パーティション２０２は、たとえば、リソースグループテンプレート２１０の参照２０６を含むリソースグループ２０５と、仮想ターゲット（たとえば仮想ホスト）情報２０７と、プラグ接続可能なデータベース（pluggable database：ＰＤＢ）情報２０８とを含み得る。リソースグループテンプレート（たとえば２１０）は、たとえば、Ｊａｖａ（登録商標）メッセージサーバ（Java Message Server：ＪＭＳ）サーバ２１３、ストア・アンド・フォワード（store-and-forward：ＳＡＦ）エージェント２１５、メールセッションコンポーネント２１６またはＪａｖａデータベースコネクティビティ（Java Database Connectivity：ＪＤＢＣ）リソース２１７などのリソースとともに、複数のアプリケーションＡ２１１およびＢ２１２を定義することができる。

図２に示されるリソースグループテンプレートが一例として提供される。他の実施形態に従うと、さまざまなタイプのリソースグループテンプレートおよび要素を提供することができる。

一実施形態に従うと、パーティション（たとえば２０２）内のリソースグループが、特定のリソースグループテンプレート（たとえば２１０）を参照する（２２０）と、パーティション特有の情報２３０（たとえば、パーティション特有のＰＤＢ情報）を示すために、特定のパーティションと関連付けられた情報を、参照されたリソースグループテンプレートと組合わせて用いることができる。次いで、パーティション特有の情報は、パーティションによって使用されるリソース（たとえば、ＰＤＢリソース）を構成するようにアプリケーションサーバによって使用可能である。たとえば、パーティション２０２と関連付けられたパーティション特有のＰＤＢ情報は、そのパーティションによって使用されるべき適切なＰＤＢ２３８を備えたコンテナデータベース（container database：ＣＤＢ）２３６を構成する（２３２）ようにアプリケーションサーバによって使用可能である。

同様に、一実施形態に従うと、特定のパーティションと関連付けられた仮想ターゲット情報を用いて、そのパーティションによって使用されるべきパーティション特有の仮想ターゲット２４０（たとえば、ユニフォーム・リソース・ロケータ（uniform resource locator：ＵＲＬ）（たとえば、http://baylandurgentcare.com）によってアクセス可能にすることができるbaylandurgentcare.com）を定義する（２３９）ことができる。

図３は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。

一実施形態に従うと、config.xml構成ファイルなどのシステム構成を用いて、パーティションを定義する。当該パーティションは、そのパーティションと関連付けられたリソースグループについての構成エレメントおよび／または他のパーティションプロパティを含む。値は、プロパティ名／値の対を用いてパーティションごとに指定することができる。

一実施形態に従うと、複数のパーティションは、管理されるサーバ／クラスタ２４２内で、または、ＣＤＢ２４３にアクセス可能でありかつウェブ層２４４を介してアクセス可能である同様の環境内で、実行することができる。これにより、たとえば、ドメインまたはパーティションを（ＣＤＢの）ＰＤＢのうち１つ以上のＰＤＢに関連付けることが可能となる。

一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は、そのパーティションと関連付けられた複数のリソースを含むように構成することができる。たとえば、パーティションＡは、アプリケーションＡ１ ２５２と、アプリケーションＡ２ ２５４と、ＪＭＳ Ａ ２５６と、さらには、ＰＤＢ Ａ ２５９と関連付けられたデータソースＡ２５７とをともに含むリソースグループ２５１を含むように構成することができる。この場合、パーティションは仮想ターゲットＡ２５８を介してアクセス可能である。同様に、パーティションＢ２６０は、アプリケーションＢ１ ２６２と、アプリケーションＢ２ ２６４と、ＪＭＳ Ｂ ２６６と、さらには、ＰＤＢ Ｂ ２６９と関連付けられたデータソースＢ２６７とをともに含むリソースグループ２６１を含むように構成することができる。この場合、パーティションは仮想ターゲットＢ２６８を介してアクセス可能である。

上述の例のうちいくつかはＣＤＢおよびＰＤＢの使用を例示しているが、他の実施形態に従うと、他のタイプのマルチテナントのデータベースまたは非マルチテナントのデータベースをサポートすることができる。この場合、特定の構成は、たとえば、スキーマを使用するかまたはさまざまなデータベースを使用することによって、各々のパーティションのために提供することができる。

リソース
一実施形態に従うと、リソースは、環境のドメインにデプロイすることができるシステムリソース、アプリケーションまたは他のリソースもしくはオブジェクトである。たとえば、一実施形態に従うと、リソースは、アプリケーション、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、ＷＬＤＦもしくはデータソースであり得るか、または、サーバ、クラスタもしくは他のアプリケーションサーバターゲットにデプロイすることができる他のシステムリソースもしくは他のタイプのオブジェクトであり得る。

パーティション
一実施形態に従うと、パーティションは、パーティション識別子（partition identifier：ＩＤ）および構成に関連付けられ得るドメインのランタイムおよび管理の区分またはスライスであるとともに、アプリケーションを含み得て、ならびに／または、リソースグループおよびリソースグループテンプレートを使用することによってドメイン全体に渡るリソースを参照し得る。

概して、パーティションは、それ自体のアプリケーションを含み、リソースグループテンプレートを介してドメイン全体に渡るアプリケーションを参照し、それ自体の構成を有し得る。パーティション可能なエンティティは、リソース、たとえば、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、およびＷＬＤＦリソースや、他のコンポーネント、たとえばＪＮＤＩネームスペース、ネットワークトラフィック、ワークマネージャ、セキュリティポリシーおよび領域などを含み得る。マルチテナント環境のコンテキストにおいては、システムは、テナントと関連付けられたパーティションの管理およびランタイムのアスペクトへのアクセスをテナントに提供するように構成することができる。

一実施形態に従うと、パーティション内の各々のリソースグループは、任意には、リソースグループテンプレートを参照することができる。パーティションは、複数のリソースグループを有し得るとともに、それらの各々はリソースグループテンプレートを参照し得る。各々のパーティションは、パーティションのリソースグループが参照するリソースグループテンプレートにおいて指定されていない構成データについてのプロパティを定義することができる。これにより、パーティションが、リソースグループテンプレートで定義されたデプロイ可能なリソースをそのパーティションで使用されるべき特定の値にバインドするものとして機能することが可能となる。場合によっては、パーティションは、リソースグループテンプレートによって指定される構成情報を無効にすることができる。

一実施形態に従うと、パーティション構成は、たとえば、config.xml構成ファイルによって定義されるように、複数の構成エレメントを含み得る。複数の構成エレメントは、たとえば、「パーティション（partition）」（そのパーティションを定義する属性および子エレメントを含む）；「リソース・グループ（resource-group）」（パーティションにデプロイされるアプリケーションおよびリソースを含む）；「リソース・グループ・テンプレート（resource-group-template）」；（そのテンプレートによって定義されるアプリケーションおよびリソースを含む）；「ｊｄｂｃ・システム・リソース・無効化（jdbc-system-resource-override）」（データベース特有のサービス名、ユーザ名およびパスワードを含む）；ならびに、「パーティション・プロパティ（partition-properties）」（リソースグループテンプレートにおいてマクロ置換のために使用可能なプロパティキー値を含む）を含む。

始動後、システムは、構成ファイルによって提供される情報を用いて、リソースグループテンプレートから各々のリソースについてのパーティション特有の構成エレメントを生成することができる。

リソースグループ
一実施形態に従うと、リソースグループは、名前付けされ完全に修飾されたデプロイ可能なリソースの集合であって、ドメインまたはパーティションのレベルで定義することができ、かつ、リソースグループテンプレートを参照することができる。リソースグループにおけるリソースは、完全に修飾されているものと見なされる。というのも、アドミニストレータが、それらのリソースを開始させるのに必要とされるかまたはそれらのリソースに接続するのに必要とされるすべての情報、たとえば、データソースに接続するためのクレデンシャル、またはアプリケーションについての目標情報、を提供しているからである。

システムアドミニストレータは、ドメインレベルで、またはパーティションレベルでリソースグループを公開することができる。ドメインレベルでは、リソースグループは、関連するリソースをグループ化するのに好都合な方法を提供する。システムは、グループ化されていないリソースと同じドメインレベルのリソースグループにおいて公開されたリソースを管理することができる。このため、リソースは、システム起動中に開始させたり、システムのシャットダウン中に停止させたりすることができる。アドミニストレータはまた、グループ内のリソースを個々に停止させるか、開始させるかまたは削除することができ、グループ上で動作させることによって暗黙的にグループ内のすべてのリソースに対して機能することができる。たとえば、あるリソースグループを停止させることにより、まだ停止されていないグループにおけるすべてのリソースを停止させ；リソースグループを始動させることにより、まだ始動させていないグループにおけるいずれのリソースも始動させ、リソースグループを削除することにより、グループに含まれるすべてのリソースを削除する。

パーティションレベルでは、システムまたはパーティションアドミニストレータは、任意のセキュリティ制限下で、或るパーティションにおいて０個以上のリソースグループを構成することができる。たとえば、ＳａａＳ使用事例においては、さまざまなパーティションレベルのリソースグループは、ドメインレベルのリソースグループテンプレートを参照することができる。ＰａａＳ使用事例においては、リソースグループテンプレートを参照しないが代わりにそのパーティション内でのみ使用可能にされるべきアプリケーションおよびそれらの関連するリソースを表わすパーティションレベルのリソースグループを作成することができる。

一実施形態に従うと、リソースグループ化を用いることで、アプリケーションと、それらアプリケーションがドメイン内で別個の管理ユニットとして使用するリソースとをともにグループ化することができる。たとえば、以下に記載される医療記録（ＭｅｄＲｅｃ）アプリケーションにおいては、リソースグループ化によりＭｅｄＲｅｃアプリケーションおよびそのリソースが定義される。複数のパーティションは、各々がパーティション特有の構成情報を用いて、同じＭｅｄＲｅｃリソースグループを実行することができ、このため、各々のＭｅｄＲｅｃインスタンスの一部であるアプリケーションが各々のパーティションにとって特有のものにされる。

リソースグループテンプレート
一実施形態に従うと、リソースグループテンプレートは、リソースグループから参照することができドメインレベルで定義されるデプロイ可能なリソースの集合であり、そのリソースを起動するのに必要な情報のうちいくらかは、パーティションレベル構成の仕様をサポートするように、テンプレート自体の一部として記憶されない可能性がある。ドメインは、リソースグループテンプレートをいくつ含んでもよく、それらの各々は、たとえば、１つ以上の関連するＪａｖａアプリケーションと、それらのアプリケーションが依存するリソースとを含み得る。このようなリソースについての情報のうちのいくらかは、すべてのパーティションにわたって同じであってもよく、他の情報はパーティションごとに異なっていてもよい。すべての構成がドメインレベルで指定される必要はなく、代わりに、パーティションレベル構成が、マクロまたはプロパティ名／値の対を使用することによってリソースグループテンプレートで指定することができる。

一実施形態に従うと、特定のリソースグループテンプレートは、１つ以上のリソースグループによって参照可能である。概して、任意の所与のパーティション内では、リソースグループテンプレートは一度に１つのリソースグループによって参照することができる。すなわち、同じパーティション内で複数のリソースグループによって同時に参照することはできない。しかしながら、異なるパーティションにおける別のリソースグループによって同時に参照することができる。リソースグループを含むオブジェクト、たとえばドメインまたはパーティションは、プロパティ名／値の割当てを用いて、任意のトークンの値をリソースグループテンプレートで設定することができる。システムは、参照するリソースグループを用いてリソースグループテンプレートを起動させると、それらのトークンを、リソースグループが含むオブジェクトにおいて設定された値と置換えることができる。場合によっては、システムはまた、静的に構成されたリソースグループテンプレートおよびパーティションを用いて、パーティション／テンプレートの組合せごとにランタイム構成を生成することができる。

たとえば、ＳａａＳ使用事例においては、システムは、同じアプリケーションおよびリソースを複数回起動することができるが、そのうちの１回は、それらを用いるであろう各パーティションごとに起動され得る。アドミニストレータがリソースグループテンプレートを定義すると、これらは、どこか他のところで提供されるであろう情報を表わすためにトークンを用いることができる。たとえば、ＣＲＭ関連のデータリソースに接続する際に使用されるユーザ名は、リソースグループテンプレートにおいて＼＄｛ＣＲＭＤａｔａＵｓｅｒｎａｍｅ｝として示すことができる。

テナント
一実施形態に従うと、マルチテナント（ＭＴ）アプリケーションサーバ環境などのマルチテナント環境においては、テナントは、１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションによって表現可能であるエンティティ、または１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションに関連付けることができるエンティティである。

たとえば、テナントは、別個のユーザ組織、たとえばさまざまな外部会社、特定の企業内のさまざまな部門（たとえばＨＲおよび財務部）などを表わすことができ、それら各々は、異なるパーティションに関連付けることができる。テナントのグローバルユニークアイデンティティ（テナントＩＤ）は、特定の時点において特定のユーザを特定のテナントに関連付けるものである。システムは、たとえば、ユーザアイデンティティの記録を参照することによって、ユーザアイデンティティから、特定のユーザがどのテナントに属しているかを導き出すことができる。ユーザアイデンティティにより、ユーザが実行することを認可されているアクションをシステムが実施することが可能となる。ユーザアイデンティティは、ユーザがどのテナントに属し得るかを含むが、これに限定されない。

一実施形態に従うと、システムは、互いに異なるテナントの管理およびランタイムを分離することを可能にする。たとえば、テナントは、それらのアプリケーションのいくつかの挙動、およびそれらがアクセスできるリソースを構成することができる。システムは、特定のテナントが別のテナントに属するアーティファクトを確実に管理することができないようにし、かつ、実行時に、特定のテナントの代わりに機能するアプリケーションがそのテナントと関連付けられたリソースのみを参照するが他のテナントと関連付けられたリソースは参照しないことを確実にすることができる。

一実施形態に従うと、テナント非認識型アプリケーションは、アプリケーションが応答している要求をどんなユーザが提示したかにかかわらず、アプリケーションが用いる如何なるリソースにもアクセス可能となるように明示的にテナントに対処する論理を含まないものである。対照的に、テナント認識型アプリケーションは、テナントに明示的に対処する論理を含む。たとえば、ユーザのアイデンティティに基づいて、アプリケーションは、ユーザが属するテナントを導き出すことができ、テナント特有のリソースにアクセスするためにその情報を用いることができる。

一実施形態に従うと、システムは、テナント認識型となるように明示的に書き込まれたアプリケーションをユーザがデプロイすることを可能にし、これにより、アプリケーション開発者は、現在のテナントのテナントＩＤを取得することができる。次いで、テナント認識型アプリケーションは、このテナントＩＤを用いて、アプリケーションの単一のインスタンスを用いている複数のテナントを処理することができる。

たとえば、単一の診療室または病院をサポートするＭｅｄＲｅｃアプリケーションは、２つの異なるパーティションまたはテナント（たとえばBayland Urgent CareテナントおよびValley Healthテナント）に対して公開することができ、その各々は、基礎をなすアプリケーションコードを変更することなく、別個のＰＤＢなどの別個のテナント特有のリソースにアクセスすることができる。

例示的なドメイン構成およびマルチテナント環境
一実施形態に従うと、アプリケーションは、ドメインレベルでリソースグループテンプレートにデプロイすることができるか、または、パーティションに範囲指定されているかもしくはドメインに範囲指定されているリソースグループにデプロイすることができる。アプリケーション構成は、アプリケーションごとまたはパーティションごとに指定されたデプロイメントプランを用いて無効化することができる。デプロイメントプランはまた、リソースグループの一部として指定することができる。

図４は、一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す。

一実施形態に従うと、システムがパーティションを始動させると、当該システムは、提供された構成に従って、それぞれのデータベースインスタンスに対して、各パーティションごとに１つずつ、仮想ターゲット（たとえば仮想ホスト）および接続プールを作成する。

典型的には、各々のリソースグループテンプレートは、１つ以上の関連するアプリケーションと、それらアプリケーションが依存するリソースとを含み得る。各々のパーティションは、それが参照するリソースグループテンプレートにおいて指定されていない構成データを提供することができるが、これは、場合によっては、リソースグループテンプレートによって指定されるいくつかの構成情報を無効にすることを含めて、パーティションと関連付けられた特定値に対するリソースグループテンプレートにおけるデプロイ可能なリソースのバインディングを行なうことによって、実行可能である。これにより、システムは、各々のパーティションが定義したプロパティ値を用いて、パーティションごとにリソースグループテンプレートによってさまざまに表わされるアプリケーションを起動させることができる。

いくつかのインスタンスにおいては、パーティションが含み得るリソースグループは、リソースグループテンプレートを参照しないか、または、それら自体のパーティション範囲指定されたデプロイ可能なリソースを直接定義する。パーティション内で定義されるアプリケーションおよびデータソースは、概して、そのパーティションにとってのみ使用可能である。リソースは、パーティション：<partitionName>/<resource JNDI name>、またはドメイン：<resource JNDI name>を用いて、パーティションの中からアクセスすることができるようにデプロイ可能である。

たとえば、ＭｅｄＲｅｃアプリケーションは、複数のＪａｖａアプリケーション、データソース、ＪＭＳサーバおよびメールセッションを含み得る。複数のテナントのためにＭｅｄＲｅｃアプリケーションを実行させるために、システムアドミニストレータは、テンプレートにおけるそれらのデプロイ可能なリソースを公開している単一のＭｅｄＲｅｃリソースグループテンプレート２８６を定義することができる。

ドメインレベルのデプロイ可能なリソースとは対照的に、リソースグループテンプレートにおいて公開されたデプロイ可能なリソースは、テンプレートにおいて完全には構成されない可能性があるか、または、いくつかの構成情報が不足しているので、そのままでは起動させることができない。

たとえば、ＭｅｄＲｅｃリソースグループテンプレートは、アプリケーションによって用いられるデータソースを公開し得るが、データベースに接続するためのＵＲＬを指定しない可能性がある。さまざまなテナントと関連付けられたパーティション、たとえば、パーティションＢＵＣ−Ａ２９０（Bayland Urgent Care：ＢＵＣ）およびパーティションＶＨ−Ａ２９２（Valley Health：ＶＨ）は、各々がＭｅｄＲｅｃリソースグループテンプレートを参照する（２９６，２９７）ＭｅｄＲｅｃリソースグループ２９３，２９４を含むことによって、１つ以上のリソースグループテンプレートを参照することができる。次いで、当該参照を用いて、Bayland Urgent Careテナントによって使用されるＢＵＣ−Ａパーティションと関連付けられた仮想ホストbaylandurgentcare.com３０４と、Valley Healthテナントによって使用されるＶＨ−Ａパーティションと関連付けられた仮想ホストvalleyhealth.com３０８とを含む各々のテナントのための仮想ターゲット／仮想ホストを作成する（３０２，３０６）ことができる。

図５は、一実施形態に従った例示的なマルチテナント環境をさらに示す。図５に示されるように、２つのパーティションがＭｅｄＲｅｃリソースグループテンプレートを参照している上述の例から引続いて、一実施形態に従うと、サーブレットエンジン３１０は、この例においてはBayland Urgent Careの医師テナント環境３２０およびValley Healthの医師テナント環境３３０といった複数のテナント環境をサポートするために用いることができる。

一実施形態に従うと、各々のパーティション３２１および３３１は、そのテナント環境についての入来トラフィックを受入れるための異なる仮想ターゲットと、異なるＵＲＬ３２２，３３２とを定義することができる。異なるＵＲＬ３２２，３３２は、パーティションと、この例ではBayland Urgent Careデータベースまたはvalley healthデータベースを含むそれぞれのリソース３２４、３３４とに接続するためのものである。同じアプリケーションコードが両方のデータベースに対して実行され得るので、データベースインスタンスは互換性のあるスキーマを用いることができる。システムがパーティションを始動させると、当該システムは、それぞれのデータベースインスタンスに対する接続プールおよび仮想ターゲットを作成することができる。

マルチテナント認識型パッチング
一実施形態に従うと、マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムおよび方法が本明細書に記載される。当該システムは、１つ以上のパーティションを、テナントが使用するために当該テナントと関連付けることができ、パーティションはドメインのランタイムおよび管理の区分またはスライスである。パッチングプロセスは、アプリケーションサーバクラスタ化環境が提供する高可用性特徴を利用して、中断なしでまたはゼロのダウンタイムで動作するドメインの能力を維持する制御されたローリングリスタートにおいてパッチを適用することができる。当該プロセスを用いて、アプリケーションサーバ、アプリケーション、または他のソフトウェアコンポーネントの未パッチバージョンもしくは以前のバージョンを起こり得るロールバックのために保存すること、または回復不能エラーが起きた場合に自動復帰を提供することを含む、複雑なまたは長い実行タスクを自動化することができる。

さまざまな実施形態に従うと、本明細書において提供されるパッチングプロセスの説明では、以下の概念の一部またはすべてが用いられる：
ＰＳＵ：パッチセット更新。

ＺＤＴ：ゼロダウンタイム。
ワークフロー：オーケストレーションフレームワークまたはパッチオーケストレータが実行する一連のタスク。

パッチングプリミティブ：パッチングロールアウトの再使用可能部分を表わす論理演算。

アウトオブプレース（out-of-place）パッチング：プロダクションサーバのダウンタイムが少なくて済み、必要であれば元のバージョンをより容易にロールバックする能力を提供する帯域内および帯域外パッチングおよび試験の態様で、ノンプロダクションサーバ上で実行されているたとえばＯｒａｃｌｅホームをパッチングしてから、パッチを試験および検証した後に、それをプロダクションサーバにプッシュアウトすること。

図６は、一実施形態に従ったパッチングのサポートを示す。
図６に示されるように、一実施形態に従うと、システムは管理サーバ４００を含み得、管理サーバ４００は、この例では、管理されるサーバ（ここではＭＳ１、ＭＳ２およびＭＳ３として示される）の第１のフェイルオーバーグループ４０４と、管理されるサーバ（ここではＭＳ４、ＭＳ５およびＭＳ６として示される）の第２のフェイルオーバーグループとを含む、管理されるサーバまたはクラスタを管理する役割を果たす。管理サーバは、ＲＥＳＴ ＡＰＩ４１０、または別のタイプのインターフェイスを介してクライアントがアクセス可能である。

一実施形態に従うと、システムはパッチオーケストレーションフレームワークまたはパッチオーケストレータ４２０をさらに含み、パッチオーケストレータ４２０は、パッチングワークフローの一部として、以下にさらに説明するように複数のパッチングプリミティブを用いて、ソフトウェアコンポーネントもしくはパッチのさまざまなバージョンをロールアウトするおよび／または適用するように動作する。

概して、パッチオーケストレータは、ロバストな態様で動作するように、かつ、タスク再試行、およびロールバックセマンティクスなどの機能のサポートを含むように設計される。

一実施形態に従うと、パッチオーケストレーションプロセスは、アプリケーションサーバが提供するさまざまな特徴を活用して、高度な機能を提供する。当該機能は、後方互換性を有さない可能性があるアプリケーションセッションを処理する能力；管理されるサーバ内の既存のセッションが終了するのを待ってからそのサーバをシャットダウンする、セッション認識型グレースフルシャットダウン；パッチングウィンドウ時に複製セッションの自動デシリアライゼーションをオフにする、複製セッションのレイジーデシリアライゼーション；クラスタリスタートを回避するためにレイジーデシリアライゼーションを動的にオン／オフにすること；およびグループ情報に基づいたフェイルオーバーなどであり、これらの特徴または機能の各々は以下にさらに説明する。

一実施形態に従うと、パッチオーケストレータがサポートするパッチングプリミティブの例として、トラフィックディレクタまたは他のタイプのロードバランサ４３０、たとえばオラクルトラフィックディレクタ（Oracle Traffic Director：ＯＴＤ）と通信して、指定サーバへのトラフィックを静止させる静止サーバ４２２；ホームディレクトリまたは他のストレージの（たとえばＯｒａｃｌｅホーム）シンボリックリンク（ｓｙｍｌｉｎｋ）を新たなターゲットを指すように変更する更新ホーム４２４；準備完了（レディ）アプリケーションまたは同様のフレームワークと通信し、すべての登録アプリケーションがレディ状態にある時にのみ完了するレディ確認アプリケーション４２６；および、たとえばＯＴＤと通信して、指定サーバへのトラフィックの送信を再開する起動サーバ４２８が挙げられ得る。

一実施形態に従うと、パッチオーケストレータを、そのプリミティブおよびワークフローとともに、パッチデータベース４４０と組合せて用いて、ソフトウェアコンポーネントまたはパッチのさまざまなバージョンをサポートすることができ、これは、たとえば、１つ以上の管理されるサーバ４５１について、初期のパッチ済バージョンまたは未パッチバージョン４５２から、後にパッチされたバージョン４５４への、１組のホームディレクトリまたは他のストレージをパッチまたは更新するために必要な情報４５０を含む。

たとえば、図６に示されるように、クラスタは上述のように管理されるサーバの２つのフェイルオーバーグループを含み得、第１のフェイルオーバーグループおよびその管理されるサーバ（ＭＳ１、ＭＳ２およびＭＳ３）の選択はホームディレクトリのパッチ済バージョンを使用し、第２のフェイルオーバーグループおよび他の管理されるサーバ（ＭＳ４、ＭＳ５およびＭＳ６）はホームディレクトリの初期バージョンまたは未パッチバージョンを使用する。

トラフィックディレクタまたはロードバランサからの要求は、フェイルオーバーグループ内の任意のサーバにフェイルオーバーし得る。以下にさらに説明するように、一実施形態に従うと、レイジーセッションデシリアライゼーション機能を用いて、２つのフェイルオーバーグループ、およびその中の管理されるサーバに跨り得る任意のセッションのフェイルオーバーをグレースフルに処理することができる。

図７は、一実施形態に従った、セッション処理のサポートを含むパッチングのためのシステムをさらに示す。

典型的なアプリケーションサーバ環境では、サーバインスタンスのシャットダウンおよびその後のリスタートには少しの時間が掛かり得、場合によっては数分も掛かり得る。これに対処するために、一実施形態に従うと、システムは、シャットダウン時に実行可能なよりスマートなセッション複製プロセスを含み、当該プロセスは、アクティブなセッションがシステム内のどこか別の場所で提供されているか否かを判断すること、および、提供されていない場合は、対象サーバをシャットダウンする前にセッションを使用可能にすることを含む。

図７に示されるように、一実施形態に従うと、トラフィックディレクタは、ロードバランシング４５２、５０３ヘッダ検出４５４、ダイナミックディスカバリ４５６、およびヘルスチェック４５８などの機能をサポートするのに対し；アプリケーションサーバクラスタ化環境４６０は、ダイナミックレイジーセッションデシリアライゼーション４６２、セッションフェッチング４６４、およびオーファンセッションクリーンアップ４６８などの機能をサポートし；ｗｅｂコンテナ４７０は、セッション互換性検出４７２などの機能をサポートし；サーバライフサイクルコンポーネント４８０は、シャットダウン時のセッション複製４８２、およびすべてのセッションの待機４８４などの機能をサポートする。

一実施形態に従うと、上記のコンポーネントの各々は以下により詳細に説明され、これは、パッチング前後にパッチングサポートを動的にオンおよびオフにすること；セッションフェッチング；複数のバックアップを回避するためのオーファンセッションクリーンアップ；１つのサーバがどのようにトラフィックディレクタに５０３メッセージを送信して当該ディレクタに異なるサーバを試みるように指示するかを含む、非互換性セッションの処理；ならびにアプリケーションサーバ、アプリケーション、または他のコンポーネントの複数のバージョンの処理などの、さまざまな状況に対処するための上記コンポーネントの使用を含む。

たとえば、一実施形態に従うと、システムは、新たなパーティションを作成し、当該新たなパーティションにおいてアプリケーションサーバ、アプリケーション、または他のコンポーネントの異なるバージョンをセットアップすることによって、当該アプリケーションサーバ、アプリケーション、または他のコンポーネントのさまざまなバージョンがさまざまなパーティションにデプロイされることを可能にする。トラフィックディレクタは、どのくらいのトラフィックおよび／またはどのタイプのトラフィックを、アプリケーションサーバ、アプリケーション、または他のコンポーネントの新バージョンに対して、アプリケーションサーバ、アプリケーション、または他のコンポーネントの旧バージョンにダイレクトすべきかを制御するように構成され得る。

アプリケーションの２つのバージョンのみがデプロイされ得る（かつアプリケーションの一方のバージョンはリタイアメント用にマークを付けられる必要がある）アプリケーションのプロダクション再デプロイメントとは異なり、一実施形態に従うと、システムは、アプリケーションの２つよりも多いバージョンを同時にデプロイしてアクティブにすることができ、唯一の要件は、それらが異なるパーティションにデプロイされることである。

一実施形態に従うと、システムはさらに、複数のテナントが基礎をなす論理を共有する能力をサポートし、特定のパッチレベルをクラスタレベルで維持するが、たとえば、いくつかのパーティションがその特定の時間に特定のパッチレベルをサポートできないと判断された場合はそれらのパーティションを必要に応じてさまざまなクラスタに移動させる。

同様に、一実施形態に従うと、システムは、試験するために１つのノードにおいてたとえばＯｒａｃｌｅホームのパッチングレベルバージョンを使用し、その後、試験が完了すると、Ｏｒａｃｌｅホームのそのバージョンを必要に応じて他のノードにロールアウトする能力をサポートする。

図８は、一実施形態に従った、セッション互換性検出のサポートを含むパッチングのためのシステムをさらに示す。

図８に示されるように、本明細書に示される一実施形態および例に従うと、クラスタ５００は、パッチ済サーバ５０２、使用不可能サーバ５０４、および未パッチサーバ５０６のグループを含む複数のグループで提供される、複数の管理されるサーバ（ここではＭＳ１〜ＭＳ５として示される）を含み得る。

一実施形態に従うと、管理されるサーバが使用不可能になる（ここでは取消し線が引かれたＭＳ３として示される）と、トラフィックディレクタ（たとえばＯＴＤ）は、ＭＳ３がダウンしていることを示すエラーメッセージ５１１を受信し得る。トラフィックディレクタは別の管理されるサーバＭＳ２にコンタクトすることを試み得（５１２）、サーバＭＳ２は、デシリアライゼーションエラーを検出すると、ｗｅｂコンテナに、たとえばFailoverGroupヘッダ情報を有する５０３メッセージを返信させる。トラフィックディレクタは、５０３ヘッダ情報に基づいて、今度は管理されるサーバＭＳ４にその要求を再試行し得る（５１３）。次いで、ＭＳ４におけるアプリケーションサーバは、ＭＳ２から適切なセッション情報をフェッチし（５１４）、最後に当該要求に応答し得る（５１５）。

一実施形態に従うと、プロセスは、以下にさらに説明するように、レイジーセッションデシリアライゼーション５１８機能の使用を活用し得る。

図９は、一実施形態に従ったパッチングのためのシステムをさらに示す。
図９に示されるように、一実施形態に従うと、システムは、ドメイン内の１つのクラスタが、たとえば異なるＯｒａｃｌｅホームなどの異なるホームディレクトリを使用すること、したがって異なるアプリケーションサーバ（たとえばＷＬＳ）バージョンまたはパッチバージョンを用いて動作することを可能にする。当該クラスタについて管理されるサーバは、同じドメインからの他のクラスタをサポートする任意の管理されるサーバと同じホスト上に存在していてもよいし、異なるホスト上に存在していてもよい。

特に、図９に示されるように、システムは、Ｃ１ ５３０、Ｃ２ ５３２およびＣ３ ５３４を含む複数のクラスタを含み得、その各々は、ここではパーティションＡ５６２、パーティションＢ５６４、パーティションＣ５６６およびパーティションＮ５６８として示される１つ以上のパーティション５５０、５５２、５５４を操作する。

一実施形態に従うと、パッチデータベース５４０は、ここではバージョンＡ５４２、バージョンＢパッチセット１（ＰＳ１）５４４、およびバージョンＢパッチセット２（ＰＳ２）５４６として示される、アプリケーションサーバ、アプリケーション、または他のコンポーネントの複数のバージョンについてのバージョンまたはパッチ情報を含み得る。

一実施形態に従うと、さまざまなパーティションがさまざまな時間にマイグレーションおよび／またはパッチされ得るため、たとえば、パーティションＡは、特定のアプリケーションサーバ（たとえばＷＬＳ）の第１のバージョンＡを有するクラスタＣ１から、当該アプリケーションサーバの異なるバージョンＢ ＰＳ１を有するクラスタＣ２にマイグレーションされ得る。同様に、パーティションＣは、アプリケーションサーバのバージョンＡを有するクラスタＣ１から、アプリケーションサーバのさらに別の異なるバージョンＢ ＰＳ２を有するクラスタＣ３にマイグレーションされ得る。

一実施形態に従うと、このパッチングプロセスのいくつかの利点として、個別のパーティションを、同じリソースを共有している他のパーティションに影響を与えることなく、アプリケーションサーバ、アプリケーション、または他のコンポーネントのより新しい（たとえばパッチ済）バージョン（たとえばＷＬＳのより新しいバージョン）にマイグレーションできることが挙げられる。パッチング処理はさらに、たとえば、ＷＬＳのパッチ済バージョンに対するＷＬＳアプリケーションサーバの初期バージョンのＡ／Ｂテスト、またはアプリケーションのさまざまなバージョンをＷＬＳの特定のバージョンで試験することを可能にする。

一実施形態に従うと、ある期間の間、パーティションは２つのクラスタ（たとえばソースおよびターゲットクラスタ）内で同時に「ライブである（live）」と見なすことができ、これによって任意の既存のセッションが完了またはタイムアウトすることができる。パーティションマイグレーションが完了すると、パーティションは次に、アプリケーションサーバ、アプリケーション、または他のコンポーネントの任意のより新しい（たとえばパッチ済）バージョンを含む、ターゲットクラスタ内でのみ使用可能にされる。

図１０は、一実施形態に従ったパッチングのためのシステムをさらに示す。
図１０に示されるように、一実施形態に従うと、１つ以上のコンピュータノード、または当該ノード上でアプリケーションサーバ、アプリケーション、もしくは他のコンポーネントが実行されているサーバをパッチするために、それらのノード上のサーバはまずグレースフルにシャットダウンされる。

５８０において、準備スイッチ（たとえばprepareSwitchOracleHome）プリミティブがパッチすべきノードまたはサーバにおいて呼出され、これは、そのノードまたはサーバ用のノードマネージャに、そのホームディレクトリ（たとえばＯｒａｃｌｅホーム）の切替えを実行することになるスクリプトをセットアップするように指示する。このステップを用いて、ノードマネージャが演算を実行するのに必要なパラメータがノードマネージャに与えられる。

５８２において、リスタートノードマネージャ（たとえばRestartNodeManager）プリミティブに対する呼出がなされ、これによって、そのノードにおけるノードマネージャは制御をスクリプト（たとえばswitchOracleHomeスクリプト）に転送し、当該スクリプトは次いで、現在のホームディレクトリ（たとえばＯｒａｃｌｅホーム）を指定ディレクトリパスに移動させ（５８３）、パッチ済のアプリケーションサーバ、アプリケーション、または他のコンポーネント画像を元の場所の中に抽出してから、ノードマネージャを再開する。

５８４において、アサートスイッチ（たとえばAssertSwitchOracleHome）プリミティブが実行され、これによって、ホーム（たとえばＯｒａｃｌｅホーム）ディレクトリの切替え５８５が成功裏に完了したことが確認される。

５８８において、開始サーバ（たとえばStartServers）プリミティブがノード毎またはサーバごとに呼出され、レディアプリケーション確認（たとえばReadyAppCheck）が成功裏に戻ってきて（そのように構成されている場合）初めて完了する。これによって、ワークフローがそれ以上のノードまたはサーバをシャットダウンする前に、そのノードにおけるパッチ済のアプリケーションサーバ、アプリケーション、または他のコンポーネントのすべてが確実に要求に応えることができ、制限されたダウンタイムまたはダウンタイムなし（すなわちゼロ）がサポートされる。

図１１〜図１２は、一実施形態に従ったパッチングのためのシステムをさらに示す。
図１１〜図１２に示されるように、例示的な実施形態に従うと、システムは、３つの物理マシンまたはノード（ここではコンピュータノード１〜３として示される）にわたって実行されるクラスタ６０４内の複数の管理されるサーバを含み得、管理サーバはそれ自体のマシン（ここでは管理ノード６００として示される）上で単独で実行されている。同じマシン上のクラスタ内の管理されるサーバの各対は、同じローカルドメインディレクトリおよび同じローカルホーム（たとえばＯｒａｃｌｅホーム）ディレクトリを共有している。各マシンは各自のノードマネージャを含む。

一実施形態に従うと、最初に、管理サーバおよび管理されるサーバは元のホームディレクトリを使用する（６０２、６０６、６０７、６０８）。パッチングプロセスは、管理される各サーバにパッチ済バージョンをコピーし；次いで（サービス中断なしで）管理サーバへのロールアウトを実行する（６１０）ことによって進行し得る。

一実施形態に従うと、管理されるサーバは、いくつかの管理されるサーバが一時的にシャットダウンされている間であっても、パッチされているアプリケーションサーバ、アプリケーション、または他のコンポーネントのフェイルオーバーを提供できるのに十分な数のマシンに十分に分散されている。管理されるサーバは次にパッチされ、パッチされた共有のストレージを指しているローリングリスタートが（６１６、６１７、６１８）次に実行される。このプロセスでは、状態複製のためにセッション損失が生じず、ダウンタイムが制限されるかなくなる（すなわちゼロ）。

例示的な実施形態
例示的な実施形態に従うと、アウトオブプレースパッチングは、クラスタ化に組込まれた既存の高可用性特徴を利用して、中断なしで動作するドメインの能力を維持する制御されたローリングリスタートにおいてパッチを適用する。プロセスは、複雑で長い実行タスクを自動化し、未パッチバージョン（または以前のバージョン）をロールバックのために保存し、回復不能エラーが起きた場合に自動復帰を提供することによって、エクスポージャを減らすように設計される。高レベルにおいて、プロセスは、ドメイン内のサーバによって使用されている単数または複数のＯｒａｃｌｅホームディレクトリをクローン化し；ゼロダウンタイム互換性パッチを複製ディレクトリに適用し；ロールアウトを処理するオーケストレーションタスクを開始することになっている。

一実施形態に従うと、ロールアウトタスクは、サーバごとに以下を順に調整する：共通のドメイン（ディレクトリ）を共有しているノード上のサーバをグレースフルにシャットダウンする；サーバと関連付けられたノードマネージャをリスタートする；現在のＯｒａｃｌｅホームディレクトリをバックアップ場所に移動させ、指定されたＯｒａｃｌｅホームディレクトリをその位置でデプロイする；および、サーバを開始し、そのように構成されている場合はReadyAppsCheckを待機する。

場合によっては、サーバの構成に基づいて、１つよりも多いサーバを一度にシャットダウンさせることが望ましい場合がある。任意の１つ時点でシャットダウンするサーバの数は、ロールアウトの影響を最小化するためにできるだけ小さく保つべきである。クラスタ内には、稼働中であり要求に応答可能な少なくとも１つのサーバが常にあることになる。

回復不能エラーが起こった場合、ロールアウトタスクは、当該タスクが行なったいずれの変更も自動的に復帰させるため、サーバはそれらの元の状態（以前のバージョン）に戻される。これによって、エラーが診断されて解決されている間、ドメインが完全に使用可能であることが確実になる。ロールバックは、元のＯｒａｃｌｅホームディレクトリを保存することによって可能となり、パッチが元のディレクトリではなくディレクトリを複製するために適用される理由の一部である。ロールバックプロセス時に、ロールバックの完了を妨げる別のエラーに遭遇した場合、エラーが発生し、調査を可能にするためにプロセスは停止する。エラーがクリアされると、復帰プロセスが再開され得る。

初期インストールおよび構成
一実施形態に従うと、アウトオブプレースパッチングを容易にするために、サーバにわたってアプリケーションサーバ（たとえばＷＬＳ）のインストールのために満たさなければならない要件がいくつかある。

ドメイン内には、Ｏｒａｃｌｅホームの場所が参照される多くの箇所が存在する。これは、開始スクリプト、プロパティファイル、およびｘｍｌ構成ファイル内の変数を含む。Ｏｒａｃｌｅホームの新たなバージョンを指すためにこれらの場所のすべてを見つけて更新することは概して実際的でない。このため、一実施形態に従うと、ロールアウトは、既存のＯｒａｃｌｅホームを（ユーザが指定したバックアップ場所に）移動させ、所望のＯｒａｃｌｅホームをその位置で拡張することによって機能する。このプロシージャが、まだ実行中の管理されるサーバに影響を与えないことを確実にするために、Ｏｒａｃｌｅホームディレクトリは、マシン上の影響を受けて管理されるサーバのすべてによって使用されなくてはならず、他のマシン上の管理されるサーバによって使用されてはならない。Ｏｒａｃｌｅホームはさらに、ノードマネージャプロセスによって書込可能な場所になければならない。これらの条件を保証するために、Ｏｒａｃｌｅホームディレクトリは、影響を受けて管理されるサーバにとってローカルなハードドライブ上にインストールされ得る。

サーバをアップグレードしつつアップタイムを維持するための鍵は、クラスタで構成された高可用性を利用することである。クラスタ内の最小数のサーバは常に動作可能でなければならない。同じマシン上のクラスタ内のサーバは（それらが共通のドメインディレクトリを共有している場合は）ともにリスタートされる必要があるため、クラスタ内のサーバは少なくとも２つの異なる物理マシン上でホストされることが必要であるが、クラスタごとに最低でも３つのマシンが推奨される。これによって、一部は稼働中でサービスを提供し続け、一部はローリングリスタートの一部として停止することができる。

要求を処理するために異なるマシン上で使用可能なサーバの数を判断する際、実行中であるが管理モードまたはスタンバイモードにある管理されるサーバは要求に応答しないため、これらのサーバを除外することが重要である。

ロールアウトプロセスは、管理サーバおよび管理されるサーバを同時に更新する必要がある場合は大幅に複雑化し得る。これが起こるのは、管理サーバおよび管理されるサーバが、同じマシン上で実行されて同じドメインディレクトリを共有するように構成されている場合であろう。管理サーバは、共有のＯｒａｃｌｅホームディレクトリから実行されているため、管理されるサーバと同時に停止しなければならない。管理されるサーバのインストールホームを分離して、管理されるサーバ単位でパッチをロールアウトできるようにした場合は、この制限は適用されない。このため、この問題を単純化する２つの異なる構成がサポートされる。

１．第１は、マシン上で実行されている管理されるサーバがない状態で、当該マシン上で管理サーバを実行することである。これによって、管理サーバを単独で１つのステップで更新することができ、それが完了すると、次のステップは、異なるマシン上のそのドメイン内の管理されるサーバを更新することである。

２．第２の構成は、管理サーバを管理されるサーバと同じマシン上で実行することを可能にするが、管理サーバにそれ自体の別個のドメインディレクトリを使い切らせることである。これによっても、管理サーバを個々に更新することが可能となり、管理されるサーバをそれら自体のステップで更新することができる。

ドメイン内のすべてのサーバを更新するメカニズムを提供することに加えて、この特徴は、ドメイン内の個々のクラスタを更新する能力も提供する。ユーザがクラスタロールアウトモードの使用を試みているとき、異なるクラスタにサーブする単一のノード上に複数の管理されるサーバがある場合、管理されるサーバは、それらがサーブしているクラスタに従って別個のドメインディレクトリを有する必要がある。また、それらのドメインディレクトリは別個のＯｒａｃｌｅホームディレクトリを指す必要があり、それらはノードマネージャの別個のインスタンスによって管理される必要もある。これは、一方のクラスタにサーブしている（かつまだ実行中である）管理されるサーバのＯｒａｃｌｅホームディレクトリに影響を与えることなく、他方のクラスタ用のノード上の管理されるサーバのすべてを停止させてそれらのＯｒａｃｌｅホームディレクトリを更新することができるようにするために必要である。

ドメイン内のさまざまな時間にさまざまなパーティションをパッチすることは、それ自体は明示的にサポートされていないが、パーティションを管理してクラスタレベルパッチングを使用することによって達成可能である。パーティションがその環境でどのように使用されるかに依存して、１つのパーティションをアップグレードすることなく別のパーティションをアップグレードすることが望ましい場合がある。この例は、各パーティションが異なるテナントによって使用中であり、一方のテナントをアップグレードする必要があるが、他方のテナントは使用可能なメンテナンスウィンドウを有していないという環境であり得る。この状況では、パーティションマイグレーション特徴を用いてパーティション同士を分離することができる。アップグレードが必要なパーティションは、異なるクラスタ（既存のまたは新たに作成された）にマイグレーションされ得、この新たなクラスタに対してクラスタレベルロールアウトが実行され得る。これを達成する最も単純な方法は、新たなクラスタが元のクラスタとは異なる物理マシン上でホストされており、ドメインディレクトリ、Ｏｒａｃｌｅホーム、およびノードマネージャがオーバーラップしないことが確実である場合である。使用可能な他の物理リソースがない場合、このプロシージャは、新たなクラスタがＯｒａｃｌｅホームディレクトリのそれ自体のコピーを指しているドメインディレクトリのそれ自体のコピーを有しており、ノードマネージャのそれ自体のインスタンスが影響を受ける各マシン上で実行されている限り、サポートされ得る。

一実施形態に従うと、ノードマネージャは、現在のＯｒａｃｌｅホームを指定されたバックアップディレクトリに移動させ、新たなＯｒａｃｌｅホームをその位置で抽出またはコピーする役割を果たす。また、ノードマネージャは、新たなディレクトリを使い切るためにリスタートさせる必要がある。これを調整するために、各ノードは各自のノードマネージャを有する必要がある。

たとえば、上述の図１０〜図１２では、システムは３つの物理マシンにわたって実行されている、クラスタ内の複数の管理されるサーバを含み、管理サーバはそれ自体のマシン上で単独で実行されている。同じマシン上のクラスタ内の管理されるサーバの各対は、同じローカルドメインディレクトリおよび同じローカルなＯｒａｃｌｅホームディレクトリを共有しており；各マシンの各自のノードマネージャは実行されている。

クローン化およびクローン化画像のパッチング
一実施形態に従うと、既存の画像をクローン化してクローン化画像をパッチするために、システムは、たとえば既存のＯｒａｃｌｅホームをクローン化するためのFMW Movementスクリプトの使用などの、既存のツーリングに依拠し得る。クローン化されたＯｒａｃｌｅホームができると、ユーザは次に既存のＯＰａｔｃｈツーリングを用いて画像をパッチすることができる。FMW Movementスクリプトを使用するＯｒａｃｌｅホームのクローン化の記述は以下に従う：
１．copyBinary.shを用いてＷＬＳインストールのアーカイブを作成する。

２．pasteBinary.shを新たなディレクトリに用いて、ＷＬＳインストールのクローンを作成する（中央インベントリファイルの更新）。クローンが作成されると、ユーザはオラクルユニバーサルインストーラ（Oracle Universal Installer）を実行し、クローンに中央インベントリが登録されたことを確認し得る。

自動化されたロールアウト
上述のように、一実施形態に従うと、ゼロダウンタイムで更新をロールアウトすることは、大部分はサーバクラスタ化の高可用性特徴を活用することによって可能となる。サーバクラスタ化を用いると、アプリケーションがダウンタイムを被ることなく、管理されるサーバの１つ以上をオフラインにすることができる。実際に、グレースフルサーバシャットダウンを用いると、ほとんどの場合、１つのセッションの損失さえも防止できる。サーバを停止させること、サーバを更新すること、およびサーバをサービス状態に戻すことの調整は、パッチングプリミティブと称されるカスタムコマンドを作成し、オーケストレーションフレームワークを用いてそれらを実行することによって処理され得る。コマンドはドメインのトポロジを分析し、次にサーバおよびノードマネージャのすべてを安全に更新する最良の方法を決定するのに対し；オーケストレーションフレームワークはプロセスのモニタリングおよびエラー処理を提供する。

一実施形態に従うと、このメカニズムが適切に機能するためには、アップグレード中のクラスタ内の管理されるサーバを２つ以上の物理マシンに分散する必要がある。この理由は、同じマシンによってホストされるクラスタ内のすべてのサーバは共通のドメインディレクトリを共有することになり、したがってともに停止させなければならないためである。ダウンタイムを回避するために、クラスタ内のサーバのいくつかは他のサーバと異なるマシン上で実行されなければならない。このように、要求に応えるために使用可能なサーバが常にいくつかある。

この技術によって導入される別の制約は、クローン化されたＯｒａｃｌｅホームに適用されるパッチが、サーバを、それらサーバが未パッチサーバとの互換性が依然としてある状態にしておかなければならないという要件である。より具体的には、パッチロールアウト時にサーバが故障した場合、ユーザのセッションはパッチ済サーバと未パッチサーバとの間でシームレスにマイグレーション可能でなければならない。

一実施形態に従うと、この態様でロールアウト可能な演算がいくつかある。これらは、パッチ済のＯｒａｃｌｅホームをロールアウトすること、サーバにわたってＪＡＶＡ（登録商標）＿ＨＯＭＥの場所を更新すること、アプリケーションを更新されたバージョンに置換すること、および単一のロールアウトにおけるそれらの演算の任意の組合せを含む。すべてのサーバにわたってローリングリスタートを実行する能力も提供される。

例示的なパッチングＡＰＩ
一実施形態に従って、アップグレードまたはパッチをロールアウトするために用いられ得る例示的なパッチングＡＰＩを以下に説明する。他の実施形態に従うと、異なるおよび／または付加的なパッチングＡＰＩがサポートされてもよい。

RolloutUpdateコマンド
一実施形態に従うと、rolloutUpdateコマンドは、サーバ上のＯｒａｃｌｅホーム、Ｊａｖａホーム、およびアプリケーションを更新する能力を提供する。また、当該コマンドは、オプションのパラメータのうちのどれが指定されているかに依存して、それらの変更の任意の組合せを可能にする。Ｏｒａｃｌｅホームを更新するためには、ユーザはrolloutOracleHomeパラメータ、backupOracleHomeパラメータ、およびisRollbackパラメータを指定する必要がある。Ｊａｖａホームを更新するためには、ユーザはjavaHomeパラメータを指定する必要がある。アプリケーションを更新するためには、ユーザはapplicationPropertiesパラメータを指定する必要がある。isDryRunおよびautoRevertOnFailureオプションはすべての場合に有効であり、isSessionCompatibleオプションは、アプリケーションおよび／またはＯｒａｃｌｅホームが修正中である場合にのみ考慮される。単一のロールアウト時にどの更新が実行可能であるかについての制限はない。ユーザがOracle Homeパラメータ、JavaHomeパラメータ、またはApplicationPropertiesパラメータを指定しない場合は、ローリングリスタートが実行される。

シンタックス
rolloutUpdate(target, [rolloutOracleHome, backupOracleHome, isRollback], [javaHome], [applicationProperties], [options])

例
新たなパッチ済のＯｒａｃｌｅホームをロールアウトする：

元のＯｒａｃｌｅホームにロールバックする：

Ｊａｖａの新たなバージョンのみをロールアウトする：

アップグレードされたアプリケーションのみをロールアウトする

新たなパッチ済のＯｒａｃｌｅホームをＪａｖａの新たなバージョンでロールアウトする

新たなパッチ済のＯｒａｃｌｅホーム、Ｊａｖａの新たなバージョン、およびアップグレードされたアプリケーションをロールアウトする

RolloutOracleHomeコマンド
一実施形態に従うと、rolloutOracleHomeコマンドは、Ｏｒａｃｌｅホームを更新する能力を提供する。rolloutOracleHomeタスクは、どのサーバをどの順序で更新する必要があるかを理解し、それらを安全に更新するワークフローを作成する役割を果たす。これは、サーバのグレースフルシャットダウン、Ｏｒａｃｌｅホームディレクトリの置換、ノードマネージャのリスタート、およびサーバの再開を含む。ロールアウトタスクは、ステータスがポーリングされ得るWorkflowProgressMBeanを返す。

シンタックス
rolloutOracleHome(target, rolloutOracleHome, backupOracleHome, isRollback, [options])

例
パッチ済のＯｒａｃｌｅホームをロールアウトする

RolloutJavaHomeコマンド
一実施形態に従うと、rolloutJavaHomeコマンドは、影響を受けるサーバが使用するＪａｖａホームを更新する能力を提供する。rolloutJavaHomeタスクは、どのサーバをどの順序で更新する必要があるかを理解し、それらを安全に更新するワークフローを作成する役割を果たす。これは、サーバのグレースフルシャットダウン、サーバが使用するＪａｖａホームの場所の更新、ノードマネージャのリスタート、およびサーバの再開を含む。このタスクは、ステータスがポーリングされ得るWorkflowProgressMBeanを返す。

シンタックス
rolloutJavaHome(target, javaHome, [options])

例
ドメイン内のすべてのサーバ上のＪａｖａホームを更新してｊａｖａの最新のインストールされたバージョンを使用する：

RolloutApplicationsコマンド
一実施形態に従うと、rolloutApplicationsコマンドは、サーバ上にデプロイされたアプリケーションを更新する能力を提供する。rolloutApplicationsタスクは、どのサーバをどの順序で更新する必要があるかを理解し、それらを安全に更新するワークフローを作成する役割を果たす。これは、サーバのグレースフルシャットダウン、アプリケーションの更新、ノードマネージャのリスタート、およびサーバの再開を含む。このタスクは、ステータスがポーリングされ得るWorkflowProgressMBeanを返す。

シンタックス
rolloutApplications(target, applicationProperties, [options])

例
アップグレードされたたアプリケーションをロールアウトする

RollingRestartコマンド
一実施形態に従うと、rollingRestartコマンドは、サーバを順次にリスタートする能力を提供する。rollingRestartタスクは、どのサーバをリスタートする必要があるかを理解し、それらを安全にリスタートするワークフローを作成する役割を果たす。これは、サーバのグレースフルシャットダウンおよびサーバの再開を含む。このタスクは、ステータスがポーリングされ得るWorkflowProgressMBeanを返す。

シンタックス
rollingRestart(target, [options])

例
ドメイン内のすべてのサーバのローリングリスタートを行なう

Ｊａｖａホームの更新
一実施形態に従うと、ゼロダウンタイムパッチング特徴は、指定されたターゲット内のサーバについてＪＡＶＡ＿ＨＯＭＥ設定を更新するためのメカニズムを提供する。このプロセスを開始する方法は２つあり、１つはスタンドアローンコマンドrolloutJavaHomeを用いることであり、もう１つは任意のjavaHomeパラメータをrolloutUpdateコマンドに対して指定することによるものである。後者を用いる場合、同じロールアウトにおいてＯｒａｃｌｅホームおよび／またはアプリケーションを更新することができる。ＪＡＶＡ＿ＨＯＭＥを設定する機能は、Ｏｒａｃｌｅホームまたはアプリケーションもアップグレードされるか否かに係わらず同一である。

一実施形態に従うと、Ｏｒａｃｌｅホームを更新するための上記のトポロジ前提条件は、Ｊａｖａホームの更新にも適用される。さらに、この機能を提供できるようにするために、指すべきＪＡＶＡ＿ＨＯＭＥを設定するＪａｖａのバージョンは、ローカルにアクセス可能などこかに既にインストールされていること、および影響を受けるすべてのサーバにとってＪＡＶＡ＿ＨＯＭＥへのパスが同じであることが必要である。サーバをシャットダウンする前にＪａｖａをインストールすることは、Ｊａｖａの各バージョン（現バージョンおよび新バージョン）がそれらへの別個の固有のパスを有する必要があることを意味する。

一実施形態に従うと、Ｊａｖａホームの変更をロールアウトするために、同じＯｒａｃｌｅホームを共有しているマシン上のすべてのサーバを、そのマシン上で実行されているノードマネージャとともに、一緒にシャットダウンしなければならない。それらがシャットダウンされている間、ネイティブスクリプトがpasteBinaryの特別なフォームを用いて、Ｏｒａｃｌｅホームディレクトリ内のすべてのスクリプトを更新して新たなＪＡＶＡ＿ＨＯＭＥ場所を用いる。Ｊａｖａ更新スクリプトは次にドメインディレクトリ内の必要な開始スクリプトを修正し、さらに、ＪＡＶＡ＿ＨＯＭＥへの新たなパスを用いる。次いで、ノードマネージャおよびそのマシン上のサーバが再開される。ＪＡＶＡ＿ＨＯＭＥの参照を含むＯｒａｃｌｅホームの下のすべてのスクリプトは、指定されたＪＡＶＡ＿ＨＯＭＥを指す。ＪＡＶＡ＿ＨＯＭＥの参照を含む現在のドメインディレクトリの下のすべてのスクリプトは、指定されたＪＡＶＡ＿ＨＯＭＥを指す。

成功裏に実行されたＪａｖａホームの変更をロールバックする最も簡単な方法は、古い場所を新たなパスとして、新たなupdateJavaHomeコマンドを単に実行することである。しかし、いくつかのインスタンスにおいては、システムは、Ｊａｖａホームも変更したＯｒａｃｌｅホーム変更のロールバックもサポートする。Ｏｒａｃｌｅホームスクリプトをそれらの元の状態に戻すことは、Ｏｒａｃｌｅホームディレクトリを以前の状態に復元する固有の部分として起こる。ユーザはロールバックコマンドを発行する際に元の（所望の）Ｊａｖａホーム場所を指定していない可能性があるため、ドメインスクリプトをロールバックすることはこれほど単純でない場合がある。この問題に対処するために、updateOracleHomeコマンドは、Ｏｒａｃｌｅホームディレクトリがバックアップ場所に移動すると、当該ディレクトリが、更新時に関連のドメインスクリプトの現バージョンのコピーを保持する「domainBackup」と称される付加的なディレクトリをさらに含むように、適合され得る。このように、ユーザが将来、本願のバックアップされたＯｒａｃｌｅホーム場所からロールバックコマンドを実行する場合、それらのドメインファイルを所定の位置にコピーバックすることができる。

アプリケーションの更新
上述のように、一実施形態に従うと、ゼロダウンタイムパッチング特徴は、アプリケーションサーバにデプロイされたアプリケーションを更新するためのメカニズムも提供する。このための１つのメカニズムは、それらをＯｒａｃｌｅホームディレクトリに含み、そこからそれらを非ステージデプロイすることである。このようにデプロイされたアプリケーションの更新は、Ｏｒａｃｌｅホームの新バージョン（更新されたアプリケーションが含まれる）がロールアウトされるときに起こる。このようにデプロイされたアプリケーションは、ロールアウトされている新たなＯｒａｃｌｅホームとともに含まれている最新バージョンを有すること以外は、付加的な情報またはステップが不要である。Ｏｒａｃｌｅホームディレクトリの外部のアプリケーションを更新するためのプロセスは、ステージされたアプリケーションと、ステージされていないアプリケーションとでは異なるが、いずれの場合も、現在のアプリケーションディレクトリの場所を突き止めること、そのディレクトリをバックアップ場所に移動させること、およびアプリケーションの新バージョンを含むアプリケーションディレクトリを元の場所の中に移動させ、旧アプリケーションコードを新アプリケーションコードに本質的に置換することを含む。この動作は元のディレクトリがアクセスされている間は実行できないため、影響を受けるサーバはこのプロシージャの間はシャットダウンしなければならない。しかし、ノードマネージャはアプリケーションコードから独立しているため、このプロセスは（ＯｒａｃｌｅホームまたはＪａｖａホームの更新とは異なり）ノードマネージャがまだ実行中である間に行われ得る。新たなＯｒａｃｌｅホームのロールアウトと同様に、いくつかの準備が必要である。たとえば、新たなアプリケーションコードを含むディレクトリは、ロールアウトが開始される前に、影響を受けるすべてのノードに分散されなくてはならず、かつ、ノードごとに同じパス内になくてはならない。

図１３〜図１５は、一実施形態に従ったパッチングイベントダイヤグラムを示す。
ステージされたアプリケーション、非ステージアプリケーション、および外部ステージアプリケーションは異なってデプロイされるという事実のために、それらは適切に更新されるために異なる処理を必要とする。すべてのモードにおいて、新たなアプリケーションソースは管理サーバ上のディレクトリとして提供される必要がある。非ステージモードおよび外部ステージモードでデプロイされるアプリケーションについては、新たなアプリケーションソースも、それが管理サーバ上にあるのと同じパス内で各ノードに予め分散される必要がある。

ステージされたモード
管理ノード６２０および管理サーバ６２２と、ノードマネージャ６２４および２つの管理されるサーバ（ここではＭＳ１およびＭＳ２として示される）を含むノード１との間のインタラクションを示す図１３に示されるように、ステージされたモードの一実施形態に従うと、ステージモードでアプリケーションを実行するサーバは、それらのソースを管理サーバから直接取得する。アプリケーションを更新するために、まずソースを管理サーバ上で更新する必要があり、次に、サーバが管理モードにある間、そのソースを更新して変更を適切にピックアップするようにソースをトリガするために特定のターゲット再デプロイが各々について個々に呼出される。この演算グループは、整合性のために共通のクラスタ内の共通のマシン上でともにサーブする。

非ステージモード
管理ノード６３０および管理サーバ６３２と、ノードマネージャ６３４および２つの管理されるサーバを含むノード１との間のインタラクションを同様に示す図１４に示されるように、非ステージモードの実施形態に従うと、非ステージアプリケーションは、サーバが開始されるとサーバのマシン上のディレクトリからロードされる。ここでアプリケーションコードを更新するために、同じアプリケーションディレクトリを指しているそのマシン上のすべてのサーバを同時にシャットダウンする必要がある。次いで、ディレクトリのコンテンツが脇に移動し、アプリケーションのより新しいバージョンに置換され得る。この更新はディレクトリを置換することによってなされるため、システムは、非ステージアプリケーションについて共有のストレージディレクトリを使用することをサポートし得ない。サポートすると、依然としてディレクトリからアプリケーションを実行している他のサーバにとって問題が生じるためである。次いで、影響を受けるサーバが管理モードで開始され、特定のターゲット再デプロイコマンドが、変更をピックアップするように個人ごとに発行される。

外部ステージモード
管理ノード６４０および管理サーバ６４２と、ノードマネージャ６４４および２つの管理されるサーバを含むノード１との間のインタラクションを同様に示す図１５に示されるように、外部ステージモードの実施形態に従うと、外部ステージアプリケーションは、それらのアプリケーションソースがワークフローによって更新される必要があるという点で非ステージアプリケーションと同様である。しかし、主な相違点は、外部ステージアプリケーションソースディレクトリはサーバのステージングディレクトリ内にあり、このため、各サーバは更新すべきディレクトリのそれ自体のコピーを有していることである。ワークフローは、他のステージモードと同様に、共通のマシン上のサーバをともにシャットダウンしてから、影響を受ける各サーバのステージディレクトリを更新した後にそれを管理モードで開始し、特定のターゲット再デプロイを用いて、変更をピックアップするようにサーバをトリガする。

上記のプロセスが機能するためには、アプリケーションコードの置換は、サーバがシャットダウンされる際に当該サーバについてのみ行なわなければならない。したがって、同じアプリケーションディレクトリを共有しているいずれのサーバも同時にシャットダウンしなければならない。これによって、サーバが、アプリケーションディレクトリについて共通の共有ストレージ場所を使用することが防止される。各マシンは、アプリケーションディレクトリのローカルコピーと、新たなアプリケーションディレクトリのローカルコピーとを有する必要がある。新たなアプリケーションディレクトリへのパス、現在のアプリケーションディレクトリ、およびバックアップ場所は、影響を受けるすべてのサーバについて同一でなければならない。また、アプリケーションはＯｒａｃｌｅホームディレクトリ内に存在することはできない。

ロールアウトが進行するにつれて、かつサーバが依然として要求に応えている間に、アプリケーションの変更は交互にサーバにわたってロールアウトされるため、ロールアウトが開始される前に作成されたセッションは、アプリケーションのより新しいバージョンとの互換性がない可能性がある。これによって、セッションがロールアウト時にどのように処理されるのか、およびサーバがどのようにシャットダウンされるのかが多少複雑化するが、これはアプリケーションの更新をサポートするコマンド内のisSessionCompatibleフラグを用いることによって対処され得る。アプリケーションの旧バージョンとアプリケーションの新バージョンとの間のセッション同士が互換性がある場合、一定のセーフガードは不要であり、ロールアウトはより効率的に完了する。

一実施形態に従うと、ユーザから３つの情報が概して必要である：アプリケーション名（構成内のより多くの情報を調べるために用いられる）；新たな／パッチ済のアプリケーションコードの場所（ローカルディレクトリである必要がある）；および現在のアプリケーションディレクトリがバックアップされることになる場所（これもローカルディレクトリである必要がある）。現在のアプリケーションソース場所およびステージモードは、各サーバおよびそのアプリケーションの構成に基づいてワークフローによって計算することができる。

この減少した一組の情報でさえも、コマンドラインについて指定する際には扱いにくい場合がある。これに対処するために、一実施形態に従うと、情報は、コマンドが実行されるとコマンドが情報を読むことができる場所に、コマンドを発行する前にユーザによってテキストファイルで入れられ得る。それぞれのコマンドについてのコマンドライン引数は単純にこのファイルへのパスである。

さまざまな実施形態に従うと、ファイルを定義するさまざまなフォーマットを用いることができ、主な考慮事項は、人がファイルを生成することになるため、ファイルが人に優しい必要があることである。たとえば、ＪＳＯＮは人間が読取可能な適切なバランスであり、容易に認識でき、ユーザが各アプリケーションのプロパティに同じ名前を用いることを可能にし、一般的に公知でパースしやすいという付加的な利点がある。

ローリングリスタート
一実施形態に従うと、ゼロダウンタイムパッチング特徴は、１組のサーバを１つずつリスタートするためのメカニズムを提供する。サーバまたはＯｒａｃｌｅホームまたはドメインディレクトリ上で行なわれている構成の変更はないため、共通のＯｒａｃｌｅホームディレクトリから実行される同じマシン上に複数のサーバがある場合でも、サーバは１つずつ停止される。また、この理由のために、ワークフローに失敗があった場合、以前に影響を受けたサーバに復元する元の状態がないため、ワークフローは復帰しない。

進行モニタリング
一実施形態に従うと、ＷＬＳＴロールアウトコマンドは、ロールアウトタスクの進行を監視するために問合せられ得るWorkflowProgressMBeanを返す。

ロールアウト実装
一実施形態に従うと、この特徴は、ロールアウトタスクを達成するためにいくつかの高レベル演算またはパッチングプリミティブを導入する。これらの演算は、インターフェイスがワークフローにおいて管理され得るように、オーケストレーションフレームワークからインターフェイスを実装する。パッチングプリミティブは、さらに高レベルのパッチングプリミティブによって呼出され得る。たとえば、PatchNodeプリミティブは、ShutdownServer、およびPrepareSwitchOracleHome、RestartNodeManager、AssertSwitchOracleHome、およびStartServerなどの他のプリミティブを呼出し得る。

一実施形態に従うと、ロールアウトＷＬＳＴ呼出は、PatchingFacadeMBeanを用いてワークフローを作成し、それを実行のためにワークフローライフサイクルマネージャ（たとえばWorkflowLifecycleManager）に渡す。ワークフローは、たとえば、RolloutDirectory；ともにアップグレードされる必要があるサーバグループ（同じクラスタ、同じマシン）を判断するCheckPrerequisites；および、サーバグループごとに：サーバごとにShutdownServer（グレースフルに）、ノードについて一度のPrepareSwitchOracleHome、ノードについて一度のRestartNodeManager、ノードについて一度のAssertSwitchOracleHome、およびサーバごとにStartServerなどのプリミティブを組込む。

一実施形態に従うと、PatchServerプリミティブは一度に１つのサーバをパッチするのに使用可能である。しかし、Ｏｒａｃｌｅホームをロールアウトすると、ディレクトリを共有するノード上のすべてのサーバに影響を与えるため、影響を受ける各ノード上にすべてのサーバを含むことが必要である。これは、他のコンポーネントが使用するために、または部分的なロールアウトから回復するために提供される。それは、影響を受ける単一のサーバについて以下のプリミティブを呼出す：サーバごとにShutdownServer（グレースフルに）、ノードについて一度のPrepareSwitchOracleHome、ノードについて一度のRestartNodeManager、一度のAssertSwitchOracleHome、およびサーバごとにStartServer。

一実施形態に従うと、Ｏｒａｃｌｅホームディレクトリが新たな画像に置換される方法は以下を含む：１．サーバがグレースフルにシャットダウンされる；２．prepareSwitchOracleHomeプリミティブが呼出される。このプリミティブは、そのノード用のノードマネージャに、Ｏｒａｃｌｅホームディレクトリの切替えを行なうことになるスクリプトをセットアップするように命じる。このステップは、ノードマネージャが演算を行なうために必要なすべてのパラメータをノードマネージャがどのように取得するかである；３．次のステップは、RestartNodeManagerプリミティブを呼出すことである。これによって、ノードマネージャが制御をswitchOracleHomeスクリプトに転送する。そのスクリプトは、現在のＯｒａｃｌｅホームを指定されたディレクトリパスに移動させ、新たな画像を元の場所の中に抽出してからノードマネージャを再開する；４．実行すべき次のプリミティブは、AssertSwitchOracleHomeプリミティブである。このプリミティブは、Ｏｒａｃｌｅホームディレクトリの切替えが成功裏に完了したことを確認する；そして、５．呼出される最後のプリミティブはStartServersである。これはサーバごとに呼出され、ReadyAppCheckが成功裏に戻ってきて（そのように構成されている場合）初めて完了する。これによって、ワークフローがそれ以上のサーバをシャットダウンする前に、すべてのアプリケーションが確実に要求に応えることができる。

エラーおよび失敗処理
ローリングリスタートを調整してＯｒａｃｌｅホームディレクトリを更新するためのオーケストレーションフレームワークを用いる利点の１つは、プロセスが多くのステップを含み得、数時間掛かり得ることである。必要なステップを手動で実行することは面倒で時間が掛かるため、エラーおよび非効率に繋がりやすい。プロセスを自動化することによって、引起こされるヒューマンエラーの機会が減少し、プロセスを実行するのに必要な時間をより効率的に使用でき、いくつかの失敗処理オプションが提供され、最悪の場合、その変更のすべてをそれらの元の状態に自動的に復帰させることができる。

一実施形態に従うと、複数のコマンド（または他のプリミティブ）で構成されるプリミティブを実行する際、失敗を処理可能な方法がいくつかある。個々のコマンドの失敗は、プリミティブを構成するのに用いられる設定に従って無視または再試行され得る。論理復帰演算（ファイルを新たな場所に移動させた後にその元の場所に戻すなど）を有する各プリミティブは、CommandRevertInterfaceを用いて復帰挙動も定義し得る。回復不能エラーに遭遇した場合（ロールアウト演算の完了の成功を妨げ、再試行後に成功しないエラー）、完了したステップが、当該ステップが完了したのと逆の順序で復帰される。この復帰段階時にさらなる失敗に遭遇すると、復帰プロセスは停止し、問題はオペレータによって手動で解決されなければならない。

一実施形態に従うと、ユーザはさらに、失敗が起こった場合にワークフローが自動的に復帰すべきでないと指定することができ、これによって、ワークフローの進行を妨げた問題を修正する機会がユーザに与えられる。ユーザがこれを行なうことができる場合、ユーザは次に、停止したワークフローに対する実行方法を呼出すことができ、当該方法はその最後に成功裏に完了したコマンドから進む。ユーザが、ワークフローの失敗の原因となったエラーをクリアすることができない場合、ユーザは、ワークフローを復帰させるために、停止したワークフローに対して復帰を呼出すことができ、その最後に成功裏に完了したコマンドで開始する。また、ワークフローは、それに対するキャンセルを呼出すことによって、または復帰時に回復不能エラーに遭遇することによって停止され得る。

ロールバック
状況によっては、Ｏｒａｃｌｅホームのパッチ済バージョンがドメイン内のすべてのサーバに成功裏にロールアウトされるが、パッチ済バージョンとともに実行した後に、パッチ自体の問題が発見される場合がある。この場合、更新をロールバックし、すべてのサーバを以前のバージョンに戻すことが望ましい場合がある。一実施形態に従うと、この演算はロールアウトプロセスを再び実行することによって、しかし前のバージョンをターゲットバージョンとして用いることによって達成され得る。管理サーバが常に確実に最高パッチレベルにあるようにするために、これは、以前のパッチをまずクラスタに、次に個々に管理サーバにロールアウトすることによってなされるべきである。バージョンをロールバックすることには潜在的な問題がいくつかある。たとえば、より新しいバージョンに導入された特徴についての構成情報が損失する可能性があり、スキーマチェンジを取消すとトランザクションデータが損失する可能性がある。

パッチングファサード
一実施形態に従うと、システムはパッチングファサード（facade）（ＰＯＪＯとして）およびPatchingFacadeMBeanの両方を提供し得る。MBeanバージョンは非MBeanバージョンへのパススルーとして機能するが、進行オブジェクトをpojoのものではなくMBeanのものとして返す。ファサードにおける方法は、オーケストレーションフレームワークの知識をカプセル化し、これは、PatchingWorkflowBuilderにおける適切な方法を呼出して、WorkflowLifecycleManagerに進入するWorkflowBuilderを作成することを担当することを含む。露出したパッチングプリミティブごとに、他のコンポーネントが当該プリミティブを直接呼出すことを可能にする方法が、WorkflowBuildersを作成してプリミティブのいくつかを組合せる高レベル呼出しとともに提供され得る。アクティブな、かつ完了したワークフローのリストの問合せを可能にし、ワークフローの名前からワークフローの進行を調べるための方法も提供され得る。ワークフローは開始されると呼出側によって名前を割当てられ、名前は、ワークフローを特定してその進行を問合せるために用いられ得るため、固有でなければならない。

パッチングプリミティブ
一実施形態に従うと、パッチングプリミティブは、アウトオブプレースパッチングソリューションが必要とするローリングリスタートをグレースフルに実行するために必要な演算である。下には、各プリミティブのリスト、およびそれが何を行なうかの説明、それがどのフォールトトレランスメカニズムをサポートするか、およびそれが必要とする属性がある。

Support for retry（再試行のサポート）−これは、プリミティブが、最初に失敗した場合に再試行されるべき挙動を有している場合は真である。これは、次のサービスなど、移行中の可能性がある別のオブジェクトの状態に依存するプリミティブについて、または信頼性のない接続などの間欠的な失敗を処理するために用いられ得る。

Support for revert（復帰のサポート）−これは、プリミティブが、それが属するワークフローが復帰中である場合に実行され得る論理「取消」演算を有する場合は真である。プリミティブが復帰の事例について任意の特別な挙動を定義している場合、それはここに記述される。

Customized resume（カスタマイズされた再開）−ワークフローは、それが管理サーバリスタートのために一時停止した後に再開され得る。標準的な再開機能を無効にし、場合によってはいくつかの前提条件が依然として当てはまることを再確認する機会をプリミティブ与えるインターフェイスが存在する。プリミティブが再開の事例について任意の特別な挙動を定義している場合、それはここに記述される。

Ignore failures（失敗を無視）−これは、ワークフローの一部として実行されるが、プリミティブが成功裏に完了しない場合はワークフローを復帰させるべきでないプリミティブについて真である。これは、ワークフローの成功にとって絶対不可欠でない演算を試みるプリミティブによって用いられ得る。

一実施形態に従うと、各プリミティブはisDryRunと称されるフィールドも確認する。このisDryRunフィールドが真に設定されている場合、プリミティブは、プリミティブが実際には実行しないが実行したであろう作業をログ記録する。プリミティブはさらにいくつかの整合性確認を実行するが、このモードでは適用できない整合性確認もある。たとえば、StartServerプリミティブは、StopServerプリミティブがサーバを実際にシャットダウンしたことを予期できないため、サーバが停止したことを確かめる確認を実行しない。

一実施形態に従うと、アドミニストレータが、起こり得る任意のエラーを診断し、どのプリミティブがどのノードおよびサーバに対して実行されたかを見直すのを助けるために、各プリミティブは、トップレベルワークフローのワークフローｉｄ、実行中のプリミティブのタイプ、および影響を受けるターゲットを、その他の関連の情報とともに示す少なくとも１つのログメッセージをサーバログに出力することが必要である。

例示的なパッチングプリミティブ
一実施形態に従って、アップグレードまたはパッチをロールアウトするために用いられ得る例示的なパッチングプリミティブを以下に説明する。他の実施形態に従うと、異なるおよび／または付加的なパッチングプリミティブがサポートされてもよい。

シャットダウンサーバ
一実施形態に従うと、このプリミティブは、指定された管理されるサーバをグレースフルにシャットダウンする。これは概して、プロセスにおける作業がグレースフルに処理されることを可能にしつつ、管理されるサーバが「RUNNING（実行中）」から「SHUTDOWN（シャットダウン）」状態に移行する、長い実行プロセスである。プリミティブは基本的に、ＷＬＳにおけるグレースフルシャットダウン特徴に依拠する。サーバを実際にシャットダウンする前に、プリミティブはサーバの現在の状態を取得し（それがRUNNING（実行中）、SHUTDOWN（シャットダウン）、ADMIN（管理）、またはSTANDBY（スタンバイ）のいずれかにかかわらず）、lastServerStateと称される共有の状態属性を更新する。これは、サーバがそもそも開始されるべきであるか否かを判断するためにStartServerプリミティブによって用いられる。ShutdownServerプリミティブが実行されたときにサーバが停止されていると、StartServerプリミティブはサーバを開始しない。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

UpdateOracleHomeDirectory
一実施形態に従うと、このプリミティブは、Ｏｒａｃｌｅホームディレクトリを新ディレクトリのコンテンツに更新する作業を実行する。現在のＯｒａｃｌｅホーム場所から実行されるいずれのプロセスも、まずシャットダウンすべきである。ノードマネージャは、外部スクリプトに制御を引渡し、外部スクリプトは新たなディレクトリが所定の位置に置かれると当該ディレクトリから制御をリスタートする。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

PrepareSwitchOracleHome
一実施形態に従うと、このプリミティブは、Ｏｒａｃｌｅホームディレクトリを置換してノードマネージャをリスタートするために用いられることになるスクリプトをセットアップするためにノードマネージャが必要とするパラメータをノードマネージャに与える。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

AssertSwitchOracleHome
一実施形態に従うと、このプリミティブは、Ｏｒａｃｌｅホームが成功裏に更新されたことを確認するために、ノードマネージャがリスタートした後に用いられる。これは、更新が成功した場合は真を返すが、そうでなければ失敗する。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

StartServer
一実施形態に従うと、このプリミティブは（新たなパス場所を用いて）管理されるサーバを開始する。サーバは、ここに述べられるようにSTANDBY、ADMINまたはRUNNINGモードで開始するように構成され得る。この情報は構成内に持続され、サーバが次に（再び）開始されるときに用いられる。サーバは、このプリミティブを通して開始されると、サーバが開始されるように構成されているいずれかのモードに自動的に移行する。デフォルトサーバ始動状態はRUNNINGである。

一実施形態に従うと、このプリミティブはさらにlastServerState共有属性の値を確認し、ShutdownServerプリミティブが呼出されたときにサーバが既にSHUTDOWN状態にあったかどうかを確かめる。既にSHUTDOWN状態にあった場合、元の状態を保存したいため、StartServerプリミティブはサーバを開始しない。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

RestartNodeManager
一実施形態に従うと、このプリミティブはノードマネージャをリスタートする。Ｊａｖａベースのノードマネージャプロセスは、startNodeManagerスクリプトが認識する特定のリターンコードで出る。このリターンコードを見ると、startNodeManagerスクリプトはupdateOracleHomeスクリプトをキックオフする。そのスクリプトはドメインディレクトリ内に存在しており、現在のＯｒａｃｌｅホームディレクトリを指定されたバックアップ場所に移動させ、（新たなディレクトリがディレクトリではなくアーカイブである場合はpasteBinaryを用いて）新たなＯｒａｃｌｅホームディレクトリを所定の位置に移動させる役割を果たす。次いで、当該スクリプトは新たなＯｒａｃｌｅホームディレクトリからノードマネージャを開始する。updateOracleHomeスクリプトは、アーカイブを抽出するエラーまたは新たなディレクトリを所定の位置に移動させるエラーに遭遇した場合、元のディレクトリを所定の位置に戻し、ノードマネージャを開始する。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

ExecScript
一実施形態に従うと、このプリミティブは指定されたマシン上のdomain/bin/patchingディレクトリからカスタムスクリプトを実行する。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

UpdateNodeDirectory
一実施形態に従うと、このプリミティブは、個々のノードについてＯｒａｃｌｅホームディレクトリを更新するために必要なすべてのプリミティブを呼出す。それは、ShutdownServer、UpdateOracleHomeDirectory、PrepareSwitchOracleHome、AssertSwitchOracleHome、RestartNodeManager、StartServerを呼出す。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

RolloutDirectory
一実施形態に従うと、これは、ドメインまたはクラスタにわたってＯｒａｃｌｅホーム更新をロールアウトするための主要なトップレベルプリミティブである。それは、ロールアウトが成功するようにすべての他のプリミティブを調整する。それは、ロールアウトモードを考慮に入れて、どのサーバを更新すべきかを判断し、サーバおよびノードマネージャが正しい順序で更新されるようにする。それは、それ自体の成功を妨げ得るいずれかの構成問題を迅速に見つけることを試みて、checkPrerequisitesを第１のステップとして呼出す。次いで、それは、正確な順序でノードごとにUpdateNodeを呼出す。

パラメータ
プリミティブに対するパラメータは、任意の共有される状態オブジェクトと同様に、名前で渡される。名前によるパラメータおよび共有の状態オブジェクトの表を以下に示す。

フォールトトレランスサポート

シンボリックリンク
典型的なシステムにおいて、ドメイン内には、Ｏｒａｃｌｅホームの場所が参照される多くの箇所が存在し得る。これは、開始スクリプト、プロパティファイル、およびｘｍｌ構成ファイル内の変数を含む。一実施形態に従うと、Ｏｒａｃｌｅホームディレクトリへのパス内にシンボリックリンクを用いることによって、システムは単にシンボリックリンクを変更するだけでＯｒａｃｌｅホームの場所を更新することができる。このように、システムは、パスを変更するときにパスを参照するすべてのファイルを追跡して更新しなくてもよい。各ノード上で、Ｏｒａｃｌｅホームを含む共有のストレージは、共有のストレージデバイス上の共通ディレクトリ内にインストールされた複数のアプリケーションサーバ（たとえばＷＬＳ）バージョンを潜在的に露出するレベルでマウントされる。このように、新たなＯｒａｃｌｅホームディレクトリが作成されてパッチされ得、これらのいずれのノード上のマウントポイントも変更することなく使用可能になる。ｓｙｍｌｉｎｋは、アプリケーションサーバの特定のバージョンをマウントディレクトリを通して指すように作成される。

共有ストレージ上のホーム
一実施形態に従うと、ロールアウトオーケストレーションタスクを実行するためのプリカーサーとしてクローン化してパッチしなければならないディレクトリの数を最小化するために、Ｏｒａｃｌｅホームは、パッチされるすべてのサーバがアクセス可能な共有のストレージデバイス上に位置することが推奨される。こうして、単一の複製が作成されてパッチされ得、すべてのサーバが同じストレージポイントをマウントすることができる。提供されるストレージは、それがすべてのサーバにとっての単一の故障点とならないように、いくらか冗長構成されていることが推奨される。また、各サーバのシンボリックリンクが同じ方法で更新され得るように、すべてのサーバが同じパスを用いて共有のストレージ画像をマウントすることが必要である。

別個のマシン上のクラスタ内のサーバ
上述のように、一実施形態に従うと、サーバをアップグレードしつつアップタイムを維持するためのファクタは、クラスタで構成された高可用性を利用することである。一実施形態に従うと、クラスタ内の最小数のサーバは常に動作可能でなければならない。同じマシン上のクラスタ内のサーバは（それらが共通のドメインディレクトリおよびｓｙｍｌｉｎｋを共有している場合は）ともにリスタートされる必要があるため、クラスタ内のサーバは少なくとも２つの異なる物理マシン上でホストされるべきであるが、クラスタごとに最低でも３つのマシンが推奨される。これによって、一部は稼働中でサービスを提供し続け、一部はローリングリスタートの一部として停止することができる。要求を処理するために異なるマシン上で使用可能なサーバの数を判断する際、実行中であるが管理モードまたはスタンバイモードにある管理されるサーバは要求に応答しないため、これらのサーバを除外することが重要である。

管理サーバ分離
ロールアウトプロセスは、管理サーバおよび管理されるサーバを同時に更新する必要がある場合は大幅に複雑化し得る。たとえば、これが起こるのは、管理サーバおよび管理されるサーバが、同じマシン上で実行されて同じドメインディレクトリを共有するように構成されている場合であろう。管理サーバは、共有のシンボリックリンクから実行されているため、管理されるサーバと同時に停止しなければならない。この制限は、管理されるサーバのインストールホームを分離して、管理されるサーバ単位でパッチをロールアウトすることを可能にすることによって対処され得る。一実施形態に従うと、この問題を単純化する２つの異なる構成がサポートされる。

第１は、マシン上で実行されている管理されるサーバがない状態で、当該マシン上で管理サーバを実行することである。これによって、管理サーバを単独で１つのステップで更新することができ、それが完了すると、次のステップは、異なるマシン上のそのドメイン内の管理されるサーバを更新することである。

第２の構成は、管理サーバを管理されるサーバと同じマシン上で実行することを可能にするが、管理サーバにそれ自体の別個のドメインディレクトリを使い切らせることである。これによっても、管理サーバを個々に更新することが可能となり、管理されるサーバをそれら自体のステップで更新することができる。

クラスタレベルのパッチング
一実施形態に従うと、ドメイン内のすべてのサーバを更新するメカニズムを提供することに加えて、システムは、ドメイン内の個々のクラスタを更新する能力を提供し得る。ユーザがクラスタロールアウトモードの使用を試みているとき、異なるクラスタにサーブする単一のノード上に複数の管理されるサーバがある場合、管理されるサーバは、それらがサーブしているクラスタに従って別個のドメインディレクトリを有する必要がある。これは、一方のクラスタにサーブしている（かつまだ実行中である）管理されるサーバのｓｙｍｌｉｎｋに影響を与えることなく、他方のクラスタ用のノード上の管理されるサーバのすべてを停止させてそれらのｓｙｍｌｉｎｋを更新することができるようにするために必要である。

ロールアウトモード
一実施形態に従うと、ロールアウトは、サーバをグレースフルにシャットダウンすること、そのＯｒａｃｌｅホームｓｙｍｌｉｎｋを変更すること、およびサーバを再始動することを含む。これはドメイン全体に、ドメイン内の単一のクラスタに、または個々のサーバに適用され得る。これらのモードのいずれについても、共通のＯｒａｃｌｅホームを共有する、単一のマシン上で更新されている複数のサーバがある場合、それらはともにシャットダウンされて更新される。また、サーバのＯｒａｃｌｅホームが更新されると、それに関連付けられたノードマネージャはリスタートされて変更をピックアップする。これは厳密には必要でない場合もあるが、それを一貫して行なうことによってプロセスが簡略化され、ノードマネージャが反応的でない時間ウィンドウが短くなるだけで済む。

一実施形態に従うと、ドメインモードロールアウトは、ドメイン内の管理サーバおよびすべての管理されるサーバを、それらと関連付けられたすべてのノードマネージャとともに更新する。管理サーバは、その管理されるサーバのいずれかの最高パッチレベルで常に実行されていることが重要である。この要件がドメインモードロールアウト時に確実に満たされるようにするために、管理サーバは常に管理されるサーバの前に更新される。

一実施形態に従うと、クラスタモードロールアウトは管理サーバを更新せず、クラスタ内のすべての管理されるサーバおよびそれらと関連付けられたノードマネージャを更新する。

一実施形態に従うと、サーバモードロールアウトは、ターゲットパラメータ内に指定されているサーバに影響を与える。それはさらに、それらのサーバと関連付けられたノードマネージャを更新する。

Rollout WLSTコマンド
一実施形態に従うと、ロールアウトタスクは、どのサーバをどの順序で更新する必要があるかを理解し、それらを安全に更新するワークフローを作成する役割を果たす。これは、ノードを静止させること、サーバをグレースフルにシャットダウンすること、Ｏｒａｃｌｅホームリンクを更新すること、ノードマネージャをリスタートすること、サーバを開始すること、およびノードをグレースフルに起動させることを含む。ロールアウトタスクは、それがワークフローライフサイクルマネージャ（たとえばWorkflowLifeCycleManager：ＬＣＭ）に登録することになる名前を取るため、結果のMBeanは後で、または別のＷＬＳＴ接続によってアクセス可能である。ロールアウトタスクは、ステータスがポーリングされ得るWorkflowProgressMBeanを返す。いくつかの例を以下に示す：
ドメインにわたってロールアウトを実行する：

クラスタにわたってロールアウトを実行する：

２つの特定のサーバへのロールアウトを実行する：

ＯＴＤが構成されていない状態でドメインにわたってドライランまたはロールアウトを実行する：

一実施形態に従うと、ＷＬＳＴロールアウトコマンドは、ロールアウトタスクの進行を監視するために問合せられ得るWorkflowProgressMBeanを返す。この情報は、再接続するために必要なＷＬＳＴセッションに使用可能であり、ワークフローが完了した後も使用可能であり続ける。

ノードマネージャ
一実施形態に従うと、自動パッチロールアウトソリューションには、リモートマシン上の環境を更新するメカニズムが必要である。一実施形態に従うと、オーケストレーションフレームワークは管理サーバから実行し、各マシン上のノードマネージャに、Ｏｒａｃｌｅホームの更新、および新たなバイナリを取り込むためのプロセスのリスタートなどのタスクの実行を委任し得る。

一実施形態に従うと、ノードマネージャは、リモートマシン上のカスタムパッチングスクリプトを実行してＯｒａｃｌｅホームへのシンボリックリンクを変更するメカニズムの役割を果たす。スクリプトは、ドメイン当たりのマシンごとに一度実行され得る。ノードマネージャは内部で使用されるＡＰＩをサポートし、自動化されたサービスマイグレーション時に基本的なスクリプト実行を可能にし、これは上述のパッチング特徴をサポートするために活用され得る。

一実施形態に従うと、シンボリックリンクはノードマネージャの実行中に切替えられるが、startNodeManagerスクリプトは、常にシンボリックリンクを使用するのではなく、実際のディレクトリを使い切るようにセットアップされる。シンボリックリンクは、パッチ済のバイナリを取り込むことができるようにノードマネージャをリスタートするためにのみ用いられる。ドメイン内の、またはＯｒａｃｌｅホームの外部のノードマネージャホーム内の親開始スクリプトは、シンボリックリンク場所を用いてベースのstartNodeManagerスクリプトを実行する。ベーススクリプトはＷＬ＿ＨＯＭＥセットとともに実際のディレクトリにインストールされ、その値を用いてすべての環境値が生成される。この結果、ドメインがシンボリックリンク場所から実行されている間、ノードマネージャは実際のディレクトリから実行されるのみであるため、シンボリックリンクが切替ええられても影響を受けない。

一実施形態に従うと、ノードマネージャから実行されるシステムコンポーネントは、それらのプロセスが確実にパッチングをサポートできるようにするオプションを有する。

第１に、それらがノードマネージャ環境を用いてそれらのプロセスを開始する場合、それらはシンボリックリンク変更から隔離され、ノードマネージャバージョンと整合している。つまり、それらは、シンボリックリンクが変更されている間、それらのコンポーネントを実行し続けることができ、新たなＯｒａｃｌｅホーム場所をピックアップするためにノードマネージャがリスタートされた後にのみリスタートされる。

第２に、それらがシンボリックリンクをより直接的に用いることを望む場合、それらは、ＷＬＳ使用などの何らかの開始スクリプトを介してドメイン自体から、またはＬＩＮＫ＿ＭＷ＿ＨＯＭＥなどの規定値としてのノードマネージャ環境からその値を取得する必要があり、それらのプロセスがシンボリックリンク変更の前に適切にシャットダウンされることを確実にする必要がある。さらに別のオプションは、それらが、それら自体のパス情報を供給してそれを直接管理できるようにすることである。たとえば、ＯＨＳインストールは、「ohs.home」をＪＡＶＡ＿ＯＰＴＩＯＮＳ環境フラグ内のノードマネージャに渡す。この値は、パスが変更されたとき、およびプロセスがリスタートされたときにそれ自体のパッチングプリミティブ制御を提供することによって、パッチング時に管理されるシンボリックリンクであり得る。

一実施形態に従うと、自動ロールアウトパッチングの一部として、ノードマネージャは、たとえば「RESTART」コマンドをノードマネージャに発行することによって、新たな（パッチ済の）ＷｅｂＬｏｇｉｃサーバ画像から外れるようにリスタートされ得る。また、ノードマネージャは、さまざまなオプションを指定するユーザが供給したスクリプトなどの、他の方法で開始され得る。アプローチは、ベースのstartNodeManagerスクリプトに依拠して内部終了コードをキャプチャしてから、シンボリックリンク場所で見つけたstartNodeManagerスクリプトを実行することである。たとえば、入来するRESTARTコマンドは８８のコードでＪＶＭを出る。スクリプトは８８を見て、スクリプト自体のいずれかの変更をピックアップするために新たなスクリプトを用いて別のインスタンスを開始することを試みる。これは、ドメインレベルまたは他のラッパースクリプトの変更はまったくピックアップせず、WL_HOME/server/binの下のベースのstartNodeManagerスクリプトの変更のみをピックアップする。これは、この特定のトポロジではシンボリックリンクとなる、親スクリプトが用いたSCRIPTPATHを実行することによって達成される。

一実施形態に従うと、自動パッチロールアウトソリューションにおいて、ロールアウトコマンドは管理されるすべてのサーバをシャットダウンし、ノードマネージャを介してカスタムパッチングスクリプトを実行し、管理されるすべてのサーバを開始し、ノードマネージャをリスタートする。ノードマネージャ自体は、System.getenv() APIを介してシステムプロパティを取得することによって、および／または、ProcessBuilder.environment() APIを使用し、これらの値を構成値とともに、新たなプロセスが作成されると当該プロセスに提供することによって、ノードマネージャ自体の環境を伝える。

一実施形態に従うと、ドメインは、ノードマネージャがＯｒａｃｌｅホームディレクトリのその元のビューを維持している間にスワップされ得るＯｒａｃｌｅホームディレクトリへのそれ自体の固有のシンボリックリンクを有する。そのようなトポロジでは、ノードマネージャは、CLASSPATH、および不正確なバージョンからバイナリへのポインタを管理されるサーバに与える他の値を伝える。これは、ＷｅｂＬｏｇｉｃサーバおよびＯｒａｃｌｅホームに特有の環境値のみを伝えることのみによって対処され得る。

一実施形態に従うと、ドメイン当たりのノードマネージャおよびマシン当たりのノードマネージャの両方において、NodeManagerHomeディレクトリはＯｒａｃｌｅホームディレクトリの外部に位置することが予想される。デフォルトでは、ドメイン当たりのノードマネージャのNodeManagerHomeディレクトリは、ドメインディレクトリ下のサブディレクトリである。

NodeManagerリスタート
一実施形態に従うと、システムはＪａｖａベースのノードマネージャプロセスをリスタートする自動化された能力を提供し得る。

Ｊａｖａベースのノードマネージャ
一実施形態に従うと、Ｊａｖａベースのノードマネージャは、NMClientから発行される新たなコマンド「RESTART」を受付ける。NMServerは、リスタートコマンドを受信すると、特定の終了コード８８で出る。いずれかのグレースフルシャットダウンアクションも取られるべきであるが、ノードマネージャが開始する管理されるプロセスは実行され続けるべきである。NMClient APIは以下を提案した：

startNodeManagerスクリプト
一実施形態に従うと、供給されたstartNodeManagerスクリプトは、Ｊａｖａノードマネージャがもはや実行されていない場合、特定のコード８８をチェックする。８８が戻されたコードである場合は、スクリプトはシンボリックリンク場所で見つけられる新たなstartNodeManagerスクリプトを開始する。バイナリおよびスクリプトを含むすべての新たなパッチファイルは別個の場所に位置しており、シンボリックリンクを用いて使用可能となる。つまり、いずれのファイルも上書きされるべきでない。リスタートシナリオは、＄ＷＬ＿ＨＯＭＥがシンボリックリンク場所を指す以下の例のようなものがスクリプトされる：

一実施形態に従うと、ノードマネージャプロセスを開始するさまざまな方法の多くは、WL_HOME/server/binディレクトリに含まれるベースのstartNodeManagerスクリプトを利用し得る。domain/binおよびカスタムラッパー内のドメインレベルスクリプトはこのスクリプトに委任すべきであり、その結果、開始のために同じ論理を使用すべきであり、ＷＬＳＴ startNodeManagerコマンドもそれらのスクリプトを使用可能である。

図１６は、一実施形態に従ったパッチングのための方法のフローチャートを示す。
図１６に示されるように、ステップ６６０において、１つ以上のパーティションをサポートするソフトウェアアプリケーションを実行するためのドメインを含むアプリケーションサーバ環境が、１つ以上のコンピュータにおいて提供され、各パーティションはドメインの管理およびランタイムの区分を提供し、パーティションは任意に、デプロイ可能なアプリケーションもしくはリソースの集合を有する、および／またはリソースグループテンプレートを参照する１つ以上のリソースグループを含み得る。

ステップ６６２において、１つ以上のコンピュータノード、または当該ノード上でアプリケーションサーバ、アプリケーション、もしくは他のコンポーネントが実行されているサーバが、グレースフルにシャットダウンされているそれらのノード上のサーバによって、パッチングのために準備される。

６６４において、パッチすべきノードまたはサーバにおいて準備スイッチが呼出され、これは、そのノードまたはサーバ用のノードマネージャに、そのホームディレクトリの切替えを実行することになるスクリプトをセットアップするように、かつノードマネージャが演算を実行するのに必要なパラメータをノードマネージャに与えるように指示する。

ステップ６６８において、ノードマネージャをリスタートするための呼出がなされ、これによって、ノードマネージャはスクリプトに制御を転送し、スクリプトは、現在のホームディレクトリ（たとえばＯｒａｃｌｅホーム）を指定されたディレクトリパスに移動させ、パッチ済のアプリケーションサーバ、アプリケーション、または他のコンポーネント画像を元の場所の中に抽出してから、ノードマネージャを再開する。

ステップ６７２において、アサートスイッチが実行され、これによって、ホーム（たとえばＯｒａｃｌｅホーム）ディレクトリの切替えが成功裏に完了したことが確認される。

ステップ６７４において、ワークフローがそれ以上のノードまたはサーバをシャットダウンする前に、パッチ済のアプリケーションサーバ、アプリケーション、または他のコンポーネントのすべてが確実に要求に応えることができるようにするために、開始サーバがノードごとまたはサーバごとに呼出され、これによって制限されたダウンタイムまたはダウンタイムなし（すなわちゼロ）がサポートされる。

ゼロダウンタイムパッチング時のセッション複製
一実施形態に従うと、ゼロダウンタイムパッチング時、「ゼロダウンタイム」を確実にするためにセッション損失から保護することが重要である。これは、ローリングパッチングプロセス時のセッション複製およびフェイルオーバー、ならびにアプリケーションパッチングによるセッション互換性の懸念事項を考慮することを意味する。

典型的なアプリケーションサーバ（たとえばＷＬＳ）環境では、システムは概して、ユーザ要求同士の間の時間にクラスタの１つのメンバーのみが停止される限り、１つのセッションがクラスタ内のどこかで確実に使用可能であるように努める。プライマリサーバがクラッシュした後にセカンダリサーバがクラッシュすると、そのセッションは失われる。プライマリサーバからのすべてのセッションは単一のセカンダリサーバに複製されるため、セッション複製分散はクラスタ全体にわたって均一でない。しかし、要求フェイルオーバーは均一に分散される。つまり、あるグループの要求が別のサーバにフェイルオーバーしている時、均一な部分はセカンダリサーバに、およびクラスタにわたって残っているサーバの各々にランディングする。次いで、各サーバは、受信した要求のその部分を担当する。セッションのコピーを有していなかったサーバは、セッションをフェッチしてから、それら自体の二次選択アルゴリズムを用いてバックアップコピーを維持する場所を決定しなければならない。古いコピーまたはオーファンコピーは、それがタイムアウトするまで所定の位置に残される。最終結果として、複製アルゴリズムが均一に分散されていなくても、要求の均一な分散によって、メモリ内のセッションは確実にある程度均一に分散されることになる。

非同期複製は、要求は完了しているがセッション変更は複製されていない別個のウィンドウを有する。また、この時間ウィンドウは、要求がサーバクラッシュのためにフェイルオーバーするたびに、またはフロントエンドから誤ってルーティングされるたびにサーブされる古いセッションがあり得ることを意味する。一実施形態に従うと、特定のセッションｉｄについてセッションオブジェクトを見つけるためのアルゴリズムは、１．ローカルマップでセッションＲＯＩＤをチェックし、見つけた場合はそれを使用する。２．クライアントクッキー内のＪＶＭＩＤをチェックし、プライマリサーバまたはセカンダリサーバからセッションを取得することを試みる。３．使用可能である場合、そのサーバからセッションを取得し、プライマリになり、好ましいセカンダリサーバに複製する。４．元のプライマリ／セカンダリからのセッションはオーファンになり、無効化またはタイムアウト時にのみクリーンアップされる。５．セッションが上記から使用可能でない場合は、新たなセッションを戻す。

つまり、クッキーは有効なプライマリサーバまたはセカンダリサーバを指し得るが、セッションのローカルコピーを使用する可能性がある。これが起こるのは、フェイルオーバーが発生し、セカンダリ以外のサーバが要求にサーブする場合であろう。元のセカンダリは古いコピーを有しており、別のフェイルオーバーがそのサーバに発生すると、この古いコピーはその他のコピーの前に見つけられて使用される。

サーバ毎の二次選択は、セカンダリを自動的に、または好ましい候補サーバ、リモート候補サーバ、およびローカル候補サーバの構成値に基づいて選択することを試みる。余分な構成がない場合、自動選択は、フルサーバリスト内の現在のサーバのインデックスのモジュロ演算およびリモートサーバリストのサイズに基づいて、別のマシンからサーバを選択する。各マシンが単一のサーバを含んでおり、各マシンが当該サーバに対して同様の順序で編成されている場合は、各サーバがリスト内の次のサーバに複製され、サーバ１はサーバ２に、サーバ２はサーバ３に、サーバ３はサーバ４に等、リスト内の最後のサーバがサーバ１に複製するまで継続する。フロントエンドサーバは、シャットダウンのためにプライマリサーバへのアフィニティを維持することができない場合、残りのクラスタ化されたサーバ同士の間で均一に分散している要求をランダムにリダイレクトする。

ゼロダウンタイムパッチング時、上層アプリケーションを含むパッチ済のＯｒａｃｌｅホームをロールアウトすること、またはさらにはＯｒａｃｌｅホームパッチとは独立して特定のアプリケーションパッチをロールアウトすることも可能である。それらのアプリケーションが変更を含んでいる場合、システムをセッション非互換性の可能性から保護しなければならない。セッション非互換性の一般的なシナリオは、アプリケーションフレームワークを使用して起こる。そのようなフレームワークの新バージョンでアプリケーションを更新すると、クラスパスに含まれるクラスに対する制御が欠如することになる。アプリケーションセッションの１つのパッチ済バージョンはセッション内にクラス「patched.Foo」を含み得るが、アプリケーションセッションの以前のバージョンはクラス「unpatched.Bar」を含み得る。要求が当該セッションを複製する試みをトリガすると、パッチ済または未パッチサーバ上でシリアライゼーションが起こるのに対して、反対の状態のサーバ上ではデシリアライズする試みが起こり得る。クラスパス内に適切なクラスが欠如しているため、セッションを受信するサーバはデシリアライゼーションプロセスを失敗する。これによって、セッションが複製されず、警告メッセージがログファイル内にプリントされる。セッションは単一のサーバ上にのみ存在しているため、サーバシャットダウンまたはサーバクラッシュによって失われるリスクがある。

アプリケーションをパッチする際、セッションを複製する能力も重要であるが、要求にサーブするためにセッションが何らかのサーバ上で成功裏にデシリアライズされることを確実にする能力も等しく重要である。サーバがシャットダウンされた後、フロントエンドは、均一に分散されているクラスタ内の残りのメンバーのうちのいずれかにランダムに要求をフェイルオーバーする。サーバは要求を受信すると、そのセッションのコピーを保持するサーバからセッションをグラブすることを試みる。パッチ済または未パッチサーバが、反対の状態のサーバから発生したセッションをロードすることを試みると、非互換性セッションはデシリアライゼーションエラーをもたらし、ユーザはそれらのセッション情報を失う。このようなシナリオは、サーバがシャットダウンされ、次いで、クラスタの他のメンバーがランダムなフェイルオーバー要求を処理している間にパッチを用いてリスタートされるパッチロールアウトプロセス時によく起こる。これは、クラスタメンバーがフロントエンドサーバからランダムに選択される場合にいずれかのフェイルオーバー要求について起こり得る。また、スロークライアントまたはレイジークライアントは、サーバがパッチされた後に要求を同じサーバに送り返し得る。これは、パッチ済サーバが、他の何らかのサーバ上に記憶された「未パッチセッション」をロードすることを試みるという効果を有する。

ゼロダウンタイムパッチングは、サーバ１がシャットダウンされ、パッチされてからリスタートされた後に次のノードが続行するローリングする態様で、各ノードを更新する。プロセスがパッチすべき最後のサーバに来ると、最後のサーバ上でのみ互換性があり得る未パッチサーバ上に発生したセッションのグループが存在する。これらのセッションが行なわれる前に最後のサーバがシャットダウンされた場合（タイムアウトまたは無効化）は、それらのセッションはいずれのサーバ上にもロードされない可能性があり、失われる。しかし、セッションに互換性がある場合は、それらは待機なしで安全にシャットダウンされ得る。

ゼロダウンタイムパッチングがクラスタを進行するにつれて、パッチされているサーバはシャットダウンされ、そのプライマリセッションがリスクに晒される。この理由は、サーバ１がシャットダウンされると、セッションのそのプライマリコピーが使用不可能となるからである。サーバ２がセカンダリセッションをホストしている場合、当該セッションはサーバ２上でプライマリステータスに高められるが、セッションを更新する別の要求が入ってくるまで、当該セッションはクラスタ内のその他のサーバに複製されない。サーバ１をリスタートした直後、サーバ２はパッチングロールアウトにおける次の演算としてシャットダウンされ得る。サーバ２がシャットダウンされる前に別の要求を送信しないクライアントはすべて、そのセッション情報を失う。

一実施形態に従うと、既存の複製サービスへの影響を最小限に抑えてセッション非互換性を処理するために、パッチングフレームワークは各サーバに接続し、セッションをレイジーにデシリアライズする既存のオプション、クラスタ全体にわたるセッション問合せを、シャットダウン時にセッションを複製し、それらをフェッチした後にオーファンセカンダリをクリーンアップする新たなオプションとともに、一時的にイネーブルにする。これらのオプションは組合されて、セッションがクラスタにわたって適切に記憶されることを確実にし、パッチング時のセッション損失を最小化する。

セッション損失を回避するという目標を完全に達成するために、システムは、セッションをロード可能なサーバが確実に要求にサーブするようにしなければならない。一実施形態に従うと、これも、既存のセッション処理に対する最小限の中断で行なわれる。サーバはセッションをロードすることを楽観的に試み、それができない場合、要求を処理可能であるべき５０３応答コードを用いてサーバの適切なリストをＯＴＤに通信する。

一実施形態に従うと、パッチすべきサーバをシャットダウンする際、セッション複製オプションは、サーバが、セッションがすべてセカンダリサーバ上で確実に使用可能であるようにするために必要ないずれのセッションも自動的に複製することを可能にする。パッチングフレームワークは、クラスタ内の最後のサーバをシャットダウンしようとしている場合、そのサーバをシャットダウンする際にデフォルトでwaitForAllSessionsを合図する。これは、サーバがシャットダウンを完成させ得る前にすべてのセッションを処理する必要があることをｗｅｂコンテナに合図する。ユーザは、すべてのアプリケーションパッチが互換性があるセッションクラスを有しており、したがってクラスタ内の最後のサーバを待機することが不要であると合図する入力を任意に提供し得る。

レイジーセッションデシリアライゼーションは、Ｅｘａｌｏｇｉｃプラットフォームなどのいくつかのシステム上でイネーブルになるパフォーマンスベースの特徴である。ReplicatedSessionDataオブジェットは、ClusterMBeanに問合せて、セッション属性をデシリアライズするか否かを決定する前にLazySessionDeserializationがイネーブルにされるか否かを確認する。イネーブルにされると、セッション属性はバイトアレイとして有効に記憶される。そのバイトアレイは、後で属性がリトリーブされると自動的にデシリアライズされる。

一実施形態に従うと、必要なときにのみセッションをロードするこの能力を利用するために、機能は動的にされ得る。パッチングフレームワークは、パッチングプロセス時にレイジーセッションデシリアライゼーションをイネーブル／ディスエーブルにする責任を有する。これは構成値でもあるため、フレームワークは、ClusterMBean構成が既にイネーブルにされていない場合にのみ設定を変更することを試みる。そうでない場合は、管理される各サーバ上のClusterServiceを用いて、イネーブルにされると構成値に優先するランタイム値を受信する。つまり、ClusterServiceは、LazyDeserializationがオフである場合でもオンにすることができる。しかし、ユーザがそれをオンとして構成している場合はディスエーブルにすることはできない。これはランタイム値となるため、パッチングフレームワークはClusterServiceに複数の呼出を行なわなければならない。最初の通知は、クラスタ内のいずれかのサーバがパッチされる前に起こる。これは、ClusterService上にLazySessionDeserializationを設定するために、RemoteClusterServicesOperationsインターフェイスを用いてクラスタ内の各サーバに接続する。第２の通知は、サーバがパッチされてリスタートされた後に起こる。リスタートの後、サーバは構成値を再び使用するため、ランタイム設定を再確立してLazySessionDeserializationをイネーブルにすることが必要である。パッチングプロセスが完了すると、パッチングフレームワークは必要に応じてレイジーセッションデシリアライゼーションオプションをディスエーブルにする。

一実施形態に従うと、パッチングフレームワークは、サーバのリストの対の形式で、サーバの現在の状態についてクラスタの各メンバーに警告する。サーバ名の一方のリストはグループ化と見なされ、サーバ名の他方のリストは他方のグループと見なされる。通知が必要な２つの異なるポイントが再び存在する。最初の通知は、サーバをシャットダウンしてパッチを適用した後に起こる。そのサーバをリスタートする前に、クラスタには、パッチ済リストに参加している新たなパッチ済サーバとの新たなグループ化が通知される。これによって、実行中のサーバは、パッチ済のサーバがリスタートされると古い情報を有さないことが確実になる。第２の通知は、フレームワークがすべてのアプリケーションが準備ができた状態となるのを待機する間、サーバが開始された直後に起こる。この目的は、サーバにできる限り早く状態が通知されることを確実にし、サーバがセッション非互換性を伴ういずれの要求も正確に処理できることを確実にすることである。最後に、パッチングプロセスが完了した後、値はクラスタへの最終通知とともにｎｕｌｌにリセットされる。これによってパッチング前の状態が復元されるため、クラスタはパッチングが進行中であると仮定しなくなり、したがって挙動は再びデフォルトに戻ることができる。

一実施形態に従うと、ｗｅｂコンテナは、複製セッションをリトリーブすることを楽観的に試みる。デシリアライゼーションエラーが発生する場合は、ｗｅｂコンテナは現在のサーバグループをチェックする。現在のサーバグループの値は、パッチングが現在進行中であるか否かを示す。ｗｅｂコンテナは、グループのコンテンツを調べて、現在のサーバがどのグループにいるかを特定する。現在のサーバ名を含んでいないグループは、現在のサーバは非互換性であり、したがって他方のグループが互換性があるはずであるという論理に基づいて、互換性があるグループと見なされる。これは、前方および後方互換性の問題の両方に対処する。ｗｅｂコンテナは、セッションが互換性がある可能性が最も高いサーバのグループを特定すると、そのグループ内のサーバのリストと一緒に「X-WebLogic-Cluster-FailoverGroup-List」ヘッダとともに５０３応答コードを返す。

一実施形態に従うと、ＯＴＤは、サーバグループを含むヘッダとともに５０３を受信し、そのリストからサーバをランダムに選択して要求をリダイレクトする。これはＷＬＳが有していない情報であるため、ＯＴＤはドレインプール内のサーバを確実に処理する。サーバが指定したリストは、ランタイムに生成されたクラスタ内の現在のメンバーを含む。これは、クラスタに参加しているＷｅｂＬｏｇｉｃサーバのダイナミックディスカバリと同様にフロントエンドによって処理されるべきである。リストは動的な性質のものであり、ランタイム中に変更し得るが、リストはパッチングプロセスの開始時に分かっているすべてのクラスタメンバーを含む。

一実施形態に従うと、パッチングフレームワークは、パッチング時にセッションの適切な処理を可能にする責任を有する。シャットダウン時のこのセッションの複製は、クラスタ全体にわたるセッション問合せ、およびオーファンセカンダリクリーンアップの両方を可能にすることに依存する。フレームワークは、ClusterMBean構成が任意の設定をイネーブルにしていない場合にのみ、当該設定の変更を試みる。フレームワークは、パッチング前に各サーバに接続して各フラグをイネーブルにする。そして、各サーバがリスタートされると、フラグは再び設定される必要がある。最後に、パッチングプロセスが完了した後、設定は必要に応じて復帰する。

一実施形態に従うと、ＷＬＳ−ＭＴクラスタ化について既に実装されているセッションフェッチングを用いて、クライアントクッキーを更新することなくセッションをセカンダリに自動的に複製するため、フェイルオーバー要求はクラスタのいずれかのメンバーにランディングすることになり、セッションを見つける何らかのメカニズムが必要となる。要求がサーバにランディングするときの挙動は以下のようになる：ローカルマップでセッションＲＯＩＤをチェックし、見つけた場合はそれを使用する。２．クライアントクッキー内のＪＶＭＩＤをチェックし、プライマリサーバまたはセカンダリサーバからセッションを取得することを試みる。３．使用可能である場合、そのサーバからセッションを取得し、プライマリになり、好ましいセカンダリサーバに複製する。４．元のプライマリ／セカンダリサーバ上のオーファンセッションを処理するための新たなメカニズムが導入される。５．セッションが上記から使用可能でない場合は、SessionFetchingがイネーブルにされていなければ新たなセッションを返し、SessionFetchingがイネーブルにされていればブロードキャストクエリをクラスタに送信する。第１の応答を用いて、セッションを取得可能なサーバを特定する。プライマリになり、好ましいセカンダリサーバに複製する。ｉｉ．元のプライマリ／セカンダリサーバ上のオーファンセッションに対処するための新たなメカニズムが導入される。

一実施形態に従うと、サーバシャットダウン時、他のクラスタメンバーにシャットダウンを通知する直前、ReplicationServiceは、セッションの各プライマリコピーがセカンダリサーバに確実に複製されるようにする。これによって、サーバのシャットダウン動作時にセッションが失われないことが確実になる。これは、元のプライマリがリスタートされてから要求を行なっていない、つまり、新たなプライマリサーバを新たなセカンダリサーバとともに再確立していないクライアントにしか影響を与えない。最後に、そのようなクライアントが戻ると、セッションはクラスタ内の何らかのサーバ上で使用可能となる。

一実施形態に従うと、オーファンセッションは、シャットダウン時のセッション複製またはセッションフェッチングに固有ではない。しかし、各サーバが連続してリスタートされるクラスタの反復のため、この問題が起こる可能性は高くなる。

オーファンセカンダリからの古いセッションデータをサーブする可能性に対処するために、フェッチング後にオーファンセカンダリコピーをクリーンアップするメカニズムが存在する。パッチング時にこの機能がイネーブルにされると、ReplicationServiceは、そのセッションをフェッチした後にオーファンセッションのクリーンアップを処理するバックグラウンドプロセスをトリガする。バックグラウンドプロセスは、セッションバージョン番号、タイムスタンプ情報、セッションを見つけた場所、そのセッションが関連付けられている可能性があるその他のサーバ、および新たなセカンダリサーバが分かっている。このため、セッションの現在のコピーを除去することなく、バージョンおよびタイムスタンプ情報に基づいてすべての古いコピーをクリーンアップすることができる。

一実施形態に従うと、サーバがグレースフルにシャットダウンされると、ユーザはignoreSessions=falseを指定して、ｗｅｂコンテナに、複製されていないセッションの完了を待機させ得る。しかし、クラスタ内のどこかにセッション複製があるため、ｗｅｂコンテナは複製セッションを待機しない。しかしＺＤＴパッチングについては、セッションが非互換性であり、サーバがクラスタ内の最後の未パッチサーバである場合、サーバは互換性があるセッションを有する唯一のものであり、すべてのセッションが完了するのを待機する必要がある。このため、グレースフルシャットダウンのための「waitForAllSessions」フラグが導入される。

パッチングフレームワークは、クラスタ内の最後のサーバのシャットダウンを呼出す際、「waitForAllSessions」ブールをデフォルトで指定する。これは、ｗｅｂコンテナに、シャットダウンシーケンスを終了する前にすべてのセッションが無効化されるのを待機するように合図する。関連付けられたセッションがない要求はすべて５０３応答によって拒絶され、ＯＴＤは、５０３応答を取得した場合、これらの要求にサーブするためにクラスタ内の他のサーバを試みる。既存のセッションを有する要求はすべて適切にサーブされる。これらのセッションはパッチ済サーバのいずれとも互換性がない可能性があるため、ｗｅｂコンテナは完了までこれらのセッションの各々を処理する必要がある。

ユーザは、waitForAllSessionsが偽であり得ることを合図するために、パッチング動作を開始する際にSessionCompatibility=trueを任意に指定し得る。このwaitForAllSessionsオプションは、既存のignoreSessionsパラメータと同様のServerLifeCycleRuntimeMBeanに追加される。さまざまな実施形態に従うと、付加的なパラメータ、たとえばパッチングのために次に管理されるサーバのシャットダウンを開始する前にどれぐらい長く待機するかを示すタイムアウト（delayBetweenNodes）がサポートされ得；これは、サーバのシャットダウンを試みる前にセカンダリセッションが確実に複製されるようにするのに有用であり得る。

クイックスタートの例
一実施形態に従うと、ゼロダウンタイムパッチングは、一度に１つのノードの変更をロールアウトし、その変更が完了するまでトラフィックディレクタ（たとえばＯＴＤ）が入来するトラフィックを残りのノードにリダイレクトすることを可能にすることによって達成され得る。たとえばＯｒａｃｌｅホームのパッチングのための典型的なシーケンス演算は以下を含む：１．アドミニストレータがパッチを認証する；２．Ｏｒａｃｌｅホームおよび代表ドメインのコピーが作成される；３．パッチが試験／認証環境に適用される；４．パッチがプロダクションに確実に承認されるようにするための試験が行われる；５．スクリプトを用いて認証済のＯｒａｃｌｅホームがコピーされ、生成されたアーカイブはプロダクション環境にわたってロールアウトされるパッチ済の「Gold Master」と見なされる；６．生成されたＯｒａｃｌｅホームアーカイブは、アドミニストレータによってプロダクション環境にわたって各物理マシンに分散される；および、７．アドミニストレータがロールアウト演算を実行する。

Ｊａｖａホームのインストール／更新、およびアプリケーションソースの分散は、それらのロールアウト演算のためのアドミニストレータに同様に委ねられ得る。一実施形態に従うと、ターゲット環境は、管理サーバを実行する１つのノードを含む３つ以上の物理マシンまたはノードを含む必要がある。付加的な要件は、一実施形態に従うと、管理されるサーバはゼロダウンタイムをサポートするためにクラスタ内になければならないこと；各ノードは、管理サーバを実行しているノードを含む各自のノードマネージャが実行中でなければならないこと；Ｏｒａｃｌｅホームディレクトリは、好ましくはすべてのノード上の同じ場所（たとえば/scratch/aime1/OracleHomes/wls1221）において、各ノード上にローカルにインストールされなければならないこと；および、ドメインディレクトリはＯｒａｃｌｅホームディレクトリの外部になければならないことを含む。

アドミニストレータは、移動スクリプトを利用してＯｒａｃｌｅホームのアーカイブｊａｒを作成し、アーカイブｊａｒを各リモートノードにコピーすることによって、すべてのノード上にインストールおよびドメインを複製する必要性を回避することができる。

一実施形態に従うと、ドメインは、少なくとも２つの管理されるサーバ、および少なくとも３つのノードマネージャを参照する必要がある。ドメインは、ドメインのコピーを作成すること、そのバイナリをリモートノードの両方に分散すること、および次いで各リモートノード上でアンパックを実行することを含む、パック／アンパックユーティリティを用いて複数のノードについて複製され得る。

Ｊａｖａホームロールアウトが成功するためには、新たなＪａｖａホームが影響を受ける各マシン上にインストールされる必要があり、各マシン上の同じパスに配置される必要がある。これは、現在のノードマネージャおよび管理されるサーバの実行中になされる必要があるため、インストールは既存のＪａｖａホームパスを変更してはならない。これを助けるために、Ｊａｖａホームはｓｙｍｌｉｎｋを含むパスとしてではなく、絶対パスとして指定される。

ロールアウト演算が開始されると、Ｏｒａｃｌｅホームの変更はいずれも、一度に１つのノードに適用される。アドミニストレータは、以下にさらに説明するようにＯＰａｔｃｈツーリングを用いて所望のパッチを適用することができる。顧客の中には、ＰｕｐｐｅｔまたはＣｈｅｆなど、ファイルの分散を補助し得るツールを所定の位置に有する者もある。

ＯＰａｔｃｈとの統合
一実施形態に従うと、システムは、ＯｐａｔｃｈＡｕｔｏなどのプロダクトと統合して、さまざまな範囲のたとえばオラクル製品にわたってゼロダウンタイムパッチングのための顧客対応フロントエンドを提供し得る。これらの特徴を統合すると、単一のインターフェイス下でより完全なソリューションが提供される。

一実施形態に従うと、ＯｐａｔｃｈＡｕｔｏが提供するツーリングは、ユーザが、たとえばＷＬＳコンポーネントのパッチ済バージョンを作成すること、それらを更新されるノードに対してアクセス可能とすること、およびパッチングロールアウトを呼出して監視することを可能にする。パッチングインフラストラクチャは、アクティブなセッションが確実に保存されるようにしつつ、サーバのランタイム状態および可用性を管理し、ＷＬＳコンポーネントおよびアプリケーションソースを更新し、いずれかのマルチテナンシの懸念事項に対処する。

状況によっては、顧客は、非プロダクション環境で検証試験を行なうために、パッチ済アーカイブの作成をロールアウトから分離することを望む場合があり、または、顧客は、それらの部分を組合せた単一のアクションを望む場合がある。一実施形態に従うと、ＯｐａｔｃｈＡｕｔｏは、別個のまたは組合されたステップとして、パッチ済のＷＬＳアーカイブを作成し、アーカイブをすべてのノードに対して使用可能とし、ロールアウトを開始する能力を提供する。ユーザは、ＯｐａｔｃｈＡｕｔｏを用いて、すべてのノードに分散されるパッチ済バイナリを作成し、パッチ済バイナリをすべてのノード上でステージし、サービスダウンタイムなしでパッチ済バイナリのランタイム起動を実行し得る（ＷＬＳにランタイム管理およびロールアウトの責任を負わせる）。

一実施形態に従うと、ＯｐａｔｃｈＡｕｔｏはＷＬＳ環境においてゼロダウンタイムパッチングを駆動するエントリポイントの役割を果たし、これは、ＺＤＴパッチングがトポロジについてサポートされるか否かをパッチングが決定できるようにパッチメタデータを検査する能力を提供すること、および試験用のオフラインパッチ済環境を作成するワークフロー能力を提供することを含む。これは、既存のＯｒａｃｌｅホームを、プロダクション環境から直接、またはプロダクション環境と同等であると仮定してコピーする能力を含む。

さらに、ＯｐａｔｃｈＡｕｔｏは、成功裏にパッチされ試験されたＯｒａｃｌｅホームアーカイブをトポロジ内のさまざまなノードに分散するワークフロー能力を提供する。これによって環境はロールアウトの準備ができた状態となり、ロールアウトは任意の時間にＯｐａｔｃｈＡｕｔｏを用いて開始され得る。ＯｐａｔｃｈＡｕｔｏを用いて、パッチングロールアウトを開始および監視することもできる。

パッチングインフラストラクチャは、サーバが更新される順序を決定する；パッチングロールアウトのステップを監視し、必要であれば進行すべき時および戻るべき時を判断する；セッションが確実に保存されるようにする；サーバライフサイクルを監視して、パッチ済のＯｒａｃｌｅホームビットをスワップインする；ステータス更新についてＯｐａｔｃｈＡｕｔｏによって問合せるべきその標準的な進行オブジェクトを提供する；ならびに、どのサーバがパッチされるか、かつどのサーバがパッチされたかに関する情報を提供するように進行オブジェクトを向上させる役割を果たす。この情報は、ロールアウトの実行を開始する前に進行オブジェクトを介しても使用可能にされる。

例：
アプリケーションサーバ（たとえばＷＬＳ）ドメインがＭＷ＿ＨＯＭＥの外部に作成される。ＯｐａｔｃｈＡｕｔｏウォレットがＳＳＨ／ＪＭＸを介してホストに接続するように作成される：

パッチを管理サーバに適用し、パッチ済のＯｒａｃｌｅホームアウトオブプレースに基づいてアーカイブを作成する：

検証後、更新されるすべてのノードにパッチ済アーカイブをステージする：

ドメイン全体または特定のクラスタへのロールアウトを開始して監視する：

失敗したロールアウトを再開またはロールバックする：

本発明は、本開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用または特化型デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを使用して都合よく実現され得る。ソフトウェア技術の当業者には明らかであるように、本開示の教示に基づいて、適切なソフトウェアコーディングが熟練したプログラマによって容易に準備され得る。

実施形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された（１つもしくは複数の）非一時的な記憶媒体またはコンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。

本発明のこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって他の当業者が本発明をさまざまな実施の形態および意図している特定の使用に適したさまざまな変形について理解できるようにするために、選択され説明されている。本発明の範囲は添付の特許請求の範囲およびそれらの均等物によって規定されるものと意図されている。

Claims (20)

1. マルチテナントアプリケーションサーバ環境においてパッチングをサポートするためのシステムであって、
   １つ以上のコンピュータを備え、前記コンピュータは、前記コンピュータ上で実行されるアプリケーションサーバ環境を、
   前記アプリケーションサーバ環境内で使用され得る複数のデプロイ可能なリソースと、
   ドメイン内のデプロイ可能なリソースのグループ化を定義する、１つ以上のリソースグループテンプレートと、
   １つ以上のパーティションとともに含み、パーティションの各々は前記ドメインの管理およびランタイム区分を提供し、前記システムは、１つ以上のパーティションおよびリソースグループテンプレートを、テナントが使用するために前記テナントと関連付けることができ、
   前記システムは、アプリケーションサーバ環境に組込まれた高可用性特徴を利用して、中断なしで動作するドメインの能力を維持する制御された態様でパッチを適用するパッチング特徴を含む、システム。
2. 前記パッチングのプロセスのモニタリングおよびエラー処理を提供するオーケストレーションフレームワークをさらに備える、請求項１に記載のシステム。
3. 前記アプリケーションサーバ環境はＪａｖａ ＥＥアプリケーションサーバを含み、リソースグループテンプレートの各々は、１つ以上の関連のアプリケーションを、それらのアプリケーションが依存するリソースとともに含む、請求項１から２のいずれか１項に記載のシステム。
4. 前記マルチテナントアプリケーションサーバ環境内でパッチングをサポートするノードマネージャをさらに備える、請求項１から３のいずれか１項に記載のシステム。
5. 前記システムを用いて、クラスタ化環境においてノードにパッチを適用する、請求項１から４のいずれか１項に記載のシステム。
6. 前記システムはクラウド環境内に提供され、前記クラウド環境内で動作する複数のテナントをサポートする、請求項１から５のいずれか１項に記載のシステム。
7. マルチテナントアプリケーションサーバ環境においてパッチングをサポートするための方法であって、
   １つ以上のコンピュータ上で実行されるアプリケーションサーバ環境を含む、前記コンピュータにおいて、
   前記アプリケーションサーバ環境内で使用され得る複数のデプロイ可能なリソースと、
   ドメイン内のデプロイ可能なリソースのグループ化を定義する、１つ以上のリソースグループテンプレートと、
   １つ以上のパーティションとを提供することを含み、パーティションの各々は前記ドメインの管理およびランタイム区分を提供し、前記方法はさらに、
   １つ以上のパーティションおよびリソースグループテンプレートを、テナントが使用するために前記テナントと関連付けることを含み、
   前記システムは、アプリケーションサーバ環境に組込まれた高可用性特徴を利用して、中断なしで動作するドメインの能力を維持する制御された態様でパッチを適用するパッチング特徴を含む、方法。
8. 前記パッチングのプロセスのモニタリングおよびエラー処理を提供するオーケストレーションフレームワークを用いることをさらに含む、請求項７に記載の方法。
9. 前記アプリケーションサーバ環境はＪａｖａ ＥＥアプリケーションサーバを含み、リソースグループテンプレートの各々は、１つ以上の関連のアプリケーションを、それらのアプリケーションが依存するリソースとともに含む、請求項７から８のいずれか１項に記載の方法。
10. ノードマネージャを用いて、前記マルチテナントアプリケーションサーバ環境内でパッチングをサポートすることをさらに含む、請求項７から９のいずれか１項に記載の方法。
11. 前記方法を用いて、クラスタ化環境においてノードにパッチを適用する、請求項７から１０のいずれか１項に記載の方法。
12. 前記方法はクラウド環境内で実行され、前記クラウド環境内で動作する複数のテナントをサポートする、請求項７から１１のいずれか１項に記載の方法。
13. 命令が格納されている非一時的なコンピュータ読取可能記憶媒体であって、前記命令は、１つ以上のコンピュータによって読取られて実行されると、前記１つ以上のコンピュータにステップを実行させ、前記ステップは、
    アプリケーションサーバ環境を、
    前記アプリケーションサーバ環境内で使用され得る複数のデプロイ可能なリソースと、
    ドメイン内のデプロイ可能なリソースのグループ化を定義する、１つ以上のリソースグループテンプレートと、
    １つ以上のパーティションとともに提供することを含み、パーティションの各々は前記ドメインの管理およびランタイム区分を提供し、前記ステップはさらに、
    １つ以上のパーティションおよびリソースグループテンプレートを、テナントが使用するために前記テナントと関連付けることを含み、
    前記システムは、アプリケーションサーバ環境に組込まれた高可用性特徴を利用して、中断なしで動作するドメインの能力を維持する制御された態様でパッチを適用するパッチング特徴を含む、非一時的なコンピュータ読取可能記憶媒体。
14. 前記パッチングのプロセスのモニタリングおよびエラー処理を提供するオーケストレーションフレームワークを用いることをさらに含む、請求項１３に記載の非一時的なコンピュータ読取可能記憶媒体。
15. 前記アプリケーションサーバ環境はＪａｖａ ＥＥアプリケーションサーバを含み、リソースグループテンプレートの各々は、１つ以上の関連のアプリケーションを、それらのアプリケーションが依存するリソースとともに含む、請求項１３から１４のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
16. ノードマネージャを用いて、前記マルチテナントアプリケーションサーバ環境内でパッチングをサポートすることをさらに含む、請求項１３から１５のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
17. 前記ステップを用いて、クラスタ化環境においてノードにパッチを適用する、請求項１３から１６のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
18. 前記ステップはクラウド環境内で実行され、前記クラウド環境内で動作する複数のテナントをサポートする、請求項１３から１７のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
19. １つ以上のコンピュータシステム上で実行される命令を備えるコンピュータプログラムであって、前記プログラムの命令は、実行されると、前記１つ以上のコンピュータシステムに請求項７から１２に記載の方法を実行させる、コンピュータプログラム。
20. 非一時的なマシン読取可能データ記憶媒体に格納されている、請求項１６に記載のコンピュータプログラムを備えるコンピュータプログラムプロダクト。

Images