1. Oracle WebCenter Contentの移行
  2. クラスタ化されたWebCenter Content 12cを異なるインフラストラクチャ上の新しいホストに移行する方法

7 クラスタ化されたWebCenter Content 12cを異なるインフラストラクチャ上の新しいホストに移行する方法

WebCenter Contentリリース12cのクラスタを、WebCenter Contentのオペレーティング・システムおよびディレクトリ構造が既存のインフラストラクチャと異なるインフラストラクチャに移行する場合、後続のトピックに従うことでその目的を達成できます。

ノート:

WebLogic ServerとWebCenter Contentのバージョンは、古いホストと新しいホストの間で一致している必要があります。次のトピックには、新しいバージョンにアップグレードする手順ではなく、WebCenter Contentの現在の設定を移行する手順が含まれます。既存のインフラストラクチャからWebCenter PortalやBPMなどの他のOracle製品を移行するには、その必要な作業手順も考慮してください。ここでのトピックでは、WebCenter Contentの移行のみを取り上げます。

トピック

7.1 クラスタ化されたWebCenter Content 12cを異なるインフラストラクチャに移行するための準備ステップ

移行プロセスを開始する前に、次のステップを実行します:
  1. すべての管理対象サーバー、管理サーバーおよびノード・マネージャを停止します。
  2. WebCenter Contentのファイル・システムをバックアップします。
  3. WebCenter Contentのデータベースをバックアップします。
  4. 古いホストと同じJDKバージョンを新しいホストにインストールします。
  5. WebLogic Serverのバイナリを新しいホストにインストールします。
  6. WebCenter Contentのバイナリを新しいホストにインストールします。
  7. 古いホストに適用したものと同じパッチを新しいホストにインストールします。
  8. WebCenter Contentを移行する場合、古いホストから共有ファイル・システムをデタッチ/アンマウントします。
  9. WebCenter Contentをクローニングする場合、古いホストから共有ファイル・システムをデタッチ/アンマウントして、共有ファイル・システムを新しい場所にコピーします。
  10. データベースを移行するシナリオもいくつかあります。そのようなシナリオの1つは、WebCenter ContentをOracle Cloudに移行する場合です。2番目のシナリオは、オンプレミス移行でデータベースを新しいインフラストラクチャに移行する場合です。3番目のシナリオは、WebCenter Contentをクローニングする場合です。これらのどのケースでも、データベース・スキーマは、新しいデータベース・インスタンスで使用可能であることと、WebCenter Contentが存在している新しいホストからアクセス可能であることが前提となります。構成ウィザード(config.sh)を実行するときに、新しい場所にあるデータベース・スキーマに接続できるよう、追加のステップを実行する必要があります。システム・スキーマ内には3つのオブジェクトがあり、これらのオブジェクトは、特にアップグレード時に、Fusion Middlewareが適切に動作するために必要です。これらのオブジェクトは、schema_version_registryビュー、schema_version_registryシノニムおよびschema_version_registry$表です。これらの項目のいずれかがない場合は、「RCUデータベースのなくなったSYSTEM.SCHEMA_VERSION_REGISTRYオブジェクトのリカバリ」のステップに従って、なくなったオブジェクトを新しいデータベース・インスタンスで再作成し、今後の問題を回避する必要があります。さらに、対象の環境に定義した接頭辞が名前に付いているすべてのスキーマを組み込む必要があります。

7.2 RCUデータベースのなくなったSYSTEM.SCHEMA_VERSION_REGISTRYオブジェクトのリカバリ

SYSTEM.SCHEMA_VERSION_REGISTRYスキーマ・バージョン・レジストリ表には、すべてのスキーマのバージョン・データが格納されています。この表がないと、アップグレードなど、多くの操作を進められません。

なくなったデータベース・オブジェクトをリストアするには:
  1. スキーマ・バージョン・レジストリtable/view/synonymが存在するかどうかを確認します:
    1. sysdba権限のあるユーザーとしてリポジトリ・データベースに接続しているときに、次のデータベース問合せを実行します
    2. SYSTEM.SCHEMA_VERSION_REGISTRY$.TABLEが存在し、view/synonymのみがない場合は、ステップ7に進みます。
      column OWNER format a10
select owner, object_name, object_type from all_objects where object_name like'%SCHEMA_VERSION_REGISTRY%';

OWNER OBJECT_NAME OBJECT_TYPE
---------- ------------------------------ -------------------
SYSTEM SCHEMA_VERSION_REGISTRY VIEW
PUBLIC SCHEMA_VERSION_REGISTRY SYNONYM
SYSTEM SCHEMA_VERSION_REGISTRY$ TABLE
  2. 最初にスキーマを作成する際に使用されたものと同じバージョンのRCUを使用します。既存のリポジトリに対してRCUを実行し、新しい接頭辞でスキーマを作成します。DEV1は、残りのステップで新しい接頭辞として使用されます。
  3. 元のスキーマをコピーして、schema_version_registryの複製エントリを作成します。DEVは、残りのステップで元の接頭辞として使用されます。
    1. RCU実行でDEV1用に作成されたスキーマ・エントリを表示します。
      select rowid, mrc_name, owner from system.schema_version_registry$;
