Рекомендации и вопросы производительности

Техническая статья о SQL Server

Авторы: Линдсей Аллен (Lindsey Allen), Майк Рутраф (Mike Ruthruff), Прем Мехра (Prem Mehra)

Технические редакторы: Синди Гросс (Cindy Gross), Бурзин Пател (Burzin Patel), Денни Ли (Denny Lee), Майкл Томасси (Michael Thomassy), Санджай Мишра (Sanjay Mishra), Савитха Падманабхан (Savitha Padmanabhan), Тони Вельм (Tony Voellm), Боб Уорд (Bob Ward)

Дата публикации: октябрь 2008 г.

Область применения: SQL Server 2008

Аннотация

Hyper-V — это мощная технология виртуализации, доступная при работе под управлением Windows Server 2008. Она обеспечивает консолидацию слабо загруженных корпоративных серверов, что позволяет снизить совокупную стоимость владения при хранении и повысить качество обслуживания. В документе рассматриваются рекомендации по запуску SQL Server в среде Windows Hyper-V на примере ряда сценариев, стандартных при использовании SQL Server.

Авторские права

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

Этот технический документ предоставляется исключительно в ознакомительных целях. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ДАЕТ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ ОТНОСИТЕЛЬНО СВЕДЕНИЙ, СОДЕРЖАЩИХСЯ В ДАННОМ ДОКУМЕНТЕ.

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

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

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

Microsoft, Hyper-V, SQL Server, Windows и Windows Server являются охраняемыми товарными знаками группы компаний Майкрософт.

Все остальные охраняемые товарные знаки являются собственностью соответствующих владельцев.

Введение

Основанная на технологии гипервизора функция виртуализации Hyper-V™ представляет собой тонкий слой ПО, связывающий оборудование и ОС Windows Server® 2008, который позволяет одновременно запускать на сервере несколько операционных систем без их модификации. Hyper-V — это мощная технология виртуализации, обеспечивающая консолидацию слабо загруженных корпоративных серверов, что позволяет снизить совокупную стоимость владения при хранении и повысить качество обслуживания.
Hyper-V дает возможность обойти ограничения, связанные с наличием оборудования, и использовать больше разнообразных типов сред разработки и тестирования.

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

· Дополнительные затраты системных ресурсов, связанные с работой SQL Server в среде Hyper-V

· Масштабируемость Hyper-V при работе с SQL Server 2008

В этом документе описан ряд опробованных тестовых конфигураций, представляющих разнообразные возможные сценарии функционирования SQL Server в среде Hyper-V. В документе изложены полученные результаты и наблюдения, а также представлены рекомендации. Результаты тестов показали, что SQL Server 2008 обеспечивает при работе в среде Hyper-V стабильную производительность и масштабируемость. Мы уверены, что при соответствующих рабочих нагрузках Windows Server 2008 Hyper-V представляет собой надежную платформу для работы SQL Server 2008. Запуск производственных процессов в среде Hyper-V допустим при условии, что рабочая нагрузка не превышает возможностей гостевой виртуальной машины Hyper-V.

Установка и настройка конфигураций Hyper-V

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

Контрольный список и вопросы установки Hyper-V

· Используйте серверный процессор с аппаратной поддержкой виртуализации. На выбор имеется два варианта:

o Intel VT

o AMD Virtualization (AMD-V)

· Убедитесь в том, что функции аппаратной поддержки виртуализации и предотвращения выполнения данных (Data Execution Prevention, DEP) имеются в наличии и включены. (Проверить это можно в настройках BIOS.)

· Запускайте ролью сервера Hyper-V только в корневом разделе ОС Windows®.

· Переведите все диски, которые будут настроены в качестве дисков прямого доступа гостевой виртуальной машины, в состояние отключено в корневом разделе с помощью утилиты DISKPART или диспетчера томов (Volume Manger).

· Убедитесь в том, что на гостевой виртуальной машине установлены компоненты интеграции.

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

· По возможности избегайте развертывания SQL Server на эмулированных устройствах. Такие устройства значительно сильнее нагружают ЦП по сравнению с синтетическими.

Методика тестирования и рабочие нагрузки

Был выбран ряд тестовых сценариев, на примере которых будут сформулированы рекомендации и рассмотрены вопросы производительности при запуске приложений SQL Server 2008 в среде Hyper-V. Первый набор тестовых сценариев должен позволить оценить издержки, связанные с работой в собственной среде, по сравнению со средой гостевой виртуальной машины Hyper-V. Второй набор сценариев позволит проиллюстрировать характеристики масштабирования гостевой виртуальной машины в пределах одного сервера.

Тестовые рабочие нагрузки

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

Эти сценарии предназначены для решения следующих основных задач.

· Сравнить производительность SQL Server, запущенного в корневом разделе и на гостевой виртуальной машине.

· Сравнить производительность нескольких экземпляров SQL Server, запущенных в собственной среде Windows, с производительностью нескольких экземпляров SQL Server, запущенных на нескольких гостевых виртуальных машинах.

