1.3.4.1 Khái quát về các giao dịch nguyên tử:
Khi một tiến trình muốn thực hiện giao dịch với một hoặc nhiều tiến trình khác, chúng thực hiện việc thoả thuận các thông số, tạo và xoá các đối tượng, và thực hiện các tác vụ. Sau đó nó sẽ thông báo cho tất cả các tiến trình biết để xác nhận rằng công việc của mình đã hoàn thành. Nếu tất cả đều đồng ý thì
không có vấn đề gì xẩy ra. Nếu một hoặc nhiều tiến trình từ chối việc xác nhận (vì một lí do nào đó), thì giao dịch sẽ trở về trạng thái trước khi được thực hiện. Đặc tính này gọi là all-or-nothing.
1.3.4.2 Mô hình giao dịch:
Sau đây ta sẽ làm quen với mô hình giao dịch chi tiết với các đặc tính khác nhau.
Stable Storage:
Thiết bị lưu trữ thường chia làm 3 loại, RAM, như ta đã biết, disk storage, và cuối cùng là stable storage.
Stable storage thích hợp cho các ứng dụng đòi hỏi mức độ chịu lỗi cao như giao dịch nguyên tử. Khi dữ liệu được ghi vào stable storage và được đọc ra để kiểm tra thì khả năng mất dữ liệu là rất thấp.
Transaction Primitives:
Danh sách các hàm nguyên thuỷ phụ thuộc vào loại đối tượng đang được sử dụng trong giao dịch. Ví dụ, trong hệ thống mail, các hàm nguyên thuỷ có thể là send, receive, forward; trong hệ thống kế toán, các hàm nguyên thuỷ có thể là READ và WRITE.
Các đặc tính của giao dịch:
Các giao dịch có 4 đặc tính chủ yếu:
- Nguyên tử: Với người dùng, giao dịch là không thể chia nhỏ được nữa. - Nhất quán: giao dịch không xung đột với các hằng số hệ thống.
- Tách biệt: Các giao dịch không gây ảnh hưởng đến nhau.
- Bền vững: Khi một giao dịch được commit, các thay đổi sẽ được chấp nhận.
Đây còn gọi là đặc tính ACID của giao dịch. Nested Transaction:
Các giao dịch có thể bao gồm các giao dịch thành phần, thường được gọi là nested transaction. Giao dịch ở mức cao nhất có thể gọi các giao dịch con, các giao dịch con có thể được bố trí chạy song song với nhau trên các bộ xử lí khác nhau để đạt được performance nhất định.
1.3.4.3 Concurrency Control:
Khi nhiều giao dịch đang thực hiện đồng thời trên các tiến trình khác nhau (ở
các bộ xử lí khác nhau), ta cần một số cơ chế để tách biệt hoạt động của chúng, các cơ chế này gọi là giải thuật concurrency control.
Locking:
Đây là giải thuật được sử dụng rộng rãi nhất, xét một ví dụ đơn giản, khi một tiến trình muốn đọc hay ghi một file, đầu tiên nó khoá file. Việc khoá file có
thể được thực hiện bởi trình quản lí khoá tập trung hoặc trình quản lí khoá local trên mỗi máy để quản lí các local file. Trình quản lí này duy trì một danh sách các file đã bị khoá để tránh bị khoá tiếp, đảm bảo file không bị thay đổi khi giao dịch đang tiến hành.
Quá trình này có thể được cải tiến bằng cách phân biệt các khoá đọc và khoá ghi. Nếu khoá đọc được đặt trên một file thì các khoá đọc khác có thể được phép. Các khoá đọc được thiết lập để đảm bảo file này không thay đổi trong
quá trình đọc, nhưng không cấm các giao dịch khác đọc file này. Ngược lại, khi file được khoá để ghi, không thể đặt them được khoá nào khác lên file này.
Trong thực tế, đơn vị của khoá không nhất thiết là một file, nó có thể là một
bản ghi hoặc toàn bộ database. Kích thước của đối tượng bị khoá gọi là granularity of locking. Granularity càng tốt thì khoá càng chính xác và càng đạt được cơ chế song song.
Hầu hết các giao dịch sử dụng cơ chế khoá 2 pha, trong đó, đầu tiên tiến trình thu thập tất cả các khoá mà nó cần trong growing phase, sau đó giải phóng chúng trong shrinking phase, hình 1.15.
Trong nhiều hệ thống, shrinking phase chưa hoàn thành nếu tiến trình chưa kết thúc, nghĩa là hoặc chưa commit hoặc chưa abort. Cơ chế này gọi là cơ chế khoá 2 pha chặt chẽ (strict two-phase locking).
Hình 1.15: Cơ chế khoá 2 pha Optimistic Concurrency Control:
Ý tưởng của phương pháp này là các tiến trình cứ việc thực hiện công việc của mình mà không cần quan tâm đến các tiến trình khác, nếu có xung đột thì sẽ được giải quyết sau. Trong thực tế, xung đột xẩy ra là rất ít, nên hầu hết mọi trường hợp, tiến trình đều làm việc bình thường. Phương pháp này sẽ lưu lại quá trình đọc và ghi file, khi commit, nó sẽ kiểm tra xem liệu có file nào
đã bị thay đổi kể từ thời điểm giao dịch bắt đầu thực hiện hay không, nếu không giao dịch sẽ được commit, nếu có thì giao dịch sẽ bị bỏ qua. Phương pháp này rõ ràng là thích hợp với các giao dịch sử dụng hệ thống file riêng của chúng, không chia sẻ file với các giao dịch khác.
Timestamps:
Trong phương pháp này, mỗi giao dịch sẽ đăng kí một timestamp riêng, mỗi file trong hệ thống có một timestamp đọc và timestamp ghi riêng, chỉ cho giao dịch biết tương ứng lần đọc và ghi lần cuối cùng của file này. Nếu các giao dịch đều ngắn và cách nhau một khoảng thời gian khá xa thì timestamp đọc và ghi sẽ thường nhỏ hơn timestamp của giao dịch, lúc đó giao dịch sẽ được thực hiện bình thường. Nếu giao dịch bắt đầu muộn hơn timestamp của file thì có nghĩa là có một tiến trình khác đang truy suất file này, giao dịch sẽ bị bỏ qua. 1.3.5 Deadlocks trong các hệ thống phân tán:
Deadlock trong hệ thống phân tán là khó tránh khỏi, khó phát hiện hơn trong hệ thống đơn vì thông tin liên quan được phân bố trên toàn hệ thống.
1.3.5.1 Phát hiện deadlock phân tán:
Việc phòng tránh deadlock trong hệ thống phân tán là rất khó, người ta thường đưa ra các phương pháp để phát hiện ra nó chứ không cố gắng loại trừ nó. Tuy nhiên, với các hệ thống phân tán có các giao dịch nguyên tử mà đặc tính nổi bật của nó là sẽ khôi phục lại hoạt động khi bị kill, việc giải quyết deadlock không còn đơn giản chỉ là kill tiến trình gây ra deadlock đó nữa, nếu may mắn thì việc khởi động lại giao dịch nguyên tử ở lần tiếp theo sẽ không gây ra deadlock.
Phát hiện deadlock tập trung:
Sử dụng một bộ điều phối hoạt động chung để giải quyết vấn đề chia sẻ tài nguyên giữa các tiến trình trên các máy. Để tránh tình trạng xác định nhầm
deadlock, người ta sử dụng giải thuật của Lamport về xác định thời điểm yêu cầu tài nguyên và thời điểm giải phóng tài nguyên của các tiến trình.
Phát hiện deadlock phân tán:
Có nhiều giải thuật phát hiện deadlock phân tán, sau đây giới thiệu giải thuật Chandy-Misra Haas, giải thuật này cho phép các tiến trình được yêu cầu - nhiều tài nguyên cùng một lúc.
Hình 1.16: Giải thuật phát hiện deadlock phân tán Chandy-Misra-Haas
Khi một tiến trình phải chờ được sử dụng tài nguyên mà một tiến trình khác đang chiếm giữ, nó sẽ bị block và tạo một thông điệp, thông điệp này gồm 3
số: kí hiệu tiến trình đã bị block, kí hiệu tiến trình đang gửi thông điệp, kí hiệu tiến trình mà thông điệp định chuyển đến. Khi thông điệp này được một tiến trình nào đó nhận được, tiến trình này sẽ kiểm tra xem liệu nó có đang phải chờ một tiến trình nào khác không, nếu có thì thông điệp sẽ được cập nhật. Trong đó, số hiệu thứ nhất được giữ nguyên, số hiệu thứ 2 được thay bằng số hiệu tiến trình của nó, và thành phần thứ 3 là số hiệu của tiến trình mà nó đang chờ để được sử dụng tài nguyên chia sẻ. Nếu sau đó thông điệp này
quay lại đúng tiến trình đã tạo ra nó lần đầu tiên thì hệ thống xẩy ra hiện tương deadlock. Giải pháp cho trường hợp này là tự huỷ tiến trình đã tạo ra thông điệp này. Tuy nhiên, có thể xẩy ra trường hợp có 2 hay nhiều hơn các tiến trình tạo ra các thông điệp này, việc tự huỷ chúng sẽ làm giao dịch không
thể thực hiện được, hình 1.16. Đây là vấn đề cần giải quyết trong tương lai đối với một hệ thống phân tán.
1.3.5.2 Tránh deadlock phân tán:
Tránh deadlock bao gồm việc thiết kế cẩn thận hệ thống để không xẩy ra trường hợp deadlock. Có nhiều kĩ thuật như thế, ví dụ giải thuật yêu cầu các tiến trình phải yêu cầu tất cả các tài nguyên mà nó cần ngay từ đầu rồi giải phóng các tài nguyên này khi định đưa ra một yêu cầu mới. Một phương thức nữa là sắp xếp tất cả các tài nguyên và yêu cầu các tiến trình sử dụng các tài nguyên này theo một trật tự tăng dần. Có nghĩa là một tiến trình đang sử dụng một tài nguyên bậc cao không thể yêu cầu sử dụng tiếp một tài nguyên bậc thấp khác.
Trong hệ thống phân tán, người ta thường sử dụng 2 giải thuật dựa trên ý tưởng gán cho mỗi giao dịch một timestamp toàn cục khi nó bắt đầu thực hiện và 2 giao dịch không thể có timestamp giống nhau. Đó là các giải thuật wait- die deadlock prevention và wound wait deadlock prevention.-
1.4 Các tiến trình và bộ xử lí trong các hệ thống phân tán:
Trong các hệ thống phân tán, có rất nhiều luồng điều khiển trong một tiến trình. Khả năng này có một số ưu điểm quan trọng, đồng thời cũng làm nảy sinh một số vấn đề về cách tổ chức bộ xử lí và tiến trình, vấn đề về phân bổ bộ xử lý và scheduling trong các hệ thống phân tán.
1.4.1 Threads:
Trong các hệ điều hành truyền thống, mỗi tiến trình có một không gian địa chỉ và một luồng điều khiển (thread) riêng. Ví dụ: một file server thường phải chờ để được phép truy suất đĩa cứng. Nếu server có nhiều thread, thì thread thứ 2 có thế chạy trong khi thread thứ nhất vẫn đang chờ được truy suất đĩa cứng, giải pháp này làm tăng thông lượng cũng như performance của hệ thống. Sự khác nhau giữa thread và tiến trình là ở chỗ, các thread không hoàn toàn được
độc lập như các tiến trình, chúng phải chia sẻ không gian nhớ, nghĩa là có cùng các biến toàn cục. Mỗi tiến trình có thể được phân chia thành nhiều thread để phối hợp hoạt động với nhau.
Vì các thread phải chia sẻ không gian địa chỉ với nhau nên để tránh xung đột khi có nhiều hơn 1 thread cùng truy suất đến một biến trong không gian địa chỉ, người ta sử dụng mutex, là cơ chế hoạt động giống như vùng tới hạn đã
phân tích ở trên. Một phương pháp khác là dùng biến điều kiện (condition variable).
1.4.2 Các mô hình hệ thống:
Hệ thống phân tán có nhiều CPU cùng hoạt động, có thể có nhiều cách tổ
chức hoạt động cho các CPU này. Ở đây ta xem xét 2 loại cơ bản là workstation và processor pool, cũng như dạng kết hợp đặc tính của 2 loại trên. 1.4.2.1 Mô hình workstation:
Mô hình workstation là mô hình trong đó hệ thống bao gồm các workstation kết nối với nhau qua hệ thống mạng LAN tốc độ cao. Các workstation có thể là loại có đĩa local hoặc không, loại không có đĩa local gọi là diskless
workstation, loại có đĩa local thì gọi là diskfull workstation hoặc disky workstation.
Diskless workstation phải dùng fileserver, loại disky workstation thì sử dụng các đĩa riêng, các đĩa này thực hiện một trong 4 chức năng sau:
1. Paging và các file tạm
2. Paging, các file tạm và các file nhị phân hệ thống.
3. Paging, các file tạm, các file nhị phân hệ thống và file caching. 4. Làm một hệ thống file local
Mô hình này đơn giản và dễ hiểu nhưng có 2 nhược điểm, thứ nhất là không tập trung, thứ 2 là nếu có workstation không làm việc thì các user khác cũng không thể tận dụng workstation này để nâng cao khả năng tính toán của mình.
Vấn đề thứ 2 được giải quyết bằng cách, phát hiện các workstation hiện
không làm việc, chạy các tiến trình từ xa trên đó, trả lại tài nguyên của workstation cho user khi user sử dụng lại workstation đó.
Giải thuật để phát hiện các workstation rỗi có thể chia làm 2 loại: server driven, khi workstation đi vào trạng thái rỗi thì nó sẽ thông báo bằng cách, ví dụ khai báo tên, địa chỉ mạng và các đặc tính của nó vào registry. Loại kia là client driven, khi một câu lệnh được gọi thực hiện từ xa nó phát tán yêu cầu này để thông báo chương trình mà nó muốn thực hiện, lượng bộ nhớ mà nó cần… Nếu workstation nào có thể đáp ứng được yêu cầu đó thì nó sẽ gửi phản hồi cho câu lệnh đó, hình 1.16.
Hình 1.16: Giải thuật dựa trên registry để tìm và sử dụng các workstation rỗi 1.4.2.2 Mô hình Processor Pool:
Trong mô hình này, một nhóm các bộ xử lí được tập trung lại, các user sẽ được cấp phát các CPU theo yêu cầu của ứng dụng. Căn cứ của mô hình này là giải quyết vấn đề queueing. Hệ thống queueing là trạng thái trong đó các user gửi các yêu cầu một cách ngẫu nhiên.
Theo tính toán thì khi phối hợp hoạt động của n bộ xử lý khả năng xử lí của hệ thống tăng lên n lần.
1.4.2.3 Mô hình lai:
Trong mô hình này, các nhiệm vụ tương tác người dùng sẽ chạy trên workstation, các ứng dụng không tương tác sẽ chạy trên processor pool, thực hiện tất cả các tác vụ tính toán phức tạp.
1.4.3 Phân bổ bộ xử lý:
Hệ thống phân tán bao gồm nhiều bộ xử lí, chúng có thể được tổ chức theo các mô hình như mô tả ở trên. Trong mọi trường hợp, ta cần phải lựa chọn tiến trình nào sẽ được chạy trên máy nào. Với mô hình workstation, vấn đề là khi nào tiến trình chạy trên máy local khi nào phải chạy trên workstation rỗi. Với mô hình processor pool, mỗi tiến trình mới phát sinh đều cần được phân bổ bộ xử lí.
Các mô hình phân bổ:
Việc phân bổ bộ xử lí có thể phân làm 2 loại chính, nonmigratory và
migratory. Nonmigratory là cơ chế trong đó khi tạo mới một tiến trình sẽ quyết định luôn nơi sẽ chạy tiến trình đó, và tiến trình sẽ chỉ thực hiện cho đến khi hoàn thành ở máy đó bất kể máy đang ở trong tình trạng overload hay đang rỗi. Ngược lại, là cơ chế phân bổ kiểu migratory, trong đó tiến trình có thể được chuyển tới máy khác ngay cả khi đang chạy trên một máy nào đó. Việc phân bổ bộ xử lí có thể tuỳ biến theo mục đích mà ứng dụng cần đạt được. Ví dụ, mục tiêu có thể là để đạt được hiệu năng CPU cao tức là không có CPU nào có thời gian nghỉ. Mục tiêu cũng có thể là tối thiểu hoá thời gian phản hồi trung bình. Hình 1.17 là một ví dụ về phân bổ 2 tiến trình cho 2 bộ xử lí. Bộ xử lí 1 có tốc dộ 10MIPS, bộ xử lí 2 có tốc độ 100MIPS, nhưng thời gian phải chờ trong queue là 5 giây. Tiến trình A có 100 triệu lệnh, tiến trình
B có 300 triệu lệnh. Thời gian phản hồi của mỗi tiến trình trên từng bộ xử lí có thể được tính như hình 1.17.
Hình 1.17: Thời gian phản hồi của từng tiến trình trên từng bộ xử lí.
Theo đó, thời gian phản hồi trong trường hợp tiến trình A chạy trên bộ xử lí 1, tiến trình B chạy trên bộ xử lí 2 là (10+8)/2=9 giây. Trường hợp bộ xử lí 1 chạy tiến trình B còn bộ xử lí 2 chạy tiến trình A, thời gian phản hồi sẽ là (30+6)/2=18 giây. Rõ ràng cách phân bổ như trường hợp đầu sẽ có thời gian phản hồi nhỏ hơn.
Tối ưu hơn người ta có thể thực hiện phân bổ bộ xử lí theo tỉ lệ phản hồi (response ratio), là tỉ lệ giữa thời gian cần thiết để thực hiện một tiến trình nào đó trên một hệ thống trên thời gian chuẩn của tiến trình đó.
1.4.4 Scheduling trong các hệ thống phân tán: