Я читал и пытался настроить несколько разных сред кластера серверов. У меня он корректно работает при использовании различных дистрибутивов Linux.
Базовая установка выглядит следующим образом:
----- App Server 1
| Database Server 1
Load Balancer --| Database Server 2
|
----- App Server 2
Как видите, это базовая настройка ведомого мастера. Моя проблема. Я не уверен, как лучше всего воспроизвести часть сервера приложений. Итак, если на сервере приложений 1 вносятся новые файлы сценариев или изменения, как эти изменения передаются каскадом на второй сервер приложений?
На серверах баз данных работает MySQL, поэтому любые обновления одного каскада автоматически передаются другим.
Версия TL; DR: это зависит от приложения
В качестве хорошего справочника по созданию современного программного обеспечения я настоятельно рекомендую прочитать приложение с двенадцатью факторами.
Скрипты и код не реплицируются как таковые, а «передаются» на серверы приложений (вы также можете запустить серверы, выполнив их все и переключившись со старого кода на новый с помощью другого механизма, такого как символическая ссылка).
Однако у клиентов часто есть «состояние», которое серверам приложений может потребоваться запомнить, чтобы они правильно обслуживали запросы.
Вообще говоря, чтобы серверы приложений были масштабируемыми по горизонтали, вы хотите, чтобы они были как можно более «апатичными». Это означает, что серверу приложений нечего запоминать, все это хранится извне, и любой запрос может быть выполнен только с данными, полученными в запросе. Однако вашим клиентам (веб-браузерам) часто требуется состояние, например, вход в систему, поэтому вам нужно иметь возможность каким-то образом обрабатывать данные состояния.
Один из обходных путей - использовать «липкие сеансы», реализованные в балансировщике нагрузки. Обычно это реализуется путем внедрения файла cookie, который балансировщик нагрузки использует, чтобы запомнить, на какой сервер он должен отправить запрос. Это легко реализовать и не требует изменения кода, но имеет довольно большой недостаток, заключающийся в том, что состояние будет потеряно при перезапуске сервера приложений.
Другой способ - сделать приложение не имеющим состояния, сохранив все в файлах cookie. Я не рекомендую это вообще, потому что данные о состоянии будут выгружаться при каждом запросе. Клиенты также могут изменять эти данные и делать неожиданные вещи, и это может иметь серьезные последствия для конфиденциальности, если кто-то перехватит cookie.
Ни один из них не решает проблему файлов на диске, потому что они полагаются на файлы cookie, которые пользователь может потерять, или они могут просто войти в систему из другого места.
Последний и рекомендуемый способ - сохранить состояние клиента в базе данных (или хранилище ключ: значение), чтобы любой экземпляр приложения мог запрашивать его при получении запроса. Вам по-прежнему необходимо, чтобы клиент запомнил «идентификатор сеанса», но это более безопасно, поскольку клиент хранит меньше данных. Традиционно эту роль будет выполнять кластер узлов memcached с согласованным хешированием, но в наши дни существуют более мощные решения, такие как Redis.
Что касается файлов на диске - не храните ничего на дисках сервера приложений, кроме кода приложения и статических ресурсов, которые могут быть «выпущены» как часть развертывания. Журналы являются возможным исключением, но всегда предпочтительнее отправлять их на удаленный сервер системного журнала или что-то вроде logstash.
Если ваше приложение должно хранить файлы (например, загруженные клиентами), храните их в каком-либо хранилище данных (Cassandra - неплохой выбор), в какой-либо службе хранения, такой как Openstack. стремительный, или Amazon S3, если вы недостаточно велики, чтобы делать это самостоятельно.
Если приложение небольшое и вы правильно обрабатываете блокировку файлов, общий ресурс NFS или samba также может работать, но я бы порекомендовал Amazon S3, прежде чем идти по этому пути.
Как правило, вам нужна среда, в которой вы можете тестировать изменения кода, а затем развертывать их на серверах приложений пакет за пакетом (на схеме один сервер, а затем другой). Однако, если у вас есть изменения схемы БД, это становится немного сложнее, и вам, возможно, придется написать код, чтобы это учесть.
Если вы хотите реплицировать изменения файловой системы, вы можете использовать что-то вроде DRBD или блеск иметь общую файловую систему. Или создайте свое собственное решение с чем-то вроде rsync--- в зависимости от ваших требований.