fault tolerance-làm rõ đối với web-based systems

fault tolerance-làm rõ đối với web-based systems

HỌC VIỆN KỸ THUẬT QUÂN SỰ

KHOA CÔNG NGHỆ THÔNG TIN

˜ & ™

-BÀI TẬP LỚN

MÔN LÝ THUYẾT HỆ PHÂN TÁN

Đề tài (Nhóm 14): "Fault tolerance - làm rõ đối với

Hà Nội - 05/2014

Fault Tolerance

Tính chịu lỗi

Một tính năng đặc trưng của hệ thống phân tán để phân biệt chúng từ các

hệ thống độc lập là khái niệm của các thành phần lỗi Một lỗi có thể xảy ra khimột thành phần trong một hệ thống phân tán bị hỏng Lỗi này có thể ảnh hưởngtới hoạt động riêng của các thành phần khác, trong khi tại cùng một thời điểmđấy nhưng các thành phần khác hoàn toàn không bị ảnh hưởng Ngược lại mộtlỗi trong một hệ thống không được phân tán thì sẽ thường ảnh hưởng tới tất cảcác thành phần khác Và có thể dễ dàng ảnh hưởng tới toàn bộ hệ thống

Một phần quan trọng của hệ thống phân tán được thiết kế ra đó là xâydựng hệ thống như một cách mà nó có thể tự động khôi phục từ các thành phầnlỗi mà không ảnh hưởng tới hiệu năng hoạt động của toàn bộ hệ thống Đặc biệt,bất cứ khi nào khi có một lỗi xảy ra thì hệ thống vẫn tiếp tục hoạt động trongkhi quá trình sửa chữa vẫn đang được tiến hành, có nghĩa là khả năng chịu đựnglỗi và hoạt động với một số mức độ trọng sự hiện diện của chúng

Trong chương này chúng ta sẽ xem xét kỹ hơn các kỹ thuật để tạo ra một

hệ thống phân tán có khả năng chống chịu lỗi Sau khi cung cấp một nền tảngchung về khả năng chịu lỗi, chúng ta sẽ sẽ xem xét khả năng phục hồi và quátrình truyền dữ liệu multicasting đáng tin cậy Quá trình phục hồi kết hợp chặtchẽ các kỹ thuật bởi một hoặc nhiều tiến trình có thể thất bại mà không làm ảnhhưởng nghiêm trọng tới phần còn lại của hệ thống Liên quan tới vấn đề này đó

là quá trình truyền dữ liệu đáng tin cậỵ multicasting bằng cách các thông điệpđược truyền tải tới một nhóm bộ xử lý đảm bảo đã thành công Quá trình truyền

dữ liệu đáng tin cậy multicasting thường cần thiết để giữ cho các tiến trình đượcđồng bộ

Atomicity là một thuộc tính qua trọng trong nhiều ứng dụng Ví dụ, trongcác quá trình truyền phân tán nó thực sự là cần thiết để đảm bảo rằng tất cả cáchoạt động trong một quá trình được truyền đi được thực hiện Về cơ bảnatomicity trong các hệ phân tán là một khái niệm về các giao thức phân tán đượccam kết, sẽ được thảo luận trong một phần riêng biệt trong chương này

Cuối cùng, chúng tôi sẽ xem xét làm thế nào để khôi phục từ một lỗi Đặcbiệt chúng ta sẽ xem xét khi nào và làm thế nào để trạng thái của môt hệ thống

phân tán nên được lưu trữ lại để cho phép khôi phục lại trạng thái sau này

8.1 Giới thiệu về Fault Tolerance

Khả năng chống chịu lỗi như là một chủ đề đã được nghiên cứu nhiềutrong khoa học máy tính Trong phần này, chúng ta sẽ bắt đầu được làm quenvới các khái niệm cơ bản lien quan tới tiến trình xử lý các lỗi, theo chỉ dẫn bằngcách thảo luận về các kiểu lỗi Kỹ thuật quan trọng để xử lý các lỗi đó là khảnăng dự phòng, cũng sẽ được thảo thuận trong phần kế tiếp sau Để tham khảothêm thông tin về khả năng chống chịu lỗi của hệ thống phân tán, ví dụ Jalote(1994) hoặc (Shooman, 2002)

8.1.1 Các khái niệm cơ bản

Để hiểu được vai trò về khả năng chống chịu lỗi của hệ thống phân tánđầu tiên chúng ta cần có một cái nhìn gần hơn vào những gì nó thực sự có nghĩa

về khả năng chống chịu lỗi của một hệ thống phân tán Khả năng chống chịu lỗiliên quan nhiều đến những gì gọi là hệ thống đáng tin cậy Độ tin cậy là mộtthuật ngữ bao gồm một số các yêu cầu hữu ích cho các hệ thống phân tán baogồm những yêu cầu sau (Kopetz and Verissimo, 1993):