· Оценить масштабируемость пропускной способности рабочей нагрузки SQL Server по мере роста числа гостевых виртуальных машин, запущенных в пределах одного корневого раздела.

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

Таблица 1. Рабочие нагрузки и сценарии

Рабочая нагрузка	Общие характеристики	Целевые сценарии
SQLIO	Рабочая нагрузка ввода-вывода.	· Сравнение производительности дискового ввода-вывода в собственной среде и на гостевой виртуальной машине.
Рабочая нагрузка OLTP	Рабочая нагрузка типа OLTP, моделирующая брокерское приложение, ориентированное на клиента. Дополнительные сведения о конфигурации оборудования см. в приложении 3.	· Сравнение производительности рабочей нагрузки в собственной среде, корневом разделе и на гостевой виртуальной машине. · Сравнение нескольких экземпляров SQL Server, запущенных в собственной среде Windows с несколькими гостевыми виртуальными машинами, на каждой из которых запущен один экземпляр SQL Server. · Масштабирование пропускной способности рабочей нагрузки по мере роста числа гостевых сред.
Рабочая нагрузка «построение отчетов»	Запросы, связанные с построением отчетов, потребляющие значительный объем ресурсов ЦП и ввода-вывода.	· Сравнение производительности при подготовке отчетов в собственной среде, корневом разделе и на гостевой виртуальной машине.
Рабочая нагрузка, связанная с функционированием SQL Server	Резервное копирование и восстановление, перестроение индекса, DBCC CHECKDB.	· Сравнение производительности при выполнении операций над базой данных в собственной среде, корневом разделе и на гостевой виртуальной машине.

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

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

· Рабочая нагрузка OLTP. Этот тестовый сценарий решает следующие задачи.

o Сравнивает производительность SQL Server при работе в собственной среде Windows и на гостевой виртуальной машине. Для этого сравнения собственный экземпляр и гостевая виртуальная машина были настроены с одинаковой конфигурацией оборудования.

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

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

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

§ Число физических ядер процессора равно суммарному числу логических ядер процессора всех гостевых виртуальных машин.

§ Число физических ядер процессора меньше, чем суммарное число логических ядер процессора всех гостевых виртуальных машин (так называемая «перегруженность» ресурсов ЦП).

· Рабочая нагрузка «построение отчетов». Этот сценарий сравнивает производительность экземпляра SQL Server, запущенного в собственной среде Windows, с производительностью экземпляра SQL Server, запущенного на гостевой виртуальной машине с эквивалентной конфигурацией оборудования.

· Операции с базами данных. Этот сценарий сравнивает производительность экземпляра SQL Server, запущенного в собственной среде Windows, с производительностью экземпляра SQL Server, запущенного на гостевой виртуальной машине с эквивалентной конфигурацией оборудования.

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

Наблюдение за работой SQL Server в конфигурациях Hyper-V

При наблюдении за производительностью рабочих нагрузок SQL Server в конфигурациях Hyper-V с помощью системного монитора Windows (perfmon) необходимо учитывать несколько соображений. Для точного измерения объема используемых ресурсов необходимо использовать счетчики Hyper-V, которые Windows отображает в корневом разделе. Углубленное рассмотрение особенностей наблюдения за Hyper-V выходит за рамки этого документа. Дополнительные сведения см. в приложении 3.

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

· Логический процессор гипервизора Hyper-V (Hyper-V Hypervisor Logical Processor). Представляет наиболее точные сведения о ресурсах ЦП, потребляемых физическим сервером в целом.

· Виртуальный процессор корневого раздела гипервизора Hyper-V (Hyper-V Hypervisor Root Virtual Processor). Предоставляет наиболее точную оценку ресурсов ЦП, потребляемых корневым разделом.

· Виртуальный процессор гипервизора Hyper-V (Hyper-V Hypervisor Virtual Processor). Предоставляет наиболее точную оценку ресурсов ЦП, потребляемых конкретными гостевыми виртуальными машинами.

Традиционные счетчики вида % процессорного времени могут отслеживаться в пределах корневого раздела. Однако, поскольку этим процессорным счетчикам доступны не все слои виртуализации, данные о ресурсах ЦП, отображаемые ими, могут быть неточными. При наблюдении за производительностью измеряйте уровень загрузки ЦП с помощью счетчиков Hyper-V на любом сервере, работающем под ролью Hyper-V и с включенным гипервизором. Дополнительные сведения о наблюдении за производительностью Hyper-V можно найти в блоге Тони Вельма.

На рис. 1 изображены все эти счетчики. Верхний набор счетчиков на этом рисунке (\\SQLBP08R900) отслеживает корневой раздел, а нижний набор (\\sqlhv1) — гостевую среду. Обратите внимание, что в данном примере корневому разделу видны 16 физических ядер процессора, а гостевой виртуальной машине — четыре логических ядра процессора. Заметьте также, что, хотя в корневом разделе запущены две гостевые виртуальные машины, для экономии пространства на рисунке показана только одна из них. Четыре счетчика логических процессоров второй виртуальной машины расположены вне видимой части окна с правой стороны.

