ГлавнаяОптимизацияОптимизация виртуальной машины hyper v

Russian Windows Virtualization Discussion Russian Windows Virtualization Discussion. Оптимизация виртуальной машины hyper v


Второе поколение виртуальных машин Hyper-V

Одним из главных нововведений в гипервизоре Windows Server 2012 R2 – возможность создавать виртуальные машины второго поколения (Generation 2).  Какова же цель разработки второго поколения виртуальных машин Hyper-V, в чем их преимущества и в каких случаях предпочтительно их использовать? В этой статье мы попробуем ответить на все эти вопросы.

В Hyper-V  на Windows Server 2012 R2 теперь поддерживаются два поколения виртуальных машин: поколение 1 (Generation 1) и поколение 2 (Generation 2). Виртуальные машины первого поколения (Generation 1) являлись единственным типом виртуальных машин, доступных  в предыдущих версиях Hyper-V. В Hyper-V на базе Windows Server 2012 R2 при создании новой виртуальной машины теперь можно указать к какому поколению будет относиться создаваемая виртуальная машина.

Исторические предпосылки разработки второго поколения виртуальных машин

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

Главная задача при создании любой виртуальной машины – создание надежной программной эмуляции физического оборудования, которое изначально проектировалось и разрабатывалось без учета возможностей виртуализации. Со временем в архитектуру  ОС и аппаратного обеспечения компьютеров вносилось все больше и больше изменений. В результате разработчикам виртуальных платформ для того, чтобы запустить ОС в среде виртуализации, приходилось прибегать к эмуляции различного  (в том числе морально устаревшего) оборудования: это BIOS, стандартные порты ввода-вывода (COM, LPT, PS/2), IDE-контроллеры,  контроллеры флоппи дисков,  контроллеры прерываний, мосты PCI-to-ISA и многое другое.

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

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

Вот каким образом могут выглядеть списки эмулируемых устройств в Device Manager на  ВМ Hyper-V:

1 поколения виртуальных машин Hyper-V:

2 поколения виртуальных машин Hyper-V:

Возможности виртуальных машин Hyper-V второго поколения

Какие же базовые изменения внесены в виртуальные машины Hyper-V Generation 2:

Совет. За данный функционал отвечает опция  Enhanced Session Mode в настройках виртуальной машины Hyper-V.

За счет отказа от эмуляции устаревших типов оборудования существенно увеличилась скорость загрузки виртуальной машины и уменьшилось время на установку гостевой ОС. В различных тестах разница в скорости загрузки и развертывания ВМ 1 и 2 поколения достигает 20% и 50% соответственно, что особенно интересно в различных VDI сценариях.

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

Требования и ограничения виртуальных машин 2 поколения

В качестве гостевых ОС в виртуальных машинах Hyper-V второго поколения поддерживаются:

Судя по всему данное ограничение связано с тем, что именно эти версии ОС поддерживают спецификацию UEFI 2.3.1 с Secure Boot.

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

2-ое поколение виртуальных машин Hyper-V в Windows Server 2012 R2 обеспечивает прирост производительности виртуальных машин, особенно на этапах установки и загрузки, обладает повышенной безопасностью, работает на UEFI и освобождено от необходимости поддержки эмуляции устаревшего оборудования.

winitpro.ru

Оптимизация работы сети в Hyper-V – Russian Windows Virtualization Discussion

Примерно с неделю назад у нас в консалтинге развелись бурные дискуссии, когда случайно был обнаружен интересный факт. Обновление драйверов сетевых карт Intel на «родительской» (host) системе Hyper-V до последней версии «родных» драйверов увеличивает производительность сети в виртуальным машинах в два раза!

Microsoft всегда рекомендовала использовать оригинальные драйверы от производителя оборудования, где это возможно — но то и дело подспудно устанавливала свои собственные версии этих драйверов через Windows Update. В случае с драйверами Intel мы наблюдаем именно такую картину. Вы можете скачать эти драйверы для вашего Windows Server 2008 x64 с сайта Intel. Если позже вам будет предложено установить «обновленные» драйверы WHQL с Windows Update — не делайте этого, а просто скройте (hide) это обновление, чтобы оно вам не докучало.

Пример: свойства сетевого адаптера с драйверами Microsoft (по умолчанию) и после установки драйверов Intel.

Помните, что Windows Server 2008 «предпочитает» подписанные (signed) драйверы от Microsoft. И программа установки Intel может просто не найти у вас оборудования, подходящего для обновления. Однако, не отчаивайтесь. Запустите установщик с ключём /s — PROVISTAx64.exe /s. Эта команда распакует файлы и сохранит их на диск в каталог C:\PF\Intel. Оттуда вы можете обновить драйвер вручную, выбрав «Update Driver» в свойствах устройства:

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

blogs.technet.microsoft.com

Настройки виртуальных процессоров в Hyper-V