có tính sẵn sàng cao khi nó đáp ứng được ngay lập tức khi thời gian yêu cầu đưara

Tính tin cậy nghĩa là hệ thống có thể chạy liên tục mà không phát sinh lỗi.Khác với tính sẵn sàng, một hệ thống tin cậy cao là một hệ thống có thể hoạtđộng liên tục mà không có bất kỳ một sự gián đoạn nào trong một khoảng thờigian dài Đây là một sự khác biệt khó nhận ra nhưng rất quan trọng khi đem sosánh với tính sẵn sàng Nếu một hệ thống ở trạng thái down 1 milisecond mỗi

giờ, tính sẵn sàng của nó đạt đến 99.9999 phần trăm nhưng vẫn là một hệ thốngkhông tin cậy Ngược lại một hệ thống không bao giờ đổ vỡ nhưng luôn luôn ởtrạng thái down trong 2 tuần của tháng 8 là một hệ thống tin cậy cao nhưng lạichỉ đạt được 96% sẵn sàng Tính tin cậy và tính sẵn sàng không giống nhau

Tính an toàn thể hiện ở chỗ khi hệ thống tạm thời bị lỗi, không có thiệthại nghiêm trọng nào xảy ra Chẳng hạn nhiều hệ thống điều khiển tiến trình như

hệ thống dùng để điều khiển nhà máy hạt nhân hay đưa con người vào vũ trụyêu cầu độ an toàn cao Nếu hệ thống điều khiển chỉ bị lỗi trong một khoảngthời gian rất ngắn, hậu quả có thể rất thảm khốc Nhiều ví dụ trong quá khứ đãchứng tỏ rất khó để xây dựng một hệ thống an toàn

Cuối cùng, tính duy trì thể hiện ở chỗ một hệ thống lỗi có thể được sửamột cách dễ dàng Một hệ thống có tính duy trì cao sẽ có tính sẵn sàng cao, đặcbiệt là nều lỗi có thể được phát hiện và sửa chữa một cách tự động Tuy nhiênnhư chúng ta sẽ thấy sau trong chương này, việc tự động phục hồi lỗi là rất khó

Thông thường một hệ thống đáng tin cậy còn đòi hỏi phải cung cấp được

độ an ninh an toàn cao, đặc biệt khi nó đi đến vấn đề như tính toàn vẹn Chúng

ta sẽ thảo luận về sự an ninh, an toàn trong chương tiếp theo

Một hệ thống bị coi là lỗi khi nó không thể thực hiện được những chứcnăng thông thường của nó Cụ thể nếu một hệ phân tán được thiết kế để cungcấp một số những dịch vụ, hệ thống lỗi khi nó không thể cung cấp được mộttrong những dịch vụ đó Ví dụ khi truyền một gói tin qua mạng, nó có thể bị rớtgói tin khi tới phía đầu người nhận Quá trình gói tin bị hư hỏng có nghĩa là phíađầu người nhận đã nhận những thông tin không chính xác các bít 0 và 1

Rõ ràng việc tìm ra nguyên nhân gây lỗi là rất quan trọng Chẳng hạn mộtmôi trường truyền không tốt có thể dễ dàng ảnh hưởng đến Trong trường hợpnày, xóa bỏ lỗi là khá dễ dàng Tuy nhiên lỗi do truyền có thể bị gây ra bởi điềukiện thời tiết xấu (ví dụ trong mạng wireless) Thay đổi thời tiết để ngăn chặn lỗi

là một giải pháp không khả thi

Việc xây dựng một hệ thống có thể tin cậy được liên quan chặt chẽ đếnviệc xử lý lỗi Một khác biệt có thể được thực hiện giữa phòng ngừa, loại bỏ, và

dự báo các lỗi (Avizieniset al., 2004) Với chúng ta, điều quan trọng nhất là tínhchịu lỗi, nghĩa là hệ thống có thể cung cấp các dịch vụ trong khi vấn tồn tại lỗi.Nói cách khác, hệ thống có thể chịu lỗi và tiếp tục hoạt động một cách bình

thường

Lỗi thường được chia thành 3 loại: nhất thời, liên tiếp hoặc lâu dài Lỗinhất thời chỉ xuất hiện một lần rồi biến mất Nếu quá trình hoạt động lặp lại, lỗikhông xuất hiện nữa Ví dụ, một con chim bay qua bay qua một máy phát sóng

có thể gây ra mất bit tín hiệu trên một số mạng lưới Nếu trong thời gian truyền

và được thử lại thì nó sẽ lại hoạt động bình thường trở lại trong một vài giây

Lỗi liên tiếp là tình trạng hoạt động không ổn định, lỗi lặp đi lặp lại nhiềulần Lỗi liên tiếp là nguyên nhân của những hậu quả nghiêm trọng vì khó tìmđược nguyên nhân Thông thường khi có lỗi thì các chuyên gia sẽ có mặt khắcphục sự cố và hệ thống lại hoạt động tốt

