Двунаправленная синхронизация в реальном времени большого файлового дерева между двумя удаленными Linux-серверами


21

Под большим файловым деревом я имею в виду около 200 тыс. Файлов, и они постоянно растут. Относительно небольшое количество файлов изменяется в любой данный час, хотя.

Под двунаправленным я подразумеваю, что изменения могут происходить на любом сервере и должны быть перенесены на другой, поэтому rsync кажется неуместным.

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

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

РЕДАКТИРОВАТЬ : Это работает на VPS, так что я мог бы ограничиться видами вещей на уровне ядра, которые я могу сделать. Кроме того, VPS не богаты ресурсами, так что я бы избегал решений, которые требуют много оперативной памяти (например, Gluster?).

Каков наилучший / наиболее «приемлемый» подход для достижения этой цели? Кажется, что это будет общая потребность, но я пока не смог найти общепринятый подход, что было удивительно. (Я ищу безопасность масс. :)

Я сталкивался с lsyncd для запуска синхронизации на уровне изменения файловой системы. Это кажется умным, хотя и не супер распространенным, и меня немного смущают различные подходы lsyncd. Есть только использование lsyncd с rsync, но кажется, что это может быть хрупким для двунаправленности, поскольку rsync не имеет представления о памяти (например, чтобы узнать, следует ли удалять удаленный файл на A на B или новый файл на B это должно быть скопировано в А). lipsync - это просто реализация lsyncd + rsync, верно?

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

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

Я видел упомянутое Глостер , но, может быть, излишне для того, что мне нужно?

ОБНОВЛЕНИЕ: я закончил тем, что пошел к оригинальному решению, которое я упомянул: lsyncd + csync2. Кажется, он работает довольно хорошо, и мне нравится архитектурный подход, предусматривающий очень слабое объединение серверов, чтобы каждый сервер мог работать самостоятельно неограниченное время независимо от качества связи между ними.


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

Кроме того, вы ожидаете конфликтов? Может ли один и тот же файл быть изменен на обоих серверах?
sciurus

Все изменения: создание, удаление, модификация. Возможны конфликты, но они должны быть редкими. Я не возражаю, если я просто получу предупреждение о конфликте, который мне придется разрешить вручную.
ДЛО

Ответы:


5

DRBD в режиме Dual-primary с прокси-сервером является опцией.


Прокси, кажется, не является ни открытым исходным кодом, ни бесплатным, верно? Я не уверен, что понимаю последствия отсутствия прокси в асинхронном режиме: во время длительного простоя, если нет прокси, выходной буфер [small?] Может заполниться, и мы потеряем синхронизацию? Трудно ли оправиться от этого?
ДЛО

Смотрите мой ответ выше. Я не думаю, что вам нужен прокси. Даже во время небольшого простоя мета-устройство drbd помечает «грязные» блоки и передает их после восстановления соединения. Я думаю, что основное различие между прокси и асинхронным режимом состоит в том, что асинхронный режим использует максимальный буфер в несколько МБ. После этого он синхронизируется перед заполнением буфера снова. Возможно, прокси-сервер обеспечивает больший буфер (необходим, если у вас большая задержка или вы можете писать намного быстрее локально, чем удаленно).
Нильс

2

Вместо синхронизации почему бы не использовать одну и ту же файловую систему через NFS?


2
NFS ужасна, просто ужасна. Все было бы лучше, чем NFS
AliGibbs

2
Одним из основных пунктов настройки нескольких серверов является аварийное переключение / резервирование. Таким образом, один сервер должен иметь возможность продолжить работу без другого.
ДЛО

Тогда вы должны были упомянуть об этом в своем вопросе - не нужно голосовать за совершенно разумный ответ!
Барт B

Кстати, я не понизил это - кто-то другой сделал. Но да, я должен был упомянуть это для начала.
ДЛО

@ Барт: Хорошо - он упомянул, что есть одновременный доступ на двух удаленных сайтах. Таким образом, даже если вы установите HA-NFS, это будет плохим решением, поскольку одна сторона будет страдать от задержки во время NFS-доступа. И я тоже не понизил. Но я достаточно долго был администратором NFS, чтобы поддерживать AliGibbs. : - /
Нильс

2

Реализация распределенной файловой системы, вероятно, лучше, чем взламывать ее вместе с инструментами и скриптами, особенно если кластер серверов будет расти. Вы также сможете лучше обрабатывать сбитый узел.

Я не думаю, что Gluster (или AFS) является излишним.


Gluster требует 1 ГБ оперативной памяти? gluster.com/community/documentation/index.php/… ... Я также использую VPS, поэтому я не уверен в необходимости вносить изменения в уровень ядра, которые могут потребоваться AFS. Но я начинаю видеть, что правильный распределенный fs - лучший путь.
ДЛО

Да, извините, я не заметил, что вы использовали хосты VPS. Объемные области памяти, как серверные, так и клиентские, не малы и могут существенно возрасти. DRBD звучит более уместно.

AFS - это путь.
Энтони Джорджио

2

В вашем случае я бы порекомендовал комбинацию DRBD в режиме с двумя основными каналами и gfs или ocfs.

Недостаток DRBD в двойном первичном состоит в том, что он будет работать в синхронном режиме. Но скорость записи здесь не так важна, верно?

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


1
Синхронный режим был бы плох - мне это не нужно, и я не хотел бы снижать производительность, поскольку серверы подключены через глобальную сеть на разных континентах. Но вы не можете иметь двойной первичный в асинхронном режиме?
ДЛО

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

Я только что проверил немецкую статью, сравнивающую GFS2 и OCFS2. Из этого, по крайней мере, OCFS2, похоже, поддерживает буферизованный доступ к файловой системе. GFS2 рекомендуется в этой статье, так как он старше. См. Документацию RedHat по GFS2 для получения подробной информации о GFS2 - она ​​также использует буферизацию - но вы должны использовать разные каталоги для одновременной записи, чтобы получить лучшую производительность.
Нильс

0

Как показано выше, доступно много решений, каждое из которых имеет свои преимущества и недостатки.

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


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.