A. Giới thiệu

Hệ phân tán đóng vai trò quan trọng trong lĩnh vực phát triển của công nghệ máy

tính, đăc biệt là trong điều kiện phát triển bùng nổ của các mạng máy tính. Sự phát triển

của các mạng LAN, WAN cho phép hàng trăm, hàng nghìn hay thậm chí hàng triệu mát

tính có thể kết nối với nhau.

Kết quả của sự phát triển công nghệ hiện nay không chỉ đáng tin cậy mà còn tạo nên các

hệ thống máy tính rất lớn, được kết nối bằng các đường kết nối tốc độ cao. Chúng tạo nên

các mạng máy tính lớn hoặc các hệ phân tán, ngược với hệ thống tập trung trước đây, bao

gồm các máy tính đơn và có thể cả thiết bị điều khiển đầu cuối (remote teminal).

Có nhiều định nghĩa được đưa ra, nhưng nếu coi hệ phân tán là hệ thống phục vụ người

dùng thì : hệ phân tán là tập các máy tính độc lập giao tiếp với người dùng như một hệ

thống thống nhất và trọn vẹn.

Hệ phân tán được xây dựng cần đảm bảo một số đặc trưng :

Chia sẻ tài nguyên

Tính trong suốt

Tính mở

Tính co giãn

Tính trong suốt đảm bảo khả năng che giấu tiến trình và tài nguyên phân tán trong mạng

máy tính. Hệ phân tán có khả năng biểu diễn bản thân nó với người dùng và ứng dụng

giống như một máy tính đơn lẻ.

Bài tiểu luận này sẽ trình bày về các đặc trưng về mặt lý thuyết để đảm bảo tính trong

suốt trong hệ phân tán và triển khai nó trong hệ thống WEB.

1

B. Nội dung

I. Các vấn đề về lý thuyết của hệ phân tán

1. Tinh trong suôt đôi vơi ngươi sư dung

• Truy nhâp (Access transparency): che giấu sư khac biêt trong cach biêu hiên dư

liêu va cach thưc truy nhâp tai nguyên. Ơ mưc cơ ban, ta che giấu sư khac biêt vê

kiên truc may, nhưng quan trong hơn chinh la ta phai đat đươc sư thông nhât

trong biêu diên dư liêu bơi cac may tinh khac nhau va cac hê điêu hanh khac

nhau. Vi du, quy ươc vê cach đăt tên cua cac may tinh khac nhau chay trên cac hê

điêu hanh khac nhau la khac nhau, tuy nhiên cach thưc nay cung vơi cac thao tac

vơi file hoan toan trong suôt vơi ca ưng dung va ngươi dung.

• Vi tri (Location transparency): che giấu vi tri tai nguyên → ngươi dung hoan toan

không biêt vê vi tri vât ly cua tai nguyên trong hê thông. Đê đat đươc , ta cân tiên

hanh đinh danh băng tên goi logic. Tên goi co thê đơn gian, không cân ma hoa.

VD : cardchua.vn, la tên cua trang web, ta không hê biêt vi tri vât ly cua no trên

Web server nao, nhưng vân co thê truy câp đươc.

• Di tru (Migration transparency): che giấu viêc tai nguyên di chuyên sang may

khac → tai nguyên co thê không năm ơ vi tri cô đinh, ma no co thê đươc di

chuyên sang cac may khac nhau trong hê thông để phuc vu cac yêu câu khac nhau

ma không anh hương tơi viêc truy nhâp tai nguyên.

• Di chuyên (Relocation transparency): che giấu viêc tai nguyên co thê bi di chuyên

sang nơi khac → tai nguyên co thể di chuyên sang nơi khac ngay ca khi no đang bi

truy câp. VD: ngươi dung điên thoai di đông co thê di chuyên tư nơi nay sang nơi

khac, do đo chuyên liên lac tư tram phat song nay sang tram phat song khac

nhưng cuôc thoai vân liên tuc, không co bât ki gian đoan nao.

• Nhân bản (Repilcation transparency): che giấu viêc sao chep tai nguyên → viêc

sao chep tai nguyên giup đơn gian hoa va tăng tôc đô truy câp dư liêu, cac ban sao

đăt gân hoăc ngay tai nơi truy câp dư liêu. Cac ban sao nay phai co cung tên, để

2

che giâu vơi ngươi dung; va hê thông cân co tinh trong suôt vê vi tri, để đam bao

kha năng quan ly cac ban sao khac nhau trên cac may trong hê thông.

• Tương tranh (Concurrency transparency): che giấu sư chia se tai nguyên bơi môt

sô ngươi sư dung, nhiêu ngươi dung co thê cung truy câp dư liêu tai cung môt thơi

điêm, đăc biêt sư dung nhiều trong mang truyên thông. VD: hai ngươi cung lưu

trư file trên cung server, va tai môt thơi điêm, ho truy câp tơi cung ban ghi trong

cơ sơ dư liêu chung, đê đam bao tinh nhât quan va ôn đinh cua dư liêu vơi tưng

ngươi dung, ta cân sư dung cac cơ chê khoa. Ngoai ra, con co thê thưc hiên cơ chê

giao dich, tuy nhiên no kho thưc hiên trên hê thông phân tan.

• Lôi (Failure transparency): che giấu lôi va khăc phuc lôi → đam bao ngươi dung

hoan toàn không biêt vê cac lôi xay ra trong hê thông va sư khăc phuc cac lôi nay.

Che dâu lôi la môt trong cac yêu câu kho thưc hiên nhât, va co thê không thưc

hiên đươc trong môt sô tinh huông cu thê. Điêm kho nhât chinh la ta không thê

phân biêt đươc tai nguyên la truy câp châm hay không thê truy câp đươc. VD: khi

truy câp môt web Server bân, trinh duyêt thông bao “time-out”, thi ta không thê

biêt đươc server co thưc sư bị lỗi hay không.

Mức độ trong suốt

Tuy nhiên không phải lúc nào cũng nên thể hiện tính trong suốt hoàn toàn với người

dùng. Ví dụ, khi có báo điện tử xuất hiện trong hòm thư của người dùng vào lúc 7h, trong

khi bạn đang ở múi giờ khác, người dùng cần phải biết thông tin về tờ báo này không

phải là tờ báo mà họ vẫn sử dụng. Ngoài ra cũng có sự đánh đổi giữa mức độ trong suốt

và tốc độ hệ thống. Ví dụ, nhiều ứng dụng Internet lặp lại việc truy cập máy chủ sau một

khoảng thời gian nhất định trước khi từ bỏ, do đó, nếu ta cố che dấu việc kết nối thất bại

sẽ làm chậm đáng kể tốc độ hệ thống. Với trường hợp này, cần rút ngắn thời gian cố kết

nối hoặc để cho người dùng huỷ bỏ kết nối.

Ví dụ khác, ta cần đảm bảo sự thống nhất giữa các bản sao trên các máy khác nhau. Một

bản ghi bị thay đổi sẽ kéo theo sự thay đổi của tất cả các bản ghi khác, làm chậm đáng kể

thời gian hệ thống, nên không thể che giấu người dùng.

3

Trong một số tình huống, tính trong suốt không hẳn là giải pháp tốt, cụ thể như trong các

tình huống liên quan tới vị trí và hoàn cảnh đặc biệt, chúng ta nên thể hiện tính phân tán

của hệ thống hơn là nên che dấu nó, cụ thể như trong các hệ phân tán nhúng và phân bố

rộng. Ví dụ, khi ta muốn in văn bản thông qua các máy in mạng, nên gửi tới các máy in ở

gần ta, dù đang bận, hơn là tại các máy in xa.

Việc thiết kế hệ phân tán trong suốt là cần thiết, tuy nhiên cũng cần đảm bảo sự hài hoà

với các đặc tính khác như hiệu năng và tính thân thiện với người dùng của hệ thống. Tuy

nhiên có thể phải trả giá đắt cho việc không đảm bảo tính trong suốt hoàn toàn của hệ

phân tán.

2. Kiến trúc

Hệ phân tán thường bao gồm tập phức tạp của các phần mềm nằm rải rác trên các máy

khác nhau, do đó cần tổ chức tốt. Có nhiều cách khác nhau để xem xét tổ chức của hệ

phân tán , và một trong số đó là tách riêng tổ chức logic của các thành phần phần mềm và

các phần cứng hệ thống.

Một trong các mục đích quan trọng của hệ phân tán là phân tách các ứng dụng từ nền bên

dưới thông qua lớp trung gian. Đó chính là bước thiết kế quan trọng với mục đích chính

là đảm bảo tính trong suốt phân tán. Tuy nhiên, việc đó phải đánh đổi bằng nhiều biện

pháp thiết kế phức tạp để làm lớp trung gian có khả năng tương tác tốt.

Các loại kiến trúc hệ thống:

- kiến trúc lớp

- kiến trúc hướng đối tượng

- kiến trúc dữ liệu trung tâm

- kiến trúc hướng sự kiện

Kiến trúc lớp : các thành phần được tổ chức theo kiểu lớp, thành phần lớp Li sẽ gọi thành

phần ở lớp dưới Li-1 , mô hình được sử dụng rộng rãi trong truyền thông mạng .

Kiến trúc hướng đối tượng có các đối tượng được định nghĩa dưới dạng các thành phần

và được kết nối với nhau thông qua cơ chế gọi thủ tục (remote). Dạng kiến trúc phần

mềm này tương tự như kiến trúc client-server.

Hai dạng kiến trúc lớp và hướng đối tượng vẫn đóng vai trò quan trọng trong các hệ

thống phần mềm lớn.

4

Kiến trúc dữ liệu tập trung suy ra từ ý tưởng các tiến trình giao tiếp thông qua phần tử

(chủ động hay thụ động) chung. Kiến trúc này cũng quan trọng không kém 2 kiến trúc

trên, ví dụ như hệ thống chia sẻ file chung nhằm che giấu tất cả các kết nối trong hệ

thống thông qua các liên kết ảo tới file như trong hệ thống phân tán kiểu Web.

Trong kiến trúc hướng sự kiện, tiến trình về cơ bản sẽ giao tiếp thông qua sự lan truyền

của sự kiện, có thể mang cả dữ liệu. Với hệ phân tán, sự lan truyền sự kiện nói chung liên

quan tới các hệ thống công cộng (publish/subscribe). Ý tưởng cơ bản là các tiến trình gửi

sự kiện sau khi lớp trung gian đảm bảo chỉ các tiến trình chấp nhận sự kiện này mới có

thể nhận chúng. Lợi ích lớn của hệ thống hướng sự kiện là các tiến trình có mỗi quan hệ

linh động, chúng không cần liên quan chặ chẽ với các tiến trình khác. Do đó chúng có thể

liên kết hoặc tự do.

Kiến trúc hướng sự kiện có thể kết hợp với kiến trúc dữ liệu tập trung, tạo thành không

gian dữ liệu chia sẻ. Bản chất của không gian dữ liệu tập trung là các tiến trình có thể

không liên kết với nhau, chúng không cần sẵn sàng khi sự truyền đạt được thiết lập. Xa

hơn, nhiều không gian dữ liệu chia sẻ sử dụng giao diện SQL để chia sẻ kho dữ liệu với ý

nghĩa dữ liệu có thể truy nhập thông qua mô tả hơn là tham chiếu rõ ràng, như trong

trường hợp với file.

Sự cần thiết của các kiến trúc phần mềm để đảm bảo tính trong suốt đối với các hệ phân

tán là không có gì phải bàn cãi, tuy nhiên yêu cầu về tính trong suốt phải đánh đổi với

hiệu năng hệ thống, khả năng chịu lỗi, khả thi khi lập trình và còn một số các yêu cầu

khác. Không có lời giải tách biệt nào đảm bảo tất cả yêu cầu của hệ phân tán, do đó ta cần

áp dụng tổng hợp các giải pháp để đạt hiệu quả.

3. Tiến trình

Khái niệm của tiến trình bắt nguồn từ các lĩnh vực của hệ điều hành , trong đó nó được

định nghĩa như là chương trình đang thực thi . Trong đó thì việc quản lý và lập kế hoạch

của các tiến trình có lẽ là vấn đề quan trọng nhất cần phải quan tâm .

Ví dụ , để tổ chức hiệu quả 1 hệ thống client-server, người ta thường sử dụng các kỹ

thuật đa luồng. Như chúng ta đã thảo luận trong phần trước, đặc điểm quan trọng nhất

của luồng trong hệ phân tán là chúng cho phép các máy trạm và máy chủ có thể được xây

dựng để các kết nối và xử lý nội bộ có thể chồng lên nhau , điều này dẫn đến hiệu suất

5

cao , Trong những năm gần đây , khái niệm về ảo hóa đã trở nên phổ biến . Ảo hóa cho

phép một ứng dụng và có thể có môi trường hoàn chỉnh bao gồm hệ điều hành , để chạy

đồng thời với các ứng dụng khác nhưng hoàn toàn độc lập về phần cứng và nền tảng nằm

dưới . Hơn nữa , ảo hóa giúp tách được các sự cố gây ra do lỗi hay các vấn đề về bảo mật.

Đây là một khái niệm quan trọng trong hệ phân tán .

Một vấn đề quan trọng , đặc biệt là ở khu vực phân tán rộng, là việc di chuyển tiến tình

giữa các máy tính khác nhau . Quá trình di chuyển hay cụ thể hơn là di trú mã.

