Компоненты логической архитектуры (SharePoint Server 2010)

  • Статья

 

Применимо к: SharePoint Foundation 2010, SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

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

  • Определите цели общего доступа и изоляции.

  • Оцените целесообразность каждого варианта.

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

Содержание:

  • Фермы серверов

  • Приложения служб

  • Пулы приложений IIS

  • Веб-приложения

  • Зоны

  • Политика для веб-приложений

  • Базы данных контента

  • Семейства сайтов

  • Сайты

  • Именованные семейства сайтов

  • Личные сайты

Фермы серверов

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

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

  • Интенсивное использование служб может требовать одной или нескольких выделенных ферм серверов.

  • Разделение ответственности работающих подразделений.

  • Выделенные источники финансирования.

  • Раздельное расположение центров обработки данных.

  • Отраслевые требования к физической изоляции сайтов.

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

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

Приложения служб

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

В SharePoint Server 2010 службы больше не содержатся в поставщике общих служб. Инфраструктура для хранения служб перемещена в Microsoft SharePoint Foundation 2010, и конфигурация предлагаемых служб стала гораздо более гибкой. Отдельные службы можно настраивать независимо, кроме того, сторонние поставщики могут добавлять службы на платформу.

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

Приложения служб связаны с веб-приложениями. Каждое приложение службы может настраиваться по-разному.

  • Веб-приложения можно настроить для использования только необходимых служб, а не всего разворачиваемого набора служб.

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

  • Приложения служб могут совместно использоваться несколькими веб-приложениями в одной ферме.

  • Некоторые приложения служб могут совместно использоваться среди нескольких ферм.

Емкость

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

Общий доступ и изоляция

Приложения служб могут совместно использоваться следующими двумя способами.

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

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

    Примечание

    Не все приложения служб поддерживают секционирование.

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

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

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

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

Настраиваемые элементы

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

Элемент

Описание

Группа по умолчанию

По умолчанию все приложения служб включаются в группу по умолчанию. Можно добавлять приложения служб в эту группу и исключать их из нее в любое время, в том числе и во время создания приложения.

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

Подключение (прокси)

При создании приложения службы в то же время создается и подключение для него. Подключение — это виртуальная сущность, которая подключает веб-приложение к приложению службы. Некоторые приложения служб, например служба управляемых метаданных, хранят параметры в подключениях. В Windows PowerShell подключения называются прокси.

Разрешения приложений служб

Управление приложениями служб можно передать другим пользователям, предоставив им разрешение на одно или несколько приложений служб.

Надежные расположения личного сайта

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

Администрирование

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

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

Рекомендации по планированию

Следует настраивать приложения служб либо для совместного использования ресурсов несколькими веб-приложениями, либо для изоляции контента.

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

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

  • Ограничение результатов поиска отдельными семействами сайтов.

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

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

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

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

Пулы приложений

В IIS 7.0 пул приложений — это группа, состоящая из одного или нескольких URL-адресов, обслуживаемых рабочим процессом или набором рабочих процессов.

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

Емкость

Память служебных данных пула приложений составляет 30-50 мегабайт (МБ) плюс некоторая память для приложений, работающих в пространстве процессов пула приложений. Разные требования приложений обычно быстро увеличивают использование памяти пулом приложений до 800 МБ или более. Предельное количество пулов приложений определяется объемом доступной системной памяти. Это значит, что на количество пулов приложений влияют следующие два фактора:

  • доступная для адресации память;

  • объем памяти, используемый приложениями, работающими в пуле приложений.

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

Общий доступ и изоляция

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

Настраиваемые элементы

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

Администрирование

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

Рекомендации по планированию

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

  • для разделения контента, прошедшего проверку подлинности, от анонимного контента;

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

Веб-приложения

Веб-приложение — это веб-сайт IIS, созданный и используемый продуктами SharePoint 2010. Веб-приложение может быть расширено вчетверо для создания четырех дополнительных зон в продуктах SharePoint 2010, что приводит к созданию до пяти веб-сайтов IIS, связанных с одним веб-приложением, причем каждый веб-сайт IIS связывается с отдельной зоной. Каждому веб-приложению можно назначить уникальное доменное имя. Дополнительные сведения см. в разделе Zones этой статьи.

Общий доступ и изоляция

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

Настраиваемые элементы

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

Элемент

Описание

Приложения служб

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

Зоны

В рамках веб-приложения можно создать до пяти зон. Зоны позволяют применять разные условия доступа и политики для больших групп пользователей.

Политика для веб-приложения

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

