NVIDIA Mission Control 2.5 mở rộng tự phục hồi cho Kubernetes
NVIDIA Mission Control 2.5 mở rộng autonomous recovery sang workload Kubernetes do NVIDIA Run:ai quản lý. Hệ thống phối hợp scheduler, phục hồi job và phục hồi phần cứng để retry, reschedule hoặc cô lập node theo ngữ cảnh lỗi.
Một job huấn luyện phân tán có thể đang chạy bình thường thì gặp lỗi ECC trên GPU, worker treo hoặc timeout giao tiếp giữa các node. Với cụm GPU on-prem, đây không chỉ là lỗi của một pod: nếu node nghi vấn vẫn tiếp tục nhận workload mới, sự cố có thể lặp lại trên các job khác.
NVIDIA Mission Control 2.5 mở rộng autonomous recovery engine sang workload Kubernetes được quản lý bằng NVIDIA Run:ai. Ý tưởng cốt lõi là tách hai việc có thể diễn ra song song: khôi phục workload và cô lập, chẩn đoán hạ tầng có vấn đề.
Thay vì chờ hoàn tất phân tích nguyên nhân gốc rồi mới xử lý job, hệ thống hướng tới việc đưa workload trở lại trạng thái chạy trên năng lực phù hợp, đồng thời đưa node rủi ro ra khỏi luồng scheduling.
Ba lớp trong vòng điều khiển phục hồi
Theo NVIDIA, autonomous recovery engine gồm hai dịch vụ: autonomous job recovery và autonomous hardware recovery. Kết hợp cùng Kubernetes scheduler, chúng tạo thành mô hình ba lớp.
| Lớp | Vai trò |
|---|---|
| NVIDIA Run:ai scheduler | Quản lý workload, hàng đợi, policy và đặt job lên năng lực sẵn có |
| Autonomous job recovery | Theo dõi job, vị trí chạy, lịch sử lỗi và topology để xác định hướng khôi phục |
| Autonomous hardware recovery | Giám sát node/GPU, cô lập tài nguyên bất thường và thực hiện chẩn đoán hoặc khắc phục |
Trong mô hình này, scheduler chịu trách nhiệm đặt workload; job recovery tập trung vào ngữ cảnh của workload; còn hardware recovery tập trung vào sức khỏe hạ tầng.
Sự tách biệt này giúp scheduler có thể hướng workload đến năng lực sẵn sàng mà không cần chờ chẩn đoán nguyên nhân gốc hoàn tất. Đồng thời, dịch vụ phục hồi job không phải tự xử lý phần cứng, còn dịch vụ phần cứng không cần hiểu chi tiết mọi framework huấn luyện.
Ba kịch bản phục hồi NVIDIA mô tả
1. Lỗi phần cứng khi job đang training
Một GPU có thể bắt đầu lỗi với dấu hiệu như ECC error, worker bị treo hoặc timeout giao tiếp trong job. Khi đó, Mission Control xử lý theo hai nhánh.
Autonomous job recovery ghi nhận ngữ cảnh job và xác định node hoặc GPU nghi vấn.
Tích hợp với scheduler Kubernetes tiếp tục quá trình khôi phục bằng restart hoặc reschedule workload.
Autonomous hardware recovery đồng thời cô lập node có vấn đề, lưu lý do và khởi chạy chẩn đoán.
Nhờ vậy, workload không nhất thiết phải chờ quá trình điều tra phần cứng hoàn tất mới có thể tiếp tục. Trong khi đó, node nghi vấn không được đưa trở lại cho job kế tiếp trước khi được xử lý.
2. Lỗi phần mềm tạm thời
Không phải mọi worker exit hoặc timeout đều chứng tỏ GPU hay node đã hỏng. NVIDIA nêu ví dụ về worker gặp lỗi có thể phục hồi, timeout tạm thời hoặc mất phối hợp trong thời gian ngắn dù node nền vẫn khỏe.
Nếu lịch sử và ngữ cảnh lỗi cho thấy đây là lỗi tạm thời, autonomous job recovery có thể retry workload theo policy của scheduler thay vì lập tức cô lập phần cứng.
Autonomous hardware recovery vẫn tiếp tục giám sát, nhưng không cần tham gia vào luồng khắc phục nếu chưa xuất hiện thêm bằng chứng về lỗi hạ tầng. Cách xử lý này tránh việc rút tài nguyên khỏe khỏi scheduling pool chỉ vì một lỗi phần mềm có thể retry.
3. Phát hiện suy giảm trước khi job bị ảnh hưởng
Hardware recovery không chỉ phản ứng sau khi job thất bại. Theo NVIDIA, dịch vụ này cũng có thể phát hiện dấu hiệu suy giảm như cảnh báo sức khỏe GPU lặp lại, vấn đề kết nối hoặc các tín hiệu khiến node trở nên rủi ro cho scheduling.
Trong trường hợp đó, node có thể bị rút khỏi danh sách tài nguyên đủ điều kiện scheduling trước khi một job training mới được đặt vào. Job recovery có thể không cần tham gia, vì năng lực rủi ro đã được loại khỏi vòng cấp phát từ sớm.
Điều đội vận hành Kubernetes/GPU nên kiểm tra
Mission Control 2.5 mở rộng autonomous recovery engine vốn hỗ trợ workload HPC dùng Slurm sang workload Kubernetes do NVIDIA Run:ai quản lý. Tuy nhiên, bài viết giới thiệu không nêu câu lệnh cài đặt, cấu hình mẫu, yêu cầu phiên bản Kubernetes, sizing hay các ngưỡng năng lực dự phòng.
Vì vậy, khi đánh giá triển khai, đội hạ tầng nên tập trung vào các câu hỏi vận hành sau.
Scheduler hiện tại là gì?
NVIDIA mô tả NVIDIA Run:ai là Kubernetes default scheduler đi kèm Mission Control. Bài viết không làm rõ cách tích hợp với scheduler khác.
Những failure signal nào đang được giám sát?
Có thể đối chiếu các tín hiệu được NVIDIA nêu: ECC error, worker treo, timeout giao tiếp, cảnh báo sức khỏe GPU và vấn đề kết nối.
Retry, restart, reschedule và cô lập node sẽ được phân định ra sao?
Lỗi phần mềm có thể phục hồi nên đi theo nhánh retry phù hợp policy. Khi có dấu hiệu phần cứng, workload cần có đường khôi phục, trong khi node nghi vấn cần được loại khỏi scheduling để chẩn đoán.
Cụm còn đủ capacity để reschedule hay không?
Reschedule chỉ hiệu quả nếu còn năng lực phù hợp cho workload. Đây đặc biệt là điểm cần xem xét với job phân tán nhiều node.
Có thể diễn tập các luồng sự cố không?
Một kịch bản kiểm tra có thể bắt đầu bằng lỗi GPU trong lúc job chạy: xác nhận workload có được restart hoặc reschedule, node nghi vấn có bị rút khỏi scheduling, và chẩn đoán có được khởi chạy hay không.
Những điểm bài viết chưa nêu chi tiết
NVIDIA cho biết hardware recovery có thể cô lập node, ghi nhận lý do và chạy chẩn đoán. Tuy nhiên, bài giới thiệu không nêu vị trí xuất log, thời gian lưu giữ, định dạng audit hay cách tích hợp với hệ thống logging hiện có.
Nội dung này cũng chưa cung cấp chi tiết về cổng mạng, cơ chế xác thực, Kubernetes RBAC hoặc phạm vi quyền của các thành phần recovery. Với môi trường mạng nội bộ, đây là các điểm cần kiểm tra trong tài liệu triển khai và release notes trước khi đưa vào vận hành.
NVIDIA hướng người dùng đến documentation hub để nâng cấp Mission Control 2.5 và release notes để xem các tính năng mới, bao gồm AI-enabled network anomaly detection. Bài viết không mô tả quy trình nâng cấp, rollback hoặc tác động đến job đang chạy.
Scheduler chỉ là một phần của khả năng tự phục hồi
Mission Control 2.5 không thay thế scheduler. Bản cập nhật bổ sung hai lớp phục hồi xoay quanh scheduler: hiểu ngữ cảnh của job để chọn hướng khôi phục, và theo dõi hạ tầng để cô lập tài nguyên có rủi ro.
Khi lỗi phần cứng xuất hiện, workload có thể được khôi phục trong lúc node được cách ly và chẩn đoán. Khi lỗi chỉ mang tính tạm thời, workload có thể được retry mà không cần rút phần cứng khỏe khỏi cụm.
Với đội vận hành Kubernetes/GPU, điểm đáng chú ý là recovery không chỉ là restart pod. Nó cần phối hợp giữa scheduler, policy retry, theo dõi sức khỏe phần cứng và năng lực còn lại của cụm.