У нас есть три сервера под управлением Ubuntu Server 10.04, балансировка нагрузки между ними через DNS. Мы используем Django, nginx для обслуживания контента и PostgresQL в качестве базы данных.
Для PostgresQL есть несколько решений для зеркалирования, но как лучше всего отразить наши статические файлы, используя схему «трех мастеров»?
Думаю, простая их синхронизация не будет масштабируемым и простым в обслуживании способом.
Если файлы меняются не часто и должны постоянно синхронизироваться, почему бы не использовать rsync? Просто убедитесь, что у вас есть один главный сервер, на котором вы редактируете файлы, что упрощает синхронизацию.
Кроме того, может работать сетевая файловая система, такая как NFS, или вы реализуете что-то вроде DRBD чтобы файлы всегда синхронизировались.
Есть много других решений (afs, unionfs ...), но rsync работает на удивление хорошо для односторонней репликации и самовосстанавливается - и масштабируется, если вы определили пути для репликации (один мастер подходит до около 5 рабов, но помимо этого, вероятно, есть веская причина перейти на многоуровневую репликацию).
Единственная проблема - время репликации. Поскольку вы используете циклический DNS, у вас уже есть привязка к серверу, поэтому у вас не возникнет проблема, когда пользователь обновляет сервер A, а затем не может видеть обновления, потому что он смотрит на сервер B. Но задержки в распространении код может вызвать некоторую боль при развертывании (особенно если у вас есть зависимость кода от изменений DDL в общей базе данных).
Если вам нужна двунаправленная репликация (старайтесь избегать, если это вообще возможно), тогда да, система репликации в реальном времени была бы более подходящей.
Если вы в настоящее время запускаете rsync вручную / через cron, вы можете рассмотреть возможность использования inotify для запуска rsync для файлов по мере их изменения, так что задержка становится очень короткой.
С.
Когда код развертывается в производственной среде, он должен быть развернут сразу на всех серверах. Если это действие контролируется должным образом, оно должно быть отражено как часть ваших элементов управления, и технологическое решение не потребуется. Не все административные решения основаны на технологиях.
OpenEFS - это инструмент, который был разработан для управления изменениями, а также для развертывания, который может оказаться вам полезным. Я реализовал многое из того, что они делают, самостоятельно, но для человека, у которого нет оснований, это было бы хорошим началом.
Для статических серверов, которые не подлежат контролю изменений, в прошлом я считал rsync подходящим решением. Обычно для серверов, которые подпадают под эту категорию, масштабирование вряд ли будет проблемой, но если это так, то где NFS или AFS может вступить в игру.