ヘッダーをスキップ
Oracle Access Managerアップグレード・ガイド
10g（10.1.4.2.0）
E05837-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

1 Oracle Access Managerのアップグレードおよび計画の概要

この章では、アップグレードのメソッドとタスク、およびアップグレード前に実行する必要がある計画の概要について説明します。オラクル社では2つのアップグレード方法を提供しており、ユーザーのニーズに最適な方法を選択できます。特に明記されていない場合、記載情報はどちらのメソッドにも同様に適用されます。内容は次のとおりです。


注意:

このマニュアルでは、基本的に新しい製品名およびコンポーネント名を使用します。たとえば、Oracle Access Managerは以前のOblix NetPointまたはOracle COREidです。詳細は、「Oracle Access Managerの新機能」を参照してください。

1.1 アップグレードおよびアップグレード方法の概要

最新リリースでは、大幅な機能拡張とともに以前のリリースとの厳密な互換性が実現されています。たとえば、メジャー・リリースのたびに新機能が搭載される他、新しいプラットフォームがサポートされ、場合によってはスキーマ、データ、パラメータまたはメッセージ・ファイルが変更されます。

アップグレードという用語は、以前の製品リリース（パッチの適用の有無は問わない）の上に最新のメジャー・リリースの製品をインストールするプロセスを意味します。

既存のデータと構成は新しいリリースでも使用可能です。たとえば、Oracle Access Manager 6.1.1をインストール済で、新規のオブジェクト・クラスおよびパネルの追加、担当者への管理権限の割当てまたは委任、ワークフローの作成、ポリシー・ドメインでのリソースの保護、認証スキームおよび認可ルールの構成、製品の外観や動作のカスタマイズ、メッセージ・ファイルの変更が行われているとします。以前のリリースで行ったこのような作業を、10g（10.1.4.0.1）へのアップグレード後に繰り返す必要はありません。ただし、手動での処理が必要な項目もいくつかあります。自動化プロセスおよび手動タスクの詳細は、第3章を参照してください。

オラクル社では2つのアップグレード方法を提供しており、ユーザーのニーズに最適な方法を選択できます。

1.1.1 インプレース・アップグレード・メソッド

インプレース・アップグレードは、デプロイの以前のコンポーネント・インスタンスをそれぞれアップグレードする際に、Oracle Access Manager 10g（10.1.4.0.1）コンポーネント・インストーラを使用する方法です。コンポーネントごとに、プラットフォーム固有の独立したパッケージが用意されています。インストールとアップグレードのどちらにも同じパッケージが使用されます。具体的には次のとおりです。


Windowsの場合: Oracle_Access_Manager10_1_4_0_1_win32_Component.exe
Solarisの場合: Oracle_Access_Manager10_1_4_0_1_sparc-s2_Component

注意:

リリース10.1.4パッチ・セット1（10.1.4.2.0）は完全なリリースではありません。リリース10.1.4パッチ・セット1（10.1.4.2.0）コンポーネント・インストーラを使用して、インプレース・アップグレード・メソッドでコンポーネントをインストールまたはアップグレードすることはできません。

このマニュアルの第I部の各章には、アップグレードの開始前に注意する必要がある一般情報が記載されています。インプレース・アップグレードの実行に必要な特定のタスクについては、このマニュアルの第II部と第III部を参照してください。

特に明記されていない場合、記載情報は、選択するアップグレード・メソッドを問わず同様に適用されます。具体的には次のとおりです。

  • 第IV部では、手動タスクによるカスタマイズ内容のアップグレード方法を説明します。

  • 第V部では、アップグレードした環境を検証してすべての機能が正常に動作することを確認する方法について説明します。

  • 第VII部では、主要な部分で扱われていない情報を示す付録を提供します。

1.1.2 停止時間ゼロのアップグレード・メソッド

停止時間ゼロのアップグレード・メソッド（アウトオブプレース・アップグレードとも呼ばれる）の詳細は、このマニュアルの第VI部を参照してください。このメソッドの場合、Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）でのみ使用可能なMigrateOAMスクリプトを使用する必要があります。

このマニュアルの第I部の各章には、アップグレードの開始前に注意する必要がある一般情報が記載されています。特に明記されていない場合、記載情報は、選択するアップグレード・メソッドを問わず同様に適用されます。停止時間ゼロのアップグレードを実行する場合、どちらのメソッドにも適用される説明（第VI部以外）を参照してください。具体的には次のとおりです。

  • 第IV部では、手動タスクによる以前のカスタマイズ内容のアップグレード方法を説明します。

  • 第V部では、アップグレードした環境を検証してすべての機能が正常に動作することを確認する方法について説明します。

  • 第VII部では、トラブルシューティングのヒントなど、主要な部分で扱われていない情報を示す付録を提供します。

1.2 一般的なデプロイ・シナリオ

このマニュアルでは、Oracle Access Managerコンポーネントのアップグレードについてのみ説明します。Oracle Application Serverコンポーネントのアップグレードの詳細は、『Oracle Application Serverアップグレードおよび互換性ガイド』を参照してください。

Oracle Access Managerデプロイは、アイデンティティ・システムのみと、アイデンティティ・システムとアクセス・システムの混合デプロイの2種類に分類されます。使用しているデプロイのタイプに応じて、実行が必要なアップグレード・タスクや、これらのタスクを実行する順序が異なります。この項の内容は、インプレース・アップグレードを実行する場合も、停止時間ゼロのアップグレード・メソッドを使用する場合も適用されます。デプロイ・タイプとアップグレードの詳細は、次を参照してください。

1.2.1 アイデンティティ・システムのみのデプロイのアップグレードの概要

図1-1に、アイデンティティ・システムのみの、非常に単純なデプロイを示します。この図には、アイデンティティ・システム・コンポーネントごとに、アップグレードされる情報の種類が示されています。この図から、アイデンティティ・システムのスキーマとデータもアップグレードされることがわかります。

図1-1 アイデンティティ・システムのデプロイの概要

アイデンティティ・システムのみのデプロイの概要
「図1-1 アイデンティティ・システムのデプロイの概要」の説明

Oracle Access Managerのスキーマとアイデンティティ・システムのデータは、ディレクトリ・サーバー内にあります。アイデンティティ・システムのスキーマおよびデータのアップグレードは1回だけ実行され、これにはディレクトリ・サーバー内の情報への書込み権限が必要です。

アイデンティティ・システムのスキーマおよびデータのアップグレード

アイデンティティ・システムのスキーマおよびデータのアップグレードでは、最新リリースの要件を満たすため、次の種類の情報を更新する必要があります。

  • Oracle Access Managerのスキーマ

  • Oracle Access Managerの構成データ

  • Oracle Access Managerのユーザー・データおよびグループ・データとランタイム情報

  • Oracle Access Managerのワークフロー・データ


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

コンポーネントの情報は、各Oracle Access Managerコンポーネントのインストール・ディレクトリにあります。アップグレードされる情報の種類は、コンポーネント・タイプがOracle Access Managerのサーバー・コンポーネントかまたはWebコンポーネントであるかによって異なります。

アイデンティティ・サーバー・コンポーネントのアップグレード

各アイデンティティ・サーバー・コンポーネントのアップグレードにより、次の情報がリリース10g（10.1.4.0.1）に適合するように更新されます。

  • プログラムおよびライブラリ・ファイル（メッセージ・カタログとパラメータ・カタログを含みます）。これらが最新バージョンに置き換えられます。

  • 構成設定およびシステム環境設定（Windowsレジストリなど）。これらが最新のアイデンティティ・サーバー・リリースの要件を満たすように更新されます。

アイデンティティ・システムのWebコンポーネントのアップグレード

