Chapter 8 fault tolerance full

1
Fault tolerance - làm rõ đối
với Web-Based Systems
BÁO CÁO MÔN HỌC
Lý thuyết hệ phân tán
Giảng viên: TS. Hoa Tất Thắng
Học viên: Phạm Công Hòa
Nguyễn Hữu An
Lê Thị Thu Thủy
Trần Thị Huyền
Phạm Thị Ngà-K24

Báo cáo môn học Lý thuyết hệ phân tán 2
Nội dung báo cáo
I. Một số khái niệm cơ bản
II. Các phương pháp che giấu
lỗi
III. Ủy thác phân tán
IV. Phục hồi
V. Làm rõ đối với Web-Based
Systems

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

Tính chịu lỗi liên quan nhiều tới khái niệm
có thể tin cậy được (dependable system). Thuật
ngữ "có thể tin cậy được" bao gồm các thuộc tính
sau:
1. Tính sẵn sàng (Availability)
2. Tính tin cậy (Reliability)
3. Tính an toàn (Safety)
4. Khả năng duy trì (Maintainability)

Tính chịu lỗi còn liên quan tới khái niệm
điều khiển lỗi (Fault control). Điều khiển lỗi bao
gồm: ngăn ngừa lỗi, loại bỏ lỗi và dự báo lỗi với
mục tiêu xây dựng thành công khả năng chịu
đựng lỗi cho hệ thống.

Báo cáo môn học Lý thuyết hệ phân tán6
Phân loại lỗi:
1. Lỗi nhất thời
2. Lỗi liên tiếp
3. Lỗi lâu dài

Các mô hình lỗi:
1. Lỗi sụp đổ (Crash failure)
2. Lỗi bỏ sót (Omission failure)
3. Lỗi thời gian (Time failure)
4. Lỗi đáp ứng (Respond failure)
5. Lỗi bất kỳ (Arbitary failure)

II. Các phương pháp che giấu lỗi
1. Che giấu lỗi bằng dư thừa:
2. Khôi phục tiến trình
3. Che giấu lỗi trong truyền thông client/server
đáng tin cậy
4. Che giấu lỗi trong truyền thông nhóm đáng
tin cậy

1. Che giấu lỗi bằng dư thừa:
Chia làm 3 loại:
- Dư thừa thông tin
- Dư thừa thời gian
- Dư thừa vật lý

2. Khôi phục tiến trình:
2.2. Thiết kế:
- Tổ chức các tiến trình giống nhau vào cùng một nhóm.
- Khi có một bản tin được gửi đến nhóm, mọi thành viên trong
nhóm sẽ nhận được bản tin đó. 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.
2.1. Mục đích:
- Chống lại các tiến trình bị lỗi bằng cách sao chép và phân tán
việc tính toán trong một nhóm

2.3. Phân loại nhóm:
- Nhóm ngang hàng: tất cả các tiến trình là
ngang bằng nhau không có cái nào là boss
và mọi quyết định đều được thực hiện theo
tập thể.
+ Ưu điểm: Nếu một tiến trình bị lỗi, cả
nhóm chỉ đơn giản bị thu hẹp lại, nhưng vẫn
có thể tiếp tục hoạt động.
+ Nhược điểm: Thời gian trễ lớn, tốn tài
nguyên.

- Nhóm phân cấp: Trong mỗi nhóm sẽ có một
tiến trình giữ vai trò quản lý gọi là coordinator, còn
các tiến trình khác đóng vai trò thực hiện (worker).
Khi có một yêu cầu chuyển đến, yêu cầu này sẽ
được gửi tới coordinator. Coordinator sẽ quyết
định worker nào thích hợp nhất để thực hiện nó
và sẽ chuyển đến cho worker đó.
+ Ưu điểm: Không bị trễ như nhóm ngang
hàng.
+ Nhược điểm: Khi coordinator gặp sự cố
thì toàn bộ hoạt động của nhóm sẽ bị dừng lại

2.4. Để 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ì đủ?
- Một hệ thống được gọi là k fault tolerance nếu nó có thể
hoạt động đúng với k phần tử (tiến trình) bị lỗi. Nếu có k tiến trình
bị lỗi thì cần có k+1 tiến trình khác không bị lỗi để quá trình lựa
chọn kết quả vẫn diễn ra chính xác.
- 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)