Главная \ FAQ \ Настройки виртуальных процессоров в Hyper-V

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

 

 

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

Вот они, эти настройки:

Virtual Machine Reserve

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

Работает этот параметр следующим образом. Возьмем наш 4-ядерный сервер и 5 виртуальных машин, по 4 виртуальных процессора на каждой. Если установить Virtual Machine Reserve, равный 20%, то от физически имеющихся ресурсов для каждой виртуальной машины будет зарезервировано 0,2 * 4 / 4 = 20%. Это значение отобразиться в поле «Percent of total system resources». Если у сервера будет 8 ядер, то это значение будет уже другое: 0,2 * 4 / 8 = 10%.

Но вернемся к нашим баранам. Если мы запустим все 5 наших виртуальных машин, то все процессорные ресурсы будут заняты, и запустить 6ю виртуальную машину будет можно только в том случае, если Virtual Machine Reserve установлен равным 0%:

А вот теперь более интересный пример. На той же самой 4-ядерной системе создадим две виртуальных машины. Одной из них назначим 4 виртуальных процессора, и установим Virtual Machine Reserve 50%. Это значит, что наша виртуальная машина получает половину от каждого из имеющихся ядер, половину от всех системных ресурсов сервера. Запустим ее. Второй виртуальной машине дадим два виртуальных процессора и Virtual Machine Reserve 80%. Это – 40% от всех системных ресурсов. Казалось бы, 50% + 40% = 90%. То есть вторая виртуальная машина тоже должна запуститься, но на самом деле она не запустится. А все потому, что система попытается найти два ядра, от которых можно «отщипнуть» в резерв 80%, а все 4 ядра зарезервированы на 50% каждое:

Об этом ограничении нужно всегда помнить, и не «играться» с параметром Virtual Machine Reserve без насущной необходимости. Особое внимание нужно уделять при использовании кластерных решений: при сбое одного узла возможна ситуация, что часть виртуальных машин не сможет перезапуститься на доступном узле из-за недостатка ресурсов для резервирования.

Тем не менее, резервирование здесь не совсем «жесткое». Допустим, в примере с 5ю виртуальными машинами и 20% Virtual Machine Reserve все 5 виртуальных машин простаивают. Если вдруг одной из виртуальных машин потребуется больше, чем 20% доступных ресурсов – эти ресурсы будут ей предоставлены, не смотря на то, что все 100% вроде бы как зарезервированы. Дело в том, что процессорный ресурс может легко выделяться виртуальным машинам, и так же легко у них забираться. Так что, если возникнет необходимость – резервы для всех гарантируются.

Для чего можно использовать этот параметр? Главное его назначение – гарантировать ресурсы для бизнес-критичных виртуальных машин, имеющих жесткое SLA. Кроме этого, его можно использовать для искусственного ограничения на количество одновременно запущенных виртуальных машин, хотя по моему мнению – это не самое красивое решение.

Virtual Machine Limit

Этот параметр, как и предыдущий (Virtual Machine Reserve), задается в процентах от доступных виртуальной машине ресурсов. Точно так же, как и предыдущий параметр – есть поле «Percent of total system resources» — все точно так же. По умолчанию равен 0, что означает, что никаких ограничений нет, и виртуальная машина может забирать себе столько процессорных ресурсов, сколько ей необходимо и сколько доступно физически. Ненулевое значение параметра Virtual Machine Limit означает, что виртуальная машина ни при каких условиях не сможет использовать больше процессорных ресурсов, чем разрешено. Единственное применение этого параметра – ограничить «аппетит» виртуальной машины, если используются приложения, которые слишком сильно нагружают процессор.

Так же, как и Virtual Machine Reserve, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% — то она получит два виртуальных процессора, каждый из которых ограничивается 50%.

Но есть одно небольшое отличие: лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено. Кроме этого, лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 2 процессорами и установлен лимит 50% — то она получит два виртуальных процессора, каждый из которых лимитирован 50%.

Relative Weight

Третий параметр, о котором я хотел бы рассказать – Relative Weight. В отличие от предыдущих этот параметр – безразмерная величина, и может изменяться от 0 до 10000. По умолчанию равен 100.

До тех пор, пока у сервера имеются свободные системные ресурсы – параметр Relative Weight не проявляет себя абсолютно никак. Будь значение веса хоть 100, хоть 200, хоть 10000 – на работе виртуальных машин это не отразится. Но как только виртуальные машины начинают запрашивать больше процессорных ресурсов, чем сервер готов предоставить физически – тут-то и начинается самое интересное. Если у всех виртуальных машин значение этого параметра одинаково (к примеру, у всех 100) – то каждая из них получит равную долю процессорного ресура. А вот если у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они «равнее, чем другие», и они получат больше процессорного ресурса, чем остальные. А если есть виртуальные машины с еще более высокими значениями этого параметра – то они получат еще больше. Этот параметр хорош тем, что позволяет выделять более критичные виртуальные машины, при этом не боясь, что какая-то из виртуальных машин откажется запускаться, и придется менять настройки еще и для нее. Но есть один небольшой нюанс: Relative Weight вовсе не дает гарантий, что виртуальная машина в трудную минуту получит ровно столько процессорных ресурсов, сколько ей нужно. Если какие-то из виртуальных машин являются особо критичными, и на них распространяются жесткие SLA – лучше использовать Virtual Machine Reserve, который гарантирует выделение ресурсов.

