Варіанти ефективної синхронізації 1 мільйона файлів з віддаленими серверами?

У компанії, в якій я працюю, у нас є така штука, яка називається "списки відтворення", це невеликі файли ~ 100-300 байт кожен. Їх близько мільйона. Близько 100 000 з них змінюються щогодини. Ці списки відтворення потрібно завантажувати на 10 інших віддалених серверів на різних континентах щогодини, і це має відбуватися швидко за 2 хвилини. Дуже важливо, щоб файли, які видаляються на майстрі, також видалялися з усіх реплік. В даний час ми використовуємо Linux для нашої інфраструктури.

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

Які ще варіанти варто розглянути?

Оновлення: я вибрав варіант lsyncd як відповідь, але тільки тому, що він був найпопулярнішим. Інші запропоновані альтернативи також дійсні по-своєму.

Оскільки миттєві оновлення також прийнятні, ви можете використовувати lsyncd .
Він переглядає каталоги (прищеплює) і rsyncзміниться на рабів.
При запуску він зробить повний rsync, так що це займе деякий час, але після цього передаються лише зміни.
Можливий рекурсивний перегляд каталогів, якщо підлеглий сервер не працює, синхронізація буде повторена, доки вона не повернеться.

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

Подумайте про використання розподіленої файлової системи, наприклад, GlusterFS . Розроблений з урахуванням тиражування та паралелізму, GlusterFS може масштабувати до 10 серверів набагато плавніше, ніж спеціальні рішення, що включають ініціацію та rsync.

Для цього конкретного випадку використання можна створити 10-серверний GlusterFS об'єм 10 реплік (тобто 1 репліка / цегла на сервер), так що кожна репліка була б точним дзеркалом кожної іншої репліки в томі. GlusterFS автоматично поширюватиме оновлення файлової системи на всі репліки.

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

Я сумніваюся rsync, працював би для цього звичайним способом, тому що сканування мільйона файлів та порівняння їх з віддаленою системою в 10 разів зайняло б багато часу. Я б спробував реалізувати систему з чимось подібним, inotifyщо зберігає список модифікованих файлів і пересилає їх на віддалені сервери (якщо ці зміни все одно не входять в систему). Потім ви можете скористатися цим списком, щоб швидко визначити файли, необхідні для передачі - можливо, навіть з rsync (а краще 10 паралельних екземплярів цього).

Редагувати: Трохи попрацювавши, ви навіть можете скористатись цим методом перегляду ініціації / журналу, щоб скопіювати файли, як тільки зміни відбудуться.

Ще кілька альтернатив:

• Вставте завдання в RabbitMQ або Gearman, щоб асинхронно вимкнути та видалити (або додати) один і той же файл на всіх віддалених серверах, коли ви видаляєте або додаєте файл на первинному сервері.
• Зберігайте файли в базі даних та використовуйте реплікацію для синхронізації віддалених серверів.
• Якщо у вас є ZFS, ви можете використовувати реплікацію ZFS .
• Деякі SAN мають реплікацію файлів. Я не маю уявлення, чи можна цим користуватися через Інтернет.

Це, мабуть, є ідеальним випадком використання книжок для MongoDB та, можливо, GridFS . Оскільки файлів порівняно мало, лише MongoDB має бути достатньо, хоча використання API GridFS може бути зручним.

MongoDB - це база даних nosql, а GridFS - це збірка файлів для зберігання файлів. У MongoDB є багато вбудованих варіантів реплікації та шардингу , тому це має бути дуже масштабним у вашому випадку використання.

У вашому випадку ви, ймовірно, почнете з набору реплік, який складається з майстра, розташованого у вашому первинному центрі обробки даних (можливо, другого, на випадок, коли ви хочете перейти на інше місце у тому самому місці) та ваших десяти "рабів", що поширюються по всьому світу. Потім зробіть тести завантаження, щоб перевірити, чи достатня продуктивність запису, і перевірте час реплікації на свої вузли. Якщо вам потрібно більше виконання, ви можете перетворити налаштування на стримане (переважно для розподілу завантаження запису на більше серверів). MongoDB був розроблений з можливістю масштабування величезних налаштувань за допомогою «дешевого» обладнання, так що ви можете кинути партію недорогих серверів для підвищення продуктивності.

Я б використав S3 Backend, а потім просто встановив би це на всіх потрібних мені серверах. Таким чином, всі миттєво синхронізуються в будь-якому випадку

Варіант, який, здається, ще не згадується, - це архівування всіх файлів в один стислий файл. Це має суттєво зменшити загальний розмір і видалити всі накладні витрати, пов'язані з використанням мільйонів окремих файлів. Замінивши весь набір файлів одним великим оновленням, ви також можете бути впевнені, що видалені файли видаляються з реплік.

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