ROWID MRC_NAME OWNER
----------------- ------------------------------ ------------------------------
AAASqQAABAAAUmJAAA DEV1 DEV1_MDSAAASqQ
AABAAAUmJAAB DEV1 DEV1_ORASDPM
AAASqQAABAAAUmJAAC DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABA
    2. DEV1からsystem.schema_version_registry$に複製エントリを作成します。
      insert into system.schema_version_registry$ select * from system.schema_version_registry$ where mrc_name='DEV1';
    3. 問合せを実行して複製エントリを表示します。
      select rowid, mrc_name, owner from system.schema_version_registry$;

Example:
ROWID MRC_NAME OWNER
----------------- ------------------------------ ------------------------------
AAASqQAABAAAUmJAAA DEV1 DEV1_MDS
AAASqQAABAAAUmJAAB DEV1 DEV1_ORASDPMAAASqQ
AABAAAUmJAAC DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABAMAAASqQ
AABAAAUmJAAE DEV1 DEV1_MDSAAASqQ
AABAAAUmJAAF DEV1 DEV1_ORASDPMAAASqQ
AABAAAUmJAAG DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAH DEV1 DEV1_ORABAM
  4. MRC_NAME列の元のスキーマの接頭辞と一致するよう、複製エントリを変更します。これは、ROWID列で、新しく作成されたRCUエントリと作成した複製を区別して実行します。ご使用のデータベースでは、これらのROWID値が、この例に示す値とは異なりますので注意してください。元のスキーマ接頭辞としてDEVを使用します。
    update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_MDS' where rowid='AAASqQAABAAAUmJAAE';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORASDPM' where rowid='AAASqQAABAAAUmJAAF';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_SOAINFRA' where rowid='AAASqQAABAAAUmJAAG';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORABAM' where rowid='AAASqQAABAAAUmJAAH';
  5. 元の接頭辞(DEV)を示す変更を表示します。
    select mrc_name, owner, status from schema_version_registry where mrc_name='DEV';

MRC_NAME OWNER STATUS
------------------------------ ------------------------------ -----------
DEV DEV_ORABAM LOADINGDEV 
DEV_MDS VALIDDEV 
DEV_ORASDPM VALIDDEV 
DEV_SOAINFRA VALID
  6. 変更のコミット
    commit;
  7. system.schema_version_registry$のパブリック・シノニムとビューを作成します。
    create view system.schema_version_registry as select comp_id, comp_name,mrc_name, mr_name, mr_type, owner, version, status, upgraded, start_time,modified, edition from system.schema_version_registry$;

create public synonym SCHEMA_VERSION_REGISTRY FOR SYSTEM.SCHEMA_VERSION_REGISTRY;
  8. 一部のスキーマに適切な権限を付与することが必要な場合があります(例: エクスポート/インポート中にスキーマの権限が失われた場合)。このステップはサイト固有であり、状況や作成されるスキーマによって異なります。
    For example:
grant select on system.schema_version_registry to DEV_IAU ;
grant select on system.schema_version_registry to DEV_IAU_APPEND;
grant select on system.schema_version_registry to DEV_IAU_VIEWER;
grant select on system.schema_version_registry to DEV_MDS ;
grant select on system.schema_version_registry to DEV_OPSS;
  9. RCUを再度実行して、前述のステップ2で実行したときに作成されたすべてのスキーマを削除します。これにより、接頭辞(例: DEV)が付いたスキーマの変更されたschema_version_registryエントリのみが、追加した system.schema_version_registry$表に残ります。

7.3 既存ドメインのテンプレートの構築

準備ステップを実行したら、移行するドメインのテンプレートを構築します。

テンプレートを構築するには:
  1. 管理サーバーが実行されているホスト(この例ではapphost1)でテンプレート・ビルダーを実行します。
    $ORACLE_HOME/oracle_common/common/bin/config_builder.sh
  2. 「テンプレート・ビルダー」ダイアログ・ボックスで:
    1. 「テンプレート・タイプ」ページで、「ドメイン・テンプレートの作成」および「ドメインをソースとして使用」を選択し、「ソースの場所」にこのテンプレートを作成するドメインのディレクトリを指定して、「テンプレートの場所」に新しいテンプレートを保存するための名前と場所を指定します。
    2. 「テンプレート情報」ページで、値を確認して「次」をクリックします。
    3. 「テンプレートのサマリー」ページで、値を確認して「作成」をクリックします。
    4. 「構成の進行状況」ページで、「次」をクリックします。
    5. 「構成の終了」ページで、「終了」をクリックします。
  3. 作成したドメイン・テンプレートを、新しい管理サーバーが存在する新しいホストにコピーします。

7.4 新規ドメインの作成

ドメイン・テンプレートを作成して、クラスタ化されたWebCenter Content 12cインスタンスの移行先となる新しいホストにコピーしました。ここでは、新しいホストに新しいドメインを作成します。