Если систему обслуживают несколько администраторов – то необходимо договориться о единой шкале для параметра Relative Weight. В частности, если один будет ставить для некритичныхвиртуальных машин значение 100, для критичных 200, а другой будет ставить 500 для некритичных и 1000 для критичных – система может повести себя немного непредсказуемо. Но это уже вопрос стандартизации, и в более-менее сложных системах, которые управляются более чем одним администратором – такие договоренности должны быть a priori.

Оригинал статьи http://itband.ru/2011/03/hyper-v-vcpu/

statusspb.com

Настройка ресурсов процессора виртуальной машины Hyper-V

Откройте Hyper-V Manager, а затем щелкните правой кнопкой мыши на виртуальной машине. Выберите команду «Настройка» контекстного меню. Откроется окно настроек виртуальной машины. Имейте в виду, что параметры не будут доступны, если виртуальная машина не остановлена.

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

Первый параметр Number of logical processors позволяет выбрать количество логических процессоров доступных виртуальной машине.  Логические процессоры равно числу физических ядер, установленных на машине. Например, сервер, который я использовал, имеет четырех ядерный процессор. В таком случае, я имею возможность назначения 1, 2 или 4 логических процессоров в виртуальной машине. В данном конкретном случае я использую один логический процессор на виртуальную машину, даже если бы машина могла бы извлечь выгоду из наличия нескольких логических процессоров:). Причина почему я делаю это потому, что данный сервер несет на себе три отдельных виртуальных машинах. Ограничивая каждой виртуальной машине с помощью одного логического процессора, я  резервирую одно ядро для операционной системы управляюшей Hyper-V, и по одному для каждой из виртуальных машин.

Следующий параметр Virtual Machine Reserve — резервирует процессорную мощность для виртуалки (позволяет  забронировать в процентах от общей процессорной мощности машина ресурсы для данной виртуальной машины). Параметр удобен, если у вас есть виртуальная машина  с интенсивным использованием ресурсов, а второй виртуалке вы хотите обеспечить по крайней мере минимальный уровень постоянно доступных ресурсов процессора. У меня параметр Virtual Machine Reserve установлен в ноль.  Я не резервирую ресурсы процессора для виртуальной машины.

Следующий параметр Virtual Machine Limit — устанавливает в процентах предел использования процессорной мощности.  Этот параметр по сути противоположен Virtual Machine Reserve. Вместо того, гарантирования минимального объема ресурсов процессора, эта настройка не позволяет виртуальной машине использовать чрезмерное количество доступных ресурсов процессора. У меня Virtual Machine Limit установлен в 100.  Под этим параметром в процентах (от общего объема ресурсов системы) показано кол-во доступных для виртуальной машины ресурсов процесора 25.  Вроде бы странно потому что в настройки виртуальной машины разрешено использовать до 100% . А всё из-за того что существует четыре логических процессоров в машине, 25% составляет 100%-тное использование одного логического процессора от общего числа процессоров машины.

Relative Weight параметр — установка относительного веса. Идея является в том, что виртуальные машины с более высоким относительным весом получать больше процессорного времени, а также виртуальные машины с меньшим относительным весом получают меньше процессорного времени. По умолчанию все виртуальные машины присваивается относительный вес 100 для предотвращения любой виртуальной машины от получения льгот.

helpers.com.ua

Настройка виртуальных процессоров в Hyper-V

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

В качестве подопытного возьмем сервер с двумя шестиядерными процессорами Xeon, что с учетом Hyper-threading дает нам 24 виртуальных процессора. Операционная система — Windows Server 2012.

Открываем оснастку Hyper-V Manager и заходим в настройки виртуальной машины, на вкладку Processor. Обратите внимание на параметр Percent of total system resources — он показывает, какой  процент от общей процессорной мощности выделен конкретно этой виртуальной машине. В нашем случае это 1/24 = 4% . Если выделить машине второй процессор, то получим 8%, третий — 12% и т.д.  Таким способом мы управляем распределением процессорных ресурсов между виртуальными машинами.

 

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

На случай нехватки ресурсов есть дополнительные настройки, объединенные под общим названием Resource control.  О них стоит рассказать поподробнее.

Virtual Machine Reserve

Этот параметр задает процент ресурсов, который будет зарезервирован за виртуальной машиной. Этот параметр играет роль в ситуации нехватки ресурсов,  то есть когда физические процессоры используются на все 100%. В этом случае те из виртуальных машин, у которых задан этот параметр, должны гарантированно получить то, что за ними зарезервировано. По умолчанию Virtual Machine Reserve не задан и имеет значение 0%.