3. Che giấu lỗi trong truyền thông client/server đáng
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 ý.

tin cậy:
3.1. 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/NACK và việc thực hiện truyền lại. 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. Chỉ có một cách để che giấu lỗi sụp đổ là hệ thống
phải có khả năng tự động tạo một kết nối mới.

tin cậy:
3.2. Kết nối RPC:
* 5 lớp lỗi có thể xảy ra trong hệ thống RPC
- Máy khách không thể định vị được máy chủ
- Tin nhắn yêu cầu từ máy khách đến máy chủ bị mất
- Máy chủ bị treo sau khi nhận yêu cầu
- Tin nhắn phản hồi từ máy chủ đến máy khách bị mất
- Máy khách bị treo sau khi gửi yêu cầu:

tin cậy:
- Máy khách không thể định vị được máy chủ: Lỗi này
xảy ra khi máy khách không thể xác định vị trị của một máy
chủ thích hợp. Chẳng hạn như tất cả các máy chủ có thể bị
down. Cách khắc phục: gửi báo cáo cho máy khách "Cannot
locate server"

tin cậy:
- Tin nhắn yêu cầu từ máy khách đến máy chủ bị mất:
Đâ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"

tin cậy:
- Máy chủ bị treo sau khi nhận yêu cầu: Lỗi 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ị treo trước khi nó có thể gửi phản hồ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.

tin cậy:
Khi gặp kiểu lỗi này, ở phía máy server sẽ thực hiện theo 3 kỹ
thuật sau:
+ Kỹ thuật 1: chờ cho đến khi server khởi động lại (hoặc xây
dựng một sever mới) và cố gắng vận hành lại một lần nữa. Kỹ thuật
này đảm bảo RPC được thực hiện ít nhất một lần.
+ Kỹ thuật 2: ngừng ngay lập tức và gửi phản hồi thông báo lỗi
cho máy khách. Với kỹ thuật này thì RPC thực hiện nhiều lần nhất.
+ Kỹ thuật 3: Khi một server treo, máy trạm không nhận được
sự hỗ trợ và cũng không được báo trước điều gì xảy ra. RPC có
thể được thực hiện rất nhiều lần hoặc không một lần nào.

tin cậy:
Còn máy khách thì có thể thực hiện theo 4 cách sau:
+ Một là: Client không thực hiện gửi lại các yêu cầu, có nguy
cơ rằng yêu cầu đó sẽ không được thực hiện.
+ Hai là: Client liên tục gửi lại yêu cầu: có thể dẫn tới trường
hợp một yêu cầu được thực hiện nhiều lần.
+ Ba là: Client chỉ gửi lại yêu cầu nào đó khi không nhận được
bản tin ACK phản hồi từ server thông báo đã nhận thành công.
Trường hợp này, server dùng bộ đếm thời gian. Sau một khoảng
thời gian xác định trước mà không nhận được ACK thì client sẽ gửi
lại yêu cầu đó.
+ Bốn là: Client gửi lại yêu cầu nếu nhận được phản hồi đối
với yêu cầu thực hiện.

tin cậy:
- Tin nhắn phản hồi từ máy chủ đến máy khách bị mất. Cách
khắc phục: máy trạm có thể đánh số thứ tự cho mỗi yêu cầu. Bằng
cách này, máy chủ theo dõi các yêu cầu đã được máy trạm gửi,
máy chủ có thể phân biệt yêu cầu ban đầu với yêu cầu gửi lại và
có thể từ chối thực hiện bất cứ yêu cầu gửi lại nào. Tuy nhiên, máy
chủ vẫn phải gửi một thông báo cho máy trạm. Ngoài ra trong tiêu
đề tin nhắn có thể sử dụng một bit giúp nhận biết đâu là các yêu
cầu được gửi lại

tin cậy:
- Máy khách bị treo sau khi gửi yêu cầu: Client gửi yêu
cầu tới server rồi bị lỗi trước khi nhận được trả lời gửi về từ
server. Công việc mà server thực hiện nhưng không có đích
nào đợi để nhận kết quả được gọi là một "orphan". Các
orphan có thể gây ra hàng loạt các vấn đề cản trở hoạt động
bình thường của hệ thống. Ít nhất là gây lãng phí chu kỳ
CPU. Nó cũng có thể khóa các tập tin hoặc các nguồn tài
nguyên có giá trị, gây ra lỗi...