新規ドメインを作成するには:
  1. 作成したテンプレートを使用して、新しいホストでFusion Middleware構成ウィザードを実行します:
    $ORACLE_HOME/oracle_common/common/bin/config.sh
  2. 「Fusion Middleware構成ウィザード」ダイアログ・ボックスで:
    1. 「ドメインの作成」ページで、「新規ドメインの作成」を選択し、ドメインの場所を指定して「次」をクリックします。
    2. 「テンプレート」ページで、「カスタム・テンプレートを使用してドメインを作成」を選択し、テンプレートの場所を指定して「次」をクリックします。
    3. 「アプリケーションの場所」ページで、アプリケーションの場所を指定して「次」をクリックします。
    4. 「管理者アカウント」ページで、「名前」、「パスワード」および「パスワードの確認」の値を指定して「次」をクリックします。
    5. 「ドメイン・モードおよびJDK」ページで、ドメイン・モードとJDKを選択して「次」をクリックします。
    6. 「JDBCデータ・ソース」ページで、(適用可能な場合は)次のいずれかを実行します:
      • データベースを移行しない場合、MDSデータソースを選択して「次」をクリックします。
      • データベースを移行する場合、MDSスキーマを選択し、「ホスト名」、「DBMS/サービス」、「ポート」、「ユーザー名」および「パスワード」の新しい値を入力して「次」をクリックします。
    7. 「JDBCデータ・ソース・テスト」ページで、mds-WCCUIMDSREPOデータ・ソースを選択して「選択された接続のテスト」をクリックします。テストの成功を確認してから「次」をクリックします。
    8. 「データベース構成タイプ」ページで、(適用可能な場合は)次のいずれかを実行します:
      • データベースを移行しない場合、「RCU構成の取得」を選択して「次」をクリックします。
      • データベースを移行する場合、次を実行します:
        1. 「ホスト名」、「DBMS/サービス」、「ポート」、「スキーマ所有者」および「スキーマ・パスワード」の新しい値を入力します。
        2. 「RCU構成の取得」を選択して「次」をクリックします。
    9. 「JDBCコンポーネント・スキーマ」ページで、(適用可能な場合は)次のいずれかを実行します:
      • データベースを移行しない場合、スキーマを選択して「次」をクリックします。
      • データベースを移行する場合、各データ・ソースの「ホスト名」、「DBMS/サービス」、「ポート」、「スキーマ所有者」および「スキーマ・パスワード」に新しい値を入力し、「次」をクリックします。

      ノート:

      このページで複数のデータ・ソースが選択されている場合、選択されたすべてのデータ・ソースに対して同じフィールドの値を一度に変更できます。

    10. 「JDBCコンポーネント・スキーマ・テスト」ページで、(適用可能な場合は)次のいずれかを実行します:
      • すべての接続/コンポーネント・スキーマを選択して、「選択された接続のテスト」をクリックします。
      • テストの成功を確認してから「次」をクリックします。
    11. 「拡張構成」ページで、「管理サーバー」、「ノード・マネージャ」、「トポロジ」、「システム・コンポーネント」の順に選択して、「次」をクリックします。
    12. 「管理サーバー」ページで、「リスニング・アドレス」に管理サーバーが配置される新しいホストの更新された値を指定して、「次」をクリックします。
    13. 「ノード・マネージャ」ページで、ユーザー名とパスワードを確認して「次」をクリックします。
    14. 「管理対象サーバー」ページで、各管理対象サーバーの「リスニング・アドレス」および「リスニング・ポート」に更新された値を指定して、「次」をクリックします。
    15. 「クラスタ」ページで、クラスタを確認して「次」をクリックします。
    16. 「サーバー・テンプレート」ページで、「次」をクリックします。
    17. 「動的サーバー」ページで、「次」をクリックします。
    18. 「サーバーのクラスタへの割当」ページで、割当てを確認して「次」をクリックします。
    19. 「Coherenceクラスタ」ページで、「次」をクリックします。
    20. 「マシン」ページで、「ノード・マネージャ・リスニング・アドレス」および「リスニング・ポート」に更新された値を指定して、「次」をクリックします。
    21. 「サーバーのマシンへの割当」ページで、既存の割当てを確認します(ノード・マネージャでマシンが変更されていない場合)。それ以外の場合、管理対象サーバーと管理サーバーを適切なマシンにマップして、「次」をクリックします。
    22. 「仮想ターゲット」ページで、「次」をクリックします。
    23. 「パーティション」ページで、「次」をクリックします。
    24. 「システム・コンポーネント」ページで、システム・コンポーネントのリストを確認して「次」をクリックします。
    25. 「OHSサーバー」ページで(「システム・コンポーネント」ドロップダウン・リストから各インスタンスを選択して、すべてのOHSインスタンスに対してこれを行います)、「管理ホスト」、「管理ポート」、「リスニング・ポート」、「SSLリスニング・ポート」の値を確認し、「リスニング・アドレス」に更新された値を指定して、「次」をクリックします。
    26. 「マシンへのシステム・コンポーネントの割当」ページで、割当てを確認して「次」をクリックします。
    27. 「構成のサマリー」ページで、「作成」をクリックします。
    28. 「構成の進行状況」ページで、「次」をクリックします。
    29. 「構成の終了」ページで、「終了」をクリックします。

7.5 新しいデータベース情報によるJPS構成の更新

データベースを移行する場合、次のステップを使用して、いくつかの構成ファイルを変更する必要があります。ただし、データベースを移行しない場合は、この手順を無視して、UCMディレクトリを新しいホストにコピーする方法を記載した次の手順に進んでください。

  1. 新しいapphost1のターミナル・ウィンドウで、新しいホストのDOMAINHOME/config/fmwconfigディレクトリに移動します。
  2. jps-config.xmlファイルで、新しいデータベースの場所に関する新しいJDBC接続文字列情報でjdbc.urlプロパティを更新し、変更内容を保存します。
  3. jps-config-jse.xmlファイルで、次の変更を行って変更内容を保存します:
    • 新しいデータベースの場所に関する新しいJDBC接続文字列情報でjdbc.urlプロパティを更新します。
    • 新しいデータベースの場所に関するJDBC接続文字列情報でaudit.loader.jdbc.stringプロパティを更新します。

