Tối ưu hoá ứng dụng ngân hàng trên nền hệ thống phân tán777

- Các phần mềm, hệ điều hành, các ngôn ngữ lập trình, và các ứng dụng phải được thiết kế, thực hiện một cách tương thích với hệ thống phân tán - Phụ thuộc vào chất lượng mạng truyền thôn

B Ộ GIÁO DỤ C VÀ ĐÀO T Ạ O TRƯỜ NG Đ Ạ I H C BÁCH KHOA HÀ NỘI Ọ

PHAN LÊ TUẤN

T Ố I ƯU HÓA Ứ NG DỤNG NGÂN HÀNG TRÊN NỀ N

H Ệ THỐNG PHÂN TÁN

LUẬ N VĂN TH C SĨ Ạ NGÀNH ĐIỆ N TỬ ỄN THÔNG VI

Hà N i, 20 ộ 06

PHAN LÊ TUẤN

T Ố I ƯU HÓA Ứ NG DỤNG NGÂN HÀNG TRÊN NỀ N

H Ệ THỐNG PHÂN TÁN

LUẬ N VĂN TH C SĨ Ạ NGÀNH ĐIỆN TỬ VIỄN THÔNG

NGƯỜ I HƯ Ớ NG D N Ẫ :

TS.NGUYỄN CHẤN HÙNG

Hà N i, 20 ộ 06

Viết tắt

Tóm tắt

Abstract

MỞ ĐẦU

Chương I Tổng quan về hệ thống tính toán phân tán- 1

1 1.1 Lịch sử phát triển của các hệ thống phân tán

1.1.1 Các nguyên lí phần cứng 2

1.1.2 Các nguyên lí phần mềm 4

1.2 Truyền thông trong các hệ thống phân tán 5

1.2.1 Các giao thức phân lớp 5

1.2.2 Các mạng ATM 5

1.2.3 Mô hình client/server 5

1.3 Đồng bộ trong các hệ thống phân tán 12

1.3.1 Đồng bộ đồng hồ 13

1.3.2 Vấn đề xung đột giữa các tiến trình 16

1.3.3 Các giải thuật lựa chọn 19

1.3.4 Các giao dịch nguyên tử 22

1.3.5 Deadlocks trong các hệ thống phân tán 25

1.4 Các tiến trình và bộ xử lí trong các hệ thống phân tán 27

1.4.1 Threads 27

1.4.2 Các mô hình hệ thống 28

1.4.3 Phân bổ bộ xử lí 30

1.4.4 Scheduling trong các hệ thống phân tán 31

1.4.5 Khả năng chịu lỗi 33

1.5.2 Giao diện Directory Server 39

1.5.3 Chia sẻ file 39

1.5.4 Caching 42

1.5.5 Tính toàn vẹn của cache 45

1.5.6 Replication 46

1.5.7 Các giao thức cập nhật 48

1.5.8 Các xu hướng phát triển của hệ thống file phân tán 50

1.6 Bộ nhớ chia sẻ phân tán 51

1.6.1 Giới thiệu 52

1.6.2 Bộ nhớ chia sẻ 53

1.6.3 Các mô hình toàn vẹn 63

1.6.4 Bộ nhớ chia sẻ phân tán page-based 64

1.6.5 Bộ nhớ chia sẻ phân tán chia sẻ biến 73

1.6.6 Bộ nhớ chia sẻ phân tán object-based 73

Chương II Hệ thống core banking - 76

2.1 Giới thiệu 76

2.1.1 Cấu hình máy chủ tại các điểm thanh toán 76

2.1.2 Phần truyền thông 77

2.2 Các ứng dụng chạy trên hệ thống core banking 78

2.2.1 Hệ thống bù trừ liên ngân hàng 78

2.2.2 Hệ thống xử lí tài khoản quyết toán 79

Chương III-Mô hình high-performance cho hệ thống core banking 81

3.1 Kiến trúc high-performance 81

3.1.1 Mô hình tham khảo cho kiến trúc Client/Server 81

3.1.5 Ý nghĩa high performance 85

-3.2 Thiết kế hệ thống high-performance 86

3.2.1 Thiết kế các hệ thống thời gian thực 86

3.2.2 Thiết kế một ứng dụng phân tán 87

91 3.2.3 Mô hình thời gian phản hồi tham chiếu Kết luận và kiến nghị

Tài liệu tham khảo

Chương I TỔNG QUAN VỀ HỆ THỐNG TÍNH TOÁN PHÂN TÁN

1.1 Lịch sử phát triển của các hệ thống phân tán:

Kỉ nguyên phát triển của máy tính hiện đại bắt đầu từ năm 1945, cho tới năm

1985, máy tính vẫn có kích thước lớn và đắt tiền Bắt đầu từ giữa năm 1980,

có hai thành tựu công nghệ đã làm thay đổi hoàn toàn bộ mặt của nền công nghệ máy tính Đầu tiên là sự ra đời và phát triển của các bộ vi xử lí mạnh nhưng có giá thành thấp hơn các bộ xử lí cũ, 8-bit, 16 bit, 32 bit, rồi 64-bit - -Thứ hai là phát minh ra các mạng máy tính tốc độ cao Các mạng LAN cho phép hàng chục thậm chí hàng trăm thiết bị nối với nhau để trao đổi dữ liệu

