Назад | Перейти на главную страницу

Синхронизация 2 удаленных папок

У нас есть 2 сервера Drupal, которые read/write в свою копию той же папки ( sites/default/files папка для тех из вас, кто знает немного о Drupal). Эти 2 папки должны быть синхронизированы. Я рассматривал несколько вариантов и вот что выяснил:

ВАРИАНТ 1: Rsync в обоих направлениях: не вариант
Вам нужно бежать rsync в обе стороны, потому что обе папки изменяются. Пока файлы просто изменяются, все работает нормально, потому что вы можете использовать -u флаг, который проверяет время обновления и изменяется только в том случае, если источник более новый, чем место назначения. Однако поскольку rsync не хранит историю файлов, которые удаляются и когда, rsync не будет знать, что делать с файлами, удаленными на одной стороне, и следует ли их хранить на другой стороне, потому что они обновлены недавно или также выброшены.

ВАРИАНТ 2: Общий сетевой ресурс: ОК, но проблема с производительностью ожидания ввода-вывода
Один из вариантов - настроить сетевой ресурс, исключив необходимость синхронизации. Обратной стороной является ожидание ввода-вывода, поскольку оба сервера read/write на том же диске.

ВАРИАНТ 3: 3-й сервер с главной копией: ОК, но потенциальные проблемы с производительностью / гонкой Другой вариант - создать на третьем сервере главную копию папки. При каждом изменении на одном сервере Drupal папка сервера Drupal будет rsync'ed в основную копию, что позволяет обойти проблему, поднятую в варианте 1. Однако для этого вам потребуется синхронизировать изменения с основной копией в порядке появления на серверах Drupal, что вызовет следующие проблемы:
-P1: если вы синхронизируете с мастером для каждого внесенного изменения, и изменения происходят часто, ваши серверы могут быть тихо заняты процессом синхронизации
-P2: даже если вы запускаете задания синхронизации по порядку, из-за различных элементов (скорость выполнения процесса, задержки в сети ...) у вас нет гарантии, что файлы будут синхронизированы по порядку на главной копии.

Q1: Как решить проблемы P1 и P2?
Q2: Есть ли другие подходы для синхронизации двух удаленных папок?

Дополнительная информация:

server OS:                   Ubuntu server 10.04 LTS
Drupal v:                    Drupal 6.X
Size of sites/default/files: 4.5G

Обновление 1: тестирование Unison

Я тестировал Unison и это не работает, как я ожидал, в отношении удаленных файлов:

[1] Настройка каталогов

FOLDER1     FOLDER2
file1 (new)     (empty)

[2] Бегущий унисон (unison FOLDER1 FOLDER2)

FOLDER1        FOLDER2            
file     ---->            file1

=> file1 копируется из FOLDER1 в FOLDER2

[3] Обновление каталогов

FOLDER1     FOLDER2
file1 (removed) file1 (modified)

[4] Снова бегу унисон (unison FOLDER1 FOLDER2)

FOLDER1        FOLDER2            
deleted  <-?-> changed    file1  [] 
No default command [type '?' for help]

С этой точки зрения Unison не знает, следует ли удалять file1 из FOLDER2 или скопируйте его в FOLDER1. Я ожидал Unison сделать последнее как:
-at [2] мы знаем время последнего изменения / доступа file1 в обеих папках, и они копируются в Unison архивы.
-в [4] мы видим file1 отсутствует в FOLDER1 поэтому время, учитываемое для удаления, должно быть последним доступным временем в архиве (то есть временем, полученным в [2]).
-at [4] мы также видим, что время последнего изменения / доступа file1 в FOLDER2 больше [2] для FOLDER1, так file1 следует скопировать из FOLDER2 к FOLDER1.

Я пробовал разные переключатели, такие как -auto (автоматически принимать действия по умолчанию) и -batch (пакетный режим: вообще не задавайте вопросов), но все же, Unison не может принять это решение самостоятельно.

В: Есть ли способ получить Unison или другой инструмент для работы в соответствии с описанным мной поведением?

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

Рассматривали ли вы использование нескольких интерфейсов кэширования и одного бэкенда базы данных drupal +? Pressflow - это расширенная версия Drupal, которая имеет встроенную интеграцию с memcached и Varish (интерфейс кэширования).

http://pressflow.org/

Как @Khaled кратко коснулся, вы можете использовать DRBD для этого.

Каждый узел имеет свою собственную локальную копию данных (так что чтение происходит так же быстро, как ваш локальный диск); вы можете настроить его так, чтобы записывать блок до тех пор, пока данные не будут записаны на диск на других узлах (так что есть задержка, которая зависит от скорости вашей сети, но все клиенты будут видеть согласованное представление файлов).

Мы используем Gluster по аналогичному сценарию (приложения Ruby, а не Drupal). В вашем случае обе машины будут одновременно серверами и клиентами gluster. Установка Drupal будет указывать на общий ресурс, как видно из конфигурации клиента. Файловые операции на общем ресурсе распространяются на весь кластер, и вы должны быть устойчивы к сбоям одного узла.

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

Чтобы решить обе проблемы, используйте унисон. Основан на rsync и решает проблему с удаленными файлами.

Я думаю, что вы слишком усложняете проблему. Все, что вам нужно, это иметь что-то вроде NFS. Таким образом, один сервер будет обращаться к папке локально, а другой - удаленно через NFS. Я не думаю, что NFS настолько медленный, особенно если два сервера находятся рядом друг с другом в одной подсети.

Другой вариант - использовать репликацию на уровне диска, например DRBD.

Используя такие решения, вы можете избавиться от необходимости вручную синхронизировать изменения обоими способами.