Работает этот параметр следующим образом. Возьмем виртуальную машину, выделим ей 2 виртуальных процессора и установим Virtual Machine Reserve равным 100. Это значит, что от физически имеющихся ресурсов этой виртуальной машине зарезервировано 100 % от 2 ядер, или  8% от общей процессорной мощности. Это значение отображается в поле «Percent of total system resources».

 

Регулировать резерв можно как через Virtual Machine Reserve, так и изменяя количество виртуальных ядер. Например, те же 8% можно получить при 8 ядрах по 25% каждое.

 

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

Параметр Virtual Machine Reserve вступает в дело только в ситуации нехватки системных ресурсов. Основное его назначение – гарантировать бесперебойную работу особо критичных виртуальных машин.

Virtual Machine Limit

Этот параметр похож на предыдущий — он так же задается в процентах от доступных виртуальной машине ресурсов и у него есть  поле «Percent of total system resources». По умолчанию лимит не задан, и виртуалка при необходимости сможет забрать себе все свободные ресурсы процессора. Задавая значение Virtual Machine Limit мы говорим, что виртуальная машина не при каких условиях не должна использовать больше процессорных ресурсов, чем ей разрешено. Назначение этого параметра одно – ограничить «аппетиты» виртуальной машины, если на ней используются тяжелые, нагружающие процессор приложения.

Лимит применяется отдельно к каждому виртуальному процессору. К примеру, если виртуальная машина сконфигурирована с 4 процессорами и установлен лимит 50% — то она получит четыре виртуальных процессора, каждый из которых ограничивается 50%.

 

Обратите внимание, что в отличие от резервирования лимит задается жестко. Если Virtual Machine Limit равен 50% — виртуальная машина никогда не сможет использовать больше, даже если на сервере больше ничего не запущено.

Relative Weight

Третий параметр, Relative Weight, представляет из себя безразмерную величину и может варьироваться в пределах от 0 до 10000. По умолчанию равен 100.

С помощью Relative Weight мы можем задать приоритет виртуальной машины при распределении ресурсов. До тех пор, пока у сервера имеются свободные системные ресурсы – значение Relative Weight не имеет особого значения. Будь у машины вес хоть 100, хоть 10000 – на ее работе это никак не отразится. Но как только ресурсы сервера подходят к концу — начинается самое интересное. Если виртуальные машины имеют одинаковый вес (к примеру, у всех 100), то каждая из них получит равную долю процессорного ресура. Если же у одной или нескольких виртуальных машин Relative Weight выше – это значит, что они получат больше процессорного ресурса, чем остальные.  Причем, чем больше вес, тем выше приоритет и тем больше ресурсов может получить виртуальная машина.

Таким образом Relative Weight позволяет разделять  виртуальные машины на более и менее критичные, при этом не боясь, что какая-то из них откажется запускаться из за отсутствия ресурсов.

 

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

 

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

windowsnotes.ru

Hyper-V и производительность. Часть 1 — как тестировать? – Russian Windows Virtualization Discussion

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

Шаг 1. Установите компоненты интеграции. Integration Components — это такой же важный элемент работы виртуальной машины Hyper-V, как Virtual Machine Additions в Virtual Server 2005. Установка компонентов интеграции увеличивает производительность на десятки, а иногда и на сотни процентов. Поэтому прежде всего убедитесь, что у вас установлены компоненты интеграции. Есть несколько способов сделать это. Один из способов — подключить виртуальный диск к контроллеру SCSI вашей ВМ. Виртуальный контроллер SCSI использует шину VMBus, и если компоненты интеграции не установлены или работают некорректно, то вы не увидите подключенного диска.

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

Втором способом проверки наличия установленных компонентов интеграции будет просто открыть Диспетчер устройств и проверить наличие шины VMBus и устройств, ассоциированных с Hyper-V. Их список может отличаться в зависимости от версии и языка ОС, а также версии самих компонентов интеграции. Также в Диспетчере устройств вы сможете изучить свойства драйвера шины VMBus, чтобы узнать версию установленных компонентов интеграции. Убедитесь в том, что версия компонентов интеграции и самого Hyper-V на сервере совпадают. Подробнее о версиях смотрите «Версии Hyper-V».

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

Шаг 3. Не используйте VMConnect для соединения с тестируемой машиной. Если вы установили соединение с виртуальной машиной из Hyper-V Manager — у вас открылось окно утилиты VMConnect, через которое вы получаете доступ к ее консоли. Даже если затем вы перехватите сессию используя «Удаленный рабочий стол» — окно VMConnect все равно будет отображать заблокированную консольную сессию гостевой ОС, потребляя ресурсы. Для задач тестирования пользуйтесь только «Удаленным рабочи столом», а не VMConnect. Вы же не будете постоянно держать консоль открытой после внедрения. Если тестирование происходит автоматически и не требует вашего вмешательства, то и «Удаленный рабочий стол» следует свернуть или закрыть. Для получения максимальных результатов запускайте задачи на тестируемой ВМ удаленно при помощи утилиты PsExec.

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