WebPassは、アイデンティティ・システムのWebコンポーネントです。各WebPassコンポーネントのアップグレードにより、次の情報がリリース10g（10.1.4.0.1）に適合するように更新されます。

  • プログラムおよびライブラリ・ファイル（メッセージ・カタログとパラメータ・カタログを含みます）。これらが最新バージョンに置き換えられます。

  • WebPass構成設定およびシステム環境設定（Windowsレジストリなど）。これらが最新のWebPassリリースの要件を満たすように更新されます。

  • WebPassプラグインをホストするWebサーバーの構成ファイルおよびフィルタ。これらが最新のWebPassリリースの要件を満たすように更新されます。

図1-2に、アイデンティティ・システムのみのデプロイでインプレース・アップグレード・メソッドを使用する場合に実行する必要があるアップグレード・タスクの順序を示します。

図1-2 アイデンティティ・システムのみのインプレース・アップグレードのタスクおよび順序

アイデンティティ・システムのみのインプレース・アップグレード・タスク
「図1-2 アイデンティティ・システムのみのインプレース・アップグレードのタスクおよび順序」の説明

各タスクの概要は、「インプレース・アップグレードの実行ステージの概要」を参照してください。停止時間ゼロのアップグレード・メソッドとタスクの詳細は、第VI部を参照してください。

1.2.2 アイデンティティ・システムとアクセス・システムの混合デプロイのアップグレードの概要

図1-3に、アイデンティティ・システムとアクセス・システムの両方からなる非常に単純な混合デプロイを示します。この図には、コンポーネントごとに、アップグレードされる情報の種類が示されています。この図から、アイデンティティ・システムとアクセス・システムの両方のスキーマとデータもアップグレードされることがわかります。使用するアップグレード・メソッドがインプレースの場合も停止時間ゼロの場合も、同じタイプの情報がアップグレードされます。

図1-3 アイデンティティ・システムとアクセス・システムの混合デプロイの概要

アイデンティティ・システムとアクセス・システムの混合デプロイの概要
「図1-3 アイデンティティ・システムとアクセス・システムの混合デプロイの概要」の説明

Oracle Access Managerのスキーマ、およびアイデンティティ・システムとアクセス・システムのデータは、ディレクトリ・サーバー内にあります。スキーマおよびデータのアップグレードには次に説明する情報が含まれ、ディレクトリ・サーバー内の情報への書込み権限が必要です。

アイデンティティ・システムのスキーマおよびデータのアップグレード

アイデンティティ・システムとアクセス・システムの混合デプロイの場合も、アイデンティティ・システムのスキーマおよびデータのアップグレードでは、最新リリースの要件を満たすため、次の種類の情報を更新する必要があります。

  • Oracle Access Managerのスキーマ

  • Oracle Access Managerの構成データ

  • Oracle Access Managerのユーザー・データおよびグループ・データとランタイム情報

  • Oracle Access Managerのワークフロー・データ

アクセス・システムのスキーマおよびデータのアップグレード

アクセス・システムのスキーマおよびデータのアップグレードでは、最新リリースの要件を満たすため、次の種類の情報を更新する必要があります。

  • Oracle Access Managerのポリシー・データ

  • アクセス・システムによってのみ使用されるディレクトリ・インスタンスを構成していないかぎり、通常、アクセス・システムには追加のスキーマ更新は必要ありません。

コンポーネントの情報は、各Oracle Access Managerコンポーネントのインストール・ディレクトリにあります。アップグレードされる情報の種類は、コンポーネント・タイプがOracle Access Managerのサーバー・コンポーネントかまたはWebコンポーネントであるかによって異なります。次に例を示します。

アイデンティティ・サーバーおよびアクセス・サーバーのアップグレード

各アイデンティティ・サーバーおよびアクセス・サーバー・コンポーネントのアップグレードにより、次の情報がリリース10g（10.1.4.0.1）に適合するように更新されます。

  • プログラムおよびライブラリ・ファイル（メッセージ・カタログとパラメータ・カタログを含みます）。これらが最新バージョンに置き換えられます。

  • 構成設定およびシステム環境設定（Windowsレジストリなど）。これらが最新のアイデンティティ・サーバー・リリースの要件を満たすように更新されます。

ポリシー・マネージャ、WebPassおよびWebGateのアップグレード

各Oracle Access Manager Webコンポーネントのアップグレード（ポリシー・マネージャ、WebPassおよびWebGate）により、次の情報がリリース10g（10.1.4.0.1）に適合するように更新されます。

  • プログラムおよびライブラリ・ファイル（メッセージ・カタログとパラメータ・カタログを含みます）。これらが最新バージョンに置き換えられます。

  • 構成設定およびシステム環境設定（Windowsレジストリなど）。これらが最新のWebPassリリースの要件を満たすように更新されます。

  • Webコンポーネント・プラグインをホストするWebサーバーの構成ファイルおよびフィルタ。これらが最新リリースの要件を満たすように更新されます。

WebPassは、各ポリシー・マネージャでも同じディレクトリ・レベルで、同じWebサーバー・インスタンス上にインストールする必要があります。

図1-4に、アイデンティティ・システムとアクセス・システムの混合デプロイでインプレース・アップグレード・メソッドを使用する場合に実行する必要があるアップグレード・タスクの順序を示します。

図1-4 アイデンティティ・システムとアクセス・システムの混合デプロイのインプレース・アップグレード・タスク

アイデンティティ・システムとアクセス・システムの混合のインプレース・アップグレード・タスク
「図1-4 アイデンティティ・システムとアクセス・システムの混合デプロイのインプレース・アップグレード・タスク」の説明

詳細は、「インプレース・アップグレード・タスクの概要」を参照してください。停止時間ゼロのアップグレード・メソッドを使用する場合、実行が必要なタスクとその順序は異なります。


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

1.3 インプレース・アップグレード・タスクの概要

この項では、インプレース・アップグレード・メソッドを使用する場合に実行する必要があるタスクの大まかな順序を示します。これは、計画における単なる開始点です。


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

実行するインプレース・アップグレード・タスク全体の順序は、組織が採用したデプロイ方法、つまりアイデンティティ・システムのみのデプロイと、アイデンティティ・システムとアクセス・システムの混合デプロイのどちらを採用したかによって決まります。図1-5に、実行が必要なアップグレード・タスクの概要とその実行順序を示します。追加情報は、「インプレース・アップグレードの実行ステージの概要」を参照してください。

図1-5 インプレース・アップグレード・タスクの概要

標準的なインプレース・アップグレード・タスクの概要
「図1-5 インプレース・アップグレード・タスクの概要」の説明

1.3.1 計画ステージの概要

インプレース・アップグレード・アクティビティを開始する前に、必ずこの章を通読するようにしてください。インプレース・アップグレードでの停止時間の評価の計画については、「インプレース・アップグレード時のシステム停止時間に関する計画の考慮事項」を参照してください。

インプレース・アップグレードを実行するか、停止時間ゼロのアップグレード・メソッドを使用するかを問わず、既存のデプロイに関する詳細を収集して記録しておく必要があります。計画に関する追加情報および詳細は、「インプレース・アップグレードの計画と成果物」を参照してください。既存のデプロイに関する情報の収集に役立つ概要をまとめたページがあります。詳細は、付録Fを参照してください。


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

1.3.2 インプレース・アップグレードの実行ステージの概要

このステージは、図1-5に示されており、詳細は次のとおりです。アップグレードを成功させるには、実行するタスクの順序が重要になります。付録Fに、使用環境でのアップグレード・タスクの進捗状況を追跡する際に役立つ概要をまとめています。


注意:

この項に示すタスクの概要は、実行する必要があるタスクの概略のみを示しており、タスクの実行に必要な詳細は参照先を示しています。停止時間ゼロのタスクの詳細は、「停止時間ゼロのアップグレード・タスクおよび手順」を参照してください。

