5 Oracle Access Managerマルチデータ・センター環境のアップグレード
マルチデータ・センター(MDC)でデプロイされたOracle Access Managerを11gリリース2 (11.1.2.3.0)から12c (12.2.1.3.0)にアップグレードできます。
- レプリケーションの停止
- 一方のデプロイメントへのすべてのトラフィックの転送
- 他方のデプロイメントのアップグレード
- 新しくアップグレードしたデプロイメントへのトラフィックの転送
- 残りのデプロイメントのアップグレード
- レプリケーションの再確立
ノート:
Oracle Access Manager MDC環境を12c (12.2.1.3.0)にアップグレードするには、すべてのデータ・センター(DC)が同じパッチ・セット・レベルであることを確認してください。
12c (12.2.1.3.0)へのアップグレードを計画している場合は、アップグレードする必要があるデータ・センターを停止し、すべてのトラフィックを他のデータ・センターにルーティングすることで、ダウン時間をなくすことを選択できます。1つのデータ・センターでアップグレードが完了した後、それは独立したデータ・センターとして始動および機能できます。その後、アップグレードしたデータ・センターにすべてのトラフィックをリダイレクトできます。MDCシングル・サインオンは、下位互換性フラグが有効な場合に11gと12cサーバー間で機能します。これにより、すべてのサーバー(アップグレードされたもの、およびされなかったもの)が、引き続きMDCに含まれるようになります。
ノート:
下位互換性フラグの有効化の詳細は、Oracle Access Manager管理者ガイドの下位互換性フラグの変更に関する項を参照してください。- Oracle Access Managerマルチデータ・センター・トポロジについて
サンプルのOracle Access Managerマルチデータ・センター・トポロジにはマスター・データ・センターとクローン・データ・センターの2つのデータ・センターが含まれています。 - Oracle Access Manager MDC設定のアップグレードのためのロードマップ
アップグレード・ロードマップを使用して、Oracle Access Managerマルチデータ・センター設定を12c (12.2.1.3.0)にアップグレードします。 - 既存のMDC環境のバックアップ
アップグレードを開始する前に、既存の環境をバックアップします。 - マスターおよびクローンへの書込み権限の有効化(必要な場合)
アップグレードを開始する前に、マスターとクローンの両方で、システムおよびポリシーの構成に対する変更を可能にする必要があります。 - マスターとクローンとの間のすべてのレプリケーション承諾の無効化および削除
マスターおよびクローン・データ・センター間のすべてのレプリケーション承諾を無効化します。 - マスター・データ・センターへのトラフィックのリダイレクト
ダウン時間が必要なクローン・データ・センターをアップグレードするには、インライン・アップグレード手順を使用します。そのため、すべてのトラフィックはマスター・データ・センターへ再ルーティングされる必要があります。 - クローン・データ・センター上のOracle Access Managerのアップグレード
マスター・データ・センターにトラフィックをリダイレクトした後、クローン・データ・センター上のOracle Access Managerを12c (12.2.1.3.0)にアップグレードします。 - クローン・データ・センターへのトラフィックのリダイレクト
ダウン時間が必要なマスター・データ・センターをアップグレードするには、インライン・アップグレード手順を使用します。そのため、すべてのトラフィックは、クローン・データ・センター(バックアップ・データ・センターまたはセカンダリ・データ・センターとも呼ばれる)に再ルーティングされる必要があります。 - マスター・データ・センター上のOracle Access Managerのアップグレード
クローン・データ・センターにトラフィックをリダイレクトした後、マスター・データ・センター上のOracle Access Managerを12c (12.2.1.3.0)にアップグレードします。 - クローンへのすべての変更の禁止(必要な場合)
すべてのクローン・データ・センターでOracle Access Managerをアップグレードした後は、クローン・データ・センターに対する変更を禁止することをお薦めします。これは、誤って書込むことがないようにするためです。 - アクセス・メタデータの同期
Unified Data Model (UDM)に格納されたOracle Access Managerメタデータをマスターからクローンに同期する必要があります。 - レプリケーション承諾の作成
マスターおよびクローン・データ・センターをアップグレードした後、レプリケーション承諾を再度作成します。 - java.securityファイルの更新
複数のOracle Identity and Access Managementコンポーネント(Oracle Access Manager、Oracle Identity Manager、WebGatesなど)をデプロイしている場合、すべてのコンポーネントを12c (12.2.1.3.0)にアップグレードするまで、この項で説明している変更を行ってjava.securityファイルを更新する必要があります。 - マスターおよびクローン・データ・センターのオンライン化
アップグレードが成功したら、マスターおよびクローン・データ・センターの両方をオンラインにできます。トラフィックは、既存のルーティング・ルールに基づいて両方のデータ・センターにルーティングできます。
Oracle Access Managerマルチデータ・センター・トポロジについて
サンプルのOracle Access Managerマルチデータ・センター・トポロジにはマスター・データ・センターとクローン・データ・センターの2つのデータ・センターが含まれています。
この章内の手順では、この項で説明している参照トポロジと類似したMDC設定でのOracle Access Managerのアップグレード方法を示します。このアップグレード手順を使用して、含まれているデータ・センター数にかかわらず環境をアップグレードできます。
この図には、マスター・データ・センターおよびクローン・データ・センターを示しており、どちらにもAccess Managerのフル・インストールが含まれています。このトポロジでは、GTMはグローバル・ロード・バランサ、LTMはローカル・ロード・バランサ、WGはWebGateを示します。S2S OAPは、Oracle Accessプロトコルです。
Oracle Access Manager MDC設定のアップグレードのためのロードマップ
アップグレード・ロードマップを使用して、Oracle Access Managerマルチデータ・センター設定を12c (12.2.1.3.0)にアップグレードします。
表5-1 Oracle Access Manager MDCアップグレード・ロードマップ
| タスク | 詳細 |
|---|---|
|
Oracle Access Managerマルチデータ・センター・トポロジを確認します。 |
|
|
既存の環境をバックアップします。 |
|
|
マスターおよびクローン・データ・センターへの書込み権限を有効にします(まだ実行していない場合)。 |
|
|
マスター・データ・センターとクローン・データ・センターとの間のすべてのレプリケーション承諾を無効化および削除します。 |
|
|
マスター・データ・センターにトラフィックをリダイレクトします。 |
|
|
クローン・データ・センターでOracle Access Managerをアップグレードします。 |
|
|
クローン・データ・センターにトラフィックをリダイレクトします。 |
|
|
マスター・データ・センターでOracle Access Managerをアップグレードします。 |
|
|
必要な場合は、マスターおよびクローンへのすべての変更を禁止します。 |
|
|
マスター・データ・センターからアクセス・ストア・データをエクスポートし、それをクローン・データ・センターにインポートすることで、アクセスUDMデータを同期します。 |
|
|
もう一度、レプリケーション承諾を作成します。 |
|
|
java.securityファイルをアップグレードします。 |
|
|
マスターおよびクローン・データ・センターをオンラインにします。 |
既存のMDC環境のバックアップ
アップグレードを開始する前に、既存の環境をバックアップします。
-
ORACLE_HOME: Oracleホーム・ディレクトリ。 -
すべてのOAMホスト上のOracle Access Managerドメイン・ホーム・ディレクトリ。
-
次のデータベース・スキーマ:
-
Oracle Access Managerのスキーマ
-
監査スキーマおよびその他の依存スキーマ
-
スキーマをバックアップする方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
マスターおよびクローンへの書込み権限の有効化(必要な場合)
アップグレードを開始する前に、マスターとクローンの両方で、システムおよびポリシーの構成に対する変更を可能にする必要があります。
ORACLE_HOME/common/binディレクトリに移動します。たとえば:
/home/oracle/oam/ORACLE_IDM/common/bin- マスターおよびクローン・データ・センターで次のコマンドを実行します:
setMultiDataCenterWrite(WriteEnableFlag="true")
マスターとクローンとの間のすべてのレプリケーション承諾の無効化および削除
マスターおよびクローン・データ・センター間のすべてのレプリケーション承諾を無効化します。
マスター・データ・センターへのトラフィックのリダイレクト
ダウン時間が必要なクローン・データ・センターをアップグレードするには、インライン・アップグレード手順を使用します。そのため、すべてのトラフィックはマスター・データ・センターへ再ルーティングされる必要があります。
クローン・データ・センター上のOracle Access Managerのアップグレード
マスター・データ・センターにトラフィックをリダイレクトした後、クローン・データ・センター上のOracle Access Managerを12c (12.2.1.3.0)にアップグレードします。
クローン・データ・センターへのトラフィックのリダイレクト
ダウン時間が必要なマスター・データ・センターをアップグレードするには、インライン・アップグレード手順を使用します。そのため、すべてのトラフィックは、クローン・データ・センター(バックアップ・データ・センターまたはセカンダリ・データ・センターとも呼ばれる)に再ルーティングされる必要があります。
マスター・データ・センター上のOracle Access Managerのアップグレード
クローン・データ・センターにトラフィックをリダイレクトした後、マスター・データ・センター上のOracle Access Managerを12c (12.2.1.3.0)にアップグレードします。
クローンへのすべての変更の禁止(必要な場合)
すべてのクローン・データ・センターでOracle Access Managerをアップグレードした後は、クローン・データ・センターに対する変更を禁止することをお薦めします。これは、誤って書込むことがないようにするためです。
ORACLE_HOME/common/binに移動します。- 次のコマンドを実行します。
SetMultiDataCenterWrite(WriteEnableFlag="false")
アクセス・メタデータの同期
Unified Data Model (UDM)に格納されたOracle Access Managerメタデータをマスターからクローンに同期する必要があります。
exportAccessStoreおよびimportAccessStore)を使用して同期できます。これらのコマンドは、すべてのデータ・センターをアップグレードした後、新しいレプリケーション承諾を作成する前に実行する必要があります。これにより、そのポイントまで作成されたUDMアーティファクトがマスター・データ・センターからエクスポートされ、それらがクローン・データ・センターにインポートされます。
UDMメタデータを同期するには、次のステップを実行します。
レプリケーション承諾の作成
マスターおよびクローン・データ・センターをアップグレードした後、レプリケーション承諾を再度作成します。
ノート:
このコマンドを実行する前に、マスターおよびクローン・データ・センターのRESTエンドポイントが稼働中であることを確認します。
curl -u <repluser> -H 'Content-Type: application/json' -X POST 'https://supplier.example.com/oam/services/rest/_replication/setup' -d '{"name":"DC12DC2", "source":"DC1","target":"DC2","documentType":"ENTITY"}'
レプリケーション承諾の作成の詳細は、Oracle Access Managerの管理者ガイドのレプリケーション承諾の作成に関する項を参照してください。
java.securityファイルの更新
複数のOracle Identity and Access Managementコンポーネント(Oracle Access Manager、Oracle Identity Manager、WebGatesなど)をデプロイしている場合、すべてのコンポーネントを12c (12.2.1.3.0)にアップグレードするまで、この項で説明している変更を行ってjava.securityファイルを更新する必要があります。