Sharepoint изнутри: Создание инфраструктуры SharePoint

Так же, как электронная почта изменила деловое общение, совместная работа на основе веб-технологий меняет процесс взаимодействия людей и обмена информацией. В качестве хорошего примера рассмотрим возможности, предоставляемые технологией SharePoint. Службы Microsoft Windows SharePoint Services (WSS) 3.0 и сервер Microsoft Office SharePoint Server (MOSS) 2007 позволяют создавать узлы групп, порталы, решения для управления веб-содержимым, библиотеки документов и центры поиска, не говоря уж об интеграции выпуска 2007 системы Microsoft® Office, формах на основе XML, потоках работ, поддержке мобильных устройств и т.д.

Однако приступить к работе с SharePoint® не всегда просто. Терминология может сбивать с толку. Архитектура системы может быть очень сложной, а для SharePoint необходимо использование множества компонентов, включая IIS, Microsoft .NET Framework, SQL Server® и, возможно, других технологий, таких как бизнес-аналитика, служба форм InfoPath®, служба управления правами (RMS), Exchange Server и ForefrontTM Security.

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

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

Первоначальное рассмотрение архитектуры SharePoint упрощает ознакомление с действиями по развертыванию и настройке, необходимыми для реализации гибкой и масштабируемой инфраструктуры. Так что давайте взглянем на зависимости, а затем перейдем непосредственно к развертыванию WSS 3.0. Подробные указания по развертыванию приведены в сопровождающих справочных материалах. Их можно найти в разделе загрузок кода на веб-узле журнала TechNet Magazine по адресу technetmagazine.com.

Архитектура SharePoint

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

SharePoint – это технология для подготовки веб-приложений и узлов. Это решение для веб-узлов на основе IIS, интегрированное с IIS посредством ASP.NET и использующее серверную часть базы данных SQL Server для хранения данных настройки и содержимого. Вкратце, SharePoint сочетает три различные архитектуры (IIS, .NET и SQL Server), как показано на рис. 1.

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

Как показано на рисунке, SharePoint полагается на службы IIS и платформу ASP.NET для обработки запросов и ответов HTTP. Стандартные компоненты служб IIS, такие как драйвер HTTP режима ядра (http.sys) и рабочий процесс (w3wp.exe), выполняют первоначальную постановку в очередь и маршрутизацию запросов, пока они не поступают фильтру ISAPI платформы ASP.NET (aspnet_isapi.dll). При установке .NET Framework библиотека aspnet_isapi.dll регистрируется в метабазе служб IIS (C:\Windows\System32\Inetsrv\metabase.xml) следующим образом:

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll 
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll  
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

После загрузки службами IIS фильтра ISAPI платформы ASP.NET все входящие запросы для веб-узла могут быть переданы платформе ASP.NET, что важно, поскольку SharePoint необходимо в конечном счете получить эти запросы через платформу ASP.NET. Для этого SharePoint расширяет настройку выбранного веб-узла the путем добавления сопоставления с подстановочными символами для приложений, маршрутизирующего все входящие запросы независимо от расширения имени файла к фильтру ISAPI платформы ASP.NET.

Это можно увидеть в диспетчере служб IIS после установки WSS 3.0 при выборе базовой установки. Программа установки WSS отключает существующий веб-узел IIS по умолчанию на сервере и создает новый веб-узел по умолчанию для порта 80 с определенным сопоставлением с подстановочными символами для приложений ASP.NET, как показано на рис. 2.

Чтобы платформа ASP.NET в свою очередь передавала запросы серверу SharePoint, SharePoint должен расширить конвейер обработки запросов HTTP посредством настраиваемого объекта HttpApplication, реализуемого с помощью класса SPHttpApplication сборки Microsoft.SharePoint. SharePoint определяет этот настраиваемый объект приложения в файле приложения ASP.NET (global.asax), который находится в корневой папке расширенных с помощью SharePoint веб-узлов в файловой системе. Ниже приведено содержимое такого файла global.asax:

<%@ Assembly Name="Microsoft.SharePoint"%>  
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

Платформа ASP.NET динамически обрабатывает и компилирует этот файл для создания экземпляра объекта приложения SharePoint.

