10 ошибок в настройке Microsoft SharePoint 2010

Тодд Клиндт (todd@sharepoint911.com) – консультант по SharePoint, имеет звание SharePoint MVP

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

Ошибка № 1: экономия на оперативной памяти или объеме жесткого диска для SharePoint

Я много раз наблюдал безотрадную картину: бедный беззащитный сервер SharePoint работает на пределе своих возможностей, чтобы осчастливить пользователей, но он связан по рукам и ногам из-за ограниченных ресурсов. Такая ситуация является обычной при «агрессивной» виртуализации. Сама по себе виртуализация — вещь неплохая, но она должна быть организована умно и без жертв со стороны SharePoint.

Если SharePoint не хватает оперативной памяти, это ограничивает его функционирование, чтобы мог втиснуться в доступный объем. SharePoint также получает меньше в пулах веб-приложений и перезаписывает эти пулы чаще. Уменьшение кэширования и увеличение повторных циклов записи снижает производительность SharePoint и замедляет работу конечных пользователей, поскольку SharePoint должен компилировать тот же самый код ASP.NET снова и снова. А несчастные пользователи не нужны никому.

Решение в данном случае простое: добавьте оперативной памяти. Специалисты Microsoft опубликовали требования для SharePoint 2010 на сайте technet.microsoft.com/en-us/library/cc262485.aspx. Эти требования подразумевают, что как минимум каждый производственный сервер SharePoint 2010 должен иметь 8 Гбайт оперативной памяти, а диск С должен быть объемом как минимум 80 Гбайт. Но во многих случаях этого недостаточно. Для производственных серверов вы можете проверить загрузку памяти и понять, задействуют ли они все 8 Гбайт оперативной памяти полностью. Если да, то они могли бы расходовать и больше. Если ваши серверы еще не в рабочем режиме, вы можете задействовать разнообразные тестовые нагрузочные утилиты для симуляции загрузки, которую желали бы создать, и посмотреть, как серверы себя ведут. Например, вы можете загрузить Microsoft Load Testing Kit, который является частью SharePoint Administration Toolkit, по адресу www.microsoft.com/download/en/details.aspx?id=20022.

Что касается диска С, то сам по себе SharePoint не требует его большого объема, в отличие от Windows. В конце концов, вашему серверу нужно хранить исправления для Windows за несколько лет. Если вы увеличиваете объем диска на своем сервере, подумайте над тем, чтобы добавить еще и второй диск. Этот диск будет подходящим местом для хранения всех файлов, которые вы используете при установке SharePoint. Все установочные файлы программ сторонних фирм тоже могут храниться там. На этот диск вы можете поместить и файлы журналов SharePoint, и индексы Search. Такой подход снимет с диска С некоторое напряжение. А быстрый диск С и довольные конечные пользователи осчастливят и администратора сервера SharePoint.

Ошибка № 2: использование виртуализованного сервера Microsoft SQL

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

Очевидное решение — переместить SQL Server на физическую систему, где ему не нужно будет делиться ресурсами. Перемещение SQL Server подальше от SharePoint – это несложный процесс, который описан на сайте www.toddklindt.com/sqlalias.

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

Брент Озар подготовил видеоролик о том, как лучше всего виртуализировать SQL Server; он опубликован на сайте technet.microsoft.com/en-us/sqlserver/gg429826.aspx.

Ошибка № 3: использование мастера настройки фермы

Применение мастера настройки фермы Farm Configuration Wizard было очень распространенной ошибкой, когда только вышел SharePoint 2010. Список недоработок мастера настройки велик, поэтому я расскажу только о наиболее известных. Прежде всего, базы данных, которые создает мастер настройки, имеют глобальные уникальные идентификаторы GUID в конце имен. Мастер настройки также создает веб-приложение с адресом http://servername, которое не очень хорошо масштабируется. Чтобы добавить неразберихи, мастер настройки создает сайт My Site в том же самом веб-приложении с адресом http://servername/my. Наконец, мастер настройки подталкивает вас к созданию служебных приложений, которые вы на самом деле использовать не будете. Трудно противиться желанию поставить флажки у параметра, если есть возможность, я знаю.

