Пример проекта логической архитектуры: сайты для совместной работы
В этой статье:
О модели
Общие задачи проекта
Фермы серверов
Пользователи, зоны и проверка подлинности
Сайты администрирования
Пулы приложений
Веб-приложения
Семейства веб-сайтов
Базы данных контента
Зоны и URL-адреса
Политики зон
Резервное копирование и восстановление веб-сайтов для совместной работы
Проектирование безопасной внешней совместной работы
В этой статье приводятся практические примеры внедрения логических компонентов архитектуры для создания работоспособного проекта. Эту статью рекомендуется использовать совместно с моделью, описанной в статье Пример проекта логической архитектуры: совместная работа Windows SharePoint Services (на английском языке) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x419) (на английском языке) .
О модели
Эта модель иллюстрирует развертывание в вымышленной корпорации Fabrikam. Если планируется создать решение, использующее один или несколько типов веб-сайтов для совместной работы, используемых в этой модели, ее можно использовать в качестве основы для собственного проекта.
Эта модель иллюстрирует общее развертывание Windows SharePoint Services 3.0 с использованием веб-сайтов для совместной работы трех типов:
сайты групп;
самостоятельно создаваемые сайты;
сайты совместной работы с партнерами.
В этой модели применяются почти все компоненты логической архитектуры и иллюстрируется процедура внедрения этих компонентов в совокупный проект. В этой статье описаны задачи разработки модели и поясняются методы решения этих задач с помощью приведенных в модели логических компонентов архитектуры.
На каждом из веб-сайтов для совместной работы разных типов
размещаются данные с различными информационными показателями,
применяется отдельный профиль использования,
требуется отдельная стратегия управления правами доступа.
Следовательно, варианты разработки в этой модели предназначены для оптимизации производительности и безопасности для каждого приложения.
Сайты групп
Сайты групп — это высокоструктурированные и управляемые веб-сайты для совместной работы, обладающие следующими характеристиками:
Меньшее число семейств веб-сайтов верхнего уровня; в этих семействах веб-сайтов должен размещаться большой объем данных (в отличие от самостоятельно создаваемых веб-сайтов).
URL-адреса верхнего уровня понятны для каждой группы.
В иерархии, таксономии и настройки веб-сайтов включен большой объем планирования.
Контент каждой группы хранится в отдельной базе данных, и им можно управлять индивидуально.
На следующей диаграмме проиллюстрирована иерархия веб-сайтов групп:
.gif "Огранизация веб-сайтов групп")
Самостоятельно создаваемые сайты
Самостоятельно создаваемые сайты являются альтернативой жестко контролируемым веб-сайтам групп. Можно разрешать пользователям и группам создавать собственные семейства веб-сайтов, используя средство управления самостоятельно создаваемыми веб-сайтами. Можно отключить управление самостоятельно создаваемыми веб-сайтами в центре администрирования. Этот способ лучше всего подходит для случаев, когда необходимо разрешить создание веб-сайтов группам или сообществам. Этот способ также подходит в случае размещения веб-сайтов, когда необходимо, чтобы пользователи могли создавать веб-сайты, не ожидая завершения подробного процесса.
Характеристики самостоятельно создаваемых веб-сайтов обычно отличаются от характеристик веб-сайтов с жестким контролем. Среди них можно перечислить следующие:
Большое число семейств веб-сайтов верхнего уровня.
Небольшой объем данных в каждом семействе веб-сайтов.
Автоматически создаваемые URL-адреса, которые редко являются понятными для всех.
На следующей диаграмме самостоятельно создаваемые веб-сайты показаны так, как они реализованы в примере проекта:
.gif "Веб-сайты для самостоятельного создания веб-сайтов")
При планировании самостоятельно создаваемых веб-сайтов необходимо помнить о нескольких компромиссных вариантах, которые влияют на методы управления веб-сайтами этого типа.
Сайты создаются не в соответствии с продуманной таксономией, а по желанию без соблюдения каких-либо единых организационных принципов для разных веб-сайтов. Поскольку каждый новый веб-сайт создается как семейство веб-сайтов, совместное использование шаблонов и средств перемещения между веб-сайтами невозможно.
Поскольку в каждом семействе веб-сайтов предусмотрен поиск контента только по этому семейству веб-сайтов, агрегирование результатов поиска по разным семействам веб-сайтов невозможно.
Семейства веб-сайтов могут значительно варьироваться по размеру и назначению.
Сайты могут быть легко заброшены пользователями.
Управление самостоятельно создаваемыми веб-сайтами может включать управление хранением контента на основе целевого размера базы данных контента и управление удалением неиспользуемых веб-сайтов.
Дополнительные сведения о внедрении функции управления самостоятельно создаваемыми веб-сайтами см. в статье Plan process for creating sites (Windows SharePoint Services).
Cайты совместной работы с партнерами
Веб-приложение партнера размещает веб-сайты, доступные извне, для обеспечения безопасной совместной работы с сотрудниками партнерских компаний. Это приложение позволяет сотрудникам легко создавать безопасные веб-сайты для совместной работы. Выбор варианта разработки для этого приложения определяется следующими факторами.
**Изоляция контента **Партнеры не получают доступа к другим типам контента, размещенным на ферме серверов.
**Раздельная проверка подлинности учетных записей партнеров **Учетные записи партнеров управляются посредством проверки подлинности на основе форм. Учетные записи партнеров не добавляются в корпоративный каталог.
**Управление правами доступа **Владельцы отдельных веб-сайтов управляют разрешениями на доступ к своим веб-сайтам, приглашая к сотрудничеству только необходимых участников.
На следующей диаграмме иллюстрируются веб-сайты совместной работы с партнерами.
.gif "Иерархия веб-сайтов проектов в партнерской сети")
Общие задачи проекта
Эта модель иллюстрирует практическое внедрение функций Windows SharePoint Services 3.0 для приложений совместной работы нескольких типов (веб-сайты групп, самостоятельно создаваемые веб-сайты и веб-сайты совместной работы с партнерами). В этой статье рассматриваются процедуры внедрения проекта для каждого отдельного приложения работы с веб-сайтами. В число основных задач разработки модели входят:
Создание платформы для разработки потенциально развивающейся среды. Решения по разработке отдельных приложений для совместной работы не препятствуют добавлению других приложений. Например, в состав исходного развертывания могут входить только веб-сайты для совместной работы групп или только веб-сайты для совместной работы с партнерами. Используя аналогичную логическую архитектуру, к решению можно добавлять другие типы веб-сайтов для совместной работы, не влияя на структуру исходных веб-сайтов. Другими словами, при разработке не предполагается выбирать структуры, ограничивающие использование среды.
Предоставление доступа к нескольким классам пользователей без снижения уровня защиты контента в рамках разных приложений для совместной работы. В совместной работе могут принимать участие пользователи из разных зон сети (как внутренних, так и внешних), использующие различных поставщиков проверки подлинности. Кроме того, пользователи могут получать доступ только к указанному контенту. Применяя аналогичную логическую архитектуру, можно предоставлять доступ пользователям, находящимся в разных точках и имеющих разные цели. Например, исходная структура может быть предназначена только для предоставления внутреннего доступа для сотрудников. Тем не менее, используя аналогичную структуру, можно также предоставить доступ удаленным сотрудникам, сотрудникам партнеров и даже клиентам.
Обеспечение возможности использования проекта в среде экстрасети. Можно намеренно выбирать такие варианты разработки, которые обеспечивают безопасное развертывание ферм серверов в топологиях демилитаризованной зоны или экстрасети, которые рассматриваются в статье Design extranet farm topology (Windows SharePoint Services).
В оставшейся части статьи рассматриваются все логические компоненты, появляющиеся в модели (сверху вниз), и варианты разработки, применяемые к модели. Цель этого подхода — продемонстрировать различные способы настройки логических компонентов архитектуры на основе приложения.
Фермы серверов
В этой модели иллюстрируется ферма, состоящая из пяти серверов. Однако ее можно применить в ферме любого размера, в том числе и на отдельном сервере. Ферма серверов в этой модели состоит из пяти серверов со следующей топологией:
Два веб-сервера переднего плана;
Один сервер приложений для сервера поиска;
Два сервера баз данных, кластерные или дублируемые.
В этой модели описывается логическая архитектура Windows SharePoint Services 3.0 с отображением следующих характеристик:
Все веб-сайты дублируются на веб-серверах переднего плана.
Сайт центра администрирования установлен на сервере приложений для защиты сервера приложений от непосредственного доступа пользователей.
На практике число серверов и топология серверных ферм не представляют значимости для логической архитектуры, за исключением увеличения емкости и производительности при необходимости. Логическую архитектуру можно создать независимо от топологии серверных ферм. Процедура планирования производительности и емкости помогает определить размер серверной фермы в соответствии с задачами производительности и емкости. Дополнительные сведения см. в статье Plan for performance and capacity (Windows SharePoint Services).
Пользователи, зоны и проверка подлинности
В этой модели описываются пять различных классов пользователей, для каждого из которых определена отдельная зона. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть". Ферма, на которой размещается более одного веб-приложения, может поддерживать пользовательские запросы из более чем пяти зон сети (до пяти зон на каждое веб-приложение). Однако в модели приведено только пять зон.
Пользователи и проверка подлинности
В модели продемонстрировано, каким образом применяется проверка подлинности для разных пользователей из разных зон сети. В следующей таблице также приводится проверка подлинности, применяемая к пользователю и зоне каждого типа.
| Зона | Пользователи | Проверка подлинности |
|---|---|---|
Интрасеть |
Внутренние сотрудники |
NTLM (встроенная проверка подлинности Windows) |
По умолчанию |
Удаленные сотрудники |
NTLM (встроенная проверка подлинности Windows) или проверка подлинности на основе форм по протоколу LDAP. |
Экстрасеть |
Сотрудники партнеров |
Проверка подлинности через формы |
Внутренние сотрудники
Для доступа внутренних сотрудников используется зона интрасети. Применяется встроенная проверка подлинности Windows.
Удаленные сотрудники
Для удаленных сотрудников используется зона по умолчанию. С задачам разработки для зоны "По умолчанию" относятся:
Проверка подлинности с использованием внутренней среды службы каталогов Active Directory.
Упрощение управления разрешениями при помощи проверки подлинности Windows как для внутренних, так и для удаленных сотрудников. Эта задача очень важна, поскольку, если пользователи подключаются к веб-сайтам через двух разных поставщиков проверки подлинности, то Windows SharePoint Services 3.0 создает две разных учетных записи для каждого пользователя. Причем для каждой из этих двух учетных записей необходимо установить разрешения.
В этой модели представлены два варианта проверки подлинности для удаленных сотрудников. В первом варианте (встроенная проверка подлинности Windows с использованием NTLM) выполняются обе задачи разработки. Во втором варианте (проверка подлинности на основе форм по протоколу LDAP) выполняется только первая задача. Следовательно, для удаленных сотрудников предпочтителен первый вариант.
В следующей таблице приведены основные данные о различиях между этими двумя вариантами проверки подлинности.
| Сравниваемые параметры | Встроенная проверка подлинности Windows с использованием NTLM | Проверка подлинности на основе форм по протоколу LDAP |
|---|---|---|
Функция |
В этом методе используется сервер Internet Security and Acceleration (ISA) Server 2006 или шлюз Intelligent Application Gateway (IAG 2007) для проверки подлинности пользователей и передачи учетных данных пользователя в Windows SharePoint Services 3.0. В этих серверах для проверки подлинности пользователей в среде Active Directory используется проверка подлинности на основе форм. Затем они передают учетные данные Windows в Windows SharePoint Services 3.0. Дополнительные сведения см. в следующих ресурсах:
Поскольку эта зона является зоной по умолчанию, то для выполнения требования компонента индексирования используется проверка подлинности NTLM. Дополнительные сведения см. в статье "Требования к конфигурации зоны по умолчанию" далее в этой статье. |
В Windows SharePoint Services 3.0 используется проверка подлинности на основе форм по протоколу LDAP для проверки подлинности удаленных сотрудников во внутренней среде Active Directory. |
Преимущества |
Windows SharePoint Services 3.0 не создает двух разных учетных записей для пользователей, работающих внутри компании и удаленно. Таким образом, управление разрешениями значительно упрощается. |
Для проверки подлинности пользователей и направления учетных данных не требуется прокси-сервер. |
Недостатки |
Необходимо дополнительное согласование и настройка ISA Server 2006, IAG 2007 или другого прокси-сервера. |
Если пользователи подключаются к Windows SharePoint Services 3.0 внутри компании и удаленно, в Windows SharePoint Services 3.0 создаются две разные учетные записи. Следовательно, для обеих учетных записей необходимы разрешения на доступ к веб-сайтам и документам. Если сотрудник планирует работать как внутри сети, так и удаленно, то ему необходимо управлять разрешениями на доступ к собственным веб-сайтам и документам из обеих учетных записей. |
Сотрудники партнеров
Сотрудники партнеров получают доступ к сети через зону экстрасети, и для них используется проверка подлинности на основе форм. Для хранения учетных записей партнеров в экстрасети требуется отдельный каталог и поставщик, например, база данных и поставщик Microsoft SQL Server. Преимуществом данного подхода является возможность раздельного управления учетными записями партнеров и отсутствие необходимости в добавлении учетных записей партнеров в каталог внутренних сотрудников.
В качестве альтернативы можно воспользоваться технологией единого входа в Интернете (SSO) для проверки подлинности через собственный каталог партнера. Однако при данном подходе требуется отдельная зона для каждого партнерского каталога.
Поскольку в этой модели предполагается, что компания Fabrikam работает с партнерами из различных компаний в одном партнерском приложении, то применяется проверка подлинности на основе форм. При этом каталог и поставщик не указываются.
Зоны
При проектировании зон для их успешного развертывания важную роль играют несколько ключевых решений. К ним относятся решения по разработке и настройке следующих зон:
Зона по умолчанию
Зоны для внешнего доступа
В следующих разделах описаны решения, внедренные в модели.
Требования конфигурации зоны по умолчанию
Зона, привлекающая больше всего внимания — это зона по умолчанию. Windows SharePoint Services 3.0 предъявляет следующие требования к настройке зоны по умолчанию:
Если запрос пользователя нельзя связать с зоной, то применяется проверка подлинности и политики зоны по умолчанию. Соответственно, зона по умолчанию должна являться наиболее защищенной зоной.
Для обхода контента компоненту индексирования необходим доступ к контенту по меньшей мере одной зоны. Для компонента индексирования используется проверка подлинности NTLM. Следовательно, для обхода контента хотя бы в одной зоне необходимо настроить проверку подлинности NTLM. Кроме того, до обнаружения зоны, подлинность которой можно проверить, обходчик будет опрашивать зоны в следующем порядке: зона по умолчанию, зона интрасети, зона Интернета, специальная зона и зона экстрасети. Однако если обходчик сначала обнаруживает зону, где настроено использование проверки подлинности Kerberos, а также базовой или краткой проверки подлинности, то обходчик не проверяет ее подлинность и не пытается получить доступ к следующей зоне. Поэтому убедитесь, что настройка зон не препятствует компоненту индексирования выполнять обход контента. Дополнительные сведения о требованиях к проверке подлинности см. в статье Plan authentication methods.
Административная электронная почта отправляется со ссылками от зоны по умолчанию. Это относится и к сообщениям электронной почты владельцам веб-сайтов, которые почти исчерпали квоту. Следовательно, пользователи, получающие электронные сообщения такого типа, должны иметь возможность открыть ссылки через зону по умолчанию. Это особенно важно для владельцев веб-сайтов.
Именованные семейства веб-сайтов доступны только в зоне по умолчанию. Все пользователи, которым необходим доступ к именованным семействам веб-сайтов, должны иметь доступ к зоне по умолчанию.
В этой модели для доступа удаленных сотрудников применяется зона по умолчанию, что вызвано следующими причинами:
Сотрудники могут переходить по ссылкам в административных сообщениях электронной почты вне зависимости от того, получают ли они доступ к веб-сайту изнутри или удаленно.
Имена и URL-адреса внутренних серверов защищены от раскрытия, если невозможно определить зону, связанную с пользовательским запросом. Поскольку зона по умолчанию уже настроена для удаленных сотрудников, то при применении этой зоны в URL-адресах не указывается важных данных.
Настройка зон для среды экстрасети
Разработка зон в среде экстрасети крайне важна по следующим двум причинам:
Пользовательские запросы можно инициировать из нескольких различных сетей. В этой модели пользователи инициируют запросы из внутренней сети, из Интернета и из партнерских компаний.
Пользователи могут принимать участие в совместной работе, используя разные веб-приложения. Например, внутренние и удаленные сотрудники могут заниматься созданием и администрированием контента во всех веб-приложениях на веб-сайтах групп, самостоятельно создаваемых веб-сайтах и на веб-сайтах партнеров.
Убедитесь, что в среде экстрасети соблюдены следующие принципы разработки:
Зоны для разных веб-приложений должны быть согласованы друг с другом при настройке. Настройки проверки подлинности и назначения пользователей должны быть одинаковы, но политика, связанная с зонами, может отличаться для разных веб-приложений. В частности, необходимо убедиться, что зона интрасети используется одними и теми же сотрудниками во всех веб-приложениях. Другими словами, нельзя настраивать зону интрасети в одном веб-приложении для внутренних сотрудников, а в другом — для удаленных сотрудников.
Альтернативные сопоставления доступа для каждой зоны и каждого ресурса должны быть настроены корректно и точно.
В этой модели зона по умолчанию для каждого веб-приложения настроена одинаково применительно к доступу удаленных сотрудников. Кроме того, зона интрасети настроена одинаково во всех веб-приложениях для доступа внутренних сотрудников. Зона экстрасети настроена только для одного веб-приложения.
При создании зоны автоматически создаются альтернативные сопоставления доступа. Однако при использовании прокси-сервера или шлюза для обеспечения доступности веб-сайтов через Интернет придется добавить дополнительную запись альтернативного сопоставления доступа для каждой зоны. Благодаря этому URL-адреса, возвращаемые пользователями за пределами внутренней сети, доступны пользователям в соответствии с контекстом их зоны. Дополнительные сведения см. в статье Plan alternate access mappings.
Если зоны веб-приложений не сопоставлены друг с другом, а ссылки на внешние ресурсы некорректны, то возможны следующие риски:
Имена серверов, имена службы доменных имен (DNS) и IP-адреса могут потенциально быть видны за пределами внутренней сети.
У пользователей может отсутствовать доступ к веб-сайтам и другим ресурсам.
Cайты администрирования
В этой модели веб-сайт центра администрирования размещен на сервере поиска. Таким образом обеспечивается защита веб-сайта от непосредственного контакта с пользователями. Если на доступность веб-серверов переднего плана влияют проблемы производительности или нарушение норм безопасности, то веб-сайт центра администрирования остается доступным. Кроме того, веб-сайт центра администрирования размещен внутри выделенного пула приложений и веб-приложения.
В этой модели и в статье для веб-сайтов администрирования не рассматриваются URL-адреса с балансировкой нагрузки. Рекомендации:
Если в административных URL-адресах используются номера портов, применяйте нестандартные порты. По умолчанию номера портов включаются в URL-адреса. Хотя номера портов обычно не используются в URL-адресах, предназначенных для клиентов, использование номеров портов для сайтов администрирования позволяет повысить уровень безопасности путем предоставления доступа к этим сайтам только через нестандартные порты.
Создание отдельных DNS-записей для веб-сайтов администрирования.
Пулы приложений
Отдельные пулы приложений служб IIS обычно применяются для достижения изоляции процессов между веб-сайтами. Пулы приложений позволяют запускать на одном сервере несколько веб-сайтов с отдельными рабочим процессами и удостоверениями. Это позволяет устранить на одном веб-сайте все возможные уязвимые места системы безопасности, позволяющие злоумышленнику внедрить свой код на сервер и атаковать другие веб-сайты.
На практике выделенный пул приложений целесообразно использовать в следующих случаях:
Для разделения проверенного и анонимного контента.
Для изоляции веб-сайтов, преимущественно предназначенных для совместной работы с внешними партнерами и заказчиками. Это позволяет изолировать внешние учетные записи на веб-сайтах в пределах одного пула приложений.
Для изоляции веб-сайтов, предоставляющих пользователям больше свободы по созданию и администрированию веб-сайтов, а также по совместной работе над контентом.
В этой модели пулы приложений используются следующим образом:
Cайт администрирования размещается в выделенном пуле приложений. Это требование Windows SharePoint Services 3.0.
Внутренние веб-сайты для совместной работы (сайты групп и самостоятельно создаваемые веб-сайты) размещаются в одном пуле приложений.
Приложение партнерской сети размещается в выделенном пуле приложений.
Веб-приложения
Веб-приложение — это веб-сайт IIS, созданный и используемый продуктами и технологиями SharePoint. Каждое веб-приложение представлено своим веб-сайтом в службах IIS. Каждому веб-сайту присваивается уникальное имя домена, что помогает предотвратить атаки по запуску сценариев между веб-сайтами.
В целом, выделенные веб-приложения используются для следующих задач:
Отделение анонимного контента от контента, прошедшего проверку подлинности.
Изоляция пользователей. В этой модели партнерская сеть размещается в выделенном веб-приложении и отдельном пуле приложений, что обеспечивает ограничение доступа партнеров к внутреннему контенту для совместной работы.
Обеспечение разрешений. Выделенное веб-приложение обеспечивает возможность принудительно применять разрешения с помощью страницы "Политика для веб-приложения" в центре администрирования. Например, можно создать политику на внутренних веб-сайтах для совместной работы, явно запрещающую доступ к учетных записям партнеров. Политики для веб-приложения обеспечиваются независимо от настроек разрешений отдельных веб-сайтов и документов в рамках веб-приложения.
Оптимизация производительности. Можно добиться оптимальной производительности веб-сайтов, если разместить их в веб-приложениях вместе с другими приложениями с аналогичными характеристиками данных. Например, характеристики данных самостоятельно создаваемых веб-сайтов включают большое число меньших по размеру веб-сайтов. С другой стороны, веб-сайты групп содержат небольшое число очень крупных веб-сайтов. Если разместить эти два разных типа веб-сайтов в раздельные веб-приложения, то конечные базы данных будут состоять из данных со схожими характеристиками, что оптимизирует производительность базы данных. В этой модели к веб-сайтам групп и самостоятельно создаваемым веб-сайтам не предъявляются никакие уникальные требования к изоляции данных, поэтому их можно использовать в одном пуле приложений. Однако веб-сайты групп и самостоятельно создаваемые веб-сайты размещаются в разных веб-приложениях для оптимизации производительности.
Оптимизация управляемости. Поскольку создание раздельных веб-приложений приводит к появлению отдельных веб-сайтов и баз данных, то можно реализовать различные ограничения для корзины, сроков давности и емкости каждого веб-сайта, а также согласовать различные соглашения об уровне обслуживания. Например, можно разрешить использовать больше времени на восстановление контента самостоятельно создаваемого веб-сайта, если этот тип контента не является наиболее важным в организации. Это позволяет восстановить более важный контент до восстановления контента этих веб-сайтов. В этой модели самостоятельно создаваемые веб-сайты размещаются в отдельном веб-приложении, что позволяет администраторам более активно управлять развитием по сравнению с другими приложениями.
Семейства веб-сайтов
Семейства веб-сайтов объединяют логическую и информационную архитектуру. В этой модели задачей разработки семейств веб-сайтов является удовлетворение потребностей в разработке URL-адресов и создание логических подразделов контента.
Для удовлетворения потребностей в разработке URL-адресов каждому веб-приложению присваивается одно семейство веб-сайтов корневого уровня. Управляемые пути применяются для внедрения второго уровня в семействах веб-сайтов верхнего уровня. Дополнительные сведения о требованиях URL-адресов и об использовании управляемых путей см. в статье "Зоны и URL-адреса" далее в этой статье. Каждый веб-сайт ниже второго уровня семейств веб-сайтов является дочерним.
На следующем рисунке отображена иерархия веб-сайтов групп.
.jpg "Логическая архитектура для веб-сайтов совместной работы")
Учитывая требование для семейства веб-сайтов корневого уровня, решения по разработке непосредственно связаны со вторым уровнем семейств веб-сайтов. В этой модели приведены варианты, основанные на направленности приложения.
Самостоятельно создаваемые сайты
В этой модели самостоятельно создаваемые веб-сайты содержат веб-сайт верхнего уровня, расположенный по URL-адресу http://sites. Используется управляемый путь (за счет применения включения по шаблону), что позволяет создавать неограниченное число пользовательских веб-сайтов. Все пути, расположенные по управляемому пути, — это независимые семейства веб-сайтов, наследующие шаблон веб-сайта, использованный для создания веб-сайта верхнего уровня. На следующем рисунке изображены самостоятельно создаваемые веб-сайты.
Дополнительные сведения о самостоятельно создаваемых веб-сайтах см. в статье Plan process for creating sites (Windows SharePoint Services).
Сайты групп
При проектировании семейства веб-сайтов внутри приложения веб-сайта групп рекомендуется создавать ограниченное число семейств веб-сайтов для своей организации на основании того, каким образом организация функционирует При таком подходе семейства веб-сайтов создаются администратором Windows SharePoint Services 3.0. После создания семейства веб-сайтов групп могут создавать веб-сайты в рамках семейства веб-сайтов, когда возникает подобная необходимость.
Этот подход предоставляет возможность внедрения продуманной таксономии, что обеспечивает необходимую структуру для методов администрирования и развития веб-сайтов групп. Кроме того, возникает больше возможностей для совместного использования шаблонов и средств перемещения между проектами и группами, использующими одно семейство веб-сайтов. Сложность для информационных архитекторов представляет создание второго уровня семейств веб-сайтов, необходимых для организации. В следующей таблице перечисляются рекомендации для различных типов организаций.
| Тип организации | Рекомендованные таксономии для семейств веб-сайтов |
|---|---|
Разработка продуктов |
|
Исследования |
|
Высшее учебное заведение |
|
Государственный законодательный орган |
|
Корпоративная юридическая фирма |
|
Промышленное предприятие |
|
Партнерская сеть
Партнерская сеть предназначена для совместной работы с внешними партнерами над проектами, имеющими ограниченную сферу приложения или длительность. Изначально веб-сайты в приложении партнерской сети не предназначены быть связанными. В число требований для партнерской сети входит обеспечение следующих показателей:
Владельцы проекта могут легко создавать веб-сайты для совместной работы с партнерами.
Партнеры и другие участники получают доступ только к проектам, над которым они работают.
Разрешениями управляют владельцы веб-сайтов.
Результаты поиска по одному проекту не открывают контент других проектов.
Администраторы могут легко определять неиспользуемые веб-сайты и удалять их.
Для удовлетворения этих требований в модели предусмотрены семейства веб-сайтов для каждого проекта, что обеспечивает следующие преимущества:
Отдельные семейства веб-сайтов предоставляют необходимый уровень изоляции между проектами.
Возможно внедрение возможности самостоятельного создания веб-сайтов.
Базы данных контента
Для внедрения баз данных контента в проект можно воспользоваться следующими двумя подходами (в модели применены оба подхода):
Установите определенные размеры для баз данных контента с соответствующими лимитами размеров, после достижения которых следует предупреждение. После достижения лимита и получения предупреждения создавайте новые базы данных. При таком подходе семейства веб-сайтов автоматически добавляются к доступным базам данных, основываясь только на указанном размере.
Свяжите семейства веб-сайтов с определенными базами данных контента. Данный подход позволяет размещать одно или несколько семейств веб-сайтов в отдельную базу данных, которой можно управлять независимо от остальных баз.
Чтобы связать семейства веб-сайтов с определенными базами данных контента, воспользуйтесь следующим методом:
Используйте программу командной строки Stsadm, чтобы создать семейство веб-сайтов в определенной базе данных.
Выделите базу данных для отдельного семейства веб-сайтов путем применения следующих настроек емкости базы данных:
Число веб-сайтов, при достижении которого выдается предупреждение = 1
Максимальное число веб-сайтов, которое может быть создано в этой базе данных = 1
Добавьте группу семейств веб-сайтов в выделенную базу данных, выполнив следующие действия:
Создайте базу данных в веб-приложении и установите для базы данных состояние Готово.
Для всех остальных баз данных установите состояние Отключено. Пока базы данных контента отключены, создавать новые семейства веб-сайтов нельзя. Однако существующие семейства веб-сайтов в отключенных базах данных по-прежнему доступны и для операций чтения, и для операций записи.
Создайте семейства веб-сайтов. Они будут автоматически добавлены в базу данных.
Верните всем остальным базам данных состояние Готово.
Сайты групп
В модели предусмотрены выделенные базы данных для всех семейств веб-сайтов групп. Такой подход позволяет независимо управлять каждой базой данных групп для осуществления резервного копирования, восстановления и переноса. Кроме того, по завершении проекта можно легко архивировать базу данных, связанную с этим проектом.
Самостоятельно создаваемые сайты
Для самостоятельно создаваемых веб-сайтов в модели достигается эффективность масштабирования за счет управления базами данных до максимального конечного размера. Для решения этой задачи используются следующие настройки:
Максимальный объем дискового пространства, используемого веб-сайтом Этот параметр ограничивает размер личного веб-сайта и находится на странице "Шаблоны квот" в центре администрирования.
Корзина второго уровня Этот параметр указывает объем дополнительного дискового пространства, выделенного для корзины второго уровня. Он находится на странице "Общие параметры веб-приложения".
Максимальное число веб-сайтов, которое можно создать в этой базе данных Этот параметр настраивается при создании базы данных. Рассчитайте общий допустимый размер веб-сайтов, используя значения, указанные для двух предыдущих параметров. Затем на основе конечного размера каждой базы данных определите количество веб-сайтов для базы данных.
В этой модели представлены указанные далее примеры настроек размеров на основе конечного размера базы данных в 100 гигабайт (ГБ) и конечного размера личного веб-сайта в 500 мегабайт (МБ):
Ограничение размера веб-сайта = 500 МБ
Конечный размер базы данных = 100 ГБ
Максимальное число веб-сайтов = 200
Предупреждение о размере веб-сайта = 175
При получении предупреждения о размере веб-сайта создавайте новую базу данных. После этого новые самостоятельно создаваемые веб-сайты поочередно добавляются в новую и существующую базы данных, пока не будет достигнуто максимальное число веб-сайтов в одной из этих баз данных.
Партнерская сеть
Так же, как и самостоятельно создаваемые веб-сайты, партнерская сеть обеспечивает эффективность масштабирования за счет расширения баз данных до максимального конечного размера.
Поскольку партнерская сеть размещается в выделенном веб-приложении, можно указывать лимиты размеров, более соответствующие типам создаваемых размеров. В этой модели приводятся следующие примеры параметров размеров:
Конечный размер базы данных = 100 ГБ
Квота дискового пространства на веб-сайт = 5 ГБ
Максимальное число веб-сайтов = 20
Зоны и URL-адреса
В этой модели иллюстрируется процедура согласования URL-адресов для ряда приложений в рамках корпоративного развертывания.
Задачи разработки
На решения по разработке URL-адресов оказывают влияние следующие задачи:
Соглашения по URL-адресам не ограничивают зоны, через которые возможен доступ к контенту.
Стандартные порты HTTP и HTTPS (80 и 443) можно использовать во всех приложениях этой модели.
Номера портов не входят в состав URL-адресов. На практике номера портов обычно не используются в рабочей среде.
Принципы разработки
Для решения этих задач применяются следующие принципы разработки:
Именованные семейства веб-сайтов не используются. Обратите внимание, что именованные семейства веб-сайтов отличаются от заголовков веб-сайтов IIS. Именованные семейства веб-сайтов не поддерживают функцию альтернативного сопоставления доступа. Эта функция необходима для доступа к одному и тому же контенту через несколько URL-адресов в домене. Следовательно, при использовании именованных веб-сайтов эти веб-сайты доступны только через зону по умолчанию. Функция альтернативного сопоставления доступа также обеспечивает поддержку внешнего завершения подключений по протоколу SSL, что разрешает сценариям доступа удаленных сотрудников и партнеров использовать протокол SSL (HTTPS). Дополнительные сведения об использовании именованных семейств веб-сайтов см. в статье White paper: Create shared hosting solutions on Windows SharePoint Services.
Каждое приложение включает одно семейство веб-сайтов корневого уровня. Это требуется для применения альтернативного сопоставления доступа. Если в рамках веб-приложение требуется несколько семейств веб-сайтов корневого уровня и для пользовательского доступа планируется использовать только зону по умолчанию, то применение именованных семейств веб-сайтов вполне целесообразно.
Для приложений, включающих несколько семейств веб-сайтов высокого уровня, где каждое семейство веб-сайтов соответствует группе или проекту верхнего уровня (например, веб-сайты групп), то в модели применяются управляемые пути. Управляемые пути обеспечивают значительно большие возможности управления URL-адресами для этих типов веб-сайтов.
Компромиссные решения при разработке
Согласование задач разработки приводит к некоторым компромиссным решениям, среди которых можно выделить следующие:
URL-адреса длиннее.
Именованные семейства веб-сайтов не используются.
Разработка URL-адресов с балансировкой нагрузки
При создании веб-приложения необходимо назначить веб-приложению выбранный URL-адрес с балансировкой нагрузки. Кроме того, необходимо создать URL-адрес с балансировкой нагрузки для каждой зоны, создаваемой в рамках веб-приложения. В состав URL-адреса с балансировкой нагрузки входит протокол, схема, имя веб-сайта, а также при необходимости номер порта. Каждый URL-адрес с балансировкой нагрузки должен быть уникальным для всех веб-приложений и зон. Следовательно, для каждого приложения и для каждой зоны в рамках каждого приложения требуется уникальный для модели URL-адрес.
Внутренние веб-сайты совместной работы
Для обоих типов внутренних веб-сайтов совместной работы необходимы уникальные URL-адреса. В этой модели целевая аудитория этих веб-сайтов — это внутренние и удаленные сотрудники. В следующей таблице перечислены URL-адреса для доступа внутренних и удаленных сотрудников к каждому приложению.
| Приложение | URL-адрес внутреннего сотрудника | URL-адрес удаленного сотрудника |
|---|---|---|
Сайты групп |
http://teams/ |
https://teams.fabrikam.com/ |
Самостоятельно создаваемые сайты |
http://sites |
https://sites.fabrikam.com/ |
Партнерская сеть
В этой модели доступ к партнерской сети используют внутренние сотрудники, удаленные сотрудники и сотрудники партнеров. Хотя как удаленные сотрудники, так и сотрудники партнеров получают доступ к партнерской сети извне по протоколу SSL (HTTPS), но каждой из этих двух групп требуется свой URL-адрес для реализации преимуществ применения отдельных зон — разных методов проверки подлинности и разных политик зон. В следующей таблице перечислены URL-адреса для доступа внутренних сотрудников, удаленных сотрудников и сотрудников партнеров к партнерской сети.
| Зона | URL-адрес |
|---|---|
URL-адрес внутреннего сотрудника |
http://partnerweb/ |
URL-адрес удаленного сотрудника |
https://remotepartnerweb.fabrikam.com/ |
URL-адрес партнера |
https://partnerweb.fabrikam.com/ |
Использование явных включений и включений по шаблону для URL-путей
С помощью определения управляемых путей можно указать пути для семейств веб-сайтов в пространстве URL-имен веб-приложения. Также можно указать, что одно или несколько семейство веб-сайтов существуют в уникальном пути корневого веб-сайта. Без использования управляемых путей все веб-сайты, созданные ниже корневого семейства веб-сайтов, становятся частью корневого семейства.
Можно создать управляемые пути двух следующих типов:
Явное включение Семейство веб-сайтов с явно заданным URL-адресом. Явное включение применяется только к одному семейству веб-сайтов. Можно создать ряд явных включений ниже корневого семейства веб-сайтов. Примером URL-адресе для семейства веб-сайтов, созданного с помощью этого метода, является адрес http://team/Team1.
Включение по шаблону Путь, который добавляется к URL-адресу. Этот путь обозначает, что все веб-сайты, указанные непосредственно после имени пути являются уникальными семействами веб-сайтов. Этот вариант обычно используется для приложений, поддерживающих самостоятельное создание веб-сайтов. Примером URL-адреса для семейства веб-сайтов, созданных с помощью этого метода, является адрес http://sites/site1.
В этой модели предусматривается применение обоих типов включения, которые описаны в следующих разделах.
Явные включения: веб-сайты групп
В этой модели оба приложения веб-сайтов групп включают использование явных включений.
Сайты групп
В приложении веб-сайтов групп явное включение применяется для каждого семейства веб-сайтов групп. Ограничение масштабирования семейства веб-сайтов, созданного с помощью явного включения, составляет около 100 веб-сайтов. Рекомендуется поддерживать число веб-сайтов групп верхнего уровня на значении, котором можно эффективно управлять. Кроме того, таксономия веб-сайтов групп должна логически соответствовать методами работы предприятия. Многие организации отлично укладываются в рекомендуемые 100 веб-сайтов. Если для организации требуется большее масштабирование веб-сайтов групп, то необходимо использовать включение по шаблону.
В этой модели использование явных включений результатов отражается в URL-адресах следующей таблицы.
| Внутренний сотрудник (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
В этой примере корневое семейство веб-сайтов, http://team,/ не обязательно содержит контент для пользователей.
Включения по шаблону: партнерские сети и самостоятельно создаваемые веб-сайты
Как партнерские сети, так и самостоятельно создаваемые веб-сайты предусматривают использование включений по шаблоны. Включение по шаблону идеально походит для приложений, позволяющих пользователям создавать собственные семейства веб-сайтов. Включение по шаблону указывает, что элемент, следующий после шаблона, является корневым веб-сайтом для семейства веб-сайтов.
Самостоятельно создаваемые сайты
В этой модели самостоятельно создаваемые веб-сайты содержат включение по шаблону "/sites" (http://selfservice/sites).
Таким образом формат URL-адреса соответствует формату, приведенному в следующей таблице.
| Внутренний (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.fabrikam.com/personal/user3 |
Партнерская сеть
Партнерская сеть предназначена для предоставления сотрудникам возможности легко создавать защищенные веб-сайты для совместной работы с внешними партнерами. Чтобы обеспечить выполнение этой задачи, разрешено самостоятельное создание веб-сайтов.
В этой модели в партнерской сети предусмотрено включение по шаблону "/sites" (http://partnerweb//sites). Таким образом формат URL-адреса соответствует формату, приведенному в следующей таблице.
| Внутренний сотрудник (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://partnerweb//sites/project1 |
https://remotepartnerweb.fabrikam.com//sites/project1 |
http://partnerweb//sites/project2 |
https://remotepartnerweb.fabrikam.com//sites/project2 |
http://partnerweb//sites/project3 |
https://remotepartnerweb.fabrikam.com//sites/project3 |
Участники-партнеры могут получать доступ к веб-сайтам партнерской сети с помощью URL-адресов, перечисленных в следующей таблице.
| Партнер (зона экстрасети) |
|---|
https://partnerweb.fabrikam.com//sites/project1 |
https://partnerweb.fabrikam.com//sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
Политики зон
Для обеспечения разрешений на уровне веб-приложения можно создать политику для веб-приложения. Политика может быть назначена для веб-приложения в целом или лишь для определенной зоны. Политики обеспечивает разрешения на весь контент в рамках веб-приложения или указанной зоны. Разрешения политики перекрывают все остальные параметры безопасности, настроенные для веб-сайтов и контента. Можно настроить политику, основанную на пользователях, группах пользователей, но не группах SharePoint.
В модели содержится один пример: отказ учетным записям партнера в доступе к внутренним веб-сайтам совместной работы.
Резервное копирование и восстановление веб-сайтов для совместной работы
Для веб-сайтов совместной работы подходит несколько вариантов резервного копирования и восстановления контента:
Встроенные средства резервного копирования и восстановления. Используйте средства, входящие в состав Windows SharePoint Services 3.0, если размер баз данных не превышает 100 ГБ, и в них внесено небольшое число настроек, или настройки упакованы как решения.
Средства резервного копирования и восстановления Microsoft SQL Server 2005. Используйте эти средства при наличии администратора базы данных SQL.
Дополнительные сведения см. в статье Choose backup and recovery tools (Windows SharePoint Services).
Проектирование безопасной внешней совместной работы
Плакат с примером проекта содержит обзор методов планирования безопасной внешней совместной работы. В этом разделе содержится вступительный текст для каждого элемента и ссылки на соответствующие статьи в библиотеке TechNet.
| Рекомендации по проектированию | Указание |
|---|---|
Выбор технологии экстрасети |
Защита фермы серверов либо за счет использования пограничного межсетевого экрана, либо за счет размещения фермы серверов в демилитаризованной зоне. Дополнительные сведения см. в следующих статьях на сайте TechNet:
|
Безопасная связь клиент-сервер |
Безопасная совместная работа в среде экстрасети зависит от безопасного взаимодействия между клиентскими компьютерами и средой фермы серверов. Везде, где можно, используйте протокол SSL для безопасной связи между клиентскими компьютерами и серверами. Дополнительные сведения см. в следующих статьях на сайте TechNet: |
Защита внутренних серверов и веб-сайта центра администрирования |
Для совместной работы в безопасной внешней среде необходимо использовать серверы, доступные через Интернет. Можно ограничить видимость для трафика из Интернета, разместив межсетевой экран между веб-серверами и другими серверами или поместив веб-сайт центра администрирования на внутреннем сервере. Дополнительные сведения см. в следующих статьях на сайте TechNet:
|
Настройка альтернативных сопоставлений доступа |
Альтернативные сопоставления доступа поддерживают сценарии развертывания Интернета, в которых URL-адрес веб-запроса, полученного службами IIS, отличается от URL-адреса, введенного конечным пользователем. Чаще всего это происходит в сценариях развертывания, включающих публикацию обратного прокси-сервера и балансировку нагрузки. Например, обратные прокси-серверы могут выполнять расширенные функции, такие как получение веб-запроса через Интернет с использованием протокола SSL (HTTPS), но передавать запрос на сервер с использованием HTTP. Эта возможность называется "автономным завершением SSL". Дополнительные сведения см. в статье Plan alternate access mappings. |
Загрузить эту книгу
Для упрощения чтения и печати этот раздел включен в следующую загружаемую книгу:
Полный список доступных книг см. в разделе Загружаемые книги для служб Windows SharePoint Services.