7.6 ホスト名の検証の無効化

ホスト名の検証を無効化するには:
  1. ターゲット・ホスト(この例ではapphost1)の管理サーバーを起動し、ステータスがRUNNINGと表示されるまで待機します。
  2. 管理サーバー・コンソールにログインします。本番モードで実行している場合、チェンジ・センターで「ロックして編集」をクリックします。
  3. 「環境」→「サーバー」→「AdminServer(管理サーバー)」に移動します。
  4. 「SSL」タブ、「詳細」を順にクリックします。
  5. 「ホスト名の検証」を「なし」に設定し、「保存」をクリックします。
  6. 「環境」→「サーバー」→WebCenter Contentサーバー1 (この例ではUCM_server1)に移動します。
  7. 「SSL」タブ、「詳細」を順にクリックします。
  8. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  9. 「環境」→「サーバー」→WebCenter Contentサーバー2 (この例ではUCM_server 2)に移動します。
  10. 「SSL」タブ、「詳細」を順にクリックします。
  11. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  12. 「環境」→「サーバー」→Oracle Inbound Refinery 1 (この例ではIBR_server1)に移動します。
  13. 「SSL」タブ、「詳細」を順にクリックします。
  14. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  15. 「環境」→「サーバー」→Oracle Inbound Refinery 2 (この例ではIBR_server2)に移動します。
  16. 「SSL」タブ、「詳細」を順にクリックします。
  17. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  18. 「環境」→「サーバー」→WebCenter Content ADF 1 (この例ではWCCADF_server1)に移動します。
  19. 「SSL」タブ、「詳細」を順にクリックします。
  20. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  21. 「環境」→「サーバー」→WebCenter Content ADF 2 (この例ではWCCADF_server2)に移動します。
  22. 「SSL」タブ、「詳細」を順にクリックします。
  23. 「ホスト名の検証」が「なし」に設定されていることを確認し、「保存」をクリックします。
  24. 本番モードで実行している場合、チェンジ・センターで「変更のアクティブ化」をクリックします。

7.7 共有ファイル・システムのマウントとWebCenter Contentの構成設定の調整

WebCenter Contentが移行された場合、この時点で共有ファイル・システムをマウントします。かわりに、それがクローニングされた場合、この時点で新しい場所から共有ファイル・システムをマウントします。

WebCenter Contentノードの構成設定を調整するには:
  1. 新しいホスト1 (この例ではapphost1)でDOMAINHOME/ucm/cs/bin/UCM_server1_intradoc.cfgファイルを開き、必要に応じて値を更新します。
    次を更新して変更内容を保存します:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  2. 新しい/ターゲット・ホスト(この例ではapphost1)でDOMAINHOME/ucm/cs/bin/intradoc.cfgファイルを開いて確認するか、必要に応じて値を更新します。
    次を更新して変更内容を保存します:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  3. SocketHostNameSecurityFilterの更新されたホスト名またはSocketHostAddressSecurityFilterのIPアドレスを含むようにWebCenter Contentのconfig.cfgファイルを編集します。
  4. ロード・バランサのアドレスを変更する場合、HttpServerAddressの更新されたホスト名を含むように共有ファイル・システムでWebCenter Contentのconfig.cfgを編集します。
  5. ロード・バランサの構成を、WebCenter Contentの新しいバックエンド・ホストのアドレスで編集します。
  6. 新しい/ターゲット・ホスト1 (この例ではapphost1)でDOMAINHOME/nodemanager/nodemanager.propertiesファイルを開きます。
  7. WindowsとWindowsではない別のオペレーティング・システムとの間で切替えを行う場合、weblogic.StartScriptNameエントリの値を変更して、変更内容を保存します。

7.8 UCM_server1が新しいホストで起動することの確認

  1. ターゲット・クラスタのapphost1で、ノード・マネージャを起動します。
  2. 「ドメイン構造」で、「環境」→「サーバー」に移動します。
  3. 「制御」タブで、WebCenter Content 1 (この例ではUCM_server1)のチェック・ボックスを選択します。
  4. 「起動」をクリックし、「はい」をクリックして確認します。
  5. 「サーバー」表の上で、「リフレッシュ」矢印をクリックして、UCM_server1の状態がRUNNINGに変更されていることを確認します。
  6. ブラウザを開き、新しいapphost1ホストのportal.htmが正常にロードされることを確認します。

