20170217 ロードバランサ再入門

ロードバランサ再入門
2017年2月17日
高嶋隆一
第8回電力系NCC情報交換会
Version 02/19

View Slide

おっさんエンジニアがロードバランサについて改めて設
計・構築するに当たり、
✓ ロードバランサの基本
✓ 最近の動向 (と言っても最新ではない)
について整理した情報を共有します。
新人教育にでも使って頂けるとうれしいです！
1
本資料の目的

View Slide

➢ ロードバランサの役割
➢ SLBとGSLB
➢ 詳解SLB
✓ ロードバランサの機能
✓ L4とL7
✓ 振分けアルゴリズム
✓ 振分けトポロジ
✓ その他のロードバランサの機能
2
目次

View Slide

3
ロードバランサの役割

View Slide

4
用語
クライアント
Virtual IP Address (VIP)
ロードバランサ (LB)
通信の接続元。
Webコンテンツであればブラウザ。
クライアントから接続されるIPアドレス。
今回解説対象。
冗長化や負荷分散を行う。
ADC (Application Delivery Controller)ともいう。
リアルサーバ
実際に通信を処理するサーバ。
VMでもリアルサーバなので最近ややこしい。

View Slide

5
冗長化
1台のリアルサーバが故障しても、他の正常なリアルサーバによって
サービス継続を可能とする冗長化機能。
(ロードバランサ自体も1:1、N:1で冗長化が可能)
LB無し LB有り+複数のリアルサーバ

View Slide

6
負荷分散
1台のリアルサーバでは処理しきれない負荷を複数サーバに振分け、
スケールアウトさせる事により性能を上げる負荷分散機能。
LB無し LB有り+複数のリアルサーバ
… …
1台分の性能 N台分の性能
…

View Slide

7
SLBとGSLB

View Slide

8
サーバロードバランシング(SLB)
IPアドレスもしくはMACアドレスの書き換えにより、
TCP/UDPを始めとした同一IPアドレス(VIP)宛の通信を複数の
リアルサーバに振分ける技術。
通常LBといった場合はこちらを指すことがほとんど。
192.168.0.1 192.168.0.2 192.168.0.3
203.0.113.1
…
アドレス書き換え＆セッション振分け
クライアントはVIP:203.0.113.1
に通信を要求しているが実際には複数の
サーバに処理が振分けられている。

View Slide

9
グローバルサーバロードバランシング(GSLB)
LBが権威DNSサーバとなる。
1つのホスト名に対するAもしくはAAAAレコードを複数したアドレスのうち
いずれかを1つ返答し、異なるIPアドレスに負荷分散する技術。
権威DNSサーバとしての動作であり、TCP/UDP他の通信を直接
振分ける訳ではないことに注意。
GSLB
A/AAAA振分け
www.example.com=
192.0.2.1
198.51.100.1
203.0.113.1
192.0.2.1 198.51.100.1 203.0.113.1
今回は203.0.113.1が
DNS応答で得られたので
そこに接続
クライアント
リアルサーバ

View Slide

10
GSLBの動き
キャッシュDNS
www.example.com
の権威DNSサーバ
=GSLB
www.example.com
のIPアドレスは？
2
www.example.com
4
www.example.com
の権威DNSを教える
3
複数あるAのうち
203.0.113.1を
Aとして返答
5
example.com
クライアント
192.0.2.1 198.51.100.1 203.0.113.1
www.example.com
のリアルサーバ
www.example.com
1
203.0.113.1
6
203.0.113.1に接続
7

View Slide

11
よくあるwebサービスのアーキテクチャ
www.example.com
=GSLB
www.example.com
のSLB
www.example.com
の実サーバ
セッション振分け
example.com
所謂普通の権威DNSサーバ。
GSLBを使うため、このケースでは
wwwのNSをGSLBに移譲
wwwの負荷分散、冗長を行う為、
A/AAAAに複数のレコードを登録
障害時に切り外す為、A/AAAA の
TTLが短いのは許してorz
NS移譲
A/AAAA振分け
GSLBとSLBを組み合わせた階層化ロードバランシング

View Slide

12
詳解SLB

View Slide

13
ロードバランサの基本機能
基本機能1.セッション振分け
基本機能2.アドレス変換
基本機能3.ヘルスチェックと切り離し
基本機能4.パーシステンス

View Slide

14
基本機能1.セッション振分け
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
振分け
リアルサーバ
SLB
クライアントはVIPに対して通信を行うが、SLBはそのセッションの
を特定の手順により複数のリアルサーバのうちの1台に振分けを行う。

View Slide

