10 рекомендаций по настройке хранилищ данных

 Автор: Алексей Халяко

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

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

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

• Каково соотношение операций чтения и записи, производимых приложением?
• Каковы типичные значения параметров дискового ввода-вывода (число операций ввода-вывода в секунду, объем передаваемых данных в МБ/с, размер операций ввода-вывода)? Проверьте следующие счетчики системного монитора:

1. Средняя скорость чтения, байт/c (average read bytes/sec), средняя скорость записи, байт/c (average write bytes/sec)
2. Чтений/с (reads/sec), записей/с (writes/sec)
3. Скорость чтения с диска (disk read bytes/sec), скорость записи на диск, байт/c (disk write bytes/sec)
4. Среднее время чтения с диска (average disk sec/read), среднее время записи на диск (average disk sec/write)
5. Средняя длина очереди диска (аverage disk queue length)

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

С основными возможностями дискового ввода-вывода в SQL Server можно ознакомиться в статье Основы ввода-вывода в SQL Server 2000 (на английском языке).

2. Использование большего числа дисков и/или дисков с более высокой скоростью работы положительно скажется на производительности системы

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

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

• За исключением случаев, когда досконально известны особенности приложения, не следует дополнительно оптимизировать дисковый ввод- вывод путем выборочного размещения объектов на различных физических дисках.
• Обязательно продумайте заранее стратегию роста инфраструктуры. Как будет решаться задача увеличения числа файлов данных, устройств LUN и групп RAID по мере роста объема данных? Лучше спланировать решение этой задачи заранее, чем впоследствии перераспределять нагрузку по файлам данных или LUN в уже работающей системе.

4. Проверяйте конфигурацию перед развертыванием

• Перед развертыванием SQL Server выполните базовое тестирование пропускной способности дисковой подсистемы ввода-вывода. Убедитесь, что на этих тестах достигаются требуемые показатели дискового ввода-вывода с приемлемым временем задержки. Одним из средств, полезных для тестирования, является SQLIO. Вместе с этим средством поставляется документ, в котором описаны основы тестирования дисковой подсистемы ввода-вывода. Загрузите Средство DISKSPD для тестирования дисковой подсистемы.
• Учтите, что тесты DISKSPD не предназначены для точного воспроизведения реальных характеристик дискового ввода-вывода SQL Server. Однако они помогут оценить максимальную пропускную способность, которую можно достичь в подсистеме дискового ввода-вывода для распространенных типов ввода-вывода SQL Server.
• В качестве альтернативы средству DISKSPD можно использовать средство IOMETER.

5. Всегда размещайте файлы журналов на дисковых массивах SSD или если HDD, то RAID 1+0 (или RAID 1). Это позволит:

• обеспечить повышенную защиту от сбоев оборудования;
• достичь большей производительности записи.
• Примечание. Дисковый массив RAID 1+0 обычно обеспечивает более высокую пропускную способность для приложений, интенсивно нагружающих подсистему записи. Выигрыш в производительности может быть разным в зависимости от реализации RAID на конкретном оборудовании. Самой распространенной альтернативой дисковому массиву RAID 1+0 является массив RAID 5. Однако в общем случаем массив RAID 1+0 обладает самой высокой производительностью среди массивов RAID, предусматривающих защиту данных, включая также и RAID 5.

6. Изолируйте журнал от данных на уровне физического диска (не актуально для SSD)

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

7. Проверьте конфигурацию базы данных TEMPDB

• После установки SQL Server базу данных TEMPDB необходимо переместить в подходящее хранилище и правильно задать для нее исходный размер.
• В некоторых случаях (в зависимости от характера использования TEMPDB) можно добиться повышения производительности, если поместить базу данных TEMPDB на дисковый массив SSD, а в случае HDD на RAID 1+0.
• Создайте для базы данных TEMPDB один файл данных на каждый ЦП, как описано ниже в пункте 8.

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

• Рекомендуется иметь от 0,25 до 1 файла данных (в каждой файловой группе) на каждый процессор сервера.
• Это особенно важно для базы данных TEMPDB, для которой рекомендуется создать 1 файл данных на каждый процессор.
• Двухъядерные процессоры считаются за 2 процессора, но логические процессоры (технология Hyper-Threading) не считаются отдельными процессорами.

9. Соблюдайте основные требования SQL Server

• Файлы данных должны иметь одинаковый размер. Алгоритм пропорционального заполнения, применяемый в SQL Server, отдает предпочтение файлам с большим объемом свободного места.
• Задавайте исходный размер для файлов данных и файлов журнала.
• Не полагайтесь на автоматическое расширение этих файлов, включаемое с помощью параметра AUTOGROW; вместо этого управляйте увеличением размера вручную. По соображениям безопасности можно оставить для параметра AUTOGROW значение ON, однако следует заблаговременно увеличивать размер файлов данных.

10. Соблюдайте основные требования к конфигурации хранилища

• Используйте последние версии драйверов HBA, рекомендуемые поставщиком оборудования.
• Применяйте специальные версии драйверов, полученные с веб-узла изготовителя HBA и предназначенные для определенного оборудования.
• Настройте параметры HBA в соответствии с потребностями томов ввода-вывода. Обычно поставщик оборудования указывает необходимые значения параметров драйвера, однако обнаружилось, что, как правило, значение длины очереди по умолчанию оказывается недостаточным для поддержки томов ввода-вывода SQL Server.
• Убедитесь, что прошивка массива хранения данных обновлена до последней рекомендованной версии.
• Для равномерного распределения нагрузки по HBA и устройствам LUN применяйте ПО многопутевого ввода-вывода. Убедитесь, что оно работает правильно.
• Такое ПО упрощает настройку и помогает в обеспечении доступности.
• Технология Microsoft Multipath I/O (MPIO): разработчики оборудования создают модули для отдельных устройств (DSM) на базе пакета разработки драйверов, поставляемого корпорацией Майкрософт.