7.9 packおよびunpack操作の実行による第2ノードへのドメインの拡張

  1. 既存の管理コンソール・ブラウザ・タブから、「環境」→「サーバー」に移動します。
  2. 「制御」タブで、WebCenter Content 1 (この例ではUCM_server1)のチェック・ボックスを選択します。
  3. 「停止」/「ただちに強制停止」をクリックします(強制停止を使用しない場合、実行状態の問題が発生します。)
  4. 「はい」をクリックして確認します。
  5. 「サーバー」表の上で、「リフレッシュ」矢印をクリックします。UCM_server1の状態がSHUTDOWNに変更されていることを確認します。
  6. ターミナル/コンソール・ウィンドウで、実行中の管理サーバーを停止します。
  7. 新しいapphost1で、ターミナル/コンソール・ウィンドウを開き、共有ファイル・システムに移動します。
  8. packコマンドを実行します:
    FMW_HOME/oracle_common/common/bin/pack.sh -managed=true -domain=/u01/oracle/user_projects/domains/cluster_domain -template=cluster.jar -template_name="cluster_domain"
  9. apphost2で、ターミナルを開きます。
  10. FMW_HOME/oracle_common/common/binディレクトリに移動し、unpackコマンドを実行します:
    ./unpack.sh -domain=/u01/oracle/user_projects/domains/cluster_domain -template=/<SHAREDFILESYSTEM>/cluster.jar

7.10 WebCenter Contentディレクトリの新しいホストへのコピー

WebCenter Contentディレクトリを新しいホストにコピーするために役立つ複数のツールがあります。この例では、あるLinuxホストから別のホストにコピーするためにrsyncを使用します。

WebCenter Contentディレクトリを新しいホストにコピーするには:
  1. ターゲット・ホスト(この例ではapphost2)のDOMAINHOMEディレクトリでmkdir ucmを実行します。
  2. DOMAINHOME/ucmディレクトリを、古い/ソース・ホスト(この例ではapphost2)から新しい/ターゲット・ホスト(この例ではapphost2)にコピーします。
    rsync -avzh ucm/ oracle@targetapphost2.domain.com:DOMAINHOME/ucm
In this case, target = apphost2

7.11 WebCenter Contentの構成設定の調整

WebCenter Contentノードの構成設定を調整するには:
  1. 新しいホスト2 (この例ではapphost2)でDOMAINHOME/ucm/cs/bin/<managedservername>_intradoc.cfgファイルを開き、必要に応じて値を更新します。
    次を更新して変更内容を保存します:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  2. 新しい/ターゲット・ホスト(この例ではapphost2)でDOMAINHOME/ucm/cs/bin/intradoc.cfgファイルを開いて確認するか、必要に応じて値を更新します。
    次を更新して変更内容を保存します:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  3. 新しいapphost2でDOMAINHOME/nodemanager/nodemanager.propertiesファイルを開きます。
  4. WindowsとWindowsではない別のオペレーティング・システムとの間で切替えを行う場合、weblogic.StartScriptNameエントリの値を変更して、変更内容を保存します。

7.12 UCM_server2が新しいホストで起動することの確認

  1. ターゲット・クラスタのapphost2で、ノード・マネージャを起動します。
  2. ターゲット・クラスタのapphost1で、管理サーバーを起動して、管理サーバーの状態がRUNNINGに変更されたら次のステップに進みます。
  3. 管理サーバー・コンソールの「ドメイン構造」で、「環境」→「サーバー」に移動します。
  4. 「制御」タブで、UCM_server2のチェック・ボックスを選択します。
  5. 「起動」をクリックし、「はい」をクリックして確認します。
  6. 「サーバー」表の上で、「リフレッシュ」矢印をクリックします。UCM_server2の状態がRUNNINGに変更されていることを確認します。
  7. ブラウザを開き、新しいapphost2ホストのportal.htmが正常にロードされることを確認します。
  8. 既存の管理コンソール・ブラウザ・タブから、「環境」→「サーバー」に移動します。
  9. 「制御」タブで、UCM_server2のチェック・ボックスを選択します。
  10. 「停止」/「強制停止」をクリックします(強制停止を使用しない場合、実行状態の問題が発生します。)
  11. 「はい」をクリックして確認します。
  12. 「サーバー」表の上で、「リフレッシュ」矢印をクリックします。UCM_server2の状態がSHUTDOWNに変更されていることを確認します。

7.13 Inbound Refineryの構成設定の調整

  1. 新しいホスト1 (この例ではapphost1)でDOMAINHOME/ucm/ibr/config/config.cfgファイルを開きます。
  2. HttpServerAddressの値として、更新されたホスト名およびポートを指定します。
  3. SocketHostNameSecurityFilterのホスト名またはSocketHostAddressSecurityFilterのIPアドレスを指定し、変更内容を保存します。
  4. 新しいホスト1 (この例ではapphost1)でDOMAINHOME/ucm/ibr/bin/MANAGEDSERVERNAME_intradoc.cfgファイルを開き、次を更新して変更内容を保存します。
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  5. 新しいapphost1ホストでDOMAINHOME/ucm/ibr/bin/intradoc.cfgファイルを開き、次を更新して変更内容を保存します。
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  6. 新しいホスト2 (この例ではapphost2)でDOMAINHOME/ucm/ibr/config/config.cfgファイルを開きます。
  7. HttpServerAddressの値として、更新されたホスト名およびポートを指定します。
  8. SocketHostNameSecurityFilterのホスト名またはSocketHostAddressSecurityFilterのIPアドレスを指定し、変更内容を保存します。
  9. 新しいホスト2 (この例ではapphost2)でDOMAINHOME/ucm/ibr/bin/MANAGEDSERVERNAME_intradoc.cfgファイルを開き、次を更新して変更内容を保存します。
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  10. 新しいapphost2ホストでDOMAINHOME/ucm/ibr/bin/intradoc.cfgファイルを開き、次を更新して変更内容を保存します。
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir

