Protokol berbagi file jaringan apa yang memiliki kinerja dan keandalan terbaik? [Tutup]

Kami memiliki pengaturan dengan beberapa server web menjadi beban-seimbang. Kami ingin memiliki semacam penyimpanan bersama jaringan yang dapat diakses oleh semua server web. Ini akan digunakan sebagai tempat untuk menyimpan file yang diunggah oleh pengguna. Semuanya menjalankan Linux.

Haruskah kita menggunakan NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Ada begitu banyak pilihan di luar sana untuk protokol berbagi file jaringan, sangat sulit untuk memilih satu. Kami pada dasarnya hanya ingin me-mount share yang satu ini secara permanen di beberapa mesin. Fitur keamanan kurang menjadi perhatian karena tidak dapat diakses jaringan dari mana pun selain server yang memasangnya. Kami hanya ingin itu berfungsi dengan andal dan cepat.

Yang mana yang harus kita gunakan?

Saya memilih NFS.

NFSv4.1 menambahkan kemampuan NFS pNFS Paralel, yang memungkinkan akses data paralel. Saya bertanya-tanya klien seperti apa yang menggunakan penyimpanan jika hanya seperti Unix maka saya akan menggunakan NFS berdasarkan angka kinerja.

Jawaban singkatnya adalah menggunakan NFS. Menurut baku tembak ini dan pengalaman saya sendiri, lebih cepat.

Tapi, Anda punya lebih banyak opsi! Anda harus mempertimbangkan cluster FS seperti GFS, yang merupakan sistem file yang dapat diakses oleh banyak komputer sekaligus. Pada dasarnya, Anda berbagi perangkat blok melalui iSCSI yang merupakan sistem file GFS. Semua klien (pemrakarsa dalam bahasa iSCSI) dapat membaca dan menulis. Redhat punya whitepaper . Anda juga dapat menggunakan cluster Oracle OCFS oracle untuk mengelola hal yang sama.

Makalah redhat melakukan pekerjaan dengan baik daftar pro dan kontra dari cluster FS vs NFS. Pada dasarnya jika Anda ingin banyak ruang untuk skala, GFS mungkin sepadan dengan usaha. Juga, contoh GFS menggunakan Fibre Channel SAN sebagai contoh, tetapi itu bisa dengan mudah menjadi RAID, DAS, atau iSCSI SAN.

Terakhir, pastikan untuk melihat ke Frame Jumbo, dan jika integritas data sangat penting, gunakan CRC32 checksumming jika Anda menggunakan iSCSI dengan Frame Jumbo.

Kami memiliki 2 kluster web load-blanacing server. Kami telah mencoba metode berikut untuk menyinkronkan konten antara server:

• Drive lokal di setiap server disinkronkan dengan RSYNC setiap 10 menit
• CIFS pusat (SAMBA) berbagi ke kedua server
• Berbagi NFS pusat ke kedua server
• Drive SAN bersama yang menjalankan OCFS2 dipasang kedua server

The rsync solusi adalah yang paling sederhana, tapi butuh 10 menit untuk perubahan muncul dan rsync menempatkan begitu banyak beban pada server kami harus throttle dengan script khusus untuk pause setiap detik. Kami juga dibatasi hanya menulis ke drive sumber.

Drive bersama yang berperforma paling cepat adalah drive berkerumun OCFS2 sampai benar-benar menjadi gila dan membuat crash cluster. Kami belum dapat menjaga stabilitas dengan OCFS2. Segera setelah lebih dari satu server mengakses file yang sama, memuat tanjakan melalui atap dan server mulai reboot. Ini mungkin kegagalan pelatihan bagi kami.

Yang terbaik berikutnya adalah NFS . Sudah sangat stabil dan toleran terhadap kesalahan. Ini adalah pengaturan kami saat ini.

SMB (CIFS) memiliki beberapa masalah penguncian. Secara khusus perubahan pada file di server SMB tidak terlihat oleh server web. SMB juga cenderung hang ketika gagal melewati server SMB

Kesimpulan kami adalah bahwa OCFS2 memiliki potensi paling besar tetapi membutuhkan BANYAK analisis sebelum menggunakannya dalam produksi. Jika Anda menginginkan sesuatu yang mudah dan dapat diandalkan, saya akan merekomendasikan cluster server NFS dengan Heartbeat untuk failover.