3.1. Luồng

Để thực thi 1 chương trình , hệ điều hành tạo ra một số bộ xử lý ảo, mỗi một bộ xử lý này

chạy 1 chương trình khác nhau. Để theo dõi các bộ xử lý ảo này , hệ điều hành có 1 bảng

tiến trình, mỗi mục lưu các giá trị thanh ghi, ánh xạ bộ nhớ, các tập tin mở, các thông tin

tính toán, quyền hạn … Một tiến trình thường được định nghĩa như là một chương trình

đang thực thi. Một vấn đề quan trọng là hệ điều hành sẽ theo dõi chặt chẽ để đảm bảo

rằng các tiến trình độc lập không vô tình hoặc cố ý ảnh hưởng đến các hành vi của tiến

trình khá. Tuy nhiên, thực tế là nhiều quá trình có thể chia sẻ cùng một bộ xử lý và tài

nguyên phân cứng khác do tính trong suốt của hệ thống. Thông thường , hệ điều hành yêu

cầu phần cứng hỗ trợ để thực hiện việc phân chia này.

Điều này làm chi phí cho các tiến trình sẽ rất lớn . Ví dụ , mỗi lần 1 tiến trình được tạo ra,

hệ điều hành cần phải tạo ra một không gian địa chỉ độc lập. Phân phối bộ nhớ được xem

như khởi tạo phân đoạn bộ nhớ bằng cách xoá dữ liệu, sao chép chương trình vào phân

đoạn text, và khởi tạo ngăn xếp . Tương tự, chuyển đổi phục vụ của CPU giữa 2 tiến trình

có thể tương đối tốn kém. Ngoài việc tiết kiệm CPU ( các giá trị thanh ghi , bộ đếm

chương trình , ngăn xếp con trỏ .. ) hệ điều hành cũng sẽ phải sửa đổi thanh ghi của bộ

nhớ quản lý (MMU ) và bộ nhớ cache như trong bộ đệm TLB. Thêm vào đó, nếu hệ

thống hỗ trợ nhiều tiến trình đồng thời nó cần phải lưu tiến trình trong bộ nhớ chính. Nó

có thể có tiến trình nháp để trao đổi giữa bộ nhớ chính và ổ đĩa trước khi thực sự thực

hiện tiến trình.

Giống như tiến trình, một luồng thực thi các đoạn mã của nó độc lập với các luồng khác.

Tuy nhiên, ngược với tiến trình nó không cố gắng để tạo ra sự độc lập với các luồng khác

nếu việc này làm giảm hiệu năng. Do đó một luồng hệ thống thường chỉ duy trì các thông

tin tối thiểu cho phép một CPU được chia sẻ bởi 1 vài luồng. Đặc biệt, một bối cảnh

6

luồng thông thường chỉ gồm có bối cảnh CPU cùng với một số thông tin khác để quản lý

luồng. Ví dụ , một hệ thống luồng có thể đảm bảo rằng một luồng hiện tại đang bị khóa

thì sẽ không thể thực thi. Thông tin đó không thực sự cần thiết để quản lý đa luồng và

thường bị bỏ qua. Vì lý do này , bảo vệ dữ liệu chống lại các truy cập không thích hợp

bằng luồng trong 1 tiến trình được đặt hoàn toàn vào người phát triển ứng dụng .

Có hai ý nghĩa quan trọng của phương pháp này. Trước hết , hiệu suất của 1 ứng dụng đa

luồng khó có thể kém hơn ứng dụng đơn luồng. Trong thực tế, nhiều trường hợp đa luồng

làm cho hiệu suất tăng . Thứ hai, bởi vì các luồng không tự động bảo vệ lẫn nhau như

cách của tiến trình, nên việc phát triển các ứng dụng đa luồng cần được phát triển hơn

nữa, đảm bảo thiết kế và giữ mọi thứ càng đơn giản càng tốt. Tuy nhiên, những thực

nghiệm hiện nay không chứng mình rằng nguyên tắc này đều được các nhà phát triển

nắm rõ.

3.2. Di trú mã

Di trú mã là một trong các đặc tính của tính trong suốt trong hệ phân tán, nhằm di trú tiến

trình (ngay cả khi chúng đang thực thi), nhằm đơn giản hoá việc thiết kế hệ phân tán.

Phương pháp tiếp cận

Di trú mã trong hệ phân tán là quá trình di chuyển toàn bộ tiến trình từ máy này sang máy

khác. Tuy điều này làm tốn kém và phức tạp nhưng hiệu quả mang lại về hiệu năng là rõ

rệt. Ý tưởng cơ bản là hiệu năng hệ thống có thể tăng rõ rệt nếu các tiến trình được di

chuyển từ máy nặng tải sang máy nhẹ tải hơn. Các thuật toán phân chia tải cho hệ thống

liên quan tới phân chia và tái phân chia các tác vụ với tập hợp các vi xử lý, đóng vai trò

quan trọng trong các hệ thống tính toán cường độ lớn. Mặc dù vậy, trong các hệ thống

tính toán hiện đại, tối ưu tính toán tải ít được đưa ra hơn. Hơn nữa, do tính không đồng

nhất của nền bên dưới và mạng máy tính, việc cải thiện hiệu năng thông qua di trú mã

thường dựa trên lý do định tính hơn là định lượng.

Ví dụ, trong trường hợp server chứa lượng cơ sở dữ liệu lớn, nếu client cần thực hiện

nhiều hoạt động trên CSDL này, có thể nên chuyển một phần mã của ứng dụng client

sang server và chỉ gửi kết quả qua mạng, giúp giảm tải đáng kể. Điều này có thể áp dụng

tương tự cho phía client.

Di trú mã có thể được áp dụng trong tính toán song song, dù không rắc rối như lập trình

song song. Ví dụ cụ thể như với trường hợp tìm kiếm thông tin trên WEB, được thực hện

7

thông qua tác tử di động, di chuyển từ site này sang site khác. Bằng cách sao chép tác tử

này, do kích thước nhỏ nên thời gian thực hiện nhanh, và gửi chúng tới các site khác

nhau, ta có thể thu dược hiệu quả như sử dụng một chương trình đơn lẻ.

Bên cạnh việc cải thiện hiệu năng, còn một số lý do khác. Lý do quan trọng nhất là độ

linh động của hệ thống. đơn giản nhất là ta chia ứng dụng thành các đoạn khác nhau, và

đánh giá đoạn nào nên được thực thi.Tuy nhiên, nếu mã di chuyển giữa các máy khác

nhau, ta có thể cấu hình động cho hệ phân tán.

Mô hình di trú mã

Mặc dù di trú mã có nghĩa là ta chỉ chuyển mã giữa các máy, điểu này bao hàm khu vực

rộng lớn hơn nhiều. Theo truyền thống, truyền thông trong hệ phân tán liên quan tới việc

trao đổi dữ liệu giữa các tiến trình. Di trú mã theo nghĩa rộng là di chuyển các chương

trình giữa các máy với nhau, với mục tiêu thực hiện các chương trình này để đạt được

mục đích. Trong một số trường hợp, trạng thái thực thi chương trình, thông tin hiện hành

và một số phần khác của môi trường cũng được di chuyển theo.

Ta sử dụng mô hình sau : trong mô hình này, tiến trình được chia thành 3 phần. Phần mã

chứa tập lệnh thực hiện của tiến trình. Phần tài nguyên chứa các tài nguyên cần thiết như

file, máy in, các thiết bị và các tiến trình khác. Cuối cùng, phấn thực thi lưu giữ các trạng

thái của tiến trình trong thời điểm hiện tại, gồm dữ liệu riêng, ngăn xếp và bộ đếm

chương trình.

Ta có 2 mô hình chính của di trú mã: mô hình di động yếu và mô hình di động mạnh.

Trong mô hình di động yếu, ta có thể chỉ chuyển phần mã, với một số dữ liệu ban đầu.

Chức năng chính của mô hình này là chương trình được truyền luôn bắt đầu từ một trong

các vị trí bắt đầu được xác định trước. Lợi ích rõ ràng nhất của phương pháp này là sự

đơn giản, chỉ yêu cầu máy đích thực thi mã, thực tế làm giảm sự linh động của mã.

Ngược với mô hình di động yếu, trong mô hình di động mạnh, tiến trình đang chạy có thể

dừng lại và tiếp tục trạng thái đang hoạt động khi di chuyển từ máy này sang máy khác.

Tuy nhiên nó phải trả giá bằng việc khó triển khai hơn so với mô hình di động yếu.

Trong trường hợp mô hình di động yếu, có sự khác nhau nếu mã di trú được thực thi bởi

tiến trình đích và với các tiến trình riêng biệt, ví dụ với Java applet được tải về bởi trình

duyệt được thực thi trong không gian địa chỉ của trình duyệt. Lợi ích rõ ràng là không cần

8

kết nối tới máy chủ, tuy nhiên cần bảo vệ tiến trình đích trước mã độc và sự sơ xuất khi

thực thi. Có thể giải quyết bằng cách hệ điều hành chú ý tới việc tạo các tiến trình để thực

thi mã di trú. Tuy nhiên nó không giải quyết được vấn đề truy nhập tài nguyên trái phép.

Thay vì di chuyển các tiến trình đang chạy, mô hình di động mạnh được hỗ trọ bởi các

remote cloning. Trái ngược với di trú mã, ta sao chép hoàn toàn chính xác tiến trình gốc,

nhưng được thực hiện trên máy khác. Trong hệ thống UNIX, remote cloning chia nhánh

một tiến trình con và để tiến trình này tiếp tục thực thi trên máy điều khiển. Lợi ích của

việc nhân bản là tạo mô hình gần như tập hợp bởi các ứng dụng khác nhau đã được sử

dụng. Điểm khác duy nhất là tiến trình nhân bản được thực thi trên máy khác. Do đó, việc

di trú bằng cách nhân bản là cách đơn giản để cải thiện tính trong suốt.

Tài nguyên di trú và tài nguyên cục bộ

Cho tới phần này, ta mới chỉ xét tới mã di trú và các phần thực thi (execution segment)

được thực hiện … Phân đoạn tài nguyên đòi hỏi những sự chú ý đặc biệt. Điều khó khăn

thường gặp khi thực hiện di trú mã đó là phân đoạn tài nguyên không phải luôn dễ dàng

được chuyển đi cùng các phân đoạn khác mà không bị thay đổi. Ví dụ, giả sử rằng một

tiến trình nắm giữ một tham chiếu tới một cổng TCP mà qua đó nó giao tiếp với các tiến

trình khác. Do một tham chiếu được giữ trong phân đoạn tài nguyên của nó, khi tiến trình

di chuyển sang vị trí khác, nó sẽ phải từ bỏ cổng cũ và yêu cầu một cổng mới ở vị trí mới.

Để hiểu sự hàm ý mà di trú mã có trong phân đoạn tài nguyên, ta phân biệt 3 loại ràng

buộc tiến trình-tài nguyên. Loại ràng buộc mạnh nhất là khi một tiến trình đòi hỏi tài

nguyên dựa vào định danh của nó. Trong trường hợp đó, tiến trình sẽ yêu cầu chính xác

9

tài nguyên tham chiếu, ngoài ra không còn yêu cầu gì khác. Một ví dụ của ràng buộc bởi

định danh là khi một tiến trình sử dụng một VRL để yêu cầu một Web site cụ thể nào đó

hoặc yêu cầu tới một FrP server bởi địa chỉ Internet của server đó. Với cùng nguyên nhân

đó, những tham chiếu tới các điểm giao tiếp cục bộ cũng dẫn tới ràng buộc bởi định danh.

Một dạng ràng buộc tiến trình – tài nguyên yếu hơn là khi ta chỉ quan tâm tới giá trị của

tài nguyên được yêu cầu. Trong trường hợp đó, sự thực thi của tiến trình sẽ không bị ảnh

hưởng nếu các tài nguyên khác cũng cung cấp cùng một giá trị. Một ví dụ cho ràng buộc

bởi giá trị là khi một chương trình dựa trên các thư viện chuẩn, như lập trình C hoặc Java

chẳng hạn. Các thư viện này luôn tồn tại ở cục bộ, nhưng vị trí chính xác của chúng trong

hệ thống file cục bộ có thể khác nhau giữa các site khác nhau. Nội dung của chúng rất

quan trọng cho việc thực thi chính xác của các tiến trình.

Cuối cùng, dạng ràng buộc yếu nhất là khi một tiến trình chỉ yêu cầu một loại nhất định

nào đó của tài nguyên.Ràng buộc bởi loại đơn giản nhất đó là tham chiếu tới các thiết bị

cục bộ, như màn hình, máy in,…

Khi di trú mã, chúng ta thường cần thay đổi tham chiếu tới các tài nguyên, nhưng không

thể làm ảnh hưởng tới loại ràng buộc tiến trình – tài nguyên. Một tham chiếu được thay

đổi chính xác như thế nào, phụ thuộc vào tài nguyên được di chuyển cùng với mã tới máy

đích. Cụ thể hơn, chúng ta cần quan tâm tới ràng buộc tài nguyên – máy, và phân biệt các

trường hợp khác nhau.Tài nguyên tách rời có thể dễ dàng di chuyển giữa các máy khác

nhau, và là các file cụ thể chỉ liên quan đến chương trình được di trú. Ngược lại, di

