Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

3 ロードバランサの役割

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

7 SLBとGSLB

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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応答で得られたので そこに接続 クライアント リアルサーバ

Slide 11

Slide 11 text

10 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.1 www.example.com のリアルサーバ www.example.com のIPアドレスは? 1 203.0.113.1 6 203.0.113.1に接続 7

Slide 12

Slide 12 text

11 よくある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を組み合わせた階層化ロードバランシング

Slide 13

Slide 13 text

12 詳解SLB

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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!

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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 と してレスポンス

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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でクライア ントにレスポンス

Slide 40

Slide 40 text

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等を用いる

Slide 41

Slide 41 text

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が必要

Slide 42

Slide 42 text

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でレスポンスする必要がある。

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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通信 リアルサーバ 証明書

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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へプロトコル変換し、 クライアントへレスポンス。

Slide 49

Slide 49 text

◼ 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

Slide 50

Slide 50 text

49 Thank you!