Saya sarankan Anda POHMELFS - ini dibuat oleh programmer Rusia Evgeniy Polyakov dan itu sangat, sangat cepat.

Dalam hal keandalan dan keamanan, mungkin CIFS (alias Samba) tetapi NFS "tampaknya" jauh lebih ringan, dan dengan konfigurasi yang cermat, mungkin untuk tidak sepenuhnya memaparkan data berharga Anda ke setiap mesin lain di jaringan ;-)

Tidak menghina hal-hal SEKERING, tetapi masih tampak ... segar, jika Anda tahu apa yang saya maksud. Saya tidak tahu apakah saya masih mempercayainya, tapi itu bisa saja saya menjadi fog lama, tetapi fogeyisme lama kadang-kadang diperlukan dalam hal data perusahaan yang berharga.

Jika Anda ingin me-mount satu share secara permanen di beberapa mesin, dan Anda dapat bermain bersama dengan beberapa keanehan (kebanyakan masalah UID / GID), kemudian gunakan NFS. Saya menggunakannya, dan sudah bertahun-tahun.

NFS. Sudah dicoba dan benar, dan Anda dapat memiliki pengaturan yang kokoh. Kinerja GFS umumnya mengerikan, terutama pada sistem file dengan sejumlah besar file kecil. Saya belum pernah menggunakan OCFS, tapi saya umumnya tidak menyukai konsep sistem file cluster. Lalu ada Lustre, tapi itu sekaleng cacing ...

Saya akan menyarankan terhadap NFS. Sederhananya - kami memiliki server web farm, dengan JBoss, Apache, Tomcat dan Oracle semuanya menggunakan saham NFS untuk file konfigurasi umum, dan pencatatan.

Ketika berbagi NFS menghilang (diakui kejadian langka) semuanya hanya runtuh (benar-benar dapat diprediksi, dan saya menyarankan 'devlopers' terhadap pintasan waktu konfigurasi ini).

Tampaknya ada masalah dengan versi NFS yang kami gunakan itu, jika target menghilang selama penulisan, klien akan jatuh ke loop menunggu yang tidak pernah berakhir, menunggu target NFS untuk kembali. Bahkan jika kotak NFS dipasang kembali - loop masih tidak berakhir.

Kami menggunakan campuran RHEL 3,4,5. Penyimpanan ada di RHEL4, server ada di RHEL5, jaringan penyimpanan adalah lan yang terpisah, dan tidak berjalan di vlan.

Jika ada front end beban seimbang, memeriksa penyimpanan tunggal - bukankah ini akan menghambat sistem Anda?

Sudahkah Anda mempertimbangkan koneksi iSCSI baca-saja ke penyimpanan Anda, dengan skrip yang digerakkan oleh peristiwa untuk memindahkan file yang diunggah ke penyimpanan melalui ftp / scp ketika file diunggah?

Satu-satunya saat saya menerapkan penyimpanan terpusat yang berhasil untuk banyak kepala baca adalah pada larik penyimpanan EMC ... Semua upaya lain yang hemat biaya memiliki kelemahan.

Dianggap sebagai GFS? GFS adalah sistem file cluster, dan menurut pengalaman saya, cukup dapat diandalkan. Ini dapat memiliki lebih dari satu jurnal, berskala cukup baik

Tetapi Anda perlu menginstal beberapa layanan cluster dan GFS tidak tahu persis karena kecepatannya. Otoh, selalu cukup cepat bagiku, tapi ymmv.

Anda akan keluar dari pikiran Anda untuk mempertimbangkan FS terdistribusi seperti GFS, dan iSCSI berlebihan.

Jika Anda ingin pergi sederhana dengan NFS. Ini sederhana dan cepat, dan dengan soft mount yang cukup kuat. Juga pertimbangkan untuk menonaktifkan semua sampah pengunci yang menyertainya. Saya memiliki desktop Linux yang mengambil semua direktori home dan aplikasi dari NFS, itu berfungsi dengan baik.

Jika Anda ingin kecepatan yang luar biasa, gunakan Lustre, yang secara signifikan lebih mudah daripada GFS untuk mengatur dan sangat mirip dengan RAID NFS. Kami menggunakan Lustre untuk kelompok kami.

