Chương 7:  Chịu lỗi

7.1  Chịu lỗi và một số khái niệm liên quan

7.1.1  Một số khái niệm cơ bản.

Các khái niệm.

Tính chịu lỗi liên quan nhiều tới khái niệm hệ có thể tin cậy được (dependable system). Bao gồm các thuộc tính sau:

Tính sẵn sàng (availability): HT có tính sẵn sàng là HT luôn sẵn sàng hoạt động tốt ở mọi thời điểm.

Tính tin cậy (Reliability): một HT có tính tin cậy là HT có khả năng hoạt động trong một thời gian dài mà không bị gián đoạn, không xảy ra lỗi.

Tính an toàn (Safety): HT có tính an toàn là HT mà khi xảy ra lỗi cũng không dẫn tới thảm họa. Các HT cần phải có độ an toàn cao là các HT điều khiển.

Khả năng bảo trì (Maintainability):HT có khả năng bảo trì là HT có khả năng phục hồi lại được sau khi có lỗi. Nếu sự phục hồi này diễn ra tự động thì có thể nói HT này cũng có tính sẵn sàng cao.

Tính chịu lỗi còn có 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 lỗi cho HT.

Phân loại lỗi.

Lỗi được phân chia thành các loại sau:

Lỗi nhất thời (Transient faults): Là loại lỗi xuất hiện một lần rồi biến mất. Cách khắc phục: thực hiện lại hoạt động có lỗi này

Lỗi lặp (Intermittent faults): Là loại lỗi mà chúng xuất hiện, rồi biến mất, sau đó lại xuất hiện lại và cứ tiếp tục như thế. Lỗi này thường gây ra các hậu quả trầm trọng vì chúng rất khó xác định được.

Cách khắc phục: sử dụng bộ sửa lỗi cho HT (fault doctor) để khắc phục lỗi.

Lỗi lâu dài (Permanent faults):Là loại lỗi vẫn  tồn tại ngay cả khi thành phần gây lỗi đó đã được sửa chữa.

7.1.2  Các mô hình lỗi.

Lỗi sụp đổ (crash failure):  khi server gặp lỗi này thì nó sẽ bị treo, trước đó server vẫn hoạt động tốt cho đến khi ngừng hoạt động. Khi server gặp lỗi này, nó sẽ không thể làm gì được nữa. Một ví dụ hay gặp lỗi này là HĐH của các máy cá nhân. Khi HĐH ngừng hoạt động thì chỉ còn cách duy nhất là khởi động lại.

Lỗi bỏ sót (omission failure): là lỗi mà một server không thể đáp ứng được yêu cầu gửi tới nó. Người ta chia nó thành hai loại:

-Lỗi khi nhận thông điệp gửi tới: gặp lỗi này, server không nhận được yêu cầu ngay cả từ client gần nó nhất và mặc dù kết nối giữa server với client đã được thiết lập. Lỗi khi nhận thông điệp chỉ làm cho server không nhận biết được các thông điệp gửi tới nó mà không hề ảnh hưởng đến trạng thái của server.

-Lỗi khi gửi thông điệp: server vẫn nhận được các yêu cầu, vẫn hoàn thành yêu cầu đó nhưng vì một lý do nào đó lại không thể gửi kết quả tới máy đã yêu cầu. Một trong những lý do thường gặp là do bộ nhớ đệm gửi đầy. Trong trường hợp gặp lỗi này, server cần chuẩn bị tình huống clien sẽ gửi lại yêu cầu đã gửi đó .

Lỗi thời gian (timing failure): là lỗi xảy ra khi server phản ứng lại quá chậm, sau cả thời gian cho phép. Trong một HT luôn có các ràng buộc về mặt thời gian. Nếu bên gửi gửi đến bên nhận nhanh quá, bộ nhớ đệm của bên  nhận không đủ để chứa thì sẽ gây ra lỗi. Tương tự, server phản ứng lại chậm quá, vượt quá khoảng timeout quy định sẵn cũng sẽ gây ra lỗi, ảnh hưởng đến hiệu năng chung của HT.

Lỗi đáp ứng (Response failure): là lỗi khi server trả lời không đúng. Đây là một kiểu lỗi rất ngiêm trọng và được phân chia thành hai loại:

-Lỗi về mặt giá trị: là lỗi khi server trả lời lại yêu cầu của client với giá trị không chính xác. Ví dụ khi sử dụng các máy tìm kiếm, kết quả trả về không hề liên quan gì tới yêu cầu của user.

-Lỗi về chuyển trạng thái: là lỗi khi server hoạt động trệch hướng khỏi luồng điều khiển. Có nghĩa là server trả lời các yêu cầu được gửi tới một cách không theo như mong đợi.

Lỗi bất kì (Arbitrary failure): một server có thể tạo ra một lỗi bất kì ở bất kì thời gian nào. Đây là loại lỗi nguy hiểm nhất. Có thể có hai khả năng xảy ra:

Thứ nhất: một server tạo ra một kết quả sai mà không thể phát hiện ra được.

Thứ hai: server bị lỗi có liên kết với các server khác tạo ra một kết quả sai.

Ta có thể xét một vào lỗi bất kì hay gặp sau : lỗi fail-stop, lỗi fail-silent và lỗi fail-safe. Với fail-stop, server bị treo, ngừng hoạt động và có thông báo tới các tiến trình khác. Với fail-silent, server đột ngột hoạt động chậm lại vì thế làm cho các tiến trình không thể kết thúc được, ảnh hưởng đến hiệu năng của HT. Lỗi fail-safe là lỗi mà khi server tạo ra kết quả ngẫu nhiên nhưng các tiến trình nhận dạng các kết quả này là không có giá trị.

7.2      Các phương pháp che giấu lỗi.

7.2.1        Che giấu lỗi bằng dư thừa.

Có ba loại dư thừa: dư thừa thông tin, dư thừa thời gian và dư thừa vật lý.

Dư thừa thông tin : bổ sung thêm các bit dư thừa để phát hiện lỗi và phục hồi lỗi. Ví dụ trong việc truyền dữ liệu thường thêm vào các bit kiểm tra chẵn lẻ, mã Haming, CRC… để phát hiện lỗi và khôi phục lỗi.

Dư thừa thời gian: khi một hoạt động đã được thực hiện, nếu dư thừa thời gian nó có thể được thực hiện lại. Kĩ thuật dư thừa thời gian phù hợp khi lỗi là ngắn và không liên tục. Ví dụ: khi một giao tác bị hủy giữa chừng, nó có thể được thực hiện lại mà không gây nguy hại gì.

Dư thừa vật lý: bổ sung thêm tài nguyên

7.2.2        Khôi  phục tiến trình.

a.      Các vấn đề khi thiết kế.

Nguyên tắc: tổ chức các tiến trình giống nhau vào cùng một nhóm.

Hoạt động: khi nhóm nhận được thông báo thì thông báo này sẽ được gửi tới tất cả các thành viên trong nhóm. Nếu có tiến trình nào trong nhóm bị lỗi thì sẽ có tiến trình khác thay thể .

Đặc điểm: các nhóm này có thể là động. Tính động thể hiện ở các mặt sau:

Số lượng các nhóm là không cố định: có thể tạo thêm hay hủy bỏ một nhóm.

Số lượng các tiến trình trong cùng một nhóm là không cố định: một tiến trình có thể gia nhập hay rời khỏi nhóm.

Một tiến trình có thể là thành viên của nhiều nhóm trong cùng thời điểm.

èDo tính động đó mà cần phải đưa ra các cơ chế quản lý nhóm: quản lý mối quan hệ giữa các nhóm và quản lý thành viên trong một nhóm.

Phân loại nhóm: dựa trên cấu trúc bên trong thì nhóm được phân thành hai loại:

Nhóm ngang hàng:

-          Tất cả các tiến trình trong nhóm là ngang hàng nhau.

-          Khi thực hiện một công việc nào đó sẽ phải có một quá trình bầu cử (vote) để xác định xem tiến trình nào phù hợp để thực hiện công việc đó.

-          Ưu điểm: khi một tiến trình bị lỗi thì chỉ làm cho kích thước của nhóm giảm đi chứ không ảnh hưởng đến hoạt động của cả nhóm.

-          Nhược điểm: do phải có quá trình bầu cử nên tốn thời gian (delay &overhead).

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). Các tiến trình thực hiện chịu sự điều khiển của coordinator.