mà chỉ mất khoảng thời gian cỡ mili giây Các mạng WAN cho phép hàng triệu thiết bị trên thế giới kết nối với nhau ở tốc độ từ 64kbps đến hàng Gbps Kết quả là, các thiết bị khác nhau được nối với nhau qua mạng tốc độ cao để hình thành các hệ thống tính toán bao gồm rất nhiều CPU Chúng được gọi là các hệ thống phân tán để phân biệt với các hệ thống tính toán tập trung trước

đó bao gồm một CPU đơn, với memory, các thiết bị ngoại vi và một số terminal

Ưu điểm của hệ thống phân tán so với hệ thống tập trung:

- Đạt được tỉ lệ giá/performance cao hơn

- Độ tin cậy cao hơn, nhờ khả năng phân bổ workload đến các máy tính trong mạng

- Khả năng mở rộng hệ thống mềm dẻo hơn

- Tốc độ tính toán cao hơn, bằng tổng năng lực tính toán của tất cả các thiết bị trong mạng

Nhược điểm:

- Các phần mềm, hệ điều hành, các ngôn ngữ lập trình, và các ứng dụng phải được thiết kế, thực hiện một cách tương thích với hệ thống phân tán

- Phụ thuộc vào chất lượng mạng truyền thông

- Vấn đề bảo mật thông tin dùng chung

1.1.1 Các nguyên lý phần cứng:

Vì hệ thống phân tán bao gồm nhiều CPU, nên cũng có nhiều cách khác nhau

để liên kết và trao đổi trong tin giữa chúng Người ta chia các máy tính loại nhiều luồng lệnh, nhiều luồng dữ liệu (multiple instruction stream, multiple

data stream-MIMD) thành 2 nhóm: nhóm chia sẻ bộ nhớ gọi là multiprocessor, còn nhóm không chia sẻ bộ nhớ gọi là multicomputers

Hình 1.1: Phân loại các hệ thống tính toán phân tán

Bus-Based Multiprocessors:

Hệ thống Bus based multiprocessors bao gồm một số CPU nối với nhau qua một bus chung tới bộ nhớ Vì chỉ có một bộ nhớ nên nếu CPU A ghi một từ vào bộ nhớ thì CPU B đọc từ này sau đó vài mili giây sẽ đọc được giá trị mà

ra còn có snooping cache, loại này luôn giám sát bus, để nếu có yêu cầu ghi lên từ nhớ có trên cache mà bus bận thì nó sẽ xoá từ nhớ này khỏi cache, còn nếu bus rỗi thì nó sẽ cập nhật giá trị mới này vào bộ nhớ chính

Mỗi CPU có một liên kết đến thẳng bộ nhớ local riêng của nó, vấn đề còn lại

là các CPU sẽ liên kết với nhau như thế nào Do lưu lượng dữ liệu trên đường kết nối giữa các CPU thấp hơn so với trong kiến trúc multiprocessor nên tốc

độ bus không nhất thiết phải cao, thường từ 10-100Mbps

Hình 1.3: Bus based multiprocessor

Các hệ thống chia sẻ thời gian multiprocessor:

Đặc tính quan trọng nhất của loại hệ thống này là sự tồn tại của chỉ một queue, đây là danh sách các tiến trình trong hệ thống đang sẵn sàng để chạy Queue này là một cấu trúc dữ liệu nằm trong bộ nhớ Ví dụ: có 3 CPU và 5 tiến trình đang sẵn sàng để chạy, cả 5 tiến trình này được đặt trong bộ nhớ chia sẻ và 3 trong số đó đang chạy, tiến trình A trên CPU1, tiến trình B trên CPU2, tiến trình C trên CPU3 Hai tiến trình còn lại, C và D cùng nằm trong

bộ nhớ, chờ đến lượt để chạy

Hình 1.4: Multiprocessor với một hàng đợi

1.2 Truyền thông trong các hệ thống phân tán:

Sự khác biệt lớn nhất giữa một hệ thống phân tán và hệ thống đơn xử lí là vấn

1.2.3 Mô hình Client/Server:

Như đã phân tích, mạng ATM có ưu điểm về mặt kĩ thuật nhưng giá thành cao, nên trong thực tế, mô hình giao thức phân lớp OSI được sử dụng cho các ứng dụng phân tán Vấn đề cần giải quyết là việc thêm các header ở các lớp sẽ làm tăng dung lượng gói tin truyền trong mạng Mỗi khi message được gửi đi,

nó được xử lí bởi nhiều lớp, mỗi lớp tạo và thêm header ứng với từng lớp, và chỉ được tách ra ở phía nhận Công việc này tốn khá nhiều thời gian

Trong các mạng WAN, tốc độ truyền thường khá thấp, dung lượng truyền dẫn

bị giới hạn (khoảng 64kbps), các CPU xử lí đủ nhanh làm cho đường truyền luôn hoạt động ở tốc độ tối đa

Với các hệ thống phân tán hoạt động trên mạng LAN, thời gian CPU dùng để

xử lí các giao thức nhiều đến nỗi thông lượng mạng LAN thường chỉ là một phần nhỏ trong tổng dung lượng của mạng LAN Do đó, hầu hết các hệ thống phân tán trong mạng LAN thường không sử dụng các giao thức phân lớp, nếu

có dùng thì chỉ là một phần nhỏ của các giao thức này

Ngoài ra, mô hình OSI chỉ thực hiện một phần nhỏ của ứng dụng, đó là gửi các bit thông tin từ nơi gửi đến nơi nhận Nó không đề cập đến cấu trúc của một hệ thống phân tán