blogs.technet.microsoft.com

рекомендации ведущих собаководов / Хабр

Прежде, чем строить инфраструктуру на базе виртуализации, и, тем более – вводить ее в промышленную эксплуатацию, необходимо позаботиться о том, чтобы ресурсы системы использовались наиболее эффективно, и производительность была максимальной. В этом цикле статей я дам рекомендации о том, как оптимизировать систему по производительности – как со стороны хоста, так и со стороны виртуальных машин.
Начнем с хоста
Поскольку сервера, хостящие виртуальные машины, достаточно часто работают на пиковых нагрузках – производительность таких серверов имеет решающее значение для производительности всей системы. Потенциальными «узкими местами» могут являться: Здесь я расскажу, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.
Процессор – сердце компьютера
«Сердцем» любого компьютера является процессор. И правильность выбора процессора в контексте виртуализации – становится еще важнее. Процессор – самая дорогая часть любого компьютера, и выбор слишком мощного процессора может привести к лишним затратам не только на покупку самого процессора, но и в дальнейшем – на электроэнергию и охлаждение. Если же процессор будет недостаточно мощным – система не сможет обеспечить необходимую производительность, что может вылиться в покупку нового процессора – и, следовательно, опять затраты. Нам необходимо получить ответы на следующие ключевые вопросы: Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в Failover-кластер – и можно получить более высокопроизводительное и отказоустойчивое решение. Но с другой стороны, при таких делах… Появляется множество новых затрат:
  1. Требуется больше лицензий на ПО – как на сами ОС, так и на ПО управления (SCVMM, SCCM, SCOM, etc.)
  2. Возрастают затраты на администрирование – три сервера вместо одного
  3. Три сервера потребляют больше энергии, а значит – выделяют больше тепла, и занимают больше места в стойке, чем один сервер, пусть и более мощный.