7.14 Inbound Refineryが新しいホストで正常に起動することの確認

  1. 管理サーバー・コンソールの「ドメイン構造」で、「環境」→「サーバー」に移動します。
  2. 「制御」タブで、IBR_server1およびIBR_server2のチェック・ボックスを選択します。
  3. 「起動」をクリックし、「はい」をクリックして確認します。
  4. 「サーバー」表の上で、両方のサーバーの「リフレッシュ」矢印をクリックします。IBR_server1およびIBR_server2の状態がRUNNINGに変更されていることを確認します。
  5. 両方のリファイナリにログインできることを確認します。

7.15 実行可能ファイルのスワップ・アウト

オペレーティング・システムが変更された場合やディレクトリ・パスが変更された場合、実行可能ファイルを置換するか、シンボリック・リンクを適切な内容で再作成する必要があります。次に、考えられるシナリオをいくつか示します。

7.15.1 WindowsからLinux

  1. 新しいLinuxホストのDOMAINHOME/ucm/cs/binディレクトリにある.exeファイルを削除します。
  2. DOMAINHOME/ucm/cs/binディレクトリで、FMWHOME/wccontent/ucm/idc/native/Launcher.shへのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  3. DOMAINHOME/ucm/cs/binディレクトリで、次の名前でDOMAINHOME/ucm/cs/bin/Launcher.shへのシンボリック・リンクを作成します:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WebLayoutEditor
    • WorkflowAdmin

    例:

    ln -s Launcher.sh Archiver
  4. DOMAINHOME/ucm/cs/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin.exe
    • IdcAdminNT.exe
    • NTProcCtrl.exe
  5. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  6. DOMAINHOME/ucm/cs/admin/bin/Launcher.shを指し示すようにIdcAdminおよびUnixProcCtrlのシンボリック・リンクを作成します:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  7. ドメイン内の他のコンテンツ・サーバー・クラスタ・ノードでステップ1から4までを繰り返します。
  8. リファイナリが移動された場合、DOMAINHOME/ucm/ibr/binディレクトリの.exeファイルを削除します。
  9. DOMAINHOME/ucm/ibr/binディレクトリで、FMWHOME/wccontent/ucm/idc/native/Launcher.shへのシンボリック・リンクを作成します。
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  10. DOMAINHOME/ucm/ibr/binディレクトリで、次の名前でDOMAINHOME/ucm/ibr/bin/Launcher.shへのシンボリック・リンクを作成します:
    • ComponentWizard
    • IdcCommand
    • IdcRefinery
    • Installer
    • SystemProperties
    • UnixProcCtrl

    例:

    ln -s Launcher.sh ComponentWizard
  11. DOMAINHOME/ucm/ibr/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin.exe
    • IdcAdminNT.exe
    • NtProcCtrl.exe
  12. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  13. DOMAINHOME/ucm/ibr/admin/bin/Launcher.shを指し示すようにIdcAdminおよびUnixProcCtrlのシンボリック・リンクを作成します:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  14. ドメイン内の他のリファイナリでステップ8から13までを繰り返します。

7.15.2 LinuxからLinux

  1. DOMAINHOME/ucm/cs/binディレクトリに移動して、Launcher.shシンボリック・リンクを削除します。
  2. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  3. 次の項目を削除します:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WeblayoutEditor
    • WorkflowAdmin
  4. Launcher.shを指し示すように様々なシンボリック・リンクを作成します:
    ln -s Launcher.sh Archiver
ln -s Launcher.sh BatchLoader
ln -s Launcher.sh ComponentTool
ln -s Launcher.sh ComponentWizard
ln -s Launcher.sh ConfigurationManager
ln -s Launcher.sh IdcAnalyze
ln -s Launcher.sh IdcCommand
ln -s Launcher.sh IdcServer
ln -s Launcher.sh IdcShell
ln -s Launcher.sh Installer
ln -s Launcher.sh IntradocApp
ln -s Launcher.sh RepositoryManager
ln -s Launcher.sh SystemProperties
ln -s Launcher.sh UnixProcCtrl
ln -s Launcher.sh UserAdmin
ln -s Launcher.sh WeblayoutEditor
ln -s Launcher.sh WorkflowAdmin
  5. DOMAINHOME/ucm/cs/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  6. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh
  7. DOMAINHOME/ucm/cs/admin/bin/Launcher.shを指し示すようにIdcAdminおよびUnixProcCtrlのシンボリック・リンクを作成します。
  8. ドメイン内の他のWebCenter Contentクラスタ・ノードでステップ1から4までを繰り返します。
  9. DOMAINHOME/ucm/ibr/binディレクトリに移動して、Launcher.shを削除します。
  10. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  11. 次の項目を削除します:
    • ComponentWizard
    • IdcCommand
    • IdcRefinery
    • Installer
    • SystemProperties
    • UnixProcCtrl
  12. DOMAINHOME/ucm/ibr/bin/Launcher.shを指し示すようにシンボリック・リンクを作成します:
    ln -s Launcher.sh ComponentWizard
