Cách NVIDIA Mission Control 2.5 mang lại khả năng tự động phục hồi cho Kubernetes

Việc huấn luyện các mô hình AI quy mô lớn trên hàng nghìn GPU là một hoạt động có rủi ro cao, trong đó việc giám sát và tự động hóa phải được tích hợp sẵn để tối ưu hóa khả năng phục hồi và thời gian hoạt động của cụm ở quy mô lớn. Khái niệm này không còn mới đối với các nhà vận hành trung tâm dữ liệu, những người đã đo lường thời gian sửa chữa trung bình (MTTR) và thời gian giữa các lần hỏng hóc trung bình (MTBF) từ lâu trước khi các nhà máy AI ra đời.

Giờ đây, mức độ rủi ro còn cao hơn. Các nhà máy AI hiện đại chạy các tác vụ huấn luyện phân tán trên hàng trăm nút trong nhiều ngày hoặc nhiều tuần, và ở quy mô này, mô hình vận hành thay đổi: các bất thường phần cứng, lỗi phần mềm, hết thời gian chờ mạng và tranh chấp tài nguyên phải được quản lý một cách chủ động để đảm bảo các khối lượng công việc diễn ra đúng tiến độ. Các phương pháp truyền thống dựa vào can thiệp thủ công, kiểm điểm tĩnh (static checkpointing) và giám sát thụ động đơn giản là không thể mở rộng khi các tổ chức đang chạy hàng chục khối lượng công việc đa nút đồng thời trên cơ sở hạ tầng dùng chung.

Đây là lý do tại sao các dịch vụ phần mềm, chẳng hạn như động cơ phục hồi tự động được cung cấp trong NVIDIA Mission Control, lại đóng vai trò quan trọng trong việc mở rộng quy mô AI trong môi trường sản xuất. Trước đây, động cơ phục hồi tự động, có khả năng phát hiện, chẩn đoán và khắc phục các bất thường trên toàn bộ hệ thống, chỉ giới hạn cho các tác vụ tính toán hiệu năng cao (HPC) sử dụng Slurm. Là một phần của Mission Control 2.5, dịch vụ này hiện đã được mở rộng cho các tác vụ dựa trên Kubernetes được quản lý bằng NVIDIA Run:ai.

Bài viết này minh họa cách phiên bản mới nhất của Mission Control đưa khung độ bền tích hợp của nó đến các tác vụ Kubernetes, giúp các hoạt động nhà máy AI chuyển từ bảo trì vận hành thụ động sang hạ tầng tự phục hồi chủ động.

Các dịch vụ khả năng phục hồi tích hợp

Tầm nhìn đằng sau động cơ phục hồi tự động của Mission Control rất đơn giản: các nhà máy AI nên là những hệ thống tự chữa lành, trong đó các sự cố được phát hiện ngay lập tức, các quyết định phục hồi được đưa ra một cách thông minh dựa trên ngữ cảnh khối lượng công việc và loại sự cố, và các tác vụ được tiếp tục tự động với sự gián đoạn hoặc lãng phí tài nguyên tính toán ở mức tối thiểu.

Mục tiêu là hiểu được điều gì đã gặp sự cố, cách ly các điểm bất thường và gắn thẻ chúng để bảo trì, đồng thời đưa các khối công việc trở lại các máy tính có hiệu suất hoạt động với thời gian lãng phí ít nhất có thể.

Hình 1. Trong một nhà máy AI, tự động hóa phục hồi nên đưa các nút ra khỏi các trạng thái rủi ro hoặc bị mắc kẹt và đưa chúng trở lại các máy tính có thể lập lịch và hoạt động hiệu quả càng nhanh càng tốt để ngăn ngừa việc mất công việc và chi phí cơ hội bị bỏ lỡ

Có hai dịch vụ tạo thành bộ động cơ phục hồi tự động:

phục hồi công việc tự động
phục hồi phần cứng tự động

Bởi vì khả năng phục hồi tự quản trị thực sự được hiểu tốt nhất là một vòng điều khiển thay vì một tính năng phục hồi đơn lẻ, bộ động cơ phục hồi tự động sau đó sẽ phối hợp với trình lập lịch tải việc (HPC hoặc Kubernetes), cung cấp một khung ba lớp tích hợp trong đó mỗi thành phần đóng một vai trò riêng biệt nhưng được phối hợp nhịp nhàng.

Trong bài viết này, chúng ta sẽ tập trung vào việc lập lịch các tác vụ dựa trên Kubernetes.

Hình 2. Ba thành phần của bộ động cơ phục hồi tự động của NVIDIA Mission Control 2.5: trình lập lịch Kubernetes, dịch vụ phục hồi tác vụ tự động và dịch vụ phục hồi phần cứng tự động

Ba vai trò trong vòng lặp

Hãy bắt đầu với lớp đặt tải việc Kubernetes. Trong Mission Control, NVIDIA Run:ai là trình lập lịch mặc định của Kubernetes và được bao gồm như một phần của phần mềm. Nó quản lý các tải việc AI dựa trên Kubernetes, hàng đợi, chính sách và lập lịch các tác vụ lên dung lượng khả dụng.

