Я ищу варианты и решения для проекта моей компании, где мы можем размещать наши веб-сайты на нескольких серверах и использовать балансировку нагрузки. Основная проблема заключается в том, что при обновлении веб-сайтов мне необходимо перезапустить сервер. Наши веб-проекты написаны на Djanog / Python, и каждый раз, когда я отправляю обновления, требуется перезапуск uWSGI. В настоящее время наши веб-сайты работают на отдельных серверах, и их сложно обновить / перезапустить, пока клиенты используют приложение. Я искал решение в Интернете и нашел хорошую статью на сайте DigitalOcean. Вы можете прочитать об этом подробнее Вот.
Мы также стремимся отделить нашу базу данных от работы на одном сервере приложений и использования на конкретном компьютере, а также настроить главный-подчиненный сервер для репликации. Итак, мой вопрос заключается в том, что, например, наш сайт example.com работает на веб-серверах / ip 101 и 102. Оба эти сайта подключены к базе данных ip 201. Итак, теперь, когда я нажимаю обновление на сервере 101 и перезапускаю приложение, я хотите, чтобы 102 обрабатывал все запросы без каких-либо ошибок или чего-либо еще. После обновления 101 я хочу, чтобы он снова включился и обрабатывал все запросы, пока я обновляю сервер 102. У меня также будет такая же настройка для базы данных, поэтому 201 и 202 в качестве мастеров, и один обновляется, а другой срабатывает.
Наши текущие серверы работают под управлением Ubuntu и Nginx с MySQL, обслуживающим приложение Django. Возможно, я не знаком с отраслевыми терминами, поэтому я объясняю вопрос / проблему. Я не говорю о таких компаниях, как Google, Microsoft или Facebook, поскольку я знаю, что у них есть свои индивидуальные решения для такого рода проблемы, но может ли кто-нибудь помочь мне найти, что по условиям или любому объяснению, статье, публикации или учебнику, который я могу прочитать, чтобы справиться это решение?
Спасибо
У вас есть два основных варианта отключения серверов
Возможно, вам придется быть немного осторожнее с базами данных.
Я бы, вероятно, сделал Nginx с проверками работоспособности, серверы приложений, осведомленные об обеих базах данных с кодом аварийного переключения, репликацией базы данных и сине-зелеными развертываниями. Обязательно хорошо протестируйте сценарии сбоев.
В AWS вы просто должны использовать:
Обновления
База данных должна находиться в том же месте, что и приложения / веб-серверы, чтобы уменьшить задержку. Вы можете переместить всю свою среду в облачную службу, если хотите, но вам нужно понимать среду, а не заряжаться и надеяться на лучшее.
Что касается настройки базы данных master / slave, я, вероятно, не тот человек, чтобы давать советы. Вам нужно будет рассмотреть возможность использования нескольких мастеров, мастеров и подчиненных, а также среду, в которой нет мастера. Затем следует рассмотреть NoSQL, который в некоторых случаях может хорошо подойти.
Я бы, вероятно, посмотрел на главный / подчиненный сервер, когда оба сервера приложений смотрят на одну базу данных, а другой остается в актуальном состоянии. Если вы хотите обновить схему (что, надеюсь, редко), вы можете остановить репликацию, обновить ведомое устройство, а затем указать новую версию приложения на старом ведомом устройстве, новом главном устройстве. В облаке вы, вероятно, просто создадите новые среды для каждого развертывания - серверы в виде крупного рогатого скота, а не домашних животных.
Метод обновления одного сервера, когда другой все еще обслуживает, называется «сине-зеленое развертывание». Вы можете прочитать информацию об этом в блоге Мартина Фаулера здесь: https://martinfowler.com/bliki/BlueGreenDeployment.html
Допустим, у вас есть серверы web1 и web2.
Шаги, которые вам необходимо предпринять:
Я не так хорошо знаком с базой данных, но если вы используете стиль «главный-подчиненный» для настройки базы данных, вы можете настроить свой веб-сайт в режиме обслуживания, в котором он может только читать данные, но не записывать данные с подчиненного сервера. После того, как вы обновили мастер, измените переменную в своем приложении, чтобы она указывала на мастер, и включите обратное чтение / запись.