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 — ваш наилучший выбор, если вы комфортабельно себя чувствуете при написании кода на более сложных языках программирования.

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.