1. Oracle Identity and Access Managementのアップグレード戦略
  2. アウトオブプレース・クローン・アップグレード

4 アウトオブプレース・クローン・アップグレード

アウトオブプレース・クローン・アップグレードとは、新しいハードウェアに既存のシステムのコピーを作成してから、クローンでインプレース・アップグレードを実行することです。

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

アウトオブプレース・クローン・アップグレードに関する考慮事項

この項では、アウトオブプレース・クローン・アップグレードに関する考慮事項を示します:

親トピック: アウトオブプレース・クローン・アップグレード

対称性

クローニングされた環境はソース環境と同一にすることをお薦めします。変更が少ないほど、クローニング・プロセス中に再構成する必要がなくなります。

次のものが必要となります。

  • アプリケーションURL - login.example.comを使用してアプリケーションにアクセスする場合、クローニングされた環境でもlogin.example.comを使用する必要があります。

  • ホスト名 - ホスト名はソースとクローンの両方で同一である必要があります。ベスト・プラクティスとして、物理ホスト名ではなく仮想ホスト名を使用することをお薦めします。たとえば、mhost.example.comを使用するかわりに、OAMHOST1.example.comを使用します。仮想ホスト名を使用している場合は、単純にローカル・ホスト・ファイルでこれらに物理ホスト名の別名を付けます。仮想ホスト名を使用していない場合は、ローカル・ホスト・ファイルでソース物理ホスト名にクローニングされたホスト名の別名を付けることで、同じことを実現できます。

    これには、データベースおよびミドルウェア・ホスト名が含まれます。

    これが望ましい方法であり、クローニング・プロセスを使用して再構成する必要はなくなりますが、必要に応じてホスト名を変更することは可能です。ただし、これによりソリューションが複雑になります。

  • ファイル・システム・パス - ファイル・システム・パスは、ソース・システムとプライマリ・システムの両方で同一である必要があります。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

ロード・バランサ

高可用性構成では、Oracle Identity and Access ManagementはOracle HTTPサーバーの背後に存在し、Oracle Weblogicコンポーネントへのリクエストのルーティングに使用されます。Oracle HTTPサーバーへのアクセスは、ロード・バランサを介して行われます。アウトオブプレース・クローン環境では、既存のロード・バランサを使用することも、別のロード・バランサを使用することもできます。別のロード・バランサを使用している場合は、SSL証明書をコピーする必要があります。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

データベース

この戦略では、ソース・システムから宛先システムにデータベース・オブジェクトをクローニングします。データベースのクローニングには複数の方法があり、それぞれに利点があります。

ノート:

Oracle Identity and Access Management 12cでは、同じデータベース・スキーマ接頭辞を使用するように構成されたOracle Access ManagerおよびOracle Identity Managerはサポートされません。アップグレードする前に、両方の製品が共存し、同じデータベース・スキーマを共有している場合は、まずデータベースを2つの異なる接頭辞とスキーマ・セットに分割する必要があります。

次のオプションを使用して、データベースをクローニングできます:

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

  • 小規模なデータベースに適しています。

  • バージョン間の移動を許可します。たとえば、12.1.0.3から19cです。

  • コンテナ・データベース/プライベート・データベースへの移動を許可します。

  • 完全なコピーです。実行をやり直すには、毎回ターゲットからデータを削除する必要があります。

  • 進行中の同期化はありません。

  • カットオーバー中は、ソース・システムを更新のために凍結する必要があります。

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

  • あらゆるサイズのデータベースに適しています。

  • データベース全体をバックアップします。

  • データベース・バージョンおよびパッチ・レベルは、ソースと宛先の両方で同じである必要があります。

  • データベースのアップグレードは、別のタスクとして実行する必要があります。

  • CDP/PDBの移行は、別の実行として行う必要があります。

  • 進行中の同期化はありません。

  • カットオーバー中は、ソース・システムを更新のために凍結する必要があります。

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

  • あらゆるサイズのデータベースに適しています。

  • データベース全体をバックアップします。

  • データベースのアップグレードは、別のタスクとして実行する必要があります。

  • CDP/PDBの移行は、別の実行として行う必要があります。

  • 進行中の同期。データベースを開いてアップグレードをテストし、再度閉じてデータとソース・システムの同期を保つことができます。

ノート:

要件に基づいてソリューションを選択する必要があります。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

アプリケーション・バイナリのクローニング