Администрирование

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

Рекомендации по планированию

Основной сферой применения выделенных веб-приложений являются следующие задачи:

  • Отделение контента, доступного анонимным пользователям, от контента, доступного только зарегистрированным пользователям.

  • Изолирование пользователей. Например, можно гарантированно изолировать партнеров от доступа к контенту экстрасети, разместив сайты партнеров в отдельном веб-приложении.

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

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

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

Зоны

Зоны представляют разные логические пути (URL-адреса) получения доступа к одному веб-приложению. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть". Каждое имя может быть выбрано один раз для одного веб-приложения. Каждую зону представляет отдельный веб-сайт в IIS.

Зона по умолчанию — это зона, которая создается первой при создании веб-приложения. Остальные зоны создаются путем расширения веб-приложения.

Емкость

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

Общий доступ и изоляция

Зоны предоставляют метод разделения пользователей на группы:

  • **Тип проверки подлинности.   **Каждая зона может быть настроена на использование собственного поставщика проверки подлинности, что позволяет реализовать совместный доступ к одному и тому же контенту для компаний-партнеров.

  • **Зона сети.   **Каждая зона может быть настроена для приема пользователей, вошедших из другой зоны сети, например из экстрасети или Интернета.

  • Разрешения политики.   Можно явно разрешить или запретить доступ на чтение или запись контента по зонам на основе учетной записи пользователя или группы.

Настраиваемые элементы

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

Элемент

Описание

Поставщик проверки подлинности

Каждая зона может быть настроена на использование собственного поставщика проверки подлинности.

Анонимный доступ

Включить или выключить анонимный доступ в каждой зоне.

Протокол SSL

Включить или выключить протокол SSL в каждой зоне.

Общий URL-адрес и альтернативное сопоставление доступа

Укажите, какое имя домена будут вводить пользователи для доступа к контенту веб-приложения. Либо используйте альтернативное сопоставление доступа, чтобы сопоставить URL-адресу по умолчанию (имени сервера или порта) каждой зоны наглядные или более соответствующие зоне IP-адреса. Альтернативное сопоставление доступа позволяет использовать внешние конечные точки для SSL-соединений: прокси-сервер является конечной точкой SSL-соединения, ретранслируя запросы веб-серверу по протоколу HTTP. В этом случае можно настроить альтернативные сопоставления доступа для возвращения запросов по протоколу SSL, чтобы обеспечить безопасное соединение между клиентом и сервером.

Политика для веб-приложения

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

Администрирование

Если используется альтернативное сопоставление доступа, обратите внимание на то, что всем общедоступным URL-адресам требуются записи службы доменных имен (DNS) для сопоставления общедоступных URL-адресов с IP-адресами службы балансировки нагрузки фермы.

Рекомендации по планированию

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

  • Зона по умолчанию

  • Зоны для внешнего доступа

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

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

  • Именованные семейства сайтов доступны только в зоне по умолчанию. Все пользователи, которым назначен доступ к именованным семействам сайтов, должны иметь доступ к зоне по умолчанию.

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

В среде экстрасети разработка зон критически важна по двум причинам:

  • Запрос пользователя может быть инициирован из нескольких разных сетей, например, из внутренней сети, сети компании-партнера или Интернета.

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

Убедитесь, что в среде экстрасети соблюдены следующие принципы разработки:

  • Зоны группы веб-приложений должны быть настроены так, чтобы они были согласованы друг с другом. Настройки проверки подлинности и назначения пользователей должны быть одинаковы, но политика, связанная с зонами, может отличаться для разных веб-приложений. В частности, необходимо убедиться, что зона интрасети используется одними и теми же сотрудниками во всех веб-приложениях. Другими словами, нельзя настраивать зону интрасети в одном веб-приложении для внутренних сотрудников, а в другом — для удаленных сотрудников.

  • Альтернативные сопоставления доступа для каждой зоны и каждого ресурса должны быть настроены корректно и точно.

Политика для веб-приложения

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

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

Емкость

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

Общий доступ и изоляция

Политика для веб-приложения предоставляет метод установки разрешений, основанный на пользователях и на зонах, к контенту которых они имеют доступ.

Например, используя политику, можно:

  • Разрешить персоналу службы поддержки доступ ко всему контенту.

  • Запретить доступ на запись для партнеров и поставщиков.

  • Запретить доступ к защищенным данным группе пользователей независимо от того, как владельцы сайта настроили разрешения.

  • Проконтролировать, что учетная запись обхода имеет доступ для обхода всего контента.

Настраиваемые элементы

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

