1 アップグレード戦略について

Oracle Identity and Access Managementデプロイメントは、複数の異なるコンポーネントで構成されています:

• データベース
• ユーザー情報を格納するLDAPディレクトリ
• 認証用のOracle Access Manager
• プロビジョニング用のOracle Identity Governance (正式名称Oracle Identity Manager)
• オプションで、Oracle Access ManagerおよびOracle Identity Governanceへのアクセスを保護するOracle HTTP ServerおよびWebgate

Oracle Internet Directory、Oracle Unified DirectoryおよびOracle Identity and Access Managementのアップグレードには、様々なアップグレード戦略を採用できます。選択する戦略は、主にビジネス・ニーズによって異なります。

ノート:

このガイドでは、様々なアップグレード戦略の概要について説明します。アップグレード・ステップの詳細は、アップグレードするリリースのコンポーネント固有のアップグレード・ガイドを参照してください。

この章の内容は次のとおりです。

• インプレース・アップグレード戦略について
  
• アウトオブプレース・アップグレード戦略について
  
• クローニングによるアウトオブプレース・アップグレード戦略について
  
• 前提
  

インプレース・アップグレード戦略について

インプレース・アップグレードでは、既存のデプロイメントを取得し、それを元の場所でアップグレードできます。

アップグレードを実行する場合、アップグレードが成功するように、各ステージでできるだけ少ない変更を行う必要があります。

たとえば、Oracle Identity and Access Managementのアップグレード、ディレクトリの変更、オペレーティング・システムの更新など、複数のアップグレード・アクティビティを同時に実行することはお薦めしません。

このようなアップグレードを実行する場合は、段階的に実行する必要があります。次のステージに進む前に各ステージを検証する必要があります。この方法の利点は、問題が発生した場所を正確に特定し、問題を修正するか元に戻してから実行を続行できることです。

この項で説明するトピックは、次のとおりです:

• インプレース・アップグレードの実行
  
• インプレース・アップグレードのメリットおよびデメリット
  
• インプレース・アップグレードが推奨される場合
  

インプレース・アップグレードの実行

インプレース・アップグレード・プロセスは、すべての製品で同様です。

インプレース・アップグレードを実行するには:

1. 既存の環境のバックアップを作成します。

2. 新しいバイナリ・インストールを作成します。

3. アップグレード前パッチがある場合は、バイナリに適用します。

4. データベース・オブジェクトをアップグレードします。

5. ドメインを再構成します。

6. カスタマイズを再適用します。

7. 新しいバージョンを使用してコンポーネントを起動します。

8. 新しい環境でバックアップを作成します。

インプレース・アップグレードのメリットおよびデメリット

次の表に、インプレース・アップグレードのメリットおよびデメリットを示します:

表1-1 インプレース・アップグレードのメリットおよびデメリット

メリット	デメリット
既存のハードウェアでアップグレードを実行でき、追加のハードウェアは必要ありません。 高度に自動化され、簡素化されます。 他の戦略と比較して作業が減少します。 履歴データが保持されます。 既存のパスワード、ポリシーおよび質問/回答が保持されます。 データにギャップがないことが保証されます。 DNSやロード・バランサなどの外部リソースの再構成は必要ありません。 アイデンティティ管理機能を使用して、外部依存性および他のシステムを再構成する必要はありません。	停止時間が必要です。 失われる可能性のあるカスタマイズの再適用が必要です。 複数のバージョンからアップグレードする場合は、アップグレードを複数回実行する必要があります。 一部のコンポーネントは、異なるバージョンではうまく連携しない場合があります。 たとえば、OHS 12cは、変更しないとOAM 11gで正常に動作しません。 問題が発生すると、実際の停止時間が計画停止時間より長くなる場合があります。

インプレース・アップグレードが推奨される場合

インプレース・アップグレードには、次のシナリオが適しています:

• 単一のインスタンス・デプロイメント。

• カスタマイズがない、またはほとんどないデプロイメント。

• リソースに制約があるデプロイメント(ハードウェアに制限がある場合)。

• 非統合(緩やかに接続された)環境。

アウトオブプレース・アップグレード戦略について