1.2.3.1 Client và Server:

Ý tưởng của mô hình này là xây dựng hệ điều hành thành một nhóm các tiến trình phối hợp hoạt động với nhau, gọi là server, cung cấp các dịch vụ cho người dùng, còn gọi là client Giao thức sử dụng trong mô hình này là request/reply protocol

Client/Server là hệ thống phân tán trong đó ứng dụng được chia ít nhất thành

2 phần: một hoặc nhiều server thực hiện một phần công việc, còn phần khác được thực hiện bởi các client Client kết nối với Server qua mạng Client hầu như không thực hiện xử lí ứng dụng mà chỉ hiển thị kết quả đã nhận được từ server, client phức tạp hơn có thể chạy toàn bộ ứng dụng và sử dụng các dữ liệu lấy từ server Các hệ thống client/server thường được phân làm 2 loại là 2-tier và 3 tier Hệ thống 2 tier phân biệt giữa client và server như sau: các - -client nằm trên một tier, các server nằm trên tier thứ 2, ví dụ: client PC có thể truy suất đến dữ liệu trên một hoặc nhiều máy chủ Trong hệ thống 3-tier, client và server cũng nằm ở 2 tier khác nhau nhưng ngoài ra còn có lớp trung

gian Ví dụ, client PC có thể nối tới web server, sau đó web server truy suất đến máy chủ dữ liệu để thực hiện lưu trữ

Các ngôn ngữ lập trình hiện đại cung cấp các cấu trúc để xây dựng các ứng dụng phân tán dựa trên mô hình client/server Các ứng dụng này phân bố trên client và server, là các máy tính khác nhau trong mạng Client gửi yêu cầu tới server và chờ được phúc đáp Khi server nhận được yêu cầu, nó xử lí yêu cầu này và gửi kết quả trở lại cho client Trong môi trường client/server truyền

thống, server thường là các máy tính mạnh, xử lí yêu cầu của nhiều client cùng một lúc Ví dụ trong hệ thống cơ sở dữ liệu, nhiều client gửi yêu cầu đến server để truy suất cơ sở dữ liệu Server thực hiện các truy suất thay cho client

và gửi lại các kết quả cho client tương ứng Xử lí đa luồng được xem là cách tốt nhất để cung cấp các ứng dụng server Mỗi tiến trình server có thể phục vụ nhiều client như hình 1.5 Mỗi client yêu cầu được phục vụ và tạo thành một luồng mới trong server

Hình 1.5: Mỗi client được xem là một thread đối với server

Để client và server có thể liên lạc được với nhau, người ta gán cho client và server một địa chỉ, thông thường là các địa chỉ IP

1.2.3.2 Sockets:

Socket được dùng để cung cấp tính năng tạo các kết nối từ một ứng dụng đang chạy trên một máy tính này sang một ứng dụng đang chạy trên máy tính khác Socket gồm một cấu trúc dữ liệu lưu các thông tin cần thiết để liên lạc

và lời gọi hệ thống để thực hiện cấu trúc này Khi socket được tạo, nó có thể được dùng để chờ kết nối đến (socket thụ động) hoặc dùng để thiết lập kết nối (socket chủ động)

Client có thể thiết lập một kết nối chủ động đến máy chủ ở xa bằng cách tạo một socket Để thiết lập kết nối máy chủ và gán nó với một port number nào

đó chúng ta cần tạo một server socket Server socket "lắng nghe" trên một port TCP nào đó để chờ kết nối từ client (socket thụ động) Khi client kết nối tới port này, server sẽ chấp nhận kết nối Khi kết nối được thiết lập, client và server có thể đọc và ghi từ socket dùng các luồng vào ra

1.2.3.3 Lời gọi thủ tục từ xa (Remote Procedure Call-RPC):

Mặc dù mô hình Client/Server là cách hiệu quả để xây dựng hệ điều hành phân tán, nhưng nó có một thiếu sót: mô hình truyền thông được xây dựng trên đầu vào và đầu ra Các thủ tục send và receive về cơ bản sẽ thực hiện các lệnh I/O Nhưng I/O không phải là nguyên tắc chính của các hệ thống phân tán Birrell và Nelson (1984) đã đưa ra phương pháp hoàn toàn khác để giải quyết vấn đề này, nó cho phép các chương trình có thể gọi các thủ tục trên

máy khác Khi một tiến trình trên máy A gọi một thủ tục trên máy B, tiến trình gọi thủ tục trên máy A được duy trì, thủ tục được gọi sẽ được xử lý trên máy B Thông tin mà nơi gọi gửi cho nơi nhận là các thông số của thủ tục, còn thông tin phản hồi là kết quả thực hiện thủ tục này Như vậy không hề có trao đổi message và I/O Phương pháp này gọi là RPC Vấn đề của phương

pháp này là, thủ tục gọi và thủ tục được gọi chạy trên 2 máy khác nhau, chúng được thực hiện trong các không gian địa chỉ khác nhau, điều này khá phức tạp Nếu các máy là khác nhau thì việc trao đổi các tham số và kết quả phản hồi cũng phức tạp hơn

3 Chương trình phía client tạo message và gửi cho kernel

4 Kelnel phía client gửi message này tới kelnel của server

5 Kelnel của server chuyển message cho chương trình trên máy server

6 Chương trình trên máy server mở message để lấy các tham số và gọi thực hiện chương trình với các thông số này

