1. Clusterware管理およびデプロイメント・ガイド
  2. フリート・パッチ適用およびプロビジョニングと保守

5 フリート・パッチ適用およびプロビジョニングと保守

フリート・パッチ適用およびプロビジョニングは、Oracleホームのプロビジョニングと保守のためのソフトウェア・ライフサイクル管理方法です。

フリート・パッチ適用およびプロビジョニングにより、データベース、クラスタ、およびユーザー定義ソフトウェア・タイプの標準的な操作環境の一括デプロイメントおよび保守が可能になります。フリート・パッチ適用およびプロビジョニングを使用することで、クラスタのインストールと、Oracle Grid InfrastructureおよびOracle Database 11gリリース2 (11.2)以降のプロビジョニング、パッチ適用、スケーリング、およびアップグレードを行うこともできます。また、アプリケーションおよびミドルウェアのプロビジョニングもできます。

フリート・パッチ適用およびプロビジョニングは、次のいずれかのモードで使用できるOracle Grid Infrastructureのサービスです。

  • ゴールド・イメージと呼ばれる標準化されたイメージを格納および管理する中央サーバー(フリート・パッチ適用およびプロビジョニング・サーバー)として。ゴールド・イメージは、データ・センター全体の任意の数のノードにデプロイできます。デプロイされたホームを使用して、新しいクラスタとデータベースの作成、および既存のインストールに対するパッチ適用、アップグレード、およびスケーリングを行うことができます。

    サーバーは、フリート・パッチ適用およびプロビジョニング・サーバー自体をホストするクラスタ上のソフトウェア・ホーム、フリート・パッチ適用およびプロビジョニング・クライアントを管理し、さらにOracle Grid Infrastructure 11g リリース2 (11.2.0.3と11.2.0.4)および12c リリース1 (12.1.0.2)を実行するインストールも管理できます。サーバーは、グリッド・インフラストラクチャを実行せずにインストールを管理することもできます。

    フリート・パッチ適用およびプロビジョニング・サーバーは、新規インストールをプロビジョニングでき、さらに既存のインストールを変更せずに(たとえば、エージェント、デーモン、構成の前提条件なし)、既存のインストールを管理できます。フリート・パッチ適用およびプロビジョニング・サーバーには、ピア・フリート・パッチ適用およびプロビジョニング・サーバー間でゴールド・イメージを自動的に共有し、データセンターが地理的に分散している企業をサポートする機能があります。

  • クライアント(フリート・パッチ適用およびプロビジョニング・クライアント)として、中央フリート・パッチ適用およびプロビジョニング・サーバーから管理することも、またはフリート・パッチ適用およびプロビジョニング・クライアント自体でコマンドを実行することによって直接管理することもできます。フリート・パッチ適用およびプロビジョニング・サーバーと同様に、フリート・パッチ適用およびプロビジョニング・クライアントは、Oracle Grid Infrastructureに組み込まれたサービスであり、Oracle Grid Infrastructureの12cリリース2 (12.2.0.1)以降で使用できます。フリート・パッチ適用およびプロビジョニング・クライアント・サービスは、フリート・パッチ適用およびプロビジョニング・サーバーからゴールド・イメージを取得することも、ポリシーに基づいて新しいイメージをアップロードしたり、メンテナンス操作をそれ自体に適用したりすることもできます。

パッチ適用操作の場合、3番目のオプションは、Oracle DatabaseおよびOracle Grid Infrastructure 18cで使用できます。データベースおよびグリッド・インフラストラクチャ・ホームを更新する手順は、Oracle DatabaseおよびOracle Grid Infrastructureに同梱されている独立オートマトンにモジュール化されており、アーキテクチャに中央フリート・パッチ適用およびプロビジョニング・サーバーが存在しなくてもローカルで実行できます。これにより、Oracle Databaseまたはクラスタを起動すると、すぐにフリート・パッチ適用およびプロビジョニングの機能を使用できます。

フリート・パッチ適用およびプロビジョニングを使用したOracleソフトウェアの管理

  • デプロイされるソフトウェアのゴールド・イメージおよび系統の管理により、標準化および高レベルの自動化が可能になります。

  • アクティブ・データベースまたはクラスタを中断させることなく、新規ホーム(ゴールド・イメージ)をアウトオブプレースでデプロイすることで保守ウィンドウが最小化されます。

  • データベース・バージョンおよびデプロイメント・モデル全体でAPIを使用して呼び出されるオートマトンを提供することにより、保守が簡素化されます。

  • 操作をエンドツーエンドで確実に成功させる組込みの検証とドライラン・モードにより保守リスクが軽減されます。

  • 問題が発生しても、コマンドを再開および再起動できるため、保守操作のリスクがさらに軽減されます。

  • 次の機能により、パッチ適用およびアップグレードの影響が最小化、また多くの場合は解消されます。

    • 停止時間0のデータベース・アップグレード: 追加ノードまたは外部記憶域を必要とせずにデプロイメント内ですべて実行される完全に自動化されたアップグレード。

    • ローリング・パッチ適用中のデータベース・セッションおよびOJVMのアダプティブ管理。

    • 一括デプロイメントを詳細に管理するためのオプション。

デプロイメントおよび保守操作は拡張可能で、カスタマイズにより、自動化されたワークフローに環境固有のアクションを組み込むことができます。

フリート・パッチ適用およびプロビジョニングの自動化

  • 停止時間0のデータベース・アップグレードにより、データベースのアップグレードに必要な手順のすべてが自動化され、Oracleデータベースのアップグレード中、アプリケーションの停止時間が最小化され、場合によっては解消されます。また、リソース要件が最小化され、アップグレードをロールバックする必要がある場合にはフォールバック・パスが提供されます。

  • OJVMデプロイメントのアダプティブOracle RACローリング・パッチ適用: クラスタ化環境で、フリート・パッチ適用およびプロビジョニングでデータベースにパッチを適用するデフォルトの方法は、Oracle RACローリング・パッチ適用です。ただし、パッチ適用対象のデータベース・ホームにOJVMパッチが含まれる場合、非ローリングが必要になることがあります。この場合、フリート・パッチ適用およびプロビジョニングにより、ローリング・パッチ適用が可能かどうか判別され、可能な場合はパッチが適用されます。

  • ドライラン・コマンド評価: フリート・パッチ適用およびプロビジョニングでは、コマンドの実行前に、コマンドを確実に成功させるために、多様な事前条件がチェックされます。ただし、一部の条件は、コマンド実行前に検出できません。また、フリート・パッチ適用およびプロビジョニングでは、エラー状況の修正後に、失敗したコマンドの取消しや再開が可能ですが、コマンド実行前に、可能なかぎり多くの潜在的な問題を解決しておくことをお薦めします。コマンド評価モードでは、コマンドが実際に実行される前に、何も変更を加えずに特定コマンドの事前条件がテストされ、発生する可能性のある問題がレポートされ、それらが修正されます。

  • 独立オートマトン: Oracle Database 18cより以前は、フリート・パッチ適用およびプロビジョニング操作(データベース・ホームを新しいバージョンに切り替えるなど)を実行するには、中央のフリート・パッチ適用およびプロビジョニング・サーバーが必要でした。Oracle Database 18c以降は、アーキテクチャ内に中央フリート・パッチ適用およびプロビジョニング・サーバーがなくても、主な機能は独立して実行できます。

    注意:

    Oracle Grid Infrastructureをインストールすると、フリート・パッチ適用およびプロビジョニング・サーバーがローカル・モードでデフォルトで構成され、ローカル・スイッチ・ホーム機能がサポートされます。一般的なフリート・パッチ適用およびプロビジョニング・サーバー製品を構成する必要がある場合は、rootとして次のコマンドを使用して、現在のローカル・モードのフリート・パッチ適用およびプロビジョニング・サーバーを削除する必要があります。
    # srvctl stop rhpserver

    「フリート・パッチ適用およびプロビジョニング・サーバーが実行されていません」のようなメッセージを無視します。

    # srvctl remove rhpserver

グローバル・フリートの標準化および管理

  • ピア・フリート・パッチ適用およびプロビジョニング・サーバー間でのゴールド・イメージの共有: 大企業は、通常、複数のデータ・センターをホストし、各データ・センター内には、分離されたネットワーク・セグメントが存在する場合があります。フリート・パッチ適用およびプロビジョニング・アーキテクチャでは、特定のデータ・センター(またはデータ・センターのネットワーク・セグメント)内の一連のターゲットに対して1つのフリート・パッチ適用およびプロビジョニング・サーバーが実行されます。このため、各データ・センターに少なくとも1つのフリート・パッチ適用およびプロビジョニング・サーバーが必要です。

    各データ・センターには、ターゲット・サーバーが使用するゴールド・イメージに関して固有の要件が存在する場合もありますが、標準化の目標は、可能な場合は常に、すべてのデータ・センター間で同一のゴールド・イメージを使用することです。そのために、複数のフリート・パッチ適用およびプロビジョニング・サーバー間でゴールド・イメージを簡単に伝播できるように、フリート・パッチ適用およびプロビジョニングではゴールド・イメージのピア・ツー・ピア共有がサポートされています。

  • ゴールド・イメージ・ドリフトの検出および集約: ゴールド・イメージからソフトウェア・ホームをプロビジョニングした後、デプロイされたホームにパッチを直接適用することが必要な場合があります。この時点で、デプロイされたホームはゴールド・イメージからドリフトしています。フリート・パッチ適用およびプロビジョニングには、ドリフトを監視およびレポートする次の2つの機能が提供されています。

    • フリート・パッチ適用およびプロビジョニングでは、特定のホームとその親のゴールド・イメージが比較され、ホームに適用され、ゴールド・イメージに適用されていないパッチがリストされます。

    • フリート・パッチ適用およびプロビジョニングでは、特定のゴールド・イメージとそのすべての子孫のホームが比較され、それらのホームに適用され、ゴールド・イメージに適用されていないすべてのパッチの集約がリストされます。これにより、元のゴールド・イメージのすべての子孫に適用できる新規ゴールド・イメージのビルド仕様が得られ、それらのデプロイメントのどこからもパッチが失われないようにします。

  • 構成の収集およびレポート: フリート・パッチ適用およびプロビジョニング・サーバーは、指定されたフリート・パッチ適用およびプロビジョニング・クライアントのオペレーティング・システムの構成とルート・ファイル・システムの内容を収集し、保持できます。フリート・パッチ適用およびプロビジョニング・クライアント・ノードが使用不可として表示されている場合(たとえば、ユーザーがオペレーティング・システムの構成やルート・ファイル・システムを誤って削除または変更した場合など)、問題の特定および修正が困難な場合があります。この機能により、関連する情報の収集が自動化され、ノード障害が発生した場合に簡単なリストアを行うことができます。

柔軟性と拡張性

  • RESTful API: フリート・パッチ適用およびプロビジョニング、パッチ適用、アップグレード、問合せ操作など、多くの一般的な操作のためのRESTful APIを提供します。

    関連項目:

    Oracle Database REST APIリファレンス

  • カスタマイズ可能な認証: 特にコンプライアンスに配慮する業界(金融、電子商取引など)では、特定環境のホスト対ホスト認証で、フリート・パッチ適用およびプロビジョニングがネイティブでサポートされていないテクノロジおよび製品が多く使用されます。この機能により、フリート・パッチ適用およびプロビジョニング認証とデータ・センターで使用されているメカニズムを統合できます。

  • コマンド・スケジューラ: 自動タスクをスケジュールおよびバンドルする機能は、大規模なデータベース資産の保守に非常に重要です。フリート・パッチ適用およびプロビジョニングでは、ソフトウェア・ホームのプロビジョニング、新しいホームへの切替え、クラスタのスケーリングなどのタスクのスケジューリングがサポートされます。また、コマンドにクライアントのリストを追加して、大規模な操作を容易にすることができます。

  • 構成可能な接続: 多くの企業では、セキュリティ上の問題やコンプライアンス要件が増えるにつれて、イントラネットに関する接続の制限事項も増えます。フリート・パッチ適用およびプロビジョニング・サーバーとそのクライアント間の通信に使用される小規模なポート・セットを構成することで、ファイアウォールや監査対象環境への影響を低減できます。

その他のフリート・パッチ適用およびプロビジョニング機能

  • 停止時間0のアップグレード: 関連するすべてのアップグレード手順の自動化により、Oracle Databaseのアップグレード時のアプリケーションの停止時間が最小化、さらには解消されます。また、リソース要件も最小化され、アップグレードをロールバックする必要がある場合にはフォールバック・パスが提供されます。停止時間0のアップグレードは、Oracle RACおよびOracle RAC One Nodeデータベースの特定バージョンに対して実行できます。

  • 新しいサーバー・プールのプロビジョニング: フリート・パッチ適用およびプロビジョニング・サーバーでは、Oracleソフトウェア・インベントリのないノードにOracle Grid Infrastructure (11g リリース2 (11.2.0.4)、12c リリース1 (12.1.0.2)、およびリリース2 (12.2))をインストールし、構成することで、完全なフリート・パッチ適用およびプロビジョニング機能を使用してそれらのデプロイメントを管理できます。

  • ソフトウェア・ホームのプロビジョニングおよび管理: フリート・パッチ適用およびプロビジョニングにより、あらゆるソフトウェア・ホームからゴールド・イメージを作成できます。その後、そのソフトウェアをゴールド・イメージの作業用コピーとして任意のフリート・パッチ適用およびプロビジョニング・クライアントまたはターゲットにプロビジョニングできます。ソフトウェアは、フリート・パッチ適用およびプロビジョニング・クライアントで実行するバイナリか、またはターゲットで実行するバイナリです。

  • Oracle Grid Infrastructureのプロビジョニング、スケーリング、パッチ適用、およびアップグレード: フリート・パッチ適用およびプロビジョニング・サーバーでは、Oracle Grid Infrastructure 11g リリース2 (11.2.0.4)ホームのプロビジョニング、Oracle Grid Infrastructure構成に対するノードの追加または削除を実行でき、また、Oracle Grid Infrastructureホームのパッチ適用およびアップグレードにも使用できます。また、失敗したパッチ適用手順を簡単に元に戻すことができるロールバック機能も存在します。Oracle Grid Infrastructureのパッチ適用中に、必要に応じてフリート・パッチ適用およびプロビジョニングを使用して、クラスタ上でホストされる任意のデータベース・ホームにパッチを適用できます。

  • Oracle Databaseのプロビジョニング、スケーリング、パッチ適用、およびアップグレード: フリート・パッチ適用およびプロビジョニングを使用でき、Oracle Database 11g リリース2 (11.2.0.4)以降のプロビジョニング、スケーリング、およびパッチ適用が可能です。また、Oracle Databaseを11g リリース2 (11.2.0.3)から11g リリース2 (11.2.0.4)に、11g リリース2 (11.2.0.4)から12c リリース1 (12.1.0.2)に、および11g リリース2 (11.2.0.4)または12c リリース1 (12.1.0.2)から12c リリース2 (12.2)にアップグレードできます。

    このようなソフトウェアをプロビジョニングするとき、フリート・パッチ適用およびプロビジョニングによって、多様なタイプのデータベース(Oracle RAC、シングル・インスタンス、Oracle Real Application Clusters One Node (Oracle RAC One Node)データベースなど)をタイプの異なる記憶域に作成する追加機能や、その他のテンプレートの使用やコンテナ・データベース(CDB)の作成などのオプションが提供されます。フリート・パッチ適用およびプロビジョニング・サーバーにより、Oracle RAC構成へのノードの追加およびOracle RAC構成からのノードの削除を実行できます。また、フリート・パッチ適用およびプロビジョニングにより、データベース・ソフトウェアへのパッチ適用が改善され、効率がよくなります。このため、ソフトウェアのリモートでの高速パッチ適用が可能になり、ほとんどのケースでデータベースの停止時間が発生しません。

  • 単一インスタンス・データベースのサポート: フリート・パッチ適用およびプロビジョニングを使用して、クラスタ、Oracle Restartまたは単一のスタンドアロン・ノードで実行される単一インスタンス・データベースのプロビジョニング、パッチ適用およびアップグレードを実行できます。

  • 拡張パッチ適用機能: Oracle Grid InfrastructureまたはOracle Databaseホームにパッチを適用する場合、フリート・パッチ適用およびプロビジョニングでは、クラスタの一部またはすべてのノードに順次ではなくパラレルでパッチを適用することでパッチ適用プロセスを高速化するバッチ・モードが提供されます。

    Oracle Databaseホームに対して、非結合のノードのセットを定義できます。ノードの各セットは順次更新されます。それ自体で実行されるデータベース・インスタンスへの参照を含むセットを定義することで、サービス全体がオフラインになることがなくなり、ローリング更新の影響を最小化できます。この目的のために、バッチ・セットの定義に役立つsmartmoveオプションを使用できます。

    もう1つの拡張機能はアプリケーションの継続性との統合で、メンテナンスの影響の解消に役立ちます。これにより、クラスタ内でサービスを正常にドレインおよび再配置して、ユーザーに対してメンテナンスを完全に隠すことができます。

  • 通知: フリート・パッチ適用およびプロビジョニング・サーバーは、データ・センターで使用できるソフトウェア・ホームの中央リポジトリです。そのため、データ・センター全体の管理者が、自身の担当する領域に影響する可能性があるインベントリへの変更を把握する必要があります。

    フリート・パッチ適用およびプロビジョニングにより、各ユーザーがイメージ・シリーズ・イベントにサブスクライブできます。サブスクライバには、特定のイメージ・シリーズの使用可能なイメージに対する変更が電子メールで通知されます。また、クライアントでゴールド・イメージの作業用コピーが追加または削除されたときに、ユーザーに電子メールで通知できます。

  • カスタム・ワークフロー・サポート: イメージのインポート、ゴールド・イメージの作業用コピーの追加または削除、ソフトウェア・ホームの管理など、様々なフリート・パッチ適用およびプロビジョニング操作のアクションを作成できます。操作ごとに異なるアクションを定義して、操作が適用されるイメージのタイプでさらに区別できます。定義したアクションは、特定の操作の前後で実行でき、操作が適用されるデプロイメント(フリート・パッチ適用およびプロビジョニング・サーバー、フリート・パッチ適用およびプロビジョニング・クライアントを実行していないターゲット、またはフリート・パッチ適用およびプロビジョニング・クライアントを実行しているターゲット)で実行されます。

  • 失敗した操作の再開: イメージの追加、ゴールド・イメージの作業用コピーのプロビジョニング、あるいはスケーリング、パッチ適用またはアップグレードの実行などの操作が失敗した場合、フリート・パッチ適用およびプロビジョニングでエラーがレポートされて停止します。問題が解決した(たとえば、ターゲット・ノードのディレクトリの権限または所有権の構成ミスなど)後で、失敗したRHPCTLコマンドを再度実行して、失敗したところから再開できます。これにより、失敗の前に完了した作業を再度実行する必要がなくなります。

  • 監査コマンド: フリート・パッチ適用およびプロビジョニング・サーバーは、フリート・パッチ適用およびプロビジョニング操作すべての実行を記録し、その結果(成功または失敗)も記録します。監査メカニズムにより、様々なディメンションで監査ログを問い合せることができ、さらにその内容とサイズを管理できます。

注意:

  • HP-UXまたはWindowsオペレーティング・システムではフリート・パッチ適用およびプロビジョニングはサポートされません。

  • フリート・パッチ適用およびプロビジョニング・サーバーでは、オペレーティング・システムのイメージは管理されません。

この項には次のトピックが含まれます:

関連トピック

フリート・パッチ適用およびプロビジョニングのアーキテクチャ

フリート・パッチ適用およびプロビジョニングのアーキテクチャに関する概念です。

フリート・パッチ適用およびプロビジョニングのアーキテクチャは、フリート・パッチ適用およびプロビジョニング・サーバーと、任意の数のフリート・パッチ適用およびプロビジョニング・クライアントおよびターゲットで構成されます。高可用性を実現するために、マルチノード・クラスタにフリート・パッチ適用およびプロビジョニング・サーバーをデプロイすることをお薦めします。

フリート・パッチ適用およびプロビジョニング・サーバー・クラスタはすべてのデータのリポジトリです。データは大きく分けて次の2つのタイプがあります。

  • ゴールド・イメージ

  • ユーザー、ロール、権限およびアイデンティティに関連するメタデータ

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracle Databaseホーム、Oracle Grid Infrastructureホームおよびその他のアプリケーション・ソフトウェア・ホームをプロビジョニングするための中央サーバーとして機能し、フリート・パッチ適用およびプロビジョニング・サーバーと、フリート・パッチ適用およびプロビジョニング・クライアントのクラスタおよびターゲットをホストするクラスタで使用できるようにします。

ユーザーは、フリート・パッチ適用およびプロビジョニング・サーバーまたはフリート・パッチ適用およびプロビジョニング・クライアントを操作して、Oracleホームのデプロイメントのリクエストや、ゴールド・イメージの問合せを行います。ユーザーがゴールド・イメージを指定してOracleホームに対するリクエストを行う場合、フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・サーバーと通信してリクエストを渡します。フリート・パッチ適用およびプロビジョニング・サーバーが適切なアクションを実行してリクエストを処理します。具体的には、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)、ローカル・ファイル・システムなどの使用可能なテクノロジを使用して、ゴールド・イメージのコピーをインスタンス化し、フリート・パッチ適用およびプロビジョニング・クライアント・クラスタで利用できるようにします。

フリート・パッチ適用およびプロビジョニング・サーバーは、次に示すポートを使用して、フリート・パッチ適用およびプロビジョニング・クライアント(Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)以降が稼働)およびターゲット(ターゲットはOracle Grid Infrastructure 12cリリース1 (12.1.0.2)またはリリース11.2がインストールされているターゲットか、またはOracle Grid Infrastructureがインストールされていないターゲット)と通信します。これらのポートの一部は、表5-1の説明に従い構成できます。また、フリート・パッチ適用およびプロビジョニング・クライアントとの通信時に使用されるポートと、ターゲットとの通信時に使用されるポートは違うので注意してください。

表5-1 フリート・パッチ適用およびプロビジョニングの通信ポート

クライアント、ターゲット、または両方 プロトコル ポート 目的 説明

ターゲット

TCP

22

SSH

クライアントレス・ターゲットが含まれる認証ベースの操作。

クライアント

TCP

22

SSH

Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)以上のプロビジョニングにはSSHポートが必要です。(後続のフリート・パッチ適用およびプロビジョニング・サーバー/クライアント相互作用では、JMXパスが使用されます。)

クライアント

TCP

23795

JMXレジストリおよびサーバー・ポート

フリート・パッチ適用およびプロビジョニング・サーバーとフリート・パッチ適用およびプロビジョニング・クライアントとの通信の確立。

このポートは、srvctl modify rhpserver -port port_numberコマンドを使用して構成できます。

注意: 前述のコマンドでは、サービスを再起動する必要があります。

クライアント

UDP

受信接続を受け入れるには、フリート・パッチ適用およびプロビジョニング・サーバーのみでポート53を開いておく必要があります。

GNSポート

GNSは、フリート・パッチ適用およびプロビジョニング・クライアントが、フリート・パッチ適用およびプロビジョニング・サーバーを見つけるために使用されます。

ゾーン委任の有無にかかわらずGNSを構成できます。

両方

TCP

  • エフェメラル・ポート範囲から1つのRHPCTLコマンドにつき1つのポート、またはsrvctl modify rhpserver –pl_port port_numberコマンドで指定した1つのポート。

  • RHPCTLが実行されているサーバー(フリート・パッチ適用およびプロビジョニング・サーバーまたはクライアント)で受信接続を受け入れるには、進捗リスナー・ポートが開いている必要があります。

コマンド進捗リスナー

フリート・パッチ適用およびプロビジョニング・サーバーは、エフェメラル範囲からランダムなポートを開いて、クライアントやターゲットの進捗を監視するか、srvctl modify rhpserver –pl_port port_numberで指定した固定ポートを使用し、クライアント/ターゲット間での多重化を行います。