Dịch vụ khôi phục công việc tự động cung cấp lớp ngữ cảnh khối lượng công việc. Nó theo dõi các công việc đang chạy, theo dõi vị trí thực thi của từng công việc và sử dụng lịch sử sự cố cùng topo công việc để phân loại loại đường dẫn khôi phục nào là hợp lý. Tích hợp quản lý tài nguyên xác định cách hướng dẫn đó trở thành hành động khởi động lại, thử lại, xếp hàng lại hoặc bố trí.

Dịch vụ khôi phục phần cứng tự động là lớp sức khỏe hạ tầng. Nó giám sát các nút và GPU, loại bỏ các bất thường khỏi lịch trình khi cần thiết và chạy chẩn đoán hoặc khắc phục để các vấn đề phần cứng không tiếp tục lan rộng sang các công việc mới.

Việc tách biệt các trách nhiệm này chính là điều khiến mô hình trở nên có khả năng di chuyển. Dịch vụ khôi phục việc tự động không cần phải sửa chữa phần cứng và dịch vụ khôi phục phần cứng không cần phải hiểu mọi khung đào tạo. Cuối cùng, trình lập lịch có thể điều hướng các khối lượng công việc hướng tới sức chứa sẵn sàng mà không cần chờ đợi chẩn đoán nguyên nhân gốc rễ.

Các đường dẫn sự cố trong thực tế

Các kịch bản sau đây cho thấy vòng điều khiển hoạt động khác nhau trong Mission Control tùy thuộc vào tín hiệu lỗi được phát hiện bởi động cơ phục hồi tự động của nó.

Kịch bản 1. Lỗi phần cứng trong quá trình huấn luyện

Một tác vụ huấn luyện phân tán đang chạy trên một nhóm GPU thì một GPU bắt đầu gặp sự cố. Triệu chứng có thể xuất hiện đầu tiên dưới dạng lỗi ECC, worker treo hoặc thời gian chờ liên lạc hết hạn trong tác vụ.

Điều quan trọng là những gì xảy ra tiếp theo: quá trình phục hồi được chia thành hai luồng song song. Dịch vụ phục hồi tác vụ tự động sẽ nắm bắt ngữ cảnh của tác vụ và xác định nút hoặc GPU bị nghi ngờ. Tích hợp bộ lập lịch Kubernetes sau đó sẽ thúc đẩy quá trình phục hồi tải công việc bằng cách khởi động lại hoặc lập lịch lại tác vụ.

Hình 3. Khi một bất thường phần cứng xảy ra trong quá trình chạy huấn luyện, NVIDIA Mission Control có khả năng khởi động lại tác vụ trên các nút khác đang hoạt động bình thường trong khi quá trình khắc phục phần cứng vẫn tiếp tục

Đồng thời, dịch vụ khôi phục phần cứng tự động sẽ cách ly nút có vấn đề, ghi lại lý do và bắt đầu chẩn đoán. Đường dẫn phần cứng đó có thể tiếp tục ngay cả sau khi khối lượng công việc đã bắt đầu di chuyển trở lại.

Hình 4. Dịch vụ khôi phục phần cứng tự động trong NVIDIA Mission Control khiến nút không thể lập lịch và có thể kiểm toán. Việc thăm dò sau đó sẽ khóa quá trình phân loại và bắt đầu chẩn đoán

Giá trị của con đường này là giảm thời gian ngừng hoạt động. Khối lượng công việc không phải chờ phân tích nguyên nhân gốc rễ trước khi bắt đầu khôi phục, và nút bị lỗi sẽ không bị chuyển nhầm sang công việc tiếp theo.

Kịch bản 2. Lỗi phần mềm tạm thời

Không phải mọi sự cố công việc đều nên kích hoạt sửa chữa phần cứng. Một worker huấn luyện có thể thoát, gặp thời gian chờ có thể phục hồi, hoặc mất phối hợp trong một thời gian ngắn ngay cả khi node cơ bản vẫn hoạt động bình thường.

Trong luồng này, dịch vụ tự động phục hồi việc làm sử dụng ngữ cảnh của việc làm để tránh phản ứng quá mức. Nếu lịch sử lỗi có vẻ tạm thời, hệ thống sẽ thử lại theo chính sách của trình lập lịch thay vì cách ly phần cứng không cần sửa chữa.

Mặc dù NVIDIA Run:ai có thể diễn đạt quá trình phục hồi khác với cách xử lý cho Slurm, nhưng ý định là giống nhau: đưa khối lượng công việc trở lại trạng thái thực thi hiệu quả mà không cần khắc phục phần cứng không cần thiết. Dịch vụ tự động phục hồi phần cứng tiếp tục giám sát ở chế độ nền, nhưng nó không can thiệp vào luồng phục hồi trừ khi có bằng chứng mới chỉ ra lỗi phần cứng.

Hình 5. NVIDIA Mission Control xem xét việc một số sự cố việc làm là lỗi phần mềm và không cần khắc phục phần cứng. Trong trường hợp này, các sự cố phần mềm có thể thử lại sẽ tự động khởi động lại và các sự cố lặp lại sẽ được hiển thị

