Inoventica Services
Компания
67,26
рейтинг
13 января в 09:59

Разработка → Ферма IIS и Application Request Routing



Совсем недавно мои коллеги написали несколько статей про shared-хостинг на базе Cloud Linux, а сегодня я расскажу вам про технологии Microsoft которые мы используем для услуги Windows-хостинга. Речь пойдет про связку IIS 8.5 и Application Request Routing (ARR).

ARR — это расширение для IIS которое позволяет собирать множество серверов IIS в единую ферму. Оно позволяет производить балансировку нагрузки HTTP-трафика, использовать правила маршрутизации и может выступать в роли кэширующего Reverse Proxy-сервера для разгрузки основных серверов предоставления контента.
ARR может распределять трафик различными способами:
  • Weighted round robin – самый простой тип балансировки. Запросы будут распределяться между всеми серверами по очереди.
  • Weighted total traffic – запросы будут распределяться на основе их размеров, и перенаправляться на менее загруженные узлы.
  • Least response time – запрос будет отправлен на любой откликнувшийся раньше всех сервер.
  • Sticky sessions – в этом режиме все запросы клиента в рамках сессии будут передаваться на один и тот же сервер.

Еще очень важной фичей является возможность использовать правила фильтрации URL. С помощью регулярных выражений можно перенаправлять запросы HTTP и HTTPS по отдельности на разные фермы IIS.
Внутри фермы постоянно происходит проверка «пульса» всех узлов. В случае если узел «умер», ARR перестанет направлять на него запросы.
Проверка узлов производиться двумя способами:
  • Проверка доступности сайта, расположенного в ферме, обычным GET-запросом. Опрос происходит по заранее определенному интервалу. Обычно для этого используется заранее развернутый сайт с техническим именем.
  • Мониторинг живого трафика к сайтам.

Разница между ними лишь в том, что в режиме мониторинга ARR не будет прекращать запросы на узлы фермы в случае выхода их из строя. А лишь делать пометку для администратора, давая таким образом возможность ручного управления. А уже при включенном опросе URL, в случае недоступности узла, он будет переведен в паузу.
ARR можно использовать не только для веб-хостинга, но и для балансировки нагрузки на другие сервисы, которые работают по протоколу HTTP. Пример тому, публикация Exchange OWA (Outlook Web Access), отлично подходит для организации доступа к почте для большого количества клиентов.
Начиная с Windows Server 2012 появилась возможность хранить все SSL-сертификаты в одном, доступном для всех узлов месте. Это значительно упрощает эксплуатацию всей фермы т.к. теперь не приходиться тратить кучу времени на установку и управление сертификатами.

Как это работает у нас?

Раньше для предоставления shared-хостинга на базе Windows, мы использовали одиночные сервера. По мере их заполнения появлялись новые и новые узлы, которые не были объединены единой конфигурацией. Со временем это стало доставлять неудобства как для клиентов, так и для системных администраторов, которым приходилось обслуживать весь этот зоопарк. В качестве примера можно привести обновление ОС на веб-сервере, требующее перезагрузки, а в следовательно и приостановки работы всех сайтов, размещенных на нем.

Сейчас я расскажу вам, про минимальную отказоустойчивую конфигурацию которая используется в основе нашего shared-хостинга.



Все компоненты фермы размещены в облачной инфраструктуре, что уже на уровне оборудования сводит возможность отказа к минимуму. Одним из самых важных компонентов является хранение данных т.к. распределение нагрузки теряет всякий смысл если пользовательский контент будет недоступен, поврежден или что еще хуже безвозвратно утрачен. Для решения этой задачи, данные размещены на кластеризованном файловом хранилище.
Кроме сайтов клиентов на нем еще хранятся:
  • Общие конфигурационные файлы серверов IIS и ARR. Это является одним из условий работы фермы.
  • Общее хранилище SSL-сертификатов. С IIS 8.0 больше нет необходимости производить установку клиентских сертификатов на каждом узле ферм, как это было в предыдущих версиях.

В итоге получается, что вся конфигурация и пользовательские данные не хранятся на самих веб-серверах. Это значительно упрощает настройку серверов, хранение и резервное копирование данных. Ферма веб-серверов и балансировщиков нагрузки, может быть горизонтально масштабирована новыми узлами. Для доступа клиентов к своему контенту, организован отдельный хост, который выступает в роли FTP-сервера и сервиса Web Deploy. На нашем shared-хостинге одинаково комфортно чувствуют себя сайты, написанные на PHP и ASP.NET.

Хостингом наши клиенты управляют через личный кабинет. Все задачи, которые пользователь отправляет на выполнение ставятся в очередь и за дело берется оркестратор. Он-то и управляет всеми услугами Windows-хостинга с помощью PowerShell-сценариев.

Но бывают и особо требовательные клиенты. Нам есть что предложить и им: гео-распределенные фермы. Они физически разнесены по нескольким ЦОДам. Репликация данных происходит на уровне файловых хранилищ. Для этого отлично подходит DFS. Данные клиента между ЦОДами могут реплицироваться как в автоматическом режиме, так и по запросу. А поскольку кроме контента реплицируется и вся конфигурация веб-серверов, то это является дополнительным бонусом к снижению издержек на администрирование всего этого хозяйства.

На сегодня все, в следующей статье я постараюсь подробно описать как заставить все это жить в гармонии и бесперебойно выполнять свои обязанности.
Автор: @consolko
Inoventica Services
рейтинг 67,26
Компания прекратила активность на сайте

Комментарии (10)

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка

Интересные публикации