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
390
機械学習クラスタ コンテナネットワーキング 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
190
GPU NW BoF / JANOG 55
pfn
PRO
1
71
深層学習と3Dキャプチャ・3Dモデル生成(土木学会応用力学委員会 応用数理・AIセミナー)
pfn
PRO
0
540
KubeCon NA 2024 Recap: Distributed Cache Empowers AI/ML Workloads on Kubernetes Cluster / Kubernetes Meetup Tokyo #68
pfn
PRO
1
69
PLaMo-100B-Instruct 国産大規模言語モデル構築における事後学習の取り組み
pfn
PRO
4
600
新卒エンジニアが DEEP DIVE するMN-Core™
pfn
PRO
0
130
LinuxとMN-Coreコンパイラランタイムにおけるプログラムの起動プロセスとその比較
pfn
PRO
2
750
KubeCon NA 2024 Recap: Managing and Distributing AI Models Using OCI Standards and Harbor / Kubernetes Meetup Tokyo #68
pfn
PRO
0
310
実践/先取り「入門 Kubernetes Validating/Mutating Admission Policy」 / CloudNative Days Winter 2024
pfn
PRO
1
340
Other Decks in Technology
See All in Technology
分解して理解する Aspire
nenonaninu
1
350
運用しているアプリケーションのDBのリプレイスをやってみた
miura55
1
770
Windows の新しい管理者保護モード
murachiakira
0
110
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.4k
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
620
2.5Dモデルのすべて
yu4u
2
900
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
470
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
390
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
2.1k
Tech Blogを書きやすい環境づくり
lycorptech_jp
PRO
1
250
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
150
Active Directory攻防
cryptopeg
PRO
2
920
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
35
1.6k
Fireside Chat
paigeccino
34
3.2k
Building an army of robots
kneath
303
45k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
How to Ace a Technical Interview
jacobian
276
23k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
550
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
51k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
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