Oracle Database18cまたは2018年1月のRUを適用したOracle Database 12cリリース2 (12.2.0.1)以上を実行するクライアント

TCP

受信接続を受け入れるには、フリート・パッチ適用およびプロビジョニング・クライアント・サーバーでゴールド・イメージ・プロビジョニング用の6つのポートが必要です。

ゴールド・イメージは、Oracle Database18cクライアントおよび2018年1月のRUを適用したクライアントに転送します(フリート・パッチ適用およびプロビジョニング・サーバーでrhpctl add workingcopyコマンドを実行)

フリート・パッチ適用およびプロビジョニング・サーバーからクライアントへのゴールド・イメージのコピーの転送では、エフェメラル範囲から選択された6つのポート、またはsrvctl modify rhpserver -port_range port_number_rangeを使用して定義した範囲から6つのポートを使用します。この場合、使用する予想並列度(同時転送)に対応する範囲を指定します。

両方

TCP/UDP

固定ポートおよび構成可能なポート(表5-2を参照)

NFS

フリート・パッチ適用およびプロビジョニング・サーバーは、一時NFSマウント・ポイントを使用して、ソフトウェア・ホームをターゲットと、2018年1月のRUより前のOracle Database 12cリリース2 (12.2.0.1)クライアントに転送します。NFSは、クライアントおよびターゲット(すべてのバージョン)でのリモート・コマンドの実行をサポートするためにも使用されます。

表5-2 NFSのポート

ポート 説明

2049, 111

固定NFSポート

エフェメラル範囲から選択された6つのポート(デフォルト)または/etc/sysconfig/nfsで定義
構成可能なNFSポート。各項目の後に構成ファイル・エントリが続きます。
  • rpc: STATD_PORT
  • rpc status out: STATD_OUTGOING_PORT
  • rpc quota: RQUOTAD_PORT
  • rpc mountd: MOUNTD_PORT
  • rpc lockd tcp: LOCKD_TCPPORT
  • rpc lockd udp: LOCKD_UDPPORT

フリート・パッチ適用およびプロビジョニング・サーバー

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracle Automatic Storage Management (Oracle ASM)、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)、Grid Naming Service (GNS)、およびその他のコンポーネントを使用する、高可用性ソフトウェア・プロビジョニング・システムです。

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracleホームのプロビジョニングで主にセントラル・サーバーとして動作し、フリート・パッチ適用およびプロビジョニング・クライアントおよびターゲットがOracleホームを利用できるようにします。

フリート・パッチ適用およびプロビジョニング・サーバーの機能:

  • 管理ホームのゴールド・イメージおよびイメージ・シリーズを効率よく保存します(ユーザー、ロールおよび権限に関連する、個別のバイナリおよびメタデータを含む)。

  • リクエストに応じて、クライアントに利用可能なホームのリストを提供します。

  • ソフトウェア・ホームにパッチを1回適用してから、そのホームをフリート・パッチ適用およびプロビジョニング・クライアントまたはその他のターゲットにデプロイします。すべてのサイトにパッチを適用するのではありません。

  • 既存のデプロイに関するレポートが可能となります。

  • 物理サーバーと仮想マシンにホームをデプロイします。

  • イメージ・シリーズに対する変更をサブスクライバに通知します。

  • すべてのRHPCTLコマンドの実行の監査ログを保持します。

フリート・パッチ適用およびプロビジョニングのターゲット

フリート・パッチ適用およびプロビジョニングで認識されているコンピュータはターゲットと呼ばれます。

フリート・パッチ適用およびプロビジョニング・サーバーでは、新しいターゲットを作成でき、さらに、1つのオペレーティング・システムのみがインストールされているターゲットにOracle Grid Infrastructureをインストールして構成できます。その後、フリート・パッチ適用およびプロビジョニング・サーバーでは、他の多くの操作に加えて、それらのターゲットのデータベースおよびその他のソフトウェアのプロビジョニング、メンテナンスの実行、ターゲット・クラスタのスケーリングが可能です。フリート・パッチ適用およびプロビジョニングのコマンドはすべて、フリート・パッチ適用およびプロビジョニング・サーバーで実行されます。Oracle Clusterware 12cリリース2 (12.2)以降のフリート・パッチ適用およびプロビジョニング・クライアントを実行しているターゲットは、フリート・パッチ適用およびプロビジョニングの多くのコマンドを実行して、フリート・パッチ適用およびプロビジョニング・サーバーに新しいソフトウェアをリクエストしたり、他のタスクの中で、メンテナンスを自身で開始したりできます。

注意:

12cリリース2 (12.2)より前のOracle Clusterwareでフリート・パッチ適用およびプロビジョニング・クライアントを実行しているターゲットがある場合、イメージをクライアントとせずにRHPCTLユーティリティを使用してインポートできます。クライアントがOracle Clusterware 12cリリース2 (12.2)以上で実行される場合、フリート・パッチ適用およびプロビジョニング・クライアントを構成して有効化し、接続および資格証明の問題を簡略化する必要があります。

フリート・パッチ適用およびプロビジョニング・クライアント

フリート・パッチ適用およびプロビジョニング・クライアントは、Oracle Grid Infrastructureの一部です。ユーザーは、Oracleホームのデプロイのリクエストや使用可能なゴールド・イメージのリスト表示といったタスクを実行するために、フリート・パッチ適用およびプロビジョニング・クライアントで操作を行います。

ユーザーがゴールド・イメージを指定してOracleホームをリクエストする場合、フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・サーバーと通信してリクエストを渡します。フリート・パッチ適用およびプロビジョニング・サーバーは、ゴールド・イメージの作業用コピーをインスタンス化し、Oracle ACFSまたは別のローカル・ファイル・システムを使用してフリート・パッチ適用およびプロビジョニング・クライアントで使用可能にすることによって、リクエストを処理します。

フリート・パッチ適用およびプロビジョニング・クライアント:

  • Oracle ACFSを使用して、ローカル・ホームとして迅速にプロビジョニングできるゴールド・イメージの作業用コピーを格納できます。新しいホームは、Oracle ACFSスナップショットを使用してすぐに作成したり元に戻すことができます。

    注意:

    Oracle ACFS以外のローカル・ファイル・システムも使用できます。

  • フリート・パッチ適用およびプロビジョニング・サーバーの使用可能なホームのリストを提供します。

  • Oracle Clusterware 12c リリース2 (12.2)のすべての機能を使用でき、Oracle Clusterware 12c リリース2 (12.2)以降のフリート・パッチ適用およびプロビジョニング・サーバーと通信できます。

関連トピック

フリート・パッチ適用およびプロビジョニング操作の認証オプション

一部のRHPCTLコマンドでは、オプション・パラメータとして認証の選択肢が表示されます。

フリート・パッチ適用およびプロビジョニング・クライアントでRHPCTLコマンドを実行する場合、フリート・パッチ適用およびプロビジョニング・サーバーでRHPCTLコマンドを実行する場合、およびフリート・パッチ適用およびプロビジョニング・クライアントで操作を行う場合、認証オプションを指定する必要はありません。これは、クライアントが作成されるときにサーバーとクライアント間で信頼関係が確立され、トランザクションが実行されるたびに、認証が内部で処理されるためです。(認証オプションを指定する必要があるサーバー/クライアント通信の唯一の条件は、サーバーが新しいOracle Grid Infrastructureデプロイメントをプロビジョニングする場合です。この場合、クライアントはまだ存在しません。)

フリート・パッチ適用およびプロビジョニング・クライアントではないターゲットで操作するには、フリート・パッチ適用およびプロビジョニング・サーバーに情報を指定して、ターゲットによる認証を可能にする必要があります。使用できるオプションは次のとおりです。

  • ターゲットのrootパスワード(stdin上)を指定します。

  • ターゲットのsudoユーザー名、sudoバイナリ・パス、およびパスワード(stdin)を指定します。

  • ローカルの暗号化されたストアからパスワード(rootまたはsudouser)を非対話的に指定します(-cred認証パラメータを使用)。

  • SSLで暗号化されたパスワードなしの認証の場合は、フリート・パッチ適用およびプロビジョニング・サーバーに格納されているアイデンティティ・ファイルへのパスを指定します(-auth sshkeyオプションを使用)。

パスワードなしの認証の詳細

フリート・パッチ適用およびプロビジョニング・サーバーでは、鍵のペアを使用してSSHを介してターゲットを認証できます。このオプションを有効にするには、フリート・パッチ適用およびプロビジョニング・サーバーのcrsusrとターゲットのrootまたはsudouserの間でユーザー等価関係を確立する必要があります。

注意:

この等価関係を作成する手順は、プラットフォームによって異なるため、ここでは詳しく説明しません。Linuxの場合、ターゲットで実行するコマンドssh-keygen、およびフリート・パッチ適用およびプロビジョニング・サーバーで実行するコマンドssh-copy-idを参照してください。
たとえば、フリート・パッチ適用およびプロビジョニング・サーバーのcrsusrとターゲット・ノードnonRHPClient4004.example.comのrootの間でユーザー等価関係が確立されており、フリート・パッチ適用およびプロビジョニング・サーバーの/home/oracle/rhp/ssh-key/key –pathに鍵の情報が保存されている場合、次のコマンドで、パスワードなし認証を使用して、ターゲット・ノードに指定のゴールド・イメージのコピーをプロビジョニングします。
$ rhpctl add workingcopy -workingcopy db12102_160607wc1 –image db12102_160607
  -targetnode nonRHPClient4004.example.com –path /u01/app/oracle/12.1/rhp/dbhome_1
  -oraclebase /u01/app/oracle -auth sshkey -arg1 user:root -arg2
   identity_file:/home/oracle/rhp/ssh-key/key
フリート・パッチ適用およびプロビジョニング・サーバーのcrsusrとターゲットの特権ユーザー(root以外)の間の等価関係の場合、コマンドの-auth部分は次のようになります。
-auth sshkey -arg1 user:ssh_user -arg2 identity_file:path_to_identity_file_on_RHPS
 -arg3 sudo_location:path_to_sudo_binary_on_target

関連トピック

フリート・パッチ適用およびプロビジョニングのロール

管理者は、ロールをフリート・パッチ適用およびプロビジョニングのユーザーに割り当てます(各ロールにはアクセスレベル権限が定義されています)。フリート・パッチ適用およびプロビジョニング・クライアントのユーザーにも、特定のロールが割り当てられます。フリート・パッチ適用およびプロビジョニングには、基本組込みロールと複合組込みロールが含まれます。

基本組込みロール

基本組込みロールとその機能:

  • GH_ROLE_ADMIN: ロールに関連するすべてのための管理ロール。このロールを割り当てられたユーザーは、rhpctl verb roleコマンドを実行できます。

  • GH_SITE_ADMIN: フリート・パッチ適用およびプロビジョニング・クライアントに関連するすべてのための管理ロール。このロールを割り当てられたユーザーは、rhpctl verb clientコマンドを実行できます。

  • GH_SERIES_ADMIN: イメージ・シリーズに関連するすべてのための管理ロール。このロールを割り当てられたユーザーは、rhpctl verb seriesコマンドを実行できます。

  • GH_SERIES_CONTRIB: このロールを割り当てられたユーザーは、シリーズへのイメージの追加(rhpctl insertimage seriesコマンド使用)またはシリーズからのイメージの削除(rhpctl deleteimage seriesコマンド使用)を行うことができます。

  • GH_WC_ADMIN: ゴールド・イメージの作業用コピーに関連するあらゆるものを対象とする管理ロール。このロールを割り当てられたユーザーは、rhpctl verb workingcopyコマンドを実行できます。

  • GH_WC_OPER: このロールでは、rhpctl add workingcopyコマンドを使用して、自分または他のユーザーのためにゴールド・イメージの作業用コピーを作成できます。他のユーザーのために作成する場合は-userオプションを指定します。このロールが割り当てられたユーザーには管理権限はありません。自分が作成するゴールド・イメージの作業用コピーのみ管理できます。

  • GH_WC_USER: このロールでは、rhpctl add workingcopyコマンドを使用してゴールド・イメージの作業用コピーを作成できます。このロールが割り当てられたユーザーには管理権限はありません。自分で作成した作業用コピーのみ削除できます。

  • GH_IMG_ADMIN: イメージに関連するすべてのための管理ロール。このロールが割り当てられたユーザーは、rhpctl verb imageコマンドを実行できます。

  • GH_IMG_USER: このロールでは、rhpctl add | import imageコマンドを使用してイメージを作成できるようになります。このロールが割り当てられたユーザーには管理権限はありません。自分で作成したイメージのみ削除できます。

  • GH_IMG_TESTABLE: このロールでは、TESTABLE状態のイメージの作業用コピーを追加できるようになります。このロールが割り当てられたユーザーが作業用コピーを追加するためには、GH_WC_ADMINロールまたはGH_WC_USERロールのいずれかの割当てが必要です。

  • GH_IMG_RESTRICT: このロールでは、RESTRICTED状態のイメージから作業用コピーを追加できるようになります。このロールが割り当てられたユーザーが作業用コピーを追加するためには、GH_WC_ADMINロールまたはGH_WC_USERロールのいずれかの割当てが必要です。

  • GH_IMG_PUBLISH: このロールが割り当てられたユーザーは、イメージを別の状態にプロモートするか、PUBLISHED状態のイメージをTESTABLEまたはRESTRICTED状態にリトラクトできます。

  • GH_IMG_VISIBILITY: このロールが割り当てられたユーザーは、rhpctl allow | disallow imageコマンドを使用して、プロモート済または公開済のイメージへのアクセスを変更できます。

複合組込みロール

複合組込みロールとその機能:

  • GH_SA: フリート・パッチ適用およびプロビジョニング・サーバー上のOracle Grid Infrastructureユーザーは自動的にこのロールを継承します。

    GH_SAロールに含まれる基本組込みロール: GH_ROLE_ADMIN、GH_SITE_ADMIN、GH_SERIES_ADMIN、GH_SERIES_CONTRIB、GH_WC_ADMIN、GH_IMG_ADMIN、GH_IMG_TESTABLE、GH_IMG_RESTRICT、GH_IMG_PUBLISHおよびGH_IMG_VISIBILITY。

  • GH_CA: フリート・パッチ適用およびプロビジョニング・クライアント上のOracle Grid Infrastructureユーザーは自動的にこのロールを継承します。

    GH_CAロールに含まれる基本組込みロール: GH_SERIES_ADMIN、GH_SERIES_CONTRIB、GH_WC_ADMIN、GH_IMG_ADMIN、GH_IMG_TESTABLE、GH_IMG_RESTRICT、GH_IMG_PUBLISHおよびGH_IMG_VISIBILITY。

  • GH_OPER: このロールに含まれる基本組込みロール: GH_WC_OPER、GH_SERIES_ADMIN、GH_IMG_TESTABLE、GH_IMG_RESTRICTおよびGH_IMG_USER。このロールが割り当てられたユーザーは、自分が作成したイメージのみを削除できます。

フリート・パッチ適用およびプロビジョニング・サーバーで使用できるG1というゴールド・イメージについて考えてみます。

また、フリート・パッチ適用およびプロビジョニング・クライアントCl1のユーザーU1がGH_WC_USERロールを持っているとします。U1がゴールド・イメージG1に基づくOracleホームのプロビジョニングをリクエストすると、GH_WC_USERロールによって付与される権限によりU1はそれを実行できます。ただし、U1がG1の削除をリクエストした場合、GH_WC_USERロールには必要な権限が含まれないため、そのリクエストは拒否されます。

フリート・パッチ適用およびプロビジョニング・サーバーは、フリート・パッチ適用およびプロビジョニング・クライアントにユーザー・ロール・マッピングを関連付けることができます。フリート・パッチ適用およびプロビジョニング・サーバーがユーザー・ロール・マッピングを委任すると、フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・クライアントに属するすべてのユーザーに対して、フリート・パッチ適用およびプロビジョニング・サーバー上のユーザーとロールのマッピングを変更できます。つまり、フリート・パッチ適用およびプロビジョニング・サーバーは、フリート・パッチ適用およびプロビジョニング・クライアント・サイトからのユーザーIDを、そのサイトのクライアント・クラスタ名でのみ修飾するということです。したがって、フリート・パッチ適用およびプロビジョニング・クライアントCL1は、CL2上のユーザーのユーザー・マッピングを更新できません(CL2は別のフリート・パッチ適用およびプロビジョニング・クライアントのクラスタ名)。

フリート・パッチ適用およびプロビジョニングのイメージ

デフォルトでは、rhpctl import imageまたはrhpctl add imageを使用してゴールド・イメージを作成した場合、そのイメージを作業用コピーのプロビジョニングにすぐ使用できます。ただし、一定の条件の下では、イメージへのアクセスを制限して、他の人にイメージのテストまたは検証を要求してから、一般に使用できるようにする必要があります。

同一のリリース・バージョン、特定のユーザーによって公開されたゴールド・イメージ、組織内の特定の部門用のイメージなど、互いに関連するゴールド・イメージ・シリーズとしてまとめて分類できる一連のゴールド・イメージをフリート・パッチ適用およびプロビジョニング・サーバーで作成することもできます。

関連トピック

フリート・パッチ適用およびプロビジョニング・サーバー間でのゴールド・イメージの配布

フリート・パッチ適用およびプロビジョニングでは、フリート・パッチ適用およびプロビジョニング・サーバー間でゴールド・イメージを自動的に共有および同期化できます。

フリート・パッチ適用およびプロビジョニング・アーキテクチャでは、1つのフリート・パッチ適用およびプロビジョニング・サーバーが、一連のフリート・パッチ適用およびプロビジョニング・クライアントおよび指定のデータ・センター(またはデータ・センターのネットワーク・セグメント)内のターゲットを管理します。データ・センターまたはセグメント化されたデータ・センターが複数存在する場合は、複数のフリート・パッチ適用およびプロビジョニング・サーバーを使用する必要があります。
フリート・パッチ適用およびプロビジョニング・アーキテクチャでは、1つのフリート・パッチ適用およびプロビジョニング・サーバーが、一連のフリート・パッチ適用およびプロビジョニング・クライアントおよび指定のデータ・センター(またはデータ・センターのネットワーク・セグメント)内のターゲットを管理します。複数のデータ・センターまたはセグメント化されたデータ・センターが存在する場合は、複数のフリート・パッチ適用およびプロビジョニング・サーバーを使用して、複数の設備資産間での大規模な標準化を促進する必要があります。
フリート・パッチ適用およびプロビジョニング・サーバーには、その有効範囲に専用のゴールド・イメージを作成および管理する機能があるため、ローカルのカスタマイズがシームレスにサポートされます。
最初に、2つのフリート・パッチ適用およびプロビジョニング・サーバー間でピア関係を確立する必要があります。登録では、フリート・パッチ適用およびプロビジョニング・サーバー・クラスタの名前が使用されます。2つのクラスタの名前を同じにすることはできますが、命名制限が1つあります。フリート・パッチ適用およびプロビジョニング・サーバー(たとえば、RHPS_1)は、ピアのフリート・パッチ適用およびプロビジョニング・サーバーの名前がRHPS_1の管理ドメイン内の高速ホーム・プロビジョニング・クライアントまたはターゲットと同じ名前である場合、そのピア・フリート・パッチ適用およびプロビジョニング・サーバーを登録できません。
  1. フリート・パッチ適用およびプロビジョニング・サーバーで、次のように、サーバーの構成情報を含むファイルを作成します。
    $ rhpctl export server -serverdata file_path
  2. ファイルを2番目のフリート・パッチ適用およびプロビジョニング・サーバーにコピーします。
  3. 次のように、2番目のフリート・パッチ適用およびプロビジョニング・サーバーの登録を完了します。
    $ rhpctl register server -server server_cluster_name -serverdata file {-root
  | {-sudouser user_name -sudopath sudo_path}}

    資格証明は、1番目のフリート・パッチ適用およびプロビジョニング・サーバーのログイン資格証明です。

フリート・パッチ適用およびプロビジョニング・サーバーをピアとして登録すると、次のコマンドで、サーバーのピア(または複数のピア)が表示されます。
$ rhpctl query peerserver
次のように、ピア・フリート・パッチ適用およびプロビジョニング・サーバーのイメージを調べることができます。
$ rhpctl query image -server server_cluster_name

前述のコマンドでは、特定のピア・フリート・パッチ適用およびプロビジョニング・サーバーのすべてのイメージが表示されます。また、-image image_nameパラメータと一緒にピア・サーバーを指定することで、特定ピア・サーバーの特定イメージの詳細を表示できます。

フリート・パッチ適用およびプロビジョニング・サーバーは複数のピアを持つことができます。ただし、Oracleでは、ピア間の結合関係はサポートされません。たとえば、RHPS_1がRHPS_2のピアであり、RHPS_2がRHPS_3のピアである場合、RHPS_1とRHPS_3の間では関係が確立されたり、暗黙的に関係を持つことはありません。ただし、これらは必要に応じてピアにすることができます。

ピア・フリート・パッチ適用およびプロビジョニング・サーバーからゴールド・イメージのコピーを1つ以上取得するには、次のようにします。
$ rhpctl instantiate image –server server_cluster_name
rhpctl instantiate imageコマンドを実行して、自動更新メカニズムをアクティブ化します。その時点から、ピア・フリート・パッチ適用およびプロビジョニング・サーバー(RHPS_2など)にゴールド・イメージを作成すると、インスタンス化操作を実行したフリート・パッチ適用およびプロビジョニング・サーバー(RHPS_1など)に自動的にコピーされる候補になります。新しいゴールド・イメージが自動的にコピーされるかどうかは、そのイメージが、コマンドに含めることができるインスタンス化パラメータに関連しているかどうかによって決まります。

  • -all: RHPS_2で作成されたすべてのゴールド・イメージのRHPS_1への自動プッシュを作成します。

  • -image image_name: RHPS_2で作成された指定のイメージの新しいすべての子孫ゴールド・イメージのRHPS_1への自動プッシュを作成します。指定のイメージの子孫は、rhpctl add imageコマンドを使用してRHPS_2で作成されるイメージです。

  • -series series_name: RHPS_2の指定のシリーズに追加されたすべてのゴールド・イメージのRHPS_1への自動プッシュを作成します。

  • -imagetype image_type: RHPS_2で作成された、指定のイメージ・タイプのすべてのゴールド・イメージのRHPS_1への自動プッシュを作成します。

rhpctl instantiate imageコマンドで確立された更新の受信を停止するには、rhpctl uninstantiate imageを実行し、ピア・フリート・パッチ適用およびプロビジョニング・サーバーを指定し、さらにall、イメージ名、イメージ・シリーズ名、またはイメージ・タイプのいずれかを指定します。

次のように、フリート・パッチ適用およびプロビジョニング・サーバーのいずれかでピア関係を終了します。
$ rhpctl unregister server -server server_cluster_name

関連トピック

フリート・パッチ適用およびプロビジョニング・サーバーの監査

フリート・パッチ適用およびプロビジョニング・サーバーは、フリート・パッチ適用およびプロビジョニング操作すべての実行を記録し、それらの操作が成功したか失敗したかも記録します。

監査メカニズムにより、管理者が様々なディメンションで監査ログを問い合せることができ、さらにその内容とサイズを管理できます。

フリート・パッチ適用およびプロビジョニングの通知

フリート・パッチ適用およびプロビジョニング・サーバーは、データ・センターで使用できるソフトウェア・ホームの中央リポジトリです。そのため、データ・センター全体の管理者が、自身の担当する領域に影響する可能性があるインベントリへの変更を把握する必要があります。

イメージ・シリーズ・イベントへのサブスクリプションを作成できます。フリート・パッチ適用およびプロビジョニングにより、サブスクライブするロールまたは複数のユーザーに、イメージの追加や削除などの、シリーズの使用可能なイメージに対する変更が電子メールで通知されます。シリーズごとに固有のサブスクライバのグループを作成できます。

