Giao thức chia sẻ tập tin mạng nào có hiệu suất và độ tin cậy tốt nhất? [đóng cửa]

Chúng tôi có một thiết lập với một vài máy chủ web được cân bằng tải. Chúng tôi muốn có một số loại lưu trữ chia sẻ mạng mà tất cả các máy chủ web có thể truy cập. Nó sẽ được sử dụng như một nơi để lưu trữ các tập tin được tải lên bởi người dùng. Mọi thứ đều chạy Linux.

Có nên sử dụng NFS, CIFS, SMB, cầu chì + sftp, cầu chì + ftp? Có rất nhiều lựa chọn cho các giao thức chia sẻ tệp mạng, rất khó để chọn một giao thức. Về cơ bản, chúng tôi chỉ muốn gắn kết vĩnh viễn phần này trên nhiều máy. Các tính năng bảo mật ít được quan tâm hơn vì nó sẽ không thể truy cập mạng từ bất kỳ nơi nào khác ngoài các máy chủ lắp đặt nó. Chúng tôi chỉ muốn nó hoạt động đáng tin cậy và nhanh chóng.

Chúng ta nên sử dụng cái nào?

Tôi bỏ phiếu cho NFS.

NFSv4.1 đã thêm khả năng Parallel NFS pNFS, giúp truy cập dữ liệu song song có thể. Tôi đang tự hỏi loại khách hàng nào đang sử dụng bộ lưu trữ nếu chỉ có Unix giống như vậy thì tôi sẽ sử dụng NFS dựa trên các số liệu hiệu suất.

Câu trả lời ngắn gọn là sử dụng NFS. Theo loạt đá luân lưu này và kinh nghiệm của riêng tôi, nó nhanh hơn.

Nhưng, bạn có nhiều lựa chọn hơn! Bạn nên xem xét một cụm FS như GFS, một hệ thống tệp mà nhiều máy tính có thể truy cập cùng một lúc. Về cơ bản, bạn chia sẻ một thiết bị khối thông qua iSCSI là hệ thống tệp GFS. Tất cả các máy khách (người khởi xướng theo cách nói của iSCSI) có thể đọc và ghi vào nó. Redhat có một whitepaper . Bạn cũng có thể sử dụng cụm FS OCFS của oracle để quản lý điều tương tự.

Bài báo làm lại một công việc tốt liệt kê những ưu và nhược điểm của cụm FS so với NFS. Về cơ bản nếu bạn muốn có nhiều chỗ để mở rộng quy mô, GFS có lẽ đáng để nỗ lực. Ngoài ra, ví dụ GFS sử dụng SAN Kênh sợi làm ví dụ, nhưng đó có thể dễ dàng là RAID, DAS hoặc iSCSI SAN.

Cuối cùng, hãy đảm bảo xem xét Khung Jumbo và nếu tính toàn vẹn dữ liệu là quan trọng, hãy sử dụng kiểm tra CRC32 nếu bạn sử dụng iSCSI với Khung Jumbo.

Chúng tôi có một cụm web tải 2 máy chủ tải. Chúng tôi đã thử các phương pháp sau để đồng bộ hóa nội dung giữa các máy chủ:

• Ổ đĩa cục bộ trên mỗi máy chủ được đồng bộ hóa với RSYNC cứ sau 10 phút
• Một CIFS trung tâm (SAMBA) chia sẻ cho cả hai máy chủ
• Một chia sẻ NFS trung tâm cho cả hai máy chủ
• Một ổ đĩa SAN được chia sẻ chạy OCFS2 gắn cả hai máy chủ

Các RSYNC giải pháp là đơn giản nhất, nhưng cũng phải mất 10 phút để thay đổi xuất hiện và RSYNC đặt quá nhiều tải trọng trên máy chủ chúng tôi phải tăng tốc nó với kịch bản tùy chỉnh để tạm dừng nó mỗi giây. Chúng tôi cũng bị giới hạn chỉ ghi vào ổ đĩa nguồn.

Ổ đĩa được chia sẻ hiệu năng nhanh nhất là ổ đĩa cụm OCFS2 cho đến khi nó phát điên và làm hỏng cụm. Chúng tôi không thể duy trì sự ổn định với OCFS2. Ngay khi có nhiều hơn một máy chủ truy cập vào cùng một tệp, tải leo qua mái nhà và máy chủ bắt đầu khởi động lại. Đây có thể là một thất bại đào tạo về phía chúng tôi.

Tốt nhất tiếp theo là NFS . Nó đã được cực kỳ ổn định và chịu lỗi. Đây là thiết lập hiện tại của chúng tôi.

SMB (CIFS) đã có một số vấn đề về khóa. Cụ thể là các thay đổi đối với các tệp trên máy chủ SMB không được các máy chủ web nhìn thấy. SMB cũng có xu hướng bị treo khi bị lỗi trên máy chủ SMB

