DataPower トポロジー・ガイド WebSphere DataPower Topology Guide 日本アイ・ビー・エム株式会社 日本アイ・ビー・エム

WebSphere DataPower Topology Guide
DataPower トポロジー・ガイド
日本アイ・ビー・エム株式会社
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
Disclaimer
WebSphere DataPower Topology Guide
„
当資料で提供する技術情報は、各製品の出荷前コードに基づくものを
含みます。
„
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式な
レビューを受けておりません。
„
当資料は、資料内で説明されている製品の仕様を保証するものではあ
りません。
„
資料の内容には正確を期するよう注意しておりますが、この資料の内
容は2011年6月現在の情報であり、製品の新しいリリースによって動
作、仕様が変わる可能性があるのでご注意下さい。
„
今後国内で提供されるリリース情報は、対応する発表レターなどでご
確認ください。
2
目次
WebSphere DataPower Topology Guide
„
„
„
„
„
はじめに
DataPowerとは
代表的なトポロジー・パターン
DataPowerの構成要素
構成要素詳細
‹
„
„
„
„
Application Optimizationフィーチャーによる機能拡張
設計ポイント
主な構成手順
まとめ
参考資料
3
はじめに
WebSphere DataPower Topology Guide
„
本資料の目的
‹
„
本資料の対象
‹
„
AOの機能が追加されることにより、多様なトポロジーが構成できるように
なった。それぞれのトポロジーの特徴、考慮点をまとめる
DataPowerの設計、構築の担当者
本資料の前提
‹
対象機種・モデル
z
‹
対象Firmwareバージョン
z
‹
9235/ 9004 XI50またはXS40
3.8.2.1
トポロジーの対象プロトコル
z
HTTPプロトコルベースの処理時のトポロジーガイドとする
4
DataPowerとは
WebSphere DataPower Topology Guide
„
ESBに求められる処理を満たすアプライアンス
‹
‹
適用目的に応じた３つのラインアップ
上位モデルは下位モデルの機能を全て含む
XS40 セキュリティ・
ゲートウェイ
XA35 XMLアクセラレーター
XML処理の高速化
‹
‹
‹
XML処理
XML変換
スキーマ検証
XMLセキュリティー機能
„
„
„
„
„
共通機能
‹
‹
‹
SSL/アクセラレーション
ロードバランシング
HA構成(StandbyGroup)
„
„
„
XI50 インテグレーション・
アプライアンス
異機種間連携
WS-Security
„
XML暗号、XML署名
„
XDoS攻撃等XML脅威への防御 „
非XMLメッセージのサポート
非XML/XMLフォーマット変換
WebSphere JMSサポート
アクセス制御
外部認証認可サーバー連携
鍵・証明書管理
メッセージの中間処理
オプション
マルチプロトコル変換
オプション
‹
‹
„
„
‹
‹
‹
WebSphere MQサポート
TIBCO EMSサポート
ODBCサポート
Tivoli Access Managerサポート
HSM
5
トポロジーに関連する主な構成要素
WebSphere DataPower Topology Guide
„
プライマリー・サービス
‹
フロント(クライアント)サイドとバック
エンドの仲介処理が実装されるコ
ンポーネント。以下の要素が含ま
れる
‹ フロント・サイド処理
z
‹
z
‹
処理ポリシー
z
リクエスター
リクエスターに対する接続処理を
行う。 Front Side Handlerコン
ポーネントとして定義する場合が
ある
„
„
DataPower同士間でHA機能、または負
荷分散を行うコンポーネント
Application Optimization
‹
処理ポリシー
後段プロバイダーへのロードバランシン
グを行うコンポーネント
Standby Group
‹
„
エンドポイントの設定に従ってプロバイ
ダーへの呼び出しを行う
LoadBalancer Group
‹
メッセージに対する処理を定義す
るコンポーネント
フロント
サイド
処理
バックエンド処理
Add Onフィーチャー。Load Balancer
GroupとStandby Groupの機能を拡張
バックエンド
処理
プロバイダー
プライマリー・サービス
LoadBalancer
Group
Standby
Group
6
WebSphere DataPower Topology Guide
代表的なトポロジーパターン
7
Active-Active構成①：外部負荷分散装置ありの場合
WebSphere DataPower Topology Guide
„
外部負荷分散装置が使用可能な場合
‹
‹
基本的に前段のDataPowerに対する障害検知及び振り分けを外部負荷分
散装置で行う
バックエンドサーバーに対する障害検知も外部負荷分散装置で行う
z
別途負荷分散装置から定期的にヘルスチェックの処理フローを実装する必要
がある
負荷分散装置
Active
Active
8
Active-Active構成①’：外部負荷分散装置ありの場合
WebSphere DataPower Topology Guide
„
負荷分散装置+Load Balancer Group使用の場合
‹
‹
DataPowerに対する障害検知及び振り分けを外部負荷分散装置で行う
バックエンドサーバーに対する障害検知及び振り分けはDataPowerの
Load Balancer Group機能で行われる
z
製品機能で自動的にバックエンドサーバーのヘルスチェックを行う
負荷分散装置
Active
Active
9
Active-Active構成②：外部負荷分散装置なしの場合
WebSphere DataPower Topology Guide
„
Self-Balancing機能で負荷分散及び高可用性を実現
‹
外部負荷分散装置が使用不可の場合、基本的にこのパターンを選択する
z
‹
2台のDataPowerでStandby Groupを構成、さらにSelf-Balancing機能を有効
にする。 Self-Balancingの機能でリクエストの負荷分散及び高可用性を実現
後段サーバーへの負荷分散要件がある場合、Load Balancer Group機能
で後段に対する負荷分散及び高可用性を実現可能
仮想IP
仮想IP
Active
Active
activeメンバー
activeメンバー
Active
Active
Standbyメンバー
Standbyメンバー
10
WebSphere DataPower Topology Guide
各構成要素の詳細
11
プライマリー・サービス
WebSphere DataPower Topology Guide
„
以下の種類が提供されている
1
2
1.
3
4
5
Web Service Proxy: クライアントからのリクエストを、バックエンドサーバー
に橋渡し
Multi-Protocol Gateway: 転送プロトコルの変換
3. XML Firewall: XML形式の不正メッセージをブロック
4. Web Application Firewall: Layer7のFirewall
5. XSL Accelerator: XSLTによる変換処理を高速に実行
2.
12
フロントサイド・ハンドラー
WebSphere DataPower Topology Guide
„
„
„
クライアントに対する接続ポイントとしての構成オブジェクト
Webサービスプロキシーとマルチプロトコルゲートウェイで
サポート
‹
WebサービスプロキシーはWSDLごとにフロントサイドハンドラーを一つ
‹
マルチプロトコルゲートウェイは複数フロントサイドハンドラーを定義可能
通信プロトコルの別でフロントサイド・ハンドラーを構成
‹
XI50はライセンスに応じてMQ/WAS JMS/TIBCO EMSの非同期プロトコルに対応
z
z
z
HTTP,HTTPS,RawTCP
MQ
WebSphere JMS
：IP/ホスト名、ポートの指定
：キューマネージャー、PUT/GETキューの指定等
：ホスト名/ポート番号、PUT/GETキューの指定等
マルチプロトコル・ゲートウェイ
Webサービスプロキシー
Backend Serivce
HTTP
host1.makuhari.japan.ibm.com:9082
HTTP
host1.makuhari.japan.ibm.com:9080
HTTP
HTTPS
host1.makuhari.japan.ibm.com:9081
HTTPS
Backend Serivce
HTTPS
host1.makuhari.japan.ibm.com:9083
MQ
dpmq://QMDP/URI?RequestQueue・・
HTTP/HTTPS/MQ
13
Load Balancer Group
WebSphere DataPower Topology Guide
„
後続サーバーへの負荷分散及び高可用性機能を提供するオブジェクト
ロードバランシング機能
‹ 後段サーバーへのアクセスのロードバランシングが可能
‹
z
z
z
z
z
z
first-alive：プライマリーサーバーがダウンした場合のみバックアップサーバーへ割り振り
hash：クライアントIPによるアフィニティ
least-connection：コネクションが最も少ないサーバーへの割り振り
round-robin：ラウンドロビン
weighted-least-connections：アクティブなコネクションと重み付けの複合でラウンドロビン
(※)
weighted-round-robin：重み付けラウンドロビン
‹
ヘルスチェック機能
‹ サービスのレベルでの生死確認が可能
‹
z
HTTP GETもしくはSOAPリクエストでの定期チェック
z XPathを用いてレスポンスを走査
z ダウンと検知したサーバーにはリクエストを転送しない
※weighted-least-connectionsを使用するには、Application Optimizationフィーチャー(後述)の導入が必要
14
Standby Group
WebSphere DataPower Topology Guide
„
„
„
„
DataPowerが提供する冗長化機能
仮想IPアドレス(VIP)を持ち、通常はActive機が全ての通信を処理
する
Active機の障害時にはStandby機のDataPowerでVIPを引き継ぎ、
通信を処理する
動作概要
各インターフェースは同じStandby Groupに属すことを示すために、同じGroup
IDを持つ
‹ プライオリティの高いほうが通常時Active機、低いほうが通常時Standby機とな
る
‹ Active機がVIPのOwnerとなる
‹ Helloパケットを3秒毎に交換し、互いの生死確認を行なう
‹
Standby Group
DataPower#1
VIP
Active
DataPower#2
VIP
Standby
15
Standby Groupにおける障害検知の仕組み
WebSphere DataPower Topology Guide
„
„
„
Active機、Standby機がBroadCastドメイン(224.0.0.2)を
介してお互いのステータス確認する
ステータス確認するにはHSRP (Hot Standby Router
Protocol)を使用
デフォルトではステータス確認のインターバルは3秒、障害
検知されてからFailover開始までのIntervalは10秒となっ
ている
‹
インターバルの変更が推奨されない
z
„
http://www01.ibm.com/support/docview.wss?rs=180&uid=swg21420179&wv=1
FailoverによってStandby機がVIPを引き継ぐ
16
Standby Groupにおける障害検知の仕組み
WebSphere DataPower Topology Guide
DataPower#1
Active
VIP1
SrcIP:192.168.1.14
DstIP:224.0.0.2
SrcMAC:00:00:0c:07:ac:32
Active機、Standby機が
BroadCastドメイン
(224.0.0.2)を介してお互いの
ステータス確認する
0
Hello Standby
3
Hello Standby
6
Hello Standby
9
Hello Standby
Hello Active
< DataPower#1 ネットワーク障害 >
Hello Standby
12
Hello Standby
18
Hello Standby
21
Hello Standby
23
Gratuitous ARP for 192.168.1.10
27
ARP for 192.168.1.10
27
Hello Active
28
Hello Active
31
Hello Active
3
Hello Active
6
Hello Active
9
Hello Active
12
t (秒)
Standby
VIP1
Hello Standby
0
障害時Standby機がVIPを引
き継ぐ
DataPower#2
SrcIP:192.168.1.10
DstIP:224.0.0.2
SrcMAC:00.1a.64.88.90.eb
15
SrcIP:192.168.1.10
DstMAC:Broadcast
SrcMAC:00:00:0c:07:ac:32
SrcIP:192.168.1.10
DstIP:224.0.0.2
SrcMAC:00:00:0c:07:ac:32
t (秒)
17
Standby Groupにおける障害検知の仕組み
WebSphere DataPower Topology Guide
„
障害でFailover発生時
‹
„
Active機へのすべてのリクエストが失敗する
復旧後、自動的にFailback行うかどうか指定可能
‹
‹
Failbackが有効になるとDataPower#1が復旧後、再びActive機になる
切り替えの際、Standby機(DataPower#2)へのリクエストが失敗するため
基本的に無効にする設定が推奨される
z
http://www01.ibm.com/support/docview.wss?rs=180&uid=swg21420179&wv=1
DataPower#1
VIP1
Active
Failover
Failback
DataPower#2
VIP1
Standby
18
Application Optimizationフィーチャー概要
WebSphere DataPower Topology Guide
„
3.8.0にAdd Onとして追加、以下の機能を提供する
‹
Self-balancing機能
従来のStandby Group機能を拡張し、二台以上のDataPower間で負荷を分散
させる機能を提供
z V3.8以前ではActive-Standbyの構成のみ、負荷分散機能はない
z
‹
Intelligent Load Distribution機能
z
WASのセル情報をベースに動的にLoad Balancer Groupの作成
z WASクラスターのWeight情報を動的に取得し、それを元に負荷分散の実施
z Cookieベースのセッション・アフィニティー機能
„
適用可能なモデル
‹
9235/ 9004 XI50またはXS40
‹
別途ライセンスを購入する必要がある
19
WebSphere DataPower Topology Guide
Application Optimizationフィーチャー
による負荷分散/ロードバランス機能
の拡張
20
Self-Balancing機能
WebSphere DataPower Topology Guide
„
Standby Groupの冗長化機能を加えて、構成するメンバー間で負荷分散を
可能にする機能。Application Optimization (AO)フィーチャーで提供される
‹
Activeメンバーが仮想IPアドレスへのコネクションを一旦受け付けた後、自分自
身を含め、コネクションの転送先を決める
‹ 他のメンバーが転送されたコネクションを処理して、直接レスポンスをクライアント
に返す
‹ DataPowerの前段の負荷分散装置が不要となり、DataPowerのみで負荷分散
が可能
‹ Active機障害時、グループ内で次にプライオリティの高いメンバーがVIPを引き継
ぎ、リクエストの受付、転送を行う
Standby Group
DataPower#1
VIP
Active
DataPower#2
VIP
Passive
注：プライマリー・サービスとしてXML Firewallを使用する場合、Self-Balancingを有効にするため、Firmwareのバージョンが
3.8.0.13、3.8.1.12及び3.8.2.4が必要
21
Self-Balancingにおける処理転送の仕組み
WebSphere DataPower Topology Guide
Standby Group
クライアント
IP:192.168.1.17
MAC:00.16.d3.cc.47.82
VIP:192.168.1.10
VMAC:00:00:0c:07:ac:32
DataPower#1
①要求送信
宛先MAC: 00:16:d3:cc:47:82
送信元MAC: 00:14:5e:f1:66:34
宛先IP: 192.168.1.17
送信元IP:192.168.1.10
Active
VIP
宛先MAC: 00:00:0c:07:ac:32
送信元MAC: 00.16.d3.cc.47.82
宛先IP: 192.168.1.10
送信元IP:192.168.1.17
宛先MAC: 00:16:d3:cc:47:82
送信元MAC: 00:14:5e:f1:66:34
宛先IP: 192.168.1.17
送信元IP:192.168.1.12
②要求転送
③要求送信
宛先MAC: 00:14:5e:f1:66:34
送信元MAC: 00:00:0c:07:ac:32
サーバー
IP:192.168.1.17
MAC:00.16.d3.cc.47.82
④応答送信
DataPower#2
⑤応答送信
DataPower#1
Real IP:192.168.1.15
Real MAC: 00:00:0c:07:ac:32
VIP
Standby
宛先MAC: 00:14:5e:f1:66:34
送信元MAC: 00.16.d3.cc.47.82
宛先IP: 192.168.1.12
送信元IP:192.168.1.17
DataPower#2
Real IP:192.168.1.12
Real MAC: 00:14:5e:f1:66:34
22
Self-Balancingにおける処理転送の仕組み
WebSphere DataPower Topology Guide
1.
2.
3.
4.
5.
Active機がクライアントからのコネクションを確立する
Active機が同一Standby Groupに属するメンバーの負荷状況を判断し、適
切なメンバーへ処理を転送する。その際MACアドレスを書き換えが行われ
る
転送先のメンバー(Standby機)が後続の処理を行い、後段サーバーへリク
エストを送信する
後段サーバーで処理が完了後、応答を転送先のメンバー(Standby機)へ
送信
転送先のメンバー(Standby機)から結果をクライアントへ送信する
23
Self-Balancingにおける処理転送の仕組み
WebSphere DataPower Topology Guide
‹
DPに対する処理ごとに使用されるIPアドレスとMACアドレスは以下の通り
„
Active機自身で処理を行う場合
‹
クライアント→DP (Active機)
z
z
‹
z
‹
‹
送信元IP：Real IP
送信元Mac：Virtual Mac (Real
Mac)
z
宛先IP：Real IP
宛先Mac：Virtual Mac (Real Mac)
DP (Active機)→クライアント
z
z
送信元IP：Virtual IP
送信元Mac：Virtual Mac (Real
Mac)
クライアント→DP (Active機)
z
z
‹
z
‹
送信元IP：Real IP
送信元Mac：Real Mac
後段サーバー→DP (Standby機)
z
z
‹
宛先IP：Virtual IP
宛先Mac：Virtual Mac
DP (Standby機) →後段サーバー
z
後段サーバー→DP (Active機)
z
‹
Standby機で処理を行う場合
宛先IP：Virtual IP
宛先Mac：Virtual Mac
DP (Active機) → 後段サーバー
z
„
宛先IP：Real IP
宛先Mac：Real Mac
DP (Standby機)→クライアント
z
z
送信元IP：Virtual IP
送信元Mac：Real Mac
注：Active機はReal MacがVirtual Macで上書きされる
24
セッション・アフィニティー
WebSphere DataPower Topology Guide
„
同一クライアントからのリクエストを同一バックエンドサー
バーへ振り分ける機能
‹
„
Application Optimizationフィーチャーが提供する機能で、既存のLoad
Balancer Group機能を拡張する
クッキーベースでLoad Balancer Groupによるリクエストの
振り分け先を制御
‹
‹
‹
DataPowerがリクエストに含まれるクッキーの情報で振り分け先を判断
有効時セッション・アフィニティーがLoad Balancer Groupの振り分けアル
ゴリズムを上書きする
3種類のセッション・アフィニティーモード
z
Passiveモード
z Activeモード
z Active-Conditionalモード
25
セッション・アフィニティーの種類
WebSphere DataPower Topology Guide
„
Passiveモード
‹
‹
バックエンド・サーバーがWASである必要がある
WASのJSESSIONIDを利用してセッション・アフィニティーを実現
Load Balancer Group
DataPower
リクエスト (JSESSIONID=PAKZZ:P_A.1)
リプライ
リクエスト(JSESSIONID=PAKZZ:P_A.1)
WASのJSESSIONを
利用する
リプライ
26
セッション・アフィニティーの種類
WebSphere DataPower Topology Guide
„
Active-conditionalモード
‹
‹
‹
WAS以外のサーバーにも適用可能
レスポンスにSet-cookie要求をモニターし、要求があった場合、
DataPower独自のクッキー(DPJSESSIONID)を挿入
以後のリクエストにDPJSESSIONIDでセッション・アフィニティーを実現
Load Balancer Group
DataPower
リクエスト
リクエスト
リプライ(SetCookie: JSESSIONID= … ;
SetCookie: DPJSESSIONID=PBC5YS:-2342213232;)
リプライ(SetCookie: JSESSIONID=…)
リプライにSetCookieが
あったため、
DPJSEESIONIDを挿入
27
セッション・アフィニティーの種類
WebSphere DataPower Topology Guide
„
Activeモード
‹
‹
‹
WAS以外のサーバーにも適用可能
リクエストにDPJSESSIONIDの有無をモニターし、ある場合、対応するバッ
クエンド・サーバーへ転送
ない場合、レスポンスにDPJSESSIONIDを挿入し、以後のリクエストに
DPJSESSIONIDでセッション・アフィニティーを実現
Load Balancer Group
DataPower
リクエスト
リクエスト
リプライ(SetCookie: DPJSESSIONID=PBC5YS:-2342213232;)
リプライ
リプライにSetCookieがないた
め、DPJSEESIONIDを挿入
28
WebSphere DataPower Topology Guide
設計時のポイント
29
障害検知の範囲(Standby Group)
WebSphere DataPower Topology Guide
„
Standby Groupの障害検知の範囲がインターフェース単位
‹
1つのStandby Groupにテイクオーバーが発生しても、連動して他の
Standby Groupのテイクオーバーを発生させることはできない
‹
例：
z
Front-endとBack-endを分離、DataPower#1のeth0とDataPower#2のeth0が
Standbyグループ
z Backendのeth1が障害になりBackendサーバーに一切の疎通ができなくなって
も、eth0は無影響のため依然としてクライアントからのリクエストを受けてしまう
z DataPower#2のBack-endのeth1が障害になっても、DataPower#1がそれを検
知できず、DataPower#2へDispatchする可能性がある
DataPower#1
eth0
eth1
Active
DataPower#2
eth0
eth1
Standby
30
障害検知の範囲(Standby Group)
WebSphere DataPower Topology Guide
„
前段、後段のポートを連動して障害検知したい場合、前
段・後段を同一物理ポートを設定することで実現可能
‹
‹
‹
VLANを使用して前段・後段のネットワークを別々にする
Front-endとBackend(eth0)が1インターフェースとなるので、
DataPower#1 のeth0障害になった場合はDataPower#1のBOX障害と同
等になり、DataPowr#2でVIPを引き継ぎ、その後の通信を処理する
行きと帰りのトラフィックがすべてeth0を通るため、帯域の考慮が必要
DataPower#1
eth0
Active
DataPower#2
eth0
Standby
31
障害検知(Load Balancer Group)
WebSphere DataPower Topology Guide
„
Load Balancer Groupが後段サーバーへの負荷分散機能
の他、ヘルスチェック機能も持っている
‹
指定したインターバルで後段サーバーへHTTPリクエストを送信
z
‹
‹
ユーザー指定したSOAPリクエストの送信も可能
後段サーバーからのレスポンスへのタイムアウト値で後段サーバーの筐体
障害やハング状況を検知可能
さらに後段サーバーからのレスポンスの中身を解析し、アプリケーションレ
ベルで障害検知も可能
開閉局管理用など
z レスポンスメッセージのフォーマットはXMLである必要がある
z
‹
障害と見なす後段サーバーが振り分けのリストから除外される
z
後続のヘルスチェックをパスすれば再び振り分けリストに加える
注：後段サーバーがLDAP及びIMSサーバーの場合、TCPのPingでヘルスチェックが行われる
32
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
基本的に、Active機のFailover中の新規リクエストが接続
エラーとなる
‹
„
„
クライアントアプリケーションの実装によって、新規接続の生成（SYN）をリト
ライする場合は、リトライ中にFailoverが完了すれば正常応答となる
DataPower処理中(リクエストあるいはレスポンス)に障害
でFailoverが発生すると、処理が失敗する
バックエンド処理中(リクエストあるいはレスポンス)に障害
でFailoverが発生すると、要求処理を実施した箇所によっ
て挙動が異なる
‹
‹
正常稼動中のDataPowerで処理されたリクエストは、正常処理される
（Failoverの影響は受けない）
要求処理を実施したDataPowerがダウンしても、応答処理がFailover先で
処理されることはない
33
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
要求処理をActive機で実施した場合(Failover)
‹
応答処理ではバックエンドサーバーから元のActive機に接続を試みる
‹
停止状態のため応答を返せず、クライアント側のタイムアウトでエラー
Standby Group
クライアント
Standby Group
DataPower#1
①要求送信
VIP
Active
③Failover発生
DataPower#1
VIP
Active
Webサービス要求タイ
ムアウトでエラー
④応答送信(リトライ)
②要求送信
Active機で実施した要求処理が失敗する
DataPower#2
VIP
Standby
バックエンド
サーバー
バックエンド
サーバー
DataPower#2
VIP
Active
34
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
要求処理をActive機で実施した場合(Failover)
1.
2.
3.
4.
Active機がクライアントからのリクエストを受信後、自分自身へ処理を振り
分ける
Active機から後段のサーバーへリクエストを送信する
後段サーバーでの処理中にActive機のDataPowerが障害発生し、
Failoverが行われる
後段サーバーでの処理完了後、リクエストの送信元であるActive機へ結果
を送信しようとするが、Active機がダウンしているため結果送信できず。ク
ライアント側でタイムアウトエラーが発生し、処理が失敗する
35
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
要求処理をStandby機で実施した場合(Failover)
‹
バックエンドサーバーからActive機（元Standby機）に応答を返す
‹
クライアントに正常に応答を返す
④Failover発生
Standby Group
DataPower#1
①要求送信
VIP
Active
Standby Group
DataPower#1
VIP
Active
⑤応答送信
③要求送信
②要求転送
DataPower#2
VIP
Standby
DataPower#2
VIP
Standby
36
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
要求処理をStandby機で実施した場合(Failover)
1.
2.
3.
4.
5.
Active機がクライアントからの接続を確立する
Active機がStandby機へ処理を振り分ける
Standby機から後段のサーバーへリクエストを送信する
後段サーバーでの処理中にActive機のDataPowerが障害発生し、
Failoverが行われる。Standby機がVIPを持つようになる
後段サーバーでの処理完了後、リクエストの送信元であるStandby機へ正
常に送信できる。Standby機がVIPを持っているので、クライアントへも正常
に結果を送信できる。一連の処理が正常に完了できる
37
仕掛中の処理の障害設計
WebSphere DataPower Topology Guide
„
バックエンドサーバー処理中にFailoverが発生すると、処
理が失敗する可能性がある
仕掛中の処理が失敗するという前提でシステム前提の障害設計が必要
38
振り分けのオーバーヘッド
Active機でコネクションのみ確立して、処理を転送するため、
処理のオーバーヘッドが小さい
‹
‹
リクエストデータを受け付けるわけではない
基本的にStandby機に対して3%～5%のオーバーヘッドが発生
各DataPowerで処理したリクエスト量/sとCPU使用率の関係
cpu(%)
WebSphere DataPower Topology Guide
„
100
90
80
70
60
50
40
30
20
10
0
AO-Active(AOあり)
AO-Standby(AOあり)
参考(AO無し）
近似線 AO-Active
近似線 AO-Standby
0
500
1000 1500 2000
負荷(req/s)
2500
3000
39
リソースの引継ぎ
WebSphere DataPower Topology Guide
„
Standby Groupで属するDataPower間で基本的にリソー
スの引継ぎという機能を持っていない
‹
‹
„
ネットワークコネクションの引継ぎはない
処理フローのデータの引継ぎはない
障害時処理のリカバリが必要なケース、アプリケーションレ
ベルでカバーする必要がある
‹
例：アプリケーションでリトライする仕組みを提供するなど
40
WebSphere DataPower Topology Guide
トポロジー構成
・Load Balancer Groupの設定手順
・Session Affinityの設定手順
・Standby Groupの設定手順
・Self-Balancingの設定手順
41
Load Balancer Group
WebSphere DataPower Topology Guide
„
DataPowerがバックエンド・サーバーの構成情報を定期的
に取得でき、動的に負荷分散を実施可能
‹
‹
サーバーの増減、Weightの変更
AOフィーチャーが提供しているODCInfoというWebアプリケーションで定期
的にBackendサーバーをPollingする
z
ODC:On Demand Configuration
ODCInfoによりバックエンド・
サーバー情報を定期的に取得
ODCInfo
DataPower
バックエンド・サーバーが
WAS Network Deploymentである必要がある
DataPowerは
バックエンド・サーバー
への通信を分散
DataPowerのLoad Balancer Group
WASのクラスター
42
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
„
手順の流れ
1.
2.
3.
バックエンドのWASに対してクラスターを構成する
DataPower上でLoad Balancer Groupを構成する
DataPower上の処理フローに対して2で定義したLoad Balancer Groupを
使用するように設定する
43
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
„
Control Panelから｢Network-Other-Load Balancer
Group｣と選択
‹
｢Add｣ボタンをクリックし、新規作成する
44
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
„
｢Main｣タブで以下ように設定し、｢Apply｣する
1.
2.
3.
4.
Retrieve Workload Management Information：｢on｣に設定、動的Load
Balancer Groupの使用を有効にする
Workload Management Retrieval：｢WebSphere Cell｣と設定
WebSphere Cell:｢+｣ボタン
をクリックし、WASセルの情報を定義する
Workload Management Group Name：WASのクラスター名を設定
45
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
‹
以下のクラスターに属するWASセルのデプロイメント・マネージャーの情報
を設定し、｢Apply｣ボタンをクリックし、元のLoad Balancer Groupの設定画
面に戻る
z
Deployment Manager Host
z Deployment Manager Port number
46
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
„
„
以上の設定でLoad Balancer Groupの設定が完了。
DataPowerがWASのクラスターメンバーの情報を自動的
に取得し、振り分けを行う
Load Balancer Groupのステータス確認
‹
Control Panelから｢Status-IP-Network-Load Balancer Status｣で確認
47
動的Load Balancer Groupの設定手順
WebSphere DataPower Topology Guide
„
構成したLoad Balancer Groupを処理フローの中で指定
‹
例えばXML Firewallプライマリー・サービスを利用してフローを作成した場
合、作成したXML FirewallのXML Managerの中で作成Load Balancer
Groupを指定する
48
補足：
WebSphere DataPower Topology Guide
„
動的Load Balancer Groupを構成する際、｢Members｣タ
ブで明示的に振り分けメンバーを定義しない
‹
‹
定義すると正しく動作しないことがある
動的Load Balancer Groupを無効にする場合のみ、｢Members｣タブで明
示的に定義する必要がある
49
Session Affinityの構成
WebSphere DataPower Topology Guide
„
Load Balancer Group構成画
面の｢Session Affinity｣タブで
設定する
‹
[Enable Session Affinity]
z
‹
[Insertion Cookie Name]
z
‹
クッキーの挿入パス
[Insertion Domain]
z
‹
DPJSESSIONID(値の変更は不
可)
[Insertion Path]
z
‹
セッション・アフィニティーの使用
有無を指定
クッキーの挿入ドメイン
[Override WebSphere Cell
Session
Session Affinity]
z
z
offの場合Passiveモード
onの場合、Active-conditional
モードか、Activeモードを選択
50
Standby Group/Self-Balancingの設定手順
WebSphere DataPower Topology Guide
1.
Control Panelから｢Network-Interface-Ethernet Interface｣を選択
2.
Ethernetインターフェース一覧から、Standby Groupを構成したインター
フェースを選択し、｢Standby Control｣タブをクリックする
51
Standby Group/Self-Balancingの設定手順
WebSphere DataPower Topology Guide
3.
以下の項目を設定する(それ以外デフォルトのままにする)
z
Group Number：Standby Groupを識別するためのIDVirtual IP Address：
Standby Groupでリクエストを受け付ける仮想IPアドレス
z Enable/Disable Preempt Mode：復旧時Failbackするかどうかを指定。｢on｣に
設定するとFailbackが行われる
z Priority：プライオリティを指定する
z Enable/Disable Self-Balancing：Self-Balancingを使用するかどうかを指定。
｢off｣の場合Failover機能のみ有効。 ｢on｣の場合Failover及びSelfBalancing(負荷分散)機能が有効になる。
52
Standby Group/Self-Balancingの設定手順
WebSphere DataPower Topology Guide
4.
繰り返し前述の手順をStandby Groupに属する他のDataPowerのイン
ターフェースに対しても実施する
53
Standby Group/Self-Balancingの設定手順
WebSphere DataPower Topology Guide
„
注意事項
‹
‹
Standby Controlに属する各物理ネットワーク・インターフェースは同一ネッ
トワークのサブネットワークに存在する必要がある
管理インターフェースに対してStandby Controlを設定しない
z
‹
WebGUIが正常に動作しない可能性がある
プライオリティ値に異なる値を設定する必要がある
同一値を設定すると、ActiveかStandbyの状態を決めることができず、正常に
動作しない可能性がある
z プライオリティがActive機かStandby機かを決めるための設定、振り分けの重
み付けためのではない
z 重み付けは基本的にDataPowerのCPU能力で自動的に計算される。同一モデ
ルのDataPower間の場合、ほぼランドロビンで処理が振り分けされる
z
54
Standby Group/Self-Balancingの設定手順
WebSphere DataPower Topology Guide
„
Standby Groupのステータスの確認
‹
Control Panelから｢Status-IP-Network-Standby｣から確認する
55
まとめ
WebSphere DataPower Topology Guide
高可用性
負荷分散
構成の容易性
Active-Active
(外部負荷分散装置)
◎
○
△
„別途負荷分散装置
の構成が必要
„別途後段サーバー
への障害検知の仕組
みの実装が必要
Active-Active
(外部負荷分散装置
+Load Balancer
Group)
◎
○
△
別途負荷分散装置の
構成が必要
○
前段・後段異なる物
理ポートの場合、障
害検知できない場
合がある
○
○
Active-Active
(Self-balancing)
56
参考資料
WebSphere DataPower Topology Guide
„
Information center
‹
„
RedBook:DataPower SOA Appliance Administration,
Deployment, and Best Practices
‹
„
http://publib.boulder.ibm.com/infocenter/wsdatap/v3r8m2/index.jsp?to
pic=/xi50/welcome.htm
http://www.redbooks.ibm.com/abstracts/sg247901.html?Open
DataPower構成ガイド
‹
http://www.ibm.com/developerworks/jp/websphere/library/esb/dtpw_co
nfig_guide/
57