7 Server thực hiện chương trình và trả lại kết quả

8 Chương trình trên server đóng gói các kết quả này vào message và chuyển cho kernel phía server

9 Kernel gửi message cho kernel phía client

10 Kernel của client chuyển message tới chương trình phía client đang chờ Chương trình sẽ lấy ra kết quả và trả lại cho client

Trao đổi tham số:

Thủ tục ở phía client mà sẽ được thực hiện ở server gọi là client stub, còn thủ tục được thực hiện ở phía server gọi là server stub Chức năng của client stub

là xác định các tham số của nó, đặt chúng vào message rồi gửi cho server stub Việc đóng gói các tham số vào message gọi là parameter marshalling Hình 1.7 là một ví dụ về phương pháp thực hiện câu lệnh tính tồng của 4 và 7

dịch lại Để giải quyết vấn đề này, các hệ thống phân tán sử dụng kĩ thuật dynamic binding để kết nối client và server với nhau

Trước hết, ta phải xác định các đặc tính của server, ví dụ tên của server, version number và danh sách các thủ tục mà nó cung cấp (đọc, viết, tạo và xóa) Mỗi thủ tục khai báo các tham số của nó, các tham số có thể là tham số vào, ra, hay vào ra, hướng của chúng so với server Tham số vào, chẳng hạn tên một file, được gửi tới server từ client

1.2.3.4 Thông tin nhóm:

Trong thực tế, thường có rất nhiều tiến trình thông tin với nhau, ví dụ các file server kết hợp với nhau, dịch vụ fault tolerant … Trong các hệ thống như vậy, -client yêu cầu phải gửi message tới tất cả các server, để đảm bảo yêu cầu luôn được thực thi ngay cả khi một trong số các server bị lỗi RPC không thể thực hiện trao đổi thông tin từ một người gửi đến nhiều người nhận, mà phải thực hiện các RPC khác nhau

Giới thiệu thông tin nhóm:

Nhóm là tập hợp các tiến trình hoạt động cùng nhau trên một số hệ thống Đặc tính chủ yếu của nhóm là khi message được gửi tới nhóm thì tất cả các thành viên đều nhận được nó

Các hệ thống hỗ trợ thông tin nhóm có thể được chia thành 2 loại phụ thuộc vào việc ai là người gửi và ai là người nhận:

- Closed groups: Chỉ các thành viên của nhóm mới có thể gửi thông tin cho nhóm, các tiến trình ngoài nhóm có thể gửi thông tin cho từng tiến trình cụ thể trong nhóm nhưng không thể gửi thông tin đồng thời cho cả nhóm

- Open groups: Một tiến trình bất kì đều có thể gửi thông tin cho cả nhóm

Hình 1.8: Thông tin nhóm

Các nhóm cũng có thể được phân thành loại đồng cấp, trong đó các tiến trình đều có vai trò như nhau, hoặc lại phân cấp, trong đó có một tiến trình đóng vai trò điều phối, khi một tiến trình nào đó gửi một yêu cầu thì nó sẽ gửi yêu cầu đó cho tiến trình đóng vai trò điều phối này

Thành viên nhóm:

Việc đăng kí hoặc xoá tư cách thành viên nhóm có thể được thực hiện bởi

group server, group server sẽ duy trì một danh sách các thành viên trong nhóm cũng như các thông tin khác về nhóm Phương pháp này thực hiện đơn giản và hiệu quả nhưng có nhược điểm là có thể tạo ra single point of failure Một biện pháp khác để quản lí các thành viên trong nhóm là dùng phương pháp phân tán

1.3 Đồng bộ trong các hệ thống phân tán:

Trong các hệ thống CPU đơn lẻ, vấn đề đồng bộ được giải quyết bằng các phương pháp như semaphore và giám sát Các phương pháp này không còn thích hợp đối với hệ thống phân tán vì chúng dựa trên cơ chế chia sẻ bộ nhớ

Ví dụ, hai tiến trình tương tác với nhau sử dụng semaphore phải cùng có khả năng truy suất được semaphore đó Nếu chúng chạy trên cùng một máy, chúng có thể chia sẻ semaphore bằng cách chứa semaphore trong kernel của

hệ điều hành, và các lời gọi hệ thống sẽ được gọi để truy suất tới semaphore Tuy nhiên nếu 2 tiến trình chạy trên 2 máy khác nhau thì không thể làm việc theo cách này được, cần phải dùng phương pháp khác

1.3.1 Đồng bộ đồng hồ:

Đồng bộ trong hệ thống phân tán phức tạp hơn so với các hệ thống tập trung

vì phải sử dụng các thuật toán phân tán Ta không thể thu thập tất cả thông tin

về hệ thống ở một nơi rồi sau đó mới sử dụng các tiến trình để kiểm tra và ra quyết định như trong các hệ thống tập trung Nói chung, các giải thuật phân tán thường có các đặc tính sau đây:

1 Thông tin cần thiết nằm phân tán trên nhiều máy khác nhau

2 Các tiến trình ra quyết định chỉ dựa trên thông tin cục bộ

3 Có thể tránh được single point of failure

4 Không có một đồng hồ chung hay các nguồn cung cấp thời gian toàn cục chính xác

Ba đặc tính đầu tiên chỉ ra rằng, không thể thu thập tất cả thông tin về một nơi

