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

Статья
03/08/2023

ОБЛАСТЬ ПРИМЕНЕНИЯ: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint в Microsoft 365

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

Важно!

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опубликованный контент интрасети (например, HRweb)
Сайты для совместной работы групп
Личные сайты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Два интерфейсных веб-сервера
Два сервера приложений
Два сервера баз данных с установленными SQL Server и настроенными для поддержки кластеризации, зеркального отображения или Always On SQL Server. Always On требуется 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://my personal/ имяпользователя_. На следующей иллюстрации показаны личные сайты.

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

Личные сайты

Сайты групп

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

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

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

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

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