Я дал задание создать два сервера CentOS 7, на которых будут реплицироваться не только базы данных, но и файлы. Теперь моя проблема в том, что, вероятно, будут сотни тысяч файлов, если не миллион файлов с самыми разными размерами от нескольких килобайт до ~ 1 гигабайта.
Я читал о
Теперь я хочу спросить о вашем опыте использования любого из них, если вы его использовали или используете в настоящее время. Как работает производительность с изменениями файлов в отношении копий и удалений? Я очень боюсь использовать какой-либо rsync, потому что мой опыт показывает, что он не очень быстрый с большим количеством небольших файлов, поэтому я не могу использовать его для репликации файлов в реальном времени. Или я не прав? Пожалуйста, докажите, что я ошибаюсь. :)
А может мне понадобятся 3-й и 4-й сервер в качестве файловых серверов? Если да, то остается вопрос: как реплицировать файлы между двумя серверами в реальном времени?
Ура!
Если ваши серверы находятся в одной локальной сети, то лучшим выбором должна быть кластерная файловая система (например, GlusterFS) или общее хранилище (например, через NFS).
Если ваши серверы находятся в другом месте и имеют только подключение к глобальной сети, вышеуказанное решение не будет работать. В этом случае и если вам нужна только односторонняя репликация (то есть: от активного к резервному серверу), lsyncd хорошее решение. Другое решение csync2. Наконец, еще одна возможность - использовать DRBD + DRBD Proxy (обратите внимание, что его прокси-компонент является коммерческим плагином).
Наконец, если ваши серверы имеют только подключение к глобальной сети и вам нужна двунаправленная репликация (т.е. оба сервера активны одновременно), серебряной пули практически не существует. Я перечислю некоторые возможности, но я далек от рекомендации подобной установки:
unison с его плагином реального времениpsync, который я как раз и написал для решения подобной проблемы (но учтите, что у него есть свои особенности, и я предлагаю нет поддержки для этого)syncthing с его плагином реального времени (но он имеет значительные ограничения, а именно, он не сохраняет ACL или владельца / группу файла)Я использую файловую систему ZFS и репликацию на уровне блоков, используя структуру отправки / получения zfs.
Я использую удобный скрипт под названием синкоид выполнять регулярную синхронизацию файловых систем с интервалом от 15 секунд до ежечасного или ежедневного, в зависимости от требований.
Блочная репликация будет более чистой и точной, чем rsync для набора данных, о котором вы говорите.
По моему опыту, распределенные файловые системы предоставляют простые механизмы репликации для приложений. Однако они страдают от плохой производительности, особенно когда каталоги становятся очень большими со слишком большим количеством маленьких файлов. Это ожидается, поскольку им необходимо иметь дело с блокировкой / общим доступом из нескольких мест / машин.
Способы, подобные Rsync, в некоторых случаях обеспечивают приемлемую репликацию с некоторой задержкой. Они не влияют на производительность приложения при чтении / записи реплицированной папки.
Я думаю, что лучшим решением является предоставление общего хранилища (если доступно), доступного с одного сервера. Другой резервный сервер готов к подключению общей папки, когда первый выйдет из строя. Нет необходимости реплицировать какие-либо данные между серверами.
Приветствую идеи. Я проверил и протестировал их все, и я придерживаюсь lsyncd.
Причины: