WAS V6/V7へのマイグレーション資料リンクおよび既知の考慮点 (WAS-08-050)

更新ログ

(2009/05/14 10:34) V7証明書自動更新機能について説明追加
【概要】
2008年9月26日をもちまして、WebSphere Application Server(WAS) V5.1のサポートが終了となりました。
現在V5.1以前のバージョンを使用している場合は、早急なバージョンアップが推奨されます。
本技術速報では、WAS V6/V7へのマイグレーションに関する資料リンクと既知の考慮点についてそれぞれまとめています。

I. WAS V6.xへのマイグレーション
1. WAS V6.xへのマイグレーション関連資料リンク
2. マイグレーションにおける既知の考慮点

II. WAS V7.0へのマイグレーション
1. WAS V7.0へのマイグレーション関連資料リンク
2. マイグレーションにおける既知の考慮点

【対象】
・WAS V5.1以前のバージョンからWAS V6.xへのマイグレーション
・WAS V6.1以前のバージョンからWAS V7.0へのマイグレーション

【I. WAS V6.xへのマイグレーション】

【I-1. WAS V6.xへのマイグレーション関連資料リンク】
WAS V6.xへのマイグレーションに関する資料をご紹介します。
WAS V6.1 InfoCenter
WAS V6.0 InfoCenter
WebSphere Application Server Version 6.1へのマイグレーションガイド
WebSphere Application Server V6.0 管理ガイド-第3部　マイグレーション・ガイド
Knowledge Collection: Migrating to (or from) WebSphere Application Server

【I-2. マイグレーションにおける既知の考慮点】
マイグレーションを実施するにあたって注意すべき考慮点をご紹介します。

[読み取り書き込みタイムアウト]
大容量のデータをアップロード・ダウンロードする際には、HTTPトランスポートチャネルの書き込みタイムアウト・読み取りタイムアウトにも注意を払ってください。
これらはWASからデータを入出力する際のタイムアウト値になり、デフォルトでは60秒に設定されています。
WAS V6のHTTPトランスポート・チャネルの書き込みタイムアウト設定における注意事項

[OSをAIX6.1にバージョンアップする際の考慮点]　　
WAS V6.1/V6.0.2は、AIX V6.1をサポートしています。
下記リンクにAIX V6.1上にWAS V6.1を導入する際の注意点および既知エラー情報とその回避策がまとめられています。
WAS V6.1/V6.0.2は、AIX V6.1をサポートします

[プラグインの生成と伝播について]
IHSが読み込むプラグイン構成ファイルは、httpd.confで指定します。
これはプラグインのインストール際に指定しますが、必要に応じて変更することが可能です。
セルにWebサーバーを統合する際にはIHSのインストール・ルート、プラグインのインストール・ルート、プラグイン構成ファイルの伝播先を指定します。
デフォルトではDeployment Manager(DM)はプラグイン構成ファイルを自動生成し、Webサーバーのプロパティーに指定された伝播先に対して自動伝播します。
DMが生成するプラグイン構成ファイルはIHS:WASが1:N構成となる構成ファイルですので、1:1構成をとる場合はGenPluginCfgコマンドを使用してプラグイン構成ファイルを生成するか、DMが生成したプラグイン構成ファイルを手動で編集して1:1構成用にする必要があります。
ただし、そのままですとDMが生成するプラグイン構成ファイルによって上書きされますので、プラグインの自動生成と自動伝播をオフにし、さらに、作成したプラグイン構成ファイルを独自のディレクトリに配置して、httpd.confでそのファイルを指定するようにするようにしてください。
なお、WAS V6.1ではWebサーバーをセルに統合して管理することができます。
WAS V6.1による基幹システム設計ワークショップ 04 運用設計 P17-21

[ND版とBase版のマイグレーションの違い]
ND版の場合にはBASE版とは異なり、アプリケーション･サーバーだけでなくデプロイメント・マネージャーもマイグレーションする必要があります。
デプロイメント・マネージャーをマイグレーションする場合、WAS V6.xのセル名を旧バージョンのセル名と一致させる必要があります。
新規セル名でプロファイルを作成すると、マイグレーションは失敗します。
また、統合ノードをマイグレーションする場合には、WAS V6.xのセル名およびノード名を、旧バージョンのセル名およびノード名と一致させる必要があります。

[changeHostNameコマンドの利用(WAS6.1のみ)]
WAS V6.1の新機能として、wsadminのAdminTaskオブジェクトのchangeHostNameコマンドによってWASの構成情報に含まれるホスト名/IPアドレスを変更することが出来ます。
changeHostNameコマンドではDMが持つ構成情報(<DM_PROFILE_ROOT>/config/cells/<cell>/nodes/<node>以下のファイル)に含まれるホスト名/IPアドレスを変更しますので、その後DMと各ノード間で構成情報の同期を取る必要があります。
同期はsyncNodeコマンドによって手動で行うことが可能です。

以下、changeHostNameコマンドの例です。また、changeHostNameコマンド実行後には必ず構成変更の保管を行ってください。
(Jythonの場合)

wsadmin>AdminTask.changeHostName ('[-hostName hostname -nodeName nodename]')
wsadmin>AdminConfig.save()

