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

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

Основным доводом, на который опираются руководители компаний, принимая решение об использовании виртуализации, является консолидация серверов. Хотя для консолидации серверов можно использовать несколько экземпляров SQL Server, данный подход не получил широкого распространения. Дополнительная информация об этой возможности приведена во врезке «SQL Server: виртуализация или использование нескольких экземпляров?». Предприятия могут задействовать консолидацию серверов для объединения мощностей нескольких физических серверов в единый высокопроизводительный сервер, в котором ресурсы каждого из составляющих серверов размещаются на отдельной виртуальной машине. Такой подход повышает коэффициент использования сервера и показатель «прибыль на инвестицию». Консолидация серверов позволяет организациям полностью задействовать свои вычислительные мощности. Кроме того, она повышает управляемость информационной системы, сокращая необходимое количество физических серверов.

Другим преимуществом виртуализации является повышение отказоустойчивости сети компании. Благодаря независимости операционной системы сервера от его аппаратной основы виртуализация обеспечивает дополнительную гибкость использования механизмов резервного копирования и аварийного восстановления. Например, для отработки отказа сервера в традиционной, привязанной к аппаратной платформе, реализации SQL Server требуется дополнительная система резервного копирования. Некоторые компании для защиты серверов на аппаратном уровне используют технологию кластеризации, однако в большинстве случаев кластерная архитектура реализуется только для самых важных серверов. Обычно для отработки аппаратных отказов требуется заменить сервер, установить на новую платформу образ системы и восстанавливать данные из последней копии — для выполнения этих операций необходимо как минимум несколько часов. Технология виртуализации может ускорить процесс восстановления, позволяя переносить копии виртуальных машин SQL Server на другую аппаратную платформу, — этот процесс занимает всего несколько секунд. Кроме того, такие службы, как Quick Migration и Live Migration, входящие в состав системы Windows Server 2008 R2, позволяют предупреждать конечных пользователей о плановом простое и минимизировать прерывания в работе служб.

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

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

Кроме того, многие ошибочно полагают, что компания Microsoft не поддерживает использование системы SQL Server в виртуальных окружениях. Это верно только для устаревших продуктов SQL Server 2005 и Virtual Server 2005. Однако ситуация изменилась с выпуском платформы виртуализации Hyper-V и системы SQL Server 2008. Microsoft поддерживает использование SQL Server на платформах Hyper-V и ESX Server, а также на любых платформах виртуализации, сертифицированных в рамках программы Microsoft Server Virtua-lization Validation Program (SVVP). Дополнительные сведения о политике компании Microsoft по поддержке использования системы SQL Server в виртуальном окружении можно найти в статье Microsoft по адресу http://support.microsoft.com/kb/956893.

Наконец, многих смущает сложная система лицензирования серверов SQL Server, развернутых на виртуальных машинах. Однако приобретение грамотно выбранных редакций Windows Server и SQL Server при использовании виртуализации позволит получить существенные преимущества при лицензировании. Дополнительная информация о лицензировании приведена во врезке «Лицензирование систем Windows Server и SQL Server при виртуализации».

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

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

  • Динамические VHD. Динамические VHD используют столько дискового пространства, сколько им требуется в данный момент, и при необходимости их объем автоматически увеличивается.
  • Фиксированные VHD. Фиксированные VHD полностью занимают дисковое пространство, выделенное им при создании.
  • Делегируемые VHD. Под делегируемым VHD подразумевается реальный дисковый носитель, установленный в хост-системе и используемый виртуальной системой.