また、ターゲットに対するゴールド・イメージの作業用コピーの追加または削除が実行されたときに、作業用コピーの所有者と追加ユーザーに電子メールで通知できます。追加のフリート・パッチ適用およびプロビジョニングのイベントに関する通知を有効にする場合は、次の項で説明するように、ユーザー定義のアクションを作成できます。

フリート・パッチ適用およびプロビジョニングの実装

フリート・パッチ適用およびプロビジョニングの実装には、フリート・パッチ適用およびプロビジョニング・サーバーの作成、サーバーへのゴールド・イメージの追加、およびソフトウェアをプロビジョニングするゴールド・イメージの作業用コピーの作成が含まれます。

Oracle Clusterwareをインストールして構成した後で、フリート・パッチ適用およびプロビジョニングを構成して、使用を開始できます。データベースなどのソフトウェア・ホームのゴールド・イメージを作成および格納するフリート・パッチ適用およびプロビジョニング・サーバーを作成する必要があります。

フリート・パッチ適用およびプロビジョニング・サーバーの作成

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracle ACFSファイル・システムに作成されたリポジトリを使用します。ここに、クライアントおよびターゲットで利用できるようにするすべてのソフトウェア・ホームを格納します。

フリート・パッチ適用およびプロビジョニング・サーバーを作成する手順は、次のとおりです。

  1. Oracle ASM Configuration Assistant (ASMCA)を使用して、次のように、ソフトウェアを格納するOracle ASMディスク・グループをフリート・パッチ適用およびプロビジョニング・サーバー上に作成します。
    $ Grid_home/bin/asmca

    このディスク・グループはソフトウェアの格納に使用されるため50 GB以上にすることをお薦めします。

    注意:

    このディスク・グループのOracle ASM Dynamic Volume Manager (Oracle ADVM)互換性設定は12.1に設定する必要があります。

  2. クラスタのすべてのノードに存在するマウント・パスを指定します。フリート・パッチ適用およびプロビジョニング・サーバーはこのパスを使用してゴールド・イメージをマウントします。
    $ mkdir -p storage_path/images
  3. rootとして、次のようにフリート・パッチ適用およびプロビジョニング・サーバーのリソースを作成します。
    # Grid_home/bin/srvctl add rhpserver -storage storage_path
    -diskgroup disk_group_name
  4. 次のようにして、フリート・パッチ適用およびプロビジョニング・サーバーを起動します。
    $ Grid_home/bin/srvctl start rhpserver

フリート・パッチ適用およびプロビジョニング・サーバーの起動後に、さらにフリート・パッチ適用およびプロビジョニングを管理するにはフリート・パッチ適用およびプロビジョニング・コントロール(RHPCTL)ユーティリティを使用します。

関連トピック

フリート・パッチ適用およびプロビジョニング・サーバーへのゴールド・イメージの追加

後でソフトウェアをプロビジョニングするために、RHPCTLを使用してゴールド・イメージを追加します。

フリート・パッチ適用およびプロビジョニング・サーバーは、ソフトウェア・ホームのゴールド・イメージの保存および提供を行います。このようなイメージは、フリート・パッチ適用およびプロビジョニング・サーバーでインスタンス化される必要があります。

注意:

イメージは読取り専用です。イメージからプログラムを実行することはできません。利用可能なソフトウェア・ホームをイメージから作成するには、ゴールド・イメージの作業用コピーを作成する必要があります。イメージをソフトウェア・ホームとして直接使用することはできません。ただし、イメージを使用して作業用コピー(ソフトウェア・ホーム)を作成できます。

次の方法の1つを使用して、フリート・パッチ適用およびプロビジョニング・サーバーにソフトウェアをインポートできます。

  • 次のコマンドを使用して、フリート・パッチ適用およびプロビジョニング・サーバーにインストールされたホームからイメージをインポートできます。

    rhpctl import image -image image_name -path path_to_installed_home
  [-imagetype ORACLEDBSOFTWARE | ORACLEGISOFTWARE | ORACLEGGSOFTWARE | SOFTWARE]

  • フリート・パッチ適用およびプロビジョニング・クライアントから次のコマンドを使用して、フリート・パッチ適用およびプロビジョニング・クライアントにインストールされたホームからイメージをインポートできます。

    rhpctl import image -image image_name -path path_to_installed_home

  • 次のコマンドを使用して、既存の作業用コピーからイメージを作成できます。

    rhpctl add image –image image_name -workingcopy working_copy_name

前のリストの最初の2つのコマンドを使用して、イメージ・リポジトリをシードして、時間の経過とともにイメージを追加します。既存のゴールド・イメージに適用されるパッチを含むゴールド・イメージを作成するワークフローの一部として、フリート・パッチ適用およびプロビジョニング・サーバーで3つ目のコマンドを使用します。

また、これらの3つのコマンドを実行すると、次のようなOracle ACFSファイル・システムがフリート・パッチ適用およびプロビジョニングのルート・ディレクトリに作成されます。

/u01/rhp/images/images/RDBMS_121020617524

関連トピック

イメージの状態

イメージの状態をTESTABLEまたはRESTRICTEDに設定すると、GH_IMG_TESTABLEまたはGH_IMG_RESTRICTロールを持つユーザーのみがこのイメージから作業用コピーをプロビジョニングできます。イメージのテストまたは検証が終了したら、rhpctl promote image -image image_name -state PUBLISHEDコマンドを実行して、状態を変更し、イメージを一般に使用できるようにします。新しいゴールド・イメージを追加したときのデフォルトのイメージ状態はPUBLISHEDですが、rhpctl add imageコマンドとrhpctl import imageコマンドを使用して、異なる状態を指定することもできます。

イメージ・シリーズ

イメージ・シリーズは、様々なゴールド・イメージを論理的な順序でグループ化する方法として便利です。

フリート・パッチ適用およびプロビジョニングは、各イメージを他のイメージとは独立したエンティティとして扱います。イメージが特定の体系に沿っている場合でも、イメージ間に関係はないとみなされます。イメージ管理者は、ユーザーのコミュニティで理解できる論理的な方法でイメージに名前を付けることができますが、これによってフリート・パッチ適用およびプロビジョニングのフレームワーク内に管理グループが作成されることはありません。

rhpctl add seriesコマンドを使用して、イメージ・シリーズを作成し、1つ以上のイメージをそのシリーズに関連付けます。イメージ・シリーズ内のイメージのリストは、順序付きのリストです。rhpctl insertimage seriesとrhpctl deleteimage seriesを使用して、イメージ・シリーズに対してイメージを追加および削除します。これらのコマンドを使用してシリーズ内のイメージの順序を変更することもできます。

insertimageとdeleteimageのコマンドでは、実際のゴールド・イメージがインスタンス化されることも削除されることもありませんが、リストの変更のみ行われます。また、イメージは、複数のシリーズに属する(またはシリーズにまったく属さない)ことができます。

イメージ・タイプ

ゴールド・イメージを追加またはインポートするときに、イメージ・タイプを指定する必要があります。

Oracle Clusterwareには、次の組込みベース・イメージ・タイプが用意されています。
  • ORACLEDBSOFTWARE
  • ORACLEGISOFTWARE
  • ORACLEGGSOFTWARE
  • SOFTWARE

すべてのゴールド・イメージがイメージ・タイプを持つ必要があり、独自のイメージ・タイプを作成できます。新しいイメージ・タイプは、いずれかの組込みのタイプに基づく必要があります。イメージ・タイプにより、Oracle Grid InfrastructureおよびOracle Databaseホームを管理するためにその機能がフリート・パッチ適用およびプロビジョニングに適用されます。また、フリート・パッチ適用およびプロビジョニングでイメージ・タイプを使用して、カスタム・ワークフロー・サポート・フレームワークを編成します。

カスタム・イメージ・タイプの作成

カスタム・イメージ・タイプを作成するには、rhpctl add imagetypeコマンドを使用します。

たとえば、ORACLEDBSOFTWAREイメージ・タイプに基づくDBTESTというイメージ・タイプを作成するには、次のコマンドを実行します。

$ rhpctl add imagetype -imagetype DBTEST -basetype ORACLEDBSOFTWARE

注意:

既存のイメージ・タイプに基づくイメージ・タイプを作成する場合、新しいイメージ・タイプでは、ベースとなるタイプから(カスタム・ワークフロー・サポートの)ユーザー・アクションは継承されません。

ゴールド・イメージのコピーのプロビジョニング

RHPCTLを使用して、ゴールド・イメージのコピーを、フリート・パッチ適用およびプロビジョニング・サーバー、クライアント、およびターゲットに向けてプロビジョニングします。

ゴールド・イメージを作成し、インポートした後、フリート・パッチ適用およびプロビジョニング・サーバー、フリート・パッチ適用およびプロビジョニング・クライアント、またはターゲットでゴールド・イメージのコピー(「作業用コピー」と呼ぶ)を追加することで、ソフトウェアをプロビジョニングできます。その後、サーバーまたはクライアントでソフトウェア・プロビジョニング・コマンドを実行できます。

  • フリート・パッチ適用およびプロビジョニング・サーバーに作業用コピーを作成するには、次の手順を実行します。
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
  • フリート・パッチ適用およびプロビジョニング・クライアントのローカル・ファイル・システムに作業用コピーを作成するには、次のコマンドを使用します。
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
   -storagetype LOCAL -path path_to_software_home
  • フリート・パッチ適用およびプロビジョニング・サーバーから、フリート・パッチ適用およびプロビジョニング・クライアントに作業用コピーを作成するには、次の手順を実行します。
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
   -client client_cluster_name

注意:

  • -pathパラメータに指定するディレクトリは空であることが必要です。

  • システム・エラーまたはユーザー・エラーによって中断または失敗した場合には、プロビジョニング・コマンドを再実行できます。報告されたエラーを修正してからコマンドを再実行すると、失敗したところから再開します。

関連トピック

フリート・パッチ適用およびプロビジョニングでのユーザー・グループ管理

移動操作またはアップグレード操作の一部としてゴールド・イメージの作業用コピーを作成すると、フリート・パッチ適用およびプロビジョニングにより、新しい作業用コピーのオペレーティング・システムのグループがソースのソフトウェア・ホームのものと一致するように構成されます(移動元またはアップグレード元のホームは管理対象かどうかを問いません)。

SOFTWAREイメージ・タイプのゴールド・イメージを作成した場合、ソースのユーザー・グループが継承されることはなく、このタイプのイメージにユーザー・グループ情報が含まれることはありません。rhpctl add workingcopyコマンドを使用してSOFTWAREゴールド・イメージから作業用コピーをプロビジョニングする場合、必要に応じて-groupsパラメータを使用して作業用コピーのユーザー・グループを構成できます。

rhpctl move database、rhpctl move gihome、rhpctl upgrade databaseおよびrhpctl upgrade gihomeのすべてのコマンドで、ソース・ホーム(フリート・パッチ適用およびプロビジョニングを使用してプロビジョニングした管理対象外ホームまたは管理対象ホーム(作業用コピー))および宛先ホーム(作業用コピーである必要があります)を指定する必要があります。

rhpctl add workingcopyコマンドを使用して宛先ホームをプロビジョニングした場合、移動操作またはアップグレード操作を実行する前に、ソース・ホームで構成されたグループを宛先ホームのグループと一致させる必要があります。フリート・パッチ適用およびプロビジョニングでは、追加操作の一部としてグループが構成されます。

ソースのソフトウェア・ホーム(rhpctl import imageコマンドを使用)または作業用コピー(rhpctl add imageコマンドを使用)からORACLEGISOFTWAREまたはORACLEDBSOFTWAREイメージ・タイプのゴールド・イメージを作成すると、ゴールド・イメージが、ソースで構成されたOracleユーザー・グループを継承します。この機能は無効にできません。

次の各項で説明するように、イメージ・タイプとユーザー・グループに応じて、rhpctl add workingcopyコマンドを使用してORACLEGISOFTWAREおよびORACLEDBSOFTWAREの作業用コピーに対してユーザー・グループを定義できます。

この項では、フリート・パッチ適用およびプロビジョニングでユーザー・グループ構成を管理する方法と、rhpctl add workingcopyの-groupsコマンドライン・オプションがどのように機能するかについて説明します。

ORACLEGISOFTWARE (Oracle Grid Infrastructure 11g リリース2 (11.2)と、12c リリース1 (12.1)およびリリース2 (12.2))

Oracle Grid Infrastructureのゴールド・イメージの作業用コピーをプロビジョニングすると、プロビジョニングのタイプ(通常のプロビジョニングか、ソフトウェアのみか、および-localパラメータを指定したかどうか)、およびrhpctl add workingcopyで-groupsパラメータを指定したかどうかに応じて、作業用コピーでグループが設定されます。-softwareonlyコマンド・パラメータを指定するか、rhpctl add workingcopyコマンドでレスポンス・ファイルを使用して、Oracle Grid InfrastructureソフトウェアにOSDBAおよびOSASMユーザー・グループを定義できます。

-softwareonlyコマンド・パラメータを使用してOracle Grid Infrastructureソフトウェアのみをプロビジョニングしている場合は、-groupsパラメータを使用することはできず、フリート・パッチ適用およびプロビジョニングでアクティブなGridホームからOSDBAおよびOSASMユーザー・グループ情報が取得されます。

rhpctl add workingcopyで-localコマンド・パラメータ(これは、-softwareonlyコマンド・パラメータを使用する場合にのみ有効)を使用すると、フリート・パッチ適用およびプロビジョニングで、コマンドラインからグループの値が取得される(-groupsパラメータを使用)か、フリート・パッチ適用およびプロビジョニングがゴールド・イメージのosdbagrpバイナリから取得するデフォルト値が使用されます。

前述のものがいずれも該当しない場合、インストーラのデフォルトのユーザー・グループが使用されます。

レスポンス・ファイルからの情報を使用して作業用コピーをプロビジョニングおよび構成している場合、フリート・パッチ適用およびプロビジョニングの動作は次のとおりです。

  1. コマンドラインからユーザー・グループの値を使用します(OSDBAまたはOSASM、あるいはその両方に対して指定されている場合)。

  2. コマンドラインで値を指定しない場合、レスポンス・ファイルに定義されたユーザー・グループ情報が取得されます。

OSOPER Oracleグループを定義している場合は、その後、再度-softwareonlyコマンド・パラメータを使用するか、rhpctl add workingcopyコマンドでレスポンス・ファイルを使用できます。

-softwareonlyコマンド・パラメータを使用する場合は、コマンドラインで値を指定する(-groupsパラメータを使用)ことも、ユーザー・グループを未定義のままにすることもできます。

レスポンス・ファイルからの情報を使用してゴールド・イメージの作業用コピーをプロビジョニングおよび構成している場合、コマンドラインで値を指定することも、レスポンス・ファイルに含まれる情報を使用することも、OSOPER Oracleグループを未定義のままにすることもできます。

ORACLEDBSOFTWARE (Oracle Database 11g リリース2 (11.2)と、12c リリース1 (12.1)およびリリース2 (12.2))

Oracle Databaseソフトウェアの作業用コピーをプロビジョニングしており、Oracleグループを定義する場合は、rhpctl add workingcopyコマンドで-groupsコマンド・パラメータを使用します。Oracle Databaseの各種リリースで使用できるOracleグループは、次のとおりです。

  • Oracle Database 11gリリース2(11.2)

    • OSDBA
    • OSOPER

  • Oracle Database 12c リリース1 (12.1)

    • OSDBA
    • OSOPER
    • OSBACKUP
    • OSDG
    • OSKM

  • Oracle Database 12cリリース2 (12.2)

    • OSDBA
    • OSOPER
    • OSBACKUP
    • OSDG
    • OSKM
    • OSRAC

定義しているグループが前述のいずれでも(OSOPERを除く)、フリート・パッチ適用およびプロビジョニングで、コマンドラインからグループの値が取得される(-groupsパラメータを使用)か、フリート・パッチ適用およびプロビジョニングがゴールド・イメージのosdbagrpバイナリから取得するデフォルト値が使用されます。

データベース・ユーザーが属しているグループのリストに、osdbagrpバイナリから選択したグループが含まれていない場合(idコマンドで確認)、インストーラのデフォルトのユーザー・グループが使用されます。それ以外の場合、データベース・ユーザーはrhpctl add workingcopyコマンドを実行しているユーザーです。

プロビジョニングするソフトウェアのための記憶域オプション

フリート・パッチ適用およびプロビジョニングでゴールド・イメージの作業用コピーを格納する3つの記憶域オプションのいずれかを選択します。

rhpctl add workingcopyコマンドを使用してソフトウェアをプロビジョニングする場合、3つの記憶域オプションから選択して、フリート・パッチ適用およびプロビジョニングでそのソフトウェアを次の場所に配置できます。

  • フリート・パッチ適用およびプロビジョニングで管理されるOracle ACFS共有ファイル・システム(データベース・ホームの場合のみ)

  • フリート・パッチ適用およびプロビジョニングで管理されていないローカル・ファイル・システム

–storagetypeと–pathのパラメータを指定してrhpctl add workingcopyコマンドを使用すると、プロビジョニングした作業用コピーを格納する場所を選択できます。パラメータが適用可能かどうかは、作業用コピーのプロビジョニング対象の1つ以上のノードがフリート・パッチ適用およびプロビジョニング・サーバーであるか、フリート・パッチ適用およびプロビジョニング・クライアントであるか、非フリート・パッチ適用およびプロビジョニング・クライアントであるかに応じて異なります。–stroragetypeパラメータの値は、次の値から選択できます。

  • RHP_MANAGED: フリート・パッチ適用およびプロビジョニング・サーバーおよびフリート・パッチ適用およびプロビジョニング・クライアントに使用可能なこの値を選択すると、Oracle ACFS共有ファイル・システムに作業用コピーが格納されます。フリート・パッチ適用およびプロビジョニングで記憶域オプションが管理されるため、このオプションでは–pathパラメータは使用されません。

    注意:

    • RHP_MANAGED記憶域にOracle Grid Infrastructureホームを格納することはできません。

    • Oracle ASMディスク・グループを含むように構成されたフリート・パッチ適用およびプロビジョニング・サーバーおよびクライアントで使用できるRHP_MANAGED記憶域タイプを使用することをお薦めします。

    • フリート・パッチ適用およびプロビジョニング・サーバーで作業用コピーをプロビジョニングする場合は、デフォルトでRHP_MANAGEDが設定されるため、-storagetypeオプションを指定する必要はありません。

    • フリート・パッチ適用およびプロビジョニング・クライアントで作業用コピーをプロビジョニングする場合に、-pathパラメータを指定しないと、クライアントにOracle ASMディスク・グループがある場合にのみ、記憶域タイプがデフォルトでRHP_MANAGEDに設定されます。それ以外の場合、コマンドは失敗します。-pathパラメータにクライアント上の場所を指定すると、Oracle ASMディスク・グループの有無に関係なく、記憶域タイプがデフォルトでLOCALに設定されます。

  • LOCAL: この値を選択すると、フリート・パッチ適用およびプロビジョニングで管理されていないローカル・ファイル・システムに作業用コピーが格納されます。フリート・パッチ適用およびプロビジョニング・サーバー、フリート・パッチ適用およびプロビジョニング・クライアントまたは非フリート・パッチ適用およびプロビジョニング・クライアントのファイル・システムへのパス、あるいはフリート・パッチ適用およびプロビジョニング・クライアントのOracle ASMディスク・グループへのパスを指定する必要があります。

–pathパラメータを指定する場合、クラスタのすべてのノードでファイル・システムが共有されていると、この共有記憶域に作業用コピーが作成されます。ファイル・システムが共有されていない場合は、クラスタの各ノードの指定パスの場所に作業用コピーが作成されます。

注意:

-pathパラメータに指定するディレクトリは空であることが必要です。

関連トピック

別のユーザーのプロビジョニング

コマンドを実行しているユーザーとは異なるユーザーがソフトウェアをプロビジョニングできるようにするには、rhpctl add workingcopyコマンドの-userパラメータを使用します。

プロビジョニングが完了したとき、プロビジョニングされたソフトウェアのすべてのファイルとディレクトリは、指定したユーザーが所有します。リモートでプロビジョニングされたソフトウェアのファイルに対する権限は、そのアプリケーション・ソフトウェアのプロビジョニング元のゴールド・イメージに存在する権限と同じです。

フリート・パッチ適用およびプロビジョニング・サーバー間でのイメージの伝播

自動イメージ伝播を使用すると、様々なピア・フリート・パッチ適用およびプロビジョニング・サーバー間でソフトウェア・イメージの自動コピーを設定できます。1つのサイトに登録するゴールド・イメージは、ピア・フリート・パッチ適用およびプロビジョニング・サーバーにコピーされます。

2つのフリート・パッチ適用およびプロビジョニング・サーバー間のピアツーピア関係では、1つのサーバーがソフトウェア・イメージのソース、もう1つはソフトウェア・イメージの宛先です。
サーバー間でソフトウェア・イメージをコピーする基準は、ソフトウェア・イメージ・タイプ、イメージ・シリーズ、すべてのソフトウェア・イメージなどの特定のポリシーに基づいて指定できます。ソフトウェア・イメージ伝播の基準を満たすイメージを登録すると、このイメージのコピーがすべての登録済ピア・サーバーに伝播されます。
次の例では、2つのフリート・パッチ適用およびプロビジョニング・サーバー・サイト(RHPS-AとRHPS-B)の間で関係を確立します。RHPS-Aがソース、RHPS-Bがソフトウェア・イメージの宛先です。
  1. RHPS-Bで次のコマンドを実行します。
    $ rhpctl export server -server RHPS-A -serverdata file_path

    前述のコマンドにより、-serverdataパラメータに指定するディレクトリ・パスにRHPS-B.xmlという名前のファイルが作成されます。

  2. 次のコマンドを実行して、現在のフリート・パッチ適用およびプロビジョニング・サーバーにピア・サーバーを登録します。
    $ rhpctl register server -server RHPS-B -serverdata /tmp/RHPS-B.xml

    前述のコマンドでは、前の手順で作成されたRHPS-B.xmlファイルを、コマンドを実行するサーバー上の場所(この場合は/tmp/RHPS-B.xml)にコピーします。

    前述のコマンドを実行するクラスタはソース・サイトであり、コマンドラインで指定するサーバーはソフトウェア・イメージのコピー先となる宛先サイトです。

    ピア・ツー・ピア関係を削除するには、rhpctl unregister serverコマンドを使用します。

  3. RHPS-Bで次のコマンドを実行して、RHPS-AからRHPS-Bにソフトウェア・イメージを伝播します。
    $ rhpctl instantiate image -server RHPS-A  -all
    前述のコマンドでは、RHPS-AからRHPS-Bに、すべてのイメージが伝播されます。RHPS-Bにイメージがすでに存在する場合、再度は伝播されません。

    注意:

    イメージの伝播はイメージ名に基づきます。RHPCTLが、イメージの内容自体を比較して、それらが異なるかどうかを判断することはありません。伝播するイメージの名前が一意でない場合、RHPCTLはそのイメージを同一とみなし、イメージを伝播しません。

    特定のイメージの伝播を取り消すには、rhpctl uninstantiate imageコマンドを使用します。すでに進行中の伝播はこのコマンドの影響を受けず、完了するまで続行されます。-allパラメータを指定すると、-imagetypeパラメータと-seriesパラメータの値がすべて削除されます。

関連トピック

Oracle Grid Infrastructureの管理

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracle Grid Infrastructureホームを、ターゲットとフリート・パッチ適用およびプロビジョニング・クライアントに分散するための効率的でセキュアなプラットフォームを提供します。

また、フリート・パッチ適用およびプロビジョニング・クライアントには、フリート・パッチ適用およびプロビジョニング・サーバーからOracle Grid Infrastructureホームをフェッチする機能もあります。

Oracle Grid Infrastructureホームは、ゴールド・イメージの作業用コピーの形式で配布されます。作業用コピーがプロビジョニングされた後は、フリート・パッチ適用およびプロビジョニングによって、オプションでOracle Grid Infrastructureを構成できます。これにより、フリート・パッチ適用およびプロビジョニングで、最初にOracle Grid Infrastructureがインストールされていない1つ以上のノードで構成されるグループにOracle Grid Infrastructureインストールを作成できます。

