SharePoint 2010: Создайте свою ферму SharePoint

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

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

Следующий интерфейс, доступный из командной строки Windows, — средство администрирования  SharePoint, известное как STSADM. Подстрока STS в названии этого средства восходит к прошлым временам, когда SharePoint называли SharePoint Team Services.

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

Важно заметить, что Microsoft считает инструмент STSADM устаревшим и, возможно, исключит его из будущих версий продукта. Новые сценарии следует писать, используя интерфейс SharePoint 2010 Management Shell.

Последний интерфейс основан на среде Windows PowerShell. Как раз он и называется SharePoint 2010 Management Shell. Это среда, основанная на командной строке, позволяющая создавать более гибкие объектно-ориентированные сценарии. Как и средство STSADM, Management Shell поддерживает множество команд (так называемых командлетов Windows PowerShell), выполняющих действия по настройке SharePoint.

Одно из преимуществ интерфейса Management Shell — то, что он позволяет более просто выполнять многократные операции благодаря таким встроенным возможностям как циклы и связки команд. Он является объектно-ориентированным, а не ориентированным на командную строку, так что Management Shell — ваш лучший выбор, если вы комфортно себя чувствуете при написании кода на более сложных языках программирования.

Выбор между тремя интерфейсами администрирования определяется в основном удобством и привычностью для администраторов, которые с ними работают. За очень небольшим исключением, можно делать все, что вам нужно, в любом из них. Для автоматизации операций CA — не лучший выбор. STSADM — более простой, но менее гибкий интерфейс, просто потому, что командный язык Windows устанавливает свои ограничения. Кроме того, Microsoft придерживается стратегии отхода от пакетной среды и продвижения Windows PowerShell как более перспективного варианта. Если вам интересно освоить один из интерфейсов командной строки, то, скорее всего, вы выберете Management Shell.

Управляемые учетные записи SharePoint

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

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

К сожалению, многие из этих подходов делают управление учетными записями служб настолько сложным, что лишь немногие организации добросовестно им следуют. Чтобы упростить использование передовых методик защиты учетных записей служб, в SharePoint 2010 ввели управляемые учетные записи.

Управляемая учетная запись — это учетная запись службы, зарегистрированная в SharePoint. Это доменная учетная запись Active Directory, которой предоставили набор разрешений для определенной роли серверной фермы. Имя пользователя и пароль создаются для SharePoint один раз. При необходимости можно их повторно использовать при настройке фермы. Эти учетные записи служб, как правило, настраиваются при первоначальной установке фермы серверов. Однако при необходимости можно перенастроить их в дальнейшем.

Самой сложной частью работы с учетными записями служб всегда было регулярное изменение паролей. Как только в Active Directory меняли пароль, зависящие от него службы переставали работать до тех пор, пока пароль вручную не обновляли во всех местах, где использовалась учетная запись, а число таких мест в отдельных конфигурациях могло доходить до сотен. Очевидно, это отнимало время и было чревато ошибками. В результате так поступали редко. Напротив, при использовании управляемых учетных записей их удостоверения безопасно хранятся в SharePoint.

В SharePoint даже предусмотрена возможность регулярной автоматической генерации паролей. SharePoint меняет пароль Active Directory и сохраняет сгенерированный криптостойкий пароль в своей конфигурации. Благодаря этому обеспечивается безопасность учетных записей без необходимости ручного изменения паролей.

Компоненты SharePoint

Большую часть функций платформы SharePoint можно включить или отключить, используя компоненты. Включение компонента может радикально изменить поведение сайта SharePoint. Отличный пример — такой компонент SharePoint, как Publishing. Когда вы активизируете этот компонент, на сайте, на котором раньше был простой контент, внезапно появляются новые библиотеки, рабочие процессы и механизмы публикации страниц.

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

«Песочница»

«Песочница» — новый компонент, введенный в SharePoint 2010. Ее также называют User Code Service. Предназначение «песочницы» — позволить добавлять в среду SharePoint недоверяемый исполняемый код, не подвергая риску безопасность, производительность и надежность серверной фермы. О коде, развернутом в службе «песочницы», говорят, что он «выполняется в песочнице».

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

• Код, выполняемый в «песочнице», развертывают в Site Solution Gallery набора сайтов, и он всегда выполняется в контексте этого набора сайтов.
• Код, выполняемый в «песочнице», может обращаться к ресурсам только того набора сайтов, в котором развернут.
• Набор операций, доступных коду, выполняемому в «песочнице», существенно ограничен за счет использования ряда прокси-библиотек SharePoint API и политик Code Access Security (CAS).
• В конечном счете, за развертывание и удаление кода, выполняемого в «песочнице», отвечают администраторы набора сайтов.
• Администраторы фермы отвечают за настройку службы «песочницы», наблюдение за ее использованием и задание квот, позволяющих автоматически отключать код, выполняемый в «песочнице» и не соответствующий требованиям.
• Формы InfoPath могут содержать управляемый код .NET, который будет выполняться в «песочнице», когда его запускают, работая с формами в браузере.

Собственный код, выполняемый вне «песочницы», потребуется развернуть в Solution Gallery серверной фермы. Только тогда он будет работать в полностью доверяемой среде выполнения. Поэтому его надо тщательно протестировать и проверить перед развертыванием.

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

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

Профили пользователей и My Sites

Профиль пользователя SharePoint содержит все метаданные об определенном пользователе. Это могут быть имя, телефон, местонахождение офиса, специальности и навыки. Можно также добавлять в профили SharePoint собственные метаданные. Данные профилей могут вводить либо сами пользователи, либо внешние системы, такие как база данных отдела кадров или Active Directory.

SharePoint User Profile Service хранит профили и управляет ими. Эта служба предоставляет общий набор данных о пользователях для всей фермы. Можно настроить службу, адаптировав ее поведение под свои нужды, следующими методами:

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

Кроме того, компонент профилей пользователей поддерживает функции социальных сетей. Сюда входят рейтинги и тэги, сопоставляемые контенту фермы. Также это могут быть заметки и ссылки на внешние ресурсы. Можно управлять этими социальными функциями с помощью разрешения Use Social Features.

Компонент My Sites позволяет каждому пользователю, прошедшему аутентификацию, создавать веб-сайт, используемый в качестве личного рабочего пространства. Кроме того, с помощью этого сайта пользователь может делиться информацией с другими или создавать в закрытой области новый контент, предназначенный для публикации в дальнейшем. My Sites часто содержит важную личную информацию, поэтому необходимо планировать и настраивать эту функцию с осторожностью. Объем данных, хранящихся в My Sites, можно ограничить, чтобы система не переполнялась личными данными. Можно также отключить компонент My Site на уровне фермы или предоставить доступ к нему ограниченному количеству пользователей с помощью разрешения Use Personal Features.

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