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