Использование SQL Server 2008 в среде Hyper-V (стр. 5 )

Рис. 10. Коэффициент использования сети и ЦП при резервном копировании

Рис. 11. Коэффициент использования сети и ЦП при восстановлении

Таблица 5 содержит данные, собранные при выполнении этого тестового сценария.

Таблица 5. Пропускная способность при резервном копировании и восстановлении

	Основная среда	Корневой раздел	Гостевая виртуальная машина (диски прямого доступа)	Гостевая виртуальная машина (виртуальные жесткие диски фиксированного размера)
Пропускная способность при резервном копировании (МБ/с)	181,00	158,00	154,00	157,00
Общее время резервного копирования (сек)	764,00	875,00	874,00	874,00
Пропускная способность при восстановлении (МБ/с)	241,00	218,00	173,00	167,00
Общее время восстановления (сек)	573	634	799	824

Перестроение индекса

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

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

Рис. 12. Последовательное перестроение трех индексов компрессией на уровне страниц

DBCC CHECKDB

Также была протестирована операция DBCC CHECKDB, еще одна операция с интенсивным использованием ресурсов ЦП и дискового ввода-вывода. Выполнение этой операции на гостевой виртуальной машине занимает больше времени, чем в базовой ОС. Рис. 13 показывает время выполнения в сравнении с общим объемом потребленных операцией ресурсов ЦП. Как и при тестировании перестроения индекса, обнаружено сравнительно небольшое увеличение времени выполнения.

Рис. 13. Инструкция DBCC CHECKDB с параметром MAXDOP 0

Варианты консолидации экземпляров SQL Server с помощью среды Hyper-V

Целью выполнения этих тестов был поиск ответов на некоторые основные вопросы, связанные с консолидацией экземпляров SQL Server в среде Hyper-V:

Влияние на производительность конфигурации хранилища данных нескольких экземпляров

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

Масштабируемость виртуального экземпляра

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

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

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

Сравнение конфигураций хранилищ в консолидированной среде

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

Выделенное хранилище (т. е., диск используется только одной виртуальной машиной) на базе дисков прямого доступа Общий массив дисковых ресурсов с файлами виртуальных жестких дисков для хранения данных и файлов журналов SQL Server

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

Рисунок 14. Конфигурация дисков виртуальной машины/корневого раздела

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

Рисунок 15. Единые массивы

Затем одинаковая рабочая нагрузка OLTP была использована при разных уровнях пропускной способности в каждой из этих двух конфигураций. На рисунках 16 и 17 показана пропускная способность ввода-вывода и сравнение времени задержки при использовании конфигурации с выделенными хранилищами на базе дисков прямого доступа и конфигурации с совместно используемым хранилищем на базе файлов виртуальных жестких дисков.

Рисунок 16. Пропускная способность ввода-вывода и время задержки при использовании дисков прямого доступа и виртуальных жестких дисков фиксированного размера

Рисунок 17. Пропускная способность выделенных LUN прямого доступа и виртуальных жестких дисков фиксированного размера на базе общих дисков

Обе эти конфигурации хранилищ обеспечивали сходную производительность. В среднем конфигурация с виртуальными жесткими дисками фиксированного размера работала примерно на 3,5% медленнее, чем при использовании выделенных дисков прямого доступа. Если важнейшее значение имеет производительность ввода-вывода и предсказуемость, то рекомендуется использовать диски прямого доступа на базе выделенных дисковых ресурсов. Использование же файлов виртуальных жестких дисков обеспечивает лишь небольшое преимущество в плане гибкости.

Масштабируемость виртуального экземпляра

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

Сервер Dell R900, использовавшийся для этого теста, имеет 16 ядер. Было выполнено два набора тестируемых вариантов. Первый набор был настроен для использования восьми ядер (NUMPROC=8), а второй — всех шестнадцати ядер (NUMPROC=16). Все гостевые виртуальные машины имели по четыре логических процессора и 14 ГБ ОЗУ. SQL Server мог использовать до 12 ГБ памяти, оставшиеся 2 ГБ были зарезервированы для операционной системы.

Две гостевые виртуальные машины, работающие одновременно

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

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

Рисунок 18. Масштабируемость гостевых виртуальных машин, работающих одновременно

Четыре гостевые виртуальные машины, работающие одновременно

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

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

Все четыре виртуальных машины имели одинаковые подсистемы хранения.

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

Рисунок 19. Масштабируемость виртуальных машин без перегруженных процессоров

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

Среда Hyper-V поддерживает сопоставление логических ЦП с виртуальными в соотношении 1:8. При консолидации перегрузку процессоров можно использовать, чтобы максимально задействовать ресурсы ЦП, имеющиеся на физическом сервере. Этот метод, однако, ведет к значительному росту издержек ЦП. Описанные в этом разделе тесты позволили оценить влияние выполнения SQL Server в виртуализованной среде с перегруженными ресурсами ЦП.