Совсем недавно мои коллеги написали несколько статей про 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. Данные клиента между ЦОДами могут реплицироваться как в автоматическом режиме, так и по запросу. А поскольку кроме контента реплицируется и вся конфигурация веб-серверов, то это является дополнительным бонусом к снижению издержек на администрирование всего этого хозяйства.

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