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

параметры репликации файлового сервера

Я пытаюсь настроить файловый сервер в разных географических точках на Linux-сервере на основе centos. В настоящее время я планирую иметь два таких сервера и в ближайшем будущем планирую распространить их на другие области. Файловые серверы должны зеркалировать себя, когда файл добавляется в любое место (я еще не придумал стратегию удаления, но простое размышление должно разрешить удаление файлов, когда они удаляются с основного сервера). В настоящее время я думаю, что у меня будет «список каталогов» apache и rsync для выполнения этой работы. Я просто хочу знать, есть ли какие-нибудь более эффективные инструменты для выполнения вышеуказанного. Также я хотел бы услышать несколько предложений по лучшему скрипту листинга каталогов (на основе php / python). Было бы хорошо, если бы у этого инструмента были некоторые возможности поиска, опции для загрузки файлов и т. Д. (Я слишком много прошу?;)).

Примечание. На текущем сервере также находится репликация подрывной версии. Я также подумал о том, чтобы передать все файлы в Subversion и проверить их во втором месте. Но я чувствую, что пространство было бы ограничением, поскольку я бы продолжал удалять некоторые ненужные файлы, чтобы у меня было дисковое пространство под контролем, это будет невозможно, поскольку история версий svn будет содержать данные

Заранее спасибо.

В общем случае это невероятно сложная проблема. Географически распределенные файловые системы с несколькими главными репликами - это тема, по которой вы можете получить докторскую степень, даже если вы не решить всю проблему, так что небольшой фрагмент PHP или Python вряд ли поможет.

Если вы обрабатываете только добавление файлов (без модификаций) и нет возможности конфликта имен файлов, проблема становится намного проще, и вы можете обойтись без небольшого сценария оболочки. Однако имейте в виду, что это не обычная ситуация - вы можете подумать, что это сейчас, но держу пари, что идеи пользователей другие.

Мой совет: найдите человека, который разбирается в подобных вещах, и дайте ему немного денег, чтобы он провел тщательный анализ требований и нашел решение.

Если «файловый сервер» означает, что пользователи подключают диски к этому серверу через что-то вроде Samba или NFS, это очень сложная проблема, которую Уомбл так хорошо описал. Я видел, что некоторые системы были близки к этому, но они не включают в себя смонтированные тома; они используют определенного клиента для каждого дерева каталогов, участвующих в схеме репликации, и используют некоторые сложные алгоритмы обнаружения столкновений, чтобы гарантировать, что что-то не пострадает. И несколько открытых файлов, таких как базы данных Access, просто не работают в этих обстоятельствах.

Если «файловый сервер» означает сервер статических файлов для динамического веб-сайта, это намного проще. DRBD и Rsync были разработаны для такой нагрузки. Однако то, что вам приходится много держаться за руки, предполагает, что происходит что-то еще.

Наконец-то я это сделал. Настройте rsync. Вместе с этим я исследователь который предоставляет возможности файлового менеджера на базе веб. С их помощью мне удалось решить вышеупомянутую проблему, я еще не перенес ее в производство, но она успешно работает в течение последних 4 дней.

PS: По совету, позвольте мне попробовать свой PHD :)

GlusterFS - не лучшее решение для WAN.

Я могу только порекомендовать DRBD (потребуется приобрести прокси DRBD) или посмотреть csync2.

Я считаю, что вы можете использовать что-то вроде inotify для запуска csync2 или использовать lsyncd.

HTH

Brent