Я хотел бы иметь 2 одинаковых веб-сервера: один главный и один подчиненный. Файл, недавно измененный / созданный на ведущем устройстве, должен быть немедленно реплицирован на ведомом устройстве (в течение минуты).
Я не хочу использовать rsync, потому что он сканирует все файлы, чтобы вычислить отправляемую дельту. Я не хочу использовать распределенную файловую систему, такую как GLUSTER, потому что боюсь, что она может принимать много небольших записей. Тем не менее, я могу подождать одну минуту, чтобы сбросить все модификации подчиненного устройства.
Вы знаете, какой инструмент мне следует использовать?
Я не понимаю, почему вы не хотите использовать rsync; в конце концов, именно для этого ...
Поскольку вы говорите, что не хотите использовать кластерную файловую систему, как насчет использования папки www на ServerA (общий доступ / экспорт) для ее монтирования на ServerB в качестве wwwRoot. Вместо репликации ServerB использует те же самые файлы.
Я не пробовал, но это может сделать то, о чем вы просите.
Если вы храните файлы своего веб-приложения в системе контроля версий, (вы делать у вас есть файлы в системе контроля версий, не так ли?), вы могли бы написать сценарий, чтобы вытащить эти файлы из вашей VCS и перезапустить службу веб-сервера (Apache, NGINX и т. д.). Вы даже можете запустить этот запуск под cron, чтобы каждый раз, когда вы обновляете репо (я рекомендую проверять тег, а не ветку или просто мастер), он автоматически обновлял веб-сайт.
drbd разрешит репликацию на уровне блоков, однако, если вы выполняете какие-либо записи на ведомом устройстве, вы можете использовать OCFS2 или GFS для поддержки блокировки кластера. Если вы можете смонтировать первичный сервер с ведомого по NFS и направить запись на монтирование NFS, вы можете избежать использования файловой системы блокировки кластера.
GlusterFS была бы более бесшовной, но многие крошечные записи, кажется, временами задерживаются. OpenAFS похожа, но почти любая распределенная файловая система подойдет для этого. Двухузловая HDFS, вероятно, также подойдет вам.
@gwaldo, Что касается неиспользования rsync, если у вас есть сотни тысяч файлов, просто обход дерева для поиска измененных файлов может занять больше минуты.
rsync не должен сканировать все файлы для вычисления их дельт, по умолчанию он использует алгоритм быстрой проверки, который ищет только файлы с измененным размером или измененным временем. Если у вас не так много миллионов файлов, запуск rsync должен быть довольно быстрым.
В противном случае вам, вероятно, понадобится специальное решение, которое должно будет отслеживать приложения, которые могут изменять данные, и отправлять их после того, как программа закроет файл.
В этих требованиях нет ничего необычного, но, похоже, это приведет к проблемам.
Для наиболее значимого бизнеса веб-приложенияпрокси-серверы с высокой доступностью и балансировкой нагрузки должны быть почти везде. Это означает использование всего подходящего: dns round-robin, haproxy, ipvs, pfsense, f5's, netscaler, cisco ace и т. Д.
Веб-серверы, обслуживающие статический контент, не должны иметь состояния. Помимо разрыва соединений, отключение какого-либо одного веб-сервера не должно иметь практически никакого влияния на пользователей. Таким образом, нет необходимости в репликации дисков между машинами. Используйте LB, упомянутый выше, чтобы сделать то же самое с меньшими усилиями. Репликация создает хрупкие зависимости и кошмар поддержки, который может все разрушить. Лучше использовать git или rsync по ssh, как упоминалось ранее, с внутреннего сервера развертывания. Если отправлять контент на тысячи узлов, жемчужина убийства из твиттера - это круто.
Серверы приложений, все, что создает веб-страницу на основе изменяющихся данных, также должны быть относительно апатичными. Определенно используйте что-то вроде Nginx для чистого, последовательного, экспоненциального развертывания приложения. Данные должны храниться в базе данных (sql / nosql) или у поставщика данных RESTful.
Тщательно протестированное аварийное переключение следует использовать для защиты баз данных и других важных компонентов. Что касается производительности, если приложение имеет узкое место одновременной записи в базе данных, превышающее то, что может обрабатывать оборудование (масштабирование), рассмотрите надежный nosql, который использует механизм хранения с журнальной структурой, такой как bitcask riak.
Если это не веб-приложение, а обрабатывает большой объем данных, оцените структуру MapReduce, такую как Hadoop, которая использует их HDFS.
Кластер DRBD + Heartbeat Apache может быть включен ... лично я тестировал это ... он работает нормально
Вам, вероятно, следует использовать врезаться следить за измененными файлами вместо того, чтобы запускаться регулярно (и вслепую).
Вы бы использовали $# переменная, обозначающая имя файла, связанное с событием, для индивидуальной синхронизации каждого измененного файла. Это может быть подходящим вариантом, если вы хотите избежать сканирования всех файлов в пути после каждого изменения. Но я не пробовал.
Также, возможно, вам стоит взглянуть на Унисон:
Unison имеет ряд функций с такими инструментами, как пакеты управления конфигурацией (CVS, PRCS, Subversion, BitKeeper и т. Д.), Распределенные файловые системы (Coda и т. Д.), Утилиты однонаправленного зеркалирования (rsync и т. Д.) И другие синхронизаторы. (Intellisync, Reconcile и т. Д.).
Вот как.