После этого может оказаться, что лучше будет использовать четырехпроцессорный сервер, который может и будет стоить чуть дороже, и будет менее отказоустойчив – вместе со всеми накладными расходами может оказаться все же дешевле. Тем не менее, производительность системы в целом может зависеть не только и не столько от процессоров. Возьмем, для примера, СУБД. В некоторых случаях требования к процессору могут быть не слишком высокими, зато дисковая подсистема может использоваться очень активно. А если в этой СУБД активно используется бизнес-логика и аналитика (OLAP, отчеты) – то наоборот, требования к процессору и памяти могут быть намного выше, чем к дисковой подсистеме. Чтобы определить, является ли процессор «узким местом» в системе – нужно узнать, насколько сильно он загружен. Для этого могут использоваться разные системные утилиты. К примеру, многие системные администраторы привыкли пользоваться стандартным Windows Task Manager. К сожалению, из-за особенностей архитектуры Hyper-V этот самый Task Manager покажет не погоду в Гондурасе, и не курс зимбабвийского доллара, но всего-лишь навсего загрузку процессора хостовой ОС. Виртуальные машины при этом учитываться не будут – поскольку хостовая ОС, точно так же, как и все виртуальные машины – работает в своем изолированном разделе. Поэтому нужно использовать оснастку Perfmon. Многие администраторы, особенно те, кто сдавал экзамены MCSA, об этой утилите знают. Для тех, кто все же не знает – запускается она достаточно легко: Start – Administrative Tools – Reliability and Performance. Из этой оснастки нам нужна ветка Monitoring Tools – Performance Monitor. С помощью этой утилиты можно видеть значения практически любых системных параметров, а так же наблюдать их изменение на графике. По умолчанию добавлен всего один параметр (в терминах Perfmon – «счетчик» или «counter») – «% Processor Time». Этот счетчик показывает то же самое, что и Task Manager – загрузку процессора хостовой ОС. Поэтому этот счетчик можно удалить. Перейдем к добавлению счетчиков. В Perfmon имеется множество счетчиков, связанных с Hyper-V. Из них нас на данный момент интересуют два:Примечание: Что же такое логический процессор? Проще всего это понять на примерах. Допустим, если у вас есть один процессор с одним ядром – у вас будет один логический процессор. Если процессор будет двухъядерным – то логических процессоров станет уже два. А если он будет поддерживать Hyper-Threading – то их будет уже четыре. Эти два счетчика помогут получить реальную картину загрузки процессоров хоста. Значения счетчиков измеряются в процентах, а, соответственно, чем они ближе к 100% — тем выше нагрузка процессора, и, возможно, стоит подумать о покупке дополнительных или новых, более мощных процессоров.
Памяти много не бывает
Мощный процессор – это хорошо, но при недостатке памяти система начинает использовать файлы подкачки, и производительность начинает падать едва ли не экспоненциально. Как говорят в интернете – «512 мегабайт – это не память, это маразм». К сожалению (а скорее всего – к счастью) в Hyper-V невозможно выделить виртуальным машинам больше памяти, чем физически присутствует в системе. Это то, что называют «memory overcommit», и чем с такой радостью играет маркетинг других вендоров решений виртуализации. Хорошо это или плохо – это тема отдельной статьи, и об эту тему было сломано уже не мало виртуальных копий. В связи с этим возникает вопрос: а сколько памяти нам в итоге необходимо? Ответ зависит от разных факторов: Как же нам посмотреть, что происходит с памятью? К счастью, можно посмотреть через любимый Task Manager – в отличие от загрузки процессора, он покажет использование памяти достаточно правдиво. А можно (и даже нужно) прибегнуть к уже знакомому Perfmon и его счетчикам Memory/Available Mbytes и Memory/Pages/Sec.
Жесткие диски: сколько их надо?
Как правило, достаточно трудно предсказать, сколько дискового пространства потребуется виртуальным машинам для работы. И потому ситуации, когда дискового пространства не хватает, или же наоборот – когда его слишком много и диски простаивают – встречаются довольно часто. Помимо объема, есть еще одна очень важная характеристика – быстродействие дисковой подсистемы. 2 Тб дискового пространства – это конечно же хорошо, но если это два SATA-диска, не объединенных в RAID-массив – то пропускной способности может попросту не хватить, и это сильно скажется на быстродействии системы. Планирование подсистемы хранения данных включает в себя следующие аспекты: Контроллеры. Контроллеры жестких дисков могут иметь разную разрядность шины, разный объем кэш-памяти, и вообще их быстродействие может сильно различаться. Некоторые контроллеры являются полностью «аппаратными», то есть обрабатывают все запросы самостоятельно, а некоторые – «полусофтовые», то есть часть обработки запросов выполняет процессор самого компьютера. От типа контроллера в первую очередь зависит быстродействие дисковой подсистемы, и выбирать контроллер нужно грамотно. Тип дисков. Жесткие диски, помимо объема, имеют множество других характеристик, о которых нельзя забывать. Это и тип интерфейса (IDE, SATA, SCSI, SAS), и скорость вращения шпинделя (7200, 10000, 15000 об/мин), и объем кэш-памяти самого жесткого диска. Разница, к примеру, между диском на 7200 и 10000, а тем более – 15000 об/мин, или между 8 и 32 Мб кэш-памяти – для таких высоконагруженных систем, как хосты виртуализации – достаточно высока. Количество дисков и тип RAID-массива. Как уже было сказано, иногда, для достижения более высокой производительности, и надежности, наилучшим решением станет не установка одного диска большого объема, а объединение нескольких дисков меньшего объема в RAID-массив. Есть несколько типов RAID-массивов: Как видно, выбор дисков – достаточно непростая задача, поэтому выбирать нужно, исходя не только из требований к дисковому пространству, но и требований к производительности, и разумеется – из выделенных бюджетов. Иногда будет более оправданно использование внешней системы хранения данных, к примеру – когда речь идет о больших объемах и/или высокой производительности, которые невозможно достичь, используя внутренние диски. А когда планируется инфраструктура с высокой отказоустойчивостью – то тут уж точно никуда не деться от внешней СХД. Внешние СХД нужно выбирать, руководствуясь теми же принципами, что и внутренние диски: пропускная способность интерфейсов, количество дисков, тип дисков, поддерживаемые RAID-массивы, дополнительные функции – такие, как изменение объемов виртуальных дисков (LUN’ов) «на лету», возможность использования моментальных снимков (snapshots), и т.д. А что же насчет измерений? Есть несколько счетчиков, связанных с производительностью дисковой подсистемы. Интерес представляют следующие: Эти счетчики показывают, какой процент времени идет чтение, запись на диск и, соответственно – процент простоя. Если их значения поднимаются выше 75% на длительные промежутки времени – это значит, что производительность дисковой подсистемы недостаточно высока. Кроме этого, есть еще два счетчика: Эти два счетчика показывают среднюю длину очереди диска – соответственно, на чтение и на запись. Высокие значения этих параметров (выше 2) на небольшие промежутки времени («пики») вполне допустимы, и, к примеру, для СУБД или серверов MS Exchange вполне характерны, но длительные превышения говорят о том, что дисковая подсистема, вероятно, является «узким местом».
Сетевая подсистема
Сетевая подсистема бывает «узким местом» намного реже, чем процессор, память и жесткий диск, но тем не менее – о ней не стоит забывать. Как и со всеми остальными компонентами – имеется несколько вопросов, на которые неплохо было бы получить ответы еще на этапе планирования: В зависимости от ответов возможны разные сценарии настройки сетевой подсистемы. Предположим, что у нас есть всего один сервер. Сетевых интерфейсов у него ровно 4. Запущено всего три виртуальных машины. Out-of-band-management-контроллера у сервера нет, а значит – если случится что плохое – придется бежать в серверную (которая находится на другом конце города). На уровне хоста Для серверов, у которых нет аппаратных средств удаленного управления рекомендуется один из сетевых интерфейсов оставлять незадействованным в виртуальных сетях, исключительно для задач управления. Это сильно снизит риск ситуации, когда при чрезмерной утилизации или же из-за неправильных настроек сетевого интерфейса пропадает возможность удаленного управления сервером. Сделать это можно либо на этапе инсталляции роли Hyper-V, сняв галочку с одного из сетевых интерфейсов, либо же после инсталляции – удалив виртуальную сеть, привязанную к сетевому интерфейсу, который будет использоваться для управления. Кроме этого, на уровне хоста прямо таки необходимо установить как можно более «свежие» драйверы для сетевых адаптеров. Это нужно для того, чтобы воспользоваться специальными функциями сетевых адаптеров – VLAN, Teaming, TCP Offloading, VMQ (при условии, что сами сетевые адаптеры это поддерживают – как правило, это специализированные серверные сетевые адаптеры). Сетевые нагрузки Предположим, что наши три виртуальные машины какое-то время уже поработали, и анализ трафика показал, что две из них не особо сильно нагружают сетевой интерфейс, а вот третья генерирует очень большие объемы трафика. Наилучшим решением будет «выпустить в мир» виртуальную машину, генерирующую большой объем трафика, через отдельный сетевой интерфейс. Для этого можно создать две виртуальные сети типа External: одну – для тех виртуальных машин, которые не нагружают сеть, и отдельную – для третьей виртуальной машины. Кроме этого, можно создавать виртуальную сеть с выходом «наружу», при этом не создавая виртуальный сетевой адаптер в родительской партиции. Делается это с помощью скриптов. В подробности я вдаваться не буду, а просто дам ссылку: blogs.msdn.com/b/robertvi/archive/2008/08/27/howto-create-a-virtual-swich-for-external-without-creating-a-virtual-nic-on-the-root.aspxiSCSI Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.VLAN-тегирование VLAN-тегирование (IEEE 802.1q) означает «маркировку» сетевых пакетов специальным маркером (тегом), благодаря которому пакет может быть ассоциирован с определенной виртуальной сетью (VLAN). При этом хосты, принадлежащие к разным VLAN, будут находиться в разных широковещательных доменах, хотя и подключаться физически к одному и тому же оборудованию. Виртуальные сетевые адаптеры в Hyper-V так же поддерживают тегирование VLAN. Для этого нужно зайти в свойства виртуального адаптера в настройках виртуальной машины и прописать там соответствующий VLAN ID.Активное оборудование До сих пор мы говорили о сетевых интерфейсах и виртуальных сетевых адаптерах в пределах хоста. Но необходимо так же учитывать и пропускную способность активного оборудования – к примеру, коммутаторов, к которым наши хосты будут подключаться. Простой пример: если имеется 8-портовый коммутатор 1Gbps, и каждый из портов утилизирует весь 1Gbps пропускной способности – то 1Gbps-аплинк физически не сможет пропускать такие объемы трафика, что приведет к падению производительности. Особенно это приходится учитывать при использовании iSCSI – нагрузки там могут быть высоки, а задержки пакетов могут быть достаточно критичны для производительности. Поэтому при использовании iSCSI крайне рекомендуется пускать iSCSI-трафик через отдельные коммутаторы.
Рекомендации для хостовой ОС
Теперь перейдем к рекомендациям по ОС хоста. Как известно, ОС Windows Server 2008 R2 может быть установлена в двух разных режимах: Full и Server Core. С точки зрения работы гипервизора эти режимы ничем не отличаются. Хотя режим Server Core на первый взгляд кажется сложнее (особенно для малоопытных администраторов), рекомендуется использовать именно этот режим. Установка ОС в режиме Server Core имеет следующие преимущества по сравнению с полной установкой:Запуск других приложений в хостовой ОС Запуск в гостевой ОС сторонних (не имеющих отношения к Hyper-V) приложений, а так же установка других серверных ролей помимо Hyper-V может привести к сильному падению производительности, а так же к снижению стабильности. Дело в том, что из-за особенностей архитектуры Hyper-V, все взаимодействие виртуальных машин с устройствами проходит через родительскую партицию. Поэтому высокие нагрузки или «падение в синий экран» в родительской партиции обязательно приведут к падению производительности или просто к «падению» всех запущенных виртуальных машин. Сюда же можно (и нужно) отнести антивирусное ПО. Нужно ли оно вообще на хосте, который не будет заниматься ничем, кроме, собственно, виртуализации – это, конечно, тот еще вопрос. Тем не менее, если антивирус все же установлен – первое, что необходимо сделать – исключить из списка проверки все папки, где могут находиться файлы виртуальных машин. В противном случае, при сканировании может замедлиться производительность, а если в каком-нибудь VHD-файле обнаружится что-то похожее на вирус – то при попытке лечения антивирусный пакет может испортить сам VHD. Подобные случаи наблюдались и с базами MS Exchange, и потому первая рекомендация – не ставить вообще на серверах Exchange файловые антивирусы, а если и ставить – то добавить папки с базами в исключения.
Рекомендации для виртуальных машин
Шаги, которые необходимы предпринять для повышения производительности самих виртуальных машин – зависят от приложений, которые будут на них выполняться. У Microsoft имеются рекомендации (best practices) для каждого из приложений – Exchange, SQL Server, IIS, и других. Аналогичные рекомендации существуют для ПО других вендоров. Здесь я дам лишь общие рекомендации, не зависящие от конкретного ПО. Здесь будет рассказано, почему нужно устанавливать Integration Services в гостевой ОС, как упростить развертывание новых виртуальных машин с помощью библиотеки VHD, и как поддерживать эти VHD в актуальном состоянии с выпуском новых патчей.
Сервисы интеграции
Сервисы интеграции – это набор драйверов, работающих внутри гостевой ОС. Они должны быть установлены сразу после установки ОС. На данный момент список поддерживаемых ОС следующий: ОС Windows 7 и Windows Server 2008 R2 содержат сервисы интеграции в инсталляционном пакете, поэтому на эти ОС их не нужно устанавливать дополнительно. Установка интеграционных сервисов позволяет использовать синтетические устройства, имеющие более высокую производительность по сравнению с эмулируемых. Подробнее о разнице между эмулируемыми и синтетическими устройствами – в моей статье об архитектуре Hyper-V. Вот список драйверов, входящих в Integration Services: Помимо перечисленных драйверов, при установке сервисов интеграции поддерживаются следующие функции: Для установки интеграционных сервисов в ОС Windows нужно выбрать Action – Integration Services Setup. При этом к виртуальной машине автоматически подмонтируется ISO-образ с файлами установки, и запустится процесс инсталляции. Если в гостевой системе отключен запуск Autorun, то процесс инсталляции придется запустить вручную. Интеграционные компоненты для Linux не включены в дистрибутив Windows Server – их необходимо загрузить с сайта Microsoft.
Sysprep: создаем мастер-образ
Если у вас имеется достаточно большая инфраструктура, и вам приходится часто создавать новые виртуальные машины и устанавливать на них ОС –набор готовых «мастер-образов» виртуальных жестких дисков поможет сильно сэкономить время. Такой «мастер-образ», хранящийся в виде VHD-файла, можно скопировать, а затем создать новую виртуальную машину с использованием VHD в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции). Для создания такого мастер-образа необходимо:
  1. Создать новую виртуальную машину
  2. Произвести установку ОС, сервисов интеграции, всех доступных обновлений системы и дополнительного ПО, если таковое необходимо
  3. Подготовить установленную ОС с помощью утилиты Sysprep, которая удалит информацию о пользователе, ключе продукта и уникальный идентификатор (SID).