Lỗi lâu dài là lỗi chỉ được khắc phục khi thành phần gây lỗi được thaythế, ví dụ như cháy nổ chip, lỗi phần mềm, lỗi ổ đĩa

ra lỗi mà chúng ta đang mắc phải Nếu một server phụ thuộc vào các server khác

để cung cấp đầy đủ các dịch vụ của nó, nguyên nhân của lỗi có thể cần phảiđược tìm kiếm ở những nơi khác nữa ngoài server đó, mặc dù server đó bị lỗi

Mối quan hệ phụ thuộc đó xuất hiện rất thường xuyên trong hệ phân tán.Một đĩa cứng bị lỗi có thể ảnh hưởng đến một file server được thiết kế để cungcấp hệ thống file có tính sẵn sàng cao Nếu một file server như vậy là một phầncủa một hệ cơ sở dữ liệu phân tán, sự hoạt động chính xác của hệ toàn bộ hệ cơ

sở dữ liệu có thể bị đe dọa và chỉ một phần dữ liệu là có thể truy cập được

Để hiểu rõ hơn thực tế một lỗi là nghiêm trọng đến mức nào, người ta đãđưa ra một vài cách phân loại Một trong số đó được chỉ ra trong hình 8-1 nhưsau, và cơ sở dựa trên đề án được mô tả trong Cristian (1991) và Hadzilacos vàToueg (1993)

Lỗi bị treo Một máy chủ tạm dừng, nhưng nó vẫn hoạt động

chính xác cho tới khi nó tạm dừngLỗi thiếu sót

Nhận thiếu sót

Gửi thiếu sót

Một máy chủ bị lỗi đáp ứng các yêu cầu gửi tớiMột máy chủ bị lỗi nhận các thông tin gửi tớiMột máy chủ bị lỗi gửi các thông tin

Lỗi về thời gian Đáp ứng của một máy chủ nằm phía ngoài khoảng

thời gian quy địnhĐáp ứng bị lỗi

Các máy chủ đi chệch khỏi sự kiểm soát chính xác

Lỗi tùy ý Một máy chủ có thể xử lý nhiều đáp ứng tùy ý tại bất

kỳ thời điểm nàoHình 8-1 Các kiểu lỗiLỗi bị treo xảy ra khi một server ngừng hoạt động sớm hơn mong đợi,nhưng vẫn làm việc chính xác cho đến khi nó dừng Một ví dụ điển hình củatrường hợp này là khi hệ điều hành gặp phải một lỗi nghiêm trọng, và chỉ có mộtgiải pháp duy nhất là khởi động lại nó Nhiều hệ thống máy tính cá nhân gặpphải lỗi bị treo thường xuyên đến nỗi mọi người phải cho rằng đó là chuyệnbình thường Đó là lí do người ta đã chuyển phím reset của máy tính cá nhân từmặt sau ra mặt trước của cây máy tính Có lẽ một ngày nào đó nó sẽ đượcchuyển lại ra phía sau, hoặc thậm chí bị loại bỏ hoàn toàn

Lỗi Omission failure xảy ra khi server không có khả năng phản hồi hoặcnhận các yêu cầu Trong trường hợp lỗi nhận các yêu cầu, có khả năng serverkhông bao giờ nhận được yêu cầu ngay trong lần đầu tiên Chú ý rằng có thể kếtnối giữa client và server có thể đã được tạo ra nhưng không có luông nào lắngnghe các request đến Hơn nữa lỗi nhận các yêu cầu nói chung sẽ không ảnhhưởng đến trạng thái của server vì server chỉ không nhận biết được rằng cóthông điệp gửi cho nó

Tương tự như vậy, lỗi gửi các bản tin xảy ra khi server đã hoàn thànhcông việc của nó, nhưng vì một lý do nào đó mà không thể gửi được phản hồi.Những lỗi như vậy có thể xảy ra, chẳng hạn khi gửi buffer overflows trong khiserver không được chuẩn bị cho tình huống đó Chú ý rằng ngược với lỗi nhậnyêu cầu, server hiện tại có thể ở trạng thái chỉ ra rằng nó đã thực hiện xong mộtdịch vụ cho một client Do đó nếu việc phản hồi các yêu cầu không được hoàntất, client phải gửi lại các yêu cầu của nó

Một loại lỗi omission failure khác không liên quan đến kết nối có thể gây

ra bởi các lỗi phần mềm như vòng lặp vô tận hoặc quản lý bộ nhớ không hợp lýdẫn đến server bị treo

Một loại lỗi khác là timing failure Timing failure xảy ra khi bản tin phảnhồi được gửi đi trong một khoảng thời gian không thích hợp Như chúng ta đãbiết trong chương 4, gửi dữ liệu quá sớm có thể dễ dàng gây ra rắc rối cho phíanhận nếu máy nhận không đủ không gian bộ nhớ đệm để lưu giữ tất cả các dữliệu đến Tuy nhiên thực tế thường xảy ra trường hợp server phản hồi quá chậmdẫn đến giảm hiệu năng của hệ thống

