PFN の機械学習向け Kubernetes クラスタ におけるノード障害の運用自動化・省力化 Private Cloud Meetup #5 (2023/11/2) Sho Shimizu, Preferred Networks, Inc. @oshothebig

2 自己紹介 : 清水 翔 (Sho Shimizu / @oshothebig) ● 2010 ~ 2019 株式会社富士通研究所 ○ Software Defined Networking (SDN) ● 2019 ~ 現在 株式会社Preferred Networks ○ Cluster Servicesチーム ● オンプレのKubernetesクラスタの開発 & 運用 ○ コンテナネットワーキング ■ 内製CNI pluginの開発 ■ CNI pluginの構成変更

3 ● PFNのクラスタ構成 ● クラスタで発生するノード障害 ● ノード障害への対応方法 Agenda

4 3つのオンプレミス計算機クラスタ 2022~ MN-2a MN-3 MN-2b 2020~ 2019~

5 各クラスタの構成 36 cores 384 GB V100 x 8 100 GbE x 4 128 nodes MN-2a 48 cores 384 GB MN-Core x 4 100 GbE x 4 48 nodes MN-3 128 cores 1,024 GB A100 x 4 100 GbE x 2 42 nodes MN-2b 80 cores 512 GB A30 x 6 100 GbE x 2 42 nodes Icons by https://icons8.com ユーザからは単一のKubernetesクラスタとして利用可能 合計 260 nodes, 1,444 GPU + 192 MN-Core

6 クラスタは常にどこかが壊れている 分散システムは、完全な意味で「アップ（up）」になることはない。* ● 障害の発生しうる要素 ○ ハードウェア ■ CPU, GPU, Memory, Disk, Network (NIC, Cable, ...), FAN, 電源,… ○ ソフトウェア ■ OS, ドライバ, システムプロセス (k8s 含む), Pod (ユーザーのワー クロード) , … ● 各要素で障害となりうる故障・不具合の種類も複数存在 ● クラスタの規模に比例して、どこかが壊れているのが定常的な状態 * Ops: It's everyone's job now | Opensource.com

様々なノード障害

GPUの障害 ● GPUメモリのエラー ○ Single/Double Bit ECC Error → Page retirement ● 認識しない ○ Kubernetesのリソースとして ○ PCIeデバイスとして ● 認識はしているがビジー状態で利用不可 ○ ワークロードを実行するまで分からない

ネットワークの障害 ● リンクダウン/フラップ ● インターフェイスを認識しない ● ソフトウェア要因 ○ ドライバ ● ハードウェア要因 ○ AOC (Active Optical Cable) ○ 光トランシーバ ○ NIC ○ PCI Express

その他の障害 ● Terminatingのまま削除できないpod ○ プロセスがD state (Uninterruptible sleep) のまま返ってこない ○ リソースが解放されたと見なされず無駄が生じる ○ SIGKILLが効かずノードを再起動するしかない ● PCI Expressのリンク速度の低下 ○ ノードの再起動が必要

運用自動化・省力化の取り組み

12 監視と自動修復 Servers icon by https://icons8.com 自己診断 修復処理 監視 Issue 作成 通知 調査・修復処理 監視 システム node-operation-controller alertmanager-to-github

Node Conditionを活用したノード障害検知 ● Node Condition ○ ノードの状態を表すKubernetes上の概念 ○ デフォルトのタイプに加えて、独自のタイプを定義可能 → 既知のノード障害に対して独自のNode Conditionを定義 ● 独自のNode Conditionの例 ○ GPUIsLost ○ GPUPendingPage ○ DStateProcess ○ PCIeLinkDegraded

障害検知 → Node Conditionの設定方法 ● Node Problem Detector (OSS) https://github.com/kubernetes/node-problem-detector ○ 問題を見つけるとNode Conditionを設定出来る ○ カスタムプラグインを自社開発 ● kube-nvidia-active-monitor (自社開発) ○ ワークロードを実行してはじめて分かるGPUの問題を検知 ○ GPUを使う簡単なワークロードを定期実行 ○ 問題を見つけると GPURuntimeError を設定

自動復旧: node-operation-controller https://github.com/pfnet-research/node-operation-controller ● 設定されたNode Conditionに対して任意のオペレーションを実行する Kubernetesコントローラ ● 復旧処理が既知である場合の自動復旧を担当 ● 復旧処理 ○ ノードの再起動 ○ NFSの再マウント

16 監視と自動修復 Servers icon by https://icons8.com 自己診断 修復処理 監視 Issue 作成 通知 調査・修復処理 監視 システム node-operation-controller alertmanager-to-github

マニュアル対応: alertmanager-to-github https://github.com/pfnet-research/alertmanager-to-github ● Alertmanager からの Webhook を受け取って GitHub イシューを作成 ○ 新しいアラートから GitHub イシューを作成 ○ アラートが resolved ステータスになるとイシューをクローズ ○ アラートが再度 firing ステータスになるとイシューをリオープン ● Node Condition も Prometheus でメトリクスとして収集 ○ アラートとして一元化して扱うことができる ● GitHub イシューの assignee は自動で設定 ● GitHub イシューには過去の対応履歴が残る → 将来の自動化の参考

まとめ ● 機械学習向けクラスタでは多数のアクセラレータがあり、様々な要因 でノード障害が発生する ● 運用負荷の削減 ○ 自動復旧 ○ チケットの自動起票 ● OSSの利用と内製ツールの開発の両輪

19 ● Preferred Networksの計算基盤関連チームでは採用を実施中です！ ○ 機械学習プラットフォームエンジニア (クラスタのサービス化) ○ ストレージエンジニア (ストレージの企画設計管理運用) ○ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理) ● カジュアル面談もやってます → We're Hiring !!