Мастер настройки фермы Farm Configuration оставляет свои «грязные отпечатки» по всему SharePoint, и может быть проблематично «отмыть» их все. Однако некоторые места поправить можно. Начните со своих веб-приложений. Создайте веб-приложение для My Site и дайте ему полное доменное имя Fully Qualified Domain Name (FQDN), такое как mysites.company.com. Создайте хост My Site в корневой папке веб-приложения. Используйте команду Windows PowerShell, которая называется Move-SPSite, для перемещения My Site в одну базу данных контента, а затем присоедините эту базу данных контента к своему новому веб-приложению. Кроме того, вам потребуется выполнить настройку службы User Profile Service и оповестить ее о новом местоположении My Site.

Затем подчистите свои служебные приложения. Пройдитесь по списку служебных приложений и удалите все, которые не используете. После удаления ненужных служебных приложений остановите связанные экземпляры служб (services on server – службы на сервере), которые управляют ими. Если возможно, удалите разные GUID из имен баз данных служебных приложений. Методы выполнения этих задач меняются в зависимости от служебного приложения; в статье Microsoft «Rename or Move Service Application Databases (SharePoint Server 2010)» (technet.microsoft.com/en-us/library/ff851878.aspx) приводятся инструкции для всех служебных приложений. И, конечно, сделайте полную копию, прежде чем что-то удалять.

Ошибка № 4: использование неправильного URL при создании веб-приложения контента

Как и у всех партнеры, между SharePoint и Microsoft IIS время от времени возникают проблемы с коммуникацией. Создание веб-приложения – один из этих случаев. SharePoint не оповещает IIS об изменениях, которые вы можете внести в веб-приложение после его создания. Например, если вы создаете альтернативный путь Alternate Access Mapping (AAM) для веб-приложения в Central Administration, вы все еще должны зайти в IIS и добавить заголовок хоста для нового адреса.

Проблема усложняется, если к фермам SharePoint, о которых вы никогда не думали, что к ним будет доступ извне, требуется доступ из Интернета. Администраторы SharePoint обычно выдают своим веб-приложениям короткие адреса URL, такие как http://portal, чтобы сократить число набираемых символов. Конечно, этот URL не маршрутизируется по Интернету, поэтому веб-приложение требует полного доменного URL, добавленного к статичным AAM. Этот новый URL не только не прописан в заголовках хоста IIS, но он отсутствует и во всех предупреждениях, рабочих процессах и других элементах, которые хранят URL. Все эти элементы обладают старым жестко кодированным URL. Поскольку SharePoint не прописывал никаких дополнительных URL в IIS, когда они создавались, он и не будет выписывать их никаким новым серверам SharePoint, которые добавляются к ферме. SharePoint не станет прописывать эти изменения в IIS и тогда, когда экземпляр службы Microsoft SharePoint Foundation веб-приложения lication будет остановлен и перезапущен.

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

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

Первый шаг – это документирование всех ваших настроек веб-приложения. В большинстве случаев их немного и вы понимаете все изменения, которые произвели. Затем отсоедините базу данных контента от своего веб-приложения. Сохраните базы данных, они вам могут понадобиться. Затем сделайте копию файла web.config для этого веб-приложения. Некоторые настройки, такие как аутентификация на основе форм Form Based Authentication (FBA) и настройки кэша BLOB, находятся в этом файле. Наконец, зайдите в Central Administration и удалите веб-приложение. SharePoint придется удалить лишние материалы. Самая опасная часть работы завершена.

