Edge ComponentsのV5.1からV6.0/6.1/7.0へのバージョンアップに関する既知の考慮点 (WAS-08-040)

2008年9月26日をもちまして、WAS V5.1のサポートが終了となります。WAS NDの同梱ソフトウェアであるEdge Componentsに関してもサポートが終了となりますので、現在V5.1を使用している場合は早急なバージョンアップが推奨されます。本文書では、V5.1からV6.0/6.1へのバージョンアップに関する既知の考慮点をお知らせします。

内容/目次

更新ログ

(2009/08/24 14:51) リンク修正。
(2009/09/17 11:43) V7.0についての記述を追加

【概要】
2008年9月26日をもちまして、WAS(WebSphere Application Server) V5.1のサポートが終了となります。
WAS ND(Network Deployment)の同梱ソフトウェアであるEdge Componentsに関してもサポートが終了となりますので、現在V5.1を使用している場合は早急なバージョンアップが推奨されます。
本文書では、V5.1からV6.0/6.1/7.0へのバージョンアップに関する既知の考慮点をお知らせします。

【対象S/W・転送方式】
Edge Components Load Balancer V5.1を使用している環境

【詳細】
Edge Components V6.1ではMAC転送以外の転送方式がDeprecation(廃止予定)となりました。
MAC転送以外の転送方式を使用している環境では、MAC転送方式へのマイグレーションが推奨されます。
非推奨機能の詳細につきましては以下のリンクをご参照ください。

WAS 6.1 Information Center - 非推奨のフィーチャーと除去されたフィーチャー

また、V6.0.2からはIPv6に対応した新しいLoad BalancerであるLoad Balancer for IPv4 and IPv6（以下、IPv6版）が提供されています。
IPv6版はIPv4環境でも使用可能であり、今後はIPv6版への移行が推奨となります。
従来のLoad BalancerであるLoad Balancer for IPv4（以下、IPv4版）とIPv6版では多くの変更点があるために、使用する際は考慮が必要ですが、本テクニカルフラッシュではIPv6版へのマイグレーションは対象としていません。
本文書では、Edge Components Load Balancer V5.1でMAC転送を使用しているお客様が、トポロジーを引き継いでV6.0/6.1/7.0のLoad Balancer for IPv4へバージョンアップするにあたり、既知のソフトウェアの変更点などについてお知らせします。

[ Edge Componentsの構成ファイルについて ]
V5.1からV6.0/6.1/7.0のバージョンアップにあたり、基本的には大きな変更はありません。
構成ファイルやgoActive等のスクリプトファイルは、多くの場合そのまま、あるいは少しの変更で使用することができます。

実際に読み込まれる構成ファイルは、起動方法によって異なります。
Load Balancerは、通常、以下のいずれかの方法で起動・構成します。

2および3のケースでは、構成ファイルは以下のパスに保管されます。

<EDGE_ROOT>/lb/servers/configurations/dispatcher/

また、goActive等のスクリプト・ファイルは以下のパスに保管されます。

<EDGE_ROOT>/lb/servers/bin/

なお、<EDGE_ROOT>のデフォルトは各OSでそれぞれ以下となっています。

AIXおよびLinux　　　/opt/ibm/edge/

Windows　　　　　　　C:\Program Files\IBM\edge\

[ Edge Componentsのバージョンアップに伴うソフトウェアの変更点について ]
V5.1からV6.0/6.1での変更点については、Load Balancer管理ガイドの記述をご参照ください。
<V5.1->V6.0.2の変更点>

Load Balancer 管理ガイドバージョン 6.0.2 - 6.0.2の新規機能

V6.0.2->V6.1の変更点

Load Balancer 管理ガイドバージョン 6.1 - 6.1の新規機能

V6.1からV7.0については基本的に変更がなく、Load Balancer for IPv4管理ガイドには新機能についての記述がありません。
※Load Balancer for IPv4 and IPv6管理ガイドには新機能についての記述がありますが、これはIPv6版のV6.1からIPv6版のV7.0へのバージョンアップに伴う新機能となります。

