Программно-аппаратная архитектура портала на базе MS SharePoint

Авторы: Р.Носков, А.Марков

В ходе общения с заказчиками интранет порталов, мы обнаружили характерный факт: обращающиеся к нам за консультациями представители компаний не всегда представляют, как будет реализовываться внутренний портал, какое базовое программное обеспечение и какие аппаратные мощности будут использоваться. Иногда даже встречаются ожидания, что наш продукт «СДЦ. Типовой портал» – нечто вроде дистрибутива программы, установив которую на собственный компьютер, пользователь получит все преимущества SharePoint. Конечно, это не так. Типовой портал строится на основе Microsoft SharePoint – гибкой, эффективной и масштабируемой платформы, которая позволяет создавать порталы очень и очень разных масштабов и стоимости. Для того чтобы ввести посетителей нашего сайта в аппаратно-программные особенности этой платформы, мы и публикуем эту статью.

1. Базовая архитектура

Прежде всего, рассмотрим, какое программное обеспечение (ПО) необходимо для создания портала. Будем описывать его последнюю версию – SharePoint 2013, и постараемся привести максимальную степень детализации, указывая наименования, но не указывая парт-номеров продуктов. Итак, для работы порталу на базе Microsoft SharePoint 2013, прежде всего, требуется операционная система семейства Windows Server, версии не ниже 2008 R2, с веб-сервером Internet Information Server (IIS). В общем случае для функционирования портала и управления его пользователями также требуется развёрнутый корпоративный каталог Active Directory (AD). Для AD есть небольшое исключение, для самых простых реализаций, мы его опишем ниже. И AD и IIS лицензируются в составе Windows Server.

Собственно сам портал представлен серверным продуктом Microsoft SharePoint Server 2013. Для хранения данных используется сервер базы данных Microsoft SQL Server, версии не ниже 2008 R2. На сервер портала может устанавливаться специализированное программное обеспечение (т.н. набор веб-частей и настроек), которое позволяет настроить портал под нужды заказчика. В частности, таким ПО является наше решение «СДЦ. Типовой портал». Либо портал может быть настроен «стандартными» средствами, с использованием встроенной функциональности узлов, библиотек и списков, но такая настройка требует отдельного вдумчивого планирования. Впрочем, как и использование типовых решений – любое типовое решение должно быть адаптировано под конкретную компанию. Итак, резюмируя написанное выше, мы получаем следующую базовую программно-аппаратную архитектуру портала (см. рис.1)

Рисунок 1. Базовая архитектура портала

1.1 Сервер портала: Microsoft SharePoint Server 2013, операционная система Windows Server, развёрнут IIS.

1.2 Сервер базы данных: Microsoft SQL Server, операционная система Windows Server.

1.3 Аппаратная подсистема хранения данных – могут использоваться диски внутри сервера базы данных.

1.4 Корпоративный каталог Active Directory (внешняя для портала система).

2. Изменения базовой архитектуры

Как мы уже отмечали, на основе базовой архитектуры могут строиться порталы самого разного размера и стоимости. Ведь одной из наиболее интересных особенностей SharePoint является его фантастическая масштабируемость. Используя простейшие продукты семейств SharePoint и SQL, мы можем построить условно-бесплатный в части ПО портал на 15-50 пользователей, реализованный на одном аппаратном или виртуальном сервере. Для организации в 150-350 активных пользователей, наиболее распространённым является портал базовой архитектуры. Такие порталы включают в себя сервер портала и сервер базы данных, и используют отдельный контроллер домена. А далее, разнося на разные серверы функциональные части портала (Front-End, Search, Index), и применяя кластеры баз данных SQL, мы можем масштабировать портал для обслуживания одновременно десятков тысяч пользователей. И это не пустые обещания: на таком масштабируемом портале, например, функционирует глобальный веб-сайт компании Microsoft. Ниже мы рассмотрим особенности аппаратной реализации и лицензирования ПО для каждого из трёх описанных размеров портала:

1. Простейший портал на одном сервере;
2. Самая распространённая архитектура — сервер портала плюс сервер базы данных;
3. Масштабируемая ферма серверов.

3. Простейший портал

Как это ни удивительно, но на базе такой мощной платформы, как Microsoft SharePoint, можно построить практически бесплатный портал. Понятно, что его производительность будет ограничена, но для небольшой компании в 15-50 пользователей, её будет вполне достаточно. Архитектура такого решения отличается простотой и незамысловатостью: все компоненты портала размещаются на одном аппаратном (виртуальном) сервере с операционной системой Windows Server версии от 2008 R2 SP1 64-bit. В технической документации Микрософт такая конфигурация называется один сервер со встроенной базой данных (см. рис. 2).

Рисунок 2. Реализация на одном сервере

В упрощённой архитектуре мы можем не использовать каталог Active Directory, пользователи создаются и администрируются на веб-сервере IIS, развёрнутом на том же аппаратном сервере. В качестве ПО портала используется программное обеспечение Microsoft SharePoint Foundation 2013, лицензируемое в составе Windows Server. Сервер базы данных представлен свободно распространяемым Microsoft SQL 2012 Express. Описание требований к лицензированию и к ресурсам аппаратного сервера можно привести в виде следующей таблицы:

Таблица 1. Требования к серверу базовой архитектуры

Таким образом, используя один аппаратный сервер с серверной и клиентскими лицензиями на операционную систему Windows Server, и добавив к нему свободно распространяемые SharePoint Foundation и SQL Express, мы получаем полнофункциональный портал, удовлетворяющий большинство потребностей пользователей.

