Планирование емкости для SharePoint Server 2010

Статья
03/05/2017

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

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

Прежде чем приступать к чтению этой статьи, вы должны прочитать статью Обзор управления емкостью и изменения размера для SharePoint Server 2010.

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

Содержание:

Шаг 1. Модель
Шаг 2. Макет
Шаг 3. Пилотный проект, тестирование и оптимизация
Шаг 4. Развертывание
Шаг 5. Наблюдение и поддержка

Шаг 1. Модель

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

Определение предполагаемой рабочей нагрузки и набора данных

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

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

Рабочая нагрузка

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

Характеристики рабочей нагрузки	Значение
Среднее число запросов в секунду при обычной нагрузке
Среднее число запросов в секунду при пиковой нагрузке
Общее число уникальных пользователей в день
Среднее число параллельных пользователей при обычной нагрузке
Максимальное число параллельных пользователей при пиковой нагрузке
Общее число запросов в день
Ожидаемое распределение рабочей нагрузки	Число запросов в день
Веб-браузер — обход службы поиска
Веб-браузер — общее взаимодействие при совместной работе
Веб-браузер — социальное взаимодействие
Веб-браузер — общее взаимодействие
Веб-браузер — Office Web Apps
Клиенты Office
Клиент OneNote
SharePoint Workspace
Синхронизация Outlook RSS
Outlook Social Connector
Другие взаимодействия (пользовательские приложения или веб-службы)

Параллельные пользователи: этот показатель чаще всего используется для измерения способности одновременного выполнения операций в ферме серверов и представляет число отдельных пользователей, создающих запросы в определенный интервал времени. Основные метрики: среднее число в день и число параллельных пользователей во время пиковой нагрузки.
Запросов в секунду (RPS): этот показатель числа запросов в секунду чаще всего используется для описания спроса на ферму серверов, выраженного в количестве запросов, обработанных фермой за секунду, без разделения запросов по типам и размерам. Каждая база пользователей организации создает системную нагрузку со скоростью, зависящей от уникальных характеристик использования в организации. Дополнительные сведения об этом понятии см. в разделе Глоссарий в статье Обзор управления емкостью и изменения размера для SharePoint Server 2010.
Общее число запросов в день: хороший показатель общей нагрузки, которую должна обрабатывать система. Обычно учитываются все запросы за 24 часа, кроме запросов подтверждения проверки подлинности (состояние HTTP 401).
Общее число пользователей в день: еще один ключевой показатель общей нагрузки, которую должна обрабатывать система. Эта величина представляет фактическое число уникальных пользователей за 24 часа, а не общее число сотрудников в организации.

Примечание

Общее число пользователей в день может указывать на потенциал роста нагрузки в ферме. Например, если число потенциальных пользователей равно 100 тысячам сотрудников, 15 тысяч пользователей в день показывают, что со временем нагрузка может значительно возрасти по мере увеличения вовлеченности пользователей.
Распределение рабочей нагрузки: информация о распределении запросов в зависимости от клиентских приложений, взаимодействующих с фермой, помогает прогнозировать тенденции и ожидаемые изменения нагрузки после перехода на SharePoint Server 2010. При переходе пользователей на более новые версии клиентов, например Office 2010, и использовании новых возможностей ожидается увеличение числа новых шаблонов нагрузки, запросов в секунду и общего числа запросов. Для каждого клиента можно описать число отдельных пользователей, использующих его в течение дня, и общее число запросов, создаваемых клиентом или компонентом на сервере.

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

Типичное распределение дневной нагрузки по запросам

Оценка производственной рабочей нагрузки

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

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

Загрузка — схема рабочей нагрузки

Для оценки ожидаемой рабочей нагрузки соберите следующие сведения.