để xử lí, ví dụ: để phân chia tài nguyên (phân chia các thiết bị I/O theo kiểu deadlock-free), ta không thể gửi tất cả các yêu cầu đến một tiến trình quản lí đơn để kiểm tra tất cả và chấp nhận hay không chấp nhận yêu cầu dựa trên các thông tin trong các bảng của nó Trong các hệ thống lớn, giải pháp này sẽ làm cho một tiến trình này bị quá tải

cả các thiết bị thống nhất với nhau về thời gian chứ không cần phải chính xác tuyệt đối Để đồng bộ các đồng hồ logic, Lamport đã đưa ra giải thuật sau, được gọi là giải thuật happens-before:

Kí hiệu a->b là sự kiện a xẩy ra trước sự kiện b, quan hệ happens-before có thể ở 2 trạng thái sau đây:

1 Nếu 2 sự kiện a và b nằm trong cùng một tiến trình và a xẩy ra trước b thì a->b là đúng

2 Nếu a là sự kiện một tiến trình gửi đi một message và b là sự kiện một tiến trình khác nhận message đó thì a >b cũng là đúng -

Sau đây là một ví dụ:

Xét 3 tiến trình khác nhau chạy trên 3 máy khác nhau như hình 1.9

Hình 1.9: (a) Ba tiến trình, mỗi tiến trình có một đồng hồ riêng chạy ở 3 tốc

độ khác nhau (b) Giải thuật của Lamport để sửa sai của các đồng hồ

Như ta thấy trên hình 1.9(a) message C có thời điểm gửi là 60 trong khi thời điểm đến trên tiến trình 1 là 56, tương tự với message D, thời điểm gửi là 64 còn thời điểm nhận là 54 Cả 2 trường hợp đều có thời điểm nhận nhỏ hơn thời điểm gửi, để giải quyết vấn đề này, thời điểm đến sẽ được cộng thêm 1

Như trong hình 1.9(b) Trong trường hợp có nhiều tiến trình, không thể có cùng 2 sự kiện xẩy ra tại cùng một thời điểm

1.3.1.2 Đồng hồ vật lý:

Trong một số ứng dụng, các đồng hồ không nhất thiết phải giống nhau, nhưng cũng không được chênh lệch quá một giá trị nhất định, các đồng hồ như vậy gọi là các đồng hồ vật lí Để thực hiện việc đồng bộ các đồng hồ vật lý, người

ta sử dụng các trạm phát tín hiệu chuẩn

1.3.1.3 Các giải thuật đồng bộ đồng hồ:

Có nhiều giải thuật khác nhau để đồng bộ các đồng hồ vật lý khi không có bộ thu tín hiệu chuẩn từ trạm phát

Giải thuật Cristian:

Giải thuật này dựa trên một thiết bị có bộ thu tín hiệu đồng bộ gọi là time server Các máy khác trong hệ thống sẽ định kì gửi một thông điệp cho time server để xác định thời gian hiện tại Theo đó, ta phải tính toán cả thời gian trễ trên đường truyền cũng như thời gian truy vấn ở time server để xác định một cách chính xác thời gian hiện tại

Giải thuật Berkeley:

Với giải thuật Cristian, time server hoàn toàn thụ động, chờ truy vấn từ các thiết bị khác trong hệ thống Còn với giải thuật Berkeley, time server hoàn toàn chủ động thông báo cho các máy trong hệ thống thời gian hiện tại Hoạt động của giải thuật Berkeley có thể được mô tả như hình 1.10

Hình 1.10: (a) time server hỏi các thiết bị khác về thời gian hiện tại của chúng (b) Các thiết bị trả lời (c) time server thông báo sai lệch để các thiết bị điều chỉnh đồng hồ của mình

Các giải thuật lấy trung bình:

Cả 2 phương pháp trên đều mang tính tập trung cao, tuy nhiên cũng có nhiều

nhược điểm Người ta cũng có thể sử dụng các giải thuật đồng bộ phi tập trung hoá, phương pháp này chia thời gian thành các khoảng bằng nhau cố định Khoảng thời gian thứ i bắt đầu từ thời điểm TR 0 R+iR và kéo dài cho đến thời điểm TR 0 R+(i+1)R, trong đó TR 0 R là thời điểm đã được thoả thuận trước, còn

R là thông số của hệ thống Tại mỗi thời điểm như vậy các thiết bị trong mạng phát tán thời gian hiện tại theo đồng hồ của mình Vì các thiết bị hoạt động ở tốc độ khác nhau nên thời điểm phát tán này không diễn ra đồng thời Sau đó chúng thu thập các bản tin phát tán của các thiết bị khác trong mạng, rồi dựa

vào các giá trị này tính ra giá trị trung bình của thời gian sẽ được thiết lập trong đồng hồ của mình

1.3.2 Vấn đề xung đột giữa các tiến trình:

Các hệ thống nhiều tiến trình sử dụng các vùng tới hạn (critical region) để tránh xung đột khi truy suất dữ liệu, ví dụ: khi một tiến trình đọc hoặc cập nhật cấu trúc dữ liệu chia sẻ, trước hết nó phải chuyển tới vùng tới hạn để loại trừ lẫn nhau và đảm bảo tại cùng thời điểm đó không có tiến trình khác sử dụng các cấu trúc chia sẻ này Trong các hệ thống một bộ xử lí, các vùng giới hạn được thực hiện nhờ sử dụng các semaphore, các bộ giám sát và các cấu trúc tương đương Với các hệ thống phân tán, người ta sử dụng các phương pháp khác