アウトオブプレース・アップグレードでは、移動先のリリースで別のハードウェアに2番目の環境が作成され、既存のシステムから新しいシステムにデータおよび構成が移行されます。

データを移行し、新しいシステムが動作していることを確認した後、新しいシステムに切り替えて、既存のシステムを廃止します。

この項では、次のトピックについて説明します:

• アウトオブプレース・アップグレードの実行
  
• アウトオブプレース・アップグレードのメリットおよびデメリット
  
• アウトオブプレース・アップグレードが推奨される場合
  

アウトオブプレース・アップグレードの実行

アウトオブプレース・アップグレード・プロセスは、すべての製品で同様です。

アウトオブプレース・アップグレードを実行するには:

1. 新しいハードウェアにOracle Identity Managementのターゲット・バージョンをインストールします。

2. 必要に応じて、コンポーネントを統合して新しいシステムを構成します。

3. 新しい環境にカスタマイズを適用します。

4. 既存のシステムからデータをエクスポートします。

5. 新規システムにデータをロードします。

6. 新しいシステムを確認します。

7. 新しい環境でバックアップを作成します。

8. 新しいシステムにスイッチオーバーします。

アウトオブプレース・アップグレードのメリットおよびデメリット

次の表に、アウトオブプレース・アップグレードのメリットおよびデメリットを示します:

表1-2 アウトオブプレース・アップグレードのメリットおよびデメリット

メリット

デメリット

ダウンタイムが削減されます。 リスクを低減します。 多数のコンポーネントを同時にアップグレードします。 トポロジを変更します。 アーキテクチャを変更します。 例: Oracle RACからExadataへの移行。 必要に応じてデータを消去します。 事前にカスタマイズを作成します。 UIまたはカスタマイズを更新します。 システムを大幅に変更する必要があるお客様に役立ちます。 古いシステムと新しいシステムを並行して実行します。 本番に影響を与えることなく問題を解決します。

追加のハードウェア/リソースが必要です。 新しいシステムと既存のシステムを並行して実行する場合、既存の外部リソースでは、新しいシステムを使用するために構成を変更する必要があります。 例: 一度に1つのシステムのみを指すことができるWebゲートなどのIDMエージェント、または2つの異なるLDAPディレクトリからリコンサイルするOIM。これらのシステムを並行して実行する場合は、カットオーバーまで両方のシステムに並行して手動で詳細を入力する必要があります。 古いシステムと新しいシステムを並行して実行しない場合は、新しい環境を使用するようにDNSやロード・バランサなどの既存のリソースを再構成する必要があります。 新しいシステムを事前に構築してデータを転送する場合は、カットオーバーまで両方のシステムのデータの同期を保つメカニズムが必要です。 データのアンロードまたはロードにかかる時間は、データ量によって大きくなる場合があります。

アウトオブプレース・アップグレードが推奨される場合

アウトオブプレース・アップグレードには、次のシナリオが適しています:

• 多数のカスタマイズがある複雑なインストール。

• 密結合された複雑なHAインストール。

• 古いシステムと新しいシステムを並行して実行する場合。

クローニングによるアウトオブプレース・アップグレード戦略について

クローン環境を介したアップグレードとは、既存のシステムを新しいハードウェア・セットにクローニングし、クローニングされたシステムでインプレース・アップグレードを実行するハイブリッドな方法です。この方法は、本番環境で実行する前に、安全な環境でアップグレードをテストするためにも使用できます。

この項で説明するトピックは、次のとおりです:

• クローン環境を介したアップグレードの実行
  
• クローン環境を介したアップグレードのメリットおよびデメリット
  
• クローン環境を介したアップグレードの代替方法
  

クローン環境を介したアップグレードの実行

既存のデプロイメントのアップグレード中に問題が発生した場合は、アップグレードを開始する前の時点にそのデプロイメントをリストアする必要があります。代替策として、既存の環境のコピーを作成し、そのコピーをアップグレードする方法があります。問題が発生した場合は、既存の環境をフォールバックとして使用します。

• ホスト名
  
• データベースのクローニング
  
• バイナリのクローニング
  
• 構成のクローニング
  
