Каков наилучший способ синхронизации нескольких серверов Linux?

Question

У меня есть несколько разных мест в довольно широкой области, каждая с сервером Linux, на котором хранятся данные компании. Эти данные меняются каждый день по-разному в разных местах. Мне нужен способ поддерживать эти данные в актуальном состоянии и синхронизировать их между собой.

Например:

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

Мой первый инстинкт - использовать rsync и задание cron для синхронизации в течение ночи (с 1 до 6 или около того), когда не используется ни одна полоса пропускания в наших местах. Мне кажется, что было бы лучше, если бы один сервер был «центральным», сначала извлекая все файлы с других серверов. Тогда это подтолкнет эти изменения обратно на каждый удаленный сервер? Или есть другой, лучший способ выполнить эту функцию?

Answer 1

Как я это делаю (на коробках Debian / Ubuntu):

• Используйте dpkg --get-selections для получения установленных пакетов
• Используйте dpkg --set-selections для установки этих пакетов из созданного списка
• Используйте систему управления версиями для управления файлами конфигурации. Я использую git централизованно, но subversion можно использовать так же легко.

Answer 2

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

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

Например, если кто-то загрузит spreadsheet.doc на сервер, скрипт увидит его мгновенно; если документ не будет изменен или удален, скажем, в течение 5 минут, скрипт может скопировать его на другие серверы (например, через rsync)

Такая система теоретически может реализовать своего рода ограниченную «репликацию файловой системы» с одного компьютера на другой. Вроде изящная идея, но вам, вероятно, придется написать ее самостоятельно.

Answer 3

Альтернативой, если rsync не лучшее решение для вас, является Unison . Unison работает под Windows и имеет некоторые функции для обработки, когда есть изменения с обеих сторон (необязательно выбирать один сервер в качестве основного, как вы предложили).

В зависимости от того, насколько сложна задача, может работать любая из них.

Answer 4

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

Answer 5

Я не знаю, насколько это практично, но здесь может работать система контроля версий. В какой-то момент (возможно, каждый час?) В течение дня задание cron запускает коммит, и в одночасье каждая машина запускает проверку. Вы можете столкнуться с проблемами, когда длинная фиксация не выполняется, когда нужно запустить извлечение, и, по сути, то же самое можно сделать rsync.

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

Answer 6

Зависит от следующих * Сколько серверов / компьютеров нужно синхронизировать? ** Если существует слишком много серверов, использование rsync становится проблемой ** Либо вы используете потоки и синхронизируетесь с несколькими серверами одновременно или один за другим. Таким образом, вы наблюдаете высокую нагрузку на исходный компьютер или непоследовательные данные на серверах (в кластере) в данный момент времени в последнем случае

• Размер папок, которые необходимо синхронизировать и как часто они меняются

  • Если данные огромны, тогда rsync займет время.

• Количество файлов

  • Если количество файлов велико и особенно, если это небольшие файлы, rsync снова займет много времени

Так что все зависит от сценария, использовать ли rsync, NFS, контроль версий

• Если есть меньше серверов и только небольшое количество данных, то имеет смысл запускать rysnc каждый час. Вы также можете упаковать содержимое в RPM, если данные периодически изменяются

С предоставленной информацией IMO Version Control подойдет вам лучше всего.

Rsync / scp может вызвать проблемы, если два человека загружают разные файлы с одинаковыми именами. NFS в нескольких местах должна быть с идеальной архитектурой

Почему бы не иметь один / несколько репозиториев, и каждый из них просто фиксирует в этом репозитории. Все, что вам нужно сделать, это синхронизировать репозиторий. Если объем данных велик, а обновления происходят часто, то вашему серверу хранилища потребуется хороший объем оперативной памяти и хорошая подсистема ввода-вывода

Answer 7

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

Я думаю, что центральная расчетная палата - хорошая идея.

Answer 8

rsync будет вашим лучшим выбором. Но вам нужно тщательно продумать, как вы собираетесь разрешать конфликты между обновлениями одних и тех же данных на разных сайтах. Если сайт-1 обновился Файлы customer.doc и site-2 по-разному обновляют один и тот же файл. Как вы собираетесь его решить?