Một loại lỗi nghiêm trọng nữa là lỗi respond failure, nghĩa là các bản tinphản hồi của server không thích hợp Có 2 loại lỗi phản hồi có thể xảy ra làvalue failure và state transition failure Value failure là khi server cung cấp cácphản hồi sai cho một yêu cầu nào đó Chẳng hạn một serach engine đưa ra kếtquả tìm kiếm các trang web không liên quan gì tới các từ khóa tìm kiếm Statetransition failure xảy ra nếu không có tiêu chuẩn nào được đưa ra để điều khiểncác bản tin Cụ thể là trong trường hợp một server lỗi có thể có những quyếtđịnh mặc định không hợp lý

Lỗi nghiêm trọng nhất là arbitrary failure, còn được biết đến như làByzantine failure Lỗi này có thể xảy ra khi server tạo ra những output mà khibình thường nó không bao giờ tạo ra, sau đó kết hợp với những server khác đểtại ra những câu trả lời sai Lỗi Arbitrary failure có quan hệ chặt chẽ với lỗicrash failure Crash failure còn được gọi là fail-stop failure, nó là loại lỗi ít gâythiệt hại nhất khi server ngừng hoạt động Trong thực tế, fail-stop failure server

sẽ ngừng tạo ra những output nhờ đó mà các tiến trình khác có thể nhận thấyđược sự ngừng hoạt động của nó Trong trường hợp tốt nhất, server có thể thôngbáo rằng nó sắp ngừng hoạt động

Dĩ nhiên trong thực tế, những server ngừng hoạt động do omission failure

và crash failure sẽ không báo trước rằng nó chuẩn bị ngừng hoạt động Các tiếntrình khác sẽ có nhiệm vụ xác định rằng server đó đã ngừng Tuy nhiên trongcác fail-silent systems như vậy, các tiến trình khác có thể không biết là server đãngừng hoạt động, thay vào đó nghĩ rằng server đó đột nhiên chạy chậm, dẫn đếnperformance failure

Cuối cùng, có nhiều trường hợp mà server đưa ra những output ngẫunhiên, nhưng output này có thể nhận biết được bởi những tiến trình khác Servernhư vậy thể hiện arbitrary failure nhưng theo một cách vô hại Lỗi này cũngđược gọi là fail-safe

8.1.3 Failure Masking by Redundancy (Che giấu lỗi bằng dư thừa).

Nếu một hệ thống được coi là có khả năng chịu lỗi, nó phải có khả năngche giấu những lỗi xảy ta với các tiến trình khác Kỹ thuật chính để che giấu lỗi

là sử dụng sự dư thừa Có 3 loại có thể thực hiện được là: informationredundancy (dư thừa thông tin), time redundancy (dư thừa thời gian), vàphysical redundancy (Dư thừa vật lý) Information redundancy là dùng một sốbit dư thừa được thêm vào để cho phép phục hồi lại dữ liệu từ dữ liệu lỗi Chẳnghạn Hamming code có thể được thêm vào dữ liệu được truyền đi để bù lại nhiễutrên đường truyền

Time redundancy nghĩa là một hành động được thực hiện, sau đó nếu cầnthiết nó sẽ được thực hiện lại một lần nữa Các giao dịch sử dụng phương phápnày (Chương 1) Nếu một giao dịch bị bỏ qua, nó có thể được thực hiện lại màkhông có tổn hại gì Time redundancy tỏ ra đặc biệt hữu ích khi lỗi là tạm thờihoặc không liên tục

Physical redundancy nghĩa là các tiến trình hoặc thiết bị dự phòng đượcthêm vào giúp cho hệ thống hoàn thiện để chống lại sực thiếu hoặc hoạt động saichức năng của một số thiết bị Do vậy physical redundancy có thể được thựchiện dựa theo phần cứng hoặc phần mềm Chẳng hạn các tiến trình dự phòng cóthể được thêm vào hệ thống để đề phòng trường hợp nếu có một số nhỏ trong sốchúng gặp vấn đề, hệ thống vẫn có thể hoạt động chính xác Nói cách khác, bằngcách sao chép các tiến trình, có thể đạt được khả năng chịu lỗi cao

Chúng ta sẽ minh họa về sự áp dụng của physical redundancy như hình

8-2 ở trên Theo hình 8-8-2a tín hiệu sẽ đi qua A,B,C theo thứ tự Nếu một trong 3thiết bị đó bị lỗi, kết quả cuối cùng có thể không chính xác Trong hình 8-2b,mỗi thiết bị được sao chép lại thành 3 bản Tín hiệu lúc này sẽ không chỉ đi quathiết bị A mà đi qua 3 thiết bị A1, A2, A3 giống hệt thiết bị A Các tín hiệuoutput sẽ được đưa và các bộ so sánh V1, V2, V3 Mỗi mạch so sánh này sẽ sosánh 3 tín hiệu A1, A2, A3 nếu 2 trong 3 output qua 3 thiết bị trên là giống nhauthì sẽ lấy tín hiệu đó, cón nếu cả 3 tín hiệu khác nhau thì output sẽ không xácđịnh Thiết kế như vậy được gọi là TMR (Triple Modular Redundancy)

