Записки IT специалиста

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

Что такое виртуализация?

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

Так что-же такое виртуализация? Это возможность запустить на одном физическом компьютере несколько изолированных друг от друга виртуальных машин, каждая из которых будет «думать» что работает на отдельном физическом ПК. Рассмотрим следующую схему:

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

Гипервизор может работать как непосредственно поверх железа, так и на уровне операционной системы, существуют также гибридные реализации, которые работают поверх специально сконфигурированной ОС в минимальной конфигурации.

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

Как устроена виртуальная машина?

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

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

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

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

Преимущества виртуализации

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

На рисунке ниже окно средства настольной виртуализации из нашей тестовой лаборатории в окне которого запущена ОС Windows 8.

Серверная визуализация широко используется в IT инфраструктурах любого уровня и позволяет использовать один физический сервер для запуска нескольких виртуальных серверов. Преимущества данной технологии очевидны:

Оптимальное использование вычислительных ресурсов

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

Экономия физических ресурсов

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

Повышение масштабируемости и расширяемости инфраструктуры

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

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

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

Повышение отказоустойчивости

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

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

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

Возможность поддерживать устаревшие ОС

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

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

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

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

Хост подключен к внешней сети посредством физического сетевого адаптера LAN 0, посредством этого же физического интерфейса к внешней сети подключена виртуальная машина VM5, через сетевой адаптер VM LAN 0. Для остальных машин внешней сети хост и VM5 два разных ПК, каждый из них имеет свой сетевой адрес, свою сетевую карту со своим MAC-адресом. Вторая сетевая карта VM5 подключена к виртуальному коммутатору виртуальной сети VM NET 1, к нему же подключены сетевые адаптеры виртуальных машин VM1-VM4. Таким образом мы в пределах одного физического хоста организовали безопасную внутреннюю сеть, которая имеет доступ к внешней сети только через роутер VM5.

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

Моментальные снимки

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

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

Заключение

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

Виртуализация: рекомендации ведущих собаководов

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

Начнем с хоста

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

• Процессор
• Память
• Дисковая подсистема
• Сетевая подсистема

Здесь я расскажу, как выявлять «узкие места» по всем четырем направлениям и как с ними бороться, и самое главное – как их можно избежать.

Процессор – сердце компьютера

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

• Сколько ставить процессоров?
• Сколько нужно ядер?
• Их скоростные характеристики?

Ответить на эти вопросы не так просто, как кажется. Простой пример: какую систему использовать – двухпроцессорную или четырехпроцессорную? По цене двухпроцессорные системы в безусловном выигрыше: цена одного четырехпроцессорного сервера примерно равна трем двухпроцессорным. Казалось бы, в таком случае наилучшее решение – купить три двухпроцессорных сервера и объединить их в 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-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 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 в качестве жесткого диска. При этом на нем уже будет установлена ОС и некоторый необходимый набор ПО (в частности – сервисы интеграции).
Для создания такого мастер-образа необходимо:

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.

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

Виртуализация: новый подход к построению IT-инфраструктуры

Что такое виртуализация и виртуальные машины

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

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

Сам термин «виртуализация» в компьютерных технологиях появился в шестидесятых годах прошлого века вместе с термином «виртуальная машина», означающим продукт виртуализации программно-аппаратной платформы. В то время виртуализация была, скорее, интересной технической находкой, чем перспективной технологией. Разработки в сфере виртуализации в шестидесятых-семидесятых годах проводились только компанией IBM. С появлением в компьютере IBM M44/44X экспериментальной системы пэйджинга, впервые был употреблен термин «виртуальная машина» (virtual machine), который заменил более ранний термин «псевдо машина» (pseudo machine). Затем в мэйнфреймах IBM серии System 360/370, можно было использовать виртуальные машины для сохранения предыдущих версий операционных систем. До конца девяностых годов никто кроме IBM так и не решался использовать эту оригинальную технологию всерьез. Однако в девяностых годах стали очевидны перспективы подхода виртуализации: с ростом аппаратных мощностей, как персональных компьютеров, так и серверных решений, вскоре представится возможность использовать несколько виртуальных машин на одной физической платформе.

