Chiến lược xây dựng cụm OpenSearch chống chịu lỗi vùng tại Uber: Bài học từ thực tế

Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.

Điểm tin nhanh:

• Uber triển khai Isolation Groups (IG) như một lớp logic trung gian để đảm bảo phân bổ node đồng đều, bất chấp sự chênh lệch về hạ tầng vật lý giữa các vùng.
• Cơ chế forced shard allocation awareness ngăn chặn các đợt rebalancing gây quá tải hệ thống khi xảy ra sự cố vùng.
• Sử dụng 5 node quản lý cụm (cluster manager) kết hợp với tính năng tự động thu nhỏ cấu hình bỏ phiếu giúp duy trì quorum ngay cả khi mất 2 node.

Trong thế giới hạ tầng quy mô lớn, việc một trung tâm dữ liệu hay một vùng (availability zone) gặp sự cố không còn là chuyện hiếm gặp. Tuy nhiên, đối với các hệ thống lưu trữ dữ liệu phân tán như OpenSearch, việc xử lý sự cố này mà không làm sập toàn bộ hệ thống hoặc gây ra tình trạng quá tải do rebalancing là một thách thức kỹ thuật cực kỳ lớn. Uber đã giải quyết bài toán này không chỉ bằng cách dựa vào các tính năng có sẵn mà còn thông qua việc xây dựng một lớp trừu tượng hóa thông minh, giúp hệ thống vận hành ổn định ngay cả trong những tình huống khắc nghiệt nhất.

Thách thức từ sự không đồng nhất của hạ tầng vật lý

Thông thường, logic phân bổ shard của OpenSearch dựa trên các thuộc tính nhận thức vùng (awareness attributes). Tuy nhiên, tại Uber, các vùng vật lý thường không có số lượng node bằng nhau. Sự chênh lệch này dẫn đến tình trạng cụm luôn ở trạng thái yellow, các shard không được gán (unassigned), và nghiêm trọng hơn là gây ra hiện tượng disk skew (lệch đĩa) và hot nodes (node quá tải) khi hệ thống cố gắng rebalance trên các vùng có dung lượng không đồng đều.

Để giải quyết vấn đề này, Uber đã giới thiệu Isolation Groups (IG). Đây là một lớp logic nằm giữa hạ tầng vật lý và logic phân bổ của OpenSearch. Mỗi IG được đảm bảo có số lượng node bằng nhau, giúp OpenSearch hoạt động hiệu quả như thể hạ tầng bên dưới hoàn toàn đồng nhất.

Kiến trúc Isolation Groups và cơ chế chống chịu lỗi

Uber áp dụng mô hình 3 IG cho hầu hết các dịch vụ. Một vùng vật lý sẽ ánh xạ trực tiếp vào một IG, đảm bảo rằng nếu một vùng gặp sự cố, hệ thống chỉ mất tối đa khoảng 1/3 công suất. Mỗi index được cấu hình với ít nhất 2 bản sao (tổng cộng 3 bản sao), mỗi bản sao nằm trên một IG khác nhau.

Mẹo hay: Việc tách biệt logic phân bổ shard ra khỏi hạ tầng vật lý giúp bạn kiểm soát tốt hơn sự ổn định của cụm mà không cần phụ thuộc vào sự cân bằng của các provider cloud.

Khi xảy ra sự cố, thay vì để OpenSearch tự động rebalance - điều thường gây ra bão I/O và CPU - Uber sử dụng cơ chế forced shard allocation awareness. Cụm được cấu hình với tất cả các giá trị IG ngay từ đầu. Khi một IG mất kết nối, OpenSearch sẽ nhận diện được khoảng trống nhưng không cố gắng phân bổ quá mức sang các nhóm còn lại. Kết quả là cụm chuyển sang trạng thái yellow thay vì kích hoạt một đợt rebalancing gây quá tải cho các node khỏe mạnh.

Bảng so sánh cơ chế xử lý sự cố

Việc tối ưu hóa hạ tầng này cũng tương tự như cách các kỹ sư cần tối ưu hóa quy trình phát triển để tránh các lỗi cấu hình không đáng có trong môi trường thực tế.

Quản lý Quorum với 5 Cluster Manager Nodes

Để đảm bảo tính toàn vẹn của dữ liệu, Uber sử dụng 5 node quản lý cụm thay vì 3 node thông thường. Kết hợp với tính năng cluster.auto_shrink_voting_configuration, cụm có khả năng tự động thu nhỏ cấu hình bỏ phiếu khi mất node. Nếu một vùng gặp sự cố làm mất 2 node quản lý, hệ thống vẫn còn 3 node để duy trì quorum, đảm bảo cụm vẫn có thể ghi dữ liệu.

Đây là một ví dụ điển hình về việc xây dựng hệ thống bền vững, tương tự như cách chúng ta cần xây dựng hệ thống Event-Driven đáng tin cậy bằng cách kiểm soát chặt chẽ các hợp đồng dữ liệu.

Đánh giá & Lời khuyên Thực tiễn

Giải pháp của Uber rất mạnh mẽ cho các hệ thống có quy mô cực lớn (hyperscale).

• Ưu điểm: Loại bỏ hoàn toàn tình trạng rebalancing storm, tăng tính dự báo của hệ thống khi có sự cố.
• Nhược điểm: Yêu cầu quản lý thêm một lớp logic (IG), tăng độ phức tạp trong cấu hình ban đầu.
• Phạm vi ứng dụng: Phù hợp cho các doanh nghiệp chạy cụm OpenSearch/Elasticsearch trên nhiều vùng vật lý với tài nguyên không đồng nhất.

Lưu ý: Trước khi áp dụng, hãy đảm bảo đội ngũ vận hành của bạn đã nắm vững cơ chế shard allocation awareness của OpenSearch để tránh cấu hình sai dẫn đến mất dữ liệu.

Nếu bạn đang gặp khó khăn với hiệu năng, hãy cân nhắc xem liệu các tiến trình dev server bị bỏ quên có đang làm ảnh hưởng đến tài nguyên máy trạm của bạn hay không, vì sự ổn định bắt đầu từ chính môi trường phát triển.

Câu hỏi thường gặp (FAQ)

Tại sao không nên để OpenSearch tự động rebalance khi mất vùng?

Việc tự động rebalance sẽ kích hoạt hàng loạt tác vụ di chuyển dữ liệu, gây quá tải I/O, CPU và mạng, có thể dẫn đến hiệu ứng domino làm sập cả các node còn khỏe mạnh.

Isolation Groups có làm giảm dung lượng khả dụng của cụm không?

Không, IG chỉ là lớp logic để phân bổ shard. Dung lượng tổng thể vẫn được duy trì, nhưng việc phân bổ trở nên có kiểm soát hơn.

Làm sao để biết khi nào cần tăng số lượng Cluster Manager lên 5 node?

Khi hệ thống của bạn yêu cầu khả năng chịu lỗi cao hơn mức 1 node (ví dụ: chịu được mất 2 node quản lý mà không mất khả năng ghi), việc nâng cấp lên 5 node là cần thiết.

Kết luận

Cách tiếp cận của Uber cho thấy rằng trong kỹ thuật phần mềm, đôi khi việc thêm một lớp trừu tượng hóa logic chính là chìa khóa để giải quyết các vấn đề vật lý phức tạp. Bằng cách kiểm soát chặt chẽ shard allocation và quorum, Uber đã biến một cụm OpenSearch vốn nhạy cảm trở nên bền bỉ hơn bao giờ hết. Hãy theo dõi hi_dev để cập nhật thêm những kiến thức chuyên sâu về hạ tầng và công cụ lập trình mới nhất.