フリート・パッチ適用およびプロビジョニングには、パッチが適用されたホームへの切替えや新しいバージョンのOracle Grid Infrastructureへのアップグレードなど、Oracle Grid Infrastructureホームを管理するコマンドもあります。これらはいずれも、関連する多数の手順を統合する単一のコマンドです。元のホームに、同様に簡単に戻すことができます。また、フリート・パッチ適用およびプロビジョニングにより、Oracle Grid Infrastructure構成のノードを追加または削除できます。

フリート・パッチ適用およびプロビジョニング(FPP)を使用したOracle Grid Infrastructureのデプロイについて

フリート・パッチ適用およびプロビジョニング(FPP)は、Oracleホームのプロビジョニングと保守のためのソフトウェア・ライフサイクル管理方法です。フリート・パッチ適用およびプロビジョニングにより、データベース、クラスタ、およびユーザー定義ソフトウェア・タイプの標準的な操作環境の一括デプロイメントおよび保守が可能になります。

注意:

Oracle Grid Infrastructure 19c以上では、これまで高速ホーム・プロビジョニング(RHP)と呼ばれていた機能がフリート・パッチ適用およびプロビジョニング(FPP)という名前になります。

フリート・パッチ適用およびプロビジョニングにより、クラスタのインストールと、Oracle Grid Infrastructure、Oracle Restart、およびOracle Databaseホームのプロビジョニング、パッチ適用、スケーリング、およびアップグレードを行うことができます。サポートされているバージョンは11.2、12.1、12.2、18cおよび19cです。アプリケーションおよびミドルウェアもフリート・パッチ適用およびプロビジョニングを使用してプロビジョニングできます。

フリート・パッチ適用およびプロビジョニングは、次のいずれかのモードで使用できるOracle Grid Infrastructureのサービスです。

  • 中央フリート・パッチ適用およびプロビジョニング・サーバー

    フリート・パッチ適用およびプロビジョニング・サーバーでは、ゴールド・イメージと呼ばれる標準化されたイメージが保存および管理されます。ゴールド・イメージは、データ・センターの任意の数のノードにデプロイできます。デプロイされたホームに新規クラスタおよびデータベースを作成し、それらを使用して、既存のインストールのパッチ適用、アップグレード、およびスケーリングを行うことができます。

    フリート・パッチ適用およびプロビジョニング・サーバーは、次のタイプのインストールを管理できます。

    • フリート・パッチ適用およびプロビジョニング・サーバー自体をホストするクラスタ上のソフトウェア・ホーム。

    • Oracle Grid Infrastructure 12cリリース2 (12.2)、18cおよび19cを実行しているフリート・パッチ適用およびプロビジョニング・クライアント。

    • Oracle Grid Infrastructure 11gリリース2 (11.2)および12cリリース1 (12.1)を実行しているインストール。

    • Oracle Grid Infrastructureなしで実行されるインストール。

    フリート・パッチ適用およびプロビジョニング・サーバーは、新規インストールをプロビジョニングでき、さらに既存のインストールに変更を加えることなく既存のインストールを管理できます。フリート・パッチ適用およびプロビジョニング・サーバーは、ピア・サーバー間でゴールド・イメージを自動的に共有し、データセンターが地理的に分散している企業をサポートできます。

  • フリート・パッチ適用およびプロビジョニング・クライアント

    フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・サーバーから管理することも、クライアント自体でコマンドを実行することで直接管理することもできます。フリート・パッチ適用およびプロビジョニング・クライアントは、Oracle Grid Infrastructureに組み込まれたサービスであり、Oracle Grid Infrastructure 12cリリース2 (12.2)以上のリリースで使用できます。フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・サーバーからゴールド・イメージを取得することも、ポリシーに基づいて新しいイメージをアップロードしたり、メンテナンス操作をそれ自体に適用したりすることもできます。

フリート・パッチ適用およびプロビジョニング

フリート・パッチ適用およびプロビジョニングを使用したOracleソフトウェアのデプロイには、次の利点があります。

  • デプロイされるソフトウェアのゴールド・イメージおよび系統の管理により、標準化および高レベルの自動化が可能になります。

  • アクティブ・データベースまたはクラスタを中断させることなく、新規ホームをアウトオブプレースでイメージ(ゴールド・イメージと呼ばれる)としてデプロイすることで、停止時間を最小限に抑えられます。

  • データベース・バージョンおよびデプロイメント・モデル全体で、簡単な一貫性のあるAPIによって呼び出されるオートマトンを提供することにより、保守が簡素化されます。

  • 操作をテストするための組込みの検証と「ドライラン」モードにより保守リスクが軽減されます。

  • 予期せぬ問題が発生した場合にコマンドを再開または再起動できるため、保守操作のリスクが軽減されます。

  • 次のような機能により、パッチ適用およびアップグレードの影響が最小限に抑えられ、多くの場合、排除されます。

    • 追加ノードまたは外部記憶域が不要で、デプロイメント内ですべてが実行される完全自動化された停止時間0のデータベース・アップグレード。

    • ローリング・パッチ適用中のデータベース・セッションおよびOJVMのアダプティブ管理。

    • 一括デプロイメントを管理するためのオプション。

  • デプロイメントおよび保守操作では、カスタマイズにより、自動化されたワークフローに環境固有のアクションをインクルードできます。

関連トピック

関連項目:

フリート・パッチ適用およびプロビジョニング・サーバーおよびクライアントの設定と、Oracle Grid InfrastructureおよびOracle Databaseホームのプロビジョニングおよびパッチ適用のためのゴールド・イメージの作成および使用については、Oracle Clusterware管理およびデプロイメント・ガイドを参照してください。

Oracle Grid Infrastructureソフトウェアのプロビジョニング

フリート・パッチ適用およびプロビジョニングには、Oracle Grid InfrastructureおよびOracle Restartグリッド・インフラストラクチャのホームをプロビジョニングして、オプションで構成する方法がいくつか用意されています。

フリート・パッチ適用およびプロビジョニングによって、現在Gridホームのない1つ以上のノードでOracle Grid Infrastructureをプロビジョニングおよび構成して、単一ノードまたはマルチノードのOracle Grid Infrastructureインストールを形成するようにOracle Grid Infrastructureを構成できます。
Oracle Grid Infrastructureをインストールおよび構成して、単純かつ繰返し可能な標準化されたデプロイメントの作成を可能にするには、rhpctl add workingcopyコマンドを使用します。
フリート・パッチ適用およびプロビジョニング・サーバーは、現在Oracle Grid Infrastructureを実行しているノードまたはクラスタにOracle Grid Infrastructureホームをプロビジョニングすることもできます。現在実行されているGridホームは、フリート・パッチ適用およびプロビジョニングでプロビジョニングされていないホーム(管理対象外のホーム)にすることも、フリート・パッチ適用およびプロビジョニングでプロビジョニングされたホーム(管理対象のホーム)にすることもできます。
また、クラスタ内のノードにOracle Restartグリッド・インフラストラクチャをプロビジョニングすることもできます。
いずれの場合でも、rhpctl add workingcopyコマンドの-softwareonlyパラメータを使用します。これによってプロビジョニングされますが、新しいGridホームがアクティブ化されるわけではないため、新しいホームに切り替えることができる場合は、単一のコマンドで実行できます。
  • Oracle Grid Infrastructureをインストールするノードをフリート・パッチ適用およびプロビジョニングに通知する場合、およびOracle Grid Infrastructureを構成する場合は、次の例のようにレスポンス・ファイルに指示を指定します。
    $ rhpctl add workingcopy -workingcopy GI_HOME_11204_WCPY -image GI_HOME_11204 –responsefile /u01/app/rhpinfo/GI_11204_install.txt
  {authentication_option}
    前述のコマンドでは、GI_HOME_11204ゴールド・イメージに基づくGI_HOME_11204_WCPY作業用コピーが、GI_11204_install.txtレスポンス・ファイルで指定されたターゲットにプロビジョニングされます。ターゲット・ノードの識別に加えて、レスポンス・ファイルでは、Oracle ASMおよびGNSパラメータなどのOracle Grid Infrastructure構成に関する情報が指定されます。

    注意:

    レスポンス・ファイルに指定した内容に関係なく、フリート・パッチ適用およびプロビジョニングではoracle.install.crs.rootconfig.executeRootScript=xxxレスポンス・ファイル・パラメータは上書きされ、常にfalseに設定されます。
  • 現在Oracle Grid Infrastructureを実行しているノードまたはクラスタにOracle Grid Infrastructureホームをプロビジョニングするには、次のコマンドを実行します。
    $ rhpctl add workingcopy -workingcopy GI_HOME_12201_PATCHED_WCPY -image GI_HOME_12201_PSU1 –client CLUST_002 -softwareonly

    前述のコマンドでは、GI_HOME_12201_PSU1ゴールド・イメージに基づく新しい作業用コピーが、CLUST_002という名前のフリート・パッチ適用およびプロビジョニング・クライアント(Oracle Grid Infrastructure 12c リリース2 (12.2)を実行しているもの)にプロビジョニングされます。Oracle Grid Infrastructure 12c リリース2 (12.2)を実行していないターゲット(たとえば、Oracle Grid Infrastructure 12c リリース1 (12.1)またはOracle Grid Infrastructure 11g リリース2 (11.2)を実行しているターゲットなど)にプロビジョニングする場合は、-clientではなく-targetnodeパラメータを使用します。

  • 次のように、Oracle Restartグリッド・インフラストラクチャをプロビジョニングするターゲット・ノードを指定します。
    $ rhpctl add workingcopy -workingcopy SIHA_GI -image goldimage -targetnode remote_node_name -resposnefile Oracle_Restart_resposne_file {authentication_option}

関連トピック

Oracle Grid Infrastructureソフトウェアへのパッチ適用

フリート・パッチ適用およびプロビジョニングには、Oracle Grid Infrastructureソフトウェア・ホームにパッチを適用する方法として、ローリング、非ローリングおよびバッチの3つがあります。

Oracle Grid Infrastructureソフトウェアへのパッチ適用では、Gridホームが、パッチが適用されたバージョンの現在のGridホームに移動します。パッチ適用操作がフリート・パッチ適用およびプロビジョニング・サーバーまたはクライアントで開始される場合、パッチが適用されたバージョンは、ゴールド・イメージの作業用コピーである必要があります。Gridホームの移動先の作業用コピーは、現在のホームよりも低いパッチ・レベルにすることができます。これにより、高いレベルのパッチが適用されたホームに移動した後で問題が発生した場合に、ロールバックが容易になります。

フリート・パッチ適用およびプロビジョニング・サーバーが存在しない環境で独立オートマトンを使用してこの操作を実行することもできます。この場合、ソース・ホームおよび宛先ホームはゴールド・イメージの作業用コピーではありませんが、フリート・パッチ適用およびプロビジョニングを使用する以外の方法でデプロイした2つのインストール済ホームです。

この項には次のトピックが含まれます:

関連トピック

ローリング方式を使用したOracle Grid Infrastructureへのパッチ適用

Oracle Grid Infrastructureへのパッチ適用のローリング方式は、デフォルトの方法です。

rhpctl move gihomeコマンド(アトミック操作)を使用し、これは、新しいホームで各ノードのOracle Grid Infrastructureスタックが再起動された後に戻されます。ノードは順次再起動されるため、一度に1つのみのノードがオフラインになり、クラスタのその他すべてのノードはオンラインのままになります。
  • 次のように、Oracle Grid Infrastructureホームを同じリリース・レベルの作業用コピーに移動します。
    $ rhpctl move gihome -client cluster_name –sourcewc Grid_home_1 –destwc Grid_home_2

    前述のコマンドでは、実行中のOracle Grid Infrastructureホームが、現在の管理対象のホーム(sourcewc)から、特定のクライアント・クラスタのパッチが適用されたホーム(destwc)に移動します。パッチが適用されたホームは、クライアントでプロビジョニングする必要があります。

  • 移動操作が完了前にあるポイントで失敗した場合は、コマンドを再実行することで操作を再実行できます。これにより、操作が中断したポイントから再開されます。これにより、失敗の原因となったどのような問題でも修正でき、障害が発生したポイントから処理を再開できます。また、次のように、部分的に完了した操作を元に戻すこと、および構成を初期状態に戻すことができます。
    $ rhpctl move gihome -destwc destination_workingcopy_name -revert [authentication_option]

    管理対象外のホームを指定して-revertパラメータを使用できます。

注意:

  • Gridホームは、フリート・パッチ適用およびプロビジョニングで管理されていないホームには移動できません。このため、(元のホームへの)ロールバックは、2つの作業用コピー間での移動にのみ適用されます。この制限は、管理対象外のホームでのみ作用するため、独立オートマトンを使用している場合は適用されません。

  • Gridホームを移動した後、いつでもソースの作業用コピーを削除できます。ただし、作業用コピーを削除した後は、ロールバックを実行できません。また、rhpctl delete workingcopyコマンド(rmなどではなく)を使用してソースの作業用コピーを削除し、フリート・パッチ適用およびプロビジョニング・インベントリを正常な状態に保ちます。

  • -abortパラメータを使用してパッチ適用操作を終了する場合、フリート・パッチ適用およびプロビジョニングでは、クリーン・アップは行われず、またパッチ適用手順は元に戻されません。すべてのノードにパッチが適用されていないため、クラスタ、データベース、あるいはその両方が一貫性のない状態である可能性があります。

非ローリング方式を使用したOracle Grid Infrastructureへのパッチ適用

rhpctl move gihomeコマンドで-nonrollingパラメータを使用して、すべてのノードのOracle Grid Infrastructureスタックをパラレルで再起動できます。

ローリング方式と同様、すべてのノードがオンラインになった後に戻されるアトミック・コマンドです。
  • 非ローリング方式でOracle Grid Infrastructureにパッチを適用するには、次のコマンドを使用します。
    $ rhpctl move gihome -client cluster_name –sourcewc Grid_home_1 –destwc Grid_home_2 -nonrolling
バッチを使用したOracle Grid Infrastructureへのパッチ適用

3つ目のパッチ適用方法は、ノードのバッチを順次処理し、各バッチの多数のノードをパラレルで再起動する方法です。

この方法により、パッチ適用プロセス中のサービスの可用性が最大化されます。Oracle Grid Infrastructure 12cリリース2 (12.2.x)ソフトウェア・ホームにパッチを適用するときに、コマンドラインでバッチを定義することも、クラスタで実行されているデータベース・サービスの分析に基づいてフリート・パッチ適用およびプロビジョニングでバッチのリストを生成することもできます。
バッチを定義する方法として、2つの方法があります。

ユーザー定義のバッチ

このパッチ適用の方法を使用する場合、初めてrhpctl move gihomeコマンドを実行するときに、ソース・ホーム、宛先ホーム、バッチおよび必要に応じてその他のオプションを指定する必要があります。コマンドは、最初のノードの再起動後に終了します。

定義したバッチを使用してOracle Grid Infrastructureにパッチを適用するには、次の手順を実行します。

  1. 次の例のように、コマンドラインでバッチのリストを定義して、パッチ適用プロセスを開始します。

    $ rhpctl move gihome -sourcewc wc1 -destwc wc2 -batches "(n1),(n2,n3),(n4)"

    前述のコマンド例では、移動操作を開始し、最初のバッチでOracle Grid Infrastructureスタックが再起動したときに終了し、成功をレポートします。Oracle Grid Infrastructureは、-batchesパラメータで指定した順序でバッチを再起動します。

    コマンド例では、ノードn1は最初のバッチを形成し、ノードn2およびn3は2つ目のバッチを形成し、ノードn4は最後のバッチを形成しています。コマンドでは、ソースの作業用コピーがwc1として、パッチが適用された(宛先)作業用コピーがwc2として定義されています。

    注意:

    シングルトン・サービス(ポリシー管理シングルトン・サービスまたは1つのインスタンスで実行中の管理者管理シングルトン・サービス)がバッチ間で再配置されて、非シングルトン・サービスが引き続きパッチ適用プロセス中に部分的に使用できるように、バッチを指定できます。

  2. 次のように、rhpctl move gihomeコマンドを再度実行して、次のバッチを処理する必要があります。 

    $ rhpctl move gihome -destwc wc2 -continue

    前述のコマンド例では、2つ目のバッチ(ノードn2およびn3)のOracle Grid Infrastructureスタックを再起動します。コマンドは、2つ目のバッチが正常にパッチ適用されたことをレポートして、終了します。

  3. ノードの最後のバッチが処理されるまで、前述の手順を繰り返します。最後のバッチが処理された後で-continueパラメータを含むコマンドを実行しようとすると、コマンドでエラーが返されます。

    前述の一連の手順のいずれかでrhpctl move gihomeコマンドが失敗した場合は、失敗の原因を特定し、修正した後、-continueオプションを指定してコマンドを再度実行し、失敗したバッチへのパッチ適用を試行します。失敗したバッチをスキップして次のバッチに進む場合は、-continueと-skip のパラメータを使用します。最後のバッチをスキップしようとすると、移動操作が終了します。

    また、-revertパラメータを使用してコマンドを再発行することで、行われた変更を元に戻し、構成を初期状態に戻すことができます。

    前述の手順のいずれかで-continueパラメータではなく-abortパラメータを使用して、パッチ適用プロセスを終了し、クラスタを現在の状態のままにすることができます。

    注意:

    • 1つのアクティブ・サーバーによるサーバー・プールでホストされたポリシー管理サービスと、1つの優先インスタンスによる管理者管理サービスおよび使用可能なインスタンスがない管理者管理サービスは再配置できず、インスタンスの再起動中にオフラインになります。

    • 移動操作が進行中の場合は、同じソース・ホームからの別の移動操作または同じ宛先ホームへの別の移動操作は開始できません。

    • 移動操作が終了した後で、移動の前に実行されていたものとは異なるノードでサービスが実行されている場合があり、必要に応じてこれらを元のインスタンスに手動で配置しなおす必要があります。

    • -abortパラメータを使用してパッチ適用操作を終了する場合、フリート・パッチ適用およびプロビジョニングでは、クリーン・アップは行われず、またパッチ適用手順は元に戻されません。すべてのノードにパッチが適用されていないため、クラスタ、データベース、あるいはその両方が一貫性のない状態である可能性があります。

    • 起動依存性に応じて、移動の開始前にオフラインだったサービスが移動中にオンラインになる場合があります。

フリート・パッチ適用およびプロビジョニング定義のバッチ

ノードのバッチの定義とパッチ適用にフリート・パッチ適用およびプロビジョニングを使用することは、次のコマンド例、つまり、ソースの作業用コピーがwc1で宛先の作業用コピーがwc2となっている例で示すように、実行する必要があるコマンドが1つのみであることを意味します。 

$ rhpctl move gihome -sourcewc wc1 -destwc wc2 -smartmove -saf Z+ [-eval]

コマンドで-separateパラメータを使用していないかぎり、他の操作を実行する必要はありません。その場合、移動操作は次のバッチに進むためのユーザーの介入を待機し、各バッチが完了した後、-continueパラメータを指定してコマンドを実行する必要があります。

移動操作が完了前のある時点で失敗した場合は、次のように、コマンドを再度実行することで操作を再実行するか、部分的に完了した操作を元に戻すことができます。
$ rhpctl move gihome -destwc destination_workingcopy_name -revert [authentication_option]
管理対象外のホームを指定して-revertパラメータを使用できます。

前述の例で使用されているパラメータは、次のとおりです。

  • -smartmove: このパラメータにより、Oracle Grid Infrastructureを起動する前にシングルトン・リソースが再配置されるように、非結合のノードのセット上のOracle Grid Infrastructureスタックが再起動されます。

    注意:

    リソースが属するサーバー・プールに含まれるアクティブ・サーバーが1つのみの場合は、再配置を実行できないため、そのリソースはオフラインになります。

    -smartmoveパラメータ:

    • サービスとそれらが実行されているノードのマップを作成します。

    • ノードのバッチを作成します。構成がOracle Flex Clusterの場合は、最初のバッチにはハブ・ノードのみが含まれます。追加バッチについては、次の場合にノードをバッチにマージできます。

      • このノードで実行されている非シングルトン・サービスの可用性が、指定したサービスの可用性ファクタ(またはデフォルトの50%)を下回っていない。

      • このノードに実行中のシングルトン・サービスがあり、バッチにサービスの再配置ターゲット・ノードが含まれていない。

    • バッチごとにOracle Grid Infrastructureスタックを再起動します。

  • サービスの可用性ファクタ(-saf Z+): データベース・サービスを実行する必要があるデータベース・インスタンスの最小数を示す正数を割合として指定できます。次に例を示します。

    • 2つのインスタンスで実行されるサービスに対して-saf 50を指定した場合は、一度に1つのインスタンスのみをオフラインにすることができます。

    • 3つのインスタンスで実行されるサービスに対して-saf 50を指定した場合は、一度に1つのインスタンスのみをオフラインにすることができます。

    • 2つのインスタンスで実行されるサービスに対して-saf 75を指定した場合、ターゲットは対応できないため、エラーが発生します。

    • サービスの可用性ファクタは、2つ以上のインスタンスで実行されるサービスに適用できます。そのため、サービスの可用性ファクタは非ローリング移動を示す0%にすることはできますが、100%にすることはできません。デフォルトは50%です。

    • シングルトン・サービスに対してサービスの可用性ファクタを指定した場合、そのようなサービスの可用性は100%であるためパラメータが無視されて、サービスが再配置されます。

  • -eval: オプションでこのパラメータを使用して、自動生成されたバッチを表示できます。また、このパラメータでは、実際にソフトウェアにパッチを適用することなく、移動操作の順序が表示されます。

関連トピック

Oracle Grid InfrastructureとOracle Databaseのパッチ適用の結合

Oracle Grid Infrastructureデプロイメントにパッチを適用するときに、フリート・パッチ適用およびプロビジョニングでは、クラスタのOracle Databaseホームに同時にパッチを適用できるため、単一のメンテナンス操作で両方のタイプのソフトウェア・ホームにパッチを適用できます。

注意:

独立オートマトンを使用して、Oracle Grid InfrastructureとOracle Databaseの両方の組合せにパッチを適用することはできません。

次のrhpctl move gihomeコマンドのオプション・パラメータは、Oracle Grid InfrastructureとOracle Databaseのパッチ適用の結合のユースケースに関連します。

  • -auto: Oracle Grid Infrastructureへのパッチ適用とともに自動的にデータベースにパッチを適用します。

  • -dbhomes mapping_of_Oracle_homes: 次の形式のソースと宛先の作業用コピーのマッピング:
    sourcewc1=destwc1,...,source_oracle_home_path=destwcN

  • -dblist db_name_list: 指定したデータベースのみにパッチを適用します。

  • -excludedblist db_name_list: 指定したデータベースを除くすべてのデータベースにパッチを適用します。

  • -nodatapatch: 移動するデータベースに対してdatapatchが実行されないことを示します。

たとえば、Oracle Grid Infrastructure 12c リリース2 (12.2)のフリート・パッチ適用およびプロビジョニング・サーバーによって、ノードtest_749を含むOracle Grid Infrastructure 12c リリース1 (12.1.0.2)ターゲット・クラスタの次の作業用コピーがプロビジョニングされているとします。

  • GI121WC1: Oracle Grid Infrastructure 12c リリース1 (12.1.0.2)クラスタのアクティブなGridホーム

  • GI121WC2: Oracle Grid Infrastructure 12c リリース1 (12.1.0.2)クラスタのソフトウェアのみのGridホーム

  • DB121WC1: データベース・インスタンスを実行しているOracle RAC 12c リリース1 (12.1.0.2.0)データベース・ホーム

  • DB121025WC1: データベース・インスタンスのないOracle RAC 12c リリース1 (12.1.0.2.5)データベース・ホーム(これがパッチが適用されたホームです)

  • DB112WC1: データベース・インスタンスを実行しているOracle RAC 11g リリース2 (11.2.0.4.0)データベース・ホーム

  • DB112045WC1: データベース・インスタンスのないOracle RAC 11g リリース2 (11.2.0.4.5)データベース・ホーム(これがパッチが適用されたホームです)

