Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
機械学習クラスタ コンテナネットワーキング BoF
Search
Preferred Networks
PRO
July 03, 2024
Technology
1
310
機械学習クラスタ コンテナネットワーキング BoF
JANOG 54の機械学習クラスタ コンテナネットワーキング BoF (2024/7/5) での発表資料です。
Preferred Networks
PRO
July 03, 2024
Tweet
Share
More Decks by Preferred Networks
See All by Preferred Networks
DFTの実践的基礎理論
pfn
PRO
2
90
PFN Internship 2024 / Kai Kohyama: Blowin’ in the Wild: Dynamic Looping Gaussians from Still Images
pfn
PRO
0
40
自然言語処理を役立てるのはなぜ難しいのか
pfn
PRO
18
4.9k
Efficient Crystal Structure Prediction using Universal Neural Network Potential and Genetic Algorithm
pfn
PRO
1
28
Optuna: a Black-Box Optimization Framework
pfn
PRO
1
150
自社開発した大規模言語モデルをどうプロダクションに乗せて運用していくか〜インフラ編〜
pfn
PRO
28
8.4k
Extension API Server による Kubernetes API の拡張 / Kubernetes Meetup Tokyo #66
pfn
PRO
3
280
Preferred Networks会社概要
pfn
PRO
3
29k
生成AI向け機械学習クラスタ 構築のレシピ 北海道石狩編
pfn
PRO
6
2.4k
Other Decks in Technology
See All in Technology
「最高のチューニング」をしないために / hack@delta 24.10
fujiwara3
7
1.2k
サーバーサイドのデータプレーンプログラミング 〜 NVIDIA Blue Field / DOCA 〜
ebiken
PRO
1
220
Railway Oriented Programming を オニオンアーキテクチャに適用する by kotlin-result / Railway Oriented Programming in Onion Architecture by kotlin-result
yuitosato
2
190
実は仲良し?Amplify Gen2と生成AI
mkdev10
1
240
開発健全性の可視化と開発者体験の改善 ~ Compassでエンジニアに活力と生産性を ~
atlassianjapan
0
170
Trusted Types API と Vue.js
lycorptech_jp
PRO
1
260
次は君だ。~Japan AWS Jr. Champions 受賞までの奇跡~
fukuchiiinu
0
210
AIを使って小説を書こう!【2024/10/25講演資料】
kamomeashizawa
0
160
WebRTC と Wasm の関係を振り返ってみた
tetter27
0
230
品質の高い機能を”早く”提供するために技術的な面でチームでやったこと、やりたいこと
sansantech
PRO
2
220
Mackerelが取り組むオブザーバビリティ - Mackerel Tech Day
mackerelio
0
300
入門『状態』#kaigionrails / "state" for beginners with Rails
shinkufencer
2
750
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Statistics for Hackers
jakevdp
796
220k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Designing Experiences People Love
moore
138
23k
Ruby is Unlike a Banana
tanoku
96
11k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Six Lessons from altMBA
skipperchong
26
3.4k
Testing 201, or: Great Expectations
jmmastey
38
7k
How to train your dragon (web standard)
notwaldorf
88
5.6k
Being A Developer After 40
akosma
86
590k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Transcript
機械学習クラスタ コンテナネットワーキング BoF JANOG 54 (2024/7/5) Sho Shimizu, Preferred Networks,
Inc.
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 • Preferred Networksでは2019年以降、RoCEv2を使ったRDMAが利用 可能なAI/ML向けKubernetesクラスタを構築、運用している • これまでのクラスタの設計や運用での試行錯誤や知見はあるものの公開 されている事例が少ないので自社での設計との比較が難しい • AI/ML向けKubernetesクラスタを構築する時のデザイン空間はネット
ワークに限っても結構広い AI/ML向けKubernetesクラスタのネットワーク設計の議論がしたい はじめに (2/2)
4 • RDMAの実現方法とCNI pluginの構成 ◦ Preferred Networksでの事例 ◦ 議論 •
Multus + SR-IOV CNI pluginでの設計の詳細 ◦ デザイン空間の詳細 ◦ Preferred Networksでの事例 ◦ 議論 本日の流れ
5 RDMAの実現方法: SR-IOVを利用する方法 veth VF eth0 net1 PF VF VF
veth VF Pod Podのnetnsに移す NIC ホスト 通常ネットワーク RDMA用ネットワーク SR-IOVによる NICの仮想化
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 • 割当可能な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 RDMA対応の典型的CNI plugin構成 Multus kubelet Pod eth0 net1 CNI plugin
CNI plugin 通常ネットワーク用 インターコネクト用 2種類のCNI pluginにそれぞれ何を採用するかという問題 VFを付ける
9 構成その1 (Calico + 内製CNI plugin) Multus kubelet Pod eth0
net1 Calico 内製 CNI plugin 通常ネットワーク用 RDMA用 VFを付ける
10 • kube-proxyのパッチが不要 👉 kube-proxyのパッチ由来の問題が解決 • 内製CNI pluginが活用できる 👉 新規コンポーネント導入の設計や検証作業が減らせる
• 引き続きVFはKubernetesのリソースとしては認識されない 👉 VF枯渇起因のpod作成失敗は発生するが頻度は大幅減 構成その1の特長
11 構成その2 (Cilium + SR-IOV CNI plugin) Multus kubelet Pod
eth0 net1 Cilium SR-IOV CNI plugin 通常ネットワーク用 RDMA用 VFを付ける
12 • VFがKubernetesが認識するリソースとして扱われる 👉 VFが不足しているノードにはpodがスケジュールされない 👉 VF枯渇によるpod作成失敗の問題が解消 構成その2の特長
13 • Kubernetesクラスタ上でのRDMAの実現方法 ◦ SR-IOVを使っているか? ◦ 別の方法で実現しているか? • CNI pluginの構成
◦ Multus (もしくは類似のmeta CNI plugin) を使っているか? ◦ 通常ネットワーク用には何を使っているか? ◦ RDMA用には何を使っているか? 議論したいポイント その1
14 • 構成その1と構成その2で前提とする環境に違いがある ◦ RDMA用の専用ネットワークがあるか ◦ IP Clos (Routing on
the Host) vs. フラットなL2 ◦ IPアドレスの割り当て方法 👉 構成その1の環境にそのまま構成その2の実装を適用できない • 構成その2の中にも細かく様々な設計空間や制約があり、考えないとい けないことが多い 構成その2で課題は全て解消? → No
15 • VFのリソース設計 • Podに付けるVFの個数の設計 • NetworkAttachmentDefinitionの作成単位 • IPAM pluginの選択
• それぞれが独立なわけではなく相互に関連する場合がある • 各設計の中でもトレードオフがある Multus + SR-IOV CNI plugin構成の設計空間
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 • 親になるPF毎にリソースを分ける場合 ◦ PodはどのPFを使うかを意識してリソースを要求する必要がある ◦ ノード毎にPF数が異なる場合にはユーザが使い分ける必要がある • 親になるPFは関係なく1つのリソースにする場合 ◦
PodはどのPFを使うか意識しないので抽象度が高い ◦ VFの割り当てはKubernetesのリソース割り当てロジックに依存 👉 ローカリティを意識した割り当てに制約が生じうる VFのリソース設計のトレードオフ
18 • Podに付けるVFの個数を誰が決めるか? • ユーザ ◦ 実装コストが低い(全てユーザ任せ) ◦ コアユーザは自分でチューニングできるので ◦
ライトユーザは適切な値を設定するのが難しい • システム ◦ 実装コストが高い(適切な割り当てロジックはなにか) ◦ UXが改善する一方、ユーザ側でのチューニングは難しくなる Podに付けるVFの個数
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 • 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 • VFのリソース設計 👉 親になるPF毎にリソースを分ける • Podに付けるVFの個数 👉 常に4 (=
ノードのPF数) で固定 ユーザに指定してもらう • net-attach-defの作成単位 👉 VFリソース毎に1つ (= 全体で4つ) • IPAM pluginの選択 👉 Whereabouts 背景 • 早く使えるようにするのを優先(作り込みや最適化は後に回す) • 各ノードに搭載するPF数が全て同じ構成 • 各ノードにはRDMA用にフラットなL2が4つ接続される構成 現時点での選択 (いろいろ妥協)
22 • どのような前提や設計方針か? • 各ポイントでどのような選択をするか? ◦ VFのリソース設計 ◦ Podに付けるVFの個数 ◦
net-attach-defの作成単位 ◦ IPAM pluginの選択 ◦ その他 • (Optional) RDMAトラフィックのアイソレーションの方法 議論したいポイント その2