Giới thiệu
JuiceFS là một hệ thống tệp phân tán được xây dựng trên lưu trữ đối tượng. Để nâng cao hiệu quả ghi dữ liệu, JuiceFS cung cấp tính năng ghi writeback, nơi dữ liệu được ghi vào bộ nhớ cache của đĩa cục bộ trên nút ứng dụng trước khi được ghi không đồng bộ vào lưu trữ đối tượng. Điều này giúp giảm đáng kể độ trễ ghi. Ví dụ, trong một thử nghiệm ghi 10.000 mục, việc bật tính năng writeback cho phép quá trình truyền dữ liệu hoàn thành trong 10 giây, trong khi không có writeback, quá trình này mất 2 phút. Tuy nhiên, tính năng writeback cũng đi kèm với một số rủi ro và hạn chế trong việc sử dụng.
Trong bài viết này, chúng ta sẽ đi sâu vào cơ chế ghi của JuiceFS và giải thích cách hoạt động của writeback, các tình huống áp dụng cũng như những lưu ý quan trọng. Chúng tôi hy vọng bài viết sẽ giúp bạn hiểu rõ hơn về cả những lợi ích và vấn đề tiềm ẩn của tính năng này.
Chế độ ghi tiêu chuẩn của JuiceFS
Quá trình ghi dữ liệu của JuiceFS bao gồm hai bước:
- Ghi các chunk dữ liệu vào lưu trữ đối tượng và trả về đồng bộ: Khách hàng ghi các chunk dữ liệu đã chia nhỏ vào lưu trữ đối tượng. Bất kể tốc độ ghi của lưu trữ đối tượng (dù độ trễ có thể lên đến hàng trăm mili giây), JuiceFS sẽ đợi xác nhận trước khi tiếp tục.
- Ghi metadata: Sau khi lưu trữ đối tượng phản hồi, JuiceFS ghi metadata.
Các phiên bản Community và Enterprise có cơ chế không hợp lệ hóa cache khác nhau. Điều này dẫn đến các cách tiếp cận khác nhau trong việc xử lý tính nhất quán dữ liệu:
- Phiên bản Community: Mỗi khách hàng có một bộ nhớ cache metadata trong bộ nhớ với thời gian hết hạn mặc định là 1 giây. Do thiếu cơ chế thông báo chủ động trong phiên bản Community, khách hàng chỉ có thể chờ đợi một cách thụ động cho đến khi cache hết hạn để lấy dữ liệu mới nhất. Như một sự thỏa hiệp, thời gian mặc định được đặt thành 1 giây; việc tăng cường thiết lập này chỉ được khuyến nghị trong các tình huống chỉ đọc.
- Phiên bản Enterprise: Phiên bản Enterprise hỗ trợ thông báo không hợp lệ hóa cache chủ động. Khi một tệp được sửa đổi, nó gửi thông báo không hợp lệ đến tất cả các khách hàng đang sử dụng tệp đó, yêu cầu họ yêu cầu dữ liệu trực tiếp từ máy chủ metadata trong lần đọc tiếp theo thay vì sử dụng cache cục bộ của họ. Điều này cho phép bản Enterprise duy trì thời gian cache metadata lâu hơn, giảm áp lực cho máy chủ.
Cách hoạt động của writeback
Mục tiêu chính của chế độ writeback là tăng tốc quá trình ghi. Dữ liệu được ghi vào đĩa cục bộ trước, và một thư mục rawstaging được tạo ra dưới thư mục cache-dir để lưu trữ dữ liệu cục bộ chưa được tải lên lưu trữ đối tượng. Dữ liệu này được gọi là dữ liệu staging.
Dữ liệu được ghi vào đĩa cục bộ và trả về phản hồi ngay lập tức. Điều này giúp tốc độ ghi nhanh hơn nhiều so với ghi trực tiếp vào lưu trữ đối tượng — thường trong khoảng mili giây. Các đĩa NVMe hiệu suất cao thậm chí có thể đạt độ trễ dưới 1 mili giây. Sau khi ghi, khách hàng thông báo cho máy chủ metadata rằng việc ghi dữ liệu đã hoàn thành, và quá trình đồng bộ hóa tiếp theo giống như trong các ghi chuẩn. Tuy nhiên, các chunk dữ liệu được tải lên không đồng bộ vào lưu trữ đối tượng. Tốc độ tải lên và thời gian hoàn thành phụ thuộc vào mạng và tải của nút, làm cho việc dự đoán trạng thái chính xác trở nên không thể.
Mặc dù chế độ writeback cung cấp tốc độ ghi cao hơn, chúng tôi thường không khuyến nghị cho khách hàng, chủ yếu do hai mối quan tâm sau:
- Rủi ro về dữ liệu chưa được tải lên: Nhiều khách hàng nhầm tưởng rằng dữ liệu đã được ghi thành công vào lưu trữ đối tượng sau khi nhận được phản hồi đồng bộ. Tuy nhiên, dữ liệu có thể vẫn nằm cục bộ và chưa được tải lên. Nếu nút bị tắt hoặc thậm chí bị phá hủy tại thời điểm này, dữ liệu sẽ tiếp tục được tải lên sau khi khởi động lại, nhưng nếu nút bị phá hủy, dữ liệu sẽ bị mất vĩnh viễn.
- Không khả dụng ngay lập tức trên các nút khác: Các tệp được ghi vào thư mục staging cục bộ không thể truy cập được từ các nút khác cho đến khi được tải lên lưu trữ đối tượng. Điều này vi phạm tính nhất quán đọc-sau-ghi và phá vỡ tính nhất quán mạnh mẽ gần-mở. Điều này có thể không thể chấp nhận được trong một số tình huống.
Các tình huống áp dụng cho chế độ writeback
Mặc dù có những rủi ro, chế độ writeback mang lại lợi ích đáng kể trong việc cải thiện tốc độ ghi, đặc biệt trong các tình huống yêu cầu phản hồi ghi nhanh. Ví dụ, khi ghi một số lượng lớn tệp nhỏ, miễn là các rủi ro về việc ghi chậm vào lưu trữ đối tượng và mất dữ liệu do tải lên không đồng bộ có thể được giảm thiểu hiệu quả, chế độ writeback là một lựa chọn hiệu quả và thực tiễn. Bạn có thể linh hoạt áp dụng nó dựa trên nhu cầu thực tế của bạn.
Lấy ví dụ về việc ghi 10.000 mục vào thư mục "numbers" trong JuiceFS. Nếu không bật chế độ cache hoặc writeback, việc giám sát cho thấy mỗi yêu cầu PUT đến lưu trữ đối tượng chỉ truyền tải được vài trăm byte, với độ trễ hơn 20 mili giây. Việc ghi 10.000 mục mất khoảng hai phút, điều này rất chậm.
Khi chế độ writeback được bật, độ trễ PUT không thay đổi. Tuy nhiên, lưu lượng PUT trở nên tập hợp lại, với mỗi yêu cầu gửi hàng chục nghìn byte (chẳng hạn như 21 KB hoặc 70 KB). Trong trường hợp này, ứng dụng nhận được phản hồi trong vòng 5 giây, và quá trình truyền dữ liệu hoàn thành trong vòng 10 giây, cải thiện đáng kể hiệu suất.
Trong các tình huống khác nhau, cần phải đánh giá rủi ro. Rủi ro của các tác vụ ghi chậm là thời gian dài, trong đó các thay đổi ứng dụng có thể dẫn đến các vấn đề về dữ liệu. Ngược lại, ghi nhanh trước và sau đó tập hợp các tải lên, mặc dù mang rủi ro mất dữ liệu, nhưng làm ngắn thời gian. Trong các trường hợp thực tế, sự khác biệt hiệu suất này có thể mở rộng từ 5 giây đến 5 giờ, và các rủi ro do các thay đổi ứng dụng trong 5 giờ này không thể bị bỏ qua.
Dựa trên phân tích trên, chúng tôi tóm tắt các tình huống khuyến nghị cho chế độ writeback:
- Ghi checkpoint thường xuyên trong các tác vụ đào tạo: Ví dụ, một số tác vụ đào tạo ghi checkpoint hàng giờ, và GPU phải chờ phản hồi trước khi tiếp tục. Khi bật chế độ writeback, ngay cả khi một nút gặp sự cố và không thể khôi phục, mất mát chỉ giới hạn trong một giờ dữ liệu đào tạo và xác suất gặp sự cố là thấp. Từ góc độ ứng dụng, phản hồi ngay lập tức sau khi ghi giúp cải thiện đáng kể việc sử dụng GPU và giảm thời gian chờ. Tuy nhiên, nếu chỉ ghi một checkpoint mỗi ngày, nên chờ vài phút để đảm bảo dữ liệu được ghi vào lưu trữ đối tượng trước khi trả về, đảm bảo an toàn dữ liệu.
- Môi trường phát triển của người dùng: Ví dụ, trong các tình huống AI, nhiều người dùng đặt thư mục chính của họ trên JuiceFS. Nếu không có chế độ writeback, việc cài đặt một gói phần mềm có thể mất từ ba đến năm phút, trong khi với chế độ writeback được bật, thời gian cài đặt có thể giảm xuống chỉ còn vài chục giây. Vì đây thường là thư mục cá nhân và hiếm khi được chia sẻ với các điểm gắn khác, rủi ro mất dữ liệu là thấp. Do đó, bật chế độ writeback để tăng tốc các thao tác là khuyến nghị.
- Các tình huống với nhiều tệp nhỏ hoặc giải nén tạm thời: Ví dụ, khi kéo tệp từ JuiceFS và giải nén chúng, có liên quan đến một số lượng lớn tệp nhỏ. Việc bật chế độ writeback có thể cải thiện đáng kể tốc độ và hiệu quả giải nén.
- Các tình huống với nhiều ghi ngẫu nhiên.
Về việc áp dụng chế độ writeback, hãy xem StepFun đã xây dựng một nền tảng lưu trữ LLM hiệu quả và tiết kiệm chi phí với JuiceFS. StepFun sử dụng hệ thống tệp phân tán GPFS làm đĩa cache và đặt thư mục staging trên GPFS để giải quyết các vấn đề về an toàn dữ liệu và khả năng đọc. Cần lưu ý rằng số lượng nút GPFS không nên quá nhiều, vì điều này có thể gây ra rủi ro về độ ổn định. Tuy nhiên, lợi ích là rất lớn: trong quá trình ghi dữ liệu checkpoint, việc bật chế độ writeback giúp cải thiện đáng kể khả năng chịu lỗi ghi và hiệu suất thông lượng.
Kế hoạch tối ưu hóa trong tương lai
Trong JuiceFS Enterprise Edition 5.3, chúng tôi dự định giới thiệu khái niệm thiết bị khối chia sẻ để thay thế chế độ writeback dựa vào đĩa cục bộ của một nút duy nhất. Nói một cách đơn giản, một thiết bị khối sẽ được gắn đồng thời bởi nhiều khách hàng như thư mục staging, đảm bảo tính nhất quán đọc-sau-ghi. Các thiết bị khối chia sẻ thường là đĩa đám mây với độ tin cậy cao và tỷ lệ hỏng hóc thấp, hiệu quả giải quyết các vấn đề về tính nhất quán truy cập dữ liệu.
Tuy nhiên, các đĩa đám mây chia sẻ có những hạn chế — một đĩa đám mây duy nhất chỉ có thể được gắn bởi tối đa 16 khách hàng. Để giải quyết điều này, chúng tôi đề xuất một giải pháp thiết bị gắn một lần: một nút gắn thiết bị, và các nút khác đọc dữ liệu thông qua nó. Khi đủ nhiều nút cung cấp đủ đĩa gắn một lần, các vấn đề nóng dữ liệu sẽ được giải quyết một phần. Đây là một giải pháp tăng tốc ghi hứa hẹn trên lưu trữ đối tượng.
Nếu bạn có bất kỳ câu hỏi nào về bài viết này, hãy tham gia thảo luận về JuiceFS trên GitHub và cộng đồng trên Slack.
