|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
|
|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
本章で対象とする移行元のAPサーバは以下のとおりです。
| 移行元APサーバ | バージョン |
|---|---|
| WebOTX Application Server | 9.4 |
| WebOTX Application Server | 10.1 |
マイグレーションアシスタントを使用した移行の流れを説明します。
マイグレーションアシスタントを使用する場合、以下の流れで移行を行います。
情報採取スクリプトを使って設定ファイルなどの設定情報を採取します。
WebOTX Developerに採取した設定情報をインポートして、移行先の設定情報に変換します。
変換結果として表示されるパラメータシートの内容を確認し、必要に応じて設定値の修正を行います。
必要に応じてアプリケーションソースの検証を行い、アプリケーションの実体ファイル(warやjarなど)を用意します。用意した実体ファイルは、変換後の設定情報に取り込みます。詳細は[ アプリケーションの準備 ]にて説明します。
パラメータシートの内容に従い、移行先の環境にWebOTX Application Serverをインストールします。
WebOTX Developerより、設定情報とアプリケーションを移行先の環境に反映します。
設定情報の採取(手順1)は移行元の環境で、APサーバのインストール(手順5)は移行先の環境で行います。その他の作業については、WebOTX Developerをインストールした環境で行います。
移行元環境からアプリケーションを移行する場合、JDKやWebOTXのバージョン間の非互換に該当していないかソースを検証し、該当している場合は内容を確認し変更して移行先環境に配備します。
種類別に以下の対応を行います。
移行元環境構築時に利用したEclipseのアプリケーションの作成プロジェクトを準備します。
Eclipse形式のプロジェクトが無い場合、[ アプリケーション開発 ]を参照し、アプリケーションの種類に 応じたプロジェクトを作成してください。
Eclipseのプロジェクト上でアプリケーション検証機能による非互換チェックを行います。
非互換に該当していた場合、内容を確認し必要があれば修正を行います。
修正したアプリケーションを設定情報のZIPファイルに含めて配備します。
Caution
Linux のC++アプリケーションを移行する場合、gcc 3.xとgcc 4.xのバイナリ非互換のため、
gcc 3.x でビルドされているアプリケーションは必ず gcc 4.x で再ビルドする必要があります。
gcc 4.x で再ビルドを行わない場合、正しく移行されません。
本章では、WebOTXの旧バージョンから移行する場合の具体的な移行の流れを説明します。
本章で対象とする移行パターンは以下です。
移行の前に必ず行う必要がある作業と確認事項について、説明します。
マイグレーションアシスタントを利用するためには、WebOTX Developerが必要です。WebOTX Developerのインストール方法については、[ アプリケーション開発 > 開発環境の構築(WebOTX Developer) > インストール・アンインストール ]を参照してください。
移行元で採取した設定情報やアプリケーションの実体ファイルを取り扱うため、マイグレーションアシスタントを実行する環境(移行元の環境、WebOTX Developerを実行する環境、移行先の環境)には十分な空き容量が必要です。必要な容量は[ 必要リソース ]を参照してください。
そのほか、 [ 注意制限事項 > マイグレーション ] についても確認してください。
情報採取スクリプトを使用して、移行元環境の設定情報を採取します。複数のWebOTXサーバから移行する場合は、移行元のすべてのWebOTXサーバから情報を採取してください。
採取の前に以下の点を確認してください。
設定情報を採取するためには、採取対象のドメインが起動している必要があります。対象のドメインが起動しているか確認してください。起動していない場合は起動してください。
設定情報を採取する情報採取スクリプトでは、ファイルの作成・削除を行います。そのため、管理者権限があるユーザで実行する必要があります。Windowsの場合はユーザにAdministrator権限があること、Linuxの場合はユーザがrootグループに所属していることを確認してください。管理者権限がない場合は、管理権限があるユーザに切り替えてください。
設定情報の採取中に移行元環境の設定や状態が変化した場合、正しく情報が採取できません。移行元の環境のシステムを利用しているユーザ(システムにアクセスしているユーザや、運用操作を実行中のユーザ)がいないか確認してください。利用しているユーザが存在した場合は、利用が完了するまで設定情報を採取しないでください。
設定情報の採取は次の手順で実施します。詳細は [ 情報採取 ] をご参照ください。
WebOTX Developerを起動して、メニュー ファイル > インポート を選択し、インポート ダイアログが表示されます。
図1.6.3-1
採取した移行元の設定情報を変換します。複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、WebOTXサーバ単位で採取した設定情報をそれぞれ変換してください。
インポート ダイアログで マイグレーション > 設定情報圧縮ファイル を選択して 次へ ボタンを押下すると 移行元設定情報のインポート ウィザードが表示されます。
図1.6.3-2
移行元設定情報のインポート ウィザードでプロジェクト名と移行元の設定情報圧縮ファイルを入力して 次へ ボタンを押下すると 移行元設定情報の設定 ウィザードが表示されます。
図1.6.3-3
移行元設定情報の設定 ウィザードで移行元の情報を確認してから、 次へ ボタンを押下すると移行先設定情報の設定 ウィザードが表示されます。
図1.6.3-4
Caution
WebOTX Webサーバ 1.3, IIS以外の外部Webサーバの場合、移行元のWebサーバの種類が内蔵Webサーバと表示されますが、移行対象の内蔵Webサーバに移行されます。
詳細は[ 移行 > 移行機能リファレンス > マイグレーションアシスタント > 使用上の条件 > ソフトウェア条件 > WebOTX ]のドメインの動作設定とWebサーバの構成を参照してください。
移行先設定情報の設定 ウィザードで各項目を移行先サーバの情報に合わせて設定して 終了 ボタンを押下すると、マイグレーションプロジェクト webotx_migration_configs_xxxxxx が生成されます。
図1.6.3-5
マイグレーションプロジェクト webotx_migration_configs_xxxxxx の構成は下図のようになります。
図1.6.3-6
ここまでで、移行元の環境情報の変換が完了しました。
設定情報の変換機能で変換された設定情報をWebOTX Developerのパラメータシートビューで確認・修正できます。
マイグレーションプロジェクト webotx_migration_configs_xxxxxx のインポートが完了したあとにパラメータファイルの内容がパラメータシートビューで表示されます。
図1.6.4-1
表示内容を確認し、変換先サーバの状況に合わせて必要であれば修正してください。
詳細な使用方法は [ パラメータシートの表示 ] を参照してください。
複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、WebOTXサーバ単位での変換結果をすべて確認してください。
パラメータシートには、変換の途中で起こった問題や、設定値の妥当性チェック結果などがメッセージとして出力されます。
メッセージには以下のような三段階のレベルがあります。メッセージレベルに応じて確認を行ってください。
| メッセージレベル | 説明 |
|---|---|
| MUST | 確認必須のメッセージです。必ず内容を確認し、必要に応じて設定値を修正してください。 |
| SHOULD | 確認したほうがよいメッセージです。内容を確認し、必要に応じて設定値を修正してください。 |
| INFO | 確認しなくても問題ないメッセージです。必要に応じて内容を確認してください。 |
メッセージに加えて、以下の確認・修正も行ってください。
特に「MUST」で表示される内容が設定されるか、確認する必要があります。▽をクリックして、メニュー パラメータ・フィルター を選択します。
図1.6.4-2
パラメータ・フィルター ダイアログが表示されて、 メッセージレベルは「MUST」のパラメータのみ表示 をチェックしてOKボタンを押下します。
図1.6.4-3
パラメータシートビューでメッセージレベルが「MUST 」のパラメータのみ表示されて、修正に必要がある場合に該当パラメータをダブルクリックして、関連ファイルにジャンプし、編集して保存します。
図1.6.4-4
詳細な使用方法は [ パラメータシートの表示 ] を参照してください。
ファイルやディレクトリのパス、通信で使用するホスト名やIPアドレスの設定は、環境に依存するため、必要に応じて移行先の環境に適した値に変更してください。
このような環境に依存する設定については、パラメータシートにMUSTレベルでメッセージを出力していますので、必ずご確認ください。
以下の設定は移行元環境の設定が反映されています。移行先環境に合わせて設定を変更してください。
(例)
otxadmin > set server.jndi-service.url=corbaname://<ホスト名>
JMSサーバとのSSL通信で使用するキーストアファイル（${AS_INSTALL}/wojms/etc/keystore）、および、SSLキーストアのパスワードのプロパティ（wojms.keystore.password）値は移行しません。JMSサーバ起動引数 (server.jms-service.start-args) で、ssljms、および、ssladminコネクションサービスを有効化している場合は、当該定義 (-Dwojms.service.activelist=...,ssljms,ssladmin,...の部分) を削除して移行してください。
移行操作後、移行先の環境において、[ 移行後の作業 > Windows > JMS ]、[ 移行後の作業 > Linux > JMS ] の手順に従って、SSL関連のコネクションサービスを有効化してください。
移行するアプリケーションは 配備可能なファイル と プロジェクト の2つ形式で指定できます。
本サンプルでは、移行する5つアプリケーションの中に、1つが プロジェクト として指定し、それ以外は 配備可能なファイル として指定します。
| アプリケーション | アプリケーションタイプ | 関連プロジェクト/配備可能なファイル |
|---|---|---|
| HelloServer | EJB | HelloServer.jar |
| CartAppClient | APP_CLIENT | CartAppClient.jar |
| CartApp1 | JAVAEE | CartApp1.ear |
| testservlet | WEB | dynamicWeb |
| inbound2 | RESOURCE | inbound2.rar |
アプリケーション testservlet の関連プロジェクト dynamicWeb をワークスペースにインポートして、WebOTX V11.1 サーバに利用できるかのチェックを行います。
dynamicWeb を右クリックして アプリケーション検証 をクリックします。
図1.6.5-1
実行後、検証結果が HTMLレポート に出力されます。
検証結果に 互換性の問題 がある場合、その内容を確認し、必要であれば修正してください。
詳細な使用方法は [ アプリケーション検証機能 ] を参照してください。
次はマイグレーションプロジェクトとの関連付けを設定します。
webotx_migration_configs_xxxxxx を選択し、右クリックメニュー プロパティー を選択すると プロパティー ダイアログが表示されます。
図1.6.5-2
プロパティー ダイアログで 関連アプリケーション を選択し、関連アプリケーションページが表示されます。
図1.6.5-3
testservlet を選択して 編集 ボタンを押下すると、関連アプリケーションの情報 ダイアログが表示されます。
図1.6.5-4
参照 ボタンを利用して、dynamicWebを指定し、OK ボタンを押下して、プロパティー ダイアログに戻ります。
図1.6.5-5
プロパティー ダイアログで OK ボタンを押下して、関連アプリケーションの設定を完了します。
図1.6.5-6
ここまでで、移行するアプリケーションの準備が完了しました。
移行先の環境に WebOTX Application Server をインストールします。
パラメータシートの「インストール設定」に記載された内容でインストールしてください。
具体的なインストール手順については詳細は、各インストールガイド（ Windows ／Linux ）を参照してください。
変換した設定情報を移行先の環境に反映します。
複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、全WebOTXサーバの設定情報を反映します。ただし、システムおよび管理ドメインの設定は一つの環境からのみ移行可能なため、どのWebOTXサーバからシステムおよび管理ドメインの設定を移行するかを検討のうえ、システムおよび管理ドメインの設定を含む設定情報を最初に移行してください。また、既に存在するドメインと同名のドメインは移行できないため、二つ目以降の設定情報を反映する際にドメイン名の重複があればドメイン名を変更する必要があります。
設定情報の反映を行う前には、以下の点を確認してください。
設定情報の反映は、移行先環境の管理ドメインに接続して行います。そのため、移行先環境の管理ドメインが起動している必要があります。起動していない場合は起動してください。
システムの設定はドメインに影響するため、接続する必要がある管理ドメインを除くすべてのドメインを停止している必要があります。停止していない場合は停止してください。
確認できましたら設定情報を反映します。
webotx_migration_configs_xxxxxxを選択し、右クリックメニュー 実行 > 移行先サーバに配備 を選択します。
図1.6.7-1
移行先サーバに配備 ダイアログが表示されます。
移行先サーバに配備 ダイアログで各項目を設定して、終了 ボタンを押下して、移行先サーバの配備を行います。
図1.6.7-2
サービスが開始できること、ドメインが起動できることを確認します。
具体的な手順は インストールガイド（Windows）の[動作確認]を参照ください。
なお、マイグレーションでの移行後はドメインのパスワードが既定に変更されています。ドメインのパスワードが必要な場合はadminadminを使用してください。
移行元環境において、JDBCストアを利用していた場合、移行先の環境では、ファイルストアに変更されています。 また、JMSサーバとのSSL通信や、JMSサーバクラスタを利用していた場合は、移行先の環境では無効になっています。 移行先でも、JDBCストアや、SSL通信、JMSサーバクラスタを利用する場合は、それぞれ、次の手順で有効化してください。
otxadmin> stop-jms
otxadmin> set server.jms-service.storeType=<永続ストアタイプ> otxadmin> set server.jms-service.jdbcStoreURL=<JDBC URL> otxadmin> set server.jms-service.jdbcStoreUser=<DBユーザ名> otxadmin> set server.jms-service.jdbcStorePassword=<DBパスワード>
> jmqdbmgr delete tbl -u <DBユーザ名> -p <DBパスワード> -t <DBの種類> -url <JDBC URL>
> jmqdbmgr create tbl -otxdomain <ドメイン名>
otxadmin> set server.jms-service.enableCluster=trueJMSサーバクラスタを構成するサーバ情報に変更がある場合は、次のコマンドにより変更してください。
otxadmin> set server.jms-service.clusterBrokerList=<JMSサーバのアドレスリスト> otxadmin> set server.jms-service.clusterMasterBroker=<マスターブローカのアドレス>
otxadmin> start-jms
パラメータシートで差分を確認し、移行元の設定ファイルの行番号情報を参考に、必要な定義を移行先の設定ファイルに移行してください。 移行の注意点は、[ 注意制限事項 > マイグレーション > 注意事項 > WebOTX Webサーバ > WebOTX Webサーバ 2.x からの移行 ] を参照してください。
マイグレーション実行後の環境は、下記のユーザを設定しています。
また、他にユーザを追加していた場合も、パスワードが移行されていないため、ユーザの追加やパスワードの変更が必要になることがあります。 この場合、統合運用管理ツールや、otxadminコマンドを利用して運用ユーザの作成、及び変更を実施してください。
WebOTXが提供しているもの以外の独自の証明書や、独自のキーストアエントリは移行されません。 利用している場合、Javaが提供するkeytoolコマンドを利用し、移行先の環境に対して証明書やキーストアエントリを登録する必要があります。
登録の必要がある場合、パラメータシートに手動で追加することを促すメッセージが出力されます。 その場合は、下記の設定方法に基づき、マイグレーション完了後に設定を行ってください。
マイグレーション機能ではライフサイクルモジュール設定の移行のみを行っており、ライブラリは手動で配置する必要があります。 パラメータシートを確認し、アプリケーションのノード配下にライフサイクルモジュールの設定が存在する場合、移行元から移行先へライフサイクルモジュールのライブラリをコピーしてください。
また、ライブラリのコピー先は、パラメータシート上で[アプリケーション/ライフサイクルモジュール]-[ライフサイクルモジュール名]-[クラスパス]で指定しているパス、またはWebOTXがロードする場所に配置する必要があります。
ライブラリの配置についての詳細は、下記を参照してください。
ライフサイクルモジュールの設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、ライブラリを配置した後に下記のコマンドにより設定を変更してください。
otxadmin > set server.applications.lifecycle-module.{ライフサイクルモジュール名}.is-failure-fatal=true
内部ライフサイクルモジュールは、WebOTXが既定で提供する機能です。
本設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、下記のコマンドにより設定を変更してください。
otxadmin > set server.internal-lifecycle-module.{内部ライフサイクルモジュール名}.is-failure-fatal=true
提供しているサービス名は、下記の章の内部ライフサイクルモジュール配下を参照してください。
移行後、そのままの状態ではJDBCドライバの設定やパスワードの設定が足りないため接続に失敗します。次の手順で接続確認を行ってください。
otxadmin> set server.resources.jdbc-datasource.<datasource-name>.password=<パスワード>
* datasource-nameは、"jdbc/"で始まるJDBCデータソースの定義名です。
otxadmin> get server.resources.jdbc-datasource.<datasource-name>.dataSourceName otxadmin> get server.resources.jdbc-datasource.<datasource-name>.serverName必要であれば次のsetコマンドで設定を行ってください。
otxadmin> get server.resources.jdbc-datasource.<datasource-name>.dataSourceName=<JDBC URLまたはデータベース名、データソース名> otxadmin> get server.resources.jdbc-datasource.<datasource-name>.serverName=<データベースサーバ側のサーバ名>JDBC URLまたはデータベース名、データソース名[dataSourceName]およびサーバ名[serverName]の詳細は次のマニュアルを確認してください。
otxadmin> ping-jdbc-datasource <datasource-name>
接続テストの詳細は次のマニュアルを確認してください。
JCAリソースのユーザ名、パスワードは移行の対象外です。移行元で独自に設定を行っていた場合は、移行後に設定を行ってください。
コマンド実行例：otxadmin> set server.resources.jca-resource.<リソース名>.user-name=<ユーザ名> otxadmin> set server.resources.jca-resource.<リソース名>.password=<パスワード>
・[リファレンス > 設定 > Transactionサービス > リソースを管理するためのコマンド]
以下のパスワード設定は移行されません。
移行元環境で既定値から変更を行っている場合は、手動でパスワードを設定してください。
(例)
otxadmin > set server.embedded-iiop-service.cert-key-pass-phrase=<パスワード>
各コネクタコネクションプールに対応したセキュリティマップは移行されません。
(例)
移行元環境でセキュリティマップを作成している場合は、手動でセキュリティマップを再作成してください。
otxadmin > create-connector-security-map --poolname <コネクタコネクションプール名> --principals <プリンシパル名> --mappedpassword <ユーザグループ名> --mappedusername <enterprise information systemユーザ名> --mappedpassword <enterprise information systemパスワード> <セキュリティマップ名>
Standardエディションの場合、TPシステムの以下の設定は、環境に依存するため移行されません。
手動で適した値を設定してください。
(例)
otxadmin > set tpsystem.nameSvHostName=<名前サーバのホスト名>
WebOTX運用管理ユーザでWebOTXを運用したい場合は、運用ユーザの変更を行います。
具体的な手順は [ 構築・運用 > ドメインの構築 > ユーザ管理 > その他の管理ユーザ > 管理ユーザ設定(UNIX) > WebOTX管理ユーザ(運用ユーザ)の設定 ] を参照してください。
サービスが開始できること、ドメインが起動できることを確認します。
具体的な手順は、インストールガイド（Linux）の[動作確認]を参照ください。
なお、マイグレーションでの移行後はドメインのパスワードが既定に変更されています。ドメインのパスワードが必要な場合はadminadminを使用してください。
移行元環境において、JDBCストアを利用していた場合、移行先の環境では、ファイルストアに変更されています。 また、JMSサーバとのSSL通信や、JMSサーバクラスタを利用していた場合は、移行先の環境では無効になっています。 移行先でも、JDBCストアや、SSL通信、JMSサーバクラスタを利用する場合は、それぞれ、次の手順で有効化してください。
otxadmin> stop-jms
otxadmin> set server.jms-service.storeType=<永続ストアタイプ> otxadmin> set server.jms-service.jdbcStoreURL=<JDBC URL> otxadmin> set server.jms-service.jdbcStoreUser=<DBユーザ名> otxadmin> set server.jms-service.jdbcStorePassword=<DBパスワード>
> jmqdbmgr delete tbl -u <DBユーザ名> -p <DBパスワード> -t <DBの種類> -url <JDBC URL>
> jmqdbmgr create tbl -otxdomain <ドメイン名>
otxadmin> set server.jms-service.enableCluster=trueJMSサーバクラスタを構成するサーバ情報に変更がある場合は、次のコマンドにより変更してください。
otxadmin> set server.jms-service.clusterBrokerList=<JMSサーバのアドレスリスト> otxadmin> set server.jms-service.clusterMasterBroker=<マスターブローカのアドレス>
otxadmin> start-jms
パラメータシートで差分を確認し、移行元の設定ファイルの行番号情報を参考に、必要な定義を移行先の設定ファイルに移行してください。 移行の注意点は、[ 注意制限事項 > マイグレーション > 注意事項 > WebOTX Webサーバ > WebOTX Webサーバ 2.x からの移行 ] を参照してください。
マイグレーション実行後の環境は、下記のユーザを設定しています。
また、他にユーザを追加していた場合も、パスワードが移行されていないため、ユーザの追加やパスワードの編集が必要になることがあります。 この場合、統合運用管理ツールや、otxadminコマンドを利用して運用ユーザの作成、及び変更を実施してください。
WebOTXが提供しているもの以外の独自の証明書や、独自のキーストアエントリは移行されません。 利用している場合、Javaが提供するkeytoolコマンドを利用し、移行先の環境に対して証明書やキーストアエントリを登録する必要があります。
登録の必要がある場合、パラメータシートに手動で追加することを促すメッセージが出力されます。 その場合は、下記の設定方法に基づき、マイグレーション完了後に設定を行ってください。
マイグレーション機能ではライフサイクルモジュール設定の移行のみを行っており、ライブラリは手動で配置する必要があります。 パラメータシートを確認し、アプリケーションのノード配下にライフサイクルモジュールの設定が存在する場合、移行元から移行先へライフサイクルモジュールのライブラリをコピーしてください。
また、ライブラリのコピー先は、パラメータシート上で[アプリケーション/ライフサイクルモジュール]-[ライフサイクルモジュール名]-[クラスパス]で指定しているパス、またはWebOTXがロードする場所に配置する必要があります。
ライブラリの配置についての詳細は、下記を参照してください。
ライフサイクルモジュールの設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、ライブラリを配置した後に下記のコマンドにより設定を変更してください。
otxadmin > set server.applications.lifecycle-module.{ライフサイクルモジュール名}.is-failure-fatal=true
内部ライフサイクルモジュールは、WebOTXが既定で提供する機能です。
本設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、下記のコマンドにより設定を変更してください。
otxadmin > set server.internal-lifecycle-module.{内部ライフサイクルモジュール名}.is-failure-fatal=true
提供しているサービス名は、下記の章の内部ライフサイクルモジュール配下を参照してください。
移行後、接続確認を行ってください。手順はWindowsと同様ですので、次の箇所を参照してください。
移行後、必要な場合は設定を行ってください。手順はWindowsと同様ですので、次の箇所を参照してください。
以下のパスワード設定は移行されません。
移行元環境で既定値から変更を行っている場合は、手動でパスワードを設定してください。
(例)
otxadmin > set server.embedded-iiop-service.cert-key-pass-phrase=<パスワード>
各コネクタコネクションプールに対応したセキュリティマップは移行されません。
移行元環境でセキュリティマップを作成している場合は、手動でセキュリティマップを再作成してください。
(例)
otxadmin > create-connector-security-map --poolname <コネクタコネクションプール名> --principals <プリンシパル名> --mappedpassword <ユーザグループ名> --mappedusername <enterprise information systemユーザ名> --mappedpassword <enterprise information systemパスワード> <セキュリティマップ名>
Standardエディションの場合、TPシステムの以下の設定は、環境に依存するため移行されません。
手動で適した値を設定してください。
(例)
otxadmin > set tpsystem.nameSvHostName=<名前サーバのホスト名>
[ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 注意事項 ] を参照してください。
[ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 制限事項 ] を参照してください。