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

    View Slide

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

    View Slide

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

    View Slide

  4. 3
    ロードバランサの役割

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. 7
    SLBとGSLB

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  13. 12
    詳解SLB

    View Slide

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

    View Slide

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

    View Slide

  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!

    View Slide

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

    View Slide

  18. 17
    代表的なヘルスチェックの種類
    PINGによってリアルサーバの死活を監視する
    ICMP
    TCPのポートの状態を監視する
    L4
    HTTP GET等、プロトコルレベルの死活監視を行

    プロトコル監視
    実際にアプリケーションレベルでの入力を行い、
    その返答が正しいかの確認を行う
    アプリケーション
    監視

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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








    A,B,C,A,B,C…
    の順にセッションを振分けるケース
    A B C

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. 34
    インラインとL2DSRの比較
    インライン L2DSR
    リクエスト処理性能 △(*1) ◯
    インタフェース
    ×
    レスポンスに合わせた帯域

    リクエスト分だけの帯域
    L7/TLS ◯
    ×
    TCPを終端しない為、
    L7/TLSの処理は不可
    セッション制御 ◯
    ×
    TCPを終端しない為、細か
    な制御は不可
    リアルサーバ設定

    特殊な設定は不要
    ×
    DSR用の設定が必要(*2)
    トポロジ

    特に制限なし
    ×
    L2同一セグメントに制限
    (*1)現在では性能がボトルネックになる事は少ないが、インタフェース速度からより上位のモデルが必要になる
    (*2)LoopbackにVIPを設定する、LoopbackのARPは無視するといった追加設定が必要

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. 42
    L2DSRとL3DSRの比較
    L2DSR L3DSR(DSCP) L3DSR(トンネル)
    リクエスト処理性能 ◯
    インタフェース

    リクエスト分だけの帯域
    L7/TLS
    ×
    TCPを終端しない為、L7/TLSの処理は不可
    セッション制御
    ×
    TCPを終端しない為、細かな制御は不可
    リアルサーバ設定 ✓ Loopback
    ✓ ARP無返答
    ✓ Loopback
    ✓ DSCP
    ✓ Loopback
    ✓ トンネル
    トポロジ
    ×
    L2同一セグメント
    に制限

    特に制限なし
    その他 DSCP 6bits より多い
    VIPは識別できない
    物理ネットワーク、
    リアルサーバのインタ
    フェースそれぞれで
    MTUの考慮が必要

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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の調整などが必要となる。

    View Slide

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

    View Slide

  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

    View Slide

  50. 49
    Thank you!

    View Slide