Вопросы Теги

Что оборотная сторона к липким сессиям с подсистемами балансировки нагрузки?

Месяц или два назад мы столкнулись с подобной проблемой после установки.NET 3,5 SP1 на нашем сервере SharePoint 2007. Наша проблема была вызвана петлевой аутентификацией NTLM. Мы исправили проблемный Метод использования 2, как описано в этой статье KB:

http://support.microsoft.com/kb/896861

13
задан 15 April 2019 в 00:21
3 ответа

Существует две основных оборотных стороны:

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

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

AOL однажды использовала кластеры прокси, и действительно завинченная с подсистемами балансировки нагрузки и липкими сессиями. Большинство подсистем балансировки нагрузки теперь предложит липкие сессии, базирующиеся прочь диапазонов сети C-класса, или со случаем F5, cookie основывал липкие сессии, которые хранят конечный узел в cookie веб-запроса.

В то время как основанные на cookie сессии должны работы, я имел некоторые проблемы с ними и обычно выбираю основанные на IP сессии. БОЛЬШОЙ ОДНАКО: я являюсь главным образом рабочим на внутренних приложениях - демилитаризованная зона milage могла бы варьироваться.

Все, что быть указанным, мы имели некоторый большой успех с сайтами рабочий behing F5 с липкими сессиями и В - Proc сессии.

Вы также могли бы хотеть смотреть на один из в системах распределенного кэширования памяти как Memcached или Velocity для альтернативы сессии, сохраненной в SQL или из proc сервиса памяти. Вы рядом со скоростью в - proc память со способностью выполнить его через несколько серверов.

15
ответ дан 2 December 2019 в 21:22
  • 1
    Помимо ЦП, там способы проверить текущие соединения и/или пропускную способность исходно на машине окон 2008 с IIS7..., чтобы видеть, получает ли сервер также хит / занятый? В основном, что метрики, Вы используете, чтобы удостовериться, что серверы являются not' t быть уничтоженным? –  Pure.Krome 27 July 2009 в 10:27
  • 2
    Мы использовали соединение липкого IP и липких сессий cookie долгое время назад и нашли неравномерное распределение, но не ужасно так. Кластер прокси AOL был кошмаром для кластеризации IP, и мы имели к hardcode исключениям. –  ericslaw 27 July 2009 в 17:25
  • 3
    Собственные Счетчики Перфекта покажут активные HTTP-соединения. –  Christopher_G_Lewis 27 July 2009 в 18:36

Я недавно прочитал большую статью в TechNet относительно "Обеспечения Масштабируемости для Приложений ASP.NET". Это вошло в за и против каждого возможного решения. Возьмите чтение:

Июнь 2009 TechNet - обеспечение масштабируемости для приложений ASP.NET

5
ответ дан 2 December 2019 в 21:22

В дополнение к превосходному ответу от Christopher липкие сессии означают потерю нескольких огромных преимуществ избыточных серверов - способность удалить один или несколько для обслуживания и прозрачности перед лицом системного отказа.

Я считаю липкие сессии сильным индикатором архитектуры некачественного нанесения и/или плохого программирования. "Избегайте любой ценой", мой девиз.

4
ответ дан 2 December 2019 в 21:22
  • 1
    Превосходные мысли об обслуживании. Мы бросаем ДРЕНАЖ на сервер прежде, чем вынуть его из кластера. ИСТОЩИТЕ средства, текущие сессии обрабатываются, но никакие новые сессии, запущенные на том сервере. –  Christopher_G_Lewis 27 July 2009 в 18:35
  • 2
    К счастью никто никогда не должен делать обслуживание в кратчайшие сроки, и при этом сервер неожиданно никогда не перестает работать (порождение всех сессий придерживалось того сервера, чтобы быть внезапно бесполезным - я держал пари, что клиенты любят это). –  womble♦ 28 July 2009 в 01:47
  • 3
    U может ВЫТЕЧЬ из сервера, не имея необходимость делать конфигурацию на самом F5? В основном, мы don' t имеют доступ к F5 (it' s управляемый для нас, в сценарии управляемого хостинга).. но у нас есть полный доступ к нашим веб-серверам.. таким образом, можно ли ВЫСУШИТЬ путем отбрасывания файла или чего-то в веб-сайте? –  Pure.Krome 28 July 2009 в 04:48
  • 4
    Наш F5' s определяют сервер/сервер вниз/дренаж через текстовый файл на веб-сайте - контекст файла является " UP/DOWN/DRAIN". исследуйте свои журналы IIS для определения то, на что они смотрят. Обратите внимание, что иногда F5 просто делает SYN/ACK на порте TCP/IP, в этом случае you' ll должны иметь Ваше изменение hoster F5' s конфигурация. –  Christopher_G_Lewis 29 July 2009 в 05:13

Теги

Похожие вопросы