Определите операции взаимодействия пользователя, такие как просмотр веб-страниц, загрузка и отправка файлов, просмотр и изменение данных через Office Web Applications в браузере, совместное редактирование, синхронизация сайтов в SharePoint Workspace, взаимодействие в Outlook Social Connector, синхронизация RSS (в Outlook или других средствах просмотра), вещание в PowerPoint, общие записные книжки в OneNote, общие книги в службе Excel, общие приложения в службе Access и другие. Дополнительные сведения см. в разделе Службы и компоненты в статье Обзор управления емкостью и изменения размера для SharePoint Server 2010. В первую очередь определите взаимодействия, которые могут оказаться специфичными для вашего развертывания, и оцените влияние такой нагрузки; в качестве примера можно привести интенсивное использование форм InfoPath, вычислений службы Excel и аналогичных специализированных решений.
Определите системные операции, такие как добавочные обходы службы поиска, ежедневное резервное копирование, задания таймера синхронизации профилей, обработка данных Web Analytics и другие.
Оцените общее число пользователей в день, которые предположительно будут использовать каждую функциональную возможность, и получите ориентировочное число параллельных пользователей и запросов верхнего уровня в секунду; можно также сделать некоторые допущения, например относительно текущей параллельности и показателя числа запросов в секунду для параллельных пользователей, который отличается для разных функциональных возможностей; для оценки используйте таблицу рабочей нагрузки, приведенную ранее в этом разделе. Важно определить не столько среднюю производительность, сколько пиковую нагрузку. Планирование пиковой активности позволит надлежащим образом определить размеры решения на основе SharePoint Server 2010.

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

Анализ журналов IIS в SharePoint Server 2010

Чтобы найти основные метрики для существующего развертывания SharePoint Server 2010, такие как число активных пользователей, интенсивность использования системы этими пользователями, тип поступающих запросов и тип отправляющих запросы клиентов, необходимо извлечь данные из журналов ULS и IIS. Проще всего для получения этих данных использовать средство синтаксического анализа журналов — полнофункциональную утилиту, которую можно бесплатно загрузить с сайта Майкрософт. Средство синтаксического анализа журналов поддерживает чтение и запись в ряде текстовых и двоичных форматов, включая все форматы IIS.

Подробные сведения о том, как анализировать использование SharePoint Server 2010 с помощью средства синтаксического анализа журналов, см. в статье, посвященной анализу использования продуктов и технологий Microsoft SharePoint (Возможно, на английском языке) (https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en) (Возможно, на английском языке).

Средство синтаксического анализа журналов Log Parser 2.2 можно загрузить по адресу https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en (Возможно, на английском языке).

Набор данных

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

Объект	Значение
Размер базы данных (в ГБ)
Число баз данных контента
Число семейств веб-сайтов
Число веб-приложений
Число сайтов
Размер индекса поиска (число элементов)
Число документов
Число списков
Средний размер сайтов
Максимальный размер сайта
Число профилей пользователей

Размер контента: определение размеров контента, который предположительно будет храниться в системе SharePoint Server 2010, имеет большое значение для планирования и проектирования хранилища системы, а также для надлежащей оценки размеров поискового решения, которое будет выполнять обход и индексирование этого контента. Размер контента описывается в терминах общего объема дискового пространства. Если осуществляется перенос контента из существующего развертывания, возможно, проще определить общий размер переносимых данных; кроме того, при планировании следует оставить место для будущего роста на основании прогнозируемой тенденции.
Общее число документов: отличается от размера совокупности данных и имеет большое значение для отслеживания общего числа элементов. Реакции системы в ситуации, когда 100 ГБ данных состоят из 50 файлов по 2 ГБ каждый, будут отличаться от ситуации, когда имеется 100 000 файлов по 1 КБ каждый. В крупных развертываниях, чем меньше нагрузки приходится на отдельный элемент, документ или область документов, тем выше производительность. Распределенный контент, когда несколько файлов меньшего размера распределено по множеству сайтов и семейству сайтов, проще обслуживать, чем одну большую библиотеку документов с очень большими файлами.
Максимальный размер семейства веб-сайтов: важно определить наибольшую единицу контента, которая будет храниться в SharePoint Server 2010; как правило, невозможность разделения этой единицы контента определяется организационной необходимостью. Средний размер всех семейств веб-сайтов и предполагаемый общий размер семейств веб-сайтов — это дополнительные показатели, помогающие определить предпочтительную структуру данных.
Характеристики данных приложений-служб: помимо анализа требований к хранилищу для контента следует проанализировать и оценить размеры других хранилищ SharePoint Server 2010, в том числе:
Общий размер индекса поиска
Общий размер базы данных профилей на основе числа пользователей в хранилище профилей
Общий размер базы данных социального контента на основе предполагаемого числа тегов, коллег и операций
Размер хранилища метаданных
Размер базы данных использования
Размер базы данных Web Analytics