1.3.2.1 Giải thuật tập trung:

Một tiến trình sẽ được chọn làm tiến trình điều phối, bất kể tiến trình nào muốn chuyển vào vùng tới hạn đều phải gửi một bản tin yêu cầu tới tiến trình điều phối để xin phép Nếu hiện tại không có tiến trình nào đang ở trong vùng

tới hạn thì tiến trình điều phối sẽ gửi thông tin chấp nhận trở lại tiến trình đang yêu cầu, tiến trình đó sẽ chuyển tới vùng tới hạn

Sau đây là một ví dụ về hoạt động của giải thuật tập trung, hình 1.11

Hình 1.11: (a) tiến trình 1 tiến trình điều phối cấp quyền để chuyển tới vùng tới hạn, và được đồng ý (b) Tiến trình 2 sau đó cũng yêu cầu được chuyển tới

vùng tới hạn ấy, tiến trình điều phối từ chối (c) khi tiến trình 1 thoát khỏi vùng tới hạn, nó thông báo cho tiến trình điều phối biết để tiến trình điều phối thông báo cho tiến trình 2 biết

Giả sử một tiến trình khác, 2, yêu cầu được chuyển tới vùng tới hạn, tiến trình điều phối thấy rằng có một tiến trình khác đang ở vùng tới hạn nên nó không cho phép tiến trình 2 chuyển tới vùng tới hạn

1.3.2.2 Giải thuật phân tán:

Giải thuật tập trung sẽ tạo ra single point of failure, người ta phải sử dụng giải thuật phân tán để giải quyết vấn đề này Giải thuật này hoạt động như sau: Khi một tiến trình muốn chuyển đến vùng tới hạn, nó sẽ tạo một thông điệp chứa thông tin về tên vùng tới hạn mà nó muốn chuyển đến, số hiệu tiến trình của nó, và thời gian hiện tại Sau đó nó gửi bản tin này cho tất cả các tiến trình khác và chờ các thông báo xác nhận cho bản tin này Khi một tiến trình nhận được bản tin yêu cầu từ một tiến trình khác, tuỳ vào trạng thái của vùng tới hạn có tên trong bản tin, nó có thể thực hiện một trong 3 việc sau:

1 Nếu tiến trình nhận được bản tin không ở trong vùng tới hạn và cũng không có nhu cầu chuyển tới vùng tới hạn thì nó gửi bản tin OK trở lại cho tiến trình đã gửi bản tin yêu cầu

2 Nếu tiến trình nhận đang ở trong vùng tới hạn, nó sẽ không trả lời bản tin yêu cầu, mà thực chất là đưa bản tin yêu cầu vào hàng đợi

3 Nếu tiến trình nhận muốn chuyển vào vùng tới hạn, nhưng vẫn chưa thực sự ở vùng tới hạn thì nó sẽ so sánh thời gian trong bản tin yêu cầu với thời gian trong bản tin yêu cầu mà nó đã gửi cho các tiến trình khác, bản tin nào có thời gian sớm hơn sẽ được chấp nhận Nếu bản tin

mà nó nhận được có thời gian nhỏ hơn thì tiến trình sẽ gửi trở lại cho tiến trình yêu cầu một bản tin OK Nếu bản tin mà tiến trình đã gửi có mốc thời gian thấp hơn bản tin mà nó nhận được thì nó sẽ đưa bản tin yêu cầu vào hàng đợi và không gửi bản tin phản hồi

Hình 1.12: (a) Có 2 tiến trình cùng muốn chuyển vào vùng tới hạn tại cùng một thời điểm (b) Tiến trình 0 có timestamp nhỏ nhất nên nó sẽ được chuyển vào vùng tới hạn (c) Khi tiến trình 0 đã thực hiện xong, nó gửi thông điệp

OK, khi đó tiến trình 2 sẽ được chuyển vào vùng tới hạn

1.3.2.3 Giải thuật Token Ring:

Hoạt động dựa trên việc cấp cho các tiến trình một số thứ tự, tiến trình cấp

thấp nhất sẽ được cấp một thẻ (token), thẻ này sẽ luân chuyển trong mạng theo thứ tự đã phân cấp

1.3.3 Các giải thuật lựa chọn:

Nhiều giải thuật phân tán cần một tiến trình hoạt động như một tiến trình điều phối, initiator, sequencer để thực hiện một số nhiệm vụ đặc biệt Nếu tất cả các tiến trình không có đặc tính khác biệt nhau thì không thể chọn được một tiến trình đặc biệt nào cả Do đó ta giả thiết là mỗi tiến trình đều có một số phân biệt ví dụ như địa chỉ mạng (ở đây ta coi mỗi tiến trình nằm trên một máy khác nhau) Nói chung, các giải thuật lựa chọn có gắng định vị một tiến trình có số hiệu tiến trình cao nhất làm tiến trình điều phối, các giải thuật khác nhau ở cách định vị tiến trình này

1.3.3.1 Giải thuật Bully:

Giải thuật này lựa chọn một tiến trình mà khi không thấy phản hồi từ tiến trình điều phối nào cả về bản tin yêu cầu của nó làm tiến trình điều phối Một tiến trình, P, được chọn theo cách như sau:

1 P gửi bản tin ELECTION cho tất cả các tiến trình có số hiệu tiến trình cao hơn

2 Nếu không có phản hồi, P sẽ trở thành tiến trình điều phối