Giả sử rằng thiết bị Az nào đó bị lỗi, vẫn còn 2 thiết bị khác hoạt độngđúng và hệ thống vẫn là tin cậy Về bản chất, việc Az bị lỗi là hoàn toàn đượcche đậy, vì vậy tín hiệu input cho B1, B2, B3 vẫn chính xác như trường hợp Azkhông hề bị lỗi

Trong trường hợp cả B3 và C1 nữa cũng bị lỗi thì sao? Sự tác động của nócũng được che dấu tốt và hệ thống vẫn hoạt động bình thường

Một điều nữa là tại sao tại mỗi modul phải có tận 3 voter? Hiển nhiên làcác voter này cũng là các thiết bị bình thường và cũng có khả năng xảy ra lỗi.Việc thiết kế 3 voter như vậy nhằm mục đích khi một thiết bị hỏng sẽ không ảnhhưởng đến sự hoạt động của hệ thống

Mặc dù không phải mọi hệ phân tán có khả năng chịu lỗi đều sử dụngTMR nhưng kỹ thuật đó là rất phổ biến để cung cấp một cái nhìn rõ ràng về một

hệ thống có khả năng chịu lỗi

8.2 Process Resilience (Khôi phục tiến trình)

Vấn đề cơ bản của khả năng chịu lỗi đã được thảo luận ở trên, bây giờchúng ta sẽ tập trung vào cách thức tiến hành để có thể đạt được khả năng chịulỗi trong hệ phân tán Phần trên chúng ta tập trung vào cách thức ngăn chặn lỗixảy ra, trong phần này chúng ta sẽ xem xét những vần đề thiết kế chung củanhóm các tiến trình, và tìm hiểu thế nào là một nhóm có khả năng chịu lỗi.Ngoài ra, chúng ta cũng xem xét cách thức hoạt động khi một hoặc một vài tiếntrình trong nhóm bị lỗi

8.2.1 Thiết kế đưa ra.

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ếntrì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ọithành viên trong nhóm sẽ nhận được bản tin đó Theo cách này, nếu một tiếntrì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 (Guerraoui và Schiper, 1997)

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ộtnhó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ànhviê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ềunhó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ựachọn

Mục đích của việc giới thiệu những nhóm sẽ cho phép

Flat Groups versus Hierarchical.

Một phân tích quan trọng sự khác biệt giữa các nhóm đó là cấu trúc bêntrong của chúng 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à quyết định chính và mọi quyết định đều được thực hiện dựatheo 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ấthiệ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ìnhkhá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

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

Nhóm thành viên

Khi một nhóm đang tồn tại, cần có một vài phương pháp để tạo hoặc xóanhóm và cho phép một tiến trình tham gia hoặc rời bỏ nhóm Một phương phápkhả thi là có một group server nhận mọi yêu cầu Group server có thể duy trìmột cơ sở dữ liệu đầy đủ của tất cả các group và các thành viên của nó Phươngpháp này dễ hiểu, hiệu quả và khá dễ thực hiện Tuy nhiên nhược điểm của nó

kỹ là tồn tại single point of failure Nếu nhóm Server bị treo, nhóm quản trịngừng tồn tại Điều đó chứng tỏ hầu hết các nhóm sẽ tự tái lại cấu trúc từ cácthành phần

Phương pháp ngược lại là quản lý các thành viên của nhóm theo phương

Một vấn đề khó khăn nữa là việc tham gia hoặc rời bỏ một group phảiđược động bộ hóa với các bản tin được gửi đi Nói cách khác, ngay tại thời điểmbắt đầu tham gia vào một nhóm, nó phải nhận tất cả các bản tin được gửi đếncho nhóm Tương tự như vậy, ngay sau khi rời khỏi nhóm, nó không được nhậnthêm bất kỳ một bản tin nào từ nhóm và cũng không được gửi bất kỳ một bản tinnào khác cho các thành viên trong nhóm Một phương pháp để thực hiện vấn đềtrên là khi một thành viên chuẩn bị rời nhóm, sẽ có một chuỗi bản tin thông báogửi đến cho toàn nhóm.

Vấn đề cuối cùng liên quan đến nhóm thành viên là cần phải làm gì khi cóquá nhiều thành viên trong nhóm cùng down 1 lúc và group không thể hoạt độngđược nữa Một và giao thức cần được thực hiện để xây dựng lại nhóm Lúc nàocũng vậy, một vài tiến trình sẽ phải hành động để bắt đầu xây dựng lại nhóm.Nhưng điều gì xảy ra nếu có 2 hoặc 3 cùng cố gắng xây dựng lại nhóm 1 lúc?Giao thức phải có khả năng đảm bảo điều đó không xảy ra