Для тестовых серверов и серверов разработки оптимальным решением будет использование динамических VHD, так как они снижают требования к доступному дисковому пространству. Для систем SQL Server, вовлеченных в производственные операции, лучше использовать фиксированные или делегируемые VHD. Они обеспечивают более высокую производительность, так как у динамических VHD часть вычислительных мощностей расходуется на расширение объема виртуального носителя. Специалисты из команды Microsoft’s SQL Server Customer Advisory Team (SQLCAT) провели всестороннее тестирование работы системы SQL Server 2008 на платформе Hyper-V. По результатам тестирования команда SQLCAT опубликовала набор рекомендаций, одна из которых гласит, что наиболее высокую производительность при работе с платформой Hyper-V обеспечивает использование делегируемых дисков. Изучить результаты тестирования, проведенного командой SQLCAT, вы можете на сайте, пройдя по ссылке SQLCAT Whitepapers (http://sqlcat.com/whitepapers/archive/2008/10/03/running-sql-server-2008-in-a-hyper-v-environment-best-practices-and-performance-recommendations.aspx).

Мастера New Virtual Machine Wizard и New Virtual Hard Disk Wizard, входящие в состав Hyper-V, не позволяют создавать делегируемые диски. Для создания делегируемого VHD нужно открыть окно Hyper-V Manager. Щелкните правой кнопкой мыши на виртуальной машине, в которой хотите использовать делегируемый VHD, и в появившемся меню выберите нужный вам виртуальный диск. Используя переключатель Physical hard disk, выберите физический диск, который вы хотите использовать в качестве делегируемого. Физический диск может быть локальным или может быть установлен в сети SAN. Диск, выбираемый из списка, должен находиться в автономном состоянии. Пример настройки виртуальной машины, построенной на платформе Hyper-V и использующей делегируемые VHD, приведен на экране 1.

Экран 1. Настройка делегируемого VHD на платформе Hyper-V

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

Тип используемой для создания VHD системы хранения данных оказывает огромное влияние на производительность. Применение массивов SAN с поддержкой многоканальной обработки для хранения VHD обеспечивает наилучшую производительность. Массивы SAN облают высокой масштабируемостью и позволяют распределять процесс ввода/вывода между несколькими физическими дисками. В данной статье мы не будем рассматривать полную настройку системы SQL Server на использование массивов SAN. Дополнительную информацию по этой теме можно найти в статьях http://sqlmag.com/Articles/ArticleID/48486/48486.html и http://sqlmag.com/Articles/ArticleID/96555/96555.html.

Выделение виртуальных процессоров

Число виртуальных процессоров — самый значительный фактор после подсистемы ввода/вывода, влияющий на производительность виртуальной машины. Выбор количества виртуальных процессоров, выделяемых виртуальному серверу SQL Server, является достаточно простой операцией в системах, имеющих не более четырех процессорных ядер. Система Hyper-V позволяет выделить каждой виртуальной машине до четырех виртуальных процессоров. Чтобы назначить виртуальной машине несколько виртуальных процессоров, откройте окно Hyper-V Manager. Щелкните правой кнопкой мыши на виртуальной машине, выберите пункт Settings, а в появившемся меню — пункт Processor. В ниспадающем списке Number of logical processors укажите количество виртуальных процессоров, которое должна использовать данная виртуальная машина (см. экран 2).

Экран 2. Назначение количества виртуальных процессоров

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

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

CPU Cores × CPU Speed × CPU Utilization =
Total CPU

где CPU cores — количество процессоров в физическом сервере, который должен быть переведен в виртуальную среду, CPU Speed — скорость процессора, а CPU Utilization — средняя загруженность процессора. Данное вычисление необходимо провести для всех серверов, которые будут размещены на хост-сервере Hyper-V. После этого сложите полученные значения, и получите общую оценку ресурсов процессора для всех виртуальных машин:

Sum (Total CPU) = Overall CPU

Хотя в разных случаях требования могут отличаться, рекомендуется создавать резерв в 25% вычислительной мощности хост-сервера. Таким образом, необходимую вычислительную мощность хост-сервера можно определить по формуле:

Overall CPU × 125%

В идеале нужно стремиться к соотношению один к одному между количеством виртуальных процессоров и количеством физических ядер, несмотря на то что при консолидации серверов обычно достигается избыточность. Следует помнить, что добавление виртуального процессора в виртуальную машину не приведет к линейному росту производительности. Другими словами, добавление второго процессора не удвоит производительность вашей виртуальной машины. Результат будет куда скромнее. Эксперты оценивают возможное повышение производительности при добавлении виртуальных процессоров в 10–15%.

Выделение оперативной памяти виртуальной машине

Чтобы задать объем оперативной памяти для виртуального сервера SQL Server, просто создайте виртуальную машину на хост-сервере Hyper-V, выделив ей требуемый объем памяти. Если на хост-сервере объем памяти ограничен, то лучше его увеличить именно сейчас. Система Hyper-V поддерживает до 64 Гбайт памяти на каждой виртуальной машине, а хост-сервер может работать с физической памятью объемом до 1 Тбайт. Если объем памяти превышает 4 Гбайт, то для его полного использования на виртуальной машине должна быть установлена 64-разрядная операционная система. Имейте в виду, что количество активных виртуальных машин ограничено объемом физической памяти хост-сервера, которая распределяется между виртуальными машинами в соответствии с указанными объемами. Например, система с оперативной памятью объемом 32 Гбайт сможет поддерживать не более четырех виртуальных машин с объемом памяти 8 Гбайт.

Чтобы вычислить необходимый объем памяти хост-сервера, необходимо сначала прибавить 32 Мбайт (резерв для виртуализации) к объему памяти каждой виртуальной машины, после чего суммировать объемы памяти всех виртуальных машин. Вдобавок требуется создать резерв памяти для работы хост-сервера. Как показывает практика, резерва в 512 Мбайт для работы хост-сервера будет вполне достаточно. Еще 300 Мбайт памяти нужно самому гипервизору. Таким образом, для расчета объема памяти хост-сервера можно использовать следующую формулу:

Sum (VM RAM + 32MB) + 512MB + 300MB

На Web-странице Hyper-V RAM Calculator.xls (http://cid-2095eac3772c41db.skydrive.live.com/self.aspx/Public/Hyper-V%20RAM%20Calculator.xls) вы найдете книгу Excel, предоставляющую удобный механизм расчета требований к объему оперативной памяти хост-сервера. Полезно помнить, что добавление памяти в виртуальную машину позволяет повысить производительность операций ввода/вывода в ней за счет того, что система SQL Server может задействовать дополнительную память для кэширования.

Использование синтетических сетевых устройств

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

Драйверы для новых синтетических сетевых устройств входят в состав операционных систем Windows Server 2008 и Windows Server 2008 R2. Если вы используете эти системы на виртуальных машинах, драйверы синтетических устройств будут доступны по умолчанию. Однако эти драйверы не входят в состав систем Windows Server 2003 или более ранних реализаций Windows. Если в качестве гостевой системы используется платформа Windows Server 2003, вам необходимо установить пакет Hyper-V Integration Components. Пакет Integration Components включает драйверы синтетических сетевых устройств, а также усовершенствованные технологии поддержки мыши и видеокарты и средство временной синхронизации с хост-сервером. Вы можете убедиться, что используются именно синтетические устройства, подключившись к виртуальной машине и открыв консоль Device Manager. Разверните узел Network adapters и удостоверьтесь, что в нем установлено значение Microsoft VMBus Network Adapter (см. экран 3).

Экран 3. Проверка используемых драйверов сетевых устройств

Для установки пакета Integration Components откройте консоль Hyper-V Manager, щелкните правой кнопкой мыши на виртуальной машине и выберите команду Connect. В появившемся окне Virtual Machine Console в меню Action выберите пункт Insert Integration Services Setup Disk. Для перехода с одного экрана мастера на другой щелкайте мышью на кнопке Next.

Вычисление пропускной способности сетевого адаптера

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

VM NICs × NIC Speed × NIC Utilization =
NIC Requirements

где VM NICs — число активных сетевых адаптеров виртуальных машин на хост-сервере, NIC Speed — скорость сетевых интерфейсов, а NIC Utilization — средняя загрузка этих интерфейсов.

Чтобы вычислить общую пропускную способность хост-сервера, возьмите количество сетевых адаптеров, установленных на хост-сервере, и умножьте это число на их скорость по формуле:

Number of NICs × NIC speed =
Total NIC Capacity

Разделив параметр Total NIC Capacity на параметр NIC Requirements, вы получите представление о том, сколько сетевых адаптеров необходимо установить на хост-сервер. В идеале рекомендуется для каждой виртуальной машины выделять отдельный сетевой адаптер. Другой проверенный временем подход предполагает выделение дополнительного сетевого адаптера под управление хост-сервером Hyper-V. В целях повышения безопасности стоит разделять сеть управления и сеть взаимодействия виртуальных машин.

Если вы знакомы с системой ESX Server, то у вас наверняка назрел вопрос о возможности совместной работы сетевых интерфейсов. Поддержка совместной работы позволяет связать несколько сетевых адаптеров хост-сервера в один. Хотя система Hyper-V не поддерживает совместную работу сетевых интерфейсов, при покупке определенных сетевых карт вы сможете реализовать этот подход.

SQL в виртуальности

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

Майкл Оти - Редактор Windows IT Pro и президент компании TECA (Портленд, шт. Орегон), занимающейся разработкой программного обеспечения и консалтингом. mikeo@windowsitpro.com


Лицензирование систем Windows Server и SQL Server при виртуализации

Лицензирование продуктов Microsoft всегда было сложной задачей, и виртуализация систем ничуть ее не упрощает. Основное правило, которым стоит руководствоваться, заключается в том, что при лицензировании нет разницы между виртуальной машиной и физическим сервером. Хотя исключения существуют, вы должны планировать приобретение лицензий на операционные системы, устанавливаемые на виртуальные машины, серверное программное обеспечение, например систему SQL Server, и клиентские лицензии для пользователей (CAL).

Теперь об исключениях. Различные редакции системы Windows Server 2008 позволяют задействовать несколько виртуальных экземпляров без приобретения дополнительных лицензий.

  • Редакция Standard Edition позволяет использовать один виртуальный экземпляр.
  • Редакция Enterprise Edition позволяет использовать четыре виртуальных экземпляра.
  • Редакция Datacenter Edition позволяет использовать неограниченное число виртуальных экземпляров.

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

Система SQL Server предполагает три варианта лицензирования:

  • лицензия на сервер и на клиентское устройство;
  • лицензия на сервер и на пользователя;
  • лицензия на процессор.

Лицензирование по схеме «лицензия на сервер» при виртуализации выполняется достаточно просто. Для каждой виртуальной машины, на которой установлена система SQL Server, требуется серверная лицензия. Схема приобретения лицензий на клиентские устройства и пользователей для виртуальной платформы ничем не отличается от варианта с физическим сервером.

При лицензировании системы SQL Server по схеме «лицензия на процессор» вы приобретаете лицензии на виртуальные процессоры виртуальных машин, а не на физические процессоры, установленные в хост-сервере. Исключение составляет система SQL Server 2008 Enterprise Edition. Если для лицензирования этой системы вы используете вариант «лицензия на процессор» и покупаете лицензии на все физические процессоры хост-сервера, то в дальнейшем имеете право задействовать неограниченное количество виртуальных серверов SQL Server без дополнительных затрат. Информацию по лицензированию системы SQL Server можно получить, пройдя по ссылке: http://download.microsoft.com/download/1/e/6/1e68f92c-f334–4517-b610-e4dee946ef91/2008%20SQL%20Licensing%20Overview%20final.docx.