Двонаправлена ​​синхронізація в реальному часі великого дерева файлів між двома віддаленими серверами Linux


21

Під великим файловим деревом я маю на увазі близько 200 тис. Файлів, які постійно зростають. Однак порівняно невелика кількість файлів змінюється за будь-яку годину.

Під двонаправленим я маю на увазі, що зміни можуть відбуватися на будь-якому сервері і їх потрібно перенести на інший, тому rsync не здається підходящим.

Під віддаленим я маю на увазі, що сервери знаходяться як в центрах обробки даних, але географічно віддалені один від одного. Наразі існує лише 2 сервери, але вони можуть з часом розширюватися.

У режимі реального часу нормально, що між синхронізацією буде невелика затримка, але запуск крона кожні 1-2 хвилини не здається правильним, оскільки дуже мала частина файлів може змінюватися в будь-яку годину, не кажучи вже про хвилину.

EDIT : Ця функція працює на VPS, тому я можу обмежитися видами ядер на рівні ядра. Крім того, VPS не багаті на ресурси, тому я б ухилявся від рішень, які вимагають багато оперативної пам’яті (наприклад, Gluster?).

Який найкращий / найбільш "прийнятий" підхід для цього? Це здається, це було б загальною потребою, але я ще не зміг знайти загальноприйнятого підходу, що було дивно. (Я шукаю безпеку мас. :)

Я наткнувся на lsyncd, щоб запустити синхронізацію на рівні зміни файлової системи. Це здається розумним, хоча і не надто поширеним, і мене трохи бентежать різні підходи lsyncd. Там просто використовується lsyncd з rsync, але, схоже, це може бути тендітним для двонаправленості, оскільки rsync не має поняття пам’яті (наприклад, - знати, чи слід видалити видалений файл з A на B або новий файл у B) що слід скопіювати на A). Lipsync , здається, просто lsyncd + Rsync реалізація, НЕ так?

Потім використовується lsyncd з csync2 , як-от так: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Я схиляюся до цього підходу, але csync2 трохи химерний, хоча я зробив успішний тест на цьому. Мене найбільше турбує те, що мені не вдалося знайти багато підтвердження громади цього методу.

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

Я бачив, як Gluster згадував, але, можливо, надмірність того, що мені потрібно?

ОНОВЛЕННЯ: fyi- Я закінчив роботу з оригінальним рішенням, про яке я згадав: lsyncd + csync2. Це, здається, працює досить добре, і мені подобається архітектурний підхід до того, щоб сервери були дуже вільно з'єднані, так що кожен сервер може працювати на невизначений час самостійно незалежно від якості зв'язку між ними.


Які зміни потрібно вжити? Створення, видалення, модифікація EG.
sciurus

Також ви очікуєте конфліктів? Чи може бути змінений один і той же файл на обох серверах?
sciurus

Всі зміни: створення, видалення, модифікація. Існує потенціал для конфліктів, але вони повинні бути рідкісними. Я був би не проти, якщо мені просто надійде сповіщення про конфлікт, який мені доведеться потім вирішувати вручну.
dlo

Відповіді:


5

DRBD в режимі подвійного основного режиму з проксі - це опція.


Схоже, проксі не є ні відкритим, ні безкоштовним, правда? Я не впевнений, що розумію наслідок відсутності проксі в режимі асинхронізації: під час тривалого простою, якщо немає проксі, вихідний буфер [малий?] Міг би заповнитися, і ми втратимо синхронізацію? Чи важко від цього видужати?
dlo

Дивіться мою відповідь вище. Я не думаю, що проксі - це те, що вам потрібно. Навіть під час невеликого простою мета-пристрій drbd позначатиме "брудні" блоки та передаватиме їх після того, як з'єднання буде відновлено. Я думаю, що головна відмінність проксі-режиму від асинхронного режиму полягає в тому, що в режимі async використовується максимальний буфер деяких МБ. Після цього він синхронізується, щоб знову заповнити буфер. Проксі-сервер дозволяє отримати більший буфер (потрібен, якщо у вас велика затримка або ви можете писати набагато швидше локально, ніж віддалений).
Нілс

