В SharePoint 2013 без большого шума появилась новая best-practice, рекомендующая использовать так называемые Host-Named SiteCollection (HNSC). Как обычно это вызывает множество вопросов, на которые я попробую ответить.

Краткий экскурс в историю

Во времена x86 процессоров максимальный объем адресного пространства, которое могло занимать приложение – 2гб. Поэтому для масштабирования был выбран подход, когда вся ферма SharePoint разбивается на несколько “веб-приложений”, каждое из которых представляет один или несколько сайтов на IIS. Тем не менее создание сайтов на IIS – дорогое удовольствие. Каждый сайт запускает как минимум один процесс w3wp, который загружает сборки SharePoint и съедает немало памяти. Поэтому даже придумали лимит веб-приложений.

Еще один фактор, который подталкивает плодить веб-приложения в SharePoint – безопасность. Каждое веб-приложение содержит множество коллекций сайтов, все имеют общий hostname. Это значит что javascript из одной коллекции сайтов может обращаться к ресурсам другой коллекции с правами текущего пользователя (Cross-Site Scripting). А для добавления JavaScript достаточно иметь права хотя бы на одно узле.

Таким образом даже появление x64 версий SharePoint не изменило картину – все использовали веб-приложения и отдельные сайты IIS.

HNSC существовали еще в SharePoint 2003 (только назывались не так). Они позволяли иметь коллекции сайтов с разными hostname в рамках одного веб-приложения SharePoint. Но из-за ограничений и сложностей использования не прижились. В SharePoint 2010 произошло улучшение HNSC в первую очередь для Office 365.

В SharePoint 2013 снова улучшили HNSC и появились некоторые возможности\особенности платформы, которые делают HNSC лучшим выбором.

Для чего нужны HNSC

Обязательно нужно запомнить (ибо понять это сложно): Host-Named SiteCollection это альтернатива веб-приложениям, а не обычным коллекциям сайтов. При использовании HNSC обычные коллекции сайтов, официально называемые Path-Based SiteCollection, все так же доступны.

Как я писал выше, HNSC позволяют создавать коллекции сайтов с разными hostname в рамках одного веб-приложения. В SharePoint 2013 HNSC также научлись поддерживать несколько hostname в разных зонах и SSL Termination и разные режимы аутентификации на основе зон.

С точки зрения API обычные коллекции сайтов не отличаются от HNSC. Важно только помнить что SPSite.Url  может не совпадать ни с одним из Url в объекте SPSite.WebApplication.

Применять HNSC нужно по трем причинам:

  1. Экономия ресурсов.
    Все HNSC живут в одном веб-приложении, следовательно в одном процессе w3wp. Это означает, что загружена только одна копия сборок SharePoint, что уменьшает оверхед на пару сотен мегабайт на процесс.
  2. Совместимость с apps.
    Для того чтобы работали apps нужен wildcard-сайт, который принимает запросы на любой hostname, потому что AppWeb создается с уникальным hostname.
    Но AppWeb это все еще сайт SharePoint, поэтому требуется загрузка всех объектов SharePoint в процесс веб-сайта, обсуживающего apps.
    Если все коллекции сайтов находятся в одном сайте IIS, то это также уменьшает оверхед и упрощает, в итоге, настройку IIS.
  3. Новые фичи SharePoint 2013.
    В SharePoint 2013 появилась фича Request Management, позволяющая управлять WFE. Request Management позволяет задать какой WFE будет обрабатывать запросы какого типа. Конфигурация может быть динамической, учитывающей состояние сервера (нагрузка, ресурсы итд). Microsoft говорит что эта фича тестировалась только с HNSC и в будущем новые фичи будут работать в первую очередь с HNSC.

Недостатки HNSC

Увы использовать HNSC не так просто. Central administration сайт не умеет создавать HNSC, поэтому всю работу надо будет делать в PowerShell.

Тем не менее для любителей тикать мышкой есть проект на codeplex: https://hnsc.codeplex.com/https://hnsc.codeplex.com/.

Кроме того HNSC обеспечивают гораздо меньшую изоляцию ресурсов сервера, по сравнению с веб-приложениями. Все HNSC будут иметь общие настройки веб-приложения, такие как throttling, настройки корзины, настройки безопасности и аутентификации, общие managed paths, итд. У всех HNSC будет общий web.config и общий app pool. Это значит что установка приложений будет затрагивать все HNSC.

Как создавать HNSC

Я не буду писать множество PowerShell команд для создания и настройки HNSC. На MSDN есть прекрасный гайд по HNSC (даже с достойным переводом на русский язык), который описывает разные топологии, а также процесс перехода от Path-based sitecollections к HNSC.

Ссылка на гайд: http://technet.microsoft.com/ru-ru/library/cc424952.aspx.

Дополнительные материалы для тех, кто решит использовать HNSC:

Заключение

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

Теги : SharePoint 2013, sp2013, Architecture