マイグレーション 日本アイ・ビー・エム(株) SW事業 WebSphere Technical Sales 田中 孝清 ()
by user
Comments
Transcript
マイグレーション 日本アイ・ビー・エム(株) SW事業 WebSphere Technical Sales 田中 孝清 ()
マイグレーション 日本アイ・ビー・エム(株) SW事業 WebSphere Technical Sales 田中 孝清 ([email protected]) Version 1.1a © 2008 IBM Corporation 1 Disclaimer WAS WAS V7 V7 W/S W/S 当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。 この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレ ビューを受けておりません。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2008年 10月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変 わる可能性があるのでご注意下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ い。 WebSphere Application Server V7 Announcement Workshop 2008 #2 © IBM Corporation. 2 Agenda WAS WAS V7 V7 W/S W/S アプリケーションのマイグレーション 新しい標準仕様への対応 非推奨となった機能・削除された機能への対応 システムのマイグレーション WebSphere Application Server V7 Announcement Workshop 2008 #3 © IBM Corporation. 3 WAS WAS V7 V7 W/S W/S アプリケーションのマイグレーション WAS WAS V7 V7 W/S W/S WebSphere Application Server V7 Announcement Workshop 2008 #4 © IBM Corporation. 4 アプリケーションの単体テスト・統合テストの重要性 WAS WAS V7 V7 W/S W/S アプリケーションのマイグレーションにあたっては, 文章化されていない変更が原因で修正が必要となるケースがある 仕様で定められた制限に違反しているアプリケーション 以前存在していた「バグ」に依存してしまったアプリケーション 非公開仕様・WAS/JDKの内部実装への依存 等 このような問題は,事前のコードレビューで発見することが難しい 「仕様の変更」は文書化されているが, 「仕様外の動作の変更」はほとんど文書化されていない 開発環境のコードチェック機能でも発見できないケースが多い 問題が発生するパターンが無数に考えられ, 事前検証で網羅することが不可能 テストを実行して発見することが最良の手段 最低限必要な修正を加えたら、まずは新環境でテストを行い 問題の洗い出しを行う 十分な期間のテストをスケジュールしておくことが必要 運用後のパッチ適用なども考え,テストの自動化も検討する WebSphere Application Server V7 Announcement Workshop 2008 #5 © IBM Corporation. アプリケーションのマイグレーションにあたって,ひとつ留意点があります。それは, アプリケーションの修正が必要な箇所を,各種の資料で事前に全て洗い出すこと は現実的ではない,ということです。 マイグレーションにあたっては,標準仕様やWebSphereの仕様変更に対応するだ けではすまないケースがあります。それはアプリケーションがWASやJDKの内部実 装や仕様外の動作に依存してしまっている場合です。このような「APIを仕様外の 方法で使用したときの挙動」などは,バージョンによって変化しても,それがドキュメ ント化されることはほとんどありません。また,バグの修正などは膨大な件数があり, それらの一つ一つについてアプリケーションへの影響を検討することは実質的に不 可能です。 これらの変更による修正箇所の洗い出しは,アプリケーションのテストによっておこう ことが,作業工数の面からも,検出の確実性の面からもすぐれています。仕様変更 への対応など,必須の修正をおこなったら,まずは新しいアプリケーションサー バーのうえで実行するようにします。マイグレーションプロジェクトにあたっては,そ のようなテストのスケジュールを組み込んでおくことが重要ですし,アプリケーション 開発者がローカルのPC上で単体テストが行える開発環境を使用することも考慮し ます。 5 WAS WAS V7 V7 W/S W/S 新しい標準仕様への対応 WAS WAS V7 V7 W/S W/S WebSphere Application Server V7 Announcement Workshop 2008 #6 © IBM Corporation. 6 それぞれのWASでサポートされている主な仕様 WebSphere J2EE/Java EE J2SE/JDK 2.0 N/A 3.0 WAS WAS V7 V7 W/S W/S Servlet JSP EJB DB Connection JDK 1.1 2.0 0.91 N/A ConnMgr N/A JDK 1.1 2.0/2.1 0.91/1.0 1.0 3.5 N/A J2SE 1.2 2.0/2.1 2.2 0.91/1.0 1.0+α ConnMgr 1.1 JDBC 2.0 4.0 J2EE 1.2 J2SE 1.3 2.2 1.1 1.1 JDBC 2.0 5.0 J2EE 1.3 J2SE 1.3 2.3 1.2 2.0 JDBC 2.0 5.1 J2EE 1.3 J2SE 1.4 2.3 1.2 2.0 JDBC 2.0 6.0 J2EE 1.4 J2SE 1.4 2.4 2.0 2.1 JDBC 3.0 6.1 J2EE 1.4 J2SE 5.0 2.4 2.0 2.1 JDBC 3.0 7.0 Java EE 5 Java SE 6 2.5 2.1 3.0 JDBC 4.0 ConnMgr+α 使用している場合,移行に当たって大きな修正が必要なもの 使用している場合,移行に当たってある程度の修正が必要となる可能性が高いもの WebSphere Application Server V7 Announcement Workshop 2008 #7 © IBM Corporation. それぞれのWASのバージョンが対応している主な仕様のリストです。 画面,赤字で書かれている仕様が使用されていると,大規模なアプリケーション修 正が必要となります。黄色の仕様が使用されている場合にも,ある程度の修正が必 要となる可能性があります。 その他,黒字で書かれているバージョンについては,基本的な上位互換性がとら れているため,一般的には大規模なアプリケーションの回収は必要ありません。た だし,細かい仕様の違いにより,小規模なアプリケーション修正が必要となるケース はあります。 WASのバージョンが4.0以上であれば,アプリケーションの改修はそれほど必要な いことが多いことがわかります。 7 WAS V6.1からV7.0への移行 WAS WAS V7 V7 W/S W/S 「J2EE 1.4→Java EE 5」および「J2SE 5.0→Java SE 6」ともに, 高いレベルで上位互換がある WAS V6.1で稼働していたアプリケーションは,ほとんど変更なく動く WAS 6.0以前からのアプリケーションの移行については, WAS 6.1への移行と同じ作業になる 移行先がWAS 6.1でも7.0でも 必要な作業・手順はほとんど変わらない WAS 4.0 WAS 5.0 WAS 5.1 WAS 6.0 WAS 6.1 WAS 7.0 従来の移行ガイド ・移行情報がそのまま使える WebSphere Application Server V7 Announcement Workshop 2008 #8 © IBM Corporation. WAS V7.0を直近のバージョンであるV6.1と比較すると,非常に高いレベルの上位 互換性がとられています。WAS 7.0上では,WAS V6.1用に作成されたJ2EE 1.4 準拠のアプリケーションをそのまま稼働させることができます。WAS V7.0のBetaテ スト段階からテストに参画いただいたお客様でも,問題となるような仕様の変更は見 つかっていません。 言い換えれば,WAS 6.0以前からの移行に当たっては,WAS V6.1へのマイグ レーションで使用した手法がそのまま使用できると言うことです。以前のWASからの マイグレーションは,移行対象がV6.1であってもV7.0であっても,必要なアプリケー ション修正内容は同じになります。 8 WAS V6.0からV7.0への移行 WAS WAS V7 V7 W/S W/S J2SE 1.4 → Java SE 6への対応が必要 追加された予約語「enum」の対応 Genericsへの対応 強化されたコードチェックによる,エラー・警告への対応 java.lang.reflect.Proxyと同名のjava.net.Proxyが追加 java.util.Loggerのコンストラクタの変更 等 Java Virtual Machine Profiler Interface (JVMPI) Java Virtual Machine Debug Interface (JVMDI)を使用している場合は 対応が必要 これらの機能はJava SE 6で削除された その他詳細についてはSunの文書を参照 http://java.sun.com/j2se/1.5.0/compatibility.html http://java.sun.com/javase/6/webnotes/compatibility.html WebSphere Application Server V7 Announcement Workshop 2008 #9 © IBM Corporation. WAS V6.0からの移行にあたっては,J2EEの仕様は1.4になっているため,Java実 行環境の仕様がJ2SE 1.4からJava SE 6に変わったことによる対応が必要となりま す。Java実行環境の仕様は,J2SE 1.4からJ2SE 5.0にあがる際に大きく変更され ています。これらの変更への対処が必要となります。 また,Java SE 6では,J2SE 5.0にあった機能の一部が削除されています。 詳細については,Sunのサイトで情報が公開されています。 9 WAS V5.1以前からV7.0への移行 WAS WAS V7 V7 W/S W/S J2EEの移行 J2EE 1.4アプリケーションへ移行すれば, WAS V7.0で正常に稼働する J2EE 1.2移行であれば, ツールを使用してJ2EE 1.4へ移行可能 JDK/J2SEの移行 前ページの情報を参照 詳細については,既存の マイグレーション資料を参照 RAD 7.5の マイグレーション・ウイザード WebSphere Application Server V7 Announcement Workshop 2008 # 10 © IBM Corporation. WAS 5.1以前のアプリケーションにおいては,J2EEのバージョンを1.4に, JDK/J2SEのバージョンをJava SE 6にあげることによって移行します。詳細につい ては,既存のWAS V6.1へのマイグレーションの資料がそのまま使用できるので, そちらを参照ください。 Java EE 5ではアプリケーションの記述方法が大きく変わっていますので,Java EE 5へ移行する必要はありません。実際,Rational Application Developer 7.5で 提供されているマイグレーション・ウィザードでも,J2SE 1.2/1.3のアプリケーション を1.4に変換することはできますが,Java EE 5へ変換する機能は提供されていま せん。Java EE 5による開発は,新規アプリケーション開発をおこなうときに使用し ます。 10 WAS WAS V7 V7 W/S W/S V7で非推奨となった機能・削除された機能 WAS WAS V7 V7 W/S W/S WebSphere Application Server V7 Announcement Workshop 2008 # 11 © IBM Corporation. 11 非推奨となった機能・削除された機能 WAS WAS V7 V7 W/S W/S IBM独自機能は,標準仕様で同等のものが提供された時点で非推奨となる これらを使用していた場合には, 基本的には標準仕様を使用する用にアプリケーションを修正する 原則として非推奨となってから2バージョンは使用可能 それ以降のバージョンで削除される可能性がある JVM/JDKの機能などは,この原則よりも早く削除されることもある 正確なリストは以下の情報を参照 Information Center http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.web sphere.nd.multiplatform.doc/info/ae/ae/rmig_deprecationlist.html http://www.ibm.com/support/docview.wss?rs=180&uid=swg21316317 WebSphere Application Server V7 Announcement Workshop 2008 # 12 © IBM Corporation. WASは,標準のJava仕様やWeb Services仕様で規定されている機能の他,それ らを補完するIBM独自機能を数多く提供しています。それらの機能については,標 準仕様が拡張・新規策定され,同等の機能が提供されるようになると, 「非推奨」と なり標準の仕様へ移行することが推奨されます。 非推奨となった機能は,即時に削除されることはなく,原則として非推奨となってか ら2バージョンは提供されることになっています。そのため,修正は必須ではありま せんが,将来のバージョンアップなどを考えると,可能な限り改修をしておくことが 推奨されます。 また,IBMが提供している機能ではなく,JVM/JDKで提供されている機能などは, 仕様自体の変更により,この原則よりも早く削除されることがあります。 JVMPIや JVMTIなどの機能が,これに該当します。 以降のページでは,WAS V7.0で新たに非推奨となった機能をリストアップしてい ます。これ以外にも,WAS V6.1以前で非推奨となった機能などもあります。全ての 非推奨機能の一覧については,Information Centerなどの情報を参照してくださ い。 12 WAS V7で非推奨となった機能(サーブレット関連) WAS WAS V7 V7 W/S W/S Proxyオブジェクト com.ibm.websphere.servlet.request.HttpServletRequestProxyおよび com.ibm.websphere.servlet.response.HttpServletResponseProxy Servlet APIのHttpServletRequestWrapper/HttpServletResponseWrapperを使用する セッションマネージャー(HttpSession) Shared Session Contextを使用したWAR/EAR間のHttpSessionの共有 Servlet21SessionCompatibilityプロパティを使用したHttpSessionの共有 BLA内で情報を共有するIBMApplicationSessionを使用する SSL IDによるセッショントラッキング CookieもしくはURLリライティングによるトラッキングに置き換える システムプロパティ,Webコンテナカスタムプロパティによる設定 セッションマネージャーのカスタムプロパティで設定する WebSphere Application Serverに同梱されていた以下のライブラリ JavaServer Faces Widget Library (JWL) のJarファイル Rationalツールに付属のものを使用する Apache Struts 1.1, 1.2.4, and 1.2.7 Apache Strutsのサイトから最新のものをダウンロードして使用する WebSphere Application Server V7 Announcement Workshop 2008 # 13 © IBM Corporation. Proxyオブジェクトは,Webコンテナから提供される HttpServletRequest/HttpServletResponseをwrapして独自機能を追加するため に使用するものです。Servlet API 2.3で同等のものが提供されていますのでそち らを使用します。 サーブレットAPIが2.1から2.2にあがった際に,HttpSessionのスコープはWebアプ リケーション(WARファイル)内で閉じていること,Webアプリケーションをこえて情 報を共有することはできないことが規定されました。これ以前に作成されたアプリ ケーションを救済するために,WASではWARやEARの境界を越えてHttpSession の内容を共有する仕組みが実装されています。この機能はWAS V7.0で非推奨と なりました。新しく提供されたIBMApplicaitonSessionなどの機能を利用してくださ い。 また,以前のWASのバージョンに添付されていたライブラリのいくつかが非推奨と なっています。これらについては,Rationalのツールや,開発元のサイトで提供され ている最新のバージョンを使用するようにしてください。 13 WAS V7で非推奨となった機能(トランザクション) WAS WAS V7 V7 W/S W/S トランザクション関連 com.ibm.websphere.jtaextensions.ExtendedJTATransactionインターフェース のregisterSynchronizationCallbackForCurrentTranメソッド com.ibm.ws.extensionhelper.TransactionControlインターフェース トランザクションの制御には新しく追加されたJTA 1.1の機能を使用する UOWManager#registerIterposedSynchronization() /javax.transaction.TransactionSynchronizationRegistry等 WebSphere Application Server V7 Announcement Workshop 2008 # 14 © IBM Corporation. WASのトランザクションマネージャーが管理するトランザクションを,アプリケーショ ンから操作することができる機能について,JTA 1.1で新しい機能が追加されたた め,IBM独自機能として提供されていたものが非推奨となりました。 これらは,アプリケーションで直接使用されていることはほとんどありませんが,トラ ンザクション管理機能を持ったフレームワークなどで使用されているケースがありま す。 14 WAS V7で非推奨となった機能(DBアクセス)1 WAS WAS V7 V7 W/S W/S DB接続関連クラス com.ibm.websphere.rsadapterのクラス JdbcAccessorImpl/OracleDataStoreHelper com.ibm.websphere.rsadapterのインターフェース Beginnable/HandleStates/Reassociateable/WSNativeConnectionAccessor com.ibm.websphere.rsadapterのクラスのメソッド WSCallHelperのsetConnectionError(Object conn)/call WSConnectionのgetClientInformation/setClientInformation com.ibm.ws.rsadapter.cciのクラスのメソッド WSResourceAdapterBaseのgetNativeConnection(javax.resource.cci.Connection) /getNativeConnection(com.ibm.ws.rsadapter.jdbc.WSJdbcConnection) com.ibm.ws.rsadapter.jdbcのクラスのメソッド WSJdbcUtilのgetNativeConnection(com.ibm.ws.rsadapter.jdbc.WSJdbcConnection) com.ibm.websphere.rsadapterのクラスのフィールド WSConnectionのCLIENT_ACCOUNTING_INFO/CLIENT_APPLICATION_NAME/CLIENT_ID/CLIENT_LOCATION /CLIENT_OTHER_INFOCLIENT_TYPE getNativeConnectionはJDBC 4.0で追加されたメソッドを使用する その他はInformation Centerの記述にしたがって対処 WebSphere Application Server V7 Announcement Workshop 2008 # 15 © IBM Corporation. WASが管理するDataSourceを制御することができるDataStoreHelperや,WAS がJDBCオブジェクトWrapしているクラスの機能に関連して,非推奨となった項目 がいくつかあります。 このうち,比較的よく使われているのがgetNativeConnection()かと思います。 JDBC Driverで独自に提供されている機能を呼び出すために,WASのJDBC Connection WrapperからNativeのConnectionを取得したいという要件がしばしば あり,そのためにこのメソッドが使用されています。 Native Connectionの取得は,JDBC 4.0から標準仕様の機能として取り入れられ ましたので,そちらを使用するようにします。 15 WAS V7で非推奨となった機能(DBアクセス)2 WAS WAS V7 V7 W/S W/S SQLストリングによる妥当性検査 WebSphere Application Server データ・ソース・プロパティーに設定 「検証オプション」の「照会」に設定する JDBC 4.0で追加された Connection#isValid()メソッドを 使用することにより,SQL実行前に 有効性確認を行うことが可能になった Connection Connection conn conn == ds.getConnection(); ds.getConnection(); if if (!conn.isValid(10)) (!conn.isValid(10)) {{ // // リトライ処理 リトライ処理 }} Statement Statement ss == conn.createStatement(); conn.createStatement(); s.executeUpdate(slq); s.executeUpdate(slq); s.close(); s.close(); JDBC 4.0の機能を利用した例 WebSphere Application Server V7 Announcement Workshop 2008 # 16 © IBM Corporation. WASのDataSource設定にSQL文を指定し,Connectionの取得時にSQL実行を おこなってConnectionの妥当性検査を行うという機能が実装されています。この機 能は,WAS V7.0より非推奨となりました。JDBC 4.0より,標準仕様でisValid()とい うConnectionの妥当性検査をおこなうメソッドが追加されたので,これを利用するよ うにします。 16 参考:DB接続障害のアプリケーション対応 WAS WAS V7 V7 W/S W/S 従来はSQL実行時するまで,Connectionが有効かを確認できなかった StaleConnectionExceptionの発生で無効接続の検知をおこなっていた DBC 4.0で追加されたConnection#isValid()メソッドを使用することによ りSQL実行前に有効性確認を行うことが可能になった これからは,可能な限りこちらの方式を利用する Connection Connection conn conn == ds.getConnection(); ds.getConnection(); while while (true) (true) {{ try { try { Statement Statement ss == conn.createStatement(); conn.createStatement(); s.executeUpdate(sql); s.executeUpdate(sql); s.close(); s.close(); break; break; }} catch catch (StaleConnectionException (StaleConnectionException e) e) {{ // // リトライ処理 リトライ処理 }} }} 従来の方法の例 Connection Connection conn conn == ds.getConnection(); ds.getConnection(); if if (!conn.isValid(10)) (!conn.isValid(10)) {{ // リトライ処理 // リトライ処理 }} Statement Statement ss == conn.createStatement(); conn.createStatement(); s.executeUpdate(slq); s.executeUpdate(slq); s.close(); s.close(); JDBC 4.0の機能を利用した例 WebSphere Application Server V7 Announcement Workshop 2008 # 17 © IBM Corporation. JDBC 4.0のConnection#isValid()の追加は,SQL実行時のエラーハンドリングの 方法も大きく変更させます。 従来,WAS上のアプリケーションでDB接続障害に対応したアプリケーションを実装 しようとした場合,SQL実行時のStaleConnectionException発生をcatchし,リトラ イ処理を実装する方法が推奨されていました。この方法は, StaleConnectionExceptionがWAS独自で提供されているクラスであるため,作成 したアプリケーションがWASに依存したアプリケーションになってしまうという欠点が あります。 JDBC 4.0のisValid()メソッドを使用すると,コンテナに依存することなく,DB接続障 害のリトライ処理を実装することができるようになります。 なお, StaleConnectionException自体は非推奨となっていないため,従来の形 式でDB接続障害に対処しているアプリケーションも,WAS V7.0 上で全く問題なく 稼働します。 17 WAS V7で非推奨となった機能(Messageリソース) WAS WAS V7 V7 W/S W/S J2C(J2EE Connector Architecture)1.5に準拠していないJMSプロバイ ダーの使用 WAS V5でデフォルトで使用されていたJMSプロバイダーはWAS 6.1で非推奨と なっている WebSphere MQで提供されるJMSプロバイダーは,WMQ V7以降でJ2C 1.5対応に JMSリスナーポートによるMDBの使用 リスナーポートを構成・管理するAdminConfigのコマンドやMBeanなども非推奨 JMS activation specificationによるMDBに置き換える WebSphere Application Server V7 Announcement Workshop 2008 # 18 © IBM Corporation. Message関連で非推奨となった機能です。 18 WAS V7で非推奨となった機能(Webサービス)1 WAS WAS V7 V7 W/S W/S Java API for XML Web Services (JAX-WS) 2.0で使用されていた WS-Addressingエンドポイントリファレンス com.ibm.websphere.wsaddressing.jaxws.W3CEndpointReference com.ibm.websphere.wsaddressing.jaxws.SubmissionEndpointReference com.ibm.websphere.wsaddressing.jaxws.EndpointReferenceConverter 以下のものに置き換える javax.xml.ws.wsaddressing.W3CEndpointReference com.ibm.websphere.wsaddressing.jaxws21.SubmissionEndpointReference com.ibm.websphere.wsaddressing.jaxws21.EndpointReferenceConverter ‘2006/02’WS-Addressing WSDLネームスペースのサポート ‘2006/05’ネームスペースを使用する Web Services Distributed Management (WSDM) インターフェース WAS標準のMBeanを使用した管理機能を利用する WebSphere Application Server V7 Announcement Workshop 2008 # 19 © IBM Corporation. Webサービス関連で非推奨となった機能です。 19 WAS V7で非推奨となった機能(Webサービス)2 WAS WAS V7 V7 W/S W/S IBM独自実装のSOAP/JMSを利用したJAX-WS/JAX-RPCアプリケーション 標準のSOAP/JMSを利用したアプリケーションへ書き換える Webサービス・プロバイダー側 ボトムアップ開発の場合: BeanやEJBからプロバイダーを再作成する トップダウン開発の場合: WSDLから再度スケルトンを生成し,従来のロジックをコピーする Webサービス・リクエスター側 WSDLからクライアント・スタブを再作成する WebSphere Application Server V7 Announcement Workshop 2008 # 20 © IBM Corporation. Webサービス関連で大きな変更点は,従来のWebSphere独自実装を用いた SOAP/JMSでのWebサービス呼び出しが非推奨となったことです。Java EE 5より, JMSを使用してWebサービスを呼び出す方法が,標準仕様の一部として策定され ました。そちらの実装を使用することが推奨されています。 WebSphere Application ServerなどIBM製品どうしのSOAP/JMS通信であれば, すぐに移行する必要はありません。ですが,他のSOAP/JMS実装と通信する可能 性があるシステムの場合には,標準の方式に移行することが推奨されます。 20 WAS V7で非推奨となった機能(SIBus) WAS WAS V7 V7 W/S W/S Websphere Common Configuration Model(WCCM)の以下の型 SIBJMSProvider/SIBJMSConnectionFactory/SIBJMSQueueConnectionFactory /SIBJMSTopicConnectionFactory/SIBJMSQueue/SIBJMSTopic スクリプト中でこれらのクラスが使用されている場合には,AdminTaskで提供さ れる同等のメソッド(例:AdminTask.listSIBJMSQueues()など)に置き換える wsadmin内で使用できる以下のSIBusのセキュリティ機能 createSIBus, modifySIBusコマンドの-secureオプション -busSecurityオプションを使用する listInheritSenderForTopic, listInheritReceiverForTopic, listInheritDefaultsForDestinationコマンド isInheritSenderForTopic, isInheritReceiverForTopic, isInheritDefaultsForDestinatonコマン ドに置き換える Inter-engine authentication alias createSIBus, modifySIBusコマンドから-interEngineAuthenticationAliasオプションを削除する WebSphere Application Server V7 Announcement Workshop 2008 # 21 © IBM Corporation. SIBus関連で非推奨となった機能です。 基本的に,wsadminで使用するスクリプトの機能です。WAS上で稼働するアプリ ケーションに影響のある変更はありません。 21 WAS V7で非推奨となった機能(サーバー構成・管理) WAS WAS V7 V7 W/S W/S disablePK54589プロパティ 「disablePK54589=true」を設定している場合には 「isConnectionSharingBasedOnCurrentState=false」に置き換える Core GroupトランスポートのUnicast/Multicast チャネルトランスポートに移行する Collectorツール(collector.bat, collector.sh) IBM Support Assistant(ISA)に統合されているAutoPDツールを使用する ISAについては,以下のサイトを参照 http://www.ibm.com/software/support/isa/ http://www.ibm.com/support/docview.wss?rs=3455&uid=swg27013569 WebSphere Touchpoint機能 標準のWAS管理機能を使用する AdminTaskオブジェクトのSecureConversationコマンドグループ WS-Security分散キャッシュ構成を管理するためにはWSSCacheManagementを使用 する WebSphere Application Server V7 Announcement Workshop 2008 # 22 © IBM Corporation. サーバー構成・管理機能で非推奨となったものです。 比較的影響の大きい変更は,Collectorツールの使用が非推奨となったことです。 問題発生時の情報収集のために,ISAまたはISA Agentをサーバー環境に導入し ておきます。 22 WAS V7で非推奨となった機能(IBM HTTP Server) WAS WAS V7 V7 W/S W/S mod_file_cacheモジュール mod_mem_cacheやmod_cacheなどのキャッシング機能に置き換える mod_ibm_ldapモジュール mod_ldapに置き換える mod_mime_magic・mod_proxy_ftpモジュール これらの使用は推奨されないので,関連ディレクティブを削除する AFPA機能(mod_afpa_cacheモジュール) AFPA(Adaptive Fast Path Architecture)機能は, ほとんどの環境でパフォーマンス上の効果が無く, 様々なトラブルの原因ともなるため,使用は推奨されません WebSphere Application Server V7 Announcement Workshop 2008 # 23 © IBM Corporation. IBM HTTP Serverで非推奨となった機能です。 従来より使用がすすめられていなかったAFPA機能が,正式に非推奨となりました。 23 WAS V7で削除された機能 WAS WAS V7 V7 W/S W/S Java Virtual Machine Profiler Interface (JVMPI) Java Virtual Machine Debug Interface (JVMDI) Java Virtual Machine Tool Interface (JVMTI)を使用する com.ibm.websphere.servlet.filterパッケージのクラス サーブレットAPIで提供されるServletFilterに移行する Integrated Cryptographic Services Facility (ICSF)認証機構 Lightweight Third-Party Authentication (LTPA)認証機構を使用する mb2mdbツール 後継機能は無し Web services gateway customization API JAX-RPC handlerおよびSIBusメディエーションへ移行する com.ibm.websphere.servlet.session.UserTransactionWrapper UserTransactionを直接HttpSessionに格納する com.ibm.websphere.rsadapter.DataDirectDataStoreHelper com.ibm.websphere.rsadapter.ConnectJDBCDataStoreHelperを使用する com.ibm.websphere.rsadapter.MSSQLServerDataStoreHelper com.ibm.websphere.rsadapter.MicrosoftSQLServerDataStoreHelperを使用する WebSphere Application Server V7 Announcement Workshop 2008 # 24 © IBM Corporation. WAS V7で削除された機能です。大部分が,以前のバージョンより非推奨となって いた機能です。 24 WAS V7で削除された機能(JDBCサポート) WAS WAS V7 V7 W/S W/S 以下のJDBC Driverのサポート WebSphere Connect JDBC driver Microsoft SQL Server 2000 Driver for JDBC WebSphere SequeLink JDBC driver for Microsoft SQL Server DB2® Legacy CLI-based Type 2 JDBC Driverのサポート DB2® Legacy CLI-based Type 2 JDBC Driver (XA)のサポート DB2 Universal JDBC Driverを使用する WebSphere Application Server V7 Announcement Workshop 2008 # 25 © IBM Corporation. JDBCでサポートが削除されたものです。 とくに,DB2 Legacy Type 2 Driverがサポートされなくなったことにご注意ください。 25 WAS WAS V7 V7 W/S W/S システム環境のマイグレーション WebSphere Application Server V7 Announcement Workshop 2008 WAS WAS V7 V7 W/S W/S # 26 © IBM Corporation. 26 システムのマイグレーションの概要 WAS WAS V7 V7 W/S W/S WAS V4.0以前からのマイグレーション サーバーの管理トポロジーが根本的に変更になっているため 従来の構成や設定内容,運用スクリプトなどを流用することはできない 新規にアプリケーション実行環境を設計し直す必要がある WAS V5.0からのマイグレーション 基本的な管理トポロジーは変更されてないため,同様の構成を取ることが可能 ツールによるマイグレーションがサポートされていないため, 手動で同様のアプリケーション実行環境を再作成する WAS V5.1/6.0/6.1からのマイグレーション WAS V7.0との共存や相互運用がサポートされる ツールによる既存のアプリケーション実行環境の自動移行が可能 WebSphere Application Server V7 Announcement Workshop 2008 # 27 © IBM Corporation. システム環境の移行については,大きく三つに分けられます。 WAS V4.0以前とV5.0以降では,サーバーの管理トポロジーが根本的に変更され ています。これらのバージョン間では,起動しているプロセスの種類やその役割,出 力されるログの種類と場所,サーバーを管理するためのコマンドの名前や使用方 法,構成情報が保存される場所や方式などが全て異なっています。WAS V4.0以 前のサーバー構成情報や運用・監視手段は,新しい環境に移行することができま せん。完全に新しく設計し直す必要があります。 WAS V5.0以降であれば,構成情報などは新環境に引き継ぐことが可能です。 V5.0はツールによる自動移行ができませんが,V5.1以降ではツールによる移行も サポートされます。 27 参考:WAS V3.5やWAS V4.0 AEの管理トポロジー WAS WAS V7 V7 W/S W/S 管理モデル z z z z z 全てのノードに管理サーバー(AdminServer)が必要 各アプリケーションサーバーは 管理サーバー経由で起動 構成情報はDBMS上に保存 (リポジトリDB) z z Application Server Application Server アプリケーションサーバーは 管理サーバー経由で構成情報を入手 Admin Serverの正常稼働には リポジトリDBの稼働が必須 管理ツール z Administrative Domain Node Node Admin Console Admin Server Admin Server Javaアプリケーションベースの 管理コンソール XMLConfig Admin Console Adminstrative Repository WebSphere Control Program (WSCP) WebSphere Application Server V7 Announcement Workshop 2008 # 28 © IBM Corporation. WAS V4.0以前の管理トポロジーです。 28 参考:WAS V5.0以降の管理トポロジー WAS WAS V7 V7 W/S W/S 管理モデル 各NodeにNode Agentが必要 構成情報はXMLファイルで保存 各Application Serverは個別に 構成ファイルを参照 Cell Node Node Application Server Deployment Managerが マスターの構成を保持し、 Node Agent経由で 各Nodeのファイルを同期 Deployment Managerと 各Node Agentは独立して起動可能 (構成の同期などだけが不可に) 管理ツール Webブラウザベースの 管理コンソール Application Server XML Node Agent XML Node Agent Deployment Manager Admin Console XML wsadminコマンド WebSphere Application Server V7 Announcement Workshop 2008 # 29 © IBM Corporation. WAS V5.0以降のサーバー管理トポロジーです JMXを使用して各サーバーが連携するようになり,リポジトリDBが必要なくなりまし た。また,サーバー間の依存関係が無くなるなど,多くの改良が行われました。この 管理トポロジーは最新のWAS V7.0まで基本的には変わっていません。 29 混合バージョンセルのサポート WAS WAS V7 V7 W/S W/S WAS V7.0のDeployment Managerは, V5.1,V6.0,V6.1のノードを含むことができる ただし,6.0.0.xおよび6.0.1.xの ノードは管理することがでない かならず修正パッチを当てて 6.0.2.xにあげておく必要がある Deployment Managerは, 各ノードよりもバージョンが 上でなければならない V7 Deployment Manager V6 V7 NodeAgent NodeAgent 混合セルを使用した マイグレーションの手順例 1. Deployment Managerを WAS V7にマイグレーションする 2. Cell内のNodeを,クラスター単位で V7にマイグレーションする J2EE Apps (EARs) Config Files V6 V6 … Application Application Server Server V6 V6 V7 V7 Application Application Server Server V6 Node V6 Config Files J2EE 1.4 Apps … Application Application Server Server V7 V7 Application Application Server Server V7 Node Cell V7 Config Files WebSphere Application Server V7 Announcement Workshop 2008 Java EE 5 Apps # 30 © IBM Corporation. WAS V7.0では,一つのセル内に旧バージョンのノードも同居させることができます。 これにより,複数サーバーで構成された環境を段階的にマイグレーションすることが できます。 30 混合バージョンセルの注意事項 WAS WAS V7 V7 W/S W/S 混合バージョンセルは, マイグレーション中の一時てきな構成として使用する 混合セルのまま,長期運用することは避ける 混合セルでは,アプリケーションサーバーの作成などに制限がある Nodeをマイグレーションした直後は, syncNodeコマンドを使用して手動で同期を行う必要がある場合も 一つのアプリケーションが実行されているクラスター内に, 複数のバージョンのWASが混在する構成は避ける HttpSessionの内容を新旧バージョン間で共有することなどはできない トラブルを避けるために, 既存の環境は最新のFixPackを適用しておくことが望ましい WebSphere Application Server V7 Announcement Workshop 2008 # 31 © IBM Corporation. 混合セル環境には,可能な管理操作に制限があるため,そのまま長期運用を行う ことは推奨されません。あくまで,マイグレーションの際の一時的な構成として使用 するようにします。 31 同一サーバー上での異なるWASバージョンの共存 WAS WAS V7 V7 W/S W/S インストール時の導入ディレクトリを変更することで, 旧バージョンを残したまま,WAS V7.0を導入することが可能 逆に,同じディレクトリに上書き導入はできない WAS 5.0以降が導入されている環境では, 使用しているポート番号を自動認識し, 異なるポートを使用してサーバーが 起動するように構成できる プロファイル管理ツールで プロファイルを作成する際に選択できる 既存環境を無視して デフォルト構成で作成もきできる WebSphere Application Server V7 Announcement Workshop 2008 # 32 © IBM Corporation. WAS V5.0以降は,導入ディレクトリを変更することで,同一のサーバー筐体上に 複数のバージョンのWASを導入することができます。そのような環境では,WASは 既存環境を自動的に認識し,共存が可能となるよう,すでに使用されているポート を避けて構成を作成する機能があります。 32 ツールによる既存WAS環境のマイグレーション WAS WAS V7 V7 W/S W/S V5.1およびV6.0/V6.1からのマイグレーションがサポートされる マイグレーション・ツールにより既存環境から構成情報を抽出し, 新規導入されたV7.0のプロファイルに適用することができる 既存環境とは別のディレクトリにV7.0を導入し,プロファイルを作成する そのプロファイルに,既存環境の情報がコピーされる 既存環境を上書きしないので,トラブル発生時の切り戻しが容易 アプリケーションを移行するかどうかを選択可能 アプリケーションが新旧バージョンで互換性がある場合, ツールにより新環境へ自動的にコピーさせることができる 互換性がなく,アプリケーションの修正が必要な場合は, ツールによるコピーは行わず, 別途,新環境に修正後のアプリケーションを再デプロイする WebSphere Application Server V7 Announcement Workshop 2008 # 33 © IBM Corporation. 既存のWAS環境を構成情報などを新環境に移行するツールが提供されます。 このツールによるマイグレーションでは,既存のWAS環境のファイルを上書きする のではなく,別ディレクトリに導入された新環境に旧環境の構成情報がコピー・反映 されます。旧環境がそのまま残るため,トラブルが発生した際の旧バージョンへの 切り戻しなどが簡単にできます。 33 マイグレーションツール WAS WAS V7 V7 W/S W/S コマンドラインツール WASPreUpgrade / WASPostUpgrade GUIツール マイグレーションウィザード コマンドラインツールのフロントエンド・プログラム 指定されたパラメーターでWASPreUpgradeとWASPostUpgradeが実行される Profileの新規作成も行える WebSphere Application Server V7 Announcement Workshop 2008 # 34 © IBM Corporation. マイグレーションのツールは,コマンドラインのツールとGUIを使用したツールの二 種類が提供されます。後者は前者のフロントエンド・プログラムであり,実際にはコ マンドラインツールによって全ての移行作業が行われます。 34 ツールによるマイグレーションの概要 WAS WAS V7 V7 W/S W/S 1. WAS V7インストール 2. プロファイルの作成 WAS V7 Application Server V7 3. 旧WASプロセスの停止 WAS V5/6 Application Server 5. WASPostUpgradeの実行 バックアップ ファイル 4. WASPreUpgradeの実行 Migrated WAS V7 Application Server 6. WAS V7プロセスの起動 WebSphere Application Server V7 Announcement Workshop 2008 # 35 © IBM Corporation. ツールによるマイグレーションの概要です。 まず,既存環境にWAS V7.0を別ディレクトリを指定して導入し,そこで新規にプロ ファイルを作成します。旧バージョンのプロセスを停止した状態で WASPreUpgradeを実行すると,旧環境の構成情報が抽出され,バックアップファ イルに保存されます。次にWASPostUpgradeを実行すると,バックアップファイル が読み込まれ,その内容がWAS V7.0のプロファイルに反映されます。この後, WAS V7.0のプロセスを起動すると,旧バージョンの構成を引き継いだ新サーバー が稼働することになります。 35 マイグレーションウィザードによる移行(1) 複数バージョンが導入されている場合 マイグレーション対象(ソース)を 選択することができる WAS WAS V7 V7 W/S W/S WAS V6.0/6.1では, 移行対象のプロファイルを選択する WebSphere Application Server V7 Announcement Workshop 2008 # 36 © IBM Corporation. マイグレーションウイザードによる移行の画面です。 36 マイグレーションウィザードによる移行(2) 移行先のプロファイル(ターゲット) を選択する 新しいプロファイルの作成を 指定することもできる WAS WAS V7 V7 W/S W/S 移行に使用するディレクトリを指定 このディレクトリに バックアップが作成される このディレクトリのしたの logsディレクトリに経過が記録される WebSphere Application Server V7 Announcement Workshop 2008 # 37 © IBM Corporation. 移行先のWAS V7.0のプロファイルは,既存のものを使用することもできますし,新 規に作成することもできます。既存のものを指定した場合,現在のプロファイルを backupConfigコマンドでバックアップさせることもできます。 また,ここで指定したバックアップディレクトリに,各種の構成ファイルを格納した バックアップファイルが作成されます。後述するように,このディレクトリのファイルを 別サーバーにコピーして,そこで新環境に反映させることもできます。また,この ディレクトリにはコマンド実行時のログファイルも記録されます。実際に WASPreUpgradeとWASPostUpgradeが実行されたときのコマンドライン引数など も参照することができますので,テスト環境で実施したマイグレーションを本番環境 で実行する際の参考などにも利用できます。 37 マイグレーションウィザードによる移行(3) WAS WAS V7 V7 W/S W/S 他にも以下のような項目を指定可能 アプリケーションを移行するかどうか 移行後のアプリケーションのディレクトリ 移行後のポートを変更するか,以前のものを使うか 管理コンソールのカスタマイズ情報を移行するか スクリプトの互換性を維持するか WebSphere Application Server V7 Announcement Workshop 2008 # 38 © IBM Corporation. その他,後続の画面では各種の指定を行うことができます。 38 マイグレーションウィザードによる移行(4) WAS WAS V7 V7 W/S W/S 指定された内容でWASPreUpgradeがバックグラウンドで実行され 続いてWASPostUpgradeが実行される WebSphere Application Server V7 Announcement Workshop 2008 # 39 © IBM Corporation. 「マイグレーションの要約」画面で「次へ」をおすと, WASPreUpgradeと WASPostUpgradeが順次実行されます。 39 ツールによるマイグレーションの注意点 WAS WAS V7 V7 W/S W/S アプリケーションが多数導入された大規模なCellのマイグレーションでは, 通信タイムアウトによりWASPostUpgradeの実行に失敗することがある <WAS Root>/properties/ssl.client.props を編集し, com.ibm.SOAP.requestTimeout の値をデフォルトの180秒から10倍程度に増やす 旧環境の動いているOSがWAS V7でサポートされない場合 異なる物理筐体にWAS V7を導入する場合 サプリメントディスクにあるmigration/binディレクトリには, ディスクから直接起動できるマイグレーションツールが収録されいている ディスクに収録されいているJDKが稼働しない場合には,別途JDK 1.6を用意し, ツールをHDD上にコピーのうえ,setupCmdLine.batまたはsetupCmdLine.shを編集して起動する ここからWASPreUpgradeコマンドを実行して現環境をバックアップする 新しいOSを導入した環境にWAS V7をセットアップする バックアップされたファイルを新環境に転送し,WASPostUpgradeを実行 WebSphere Application Server V7 Announcement Workshop 2008 # 40 © IBM Corporation. マイグレーションにあたってOSも入れ替える場合には,旧環境でマイグレーション ツールのみを実行し,バックアップファイルを作成しておくことに夜以降も可能です。 ただし,移行前後のホスト名などの情報は同じになるようにしておきます。ホスト名 などが異なる場合には, WASPreUpgradeの引数の変更が必要となります。 40 ツールによるマイグレーションの注意点(1) WAS WAS V7 V7 W/S W/S Cell環境のマイグレーション 移行後のセル名・ノード名は,移行前と同じにしておく必要がある SSL証明書および鍵管理 使用していたSSL証明書はそのままインポートされる WAS 7.0から採用された階層付きの証明書の構成にはならない WAS 6.1までのデフォルトの環境では自己署名証明書が使用されている 必要であれば,wsadminのconvertSelfSignedCertificatesToChainedタスクを使用して, 自己署名証明書を階層付き証明書に変換する 変換しない場合,証明書の自動更新によるアクセス障害などに注意する WAS 7.0では,署名者証明書(Root証明書)がデフォルトで15年間の有効期限を持つため, 個人証明書が1年ごとに更新されても,証明書の検証失敗による接続障害は起こらない 非rootユーザーで導入された環境 いったんrootユーザーのプロファイルへマイグレーションする その後,非rootユーザーへファイルの所有権・アクセス権を変更する WebSphere Application Server V7 Announcement Workshop 2008 # 41 © IBM Corporation. ツールによるマイグレーションを行った際の注意点です。 WAS V7.0の証明書管理機能で作成される証明書は,以前のバージョンとは異な り,階層付きの証明書になっています。つまり,有効期限の長いルート証明書がコ ンポーネント間で共有され,実際にSSL通信を行うための証明書はルート証明書に よって署名された証明書が使用されるようになっています。これにより,通信につか う証明書を一定期間ごとに更新を行いつつ,証明書の更新に伴う諸問題を回避す ることができるようになりました。 これに対し,WAS V6.1で作成される証明書は全て自己署名証明書になっていま す。証明書の検証には,その証明書自体の情報が必要となります。またWAS V6.0 までは,WAS出荷時に作成された自己署名証明書が同梱されており,これがSSL 通信に使用されています。 マイグレーションツールを使用した移行では,これら以前の証明書環境がそのまま 移行されます。階層付きの証明書を使うよう環境を変更するためには, wsadminの convertSelfSignedCertificatesToChainedタスクを使用して手動で証明書を変換 する必要があります。 41 ツールによるマイグレーションの注意点(2) WAS WAS V7 V7 W/S W/S HA ManagerのCore Group WAS 5.1からのマイグレーションでは, 全体が単一のCore Groupにマイグレーションされる Cell内のNode数やApplication Server数が多い場合, Core Groupを適切に分割してパフォーマンスへの影響を避ける プラグイン構成ファイル WAS V5.1からマイグレーションされた環境では, 生成されるPlug-in.cfgには,全てのアプリケーションが含まれている WAS V6.0以降では、特定のアプリケーションを特定のWebサーバーにのみ 割り当てることができるようになっている WAS V5.1のトポロジー WAS V6.0以降で可能なトポロジー Webサーバー Application Webサーバー Application Webサーバー Application Webサーバー Application Webサーバー Application Webサーバー Application WebSphere Application Server V7 Announcement Workshop 2008 # 42 © IBM Corporation. ツールによるマイグレーションを行った際の注意点です。 WAS V6.0からHA Managerが実装され,WASのプロセス間では互いの生存確認 が行われるようになっています。この通信の負荷は,HA Managerの構成単位であ るCore Groupに参加しているプロセスの数に応じて幾何級数的に増加する特性を 持っています。ノードやサーバーが多数ある環境でマイグレーションを行った際に は,Core Groupに属するプロセス数が30~50程度になるように適切に分割します。 42 Summary WAS WAS V7 V7 W/S W/S WAS V7.0は,V6.1と高いレベルのアプリケーション互換性がある 既存アプリケーションは, WAS V6.1へマイグレーションすれば,WAS V7.0でも稼働する 非推奨となった機能,削除された機能を使用している場合は対処が必要 システム環境の移行はWAS 5.1以降からがサポートされる WebSphere Application Server V7 Announcement Workshop 2008 # 43 © IBM Corporation. 43 Reference WAS WAS V7 V7 W/S W/S Information Center “Migrating, coexisting, and interoperating” http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ib m.websphere.nd.multiplatform.doc/info/ae/ae/welc6topmigrating.html Knowledge Collection: Migrating WebSphere Application Server http://www.ibm.com/support/docview.wss?rs=180&uid=swg21318221 Knowledge Collection: Migrating to (or from) WebSphere Application Server V7.0 http://www.ibm.com/support/docview.wss?rs=180&uid=swg27013842 WebSphere Application Server Version 6.1へのマイグレーションガイド http://www.ibm.com/developerworks/jp/websphere/library/was/was61_m igration/ WebSphere Application Server V7 Announcement Workshop 2008 # 44 © IBM Corporation. 44 資料の変更略歴 1.0 2008-10-17 1.1 2008-10-19 1.1a 2008-10-20 WAS WAS V7 V7 W/S W/S 最初の公開バージョン スピーカーノート/Referenceを追加,ミスを修正 誤字を修正 WebSphere Application Server V7 Announcement Workshop 2008 # 45 © IBM Corporation. 45