Для каждого полученного запроса платформа ASP.NET запускает серию событий, которые может обработать веб-приложение, таких как BeginRequest, AuthenticateRequest, ProcessRequest и EndRequest. Подробная информация об обработке ошибок выходит за рамки развертывания и управления SharePoint, хотя важно знать, что помимо класса SPHttpApplication, указанного в файле global.asax, SharePoint также реализует настраиваемые обработчики данных и модули HTTP, определенные в файле web.config для узла. Например, SharePoint использует модуль HTTP на основе класса SPRequestModule, зарегистрированноый в качестве первого модуля HTTP до стандартных модулей ASP.NET. SPRequestModule инициализирует среду выполнения SharePoint путем регистрации компонента SPVirtualPathProvider в ASP.NET. Модуль SPRequestModule предназначен для внутреннего использования SharePoint, но разработчики решений SharePoint могут изменить файл web.config для регистрации дополнительных компонентов, таких как настраиваемые обработчики данных и модули HTTP. Настраиваемые и стандартные модули HTTP позволяют SharePoint использовать преимущества ASP.NET, сохраняя жесткий контроль над всеми запросами к приложениям SharePoint.

Имейте в виду, что при создании веб-приложения с помощью узла центра администрирования SharePoint 3.0 службы WSS добавляют к выбранному веб-узлу IIS сопоставление с подстановочными символами для приложений ASP.NET и создает в корневой папке веб-узла файлы global.asax и web.config. Каждое веб-приложение использует собственный набор файлов global.asax и web.config высокого уровня.

Для обработки запросов и возврата обозревателям значимых данных WSS 3.0 и MOSS 2007 используют стандартный анализатор страниц ASP.NET, который компилирует запрошенные страницы ASP.NET или обрабатывает их в режиме без компиляции. Но страницы ASP.NET, передаваемые службами SharePoint анализатору ASP.NET, не обязательно находятся там, где кажется. Например, файл default.aspx не удастся найти в корневой папке расширенного с помощью SharePoint веб-узла, такого как узла центра администрирования SharePoint 3.0, хотя файл default.aspx открывается при отображении домашней страницы этого веб-узла. Именно компонент SPVirtualPathProvider виртуализируюет среду путем загрузки содержимого страницы из локальной файловой системы или базы данных содержимого SQL Server и его передачи анализатору страницы ASP.NET в качестве виртуального файла. Для узла центра администрирования SharePoint загружает файл default.aspx из папки C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.

Домашняя страница, также как и большинство других страниц узлов SharePoint, связана с главной страницей ASP.NET (default.master), реализующей общий макет для меню и элементов управления переходами. Страница Default.master находится в папке C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global и имеет в своем составе именованные заглушки для других страниц содержимого в локальной файловой системе или базе данных содержимого SQL Server. Ключевой момент заключается в том, что при открытии узла SharePoint в веб-обозревателе на самом деле отображается информация коллекции страниц содержимого, которые могут быть размещены не на локальном веб-сервере и упорядочены в соответствии с макетом, определенным главной страницей.

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

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

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

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

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

WSS 3.0 не поддерживает контекстный поиск по нескольким семействам узлов. Для такого поиска необходим MOSS 2007 или Microsoft Search Server 2008. Например, можно создать веб-приложение и узел верхнего уровня для http://contoso, а администратор семейства узлов затем может создать узлы подуровней, используя пользовательский интерфейс SharePoint, например, http://contoso/info и http://contoso/events. Все эти узлы находятся в одной базе данных содержимого, поскольку принадлежат одному семейству узлов.

Вы, как администратор фермы, также можете использовать управляемый путь, такой как /sites, а затем определить дополнительные семейства узлов, например, http://contoso/sites/IT и http://contoso/sites/HR, в центре администрирования SharePoint 3.0. У этих трех семейств узлов (http://contoso, http://contoso/sites/IT и http://contoso/sites/HR) могут быть различные администраторы, параметры настройки и базы данных содержимого, но доступ к ним осуществляется через один веб-узел IIS (http://contoso), и все три семейства используют одно удостоверение пула приложений веб-приложения.

Конечно, существует гораздо больше деталей, но эта взаимосвязь IIS, ASP.NET и SQL Server особенно важна для понимания успешной работы со SharePoint. Тем, кто хочет поближе познакомиться с архитектурой SharePoint, я рекомендую статью Теда Паттинсона в журнале MSDN® Magazine, озаглавленную «Значительные улучшения служб SharePoint Services для разработчика» и доступную по адресу msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

