Сценарий нескольких ферм – тема непростая, поскольку подразумевает вопрос расширения SharePoint до моделей, для которых просто невозможно осуществлять поддержку. Готовые инструменты не проходят тестирование, поскольку в них нет нормального набора бизнес-требований. Таким образом, вам придется потратить больше времени и средств на внедрение, поддержку, управление и презентацию службы SharePoint для бизнес-клиентов.

Итак, сначала мы выстроим общий план действий и подход к оценке бизнес-требований и технических возможностей SharePoint, чтобы определить, когда необходимо использовать сценарий с несколькими фермами. Затем я расскажу о путанице в среде, которая может возникнуть, когда используется несколько ферм. После этого мы рассмотрим конкретные сценарии, проблемы, которые они вызывают, и способы выживания в среде из нескольких ферм.

Сбор требований

Как бы то ни было, начинать вам придется с бизнес-требований. Я работаю консультантом, и большую часть времени занимаюсь тем, что помогаю потребителям подготовить длинный список требований, которые включают в себя возможности, функции, управление информацией, управление службой и управление проектом (бюджеты и сроки поставки).

Если вы не определите весь спектр требований, то сильно рискуете. Нераспознанные изначально требования непременно проявятся впоследствии.

Подстройка технических возможностей SharePoint

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

Этот шаг называется «архитектура SharePoint». Вам не следует спрашивать «как мы поддержим данный набор инструментов в существующей ферме». Вместо этого стоит задаться вопросом, какую создать архитектуру SharePoint с нуля, чтобы соответствовать новым требованиям? Между этими двумя вопросами большая разница, но к этому я вернусь в подходящий для подобного обсуждения момент.

На данном этапе следует определить элементы и диапазон управления таким образом, чтобы они отвечали требованиям. Элемент управления является чем-то, что вы можете настроить или получить. Это может называться переключателем, настройкой, функцией или возможностью.

Диапазон управления – это логический, ресурсный или информационный контейнер в архитектуре, который подлежит управлению.

Нужно иметь в виду, что определенные виды элементов управления имеют ограничения только на уровне фермы. Существуют конфигурации, характеристики, настройки, функции и возможности, которые применяются ко всей ферме. Ферма может быть либо А, либо Б. Она может быть и А, и Б. И вы не можете преобразовать ферму: нет диапазонов ниже уровня фермы (например, на уровне веб-приложения или уровне коллекции сайта), которые позволят вам получить и А, и Б, существующие внутри одной и той же фермы.

Как только вы приведете в соответствие технические возможности SharePoint со своими требованиями, возникнет вопрос: «как задать архитектуру SharePoint, чтобы она отвечала нашим требованиям?» Возможно, вы захотите, чтобы она отвечала определенному требованию, тогда конкретный элемент управления должен быть «Б».

Если ваша среда SharePoint состоит из фермы, которая называется «А», вы принимаете жесткое решение. Вы либо добавляете ферму к своей службе так, чтобы у вас появилась среда SharePoint, в которой есть ферма с «А» и ферма с «Б», либо говорите, что требование относительно наличия «Б» не может быть выполнено.

Обычно возникают бурные дискуссии, с обсуждением цены и получаемых выгод от дополнительной фермы с возможностью «Б» и рисков отсутствия такой фермы. Руководство должно принять решение, а ваша работа заключается в том, чтобы как минимум предоставить достаточную информацию о возможностях и ценах, преимуществах и рисках принятия того или иного решения.

И сразу же скажу о том, почему необходимо иметь полный набор требований. Если не выявить потребность в каких-либо ресурсах и функциях заранее, вы сочтете, что те требования, которые вы выявили, могут полностью поддерживаться на вашей ферме «А». Позднее (может быть, слишком поздно) вы обнаружите, что проглядели какое-то требование, и осознаете, что построили службу неправильно. А это означает, что либо будет повышенный риск и цена (вы же не сможете отвечать данному требованию), либо что потребуется перенастроить службу. И то, и другое плохо.

