PFN の機械学習向け Kubernetes クラスタ におけるノード障害の運用自動化・省力化

Transcript

1. PFN の機械学習向け Kubernetes クラスタ におけるノード障害の運用自動化・省力化 Private Cloud Meetup #5 (2023/11/2) Sho Shimizu, Preferred Networks, Inc. @oshothebig
2. 2 自己紹介 : 清水 翔 (Sho Shimizu / @oshothebig) • 2010 ~ 2019 株式会社富士通研究所 ◦ Software Defined Networking (SDN) • 2019 ~ 現在 株式会社Preferred Networks ◦ Cluster Servicesチーム • オンプレのKubernetesクラスタの開発 & 運用 ◦ コンテナネットワーキング ▪ 内製CNI pluginの開発 ▪ CNI pluginの構成変更
3. 3 • PFNのクラスタ構成 • クラスタで発生するノード障害 • ノード障害への対応方法 Agenda
4. 4 3つのオンプレミス計算機クラスタ 2022~ MN-2a MN-3 MN-2b 2020~ 2019~
5. 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. 6 クラスタは常にどこかが壊れている 分散システムは、完全な意味で「アップ（up）」になることはない。* • 障害の発生しうる要素 ◦ ハードウェア ▪ CPU, GPU, Memory, Disk, Network (NIC, Cable, ...), FAN, 電源,… ◦ ソフトウェア ▪ OS, ドライバ, システムプロセス (k8s 含む), Pod (ユーザーのワー クロード) , … • 各要素で障害となりうる故障・不具合の種類も複数存在 • クラスタの規模に比例して、どこかが壊れているのが定常的な状態 * Ops: It's everyone's job now | Opensource.com
7. 様々なノード障害
8. GPUの障害 • GPUメモリのエラー ◦ Single/Double Bit ECC Error → Page retirement • 認識しない ◦ Kubernetesのリソースとして ◦ PCIeデバイスとして • 認識はしているがビジー状態で利用不可 ◦ ワークロードを実行するまで分からない
9. ネットワークの障害 • リンクダウン/フラップ • インターフェイスを認識しない • ソフトウェア要因 ◦ ドライバ • ハードウェア要因 ◦ AOC (Active Optical Cable) ◦ 光トランシーバ ◦ NIC ◦ PCI Express
10. その他の障害 • Terminatingのまま削除できないpod ◦ プロセスがD state (Uninterruptible sleep) のまま返ってこない ◦ リソースが解放されたと見なされず無駄が生じる ◦ SIGKILLが効かずノードを再起動するしかない • PCI Expressのリンク速度の低下 ◦ ノードの再起動が必要
11. 運用自動化・省力化の取り組み
12. 12 監視と自動修復 Servers icon by https://icons8.com 自己診断 修復処理 監視 Issue 作成 通知 調査・修復処理 監視 システム node-operation-controller alertmanager-to-github
13. Node Conditionを活用したノード障害検知 • Node Condition ◦ ノードの状態を表すKubernetes上の概念 ◦ デフォルトのタイプに加えて、独自のタイプを定義可能 → 既知のノード障害に対して独自のNode Conditionを定義 • 独自のNode Conditionの例 ◦ GPUIsLost ◦ GPUPendingPage ◦ DStateProcess ◦ PCIeLinkDegraded
14. 障害検知 → Node Conditionの設定方法 • Node Problem Detector (OSS) https://github.com/kubernetes/node-problem-detector ◦ 問題を見つけるとNode Conditionを設定出来る ◦ カスタムプラグインを自社開発 • kube-nvidia-active-monitor (自社開発) ◦ ワークロードを実行してはじめて分かるGPUの問題を検知 ◦ GPUを使う簡単なワークロードを定期実行 ◦ 問題を見つけると GPURuntimeError を設定
15. 自動復旧: node-operation-controller https://github.com/pfnet-research/node-operation-controller • 設定されたNode Conditionに対して任意のオペレーションを実行する Kubernetesコントローラ • 復旧処理が既知である場合の自動復旧を担当 • 復旧処理 ◦ ノードの再起動 ◦ NFSの再マウント
16. 16 監視と自動修復 Servers icon by https://icons8.com 自己診断 修復処理 監視 Issue 作成 通知 調査・修復処理 監視 システム node-operation-controller alertmanager-to-github
17. マニュアル対応: alertmanager-to-github https://github.com/pfnet-research/alertmanager-to-github • Alertmanager からの Webhook を受け取って GitHub イシューを作成 ◦ 新しいアラートから GitHub イシューを作成 ◦ アラートが resolved ステータスになるとイシューをクローズ ◦ アラートが再度 firing ステータスになるとイシューをリオープン • Node Condition も Prometheus でメトリクスとして収集 ◦ アラートとして一元化して扱うことができる • GitHub イシューの assignee は自動で設定 • GitHub イシューには過去の対応履歴が残る → 将来の自動化の参考
18. まとめ • 機械学習向けクラスタでは多数のアクセラレータがあり、様々な要因 でノード障害が発生する • 運用負荷の削減 ◦ 自動復旧 ◦ チケットの自動起票 • OSSの利用と内製ツールの開発の両輪
19. 19 • Preferred Networksの計算基盤関連チームでは採用を実施中です！ ◦ 機械学習プラットフォームエンジニア (クラスタのサービス化) ◦ ストレージエンジニア (ストレージの企画設計管理運用) ◦ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理) • カジュアル面談もやってます → We're Hiring !!