3 Nếu có một tiến trình có số hiệu cao hơn phản hồi, tiến trình P sẽ thực hiện công việc như bình thường

Hình 1.13 là một ví dụ về giải thuật Bully

Hình 1.13: Giải thuật Bully, (a) tiến trình 4 giữ quyền được lựa chọn, (b) tiến trình 5 và 6 thông báo cho tiến trình 4 để nhận quyền được lựa chọn, (c) 5,6 đều giữ quyền được lựa chọn, (d) 6 thông báo cho 5 biết để giữ quyền được lựa chọn, (e) tiến trình 6 thông báo cho các tiến trình khác về vai trò điều phối

của mình

Một nhóm 8 tiến trình có số hiệu từ 0 đến 7 Trước đây, tiến trình 7, với số hiệu tiến trình cao nhất đã được chọn là tiến trình điều phối, nhưng đã bị lỗi

Tiến trình 4 là tiến trình đầu tiên phát hiện ra điều này, nó gửi các bản tin ELECTION cho tất cả các tiến trình có số hiệu cao hơn nó là 5,6 và 7 Tiến trình 5,6 gửi lại bản tin OK, tiến trình 4 biết rằng đã có một tiến trình nào đó được chọn làm tiến trình điều phối Cả 5 và 6 đều giữ quyền được lựa chọn,

và cùng gửi các bản tin ELECTION tương tự như trên, cuối cùng 6 được chọn

là tiến trình điều phối 4 chấp nhận điều này và trong khi chờ tiến trình 7 khôi phục hoạt động trở lại, nó sẽ xem 6 là tiến trình điều phối

1.3.3.2 Giải thuật Ring:

Khi một tiến trình nào đó phát hiện thấy tiến trình điều phối không hoạt động,

nó sẽ tạo một bản tin ELECTION chứa số hiệu tiến trình của nó và gửi cho

tiến trình kế tiếp Nếu tiến trình kế tiếp không hoạt động, bản tin sẽ được chuyển tiếp cho tiến trình tiếp sau, mỗi tiến trình đều ghi lại số hiệu tiến trình của mình vào bản tin này

Hình 1.14: Giải thuật lựa chọn sử dụng vòng ring

Sau khi bản tin trở về nơi xuất phát nó sẽ được chuyển thành bản tin COORDINATOR và quay vòng một lần nữa để thông báo cho các thành viên trong mạng biết tiến trình điều phối mới (ứng với tiến trình có số hiệu cao nhất trong bản tin lúc đầu), hình 1.14

1.3.4 Các giao dịch nguyên tử:

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

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

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

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 đã

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

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:

Thông thường, mỗi bộ xử lí thực hiện tự lập trình lịch cho các tiến trình chạy trên nó (giả sử có nhiều tiến trình cùng chạy trên bộ xử lí này) mà không cần quan tâm đến việc các bộ xử lí khác đang làm gì Tuy nhiên, khi có các tiến trình tương tác và có quan hệ với nhau chạy trên các bộ xử lí khác nhau, thì phương pháp scheduling độc lập không còn phù hợp nữa

Hình 1.18 là một ví dụ, trong đó các tiến trình A và B chạy trên một bộ xử lí, còn C và D chạy trên bộ xử lí kia Các bộ xử lí hoạt động theo nguyên tắc

chia sẻ thời gian, với time slice là 100ms, A và C sẽ chạy trên các time slice chẵn, B và D chạy trong các time slice lẻ

Hình 1.18: (a) 2 job chạy lệch pha nhau (b) Ma trận scheduling cho 8 bộ xử

lí, mỗi bộ có 6 khe thời gian, các dấu X chỉ các khe thời gian đã được cấp

Giả sử A gửi nhiều thông điệp hoặc gọi nhiều lệnh cho D Trong time slice, A khởi tạo và gọi D, nhưng hiện tại D chưa chạy, sau 100ms D mới nhận được thông điệp của A và trả lời ngay, nhưng ở bộ xử lí 0 B đang chạy, và phải mất 100ms sau nữa, A mới nhận được phản hồi này và xử lí nó Như vậy, việc trao đổi thông điệp phải mất 200ms

Ousterhour (1982) đã giới thiệu một số giải thuật dựa trên nguyên lí mà ông gọi là co-scheduling, nguyên lí này tính tới các thành phần thông tin giữa các tiến trình, trong khi đảm bảo cho tất cả các thành viên trong một nhóm tiến trình đều chạy đồng thời

Giải thuật thứ nhất dựa trên ma trận trong đó mỗi cột là một bảng các tiến trình ứng với một bộ xử lí, như ví dụ trong hình 1.18(b) Cột 4 chứa tất cả các tiến trình chạy trên bộ xử lí 4, hàng 3 là tất cả các tiến trình chạy trên khe thời gian thứ 3 của tất cả các bộ xử lí Bằng cách đặt tất cả các thành viên của một nhóm tiến trình vào cùng một khe thời gian, giải thuật này sẽ đảm bảo cho tất

cả các tiến trình này đều chạy cùng một thời điểm, tối đa hoá thông lượng

1.4.5 Khả năng chịu lỗi:

Các lỗi thường gặp trong các hệ thống phân tán là:

Thời gian lỗi trung bình=∑∞ ( )

Khi ta không quan tâm đến hoạt động của từng thành phần trong hệ thống phân tán mà chỉ quan tâm đến tính chất có hoạt động hay không của ứng dụng thì các lỗi làm cho ứng dụng ngừng chạy đều gọi là lỗi hệ thống