chuyển hay sao chép một tài nguyên gắn kết là có thể, nhưng phải tốn chi phí rất cao. Ví

dụ, về tài nguyên gắn kết đó là các cơ sở dữ liệu cục bộ và những Website hoàn chỉnh.

Mặc dù các tài nguyên, xét về lý thuyết, không phụ thuộc vào máy chứa nó, nhưng

thường là không thể di chuyển chúng tới môi trường khác. Cuối cùng, tài nguyên cố định

được gắn kết cố định với một máy tính hoặc môi trường cụ thể và không thể bị di chuyển.

Tài nguyên cố định thường là các thiết bị cục bộ. Một ví dụ khác của tài nguyên cố định

đó là các điểm truyền thông cục bộ.

Kết hợp 3 loại ràng buộc tiến trình – tài nguyên, và 3 loại ràng buộc tài nguyên – máy

tính, dẫn tới 9 kết hợp ta cần quan tâm khi thực hiện di trú mã. 9 kiểu kết hợp này được

chỉ ra trong hình

10

Trước hết chúng ta quan tâm tới khả năng một tiến trình được gắn với tài nguyên bởi định

danh. Khi tài nguyên bị tách rời, điều tốt nhất là di chuyển nó cùng với mã di trú. Tuy

nhiên, khi tài nguyên được chia sẻ bởi các tiến trình khác, một lựa chọn khác là thiết lập

một tham chiếu toàn cục, một tham chiếu có thể sử dụng ngoài giới hạn của một máy đơn

lẻ. Một ví dụ của một tham chiếu toàn cục đó là một URL. Khi tài nguyên được gắn kết

hoặc cố định, giải pháp tốt nhất đó là tạo ra một tham chiếu toàn cục.

Một điều quan trọng cần nhận ra là việc thiết lập một tham chiếu toàn cục phức tạp hơn là

việc sử dụng URLs, và việc sử dụng một tham chiếu toàn cục đôi khi rất tốn kém. Ta hãy

ví dụ, một chương trình tạo ảnh chất lượng cao cho một máy trạm đa phương tiện chuyên

dụng. Việc tạo ảnh chất lượng cao trong thời gian thực là một nhiệm vụ đòi hỏi tính toán

rất lớn, cho nên chương trình đó nên được chuyển tới một máy chủ tính toán hiệu năng

cao. Thiết lập một tham chiếu toàn cục tới một máy trạm đa phương tiện nghĩa là thiết lập

một đường truyền thông giữa máy chủ tính toán và máy trạm. Thêm vào đó, còn có quá

trình xử lý tín hiệu ở đồng thời cả máy chủ và máy trạm để đạt tới yêu cầu về băng thông

cho truyền tải ảnh. Kết quả là việc chuyển chương trình sang máy chủ tính toán không

phải là một ý hay, chỉ bởi vì chi phí của tham chiếu toàn cục là quá cao.

Một ví dụ khác cho việc không phải lúc nào cũng có thể thiết lập tham chiếu toàn cục

một cách dễ dàng khi di trú một tiến trình có sử dụng một điểm truyền thông cuối cục bộ.

Trong trường hợp đó, ta phải xử lý một tài nguyên cố định mà theo đó tiến trình được

giới hạn bởi định danh. Có hai giải pháp cơ bản. Một giải pháp đó là để cho tiến trình

thiết lập một kết nối tới máy tài nguyên sau khi nó được di trú và cài đặt một tiến trình

riêng biệt ở máy tài nguyên để làm nhiệm vụ đơn giản là chuyến tiếp tất cả các thông

điệp gửi đến. Điểm hạn chế chính của cách này là nếu như máy tính tài nguyên gặp sự cố

thì việc giao tiếp với tiến trình di trú sẽ bị thất bại. Giải pháp thứ hai đó là cho tất cả các

11

tiến trình có giao tiếp với tiến trình di trú thay đổi tham chiếu toàn cục của chúng, và sau

đó gửi thông điệp tới điểm cuối truyền thông mới trên máy đích.

Tình hình sẽ khác đi trong trường hợp xử lý ràng buộc bởi giá trị. Trước hết hãy xét một

tài nguyên cố định. Sự kết hợp của một tài nguyên cố định và ràng buộc bởi giá trị xảy ra,

ví dụ khi một tiến trình chiếm bộ nhớ được chia sẻ giữa các tiến trình. Thiết lập một tham

chiếu toàn cục trong trường hợp này nghĩa là chúng ta cần thiết lập một dạng phân tán

của bộ nhớ chia sẻ. Trong nhiều trường hợp, đây không thực sự là một giải pháp khả thi.

Tài nguyên gắn kết thường được quy với giá trị của chúng, thường là các thư viện

runtime. Thông thường, các bản sao của các tài nguyên đó đã có ở trên máy đich, hoặc

nên được sao chép trước khi di trú mã được thực hiện. Thiết lập một tham chiếu toàn cục

là cách tốt hơn khi lượng lớn dữ liệu được sao chép, như trường hợp từ điển trong các hệ

thống xử lý văn bản.

Trường hợp dễ nhất là khi xử lý với các tài nguyên tách rời. Giải pháp tốt nhất đó là sao

chép (hoặc di chuyển) tài nguyên tới đích mới, trừ khi nó được chia sẻ bởi một số tiến

trình. Trong các trường hợp khác, thiết lập một tham chiếu toàn cục là lựa chọn duy nhất.

Trường hợp cuối cùng là xử lý ràng buộc bởi loại. Không kể đến ràng buộc tài nguyên –

máy tính, các giải pháp trước đó cố tái liên kết tiến trình với một tài nguyên cục bộ có sẵn

cùng loại. Chỉ khi một tài nguyên không tồn tại, ta mới cần sao chép hoặc di chuyển

nguyên gốc tới đích mới, hoặc thiết lập một tham chiếu toàn cục.

Di trú trong các hệ thống hỗn tạp

Cho tới giờ, chúng ta ngầm định rằng các mã di trú có thể được thực thi dễ dàng ở máy

đích. Giả định này được coi là hợp lệ khi xử lý với các hệ thống hỗn tạp. Một cách tổng

quát, dĩ nhiên, các hệ phân tán được cấu trúc bởi một tập các platform hỗn tạp, đều có hệ

điều hành riêng và kiến trúc máy tính riêng. Di trú trong mỗi hệ thống đó đòi hỏi mỗi

platform được hỗ trợ, theo đó, mọt phân đoạn mã có thể được thực thi trên từng platform.

Mặt khác, chúng ta cũng cần đảm bảo phân đoạn mã có thể tương ứng với mỗi platform.

Các vấn đề đối với tính hỗn tạp trong nhiều khía cạnh giống với vấn đề về tính di động.

và các giải pháp có phần tương đồng. Ví dụ, cuối những năm 1970, một giải pháp đơn

giản để giảm thiểu các vấn đề trong ngôn ngữ Pascal giữa các máy khác nhau là tạo ra mã

tức thì độc lập với máy tính cho các máy ảo trừu tượng (Barron 1981). Các máy ảo đó,

12

không cần phải cài đặt trên các platform, nhưng nó vẫn cho phép các chương trình Pascal

có thể chạy ở bất cứ đâu. Mặc dù ý tưởng đơn giản này được sử dụng rộng rãi trong nhiều

năm, nó chưa bao giờ được coi là một giải pháp cơ bản đê giải quyết vấn đề di động cho

các ngôn ngữ khác, nhất là C.

Khoảng 25 năm sau, di trú mã trong các hệ thống hỗn tạp bị đe doạ bởi sự ra đời của các

ngôn ngữ script và ngôn ngữ có tính di động cao như Java. Về thực chất, những giải pháp

này cũng áp dụng cách giống như đã làm với di trú Pascal. Tất cả các giải pháp này đều

có điểm chung là dựa vào một máy ảo để biên dịch trực tiếp mã nguồn (như trong trường

hợp của các ngôn ngữ script), hoặc các biên dịch các mã được sinh ra bởi một trình biên

dịch (như trong Java).

Các bước phát triển gần đây đã bắt đầu làm giảm đáng kể tính phụ thuộc vào các ngôn

ngữ lập trình. Cá biệt, các giải pháp đề xuất không chỉ di trú tiến trình, mà còn di trú toàn

bộ môi trường tính toán. Ý tưởng cơ bản là phân chia toàn bộ môi trường và cung cấp các

tiến trình trong cùng một phần tầm nhìn của chúng trong môi trường tính toán.

Nếu việc phân chia được làm chính xác, nó dẫn tới khả năng có thể nhân đôi một phần từ

hệ thống cơ sở và di trú tới một máy khác. Theo cách này, di trú thực sự cung cấp một

form di động mạnh cho các tiến trình, chúng có thể được di chuyển ở mọi thời điểm thực

thi, và tiếp tục khi di trú xong. Hơn nữa, nhiêu vấn đề khó hiểu liên quan đến tiến trình di

trú khi chúng được gắn kết với các tài nguyên cục bộ có thể được giải quyết, các gắn kết

này trong nhiều trường hợp đã được dự trữ sẵn. Các tài nguyên cục bộ thường là một

phần của môi trường được di trú.

Có một vài nguyên nhân cho việc di trú môi trường, nhưng dĩ nhiên điều quan trọng nhất

là cho phép sự tiếp tục hoạt động khi một máy tính tắt. Ví dụ, trong một cluster server,

quản trị hệ thống có thể quyết định cho tắt hoặc thay thế một máy tính, nhưng sẽ không

phải ngừng tất cả các tiến trình đang chạy của nó. Thay vào đó, có thể tạm thời đóng

băng môi trường, chuyển nó tới một máy khác và mở đóng băng trở lại. Đó thực sự là

một cách mạnh mẽ để quản lý môi trường tính toán và các tiến trình của chúng.

Ta hãy xét một ví dụ cụ thể về di trú máy ảo, như đã được đề cập bởi Clark(2005). Trong

trường hợp này, tác giả tập trung vào di trú thời gian thực của một hệ điều hành ảo,

thường là sẽ thuận lợi trong một cluster server khi liên kết chặt chẽ đạt tới thông qua một

13

mạng cục bộ đơn và có chia sẻ. Trong các tình huống này, di trú sẽ có 2 vấn đề cơ bản: di

trú toàn bộ ảnh bộ nhớ và di trú liên kết tới tài nguyên cục bộ.

Với vấn đề đầu tiên, trong lý thuyết, ta có 3 cách đề quản lý di trú

• Đẩy các trang bộ nhớ vào máy mới và gửi lại những trang đã được chỉnh sửa sau

trong suốt tiến trình di trú.

• Ngừng máy ảo hiện thời, di trú bộ nhớ, và khởi tạo máy ảo mới.

• Để máy ảo mới yêu cầu mọt trang mới nếu cần, ta sẽ để các tiến trình khởi đầu

trên máy ảo mới ngay lập tức.

Lựa chọn thứ hai có thể dẫn tới thời gian chết quá lớn nếu các máy ảo di trú đang chạy

dichjvuj trực tuyến, nghĩa là các dịch vụ đòi hỏi tính tiếp diễn liên tục. Mặt khác, một

cách tiếp cận theo yêu cầu thuần túy theo phương pháp thứ ba có thể kéo dài chu kỳ di

trú, nhưng sẽ dẫn tới hiệu năng thấp vì sẽ tốn kém nhiều thời gian trước khi làm việc với

các tiến trình di trú được di chuyển tới máy mới.

Như một lựa chọn khác, Clark đề xuất sử dụng cách tiền sao chép khi kết hợp lựa chọn

đầu tiên, kèm theo một pha “dừng và sao chép”(stop-and-copy) như giới thiệu trong lựa

chọn thứ hai. Kết quả của sự kết hợp này có thể dẫn tới thời gian chết không quá 0,2s.

Liên quan đến tài nguyên cục bộ, vấn đề được đưa ra khi xử lý với một cluster server.

Đầu tiên, bởi vì chỉ có một mạng đơn lẻ, điều cần làm chỉ là thông báo về sự gắn kết mới

giữa mạng và địa chỉ MAC, để cho client có thể liên hệ các tiến trình di trú ở đúng card

mạng.

Hiệu quả tổng thể đó là, thay vì di trú tiến trình, chúng ta thực sự có thể thấy toàn bộ một

hệ điều hành có thể được di chuyển giữa các máy tính khác nhau.

3.3. Kết luận

Ta đã thấy được vai trò quan trọng của di trú mã cho các hệ phân tán giữa các máy khác

nhau. Hai nguyên nhân quan trọng để hỗ trợ di trú mã là tăng hiệu năng và tính linh hoạt.

Khi truyền thông tốn kém, chúng ta có thể giảm chi phí bằng cách chuyển bớt tính toán từ

server sang các client, và đề cho client thực hiện tính toán cục bộ các nhiều càng tốt. Tính

linh hoạt tăng lên nếu một client có thể tự động tải về ềm cần thiết dể giao tiếp với server

nhất định. Phần mềm được tải có thể định hướng sẵn tới server, mà không cần client phải

cài đặt trước.

14

Di trú mã đặt ra những vấn đề liên quan tới sử dụng tài nguyên cục bộ mà theo đó yêu

cầu các tài nguyên khác được di trú, gắn kết mới với tài nguyên cục bộ ở máy đích được

thiết lập, hoặc các tham chiếu toàn cục được sử dụng. Một vấn đề khác là di trú mã đòi

