Đồ án Hệ thống file phân tán Coda

. Có hai loại hệ thống mật mã: mật mã đối xứng (symmetric cryptosystem) và mật mã bất đối xứng (asymmetric cryptosystem). Mật mã đối xứng: dùng khóa bí mật.. Với mật mã đối xứng: khóa mã hóa và khóa giải mã là giống nhau. Mật mã bất đối xứng: dùng khóa công khai. Mật mã bất đối xứng: khóa mã hóa và khóa giải mã là khác nhau. Ta có: 8.2 Kênh an toàn (Secure channels) 8.2.1 Xác thực (Authentication) a. Xác thực dựa trên khóa bí mật. Nguyên lý chung: bên gửi muốn giao tiếp với bên nhận sẽ gửi một yêu cầu A tới bên nhận. Bên nhận trả lời bằng một yêu cầu RB . Bên gửi sẽ mã hóa yêu cầu RB bằng khóa bí mật KA,B và gửi về cho bên nhận. Bên nhận xác thực được bên gửi nhờ nhận biết được yêu cầu RB mình đã gửi trong gói tin vừa nhận. Lúc này bên gửi muốn xác thực bên nhận sẽ tiếp tục gửi yêu cầu RA tới bên nhận. Bên nhận sẽ lại mã hóa RA bằng khóa bí mật KA,B đó và gửi về cho bên nhận. Và như thế bên nhận đã xác định được bên gửi, sau đó quá trình trao đổi sẽ được thực hiện. Hình 26 Xác thực dựa trên khóa bí mật Một mô hình cải tiến hơn là thu gọn số lượng bản tin chỉ còn lại 3 bản tin giữa bên nhận và bên gửi. b. Xác thực dựa trên trung tâm phân phối khóa Nếu hệ thống gồm N host, mỗi host phải chia sẻ một khóa mật với N-1 host khác thì hệ thống cần quản lý N.(N-1)/2 khóa, và mỗi host phải quản lý N-1 khóa. Như vậy nếu N lớn sẽ rất khó khăn trong việc quản lý. Do đó, để khắc phục hiện tượng trên ta sử dụng trung tâm phân phối khóa KDC (Key Distribution Center). Tư tưởng chính: bên gửi sẽ gửi bản tin tới trung tâm phân phối khóa thông báo mình muốn giao tiếp với bên nhận. KDC sẽ gửi cho cả bên gửi và bên nhận một bản tin có chứa khóa bí mật KA,B . Bản tin gửi cho bên nhận sẽ được mã hóa bằng KA,KDC . Bản tin gửi cho bên gửi sẽ được mã hóa bằng KB,KDC . Cách tiếp cận thứ hai là KDC sẽ gửi cả hai bản tin chứa khóa bí mật KA,KDC (KA,B ) và KB,KDC (KA,B ) cho bên gửi và bên gửi có nhiệm vụ gửi cho bên nhận khóa đã được KDC mã hóa KB,KDC (KA,B ) đó. c. Xác thực dựa trên khóa công khai. Hình 27. Xác thực dựa trên khóa công khai. Bên gửi mã hóa yêu cầu bằng khóa công khai K+B của bên nhận. Bên nhận này là nơi duy nhất có thể giải mã bản tin đó bằng K-B. Bên nhận sẽ mã hóa yêu cầu của bên gửi cùng với yêu cầu của chính mình và khóa KA,B vừa tạo ra bằng khóa công khai K+A của bên gửi nhằm xác thực bên gửi. Cuối cùng, bên gửi sẽ gửi lại cho bên nhận yêu cầu RB của bên nhận đã gửi đi để xác thực. 8.2.2 Tính toàn vẹn và tính mật của thông điệp. a. Chữ kí số Chữ kí số để đảm bảo tính toàn vẹn của thông điệp.Có nhiều cách thiết lập chữ kí số cho thông điệp: Cách 1: dùng hệ mật mã khóa công khai là RSA. Cách 2: dùng hàm băm. b. Khóa phiên Trong một kênh trao đổi an toàn, sau pha xác thực sẽ tiến hành truyền thông. Mỗi kênh truyền thông đó được xác định bởi một khóa phiên tương ứng. Khi phiên truyền kết thúc thì khóa phiên tương ứng cũng bị hủy bỏ. 8.2.3 Truyền thông nhóm an toàn a. Truyền thông nhóm bí mật Mô hình đơn giản là tất cả các thành viên trong nhóm sẽ cùng có một khóa bí mật để mã hóa và giải mã các bản tin. Điều kiện tiên quyết cho mô hình này là phải đảm bảo rằng tất cả các thành viên trong nhóm phỉa giữ bia mật khóa đó. Mô hình thứ hai là dùng một khóa bí mật cho từng cặp thành viên trong nhóm. Khi một trong hai thành viên kết thúc phiên truyền thì thành viên còn lại vẫn sẽ dùng khóa đó để giao tiếp với thành viên khác trong nhóm. Với mô hình này phải duy trì tới N (N-1)/2 khóa. Mô hình thứ ba là dùng khóa công khai. Mỗi một thành viên trong nhóm sẽ phải duy trì một cặp khóa công khai và khóa riêng, trong đó khóa công khai được dùng bởi tất cả thành viên trong nhóm. b. Server nhân bản an toàn Việc nhân bản các server thường dùng trong việc chịu lỗi cho hệ phân tán nhưng đôi khi cũng được dùng để đảm bảo tính tin cậy cho hệ thống. 8.3 Kiểm soát truy nhập (Access Control) 8.3.1 Các khía cạnh tổng quát trong kiểm soát truy cập a. Ma trận kiểm soát truy cập (Access Control Matrix) Trong ma trận điều khiển truy cập, một hàng biểu diễn cho một chủ thể (subject), một cột biểu diễn cho một đối tượng (object). Gọi ma trận kiểm soát truy nhập là M. M[s,o]: đưa ra danh sách các phép toán mà chủ thể s có thể yêu cầu trên đối tượng o. Khi một chủ thể s gọi một phương thức m của đối tượng o thì monitor sẽ kiểm tra trong danh sách M[s,o], nếu m không có trong danh sách này thì lời triệu gọi bị hủy bỏ. b. Danh sách kiểm soát truy cập (Access Control List) Mỗi một đối tượng sẽ duy trì một danh sách các truy cập hợp lệ của các chủ thể muốn truy cập nó gọi là ACL nhờ đó tránh được sự tồn tại của các entry rỗng như ở ma trận kiểm soát truy nhập. c. Miền bảo vệ (Protection Domains) Với việc sử dụng ACL, tuy đã khắc phục được nhược điểm của ma trận kiểm soát truy nhập nhưng vẫn có kích thước lớn nên đã đưa ra cách sử dụng miền bảo vệ. Miền bảo vệ là một tập các cặp (đối tượng, truy cập hợp lệ), mỗi cặp này sẽ cho ta một đối tượng và các thao tác hợp lệ trên nó. Mỗi một yêu cầu đều thuộc một miền bảo vệ nào đó. Khi một yêu cầu gửi đến, monitor sẽ tìm trong miền bảo vệ tương ứng yêu cầu này. 8.3.2 Tường lửa (Firewall) Firewall dùng để ngăn chặn các luồng không được phép. 8.4 Quản trị an toàn – an ninh (Security management ) 8.4.1 Quản trị khóa a. Thiết lập khóa Việc tạo ra khóa bí mật giữa bên truyền và bên nhận được thực hiện như sau: Bên A và bên B đều tạo ra hai số lớn là n và g - hai số này có thể được công khai. Bên A sẽ tạo ra một số lớn khác là x, bên B tạo ra số lớn y và giữ bí mật chúng. Bên A sẽ gửi cho bên B: n, g và (gx mod n). Bên B sẽ thực hiện tính (gx mod n)y= gxy mod n. do đó sẽ xác định được khóa bí mật x của bên A. Đồng thời, bên B cũng gửi cho bên A (gy mod n). Bên A thực hiện tính toán (gy mod n)x= gxy mod n nhờ đó cũng xác định được khóa bí mật y của bên B. b. Phân phát khóa Trong hệ mã mật đối xứng, khóa bí mật tạo ra phải được truyền đi trên kênh mật riêng . Trong hệ mật mã dùng khóa công khai, khóa công khai phải đảm bảo cùng một cặp với một khóa bí mật. Khóa công khai được truyền đi như một bản rõ trên đường truyền và phải có hỗ trợ xác thực. Khóa bí mật được truyền đi trên một kênh riêng và cũng phải được xác thực. Thông thường, khóa công khai thường đượcthay bằng một chứng chỉ khóa công khai (public – key certificate). Chứng chỉ này bao gồm một khóa công khai và một xâu định danh để xác định được khóa mật liên kết với nó. c. Thời gian tồn tại của chứng chỉ. Khi cần hủy bỏ một chứng chỉ ta có thể thực hiện theo nhiều phương pháp: Cách 1: sử dụng danh sách các chứng chỉ bị hủy bỏ CRL (certification revocation list). Khi cllient kiểm tra một chứng chỉ thì nó cũng kiểm tra trong danh sách CRL để kiểm tra xem chứng chỉ này đã bị hủy hay không. Như thế mỗi client phải được cập nhật danh sách này thường xuyên. Cách 2: mỗi chứng chỉ tự động hết hiệu lực sau một thời gian xác định nào đó. Nhưng nếu muốn hủy chứng chỉ trước thời gian đó thì vẫn phải dùng đến danh sách CRL như trên. Cách 3: giảm thời gian tồn tại có hiệu lực của một chứng chỉ xuống gần bằng 0. Khi đó client phải thường xuyên kiểm tra chứng chỉ để xác đinh thời gian có hiệu lực của khóa công khai. 8.4.2 Quản trị nhóm an toàn Xét nhóm G, khóa mật CKG được chia sẻ với tất cả các thành viên của nhóm để mã hóa thông điệp của nhóm. Nhóm còn có thêm 1 cặp khóa công khai/riêng (KG+, KG-) để giao tiếp với các thành viên của nhóm khác. Tiến trình P muốn tham gia vào nhóm G sẽ gửi yêu cầu tham gia JR. RP (Reply pad) và khóa bí mật KP,G được mã hóa sử dụng khóa công khai KG+ của nhóm. JR được gán bởi P và nó được gửi đi cùng với chứng chỉ chứa khóa công khai của P. Khi một thành viên nhóm Q nhận một yêu cầu từ P, nó sẽ xác thực P, xác định tem thời gian T để đảm bảo rằng P vẫn còn giá trị tại thời điểm gửi. Sau đó lấy ra khóa công khai của P để kiểm tra tính hợp lệ của JR. Nếu P được chấp nhận vào nhóm, Q trả lại thông điệp GA nhận dạng P và chứa N (nonce). RP được sử dụng để mã hóa khóa giao tiếp của nhóm CKG. P sử dụng khóa KG- để mã hóa cùng với CKG. Sau đó thông điệp GA được gán cho Q sử dụng khóa KP,G. 8.4.3 Quản trị phân quyền (Authorization management ) Sử dụng capability để xác định quyền truy cập tài nguyên của tiến trình chiếm giữ nó. Một capability là một từ định danh 128 bit, cấu trúc bên trong được mô tả như sau: 48 bit đầu tiên được khởi tạo khi đối tượng được tạo ra bởi server của đối tượng. 48 bit này được gọi là server port. 24 bit tiếp theo được sử dụng để xác định đối tượng tại server đã định sẵn. 8 bit tiếp theo xác định quyền truy cập của holder của capability Trường check (48 bit cuối) được dùng để tạo ra một capability thật (không thể giả mạo được). Khi một đối tượng được khởi tạo, server của đối tượng đó chọn lấy một trường check ngẫu nhiên và lưu trữ nó trong cả capability và trong cả table riêng của server Sự ủy quyền(delegation) Sự ủy thác quyền truy nhập là một kỹ thuật quan trọng để thực thi sự bảo vệ trong hệ thống máy tính và đặc biệt hơn là trong hệ phân tán. Ý tưởng cơ bản rất đơn giản: bằng việc chuyển quyền truy nhập từ tiến trình này sang tiến trình khác, nó sẽ trở nên dễ dàng hơn để phân tán công việc giữa các tiến trình mà không làm ảnh hưởng tới việc bảo vệ tài nguyên. Có vài cách để thực thi sự ủy quyền, một cách là sử dụng proxy. Phần 2: Tìm hiểu về các hệ thống file phân tán Sau khi xem xét 7 nguyên lý của hệ phân tán ta sẽ áp dụng các nguyên lý đó để tìm hiểu các nguyên lý đó được sử dụng như thế nào trong các hệ thống phân tán cụ thể và ở đât chúng ta sẽ minh họa bằng các hệ thống file phân tán Chương 10: Các hệ thống file phân tán Chúng ta đều biết rằng việc chia xẻ dữ liệu là một vấn đề cơ bản của hệ phân tán chính vì vậy không có gì là ngạc nhiên khi của hệ thống file phân tán định hình một cách cơ bản cho rất nhiều các ứng dụng phân tán. Hệ thống file phân tán cho phép nhiều bộ xử lý chia xẻ dữ liệu theo một cách an toàn và đáng tin cậy. Chính vì vậy chúng ta sẽ cùng nhau xem xét hệ thống file phân tán như một mô hình chung cho hệ thống file phân tán chung mục đích. Chúng ta sẽ xem xét 2 hệ thống file phân tán khác nhau, đó là hệ thống file phân tán mạng Sun (NFS), là hệ thống được sử dụng rộng rãi và hiện nay đang được mở rộng cho các phiên bản Internet. Một hệ thống file phân tán khác là Coda, nó kế thừa hệ thống file Andrew (AFS). Bên cạnh đó ta cũng xem xét thêm một hệ thống thứ 3. Plan 9 là một hệ thống phân tán mà ở đó tất cả các tài nguyên đều được coi như là các file. Một hệ thống nữa chúng ta cũng xem xét đó là xFS và SFS. Chúng ta cùng nhau xem xét 7 nguyên lý của hệ phân tán sẽ được áp dụng vào trong từng hệ thống file phân tán như thế nào và đưa ra so sánh các hệ thống file phân tán đó ở phần kết luận. 10.1 Sun Network File System (NFS). Hệ thống NFS được phát triển bởi Sun sử dụng trong các trạm sử dụng hệ Unix nhưng nó cũng được sử dụng tốt trong một số hệ khác. Vấn đề chủ đạo trong hệ NFS đó là mỗi file server cung cấp một view chuẩn của mỗi hệ thống file cục bộ có nghĩa rằng sẽ không có vấn đề gì khi mà hệ thống file cục bộ được thực thi , mỗi một NFS chủ sẽ cung cấp cùng một mô hình. Mô hình này cùng với giao thức giao tiếp cho phép client truy cập vào các file được lưu trữ trên server. 10.1.1 Tổng quan về NFS NFS không phải hẳn là một hệ thống file mà nó là tập các giao thức cung cấp cho các client với cùng một mô hình của hệ thống file phân tán. Ở khía cạnh này thì NFS được so sánh với CORBA, giống như CORBA thì có rất nhiều các thực thi NFS , chạy trên các hệ điều hành và các máy khác nhau. Giao thức NFS được thiết kế theo cách mà các thực thi khác nhau sẽ dễ dàng hợp tác với nhau, bằng cách này thì NFS có thể chạy trên một tập các máy tính không đồng bộ. Kiến trúc NFS: Hình 30: mô hình a là mô hình truy cập từ xa với mô hình b là mô hình upload/download Mô hình NFS là remote file service. Trong mô hình đó, client yêu cầu truy nhập một cách trong suốt tới hệ thống file cái mà được quản lý bởi server từ xa. Tuy nhiên client không biết địa chỉ thực sự của file. Thay vào đó, nó yêu cầu một giao diện tới một hệ thống file mà giống như giao diện được yêu cầu bởi một hệ thống file cục bộ thông thường. Cụ thể client được yêu cầu bởi một giao diện bao gồm rất nhiều file thực thi nhưng server chịu trách nhiệm thực thi những file đó. Nhưng trong mô hình upload/download một client truy cập một file cụ bộ sau khi download tù server. Khi client thự hiện xong các thao tac trên file đó, nó upload trở lại server và file đó có thể tiếp tục được sử dụng bởi client khác. Trong dịch vụ Internet FTP có thể được sử dụng bằng cách này khi một cliẻnt download một file hoàn chỉnh, chỉnh sủa nó và gửi ngược trở lại. Hình 31 :Kiến trúc NFS cơ bản cho UNIX Khi một client truy cập một hệ thống file sử dụng các lời gọi hệ thống cung cấp bởi hệ điều hành cục bộ đó. Tuy nhiên giao diện hệ thống file UNIX cục bộ đó được thay thế bởi giao diện hệ thống file ảo (VFS), cái mà bây giờ là chuẩn thực tế cho giao diện của các hệ thống file khác nhau. Các thao tác trên giao diện VFS cùng giống như trên các hệ thống file cục bộ hoặc trên các thành phần riêng biệt như NFS client, thực hiện truy cập các file được lưu trữ tại các server từ xa. Tại NFS, tất cả các client- server các giao tiếp được thực hiện qua RPC. NFS client thực thi các thao tác hệ thống file NFS như là RPC tới server. Trên phương diện của server, chúng ta sẽ thấy tổ chức tương tự, NFS server sẽ chịu trách nhiệm phản hồi lại yêu cầu của client. Yêu cầu của RPC stub và NFS server sẽ convert chúng để diều chỉnh các thực thi VFS file và chuyển đến lớp VFS. Sau đó VFS chịu trách nhiệm thực thi hệ thống file cục bộ mà ở đó các file thực sự được lưu trữ. Mô hình hệ thống file: Operation v3 v4 Description Create Yes No Tạo một file thông thường Create No Yes Tạo một file dị thường Link Yes Yes Tạo một đường dẫn cứng tới một file Symlink Yes No Tạo một đường dẫn biểu tượng tới một file Mkdir Yes No Tạo một thư mục con trong một thư mục cho trước Mknod Yes No Tạo một file đặc biệt Rename Yes Yes Thay đổi tên file Rmdir Yes No Xoá một thư mục con trống trong một thư mục Open No Yes Mở file Close No Yes Đóng file Lookup Yes Yes Tìm kiếm một file nhờ tên file Readdir Yes Yes Đọc các mục của một thư mục Readlink Yes Yes Đọc tên đường dẫn chứa trong một đường dẫn biểu tượng Getattr Yes Yes Đọc giá trị thuộc tính cho một file Setattr Yes Yes Thiết lập một hoặc nhiều giá trị thuộc tính cho một file Read Yes Yes Đọc dữ liệu chứa trong file Write Yes Yes Ghi dữ liệu lên file Mô hình hệ thống file được nêu ra bởi NFS thì hầu như tương tự với hệ thống dựa trên Unix. File sẽ được coi như một chuỗi các byte kkhông phiên dịch. Để truy nhập vàp một file thì client đầu tiên phải tìm kiếm tên file trong dịch vụ tên và kết hợp với file handle, mỗi file có một số các thuộc tính mà giá trị của nó sẽ được xem xét và thay đổi. 10.1.2 Giao tiếp (Communication) Một vấn đề quan trọng trong thiết kế NFS đó là sự độc lập của các hệ điều hành, kiến trúc mạng và giao thức trung chuyển. Trong NFS, tất cả các giao tiếp giữa client và server đều phải tuân thủ theo giao thức Open Network Computing RPC (ONC RPC), nó được định nghĩa với các chuẩn cho việc trình diễn dữ liệu. Tất cả các thực thi NFS có thể được thực hiện như là một thủ tục từ xa gọi đến một file server. Thực tế phải đến phiên bản 4 của NFS, để đọc dữ liệu từ một file đầu tiên, client đầu tiên phait tìm kiếm file handle sử dụng thao tác lookup sau đó sử dụng câu lệnh read như trong hình (a). Hình 32: a, Mô hình đọc dữ liệu từ một file ở phiên bản NFS 3 b, Đọc dữ liệu sử dụng các thủ tục kết hợp trong phiên bản 4. Điều trên yêu cầu 2 RPC thành công nhưng ở phiên bản 4 cung cấp thủ tục compound mà một vài RPC có thể được nhóm lại thành một một yêu cầu đơn như trong hình (b). Khi đó client kết hợp yêu cầu lookup và request thành một RPC. Với phiên bản 4 thì nó thực sự cần thiết để mở một file trước khi lện đọc được thực thi. Sau khi file handlde được tìm kiếm nó sẽ chuyển sang thao tác mở sau đó là thao tác đọc nhưng chỉ có 2 message cần phải trao đổi giữa client và server. 10.1.3 Tên (Naming) Hình 33: Mounting một hệ thống file từ xa trong NFS Giống như hầu hết các hệ thống file phân tán khác, tên đóng vai trò rất quan trọng trong NFS. Mô hình chủ đạo của NFS là cung cấp cho client có thể truy cập một cách trong suốt tới một hệ thống file từ xa nằm trên server. Sự trong suốt này được thực hiện bằng việc cho phép client có thể mount tới hệ thống file từ xa trong hệ thống file cục bộ. NFS cho phép client mount tới chỉ một phần của hệ thống file. Một server được nói là truy xuất a directory khi mà nó làm cho directory và các entry của nó là sẵn sàng đối với các client. Theo nguyên tắc người sử dụng không chia xẻ tên miền (name space). Theo như hình trên file có tên /remote/vu/mbox tại client A có tên /work/me/mbox ở client B. chính vì thế ta phải có giải pháp để giải quyết vấn đề để một client có thể truy cập vào vùng tên file đó. Có một cách phổ biến được sử dụng đó là với mỗi client sẽ được cung cấp một không gian tên chuẩn, ví dụ như các client đều sử dụng đường dẫn /usr/bin để mount tới hệ thống file chứa tập chuẩn các file chương trình, cũng tương tự như vậy /local được sử dụng để mount tới hệ thống file cục bộ mà đặt trên host của client. Một server NFS cũng có thể mount đường dẫn của chính nó mà được cung cấp bởi server khác tuy nhiên nó không cho phép export những directory tới client của chính nó. Thay vào đó client sẽ mount giống như đường dẫn từ server có chứa nó. File handles: File handle là một reference của một file nằm trong hệ thống file. Nó là một cái tên độc lập của file. Một file handle được tạo ra bởi server và nó là duy nhất với tất cả các hệ thống file được export bởi server. Nó được tạo ra khi mà một file được tạo ra. Trong phiên bản NFS 2 thì file handle sử dụng 32 byte nhưng nó có thể mở rộng ra thành 64 byte ở phiên bản 3 và thành 128 byte ở phiên bản 4. Một file handle được thực thi như là một định danh thực của một file trong hệ thống file và nó còn có nghĩa rằng khi một file tồn tại nó sẽ có một và cùng file handle. Và ưu điểm của nó đó là các thực thi của hầu hết các file yêu cầu file handle thay cho tên file và client có thể tránh được việc lặp lại việc tìm xem lại tên file trước khi các các thao tác file và một ưu điểm nữa là client có thể truy cập tới file một cách độc lập với tên file. Bởi vì file hàndle được lưu trữ một cách cục bộ bởi client cho nên một điều quan trọng là server không được tái sử dụng một file handle sau khi đã xóa file. Automounting Như chúng ta đã nói mô hình tên NFS cung cấp cho người sử dụng không gian tên. Chia xẻ trong mô hình này trở thành rất khó khăn nếu người sử dụng đặt tên cho những file giống nhau bằng những tên khác nhau. Một giải pháp cho vấn đề này là cung cấp cho mỗi người sử dụng không gian tên cục bộ theo một tiêu chuẩn và việc mount tới các hệ thống file tù xa sẽ là giống nhau cho mỗi người sử dụng. Một vấn đề khác của mô hình tên NFS đó là quyết định khi nào một hệ thống file từ xa nên được mount. Hãy tưởng tượng với một hệ thống lớn với cả vài nghìn user, giả sử rằng mỗi người sử dụng đều có thư mục /home được sử dụng để mount tới home của các user khác, khi đó yêu cầu mount tới một hệ thống file từ xa được thực hiện trên NFS bởi automounter được chạy như là một tiến trình độc lập với các máy client. Khi đó giả sử rằng với mỗi người sử dụng đường dẫn home cho mỗi người sử dụng là /home. Khi mà một máy client bôt, automounter batứ đầu mount tới đường dẫn đó. Hiệu quả của mount cục bộ đó là bất cứ khi nào một chương trình cố gắng truy cập vào /home thì UNIX sẽ forword thao tác tìm kiếm tới NFS clỉent, trong trường hợp này thì sẽ forword yêu cầu tới automounter trong vai trò như là NFS server. File Atribute File NFS có rất nhiều các thuộc tính. Ở phiên bản 3, tập các thuộc tính là cố định và mỗi thực thi NFS đều phải có các thuộc tính đó. Với NFS phiên bản 4, tập các thuộc tính được chia thành các lọai ví dụ như tập thuộc tính bắt buộc, tập thuộc tính lựa chọn (có hoặc không có đều được) và các thuộc tính thêm. Thuộc tính Mô tả TYPE Loại file (file thường, thư mục, đường dẫn biểu tượng) SIZE Độ dài của file tính bằng bytes CHANGE Chỉ báo cho client nhận biết nếu hoặc khi file bị thay đổi. FSID Server-duy nhất xác định của file's file system Hình 34:Các thuộc tính bắt buộc Thuộc tính Mô tả ACL Một danh sách điều khiển truy nhập kết hợp với file FILEHANDLE Server-cung ứng con trỏ file của file FILEID Một hệ thống file duy nhất xác định file đó FS_LOCATIONS Định vị trong mạng mà hệ thống file có thể được tìm thấy. OWNER Ký tự xâu tên của chủ sở hữu file. TIME_ACCESS Thời điểm mà một file dữ liệu được truy nhập lần cuối TIME_MODIFY Thời điểm mà một file dữ liệu được thay đổi lần cuối TIME_CREATE Thời điểm mà file được tạo ra Hình 35: Các thuộc tính khuyến nghị 10.1.4 Đồng bộ hóa File trong hệ phân tán được chia xẻ cho rất nhiều các client. Nếu việc chia xẻ không bao giờ xảy ra thì nó không phải là hệ phân tán. Tuy nhiên việc chia xẻ cũng có cái giá của nó, để đảm bảo việc chia xẻ file là nhất quán thì việc đồng bộ là cần thiết. Đồng bộ hóa sẽ đơn giản nếu file được giữ ở server trung tâm nhưng khi đó vấn đề hiệu năng sẽ được mang ra xem xét, chính vì thế mà các client được cho phép giữ các bản copy của file khi mà chúng đang đọc hay ghi . Ngữ nghĩa của chia xẻ file. Khi 2 hay nhiều user chia xẻ cùng 1 file khi đó sẽ rất cần thiết đưa ra định nghĩa ngũ nghĩa của việc đọc và ghi một cách chính xác. Ta hãy cùng xem xét vấn đề ngữ nghĩa của chia xẻ file trong NFS. Trong hệ thống đơn bộ xử lý cho phép các bộ xử lý chia xẻ file ví dụ như Unix, ngữ nghĩa chỉ ra rằng khi mà lệnh đọc thực hiện sau lệnh viết thì đọc sẽ lấy giá trị vừa được viết, cũng tương tự như vậy khi mà 2 lệnh viết cùng xảy ra theo sau là lệnh đọc thì giá trị đọc là giá trị ghi sau cùng và hệ thống cho phép thông tin về trình tự thời gian tuyết đối cho tất cả các thao tác . Mô hình này được ví dụ trong Unix Semantic rất dễ hiểu và dễ thực hiện. Trong hệ phân tán ngữ nghĩa Unix có thể thực hiện một cách dễ dàng băng cách chỉ có một file server và client không lưu trữ file. Tât cả các thao tác đọc và ghi đều thực hiện trực tiếp tới server. Tuy nhiên hiệu năng của phương pháp này rất thập vì có thể dẫn tới việc server làm việc quá tải và không đáp ứng được yêu cầu. Ta giải quyết vấn đề trên bằng cách cho phép các client lưu trữ các bản sao của file mà có nhiều người sử dụng truy cập đến trong bộ nhớ caches cục bộ. khi đó có một vấn đề là làm sao cập nhật được tất cả các thay đổi ở caches trở về server ngay lập tức. Một giai pháp được đưa ra đó là giảm nhẹ tính ngữ nghĩa của chia xẻ file. Thay cho yêu cầu đọc để biết được các lệnh ghi trước đó thì có một cách khác đó là thay đổi khi file mở chỉ có thể quan sát bởi tiến trình mà thay đổi file, chỉ khi file đóng thì các thay đổi đó các tiến trình khác mới có thể quan sát đựợc. Khi một tiến trình đóng thì nó sẽ gửi bản copy tới server cho nên các lệnh đọc sau đó sẽ lấy giá trị mới cập nhật. luật đó gọi là session semantic và cũng giống như hầu hết các hệ thống file phân tán, NFS cũng thực hiện theo như vậy, điều đó có nghĩa rằng tất cả các thực thi đều thực hiện trên dữ liệu được lưu trong cache cục bộ. Tuy nhiên có một vấn đề phát sinh đó là nếu có 2 hay nhiều client cùng thay đổi một file. Giải pháp đó là mỗi một file được đóng lần lượt, giá trị của nó được gửi cho server và kết quả cuối cùng phụ thuộc vào yêu cầu đóng cuối cùng là của cái nào. Một cách khác đó là làm cho tất cả các file không thể thay đổi được tức là thao tác ghi là không thể thực hiện và chỉ có thao tác tạo và đọc. Ngoài ra ta cung có thể sử dụng giao tác (transaction) giống như nói ở chương 5, để truy nhập một file hay một nhóm của file, tiến trình thực hiện BEGIN_TRANSACTION, END_TRANSACTION. Khóa file trong NFS Với hệ phân tán mà server phi trạng thái, khóa file là vấn đề khá mơ hồ. Trong NFS, khóa file là một giao thức độc lập được thực hiện bởi quản lý khóa. Tuy nhiên vì một số lý do giao thức khóa không được phổ dụng vì tính phức tạp cảu giao thức và kết quả mang lại không hiệu quả. Trong phiên bản 4 khóa file được tích hợp trong giao thức truy nhập file NFS. Mục đích mong muốn đó là làm cho người sử dụng cảm thấy đơn giản hơn trong việc khóa file thay cho việc dùng đến các giải pháp khác khóa file trong phiên bản 3. Khóa file là sự kết hợp khi mà client và server có thể bị lỗi khi mà vẫn còn khóa. Khi đó khôi phục sẽ đảm bảo cho việc chia xẻ dữ liệu được nhất quán. Khóa file trong phiên bản 4 rất đơn giản, chỉ có 4 thao tác liên quan tới khóa: Câu lệnh Miêu tả Lock Tạo ta khóa Lockt Kiểm tra khi có đụng độ khóa Locku Dỡ bỏ khóa Renew Làm mới một khóa 10.1.5 Lưu trữ và nhân bản NFS sử dụng caches của client để nâng cao hiệu năng sử dụng. Client caching Caching trong phiên bản 3 được thực hiện với rất nhiều chính sách khác nhau và không được bảo đảm tính nhất quán. Dữ liệu lưu trữ trong caches có thể cũ hơn vài giây so với dữ liệu lưu trong server. Tuy nhiên thực thi tồn tại cho phép dữliệu cache cũ 30 giây mà client không biết. Ở phiên bản 4 giải quyết được các vấn đề về nhất quán. Mỗi client có bộ nhớ cache mà nó chứa dữ liệu trước đó đọc từ server. Client lưu trữ dữ liệu file, thuộc tính, file handle và danh mục. Có 2 cách để cache dữ liệu. Cách đơn giản nhất là khi mà client mở file và lưu dữ liệu từ server như là kết quả của thao tác đọc, khi client đóng file, dữ liệu sẽ được gửi trở lại server. Khi một phần của file được cache, client có thể lưu trữ dữ liệu trong caches sau khi đóng file, cũng có khi một vài client trên cùng 1 máy có thể chia xẻ cache.NFS yêu cầu bất cứ khi nào một client mở file trước khi đóng file thì clietn phải làm cho sữ liệu cache có giá trị (có hiệu lực) ngay lập tức. Replica server NFS phiên bản 4 cung cấp một tiện ích nhỏ cho nhân bản file. Chỉ khi cả hệ thống file có thể nhân bản thuộc tính đó là FS_LOCATIONS. Thuộc tính này cung cấp một danh sách các địa chỉ nơi mà mỗi địa chỉ được đưa ra như tên DNS hay địa chỉ IP. 10.1.6 Chịu lỗi Cho tới tận những phiên bản gần đây của NFS thì vấn đề chịu lỗi cũng vẫn thực sự là một vấn đề lý do đó là giao thức NFS không yêu cầu server phải có trạng thái. Vấn đề khôi phục lại khi server bị lỗi là đơn giản hơn khi không có trạng thái nào bi mất. Tuy nhiên trạng thái được duy trì bởi quản lý khóa riêng biệt và trong một vài trường hợp thì một vài phép đo đặc biệt là cần thiết Lỗi RPC Vấn đề xảy ra khi sử dụng NFS là nó khong cung cấp sự bảo đảm bảo trong vấn đề nhất quán. Vấn đề chính NFS với ngữ nghĩa RPC thiếu mất việc phát hiện yêu cầu trùng lặp. khi mà reply bị mất và client gửi lại thành công yêu cầu ban đầu, server sẽ thực hiện yêu cầu thêm một lần nữa.. Có 3 trường hợp xảy ra Trường hợp 1, client gửi yêu cầu và bắt đầu đếm thời gian, nếu như timer dừng lại trước khi có tin reply thì client tiếp tục gửi. Trường hợp thứ 2 là server nhận được yêu cầu gửi lại sau khi nó đã gửi tin phản hồi lại cho client, nếu như thời gian chuyển đến cho yêu cầu gửi lại đã hết cho server gửi lại tin phản hồi thì server sẽ bỏ qua yêu cầu gửi lại Trường hợp 3 đó là tin phản hồi đã mất và yêu cầu gửi lại được phản hồi bởi gửi đi kết quả đã được lưu trữ. Khóa file trong khi có lỗi Khóa file trong NFS phiên bản 3 được thực hiện qua một server riêng biệt. bằng cách này sự phi trạng thái của giao thức NFS có thể được duy trì và vấn đề liên quan tới chịu lỗi có thể thực hiện bằng khóa server. Tuy nhiện với phiên bản 4 cùng với việc khóa file nó sẽ chắc chắn xảy ra đó là cung cấp cho lỗi server và client như là một phần cảu giao thưc NFS. Để khóa file, client chỉ ra việc khóa yêu cầu ở server. Khi có khóa chúng ta có thể chạy khi mà client hay server bị crash. Để giải quyết vấn đề client bị vỡ, server thỏa thuận trên tất cả các khóa được cho phép 10.1.7.Bảo mật Như chúng ta đã đề cập trước đó vấn đề cơ bản đi cùng với NFS đó là hệ thống fiel từ xa nên đữợc biêu diễn như thế nào nếu nó là file cục bộ. chính vì thế sẽ không có gì đáng ngạc nhiên khi mà vấn đề chính của bảo mật trong NFS tập trung vào giao tiếp giữa client và server điều đó có nghĩa rằng bảo mật kênh (đã được nói ở chương 8). Thêm vào đó là bảo mật RPC nó cần thiết để điều khiển truy nhập tới file, các thuộc tính của file trong NFS. Bảo mật RPC Bởi vì NFS là lớp nằm trên cùng của hệ thống RPC, thiết lập việc bảo mật kênh trong NFS có nghĩa rằng thiết lập bảo mật RPC. Cho tới tận NFS phiên bản 4, bảo mật RPC có nghĩa rằng chỉ có xác thực là được quan tâm. Có 3 cách để thực hiện xác thực. Cách thứ nhất cũng là cách phổ biến nhất đó là xác thực hệ thống, một client gửi user ID và group ID tới server cùng với list các nhóm mà nó là thành viên. Phương pháp thứ 2 được sử dụng trong các phiên bản cũ hơn của NFS đó là sử dụng khóa trao đổi Diffie- Hellman để tạo ra khóa phiên giao dịch (chương 8) Giao thức xác thực thứ 3 là Kerber cũng được nói đến trong chương 8. Đặc biệt với NFS phiên bản 4, vấn đề bảo mật được cung cấp NPCSEC_GSS, đóa là framework bảo mật có thể cung cấp vô số cơ chế bảo mật cho thiết lập bảo mật kênh. Nó không chỉ cung cấp cơ sở cho các hệ thống xác thực khác nhau mà còn cung cấp tính nguyên vẹn của tin nhắn và tính bảo mật, 2 thuộc tính không có ở NFS phiên bản cũ. NPCSEC_GSS dựa trên giao diện tiêu chuẩn cho các dịch vụ bảo mật gọi là GSS-API (đề cập ở chương 8). Điều khiển truy nhập Tính xác thực trong NFS là chìa khóa của vấn đề bảo mật trong NFS,nó cung cấp các cơ chế nhưng không cụ thể bất cứ chính sách nào. Điều khiển truy nhập được cung cấp bởi các thuộc tính file ACL. Thuộc tính này là tập hợp các đầu vào điều khiển truy nhập mà mỗi một đàu vào chỉ định các quyền truy nhập cho từng người dùng và nhóm cụ thể.(chèn bảng). 10.2 Hệ thống file Coda 10.2.1 Tổng quan về Coda Coda là một hệ thống file phân tán đảm bảo tính co dãn, tính an toàn và khả năng tồn tại cao. Mục đích quan trọng của là đảm bảo thu được mức cao trong việc định danh và độ trong suốt vị trí, để hệ thống xuất hiện trước người dùng tương tự như một hệ thống file cục bộ thông thường. Mô hình cơ bản của CODA Coda gồm 2 thành phần chính Vice file server: Đây là một nhóm nhỏ các bộ quản lí trung tâm, có liên hệ với nhau. Tiến trình Venus đảm nhiệm cung cấp sự truy cập tới hệ thống file nằm trên Vice file server Virtual client: là tập hợp rộng lớn các máy trạm ảo, thông qua nó người dùng và các tiến trình có thể truy nhập vào hệ thống file. Có ba tiến trình diễn ra bên phía server: quan trọng nhất là đảm bảo cho việc duy trì một tập các file cục bộ ; các máy Vice tin cậy để chạy server thẩm định quyền ; và một tiến trình update để dam bảo các siêu thông tin (meta-informaton) trên hệ thống file nhất quán tại mỗi server. Hình 46 . Mô hình CODA 10.2.2 Truyền thông Truyền thông liên quá trình trong Coda được thực hiện bằng cách sử dụng RPCs. Tuy nhiên, hệ thống RPC2 cho Coda tinh vi hơn rất nhiều so với các hệ thống RPC truyền thống như ONC RPC được sử dụng trong NFS. RPC2 có các tính năng đáng kể sau đây Cho phép client nắm được trạng thái của server (đang xử lý kết quả hoặc đã ngừng hoạt động). Hỗ trợ cơ cấu cho phép client và server có thể truyền thông với nhau sử dụng giao thức đặc tả ứng dụng, gọi là side effect. Hỗ trợ multicasting thông qua hệ thống MultỉPC, thực chất là thực hiện nhiều RPC song song. 10.2.3 Tiến trình Có sự khác biệt rõ ràng giữa các tiến trình client và server. Client được thực hiện bởi tiến trình Venus còn server được thực hiện bởi tiến trình Vice. Cả hai loại tiến trình đều là một tập hợp các luồng nhất quán. Luồng trong Coda không có quyền ưu tiên và hoạt động hoàn toàn trong không gian người sử dụng. Để giải thích cho thao tác liên tục khi gặp phải sự ngăn chặn lệnh I/O, một chuỗi riêng biệt được sử dụng để xử lý tất cả các thao tác I/O, mà thực hiện việc sử dụng các thao tác I/O thiếu đồng bộ cấp thấp của hệ thống hoạt động cơ sở. Chuỗi này mô phỏng một cách có hiệu quả I/O đồng bộ mà không hề ngăn chặn toàn bộ một quy trình. 10.2.4 Định danh Coda duy trì một hệ thống định danh tương tự như UNIX. File được nhóm thành một đơn vị gọi là volume. Volume tương ứng với các cây con trong không gian tên chia sẻ của server Vice. Có 2 lý do khiến volume trở nên quan trọng:Chúng tạo nên đơn vị cơ bản mà từ đó không gian tên được xây dựng. Và chúng tạo nên đơn vị cho nhân bản ở phía server. Thông tin mount được Vice file server trả về cho tiến trình Venus sẽ cho phép Venus tự động mount một volume vào không gian tên của client khi cần thiết. Coda phân biệt 2 loại volume: volume logic tương ứng với một bản sao của volume vật lý và có RVID liên kết (Replicated Volume Identifier). RVID là vị trí và định danh volume không phụ thuộc vào bản sao. Mỗi volume vật lý có một định danh volume (Volume Identifier – VID) Coda gán cho mỗi file một định danh file dài 96 bit, gồm 2 phần: phần đầu chứa 32bit RVID của volum logic và phàn thứ hai gồm 64 bit định danh duy nhất file trong volume. 10.2.5 Đồng bộ Chia sẻ file trong Coda Khi một client mở thành công một file, toàn bộ file đó được sao chép vào máy client và server ghi lại client đã sao chép. Trong Coda, server cho phép nhiều client cùng đọc một file nhưng không cho phép hai client thao tác trên cùng một file mà trong đó ít nhất một thao tác là thao tác ghi. Vấn đề cập nhật xảy ra khi một client thay đổi giá trị của file và gửi bản cập nhất về phía server. Server nhận biết được sự cập nhật này, tuy nhiên các client khác lại vẫn thao tác trên các bản sao chép đang chứa tại máy của mình (nghĩa là chưa được cập nhật). Ngữ nghĩa của giao tác: Trong Coda, một phân vùng là phần của mạng chứa một tập hợp các clienr hoặc server hoặc cả hai. Điều quan trọng ở đây là các thao tác trên file có thể tiếp tục thực hiện trong trường hợp xảy ra các thao tác đụng độ giữa các vùng khác nhau. Để làm được điều này, Coda sử dụng lược đồ phiên bản. Mỗi file có một số hiệu phiên bản biểu thị rằng nó đã được cập nhật bao nhiêu lần kể từ khi được tạo ra. Khi một client bắt đầu một phiên, tất cả dữ liệu liên quan đến phiên sẽ được sao chép về máy client, bao gồm cả số hiệu phiên bản của mỗi phần tử dữ liệu. Khi có một hoặc nhiều giao tác đang thực hiện ở phía client, phân vùng mạng bị đứt kết nối. Khi đó, Venus cho phép client tiếp tục và hoàn thành việc thực hiện phiên như là không có gì xảy ra. Sau đó, khi kết nối với server được thiết lập lại, sự cập nhật được gửi tới server giống như nó đã diễn ra ở client. 10.2.6 Đệm và nhân bản Client Caching Client trong Coda luôn luôn thực hiện đệm toàn bộ các file do: (1) nó đảm bảo được khả năng co dãn ; (2) làm tăng khả năng chịu lỗi. Cơ chế đệm dữ liệu trong Coda được thực hiện dựa trên callback. Server Replication Coda cho phép server chứa file được nhân bản và sử dụng giao thức ghi nhân bản (replicated-write protocol) để duy trì sự nhất quán của các bản sao volume. Ngoài ra, Coda cũng hỗ trợ việc phát hiện và khắc phục sự không nhất quán thông qua việc sử dụng vecto phiên bản Coda (Coda version vector). 10.2.7 Chịu lỗi Thao tác ngắt kết nối Để thao tác ngắt kết nối thành công, phải đảm bảo rằng bộ đệm của client chứa những file sẽ được truy cập trong khi ngắt kết nối. Việc đảm bảo bộ đệm chứa đầy đủ những file thích hợp được gọi là dự trữ (hoarding). Coda sử dụng cơ chế ưu tiên để đảm bảo điều đó. Đầu tiên, người sủ dụng chỉ ra các file và thư mục mình cần bằng cách chứa các pathname trong cơ sở dữ liệu dự trữ (được duy trì cho mỗi máy trạm). Kết hợp thông tin trong cơ sở dữ liệu dự trữ và thông tin tham chiếu hiện tại, Coda tinh toán quyền ưu tiên cho mỗi file, sau đó nó gán file với mỗi quyền thỏa mãn 3 điều kiện: (1) Khong có file không đệm có quyền cao hơn file đệm ; (2) Hoặc bộ đệm đã đầy hoặc không có file không đệm nào có quyền ưu tiên khác 0 ; (3) Mỗi file đệm được sao chép của file trong AVSG của client. Bộ nhớ ảo có thể phục hồi Bộ nhớ ảo có khả năng phục hồi là cơ cấu mức người dùng để duy trì các cấu trúc dữ liệu quan trọng trong bộ nhớ để đảm bảo rằng chúng có thể dễ dàng được phục hồi sau khi bị phá vỡ. Ý tưởng cơ bản khá đơn giản: dữ liệu được chứa trong file được map vào trong bộ nhớ khi cần thiết. Các thao tác trên dữ liệu sẽ được ghi lại giống như trong trường hợp giao tác phẳng. 10.2.8 An toàn – An ninh Kênh an toàn: Coda sử dụng hệ thống mật khóa bí mật để thiết lập kênh truyền an toàn giữa client và server. Tất cả việc truyền thông giữa client và server đều dựa trên cơ cấu RPC an toàn của Coda RPC an toàn chỉ được sử dụng để thiết lập kết nối an toàn giữa client và server, nó không đủ an toàn để thiết lập kênh đăng nhập. Do đó một giao thức khác được sử dụng trong đó client sử dụng thẻ thẩm định quyền. Nó chứa đựng định danh của tiến trình, định danh của thẻ, khóa phiên, tem thời gian biểu thị thời gian thẻ hợp lệ và hết hạn. Điều khiển truy cập: Coda sử dụng điều khiển truy cập để đảm bảo rằng chỉ các tiến trình có quyền mới được phép truy cập vào file. Coda phân biệt quyền truy cập đối với từng loại thao tác và không quy định quyền đối với việc thực thi file. 10.3 Các hệ thống file phân tán khác. Ngoài các hệ thống file đã thảo luận thì còn có rất nhiều các hệ thống file khác mặc dù cũng có rất nhiều các hệ thống file tương tự với NFS hay Coda. Chính vì thế ở phần này ta sẽ có cái nhìn tổng quan về 3 hệ thống mà chúng khác nhau ở motọ vài khía cạnh nào đó. Đầu tiện là Plan 9 mà ở đó các tài nguyên đều được coi như là file. Sau đó là XFS, nó được coi như là một ví dụ về hệ thống file không có server và cuối cùng là SFS một hệ thống file mà trong tên file cũng bao gồm các thông tin về bảo mật. 10.3.1 Plan 9: Hợp nhất các nguồn tài nguyên thành file Plan 9 không thực sự là hệ thống file phân tán, tất cả tài nguyên của nó đều được truy cập theo cùng một cách, cú pháp và thao tác bao gồm cả các tài nguyên như tiến trình và giao diện mạng . Hệ thống Plan 9 bao gồm một tập các server yêu cầu các tài nguyên phải theo một khuana dạng không gian tên cục bộ. Để truy cập vào nguồn tài nguyên của server thì client phải mount không gian tên của server thành không gian tên của chính nó. Truyền thông Truyền thông qua mạng được thực hiện theo giao thức chuẩn là 9P, đó là giao thức thực hiện trên các thao tác hướng file. Một điểm cần lưu ý của Plan 9 đó là cách nó thực hiện truyền thông ở mức giao diện mạng. Giao diện mạng được thể hiện bởi một hệ thống file, trong trường hợp này là bao gồm một tập các file đặc biệt. Cách này giống như của Unix nhưng mà giao diện mạng của Unix là các file chứ không phải là hệ thống file Hình 37 Tổ chức chung của Plan 9 Tiến trình Có rất nhiều server trong Plan 9. Mỗi một server thực thi một không gian tên theo thứ bậc. Ví dụ đơn giản nhất của Plan 9 đó là file server, đó là một hệ thống dơn lẻ chạy trên một máy phức tạpvà server được tổ chức thành hệ thống lưu trữ 3 lớp: Hình 38: File server của Plan 9 Naming Mỗi một tiến trình trong Plan 9 đều có không gian tên của riêng nó, nó được xây dựng bởi không gian tên mounting cục bộ từ xa và đa không gian tên có thể được cùng một điểm mount và được gọi là liên danh mục Đồng bộ hóa Để tăng hiệu năng, rất nhiều hệ thống file phân tán đã truyền một file hay một phần của file tới client khi file được mở, chính vì thế nó xuất hiện nhiều bản sao của file được thay đổi đồng thời bởi các client khác nhau.Chính vì thế trong trường hợp cảu semantic phiên, bản update của client cuối cùng đóng file sẽ được giữlại còn ác cái khác sẽ mất đi. Plan 9 thực hiện luôn để cho hệ thống fiel gữ một bản copy của file. Tất cả các thay đổi sẽ đều phải truyền về server. Các client có những tiến trình của nso theo trình tự được đưa ra bởi server nhưng những thay đổi sẽ không bị mất đi. Caching và nhân bản Client có thể cache file sử dụng một server đặc biệt fọi là cfs, được gọ một cách tự động khi mà máy client boot. Cfs thực thi các chính sách cache, thao tác update được gửi ngay lập tức tới server. Bảo mật Trong Plan 9, người dùng được xác thực dựa trên giao thức Needham-Schroeder. 10.3.2 XFS Hệ thống file không server XFS được thiết kế để vận hành mạng cục bộ mà ở đó các máy kết nối với nhau qua đường link tốc độ cao có khả năng chịu lỗi, tính thích nghi cao. Trong kiến trúc của XFS có 3 dạng tiến trình khác nhau, đó là server lưu trữ, quản lý đa dữ liệu và client . nguyên lý cơ bản của XFS đó là vai trò của server, manager hay client có thể được thực hiện bởi bất cứ máy nào và có thể sử dụng các máy phức tạp để môtj máy thực hiện cả 2 chức năng như quản lý và client… Hình 39:Sự phân tán của các tiến trình XFS Truyền thông Tất cả các truyền thông trong XFS đều thực hiện theo RPC. Tuy nhiên có các vấn đề nảy sinh đó là hiệu năng và truyền thông điểm-điểm. Vì những lý do đó truyền thông trong XFS được thay bởi active message. Khi message chuyển đến, handler sẽ trực tiếp gọi và chạy cho tới khi hoàn thành, khi handler đang thực hiện thì không một messager nào được gửi đi. Tiến trình XFS thực hiện hệ thống lưu trữ dựa vào LFS (Log-Structured file sýstem). Trong LFS các thao tác viết lên hệ thống file thì được nhốm lại cùng nhau thành từng segment, được gắn vào với log, ngoài ra còn có thêm một bảng gọi là imap được sử dụng để tra địa chỉ của chúng trong log. Các server lưu trứ được tổ chức thành các nhóm, nó fiúp cho XFS dễ dàng thêm các server lưu trữ mà không yêu cầu các segment được quản lý bởi tất cả các server. Bảng sao được sử dụng để tìm kiếm server nào thuộc nhóm nào. Hình 40:Nguyên lý của log-based striping trong XFS Sử dụng hệ thống file cấu trúc log yêu cầu phải theo dõi dữ liệu thực sự được lưu trữ ở đâu. Chính vì thế mỗi file đều có quản lý đi kèm gọi là inode của file trong đó bất cứ thay đổi nào của file thì inode cũng thay đổi.Ngoài ra hệ quản lý file phân tán XFS còn có vô số các manager. Ví dụ như đươc minh họa bằng việc đọc một blog dữ liệu trong XFS Hình 41: Đọc một block dữ liệu trong XFS Naming Có một số cấu trúc dữ liệu và thực thể được sử dụng cho việc định vị của các manager, block, inode…như manager mape, imap,…. Caching Client trong XFS giữ block cache cục bộ và nó được dùng thay thế cho cache của file. Chịu lỗi Bằng việc thực thi các server lưu trữ thành các nhóm để duy trừ sự dư thừa, tính sẵn sàng của XFS được nâng lên. Khi một client bị lỗi nó có thể phục hồi một phần bằng phần parity được lưu trữ trong một server khác, nếu như mà fragment parity bị mất thì nó cũng dễ dàng được tính tóan lại nhờ các fragment khác. Quản lý phục hồi được thực hiện bởi các điểm checkpoint dữ liệu được manager lưu trữ. Một vấn đề khó đó là phục hồi lại imap của manager, chính vì thế client theo dõi các thay đổi chúng gửi cho manager tại điểm checkpoint cuối cùng, bằng cách này manager có thể yêu cầu client thực hiện lại thay đổi cuối cùng và imap của nó cũng sẽ nhất quán với thông tin trong server lưu trữ. Bảo mật Bên cạnh việc thực hiện các cơ chế điều khiển truy nhập, XFS yêu cầu client, manager và server lưu trữ chạy trên các máy đáng tin cậy. 10.3.3 SFS Hệ thống file bảo mật (Secure File System)được thiết kế dựa trên nguyên tắc tách riêng các quản lý khóa từ bảo mật hệ thống file, nó đảm bảo rằng client không thể truy cập vào một file mà không có khóa bí mật. Hình 42 Tổ chức của SFS SFS đã tích hợp với các thành phần của NFS phiên bản 3. trên máy client có 3 thành phần khác nhau trong đó NFS client như là giao diện đối với user programe và trao đổi thông tin với SFS client. Tương tự như vậy đối với server . Truyền thông SFS client và server giao tiếp sử dụng định dạng của giao thức NFS phiên bản 3. Tiến trình SFS hoàn toàn độc lập khi mà user của nó truy cập SFS. Naming Không gian tên của SFS đã làm cho nó trở nên đặc biệt. SFS cung cấp không gian tên bắt đầu từ thư mục /sfs sau đó là đại chỉ LOC (tên DNS của server SFS) Bảo mật Để lấy được khóa của server, client liên lạc với server và yêu cầu server gửi khóa. 10.4 So sánh các hệ file phân tán Về mục đích thiết kế Mỗi hệ thống file phân tán khác nhau được thiết kế nhằm được các mục đích khác nhau. Với NFS, mục đích là hỗ trợ người dùng có thể truy cập các file được lưu trữ ở những server đặc biệt từ xa một cách trong suốt, trong bản NFS 4 còn phát triển lên mức truy cập trong suốt trên diện rộng và ẩn đi các kết nối. Với CODA mục đích là tạo ra một hệ thống có mức độ sẵn sàng đáp ứng cao nhất, ngay cả đổi với từng phần trong mạng và trong trường hợp mất kết nối tạm thời. Vì là phiên bản 2 của AFS nên CODA kế thừa những tính chất của AFS là khả năng mở rộng dễ dàng. Plan 9 là một hệ thống timesharing phân tán nền tảng file (file-base distributed system), trong đó, tài nguyên được truy nhập và xử lý theo những các giống như với file. XFS có mục đích thiết kế giống với nhiều hệ thống file phân tán khác là tính mở rộng và tính đáp ứng. Tuy nhiên mục đích quan trọng nhất của hệ thống này là việc giảm vai trò của server và chuyển một phần xuống client, ngay cả thực thể file phân tán cũng được lưu trữ cả ở client, đây là cách tiếp cận ngược lại với phần lớn các hệ thống file phân tán khác. SFS với mục đích có thể mở rộng các tính năng bảo mật. Communication Các hệ thống file phân tán thường dùng RPC làm phương thức giao tiếp. NFS, Coda, SFS sử dụng phương pháp này. Ngoài ra các hệ thống khác có những phương pháp riêng như Plan 9 và XFS Processes Ở NFS phiên bản 3 tiến trình ở phía client là “mỏng” – thin), nghĩa là các thao tác với file được thực hiện trên server, phía client chỉ thực hiện gọi. Trong khi ở phiên bản NFS 4, client process thực hiện nhiều hơn, nên có thể hiểu ở bản 4 client process là “dày” (fat). Trong Coda, Venus thực hiện rất nhiều thao tác với file ở phía client, hỗ trợ cache file để có thể đảm bảo ngay cả trong trường hợp mất kết nối. Vì thế trong Coda, client process là “dày”, fat process. Ngược lại trong Plan 9 lại thực hiện đơn giản tối đa những thao tác tại client. Còn trong XFS client không thao tác nhiều hơn server nhưng hệ thống này hỗ trợ cache phía client nên cũng là fat client process. SFS thiết kế phía client đơn giản hơn Coda nhưng phức tạp hơn Plan 9, nó được coi là client process ở mức trung bình – medium client process. Naming Trừ SFS các hệ thống file phân tán đều hỗ trợ không gian tên thông qua mounting giống như UNIX. Có hai cách tiếp cận: - Mỗi người dùng sử dụng không gian tên riêng như trong NFS hoặc Plan 9 - Hoặc sử dụng một không gian tên chung, chia sẻ như trong Coda, xFS hay SFS Cũng có một số khác biệt trong việc tham chiếu file. Chỉ có Coda và xFS sử dụng tham chiếu file duy nhất. Trong Coda, file được tham chiếu gồm có hai phần, phần thứ nhất để xác định vị trí ổ, phần sau là định danh duy nhất của file trên ổ đó. Ghép hai phần này lại sẽ được một tên duy nhất trong hệ thống. Synchronization NFS cung cấp cách thức chia sẻ file dạng phiên (session – semantics), có nghĩa là chỉ những cập nhật của tiến trình đóng file sau cùng là được ghi lại bởi server. Trong Coda, một phương thức chia sẻ file dạng giao tác tạo cảm giác các phiên là tuần tự, trong khi thực tế chúng song song với nhau. Điều này có thể tạo nên những xung đột nhất định và vì vậy cần xử lý những xung đột nảy sinh này. Trong Plan 9 và XFS sử dụng UNIX – semantics. SFS không có một semantic đặc biệt. Tuy nhiên vì nó dựa trên giao thức NFS, nên ít nhất nó cũng đã sử dụng session – semantics. Caching và Replication Trong các hệ thống đã trình bày đều hỗ trợ caching phía client. Chỉ Plan 9 là dùng cache dạng ghi xuyên (write throught) còn các hệ thống khác sử dụng write-back. XFS cache block còn các hệ thống khác dùng file. Fault Tolerance NFS chịu lỗi bằng cách sử dụng phương thức truyền thông tin cậy và phục hồi dựa trên log client. Coda sử dụng caching và sao lưu phía client để có thể thực hiện việc kết hợp lại với hệ thống khi bị mất kết nối. XFS sử dụng Checkpoint và log ghi tại client để thực hiện phục hồi. Security NFS phiên bản 4 tách biệt giữa cơ cấu bảo mật và việc thực thi cơ cấu bảo mật. NFS cung cấp những giao diện chuẩn cho các kênh bảo mật theo dạng RPCSEC_GSS. Coda và Plan 9 bảo mật dựa trên giao thức chứng thực Needham-Schroeder. SFS sử dụng cách riêng để bảo mật. Một agent đặc biệt được sử dụng để xác thực người dùng với server. 10.5 KẾT LUẬN Hệ thống file phân tán là một mô hình quan trọng cho việc xây dựng các hệ thống phân tán. Chúng được xây dựng, tổ chức hoạt động theo mô hình client-server, trong đó phía client thực hiện caching và hỗ trợ việc sao lưu ở server để đảm bảo các yêu cầu mở rộng. Thêm vào đó, việc cache và sao lưu giúp tăng khả năng đáp ứng của hệ thống. Điều tạo nên sự khác biệt giữa hệ thống file phân tán với hệ thông file không phân tán kà ở ý nghĩa của việc chia sẻ file. Một cách lý tưởng, một hệ thống file phải cho phép người dùng đọc và ghi dữ liệu vào file. Cách chia sẻ file theo cách hiểu như UNIX rất khó để thực hiện hiệu quả trong một hệ phân tán. NFS sử dụng cách hiểu kiểu phiên còn Coda sử dụng cách hiểu kiểu giao tác.Trong trường hợp Server nắm các quyền điều khiển và thao tác với file, có thể thực thi theo Unix semantics, tuy nhiên việc mở rộng sẽ khó khăn. Để tăng hiệu năng các hệ thống file phân tán sử dụng việc cache các thực thể file. Đó là cách tiếp cận của NFS, và Coda, mặc dù các hệ thống này cũng hỗ trợ lưu trữ theo các khôi lớn của file. Một file có thể được mở và chuyển xuống client toàn bộ hoặc từng phần. Việc cập nhật và đẩy lên server khi file được đẩy lên server. Các hệ thống như Plan 9, xFS sử dụng block caching và giao thức write-back. Coda là hệ thống file phân tán hỗ trợ các thao tác khi không kết nối, bằng cách sử dụng cache tại client. Bảo mật là rất quan trọng trong các hệ thống phân tán, bao gồm cả hệ thống file phân tán.... Tài liệu tham khảo Distributed System – Principles and Paradigm của Andreư S.Tanenbaum and Maaten van Steen. Lý thuyết cơ sở dữ liệu phân tán: Ts Nguyễn Trung NFS version 4 protocol File System and NFS The CODA File System Plan 9 file system