また、同時に次の移動を実行するとします。

  • Oracle Grid Infrastructureを作業用コピーGI121WC1から作業用コピーGI121WC2に

  • Oracle RACデータベースdb1を作業用コピーDB121WC1から作業用コピーDB121025WC1に

  • Oracle RACデータベースdb2を作業用コピーDB112WC1から作業用コピーDB112045WC1に

次の単一のコマンドによって移動が完了します。

$ rhpctl move gihome -sourcewc GI121WC1 -destwc GI121WC2 -auto
  -dbhomes DB121WC1=DB121025WC1,DB112WC1=DB112045WC1 -targetnode test_749 {authentication_option}

注意:

  • 現在作業用コピーでない既存のOracleホームがある場合、ソース・ホームには作業用コピーの名前ではなくOracleホームのパスを指定します。前述の例では、既存の12.1.0.2ホームのOracleホームのパスが/u01/app/prod/12.1.0.2/dbhome1である場合は、DB121WC1=DB121025WC1を/u01/app/prod/12.1.0.2/dbhome1=DB121025WC1に置き換えます。

  • 移動操作が完了前のある時点で失敗した場合は、失敗の原因を解決し、コマンドの再実行によって操作を再開するか、次のコマンドを発行して、部分的に完了した操作を元に戻すことができます。このコマンドにより、構成がその初期状態に戻されます。
    $ rhpctl move gihome -destwc GI121WC2 -revert {authentication_option}

前述のコマンド例では、Oracle Grid Infrastructure 12c リリース1 (12.1.0.2)のGridホームが作業用コピーGI121WC1から作業用コピーGI121WC2に移動し、作業用コピーDB121WC1で実行されているデータベースが作業用コピーDB121025WC1に移動し、作業用コピーDB112WC1で実行されているデータベースが作業用コピーDB112045WC1に移動します。

クライアント・クラスタの各ノードでは、RHPCTLの手順は次のとおりです。

  1. Oracle Grid Infrastructureを移動する構成済の操作前ユーザー・アクションを実行します(move gihome)。

  2. データベースの作業用コピーを移動する構成済の操作前ユーザー・アクションを実行します(move database)。

  3. ノードで実行されているサービスを停止して、ドレインと切断のオプションを適用します。

  4. Oracle ClusterwareとOracle Databaseの関連するパッチ適用操作を実行します。

  5. データベースの作業用コピーを移動する構成済の操作後ユーザー・アクションを実行します(move database)。

  6. Oracle Grid Infrastructureの作業用コピーを移動する構成済の操作後ユーザー・アクションを実行します(move gihome)。

関連トピック

ローカル・モード構成を使用したOracle Grid Infrastructureへのパッチ適用

Oracle Grid Infrastructureをインストールするとき、または以前のバージョンを現在のバージョンにアップグレードする場合、フリート・パッチ適用およびプロビジョニング・サーバーはローカル・モードで自動的に構成されます。

ローカル・モード操作では、ゴールド・イメージを登録またはデプロイせずに、単純化された環境のローカル・クラスタでグリッド・インフラストラクチャおよびデータベースのパッチ適用操作を実行できます。rhpctl move gihomeまたはrhpctl move databaseコマンドを使用して、グリッド・インフラストラクチャまたはデータベースのパッチ適用済ホームのいずれかをデプロイしてパッチ操作を実行し、作業用コピー名のかわりにソースと宛先のパスを指定します。

注意:

ローカル・モードのパッチ適用操作を使用するには、次のコマンドを使用して、フリート・パッチ適用およびプロビジョニング・サーバーを有効化および起動する必要があります。
$ srvctl enable rhpserver
$ srvctl start rhpserver
フリート・パッチ適用およびプロビジョニング・サーバーをローカル・モードから通常モードに切り替える(リモート・ターゲットを管理するために)には、次のように、ローカル・モードで現在のフリート・パッチ適用およびプロビジョニング・サーバーを削除する必要があります。
$ srvctl stop rhpserver
$ srvctl remove rhpserver

「フリート・パッチ適用およびプロビジョニング・サーバーの作成」の手順に従って、中央モードのフリート・パッチ適用およびプロビジョニング・サーバーを作成します。

  • Oracle Grid Infrastructureにパッチを適用する独立オートマトンは、あるホームから別のホームへの切替えに必要なすべての手順を実行します。オートマトンはゴールド・イメージを認識しないため、データベースを移動するには、次のように2つのホーム・パスが必要です。
    $ rhpctl move gihome –sourcehome Oracle_home_path -destinationhome Oracle_home_path
パッチ適用操作には、次のrhpctl move gihomeコマンド・パラメータを使用します。

  • -node: 移動するホームが複数のノードにインストールされているOracle Grid Infrastructureホームである場合、デフォルトの操作はすべてのノードのローリング更新です。1つのノードにのみパッチを適用するには、このパラメータでそのノードの名前を指定します。

  • -nonrolling: 移動するホームが複数のノードにインストールされているOracle Grid Infrastructureホームである場合、デフォルト操作はすべてのノードのローリング更新です。非ローリング方式ですべてのノードにパッチを適用するには、-nodeパラメータのかわりにこのパラメータを使用します。

  • -ignorewcpatches: デフォルトでは、宛先ホームにソース・ホームに存在するパッチがない場合、フリート・パッチ適用およびプロビジョニングでは移動操作は実行されません。この機能は、このパラメータを使用して上書きできます。たとえば、更新を元に戻す必要がある場合、前のソース・ホームに戻すことができます。

関連トピック

エラー防止および自動リカバリ・オプション

フリート・パッチ適用およびプロビジョニングには、保守操作中に役立つエラー防止オプションおよび自動リカバリ・オプションがあります。

保守操作中、エラーは、可能な場合は必ず回避する必要があり、エラーが発生した場合には、サービスの中断を回避するために自動リカバリ・パスを用意する必要があります。

エラー防止

多くのRHPCTLコマンドには、-evalパラメータがあります。このパラメータを使用すると、コマンドを実行して、変更を加えることなく現在の構成を評価し、コマンドを正常に実行できるかどうか、およびコマンド実行が構成にどのように影響するかを判別できます。-evalパラメータを使用して実行するコマンドは、構成を変更せずに、可能なかぎり多くの前提条件チェックを実行します。エラーが発生した場合は、RHPCTLにより、それらのエラーがコマンド出力で報告されます。エラーを修正した後、-evalを使用してコマンドを再実行することで、その修正を検証できます。–evalを使用してコマンドが正常に実行されると、実際のコマンドを実行しても成功する確実性が高くなります。

保守ウィンドウの外部で-evalパラメータを使用してコマンドをテストできるため、保守手順自体にはフル・ウィンドウを使用できます。

自動リカバリ・オプション

保守操作時、処理中(たとえば、rhpctl move databaseまたはrhpctl move gihomeコマンドの途中)、または操作成功後(たとえば、rhpctl move databaseコマンドの後、パフォーマンスや動作に関する問題が発生)にエラーが発生することがあります。

処理中のエラー

移動操作時に処理中のエラーが発生した場合は次のように処理します。

  • RHPCTLによって報告されたエラーを修正し、コマンドを再実行します。これにより、障害のポイントから実行が再開されます。

    コマンドの再実行が成功し、移動操作に操作後のユーザー・アクションが関連付けられている場合は、そのユーザー・アクションが実行されます。ただし、操作前ユーザー・アクションがある場合、RHPCTLでは、コマンドは再実行されません。

  • 失敗した移動の宛先(作業用コピーまたは管理対象外ホーム)、認証オプション(必要な場合)のみ指定し、-revertパラメータを使用して、新しいmoveコマンドを実行します。これにより、構成が初期状態に戻ります。

    操作に関連付けられているユーザー・アクションは実行されません。

  • 失敗した移動の宛先(作業用コピーまたは管理対象外ホーム)、認証オプション(必要な場合)、および-abortパラメータのみ指定して、新しいmoveコマンドを実行します。この場合、構成は現在の状態のままです。この時点で構成を最終状態にするには、手動操作が必要です。

    操作に関連付けられているユーザー・アクションは実行されません。

更新後の問題

新規データベースまたはOracle Grid Infrastructureホームへの移動操作が成功した後でも、変更を元に戻し、以前のホームにロールバックすることが必要になる場合もあります。ソース・ホームと宛先ホームを反対にしてコマンドを再実行することで、これを行うことができます。これは、実質的には、前の移動操作を参照せずに実行される新しい移動操作です。

注意:

独立オートマトンでは、ソース・ホームおよび宛先ホームは、常に管理対象外のホーム(フリート・パッチ適用およびプロビジョニングによってプロビジョニングされていないホーム)です。フリート・パッチ適用およびプロビジョニング・サーバーまたはフリート・パッチ適用およびプロビジョニング・クライアントで移動操作を実行する場合、宛先ホームは、フリート・パッチ適用およびプロビジョニングでプロビジョニングされた管理対象ホームである必要があります。

Oracle Grid Infrastructureソフトウェアのアップグレード

フリート・パッチ適用およびプロビジョニングを使用している場合、1つのコマンドでOracle Grid Infrastructureホームをアップグレードできます。

フリート・パッチ適用およびプロビジョニングは、Oracle Grid Infrastructure 11g リリース2 (11.2.0.3および11.2.0.4)から12c リリース1 (12.1.0.2)へのアップグレードをサポートします。Oracle Grid Infrastructure 11g リリース2 (11.2.0.3と11.2.0.4)および12c リリース1 (12.1.0.2)から12c リリース2 (12.2.0.1)へのアップグレードがサポートされています。すでにプロビジョニングされているゴールド・イメージの作業用コピーをアップグレード先にすることも、この操作の一部として作業用コピーを作成することもできます。

たとえば、ターゲット・クラスタが、フリート・パッチ適用およびプロビジョニングによってプロビジョニングされたOracle Grid InfrastructureホームでOracle Grid Infrastructureを実行しているとします。このOracle Grid Infrastructureホームは11g リリース2 (11.2.0.4)で、それに従って作業用コピーに名前が付けられます。

Oracle Grid Infrastructure 12c リリース2 (12.2.0.1)の作業用コピー・バージョン(この例ではGIOH12201)をプロビジョニングしたら、次の1つのコマンドでその作業用コピーにアップグレードできます。 

$ rhpctl upgrade gihome -sourcewc GIOH11204 -destwc GIOH12201
フリート・パッチ適用およびプロビジョニングでは、ソースの作業用コピーの名前に基づいて、アップグレードするクラスタを識別できます。管理対象外のOracle Grid Infrastructureホームでターゲット・クラスタが実行されていた場合、ソースの作業用コピーの名前ではなくソース・ホームのパスを指定して、ターゲット・クラスタも指定する必要があります。

注意:

アップグレードの完了後は、いつでもソースの作業用コピーを削除できます。ただし、作業用コピーを削除した後は、ロールバックを実行できません。また、rhpctl delete workingcopyコマンド(rmなどではなく)を使用してソースの作業用コピーを削除し、フリート・パッチ適用およびプロビジョニング・インベントリを正常な状態に保ちます。

Oracle Databaseソフトウェアの管理

フリート・パッチ適用およびプロビジョニング・サーバーは、Oracle Databaseホームを、ターゲットとフリート・パッチ適用およびプロビジョニング・クライアントに分散するための効率的でセキュアなプラットフォームを提供します。

また、フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・サーバーからデータベース・ホームをフェッチできます。

Oracle Databaseホームは、ゴールド・イメージの作業用コピーの形式で配布されます。その後、作業用コピーでデータベース・インスタンス(1つ以上)を作成できます。

フリート・パッチ適用およびプロビジョニングには、パッチが適用されたホームへの切替えや新しいバージョンのデータベースへのアップグレードなど、既存のデータベースを管理するコマンドもあります。これらはいずれも、関連する多数の手順を統合する単一のコマンドです。元のホームに、同様に簡単に戻すことができます。

データベース・ホームのゴールド・イメージのコピーのプロビジョニング

フリート・パッチ適用およびプロビジョニング・サーバー、クライアントまたはターゲットでデータベース・ホームの作業用コピーをプロビジョニングするには、rhpctl add workingcopyコマンドを使用します。

  • 次の例のように、フリート・パッチ適用およびプロビジョニング・サーバーでrhpctl add workingcopyコマンドを実行します。
    $ rhpctl add workingcopy -image db12c -path /u01/app/dbusr/product/12.2.0/db12201
  -client client_007 -oraclebase /u01/app/dbusr/ -workingcopy wc_db122_1

    前述のコマンド例では、client_007というフリート・パッチ適用およびプロビジョニング・クライアント・クラスタのすべてのノードでwc_db122_1という作業用コピーが作成されます。ゴールド・イメージdb12cが作業用コピーのソースです。コマンドで指定するディレクトリ・パスの場所は、空である必要があります。

関連トピック

ゴールド・イメージのコピーでのOracle Databaseの作成

作業用コピーでOracle Databaseを作成します。

フリート・パッチ適用およびプロビジョニング・サーバーは、フリート・パッチ適用およびプロビジョニング・サーバー自体、フリート・パッチ適用およびプロビジョニング・クライアント、または非フリート・パッチ適用およびプロビジョニング・クライアント・ターゲットにある作業用コピーにデータベースを追加できます。フリート・パッチ適用およびプロビジョニング・クライアントは、フリート・パッチ適用およびプロビジョニング・クライアント自体で実行中の作業用コピーにデータベースを作成できます。

  • ゴールド・イメージの作業用コピーを作成してその作業用コピーをターゲットにプロビジョニングすると、次のコマンド例、つまり、wc_db122_1という作業用コピーにdb12201というOracle Real Application Clusters (Oracle RAC)データベースを作成する例のように、rhpctl add databaseコマンドを使用して、作業用コピーにOracle Databaseを作成できます。
    $ rhpctl add database –workingcopy wc_db122_1 –dbname db12201 -node client_007_node1,client_007_node2 -dbtype RAC -datafileDestination DATA007_DG
前述の例では、クライアント・クラスタの2つのノードに、管理者管理Oracle RACデータベースが作成されます。データ・ファイルの宛先は、コマンドの実行前に作成したOracle ASMディスク・グループです。さらに、Oracle RAC One Nodeと非クラスタ化データベースを作成できます。

注意:

フリート・パッチ適用およびプロビジョニングを使用してデータベースを作成する場合、データベースのSYSとSYSTEMの両方のスキーマに、取得できないランダムなパスワードが使用されます。DBAまたはオペレータのロールを持つユーザーは、実行中のノードのデータベースにローカルに接続して、パスワードをこれら2つのアカウントにリセットする必要があります。

Oracle Databaseソフトウェアへのパッチ適用

Oracle Databaseにパッチを適用するには、データベース・ホームを、実装するパッチが含まれる新しいホームに移動します。

1つ以上のデータベース・ホームを同じリリース・レベルのデータベースの作業用コピーに移動するには、rhpctl move databaseコマンドを使用します。データベースは、作業用コピー、またはフリート・パッチ適用およびプロビジョニングで管理されていないOracle Databaseホームで実行できます。
移動操作がフリート・パッチ適用およびプロビジョニング・サーバーまたはクライアントで開始される場合、移動先のバージョンは、ゴールド・イメージの作業用コピーである必要があります。フリート・パッチ適用およびプロビジョニング・サーバーが存在しない環境で独立オートマトンを使用してこの操作を実行することもできます。この場合、ソース・ホームおよび宛先ホームはゴールド・イメージの作業用コピーではありませんが、フリート・パッチ適用およびプロビジョニングを使用する以外の方法でデプロイした2つのインストール済ホームです。
データベースの移動先の作業用コピーは、現在のデータベース・ホームよりも低いパッチ・レベルにすることができます。これにより、高いレベルのパッチが適用されたホームに移動した後で問題が発生した場合に、ロールバックが容易になります。
データベース・ホームの移動先の作業用コピーは、元の作業用コピーと同じパッチ・レベルにすることができます。このことは、ある記憶域の場所から別の記憶域の場所にデータベース・ホームを移動する場合や、同じパッチ・レベルを維持して管理対象外のホームを管理対象のホームに変換する場合に役立ちます。
フリート・パッチ適用およびプロビジョニングでは、すべてのパッチがアウトオブプレースで適用されることで、メンテナンスに必要な停止時間が最小化されます。また、フリート・パッチ適用およびプロビジョニングでは、現在の構成が保持されるため、前述のロールバック機能を使用できます。デフォルトでは、フリート・パッチ適用およびプロビジョニングでは、パッチがローリング方式で適用されるため、サービスの停止時間が削減され、多くの場合解消されます。非ローリング・モードでパッチ適用を実行するには、-nonrollingオプションを使用します。 こうすると、古いORACLE_HOMEデータベースでデータベースが完全に停止してから、新しくパッチ適用されたORACLE_HOMEから再起動して実行されます。

注意:

パッチ適用プロセスの一部には、データパッチの適用が含まれます。Oracle Database 12c リリース1 (12.1)以降を移動する場合、フリート・パッチ適用およびプロビジョニングでこの手順が自動的に完了します。ただし、Oracle Database 12c リリース1 (12.1)より前のバージョンに移動する場合は、手動でデータパッチを実行する必要があります。フリート・パッチ適用およびプロビジョニングではOracle Data Guardが認識され、Oracle Data Guardスタンバイにはデータパッチは適用されません。

データベースへのパッチ適用のワークフロー

DB122というOracle Database 12c リリース2 (12.2)のゴールド・イメージから作成された作業用コピーでmyorcldbというデータベースが実行されているとします。Oracle Databaseホームにパッチを適用する一般的なワークフローは次のとおりです。
  1. パッチを適用するOracle Database (この場合、DB122)の作業用コピーを作成します。
  2. 作成した作業用コピーにパッチを適用します。
  3. パッチが適用された作業用コピーをテストおよび検証します。
  4. パッチが適用された作業用コピーからゴールド・イメージ(DB122_PATCHなど)を作成するには、rhpctl add imageコマンドを使用します。

    注意:

    前述のコマンドで指定する作業用コピーは、フリート・パッチ適用およびプロビジョニング管理の記憶域でフリート・パッチ適用およびプロビジョニング・サーバーにホストされている必要があります。
  5. rhpctl delete workingcopyコマンドを使用して、パッチが適用されたOracle Databaseとともにパッチが適用された作業用コピーを削除します。

    注意:

    rmコマンドなどのいくつかの方法では、フリート・パッチ適用およびプロビジョニング・インベントリの情報が更新されないため、これらの方法を使用して直接削除しないでください。
  6. パッチが適用されたゴールド・イメージ(DB122_PATCH)から作業用コピーを作成します。
  7. 作成した作業用コピーにmyorcldbを移動します。
  8. 手順の開始時にデータベースが実行されていた作業用コピーにロールバックする必要がないことがわかっている場合は、rhpctl delete workingcopyコマンドを使用してその作業用コピーを削除します。

バッチを使用したOracle Databaseへのパッチ適用

データベースへのパッチの適用中に、フリート・パッチ適用およびプロビジョニングによって、ノードのバッチを順次処理し、各バッチの多数のノードをパラレルで再起動できます。この方法により、パッチ適用プロセス中のサービスの可用性が最大化されます。コマンドラインでバッチを定義することも、クラスタで実行されているデータベース・サービスの分析に基づいてフリート・パッチ適用およびプロビジョニングでバッチのリストを生成することもできます。

OJVMデプロイメントのアダプティブOracle RACローリング・パッチ適用

クラスタ化環境で、フリート・パッチ適用およびプロビジョニングによりデータベース保守を適用するデフォルトの方法は、Oracle RACローリングです。ただし、新しい(パッチ適用対象の)データベース・ホームにOJVMパッチが含まれる場合、非ローリングが必要になることがあります。この場合、フリート・パッチ適用およびプロビジョニングにより、ローリング方式が可能かどうか判別され、可能な場合はローリングが行われます。(詳細は、MOS Note 2217053.1を参照してください。)

関連トピック

独立オートマトンを使用したOracle Databaseへのパッチ適用

独立したローカル・モードのオートマトンは、クラスタ内のOracle Database単一インスタンス・データベース、スタンドアロン(Oracle Grid Infrastructureなし)、Oracle RACデータベース、またはOracle RAC One NodeデータベースなどのOracle Databaseホームを更新します。

クラスタ環境では、データベース・ソース・ホームはOracle Database 11g (11.2.0.4)、12c (12.1.0.2)、12c (12.2.0.1)またはそれ以降です。
スタンドアロン(クラスタ化されていない)環境では、データベース・ホームはOracle Database18c以上である必要があります。
オートマトンはデプロイメント上でローカルに実行されるため、アーキテクチャにフリート・パッチ適用およびプロビジョニング・サーバーは必要ありません。(アーキテクチャ内にフリート・パッチ適用およびプロビジョニング・サーバーがある場合、オートマトンとの通信は行われず、フリート・パッチ適用およびプロビジョニング・サーバーは独立オートマトンと対話できません。)
  • Oracle Databaseにパッチを適用する独立オートマトンは、あるホームから別のホームへの切替えに必要なすべての手順を実行します。オートマトンはゴールド・イメージを認識しないため、データベースを移動するには、次のように2つのホーム・パスが必要です。
    $ rhpctl move database –sourcehome Oracle_home_path -destinationhome Oracle_home_path
パッチ適用シナリオには、次のrhpctl move databaseコマンド・パラメータを使用します。
  • -dbname: データベース・ホームが複数のデータベースをホストしている場合、このパラメータでカンマ区切りのリストを指定することで、特定のデータベースを移動できます。指定されていないデータベースは移動されません。このパラメータを使用しない場合、RHPCTLはすべてのデータベースを移動します。

    注意:

    非クラスタ化(シングル・インスタンス)データベースを移動する場合は、-dbnameパラメータの値に対して、データベース名ではなくデータベースのSIDを指定する必要があります。

  • -ignorewcpatches: デフォルトでは、宛先ホームにソース・ホームに存在するパッチがない場合、フリート・パッチ適用およびプロビジョニングでは移動操作は実行されません。この機能は、このパラメータを使用して上書きできます。たとえば、更新を元に戻す必要がある場合、前のソース・ホームに戻すことができます。

次のパラメータは、クラスタ化環境にのみ適用されます。

  • -node: 移動するホームが複数のノードにインストールされているデータベース・ホームである場合、デフォルトの操作はすべてのノードのローリング更新です。1つのノードにのみパッチを適用するには、このパラメータでそのノードの名前を指定します。

  • -nonrolling: 移動するホームが複数のノードにインストールされているデータベース・ホームである場合、デフォルトの操作はすべてのノードのローリング更新です。非ローリング方式ですべてのノードにパッチを適用するには、-nodeパラメータのかわりにこのパラメータを使用します。

-disconnectおよび-noreplay: シングル・インスタンスのOracle Database、Oracle RACおよびOracle RAC One Nodeデータベース・インスタンスに適用されます。サービスを停止または再配置する前にすべてのセッションを切断する場合は、-disconnectパラメータを使用します。-disconnectを使用するように選択した場合、-noreplayパラメータを使用して切断中のセッション再生を無効にするように選択できます。

-drain_timeout: シングル・インスタンスのOracle Database、Oracle RACおよびOracle RAC One Nodeデータベース・インスタンスに適用されます。このパラメータを使用して、各ノードからリソース・ドレインが完了するまでの許容時間を秒数で指定します。受け入れられる値は、空の文字列("")、0または任意の正の整数です。デフォルト値は空の文字列で、このパラメータが設定されていないことを意味します。これは従来の動作を維持するために古いバージョンに適用できます。0に設定されている場合、停止オプションはただちに適用されます。