Теперь создайте веб-приложение заново, но на этот раз сделайте это правильно. Сначала введите корректный, полностью определенный адрес URL в поле Host Header. Доставьте удовольствие своим конечным пользователям и установите веб-приложение на порт 80, как показано на экране 1. В разделе настроек безопасности Security Configuration примите все по умолчанию, даже если вы собираетесь использовать Kerberos или SSL. Позднее вы можете изменить эти настройки, а вам нужно убедиться, что веб-приложение работает корректно, прежде чем вы примените желаемые настройки безопасности. В разделе настроек Application Pool отметьте существующий пул приложения (зачем это нужно, я объясню в следующем разделе).

Экран 1. Создание нового веб-приложения

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

После того как веб-приложение создано, вы можете скорректировать настройки так, как вам нужно. Большая часть настроек может быть изменена в разделе Central Administration. Если вы выполнили какие-либо изменения в файле web.config в исходном веб-приложении, то теперь самое время скопировать эти изменения в заново созданный файл web.config. Вы можете использовать такую программу как Notepad++ (notepad-plus-plus.org) для сравнения этих двух файлов. В итоге вы получите хорошо написанное веб-приложение, на которое можно будет положиться в случае сбоя.

Ошибка № 5: запуск веб-приложений или служебных приложений в раздельных пулах приложений

Веб-приложения и служебные приложения запускаются внутри пула приложения, который является процессом W3WP.exe, запущенным на сервере. Пока у вас нет причины поступать иначе, следует запустить все веб-приложения SharePoint внутри одного пула приложений. То же самое касается и служебных приложений. Запуск каждого веб-приложения в своем пуле приложения делает неэффективным использование памяти сервера. Каждый пул приложений имеет минимальный прирост более чем в 100 Мбайт, и его доля в памяти может быть увеличена по мере кэширования часто обновляемого контента. На экране 2 показано несколько процессов W3WP.exe, запущенных как sp_webapps; это результат запуска веб-приложений в раздельных пулах приложений.

Экран 2. Результат запуска веб-приложений в раздельных пулах приложений

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

Что касается служебных приложений, то эту проблему легко решить. Прежде всего, убедитесь, что у вас хороший служебный пул приложений, который можно использовать. Я рекомендую назвать его пул Default SharePoint Service App Pool, чтобы он оказался в верхней строчке всех ваших списков. Используйте специальную учетную запись sp_serviceapps (обратитесь на сайт учетных записей www.toddklindt.com/service) для идентификации пула. Большинство служебных приложений позволяют переводить их в новый пул служебных приложений путем изменения их свойств в Central Administration. Если эта возможность недоступна там, поищите ее в PowerShell.

Веб-приложения — более сложный случай. Непросто изменить пул приложения, который использует веб-приложение. К счастью, в нашем распоряжении есть PowerShell. Описание этого процесса не соответствует теме данной статьи, но я детально рассказываю о нем на сайте: www.toddklindt.com/changeapppool.

Ошибка № 6: использование одной учетной записи для всего

Система безопасности сложна, и совсем не факт, что SharePoint делает ее проще. Использование только одной учетной записи – может быть даже всемогущей записи Domain Administrator – это так просто. Мы все так делаем, хотя это и неправильно. Когда вы используете существующую учетную запись, вы открываете в SharePoint несколько лазеек в системе безопасности. Любой, кто знает пароль учетной записи, может сделать с SharePoint все что угодно, ведь вы не сможете разделить обязанности. Кроме того, вы можете потерять возможность контролировать тех, кто внес изменения. И если этот общеизвестный пароль скомпрометирован или нуждается в том, чтобы его изменили, вы нарушите работу SharePoint. Даже если вы используете один специальный пароль для SharePoint, вы остаетесь уязвимы для атак. Если учетная запись будет скомпрометирована через брешь в защите, то хакеры получат доступ ко всему в SharePoint.

