Комментарии 10
Очень жду продолжения. В частности, правильно ли я понял, что все данные пользователей (сайты, порталы, да бог знает что) хранятся на внешнем хранилище, доступном для все фермы соответственно. Вы используете хардварные решения аля Fiber Channel и какие-то хранилища от известных брендов или тоже реализовали на основе Widows?
Совсем забыл спросить, у вас из вне, условно — интернета, идет несколько стрелок на разные точки входа с маршрутизацией. Как вы при этом обеспечиваете аутентификацию и т.д. на IIS для ASP.NET? Ведь там сервер должен быть один и тот же, конечный. Или все-таки для каждого сайта всегда один и только один ip адрес? Тогда как вам поможет это перекрестие двух входящих серверов на одни и те же локальные сервера?
Если вы имеете ввиду сессии в ASP, то они хранятся во внешней базе. MS уже давно реализовала данный функционал.
Я не корректно выразился. Я имею ввиду то, что в стандартном варианте при аутентификации мы получаем кукис, который привязан к сайту и его ip адресу по умолчанию, ведь ключи генерируются автоматически (без магии одного ключа в web.config). Соответственно авторизовавшись на одном экземпляре (пуле) при входе на другой (при round robin) он потеряет авторизацию. Вот и вопрос, как вы с этим боритесь, и боритесь ли вообще. Может у вас на сайт всегда 1 адрес, и n сайтов маршрутизируются ARR1 а m сайтов ARR2, и n и m никогда не пересекаются. Соответственно и у ARR1 и ARR2 всегда разные адреса.
В ARR реализован так называемый механизм «Sticky session» (липкие сессии). При их использовании, правила балансировки будут срабатывать один раз при первом запросе от клиента. Дальше выдается кукис который содержит уже непосредственно адрес сервера (хэш узла в ферме) к которому было первое обращение. В итоге клиент в рамках активной сессии будет обращаться к одному и тому же серверу. В следующих статьях я расскажу и про это тоже :)
Спасибо! Это я хотел услышать просто очень как! Т.е. дальше они обращаются к тому же ARR, но уже сами знают, к какому серверу дальше их отправят через куку. Ок, спасибо!
Стоп. Я рано радовался, тут подумал и все же мой вопрос остался. Смотрим на ARR1 и ARR2, у них висят разные внешние IP. Какие бы правила не были в ARR1 и ARR2, это не поможет никак клиенту, если у него по Round Robin выдается то ARR1 то ARR2. Ведь так? То, что в рамках ARR одного можно включить (или оно постоянно выключено) сессионность это другое. Получаем в результате, что на DNS реально крутится только 1 адрес на 1 сайт позади одного ARR. Т.е. выход из строя канала до ARR1 никак не будет обработан ARR2. Если же выдавать Round 2 адреса, то как быть с аутентификацией, возможно достаточно машинкей прописать.
Даже если у Вас будет N кол-во хостов ARR они все будут работать в режиме общей конфигурации (Shared config). Хэш который записан в куки клиента является ни чем иным как идентификатор сервера с контентом, не ARR. Поэтому без разницы к какому серверу ARR обратился клиент по RR, они все проверяют кукис клиента и перенаправляют запрос в зависимости от настроек.
Да, все верно. Вся конфигурация фермы и данные хранятся на внешнем хранилище, в случае с Shared-хостингом в этой роли выступает программное решение на базе Windows. Все узлы виртуализированы и размещены на СХД HP 3Par.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ферма IIS и Application Request Routing