ドレイン期間は、計画的なメンテナンス操作のために意図されています。ドレイン期間中は、各ノードで連続して、現在のすべてのクライアント要求は処理されますが、新しい要求は受け入れません。

-stopoption: シングル・インスタンスのOracle Database、Oracle RACおよびOracle RAC One Nodeデータベース・インスタンスに適用されます。データベースの停止オプションを指定します。停止オプションには、ABORT、IMMEDIATE、NORMAL、TRANSACTIONALおよびTRANSACTIONAL_LOCALがあります。

注意:

rhpctl move databaseコマンドはOracle Data Guard対応であり、データベースがOracle Data Guardスタンバイの場合、データパッチは実行されません。

関連トピック

Oracle Exadataソフトウェアへのパッチ適用

Oracle Grid InfrastructureおよびOracle Databaseホームに加えて、フリート・パッチ適用およびプロビジョニングは、Oracle Exadataコンポーネント(データベース・ノード、ストレージ・セル、およびInfiniBandスイッチ)へのパッチ適用をサポートしています。

フリート・パッチ適用およびプロビジョニングを使用してOracle Exadataシステムに初めてパッチを適用する場合、目的のOracle Exadataノードにパッチを適用する前に、rhpctl add workingcopyコマンドを実行します。これにより、フリート・パッチ適用およびプロビジョニング・サーバーにOracle Exadataシステムの情報(ノードとそれらのノードに最後にパッチを適用したときに使用されたイメージのリスト)が保管されます。
以降のパッチ適用では、rhpctl update workingcopyコマンドを実行します。パッチを適用した後、フリート・パッチ適用およびプロビジョニングによりノードのイメージが更新されます。
EXAPATCHSOFTWAREイメージ・タイプに基づいた作業用コピーに対してrhpctl query workingcopyコマンドを実行すると、ノードとそれらのイメージのリストが返されます。
フリート・パッチ適用およびプロビジョニングを使用してOracle Exadataにパッチを適用するには、次のようにします。
  1. 次のようなrhpctl import imageコマンドを使用して、EXAPATCHSOFTWAREイメージ・タイプのイメージをインポートします。
    $ rhpctl import image -image EXA1 -imagetype EXAPATCHSOFTWARE -path /tmp/ExadataPatchBundle
  -version 12.1.2.2.3.160720

    注意:

    パッチのZIPファイルの名前を変更して、storage、database、およびisoという用語を含める必要があります。これにより、フリート・パッチ適用およびプロビジョニングでこれらを区別できるようになります。
  2. フリート・パッチ適用およびプロビジョニングを使用してOracle Exadataにパッチを適用するのが今回初めての場合、次のようにrhpctl add workingcopyコマンドを使用します。
    $ rhpctl add workingcopy -image image_name -root {[-dbnodes dbnode_list]
  [-cells cell_list] [-ibswitches ibswitch_list]} [-fromnode node_name]
  [-unkey] [-smtpfrom "address"] [-smtpto "addresses"] [-precheckonly]
  [-modifyatprereq] [-resetforce] [-force]

    前述のコマンドでは、ノードのタイプとイメージのタイプに加えて、ノード(データベース・ノード、セル、およびInfiniBandスイッチ)のリストとフリート・パッチ適用およびプロビジョニングの各ノードのバージョンが作業用コピーに保管されます。

  3. 以降のパッチ適用操作では、更新されたデータベース、ストレージ・セル、およびスイッチ・ファイルを使用してゴールド・イメージを作成した後、次のようにrhpctl update workingcopyコマンドを実行して、1つ、2つ、または3つすべてのOracle Exadataコンポーネントにパッチを適用します。
    $ rhpctl update workingcopy -image image_name -root {[-dbnodes dbnode_list] [-cells cell_list]
  [-ibswitches ibswitch_list]} [-fromnode node_name] [-unkey] [-smtpfrom "address"]
  [-smtpto "addresses"] [-precheckonly] [-modifyatprereq] [-resetforce] [-force]

    注意:

    作業用コピーの名前は、指定のOracle Exadataターゲットにパッチを適用するライフ・サイクル全体を通じて同じままです。

    データベース・ノード、セル、またはInfiniBandスイッチのいずれかのみにパッチを適用するか、この3つの任意の組合せに適用するかを選択できます。パッチ適用は、InfiniBandスイッチ、セル、データベース・ノードの順に実行されます。

  4. 次のように、ノードとそれらのイメージのリストが表示されます。
    $ rhpctl query workingcopy -workingcopy working_copy_name
  5. 次のように、作業用コピーを削除します。
    rhpctl delete workingcopy -workingcopy working_copy_name

関連トピック

Oracle Databaseソフトウェアのアップグレード

フリート・パッチ適用およびプロビジョニングでは、Oracle Databaseをアップグレードするオプションが2つ用意されています。どちらのオプションも、単一のコマンドで実行します。

rhpctl upgrade databaseコマンドでは、従来のアップグレードが実行され、停止時間が発生します。rhpctl zdtupgrade databaseコマンドでは、停止時間は最小限またゼロで、Oracle RACまたはOracle RAC One Nodeのアップグレードが実行されます。
Oracle Database 11g リリース2 (11.2.0.3および11.2.0.4)からOracle Database 12c リリース1 (12.1.0.2)にアップグレードするには、rhpctl upgrade databaseコマンドを使用します。Oracle Database 11g リリース2 (11.2.0.3と11.2.0.4)およびOracle Database 12c リリース1 (12.1.0.2)からOracle Database 12c リリース2 (12.2.0.1)へのアップグレードがサポートされています。

注意:

アップグレード前のデータベースが実行されているOracle Grid Infrastructureのバージョンは、アップグレード先のデータベースのバージョン以上にする必要があります。
すでにプロビジョニングされている作業用コピーをアップグレード先にすることも、この操作の一部としてゴールド・イメージの作業用コピーを作成することもできます。
アップグレード前のデータベースは、作業用コピー(フリート・パッチ適用およびプロビジョニングされた管理対象のホーム)、または管理対象外のホームで実行できます。前者の場合は、1つのRHPCTLコマンドでアップグレード・プロセスをロールバックできます。

注意:

アップグレードの完了後は、いつでもソースの作業用コピーを削除できます。ただし、作業用コピーを削除した後は、ロールバックを実行できません。また、rhpctl delete workingcopyコマンド(rmなどではなく)を使用してソースの作業用コピーを削除し、フリート・パッチ適用およびプロビジョニング・インベントリを正常な状態に保ちます。

関連トピック

停止時間0のアップグレード

データベース・アップグレードを自動化および調整するフリート・パッチ適用およびプロビジョニングを使用すると、サービスを中断することなくOracle RACまたはOracle RAC One Nodeデータベースをアップグレードできます。

エラーにより処理が中断した場合でも、停止時間0のアップグレード・プロセスは、再開、再起動、およびリカバリできます。問題を修正した後、コマンドを再実行できます。これにより、フリート・パッチ適用およびプロビジョニングでは、エラーが発生したポイントから処理が続行されます。また、Oracleでは、停止時間0のアップグレード・プロセスの開始時とと終了時にフックが提供され、これにより、ユーザー定義スクリプトを呼び出すことができるため、プロセスをカスタマイズできます。

停止時間0のアップグレード・プロセスを使用して、次の基準を満たすデータベースをアップグレードできます。
  • データベース・アップグレード・ターゲット: Oracle RACおよびOracle RAC One Node。次のアップグレード・パスがあります。
    • 11g リリース2 (11.2.0.4)から12c リリース1 (12.1.0.2)
    • 11g リリース2 (11.2.0.4)から12c リリース2 (12.2.0.1)
    • 12c リリース1 (12.1.0.2)から12c リリース2 (12.2.0.1)

  • フリート・パッチ適用およびプロビジョニング管理: ソース・データベース・ホームは、管理対象外にも(フリート・パッチ適用およびプロビジョニング・サービスでプロビジョニングされていない)、管理対象にも(フリート・パッチ適用およびプロビジョニング・サービスでプロビジョニング)できます。

  • データベース状態: ソース・データベースはアーカイブ・ログ・モードである必要があります。

コンテナ・データベースのアップグレード

フリート・パッチ適用およびプロビジョニングを使用してCDBをアップグレードできますが、フリート・パッチ適用およびプロビジョニングでは、アップグレード中に非CDBをCDBに変換することはできません。停止時間0のアップグレードを準備するには、構成手順および検証チェックを実行します。フリート・パッチ適用およびプロビジョニングを使用して停止時間0のアップグレードを実行した場合は、必要に応じてアップグレードを停止し、再開できます。アップグレード・エラーからリカバリできます。また、アップグレードを再開できます。また、アップグレード中に独自のスクリプトの呼び出しを挿入する機能もあるため、アップグレード手順をカスタマイズできます。

停止時間0のアップグレードの環境の前提条件

  • サーバー環境: フリート・パッチ適用およびプロビジョニングを使用したOracle Grid Infrastructure 18c

  • データベース・ホスト: 次のいずれかのプラットフォームでホストされているデータベース

    • Oracle Grid Infrastructure 18cのフリート・パッチ適用およびプロビジョニング・クライアント

    • Oracle Grid Infrastructure 18cのフリート・パッチ適用およびプロビジョニング・サーバー

    • Oracle Grid Infrastructure 12c (12.2.0.1)のフリート・パッチ適用およびプロビジョニング・クライアント

    • Oracle Grid Infrastructure 12c (12.1.0.2)のターゲット・クラスタ

  • 環境のデータベース固有の前提条件: アップグレード中に、新しいデータベースの準備ができたときに適用されるトランザクションを保持するため、フリート・パッチ適用およびプロビジョニングでは、ローカル・データ・ファイルへのレプリケーションが管理されます。次の2種類のローカル・データ・ファイルが使用されます。
    • スナップ・クローン。これは、データベース・データ・ファイル、REDOログ、およびアーカイブREDOログがOracle ACFSファイル・システムにある場合に使用できます。
    • 他のすべての場合、フル・コピー。

  • フリート・パッチ適用およびプロビジョニングでは、停止時間0のデータベース・アップグレード中に、Oracle GoldenGateまたはOracle Data Guardのいずれかを必要とします。アップグレード手順の一部として、フリート・パッチ適用およびプロビジョニングでは、Oracle GoldenGateデプロイメントが構成および管理されます。

レプリケーションにOracle GoldenGateを使用した停止時間0のアップグレードの実行

Oracle GoldenGateをレプリケーションに使用して停止時間0のアップグレードを実行します。

  1. フリート・パッチ適用およびプロビジョニング・サーバーを準備します。

    フリート・パッチ適用およびプロビジョニング・サーバーのイメージ・ライブラリでOracle GoldenGateソフトウェアのゴールド・イメージを作成します。

    注意:

    Oracle eDeliveryから、ご使用のプラットフォーム用のOracle GoldenGateソフトウェアをダウンロードできます。Oracle GoldenGate 12.3インストール・キットには、Oracle Database 11gデータベースとOracle Database 12cデータベースの双方に必要なソフトウェアが含まれています。

    Oracle GoldenGateソフトウェアをダウンロードする場合、ソフトウェア・ホームを抽出し、フリート・パッチ適用およびプロビジョニング・サーバーでソフトウェアのみのインストールを実行します。

    次のように、双方のデータベースにOracle GoldenGateソフトウェアのゴールド・イメージを作成します。
    $ rhpctl import image -image 112ggimage -path path -imagetype ORACLEGGSOFTWARE
$ rhpctl import image -image 12ggimage -path path -imagetype ORACLEGGSOFTWARE
    前述の両コマンドで、pathは、各データベース・リリースのフリート・パッチ適用およびプロビジョニング・サーバー上のOracle GoldenGateソフトウェア・ホームの場所を示します。

  2. ターゲット・データベースを準備します。

    次のように、データベースをホストしているクラスタにOracle GoldenGateソフトウェアの作業用コピーをプロビジョニングします。
    $ rhpctl add workingcopy -workingcopy GG_Wcopy_11g -image 112ggimage -user
  user_name -node 12102_cluster_node -path path {-root | -sudouser user_name
  -sudopath sudo_bin_path}
$ rhpctl add workingcopy -workingcopy GG_Wcopy_12c -image 12ggimage -user
  user_name -node 12102_cluster_node -path path {-root | -sudouser user_name
  -sudopath sudo_bin_path}
    データベースがフリート・パッチ適用およびプロビジョニング・サーバーでホストされている場合、-targetnodeパラメータも-clientパラメータも必要ありません。

    注意:

    作業用コピー名は一意である必要があるため、後続のターゲットでは別の作業用コピー名を使用する必要があります。作業用コピー名にターゲットの名前/クライアント・クラスタ名を含めることで、一意の作業用コピー名を作成できます。

  3. Oracle Database12cソフトウェア・ホームの作業用コピーをターゲット・クラスタにプロビジョニングします。

注意:

この準備は、ターゲットで実行されている処理を中断させることなく、保守ウィンドウより前に実行できます。
  • フリート・パッチ適用およびプロビジョニング・サーバーでアップグレード・コマンドを実行して、サーバーでホストされているデータベース、Oracle Database 12c リリース1 (12.1.0.2)ターゲット・クラスタ、またはフリート・パッチ適用およびプロビジョニング・クライアント12c リリース2 (12.2.0.1)または18cでホストされているデータベースをアップグレードできます。また、フリート・パッチ適用およびプロビジョニング・クライアント18cでコマンドを実行して、クライアント自体でホストされているデータベースのアップグレードもできます。
    次のようなアップグレード・コマンドを使用します。
    $ rhpctl zdtupgrade database -dbname sierra -destwc DB_Wcopy_121 -ggsrcwc
  GG_Wcopy_11g -ggdstwc GG_Wcopy_12c -targetnode 12102_cluster_node -root

    前述のコマンドで、12102_cluster_nodeは、アップグレード対象のデータベースをホストしているOracle Grid Infrastructure 12c リリース1 (12.1.0.2)クラスタを示します。

関連トピック

レプリケーションにOracle Data Guardを使用した停止時間0のアップグレードの実行

Oracle Data Guardをレプリケーションに使用して停止時間0のアップグレードを実行します。

Oracle Data Guardの一時ロジカル・スタンバイ(TLS)機能を使用して、停止時間0のアップグレード・コマンドを実行できます。必要な手順はすべて、停止時間0のアップグレード・コマンドによってオーケストレートされます。
宛先データベース・ホームをプロビジョニングした後に、次の前提条件を満たしている必要があります。

  • Data Guard Brokerが有効化されていない。

  • フラッシュ・リカバリ領域(FRA)が構成されている。

  • Oracle Data Guardを使用した停止時間0のアップグレードの次の例では、ターゲット・クラスタで実行されているOracle Database 11g リリース2 (11.2.0.4)のsierra(targetclust003というノードが含まれます)が、Oracle Database 12c リリース1 (12.1.0.2)にアップグレードされます(宛先作業用コピーはrhps.example.comという名前のフリート・パッチ適用およびプロビジョニング・サーバーに保管されているゴールド・イメージからプロビジョニングされています)。
    $ rhpctl zdtupgrade database -dbname sierra -destwc WC121DB4344 -clonedatadg DBDATA -targetnode node90743 -root

Enter user "root" password:
node90753.example.com: starting zero downtime upgrade operation ...
node90753.example.com: verifying patches applied to Oracle homes ...
node90753.example.com: verifying if database "sierra" can be upgraded with zero downtime ...
node90743: 15:09:10.459: Verifying whether database "sierra" can be cloned ...
node90743: 15:09:10.462: Verifying that database "sierra" is a primary database ...
node90743: 15:09:14.672: Verifying that connections can be created to database "sierra" ...
< ... >
node90743: 15:14:58.015: Starting redo apply ...
node90743: 15:15:07.133: Configuring primary database "sierra" ...
####################################################################
node90753.example.com: retrieving information about database "xmvotkvd" ...
node90753.example.com: creating services for snapshot database "xmvotkvd" ...
####################################################################
node90743: 15:15:33.640: Macro step 1: Getting information and validating setup ...
< ... >
node90743: 15:16:02.844: Macro step 2: Backing up user environment in case upgrade is aborted  ...
node90743: 15:16:02.848: Stopping media recovery for database "xmvotkvd" ...
node90743: 15:16:05.858: Creating initial restore point "NZDRU_0000_0001" ...
< ... >
node90743: 15:16:17.611: Macro step 3: Creating transient logical standby from existing physical standby ...
node90743: 15:16:18.719: Stopping instance "xmvotkvd2" of database "xmvotkvd" ...
node90743: 15:16:43.187: Verifying that database "sierra" is a primary database ...
< ... >
node90743: 15:19:27.158: Macro step 4: Upgrading transient logical standby database ...
node90743: 15:20:27.272: Disabling service "sierrasvc" of database "xmvotkvd" ...
node90743: 16:36:54.684: Macro step 5: Validating upgraded transient logical standby database ...
node90743: 16:37:09.576: Creating checkpoint "NZDRU_0301" for database "xmvotkvd" during stage "3" and task "1" ...
node90743: 16:37:09.579: Stopping media recovery for database "xmvotkvd" ...
node90743: 16:37:10.792: Creating restore point "NZDRU_0301" for database "xmvotkvd" ...
node90743: 16:37:11.998: Macro step 6: Switching role of transient logical standby database ...
node90743: 16:37:12.002: Verifying that database "sierra" is a primary database ...
< ... >
node90743: 16:39:07.425: Macro step 7: Flashback former primary database to pre-upgrade restore point and convert to physical standby ...
node90743: 16:39:08.833: Stopping instance "sierra2" of database "sierra" ...
< ... >
node90743: 16:41:17.138: Macro step 8: Recovering former primary database ...
node90743: 16:41:19.045: Verifying that database "sierra" is mounted ...
< ... >
node90743: 17:20:21.378: Macro step 9: Switching back ...
< ... >
####################################################################
node90753.example.com: deleting snapshot database "xmvotkvd" ...

停止時間0のアップグレードのカスタマイズ

フリート・パッチ適用およびプロビジョニングのユーザー・アクション・フレームワークを使用して、停止時間0のアップグレードをカスタマイズできます。

ユーザー・アクション・フレームワークを使用するには、全体プロセスにリストされている任意またはすべての項目に対して個別スクリプトを指定します。

表5-3 停止時間0のアップグレードのプラグイン

プラグイン・タイプ 前または後 プラグインの実行時期
ZDTUPGRADE_DATABASE

前

フリート・パッチ適用およびプロビジョニングによる停止時間0のアップグレードの開始前。

後

フリート・パッチ適用およびプロビジョニングによる停止時間0のアップグレードの完了後。
ZDTUPGRADE_DATABASE_SNAPDB

前

スナップショットまたはフル・クローン・データベースの作成前。

後

スナップショットまたはフル・クローン・データベースの開始後(ただし、スイッチオーバーの前)。
ZDTUPGRADE_DATABASE_DBUA

前

DBUAの実行前(スイッチオーバー後)。

後

DBUAの完了後。
ZDTUPGRADE_DATABASE_SWITCHBACK

前

ユーザーをアップグレード後のソース・データベースにスイッチバックする前。

後

ユーザーをアップグレード後のソース・データベースにスイッチバックした後(スナップショットまたはフル・クローン・データベースの削除前)。
  • 停止時間0のアップグレード時に実行するプラグインを登録するには、次のコマンドを実行します。
    $ rhpctl add useraction -useraction user_action_name -actionscript script_name
  {-pre | -post} -optype {ZDTUPGRADE_DATABASE | ZDTUPGRADE_DATABASE_SNAPDB |
   ZDTUPGRADE_DATABASE_DBUA | ZDTUPGRADE_DATABASE_SWITCHBACK}

    rhpctl zdtupgrade databaseコマンドの-useractiondataオプションを使用して、プラグインへの実行時入力を指定できます。

パッチ適用中の永続的ホーム・パス

更新を適用する場合は、アウトオブプレース・パッチ適用をお薦めします。

アウトオブプレース・パッチ適用では、パッチが適用された環境を新しいディレクトリ・パスにデプロイして、ソフトウェア・ホームをその新しいパスに切り替えます。この方法では、新しいホームのプロビジョニング時に既存のホームがアクティブに保持され、中断なくソフトウェアを配信できるため、切替え後に問題が発生した場合にパッチが適用されていないソフトウェア・ホームを使用でき、ロールバックが容易になります。また、データベースのアウトオブプレース・パッチ適用では、ホームで複数のインスタンスが実行されている場合に、インスタンスのサブセットを新しいホームに移動できますが、インプレース・パッチ適用では、すべてのインスタンスに同時にパッチを適用する必要があります。

従来のアウトオブプレース・パッチ適用の潜在的な悪影響は、ソフトウェア・ホームのパスが変更されることです。フリート・パッチ適用およびプロビジョニングでは、Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアで内部的および透過的にこのことが管理されますが、一部のユーザーがパスに依存するスクリプトを開発しています。これに対処するために、フリート・パッチ適用およびプロビジョニングでは、サイト固有の構成の変更からゴールド・イメージ・ソフトウェアを分離できるようにするファイル・システム機能が使用されているため、ソフトウェア・ホームのパスはすべての更新で永続的です。

この機能は、ローカル記憶域でプロビジョニングされたOracle Database 12c リリース2 (12.2)およびOracle Grid Infrastructure 12c リリース2 (12.2)の作業用コピーで使用できます。また、この機能を使用しないでOracle Database 12c リリース2 (12.2)またはOracle Grid Infrastructure 12c リリース2 (12.2)ホームをプロビジョニングした場合は、rhpctl move databaseまたはrhpctl move gihomeコマンドを使用したパッチ適用操作中に、この構成に変換して機能を利用できます。

注意:

フリート・パッチ適用およびプロビジョニング・サーバーからの永続的ホーム・パスに基づくホームを持つ、フリート・パッチ適用およびプロビジョニング・クライアントのOracle Grid Infrastructureのみにパッチを適用できます。

フリート・パッチ適用およびプロビジョニング・クライアントの管理

フリート・パッチ適用およびプロビジョニング・クライアントの管理タスクには、作成、有効化と無効化、ユーザーの作成とそれらのユーザーへのロールの割当ておよびパスワードの管理が含まれます。

SRVCTLおよびRHPCTLを使用すると、フリート・パッチ適用およびプロビジョニング・クライアントのすべての管理タスクを実行できます。

フリート・パッチ適用およびプロビジョニング・クライアントの作成

ユーザーは、Oracleホームのデプロイのリクエストやゴールド・イメージの問合せといったタスクを実行するために、フリート・パッチ適用およびプロビジョニング・クライアントで操作を行います。