Рис. 1. Счетчики системного монитора Hyper-V

Дополнительные сведения о наблюдении и связанными с ним проблемами см. в разделе руководства по оптимизации производительности Windows 2008, посвященном виртуализации, а также в блогах по счетчикам производительности Hyper-V.

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

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

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

· Если хранилище гостевой виртуальной машины настроено для прямого доступа, то на уровне корневого раздела диск считается отключенным и не влияет на показания счетчиков логических дисков в корневом разделе. Для наблюдения за производительностью дисков прямого доступа в корневом разделе необходимо использовать счетчики физических дисков. В период проведения тестов было известно о проблемах, связанных с работой счетчиков физических дисков Windows Server 2008 при использовании многопутевых решений. Эти неполадки были устранены в последнем GDR диспетчера виртуальных машин System Center.

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

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

Таблица 2. Счетчики и рабочие нагрузки

*Расположение* *счетчиков*	Счетчик	Низкая рабочая нагрузка OLTP	Средняя рабочая нагрузка OLTP	Высокая рабочая нагрузка OLTP
Гостевая виртуальная машина	Транзакций/сек	352	546	658
	Пакетов/сек	565	897	1075
	% процессорного времени	34,2	65,3	84,2
	% работы в привилегированном режиме	5,1	8	8,4
	Логические диски: среднее время чтения с диска/(сек) (_Всего)	0,005	0,006	0,007
	Логические диски: обращений чтения с диска/сек (_Всего)	1053	1597	1880
Корневой раздел	% процессорного времени	4,9	7,8	11,2
	% работы в привилегированном режиме	3,6	6,1	7,3
	Логический процессор Hyper-V: % времени выполнения гипервизора	4	4,8	4,3
	Логический процессор Hyper-V: % общего времени выполнения	39,1	68,7	86,5
	Логический процессор Hyper-V: % времени выполнения гостевой виртуальной машины	35,1	63,9	82,1
	Физические диски: среднее время чтения с диска/(сек) (_Всего)	0,005	0,006	0,006
	Физические диски: обращений чтения с диска/сек (_Всего)	1053	1597	1880
	*пакетов на* %*ЦП (Пакет/сек/% времени выполнения гостевой виртуальной машины)*	16,1	14	13,1

Примечание. Счетчики Hyper-V в корневом разделе отображают совокупные значения по всем запущенным гостевым виртуальным машинам.

Результаты тестов, наблюдения и рекомендации

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

Снижение производительности при запуске SQL Server в среде Hyper-V

Первая группа тестовых сценариев разработана для оценки снижения производительности при запуске SQL Server в «стерильной» среде Hyper-V. Базовые тесты выполнялись трижды: в собственной среде Windows с выключенным Hyper-V, в корневом разделе при включенном Hyper-V и на единственной гостевой виртуальной машине. Конфигурация оборудования была одинаковой во всех трех случаях.

Примечание. Под собственным экземпляром далее понимается экземпляр SQL Server, запущенный в собственной среде Windows, а под виртуальным экземпляром — экземпляр SQL Server, запущенный на гостевой виртуальной машине.

В этом разделе рассматриваются следующие тестовые сценарии.

· Определение с помощью SQLIO издержек на операции ввода-вывода при использовании дисков прямого доступа

· Сравнение производительности рабочей нагрузки OLTP на единственном собственном экземпляре и на виртуальном экземпляре

· Сравнение производительности запросов построения отчетов на собственном экземпляре и на виртуальном экземпляре

· Оценка влияния виртуализации на типичные операции с базой данных.

o Резервное копирование со сжатием и восстановление

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

o DBCC CHECKDB

Издержки на операции ввода-вывода при использовании дисков прямого доступа: SQLIO