При первой загрузке виртуальной машины с такого образа запустится процедура, именуемая «mini-setup». При этом будет предложено заново ввести имя компьютера, пароль администратора, и некоторые другие данные.
Оффлайн-установка обновлений
Мы создали мастер-образ, и он будет храниться у нас в течение длительного времени. И все бы ничего, но есть одна небольшая проблема: периодически выходят обновления системы, и при развертывании виртуальной машины с мастер-образа придется установить все обновления, вышедшие с момента создания мастер-образа. Если образ был создан, скажем, год или два тому назад – объем обновлений может быть достаточно большим. Кроме того, сразу после подключения к сети ОС без последних обновлений подвержена всевозможным угрозам безопасности, в том числе – и вирусам. Есть прекрасный инструмент, позволяющий устанавливать обновления прямо на мастер-образы виртуальных машин – он называется «Offline Virtual Machine Servicing Tool». Для его использования необходимо развернуть System Center Virtual Machine Manager (SCVMM), а так же иметь развернутый сервер WSUS или SCCM, откуда, собственно говоря, обновления и будут подтягиваться. Принцип его действия следующий:
  1. Виртуальная машина разворачивается на специальном, выбираемом с помощью SCVMM, хосте – так называемый maintenance host.
  2. Виртуальная машина запускается, и на ней производится установка всех необходимых обновлений.
  3. Виртуальная машина останавливается, и VHD-файл возвращается в библиотеку уже с установленными обновлениями.
Offline Virtual Machine Servicing Tool распространяется бесплатно. Чтобы больше узнать об этом инструменте и скачать его – можно зайти на официальный сайт: www.microsoft.com/solutionaccelerators.
Заключение
Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.

habr.com

Prostoy-Site | Все права защищены © 2018 | Карта сайта