Примеры структуры в SharePoint Server: корпоративный портал и сайты экстрасети

ПРИМЕНЯЕТСЯ К:  да 2013  да 2016  да 2019  нет SharePoint в Microsoft 365

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

Важно!

Сведения, содержащиеся в этой статье, применимы к SharePoint Foundation 2013 и SharePoint Server. Тем не менее в статье рассматриваются определенные функции, например личные сайты и поиск в корпоративной среде, недоступные в SharePoint Foundation 2013.

Сведения о примерах структуры

В этой статье описываются следующие примеры структуры:

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

Примечание

Названия моделей содержат фразу SharePoint 2013, но также относятся к SharePoint Server 2016.

Пример структуры корпоративного портала: две версии

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

Мы рекомендуем использовать дизайн на основе коллекций сайтов с именами узла, если только требования не требуют, чтобы сайты с альтернативным сопоставлением доступа были необходимы (см. архитектуру и развертывание коллекции сайтов с именем host(SharePoint 2013)для получения дополнительных сведений). Этот дизайн рекомендуется, так как это та же архитектура, что Microsoft 365 среды. Следовательно, это самая протестированная конфигурация. Новые возможности, в том числе модель приложений и управление запросами, оптимизированы для этой конфигурации, благодаря чему она является самой надежной конфигурацией.

Экстрасеть с выделенными зонами для проверки подлинности

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

Пример структуры для экстрасети с выделенными зонами для проверки подлинности также представляет новый рекомендованный способ для удаленного доступа сотрудников прямой доступ с использованием Windows Server 2012. Альтернативный ему способ заключается в создании виртуальной частной сети (VPN). При необходимости можно также использовать проверку подлинности на основе форм на брандмауэре или шлюзе для получения и перенаправления учетных данных.

Реализация коллекций веб-сайтов в примерах структуры

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

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

  • Корпоративный портал с семействами веб-сайтов с именем на основе узла — этот пример иллюстрирует семейства веб-сайтов с именем на основе узла, где все сайты развернуты в одном веб-приложении на ферме. Этот метод обеспечивает высокий уровень масштабируемости и повышенную гибкость при управлении URL-адресами.

  • Экстрасеть с выделенными зонами для проверки подлинности этот пример иллюстрирует многие высокоуровневые сайты проектов с запоминающимися URL-адресами, где сайты с именем на основе узла используются для каждого сайта проекта (вместо упорядочивания сайтов проектов в рамках высокоуровневого семейства веб-сайтов). При таком подходе одно из преимуществ использования семейств веб-сайтов с именем на основе узла заключается в создании дополнительной изоляции между URL-адресами доменов, что может быть желательным в решении для совместной работы партнеров. Однако недостатком такого подхода являются дополнительные затраты на управление увеличенным количеством имен узлов, включая управление сертификатами SSL. Кроме того, если используется проверка подлинности SAML, требуется дополнительная настройка (см. раздел "Использование проверки подлинности SAML для сайтов с именем на основе узла" ниже).

Проверка подлинности на основе утверждений для SharePoint Server

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

  • В SharePoint Server режим проверки подлинности на основе утверждений используется по умолчанию. Это единственный режим, доступный в центре администрирования. Классический режим проверки подлинности можно реализовать c помощью PowerShell.

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

В SharePoint Server учетной записи обхода контента при поиске требуется доступ к контенту через зону, применяемую по умолчанию, с использованием встроенной проверки подлинности Windows (NTLM или Kerberos). Так как функция проверки подлинности на основе утверждений позволяет использовать несколько типов проверки подлинности в одной зоне, это требование не должно влиять на остальные требования по проверке подлинности.

Сводка по возможностям примеров структуры

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

Таблица: сводка по примерам структуры

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

Сайты, включенные в примеры структуры

В этом разделе описываются высокоуровневые сайты, включенные в примеры структуры.

Сайты интрасети

Корпоративный портал включает следующие сайты для использования в интрасети:

  • Опубликованный контент интрасети (например, HRweb)

  • Сайты для совместной работы групп

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

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

  • Выделяют разные возможности SharePoint Server.

  • В них размещаются данные с разными характеристиками.

  • Регулируются разными профилями использования.

  • Требуют различной стратегии управления разрешениями.

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

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

  • Поиск на уровне предприятия

  • Использование общих данных профиля и корпоративных метаданных

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

Типы сайтов, составляющих корпоративную интрасеть

Сайты интрасети

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

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

В примере структуры экстрасети представлен только этот тип сайтов.

Общие цели разработки

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

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

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

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

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

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

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

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

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

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