8.2.2 Failure Masking and Replication (Che giấu lỗi và sao lưu).

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ịulỗ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 chegiấ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ếntrì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ảoluậ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 faulttolerance 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ó ktiế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ọnkết quả vẫn diễn ra chính xác

8.2.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áctiế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áccommunication và processess là hoàn hảo thì dễ dàng đạt được sự thống nhấtnhư 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ữngtiế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ácnhau 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ớihạ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ácchú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ó đượcnhậ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ìnhhoạt động không đồng bộ, các bản tin được truyền unicast, và delay là có giớihạn Do đó, chúng ta phải truyển các bản tin theo thứ tự, giống như trong TCP

Trong hình 8-5 chúng tôi minh họa quá trình làm việc của thuật thuật toánvới trường hợp N=4 và K=1 Với các tham số đã cho như trên thì thuật toán sẽhoạt động trong 4 bước Trong bước 1 mọi Nonfault xử lý i gửi vi đến mọi tiếntrình xử lý khác sử dụng truyền dạng unicasting tin cậy Tiến trình xử lý lỗi cóthể không truyền bất cứ thông tin gì Bắt đầu vi=i, Trong hình 8-5(a) chúng ta cóthể nhìn thấy tiến trình xử lý 1 report 1, process2 report 2, process 3 nằm trongthành phần x,y,z, và process 4 report 4 Trong bước 2 kết quả là của bước 1 với

sơ đồ véc tơ như trong hình 8-5(b)

Bước 3 bao gồm tất cả các quá trình đi qua véc tơ từ hình 8-5(b) đến cácquá trình xử lý khác Bằng cách này thì mỗi quá trình sẽ có được 3 véc tơ Kếtquả của bước 3 được thể hiện trong hình 8-5(c) Cuối cùng ở bước 4 mỗi quátrình được xem xét thành phần thứ i của mỗi véc tơ mới nhận được Nếu mỗimột giá trị là chính, thì giá trị đó sẽ được đưa vào véc tơ kết quả Nếu giá trị đókhông phải là chính thì véc tơ kết quả sẽ được đánh dấu UNKNOWN Từ hình8-5(c) chúng ta thấy 1,2 và 4 tất cả đều nhận giá trị VI, v 2 và v 4 là kết quảchính xác

Bây giờ chúng ta sẽ xem xét lại vấn đề này với giá trị N=3 và K=1, cónghĩa là chỉ có 2 nonefaulty xử lý và một bị lỗi như mô tả trong hình 8-6 Tronghình 8-6(c) không phải các quá trình xử lý một cách chính xác khi nhìn thấy cácphần tử chính element 1, element 2, hoặc element 3, do đó sẽ được đánh dấuUNKNOWN Các thuật toán đã sai trong quá trình bắt tay thỏa thuận với nhau

8.2.4 Phát hiện lỗi

Muốn che giấu lỗi, trước tiên chúng ta phải phát hiện được chúng Pháthiệ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ómcá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ànhviê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ệnkhi có một tiến trình lỗi

Khi nói đến việc phát hiện lỗi, có hai cách phát hiện ra các tiến trình bịlỗi Hoặc là tiến trình chủ động gửi tin nhắn: "are you alive?" tới từng thành viênkhác hoặc thụ động chờ tin nhắn từ một tiến trình khác Phương pháp thụ độngchỉ có ý nghĩa khi chắc chắn có đầy đủ các kết nối giữa các tiến trình Trongthực tế, thường sử dụng phương pháp chủ động

Có rất 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ế, có hai vấn đề lớn với cách tiếp cận này Trước tiên, do các mạng không antoàn, đơn giản như một tiến trình bị lỗi vì nó không gửi về một phản hồi nào chotin nhắn ping Nói cách khác, nó khá dễ cho kết quả sai Nếu kết quả sai đó tácđộng đến một tiến trình bình thường trong tập hợp danh sách các tiến trình thànhviên thì rõ ràng các công việc chúng ta đang thực hiện cũng sai theo

Một vấn đề nghiêm trọng khác là thời gian chờ Theo Birman (2005), hầunhư không có bất kỳ việc gì hoạt hoạt động bằng việc tạo ra các hệ phát hiện lỗinhỏ không phù hợp mà được tính toán lâu hơn là phản hồi với 1 thông tin Điềunày thậm chí còn là 1 minh chứng rõ rang hơn khi nhìn vào hệ thống mạngkhông tin cậy Còn nhiều vấn đề mà cần phải được tính đến khi thiết kế hệ thốngphát hiện lỗi nhỏ Ví dụ, việc phát hiện lỗi có thể được thực hiện thông qua việctrao đổi thông tin đều đặn giữa các nút gần nhau, trong đó các nút thường xuyêngửi thông báo đến các nút lân cận rằng nó vẫn đang tồn tại và hoạt động Nhưchúng ta đã thấy, cách này đã cho phép các nút có thể chủ động kiểm tra lẫnnhau

