機械学習クラスタ コンテナネットワーキング BoF

JANOG 54の機械学習クラスタ コンテナネットワーキング BoF (2024/7/5) での発表資料です。

Transcript

1. 機械学習クラスタ コンテナネットワーキング BoF JANOG 54 (2024/7/5) Sho Shimizu, Preferred Networks, Inc.
2. 2 はじめに (1/2) • JANOG 52以降、AI/ML向けネットワークの発表が増えている • KubeCon EU 2024ではAI/MLやGPUが注目トピックの1つだった ◦ KubeCon NA 2024のCFPでもAI + MLがsuggested topicsに • 一方で具体的な設計パターンを含んだ事例はそんなに多くない印象 ◦ AI/MLクラスタを構築、運用する機会は限られる ◦ 新しいトピックである
3. 3 • Preferred Networksでは2019年以降、RoCEv2を使ったRDMAが利用 可能なAI/ML向けKubernetesクラスタを構築、運用している • これまでのクラスタの設計や運用での試行錯誤や知見はあるものの公開 されている事例が少ないので自社での設計との比較が難しい • AI/ML向けKubernetesクラスタを構築する時のデザイン空間はネット ワークに限っても結構広い AI/ML向けKubernetesクラスタのネットワーク設計の議論がしたい はじめに (2/2)
4. 4 • RDMAの実現方法とCNI pluginの構成 ◦ Preferred Networksでの事例 ◦ 議論 • Multus + SR-IOV CNI pluginでの設計の詳細 ◦ デザイン空間の詳細 ◦ Preferred Networksでの事例 ◦ 議論 本日の流れ
5. 5 RDMAの実現方法: SR-IOVを利用する方法 veth VF eth0 net1 PF VF VF veth VF Pod Podのnetnsに移す NIC ホスト 通常ネットワーク RDMA用ネットワーク SR-IOVによる NICの仮想化
6. 6 CNI pluginの構成: 2019年〜2021年 内製 CNI plugin kubelet Pod eth0 net1 通常ネットワーク用 RDMA用 VFを付ける • RDMA用ネットワークと通常ネットワークは同一物理ネットワーク • 1ノードあたり2 PFs or 4 PFs (100GbE) • 1PFあたり16 VFs or 32 VFs • 内製CNI pluginによって(無理矢理)マルチNIC podを実現
7. 7 • 割当可能なVFがなくなるとpodの作成に失敗する 👈 VFはKubernetesが認識可能なリソースではない • Cluster IPでの通信のためにkube-proxyにパッチを当てていた 👈 Podに付けられたVFにはホストのiptablesが適用されない ◦ パッチ起因の問題 ▪ Podの起動直後にCluster IPの疎通がない ▪ kube-proxyのメモリ使用量が増加し続ける ▪ Kubernetsのバージョンアップの手間が増える 詳しくはブログに書いてます https://tech.preferred.jp/ja/blog/cni-plugin-in-pfn-kubernetes-cluster/ CNI pluginの構成 (2019年〜2021年) の問題点
8. 8 RDMA対応の典型的CNI plugin構成 Multus kubelet Pod eth0 net1 CNI plugin CNI plugin 通常ネットワーク用 インターコネクト用 2種類のCNI pluginにそれぞれ何を採用するかという問題 VFを付ける
9. 9 構成その1 (Calico + 内製CNI plugin) Multus kubelet Pod eth0 net1 Calico 内製 CNI plugin 通常ネットワーク用 RDMA用 VFを付ける
10. 10 • kube-proxyのパッチが不要 👉 kube-proxyのパッチ由来の問題が解決 • 内製CNI pluginが活用できる 👉 新規コンポーネント導入の設計や検証作業が減らせる • 引き続きVFはKubernetesのリソースとしては認識されない 👉 VF枯渇起因のpod作成失敗は発生するが頻度は大幅減 構成その1の特長
11. 11 構成その2 (Cilium + SR-IOV CNI plugin) Multus kubelet Pod eth0 net1 Cilium SR-IOV CNI plugin 通常ネットワーク用 RDMA用 VFを付ける
12. 12 • VFがKubernetesが認識するリソースとして扱われる 👉 VFが不足しているノードにはpodがスケジュールされない 👉 VF枯渇によるpod作成失敗の問題が解消 構成その2の特長
13. 13 • Kubernetesクラスタ上でのRDMAの実現方法 ◦ SR-IOVを使っているか？ ◦ 別の方法で実現しているか？ • CNI pluginの構成 ◦ Multus (もしくは類似のmeta CNI plugin) を使っているか？ ◦ 通常ネットワーク用には何を使っているか？ ◦ RDMA用には何を使っているか？ 議論したいポイント その1
14. 14 • 構成その1と構成その2で前提とする環境に違いがある ◦ RDMA用の専用ネットワークがあるか ◦ IP Clos (Routing on the Host) vs. フラットなL2 ◦ IPアドレスの割り当て方法 👉 構成その1の環境にそのまま構成その2の実装を適用できない • 構成その2の中にも細かく様々な設計空間や制約があり、考えないとい けないことが多い 構成その2で課題は全て解消？ → No
15. 15 • VFのリソース設計 • Podに付けるVFの個数の設計 • NetworkAttachmentDefinitionの作成単位 • IPAM pluginの選択 • それぞれが独立なわけではなく相互に関連する場合がある • 各設計の中でもトレードオフがある Multus + SR-IOV CNI plugin構成の設計空間
16. 16 • SR-IOV Network Device pluginでVFをリソースとして広告できる ◦ リソースの例 → sriov_vf: 16 • どの単位でリソースとして広告するかを設定ファイルで定義 ◦ 親になるPF毎にリソースを分ける ▪ sriov_vf1: 4, sriov_vf2: 4, sriov_vf3: 4, sriov_vf4: 4 ◦ 親になるPFは関係なく1つのリソースとして扱う ▪ sriov_vf: 16 VFのリソース設計
17. 17 • 親になるPF毎にリソースを分ける場合 ◦ PodはどのPFを使うかを意識してリソースを要求する必要がある ◦ ノード毎にPF数が異なる場合にはユーザが使い分ける必要がある • 親になるPFは関係なく1つのリソースにする場合 ◦ PodはどのPFを使うか意識しないので抽象度が高い ◦ VFの割り当てはKubernetesのリソース割り当てロジックに依存 👉 ローカリティを意識した割り当てに制約が生じうる VFのリソース設計のトレードオフ
18. 18 • Podに付けるVFの個数を誰が決めるか？ • ユーザ ◦ 実装コストが低い（全てユーザ任せ） ◦ コアユーザは自分でチューニングできるので ◦ ライトユーザは適切な値を設定するのが難しい • システム ◦ 実装コストが高い（適切な割り当てロジックはなにか） ◦ UXが改善する一方、ユーザ側でのチューニングは難しくなる Podに付けるVFの個数
19. 19 • Multusを使う場合には NetworkAttachmentDefinition (net-attach-def) を介してSR-IOV CNI pluginの設定を指定する 1. Podの annotation で net-attach-def を指定 2. 指定された net-attach-def で定義された CNI config に基づいて CNI plugin が呼び出される ◦ IPAM plugin のパラメータも CNI config に内包されている 👉 CNI config の内容が異なると別の net-attach-def が必要 　 ノード毎に異なるとpodで指定するのが難しくなる NetworkAttachmentDefinitionの作成単位
20. 20 • SR-IOV CNI plugin を使う場合、 IPAM plugin を決めないといけない ◦ 通常の CNI plugin と違い IPAM plugin を内包していないため • ノード毎に IPAM plugin の設定が違うと都合が悪い ◦ ノード毎に net-attach-def が別になるため • オープンソースのIPAM pluginの選択肢が少ない ◦ 例 ▪ 参照実装に含まれるもの: dhcp, static, host-local ▪ 参照実装以外: Whereabouts, NVIDIA IPAM plugin ◦ 実用的に使えるものが少ない or ネットワーク構成の制約が強い IPAM pluginの選択
21. 21 • VFのリソース設計 👉 親になるPF毎にリソースを分ける • Podに付けるVFの個数 👉 常に4 (= ノードのPF数) で固定 ユーザに指定してもらう • net-attach-defの作成単位 👉 VFリソース毎に1つ (= 全体で4つ) • IPAM pluginの選択 👉 Whereabouts 背景 • 早く使えるようにするのを優先（作り込みや最適化は後に回す） • 各ノードに搭載するPF数が全て同じ構成 • 各ノードにはRDMA用にフラットなL2が4つ接続される構成 現時点での選択 (いろいろ妥協)
22. 22 • どのような前提や設計方針か？ • 各ポイントでどのような選択をするか？ ◦ VFのリソース設計 ◦ Podに付けるVFの個数 ◦ net-attach-defの作成単位 ◦ IPAM pluginの選択 ◦ その他 • (Optional) RDMAトラフィックのアイソレーションの方法 議論したいポイント その2