Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ロードバランサ再入門

28,728 views

Published on

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

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

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

Published in: Internet
  • Be the first to comment

ロードバランサ再入門

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

×