Географічно розподілена файлова система з бажаною локальністю

Я будую додаток, який повинен розподіляти стандартний файловий сервер на декількох сайтах по мережі. В основному, кожен сайт повинен написати багато файлів різного розміру різного розміру (деякі в діапазоні 100 Мб, але більшість малих), а програма написана таким чином, що зіткнення не є проблемою. Я хотів би створити систему, яка відповідатиме наступним вимогам:

1. Кожен сайт може зберігати файли у спільному "просторі імен". Тобто всі файли відображатимуться в одній файловій системі.
2. Кожен сайт не надсилатиме дані через WAN, якщо не потрібно. Тобто, з кожної сторони WAN було б місцеве сховище, яке було б "об'єднане" в одну і ту ж логічну файлову систему.
3. Linux & Free ($$$) - це плюс

В основному, щось на зразок центральної частки NFS відповідало б більшості вимог, однак це не дозволило б місцевим записаним даним залишатися локальними. Усі дані з віддалених сторін WAN весь час будуть копіюватися локально.

Я вивчив Luster і провів з ним кілька успішних тестів, однак, схоже, вони розподіляють файли досить рівномірно по розподіленому сховищу. Я переглянув документацію і не знайшов нічого, що автоматично «віддасть перевагу» локальному сховищу перед віддаленим сховищем. Навіть те, що йшло із найнижчою затримкою, було б добре. Він би працював більшу частину часу, що відповідало б вимогам цієї програми.

Деякі відповіді на деякі запитання, задані нижче:

• Серверні вузли: 2 або 3 для запуску. Кожен сервер мав би десятки одночасно підключених клієнтів для читання / запису.
• WAN Topology є повною сіткою та надійною. (велика корпорація, вартість не така обмежує, як бюрократія)
• Відмова від клієнтів: Я фактично не думав про те, щоб відмовитись від клієнтів (в основному тому, що наше поточне застосування не робить цього лише на одному сайті). Я припускаю, що відповідь практик полягає в тому, що очікується, що сервери на кожному географічно розподіленому майданчику будуть єдиними пунктами відмов для клієнтів, яких вони обслуговують. Хоча, якщо ви думаєте про щось конкретне тут, я думаю, це було б цілком германно до дискусії.
• Roll-my-own: Я думав про rsync / unison, проте мені знадобиться трохи фантазійної логіки, щоб зробити "динамічну" частину цієї роботи безпроблемною. Тобто файл видається локальним, але отримується лише на вимогу.
• MS-DFS: Звичайно, мені здається, що я повинен заглянути. Моя головна проблема може бути невпевненою у конфігурації / надійності / продуктивності сервера NFS в Windows, оскільки багато клієнтів, що підключаються, є клієнтами NFS.

Ганьба щодо вимоги Linux. Саме цим займається Windows DFS. Починаючи з 2003 року R2, він також робить це на рівні блоків.

Деякі питання:

• Скільки «серверних» вузлів ви думаєте про участь у цій справі?

• Як виглядає топологія підключення WAN - концентратор та розмовляння, повна сітка? Наскільки це надійно?

• Чи очікуєте ви, що клієнти зможуть перейти на географічно не локальний сервер у випадку виходу з ладу локального сервера?

Windows DFS-R, безумовно, би те, що ви шукаєте, хоч і за певних потенційно значних витрат на ліцензування.

Ви кажете, що зіткнення не є проблемою, і вам не потрібен розподілений диспетчер блокування, тому ви можете зробити це за допомогою інструментів користувача, таких як rsync або Unison, і просто експортувати отриманий корпус файлів з NFS для місцевих клієнтів. Це некрасиво, і вам доведеться обробляти збивання якоїсь системи для обробки генерації топології реплікації та фактично запуску інструментів userland, але це, безумовно, дешево, оскільки вартість ліцензування зростає.

Ви розглядали AFS ?

Файлова система Ендрю (AFS) - це розподілена мережева файлова система, яка використовує набір надійних серверів для представлення однорідного прозорого простору імен файлів на всіх робочих станціях клієнта.

Як я розумію, більшість останніх розробок стоять за проектом OpenAFS .

Я не можу зробити вигляд, що я досить знайомий з проектом, щоб знати, чи доступна функція "бажаного населеного пункту", але в іншому випадку це здається непоганою.

Ви подивилися басейни OST у Люстері?

Це не буде автоматично, але за допомогою пулів OST ви можете призначити каталоги / файли певним OST / OSSes - в основному розподіл пам’яті, заснований на політиці, а не за замовчуванням / смугою через OST.

Таким чином, ви можете налаштувати каталог на кожен сайт і призначити цей каталог локальним OST для цього сайту, який направить усі введення-виведення до локальних OST. Це все ще буде глобальним простором імен.

Потрібно багато роботи над вдосконаленням Luster через WAN-з'єднання (локальні кешування-сервери і подібні речі), але все це все ще перебуває під важким розвитком AFAIK.

Можливо, NFS, але з Cachefs на серверах додатків здійснить вашу частину вашої мети. Як я розумію, все написане все одно перейде на центральний сервер, але принаймні читання можуть в кінцевому підсумку бути кешованими локально. Це може призвести до значної затримки зчитування, залежно від моделей використання.

Крім того, варто звернути увагу на Mabye UnionFS. Зважаючи на це, я думаю, що кожне місцеположення було б експортом NFS, і тоді ви можете використовувати UnionFS у кожному місці, щоб це і всі інші кріплення NFS з розташування відображалися як одна файлова система. Я не маю досвіду з цим.

Ви можете заглянути в DRBD для копіювання дисків. http://www.drbd.org/ . Це рішення з високою доступністю Linux, яке щойно перетворило його на ядро.

Однак це має деякі обмеження:

1. Можна встановити лише два вузли
2. WAN може бути занадто ненадійним, щоб підтримувати DRBD надійним.

Якщо ви хочете зробити це простим, тоді погляньте на rsync, вирішує багато проблем і може бути написано сценарії.

Перевірте на хіронах .

Можливо, це може робити те, що ви хочете, на основі файлової системи.

Btsync - це ще одне рішення, з яким я мав хороший досвід. Він використовує протокол BitTorrent для передачі файлів, тому чим більше у вас серверів, тим швидше відбувається синхронізація нових файлів.

На відміну від рішення, заснованого на rsync, воно виявляє, коли ви перейменовуєте файли / папки та перейменовує їх у всіх вузлах замість видалення / копіювання.

Однак клієнти btsync можуть потім ділитися папками в локальній мережі.

Єдиний недолік, який я знайшов (порівняно з MS DFS), це те, що він не виявить локальну копію файлу. Натомість він трактуватиме його як новий файл, завантажений всіма однолітками.

На даний момент btsync здається найкращим рішенням для синхронізації, і його можна встановити на пристроях Windows, Linux, Android та ARM (наприклад, NAS)