Дополнительные сведения о порядке оценки размеров баз данных см. в статье Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).

Задание целевых показателей производительности и надежности фермы

Одним из результатов, полученных в разделе Шаг 1. Модель, является хорошее понимание целевых показателей производительности и надежности, наилучшим образом соответствующих нуждам организации. Период работоспособности правильно спроектированного решения SharePoint Server должен выражаться "четырьмя девятками" (99,99 %) при скорости отклика сервера меньше секунды.

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

Доступность сервера: обычно выражается в процентах от общего времени работоспособности системы. Необходимо отслеживать любое неожиданное время простоя и сравнивать общую доступность с целевым показателем, заданным для организации. Целевые показатели обычно выражаются девятками (например, 99 %, 99,9 %, 99,99 %)
Скорость отклика сервера: время, которое требуется ферме для обслуживания запросов, является хорошим показателем для наблюдения за исправностью фермы. Этот показатель обычно называется задержкой на сервере и используется для применения среднего или срединного (50-я процентиль) времени ожидания при обслуживании ежедневных запросов. Целевые показатели обычно выражаются в долях секунды или секундах. Имейте в виду, что если в вашей организации имеется целевой показатель для обслуживания страниц из SharePoint Server 2010 менее чем за две секунды, то время отклика сервера должно включать доли секунды на то, чтобы страница дошла до клиента по сети, и время на воспроизведение в браузере. К тому же, большое время отклика сервера служит показателем неисправности фермы, поскольку обычно это влияет на производительность и практически невозможно поддерживать заданное число запросов в секунду, если сервер тратит больше секунды на большинство запросов.
Пиковость сервера: еще одним хорошим показателем для отслеживания задержки на сервере является режим обработки пяти процентов запросов, которые являются самыми медленными. Медленными обычно являются запросы, которые попадают в систему в период ее высокой нагрузки, или, если говорить даже более обобщенно, запросы, на которые влияют более редкие факторы, связанные с работой пользователей в системе; работоспособной считается система, в которой самые медленные запросы также находятся под контролем. Целевой показатель здесь такой же, как и для скорости отклика сервера, но для достижения отклика не более секунды в период пиковой нагрузки сервера необходимо построить систему, содержащую множество резервных ресурсов для обработки пиковой нагрузки.
Использование системных ресурсов: общими показателями для наблюдения за исправностью системы являются также системные счетчики, показывающие исправность каждого сервера в топологии фермы. Чаще всего для этой цели используются такие показатели, как процент использования ЦП и доступная память; однако имеется несколько дополнительных счетчиков, которые помогут определить неисправность системы; подробные сведения см. в разделе Шаг 5. Поддержка.

Шаг 2. Макет

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

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

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

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

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

Роль	Тип (стандартный или виртуальный)	Число компьютеров	Процессоры	ОЗУ	Число операций ввода-вывода в секунду	Размер диска, ОС+журнал	Диск данных
Веб-серверы	Виртуальный	4	4 ядра	8	Не определен	400 ГБ	Не определен
Сервер базы данных контента	Стандартный	1 кластер	4 Quad-Core 2,33 (ГГц)	48	2000	400 ГБ	20 дисков по 300 ГБ, 15 тыс. об/мин
Серверы приложений	Виртуальный	4	4 ядра	16	Не определен	400 ГБ	Не определен
Целевой веб-сервер для обхода службы поиска	Виртуальный	1	4 ядра	8	Не определен	400 ГБ	Не определен
Сервер запросов поиска	Стандартный	2	2 Quad-Core 2,33 (ГГц)	32	Не определен	400 ГБ	500 ГБ
Сервер программы-обходчика службы поиска	Стандартный	2	2 Quad-Core 2,33 (ГГц)	16	400	400 ГБ	Не определен
Сервер базы данных для обхода службы поиска	Стандартный	1 кластер	4 Quad-Core 2,33 (ГГц)	48	4000 (настроен для чтения)	100 ГБ	16 дисков по 150 ГБ, 15 тыс. об/мин
База данных хранилища свойств службы поиска + сервер базы данных администрирования	Стандартный	1 кластер	4 Quad-Core 2,33 (ГГц)	48	2000 (настроен для записи)	100 ГБ	16 дисков по 150 ГБ, 15 тыс. об/мин

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

В этом разделе рассказывается, как выбрать архитектуру.

