Построение логической архитектуры сайтов для совместной работы

Содержание:

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

• Рекомендации по конструированию сайтов группы

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

• Планирование общих параметров веб-приложения

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

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

• Автоматическое удаление неиспользуемых сайтов

• Использование путей для организации URL-адресов сайтов группы

• Планирование пользовательских элементов

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

В Microsoft Office SharePoint Portal Server 2003 функциональные возможности сайтов группы по сравнению с сайтами портала были ограниченными. В Microsoft Office SharePoint Server 2007 все иначе. В Office SharePoint Server 2007 сайты совместной работы в среде интрасети имеют те же функции, что и опубликованный сайт портала в интрасети, если эти функции доступны в среде интрасети. В рамках данной статьи такие сайты будут обозначаться их прежним названием — "сайты группы". При этом следует помнить, что функциональные возможности, которыми эти сайты обладали в предыдущей версии, не настолько ограничены. Скорее понятие "сайты группы" говорит о том, что они используются небольшими группами или для более расширенной совместной работы, чем отличаются от опубликованного и контролируемого сайта портала в интрасети.

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

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

Сведения об сайтах группы в среде интрасети

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

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

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

• Планирование бизнес-аналитики

• Планирование служб InfoPath Forms Services

Рекомендации по конструированию сайтов группы

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

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

• Оптимизация производительности в масштабе фермы серверов.

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

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

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

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

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

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

• Автоматическое удаление неиспользуемых сайтов

• Использование путей для организации URL-адресов сайтов группы

• Планирование соответствующих политик и разрешений.

Размещение сайтов группы в выделенном веб-приложении

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

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

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

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

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

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

• Разделение проверенного и анонимного содержимого.

• Изолирование пользователей.

• Обеспечение разрешений.

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

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

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

Вопросы производительности

При размещении сайтов группы в выделенном веб-приложении доступно несколько баз данных контента, в которых находятся только семейства сайтов группы. Если в базах данных контента разместить сайты с одинаковыми признаками данных, программное обеспечение баз данных Microsoft SQL Server будет работать эффективнее, поскольку SQL Server выбирает план запросов на основе характеристик базы данных. И наоборот, если в базе данных разметить сайты с абсолютно разными признаками данных, план запросов, используемый SQL Server, может оказаться не самым эффективным для всего содержимого в базе данных. Например, если в базе данных размещены сайты группы (то есть, много сайтов среднего размера) и сайты портала (то есть, немного сайтов очень большого размера с большим числом запросов), то выбранный план запросов будет неэффективным для одного из типов сайтов. Таким образом, размещение содержимого сайтов группы в выделенных базах данных позволит оптимизировать производительность SQL Server, что положительно скажется на производительности всей фермы серверов.

Вопросы управляемости

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

• Возможность раздельного управления следующими элементами:

  • Параметры базы данных

  • Шаблоны квот

  • Параметры корзины

  • Автоматизированные действия для неиспользуемых сайтов

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

  • Политики

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

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

Выбор пула приложений

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

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

• Разделение проверенного и анонимного содержимого.

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

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

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

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

Планирование общих параметров веб-приложения

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

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

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

• Включение корзин сайта и использование сайта второго уровня.

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

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

• Предупреждения (по умолчанию пользователи могут создать до 500 предупреждений)

• RSS-каналы

• Программный интерфейс (API) блога (ссылка на создание блога)

Определение параметров шаблона квот

В среде Office SharePoint Server 2007 нет шаблона квот по умолчанию для сайтов шаблона. При этом на начальном этапе рекомендуется выполнить следующие настройки:

• Автоматическая отправка сообщения электронной почты владельцу сайта при достижении размера сайта 450 мегабайт (МБ).

• Запрет на отправку дополнительных документов пользователями при достижении размера сайта 500 МБ.

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

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

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

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

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

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

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

Определение параметров корзины

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

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

• Состояние корзины: Вкл

• Удалять элементы в корзине: после 30 дней

• Корзина второго уровня: Добавить 50 процентов текущей квоты для удаленных элементов второго уровня

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

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

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

Планирование метода создания

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

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

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

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

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

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

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

Примеры случаев использования этого метода см. в разделе Модель логической архитектуры: корпоративное развертывание. Дополнительные сведения о планировании создания сайтов см. в разделе Планирование процедуры создания сайтов (Office SharePoint Server).

Если в организации принято решение создать семейства сайтов для сайтов группы и не позволять пользователям создавать их самостоятельно, рекомендуется использовать таблицу Пути сайта (на английском языке) (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x419) (на английском языке) для определения уровня, на котором будут созданы сайты группы: сайты верхнего уровня в своих семействах сайтов или одно большое семейство сайтов с несколькими дочерними сайтами. Дополнительные сведения о принятии решения о числе создаваемых семейств сайтов и количестве дочерних сайтов в них см. в разделе "Принятие решения об использовании отдельных семейств сайтов или дочерних сайтов в одном семействе сайтов" Determine sites and subsites needed [Windows SharePoint Services] в технической библиотеке Windows SharePoint Services 3.0. Дополнительные сведения о типах доступных сайтов в Office SharePoint Server 2007 см. в разделе Определение основных и дочерних сайтов.

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

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

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

