Khả năng chịu lỗi giúp hệ thống tiếp tục hoạt động thế nào?

Cơ chế này thường dựa trên một chuỗi: phát hiện lỗi → cô lập thành phần lỗi → chuyển sang tài nguyên thay thế → duy trì hoặc khôi phục trạng thái cần thiết → phục hồi thành phần hỏng. Vì vậy, khả năng chịu lỗi không phải một tính năng đơn lẻ mà là đặc tính hình thành từ nhiều cơ chế phối hợp.

Khả năng chịu lỗi khác gì với việc hệ thống không xảy ra lỗi?

Hệ thống chịu lỗi vẫn có thể gặp lỗi ở máy chủ, tiến trình, kết nối mạng, cơ sở dữ liệu hoặc dịch vụ phụ thuộc. Khác biệt nằm ở hậu quả của lỗi đó.

Nếu một máy chủ xử lý yêu cầu bị hỏng và không có thành phần thay thế, dịch vụ có thể ngừng hoạt động. Trong hệ thống có khả năng chịu lỗi, yêu cầu có thể được chuyển sang một máy chủ khác đang sẵn sàng phục vụ. Người dùng có thể không nhận thấy sự cố, hoặc chỉ nhận thấy một mức suy giảm chức năng tạm thời.

Điều này tạo ra một phân biệt quan trọng:

·         Fault prevention: Cố gắng ngăn lỗi xảy ra

·         Fault tolerance: Giảm khả năng lỗi của một thành phần làm mất chức năng của toàn hệ thống

·         Recovery: Khôi phục thành phần hoặc dịch vụ sau khi lỗi xảy ra

·         High availability: Duy trì dịch vụ ở trạng thái sẵn sàng cao, thường nhờ nhiều cơ chế trong đó có khả năng chịu lỗi

Vì vậy, một hệ thống có độ sẵn sàng cao chưa chắc chịu được mọi loại lỗi. Khả năng chịu lỗi tập trung vào câu hỏi: “Nếu một thành phần hỏng ngay bây giờ, phần còn lại của hệ thống có tiếp tục thực hiện được chức năng cần thiết không?”

Cơ chế nào giúp hệ thống tiếp tục hoạt động khi một thành phần bị lỗi?

Cơ chế cốt lõi là loại bỏ sự phụ thuộc tuyệt đối vào một thành phần duy nhất. Hệ thống phải có khả năng thay thế hoặc bỏ qua thành phần đã lỗi.

Dự phòng

Dự phòng tạo ra nhiều tài nguyên có khả năng đảm nhiệm cùng một chức năng. Ví dụ, một dịch vụ có thể chạy trên nhiều máy chủ thay vì chỉ một máy chủ duy nhất.

Khi một máy chủ ngừng hoạt động, các máy chủ còn lại tiếp tục nhận tải. Dự phòng có thể được áp dụng ở nhiều lớp như máy chủ, mạng, nguồn điện, lưu trữ hoặc dịch vụ.

Tuy nhiên, chỉ có nhiều bản sao chưa đủ để tạo khả năng chịu lỗi. Nếu tất cả bản sao cùng phụ thuộc vào một nguồn điện, một mạng hoặc một cơ sở dữ liệu duy nhất, điểm lỗi chung vẫn có thể làm cả hệ thống ngừng hoạt động.

Phát hiện lỗi và health check

Hệ thống cần nhận biết khi một thành phần không còn hoạt động đúng. Health check, heartbeat, timeout hoặc các tín hiệu giám sát có thể được sử dụng để xác định thành phần nào đang không thể phục vụ.

Phát hiện lỗi phải đủ nhanh để hạn chế ảnh hưởng, nhưng cũng phải đủ chính xác để tránh coi nhầm một thành phần khỏe mạnh là bị lỗi. Nếu hệ thống chuyển đổi dự phòng dựa trên tín hiệu sai, chính cơ chế bảo vệ có thể tạo thêm sự cố.

Failover

Sau khi phát hiện lỗi, hệ thống có thể chuyển lưu lượng hoặc nhiệm vụ sang thành phần dự phòng. Đây là cơ chế failover.

Ví dụ, nếu một instance xử lý yêu cầu không còn phản hồi, bộ cân bằng tải có thể ngừng gửi yêu cầu mới đến instance đó và phân phối tải cho các instance còn lại.

Failover có thể được thực hiện tự động hoặc cần sự can thiệp của con người tùy kiến trúc. Điểm quan trọng là quá trình chuyển đổi phải được thiết kế từ trước thay vì chỉ tìm cách xử lý sau khi sự cố xảy ra.

Cô lập lỗi và graceful degradation

Không phải lỗi nào cũng cần khiến toàn bộ hệ thống dừng lại. Cô lập lỗi giúp giới hạn phạm vi ảnh hưởng của một thành phần hỏng.

Trong một số trường hợp, hệ thống có thể graceful degradation: tạm thời bỏ một chức năng phụ nhưng vẫn duy trì chức năng cốt lõi. Chẳng hạn, một dịch vụ có thể vẫn xử lý giao dịch chính dù chức năng thống kê hoặc một tính năng không thiết yếu đang tạm thời unavailable.

Cách tiếp cận này giúp biến một lỗi toàn hệ thống thành một mức suy giảm chức năng có kiểm soát.

Vì sao trạng thái dữ liệu quyết định khả năng chịu lỗi?