タスクの概要: インプレース・メソッドを使用するアップグレードの実行に含まれる手順

  1. 計画: インストール環境ごとに詳細な方法を定義する計画ドキュメントを作成します。詳細は、次を参照してください。

  2. スキーマおよびデータのアップグレード: 以前のOracle Access Managerのスキーマおよびデータをアップグレードする準備をします。詳細は、次を参照してください。

  3. 残りのコンポーネントの準備: スキーマおよびデータのインプレース・アップグレード後、その他のコンポーネントをアップグレード用に準備する必要があります。詳細は、第8章を参照してください。

  4. アイデンティティ・システム・コンポーネントのアップグレード: アイデンティティ・システム・コンポーネントのインプレース・アップグレードを実行します。詳細は、第9章を参照してください。次に概略を示します。

  5. アクセス・システム・コンポーネントのアップグレード: アクセス・システム・コンポーネントのインプレース・アップグレードを実行します。詳細は、第10章を参照してください。次に概略を示します。

  6. サード・パーティ製品の統合コネクタのアップグレード: サード・パーティ製品の統合コンポーネント用およびJ2EEアプリケーション・サーバー（使用されている場合）用のOracle Access Managerコネクタをアップグレードします。

  7. 個別にインストールされたSoftware Developer Kitのアップグレード: このアップグレードを実行することにより、古いAPIがアップグレードされます（これらのAPIを使用して開発されたプラグインは互換性を持ち、アップグレード後の環境で正しく動作するようになります）。

  8. カスタマイズのアップグレード: このタスクは、その他のタスクの前に余裕を持って開始できます。また、別の環境で実行できるため、システム停止時間を削減できます。詳細は、次を参照してください。

  9. アップグレードの検証: ここまでの作業が完了した後、システムの動作を確認できます。詳細は、第14章「システム全体のアップグレードの検証」を参照してください。

1.4 インプレース・アップグレードの計画と成果物

インプレース・アップグレード・タスクを開始する前に、ユーザーおよび担当チームが、図1-6に示されたすべての項目と、その後に続くタスクの概要に習熟しておくことをお薦めします。インプレースと停止時間ゼロのどちらでアップグレードを実行する場合も、計画の成果物はほとんど同じですが、停止時間ゼロのアップグレード・メソッドを使用する場合、詳細は「停止時間ゼロのアップグレード計画の立案」を参照してください。

図1-6 インプレース・アップグレード計画の概要

アップグレード計画の概要
「図1-6 インプレース・アップグレード計画の概要」の説明

タスクの概要: インプレース・アップグレードの計画

  1. この章の次の情報を参照し、アップグレード・タスク、考慮事項、計画の成果物、デプロイ・シナリオおよび開始点の概要を把握します。詳細は、次を参照してください。

  2. 第2章を参照し、アップグレードの概念と使用するメソッドおよび計画について深く理解するとともに、廃止されている（正式サポートが終了した）アプリケーションおよびコンポーネントを把握します。

  3. 第3章を参照し、プログラムによるコンポーネントのアップグレード中に発生するイベントの順序、保持されるデータ項目、および手動処理が必要なものを把握します。

  4. 第4章「システム動作と下位互換性」にまとめられた概要を参照し、以前のリリースとOracle Access Manager 10g（10.1.4.0.1）の間の機能上の差異を調べます。


    注意:

    コンポーネントのアップグレード時には、以前のプラグインおよびWebGateとの下位互換性は自動的に保証されます。ただし、システムの動作には以前のリリースとは異なる点があります。

1.4.1 計画の考慮事項

使用環境のアップグレードの計画を開始するに当たって、次の各事項に留意してください。

  • デプロイ・シナリオ: アップグレード・タスクは、組織が採用したデプロイ方法（アイデンティティ・システムのみのデプロイかアイデンティティ・システムとアクセス・システムの混合デプロイか、イントラネットかエクストラネットか、インストールされた環境の数とタイプはどのようなものか）に応じた順序で実行する必要があります。

    たとえば、以前のアイデンティティ・システムのみのリリースが、3種類のLDAP環境（開発用、テスト/デモ用、本番用）があるイントラネット環境にのみデプロイされている場合、アップグレード・プロセスは、最終的に本番環境で実行する前に、より小さな環境で実行および微調整する必要があります。イントラネット・デプロイまたはエクストラネット・デプロイの詳細は、「エクストラネットおよびイントラネットのデプロイに関する計画の考慮事項」を参照してください。

  • 安定性: アップグレード対象の各環境では、安定して動作している、適切にインストールされたリリースが現在稼働している必要があります。つまり、アップグレードを開始する前に、既存の各環境における以前のOracle Access Manager構成が安定していて完全であることを確認する必要があります。

    既存の環境が安定していることを確認するには、確認用のテスト・スクリプトを開発し、アップグレードの前および後で実行することをお薦めします。たとえば、このスクリプトにより、認証、認可およびワークフロー・リクエスト（すべて単一のページ・リクエストによってトリガー）を必要とする単一のページをリクエストすることで、完全なエンドツーエンド・トランザクションを実行します。

  • 管理アクセス: スキーマ（およびその他）のアップグレード操作には、ディレクトリ・サーバーやOracle Access Managerファイルへの、書込み権限を含む管理アクセス権限が必要です。

  • スキーマおよびデータのアップグレード: スキーマおよびデータのアップグレードを実行する上で、以前のマスター・アイデンティティ・システム（以前のCOREidシステム）およびポリシー・マネージャ（以前のAccess Managerコンポーネント）を準備することは、最初の重要なステップです。詳細は、「スキーマおよびデータのインプレース・アップグレード計画」を参照してください。

  • カスタマイズのアップグレード: これは基本的に手動のプロセスです。テストおよび修正は開発環境で実行した上で、その内容を共有または本番環境に再デプロイすることをお薦めします。詳細は、「カスタマイズのアップグレード計画」を参照してください。

1.4.2 スキーマおよびデータのインプレース・アップグレード計画

スキーマおよびデータのアップグレードは、ディレクトリおよびファイルへの書込み権限を含む管理者権限を持つユーザーが実行する必要があります。以前のOracle Access Managerのスキーマおよびデータを10g（10.1.4.0.1）にアップグレードするために実行が必要なタスクの順序は、使用しているデプロイのタイプ（アイデンティティ・システムのみ、またはアイデンティティ・システムとアクセス・システムの両方）によって異なります。

スキーマおよびデータをアップグレードする方法は新しくなっており、その他のコンポーネントのアップグレードを開始する前に、スキーマおよびデータが正しくアップグレードされたかどうかを確認できるように設計されています。これは、元のインストールによってわずかに異なります。

アイデンティティ・システムのみ: アイデンティティ・システムのみ（1つ以上のアイデンティティ・サーバーおよびWebPassインスタンス）がデプロイされている場合、スキーマおよびデータのアップグレードを実行してから、その他のアップグレード・タスクを実行します。詳細は、次の概要を参照してください。

タスクの概要: アイデンティティ・システムのみがインストールされている場合のスキーマおよびデータのインプレース・アップグレード

  1. 第5章の説明に従って、アイデンティティ・システムのディレクトリ・インスタンスとデータを準備およびバックアップします。

  2. 次のコンポーネントの以前のインスタンスを追加し、スキーマおよびデータのアップグレード用のマスター環境を作成します。

    • 元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスのセカンダリ・サーバーとして、以前のリリースの1つのアイデンティティ・サーバー・インスタンス（以前のNetPointまたはCOREidサーバー）。ディレクトリ・サーバー管理者は、スキーマおよびデータをアップグレードする際に、このインスタンスをマスター・アイデンティティ・サーバーとして使用します。

    • 追加したマスター・アイデンティティ・サーバーと通信するための、以前のリリースの1つのWebPass。

      詳細は、「インプレース・メソッドのマスターとして使用するための以前のアイデンティティ・システムの追加」を参照してください。

  3. 追加したマスター・アイデンティティ・システム・コンポーネントをアップグレードし、次のリストの順序に従ってスキーマおよびデータの自動アップグレードを受け入れます。

    • マスター・アイデンティティ・サーバー、スキーマおよびデータのアップグレード（およびディレクトリ索引ファイルのアップロード）

    • マスターWebPassのアップグレード（ここではスキーマまたはデータのアップグレードはなし）

    • アイデンティティ・システムのスキーマおよびデータのアップグレードの検証

      スキーマおよびデータのインプレース・アップグレードの詳細は、第6章を参照してください。

  4. 図1-5「インプレース・アップグレード・タスクの概要」に記載された順序どおり、残りのアイデンティティ・システム・コンポーネント、統合コンポーネント、個別にインストールしたSDKをすべて準備してから、これらをアップグレード（および検証）し、アップグレード元のアイデンティティ・システムのカスタマイズを再デプロイします。