Топология ферм серверов

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

  • Два интерфейсных веб-сервера

  • Два сервера приложений

  • Два сервера баз данных с SQL Server, установленным и настроенным так, чтобы поддерживать кластеризацию, зеркальное отображение или AlwaysOn в SQL Server. Для работы AlwaysOn требуется SQL Server 2012.

Концепция переднего и серверного приложений отличается в SharePoint Server 2016, см. в обзоре ролей сервера MinRole в SharePoint Server

В примере структуры показана логическая архитектура SharePoint Server с указанными ниже особенностями.

  • Для всех сайтов используется зеркальное отображение на интерфейсных веб-серверах.

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

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

Пользователи, зоны и проверка подлинности

В SharePoint Server по умолчанию используется проверка подлинности на основе утверждений. Она используется в каждом примере структуры. Вы можете реализовать классический режим проверки подлинности с помощью Windows PowerShell, однако некоторые возможности SharePoint Server будут недоступны в этом режиме. Дополнительные сведения о примерах структур, включающих классический режим проверки подлинности, см. в статье Пример проекта: корпоративное развертывание (SharePoint Server 2010).

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

Таблица: сравнение подходов к конфигурации зон на примерах структур

Корпоративный портал с сайтами с именем на основе узла и корпоративный портал с сайтами на основе путей Экстрасеть с выделенными зонами для проверки подлинности
Режим проверки подлинности
Утверждения
Утверждения
Конфигурация зон
Одна зона с несколькими методами проверки подлинности, настроенными для разных классов пользователей.
Несколько зон с одним методом проверки подлинности для каждой зоны.
URL-адреса
Все классы пользователей используют один и тот же URL-адрес для каждого из сайтов. Сотрудники используют один и тот же URL-адрес независимо от того, находятся ли они внутри корпоративной сети или работают удаленно.
Каждый класс пользователей использует отдельный URL-адрес для доступа к сайту. Сотрудники используют разные URL-адреса в зависимости от того, находятся они внутри корпоративной сети или работают удаленно.
Внутренние запросы
Запросы, которые инициируются внутри корпоративной сети, перенаправляются за пределы сети, а затем обратно через шлюз или прокси-сервер. Безопасность для таких запросов обеспечивается с помощью протокола SSL.
Кроме того, чтобы перенаправлять запросы непосредственно во внутренний интерфейс для серверов, можно использовать разделенную DNS.
Запросы, которые инициируются внутри корпоративной сети, остаются внутренними.
Взаимодействие с пользователем
Всем пользователям отображается запрос на выбор типа учетной записи, используемой ими для входа.
Метод проверки подлинности предопределен. Пользователям не требуется выбирать тип учетной записи на странице входа.

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

Пример структуры экстрасети с выделенными зонами

Пример структуры экстрасети иллюстрирует три разных класса пользователей, назначенных разным зонам. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть". Учетной записи обхода контента при поиске требуется осуществлять доступ к зоне по умолчанию, используя встроенную проверку подлинности Windows (протокол NTLM или Kerberos), что учитывается для образца структуры. В следующей таблице показано, как настроены зоны в примере структуры экстрасети.

Таблица: зоны, пользователи и тип проверки подлинности, заданные в примере структуры экстрасети

Зона Пользователи Проверка подлинности
Intranet
Внутренние и удаленные сотрудники
Учетная запись для обхода контента при поиске
Протокол NTLM или Kerberos
Удаленные сотрудники, осуществляющие подключение посредством прямого доступа или VPN.
По умолчанию
Отдельные партнеры
Параметры:
Каталог LDAP, использующий проверку подлинности на основе форм
Внешний лес доменных служб Active Directory с односторонним отношением доверия к внутреннему лесу и встроенная проверка подлинности Windows
Надежный поставщик удостоверений с проверкой подлинности на основе SAML
Экстрасеть
Партнерские компании
Надежный поставщик удостоверений партнера с проверкой подлинности на основе SAML

Пример структуры корпоративного портала

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

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

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

