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

Data & Analytics

Transcript of Chapter 8 fault tolerance full