アイデンティティ・システムとアクセス・システムの混合: インストールにアイデンティティ・システムとアクセス・システムの両方が含まれる場合、全体的な手順は次の概要に示したものとは若干異なります。いずれの場合も、ディレクトリ・サーバー管理者は、アイデンティティ・システムとアクセス・システムのスキーマおよびデータをアップグレードする前に追加したマスター環境を使用します。しかし、これ以降は、順序が異なります。

タスクの概要: アイデンティティ・システムとアクセス・システムのスキーマおよびデータのインプレース・アップグレード

  1. 第5章の説明に従って、スキーマおよびデータのインプレース・アップグレードを準備して、アイデンティティ・システムとアクセス・システムのディレクトリ・インスタンスとデータをバックアップします。

  2. 次のコンポーネントの以前のリリースのインスタンスを追加します。

  3. アイデンティティ・システムのスキーマおよびデータのアップグレード: 追加したマスター・コンポーネントをアップグレードし、次のリストの順序に従ってスキーマおよびデータの自動アップグレードを受け入れます。

    • マスター・アイデンティティ・サーバー、スキーマおよびデータのアップグレード（およびディレクトリ索引ファイルのアップロード）

    • マスターWebPassのアップグレード（ここではスキーマまたはデータのアップグレードはなし）

    • アイデンティティ・システムのスキーマおよびデータのアップグレードの検証

      アイデンティティ・システムのスキーマおよびデータのインプレース・アップグレードの詳細は、第6章を参照してください。

  4. アクセス・システムのスキーマおよびデータのアップグレード: 追加したマスター・コンポーネントをアップグレードし、次の順序に従ってアクセス・システムのスキーマおよびデータの自動アップグレードを受け入れます。

    • マスター・ポリシー・マネージャ、およびアクセス・システムのスキーマとポリシー・データのアップグレード、ならびにディレクトリ索引ファイルのアップロード

    • アクセス・システムのスキーマおよびデータのアップグレードの検証

      アクセス・システムのスキーマおよびデータのインプレース・アップグレードの詳細は、第7章を参照してください。

  5. アクセス・システム: 「アクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの作成」の説明に従って、一時ディレクトリ・プロファイルを作成し、後でWebGateをアップグレードできるようにアクセス・サーバーにポリシー・データに対する書込み権限を付与します。

  6. 図1-5「インプレース・アップグレード・タスクの概要」に記載された順序どおり、残りのアイデンティティ・システム・コンポーネント、アクセス・システム・コンポーネント、統合コンポーネント、個別にインストールしたSDKをすべて準備してから、これらをアップグレード（および検証）し、アイデンティティ・システムのカスタマイズ、その後にアクセス・システムのカスタマイズを再デプロイします。

1.4.3 カスタマイズのアップグレード計画

以前のリリースのOracle Access Managerインストールをカスタマイズした構成は、手動で互換性のテストを行い、10g（10.1.4.0.1）に適合するようにアップグレードする必要があります。このようなカスタマイズ構成の例には、IdentityXML、PresentationXMLおよびAccess Manager API（以前のアクセス・サーバーAPIまたは短くAccess API）を使用して作成されたフロントエンドのカスタマイズがあります。また、アイデンティティ・イベントAPI、認証APIおよび認可API（アクセス・ゲートやプラグインを含む）を使用して作成されたバックエンドのカスタマイズもその例です。

以前のカスタマイズのテストやアップグレードは、基本的には手動プロセスのため、その分、開発の時間がかかります。このため、カスタマイズを共有環境（QA、統合または本番など）に簡単に再デプロイできるようにするには、前もって計画することが重要です。


関連項目:

停止時間ゼロのアップグレードを実行している場合は、第VI部を参照してください。

推奨事項: カスタマイズおよびプラグインのアップグレード

  1. その他のアップグレードは余裕を持って開始し、「インプレース・アップグレード時のシステム停止時間に関する計画の考慮事項」に記載のカスタマイズに関する考慮事項を参照してください。

  2. 完全エンドツーエンド・トランザクションを実行するための、アップグレードの前および後に実行する確認用のテスト・スクリプトを開発します。

    たとえば、このスクリプトにより、認証、認可およびワークフロー・リクエスト（すべて単一のページ・リクエストによってトリガー）を必要とする単一のページをリクエストできます。以前のリリースのカスタマイズの動作を確認するテスト・スクリプトを使用すると、これらのカスタマイズが意図したとおりに機能し、アップグレードの前と後で同じ結果を得られるかどうかを確認できます。テスト・スクリプトの結果は、実行対象の各カスタマイズに依存します。

  3. スクリプトのコード、および特定の環境でのカスタマイズ構成方法を説明するために開発した手順をコンパイルおよびテストします。

  4. 既存の環境で、以前のリリースのカスタマイズ（スタイル、アクセス・ゲートまたはプラグインなど）をテストし、意図したとおりに機能するかどうかを確認します。

  5. Oracle Access Managerデプロイ全体への依存性が最小限となる小規模な開発環境（理想的にはサンドボックス・タイプの設定）に、10g（10.1.4.0.1）をインストールします。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

  6. 10g（10.1.4.0.1）サンドボックスで、以前のリリースのカスタマイズをテストし、10g（10.1.4.0.1）の機能とともに動作するようカスタマイズをアップグレードするために必要な手動ステップを実行します。

  7. 「インプレース・アップグレード・タスクの概要」の説明に従って、テストまたは開発環境のOracle Access Managerをアップグレードします。

  8. テストまたは開発環境のアップグレードが成功した後、コンパイルしたバイナリおよびカスタム・コンポーネントを再デプロイし、本番環境をアップグレードできます。

各カスタマイズの詳細は、次を参照してください。

1.4.4 計画の成果物

計画の成果物には、各環境内でアップグレード・タスクを実行する方法を示す詳細な計画を定義および記録するドキュメントが含まれます。各環境に固有のニーズに合せ、サーバー数や停止時間範囲などを考慮に入れるよう、計画およびタスクを微調整することにより、システム停止時間を削減できます。

また、以前のリリースのすべてのコンポーネントとカスタマイズの詳細なインベントリを準備することもお薦めします。各コンポーネントや環境について記録する必要がある詳細を、次に記載します。付録Fに、計画の概要をまとめたページがあります。