Для очистки совести отметим, что сама компания Микрософт рекомендует использовать такие порталы только для тестовых целей и для целей разработки. Вместе с тем, наш опыт показывает, что они функционируют стабильно, и вполне удовлетворяют потребности компаний с небольшим числом пользователей. По сравнению с базовой архитектурой, это решение имеет ряд ограничений, в частности, по объёму хранимой информации (до 20ГБ). Но эти недостатки искупаются дешевизной и простотой использования, что является существенным преимуществом для небольших организаций.

4. Самый распространённый портал

Описанная немного выше базовая архитектура портала, как можно заключить из названия, является и самой распространённой. В терминах Микрософт это – ферма с одним сервером, где под сервером имеется ввиду сервер портала. Название «с одним сервером» получилось потому, что вынесенный отдельно сервер базы данных в состав собственно портальной фермы не входит. Знание этого факта позволит нам исключить некоторую путаницу в терминологии – ведь аппаратных (виртуальных) серверов в такой конфигурации два: сервер портала и сервер базы данных. Такая архитектура достаточно подробно описана в п.1, поэтому, чтобы не повторяться, здесь мы приведём только табличку с требованиями к оборудованию и параметрами лицензирования.

Таблица 2. Требования к ферме с одним сервером

Такие порталы достаточно эффективны в использовании в средних организациях с количеством пользователей 150-350. Если не слишком нагружать портал специально разработанными приложениями, и при этом добавить побольше оперативной памяти, то количество обслуживаемых пользователей может достигнуть 500-700. Вместе с тем, наибольшую пользу портал приносит, если кроме информации содержит ещё и автоматизированные для компании бизнес-процессы и инструменты групповой работы. А при большом количестве пользователей, эти приложения и различные службы портала, для большей эффективности, необходимо вынести на отдельные серверы. Как будет выглядеть подобная архитектура, мы рассмотрим в следующем разделе.

5. Масштабируемая ферма серверов

Для того, чтобы понять, как происходит распределение нагрузки на портал, создаваемой пользователями, немного погрузимся в его составляющие. Прежде всего, отметим, что в состав портала входят различные службы, которые функционируют в той или иной мере независимо. Важнейшие из этих служб: служба веб-сервера (WebFront End), служба индексации (Index) и служба поиска (Search). Служба веб-сервера обрабатывает запросы пользователей, поэтому чем больше веб-серверов в ферме, тем большее количество пользователей может быть работать без задержек. Соответственно, служба поиска выполняет поиск по базе данных портала, а служба индексации индексирует содержимое для ускорения поиска. Разнося эти службы по разным аппаратным (виртуальным) серверам, и выделяя несколько серверов под службу веб-сервера, мы получаем существенное увеличение производительности всего портала.

Дальше возникает вопрос: а что же с хранением данных? Ответ на него тоже исходит из понимания структуры SharePoint: упрощённо можно отметить, что для различных групп пользователей, и различных применений, SharePoint хранит данные в разных базах данных контента. Эти базы независимы друг от друга, и могут быть легко разнесены на разные аппаратные серверы баз данных, что, безусловно, повысит производительность обращения к ним со стороны служб портала.

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

Таким образом, в результате деления нагрузки между разными физическими серверами, мы получаем портал, объединённый единым администрированием, и практически неограниченный по эффективности: количеству одновременно обслуживаемых пользователей и объёму хранимой информации. Такая ферма в терминологии Микрософт – ферма серверов с несколькими серверами. В таблице ниже представлены требования к серверам в составе такой фермы.

Таблица 3. Требования к серверам в ферме с несколькими серверами

В нашей небольшой статье мы не будем вдаваться в детали построения таких ферм, тем более, что этому посвящены сотни страниц описаний в библиотеке TechNet компании Микрософт (http://technet.microsoft.com/ru-ru/). Но для иллюстрации приведём пример отказоустойчивой фермы серверов, похожей на ту, которую мы недавно реализовали для своего заказчика. (см. рис.3).

Рисунок 3. Масштабируемая ферма серверов

Как видно, в этой ферме отдельно вынесены два сервера веб-службы, индексный и поисковый серверы. Серверы базы данных объединены в отказоустойчивый кластер с общим хранилищем (failover cluster). При этом веб-серверы объединены в кластер с распределением сетевой нагрузки (Network Load Balancing cluster). Отметим, что указанная конфигурация позволяет обслуживать без задержек порядка 5000 пользователей.

В заключение нашей статьи, хотелось бы ещё раз подчеркнуть уникальную особенность портальной платформы Microsoft SharePoint – её широчайшую масштабируемость. Подходящие по цене и производительности решения могут быть построены как для простых порталов, обслуживающих 15-50 пользователей, так и для мощных ферм, к которым обращаются тысячи пользователей одновременно. Но самой распространённой является реализация на 150-350 пользователей, состоящая из связки двух серверов: сервера портала Microsoft SharePoint (включающего дополнительное ПО, например «СДЦ. Типовой портал») и сервера базы данных Microsoft SQL; функционирующих под операционной системой Windows Server, и использующих корпоративный каталог Active Directory.

Полезные ссылки:

1. SharePoint: Требования к оборудованию и программному обеспечению (MS TechNet) (http://technet.microsoft.com/ru-ru/library/cc262485(v=office.15).aspx)
2. SQL: Требования к оборудованию и программному обеспечению для установки SQL Server 2012 (MSDN) (http://msdn.microsoft.com/library/ms143506(v=SQL.110).aspx)