Hệ thống Phân tán

Distributed Systems
II. Các vấn đề cơ bản
1. Giới thiệu
 Sự cố - lỗi:
 Lỗi: là khi hệ thống không cung cấp dịch vụ như thiết kế
 Trong hệ tập trung:
 lỗi client => phạm vi ảnh hưởng ?
 lỗi server => phạm vi ảnh hưởng ?
 Hệ phân tán
 lỗi từng phần là đặc điểm => ảnh hưởng đến 1 phần hệ thống
 Nhu cầu thiết kế: đảm bảo khả năng phục hồi khi có lỗi
Giới thiệu
 Chịu lỗi
 Chịu lỗi:
 Hệ thống vẫn vận hành (ở mức chấp nhận) ngay cả khi có sự cố
 Hệ thống chịu lỗi => hệ thống là tin cậy - nếu đáp ứng
 khả năng sẵn sàng phục vụ
 độ tin cậy
 độ an toàn
 khả năng bảo trì
Giới thiệu
 Mô hình lỗi
 Trong hệ phân tán, lỗi có thể xảy ra ở: nút xử lý hoặc môi trường truyền thông
 Theo tần suất
 lỗi nhất thời
 lỗi lặp
 lỗi lâu dài
 Theo mức độ
 Lỗi nghiêm trọng
 Lỗi xử lý (kh nhận được kết quả)
 Lỗi thời gian
 Lỗi kết quả xử lý
 Lỗi bất thường
Giới thiệu
 Che dấu lỗi
 Hệ thống chịu được lỗi => cần che dấu được lỗi (client kh nhận biết có lỗi xảy ra)
 Tính năng chịu lỗi gồm phòng chống và khắc phục lỗi
 Thường dùng phương án dư thừa
 dư thừa về thông tin: vd parity
 dư thừa về thời gian: thực hiện lại
 dư thừa tài nguyên: vd nhiều máy
Giới thiệu
 Che dấu lỗi
 Hệ thống chịu được lỗi => cần che dấu được lỗi (client kh nhận biết có lỗi xảy ra)
 Tính năng chịu lỗi gồm phòng chống và khắc phục lỗi
 Thường dùng phương án dư thừa
 vd bên:
dư thừa phần cứng
có bộ chuyển mạch hay
load balancing
2. Tiến trình chịu lỗi
 Tiếp cận thiết kế
 Bên cạnh dư thừa tài nguyên vật lý, có thể sử dụng giải pháp phần mềm:
 Giải pháp nhiều tiến trình vai trò như nhau => tạo thành nhóm xử lý
 yc gửi tới => tất cả tiến trình thành viên nhận được
 một tiến trình xử lý yc
 Các tiến trình - cần phối hợp hoạt động => có nhiều phương án khác nhau:
ngang hàng, phân cấp, ..
2. Tiến trình chịu lỗi
 Thỏa thuận trong hệ thống chịu lỗi
 Có nhiều tiến trình => cần thỏa thuận để quyết định trong nhiều tình huống như:
phân chia nhiệm vụ, ghi dữ liệu, ..
 Thực hiện thỏa thuận => cần quan tâm nhiều yếu tố như:
 hệ đồng bộ, bất đồng bộ
 độ trễ truyền tin
 thứ tự thông điệp, ..
2. Tiến trình chịu lỗi
 Thỏa thuận trong hệ thống chịu lỗi
 một Giao thức thực hiện: hệ thống N tiến trình i = 1.. n
 Tiến trình thứ i cung cấp giá trị vi cho các tiến trình khác
 Mỗi tiến trình: xây dựng vector V[N],
• phần tử i V[i]= vi nếu tiến trình i không lỗi
Unkown nếu tiến trình i lỗi
 Các bước của giao thức
1. Mỗi tiến trình gửi giá trị vi của mình cho các tiến trình còn lại
2. các Tiến trình nhận được => xây dựng vector V
3. Tiến trình gửi vector V cho các tiến trình khác
4. các Tiến trình nhận V: duyệt phần tử, với phần tử i
nếu phần lớn giá trị là vi => tiến trình i không lỗi, xây dựng vector kết quả V: V[i] = vi
ngược lại: tiến trình lỗi => V[i] = Unkown
2. Tiến trình chịu lỗi
 Thỏa thuận trong hệ thống chịu lỗi
 Ví dụ
 giả sử tiến trình số 3 bị lỗi khi đó các thành viên
