У нас есть 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
Я тестировал 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 (интерфейс кэширования).
Как @Khaled кратко коснулся, вы можете использовать DRBD для этого.
Каждый узел имеет свою собственную локальную копию данных (так что чтение происходит так же быстро, как ваш локальный диск); вы можете настроить его так, чтобы записывать блок до тех пор, пока данные не будут записаны на диск на других узлах (так что есть задержка, которая зависит от скорости вашей сети, но все клиенты будут видеть согласованное представление файлов).
Мы используем Gluster по аналогичному сценарию (приложения Ruby, а не Drupal). В вашем случае обе машины будут одновременно серверами и клиентами gluster. Установка Drupal будет указывать на общий ресурс, как видно из конфигурации клиента. Файловые операции на общем ресурсе распространяются на весь кластер, и вы должны быть устойчивы к сбоям одного узла.
Да, производительность ввода-вывода Gluster не будет такой хорошей, как у чего-то более физического, но я не уверен, как вы сможете обойти это с учетом вашей настройки.
Чтобы решить обе проблемы, используйте унисон. Основан на rsync и решает проблему с удаленными файлами.
Я думаю, что вы слишком усложняете проблему. Все, что вам нужно, это иметь что-то вроде NFS. Таким образом, один сервер будет обращаться к папке локально, а другой - удаленно через NFS. Я не думаю, что NFS настолько медленный, особенно если два сервера находятся рядом друг с другом в одной подсети.
Другой вариант - использовать репликацию на уровне диска, например DRBD.
Используя такие решения, вы можете избавиться от необходимости вручную синхронизировать изменения обоими способами.