ソース・システムと宛先システムには、両方のシステムに同じパッチがインストールされた同一のバイナリ・インストールが必要です。アプリケーション・バイナリのクローニングに使用できるいくつかのメカニズムがあります:

  • バックアップ/リストア - 選択したバックアップおよびリストア・ツールを使用して、ミドルウェア・ホームをソースからターゲット・システムにコピーできます。

  • T2P - ソース環境が11gの場合、Oracle Test to Productionユーティリティ(T2P)を使用して、ミドルウェア・ホームをソースからターゲット・システムにコピーできます。

  • 手動インストール - バイナリ・インストールの内容が確実な場合は、宛先システムで手動インストール/パッチ適用を実行できます。

ノート:

要件に基づいてオプションを選択する必要があります。最初のオプションを選択して、両方のシステムが同一であることを確認することをお薦めします。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

構成情報のクローニング

ソース・システムと宛先システムの構成は同じである必要があります。構成情報のクローニングには、次の2つのメカニズムを使用できます:

  • バックアップ/リストア - 優先バックアップおよびリストア・ツールを使用して、ドメイン/インスタンス構成をソースからターゲット・システムにコピーできます。これにより、正確なコピーが保証され、構成の変更は許可されません(たとえば、ホスト名はそのまま残ります)。

  • T2P - Oracle Test to Production (T2P)ユーティリティを使用して、ソース・システムからターゲット・システムに構成をコピーできます。これはより複雑な方法ですが、ホスト名を変更できます。

要件に基づいてオプションを選択する必要があります。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

異なるドメイン

Oracle Identity and Access Management 12cは、同じドメインで実行されているOracle Access ManagerおよびOracle Identity Managerをサポートしていません。両方の製品が共存するドメインをアップグレードする前に、まずドメインを2つの異なるドメインに分割する必要があります。詳細は、「Oracle Identity Managementアプリケーションの複数のドメインへの分離」を参照してください。

親トピック: アウトオブプレース・クローン・アップグレードに関する考慮事項

Oracle Internet Directoryのアウトオブプレース・クローン・アップグレードの実行

Oracle Internet Directoryのクローン・アップグレードを実行するには:

  1. ソース・ディレクトリを読取り専用モードに設定します。

  2. OIDデータベース・スキーマをホストするデータベースをバックアップします。

  3. Oracle Internetバイナリ・インストールをバックアップします。

  4. Oracle Internet Directoryインスタンス構成をバックアップします。

  5. ODSM/DIPドメイン・ディレクトリをバックアップします(使用している場合)。

  6. バックアップ・ファイルを宛先システムにコピーします。

  7. 宛先システムでデータベースをリストアします。

  8. 宛先システムでバイナリをリストアします。

  9. 宛先システムでOracle Internet Directoryインスタンスをリストアします。

  10. ODSM/DIPドメイン・ディレクトリをリストアします(使用している場合)。

  11. 必要なホスト名を変更します。

  12. Oracle Internet Directoryインスタンスを起動します。

  13. Oracle OUDSM/DIPドメインを起動します。

  14. 社内テストを使用して、OIDが正しく機能していることを検証します。

  15. 目的のバージョンに達するようにインプレース・アップグレードのステップを使用してOIDインストールをアップグレードします。

親トピック: アウトオブプレース・クローン・アップグレード

Oracle Unified Directoryのアウトオブプレース・クローン・アップグレードの実行

Oracle Unified Directoryのクローン・アップグレードを実行するには:

  1. ソース・ディレクトリを読取り専用モードに設定します。

  2. Oracle Unified Directoryバイナリ・インストールをバックアップします。

  3. Oracle Unified Directoryインスタンス構成をバックアップします。

  4. ODSM/DIPドメイン・ディレクトリをバックアップします(使用している場合)。

  5. バックアップ・ファイルを宛先システムにコピーします。

  6. 宛先システムでバイナリをリストアします。

  7. 宛先システムでOracle Unified Directoryインスタンスをリストアします。

  8. ODSM/DIPドメイン・ディレクトリをリストアします(使用している場合)。

  9. 必要なホスト名を変更します。

  10. Oracle Unified Directoryインスタンスを起動します。

  11. Oracle OUDSM/DIPドメインを起動します。

  12. 社内テストを使用してOUDが正しく機能していることを検証します。

  13. 目的のバージョンに達するように、インプレース・アップグレードのステップを使用してOUDインストールをアップグレードします。

親トピック: アウトオブプレース・クローン・アップグレード

Oracle Access Managerのアウトオブプレース・クローン・アップグレードの実行

