Назад | Перейти на главную страницу

Рекомендации по обновлению работающей веб-службы

Мне всегда любопытно, как выполняются масштабные обновления веб-приложений в реальном времени. Поскольку приложение работает, поэтому оно все усложняет - вы не должны отключать свой сервис, и в то же время вы должны восстановить активность / изменения (в базе данных и т. Д.), Сделанные на вашем сайте, до новой версии во время обновления позже .

Первый и самый естественный прием, который приходит в голову, - это перенаправление всех запросов на какой-либо другой реплицированный сервер, чтобы вы могли обновить исходный сервер, не завершая работу службы.

Мне просто интересно, есть ли другие более разумные методы обработки обновлений в живом веб-сервисе. Ребята, поделитесь опытом и мнениями!

Вы загружаете свой сайт на один сервер? Если нет, то я предполагаю, что у вас есть какой-то балансировщик нагрузки. Если вы загружаете один сервер, выполните горизонтальное масштабирование и установите балансировщик нагрузки.

Удовольствие от наличия такой услуги позволяет вам не только быть высокодоступным, но и, если вам нужно работать над своим приложением, вы можете отключить один из серверов от приема трафика во внешний мир, а затем работать над обновлением / тестированием вашего приложения / веб-сайта. в периоды менее загруженного движения.

Я загружаю свои веб-сайты и приложение (на самом деле то же самое) на 15 серверов, и некоторые из них используются как «Серверы извинения», где, если мои основные серверы заняты, я могу загрузить их на «Извините». В этой ситуации я могу работать над своими запасными частями и обновлять их, а затем, когда я доволен тем, что все работает, я медленно вытаскиваю одну коробку из пула за раз и работаю над этим ..

Мониторинг вашего веб-сайта / сетевого трафика с помощью чего-то вроде Cacti (www.cacti.net) позволит вам видеть ваше загруженное время на основе трафика, а затем работать над обновлением вне периодов занятости.

Надеюсь, это даст вам немного света.

Обычно для решения этой проблемы мы выполняем «постепенное обновление». Это означает, что вместо одного сервера, обрабатывающего всю вашу нагрузку, у вас есть N серверов. Вы можете «вывести сервер из строя», например, просто остановив веб-сервер apache. Нам нужен другой механизм, чтобы поддерживать сервер в рабочем состоянии с точки зрения apache, но защищать его от входящих подключений клиентов. Мы делаем это с помощью простого текстового файла, наличие которого указывает нашему балансировщику нагрузки пометить вес этого сервера как 0.

Для балансировки нагрузки мы используем виртуальный сервер Linux с открытым исходным кодом или LVS: http://www.linuxvirtualserver.org

Он поддерживает проверку работоспособности «реального сервера». Мы периодически запускаем эту проверку работоспособности, чтобы поддерживать список активных веб-серверов за балансировщиком нагрузки.

Помечая хост для обновления, обновляя отдельный сервер за раз, отправляя на него тестовый трафик, подтверждая его работу, а затем считывая его в пул, мы можем эффективно выполнять обновления до действующей службы.

Сложнее сделать на уровне БД, когда мы говорим об изменениях схемы онлайн ... но есть решения, например, Tungsten Cluster в пространстве MySQL, которые пытаются решить эту проблему.