7. Tính nhất quán và sử dụng bản sao
TRUYỀN THÔNG TIN CẬY Truyền thông client/server tin cậy.
Truyền thông client/server tin cậy.
Việc che giấu lỗi trong hệ phân tán tập trung vào trường hợp có tiến trình bị lỗi. Nhưng ta cũng phải xét đến trường hợp các giao tiế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 trung vào che giấu lỗi sụp đổ và lỗi tùy ý.
Truyền thông điểm – điểm.
Trong hệ phân tán, truyền thông điểm – điểm tin cậy được thiết lập bằ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 bằng cách dùng cơ chế thông báo ACK và việc thực hiện truyền lại. Những lỗi này hoàn toàn trong suốt với client.
Tuy nhiên TCP không che giấu được lỗi sụp đổ. Khi xảy ra lỗi sụp đổ thì kết nối TCP sẽ bị hủy nên nếu muốn che giấu lỗi, hệ thống phải có khả năng tự động tạo một kết nối mới.
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ục bằ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áp nà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ản hồi từ server thì nó sẽ gửi lại u cầu đó. Nếu bên client nhận thấy có q nhiều 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ẽ quay lạ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ương phá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ương phá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 u cầu nào là yêu cầu được gửi lại.
Đợ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.
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 để client gử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.
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:
Client không thực hiện gửi lại các 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. 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.
Client chỉ gửi lại 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 được ACK thì client sẽ gửi lại yêu cầu đó.
Client gửi lại yêu cầu nếu nhận được thơng báo hỏng từ server.
• Mất bản tin phản hồi từ server gửi trả về client: ta cần thiết kế các u cầu có đặc tính khơng thay đổi giá trị (idempotent). Client đánh số thứ tự cho các yêu cầu, server sẽ nhận ra được đâu là yêu cầu đã được gửi lại nhờ các số tứ tự này. Do đó server sẽ khơng thực hiện lặp lại các yêu cầu. Tuy nhiên server vẫn phải gửi trả về bản tin thông báo yêu cầu nào bị thất lạc. Hoặc ta có thể sử dụng một bit ở phần header của yêu cầu để phân biệt yêu cầu nào là yêu cầu đã được gửi lại.
• Client bị lỗi ngay sau khi gửi yêu cầu tới server: Client gửi yêu cầu tới server rồi bị lỗi trước khi nhận được trả lới từ server gửi về. Cơng việc mà server thực hiện nhưng khơng có đích nào đợi để nhận được gọi là một “orphan”. Như thế sẽ gây lãng phí chu kì CPU. Ta có 4 giải pháp được đưa ra trong trường hợp này là:
Trước khi gửi đi yêu cầu, client stub sẽ tạo ra một bản ghi xác định công việc cần thực hiện này và lưu lại. Như thế, khi được phục hồi sau khi lỗi, client sẽ lấy lại bản ghi đó và và việc thực hiện các orphan đang diễn ra sẽ
dừng lại. Phương pháp này có nhiểu nhược điểm: Chi phí để trang bị đĩa để lưu lại mỗi bản ghi cho mỗi RPC. Orphan có thể tự mình thực hiện RPC tạo ra một grandorphan nên rất khó xác định.
Chia thời gian hoạt động liên tục của client thành các số liên tục gọi là các thời kì. Mỗi khi các clietn khơi phục trở lại thì số chỉ thời kì này lại tăng lên một đơn vị. Lúc này client sẽ gửi thông báo đến tất cả các máy khác thơng báo số thời kì mới của mình. Khi nhận dược thơng báo này thì các orphan sẽ dừng lại.
Khi nhận được bản tin thơng báo thời kì mới, mỗi máy sẽ kiểm tra xem mình có đang thực hiện một tính tốn từ xa nào đó khơng. Nếu có, máy đó sẽ cố xác định xem client nào đã gửi u cầu này. Nếu khơng xác định được thì q trình tính tốn này sẽ bị hủy bỏ.
Quy định mỗi RPC chỉ có một khoảng thời gian xác định T để thực hiện,
sau khi gặp lỗi, clietn sẽ phảo đợi thêm một khoảng thời gian T trước khi khởi động lại để nhận các orphan. Vấn đế đặt ra là phải lựa chọn giá trị T
như thế nào cho hợp lý.