Элементы инфраструктуры SharePoint

Теперь в рамках нашего краткого обзора архитектуры рассмотрим гибкую инфраструктуру SharePoint. Как вы наверняка заметили, нам необходимы Windows Server®, IIS, .NET Framework 3.0 (для ASP.NET и Windows® Workflow Foundation), WSS 3.0 или MOSS 2007 и SQL Server. Хотя вы можете рассчитывать использовать службы IIS 7.0 на Windows Server 2008, для наших целей мы будем использовать IIS 6.0 на Windows Server 2003, поскольку на момент написания данной статьи это наиболее распространенная развертываемая версия. Мы будем использовать WSS 3.0, поскольку для начального экспериментального проекта SharePoint не требуются функции MOSS 2007.

При минималистском подходе можно установить WSS 3.0 со всеми необходимыми компонентами на одном компьютере (как описано в файле WSS 3.0 on a single computer.pdf, входящем в состав сопровождающего материала для этой статьи), что достаточно для лабораторного сервера или среды небольшой рабочей группы. Однако если вашей целью для инфраструктуры SharePoint является гибкость, не следует начинать с отдельного развертывания в вашей рабочей среде. В целях обеспечения доступности и расширяемости в будущем лучше начать с многоуровневой архитектуры и добавить необходимое количество серверов.

На рис. 4 показана рекомендуемая инфраструктура SharePoint, если необходима простая и гибкая структура системы. В ее состав входит веб-ферма, состоящая из двух серверов SharePoint и отдельного компьютера с установленной базой данных SQL Server. Такая структура уменьшает затраты на обработку базы данных на веб-серверах, улучшает доступность и масштабируемость, а также упрощает обслуживание системы. Имейте в виду, что необходима служба Active Directory®, так как это требование к программному обеспечению WSS 3.0 в развертывании веб-фермы. Поэтапные указания по развертыванию приведены в файле Basic SharePoint Infrastructure.pdf в материале, сопровождающем данную статью.

Для учетной записи домена, используемой для развертывания SharePoint в такой сборке, необходимы права локального администратора на веб-серверах. Также необходимо добавить эту учетную запись к ролям создателя баз данных и администратора безопасности SQL Server, а также к роли владельца базы данных для главной базы данных SQL Server 2005, как показано в файле Basic SharePoint Infrastructure.pdf. После этого при установке WSS 3.0 можно использовать мастер настройки продуктов и технологий SharePoint для создания необходимой базы данных настройки для фермы веб-серверов и базы данных содержимого для узла центра администрирования SharePoint 3.0. В противном случае администратор SQL Server должен предоставить вам эти базы данных и добавить к роли владельца базы данных системные учетные записи WSS.

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

Мастер настройки продуктов и технологий SharePoint выдаст запрос на ввод сведений об учетной записи. Рекомендуется использовать специальную учетную запись пользователя домена, такую как CONTOSO\WssConfigAdmin. Обычно я использую специальные, выделенные учетные записи пользователей для всех создаваемых позже дополнительных веб-приложений. Использование отдельного пула приложений для каждого веб-приложения помогает обеспечить изоляцию процесса, а использование различных учетных записей пользователей для всех пулов приложений помогает поддерживать изоляцию безопасности. Тем не менее, следует обратить внимание на то, что это всего лишь один из возможных подходов, и необходимо оценить управляемость и возможное воздействие на производительность с точки зрения вашей среды и бизнес-требований.

Другая важная системная учетная запись, которая должна быть создана для вас администратором домена, – учетная запись службы поиска. Можно использовать учетную запись центра администрирования, но для обеспечения повышенной безопасности лучше использовать специальную учетную запись поиска, например, CONTOSO\WssSearch, которая не имеет прав администратора и не может изменять никакое содержимое. Разрешение на запись в базах данных содержимого не требуется, поскольку служба поиска выполняет обход содержимого только для целей индексирования и хранит данные поиска в отдельной базе данных.

