Triển khai Prometheus và Grafana để giám sát GPU và mạng
Cấu hình Prometheus để thu thập metrics GPU và Ray
Chúng ta cần triển khai Prometheus để thu thập dữ liệu từ Ray Dashboard và các GPU thông qua exporter. Sử dụng Prometheus Operator hoặc Helm chart là cách chuẩn nhất trên Kubernetes.
Tạo file values.yaml để cấu hình Helm chart Prometheus, bao gồm việc thu thập metrics từ namespace ray và các node có GPU.
cat > /opt/k8s-monitoring/prometheus-values.yaml
Kết quả mong đợi: File cấu hình đã được tạo sẵn sàng để deploy bằng lệnh helm install prometheus prometheus-community/kube-prometheus-stack -f /opt/k8s-monitoring/prometheus-values.yaml.
Triển khai NVIDIA DCGM Exporter để giám sát GPU
Để Prometheus đọc được thông số GPU (nhiệt độ, usage, memory), ta cần deploy DCGM Exporter. Đây là bước bắt buộc nếu chưa làm ở phần trước.
Tạo manifest YAML để deploy DCGM Exporter dưới dạng DaemonSet, đảm bảo nó chạy trên tất cả các node có GPU.
cat > /opt/k8s-monitoring/dcgm-exporter.yaml
Chạy lệnh kubectl apply -f /opt/k8s-monitoring/dcgm-exporter.yaml.
Kết quả mong đợi: Pod nvidia-dcgm-exporter chạy trên mọi node có GPU, trạng thái Running.
Cấu hình Grafana với dashboard AI Training
Deploy Grafana để trực quan hóa dữ liệu từ Prometheus. Cần import dashboard cụ thể cho Ray và NVIDIA GPU.
Sử dụng Helm chart Grafana và cấu hình datasource cùng dashboard ID tự động.
cat > /opt/k8s-monitoring/grafana-values.yaml
Triển khai bằng lệnh: helm install grafana grafana/grafana -f /opt/k8s-monitoring/grafana-values.yaml.
Kết quả mong đợi: Grafana truy cập được qua IP LoadBalancer, dashboard Ray và GPU hiện lên với dữ liệu realtime.
Verify kết quả giám sát
Truy cập Grafana qua trình duyệt, chọn dashboard "NVIDIA GPU Monitoring".
Thực hiện một job training nhỏ, quan sát biểu đồ GPU Utilization và Memory Used tăng lên.
Trong Prometheus UI (port 9090), query: dcgm_gpu_utilization để xác nhận metrics được thu thập.
Xử lý các lỗi thường gặp: OOM và lỗi kết nối mạng
Phân tích và xử lý lỗi OOM (Out of Memory) trên GPU
Lỗi OOM xảy ra khi batch size quá lớn hoặc model quá nặng so với VRAM. Cần cấu hình Ray để tự động restart hoặc giảm resource.
Chỉnh sửa Ray Job Submission để thêm logic catch exception OOM và giảm batch size động.
cat > /opt/training-scripts/train_with_oom_handling.py
Đảm bảo file ds_config.json đã được cấu hình với zero_offload để offload tham số ra RAM khi cần.
Kết quả mong đợi: Script tự động giảm batch size khi gặp OOM và tiếp tục training mà không crash hoàn toàn.
Chẩn đoán lỗi kết nối mạng giữa các Node (Network Partition)
Trong training phân tán, lỗi mạng giữa các node Ray gây ra ConnectionError hoặc Timeout. Cần kiểm tra CNI (Calico/Flannel) và firewall.
Sử dụng lệnh ray job status và xem log của worker để xác định node nào bị mất kết nối.
ray job status --address=http://ray-head:8265
Để debug sâu hơn, truy cập vào pod worker và ping head node.
kubectl exec -it ray-worker-default-0 -- bash
ping ray-head.ray.svc.cluster.local
ip route
Đảm bảo rằng CNI cho phép traffic giữa các namespace và ports cần thiết (6379, 8000, 8265).
Cấu hình lại Ray để tăng timeout nếu mạng chập chờn nhưng không bị ngắt.
cat > /opt/ray-config/ray-cluster-advanced.yaml
Chạy kubectl apply -f /opt/ray-config/ray-cluster-advanced.yaml.
Kết quả mong đợi: Ray cluster chịu được các jitter mạng nhỏ mà không bị kill worker ngay lập tức.
Verify kết quả xử lý lỗi
Giả lập OOM bằng cách chạy script với batch size rất lớn trên GPU nhỏ.
Quan sát log trong kubectl logs thấy thông báo OOM Detected và quá trình tự động retry với batch size nhỏ hơn.
Cắt mạng giữa hai node bằng kubectl run --rm -it --restart=Never --image=busybox --network=host -- bash và dùng iptables chặn port, sau đó kiểm tra Ray cluster có tự recovery không.
Tips nâng cao về bảo mật và tự động hóa recovery
Bảo mật Ray Cluster với NetworkPolicies
Ngăn chặn truy cập trái phép vào Ray Dashboard và Ray GCS từ bên ngoài cluster.
Tạo NetworkPolicy chỉ cho phép traffic từ Ingress hoặc Pod cụ thể đến Ray Head.
cat > /opt/security/ray-networkpolicy.yaml
Chạy kubectl apply -f /opt/security/ray-networkpolicy.yaml.
Kết quả mong đợi: Chỉ các pod trong cluster (monitoring, worker) mới truy cập được Ray Head, bên ngoài bị chặn.
Tự động hóa Recovery khi Node bị lỗi (Pod Disruption Budget & Liveness Probe)
Cấu hình Liveness Probe để Kubernetes tự động kill và restart pod nếu Ray worker bị treo (hang).
Sử dụng Ray Health Check endpoint để kiểm tra trạng thái worker.
cat > /opt/recovery/ray-worker-liveness.yaml
Chú ý: Ray worker mặc định không expose port 8080, cần cấu hình --metrics-export-port 8080 trong rayStartParams hoặc dùng sidecar container để expose health check.
Cấu hình PodDisruptionBudget (PDB) để đảm bảo ít nhất 1 worker luôn chạy khi có sự cố maintenance.
cat > /opt/recovery/pdb.yaml
Chạy kubectl apply -f /opt/recovery/pdb.yaml.
Kết quả mong đợi: Nếu worker bị treo, Kubernetes sẽ kill và tạo mới pod. Khi node bị down, PDB đảm bảo cluster không mất hoàn toàn worker.
Verify kết quả bảo mật và recovery
Thử truy cập Ray Dashboard từ pod không nằm trong whitelist, kết quả phải là Connection refused.
Giả lập worker bị treo bằng cách kill tiến trình raylet bên trong container, quan sát Kubernetes tự động restart container.
Thử scale down node có worker, đảm bảo PDB không cho phép tất cả worker bị evict cùng lúc.
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng AI Training phân tán với DeepSpeed, Ray và Kubernetes trên hạ tầng Proxmox
« Phần 6: Tối ưu hóa hiệu năng và cân bằng tải cho training