タスクの概要: 計画の成果物の作成

  1. 計画ドキュメントの作成: 各環境内でアップグレード・プロセスを実行する方法を示す詳細な計画を定義および記録します。詳細は、次も参照してください。

  2. 以前のデプロイのインベントリの記録: 以前の環境の正確な詳細をまだ記録していない場合、ここで記録します。これには、表1-1に示すように、アイデンティティおよびアクセス・コンポーネント、ディレクトリ・サーバー、Webサーバーおよびアプリケーションを含めます。付録Fに、計画の概要をまとめたページがあります。

    表1-1 以前のデプロイの詳細のインベントリ

    詳細のタイプ 説明

    環境の詳細

    トランスポート・セキュリティ・モード: 簡易、証明書またはオープン

    ルートCAの詳細（証明書モードが使用されている場合）

    NetPointに関するホスト定義タイプのエントリ（/etc/hostなど）

    アイデンティティ・サーバーのインベントリ

    ワークフロー、検索ベースおよびACL

    NetPointで管理される全オブジェクトのオブジェクト定義の詳細（可能な場合）

    監査構成の詳細

    パスワード・ポリシー構成

    アクセス・サーバーのインベントリ

    ポリシー・ドメイン、認証スキーム、リソース定義、ホスト識別子

    監査構成

    ディレクトリ・プロファイル情報

    アップグレード中に影響を受けるアプリケーション層の詳細

    Cookieまたはヘッダー変数を使用してWebGateによって保護された統合（これらに対する影響は最小限に抑える必要があります）。

    APIを使用して作成されたカスタム・アクセス・ゲート統合（より顕著な影響を受ける可能性があります）。

    Oracle Access Manager Identity Portal Insertsを公開するアプリケーション（ポータルなど）。これらを綿密に調べ、アップグレード・プロセス中にワークフローにアクセスできないときに、サービスが一時的に使用できないというページが表示されることを確認します。

    IdentityXMLに依存しているアプリケーションは影響が著しく大きくなります。これは、IdentityXMLサービス全体が使用できなくなる可能性があるためです（読取り専用コールと書込みコールが区別しにくくなるため、アップグレード・プロセス中はアプリケーション全体を無効にするのが最善です）。

    WebGate、WebPassおよびWebサーバーごとの管理層およびプレゼンテーション層の詳細

    Webサーバー・タイプ、バージョン、オペレーティング・システム、WebPassまたはWebGate識別子、およびバイナリの正確なパッチ・バージョン（6.1.1.19または7.0.4.2など）

    Oracle Access Managerの正確なパッチ・バージョン（6.1.1.19または7.0.4.2など）

    WebPassまたはWebGateのインストール・ディレクトリ

    コンポーネントとそれに対応するOracle Access Managerサーバー間の接続情報（サーバーのプライマリ/セカンダリ区分および接続数を含む）

    アクセス・ゲート、WebGate、ポリシー・マネージャ、アプリケーション・サーバー統合の各詳細

    注意: ポリシー・マネージャは、以前はAccess Managerコンポーネントと呼ばれていました。

    HTTP Cookieドメイン、優先ホスト名、キャッシュのタイムアウトおよびサイズ、フェイルオーバーしきい値

    カスタム開発されたIdentityXMLクライアントのインベントリ

    WebGateによって保護されたWebPassまたはWebサーバー・ファームを参照するために使用される仮想IPおよびDNSの別名のインベントリ。これにより、Webサーバー・コンポーネント（WebPassおよびWebGateは計画対象として必須）を段階的にアップグレードする場合、これらの定義を変更できるようになります。

    Oracle Access Managerサーバー層（アイデンティティ・サーバーとアクセス・サーバーごと）

    正確なパッチ・レベル（6.1.1.19や7.0.4.2など）

    アイデンティティ・サーバーまたはアクセス・サーバーのインストール・ディレクトリ

    関連するWebPassまたはWebGateのインストール・ディレクトリ

    サービスのTCPポート番号（ポート6021など）

    ホスト名（DNS）およびアイデンティティ（以前のCOREid）サーバーの識別子

    アクセス・サーバーの場合はアクセス管理フラグのステータス（オンまたはオフ）も記録

    実行したカスタマイズのインベントリ

    アイデンティティ・イベント・プラグインの特定

    アクセス・サーバーの場合はカスタマイズした認証または認可プラグインも記録

    globalparams.xmlや.lstファイルの変更などファイルごとの変更の記録

    PresentationXMLおよびXSLスタイルシートのカスタマイズの記録

    アイデンティティ・サーバー（およびアクセス・サーバー）がファイルとデータベースのどちらを監査するよう構成されているか

    UNIXシステムの場合、アイデンティティ・サーバー（以前のCOREidサーバー）のユーザー名およびグループ・メンバーシップの記録

    ディレクトリ・サーバー層

    ディレクトリ・サーバーの正確なバージョンおよびパッチ・レベル（Sun ONE v5.2 SP2など）

    ディレクトリ・サーバーのDNS名およびポート

    トランスポート・セキュリティ・モード: LDAP、LDAPS、ADSI

    Oracle Access Managerによって使用されるバインディング資格証明

    Oracle Access Managerで使用されるDITおよびスキーマ・オブジェクト

    マスター/レプリカ構成の詳細

    詳細は、「スキーマおよびデータのインプレース・アップグレード計画」を参照してください。

    カスタマイズの評価および計画

    カスタム開発したプラグイン、Access Manager APIクライアント、IdentityXMLクライアント、PresentationXMLカスタマイズ、Portal Inserts、およびカスタマイズしたスタイルがOracle Access Manager 10g（10.1.4.0.1）と互換性があることを確認します。これは基本的に手動の手順です。詳細は、次を参照してください。

1.5 インプレース・アップグレード時のシステム停止時間に関する計画の考慮事項

あらゆる環境において、アップグレード時にシステム停止時間が発生することは避けられません。アップグレード時に直接的または間接的に影響を受ける可能性のある外部の関係者との調整や計画には特別の注意を払うことをお薦めします。


関連項目:

停止時間ゼロのアップグレードの詳細は、第VI部を参照してください。

ほとんどのOracle Access Managerデプロイは、各アプリケーションの基盤となっているため、企業のインフラストラクチャに不可欠な構成要素となっています。たとえば、Oracle Access Managerが従業員ポータルへのアクセスを保護するとともに、新規ユーザーの登録サービスを提供しているとします。アップグレード時には、新規ユーザーは登録できない場合があります。また、ポータルや保護されているアプリケーションへのアクセスが不可能となる時間帯が生じる可能性もあります。これは、エンドユーザーに対して重大な影響を及ぼします。

この項では、使用環境でのアップグレード・プロセスおよび手動アップグレード・タスクに必要な停止時間の長さを確認する上で役に立つ情報を提供します。このプロセスの途中に、Oracle Access Managerによって提供されるサービスが中断される時間帯が生じます。しかし、サービスの停止時間の合計を最小限に抑える方法はあります。たとえば、Oracle Access Managerが開発、テスト/デモおよび本番の3つの環境にデプロイされている場合、アップグレード・タスクを最初に開発環境で試して微調整してから、最後に本番環境で実行します。

推奨事項: 使用環境での各デプロイのアップグレード

  1. 次で説明するように、開発環境でアップグレード・タスク全体を実行します。

  2. 開発環境が正常にアップグレードされ、正しく動作していることを確認できたら、テスト/デモ環境でアップグレード・タスク全体を同じように実行します。

  3. テスト/デモ環境のアップグレードが正常終了し、正しく動作していることを確認できたら、本番環境でアップグレード・タスク全体を実行します。

この方法を採用すると、使用環境でアップグレードを実行するために要する時間を正確に測定し、本番環境でアップグレードを開始する前にすべてのカスタマイズおよびプラグインが正常に動作することを確認できます。また、この方法は、サービスの中断を最小限に抑えながら本番環境でのアップグレードを円滑かつ迅速に実行する上でも役に立ちます。

重要なのは、アップグレード時にOracle Access Manager（以前のOblix NetPointまたはOracle COREid）サービスの可用性に与える影響を小さくできるということです。この方法の目的の1つは、全体的なアップグレード時間を短縮し、サービスに与える影響を最小限に抑えることが可能な方策を探し出すことです。各環境でアップグレード・タスクを実行しながら、タスク全体の効率を大幅に上げるための計画や最適化方法を策定できます。

以前の環境のアップグレードが運用に与える影響を最小限に抑えるために計画は慎重に作成することをお薦めします。サービスを停止せずにアップグレードを実行できる保証はありません。