• ドメインのアップグレード
  

ホスト名

クローニングの最も簡単な方法は、デプロイメント自体を変更しないことです。これを実現する最も簡単な方法は、クローニング・プロセス中にホスト名とサイトURLが変更されないようにすることです。このプロセスは、Oracleが障害時リカバリに推奨するのと同じ方法に従います。物理ホスト名ではなく仮想ホスト名を使用してソース環境を構成しておくことが理想的です。たとえば、physhost1ではなくoamhost1です。これを行った場合は、クローニング時に仮想ホスト名を物理ホスト名の別名として追加します。ただし、ソース環境が仮想ホスト名を使用するように構成されていない場合でも、ターゲット環境でソース環境の物理ホスト名に別名を付けることで、同じ方法を使用できます。

たとえば、目的は、ソース環境とターゲット環境の両方でoamhost1を解決できるようにすることですが、それぞれが作業している環境に適したIPアドレスに解決されるようにすることです。これを行う場合は、クローンの構成を変更する必要はありません。ホスト名を変更する必要がある場合でも、これは実現できますが、クローニング・プロセスはより複雑になり、クローンを再構成する必要があります。

データベースのクローニング

次の方法を使用して、アプリケーションのホストに使用するデータベースをクローニングできます:

オプション1 - データベースのエクスポートとインポート

データ・ポンプとエクスポート/インポートによるデータの移動を参照してください。

オプション2 - RMANを使用したデータベースの複製

データベースの複製を参照してください。

オプション3 - Dataguardデータベース

『Data Guard概要および管理』を参照してください。

次の表に、前述の3つのオプションのメリットを示します:

表1-3 データベースをクローニングする各方法を使用するメリット

オプション1	オプション2	オプション3
小規模なデータベースに適しています。 バージョン間の移動を許可します。 たとえば、12.1.0.3から19cです。 コンテナ・データベース/プライベート・データベースへの移動を許可します。 完全なコピーです。実行をやり直すには、毎回ターゲットからデータを削除する必要があります。 進行中の同期はありません。 カットオーバー中は、ソース・システムを更新のために凍結する必要があります。	あらゆるサイズのデータベースに適しています。 データベース全体をバックアップします。 データベースのアップグレードは、別のタスクとして実行する必要があります CDB/PDBの移行はリストア後に実行する必要があります。 進行中の同期化はありません。 カットオーバー中は、ソース・システムを更新のために凍結する必要があります。	あらゆるサイズのデータベースに適しています。 データベース全体をバックアップします。 データベースのアップグレードは、別のタスクとして実行する必要があります CDP/PDBの移行は、別の実行として行う必要があります。

バイナリのクローニング

Oracleバイナリは、ソース・システムとターゲット・システムの両方で同一である必要があります。これらは、同じパッチ・レベルで同じ場所にある必要があります。

これを実現するには、次のメソッドを使用できます:

バックアップ/リストア - 優先バックアップ・ツールを使用して、既存のバイナリ・インストールをバックアップし、ターゲット・システムにリストアします。oraInventoryディレクトリを忘れずに含めてください。

T2P - ソース環境が11g環境の場合、Oracle Test to Productionユーティリティを使用して、バイナリを別のホスト・セットにレプリケートできます。詳細は、『Fusion Middleware管理者ガイド』のテスト環境から本番環境への移行に関する項および移行スクリプトの使用に関する項を参照してください。

再インストール - バイナリ・インストールに含まれるすべてのパッチおよびバージョンが確実にわかっている場合は、それらをターゲット・システムに手動でインストールできます。詳細は、インストールするリリースの『Oracle Identity Managementのインストールと構成ガイド』を参照してください。

ノート:

バイナリをローカルにインストールする場合は、ターゲット・システムでも同じことを実行してください。共有記憶域を使用する場合は、冗長コピーを含め、各共有記憶域の場所に一度のみリストアする必要があります。

構成のクローニング

ソース・サイトとターゲット・サイト間でホスト名の同期を維持している場合は、お気に入りのバックアップおよびリストア・ツールを使用してシンプル・バックアップおよびリストアを実行できます。