tin cậy:
Giải pháp:
+ Một là: trước khi gửi một yêu cầu nào đó, 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 lỗi, client sẽ lấy lại bản ghi
đó và việc thực hiện các orphan đang diễn ra sẽ bị dừng lại.
Nhược điểm của phương pháp này là chi phí để trang bị đĩa để
lưu lại mỗi bản hi 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.
+ Hai là: 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 client khôi phục trở
lại thì số chỉ thời kỳ 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 thời kỳ mới của
mình. Khi nhận được thông báo này thì các orphan sẽ dừng lại.

tin cậy:
Giải pháp:
+ Ba là: 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ỏ.
+ Bốn là: 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, client sẽ phải đợ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ý

Các phương pháp che giấu lỗi
4. Che giấu lỗi trong truyền thông nhóm tin cậy
(dùng multicasting)
4.1. Multicasting tin cậy cơ bản
4.2. Multicasting tin cậy mở rộng
4.3. Multicasting nguyên tử

4. Che giấu lỗi trong truyền thông nhóm tin cậy (dùng
multicasting)
4.1. Multicasting tin cậy cơ bản (Basic Reliable - multicast
ing).
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ề.

multicasting)
4.2. Multicast tin cậy mở rộng.
Để tăng hiệu quả công vệc khi làm việc với một số lượng lớn
các tiến trình thì đưa ra mô hình multicast tin cậy mở rộng. Với mô
hình này sẽ không gửi trả về bản tin ACK báo nhận thành công mà
chỉ gửi trả về cho tiến trình nhận bản tin NACK thông báo khi có lỗi
truyền.Việc này được thực hiện bằng giao thức SRM (Scalable
Reliable Multicasting).

multicasting)
4.3. Multicast nguyên tử (Atomic multicast ).
Tư tưởng chính: 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 đó.

III. Ủy thác phân tán (Distributed commit)
1. Khái niệm ủy thác phân tán
2. Ủy thác hai pha
3. Ủy thác 3 pha

1. Khái niệm ủy thác phân tán:
Có nhiều người dùng truy cập cơ sở dữ liệu phân tán thông
qua các ứng dụng. Vì lý do này chức năng quản lý giao dịch (
transaction management ) được đưa ra. 1 giao dịch là 1 quá trình
trao đổi giữa máy thành viên và máy chủ, giao dịch hoàn tất khi quá
trình này hoàn tất.
Chức năng quản lý giao dịch nhằm duy trì tính nhất quán dữ
liệu, tránh xung đột dữ liệu bằng cách chia dữ liệu thành các đơn vị
giao dịch sao cho cơ sở dữ liệu có thể điều khiển được việc cập nhật
từ các người dùng khác nhau. Quản lý giao dịch bao gồm đặc điểm:
Automicity ( nguyên tố ), Consistency (Nhất quán), Isolation (Cô lập),
Durability (Bền vững)

- Distributed commit ( ủy thác phân tán ) là các giao thức giúp
thực hiện truy cập tài nguyên (dữ liệu) – thực hiện giao dịch như
trên mà vẫn đảm bảo CSDL của ta có đầy đủ các đặc điểm đã nêu.
- Ủy thác ( commit ) : là việc khi kết thúc 1 công việc xử lý cơ sở
dữ liệu, cập nhật cơ sở dữ liệu xong kết quả được lưu trữ.

2. Ủy thác hai pha:
* Là cơ chế đảm bảo tính toàn vẹn của cơ sở dữ liệu phân tán.
* Gồm 2 pha khác nhau :
- Pha 1 :
+ Máy chủ gửi lệnh cập nhật đến mỗi site. Mỗi site tiến hành cập
nhật tạm thời cơ sở dữ liệu.
+ Các site nhận được lệnh cập nhật sẽ trả lời lại máy chủ lệnh
VOTE_COMMIT nếu nó ở trạng thái sẵn sàng (ready ) cập nhật hay lệnh
VOTE_ABORT nếu nó đang có sự cố mà muốn hủy bỏ (abort ) bất kỳ khi
nào nhận được lệnh ủy thác từ máy chủ.
- Pha 2 :
Sau khi đã chắc chắn tất cả các site đã sẵn sàng cho việc cập
nhật Máy chủ chuyển lệnh GLOBAL_COMMIT cho các site một cách
tuần tự. Các thành viên tiến hành cập nhật cơ sở dữ liệu một cách tuần
tự.