В 1997 году компания Connectix выпускает первую версию Virtual PC для платформы Macintosh, а в 1998 году VMware патентует свои техники виртуализации. Компания Connectix впоследствии была куплена корпорацией Microsoft, а VMware корпорацией EMC, и на данный момент обе эти компании являются двумя основными потенциальными конкурентами на рынке технологий виртуализации в будущем. Потенциальными — потому что сейчас VMware безоговорочный лидер на этом рынке, однако у Microsoft, как всегда, есть козырь в рукаве.

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

Виды виртуализации

Понятие виртуализации условно можно разделить на две фундаментально различающиеся категории:

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

Виды виртуализации

Виртуализация платформ

Под виртуализацией платформ понимают создание программных систем на основе существующих аппаратно-программных комплексов, зависящих или независящих от них. Система, предоставляющая аппаратные ресурсы и программное обеспечение, называется хостовой (host), а симулируемые ей системы — гостевыми (guest). Чтобы гостевые системы могли стабильно функционировать на платформе хостовой системы, необходимо, чтобы программное и аппаратное обеспечение хоста было достаточно надежным и предоставляло необходимый набор интерфейсов для доступа к его ресурсам. Есть несколько видов виртуализации платформ, в каждом из которых осуществляется свой подход к понятию «виртуализация». Виды виртуализации платформ зависят от того, насколько полно осуществляется симуляция аппаратного обеспечения. До сих пор нет единого соглашения о терминах в сфере виртуализации, поэтому некоторые из приведенных далее видов виртуализации могут отличаться от тех, что предоставят другие источники.

Виды виртуализации платформ:

1. Полная эмуляция (симуляция).

   При таком виде виртуализации виртуальная машина полностью виртуализует все аппаратное обеспечение при сохранении гостевой операционной системы в неизменном виде. Такой подход позволяет эмулировать различные аппаратные архитектуры. Например, можно запускать виртуальные машины с гостевыми системами для x86-процессоров на платформах с другой архитектурой (например, на RISC-серверах компании Sun). Долгое время такой вид виртуализации использовался, чтобы разрабатывать программное обеспечение для новых процессоров еще до того, как они были физически доступными. Такие эмуляторы также применяют для низкоуровневой отладки операционных систем. Основной минус данного подхода заключается в том, что эмулируемое аппаратное обеспечение весьма и весьма существенно замедляет быстродействие гостевой системы, что делает работу с ней очень неудобной, поэтому, кроме как для разработки системного программного обеспечения, а также образовательных целей, такой подход мало где используется.

   Примеры продуктов для создания эмуляторов: Bochs, PearPC, QEMU (без ускорения), Hercules Emulator.

2. Частичная эмуляция (нативная виртуализация).

   В этом случае виртуальная машина виртуализует лишь необходимое количество аппаратного обеспечения, чтобы она могла быть запущена изолированно. Такой подход позволяет запускать гостевые операционные системы, разработанные только для той же архитектуры, что и у хоста. Таким образом, несколько экземпляров гостевых систем могут быть запущены одновременно. Этот вид виртуализации позволяет существенно увеличить быстродействие гостевых систем по сравнению с полной эмуляцией и широко используется в настоящее время. Кроме того, в целях повышения быстродействия в платформах виртуализации, использующих данный подход, применяется специальная «прослойка» между гостевой операционной системой и оборудованием (гипервизор), позволяющая гостевой системе напрямую обращаться к ресурсам аппаратного обеспечения. Гипервизор, называемый также «Монитор виртуальных машин» (Virtual Machine Monitor) — одно из ключевых понятий в мире виртуализации. Применение гипервизора, являющегося связующим звеном между гостевыми системами и аппаратурой, существенно увеличивает быстродействие платформы, приближая его к быстродействию физической платформы.

   К минусам данного вида виртуализации можно отнести зависимость виртуальных машин от архитектуры аппаратной платформы.

   Примеры продуктов для нативной виртуализации: VMware Workstation, VMware Server, VMware ESX Server, Virtual Iron, Virtual PC, VirtualBox, Parallels Desktop и другие.

3. Частичная виртуализация, а также «виртуализация адресного пространства» («address space virtualization»).

   При таком подходе, виртуальная машина симулирует несколько экземпляров аппаратного окружения (но не всего), в частности, пространства адресов. Такой вид виртуализации позволяет совместно использовать ресурсы и изолировать процессы, но не позволяет разделять экземпляры гостевых операционных систем. Строго говоря, при таком виде виртуализации пользователем не создаются виртуальные машины, а происходит изоляция каких-либо процессов на уровне операционной системы. В данный момент многие из известных операционных систем используют такой подход. Примером может послужить использование UML (User-mode Linux), в котором «гостевое» ядро запускается в пользовательском пространстве базового ядра (в его контексте).