При создании веб-приложения в ферме серверов можно связать базу данных содержимого с сервером поиска, который неявным образом добавляет соответствующую учетную запись службы поиска к политике «Чтение любых элементов» веб-приложения. Подобными серверами являются серверы SharePoint, на которых запущена служба поиска Windows SharePoint Services. Если вы выполнили поэтапные указания в файле Basic SharePoint Infrastructure.pdf, вы настроили оба веб-сервера в качестве серверов поиска таким образом, чтобы можно было распределить нагрузку на обход содержимого и индексирование нескольких баз данных содержимого. Однако также можно настроить специальный сервер поиска в веб-ферме, исключенный из балансировки сетевой нагрузки и клиентских подключений, чтобы действия по обходу содержимого не влияли на клиентские подключения.

Управление средствами самостоятельного создания узлов

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

Также можно предоставить пользователям возможность создания семейств узлов по управляемым путям (например, путям /sites или другим путям со включениями по подстьановочным символам, созданными в центре администрирования SharePoint 3.0). При включении функции управления средствами самостоятельного создания узлов в веб-приложении пользователи могут создавать собственные семейства узлов и управлять правами и группами узлов с помощью пользовательского интерфейса SharePoint. В отличие от узлов подуровней, семейства узлов не наследуют права от родительского узла.

Управление средствами самостоятельного создания узлов подходит не для всех сред SharePoint и по умолчанию отключено. Включение этой функции может привести к появлению большого числа редко используемых семейств узлов в базах данных содержимого. Однако она весьма наглядно демонстрирует гибкость администрирования SharePoint, и я рекомендую включить ее в экспериментальном развертывании. (Кроме того, в SharePoint существует возможности уведомления пользователей и/или администраторов о неактивных узлах, чтобы их можно было при необходимости удалить.) Необходимо включить управление средствами самостоятельного создания узлов в веб-приложении явным образом, как указано в файле Enabling Self-Service Site Management.pdf, входящем в материал, сопровождающий данную статью.

Индивидуализации SharePoint и включение стиля компании

В данный момент возникает естественное желание включить логотип, название и фирменную раскраску компании в пользовательский интерфейс SharePoint. Однако, необходимо учитывать, что это означает вывод проекта SharePoint на уровень разработчика ASP.NET. Как минимум, необходима система разработки, например, отдельный сервер WSS 3.0 с программой Microsoft Office SharePoint Designer 2007 (см. файл SharePoint Designer Installation.pdf в материале, сопровождающем данную статью), чтобы можно было внести и протестировать изменения, не влияя на рабочую среду. Также необходимо посетить центр разработчиков Windows SharePoint Services Developer Center по адресу msdn2.microsoft.com/sharepoint для получения дополнительных сведений о множестве вариантов настройки, предоставляемых SharePoint.

Хотя разработка While SharePoint не рассматривается в данной статье, я отмечу несколько моментов, которые необходимо учитывать. SharePoint сохраняет индивидуализированные страницы в базе данных содержимого соответствующего семейства узлов. Другими словами, все индивидуализациии, выполненные для страниц узла, страниц приложения, главных страниц, таблиц стилей и т.д. на узле SharePoint, применяются только на уровне узла или семейства узлов. Это очень существенно для администраторов отдельных семейств узлов, которым необходимо изменить вид и функции соответствующих узлов с помощью SharePoint Designer 2007, но не очень хорошо для администраторов ферм, которым необходимо применить фирменный стиль ко всем веб-приложениям, семействам узлов или узлам в веб-ферме.

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

Для глобального применения стиля компании необходима замена компонентов SharePoint по умолчанию, чтобы вместо них использовались пользовательские компоненты. Разработчики далеко продвинулись в сторону выполнения этой задачи без изменения исходных файлов. Одним из подходов является изменение настройки виртуальных каталогов в диспетчере служб IIS и их указание на новые папки с настроенными файлами. Другой способ – реализация настраиваемого модуля HTTP или фильтра ISAPI, переписывающего URL-адреса для перенаправления запросов для отдельных страниц по умолчанию на индивидуализированннные версии.

Заключение.

В данной статье были рассмотрены основные моменты установки инфраструктуры SharePoint с WSS 3.0. Не рассматривались ни другие функции, такие как потоки работ, опросы, интеграция системы обмена сообщениями и антивирусы, ни специальные функции MOSS 2007, такие как порталы, каталоги узлов и бизнес-данных. Индивидуализация для администрирования узлов и фирменного стиля компании также рассматривалась только с помощью средств SharePoint. Дальнейшая индивидуализация может быть выполнена с помощью WSS 3.0 путем создания пользовательских приложений в Visual Studio®.

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