Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20170217 ロードバランサ再入門

20170217 ロードバランサ再入門

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

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

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

Ryuichi Takashima

May 19, 2022
Tweet

More Decks by Ryuichi Takashima

Other Decks in Technology

Transcript

  1. ➢ ロードバランサの役割 ➢ SLBとGSLB ➢ 詳解SLB ✓ ロードバランサの機能 ✓ L4とL7

    ✓ 振分けアルゴリズム ✓ 振分けトポロジ ✓ その他のロードバランサの機能 2 目次
  2. 4 用語 クライアント Virtual IP Address (VIP) ロードバランサ (LB) 通信の接続元。

    Webコンテンツであればブラウザ。 クライアントから接続されるIPアドレス。 今回解説対象。 冗長化や負荷分散を行う。 ADC (Application Delivery Controller)ともいう。 リアルサーバ 実際に通信を処理するサーバ。 VMでもリアルサーバなので最近ややこしい。
  3. 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
  4. 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を組み合わせた階層化ロードバランシング
  5. 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!
  6. 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
  7. 19 代表的なパーシステンスの種類 Source IPアドレスもしくはSource IPアドレス+ ポートを識別に用いる手法 L3/L4 CookieをLBもしくはリアルサーバで挿入し、そ れを識別に用いる手法 Cookie

    URIを動的に生成し、識別に用いる手法 URI TLS session ID, Jsession-ID等のプロトコルのID を識別に用いる手法、L3-L7のパラメータから ハッシュを生成する手法等がある その他
  8. 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
  9. 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
  10. 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
  11. 31 インライン 長所 往復のパケットが全てLBを経由する為、 ◯ TCPセッションの状態監視、異常セッションの切断等、きめ細かな管 理がLB上で可能 特徴 ✓ IPアドレスのNATを行っている為、往復の経路が一致する

    短所 往復のパケットが全てLBを経由する為、 ✖️必要となる性能が高くなる。また、リクエスト、レスポンスでは通常 後者の帯域が大きい為、より広帯域なインタフェースが必要
  12. 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 と してレスポンス
  13. 33 L2DSR 長所 レスポンスのトラフィックがLBを経由しない為、 ◯ LB自体の負荷が低く、結果として多くのリクエスト処理が可能となる ◯ リクエストのみの処理の為、広帯域のインタフェースを必要としない 上記の観点から、1VIPのトランザクション数も多く、レスポンスのデー タも大きなコンテンツプロバイダ向き

    特徴 ✓ MACアドレスの変換でセッション振分けを行っており、レスポンスの トラフィックはLBを経由しない 短所 × セッションのステータスを管理できず、細かな制御は不可 × TCPを終端しない為、L7LB不可 × サーバでDSRに特化した特殊設定が必要 × LB、リアルサーバ共に同一のL2セグメントに存在する必要がある
  14. 34 インラインとL2DSRの比較 インライン L2DSR リクエスト処理性能 △(*1) ◯ インタフェース × レスポンスに合わせた帯域

    ◯ リクエスト分だけの帯域 L7/TLS ◯ × TCPを終端しない為、 L7/TLSの処理は不可 セッション制御 ◯ × TCPを終端しない為、細か な制御は不可 リアルサーバ設定 ◯ 特殊な設定は不要 × DSR用の設定が必要(*2) トポロジ ◯ 特に制限なし × L2同一セグメントに制限 (*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる (*2)LoopbackにVIPを設定する、LoopbackのARPは無視するといった追加設定が必要
  15. 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ネットワークを自由に 構成でき、セグメント追加も容易。
  16. 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でクライア ントにレスポンス
  17. 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等を用いる
  18. 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が必要
  19. 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でレスポンスする必要がある。
  20. 42 L2DSRとL3DSRの比較 L2DSR L3DSR(DSCP) L3DSR(トンネル) リクエスト処理性能 ◯ インタフェース ◯ リクエスト分だけの帯域

    L7/TLS × TCPを終端しない為、L7/TLSの処理は不可 セッション制御 × TCPを終端しない為、細かな制御は不可 リアルサーバ設定 ✓ Loopback ✓ ARP無返答 ✓ Loopback ✓ DSCP ✓ Loopback ✓ トンネル トポロジ × L2同一セグメント に制限 ◯ 特に制限なし その他 DSCP 6bits より多い VIPは識別できない 物理ネットワーク、 リアルサーバのインタ フェースそれぞれで MTUの考慮が必要
  21. 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通信 リアルサーバ 証明書
  22. 46 IPv4-IPv6 プロトコル変換の留意点 Source IPアドレス Destination だけではなく Source IPアドレスも書き換えられる為、リア ルサーバから見るとLBからアクセスされている様にみえる

    → LBでX-Forwarded-ForやRFC7239等のヘッダを挿入する事によりリ アルサーバでも元々のSource IPアドレスを確認可能 MTUサイズとフラグメント IPv4とIPv6では ✓ ヘッダサイズが異なる ✓ Path MTU Discoveryの方法が異なる ✓ IPv6ではフラグメントが認められていない と言った差異がある。場合によっては送出MTUの調整などが必要となる。
  23. 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へプロトコル変換し、 クライアントへレスポンス。
  24. ◼ 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