引言
隨著AI工作負載的快速成長，GPU集群成為推動機器學習與深度學習應用的核心基礎設施。然而，面對高密度GPU節點與複雜的資源管理需求，如何確保系統的穩定性、可觀測性與自動化恢復能力，成為關鍵挑戰。本文探討Bella與Bella 2集群的架構設計，並分析其在故障檢測、資源優化與自動化恢復方面的技術實踐，為大規模GPU集群管理提供參考。
主要內容
技術與架構概述
GPU集群管理的核心目標在於確保AI工作負載的高可用性與資源利用率。Bella與Bella 2集群透過硬體與軟體的協同設計，實現對GPU、網路與儲存的精細控制。其軟體架構基於CNCF生態系，整合Red Hat OpenShift、MLB Batch與Q系統，並透過AppWrapper實現工作負載的強化與容錯機制。
硬體架構
- Bella集群：部署於IBM Cloud，每節點配備8塊NVIDIA 800系列GPU，透過MVLink與MV Switch實現800 Gbps網路帶寬，儲存容量達3.2 TB NVMe。
- Bella 2集群：升級至NVIDIA H100 GPU，網路帶寬提升至3.2 TB/s，儲存容量為Bella的兩倍，支援訓練與推理雙模式工作負載。
軟體架構
- Red Hat OpenShift：作為底層容器編排平臺，配合Multus CNI實現多網路接口管理。
- MLB Batch：專為Kubernetes設計的批次AI工作負載管理工具，支援多租戶資源配額與優先順序。
- Q系統：原生隊列管理系統，包含Cluster Queue（配額分配）與Slack Cluster Queue（動態緩衝容量），支援跨隊列配額借用機制。
- AppWrapper：整合計算、服務、憑證與入口資源，提供工作負載的自動清理、重試策略與故障回復流程。
故障檢測與恢復機制
故障源與處理流程
根據Meta白皮書與NVIDIA技術報告，GPU故障佔訓練中斷的60%，且四個月內工作負載失敗原因包含硬體與軟體問題。為應對此挑戰，系統採用以下技術：
- Autopilot工具：自動執行健康檢查，監控GPU、網路與儲存狀態，並透過Prometheus導出指標，標籤節點狀態供其他工具使用。
- AppWrapper生命週期管理：
- 准入（Admitted）：分配配額並創建資源。
- 恢復（Resuming）：資源排程與初始化。
- 運行（Running）：工作負載執行。
- 重置（Reset）：檢測節點標籤後移除資源並重新執行。
- Slack Cluster Queue動態調整：根據節點健康狀態（Autopilot標籤）自動調整可用容量，支援系統維護作業。
故障回復與自動化
- Pod健康監控：AppWrapper控制器監控Pod狀態，若基礎控制器無法恢復，啟動重試流程。
- 自動排程：Autopilot標記異常節點後，注入親和性（Affinity）至Pod，避免新工作負載分配至不健康節點。
- 資源清理與重試策略：集群管理員可配置預設重試次數與等待時間，用戶透過Annotations覆寫。
資源管理與優化策略
動態配額與工作負載分級
- Q系統配額調整：根據節點健康狀態動態管理Slack Cluster Queue容量。
- 工作負載分級：依GPU數量（1~數百塊）與類型（訓練、微調、模型服務）分配資源，確保公平使用。
- 資源利用率優化：MLB Batch避免GPU閒置，提升整體效能。
異常處理機制
- 異常類型：Pod失敗、資源不足、鏡像拉取問題、排程錯誤等。
- 自動化處理：AppWrapper控制器監控異常並觸發清理與重試流程。
技術優勢與挑戰
優勢
- 高可用性：透過Autopilot與AppWrapper實現自動化故障檢測與恢復。
- 可觀測性：整合Prometheus、DCGM Exporter與Grafana，實現GPU與節點狀態的即時監控。
- 資源效率：動態配額與工作負載分級策略提升GPU利用率。
挑戰
- 複雜性：多層次架構需精細協調，增加系統維護成本。
- 異常處理：需平衡自動恢復與人工幹預，避免資源浪費。
總結
大規模GPU集群管理需結合故障檢測、自動化恢復與資源優化技術。Bella與Bella 2集群透過CNCF生態系的整合，實現高可用性與資源利用率。關鍵技術包括AppWrapper的強化機制、Q系統的動態配額管理，以及Autopilot的自動健康檢查。未來，進一步提升可觀測性與異常處理的靈活性，將是推動AI工作負載穩定執行的核心方向。