Тюнинг SQL Server 2012 под SharePoint 2013/2016. Часть 1

  • Tutorial
Здравствуйте. Меня зовут Любовь Волкова, я системный архитектор департамента разработки бизнес-решений. Время от времени я пишу прикладные посты о серверных продуктах Microsoft (например про мониторинг серверов SharePoint и про обслуживание баз данных, связанных с базами контента, службами и компонентами этой платформы.

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

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


Планирование инсталляции SQL-сервера


Виртуализация SQL-сервера


Зачем нужна виртуализация серверов?


Перечислим семь основных причин, почему рассматривается вопрос о виртуализации серверов:

  1. Увеличение коэффициента использования аппаратного обеспечения. По статистике, большинство серверов загружены на 15-20 процентов при выполнении ими повседневных задач. Использование нескольких виртуальных серверов на одном физических позволит увеличить его до 80 процентов, обеспечив при этом существенную экономию на приобретении аппаратного обеспечения.

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

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

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

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

  6. Экономия на обслуживающем персонале. Упрощение управления виртуальными серверами в перспективе влечет за собой экономию на специалистах, обслуживающих инфраструктуру компании. Если два человека с помощью средств для управления виртуальными серверами могут делать то, что делали четверо, зачем вам два лишних специалиста, получающих не менее $15000 в год? Тем не менее, нужно учитывать, что для подготовки квалифицированных кадров в сфере виртуализации тоже нужны немалые деньги.

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

Поддержка виртуализации SQL-северов


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

  • Active Directory Domain Services;
  • Веб-серверов и серверов приложений SharePoint (Front-End Web Server и Application Server);
  • SQL Server Services;
  • Любого компонента SQL, ADS, SharePoint 2013.

Сводные данные о гостевых операционных системах, поддерживаемых ими версиях SQL-серверов и кластеризации виртуальных машин представлены в таблице ниже:
Версия SQL-сервера Поддерживаемые гостевые операционные системы Windows Server Поддержка на Hyper-V Поддержка гостевой кластеризации
SQL Server 2008 SP3 2003 SP2, 2003 R2 SP2, 2008 SP2, 2008 R2 SP1, 2012, 2012 R2 Да Да
SQL Server 2008 R2 SP2 2003 SP2, 2008 SP2, 2008 R2 SP1, 2012, 2012 R2 Да Да
SQL Server 2012 SP1 2008 SP2, 2008 R2 SP1, 2012, 2012 R2 Да Да
SQL Server 2014 2008 SP2, 2008 R2 SP1, 2012, 2012 R2 Да Да

Отметим, что поддержка гостевой кластеризации осуществляется в версиях операционной системы Windows Server 2008 SP2 и более поздних.

Более подробное описание назначение и архитектуры отказоустойчивого гостевого кластера можно найти здесь, а требований к оборудованию, особенностей поддержки работы в виртуальной среде для конкретных версий SQL-серверов можно получить по ссылкам, приведенным в следующей таблице:
Версия SQL-сервера Ссылка на документацию
SQL Server 2008 SP3 Hardware & Software Requirements, Hardware Virtualization & Guest Clustering Support
SQL Server 2008 R2 SP2 Hardware & Software Requirements, Hardware Virtualization & Guest Clustering Support
SQL Server 2012 SP1 Hardware & Software Requirements, Hardware Virtualization & Guest Clustering Support
SQL Server 2014 Hardware & Software Requirements, Hardware Virtualization & Guest Clustering Support

Производительность SQL-серверов при виртуализации


Исследования ESG Labs подтвердили, что производительность SQL Server 2012 OLTP на виртуальных серверах уступает лишь около 6.3% показателям физической платформы.

Hyper-V поддерживает до 64 процессоров на отдельную виртуальную машину, тесты показали увеличение производительности в 6 раз и 5-кратное повышение показателей времени выполнения транзакций. На иллюстрации ниже представлены основные результаты проведенных тестов. С подробным отчетом можно познакомиться здесь.



Hyper-V может быть использована для виртуализации баз данных SQL-сервера больших объемов и поддерживает использование дополнительных возможностей, таких как SR-IOV, Virtual Fibre Channel и Virtual NUMA.

Недостатки виртуализации SQL-серверов


Перечислим главные ее недостатки, которые становятся основными причинами того, что SQL-сервер для SharePoint разворачивается на физическом сервере:

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

  2. Балансировка нагрузки. Если виртуальная машина SQL-сервер обычно использует много вычислительных ресурсов процессора (или памяти), что сказывается на работе других виртуальных машин и приложений хоста, которым также требуется процессорное время (память). Даже в случае размещения на хосте только виртуальной машины с SQL-сервером, настройка оптимального уровня производительности требует целого комплекса действий. Подробнее об этом можно узнать в статье Майкла Оти, доступной по ссылке. Администраторам приходится распределять нагрузку, устанавливая правила, по которым запущенные виртуальные машины будут автоматически перемещаться на менее нагруженные сервера или же «разгружать» загруженные.

ОЗУ & ЦПУ


Для обеспечения нормального уровня функционирования SQL-сервера требуется обеспечить достаточное кол-во оперативной памяти. В случае, когда разворачивается только один экземпляр SQL, который выделяется исключительно под работу с базами данных SharePoint, требования минимальны:
Малая ферма SharePoint (контент до 500 Гб) Средняя ферма SharePoint (контент от 501 Гб до 1 Тб) Большая ферма SharePoint (контент 1-2 Тб) Очень большая ферма SharePoint (контент 2-5 Тб) Особые случаи
ОЗУ 8 Гб 16 Гб 32 Гб 64 Гб 64 Гб
ЦПУ 4 4 8 8 8

Планирование размера, размещения и общих требований к базам данных для SharePoint


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

  1. Перед инсталляцией SQL-сервера. К этой группе относятся все системные базы данных SQL-сервера, база контента SharePoint (по умолчанию одна).
  2. Перед инсталляцией SharePoint-сервера. К этой группе относятся база данных конфигурации SharePoint, база контента Центра Администрирования SharePoint.
  3. Перед развертыванием приложения-службы, хранящей данные в базе/базах данных. Примеры: служба управляемых метаданных, служба профилей пользователей, поиск и др.
  4. Перед созданием дополнительных баз контента SharePoint.

В статье Майкрософт подробно описываются основные характеристики всех базы данных, перечисленных в группах. В таблице ниже приведена рекомендация по настройке режима восстановления для каждой из них с учетом многолетнего опыта технической поддержки, миграций, восстановления баз данных SharePoint:
База данных
Режим восстановления по умолчанию
Рекомендуемый режим восстановления и комментарии
База данных master
Простой
Простой
Шаблон базы данных model
Полный доступ
Простой.

Как правило настройка выполняется однократно или очень редко. Вполне достаточно выполнять резервную копию после внесения изменений
База данных msdb
Простой
Простой
База данных tempdb
Простой
Простой
База данных контента Центра администрирования
Полный доступ
Простой.
База данных конфигурации
Полный доступ
Изменения обычно активно вносятся на этапе первоначальной или точечной настройки служб и компонентов фермы SharePoint, что имеет четкие непродолжительные временные границы. Более рационально выполнять резервную копию после внесения завершенных блоков изменений.
База данных службы управления приложениями
Полный доступ
Простой.
Как правило в ферме SharePoint устанавливается от 0 до небольшого кол-ва приложений (1-5) SharePoint. Установки приложений обычно существенно разнесены по времени. Более рационально выполнять полное резервное копирование базы данных после инсталляции отдельного приложения
База данных службы параметров подписки
Полный доступ
Простой.
Как правило приложения SharePoint устанавливаются на небольшом кол-ве сайтов (1-5). Установки приложений обычно существенно разнесены по времени. Более рационально выполнять полное резервное копирование базы данных после инсталляции отдельного приложения.

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


Полный доступ в случае внесения изменений в наборы терминов на регулярной основе (активное создание и редактирование иерархических справочников, тегитирование элементов списков и документов).
База данных приложения-службы перевода SharePoint
Полный доступ
Простой.
Power Pivot Database
Полный доступ
Полный доступ
База данных PerformancePoint Services
Полный доступ
Простой в случае работы с набором панелей индикаторов, в настройки которых редко вносятся изменения.


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


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


Полный доступ, если поиск по порталу и его постоянная персонализированная работа являются критичными для бизнеса
База данных Secure Store
Полный доступ
Простой.
Настройка и внесение изменений, связанных с работой данной службы обычно непродолжительна по времени и выполняется однократно или небольшое кол-во раз. Более рационально выполнять полное резервное копирование базы данных после завершенных блоков настроек.
База данных приложения-службы состояний
Полный доступ
Простой.
Ввиду того, что эта база данных обеспечивает хранение временных состояний для форм InfoPath, веб-частей службы Visio и не предназначена для продолжительного хранения этой информации. Корректность данных в этой базе имеет значение на момент просмотра пользователем конкретной формы InfoPath или Visio-диаграммы посредством веб-части.
База данных сбора данных об использовании и работоспособности
Простой
Простой или Полный доступ.
Зависит от требований к допустимому для организации уровню потери данных.
База данных профилей
Простой
Простой, если нет бизнес-критичного функционала, работа которого требует работы с самыми актуальным данными о профилях пользователей


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


Полный доступ, если ситуация обратная
База данных социальных тегов
Простой
Простой, если работа с социальным контентом не является бизнес-критичным функционалом


Полный доступ, если ситуация обратная
База данных Word Automation
Полный доступ
Полный доступ

Количество дисков


В идеале на SQL-сервере рекомендуется иметь шесть дисков для размещения следующих файлов:

  1. Файлы данных базы данных tempdb;
  2. Файл журналов транзакций базы данных tempdb;
  3. Файлы данных баз данных SharePoint;
  4. Файлы журналов транзакций баз данных SharePoint;
  5. Операционная система;
  6. Файлы других приложений.

Подготовка дисковой подсистемы


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

Данные, которые хранит Microsoft SQL Server, разбиваются на страницы размером по 8 КБ, которые в свою очередь группируются в так называемые экстенты (extent) размером по 64 КБ. Подробнее об этом можно узнать здесь. В соответствии с этим настройка дисковой подсистемы заключается в обеспечении целостного размещения экстента на всех физических и логических уровнях дисковой подсистемы.

Первое с чего следует начать – это инициализация RAID. При этом массив, на котором будут располагаться базы данных должен иметь размер страйпа (stripe size) кратный 64 КБ, предпочтительнее если это будет именно 64 КБ.

Выравнивание разделов жёсткого диска или твердотельного накопителя SSD


Процедура выравнивания файловой системы относительно физического её размещения на дисковом массиве имеет очень важное значение при рассмотрении вопроса повышения производительности работы SQL-сервера. Подробно она описана здесь. На любом жёстком диске или SSD первые 63 сектора по 512 байт зарезервированы для размещения файлов, которые создаются в процессе установки операционной системы или при выполнении операций управления дисками, а также с помощью специальных программ — менеджеров разделов жёсткого диска. Суть процедуры выравнивания заключается в подборе такого начального смещения (starting partition offset), при котором в одном страйпе дискового массива умещалось бы целое число кластеров файловой системы. Иначе возможна ситуация, при которой для произведения операции считывания одного кластера данных файловой системы необходимо будет выполнить две операции физического чтения с дискового массива, что в значительной степени ухудшает производительность дисковой подсистемы (потеря в производительности может составлять до 30%). В случае твердотельного накопителя потери производительности будут несколько ниже, но он быстрее выработает свой ресурс ввиду более частых операций чтения-записи.

На иллюстрации ниже отражены особенности выполнения операций чтения/записи для невыравненных разделов на примере страйпа в 64 Кб.



На иллюстрации ниже отражены особенности выполнения операций чтения/записи для выравненных разделов на примере страйпа в 64 Кб.

По умолчанию в Windows Server 2008/2012 смещение разделов составляет 1024 Кб, что хорошо коррелируется с размером страйпов на дисках в 64 Кб, 128 Кб, 256 Кб, 512 Кб и 1024 Кб.

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

Важные корреляции: Partition Offset, File Allocation Unit Size, Stripe Unit Size


Partition Offset

Наиболее правильный метод проверки смещения разделов для базовых дисков, — использование утилиты командной строки wmic.exe:

wmic partition get BlockSize, StartingOffset, Name, Index



Для проверки выравнивания разделов для динамических дисков необходимо воспользоваться diskdiag.exe (описание работы с нею приведено в разделе «Dynamic Disk Partition Offsets»).

Stripe Unit Size

В ОС Windows нет стандартных средств определения размера минимального блока данных для записи на диск (stripe unit size). Значение этого параметра необходимо выяснять из документации вендора на жесткий диск или у SAN-администратора. Чаще всего показатели Stripe Unit Size составляют 64 Кб, 128 Кб, 256 Кб, 512 Кб или 1024 Кб. В рассмотренных ранее примерах использовалось значение в 64 Кб.

File Allocation Unit Size

Для определения значения данного показателя необходимо использовать следующую команду отдельно для каждого из дисков (Значение свойства Bytes Per Cluster):

fsutil fsinfo ntfsinfo c:



Для разделов, на которых хранятся файлы данных и файлы журналов транзакций SQL Server значение показателя должно быть 65,536 байт (64 Кб). См. «Оптимизация хранения данных на уровне файловой системы».

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

  • Partition_Offset ÷ Stripe_Unit_Size
  • Stripe_Unit_Size ÷ File_Allocation_Unit_Size

Наиболее важной является первая корреляция.

Пример невыравненных значений. Смещение раздела (Partition offset) равно 32,256 bytes (31.5 Кб) и размер минимального блока записи данных на диск составляет 65,536 bytes (64 Кб). 32,256 bytes/65,536 bytes=0.4921875. Результат деления не является целым числом, в итоге имеем не выравненные значения Partition_Offset и Stripe_Unit_Size.

Если же смещение раздела (Partition offset) равно 1,048,576 байт (1 Мб), а размер минимального блока записи данных на диск составляет 65,536 байт (64 Кб), то результат деления равен 8, — целое число.

Оптимизация хранения данных на уровне файловой системы


Следующим уровнем, на котором следует организовать оптимальное хранение экстентов, является файловая система. Оптимальными настройками здесь являются файловая система NTFS с размером кластера 65,536 байт (64 КБ). В связи с этим перед инсталляцией SQL-сервера настоятельно рекомендуется выполнить форматирование дисков и задать размер кластера в 65,536 байт (64 Кб) вместо 4096 байт (4Кб) по умолчанию.

Проверить текущие значения для диска можно при помощи следующей команды:
chkdsk c:

Пример вывода результата:



В представленном примере размер кластера равен 4096 байт/1024 = 4 Кб, что не соответствует рекомендациям. Для изменения придется выполнить переформатирование диска. Установку размера кластера можно выполнить в ходе настройки параметров форматирования диска средствами операционной системы Windows:



После этого убедиться в том, что размер кластера теперь соответствует рекомендациям (65536 байт/1024 = 64 кб):



Ранжирование дисков на основе данных о скорости чтения/записи


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

Для тестирования и определения точных данных о скорости чтения/записи файлов с произвольным доступом и с последовательным доступом можно воспользоваться программным обеспечением, аналогичным CrystalDiskMark (например, SQLIO). Обычно приложение позволяет ввести базовые параметры тестирования, как минимум:

  • Количество тестов. Тестов должно быть несколько для получения более точного среднего значения.
  • Размер файла, который должен быть использован в ходе выполнения тестов. Рекомендуется установить значение, превышающее объем оперативной памяти сервера, чтобы избежать использование только кэша. Кроме того, полученные цифры позволят получить статистику по выполнению обработки файлов больших размеров, что является актуальным для многих корпоративных порталов с интенсивной совместной работой пользователей над контентом.
  • Имя диска, на который будут выполняться операции чтения/записи;
  • Список тестов, которые необходимо выполнить.

Ниже приведен пример полученных результатов выполнения тестов:



Ниже приведено описание содержания выполняемых тестов:

  • Seq Q32 – скорость выполнения чтения/записи в файлы с последовательным доступом. Для SQL-сервера это такие операции, как резервное копирование, сканирование таблиц, дефрагментация индексов, чтение/запись файлов транзакций.

  • 4K QD32 – скорость выполнения большого кол-ва случайных операций чтения/записи с данными малых размеров (4 Кб) в один и тот же момент времени. Результаты теста позволяют судить о показателях диска при выполнении транзакций в ходе работы OLTP-сервера, имеющего высокую загрузку.

  • 512K — скорость выполнения большого кол-ва операций чтения/записи с данными больших размеров (4 Кб) в один и тот же момент времени. Результаты этого теста можно не учитывать, т.к. к работе SQL-сервера как такового отношения не имеют.

  • 4K – скорость выполнения небольшого кол-ва случайных операций чтения/записи с данными малых размеров (4 Кб) в один и тот же момент времени. Результаты теста позволяют судить о показателях диска при выполнении транзакций в ходе работы OLTP-сервера с небольшой загрузкой.

Отметим, что в тестах используется размер единицы записи в 4 Кб, что не полностью соответствует реальной схеме хранения данных SQL-сервером и работе со страницами в 8 кб эктентами в 64Кб. При выполнении нет цели обеспечить абсолютное соответствие полученных результатов реальным данным о тех же операциях, выполняемых SQL-сервером. Основная конечная цель – ранжирование дисков по скорости выполнения операций чтения/записи и получение итоговой таблицы.

Для быстрого принятия решения в ходе инсталляции SQL-сервера, конфигурирования параметров размещения файлов баз данных будет полезным оформить результаты проведения тестирований в виде таблицы отдельно по каждому виду тестов, шаблон которой показан ниже:
Диски с сортировкой по скорости выполнения операций чтения/записи от самого быстрого к самому медленному <Название теста> Назначенное имя Размер Комментарии
0 I: 20GB VHD фиксированного размера
1 H: 20GB VHD фиксированного размера
2 G: 50GB
3 F: 200GB
4 C: 80GB Операционная система
5 E: 2TB
6 D: 100GB

Как интерпретировать результаты тестов CrystalDiskMark?


Для магнитных дисков (отдельных или в составе RAID), последовательные операции operations (тест Seq Q32) часто превышают результаты других тестов в 10x-100x раз. Эти метрики часто зависят от способа подключения к хранилищу. Необходимо помнить о том, что кол-во Мб/с, заявляемые вендорами – это теоретические ограничения. На практике они обычно меньше заявляемых на 5-20%.

Для твердотельных дисков разница между скоростью последовательных и произвольных операций чтения/записи не должны сильно отличаются друг от друга, как правило не более чем в 2-3 раза. На скорость будут влиять методы подключения, такие как 3Gb SATA, 1Gb iSCSI, or 2/4Gb FC.

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

Расстановка приоритетов при выборе дисков


Информация о том, для каких целей используется портал, позволяет корректно расставить приоритеты при выборе дисков для хранения баз данных SharePoint.

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

Если корпоративный портал используется для организации совместной работы пользователей, которые ежедневно активно загружают десятки документов, приоритеты будут другими:
Скорость/Сценарий использования Преобладание редактирования контента над его чтением (внешний веб-сайт)
Наибольшая производительность Файлы данных и файлы журналов транзакций базы данных Tempdb
... Файлы журналов транзакций баз данных контента SharePoint
... Файлы данных службы поиска за исключением базы данных администрирования
Наименьшая производительность Файлы данных баз данных контента

Рекомендации по типам дисков для хранения баз данных для фермы SharePoint


Рекомендации по выбору диска для tempdb


Низкая скорость выполнения операций чтения/записи для системной базы данных tempdb SQL-сервера серьезно влияет на общую производительность фермы SharePoint, как следствие на производительность корпоративного портала. Лучшей рекомендацией может стать использование RAID 10 для хранения файлов этой базы данных.

Рекомендации по дискам для интенсивно использующихся баз контента


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

  • Размещение файлов данных и журналов транзакций для баз контента на разных физических дисках
  • Учесть в проектировании портальных решений рост размеров контента. Наиболее оптимальным является поддержка размера каждой отдельной базы контента до 200 ГБ.
  • Для интенсивно использующихся баз контента SharePoint рекомендуется использовать несколько файлов данных, размещая их на отдельных дисках. Во избежание внезапных системных сбоев в работе баз данных настоятельно рекомендуется не использовать настройку ограничения размера баз данных.

Расчет ожидаемого размера базы данных контента


Общая формула расчета ожидаемого размера базы данных контента:

((D*V)*S)+(10Kb*(L+(V*D))), где:

  • D – кол-во документов с учетом личных сайтов, документов и страниц в библиотеках, прогноза по увеличению кол-ва в ближайший год;
  • V – кол—во версий документов;
  • S – средний размер документов (если возможно выяснить);
  • 10 Kb – константа, ожидаемое SharePoint 2013 кол-во метаданных для одного документа;
  • L – ожидаемое кол-во элементов списков с учетом прогноза по увеличению кол-ва в ближайший год.

Необходимо учитывать дополнительные расходы по хранению:

  • Ведение аудита, время хранения данных аудита + прогнозы по росту данных аудита;
  • Корзина, время хранения данных в корзине сайта и коллекции сайтов.

Рекомендации по выбору RAID


Не смотря на то что RAID 5 имеет лучшие показатели в разрезе производительность/стоимость, для баз данных SharePoint настоятельно рекомендуется использовать RAID 10, особенно в случае активного использования корпоративного портала для совместной работы пользователей. RAID 5 имеет не очень высокие показатели скорости записи на диск.

Оптимизация передачи данных по сети


Необходимо убедиться в том, что между серверами SQL и SharePoint настроено высокоскоростное соединение.

Выделенные сетевые адаптеры и их объединения в группы


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

Инсталляция серверов SQL и SharePoint на базе Windows Server 2012 и использование функциональной возможности объединения адаптеров в группу даст дополнительные преимущества и может стать вторым серьезным шагом в оптимизации конфигурационных настроек под SharePoint:

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

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

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

  • 64-разрядный выпуск Windows Server 2008 R2 с пакетом обновления 1 (SP1) Standard, Enterprise или Datacenter
  • 64-разрядный выпуск Windows Server 2012 Standard или Datacenter
  • С выходом первого пакета обновления для Microsoft SharePoint Server 2013 стала доступна установка серверов SharePoint 2013 на базе 64-разрядного выпуска операционной системы Windows Server 2012 R2.

Scalable Networking Pack


Еще в 2007 году в системе Windows Server 2003 SP2 появился набор функций, управляющих производительностью сети и известных под общим названием Scalable Networking Pack (SNP). Данный пакет использовал аппаратное ускорение при обработке сетевых пакетов для обеспечения более высокой пропускной способности. В состав пакета SNP входят функции, известные как Receive Side Scaling (RSS), TCP/IP Chimney Offload (иногда ее называют TOE) и Network Direct Memory Access (NetDMA). Этот функционал операционной системы, позволяющий передать нагрузку по обработке пакетов TCP/IP от процессора на сетевую карту.

Из-за проблем с пакетом SNP в системе Server 2003 SP2 ИТ-сообщество быстро взяло за правило отключать эти функции. Для системы Server 2003 такой подход имел смысл. Но в системах Server 2008, Server 2008 R2 и более поздних версиях операционной системы отключение данных функций зачастую может привести к снижению производительности сети и пропускной способности сервера. Эти функции весьма стабильны в системе Server 2008 R2 (с пакетом SP1 или без него). К сожалению, отключение функций как один из первых шагов в решении сетевых проблем по-прежнему является очень распространенной практикой устранения неполадок, при том что многие проблемы таким образом не решаются.

Receive Side Scaling


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

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

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

netsh interface tcp show global



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



RSS также зависит от разгрузок сетевого адаптера, известных под названиями TCP Checksum Offload, IP Checksum Offload, Large Send Offload и UDP Checksum Offload (для протоколов IPv4 и IPv6). Так что, если они были отключены на сетевом адаптере, технология RSS не будет для него использоваться.





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



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

TCP/IP Chimney Offload


Технология TCP Chimney Offload (часто называемая производителями TCP/IP Offloading или более кратко, — TOE) передает обработку трафика TCP от процессора компьютера сетевому адаптеру, который поддерживает TOE. Передача TCP обработки с центрального процессора на сетевой адаптер может освободить процессор для выполнения функций, больше связанных с работой приложений. TOE может разгрузить обработку как для TCP/IPv4, так и для TCP/IPv6 соединений, если сетевой адаптер это поддерживает.

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

Серверы с недолгими соединениями, такие как веб-серверы SharePoint фактически ничего не выигрывают от данной технологии. В связи с этим рекомендуется отключить использование TCP Chimney Offload.

Проверить глобальные настройки TCP можно при помощи следующей команды:

netsh interface tcp show global



Отключить использования TOE для TCP можно при помощи команды:

netsh int tcp set global chimney=disable

Перед принятием решения об отключении использования TOE рекомендуется предварительно взглянуть на статистику использования TOE для TCP с помощью команды:

Netsh netsh interface tcp show chimneystats

Отключить ТОЕ для IP можно при помощи следующей команды

netsh int ip set global taskoffload=disabled

Проверить глобальные настройки IP при помощи другой команды:

netsh int ip show global



Network Direct Memory Access


NetDMA – достаточно интересная функция. Смысл её применения есть тогда, когда у Вас не поддерживается отключен TOE и необходимо ускорить обработку сетевых подключений. NetDMA позволяет копировать без участия CPU данные из приемных буферов сетевого стека сразу в буферы приложений, чем снимает с CPU данную задачу.

Для того, чтобы использовать NetDMA, необходимо оборудование, которое поддерживает этот функционал, – в случае Windows это процессор с поддержкой технологий семейства Intel I/O Acceleration Technology (I/OAT). Включение NetDMA на оборудовании AMD эффекта, увы, не принесёт.

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

Для включения NetDMA в Windows 2008 R2 можно использовать следующую команду:

netsh interface tcp set global netdma=enabled

Проверку состояния функционала можно выполнить при помощи другой команды:

netsh interface tcp show global



Настройки SNP по умолчанию


Windows Server 2008 R2
Параметр Значение по умолчанию
TCP Chimney Offload automatic
RSS enabled
NetDMA enabled

«Automatic» для TCP Chimney Offload означает, что функция будет включена, если для сетевого адаптера включена настройка «TCP Chimney Offload» в сочетании с использованием высокоскоростного подключения, такого 10 GB Ethernet.

Windows Server 2012, Windows Server 2012 R22
Параметр Значение по умолчанию
TTCP Chimney Offload disable
RSS enabled
NetDMA Не поддерживается
Softline
Компания

Комментарии 15

    0
    >На любом жёстком диске или SSD первые 63 сектора по 512 байт зарезервированы для размещения файлов, которые создаются в процессе установки операционной системы или при выполнении операций управления дисками, а также с помощью специальных программ — менеджеров разделов жёсткого диска
    Вот эта информация совсем чуть-чуть устарела. Не на десять лет, меньше, но около того.
    Собственно, тот контроллер, что на жестком диске, представляет собой достаточно давно «черный ящик», транслирующий видение контроллера, к которому он подключен, в физику. С нынешними секторами в 4К или эмуляцией сектора в 512 байт — это уже всё совсем не так.
    С SSD всё еще хуже — они, по сути, упрощенный вариант RAID-контроллера с накопителями и кэшем в одном корпусе.
    В итоге результат такого «выравнивания» будет зависеть отнюдь не от воли администратора сервера, а от логики, причем с более, чем одним уровнем абстракции: уровень ОС — уровень дискового контроллера — накопитель. И при смене прошивки контроллера или диска, либо обновлении ОС можно вместо ожидаемых получить результаты весьма неожиданные.
      0
      Выравнивание разделов остается одной из рекомендаций, которая справедлива для всех версий ОСЦ Windows и для всех версий SQL Server, включая SQL Server 2012 и SQL Server 2014. Исключений нет.
      При работе с ОС Windows Server 2008 и более поздними версиями, в ходе управления дисками средствами графического интерфейса выравнивание разделов выполняется автоматически. Несмотря на это на практике регулярно встречаются ситуации, когда системные администраторы вручную управляют разделами жестких дисков, не задумываясь о необходимости соблюдать корреляцию между Partition Offset, File Allocation Unit Size, Stripe Unit Size (в случае последующей работы с SQL Server). Если корреляция нарушена, это оказывает существенное влияние на производительность в ходе выполнения операция чтения/записи. В связи с этим вендором настоятельно рекомендуется обязательно проводить проверку выравнивания разделов перед инсталляцией любой из версий SQL Server.
      Более подробно вы можете прочитать об этом, например, в статье.
        0
        Я уже который год пытаюсь объяснить, что это выравнивание (наряду с «ручной» раскладкой нагрузки на диски и пр. подобными вещами) — оно давно уже перекочевало из вещей технических в область суеверий, потому как тестами это, как правило, подтвердить не удается.
      0

      Методы восстановления SQL все-таки "простой" и "полный" (Simple and Full).


      Отключение TCP Chimney нужно отлаживать. Для SharePoint вряд ли повлияет с точки зрения нормальной работы, но некоторое ПО, обычно связанное с шифрованием, плохо работает при включенном checksum offload. К сожалению, забыл, какое именно, но в его рекомендациях было отключать tcp chimney даже на гипервизорах. Наверно, это всё-таки не касается шарепойнта, но настройка иногда позволяет убрать малозаметные грабли при настройке некоторых типов серверного ПО.


      И можно поподробнее, зачем 64кб размер кластера для sql server? И нужно ли в случае виртуального диска хостовую ФС тоже форматировать под 64кб?

        0
        Если говорить о моделях восстановления баз данных SQL-сервера, то используем стандартные названия «простая», «полная» и «с неполным протоколированием».
        На практике при работе с локализованными последними версиями SQL-сервер встречаются непривычные нам подмены названий параметров и опций, на счастье без искажений сути. Очень не люблю локализации, но с ними приходится работать. В статье использованы реальные названия параметров и значения одной из таких локализаций.
        В случае SharePoint отладке работы с TCP/IP Chimney Offload следует уделить внимание при работе веб-приложений по SSL и активном обращении пользователей к файлам больших размеров (видео, аудио).
        Размер кластера в 64Кб коррелируется с размером экстента, — одной из основных единиц организации хранения данных SQL-сервером. Более подробно о страницах и экстентах можно прочитать здесь.
        Вендор не выдвигает прямого требования о соответствии между размерами кластеров на хостовой машине и виртуальной. Если есть возможность, то выполняют тестирование обоих вариантов, после чего выбирают с наиболее высокими показателями производительности.
        0
        Вот кстати да… Допустим, у меня все SQL-сервера стоят на RAID-контроллерах, минимум P420i. Там stripe по-умолчанию составляет 512к, что хорошо бьётся с современными дисками. А еще — чудесная рекомендация о шести дисках — точно ли 4 Гб кеша RAID-контроллера и 8 шпинделей в массиве (RAID 1+0) будут работать медленней, чем 2+2+2+2 в RAID 1 (по-другому я шпиндели без отказоустойчивости не размажу)? А если у меня, допустим, 128 Гб ОЗУ для небольшой БД? Как оно лучше будет работать после прогрева кеша — с раздельными дисками либо с массивом?
        Нужно ли для самого SQL-сервера выставлять настройку про OLTP-транзакции (оптимизацию для ad-hoc запросов), или это бессмысленно?
        Откройте нам тайну про использование maximum degree of parallelism, которую так любят выставлять в «1» при недостаточности процессорных ядер многие разработчики приложений… И да, использование термина «полный доступ» применительно к модели восстановления БД сильно режет глаз.
        Пока статья вопросов ставит больше чем ответов.
        При этом, настоящее спасибо за объяснение настроек сетевой карты понятным языком. Потому что в интернетах встречаются рекомендации «тыкните это» без объяснения причин, а это неправильно.
          0
          В первой части статьи, посвященной тюнингу SQL Server под SharePoint даются рекомендации относительно действий и настроек, которые выполняются еще до начала инсталляции SQL, и, тем более, SharePoint. Описание особенностей настройки параметров в ходе инсталляции SQL Server, а также параметрами и настройками непосредственно до инсталляции SharePoint и после нее будут описаны во второй части, выход которой ожидается 10.04.2017. Во второй части речь пойдет и о maximum degree of parallelism, и о коэффициенте заполнения индекса, и о многих других настройках.
          Ранжирование дисков по скоростям выполняется на основе проведения тестов, в этом отношении каждую конкретную среду можно считать уникальной. Рекомендация по распределению файлов данных и файлов журналов транзакций для баз данных SharePoint учитывает особенности выполнения операций чтения/записи в файлы данных, в файлы журналов транзакций, а также типовые различия в интенсивности этих операций в отношении разных служб и компонентов SharePoint. Обязательным является предварительный анализ характера работ на портале.
            0
            OLTP-транзакции и оптимизация для ad-hoc запросов — это разные вещи, не путайте их, пожалуйста.
            OLTP — это большое количество транзакций, в т.ч. на запись.
            Ad-Hoc запросы — это запросы, «новые» для сервера, т.е. не имеющие плана выполнения.
            Т.е. база может быть OLTP, но совершенно не иметь ad-hoc запросов, если вся логика заложена в хранимые процедуры и работа идет через них. ad-hoc — это когда запросы генерируются на лету, тут же выполняются и забываются.
            Соответственно, опция дает понять SQL Server'у, что не нужно хранить полный план для каждого запроса, тем самым снижается нагрузка на память для кэша планов.

            max degree of parallelism — действительно рекомендуется выставлять в 1. Логика тут примерно такая — у вас все равно очень много запросов, поэтому все процессорные ядра будут загружены примерно поровну, а параллелизм дает доп. нагрузку на процессор, которую можно снизить, отключив параллелизм. Каждый конкретный запрос, возможно, будет выполняться чуть дольше без параллелизма, но в среднем производительность системы будет выше.
            Для примера, у нас база используется также и для некоторой OLAP-нагрузки, периодически выполняются отчеты по базе, поэтому мы не выставляем этот параметр в 1, но мы сильно задираем вверх значение параметра «cost threshold for parallelism», чтобы в параллелизм уходили только очень тяжелые запросы, которым параллелизм сильно сократит время выполнения.
            max degree of parallelism при этом нельзя ставить равным количеству ядер, т.к.в этом случае долгий запрос «подвесит» сервер, не даст другим запросам выполняться, пока он сам не будет выполнен (это очень грубое описание, но смысл, думаю, понятен), поэтому мы выставляем его обычно равным половине ядер на сервере.
              0
              Про OLTP и ad-hoc — извините, был неправ. Вы меня поправили совершенно справедливо.
              А вот про max degree… Понимаете, в теории я с вами согласен. На практике ни один наш синтетический тест (не говоря о реальной работе) не показал преимущества ручной настройки max degree либо cost treshold for parallelism — длительность выполнения запросов только увеличивалась, по сравнению с настройками по-умолчанию, а занять все ядра (у нас ad-hoc не приветствуется, и для всего критичного индексы есть) у нас не получилось. Потому спасибо за вашу информацию, попробуем синтетику с указанными вами настройками.
                0
                Посмотрите переведенную мной статью про ожидания. Конкретнее — про CXPACKET. Когда это ожидание становится проблемой — тогда имеет смысл думать про настройку этих параметров. Пока оно не проблема — можно не трогать эти параметры, с достаточной долей вероятности они приведут к замедлению, а не к ускорению.
                Все таки параллелизм — это благо, оно, как правило, приводит к ускорению запросов. Замедление происходит, только когда загрузка сервера приближается к максимуму — тогда лишняя работа по организации параллелизма может приводить к негативным последствиям.
                  0
                  Я читал статью, спасибо. Действительно, нам CXPACKET не доставляет проблем. Видимо, в результате аппаратного запаса. Получается, что в синтетике мало смысла.
                  0
                  Будем благодарны за обратную связь по результатам ваших тестирований.
                  0
                  SharePoint изначально ориентирована на обработку большого кол-ва конкурирующих запросов, в связи с чем для параметра max degree of parallelism вендор рекомендует установить значение 1. Более того, если будет установлено иное значение, то будут блокироваться операции создания баз данных SharePoint. Подробнее можно прочитать здесь.
                0
                В идеале на SQL-сервере рекомендуется иметь шесть дисков для размещения следующих файлов:


                Я не занимался настройкой MS SQL Server для Sharepoint, но, учитывая количество баз, указанных в пункте выше, разве не логично будет вынести разные базы на разные диски? По крайней мере, высоконагруженные для разных типов использования базы вынести на отдельные диски? Это раз уж мы заговорили об «идеале».

                Расстановка приоритетов при выборе дисков


                Мне кажется, полезнее было бы увидеть приоритеты в зависимости от скорости чтения и скорости записи. Для разных файлов в приоритете разные виды ввода-вывода. Например, для файла данных основной базы важнее скорость случайного чтения, а для файла журнала транзакций — скорость последовательной записи. Ну и т.д.
                  0
                  Один из наиболее часто встречающихся на практике подходов – выделение трех дисков (1- под ОС, второй – под файлы данных, 3 – под журналы). Этот вариант предлагается обычно администраторами баз данных, не знакомыми с SharePoint. Те, кто понимает специфику работы на портале и возникающую нагрузку по обработке данных, еще учитывает другую информацию. Примеров можно привести массу, рассмотрю лишь два:
                  Кейс 1. В случае развертывания портала в базовой конфигурации и небольших пропорциональных нагрузках по чтению/записи контента, работе с файлами небольших размеров и обеспечении стандартных возможностей поиска разбиения между двумя дисками файлов данных и журналов вполне хватает. В случае же большого кол-ва файлов (к примеру, 1 млн), повышения требований ко времени обхода контента, производительности поиска, — без переноса файлов данных и журналов службы поиска на другие диски уже не обойтись из-за явно наблюдаемых проблем производительности.
                  Кейс 2. Если на портале реализован функционал по массовой обработке элементов списков/библиотек, обработке XML и тп, то существенно повышаются требования к скорости чтения/записи для базы данных tempdb и базе контента.

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

                Самое читаемое