15
基本機能2.アドレス変換
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
アドレス書き換え
リアルサーバ
SLB
クライアントはVIPに対して通信を行うが、SLBはそのセッションの
宛先アドレスを書換えることによりリアルサーバへの振分けを行う。
宛先IPアドレス、MACアドレスのどちらかを書換える。
Src:192.0.2.1
Dst:203.0.113.1
192.0.2.1
パケットヘッダ(IPアドレス書換えの場合)
Src:192.0.2.1
Dst:192.168.0.3
Changed!

View Slide

16
基本機能3.ヘルスチェックと切り離し
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
リアルサーバ
SLB
LBはリアルサーバに対して、正常性の確認(ヘルスチェック)を
定期的に行い、異常が見つかったリアルサーバにはセッション
振分けを行いわないようにする
192.0.2.1
ヘルスチェック
ヘルスチェックが失敗した
192.168.0.3への振分けを停止

View Slide

17
代表的なヘルスチェックの種類
PINGによってリアルサーバの死活を監視する
ICMP
TCPのポートの状態を監視する
L4
HTTP GET等、プロトコルレベルの死活監視を行
う
プロトコル監視
実際にアプリケーションレベルでの入力を行い、
その返答が正しいかの確認を行う
アプリケーション
監視

View Slide

18
基本機能4.パーシステンス
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
リアルサーバ
SLB
LBは振分けアルゴリズムに従い、セッション毎に各リアルサーバに振分け
を行う。
動的コンテンツの処理等で、複数のセッションを張り、クライアントからの
アプリケーショントランザクションが終了する迄は特定のリアルサーバに振
分けが必要な場合がある。これを実現する機能をパーシステンスという。
192.0.2.2
Source IPアドレスベースでパーシ
ステンスを実現する例
セッションの順序によらず、同じIP
アドレスからの通信は同じリアル
サーバに割り振る
192.0.2.1 192.0.2.3
1 4 5 6 2 3

View Slide

19
代表的なパーシステンスの種類
Source IPアドレスもしくはSource IPアドレス+
ポートを識別に用いる手法
L3/L4
CookieをLBもしくはリアルサーバで挿入し、そ
れを識別に用いる手法
Cookie
URIを動的に生成し、識別に用いる手法
URI
TLS session ID, Jsession-ID等のプロトコルのID
を識別に用いる手法、L3-L7のパラメータから
ハッシュを生成する手法等がある
その他

View Slide

20
L4とL7
VIPに来た通信をどう区別して適切な
リアルサーバ(群)に振分けるか
✓ L4LB
✓ L7LB
✓ ルールベース

View Slide

21
L4LB
該当VIP用リアルサーバ群
VIP: 203.0.113.0 TCP80
セッションを振分けるリアルサーバ群の選定を
IPアドレス+TCP/UDPポート
のみで識別する選択方法。基本的にはハードウェア処理の為、
パフォーマンスに優れる

View Slide

22
L7LB
example.com
VIP: 203.0.113.0 TCP80
セッションを振分けるリアルサーバ群の選定を
L4情報にに加え、HTTPヘッダ等のL7情報を解釈して識別する。
その為、一旦TCP他のプロトコルをLBが終端する必要がある。
CPU処理が入る為、L4LBより負荷が高い。
example.jp
同一IPアドレスをVIPとするexample.jp
とexample.comをHTTP Hostヘッダを
見て選択する例(*)
(*)Hostヘッダ以外にもpath情報の他、
LBが解釈できるL7情報であれば
個別の振分けが可能
GET /hoge/fuga HTTP/1.1
Host: example.jp

View Slide

23
ルールベース
L3,L4,L7ヘッダ、場合によってはペイロードも含むパケットの
情報等を用いて条件分岐を行い、振分け先を選択する。
単純に振分け先を選択するだけではなく、他のアクションも可能。
多くは独自のプログラミング言語の態をとり、
ベンダによって実装が異なる。(F5 iRules, A10 aFleX等)

View Slide

24
振分けアルゴリズム
同一グループに属するリアルサーバ群
に対して、振分け先をどの様に決定す
るか
✓ Round Robin
✓ Least Connection
✓ その他の振分けアルゴリズム
✓ Priority

View Slide

25
Round Robin
複数のリアルサーバから次のセッションをどこに振分けるかを
決める方式のひとつとしてRound Robin (RR)がある。
RRでは一定の順番でセッションを割り振っていく。
リアルサーバ群
1
1
２
２
３
３
４
４
５
５
A,B,C,A,B,C…
の順にセッションを振分けるケース
A B C

View Slide