4. Паравиртуализация.

   При применении паравиртуализации нет необходимости симулировать аппаратное обеспечение, однако, вместо этого (или в дополнение к этому), используется специальный программный интерфейс (API) для взаимодействия с гостевой операционной системой. Такой подход требует модификации кода гостевой системы, что, с точки зрения сообщества, Open Source не так и критично. Системы для паравиртуализации также имеют свой гипервизор, а API-вызовы к гостевой системе, называются «hypercalls» (гипервызовы). Многие сомневаются в перспективах этого подхода виртуализации, поскольку в данный момент все решения производителей аппаратного обеспечения в отношении виртуализации направлены на системы с нативной виртуализацией, а поддержку паравиртуализации приходится искать у производителей операционных систем, которые слабо верят в возможности предлагаемого им средства. В настоящее время провайдерами паравиртуализации являются компании XenSource и Virtual Iron, утверждающие, что быстродействие паравиртуализации выше.

5. Виртуализация уровня операционной системы.

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

   Примеры виртуализации уровня ОС: Linux-VServer, Virtuozzo, OpenVZ, Solaris Containers и FreeBSD Jails.

6. Виртуализация уровня приложений.

   Этот вид виртуализации не похож на все остальные: если в предыдущих случаях создаются виртуальные среды или виртуальные машины, использующиеся для изоляции приложений, то в данном случае само приложение помещается в контейнер с необходимыми элементами для своей работы: файлами реестра, конфигурационными файлами, пользовательскими и системными объектами. В результате получается приложение, не требующее установки на аналогичной платформе. При переносе такого приложения на другую машину и его запуске, виртуальное окружение, созданное для программы, разрешает конфликты между ней и операционной системой, а также другими приложениями. Такой способ виртуализации похож на поведение интерпретаторов различных языков программирования (недаром интерпретатор, Виртуальная Машина Java (JVM), тоже попадает в эту категорию).

   Примером такого подхода служат: Thinstall, Altiris, Trigence, Softricity.

Виртуализация ресурсов

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

Виды виртуализации ресурсов:

1. Объединение, агрегация и концентрация компонентов.

   Под таким видом виртуализации ресурсов понимается организация нескольких физических или логических объектов в пулы ресурсов (группы), представляющих удобные интерфейсы пользователю. Примеры такого вида виртуализации:

   • многопроцессорные системы, представляющиеся нам как одна мощная система,
   • RAID-массивы и средства управления томами, комбинирующие несколько физических дисков в один логический,
   • виртуализация систем хранения, используемая при построении сетей хранения данных SAN (Storage Area Network),
   • виртуальные частные сети (VPN) и трансляция сетевых адресов (NAT), позволяющие создавать виртуальные пространства сетевых адресов и имен.
2. Кластеризация компьютеров и распределенные вычисления (grid computing).

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

3. Разделение ресурсов (partitioning).

   При разделении ресурсов в процессе виртуализации происходит разделение какого-либо одного большого ресурса на несколько однотипных объектов, удобных для использования. В сетях хранения данных это называется зонированием ресурсов («zoning»).

4. Инкапсуляция.

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

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

Где применяется виртуализация

Виртуализация операционных систем за последние три-четыре года очень хорошо продвинулась вперед, как в технологическом, так и в маркетинговом смысле. С одной стороны, пользоваться продуктами виртуализации стало намного проще, они стали более надежными и функциональными, а с другой — нашлось немало новых интересных применений виртуальным машинам. Сферу применения виртуализации можно определить, как «место, где есть компьютеры», однако на данный момент можно обозначить следующие варианты использования продуктов виртуализации:

1. Консолидация серверов.

   В данный момент приложения, работающие на серверах в IT-инфраструктуре компаний, создают небольшую нагрузку на аппаратные ресурсы серверов (в среднем 5-15 процентов). Виртуализация позволяет мигрировать с этих физических серверов на виртуальные и разместить их все на одном физическом сервере, увеличив его загрузку до 60-80 процентов и, повысив тем самым коэффициент использования аппаратуры, что позволяет существенно сэкономить на аппаратуре, обслуживании и электроэнергии.