Элемент

Описание
   

Пользовательская политика

Создайте политику, которая применяется к пользователям или к группе пользователей:

  • эта политика может применяться ко всем зонам или к одной зоне;

  • можно указывать имена пользователей, имена групп или адреса электронной почты;

  • укажите разрешения, которые следует применить к политике.

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

Анонимная политика

Если для веб-приложения или для одной или нескольких зон разрешен анонимный доступ, то можно создать политику, применяемую ко всем анонимным пользователям. Параметры политики по умолчанию:

  • Отсутствует: нет политики

  • Запретить запись: нет доступа на запись

  • Запретить все: нет доступа

Уровни политики анонимных пользователей не могут быть изменены.

Политика разрешений

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

После создания нового уровня политики разрешений можно создать пользовательскую политику, использующую эту политику разрешений.

Администрирование

Непрерывное администрирование веб-приложений не представляет особой сложности.

Рекомендации по планированию

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

Базы данных контента

По умолчанию весь контент веб-приложения хранится в одной базе данных контента. Можно разделить контент по нескольким базам данных на уровне семейства сайтов. База данных контента может включать одно или несколько семейств сайтов. Одно семейство сайтов не распространяется на несколько баз данных. Резервное копирование и восстановление сайтов производится на уровне баз данных контента.

Емкость

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

Общий доступ и изоляция

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

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

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

Настраиваемые элементы

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

Элемент

Описание

Сервер баз данных

Укажите, на каком компьютере с ПО SQL Server создана база данных контента.

Отказоустойчивый сервер

Можно выбрать связывание базы данных контента с конкретным отказоустойчивым сервером, который используется вместе с зеркальным отображением базы данных SQL Server.

Параметры емкости

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

Администрирование

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

Процедура администрирования баз данных включает в себя:

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

  • Отслеживание размеров баз данных и создание новых баз данных при достижении целевого размера.

  • Резервное копирование и восстановление баз данных.

Рекомендации по планированию

Выберите один из двух подходов, предложенных ниже:

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

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

Чтобы связать семейства сайтов с определенными базами данных контента, воспользуйтесь следующим методом:

  • Для создания семейства сайтов в новой базе данных используйте Windows PowerShell.

  • Применяйте указанные далее параметры емкости базы данных на странице параметров управления базой данных контента веб-сайта центра администрирования SharePoint.

    • Число сайтов, по достижении которого выдается предупреждение, равно 0.

    • Максимальное число сайтов, которое может быть создано в этой базе данных = 1

  • Добавьте группу семейств сайтов в выделенную базу данных, выполнив следующие действия:

    1. Добавьте базу данных контента для веб-приложения и убедитесь, что она находится в состоянии "Готово".

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

    3. Создайте семейства сайтов. Они будут автоматически добавлены в оперативную базу данных.

    4. Верните состояние "Готово" для всех остальных баз данных.

Семейства сайтов

Семейство сайтов — это набор веб-сайтов с единым владельцем и общими параметрами администрирования. Каждое семейство сайтов содержит веб-сайт верхнего уровня и может содержать один или более дочерних сайтов.

Емкость

Для обеспечения приемлемой производительности рекомендуется реализовывать не более 50 000 семейств сайтов на базу данных контента, однако на производительность может влиять уже около 10 000 семейств сайтов. Масштабирование, которое заключается в распределении семейств сайтов по нескольким серверам баз данных, обеспечивает дополнительную емкость для хранения и дополнительную пропускную способность.

Общий доступ и изоляция

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

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

  • Шаблоны страниц

  • Макеты страниц

  • Изображения

  • Шаблоны сайтов

Кроме того, разрешения и навигация изолированы на уровне семейств сайтов следующими способами:

  • Дочерние сайты семейства сайтов могут наследовать разрешения от сайта верхнего уровня.

  • Семейства сайтов не могут наследовать разрешения от других семейств сайтов.

  • Встроенная навигация от одного семейства сайтов к другому отсутствует.

Наконец, SharePoint Server 2010 собирает воедино результаты поиска по семействам сайтов на основе разрешений пользователя, независимо от количества семейств сайтов или баз данных (в зависимости от областей поиска).

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

Настраиваемые элементы

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

Элемент

Описание

Администратор семейства сайтов

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

Шаблон сайта

Шаблон сайта определяет, какие списки и компоненты будут доступны на новом сайте. Многие аспекты сайта можно настроить после создания. Однако сам шаблон сайта нельзя изменить после создания сайта.