Таким образом, если планируется более 300 семейств сайтов группы, выделенные базы данных использовать не следует. Вместо этого несколько семейств сайтов необходимо хранить в одной базе данных. Следует упомянуть, что 300 это именно то число баз данных, которое используется ИТ-отделом Microsoft. При этом 300 баз данных не означает точку отказа, а лишь является оценкой на основе данных SharePoint Portal Server 2003; именно это число баз данных позволило сделать заключение в ИТ-отделе Microsoft о количестве сайтов, которые можно безопасно разместить на каждом сервере. Для каждого случая это число будет разным в зависимости от количества параметров и количества баз данных. Например, решение об использовании выделенных баз данных может также зависеть от следующих факторов:

• Используются ли в группах разных соглашения об уровнях обслуживания (например, разные требования к резервному копированию)?

• Требуется ли группам более 8 ГБ пространства для хранения?

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

• Будут ли группы достаточно автономными и независимыми в операциях, выполняемых на уровне базы данных?

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

Если принято решение о хранении нескольких семейств сайтов в каждой базе данных, то рассчитать их количество можно определив максимальный размер каждого семейства сайтов (исходя из предельного значения шаблона квоты плюс выделенный размер корзины). Следует помнить, что даже в случае выделения квоты равной 500 МБ для каждого семейства не обязательно, что все семейства израсходуют эту квоту, поэтому число создаваемых баз данных может оказаться слишком большим. При планировании баз данных необходимо опираться на оценку квот, но фактическое использование следует контролировать и адаптироваться соответствующим образом. Если ранее существовала среда с SharePoint Portal Server 2003 или Windows SharePoint Services 2.0, можно оценить размер семейств сайтов в ней и создавать базы данных на основе фактических размеров семейств сайтов, а не на оценках квот.

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

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

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

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

Учитывая два значения размера содержимого (B и D), максимальный контролируемый размер база данных для организации является меньшим из двух значений.

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

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

Автоматическое удаление неиспользуемых сайтов

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

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

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

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

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

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

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

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

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

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

Использование путей или имен сайтов для организации URL-адресов сайта группы

В зависимости от организации и режима использования сайтов группы следует подумать об использовании путей для организации URL-адресов для сайтов группы. Например, если для сайтов группы, связанных с различными версиями, требуются разные URL-адреса, можно использовать URL-адреса вида http://компания/отдел/sites или http://компания/research/sites. Подобным образом, можно добиться четкой ассоциации с опубликованным сайтом интрасети, использовав адрес http://интрасеть/teamsites. При использовании управления средствами самостоятельного создания сайтов URL-адрес по умолчанию для сайтов группы будет http://имя_сервера/sites, но также можно создать включение по шаблону для адреса http://имя_сервера/team или любой префикс, необходимый для сайтов группы.

Дополнительные сведения о путях см. в следующих материалах:

• Планирование сайтов совместной работы

• Определение основных и дочерних сайтов

• "Использование явных включений и включений по шаблону для путей URL" в Модель логической архитектуры: корпоративное развертывание

• Технический документ. Создание общих решений размещения на основе Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=86128&clcid=0x419)

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

Планирование пользовательских элементов

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

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

• Возможность поддержки   Наличие пользовательских элементов в среде может требовать дополнительного времени на устранение неполадок в случае ошибок. Каждый пользовательский фрагмент кода является уникальным и может быть как простым, так и сложным, и потреблять дополнительную память во время выполнения. Следует запомнить места использования пользовательского кода и проследить за тем, как он влияет на систему. Кроме того, следует выработать способы исключения пользовательских элементов из причины проблемы при поиске неисправностей. При создании пользовательского кода самостоятельно его необходимо строить таким образом, чтобы любые ошибки в пользовательских элементах записывались как в журнал событий — для событий Microsoft Operations Manager (MOM), так и в любое другое расположение, используемое в организации при поиске неисправностей, так чтобы ошибки можно было диагностировать.

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

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

Планирование разрешений для применения к сайтам группы

Разрешения и политики, применяемые к сайтам группы, определяют:

• Пользователей, которые могут создавать сайты группы.

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

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

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

Загрузите эту книгу

Этот раздел включен в следующую загружаемую книгу для удобства чтения и печати:

• Планирование и архитектура для Office SharePoint Server 2007, Часть 2

Полный список доступных книг приведен в разделе Загружаемые материалы для Office SharePoint Server 2007 .