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
160
機械学習クラスタ コンテナネットワーキング 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
Preferred Networks会社概要
pfn
PRO
3
2.8k
生成AI向け機械学習クラスタ 構築のレシピ 北海道石狩編
pfn
PRO
5
1.3k
三次元再構成(東京大学大学院 情報理工学系研究科『知能情報論』)
pfn
PRO
10
2.3k
Developing image pull secrets provisioner / Kubernetes Meetup Tokyo #65
pfn
PRO
3
360
マルチテナントマルチクラスタKubernetesでもUXを損なわない認証認可の勘所
pfn
PRO
2
350
大規模言語モデル (LLM)における低精度数値表現
pfn
PRO
4
1.2k
個人的、Kubernetes の最新注目機能! (2024年5月版) / TechFeed Experts Night#28 〜 コンテナ技術最前線
pfn
PRO
3
310
LLMの現在
pfn
PRO
190
87k
実際に運用してわかった! 多種GPU混載Kubernetesクラスタの使われ方と運用省力化
pfn
PRO
0
200
Other Decks in Technology
See All in Technology
現場の失敗から学ぶ!プロダクトバックログアイテムの改善/Learn_from_On-Site_Failures!_Improving_Product_Backlog_Items
m_iyama
3
950
[ABC2024Summer]Flutter UX Improvements + α
korodroid
0
330
Productivity-Conference-GitHub-20240629
yuhattor
2
2.4k
RDS for Db2 はじめの一歩・作り方編 #1 /20240628-RDSforDb2-dojo
mayumihirano
0
220
ベイジアンABテストってありなの? / Is Bayesian AB Testing Truly Effective?
ak_iyama
1
530
国連も推進する、デジタル公共財とは何か
halsk
1
480
はてなのチーム開発一巡り / Hatena Engineer Seminar 30
daiksy
0
330
Bring your app’s core features to users with App Intents とか App Intents 関連の要約
ryomm
1
280
運用者の各領域で向き合うLLM
nwiizo
1
290
ポストモーテム読書会のすすめ
taxin
0
410
プラットフォーム開発の実例と撤退から学ぶ / Learning from examples of platform development and withdrawal
kaminashi
5
690
健常者から見たAndroidのアクセシビリティ機能
takamichie
PRO
0
270
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
10
3.7k
Optimizing for Happiness
mojombo
372
69k
The Language of Interfaces
destraynor
151
23k
The Pragmatic Product Professional
lauravandoore
28
6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
247
20k
Six Lessons from altMBA
skipperchong
22
3.2k
It's Worth the Effort
3n
180
27k
In The Pink: A Labor of Love
frogandcode
139
22k
Why Our Code Smells
bkeepers
PRO
331
56k
StorybookのUI Testing Handbookを読んだ
zakiyama
14
4.8k
Documentation Writing (for coders)
carmenintech
62
4.1k
Mobile First: as difficult as doing things right
swwweet
218
8.7k
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