Sistem file yang terdistribusi secara geografis dengan lokasi yang disukai

Saya sedang membangun aplikasi yang perlu mendistribusikan server file standar di beberapa situs melalui WAN. Pada dasarnya, setiap situs perlu menulis banyak file misc dengan ukuran yang bervariasi (beberapa di kisaran 100-an MB, tetapi yang paling kecil), dan aplikasi ditulis sedemikian rupa sehingga tabrakan tidak menjadi masalah. Saya ingin memiliki pengaturan sistem yang memenuhi kualifikasi berikut:

1. Setiap situs dapat menyimpan file dalam "namespace" bersama. Artinya, semua file akan muncul di sistem file yang sama.
2. Setiap situs tidak akan mengirim data melalui WAN kecuali diperlukan. Yaitu, akan ada penyimpanan lokal di setiap sisi WAN yang akan "digabungkan" ke sistem file logis yang sama.
3. Linux & Gratis ($$$) adalah Plus

Pada dasarnya, sesuatu seperti pusat NFS akan memenuhi sebagian besar persyaratan, namun itu tidak akan membiarkan data yang ditulis secara lokal tetap lokal. Semua data dari sisi remote WAN akan disalin secara lokal setiap saat.

Saya telah melihat ke dalam Lustre, dan telah menjalankan beberapa tes yang berhasil dengannya, namun, tampaknya mendistribusikan file dengan cukup merata di seluruh penyimpanan terdistribusi. Saya telah menggali melalui dokumentasi dan belum menemukan apa pun yang secara otomatis akan "lebih suka" penyimpanan lokal daripada penyimpanan jarak jauh. Bahkan sesuatu yang pergi dengan penyimpanan latensi terendah akan baik-baik saja. Itu akan bekerja sebagian besar waktu, yang akan memenuhi persyaratan aplikasi ini.

Beberapa jawaban untuk beberapa pertanyaan yang diajukan di bawah ini:

• Node server: 2 atau 3 untuk memulai. Setiap server akan memiliki lusinan klien baca / tulis simultan yang terhubung.
• Topologi WAN adalah mesh penuh dan dapat diandalkan. (perusahaan besar, biaya tidak sebatas pita merah)
• Kegagalan klien: Saya sebenarnya tidak berpikir tentang kegagalan klien (kebanyakan karena aplikasi kami saat ini tidak melakukan ini di satu situs). Saya kira jawaban praktiknya adalah bahwa server di setiap situs yang didistribusikan secara geografis diharapkan menjadi titik kegagalan tunggal bagi klien yang mereka layani. Padahal, jika Anda berpikir tentang sesuatu yang spesifik di sini, saya pikir itu akan sangat erat dengan diskusi.
• Roll-my-own: Saya sudah memikirkan rsync / unison, namun saya akan memerlukan sedikit logika mewah untuk membuat bagian "dinamis" dari pekerjaan ini mulus. Yaitu, file tampaknya bersifat lokal, tetapi hanya diambil berdasarkan permintaan.
• MS-DFS: Tampaknya memang sesuatu yang harus saya perhatikan. Masalah utama saya mungkin berpotensi menjadi tidak yakin tentang konfigurasi server NFS / keandalan / kinerja pada Windows, karena banyak klien yang terhubung adalah klien NFS.

Malu tentang persyaratan Linux. Inilah yang dilakukan Windows DFS. Sejak 2003 R2, ia melakukannya atas dasar level blok juga.

Beberapa pertanyaan:

• Berapa banyak "server" yang Anda pikirkan untuk berpartisipasi dalam hal ini?

• Seperti apa topologi konektivitas WAN - hub dan bicara, full mesh? Seberapa andal itu?

• Apakah Anda mengharapkan klien untuk failover ke server geografis non-lokal jika server lokal gagal?

Windows DFS-R pasti akan apa yang Anda cari, meskipun untuk beberapa biaya lisensi berpotensi besar dan kuat.

