ロードバランサ再入門

2017 年 2 月 17 日

株式会社 DMM.com ラボ

高嶋隆一

第 8 回電力系 NCC 情報交換会

Version 02/19

2

おっさんエンジニアがロードバランサについて改めて設計・構築するに当たり、

ロードバランサの基本 最近の動向 ( と言っても最新ではない )について整理した情報を共有します。

新人教育にでも使って頂けるとうれしいです！

本資料の目的

3

ロードバランサの役割 SLB と GSLB 詳解 SLB

ロードバランサの機能 L4 と L7 振分けアルゴリズム 振分けトポロジ その他のロードバランサの機能

目次

4

ロードバランサの役割

5

用語クライアント

Virtual IP Address (VIP)

ロードバランサ (LB)

通信の接続元。Web コンテンツであればブラウザ。

クライアントから接続される IP アドレス。

今回解説対象。冗長化や負荷分散を行う。ADC (Application Delivery Controller) ともいう。

リアルサーバ

実際に通信を処理するサーバ。VM でもリアルサーバなので最近ややこしい。

6

冗長化

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

LB 無し LB 有り + 複数のリアルサーバ

7

負荷分散

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

LB 無し LB 有り + 複数のリアルサーバ

… …

1 台分の性能 N 台分の性能

…

8

SLB と GSLB

9

