ヘッダーをスキップ

Oracle Application Server 高可用性ガイド
10gリリース3(10.1.3.2.0)

E05048-01
目次
目次
索引
索引

戻る 次へ

8 OracleAS Disaster Recoveryサイトのアップグレード手順

この章では、Oracle Application Server Disaster Recovery(OracleAS Disaster Recovery)のサイト全体をOracleAS 10g(9.0.4)からOracleAS 10gリリース3(10.1.3.1.0)にアップグレードする方法について説明します。この手順は、サイトを定義しているトポロジ内のOracleホーム・タイプすべてに対してリリース9.0.4からリリース10.1.3にアップグレードすることが可能であることを前提としており、これらの手順をOracleAS Disaster Recovery(DR)ソリューションにおいて拡張します。

このサイトは、OracleAS 10g(9.0.4)用『Oracle Application Server高可用性ガイド』の「Oracle Application Server Disaster Recovery」に説明されているように、既存のサポート済DR実装をアップグレードします。このプロセスでは、サポートされていないDR環境はアップグレード済DR環境にはアップグレードされません。また、この手順では既存のリリース9.0.4 Oracleホーム内でスタンドアロンのOracleAS Guardインストールが利用され、OracleAS Guardの操作手順を使用して指示が表示されます。この環境が可能でない場合は、同等の手動手順を実行できます。つまり、OracleAS Guardのsync topologyコマンドの実行は、OracleAS 10g(9.0.4)用『Oracle Application Server高可用性ガイド』の「Oracle Application Server Disaster Recovery」に説明されているサイトの同期手順を実行することと同じことです。

8.1 前提条件

OracleAS 10g(9.0.4)からOracleAS 10gリリース3(10.1.3.1.0)へのDRサイトのフル・アップグレードを実行するための前提条件は次のとおりです。

8.2 Disaster Recoveryのトポロジ

このDR環境に関与するシステムは、サイトAとサイトBの2つのサイトに含まれています。各サイトの初期のロールは次のとおりです。

これらのサイトは地理的に離れているため、各サイトの現在のロールはこの手順の終了時におけるこれらのサイトの最終的なロールになるものと想定します。ただし、手順の実行過程でこれらのロールは変更されます。このため、ここではすべて、「サイトA」および「サイトB」という名前で呼びます。特定の時点におけるサイトのロールによっては、使用される用語によって混乱を招く場合があります。

8.3 高レベルOracleAS Disaster Recoveryのアップグレード手順

