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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. 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 full-size slide

  9. 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 full-size slide

  10. 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 full-size slide

  11. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 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 full-size slide

  15. 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 full-size slide

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

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

    View full-size slide

  17. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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








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

    View full-size slide

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

    View full-size slide

  26. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 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 full-size slide

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

    View full-size slide

  31. 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 full-size slide

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

    View full-size slide

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

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

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

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

    View full-size slide

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

    View full-size slide

  35. 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 full-size slide

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

    View full-size slide

  37. 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 full-size slide

  38. 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 full-size slide

  39. 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 full-size slide

  40. 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 full-size slide

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

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

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

    View full-size slide

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

    View full-size slide

  43. 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 full-size slide

  44. 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 full-size slide

  45. 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 full-size slide

  46. 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 full-size slide

  47. ◼ 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 full-size slide

  48. 49
    Thank you!

    View full-size slide