Chọn đơn vị chỉ huy trong các hệ thống phân tán

Chọn đơn vị chỉ huy là ý tưởng đơn giản về việc cấp cho một đơn vị (như quy trình, máy chủ, luồng, đối tượng hoặc con người) trong hệ thống phân tán một số quyền đặc biệt. Những quyền đặc biệt đó có thể bao gồm khả năng chỉ định công việc, khả năng sửa đổi một chi tiết dữ liệu hoặc thậm chí là trách nhiệm xử lý tất cả các yêu cầu trong hệ thống.

Chọn đơn vị chỉ huy là một công cụ mạnh mẽ giúp cải tiến hiệu quả, giảm công tác điều phối, đơn giản hóa kiến trúc và giảm thao tác. Tuy vậy, chọn đơn vị chỉ huy có thể gây ra các chế độ lỗi mới và vướng mắc trong việc mở rộng. Ngoài ra, hoạt động này còn có thể khiến bạn khó đánh giá tính chính xác của một hệ thống hơn.

Vì những phiền toái này, chúng tôi cẩn thận cân nhắc các tùy chọn khác trước khi triển khai việc chọn đơn vị chỉ huy. Với các quy trình công việc và việc xử lý dữ liệu, các dịch vụ quy trình công việc như AWS Step Functions có thể đem lại nhiều lợi ích tương tự như phương pháp chọn đơn vị chỉ huy mà vẫn tránh được phần lớn các rủi ro này. Với các hệ thống khác, chúng tôi thường triển khai API lũy đẳng, khóa tích cực và các mô hình khác để không cần dùng đến đơn vị chỉ huy duy nhất.

Trong bài viết này, tôi sẽ thảo luận một số điểm mạnh và điểm yếu của việc chọn đơn vị chỉ huy nói chung và cách Amazon tiếp cận phương pháp chọn đơn vị chỉ huy trong hệ thống phân tán của chúng tôi, trong đó có thông tin chuyên sâu về lỗi của đơn vị chỉ huy.

Có rất nhiều cách để chọn đơn vị chỉ huy, từ sử dụng thuật toán như Paxos, đến phần mềm như Apache ZooKeeper, phần cứng tùy chỉnh hay hợp đồng thuê. Hợp đồng thuê là cơ chế chọn đơn vị chỉ huy được dùng nhiều nhất tại Amazon. Đây là cách tương đối dễ hiểu và thực hiện, cung cấp khả năng chịu lỗi cao được tích hợp sẵn. Hợp đồng thuê hoạt động khi có một cơ sở dữ liệu duy nhất lưu trữ đơn vị chỉ huy hiện tại. Khi đó, hợp đồng thuê sẽ yêu cầu đơn vị chỉ huy đo nhịp định kỳ để chứng minh rằng đó vẫn là đơn vị chỉ huy. Nếu đơn vị chỉ huy không thể đo nhịp sau một vài lần, các ứng cử viên đơn vị chỉ huy khác có thể tìm cách tiếp nhận.

Chúng tôi tránh phụ thuộc vào thời gian trong các hệ thống phân tán, kể cả với tính năng đồng bộ thời gian tốt trong Amazon Elastic Compute Cloud (Amazon EC2). Thật khó để đảm bảo đồng hồ hệ thống trên toàn cụm được đồng bộ đủ để dựa vào đó ra lệnh hoặc điều phối các hoạt động phân tán. Tại Amazon, các hệ thống phân tán chỉ sử dụng thời gian cho việc tiêu thụ của con người. Hợp đồng thuê phụ thuộc vào thời gian. Tuy nhiên, chúng chỉ phụ thuộc vào khoảng thời gian đã qua cục bộ, thay vì giờ trên đồng hồ treo tường được đồng bộ hóa và cần có sự đồng ý của nhiều máy chủ.

Mã nguồn máy khách khóa DynamoDB đưa ra các ví dụ và thông tin chi tiết liên quan đến việc chọn đơn vị chỉ huy. Tuy nhiên, chúng tôi nhận thấy rằng mặc dù hợp đồng thuê và khóa đơn giản về mặt khái niệm nhưng để triển khai đúng thì cần có sự tinh tế. Để triển khai, phải có hiểu biết về cách máy chủ đo thời lượng cục bộ. Ví dụ: Nếu một máy chủ hoặc thư viện đo thời gian cho rằng thời gian thỉnh thoảng lùi lại, việc này sẽ phá vỡ các giả định về thời lượng được đưa vào hợp đồng thuê. Vấn đề nhảy bước thời gian với đồng bộ hóa đồng hồ toàn cầu có thể khiến máy chủ dừng chấp nhận thời gian, từ giây nhuận đến đồng hồ cục bộ sai lệch theo thời gian do liên tục sử dụng CPU ở mức cao.