各環境のアップグレードを計画する場合、Oracle Access Managerに依存するアプリケーションの数と重大性を考慮することが重要です。環境によってはこの依存性が高くなる場合があります。アップグレードによって環境全体に適用される変更プロセスは、特に注意して調整してください。エンドユーザーに対する影響を最小限に抑えるには、アプリケーションの所有者と協力することが必要です。Oracle Access Managerのアップグレードを計画する際には、変更管理プロセス、メンテナンス時間帯のスケジュール、勤務時間外の運用時間帯など、標準手順について十分に検討する必要があります。

Oracle Access Managerのアップグレードの影響を評価する場合、Oracle Access Managerに依存する様々なアプリケーションのインベントリを作成し、これらのアプリケーションをカテゴリ別に分けます。これらのアプリケーションには、アクセス・システムによって保護されるアプリケーションや、アイデンティティ管理機能用にアイデンティティ・システムを利用するアプリケーションがあります。また、基盤のディレクトリ環境に与える影響も評価の対象です。アップグレード・プロセスにはディレクトリ・スキーマのアップグレードが必要であるため、ディレクトリ環境は特に重要です。多くの環境では、ディレクトリ・スキーマのアップグレードは、ディレクトリ管理グループによって処理される、高い権限を必要とする作業です。

様々なアプリケーションのインベントリを作成してカテゴリ別に分ける際、各アプリケーションが停止する可能性のある時間帯を必ず見積ってください。この作業は、エンドユーザーがアプリケーションに求める使用時間を設定する上で役に立ちます。停止する時間帯の見積りは、アプリケーションのタイプ（アクセス・システムとアイデンティティ・システムのどちらに依存しているか）や、アップグレード・タスクの時間の見積りによって異なります。本番環境では、開発およびテスト/デモ環境でアップグレード・タスクや微調整を行った際に得られた経験を基に見積りを作成できます。

詳細は、次を参照してください。

1.5.1 インプレース・アップグレード時の停止時間の最小化

アップグレード・プロセスでは、アイデンティティ管理、認証および認可用としてOracle Access Managerを使用しているエンタープライズ・アプリケーションを一時停止する必要があります。これらのアプリケーションに影響を与えないアップグレード・タスクは少数です。表1-2に、アップグレード・タスク、その影響としての停止時間、および停止時間を最小限に抑えるための計画の考慮事項（該当する場合）を示します。

表1-2 停止時間の最小化

アップグレード・タスク その影響としての停止時間 停止時間を削減する手順

アップグレード計画

なし。

なし。計画について記載された章を参照し、使用環境のインベントリを作成するときに概要の記録を準備します。人為ミスが発生する可能性を減らすには、アップグレード・タスクを実行する際に追跡の概要を使用して進捗状況を追跡します。

計画および追跡の概要の詳細は、付録Fを参照してください。

スキーマおよびデータのアップグレードの準備

なし。

なし。

スキーマおよびデータのアップグレード

すべてのOracle Access Managerサーバーが停止し、Oracle Access Managerのすべてのコンシューマが影響を受けます。

バックアップを作成し、問題発生時のリカバリ手順への備えとします。アップグレード・プロセスを、本番環境で実行する前にステージング環境で検証します。

Oracle Access Managerコンポーネントのアップグレード

すべてのOracle Access Managerサーバーが停止し、Oracle Access Managerのすべてのコンシューマが影響を受けます。

バックアップを作成し、問題発生時のリカバリ手順への備えとします。アップグレード・プロセスを、本番環境で実行する前にステージング環境で検証します。

サード・パーティ製品の統合コネクタのアップグレード

デプロイでコネクタがアップグレードの対象として選択されたサード・パーティ環境のみ。

アップグレードを、本番環境で実行する前にステージング環境で検証します。第4章を参照して、Oracle Access Managerが以前の環境に対する下位互換性を持つかどうかを検討します。下位互換性があれば、停止時間を最小限に抑えることができます。

個別にインストールされたSDKのアップグレード

個別にインストールされたSDKをアップグレードする環境のみが、影響を受けます。

アップグレードを、本番環境で実行する前にステージング環境で検証します。第4章を参照して、Oracle Access Managerが以前の環境に対する下位互換性を持つかどうかを検討します。下位互換性があれば、停止時間を最小限に抑えることができます。

カスタマイズのアップグレード

アイデンティティ・システムおよびアクセス・システムのカスタマイズを使用するデプロイ・サービスが、影響を受けます。

最初にステージング環境でカスタマイズを適用し、問題を解決しておきます。次に、カスタマイズを本番環境で適用します。

アップグレードの検証

なし。

なし。

1.5.2 インプレース・アップグレードの停止時間の評価

多くの場合、アップグレードで最も時間がかかるのは、オフラインで行われる計画プロセスです。計画を慎重に行うと、企業の各環境をアップグレードするために必要となる停止時間の合計を削減する上で効果があります。

アップグレード・タスクで2番目に時間がかかるのは、スキーマおよびデータのアップグレードの準備です。

コンポーネントを実際にアップグレードするために費やされる時間はこれらより短くなります。以前のカスタマイズが10g（10.1.4.0.1）に適合するようにするだけでなく正常に再デプロイされるようにするために必要な手動タスクには、デプロイやカスタマイズの量に応じて、一定の時間を割り当てる必要があります。ただし、カスタマイズは、共有環境の外部で処理でき、システム停止時間には最小限の影響しか及ぼしません。

次に記載する考慮事項は、使用環境におけるアップグレードによる影響と停止時間について理解する上で役に立ちます。追加情報は、「インプレース・アップグレードの停止時間の評価例」を参照してください。

  • この章と第I部の他の章で説明されている、計画および既存環境のインベントリ作成は、停止時間がゼロのアクティビティです。計画を慎重に行うと、実際のアップグレード・タスクにおけるシステム停止時間の削減に効果があります。

  • スキーマおよびデータのアップグレード（「スキーマおよびデータのインプレース・アップグレード計画」と第II部を参照）には、次の作業が含まれ、最も時間がかかります。

    • LDAPディレクトリのインスタンスおよびデータの準備。

    • アップグレード前に行う、すべてのデータ、インストール・ディレクトリ、およびOracle Access Manager情報が含まれるWindowsレジストリ・エントリに対するバックアップ・コピーの作成。

    • 実際のスキーマ・アップグレード中に使用するマスター・システムの準備。

    • 実際のスキーマ・アップグレードの実行。

    • 実際のデータ・アップグレードの実行。これにかかる時間は、ワークフローおよびワークフロー・ステップの数や、アクセス・ポリシー、ドメインおよび保護リソースの数によって決まります。

    • スキーマおよびデータのアップグレードが成功したかどうかの確認。

  • 第III部で説明されている、その他すべてのOracle Access ManagerコンポーネントとWebサーバー構成の準備およびアップグレードには、ほとんどの場合、システム停止時間は必要ありません。

  • 第IV部で説明されている、カスタマイズしたスタイルシート、プラグイン、フォーム・ベース認証、データベース実装への監査出力などの手動処理は、共有環境の外部で実行できます（このため、必要となるシステム停止時間が大幅に削減されます）。

  • 第V部で説明されている、アップグレードが成功したかどうかの確認では、システム停止時間は発生しません。

1.5.3 インプレース・アップグレードの停止時間の評価例

次の見積りに、約100のワークフロー、500のポリシー・ドメイン、2,500のアクセス・ポリシーおよび1,700の保護リソースが含まれる以前のデプロイをアップグレードするにはどれぐらいの時間がかかるかを示します。

アイデンティティ・システム停止時間の評価

アクセス・システム停止時間の評価

したがって、この環境でアイデンティティ・システムとアクセス・システムの両方をアップグレードする場合、システムを停止する必要があるタスクには約11時間かかります。

