LVS 勉強会 (LVS Study)

Transcript

1. LVS 勉強会
2. お品書き 1. L2/L3 の基礎知識 2. VRRP の基礎知識 3. LVS について 4. keepalived について
3. L2/L3 の基礎知識
4. L2/L3 • L2 (データリンク層) MAC アドレスとかの世界 ◦ 物理的な NIC ポートを特定する (ちょっと乱暴) ◦ 上位層である L3 (ネットワーク層) からの要求に応じて下位層である L1 (物理層) に情報伝達の要 求を伝える ◦ 隣接する通信機器(ノード)との情報(フレーム)伝達に責任をもっている • L3 (ネットワーク層) IP アドレスの世界 ◦ ネットワーク的な場所を特定する ◦ 通信のエンド • ツー • エンドの情報(パケット)伝達に責任を持っている
5. tcpdump とかでよく見るパケットの中身 ethernet ヘッダ IPv4 ヘッダ データ ethernet frame IP packet • 本当は ethernet ヘッダの前に物理ヘッダ、データの末尾に Frame check sequence がついている (けど、tcpdump とかで は取れているので、書いていない )
6. ethernet ヘッダ ethernet ヘッダ IPv4 ヘッダ データ ethernet frame IP packet destination MAC アドレス source MAC アドレス type 0x0800
7. IPv4 ヘッダ ethernet ヘッダ IPv4 ヘッダ データ ethernet frame IP packet Version Header Length Type Of Service Identification Flags Time to Live Protocol Header Checksum Source Destination Total Length Fragment Offset Options Padding
8. ARP テーブル / ARP キャッシュ • MAC アドレスと IPv4 アドレスの対応表 • ARP (Address Resolution Protocol) によって生成される ◦ とある IPv4 アドレスを持っているノードの MAC アドレスを探す ◦ 例) 192.168.10.100 の MAC アドレスを持っている人を探す • GARP (Gratuitous ARP) ◦ 他ノードの ARP テーブルの更新を促す ◦ 例) 192.168.10.100 の MAC アドレスに変更があったことを広報する
9. 192.168.10.100 が 10.4.15.13 にデータを送信したい • 192.168.10.100 には ARP テーブルとルーティングテーブルがある ◦ ARP テーブル : MAC アドレスと IP アドレスの対応表 ◦ ルーティングテーブル : 宛先となる IP アドレスを配送するための宛先 • 192.168.10.100 の ethernet frame の錬成 ◦ 10.4.15.13 とは直接通信できないので、 10.4.15.13 と接続していると思われるノードをルーティン グテーブルから探す ▪ 仮に 192.168.10.1 が候補に上がる ◦ ARP テーブルから 10.4.15.13 と接続していると思われる IP アドレスの MAC アドレスを探す ◦ 錬成された ethernet frame の中身 ▪ ethernet ヘッダの destination に 192.168.10.1 の MAC アドレスを入れる ▪ IPv4 ヘッダの destination に 10.4.15.13 を入れる
10. まとめ • L2 は近接ノード間での通信手段 • L3 はエンド•ツー•エンドでの通信手段 • 各レイヤーは違いに独立している • MAC アドレスと IPv4 アドレスの対応は ARP によって実現している ◦ ちなみに IPv6 は ARP ではなく異なる近傍探索が実装されている
11. VRRP の基礎知識
12. 注意 VRRP の実装として keepalived を念頭に話します
13. VRRP : Virtual Router Redundancy Protocol • ルータを冗長化するためのプロトコル ◦ Master と Backup のルータを定義する ◦ L3 の冗長性を確保する • VIP ( Virtual IP ) の所在を管理するためにも使われている ◦ 例) DB の active master として VIP を登録 • VRID (Virtual Router ID) ◦ VRRP で構成している仮想ルータの ID • Priority ◦ 同一の VRID を持っている場合、Priority が高いノードが Master になる • VRRP 広報 ◦ マルチキャスト (224.0.0.18) を使用 ◦ VRRP 広報時は特殊な MAC アドレス (00:00:5E:00:01:XX) を使用する
14. VRRP による Master 選出 • VIP 192.168.10.1 が VRID 1 で 192.168.10.2 と 192.168.10.3 で構成されてい る 192.168.10.2 192.168.10.3 initialize initialize VRID 1 で Priority が 150 やで VRID 1 で Priority が 100 やで Master Backup VRID 1 で Priority が 150 やで
15. VRRP 起動時の挙動 • 実際には Backup で起動して、Master がいない、もしくは自分より Priority が低い Master が存在した場合は Master に昇格する、などの挙動をする ◦ Backup で起動するのは、事故防止 • nopreempt ◦ 自分より Priority が低い Master が存在しても、Master に昇格しない
16. VRRP 広報 • Master に昇格したら定期的に VRID、VIP、Priority を広報する ◦ この広報が聞こえなくなると Backup は Master 昇格を試みるために VRRP 広報を実施する
17. VRRP Packet Format (RFC 3768) version type virtual_router_id priority count VIP auth type advert_int check sum VIP (1) ... VIP (n) Authentication Data (1) Authentication Data (2) • 実は RFC 3768 的には authentication 周りは RFC 2338 との後方互換性 確保のために定義されているだけ ◦ keepalived 的にも VRRPv2 では非対応 (non-compliant) で、問題が 起きるかもしれへんで、と書かれている
18. IPv4 Packet Format for VRRP Version Header Length Type Of Service Identification Flags Time to Live Protocol Header Checksum Source Destination Total Length Fragment Offset Options Padding • Source は VRRP 広報をしているノードのプライマリアドレス • Destination は VRRP 向けに IANA でアサインされているマルチキャストアド レス (224.0.0.18) • TTL は 255。VRRP パケットを受け取ったルータは 255 以外の値が入って いる場合は破棄する (ルータ越えができない ) • Protocol は VRRP (112)
19. VRRP Master 遷移と ARP キャッシュ • Backup から Master に昇格したとき ◦ VIP の MAC アドレスが変わる ◦ ノードは ARP キャッシュとして VIP と MAC アドレスの対応表を持っている ◦ Master 昇格をしたときに GARP でブロードキャストネットワーク内の ARP キャッシュを更新する
20. まとめ • VRRP は Master / Backup によって L3 の冗長性を担保している • VRID と Priority によって VIP を管理している
21. LVS について
22. LVS (IPVS) • L4 の Load Balancer ◦ VIP を virtual server として、配下の real server に L4 レベルで負荷分散している • Linux Kernel の一部として実装されている ◦ Linux kernel のソースコードの net/netfilter/ipvs で実装されている ◦ 以前は Linux Kernel とは別のプロジェクトして開発されていたが、 kernel 2.4 あたりでマージされた • virtual server 内の負荷分散方式として複数の方式が実装されている • real server への通信手段として以下が実装されている ◦ LVS/NAT -> あまり使われていない ◦ LVS/TUN ◦ LVS/DR
23. 負荷分散と通信方式 • 負荷分散はトラフィックを割り当てる real server をどのように選択するか、という手 段 ◦ ラウンドロビンで割り当てる ◦ コネクション数が一番少ない real server を割り当てる ◦ keepalived.conf の virtual_server で lvs_sched として設定されている • 通信方式は通信元と real server をどのように通信させるか ◦ おもにネットワーク技術のお話になる ◦ keepalived.conf の virtual_server で lvs_method として設定されている
24. 負荷分散方式 • ラウンドロビン (rr) と重み付けラウンドロビン (wrr) • 最小接続数 (lc) と重み付け最小接続数 (wlc) ◦ 接続数が少ない real server を優先的に割り当てる ◦ 重み付けをした場合は接続数と real server の weight を考慮する • 宛先ハッシュ (dh) • 送信元ハッシュ (sh)
25. LVS/TUN と LVS/DR client LVS (Virtual Server) Real Server RIP VIP VIP • クライアントから見て行きと帰りの経路が異 なる ◦ LVS/NAT と比較して LVS がボトルネックに なる要素が少ない • LVS/TUN と LVS/DR は LVS から real server の通信方式が異なっている ◦ ネットワーク要件が異なる • real server は VIP に対する ARP リクエスト に答えてはいけない
26. LVS/DR client LVS (Virtual Server) Real Server RIP VIP VIP ethernet header src dst : LVS rip IPv4 header src dst : vip Data ethernet header src dst : realserver rip IPv4 header src dst : vip Data 宛先 MAC アドレスを変更している
27. LVS/TUN client LVS (Virtual Server) Real Server RIP VIP VIP ethernet header src dst : LVS rip IPv4 header src dst : vip Data ethernet header src dst : realserver rip IPv4 header src dst : realserver rip Data IPv4 header src dst : vip IPIP でカプセル化している
28. VIP のつく場所 • virtual server と real server で異なる ◦ virtual server eth0 などの実足 ◦ real server ループバックインターフェースや tun インターフェース • virtual server は VIP を対象にした ARP 要求に答える必要がある ◦ ip addr show dev eth0 とかして secondary なアドレスがあれば、 VRRP Master という読み方がで きる • real server は VIP を対象にした ARP 要求に答えてはいけない、かつ、LVS/TUN の場合は ipip カプセルを tun インターフェースで解く必要がある
29. LVS/TUN と LVS/DR の違い LVS/TUN LVS/DR real server への通信 IPIP カプセル 宛先の MAC アドレスを変更する real server 側の設定 IPIP でカプセル化されたパケットを受 けるためのインターフェースが必要 VIP に対する ARP 応答に答えないよ うにする ループバックインターフェースに VIP をつけ ておく VIP に対する ARP 応答に答えないように する 通信要件 異なるブロードキャストネットワークに 配送できる real server は LVS と同一のブロードキャ ストネットワークに存在する必要がある 戻りパケット real server から直接 client に投げる real server から直接 client に投げる
30. まとめ • real server との通信方式は複数ある ◦ LVS/TUN と LVS/DR はクライアントからみたパケット配送経路が異なる • 複数の負荷分散方式を必要に応じて選択する • LVS/TUN と LVS/DR でネットワーク要件が異なり、必要に応じて選択する ◦ LVS/TUN が使えるなら、ネットワーク設計の自由度が上がる
31. keepalived について
32. 落とし穴 : keepalived と LVS の関係 • LVS と keepalived は本来的には別物 ◦ LVS (IPVS) は Linux kernel の機能 • keepalived は基本的にユーザランドで動いている • LVS には ipvsadm という LVS の cli ツールが別に存在している ◦ keepalived を使わずに LVS を使うことも可能 ◦ keepalived を使って LVS を設定して、ipvsadm で状態を取得する、などの使い分け
33. keepalived is 何? • 二つの側面がある ◦ VRRP で IP アドレスを冗長性を管理する ◦ LVS による L4 ロードバランサーのインターフェース
34. keepalived のプロセスモデル http://keepalived.org/documentation.html • /var/log/messages などでは以下のようにど のプロセスが出力したかが app-name で区別 できる ◦ 親 keepalived ◦ Checkers Keepalived_healthcheckers ◦ VRRP Stack Keepalived_vrrp
35. keepalived.conf の歩き方 • man 5 keepalived.conf を読んでみる ◦ より詳細な記述内容は doc/keepalived.conf.SYNOPSIS ◦ keepalived.conf のサンプルは doc/samples 以下 • 以下の3種類に分別されている ◦ Global ◦ VRRP 向け設定 冗長化 ▪ vrrp_instance <STRING> {} で VRID ごとに定義されている ◦ IPVS 向け設定 負荷分散 ▪ virtual_server <STRING> {} で VIP (= virtual server) ごとに定義されている
36. まとめ • keepalived は以下の機能を提供する L4 Load Balancer である ◦ VRRP による VIP 管理 ◦ LVS ノードの死活監視と LVS の設定
37. 今日のまとめ • LVS の挙動を理解するには L2/L3 の基礎的な知識が必要 • VRRP によって VIP の冗長性を確保している • keepalived が VRRP、VIP、LVS のインターフェースになっている • LVS は通信方式でネットワーク要件が異なる
38. 便利なリンク集 • Linux Kernel ◦ Elixir Cross Referencer • LVS ◦ LVS Documentation ◦ LVS Knowledge Base ◦ LVS-HOWTO ◦ LVS-mini-HOWTO • keepalived のプロセスモデル • halfrack さんの LVS/TUN の解説記事
39. 完