Giá trị của con đường này là sự tiết chế. Hệ thống khôi phục khối lượng công việc mà không tạo ra tiếng ồn vận hành không cần thiết hoặc thu nhỏ pool lập lịch.

Kịch bản 3. Phát hiện sớm sự suy giảm phần cứng

Dịch vụ phục hồi phần cứng tự động trong Mission Control cũng có thể phát hiện sự suy giảm cơ sở hạ tầng trước khi nó trở thành sự cố việc làm. Một nút có thể bắt đầu hiển thị các cảnh báo sức khỏe GPU lặp đi lặp lại, các vấn đề về kết nối hoặc các tín hiệu khác khiến nó trở nên rủi ro cho việc lập lịch trong tương lai.

Trong quy trình này, dịch vụ khôi phục phần cứng tự động có thể chủ động loại bỏ nút khỏi phạm vi đủ điều kiện của bộ lập lịch và bắt đầu chẩn đoán trước khi một tác vụ huấn luyện AI được triển khai tại đó. Dịch vụ khôi phục tác vụ tự động có thể không bao giờ cần phải phản hồi, vì dung lượng lỗi đã bị loại khỏi vòng lưu thông trước khi nó gây gián đoạn cho một khối lượng công việc.

Hình 6. Với dịch vụ khôi phục phần cứng tự động của NVIDIA Mission Control, phần cứng nghi ngờ bị lỗi được giữ ngoài nhóm lập lịch trong khi quá trình chẩn đoán và khắc phục được thực hiện

Trong trường hợp này, trình lập lịch dựa trên Kubernetes của Mission Control được hưởng lợi từ một nhóm tài nguyên khả dụng sạch sẽ hơn. Nó có thể tránh việc đặt các tác vụ Kubernetes trên các khả năng nghi ngờ, tương tự như cách Mission Control đã cho phép Slurm giữ các nút lỗi ra khỏi các phân bổ cho đến khi chúng được xác thực lại.

Giá trị của con đường này là sự phòng ngừa. Hệ thống giảm thiểu khả năng một nút có rủi ro đã biết trở thành sự cố huấn luyện AI vào ngày mai.

Tác động vận hành

Việc mở rộng động cơ phục hồi tự động của Mission Control sang NVIDIA Run:ai đánh dấu thêm một bước tiến hướng tới việc đạt được nhà máy AI tự phục hồi. Cấu trúc này thay đổi khả năng chống chịu sự cố từ quy trình xử lý sự cố cụ thể của bộ lập lịch thành mô hình vận hành nhận thức được bộ lập lịch.

Đối với các nhóm nền tảng, Mission Control 2.5 cung cấp một mô hình phục hồi nhất quán trên cả môi trường Kubernetes và Slurm của họ. Các nút lỗi sẽ được cách ly, chú thích hoặc ghi nhận, chẩn đoán và chỉ được đưa trở lại hoạt động khi chúng đã sẵn sàng.

Đối với các chuyên gia AI, giờ đây cả người dùng Slurm và Kubernetes đều có thể hưởng lợi từ quá trình phục hồi đơn giản hơn. Các tác vụ có thể khởi động lại, thử lại hoặc xếp hàng lại theo trình điều độ mà họ đang sử dụng, trong khi động cơ phục hồi tự động cung cấp ngữ cảnh cần thiết để tránh các sự cố lặp lại trên cơ sở hạ tầng cần được bảo trì.

Đối với doanh nghiệp, lợi ích là việc sử dụng hiệu quả hơn năng lực của các bộ tăng tốc quý giá. Hệ thống dành ít thời gian hơn cho việc bị đình trệ trong sự mơ hồ và nhiều thời gian hơn để duy trì hiệu suất của các tác vụ huấn luyện.

Video 1. NVIDIA Mission Control demo của khả năng phục hồi tự động cho các tải việc dựa trên Kubernetes

Bắt đầu với Mission Control 2.5

Mission Control 2.5 đã có sẵn từ hôm nay. Người dùng NVIDIA Mission Control hiện tại có thể truy cập trung tâm tài liệu để tìm hiểu thêm về cách nâng cấp lên phiên bản mới nhất. Ngoài việc mở rộng động cơ phục hồi tự động cho các khối việc dựa trên Kubernetes, các điểm nổi bật khác của bản phát hành bao gồm:

Dịch vụ phát hiện bất thường mạng mới được hỗ trợ bởi AI (chỉ ở chế độ beta)
Cải thiện trải nghiệm người dùng cho xác thực xuyên suốt các dịch vụ bằng cách sử dụng central keycloak
Các bản cập nhật bảo mật và tăng cường bảo mật Kubernetes bổ sung
Truy cập sớm cho NVIDIA Vera Rubin NVL72

Đọc đầy đủ ghi chú phát hành tại đây hoặc đọc tổng quan giải pháp để tìm hiểu thêm về cách NVIDIA Mission Control đơn giản hóa hoạt động của nhà máy AI bằng phần mềm sẵn sàng cho doanh nghiệp, bao quát điều phối khối lượng công việc, giám sát đầu-cuối và tự động phục hồi.

____
Bài viết liên quan