Phát hiện lỗi cũng có thể được thực hiện như một tác động thứ yếu traođổi thông tin thường xuyên với các nút lân cận, giống như trường hợp dựa vàotrao đổi thông tin mà chúng ta đã thảo luận ở chương 4 Cách tiếp cận này về cơbản cũng được thông qua tại Obduro (Vogels, 2003): xử lý định kỳ tin đồn cósẵn dịch vụ của họ Thông tin này đang dần phổ biến qua mạng bằng cách traođổi thông tin Cuối cùng, mọi quá trình sẽ biết về tất cả các quá trình khác,nhưng quan trọng hơn cả là quá trình này sẽ có đủ thông tin cục bộ để quyếtđịnh xem một quá trình đã bị lỗi hay không Một yếu tố khác đối với các thôngtin sẵn có là cũ, có lẽ đã thất baị

Một vấn đề quan trọng khác là hệ thống phát hiện lỗi cần phân biệt đượcgiữ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 không ping được đến mộtneigbor, 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 Tất nhiên cácthông tin xác thực có thể được chia sẻ: nếu nút đó vẫn còn tồn tại, thông tin cóthể được chuyển tiếp cho những người có liên quan khác (những người có thểphát hiện lỗi đường truyền nếu có nghi ngờ)

Điều này mang đến cho chúng ta một vấn đề quan trọng khác: Khi mộtthành phần bị lỗi, các tiến trình báo lỗi khác sẽ được thông báo như thế nào?Một cách đơn giản, cách thức này được thể hiện trong FUSE Trong Fuse, tiếntrình có thể được gia nhập một nhóm có phạm vi trong một mạng diện rộng Cácthành viên của nhóm tạo ra một mạng lưới được sử dụng để theo dõi các thànhviên bị lỗi Các thành viên gửi các tin nhắn ping đến hàng xóm của mình Khimột nút lân cận không phản hồi, nút ping ngay lập tức chuyển sang trang tháikhác mà ở đó nó cũng không trả lời phản hồi của những nút khác Đệ quy đượcxem là một thất bại nút duy nhất, nhanh chóng đưa ra một thông báo thất bại củanhóm FUSE không chịu nhiều thất bại cho lí do đơn giản rằng nó dựa trênđiểm-điểm kết nối TCP giữa các thành viên trong nhóm FUSE không bị ảnhhưởng nhiều bởi lỗi liên kết với lý do đơn giản vì nó dựa trên phương thức kết

nối điểm-điểm kết nối giữa các thành viên trong nhóm

8.3 Che giấu lỗi trong truyền thông client/server tin cậy.

Trong nhiều trường hợp, tính chịu lỗi trong hệ phân tán tập trung chủ yếuvào các tiến trình lỗi Tuy nhiên chúng ta cũng phải xét đến trường hợp các giaotiếp bị lỗi Thông thường, một kênh giao tiếp có thể gặp các lỗi: lỗi sụp đổ, lỗi

bỏ sót, lỗi thời gian và lỗi tùy ý Việc xây dựng một kênh truyền thông tập trungvào che giấu lỗi sụp đổ và lỗi tùy ý Lỗi tùy ý có thể xảy ra dưới dạng các tinnhắn trùng lặp, kết quả thực tế cho thấy trong một mạng máy tính tin nhắn cóthể được lưu ở bộ nhớ đệm trong một khoảng thời gian tương đối lâu và đượcđưa vào mạng sau khi máy gửi tin nhắn đầu đầu tiên đã sẵn sàng truyền lại (xem

ví dụ Tanenbaum 2003)

8.3.1 Truyền thông điểm – điểm

Trong nhiều hệ phân tán, truyền thông điểm – điểm tin cậy được thiết lậpbằng cách sử dụng các giao thức truyền tin cậy như TCP TCP che giấu được lỗi

bỏ sót, lỗi xảy ra dưới dạng mất tin nhắn, bằng cách dùng cơ chế thông báoACK/NACK (xác nhận) và việc thực hiện truyền lại Lỗi như vậy là được chedấu hoàn toàn với máy trạm TCP

Tuy nhiên, TCP không che giấu được lỗi sụp đổ Một lỗi sụp đổ có thểxảy ra khi (vì bất cứ lý do gì) một kết nối TCP bị hủy đột ngột do đó không cómột tin nhắn nào được truyền đi trên đường truyền Trong hầu hết các trườnghợp, máy trạm được thông báo rằng đường truyền đã bị sụp đổ do sinh ra trườnghợp ngoại lệ Cách duy nhất để che giấu lỗi sụp đổ là hệ thống phải có khả năng