Чтобы исправить эту ошибку, начните с создания учетных записей, о которых я рассказал в своем блоге на сайте www.toddklindt.com/serviceaccounts. Добавьте учетные записи sp_webapps и sp_serviceapps в качестве управляемых учетных записей. Используйте технологии, о которых шла речь в разделе «Ошибка №5», для исправления учетных записей вашего веб-приложения и служебного приложения. Вы также можете изменить доступ к учетной записи, который предоставляется по умолчанию, для служебного приложения Search на странице Search Service Application. В разделах Central Administration, Security, Configure Service Accounts вы можете изменить учетные записи, которые используют другие процессы. Вы даже можете изменить Farm Account здесь. Я делал именно так в тестовых средах, но не осмелился повторить это в рабочей среде. Если вы используете User Profile Service, убедитесь, что ваша учетная запись sp_userprofile имеет корректные разрешения в Active Directory, и заново создайте соединение с Active Directory в User Profile Service.

Вы также можете выполнить действия, которые я описал на сайте www.toddklindt.com/sp_farm, чтобы предоставить учетной записи правильные разрешения для администрирования SharePoint без потребности в использовании другой привилегированной учетной записи.

Ошибка № 7: сохранение настроек базы данных SharePoint по умолчанию

Когда SharePoint создает свое семейство баз данных, он делает несколько неудачных допущений. Например, настройки автоматического увеличения: файлы базы данных увелчиваются по 1 Мбайт, чтобы гарантировать, что они будут автоматически реагировать на малейшее повышение нагрузки. Это не только замедляет SQL Server (который замедляет SharePoint), но и отражается на файлах базы данных, которые распределяются по всем дискам очень маленькими фрагментами памяти в 1 Мбайт.

SharePoint также создает большую часть своих баз данных, особенно базы данных Config и Content, с моделью восстановления, настроенной на Full. Это великолепно, но если вы хотите восстановить данные, вы должны правильно управлять процессом или коварные файлы.ldf будут медленно и методично заполнять жесткий диск. Если вы думаете, что пользователи расстроятся, когда увидят, что SharePoint тормозит из-за фрагментированных баз данных, вообразите, что они испытают, когда SharePoint полностью встанет из-за полного заполнения дисков SQL Server.

Чтобы исправить эту ошибку, установите настройки автоматического роста своей базы данных так, чтобы ее не нужно было наращивать часто. Для большинства ферм я рекомендую изменить автоматический рост по 1 Мбайт до 500 Мбайт или 1 Гбайт. Автоматический рост должен быть последним средством. Кто-то, администратор SharePoint или отдельный DBA, должен заранее нарастить базы данных так, чтобы автоматический рост был ненужным.

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

Ошибка № 8: блокировка кэширования BLOB

Не знаю как вы, но я никогда не слышал, чтобы пользователи говорили: «SharePoint слишком быстрый. Не могли бы вы сделать так, чтобы он отвечал немного медленнее?» Мы все хотим, чтобы SharePoint доставлял пользователям файлы так быстро, как только это возможно. Однако чаще всего я вижу фермы SharePoint с неактивированным кэшированием BLOB. кэширование BLOB является одним из самых простых и наименее дорогих способов повысить производительность SharePoint. Это не только помогает быстрее доставлять пользователям файлы, но и облегчает эксплуатацию SQL Server. Все выигрывают.

Это кажется самым простым решением: тогда давайте же включим кэширования BLOB! Кэширование BLOB на самом деле является функцией IIS; SharePoint просто извлекает выгоду от этого. Таким образом, чтобы активировать кэширование BLOB, нужно изменить файл web.config веб-приложения на каждом сервере. Такая настройка уже существует, ее нужно просто активировать. По умолчанию файлы web.config находятся в каталоге диска С: \inetpub\wwwroot\wss\virtualdirectories. Каждое веб-приложение имеет подкаталог и файл web.config. Откройте один из этих файлов и поищите такую строчку:

Чтобы активировать кэширование BLOB, замените False на True и сохраните файл web.config. Кроме того, вы можете переместить файл в каталоге на диске С на любой другой диск. Параметр maxSize указывает значение в гигабайтах, а по умолчанию имеется 10 Гбайт. Если позволяет пространство, вы можете увеличить этот размер.