1.6 エクストラネットおよびイントラネットのデプロイに関する計画の考慮事項

既存の以前のOracle Access Managerデプロイは、エクストラネット（B2B、G2C、B2C）デプロイとイントラネット（B2E、G2E）デプロイの2つの基本カテゴリに分類できます。これらは一般的なカテゴリです。しかし、これらには、デプロイの使用ユーザー数の把握に使用できる関連パターンがあると考えられます。

詳細は、次の項を参照してください。

1.6.1 エクストラネット・デプロイ

エクストラネット・デプロイは、次のようなデプロイです。

  • 比較的大規模なユーザー人口（20,000人以上のユーザー）

  • このユーザー人口が使用するアプリケーションは、比較的少数です（20未満）。

  • 各アプリケーションは、NetPoint（Oracle Access Manager）と統合されており、また通常、ポータルに統合されています。

エクストラネット・デプロイの最も一般的な特徴は、次のとおりです。

  • アクセス・システム・デプロイよりもアイデンティティ・システム・デプロイの方が複雑です。

  • 多数のワークフロー（自己登録、セルフサービス、管理の委任）。通常、アイデンティティ・イベント・プラグイン（カスタマイズ）が組み込まれます。

  • 管理の委任の高度な要件。多くの場合、様々なユーザー・タイプ（少なくとも4レベルの管理ロール/アクセス）が含まれ、また、ACLやグループなどのオブジェクトが使用されています。

  • ユーザー・インタフェースのカスタマイズ（XSLスタイルシート、PresentationXMLおよびIdentityXMLを使用して実現）。これは、過半数の要件が多数のユーザーのアイデンティティ管理に集中していることと、インタフェースを使いやすくすることが最も重要であるためです。実装の大部分は、IdentityXMLをベースに構築されるフロントエンドのユーザー・インタフェースに費やされます。

  • 多くの場合、ロスト・パスワード管理などの機能が構成されます。

  • 比較的小さいフットプリント（たとえば多くの場合、少数のデータ・センターにいくつかのサーバー（層ごとに2〜4台のサーバー）のみが分散されます）、および停止時間に対する非常に低い許容度。これは、多くの場合、Oracle Access Managerを使用するアプリケーションがビジネスに不可欠であるためです。

  • 通常、ディレクトリ環境は、Oracle Access ManagerおよびOracle Access Managerがサポートするアプリケーションに専用とされます。このため、Oracle Access Manager専用であるディレクトリ・サービスは、運用上、アプリケーションよりも少し厳格に管理されます。これに対して、アプリケーション（通常、一般的な業務分野）のユーザーは比較的少数です。

このように複雑な環境では、サービスの中断を最小限に抑えて10g（10.1.4.0.1）にアップグレードするのは容易ではありません。

1.6.2 イントラネット・デプロイ

一般的なイントラネット・デプロイ環境は、次のとおりです。

  • 比較的小規模なユーザー人口（20,000人未満のユーザー）を持つ内部向けのポータル。

  • このユーザー人口が使用するアプリケーションは、比較的多数（20を超える）であり、NetPoint（新名称はOracle Access Manager）と統合されています。

イントラネット・デプロイの最も一般的な特徴は、次のとおりです。

  • アクセス・システムのカスタマイズの大部分は、通常、次のように行われます。

    • ログイン・ページのフロントエンド（つまり、ログイン・フロントエンド）をカスタマイズします。

    • カスタム作成したアクセス・ゲートを使用してカスタマイズします。

    • APIを使用して開発、カスタマイズした認証または認可プラグインを使用して、バックエンドをカスタマイズします。

  • 比較的多数のアプリケーション（20以上）が、認証およびシングル・サインオン（SSO）を主目的として保護されます。アプリケーション・レベルの統合数はかなりの数に上ります。

  • BEA WebLogicおよびIBM WebSphere Application Serverの統合数が多く、これらのサーバーにはOracle Access Managerコネクタが使用されています。

  • アイデンティティ・システムは多くの場合、広範囲にデプロイされないか、管理ユーザー・コミュニティ（ヘルプ・デスク、IT部門またはシステム管理者など）に対してのみデプロイされます。

  • 通常、パスワード管理機能は構成および使用されません。これは、多くの場合、Oracle Access Managerが同じバックエンド・ストアをNOS（AD）として使用し、自己登録ワークフローはまれにしか使用されないためです。

  • これらの環境ではフットプリントが大きくなる傾向があります。特に、Webサーバーとアプリケーション・サーバーの数が多く、WebGateとアクセス・サーバーの比率が10:1であるWebGate/アクセス・ゲート層にはその傾向があります。

  • アクセス・サーバー層では、イントラネット・デプロイは世界中に分散される傾向があり、各場所にデプロイされるサーバーは少数になります。

  • ディレクトリ環境は多くの場合、従業員ディレクトリまたはNOSディレクトリ（AD）であるため、共有されます。したがって、ディレクトリに関連付けられる依存データの数は多くなります（メタディレクトリ、プロビジョニング・ソリューション、NOSログイン、ホワイト・ページなど）。このため、ディレクトリに対する変更や操作の影響は非常に厳密に管理されています。変更管理プロセスでは多くのユーザーを調整する必要があり、使用時間帯を厳密にすることができます。アプリケーションのフロントエンドでは、ディレクトリ環境の場合より、サーバーの可用性に柔軟性がある傾向があります。また、アプリケーションは、業務分野別、地理別またはセキュリティ要件別に「クラスタリング」される傾向があります。このため、影響を分離できます。

1.7 アップグレード・パス

この項では、インプレース・アップグレードの手法を使用しているときに、以前のリリースからOracle Access Manager 10g（10.1.4.0.1）へのアップグレードに使用できるパスについて説明します。使用できるパスは、開始リリース（アップグレードの開始元となるリリース）に応じて次のいずれかになります。

1.7.1 直接アップグレード・パス

以前のリリースのアップグレードに使用できる直接パスは、次のようにいくつかあります。

1.7.1.1 リリース6.1.1からのアップグレード

通常、リリース6.1.1のデプロイは、アーキテクチャの各層にデプロイされるコンポーネント数、およびその他のシステムやアプリケーションの数の点で、大規模です。Oracle Access Manager 6.1.1は、英語のみのリリースです。

アップグレード時には、各コンポーネント・インストーラにより、最初のリリース6.1.1とリリース10.1.4間の各リリースの製品変更が自動的に実装されます。この場合、マルチ言語機能も自動的に有効になります。リリース6.1.1からアップグレードする場合、次の操作を実行できます。

  • Oracle Access Manager 10g（10.1.4.0.1）インストーラでインプレースの手法を使用して、10g（10.1.4.0.1）への直接アップグレードを実行できます。アップグレード後にリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。

  • 停止時間ゼロの手法と、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能なツールを使用して、Oracle Access Manager 10.1.4.2.0に直接アップグレードできます。このアップグレード後にパッチ・セットを適用する必要はありません。コンポーネント・インスタンスはすでにリリース10.1.4.2.0になっています。

すべての環境において、アップグレードを開始する前にいくつかの準備を行う必要があります。詳細は、第5章および第8章を参照してください。リリース6.1.1からの直接アップグレードには、追加の注意事項や条件はありません。


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

1.7.1.2 リリース6.5からのアップグレード

リリース6.5.0では、英語のメッセージが使用可能である他に、フランス語とドイツ語に関するマルチ言語サポートがありました。Oracle Access Managerリリース6.5では、次の操作を実行できます。

  • Oracle Access Manager 10g（10.1.4.0.1）インストーラでインプレースの手法を使用して、10g（10.1.4.0.1）への直接アップグレードを実行できます。アップグレード後にリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。

  • 停止時間ゼロの手法と、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能なツールを使用して、Oracle Access Manager 10.1.4.2.0に直接アップグレードできます。このアップグレード後にパッチ・セットを適用する必要はありません。コンポーネント・インスタンスはすでにリリース10.1.4.2.0になっています。