Chuyển sang một thành phần khác chỉ giải quyết được một phần vấn đề. Thành phần thay thế còn phải có đủ trạng thái cần thiết để tiếp tục xử lý.

Nếu một máy chủ bị lỗi giữa một giao dịch, máy chủ thay thế phải biết trạng thái giao dịch đến đâu. Với hệ thống lưu trữ, dữ liệu cũng phải được sao chép hoặc bảo vệ theo cơ chế phù hợp để một bản sao lỗi không làm mất dữ liệu cần thiết.

Các cơ chế thường liên quan gồm:

·         Replication để duy trì nhiều bản sao dữ liệu hoặc trạng thái

·         Consensus hoặc cơ chế phối hợp tương ứng khi nhiều nút cần thống nhất trạng thái

·         Transaction và tính nhất quán để tránh trạng thái nửa chừng

·         Idempotency để một thao tác được thử lại mà không gây ra tác động ngoài ý muốn

·         Backup và recovery để xử lý các tình huống mà replication không đủ bảo vệ

Điểm cần phân biệt là replication không đồng nghĩa với backup. Các bản sao có thể giúp dịch vụ tiếp tục hoạt động khi một nút gặp lỗi, nhưng nếu dữ liệu sai hoặc bị xóa nhầm được sao chép sang các bản sao khác, replication không tự động khôi phục được trạng thái đúng.

Khả năng chịu lỗi có những giới hạn và đánh đổi nào?

Khả năng chịu lỗi không có nghĩa hệ thống sẽ luôn hoạt động bất kể sự cố. Hiệu quả của nó phụ thuộc vào loại lỗi mà kiến trúc đã được thiết kế để chịu đựng.

Một hệ thống có thể chịu được lỗi của một máy chủ nhưng vẫn thất bại nếu:

·         Nhiều máy chủ cùng mất kết nối mạng

·         Một dependency dùng chung bị lỗi

·         Cấu hình sai được triển khai đồng thời trên nhiều instance

·         Cơ chế failover chuyển tải sang một thành phần không đủ năng lực

·         Dữ liệu bị hỏng hoặc bị ghi sai trên nhiều bản sao

·         Cơ chế phát hiện lỗi xác định sai trạng thái của hệ thống

·         Các thành phần dự phòng thực tế vẫn phụ thuộc vào cùng một điểm lỗi

Đây là lý do cần phân biệt lỗi độc lập và lỗi tương quan. Dự phòng có hiệu quả nhất khi các bản sao không cùng chịu chung một nguyên nhân gây lỗi.

Ngoài ra, khả năng chịu lỗi luôn có trade-off. Duy trì nhiều thành phần, sao chép dữ liệu, giám sát, kiểm thử failover và cơ chế phục hồi làm tăng độ phức tạp, chi phí vận hành và yêu cầu quản trị. Nếu thiết kế quá phức tạp, chính các cơ chế bảo vệ cũng có thể trở thành nguồn lỗi mới.

Thiết kế khả năng chịu lỗi nên bắt đầu từ đâu?

Một thiết kế có khả năng chịu lỗi không nên bắt đầu bằng việc đơn giản là “thêm máy chủ dự phòng”. Cần xác định trước thành phần nào có thể hỏng, chức năng nào phải tiếp tục và mức mất mát nào có thể chấp nhận.

Trình tự hợp lý là:

1.    Xác định failure mode: Liệt kê các thành phần và kiểu lỗi có thể xảy ra

2.    Xác định chức năng cốt lõi: Phân biệt chức năng bắt buộc phải duy trì với chức năng có thể tạm thời suy giảm

3.    Xác định failure boundary: Tìm các điểm lỗi chung có thể ảnh hưởng đồng thời đến nhiều thành phần

4.    Thiết kế redundancy: Bố trí tài nguyên thay thế ở đúng lớp có rủi ro

5.    Thiết kế detection và failover: Xác định cách phát hiện lỗi và chuyển dịch vụ sang thành phần thay thế

6.    Bảo vệ state: Đảm bảo dữ liệu và trạng thái cần thiết có thể được duy trì hoặc phục hồi

7.    Kiểm thử failure: Chủ động kiểm tra hệ thống khi thành phần thực sự bị loại khỏi hoạt động

8.    Xác định giới hạn phục hồi: Làm rõ yêu cầu về thời gian khôi phục và mức mất dữ liệu có thể chấp nhận

Một kiến trúc tốt vì thế không chỉ trả lời “có dự phòng hay không”, mà phải trả lời được cả “lỗi được phát hiện thế nào, chuyển đổi ra sao, trạng thái được bảo toàn thế nào và khi nào cơ chế này không còn hiệu quả”.

Khả năng chịu lỗi giúp hệ thống tiếp tục hoạt động bằng cách giảm sự phụ thuộc vào từng thành phần đơn lẻ và kiểm soát tác động của lỗi. Dự phòng cung cấp tài nguyên thay thế, health check phát hiện sự cố, failover chuyển chức năng sang thành phần còn hoạt động, cơ chế cô lập giới hạn phạm vi ảnh hưởng và replication hoặc recovery bảo vệ trạng thái cần thiết.

Tuy nhiên, khả năng chịu lỗi chỉ hiệu quả trong phạm vi các failure mode đã được thiết kế và kiểm thử. Vì vậy, mục tiêu thực tế không phải là xây dựng một hệ thống “không thể hỏng”, mà là xây dựng hệ thống trong đó một lỗi cục bộ không dễ dàng biến thành sự gián đoạn toàn cục.