Мне было интересно, можно ли отразить два сервера, например, вы могли бы загружать файлы на один сервер, а они отправлялись бы на другой сервер и т.д. настройка (но это тоже было бы круто!)
Это во многом зависит от выполняемой работы.
Зачем вам зеркалирование файлов. Вы хотите обновить что-то вроде веб-сайта или репозитория контента, где обычно можно периодически обновлять? Или вам нужна синхронизация данных в реальном времени?
Для периодического асинхронного зеркалирования файлов обычно достаточно иметь промежуточную область, в которую вы загружаете все свои данные. И откуда вы раздаете на Сервера. В вашем случае - с двумя серверами - вы можете создать промежуточный файловый ресурс на srv1, куда вы передаете данные (через FTP, NFS, DAV, SFTP и т. Д.), А затем выполнить cronjob rsync файлов в «живые» каталоги srv1 и srv2. Самый простой способ использовать rsync в этом случае - создать пару ключей ssh, которую вы будете использовать для передачи данных и которая авторизована на всех серверах в вашем кластере.
Пример:
srv1:/data/staging/ <= is where you upload your data
srv1:/data/production/ <= is where your servers get their production data from
srv2:/data/production/
srv1$ cat /etc/cron.d/syncdata.cron
=====
*/5 * * * * syncuser rsync -a --delete /data/staging/ /data/production/
*/5 * * * * syncuser rsync -az --delete -e ssh /data/staging/ srv2:/data/production/
=====
Это должно дать вам общее представление. Конечно, вы можете заключить вызовы rsync в некоторые сценарии и реализовать правильную блокировку, чтобы она не запускалась дважды, если синхронизация занимает более 5 минут и т. Д. Кроме того, само собой разумеется, что промежуточная область не является обязательной. Вы также можете синхронизировать srv1: production напрямую с srv2: production. Только srv2 может отображать данные, которые на 5 минут старше, чем srv1. Что может быть проблемой, в зависимости от того, как вы балансируете между ними.
Другой способ асинхронного распространения файлов - упаковать их как rpm или, в вашем случае, файлы deb. Поместите их в центральный репозиторий и попросите их установить / обновить с помощью чего-то вроде cfengine, monkey или какого-нибудь самостоятельного решения на основе шины сообщений. Это имеет приятный побочный эффект управления версиями развернутых данных, но подходит только для небольших объемов данных, которые вы создаете и развертываете самостоятельно (например, версии вашего собственного программного обеспечения). Вы бы не захотели распространять с помощью этого ТБ данных, а также он не подходит для зеркалирования контента, который изменяется с высокой частотой, например, каждые две минуты или около того.
Если вам нужно реплицировать данные почти в реальном времени, но не обязательно синхронно, вместо того, чтобы периодически вызывать cron, вы можете использовать какой-нибудь метод на основе inotify, такой как уже упомянутый incron, для вызова ваших сценариев синхронизации. Еще одна возможность - использовать Gamin (который также использует inotify, если он присутствует в ядре) и написать свой собственный маленький демон синхронизации. И последнее, но не менее важное: если все файлы загружены на один сервер, например, через SFTP вы можете проверить, позволяет ли ваш SFTP-сервер определять хуки, которые вызываются после определенных событий, таких как загрузка файла. Таким образом вы можете указать серверу запускать ваш сценарий синхронизации при загрузке новых данных.
Если вам нужно синхронное зеркальное отображение данных в реальном времени, возможно, подойдет кластерная файловая система. DRDB уже назван. Это очень удобно для репликации на уровне блоков и часто используется для высокодоступных конфигураций MySQL. Вы также можете взглянуть на GFS2, OCFS2, Lustre и GlusterFS. Хотя Lustre и GlusterFS не совсем подходят для установки двух серверов.
В основном у вас есть 3 возможности:
cron + rsync знак равно зеркальные каталоги / файлы
В зависимости от вашего конкретного варианта использования - вы можете использовать что-то похожее на DRBD http://www.drbd.org/
Если вы пытаетесь создать здесь решение для резервного копирования (что я лично сделал практически в той же настройке), будьте осторожны. Есть много разных вещей, от которых вам нужно сделать резервную копию, одна из (возможно, самая большая) из них - это случайное удаление - любая живая система репликации просто воспроизведет удаление и не обеспечит никакой безопасности. Для этого работает ежедневная репликация, но это довольно слабый ответ. Попробуйте RSnapshot.
Унисон вполне может сработать для вас, но у меня нет личного опыта.
Запуск Rsync в обоих направлениях с флагами aproprate может работать, но у него есть довольно сложная проблема: как обрабатывать удаленные файлы без специальной обработки, он просто восстанавливает файлы, что нормально, если вы никогда не удаляете ничего, как я, но немного бедный иначе. Он также делает странные вещи, если файл перемещается.
Что бы вы ни делали, если может возникнуть ситуация, когда файлы можно одновременно редактировать с обеих сторон, у вас есть проблема. Унисон - единственное известное мне решение, которое может решить эту проблему даже почти удовлетворительно.
Если это одностороннее (я имею в виду, всегда с одного сервера на другой, но не наоборот), вы можете использовать incron. Он похож на cron, но основан на событиях файловой системы.
Каждый раз, когда файл создается или изменяется, он запускает scp или rsync с другим сервером.
У двунаправленного есть проблема петель :).
это зависит от ваших потребностей ..... у меня очень "дешевая и простая" установка для кластерных веб-серверов.
у меня просто есть один "файловый сервер" (NFS), где все веб-серверы монтируют следующие каталоги:
/etc/apache/sites-enabled
/etc/apache2/sites-avaliable
/var/www
мертвый простой и рабочий
clonezilla также может посмотреть, что использует rsync