hỏi tính hỗn tạp trong tài khoản. Các thí nghiệm hiện tại đưa ra phương án tốt nhất để xử

lý tính hỗn tạp đó là sử dụng các máy ảo.

4. Truyền thông

Truyền thông đa tiến trình là trái tim của hệ phân tán. Hệ phân tán hiện đại chứa hàng

nghìn, thậm chí hàng triệu tiến trình đồng thời hoạt động trong mạng, tiêu biểu như

Internet. Trong phần này, ta sẽ xét tới vai trò của các mô hình truyền thông hiện đại trong

việc đảm bảo tính trong suốt của hệ phân tán:

• Gọi thủ tục từ xa RPC (Remote Procedure Call)

• Triệu gọi đối tượng từ xa ROI(Remote Object Invocation)

• Truyền thông điệp MOM (Message Oriented Middleware)

• Truyền thông hướng dạng (Stream Oriented Middleware)

4.1. Gọi thủ tục từ xa RPC

Rất nhiều hệ phân tán dựa trên việc trao đổi thông điệp chi tiết giữa các tiến trình. Tuy

nhiên các thủ tục truyền và nhận trong giao tiếp không hoàn toàn được che giấu, trong

khi tính trong suốt trong truy cập là một trong những đặc tính quan trọng của hệ phân tán.

Vấn đề này đã được đặt ra từ lâu nhưng chỉ cơ bản được giải quyết khi Birrell và Nelson

(1984) đề ra một cách xử lý giao tiếp hoàn toàn khác.

Hai người đã đề ra một số quy tắc cho phép chương trình gọi các hàm trên máy khác. Khi

một tiến trình trên máy A gọi một hàm trên máy B, tiến trình trên máy A sẽ tạm thời bị

treo và việc xử lý hàm được gọi được thực hiện trên máy B. Thông tin có thể truyền đến

máy được gọi qua các tham số và trả kết quả về trong hàm kết quả. Không có bất kì thông

điệp của tiến trình này biểu hiện ra bên ngoài đối với người lập trình. Đây chính là nội

dung của phương pháp RPC.

Mặc dù ý tưởng đưa ra có vẻ rất đơn giản và hiệu quả nhưng vẫn tồn tại một số vấn đề

như : các hàm trên máy gọi và được gọi chạy trên các máy khác nhau và các máy này xử

lý trên các không gian địa chỉ khác nhau , điều này sẽ tạo ra một số rắc rối,bên cạnh đó

các tham số và kết quả phải được truyền giữa các máy , tuy nhiên nếu các máy này không

15

đồng bộ sẽ dẫn đến một số vấn đề rất phức tạp. Cuối cùng có thể một trong hai máy hoặc

thậm chí cả hai máy đều hoạt động không đúng và mỗi lỗi lại gây ra cac vấn đề khác

nhau. Tuy nhiên, hầu hết các vấn đề trên đều có thể xử lý được và RPC đang trở thành

một công nghệ được sử dụng rộng rãi trên rất nhiều hệ phân tán.

Hoạt động của RPC

- Giải thích cách mà thủ tục có thể xử lý trên các máy khác nhau

Các quy ước trong thủ tục gọi

- Khi một thủ tục được thực hiện , các tham số của nó đươc đẩy vào trong ngăn xếp. Sau

khi thủ tục được thực hiện xong , kết quả được lưu trong thanh ghi. Thủ được trả quyền

điều khiển, các tham số trong ngăn xếp được xóa và ngăn xếp trở về trạng thái trước khi

có lời gọi hàm.

- Các cách truyền tham số:

• Truyền bằng tham trị

• Truyền bằng tham biến

• Truyền bằng cách sao chép và phục hồi ( không phổ biến)

Client stub và Server stub

Cách thức hoạt động của RPC ( cách thức RPC hoạt động một cách trong suốt)

- Client stub và server stub ở máy client và server là thành phần nhằm giảm nhẹ công

việc cho client và server, làm cho hệ thống hoạt động một cách trong suốt hơn.

- Trong mô hình client – server thì lời gọi thủ tục từ xa được thực hiện qua các bước sau:

Một phiên làm việc theo giao thức RPC

(1) Tiến trình muốn thực hiện thủ tục ở máy client sẽ gọi client stub.

16

(2) Client stub sẽ tạo một bản tin và có lời gọi đến hệ điều hành của client đó.

(3) Hệ điều hành của máy client sẽ gửi bản tin đó tới hệ điều hành của máy

server.

(4) Hệ điều hành của server sẽ gửi bản tin tới server stub.

(5) Server stub lấy các thông tin của gói tin và gọi server tương ứng.

(6) Server thực hiện công việc được yêu cầu và trả kết quả về cho server stub.

(7) Server stub đóng gói kết quả đó vào bản tin rồi gọi hệ điều hành của server đó.

(8) Hệ điều hành của máy server này sẽ gửi bản tin kết quả đó hệ điều hành của

máy client.

(9) Hệ điều hành của máy client sẽ gửi bản tin cho client stub.

(10) Client stub sẽ mở gói tin kết quả và trả về cho client.

Truyền các tham số (Parameter Passing)

Chức năng của Client stub là lấy các tham số, gói chúng lại trong một thông điệp rồi

thông qua OS của Client gửi chúng cho Server.

Truyền tham trị (Passing value parameter)

• Parameter marshaling : Đưa các tham số vào một cách tuần tự.

• Ngoài việc đóng gói các tham số của hàm , client stub còn đưa vào cả tên hoặc

định danh của thủ tục được gọi vì server có thề hỗ trợ các hàm khác nhau, nó sẽ

giúp server biết được hàm nào cần được gọi.

• Thông điệp gửi đến server, server xác định thủ tục được gọi theo trường đầu

tiên của thông điệp.Khi server hoàn thành công việc kết quả được tra về cho

client.

• Nếu client và server đồng bộ và các tham số và kết quả là các đại lượng vô

hướng hoặc Boolean thì hệ thống sẽ làm việc hoàn toàn đúng đắn.Tuy nhiên

trong các hệ thống lớn sẽ có rất nhiều các loại máy khác nhau, mỗi dòng máy có

một cách biểu diễn các số, các ký tự và các kiểu dữ liệu khác nhau, điều này dẫn

đến việc hiểu nhầm giữa client và server.

• Nếu không có các thông tin thêm thì gần như là không thể truyền tham số từ

một Client này tới một Server khác.

Truyền tham trị (Passing value parameter )

17

Đây là một vấn đề khó: cách để truyền con trỏ và tham chiếu, vì chúng chỉ có ý nghĩa

trong không gian địa chỉ mà tiến trình sử dụng( trong đó có chứa địa chỉ mà chúng trỏ

đến).

Có hai cách giải quyết

- Cách thứ nhất:Cấm việc sử dụng con trỏ và tham chiếu. Tuy nhiên cách này

không được ưa chuộng.

- Cách thứ hai: nếu ta biết kích thước của mảng dữ liệu. Ta sẽ copy luôn mảng dữ

liệu đó và gửi cho server .Khi đó server sẽ sử dụng được con trỏ và tham chiếu

đến chính mảng dữ liệu này. Sau khi server hoàn thành công việc mảng này sẽ

được gửi lại cho client stub sau đó copy lại cho client.Trong trường hợp này

truyền tham chiếu được thay thế bằng cách truyền theo kiểu sao chép và phục hồi.

- Mặc dù chúng ta đã xử lý được con trỏ với cấu trúc mảng đơn giản , nhưng chúng

ta vẫn chưa xử lý được phần lớn các trường hợp con trỏ với cấu trúc dữ liệu tùy

biến ví dụ như bản đồ

Chi tiết hóa các tham số và sinh Stub (Parameter Specification and Stub Generation)

Giải pháp cho các vấn đề trên

Khi thực hiện một RPC thì cả Client lẫn Server phải thống nhất với nhau về định

dạng của thông điệp sẽ được trao đổi giữa chúng.Chúng sẽ phải theo một giao

thức chung, nếu không PRC sẽ làm việc không đúng đắn

Định nghĩa cấu trúc dữ liệu là một khía cạnh của giao thức RPC tuy nhiên chưa

đủ. Điều ta cần đến là sự thỏa thuận giữa Client và Server về mô tả các cấu trúc

dữ liệu đơn giản Integer, Characters, Boolean…( ví dụ, giao thức sẽ yêu cầu biểu

diễn các kí tự dưới dạng 16 bit Unicode và float được định dạng theo chuẩn

IEEE754, và dữ liệu được lưu trữ theo kiểu đầu nhỏ …) . Với những thông tin

thêm này, thông điệp được tạo ra rất rõ ràng. Thêm một điều nữa, cả client và

server sẽ phải thỏa thuận về cách truyền thông điệp ( ví dụ sử dụng truyền thông

hướng kết nỗi như TCP/IP).

Trong thực hành ta thấy rằng là sử dụng ngôn ngữ định nghĩa giao diện IDL

(Interface Definition Language) gần như đơn giản hóa các ứng dụng Client-

Server dựa trên RPC.

18

RPC dị bộ (Asynchronous RPC)

• Trong hoạt động của một RPC thì khi Client gửi thông điệp (gọi thủ tục) nó sẽ

dừng lại chờ kết quả trả về từ Server, tuy nhiên việc này gây ra sự lãng phí phía

Client, nhất là khi có nhiều việc cần Client phải thực hiện.

• Trong gọi thủ tục từ xa không đồng bộ thì Client sẽ tiếp tục làm việc ngay mà

không phải chờ cho tới khi nó nhận được phản hồi từ phía Server. Phản hồi này

được gửi tới Client ngay khi Server nhận được thông điệp từ Client, và sau đó

Server tiếp tục xử lý cho ra kết quả rồi gửi trở lại Client.

RPC đồng bộ trễ (Deferred synchronuos RPC)

Thực hiện hai lời gọi, một từ client và một từ server. Client gửi tới server lời gọi

thủ tục và chờ bản tin chấp nhận từ server. Phía server sẽ gửi bản tin chấp nhận về cho

client thông báo đã nhận được yêu cầu và bắt đầu thực hiện yêu cầu RPC đó. Lúc này

client sẽ tiếp tục thực hiện công việc của mình. Khi thực hiện thủ tục xong, server sẽ thực

hiện lời gọi tới client báo nhận lấy kết quả. Client thực hiện ngắt, nhận kết quả và gửi lại

cho server bản tin thông báo đã nhận kết quả thành công.

19

RPC đồng bộ trễ

RPC đơn tuyến (one- way RPC)

Sau khi thực hiện lời gọi thủ tục từ xa tới server, client không chờ đợi thông báo

nhận yêu cầu thành công từ server mà tiếp tục thực hiện ngay các công việc khác của

mình. Đó là RPC đơn tuyến. Tuy nhiên điều này không đảm bảo độ tin cậy do client

không biết liệu yêu cầu có được thực hiện hay không. Trong trường hợp RPC đồng bộ bị

hoãn lại, client có thể hỏi server xem kết quả có được thực hiện hay không mà không đợi

server thông báo lại cho client.

5. Định danh

Tên giữ một vai trò rất quan trọng trong tất cả các hệ thống máy tính. Chúng thường được

sử dụng để chia sẻ tài nguyên, nhận biết các thực thể duy nhất, tương ứng với các vị trị và

hơn nữa. Một vấn đề quan trọng của việc định danh đó là tên có thể được phân giải tới

thực thể tương ứng. Ngoài ra, việc định danh cũng có vai trò quan trọng trong việc đảm

bảo tính trong suốt về vị trí ytong hệ phân tán. Giải pháp định danh cho phép một tiến

trình truy cập tới thực thể đã được đặt tên. Để phân giải tên, cần phải bổ sung hệ thống

định danh. Sự khác nhau giữa việc đặt tên trong hệ phân tán và hệ không phân tán nằm ở

cách hệ thống đặt tên được thực hiện.

Một số kiểu định danh :

Tên (Name)

Địa chỉ (Address) Định danh (ID)

Một xâu bit/char để tham chiếu đến 1 thực thể trong hệ phân tán

Một tên đặc biệt có các tính chất :Một ID tham chiếu tới nhiều nhất một thực thểMỗi thực thể được tham chiếu bởi nhiều nhất một IDMột ID luôn tham chiếu tới cung một thực thể

Một xâu bit/char để tham chiếu đến 1 thực thể trong hệ phân tán

20

• Định danh phẳng (Flat Naming): ID là chuỗi bit ngẫu nhiên, phi cấu trúc. Một

tính chất quan trọng là nó không chứa bất cứ thông tin nào về vị trí điểm truy

cập của thực thể liên kết.

• Định danh có cấu trúc (Structured Naming): Định danh phẳng thích hợp với

máy nhưng nó gây khó khăn cho người sử dụng. Do đó ra đời một hệ thống

định danh hỗ trợ các tên có cấu trúc, phù hợp với con người, phục vụ không chỉ

hệ thống tên file mà cả hệ thống tên host trên internet.

• Định danh theo thuộc tính là cách mô tả một thực thể theo một cặp (thuộc tính,

giá trị). Theo cách định danh này, một thực thể có một tập hợp liên kết các thuộc

tính, mỗi thuộc tính lại mô tả một vài điều về thực thể này. Bằng việc chỉ rõ ra

giá trị mà thuộc tính có thể có, người sử dụng ràng buộc bản chất của các thực thể