Một vấn đề lớn hơn đối với hợp đồng thuê và tất cả các loại đồng hồ phân tán đó là đảm bảo đơn vị chỉ huy chỉ làm việc trong khi duy trì khóa. Việc đảm bảo đơn vị chỉ huy duy trì khóa thực sự khá khó. Chúng tôi thấy quan trọng là phải đảm bảo đơn vị chỉ huy trên một mạng chậm hoặc mạng bị rớt không cho rằng chúng đang duy trì khóa lâu hơn thực tế. Tương tự, việc tạm dừng gom rác giữa thời điểm khóa được kiểm tra và công việc được thực hiện có thể dẫn đến hành vi không đúng. Trong thực tế, việc cứng rắn chống lại những vấn đề này thường là thách thức lớn nhất.

DynamoDB và ZooKeeper cung cấp các máy khách khóa dựa trên hợp đồng thuê đơn giản, cho bạn tính năng chọn đơn vị chỉ huy có khả năng chịu lỗi cao. Trừ khi có nhu cầu đặc biệt, chúng tôi thích dùng các máy khách này vì theo chúng tôi, chúng cung cấp cách dễ nhất và đã được thử nghiệm để tiến hành chọn đơn vị chỉ huy. Đội ngũ của Amazon muốn tránh tạo ra hoạt động triển khai chọn đơn vị chỉ huy tùy chỉnh. Thay vào đó, chúng tôi thích các máy khách hiện tại vì chúng đã được thử nghiệm và củng cố qua sinh tồn.

Đây là mô hình được triển khai rộng rãi trong Amazon. Ví dụ:

• Hầu hết các hệ thống sử dụng hệ thống quản lý cơ sở dữ liệu liên quan theo kiểu truyền thống (RDBMS) đều dựa vào việc chọn đơn vị chỉ huy để chọn cơ sở dữ liệu đơn vị chỉ huy có khả năng xử lý toàn bộ việc ghi và đôi khi cả việc đọc. Trong những hệ thống này, việc chọn có thể được tự động hóa, nhưng thông thường, việc này vẫn được thực hiện thủ công bởi người vận hành.
• Amazon EBS phân phối việc đọc và ghi cho ổ đĩa trên nhiều máy chủ lưu trữ. Để đảm bảo tính nhất quán, Amazon EBS sử dụng việc chọn đơn vị chỉ huy để chọn những điểm chính cho từng khu vực ổ đĩa, có tác dụng sắp xếp việc đọc và ghi. Nếu điểm chính đó thất bại, đơn vị theo dõi sẽ sao chép các bước trong việc sử dụng cùng cơ chế chọn đơn vị chỉ huy đó. Tại Amazon EBS, việc chọn đơn vị chỉ huy vừa giúp đảm bảo tính nhất quán, vừa cải thiện được hiệu suất bằng cách tránh phải điều phối trên mặt phẳng dữ liệu. DynamoDB, Amazon Quantum Ledger Database (Amazon QLDB) và Amazon Kinesis (Kinesis) sử dụng các phương pháp tiếp cận giống nhau vì cùng lý do.
• Kinesis Client Library (KCL) sử dụng hợp đồng thuê để đảm bảo mỗi phân mảnh Kinesis đều được một chủ sở hữu xử lý, giúp dễ dàng thực hiện mở rộng luồng Kinesis.

Một điểm khác mà bạn cần suy nghĩ kỹ đó là điều gì sẽ xảy ra với công việc của đơn vị chỉ huy khi đơn vị không thành công. Nếu đơn vị chỉ huy không thành công trong khi thực hiện tác vụ, đơn vị chỉ huy mới sẽ hoàn thành tác vụ đó như thế nào? Nếu đơn vị chỉ huy không thành công trước khi biến công việc trở nên lâu dài, hệ thống có còn đúng không? Nhiều loại hệ thống có các bước “biến công việc trở nên lâu dài” và “cho đơn vị khác biết công việc đã hoàn thành” riêng. Tại Amazon, hệ thống của chúng tôi luôn thực hiện bước trước rồi mới đến bước sau (nếu không có thể mất dữ liệu). Lũy đẳng lại có ích ở đây. Nó cho phép đơn vị chỉ huy mới tự tin thực hiện tiếp công việc mà đơn vị chỉ huy trước đó có thể đã hoàn thành một phần hoặc hoàn thành xong nhưng không cho đơn vị khác biết.

Để có thể chịu lỗi, các hệ thống phân tán của Amazon không thể có một đơn vị chỉ huy duy nhất. Thay vào đó, lãnh đạo là tài sản có thể chuyển từ máy chủ này sang máy chủ kia hoặc quy trình này sang quy trình kia. Ở các hệ thống phân tán, không thể đảm bảo rằng chỉ có đúng một đơn vị chỉ huy trong hệ thống. Thay vào đó, phần lớn hệ thống có một đơn vị chỉ huy, cũng có thể là có hai hoặc không có đơn vị chỉ huy trong khi xảy ra lỗi.

Cách chúng tôi chọn hành vi của hệ thống khi có lỗi của đơn vị chỉ huy phụ thuộc vào tình huống xảy ra trong hệ thống khi có hai đơn vị chỉ huy. Các hệ thống thực hiện công việc lũy đẳng thường có thể cho phép hai đơn vị chỉ huy với tổn thất hiệu quả tối thiểu. Với hai đơn vị chỉ huy, tính khả dụng của hệ thống sẽ cao hơn và hệ thống có thể chọn phương pháp tiếp cận chọn đơn vị đứng đầu yếu hơn.