上記の管理ガイドの記述以外に、以下のようないくつかの変更点が確認されておりますので、こちらにも注意が必要です。

1) HTTPアドバイザーの監視リクエストの宛先アドレスの変更
V5.1では、HTTPアドバイザーの監視リクエストの宛先は、割り振り先サーバーのループバック・インターフェースに設定されているクラスター・アドレスとなっていました。
V6.0/6.1では、Httpアドバイザーの監視リクエストの宛先は、サーバーの実IPアドレスとなります。
(※V6.0のAIXに関してはFixで対応していますので、以下のリンクをご参照ください。)

この変更に伴い、割り振り先のIHS (IBM HTTP Server) では、実IPアドレスへのリクエストを処理可能とするため、ListenディレクティブでサーバーのIPアドレスまたはワイルド・カードにて、指定する必要があります。
手順の詳細については以下のリンクをご参照ください。

WAS Edge Componentのアドバイザーの挙動変更についての注意点 (WAS-06-001)

2) dscontrol server down時のアドバイザーの挙動変更
dscontrol server downコマンドで明示的にサーバーをdown状態に設定した場合、V5.1ではアドバイザーによる監視も停止していました。
そのためv5.1ではdscontrol manager reportでport値は-1と表示されます。
V6.0/6.1ではdown状態に設定した場合でも、アドバイザーによる監視は停止しません。
そのためport値にも正の値が表示されます。

3) アドバイザーのUser-Agentの変更
HttpアドバイザーとHttpsアドバイザーのUser-Agentが変更になっています。

V5.1

IBM_Network_Dispatcher_HTTP_Advisor

IBM_Network_Dispatcher_Https_Advisor

V6.0/6.1/7.0

IBM_

Load_Balancer

_HTTP_Advisor

IBM_

Load_Balancer

_Https_Advisor

4) Windows環境でのクラスター・アドレスの設定方法について
Windowsの場合、V5.1ではdscontrol executor configureをすると、クラスター・アドレスはネットワーク・インターフェースには定義されず、arpテーブルに静的エントリとして直接定義されます。
このエントリはarp -aコマンドで確認することができます。
V6.0/6.1/7.0ではクラスター・アドレスはarpテーブルではなくネットワーク・インターフェースに定義されます。
ipconfigコマンドでこのアドレスは確認することができます。
dscontrol executor configureコマンドでは、引数でインターフェースを指定できますので、ネットワーク・インターフェースが複数ある環境ではクラスター・アドレスを追加するインターフェースを明示的に指定するようにしてください。

Load Balancer 管理ガイドバージョン 6.0.2 - ステップ 5. ネットワーク・インターフェース・カードの別名割り当て

Load Balancer 管理ガイドバージョン 6.1 - ステップ 5. ネットワーク・インターフェース・カードの別名割り当て

5) コマンドの出力の変更
dscontrol(旧ndcontrol)コマンドの出力はバージョンによって差異があります。
コマンドの出力結果を監視している場合など、必ず対象のバージョンで出力を確認するようにしてください。

※なお、上記は全ての変更点を網羅しているわけではなく、仕様として明記されていない部分で他にも変更点がある可能性があります。
実際のマイグレーションに当たっては、必ず、十分なテストを実施してください。

[ Edge Componentsのバージョンアップ手法について ]
Edge ComponentsとIHS/WASにはバージョン間の依存関係はありませんので、Edge ComponentsとIHS/WASのバージョンアップは別々に実施することが可能です。
しかし、IHS/WASの場合、一筐体に複数のバージョンを共存することができますが、Edge Componentsの場合は共存はできません。
古いバージョンをアンインストールのうえ、新しいバージョンをインストールする必要があります。

バージョンアップに当たっては、異なるバージョンでHAを構成することは推奨されませんので、サービスの全面停止時間が必須となります。
以下の手順でバージョンアップを行うことでサービス停止時間を短くすることができます。
しかしながら、予期せぬトラブルを防止するため、サービスの全面停止時間を十分に確保し、両系を同時に停止し、一度にバージョンアップを行うことをお勧めします。