AFP, SMB, NFS là giao thức truyền dữ liệu tốt nhất?


14

Tôi có một máy tính với các đĩa cứng lớn chạy Gentoo. Tôi phải phân phát các tệp med / big qua mạng có dây cho các thiết bị của Apple (tất cả chúng đều chạy OS X).

Giao thức nào là tốt nhất cho các nhu cầu sau đây? :

  1. Tốc độ
  2. Dễ sử dụng (bởi khách hàng và máy chủ)
  3. Ít giới hạn hơn (kích thước tệp tối đa, bảng mã giới hạn cho tên tệp)
  4. Bảo vệ

Câu trả lời:


7

Bạn sẽ thấy bài viết này thú vị: hiệu năng
iSCSI, AFP, SMB và NFS với các máy khách Mac OS X 10.5.5 .

Nó cho thấy những kết quả kiểm tra:

(trong vài giây)

iSCSI 134.267530
AFP 140.285572
SMB 159.061026
NFSv3 (điều chỉnh w / o) 477.432503
NFSv3 (w / chỉnh) 293.994605


Cảm ơn cho bài viết nó rất hữu ích! Tôi có thể nói rằng trong trường hợp của tôi, AFP sẽ nhanh hơn và dễ sử dụng hơn những cái khác không?
Kami

3
Các kết quả NFS v3 được báo cáo là khá tệ hại. Trong công việc vừa phải của tôi tối ưu hóa thông lượng cho khách hàng, NFS có xu hướng nhanh gấp đôi hoặc nhiều hơn SMB. Với một máy chủ, một máy chủ lưu trữ trên mạng gigabit không có lưu lượng truy cập khác, tôi có thể nhận được 900 megabit mỗi giây cho NFS khi CIFS đấu tranh vượt qua 250. Chắc chắn đó không phải là thông lượng trong thế giới thực bền vững và không làm mất hiệu lực các thử nghiệm này mỗi se, nhưng làm cho tôi khá nghi ngờ về kết quả.
Jon Lasser

@Jon Lasser: Rắc rối với các thử nghiệm như vậy là chúng thường chỉ đúng với phần cứng được sử dụng VÀ bản chất của thử nghiệm. Nói chung, họ tốt nhất chỉ là các chỉ số yếu.
harrymc

@Kami: Tôi không thể trả lời điều đó, theo nhận xét của tôi ở trên cho Jon Lasser. Nếu bạn có thời gian, bạn có thể thử sao chép các kết quả kiểm tra này trên phần cứng của mình. Nếu chúng khác nhau theo bất kỳ cách nào, nó có thể thú vị cho bạn để xuất bản nó ở đây.
harrymc

7

Tôi đã thực hiện một số thử nghiệm phi khoa học trong thế giới thực về tốc độ i / o của iscsi và các giao thức mạng khác nhau trong OS X.

Thiết lập của tôi:

  • Đầu năm 2011 MPB chạy OS X 10.7 Lion, được kết nối với bộ chuyển đổi gigabit Netgear
  • Qnap TS-419P II NAS với 4 đĩa trong RAID5, được kết nối với bộ chuyển đổi gigabit Netgear
  • Buffalo LinkStation Pro NAS với 1 đĩa, được kết nối với bộ chuyển đổi gigabit Netgear
  • Công cụ khởi tạo iSCSI toàn cầu cho OS X đã được sử dụng cho các thử nghiệm iSCSI

Thử nghiệm được thực hiện bằng cách sao chép (cp) khoảng 2gb tệp thô của máy ảnh (mỗi tệp có kích thước khoảng 20-25mb) vào thiết bị, khởi động lại thiết bị và sao chép cùng một dữ liệu vào ổ SSD cục bộ.

Viết hiệu suất:

  1. Qnap, Async NFS = 34,59 mb / s
  2. Qnap, AFP = 31,83 mb / s
  3. Qnap, ISCSI = 31,89 mb / s
  4. * Qnap, SMB, cp = 30,71 mb / s
  5. Qnap, NFS = 27,22 mb / s
  6. Trâu, AFP = 10,07 mb / s
  7. * Qnap, SMB, mv = 3,93 mb / s

*) Chỉ khi sử dụng SMB, tôi mới nhận được kết quả thực hiện ghi rất khác so với sao chép tệp vào thiết bị bằng lệnh cp hoặc mv!

Cài đặt tùy chọn async cho NFS cải thiện đáng kể hiệu suất đọc. Tôi sử dụng lệnh mount sau đây để kiểm tra:

mount -t nfs -o resvport,soft,intr,rsize=32768,wsize=32768,timeo=900,retrans=3,proto=tcp,vers=3,async server:/share /private/share/

Đọc hiệu suất:

  1. Qnap, Async NFS = 71,99 mb / s
  2. Qnap, AFP = 67,44 mb / s
  3. Qnap, ISCSI = 60,22 mb / s
  4. Qnap, NFS = 46,51 mb / s
  5. Qnap, SMB = 35,82 mb / s
  6. Trâu, AFP = 5,46 mb / s

Các giao thức dường như xử lý bộ nhớ đệm khác nhau. Đây là kết quả tôi nhận được khi sao chép tệp vào thiết bị và ngay lập tức quay lại ổ SSD cục bộ (không khởi động lại thiết bị)

Đọc hiệu suất - không cần khởi động lại

  1. Qnap, ISCSI = 151,71 mb / s
  2. Trâu, AFP = 145,54 mb / s
  3. Qnap, AFP = 143,23 mb / giây
  4. Qnap, Async NFS = 71,99 mb / s
  5. Qnap, NFS = 47,37 mb / s
  6. Qnap, SMB = 38,13 mb / s

Kết luận của tôi: Tôi sẽ sử dụng AFP hoặc NFS vì cả hai giao thức đều cho hiệu năng và tính linh hoạt tương tự (so với iSCSI) cho mục đích của tôi (Lightroom, sao lưu, truyền phát phương tiện)


3

Mặc dù chúng là giao thức truyền dữ liệu, tôi muốn nhắc bạn rằng chúng không chấp nhận các ký tự giống như tên tệp. Ví dụ: \ /: *? Mùi <> | không được phép trong Windows NTFS và Samba.

Nó xảy ra với giao thức Apple Talk từ trải nghiệm của tôi trên MacOS 8.6 và Windows 95 chạy dịch vụ tương thích AppleTalk. Một số ký tự trong tên tệp được cho phép trong MacOS không hợp lệ với Windows.

Chi tiết về trải nghiệm của tôi khi sao chép các tệp từ Linux Desktop sang QNAP TS-212P chạy Samba và NFS có thể được tìm thấy trong So sánh hiệu suất trên các tệp Linux sao lưu sang QNAP TS-212P . Kết quả kiểm tra tính bằng MB / s cho những gì bạn quan tâm:

  1. Gắn kết Samba bằng lệnh trong thiết bị đầu cuối: Đọc 63, viết 43
  2. Gắn kết NFS bằng lệnh trong thiết bị đầu cuối: Đọc 71.8, viết 31.8

Tôi đã thực hiện một thử nghiệm với FTP, Samba, iSCSI và NFS trong Truyền tệp với Giải pháp chia sẻ khác nhau trên NAS với QNAP TS-112. Kết quả kiểm tra tính bằng MB / s cho những gì bạn quan tâm:

  1. Gắn kết Samba bởi Nautilus: Đọc 24.4, viết 18.6
  2. Gắn kết Samba bằng lệnh trong thiết bị đầu cuối: Đọc 56.4, viết 36.3
  3. Gắn kết NFS bằng lệnh trong thiết bị đầu cuối: Đọc 42.5, viết 20.6

Do đó, Samba nhanh hơn NFS từ kinh nghiệm của tôi. Nhưng một số tệp của tôi chứa các ký tự không hợp lệ trong NTFS và Samba, tôi chọn sử dụng NFS làm giao thức chính của mình.

Chúc nó giúp!


1

về cơ bản hầu hết các giao thức (nếu không phải tất cả) có thể được sử dụng trên bất kỳ nền tảng nào, nhưng một số trong số chúng là bản địa hơn thì một giao thức khác

  • SMB - PC
  • AFP - MAC
  • NFS - NIX

4
Được rồi tôi đã biết điều đó nhưng còn tốc độ, dễ sử dụng, hạn chế và bảo mật thì sao?
Kami

Thật ra điều đó khá hữu ích cho tôi.
Chris

Không chắc chắn lý do tại sao điều này sẽ được bỏ phiếu, ngoại trừ có thể đó là một đơn giản chạm; AFP có lợi thế trên Mac vì nó có trình điều khiển tốt nhất, hỗ trợ NFS của OS X không tốt và SMB tốt hơn trên các phiên bản OS X mới hơn. Vì vậy, một yếu tố lớn của hiệu suất là hỗ trợ giao thức ở cả hai đầu; Ví dụ, một NAS có trình điều khiển AFP tốt sẽ tốt nhất cho người dùng Mac trong hầu hết các trường hợp.
Harastak
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.