Прежде, чем строить инфраструктуру на базе виртуализации, и, тем более – вводить ее в промышленную эксплуатацию, необходимо позаботиться о том, чтобы ресурсы системы использовались наиболее эффективно, и производительность была максимальной. В этом цикле статей я дам рекомендации о том, как оптимизировать систему по производительности – как со стороны хоста, так и со стороны виртуальных машин.
Поскольку сервера, хостящие виртуальные машины, достаточно часто работают на пиковых нагрузках – производительность таких серверов имеет решающее значение для производительности всей системы. Потенциальными «узкими местами» могут являться:
Здесь я расскажу, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.
«Сердцем» любого компьютера является процессор. И правильность выбора процессора в контексте виртуализации – становится еще важнее. Процессор – самая дорогая часть любого компьютера, и выбор слишком мощного процессора может привести к лишним затратам не только на покупку самого процессора, но и в дальнейшем – на электроэнергию и охлаждение. Если же процессор будет недостаточно мощным – система не сможет обеспечить необходимую производительность, что может вылиться в покупку нового процессора – и, следовательно, опять затраты.
Нам необходимо получить ответы на следующие ключевые вопросы:
Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в Failover-кластер – и можно получить более высокопроизводительное и отказоустойчивое решение. Но с другой стороны, при таких делах… Появляется множество новых затрат:
После этого может оказаться, что лучше будет использовать четырехпроцессорный сервер, который может и будет стоить чуть дороже, и будет менее отказоустойчив – вместе со всеми накладными расходами может оказаться все же дешевле.
Тем не менее, производительность системы в целом может зависеть не только и не столько от процессоров. Возьмем, для примера, СУБД. В некоторых случаях требования к процессору могут быть не слишком высокими, зато дисковая подсистема может использоваться очень активно. А если в этой СУБД активно используется бизнес-логика и аналитика (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.aspx
Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.
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.
Если у вас имеется достаточно большая инфраструктура, и вам приходится часто создавать новые виртуальные машины и устанавливать на них ОС –набор готовых «мастер-образов» виртуальных жестких дисков поможет сильно сэкономить время. Такой «мастер-образ», хранящийся в виде VHD-файла, можно скопировать, а затем создать новую виртуальную машину с использованием VHD в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции).
Для создания такого мастер-образа необходимо:
При первой загрузке виртуальной машины с такого образа запустится процедура, именуемая «mini-setup». При этом будет предложено заново ввести имя компьютера, пароль администратора, и некоторые другие данные.
Мы создали мастер-образ, и он будет храниться у нас в течение длительного времени. И все бы ничего, но есть одна небольшая проблема: периодически выходят обновления системы, и при развертывании виртуальной машины с мастер-образа придется установить все обновления, вышедшие с момента создания мастер-образа. Если образ был создан, скажем, год или два тому назад – объем обновлений может быть достаточно большим. Кроме того, сразу после подключения к сети ОС без последних обновлений подвержена всевозможным угрозам безопасности, в том числе – и вирусам. Есть прекрасный инструмент, позволяющий устанавливать обновления прямо на мастер-образы виртуальных машин – он называется «Offline Virtual Machine Servicing Tool». Для его использования необходимо развернуть System Center Virtual Machine Manager (SCVMM), а так же иметь развернутый сервер WSUS или SCCM, откуда, собственно говоря, обновления и будут подтягиваться. Принцип его действия следующий:
Offline Virtual Machine Servicing Tool распространяется бесплатно. Чтобы больше узнать об этом инструменте и скачать его – можно зайти на официальный сайт: www.microsoft.com/solutionaccelerators.
Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.
Начнем с хоста
Поскольку сервера, хостящие виртуальные машины, достаточно часто работают на пиковых нагрузках – производительность таких серверов имеет решающее значение для производительности всей системы. Потенциальными «узкими местами» могут являться:
- Процессор
- Память
- Дисковая подсистема
- Сетевая подсистема
Здесь я расскажу, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.
Процессор – сердце компьютера
«Сердцем» любого компьютера является процессор. И правильность выбора процессора в контексте виртуализации – становится еще важнее. Процессор – самая дорогая часть любого компьютера, и выбор слишком мощного процессора может привести к лишним затратам не только на покупку самого процессора, но и в дальнейшем – на электроэнергию и охлаждение. Если же процессор будет недостаточно мощным – система не сможет обеспечить необходимую производительность, что может вылиться в покупку нового процессора – и, следовательно, опять затраты.
Нам необходимо получить ответы на следующие ключевые вопросы:
- Сколько ставить процессоров?
- Сколько нужно ядер?
- Их скоростные характеристики?
Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в Failover-кластер – и можно получить более высокопроизводительное и отказоустойчивое решение. Но с другой стороны, при таких делах… Появляется множество новых затрат:
- Требуется больше лицензий на ПО – как на сами ОС, так и на ПО управления (SCVMM, SCCM, SCOM, etc.)
- Возрастают затраты на администрирование – три сервера вместо одного
- Три сервера потребляют больше энергии, а значит – выделяют больше тепла, и занимают больше места в стойке, чем один сервер, пусть и более мощный.
После этого может оказаться, что лучше будет использовать четырехпроцессорный сервер, который может и будет стоить чуть дороже, и будет менее отказоустойчив – вместе со всеми накладными расходами может оказаться все же дешевле.
Тем не менее, производительность системы в целом может зависеть не только и не столько от процессоров. Возьмем, для примера, СУБД. В некоторых случаях требования к процессору могут быть не слишком высокими, зато дисковая подсистема может использоваться очень активно. А если в этой СУБД активно используется бизнес-логика и аналитика (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-V Hypervisor Virtual Processor, % Total Run Time — этот счетчик отображает загрузку виртуальных процессоров. Можно задать отображение суммарной загрузки всех процессоров для запущенных виртуальных машин, а можно выбрать конкретный виртуальный процессор конкретной виртуальной машины.
- Hyper-V Hypervisor Root Virtual Processor, % Total Run Time – а этот счетчик показывает загрузку выбранных логических процессоров задачами, не связанными с Hyper-V.
Примечание: Что же такое логический процессор? Проще всего это понять на примерах. Допустим, если у вас есть один процессор с одним ядром – у вас будет один логический процессор. Если процессор будет двухъядерным – то логических процессоров станет уже два. А если он будет поддерживать Hyper-Threading – то их будет уже четыре.
Эти два счетчика помогут получить реальную картину загрузки процессоров хоста. Значения счетчиков измеряются в процентах, а, соответственно, чем они ближе к 100% — тем выше нагрузка процессора, и, возможно, стоит подумать о покупке дополнительных или новых, более мощных процессоров.
Памяти много не бывает
Мощный процессор – это хорошо, но при недостатке памяти система начинает использовать файлы подкачки, и производительность начинает падать едва ли не экспоненциально. Как говорят в интернете – «512 мегабайт – это не память, это маразм».
К сожалению (а скорее всего – к счастью) в Hyper-V невозможно выделить виртуальным машинам больше памяти, чем физически присутствует в системе. Это то, что называют «memory overcommit», и чем с такой радостью играет маркетинг других вендоров решений виртуализации. Хорошо это или плохо – это тема отдельной статьи, и об эту тему было сломано уже не мало виртуальных копий.
В связи с этим возникает вопрос: а сколько памяти нам в итоге необходимо? Ответ зависит от разных факторов:
- Сколько виртуальных машин будет запущено, и сколько памяти им понадобится? Объем памяти, необходимый каждой виртуальной машине зависит от задач, которые она будет выполнять. Подход тот же самый, что и для обычных серверов, но память виртуальным машинам можно выделять более гибко – не 1024 Мб, а, к примеру, 900 Мб.
- Хостовой ОС тоже нужна память. Рекомендуется оставлять как минимум 512 Мб свободной памяти на нужды гипервизора и самой хостовой ОС. Если объем свободной памяти опустится ниже 32 Мб – система не даст запустить больше ни одной виртуальной машины, пока память не освободится. Кроме этого, в хостовой ОС могут выполняться какие-то другие задачи, помимо виртуализации. Хотя это и крайне не рекомендуется, но факт все же имеет место быть, и это необходимо учитывать.
- Другие виртуальные машины (для сценариев Live Migration). Если инфраструктура планируется на базе отказоустойчивого кластера, то необходимо на каждом из хостов предусмотреть дополнительные объемы памяти. Дело в том, что виртуальные машины могут перемещаться с одного хоста на другой в случае ручного перемещения (Live Migration), или же в случае отказа одного из хостов. Если на хосте будет недостаточно памяти для запуска перемещаемых виртуальных машин – то они попросту не смогут на нем запуститься. Поэтому на этапе проектирования надо предусмотреть «неприкосновенный запас» в размере 50-100% от необходимого объема памяти. Возможно, ситуация немного улучшится с выходом Windows Server 2008 R2 SP1, в который входят технологии динамического распределения памяти, но точно я смогу сказать лишь тогда, когда сам это протестирую.
Как же нам посмотреть, что происходит с памятью? К счастью, можно посмотреть через любимый 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 0 – «массив с чередованием». Информация пишется блоками («страйпами») одновременно на несколько дисков. Благодаря этому чтение и запись больших объемов информации происходит значительно быстрее, чем с одного диска, и тем быстрее, чем больше дисков в массиве. Но есть один большой недостаток: низкая надежность. Выход из строя любого из дисков приведет к полной потере информации. Поэтому на практике RAID 0 используется достаточно редко. Один из примеров – промежуточное хранилище резервных копий в модели «Disk-to-disk-to-tape», когда надежность не так важна, как быстродействие.
- RAID 1 – «зеркалирование». При такой модели информация записывается одновременно на несколько дисков, причем содержимое всех дисков абсолютно идентично. Скорость записи и чтения не выше, чем для одиночного диска, но намного выше надежность: выход из строя одного диска не приведет к потере информации. Недостаток лишь один: высокая стоимость – там, где хватает и одного диска – приходится ставить два и более. Смысл имеет в тех случаях, когда надежность имеет решающее значение.
- RAID 4 и RAID 5 – «чередование с контролем четности». Предстваляет собой некую «золотую середину» между RAID 0 и RAID 1. Смысл состоит в том, что информация хранится на дисках как и в случае RAID 0 — блоками с чередованием, но помимо этого вычисляются контрольные суммы хранимых данных. В случае отказа одного из дисков – недостающие данные автоматически вычисляются по имеющимся данным и контрольным суммам. Разумеется, это приводит к снижению производительности, но в то же время данные не теряются, и при замене сбойного диска вся информация восстанавливается (этот процесс называется перестройкой массива). Потеря данных произойдет только при отказе двух и более дисков. Такие массивы отличаются тем, что скорость записи у них значительно ниже, чем скорость чтения. Происходит так из-за того, что при записи блока данных происходит вычисление контрольной суммы и запись ее на диск. RAID 4 и RAID 5 отличаются тем, что в RAID 4 контрольные суммы записываются на отдельный диск, а в RAID 5 – хранятся на всех дисках массива вместе с данными. В любом случае, для организации такого массива нужно N дисков для хранения данных плюс один диск. В отличие от RAID 1 и RAID 10, где количество дисков просто удваивается.
- RAID 6 – он же RAID DP, double-parity, двойная четность. То же самое, что и RAID 5, но контрольные суммы вычисляются два раза, с использованием различных алгоритмов. Хотя дисков здесь требуется уже не N+1, как с RAID 5, а N+2, зато такой массив может пережить даже одновременный отказ двух дисков. Встречается относительно редко, как правило – в системах хранения данных Enterprise-уровня, к примеру – NetApp.
- RAID 10 – «гибрид» RAID 0 и RAID 1. Представляет собой RAID 0 из нескольких RAID 1 (и тогда называется RAID 0+1) или наоборот – RAID 1 из нескольких RAID 0 (RAID 1+0). Отличается наивысшей производительностью, как по записи, так и по чтению, но в то же время отличается и высокой стоимостью – так как дисков требуется в 2 раза больше, чем необходимо для хранения данных.
Как видно, выбор дисков – достаточно непростая задача, поэтому выбирать нужно, исходя не только из требований к дисковому пространству, но и требований к производительности, и разумеется – из выделенных бюджетов. Иногда будет более оправданно использование внешней системы хранения данных, к примеру – когда речь идет о больших объемах и/или высокой производительности, которые невозможно достичь, используя внутренние диски. А когда планируется инфраструктура с высокой отказоустойчивостью – то тут уж точно никуда не деться от внешней СХД. Внешние СХД нужно выбирать, руководствуясь теми же принципами, что и внутренние диски: пропускная способность интерфейсов, количество дисков, тип дисков, поддерживаемые RAID-массивы, дополнительные функции – такие, как изменение объемов виртуальных дисков (LUN’ов) «на лету», возможность использования моментальных снимков (snapshots), и т.д.
А что же насчет измерений? Есть несколько счетчиков, связанных с производительностью дисковой подсистемы. Интерес представляют следующие:
- Physical Disk, % Disk Read Time
- Physical Disk, % Disk Write Time
- Physical Disk, % Idle Time
Эти счетчики показывают, какой процент времени идет чтение, запись на диск и, соответственно – процент простоя. Если их значения поднимаются выше 75% на длительные промежутки времени – это значит, что производительность дисковой подсистемы недостаточно высока.
Кроме этого, есть еще два счетчика:
- Physical Disk, Avg. Disk Read Queue Length
- Physical Disk, Avg. Disk Write Queue Length
Эти два счетчика показывают среднюю длину очереди диска – соответственно, на чтение и на запись. Высокие значения этих параметров (выше 2) на небольшие промежутки времени («пики») вполне допустимы, и, к примеру, для СУБД или серверов MS Exchange вполне характерны, но длительные превышения говорят о том, что дисковая подсистема, вероятно, является «узким местом».
Сетевая подсистема
Сетевая подсистема бывает «узким местом» намного реже, чем процессор, память и жесткий диск, но тем не менее – о ней не стоит забывать.
Как и со всеми остальными компонентами – имеется несколько вопросов, на которые неплохо было бы получить ответы еще на этапе планирования:
- Сколько виртуальных машин будет запущено одновременно, и какова будет нагрузка на сеть?
- Какова пропускная способность сети?
- Используются ли системы хранения данных с интерфейсом iSCSI?
- Есть ли у сервера аппаратные средства удаленного управления, не зависимые от установленной ОС (к примеру – HP iLO или Dell DRAC)?
В зависимости от ответов возможны разные сценарии настройки сетевой подсистемы. Предположим, что у нас есть всего один сервер. Сетевых интерфейсов у него ровно 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.aspx
iSCSI
Если планируется использовать системы хранения данных с интерфейсом 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 2000 Server SP4
- Windows Server 2003 SP2
- Windows Server 2008
- Windows XP SP2, SP3
- Windows Vista SP1
- SUSE Linux Enterprise Server 10 SP3 / 11
- Red Hat Enterprise Linux 5.2 – 5.5
ОС Windows 7 и Windows Server 2008 R2 содержат сервисы интеграции в инсталляционном пакете, поэтому на эти ОС их не нужно устанавливать дополнительно.
Установка интеграционных сервисов позволяет использовать синтетические устройства, имеющие более высокую производительность по сравнению с эмулируемых. Подробнее о разнице между эмулируемыми и синтетическими устройствами – в моей статье об архитектуре Hyper-V.
Вот список драйверов, входящих в Integration Services:
- IDE-контроллер – заменяет собой эмулируемый IDE-контроллер, что повышает скорость доступа к дискам
- SCSI-контроллер – является полностью синтетическим устройством и требует для работы обязательной установки интеграционных сервисов. К каждому SCSI-контроллеру можно подключить до 64 дисков, самих контроллеров может быть до 4 на каждую виртуальную машину.
- Сетевой адаптер – имеет более высокую производительность, чем эмулируемый (Legacy Network Adapter), и поддерживает особые функции, такие, как VMQ.
- Видео и мышь – повышают удобство управления виртуальной машиной через ее консоль.
Помимо перечисленных драйверов, при установке сервисов интеграции поддерживаются следующие функции:
- Operating System Shutdown – возможность корректного завершения работы гостевой ОС без логина в нее. Аналогично нажатию кнопки Power на корпусе ATX.
- Time Synchronization – ясно из названия – синхронизация системного времени между хостовой и гостевой ОС.
- Data Exchange – обмен ключами реестра между гостевой и хостовой ОС. Таким образом, к примеру, гостевая ОС может определить имя хоста, на котором она запущена. Эта возможность доступна только для гостевых ОС семейства MS Windows.
- Heartbeat – специальный сервис, периодически отправляющий специальные сигналы, означающие, что с виртуальной машиной все в порядке. Если гостевая ОС по какой-то причине, например, зависнет – она перестанет отправлять Heartbeat, и это может служить сигналом, к примеру, для автоматической перезагрузки.
- Online Backup – представляет из себя VSS Writer, позволяющий в любой момент получить консистентную резервную копию данных виртуальной машины. При запуске резервного копирования через VSS приложения, запущенные на виртуальной машине автоматически сбрасывают данные на диск, и потому бэкап получается консистентным.
Для установки интеграционных сервисов в ОС Windows нужно выбрать Action – Integration Services Setup. При этом к виртуальной машине автоматически подмонтируется ISO-образ с файлами установки, и запустится процесс инсталляции. Если в гостевой системе отключен запуск Autorun, то процесс инсталляции придется запустить вручную.
Интеграционные компоненты для Linux не включены в дистрибутив Windows Server – их необходимо загрузить с сайта Microsoft.
Sysprep: создаем мастер-образ
Если у вас имеется достаточно большая инфраструктура, и вам приходится часто создавать новые виртуальные машины и устанавливать на них ОС –набор готовых «мастер-образов» виртуальных жестких дисков поможет сильно сэкономить время. Такой «мастер-образ», хранящийся в виде VHD-файла, можно скопировать, а затем создать новую виртуальную машину с использованием VHD в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции).
Для создания такого мастер-образа необходимо:
- Создать новую виртуальную машину
- Произвести установку ОС, сервисов интеграции, всех доступных обновлений системы и дополнительного ПО, если таковое необходимо
- Подготовить установленную ОС с помощью утилиты Sysprep, которая удалит информацию о пользователе, ключе продукта и уникальный идентификатор (SID).
При первой загрузке виртуальной машины с такого образа запустится процедура, именуемая «mini-setup». При этом будет предложено заново ввести имя компьютера, пароль администратора, и некоторые другие данные.
Оффлайн-установка обновлений
Мы создали мастер-образ, и он будет храниться у нас в течение длительного времени. И все бы ничего, но есть одна небольшая проблема: периодически выходят обновления системы, и при развертывании виртуальной машины с мастер-образа придется установить все обновления, вышедшие с момента создания мастер-образа. Если образ был создан, скажем, год или два тому назад – объем обновлений может быть достаточно большим. Кроме того, сразу после подключения к сети ОС без последних обновлений подвержена всевозможным угрозам безопасности, в том числе – и вирусам. Есть прекрасный инструмент, позволяющий устанавливать обновления прямо на мастер-образы виртуальных машин – он называется «Offline Virtual Machine Servicing Tool». Для его использования необходимо развернуть System Center Virtual Machine Manager (SCVMM), а так же иметь развернутый сервер WSUS или SCCM, откуда, собственно говоря, обновления и будут подтягиваться. Принцип его действия следующий:
- Виртуальная машина разворачивается на специальном, выбираемом с помощью SCVMM, хосте – так называемый maintenance host.
- Виртуальная машина запускается, и на ней производится установка всех необходимых обновлений.
- Виртуальная машина останавливается, и VHD-файл возвращается в библиотеку уже с установленными обновлениями.
Offline Virtual Machine Servicing Tool распространяется бесплатно. Чтобы больше узнать об этом инструменте и скачать его – можно зайти на официальный сайт: www.microsoft.com/solutionaccelerators.
Заключение
Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.
