| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
リリース10.1.4パッチ・セット1（10.1.4.2.0）には、重要なデプロイに対する停止時間ゼロのアップグレード・メソッドをサポートする新しいツールと更新されたユーティリティが含まれています。これが対象のエンタープライズに適切な方法であることを確認するために、停止時間ゼロのアップグレード・メソッドに関するすべての情報を確認することをお薦めします。この章では、停止時間ゼロのアップグレード・メソッドについて説明します。内容は次のとおりです。
|
注意: インプレース・アップグレードを行う場合は、この章はスキップしてください。 |
停止時間ゼロのアップグレードは、このマニュアルの第II部および第III部で説明されているインプレース・アップグレードの代替方法です。停止時間ゼロのアップグレードは、この章で説明する理由から、アウトオブプレース・アップグレードとも呼ばれます。デプロイのアップグレード時にどちらのメソッドを使用するのが適切であるかを判断する前に、インプレース・アップグレードだけでなく、停止時間ゼロのアップグレードに関する情報もすべて確認することをお薦めします。
停止時間ゼロのアップグレード・メソッドは、元のデプロイや内外の顧客に提供しているサービスをほとんど停止させることなくアップグレードする必要がある場合に、オプションとして使用できます。重要なデプロイの場合、停止時間ゼロのメソッドには次のような特長があります。
アップグレード時の、Oracle Access Managerサービスの停止時間がほとんどなくなります。Oracle Access Managerスキーマのアップグレードが、Oracle Access Managerデータのアップグレードと別々に実行されます。属性とオブジェクト・クラスのアップグレードが別々に実行されます。変更をロールバックし、いつでも開始位置に戻ることができます。
Oracle Access Managerリリース10g（10.1.4.2.0）は、第1章で説明されているようにパッチ・セット・リリースです。Oracle Access Managerリリース10g（10.1.4.2.0）には、停止時間ゼロのアップグレードの実行に必要なツールが用意されています。停止時間ゼロのアップグレード・メソッドは、6.1.1からOracle Access Managerリリース10g（10.1.4.2.0）に直接アップグレードする場合に使用できます。たとえば、次のリリースから直接アップグレードする場合にこのメソッドを使用できます。
アップグレード元リリースが6.1.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）を適用できます。停止時間ゼロのアップグレードは実行しないでください。詳細は、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)を参照してください。
旧リリースからのアップグレード中に、SolarisプラットフォームからLinuxプラットフォームへの切換えを行う場合は、付録Bの指示に従ってください。その後、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の説明に従って、10g（10.1.4.0.1）のコンポーネントにリリース10.1.4パッチ・セット1（10.1.4.2.0）を適用できます。この場合は、停止時間ゼロのアップグレードは実行しないでください。
次の項では、停止時間ゼロのアップグレード・メソッドの詳細が説明されています。
|
注意: 停止時間ゼロのメソッドに関するすべての情報を確認してから、対象のデプロイに適切な方法であるかどうかを判断し、アップグレード・タスクを実行することをお薦めします。 |
停止時間ゼロのアップグレードは、どのようなデプロイ・タイプまたはシナリオでも実行できます。たとえば、開発やテスト領域、または完全な本番デプロイでも実行できます。デプロイ・カテゴリは、エクストラネットまたはインターネットのどちらでもかまいません。デプロイ・シナリオおよびカテゴリの詳細は、第1章および『Oracle Access Managerデプロイメント・ガイド』を参照してください。
まず、小規模の独立したデプロイで停止時間ゼロのアップグレードを実行することをお薦めします。停止時間ゼロのアップグレードを実行し、それにより、その小規模な範囲が予想どおりの結果になっていることを検証した後で、停止時間ゼロのメソッドをさらに大規模なデプロイに使用します。デプロイのサイズや複雑さにかかわらず、実行するタスクは同じです。
停止時間ゼロのアップグレードのタスクおよび処理に要する期間の詳細は、「停止時間ゼロのタスクおよび検証に要する期間」を参照してください。
停止時間ゼロのアップグレード・メソッドは、2つの完全な環境で作業するため、アウトオブプレース・アップグレード・メソッドとも呼ばれます。
この項では、元のデプロイ、およびそれが停止時間ゼロのアップグレード中に果す役割について説明します。停止時間ゼロのメソッドでアップグレードする場合、元のOracle Access Managerインスタンスは変更されません。
停止時間ゼロのアップグレード中、元のインスタンスは、インストールされたコンピュータに存在します。ただし、コンポーネントをアップグレードする前に、ハードウェアやオペレーティング・システム、またはWebサーバーを変更できます。詳細は、「停止時間ゼロのアップグレードのハードウェア要件」を参照してください。
元のインスタンスでは、元の構成およびポリシー・データが使用されます。このデータは、コンポーネントのインストール時に指定したLDAPディレクトリ・サーバーの元のブランチに格納されます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
元のインスタンスは、これから作成およびアップグレードするコピーされたインスタンス（クローン）のソースになります。クローン・システムを作成、アップグレードおよび検証するため、元のインスタンスとデータは変更されません。詳細は、「クローン環境」を参照してください。
クローンをアップグレードし、クローン・システムのアップグレードを検証している間も、元のインスタンスはすべての顧客にサービスを提供します。アップグレードしたクローン環境が予想どおりに稼働していることを確認できた場合にのみ、元のコンポーネント・インスタンスをアップグレードします。
全面的にテストできるよう、アップグレード・プロセスの初期にカスタマイズもアップグレードすることをお薦めします。停止時間ゼロのアップグレードを実行する場合は、カスタマイズをアップグレードして、アップグレード済のクローン環境でテストできます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。
停止時間ゼロのアップグレード・メソッドの中心は、元のデプロイにおける以前のOracle Access Managerインスタンスのコピーです。コピーはクローンと呼ばれます。元のoblixブランチのコピーもあります。この項では、クローンの設定、およびそれが停止時間ゼロのアップグレード中に果す役割について説明します。
停止時間ゼロのアップグレード・メソッドを使用して、元のデプロイに存在する各コンポーネント・インスタンス（WebGateは除く）のクローンを作成します。
クローン・ファイル・システムは、元のファイル・システムのバックアップ・コピーです。後続のタスクで、各クローン・サブディレクトリの名前を変更して、クローン・アップグレードのソースを作成します。ソースはコンポーネントのバックアップ・コピーになり、10.1.4.2.0のツール、ライブラリおよびファイルが含まれるコピー先のアップグレード中は変更されません。元のファイル・システムは、クローンのアップグレード中は変更されません。
Oracle Access Managerコンポーネントの旧リリースの別のインスタンスをインストールして、クローンとして使用できます。たとえば、元のインスタンスがWindowsプラットフォームでIIS Webサーバーを使用して実行されている場合、クローンを別のホスト・コンピュータに配置する必要があります。新しいホストに以前のインスタンスをインストールした後、元のインスタンスから新しくインストールしたクローンにすべてのカスタマイズと構成の変更をコピーする必要があります。既存のコンポーネントとの通信にインスタンスで簡易モードまたは証明書モードを使用する場合には、元のインスタンスから新しくインストールされたインスタンスに\configサブディレクトリをコピーし、すべての証明書を正常な状態に維持する必要があります。
たとえば、サンドボックス・タイプの小規模な分散デプロイがあり、COREidサーバー（現在のアイデンティティ・サーバー）、WebPass、Access Manager（現在のポリシー・マネージャ）、アクセス・サーバーおよびWebGateのそれぞれにインスタンスが1つあるとします。図15-1に、サンプル環境に存在する元のインスタンスとクローン・インスタンスの両方を示します。
図15-1に示されているように、WebGateを除くそれぞれの元のインスタンスにはクローン・コンポーネント・インスタンスがあります。クローンは元のインスタンスと同じコンピュータ・ホストに存在できますが、必要な場合には、別のコンピュータ・ホストに配置することもできます。詳細は、「停止時間ゼロのアップグレードのハードウェア要件」を参照してください。
WebGate: WebGateのアップグレードは延期できるため、WebGateはクローニングしません。アップグレードされたアクセス・サーバーには以前のWebGateやカスタム・プラグインとの下位互換性があるため、WebGateのアップグレードは延期できます。この下位互換性機能は、旧アクセス・サーバーのアップグレード時に自動的に有効化されます。そのため、クローニングされたアクセス・サーバーと連動するように元のWebGateを構成し、WebGateのアップグレードを延期できます。下位互換性の詳細は、第4章を参照してください。
WebGateが1つのみの場合は、そのWebGateのアップグレード中（またはロールバック中）は停止します。停止を避けるため、WebGateを複数用意することをお薦めします。または、アップグレードしたアクセス・サーバーと連動できるため、古いWebGateを残してアップグレードしないことも可能です。
アクセス・サーバー: 各WebGateアップグレードでは、そのWebGate用に構成されているアクセス・サーバーが少なくとも1つは実行されている必要があります。これは、WebGateStatic.lstファイルからシステム・コンソールのWebGateプロファイルへの情報の移行を可能にするために必要です。
SDKおよび統合コネクタ: WebGateのアップグレードの延期に加え、Software Developer Kit（SDK）のアップグレードも延期できます。手動で処理する必要のある項目は、いつでもアップグレードできます。手動タスクの詳細は、第3章を参照してください。
クローンごとに別々のWebサーバー: Webコンポーネントをホスティングしているコンピュータには、WebPassおよびAccess Managerのクローン・インスタンスに対応するために、別々のWebサーバー・インスタンスが必要です。詳細は、「停止時間ゼロのアップグレードのハードウェア要件」を参照してください。
LDAPディレクトリ・サーバー: 図15-1にはLDAPディレクトリも示されています。LDAPディレクトリには、構成およびポリシー・データが格納されている元のブランチだけでなく、以前の元のコンポーネントのインストール時にインストールされたOracle Access Managerスキーマも含まれています。クローンの設定には、元の環境のデータのコピーが使用されます（スキーマのコピーはありません）。
クローンの設定では、同じLDAPディレクトリ・サーバー・インスタンスに新しいブランチを作成し、その新規ブランチに元の構成とポリシー・データのコピーを移入します。元のブランチは変更されません。新しいブランチへの移入後、クローニングされたコンポーネントを新しいブランチを使用するように再構成します。この再構成の後、クローン・コンポーネントは元の環境をレプリケートします。元の環境では、元のブランチと、元のブランチのデータが引続き使用されます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
クローンをアップグレードしたら、アップグレードした環境が、新しいブランチのアップグレード済のスキーマやデータを使用して予想どおりに動作していることを検証します。検証後、元の環境をアップグレードしている間、元のコンポーネントのかわりにアップグレードしたクローンを使用して対応できます。検証タスクの概要は、「停止時間ゼロのアップグレード中の検証」を参照してください。
元のインスタンスは既存のハードウェアに存在します。クローン・インスタンスを作成する際には、元のインスタンスをホスティングしているコンピュータにクローンを配置することをお薦めします。ただし、クローンは、Oracle Access Manager 10g（10.1.4.2.0）の要件を満たすすべてのコンピュータに作成できます。
ハードウェアをアップグレードする場合、またはデプロイ内のオペレーティング・システムやWebサーバーを変更する場合は、停止時間ゼロのアップグレードを開始する前に実行しておくことをお薦めします。既存のシステムを使用するか拡張するかにかかわらず、システムがOracle Access Manager 10g（10.1.4.2.0）でサポートされていることを確認する必要があります。詳細は、「ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる」を参照してください。
|
注意: 既存のデプロイにハードウェアを追加する場合は、アップグレードの開始前に、サポートされているプラットフォームに以前のOracle Access Managerインスタンスをインストールする必要があります。 |
クローン・コンポーネントの識別子およびサービス名は、元のインスタンスとは異なります。そのため、元のアイデンティティ・サーバーまたはアクセス・サーバー・インスタンスと同じコンピュータにIIS Webサーバーがある場合でも、別のコンピュータ・ホストにアイデンティティ・サーバーまたはアクセス・サーバーのクローンを配置する必要はありません。詳細は、「停止時間ゼロのアップグレードのWebサーバー要件」を参照してください。
現在サポートされているUNIXベースのプラットフォームには、LinuxおよびSolarisが含まれます。UNIXと表記されている場合、現在サポートされているUNIXベースのプラットフォームのみを指します。
すべてのシステムの準備ができたら停止時間ゼロのアップグレードを開始できます。
クローニングされたWebPassおよびAccess Managerには、別々のWebサーバー・インスタンスが必要です。クローンのWebサーバー・インスタンスのWebサーバー・タイプおよびリリースは、元のWebコンポーネント・インスタンスで使用されているものと同一である必要があります。たとえば、Apache 2.0.5.2ベースのOracle HTTP Server（OHS）を使用している場合は、クローンにも同じWebサーバーを使用する必要があります。WebGateはクローニングされません。
クローニングされたWebコンポーネントのWebサーバー・インスタンスには、次のガイドラインが適用されます。
単一のWebサーバー・インスタンス用に構成された単一のホスト・コンピュータにWebコンポーネントが1セットしかない場合、クローンに対応するために必要な新しいWebサーバー・インスタンスは1つのみです。
Webコンポーネントが複数のホスト・コンピュータに分散している複雑なデプロイの場合は、クローニングされたWebコンポーネントをホスティングしている各コンピュータに新しいWebサーバー・インスタンスが1つ必要です。
WebPassまたはAccess Managerコンポーネントの複数のペアに複数のWebサーバーが構成されている場合は、クローンにWebサーバー・インスタンスの類似のペアが必要です。
元のWebサーバー・インスタンスを使用するOracle Access Managerに保護された別のアプリケーションがある場合は、クローニングされたWebコンポーネント用に作成するWebサーバー・インスタンスを使用するように、そのアプリケーションもクローニングする必要があります。
Windowsシステムで以前のIIS Webコンポーネントをクローニングする場合、Windowsレジストリはそのクローン用に更新されていません。IIS Webサーバーでは、レジストリのWebコンポーネントのエントリが必要なため、これが原因で問題が発生する可能性があります。詳細は、「ロールバック操作中における元のWindowsレジストリ・エントリの回復」を参照してください。
ホスト・コンピュータには、IIS Webサーバーのインスタンスを複数配置しないことをお薦めします。元のコンポーネントでIIS Webサーバーを使用している場合には、クローンのホスト・コンピュータ名が別になるように、別のホストにクローンを作成することをお薦めします。
アップグレードしたCOREidサーバーおよびWebPassのそれぞれの関連付けに対して、アイデンティティ・システムの設定を実行する必要があります。アップグレードした各Access Managerも設定する必要があります。ただし、Webサーバー・インスタンスは、リリース・レベルが異なるOracle Access ManagerのWebコンポーネントをサポートできません（6.1.1と10.1.4など）。これは特に、UNIXベースのシステムに当てはまります。
クローンのシステムであるか元のシステムであるかによって、アップグレードしたアイデンティティ・システムおよびAccess Managerの設定に影響があります。単一のWebサーバー・インスタンス（WebPass、Access ManagerおよびWebGate）が対応しているすべてのWebコンポーネントは、Webサーバーを再起動する前に、同じリリース・レベルにしておく必要があります。Oracle Access Managerの複数のWebコンポーネントに対応している単一のWebサーバー・インスタンスがある場合には、ホスト・コンピュータの対応している全Webコンポーネントがアップグレードされるまで停止しておく必要があります。
アップグレードしたアイデンティティ・システムまたはAccess Managerは（クローンの設定と元の設定のどちらをアップグレードしているかにかかわらず）、Webサーバー・インスタンスが対応しているOracle Access ManagerのすべてのWebコンポーネントが10g（10.1.4.2.0）にアップグレードされるまで設定できません。
アップグレードしたクローンまたは元のシステムを設定する際には、次の条件が適用されます。
アイデンティティ・システムのみ:
単一のWebサーバー・インスタンスは、複数のWebPassインスタンスに対応できません。
アイデンティティ・システムを設定できるのはWebPassのみをアップグレードした後です。
アイデンティティ・システムおよびアクセス・システムの混合: 単一のWebサーバー・インスタンスが対応するすべてのWebコンポーネントをアップグレードするまで、アイデンティティ・システムおよびAccess Managerの設定を延期する必要があります。
クローン環境では、アイデンティティ・システムおよびアクセス・システムを設定する前に、COREidサーバー、および対応されているWebPassとAccess Managerのインスタンスをアップグレードします。WebGateクローンはありません。元の環境では、対応されているすべてのWebPass、Access ManagerおよびWebGateのインスタンスをアップグレードする必要があります。
WebPassおよびAccess Managerの両方で同じWebサーバー・インスタンスが使用されている場合は、対応されているAccess Managerインスタンスがアップグレードされるまでアイデンティティ・システムの設定を延期します。
WebPass、Access ManagerおよびWebGateで同じWebサーバー・インスタンスが使用されている場合は、対応されているすべてのWebコンポーネントがアップグレードされるまでアイデンティティ・システムの設定を延期します。
Access ManagerとWebGateが同じディレクトリにインストールされている場合は、WebGateがアップグレードされるまでそのAccess Managerの再構成を延期する必要があります。
各ホストで、コンポーネントを適切な順序でアップグレードする必要があります（COREidサーバー、WebPass、Access Manager、アクセス・サーバーおよびWebGateの順序）。同じホストのアクセス・サーバーをアップグレードするまでWebGateをアップグレードしないでください。
各ホストのコンポーネントは特定の順序でアップグレードします。アイデンティティ・システムおよびAccess Managerを設定する前に、環境全体のすべてのWebコンポーネントがアップグレードされるのを待機する必要はありません。
元の環境を停止時間ゼロのアップグレードに向けて準備している間に、次に示す項を確認し、対象の環境に適用可能なタスクを実行するよう指示されます。これらは第5章の項です。
デプロイには、システムの可用性やパフォーマンスを向上させるためにレプリカが採用されている場合があります。アップグレードが完了して、すべての機能が正常に動作していることを検証できるまで、レプリケーションを無効化することをお薦めします。
オブジェクト・クラス・レベルでのチャレンジ/レスポンス・フレーズの構成
アップグレードを開始する前に、チャレンジ属性およびレスポンス属性がオブジェクト・クラス・レベルで構成されていることを確認することをお薦めします。チャレンジ属性およびレスポンス属性が（オブジェクト・クラス・レベルではなく）「従業員」タブ・レベルで構成されている場合、構成データのアップグレードが正しく実行されない可能性があります。
各ディレクトリ・サーバー・プロファイルには、ディレクトリに対する接続情報が含まれます。これには、プロファイル名、適用対象のドメインまたはネームスペース、ディレクトリ・タイプ、および一連の操作要件（読取り、書込み、検索など）が含まれます。構成データまたはポリシー・データがユーザー・データとは異なるディレクトリ・サーバーに格納されている以前のOracle Access Managerインストールの場合は、ネームスペースが一意で、その他のディレクトリ・サーバー・プロファイルのネームスペースと重複しないようにするために、アップグレード前に一意のネームスペースを構成する必要があります。
スキーマおよびデータのアップグレード用のディレクトリ・インスタンスの準備
このタスクには、ディレクトリ・サーバーがサポートされていること、対象のディレクトリ・サーバー・タイプに固有の考慮事項を確認したこと、およびディレクトリ・サーバーの検索サイズ制限パラメータの値が構成ツリー内のエントリ数より大きいことの確認が含まれます。
元の環境にCOREidサーバー・インスタンスとAccess Managerインスタンスを初めてインストールして設定した際に、LDAPディレクトリ・サーバーにOracle Access Managerのスキーマ、および構成データとポリシー・データを追加しました。この項では、停止時間ゼロのメソッドを使用する際の、スキーマおよびデータのアップグレードの影響の概要を説明します。
クローン・システムで使用するために、LDAPディレクトリ・サーバーに新しいブランチを作成し、現在の構成データとポリシー・データのコピーを格納します。
スキーマは、構成データやポリシー・データとは別に、一度にすべてアップグレードされます。詳細は、「スキーマのアップグレードの概要」を参照してください。
新しいブランチのデータは、最初にインストールされたCOREidサーバーのクローンのアップグレード時にアップグレードされます（最初にインストールされたAccess Managerのクローンのアップグレード時にアップグレードされる場合もあります）。元のブランチのデータはアップグレードされず、そのシステムがアップグレードされるまで元のシステムで使用できます。詳細は、「構成データおよびポリシー・データのアップグレードの概要」を参照してください。
ロスト・パスワード管理のチャレンジ属性およびレスポンス属性として構成された複数の値は、ユーザーがアップグレード後に初めてログインする際に移行されます。この移行は、元のインスタンスをアップグレードするまで自動的に停止されます。詳細は、「ユーザー・データの移行およびLPMのチャレンジ属性とレスポンス属性の複数の値」を参照してください。ロスト・パスワード管理機能は、アップグレードされたクローン・システムで使用できます。ただし、ユーザー・データを変更しないかぎり、ロスト・パスワード管理にチャレンジおよびレスポンスを複数使用することはできません。
パラメータ・カタログおよびメッセージ・ファイルは、（クローン・データの場合も元のデータの場合も）個々のコンポーネントとともにアップグレードされます。アップグレード中の処理の詳細は、「停止時間ゼロのアップグレードのツールおよびプロセス」を参照してください。
スキーマのアップグレードもデータのアップグレードも、Lightweight Directory Interchange Format（LDIF）ファイルに依存します。LDIFファイルはASCII形式のファイルで、Lightweight Directory Access Protocol（LDAP）サーバーとのデータの交換や同期に使用できます。各LDAPディレクトリ・サーバーにはLDIFファイルがあります。
各LDIFファイルに含まれるのは、Oracle Access Managerのあるリリースと次のリリースとの変更点のみです。つまり、データのアップグレード手順は、開始リリースから10g（10.1.4.2.0）にいたるまで、各リリースへのアップグレードごとに1回繰り返されます。たとえば、リリース6.1.1からアップグレードする場合、スキーマ（およびデータ）のアップグレードは次のように行われます。
リリース6.1.1からリリース6.5へ
リリース6.5からリリース7.0へ
リリース7.0から10.1.4へ
この項では、停止時間ゼロのアップグレード・メソッドを使用して実行するスキーマのアップグレードの概要を説明します。
Oracle Access Managerのスキーマは、通常、Oracle Access Managerのメジャー・リリースのたびに拡張されます。たとえば、アイデンティティ・サーバーの機能が拡張された場合、アイデンティティ・サーバーは、以前のリリースよりも多くのスキーマ属性とオブジェクト・クラスを参照できるようになります。スキーマのアップグレードは、LDAPディレクトリ・サーバーおよびファイルへの書込み権限を含むディレクトリ・サーバーの管理者権限を持つユーザーが実行する必要があります。
停止時間ゼロのアップグレード・メソッドでは、スキーマのアップグレードはデータのアップグレードとは別に行われます。スキーマのアップグレードは一度にすべて実行されます。コンポーネント（または構成データおよびポリシー・データ）をアップグレードする前に、スキーマのアップグレードが成功したことを確認できます。
スキーマをアップグレードする前に、元のインスタンスで使用されているのと同じLDAPディレクトリ・サーバー・インスタンス内に新しいブランチを作成することをお薦めします。新しいブランチを作成したら、元の構成データおよびポリシー・データのコピーを移入します。クローンの設定にはこの新しいブランチが使用され、元の環境を中断することなく元の環境がミラー化されます。停止時間ゼロのアップグレードでこの処理がどのように行われるかの詳細は、「Mkbranchモードの処理の概要」を参照してください。ディレクトリ・サーバーの新しいブランチには、スキーマのコピーは含まれていません。
新しいブランチに移入し、クローン・インスタンスで新しいブランチを使用するように構成したら、LDAPディレクトリ・サーバーのスキーマをアップグレードできます。アイデンティティ・システムのみがデプロイされている場合、または構成データとポリシー・データが一緒に格納されているアイデンティティ・システムおよびアクセス・システムの混合の場合は、最初にインストールされたCOREidサーバーのクローンで、スキーマをアップグレードするタスクを一度のみ実行します。構成データとポリシー・データが別々に格納されている場合は、アクセス・システムのスキーマもアップグレードする必要があります。停止時間ゼロのアップグレードでこの処理がどのように行われるかの詳細は、「スキーマ・モードの処理の概要」を参照してください。
アップグレードしたスキーマには、最も古いものでリリース6.1.1までの以前のスキーマとの下位互換性機能があります。ただし、Oracle Access Managerには、スキーマのアップグレードをロールバックする自動ツールはありません。ディレクトリ・サーバーの一部のベンダーでは、スキーマのバックアップに使用できるツールが提供されています。スキーマをアップグレードする前にスキーマをバックアップしておけば、元のリリースにロールバックする場合に以前のスキーマを回復できます。詳細は、「停止時間ゼロのアップグレードのバックアップ/リカバリ計画」を参照してください。
|
注意: 停止時間ゼロのアップグレード・ツールでは、スキーマのアップグレードを自動的にロールバックすることはできません。 |
元の設定でもクローンの設定でもアップグレードしたスキーマを使用します。スキーマをアップグレードしたら、すべてが正常に動作していることを確認するために検証タスクを実行することをお薦めします。詳細は、「環境の正常な動作の検証」を参照してください。
スキーマのアップグレードの詳細は、「停止時間ゼロのアップグレード中のスキーマのアップグレード」を参照してください。
この項では、特定のクローン・コンポーネントのアップグレード時に行われる構成データとポリシー・データのアップグレードについて説明します。
第1章で説明されているように、アイデンティティ・システム・データには次のものが含まれます。
アイデンティティ・システムとアクセス・システムの混合では、アクセス・システムのデータにはOracle Access Managerのアクセス・ポリシー・データが含まれます。
元のインスタンスでは、LDAPディレクトリ・サーバーの元のブランチに格納されている構成データおよびポリシー・データのみが使用されます。元のブランチは、元の環境にCOREidサーバーとAccess Managerを最初にインストールした際に設定されています。クローン・コンポーネントでは、LDAPディレクトリ・サーバーの新しいブランチに格納されている構成データおよびポリシー・データのみが使用されます。新しいブランチの構成データとポリシー・データのみがアップグレードされます。LDAPディレクトリ・サーバーの元のブランチは変更されません。
スキーマをアップグレードしたら、クローン・インスタンス、および新しいブランチの構成データとポリシー・データをアップグレードできます。データのアップグレードは次のように実行されます。
アイデンティティ・システムのみがデプロイされている場合、または構成データとポリシー・データが一緒に格納されているアイデンティティ・システムおよびアクセス・システムの混合の場合は、最初にインストールされたCOREidサーバーのクローンのアップグレード時にデータがアップグレードされます。
構成データとポリシー・データが別々のディレクトリ・サーバーに格納されているアイデンティティ・システムおよびアクセス・システムの混合デプロイの場合は、最初にインストールされたAccess Managerのクローンのアップグレード時にアクセス・ポリシー・データがアップグレードされます。
後続のCOREidサーバー（およびAccess Manager）のクローンのアップグレード時には、最初のデータのアップグレードが検出され、データのアップグレード・アクティビティはスキップされます。停止時間ゼロのアップグレードにおけるデータのアップグレードの詳細は、「クローン・モードの処理の概要」を参照してください。
停止時間ゼロのアップグレード・メソッドでは、元のコンポーネントのアップグレード中にはデータはアップグレードされません。元のコンポーネントをアップグレードしたら、それらのコンポーネントで新しいブランチを使用するよう再構成します。
LDAPディレクトリ・サーバーに新しいブランチを作成および移入した後に元の設定に行われた変更は、クローン設定には反映されません。同様に、クローン設定に行われた変更も元の環境には反映されません。構成データおよびポリシー・データに影響を与える元の環境の変更は、一時停止することをお薦めします。停止しない場合は、LDAPディレクトリ・サーバーの新しいブランチに再度移入し、元のインスタンスのアップグレード前にクローンをもう一度アップグレードする必要があります。詳細は、「元のインスタンスのアップグレード前における元のブランチに対する変更内容取得の概要」を参照してください。
検証: スキーマ（およびデータ）のアップグレード後に、十分に検証アクティビティを実行して、クローン環境および元の環境が予想どおりに動作していることを確認することをお薦めします。検証の詳細は、「停止時間ゼロのアップグレード中の検証」を参照してください。
ユーザー・データはアップグレードされません。クローン設定と元の設定の両方で、元の検索ベースが使用されます。
ロスト・パスワード管理（LPM）のチャレンジ属性およびレスポンス属性に構成された複数の値は、アップグレード後にユーザーが初めてログインする際に移行されます。その他に、ユーザーの最初のログイン時に移行されるユーザー・データ属性はありません。
停止時間ゼロのアップグレードを実行する場合は、ロスト・パスワード管理のチャレンジ属性およびレスポンス属性の複数の値を手動で停止する必要はありません。かわりに、クローン・モードでMigrateOAMスクリプトを使用すると、この移行は自動的に停止されます。
LPMのチャレンジ属性およびレスポンス属性の複数の値の移行を、それらの値を手動で有効化するまで停止していても、ロスト・パスワード管理機能は使用できます。
停止時間ゼロのアップグレード・メソッドを使用する場合は、アップグレードしたクローン設定および元の設定を以前のリリースにロールバックする必要がないことを検証した後に、ユーザー・データの移行を手動で再開する必要があります。
ユーザー・データの移行は、停止時間ゼロのタスクの終了時に、元の設定をアップグレードおよび検証した後で最初にログインする際にのみ再開します。アップグレードしたクローン設定をアップグレードおよび検証した後には、ユーザー・データの移行は再開しません。
ロスト・パスワード管理のチャレンジ属性およびレスポンス属性の複数の値の詳細は、「最初のログイン時のユーザー・データの移行」を参照してください。
次に示す概要では、停止時間ゼロのアップグレードの特定の段階で実行する必要がある準備タスクが記載されている項を説明します。これらのタスクは、今すぐに実行する必要はありません。これらの項は紹介の目的でリストされており、実行する順序で説明されます。
トピックの概要: 各フェーズの準備タスクを説明する項
実行を指示される準備タスクの一部は停止時間ゼロのアップグレードに固有のもので、前述のリストの項で詳細に説明されています。その他の準備タスクは、どちらのアップグレード・メソッドにも適用されます。後者の場合には、別の章に記載されている実際の詳細な説明が紹介されます。たとえば、第5章には、最初にインストールされたCOREidサーバーおよびAccess Managerのクローンのアップグレード時に、スキーマおよびデータのアップグレードを準備する手順が記載されています。第8章には、コンポーネントの準備手順が記載されています。
|
注意: 推奨されているすべての準備手順を実行しないと、問題からのリカバリや元のリリースへのロールバックができなくなる可能性があります。 |
元のインストールの準備の概要: 元のインストールの準備には、元のシステム・コンソールへのクローニングされたコンポーネント用のプロファイルの追加が含まれます。コンポーネントまたは方法にかかわらず、ホスト・システムおよび以前のカスタマイズを準備する必要があります。Webコンポーネントをアップグレードする場合には、Webサーバーの既存の構成ファイルをバックアップするよう指示されます。Windowsシステムの場合は、そのコンポーネントのWindowsレジストリの詳細をバックするよう指示されます。リリース6.xの環境またはマルチ言語のインストールを準備している場合には、別の準備アクティビティもあります。
スキーマおよびデータのアップグレードに向けた準備の概要: スキーマをアップグレードする場合には、ディレクトリ・サーバー・インスタンスおよびスキーマのバックアップを指示されます。第5章の説明に従って、ベンダーが提供するツールを使用してこれらのタスクを実行します。データのアップグレードは、最初にインストールされたCOREidサーバーおよびAccess Managerのクローンのアップグレード時に行われます。次のリストに、データのアップグレードを準備するために実行する必要のあるタスクを示します。
最初にインストールされたCOREidサーバーのクローン: 第5章の説明に従って、次に示すバックアップ・アクティビティを実行します。
最初にインストールされたすべてのAccess Managerのクローン: 第5章の説明に従って、ポリシー・データをバックアップします。
コンポーネントのアップグレードの準備の概要: 各オペレーティング・システムには、格納と取得用にファイルが編成されている階層ツリー構造があります。その他の準備アクティビティを実行した後で、（クローン・インスタンスと元のインスタンスのいずれの場合も）各インスタンスをアップグレードする前に、そのコンポーネントに適切な場所に10g（10.1.4.2.0）のMigrateOAMスクリプトがあることを確認してください。これらのアクティビティは、次のようにまとめられます。
ソースの作成: インスタンス（クローン・インスタンスと元のインスタンスのどちらの場合も）を含むサブディレクトリの名前を変更し、アップグレード用にソースを作成する必要があります。このマニュアルでは、サブディレクトリの名前の変更後、ソース・ファイル・システムのパスには識別子として_sourceが含まれます。たとえば、np611\ois_01\identity_sourceのようになります。
各ソースには、対応するインスタンスの構成の詳細がすべて含まれています。この情報は、インスタンスのアップグレード中に抽出されます。ソースはアップグレードされず、以前のインスタンスのバックアップ・コピーとして使用できます。
|
注意: 宛先ではファイル・システム内のクローンまたは元の場所が置き換えられるため、まずソースを作成する必要があります。 |
宛先の作成: 10g（10.1.4.0.1）のアイデンティティ・サーバーのライブラリとファイルを抽出し、名前を変更する前のクローン・インスタンス（元のインスタンスをアップグレードしている場合は元のインスタンス）のファイル・システムと同じパスを指定します。つまり、宛先パスは、ソースを作成するために名前を変更する前のクローンまたは元のサブディレクトリのパスに正確に一致する必要があります。このマニュアルでは、宛先パスはdestination_dirと表記される場合があります。
10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルはパッチの基礎となり、アップグレード中にソースから抽出される情報の宛先になります。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」を参照してください。
ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のインスタンスに適用し、アップグレードに必要なツールを取得します。
アップグレード後、この宛先には、ソースの構成の詳細（およびWindowsプラットフォームの場合は更新されたWindowsレジストリ・エントリ）に基づいて10g（10.1.4.2.0）にアップグレードされたインスタンスが含まれています。詳細は、「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」を参照してください。
元の環境およびクローン環境の詳細は、次の項を参照してください。
いくつかの時点で、停止時間ゼロのアップグレード中に検証を行うことは非常に重要です。この項では、停止時間ゼロのアップグレード・プロセス全体をとおして、クローニングされたコンポーネントと元のコンポーネントの正常な動作を確認するために実行する検証手順を説明します。
スキーマのアップグレード後には、クローン環境と元の環境の両方が、アップグレードしたスキーマを使用して問題なく動作していることを確認する必要があります。スキーマのアップグレード後の検証には次の内容が含まれます。
元の環境がアップグレードしたスキーマを使用して正常に動作していることの確認。
クローン環境がアップグレードしたスキーマを使用して正常に動作していることの確認。
アップグレードしたスキーマを使用して動作を検証したら、クローニングされたコンポーネントのアップグレードを開始できます。特定のクローンのアップグレード中、次のような場合に、構成データおよびポリシー・データがアップグレードされます。
アイデンティティ・システムのみがデプロイされている場合、または構成データとポリシー・データが一緒に格納されているアイデンティティ・システムおよびアクセス・システムの混合の場合は、最初にインストールされたCOREidサーバーのクローンのアップグレード時にデータがアップグレードされます。
構成データとポリシー・データが別々に格納されているアイデンティティ・システムおよびアクセス・システムの混合の場合は、最初にインストールされたAccess Managerのクローンのアップグレード時にアクセス・ポリシー・データがアップグレードされます。
特定のタスクが成功したことを検証するために実行する必要があるステップは、手順の中にステップとして埋め込まれています。クローン・インスタンスおよび元のインスタンスをアップグレードする際に、これらのステップを参照して実行します。埋め込まれたステップは、手順が成功したかどうかの判断に役立ちます。また、一連の手順の最後にはそれぞれの検証項目があり、システム全体のコンテキストの中で結果を検証できます。
次に示すようなタスクの概要では、実行する必要のあるタスクの概要が説明されており、情報が記載されている項への相互参照のリンクも提供されています。説明自体が情報へのリンクになっている場合もあります。次に示すタスクの概要のように、複数の項目が同じ項を参照している場合には、一般的なリンクが提供されます。次に示すタスクの概要の詳細は、「環境の正常な動作の検証」を参照してください。
タスクの概要: クローン・インスタンスおよび元のインスタンスのアップグレードの検証
すべてのコンポーネント、カスタマイズおよびその他の手動のアップグレード・タスクを含み、クローン・システムをアップグレードして設定したら、次の説明に従って続行します。
アイデンティティ・システムのクローン: アップグレード済のクローニングされたアイデンティティ・システムの検証
アクセス・システムのクローン: アップグレード済のクローニングされたアクセス・システムの検証
元のシステムをアップグレードして設定したら、次のように続行します。
さらに徹底した検証タスクを実行するために、タスクの前後に実行する確認用のテスト・スクリプトを開発して、完全エンドツーエンド・トランザクションを実行することをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。
長期にわたる検証を計画している場合は、クローン設定と元の設定を完全に分離することをお薦めします。詳細は、「停止時間ゼロのタスクおよび検証に要する期間」の「元の環境とクローン環境の分離の概要」を参照してください。
以前のOracle Access Managerインストールをカスタマイズした構成は、元のデプロイをアップグレードする前に互換性のテストを手動で行う必要があります。カスタマイズをアップグレードし、アップグレードしたクローン・システムを使用して十分にテストすることをお薦めします。
カスタマイズには、IdentityXML、PresentationXMLおよびAccess Manager API（以前のアクセス・サーバーAPIまたは短くアクセスAPI）を使用してフロントエンド用に作成されたものが含まれます。また、アイデンティティ・イベントAPI、認証APIおよび認可API（アクセス・ゲートやプラグインを含む）を使用して作成されたバックエンドのカスタマイズもその例です。
以前のカスタマイズのテストやアップグレードは、基本的には手動プロセスのため、その分、開発の時間がかかります。このため、カスタマイズを共有環境（QA、統合または本番など）に簡単に再デプロイできるようにするには、前もって計画することが重要です。
その他のアップグレードは余裕を持って開始し、カスタマイズに関する考慮事項を参照してください。
完全エンドツーエンド・トランザクションを実行するための、アップグレードの前および後に実行する確認用のテスト・スクリプトを開発します。
たとえば、このスクリプトにより、認証、認可およびワークフロー・リクエスト（すべて単一のページ・リクエストによってトリガー）を必要とする単一のページをリクエストできます。以前のリリースのカスタマイズの動作を確認するテスト・スクリプトを使用すると、これらのカスタマイズが意図したとおりに機能し、アップグレードの前と後で同じ結果を得られるかどうかを確認できます。テスト・スクリプトの結果は、実行対象の各カスタマイズに依存します。
スクリプトのコード、および特定の環境でのカスタマイズ構成方法を説明するために開発した手順をコンパイルおよびテストします。
元の環境で、以前のカスタマイズ（スタイル、アクセス・ゲートまたはプラグインなど）をテストし、正常に機能していることを確認します。
Oracle Access Managerサービス全体への依存性が最小限となる10g（10.1.4.2.0）開発デプロイ（理想的にはサンドボックス・タイプの設定）を作成するには、次のようにします。
10g（10.1.4.0.1）を小規模の独立したデプロイにインストールします。インストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)の指示に従い、リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）のコンポーネント・インスタンスに適用します。
10g（10.1.4.2.0）サンドボックスで、以前のカスタマイズをテストし、10g（10.1.4.2.0）の機能とともに動作するようカスタマイズをアップグレードするために必要な手動ステップを実行します。各カスタマイズの詳細は、次を参照してください。
停止時間ゼロのアップグレードを実行して、「停止時間ゼロのアップグレード・タスクおよび手順」の説明に従って、スキーマ、データおよびクローンをアップグレードします。
クローンをアップグレードしたら、アップグレード済のカスタム・コンポーネントを統合します。
第14章の説明に従って、アップグレードされたクローン環境を検証します。
アップグレードしたカスタマイズおよびクローン環境が問題なく連動していることを確認したら、元のコンポーンネントをアップグレードして停止時間ゼロのアップグレードを完了します。詳細は、次の項を参照してください。
アップグレードしたカスタマイズをアップグレードした元の環境と統合して完了し、動作を検証します。詳細は、「アップグレードした元の環境全体の検証」を参照してください。
この項では、停止時間ゼロのアップグレード・メソッドを使用する際に実行する必要があるタスクの概要を説明します。アクティビティを開始する前に、停止時間ゼロのアップグレード・メソッドに関するすべての情報を確認し、対象の環境に適切な方法であるかどうかを判断することをお薦めします。
停止時間ゼロのアップグレードを実行する場合は、すべてのタスクを図15-2に示されている順序で実行する必要があります。アップグレードするデプロイのサイズやタイプにかかわらず、すべてのタスクを実行する必要があります。たとえば、まず、小規模なサンドボックス・タイプの設定で停止時間ゼロのアップグレードを実行し、すべての手順やタスクに慣れます。その後、それと同じタスクをより大規模なデプロイで実行します。図15-2に続く概要には、それぞれのタスクに関する追加の情報が記載されており、すべての詳細が記載されている特定の項へのリンクが提供されています。
タスクの概要: 停止時間ゼロのメソッドおよびツールを使用したアップグレード
停止時間ゼロのアップグレード・アクティビティを開始する前に、停止時間ゼロのアップグレード・メソッドに関する詳細をすべて把握します。
|
注意: 停止時間ゼロのアップグレード・メソッドを使用してタスクを実行する前に、すべての情報を確認して、実行が必要な項目を完全に理解してください。 |
停止時間ゼロのアップグレードの計画を立てます。詳細は、「停止時間ゼロのアップグレード計画の立案」を参照してください。
各ホスト・コンピュータおよびクローニングする以前のコンポーネント・インスタンスを準備します。このタスクを実行するには次のようにします。
既存の各コンポーネントのホスト・コンピュータを、10g（10.1.4.0.1）でサポートされているレベルまで上げます。詳細は、「ホスト・コンピュータをOracle Access Manager 10g（10.1.4.0.1）のサポート・レベルまで上げる」を参照してください。
「ディレクトリ・サーバー・インスタンスおよびデータの準備」の説明に従って、ディレクトリ・サーバー・インスタンスを準備します。
必要な場合には、「デプロイへの新しいハードウェアまたは以前のインスタンスの追加」の説明に従って、新しいハードウェアまたは拡張対象の以前のインスタンスを追加します。
作成する各クローン・インスタンスのシステム・コンソールにエントリを追加します（デプロイ内の元のコンポーネントおよびインスタンスのそれぞれに1つのクローンを作成します）。特定のタスクの詳細は、表15-1に記載されている項を参照してください。
表15-1 停止時間ゼロのアップグレードのクローン・インスタンスのプロファイルのまとめ
| クローン・インスタンスのプロファイルの追加方法が説明されている項 |
|---|
|
システム・コンソールでの計画済COREidサーバー・クローンのプロファイルの追加 |
|
システム・コンソールでの計画済WebPassクローンのプロファイルの追加 |
|
WebPassクローンのプロファイルとCOREidサーバー・クローンのプロファイルの関連付け |
|
クローニングされたCOREidサーバーの新規ディレクトリ・サーバー・プロファイルの追加 |
|
「Access Managerクローンのエントリの概要」で説明されているように、Access Managerクローンにはプロファイルはありません。 |
|
|
|
アクセス・システム・クローンの新規ディレクトリ・サーバー・プロファイルの作成 |
|
WebGateクローンのエントリは追加しないでください。かわりに、「元のWebGateとアクセス・サーバー・クローンの関連付け」のアクティビティを実行します。 |
クローニングされたWebコンポーネントをホスティングしている各コンピュータに新しいWebサーバー・インスタンスを作成し、元のリリースで使用可能なサーバー構成更新ツールを実行してWebサーバー構成ファイルを更新します。
ファイル・システムに、以前の各コンポーネントのインストール・ディレクトリのクローンを作成します（WebGateを除く）。詳細は、「停止時間ゼロのアップグレードに向けた以前のコンポーネントのクローニング」を参照してください。アップグレードされたアクセス・サーバーには以前のWebGateとの下位互換性があるため、WebGateのクローンを作成する必要はありません。詳細は、「アクセス・サーバーの下位互換性」を参照してください。
「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」で説明されているように、必要な場合には、停止時間ゼロのアップグレード処理用に10g（10.1.4.2.0）のツールを取得する必要があります。
たとえば、LDAPディレクトリ・サーバーの新しいブランチへの移入や、スキーマ、各クローン・インスタンスおよび元の各インスタンスのアップグレードの一部として、次のタスクを実行します。
アイデンティティ・サーバー、WebPass、ポリシー・マネージャ、アクセス・サーバー（および元のWebGateインスタンスをアップグレードする場合はWebGate）など、アップグレードするインスタンスの最新の10g（10.1.4.0.1）のコンポーネント・ライブラリおよびファイルを抽出します。詳細は、「宛先の作成: 10g（10.1.4.0.1）のライブラリおよびファイルの抽出」の項にまとめられています。
リリース10.1.4パッチ・セット1（10.1.4.2.0）を取得して10g（10.1.4.0.1）のライブラリおよびファイル（インスタンスとも呼ばれる）に適用し、停止時間ゼロのアップグレード処理に必要なMigrateOAMスクリプトを取得します。詳細は、「ツールの取得: リリース10.1.4パッチ・セット1（10.1.4.2.0）の適用」にまとめられています。
停止時間ゼロのツールおよび処理の詳細は、「停止時間ゼロのアップグレードのツールおよびプロセス」を参照してください。
元の環境で使用されているのと同じLDAPディレクトリ・サーバーに新しいブランチを作成し、その新規ブランチに元の構成とデータのコピーを移入します。10g（10.1.4.2.0）のMigrateOAMスクリプトの機能を使用します。詳細は、「LDAPディレクトリ・サーバーの新しいブランチへの構成データおよびポリシー・データのコピー」を参照してください。
クローニングされたコンポーネント・ディレクトリでコマンドライン・ツールを使用し、LDAPディレクトリ・サーバーの新しいブランチを使用するようクローンを構成します。10g（10.1.4.2.0）のMigrateOAMスクリプトの機能を使用します。詳細は、「クローニングされたコンポーネントおよびサービスの構成」を参照してください。
LDAPディレクトリ・サーバーのスキーマをアップグレードします。10g（10.1.4.2.0）のMigrateOAMスクリプトの機能を使用します。詳細は、「停止時間ゼロのアップグレード中のスキーマのアップグレード」を参照してください。
環境を検証し、クローンおよび元のコンポーネントの両方が、アップグレードしたスキーマを使用して問題なく動作していることを確認します。詳細は、「環境の正常な動作の検証」を参照してください。
10g（10.1.4.2.0）のMigrateOAMスクリプトの機能を使用してクローニングされたコンポーネントをアップグレードし、アップグレードしたクローン環境を検証します。
クローニングされたアイデンティティ・システム: アイデンティティ・システムのクローンをアップグレードして検証します。詳細は、「クローニングされたアイデンティティ・システムのアップグレード」を参照してください。LDAPディレクトリ・サーバーの新しいブランチの構成データは、最初にインストールされたCOREidサーバーのクローンのアップグレード時にアップグレードされます。このアクティビティには、「アイデンティティ・システム・クローンのアップグレード後における監査ファイル名の変更」のタスクが含まれます。
クローニングされたアクセス・システム: アクセス・システムのクローンをアップグレードして検証します。詳細は、「クローニングされたアクセス・システムのアップグレード」を参照してください。LDAPディレクトリ・サーバーの新しいブランチのポリシー・データは、最初にインストールされたAccess Managerのクローンのアップグレード時にアップグレードされます。
アップグレードしたクローン・システムを使用してテストできるように、カスタマイズをアップグレードおよび統合するための手動タスクをすべて実行します。
アップグレードしたクローン・システム全体を徹底的に検証し、すべてが問題なく動作していることを確認します。詳細は、第14章を参照してください。
元のブランチの元のデータに対する変更: 更新された元のデータを新しいブランチに再度移入し、クローンを新たにアップグレードして検証タスクを実行します。実行する前に、「元のインスタンスのアップグレード前における元のブランチに対する変更内容取得の概要」を参照してください。手順は、「元のシステムのアップグレード前における元のブランチに対する変更内容の取得」を参照してください。
元のコンポーネントのアップグレード中にクローンが元のコンポーネントの代替になるよう、ネットワーク・フェイルオーバーを再構成します。詳細は、「アップグレードしたクローンを使用するためのドメイン・ネーム・システム（DNS）の再構成」を参照してください。
元のコンポーネントをアップグレードし、LDAPディレクトリ・サーバーの新しいブランチを使用するよう元のコンポーネントを再構成して、アップグレードされた元のコンポーネントが問題なく動作していることを確認します。10g（10.1.4.2.0）のMigrateOAMスクリプトの機能を使用するには、次のようにします。
元のアイデンティティ・システムのアップグレード: 元のアイデンティティ・システムをアップグレード、再構成および検証します。詳細は、「元のアイデンティティ・システムのアップグレード」を参照してください。
元のアクセス・システムのアップグレード: 元のアクセス・システムをアップグレード、再構成および検証します。詳細は、「元のアクセス・システムのアップグレード」を参照してください。
元のカスタマイズをアップグレードおよび統合します。詳細は、「アップグレードした元の環境全体の検証」を参照してください。
元のアイデンティティ・システムのカスタマイズ: 「SDKおよびアイデンティティ・システムのカスタマイズのアップグレード」の説明に従って、アップグレードして検証します。
元のアクセス・システム: 「SDK、統合コネクタおよびアクセス・システムのカスタマイズのアップグレード」の説明に従って、アップグレードして検証します。
以前のクローン・デプロイまたは元のデプロイにロールバックしないことを確認したら、ユーザー・データの自動移行を開始します。詳細は、「ユーザー・データの即時移行の開始」を参照してください。
次のようにしてアップグレードを完了します。
停止時間ゼロのメソッドを使用したデプロイのアップグレードおよび検証に必要な実際の時間の長さは、元のデプロイのサイズと複雑さによって異なります。たとえば、アイデンティティ・システムおよびアクセス・システムの結合のデプロイで、プラグインとカスタマイズが最小限で各コンポーネントのインスタンスが1つのみの場合、停止時間ゼロのアップグレードの実行に1週間かかる場合があります。これには、計画からスキーマのアップグレード、およびデータとクローン環境のアップグレードまでのすべてのタスクが含まれます。
アップグレードが成功したことを確認するために、検証も実行する必要があります。スキーマ、クローン、カスタマイズおよび元のインスタンスのアップグレード後に、アップグレードが成功したことを確認するために検証タスクを実行する必要があります。検証が綿密であるほど、実行により長い時間がかかります。
検証タスクを実行するために、タスクの前後に実行する確認用のテスト・スクリプトを開発して、完全エンドツーエンド・トランザクションを実行することをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。
アップグレードしたクローン設定を使用して、リリース10g（10.1.4.2.0）の機能を確認することをお薦めします。ロスト・パスワード管理を含む、すべての機能を使用できます。ただし、ロスト・パスワード管理のチャレンジ属性およびレスポンス属性の複数の値の移行は行われません。詳細は、「ユーザー・データの移行およびLPMのチャレンジ属性とレスポンス属性の複数の値」を参照してください。
リリース10g（10.1.4.2.0）の機能に慣れるための時間が長くなると、元のコンポーネントのアップグレードまでにかかる期間も長くなります。アップグレードしたクローン設定を長期間（たとえば2〜3か月）使用する場合は、クローン環境を元の環境から完全に分離して特定のアクティビティを実行することをお薦めします。詳細は、「元の環境とクローン環境の分離の概要」を参照してください。
新しいブランチに元の構成データおよびポリシー・データを移入した後は、元のデプロイのデータを変更しないことをお薦めします。ただし、データを変更するかどうかの判断は、完全にユーザーに委ねられています。クローン環境の検証中に元の設定が変更された場合には、新しいブランチに更新された元のデータをコピーしてクローンを再度アップグレードするために、追加の手順を実行する必要があります。これにより、クローンが元のデプロイの代替になるようにネットワーク・フェイルオーバーを設定する前に、元のデプロイで行われたデータの変更がディレクトリの新しいブランチに格納されます。アップグレードしたクローン環境を元の環境と置き換えると、元の環境のアップグレードに数週間かかる場合があります。
大規模なカスタマイズされたデプロイで停止時間ゼロのメソッドを使用してアップグレードおよび検証を行う場合は、約3か月の期間を見込んでおくことをお薦めします。
このタスクはオプションです。アップグレードしたクローン設定を長期間（たとえば2〜3か月）使用する場合は、アップグレードしたクローン環境を元の環境から完全に分離することをお薦めします。
クローンおよび元のシステムは別々に動作し、どのような場合でもLDAPディレクトリ・サーバーの異なるブランチが使用されます。2つの環境を分離しても、スキーマまたはデータに影響はありません。クローンおよび元のシステムの両方で、アップグレードしたスキーマが使用されます。
これらのタスクは、クローン設定をアップグレードする前、またはクローン設定をアップグレードし、完全に動作可能であることまたはまったく動作しないことを検証した後に実行できます。このオプションのタスクを実行すると、次のような影響があります。
このタスクを実行するかどうか、またはいつ実行するかを決定する前に、ロールバックおよび停止時間ゼロのアップグレードの再開に対する次の影響を考慮してください。
クローンのシステム・コンソールに元のプロファイルを含めない場合。ロールバックに影響はありません。
元のシステム・コンソールにクローン・プロファイルを含めない場合、ロールバックしてクローンのアップグレードを再開したら、これらを再入力する必要があります。
また、クローン・システムのアップグレードおよび期間検証中に、元のデータに加えられた変更内容を含む別の新しいブランチを作成する場合は、元のシステム・コンソールにもクローン・プロファイルを再入力する必要があります。元のデータに加えられた変更内容の取得の詳細は、次の項を参照してください。
環境の分離手順は、「環境の分離」を参照してください。
アップグレードしたクローン・システムを使用して、検証タスクを実行することや、10g（10.1.4.2.0）の機能に慣れることができます。たとえば、新しいアクセス・ポリシーを作成し、アップグレードしたクローン・システムの構成データを変更できます。
アップグレードしたクローン・システムに対する変更内容は、LDAPディレクトリ・サーバーの新しいブランチに格納されます。これらの変更内容は元のブランチには移行できず、元のコンポーネントでは使用できません。元のコンポーネントをアップグレードして、新しいブランチを使用するよう再構成するまで、元のシステムは新しいブランチにアクセスできません。
ロスト・パスワード管理機能は、アップグレードしたクローン・システムで使用できます。ただし、ユーザー・データを変更しないかぎり、ロスト・パスワード管理にチャレンジおよびレスポンスを複数使用することはできません。詳細は、「ユーザー・データの移行およびLPMのチャレンジ属性とレスポンス属性の複数の値」を参照してください。
アップグレードしたクローン・システムでは、スタイルシートおよびファイルをカスタマイズして新しいカスタマイズをテストできます。アップグレードしたクローン環境に、新しいカスタマイズを保持できます。カスタマイズしたファイルがある場合は、元の環境のアップグレード後に、アップグレードした元の環境に転送できます。
新しいブランチを作成して元のインスタンスをアップグレードする前に、LDAPディレクトリ・サーバーの元のブランチに変更が加えられた場合は、元のインスタンスをアップグレードする前に変更内容を取得できます。これは、分離した環境に影響を及ぼすオプションのタスクです。詳細は、「元のシステムのアップグレード前における元のブランチに対する変更内容の取得」を参照してください。
停止時間ゼロのアップグレード・メソッドでは、Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）でのみ使用可能なMigrateOAMスクリプトを使用します。このツールを取得するには、Oracle Access Manager 10g（10.1.4.0.1）の各コンポーネントのインスタンスを1つインストールし、リリース10.1.4パッチ・セット1（10.1.4.2.0）を10g（10.1.4.0.1）の各コンポーネントに適用します。詳細は、「宛先作成の概要および停止時間ゼロのアップグレード用ツールの取得」を参照してください。
MigrateOAMスクリプトには、停止時間ゼロのアップグレード中に特定のタスクの実行に役立つ、次のような機能モードがあります。
Mkbranch: 元のLDAPディレクトリ・サーバー・インスタンスに作成する新しいブランチに、元の構成データおよびポリシー・データのコピーを移入します。
スキーマ: クローンおよび元の環境の両方で使用されるLDAPディレクトリ・サーバーのスキーマをアップグレードします。
クローン: クローン・コンポーネント、および新しいブランチの構成データとポリシー・データをアップグレードします。
Prod: 新しいブランチを使用するよう再構成する必要のある元のコンポーネントをアップグレードします。
表15-2に、MigrateOAMスクリプトに必要なモード引数および指定内容の一般的なサマリーを示します。停止時間ゼロのアップグレード・アクティビティの個々の手順により、そのタスクの正確な引数と指定内容が提供されます。
表15-2 MigrateOAMの引数および指定内容のサマリー
| MigrateOAMの引数 | 値および指定内容 |
|---|---|
|
10g（10.1.4.2.0）のMigrateOAMスクリプトへのファイル・システム・パス |
インスタンスおよび実行するタスク用のMigrateOAMスクリプトが存在する10g（10.1.4.2.0）のファイル・システム・パスへ変更します。次に例を示します。 Windows clone_np\identity\oblix\tools\migration_tools UNIX /home/clone_np/identity/oblix/tools/migration_tools |
|
-script name |
Windows: MigrateOAM. bat UNIX: MigrateOAM.sh |
|
-M Mode |
実行するタスクに適切なモードを指定します。
|
|
-C component |
タスクに適切なコンポーネントの宛先ディレクトリを指定します。
|
|
-F nnn |
以前のリリースを示す数値を指定します。次に例を示します。
|
|
-T 1014 |
コンポーネントのアップグレード後のリリースである、アップグレード先リリースとして1014を指定します。 |
|
-S "source directory" |
指定されたコンポーネントの以前のソース情報を含む、名前が変更されたファイル・システム・ディレクトリへのフルパスを引用符で囲んで指定します。次に例を示します。
注意: ソースに含まれている構成の詳細は、既存の以前のコンポーネントのものです。アップグレード・アクティビティ中は、ファイル・システム・ディレクトリは変更されません。 |
|
-D "destination directory" |
コンポーネント・インスタンスの10g（10.1.4.2.0）のMigrateOAMスクリプトを含むファイル・システム・ディレクトリへのフルパスを引用符で囲んで指定します。次に例を示します。
注意: 宛先ディレクトリには、以前のソース・ディレクトリの詳細に基づいて更新される10g（10.1.4.2.0）の情報が含まれています。 |
|
-I "installation directory" |
インストール・ディレクトリは、必ず宛先ディレクトリと一致する必要があります。次に例を示します。
注意: このファイル・システム・ディレクトリは、スクリプトおよび基礎となるツールによって参照されています。10g（10.1.4.2.0）のスクリプトおよびツールが含まれます。 |
その他のコマンドライン・ツールと同様に、すべての引数および指定内容を1行で入力する必要があります。このマニュアルおよびユーザーの画面では、行が折り返されて次の例のように見える可能性があります。
cd \1014\identity\oblix\tools\migration_tools>MigrateOAM.bat -M Mkbranch
-C OIS -F 610 -T 1014 -S "C:\clone_np\ois_01\identity" -D "C:\1014\identity"
-I "C:\1014\identity"
[Enter]キーを押すと処理が開始されます。メッセージとプロンプトから処理内容がわかります。開始リリース（6.1.1など）から、単に10.1.4と呼ばれることもある最新のリリース10g（10.1.4.2.0）まで、操作の各手順で一連の同じメッセージとプロンプトが表示されます。つまり、一連のメッセージとプロンプトは何度も表示されます。
プロセスをスキップしないように、必要な場合には、自動操作モードを使用して操作を許可および実行することをお薦めします。確認済操作モードでは、ユーザーがより多くの操作を実行する必要があります。このモードでは操作がスキップされる可能性があり、失敗の原因になります。
各コンポーネントのアップグレード中に、ログ・ファイルが1つ以上生成されます。これらのファイルは、問題が発生した場合に作成されます。ログ・ファイルが作成される場合、アップグレード・プロセスのメッセージにより、ログ・ファイルの名前と場所が表示されます。
一部の操作では、MigrateOAMスクリプトにより、インプレース・アップグレードで使用されるユーティリティがコールされます。各ログ・ファイルには、コンポーネントのアップグレード中に発生する特定のアクティビティに関する情報が含まれます。たとえば、ファイルのアップグレード、メッセージとパラメータのアップグレード、またはOracle Access Managerスキーマのアップグレードに対して、別個のログ・ファイルが生成されます。各ログ・ファイルとその内容については、付録Cを参照してください。
Mkbranchモードを使用すると、MigrateOAMスクリプトにより単一のログ・ファイルが生成されます。Mkbranchログ・ファイルは、宛先のファイル・システム・パスに格納されます。次に例を示します。
ここで、\destination_dirは、抽出およびパッチ適用された特定のコンポーネント・ライブラリとファイルのファイル・システム・ディレクトリです。identity|accessはコンポーネントが属するシステム（それぞれアイデンティティ・システムまたはアクセス・システム）で、makebranch.logはファイル名です。
また、LDAP固有のエラーを通知するために、次のログ・ファイルが作成されます。
アイデンティティ・サーバー・データの移行時に、特定のコンポーネントの宛先のファイル・システム・パスに、error_output_fromversion_to_toversion_osd.ldifファイルが作成されます。たとえば、ファイル・システムのIdentityServer_destination_dir\identity\oblix\tools \migration_tools\obmigratedataディレクトリです。
ポリシー・マネージャ・データの移行時に、宛先のファイル・システム・パスに、error_output_fromversion_to_toversion_psc.ldifファイルが作成されます。たとえば、ファイル・システムのPolicyManager_destination_dir\access\oblix\tools\migration_tools\obmigratedataディレクトリです。
ログ・ファイルの使用上の詳細は、付録Gを参照してください。
各モードでコールされるプロセスおよびユーティリティの詳細は、次の項を参照してください。
この項では、LDAPディレクトリ・サーバーの新しいブランチに、元の構成データおよびポリシー・データのコピーを移入する際に使用されるMkbranchモードのMigrateOAMスクリプトについて説明します。
このモードを使用する前に、元の構成ベース（構成DNとも呼ばれる）およびポリシー・ベース（ポリシーDNとも呼ばれる）の子ノードとして新しいブランチ・ノードを手動で作成する必要があります。次に例を示します。
o=company,c=uso=Newbranch,o=company,c=uso=Policy_base,o=company,c=uso=NewPolicyBase,o=Policy_base,o=company,c=us新しいブランチは、元のブランチと同じLDAPディレクトリ・サーバー・インスタンスに存在する必要があります。元のブランチは変更されません。新しい構成DNは次のようにして定義できます。
o=Newbranch,<OldConfigDN>およびo=NewPolicyBase,<oldPolicyBase>
o=Newbranch,o=company,c=us（o=company,c=usは古い構成DN）
o=Newbranch,dc=us,dc=company,dc=com（dc=us,dc=company,dc=comは古い構成DN）
Mkbranchモードの処理中、データのコピーは新しい構成DNまたはポリシーDN用に変更され、ldifファイルにインポートされます。インポートされたデータは、新しいldifファイルから新しいブランチにエクスポートされます。
コールされるツールおよびMkbranchの操作中に自動的に実行されるプロセスは、図15-3に記載されています。
アイデンティティ・システムのみの場合、ポリシー・データはありません。この場合、Mkbranchモードを使用できるのは、最初にインストールされたCOREidサーバーのクローンのみです。元の構成データは新しいブランチにコピーされます。
アイデンティティ・システムおよびアクセス・システムの混合で、構成データとポリシー・データが同じLDAPディレクトリ・サーバー・ノードに一緒に格納されている場合、最初にインストールされたCOREidサーバーのクローンにMkbranchモードを使用する際にデータが一緒にコピーされます。ただし、ポリシー・データが別のブランチまたは別のディレクトリ・インスタンスに格納されている場合は、最初にインストールされたAccess ManagerのクローンにMkbranchの操作を繰り返してポリシー・データを新しいブランチにコピーする必要があります。
プロセスの概要: MigrateOAMを使用した新しいブランチへの移入
Mkbranchコマンドおよび指定内容を入力すると、ファイル・システム内の以前のソース・ディレクトリが検出されます。
ディレクトリ接続が確立され、新しい構成DNがリクエストされます。
元のブランチのデータの読取りおよびコピーが行われます。
新しい構成DN（両方が一緒に格納されている場合にポリシーDNも）にコピーが通知され、LDIFファイルにエクスポートされます。成功または失敗のメッセージが表示されます。
コピーされたデータが、LDIFファイルから新しいブランチにインポートされます。
成功または失敗のメッセージが表示されます。
構成データとポリシー・データが別々に格納されていて、インストールおよび設定された最初のAccess ManagerコンポーネントのクローンにMkbranchモードを使用する場合は、この手順が繰り返されます。
この項では、MigrateOAMスクリプトをスキーマ・モードで実行する場合に行われるスキーマのアップグレード処理について説明します。
停止時間ゼロのアップグレード・メソッドでは、スキーマのアップグレードは、ディレクトリ・サーバーとのインタフェースとなるクローン・コンポーネント（アイデンティティ・サーバーおよびポリシー・マネージャ）においてのみ実行されます。スキーマのアップグレードを実行する必要のある回数は、データの格納方法によって異なります。詳細は、「停止時間ゼロのアップグレード中のスキーマのアップグレード」を参照してください。
スキーマのアップグレード中、以前のリリースのスキーマと次のリリースのスキーマとの差異が、特定のディレクトリ・サーバーで必要とされるスキーマldifファイルを使用して、ディレクトリ・サーバーにアップロードされます。どのスキーマldifファイルにも、2つのバージョン間の差異に基づく、スキーマを変更するためのエントリが含まれています。
スキーマのアップグレードは（その他すべてのアップグレードと同じように）段階的に行われます。つまり、元のリリースがその次の後継リリースにアップグレードされ、アップグレード結果のスキーマも同じ後継リリースにアップグレードされ、以降同様に、元のリリースと最新リリース間の中間スキーマ変更がすべて反映されるまで繰り返されます。不要になったスキーマ要素は、アップグレード中に削除されます。
アップグレード後、処理に関する詳細を次のログ・ファイルで確認できます。
destination_dir\identity|access\oblix\tools\migration_tools\obmigratenp.log
destination_dir\identity|access\oblix\tools\migration_tools\obmigrateschema.log
MigrateOAMスクリプトをスキーマ・モードで実行すると、図15-4に示すように、LDAPディレクトリ・サーバーのスキーマをアップグレードするためのプロセスが開始されます。
プロセスの概要: MigrateOAMを使用したスキーマのアップグレードの場合
MigrateOAMを起動して、スキーマ・モードと指定内容を指定すると、ファイル・システム内のソース・ディレクトリが検出されます。
「自動」操作モードまたは「確認済」操作モードのいずれかを選択するよう要求されます。「自動」を選択することをお薦めします。
ユーティリティobmigratenpをコールして、その他にどのユーティリティをコールするかを決定し、言語の移行を管理します。
ユーティリティobmigratedsがコールされ、次の操作が実行されます。
構成ファイルを読み取り、スキーマ・データ（OSD）を評価して、Oracle Access Managerとやり取りするディレクトリ・サーバーを検出します。
ディレクトリ・サーバーとの接続およびバインドに必要な情報を収集します。
特定のディレクトリ・タイプのスキーマ・ファイルの場所、およびアップグレード元/先のバージョンを確認し、ds_conf_update.exeユーティリティを使用してディレクトリ・サーバーに適切なldifファイルをアップロードします。
OSDから読み取られた情報（たとえば、「o=oblix...」というノード）と構成ファイルを使用して、obmigratedata.exeに渡す入力マップ・ファイルを作成します。
OSD、ポリシーおよびワークフローのアップグレードの場合:
data_fromrelease_to_torelease_osd.lst
ユーザー・データのアップグレードの場合:
data_fromrelease_to_torelease_user.lst
LDAPディレクトリ・サーバーのコンポーネントおよびデータ記憶域に基づいて、スキーマのアップグレード手順が開始されます。
最初にインストールされたCOREidサーバー: アイデンティティ・システムのスキーマが、最も古いリリースから次のリリース（6.1.1から6.5など）へアップグレードされます。
最初にインストールされたAccess Manager: アクセス・システムのスキーマが、最も古いリリースから次のリリース（6.1.1から6.5など）へアップグレードされます。詳細は、「停止時間ゼロのアップグレード中のスキーマのアップグレード」を参照してください。
完了したリリースから次のリリース（6.5から7.xなど）へのアップグレードを継続するには、ステップ4を繰り返します。リリース10.1.4になるまでこれを繰り返します。
確認を要求されて完了です。
この項では、MigrateOAMをクローン・モードで使用してクローン・コンポーネントをアップグレードする際に行われる処理について説明します。LDAPディレクトリ・サーバーの新しいブランチの構成データおよびポリシー・データも、次のようにアップグレードされます。
新しいOracle Access ManagerリリースにOracle Access Manager固有のデータの新しい編成または値が含まれる場合、データのアップグレードはスキーマのアップグレードとほぼ同様に実行されます。以前のバージョンと新しいバージョンとのデルタが検出されてデータの適切なldifが提供されるため、これらのデータをディレクトリ・サーバーにアップロードできます。アップグレードが完了するまで、メジャー・リリース間のアップグレードが段階的に実行されます。アップグレードが完了すると、Oracle Access Managerはディレクトリにあるデータを検索して使用し、円滑に動作できるようになります。
データのアップグレードは、ディレクトリ・サーバーとのインタフェースとなるOracle Access Managerコンポーネント（アイデンティティ・サーバーおよびポリシー・マネージャ）においてのみ実行可能です。
このために、オブジェクト・クラス・マッピングと属性マッピングが両方含まれるファイルが提供されます。オブジェクト・クラス・マッピング・ファイルと属性マッピング・ファイルは、obmigratedataファイル・システム・ディレクトリに配置されています。次に例を示します。
IdentityServer_install_dir\identity|access\oblix\tools\migration_tools\
obmigratedata
クローン・モードを使用する際に行われるMigrateOAMスクリプト処理は、図15-5に示されています。LDAPディレクトリ・サーバーの新しいブランチのコピーされた構成データは、最初にインストールされたCOREidサーバーのクローンのアップグレード時にのみアップグレードされます。LDAPディレクトリ・サーバーの新しいブランチのコピーされたポリシー・データは、最初にインストールされたAccess Managerのクローンのアップグレード時にのみアップグレードされます。LDAPディレクトリ・サーバーの元のブランチのデータは変更されません。
プロセスの概要: MigrateOAMを使用したクローン・コンポーネントのアップグレードの場合
MigrateOAMを起動して、クローン・モードとクローン・インスタンスの詳細を指定すると、ファイル・システム・ソースが検出されます。
|
注意: 10g（10.1.4.0.1）言語パックを使用しないで既存のマルチ言語実装をアップグレードすると、マルチ言語機能が失われます。 |
アップグレード前のリリースとアップグレード後のリリースに基づいて、特定のコンポーネントでアップグレードが必要な機能を検出するために、ユーティリティ（obmigratenp）がコールされます。
obmigratenpは、必要に応じて他のユーティリティをコールします。既存インストールに複数の言語が含まれている場合、obmigratenpはメッセージ・カタログを移行します。また、obmigratenpは、データおよびファイルの移行も監視します。
|
注意: インストール済の言語は、インストール済の各言語の適切な10g（10.1.4.0.1）言語パックを、10g（10.1.4.0.1）コンポーネント・インストーラと同じファイル・システムのディレクトリにインストールすることでアップグレードされます。 |
obmigratefilesが、以前のプログラム・ファイルおよびライブラリ・ファイルをアップグレードするためにコールされます。obmigratefilesの詳細は、「ファイルのアップグレード: obmigratefiles」を参照してください。
obmigrateparamsgが、以前のメッセージ・カタログ・ファイルおよびパラメータ・カタログ・ファイルをアップグレードするためにコールされます。obmigrateparamsgの詳細は、「メッセージおよびパラメータのアップグレード: obmigrateparamsg」を参照してください。
データのアップグレード: obmigratedsは、（スキーマではなく）データのみのアップグレードの場合にNoSchemaモードでコールされます。データのアップグレードは、データが10.1.4にアップグレードされるまで、データを以前のリリースからその次のリリースにアップグレードする手順で行われます。
obmigratedsは、最初にインストールおよび設定したCOREidサーバーのクローン（および最初にインストールおよび設定したAccess Managerのクローン）においてのみコールされます。後続のクローンのアップグレード中、データのアップグレードが検出されてスキップされます。
LDAPディレクトリ・サーバーの元のブランチのデータはアップグレードされません。データのアップグレードの詳細は、「構成データおよびポリシー・データのアップグレードの概要」を参照してください。obmigratedsの詳細は、「スキーマのアップグレード: obmigrateds」を参照してください。
コンポーネント固有のユーティリティが選択、実行され、Windowsの関連するレジストリ・エントリ、プラグインおよびその他のファイルが変更されます。コンポーネントの構成ファイルは、以前のリリースからその次のリリースへと10.1.4になるまで繰り返される手順で更新されます。これは、最初にインストールされたCOREidサーバー（またはAccess Manager）のクローンをアップグレードする際の、データのアップグレードに組み込まれています。次のように、対応するコンポーネントのアップグレードに対して単一のツールがコールされます。
アイデンティティ・サーバー: obMigrateNetPointOisは、アイデンティティ・サーバーの既存レジストリ・エントリをアップグレードして新しいリリースを反映し、PPPカタログを必要に応じて変更します。また、password.xmlにあるパスワードを必要に応じて変更し、適切なuninstall_info.txtを再作成します。詳細は、「アイデンティティ・サーバー: obMigrateNetPointOis」を参照してください。
|
注意: Oracle Access Manager 5.2のpassword.xmlファイルおよびpassword.lstファイルに書き込まれたパスワードは暗号化されていません。これに対して、それより以後のバージョンでは暗号化されます。暗号化はアップグレード中に自動的に行われます。 |
WebPass: obMigrateNetPointWPは、WebPassの既存レジストリ・エントリをアップグレードして新しいリリースを反映し、password.xmlにあるパスワードを必要に応じて変更します。詳細は、「WebPass: obMigrateNetPointWP」を参照してください。
ポリシー・マネージャ: obMigrateNetPointAMは、ポリシー・マネージャのレジストリ・エントリをアップグレードし、password.lstにある暗号化パスワードを必要に応じて変更します。また、名前の変更されたソース・ディレクトリからターゲット・インストール・ディレクトリにカスタム・プラグインをコピーします。詳細は、「ポリシー・マネージャ: obMigrateNetPointAM」を参照してください。
アクセス・サーバー: obMigrateNetPointAAAは、アクセス・サーバーのレジストリ・エントリをアップグレードして、暗号化パスワードを必要に応じて変更します。また、名前を変更したソース・ディレクトリからターゲット・インストール・ディレクトリにカスタム・プラグインをコピーして、次に示すフェイルオーバー・ファイルをアップグレードします。
AppDB.lst: .xmlに変換されます。
ConfigDB.lst: .xmlに変換されます。
Group.lst: .xmlに変換されます（存在する場合）。
UserDB.lst: .xmlに変換されます（存在する場合）。
WebResrcDB.lst: .xmlに変換されます。
アップグレードおよび変換される項目の詳細は、「アップグレードされる項目」を参照してください。obmigratenpユーティリティの詳細は、「アクセス・サーバー: obMigrateNetPointAAA」を参照してください。
SDK: obMigrateNetPointASDKがobmigratenpからコールされ、Access Manager SDKのアップグレードを実行します。
SDKのアップグレードは、SDKにバンドルされたコンポーネント（アイデンティティ・サーバーおよびOracle Access Manager WebSphere用コネクタ）のアップグレードの最終ステップとして自動的に開始されます。詳細は、「Software Developer Kit（SDK）: obMigrateNetPointASDK」を参照してください。
|
注意: 自動SDKアップグレードを拒否すると、現在のSDK構成設定が保持されなくなるため、『Oracle Access Managerアクセス管理ガイド』で説明されているように、configureAccessGateツールを使用してSDKを再構成する必要があります。 |
Web Server構成の更新: ユーティリティobmigratewsがコールされ、指定のWebサーバー構成ファイルおよびフィルタのアップグレードを実行し、WebPass、Access ManagerおよびWebGateの新しいリリースの変更内容を組み込みます。詳細は、「Webサーバーのアップグレード: obmigratews」を参照してください。
プロセスは最後の注釈で完了します。
この項では、MigrateOAMをProdモード（本番または元のインスタンスのモード）で使用した場合と、クローン・モードで使用した場合のアップグレードの違いについて説明します。
MigrateOAMスクリプトをProdモードで使用して元のコンポーネントをアップグレードする際に行われる処理は、MigrateOAMスクリプトをクローン・モードで使用してクローン・コンポーネントをアップグレードする際に行われる処理とほぼ同じです。
Prodモードでは、obmigratedsはコールされず、インストールされた最初のCOREidサーバーまたはAccess Managerのアップグレード時にスキーマまたはデータがアップグレードされないという例外が適用されます。
元のコンポーネントをアップグレードしたら、LDAPディレクトリ・サーバーの新しいブランチでアップグレードしたデータを使用するよう、アップグレードした元のコンポーンネントを再構成する必要があります。詳細は、第17章で説明されています。
インプレース・アップグレードで説明したバックアップ/リカバリ計画の多くが、停止時間ゼロのアップグレードにも適用されます。停止時間ゼロの手順では同じ説明を繰り返さないので、その情報が記載されているこのマニュアルの元の場所を探してください。表15-3に、バックアップが必要な項目の情報とマニュアル内の説明の場所を示します。
表15-3 停止時間ゼロのアップグレード前のバックアップの計画
| バックアップ対象 | 詳細の参照先 |
|---|---|
|
Oracle Access Managerのスキーマ |
|
|
Oracle Access Managerの構成データおよびポリシー・データ |
|
|
Oracle Access Managerのユーザー・データおよびグループ・データ |
|
|
Oracle Access Managerのワークフロー・データ |
|
|
処理済ワークフロー |
|
|
既存のディレクトリ・インスタンス |
|
|
Webサーバー構成ファイル |
|
|
Windowsレジストリ |
次に、停止時間ゼロのアップグレードで行うタスクを説明します。これらのタスクは今は実行しないでください。
停止時間ゼロのスキーマのアップグレード: アップグレードしたスキーマには、最も古いものでリリース6.1.1までのスキーマとの下位互換性機能があります。ただし、オラクル社が提供するツールを使用してスキーマのアップグレードをロールバックすることはできません。アップグレード前に外部ツールを使用して以前のスキーマをバックアップしておけば、元のリリースにロールバックする場合に、バックアップ・コピーを回復できます。詳細は第5章を参照してください。
停止時間ゼロのデータのアップグレード: 停止時間ゼロのアップグレード中には、ディレクトリ・サーバーの元のブランチのデータは変更されません。ただし、停止時間ゼロのアップグレード中に、LDAPディレクトリ・サーバーに新しいブランチを作成して移入する前に、表15-3のデータのバックアップ・タスクを実行することをお薦めします。
Oracle Access Managerインスタンスのアップグレード: 停止時間ゼロのアップグレード・メソッドでは、元のインスタンスのファイル・システム・ディレクトリをバックアップする必要はありません。作成するソースはアップグレード中は変更されず、バックアップ・コピーになります。詳細は、「停止時間ゼロのメソッドの準備タスク」を参照してください。ソースを作成しても、インスタンスのWebサーバー構成の詳細またはWindowsレジストリの詳細はバックアップされません。各インスタンスのアップグレード前にこれらをバックアップする方法の詳細は、第8章を参照してください。
アップグレード後のバックアップ: 多くのタスクは、手順が成功したか失敗したかを簡単に評価できる特定のステップで終了します。（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）アイデンティティ・システムのアップグレードを終了し、アップグレードしたアイデンティティ・システム情報をバックアップする前に、完全に動作可能であることを検証することをお薦めします。アイデンティティ・システムとアクセス・システムの混合の場合は、アップグレードしたアクセス・システムをバックアップする前に、（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）アクセス・システムをアップグレードおよび検証します。
バックアップする情報は、クローン・インスタンスと元のインスタンスのいずれをアップグレードした場合でも類似しています。たとえば、アップグレードしたコンポーネントのファイル・システム・ディレクトリおよびカスタム・ディレクトリをバックアップします。必要な場合には、Webサーバー構成ファイルおよびWindowsレジストリ・エントリもバックアップします。
表15-4に、停止時間ゼロのアップグレード・タスク後のバックアップについて説明する項を示します。
表15-4 停止時間ゼロのアップグレード後のバックアップの計画
| バックアップ対象 | 詳細の参照先 |
|---|---|
|
アップグレード済のクローニングされたアイデンティティ・システム |
|
|
アップグレード済のクローニングされたアクセス・システム |
|
|
アップグレードした元のアイデンティティ・システム |
|
|
アップグレードした元のアクセス・システム |
（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）停止時間ゼロのアップグレード・タスク後に予想どおりに動作しないものがある場合には、次に示す一連の処理のいずれかを続行できます。
リカバリは、以前のインスタンス（クローン・インスタンスまたは元のインスタンスのいずれか）をリストアし、再度アップグレードを試行するための手順を実行できるプロセスです。
|
注意: リカバリ計画は、必要に応じて、適切なバックアップ・タスクを実行してある場合にのみ成功します。 |
参考にできるリカバリ手順の一般的な情報は、第2章に記載されています。詳細は、表2-3「アップグレードのリカバリ計画」を参照してください。また、次の内容も参照してください。
停止時間ゼロのアップグレードの各タスクには、タスクの最後に、特定のインスタンスに問題があるかどうかを評価する1つ以上のステップがあります。一般的には、すぐに実行可能なリカバリ手順が含まれています。
停止時間ゼロのアップグレード・メソッドには、特定のリカバリに関する項が記載されています。詳細は、表15-5を参照してください。
ロールバックは、実行したことをすべて元に戻し、停止時間ゼロのアップグレードの元の設定および開始点に戻るプロセスです。ロールバック後は、元のインストールと元のリリース・レベルのみになります。
WebGateが1つのみの場合、ロールバック中は停止します。停止を避けるため、WebGateを複数用意することをお薦めします。または、アップグレードしたアクセス・サーバーと連動できるため、古いWebGateを残してアップグレードしないことも可能です。
表15-6 停止時間ゼロのアップグレード中のロールバック
| タスク | 参照先 |
|---|---|
|
システム・コンソールのクローン・プロファイル |
|
|
インスタンスのクローニング |
|
|
ディレクトリ・サーバーへの新しいブランチの作成および移入 |
|
|
新しいブランチを使用するためのクローンの再構成 |
|
|
スキーマのアップグレード |
|
|
データまたはアイデンティティ・システムのクローンのアップグレード |
|
|
データまたはアクセス・システムのクローンのアップグレード |
|
|
元のアイデンティティ・システムのアップグレード |
|
|
元のアクセス・システムのアップグレード |
ロールバック操作中のWindowsレジストリ・エントリの詳細は、「ロールバック操作中における元のWindowsレジストリ・エントリの回復」を参照してください。
この項では、Windowsプラットフォームにインストールされた元のコンポーネント・インスタンスをアップグレードした後、ロールバック中にレジストリ・エントリを回復する方法を説明します。この項は、他のプラットフォームには関係ありません。
WindowsプラットフォームへのOracle Access Managerコンポーネントのインストール中に、そのインスタンス用のWindowsレジストリ・エントリが作成されます。Windowsレジストリ・エントリは、常に、インストールされた場所および製品リリース（Oracle Access Managerリリース6.1.1など）を指しています。レジストリ・エントリは、インストール中のOracle Access Managerコンポーネントのタイプに基づいて、特定のインストール・フェーズの後に作成されます。
アイデンティティ・サーバーまたはアクセス・サーバーをインストールする場合、Windowsレジストリ・エントリは、インスタンスのサービス名を指定した後に作成されます。
Webコンポーネント（WebPass、ポリシー・マネージャおよびWebGate）をインストールする場合、サービス名はありません。この場合、Windowsレジストリ・エントリは、指定されたインストール・パスにライブラリおよびファイルが抽出された後に作成されます。
Windowsレジストリの詳細は転送できません。そのため、あるインストール場所から別の場所にライブラリおよびファイルをコピーできません。新しい場所にあるサービスを使用します。ただし、コンポーネントをアップグレードすると元のレジストリが削除され、最新のリリースに対して新しいエントリが作成されます。詳細は、次のとおりです。
アップグレード後、Windowsレジストリに含まれているのは、宛先のファイル・システム・パスにあるアップグレードしたインスタンスのエントリのみです。
アップグレード後は、元のレジストリ・エントリを回復できないかぎり、元のインスタンスをロールバックして使用することはできません。回復しない場合、Oracle Access Managerサービスが失敗します。
ロールバック手順を確実かつ効率的に実行するには、インスタンスのアップグレード・アクティビティを開始する直前に、元のインスタンスごとにWindowsレジストリ・エントリをバックアップすることをお薦めします。つまり、元のファイル・システムのパス名を変更して停止時間ゼロのアップグレードのソースを作成する前に、元のWindowsレジストリ・エントリをバックアップする必要があります。実際、各アップグレード手順のステップ1で、第8章で詳細に説明されている特定の準備タスクを実行するよう指示しています。この準備タスクでは、ファイル・システム・ディレクトリ、Webサーバー構成ファイルおよびWindowsレジストリの詳細のバックアップを実行します。
ロールバックする際に、次の方法で元のレジストリ・エントリを回復できます。
推奨方法: 元のインスタンスのファイル・システム・パスの名前を変更してアップグレード・ソースを作成する前に、元のレジストリ・エントリをバックアップします。
各インスタンスのアップグレード・アクティビティを開始する前に、（クローン・インスタンスであるか元のインスタンスであるかにかかわらず）インスタンスのレジストリの詳細をエクスポートすることをお薦めします。これにより、元のリリースにロールバックする場合に、レジストリ・エントリをインポートできます。
代替方法: ロールバック・タスク中に元のインスタンスを回復します。
ロールバック中にインポートするバックアップのレジストリ・エントリがない場合は、エントリを自動的に回復する方法はありません。この場合は、元のコンポーネントのインストールを新たに開始する必要があります。レジストリ・エントリを作成したら、インストール・プロセスを終了して、アップグレード前に名前を変更したソースから元の構成の詳細をコピーします。詳細は、トラブルシューティングに関する付録「元のインスタンスのアップグレードをロールバックする際に使用する新しいレジストリ・キーの生成」を参照してください。
停止時間ゼロのアップグレード・アクティビティを開始するに先立ち、この章を通読してください。インプレース・アップグレードの停止時間の評価計画の詳細は、「停止時間ゼロのタスクおよび検証に要する期間」を参照してください。
インプレース・アップグレードを実行する場合も、停止時間ゼロのアップグレード・メソッドを使用する場合も、前提条件およびアップグレード・タスクに関するしっかりとした計画を立てる必要があります。計画の成果物には、デプロイ内の既存の全コンポーネント・インスタンス用に収集した詳細のインベントリが含まれます。
元のデプロイの各コンポーネントおよびインスタンスの詳細をまとめ、記録しておく必要があります。計画および追跡の詳細は付録Fに記載されています。
停止時間ゼロのアップグレードの計画を立てる際には、次のタスクを実行します。計画が完了したら、第16章の説明に従ってアップグレードを開始できます。
計画を立てる際は、停止時間ゼロのアップグレードに関するすべての考慮事項を確認します。具体的には、次のとおりです。
すぐにアップグレードする元のコンポーネントを特定し、計画ドキュメントに詳細を記録します。詳細は、付録Fのサマリーを参照してください。
後からアップグレードできるコンポーネントを特定します（使用していないアクセス・サーバー、WebGateおよびSoftware Developer Kit（SDK））。
「手動でアップグレードする必要のある項目」の説明に従って、自動的にアップグレードされない項目を手動で移行する計画を立てます。
次に示す、計画に関する一般的な考慮事項を確認してください。
デプロイ・シナリオ: アップグレード・タスクは、組織が採用したデプロイ方法（アイデンティティ・システムのみのデプロイかアイデンティティ・システムとアクセス・システムの混合デプロイか、イントラネットかエクストラネットか、インストールされた環境の数とタイプはどのようなものか）に応じた順序で実行する必要があります。
たとえば、以前のアイデンティティ・システムのみのリリースが、イントラネットのみで使用するために、3種類の異なるLDAP環境（開発、テスト/デモ、本番デプロイ）にデプロイされている場合、アップグレード・プロセスは、最終的に本番環境で実行する前に、より小さな環境で実行および微調整する必要があります。
安定性: アップグレード対象の各デプロイでは、安定して動作している、適切にインストールされたリリースが現在稼働している必要があります。つまり、アップグレードを開始する前に、以前のOracle Access Manager構成が安定していて完全であることを確認する必要があります。
元の環境が安定していることを確認するには、確認用のテスト・スクリプトを開発し、アップグレードの前および後で実行することをお薦めします。たとえば、このスクリプトにより、認証、認可およびワークフロー・リクエスト（すべて単一のページ・リクエストによってトリガー）を必要とする単一のページをリクエストすることで、完全なエンドツーエンド・トランザクションを実行します。このスクリプトは、タスクが成功したことや、クローンまたは元のコンポーネントのアップグレード後にシステムが問題なく動作していることの検証にも役立ちます。
管理アクセス: スキーマ（およびその他）のアップグレード操作には、LDAPディレクトリ・サーバーやOracle Access Managerファイルへの、書込み権限を含む管理アクセス権限が必要です。
スキーマおよびデータのアップグレード: これらは、停止時間ゼロのアップグレード・メソッドを使用する際に、別々に実行されます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
カスタマイズのアップグレード: これは基本的に手動のプロセスです。テストおよび修正は開発環境で実行した上で、その内容を共有または本番環境に再デプロイすることをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。
以前のデプロイのインベントリの記録: 以前のOracle Access Managerインストールの正確な詳細をまだ記録していない場合、表15-7（第1章の繰返し）に記載されているように、アイデンティティ・サーバーとアクセス・サーバーのコンポーネント、LDAPディレクトリ・サーバー、Webサーバーおよびアプリケーションの詳細も必ず含めます。参照用として、または複製や入力用として使用可能な計画のサマリーは、付録Fを参照してください。
表15-7 以前のデプロイの詳細のインベントリ
| 詳細のタイプ | 説明 |
|---|---|
|
トランスポート・セキュリティ・モード: 簡易、証明書またはオープン ルートCAの詳細（証明書モードが使用されている場合） NetPointに関するホスト定義タイプのエントリ（/etc/hostなど） |
|
|
アイデンティティ・サーバーのインベントリ |
ワークフロー、検索ベースおよびACL NetPointで管理される全オブジェクトのオブジェクト定義の詳細（可能な場合） 監査構成の詳細 パスワード・ポリシー構成 |
|
アクセス・サーバーのインベントリ |
ポリシー・ドメイン、認証スキーム、リソース定義、ホスト識別子 監査構成 ディレクトリ・プロファイル情報 |
|
アップグレード中に影響を受けるアプリケーション層の詳細 |
Cookieまたはヘッダー変数を使用してWebGateによって保護された統合（これらに対する影響は最小限に抑える必要があります）。 APIを使用して作成されたカスタム・アクセス・ゲート統合（より顕著な影響を受ける可能性があります）。 Oracle Access Manager Identity Portal Insertsを公開するアプリケーション（ポータルなど）。これらを綿密に調べ、アップグレード・プロセス中にワークフローにアクセスできないときに、サービスが一時的に使用できないというページが表示されることを確認します。 IXMLに依存しているアプリケーションは影響が著しく大きくなります。これは、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サーバー）のユーザー名およびグループ・メンバーシップの記録 |
|
LDAPディレクトリ・サーバー層 |
LDAPディレクトリ・サーバーの正確なバージョンおよびパッチ・レベル（Sun ONE v5.2 SP2など） LDAPディレクトリ・サーバーの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）と互換性があることを確認します。これは基本的に手動の手順です。詳細は、次を参照してください。 |
