Edge 1 WebSphere Application Server V6.0 - Network Deployment -

WebSphere Application Server V6.0
- Network Deployment -
Edge
1
Agenda
１章. Load Balancer
Load Balancer とは
Edgeクラスター
u MAC転送方式
u Load Balancer 構成要素
u High Availability構成
u
u
２章. 構成とトポロジー
Rule
u Affinity
u 割り振りの制御
u スクリプト
u ログ
u
当資料では以下の略語を使用しています。
( )内が正式名称になります。
製品名
WAS
(WebSphere Application Server)
ND
(WebSphere Application Server Network Deployment)
RAD
(IBM Rational Application Developer for WebSphere Software)
RWD
(IBM Rational Web Developer for WebSphere Software)
製品に含まれるコンポーネント
AST
(Application Server Toolkit)
TPV
(Tivoli Performance Viewer)
DM
(Deployment Manager)
IHS
(IBM HTTP Server)
用語
WLM
(Workload Management)
環境により異なるインストール・ルート等については、以下の表記を使用していま
す。
<WAS_root> ：WASのインストール・ルート
(Windowsデフォルト：C:¥Program Files¥IBM¥WebSphere¥AppServer）
<Profile_root>：プロファイル・ルート（Windowsデフォルト：C:¥Program
Files¥IBM¥WebSphere¥AppServer¥profiles¥<Profile_name>）
<Plugin_root>：プラグインのインストール・ルート（Windowsデフォルト：
C:¥Program Files¥IBM¥WebSphere¥Plugins）
<IHS_root> ：IHSのインストール・ルート（Windowsデフォルト：C:¥Program
Files¥IBM¥IBM HTTP Server）
2
第１章
Load Balancer
Load Balancer とは
Edgeクラスター
MAC転送方式
u Load Balancer 構成要素
u High Availability 構成
u
u
u
3
Load Balancerとは
n
n
n
クライアントの要求を各サーバーに分散
各サーバーの監視
各サーバーへ割り振りの制御
Advisoが
サーバーの監視
Advisor
Executor
Executorが
割り振る
Client
Manager
Load Balancer
Managerが
負荷を計算
Server
Balancer は、クライアント
要求を各種サーバー間で分散させるためのソフト
ウェア・ソリューションです。これは、TCP/IP セッション要求をサーバーに割り振ること
によって、サーバーのパフォーマンスを高めます。このロード・バランシングは、ユー
ザーや他のアプリケーションに透過的に行われます。
nLoad
Balancer は、割り振り先サーバーの監視を行います。サーバーがダウンする
とそれを検知し、ダウンしたサーバーに要求を割り振りません。
nLoad
Balancer は、要件に基づき割り振りを行います。時間や要求コンテンツなどに
より割り振るサーバーを限定する事ができます。
nLoad
4
Edgeクラスター
u
u
u
u
複数のサーバーでクラスター を定義。
クライアントはLoadBalancerに定義されたCluster Addressでアクセス。
クラスターは複数定義可能 。
WASのクラスター とは別ものです。
クライアントはいつも
Cluster Address
にアクセスする
Cluster：port
10.10.10.5
10.10.10.1
Cluster Address
10.10.10.2
10.10.10.10
Load Balancer
10.10.10.3
Client
IHS/WAS
■LoadBalancerでは、割り振り先となる複数のサーバーで、クラスターを構成しま
す。クラスターとはLoadBalancer上に定義されたCluster Addressによってアクセ
スされる1つのグループです。クライアントにはクラスターアドレスしか見えませんの
で、あたかも1つのサーバーであるかのように見えます。LoadBalancerはクラス
ター・アドレス宛てで来たリクエストを受け取り、クラスター内に定義された割振り先
サーバーにリクエストを割振ります。
■負荷分散装置には複数のクラスター・アドレスを設定することができますので、
異なるサイトのトラフィックを一つの負荷分散装置で割振ることも可能です。負荷分
散装置に設定可能なクラスターの数は製品に依存します。WAS V6 NDで提供さ
れるDispatcherの場合はデフォルト最大100個のクラスター・アドレスを設定可能で
すが、あまり多くのクラスターアドレスを設定するとメンテナンス性が低下することが
懸念されますのでご注意ください。
5
Load Balancer構成方法
①サービスのdsserverを起動
dsserver start
②Executorを起動
dscontrol executor start
③Clusterアドレスを設定
dscontrol cluster add Cluster_Address
④使用するポートを設定
dscontrol port add Cluster_Address:port
⑤割り振り先サーバーを設定
dscontrol server add Cluster_Address:port:Server_1
dscontrol server add Cluster_Address:port:Server_2
⑥Managerを起動
dscontrol manager start
⑦Advisorを起動
dscontrol advisor start http 80
Cluster:80
Server2
Server1
Client
Load Balancer
IHS/WAS
n上記はServer1とServer2をポート
80でクラスター構成した時の例です。
n割り振り先サーバーであるServer1とServer2にループバック・
アドレスのAliasも
しくはiptablesでClusterアドレスを設定する必要があります。
6
MAC転送方式
u
u
u
u
u
u
クライアント・リクエスト内のMACアドレスのみを変換。
宛先IPアドレスは変更しない。
ResponseはDispatcherを経由しない。
最もパフォーマンスがよい。
Dispatcherと同じセグメント内のサーバーのみ割り振りができる。
割り振り先サーバーにクラスター・
アドレスを定義。※ノート参照
クラスター・アドレスを
ループバックのエイリアスとして追加！
MAC
IP
ClusterIP
Port
MAC aa:aa
IP
10.10.10.98
MAC
src aa:aa
dst bb:bb
IP
src 10.10.10.98
dst 10.10.10.10
TCP
dst 80
MAC
IP
ClusterIP
Port
bb:bb
10.10.10.5
10.10.10.10(en0)
80
DATA
・・・
・・・
MAC
src bb:bb
dst cc:cc
Request
IP
src 10.10.10.98
dst 10.10.10.10
TCP
dst 80
cc:cc
10.10.10.3
10.10.10.10(lo0)
80
DATA
・・・
・・・
Request
Load Balancer
Client
Response
MAC
src cc:cc
dst aa:aa
IP
src 10.10.10.10
dst 10.10.10.98
TCP
src 80
IHS/WAS
DATA
・・・
・・・
nMAC転送方式に追加で必要なIPアドレスはClusterIPのみです。DispatcherのMAC転送
方式は、クライアントから来たリクエスト内のMACアドレスのみを変換し、IPアドレスの変換は
行ないません。
nこの転送方式の特徴としては、帰りのパケットがDispatcherを経由しないことです。一般的
にWebのトラフィックはリクエストよりもレスポンスの方が重たいことが多いので、この重いトラ
フィックがDispatcherを通らない分パフォーマンスはよくなります。Dispatcherで最もパフォー
マンスのよい転送方式になります。
nMAC転送方式を用いる際の制限としては、MACアドレスしか書換えを行なわないので、
ARPが届く範囲内つまりDispatcherと同じセグメント内に割り振り先サーバーが存在する必
要があります。
nDispatcherはリクエスト
をクライアントから受け取ると、宛先MACアドレスを割振り先サー
バーのMACアドレスに変換し、リクエストを割振り先サーバーに送信します（同一ネットワーク
ですので MACアドレスにより、リクエストは割振り先サーバーに届きます）。この際、送信元の
IPアドレスが変更されていないことをご確認下さい。リクエストを受け取った割振り先サー
バーは、リクエストに含まれる送信元IPアドレスに対してレスポンスを返しますので、送信元IP
からARPテーブルを確認してMACアドレスを判断し、直接クライアントへとレスポンスを返し
ます。
※割振り先サーバーがAIX / Windows の場合は、loopbackアドレスにクラスター・アドレスを
aliasとして設定することが必要です。
※割振り先サーバーがLinuxの場合は、以下のコマンドでiptablesにクラスター・アドレスを設
定する必要です。
iptables –t nat –A PREROUTING –d cluster_address –j REDIRECT
※割振り先サーバーがWindowsの場合は、エキストラ経路を削除する必要があります。
7
Load Balancer 構成要素
u
Load Balancer の内部構成
サーバーの監視を行い
レスポンスの時間を
Managerに伝える
IHS/WAS
dsserver(javaコンポーネント）
監視
Manager
Advisor
IHS/WAS
Client
Executor
カーネル
Executorから接続数を
受け取り、それらの情報を基に
負荷を計算してExecutorに
”重み”として伝える
割り振り
IHS/WAS
Load Balancer
Managerに接続数
を伝え、“重み”
を基に
割り振りを行う
Cluster
ここでは、Load Balancerの構成を説明します。
管理者は、dscontrolコマンド、もしくはGUIを通して、executor, manager,
advisor を操作します。
nexecutor・
・・実際に割り振りを行うカーネルベースのコンポーネントです。
nmanager・
・・advisorを呼び出し、割り振り先サーバーの重みを計算し、executor
に伝えるコンポーネントです。
nadvisor・
・・割り振り先サーバーにリクエストを送り、レスポンスが返ってくるまでの
時間をmanagerに伝え、サーバーの生死の監視を行っているコンポーネントです。
8
Executorの役割
n
サーバーへ割り振りおよび割り振りの制御をします。
u
実際の割り振りを行う
l
u
カーネルの一部として動作し、プロセスとしては見えない。
接続数のカウント
l
Managerを通じて表示可。
u
High Availability構成時、primary/backup間でheartbeat
（heartbeatで接続情報およびAffinity情報の同期をとる。）
u
接続情報テーブルの保持
u
Affinity情報の保持(IP Sticky情報のみ）
9
Managerの役割
n
各サーバーの負荷を計算し、Executorに”重み”として伝える。
u
Executorが使用する各サーバー重み（負荷）を計算
l
u
ｆ
ixedweightコマンドによりサーバーに設定した重みを固定できる。※ノート参照
以下の情報からサーバーの重みを計算するJavaコンポーネント
Ø
Ø
Ø
Ø
u
ACTV
NEWC
PORT
SYS
・・・現在の接続数（
Executorが情報提供）
・・・新規の接続数（
Executorが情報提供）
・・・Advisorからの情報
・・・Metric Server等のモニタリング・ツールによる情報
Advisorの呼び出しとレスポンスタイムの計測
nmanagerは、各項目（
ACTIVE、NEW、PORT、SYSTEM）における各サーバー
に対する重みを、それぞれからのフィードバックに基づいて、manager内部で設
定しております。managerは収集した全ての情報（4項目の値）を基に、各サー
バーの新規の重み(WEIGHT)を算出し、executorに伝達します。
nadvisorを使用しなければ、managerは割振り先サーバーのダウン検知を行えま
せん。ダウン検知は行いたいが、割振り先サーバーに設定した重みをadvisorによ
り更新させたくない場合は、fixedweightオプションを使用します。例えば、以下の
ようになります。
dscontrol server set cluster:port:server fixedweight yes
また、fixedweightをyesに設定した後、dscontrol server set weightコマンドで
重みを所要の値に設定します。
10
負荷の計算方法
n
Manager
２秒間隔で重みを計算し、更新を行います。
※managerが算出する重みの計算式につきましては、内部ロジックとなります為、
一般公開されておりません。
u
図①
#dscontrol manager report （managerが持っている情報を表示するコマンド）
------------------------------------------------------------------|
9.170.19.100
| WEIGHT | ACTV | NEWC | PORT |
SYS |
|
PORT:
80
|NOW NEW|
49% |
50% |
1% |
0% |
------------------------------------------------------------------|
9.170.19.10 | 9 9 |
13 |
1 |
32 |
0 |
|
9.170.19.20 | 0 0 |
0 |
0 |
-1 |
0 |
-------------------------------------------------------------------
＜参考＞
WEIGHT
更新
WEIGHT
更新
２秒
ACTV, NEWC
更新
WEIGHT
更新
２秒
WEIGHT
更新
２秒
ACTV, NEWC
更新
■managerが持っている情報（図①）について説明します。
nWEIGHTのNOW値は現在executorが使用している重みです。
nWEIGHTのNEW値は次のサイクルでexecutorが使用する重みです。
nACTV値、NEWC値に関しては、executorが内部カウンターからカウント
した接
続数をmanagerに渡したものです。managerは、default2秒間隔でWEIGHTを更
新しており（参考図）、そのサイクルを2回（default）繰り返すごとに接続数
(ACTV,NEWC)の情報を更新しています（参考図）。その2サイクルの間に（点線
部）新しく入ってきた接続数が、次の「NEWC」として反映されます。また、総接続
数から次の接続数の更新時までに接続が終了した数を引いたものが、「ACTV」と
して反映されます。
nPORT値は，advisorを使用してサーバの状態を監視した時の、サーバに対する
リクエストのレスポンス時間（ミリ秒単位）を表しております。レスポンスがない場合
は、PORT値は−１となります。
Serverなどのシステムの負荷を監視するツールにより、割振り
先サーバーのCPU使用率やメモリ使用率などのシステム負荷を監視している場合、
その値が反映されます。
nSYS値は、Metric
※proportionオプションにより、ACTV, NEWC, PORT, SYS の４項目の重要度の
割合を変更する事が可能です。
11
Advisorの役割
n
割り振り先サーバーの監視、レスポンスタイム を計測
u
割り振り先サーバーの障害検知
l
l
負荷分散の対象となるサーバーに定期的にリクエスト
レスポンスが返れば、サーバーは正常と判断
レスポンスが返らないと、サーバーダウンと判断
※ダウンと判断する前に、もう一度リクエストを送る事ができます。ノート参照
l
Executor
レスポンスがあれば正常
なければダウンと判断
リクエスト
接続情報
重みの計算結果
７秒間隔で呼び出す
Manager
Advisor
生死情報,レスポンスタイム
Load Balancer
レスポンス
IHS/WAS
Advisorはサーバーをダウンと判断する前に再試行できます。
例えば、ポート80のHTTP advisorの場合に、ダウンと判断する前に３回再試行させる
場合は、以下のコマンドを入力します。
dscontrol advisor retries http 80 3
12
IHSまで監視させるには
n
デフォルトのHTTP Advisorを使えばOK
u
u
デフォルトのリクエスト HEAD / /HTTP 1.0
デフォルトでは、レスポンスはどんな値でもサーバーが生きてると
見なす。
※IHSにアクセス・ログが残りますが、ログから除く事も可能です。ノート参照。
レスポンスがどんな
値でも生きてると
見なす
Advisor リクエスト
HEAD / HTTP/1.0
UserAgent : IBM_Load_Balancer_HTTP_Advisor
Load Balancer
IHS
レスポンス
Advisorを使用している場合、IHSはadvisorのリクエストをアクセス・ログと
して記録してしまいます。
これを取り除くには、IHSのhttpd.confに以下のように編集をします。
nHTTP
BrowserMatch IBM_Load_Balancerh_HTTP_Advisor ND
CustomLog <IHS_ROOT>/log/access_log common env=!ND
問題判別のため、別途ログを記録する事をお奨めします。（以下：advisor_logと
いうログの作成例）
CustomLog <IHS_ROOT>/log/advisor_log common env=ND
13
WASまで監視させるには①
n
拡張 HTTP advisor
u
u
advisorが割振り先サーバーに送るリクエストや、割振り先サーバーからのレ
スポンス指定可能。
AdvisorリクエストにWASやDBまでみるサーブレットを指定する事で、WASや
DBまで監視する事が可能。
※DBまで見に行くサーブレットにリクエストを送り、
正常ならば ”Everything OK”という文字列をレスポンスに入れた場合
dscontrol server set cluster:port:server advisorrequest “¥”GET /testServlet HTTP/1.0¥””
dscontrol server set cluster:port:server advisorresponse “¥”Everything OK¥””
リクエスト
GET /testServlet HTTP/1.0
Load Balancer
IHS
レスポンス
Everything OK
WAS
DB
n例えば、拡張
HTTP advisorを使用して、割振り先サーバーに “ GET /testServlet
HTTP/1.0 ” というリクエストで、レスポンスに “ Everythihg OK “ の文字列を指定して、割振り
先サーバーのダウン検知を行うには、以下のようにします。
dscontrol>> シェル・プロンプトからこのコマンドを出す場合は、ブランクがストリングに含ま
れている場合は、そのストリングの前後を引用符で囲まなければなりません。
server set cluster:port:server advisorrequest “GET /testServlet HTTP/1.0"
server set cluster:port:server advisorresponse “Everything OK"
オペレーティング・システム・プロンプトからdscontrol コマンドを出す場合は、テキストの前
に “¥” を付けて、¥“” を付けたテキストを続けなければなりません。
dscontrol server set cluster:port:server advisorrequest "¥“GET /testServlet
HTTP/1.0¥""
dscontrol server set cluster:port:server advisorresponse "¥“Everything OK
¥""
14
WASまで監視させるには②（SSL通信の場合）
n
SSL通信でWASまで監視できるAdvisor
HTTPS Advisor はこれは、サーバーとの完全 SSL ソケット接続を実行。
HTTPS Advisor は、SSL 接続をオープンして HTTPS 要求を送信し、応答を待機し、
接続をクローズし、負荷として経過時間 を戻す。SSL Advisor より重い。リクエストおよびレ
スポンスを指定可能 。
Advisor
IHS/WAS
＜参考＞SSL通信でIHSまで監視できるAdvisor
SSL Advisor はサーバーとの完全 SSL ソケット接続を確立しない。
SSL Advisor は、接続をオープンして SSL CLIENT_HELLO 要求を送信し、
応答が来たら接続をクローズし、負荷として経過時間 を戻す。HTTPS Advisor より軽い。
Advisor
IHS
15
＜参考＞Advisorの挙動①
u
Advisorの監視に使われる制限時間を変更できます。
l
l
l
interval ・・・Advisorを呼び出す間隔です。(デフォルト７秒）
connecttimeout ・
・
・接続をするまでの時間制限です。（デフォルト２１秒）
recievetimeout ・・・レスポンスを受け取るまでの時間制限です。（デフォルト２１秒）
Advisorの監視
ClusterA
< Server1> < Server2 >
7秒間
interval
接続開始
＜
接続終了
connecttimeout
最大21秒間
レスポンス
interval
リクエスト
最大21秒間
接続確立
接続開始
7秒間
ClusterA
< Server1> < Server2 >
7秒間
interval
recievetimeout
Server1
＞＜
S e r v e r 2 ・・
advisorは、監視先サーバーに対して、接続を確立し、リクエストを投げレスポンスを受け取
り、接続を終了するまでの時間をmanagerに報告します。監視先サーバーに接続できない、
もしくは レスポンスがない場合は、ダウンとみなし、managerに報告します。
■ここでは、interval, connecttimeout, recievetimeout の３つの値について説明します。
はmanagerがadvisorを呼ぶ間隔です。default７秒ですが、advisorを７秒間
隔で呼び出す訳ではなく、advisorが監視を終了してから次の呼び出しまで７秒間あると
いう事に注意してください。実際には、advisorが監視を行っている時間+７秒後に次の
advisor監視が行われます。
例えば、ポート80 の HTTP advisor の場合に、間隔を 3 秒に設定するには、以下の
コマンドを入力します。
dscontrol advisor interval http 80 3
ninterval
nconnecttimeoutは、advisorが監視先サーバーに対して接続を確立するまでの制限時
間です。defaultは21秒ですが、要件に合うよう短くする事も可能です。
例えば、ポート80 で HTTP advisor の connecttimeout を 9 秒に設定するには、次
のコマンドを入力します。
dscontrol advisor connecttimeout http 80 9
nrecievetimeoutは、advisorが監視先サーバーに対してリクエスト
を投げ、レスポンスを
受け取るまでの制限時間です。defaultは21秒です。サーバーの応答時間が増加するよ
うなトラフィックを生じるアプリケーションの場合は、receivetimeout の値を小さく設定し
すぎないように注意してください。そうしないと、ビジーのサーバーが障害発生として
マークされるのが早すぎる事態になる場合があります。
例えば、ポート80 で HTTP advisor の recievetimeout を 9 秒に設定するには、次
のコマンドを入力します。
dscontrol advisor recievetimeout http 80 9
16
＜参考＞Advisorの挙動②
n
複数クラスターに対するAdvisorの動き
ClusterA : 80
Server1＋Server2
ClusterB : 80
Load Balancer
Server3＋Server4
dscontrol advisor start http 80
ClusterA
（
port 単位でadvisorを起動した場合）
ClusterB
< Server1> < Server2 > < Server3> < Server4 >
dscontrol advisor start http ClusterA:80
dscontrol advisor start http ClusterB:80
ClusterA
< Server1> < Server2 >
ClusterB
< Server3 > < Server4 >
7秒間
interval
7秒間
interval
ClusterA
< Server1> < Server2 >
（
Cluster+port単位でadvisorを起動した場合）
ClusterA
< Server1> < Server2 >
7秒間
interval
7秒間
interval
ClusterB
< Server3 > < Server4 >
7秒間
interval
■ここでは、クラスターが複数ある場合のadvisorの挙動について説明します。
nadvisorをport単位で起動した場合は、それぞれのクラスターに順次リクエスト
を
送ります。そのため、複数クラスターがある場合は、全てのクラスターにリクエストを
送り終わった後に、intervalが入り、次のadvisorサイクルが始まります。
nadvisorをCluster+port単位で起動した場合は、各クラスターに同時にリクエスト
を送ります。そのため、一つクラスターに対しリクエストを送り終わったら、intervalが
入り、そのクラスターに対する次のadvisorサイクルが始まります。
※サーバー単位でadvisorを起動する事はできません。
※一つのクラスターに複数のサーバーが登録されている場合は、サーバー数が増
えれば増えるほど障害検知に時間がかかってしまう恐れがあります。
17
High Availabilityとは
n
High Availability構成（
HACMPとは別物）
u
u
u
Dispatcher自身の可用性
Primary-Backupの2台でHA構成
（通常はBackup機はスタンバイ状態です。）
Primaryサーバーの障害時にBackupサーバーが処理を引き継ぐ。
Primary
heartbeat
IHS/WAS
Client
Backup
nLoadBalancerが割振り先サーバーの障害を検知し、可用性を確保していること
はご説明しました。ここではLoadBalancer自身の可用性についご説明いたします。
nまずDispatcherの可用性はPrimaryとBackupの2台でHA構成をとることにより
確
保されます。（なおこのHA構成はDispatcher自身の持っている機能であり、
HACMPとは関係ありません）。PrimaryとBackupのそれぞれのDispatcherは互い
に0.5秒間隔でheartbeatと呼ばれるパケットを送りあっています。このheartbeatが
4回(つまり2秒）相手から届かなかった場合には、相手がダウンしたと判断し
Takeoverが発生します。Takeoverが発生するとクライアントからのリクエストは
Backup機により処理されるようになります。また接続情報やsticky情報は通常の
heartbeatでやりとりされていますので、Takeoverが発生した際にもTakeover直前
までの情報は引継いでいます。
nTakeover発生条件であるheartbeatのタイムアウト
値は変更する事ができます。
（heartbeatの間隔0.5秒は変更できません。）
dscontrol executor hatimeout 3 （３秒に変更する例）
18
heartbeatとは
n
HA構成の時にお互いを監視するためのパケット
u
u
u
お互いに0.5秒間隔でheartbeatを投げ合い、監視を行う。
heartbeatが相手から４回（２秒）届かなかったら相手をダウンと判断。
(デフォルト値）
heartbeatは接続情報およびsticky情報を保持。
heartbeat
接続情報 sticky情報
heartbeat
Primary
n
Backup
Primary機の持っている接続情報およびsticky情報は、heartbeatを通してBackup機と
同期をとります。Primary機がダウンした場合は、Backup機によって、接続およびsticky
が保持されます。
19
＜参考＞High Availability 障害発生ケース
u
Primary機のマシン障害
u
ネットワーク障害
l
l
u
問題なくBackup機へと引き継ぐ。
Primary機、Backup機の両方がActiveになりますが、どちらかは障害により接続できない状態
にあるため、問題ありません。
プロセス障害
l
ManagerやAdvisorなどのJavaで動いているコンポーネントで障害が発生した場合、heartbeat
は途切れないため（Executorがカーネルのため）Takeoverは発生しません。この障害に対応
するためには、Tivoli等の監視ツールを使用する必要があります。
heartbeat
heartbeat
Primary
マシン障害の場合は、
Backup機がtakeover
します。
ネットワーク障害の場合
は、お互いがActiveに
なります。
Backup
n
Primary機のマシン障害の場合は、Backup機がTakeoverします。
n
ネットワーク障害の場合は、heartbeatが断絶するため、Backup機もActiveに
なります。ネットワーク障害から回復した場合、フェールオーバーがautoであ
ればPrimary機がActiveに、manualであればタイミングでどちらかがActiveに
なります。
プロセス障害（advisor, managerの障害）の場合は、heartbeatは止まりませ
ん（カーネルのexecutorで動作しているため）のでTakeoverは起こりません。
Tivoliや運用シェルでプロセスを監視し、障害を検知したら強制的に
Takeoverを発生させる必要があります。以下は強制的にTakeoverを発生さ
せる方法です。
−インターフェースをダウンさせてheartbeatを止めて、メンテナンスのために再
起動をする。
−dsserver（java プロセス）を再起動してexecutorを停止し、再起動をします。
n
20
＜参考＞Takeover発生時の挙動
※Takeoverが発生してBackup機がActiveになった後に、Primary機が回復した時、Primary
機をActiveに自動、もしくは手動で戻す事ができます 。
1. Primary機がダウンし、Backup機がActiveになった場合
・接続情報、sticky情報共に引き継がれます 。
2. Primary機がダウンし、Backup機がActiveになった後、Primary機が回復して
再びActiveに自動で戻った場合
・接続情報は引き継がれます。
・sticky情報は引き継がれません。
※接続情報 の同期をとってから引継ぎを行うには、dscontrol highavailability status
コマンドで、同期化済 になっている事を確認してから手動で引継ぎを行ってください。
3. Primary機がダウンし、Backup機がActiveになった後、Primary機が回復して
再びActiveに手動で戻した場合
・接続情報は引き継がれます。
・sticky情報はPrimary機が回復してから、手動でActiveに戻すまでに更新されたものが
引き継がれます。
21
＜参考＞HA構成の同期確認
§
#dscontrol highavailability status
Primary機
Backup機
high availability 状況:
------------------------役割 ......................プライマリー
リカバリー・ストラテジー ..手動
状態 ......................活動中
2 次状態 ..................同期化済 み
プライマリー・ホスト...........10.10.10.1
ポート...............34756
優先ターゲット.......適用なし
high availability 状況:
------------------------役割 ......................バックアップ
リカバリー・ストラテジー ..手動
状態 ......................待機
2 次状態 ..................同期化済 み
プライマリー・ホスト...........10.10.10.1
ポート...............34756
優先ターゲット.......適用なし
Heartbeat 状況:
--------------カウント.............1
送信元/宛先 ..........10.10.10.1/10.10.10.2
Heartbeat 状況:
--------------カウント.............1
送信元/宛先 ..........10.10.10.2/10.10.10.1
nコマンド
dscontrol highavailability status でマシンのHigh Availability情報を
確認できます。
22
第２章
構成とトポロジー
u
Rule
u
Affinity
割振りの制御
u
u
u
スクリプト
ログ
23
条件による割り振り
n
n
n
Ruleを定義して条件により、割振りを制御することが可能。
Ruleは複数定義可能で、優先度の高いものから適用。
定義できるルールの条件
u
u
u
u
Client IP
時間
・・・など
秒あたりの 接続数
活動中の接続数
通常は2台のサーバーへ割り振り
u
常に“true”
特定条件でSorryへ割り振り
接続数制限
サービス利用不可
サービス時間外
Load Balancer
Load Balancer
Sorry Server
Sorry Server
※Sorry Server はLoad Balancer と同一筐体に作成する事が可能。
nLoadBalancerの割振りをルールを用いて、制御することが可能です。例えば、業務
時間内には業務サーバーに割振るが、業務時間外にはSorry Serverに割り振り、
サービス停止中のメッセージを表示したいといった場合には、時間タイプのルールを
用いることができます。その他クライアントのIPによって割振り先を変更したり、業務
サーバーが過負荷になる前に接続数で制限をかけるといったことも可能です。
nルールは複数定義可能ですが、優先度の高いものから順位処理され、ルールに
マッチングするとそのルールに基づいて割振りが行なわれ、それ以降のルールのマッ
チングは行なわれません。またルールの”かつ”条件での設定はできません。
24
＜参考＞Ruleの使用例
n
Ruleを使用した例
IHS/WAS
Load Balancer
Sorry Server
①type true
Web Serverがダウンした時に、Sorry Serverへ割り振る。
②type ip
Client IP が10.10.10.1∼10.10.10.10までをWeb Serverへ、それ以外はSorry
Serverへ割り振る。
③type time
PM 11:00∼AM 5:59までをSorry Serverへ割り振る。
④type active
接続数が30を超えたらSorry Serverへ割り振る。
※Sorry Server となるIHS側であらゆるパスも処理できるように設定を行います。
設定例：Alias /sorryImpage/ /usr/IHS60/htdocs/ja_JP/sorryImage/
AliasMatch ^/.* /usr/IHS60/htdocs/ja_JP/sorry.html
①dscontrol rule add cluster_address:port:rule1 type true priority 10
dscontrol rule add cluster_address:port:rule2 type true priority 20
dscontrol rule useuser cluster_address:port:rule1 WebServer_address
dscontrol rule useuser cluster_address:port rule2 SorryServer_address
②dscontrol rule add cluster_address:port:rule1 type ip beginrange 10.10.10.0 endrange 10.10.10.10 priority 10
dscontrol rule add cluster_address:port:rule2 type true priority 20
dscontrol rule useuser cluster_address:port:rule1 WebServer_address
dscontrol rule useuser cluster_address:port:rule2 SorryServer_address
③dscontrol rule add cluster_address:port:rule1 type time beginrange 23 endrange 23 priority 10
dscontrol rule add cluster_address:port:rule2 type time beginrange 0 endrange 5 priority 11
dscontrol rule add cluster_address:port:rule3 type true priority 20
dscontrol rule useuser cluster_address:port:rule1 WebServer_address
dscontrol rule useuser cluster_address:port:rule2 WebServer_address
dscontrol rule useuser cluster_address:port:rule3 SorryServer_addree
※endrangeで指定した時間は、その時間の59分までが範囲になります。
例えばendrangeを3とした場合、3:59までが範囲になります。
④dscontrol rule add cluster_address:port:rule1 type active beginrange 0 endrange 30 priority 10
dscontrol rule add cluster_address:port:rule2 type true priority 20
dscontrol rule useuser cluster_address:port:rule1 WebServer_address
dscontrol rule useuser cluster_address:port:rule2 SorryServer_address
25
同一サーバーに割り振りを行うには
Affinityを使用する事で、同一サーバーに割り振る
IP Sticky
n
u
u
u
u
DispatcherがクライアントのIP に基づき、Affinity を維持。
Sticky有効時間内であれば同じサーバーへ割り振る。
前段のProxy Serverも１Clientと数える。
Ruleよりも優先される。
Cross Port
n
u
Port80とPort443をまたいでAffinityを実現。
u
例えばnon-SSL時に買い物カゴへ商品を入れ、SSLで支払いを行う場合に有効。
pIP Address Sticky
pCross Port Affinity
ØPort80 とPort443をまたいでAffinityを行う
Ø同じクライアントからのリクエストは同じサーバーへ割り振る
Load
Balancer
Load
Balancer
80
Client
このIPは、前に
Server1 に振ったか
ら、今度もServer1!
Client
443
nこれ以降、Dispatcherで提供されるAffinityの種類をご説明いたします。
nまず最もシンプルなIP
Stickyです。これはDispatcherがクライアントからのIP Address
毎にどの割振り先サーバーに割振ったかを覚えていて、sticky有効時間内であれば同
一のサーバーに割振り続けるというものです。この転送方式の注意としては、前段に
ProxyServerがいた場合にはDispatcherからはProxyServerが１クライアントと見えます
ので、割振りが偏ってしまう危険性があります。また、携帯電話からのリクエストは、ラウン
ド・ロビンProxyを通って届きますので、IP Stickyを用いてもAffinityを維持することができ
ません。
n次にCross Port Affinityです。Dispatcherは基本的にはSticky情報をクラスター・
アド
レス：ポートの組み合わせの単位で持っています。このためDispatcherでStickyを効か
せていても、80ポートへのリクエストと443ポートへのリクエストでは別々のサーバーに割
振られてしまう可能性があります。例えば、HTTPで商品を選択し精算時のみSSL通信
を行なうようなアプリケーションの場合には、商品選択の間はセッションが維持できるが、
購入ボタンを押すとセッション・オブジェクトのないサーバーに割振られてログイン・ペー
ジに戻されてしまう可能性があります。この問題を解消するのがCross Port Affinityです。
複数のポート間でSticky情報を共有し、ポートを跨いでAffinityを維持します。
26
Load Balancerによるサーバーダウン方法①
サーバーへの割り振りを即座に止める
n server down/up
コマンドを発行した時点で、
接続を強制終了します。
IHS/WAS
接続済み
新規接続
Load
Balancer
n
IHS/WAS
server down Cluster_address:port:WebServer コマンドでサーバーを
managerが強制的にダウンさせる事が可能。このコマンドを発行した後は、
いかなるリクエストもそのサーバーに割り振りません。割り振りを再開させ
たい時は、server up コマンドを発行します。
downコマンドを発行するとサーバーへの活動状態の接続はすべて切断
され、その他の接続またはパケットがこのサーバーに送信されないようになります
nserver upコマンドを発行するとサーバーが起動しているとマークを付けます。こ
れで、Dispatcher は、新しい接続をこのサーバーに送信するようになります。
nserver
27
Load Balancerによるサーバーダウン方法②
サーバーに新規リクエストの割り振りを止める
n manager quiesce/unquiesce
コマンドを発行した時点で、
残っている接続が完了する
まで待ちます。
IHS/WAS
接続済み
新規接続
Load
Balancer
n
IHS/WAS
manager quiesce WebServer_addressコマンドを入力すると、接続途中や
sticky情報のあるクライアントからの 要求はWebServerへ割り振り、新規の
クライアント・リクエストのみを別のサーバーへ割り振ることが可能。割り
振りを再開させたい時は、manager unquiesceコマンドを発行します。
quiesce server_addressコマンドでは、既存の接続が完了するまで、
もしくはsticky時間が切れるまでそのサーバーに対し割り振りを行います。コマンド
を発行した後に届いた新規（sticky情報のない）リクエストは、そのサーバーには割
り振りを行いません。このコマンドにより、クライアント
に透過的にサーバーのメンテ
ナンス（更新、保守、アップグレード）を行うことができます。
nmanager
nstickytimeが満了する前に、新規接続を別のサーバーに送信したい場合は、
now オプションを使用します。
manager quiesce server_address now
28
＜参考＞スクリプト①
u
goActive
l
u
goStandby
l
u
HighAvailability構成で、executorが停止する時、及び最初に開始される前に呼ば
れる。
goIdle
l
u
HighAvailability構成で、Standby状態になった時に呼ばれる。
goInOp
l
u
HighAvailability構成で、Active状態になった時に呼ばれる。
StandAlone構成で、Active状態になった時に呼ばれる。
highavailChange
l
High AvailabilityのステータスがActiveとStand-byで変更があった時に呼ばれます 。
ngoActive・
・・HighAvailability構成で、Active状態になった時に、クラスター・アド
レスをNICにエイリアスとして追加します。MAC転送方式以外であれば、リターン・
アドレスもNICのエイリアスに追加します。
ngoStandby・
・・HighAvailability構成で、Standby状態になった時に、クラス
ター・アドレスをNICからはずします。MAC転送方式以外であれば、リターン・アド
レスもNICからはずします。
ngoInOp・
・・HighAvailability構成で、executorが停止する時、及び最初に開始
される前に、クラスター・アドレスをNICからはずします。MAC転送方式以外であれ
ば、リターン・アドレスもNICからはずします。
ngoIdle・
・・StandAlone構成で、Active状態になった時に、クラスター・アドレスを
NICのエイリアスとして追加します。
nhighavailChange・
・・go＊スクリプト
が呼ばれた時に、記録を取ることができま
す。また、管理者にメールを送ることができます。
※HighAvailability構成では、goActive, goStandby, goInOp が、StandAlone構
成では、goIdle がそれぞれ必須になります。
※上記のスクリプト
のサンプルは/opt/ibm/edge/lb/servers/samplesディレクトリ下
にあります。sampleスクリプト
を使用する場合は、拡張子”sample”を除去し、
/opt/ibm/edge/lb/servers/binディレクトリ下に移動し、適宜、編集をしてください。
29
＜参考＞スクリプト②
これらは特殊な挙動をしますのでご注意ください。※１
u
serverDown
l
u
serverUp
l
u
特定のサーバーが活動した時に呼ばれる。
managerAlert
l
u
特定のサーバーがダウンした時に呼ばれる。
全てのサーバーがダウンした時に呼ばれる。
managerClear
l
全てのサーバーがダウンとマークされた後に、少なくとも一つが
回復した時に呼ばれる。
u
halfOpenAlert
l
u
DoS攻撃と思われるものを受けた時に呼ばれる。
halfOpenAleartDone
l
DoS攻撃が終了した時に呼ばれる。
nserverDown・
・・特定のサーバーがダウンしたことを管理者にメールで知らせ、記
録をとります。
nserverUp・
・・特定のサーバーがダウン状態から回復したことを管理者にメールで
知らせ、記録をとります。
nmanagerAlert・
・・全てのサーバーがダウンしたことを管理者にメールで知らせ、
記録をとります。
nmanagerClear・
・・全てのサーバーがダウンした後、少なくとも一つのサーバー
が回復したことを管理者にメールで知らせ、記録をとります。
nhalfOpenAlert・
・・DoS攻撃を受けたことを管理者にメールで知らせ、記録をとり
ます。
nhalfOpenAlertDone・
・・DoS攻撃が終了したことを管理者にメールで知らせ、記
録をとります。
※上記のスクリプト
のサンプルは/opt/ibm/edge/lb/servers/samplesディレクトリ下
にあります。sampleスクリプト
を使用する場合は、拡張子”sample”を除去し、
/opt/ibm/edge/lb/servers/binディレクトリ下に移動し、適宜、編集をしてください。
※１
全てのサーバーがダウンした時は、serverDownは呼ばれず、managerAlertが呼
ばれます。例えば、サーバーが３台あり、１台と２台目がダウンしたら、serverDown
が呼ばれ、３台目がダウンして全滅した場合は、managerAlertが呼ばれます。ま
た、３台ともダウンした後に、１台が回復した場合は、serverUpではなく、
managerClearが呼ばれると同時に、ダウンしている２台に対してserverDownが
呼ばれます。
30
＜参考＞ログ
Load Balancerのログは循環ログ
u
u
n
サイズがオーバーしたら古いログから上書きします。
ログ・サイズは変更可能です。
ログの種類
u
server.log
u
manager.log
u
使用advisor名_ポート.log
u
subagent.log
u
hamon.log
l
l
l
l
l
u
dsserverの活動の記録、発行したコマンド等の情報
managerの活動記録等
使用するadvisorに関する情報
SNMP subagentに関する情報
high availabilityに関する情報（Primary, Backupの両方）
reach.log
l
reach advisorがとばしたping情報等
n上記のログはコマンドdscontrol loglevel
<0∼5> で書き込む情報量が変更可能
です。
nログレベルを0~5まで変更することが出来ます。
nログレベルが３以上の場合は、最大サイズを設定することを望まれます。
nログの最大サイズを指定した場合は、ログサイズの最大値に達すると、トップから上
書きされていきます。
nログのサイズは、現在の値よりも小さいものには設定できません。
※LoadBalancerのログは問題判別用ですので、常時ログレベルを５にして運用する
事は一般的ではありません。
Balancerを再起動したときに、前回使用していたログファイルに.bak拡張子を
付加して保存し、新しいログファイルを作成します。
nログを保存したい場合は、再起動する前に、.bakを保存する事をお奨めします。
nLoad
31
＜参考＞
n
JDKの入手先
AIX：http://www-106.ibm.com/developerworks/java/jdk/aix/service.html
u Windows: http://www-106.ibm.com/developerworks/java/jdk/index.html
u Linux：
http://www-106.ibm.com/developerworks/java/jdk/linux140
u
※インストールしたJDKに対し、PATHの設定を行ってください。
n
EdgeComponent Info-Center
u
http://www -306.ibm.com/software/webservers/appserv/doc/v60/ec/infocenterjp/index.html
32