フリート・パッチ適用およびプロビジョニング・クライアントを作成する手順は、次のとおりです。

  1. 高可用性VIP (HAVIP)がフリート・パッチ適用およびプロビジョニング・サーバーにない場合は、rootユーザーとして次のようにHAVIPを作成します。
    # srvctl add havip -id id -address {host_name | ip_address}

    ホスト名、IPv4またはIPv6 IPアドレスのいずれかを指定できます。HAVIPに指定するIPアドレス、または指定したホスト名から解決されるアドレスが、このコマンドを実行するときに使用中であってはいけません。

    注意:

    可用性の高いVIPは、フリート・パッチ適用およびプロビジョニング・サーバー・クラスタで構成されているデフォルトのネットワークと同じサブネットに所属している必要があります。次のコマンドを実行することによって､サブネットを取得できます。

    $ srvctl config network -netnum network_number
  2. フリート・パッチ適用およびプロビジョニング・サーバー上で、Gridホームの所有者として、クライアント・データ・ファイルを次のように作成します。
    $ rhpctl add client -client client_cluster_name -toclientdata path

    RHPCTLによって、-toclientdataフラグの後に指定するディレクトリ・パスに、クライアント・データ・ファイルが作成されます。クライアント・データ・ファイルの名前はclient_cluster_name.xmlです。

    注意:

    client_cluster_nameは一意で、手順4を実行するクライアント・クラスタのクラスタ名と一致する必要があります。

  3. フリート・パッチ適用およびプロビジョニング・クライアント上で、Gridホームの所有者が読取り/書込み権限を持つクライアント・クラスタ上のディレクトリに、前述の手順で作成したクライアント・データ・ファイルを、コピーします。
  4. クライアント・クラスタで次のコマンドをrootとして実行し、フリート・パッチ適用およびプロビジョニング・クライアントを作成します。
    # srvctl add rhpclient -clientdata path_to_client_data
   [-diskgroup disk_group_name -storage base_path]

    作業用コピーをこのクラスタのOracle ACFS記憶域にプロビジョニングする場合、そのためのディスク・グループをすでに作成しているときは、そのディスク・グループを前のコマンドに指定します。このケースでは記憶域のパスも指定してください。これは、作業用コピーを格納するためのOracle ACFSファイル・システムを作成するときに、すべてのマウント・ポイントのベース・パスとして使用されます。

    注意:

    フリート・パッチ適用およびプロビジョニング・クライアントでディスク・グループを一度構成すると、フリート・パッチ適用およびプロビジョニング・クライアント構成からディスク・グループを削除したり変更したりすることはできません。いずれか(変更または削除)を実行するには、srvctl remove clientコマンドを使用してフリート・パッチ適用およびプロビジョニング・クライアントを完全に削除するしかありません。その後、必要であれば別のディスク・グループを使用して追加します。フリート・パッチ適用およびプロビジョニング・クライアントを削除する前には、そのクラスタから登録済のすべてのユーザーを削除し、そのクラスタにプロビジョニングされたすべての作業用コピーを削除してください。

  5. フリート・パッチ適用およびプロビジョニング・クライアントを、次のように起動します。
    $ srvctl start rhpclient
  6. フリート・パッチ適用およびプロビジョニング・クライアントのステータスを、次のようにチェックします。
    $ srvctl status rhpclient

関連トピック

フリート・パッチ適用およびプロビジョニング・クライアントの有効化と無効化

フリート・パッチ適用およびプロビジョニング・サーバーで、フリート・パッチ適用およびプロビジョニング・クライアントを有効または無効にできます。

フリート・パッチ適用およびプロビジョニング・クライアントは、すべてのアクションについてフリート・パッチ適用およびプロビジョニング・サーバーと通信します。フリート・パッチ適用およびプロビジョニング・サーバーに接続せずにRHPCTLコマンドを実行することはできません。

フリート・パッチ適用およびプロビジョニング・クライアントを有効または無効にするには、フリート・パッチ適用およびプロビジョニング・サーバー・クラスタから次のコマンドを実行します。

$ rhpctl modify client -client client_name -enabled TRUE | FALSE

フリート・パッチ適用およびプロビジョニング・クライアントを有効化するには、-enabled TRUEと指定します。逆に、クライアントを無効化するには-enabled FALSEを指定します。フリート・パッチ適用およびプロビジョニング・クライアント・クラスタを無効化すると、クライアントを再び有効化しないかぎり、そのクライアント・クラスタからのすべてのRHPCTLコマンドはフリート・パッチ適用およびプロビジョニング・サーバーによって拒否されます。

注意:

フリート・パッチ適用およびプロビジョニング・クライアント・クラスタを無効化しても、そのクライアント・クラスタ上の既存の作業用コピーは無効化されません。作業用コピーは引き続き機能し、その作業用コピー内のデータベースも引き続き実行されます。

フリート・パッチ適用およびプロビジョニング・クライアントの削除

フリート・パッチ適用およびプロビジョニング・クライアントを削除するには、次の手順を使用します。

  1. フリート・パッチ適用およびプロビジョニング・クライアントを削除する前に、次のように、フリート・パッチ適用およびプロビジョニング・サーバー上の作業用コピーおよびユーザーを削除する必要があります。
    1. フリート・パッチ適用およびプロビジョニング・クライアント・クラスタでプロビジョニングされている作業用コピーのリストを問い合せます。

      次のコマンドを実行します。

      $ rhpctl query workingcopy -client client_name
    2. 前述のコマンドの出力にリストされた各作業用コピーを削除します。

      作業用コピーごとに次のコマンドを実行して、削除する作業用コピーの名前を指定します。

      $ rhpctl delete workingcopy -workingcopy working_copy_name
    3. フリート・パッチ適用およびプロビジョニング・クライアント・クラスタからユーザーのリストを問い合せます。

      次のコマンドを実行します。

      $ rhpctl query user -client client_name
    4. 次のように、前述のコマンドの出力にリストされたユーザーを削除します。

      次のコマンドを実行して、削除するユーザーの名前とクライアントの名前を指定します。

      $ rhpctl delete user -user user_name —client client_name
  2. フリート・パッチ適用およびプロビジョニング・クライアント・クラスタで、次のようにクライアントを削除します。
    1. フリート・パッチ適用およびプロビジョニング・クライアント・デーモンを停止します。

      次のコマンドを実行します。

      $ srvctl stop rhpclient
    2. フリート・パッチ適用およびプロビジョニング・クライアント構成を削除します。

      次のコマンドを実行します。

      $ srvctl remove rhpclient
  3. フリート・パッチ適用およびプロビジョニング・サーバー・クラスタのクライアントのサイト構成を削除します。

    次のコマンドを実行して、クライアントの名前を指定します。

    $ rhpctl delete client -client client_name

フリート・パッチ適用およびプロビジョニング・クライアント・クラスタ・ユーザーのためのユーザーの作成とロールの割当て

rhpctl add clientコマンドを使用してフリート・パッチ適用およびプロビジョニング・クライアントを作成した場合は、-maprolesパラメータを使用してユーザーを作成してロールを割り当てることができます。このコマンドで、複数のユーザーをロールに関連付けたり、1ユーザーに複数のロールを割り当てたりすることができます。

クライアントが作成されたら、rhpctl grant roleコマンドを使用してユーザーのロールを追加することも、rhpctl revoke roleコマンドを使用してユーザーのロールを削除することもできます。

フリート・パッチ適用およびプロビジョニング・クライアント・パスワードの管理

フリート・パッチ適用およびプロビジョニング・クライアントは、内部に格納されているパスワードを使用して、RHPサーバーに対して自らを認証します。このパスワードを問い合せることはできません。ただし、なんらかの理由によってこのパスワードをリセットする必要がある場合には、RHPサーバー・クラスタで次のように行うことができます。

  1. フリート・パッチ適用およびプロビジョニング・サーバー・クラスタで次のコマンドを実行し、新しいパスワードを生成して、クライアント資格証明に格納します。
    $ rhpctl modify client -client client_name -password
  2. フリート・パッチ適用およびプロビジョニング・サーバー・クラスタで次のコマンドを実行し、資格証明ファイルを生成します。
    $ rhpctl export client -client client_name -clientdata file_path

    たとえば、フリート・パッチ適用およびプロビジョニング・クライアントの資格証明ファイルmjk9394を生成するには、次のようにします。 

    $ rhpctl export client -client mjk9394 -clientdata /tmp/mjk9394.xml
  3. 前の例に続いて、生成された資格証明ファイルをフリート・パッチ適用およびプロビジョニング・クライアント・クラスタにセキュアに転送し、次のコマンドをフリート・パッチ適用およびプロビジョニング・クライアント・クラスタの任意のノードで実行します。
    $ srvctl modify rhpclient -clientdata path_to_mjk9394.xml
  4. フリート・パッチ適用およびプロビジョニング・クライアント・クラスタで次のコマンドを実行して、フリート・パッチ適用およびプロビジョニング・クライアント・デーモンを再起動します。
    $ srvctl stop rhpclient
$ srvctl start rhpclient

ユーザー定義のアクション

イメージのインポート、作業用コピーの追加および削除、ソフトウェア・ホームの追加、削除、移動およびアップグレードなど、様々なフリート・パッチ適用およびプロビジョニングの操作に関するアクションを作成できます。

イメージのインポート、ゴールド・イメージの作業用コピーの追加および削除、ソフトウェア・ホームの追加、削除、移動およびアップグレードなど、様々なフリート・パッチ適用およびプロビジョニングの操作に関するアクションを作成できます。操作ごとに異なるアクションを定義して、操作が適用されるイメージのタイプでさらにそれらを区別できます。ユーザー定義のアクションは、特定の操作の前後で実行でき、操作が実行されるデプロイメント(フリート・パッチ適用およびプロビジョニング・サーバー、フリート・パッチ適用およびプロビジョニング・クライアント(12c リリース2 (12.2)以降)、またはフリート・パッチ適用およびプロビジョニング・クライアントを実行していないターゲット)で実行されます。

ユーザー定義のアクションは、フリート・パッチ適用およびプロビジョニング・サーバーに格納されるシェル・スクリプトです。スクリプト実行時に、コマンドラインで操作に関連する情報が付与されます。また、スクリプトとファイルを関連付けることができます。フリート・パッチ適用およびプロビジョニング・サーバーにより、スクリプトが実行されるクライアントまたはターゲットの同じ場所にそのファイルがコピーされます。

たとえば、データベースのアップグレード後に実行するユーザー定義のアクションを作成する場合や、Oracle Database 11gと12cで異なるアクションを定義する場合などがあります。この場合、次の手順の例のように、新しいイメージ・タイプを定義する必要があります。

  1. 次のように、ORACLEDBSOFTWAREイメージ・タイプに基づいて、新しいイメージ・タイプ(たとえば、DB11IMAGE)を作成します。 

    $ rhpctl add imagetype -imagetype DB11IMAGE -basetype ORACLEDBSOFTWARE

    Oracle Database 11gゴールド・イメージを追加またはインポートするときに、DB11IMAGEイメージ・タイプを指定します。

  2. ユーザー・アクションを定義して、それをDB11IMAGEイメージ・タイプおよびアップグレード操作に関連付けます。アップグレードの前または後で異なるアクションを実行できます。

  3. Oracle Database 12cのアクションを定義するには、前の手順のようにORACLEDBSOFTWAREイメージ・タイプに基づく新しいイメージ・タイプ(たとえば、DB12IMAGE)を作成しますが、DB12IMAGEイメージ・タイプを指定します。

    注意:

    ユーザー定義のイメージ・タイプのベース・タイプにユーザー・アクションを定義する場合(このケースでは、ベース・タイプはORACLEDBSOFTWARE)、ユーザー定義のイメージ・タイプのアクションの前に、フリート・パッチ適用およびプロビジョニングによってこれらのアクションが実行されます。

rhpctl modify imageコマンドを使用して、イメージのイメージ・タイプを変更できます。さらに、他のアクションを変更、追加および削除できます。次の、表5-4と表5-5の2つの表は、それぞれ、カスタマイズできる操作と、それらの操作を定義するために使用できるパラメータを示しています。

表5-4 フリート・パッチ適用およびプロビジョニングのユーザー定義操作

操作 パラメータ・リスト
IMPORT_IMAGE

RHP_OPTYPE、RHP_PHASE、RHP_PATH、RHP_PATHOWNER、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ADD_WORKINGCOPY

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_PATH、RHP_STORAGETYPE、RHP_USER、RHP_NODES、RHP_ORACLEBASE、RHP_DBNAME、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ADD_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_DBNAME、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
DELETE_WORKINGCOPY

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_PATH、RHP_PROGRESSLISTENERHOS、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
DELETE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_DBNAME、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
MOVE_GIHOME

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOS、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CL、RHP_USERACTIONDATA
MOVE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_DATAPATCH、RHP_USERACTIONDATA
UPGRADE_GIHOME

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
UPGRADE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ADDNODE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_DBNAME、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
DELETENODE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_DBNAME、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ADDNODE_GIHOME

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_PATH、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
DELETENODE_GIHOME

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_PATH、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ADDNODE_WORKINGCOPY

RHP_OPTYPE、RHP_PHASE、RHP_WORKINGCOPY、RHP_CLIENT、RHP_PATH、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_IMAGE、RHP_IMAGETYPE、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ZDTUPGRADE_DATABASE

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_SRCGGWC、RHP_SRCGGPATH、RHP_DSTGGWC、RHP_DSTGGPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ZDTUPGRADE_DATABASE_SNAPDB

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_SRCGGWC、RHP_SRCGGPATH、RHP_DSTGGWC、RHP_DSTGGPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ZDTUPGRADE_DATABASE_DBUA

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_SRCGGWC、RHP_SRCGGPATH、RHP_DSTGGWC、RHP_DSTGGPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA
ZDTUPGRADE_DATABASE_SWITCHBACK

RHP_OPTYPE、RHP_PHASE、RHP_SOURCEWC、RHP_SOURCEPATH、RHP_DESTINATIONWC、RHP_DESTINATIONPATH、RHP_SRCGGWC、RHP_SRCGGPATH、RHP_DSTGGWC、RHP_DSTGGPATH、RHP_DBNAME、RHP_IMAGE、RHP_IMAGETYPE、RHP_PROGRESSLISTENERHOST、RHP_PROGRESSLISTENERPORT、RHP_VERSION、RHP_CLI、RHP_USERACTIONDATA

表5-5 ユーザー定義の操作のパラメータ

パラメータ 説明
RHP_OPTYPE

前の表に示されている、ユーザー・アクションの実行対象の操作のタイプ。
RHP_PHASE

このパラメータは、ユーザー・アクションが操作の前に実行されるか、後に実行されるかを示します(PREまたはPOST)。
RHP_SOURCEWC

アップグレード操作のパッチ用のソースの作業用コピー名。
RHP_SOURCEPATH

ソースの作業用コピーのホームのパス。
RHP_DESTINATIONWC

パッチまたはアップグレード操作用の宛先の作業用コピー名。
RHP_DESTINATIONPATH

宛先の作業用コピーのホームのパス。
RHP_SRCGGWC

アップグレード元のOracle GoldenGate作業用コピーのバージョンの名前。
RHP_SRCGGPATH

アップグレード元のOracle GoldenGateソフトウェア・ホームのバージョンの絶対パス。
RHP_DESTGGWC

アップグレード先のOracle GoldenGate作業用コピーのバージョンの名前。
RHP_DESTGGPATH

アップグレード先のOracle GoldenGateソフトウェア・ホームのバージョンの絶対パス。
RHP_PATH

これは、ソフトウェア・ホームの場所のパスです。このパラメータは、IMPORT_IMAGE操作については、RHPCTLコマンドが実行されているローカル・ノードのパスを表します。その他すべての操作については、このパスは、操作が実行されているサイトに存在します。

RHP_PATHOWNER

インポートされているゴールド・イメージのパスの所有者。
RHP_PROGRESSLISTENERHOST

進捗リスナーがリスニングしているホスト。進捗リスナーのポートとともにこのパラメータを使用してTCP接続を作成し、RHPCTLコマンドが実行されているコンソールに出力を表示できます。
RHP_PROGRESSLISTENERPORT

進捗リスナーがリスニングしているポート。進捗リスナーのホスト名とともにこのパラメータを使用してTCP接続を作成し、RHPCTLコマンドが実行されているコンソールに出力を表示できます。
RHP_IMAGE

操作に関連するイメージ。移動操作の場合は、デスティネーション・イメージの名前が反映されます。
RHP_IMAGETYPE

操作に関連するイメージのイメージ・タイプ。移動操作の場合は、デスティネーション・イメージの名前が反映されます。
RHP_VERSION

フリート・パッチ適用およびプロビジョニング・サーバーで実行されているOracle Grid Infrastructureソフトウェアのバージョン。
RHP_CLI

操作を起動するために実行された正確なコマンド。
RHP_STORAGETYPE

ホームの記憶域のタイプ(LOCALまたはRHP_MANAGED)。

RHP_USER

操作の実行対象となるユーザー。
RHP_NODES

プロファイルが作成されるノード。
RHP_ORACLEBASE

プロビジョニングしたホームのOracleベースの場所。
RHP_DBNAME

作成するデータベースの名前。
RHP_CLIENT

クライアント・クラスタの名前。
RHP_DATAPATCH

このパラメータは、データベースの移動操作の完了後にSQLパッチが実行されるノードで、ユーザー・アクションの最後にTRUEに設定されます。
RHP_USERACTIONDATA

このパラメータはすべての操作に存在し、実行時に引数としてユーザー定義の項目をユーザー・アクションに渡すために使用されます。

ユーザー定義のアクションの例

Apacheデプロイメントのプロビジョニングと管理に使用する、APACHESWというイメージ・タイプがあるとします。また、apacheinstallという名前の、Apacheのゴールド・イメージもあるとします。次の例は、Apacheゴールド・イメージのコピーをプロビジョニングする前に実行されるユーザー・アクションを作成する方法を示しています。

以下は、addapache_useraction.shという名前のサンプル・ユーザー・アクション・スクリプトです。 

$ cat /scratch/apacheadmin/addapache_useraction.sh
#!/bin/sh

#refer to arguments using argument names 
touch /tmp/SAMPLEOUT.txt;
for i in "$@"
do
    export $i
done

echo "OPTYPE = $RHP_OPTYPE" >> /tmp/SAMPLEOUT.txt;
echo "PHASE = $RHP_PHASE" >> /tmp/SAMPLEOUT.txt;
echo "WORKINGCOPY = $RHP_WORKINGCOPY" >> /tmp/SAMPLEOUT.txt;
echo "PATH = $RHP_PATH" >> /tmp/SAMPLEOUT.txt;
echo "STORAGETYPE = $RHP_STORAGETYPE" >> /tmp/SAMPLEOUT.txt;
echo "USER = $RHP_USER" >> /tmp/SAMPLEOUT.txt;
echo "NODES = $RHP_NODES" >> /tmp/SAMPLEOUT.txt;
echo "ORACLEBASE = $RHP_ORACLEBASE" >> /tmp/SAMPLEOUT.txt;
echo "DBNAME = $RHP_DBNAME" >> /tmp/SAMPLEOUT.txt;
echo "PROGRESSLISTENERHOST = $RHP_PROGRESSLISTENERHOST" >> /tmp/SAMPLEOUT.txt;
echo "PROGRESSLISTENERPORT = $RHP_PROGRESSLISTENERPORT" >> /tmp/SAMPLEOUT.txt;
echo "IMAGE = $RHP_IMAGE" >> /tmp/SAMPLEOUT.txt;
echo "IMAGETYPE = $RHP_IMAGETYPE" >> /tmp/SAMPLEOUT.txt;
echo "RHPVERSION = $RHP_VERSION" >> /tmp/SAMPLEOUT.txt;
echo "CLI = $RHP_CLI" >> /tmp/SAMPLEOUT.txt;
echo "USERACTIONDATA = $RHP_USERACTIONDATA" >> /tmp/SAMPLEOUT.txt;
$

このスクリプトは、rhpctl add workingcopyコマンドの開始時に実行されるように登録されています。スクリプトが失敗した場合、作業用コピーの追加操作は中止されます。

次のコマンドでは、addapachepreという名前のユーザー・アクションが作成されます。

$ rhpctl add useraction -optype ADD_WORKINGCOPY -pre -onerror ABORT -useraction
  addapachepre -actionscript /scratch/apacheadmin/addapache_useraction.sh
  -runscope ONENODE

次のコマンドでは、APACHESWイメージ・タイプにユーザー・アクションが登録されます。 

$ rhpctl modify imagetype -imagetype APACHESW -useractions addapachepre

登録されたユーザー・アクションは、次のように、APACHESWタイプのイメージの作業用コピーをデプロイするコマンドの開始時に自動的に呼び出されます。

$ rhpctl add workingcopy -workingcopy apachecopy001 -image apacheinstall 
  -path /scratch/apacheadmin/apacheinstallloc -sudouser apacheadmin -sudopath
  /usr/local/bin/sudo -node targetnode003 -user apacheadmin -useractiondata "sample"

このサンプル・スクリプトにより、出力ファイル/tmp/SAMPLEOUT.txtが作成されます。例のコマンドに基づいた場合、出力ファイルには次の内容が含まれます。 

$ cat /tmp/SAMPLEOUT.txt
OPTYPE = ADD_WORKINGCOPY
PHASE = PRE
WORKINGCOPY = apachecopy001
PATH = /scratch/apacheadmin/apacheinstallloc
STORAGETYPE =
USER = apacheadmin
NODES = targetnode003
ORACLEBASE =
DBNAME =
PROGRESSLISTENERHOST = mds11042003.my.company.com
PROGRESSLISTENERPORT = 58068
IMAGE = apacheinstall
IMAGETYPE = APACHESW
RHPVERSION = 12.2.0.1.0
CLI = rhpctl__add__workingcopy__-image__apacheinstall__-path__/scratch/apacheadmin
 /apacheinstallloc__-node__targetnode003__-useractiondata__sample__
 -sudopath__/usr/local/bin/sudo__-workingcopy__apachecopy__-user__apacheadmin__
 -sudouser__apacheadmin__USERACTIONDATA = sample
$

注意:

  • 前述の出力の例では、空の値は等号(=)で終了します。

  • RHP_CLIパラメータのコマンドラインの値にあるスペースは、他のパラメータと区別するために、2つのアンダースコア(__)に置き換えられます。

操作用のジョブ・スケジューラ

フリート・パッチ適用およびプロビジョニングのジョブ・スケジューラには、コマンドをすぐに実行するのではなくスケジュールされた時間に操作を発行して、ジョブのメタデータを問い合せ、リポジトリからジョブを削除する機能があります。

フリート・パッチ適用およびプロビジョニングのジョブ・スケジューラには次の機能があります。

  • 時間値を指定して、特定の時点で実行するコマンドをスケジュールする

  • ジョブを実行し、現在のジョブのステータスとともにジョブのメタデータを格納する

  • 実行済または実行中の各ジョブのログを格納する

  • ジョブの詳細(ユーザー・ロールに基づいて、すべてのジョブまたは特定のジョブ)を問い合せる

  • ジョブの削除

  • ユーザーのロールベースのアクセス権に基づいて、ジョブを実行する、問合せる、削除する

次のRHPCTLコマンドで-schedule timer_valueコマンド・パラメータを使用して、特定の高速ホーム・プロビジョニング操作をスケジュールします。

  • rhpctl add workingcopy

  • rhpctl import image

  • rhpctl delete image

  • rhpctl add database

  • rhpctl move gihome

  • rhpctl move database

  • rhpctl upgrade database

  • rhpctl addnode database

  • rhpctl deletenode database

  • rhpctl delete workingcopy

次に例を示します。
$ rhpctl add workingcopy -workingcopy 18_3 -image 18_3_Base -oraclebase /u01/app/oracle -schedule 2016-12-21T19:13:17+05

すべてのコマンドは、ISO-8601値に従ってサーバーのタイムゾーンを基準に実行され、RHPCTLには同じタイムゾーンを指定してコマンド結果が表示されます。

コマンドの結果

RHPCTLは、フリート・パッチ適用およびプロビジョニング・サーバー上のコマンド・キューから実行されるコマンドを格納します。コマンド識別子を指定してコマンド結果を問い合せると、RHPCTLはジョブ出力ファイルへのパスを結果とともに戻します。

Job Operation

-scheduleパラメータを指定してRHPCTLコマンドを実行すると、一意のジョブIDを持つジョブが作成されます。このIDは、ジョブのステータスを取得する際に問い合せることができます。

ジョブ・ステータス

任意の時点で、ジョブは次のいずれかの状態になります。
EXECUTED | TIMER_RUNNING | EXECUTING | UNKNOWN | TERMINATED

  • EXECUTED: ジョブが完了しました。

  • TIMER_RUNNING: ジョブのタイマーがまだ実行中です。

  • EXECUTING: ジョブのタイマーが期限切れであり、実行中です。

  • UNKNOWN: ターゲットの停止、ノードの停止、リソース障害などの問題が原因で、予期しない障害があります。

  • TERMINATED: 異常終了が発生しているか、操作が停止しました。

関連トピック

フリート・パッチ適用およびプロビジョニングのユース・ケース

以下のトピックでは、フリート・パッチ適用およびプロビジョニングを使用してソフトウェアのプロビジョニング、パッチ適用、アップグレードを行うための手順を段階ごとに示します。