ln -s Launcher.sh IdcCommand
ln -s Launcher.sh IdcRefinery
ln -s Launcher.sh Installer
ln -s Launcher.sh SystemProperties
ln -s Launcher.sh UnixProcCtrl
  13. DOMAINHOME/ucm/ibr/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  14. 新しい場所を使用してLauncher.shのシンボリック・リンクを作成します:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  15. DOMAINHOME/ucm/ibr/admin/bin/Launcher.shを指し示すようにシンボリック・リンクを作成します:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  16. ドメイン内の他のリファイナリでステップ9から15までを繰り返します。

7.15.3 LinuxからWindows

  1. DOMAINHOME/ucm/cs/binディレクトリに移動して、次の項目を削除します:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WebLayoutEditor
    • WorkflowAdmin
  2. FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exeをDOMAINHOME/ucm/cs/binディレクトリにコピーします
  3. DOMAINHOME/ucm/cs/bin/Launcher.exeを、次の名前でDOMAINHOME/ucm/cs/binディレクトリにコピーします:
    • Archiver.exe
    • BatchLoader.exe
    • ComponentTool.exe
    • ComponentWizard.exe
    • ConfigurationManager.exe
    • IdcAnalyze.exe
    • IdcCommand.exe
    • IdcServer.exe
    • IdcShell.exe
    • Installer.exe
    • IntradocApp.exe
    • RepositoryManager.exe
    • SystemProperties.exe
    • UserAdmin.exe
    • WebLayoutEditor.exe
    • WorkflowAdmin.exe
  4. DOMAINHOME/ucm/cs/bin/Launcher.exeファイルを削除します。
  5. DOMAINHOME/ucm/cs/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  6. FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exeファイルをDOMAINHOME/ucm/cs/admin/binディレクトリにコピーします
  7. DOMAINHOME/ucm/cs/admin/bin/Launcher.exeを、次の名前でDOMAINHOME/ucm/cs/admin/binディレクトリにコピーします:
    • IdcAdmin.exe
    • IdcAdminNT.exe
  8. DOMAINHOME/ucm/cs/admin/bin/Launcher.exeファイルを削除します。
  9. FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exeファイルをDOMAINHOME/ucm/cs/admin/binディレクトリにコピーします。
  10. ドメイン内の他のWebCenter Contentクラスタ・ノードでステップ1から4までを繰り返します。
  11. DOMAINHOME/ucm/ibr/binディレクトリに移動して、次の項目を削除します:
    • ComponentWizard
    • IdcCommand
    • IdcRefineryInstaller
    • Launcher.sh
    • SystemProperties
    • UnixProcCtrl
  12. FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exeファイルをDOMAINHOME/ucm/ibr/binディレクトリにコピーします。
  13. DOMAINHOME/ucm/ibr/bin/Launcher.exeを、次の名前でDOMAINHOME/ucm/ibr/binディレクトリにコピーします:
    • ComponentWizard.exe
    • IdcRefinery.exe
    • IdcRefineryNT.exe
    • Installer.exe
    • SystemProperties.exe
  14. DOMAINHOME/ucm/ibr/bin/Launcher.exeファイルを削除します。
  15. DOMAINHOME/ucm/ibr/admin/binディレクトリに移動して、次の項目を削除します:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  16. FMWHOME/wccontent/ucm/idcnative/windows-amd64/bin/Launcher.exeファイルをDOMAINHOME/ucm/ibr/admin/binディレクトリにコピーします。
  17. DOMAINHOME/ucm/ibr/admin/bin/Launcher.exeを、次の名前でDOMAINHOME/ucm/ibr/admin/binディレクトリにコピーします:
    • IdcAdmin.exe
    • IdcAdminNT.exe
  18. DOMAINHOME/ucm/ibr/admin/bin/Launcher.exeファイルを削除します
  19. FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/NtProcCtrl.exeファイルをDOMAINHOME/ucm/ibr/admin/binディレクトリにコピーします。
  20. ドメイン内の他のリファイナリでステップ11から19までを繰り返します。

7.16 Inbound Refineryの送信プロバイダ設定の調整

  1. 「ドメイン構造」で、「環境」→「サーバー」に移動します。
  2. 「制御」タブで、UCM_server1およびUCM_server2のチェック・ボックスを選択します。
  3. 「起動」をクリックし、「はい」をクリックして確認します。
  4. 「サーバー」表の上で、「リフレッシュ」矢印をクリックします。UCM_server1およびUCM_server2の状態がRUNNINGに変更されていることを確認します。
  5. WebCenter Contentインスタンスにログインします。
  6. 「管理」→「プロバイダ」ページで、apphost1のリファイナリに接続している送信プロバイダについて、「情報」をクリックします。
  7. 「編集」をクリックし、「サーバー・ホスト名」および「HTTPサーバー・アドレス」に新しい値を指定します。
  8. 「更新」をクリックし、apphost2のリファイナリに接続している送信プロバイダについて、「情報」をクリックします。
  9. 「編集」をクリックし、「サーバー・ホスト名」および「HTTPサーバー・アドレス」に新しい値を指定します。
  10. 「更新」をクリックします。
  11. UCM_server1およびUCM_server2管理対象サーバーを再起動します。

7.17 WebCenter Contentユーザー・インタフェースの構成設定の調整

