1 Process Resilience (khả năng phục hồi của tiến trình)

1.2 Design Issues.

Phương pháp chính để xây dựng một hệ thống tin cậy là tổ chức vài tiến trình giống hệt nhau vào một nhóm. Khi có một bản tin được gửi đến nhóm, mọi thành viên trong nhóm sẽ nhận được bản tin đó. Theo cách này, nếu một tiến trình trong nhóm lỗi, hy vọng rằng các tiến trình khác vẫn hoạt động chính xác và đưa ra kết quả đúng cho cả nhóm.

Nhóm các tiến trình có thể là động. Những nhóm mới có thể được tạo ra và các nhóm cũ có thể bị loại bỏ. Một tiến trình có thể tham gia hoặc ra khỏi một nhóm trong suốt quá trình hoạt động của hệ thống. Một tiến trình có thể là thành viên của vài nhóm trong cùng một thời điểm. Do đó cần có những cơ chế để quản lý nhóm và quản lý các thành viên trong nhóm.

Một nhóm các tiến trình cũng gần tương tự như các tổ chức xã hội. Ngĩa là một tiến trình có thể tham gia vào một nhóm và trong trường hợp có nhiều nhóm cùng yêu cầu nó thực hiện một công việc nào đó, nó sẽ được tự do lựa chọn.

Flat Groups versus Hierarchical.

Trong một số nhóm, tất cả các tiến trình là ngang bằng nhau. Không có cái nào là boss và mọi quết định đều được thực hiện dựa theo tập thể. Trong những nhóm khác, một vài loại của kiến trúc phân tầng xuất hiện. Chẳng hạn một tiến trình đóng vài trò coordinator và tất cả các tiến trình khác là worker. Trong mô hình này, khi một yêu cầu cho một công việc nào đó được đưa đến, dù là yêu cầu của client bên ngoài hay của các workers trong nhóm đó đều được gửi đến coordinator. Corordinator sau đó quyết định worker nào thích hợp nhất để thực hiện nó và sẽ chuyển đến cho worker đó. 

Mỗi loại trong mô hình trên đều có những ưu và nhược điểm của nó. Flat group là cân đối và không có single point of failure. Nếu một trong những tiến trình đó bị lỗi, cả nhóm chỉ đơn giản là bị thu hẹp lại, nhưng vẫn có thể tiếp tục hoạt động. Nhược điểm của tổ chức này là quá trình đưa ra quyết định khá phức tạp. Chẳng hạn để quyết định bất kỳ một điều gì, đều phải tiến hành lựa chọn ý kiến giữa tất cả thành viên trong nhóm, dẫn đến tăng thời gian trễ và tốn tài nguyên.

Kiến trúc phân tầng có những đặc điểm ngược lại. Mất đi coordinator dẫn đến toàn bộ nhóm ngừng hoạt động nhưng khi coordinator hoạt động nó có thể tự đưa ra quyết định mà không làm phiền đến các thành viên khác.

Group Membership.

•Phương pháp sử dụng một máy chủ nhóm để nghe mọi yêu cầu.

•Phương pháp quản lý thành viên theo kiểu phân tán.

•Phương pháp lý tưởng, muốn rời khỏi một nhóm,mỗi thành viên chỉ cần gửi một thông điệp tạm biệt tới tất cả thành viên.

•Một thành viên trước khi rời khỏi nhóm sẽ gửi một chuỗi các bản tin thông báo tới toàn nhóm.

Flat Groups

Ưu điểm:Flat Group là cân xứng và không có điểm đơn bị lỗi.

Nhược điểm:Quá trình đưa ra quyết định khá phức tạp.

Hierarchical Groups

Ưu điểm:Đưa ra quyết định chỉ dựa vào Coordinator.

Nhược điểm: Không cân xứng và có điểm đơn bị lỗi.

1.2 Failure Masking and Replication.

Nhóm các tiến trình là một phần trong giải pháp xây dựng hệ thống chịu lỗi. Nói cụ thể, có một nhóm các tiến trình giống hệt nhau cho phép chúng ta che giấu một hoặc nhiều tiến trình lỗi trong nhóm. Nói cách khác, chúng ta có thể sao chép các tiến trình và tổ chức chúng thành một nhóm nhằm thay thế một tiến trình đơn lẻ (dễ bị lỗi) bằng một nhóm (có khả năng chịu lỗi hơn). Như đã thảo luận trong chương trước, có 2 cách để đạt được sự sao chép như vậy: primary-based protocols hoặc repilcated-write protocols.

Một vấn đề chính trong sử dụng nhóm các tiến trình để tăng tính chịu lỗi là cần có bao nhiêu bản sao của tiến trình thì đủ? Để đơn giản hóa, chúng ta chỉ quan tâm đến replicated-write systems. Một hệ thống được gọi là k fault tolerance nếu nó có thể hoạt động đúng với k phần tử (tiến trình) bị lỗi. Nếu có k tiến trình bị lỗi thì cần có k+1 tiến trình khác không bị lỗi để quá trình lựa chọn kết quả vẫn diễn ra chính xác.

