Производительность Hyper-V: тюнинг и мониторинг

Как известно, до определенного времени в сфере виртуализации серверов «правил бал» VMware со своим ESX. Теперь же, с выпуском Hyper-V Microsoft постепенно «наступает на пятки». Насколько успешно – вопрос, конечно, весьма спорный, учитывая, что VMware ESX существует на рынке намного дольше. Тем не менее, Hyper-V привлекает все большее и большее внимание по мере появления новых фич – таких, как Cluster Shared Volumes и Live Migration в Windows Server 2008 R2, или Dynamic Memory в готовящемся к выходу Service Pack 1.

В этой статье мы безо всякого marketing bullshit, мы поговорим о «тонкой настройке», призванной повысить производительность системы на базе Microsoft Hyper-V. Я попытаюсь рассмотреть некоторые архитектурные особенности Hyper-V, дать несколько советов о том, как можно повысить производительность, не прибегая к новым финансовым затратам, и как можно увидеть, что вообще происходит «там, внутри».

Как повысить производительность?

Разумеется, если что-то в системе начинает «подтормаживать» — то самым простым путем будет купить более мощную систему. Но это не всегда приемлемо, и не только по финансовым причинам. К примеру, замена оборудования часто сопровождается простоем системы, что не всегда допустимо. В этой части статьи мы посмотрим, как можно попытаться повысить производительность системы на базе Hyper-V без вмешательства в аппаратную часть.

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

В документации Microsoft довольно часто встречается понятие «логический процессор». Под этим термином понимают процессорные ядра. Виртуальные процессоры – это те процессоры, которые видит гостевая ОС на виртуальной машине. Допустим, у нас имеется хост с двумя процессорами Intel QuadCore Xeon, на котором запущено 10 виртуальных машин, в настройках каждой из которых установлено по два виртуальных процессора. В итоге у нас получается 8 логических процессоров и 20 виртуальных процессоров.

Сколько же процессоров назначать виртуальным машинам? Hyper-V позволяет назначить каждой виртуальной машине максимум 4 процессора. Кроме того, разные ОС могут поддерживать разное максимальное количество процессоров. В среде Hyper-V официально поддерживается Windows Server 2003, Windows Vista и Windows XP SP3 с двумя виртуальными процессорами, Windows Server 2008 R2, Windows 7, RHEL и SLES (с Linux Integration Services 2.1) – до четырех виртуальных процессоров.

Использование нескольких виртуальных процессоров может приводить к некоторому снижению производительности, но это более актуально для Windows Server 2003. При этом Windows Server 2008 R2 будет нормально работать даже с четырьмя виртуальными процессорами.

Так сколько же виртуальных машин можно запустить на одном физическом сервере? Microsoft официально поддерживает до 8 виртуальных процессоров на 1 логический процессор. При этом для наибольшей производительности рекомендуется делать не более 4 виртуальных процессоров на 1 логический.

Как же посчитать такое соотношение? Разумеется, можно «руками» пройтись по настройкам всех виртуальных машин, и посчитать виртуальные процессоры. Но что делать, если виртуальных машин много, или мы имеем дело с кластером, где виртуальные машины периодически мигрируют с одного узла на другой? Здесь поможет скрипт из одной строки на PowerShell, который я любезно позаимствую у Бена Армстронга:

write-host (@(gwmi -ns root\virtualization MSVM_Processor).count / (@(gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum).Sum) "virtual processor (s) per logical processor" -f yellow

Если вы выбираете железо – то, помимо гигагерцев и количества ядер, нужно смотреть на объем кэша L2/L3. Чем он больше – тем выше будет производительность, особенно для виртуальных машин с большими объемами памяти. Кроме того, очень желательно выбирать процессоры с поддержкой технологии преобразования адресов SLAT. В чем смысл этой технологии? Дело в том, что гостевые ОС не работают с физической памятью напрямую. Вместо этого им выделяется пространство гостевых физических адресов. При обращении к памяти гостевой ОС стек виртуализации преобразует с помощью специальной таблицы этот адрес в физический адрес страницы памяти. Это создает дополнительную нагрузку на память и на процессор. Технология SLAT позволяет осуществлять такое преобразование адресов непосредственно процессором, в результате чего накладные расходы сильно сокращаются. В некоторых случаях использование SLAT позволяет получить прирост производительности до 40%. Чтобы узнать, поддерживает ли процессор технологию SLAT – нужно глянуть в спецификацию. У AMD это может называться Rapid Virtualization Indexing (RVI) или (ранее) Nested Page Tables (NPT), у Intel — Extended Page Tables (EPT).

Память

Память – это едва ли не наиболее критичный для производительности ресурс. До недавнего времени выделение памяти для виртуальных машин вызывало некоторые затруднения. Дело в том, что память виртуальной машине выделяется «жестко», и изменить это значение можно только остановив гостевую ОС, что не всегда приемлемо. Рассчитать же точно, «сколько вешать в граммах» — зачастую не такая и простая задача, так как потребление памяти может зависеть от множества факторов. Поэтому, как правило, брали требования вендоров ПО а-ля «на 100 пользователей – 2 Гб памяти» и прибавляли (а иногда и не прибавляли) некоторый запас. Все бы ничего, но тут кроются две проблемы. Во-первых, можно ошибиться в расчетах (а вендорские требования – это «сферический конь в вакууме», они вполне могут не иметь ничего общего с реальностью) – что приведет к падению производительности. Во-вторых, если выделить виртуальной машине слишком много памяти – она будет простаивать, что по сути означает выброшенные на ветер деньги. Особенно, если виртуальных машин больше одной. С выходом Service Pack 1 для Windows Server 2008 R2 появилась новая технология – Dynamic Memory, позволяющая в режиме реального времени выделять виртуальным машинам столько памяти, сколько им нужно для работы. Dynamic Memory можно сравнить с динамическими VHD, которые увеличивают объем по мере необходимости. Но, в отличие от VHD, объем выделяемой памяти может не только увеличиваться, но и уменьшаться, позволяя отдать неиспользуемую память другим виртуальным машинам. Хотя на момент написания статьи Service Pack 1 находится в версии Release Candidate, и потому я не могу рекомендовать использовать его в продуктивных системах – я буду касаться Dynamic Memory в дальнейшем.

За распределение памяти отвечают пять параметров, из которых первые два могут быть изменены только при остановленной виртуальной машине, а другие два могут изменяться прямо «на лету»:

· Startup RAM

· Maximum RAM

· Memory Buffer

· Memory Weight

Startup RAM – это объем памяти, выделяемый виртуальной машине при запуске ОС. Microsoft рекомендует значения Startup RAM 512 Мб для Windows Server 2008, 2008 R2, Windows 7 и Vista. Для Windows Server 2003 и Windows XP рекомендуется начальное значение 128 Мб. В некоторых случаях, Startup RAM можно повысить. В частности, если используются «тяжелые» серверные приложения, стартующие вместе с гостевой ОС, и потребляющие много памяти. В частности – Exchange Server.

Maximum RAM – максимальный объем памяти, который может быть выделен виртуальной машине. Несмотря на то, что это значение может превышать объем физической памяти сервера – не обольщайтесь, это не memory overcommit, и использовать памяти больше, чем физически имеется – не получится. По умолчанию это значение равно 64 Гб, и его можно и нужно уменьшить, если необходимо ограничить «аппетит» виртуальной машины.

Memory Buffer – один из самых интересных параметров. Он позволяет выделять виртуальной машине не ровно столько памяти, сколько ей требуется, а чуть больше. То есть, если ОС и запущенные приложения потребляют 600 Мб памяти и Memory Buffer равен 20%, то виртуальной машине будет выделено 600*(1+0,2) = 720 Мб. Если нагрузка носит пиковый характер, к примеру – это сервер БД, на котором периодически выполняют сложные аналитические отчеты – то значение Memory Buffer можно увеличить. Тогда в период очередного «пика» у виртуальной машины будет достаточный объем свободной памяти, и не понадобится обращаться к файлам подкачки. Кроме того, Memory Buffer можно увеличивать, к примеру, для файловых серверов или для веб-серверов – которым нужна свободная память для файлового кэша. Тем не менее, злоупотреблять этим параметром не стоит – поскольку если одна виртуальная машина заберет себе лишнюю память – это может означать, что кому-то она не достанется, когда будет нужна.

Memory Weight – приоритет виртуальной машины при распределении памяти. В бета-версии этот параметр так и назывался «Memory Priority». До тех пор, пока на хосте имеется свободная память – этот параметр никак себя не проявляет. Но как только память заканчивается, и нужно у кого-то память отбирать, а кому-то – наоборот, добавить – тут-то и начинает работать механизм приоритетов. У тех виртуальных машин, у которых приоритет самый низкий – память будет отбираться в первую очередь. И, соответственно, на добавление памяти первыми в очереди встают виртуальные машины с наиболее высокими приоритетами. Для наиболее критичных виртуальных машин можно повысить приоритеты – и тогда при нехватке памяти у них будет самый большой шанс эту память получить. А для наименее критичных приоритет можно, наоборот, понизить – чтобы в случае чего у них можно было забрать излишек неиспользуемой памяти.

Есть еще один достаточно важный параметр – Memory Reserve. Он позволяет зарезервировать определенный объем памяти для использования хостовой ОС. Этот резерв не будет участвовать в распределении между виртуальными машинами. Изменить параметр Memory Reserve можно только через реестр (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\MemoryReserve, тип параметра REG_DWORD). Резервируемый объем задается в мегабайтах. Максимальное значение – 4096. Если указать большее значение – все равно будет выделено только 4 Гб. Microsoft считает, что если следовать Best Practices, и не запускать в хостовой ОС ничего кроме, собственно, Hyper-V – то хватит и 32 Мб, но я бы все же порекомендовал ставить 1 Гб. На всякий случай.

Дисковая подсистема

Дисковая подсистема – наиболее типичное «узкое место», и в системе виртуализации – особенно. Дело в том, что многие приложения оптимизируют работу с диском так, чтобы операции записи-чтения были по возможности последовательными. В качестве примера можно привести базы MS Exchange Server 2010. Тем не менее, при работе множества виртуальных машин поток ввода-вывода получается случайным, и эффективность всех этих оптимизаций сводится к нулю. Решить эту проблему, помимо экстенсивного наращивания мощностей подсистемы хранения данных (добавление жестких дисков в RAID-массив, установка более высокопроизводительных контроллеров, и т.п.) можно за счет использования прямого подключения дисков к виртуальным машинам вместо VHD-файлов. К примеру, для ОС можно использовать VHD, а базы данных хранить на pass-through-дисках. Несмотря на то, что Microsoft утверждает, что в Windows Server 2008 R2 производительность VHD практически идентична прямому подключению дисков – я не готов утверждать, что это полностью соответствует действительности.

Помимо этого, есть еще одна рекомендация относительно дисков. Не рекомендуется использовать в производственной среде VHD динамического объема, а так же моментальные снимки виртуальных машин (snapshots). Хотя по производительности динамические VHD не очень сильно уступают VHD фиксированного объема – возможно падение производительности при увеличении объема VHD-файла за счет фрагментации. Кроме этого, возможна ситуация, когда объем VHD не сможет увеличиться из-за недостатка дискового пространства – что тоже достаточно неприятно. Моментальные снимки не рекомендуется использовать по той же самой причине: они приводят к дроблению VHD на несколько файлов, что так же не лучшим образом может сказаться на производительности. И здесь есть опять же неприятный момент: если после удаления моментального снимка гостевая ОС будет перезагружаться – запустится операция слияния, до окончания которой гостевая ОС не запустится. Этот процесс может занять достаточно много времени. А если в процессе слияния закончится дисковое пространство – пиши «пропало». Виртуальную машину придется восстанавливать с резервной копии.

Сетевые интерфейсы

Почему-то традиционно при тюнинге производительности в первую очередь обращают внимание на процессор и память, а про сетевые интерфейсы как-то забывают. А тем не менее, сетевая подсистема вполне может стать «бутылочным горлышком». К примеру, если на виртуальных машинах запущены сервисы, генерирующие большие объемы сетевого трафика – базы данных, или файловые сервера. Помимо использования более высокопроизводительных сетевых адаптеров (1Gbps — минимум, а лучше – 10Gbps), можно с помощью виртуальных сетей разнести разные виртуальные машины по отдельным сетевым интерфейсам. Особенно, если используется iSCSI – то для iSCSI настоятельно рекомендуется использовать отдельный сетевой адаптер, а лучше – несколько. Если у вас отказоустойчивый кластер и используется Live Migration – то желательно выделить на каждом узле кластера отдельный сетевой адаптер для трафика миграции. Ну и разумеется, дешевые сетевые адаптеры SOHO-класса лучше не использовать, поскольку серверные сетевые адаптеры поддерживают такие полезные функции, как TCP Chimney Offload и Virtual Machine Queues (VMQ), позволяющие передать большую часть функций по обработке пакетов процессору сетевого адаптера.

Хостовые и гостевые ОС

Так же нужно обратить внимание на настройки ОС – как хостовой, так и гостевых. Я намеренно не буду говорить о тюнинге отдельных приложений – эта тема достойна даже не отдельной статьи, а целой книги. Причем некоторые приложения, такие, как SQL Server или Exchange Server – даже отдельных книг.

Что касается хоста. Во-первых – не рекомендуется запускать в хостовой ОС какие-либо роли и приложения. Microsoft рекомендует запускать в хостовой ОС только агенты систем управления и резервного копирования. Кроме этого, рекомендуется устанавливать ОС в режиме Server Core: это снизит потребление памяти, а так же объем обновлений, и повысит безопасность.

В гостевых ОС – во-первых, рекомендуется использовать как можно более новые версии ОС. В частности, Windows Server 2008 R2 работает в виртуальной среде намного лучше, чем Windows Server 2003. Так же необходимо следить, чтобы в гостевой ОС была установлена последняя версия служб интеграции – это тоже может влиять на производительность.

Мониторинг производительности Hyper-V

Как узнать, что производительность падает, до того, как пользователи начнут жаловаться, что у них «все тормозит»? Наилучший способ – использование счетчиков производительности. Не стоит использовать инструменты мониторинга внутри гостевой ОС – из-за особенностей архитектуры Hyper-V они не всегда могут показывать достоверную информацию. Использовать лучше всего счетчики в хостовой ОС, причем лучше всего — те, что непосредственно связаны с Hyper-V.

CPU

Счетчик Hyper-V Hypervisor Logical Processor\% Total Run Time покажет загрузку общую нагрузку на процессоры хоста. Для того, чтобы посмотреть нагрузку отдельных виртуальных машин, можно использовать счетчик Hyper-V Hypervisor Virtual Processor\% Guest Run Time. Показания этих счетчиков можно толковать следующим образом: значения ниже 75% означают, что все в порядке, выше 75% — пора задуматься, а выше 85% означают, что нужно что-то предпринимать: либо устанавливать более мощные процессоры, либо каким-то образом снижать нагрузку.

Память

На хосте нужно следить за счетчиком Hyper- V Dynamic Memory Balancer\Available Memory, который показывает объем памяти, доступной для распределения между виртуальными машинами. Для отдельных виртуальных машин есть счетчик Hyper- V Dynamic Memory VM\Physical Memory, отображающий объем памяти, фактически выделенный выбранной виртуальной машине (или нескольким – в зависимости от параметров счетчика). Кроме этого, можно обратить внимание на счетчики так называемой нагрузки (Memory Pressure). Нагрузка – это отношение объема памяти, который виртуальной машине требуется к тому объему, который был ей фактически выделен. Нагрузка измеряется в процентах, и значение должно быть ниже 80%. Значение от 80% до 100% должно заставлять задуматься, а выше 100% означает, что памяти явно недостаточно. «Среднюю температуру по больнице» показывает счетчик Hyper-V Dynamic Memory Balancer\Average Pressure, а для отдельных виртуальных машин существует счетчик Hyper-V Dynamic Memory VM\Average Pressure.

Если у вас не используется Dynamic Memory – то прежде всего нужно обратить внимание на счетчик Memory\Commited Bytes, показывающий, какая из виртуальных машин сколько памяти фактически использует из выделенных ей. Если используется менее 90% выделенной памяти – то все в порядке. Если более 90% — то нужно посмотреть, не нужно ли добавить памяти, а может, где-то есть утечка памяти, или же неправильные настройки. А может, стоит добавить виртуальной машине еще памяти. Если же у виртуальной машины остается менее 100 Мб свободной памяти – то это означает, что срочно нужно что-то предпринимать.

Диски

Здесь нужно обратить внимание на счетчик \LogicalDisk (*)\Average Disk Sec\Read / Write. Этот счетчик показывает среднее время, затраченное на операции записи/чтения. Нормальное значение – ниже 10 миллисекунд (0,010). Значения до 15мс (0,015) и выше означают, что надо обратить внимание на дисковую подсистему, а значения, превышающие 25мс (0,025) говорят о критической ситуации. Чтобы определить, какая из виртуальных машин вызывает нагрузку – есть счетчики Hyper-V Virtual IDE Controller/Read/Write Bytes / Sec, показывающий количество считываемых или записываемых байт в секунду для каждого виртуального дискового контроллера. Более того, есть счетчик Hyper- V Virtual Storage Device/Read/Write Bytes /Sec, с помощью которого можно посмотреть количество байт в секунду для отдельных виртуальных дисков.

Сеть

Для оценки общего состояния сетевых интерфейсов имеется счетчик \Network Interface (*)\OutputQueue Length. Его значение не должно превышать 1, а значения выще 2 говорят о критической ситуации. Чтобы посмотреть, кто именно генерирует нагрузки на сетевой интерфейс – имеются группы счетчиков для виртуальных коммутаторов и для отдельных виртуальных сетевых адаптеров. Для виртуальных коммутаторов существует группа Hyper-V Virtual Switch. Из этой группы два счетчика: Bytes/Sec и Packets/Sec – показывают объем трафика, проходящего через виртуальный коммутатор, соответственно – в байтах и в пакетах в секунду. Для виртуальных сетевых адаптеров существуют группы счетчиков Hyper-V Virtual Network Adapter и Hyper-V Legacy Network Adapter. В этих группах параметры Bytes Sent/Sec иBytes Received/Sec показывают объем передаваемого и принимаемого трафика в байтах в секунду.

Заключение

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

Автор: Александр Косивченко

Источник: http://itband.ru/