Hệ thống quản trị file (tệp) phân tán
Chia sẻ dữ liệu là 1 trong những chức năng cơ bản của hệ phân tán. Hệ thống file phân tán cho phép nhiều tiến trình cùng chia sẻ dữ liệu trong khoảng thời gian dài 1 cách an toàn và tin cậy. Tất cả 7 nguyên lý mà ta đã nói ở trên đều được áp dụng cho các hệ thống file phân tán.
Tóm tắt nội dung:
Trong phần này ta xem xét hệ thống file phân tán đóng vai trò như 1 mô thức cho các hệ phân tán. Ta sẽ giới thiệu 2 hệ thống file phân tán là Sun NFS (Network File System - Hệ thống file mạng) và Coda. Trong 2 hệ thồng đó, ta sẽ tập trung vào phân tích kỹ NFS.
Ta cũng sẽ xem xét ngắn gọn thêm về 3 hệ thống file khác.
Và cuối cùng là so sánh giữa các hệ thống file phân tán với nhau.
III.1/ Sun Network File System
Tên đầy đủ là Hệ thống file mạng của Sun Microsystem - thường được gọi tắt là NFS. NFS ban đầu được phát triển bởi Sun dành cho các máy trạm UNIX, tuy nhiên nó cũng có thể chạy tốt trên các hệ điều hành khác. Ý tưởng cơ bản của NFS là mỗi file server (máy chủ file) cung cấp 1 khung nhìn đã được chuẩn hóa về hệ thống file cục bộ của nó. Nói cách khác, bất kể hệ thống file cục bộ được thi hành như thế nào, thì mỗi NFS server (máy chủ hệ thống file mạng) hỗ trợ cùng mô hình. Mô hình này cùng với 1 giao thức truyền thông cho phép các client truy cập đến các file lưu trữ trên server. Hướng tiếp cận này cho phép 1 tập không thuần nhất các tiến trình, có khả năng chạy trên các máy và các hệ điều hành khác nhau, để cùng chia sẻ 1 hệ thống file chung.
Sơ lược lịch sử của NFS:
Phiên bản đầu tiên của NFS đã không được phát hành mà chỉ được lưu hành nội bộ trong Sun.
Phiên bản thứ 2 được kết hợp trong hệ điều hành SunOS 2.0 (1985).
Vài năm sau, phiên bản thứ 3 của NFS được phát hành (1994) rồi đến phiên bản 4.
III.1.1/ Tổng quan về NFS
a/ Kiến trúc của NFS
Trong mô hình Dịch vụ file từ xa (remote file service), các client truy cập 1 cách trong suốt đến hệ thống file được quản lý bởi 1 server ở xa. Vì thế, thông thường các client không biết chỗ thực sự của các file. Thay vào đó, chúng được cung cấp 1 giao diện đến hệ thống file, tương tự như giao diện của các hệ thống file cục bộ thông thường. Trong trường hợp riêng, client chỉ được cung cấp 1 giao diện chứa nhiều các thao tác file khác nhau, server chỉ có nhiệm vụ thực thi các thao tác file đó. Chính vì vậy mô hình này còn được gọi là Mô hình truy cập từ xa (remote access model). (H.1)
H.1. Mô hình truy cập từ xa
Trái lại, trong mô hình Upload / Download (tải lên / tải xuống) thì 1 client chỉ truy cập đến 1 file cục bộ sau khi đã tải nó xuống (download) từ server. Một khi client đã hoàn tất thao tác với file xong thì nó sẽ tải file lên (upload) lại server, để file đó có thể được các client khác sử dụng. Dịch vụ FTP của Internet dùng theo chính cách này. (H.2)
H.2. Mô hình upload/download
NFS dựa trên UNIX, tuy nhiên nó cũng có thể dùng cho nhiều hệ điều hành khác nhau. Với tất cả hệ thống UNIX hiện đại, nói chung NFS được thực thi theo kiến trúc phân tầng như sau (H.3)
H.3. Kiến trúc NFS cơ bản dành cho hệ thống UNIX
Một client truy cập đến hệ thống file sử dụng lời gọi hệ thống được cung cấp bởi hệ điều hành của nó. Tuy nhiên, giao diện hệ thống file UNIX cục bộ được thay bởi 1 giao diện đến Hệ thống file ảo (VFS). Các thao tác trên giao diện VFS hoặc được chuyển đến 1 hệ thống file cục bộ, hoặc được chuyển đến 1 thành phần riêng biệt gọi là NFS client, đảm trách việc điều khiển truy cập đến các file được lưu ở server từ xa. Trong NFS, tất cả client - server giao tiếp thông qua các RPC. NFS client thi hành các thao tác hệ thống file NFS khi các RPC đến server. Lưu ý rằng các thao tác được đưa ra bởi giao diện VFS có thể khác với các thao tác được đưa ra bởi NFS client. Như vậy ý tưởng chính của VFS là ẩn đi sự khác biệt giữa cáchệ thống file.
Ở bên server, chúng ta thấy tổ chức hoàn toàn tương tự. NFS server có nhiệm vụ xử lý các yêu cầu đến từ client.
Ta thấy, một lợi ích quan trọng của sơ đồ trên đó là sự độc lập của các hệ thống file cục bộ. Theo nguyên tắc thì nó sẽ không hề quan tâm dù hệ điều hành tại client hay server chạy 1 hệ thống file UNIX, 1 hệ thống file Windows 2000, hay thậm chí là 1 hệ thống file MS-DOS cũ. Chỉ có 1 điều quan trọng cần chú ý là các hệ thống file này phải tùy theo mô hình hệ thống file được đưa ra bởi NFS.
b/ Mô hình hệ thống file
Mô hình hệ thống file được đưa ra bởi NFS cũng giống như mô hình được đưa ra bởi hệ thống dựa trên UNIX. Các file sẽ được xem như dãy tuần tự các byte. Chúng được tổ chức phân cấp trong 1 đồ thị định danh, trong đó các nút biểu diễn các thư mục và các file. Để truy cập 1 file, client phải tìm tên của nó trong 1 dịch vụ định danh (naming service) và sẽ nhận được điều khiển file kết hợp (associated file handle). Ngoài ra mỗi file có 1 số các thuộc tính mà giá trị của chúng có thể được tìm và thay đổi. Ta xem xét chi tiết chúng ở phần sau.
Các thao tác với file của NFS phiên bản 3 và 4 :
Thao tác tạo mới (creat) được sử dụng để tạo ra 1 file, ở đây cũng sự khác biệt giữa NFS phiên bản 3 với phiên bản 4. Trong phiên bản 3, thao tác này được dùng để tạo ra các file chính quy (regular file), trong khi các file phi chính quy (non-regular file) lại được tạo ra bởi các thao tác riêng khác. Thao tác liên kết được dùng để tạo các liên kết cứng, còn symlink sẽ được dùng để tạo các liên kết biểu trưng (symbolic link). Mkdir để tạo các thư mục con. Đối với các file đặc biệt như các file thiết bị, các socket thì được tạo bởi thao tác mknod. Tuy nhiên, trong phiên bản 4 thì thao tác tạo mới lại được dùng để tạo ra 1 file phi chính quy, bao gồm cả các liên kết tượng trưng, các thư mục và các file đặc biệt. (H.4)
Thao tác Ph.bản 3 Ph.bản 4 Mô tả
Creat Có Không Tạo 1 file chính quy
Creat Không Có Tạo 1 file phi chính quy
Link Có Có Tạo 1 liên kết cứng đến 1 file
Symlink Có Không Tạo 1 liên kết tượng trưng đến 1 file
Mkdir Có Không Tạo 1 thư mục con trong thư mục đã cho
Mknod Có Không Tạo 1 file đặc biệt
Rename Có Có Đổi tên 1 file
Remove Có Có Xóa 1 file khỏi 1 hệ thống file
Rmdir Có Không Xóa 1 thư mục con rỗng khỏi 1 thư mục
Open Không Có Mở 1 file
Close Không Có Đóng 1 file
Lookup Có Có Tìm 1 file theo tên của nó
Readdir Có Có Đọc các mục trong 1 thư mục
Readlink Có Có Đọc tên đường dẫn lưu trong 1 liên kết biểu trưng
Getattr Có Có Lấy các giá trị thuộc tính của 1 file
Setattr Có Có Thiết lập1 hoặc nhiều giá trị thuộc tính của 1 file
Read Có Có Đọc dữ liệu chứ trong 1 file
Write Có Có Ghi dữ liệu vào 1 file
H.4. Danh sách các thao tác hệ thống file được hỗ trợ bởi NFS
Thao tác rename được dùng để thay đổi tên của 1 file đã có.
File sẽ bị xóa bởi thao tác remove. Trong phiên bản 4 thì thao tác này sẽ xóa bất kỳ loại file nào. Tuy nhiên ở trong phiên bản 3 thì rmdir sẽ xóa thư mục con. Một file được xóa bởi tên của nó, và khi đó số các liên kết cứng đến nó sẽ bị giảm đi 1. Nếu số các đường liên kết giảm xuống 0 thì file đó sẽ bị hủy đi.
Phiên bản 4 cho phép các client mở và xóa các file (chính quy). Để mở 1 file, client sẽ cung cấp tên file , cùng với các giá trị khác nhau cho các thuộc tính. Sau khi 1 file đã được mở thành công, client có thể truy cập file đó bằng điều khiển file (file handle) của nó. Điều khiển đó cũng được dùng để đóng file, bằng cách đó client có thể nói với server rằng nó không cần truy cập đến file nữa. server khi này đã có thể giải phóng trạng thái mà nó đã duy trì để cung cấp cho client truy cập đến file.
Thao tác lookup (tìm) được dùng để truy tìm 1 điều khiển file cho 1 tên đường dẫn cho trước.
Thao tác readlink (đọc liên kết) được dùng để đọc dữ liệu liên kết với 1 symbolic link.
Các file sẽ có các thuộc tính kèm theo. Các thuộc tính điển hình là: kiểu của file, độ dài file, định danh (identifier) của hệ thống file chứa file đó, và lần cuối cùng file được chỉnh sửa. Các thuộc tính của file có thể đọc hoặc thiết lập bằng cách sử dụng các thao tác getattr và setattr.
Cuối cùng là các thao tác đọc (read) dữ liệu từ 1 file, và ghi (write) dữ liệu vào 1 file. Với thao tác đọc file (đọc thẳng tới), client chỉ ra số lượng các byte và khoảng cách giữa các byte để đọc. client sẽ được trả về số các byte đã đọc được. Với thao tác ghi dữ liệu vào file, client phải chỉ rõ ra vị trí bắt đầu ghi ở trong file, số lượng các byte được ghi, và dữ liệu ghi.
III.1.2/ Truyền thông
Một điều quan trọng trong NFS đó là sự độc lập với hệ điều hành, kiến trúc mạng, và các giao thức vận chuyển. Ví dụ như, các client chạy trên hệ thống Windows vẫn có thể giao tiếp với 1 máy chủ file (file server) UNIX.
Trong NFS, tất cả truyền thông giữa client và server đều theo giao thức Open Network Computing RPC (ONC RPC). Nói chung thì ONC RPC hoàn toàn tương tự với các hệ thống RPC khác.
Mọi thao tác NFS đều có thể thi hành khi 1 thủ tục đơn từ xa gọi đến 1 file server. Ví dụ như, để đọc dữ liệu từ 1 file lần đầu tiên, trước hết 1 client thông thường phải dùng thao tác lookup để truy tìm điều khiển file, sau đó nó mới có thể gửi 1 yêu cầu đọc (H.5a).
Trong ví dụ này của ta, client kết hợp cả yêu cầu tìm và yêu cầu đọc vào trong 1 RPC đơn (H.5b). Trong trường hợp phiên bản 4, ta cũng cần phải thao tác mở file trước khi hành động đọc diễn ra. Sau khi điều khiển file được tìm thấy, sẽ chuyển sang mở file, và sau đó server mới tiếp tục với thao tác đọc. Như vậy ta có thể thấy, toàn bộ chỉ cần có 2 thông điệp phải trao đổi giữa client và server. Các thao tác sẽ được nhóm lại với nhau trong 1 thủ tục ghép (compound procedure). Nếu có lỗi thao tác dù bất kỳ lý do gì, thì không thao tác nào nữa trong thủ tục ghép được thực hiện, và kết quả cho đến lúc đó sẽ được trả về cho client. Ví dụ như, nếu thao tác truy tìm bị lỗi, thì việc mở file tiếp theo sẽ không được thực hiện nữa.
H.5. (a) Đọc dữ liệu từ 1 file trong NFS phiên bản 3. (b). Đọc dữ liệu sử dụng thủ tục ghép trong phiên bản 4.
III.1.3/ Stateless - Stateful
NFS là 1 hệ thống client - server truyền thống, mà trong đó các client gửi yêu cầu đến 1 file server (máy chủ file) để thực hiện các thao tác trên file. Một trong những điểm phân biệt khi só sánh với các hệ thống file phân tán khác, là việc các server có thể là stateless (tạm dịch là phi trạng thái). Nói cách khác, giao thức NFS không đòi hỏi các server duy trì bất kỳ trạng thái client nào. Ở NFS phiên bản 2 và 3 thì vẫn còn dùng cách tiếp cận này, tuy nhiên đến phiên bản 4 thì đã không dùng nữa. Lợi ích chính của cách tiếp cận này đó là đơn giản. Ví dụ, khi 1 stateless server bị sụp, thì về cơ bản ta không cần pha phục hồi (recovery phase) để đưa server trở lại trạng thái trước đó.
Ở phiên bản 4, hướng tiếp cận stateless đã bị bỏ đi dù rằng giao thức theo cách này cho phép server không cần phải duy trì nhiều thông tin trên các client của nó. Bên cạnh stateless ta còn có hướng tiếp cận stateful (tạm dịch là theo trạng thái). Một trong những lý do quan trọng để dùng stateful là do NFS phiên bản 4 có thể làm việc qua các mạng diện rộng (wide-area networks). Chính điều này đòi hỏi các client phải hiệu quả trong việc sử dụng các bộ nhớ đệm (cach). Từ đó cần phải có các giao thức nhất quán bộ đệm (cach consistency protocol). Ta còn có dịp bàn thêm về vấn đề này ở phần sau.
III.1.4/ Định danh
Cũng như bất kỳ hệ phân tán nào khác, việc định danh cũng đóng vai trò quan trọng trong NFS. Ý tưởng chính cho mô hình định danh NFS đó là cho các client truy cập trong suốt đầy đủ đến 1 hệ thống file từ xa được duy trì bởi 1 server. Sự trong suốt này có được bởi client có thể đặt (mount) 1 hệ thống file từ xa vào trong hệ thống file cục bộ của nó. (H.6).
Thay vì phải đặt (mount) toàn bộ cả hệ thống file sang, thì NFS cho phép các client chỉ cần đặt 1 phần của hệ thống file mà thôi (H.6). Một server được gọi là xuất (export) 1 thư mục đi khi nó làm cho thư mục đó cũng có ở bên client. Thư mục xuất đi đó có thể được đặt ở trong 1 không gian tên cục bộ của client.
Như thế, theo nguyên tắc thì người sử dụng không chia sẻ các không gian tên. Ta hãy xem lại (H.6), file có tên là /remote/vu/mbox tại client A lại có tên là /work/me/mbox tại client B. Bởi vậy, tên của file phụ thuộc vào việc các client tổ chức không gian tên của chúng như thế nào, và nơi đặt các thư mục được xuất sang. Nhưng bù lại, theo cách này thì việc chia sẻ các file sẽ trở nên khó khăn hơn. Ví dụ như, A không thể nói cho B biết tên mà A đã dùng để gán cho file, bởi tên của đó sẽ hoàn toàn khác khi nó nằm trong không gian tên của B. Tuy nhiên, cũng có vài cách để khắc phục vấn đề này. Cách thông dụng nhất đó là cung cấp cho mỗi client 1 không gian tên đã được chuẩn hóa. Ví dụ như, mỗi client đều dùng thư mục cục bộ chuẩn là /usr/bin để đặt 1 hệ thống file vào (trên các client khác cũng có hệ thống file đó).
H.6. Đặt (mounting) 1 phần hệ thống file từ xa trong NFS
Ở đây ta chú ý rằng, 1 NFS server cũng có thể đặt (mount) vào bản thân nó các thư mục được xuất sang bởi các server khác. Tuy nhiên, nó lại không được phép xuất các thư mục này sang cho các client của nó. Để giải quyết được việc này, ta hãy xem xét ví dụ sau (H.7).
Giả sử rằng server A có hệ thống file FSA , mà từ đó xuất đi thư mục /packages. Thư mục này chứa 1 thư mục con là /draw đóng vai trò như 1 điểm đặt (mount point) cho hệ thống file FSB, được xuất sang bởi server B và được đặt bởi A. Đến phiên server A cũng sẽ xuất /packages/draw sang cho các client của nó, và ta giả sử rằng client đặt /packages đó vào trong thư mục cục bộ /bin của nó (H.7).
H.7 .Việc đặt (mounting) các thư mục từ nhiều server trong NFS
Nếu việc phân giải tên bị lặp (như trong trường hợp NFS phiên bản 3), thì để phân giải tên /bin/draw/install, client sẽ liên hệ với server A khi nó đã phân giải cục bộ /bin và yêu cầu A trả về 1 điều khiển file cho thư mục /draw. Trong trường hợp đó, server A sẽ trả về 1 điều khiển file bao gồm 1 định danh cho server B, để chỉ có B có thể phân giải phần còn lại của tên đường dẫn, trường hợp này là /install. Như ta đã nói, loại phân giải tên này không được NFS hỗ trợ.
a/ Điều khiển file
Một điều khiển file là 1 tham chiếu đến 1 file trong hệ thống file. Nó không phụ thuộc vào tên của file mà nó tham chiếu đến. Một điều khiển file được tạo ra bởi server đang có hệ thống file trên đó, và là duy nhất đối với tất cả các hệ thống file được xuất đi bởi server. Điều khiển file được tạo ra khi file được tạo ra. Client không biết nội dung thực của điều khiển file. Điều khiển file dùng 32 byte trong NFS phiên bản 2, nhưng cũng có thể tùy biến độ dài lên đến 64 byte trong phiên bản 3 và 128 byte trong phiên bản 4.
Một điều khiển file được thực thi như 1 định danh thực sự cho 1 file trong hệ thống file. Điều này có nghĩa là chừng nào file còn tồn tại, thì nó sẽ chỉ có 1 điều khiển file. Một trong lợi ích của điều khiển file đó là làm tăng hiệu năng. Bởi một khi hầu hết các thao tác file chỉ đòi hỏi 1 điều khiển file thay vì tên của file, như vậy client có thể tránh phải lặp lại việc tìm tên file trước mỗi thao tác với file. Một lợi ích khác nữa là client có thể truy cập đến file ngay mà không phụ thuộc vào tên (tên hiện tại) của nó.
Vì 1 điều khiển file có thể được lưu trữ cục bộ tại 1 client, nên có 1 điểm quan trọng cần chú ý đó là 1 server không thể tái sử dụng lại 1 điều khiển file sau khi đã xóa file. Bởi nếu không, 1 client có thể bị lỗi khi truy cập đến file.
Để truy cập đến các file ở 1 hệ thống file ở xa, client sẽ cần phải cung cấp cho server 1 điều khiển file của thư mục, cùng với tên của file hoặc thư mục được phân giải. NFS phiên bản 3 giải quyết vấn đề này thông qua 1 giao thức đặt (mount protocol) riêng biệt. Sau khi đặt, client được đưa điều khiển file gốc (root file handle) của hệ thống file đã đặt, mà sau đó có thể dùng như 1 điểm bắt đầu cho việc truy tìm các tên file. Điều khiển file gốc có thể được sử dụng để tìm điều khiển file khác trong hệ thống file của server. Như vậy ta có thêm điểm lợi đó là không cần đến 1 giao thức đặt. Thay vào đó, việc đặt (mounting) này có thể được tích hợp vào trong giao thức chuẩn dành cho việc truy tìm file.
b/ Automounting
Như chúng ra đã nói ở trên, mô hình định danh NFS (NFS naming model) về cơ bản cung cấp cho người sử dụng không gian tên của họ. Việc chia sẻ trong mô hình này có thể sẽ khó khăn một khi người sử dụng đặt tên khác nhau cho cùng 1 file. Một trong những giải pháp cho vấn đề này đó là cung cấp cho mỗi người sử dụng 1 không gian tên cục bộ đã được chuẩn hóa, rồi sau đó mỗi client đều dùng thư mục cục bộ chuẩn đó để đặt hệ thống file vào.
Một vấn đề nữa với mô hình định danh NFS đó là phải quyết định xem khi nào thì 1 hệ thống file từ xa sẽ được đặt (mount) sang. Chúng ta hãy xem xét 1 hệ thống lớn với hàng ngàn người sử dụng. Giả sử rằng mỗi người sử dụng đều có 1 thư mục cục bộ /home được dùng để đặt các thư mục chủ (home directories) của người sử dụng khác sang. Ví dụ như thư mục chủ của Alice là /home/alice, mặc dù các file thực ra được lưu trữ trên 1 server ở xa. Thư mục này có thể được đặt (mounted) vào 1 cách tự động khi Alice vào máy tính của mình. Thêm vào đó, Alice cũng có thể truy cập đến các file công cộng (public file) của Bob bằng cách truy cập qua thư mục /home/bob của Bob. Như vậy, ta thấy một trong những lợi ích của hướng tiếp cận này đó là tòan bộ hệ thống sẽ trong suốt đối với Alice. Tuy nhiên cách tiếp cận này cũng có những nhược điểm của nó.
Việc đặt các hệ thống file từ xa trong NFS (thật ra là thư mục được xuất đi-exported directories), sẽ được điều khiển bởi 1 automounter, nó chạy như 1 tiến trình riêng biệt trên máy của client. Ta hãy xem xét 1 automounter đơn giản được thi hành như 1 server NFS cấp người sử dụng (user-level NFS server) trên hệ điều hành UNIX. Giả sử rằng, thư mục chủ của tất cả người sử dụng là đã có sẵn thông qua thư mục cục bộ /home, như ở trên ta đã mô tả. Khi 1 máy client khởi động, automounter sẽ bắt đầu với việc đặt thư mục này. Như vậy, hễ khi 1 chương trình cố gắng truy cập đến /home, nhân UNIX (UNIX kernel) sẽ thực hiện thao tác truy tìm (lookup) đến NFS client, ở trong trường hợp này, nó sẽ thực hiện việc yêu cầu đến automounter với vai trò như 1 NFS server (H.8).
Ví dụ, giả sử rằng Alice đăng nhập. Chương trình đăng nhập sẽ thử đọc thư mục /home/alice để tìm kiếm thông tin, chẳng hạn như các kịch bản đăng nhập (login script). Automounter vì thế sẽ nhận yêu cầu truy tìm thư mục con /home/alice. Trước tiên nó tạo 1 thư mục con /alice trong /home. Sau đó nó tìm xem NFS server nào xuất đi thư mục chủ (home directory) của Alice để rồi đặt thư mục đó trong /home/alice. Vấn đề ở đây là automounter phải được bao gồm luôn trong các thao tác file để đảm bảo tính trong suốt. Nếu 1 file được tham chiếu không có sẵn bởi hệ thống file tương ứng chưa được đặt sang, thì automounter cũng phải biết.
H.8. Một automounter đơn giản cho NFS
Cách tiếp cận trên cũng có nhược điểm của nó. Và 1 trong những giải pháp đơn giản đó là để automounter đặt các thư mục vào trong 1 thư mục con đặc biệt, và thiết lập 1 liên kết tượng trưng (symbolic link) đến mỗi thư mục được đã đặt. (H.9)
Trong ví dụ này, thư mục chủ (home directories) người sử dụng được đặt sang thành thư mục con của /tmp_mnt. Khi Alice đăng nhập, automounter đặt thư mục chủ của Alice trong /tmp_mnt/home/alice và tạo 1 liên kết biểu trưng /home/alice tham chiếu đến thư mục con đó.
H.9. Sử dụng các liên kết biểu trưng.
c/ Các thuộc tính của file
Một NFS file có 1 số các thuộc tính kết hợp. Trong phiên bản 4, tập các thuộc tính file được chia ra thành:
1 tập các thuộc tính bắt buộc (mandatory attributes) - mọi sự thực thi đều phải hỗ trợ.
1 tập các thuộc tính được đề nghị (recommended attributes) - nên được hỗ trợ là tốt nhất.
Và thêm 1 tập các thuộc tính được định danh (named attributes).
Các thuộc tính được định danh (named attributes) được mã hoá thành 1 mảng của các cặp (thuộc tính, giá trị), trong đó thuộc tính được biểu diến là 1 chuỗi (string) và giá trị của nó là 1 dãy các byte. Chúng được lưu trữ cùng với file (hoặc thư mục) và NFS sẽ cung cấp các thao tác để đọc và ghi các giá trị thuộc tính.
Có tổng cộng 12 thuộc tính file bắt buộc (H.10a).
Thuộc tính Mô tả
TYPE Kiểu của file (chính quy, thư mục, liên kết biểu trưng).
SIZE Độ dài của file tính bằng byte
CHANGE Cho client biết nếu có khi nào file bị thay đổi
FSID Định danh duy nhất của hệ thống file.
(a)
Thuộc tính Mô tả
ACL Một danh sách điều khiển truy cập được kết hợp với file.
FILEHANDLE Cung cấp điều khiển file.
FILEID Định danh duy nhất cho file.
FS-LOCATIONS Định vị trên mạng, nơi hệ thống file này có thể được tìm thấy
OWNER Tên (chuỗi/ký tự) của chủ sở hữu file.
TIME-ACCESS Thời điểm mà dữ liệu file được truy cập lần cuối.
TIME-MODIFY Thời điểm mà dữ liệu file được chỉnh sửa lần cuối.
TIME-CREAT Thời điểm mà dữ liệu file được tạo ra.
(b)
H.10. (a) Một số các thuộc tính file bắt buộc phổ biến trong NFS. (b) Một số các thuộc tính file được đề nghị phổ biến.
Các thuộc tính file được đề nghị phổ biến được liệt kê trong (H.10b). Phiên bản 4 NFS hiện tại có đến 43 thuộc tính được đề nghị.
III.1.5/ Đồng bộ hóa
Các file trong 1 hệ thống file phân tán được chia sẻ bởi nhiều client. Nếu việc chia sẻ không bao giờ xảy ra, thì quả thật như thế chẳng còn ý nghĩa của hệ thống file phân tán. Việc chia sẻ các file đòi hỏi cần phải có sự đồng bộ hóa. Sự đồng bộ hóa sẽ là khá đơn giản nếu các file được giữ trên 1 server trung tâm. Tuy nhiên khi ấy hiệu năng sẽ là 1 vấn đề. Bởi thế, các client thường được phép giữ 1 bản sao cục bộ của file trong khi chúng đang đọc và ghi nội dung file. Cách này tương tự với mô hình upload/download ở phần đầu ta đã nói (H.2).
a/ Ngữ nghĩa của việc chia sẻ file
Khi 2 hoặc nhiều hơn người sử dụng chia sẻ cùng 1 file, thì cần thiết phải định nghĩa ngữ nghĩa (semantics) của việc đọc và ghi 1 cách chính xác để tránh phiền toái. Để giải thích các ngữ nghĩa của việc chia sẻ file trong NFS, trước hết chúng ta hãy xem xét 1 vài vấn đề có liên quan đến việc chia sẻ file.
H.11. (a) Trên 1 vi xử lý đơn, khi 1 thao tác đọc theo sau 1 thao tác ghi, thì giá trị được trả về bởi đọc giá trị vừa được ghi. (b) Trong 1 hệ phân tán với bộ đệm, các giá trị cũ có thể được trả về.
Trong các hệ thống vi xử lý đơn cho phép các tiến trình chia sẻ file, chẳng hạn như UNIX, ngữ nghĩa (semantics) thường là khi 1 thao tác đọc theo sau 1 thao tác ghi, thao tác đọc trả về giá trị vừa lúc được khi (H.11). Tương tự như thế, khi 2 thao tác ghi xảy ra kế tiếp nhau, theo sau là 1 thao tác đọc, giá trị đọc là những giá trị được lưu bởi lần ghi cuối cùng. Trong thực tế, hệ thống sẽ bắt ép 1 thời gian tuyệt đối với tất cả các thao tác và luôn luôn trả về giá trị gần nhất. Ta gọi mô hình này là ngữ nghĩa UNIX (UNIX semantics). Trong 1 hệ phân tán, ngữ nghĩa UNIX có thể dễ dàng có được với điều kiện chỉ có 1 file server và các client không giữ các file. Tất cả các thao tác đọc và ghi đều đến trực tiếp file server, và file server sẽ xử lý chúng 1 cách tuần tự.
Tuy nhiên trong thực tế, hiệu năng của 1 hệ phân tán thường rất thấp nếu trong đó tất cả các yêu cầu file đều phải đi đến 1 server. Vấn đề này sẽ được giải quyết bằng cách cho phép các client duy trì các bản sao cục bộ của các file thường được dùng nhiều (heavily used files) ở trong bộ nhớ đệm riêng (cục bộ) của nó.
b/ Khoá file trong NFS
Trong NFS, việc khoá file được điều khiển bởi 1 giao thức riêng biệt, và được thực thi bởi 1 bộ quản lý khóa (lock manager). Tuy nhiên, vì nhiều lý do khác nhau, việc khóa file sử dụng giao thức khóa NFS không được phổ biến. Ở trong phiên bản 4, việc khóa file đã được tích hợp vào trong giao thức truy cập file NFS. Cách tiếp cận này làm mọi việc đơn giản hơn cho các client khi khóa file.
Tuy nhiên, việc khóa file trong 1 hệ thống file phân tán cũng phức tạp bởi các client và server có thể lỗi trong khi đó các khóa vẫn được giữ lại. Khi đó, việc khôi phục lại 1 cách thích hợp sẽ trở nên quan trọng để đảm bảo tính nhất quán của các file được chia sẻ.
Bây giờ ta hãy xem xét cụ thể việc khóa file trong NFS phiên bản 4. Khóa file trong phiên bản 4 này khá đơn giản, chỉ cần 4 thao tác có liên quan đến việc khóa file này (H.12)
Thao tác Mô tả
Lock Tạo ra 1 khóa cho 1 dãy các byte
Lockt Kiểm tra xem khóa xung đột được cấp hay không
Locku Xóa 1 khóa khỏi 1 dãy các byte
Renew Hồi phục (làm mới lại) thời gian cấp cho khóa
H.12. Các thao tác trong NFS phiến bản 4 liên quan đến khóa file.
Thao tác lock (khóa) được dùng để yêu cầu 1 khóa đọc (read lock) hoặc khóa ghi (write lock) trên 1 dãy liên tiếp các byte trong file.
Thao tác lockt được dùng để kiểm tra xem thử có khóa xung đột nào tồn tại hay không. Ví dụ như, 1 client có thể kiểm tra xem có khóa đọc nào đã được cấp trên 1 dãy các byte xác định ở trong file hay không, trước khi nó yêu cầu 1 khóa ghi cho các byte đó. Trong trường hợp xung đột, nó sẽ cho biết chính xác nguyên nhân của việc xung đột và cả dãy byte mà xung đột xảy ra trên đó nữa.
Để xoá 1 khóa khỏi 1 file ta dùng thao tác locku.
Các khóa đều được cấp cho 1 thời gian xác định (thời gian này được quyết định bởi server). Trừ phi 1 client hồi phục lại (làm mới lại - renew) khoảng thời gian đó trên các khóa đã được cấp, còn nếu không thì server sẽ tự động huỷ các khóa đó đi.
Bên cạnh các thao tác này, cũng còn có 1 cách nữa để khóa 1 file, đó là "chia sẻ chỗ đặt trước" (share reservation). Nó được dùng để thực thi NFS trên các hệ thống dựa trên Windows. Khi 1 client mở 1 file, nó sẽ xác định, chỉ ra kiểu truy cập mà nó yêu cầu (cụ thể là READ, WRITE hoặc BOTH), và kiểu truy cập mà server sẽ từ chối các client khác (NONE, READ, WRITE hoặc BOTH). Để biết chính xác điều gì sẽ xảy ra khi 1 client mới 1 file , mà file đó đã được mở thành công bởi 1 client khác, ta hãy xem (H.13) sau:
NONE READ WRITE BOTH
READ Thành công Lỗi Thành công Lỗi
WRITE Thành công Thành công Lỗi Lỗi
BOTH Thành công Lỗi Lỗi Lỗi
(a)
NONE READ WRITE BOTH
READ Thành công Lỗi Thành công Lỗi
WRITE Thành công Thành công Lỗi Lỗi
BOTH Thành công Lỗi Lỗi Lỗi
(b)
H.13. Kết quả của thao tác đọc với share reservation trong NFS.
III.1.6/ Lưu đệm (caching) và bản sao (replication)
Cũng như các hệ thống file phân tán khác, NFS sử dụng bộ đệm cho client để tăng hiệu năng. Thêm vào đó, nó cũng hỗ trợ việc tạo các bản sao của file.
a/ Lưu tạm cho client (client caching)
Trước đây, việc lưu tạm (caching) trong phiên bản 3 của NFS đã có nhiều nhược điểm, nó dẫn đến việc có nhiều cách thực hiện theo những chính sách khác nhau. Và hầu hết các cách đó đều không đảm bảo được tính nhất quán. Tuy nhiên, đến phiên bản 4, đã có 1 số thay đổi để đảm bảo tính nhất quán này. Mô hình lưu tạm (caching model) tổng quát của NFS như sau: (H.14)
H.14. Lưu tạm (đệm) ở bên phía client trong NFS
Mỗi client có thể có 1 bộ nhớ đệm (memory cach) để chứa dữ liệu trước đó đọc từ server. Ngoài ra, còn có thể có đệm đĩa (disk cach) được thêm vào để mở rộng bộ nhớ đệm, sử dụng chung các tham số nhất quán.
NFS phiên bản 4 sử dụng 2 cách cho việc lưu tạm (đệm) dữ liệu file - caching file data. Cách đơn giản nhất là khi 1 client mở 1 file và lưu tạm dữ liệu mà nó nhận được từ server nhờ vào thao tác đọc. Thao tác ghi cũng có thể được thực hiện trong bộ nhớ đệm. Khi client đóng file, NFS yêu cầu rằng, nếu có sự thay đổi nào đã được diễn ra, thì dữ liệu được lưu tạm đó phải được đẩy về lại server. Một khi 1 file đã được lưu tạm, thì client có thể giữ dữ liệu của nó trong bộ đệm thậm chí sau khi đóng file. NFS đòi hỏi rằng, bất kỳ khi nào client mở 1 file đã đóng trước đó (mà đã được lưu tạm), client phải ngay lập tức revalidate (tái hiệu lực) dữ liệu đã lưu tạm.
Thêm 1 điểm ta cần chú ý nữa là server có thể uỷ nhiệm (delegate) 1 số quyền của nó đến cho client một khi file đã được mở. Open delegation (uỷ nhiệm mở file) diễn ra khi máy client được phép xử lý cụ bộ các thao tác đóng và mở (file) từ các client khác ở trên cùng 1 máy. Thông thường thì server phải đảm nhiệm việc kiểm soát dù cho việc mở 1 file có thành công hay không. Với Open delegation, máy client đôi khi cũng được cho phép tự đưa ra các quyết định, tránh việc phải cần liên lạc với server.
Một hệ quả của việc uỷ nhiệm 1 file đến client, đó là server khi cần có thể gọi trả lại (recall) uỷ nhiệm, ví dụ như, khi 1 client khác ở trên 1 máy khác cần nhận quyền truy cập đến file. Server có thể gọi client -đang được uỷ nhiệm - để trả lại uỷ nhiệm (H.15). Một khi gọi lại theo cơ chế này thì đòi hỏi server phải lưu lại vết của các client mà nó đã uỷ nhiệm file đến.
H.15. Cơ chế gọi trả lại ủy nhiệm file trong NFS phiên bản 4.
Việc lưu trữ tạm điều khiển file và các thư mục cũng dùng cách tiếp cận giống như trên.
b/ Bản sao các server
NFS phiên bản 4 hỗ trợ không nhiều cho việc nhân bản file. Chỉ toàn bộ hệ thống file mới có thể được nhân bản (bao gồm các file, các thuộc tính, các thư mục, và các khối dữ liệu).
III.1.7/ Chịu lỗi
a/ Lỗi RPC
Vấn đề với cơ chế RPC khi được dùng bởi NFS đó là nó không đảm bảo tính tin cậy. Trên thực tế, các client và server RPC stub có thể được sinh ra dựa trên hoặc là giao thức vận chuyển hướng kết nối tin cậy như TCP, hoặc là giao thức vận chuyển phi kết nối không tin cậy như UDP.
Một trong những vấn đề chính nữa, đó là thiếu việc tìm ra các yêu cầu trùng lặp (duplicate request). Như vậy sẽ xảy ra trường hợp, khi 1 hồi đáp RPC bị mất và client truyền lại (retransmit) thành công yêu cầu gốc đến server, và kết quả là server sẽ phải thực hiện lại yêu cầu đó thêm lần nữa.
Những vấn đề trên được khắc phục bằng 1 bộ đệm các yêu cầu trùng lặp (duplicate-request cache) thực thi bởi server. Mỗi yêu cầu RPC từ client sẽ được mang theo 1 định danh giao tác (transaction identifier - XID) duy nhất ở phần header của nó, và nó sẽ được server lưu tạm khi nó đến server. Chỉ cần server không gửi hồi đáp, nó sẽ chỉ định yêu cầu RPC đang được thực hiện. Khi yêu cầu đã được xử lý xong, hồi đáp kết hợp (associated reply) của nó sẽ được lưu tạm lại, sau đó hồi đáp sẽ chính thức được gửi trả cho client.
Có 3 tình huống được đặt ra cần giải quyết ở đây:
Trong trường hợp thứ nhất (H.16a), client gửi đi 1 yêu cầu, và khởi động 1 bộ định thời. Nếu hết thời gian trước khi có hồi đáp, client sẽ truyền lại yêu cầu gốc đó với XID giống như cũ. Tuy nhiên, bên phía server, thì do server chưa hoàn tất xong yêu cầu ban đầu, vì thế nó sẽ từ chối yêu cầu mà client truyền lại.
Trường hợp 2, server có thể nhận 1 yêu cầu được truyền lại chỉ sau khi nó đã gửi đi hồi đáp cho client. Nếu thời điểm đến của yêu cầu được truyền lại đó gần sát với thời điểm mà serv7er gửi hồi đáp (H.16b), thì server sẽ kết luận rằng việc truyền lại với việc hồi đáp là đã bị chéo nhau, và vì thế server cũng lại từ chối yêu cầu truyền lại đó.
H.16. Ba tình huống của việc xử lý truyền lại. (a) Yêu cầu vẫn đang được thực hiện. (b) Hồi đáp vừa mới được trả về. (c) Hồi đáp đã gửi trước đó, nhưng bị lỗi.
Trong trường hợp thứ 3, hồi đáp bị mất và yêu cầu truyền lại sẽ được đáp ứng bằng cách gửi đến client các kết quả mà trước đây ta đã lưu tạm trong bộ đệm (H.16c). Ở đây ta chú ý rằng các kết quả của thao tác file vẫn luôn được duy trì trong bộ đệm.
b/ Khóa file khi có lỗi
Việc khóa file trong NFS phiên bản 3 được xử lý thông qua 1 server riêng biệt. Theo cách này, thì các vấn đề có liên quan đến chịu lỗi được xử lý bằng cách khóa server. Trong phiên bản 4, vấn đề được giải quyết tương đối đơn giản. Để khóa 1 file, client đưa ra 1 yêu cầu khóa đến server. Giả sử rằng khóa được cấp cho client, thì ta cũng có thể gặp rắc rối một khi client hoặc server bị sụp đổ.
Để giải quyết vấn đề client bị sụp, server đưa ra 1 lease (dành riêng) trên mọi khóa mà nó cấp cho client. Một khi lease hết hạn, server sẽ xóa khóa đi, bằng cách đó nó giải phóng các tài nguyên liên kết (tức các file). Để cho server khỏi xóa 1 khóa, client sẽ làm mới lại (hồi phục lại - renew) lease của nó trước khi bị hết hạn bằng thao tác renew. Tuy nhiên cũng có tình huống các khóa bị xóa đi, ngay cả khi client không bị sụp đổ. Việc xóa không đúng này có thể xảy ra nếu không thể đưa thao tác renew đến cho server, ví dụ do khi đó mạng tạm thời bị đứt chẳng hạn.
Khi 1 server bị sụp và sau đó được phục hồi, có thể nó sẽ mất thông tin trên các khóa mà nó đã cấp cho client. Trong phiên bản 4, người ta đưa thêm vào 1 grace period (tạm dịch là giai đoạn tạm hoãn) mà trong giai đoạn này client có thể khôi phục, cải tạo lại các khóa đã được cấp trước đó cho nó. Việc hồi phục khóa này không hề phụ thuộc vào việc hồi phục các dữ liệu bị mất khác. Trong suốt grace period, chỉ các yêu cầu khôi phục khóa nói chung mới được chấp nhận, còn các yêu cầu khóa thông thường khác sẽ bị từ chối cho đến chừng nào grace period kết thúc.
Như ta thấy ở trên, việc dùng các lease trên các khóa sẽ làm nảy sinh ra nhiều vấn đề liên quan đến tính ổn định của việc gửi thông điệp làm mới lease. Ví dụ như, nếu thông điệp này bị lỗi hoặc đến server trễ, thì lease vô tình sẽ bị hết hạn dù cho nó đã yêu cầu được làm mới lại. Trong cả 2 trường hợp này, server sẽ khắc phục bằng cách phải đưa ra 1 lease mới cho client, trước khi client sau tiếp tục dùng file.
c/ Uỷ quyền mở khi có lỗi
Uỷ quyền mở được đưa ra để giải quyết vấn đề 1 client hoặc server bị sụp
III.1.8/ An toàn - an ninh
Như ta đã nói ở trước, ý tưởng chính của NFS đó là 1 hệ thống file từ xa sẽ được hiện diện tại client như thể nó là 1 hệ thống file cục bộ của client. Cũng chính vì vậy mà an toàn an ninh trong NFS luôn được tập trung chính vào truyền thông giữa client và server. Truyền thông an toàn có nghĩa là có 1 kênh an toàn được thiết lập ở giữa server và client, như trong phần II.7.2 ta đã đề cập.
Thêm vào đó, để các RPC an toàn, thì cần thiết phải điều khiển các truy cập đến file, việc này được xử lý, điều khiển bởi các thuộc tính file điều khiển truy cập (access control file attributes) trong NFS. Một file server phụ trách việc xác minh các quyền truy cập của các client của nó, ta sẽ giải thích điều này ngay sau đây. Cùng với an toàn các RPC, kiến trúc an toàn an ninh NFS được giới thiệu trong (H.17)
H.17. Kiến trúc an toàn an ninh NFS
a/ RPC an toàn
Trong NFS phiên bản 4, thì chỉ có việc xác thực được quan tâm khi ta nói đến 1 RPC an toàn. Có 3 cách xác thực:
System authentication (xác thực hệ thống): là phương thức xác thực được sử dụng rộng rãi nhất. Xác thực hệ thống còn là phương thức xác thực dựa trên UNIX. Trong đó, các client đơn giản chỉ chuyền ID người dùng (user ID) và ID nhóm (group ID) của nó đến cho server, cùng với 1 danh sách các nhóm mà nó phải đòi hỏi là thành viên. Thông tin này được client gửi đi dưới hình thức có thể hiểu được của 1 văn bản đã được mã hoá (plaintext).
Secure NFS (NFS an toàn): phương thức xác thực này sử dụng trao đổi khóa Diffie - Hellman để thiết lập 1 khóa phiên (sesion key), nó được dùng trong các phiên bản NFS cũ. Cách xác thực này tốt hơn so với xác thực hệ thống, nhưng bù lại nó phức tạp hơn, do đó nó cũng ít được dùng hơn.
Và giao thức xác thực thứ 3 đó là Kerberos (phiên bản 4) mà ta đã từng đề cập đến trong phần II.7.5 trước đây.
Trong NFS phiên bản 4, an toàn an ninh cũng đã được nâng cao với việc hỗ trợ RPCSEC - GSS. RPCSEC-GSS là 1 bộ khung (framework) an toàn an ninh tổng quát, có thể hỗ trợ rất nhiều cơ chế an toàn an ninh cho việc thiết lập các kênh truyền an toàn. Không những hỗ trợ cho các hệ thống xác thực khác nhau, mà nó còn hỗ trợ cả việc tích hợp các thông điệp (message integrity) và sự cẩn mật (confidentiality), 2 đặc tính không được hỗ trợ trong các phiên bản NFS trước đây. RPCSEC-GSS được dựa trên 1 giao diện chuẩn cho các dịch vụ an toàn an ninh, có tên là GSS-API.
b/ Điều khiển truy cập
Uỷ quyền (authorization) trong NFS cũng tương tự với secure RPC (RPC an toàn): nó cung cấp các cơ chế, nhưng lại không chĩ rõ ra chính sách cụ thể nào. Việc điều khiển truy cập được hỗ trợ bởi thuộc tính file ACL (ACL file attribute). Thuộc tính này là 1 danh sách các mục (entry) điều khiển việc truy cập, trong đó mỗi mục chỉ ra các quyền truy cập cho 1 nhóm hoặc 1 người sử dụng xác định.
Thao tác Mô tả
Read_data Cho phép đọc dữ liệu chứa trong 1 file.
Write_data Cho phép chỉnh sửa dữ liệu của file.
Append_data Cho phép thêm dữ liệu vào file.
Execute Cho phép thực thi 1 file
List_directory Cho phép liệt kê nội dung của 1 thư mục.
Add_file Cho phép thêm 1 file mới vào thư mục
Add_subdirectory Cho phép tạo 1 thư mục con trong 1 thư mục
Delete Cho phép xóa 1 file
Delete_child Cho phép xóa 1 file hoặc thư mục trong 1 thư mục
Read_acl Cho phép đọc ACL (danh sách điều khiển truy cập)
Write_acl Cho phép ghi ACL
Read_attributes Khả năng để đọc các thuộc tính cơ bản khác của file.
Write_attributes Cho phép thay đổi các thuộc tính cơ bản khác của file.
Read_named_attrs Cho phép đọc các thuộc tính được định danh của file.
Write_owner Cho phép thay đổi chủ.
Write_named_attrs Cho phép ghi các thuộc tính được định danh của file.
Synchronize Cho phép truy cập cục bộ 1 file tại server với các thao tác đọc, ghi đồng bộ.
H.18. Phân loại các thao tác được nhận diện bởi NFS đối với việc điều khiển truy cập.
NFS phân biệt nhiều loại thao tác khác nhau. Ta chú ý đến thao tác Synchronize (đồng bộ hóa), thao tác này dùng để báo cho biết rằng, 1 tiến trình ở cũng chỗ với server có thể trực tiếp truy cập vào 1 file được hay không, bỏ qua giao thức NFS để từ đó có thể tăng hiệu năng. Mô hình NFS cho việc điều khiển truy cập có nhiều ngữ nghĩa hơn so với hầu hết các mô hình UNIX, bởi việc đòi hỏi NFS có thể liên tác với hệ thống Windows 2000.
Một điều khác nữa làm cho điều khiển truy cập file khác biệt so với các hệ thống file chẳng hạn như UNIX, đó là việc truy cập có thể được chỉ định cho những người sử dụng khác nhau và những nhóm khác nhau. Bởi theo truyền thống thì việc truy cập đến 1 file được chỉ định dành cho 1 người sử dụng (chủ sở hữu của file), 1 nhóm người sử dụng (chẳng hạn các thành viên của 1 nhóm dự án), và cho mọi người khác. NFS có nhiều loại người dùng và tiến trình khác nhau được trình bày trong bảng sau (H.19)
Kiểu người dùng Mô tả
Owner Chủ sở hữu file
Group Nhóm các người sử dụng có liên hệ với file.
Everyone Bất kỳ người sử dụng hoặc tiến trình nào.
Interactive Bất kỳ tiến trình nào đang truy cập file từ 1 trạm tương tác.
Network Bất kỳ tiến trình nào đang truy cập file qua mạng.
Dialup Bất kỳ tiến trình đang truy cập file thông qua kết nối dialup đến server.
Batch Bất kỳ tiến trình đang truy cập file như 1 phần của công việc theo khối.
Anonymous Những ai truy cập file mà không xác thực.
Authenticated Bất kỳ người sử dụng hoặc tiến trình đã được xác thực.
H.19. Các loại người dùng và tiến trình khác nhau được phân biệt bởi NFS đối với việc điều khiển truy cập.
III.2/ Hệ thống file Coda
Coda được phát triển tại trường Đại học Carnegie Mellon (CMU) vào những năm 1990, và bây giờ nó đã được tích hợp vào các hệ điều hành dựa trên UNIX phổ biến, chẳng hạn như Linux.
Coda là 1 hệ thống file phân tán có tính co dãn (về qui mô - scalable), có tính an toàn (secure), và có tính sẵn sàng cao (high available). Coda là hậu duệ của hệ thống file Andrew (AFS) phiên bản 2, cũng do CMU phát triển. Nó kết thừa nhiều điểm trong kiến trúc của AFS. Với AFS, nó có thể được thực thi với khoảng 10.000 máy trạm cần truy cập đến hệ thống. Để đáp ứng yêu cầu này, các nút AFS sẽ được chia thành 2 nhóm. Nhóm thứ nhất bao gồm 1 số tương đối ít các Vice file server, chúng sẽ được quản trị 1 cách tập trung. Nhóm còn lại bao gồm 1 lượng rất lớn các máy trạm Virtue , để đưa cho các người sử dụng và các tiến trình truy cập đến hệ thống file.
H.20. Tổ chức tổng thể của AFS
Coda cũng được tổ chức giống với AFS. Mọi máy trạm Virtue có 1 tiến trình cấp người dùng (user-level) thì được gọi là Venus, vai trò của nó tương tự như NFS client mà trước đây ta đã xét. Một tiến trình Venus có nhiệm vụ cung cấp truy cập đến các file được duy trì trên các Vice file server.
Không giống như NFS, Coda cung cấp 1 không gian tên chia sẻ tổng thể (globally shared name space) được duy trì bởi các Vice server. Các client truy cập đến không gian tên này bằng 1 thư mục con đặc biệt trong không gian tên cục bộ của chúng, chằng hạn như /afs. Mỗi khi 1 client truy tìm 1 tên trong thư mục con này, Venus đảm bảo rằng phần thích hợp của không gian tên chia sẻ được đặt (mount) sang client.
Truyền thông
Việc truyền thông giữa các tiến trình trong Coda được thực hiện bằng cách dùng các RPC. Tuy nhiên, hệ thống RPC2 dành cho Coda phức tạp hơn nhiều so với các hệ thống RPC truyền thống chẳng hạn như ONC RPC, được dùng bởi NFS.
RPC2 còn hỗ trợ các side effect (tạm gọi là hiệu ứng mặt). Một side effect là 1 cơ chế mà bằng cách đó client và server có thể truyền thông sử dụng 1 giao thức ứng dụng cụ thể (application-specific). Ví dụ, 1 client đang mở 1 file tại 1 video server. Điều cần thiết trong trường hợp này đó là thiết lập 1 luồng dữ liệu liên tục với chế độ truyền đẳng thời (như nhau về thời gian). Hay nói cách khác, dữ liệu truyền từ server đến client được đảm bảo nằm trong khoảng lớn nhất đến bé nhất thời gian trễ đầu cuối (end-to-end delay). RPC2 cho phép client và server thiết lập 1 kết nối riêng biệt để truyền dữ liệu video đến client kịp thời.
Một đặc điểm khác nữa mà RPC2 khác so với các hệ thống RPC còn lại, đó là nó hỗ trợ kỹ thuật multicasting.
Tiến trình
Với Coda thì có 1 sự khác biệt rõ ràng giữa các tiến trình client và tiến trình server. Tương ứng với client và server đó là các tiến trình Venus và Vice. Cả 2 kiểu tiến trình được tổ chức bên trong như 1 tập các luồng đồng thời (concurrent threads). Các luồng trong Coda không có sự ưu tiên và nó hoạt động trong toàn không gian người sử dụng.
Định danh
Coda duy trì 1 hệ thống tên tương tự như UNIX. Các file được nhóm lại vào trong những đơn vị gọi là volume. Một volume giống với 1 phân vùng đĩa UNIX (tức là 1 hệ thống file thực sự). Volume quan trọng bởi 2 lý do. Thứ nhất, chúng tạo ra đơn vị cơ bản được dùng để cấu trúc nên toàn bộ không gian tên. Lý do thứ 2 đó là chúng tạo ra đơn vị cho sao việc lặp bên phía server.
Có một điều quan trọng mà ta cần chú ý đó là khi 1 volume từ không gian tên chia sẻ được đặt vào trong không gian tên của client, Venus sẽ theo cấu trúc của không gian tên chia sẻ (shared name space). Cũng như vậy, các client được đảm bảo rằng các file chia sẻ quả thực có tên như nhau, dù việc phân giải tên lại dựa trên 1 thực thi cục bộ không gian tên. Như thế, ta thấy cách tiếp cận này khác cơ bản so với NFS.
Đồng bộ hóa.
Lưu tạm (caching) và nhân bản (replication).
Chịu lỗi.
III.3/ Các hệ thống file phân tán khác
Ngoài 2 hệ thống file mà ta nói ở trên, thì còn có 1 số các hệ thống file khác nữa. Tuy nhiên, hầu hết đều giống với NFS hoặc Coda. Ở đây ta xét đến 3 hệ thống file khác nữa, đó là Plan 9, XFS, và SFS.
Trong Plan 9 thì mọi tài nguyên đều được đối xử như 1 file. Còn XFS là 1 ví dụ điển hình của 1 hệ thống file không có server (serverless). Và cuối cùng là SFS, đó là 1 hệ thống file mà trong đó các tên file cũng chứa thông tin an toàn an ninh.
1. Plan 9 - Tài nguyên thống nhất với file
Trong Plan 9, tất cả các tài nguyên đều được truy cập theo cùng 1 cách, cụ thể đó là các thao tác và cú pháp giống file. Ý tưởng này được kế thừa từ UNIX, tuy nhiên nó tốt và nhất quan hơn ở trong Plan 9. Mỗi server đưa ra 1 không gian tên phân cấp đến các tài nguyên mà nó điều khiển. Một client có thể đặt vào cục bộ 1 không gian tên được đưa ra bởi server, như vậy việc xây dựng không gian tên riêng của chính nó tương tự với cách tiếp cận trong NFS. Để cho phép việc chia sẻ, các phần của không gian tên này cũng sẽ được chuẩn hóa.
H.21.Tổ chức tổng quát của Plan 9
Một hệ thống Plan 9 bao gồm 1 tập các server để cung cấp tài nguyên cho các client dưới dạng không gian tên cục bộ. Để truy cập đến các tài nguyên của 1 server, client đặt không gian tên của server vào trong không gian tên của chính nó. Ở đây ta chú ý rằng, trong Plan 9 sự khác biệt giữa client và server không thực sự quá rõ ràng. Ví dụ như, các server thường hành động như các client, trong khi các client lại cũng có thể xuất tài nguyên của chúng sang cho server. Tổ chức của Plan 9 được trình bày trong (H.21)
2. XFS - hệ thống file không có server (serverless)
xFS được phát triển như 1 phần của dự án Berkeley NOW. Ở đây ta cần chú ý là có 1 hệ thống file phân tán khác hoàn toàn khác được gọi là XFS ("X" viết hoa) được phát triển cùng thời điểm với xFS. Sau này, ta dùng "xFS" và "XFS" để chỉ nói đến hệ thống được phát triển là 1 phần hệ thống của dự án NOW.
Việc thiết kế mà không có server của XFS là 1 điều khá lạ. Toàn bộ hệ thống file được phân tán qua nhiều máy, bao gồm các client. Hướng tiếp cận này trái ngược với các hệ thống file khác, thông thường được tổ chức theo kiểu tập trung, thậm chí còn có nhiều server dùng cho việc phân tán và tạo bản sao các file.
XFS được thiết kế để hoạt động trên mạng cục bộ, trong đó các máy được kết nối với nhau thông qua các đường liên kết tốc độ cao. XFS được thiết kế với mục đích đạt độ co dãn cao (tức thay đổi về quy mô - scalability) và cả tính chịu lỗi cao.
Trong kiến trúc của XFS, có 3 loại tiến trình khác nhau:
Storage server (lưu trữ server): là tiến trình có nhiệm vụ lưu trữ các phần của 1 file. Chúng thực thi 1 dãy (array) các đĩa ảo tương tự như việc thực thi của các dãy đĩa dưới dạng RAID.
Metadata manager (quản lý siêu dữ liệu): là tiến trình có nhiệm vụ lưu lại vết, nơi 1 khối dữ liệu file thật sự được lưu
Client: là 1 tiến trình chấp nhận các yêu cầu của người sử dụng để thao tác trên file.
Môt nguyên lý thiết kế cơ bản của XFS đó là bất kỳ máy nào cũng có thể đóng vai trò của client, manager, server. Trong 1 hệ thống đối xứng hoàn toàn, mỗi máy sẽ có cả 3 tiến trình trên chạy. Tuy nhiên, cũng có thể sử dụng các máy dành để chạy các tiến trình storage server, trong khi máy khác lại chỉ chạy tiến trình client hoặc tiến trình manager (H.22)
H.22. Phân tán các tiên trình của XFS qua nhiều máy.
3. SFS - an toàn an nình có thể thay đổi, co dãn (scalable security)
Trong Hệ thống file an toàn (Secure File System - SFS), nguyên lý thiết kế chính đó là tách riêng ra việc quản lý của các khoá với an toàn an ninh hệ thống file. Hay nói cách khác, SFS đảm bảo rằng các client không thể truy cập 1 file mà không sở hữu 1 khoá bí mật thích hợp.
Tổ chức tổng thể của SFS được trình bày trong (H.23). Để đảm bảo tính di chuyển được qua nhiều máy, SFS đã tích hợp nhiều thành phần NFS phiên bản 3 khác nhau. Trên máy client, có cả thảy 3 thành phần, không tính đến chương trình của người sử dụng. NFS client được sử dụng như 1 giao diện đến các chương trình người sử dụng, và trao đổi thông tin với SFS client. SFS client có nhiệm vụ thiết lập 1 kênh an toàn với SFS server. Nó cũng có nhiệm vụ giao tiếp với tác tử người dùng SFS (SFS user agent), đó là 1 chương trình tự động xử lý xác thực người sử dụng.
H.23. Tổ chức của SFS.
Ở bên phía server cũng có 3 thành phần. Các NFS server giao tiếp với SFS server, thao tác như 1 NFS client đến NFS server. SFS server sẽ tạo tiến trình nhân (core process) của SFS. Tiến trình này có nhiệm vụ xử lý các yêu cầu file từ các SFS client.
III.4/ So sánh giữa các hệ thống file phân tán
1. Triết lý của hệ thống
Mục tiêu của các hệ thống file khác nhau thì thường cũng khác nhau.
Như NFS, thì mục đích của nó là cung cấp 1 hệ thống cho phép client truy cập trong suốt đến 1 hệ thống file được lưu tại 1 server từ xa xác định.
Với Coda thì khác, mục tiêu của nó là tính sẵn sàng cao (high available). Coda thừa kế mục đích thiết kế của AFS, trong đó một điều quan trọng đó là tính co dãn (scalability). Việc kết hợp tính sẵn sàng cao với tính co dãn giúp phân biệt Coda với hầu hết các hệ thống file phân tán khác.
Mục đích chính của Plan 9 là cung cấp 1 hệ thống chia sẻ thời gian (timesharing) phân tán, trong đó tất cả các tài nguyên được truy cập theo cách như nhau, mà cụ thể là như 1 file.
Với XFS thì mục đích của nó cũng khá giống với các hệ thống file phân tán khác, đó là tính sẵn sàng cao và tính co dãn. Tuy nhiên, điều quan trọng là đạt được mục tiêu này bằng 1 hệ thống mà không có server (serverlesss).
Mục tiêu của SFS lại là an toàn an ninh có thay đổi, co dãn (scalable security). Nó thực hiện mục tiêu này bằng cách chia tách việc quản lý với an toàn an ninh hệ thống file và cho phép người dùng bắt đầu dịch vụ SFS (SFS service) của họ mà không có sự can thiệp từ 1 authority (quyền) ở trung tâm.
2. Truyền thông
Khi so sánh về truyền thông, thì hầu hết các hệ thống file phân tán đều dựa trên các dạng của RPCs.
Với NFS, Coda và SFS thì đều sử dụng trực tiếp 1 hệ thống RPC cơ sở (underlying RPC system), đôi khi được tối ưu thêm để xử lý các trường hợp đặc biệt.
Plan 9 cũng sử dụng 1 hệ thống RPC, nhưng trên thực tế giao thức đã được biến đổi đi để đáp ứng các thao tác file của nó, điều này làm cho nó khác đôi chút so với các giao thức còn lại.
XFS cũng bắt đầu với 1 hệ thống RPC để xử lý, điều khiển tất cả các truyền thông. Tuy nhiên bởi lý do hiệu năng và một số lý do khác nữa trong XFS, mà hệ thống RPC đã được thay thế bằng các active messages.
3. Tiến trình
Các hệ thống khác ở nhau cách mà client đóng vai trò đối với toàn hệ thống file.
Với việc dùng cách tổ chức client-server, trong NFS phiên bản 3, hầu hết các công việc thực sự chỉ được làm bởi file server, trong khi đó 1 NFS client chỉ đơn thuần yêu cầu các thao tác để được server tiến hành. Đối với NFS phiên bản 4 thì các client đã được cho phép lưu tạm các file và xử lý các thao tác 1 cách cục bộ.
Với AFS và Coda ở phía client ta sẽ có tiến trình Venus, đảm nhiệm 1 lượng lớn công việc ở bên phía client.
Ngược lại, các nhà phát triển Plan 9 lại cố gắng làm sao để giữ cho các client đơn giản đến mức có thể. Tuy nhiên 1 tiến trình client cũng được cho phép lưu tạm (caching) các file, nhưng hệ thống vẫn làm việc tốt nếu các bộ đệm không được dùng gì cả.
Các server cũng rất khác nhau khi so sánh giữa các hệ thống.
4. Định danh
Có 2 hướng tiếp cận căn bản trong việc tổ chức không gian tên. Hướng thứ nhất đó là mỗi người sử dụng lấy không gian tên riêng của chính họ. Cách này được dùng trong NFS và Plan 9. Nhược điểm của không gian tên trên mỗi người dùng như thế này, đó là khó chia sẻ các file dựa trên tên của nó. Và để giảm bớt nhược điểm này, các phần của không gian tên sẽ được chuẩn hóa.
Hướng tiếp cận thứ 2 đó là cung cấp 1 không gian tên chia sẻ tổng thể, được dùng trong Coda, xFS và SFS. Trong tất cả các hệ thống này, mỗi người sử dụng cũng có khả năng gia thêm vào không gian tên tổng thể 1 không gian tên cục bộ riêng. Ví dụ, SFS client sẽ cho phép 1 người sử dụng tạo cục bộ các liên kết biểu trưng (symbolic link). Các tên này là riêng tư với người dùng, và sẽ không thể thấy với người dùng ở các SFS client khác.
Ngoài ra, cũng có nhiều điểm khác nhau đối với tham chiếu file giữa các hệ thống file phân tán.
5. Đồng bộ hóa
NFS cung cấp các ngữ nghĩa phiên (session semantics), điều này có nghĩa chỉ các cập nhật của tiến trình cuối đóng file là được nhớ bởi server.
Trong Coda, các ngữ nghĩa giao tác (transactional semantics) được hỗ trợ theo hướng, chỉ các phiên được cho phép này mới có thể được tuần tự hóa. Tuy nhiên, trong thao tác bị ngắt kết nối, các ngữ nghĩa đó có thể không được đảm bảo, bởi thế dẫn đến cập nhật các xung đột cần được giải quyết sau này.
Bởi các thao tác trên file trong Plan 9 cơ bản được xử lý bởi file server, nên Plan 9 cung cấp các ngữ nghĩa UNIX. Các ngữ nghĩa này cũng được cung cấp bởi xFS.
6. Lưu tạm (caching) và nhân bản (replication)
Tất cả các hệ thống mà ta đã xét đều hỗ trợ việc lưu tạm bên phía client. Chỉ có Plan 9 là mọi các thao tác ghi được chuyển tức thì đến server. Các hệ thống khác đều thực thi các đệm ghi lại (write-back caches), cho phép 1 client thực hiện 1 loạt các thao tác ghi trên dữ liệu được lưu tạm trước khi đẩy thẳng vào bộ đệm.
Các hệ thống file phân tán này cũng hỗ trợ việc sao lặp file bởi server.
7. Chịu lỗi
Đối với Coda, nó dùng đệm để lưu tạm và các bản sao của nó để có thể đạt được tính sẵn sàng cao (high available).
Còn trong xFS, kỹ thuật striping được dùng để bảo vệ server đơn khỏi bị sụp đổ.
Việc hồi phục dựa trên client được dùng trong NFS. Theo cách này, 1 server đã bị mất thông tin khi nó bị sụp đổ, thì các client được phép khôi phục lại các tài nguyên như các khóa chẳng hạn.
XFS thì sử dụng các điểm kiểm tra (checkpoint), và các client ghi lại nhật ký (log) để phục vụ việc phục hồi đến điểm mà dữ liệu của manager (bộ quản lý ) nhất quán với thông tin được lưu trong nhật ký.
8. An toàn an ninh
NFS phiên bản 4 tách biệt giữa cơ chế an toàn an ninh với việc thực thi các cơ chế này. Để thực thi các kênh an toàn, NFS cung cấp 1 giao diện chuẩn ở dạng RPCSEC-GSS, bằng cách đó các hệ thống an toàn an ninh đang tồn tại có thể được truy cập. NFS phiên bản 4 còn cung cấp 1 danh sách mở rộng các thao tác được dùng cho điều khiển truy cập (ACL).
Coda và Plan 9 cũng cung cấp các kênh truyền an toàn, nhưng cả 2 đều thực thi dựa trên giao thức xác thực Needham - Schroeder. Các khóa mật chia sẻ được dùng trong cách tiếp cận này. Coda cũng có cách khác với NFS trong việc điều khiển truy cập. Nó chỉ xử lý điều khiển truy cập đối với các thao tác trên thư mục. Với Plan 9 (và cả xFS) thì chủ yếu theo hướng tiếp cận UNIX chuẩn, bằng cách phân biệt các thao tác đọc, ghi, và thực thi.
SFS có cách riêng của nó để cung cấp các kênh an toàn. Nó dựa vào cơ chế xác thực server với người sử dụng, có thể dùng thêm các tác tử đặc biệt. SFS kế thừa các cơ chế điều khiển truy cập từ NFS phiên bản 3.
Bảng (H.24) giúp tổng hợp lại sự so sánh giữa 5 hệ thống file phân tán.
NFS Coda Plan 9 xFS SFS
Mục tiêu thiết kế Truy cập trong suốt Tính sẵn sàng cao Tính như nhau Hệ thống không server An toàn an ninh thay đổi
Mô hình truy cập Từ xa Up/Download Từ xa Log-based Từ xa
Truyền thông RPC RPC Đặc biệt Thông điệp linh động RPC
Tiến trình client Thin/Fat Fat Thin Fat Vừa
Các nhóm server Không Có Không Có Không
Không gian tên Mỗi client Toàn cục Mỗi tiến trình Toàn cục Toàn cục
Phạm vi ID file File server Toàn cục Server Toàn cục Hệ thống file
Ngữ nghĩa chia sẻ Phiên Giao tác UNIX UNIX Không được chỉ ra
Đơn vị lưu tạm (đệm) File (v4) File File Khối Không được chỉ ra
Nhân bản Tối thiểu ROWA Không Striping Không
Chịu lỗi Truyền thông tin cậy Nhân bản và lưu tạm Truyền thông tin cậy Striping Truyền thông tin cậy
Hồi phục Dựa vào client Khôi phục Không được chỉ ra Điểm kiểm tra và ghi nhật ký Không được chỉ ra
Các kênh an toàn Các cơ chế đang tồn tại Needham -Schroeder Needham - Schroeder Không đường dẫn tên Tự chứng nhận
Điều khiển truy cập Nhiều thao tác Các thao tác thư mục Dựa trên UNIX Dựa trên UNIX Dựa trên NFS
IV/ Kết luận
Hệ phân tán là 1 hệ thống có chức năng và dữ liệu phân tán trên các trạm (máy tính) được kết nối với nhau qua 1 mạng máy tính. Việc thiết kế 1 hệ phân tán phải tuân theo 7 nguyên lý mà ta đã đề cập đến ở phần đầu.
Trong việc xây dựng các hệ phân tán, thì 1 trong những mô thức quan trọng của nó đó là các hệ thống file phân tán. Như ta biết, chia sẻ dữ liệu là 1 trong những chức năng cơ bản của hệ phân tán. Hệ thống file phân tán cho phép nhiều tiến trình cùng chia sẻ dữ liệu trong khoảng thời gian dài 1 cách an toàn và tin cậy. Ở trên ta cũng đã xem xét 1 số các hệ thống file khá phổ biến như: NFS, Coda, Plan 9, xFS, SFS. Khi phân tích các hệ thống này, giúp ta hiểu sâu hơn về các nguyên lý của 1 hệ phân tán nói chung.
Bạn đang đọc truyện trên: Truyen2U.Pro