1. Oracle Fusion Middleware Infrastructureへのアップグレード
  2. アップグレード前の要件

2 アップグレード前の要件

Oracle Fusion Middleware Infrastructure 12c (12.2.1.3.0)へのアップグレードを開始する前に、アップグレード前のタスク(現在の環境のバックアップやクローニング、目的のシステムが動作保証要件を満たしていることの確認など)を実行する必要があります。

  • アップグレード前のチェックリスト
    アップグレード前のチェックリストは、アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に実行できるタスクを識別します。
  • 完全なバックアップの作成
    アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
  • テストのための本番環境のクローニング
    実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。
  • 動作保証およびシステム要件の確認
    ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをレビューする必要があります。
  • 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新
    アップグレードされる環境で強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定の場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。
  • 未使用データのパージ
    アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。
  • エディション・ベースの再定義のためのサーバー上でのエディションの作成
    エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.3.0)のデータベース・サーバーにエディションを作成する必要があります。
  • Upgrade Assistantを実行するための非SYSDBAユーザーの作成
    Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーはスキーマの変更に必要な権限は持っていますが、完全な管理者権限は持っていません。
  • カスタムsetDomainEnv設定のメンテナンス
    すべてのドメインには、動的に生成されたドメインおよびサーバーの起動スクリプト(setDomainEnvなど)があります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。
  • OIDセキュリティ・ストアでの認証なしSSLモードの使用方法
    SSLプロトコルでは、認証、整合性および機密保護を含むトランスポート層セキュリティがクライアントとサーバーとの間の接続に提供されます。SSL認証モードは、インスタンス固有の構成エントリ内のorclsslauthentication属性によって制御されます。デフォルトでは、Oracle Internet Directory(OID)はSSL認証なしモード(orclsslauthentication=1)を使用します。
  • OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除
    ポリシー・セット内のサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。
  • 事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行
    アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義済ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。

テストのための本番環境のクローニング

実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードします。

テストのために本番環境のクローンを作成することをお薦めします。ただし、必須ではありません。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。潜在的なアップグレードの問題を開発環境で特定しておくと、無駄な停止時間を排除できます。

ノート:

すべてのコンポーネントおよびオペレーティング・システムのクローニング手順について、このドキュメントでは説明していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有のものです。概略としては、アップグレード前のバージョンのコンポーネント・ドメインをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成し、アップグレードを実行します。
本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

  • アップグレードに関する問題を明らかにし、修正します。

  • エンドツーエンドのアップグレードを完了させる練習をします。

  • アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

  • アップグレードの完了までに必要な時間を理解します。

  • データベース・リソースの使用(一時表領域やPGAなど)について理解します。

ノート:

クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。

親トピック: アップグレード前の要件

カスタムsetDomainEnv設定のメンテナンス

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

注意:

アップグレード前にsetDomainEnvスクリプト(または他の起動スクリプト)に加えられた変更は、ドメインの再構成プロセスで再生成されるスクリプトにより上書きされます。別のファイルを作成して、アップグレード前にカスタマイズしたドメイン設定を格納してください。

たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。

ノート:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

親トピック: アップグレード前の要件

OIDセキュリティ・ストアでの認証なしSSLモードの使用方法

SSLプロトコルでは、認証、整合性および機密保護を含むトランスポート層セキュリティがクライアントとサーバーとの間の接続に提供されます。SSL認証モードは、インスタンス固有の構成エントリ内のorclsslauthentication属性によって制御されます。デフォルトでは、Oracle Internet Directory(OID)はSSL認証なしモード(orclsslauthentication=1)を使用します。

12c Infrastructureにアップグレードし、OIDをセキュリティ・ポリシー・ストアとしてOracle WebLogic Serverで使用している場合、デフォルトのSSLモードを変更する必要があります。Oracle Internet Directory 11gでは、SSL相互運用性モードはデフォルトで有効です。ただし、Oracle Internet Directoryは、SSL相互運用性モードが無効であることを前提として、JDKのSSLに完全に準拠しています。

Oracle Internet Directory (OID)における認証なしSSLモードのデフォルト使用は、介在者(MITM)攻撃を受けやすくなるため、本番環境ではお薦めできません。

ただし、認証なしSSLが必要で、WebLogic Serverがクライアントの場合は、アップグレード前に次のシステム・プロパティをweblogic.propertiesファイルに適用する必要があります。

  • -Dweblogic.security.SSL.AllowAnonymousCipher=true

  • -Dweblogic.security.SSL.ignoreHostnameVerification=true

ノート:

これらのプロパティを設定することにより、匿名暗号スイートが有効化され、ホスト名の検証チェックなしでクライアント接続が確立されるため、WebLogic Serverは介在者攻撃を受けやすくなる可能性があります。

WebLogic Server 12cでOIDを使用する場合は、サーバー認証またはクライアント/サーバーSSL認証の使用をお薦めします。

親トピック: アップグレード前の要件

OWSMポリシー・セットからのサーバー・インスタンス・スコープの削除

ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・インスタンス・スコープを使用するポリシー・セットがある場合は、12cへのアップグレード中に無効化されます。したがって、12cにアップグレードする前に、11gのすべてのポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。

詳細は、Oracle Fusion Middleware 11gリリース1 (11.1.1.7.0)のドキュメント・ライブラリのWebサービスのためのセキュリティおよび管理者ガイドのポリシー・セットの編集を参照してください。

親トピック: アップグレード前の要件

事前定義ドキュメントのクローニングおよびOWSMポリシー・アタッチメントの移行

アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義済ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。

最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOWSMリポジトリのアップグレードを参照してください。

親トピック: アップグレード前の要件