(Jaclの場合)

wsadmin>$AdminTask changeHostName {-hostName hostname -nodeName nodename}
wsadmin>$AdminConfig save

なお、このコマンドはwsadminコマンドですので、実行する際にはDMが起動している必要があります。
ホスト名変更の際にはローカルのhostsファイル内で、一つのIPアドレスに対し変更前後のホスト名を両方定義しておくことで、ホスト名変更後もDMを起動させることが可能です。
WAS V6.1 InfoCenter: AdminTask オブジェクトの Utility コマンド・グループ　　
WAS V6.1 InfoCenter: Wsadmin ツール
WAS V6.1 InfoCenter: wsadmin ツールによる構成変更の保管
WAS V6.1 InfoCenter: syncNodeコマンド

[運用スクリプトについて]
・コマンド実行パスの変更
V6から、<WAS_ROOT>/profiles/以下にプロファイル環境が作成されます。
– V5.xで<WAS_ROOT>にあったコマンドやログ・ファイルの場所は、各プロファイル のディレクトリー以下に変更されました。
– 現在スクリプトでコマンドの場所やログの場所を指定している場合には修正が必要です。

•V5.x での例
– サーバーの起動 <WAS_ROOT>/bin/startServer.sh
– サーバーのログ <WAS_ROOT>/logs/server1/SystemOut.log
•V6.x での例
– サーバーの起動 <WAS_ROOT>/profiles/<profile名>/bin/startServer.sh
– サーバーのログ <WAS_ROOT>/profiles/<profile名>/logs/server1/SystemOut.log

・スクリプト言語の変更
WASで使用するスクリプト言語は、WASV5.1ではJaclでしたが、WASV6.1ではJaclは非推奨となりJythonが推奨されます。
また、管理コンソールの操作をJythonスクリプトとして表示する「コマンド支援」機能が提供されていますので、下記リンクをご参照ください。
WAS V6.1 InfoCenter:wsadmin ツールにおける Jacl 構文の非推奨
WAS V6.1 InfoCenter:V5.x からの管理スクリプトのマイグレーション
WAS V6.1 InfoCenter:管理コンソールからコマンド支援へのアクセス

JACLからJythonへの変換アシストツールが提供されています。ただし、アシストツールであり完全な変換を保障していない、日本語が通らない、などの制限が存在しています。
このツールを使用した場合には、変換後のテストを必ず実施してください。
・IBM Jacl to Jython Conversion Assistant

[セル、ノード名を変更する方法]
以下のリンク先資料の手順によってセル、ノード名を変更することが可能です。
ただし、この方法は構成ファイルを手動で編集するもので、セルおよびノード名をコマンドやツールによって簡単に変更できるものではありません。
したがって構成ファイルの書き換えを間違えるとWASが正常に稼動しませんので注意が必要です。必ずバックアップを取得した上で変更してください。
・ノード名変更の場合(p.9～p.10)
・セル名変更の場合 (p.14～p.15)
WebSphere Application Server V6.0 best practices for configuration changes

[WASの非推奨項目について]
詳細につきましては、以下のリンク先をご確認下さい。
WAS V6.0 InfoCenter:非推奨のフィーチャーと除去されたフィーチャー
WAS V6.1 InfoCenter:非推奨のフィーチャーと除去されたフィーチャー

[マイグレーションの際にBase版からND版に変更する場合の考慮点]
マイグレーションと同時にBase版複数台構成からND版クラスター構成へ構成変更する場合の考慮点を記述します。
・クラスターの作成について
各ノードに既存アプリケーション･サーバーをシングルサーバーとしてマイグレーションした状態でND環境に統合しても、全ての既存アプリケーション･サーバーをクラスターメンバーに組み込むことができないため、マイグレーション後のアプリケーション･サーバーを有効活用できないという考慮点があります。

クラスター作成画面で1つ目のクラスターメンバーを作成する際に以下の4つオプションを選択することができます。
(1) アプリケーション・サーバー・テンプレートを使用してメンバーを作成します。
(2) 既存のアプリケーション・サーバーをテンプレートとしてメンバーを作成します。
(3) 既存のアプリケーション・サーバーを変換してメンバーを作成します。
(4) なし。 空のクラスターを作成します。

ここで、(2)もしくは(3)のオプションを選択することで、既存サーバーの設定と同一の設定でクラスターメンバーを作成することができます。(2)と(3)のオプションの違いは既存のサーバーをクラスターメンバーに含めるか否かになります。
(2)のオプションは既存のサーバーをクラスターに含めません。クラスターメンバーとなるサーバーは全て新規作成することになります。
(3)のオプションは既存のサーバーをクラスターに含めます。ただし、最初の1つのメンバーだけで、2つ目以降のメンバーは新規作成することになります。
つまり、各ノードにアプリケーション･サーバーがある状態でND環境に統合しても、全てのアプリケーション･サーバーをクラスターに追加することはできません。例えば、ノード1のアプリケーション･サーバーをクラスターに追加した場合、他のノードのアプリケーション･サーバーは同じクラスターに追加することができません。

