Как развернуть сайт в производство с минимальным влиянием на пользователей

Question

Я пытаюсь найти лучшее решение серверной архитектуры для развертывания ежемесячных обновлений на внешнем общедоступном веб-сайте Asp.net.То, что я ищу, - это способы выпустить новую версию веб-сайта с минимальным влиянием на пользователей.Помимо развертывания стандартным способом (т. Е. Остановка IIS, копирование нового веб-сайта поверх существующего веб-сайта, запуск IIS), какие существуют «лучшие» решения для развертывания?Было бы неплохо, если бы они продолжали сеанс и не видели сообщение «Сайт находится на обслуживании» во время обновления.

Конфигурация моего сервера

У нас есть 2 веб-сервера IIS (2003 г.), и мы пытаемся найти наилучший способ их использования для развертываний,Моей первой мыслью было обновить неактивный веб-сервер до последней версии.Затем, чтобы изящно направлять веб-трафик на этот сервер с минимальным воздействием на пользователей (в лучшем случае, пользователь не теряет свою сессию).Как бы вы пошли о «повторном назначении» веб-трафика с сервера 1 на сервер 2?Смена брандмауэра NAT?Менять записи DNS?Как-то иначе ??Нам нужно иметь возможность протестировать работающий сайт сразу после того, как мы выпустим новые изменения (да)к производству.Таким образом, все это автоматизировано одним нажатием кнопки.

Может ли быть достигнуто лучшее решение с использованием третьего сервера?Если так, то как?

Answer 1

То, что мы делаем, это

У нас есть балансировщик нагрузки от netscaler,

вынимает один веб-сервер из loadbalancer, делает все развертывания, делает iisreset и возвращает балансировщик нагрузки.

Сделайте то же самое для сервера 2.

Окончательно аннулируйте кэш loadbalancer.

Answer 2

Ну, здесь есть пара вещей:

• Сначала рассмотрите возможность использования решения для балансировки нагрузки.Сервер Windows 2003 поставляется с балансировкой нагрузки Windows (WLBS), хотя это не самый лучший продукт.Это, однако, бесплатно.При этом вы можете направить весь трафик на один сервер, обновить его, а затем сделать обратное.

• Во-вторых, вы можете рассмотреть вопрос о том, как вы работаете с сеансами.HTTP не имеет состояния, что означает, что до тех пор, пока вы можете восстановить сеанс пользователя при любом обращении к странице, все будет в порядке.Одним из идеальных шагов в этом направлении является использование проверки подлинности на основе форм ASP.NET - записанный ими файл cookie не привязан к сеансу ASP.NET.Конечно, такой подход ведет к большему риску - есть вероятность, что пользователи получат экран с ошибкой, если они нажмут что-то, ПРОСТО, КАК вы копируете файлы.И тогда будет задержка при обновлении пула приложений.

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

Answer 3

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

Балансировщик нагрузки будет указывать на рабочие веб-серверы ASP.NET (два в вашем случае, но мыих было три), и веб-серверы должны были настроить свои сеансы для извлечения с третьего сервера, предназначенного для размещения сеанса OutOfProc ASP.NET.

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

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

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

Кроме того, поскольку эта настройка зависит от работоспособности веб-сервера, если вы хотите повысить надежность, вы можете изменить OutOfProc на серверы сеансов на основе SQL.,Вам потребуется несколько серверов, которые реплицируют одну и ту же базу данных сеансов и указывают на них веб-серверы.Более сложный, но уменьшит время простоя сайта.