Зона Пользователи Поставщик и тип проверки подлинности
По умолчанию
Внутренние и удаленные сотрудники
Доменные службы Active Directory или хранилище LDAP с проверкой подлинности на основе форм или проверкой подлинности на основе SAML.
По умолчанию
Отдельные партнеры
Надежный поставщик удостоверений с проверкой подлинности на основе SAML или база данных SQL Server с проверкой подлинности на основе форм
По умолчанию
Партнерские компании
Надежный поставщик удостоверений партнера с проверкой подлинности на основе SAML
По умолчанию
Учетная запись для обхода контента при поиске
Доменные службы Active Directory с проверкой подлинности Windows NTLM

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

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

  • Можно настроить ферму SharePoint на доверие внешнему поставщику удостоверений, например, располагающемуся в партнерской компании (чтобы проверка подлинности выполнялась непосредственно для каталога партнера).

  • Можно настроить поставщика удостоверений внутри корпоративной среды на доверие внешнему поставщику удостоверений. Администраторы в обеих организациях должны установить такое отношение явным образом. В данном сценарии ферма SharePoint доверяет поставщику удостоверений из собственной корпоративной среды. Когда поставщик удостоверений отправляет маркер, ферма использует сертификат для подписи маркера, указанный при установке доверия, для проверки срока действия маркера. Рекомендуется именно этот подход.

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

Зоны

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

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

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

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

Требования к настройке зоны по умолчанию

Зона по умолчанию — это зона, требующая больше всего внимания. В SharePoint Server предъявляются указанные ниже требования по настройке зоны по умолчанию.

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

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

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

Настройка зон для среды экстрасети

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

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

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

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

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

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

  • Если вы используете семейства веб-сайтов с именем на основе узла, то для сопоставления URL-адресов с соответствующими зонами используйте PowerShell.

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

  • Имена серверов, DNS-имена и IP-адреса потенциально могут предоставляться извне внутренней сети.

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

Использование проверки подлинности SAML с сайтами с именем на основе узла

Если структура включает в себя проверку подлинности SAML с сайтами с именем на основе узла, каждому запоминающемуся URL-адресу требуется следующее:

  • Новая область на основе SPTrustedIdentityTokenIssuer.

  • Соответствующая проверяющая сторона в поставщике удостоверений.

Службы

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

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

Архитектура служб для корпоративного портала с сайтами на основе путей

Архитектура служб

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

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

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

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

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

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

Сайты администрирования

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

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

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

  • Создайте отдельные записи DNS для сайтов администрирования.

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

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

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

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

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

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

  • Изоляция сайтов, сохраняющих пароли серверных систем данных и взаимодействующих с этими системами (хотя для этой цели можно использовать службу Store Service).

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

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

  • Сайт администрирования размещен в выделенном пуле приложений. Это требование SharePoint Server.

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

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

  • Веб-приложение для партнеров размещается в выделенном пуле приложений.

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

Веб-приложение представляет собой веб-сайт IIS, который создается и используется SharePoint Server. В IIS каждое веб-приложение представлено отдельным веб-сайтом.

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

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

    Если в той же ферме размещается интернет-сайт компании, поместите этот сайт в выделенное веб-приложение и пул приложений.

  • Изоляция пользователей

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

  • Принудительное применение разрешений

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

  • Оптимизация производительности

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

  • Оптимизация управляемости.

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

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

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

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

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

  • Вам потребуется использовать компонент самостоятельного создания сайтов, которая по умолчанию устанавливается в составе SharePoint Server 2016.

    Это не относится к пользовательским решениям для самостоятельного создания сайтов.

  • Веб-приложению требуются уникальные включения по шаблону или явные включения.

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

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

    Вы все еще можете использовать мост SSL с семействами веб-сайтов с именем на основе узла с помощью этих устройств, если завершение SSL не требуется.

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

Подробнее о семействах веб-сайтов с именем на основе узла, в том числе о сравнении с семействами на основе путей, см. в статье Архитектура и развертывание семейства сайтов с именем на основе узла (SharePoint 2013).

Цели разработки семейств веб-сайтов

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

На следующей схеме проиллюстрирована иерархия сайтов групп.

Иерархия для сайтов групп

Сайты групп

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

Опубликованный контент интрасети

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

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

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

Недостатки использования нескольких семейств веб-сайтов состоят в следующем.

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

  • Координирование настроек и навигации в семействах веб-сайтов требует больше усилий.

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

Личные сайты

Личные сайты имеют особые характеристики, и рекомендации по развертыванию личных сайтов весьма просты. В примерах структуры семейство личных сайтов включает в себя сайт верхнего уровня с URL-адресом http://my. Для первого созданного семейства веб-сайтов верхнего уровня используется шаблон "Узел личных сайтов". В это семейство веб-сайтов включен управляемый путь (с использованием подстановочных знаков), который позволяет разместить неограниченное количество сайтов, созданных пользователями. Все сайты, расположенные ниже управляемого пути, представляют собой независимые семейства веб-сайтов, для которых используется шаблон "Личный сайт". Имя пользователя добавляется к URL-адресу в следующем виде: http://mypersonal/имя_пользователя. На иллюстрации ниже показаны личные сайты.

Иерархия для личных сайтов

Личные сайты