3. Ủy thác 3 pha
Một nhược điểm của ủy thác 2 pha là tại pha thứ nhất, máy chủ
phải nhận được phản hồi của tất cả các site con ( xem tình trạng
của nó là sẵn sàng Commit hay Abort ) thì mới quyết định có thực
hiện cam kết hay ko ở pha thứ 2. Tuy nhiên trên thực tế có những
trường hợp máy site gặp sự cố bất thường trước khi nó kịp gửi
phản hồi cho máy chủ, trong TH này sẽ khiến toàn bộ hệ thống bị
“down” do máy chủ không biết nên quyết định thế nào.

3. Ủy thác 3 pha
Ủy thác 3 pha khắc phục nhược điểm này bằng cách có thêm 1
bước đệm goi là PRECOMMIT. Trong quá trình đợi để nhận phản
hồi từ các site con, chỉ cần có 1 site gửi lại VOTE_ABORT ngay lập
tức máy chủ sẽ quyết định ABORT (hủy bỏ) quá trình cam kết (
khác với 2 pha là phải đợi tất cả phản hồi đến rồi mới quyết định ).
Trường hợp các site lần lượt gửi về VOTE_COMMIT, máy chủ
sẽ để hệ thống trạng thái PRECOMMIT. Và sau khi tất cả các site
đều đã sẵn sàng thì GLOBAL_COMMIT mới được máy chủ gửi đi.
Ngoài ra các khâu khác đều như 2 pha .

IV. Phục hồi (Recovery)
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 :
- Backward recovery : tư tưởng của nó là đư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à được điều đó, buộc ta cần 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”.
- 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.

IV. Phục hồi (Recovery)
- Trong hệ phân tán thường áp dụng backward recovery.
- Nhược điểm của backward:
+ 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.
+ Với phương pháp backward đưa ra không có sự đảm bảo
rằng sau khi trở lại trạng thái trước lỗi, lỗi lại không tiếp tục xảy ra
dễ bị rơi vào tình trạng loop recovery.
+ 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.

8.7. Làm rõ đối với Web-Based Systems
1. Kiến trúc chung
1.1. Mô hình truyền thống
- Client gửi bản tin HTTP yêu cầu tới Webserver
- Webserver tồn tại tiến trình truy nhập CSDL
- Server xử lí và trả lại thông tin cho Client

1.2.Mô hình truyền thống với kiến trúc đa tầng
Một trong những cải tiến so với kiến trúc cơ bản là việc sử dụng các
CGL (Common Gatew Interface) nhằm cung cấp sự tương tác cho
người dùng. Thông qua các Interface này, Webserver có thể chạy
những chương trình với dữ liệu đầu vào được người dung cung cấp

1.3. Mô hình cơ chế hoạt động dịch vụ Web
Các dịch vụ của máy chủ được công bố ra phía UDDL.Khi Client
cần đến dịch vụ, nó tìm kiếm dịch vụ qua các mô tả trả về qua
ngôn ngữ WSDL. Client thực hiện kết nối đến máy chủ qua giao
thức SOAP và gửi dịch vụ. Từ đây quá trình trao đổi diễn ra bình
thường thông qua giao thức SOAP.

2. Các tiến trình
2.1. Tiến trình phía Client

Rendering Engine: Engine này chịu trách nhiệm hiển
thị các văn bản HTML hay XML lên màn hình. Nó
chứa các thành phần có khả năng: Tạo liên kết, giao
tiếp trên mạng; xử lý ngôn ngữ HTML, XML; phiên
dịch các script trong văn bản Browser Engine:
Engine là trung tâm của trình duyệt, cung cấp cho
người dung cơ chế xem văn bản, như chia nó thành
các phần, lựa chọn các phần của văn bản, vào một
liên kết.v..v..
User Interface: Engine cung cấp giao diện cho người
dung. Ngoài ra, do trình duyệt không phụ thuộc nền
tảng nó chạy, User Interface cùng với Brower Engine
chạy trên các thư viện chuẩn được thể hiện trên
hình.
2.1. Tiến trình phía Client (t)

