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 Web-Based Systems" Giáo viên hướng dẫn: TS Hoa Tất Thắng Học viên thực hiện: Phạm Công Hòa Nguyễn Hữu An Lê Thị Thu Thủy Trần Thị Huyền Phạm Thị Ngà-K24 Lớp: Cao học CNTT K25 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 khi mộ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ưởng tớ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ột lỗ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ây dự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ần lỗ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 trong khi quá trình sửa chữa vẫn đang được tiến hành, có nghĩa là khả năng chịu đựng lỗ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ảng chung 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ặt chẽ 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 ảnh hưở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ụ, trong cá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ác hoạt động trong một quá trình được truyền đi được thực hiện. Về cơ bản atomicity 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 được cam 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. Đặc biệ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 2 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ều trong khoa học máy tính. Trong phần này, chúng ta sẽ bắt đầu được làm quen vớ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ằng cá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ảo thê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ỗi liên quan nhiều đến những gì gọi là hệ thống đáng tin cậy. Độ tin cậy là một thuậ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 bao gồm những yêu cầu sau (Kopetz and Verissimo, 1993): 1. Tính sẵn sàng 2. Tính tin cậy 3. Tính an toàn 4. Khả năng duy trì Tính sẵn sàng nghĩa là hệ thống có thể sử dụng ngay lập tức. Nói chung điều này thể hiện khả năng hệ thống hoạt động chính xác trong bất kỳ thời điểm nào và sẵn sàng thực hiện chức năng của nó. Nói một cách khác, một hệ thống 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 đưa ra. 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ời gian dài. Đây là một sự khác biệt khó nhận ra nhưng rất quan trọng khi đem so sá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 3 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ống khô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ại chỉ đạ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ệt hạ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ảng thờ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ửa mộ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, đặc biệ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ên như 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ức năng thông thường của nó. Cụ thể nếu một hệ phân tán được thiết kế để cung cấp một số những dịch vụ, hệ thống lỗi khi nó không thể cung cấp được một trong những dịch vụ đó. Ví dụ khi truyền một gói tin qua mạng, nó có thể bị rớt gó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ột môi trường truyền không tốt có thể dễ dàng ảnh hưởng đến. Trong trường hợp nà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ều kiệ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ẽ đến việ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ính chị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 4 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ỗi nhấ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ỗi khô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ều lầ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ắc phụ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 thay thế, ví dụ như cháy nổ chip, lỗi phần mềm, lỗi ổ đĩa 8.1.2. Các kiểu lỗi Một hệ thống lỗi là khi nó không cung cấp đầu đủ các dịch vụ như nó được thiết kế. Nếu coi một hệ phân tán là một tập các server giao tiếp với nhau và với các client của nó, thì không cung cấp đầy đủ các dịch vụ nghĩa là các server, các kênh truyền thông, hoặc cả 2 không thực hiện đúng nhiệm vụ của nó. Tuy nhiên một server hoạt động sai chức năng chưa chắc đã là nguyên nhân gây 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ế để cung cấ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ần củ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). 5 Kiểu lỗi Miêu tả 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ừng Lỗ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ới Một máy chủ bị lỗi nhận các thông tin gửi tới Mộ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 Giá trị bị lỗi Trạng thái truyền bị lỗi Đáp ứng của một máy chủ không chính xác Giá trị của đáp ứng bị sai 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ào Hình 8-1. Các kiểu lỗi Lỗ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ủa trườ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ột giả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ặp phải lỗi bị treo thường xuyên đến nỗi mọi người phải cho rằng đó là chuyện bì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ẽ được chuyể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ặc nhậ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 server không bao giờ nhận được yêu cầu ngay trong lần đầu tiên. Chú ý rằng có thể kết nối giữa client và server có thể đã được tạo ra nhưng không có luông nào lắng nghe các request đến. Hơn nữa lỗi nhận các yêu cầu nói chung sẽ không ảnh hưở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ó. 6 Tương tự như vậy, lỗi gửi các bản tin xảy ra khi server đã hoàn thành cô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 khi server không được chuẩn bị cho tình huống đó. Chú ý rằng ngược với lỗi nhận yê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ột dị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àn tấ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ản hồ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ía nhậ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ậm dẫ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 tin phả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ác phản hồi sai cho một yêu cầu nào đó. Chẳng hạn một serach engine đưa ra kết quả 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. State transition failure xảy ra nếu không có tiêu chuẩn nào được đưa ra để điều khiển cá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à khi bì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ỗi crash failure. Crash failure còn được gọi là fail-stop failure, nó là loại lỗi ít gây thiệ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ông báo rằng nó sắp ngừng hoạt động. 7 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ến trình khác sẽ có nhiệm vụ xác định rằng server đó đã ngừng. Tuy nhiên trong cá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 đến performance failure. Cuối cùng, có nhiều trường hợp mà server đưa ra những output ngẫu nhiên, nhưng output này có thể nhận biết được bởi những tiến trình khác. Server như 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ăng che 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à: information redundancy (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ẳng hạn Hamming code có thể được thêm vào dữ liệu được truyền đi để bù lại nhiễu trên đường truyền. Time redundancy nghĩa là một hành động được thực hiện, sau đó nếu cần thiế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áp nà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ời hoặ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 được thê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 sai chức năng của một số thiết bị. Do vậy physical redundancy có thể được thực hiệ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ằng cách sao chép các tiến trình, có thể đạt được khả năng chịu lỗi cao. 8 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-2a tín hiệu sẽ đi qua A,B,C theo thứ tự. Nếu một trong 3 thiế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 qua thiế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ệu output sẽ được đưa và các bộ so sánh V1, V2, V3. Mỗi mạch so sánh này sẽ so sá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 nhau thì 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 được che đậy, vì vậy tín hiệu input cho B1, B2, B3 vẫn chính xác như trường hợp Az khô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 ảnh hưở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ụng TMR 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. 9 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ịu lỗ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ỗi xảy ra, trong phần này chúng ta sẽ xem xét những vần đề thiết kế chung của nhó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ến trì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ế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. (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ộ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. 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ên trong 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ự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 10 [...]... của RPC và phân biệt rõ ràng các hệ thống xử lý đơn với các hệ phân tán Trong trường hợp trước đây, một máy chủ bị treo cũng đồng nghĩa với máy trạm bị treo, việc phục hồi là không thể và cũng không cần thiết Nhưng sau này điều đó là có thể và cần thiết đối với một hoạt động - Mất bản tin phản hồi từ server gửi trả về client: Mất tin nhắn phản hồi cũng có thể là khó khăn phải đối phó Giải pháp cụ thể... một multicast thứ 2 được sử dụng để thực sự lấy trạng thái từ checkpoint để phục hồi hoạt động cho các tiến trình trong toàn hệ thống 34 8.7_ Làm rõ đối với Web-Based Systems: 1.Kiến trúc chung: Ban đầu, hệ phân tán dựa trên nền tảng Web không khác nhiều so với những hệ phân tán khác Tuy nhiên trong quá trình phát triển, tài liệu được chia sẻ trên Web từ tài liệu tĩnh chuyển thành những tài liệu động,... 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 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... 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 Trong hì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ác phần tử chính element 1, element 2, hoặc element 3, do đó sẽ được đánh dấu UNKNOWN Các thuật toán đã sai trong quá trình bắt tay thỏa thuận với nhau 15 8.2.4 Phát hiện lỗi Muốn... 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ông tin 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 đượ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... 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... điểm khôi phục để đảm bảo sự hoàn hảo cho cả hệ thống yêu cầu sự phân tích các phần phụ thuộc được ghi lại bởi các tiến trình trong hệ thống Điều này vô cùng phức tạp, đặc biệt là đối với các hệ thống lớn Checkpointing phối hợp Với phương pháp này, tất cả các tiến trình được đồng bộ để ghi lại trạng thái vào kho lưu trữ cục bộ Lợi ích chính của phương pháp là trạng thái lưu trữ được đồng bộ tự động cho... đó, 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án vớ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ến trì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... nhập CSDL - Server xử lí và trả lại thông tin cho Client 1.2.Mô hình truyền thống với kiến trúc đa tầng: Một trong những cải tiến so với kiến trúc cơ bản là việc sử dụng các CGL( Common Gatew Interface) nhằm cung cấp sự tương tác cho người 35 dùng Thông qua các Interface này, Webserver có thể chạy những chương trình với dữ liệu đầu vào được người dung cung cấp 1.3.Mô hình cơ chế hoạt động dịch vụ Web:... các yêu cầu đã được máy trạm gửi, máy chủ có thể phân biệt yêu cầu ban đầu với yêu cầu gửi lại và có thể từ chối thực hiện bất cứ yêu cầu lần thứ hai nào Tuy nhiên, máy chủ vẫn phải gửi một thông báo cho máy trạm Lưu ý rằng phương pháp này không yêu cầu máy chủ phải duy trì quyền quản lý trên mỗi máy trạm Hơn nữa cũng không rõ duy trì quyền quản lý bao lâu Thêm một biện pháp an toàn là trong tiêu đề .  &  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 Web-Based Systems& quot; Giáo viên hướng dẫn: TS Hoa Tất Thắng Học viên thực hiện: Phạm. đơ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. trình làm việc của thuật thuật toán vớ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ến trình