WebCenter Contentユーザー・インタフェースを再構成するには:
  1. 「ドメイン構造」で、「環境」→「サーバー」に移動します。
  2. 「制御」タブで、WCCADF_server1およびWCCADF_server2のチェック・ボックスを選択します。
  3. 「起動」をクリックし、「はい」をクリックして確認します。
  4. 「サーバー」表の上で、「リフレッシュ」矢印をクリックします。WCCADF_server1およびWCCADF_server2の状態がRUNNINGに変更されていることを確認します。
  5. ロード・バランサが変更された場合、Fusion Middleware Controlにログインし、WebCenter Contentユーザー・インタフェースからWebCenter Contentへの接続を確立するために使用されるPropConnectionUrl mBeanの値を編集して、この値でロード・バランサの新しいアドレスを使用できるようにします。
    1. ページの左上隅にあるターゲット・ナビゲーションから、「WebLogicドメイン」→「<DOMAINNAME> - UI_cluster - WCCADF_server1」に移動し、WCCADF_server1管理対象サーバーを選択します。
    2. 「WebLogic Server」ドロップダウン・リストから、「WebLogic Server - システムMBeanブラウザ」を選択します。
    3. 「アプリケーション定義のMBean」→「oracle.adf.share.connections」→「サーバー: WCCADF_server1」→「アプリケーション: Oracle WebCenter Content - Web UI」→「ADFConnections」→「ADFConnections」→「WccConnection」→「WccAdfServerConnection」の順に移動します。
    4. ソケット・ポートでリスニングする新しいロード・バランサを含むようにPropConnectionUrlの値を更新して、「適用」をクリックします。
    5. 「アプリケーション定義のMBean」→「oracle.adf.share.connections」→「サーバー: WCCADF_server1」→「アプリケーション: Oracle WebCenter Content - Web UI」→「ADFConnections」の順に移動します
    1. 「操作」タブで、「保存」をクリックしてから「起動」をクリックすると、「操作は正常に実行されました。」というメッセージが表示されます。

7.18 Oracle HTTP Serverの構成

  1. 新しいapphost1で、ターミナルを開きます。
  2. DOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_1ディレクトリに移動します。
  3. テキスト・エディタでmod_wl_ohs.confファイルを開きます。
  4. apphost1およびapphost2の既存の値を新しい値に置換します。
  5. ファイルを保存してテキスト・エディタを終了します。
  6. DOMAINHOME/config/fmwconfig/components/OHS/ohs_1ディレクトリに移動します。
  7. テキスト・エディタでmod_wl_ohs.confファイルを開きます。
  8. apphost1およびapphost2の既存の値を新しい値に置換します。
  9. ファイルを保存してテキスト・エディタを終了します。
  10. 新しいapphost1のDOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_1/mod_wl_ohs.confを、新しいapphost2のDOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_2にコピーします。
  11. Fusion Middleware Controlにログインします。
  12. 「ターゲット・ナビゲーション」メニューを表示するため、左上隅にある「ターゲット・ナビゲーション」アイコンをクリックします。
  13. 「HTTP Server」セクションを展開して「ohs_1」を選択します。
  14. 「起動」をクリックして、「確認」メッセージが表示されたら次のステップに進みます。
  15. 左上隅にある「ターゲット・ナビゲーション」アイコンをクリックし、「ターゲット・ナビゲーション」メニューで「ohs_2」を選択します。
  16. 「起動」をクリックして、「確認」メッセージが表示されたら閉じます。

7.19 セキュリティ・プロバイダの構成

セキュリティ・プロバイダ・データをドメインの新しい場所に手動で転送できます。ドメイン・テンプレート・ビルダーは、オフライン・ユーティリティであり、組込みLDAPデータなどのセキュリティ・プロバイダ・データをドメイン・テンプレートにエクスポートしないため、これは必須です。

関連トピック

7.20 スタンドアロンJavaアプリケーションのデータベース情報の更新

データベースの場所が変更された場合:
  1. いずれかのクラスタ・ノードのDOMAINHOME/ucm/cs/binディレクトリから、SystemPropertiesアプリケーションを実行します。
  2. SystemPropertiesアプリケーション内で、「データベース」タブのデータベース情報を更新して、WebCenter ContentのbinディレクトリにあるスタンドアロンJavaアプリケーションを正常に起動できるようにします。

7.21 全体的な動作の検証

以前にどのスタンドアロンJavaアプリケーションも実行したことがない場合、スタンドアロンJavaアプリケーションがデータベースおよび関数と対話できるように、UserAdminアプレットを使用してローカルsysadminユーザーのパスワードをリセットし、SystemPropertiesを使用してjdbc接続を構成する必要があります。
移行が成功したことを確認するには:
  1. IdcAnalyzeを実行してエラーがないことを確認します。「構成」タブで、次を確認します:

    • 「データベース」が選択されています

    • 「データベース」→RevClassIDsが選択されています

    • 「データベース」→「データベースのクリーン」が選択解除されています

    • 検索索引が選択されています

    • 検索索引→「検索索引のクリーン」が選択解除されています

    • 「ファイル・システム」が選択されています

    • 「レポートの生成」が選択されています

    詳細は、『Oracle WebCenter Contentの管理』のContent Serverアナライザの使用に関する項を参照してください。
    エラーがレポートされたら、必要に応じて修正します。
  2. WebCenter Contentの新しいホスト名で他のアプリケーションの構成設定を更新します。