Các máy chủ nội bộ tổ chức nhiều hơn hoặc ít hơn theo
các bước cần thiết để xử lý một yêu cầu HTTP
2.2.Tiến trình phía máy chủ Web

2.3.Cơ chế chạy Clustering các máy chủ
Hệ thống sẽ có một máy chủ Front – End nhận, chuyển và trả lời các
yêu cầu tới các máy chủ Web. Cơ chế gửi có thể là tuần tự, cũng có
thể có cơ chế dõi gửi yêu cầu đến máy chủ đang chịu tải ít hơn.

2.4. Cơ chế chạy Clustering các máy chủ
Nội dung nhận thức được phân phối có thể được tốt hơn
rất nhiều

3. Các cơ chế
3.1. Cơ chế truyền thông

3.2.Cơ chế định danh URI

Định danh với các giao thức, các định dạng khác nhau:

3.3.Cơ chế đồng bộ
Quá trình đồng bộ được giải quyết thông qua một giao
thức riêng, đó là WebDAV (Web Distributed Authoring
and Versioning). WebDAV cung cấp cơ chế khóa tài
liệu khi có truy cập, cơ chế tạo các phiên bản, xóa,
sao….
- Nhằm đồng bộ hóa, WebDAV sử dụng hai cơ chế
khóa: Cơ chế khóa khi một Client thực hiện chỉnh sửa
tài liệu, lúc này các Client khác sẽ bị khoá chức năng
chỉnh sửa (quyền write). Cơ chế khóa cho một nhóm
người sử dụng. Cơ chế này cho phép một nhóm người
dùng chỉnh sửa các phần khác nhau của tài liệu. Tuy
nhiên người dùng phải quan tâm tới các vấn đề về
xung đột khi chỉnh sửa.

3.3.Cơ chế đồng bộ
- Khi Client cần chỉnh sửa tài liệu, Client phải
truy cập tới Server và yêu cầu quyền lấy khóa
(Key token). Sauk hi các dữ liệu được chỉnh
sửa, Client gửi về Server qua bản tin HTTP
Post, cùng với chứng minh quyền sửa dữ liệu
(Key token). Ở đây có một vấn đề đặt ra là khi
Client không trả lại quyền chỉnh sửa do bị sự
cố. Lúc này, Server cần có một cơ chế lấy lại
khóa.

3.4. Cơ chế nhất quán và nhân bản
Nhằm đảm bảo hiệu năng và tính sẵn sang của hệ thống
qua cơ chế Caching tức là lưu lại các thông tin được yêu
cầu nhiều nhằm trả lời Client ngay lập tức mà không cần
thực hiện tiến trình lấy dữ liệu.

3.4.1. Cơ chế Proxy Caching

3.4.2. Nhân bản hệ thống Web Hosting

3.4.2. Nhân bản hệ thống Web Hosting (t)

4. Khả năng chịu lỗi
- Khả năng chịu lỗi của hệ phân tán dựa trên
nền Web cũng chủ yếu dựa vào các cơ chế
Caching và Nhân bản
- Giao thức chống lỗi bản thân là tiến trình thu
thập và xử lý thông tin của các tiến trình khác.
- Chỉ khi thành phần thu thập thông tin nhận
được tất cả các thông báo từ các thành phần
nhân bản, nó mới được đưa ra xử lý phù hợp.

5. Tính an toàn bảo mật hệ thống

- Giai đoạn 1: Client thông báo tới Server các thuật
toán mã hóa và các chuẩn nén mà Client có thể hỗ trợ.
Server lựa chọn thuật toán và chuẩn nén cho kết nối đó
và gửi trả lời thông tin cho phía Client.
- Giai đoạn 2: Là giai đoạn xác thực giữa Client và
Server. Server xác thực (chứng minh mình là Server)
thông qua một chứng thực. Nếu như Server yêu cầu
Client phải xác thực thì Client sẽ phải xác thực với
Server.
Việc thiết lập một kết nối bảo mật bao gồm 2 giai đoạn:

Chapter 8 fault tolerance full

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Chapter 8 fault tolerance full

Similar to Chapter 8 fault tolerance full (20)

Chapter 8 fault tolerance full

Editor's Notes