Successfully reported this slideshow.

ロードバランサ再入門

86

Share

1 of 50
1 of 50

ロードバランサ再入門

86

Share

Download to read offline

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

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

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

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

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

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

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

ロードバランサ再入門

  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!

×