Kết luận của chúng tôi là OCFS2 có tiềm năng nhất nhưng đòi hỏi RẤT NHIỀU phân tích trước khi sử dụng nó trong sản xuất. Nếu bạn muốn một cái gì đó đơn giản và đáng tin cậy, tôi sẽ đề xuất một cụm máy chủ NFS với Heartbeat để chuyển đổi dự phòng.

Tôi đề nghị bạn POHMELFS - nó được tạo ra bởi lập trình viên người Nga Evgeniy Polyakov và nó thực sự rất nhanh.

Về độ tin cậy và bảo mật, có thể là CIFS (còn gọi là Samba) nhưng NFS "có vẻ" nhẹ hơn nhiều và với cấu hình cẩn thận, không thể để lộ hoàn toàn dữ liệu quý giá của bạn cho mọi máy khác trên mạng ;-)

Không xúc phạm đến những thứ FUSE, nhưng nó vẫn có vẻ ... mới mẻ, nếu bạn hiểu ý tôi. Tôi không biết nếu tôi tin tưởng nó chưa, nhưng đó có thể chỉ là tôi là một người sương mù cũ, nhưng chủ nghĩa sương mù cũ đôi khi được bảo đảm khi nói đến dữ liệu doanh nghiệp có giá trị.

Nếu bạn muốn gắn vĩnh viễn một chia sẻ trên nhiều máy và bạn có thể chơi cùng với một số điều kỳ lạ (chủ yếu là các vấn đề về UID / GID), thì hãy sử dụng NFS. Tôi sử dụng nó, và có nhiều năm.

NFS. Điều đó đã được thử và đúng, và bạn có thể có một thiết lập vững chắc. Hiệu suất GFS nói chung là khủng khiếp, đặc biệt là trên các hệ thống tệp có số lượng lớn tệp nhỏ. Tôi đã không sử dụng OCFS, nhưng tôi thường cau mày với khái niệm hệ thống tập tin cụm. Sau đó, có Luster, nhưng đó là một con giun khác ...

Tôi sẽ khuyên chống lại NFS. Nói một cách đơn giản - chúng tôi đã có một trang trại máy chủ web, với JBoss, Apache, Tomcat và Oracle đều sử dụng cổ phiếu NFS cho các tệp cấu hình phổ biến và ghi nhật ký.

Khi chia sẻ NFS biến mất (phải thừa nhận là một sự cố hiếm gặp), toàn bộ sự việc đã sụp đổ (thực sự có thể dự đoán được và tôi đã khuyên các 'nhà phát triển' chống lại lối tắt thời gian cấu hình này).

Dường như có một vấn đề với phiên bản NFS mà chúng tôi đang sử dụng, nếu mục tiêu biến mất trong quá trình ghi, máy khách sẽ rơi vào vòng chờ không bao giờ kết thúc, chờ đợi mục tiêu NFS quay trở lại. Ngay cả khi hộp NFS được gắn lại - vòng lặp vẫn không kết thúc.

Chúng tôi đã sử dụng hỗn hợp của RHEL 3,4,5. Lưu trữ là trên RHEL4, các máy chủ nằm trên RHEL5, mạng lưu trữ là một lan riêng biệt và không chạy trên vlans.

Nếu có một mặt trước cân bằng tải, kiểm tra bộ nhớ duy nhất - điều này sẽ không làm tắc nghẽn hệ thống của bạn?

Bạn đã xem xét kết nối iSCSI chỉ đọc vào bộ lưu trữ của mình chưa, với tập lệnh hướng sự kiện để di chuyển tệp đã tải lên lưu trữ qua ftp / scp khi tệp được tải lên?

Lần duy nhất tôi thực hiện lưu trữ tập trung thành công cho nhiều đầu đọc là trên mảng lưu trữ EMC ... Tất cả các nỗ lực hiệu quả về chi phí khác đều có nhược điểm.

Được coi là GFS? GFS là một hệ thống tập tin cụm, và theo kinh nghiệm của tôi, là khá đáng tin cậy. Nó có thể có nhiều hơn một tạp chí, nó có quy mô khá tốt

Nhưng bạn sẽ cần cài đặt một số dịch vụ cụm và GFS không biết chính xác về tốc độ của nó. Otoh, nó luôn luôn đủ nhanh đối với tôi, nhưng ymmv.

Bạn sẽ mất trí khi xem xét một FS phân tán như GFS và iSCSI là quá mức cần thiết.

Nếu bạn muốn đơn giản, hãy đi với NFS. Nó đơn giản và nhanh chóng, và với các giá treo mềm khá mạnh mẽ. Cũng xem xét việc vô hiệu hóa tất cả các rác khóa đi cùng với nó. Tôi có máy tính để bàn Linux lấy tất cả các thư mục và ứng dụng nhà của họ từ NFS, nó hoạt động tốt.

Nếu bạn muốn tốc độ vượt trội, hãy sử dụng Luster, dễ dàng hơn đáng kể so với GFS để thiết lập và rất giống với RAID NFS. Chúng tôi sử dụng Luster cho các cụm của chúng tôi.