Сайты групп

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

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

    • Теряется возможность реализации содержательной таксономии.

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

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

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

Таблица: рекомендуемая таксономия семейства веб-сайтов

Тип организации Рекомендуемая таксономия семейства веб-сайтов
Разработка продуктов
Создайте семейство веб-сайтов для каждого разрабатываемого продукта. Разрешите группам участвовать в создании сайтов в рамках этого семейства.
Для каждого долгосрочного проекта создайте семейство веб-сайтов для каждой большой группы, участвующей в разработке продукта. Например, создайте по одному семейству веб-сайтов для каждой из следующих групп: дизайнеры, инженеры, разработчики контента.
Справочные материалы
Создайте семейство веб-сайтов для каждого долгосрочного исследовательского проекта.
Создайте семейство веб-сайтов для каждой категории исследовательских разработок.
Высшее учебное заведение
Создайте семейство веб-сайтов для каждого факультета.
Государственное законодательное учреждение
Создайте семейство веб-сайтов для каждой политической партии. Государственные чиновники, принадлежащие к одной партии, могут совместно использовать шаблоны и навигацию.
Создайте семейство веб-сайтов для каждого комитета. Либо создайте одно семейство веб-сайтов для всех комитетов.
Юридический отдел компании
Создайте семейство веб-сайтов для каждого клиента компании.
Производство
Создайте семейство веб-сайтов для каждого семейства продуктов.

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

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

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

  • Партнеры и другие участники имеют доступ только к тому проекту, над которым они работают.

  • Владельцы сайтов управляют разрешениями.

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

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

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

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

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

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

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

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

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

  • Создайте семейство веб-сайтов в определенной базе данных с помощью PowerShell.

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

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

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

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

  1. В веб-приложении создайте базу данных и установите ее в состояние Готово.

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

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

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

Опубликованный контент интрасети

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

Личные сайты

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

  • Максимальный объем дискового пространства, используемого сайтом: этот параметр, который настраивается на странице Шаблоны квот в центре Центр администрирования, ограничивает размер личного сайта.

  • Корзина второго уровня: этот параметр, который настраивается на странице Общие параметры веб-приложений, определяет объем дополнительного пространства, выделяемого для корзины второго уровня.

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

В примерах структуры задаются следующие параметры размеров на основании целевого объема базы данных 175 ГБ и целевого размера личного сайта 1 ГБ/

  • Ограничение размера одного сайта = 1 ГБ

  • Целевой размер базы данных = 175 ГБ

  • Резерв для корзины второго уровня = 15 %

  • Максимальное число сайтов = 180

  • Предупреждение уровня сайта = 150

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

Сайты групп

Размер сайтов групп в большинстве организаций значительно превышает размер личных сайтов. Сайты групп создаются в управляемом пути, что позволяет использовать одну базу данных контента для коллекции веб-сайтов группы. В примере структуры используются параметры базы данных, принятые на основании ограничения размера семейств веб-сайтов в 30 ГБ. Выберите ограничение, подходящее для сайтов групп в вашей организации.

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

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

В примере структуры задаются следующие параметры размеров:

  • Целевой размер базы данных = 200 ГБ

  • Квота хранилища на сайт = 5 ГБ

  • Максимальное число сайтов = 40

  • Семейство веб-сайтов для разработки размещается в выделенной базе данных

Зоны и URL-адреса

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

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

  • В примере структуры стандартные порты HTTP и HTTPS (80 и 443) могут использоваться во всех приложениях.

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

Разработка URL-адресов со сбалансированной нагрузкой

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

Intranet

Для каждого из трех семейств веб-сайтов, из которых состоит интрасеть, требуется уникальный URL-адрес. В примерах структуры корпоративного портала целевой аудиторией для контента интрасети являются внутренние и удаленные сотрудники. Сотрудники используют одни и те же URL-адреса для каждого из этих сайтов независимо от того, получают ли они локальный или удаленный доступ. Несмотря на то, что этот подход добавляет в структуру SharePoint уровень безопасности (весь трафик использует SSL), он требует от вас выбрать альтернативное решение для дополнительной конфигурации:

  • Маршрутизация внутреннего трафика через брандмауэр или шлюз вместе с удаленным трафиком.

  • Настройка отдельной среды DNS для разрешения внутренних запросов во внутренней сети.

Веб-сайт для партнеров

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

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

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

Таблица: примеры URL-адресов из примера структуры экстрасети

Зона Пример URL-адреса
Внутренние и удаленные сотрудники
http://project1
Отдельные партнеры
https://project2.fabrikam.com
Партнерские компании
https://TrustedPartnerProject1.fabrikam.com

