Советы по виртуализации SQL Server

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

Совет № 1. Используйте преимущества преобразования адресов второго уровня

Для поддержки таких платформ виртуализации, как VMware vSphere Server и Microsoft Hyper-V в качестве узла виртуализации необходимо использовать сервер с 64-разрядным процессором x64. Это могут быть процессоры AMD или Intel. Кроме того, для продуктов с высоким потреблением ресурсов, таких как SQL Server, крайне важно, чтобы процессор поддерживал и преобразование адресов второго уровня Second Level Address Translation (SLAT). Технология SLAT известна под разными названиями, в зависимости от производителя процессора. В Intel ее называют Extended Page Tables, в AMD - Nested Page Tables или Rapid Virtualization Indexing.

Виртуальная машина использует оперативную память узла виртуализации, и SLAT - это механизм, позволяющий процессору отображать виртуальную память, используемую виртуальной машиной, на физическую память узла виртуализации. Если это отображение не выполняется процессором, то оно должно осуществляться гипервизором. Способность процессора выполнять отображение памяти повышает производительность и масштабируемость. Исследования Microsoft показывают, что для каждой работающей виртуальной машины SLAT сокращает избыточную нагрузку на гипервизор примерно на 2 % с одновременным освобождением памяти сервера примерно на 1 Мбайт. Работа SLAT по увеличению производительности виртуальной машины можно показана на рисунке 1.

Рисунок 1. Архитектура  SLAT

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

Совет №2. Не перегружайте ваши физические процессоры

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

Платформа виртуализации в этом вопросе играет важную роль, особенно если вам необходима виртуализация SQL Server, требующая высокого уровня масштабируемости. Hyper-V в Windows Server 2008 и Windows Server 2008 R2 ограничен четырьмя виртуальными процессорами на виртуальную машину, что является определенным потолком для виртуальных экземпляров SQL Server на этих платформах. Windows Server 2012 резко поднимает этот предел до 64 виртуальных процессоров. VMware vSphere 5.0 поддерживает 32 виртуальных процессора, а более новая версия vSphere 5.1 - до 64 виртуальных процессоров. Если рабочая нагрузка на процессор в виртуализованном SQL Server очень высока, необходимо использовать Windows Server 2012 Hyper-V, vSphere 5.0 или более новые версии.

Совет №3. Используйте динамическую память

Оперативная память - один из важнейших факторов в производительности SQL Server. Это верно и для физических, и для виртуализованных экземпляров SQL Server. SQL Server задействует память для кэша внутреннего буфера и кэша процедур. Буферный кэш в основном применяется для хранения недавно использовавшихся данных, а кэш процедур содержит недавно исполненные команды T-SQL. Эти буферы позволяют SQL Server достигать высокого уровня производительности за счет выборки необходимых данных и команд из кэша, избегая выполнения операций ввода/вывода с жестким диском. SQL Server может автоматически управлять буферным кэшем и кэшем процедур и увеличивать их размер, исходя из потребностей нагрузки и размера доступной оперативной памяти. Таким образом, наличие доступной памяти является важнейшим условием для хорошей производительности SQL Server.

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

Для использования службами SQL Server преимуществ динамической памяти гостевая операционная система должна уметь распознавать "горячее" подключение памяти. Для использования динамической памяти Hyper-V на узле Hyper-V должна быть установлена система Windows Server 2008 R2 SP1 или более новая. Вдобавок гостевая операционная система, работающая на виртуальной машине, должна поддерживать "горячее" подключение памяти. Использовать динамическую память Hyper-V могут следующие гостевые операционные системы:

• Windows Server 2012;
• Windows Server 2008 R2 SP1;
• Windows Server 2008 SP2;
• Windows Server 2003 R2 SP2;
• Windows 8;
• Windows 7 SP1;
• Windows Vista with SP1.

Для использования преимуществ динамической памяти необходимо задействовать SQL Server 2008 (или более новую версию) Enterprise Edition либо редакцию Datacenter Edition версий SQL Server 2008 R2 или SQL Server 2008. Другие редакции SQL Server не обладают возможностью поддержки "горячего" подключения памяти и не могут использовать преимущества динамической памяти.

При выделении гостевой операционной системе дополнительной памяти это выглядит как "горячее" добавление физической памяти для экземпляра SQL Server. Когда SQL Server выполняет свою рабочую нагрузку, процесс sqlservr.exe запрашивает и получает память от операционной системы. Для динамического роста памяти SQL Server важны три фактора:

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

Когда рабочая нагрузка SQL Server приводит к росту требуемых ресурсов процесса sqlserver.exe, SQL Server обнаруживает добавление памяти и выделяет ресурсы в соответствии с требованиями рабочей нагрузки. SQL Server проверяет объем памяти операционной системы каждую секунду и динамически настраивает свою память в соответствии с объемом доступной памяти и значением максимального объема памяти сервера.

