20170217 ロードバランサ再入門

2017/02/17 電力系NCC情報交換会

アプライアンスのロードバランサの動作全般を解説した資料。

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

Transcript

1. ロードバランサ再入門 2017年2月17日 高嶋隆一 第8回電力系NCC情報交換会 Version 02/19
2. おっさんエンジニアがロードバランサについて改めて設 計・構築するに当たり、 ✓ ロードバランサの基本 ✓ 最近の動向 (と言っても最新ではない) について整理した情報を共有します。 新人教育にでも使って頂けるとうれしいです！ 1 本資料の目的
3. ➢ ロードバランサの役割 ➢ SLBとGSLB ➢ 詳解SLB ✓ ロードバランサの機能 ✓ L4とL7 ✓ 振分けアルゴリズム ✓ 振分けトポロジ ✓ その他のロードバランサの機能 2 目次
4. 3 ロードバランサの役割
5. 4 用語 クライアント Virtual IP Address (VIP) ロードバランサ (LB) 通信の接続元。 Webコンテンツであればブラウザ。 クライアントから接続されるIPアドレス。 今回解説対象。 冗長化や負荷分散を行う。 ADC (Application Delivery Controller)ともいう。 リアルサーバ 実際に通信を処理するサーバ。 VMでもリアルサーバなので最近ややこしい。
6. 5 冗長化 1台のリアルサーバが故障しても、他の正常なリアルサーバによって サービス継続を可能とする冗長化機能。 (ロードバランサ自体も1:1、N:1で冗長化が可能) LB無し LB有り+複数のリアルサーバ
7. 6 負荷分散 1台のリアルサーバでは処理しきれない負荷を複数サーバに振分け、 スケールアウトさせる事により性能を上げる負荷分散機能。 LB無し LB有り+複数のリアルサーバ … … 1台分の性能 N台分の性能 …
8. 7 SLBとGSLB
9. 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 に通信を要求しているが実際には複数の サーバに処理が振分けられている。
10. 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応答で得られたので そこに接続 クライアント リアルサーバ
11. 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
12. 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を組み合わせた階層化ロードバランシング
13. 12 詳解SLB
14. 13 ロードバランサの基本機能 基本機能1.セッション振分け 基本機能2.アドレス変換 基本機能3.ヘルスチェックと切り離し 基本機能4.パーシステンス
15. 14 基本機能1.セッション振分け 192.168.0.1 192.168.0.2 192.168.0.3 VIP:203.0.113.1 振分け リアルサーバ SLB クライアントはVIPに対して通信を行うが、SLBはそのセッションの を特定の手順により複数のリアルサーバのうちの1台に振分けを行う。
16. 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!
17. 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への振分けを停止
18. 17 代表的なヘルスチェックの種類 PINGによってリアルサーバの死活を監視する ICMP TCPのポートの状態を監視する L4 HTTP GET等、プロトコルレベルの死活監視を行 う プロトコル監視 実際にアプリケーションレベルでの入力を行い、 その返答が正しいかの確認を行う アプリケーション 監視
19. 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
20. 19 代表的なパーシステンスの種類 Source IPアドレスもしくはSource IPアドレス+ ポートを識別に用いる手法 L3/L4 CookieをLBもしくはリアルサーバで挿入し、そ れを識別に用いる手法 Cookie URIを動的に生成し、識別に用いる手法 URI TLS session ID, Jsession-ID等のプロトコルのID を識別に用いる手法、L3-L7のパラメータから ハッシュを生成する手法等がある その他
21. 20 L4とL7 VIPに来た通信をどう区別して適切な リアルサーバ(群)に振分けるか ✓ L4LB ✓ L7LB ✓ ルールベース
22. 21 L4LB 該当VIP用リアルサーバ群 VIP: 203.0.113.0 TCP80 セッションを振分けるリアルサーバ群の選定を IPアドレス+TCP/UDPポート のみで識別する選択方法。基本的にはハードウェア処理の為、 パフォーマンスに優れる
23. 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
24. 23 ルールベース L3,L4,L7ヘッダ、場合によってはペイロードも含むパケットの 情報等を用いて条件分岐を行い、振分け先を選択する。 単純に振分け先を選択するだけではなく、他のアクションも可能。 多くは独自のプログラミング言語の態をとり、 ベンダによって実装が異なる。(F5 iRules, A10 aFleX等)
25. 24 振分けアルゴリズム 同一グループに属するリアルサーバ群 に対して、振分け先をどの様に決定す るか ✓ Round Robin ✓ Least Connection ✓ その他の振分けアルゴリズム ✓ Priority
26. 25 Round Robin 複数のリアルサーバから次のセッションをどこに振分けるかを 決める方式のひとつとしてRound Robin (RR)がある。 RRでは一定の順番でセッションを割り振っていく。 リアルサーバ群 1 1 ２ ２ ３ ３ ４ ４ ５ ５ A,B,C,A,B,C… の順にセッションを振分けるケース A B C
27. 26 Least Connection 複数のリアルサーバから次のセッションをどこに振分けるかを 決める方式のひとつとしてLeast Connectionがある。 Least Connectionでは同時接続数が最も少ないリアルサーバに振 分けを行う。 リアルサーバ群 最も同時接続数が少ないAに振分け A B C 同時接続数 50 55 55
28. 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
29. 28 振分け【Priority】 厳密にはアルゴリズムではないが、複数のリアルサーバグループ を使った振分けの仕組みとしてPriorityが存在する。 ヘルスチェックや同時接続数等の事前設定条件を満たす限り、 強制的にPriorityが高いリアルサーバグループに割り振られる。 Active/Standby構成やSorryページ等に使われる。 Priority 10 通常コンテンツを持つリアルサーバグ ループが異常時にSorryページを持つグ ループへフェイルオーバする構成例。 Priorityを逆にすれば緊急メンテナンス 時等にも使える Priority 5 通常 コンテンツ Sorry ページ
30. 29 振分けトポロジ 代表的なロードバランシングのトポロ ジとその特徴 ✓ インライン ✓ L2DSR ✓ L3DSR
31. 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
32. 31 インライン 長所 往復のパケットが全てLBを経由する為、 ◯ TCPセッションの状態監視、異常セッションの切断等、きめ細かな管 理がLB上で可能 特徴 ✓ IPアドレスのNATを行っている為、往復の経路が一致する 短所 往復のパケットが全てLBを経由する為、 ✖️必要となる性能が高くなる。また、リクエスト、レスポンスでは通常 後者の帯域が大きい為、より広帯域なインタフェースが必要
33. 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 と してレスポンス
34. 33 L2DSR 長所 レスポンスのトラフィックがLBを経由しない為、 ◯ LB自体の負荷が低く、結果として多くのリクエスト処理が可能となる ◯ リクエストのみの処理の為、広帯域のインタフェースを必要としない 上記の観点から、1VIPのトランザクション数も多く、レスポンスのデー タも大きなコンテンツプロバイダ向き 特徴 ✓ MACアドレスの変換でセッション振分けを行っており、レスポンスの トラフィックはLBを経由しない 短所 × セッションのステータスを管理できず、細かな制御は不可 × TCPを終端しない為、L7LB不可 × サーバでDSRに特化した特殊設定が必要 × LB、リアルサーバ共に同一のL2セグメントに存在する必要がある
35. 34 インラインとL2DSRの比較 インライン L2DSR リクエスト処理性能 △(*1) ◯ インタフェース × レスポンスに合わせた帯域 ◯ リクエスト分だけの帯域 L7/TLS ◯ × TCPを終端しない為、 L7/TLSの処理は不可 セッション制御 ◯ × TCPを終端しない為、細か な制御は不可 リアルサーバ設定 ◯ 特殊な設定は不要 × DSR用の設定が必要(*2) トポロジ ◯ 特に制限なし × L2同一セグメントに制限 (*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる (*2)LoopbackにVIPを設定する、LoopbackのARPは無視するといった追加設定が必要
36. 35 L3DSR L2DSRは大規模な環境向けの技術でありながら、MACアドレス変換 を用いている為、同一のL2セグメント上にLBとリアルサーバを置く 必要がある。 その為、下記の様な制約を持っている。 ✓ 大規模なL2ネットワークがデータセンタ上に必要 ✓ 事前に最大のリアルサーバの数を考慮したIPアドレス設計が必要 IPアドレス変換を用いたDSRを行ってL2の制約を外し、IPルーティ ングさえされていればDSRを利用可能とする技術がL3DSRである。
37. 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ネットワークを自由に 構成でき、セグメント追加も容易。
38. 37 L３DSRの方式 L2DSRでは通信を求められているVIPはIPヘッダの中にあったが、 L3DSRではIPアドレス変換を用いている為、どのVIP当ての通信か をLBからリアルサーバへ通知する必要がある。 方式としては下記の2つがある。 LBとリアルサーバ間でトンネルを張り、利用す るトンネルによってVIPを通知する方式 トンネル方式 LBとリアルサーバでVIPとDSCP bitの対応表を 持ち、DSCP bitによりVIPを通知する方式 DSCP方式
39. 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でクライア ントにレスポンス
40. 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等を用いる
41. 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が必要
42. 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でレスポンスする必要がある。
43. 42 L2DSRとL3DSRの比較 L2DSR L3DSR(DSCP) L3DSR(トンネル) リクエスト処理性能 ◯ インタフェース ◯ リクエスト分だけの帯域 L7/TLS × TCPを終端しない為、L7/TLSの処理は不可 セッション制御 × TCPを終端しない為、細かな制御は不可 リアルサーバ設定 ✓ Loopback ✓ ARP無返答 ✓ Loopback ✓ DSCP ✓ Loopback ✓ トンネル トポロジ × L2同一セグメント に制限 ◯ 特に制限なし その他 DSCP 6bits より多い VIPは識別できない 物理ネットワーク、 リアルサーバのインタ フェースそれぞれで MTUの考慮が必要
44. 43 その他のロードバランサの機能 TLS終端 IPv4-IPv6プロトコル変換
45. 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通信 リアルサーバ 証明書
46. 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
47. 46 IPv4-IPv6 プロトコル変換の留意点 Source IPアドレス Destination だけではなく Source IPアドレスも書き換えられる為、リア ルサーバから見るとLBからアクセスされている様にみえる → LBでX-Forwarded-ForやRFC7239等のヘッダを挿入する事によりリ アルサーバでも元々のSource IPアドレスを確認可能 MTUサイズとフラグメント IPv4とIPv6では ✓ ヘッダサイズが異なる ✓ Path MTU Discoveryの方法が異なる ✓ IPv6ではフラグメントが認められていない と言った差異がある。場合によっては送出MTUの調整などが必要となる。
48. 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へプロトコル変換し、 クライアントへレスポンス。
49. ◼ 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
50. 49 Thank you!