WebSphere Application Server バージョン 6.1 へのマイグレーションのプロセスを開始する前に、 注意する必要がある考慮事項があります。
まず、バージョン 5.x または 6.0.x デプロイメント・マネージャーを、拡張されていないバージョン 6.1.x デプロイメント・マネージャーにマイグレーションした後で、対象のデプロイメント・マネージャーを拡張します。
新しいスタンドアロン・アプリケーション・サーバー・プロファイルを該当するフィーチャー・パックがインストールされているバージョン 6.1.x で作成し拡張することができます。
新しいプロファイルを該当するフィーチャー・パックがインストールされているバージョン 6.1.x で作成し拡張した後で、新規ノードを拡張されたデプロイメント・マネージャーを持つバージョン 6.1.x セルに追加することができます。
こうすることで、システムにすべての必要な前提条件と WebSphere Application Server の新しいレベルのサポートが備わります。
API および仕様マイグレーション を参照してください。
Solaris x64 では、WebSphere Application Server バージョン 6.0.2 は、基幹プラットフォームが 64 ビットであっても 32 ビットのアプリケーションとして稼働します。これは、基幹となる Java 仮想マシンが 32 ビットであるためです。WebSphere Application Server バージョン 6.1 は、基幹となる Java 仮想マシンが 64 ビットであるため 64 ビットのアプリケーションとして稼働します。バージョン 6.0.2 用に 32 ビット環境でコンパイルされた JNI アプリケーションは、バージョン 6.1 の 64 ビット環境で実行することはできません。
Web サーバー構成のマイグレーション を参照してください。
以前のレベルの WebSphere Application Server は、引き続きより高水準な前提条件レベルで実行されます。
特に、WebSphere Application Server バージョン 5.x または 6.0.x と共存させてインストールする場合は、 両方のバージョンのデフォルト・デーモン・ポート定義を同じにする点に注意してください。
デフォルト・ポート情報について詳しくは、WebSphere Application Server バージョンにおけるポート番号設定 を参照してください。
共存 を参照してください。
この混合リリース環境では、旧リリース・レベルのサーバーでできることに 制限があります。 詳しくは、アプリケーション・サーバーの作成 を参照してください。 クラスターおよびクラスター・メンバーの作成にも制限がある場合があります。詳しくは、 クラスターの作成 を参照してください。
構成上の問題を回避するには、デフォルト・ロケーションを使用する代わりに、 サーブレット API を使用してファイル・ロケーションを制御します。
新規セル名でプロファイルを作成すると、 マイグレーションは失敗します。
JSP オブジェクトが構成されているレベルをバージョン 6.1 がサポートしない場合、 マイグレーション・ツールは出力中にそのオブジェクトを認識して、ログに記録します。
Java 仮想マシン設定 を参照してください。
これまでに使用したヒープ・サイズがこれより小さい場合は、 デフォルトのヒープ・サイズ (50) を使用できます。
Cloudscape データベースのマイグレーション を参照してください。
こうすることで、システムにすべての必要な前提条件と WebSphere Application Server の新しいレベルのサポートが備わります。
マイグレーション後に JMS アプリケーションを手動でインストールし、 WebSphere Application Server バージョン 6.1 JMS プロバイダーを使用するよう再構成する必要があります。
セキュリティーが WebSphere Application Server バージョン 6.0.1 に対して使用不可である場合、 この要件は適用されません。 このマイグレーションにおける、特定のサービス・レベル要件は他にありません。
STEPLIB=BOSS.VICOM.W000020.SBBOLPA:$STEPLIB STEPLIB=BOSS.VICOM.W000020.SBBOLD2:$STEPLIB STEPLIB=BOSS.VICOM.W000020.SBBOLOAD:$STEPLIB export STEPLIB
したがって、 既存の構成を別の z/OS LPAR にマイグレーションすることはできません。また、WebSphere Application Server バージョン 6.1 の マイグレーション・ユーティリティーを使用して、 z/OS 以外のオペレーティング・システムとの間でマイグレーションすることもできません。
カスタマイズ・ダイアログまたは z/OS マイグレーション管理ツールを使用してマイグレーション・ジョブを生成し、 生成された指示に従ってそれらのジョブをサブミットする必要があります。
API および仕様マイグレーション を参照してください。
Web サーバー構成のマイグレーション を参照してください。
以前のレベルの WebSphere Application Server は、引き続きより高水準な前提条件レベルで実行されます。
WebSphere Application Server バージョン 5.x、6.0.x、および 6.1 では、一部のコードを LPA (SBBOLPA) 内に配置する必要があります。 さらに、パフォーマンス上の理由から、追加製品コード (SBBOLOAD) を LPA 内に配置する必要があります。 ただし、名前の競合により、複数のバージョンの製品コードを同時に LPA に配置することはできません。
共存をサポートするには、リンク・パック域、リンク・リスト、および STEPLIB を参照して、 LPA と STEPLIB を適切にセットアップしてください。
特に、WebSphere Application Server バージョン 5.x または 6.0.x と共存させてインストールする場合は、 両方のバージョンのデフォルト・デーモン・ポート定義を同じにする点に注意してください。
デフォルト・ポート情報について詳しくは、デフォルトのポート割り当て を参照してください。
共存 を参照してください。
この混合リリース環境では、旧リリース・レベルのサーバーでできることに 制限があります。 詳しくは、アプリケーション・サーバーの作成 を参照してください。 クラスターおよびクラスター・メンバーの作成にも制限がある場合があります。詳しくは、 クラスターの作成 を参照してください。
同じ LPAR 上に複数の WebSphere Application Server バージョン 5.0.x ノード (デプロイメント・マネージャーを含む) がある場合は、すべてのノードを 同時に WebSphere Application Server バージョン 6.1 にマイグレーションしなければなりません。 すべてのノードを順次マイグレーションしてから、LPAR 内の WebSphere Application Server バージョン 6.1 ノードを始動してください。
カスタマイズ・ダイアログ内の製品ファイル・システム・パスのデフォルト値を使用して Network Deployment 環境を構成する場合、 結果的に、すべてのノードが、製品ファイル・システムのマウント・ポイントを直接ポイントすることになります。 このため、中断なしの方法で保守のローリングを行うことはほぼ不可能になります。 この方法でセルを構成する場合、製品ファイル・システムにサービスを適用すると、すべてのノードが同時に影響を受けます。 また、この方法で複数のセルを構成する場合、製品ファイル・システムにサービスを適用すると、すべてのセルが同時に影響を受けます。
各ノードの構成ファイル・システムと、その製品ファイル・システムの実際のマウント・ポイント間で、 「中間シンボリック・リンク」と呼ぶものを指定できます。 この方法については、ホワイト・ペーパー「WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance」で説明しています。
この問題と、その保守の適用との関係について詳しくは、 ホワイト・ペーパー「Washington Systems Center Sample WebSphere for z/OS ND Configuration」を参照してください。 既存の構成 HFS を、中間シンボリック・リンクを使用するよう更新することを可能にするユーティリティーの 取得および使用について詳しくは、「WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links」の指示を参照してください。
通常、ユーザーがトレースを使用可能にしない限り、マイグレーションからのバッチ・ジョブ出力は非常に小さなものになります。 トレース出力サイズは、トレースを使用可能にしたマイグレーションのパーツによって異なります。 最大のトレース・ プロデューサーは、マイグレーションの WASPostUpgrade フェーズです。一般的に、このフェーズについては、 約 30 MB のトレース出力を確認できます。
マイグレーションするバージョン 5.x または 6.0.x 構成で DB2 for zOS ローカル JDBC プロバイダー (RRS) を使用する場合、 バージョン 6.1 にマイグレーションする前、またはマイグレーションした直後に、DB2 Universal JDBC Driver プロバイダーを使用するよう構成を変更する必要があります。 バージョン 6.1 マイグレーション・ツールは、プロバイダーをマイグレーションしません。
MIGR0442W: DB2 for zOS Local JDBC Provider (RRS) jdbc プロバイダーをマイグレーションしていません。 手動で DB2 Universal Driver プロバイダーを作成し、置き換えてください。 詳細については、DB2 の資料を参照してください。
DSRA8213W: JDBC プロバイダー DB2 for zOS Local JDBC Provider (RRS) は、WebSphere Application Server ではサポートされなくなりました。 アプリケーションでは DB2 Universal JDBC Driver Provider Type 2 を使用する必要があります。
この場合、バージョン 6.1 マイグレーション・ツールが DB2 Universal JDBC Driver プロバイダーに対する マイグレーションを処理するので、マイグレーション後にアクティビティーを行う必要はありません。
バージョン 5.x または 6.0.2 製品のインフォメーション・センターを検索し、 WebSphere Application Server for z/OS 用に DB2 Universal JDBC Driver プロバイダーを 構成する方法に関する情報を見つけます。
このツールは、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーへ、 1 度に 1 つのノードずつマイグレーションする Jython スクリプトです。 ツールに付属するホワイト・ペーパーに、ツールを実行して構成をマイグレーションする前に、 DB2 Universal JDBC Driver をインストールおよび構成する方法に関する説明があります ツールおよびホワイト・ペーパーは、製品のサポート・サイト、http://www.ibm.com/support/docview.wss?uid=swg27007826 から入手可能です。
詳しくは、DB2 Universal JDBC Driver を使用した DB2 for z/OS へのアクセス を参照してください。
このツールは、DB2 for zOS ローカル JDBC プロバイダー (RRS) から DB2 Universal JDBC Driver プロバイダーへ、 1 度に 1 つのノードずつマイグレーションする Jython スクリプトです。 ツールに付属するホワイト・ペーパーに、ツールを実行して構成をマイグレーションする前に、 DB2 Universal JDBC Driver をインストールおよび構成する方法に関する説明があります ツールおよびホワイト・ペーパーは、製品のサポート・サイト、http://www.ibm.com/support/docview.wss?uid=swg27007826 から入手可能です。
「Enabling Trusted Applications」オプションを 使用すると、WebSphere Application Server for z/OS ランタイムは、 アプリケーション・コードの代わりに、特定の特権命令を実行できるようになります。 このオプションは、LocalOS レジストリーまたは SAF 許可を使用する、 すべての WebSphere Application Server for z/OS サーバーに対して、必須となります。
これにより、管理者とシステム・セキュリティー管理者の両方が、 このフィーチャーを使用するかどうかを決定できるようになります。 この実装によって、アプリケーションが どの ID を前提とするかについても制限されます。
WebSphere Application Server の 前のバージョンからマイグレーションする場合に、 これらのフィーチャーが必要なときは、 必要な SAF プロファイルを作成する必要があります。 これらのプロファイルが存在せず、 正しくセットアップされていない場合は、LocalOS ユーザー・レジストリー または SAF 許可を使用するセルを、バージョン 6.1 で起動しようとしても、 失敗します。
BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name
RDEFINE FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(READ) SETROPTS RACLIST(FACILITY) REFRESH
SAF 機能プロファイルである cluster_name は、 クラスター化されていないサーバーの クラスター遷移名によって置換されます。 セル内のすべてのサーバーで 「Enabling Trusted Applications」を使用可能にする場合は、 クラスター名をワイルドカード (*) に置き換えます。
詳しくは、System Authorization Facility のクラスおよびプロファイル を参照してください。
BBO.SYNCID.cell_shortname.cluster_transition_nameこれを実行するために使用する RACF コマンドは、次の例のようになります。
RDEFINE FACILITY BBO.SYNCID.cell_shortname.cluster_transition_name UACC(NONE) PERMIT FACILITY BBO.SYNCID.cell_shortname.cluster_transition_name ID(controller_userid) ACCESS(CONTROL) SETROPTS RACLIST(FACILITY) REFRESH
クラスター化されていないサーバーのクラスター遷移名によって、 クラスター名が置換されます。 セル内のすべてのサーバーで 「Sync to OS Thread Allowed」を使用可能にする場合は、 クラスター名をワイルドカード (*) に置き換えます。
コントローラーのユーザー ID が BBO.SYNC プロファイルへの 読み取りアクセス権を持っていて、com.ibm.websphere.security.SyncToOSThread 変数が true に設定されている場合、 アプリケーションは Sync to OS Thread を要求します。 新規 ID が BBO.SYNC.servant_user_ID SAF SURROGAT プロファイルへの読み取りアクセス権を持っている限り、 アプリケーションは、 呼び出し元の ID または役割に関連するユーザー ID のいずれかが、 リソースにアクセスするものと想定します。
コントローラーのユーザー ID が BBO.SYNC プロファイルへの 制御アクセス権を持っていて、com.ibm.websphere.security.SyncToOSThread 変数が true に設定されている場合、 アプリケーションは Sync to OS Thread を要求します。 アプリケーションは、呼び出し元の ID または 役割に関連するユーザー ID のいずれかが、 リソースにアクセスするものと想定します。 SURROGAT プロファイルは、チェックされません。
詳しくは、Application Synch to OS Thread Allowed を参照してください。
Java 仮想マシン設定 を参照してください。
これまでに使用したヒープ・サイズがこれより小さい場合は、 デフォルトのヒープ・サイズ (50) を使用できます。
Cloudscape データベースのマイグレーション を参照してください。