フリート・パッチ適用およびプロビジョニングは、ソフトウェア・ライフサイクル管理ソリューションであり、標準運用環境のパッチ適用、プロビジョニングおよびアップグレードを標準化するのに役立ちます。

Oracle Grid Infrastructure 12cリリース2デプロイメントの作成

現在Gridホームのない2つのノードでOracle Grid Infrastructureをプロビジョニングし、その後、マルチノードのOracle Grid Infrastructureインストールを形成するようにOracle Grid Infrastructureを構成します。

始める前に

Oracle Grid Infrastructureをインストールするための、ストレージ、ネットワーク、ユーザー、グループおよびノード情報の構成詳細を、レスポンス・ファイルに指定してください。レスポンス・ファイルは、フリート・パッチ適用およびプロビジョニング・サーバー上の任意の場所に格納できます。

Oracle Standalone Cluster、Oracle Application Clusters、Oracle Domain Services ClusterまたはOracle Member Clustersをプロビジョニングできます。レスポンス・ファイルに、必要なクラスタ構成詳細が含まれていることを確認してください。

『Oracle Grid Infrastructureインストレーション・ガイド』に記載されているように、ストレージ、ネットワークおよびオペレーティング・システムの要件が構成されていることを確認してください。

手順

  • フリート・パッチ適用およびプロビジョニング・サーバーから、次のコマンドを実行します。
    $ rhpctl add workingcopy -workingcopy GI122 -image GI_HOME_12201 –responsefile /u01/app/rhpinfo/GI_12201_install.rsp {authentication_option}

    GI122は、イメージGI_HOME_12201に基づく作業用コピーです

    /u01/app/rhpinfo/GI_12201_install.rspはレスポンス・ファイルの場所です。

    クラスタ検証ユーティリティは、要件に応じてインストール前の構成をチェックします。フリート・パッチ適用およびプロビジョニングは、Oracle Grid Infrastructureを構成します。

Oracle Grid Infrastructure 12cリリース2は、同じレスポンス・ファイル内の設定に基づいてプロビジョニングされます。

プロビジョニング中にエラーが発生した場合は、プロシージャが停止し、エラーを修正できます。エラーを修正したら、最後に停止した場所からプロビジョニング操作を再開できます。

ビデオを見る

Oracle Databaseホームのプロビジョニングとデータベースの作成

この手順では、Oracle Database 12cリリース2 (12.2)ソフトウェアをプロビジョニングし、Oracle Databaseインスタンスを作成します。

手順

  1. フリート・パッチ適用およびプロビジョニング・サーバーから、Oracle Databaseホーム・ソフトウェアをプロビジョニングします。
    $ rhpctl add workingcopy -image db12201 -path /u01/app/dbusr/product/12.2.0/db12201
  -client client_001 -oraclebase /u01/app/dbusr/ -workingcopy db122
    このコマンドを実行すると、クラスタclient_001上の指定されたパスに、作業用コピーdb122がプロビジョニングされます(イメージdb12201から)。
  2. データベース・インスタンスを作成します。
    $ rhpctl add database -workingcopy db122 -dbname db -dbtype RAC
    このコマンドを実行すると、Oracle RACデータベース・インスタンスdbが作成されます。add databaseコマンドを使用すれば、作業用コピー上に追加のインスタンスを繰り返し作成できます。

ビデオを見る

プラガブル・データベースのプロビジョニング

プロビジョニングされたデータベース作業用コピーで実行されている既存のコンテナ・データベース(CDB)にプラガブル・データベース(PDB)をプロビジョニングできます。

ゴールド・イメージの作業用コピーを作成してターゲットにプロビジョニングし、マルチテナントCDBとしてデータベースを作成すると、rhpctl addpdb databaseコマンドを使用してそのCDBにPDBを追加できます。
  • 次のコマンド例では、wc_db183という作業用コピー上のraccdb183というCDBに、pdb183というPDBを作成します。
    $ rhpctl addpdb database -workingcopy wc_db183 -cdbName raccdb183 -pdbName pdb183
  • 作業用コピー上の既存のCDBからPDBを削除するには、rhpctl deletepdb databaseコマンドを使用します。
    次のコマンド例では、wc_db183という作業用コピー上のraccdb183というCDBに、pdb183というPDBを削除します。
    $ rhpctl deletepdb database -workingcopy wc_db183 -cdbName raccdb183 -pdbName pdb183

Oracle Grid Infrastructure 12cリリース2へのアップグレード

この手順では、フリート・パッチ適用およびプロビジョニングを使用して、Oracle Grid Infrastructureクラスタを11gリリース2 (11.2.0.4)から12cリリース2 (12.2)にアップグレードします。

始める前に

Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)にアップグレードするには、ソースがOracle Grid Infrastructure 11gリリース2 (11.2.0.3または11.2.0.4)か、Oracle Grid Infrastructure 12cリリース2 (12.1.0.2)である必要があります。

ソース・ホームで構成されているグループが宛先ホームのものに一致することを確認してください。

作業用コピーをプロビジョニングするための、Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)ソフトウェアのイメージGI_HOME_12201があることを確認してください。

GI_11204は、アップグレードされるクラスタ上のアクティブなGrid Infrastructureホームです。これは作業用コピーです(この例では、フリート・パッチ適用およびプロビジョニングによってクラスタがプロビジョニングされているため)。フリート・パッチ適用およびプロビジョニングでは、Grid Infrastructureホームが管理対象外のクラスタ(つまり、フリート・パッチ適用およびプロビジョニングによってプロビジョニングされなかったホーム)をアップグレードすることもできます。

手順

  1. Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)ソフトウェアの作業用コピーをプロビジョニングします。
    $ rhpctl add workingcopy -workingcopy GI122 -image GI_HOME_12201 {authentication_option}

    GI122は、イメージGI_HOME_12201に基づく作業用コピーです。

  2. ターゲット・クラスタをGI122作業用コピーにアップグレードします。
    rhpctl upgrade gihome -sourcewc GI11204 -destwc GI122
    高速ホーム・プロビジョニングは、ソース作業用コピーの名前に基づいてアップグレード対象のクラスタを識別し、作業用コピー GI122にアップグレードします。

Gridホーム・パスを変更しないOracle Grid Infrastructureのパッチ適用

この手順では、Gridホーム・パスを変更せずに、Oracle Grid Infrastructureにパッチを適用する方法について説明します。

始める前に

  • Gridホームを含んだゴールド・イメージがインポートされ、フリート・パッチ適用およびプロビジョニング・サーバー上に存在していることを確認してください。

  • ­pathオプションで指定したディレクトリが既存のディレクトリでないことを確認してください。

  • ソースGridホームは、管理対象のホーム(フリート・パッチ適用およびプロビジョニングによってプロビジョニングされるホーム)である必要があります。これは、Oracleレイヤー・ファイルシステム(OLFS)準拠のホームである必要はありません。

  • Gridホームは、Oracle Grid Infrastructure 12c (12.2.0.1)以降である必要があります。

パッチ適用の手順

  • OLFSに準拠していないGridホームをOLFS Gridホームに移行するには、フリート・パッチ適用およびプロビジョニング・サーバーから、次のような2つのコマンドを実行します。
    $ rhpctl add workingcopy -workingcopy GI_HOME_12201_PSU1 -aupath
  /u01/app/orabase/product/12.2.0.1/aupath -image image_name
  -client client_name -softwareonly
    $ rhpctl move gihome -srcwc GI_HOME_12201 -destwc GI_HOME_12201_PSU1 -agpath
  /u01/app/orabase/product/12.2.0.1/agpath -path
  /u01/app/orabase/product/12.2.0.1/grid
  • OLFS準拠のGridホームをパッチ適用済バージョンに移行するには、次のような2つのコマンドを実行します。
    $ rhpctl add workingcopy -workingcopy gihome12201_psu1_lpm -aupath
  /u01/app/orabase/product/12.2.0.1/aupath -image image_name -client
  client_name -softwareonly
    $ rhpctl move gihome -sourcewc gihome12201_lpm -destwc gihome12201_psu1_lpm

Oracle Grid InfrastructureとOracle Databaseの同時パッチ適用

この手順では、クラスタのダウンタイムを発生させずに、クラスタ上のOracle Grid InfrastructureとOracle Databaseに最新のパッチ・レベルを適用します。

始める前に

この手順では、Oracle Grid Infrastructure 12cリリース2 (12.2.0.1)がターゲット・クラスタ上で実行されています。作業用コピーGI_HOME_12201_WCPYは、このクラスタ上のアクティブなGridホームです。作業用コピーDB_HOME_12201_WCPYでは、Oracle RAC 12cリリース2 (12.2.0.1)データベースが実行され、データベース・インスタンスdb1が実行されています。作業用コピーDB_HOME_12102_WCPYでは、Oracle RAC 12cリリース1 (12.1.0.2)データベースが実行され、データベース・インスタンスdb2が実行されています

フリート・パッチ適用およびプロビジョニング・サーバー上で、Oracle Grid InfrastructureとOracle RACデータベースに必要なパッチが、イメージGI_HOME_12201_PSU1、DB_HOME_12201_PSU1、DB_HOME_12102_PSU5に適用されていることを確認してください。

ソース・ホームで構成されているグループは、宛先ホームのものに一致する必要があります。

手順

  1. 次の手順で、ターゲットOracleホームを準備します。
    1. パッチ適用するクラスタ上のソフトウェア専用Gridホームをプロビジョニングします。
      $ rhpctl add workingcopy -workingcopy GI_HOME_12201_PATCHED_WCPY 
  -image GI_HOME_12201_PSU1 –client CLUSTER_005 -softwareonly
    2. パッチ適用する各リリースのデータベース・ホーム(データベース・インスタンスなし)をプロビジョニングします。
      $ rhpctl add workingcopy -workingcopy DB_HOME_12201_PATCHED_WCPY 
  -image DB_HOME_12201_PSU1
$ rhpctl add workingcopy -workingcopy DB_HOME_12102_PATCHED_WCPY 
  -image DB_HOME_12102_PSU5
  2. 次のコマンドを実行して、Oracle Grid Infrastructureと、node1上のすべてのOracle RACデータベースにパッチを適用します。
    $ rhpctl move gihome -sourcewc GI_HOME_12201_WCPY -destwc GI_HOME_12201_PATCHED_WCPY -auto
  -dbhomes DB_HOME_12102_WCPY=DB_HOME_12102_PATCHED_WCPY,DB_HOME_12201_WCPY=DB_HOME_12201_PATCHED_WCPY  -targetnode node1 {authentication_option}

    このコマンドを実行すると、アクティブなOracle Grid Infrastructureが作業用コピーGI_HOME_12201_WCPYからGI_HOME_12201_PATCHED_WCPYに、Oracle RACデータベースdb1がDB_HOME_12201_WCPYからDB_HOME_12201_PATCHED_WCPYに、Oracle RACデータベースdb2がDB_HOME_12102_WCPYからDB_HOME_12102_PATCHED_WCPYに移動されます。

ダウンタイムを発生させないOracle Database 12cリリース1のパッチ適用

この手順では、データベースをダウンさせずに、Oracle Database 12cリリース1 (12.1.0.2)に最新のパッチを適用する方法について説明します。

始める前に

最新のパッチ・レベルにパッチ適用するOracle Database db12102があることを確認してください。

DB12102_PSUイメージに基づく作業用コピーdb12102_psuに、最新のパッチが含まれていて、利用可能であることを確認してください。

手順

フリート・パッチ適用およびプロビジョニング・サーバーから、データベース上のソースと宛先に応じて、次のいずれかのコマンドを実行します。

  1. フリート・パッチ適用およびプロビジョニングによって管理されるOracle Databaseホームにパッチを適用する場合で、ソースおよび宛先データベースの作業用コピーが存在する場合は、次のコマンドを実行します。
    rhpctl move database -sourcewc db12102 -patchedwc db12102_psu

    db12102は、パッチが適用されるデータベースのソース作業用コピーです。

    db12102_psuは、パッチが適用されたOracle Databaseソフトウェアの作業用コピーです(イメージDB12102_PSUに基づく)。

  2. 管理対象外のOracle Databaseホームにパッチを適用するには、次のコマンドを実行します(Oracleホームはフリート・パッチ適用およびプロビジョニングによって管理されないため、ソース作業用コピーは存在しません)。
    rhpctl move database -sourcehome /u01/app/orabase/product/12.1.0.2/dbhome_1
 -patchedwc db12102_psu -targetnode node1

    targetnodeでは、アップグレード対象のデータベースが実行されているノードを指定します(ソースOracle Databaseは12.1.0.2クラスタ上にあるため)。

    /u01/app/orabase/product/12.1.0.2/dbhome_1はアップグレードされるデータベースのパスです

    db12102_psuは、パッチが適用されたOracle Databaseソフトウェアの作業用コピーです(イメージDB12102_PSUに基づく)。

    リリース12cリリース1のすべてのデータベースのパッチ適用を同じパッチ・レベルへと標準化するために、保存されたゴールド・イメージを使用します。
  3. なんらかの理由で、管理対象のOracle Databaseホームに適用されたパッチをロールバックする必要がある場所は、次のコマンドを実行します。
    rhpctl move database -sourcewc db12102_psu 
-patchedwc db12102 -ignorewcpatches

    db12102は、ロールバックするパッチ未適用データベースの作業用コピーです。

    db12102_psuは、パッチが適用されたOracle Databaseソフトウェアの作業用コピーです(イメージDB12102_PSUに基づく)。

すべてのOracle Databaseについて、move databaseコマンドでは次の追加オプションも指定できます。

  • -keepplacement: 管理者によって管理されるOracle RACデータベース(Oracle RAC One Nodeデータベースではありません)のために、フリート・パッチ適用およびプロビジョニングは移動後もサービスを同じノード上に保持します。

  • -disconnect: サービスを停止または再配置する前にすべてのセッションを切断します。

  • -drain_timeout: 計画的なメンテナンス操作のためのリソース排出が完了するまでの許容時間を秒数で指定します。ドレイン期間中は、現在のすべてのクライアント要求は処理されますが、新しい要求は受け入れません。このオプションは、Oracle Database 12cリリース2 (12.2)以降についてのみ使用できます。

  • -stopoption: データベースを停止します。

  • -nodatapatch: 移動するデータベースに対してdatapatchが実行されていないことを確認します。

ビデオを見る

Oracle Database 12cリリース2へのアップグレード

この手順では、管理対象と管理対象外の両方のOracleホームを対象に、フリート・パッチ適用およびプロビジョニングを使用してOracle Database 11g リリース2 (11.2)から12c リリース2へと単一コマンドでOracleデータベースをアップグレードする方法について説明します。

始める前に

  • Oracle Database 12cリリース2 (12.2.0.1)にアップグレードするには、ソース・データベースがOracle Database 11gリリース2 (11.2.0.3または11.2.0.4)か、Oracle Database 12cリリース1 (12.1.0.2)のいずれかである必要があります。

  • アップグレード前のデータベースが実行されているOracle Grid Infrastructureは、アップグレード先のデータベースのリリース以上である必要があります。

  • アップグレードされるソースOracleホームは、管理対象の作業用コピー(つまり、フリート・パッチ適用およびプロビジョニングを使用してプロビジョニングされたOracleホーム)であっても、管理対象外のホーム(つまり、フリート・パッチ適用およびプロビジョニングを使用してプロビジョニングされなかったOracleホーム)であってもかまいません。管理対象外のOracleホームをアップグレードする場合は、アップグレード用のデータベースの完全パスを指定してください。

フリート・パッチ適用およびプロビジョニングを使用してOracle Databaseをアップグレードする手順

  1. フリート・パッチ適用およびプロビジョニング・サーバーから、データベース上のソースと宛先に応じて、次のいずれかのコマンドを実行します。
    1. フリート・パッチ適用およびプロビジョニングによって管理されるOracleホームをアップグレードする場合で、ソースおよび宛先データベースの作業用コピーが存在する場合は、次のコマンドを実行します。
      $ rhpctl upgrade database -dbname test_database -sourcewc db112 -destwc db122
  {authentication_option}

      test_databaseは、アップグレードされるデータベースの名前です。

      db112は事前アップグレード・データベースのソース作業用コピーです。

      db122は、アップグレードされたOracle Databaseソフトウェアの作業用コピーです。

    2. 管理対象外のOracleホームにアップグレードするには、次のコマンドを実行します(Oracleホームはフリート・パッチ適用およびプロビジョニングによって管理されないため、ソース作業用コピーは存在しません)。
      $ rhpctl move database -sourcehome /u01/app/orabase/product/11.2.0/dbhome_1
  -destwc db122 -targetnode node1 {authentication_option}

      /u01/app/orabase/product/11.2.0/dbhome_1はアップグレードされるデータベースのパスです。

      db122は、アップグレードされたOracle Databaseソフトウェアの作業用コピーです。

      targetnodeでは、アップグレード対象のデータベースが実行されているノードを指定します(ソースOracle Databaseは11.2.0.4クラスタ上にあるため)。

アップグレードされたデータベースは、フリート・パッチ適用およびプロビジョニングによって管理されます。フリート・パッチ適用およびプロビジョニングを使用して、データベースが最新レベルにパッチ適用されていることを確認できます。

注意:

アップグレード中にエラーが発生した場合は、プロシージャが停止し、エラーを修正できます。エラーを修正したら、最後に停止した場所からアップグレード操作を再開できます。

ビデオを見る

関連トピック

クラスタへのノード追加とノードに対するOracle RACデータベースのスケーリング

フリート・パッチ適用およびプロビジョニングを使用してノードを追加し、Oracle RACデータベースを新しいノードに拡張することで、ノードを2ノード・クラスタに追加できます。

始める前に

この手順では、Oracle Grid Infrastructure 12c リリース2 (12.2.0.1)がクラスタ上で実行されています。作業用コピーGI_HOME_12202_WCPYは、このクラスタ上のアクティブなGridホームです。

Oracle RACデータベース・ホームは、作業用コピーDB_HOME_12202_WCPYで実行されます。

『Oracle Grid Infrastructureインストレーション・ガイド』に記載されているように、ストレージ、ネットワークおよびオペレーティング・システムの要件が新規ノード用に構成されていることを確認してください。

手順

  1. フリート・パッチ適用およびプロビジョニング・サーバーから、次のコマンドを実行して既存のOracle Grid Infrastructure作業用コピーにノードを追加します。
    rhpctl addnode gihome -workingcopy GI_HOME_12202_WCPY -newnodes n3:n3-vip {authentication_option}
    このコマンドは、node3を追加することによってクラスタを拡張します。
  2. 新しいノード上の管理者管理のOracle RACデータベースにインスタンスを追加します。
    rhpctl addnode database -workingcopy DB_HOME_12202_WCPY -dbname db321 -node n3 {authentication_option}
    このコマンドを実行すると、node3のデータベース・ホームが拡張され、このノード上にデータベースdb321が作成されます。

ビデオを見る

関連トピック

フリート・パッチ適用およびプロビジョニング用のゴールド・イメージの追加

ソフトウェア・ホームのゴールド・イメージを作成し、それらをフリート・パッチ適用およびプロビジョニング・サーバーに格納します(後でOracleホームのプロビジョニングに使用します)。

始める前に

ゴールド・イメージの作成に使用されるOracleホームは、フリート・パッチ適用およびプロビジョニング・サーバー、フリート・パッチ適用およびプロビジョニング・クライアント、またはフリート・パッチ適用およびプロビジョニング・サーバーが通信できる任意のターゲット・マシンに配置できます。

手順

Oracleホームのゴールド・イメージを次のいずれかの方法で作成し、それらをフリート・パッチ適用およびプロビジョニング・サーバーに格納します。

  1. フリート・パッチ適用およびプロビジョニング・サーバー上のインストール済Oracleホームから､イメージをインポートします。
    rhpctl import image -image db12201 -path /share/software/122/dbhome -imagetype ORACLEDBSOFTWARE

    imagetype Oracle Database 12cリリース2ソフトウェアのゴールド・イメージが作成され、フリート・パッチ適用およびプロビジョニング・サーバーに格納されます。

    -imagetypeをORACLEGISOFTWARE、ORACLEGGSOFTWAREまたはSOFTWAREとして指定することで、Oracle Grid Infrastructureやその他のソフトウェアのゴールド・イメージを作成することもできます。

  2. フリート・パッチ適用およびプロビジョニング・クライアントから次のコマンドを実行して、OracleホームにインストールされたOracleホームからイメージをインポートします。
    rhpctl import image -image db12201 -path /u01/app/dbusr/product/12.2.0/

    このコマンドを実行すると、指定されたパスにインストールされているローカルOracleホームに基づいて、イメージdb12201が作成され、追加されます。

注意:

イメージをソフトウェア・ホームとして直接使用することはできません。イメージを使用してソフトウェア・ホームの作業用コピーを作成してください。

Webサーバーをデプロイするためのユーザー・アクションの作成

フリート・パッチ適用およびプロビジョニングのユーザー・アクションを使用して、任意のタイプのソフトウェアをインストールし、構成できます。次に示すのは、フリート・パッチ適用およびプロビジョニングを使用してApache Webサーバーのデプロイメントを自動化するための手順です。

フリート・パッチ適用およびプロビジョニングは、すべてのタイプのソフトウェアをデプロイ・管理するためのワークフロー作成をサポートしています。
  1. Apache Webサーバーをインストールするためのスクリプトを作成します。
    1. フリート・パッチ適用およびプロビジョニング・サーバー上で、Apache Webサーバーのインストール・キットをダウンロードし、抽出します。
    2. Apache Webサーバーをインストール、構成、起動するためのスクリプトを作成します。
  2. スクリプトをユーザー・アクションとしてフリート・パッチ適用およびプロビジョニングに登録します。フリート・パッチ適用およびプロビジョニング・サーバーから次のコマンドを実行します。
    rhpctl useraction -useraction apachestart 
-actionscript /user1/useractions/apacheinstall.sh 
-post -optype ADD_WORKINGCOPY -onerror ABORT

    このコマンドにより、指定されたディレクトリに格納されているアクション・スクリプト用のapachestartユーザー・アクションが追加されます。指定されたプロパティに応じて、ADD_WORKINGCOPY操作の後にユーザー・アクションが実行され、エラーが発生した場合には操作が中止されます。

  3. イメージ・タイプを作成し、そのイメージ・タイプにユーザー・アクションを関連付けます。
    rhpctl add imagetype -imagetype apachetype -basetype SOFTWARE 
-useraction "apachestart"

    このコマンドにより、apachetypeという新しいイメージ・タイプが作成されます。これは、ユーザー・アクションapacherstartが関連付けられた、基本イメージ・タイプSOFTWAREのデリバティブです。

  4. イメージ・タイプのゴールド・イメージを作成します。
    rhpctl import image -image apacheinstall -path /user1/apache2219_kit/ 
-imagetype apachetype

    このコマンドでは、先に作成したimagetypeに基づいて、Apache Webサーバー・インストール用のスクリプトを使用したゴールド・イメージapacheinstallが、指定されたパスに作成されます。

    このイメージのプロパティを表示するには、rhpctl query image -image apacheinstallコマンドを実行します。
  5. ゴールド・イメージの作業用コピーをターゲットにデプロイします。
    rhpctl add workingcopy -workingcopy apachecopy -image apacheinstall 
-path /user1/apacheinstallloc -sudouser user1 
-sudopath /usr/local/bin/sudo -node node1 -user user1 
-useractiondata "/user1/apachehome:1080:2.2.19

    フリート・パッチ適用およびプロビジョニングは、ソフトウェアをターゲットにプロビジョニングし、ユーザー・アクションで指定されたスクリプトapachestartを実行します。Apache Webサーバーの構成詳細(ポート番号など)は、useractiondataオプションを使用して指定します。ターゲットがフリート・パッチ適用およびプロビジョニング・クライアントである場合は、sudo資格証明を指定する必要はありません。

フリート・パッチ適用およびプロビジョニングを使用して、他のユーザー・アクションを作成し、ソフトウェア・ホームのインストールおよび構成を自動化できます。