レベル: 中級 Tom Alcott, Consulting IT Specialist, IBM
2009年 5月 20日 IBM® WebSphere® Application Server構成を移動する場合や、ご使用の環境をマイグレーションする場合には、ホスト名を変更したり、別のマシンへプロファイルを移行する必要が生じる場合があります。WebSphere Application Server のバージョン 5.x、6.x、7 でこれを行う方法について、WebSphere Contrarian が説明します。
WebSphere Contrarian の各コラムでは、WebSphere 製品群の使い方に関する質問に答え、指針を示し、また基本的な話題について論じています。多くの場合、提供される助言は現場での実績に基づいている反面、一般的な見識には反することがあります。
変更が必要になった場合には
ギリシャの哲学者ヘラクレイトスによる「万物は流転する」という言葉が 2500 年以上もの間、真実であったように、皆さんはある時点で WebSphere Application Server システムのホスト名を変更する必要に迫られるかもしれません。これに関して寄せられる質問の数から判断すると、この問題は一般的に起こるもののようです。「ホスト名をどのように変更するのか」という質問に関連して、例えば 1つのテスト環境から別のテスト環境へのマイグレーションに際し、「どのようにして WebSphere Application Server のプロファイルをあるマシンから別のマシンに移動するのか」という似た質問もあります。理想的なのは、すべての構成手順を wsadmin によってスクリプト化しておき、あとは新しいホスト名を使ってスクリプトを再度実行するだけ、という状態にしておくことです。ホスト名の変更や環境のマイグレーションに備えて、包括的なスクリプト・ライブラリーを維持しているユーザーも多数います (そして皆さんも、この記事を読んだ後はそうした人々の輪に加わることになるでしょう)。しかし、スクリプトがない場合にはどうすればよいのでしょうか。幸い、WebSphere Application Server V6.x と V7 には、この両方のタスクを支援する機能がいくつか用意されています。(また、WebSphere Application Server のバージョンを、サポートが有効なリリースにアップグレードすることを怠っているユーザーのために、V5.x のホスト名を変更する方法についても説明します。)
ホスト名を変更する
まず簡単なことから始めることにして、セルの中にあるデプロイメント・マネージャー・マシンのホスト名を変更しましょう。最初の構成を図1に示します。この図では、デプロイメント・マネージャー・ノード SONOMACellManager01 が SONOMA.xd61stew.ibm.com というホスト上にあります。
図1. 最初の構成
デプロイメント・マネージャーを停止したら、変更を加える前に、その都度 WebSphere Application Server のバックアップ・ユーティリティー backupConfig.(sh/bat) を使って構成をバックアップしておくことをお勧めします (リスト 1)。ここで何か問題が起こることが予想されるわけではありませんが、いざという場合に出発点までリカバリーできるよう、常に備えておくことが得策です。
リスト 1
SONOMA:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin #
./backupConfig.sh /root/FullSonomaCellBackup.zip
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/backupConfig.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU5001I: Backing up config directory
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config to file
/root/FullSonomaCellBackup.zip
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: dmgr
ADMU2010I: Stopping all server processes for node SONOMACellManager01
ADMU0512I: Server dmgr cannot be reached. It appears to be stopped.
.....................................................................................
ADMU5002I: 939 files successfully backed up
SONOMA:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin # |
ここで、WebSphere プロセスには接続せずに wsadmin を起動します。そのためには -conntype NONE を指定します (リスト 2)。
リスト 2
SONOMA:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin # ./wsadmin.sh -conntype NONE
-lang jython
WASX7357I: By request, this scripting client is not connected to any server process.
Certain configuration and application operations will be available in local mode.
WASX7031I: For help, enter: "print Help.help()"
wsadmin> |
これまで、デフォルトの Jacl の代わりに Jython を使って wsadmin を実行したことがなかった場合には、下記のようないくつかのメッセージが表示されるはずです。これは Jython JAR ファイルが初めて処理されることを示しています。
*sys-package-mgr*: processing new jar,
'/opt/IBM/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy
/runtime/batch.jar' |
wsadmin が作動可能になったら、AdminTask オブジェクトに対してユーティリティー・コマンド changeHostName を呼び出します。リスト 3 に示した AdminTask の出力を見ると、interactive (対話) モードであることがわかります。このモードでは、ユーザーに入力を促し、その入力に基づいて wsadmin コマンドを作成します。
ここでは、ホスト名を「SONOMA.xd61stew.ibm.com」から「NAPA.xd61stew.ibm.com」に変更しています (図 1)。nodeName 引数には wsadmin に対して、どのノードを変更するのかを指定します (この例では、デプロイメント・マネージャーをホストするノード)。一方 host name 引数には新しいホスト名を指定します。リスト 3 を見るとわかるように、この変更の一部として SSL 証明書も再生成しています。また、ユーザー入力に基づいて AdminTask により生成されたコマンドが表示されていることにも気付くと思います。このコマンドは、コピーしてファイルに保存しておけば、後から使用することができます。ここでは、AdminTask により生成されたコマンドの実行後、変更を保存し、wsadmin を終了します。
リスト 3
wsadmin>AdminTask.changeHostName ('[-interactive]')
Change Host Name
Change the host name of a node
*Node Name (nodeName): SONOMACellManager01
*Host Name (hostName): NAPA.xd61stew.ibm.com
System Name (systemName): SONOMA
Regenerate Certificates (regenDefaultCert):
Change Host Name
F (Finish)
C (Cancel)
Select [F, C]: [F] F
WASX7278I: Generated command line: AdminTask.changeHostName
('[-nodeName SONOMACellManager01
-hostName NAPA.xd61stew.ibm.com -systemName SONOMA ]')
''
wsadmin>AdminConfig.save()
''
wsadmin>exit |
デプロイメント・マネージャーを再起動すると、管理コンソールに変更が反映されていることがわかります (図 2)。図 2に示されるとおり、デプロイメント・マネージャー・ノードのホスト名は「NAPA.xd61stew.ibm.com」になっています。ホスト名の入力を間違えると、おそらくデプロイメント・マネージャーは起動することができませんので注意してください。その場合は、ログを調べる必要があります。新しいホスト名の入力を間違えたことを示すメッセージの 1 つとして、下記が挙げられます。
<your new host name> and the exception is java.net.UnknownHostException:
もう1つ、関連するものとして、下記のエラー・メッセージがあります。
Host name <your new host name> is not registered in DNS.
これらのメッセージが表示された場合には、単純に AdminTask.changeHostName を再度実行して、新しいホスト名を正しく入力し、先ほどと同じように保存して終了します。
図 2. ホスト名を変更した後の構成
またこの時に、すべてのノード・エージェントを 1つずつ停止し、新しいデプロイメント・マネージャーのホスト名を使って syncNode を実行します (リスト 4)。syncNode の実行が終了したら、ノード・エージェントを起動します。
リスト 4
AVALON:/opt/WAS70/AppServer\profiles/AppSrv01/bin>./syncNode.sh NAPA
ADMU0116I: Tool information is being logged in file
/opt/WAS70/AppServer/profiles/AppSrv01/logs/syncNode.log
ADMU0128I: Starting tool with the AppSrv01 profile
ADMU0401I: Begin syncNode operation for node AVALONNode01 with Deployment
Manager NAPA: 8879
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0402I: The configuration for node AVALONNode01 has been synchronized with
Deployment Manager NAPA: 8879 |
新しいホストにプロファイルを移動する
当然のことながら、サーバー上に WebSphere Application Server などのミドルウェアを保持したまま単純にホスト名を変更する必要がある、ということはあまりありません。実際には、あるマシンから別のマシンにランタイムを移動する必要があり、その手順の一部としてホスト名の変更が必要、という状況の方が一般的です。ここで例えば、単純に既存のサーバーのホスト名を「SONOMA」から「NAPA」に変更するのではなく、実際にデプロイメント・マネージャー (または他の WebSphere Application Server プロセス) をあるマシンから別のマシンに移動し、WebSphere Application Server の構成を変更して新しいサーバーのホスト名を反映させる、ということを考えてみましょう。manageprofiles コマンドを AdminTask.changeHostName と組み合わせて使うと、まさにそれを行うことができます。
この手順を開始するために、サーバー上で実行しているすべてのプロセスを停止し、そして manageprofiles コマンドを backupProfile オプション付きで実行します。その際、バックアップ対象のプロファイルと任意のファイル名を指定します (リスト 5)。
リスト 5
SONOMA:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin # ./manageprofiles.sh
-backupProfile -profileName Dmgr01 -backupFile /root/SONOMADmgr01Backup.zip
INSTCONFSUCCESS: Success: The profile backup operation was successful. |
バックアップが終了したら、適当なファイル・コピー・ユーティリティーを使って元のサーバーから新しいサーバーにバックアップ・ファイルを転送します。新しいサーバーには WebSphere Application Server をインストールしておく必要がありますが、プロファイルを作成しておく必要はありません。ただし、転送をスムーズに行うには、1 点準備が必要です。その準備とは、ターゲット・システムのディレクトリー構造を、ソース・システムのディレクトリー構造と一致させておくことです。WebSphere Application Server V7 では、WAS_HOME ディレクトリーの場所を指す、ハードコーディングされたディレクトリー・パスの大部分を廃止したようですが (すべて廃止したわけではありません)、Version 6.1 の場合は、そのような箇所が合計で200以上ありました。その結果、マシン間でディレクトリー構造を同じに維持していない場合には、ディレクトリー構造と、setupCmdLine.sh(bat) および variables.xml 内に記述されたディレクトリー・パスへの参照を、手動で変更しなければなりません。当然ですが、この記事ではそうした 200 以上の場所やそれらの変更方法を説明するつもりはありません。代わりに、ここでは単純に、ソース・マシンとターゲット・マシンで WebSphere Application Server を必ず同じ場所にインストールすることをお勧めします。そのようにした上で、restoreProfile オプションを指定して manageprofiles を実行します (リスト 6)。
リスト 6
NAPA:/opt/IBM/WebSphere/AppServer/bin # ./manageprofiles.sh -restoreProfile
-backupFile /root/SONOMADmgr01Backup.zip
INSTCONFSUCCESS: Success: The profile was successfully restored. |
次に、先ほど説明したように単純に wsadmin AdminTask.changeHostName コマンドを実行し、変更を保存して終了します。これで、新しいサーバーでデプロイメント・マネージャー (または他の WebSphere Application Server プロセス) を起動する準備がほぼ整いました。構成のうち、WebSphere Application Server のプロファイルの外部に存在するもの (例えば、デフォルトではない場所に展開されたアプリケーション、共有ライブラリーの JAR、JDBC プロバイダーが使用するデータベース・ドライバー、スタンドアロンのコネクター・モジュールなど) は、すべて手動でコピーする必要があります。また、Sun™ Solaris™ または HP の JDK を使用するマシンと、IBM の JDK を実行するマシンとの間での移動の場合には、JVM 設定の中の Sun、HP、または IBM の JDK 特有の -X フラグも、すべて手動で変更する必要があります。
このセクションの最後に、上記の手順は WebSphere Application Server の構成を 32 ビットのインストール環境から 64 ビットのインストール環境に移動する際、もしくはその逆の場合にも使用することができるということを述べておきます。なぜ 64 ビット環境から 32 ビット環境に移動する必要があるのか、と疑問に思う人がいるかもしれませんが、それはテストの結果、64 ビットでのパフォーマンスが期待ほどではない、ということもあるからです。これにはいくつかの原因が考えられます。それについてはこちらで説明されています。
別の方法
AdminTask.changeHostName コマンドの代替として、WebSphere Application Server V7 の機能である、プロパティー・ファイル・ベース構成ユーティリティーを使う方法があります。この場合にもやはり、構成を抽出し、変更を検証して適用するために wsadmin を使用します。
先ほどと同じように、変更されるプロセスを停止した状態で、接続はせずに (-conntype NONE) wsadmin を起動します。今度は、下記のように AdminTask の extractConfigProperties ユーティリティーを呼び出します。
リスト 7
wsadmin >AdminTask.extractConfigProperties('[-propertiesFileName /root/
SONOMA.cell.props]') |
この例では、SONOMA.cell.props というプロパティー・ファイルが作成され、これは任意のテキスト・エディターで編集することができます。変更前のホスト名を探します。この場合は「SONOMA.xd61stew.ibm.com」です (リスト8)。このホスト名を新しいホスト名に変更し、ファイルを保存して、終了します。
リスト 8
# End of Section 1.0# Cell=!{cellName}
#
#
#
EnvironmentVariablesSection
#
#
#Environment Variables
nodeName=AVALONNode01
applicationName3=isclite
applicationName2=ibmasyncrsp
applicationName1=WebSphereWSDM
serverName3=nodeagent
serverName2=dmgr
serverName1=clusterserver2
serverName=clusterserver1
nodeName2=SONOMACellManager01
nodeName1=AVALONNode02
applicationName=DefaultApplication
cellName=SONOMACell01
coreGroup=DefaultCoreGroup
hostName=AVALON.xd61stew.ibm.com
nodeGroup=DefaultNodeGroup
hostName6=${LOCALHOST_NAME}
clusterName=defaultcluster
hostName5=SONOMA.xd61stew.ibm.com
hostName4=localhost
hostName3=232.133.104.73
hostName2=ff01::1
hostName1=* |
このファイルを編集した後、以下のようにさらに 3つの wsadmin コマンドを実行し、wsadmin を終了します (リスト 9)。
AdminTask.validateConfigProperties は加えられた変更を検証します。AdminTask.applyConfigProperties は加えられた変更をリポジトリーに適用します。AdminConfig.save は適用された変更を保存します。
リスト 9
wsadmin> AdminTask.validateConfigProperties('[-propertiesFileName
/root/SONOMA.cell.props ]')
'true'
wsadmin> AdminTask.applyConfigProperties('[-propertiesFileName
/root/SONOMA.cell.props ]')
''
wsadmin>AdminConfig.save()
''
wsadmin>exit |
先ほどと同じように、変更が完全に伝搬されるように各ノード・エージェントを停止した後、デプロイメント・マネージャーを起動して syncNode を実行し、ノード・エージェントを再起動します。
非常に古いバージョンの場合
もはやサポートされていないにもかかわらず、いまだに WebSphere Application Server V5.x が稼働していて、その環境に変更を加える必要があるという場合にも、使用できるツールはいくつかあります (ただしそれらのツールは V6.x や V7.0 に使われるものとは異なります)。WebSphere Application Server V5.x で既存のシステムのホスト名を変更するためには、V7.0 でのノード・ホスト名の変更と同じ手順を用いることができます。この手順では wsadmin の Jython 構文が提供されていますが、V5.x の wsadmin は Jacl を使います。そのため Jacl 構文に変更したものをリスト 10 に示します。
リスト 10
wsadmin>$AdminConfig list ServerIndex
(cells/AvalonNetwork/nodes/Avalon:serverindex.xml#ServerIndex_1)
(cells/AvalonNetwork/nodes/AvalonManager:serverindex.xml#ServerIndex_1)
wsadmin>$AdminConfig modify (cells/AvalonNetwork/nodes/AvalonManager:serverindex.xml
#ServerIndex_1) {{hostName AVALON.xd61stew.ibm.com}}
wsadmin>$AdminConfig save |
上記のようにホスト名を変更する方法の他に、ホスト名の変更に使用できる wsadmin のための一連のサンプル・スクリプトが WebSphere Application Server V7.0 のインフォメーション・センターに用意されています。
まとめ
この記事から、よくある 2 つの変更をどのように処理すればよいかを WebSphere Application Server の観点から理解できたと思います。万物は流転し、その変化が必ずしも悪、あるいはハッブル定数のように難解であるとは限らないのです。
謝辞
助言とコメントをいただいた Ajay Apte と Keys Botzum の両氏に感謝いたします。
参考文献
著者について  | 
| | Tom Alcott は、米国 IBM のコンサルティング IT スペシャリストです。彼は Worldwide WebSphere Technical Sales Support チームが 1998年に発足して以来のチーム・メンバーであり、その知識においてお客様よりも常に一歩先を行くよう心がけています。彼は WebSphere を担当する以前は IBMの Transarc Lab で TXSeries をサポートするシステム・エンジニアでした。これまで、メインフレーム系のシステムと分散システムの両方で 20 年間以上、アプリケーション設計と開発に従事した経験を有します。彼は WebSphere のランタイムの問題に関して、幅広く執筆と発表を行ってきています。 |
記事の評価
| 