При развертывании SharePoint Server 2010 можно выбрать топологию для реализации решения; можно развернуть один сервер или использовать множество серверов в ферме SharePoint Server с кластеризованными или отраженными серверами баз данных и серверами приложений c невысокой производительностью для различных служб. Затем выбираются спецификации оборудования в зависимости от требований каждой из ролей, а также от необходимой емкости, доступности и избыточности.

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

Примеры технического внедрения SharePoint Server 2010

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

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

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

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

Для получения дополнительных сведений загрузите соответствующие документы со страницы примеров технического внедрения: производительность и емкость (Возможно, на английском языке) (https://technet.microsoft.com/ru-ru/library/cc261716.aspx (Возможно, на английском языке)).

Выбор оборудования

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

Основные компоненты емкости и производительности оборудования серверов можно отнести к следующим четырем категориям: процессорная мощность, производительность диска, пропускная способность (емкость) сети и возможности памяти системы.

Необходимо принять во внимание еще один момент — использование виртуальных машин. При развертывании фермы SharePoint Server можно использовать виртуальные машины. Это не приносит дополнительных выгод в плане производительности, зато дает ряд преимуществ в плане управления. Виртуализация компьютеров с SQL Server обычно не рекомендуется, но виртуализация на уровне веб-сервера и сервера приложений может принести определенные преимущества. Дополнительные сведения см. в статье, посвященной планированию виртуализации (https://technet.microsoft.com/ru-ru/library/ff607968.aspx).

Выбор процессоров

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

В SharePoint Server 2010 можно увеличить возможности отдельных веб-серверов, добавляя дополнительные ядра (протестировано максимум 24 ядра); чем больше ядер имеет сервер, тем большую нагрузку он может поддерживать при прочих равных условиях. В крупных развертываниях SharePoint Server рекомендуется размещать либо несколько 4-ядерных веб-серверов (которые можно виртуализировать), либо меньшее количество более мощных веб-серверов (8,16 или 24 ядра).

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

Требования к емкости процессора для SQL Server также зависят от баз данных служб, размещаемых на компьютере с SQL Server. Дополнительные сведения о стандартном режиме работы и требованиях каждой базы данных см. в статье Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).

Выбор памяти

Серверам требуется различный объем памяти в зависимости от функции и роли сервера. Например, серверы, на которых выполняются компоненты обхода службы поиска, работают быстрее при наличии большого объема памяти, поскольку документы считываются в память для обработки. Веб-серверам, использующим возможности кэширования, входящие в SharePoint Server 2010, тоже может потребоваться больше памяти.

Как правило, требования к памяти веб-сервера напрямую зависят от числа разрешенных в ферме пулов приложений и числа обслуживаемых параллельных запросов. В большинстве производственных развертываний SharePoint Server рекомендуется выделять не менее 8 ГБ ОЗУ на каждый веб-сервер и 16 ГБ для серверов с более высоким трафиком или развертываний, где настроено несколько пулов приложений в целях изоляции.

Требования к памяти серверов приложений также различаются; некоторые компоненты SharePoint Server предъявляют более высокие требования на уровне приложений, чем другие. В большинстве производственных развертываний SharePoint Server рекомендуется выделять не менее 8 ГБ ОЗУ на каждый сервер приложений; серверы приложений с памятью 16 ГБ, 32 ГБ и 64 ГБ обычно используются, если на одном сервере используется несколько приложений-служб или если разрешены службы, которые напрямую зависят от памяти, например служба вычислений Excel и служба поиска SharePoint Server.

Требования к памяти со стороны серверов баз данных напрямую зависят от размеров баз данных. Дополнительные сведения о выборе памяти для компьютеров с SQL Server см. в статье Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).

Выбор сетей

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

Конфигурации веб-серверов и серверов приложений должны включать не менее двух сетевых карт (NIC): одна карта для обработки пользовательского трафика, другая — для обработки межсерверной связи. Задержка в сети между серверами может оказать существенное влияние на производительность, поэтому важно поддерживать сетевую задержку менее 1 миллисекунды между веб-сервером и компьютерами SQL Server, содержащими базы данных контента. Кроме того, компьютеры SQL Server, на которых располагаются базы данных приложений-служб, должны находиться как можно ближе к работающему с ними серверу приложений. Сеть между серверами фермы должна иметь пропускную способность не менее 1 Гбит/с.