1.3 Agreement in Fauty Systems.

Việc tổ chức các tiến trình giống nhau và cùng 1 nhóm giúp tăng khả năng chịu lỗi. Như đã đề cập ở trên, nếu một client có thể đưa ra quyết định của nó theo cơ chế bỏ phiếu, nó vẫn có thể đưa ra quyết định đúng nếu k trong số 2k+1 tiến trình hoạt động sai (k+1tiến trình còn lại vẫn hoạt động chính xác). Nói chung một vấn đề khó khăn đặt ra là khi chúng ta yêu cầu một nhóm các tiến trình đưa ra một sự thống nhất, chẳng hạn như lựa chọn ra một coordinator, thực hiện một giao dịch, phân chia công việc cho các workers.... Nếu tất cả các communication và processess là hoàn hảo thì dễ dàng đạt được sự thống nhất như vậy, nhưng nếu chúng không hoàn hảo thì sẽ nảy sinh những vấn đề khó khăn.

Mục tiêu chung của distributed agreement algorithms là có tất cả những tiến trình không lỗi đạt được sự nhất trí trong một số vấn đề, và thực hiện sự nhất trí ấy trong một số nhất định các bước. Vấn đề trở nên phức tạp bởi thực tế là các giả thuyết khác nhau về underlying system yêu cầu các giải pháp khác nhau. Turek và Shasha (1992) phân thành những trường hợp sau:

1.Đồng bộ và không đồng bộ. 

2.Communication delay là có giới hạn hay không? Delay là có giới hạn nếu và chỉ nếu chúng ta biết rằng mỗi bản tin được gửi đi với thời gian tối đa được xác định trước.

3.Việc chuyển các bản tin là có trật tự hay không? Nói cách khác chúng ta phân biệt tình huống liệu các bản tin từ cùng một máy gửi có được nhận theo đúng thứ tự nó được gửi hay không, với tình huống không có một cơ chế nào đảm bảo điều đó.

4.Việc truyền các bản tin là unicasting hay multicasting

Với các điều kiện trên, việc đạt được sự nhất trí giữa các tiến trình xảy ra như trong hình 8-4. Trong tất cả các trường hợp khác, không có giải pháp nào tồn tại. Chú ý rằng hầu hết các hệ phân tán trong thực tế đều giả sử rằng các tiến trình hoạt động không đồng bộ, các bản tin được truyền unicast, và delay là có giới hạn. Do đó, chúng ta phải truyển các bản tin theo thứ tự, giống như trong TCP. 

1.4 Failure Detection

Muốn che giấu lỗi, trước tiên chúng ta phải phát hiện được chúng. Phát hiện lỗi là một trong phần quan trọng của tính chịu lỗi. Tóm lại, trong một nhóm các tiến trình, các thành viên không lỗi phải có khả năng xác định những thành viên còn lại bị lỗi hay không. Nói cách khác, chúng phải có khả năng phát hiện khi có một tiến trình lỗi.

Có 2 phương pháp phát hiện ra các tiến trình bị lỗi. Một là tiến trình chủ đọng gửi bản tin “are you alive?” tới mỗi thành viên khác hoặc thụ động chờ bản tin được gửi đến từ các tiến trình khác. Phương pháp thụ động chỉ có ý nghĩa khi chắc chắn rằng có đầy đủ các kết nối giữa các tiến trình. Trong thực tế, thường sử dụng phương pháp chủ động.

Có nhiều lý thuyết về phát hiện lỗi nhưng tóm lại đều sử dụng cơ chế time out để kiểm tra xem liệu một tiến trình có bị lỗi không. Nhưng trong thực tế, trong hệ thống mạng không tin cậy, việc sử dụng phương pháp này sẽ đưa đến kết quả không chính xác.

Việc phát hiện lỗi cũng có thể thực hiện bằng cách trao đổi thông tin đều đặn với các neighbors. Các tiến trình đều đặn thông báo các dịch vụ mà nó đang cung cấp. Thông tin này được truyền đi từ từ trong mạng thông qua các neighbor. Cuối cùng, mỗi tiến trình sẽ biết về mỗi tiến trình khác và có thể xác định một tiến trình có bị lỗi hay không.

Một vấn đề quan trọng khác là failure detection subsystem cần phân biệt được giữa các lỗi thuộc về hệ thống mạng với lỗi của các tiến trình. Một cách để xử lý vấn đề này là không để một tiến trình đơn lẻ tự ý quyết định neighbor của nó có lỗi hay không. Thay vào đó, khi một node phát hiện một không ping được đến một neigbor, nó sẽ yêu cầu các neighbor khác xác định xem liệu chúng có thể ping đến neighbor đó không, sau đó sẽ thông báo kết quả đến node này.