Anda mengatakan bahwa tabrakan bukan masalah dan Anda tidak memerlukan manajer kunci terdistribusi, sehingga Anda bisa melakukan ini dengan alat-alat pengguna seperti rsync atau Unison dan hanya mengekspor kumpulan file yang dihasilkan dengan NFS ke klien lokal. Ini jelek, dan Anda harus menangani mengetuk beberapa jenis sistem untuk menangani menghasilkan topologi replikasi dan benar-benar menjalankan alat-alat pengguna, tetapi tentu saja akan murah karena biaya lisensi berjalan.

Sudahkah Anda mempertimbangkan AFS ?

Andrew File System (AFS) adalah sistem file jaringan terdistribusi yang menggunakan satu set server tepercaya untuk menghadirkan ruang nama file yang homogen dan transparan-lokasi untuk semua workstation klien.

Seperti yang saya pahami, sebagian besar perkembangan terakhir berada di belakang proyek OpenAFS .

Saya tidak bisa berpura-pura cukup akrab dengan proyek untuk mengetahui apakah fitur "locality yang disukai" tersedia, tetapi selain itu sepertinya cocok.

Pernahkah Anda melihat kolam OST di Lustre?

Ini tidak akan otomatis tetapi dengan kolam OST Anda dapat menetapkan direktori / file untuk OST / OSSes tertentu - pada dasarnya alokasi penyimpanan berdasarkan kebijakan, daripada round-robin / striping default di seluruh OST.

Jadi Anda bisa mengatur direktori per situs dan menetapkan direktori itu ke OST lokal untuk situs itu, yang akan mengarahkan semua I / O ke OST lokal. Itu masih akan menjadi namespace global.

Ada banyak pekerjaan untuk meningkatkan Lustre over WAN koneksi (server caching lokal dan hal-hal seperti itu) tetapi semuanya masih dalam pengembangan AFAIK berat.

Mungkin NFS tetapi dengan Cachef di server aplikasi akan mencapai bagian dari tujuan Anda. Seperti yang saya mengerti semuanya ditulis masih akan pergi ke server pusat, tetapi setidaknya membaca bisa berakhir di-cache secara lokal. Ini berpotensi menghilangkan banyak penundaan pembacaan tergantung pada pola penggunaan Anda.

Juga, mabye UnionFS layak untuk dilihat. Dengan ini saya pikir setiap lokasi akan menjadi ekspor NFS, dan kemudian Anda dapat menggunakan UnionFS di setiap lokasi untuk memiliki itu dan semua NFS mounts dari lokasi muncul sebagai satu sistem file. Saya tidak memiliki pengalaman dengan ini.

Anda bisa melihat ke DRBD untuk mereplikasi disk. http://www.drbd.org/ . Ini adalah solusi Ketersediaan Tinggi linux yang baru saja membuatnya menjadi Kernel.

Namun, ini memiliki beberapa keterbatasan:

1. Hanya dua node yang bisa diatur
2. WAN mungkin terlalu tidak bisa diandalkan untuk menjaga DRBD tetap kuat.

Jika Anda ingin membuatnya tetap sederhana maka lihatlah rsync, pecahkan banyak masalah dan dapat dituliskan.

Periksa chironfs .

Mungkin dapat melakukan apa yang Anda inginkan, berdasarkan sistem file.

Btsync adalah solusi lain yang sudah saya miliki. Ia menggunakan protokol BitTorrent untuk mentransfer file, sehingga semakin banyak server yang Anda miliki, semakin cepat sinkronisasi file-file baru.

Tidak seperti solusi berbasis rsync, ia mendeteksi ketika Anda mengganti nama file / folder, dan mengganti nama mereka di semua node alih-alih menghapus / menyalin.

Klien btsync Anda kemudian dapat berbagi folder di jaringan lokal.

Satu-satunya downside yang saya temukan (dibandingkan dengan MS DFS) adalah bahwa ia tidak akan mendeteksi salinan file lokal. Sebaliknya itu akan menafsirkannya sebagai file baru yang diunggah ke semua rekan.

Sejauh ini btsync tampaknya menjadi solusi sinkronisasi terbaik dan dapat diinstal pada perangkat Windows, Linux, Android, dan ARM (misalnya NAS)