khác trong hệ thống cần phải đảm bảo tiến trình 3
có thực sự bị lỗi hay không.
 Áp dụng các bước thực hiện trên, kết quả thực hiện
ở bước 2 sẽ bao gồm (1,2,x,4), (1,2,x,4), (1,2,y,4),
(1,2,z,4), tiếp tục thực hiện sẽ cho kết quả cuối cùng
tại các tiến trình 1, 2 và 4 như sau:
(1,2,Unknow,4),(1,2,Unknow,4),(1,2,Unknow,4),
vậy các tiến trình 1, 2 và 4 có thể đảm bảo chắc
chắn tiến trình số 3 đã bị lỗi.
2. Tiến trình chịu lỗi
 Phát hiện lỗi
 Là yêu cầu quan trọng trong khả năng chịu lỗi của hệ phân tán
 Cần phát hiện lỗi kịp thời => có các biện pháp khắc phục
 Có thể sử dụng thông tin trạng thái, ngưỡng (thời gian), ...
 Cơ chế cơ bản: 2 hướng chính
 chủ động gửi thông điệp hỏi đáp (alive , ping, probe)
 thụ động nhận thông điệp từ tiến trình khác
3. Truyền thông khách chủ tin cậy
 Truyền thông điểm - điểm
 Sử dụng giao thức mạng tin cậy: TCP
 Nếu lỗi trong truyền tin => sửa lỗi bởi TCP
 Nếu hệ thống gặp sự cố => hệ thống phải khởi tạo lại kết nối
3. Truyền thông khách chủ tin cậy
F5
 Lỗi trong cơ chế RPC Client F1

 Các lỗi có thể xảy ra: xác

gửi yc nhận
 không xác định máy chủ F2 xác
F4
nhận
• vd do khác phiên bản, máy chủ lỗi
gửi kq
• xử lý: xử lý exception Server
 Msg không tới máy chủ
F3 xử lý
• xử lý: dùng timer => gửi lại
quá N lần => máy chủ lỗi
3. Truyền thông khách chủ tin cậy
F5
 Lỗi trong cơ chế RPC
F1
Client

 Các lỗi có thể xảy ra: xác

gửi yc nhận
 Máy chủ bị lỗi sau khi nhận yc: F2 xác
F4
nhận
• Máy chủ: có thể thực hiện theo 1 số cách
gửi kq
1. Khi srv hoạt động lại => cố thực hiện Server
yc đã nhận
F3 xử lý
2. Khi srv hoạt động lại => thông báo client
đã có lỗi => máy trạm gửi lại yc
3. Khi srv hoạt động lại => không thực hiện gì
3. Truyền thông khách chủ tin cậy
F5
 Lỗi trong cơ chế RPC
F1
Client

 Các lỗi có thể xảy ra: xác

gửi yc nhận
 Máy chủ bị lỗi sau khi nhận yc: F2 xác
F4
nhận
• Máy trạm: có thể thực hiện theo 1 số cách
gửi kq
1. Máy trạm kh gửi lại => yc có thể Server
không đc thực hiện
F3 xử lý
2. Máy trạm gửi lại liên tục => yc có thể
đc thực hiện nhiều lần
3. Máy trạm gửi lại yc khi kh có xác nhận: dùng timer
4. Máy trạm gửi lại yc khi có thông báo lỗi của máy chủ
3. Truyền thông khách chủ tin cậy
F5
 Lỗi trong cơ chế RPC
F1
Client

 Các lỗi có thể xảy ra: xác

gửi yc nhận
 Mất msg kết quả gửi về máy trạm: F2 xác
F4
nhận
• có thể thiết kế yc có đặc điểm
gửi kq
kh thay đổi giá trị Server
• có thể định danh (đánh stt) yc =>
F3 xử lý
máy chủ kh cần thực hiện lại mà chỉ
gửi lại msg kết quả
3. Truyền thông khách chủ tin cậy
F5
 Lỗi trong cơ chế RPC
F1
Client

 Các lỗi có thể xảy ra: xác

gửi yc nhận
 Máy trạm gặp sự cố sau khi gửi yc F2 xác