tự động tạo một kết nối mới, chỉ đơn giản bằng cách gửi lại một yêu cầu kết nối.Giả thiết cơ sở rằng có một side nào đó vẫn tồn tại, hay phục hồi, lời yêu cầu sẽđược phản hồi

8.3.2 RPC khi xảy ra lỗi và cách khắc phục

Với hệ thống RPC, năm lớp lỗi có thể xảy ra là:

- Client không thể định vị được server: Nguyên nhân gây lỗi là do server và

client dùng các phiên bản khác nhau hoặc do chính server bị lỗi Khắc phụcbằng cách sử dụng các ngoại lệ (exception) để bắt lỗi như ở ngôn ngữ java vàđiều khiển tín hiệu (signal handle) như ở ngôn ngữ C Hạn chế của phương phápnày là không phải ngôn ngữ nào cũng hỗ trợ ngoại lệ hay điều khiển tín hiệu.Nếu tự viết một ngoại lệ hay điều khiển tín hiệu thì sẽ phá hủy tính trong suốt

- Bị mất bản tin yêu cầu từ client gửi đến server: Đây là loại lỗi dễ xử lý

nhất: hệ điều hành hay client stub kích hoạt một bộ đếm thời gian (timer) khi gửi

đi một yêu cầu Khi timer đã trở về giá trị 0 mà không nhận được bản tin phảnhồi từ server thì nó sẽ gửi lại yêu cầu đó Nếu bên client nhận thấy có quá nhiềuyêu cầu phải gửi lại thì nó sẽ xác nhận rằng server không hoạt động và sẽ quaylại thành kiểu lỗi “không định vị được server”

- Server bị lỗi ngay sau khi nhận được yêu cầu từ client: Lúc này lại phân

chia thành hai loại:

+ Loại 1: Sau khi thực hiện xong yêu cầu nhận được thì server bị lỗi Phươngpháp khắc phục: sau đó server sẽ gửi thông báo hỏng cho client

+ Loại 2: Vừa nhận được yêu cầu từ client server đã bị lỗi ngay Phươngpháp khắc phục: client chỉ cần truyền lại yêu cầu cho Vấn đề đặt ra lúc này làclient không thể nói cho server biết yêu cầu nào là yêu cầu được gửi lại

Khi gặp lỗi kiểu này, ở phía máy server sẽ thực hiện theo 3 kĩ thuật sau:

Kĩ thuật 1: đợi đến khi nào server hoạt động trở lại, nó sẽ cố thực hiện yêu

cầu đã nhận được trước khi lỗi đó Như thế RPC thực hiện ít nhất một lần

Kĩ thuật 2: server sau khi được khôi phục nó sẽ không thực hiện yêu cầu

nhận được trước khi bị lỗi mà sẽ gửi lại thông báo hỏng cho client biết để clientgửi lại yêu cầu Với kĩ thuật này thì RPC thực hiện nhiều lần nhất

Kĩ thuật 3: không thực hiện gì để đảm bảo cả Khi server bị lỗi, client

không hề hay biết gì cả Kiểu này, RPC có thể được thực hiện nhiều lần cũng cóthể không thực hiện lần nào

Còn ở client thì có thể thực hiện theo 4 chiến lược sau:

Một là: Client không thực hiện gửi lại các yêu cầu Vì thế không biết bao

giờ yêu cầu đó mới thực hiện được hoặc có thể không bao giờ được thực hiện

Hai là: Client liên tục gửi lại yêu cầu: có thể dẫn tới trường hợp một yêu

cầu được thực hiện nhiều lần

Ba là: Client chỉ gửi lại yêu cầu nào đó khi không nhận được bản tin ACK

phản hồi từ server thông báo đã nhận thành công Trường hợp này, server dùng

bộ đếm thời gian Sau một khoảng thời gian xác định trước mà không nhận đượcACK thì client sẽ gửi lại yêu cầu đó

Bốn là: Client gửi lại yêu cầu nếu nhận được thông báo hỏng từ server.

Với hai chiến lược dành cho máy chủ và bốn chiến lược dành cho máy trạm,

có tổng cộng tám sự kết hợp cần xem xét Thật không may, sự kết hợp là khôngthỏa đáng Để giải thích, lưu ý rằng có 3 trường hợp có thể xảy ra ở máy chủ:gửi tin nhắn hoàn thành (M), in văn bản (P), và treo (C) Các trường hợp này cóthể xảy ra theo 6 trình tự sắp xếp sau:

1 M ~ P ~ C: Treo máy xảy ra sau khi gửi tin nhắn hoàn thành và in văn bản

2 M ~ C (~P): Treo máy xảy ra sau khi gửi tin nhắn hoàn thành nhưng trướckhi văn bản có thể được in

3 P ~ M ~ C: Treo máy xảy ra sau khi gửi tin nhắn hoàn thành và in văn bản

4 P ~ C (~M): Văn bản được in, sau khi máy chủ treo trước khi hoàn thành

có thể được gửi đi