Использование явных включений и включений по шаблону для URL-путей

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

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

  • Явное включение: семейство веб-сайтов с явно заданным URL-адресом. Явное включение применяется только к одному семейству веб-сайтов. Вы можете создать большое количество явных включений ниже корневого семейства веб-сайтов. Вот пример URL-адреса для семейства веб-сайтов, созданного с помощью этого метода: http://intranet/hr. Каждый добавленный явный путь снижает производительность, поэтому рекомендуется ограничить количество семейств веб-сайтов, созданных с помощью явного включения, примерно до 20.

  • Включение по шаблону: путь, который добавляется к URL-адресу. Этот путь обозначает, что все сайты, указанные сразу после имени пути, представляют собой уникальные семейства веб-сайтов. Этот вариант обычно используется для семейств веб-сайтов, поддерживающих самостоятельное создание сайтов, например для личных сайтов. Вот пример URL-адреса для семейства веб-сайтов, созданного с помощью этого метода: http://my/personal/user1.

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

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

Явные включения: опубликованный контент интрасети

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

При использовании явных включений URL-адреса имеют следующий формат:

В этом примере корневое семейство веб-сайтов http://intranet.fabrikam.com представляет домашнюю страницу интрасети по умолчанию. Этот сайт предназначен для размещения контента для пользователей.

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

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

Сайты групп

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

При использовании включений по шаблону URL-адреса имеют следующий формат:

В этом примере корневое семейство веб-сайтов https://teams.fabrikam.com не обязательно должно размещать контент для пользователей.

Личные сайты

Личные сайты поддерживают самостоятельное создание сайтов. Если при просмотре интрасети пользователь впервые щелкнет элемент Личный сайт, будет автоматически создан личный сайт для пользователя. В примере структуры личные сайты содержат включение по шаблону с именем /personal (http://my/personal)). Компонент личного сайта автоматически добавляет имя пользователя к URL-адресу.

В этом случае URL-адреса имеют следующий формат:

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

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

В примерах структуры корпоративного портала веб-приложение для партнеров содержит включение по шаблону с именем /sites (http://partnerweb/sites)). В этом случае URL-адреса имеют следующий формат:

Координирование URL-адресов с помощью альтернативного сопоставления доступа и DNS

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

URL-адреса с одним именем, например http://teams, можно настроить для доступа к интрасети. Клиентский компьютер сопоставляет эти URL-адреса, добавляя суффикс DNS клиентского компьютера, например fabrikam.com, а затем выполняя поиска DNS для имени с этим суффиксом. Например, когда клиентский компьютер в домене fabrikam.com запрашивает http://teams, этот компьютер отправляет запрос в DNS для http://teams.fabrikam.com.

Система DNS должна быть настроена на использование записи A (или записи AAAA для протокола IPv6) для каждого полного доменного имени. Такая запись указывает на IP-адрес с балансировкой нагрузки для веб-серверов, на которых размещается сайт. В типичной производственной среде серверы настроены на использование статически назначаемых IP-адресов в дополнение к статически назначаемым записям A или AAAA в DNS.

После получения IP-адреса с балансировкой нагрузки клиентский браузер подключается к интерфейсному веб-серверу в ферме и отправляет HTTP-запрос с исходным URL-адресом с одним именем http://teams. Службы IIS и SharePoint Server распознают это как запрос для зоны "Интрасеть" на основании параметров, настроенных в альтернативных сопоставлениях доступа. Если пользователь вместо этого запрашивает https://teams.fabrikam.com, процесс будет аналогичным за исключением того, что службы IIS и SharePoint Server получают полное доменное имя и распознают его как запрос для зоны по умолчанию.

В средах с несколькими доменами вводите записи CNAME для DNS в доменах, в которых не размещены сайты. Например, если в сетевой среде Fabrikam имеется второй домен с именем europe.fabrikam.com, записи CNAME для этих сайтов необходимо вводить в домене Europe. Для сайта интрасети сайтов групп (http://teams)) запись CNAME с именем teams будет добавлена к домену europe.fabrikam.com, который указывает на teams.fabrikam.com. Затем, когда суффикс DNS клиентского компьютера будет добавлен к запросам поиска DNS, при выполнении запроса для http://teams из домена Europe будет выполнен поиск DNS для teams.europe.fabrikam.com, и запись CNAME направит его на teams.fabrikam.com.

Примечание

Существует известная проблема с некоторыми клиентами, использующими проверку подлинности Kerberos, и разрешением записей CNAME. Подробнее см. в статье Kerberos configuration known issues (SharePoint Server 2010).

Политики зон

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

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