Tôi có thể hơi muộn một chút Vì HDD, FAN, Bộ nguồn và Bộ điều khiển đều là Hotswap, chúng tôi thay thế các bộ phận vào và ra. Theo định dạng, chúng tôi sử dụng NFS.

Nếu bạn đã có máy chủ web ở khắp mọi nơi và giỏi chạy chúng, tại sao không xem xét WebDAV?

Câu trả lời đơn giản +1 cho NFS. Tôi có cổ phiếu NFS đã được gắn kết trong nhiều năm mà không có vấn đề.

Nếu bạn đang tìm kiếm độ tin cậy siêu cao thì hãy cân nhắc việc ném DRBD vào hỗn hợp cũng như cho một hệ thống tập tin NFS phân tán, tự động chuyển đổi.

Tùy chọn duy nhất khác (mà tôi quen thuộc) là iSCSI nhưng có thể gây khó khăn cho việc cấu hình ...

Bạn có một loạt các tùy chọn, với nhiều loại chi phí. SAN được chia sẻ với FC, iSCSI hoặc một trong những bổ sung gần đây. Trong mọi trường hợp, chúng có thể tốn kém để thiết lập và bạn vẫn cần chạy hệ thống tệp nhận biết cụm. Hệ thống tập tin cụm là một thế giới của nỗi đau. Đối với bất kỳ hy vọng thành công nào, bạn cần có mạng tốc độ cao, độ trễ thấp để truyền dữ liệu và dữ liệu cụm. Ngay cả với điều đó, bạn có khả năng nhận được các trục trặc dẫn đến một nút bị rào và bị giết.

Hệ thống tệp cụm duy nhất tôi gặp phải chỉ hoạt động mà không gặp rắc rối là VMFS. Nhưng đó là chuyên ngành, nó sẽ không được sử dụng ngay cả khi nó có sẵn cho sử dụng chung.

NFS có lẽ là cách để thiết lập của bạn. Nếu bạn lo lắng về khả năng phục hồi, bạn cần có một hộp NFS được phân cụm thích hợp. Bạn có thể thực hiện thiết lập homebrew, nhưng sẽ gặp phải vấn đề trên. Đặt cược tốt nhất (nếu bạn có tiền), được nhóm NetApp quay. Đó là một lựa chọn đắt tiền, nhưng việc phân cụm thực sự hoạt động mà không gặp rắc rối nào. Không chỉ vậy, họ còn rất nhanh.

Tôi sẽ lặp lại cảnh báo mà một số người đã đưa ra chống lại NFS - mặc dù NFS có lẽ là đặt cược tốt nhất của bạn (lạ như âm thanh đó).

Tôi đã có một máy khách NFS mà tôi phải ngắt kết nối khỏi AC để tắt vì máy chủ NFS đã biến mất và máy khách từ chối (trong kernel) để mở khóa hoặc tắt máy vì máy chủ NFS đã biến mất.

Để làm điều đó đúng, tôi sẽ nhấn mạnh vào NFSv4 trong suốt, gắn bó với các kết nối TCP, sử dụng các khung jumbo và sử dụng một cụm NFS. Bạn không đủ khả năng để máy chủ NFS của bạn biến mất.

GFS là một số voodoo đen nghiêm trọng. Số lượng công việc cần thiết để có được một cụm khách hàng đơn giản làm việc là đáng kinh ngạc so với các lựa chọn thay thế. OCFS2 đơn giản hơn rất nhiều để triển khai nhưng rất kén chọn khi nói đến các phiên bản mô-đun hạt nhân liên quan đến tất cả các máy chủ đính kèm - và đó mới chỉ là khởi đầu.

Trừ khi bạn thực sự cần loại truy cập cấp thấp mà hệ thống tập tin cung cấp, NFS hoặc CIFS có thể là tất cả những gì bạn cần.

Trong một trang trại máy chủ lớn, chúng tôi đã có vài triệu người dùng tạo các trang html. NFS đã không hoạt động tốt như vậy nên cuối cùng chúng tôi đã đưa chúng vào một bảng mysql. Chi phí hoạt động so với duyệt qua cây thư mục là như nhau.

Tôi đã sử dụng SFTP và nó hoạt động tốt cho mục đích của tôi - NFS là khu nghỉ mát đầu tiên của tôi nhưng sự thú vị của ID người dùng / nhóm khiến tôi bỏ nó khá nhanh.

Chỉ cần thiết lập autkey công khai và phần lớn bạn sẽ được thiết lập. Có thể có một chi phí CPU nặng hơn một chút cho mã hóa SSH, nhưng về mặt tích cực, tôi chưa bao giờ gặp phải bất kỳ vấn đề nào với hỏng dữ liệu.

FTP cũng có thể phù hợp với mục đích của bạn, vì nó nhẹ hơn. Có lẽ bạn muốn máy chủ web của bạn đang phục vụ web chứ không phải công việc ssh.