2

Замість того, щоб синхронізувати, чому б не поділитися тією ж файловою системою через NFS?


2
NFS жахливо, просто жахливо. Все було б краще, ніж NFS
AliGibbs

2
Одним з головних моментів налаштування мультисервера є відмова / надмірність. Отже, один сервер повинен мати можливість продовжуватись без іншого.
dlo

Ви повинні були згадати, що тоді у своєму запитанні - не потрібно проголосувати абсолютно розумну відповідь!
Барт Б

fyi, я не спростував цього - хтось ще зробив. Але так, я мав би сказати, що для початку.
dlo

@Bart: Ну - він згадав, що на двох віддалених сайтах є паралельний доступ. Тож навіть якщо ви поставите HA-NFS, це було б поганим рішенням, оскільки одна сторона постраждала б від затримки під час доступу до NFS. І я не спростував. Але я досить довго був адміністратором NFS, щоб підтримувати AliGibbs. : - /
Нілс

2

Реалізація розподіленої файлової системи, ймовірно, краще, ніж зламати це разом з інструментами та сценаріями, особливо якщо кластер серверів буде зростати. Ви також зможете краще впоратися зі збитим вузлом.

Я не думаю, що Gluster (або AFS) взагалі є надмірними.


Gluster вимагає 1 ГБ оперативної пам’яті? gluster.com/community/documentation/index.php/… ... Я також перебуваю на VPS, тому я не впевнений у внесенні змін рівня ядра, які можуть вимагати AFS. Але я починаю бачити, що правильний розподілений фс - кращий шлях.
dlo

Так, вибачте, що раніше не зрозумів, що ви використовуєте VPS-хости. Сліди пам’яті з глюстерною пам’яттю, як сервер, так і клієнт, не малі, і вони можуть істотно зрости. DRBD звучить більш доречно.

AFS - це шлях.
Ентоні Джорджіо

2

У вашому випадку я рекомендую комбінацію DRBD в режимі подвійного первинного режиму та gfs або ocfs.

Недолік DRBD в подвійному первинному полягає в тому, що він буде працювати в синхронному режимі. Але швидкість запису не здається тут важливою, чи не так?

Альтернативою DRBD може бути Soft-Raid1 з використанням багатьох (2+) iSCSI-Targets - але я вважаю за краще DRBD з двома вузлами.


1
Синхронний режим був би поганим - мені це не потрібно, і я не хотів би підривати продуктивність, оскільки сервери підключені через WAN на різних континентах. Але ви не можете мати подвійне первинне в режимі асинхронізації?
dlo

Наразі я використовую DRBD 8.3.5 - там ви повинні бути в режимі синхронізації ("C"), щоб перейти в подвійний основний режим. Я не маю особистого досвіду роботи з проксі-сервером DRBD, але він, схоже, схожий на Veritas Volume Replicator - але це, мабуть, не підходить, оскільки ви хочете отримати доступ для запису з обох сторін. Режим синхронізації на рівні блоку може бути не таким поганим, як ви думаєте - можливо, gfs та / або ocfs можуть буферувати записи.
Нілс

Я щойно перевірив німецьку статтю, в якій порівнюють GFS2 та OCFS2. З цього принаймні OCFS2, схоже, підтримує захищений доступ до файлової системи. GFS2 рекомендується в цій статті, оскільки вона постаріла. Детальну інформацію про GFS2 див. У документації RedHat на GFS2 - вона також використовує буферизацію - але для отримання найкращої продуктивності вам слід використовувати різні режими для одночасних записів.
Нілс

0

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

Я думаю, я б розглядав можливість поставити ціле дерево під контроль версій (наприклад, Subversion ) та періодично перевіряти введення / оновлення з обох серверів у завданнях cron.


0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.