F4
nhận
dẫn đến kết quả máy chủ thực hiện
gửi kq
lãng phí Server
• có thể: trước khi gửi yc, máy trạm (stub)
F3 xử lý
lưu lại yc => khi phục hồi sau sự cố: thực hiện lại
nhược điểm chi phí
• có thể quy định ngưỡng thời gian T để thực hiện RPC
khi máy trạm gặp lỗi & phục hồi => chờ chu kỳ T
4. Truyền thông nhóm tin cậy
 Truyền thông nhóm tin cậy
 Nhóm tiến trình
 Thông điệp gửi tới nhóm => gửi tới các thành viên nhóm
 Truyền thông nhóm tin cậy => cần cơ chế đảm bảo thông điệp tới được các
thành viên
4. Truyền thông nhóm tin cậy
 Phương án cơ bản
 Các cơ chế thực hiện
 Các msg cần gửi được gán số
 Msg lưu lại trong bộ đệm của bên gửi
đến khi có báo nhận
 Bên nhận: nếu xác định bị mất msg =>
yc "gửi lại" - NAck.
 Bên gửi tự gửi lại msg nếu sau thời gian
timeout không có báo nhận Ack
 Nhược điểm: khó khăn khi hệ thống
lớn có nhiều thành viên => quá nhiều
msg phản hồi
4. Truyền thông nhóm tin cậy
 Điều khiển phản hồi không phân cấp
 Vấn đề của phương án cơ bản: quá nhiều msg phản hồi
 Cải tiến: phản hồi không phân cấp với giao thức Scalable Reliable Multicasting
 Bên nhận:
 chỉ phản hồi cho msg thiếu/lỗi - gửi NAck
 msg NAck được gửi multicast tới các thành viên
 Nhược điểm:
 phản hồi Nack gửi multicast => các bên bị ngắt
=> có thể tự triệt tiêu msg: chờ một thời gian, nếu không có Nack tương tự thì mới gửi
có thể tạo nhóm, kênh riêng cho các msg Nack, và các thành viên có thể hỗ trợ phục hồi
msg mất,lỗi trước khi cần đến bên gửi
4. Truyền thông nhóm tin cậy
 Điều khiển phản hồi phân cấp
 Các nhóm tổ chức theo cấu trúc cây
 Gốc: tiến trình gửi
 Các nhóm: bầu chọn một tiến trình điều phối
 Tiến trình điều phối (coordinator)
• Nếu nhận thành công => phản hồi tới nút điều phối cha
• Nếu kh nhận đc/lỗi => cũng phản hồi tới nút điều phối cha - để truyền lại
 Mỗi nhóm: truyền thông nhóm tin cậy - có xác nhận
• tiến trình điều phối: lưu cache bản tin
đến khi tất cả nút trong nhóm xác nhận thành công
5. Cam kết phân tán (distributed commit)
 Giao dịch phân tán
 Liên quan đến đối tượng, dữ liệu được quản lý và thực thi trên nhiều máy chủ,
và đảm bảo các đặc điểm ACID như giao dịch truyền thống
 Nếu sử dụng giao thức cam kết 1 pha: tiến trình điều phối thông báo cho các tiến
trình khác hoàn tất (commit) hoặc hủy bỏ (abort) mà không có phản hồi => nếu
1 tiến trình thành viên kh thực hiện được & không phản hồi được => xảy ra lỗi
 Giao thức hai pha - two phase commit
 Xét giao dịch phân tán: các thành viên là các tiến trình chạy ở các máy khác nhau
 Client khi bắt đầu trans => gửi yc tới tiến trình điều phối coordinator - tạo
transaction, gửi yc thực hiện tới các thành viên
5. Cam kết phân tán (distributed commit)
 Giao thức hai pha - two phase commit
 Nếu client abort => gửi yc tới tiến trình coordinator => tiến trình coordinator
lập tức gửi thông báo tới các thành viên thực hiện abort
 Giao thức gồm 2 pha:
 pha biểu quyết
 pha quyết định (commit hoặc abort)
 Pha biểu quyết:
 coordinator: gửi thông điệp biểu quyết tới các thành viên
 thành viên phản hồi/trả lời:
• có thể thực hiện => vote_commit
• không thực hiện được => từ chối - vote_abort
(và chờ quyết định từ coordinator)
5. Cam kết phân tán (distributed commit)
 Giao thức hai pha - two phase commit
 Pha quyết định:
 coordinator: tập hợp các trả lời của thành viên và ra quyết định
• nếu tất cả là vote_commit => quyết định là commit
• nếu có ít nhất 1 thành viên từ chối => quyết định là abort
coordinator gửi thông điệp quyết định global_commit/global_abort tới các thành viên
 thành viên: nhận thông điệp quyết định => thực thi
