システムを静止状態にしてバックアップを作成したら、アップグレード手順を安全に開始できます。
データベースをアップグレードした場合は、DBA に依頼して、スキーマ情報やストアード・プロシージャーなどの保管されたデータベース情報をインポートします。手順については、データベース・サーバーの資料を参照してください。
4.3 以前のインストール・ファイルをバックアップすると、InterChange Server の新規バージョンをインストールする準備が整います。InterChange Server の新規バージョンをインストールするには、InterChange Server、XML データ・ハンドラー、e-Mail アダプター、 およびその他のサポート製品のインストールを参照してください。
注:
InterChange Server の 4.2.2 バージョンからアップグレードする場合は、オブジェクト・リクエスト・ブローカーを構成する必要はありません。サーバー・スクリプトのアップグレードの説明に進んでください。
InterChange Server の 4.2.2 リリースの時点で、VisiBroker ORB は IBM Java ORB に置き換えられました。 ハードウェアとサポートするソフトウェアのアップグレードで説明したように、ICS インストーラーは、ICS インストール・プロセスの一環として、IBM Java ORB および IBM Transient Naming Server を自動的にインストールします。ただし、次の作業を実行して、IBM Java ORB が適切に構成されていることを確認する必要があります。
Visibroker ORB には、ORB を調整するために各種の ORB 関連プロパティーが存在していました。カスタマイズされたスクリプトやソフトウェアでこれらのプロパティーを使用していた場合は、これらのプロパティーが IBM Java ORB に対して適切に設定されていることを確認する必要があります。表 32 には、いくつかの VisiBroker ORB プロパティーと、これに相当する IBM Java ORB での名前を示します。
VisiBroker ORB プロパティーを参照するカスタマイズされたスクリプトが、4.2.2 以前のインストール・システムに存在する場合は、これらのプロパティーを、後出の表 32 に示す IBM ORB の相当プロパティーに置換してください。
表 32. IBM ORB プロパティーと等価の VisiBroker プロパティー
IBM ORB プロパティー | 等価の VisiBroker プロパティー | 説明 |
---|---|---|
org.omg.CORBA.ORBInitialHost | vbroker.agent.addr | IBM Transient Naming Server (tnameserv) が稼働しているマシンの IP アドレスまたはホスト名を指定します。このプロパティーのデフォルト値は localhost です。 |
org.omg.CORBA.ORBInitialPort | vbroker.agent.port | IBM Transient Naming Server の listen 先ポートを指定します。 |
com.ibm.CORBA.ListenerPort | vbroker.se.iiop_tp.scm.iiop_tp. listener.port | ORB サーバーが着信要求を listen するポート。このプロパティーを指定すると、ORB はORB.init() の実行時に listen を開始します。デフォルトでは、このポートは動的に割り当てられます。4.3 では、VisiBroker のプロパティー名 OAport が引き続きサポートされます。 |
com.ibm.CORBA.LocalHost | vbroker.se.iiop_tp.host | このプロパティーは、ORB が稼働しているマシンのホスト名 (または IP アドレス) を表します。ローカル・ホスト名は、サーバーのホスト名をリモート・オブジェクトの IOR に置くために、サーバー・サイド ORB が使用します。このプロパティーを設定しなかった場合は、InetAddress.getLocalHost(). getHostAddress(); を呼び出すことにより、ローカル・ホストが検索されます。4.3 では、VisiBroker のプロパティー名 OAipAddr が引き続きサポートされます。 |
com.ibm.CORBA.ThreadPool. MaximumSize | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax | Server Connection Manager によって作成可能なスレッドの最大数を指定します。デフォルト値 0 は、制限がないことを意味します。4.3 では、VisiBroker のプロパティー名 OAthreadMax が引き続きサポートされます。 |
com.ibm.CORBA.ThreadPool. InactivityTimeout | vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle | アイドル状態のスレッドが破棄されるまでの時間を (秒単位で) 指定します。4.3 では、VisiBroker のプロパティー名 OAthreadMaxIdle が引き続きサポートされます。 |
com.ibm.CORBA.BufferSize | vbroker.orb.streamChunkSize | 最初の試行でソケットから読み取られる (GIOP メッセージとしての) バイト数。バッファー・サイズを増やすと、1 回の試行でメッセージ全体を読み取る確率が高くなり、パフォーマンスの向上につながります。デフォルトは 2048 です。 |
InterChange Server の 4.2.2 以前のバージョンでは、InterChange Server によって登録されたすべての ORB オブジェクトを識別するために、VisiBroker ORB に osfind ツールが用意されていました。IBM Java ORB には、このために CosNameServer_Dump と呼ばれるツールが用意されています。このツールは、ProductDir/bin ディレクトリーにあります。詳しくは、「システム管理ガイド」を参照してください。
InterChange Server の 4.2.2 リリースの時点で、VisiBroker ORB は IBM Java ORB に置き換えられました。この変更により、HA のために以前使用されていた VisiBroker Smart Agent は、Transient Naming Server に置き換えられました。HA 環境に合うように IBM ORB を構成することの詳細については、オブジェクト・リクエスト・ブローカー (ORB) のインストールおよび構成を参照してください。
既存の InterChange Server にカスタム・ファイルを作成した場合は、次のファイルを評価して、これらのファイルをアップグレードする必要があるかどうかを判断する必要があります。
InterChange Server の 4.2.2 リリースでは、VisiBroker ORB から IBM Java ORB への移行に対応し、IBM JRE をサポートするために、すべての始動スクリプトが変更されました。
任意のサーバー始動スクリプトをカスタマイズし、4.2.2 以外のリリースから 4.3 にアップグレードしている場合は、新規のスクリプトにも同様な変更を行う必要があります。これらの始動スクリプトには、次のようなカスタマイズが必要な場合があります。
例えば、カスタマイズしたデータ・ハンドラーがある場合は、その .jar ファイルを CLASSPATH 変数に追加します。
アップグレード・プロセスとそのテストが完了したら、InterChange Server が実動モードで始動するように、サーバー始動スクリプトから -design オプションを除去できます。
ツール構成ファイル cwtools.cfg のタスクの 1 つは、カスタムの .jar ファイルを提供して、これをコンパイル時に組み込むことです。カスタムの .jar ファイルを作成した場合は、CLASSPATH 変数の codeGeneration セクションに追加する必要があります。cwtools.cfg ファイルは、ツールが稼働している Windows マシンの次のディレクトリーにあります。
ProductDir¥bin
すべての環境変数が単一の CWSharedEnv.sh ファイルに設定されるようになりました。すべての始動スクリプトでは、その起動プロシージャーの一部としてこのファイルが読み取られます。ICS システム規模のプロパティー (IBM Java ORB のプロパティーなど) が設定されるのは、このファイル内です。アップグレード・プロセスの一環として、次に示すシステム規模のプロパティーが正常に設定されていることを確認してください。
CWSharedEnv.sh ファイルの詳細については、「システム管理ガイド」を参照してください。
リポジトリー表 (スクリプト、データベース表、ストアード・プロシージャーなど) を使用する完全にカスタムのコンポーネントがある場合は、各コンポーネントを評価して、コンポーネントのアップグレードが必要かどうかを判断する必要があります。例えば、新規リリースで変更されたリポジトリー表をストアード・プロシージャーが使用する場合は、このストアード・プロシージャーを変更して、リポジトリー表の新構造と連動する必要があります。
インストールが完了した後は、必要なサポート・ソフトウェアがすべて稼働していれば、既存バージョンのリポジトリーを使用して新規バージョンの InterChange Server を始動できます。インプレース・アップグレードによってデータベースをアップグレードした場合は、ICS を元のリポジトリーにポイントする必要があります。ICS を始動するには、次の手順を実行します。
サポート・ソフトウェアが稼働していることを確認する方法については、サポート・ソフトウェアの始動および IBM ORB Transient Naming Server の始動を参照してください。
InterChange Server を始動する方法については、InterChange Server の始動および System Manager の始動を参照してください。
ProductDir ディレクトリーの InterchangeSystem.log ファイルを調べると、始動が正常であったことを確認できます。
それでも失敗の原因が不明であれば、修正したり、バックアップから復元したりする前に、IBM ソフトウェア・サポートにお問い合わせください。
InterChange Server リポジトリーは、InterChange Server コンポーネントについてのメタデータを保持するデータベースです。アップグレードは、インプレース・データベース・アップグレードを使用するか、または使用しないで実行できます。4.3 ICS インストーラーは、ICS リポジトリーの内容を自動的にはアップグレードしません。ただし、インプレース・アップグレードを使用すると、前の手順で ICS を始動した場合は、ICS により 4.3 以前のリポジトリーのスキーマが 4.3 での変更内容よってアップグレードされます。アップグレード・プロセスのこの時点で、次のどちらのオブジェクトをリポジトリーにロードするかを決定する必要があります。
インストーラーは、ICS のさまざまなコンポーネントの適切な入力ファイルを、ProductDir および ProductDir のさまざまなサブディレクトリー (/repository など) にコピーします (ProductDir は、新規 4.3 リリースの製品ディレクトリーです)。これらの入力ファイルには、4.3 ICS リリースの新規コンポーネントが格納されています。
repos_copy を使用して ICS リポジトリーをバックアップした場合は、既存の ICS リリースのコンポーネントに対応するリポジトリー・オブジェクトが格納されているリポジトリー・ファイルが 1 つ以上存在します。
接続された Windows マシンで稼働する System Manager の「InterChange Server コンポーネント管理」ビューを使用すると、サーバーにロードされたコンポーネントを参照できます。
このセクションで説明する手順は、データベースのインプレース・アップグレードを使用しないで InterChange Server をアップグレードする場合にのみ必要になります。
ICS インストール・プロセスの一環として、これらの ICS データベースの名前は「InterChange Server 構成ウィザード」で指定済みです。ICS の新規バージョンを始動したときに、サーバーはリポジトリー・データベースのスキーマをアップグレード済みです。この新規リポジトリーを初期化するには、既存のリポジトリー・オブジェクトをロードする必要があります。
リポジトリーのロードを準備するには、次の手順を実行します。
ProductDir/DLMs/classes/NativeMaps
ProductDir/collaborations/classes/UserCollaborations
ここで、ProductDir は、新規の 4.3 リリースの製品ディレクトリーです。この手順により、既存のマップおよびコラボレーションの .class ファイルが、新規の 4.3 ディレクトリー構造に確実に置かれるようになります。
リポジトリーをロードするこれらの各手順は、以降のセクションで説明します。
このセクションの手順は、バージョン 4.1.1 からアップグレードする場合にのみ必要になります。
(リポジトリー・ファイルと呼ばれる) 既存の repos_copy バックアップ・ファイルを調べて、すべての値が新規リポジトリーに関連していることを確認します。既存のリポジトリー・ファイルのバックアップ・コピーを作成し、元のリポジトリー・ファイルを編集することにより、次の情報を修正します。
関係をインポートする場合は、次の属性が、それぞれの関係ごとにリポジトリー・ファイルの内部で有効であることを確認する必要があります。
これらの属性が、repos_copy による ICS リポジトリーへのインポート時に検出できないデータベースを示す場合、InterChange Server はインポート操作全体をロールバックします。ただし、これらの属性をリポジトリーごとに削除すると、InterChange Server はリポジトリーをデフォルトのリレーションシップ・データベースとして使用します。
4.1.1 フォーマットのデータベース接続プールは新規リポジトリーにインポートできません。したがって、リポジトリー・ファイルからはすべての接続プールを削除する必要があります。ICS インスタンスをアップグレードしたら、これらの接続プールは、接続されている Windows マシンの System Manager 内部で再作成する必要があります。
既存のリポジトリー・オブジェクトをインポートする前に、4.3 リポジトリーに既に存在している可能性のある重複オブジェクトを削除する必要があります。この手順が必要な理由は、repos_copy ユーティリティーが、以前のフォーマットをリポジトリーにインポートするときに -ar オプションや -arp オプション (重複オブジェクトを処理するオプション) を認識しないからです。ICS は、リポジトリー・ファイル内に重複オブジェクトを検出すると、インポート操作全体をロールバックします。
これらのリポジトリー・オブジェクトを削除するには、repos_copy ユーティリティーの -d オプションを使用します。例えば、次の repos_copy コマンドを実行すると、リポジトリーの内容が削除されます。
repos_copy -sNewICSinstance -uadmin -ppasswd -d
この repos_copy コマンドの詳細について、以下に説明します。
リポジトリー・ファイルの内容をリポジトリーにロードするには、repos_copy ユーティリティーを使用します。InterChange Server システムのバックアップで説明したように、repos_copy ユーティリティーの -o オプションを使用して、既存のリポジトリー・オブジェクトをエクスポートし、1 つ以上のリポジトリー・ファイルを作成しておきます。これが終了したら、repos_copy の -i オプションを使用して、これらのリポジトリー・オブジェクトを新規のリポジトリーにインポートします。
例えば、Repository411.txt というリポジトリー・ファイルがある場合を考えます。次の repos_copy コマンドを実行すると、このファイル内のすべてのリポジトリー・オブジェクトがロードされます。
repos_copy -iRepository411.txt -sserverName -uuserName -ppassword -r*
この repos_copy コマンドの詳細について、以下に説明します。
既存のリポジトリー・オブジェクトが新規のリポジトリーに格納されたら、さらに追加の手順を実行して、コラボレーション・テンプレートおよびマップのアップグレードを完了する必要があります。詳しくは、コラボレーション・テンプレートおよびマップのアップグレードの完了を参照してください。