・データソースおよびWebSphere変数等の有効範囲を持つ設定について
ND環境に統合後、データソースやWebSphere変数といった有効範囲を持つ設定で再設定が必要になります。
有効範囲は設定を誤ると意図したとおりに稼動しない可能性があるので注意が必要です。
マイグレーションをおこなった場合、データソースやWebSphere変数等は旧バージョンの有効範囲を保持したまま引き継がれます。
ここで、有効範囲をセル単位で設定されている変数がある場合、セルに統合する際に他のノードと重複してエラーとなります。
そのため、この設定を旧Baseから新NDシングルサーバー構成へマイグレーションする前後のいずれかで削除する必要があります。

また、ND環境統合後にクラスター単位での設定をおこなった場合、有効範囲がアプリケーション･サーバーなどクラスターよりも小さい範囲での設定が残っているとそちらの設定が優先されるため、クラスター単位での設定をおこなう場合にはデータソースやWebSphere変数を削除する必要があります。これを誤ると意図したとおりに稼動しない可能性があります。

今回の場合、ND環境統合前後で構成が大きく変わる(Base構成からクラスター構成になる)ため、設定の多くをクラスター単位で再設定し既存の設定を削除する必要があります。

以上の作業負荷を考慮した場合、マイグレーションをおこなわず、新規に導入および構成を行う方が手順としても単純で難易度も比較的容易になると考えられます。


【II. WAS V7.0へのマイグレーション】

【II-1. WAS V7.0へのマイグレーション関連資料リンク】
WAS V7.0へのマイグレーションに関する資料を紹介します。
WAS V7.0 InfoCenter
Knowledge Collection: Migrating to (or from) WebSphere Application Server V7.0

【II-2. マイグレーションにおける既知の考慮点】
[WASV6とV7のマイグレーションの違い]
WAS V7.0を直近のバージョンであるV6.1と比較すると、非常に高いレベルの上位互換性がとられています。
WAS V7.0上では，WAS V6.1用に作成されたJ2EE 1.4準拠のアプリケーションをそのまま稼働させることができます。
また、WAS V6.0以前からの移行に当たっては、WAS V6.1へのマイグレーションで使用した手法がそのまま使用できます。
以前のWASからのマイグレーションは，移行対象がV6.1であってもV7.0であっても，必要なアプリケーション修正内容は同じになります。

[WASV7におけるデフォルトの証明書について]
過去バージョンにおけるデフォルトの証明書について、まず整理します。
WAS V6.0までは、WAS出荷時に作成された自己署名証明書が同梱されており、これがSSL通信に使用されています。
これが以前、DummykeyRing問題として対応する必要があった証明書になります。

WAS V6.1ではプロファイルの作成時に各ノードに固有の自己署名証明書が自動生成されるようになっています。
証明書の有効期限については、以下の表をご参照ください。 また、この有効期限はカスタム・プロパティーにて変更することも可能です。

	V6.1.0.1(出荷メディア)～ V6.1.0.5の環境	V6.1.0.7(Fix Pack7適用)以降、または、PK34093 (6.1.0.7に含まれる)、または、PK42863(PK34093の置き換え)を適用した環境
作成される自己署名証明書の有効期限	1年	15年　　 ※FixPack7以降 or PK34093 or PK42863 を適用後に新たに作成されたプロファイルが対象となります。 Fix適用前に作成された既存のプロファイルの有効期限が延びる訳ではありませんので、ご注意ください。
証明書期限切れの警告送信	期限切れの90日前から (デフォルト)	期限切れの90日前から (デフォルト)

また、証明書の期限が切れる前に自動で証明書を置き換える機能が提供されたことで、この有効期限切れの問題は解決されています。
この自己署名証明書の自動更新機能を使用する場合の考慮点が以下のURLにまとめられていますので、ご確認ください。
【ご注意ください】 WAS V6.1の自己署名証明書・自動更新機能を使用する場合の考慮点

次に、WAS V7.0についてですが、以前のバージョンで使用されていた自己署名証明書とは異なり、チェーン（階層付き）証明書がデフォルトで使用されます。
WAS V6.1までのデフォルトの環境では自己署名証明書が使用されています。
階層付きの証明書によって、有効期限の長い（15年）ルート証明書がコンポーネント間で共有され、実際にSSL通信を行うための証明書はルート証明書によって署名された証明書が使用されるようになっています。
また、WAS V7.0において証明書の自動更新機能を使用する場合、上記URLの考慮点のうち、【考慮点1】セルとノードの同期が行われないケースについてはV7.0でも発生しますのでご注意ください。
この問題が発生した場合は、syncNodeコマンドを使用して手動で同期を行う必要があります。

マイグレーション・ツールを使用した移行では、以前のバージョンの自己署名証明書がそのまま移行されます。WAS V7.0から採用されたチェーン証明書の構成にはなりません。
チェーン証明書を使うよう環境を変更するためには，、wsadminのconvertSelfSignedCertificatesToChainedタスクを使用して手動で証明書を変換する必要があります。
WAS V7.0 InfoCenter:AdminTask オブジェクトの SSLMigrationCommands コマンド・グループ
　　　
以上