mà anh ta quan tâm. Công việc của hệ thống định danh là trả về một hay nhiều

thực thể hợp với những mô tả đã được người sử dụng cung cấp.

6. Đồng bộ hoá

Trong hệ phân tán, vai trò của vấn để đảm bảo tính ổn định và thống nhất hoạt động.

chúng ta sẽ tìm hiểu bằng cách nào các tiến trình đồng bộ hóa được với nhau. Ví dụ, thay

vì nhiều tiến trình đồng thời truy nhập vào một tài nguyên chia sẻ thì chúng cấp quyền

truy nhập tạm thời cho nhau. Một ví dụ khác, nhiều tiến trình đôi khi cần trả lời cho 1 sự

21

kiện nào đó, nói cách khác, cần xác định thông điệp m1 của tiến trình P được gửi trước

hay sau thông điệp m2 cùa tiến trình Q.

Đồng bộ hóa trong các hệ thống phân tán thường khó hơn rất nhiều so với đồng bộ hóa

trong các hệ đơn hoặc đa xử lý.

Ta sẽ hướng tới đồng hộ hóa dựa trên thời gian hoạt động, tức là thời gian có tính tương

quan giữa các tiến trình hơn là thời gian tuyệt đối.

Trong nhiều trường hợp, đồng bộ hóa có thể được giải quyết bằng cách một nhóm các

tiến trình có thể sử dụng 1 tiến trình được thực thi bằng cách lấy trung bình một vài thuật

toán lựa chọn.

7. Tính nhất quán và sử dụng bản sao

Dữ liệu nói chung trong hệ phân tán được nhân lên thành nhiều bản để tăng thêm tính tin

cậy và tăng hiệu năng. Vấn đề chính của các bản sao là sự nhất quán giữa các bản sao khi

một hoặc 1 số bản sao bị thay đổi. Ta cần quan tâm tới 2 vấn đề : quản lý bản sao và giữ

các bản sao được nhất quán khi xây dựng hệ phân tán.

• Để tăng tín tin cậy cho hệ thống : Trong quá trình đọc hoặc ghi dữ liệu , nếu một

bản sao bị hỏng hoặc vì lý do nào đấy nó không sẵn sàng để dùng thì ta có thể sử

dụng một bản khác và tránh việc sử dụng dữ liệu sai lạc, không chính xác.

• Để tăng hiệu năng của hệ thống : Tăng quy mô của hệ thống cả về số lượng lẫn

phạm vi địa lý, như nếu số lượng máy tăng thì tải trên mỗi máy trong hệ phân tán

cũng không tăng lên nhiều hơn. Nếu phạm vi địa lý tăng ta có thể sử dụng các bản

nhân bản gần khu vực địa lý đó .

Một cái giá phải trả cho việc nhân bản dữ liệu đấy là phải chắc chắn rằng khi một bản sao

được cập nhật thì tất cả những bản còn lại cũng phải được cập nhật theo để đảm bảo tính

nhất quán của dữ liệu. Điều này ảnh hưởng rất lớn đến hiệu năng của hệ thống.

Ví dụ : khi sử dụng các chương trình xem web => dữ liệu được ghi vào bộ nhớ máy tính (

bản sao ) , nếu trang web nội dung thay đổi . người dùng vẫn chỉ xem nội dung trên máy

=> cũ . Vấn đề đồng bộ dữ liệu trên máy khách và trên máy chủ

Có 2 hướng tiếp cận cho việc nhân bản đối tượng.

Ứng dụng tự chịu trách nhiệm nhân bản. Do đó ứng dụng cần giải quyết được vấn

đề nhất quán.

22

Hệ thống trung gian đảm trách việc nhân bản. Vì thế vấn đề nhất quán do

middleware đảm trách. Hướng này đơn giản hóa cho việc phát triển ứng dụng

nhưng lại khiến các giải pháp đặc tả đối tượng trở nên phức tạp hơn.

8.Tính chịu lỗi (Fault Tolerance)

Một đặc tính của hệ phân tán khác biệt với các hệ thống máy đơn lẻ là khái niệm lỗi bộ

phận, xảy ra khi một thành phần của hệ thống gặp sự cố. Lỗi này có thể ảnh hưởng đến

hoạt động của các thành phần khác, trong khi một số thành phần không chịu bất cứ ảnh

hưởng nào. Ngược lại, sự cố trong các hệ không phân tán thường làm cả hệ thống phải

ngừng hoạt động.

Mục đích quan trọng của hệ phân tán là xây dựng theo cách có thể tự động khôi phục lỗi

mà không ảnh hưởng đến hiệu năng hoạt động. Khi gặp sự cố, hệ thống có thể tiếp tục

hoạt động ở mức chấp nhận được trong khi sửa lỗi được tiến hành ngay, có nghĩa là có

thể chịu lỗi và tiếp tục thực thi thêm một số sự kiện dù có lỗi.

8.1. Một số định nghĩa

Một hệ thống có khả năng chịu lỗi là một hệ thống đảm bảo được những yêu cầu sau:

• Tính sẵn sàng

• Tính tin cậy

• Tính an toàn

• Khả năng duy trì hoạt động (maintainability).

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 trong khả năng.

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 giờ, tính sẵn sàng của nó đạt đến 99,9999 % nhưng vẫn

23

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 ngừng trong 2 tuần của một tháng nhất định 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ế 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 toàn an

ninh cao, đặc biệt khi nó đi đến vấn đề như tính toàn vẹn.

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 gặp lỗi khi nó không thể cung cấp được một trong những dịch vụ đó.

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.

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 đang gặp 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ỗ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.

• 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.

24

• 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.2. Các mô hình lỗi

Một hệ thống lỗi là khi nó không cung cấp đầy đủ các dịch vụ như 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 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. 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 như sau:

• Lỗi sụp đổ (Crash failure) xảy ra khi một server ngừng hoạt động trước dự kiến,

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

25

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

crash lỗi này khá thường xuyên. Lỗi này 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.

• Lỗi bỏ sót (Omission failure) xảy ra khi server không có khả năng nhận hay đáp

ứng đầy đủ 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 lắng

nghe các request gửi đế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ó. 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 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.