26
Least Connection
複数のリアルサーバから次のセッションをどこに振分けるかを
決める方式のひとつとしてLeast Connectionがある。
Least Connectionでは同時接続数が最も少ないリアルサーバに振
分けを行う。
リアルサーバ群
最も同時接続数が少ないAに振分け
A B C
同時接続数 50 55 55

View Slide

27
その他の振分けアルゴリズム
サーバ毎に重み付けを行い、振分けるセッ
ション数をリアルサーバによって変える
Round Robin
左の例ではA,A,B,C,A,A,B,C…となる
Weighted RR
Weight 2 1 1
:
:
A B C
ヘルスチェックによる遅延時間等をパラ
メータとして最も負荷が低いと思われる
サーバに振分ける
左の例ではRTTが短いBが選択される
ヘルスチェックとの組合せ
RTT 5ms 3ms 5ms
A B C

View Slide

28
振分け【Priority】
厳密にはアルゴリズムではないが、複数のリアルサーバグループ
を使った振分けの仕組みとしてPriorityが存在する。
ヘルスチェックや同時接続数等の事前設定条件を満たす限り、
強制的にPriorityが高いリアルサーバグループに割り振られる。
Active/Standby構成やSorryページ等に使われる。
Priority 10
通常コンテンツを持つリアルサーバグ
ループが異常時にSorryページを持つグ
ループへフェイルオーバする構成例。
Priorityを逆にすれば緊急メンテナンス
時等にも使える
Priority 5
通常
コンテンツ
Sorry
ページ

View Slide

29
振分けトポロジ
代表的なロードバランシングのトポロ
ジとその特徴
✓ インライン
✓ L2DSR
✓ L3DSR

View Slide

30
インライン
VIP: 203.0.113.0
宛先IPアドレスの書換えによりリアルサーバへの振分けを行う。
往復トラフィック双方がLBを経由する。
192.168.0.1 192.168.0.2 192.168.0.3
192.168.0.254
レスポンス
リクエスト
198.51.100.1 Src:198.51.100.1
Dst:203.0.13.0
1
1
Src:198.51.100.1
Dst:192.168.0.3
NAT
Changed
2
2
Dst:198.51.100.1
Src:192.168.0.3
3
3
Dst:198.51.100.1
Src:203.0.113.0
NAT
Changed
4
4

View Slide

31
インライン
長所
往復のパケットが全てLBを経由する為、
◯ TCPセッションの状態監視、異常セッションの切断等、きめ細かな管
理がLB上で可能
特徴
✓ IPアドレスのNATを行っている為、往復の経路が一致する
短所
往復のパケットが全てLBを経由する為、
✖️必要となる性能が高くなる。また、リクエスト、レスポンスでは通常
後者の帯域が大きい為、より広帯域なインタフェースが必要

View Slide

32
L2DSR (Direct Server Return)
192.0.2.10
MAC:B
192.0.2.11
MAC:C
192.0.2.254
MAC:Z
198.51.100.1
Loopback
192.0.2.1
VIP:192.0.2.1
MAC:A
Loopback
192.0.2.1
宛先MACアドレスの書換えによりリアルサーバへの振分けを行う。
リアルサーバはVIPをLoopbackアドレスとして設定し、それを
Sourceアドレスとしてレスポンスを行う。
レスポンスはLBを経由しない非対称な通信となる。
収容ルータ
LB
1 3
2
1 Src:198.51.100.1
Dst:192.0.2.1
DstMAC:A
レスポンス
リクエスト
2 Src:198.51.100.1
Dst:192.0.2.1
DstMAC:B
Dst MAC
Translation
Changed
3 Dst:198.51.100.1
Src:192.0.2.1
DstMAC:Z
Loopbackに設定し
た VIP を Source と
してレスポンス

View Slide

33
L2DSR
長所
レスポンスのトラフィックがLBを経由しない為、
◯ LB自体の負荷が低く、結果として多くのリクエスト処理が可能となる
◯ リクエストのみの処理の為、広帯域のインタフェースを必要としない
上記の観点から、1VIPのトランザクション数も多く、レスポンスのデー
タも大きなコンテンツプロバイダ向き
特徴
✓ MACアドレスの変換でセッション振分けを行っており、レスポンスの
トラフィックはLBを経由しない
短所
× セッションのステータスを管理できず、細かな制御は不可
× TCPを終端しない為、L7LB不可
× サーバでDSRに特化した特殊設定が必要
× LB、リアルサーバ共に同一のL2セグメントに存在する必要がある

View Slide