• global_commit => kết thúc tác vụ
• global_abort => hủy
6. Phục hồi
 Phục hồi - transaction recovery
 Khả năng có lỗi là kh tránh khỏi, để đảm bảo toàn vẹn - ACID => cần phục hồi khi
gặp lỗi
 Phục hồi về trạng thái trước:
 đưa hệ thống về trạng thái toàn vẹn như trước khi bắt đầu trans
 Cần thực hiện
• sao lưu trạng thái - tại các điểm kiểm tra checkpoint & ghi vào bộ nhớ bền vững
• phục hồi: đưa về trạng thái toàn cục nhất quán gần nhất
lát cắt nhất quán
lát cắt không nhất quán
1. Giới thiệu
 Trong hệ phân tán, hay áp dụng
 Phân tán dữ liệu ở nhiều nút ưu điểm: hiệu năng tốt hơn, xử lí một phần nhỏ dữ liệu, ko xử lý trên dữ liệu lớn

 Nhân bản - quản lý các bản sao của dữ liệu (trên nhiều nút/máy tính)
ưu điểm: chống chịu sự cố, ko mất dữ liệu khi mất 1 bản sao vì còn1 bản sao khác/ khai thác nhanh hơn khi cần
 Tại sao nhân bản dữ liệu
 Nhân bản dữ liệu đem lại nhiều ưu điểm cho hệ phân tán. Một số động lực:
 cải thiện hiệu năng
 tính sẵn sàng
p - xác suất 1 nút gặp sự cố => n nút: tính sẵn sàng 1-p^n
 chịu lỗi fault tolerance
1. Giới thiệu
Bộ phận xử lí quản lý các bản
sao

 Mô hình hệ thống
 Client: yc dịch vụ, dữ liệu đối tượng sử dụng
 Front-end (FE): giao tiếp
đối tượng trung gian đứng ra tiếp
• tiếp nhận yc và trả kết quả nhận yêu cầu và trả lại kết quả cho
client.
• giao tiếp với server/replica => client kh cần biết bên trong phía server - đảm bảo
tính trong suốt
 Server:
• phân hệ quản lý nhân bản Replica manager (RM)
• giả định replica manager duy trì bản sao có thể phục hồi (đảm bảo tính toàn vẹn) và
đầy đủ dữ liệu/đối tượng
1. Giới thiệu
 Có thể phân thành 5 bước xử lý 1 yc
0/ client gửi yc => tới font end
1/ FE gửi yc tới 1 hay nhiều RM
+ có thể giao tiếp với 1 RM =>
đến lượt RM giao tiếp với các RM khác
+ có thể gửi thông điệp multicast tới nhiều RM
2/ Điều phối: RM chuẩn bị xử lý yêu cầu đảm bảo toàn vẹn
xem xét xử lý hay từ chối phục vụ yc
xem xét thứ tự yc so với các yc khác (FIFO, nhân quả-causal ordering, total ordering)
3/ Xử lý yc, đảm bảo khả năng kết thúc commit hoặc hủy abort
4/ Đồng thuận: đồng thuận về ảnh hưởng-kết quả của yc
5/ Trả kết quả: trả kết quả cho FE để trả lại client
Mô hình replication
 Passive replication
 Tập các RM:
 có 1 RM đóng vai trò chính - primary,
lưu bản gốc
 các RM khác vai trò lưu bản sao - slave
 đồng bộ 1 chiều từ RM primary tới spave
 Quá trình
 request: FE gửi yêu cầu tới RM primary
 coordinate: RM primary tiếp nhận, sắp xếp
 exec: RM primary xử lý
 agreement: RM primary commit/abort cập nhật tới các slave RM
 response: RM primary phản hồi kết quả
Mô hình replication
 Active replication
 Nhóm các RM đóng vai trò như nhau
 các RM đều xử lý yêu cầu
 Nếu có RM lỗi ?
=> FE tập hợp kết quả và tính biểu quyết
 Quá trình
 request: FE gán id duy nhất cho yc & gửi multicast tới các RM
 coordinate: yc được gửi tới các correct RM theo thứ tự total order
 exec: tất cả RM xử lý, do total order => kết quả như nhau nếu RM là tốt-correct
 agreement: không cần
 response: các RM gửi tới FE, FE xử lý (biểu quyết), trả phản hồi cho client