В статье корпорации Microsoft "Running SQL Server with Hyper-V Dynamic Memory" (msdn.microsoft.com/en-us/library/hh372970.aspx) приведен набор нагрузочных тестов, в которых сравнивались восемь виртуальных машин с SQL Server. В одном из наборов тестовая нагрузка выполнялась на восьми виртуальных машинах с 7,5 Гбайт статической памяти и на восьми виртуальных машинах с динамической памятью. В тестах с динамической памятью виртуальные машины имели 2 Гбайт начальной памяти и 12 Гбайт максимальной памяти. Нагрузка состояла в выполнении 12500 SQL-пакетов в секунду. В варианте с динамической памятью в системах было стабильное значение 7500 операций ввода/вывода в секунду, а при использовании статической памяти был стабильный уровень 12000 операций ввода/вывода в секунду. Другими словами, динамическая память обеспечивает ту же производительность, используя только 60% объема операций ввода/вывода, выполняемых со статической памятью.

На приведенном экране показаны результаты теста динамической памяти в системном мониторе.

Экран. Тесты динамической памяти

Черной линией здесь показана память буферного пула SQL Server. Зеленая линия обозначает количество операций чтения с диска в секунду. Хорошо видно, что в начале теста число операций чтения очень велико, но по мере выделения виртуальной машине дополнительной памяти SQL Server увеличивает размер буферного пула. В результате количество чтений с диска уменьшилось примерно на 50%.

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

Если доступная гостевой виртуальной машине память уменьшается из-за того, что гипервизор пытается забрать память у одной виртуальной машины и выделить ее другой, гостевая операционная система может переместить часть страниц рабочего набора SQL Server в выгружаемый пул. Это может оказать негативное влияние на производительность SQL Server. Для предотвращения такой ситуации Microsoft рекомендует использовать параметры блокировки страниц памяти SQL Server для того, чтобы память SQL Server никогда не помещалась в выгружаемый пул. Более подробную информацию об использовании динамической памяти с SQL Server можно найти в статье "Использование динамической памяти Hyper-V с SQL Server", опубликованной в Windows IT Pro/RE № 3 за 2013 год.

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

Совет №4. Используйте фиксированные или подключаемые напрямую виртуальные жесткие диски

Существует три основных типа виртуальных жестких дисков Virtual Hard Disk (VHD), используемых в виртуальной машине, независимо от выбранной платформы виртуализации (Hyper-V или vSphere). *Динамические. Начальный размер динамического VHD устанавливается равным объему информации, хранящейся в гостевой операционной системе, в дальнейшем размер VHD увеличивается в соответствии с растущими потребностями, пока не достигает установленного предела.

• Фиксированные. Размер фиксированного VHD устанавливается равным максимальному размеру.
• Разностные диски. Вначале создается некий базовый диск, который используется в качестве родительского диска. Затем вы по мере необходимости можете создавать дочерние разностные диски. Дочерние диски используют родительский диск в качестве базового, но при этом все изменения каждый дочерний диск хранит независимо от других.

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

Еще одним вариантом для хранения информации виртуальной машины является использование подключаемых напрямую (pass-through) дисков. Подключаемые напрямую диски - это альтернатива файлам VHD. Диски этого вида по сути являются разделами хранилища хост-системы, напрямую выделенными для виртуальной машины. Это хранилище может быть либо внутренним жестким диском сервера Hyper-V, либо LUN массива SAN, подключенным к серверу виртуализации. Подключаемые напрямую диски обеспечивают самый высокий уровень производительности для дисковых подсистем виртуальной машины. Однако они не обладают гибкостью фиксированных VHD. Подключаемые напрямую диски не могут быть перемещены без остановки виртуальной машины, они также не поддерживают снимки виртуальной машины.

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

Совет №5. Не используйте настройки хранилища по умолчанию

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

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

Рисунок 2. Пример архитектуры виртуального хранилища

Совет №6. Будьте сведущи в вопросах лицензирования

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

В приведенной таблице представлены базовые цены и модели лицензирования различных редакций SQL Server 2012.

Как можно заметить, редакция Enterprise лицензируется только в режиме "на ядро", в то время как новая редакция Business Edition лицензируется только "на сервер" плюс клиентские лицензии (CAL). Стандартная редакция лицензируется как "на ядро", так и в режиме "на сервер плюс CAL". Режим лицензирования SQL Server 2012 "на ядро" требует обязательной покупки не менее четырех лицензий. Можно покупать дополнительные лицензии "на ядро" пакетами по 2 лицензии. При развертывании SQL Server 2012 на виртуальной машине каждый виртуальный процессор приравнивается к ядру физического процессора. Например, если вы лицензируете стандартную редакцию SQL Server 2012 в режиме "на ядро" и устанавливаете ее на виртуальной машине с четырьмя виртуальными процессорами, вам необходимо купить четыре лицензии "на ядро". Исключение составляет случай, когда вы покупаете SQL Server 2012 Enterprise Edition и лицензируете эту редакцию на все ядра физической машины. При этом вы можете запускать неограниченное количество экземпляров SQL Serverв виртуальных машинах на данном узле виртуализации. И не важно, какая у вас платформа виртуализации - Hyper-V или vSphere.

Другим важным аспектом является переносимость лицензий. Технически вы легко можете осуществлять динамическую миграцию виртуальной машины между узлами виртуализации, однако здесь имеются лицензионные ограничения, регулирующие частоту перемещения виртуальной машины. OEM-лицензия может перемещаться только раз в 90 дней, что не очень подходит для создания динамических центров обработки данных. Для возможности более частого перемещения виртуальной машине требуется иметь лицензию, предоставляемую подпиской Software Assurance (SA). Наличие SA является необходимым условием, если вы планируете развертывание динамического центра обработки данных или частного "облака".

Виртуальная реальность

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

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

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