表1-3は、6.5の各種リリースを説明しています。Oracle Access Managerリリース6.5.xから直接アップグレードする場合、各コンポーネント・インストーラにより、リリース6.5.0と後続のOracle Access Managerリリースとの間にある各リリースの製品変更が自動的に実装されます。

以前のマルチ言語機能を保持するには、コンポーネントのアップグレードに使用する10g（10.1.4.0.1）インストール・パッケージと同じディレクトリに10g（10.1.4.0.1）言語パックをインストールする必要があります。インストールしない場合は、英語のみが使用されます。その他のサポート言語は、アップグレード後、『Oracle Access Managerインストレーション・ガイド』の手順に従ってインストールできます。

表1-3 Oracle Access Managerリリース6.5からのアップグレード・パス

開始元 アップグレード先 注意事項

6.5.0.x。国際リリース（英語、ドイツ語、フランス語）です。

10g（10.1.4.0.1）

10g（10.1.4.2.0）

アップグレードの前に、「リリース6.5.0.x用のパッケージの追加」のアクティビティを実行します。また、「マルチ言語インストールの準備」も参照してください。

6.5.1。英語のみのリリースで、バックエンド・ディレクトリとしてActive Directoryアプリケーション・モード（ADAM）がサポートされています。

10g（10.1.4.0.1）

10g（10.1.4.2.0）

注意事項や特別な要件はありません。このマニュアルの説明に従ってアップグレードします。

6.5.2.x。英語のみのリリースです。

10g（10.1.4.0.1）

10g（10.1.4.2.0）

6.5.2のパッチが適用されたインストールをアップグレードする前に、「リリース6.5.2.xパッチ・バージョン用のパッケージの追加」のアクティビティを実行します。

6.5.3.x。英語のみのWebGateリリースです。

10g（10.1.4.0.1）

10g（10.1.4.2.0）

注意事項はありません。「WebGateのインプレース・アップグレード」の説明に従って、アップグレードします。

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部の説明に従ってアップグレードします。

1.7.1.3 リリース7.xからのアップグレード

リリース7.0.4（Oracle Application Server 10gリリース2（10.1.2）の一部として使用可能だった国際リリース）を除いて、すべての7.xリリースは英語のみです。通常、NetPoint 7.x環境の方が、NetPoint 6.5または6.1.1環境よりも新しくシンプルです。次のように、10g（10.1.4.0.1）にアップグレードしてからパッチ・セットを適用するか、または停止時間ゼロのメソッドを使用できます。

  • Oracle Access Manager 10g（10.1.4.0.1）インストーラでインプレースの手法を使用して、10g（10.1.4.0.1）への直接アップグレードを実行できます。アップグレード後にリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。

  • 停止時間ゼロの手法と、リリース10.1.4パッチ・セット1（10.1.4.2.0）で使用可能なツールを使用して、Oracle Access Manager 10.1.4.2.0に直接アップグレードできます。このアップグレード後にパッチ・セットを適用する必要はありません。コンポーネント・インスタンスはすでにリリース10.1.4.2.0になっています。

表1-4に、リリース7.xの簡単な概要を示します。リリース7.xからの直接アップグレード時には、各コンポーネント・インストーラにより、リリース7.0とOracle Access Manager 10g（10.1.4.0.1）間にあるすべてのリリースの製品変更が自動的に実装され、マルチ言語機能が有効になります。以前のマルチ言語機能を保持（または新規の言語をインストール）するには、10g（10.1.4.0.1）インストール・パッケージと同じディレクトリに10g（10.1.4.0.1）言語パックをインストールします。インストールしない場合は、英語のみが使用されます。

表1-4 シリーズ7.xリリースからのアップグレード・パス

開始元 アップグレード先 注意事項

リリース7.0

10g（10.1.4.0.1）

10g（10.1.4.2.0）

これらがインストールされている場合、言語をアップグレードする言語パックを含める以外の注意事項はありません。

インプレース・アップグレードの場合、スキーマおよびデータのアップグレードの詳細は第II部、コンポーネントのアップグレードの詳細は第III部を参照してください。

停止時間ゼロのアップグレード・メソッドの場合は、第VI部を参照してください。

リリース7.0.1以降には、追加のプラットフォーム証明書とパラメータおよびメッセージ更新が用意されています。これ以降、新しいGIF、XSL、HTML、イメージまたは同様のファイルをパッチ・リリースに含めることができます。

10g（10.1.4.0.1）

10g（10.1.4.2.0）

これらがインストールされている場合、言語をアップグレードする言語パックを含める以外の注意事項はありません。

インプレース・アップグレードの場合、スキーマおよびデータのアップグレードの詳細は第II部、コンポーネントのアップグレードの詳細は第III部を参照してください。

停止時間ゼロのアップグレードの場合は、第VI部を参照してください。

1.7.2 間接アップグレード・パス

6.1.1より前のOracle Access Managerリリースからアップグレードする場合、Oracle Access Manager 10g（10.1.4.0.1）以降への直接アップグレード・パスはありません。この場合、以前のリリースからリリース6.1.1への中間アップグレードが必要です。

  • リリース6.1.1からは、インプレース・アップグレードの手法を使用してOracle Access Manager 10g（10.1.4.0.1）に直接アップグレードできます。スキーマおよびデータのアップグレードの詳細は第II部、コンポーネントのアップグレードの詳細は第III部を参照してください。

  • 停止時間ゼロの手法を使用して、リリース6.1.1からOracle Access Manager 10.1.4.2.0に直接アップグレードすることもできます。


関連項目:

停止時間ゼロのアップグレード・メソッドを使用している場合は、第VI部を参照してください。

表1-5に、中間アップグレードの開始点に関する各種のシナリオと、関連する注意事項を示します。

表1-5 リリース5.xから6.1へのアップグレード・パス

開始元 アップグレード先 注意事項と条件

リリース5.2

リリース6.1

リリース6.1.1

Oracle Access Manager 10g（10.1.4.0.1）

パブリッシャを保持するには、Oracle Access Manager 6.1にのみアップグレードします。

パブリッシャを破棄する場合、6.1.1への中間アップグレードを実行できます。

リリース6.1.1からは、Oracle Access Manager 10g（10.1.4.0.1）に直接アップグレードできます。

中間アップグレードの詳細は、Oracleサポート・サービス（http://www.oracle.com/support/contact.html）に連絡してください。

リリース6.0

リリース6.1

リリース6.1.1

Oracle Access Manager 10g（10.1.4.0.1）

パブリッシャを保持するには、Oracle Access Manager 6.1にのみアップグレードします。

パブリッシャを破棄する場合、6.1.1への中間アップグレードを実行できます。

リリース6.1.1からは、Oracle Access Manager 10g（10.1.4.0.1）に直接アップグレードできます。

中間アップグレードの詳細は、Oracleサポート・サービス（http://www.oracle.com/support/contact.html）に連絡してください。

リリース6.1

リリース6.1

リリース6.1.1

Oracle Access Manager 10g（10.1.4.0.1）

パブリッシャを保持するには、アップグレードはできません。

パブリッシャを破棄する場合、6.1.1への中間アップグレードを実行できます。

リリース6.1.1からは、Oracle Access Manager 10g（10.1.4.0.1）に直接アップグレードできます。

中間アップグレードの詳細は、Oracleサポート・サービス（http://www.oracle.com/support/contact.html）に連絡してください。

以前のリリースからリリース6.1.1への中間アップグレードに関する詳細は、このマニュアルの対象外です。6.1.1より前のリリースからアップグレードを開始する場合は、その前に次のOracleサポート・サービスに連絡してください。

http://www.oracle.com/support/contact.html

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引