Настройка репликации между двумя веб серверами?

Question

[by_EL]

Есть веб сервер ,для отказоустойчивости хочу организовать вторую реплицирующую сервер в случае чего для резерва, Как могу организовать репликацию веб файлов и папок между двумя серверами чтобы файлы перодически синхронизировались желательно с правами
Заранее очень благодарен !!

Comments

[Saboteur]

Вообще это зависит от того, как файлы попадают на первый сервер.

Если из git, то просто делать git pull на обоих серверах.
Если деплоятся - настроить деплой на два сервера.
Если вы вдруг правите руками прямо на сервере - ну rsync или какой-нить отдельный nas/dfs

Answer 1

[shurshur]

Если речь идёт о постоянной синхронизации именно файлов, то очень неплохо работает lsyncd. Только ни в коем случае нельзя пытаться использовать его для синхронизации в две стороны (путём запуска двух экземпляров), только в одну! (Я тестировал, даже если запись идёт только в одну сторону, иногда спонтанно случается синхронизация в неправильную сторону неполностью записанного файла)

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

Разумеется, всё это не отменяет бэкапов и других организационных мер по развёртыванию и поддержке, но можно по возможности максимально снизить риск потери самых последних данных.

Comments

[by_EL]

спасибо , Если есть две сервера то выполненные изменения должны выполнятся на основном сервере как я понял да ?

[shurshur]

by_EL, речь о чём? Если о lsyncd, то этот демон мониторит изменения в каталоге и для изменившихся файлов делает rsync. Но он только в одну сторону синхронизирует.

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

[shurshur]

by_EL, а, ещё есть вот такая штука https://github.com/stephenh/mirror умеющая даже two-way sync, но я смог в тестах также получить случаи синхронизации в неправильную сторону.

Answer 2

[pfg21]

для постоянной синхронизации файлов посоветую syncthing (или его коммерческого брата resilio sync), выросли из торрентов, поэтому возможен полноценный п2п на кучу систем.
демон постоянно висит в памяти. слушает inotify т.е. может мгновенно вылавливать изменения в файлах. умеет простой диф файлов. цифровая подпись каждого файла, т.е. 100% подтверждения доставки, плюс адекватно обрабатывает обрывы связи, потерю пакетов. шифрует канал. и все такое.
есть какие-то опции с правами файлов, но у меня облако разнородное (лин вин андроид) так что это я отключил.

Answer 3

[Drno]

rsync
rclone

Answer 4

[rPman]

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

Существует способ организации работы, когда синхронизация идет на блочном уровне файловой системы. Например DRBD (когда несколько блочных устройств в сети настраиваются как raid1 mirror). Или файловые системы типа glusterfs, когда сетевое хранилище организуется на базе файловой системы, в догонку еще варианты типа lustre или ceph.

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

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