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
380
機械学習クラスタ コンテナネットワーキング 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
EDRからERM: PFN-SIRTが関わるセキュリティとリスクへの取り組み
pfn
PRO
0
100
GPU NW BoF / JANOG 55
pfn
PRO
1
52
深層学習と3Dキャプチャ・3Dモデル生成(土木学会応用力学委員会 応用数理・AIセミナー)
pfn
PRO
0
490
KubeCon NA 2024 Recap: Distributed Cache Empowers AI/ML Workloads on Kubernetes Cluster / Kubernetes Meetup Tokyo #68
pfn
PRO
1
57
PLaMo-100B-Instruct 国産大規模言語モデル構築における事後学習の取り組み
pfn
PRO
4
510
新卒エンジニアが DEEP DIVE するMN-Core™
pfn
PRO
0
120
LinuxとMN-Coreコンパイラランタイムにおけるプログラムの起動プロセスとその比較
pfn
PRO
2
730
KubeCon NA 2024 Recap: Managing and Distributing AI Models Using OCI Standards and Harbor / Kubernetes Meetup Tokyo #68
pfn
PRO
0
290
実践/先取り「入門 Kubernetes Validating/Mutating Admission Policy」 / CloudNative Days Winter 2024
pfn
PRO
1
310
Other Decks in Technology
See All in Technology
Japan AWS Jr. Championsがお届けするre:Invent2024のハイライト ~ラスベガスで見てきた景色~
fukuchiiinu
0
1.1k
Enhancing SRE Using AI
yoshiiryo1
1
260
Windows Server 2025 へのアップグレードではまった話
tamaiyutaro
2
260
Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは
mshibuya
2
4k
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
150
プロダクト価値を引き上げる、「課題の再定義」という習慣
moeka__c
0
200
日本語プログラミングとSpring Bootアプリケーション開発 #kanjava
yusuke
2
340
サービスローンチを成功させろ! 〜SREが教える30日間の攻略ガイド〜
mmmatsuda
2
4.4k
20250125_Agent for Amazon Bedrock試してみた
riz3f7
2
110
現実的なCompose化戦略 ~既存リスト画面の置き換え~
sansantech
PRO
0
160
ChatGPTを使ったブログ執筆と校正の実践テクニック/登壇資料(井田 献一朗)
hacobu
1
160
ココナラのセキュリティ組織の体制・役割・今後目指す世界
coconala_engineer
0
220
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
It's Worth the Effort
3n
184
28k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Six Lessons from altMBA
skipperchong
27
3.6k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Documentation Writing (for coders)
carmenintech
67
4.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.2k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
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