JANOG43 セルフフォローアップ
JANOG43に参加しました。2,3日目のみの参加でしたが、新しい技術・事例や各社の運用の工夫など、非常に勉強になるプログラムばかりでした。 その場では理解が追いつかないところが多々あったので、特に気になったプログラムを2件だけピックアップして自分のためにフォローアップしたいと思います。
Note
- (本来と使い方は違いますが) 引用の部分に私の所感や調べたことを記載しています。
- 理解の誤りや記述の間違いにお気づきの場合には、お手数ですがコメント等でご指摘いただけると幸いです。
- 後日アーカイブ動画が配信されたら再度見直して加筆修正する部分もあるかと思います。
Day2: LINEのネットワークをゼロから再設計した話
LINEのネットワークをゼロから再設計した話
LINE株式会社の小林さんによる発表。個人的には今回のJANOG全体を通して一番衝撃と感銘を受けたプログラムでした。
背景と方針
- それまでのLINEのネットワークの課題は、East-Westトラフィックの増加によるキャパシティ圧迫とトラディショナルな2N構成に起因する運用の複雑化にあった。
- 過去のLINEのネットワーク構成については JANOG39にて同社の三枝さんによる発表でも語られており、2015年以降から顕在化した様々な課題に対して、アーキテクチャレベルでの見直しを図ることで、スケーラビリティの高いネットワークを最小数のオープンなプロトコルのみで構築することで、根本解決を目指す。
(筆者メモ)
一つのキーワードとして、可能な限り "シンプル" に設計・構築するという思想が全体に散りばめられていたと感じました。
新しいアーキテクチャ
- Externalを除いて事実上Spineが1番上になる3階層のCLOSアーキテクチャをホワイトボックススイッチを利用して実現。
- 挙げられていた事前資料も踏まえると、ToRより上位では全て100G Linkを利用しサーバ間通信のボトルネックを排除、また各階層毎にN+1スケールが可能なため、障害に強く拡張性の高いネットワークを構築できる。
- 物理構築が完了している前提で、ZTPとAnsibleを用いた設定を行い、1,000台以上の ホワイトボックススイッチを2,3時間で構築可能。
(筆者メモ)
CLOSネットワークとはOTTを中心に積極的に採用されるDCネットワーク構成で、サーバ群が接続されるLeafとそれを束ねるSpineから成り、East-Westトラフィックに対し高いスケーラビリティを持ちます。改めて復習しましたが、以下の発表が参考になりました。
資料：JANOG38 :: ヤフーのIP CLOS ネットワーク
(筆者注記: 発表では新アーキテクチャに関する様々な技術要素が説明されていましたが、ポイントを掻い摘んで復習します。全貌は是非発表資料を御覧ください。)
L2-LESS
- 通常のCLOSネットワークではToRより上がL3、下がL2となるが、サーバから一方のToRに向けたトラフィックをもう一方のToRに振り替える際に、サーバ管理者に作業を依頼する必要があるのみならず、パケットロスが発生してしまう。 それを防ぐためサーバにBGPをしゃべらせることでToR <-> サーバ間をL3で接続。
- 実装としては (筆者補足：質疑で説明あり。LINE社のPrivate CloudはOpenStackで構築されている。) Compute Node上でFRRを動作させ、ハイパーバイザ上のRouting Tableを監視して、ハイパーバイザに接続されたVMの/32のホスト経路をToRにBGPで広報する。
- (筆者補足：質疑で説明あり) アプリケーションの要求によってはどうしてもL2が必要なケースがあり、ホワイトボックススイッチでMC-LAGを利用している箇所も存在する。
(筆者メモ)
パケロスの仕組みが分からず推測です。
BondingされたサーバのAct-SbyインターフェースとMC-LAG ToR間の接続で、例えばToR Aを切り離してメンテナンスする際に、サーバのActのLinkを落としてSbyをActive化しようとするとMC-LAGの切り替わりが完了するまでの数百msecの間サーバ宛のトラフィックは既に切れている旧Actインターフェースに流れ込もうとしロスしてしまう、といった感じなのでしょうか。
サーバから見た経路情報
- ハイパーバイザ上のFRRでBGPの経路を見ると2台のToR AS4208258575とAS4208258576のうち前者から受信した経路がalways-compare-medによりBest Pathに選ばれてる。
- 選ばれた経路のNext Hopには、IPv4の経路であるがRFC5549によりIPv6のリンクローカルアドレスが表示される。
- ただしLinux KernelではIPv6のNext Hopを登録することができないため、実際にはIPv4のリンクローカルアドレスによってルーティングされる。
(筆者メモ)
RFC5549はIPv4のNLRIにIPv6のNext Hopを設定して広報する技術。日本語だとIRS26で土屋さんが発表された資料が参考になりました。また、FRRのRFC5549の動作については以下の記事が参考になりました。
FRRはRFC5549な経路をLinuxカーネルのルーティングテーブルへどうやってインストールするのか - yunazuno.log
ホワイトボックススイッチの採用理由
- BGP UnnumberedとHostname Capability for BGPを使いたく、両実装を満たすFRRを動作させるため、LinuxベースNOSで動くCumulusを採用。
- (補足：質疑で説明あり) 機器選定では調達コストより運用コストの低下を重視。また、実際には各社の製品を比較しショートパケットの転送に優れた製品を選択した。
(筆者メモ)
BGP Unnumbered
RFC5549の拡張で、インターフェースにIPアドレスを設定することなくBGPピアを上げることができる技術。Cumulus社の動画は分かりやすかったです。
Hostname Capability for BGP
Open MessageにFQDNを入れて交換することでBGPピアを張るだけで対向のHostnameが分かるようにする技術。
データセンター間ネットワーク
- DC内のみならずDC間接続においてもL2オーバーレイは作らないポリシーのもと、シンプルなSR-MPLSを採用。
- 元々の帯域に余裕をもたせているため、帯域制御も不要。
(筆者メモ)
残念ながらSegment Routingを十分に理解していないため中途半端に書かずに別記事か何かでまとめようと思います。
今後の展望
- 様々なビジネスニーズに迅速に対応するため、一つのアンダーレイネットワーク上に複数のオーバーレイテナントを構築すること検討中。
- 実現手法としてSRv6に注目している。
Day3: オンプレミスKubernetesのネットワーク
オンプレミスKubernetesのネットワーク
株式会社Jストリームの城田さんによる発表。私はKubernetes勉強中の身で各CNI実装についてよく知らなかったため、エッセンスやメリット/デメリットがまとまった発表は大変有難かったです。
Kubernetesをオンプレミスで動かす理由
Node間ネットワーク
- Kubernetes本体ではネットワーキング機能は提供しておらず、Pod間通信、Serviceと他NodeのPod間通信にはNode同士を接続するネットワークが必要となる。
- 抽象化されたCNI (Container Network Interface) に従ってネットワークを実装することで初めてClusterとして機能する。
- 以降代表的なCNI実装を紹介。
Flannel
- Nodeに渡りユニキャストなVXLANを構築する。VXLAN以外にもIP-IPやIPSec(実験的)にも対応している。最近更新頻度が下がってきたのが懸念。
- 各Nodeにflanneldが立ち上がり、VXLANインターフェースである
flannel.1とBridgeインターフェースであるcni.0を作製。Node内のPod間通信はcni.0を経由し、Node間通信ではPodからNodeへ転送後、NodeのRIBに従って到達したflannel.1でVXLANのカプセリング化を行って宛先のNodeへ転送される。
(筆者メモ)
以下の記事も参考になりました。Node間通信でNodeのRIB, ARPテーブル, FDBに書かれている情報はflanneldが書き込みをしているようです。
Kubernetes Network Deep Dive (NodePort, ClusterIP, Flannel) - Qiita
Project Calico
- Bridgeやオーバーレイを作らずにBGPを用いたL3で処理を完結する。Network Policyに対応している。
- Calicoのconfig情報を保有するetcdを除く複数のプロセスが一つのPodにまとめられ、その中の一つであるBIRDが(デフォルトでは)フルメッシュでBGP接続を行う。
- Bridgeは作製されないのでNode内通信はNodeでルーティングされ、Node間通信はBGPで学習した経路情報によって行われる。
(筆者メモ)
FlannelとCalicoのさらに詳しい動作は JAPAN CONTAINER DAYS V18.12 でも発表があり、こちらも分かりやすいです。
資料：コンテナネットワーキング（CNI）最前線
アーカイブ動画：[1BL] コンテナネットワーキング（CNI）最前線 - YouTube
kube-router
- FlannelとCalicoをあわせたような動作で、Node内通信はBridge経由、Node間通信はBGPによるルーティングを提供する。
- BGPの設定はNodeのAnnotationsに記載する。
- CalicoはRoute Reflectorを設ける時に専用のコンテナを起動する必要があるが、kube-routerではCluster内からRoute Reflectorを選択することができる。
質疑の時間にコメントがあり、日本国内で自前でKubernetesを建てている人に聞くとFlannelとCalicoがほとんどでkube-routerを使っているケースは稀とのこと。
Node外ネットワーク
- クラウド上でマネージドなKubernetesを使う場合には各社が提供するロードバランサを使い、LoadBalancerタイプのServiceを利用することでCluster外からPodへの通信を通すとができるが、オンプレではそれがない。NodePortタイプやIngressタイプのServiceを利用するにしても、なんらかこれらを束ねるロードバランサーが必要になる。
- 以降、Cluster外部からアクセスを可能とするロードバランサを紹介。
MetalLB
- Kubernetes Node上で動くロードバランサ。L2モード/BGPモードがある。
- L2モードではService毎に代表Nodeを選びProxy ARPすることで当該Service宛の通信を全て一つのNodeで受け内部でロードバランスされる。トラフィックが一つのNodeに集中することが難点。
- BGPモードではCluster外部のルータとBGPを張りECMPを行う。外部のルータと、Cluster内のServiceで二重にロードバランスするのが難点。設定によってServiceでのロードバランスをしないようにすることができるが、外部のルータはCluster内のPodの配置を認識できないため、トラフィックに偏りが生じてしまう。
F5 Container Connector
- F5社のBIG-IPという製品をKubernetesから設定することができる。NodePortモード/Clusterモードがある。
- NodePortモードではMetalLBのBGPモードと同じくBIG-IPとServiceとで二重にロードバランスする。
- ClusterモードではBIG-IPをKubernetes内に組み込むことで、FlannelまたはCalicoを利用してPodに向けたロードバランスを行う。
- 商用環境でBIG-IPを利用している実績がある。
自社の構成
- FlannelとCalicoはBIG-IPとの連携に課題があると感じ、kube-router + F5 Container Connector (Clusterモード) で構築を行っている。
(筆者メモ)
以下の発表ではCNI含めたKubernetesネットワークの"すべて"について語られており、圧巻です。
発表資料： Kubernetes ネットワーキングのすべて
アーカイブ動画：[1B1] Kubernetes ネットワーキングのすべて - YouTube
おまけ
上記の発表に比べると大変お恥ずかしいのですが、私自身もLight Lighting Talk大会で発表させていただきました。 speakerdeck.com
普段の運用で感じている課題を、最近流行りのクラウドネイティブ関連技術で何とかできないかと思い勢いでやってみた、という内容です。
発表の意図としては、やったことそのものを伝えたいというよりネットワークとクラウドネイティブな技術との関わりがますます活発化するであろうことを、JANOGerの皆さんと共有できればと思った次第です。今回のJANOGでは他にもそれ系の発表が多々あり、私自身改めてその重要性を感じました。
試作機の実装は趣味で進行中、課題は山積み前途多難ですがぼちぼちやってます。
おわり
他にも勉強になったプログラムは沢山ありましたが、取り急ぎ勢いで書けるところまでを書きました。 後ほどアーカイブ動画で復習しようと思います。発表者の皆さん、スタッフの皆さんありがとうございました。