サーバロードバランシング (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に通信を要求しているが実際には複数のサーバに処理が振分けられている。

10

グローバルサーバロードバランシング (GSLB)

LB が権威 DNS サーバとなる。1 つのホスト名に対する A もしくは AAAA レコードを複数したアドレスのうちいずれかを 1 つ返答し、異なる IP アドレスに負荷分散する技術。

権威 DNS サーバとしての動作であり、 TCP/UDP 他の通信を直接振分ける訳ではないことに注意。

GSLB

A/AAAA 振分け

www.example.com=192.0.2.1198.51.100.1203.0.113.1

192.0.2.1 198.51.100.1 203.0.113.1

今回は 203.0.113.1 がDNS 応答で得られたのでそこに接続

クライアント

リアルサーバ

11

GSLB の動き キャッシュ DNS

www.example.comの権威 DNS サーバ

=GSLB

www.example.comの IP アドレスは？

2

www.example.comの IP アドレスは？

4

www.example.comの権威 DNS を教える

3

複数ある A のうち203.0.113.1 を

A として返答

5

example.comの権威 DNS サーバ

クライアント

192.0.2.1 198.51.100.1 203.0.113.1www.example.com

のリアルサーバ

www.example.com

の IP アドレスは？1

203.0.113.16

203.0.113.1 に接続7

12

よくある web サービスのアーキテクチャ

www.example.comの権威 DNS サーバ

=GSLB

www.example.comの SLB

www.example.comの実サーバ

セッション振分けセッション振分けセッション振分け

example.comの権威 DNS サーバ

所謂普通の権威 DNS サーバ。GSLB を使うため、このケースでは www の NS を GSLB に移譲

www の負荷分散、冗長を行う為、A/AAAA に複数のレコードを登録障害時に切り外す為、 A/AAAA のTTL が短いのは許して orz

NS 移譲

A/AAAA 振分け

GSLB と SLB を組み合わせた階層化ロードバランシング

13

詳解 SLB

14

ロードバランサの基本機能

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

15

基本機能 1. セッション振分け

192.168.0.1 192.168.0.2 192.168.0.3

VIP:203.0.113.1

振分け

リアルサーバ

SLB

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

16

基本機能 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.1Dst:203.0.113.1

192.0.2.1パケットヘッダ (IP アドレス書換えの場合 )

Src:192.0.2.1Dst:192.168.0.3Changed!

17

基本機能 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 への振分けを停止

18

代表的なヘルスチェックの種類

PING によってリアルサーバの死活を監視するICMP

TCP のポートの状態を監視するL4

HTTP GET等、プロトコルレベルの死活監視を行うプロトコル監

視

実際にアプリケーションレベルでの入力を行い、その返答が正しいかの確認を行う

アプリケーション監視

19

基本機能 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

20

代表的なパーシステンスの種類

Source IP アドレスもしくは Source IP アドレス + ポートを識別に用いる手法L3/L4

Cookie を LB もしくはリアルサーバで挿入し、それを識別に用いる手法Cookie

URI を動的に生成し、識別に用いる手法URI

TLS session ID, Jsession-ID等のプロトコルのID を識別に用いる手法、 L3-L7 のパラメータからハッシュを生成する手法等がある

その他

21

L4 と L7VIP に来た通信をどう区別して適切なリアルサーバ (群 ) に振分けるか

L4LB L7LB ルールベース

22

L4LB

該当 VIP 用リアルサーバ群

VIP: 203.0.113.0 TCP80

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

23

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.1Host: example.jp

24

ルールベース

L3,L4,L7 ヘッダ、場合によってはペイロードも含むパケットの情報等を用いて条件分岐を行い、振分け先を選択する。

単純に振分け先を選択するだけではなく、他のアクションも可能。

多くは独自のプログラミング言語の態をとり、ベンダによって実装が異なる。 (F5 iRules, A10 aFleX等 )　　　　　　　　

25

振分けアルゴリズム

同一グループに属するリアルサーバ群に対して、振分け先をどの様に決定するか

Round Robin Least Connection その他の振分けアルゴリズム Priority

26

Round Robin

複数のリアルサーバから次のセッションをどこに振分けるかを決める方式のひとつとして Round Robin (RR) がある。RR では一定の順番でセッションを割り振っていく。

リアルサーバ群

1

1

２

２

３

３

４

４

５

５

A,B,C,A,B,C…の順にセッションを振分けるケース

A B C

27

Least Connection

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

リアルサーバ群

最も同時接続数が少ない A に振分け

A B C

同時接続数 50 55 55

28

その他の振分けアルゴリズム

サーバ毎に重み付けを行い、振分けるセッション数をリアルサーバによって変えるRound Robin

左の例では A,A,B,C,A,A,B,C… となる

Weighted RR

Weight 2 1 1::A B C

ヘルスチェックによる遅延時間等をパラメータとして最も負荷が低いと思われるサーバに振分ける

左の例では RTT が短い B が選択される

ヘルスチェックとの組合せ

RTT 5ms 3ms 5msA B C

29

振分け【 Priority】

厳密にはアルゴリズムではないが、複数のリアルサーバグループを使った振分けの仕組みとして Priority が存在する。

ヘルスチェックや同時接続数等の事前設定条件を満たす限り、強制的に Priority が高いリアルサーバグループに割り振られる。Active/Standby 構成や Sorryページ等に使われる。

Priority 10

通常コンテンツを持つリアルサーバグループが異常時に Sorryページを持つグループへフェイルオーバする構成例。

Priority を逆にすれば緊急メンテナンス時等にも使えるPriority 5

通常コンテンツ

Sorryページ

30

振分けトポロジ

代表的なロードバランシングのトポロジとその特徴

インライン L2DSR L3DSR

31

インライン

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.1Dst:203.0.13.0

1

1

Src:198.51.100.1Dst:192.168.0.3

NAT

Changed

22 Dst:198.51.100.1

Src:192.168.0.3

33

Dst:198.51.100.1Src:203.0.113.0

NAT

Changed

4

4

32

インライン

長所往復のパケットが全て LB を経由する為、◯TCP セッションの状態監視、異常セッションの切断等、きめ細かな管

理が LB 上で可能

特徴

IP アドレスの NAT を行っている為、往復の経路が一致する

短所

往復のパケットが全て LB を経由する為、✖必要となる性能が高くなる。また、リクエスト、レスポンスでは通常後者の帯域が大きい為、より広帯域なインタフェースが必要

33

L2DSR (Direct Server Return)

192.0.2.10MAC:B

192.0.2.11MAC:C

192.0.2.254MAC:Z

198.51.100.1

Loopback192.0.2.1

VIP:192.0.2.1MAC:A

Loopback192.0.2.1

宛先 MAC アドレスの書換えによりリアルサーバへの振分けを行う。リアルサーバは VIP を Loopback アドレスとして設定し、それをSource アドレスとしてレスポンスを行う。レスポンスは LB を経由しない非対称な通信となる。

収容ルータ

LB

1 3

2

1 Src:198.51.100.1Dst:192.0.2.1DstMAC:A

レスポンスリクエスト

2 Src:198.51.100.1Dst:192.0.2.1DstMAC:B

Dst MACTranslation

Changed

3 Dst:198.51.100.1Src:192.0.2.1DstMAC:Z

Loopback に 設 定し た VIP をSource と し て レスポンス

34

L2DSR

長所レスポンスのトラフィックが LB を経由しない為、◯LB 自体の負荷が低く、結果として多くのリクエスト処理が可能とな

る◯リクエストのみの処理の為、広帯域のインタフェースを必要としな

い上記の観点から、 1VIP のトランザクション数も多く、レスポンスのデータも大きなコンテンツプロバイダ向き

特徴 MAC アドレスの変換でセッション振分けを行っており、レスポンス

のトラフィックは LB を経由しない

短所

✖セッションのステータスを管理できず、細かな制御は不可✖TCP を終端しない為、 L7LB不可✖サーバで DSR に特化した特殊設定が必要✖LB 、リアルサーバ共に同一の L2 セグメントに存在する必要がある

35

インラインと L2DSR の比較インライン L2DSR

リクエスト処理性能 △(*1) ◯

インタフェース ×レスポンスに合わせた帯域

◯リクエスト分だけの帯域

L7/TLS ◯×

TCP を終端しない為、L7/TLS の処理は不可

セッション制御 ◯×

TCP を終端しない為、細かな制御は不可

リアルサーバ設定 ◯特殊な設定は不要

×DSR 用の設定が必要 (*2)

トポロジ ◯特に制限なし

×L2 同一セグメントに制限

(*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる(*2)Loopback に VIP を設定する、 Loopback の ARP は無視するといった追加設定が必要

36

L3DSRL2DSR は大規模な環境向けの技術でありながら、 MAC アドレス変換を用いている為、同一の L2 セグメント上に LB とリアルサーバを置く必要がある。

その為、下記の様な制約を持っている。

大規模な L2ネットワークがデータセンタ上に必要 事前に最大のリアルサーバの数を考慮した IP アドレス設計が必

要

IP アドレス変換を用いた DSR を行って L2 の制約を外し、 IP ルーティングさえされていれば DSR を利用可能とする技術が L3DSRである。

37

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ネットワークを自由に構成でき、セグメント追加も容易。

38

L３DSR の方式

L2DSR では通信を求められている VIP は IP ヘッダの中にあったが、L3DSR では IP アドレス変換を用いている為、どの VIP 当ての通信かを LB からリアルサーバへ通知する必要がある。

方式としては下記の 2 つがある。

LB とリアルサーバ間でトンネルを張り、利用するトンネルによって VIP を通知する方式トンネル方式

LB とリアルサーバで VIP と DSCP bit の対応表を持ち、 DSCP bit により VIP を通知する方式DSCP方式

39

L3DSR【DSCP方式】

198.51.100.1

VIP1:192.0.2.1VIP2:192.0.2.2IF:10.0.0.1

172.16.0.1

Lo1:192.0.2.1Lo2:192.0.2.2

172.16.0.2 172.16.0.2

Lo1:192.0.2.1Lo2:192.0.2.2

Lo1:192.0.2.1Lo2:192.0.2.2

予め、 DSCP と VIP の対応表を LB とリアルサーバで持っておき、どの VIP 向けの通信かを識別する

DSCP VIP192.0.2.1192.0.2.2

0x10x2

リクエストがあった VIP に応じた DSCP bit を立ててリアルサーバに転送

DSCP bit に応じた VIP でクライアントにレスポンス

40

L3DSR【DSCP方式】

198.51.100.1

VIP1:192.0.2.1VIP2:192.0.2.2IF:10.0.0.1

172.16.0.1

Lo1:192.0.2.1Lo2:192.0.2.2

172.16.0.2 172.16.0.2

Lo1:192.0.2.1Lo2:192.0.2.2

Lo1:192.0.2.1Lo2:192.0.2.2

DSCP VIP192.0.2.1192.0.2.2

0x10x2

Src:198.51.100.1Dst:192.0.2.1DSCP: 0x01

LB の VIP 宛にリクエスト

Src:198.51.100.1Dst:172.16.0.1DSCP: 0x1

2

DSCP を立て、宛先をリアルサーバに書換えて転送

Dst:192.0.2.1DSCP: 0x0

Src:198.51.100.13

DSCP を見て、対応するアドレスに書き換え (*) 、処理プロセスに渡す

Src:192.0.2.1Dst:198.51.100.1DSCP: 0x0 4

VIP を Source IP アドレスとしたレスポンス

(*)Linux であれば iptables の PREROUTING等を用いる

41

L3DSR【トンネル方式】

198.51.100.1 VIP1:192.0.2.1VIP2:192.0.2.2IF:10.0.0.1

172.16.0.1

Lo1:192.0.2.1Lo2:192.0.2.2

172.16.0.2 172.16.0.2

Lo1:192.0.2.1Lo2:192.0.2.2

Lo1:192.0.2.1Lo2:192.0.2.2

LB とリアルサーバで IP-in-IP や GRE等のトンネルを張っておき、トンネルと VIP を対応付け、どの VIP 向けの通信かを識別する。トンネルヘッダ分パケット長が増える為、物理ネットワーク上でMTU サイズの考慮が必要。 (*)

トンネル VIP192.0.2.1192.0.2.2

黄青

リクエストがあった VIP に応じたトンネルを使ってリアルサーバに転送

トンネルに応じた VIP でクライアントにレスポンス

(*)GRE であれば 1500+24=1524bytes の IP MTU が必要

42

L3DSR【トンネル方式】

198.51.100.1

VIP1:192.0.2.1VIP2:192.0.2.2IF:10.0.0.1

172.16.0.1

Lo1:192.0.2.1Lo2:192.0.2.2

172.16.0.2 172.16.0.2

Lo1:192.0.2.1Lo2:192.0.2.2

Lo1:192.0.2.1Lo2:192.0.2.2

10.254.0.1

10.254.0.2

Src:198.51.100.1Dst:192.0.2.1

1

LB の VIP 宛にリクエスト

Dst:192.0.2.1Src:198.51.100.1

3

トンネルヘッダを除去した後、処理プロセスに渡す

Src:192.0.2.1Dst:198.51.100.1 4

VIP を Source IP アドレスとしたレスポンス

VIP に対応するトンネルヘッダを付与し転送

Src:198.51.100.1Dst:192.0.2.1

Src:10.0.0.1Dst:172.16.0.1

Outer

黄

Inner

Tunnel

2

④リアルサーバの物理インタフェースはトンネルヘッダを考慮した　MTU サイズ (GRE なら 1524bytes) になっているが、クライアントに 返す時には 1500bytes でレスポンスする必要がある。

43

L2DSR と L3DSR の比較L2DSR L3DSR(DSCP) L3DSR( トンネ

ル )リクエスト処理性能 ◯

インタフェース ◯リクエスト分だけの帯域

L7/TLS ×TCP を終端しない為、 L7/TLS の処理は不可

セッション制御 ×TCP を終端しない為、細かな制御は不可

リアルサーバ設定 Loopback ARP 無返答

LoopbackDSCP

Loopback トンネル

トポロジ×

L2 同一セグメントに制限

◯特に制限なし

その他 DSCP 6bits より多いVIP は識別できない

物理ネットワーク、リアルサーバのインタフェースそれぞれでMTU の考慮が必要

44

その他のロードバランサの機能

TLS終端IPv4-IPv6プロトコル変換

45

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 通信

リアルサーバ

証明書

46

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

47

IPv4-IPv6 プロトコル変換の留意点

Source IP アドレス

Destination だけではなく Source IP アドレスも書き換えられる為、リアルサーバから見ると LB からアクセスされている様にみえる

→ LB で X-Forwarded-For や RFC7239 等のヘッダを挿入する事によりリアルサーバでも元々の Source IP アドレスを確認可能

MTU サイズとフラグメント

IPv4 と IPv6 では ヘッダサイズが異なる Path MTU Discovery の方法が異なると言った差異がある。場合によっては送出MTU の調整などが必要となる。

48

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::1Dst:2001:2::1

1

IPv6 VIP へアクセス

192.168.0.3

Src:192.168.0.254Dst: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.254Src:192.168.0.1

3

IPv6 MTU サイズを考慮したパケットサイズで IPv4 でLB にレスポンス

Dst:2001:db8::1Src:2001:2::1

4IPv6 へプロトコル変換し、クライアントへレスポンス。

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

49

参考資料

Special Thanks To: Kono Kono @ A10 Networks

50

Thank you!