Oracle Access Managerのクローン・アップグレードを実行するには:

  1. アップグレード前の評価を実行して、非推奨の製品が使用されていないこと、またはその代替製品が配置されていることを確認します。

  2. ソース・システムを読取り専用モードに設定します。

  3. OAMデータベース・スキーマをホストしているデータベースをバックアップします。

  4. Oracle Access Managerバイナリ・インストールをバックアップします。

  5. Oracle Access Managerインスタンス構成をバックアップします。

  6. Oracle Access Managerドメイン・ディレクトリをバックアップします。

  7. バックアップ・ファイルを宛先システムにコピーします。

  8. 宛先システムでバイナリをリストアします。

  9. OAMデータベース・スキーマをホストしているデータベースをリストアします。

  10. Oracle Access Managerドメイン・ディレクトリをリストアします。

  11. 必要に応じてホスト名を変更します。これは、T2Pを使用して実行できます。

  12. Oracle Access Managerドメインを起動します。

  13. 次のような社内テストを使用して、OAMが正しく機能していることを検証します:

    • WebLogicコンソールで外部ディレクトリ・ユーザーを表示できることを確認します。

    • 外部ディレクトリ・ユーザーを使用してコンソールにログインできることを確認します。

    • AccessManagerテスト・ツールの使用。

  14. 目的のバージョンに達するように、インプレース・アップグレードのステップを使用してOAMインストールをアップグレードします。

ノート:

確実に新しいディレクトリを使用しているようにするには、誤ってアクセスしないように、既存のディレクトリを一時的に停止します。

手順は、アップグレードするリリースの『Oracle Access Managerのアップグレード』を参照してください。

親トピック: アウトオブプレース・クローン・アップグレード

Oracle Identity Managerのアウトオブプレース・クローン・アップグレードの実行

Oracle Identity Managerのクローン・アップグレードを実行するには:

  1. アップグレード前の評価を実行します。

  2. ソース・システムを読取り専用モードに設定します。

  3. OIMデータベース・スキーマをホストしているデータベースをバックアップします。

  4. Oracle Identity Managerバイナリ・インストールをバックアップします。

  5. Oracle Identity Manager構成をバックアップします。

  6. Oracle Identity Managerドメイン・ディレクトリをバックアップします。

  7. バックアップ・ファイルを宛先システムにコピーします。

  8. 宛先システムでバイナリをリストアします。

  9. データベースを宛先システムにリストアします。

  10. Oracle Identity Managerドメイン・ディレクトリをリストアします。

  11. T2PまたはOIMホスト変更ユーティリティを使用し、必要に応じてホスト名を変更します。

  12. Oracle Identity Managerドメインを起動します。

  13. 次のような社内テストを使用して、OIMが正しく機能していることを検証します:

    • OIMコンソールで外部ディレクトリ・ユーザーを表示できることを確認します。

    • リコンシリエーション・ジョブを実行します。

    • OIMでユーザーまたはロールを作成し、それがLDAPディレクトリに作成されることを確認します。

    • 従業員の終了日をマークし、OIMセッションを確認します(OIMを使用している場合)。

    • コネクタがまだ機能しているかどうかを確認します。

  14. 目的のバージョンに達するように、インプレース・アップグレードのステップを使用してOIMインストールをアップグレードします。

  15. Oracle Identity Manager 11gから12cに移行する場合、ディレクトリ・インタフェースをLDAPSYNCからコネクタに移行することをお薦めします。

  16. SOAコンポジットをアップグレードします。

  17. OIM Design Consoleをアップグレードします。

  18. 外部BI PublisherおよびOIMレポートをインストールします。

  19. ユーザー・インタフェースに対するアプリケーション・モジュールをチューニングします。

手順は、アップグレードするリリースの『Oracle Identity Managerのアップグレード』を参照してください。

親トピック: アウトオブプレース・クローン・アップグレード

Oracle HTTP Serverのアウトオブプレース・クローン・アップグレードの実行

Oracle HTTP Serverのクローン・アップグレードを実行するには:

  1. Oracle HTTP Serverバイナリ・インストールをバックアップします。

  2. Oracle HTTP Serverインスタンス構成をバックアップします。

  3. バックアップ・ファイルを宛先システムにコピーします。

  4. 宛先システムでバイナリをリストアします。

  5. 宛先システムでOracle HTTP Serverインスタンスをリストアします。

  6. 必要なホスト名を変更します。

  7. Oracle HTTP Serverインスタンスを起動します。

  8. 保護されたリソースへのアクセスを含め、社内テストを使用してOHSが正しく機能していることを検証します。

  9. 目的のバージョンに達するように、インプレース・アップグレードのステップを使用してOracle HTTP Serverインストールをアップグレードします。

親トピック: アウトオブプレース・クローン・アップグレード