Шаблон квот

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

  • Личный сайт (100 МБ)

  • Сайты рабочих групп (2 000 МБ)

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

Элемент

Описание

Администраторы семейства сайтов

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

Уровень разрешений

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

Администрирование

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

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

Рекомендации по планированию

Семейства сайтов объединяют логическую и информационную архитектуру. При разработке собственного семейства сайтов учтите следующие две задачи разработки:

  • Согласование разработки URL-адресов между организациями.

  • Создание логических подразделов контента.

За исключением случаев использования семейств сайтов с именами узлов, каждое веб-приложение должно иметь одно семейство сайтов корневого уровня. Таким образом обеспечивается единый путь URL-адреса к сайтам, расположенным в веб-приложении. Это также требуется при реализации нескольких зон в веб-приложении. Дополнительные сведения см. в разделе Host-named site collections данной статьи.

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

  • Обеспечение отдельного независимого семейства сайтов для каждой рабочей группы.

  • Создание уникального URL-адреса для каждой рабочей группы.

  • Изоляция контента между группами.

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

Можно создать два следующих типа управляемых путей:

  • Явное включение.   Семейство сайтов с явно заданным URL-адресом. Явное включение применяется только к одному семейству сайтов. Можно связать каждое семейство сайтов с собственной базой данных контента, если необходимо управлять ростом и предоставить возможность резервного копирования и восстановления этих сайтов по отдельности. Пример URL-адреса для семейства сайтов, созданного с использованием данного метода — http://fabrikam/hr. Ограничение на количество семейств сайтов, созданных с использованием явного включения, составляет примерно 100 семейств сайтов в веб-приложении, однако оптимальный рабочий максимум — это 20. Если организации требуется большее число семейств сайтов, используйте включение по шаблону.

  • Включение по шаблону.   Путь, который добавляется к URL-адресу. Этот путь обозначает, что все сайты, указанные сразу после имени пути, являются уникальными семействами сайтов. Этот вариант обычно используется для поддержки управления средствами самостоятельного создания сайтов, например сайтов или личных сайтов, созданных для совместной работы с партнерами. Примеры URL-адреса семейства сайтов, созданного с использованием данного метода — http://partnerweb//sites/project1 и http://partnerweb//sites/project2. В данных примерах "http://partnerweb/" представляет семейство сайтов корневого уровня, а "/sites" отражает включение по шаблону.

Сайты

Сайт состоит из одной или нескольких связанных веб-страниц и других элементов (таких как списки, библиотеки и документы), размещенных в семействе сайтов.

Емкость

Для обеспечения приемлемой производительности рекомендуется использовать не более 250 000 сайтов на каждое семейство сайтов. Используя вложенные сайты, можно создать очень большое суммарное количество веб-сайтов. Однако большое количество вложенных сайтов может сильно повлиять на время, необходимое для их обновления. Рекомендуется создавать не более 5000 сайтов в семействе сайтов.

Общий доступ и изоляция

Сайты содержат встроенную навигацию от одного дочернего сайта к другому в рамках семейства сайтов. Встроенная навигация от одного семейства сайтов к другому отсутствует.

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

Настраиваемые элементы

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

Администрирование

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

Именованные семейства сайтов

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

Не существует специального режима, такого как режим заголовка узла, который необходим для создания семейств сайтов с именем узла. Создавать семейства сайтов с именем узла можно с помощью Windows PowerShell. Кроме того, с помощью Windows PowerShell можно использовать управляемые пути с семействами сайтов с именами узлов (New-SPManagedPath –HostHeader).

Семейства сайтов с именами узлов предоставляют большую степень контроля над URL-адресами. Однако такие семейства сайтов доступны только из зоны по умолчанию. Учетные записи пользователей, настроенные для проверки подлинности в других зонах, не могут получать доступ к семействам сайтов с именами узлов.

В продуктах SharePoint 2010 семейства сайтов с именами узлов поддерживают внешнее завершение SSL-соединений. Однако извне может быть изменена только схема протокола (http:// или https://). Обратный прокси-сервер не может изменить имя узла или номер порта (кроме переключения от порта SSL по умолчанию на порт HTTP по умолчанию).

Емкость

Можно создать до 100 000 именованных семейств сайтов в рамках одного веб-сайта IIS Web.

Общий доступ и изоляция

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

Администрирование

Администрирование именованных семейств сайтов подразумевает следующие задачи:

  • Добавление семейств сайтов с именами узлов с помощью Windows PowerShell.

  • Каждому именованному семейству сайтов требуется отдельная DNS-запись.

Личные сайты

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