ソース環境が11gの場合、T2Pユーティリティを使用して構成をクローニングできます。この方法はシンプル・バックアップ/リストアよりも複雑ですが、ホスト名などの一部の値を変更できます。

詳細は、『Fusion Middleware管理者ガイド』のテスト環境から本番環境への移行に関する項および移行スクリプトの使用に関する項を参照してください。

OIMには、ホスト名を手動で変更できるユーティリティもあります。詳細は、ドキュメントID 2621548.1を参照してください。

ドメインのアップグレード

インストールのクローニング後、インプレースの手順を使用してドメインのアップグレードを開始できます。

クローン環境を介したアップグレードのメリットおよびデメリット

次の表に、クローン環境を介したアップグレードのメリットおよびデメリットを示します:

表1-4 クローン環境を介したアップグレードのメリットおよびデメリット

メリット	デメリット
ダウンタイムが削減されます。 リスクを低減します。 多数のコンポーネントを同時にアップグレードします。 履歴データが保持されます。 事前にカスタマイズを再適用します。 別のハードウェアに移行します(オプションで、より新しいOSレベルで移行)。 外部の依存システムを再構成する必要はありません。 インプレース・アップグレードの一環として実際に実行する前に、これをテストの場として使用して、手順を理解し検証します。 テスト環境で使用する場合は、アップグレードの練習に使用できます。 テスト環境で使用する場合、アップグレードの実行にかかる時間について知ることができます。 テスト環境で使用する場合は、予期しないアップグレードの問題を発見して解決策を提供します。	クローン環境を介したアップグレードには、追加のハードウェアおよびリソースが必要です。 新しいシステムでは、同じホスト名およびロード・バランサの仮想ホストを使用する必要があります。 名前が同じであるため(仮想名を使用していないかぎり)、両方のシステムをサイド・バイ・サイドで実行することはできません 新しいシステムが使用可能になったときに、そのシステムを指すように外部リソース(DNS/ロード・バランサ)を再構成する必要があります。 新しいシステムを事前に構築してデータを転送する場合は、カットオーバーまで両方のシステムのデータの同期を保つメカニズムが必要です。 ノート: 複数のコンポーネントを一度にアップグレードする必要があり、既成のフォールバックがある場合にのみ、クローン環境を介してアップグレードすることをお薦めします。

クローン環境を介したアップグレードの代替方法

クローン環境を介してアップグレードするかわりに、次の代替方法を使用できます:

• 障害回復(DR)システムがある場合は、クローンの代わりにDRシステムをアップグレードできます。
• Oracle Unified Directory (OUD)を使用している場合、Oracle Unified Directoryレプリケーションを使用して既存のサイトのOracle Unified Directoryインスタンスのレプリカを作成してから、レプリカをアップグレードできます。
• Oracle Internet Directory (OID)を使用している場合、OIDレプリケーションを使用して既存のOracle Internet Directoryのレプリカを作成してから、レプリカをアップグレードできます。

  ノート:

  OIGおよびOIDの使用時にこのメカニズムに従う場合は、使用する前に新しいシステムで完全リコンシリエーションを実行する必要があります。

• Oracle Access Managerを使用している場合は、Oracle Access Managerの2番目のデプロイメントを作成し、Oracle Access Managerマルチデータ・センター・テクノロジを使用して最初のデプロイメントと同期してから、2番目のサイトをアップグレードできます。

前提

採用するアップグレード戦略に関係なく、次の前提が適用されます:

• 各コンポーネント・ディレクトリ、OAM、OIGおよびWeb層には、専用のバイナリがあります。これにより、各製品を個別にアップグレードできます。
• WebLogicドメイン(OAM、OIG、ODSM、Adaptive Access Managerなど)を必要とする各コンポーネントには、専用のドメインがあります。たとえば、Oracle Access ManagerとOracle Identity Governanceは異なるドメインにあります。これにより、各製品を個別にアップグレードできます。

  ノート:

  複数のコンポーネントをアップグレードする場合は、まずOracle Internet Directory、Oracle Access Managerをアップグレードし、Oracle Identity Governanceをアップグレードしてから再構成を実行する必要があります。