Để tránh lỗi người ta thực hiện kĩ thuật Redundancy, kĩ thuật này gồm 3 loại,

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 là thực hiện thêm thông tin vào để phục vụ quá trình khôi phục thông tin khi bị mất (ví dụ mã Hamming) Dư thừa thời gian tức là có thể thực hiện lại một hành động nào đó nếu thấy cần thiết, ví dụ giao dịch nguyên tử Dư thừa vật lí

là sử dụng thêm các thiết bị để đề phòng trường hợp một số thiết bị đang làm việc không hoạt động

1.4.6 Các hệ thống phân tán thời gian thực:

Một hình thức khác của hệ thống phân tán là hệ thống thời gian thực, trên đó chạy các ứng dụng tương tác thời gian thực Khi có yêu cầu hệ thống phải đáp ứng theo một cách nhất định và có một mốc thời gian hoàn thành nhất định

Nếu hệ thống kết thúc công việc sau mốc thời gian này thì coi như không hoàn thành công việc

Hệ thống thời gian thực có thể phân làm 2 loại tuỳ thuộc mức độ cần thiết của mốc thời gian và hậu quả của việc mất thông tin:

1 Các hệ thống thời gian thực mềm

2 Các hệ thống thời gian thực cứng

Thời gian thực mềm có nghĩa là việc thỉnh thoảng xử lí không kịp mốc thời

gian nêu trên là có thể chấp nhận được Ngược lại, thời gian thực cứng là không thể chấp nhận được Thực tế còn có các hệ thống trung gian, nghĩa là nếu không đạt được mốc thời gian này thì phải kill tiến trình hiện tại nhưng kết quả không bị gián đoạn

Việc thiết kế các hệ thống thời gian thực có một số đặc điểm riêng, ta sẽ xem xét các đặc điểm quan trọng nhất

1.4.6.1 Đồng bộ đồng hồ:

Vấn đề đồng bộ đồng hồ cũng giống như trong các hệ thống phân tán thông thường như ta đã phân tích ở trên

1.4.6.2 Các hệ thống Event-Triggered và Time-Triggered:

Trong hệ thống thời gian thực event-triggered, khi một sự kiện có ý nghĩa xẩy

ra, các cảm biến sẽ xác định sự kiện này và gửi một ngắt đến CPU Hầu hết

các hệ thống thời gian thực hoạt động theo nguyên lí này Vấn đề của hệ thống này là khi có nhiều sự kiện xẩy ra cùng một lúc, hệ thống có thể bị quá tải

Hệ thống thời gian thực time-triggered không gặp phải vấn đề này, các ngắt

gửi tới CPU được quản lí bằng một đồng hồ, và được thực hiện sau mỗi khoảng thời gian ∆T nhất định Khoảng thời gian ∆T phải được chọn một cách hợp lí, vì nếu nó quá ngắn thì sẽ có quá nhiều ngắt hệ thống sẽ tốn nhiều thời gian không cần thiết để triển khai nó; còn nếu nó quá dài thì các sự kiện quan trọng sẽ không được cảnh báo kịp cho hệ thống

Tóm lại, hệ thống event triggered phù hợp trong môi trường ít tải, và sẽ bị quá tải khi tải của hệ thống tăng cao Còn hệ thống time triggered thì ngược -lại

-1.4.6.3 Khả năng dự báo trước:

Một trong những đặc tính quan trọng nhất của hệ thống thời gian là khả năng đoán trước Thông thường, khi sự kiện E xẩy ra, tiến trình X sẽ chạy, sau đó

là các tiến trình Y và Z, hoặc là chạy lần lượt hoặc là chạy song song với nhau Ví dụ, nếu tiến trình X cần 50ms, Y và Z cần 60ms và tiến trình cần 5ms để khởi động thì hệ thống có thể đảm bảo trước là có thể thực hiện được

5 sự kiện E trong 1 giây

1.4.6.4 Truyền thông thời gian thực:

Truyền thông trong các hệ thống thời gian thực khác với trong các hệ thống phân tán khác, vì luôn quan tâm đến performance, mà khả năng dự đoán và quyết định là các yếu tố quan trọng

Để đạt được khả năng dự báo thì truyền thông giữa các bộ xử lí phải có khả năng dự báo được Các giao thức LAN vốn đã mang tính ngẫu nhiên, chẳng hạn như Ethernet và chúng ta không thể đảm bảo thời gian truyền dẫn ở một ngưỡng nhất định nào đó Khi một máy gửi một bản tin vào mạng Ethernet,

nó có thể có xung đột với các máy khác, các máy sau đó phải chờ một khoảng thời gian ngẫu nhiên rồi mới gửi lại gói tin định gửi, nhưng nó vẫn có thể gây xung đột trong mạng… Như vậy thời gian gửi một gói tin trong mạng là không thể đoán trước

Không giống mạng Ethernet, mạng token ring LAN sẽ xử lí gói tin theo một cách khác Khi một bộ xử lí có một gói tin cần gửi, nó chờ cho token chuyển

đi một vòng trong mạng, sau đó thu lại token rồi mới gửi gói tin, trả lại token cho các máy khác trong mạng Ví dụ một vòng ring có k máy, một máy định gửi gói tin n-byte khi nhận được token, nó có thể đảm bảo rằng gói tin này có