Việc xây dựng các hệ thống chỉ cần tối đa một đơn vị chỉ huy khó hơn xây dựng hệ thống nhiều có đơn vị chỉ huy. Hệ thống chọn đơn vị chỉ huy luôn phải chính xác và nhất quán. Đồng thời, phải đảm bảo rằng đơn vị chỉ huy trước đó đã bị loại bỏ vai trò này trước khi chọn đơn vị chỉ huy mới, việc này khó hơn bạn tưởng. Trong các hệ thống phân tán, bạn thường khó có thể biết được liệu một hệ thống có bị lỗi không hay chỉ đang tiếp tục thực hiện công việc ở một số phân vùng mạng khác. Tại Amazon, chúng tôi đảm bảo mọi hệ thống đã chọn đơn vị chỉ huy đều có thể xử lý sự cố cực biên này.

Tại Amazon, chúng tôi làm theo các biện pháp thực hành tốt nhất để chọn đơn vị chỉ huy:

• Thường xuyên kiểm tra thời gian thuê còn lại (hoặc trạng thái khóa nói chung), đặc biệt là trước khi bắt đầu bất cứ hoạt động nào có tác dụng phụ vượt quá chính đơn vị chỉ huy.
• Cân nhắc các tình huống tạm dừng do mạng chậm, hết thời gian chờ, thử lại và tạm dừng để dọn rác có thể khiến thời gian thuê còn lại hết hạn trước thời điểm mã dự đoán.
• Tránh sử dụng các hợp đồng thuê tạo xung ở luồng trong nền. Việc này có thể gây ra vấn đề về tính chính xác nếu luồng không thể ngắt mã khi hợp đồng thuê hết hạn hoặc tạo xung nhịp ngừng. Có thể xảy ra vấn đề về tính khả dụng nếu luồng công việc ngừng hoặc dừng trong khi luồng tạo xung còn trên hợp đồng thuê.
• Có số liệu tin cậy về khối lượng công việc mà một đơn vị chỉ huy có thể làm so với khối lượng đơn vị đó hiện đang làm. Thường xuyên xem lại những số liệu này và đảm bảo rằng bạn có sẵn kế hoạch để mở rộng trước khi hết công suất.
• Tạo điều kiện thuận lợi để tìm được máy chủ hiện là đơn vị chỉ huy và máy chủ nào đã từng là đơn vị chỉ huy tại mọi thời điểm cụ thể. Giữ lại biên bản kiểm tra hoặc nhật ký thay đổi lãnh đạo.
• Xây dựng mô hình và xác minh tính chính xác của các thuật toán phân tán một cách chính thức bằng các công cụ như TLA+. Việc này cần sự tinh tế và khó theo dõi, các lỗi hiếm gặp có thể xuất hiện khi ứng dụng giả định quá nhiều về các đảm bảo mà giao thức chọn đơn vị chỉ huy cung cấp.

Chọn đơn vị chỉ huy là một công cụ mạnh mẽ được dùng ở các hệ thống trên toàn Amazon để giúp hệ thống có khả năng chịu lỗi cao và dễ vận hành hơn. Tuy nhiên, khi sử dụng phương pháp này, chúng tôi cần xem xét cẩn thận các đảm bảo mà mỗi giao thức chọn đơn vị chỉ huy cung cấp và quan trọng hơn chính là những đảm bảo mà chúng không cung cấp.

Hệ thống Amazon thường sử dụng công cụ chọn đơn vị chỉ huy để đảm bảo được tích hợp khả năng chịu lỗi cao. Khi hệ thống sử dụng phương pháp chọn đơn vị chỉ huy để đảm bảo có ít nhất một máy chủ đang xử lý tác vụ, chúng sẽ dùng những cơ chế riêng để duy trì tính chính xác dù có nhiều đơn vị chỉ huy đồng thời. Ví dụ: Chúng có thể sử dụng cơ sở dữ liệu ngầm để đảm bảo rằng nếu có hai đơn vị chỉ huy đều cho rằng mình đang giữ hợp đồng thuê thì chúng sẽ không can thiệp lẫn nhau. Thay vì đưa ra giả định về các bảo đảm được cung cấp bởi việc triển khai hợp đồng thuê, chúng tôi tập trung vào tính chính xác ở những hệ thống này, thường qua việc xây dựng mô hình bằng các kỹ thuật như TLA+.

Dù còn nhiều bất cập, song chọn đơn vị chỉ huy vẫn là một công cụ hữu dụng trong bộ công cụ hệ thống phân tán tại Amazon, cùng với các mô hình như lũy đẳng và khóa tự do.

Để biết thêm thông tin về cách thức hoạt động của hợp đồng thuê, xem:

• Làm thế nào để thực hiện khóa phân tán
• Burrows, Dịch vụ khóa Chubby cho các hệ thống phân tán kết nối lỏng lẻo
• Gray và Cheriton, Hợp đồng thuê: Một cơ chế chịu lỗi hiệu quả cho tính nhất quán của bộ nhớ đệm tệp phân tán