次の手順では、OracleAS 10g(9.0.4)からOracleAS 10gリリース3(10.1.3.1.0)へのDisaster Recoveryのアップグレード・シナリオについて説明します。これらの手順では、サイトAとサイトBのInfrastructureシステムを、それぞれinfra1およびinfra2と呼びます。

  1. OracleAS GuardのOracleAS 10gリリース3(10.1.3.1.0)スタンドアロン・インストールを本番サイトとスタンバイ・サイトの各Oracleホームにインストールします。

    1つのシステムに複数のOracleホームが存在する場合は、この構成ファイルで各OracleAS Guardサーバーにそれぞれ異なるポートが構成されていることを確認してください。デフォルトのポート番号は7890です。

    <ORACLE_HOME>/dsa/dsa.conf
    
    
  2. スタンバイ・サイト[サイトB]で、OracleAS Guardサーバーを起動します。

    <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA
    
    
  3. 本番サイト[サイトA]で、OracleAS GuardのInfrastructureシステムinfra1に接続し、同期操作を実行します。

    この操作によって、トポロジ全体のOracleホームが論理的に同期されます。

    1. asgctlクライアントを起動します。

      On Unix systems
      <ORACLE_HOME>/dsa/bin/asgctl.sh
      
      On Windows systems
      <ORACLE_HOME>¥dsa¥bin¥asgctl
      
      
    2. サイトAのInfrastructureシステムinfra1への接続操作を実行します。

      ASGCTL> connect asg infra1 ias_admin/<password>
      
      
    3. プライマリ・データベースをサイトAのOracleAS Metadata Repositoryに設定します。

      ASGCTL> set primary database sys/<password>@<site A's servicename>
      
      
    4. トポロジを検出します。

      ASGCTL> discover topology oidpassword=<oidpwd>
      
      
    5. トポロジをダンプします。

      ASGCTL> dump topology to c:¥policy_file_no_904_instances.txt
      
      
    6. トポロジ・ファイル(この例ではpolicy_file_no_904_instances.txt)を編集し、たとえば次のように、すべての9.0.4インスタンスをIgnoreに設定します。

      <policy>
      .
      .
      .
      <instanceList successRequirement="Ignore">
         <instance>904Portal_3</instance>
      </instanceList>
      .
      .
      .
      </policy>
      
      

      このポリシー・ファイルをDisaster Recoveryに関連するすべての操作に使用します。

    7. 手順3fの編集済ポリシー・ファイルを使用して、スタンバイ・サイトBのInfrastructureシステムinfra2を本番サイトと同期化します。

      ASGCTL> sync topology to infra2 using policy c:¥policy_file_no_904_
      instances.txt
      
      
    8. アップグレード手順中に環境が変更されないようにします。これには顧客データの変更は含まれません。顧客データはID管理(IM)およびMetadata Repository(MR)データとは別のデータベースに配置されるためです。ただしこのモデルでは、アップグレード手順中にIMおよびMRデータを再び同期することはできません。

  4. スタンバイ[サイトB]のInfrastructureに接続し、フェイルオーバーします。

    この手順の目的は、DR環境を2つの独立したサイトに分割することです。これによって、サイトBを最初にアップグレードできるようになります。サイトBがアップグレードされたら、アプリケーション・レベルのテストを実行し、アップグレードが完了しており、このサイトが稼動していることを確認できます。この方法を使用する場合、本番サイトであるサイトAは、アップグレード中、完全にDRトレラントにはなりません。理論的には、サイトBがアップグレードされたため、この時点で別のスタンバイ・サイトを確立できます。

    OracleAS Guardのフェイルオーバー操作を実行する手順は次のとおりです。

    1. サイトBのInfrastructureシステムinfra2への接続操作を実行します。

      ASGCTL> connect asg infra2 ias_admin/<password>
      
      
    2. 新しいプライマリ・データベースをサイトBのOracleAS Metadata Repositoryに設定します。

      ASGCTL> set new primary database sys/<password>@<site B's servicename>
      
      
    3. スタンバイ・サイトであるこのサイトBに対してフェイルオーバー操作を実行します。フェイルオーバー操作によって、opmnctl startallコマンドと同等のすべてのOPMN管理サービスがトポロジ全体で開始されます。

      ASGCTL> failover using policy c:¥policy_file_no_904_instances.txt
      
      
  5. サイトBのサイトに対して他のサービスを開始します。

    アプリケーション、データベース・ジョブ、Enterprise Managerなどの、テストに必要な追加のサービスは手動で実行する必要があります。

  6. サイトBのシステムに対して、OracleASアップグレードを実行します(詳細は、『Oracle Application Serverアップグレードおよび互換性ガイド』を参照)。

  7. 本番サイトでアプリケーションをテストするか、解決が必要な問題を確認します。アップグレードが正常に完了するまで、テストを実行し続けます。

  8. 必要に応じてサイトのアクセスをサイトBにリダイレクトします。

    1. 次の操作では、サイトAがアップグレードされます。サイトBはこのアップグレード手順中になんらかのレベルのサービスを提供できます。理論的には、この時点ですべてのアクセスを付与できます。サイトBがアップグレードされると、このサイトでリクエストが処理され、これがDR環境の本番ロールとなります。サイトAがアップグレードされると、両方のサイトのソフトウェア・バージョンが同じになり、DRのインスタンス化および同期操作が可能になります(手順12で実行)。この方法を使用する場合、元の本番サイト[サイトA]で行われた更新は失われます。

    2. 手順8aが実装され、サイトBが本番サイトになった場合は、サイトAがその後アップグレードされるため、手順3hの制限は無視してください。

  9. サイトAのシステムに対して、OracleASのアップグレードを実行します(詳細は、『Oracle Application Serverアップグレードおよび互換性ガイド』を参照)。

  10. アプリケーションをテストするか、解決が必要な問題を確認します。アップグレードが正常に完了するまで、テストを実行し続けます。

    この手順が完了すると、2つのサイトのアップグレードは機能的に同じになり、OracleAS Disaster Recovery 10.1.3.1.0にアップグレードされた状態になります。サイトBでは完全なサイトの機能が有効になり、本番とスタンバイの関係を確立できるようになります。

  11. 古いOracleAS 9.0.4のOracleホームでOracleAS Guardサーバーを停止し、UNIXシステムの<ORACLE_HOME>/dsaディレクトリまたはWindowsシステムの<ORACLE_HOME>¥dsaディレクトリにあるdsa.confファイルを削除して、新しいOracleAS 10.1.3のOracleホームのすべてのシステムでDSAプロセスとOPMNサーバーを再起動します。

    UNIXシステムの場合:

    <ORACLE_HOME>/opmn/bin/opmnctl stopall
    <ORACLE_HOME>/opmn/bin/opmnctl startall
    <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA
    
    

    Windowsシステムの場合:

    <ORACLE_HOME>¥opmn¥bin¥opmnctl stopall
    <ORACLE_HOME>¥opmn¥bin¥opmnctl startall
    <ORACLE_HOME>¥opmn¥bin¥opmnctl startproc ias-component=DSA
    
    
  12. 手順8aを利用する場合は、OracleAS Guardを使用して、サイトBからサイトAへのサイトのインスタンス化を実行します。

    この手順によって、サイトBとサイトAのOracleAS Disaster Recovery環境が再確立されます。この手順では、サイトBが本番サイトで、サイトAはサイトBをミラー化するように更新されます。

    次のasgctl手順を実行してこの操作を完了します。

    1. asgctlクライアントを起動します。

      On Unix systems
      <ORACLE_HOME>/dsa/bin/asgctl.sh
      
      On Windows systems
      <ORACLE_HOME>¥dsa¥bin¥asgctl
      
      
    2. サイトBのInfrastructureシステムinfra2への接続操作を実行します。

      ASGCTL> connect asg infra2 ias_admin/<password>
      
      
    3. プライマリ・データベースをサイトBのOracleAS Metadata Repositoryに設定します。

      ASGCTL> set primary database sys/<password>@<site B's servicename>
      
      
    4. トポロジを検出します。

      ASGCTL> discover topology oidpassword=<oidpwd>
      
      
    5. トポロジをダンプします。

      ASGCTL> dump topology to d:¥policy_file_no_904_instances.txt
      
      
    6. トポロジ・ファイル(この例ではpolicy_file_no_904_instances.txt)を編集し、たとえば次のように、すべての9.0.4インスタンスをIgnoreに設定します。

      <policy>
      .
      .
      .
      <instanceList successRequirement="Ignore">
         <instance>904Portal_3</instance>
      </instanceList>
      .
      .
      .
      </policy>
      
      

      このポリシー・ファイルをDisaster Recoveryに関連するすべての操作に使用します。

    7. 手順12fの編集済ポリシー・ファイルを使用して、サイトAのスタンバイInfrastructureシステムinfra1にトポロジをインスタンス化します。

      ASGCTL> instantiate topology to infra1 using policy d:¥policy_file_no_904_
      instances.txt
      
      
  13. ドメイン名システム(DNS)のスイッチオーバー操作を実行します。

    通常はこの手順をここで実行し、スイッチオーバー操作中のDNSタイムアウトを吸収するようにします。DNS、サイトのサービスおよびアプリケーションがすべてスイッチオーバーされ、実行されるまで、エンド・ユーザーのアクセス・エラー(サービス利用不能)が発生します。

  14. OracleAS Guardを使用して、サイトBからサイトAへのスイッチオーバーを実行します。

    最終的な目標は、アップグレードの終了時点でこのプロセスの開始時点と同じアクセスを得ることです。したがって、ロールをサイト間で交換する必要があります。サイトBのInfrastructureに接続し、プライマリ・データベースを設定し、トポロジの検出を実行し、手順12fの編集済ポリシー・ファイルを使用してサイトAのInfrastructureシステムinfra1へのスイッチオーバーを実行します。

    ASGCTL> connect asg infra2 ias_admin/<password>
    ASGCTL> set primary database sys/<password>@<site B's servicename>
    ASGCTL> switchover topology to infra1 using policy d:¥policy_file_no_904_
    instances.txt
    
    
  15. 手順914のかわりに次の手順を実行することもできます。

    1. 本番サイト[サイトA]を停止します。

    2. サイトAのシステムに対して、OracleASのアップグレードを実行します(詳細は、『Oracle Application Serverアップグレードおよび互換性ガイド』を参照)。

    3. OracleAS Guardを使用して、サイトAからサイトBへのインスタンス化を実行します。

  16. アプリケーション用に本番サイトAのサービスを開始します。

これで、OracleAS 10g(9.0.4)からOracleAS 10gリリース3(10.1.3.1.0)へのOracleAS Disaster Recoveryサイトのアップグレード手順に必要な手順が完了しました。

8.4 既存のOracleAS Disaster Recovery環境へのパッチ適用

OracleAS Disaster Recovery環境にパッチを適用して(リリース10.1.3.1.0を使用したOracleAS Guard 10.1.2.n.n(n.nは0.0および0.2を表す)へのパッチ適用)この最新リリースのOracleAS Guardの機能を活用する方法の詳細は、プラットフォーム固有のOracle Application Serverのインストレーション・ガイド、特に「高可用性環境へのインストール: OracleAS Disaster Recovery」を参照してください。この章には、このパッチ適用プロセスについて説明した項「OracleAS Guardリリース10.1.2.n.nへのリリース10.1.3.0.0のパッチの適用」が含まれています。


戻る 次へ
Oracle
Copyright © 2007, Oracle.

All Rights Reserved.
目次
目次
索引
索引