Выбор дисков и хранилища

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

Дополнительные сведения о порядке выбора дисков для серверов баз данных см. в статье Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).

Веб-серверы и серверы приложений также имеют требования к хранилищу данных. В большинстве производственных сред рекомендуется выделять не менее 200 ГБ дискового пространства для ОС и временных файлов и 150 ГБ дискового пространства для журналов.

Шаг 3. Пилотный проект, тестирование и оптимизация

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

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

Ниже перечисляются вспомогательные шаги, которые рекомендуется выполнить на этапе подготовки:

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

Тестирование

Тестирование помогает определить, способен ли макет системы поддерживать рабочую нагрузку и характеристики использования. См. в разделе Тестирование производительности для SharePoint Server 2010 подробные сведения о тестировании развертывания SharePoint Server 2010.

Создание плана тестирования
Создание тестовой среды
Разработка соответствующих тестов и средств тестирования

Развертывание пилотной среды

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

Оптимизация

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

Шаг 4. Развертывание

После выполнения заключительных тестов и проверки того, что выбранная архитектура способна поддерживать целевые показатели производительности и емкости, установленные в разделе Шаг 1. Модель, можно приступать к развертыванию решения SharePoint Server 2010 в производственной среде.

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

Развертывание новой фермы SharePoint Server. Для задачи планирования емкости необходимы стандартизированные утвержденные планы по проектированию и развертыванию SharePoint Server 2010. В данном случае внедрение будет первым широкомасштабным развертыванием SharePoint Server 2010. Это потребует перемещения или повторного создания в производственной среде серверов и служб, которые использовались во время выполнения задачи планирования емкости. Это наиболее очевидный сценарий, поскольку здесь не требуется никаких обновлений или изменений в существующей ферме.
Обновление фермы Office SharePoint Server 2007 на SharePoint Server 2010. При выполнении задачи планирования емкости должен быть проверен и утвержден проект для фермы, который может соответствовать существующему спросу и масштабироваться для соответствия растущему спросу и использованию фермы SharePoint Server 2010. Часть задачи планирования емкости должна включать тестовые переносы данных, которые позволяют проверить длительность процесса обновления, необходимость изменения или замены пользовательского кода, необходимость обновления программных средств сторонних поставщиков и т. д. В заключение планирования емкости необходимо получить проверенный и утвержденный проект, представление о времени, которое займет обновление, и план наилучшего метода обновления — например, обновление на месте или перенос баз данных контента в новую ферму. Если выполняется обновление на месте, то во время планирования емкости можно обнаружить, что потребуется дополнительное оборудование или обновление существующего оборудования; кроме того, можно рассмотреть некоторые аспекты, касающиеся времени простоя. В результате выполнения задачи планирования емкости необходимо получить список необходимых изменений оборудования и план развертывания изменений оборудования в ферме, которое необходимо выполнить прежде всего. После того как аппаратная платформа, проверенная во время планирования емкости, будет установлена на месте, можно двигаться дальше и выполнять обновление на SharePoint Server 2010.
Повышение производительности существующей фермы SharePoint Server 2010. Задача планирования емкости должна помочь выявить узкие места в текущей реализации, разработать способы сокращения или исключения этих узких мест и проверить усовершенствованную реализацию, соответствующую бизнес-требованиям организации для служб SharePoint Server. Существуют различные способы решения проблем производительности начиная с таких несложных, как перераспределение служб по имеющемуся оборудованию, обновление имеющегося оборудования или добавление дополнительного оборудования и дополнительных служб. Следует протестировать и проверить различные подходы при выполнении задачи планирования емкости, а затем составить план развертывания на основе результатов тестирования.

Шаг 5. Наблюдение и поддержка

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

См. в разделе Мониторинг и обслуживание SharePoint Server 2010 список параметров, которые можно изменять для наблюдения за средой на ранних этапах; это поможет определить, какие изменения необходимы. Помните, что расширение возможностей наблюдения повлияет на объем дискового пространства, необходимый для базы данных использования. После того как среда стабилизируется и дальнейшая необходимость в таком пристальном наблюдении отпадет, можно вернуть для параметров значения по умолчанию.

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

Health monitoring (SharePoint Server 2010)

Решение проблем и диагностика (https://technet.microsoft.com/ru-ru/library/ee748639.aspx)