Издержки на операции ввода-вывода считаются типичной проблемой виртуализированных сред. Это потенциальный камень преткновения для приложений с интенсивным вводом-выводом, таких как SQL Server. Hyper-V использует другую технологию. Вначале рассмотрим наиболее благоприятный тестовый сценарий для оценки издержек на операции ввода-вывода в наиболее оптимизированной конфигурации, использующей выделенные диски прямого доступа. Конфигурация с дисками прямого доступа была выбрана потому, что цепочка программных вызовов от сервера до подсистемы ввода-вывода в этом случае имеет наименьшую длину. В этих тестах корневому разделу и гостевой виртуальной машине было выделено равное число физических дисков (spindles). Многократное выполнение тестов с различным сочетанием операций случайного и последовательного ввода-вывода показало, что издержки на операции ввода-вывода в среде Hyper-V при использовании дисков прямого доступа отсутствуют или минимальны. Дополнительные сведения, включая подробный анализ производительности дисков прямого доступа и виртуальных жестких дисков, см. в подготавливаемом к публикации техническом документе Тони Вельма (Tony Voellm) и Ляна Яна (Liang Yang) «Производительность виртуальных жестких дисков и дисков прямого доступа в среде Windows Server 2008 Hyper-V». Дополнительные сведения о производительности хранилища Hyper-V можно также найти здесь (http://blogs.msdn.com/tvoellm/archive/2008/09/24/what-hyper-v-storage-is-best-for-you-show-me-the-numbers.aspx).

Конфигурация хранилища

В корневом разделе и на виртуальной машине использовались одинаковые конфигурации с дисками прямого доступа. Каждой из них были выделены устройства LUN из массива хранения с одним и тем же объемом физических дисковых ресурсов. Совместное использование ресурсов на дисковом уровне отсутствовало, то есть, устройства LUN не обращались к одним и тем же физическим дискам (spindles). На рис. 2 изображены обе представленные конфигурации.

Рис. 2. Конфигурация хранилища с дисками прямого доступа

Производительность конфигурации с дисками прямого доступа

Для сравнения пропускной способности на всех гостевых виртуальных машинах и в корневом разделе были выполнены одни и те же тесты SQLIO. Рис. 3 и 4 иллюстрируют результаты выполнения тестов SQLIO для операций произвольного и последовательного ввода-вывода. Для этого тестового сценария были выбраны два типичных размера SQLIO (8 КБ и 64 КБ).

Рис. 3. Произвольный ввод-вывод блоками по 8 КБ. Диски прямого доступа.

Рис. 4. Последовательный ввод-вывод блоками по 64 КБ. Диски прямого доступа.

Снижение производительности виртуальной машины: рабочая нагрузка OLTP

Задачей этого тестового сценария было измерение воздействия запуска SQL Server 2008 на виртуальной машине под рабочей нагрузкой OLTP, моделирующую работу брокерского приложения. Дополнительные сведения о конфигурации оборудования, использованной в этом тесте, см. в приложении 3. Были использованы три уровня рабочей нагрузки в основной конфигурации, корневом разделе и на гостевой виртуальной машине. Под основной конфигурацией подразумевается запуск экземпляра SQL Server на собственном сервере с выключенным Hyper-V. Для этого было выполнено отключение параметра hypervisorlaunchtype (вызовом команды bcdedit /set hypervisorlaunchtype off), для вступления в силу которого требуется перезагрузка Windows. Уровни нагрузки в этом тестовом сценарии определялись коэффициентом использования ЦП. Поскольку полная загрузка ЦП не характерна для рабочих сред, мы ориентировались на уровень нагрузки ЦП от 20 до 80 %. Коэффициенты использования ЦП для каждого уровня рабочей нагрузки показаны в таблице 3.

Таблица 3. Коэффициент использования ЦП

Тестовая рабочая нагрузка	Приблизительная загрузка ЦП
OLTP: низкая	30 %
OLTP: средняя	50 %-60 %
OLTP: высокая	80 %

Поскольку гостевые виртуальные машины Hyper-V поддерживают до 4 логических процессоров, для чистоты сравнения сервер был настроен для использования четырех ядер в настройках BIOS (NUMPROC=4). Чтобы оценить влияние конфигурации хранилища, две виртуальные машины были настроены с использованием двух типов конфигурации хранилища Hyper-V, рекомендованных для рабочей нагрузки SQL Server (диски прямого доступа и виртуальные жесткие диски фиксированного размера).

Влияние на пропускную способность и нагрузку процессора

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

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

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

Пакет / %ЦП = Пакетные запросы/сек, разделенные на коэффициент использования ЦП

Таблица 4. Издержки ЦП на виртуальной машине при запуске рабочих нагрузок OLTP

	Низкая			Средняя			Высокая
	Пак. Запр./сек	Пакет/ЦП%	Издержки	Пак. запр./сек	Пакет/ЦП%	Издержки	Пак. запр./сек	Пакет/ЦП%	Издержки
Основная конфигурация¹	566	19,2	0,00 %	908	16	0,00 %	1069	14,8	0,00 %
Корневой раздел²	566	17,5	8,85 %	907	14,8	7,50 %	1113	13,5	8,78 %
VM_PT³	565	16,1	16,15 %	897	14	12,50 %	1075	13,1	11,49 %
VM_VHD⁴	563	15,7	18,23 %	876	13,9	13,13 %	1029	13,2	10,81 %

1. Основная конфигурация: собственная среда Windows Server 2008 с выключенным Hyper-V. Переключатель виртуальной сети отключен.

2. Корневой раздел: корневой раздел Windows Server 2008 со включенным Hyper-V.

3. VM_PT: гостевая виртуальная машина, сконфигурированная для использования дисков прямого доступа, 4 логических процессоров и 14 ГБ ОЗУ.

4. VM_VHD: гостевая виртуальная машина, сконфигурированная для использования виртуальных жестких дисков фиксированного размера, 4 логических процессоров и 14 ГБ ОЗУ.

5. Издержки вычислены путем сравнения с основной конфигурацией ((Пакеты в основной конфигурации/ЦП — Пакеты на виртуальной машине/ЦП) / Пакеты в основной конфигурации/ЦП).

Рис. 5. Относительная пропускная способность: пакетные запросы в расчете на % процессорного времени

Конфигурация хранилища и производительность

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

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

Рис. 6. Тома данных (операции чтения в секунду)

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

Рис. 7. Средняя дисковая задержка

Сравнение производительности запросов, связанных с отчетами

Запросы, используемые при подготовке отчетов, как правило, выполняются очень долго, используют только операции чтения и потребляют большой объем ресурсов ЦП и ввода-вывода. По сравнению с рабочими нагрузками OLTP, запросы этого типа обычно выполняются в условиях слабой конкуренции со стороны других пользователей. В этом тестовом сценарии последовательно выполнялись четыре запроса для измерения уровня потребления ресурсов и времени исполнения. Из-за наличия статистических операций, эти запросы интенсивно использовали операции ввода-вывода и значительно нагружали ЦП. С помощью процедуры sp_configure параметру «max degree of parallelism» (максимальный уровень параллелизма) было задано значение 0, в результате чего запросы использовали все доступные ресурсы ЦП.

Разница между запуском запросов на гостевых виртуальных машинах, в собственной среде или в корневом разделе оказалась минимальной. Замечен сравнительно небольшой рост издержек производительности на гостевых виртуальных машинах. На рис. 8 показано время исполнения и потребление ресурсов ЦП для этих запросов.

Рис. 8. Производительность запросов построения отчетов

Операции с базами данных

Некоторые типичные операции с базами данных сравнительно интенсивно используют ЦП. Результаты тестов в этом разделе охватывают влияние виртуализации на такие операции с базами данных, как резервное копирование со сжатием и восстановление, перестроение индекса и DBCC CHECKDB.

Резервное копирование и восстановление

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

По сравнению с выполнением той же операции в собственной операционной системе было отмечено падение пропускной способности при резервном копировании на 10-15 % и заметный рост загрузки ЦП. Такой же уровень падения производительности был отмечен и при восстановлении резервных копий. Уменьшение пропускной способности объясняется сетевыми издержками, возникающими при активном использовании сетевых ресурсов операциями гостевой виртуальной машины. Тесты показали, что этому аспекту следует уделить наибольшее внимание при оценке издержек запуска SQL Server на гостевой виртуальной машине Hyper-V. Эти издержки оказались гораздо более значительными, чем издержки, связанные с операциями ввода-вывода и загрузкой ЦП.

В данном тестовом сценарии при выполнении операций резервного копирования и восстановления наблюдалась пропускная способность сети в интервале 50-60 МБ/с. Как на сервере с установленным экземпляром SQL Server, так и на сервере, предоставлявшем сетевую общую папку для резервных копий, был установлен один сетевой адаптер 1 ГБ/с. Пропускная способность резервного копирования и восстановления составила около 100 МБ/с. Значения взяты из выходных данных операций резервного копирования и восстановления SQL Server. При выполнении этой операции использовалось сжатие, что объясняет, почему зарегистрированная пропускная способность оказалась значительно больше максимальной пропускной способности, которую могла продемонстрировать данная сетевая конфигурация.

На рис. 9, 10 и 11 показаны результаты выполнения резервного копирования и восстановления в собственной среде, в корневом разделе и на виртуальных машинах, сконфигурированных для использования дисков прямого доступа и виртуальных жестких дисков фиксированного размера. Относительная пропускная способность по оси Y рассчитана как общее количество мегабайт в секунду, деленное на общий средний процент загрузки ЦП. Несколько более высокая пропускная способность при восстановлении может объясняться производительностью операций записи в целевую общую папку (производительность операций чтения из которой немного выше благодаря использованию RAID5).

Рис. 9. Относительная пропускная способность при операциях резервного копирования и восстановления

Рис. 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 в виртуализованной среде с перегруженными ресурсами ЦП.

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

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

На рисунке 16 показаны результаты масштабируемости по мере роста рабочей нагрузки. График по мере роста рабочей нагрузки довольно плоский, он затухает в районе 90%. Работа четырех виртуальных машин, каждая из которых имела по четыре виртуальных процессора, привела к перегрузке ЦП: ресурсы 16 виртуальных процессоров при наличии только 8 физических ядер процессора стали ограничиваться ЦП.

Hyper-V предоставляет параметры управления ресурсами ЦП на уровне виртуальной машины, которые можно использовать в таких ситуациях. Эти параметры будут рассмотрены в следующем техническом документе.

Рисунок 20. Масштабируемость четырех виртуальных машин, работающих одновременно, с перегруженным ЦП

Сравнение параметров консолидации

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

Таблица 6. Параметры консолидации

	Несколько экземпляров SQL Server	Несколько виртуальных машин
Изоляция	Общий экземпляр Windows	Выделенный экземпляр Windows
Ресурсы ЦП	Кол-во процессоров, видимое экземпляром Windows	Максимум • Windows 2008 — до 4 виртуальных процессоров • Windows 2003 — до 2 виртуальных процессоров
Память	Лимит сервера гибкий (max server memory)	Статически выделенный виртуальной машине • Только изменения в автономном режиме • Перегружать ресурсы памяти невозможно Лимит в 64 ГБ на виртуальную машину Лимит в 2 терабайта на базовый компьютер
Хранилище	Файлы данных SQL Server со стандартными параметрами хранилища	Файлы данных SQL Server с использованием дисков прямого доступа или виртуальных жестких дисков, выделенных виртуальной машине
Управление ресурсами	WSRM (уровень процесса)	Гостевая виртуальная машина Hyper-V
Кол-во экземпляров	50	Зависит от физических ресурсов компьютера
Поддержка	Применяются обычные правила	SQL Server 2008 и SQL Server 2005
Высокий уровень доступности	Применяются обычные правила	Кластеризация гостей поддерживается Зеркальное отображение базы данных, доставка журналов (поддерживается)

Заключение

С точки зрения производительности, использование Hyper-V — это хороший вариант для сценариев консолидации SQL Server. Общая производительность экземпляра SQL Server, работающего в виртуализованной среде Hyper-V, достаточно высока в сравнении с равным по параметрам экземпляром в среде Windows Server 2008.

При надлежащих пропускной способности ввода-вывода и конфигурации издержки ввода-вывода минимальны. Для обеспечения наилучшей производительности число физических процессоров должно быть достаточным для поддержки заданного на сервере числа виртуальных процессоров, чтобы их количество не превышало количества физических ресурсов ЦП. Если виртуальных процессоров больше, чем физических, то перегрузка ресурсов ЦП значительно возрастает. Важно проводить тщательное тестирование каждого приложения перед его развертыванием в среде Hyper-V.

Далее приведены некоторые общие соображения и рекомендации в отношении работы SQL Server в среде Hyper-V.

Замечания

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

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

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

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

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

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

Дополнительные сведения

· Среда Hyper-V Windows Server

· Руководство по планированию и развертыванию среды Hyper-V

· Microsoft Assessment and Planning Toolkit 3.1 для Hyper-V

· Пошаговое руководство по началу работы с Hyper-V

· Часто задаваемые вопросы по производительности Hyper-V

· Мониторинг Hyper-V (группа Windows — БЛОГ по вопросам производительности)

· Политика поддержки для установки SQL Server в средах Hyper-V

· Диспетчер виртуальных машин центра систем

Приложение 1: Архитектура Hyper-V

Hyper-V — это технология виртуализации на базе гипервизора для Windows Server 2008. Гипервизор — это платформа виртуализации, работающая в сочетании с некоторыми процессорами, позволяющая нескольким изолированным операционным системам работать на одной аппаратной платформе.

Hyper-V поддерживает изоляцию в разделах. Раздел является поддерживаемой гипервизором логической единицей изоляции, в которой выполняются операционные системы. Гипервизору Microsoft требуется как минимум один родительский, или корневой, раздел, в котором установлена 64-разрядная версия ОС Windows Server 2008. Стек виртуализации работает в родительском разделе и имеет прямой доступ к аппаратным устройствам. После этого корневой раздел создает дочерние разделы, в которых будут работать гостевые операционные системы. Дочерние разделы корневой раздел создает при помощи прикладного программного интерфейса (API) гипервызовов.

Разделы не имеют доступа к физическому процессору, и не обрабатывают его прерываний. Вместо этого, у них есть виртуальное представление процессора, а выполняются они в области адреса виртуальной памяти, которая у каждого гостевого раздела своя. Гипервизор обрабатывает прерывания процессора и перенаправляет их в соответствующий раздел. Hyper-V может также обеспечить аппаратное ускорение передачи адреса между разными пространствами адресов гостевых виртуальных машин при помощи устройства управления памятью ввода/вывода (IOMMU), которое работает независимо от аппаратных средств управления памятью, используемых ЦП. IOMMU используется для переназначения адресов физической памяти адресам, которые используются дочерними разделами.

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

Виртуальные устройства также могут пользоваться функцией виртуализации Windows Server, которая называется Enlightened IO, для подсистемы хранения, сетевой, графической подсистемы и подсистемы ввода. Enlightened IO — это специализированная реализация протоколов связи высокого уровня (например, SCSI), предназначенная для виртуализации, которая используется VMBus напрямую, в обход уровня эмуляции устройств. Благодаря этому обмен данными становится более эффективным, но для этого требуется гостевая система с такой функцией, работающая с гипервизором и VMBus. Ядро с функцией Enlightened IO, работающее с гипервизором, реализуется путем установки служб интеграции Hyper-V. Компоненты интеграции, среди которых драйверы клиента виртуального сервера, также доступны для других клиентских операционных систем. Hyper-V требуется процессор, имеющий аппаратную виртуализацию, такую, какая есть в технологии Intel VT или AMD Virtualization (AMD-V).

На следующей диаграмме представлены общие сведения о высоком уровне архитектуры среды Hyper-V, работающей на Windows Server 2008.

Общие сведения об архитектуре Hyper-V

Далее приведены определения сокращений и терминов, использованных на схеме:

 APIC — усовершенствованный программируемый контроллер прерываний — устройство, которое позволяет назначать уровень приоритета своим выходам прерываний.

 Дочерний раздел — раздел, в котором устанавливается гостевая операционная система — доступ дочернего раздела к физической памяти и всем устройствам осуществляется через шину виртуальной машины (VMBus) или гипервизор.

 Гипервызов — интерфейс для связи с гипервизором — интерфейс гипервызова включает в себя доступ к оптимизациям, предоставляемым гипервизором.

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

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

 Стек ввода-вывода — стек ввода-вывода

 MSR — подпрограмма службы памяти

 Корневой раздел — управляет функциями на уровне компьютера, например драйверами устройств, электропитанием, а также «горячим» добавлением и удалением устройств. Корневой (или родительский) раздел — это единственный раздел, имеющий прямой доступ к физической памяти и устройствам.

 VID — драйвер инфраструктуры виртуализации — предоставляет службы управления разделами, службы управления виртуальными процессорами и службы управления памятью для разделов.

 VMBus — канальный механизм связи, используемый для обмена сообщениями между разделами и перечисления устройств в системах с несколькими действующими виртуализованными разделами. VMBus устанавливается со службами виртуализации Hyper-V.

 VMMS — служба управления виртуальными машинами — отвечает за управление состоянием всех виртуальных машин, работающих в дочерних разделах.

 VMWP — процесс-исполнитель виртуальных машин — компонент пользовательского режима стека виртуализации. Процесс-исполнитель предоставляет гостевым операционным системам, установленным в дочерних разделах, службы управления виртуальными машинами из экземпляра Windows Server 2008, который работает в родительском разделе. Служба управления виртуальными машинами порождает отдельные процессы-исполнители для каждой работающей виртуальной машины.

 VSC — клиент служб виртуализации — экземпляр искусственного устройства, находящийся в дочернем разделе. Клиенты служб виртуализации используют аппаратные ресурсы, предоставляемые поставщиками служб виртуализации в родительском разделе. Они обмениваются сообщениями по VMBus с соответствующими поставщиками служб виртуализации в родительском разделе для удовлетворения запросов дочерних разделов к устройствам ввода-вывода.

 VSP — поставщик служб виртуализации — находится в корневом разделе и предоставляет поддержку искусственных устройств дочерним разделам по шине виртуальной машины (VMBus).

 WinHv — Библиотека интерфейса гипервизора Windows — по сути WinHv является мостом между драйверами разделенной операционной системы и гипервизором, который позволяет драйверам вызывать гипервизор при помощи стандартных соглашений о вызовах Windows.

 WMI — служба управления виртуальными машинами предоставляет набор API на базе инструментария управления Windows (WMI) для управления и контроля виртуальных машин.

Приложение 2. Аппаратные требования

Для Hyper-V требуются определенные аппаратные средства. Узнать, какие системы поддерживают архитектуру x64 и Hyper-V можно, выполнив поиск в каталоге Windows Server с указанием Hyper-V в качестве дополнительного условия (см. http://go.microsoft.com/fwlink/?LinkId=111228).

Для установки и использования роли Hyper-V требуется:

 Процессор с поддержкой x64. Hyper-V имеется в 64-разрядных выпусках Windows Server 2008 — а именно, в 64-разрядных выпусках Windows Server 2008 Standard, Windows Server 2008 Enterprise и Windows Server 2008 Datacenter. В 32-разрядных (x86) выпусках или Windows Server 2008 для систем на базе Itanium гипервизор Hyper-V недоступен. Однако средства управления Hyper-V могут работать в 32-разрядных выпусках.

 Аппаратная виртуализация. Она имеется в процессорах, в которых есть параметр виртуализации — а именно, в процессорах с технологией Virtualization Technology (Intel VT) или AMD Virtualization (AMD-V).

 Необходимо наличие аппаратного предотвращения выполнения данных, которое должно быть включено. В частности необходимо включить Intel XD-бит (execute disable bit) или AMD NX-бит (no execute bit).

Совет

Параметры аппаратной виртуализации и предотвращения выполнения данных имеются в BIOS. Однако имена параметров могут отличаться от приведенных здесь. Дополнительные сведения о том, поддерживает ли определенная модель процессора Hyper-V, следует узнавать у производителя компьютера. При изменении параметров для аппаратной виртуализации или предотвращения выполнения данных может потребоваться выключение и включение компьютера. Если просто перезагрузить компьютер, изменения параметров могут не примениться.

Память

Максимальный объем памяти, который можно использовать зависит от того, какая используется операционная система:

 Для Windows Server 2008 Enterprise и Windows Server 2008 Datacenter физический компьютер может иметь до 1 ТБ физической памяти, а каждая виртуальная машина на базе любого из этих выпусков может иметь до 64 ГБ памяти.

 Для Windows Server 2008 Standard физический компьютер может иметь до 32 ГБ физической памяти, а каждая виртуальная машина на базе этого выпуска может иметь до 31 ГБ памяти.

Процессоры

Среда Hyper-V поддерживается на физических компьютерах, имеющих не более 16 логических процессоров, используя RTM-версию Hyper-V. На компьютерах имеющих 64 логических процессоров поддерживается версия Hyper-V R2. Логический процессор может быть основным процессором или процессором, работающим по технологии Hyper-Threading. Одна виртуальная машина может иметь до 4 виртуальных процессоров. Однако число виртуальных процессоров, поддерживаемых гостевой операционной системой может быть и меньше. Дополнительные сведения см. в статье О виртуальных машинах и гостевых операционных системах виртуальных машин.

Далее приведены некоторые примеры поддерживаемых систем и числа имеющихся в них логических процессоров:

 Система с одним двуядерным процессором имеет 2 логических процессора.

 Система с одним четырехядерным процессором имеет 4 логических процессора.

 Система с двумя двуядерными процессорами имеет 4 логических процессора.

 Система с двумя четырехядерными процессорами имеет 8 логических процессоров.

 Система с четырьмя двуядерными процессорами имеет 8 логических процессоров.

 Система с четырьмя двуядерными процессорами и технологией Hyper-Threading имеет 16 логических процессоров.

 Система с четырьмя четырехядерными процессорами имеет 16 логических процессоров.

Сеть

Hyper-V поддерживает следующие конфигурации сетевых устройств:

 Каждая виртуальная машина может иметь до 12 виртуальных сетевых адаптеров — 8 из них могут быть сетевыми адаптерами, и 4 — унаследованными сетевыми адаптерами. Тип сетевого адаптера обеспечивает лучшую производительность, для него требуется драйвер виртуальной машины, входящий в пакеты служб интеграции.

 Каждому виртуальному сетевому адаптеру может быть присвоен статический или динамический MAC-адрес.

 Каждый виртуальный сетевой адаптер имеет встроенную поддержку виртуальной локальной сети (VLAN), ему можно присвоить уникальный канал VLAN.

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

Примечание

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

Хранилище

Hyper-V поддерживает различные варианты хранилищ. Сервер, на котором установлена среда Hyper-V, может иметь физическое хранилище следующих типов:

 Собственные жесткие диски: их можно подключать по интерфейсам Serial Advanced Technology Attachment (SATA), external Serial Advanced Technology Attachment (eSATA), Parallel Advanced Technology Attachment (PATA), Serial Attached SCSI (SAS), SCSI, USB и Firewire.

 Сети хранения данных: можно использовать технологии Internet SCSI (iSCSI), оптоволоконный канал и SAS.

 Сетевые жесткие диски:

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

 Виртуальные жесткие диски объемом до 2024 ГБ. Можно использовать виртуальные жесткие диски фиксированного размера, виртуальные жесткие диски с динамически расширяющимся размером и разностные диски.

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

 Виртуальные устройства SCSI. Каждая виртуальная машина поддерживает до 4 виртуальных контроллеров SCSI, а каждый контроллер может нести до 64 дисков. А это означает, что каждая виртуальная машина может иметь, ни много ни мало, 256 дисков SCSI.

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

 Емкость хранилища виртуальной машины. При использовании виртуальных жестких дисков каждая виртуальная машина поддерживает хранилище объемом до 512 ТБ. При использовании физических дисков это число еще больше и зависит от возможностей гостевой операционной системы.

 Моментальные снимки виртуальных машин. Hyper-V поддерживает до 50 моментальных снимков на виртуальную машину.

Примечание

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

Приложение 3. Конфигурации оборудования

Тестовая конфигурация SQL Server Hyper-V

Сервер Dell R900	Процессор	четырехъядерный процессор Interl Core 2 Quad 2,40 ГГц, шина 1066 МГц
	Кэш	Кэш L2 6 МБ
	Память	64 ГБ физической памяти
	Адаптер главной шины	Emulex 2x 4 Гб/в с двумя портами
	ОС	Windows Server 2008 с пакетом обновления 1 (SP1)
	Сеть	2 x Broadcom BCM5708C NetXtreme II GigE
Хранилище HDS AMS1000	Данные	8 x 8 дисков (4+4) (RAID 1+0)
	Журнал	4 x 4 диска (4+4) (RAID 1+0)
	Резервные копии	6 дисков (5+1) (RAID 5)
	ОС	4 x диска (1+1) (RAID 1+0)

23.12.22

Использование SQL Server в среде Hyper-V