34
インラインとL2DSRの比較
インライン L2DSR
リクエスト処理性能 △(*1) ◯
インタフェース
×
レスポンスに合わせた帯域
◯
リクエスト分だけの帯域
L7/TLS ◯
×
TCPを終端しない為、
L7/TLSの処理は不可
セッション制御 ◯
×
TCPを終端しない為、細か
な制御は不可
リアルサーバ設定
◯
特殊な設定は不要
×
DSR用の設定が必要(*2)
トポロジ
◯
特に制限なし
×
L2同一セグメントに制限
(*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる
(*2)LoopbackにVIPを設定する、LoopbackのARPは無視するといった追加設定が必要

View Slide

35
L3DSR
L2DSRは大規模な環境向けの技術でありながら、MACアドレス変換
を用いている為、同一のL2セグメント上にLBとリアルサーバを置く
必要がある。
その為、下記の様な制約を持っている。
✓ 大規模なL2ネットワークがデータセンタ上に必要
✓ 事前に最大のリアルサーバの数を考慮したIPアドレス設計が必要
IPアドレス変換を用いたDSRを行ってL2の制約を外し、IPルーティ
ングさえされていればDSRを利用可能とする技術がL3DSRである。

View Slide

36
L3DSR
192.0.2.0/24
… …
192.0.2.0/24
…
192.168.0.0/24
…
10.0.0.0/24
L2DSR L3DSR
リアルサーバを増やす
には大規模L2ネット
ワークを構築する必要
がある
ルータで分割されたL3ネットワークを自由に
構成でき、セグメント追加も容易。

View Slide

37
L３DSRの方式
L2DSRでは通信を求められているVIPはIPヘッダの中にあったが、
L3DSRではIPアドレス変換を用いている為、どのVIP当ての通信か
をLBからリアルサーバへ通知する必要がある。
方式としては下記の2つがある。
LBとリアルサーバ間でトンネルを張り、利用す
るトンネルによってVIPを通知する方式
トンネル方式
LBとリアルサーバでVIPとDSCP bitの対応表を
持ち、DSCP bitによりVIPを通知する方式
DSCP方式

View Slide

38
L3DSR【DSCP方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
予め、DSCPとVIPの対応表をLBとリアルサーバで持っておき、
どのVIP向けの通信かを識別する
DSCP VIP
192.0.2.1
192.0.2.2
0x1
0x2
リクエストがあったVIPに応じ
た DSCP bit を立ててリアル
サーバに転送
DSCP bit に応じたVIPでクライア
ントにレスポンス

View Slide

39
L3DSR【DSCP方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
DSCP VIP
192.0.2.1
192.0.2.2
0x1
0x2
Src:198.51.100.1
Dst:192.0.2.1
DSCP: 0x0
1
LBのVIP宛にリクエスト
Src:198.51.100.1
Dst:172.16.0.1
DSCP: 0x1
2
DSCPを立て、宛先をリアルサーバに書換えて転送
Dst:192.0.2.1
DSCP: 0x0
Src:198.51.100.1
3
DSCPを見て、
対応するアドレス
に書き換え(*)、
処理プロセスに渡す
Src:192.0.2.1
Dst:198.51.100.1
DSCP: 0x0
4
VIPをSource IPアドレス
としたレスポンス
(*)LinuxであればiptablesのPREROUTING等を用いる

View Slide

40
L3DSR【トンネル方式】
198.51.100.1 VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
LBとリアルサーバでIP-in-IPやGRE等のトンネルを張っておき、
トンネルとVIPを対応付け、どのVIP向けの通信かを識別する。
トンネルヘッダ分パケット長が増える為、物理ネットワーク上で
MTUサイズの考慮が必要。(*)
トンネル VIP
192.0.2.1
192.0.2.2
黄
青
リクエストがあったVIPに応じ
たトンネルを使ってリアルサー
バに転送
トンネルに応じたVIPでクライアン
トにレスポンス
(*)GREであれば1500+24=1524bytesのIP MTUが必要

View Slide

41
L3DSR【トンネル方式】
198.51.100.1
VIP1:192.0.2.1
VIP2:192.0.2.2
IF:10.0.0.1
172.16.0.1
Lo1:192.0.2.1
Lo2:192.0.2.2
172.16.0.2 172.16.0.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Lo1:192.0.2.1
Lo2:192.0.2.2
Src:198.51.100.1
Dst:192.0.2.1
1
LBのVIP宛にリクエスト
Dst:192.0.2.1
Src:198.51.100.1
3
トンネルヘッダを
除去した後、
処理プロセスに渡す
Src:192.0.2.1
Dst:198.51.100.1
4
VIPをSource IPアドレス
としたレスポンス
VIPに対応する
トンネルヘッダを
付与し転送
Src:198.51.100.1
Dst:192.0.2.1
Src:10.0.0.1
Dst:172.16.0.1
Outer
黄
Inner
Tunnel
2
④リアルサーバの物理インタフェースはトンネルヘッダを考慮した
MTUサイズ(GREなら1524bytes)になっているが、クライアントに
返す時には1500bytesでレスポンスする必要がある。

View Slide

42
L2DSRとL3DSRの比較
L2DSR L3DSR(DSCP) L3DSR(トンネル)
リクエスト処理性能 ◯
インタフェース
◯
リクエスト分だけの帯域
L7/TLS
×
TCPを終端しない為、L7/TLSの処理は不可
セッション制御
×
TCPを終端しない為、細かな制御は不可
リアルサーバ設定 ✓ Loopback
✓ ARP無返答
✓ Loopback
✓ DSCP
✓ Loopback
✓ トンネル
トポロジ
×
L2同一セグメント
に制限
◯
特に制限なし
その他 DSCP 6bits より多い
VIPは識別できない
物理ネットワーク、
リアルサーバのインタ
フェースそれぞれで
MTUの考慮が必要

View Slide

43
その他のロードバランサの機能
TLS終端
IPv4-IPv6プロトコル変換

View Slide

44
TLS終端(SSLオフロード)
192.168.0.1 192.168.0.2 192.168.0.3
VIP:203.0.113.1
LB
TLS終端をLBが行い、リアルサーバはHTTPの処理のみを行う。
✓ TLSの証明書管理の箇所が減る
✓ 専用ハードウェアによるTLS処理
といった特長がある。
必然、TCPセッションを終端する為、L2DSR/L3DSRでは利用できない
192.0.2.2
SLBがTLSを終端し、
リアルサーバとの通信は
HTTPで行う
192.0.2.1 192.0.2.3
HTTPS通信
HTTP通信
リアルサーバ
証明書

View Slide

45
IPv4-IPv6 プロトコル変換
192.168.0.1 192.168.0.2 192.168.0.3
VIP:2001:2::1
LB
クライアント・VIPがIPv6、リアルサーバがIPv4というケースでLBがプロト
コル変換を行う事により通信を可能とする事ができる。
2001:db8::1
リアルサーバ
192.168.0.254

View Slide

46
IPv4-IPv6 プロトコル変換の留意点
Source IPアドレス
Destination だけではなく Source IPアドレスも書き換えられる為、リア
ルサーバから見るとLBからアクセスされている様にみえる
→ LBでX-Forwarded-ForやRFC7239等のヘッダを挿入する事によりリ
アルサーバでも元々のSource IPアドレスを確認可能
MTUサイズとフラグメント
IPv4とIPv6では
✓ ヘッダサイズが異なる
✓ Path MTU Discoveryの方法が異なる
✓ IPv6ではフラグメントが認められていない
と言った差異がある。場合によっては送出MTUの調整などが必要となる。

View Slide

47
IPv4-IPv6 プロトコル変換
192.168.0.1 192.168.0.2
VIP:2001:2::1
LB
2001:db8::1
リアルサーバ
192.168.0.254
IPv4-IPv6プロトコル変換を実施し、RFC7239ヘッダを挿入する例
Src:2001:db8::1
Dst:2001:2::1
1
IPv6 VIPへアクセス
192.168.0.3
Src:192.168.0.254
Dst:192.168.0.1
Forwarded:
for=[2001:2::1];
by=[2001:db8::1];
proto=http;
host=example.com
2
IPv4へのプロトコル変換、
RFC7239ヘッダ挿入後、
IPv4のリアルサーバへ転送。
Dst:192.168.0.254
Src:192.168.0.1
3
IPv6 MTUサイズを考慮した
パケットサイズでIPv4で
LBにレスポンス
Dst:2001:db8::1
Src:2001:2::1
4
IPv6へプロトコル変換し、
クライアントへレスポンス。

View Slide

◼ NANOG51:
L3DSR – Overcoming Layer 2 Limitations of Direct Server Return Load Balancing
• https://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf
◼ ENOG19: ロードバランサーと俺
• http://enog.jp/wp-content/uploads/2013/02/ENOG19-KonoKono.pdf
◼ The PROXY protocol Versions 1 & 2
• http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
◼ RFC7239 Forwarded HTTP Extension
• https://tools.ietf.org/html/rfc7239
48
参考資料
Special Thanks To:
◼ Kono Kono @ A10 Networks

View Slide

49
Thank you!

View Slide

20170217 ロードバランサ再入門

20170217 ロードバランサ再入門

Ryuichi Takashima

More Decks by Ryuichi Takashima

Other Decks in Technology

Featured

Transcript