• Lỗi thời gian (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ư 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 bên 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 chỉ xảy ra ở mức server phản hồi

quá chậm dẫn đến giảm hiệu năng của hệ thống.

• Lỗi đáp ứng (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ý.

26

• Lỗi tuỳ tiện (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 những đầu ra 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, có

quan hệ chặt chẽ với lỗi sụp đổ. Trong thực tế, khi xảy ra server sẽ ngừng tạo ra

những đầu ra, 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.

Dĩ nhiên trong thực tế, những server ngừng hoạt động do lỗi sụp đổ và lỗi bỏ sót 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 hệ thống im lặng khi xảy ra lỗi

(fail-silent system), 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 lỗi hiệu năng (performance

failure).

Cuối cùng, có nhiều trường hợp mà server đưa ra những kết quả ngẫu nhiên, nhưng kết

quả 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 lỗi tuỳ

tiện vô hại. Lỗi này cũng được gọi là lỗi an toàn (fail-safe failure).

Sau đây ta sẽ đưa ra một số giải pháp để đảm bảo tính chịu lỗi cho hệ phân tán.

8.3. Che dấu lỗi bằng sự 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à: dư thừa về thông tin (information redundancy), dư thừa

về thời gian (time redundancy) và dư thừa về vật lý (physical redundancy).

• Dư thừa thông tin: 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.

• Dư thừa thời gian (Time redundancy): 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. 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ì. Dư thừa thời gian tỏ ra đặc biệt hữu ích khi lỗi là tạm thời hoặc không

liên tục.

27

• Dư thừa vật lý (Physical redundancy): 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 thiếu sót hoặc hoạt động sai

chức năng của một số thiết bị, 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.

Ở hình vẽ trên, 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 b, 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 ra sẽ được

đưa và các bộ chọn (voter)V1, V2, V3. Đó là các mạch điện có 3 đầu vào và 1 đầu ra. 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ì đầu ra sẽ không

xác định. Thiết kế như vậy được gọi là dư thừa module bậc ba 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 giấu, vì vậy tín hiệu vào

cho B1, B2, B 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 cùng lỗi, tổn hại của nó đối với hệ thống cũng được che

giấu tốt và hệ thống vẫn hoạt động bình thường.

28

Một điều nữa là tại sao tại mỗi module phải có tận 3 bộ chọn? Hiển nhiên là các bộ chọn

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 bộ

chọn 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.

Phục hồi tiến trình

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 ta đưa ra cách thức ngăn chặn lỗi xảy ra, tiếp theo 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 và 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.

Thiết kế

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 và cùng có khả năng nhận khi bản tin được gửi đến. Theo cách này,

nếu một tiến trình trong nhóm lỗi, các tiến trình khác có thể thay thế 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 tiến trình có thể tham gia vào một nhóm trong nhiều nhóm mà nó có mặt và trong

trường hợp có nhiều nhóm cùng yêu cầu thực hiện một công việc nào đó, nó sẽ được tự

do lựa chọn.

• Nhóm phẳng: tất cả các tiến trình là ngang bằng nhau. Không có tiến trình chủ và

mọi quyết định đều được thực hiện dựa theo tập thể.

• Nhóm phân cấp (Hierarchical Group): có một tiến trình đóng vài trò điều phối và

tất cả các tiến trình khác cùng tuân thủ. Trong mô hình này, khi một yêu cầu cho

29

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 tiến trình trong nhóm đó đều được gửi đến ttt diều phối. Tiến trình điều phối

sau đó quyết định tiến trình nào trong nhóm thích hợp nhất để thực hiện và sẽ

chuyển đến nó.

Mỗi loại trong mô hình trên đều có những ưu và nhược điểm của nó. Nhóm phẳng là cân

đối, 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 tiến trình điều phối dẫn đến

toàn bộ nhóm ngừng hoạt động nhưng khi tiến trình điều phối 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ân bản và che giấu lỗi

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). Có 2 cách để đạt được sự sao chép như vậy: giao thức

30

primary-based (primary-based protocols) hoặc các giao thức ghi bản sao (repilcated-write

protocol).

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 các hệ

thống ghi bản sao (replicated-write system). Một hệ thống được gọi là chịu lỗi k (k-fault

tolerance) nếu nó có thể hoạt động đúng với k 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.

Thoả thuận trong hệ thống gặp lỗi

Việc tổ chức các tiến trình giống nhau và cùng nhóm giúp tăng khả năng chịu lỗi. 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+1 tiế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 tiến trình

điều phối, thực hiện một giao dịch, phân chia công việc cho các tiến trình trong nhóm ....

Nếu tất cả sự truyền thông và các tiến trình 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 thuật toán thoả thuận phân chia (distributed agreement algorithm) là

có tất cả những tiến trình không lỗi đạt được sự đồng thuận trong một số vấn đề, và thực

hiện sự đồng thuận ấy trong một số nhất định các bước. Trong thực tế, các giả thuyết

khác nhau về hệ thống bên dưới (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:

• Đồng bộ hay không đồng bộ: hệ thống đồng bộ khi các tiến trình cùng hoạt động

trong chế độ lock-step, có nghĩa là với hằng số c thì nếu bất kỳ tiến trình nào thực

hiện c+1 bước thì các tiến trình khác cũng đã thực hiện ít nhất 1 bước. Hệ thống

không thực hiện đồng bộ gọi là hệ không đồng bộ.

• Độ trễ về truyền thông (Communication delay) là có giới hạn hay không? Độ trễ

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.

31

• 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 bên 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ó cơ chế nào đảm bảo điều đó.

• Việc truyền các bản tin là đơn điểm (unicasting) hay đa điểm (multicasting).

Với các điều kiện trên, việc đạt được sự đồng thuận giữa các tiến trình xảy ra như trong

hình vẽ dưới đây. Trong tất cả các trường hợp khác, không có bất kỳ giải pháp nào. 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 đơn điểm (unicast), và độ trễ có giới hạn. Do đó, chúng ta phải

truyển các bản tin theo đúng thứ tự, giống như trong TCP.

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át hiện lỗi là một

trong phần quan trọng của tính chịu lỗi, 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. Có 2 phương pháp chính :

• Chủ động: tiến trình gửi bản tin dạng “còn sống không ?” (“are you alive?”) tới

mỗi thành viên khác

• Thụ động: tiến trình chờ bản tin được gửi đến từ các tiến trình khác.

32

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ác lý thuyết về phát hiện 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 phương pháp này sẽ đưa đến kết quả không chính xác trong

hệ thống mạng không tin cậy.

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 tiến

trình lân cận. Các tiến trình đều đặn thông báo các dịch vụ mà nó đang cung cấp nên 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à 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 tiến trình lân cận nó có lỗi hay không. Thay vào đó, khi một nút phát hiện

một không gửi tin được đến một nút lân cận, nó sẽ yêu cầu các nút lân cận khác xác định

xem liệu chúng có thể gửi tin đến nút đó không, sau đó sẽ thông báo kết quả đến nút này.

TRUYỀN THÔNG 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.

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

33

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 yêu cầu đó. Nếu bên client nhận thấy có quá nhiều yê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 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:

34

Đợ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 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.

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 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 đượ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 yê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ẽ

35

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 toán từ xa nào đó không. Nếu có, máy đó

sẽ cố xác định xem client nào đã gửi yêu cầu này. Nếu không xác định

được thì quá trình tính toá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ý.

CHE GIẤU LỖI TRONG TRUYỀN THÔNG NHÓM TIN CẬY (DÙNG

MULTICASTING)

Cơ chế Multicasting tin cậy cơ bản

Sau khi các tiến trình đã được phân nhóm thì một tiến trình khác muốn thực hiện

multicast tức là sẽ gửi bản tin tới tất cả các tiến trình trong nhóm đó. Multicast tin cậy là

phải có cơ chế để đảm bảo bản tin đó đến được tất cả các thành viên trong nhóm. Khi xảy

ra lỗi thì sẽ áp dụng phương pháp sau để che giấu lỗi.

Phương pháp: đánh số các bản tin cần gửi. Các bản tin được lưu tại một buffer của bên

gửi và vẫn lưu ở đó cho đến khi nhận được bản tin ACK báo về từ bên nhận. Nếu bên

nhận xác định là bị mất một bản tin nào đó thì nó sẽ gửi về một bản tin NACK để yêu cầu

gửi lại. Và thông thường, bên gửi sẽ tự động gửi lại bản tin sau trong khoảng thời gian

xác định nào đó mà nó không nhận được bản tin ACK báo về.

36

Tuy nhiên phương pháp này phải trả giá đắt do ta phải đưa thêm thông tin cho mỗi lần

truyền, và việc truyền lại phải sử dụng tới truyền thông điểm-điểm cho mỗi quá trình yêu

cầu, hoặc sử dụng thông điệp muilticast gửi tới tất cả các tiến trình.

Hình (a). Truyền bản tin (b). Bản tin phản hồi

Khả năng mở rộng trong truyền Multicast tin cậy

Vấn đề đặ ra là cơ chế muilticast không có khả năng hỗ trợ số lượng lớn các bên nhận.

Bên gửi sẽ phải gửi số lượng lớn các bản tin, đồng thời phải nhận khhong ít các thông

điệp gửi vể trong trường hợp mạng diện rộng. Từ đo xuất hiện giải pháp sau.

Điều khiển phản hồi không thứ bậc (Nonhierarchical Feedback Control)

Ý tưởng chủ đạo của phương pháp là giảm số lượng các thông điệp phản hồi tới bên

gửi,với mô hình hiện đại được ứng dụng nhiều là ngăn chặn phản hồi (feedback

suppression), sử dụng giao thức Scalable Reliable Multicasting (SRM) , được phát triển

bởi Floyd (1997).

Trong giao thức này, bên nhận chỉ gửi thông điệp khi mất gói tin, nó bị mất thế nào sẽ

giao cho ứng dụng. Khi bên nhận thấy mất gói tin, nó multicast tới tất cả các thành viên

trong nhóm.

37

Điều này cho phép các thành viên trong nhóm ngăn chặn số lượng lớn các thông điệp

phản hồi. Do sự truyền các thông điêp là nối tiếp nhau, bên gửi chỉ phải nhận một thông

điệp duy nhất.

Mô hình này được sử dụng trong các cơ chế lớp dưới dành cho các ứng dụng Internet.

Tuy nhiên nó cũng phải nhiều vấn đề, tiêu biểu như các tiến trình gửi thành công thông

điệp lại bị ngắt do các thông điệp phản hồi của các tiến trình đứng sau nó. Một giải pháp

cho vấn đề này là để các bên nhận huy đi các thông điệp giống nhau trong nhóm và chia

sẻ kênh truyền multicast với các thông điệp phản hồi và sự truyền lại.

Điều khiển phản hồi có thứ bậc (Nonhierarchical Feedback Control)

Để có thể thực hiện multicast tin cậy cho một nhóm lớn các tiến trình thì thực hiện tổ

chức các nhóm theo cấu trúc dạng cây. Cấu trúc của cây :

Gốc là nhóm chứa tiến trình gửi.

Các nút là các nhóm có chứa tiến trình nhận.

38

Multicast tin cậy dạng cây

Việc thực hiện multicast được thực hiện cho các nhóm nhỏ đó. Việc chia thành các nhóm

nhỏ hơn này cho phép sử dụng các kịch bản multicast tin cậy cho từng nhóm nhỏ đó.

Trong mỗi nhóm nhỏ sẽ đề cử một tiến trình làm điều phối. Tiến trình điều phối có khả

năng điều khiển việc truyền lại khi nhận được thông báo truyền lỗi. Tiến trình điều phối

của mỗi nhóm sẽ có bộ đệm lưu trữ (history buffer) riêng.

Nếu tiến trình điều phối của mỗi nhóm không nhận được bản tin thì nó sẽ gửi yêu cầu

truyền lại tới tiến trình điều phối của nút cha nó.

Trong kịch bản truyền tin cậy sử dụng bản tin ACK thì khi tiến trình điều phối nhận

thành công một bản tin, nó sẽ gửi bản tin ACK tới tiến trình điều phối của nút cha nó.

Nếu tiến trình điều phối của một nhóm nhận được bản tin ACK báo nhận thành công bản

tin của tất cả các tiến trình trong nhóm gửi về thì nó sẽ xóa bản tin khỏi bộ đệm của nó.

Đánh giá: với phương pháp phân cấp này thì xảy ra vấn đề về cấu trúc cây. Rất nhiều

trường hợp yêu cầu cây phải có cấu trúc động. một phương pháp tiếp cận là sử dụng

trong các mạng hạ tầng. Về nguyên tắc, hướng tiếp cận này sử dụng các router trong lớp

mạng như các router điều phối cục bộ. Tuy nhiên điều này rất khó thực hiện trong thực

tế.

Để kết thúc, ta thấy xây dựng cơ chế multicast đáng tin cậy cho số lượng lớn các bên

nhận thông qua các mạng diện rộng là vấn đề rất khó. Không tồn tại bất cứ giải pháp đơn

lẻ nào, và mỗi giải pháp lại làm nảy sinh những vấn đề mới.

Multicast nguyên tử (Atomic multicast)

Một trong các vấn đề được đặt ra là đảm bảo các thông điệp được phân phối tới mỗi tiến

trình hoặc không gửi tới bất cứ tiến trình nào trong tình huống xảy ra lỗi tiến trình. Đồng

thời, ta cũng cần đảm bảo chúng được gửi đúng thứ tự, đó là vấn đề muilicast nguyên tử.

Khi một tiến trình muốn gửi bản tin cho một tập các tiến trình khác theo kiểu multicast,

nó sẽ không gửi bản tin tới tất cả các tiến trình của nhóm chứa các tiến trình nhận mà chỉ

gửi đến một nhóm nhỏ các tiến trình cần nhận bản tin đó.

Vấn đế đặt ra: phải đảm bảo gửi được bản tin tới tất cả các tiến trình trong nhóm hoặc

không được gửi tới bất kì tiến trình nào nếu một tiến trình trong nhóm bị lỗi sụp đổ.

39

Một số thuật ngữ:

• Khung nhìn nhóm (Group view): ý tưởng chính của atomic multicast là một tiến

trình thực hiện multicast bản tin m thì chỉ thực hiện liên kết tới một danh sách các

tiến trình cần nhận bản tin m đó chứ không phải toàn bộ nhóm. Danh sách các tiến

trình này tương ứng với một khung nhìn nhóm - một tập nhỏ các tiến trình của

một nhóm lớn.

• Thay đổi khung nhìn (View change): khi đang thực hiện multicast tới một group

view G mà có một tiến trình xin gia nhập nhóm hay xin ra khỏi nhóm thì sự thay

đổi vc này sẽ được gửi tới tất cả các thành viên còn lại trong nhóm. Do đó, các

tiến trình còn lại trong G sẽ nhận được hai bản tin:

m: bản tin cần nhận

vc: bản tin thông báo có thay đổi trong G.

Nếu tất cả các tiến trình trong G đều chưa nhận được vc thì thao tác multicast bản tin m

được thực hiện.

Nếu một trong số các tiến trình trong G đã nhận được vc thì phải đảm bảo rằng không

một tiến trình nào khác trong G được nhận m nữa.

Đồng bộ ảo (Virtual sychronous)

Nguyên tắc này đảm bảo bản tin chỉ được multicast tới tất cả các tiến trình không có lỗi.

Nếu tiến trình gửi bị sụp đổ trong quá trình multicast thì quá trình này bị hủy ngay dù bản

tin đó đã được gửi tới một vài tiến trình khác trong nhóm rồi.

40

Nguyên lý đồng bộ ảo

P1 tham gia vào nhóm đã có sẵn ba thành viên: P2,P3, P4.

P2 thực hiện multicast bản tin tới tất cả các tiến trình còn lại.

P1 thực hiện multicast bản tin tới tất cả các tiến trình còn lại.

P3 multicast tới tiến trình P2 , P4 thành công nhưng P1 chưa nhận được thì P3 bị

sụp đổ. Lúc này đồng bộ ảo sẽ hủy tất cả các bản tin đã được gửi trước đó cho P2,

P4, thiết lập trạng thái trước khi sụp đổ của P3 là chưa gửi bản tin dó.

nhóm lúc này chỉ còn P1, P2, P4 và P4 thực hiện multicast bản tin,

P3 được khôi phục và xin gia nhập lại nhóm.

P3 gia nhập nhóm thành công.

Lập thứ tự cho thông điệp (Messsage Ordering)

Chúng ta quan tâm tới 4 cách xếp thứ tự cho thông điệp :

• Multicast không có thứ tự

• Multicast theo thứ tự FIFO

• Multicast theo thứ tự nhân quả

• Multicast theo thứ tự tổng hợp

Trong thực tế, multicast không thứ tự là multicast đồng bộ ảo không có sự đảm bảo về

thứ tự của các thông điệp được truyền đi bởi các tiến trình.

41

Tiến trình P1 gửi thông điệp m1 và m2 tới 2 tiến trình P2 và P3 trong nhóm, giả sử không

có sự cố gì xảy ra thì tiến trình P2 sẽ nhận dược thông điệp theo thứ tự m1 và m2, nhưng

do không có thứ tự về thông điệp nên P3 có thể sẽ nhận thông điệp m2 trước khi nhận

thông điệp m1.

Multicast FIFO,lớp truyền thông buộc các thông điệp gửi đến tuân theo đúng thứ tự được

gửi nếu nó đến từ cùng một tiến trình. Tuy nhiên lại có vấn đề về việc thứ tự các tiến

trình gửi. Ví dụ, 2 tiến trình P1 gửi thông điệp m1 và m2, P2 gửi thông điệp m3 và m4

tới cho 2 tiến trình P3 và P4 thì có khả năng P3 sẽ nhận được theo thứ tự (m1, m3, m2,

m4) trong khi P4 sẽ nhận theo thứ tự (m3, m1, m2, m4).

Multicast theo thứ tự nhân quả gửi thông điệp có tính nhân quả. Nếu thông điệp m1 xảy

có tính nhân quả (xảy ra trước) thông điệp m2, thì dù thông điệp nào đến trước, lớp ứng

dụng luôn đặt m2 sau m1. Phương pháp này có thể thực thi bằng cách sử dụng tem thời

gian.

Bên cạnh 3 kiểu thứ tự trên, sự phân phối theo thứ tự tổng hợp mang ý nghĩa : dù các

thông điệp theo sạng không thứ tự, dạng FIFO hay nhân quả, cần điều kiện ràng buộc

đảm bảo khi được truyền đi, thông điệp đi theo đúng thứ tự tới tất cả các thành viên trong

nhóm.

Multicast tin cậy đồng bộ ảo sử dụng cáh thức phân phối theo thứ tự tổng hợp được gọi là

multicast nguyên tử. Với 3 loại ràng buộc về thứ tự trên, ta có 6 kiểu multicast đáng tin

cậy.

Sự phục hồi lỗi

Phục hồi lỗi (recovery error) là một trong những cách hiệu quả của việc giúp tăng khả

năng chịu lỗi (fault tolerance) của hệ thống phân tán. Có 2 dạng phục hồi lỗi chính :

• Phục hồi lùi (Backward recovery) : đưa trạng thái của hệ thống ở thời điểm hiện

tại về trạng thái tại thời điểm trước khi lỗi xảy ra. Để làm được điều đó, ta cần

42

thiết phải ghi lại trạng thái của hệ thống ở các thời điểm liên tục ( time to time ).

Mỗi thời điểm lưu trữ lại đó người ta gọi là “checkpoint”.

• Phục hồi tiến (Forward recovery): khi hê thống rơi vào trạng thái lỗi, thay vì đưa

hệ thống trở lại trạng thái trước khi lỗi, cách này lại đưa hệ thống nhảy sang một

trạng thái mới mà ở đó hệ thống lại hoạt động bình thường. Vấn đề chính trong

phương pháp này là phải dự đoán trước được khi nào lỗi có thể xảy ra. Chỉ có vậy

nó mới sẵn sàng chuyển hệ thống sang trạng thái mới.

Sự khác nhau giữa lùi và tiến chính là sự tin cậy trong truyền thông. Thông thường cách

tốt nhất để phục hồi lỗi trong quá trình truyền thông là thông báo cho bên gửi nhằm gửi

lại những gói tin đã bị mất trong quá trình truyền (bằng cách chuyển về trạng thái trước

lỗi, xem những gói nào bị mất để yêu cầu truyền lại). Phục hồi lùi được sử dụng rộng rãi

do tính tin cậy hơn trong truyền thông.

Cách thứ 2 là sử dụng phương pháp sửa chữa các bản đã mất (erasure correction). Ý

tưởng chính của phương pháp là gói tin bị mất có thể được khôi phục lại dựa trên những

gói tin khác, như việc nó quy định số lượng gói tin sau có thể phục hồi được gói tin trước,

bên gửi sẽ tiếp tục truyền gói cho đến khi một gói đã mất được dựng lại, đó chính là tư

tưởng của khôi phục tiến. phương pháp này phục hồi hệ thống tại thời điểm sau lỗi để

đảm bảo hệ thống có thể hoạt động đúng nên rất khó thực hiện trong thực tế. Do đó khôi

phục lùi vẫn là biện pháp cơ bản nhất trong hệ phân tán.

Tuy nhiên phục hồi lùi vẫn tồn tại những hạn chế:

• Việc phục hồi lại hệ thống ở trạng thái trước đôi khi rất phức tạp.

• Phương pháp không có sự đảm bảo rằng sau khi trở lại trạng thái trước lỗi, có khả

năng lỗi lại tiếp tục xảy ra dẫn đến tình trạng lặp vô hạn.

• Không phải lúc nào cũng có những trạng thái trước khi lỗi để ta quay lại ( giống

như đi rút tiền, máy gặp sự cố, ít có cơ hội quay lại trạng thái trước khi ấn nút rút

để tiếp tục rút tiền).

Sau đây ta sẽ mô tả vài biện pháp khôi phục được sử dụng trong thực tế.

Để có thể khôi phục trạng thái trước lỗi của hệ thống, buộc phải lưu trữ những thông tin

cần thiết cho sự khôi phục. Có 3 cách lưu trữ những thông tin này :

• Lưu trữ trong RAM ( nhưng bị xóa khi mất điện )

43

• Lưu trữ trong đĩa ( vẫn sống khi CPU lỗi nhưng mất khi khi đĩa hỏng)

• Sử dụng lưu trữ tĩnh (Stable storage).

Kho lưu trữ tĩnh (Stable strorage):

Được thực hiện như 2 đĩa thông thường. Mỗi khối trong đĩa 2 sẽ được copy giống hệt như

khối ở đĩa 1. Khi một khối ở đĩa 1 được cập nhật thì nó cũng được cập nhật ở đĩa 2 ( sau

khi đã cập nhật xong ở đĩa 1.

• Hình a : 2 đĩa sao chép y nguyên nhau.

• Hình b : trường hợp hệ thống gặp lỗi khi đĩa 1 đã được update còn đĩa 2 chưa

được cập nhật. Để tiến hành phục hồi, tiến hành so sánh 2 đĩa với nhau từng khối

một, thấy sự sai khác nó lại cập nhật để 2 cái giống nhau.

• Hình c: trường hợp có những khối tự động lỗi. Khi đó sẽ có 1 checksum error

được từ khối ổn định trước nó. Nếu lỗi được phát hiện, khối bị lỗi sẽ được khôi

phuc lại theo đĩa còn lại.

Ưu điểm của lưu trữ tĩnh là tính tin cậy do được ghi đồng thời, sau đó được kiểm tra lại

nên ít khả năng có lỗi xảy ra.

Checkpointing :

Trong hệ phân tán, khôi phục lùi yêu cầu hệ thống lưu lại trạng thái trong kho lưu trữ

tĩnh. Nếu tiến trình P ghi lại trạng thái thu nhận một thông điệp, sẽ có tiến trình Q ghi

44

nhận sự gửi đi thông điệp. Mỗi tiến trình lưu lại trạng thái theo trình tự thời gian vào kho

lưu trữ. Để khôi phục, chỉ cần lấy ra trạng thái tốt gần nhất để khôi phục lại hệ thống.

Checkpointing độc lập

Khi một tiến trình gặp lỗi, động tác khôi phục lùi được thực thi. Tuy nhiên vấn đề nảy

sinh là ở chỗ nếu một tiến trình khôi phục trạng thái tốt gần nhất của nó thì điều đó không

đảm bảo rằng trạng thái đó là tốt nhất cho toàn bộ hệ thống. Nói cách khác, trạng thái này

có thể ứng với trạng thái lỗi của 1 tiến trình khác trong hệ thống.

Điều này dẫn tới việc phải liên tục kiểm tra các điểm checkpoint của từng tiến trình riêng

biệt nhưng phải đảm bảo tính ổn định cho cả hệ thống, vì thế ta phải quay lui lần lượt cho

tới khi đạt được thời điểm tối ưu, điều này được gọi là hiệu ứng domino.

Hiệu ứng domino

Việc tính toán đ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

cả hệ thống, do đó có thể tránh được hiêu ứng domino.

45

Phương pháp này đảm bảo tính ổn định cho hệ thống, bởi không có thông điệp nào đến

trong thời điểm checkpoint, và các thông điệp gửi đi được lưu vào hàng đợi cho đến khi

thông điệp CHECKPOINT DONE được nhận.

Ta có thể cải thiện phương pháp bằng cách multicast một checkpoint chỉ tới các tiến trình

phụ thuộc vào thời điểm khoi phục và lờ đi các tiến trình khác. Một tiến trình là phụ

thuộc vào tiến trình điều phối nếu nó nhận được thông điệp có tính nhân quả liên quan

đến thông điệp được gửi bởi tiến trình điều phối trong lần gửi gần nhất. Lúc này, tiến

trình multicast checkpoint chỉ tới các tiến trình mà nó đã gửi thông điệp trước checkpoint

cuối cùng. Khi tiến trình nhận được thông điệp này, nó gửi yêu cầu tới tất cả tiến trình mà

nó đã từng gửi thông điệp trước checkpoint cuối cùng và cứ như vậy. Mỗi tiến trình chỉ

gửi thông điệp 1 lần duy nhất. khi tất cả các tiến trình đã được nhận diện, 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.

II. Hệ phân tán dựa trên WEB

World Wide Web (www) có thể được xem là hệ phân tán khổng lồ nhất và cũng là tiêu

biểu nhất với hàng triệu server và client cho truy cập dữ liệu. Server chứa dữ liệu trong

khi client cung cấp cho người sử dụng giao diện thân thiện cho việc biểu diễn dữ liệu và

truy nhập dữ liệu.

46

Tính trong suốt là một đặc trưng tiêu biểu của hệ phân tán, cũng được thể hiện rõ rệt

thông qua WEB. Đối với người dùng , một tài liệu được lấy từ phía server , truyền tới

client, và được biểu diễn trên màn hình. Không có sự khác nhau giữa tài liệu được lưu trữ

bên trong client và tài liệu được lưu trữ trên máy chủ, có thể là ở tận bên kia thế giới.

Theo nghĩa này, tính phân tán là trong suốt.

Trong phần này, ta sẽ chỉ đưa ra một số nội dung thể hiện tính trong suốt tiêu biểu của

web, đại diện tiêu biểu của hệ phân tán hiện đại.

1. Kiến trúc

Kiến trúc hệ phân tán trên nền tảng web về cơ bản không có gì khác biệt so với hệ phân

tán khác. Mặc dù vậy, trong những năm gần đây, các tài liệu trên web không còn đơn

thuần là tĩnh, mà chuyển sang xu hướng chứa các phần tử chủ động, nhiều tổ chức đã hỗ

trợ các dịch vụ chứ không đơn thuần là các tài liệu nữa.

Hệ thống dựa trên web truyền thống

Nhiều hệ thống dựa trên nền web được tổ chức đơn giản dưới dạng client-server. Nhân

của web được định dưới dạng tiến trình có thể truy cập tới một hệ thống file cục bộ lưu

trữ dữ liệu. Cách thức đơn giản nhất là thông qua Uniform Resource Locator (URL). Qua

đó, ta xác định vị trí của tài liệu, thường là qua tên DNS để xác định vị trí của server chứa

dữ liệu vật lý của tài liệ được yêu cầu.

Client giao tiếp với web server thông qua trình duyệt (browser), chịu trách nhiệm hiển thị

tài liệu và truyền đạt thông tin giữa người dùng và hệ thống, thông qua giao thức truyền

siêu văn bản HTTP (HyperText Transfer Protocol).

47

Các tài liệu web

Tài liệu của web mang ý nghĩa rộng lớn : nó không đơn thuần là dạng kí tự (plain text),

mà một tài liệu có thể chứa cả âm thanh, hình ảnh, hoạt hình … Trong nhiều trường hợp,

các ứng dụng trợ giúp đặc biệt là cần thiết để thể hiện tài liệu một cách gần gũi với cuộc

sống.

Hầu hết các tài liệu web đều chứa 2 phần : phần chính thường mang tính chất mẫu để

biểu diễn phần còn lại của tài liệu trên trình duyệt web., thường được biểu diễn bởi các

ngôn ngữ đánh dấu (markup language). Tiêu biểu là 2 ngôn ngữ HTML và XML.

• Ngôn ngữ HTML : là một chuẩn để biểu diễn tài liệu dạng văn bản và thông tin về

định dạng cần thiết (phông, kích cỡ, màu sắc …) để biểu diễn chúng. HTML có

cơ chế mang tính điều kiện, phương pháp để biểu diễn dữ liệu dưới dạng ngắn

gọn nhưng có thể được mở rộng bởi người dùng. HTML cung cấp khả năng định

danh cho tài liệu, gọi là liên kết siêu văn bản (hypertext links) hay metalink.

Những liên kết này xác định vị trí của tài liệu mà người dùng cần truy cập tới, có

thể ở dạng văn bản hoặc dạng hình ảnh đồ hoạ.

• Ngôn ngữ XML : là dạng tổng quát của HTML để bao quát các dạng dữ liệu lớn

hơn. Nó là dạng biểu diễn dài dòng, sử dụng mã ASCII để mã hoá dữ liệu. Các

đối tượng trong XML có khả năng tự mô tả, khác với các bản ghi truyền thống

thường mang tính quy chuẩn. Do sự dài dòng nên XML có kích cỡ lớn, hiện chưa

có khả năng thay thế các dạng biểu diễn khác, tuy nhiên với tính rộng khắp và khả

năng hoạt động song song, trong tương lai XML có thể trở thành ngôn ngữ của

tương lai, đơn giản hoá đáng kể việc lập trình.

Một số dạng tài liệu web

48

2. Định danh

Vấn đề định danh, đặc biệt là với web, là một đặc tính cơ bản thể hiên tính trong suốt về

vị trí, có nghĩa là ta không cần biết vị trí thực của một trang web về mặt vật lý nhưng vẫn

có thể đảm bảo khả năng truy cập dữ liệu khi cần đến. Web sử dụng hệ thống định danh

đơn để tham chiếu tới tài liệu gọi là Uniform Resource Identifiers (URI) . Có 2 loại URI:

• Uniform Resource Locator (URL) : định danh tài liệu bằng cách đưa thêm thông

tin về vị trí và cách thức truy cập tài liệu.

• Uniform Resource Name (URN) : đóng vai trò của đối tượng định danh đích thực,

được sử dụng như đối tượng tổng thể duy nhất, độc lập về vị trí và liên kết vững

chắc với tài liệu.

Ta sẽ xét tới cấu trúc của URL :

• Cách thức truy cập : thông qua cơ chế như http, ftp hay telnet.

• Vị trí của tài liệu : ý nghĩa của tên DNS của server hay có thể là địa chỉ IP của

server.

• Số hiệu cổng mà server lắng nghe

• Tên của tài liệu muốn truy cập tới

49

Các cấu trúc thông dụng của URL

a) chỉ sử dụng tên DNS

b) Kết hợp yên DNS và só cổng

c) Kết hợp địa chỉ IP với địa chỉ cổng

Ngoài ra ta còn có một số dạng URI khác, dùng đặc trưng cho các yêu cầu khác nhau

chứ không chỉ dành riêng cho vấn đề tham chiếu đến tài liệu. Ví dụ, URI telnet dùng

để cài đặt các phiên telnet cho server; URI tel dùng để chứa số điện thoại và để client

thiết lập cuộc gọi tới mạng điện thoại.

3. Sự nhân bản

Sự nhân bản cho các hệ thống lưu trữ web

50

Vai trò quan trọng của web ngày càng tăng về mặt tổ chức để đảm bảo khả năng biểu

diễn và kết nối trực tiếp với người dùng, ta cần đảm bảo nội dung đồng thời cả khả

năng tiện dụng trong truy cập. Sự phân biệt này mở đường cho các mạng phân phối

nội dung (content delivery networks CDNs). Ý tưởng chính là đặt các CDN này ở bên

dưới, để chúng đóng vai trò là các dịch vụ web, cung cấp cơ sở hạ tầng cho phân tán

và sao chép các tài liệu web cho nhiều trang khác nhau trên Internet.

Tổ chức chung của CDN dưới dạng phản hồi

Có 3 hướng liên quan tới việc thực hiện sao chép trong các hệ thống lưu trữ web:

đánh giá khoảng cách (metric estimation), adaptation triggering và thực hiện phép đo

thích hợp (appropriate measures).

Đánh giá độ đo

Một vấn đề đáng chú ý của CON là cần phải đánh giá vai trò của mặt khi có liên quan

đến vấn đề lưu trữ các bản sao. Ví dụ, thời gian truy cập đến một tài liệu có thể tối ưu

nếu nó được sao chép với số lượng lớn, nhưng nó lai đòi hỏi chi phí lớn về tài chính

cũng như băng thông cho hệ thống. Do đó tuỳ trương hợp mà có các tiêu chí đánh giá

khác nhau.

• Độ trễ : khoảng thời gian để thực hiện hành động, ví dụ tìm kiếm một tài liệu.

Ví dụ đánh giá độ trễ giữa một client và vài remote server. Thay vì đánh giá

độ trễ, ta có thể xác định băng thông thích hợp giữa 2 nút trong mạng, đặc biệt

quan trọng đối với việc truyền các tài liệu có kích cỡ lớn.

51

• Độ đo không gian : bao gồm khoảng cách giữa các nút thông qua số hop trong

lớp mạng, hoặc số hop giữa các hệ thống tự trị. Tuy nhiên việc này rất khó

thực hiện

• Độ đo về mức độ sử dụng mạng : thường liên quan đến băng thông, việc tính

toán băng thông bằng số byte được truyền qua mạng là đơn giản. Tuy nhiên để

chính xác, ta nên đánh giá mức độ thường xuyên mà tài liệu được đọc, ghi, và

nhân bản.

• Độ đo về tính nhất quán : xác định mức độ sai lệch của một bản sao so với bản

gốc.

• Độ đo về tài chính : xác định mức độ hoạt động tốt của CDN. Tuy không

mang tính kĩ thuật, nhưng trong trương hợp hoạt động trong hệ thống tài

chính, đây lại là yếu tố quyết định. Ví dụ, hầu hết CDN tài chính đều đặt

server tại trạm đỉnh của mạng Internet, nghĩa là họ thuê trực tiếp từ các ISP để

phục vụ người dùng cuối. Điều này làm gắn chặt mo hình kinh doanh với mô

hình kĩ thuật, và trong thực tế rất tài liệu được đưa ra về mối liên hệ này.

Qua các ví dụ trên, ta thấy việc đánh giá hiệu năng của CDN là cực kì phức tạp. Trong

thực tế với CDN tài chính, ta có thể đơn giản hoá như khả năng phục vụ nhanh người

dùng, thực hiện tốt các yêu cầu của khách hàng.

Adaptation triggering

Vấn đề cần đặt ra là khi nào và thực hiện thế nào quá trình nhân bản. Một cách thức đơn

giản là đánh giá độ đo theo chu kỳ và sau đó thực hiện đo nếu cần. Cách này thường được

thực hiện trong thực tế. Một tiến trình xác định thông tin cuar server và định kì kiểm tra

sự thay đổi.

Tuy nhiên việc thực hiện mang tính chu kỳ không đảm bảo độ tin cậy khi có sự thay đổi

đột ngột trong hệ thống, ví dụ như đối với một flash crowd. Đó là sự kiện khi xuất hiện

sự bùng nổ các yêu cầu cho một tài liệu đặc biệt nào đó, điều này có thể làm sụp đổ cả hệ

thống. Việc điều khiển flash crowd là rất khó khăn. Một giải pháp là sử dụng tiến trình

phỏng đoán flash crowd để đảm bảo để server có đủ thời gian thiết lập các bản sao,

nhưng thật khó để đưa ra được các dự đoán chính xác.

52

Một giải pháp khác được đưa ra là sử dụng kiến trúc nội suy tuyến tính đơn, thông qua

việc đánh giá số yêu cầu được gửi đến trong một khoảng thời gian dựa theo kích cỡ của

cửa sổ. Các khoảng được chia thành các đoạn nhỏ, từ đó nội suy để xác định hình dạng

đường cong thể hiện lượng yêu cầu phụ thuộc thời gian. Nếu yêu cầu gần đạt tới giá trị

ngưỡng, cảnh báo được đưa ra.

Các mẫu đo phản ánh sự truy cập flash crowd trong trương hợp bình thường và 3

trường hợp bất thường

Tuy nhiên, phương pháp này không hiệu quả do nó phụ thuộc vào kích thước cửa sổ, dẫn

đến sự phụ thuộc vào lưu lượng server web. Do đó ta cần chỉnh bằng tay để đạt dự đoán

chính xác cho từng site riêng biệt mà hiện chưa có cơ chế tự động nào.

Điều chỉnh độ đo

Vai trò của việc tái định hướng (redirection) là rất quan trọng trong việc gửi yêu cầu của

client, điều này được thực hiện thông qua các giao thức tái định hướng thích nghi, đảm

bảo cho thông tin khi các tiến trình thực hiện việc tái định hướng.

Bên cạnh việc sử dụng các giao thức khác nhau, vấn đề dược đưa ra là có cần đảm bảo

việc tái định hướng yêu cầu có nên trong suốt với client hay không. Có 3 kĩ thuật được sử

dụng trong thực tế : TCP handoff, tái định hướng DNS(DNS redirection), và tái định

hướng HTTP( HTTP redirection).

53

• Tái định hướng DNS : cơ chế trong suốt đảm bảo client hoàn toàn không hay biết

về vị trí thực của tài liệu. Chú ý rằng, cơ chế này chỉ áp dụng cho site thực thể vì

tên của tài liệu đơn không hợp với không gian tên cuả DNS.

• Tái định hướng HTTP: ngược lại, đây không là cơ chế trong suốt. Khi client yêu

cầu tài liệu đặc biệt nào đó, nó sẽ được nhận một URL tạm để sau đó được tái

định hướng. URL này hiện đối với người dùng, nên nếu lưu lại địa chỉ này, nó có

thể vô dụng trong lần yêu cầu sau.

Nhân bản của các ứng dụng web

Trong phần này ta tập trung vào các kĩ thuật cache và sao chép các bản sao tĩnh của nội

dung Web. Các kĩ thuật này cỉa thiện đáng kể hiệu năng hệ thống, việc kết hợp cả 2 kĩ

thuật cho phép đạt được hiệu quả cao hơn so với từng kĩ thuật đơn lẻ.

Ta xét trong ví dụ dưới đây, giả sử một CDN, mỗi host là một server gốc đóng vai trò

quyết định trong việc đều khiển các yêu cầu của client, và có khả năng lưu trữ từng phần

thông tin giống như server gốc.

Các phương án cải thiện hiệu năng hệ thống :

• Áp dụng bản sao đầy đủ cho tất cả dữ liệu lưu trên server, điều này áp dụng tốt

khi tỉ số cập nhật nhỏ và các truy vấn yêu cầu tìm kiếm cơ sỏ dữ liệu mở rộng.

Tuy nhiên điều này không thể thực hiện được khi tỉ số cập nhật lớn, và mỗi bản

cập nhật sẽ tạo gánh nặng cho cả hệ thống mạng. Vấn đề tiếp theo là khi các truy

54

vấn phức tạp, điều này dẫn tới việc truy cập tới nhiều bảng gây khó khăn cho việc

tìm kiếm dữ liệu.

• Điều đó dẫn tới việc thực hiện các bản sao từng phần, làm giảm nhẹ đáng kể gánh

nặng cho hệ thống. Nhưng vấn đề nảy sinh là quyết định xem dữ liệu nào nên

được tạo bản sao, một giải pháp cho phương án này là ta sẽ phân tích các vết đã

truy cập của các bản ghi trước đó và thực hiện thông qua hàm đánh giá

Cost = w i im∑ , với i = 1÷ n và mi là độ đo khoảng cách và wi là trọng số dương.

• Tạo cache nội dung-mù (content-blind). Ý tưởng của phương pháp cực kỳ đơn

giản: khi client đưa ra yêu cầu tới server edge, server sẽ tính toán giá trị băm của

truy vấn này, từ đó xác định xem có tồn tại truy vấn nào như vậy chưa. Nếu chưa

có sẽ được lưu vào cache trước khi gửi tới client, nếu đã có trong cache thì gửi

luôn cho client. Phương pháp này làm giảm đáng kể mức độ tính toán khi so sánh

với việc ta phải tiếp xúc với CSDL. Tuy nhiên nó trở nên vô dụng nếu trong cache

có rất nhiều dữ liệu dư thừa so với nội dung cần thiết hay so với các bản sao

CSDL.

Các phương pháp trên đây có thể được triển khai trong việc hình thành các dịch vụ

web, tuy nhiên cần có nhiều nghiên cứu trước khi đưa ra giải pháp ổn định.

4. Tính chịu lỗi

Tính chịu lỗi trong hệ phân tán dựa trên Web thường được sử dụng thông qua cache

client-server và các bản sao server. Không có biện pháp đặc biệt nào có khả năng kết

hợp chặt chẽ, ví dụ, cho tính chịu lỗi cho HTTP và khả năng khôi phục. Mặc dù vậy,

khả năng sẵn sàng trong các dịch vụ chủ yếu như DNS. DNS cho phép vài địa chỉ

được trả về như kết quả trong phép tìm kiếm tên. Trong các hệ thống trên nền Web,

tính chịu lỗi có thể đạt được dễ dàng mà không quan tâm đến thiết kế của server.

Khi lỗi đến từ các dịch vụ Web, cũng có một số biện pháp tương tự. Tuy nhiên, vấn

đề che giấu lỗi và khôi phục yêu cầu ở mức khắt khe hơn. Ví dụ, các dịch vụ Web hỗ

trợ các giao dịch phân tán diện rộng và giải pháp chắc chắn sẽ phải liên quan tới các

vấn đề lỗi của các dịch vụ tham gia và truyền thông không đáng tin cậy.

55

Quan trọng hơn, trong các dịch vụ Web, ta có thể xử lý với các đồ thị phức tạp. Trong

nhiều hệ thống truyền thông trên nền Web, ta dựa trên thỏa thuận giữa client-server.

Điều này có nghĩa là khi client gọi server, sau đó ước tính đáp ứng mà không cần

thêm các dịch vụ mở rộng. tính chịu lỗi thường có thể nhân được bằng cách nhân bản

server một cách đơn giản hoặc sử dụng một phần kết quả trong cache.

Tình huống này không còn đối với các dịch vụ web, trong nhiều trường hợp ta gặp

phải vấn đề server đóng vai trò là client. Vấn đề trở nên trầm trọng hơn cho các dịch

vụ được thiết kế để chống lại lỗi tùy tiện. Nhân bản đóng vai trò chủ yếu, thêm vào đó

ta gặp phải vấn đề dịch vụ chịu lỗi tùy tiện Byzantine fault-tolerant (BFT) đóng vai

trò như client trong dịch vụ không nhân bản khác.

Có 3 tình huống cần giải quyết :

• Client trong dịch vụ BFT nhìn dịch vụ như là dịch vụ web khác. Đặc biệt, điều

này có ý nghĩa rằng nhân bản bên trong dịch vụ nên che giấu đối với client, song

song với quá trình hồi đáp đúng đắn. Ví dụ, client cần lấy k+1 câu trả lời độc lập

từ 2k+1 câu trả lời, giả sử rằng dịch vụ BFT được thiết kế để chịu được tối đa k

tiến trình lỗi.

• Dịch vụ BFT nên đảm bảo tính nhất quán bên trong khi đóng vai trò là client, đặc

biệt nó phải chịu được trường hợp dịch vụ bên ngoài trả về các kết quả khác nhau

từ các bản sao khác nhau. Điều này xảy ra khi dịch vụ gặp sự cố. Các bản sao cần

chạy các giao thức thỏa thuận như sự mở rộng cho các giao thức mà nó đã chạy

mà có khả năng cung cấp tính chịu được lỗi tùy tiện. Sau khi thực thi giao thức

này, chúng có khả năng gửi trả lời ngược lại client.

• Cuối cùng, các dịch vụ mở rộng có thể coi dịch vụ BFT như một client, như một

thực thể đơn. Đặc biệt, một dịch vụ không thể chấp nhận yêu cầu một cách tùy

tiện từ một bản sao đơn, mà phải đảm bảo đủ ít nhất k+1 yêu cầu từ các bản sao

khác nhau.

Ba tình huống trên dẫn tới 3 thành phần khác nhau trong phần mềm được liên kết với

nhau trong toolkit để phát triển các dịch vụ Web.

56

57

C. Kết luận

Vai trò của hệ phân tán đối với sự phát triển của máy tính là không thể bàn cãi, đặc

biệt khi quy mô các hệ thống máy tính ngày càng lớn như hiện nay. Các đặc tính của

hệ phân tán giúp nó có điều kiện thuận lợi cho việc phát triển.

Tuy nhiên bên cạnh các đặc tính thuận lợi của hệ phân tán, tồn tại rất nhiều vấn đề

trong việc xây dựng hệ thống để đảm bảo cá tính chất tốt đó của hệ. Do đó việc

nghiên cứu hệ phân tán ngày càng đóng vai trò quan trọng trong việc xây dựng các

mạng máy tính.

Trong số các đặc tính của hệ phân tán, tính trong suốt là đặc tính quan trọng, tạo điều

kiện để khai thác hiệu quả hệ phân tán đồng thời đảm bảo tính tiện dụng cho người

dùng. Việc nghiên cứu tính trong suốt tạo điều kiện để phát triển và nâng cao hiệu

năng của hệ thống, đồng thời vẫn đảm bảo hệ phân tán là hệ thống phục vụ người

dùng.

58

Tài liệu tham khảo

1. Distributed System: Principles and Paradims – A. Tanenbaum, M. Van

Steen

2. Reliable Distributed Systems Technologies, Web Services, and

Applications - Kenneth P. Birman

59