Saya mungkin sedikit terlambat, Kami menggunakan MD3220 Dell Storage yang memiliki cluster port ganda, Unit kami memiliki 2 pengontrol dan satu turun kedua akan terus berjalan sampai kami memperbaiki masalah itu. Karena HDD, KIPAS, Catu daya, dan Pengendali semuanya adalah Hotswap, kami mengganti komponen yang masuk dan keluar. Pada Format kami menggunakan NFS.

Jika Anda sudah memiliki server web di mana-mana dan pandai menjalankannya, mengapa tidak mempertimbangkan WebDAV?

Jawaban sederhana +1 untuk NFS. Saya memiliki saham NFS yang telah dipasang selama bertahun-tahun tanpa masalah.

Jika Anda mencari keandalan super maka pertimbangkan untuk memasukkan DRBD ke dalam campuran juga untuk sistem file NFS yang dibagikan secara otomatis.

Satu-satunya pilihan lain (yang saya kenal) adalah iSCSI tetapi bisa menyusahkan di belakang untuk mengkonfigurasi ...

Anda memiliki banyak opsi, dengan berbagai biaya. SAN bersama dengan FC, iSCSI atau salah satu tambahan yang lebih baru. Bagaimanapun mereka bisa mahal untuk diatur dan Anda masih perlu menjalankan sistem file cluster aware. Filesystem yang terkluster adalah dunia yang menyakitkan. Untuk setiap harapan sukses, Anda memerlukan jaringan hi rendah, latensi rendah untuk komunikasi dan data cluster. Bahkan dengan itu Anda cenderung mendapatkan gangguan yang menghasilkan simpul yang dipagari dan terbunuh.

Satu-satunya sistem file cluster yang saya temui yang hanya berfungsi tanpa kerumitan adalah VMFS. Tapi itu sangat khusus, tidak akan ada gunanya bahkan jika itu tersedia untuk penggunaan umum.

NFS mungkin adalah cara untuk mengatur Anda. Jika Anda khawatir tentang ketahanan, Anda perlu mendapatkan kotak NFS berkerumun yang tepat. Anda dapat melakukan pengaturan homebrew, tetapi akan menemukan masalah di atas. Taruhan terbaik (jika Anda punya uang), adalah para pengumpul NetApp. Ini pilihan yang mahal, tetapi pengelompokan sebenarnya berfungsi tanpa kesulitan. Tidak hanya itu, mereka sangat cepat.

Saya akan mengulangi peringatan yang diberikan terhadap NFS - meskipun NFS mungkin merupakan taruhan terbaik Anda (aneh kedengarannya).

Saya punya klien NFS yang harus saya putuskan dari AC untuk dimatikan karena server NFS telah menghilang dan klien menolak (di kernel) untuk membuka atau mematikan karena server NFS hilang.

Untuk melakukannya dengan benar, saya akan menuntut seluruh NFSv4, tetap dengan koneksi TCP, gunakan frame jumbo, dan gunakan cluster NFS. Anda tidak bisa membiarkan server NFS Anda menghilang.

GFS adalah beberapa voodoo hitam serius. Jumlah pekerjaan yang diperlukan untuk mendapatkan dua kluster klien yang sederhana bekerja sangat mengejutkan dibandingkan dengan alternatifnya. OCFS2 jauh lebih mudah untuk digunakan tetapi sangat pilih-pilih ketika menyangkut versi modul kernel yang terlibat pada semua server yang terhubung - dan itu baru permulaannya.

Kecuali Anda benar-benar membutuhkan jenis akses tingkat rendah yang ditawarkan filesystem cluster, NFS atau CIFS mungkin adalah semua yang Anda butuhkan.

Di server server besar kami memiliki beberapa juta pengguna membuat halaman html. NFS tidak berfungsi dengan baik sehingga kami akhirnya menempatkan mereka di tabel mysql. Overhead dibandingkan dengan melintasi pohon direktori hampir sama.

Saya telah menggunakan SFTP dan itu berfungsi dengan baik untuk tujuan saya - NFS adalah pilihan pertama saya tetapi keasyikan dari ID pengguna / grup membuat saya menjatuhkannya dengan cepat.

Cukup atur publickey auth dan Anda sebagian besar akan disetel. Mungkin ada overhead CPU yang agak lebih berat untuk enkripsi SSH, tetapi di sisi positifnya saya tidak pernah mengalami masalah dengan korupsi data.

FTP dapat cocok dengan keperluan Anda, karena lebih ringan. Mungkin Anda ingin server web Anda melakukan penyajian web, bukan pekerjaan ssh.