Теперь, разобрав «А» и «Б» на общем уровне, мы можем углубиться в детали различных сценариев и типичных требований, которые ведут к среде с несколькими фермами, то есть рассмотреть архитектуры «А» и «Б». Такие сценарии подразумевают:

  • внешний веб-сайт на SharePoint;
  • поддержку развертывания и разработки пользовательского кода или расширений сторонних фирм (это, кстати, есть в каждой локальной среде SharePoint);
  • восстановление после аварии;
  • корпоративную распределенную сеть;
  • высокую рабочую нагрузку;
  • корпоративные службы (поиск, социальная сеть, метаданные);
  • размещение важных прикладных приложений на SharePoint;
  • размещение функциональных приложений, включающих пользовательский код (с полным доверием ему) или инструменты сторонних фирм на SharePoint;
  • удаленные от центра обработки данных офисы, которым необходим доступ к данным.

Каждый из этих сценариев предъявляет важные требования, которые окажут влияние на ваше решение.

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

Архитектура решения для среды из нескольких фермы

Принимая решение о поддержке требований сценария с дополнительной фермой, вы представляете себе цену и риск. Над этим стоит подумать заранее, на этапе оценки соотношения затрат и риска.

К сожалению, если у вас более одной коллекции сайтов в SharePoint, встроенные инструменты и функции начинают деградировать в плане поддержки даже фундаментальных требований.

Давайте возьмем в качестве примера навигацию. У вас более одной коллекции сайтов? Попытайтесь представить ее пользователям при помощи встроенной функции SharePoint, которая должна динамично приспосабливаться к вашей среде. Не работает? А должно. Должно уже 13 лет. Но не работает. Управление пользователями и группами — нет. Аудит и оценка — тоже. И список можно продолжать.

И это касается только случая, когда имеется более одной коллекции сайтов. А когда у вас более одной фермы, особенно в виде гибридной службы (например, Office 365 плюс дополнения), SharePoint поддерживает очень немногое из того, что вам нужно.

Таким образом, архитектура службы должна соответствовать ограничениям платформы. Термин «архитектура службы», в моем понимании, означает множество всех ваших архитектур — технических, логических, информационных, ресурсных, инфраструктурных и доставки служб. Архитектура службы определяет, как все это соотносится и работает, а один компонент архитектуры службы может «компенсировать» отсутствие чего-либо, затраты или риски, которые вносятся другими компонентами архитектуры службы.

Опять-таки навигация – отличный пример: ваша информационная архитектура и управление ею могут быть подготовлены для обеспечения универсальной навигации, которая будет у пользователей вне зависимости от того, как много коллекций сайтов, веб-приложений и ферм существует. SharePoint сам по себе не сильно помогает, но либо настройки конфигурации, сделанные вручную (я этим занимаюсь довольно часто), управление сценариями, прикладные провайдеры навигации, либо инструменты сторонних фирм могут быть добавлены к службе для того, чтобы заставить ее работать как надо.

Процессы, сценарии или инструменты управления сторонних фирм могут компенсировать недостатки управления в сценарии среды из нескольких ферм, и они у вас — на вес золота.

Таким образом, мы не просто архитекторы SharePoint, не просто помогаем найти бизнес-решение, мы помогаем идентифицировать требования, необходимые для бизнеса. Мы — архитекторы, которые складывают в единый рисунок множество кусочков мозаики (вручную, при помощи сценариев, прикладным кодом, решениями сторонних фирм и самим SharePoint).

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

Эти затраты и риски должны быть сопоставлены с исходными требованиями и привести к логической архитектуре из нескольких ферм, но в конечном счете не все требования будут соблюдены. Вы либо принимаете затраты и риски (и стараетесь уменьшить их) для архитектуры, которая поддержит требования рабочей среды, либо предпочтете остаться с одной фермой и учитывать риск (и соответственно затраты), сопутствующий этой ситуации.

В целом, разрабатывать такие решения – задача не ИТ. Служба ИТ, интересы бизнеса и соблюдение различных требований (в законодательстве, системе безопасности, персонала и так далее) должны в совокупности определять решение. Каждый должен вносить свой вклад.

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