Компоненты логической архитектуры
Содержание:
Фермы серверов
Поставщики общих служб
Пулы приложений IIS
Веб-приложения
Зоны
Политика для веб-приложений
Базы данных контента
Семейства сайтов
Сайты
Именованные семейства сайтов
Личные узлы
При разработке логической архитектуры существует несколько способов организации компонентов. Каждый из компонентов предоставляет различные возможности как для общего доступа, так и для изоляции. Перед началом разработки логической архитектуры:
Определите цели общего доступа и изоляции.
Оцените целесообразность каждого варианта.
В каждом разделе этой статьи описывается определенный компонент логической архитектуры и обсуждаются следующие характеристики этого компонента: емкость, общий доступ и изоляция, настраиваемые элементы, администрирование и рекомендации по планированию.
Информацию о внедрении компонентов логической архитектуры в простом варианте дизайна см. в разделе Модель логической архитектуры: корпоративное развертывание.
Фермы серверов
С технической точки зрения фермы серверов не являются компонентами логической архитектуры. Однако ферма серверов представляет собой конструктивный элемент высшего уровня. Отдельные серверные фермы обеспечивают физическую изоляцию.
На количество необходимых ферм серверов могут повлиять некоторые критерии, определенные организацией, например:
Разделение ответственности работающих подразделений.
Выделенные источники финансирования.
Раздельное расположение центров обработки данных.
Отраслевые требования к физической изоляции сайтов.
Несмотря на вышесказанное, многие требования изоляции можно обеспечить на одной ферме серверов. Например, можно использовать разные пулы приложений IIS для разных типов процессов, чтобы добиться изоляции на уровне процессов. Также можно использовать раздельные веб-приложения для изоляции на уровне веб-приложений.
В дополнение к требованиям изоляции, которые могут диктовать необходимость в нескольких фермах серверов, организация может внедрить несколько ферм серверов для обеспечения целевых показателей производительности и масштабирования.
В Microsoft Office SharePoint Server 2007 есть другие факторы, которые могут вызвать потребность в развертывании нескольких ферм серверов. Например, это могут быть вопросы лицензирования или внедрения среды публикации. Более подробную информацию см. в разделе Планирование ферм серверов.
Поставщики общих служб
Поставщик общих служб предоставляет стандартный набор служб и данных служб для логической группы веб-приложений и связанных с ними сайтов. В число служб и данных служб входят:
службы личной настройки, включая личные узлы;
аудитории;
каталог бизнес-данных;
службы Excel;
служба поиска Office SharePoint Server;
отчеты об использовании.
Поставщики общих служб связаны с веб-приложениями. Все сайты веб-приложения обслуживаются поставщиком общих служб, присвоенныи веб-приложению. У поставщика общих служб могут размещаться службы нескольких веб-приложений.
Емкость
Создать можно до 20 поставщиков общих служб на каждую ферму. Чтобы избежать ухудшения производительности, рекомендуется использовать не более трех поставщиков общих служб.
Общий доступ и изоляция
Отдельные поставщики общих служб обеспечивают изоляцию профилей, контента и результатов поиска от процессов. Изоляция выполняется следующими методами:
Каждый поставщик общих служб располагается в отдельном пуле приложений IIS.
Каждый поставщик общих служб использует уникальный набор служебных учетных записей для запуска служб, предоставленных поставщиком общих служб, например, поиска, обхода контента и импорта профилей.
Самые важные критерии, определяющие количество поставщиков общих служб в логической архитектуре, следующие:
Потребность в общем доступе к контента и данным профиля с сайтов которые находятся в отдельных веб-приложениях и пулах приложений IIS. Например, можно обеспечить общий доступ к личным сайтам, сайтам групп и опубликованному контенту через интрасеть, связав эти сайты одним поставщиком общих служб.
Потребность в изоляции контента и аудиторий определенных сайтов. Например, если на ферме серверов расположены приложения для нескольких классов пользователей, отдельные поставщики общих служб могут помочь изолировать эти классы.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Разрешения общих служб |
Управление общими службами можно передать другим лицам, предоставив им разрешение для одной или более служб. Кроме того, для просмотра и управления общими службами пользователи должны иметь разрешения доступа к веб-сайту администрирования общих служб. |
Надежные расположения личного узла |
В организациях, где личные узлы предоставляет несколько поставщиков общих служб эта функция гарантирует, что пользователи будут создавать в поставщике общих служб узлы, соответствующие их профилям. Она не позволяет создавать в организации несколько личных сайтов. Дополнительную информацию см. в разделе "Координирование личных сайтов организации" документа Построение архитектуры личных сайтов. |
Администрирование
Функции настройки и управления поставщика общих служб можно передать администраторам, которые специализируются в поддержке общих служб, например, поиска и аудиторий.
В среде размещения администраторы могут настроить по одному поставщику общих служб на клиента и позволить клиентам управлять собственными общими службами.
Дополнительную информацию о планировании ролей администрирования поставщика общих служб см. в разделе Планирование ролей безопасности (Office SharePoint Server).
Рекомендации по планированию
Настройте поставщика общих служб, чтобы усовершенствовать общий доступ к данным нескольких веб-приложений или дополнительно изолировать контент одного веб-приложения.
Например, несколько сайтов из одного веб-приложения можно объединить с использованием общего поставщика общих служб, чтобы обеспечить общий доступ к контенту и профилям в интрасети. Это позволит выполнить персонализацию и поиск в масштабах предприятия, по многочисленным сайтам и приложениям. Это пример балансировки изоляции процесса (методов внедрения отдельных веб-приложений и пулов приложений) и потребностей в общем доступе к данным и использовании данных профилей в разных приложениях.
Кроме того, поставщика общих служб можно настроить для совершенствования изоляции в целом. Например, использование выделенного поставщика общих служб для сотрудничества с партнером гарантирует, что партнер не получит доступа к уязвимым данным из среды интрасети и не сможет их найти. Поставщих общих служб позволяет дополнительно изолировать контент семейств сайтов следующими способами:
Ограничение результатов поиска отдельными семействами сайтов.
Использование аудиторий для указанного контента и определенных групп пользователей.
Использование программы командной строки Stsadm для настройки средства выбора людей только на отображение пользователей, которые являются участниками семейства сайтов.
При разработке стратегии поставщика общих служб нужно продумать способы настройки отдельных служб поставщика общих служб для более успешного достижения целей в области общего доступа или изоляции.
Пулы приложений
Пул приложений — это группа, состоящая из одного или более URL-адресов (или веб-сайтов, представленных в IIS) и обслуживаемая рабочим процессом. Каждый пул приложений имеет собственный рабочий процесс и удостоверение (учетную запись безопасности), не допускающее взаимодействия двух процессов.
Емкость
Память служебных данных пула приложений — 30-50 мегабайт (МБ) плюс любая память для приложений, запущенных в пространстве процессов пула приложений. Предельное число пулов приложений определяется объемом доступной системной памяти. Это значит, что число пулов приложений зависит от двух следующих факторов:
Доступная для адресации память.
Размер приложения, запущенного в пуле приложений.
Для обеспечения приемлемой производительности рекомендуется в первую очередь использовать не более восьми пулов приложений.
Общий доступ и изоляция
Пулы приложений IIS позволяют обеспечить работу нескольких сайтов на одном серверном компьютере, при этом сайты по-прежнему используют собственные рабочие процессы и удостоверения. Тем самым для одиночных сайтов устраняется уязвимость, позволяющая злоумышленнику вставлять вредоносный код для атаки на сайты в разных пулах приложений.
Настраиваемые элементы
Используйте раздельные удостоверения пулов приложений для каждого пула приложений.
Администрирование
Администрирование включает в себя обслуживание раздельных удостоверений пулов приложений для каждого пула приложений.
Рекомендации по планированию
На практике следует принять во внимание следующие доводы в пользу выделенного пула приложений:
Разделение проверенного и анонимного контента.
Для изоляции приложений, сохраняющих пароли внешних бизнес-приложений и взаимодействующих с этими приложениями (например, для подключений к каталогу бизнес-данных).
Изолирование приложений, предоставляющих пользователям возможность создавать и администрировать сайты, а также совместно работать с контентом.
Веб-приложения
Веб-приложение — это веб-сайт IIS, созданный и используемый продуктами и технологиями SharePoint. Каждое веб-приложение представлено своим веб-сайтом в IIS. Каждому веб-сайту присваивается уникальное имя домена, что помогает предотвратить атаки межсайтовых сценариев.
Емкость
Каждая страница ASP.NET генерирует отдельную динамическую библиотеку (DLL) для каждого веб-приложения. Раздельные библиотеки DLL занимают память, ограничивая количество веб-приложений, которые можно запустить на сервере. Для обеспечения приемлемой производительности рекомендуется запускать не более 99 веб-приложений на поставщике общих служб.
Общий доступ и изоляция
Коллекции и шаблоны регистрируются в базе данных конфигурации фермы серверов. Можно указать, какие веб-приложения смогут их использовать.
Каждому веб-сайту соответствует уникальное имя домена, что помогает предотвратить атаки межсайтовых сценариев.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Поставщики общих служб |
Поставщики общих служб связаны с веб-приложениями. Все сайты веб-приложений обслуживает один и тот же поставщик общих служб. Поставщик общих служб может обслуживать несколько веб-приложений, обеспечивая общий доступ к их контенту и данным профилей. |
Зоны |
В рамках веб-приложения можно создать до пяти зон. Зоны позволяют применять разные условия доступа и политики для крупных классов пользователей. |
Политика для веб-приложения |
Создайте политику "Все зоны", чтобы определить условия политики, применяемые ко всем зонам веб-приложения. |
Администрирование
Текущие задачи администрирования веб-приложений не представляют существенной сложности.
Рекомендации по планированию
Основной сферой применения выделенных веб-приложений являются следующие задачи:
Отделение контента, доступного анонимным пользователям, от контента, доступного только зарегистрированным пользователям.
Изолирование пользователей. Например, можно гарантированно изолировать партнеров от доступа к контенту экстрасети, разместив сайты партнеров в отдельном веб-приложении.
Обеспечение разрешений. Выделенное веб-приложение предоставляет возможность обеспечить разрешения с помощью политик, используя страницу центра администрирования "Политика для веб-приложения". Например, можно создать политику для явного запрета доступа на запись одной или нескольким группам пользователей. Политики для веб-приложения обеспечиваются независимо от настроек разрешений отдельных сайтов и документов в рамках веб-приложения.
Оптимизация производительности базы данных. Производительность веб-приложений можно повысить, разместив их вместе с другими приложениями со схожими характеристиками данных. Например, группа "Мои сайты" обычно характеризуется большим количеством сайтов незначительной емкости. С другой стороны, сайты рабочих групп содержат меньшее число очень крупных сайтов. Если разместить эти два разных типа сайтов в раздельные веб-приложения, то конечные базы данных будут состоять из данных со схожими характеристиками, что оптимизирует производительность базы данных.
Оптимизация управляемости. Поскольку создание раздельных веб-приложений предполагает наличие отдельных сайтов и базы данных, то можно реализовать различные ограничения для корзины, сроков давности и емкости каждого сайта, а также согласовать различные соглашения об условиях обслуживания. Например, можно разрешить использовать больше времени на восстановление сайтов, не имеющих критической важности для бизнеса.
Зоны
Зоны представляют собой разные логические пути (URL-адреса) получения доступа к одному веб-приложению. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть". Каждую зону представляет отдельный веб-сайт в IIS.
Зона по умолчанию — это зона, которая создается первой при создании веб-приложения.
Емкость
В веб-приложении можно создать до пяти зон. Обычно зоны согласовываются между веб-приложениями так, чтобы зоны с одинаковым именем были настроены для одинаковых пользователей.
Общий доступ и изоляция
Зоны предоставляют метод разделения пользователей на группы:
**Тип проверки подлинности **Каждая зона может быть настроена на использование собственного поставщика проверки подлинности, что позволяет реализовать совместный доступ к одному и тому же контенту для компаний-партнеров.
**Зона сети **Каждая зона может быть настроена для учета зоны сети, из которой входит пользователь, например, из экстрасети или Интернета.
Политика разрешений Можно явно разрешить или запретить доступ на чтение или запись контента в зоне, основываясь на учетной записи пользователя или группы.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Поставщик проверки подлинности |
Каждая зона может быть настроена на использование собственного поставщика проверки подлинности. |
Протокол SSL |
Включить или выключить протокол SSL в каждой зоне. |
URL-адрес со сбалансированной нагрузкой и альтернативное сопоставление доступа |
Укажите, какое имя домена будут вводить пользователи для доступа к контенту веб-приложения. Либо используйте альтернативное сопоставление доступа, чтобы сопоставить URL-адресу по умолчанию (имени сервера или порта) каждой зоны наглядные или более соответствующие зоне IP-адреса. Альтернативное сопоставление доступа позволяет использовать внешние конечные точки для SSL-соединений: прокси-сервер является конечной точкой SSL-соединения, ретранслируя запросы веб-серверу по протоколу HTTP. В этом случае можно настроить альтернативные сопоставления доступа для возвращения запросов по протоколу SSL, чтобы обеспечить безопасное соединение между клиентом и сервером. |
Политика для веб-приложения |
Создайте уникальный набор политик для каждой зоны в рамках веб-приложения. При наличии специальной группы пользователей, требующей исключений из общей политики безопасности, рекомендуется использовать для этих пользователей отдельную зону. |
Администрирование
Если используется альтернативное сопоставление доступа, обратите внимание на то, что всем общедоступным URL-адресам требуются записи службы доменных имен (DNS) для сопоставления общедоступных URL-адресов с IP-адресами службы балансировки нагрузки фермы.
Рекомендации по планированию
Для успешного развертывания на этапе разработки зон большую важность имеет ряд ключевых решений. К таковым относятся решения по разработке и настройке следующих зон:
Зона по умолчанию
Зоны для внешнего доступа
В следующем разделе приведены некоторые рекомендации и требования по планированию зон.
Требования конфигурации зоны по умолчанию
Зона, требующая больше всего внимания — это зона по умолчанию. Далее описаны требования, которые относятся к настройке зоны по умолчанию.
Зона по умолчанию должна быть самой защищенной зоной, поскольку когда запрос пользователя не может быть сопоставлен с какой-либо зоной, то применяется проверка подлинности и политика зоны по умолчанию.
Для обхода контента компонент индексирования требует доступа к контенту по крайней мере одной зоны. По умолчанию компонент индексирования использует проверку подлинности NTLM. При обходе контента определенного диапазона URL-адресов администратор службы поиска может настроить правила обхода контента таким образом, чтобы использовать либо базовую проверку подлинности, либо сертификат клиента. Следовательно, для обхода контента по крайней мере одна зона должна быть настроена на использование проверки подлинности NTLM, базовой проверки подлинности или сертификатов. Кроме того, до обнаружения зоны, подлинность которой можно проверить, обходчик будет опрашивать зоны в следующем порядке: зона по умолчанию, зона интрасети, зона Интернета, специальная зона, зона экстрасети. Однако если обходчик сначала обнаружит зону, которая настроена на использование проверки подлинности Kerberos и не настроена на использование стандартного порта (с номером 80 или 443), то обходчик не будет проверять ее подлинность и не произведет попытки доступа к следующей зоне. Поэтому удостоверьтесь, что настройка проверки подлинности Kerberos для отдельных зон не остановит индексирование компонентов обходчиком. Дополнительные сведения о требованиях проверки подлинности, связанных с обходом контента, см. в статье Планирование способов проверки подлинности (Office SharePoint Server).
Административная электронная почта, включая сообщения для владельцев сайтов, почти исчерпавших квоту, отправляется со ссылками из зоны по умолчанию. Таким образом, пользователи, которые получают административные сообщения электронной почты и предупреждения, должны иметь возможность получить по ссылкам доступ к зоне по умолчанию. Это особенно важно для владельцев сайтов.
Именованные семейства сайтов доступны только в зоне по умолчанию. Все пользователи, которым назначен доступ к именованным семействам сайтов, должны иметь доступ к зоне по умолчанию.
Настройка зон для среды экстрасети
В среде экстрасети разработка зон критически важна по двум причинам:
Запрос пользователя может быть инициирован из нескольких разных сетей, например, из внутренней сети, сети компании-партнера или Интернета.
Пользователи одновременно используют контент различных веб-приложений. Например, в среду интрасети могут входить сайты, которые размещены в нескольких разных веб-приложениях. Кроме того, сотрудники могут иметь доступ и к контенту интрасети, и к совместному с партнерами контенту.
Убедитесь, что в среде экстрасети соблюдены следующие принципы разработки:
Зоны группы веб-приложений должны быть настроены так, чтобы они были согласованы друг с другом. Настройки проверки подлинности и назначения пользователей должны быть одинаковы, но политика, связанная с зонами, может отличаться для разных веб-приложений. В частности, необходимо убедиться, что зона интрасети используется одними и теми же сотрудниками во всех веб-приложениях. Другими словами, нельзя настраивать зону интрасети в одном веб-приложении для внутренних сотрудников, а в другом — для удаленных сотрудников.
Альтернативные сопоставления доступа для каждой зоны и каждого ресурса должны быть настроены корректно и точно.
Политика для веб-приложения
Политика для веб-приложения обеспечивает разрешения на весь контент в рамках веб-приложения, позволяя настраивать политику уровня безопасности для пользователей веб-приложения. Разрешения политики перекрывают все параметры безопасности, которые настроены для сайтов и контента.
Можно настроить политику, основанную на пользователях, группах пользователей, но не группах SharePoint. Политика может быть назначена для веб-приложения в целом или лишь для определенной зоны.
Емкость
Не существует ограничений на емкость, которые влияли бы на политики для веб-приложений.
Общий доступ и изоляция
Политика для веб-приложения предоставляет метод установки разрешений, основанный на пользователях и на зонах, к контенту которых они имеют доступ.
Например, используя политику, можно:
Разрешить персоналу службы поддержки доступ ко всему контенту.
Запретить доступ на запись для партнеров и поставщиков.
Запретить доступ к защищенным данным для класса пользователей независимо от того, как владельцы сайта настроили разрешения.
Проконтролировать, что учетная запись обхода имеет доступ для обхода всего контента.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Зона |
Политика будет применяться к определенной зоне в рамках веб-приложения — например, к зоне интрасети — или ко всем зонам в рамках веб-приложения. |
Пользователи |
Укажите пользователей, к которым следует применить политику, воспользовавшись одним из следующих списков:
|
Разрешения |
Выберите разрешения, которые необходимо предоставить пользователям:
Данные разрешения перекрывают любые разрешения, назначенные веб-приложением, в том числе разрешения, установленные для семейств сайтов, сайтов, списков, документов и т. д. |
Администрирование
Непрерывное администрирование веб-приложений не представляет особой сложности.
Рекомендации по планированию
Поскольку управление политиками осуществляется централизованно, рекомендуется использовать политики для управления большими классами пользователей, а не отдельными пользователями.
Базы данных контента
По умолчанию весь контент веб-приложения хранится в одной базе данных контента. Можно разделить контент по нескольким базам данных на уровне семейства сайтов. База данных контента может включать одно или несколько семейств сайтов. Одно семейство сайтов не распространяется на несколько баз данных. Резервное копирование и восстановление сайтов производится на уровне баз данных контента.
Емкость
Для обеспечения приемлемой производительности рекомендуется использовать не более 99 баз данных контента для каждого веб-приложения.
Общий доступ и изоляция
Планирование баз данных позволяет произвести оптимизацию — либо для повышения эффективности (если несколько семейств сайтов имеют общий доступ к одной базе данных), либо для изоляции (если каждое семейство сайтов использует одну базу данных).
Для эффективного масштабирования можно привести базы данных к максимальным размерам. В этом случае параметры базы данных следует настроить таким образом, чтобы новые семейства сайтов добавлялись к существующей базе данных до тех пор, пока не будет достигнуто максимальное число семейств сайтов. Чтобы рассчитать максимальное число семейств сайтов, оцените средний или максимальный размер семейств сайтов и разделите его на максимальный размер одной базы данных. Такой метод хорошо подходит для случаев, в которых ожидается большое число небольших семейств сайтов, например, семейство личных сайтов.
Для изоляции контента между рабочими группами или проектами можно ограничить базу данных одним семейством сайтов. Данный подход позволяет независимо управлять контентом отдельных рабочих групп. Например, можно независимо управлять базой данных каждой рабочей группы для резервного копирования, восстановления и миграции данных. Таким образом предоставляется возможность внедрять соглашения разных служебных уровней для разных рабочих групп или проектов. Также данный подход позволяет управлять контентом на протяжении всего жизненного цикла проекта. Например, можно заархивировать базу данных после завершения проекта.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Сервер баз данных |
Укажите, на каком компьютере с ПО SQL Server создана база данных контента. |
Параметры емкости |
|
Администрирование
Действенный план администрирования базы данных позволяет найти оптимальный баланс между числом баз данных с ресурсами, необходимыми для управления базами данных.
Процедура администрирования баз данных включает в себя:
Создание новых баз данных для сайтов или семейств сайтов рабочих групп, которым требуются отдельные базы данных.
Отслеживание размеров баз данных и создание новых баз данных при достижении определенного размера.
Резервное копирование и восстановление баз данных.
Рекомендации по планированию
Выберите один из двух подходов, предложенных ниже:
Установите определенные размеры для баз данных контента с соответствующими лимитами размеров, после достижения которых следует предупреждение. После достижении лимита и получения предупреждения создавайте новые базы данных. При таком подходе семейства сайтов автоматически добавляются к доступным базам данных, основываясь только на указанном размере.
Свяжите семейства сайтов с определенными базами данных контента. Данный подход позволяет размещать одно или несколько семейств сайтов в отдельную базу данных, которой можно управлять независимо от остальных баз.
Чтобы связать семейства сайтов с определенными базами данных контента, воспользуйтесь следующим методом:
Используйте инструмент командной строки Stsadm, чтобы создать семейство сайтов в определенной базе данных.
Выделите базу данных для одного семейства сайтов, применив указанные далее параметры емкости базы данных на странице "Управление параметрами базы данных содержимого" веб-сайта центра администрирования SharePoint:
Число сайтов, при достижении которого выдается предупреждение = 1
Максимальное число сайтов, которое может быть создано в этой базе данных = 1
Добавьте группу семейств сайтов в выделенную базу данных, выполнив следующие действия:
Создайте базу данных в рамках веб-приложения, затем на странице "Управление параметрами базы данных содержимого" центра администрирования SharePoint установите для базы данных статус Готово.
Для всех остальных баз данных установите статус Отключено. Пока базы данных контента отключены, создавать новые семейства сайтов нельзя. Однако существующие семейства сайтов в отключенных базах данных по-прежнему доступны и для операций чтения, и для операций записи.
Создайте семейства сайтов. Они будут автоматически добавлены в базу данных.
Верните статус Готово для всех остальных баз данных.
Семейства сайтов
Семейство сайтов — это набор веб-сайтов с единым владельцем и общими параметрами администрирования. Каждое семейство сайтов содержит веб-сайт верхнего уровня и может содержать один или более дочерних сайтов.
Емкость
Для обеспечения приемлемой производительности рекомендуется внедрять не более 50 000 семейств сайтов для каждого веб-приложения. Масштабирование, которое заключается в распределении семейств сайтов между различными серверами баз данных, обеспечивает дополнительную емкость для хранения и дополнительную пропускную способность.
Общий доступ и изоляция
Семейства сайтов предоставляют ряд возможностей общего доступа и изоляции, связанных с внедрением разрешений, навигации и функций.
К указанным далее элементам может быть предоставлен общий доступ в рамках семейства сайтов, но не между семействами сайтов:
Шаблоны страниц
Макеты страниц
Изображения
Шаблоны сайтов
Кроме того, разрешения и навигация изолированы на уровне семейств сайтов следующими способами:
Дочерние сайты семейства сайтов могут наследовать разрешения от сайта верхнего уровня.
Семейства сайтов не могут наследовать разрешения от других семейств сайтов.
Встроенная навигация от одного семейства сайтов к другому отсутствует.
Наконец, Office SharePoint Server 2007 собирает воедино результаты поиска по семействам сайтов на основе разрешений пользователя, независимо от количества семейств или баз данных (в зависимости от областей поиска).
Важно отметить, что хотя разрешения обеспечиваются на изолированных сайтах, сайты по-прежнему уязвимы к атакам межсайтовых сценариев из других сайтов домена.
Настраиваемые элементы
В следующей таблице описаны настраиваемые элементы центра администрирования, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Администратор семейства сайтов |
Можно указать одного пользователя, который будет главным администратором семейства сайтов, и одного пользователя, который будет дополнительным администратором этого семейства. В центре администрирования для этих ролей нельзя указать более одной учетной записи и нельзя указать учетную запись группы. |
Шаблон квот |
Можно использовать шаблон квот, чтобы ограничить ресурсы, используемые семейством сайтов. Предоставляются следующие шаблоны:
|
В следующей таблице описаны настраиваемые элементы семейства сайтов, которые используются в процессах изоляции и общего доступа.
| Элемент | Описание |
|---|---|
Администраторы семейства сайтов |
Можно указать несколько учетных записей пользователей, которые будут администраторами семейств сайтов. Добавлять учетные записи групп нельзя. |
Уровень разрешений |
Добавьте для семейства сайтов учетные записи пользователей и групп и укажите уровни разрешений для каждой. |
Администрирование
Создание семейств сайтов не требует DNS-записей и может быть легко автоматизировано или делегировано пользователям. Можно создавать семейства сайтов для сайтов рабочей группы централизировано, а можно позволить пользователям создавать собственные семейства сайтов, используя "Управление средствами самостоятельного создания сайтов". Связывание семейства сайтов с одной базой данных предоставляет возможность проводить резервное копирование и восстановление данных на уровне семейства сайтов.
Рекомендации по планированию
Семейства сайтов объединяют логическую и информационную архитектуру. При разработке собственного семейства сайтов учтите следующие две задачи разработки:
Согласование разработки URL-адресов между организациями.
Создание логических подразделов контента.
За исключением случаев использования именованных семейств сайтов, каждое веб-приложение должно иметь одно семейство сайтов корневого уровня. Таким образом обеспечивается единый URL-путь к сайтам, относящимся к веб-приложению. Это также требуется при внедрении нескольких зон в рамках веб-приложения.
Многие организации планируют внедрение нескольких семейств сайтов в рамках веб-приложения для использования разными рабочими группами или подразделениями организации. Обычно к целям разработки относится следующее:
Обеспечение отдельного независимого семейства сайтов для каждой рабочей группы.
Создание уникального URL-адреса для каждой рабочей группы.
Чтобы достичь этих целей, можно использовать управляемые пути для включения нескольких сайтов высшего уровня в рамках веб-приложения. Определяя управляемые пути, можно указать пути для семейств сайтов в пространстве URL-имен веб-приложения. Также можно указать уникальный путь под корневым сайтом, в котором существуют одно или несколько семейств сайтов. Без использования управляемых путей все сайты, созданные ниже корневого семейства сайтов, становятся частью корневого семейства.
Можно создать два следующих типа управляемых путей:
Явное включение Семейство сайтов с явно заданным URL-адресом. Явное включение применяется только к одному семейству сайтов. Можно связать каждое семейство сайтов с собственной базой данных контента, если необходимо управлять развитием и предоставить возможность резервного копирования и восстановления отдельно этих сайтов. Пример URL-адреса семейства сайтов, созданного с использованием данного метода, — http://fabrikam/hr. Ограничение на количество семейств сайтов, созданных с использованием явного включения, составляет примерно 100 семейств сайтов. Если организации требуется большее число семейств сайтов, используйте включение по шаблону.
Включение по шаблону Путь, который добавляется к URL-адресу. Этот путь обозначает, что все сайты, указанные сразу после имени сайта, являются уникальными семействами сайтов. Этот вариант обычно используется для поддержки управления средствами самостоятельного создания сайтов, например, сайтов или личных сайтов, созданных для совместной работы с партнерами. Примеры URL-адреса семейства сайтов, созданного с использованием данного метода, — http://partnerweb//sites/project1 и http://partnerweb//sites/project2. В данных примерах "http://partnerweb/" указывает на семейство сайтов корневого уровня, а "/sites" отражает включение по шаблону.
Дополнительную информацию о разработке URL-адресов и использовании управляемых путей см. в разделе "Зоны и URL-адреса" следующей статьи по планированию : Модель логической архитектуры: корпоративное развертывание.
Сайты
Сайт — это одна или несколько связанных веб-страниц, размещенных в семействе сайтов.
Емкость
Для обеспечения приемлемой производительности рекомендуется использовать не более 250 000 сайтов на каждое семейство сайтов. Используя дочерние сайты, можно создать очень большое суммарное количество веб-сайтов. Например, 100 сайтов, каждый из которых содержит 1000 дочерних сайтов, — в общей сложности 100 000 сайтов. Рекомендуется создавать не более 125 сайтов, каждый из которых содержит 2 000 дочерних сайтов, что составляет суммарно 250 000 сайтов.
Общий доступ и изоляция
Сайты содержат встроенную навигацию от одного дочернего сайта к другому в рамках семейства сайтов. Встроенная навигация от одного семейства сайтов к другому отсутствует.
Как и семейства сайтов, отдельные сайты уязвимы к атакам межсайтовых сценариев из других сайтов домена.
Настраиваемые элементы
Из каждого сайта можно добавить учетную запись пользователя или группы в группу владельцев данного сайта.
Администрирование
Можно использовать Microsoft Office SharePoint Designer 2007 для резервного копирования и восстановления отдельных сайтов. Дополнительные сведения об администрировании сайта см. следующие статьи:
Резервное копирование, восстановление и перемещение сайта SharePoint (https://go.microsoft.com/fwlink/?linkid=85710&clcid=0x419)
Планирование создания и обслуживания сайтов (Office SharePoint Server)
Рекомендации по планированию
Информацию о планировании сайтов см. в следующих статьях:
Именованные семейства сайтов
Именованные семейства сайтов целесообразно использовать, если необходимо создать множество семейств сайтов корневого уровня в рамках веб-приложения. Например, администраторы организации, размещающей сайт, используют именованные семейства сайтов для создания группы сайтов с именем домена.
Не существует специального режима, например, режима заголовка сайта, необходимого для создания именованных семейств сайтов. Создавать именованные семейства сайтов можно с помощью инструмента командной строки Stsadm.
Именованные семейства сайтов обеспечивают больший контроль над URL-адресами. Однако присутствуют и определенные недостатки, к которым можно отнести следующее:
Именованные семейства сайтов доступны только в зоне по умолчанию. Учетные записи пользователей, которые настроены на проверку подлинности в других зонах, не могут получить доступ к именованным семействам сайтов.
Функция альтернативного сопоставления доступа не работает с именованными семействами сайтов. Функция альтернативного сопоставления доступа обеспечивает поддержку внешнего завершения SSL-соединений, что позволяет сценариям доступа удаленных сотрудников и партнеров использовать протокол SSL (HTTPS).
Емкость
Можно создать до 100 000 именованных семейств сайтов в рамках одного веб-сайта IIS Web.
Общий доступ и изоляция
Независимые доменные имена, к которым приводят именованные семейства сайтов, способствуют предотвращению атак межсайтовых сценариев.
Администрирование
Администрирование именованных семейств сайтов подразумевает следующие задачи:
Добавление именованных семейств сайтов с помощью инструмента командной строки Stsadm.
Каждому именованному семейству сайтов требуется отдельная DNS-запись.
Рекомендации по планированию
Дополнительные сведения о создании именованных семейств сайтов с помощью инструмента командной строки Stsadm и использовании именованных семейств сайтов в среде размещения см. в статье White paper: Create shared hosting solutions on Windows SharePoint Services.
"Мои узлы"
В Office SharePoint Server 2007 личные сайты — это специальные сайты SharePoint, персонализированные для каждого пользователя. Создание личных сайтов включено по умолчанию, у каждого пользователя организации есть свой сайт. Информацию о мощности, общем доступе, изоляции и администрировании см. в разделе "Сайты", ранее в этой статье.
Информацию о планировании личных сайтов см. в следующих ресурсах:
Загрузка этой книги
Для упрощения чтения и печати эта тема включена в следующую загружаемую книгу:
См. полный список доступных книг на веб-сайте Загружаемые книги для Office SharePoint Server 2007.