2. Разработка и тестирование приложений.

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

3. Использование в бизнесе.

   Этот вариант использования виртуальных машин является наиболее обширным и творческим. К нему относится все, что может понадобиться при повседневном обращении с IT-ресурсами в бизнесе. Например, на основе виртуальных машин можно легко создавать резервные копии рабочих станций и серверов (просто скопировав папку), строить системы, обеспечивающие минимальное время восстановления после сбоев и т. п. К данной группе вариантов использования относятся все те бизнес-решения, которые используют основные преимущества виртуальных машин.

4. Использование виртуальных рабочих станций.

   С приходом эры виртуальных машин будет бессмысленно делать себе рабочую станцию с ее привязкой к аппаратуре. Теперь создав однажды виртуальную машину со своей рабочей или домашней средой, можно будет использовать её на любом другом компьютере. Также можно использовать готовые шаблоны виртуальных машин (Virtual Appliances), которые решают определенную задачу (например, сервер приложений). Концепция такого использования виртуальных рабочих станций может быть реализована на основе хост-серверов для запуска на них перемещаемых десктопов пользователей (нечто подобное мэйнфреймам). В дальнейшем эти десктопы пользователь может забрать с собой, не синхронизируя данные с ноутбуком. Этот вариант использования также предоставляет возможность создания защищенных пользовательских рабочих станций, которые могут быть использованы, например, для демонстрации возможностей программы заказчику. Можно ограничить время использования виртуальной машины — и по прошествии этого времени виртуальная машина перестанет запускаться. В этом варианте использования заложены большие возможности.

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

Как работает виртуализация сегодня

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

10 причин использовать виртуальные машины

1. Экономия на аппаратном обеспечении при консолидации серверов.

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

2. Возможность поддержания старых операционных систем в целях обеспечения совместимости.

   При выходе новой версии операционной системы, старую версию можно поддерживать на виртуальной машине, пока не будет полностью обкатана новая ОС. И наоборот, можно «поднять» новую ОС на виртуальной машине и опробовать ее без ущерба для основной системы.

3. Возможность изолировать потенциально опасные окружения.

   Если какое-то приложение или компонент вызывает сомнения в его надежности и защищенности, можно использовать его на виртуальной машине без опасности повредить жизненно важные компоненты системы. Такую изолированную среду называют также «песочницей» (sandbox). Помимо этого, можно создавать виртуальные машины, ограниченные политиками безопасности (например, машина перестанет запускаться через две недели).

4. Возможность создания требуемых аппаратных конфигураций.

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

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

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

6. На одном хосте может быть запущено одновременно несколько виртуальных машин, объединенных в виртуальную сеть.

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

7. Виртуальные машины предоставляют великолепные возможности по обучению работе с операционными системами.

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

8. Виртуальные машины повышают мобильность.

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

9. Виртуальные машины могут быть организованы в «пакеты приложений».

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

10. Виртуальные машины более управляемы.

    При использовании виртуальных машин существенно повышается управляемость в отношении создания резервных копий, создания снимков состояний виртуальных машин («снапшотов») и восстановлений после сбоев.

На этом, конечно, достоинства виртуальных машин не исчерпываются, это лишь пища для размышления и исследования их возможностей. Безусловно, как и у всякого нового и перспективного решения, у виртуальных машин есть и свои недостатки:

1. Невозможность эмуляции всех устройств.

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

2. Виртуализация требует дополнительных аппаратных ресурсов.

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

3. Некоторые платформы виртуализации требовательны к конкретному аппаратному обеспечению.

   В частности, замечательная платформа компании VMware, ESX Server, была бы и вовсе замечательной, если бы не предъявляла жестких требований к аппаратному обеспечению.

4. Хорошие платформы виртуализации стоят хороших денег.

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

Несмотря на перечисленные и вполне устранимые недостатки, виртуализация продолжает набирать обороты, и в 2007 году ожидается существенное расширение, как рынка платформ виртуализации, так и средств управления виртуальными инфраструктурами. За последние несколько лет интерес к виртуализации вырос в разы, что можно увидеть по статистике Google Trends:

Статистика тренда «виртуализация»

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

Что ждет виртуализацию в будущем

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

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

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