Thực hiện caching trên client sẽ làm nảy sinh tính không toàn vẹn trong hệ thống. Nếu 2 client cùng đọc một file sau đó cả hai đều thay đổi nó, sẽ có lỗi xẩy ra, khi một tiến trình thứ 3 đọc file này từ server nó sẽ đọc được nội dung ban đầu của file chứ không phải là nội dung cập nhật mà 2 client đã thực hiện. Khi 2 file này được cập nhật về cho server, file cập nhật cuối cùng sẽ ghi đè lên file đã được cập nhật trước đó.
Để giải quyết bài toán toàn vẹn dữ liệu cho cache, người ta dùng giải thuật write-through. Khi một thực thể của cache bị thay đổi, giá trị mới sẽ được lưu trong cache, nhưng nó cũng đồng thời được cập nhật cho server. Kết quả là, khi một tiến trình khác đọc file này, nó sẽ nhận được giá trị mới nhất.
Tuy nhiên lại nảy sinh vấn đề khác, giả sử một tiến trình client trên máy A đọc file f, client này kết thúc nhưng máy vẫn giữ f trong cache, sau đó client ở máy B đọc file này, thay đổi nó và cập nhật tới server. Cuối cùng một tiến trình mới ở máy A mở và đọc file f, file này vẫn đang được lưu trên cache, nhưng giá trị này đã cũ, chưa được cập nhật. Để giải quyết vấn đề này, trình quản lí cache sẽ phải kiểm tra trên server trước khi client có thể truy suất file
trên cache, nó có thể tiến hành kiểm tra thời gian cập nhật mới nhất và cả checksum, việc này rõ ràng là tốn thời gian.
Giải thuật này cũng chỉ cải thiện tốc độ đọc, còn tốc độ ghi hầu như không thay đổi vì trao đổi dữ liệu trên mạng trong quá trình ghi không khác trường hợp không dùng cache. Người ta có thể cải thiện tốc độ ghi bằng cách tập hợp các file đã được cập nhật và gửi định kì tới server một lần cho tất cả.
Một số ứng dụng tạo ra các file tạm thời, ghi, đọc sau đó xoá chúng. Toàn bộ các file này sẽ được xoá trước khi đến thời điểm phải ghi lên server, điều này sẽ cải thiện đáng kể performance của hệ thống.
Giải thuật ghi file lên server sau khi đóng file gọi là giải thuật write-on-close, và thường chờ thêm 30 giây để xác định xem nó có bị xóa hay không.
Một giải thuật khác dùng để giải quyết vấn đề toàn vẹn dữ liệu trong cache là giải thuật điều khiển tập trung. Khi một file được mở, máy mở file sẽ gửi một thông điệp cho file server để thông báo về việc mở file này. File server sẽ theo dõi user đang thực hiện mở file, xác định xem nó được mở để đọc hay để ghi, hay cả hai. Nếu file được mở để đọc, sẽ không có vấn đề gì xẩy ra khi có một tiến trình khác cũng mở file để đọc, nhưng sẽ không cho tiến trình khác mở file này để ghi. Nếu tiến trình mở file để ghi, tất cả các truy suất khác đều bị
cấm. Khi file đóng lại, sự kiện này sẽ được ghi lại, sau đó server sẽ chọn client tiếp theo để truy suất file này. Nếu một client định mở file mà file này đã được mở trong hệ thống, thì yêu cầu này sẽ bị từ chối hoặc được sếp hàng để được phục vụ sau. Hoặc, server sẽ gửi một thông điệp tới tất cả các client đang mở file để client xoá file này khỏi cache và không cho caching file này. Phương thức Ý nghĩa
Write though Hoạt động và không làm thay đổi tốc độ ghi
Delayed write Có performance tốt hơn nhưng có khả năng gây nhầm lẫn Write on close Phù hợp với các phiên
Điều khiển tập trung
Khả năng mở rộng kém, thường dùng trong các hệ thống UNIX
Hình 1.24: Bốn giải thuật quản lí cache của client 1.5.6 Replication:
Các hệ thống phân tán thường cung cấp dịch vụ tạo bản sao của file cho các client, nghĩa là duy trì nhiều bản sao của một tập hợp của các file trong đó mỗi bản sao nằm trên một file server. Ý nghĩa của viêc duy trì các bản sao này là:
1. Làm tăng độ tin cậy, vì sẽ có nhiều bản sao của mỗi file độc lập nhau. 2. Nếu có một server bị hỏng sẽ không làm ảnh hưởng đến việc truy suất
file trong hệ thống.
3. Chia nhỏ tải trên nhiều server. Khi hệ thống mở rộng, việc có nhiều file trên một server có thể tạo nút cổ chai ở server đó, việc phân tán các bản sao của các file trên nhiều server sẽ giúp phân tải cho hệ thống.
Vấn đề quan trọng nhất của replication là tính trong suốt với người dùng, hình 1.25 mô tả 3 phương pháp thực hiện replication.
Hình 1.25: (a) Explicit file replication. (b) Lazy file replication. (c) File replication dùng group.
Cách thứ nhất như mô tả trong hình 1.25(a), người lập trình có thể điều khiển toàn bộ tiến trình. Khi tiến trình tạo một file, nó cũng tạo một file trên một server nào đó, sau đó tạo các bản sao của file này trên các server khác nếu cần. Địa chỉ mạng của các bản sao này có thể gắn với tên file như bảng dưới hình 1.25(a), do đó khi tìm theo tên file, sẽ tìm thấy tất cả các bản sao này. Khi file được mở sau đó, các bản sao có thể được mở tuần tự, cho tới khi chọn được bản sao thích hợp nhất.
Phương pháp thứ 2 là lazy replication, trong đó, chỉ tạo một bản sao của mỗi file trên một số server, sau đó server này sẽ tạo bản sao trên các server khác một cách tự động.
Phương pháp thứ 3 là phương pháp sử dụng truyền thông nhóm, như mô tả trong hình 1.25(c). Trong phương pháp này, tất cả các lời gọi ghi của hệ thống đều được tự động chuyển tới tất cả các server, do đó các bản sao của file được tạo ra ngay tại thời điểm toạ file gốc. Có 2 khác biệt cơ bản giữa phương pháp
thứ 2 và phương pháp thứ 3, đó là: thứ nhất, với phương pháp lazy replication, chỉ một server được xử lí chứ không phải cả nhóm; thứ hai, lazy replication thực hiện như một tiến trình nền khi server có thời gian rỗi, trong
khi phương pháp thông tin nhóm sẽ tạo các bản sao cùng một lúc với bản chính.
1.5.7 Các giao thức cập nhật:
Khi file bị thay đổi, nếu chỉ gửi đi một thông điệp cập nhật tới mỗi bản sao một cách tuần tự thì sẽ không tối ưu vì nếu tiến trình cập nhật bị lỗi trong khi đang cập nhật thì một số bản sao có thể đã bị thay đổi cũng như một số bản sao khác vẫn chưa cập nhật được. Kết quả là các thao đọc sau đó có thể lấy được các kết quả cũ trên một bản sao và lấy được các giá trị mới trên các bản sao đã được cập nhật. Để giải quyết vấn đề này, người ta đưa ra hai giải pháp.
Giải pháp thứ nhất gọi là primary copy replication, trong đó, một server được chỉ định là server chính, các server còn lại là server thứ cấp. Khi một file cần cập nhật, thông tin cập nhật sẽ được gửi tới server chính, làm cập nhật bản sao trên đó, sau đó nó sẽ gửi các lệnh tới các server thứ cấp để cập nhật bản sao trên các server này. Thao tác đọc có thể thực hiện trên bất kỳ bản sao nào, cả chính và thứ cấp. Để tránh trường hợp các bản sao không kịp cập nhật khi server chính bị lỗi, người ta thực hiện ghi các thông tin update lên một bộ nhớ ổn định để server chính có thể cập nhật sau khi hoạt động trở lại. Một phương pháp khác được Gifford đưa ra là voting, ý tưởng của phương pháp này là yêu cầu client gửi request để được sự cho phép của các server trước khi đọc hay ghi lên file đã sao. Giả sử có một file được sao trên N server, ta sẽ thiết lập một luật để khi cập nhật file, client phải liên hệ với một số lượng server nhất định (còn gọi là write quorum-NRrR) để được sự đồng ý cho cập nhật. Khi được đồng ý, file này sẽ được cập nhật và được cấp một số hiệu, số hiệu này được dùng để xác định phiên bản của file. Để đọc file, client phải liên hệ với một số lượng server nhất định (còn gọi là write quorum-NRwR ) để yêu cầu chúng gửi số hiệu file, khi đã thống nhất được số hiệu file thì sẽ được phép đọc file. Giá trị của NrRR và NRwR phải thoả mãn NRrR + NRwR> N (tổng số bản sao).
Ví dụ như trong hình 1.26(a) với NRrR=3 và NRwR=10. Giả sử các server đã cập nhật file là từ C đến L, nếu số lượng server mà client cần để thoả thuận là 3 thì có ít nhất một server đã cập nhật được số hiệu của file đó.
1.5.8 Các xu hướng phát triển của hệ thống file phân tán: 1.5.8.1 Phần cứng: 1.5.8.1 Phần cứng:
Công nghệ điện tử đang phát triển rất nhanh, dung lượng bộ nhớ chính có thể lên đến hàng trăm GB, các hệ thống file có thể nằm hoàn toàn trên bộ nhớ
chính, điều này sẽ làm tăng performance và đơn giản hoá cấu trúc của hệ thống file. Tuy nhiên với nhược điểm là bị mất dữ liệu khi nguồn điện cung cấp cho bộ nhớ chính bị mất, người ta vẫn đang chú ý phát triển các công nghệ lưu trữ ngoài, với dung lượng ngày càng tăng, lên đến hàng TB.
Bên cạnh đó, công nghệ mạng cũng phát triển rất nhanh với sự bùng nổ của các mạng quang. Như ta biết, mục đích của việc caching trên client là để tránh phải trao đổi dữ liệu qua mạng từ server đến client, nếu cơ sở hạ tầng mạng phát triển đến một mức nhất định chúng ta có thể không phải dùng cache trên client và disk của server, hệ thống có thể hoạt động dựa trên nền tảng mạng tốc độ cao và bộ nhớ chính của server, được backup bằng các thiết bị lưu trữ ngoài.
1.5.8.2 Khả năng mở rộng:
Khả năng mở rộng trong tương lai của các hệ thống phân tán là rất lớn, vì nó đã là sản phẩm mang tính thương mại, một hệ thống tính toán của một công ty đa quốc gia có thể trải rộng trên toàn thế giới.
1.5.8.3 Kết nối mạng diện rộng:
Khi các hệ thống phân tán trải rộng trên phạm vi vùng miền và thế giới thì công việc của các hệ thống phân tán không còn gói gọn trong các mạng LAN nữa mà sẽ được thực hiện trên các mạng diện rộng. Vấn đề đối với các hệ
thống phân tán không chỉ là phải thay đổi ứng dụng cho tương thích mà còn vì băng thông của các mạng diện rộng thường rất thấp, thấp hơn rất nhiều so với
mạng LAN. Chúng ta có thể phải phát triển các hệ thống file để phân biệt giữa thông tin chỉ đọc và cố định (chẳng hạn như danh sách điện thoại) và các thông tin động (chẳng hạn địa chỉ email).
1.5.8.4 Người dùng di động:
Với người dùng di động, khi được kết nối, người dùng sẽ tải về cache các file cần thiết để dùng khi ngắt kết nối khỏi mạng của hệ thống phân tán. Sau khi được kết nối lại, các thông tin trên cache sẽ được cập nhật. Vì thời gian ngắt kết nối thường kéo dài nên các vấn đề về toàn vẹn dữ liệu trong cache của các thiết bị cầm tay sẽ khó khăn hơn so với trong các hệ thống trực tuyến.
1.5.8.5 Khả năng chịu lỗi:
Trong các ứng dụng nhất định, các hệ thống thường được dự phòng phần cứng, thông tin sẽ được replication.
1.5.8.6 Multimedia:
Ngày càng có nhiều ứng dụng mới ra đời, đặc biệt là các ứng dụng kết hợp video thời gian thực hay multimedia với kích thước file rất lớn. Do đó cần các hệ thống file khác nhau để quản lí các file này.
1.6 Bộ nhớ chia sẻ phân tán:
Như ta biết, có hai loại hệ thống nhiều bộ xử lí: multiprocessor và multicomputer. Trong hệ thống multiprocessor, hai hoặc nhiều CPU cùng chia sẻ một bộ nhớ chính chung, còn trong hệ thống multicomputer, mỗi CPU có một bộ nhớ riêng, không chia sẻ.
Về mặt phần cứng, việc thiết kế một hệ thống đa bộ xử lí sử dụng chung bộ nhớ là rất khó, đối với hệ thống bus-based multiprocessor thì sẽ dẫn tới tình
switched multiprocessor thì việc mở rộng hệ thống trở nên tốn kém và khó duy trì hoạt động hơn. Ngược lại, các hệ thống multicomputer dễ xây dựng hơn.
Về mặt phần mềm, có rất nhiều phương pháp lập trình đa bộ xử lí. Để thông tin với nhau, một tiến trình chỉ phải ghi dữ liệu vào bộ nhớ, để các tiến trình khác đọc dữ liệu này trên bộ nhớ chia sẻ. Để đồng bộ, ta sử dụng các vùng tới hạn, với các semaphore hay các bộ giám sát để tạo cơ chế loại trừ lẫn nhau khi cần thiết. Với các hệ thống multicomputer thì ngược lại, để thông tin với nhau phải dùng cơ chế truyền thông điệp khá phức tạp về điều khiển luồng,
xử lí các thông điệp bị thất lạc, buffering và blocking. Một dạng trao đổi thông tin trong hệ thống multicomputer là RPC, sử dụng thư viện các thủ tục. Để sử dụng các dịch vụ từ xa, tiến trình phải gọi thủ tục phù hợp, đóng gói các mã lệnh và các thông số của thủ tục vào trong thông điệp, gửi vào mạng và chờ phản hồi. Tuy nhiên nó cũng có nhược điểm vì với các cấu trúc dữ liệu phức tạp chứa con trỏ, và các biến toàn cục, các array lớn thì rất khó để trao đổi qua các thông điệp. Như vậy các hệ thống kiểu multiprocessor sẽ thích hợp hơn.
Tóm lại, hệ thống multicomputer thì dễ xây dựng nhưng khó lập trình, còn hệ thống multiprocessor thì khó xây dựng nhưng dễ lập trình.
Ta sẽ xây dựng hệ thống đạt được ưu điểm của cả hai mô hình trên. 1.6.1 Giới thiệu:
Trong giai đoạn đầu của hệ thống tính toán phân tán, các chương trình chạy trên các máy khác nhau, không chia sẻ bộ nhớ, việc trao đổi giữa các máy được thực hiện qua cơ chế truyền thông điệp.
Có một phương pháp là không chia sẻ toàn bộ không gian địa chỉ mà chỉ chia sẻ một phần, chủ yếu là các biến và cấu trúc dữ liệu mà nhiều tiến trình cùng sử dụng. Giải pháp này sẽ làm giảm số lượng dữ liệu phải chia sẻ đồng thời ta
cũng biết được các thông tin cần thiết về dữ liệu được chia sẻ để tối ưu hoá việc triển khai.
Một phương pháp khác là tạo các bản sao các biến chia sẻ trên các máy khác
nhau. Thao tác đọc có thể được thực hiện một cách local còn thao tác ghi được thực hiện thông qua giao thức cập nhật nhiều bản ghi.
Không gian địa chỉ cần chia sẻ chủ yếu là các đối tượng và phương thức của đối tượng đó.
1.6.2 Bộ nhớ chia sẻ:
Ta sẽ xem xét các loại hệ thống shared memory multiprocessor từ loại đơn giản nhất là hoạt động trên một bus tới loại sử dụng cache là loại phức tạp nhất. Sở dĩ ta chỉ xem xét các hệ thống multiprocessor là vì các giải thuật của
hệ thống multiprocessor và multicomputer khá tương tự nhau khi cùng sử dụng bộ nhớ chia sẻ.
Hình 1.27: (a) single-chip computer, (b) đa xử lí chia sẻ bộ nhớ giả thiết. 1.6.2.1 On chip Memory:-
Trong mô hình này, CPU có các đường địa chỉ và dữ liệu nối trực tiếp đến bộ nhớ. Trong hình 1.27(a) là máy tính với mô hình CPU và bộ nhớ đơn giản, hình 1.27(b) là mô hình nhiều bộ xử lí cùng chia sẻ một bộ nhớ.
1.6.2.2 Bus based multiprocessors:-
Phương pháp đơn giản và hiệu quả nhất để xây dựng multiprocessor là tạo một bus để các CPU kết nối tới. Để tránh trường hợp có hai hay nhiều hơn CPU cùng truy suất vào bộ nhớ, người ta dùng một số phương pháp chia sẻ bus. Ví dụ, để được truy suất file, CPU phải gửi yêu cầu của nó vào một đường đặc biệt, khác với đường địa chỉ và đường dữ liệu, để được quyền sử dụng bus. Chức năng cấp quyền cho CPU có thể được thực hiện tập trung tại một thiết bị đặc biệt hoặc yêu cầu quyền này qua các CPU trên bus.