-    Khi có yêu cầu gửi đến nhóm, yêu cầu này sẽ được gửi tới coordinator. Coordinator sẽ quyết định xem tiến trình nào trong nhóm đảm nhiệm công việc đó một cách phù hợp nhất và chuyển yêu cầu nhận được đến tiến trình đó.

-    Ưu điểm: không bị trễ như kiến trúc 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.

Các phương pháp quản lý thành viên trong nhóm:

Phương pháp 1: dùng một server gọi là group server

Server này chứa tất cả các thông tin về các nhóm và các thành viên của từng nhóm.

Ưu điểm: hiệu quả, dễ sử dụng

Nhược điểm: nếu server bị lỗi thì không thể quản lý được toàn bộ HT và các nhóm có thể phải xây dựng lại từ đầu các công việc mình đã thực hiện.

Phương pháp 2: phương pháp phân tán.

Khi tiến trình muốn gia nhập hay rời khỏi nhóm thì nó phải gửi bản tin thông báo tới tất cả các tiến trình khác.

Phương pháp 3: yêu cầu việc gia nhập/ rời khỏi nhóm phải đồng bộ với bản tin gửi hay nhận.

Khi một tiến trình gia nhập nhóm nó sẽ nhận tất cả các bản tin từ nhóm đó.

Khi một tiến trình rời khỏi nhóm thì nó sẽ không được nhận bất kì bản tin nào từ nhóm đó nữa và không một thành viên nào của nhóm cũ nhận được các bản tin từ nó

b.      Che giấu lỗi và nhân bản.

Có hai phương pháp nhân bản : bằng giao thức primary-based và bằng giao thức replicated-write

Bằng giao thức primary-based: Các tiến trình trong nhóm tổ chức theo mô hình phân cấp. Nếu coordinator của nhóm chính dừng hoạt động thì coordinator của các nhóm sao lưu sẽ thực hiện các giải thuật để lựa chộn nhóm chính mới (mặc dù nó có thể đảm nhiệm công việc đó).

Bằng giao thức replicated-write : Các tiến trình trong nhóm tổ chức theo mô hình nhóm ngang hàng.Vấn đề là cần nhân bản với số lượng là bao nhiêu

7.2.3  Che giấu lỗi trong TT client/server tin cậy.

Việc che giấu lỗi trong HPT 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 TT tập trung vào che giấu lỗi sụp đổ và lỗi tùy ý.

a. TT điểm – điểm .

Trong HPT, TT đ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à HT phải có khả năng tự động tạo một kết nối mới.

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

Với HT 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ĐH 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:

Kĩ thuật 1: đợ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.

Kĩ thuật 2: 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.

Kĩ thuật 3: 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:

Một là: 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.

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 thông báo hỏng từ server.

-          Mất bản tin phản hồi từ server gửi trả về client: Phương pháp khắc phục: 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.

Có 4 giải pháp được đưa ra trong trường hợp này là:

Một là: trước khi gửi đi 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 khi lỗi, client sẽ lấy lại bản ghi đó và và việc thực hiện các orphan đang diễn ra sẽ dừng lại. Phương pháp này có nhiểu nhược điểm: Chi phí để trang bị đĩa để lưu lại mỗi bản ghi cho mỗi RPC. Orphan có thể tự mình thực hiện RPC tạo ra một grandorphan nên rất khó xác định.

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 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 clietn 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

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, 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ý.

7.2.4  Che giấu lỗi trong TT nhóm tin cậy (dùng multicasting)

a.      Multicasting tin cậy cơ bản (Basic Reliable-multicasting).

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

b.      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).

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

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 coordinator. Coodinator 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. Coodinator của mỗi nhóm sẽ có bộ đệm (history buffer) riêng.

-          Nếu Coordinator của mỗi nhóm không nhận được bản tin m thì nó sẽ gửi yêu cầu truyền lại tới coordinator 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 coordinator nhận thành công một bản tin m nó sẽ gửi bản tin ACK tới coordinator của nút cha nó.

-          Nếu coordinator của một nhóm nhận được bản tin ACK báo nhận thành công bản tin m 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 m 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 nên phải có một cơ chế tìm đường cho cây này

c.       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 đó.

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 đổ.

Một số thuật ngữ:

Group view (khung nhìn nhóm): ý 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 (group view)- một tập nhỏ các tiến trình của một nhóm lớn.

View change (thay đổi khung nhìn): 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ảo đả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).

Tư tưởng chính: đả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.

7.3      Cam kết phân tán.

Mô hình thiết lập cam kết phải là mô hình phân cấp và coordinator lãnh trách nhiệm thiết lập cam kết phân tán. Ở cam kết một pha đơn giản, coordinator thông báo với tất cả các thành viên còn lại hoặc là thực hiện hoặc là không thực hiện một thao tác nào đó. Nếu thành viên nào đó không thực hiện được cũng không thể báo lại cho coordinator biết. Do đó người ta đưa mô hình mới đó là cam kết hai pha và cam kết ba pha

7.3.1  Cam kết hai pha.

Xét một giao dịch phân tán với các thành viên là một tập các tiến trình chạy ở một máy khác với giả thiết không có lỗi xảy ra.

Cam kết hai pha gồm hai: Pha bầu cử (voting phase )và pha quyết định (Decision phase).

Với pha bầu cử: bao gồm hai bước thực hiện:

-          Coordinator gửi một bản tin thông báo yêu cầu bầu cử VOTE_REQUEST tới tất cả các thành viên trong nhóm.

-          Sau khi nhận được bản tin VOTE_REQUEST của coordinator, nếu có thể thực hiện được thì thành viên đó sẽ gửi lại cho coordinator thông báo chấp nhận bầu cử VOTE_COMMIT, nếu không, sẽ gửi lại cho coordinator thông báo từ chối VOTE_ABORT.

Pha quyết định: gồm hai bước thực hiện:

-          Coordinator tập hợp tất cả các bầu cử của các thành viên. Nếu tất cả đều đồngý chấp nhận giao dịch thì coordinator sẽ gửi một bản tin GLOBAL_COMMIT tới tất cả các thành viên. Tuy nhiên, chỉ cần một thành viên gửi thông báo từ chối thì coordinatorquyết định hủy giao dịch trên và sẽ gửi một bản tin GLOBAL_ABORT cho tất cả các thành viên trong nhóm.

-          Các thành viên sau khi đã gửi thông báo chấp nhận tới coordinator sẽ đợi phản hồi từ coordinator. Nếu nó nhận về thông báo GLOBAL_COMMIT thì giao dịch sẽ được chấp thuận, còn nếu nhận được GLOBAL_ABORT thì giao dịch sẽ bị hủy.

Các trạng thái của một coordinator là: INIT, WAIT, ABORT, COMMIT. Còn các trạng thái của một thành viên bất kì là : INIT, READY, ABORT, COMMIT.

Nhược điểm của cam kết hai pha: Nhược điểm chính của cam kết hai pha là tốn nhiều thời gian chờ đợi. Cả coordinator và các thành viên còn lại đều phải chờ một bản tin nào đó được gửi đến cho mình.

Nhược điểm thứ hai là nếu coordinator bị lỗi thì hoạt động của cả HT sẽ bị ảnh hưởng.

7.3.2  Cam kết 3 pha

Để khắc phục nhược điểm của cam kết hai pha trong trường hợp coordinator bị lỗi, người ta đưa ra mô hình cam kết ba pha. Các trạng thái khá giống hai pha nhưng thêm một trạng thái PRECOMMIT.

7.4        Phục hồi.

Phục hồi là các phương pháp đưa trạng thái bị lỗi sang trạng thái lành (fault free). Có hai cách tiếp cận cho phục hồi lỗi: phục hồi lùi (back forward) và phục hồi tiến (forward recovery).

Phục hồi lùi: khi thực hiện phục hồi lùi sẽ thực hiện phục hồi trạng thái lành của HT trước khi có lỗi và cho HT chạy lại từ điểm đó. Để có thể thực hiện được điều này phải sử dụng các điểm checkpoint. Tại các điểm này sẽ sao lưu trạng thái hiện hành của HT để khi khôi phục sẽ cho chạy ở điểm checkpoint gần nhất. Việc thực hiện theo phương pháp này là rất tốn kém.

Phục hồi tiến: chuyển HT từ trạng thái lỗi sang trạng thái mới với các thông tin để tiếp tục thực hiện