Если редактирование этого файла в Notepad на всех ваших серверах не доставляет вам удовольствия, вы можете использовать PowerShell для автоматизации процесса. Вам еще нужно выполнить процесс на каждом сервере, но использование PowerShell быстрее и снижает вероятность ошибки. Для начала загрузите сценарий с сайта www.toddklindt.com/blobcache и сохраните его в файле, названном blobcache.ps1. Этот сценарий содержит две функции: Enable-SPBlobCache и Disable-SPBlobCache. Каждая функция берет веб-приложение из конвейера и активирует или блокирует BLOB-кэширование для этого приложения. Код для активации BLOB-кэширования на каждом веб–приложении в ферме выглядит так:

PS e:\install\Scripts>. .\blobcache.ps1
PS e:\install\Scripts>
get-SPWebapplication |
enable-SPBlobCache

Ошибка № 9: не установлен PDF iFilter

Большинство организаций имеет огромное количество файлов PDF на фермах SharePoint. Конечные пользователи хотят иметь возможность исследовать хранящуюся на них информацию, используя SharePoint Search. Установка PDF iFilter очень проста. У Adobe есть бесплатный PDF iFilter, который вы можете инсталлировать. Ссылку на порядок загрузки и подробную информацию можно найти на сайте support.microsoft.com/kb/2293357. Вам нужно установить iFilter только на тех серверах, которые играют роль Search Index, хотя установка на оставшихся серверах SharePoint тоже не повредит. Если у вас большая ферма и вы хотите сократить время индексирования файлов PDF, вы можете использовать PDF iFilter от Foxit (www.foxitsoftware.com). У этого продукта более высокая производительность, чем у Adobe iFilter, но он платный.

И снова вы можете использовать PowerShell, чтобы облегчить задачу. Брайан Лалансетте, создатель AutoSPInstaller (autospinstaller.codeplex.com), написал превосходный сценарий, который автоматически загружает, устанавливает и задает настройки PDF iFilter. Данный сценарий является частью пакета, поэтому я выделил подходящие части и привел их на сайте www.toddklindt.com/PDFSearch. Сохраните этот файл как pdfsearch.ps1. Он содержит две функции: Configure-PDFSearch и Configure-PDFIcon. Первая устанавливает и задает настройки iFilter, а вторая добавляет значок PDF в интерфейс SharePoint. Как и в описании сценария в разделе «Ошибка № 8», установите функции с помощью файла pdfsearch.ps1, а затем выполните их.

Ошибка № 10: серверы SharePoint не направлены на самих себя

Я убедился, что каждый сервер в ферме SharePoint указывает сам на себя для всех веб-приложений. Если я получаю эпизодические отчеты о том, что SharePoint не отвечает, я с легкостью могу использовать RDP для регистрации на каждом сервере и попытаться исправить SharePoint. Если это срабатывает, я знаю, что сервер работает. Если SharePoint не поддается коррекции, я знаю точно, в каком журнале Microsoft User Location Server (ULS) мне следует искать ошибку. Мне не нужно думать о том, в какой внешний веб–сервер балансировщик нагрузки послал мой запрос. Чем быстрее вы доберетесь до правильных файлов журналов, тем скорее проблема будет решена.

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

Есть простой способ исправить эту ошибку: откройте файл hosts (C:\windows\system32\drivers\etc\hosts) на каждой системе SharePoint, затем добавьте все URL, о которых знает SharePoint. Направьте эти URL на адрес 127.0.0.1, который означает «этот компьютер». На экране 3 показано, как этот файл выглядит в типичной среде SharePoint. Об этом подходе подробно рассказано на сайте www.toddklindt.com/loopback.

Экран 3. Файл hosts в обычной среде SharePoint

Как вы, вероятно, заметили, я в восторге от использования РowerShell для исправления всех этих ошибок, и ошибка № 10 — не исключение. Сценарий, опубликованный на сайте www.toddklindt.com/edithosts, будет автоматически добавлять все URL SharePoint к вашим локальным файлам hosts на сервере и исправлять замыкания. Есть ли что-то, что РowerShell не под силу?

На ошибках учатся

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