Всем доброго времени суток!
Сегодня тема для разговора будет уж (как я лично считаю) очень актуальной, если даже не сказать болезненной…
Да-да, я-таки решил провести функционально-экономическое сравнение 2-х ведущих платформ гипервизоров — Hyper-V 3.0 и VMware ESXi 5.0/5.1 между собой… Но потом я решил для полноты картины к сравнению добавить еще XenServer 6 от Citrix…
Я уже в предчувствии камнепада в свой огород, но все же будем держать оборону до конца — просьба занять соответствующую позицию, сторону, лагерь — кому как удобно — и под кат для начала боя…
Прежде чем начать бой ни на жизнь, а на смерть, я предлагаю определить критерии, домены, зоны в пределах которых будут выделяться фичи и сравниваться между платформами. И так:
1) Масштабируемость и производительность
2) Безопасность и сеть
3) Гибкость инфраструктуры
4) Отказоустойчивость и непрерывность бизнес-процессов
Категории заданы — приступим!
Для начала я предлагаю взглянуть на сравнительную таблицу масштабируемости подопытных:
Как видно из таблицы, лидер здесь явный и однозначный — это Hyper-V 3.0. Причем здесь следует упомянуть о том, что производительность и масштабируемость гипервизора от MS никак не зависит от его платности. У VMware же ситуация обратная — в зависимости от того, сколько вечно зеленых цифровых вы заплатите — столько фишек вы и получите.
Так что для сравнения VMware у нас аж 2 столбца. XenServer явно ни к селу, ни к городу — он как-то застрял по середине…
Однако, если вспомнить многочисленные заявления Citrix о том, что «мы не компания которая делает решения по виртуализаци, а компания которая делает решения по оптимизации трафика», то XenServer — это инструмент для достижения этой задачи. Однако, тот факт, что Hyper-V и Citrix Xen — дальние родственники — и в результате такая разница в масштабиоуемости — удручает.
Про VMware сильно раздражал колебательный фактор их политики лицензирования ОЗУ — т.н. vRAM — ЧТО ФАКТИЧЕСКИ МОЖНО НАЗВАТЬ ВЫМОГАТЕЛЬСТВОМ. Мало того, что необходимо было лицензировать объем ОЗУ, который потребляют виртуалки, так помимо этого в случае необходимости апгрейда по этому самому параметру vRAM образовывалась дельта (т.к. такого параметра в ESX/ESXi 4.x просто-навсего не было) — а значит люди попадали на деньги. Правда, с выходом 5.1 VMware одумалась и отказалась от такого бредового формата — однако, такие жесткие ценооброзавательные конвульсии ни о чем хорошем свидетельствовать не могут…
С точки зрения технологической — мною лично реально ожидалась ситуация «ноздря-в-ноздрю» — но нет, такого не случилось, и интерес немного по угас… Я думаю первый блок сравнения особо больше в комментариях не нуждается — он достаточно «прозрачный».
Предлагаю перейти в следующей части данного блока сравнения — а именно к обзору некоторых фич, которые относятся к показателям производительности и масштабируемости. Рассмотрим функционал взаимодействия с дисковой подсистемой, таблица ниже:
Если посмотреть на данную таблицу, то здесь можно отметить следующие моменты:
1) Нативная поддержка 4Кб-секторов в виртуальных дисках — достаточно критичная вещь для ресурсоемких приложений. Высокопроизводительный СУБД как правило размещаются на дисках с большим размером страйпа. Поддержка данного механизма официально присутствует только в Hyper-V — у конкурирующих вендоров мне не удалось найти в официальной документации информации о поддержке данного механизма.
2) Максимальный размер LUN, подключаемого напрямую к ВМ — здесь ситуация следующая. У Citrix и VMware это параметр, который зависит именно от самого гипервизора напрямую, а у Hyper-V — скорее от того, какая ОС является гостевой. В случае использования Windows Server 2012 в качестве гостевой ОС есть возможность пробросить LUN размером свыше 256 Тбайт, у других гипервизоров данный параметр заканчивается на 64 Тбайт у VMware и не поднимается выше отметки в 15 Тб у Citrix соответственно.
С точки зрения функционала очень слабо смотриться XenServer — поддержка виртуализации Fiber Channel уже должно стать нормой — хотя бы на уровне платформы, однако ситуация в данном случае не является положительным примером. То, что у VMware политика «платности» фич уже все давно привыкли, так что на уровне самой платформы ESXi умеет это делать — вопрос только в том готовы ли вы за это столько платить? Редакция vSphere Enterprise Plus крайне не дешева, да еще и поддержку нужно покупать в обязательном порядке.
Наличие поддержки аппаратной разгрузки передачи данных в сетях SAN тоже является очень неплохим бонусом. Если раньше это было исключительной фичей VMware — vStorage API for Array Integration (VAAI), то Hyper-V 3.0 имеет в своем арсенале схожую технологию — Offload Data Transfer (ODX). Большинство вендоров СХД уже либо выпустили прошивки для своих систем с поддержкой данной технологии либо готовы сделать этов ближайшее время. Очень грустно за Citrix в данном конкретном случае — у XenServer никаких технологий оптимизации работы с SAN-системами нет.
Ну что же, с дисковой подсистемой разобрались — давайте теперь посмотрим какие же есть механизмы управления ресурсами у наших участников обзора.
С точки зрения фич картина в данной ситуации более-менее ровная, однако есть моменты на которые стоит обратить внимание:
1) Data Center Bridging (DCB) — под данной загадочной аббревиатурой скрывается ни что иное, как поддержка конвергентных сетевых адаптеров — Converged Network Adapter (CNA). Иными словами, конвергентный сетевой адаптер — это такой адаптер, который одновременно имеет аппаратные поддержку и ускорение для работы как в обычных сетях LAN Ethernet, так и в сетях SAN — т.е. идея состоит в том что, среда передачи данных, тип носителя — становятся унифицированными (это может быть оптика или витая пара), а поверх физического канала используется различные протоколы — SMB, FCoE, iSCSI, NFS, HTTP и прочие — т.е. с точки зрения управления у нас есть возможность динамически переназначать такие адаптеры перераспределяя их в зависимости от необходимости и типа нагрузки. Если взглянуть на таблицу, то Citrix не то чтобы не имеет поддержки DCB — есть некоторый список адаптеров CNA, которые поддерживаются — но в официальной документации Citrix XenServer 6.0 нет ни слова о поддержке DCB.
2) Качество обслуживания, поддержка QoS — по сути механизмы оптимизации трафика и гарантии качества канала передачи данных. Здесь все в принципе у всех в норме, за исключением бесплатного ESXi.
3) Динамическая память — вот тут история получается крайне интересная. По заявлениям Microsoft механизмы оптимизации памяти с помощью Dynamic Memory были существенно переработаны и позволили получить оптимизацию в работе с памятью — и тем самым увеличить плотность размещения виртуальных машин. К этому добавили файл интеллектуальной подкачки, который настраивается на каждую отдельную ВМ. Честно скажу, мне трудно судить насколько это эффективный механизм, однако при сравнения плотности размещения одинаковых ВМ на Hyper-V 2.0 и Hyper-V 3.0 разница была почти в 2 раза в пользу второго (Машинки были с виртуальным Windows Server 2008 R2). И вот тут возникает вопрос — у VMware целый арсенал фич по оптимизации работы с памятью, включая дедупликацию страниц памяти, что работает гораздо эффективнее. Но давайте более детально взглянем на эту ситуацию. У VMware есть 4 технологии оптимизации работы с памятью — Memory Balooning, Transparent Page Sharing, Compression и Swapping. Однако, все 4 технологии начинаю свою работу только в условиях повышенной нагрузки на ресурсы хост-системы, т.е. по своей манере действия они являются реактивными, нежели проактивными или оптимизирующими. Если еще учесть тот факт, что большинство современных серверных платформ поддерживают большие таблицы Large Page Tables, которые по умолчанию имеют размер в 2 Мбайта — это увеличивает производительность, то картина меняется — ибо ESXi не умеет дедуплицировать такие большие блоки данных — он начинает их разбивать на блоки меньшего размера, 4 Кбайта, а вот уже их он и дедуплицирует — но все эти операции стоят ресурсов и времени — так картина не такая уж однозначная с точки зрения полезности данных технологий.
Ну что же, с производительностью и масштабируемостью вроде бы мы разобрались — теперь самое время перейти к сравнению возможностей безопасности и изоляции виртуализованных сред.
Здесь следует выделить следующие моменты:
1) Single Root I/O Virtualization (SRIOV) — фактически это механизм пробрасывания физического адаптера внутрь виртуальной машины, однако, на мой взгляд немного некорректно сравнивать технологии VMware и Microsoft в этой области. DirectPath I/O, технология которую применяет VMware, действительно полностью пробрасывает слот PCI Express, а точнее устройство которое в нем находится — однако список устройств, которые совместимы с данной фичей крайне мал, да и вы фактически привязывайте вашу ВМ к хосту в довесок лишая ее практически всех бонусов в области оптимизации работы с памятью, высокой доступности, мониторинга сетевого трафика и прочих вкусностей. Исключением, разве что, в данной ситуации могут стать платформы на базе Cisco UCS — да и то — только в отдельных конфигурациях. Точно такая же ситуация у Citirix — не смотря на поддержку SRIOV, ВМ в которой активирована данная фича лишается всех возможностей в области премещения ВМ, возможности настроить списки доступа к ВМ (ведь карточка-то такая в обход свича виртуального пойдет) — так что все это крайне лимитировано. У Microsoft же скорее происходит виртуализация и профилирования такого адаптера — т.к. ВМ может быть и высокодоступной, и мигрировать с хоста на хост может, однако для этого необходимо наличие карт с поддержкой SRIOV в каждом хосте — тогда параметры адаптера SRIOV передут вместе с ВМ на новый хост.
2) Шифрование дисков и IPSec Offload — здесь картина явно однозначная, никто кроме как Hyper-V не работает с такими механизмами. Естественно, что для IPSec Offload понадобиться карточка с аппаратной поддержкой данной технологии, однако если вы запускаете ВМ с интенсивным взаимодействием с механизмами IPSec — то выигрыш вы получите от применения данной технологии. Что же касается шифрования дисков, то реализуется этот механизм с помощью BitLocker, однако возможности его применения в нашей стране сильно ограничены нормативными актами. В общем-то механизм интересный — зашифровать пространство, где располагаются ВМ с целью предотвращения утечки данных, но, к сожаления, широкого распространения данный механизм не получит до тех пор, пока не будут решены юридические и нормативные вопросы.
3) Virtual Machine Queue (VMQ) — Технология оптимизации работы с трафиком ВМ на уровне хоста и сетевых интерфейсов. Здесь, по чес_ноку, тяжело судить насколько DMVq лучше VMq — ибо на практике я не имел возможности сравнить эти технологии. Однако, заявлено что DMVq есть только у Hyper-V. Ну что же — есть так есть, наверное это хорошо, но в данном случае я оставлю без каких-либо комментариев данный пункт — ибо для меня лично нет сильной разницы, кроме букв — буду рад если кто-то прольет свет на разницу и эффект от динамичности пресловутого VMq.
Продолжим дальше — теперь я предлагаю взглянуть на возможности виртуальных коммутаторов, которые есть в арсенале у наших гипервизоров:
1) Расширяемые коммутаторы — здесь стоит сразу разобраться с тем, что понимается под «расширяемостью». В моем понимание — это значит возможность добавить, расширить функционал существующего решения, при этом сохранить его целостность. В данном случае Hyper-V и XenServer именно этой идеологии и соответствуют. А вот у VMware я бы их коммутатор назвал бы не «расширяемым», а «заменяемым» — поскольку как только, допусти, ставите Cisco 1000V Nexus, то он заменяет собой vDS, нежели расширяет его возможности.
2) Защита от спуффинга и неавторизованных пакетов — здесь ситуация простая. Бесплатно воспользоваться защитой от нежелательных пакетов и атак можно только в Hyper-V. У Citrix, к сожалению, такого функционала нет, а у VMware вам придется докупать решение vShield App либо от сторонних партнеров.
Из остальных особенностей, наверное, стоит отметить то, что контроль доступа к виртуальным сетевым порта есть у всех, кроме бесплатного ESXi — т.е. у VMware это можно применить опять только за дополнительную плату. Ну и на последок хочется упомянуть о режиме прямого транка к ВМ, который есть только у Hyper-V.
Теперь давайте рассмотрим в сравнении механизмы миграции ВМ, а также наличие поддержки VXLAN.
1) Живая миграция — ее поддерживают все, кроме бесплатного ESXi. Количество одновременных миграций — параметр очень тонкий. У VMware он ограничен технически на уровне гипервизора, а Hyper-V — на уровне здравой логики и физических возможностей инфраструктуры. У Citrix нет четких официальных данных о количестве поддерживаемых одновременных миграций. Хоть у Hyper-V данный параметр и смотрится более привлекательным, но такой подход очень настораживающий — конечно, очень круто, что можно хоть 1000 ВМ одновременно мигрировать — но это же просто повесит вашу сеть. По незнанию такое может произойти, а вот если с головой дружба — то вы сами выставите нужный параметр — спасает то, что по умолчанию количество одновременных миграций равно 2-м — так что будьте внимательны. Что касается живой миграции виртуального стораджа ВМ — то этим могут похвастать только Hyper-V и vSphere Enterprise Plus. А вот смигрировать с хоста на хост (или куда еще) без общего хранилища под силу только Hyper-V — хотя функция действительно важная и полезная, жалко что только у одного гипервизора реализован данный механизм.
2) VXLAN — механизм абстракции и изоляции виртуальной сети с возможностью ее динамического расширения. Данный механизм очень необходим для непрерывных облачных сред или очень больших дата-центров с внедренной виртуализацией. На сегодняшний день только Hyper-V по умолчания поддерживает данный механизм — у VMware есть возможность реализовать данный механизм, но только за дополнительную плату, т.к. вам придется покупать стороннее расширение от Cisco.
Теперь давайте рассмотрим механизмы отказо- и катастрофоустойчивости, которые присутствуют в платформах виртуализации.
1) Встроенный бэкап — данный механизм бесплатно доступен только в Hyper-V, в XenServer — начиная с редакции Advanced, а если мы говорим про VMware — то начиная с Essentials Plus. На мой взгляд, немного странно не встроить и не сделать бесплатным данный механизм — представьте ситуации, что вы апробируйте виртуализацию, вы развернули виртуалки — и хрясь, все — конец!!! Не очень здорово, я думаю, это будет выглядеть — если уж хотите платформу протолкнуть на рынок — то сделайте это с заботой о клиенте (смайл).
2) Репликация ВМ — решение для катастрофоустойчивого сценария, когда вам необходимо иметь возможность поднять актуальные экземпляры ВМ в другом дата-центре. У VMware для реализации этого решения есть отдельный продукт — Site Recovery Manager (SRM) — а он стоит денег. У Citrix — та же ситуация — Platinum Edition — и вы получите данный функционал. У Hyper-V 3.0 — бесплатно.
3) Мониторинг гостевых приложений — механизм, который следит за состоянием приложения или службы внутри ВМ и на основе этих данных может предпринять какие-либо действия с ВМ, например, перезапустить ее в случае необходимости. Встроенный функционал для снятия параметров и принятия действий есть у Hyper-V, у VMware есть API — но нет самого решения для работы с данной функцией, а у Citrix нету ничего в это плане.
4) Правила распределения ВМ — механизм, который позволяет распределять ВМ на кластере так, чтобы они либо никогда не встречались на одном хосте, либо наоборот — никогда не разъезжались между собой. Citrix не умеет делать такие финты ушами, VMware это умеет во всех платных редакциях, где доступно HA, а Hyper-V как всегда — 0 рублей.
В остальном платформы более-менее одинаковы с точки зрения функциоанла, за исключением ESXi, конечно же.
За время проведения IT Camps по России и Москве я пообщался с очень разной аудиторией — а поэтому хочется сразу выделить еще несколько моментов.
1) «А когда Hyper-V научится пробрасывать USB-ключи с хоста внутрь ВМ?» — Скорее всего, никогда. На это есть и ограничения с точки зрения архитектуры гипервизора, и соображения с точки зрения безопасности и доступности сервисов.
2) «У VMware есть технология Fault Tolerance — когда что-то подобное будет в Hyper-V?» — Ответ будет похож на предыдущий, но… Я лично эту технологию считаю кастрированной — судите сами — вы ее включили. Но что вы будете делать с виртуалкой у которой может быть всего 1 процессор и не более 4 Гб ОЗУ? Контроллер домена туда засунете!? Свят-свят-свят — изыйди! Контроллеров домена всегда как минимум должно быть 2, а от сбоя на уровне гостевой ОС или гостевого приложения это вас не спасет — если BSOD наступит — то на обоих экземплярах ВМ. Ограничения на количество процессоров и ОЗУ обещают увеличить уже аж 3 релиза к ряду, если не больше — а воз и ныне там.
3) «У VMware среда лучше приспособлена под Linux-окружение — как дела у Hyper-V?» — Да, действительно — VMware гораздо лучше поддерживает Linux-гостей — это факт. Но и Hyper-V не стоит на месте — увеличивается и количество поддерживаемых дистрибутивов, и возможности служб интеграции.
И так — в общем, подведем итоги.
С точки зрения функционала — все гипервизоры примерно одинаковы, но я бы выделил VMware и Hyper-V как 2-х лидеров. Если сравнивать их между собой — то исключительно вопрос денег и функционала, а также вашей ИТ-инфраструктуры — чего у вас больше — Linux или Windows? У VMware все вкусные фичи стоят денег — у Microsoft — нет. Если у вас операционная среда на MS — то VMware станет для вас дополнительным затратами, причем серьезными — лицензии+поддержка+обслуживание…
Если у вас больше Linux — то тут наверное VMware, если среда смешанная — то вопрос открытый.
P.S> Я где-то слышал что на последнем квадрате Гартнера Hyper-V в лидерах — и обогнал vSphere, однако такой картинки я не нашел, так что на этот раз без Гартнера — если у кого есть инфа на эут тему — поделитесь, плз. Я нашел квадрат Гартнера от июня месяца — но это не то…
P.S.S> Что же, я готов к адскому расстрелу))) Что и как использовать — it's up to you, как говориться, но что же, — я жду патронов!
С уважением,
Человек-огонь,
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation
Сегодня тема для разговора будет уж (как я лично считаю) очень актуальной, если даже не сказать болезненной…
Да-да, я-таки решил провести функционально-экономическое сравнение 2-х ведущих платформ гипервизоров — Hyper-V 3.0 и VMware ESXi 5.0/5.1 между собой… Но потом я решил для полноты картины к сравнению добавить еще XenServer 6 от Citrix…
Я уже в предчувствии камнепада в свой огород, но все же будем держать оборону до конца — просьба занять соответствующую позицию, сторону, лагерь — кому как удобно — и под кат для начала боя…
Критерии сравнения
Прежде чем начать бой ни на жизнь, а на смерть, я предлагаю определить критерии, домены, зоны в пределах которых будут выделяться фичи и сравниваться между платформами. И так:
1) Масштабируемость и производительность
2) Безопасность и сеть
3) Гибкость инфраструктуры
4) Отказоустойчивость и непрерывность бизнес-процессов
Категории заданы — приступим!
Масштабируемость и производительность
Для начала я предлагаю взглянуть на сравнительную таблицу масштабируемости подопытных:
Как видно из таблицы, лидер здесь явный и однозначный — это Hyper-V 3.0. Причем здесь следует упомянуть о том, что производительность и масштабируемость гипервизора от MS никак не зависит от его платности. У VMware же ситуация обратная — в зависимости от того, сколько вечно зеленых цифровых вы заплатите — столько фишек вы и получите.
Так что для сравнения VMware у нас аж 2 столбца. XenServer явно ни к селу, ни к городу — он как-то застрял по середине…
Однако, если вспомнить многочисленные заявления Citrix о том, что «мы не компания которая делает решения по виртуализаци, а компания которая делает решения по оптимизации трафика», то XenServer — это инструмент для достижения этой задачи. Однако, тот факт, что Hyper-V и Citrix Xen — дальние родственники — и в результате такая разница в масштабиоуемости — удручает.
Про VMware сильно раздражал колебательный фактор их политики лицензирования ОЗУ — т.н. vRAM — ЧТО ФАКТИЧЕСКИ МОЖНО НАЗВАТЬ ВЫМОГАТЕЛЬСТВОМ. Мало того, что необходимо было лицензировать объем ОЗУ, который потребляют виртуалки, так помимо этого в случае необходимости апгрейда по этому самому параметру vRAM образовывалась дельта (т.к. такого параметра в ESX/ESXi 4.x просто-навсего не было) — а значит люди попадали на деньги. Правда, с выходом 5.1 VMware одумалась и отказалась от такого бредового формата — однако, такие жесткие ценооброзавательные конвульсии ни о чем хорошем свидетельствовать не могут…
С точки зрения технологической — мною лично реально ожидалась ситуация «ноздря-в-ноздрю» — но нет, такого не случилось, и интерес немного по угас… Я думаю первый блок сравнения особо больше в комментариях не нуждается — он достаточно «прозрачный».
Предлагаю перейти в следующей части данного блока сравнения — а именно к обзору некоторых фич, которые относятся к показателям производительности и масштабируемости. Рассмотрим функционал взаимодействия с дисковой подсистемой, таблица ниже:
Если посмотреть на данную таблицу, то здесь можно отметить следующие моменты:
1) Нативная поддержка 4Кб-секторов в виртуальных дисках — достаточно критичная вещь для ресурсоемких приложений. Высокопроизводительный СУБД как правило размещаются на дисках с большим размером страйпа. Поддержка данного механизма официально присутствует только в Hyper-V — у конкурирующих вендоров мне не удалось найти в официальной документации информации о поддержке данного механизма.
2) Максимальный размер LUN, подключаемого напрямую к ВМ — здесь ситуация следующая. У Citrix и VMware это параметр, который зависит именно от самого гипервизора напрямую, а у Hyper-V — скорее от того, какая ОС является гостевой. В случае использования Windows Server 2012 в качестве гостевой ОС есть возможность пробросить LUN размером свыше 256 Тбайт, у других гипервизоров данный параметр заканчивается на 64 Тбайт у VMware и не поднимается выше отметки в 15 Тб у Citrix соответственно.
С точки зрения функционала очень слабо смотриться XenServer — поддержка виртуализации Fiber Channel уже должно стать нормой — хотя бы на уровне платформы, однако ситуация в данном случае не является положительным примером. То, что у VMware политика «платности» фич уже все давно привыкли, так что на уровне самой платформы ESXi умеет это делать — вопрос только в том готовы ли вы за это столько платить? Редакция vSphere Enterprise Plus крайне не дешева, да еще и поддержку нужно покупать в обязательном порядке.
Наличие поддержки аппаратной разгрузки передачи данных в сетях SAN тоже является очень неплохим бонусом. Если раньше это было исключительной фичей VMware — vStorage API for Array Integration (VAAI), то Hyper-V 3.0 имеет в своем арсенале схожую технологию — Offload Data Transfer (ODX). Большинство вендоров СХД уже либо выпустили прошивки для своих систем с поддержкой данной технологии либо готовы сделать этов ближайшее время. Очень грустно за Citrix в данном конкретном случае — у XenServer никаких технологий оптимизации работы с SAN-системами нет.
Ну что же, с дисковой подсистемой разобрались — давайте теперь посмотрим какие же есть механизмы управления ресурсами у наших участников обзора.
С точки зрения фич картина в данной ситуации более-менее ровная, однако есть моменты на которые стоит обратить внимание:
1) Data Center Bridging (DCB) — под данной загадочной аббревиатурой скрывается ни что иное, как поддержка конвергентных сетевых адаптеров — Converged Network Adapter (CNA). Иными словами, конвергентный сетевой адаптер — это такой адаптер, который одновременно имеет аппаратные поддержку и ускорение для работы как в обычных сетях LAN Ethernet, так и в сетях SAN — т.е. идея состоит в том что, среда передачи данных, тип носителя — становятся унифицированными (это может быть оптика или витая пара), а поверх физического канала используется различные протоколы — SMB, FCoE, iSCSI, NFS, HTTP и прочие — т.е. с точки зрения управления у нас есть возможность динамически переназначать такие адаптеры перераспределяя их в зависимости от необходимости и типа нагрузки. Если взглянуть на таблицу, то Citrix не то чтобы не имеет поддержки DCB — есть некоторый список адаптеров CNA, которые поддерживаются — но в официальной документации Citrix XenServer 6.0 нет ни слова о поддержке DCB.
2) Качество обслуживания, поддержка QoS — по сути механизмы оптимизации трафика и гарантии качества канала передачи данных. Здесь все в принципе у всех в норме, за исключением бесплатного ESXi.
3) Динамическая память — вот тут история получается крайне интересная. По заявлениям Microsoft механизмы оптимизации памяти с помощью Dynamic Memory были существенно переработаны и позволили получить оптимизацию в работе с памятью — и тем самым увеличить плотность размещения виртуальных машин. К этому добавили файл интеллектуальной подкачки, который настраивается на каждую отдельную ВМ. Честно скажу, мне трудно судить насколько это эффективный механизм, однако при сравнения плотности размещения одинаковых ВМ на Hyper-V 2.0 и Hyper-V 3.0 разница была почти в 2 раза в пользу второго (Машинки были с виртуальным Windows Server 2008 R2). И вот тут возникает вопрос — у VMware целый арсенал фич по оптимизации работы с памятью, включая дедупликацию страниц памяти, что работает гораздо эффективнее. Но давайте более детально взглянем на эту ситуацию. У VMware есть 4 технологии оптимизации работы с памятью — Memory Balooning, Transparent Page Sharing, Compression и Swapping. Однако, все 4 технологии начинаю свою работу только в условиях повышенной нагрузки на ресурсы хост-системы, т.е. по своей манере действия они являются реактивными, нежели проактивными или оптимизирующими. Если еще учесть тот факт, что большинство современных серверных платформ поддерживают большие таблицы Large Page Tables, которые по умолчанию имеют размер в 2 Мбайта — это увеличивает производительность, то картина меняется — ибо ESXi не умеет дедуплицировать такие большие блоки данных — он начинает их разбивать на блоки меньшего размера, 4 Кбайта, а вот уже их он и дедуплицирует — но все эти операции стоят ресурсов и времени — так картина не такая уж однозначная с точки зрения полезности данных технологий.
Безопасность и сеть
Ну что же, с производительностью и масштабируемостью вроде бы мы разобрались — теперь самое время перейти к сравнению возможностей безопасности и изоляции виртуализованных сред.
Здесь следует выделить следующие моменты:
1) Single Root I/O Virtualization (SRIOV) — фактически это механизм пробрасывания физического адаптера внутрь виртуальной машины, однако, на мой взгляд немного некорректно сравнивать технологии VMware и Microsoft в этой области. DirectPath I/O, технология которую применяет VMware, действительно полностью пробрасывает слот PCI Express, а точнее устройство которое в нем находится — однако список устройств, которые совместимы с данной фичей крайне мал, да и вы фактически привязывайте вашу ВМ к хосту в довесок лишая ее практически всех бонусов в области оптимизации работы с памятью, высокой доступности, мониторинга сетевого трафика и прочих вкусностей. Исключением, разве что, в данной ситуации могут стать платформы на базе Cisco UCS — да и то — только в отдельных конфигурациях. Точно такая же ситуация у Citirix — не смотря на поддержку SRIOV, ВМ в которой активирована данная фича лишается всех возможностей в области премещения ВМ, возможности настроить списки доступа к ВМ (ведь карточка-то такая в обход свича виртуального пойдет) — так что все это крайне лимитировано. У Microsoft же скорее происходит виртуализация и профилирования такого адаптера — т.к. ВМ может быть и высокодоступной, и мигрировать с хоста на хост может, однако для этого необходимо наличие карт с поддержкой SRIOV в каждом хосте — тогда параметры адаптера SRIOV передут вместе с ВМ на новый хост.
2) Шифрование дисков и IPSec Offload — здесь картина явно однозначная, никто кроме как Hyper-V не работает с такими механизмами. Естественно, что для IPSec Offload понадобиться карточка с аппаратной поддержкой данной технологии, однако если вы запускаете ВМ с интенсивным взаимодействием с механизмами IPSec — то выигрыш вы получите от применения данной технологии. Что же касается шифрования дисков, то реализуется этот механизм с помощью BitLocker, однако возможности его применения в нашей стране сильно ограничены нормативными актами. В общем-то механизм интересный — зашифровать пространство, где располагаются ВМ с целью предотвращения утечки данных, но, к сожаления, широкого распространения данный механизм не получит до тех пор, пока не будут решены юридические и нормативные вопросы.
3) Virtual Machine Queue (VMQ) — Технология оптимизации работы с трафиком ВМ на уровне хоста и сетевых интерфейсов. Здесь, по чес_ноку, тяжело судить насколько DMVq лучше VMq — ибо на практике я не имел возможности сравнить эти технологии. Однако, заявлено что DMVq есть только у Hyper-V. Ну что же — есть так есть, наверное это хорошо, но в данном случае я оставлю без каких-либо комментариев данный пункт — ибо для меня лично нет сильной разницы, кроме букв — буду рад если кто-то прольет свет на разницу и эффект от динамичности пресловутого VMq.
Продолжим дальше — теперь я предлагаю взглянуть на возможности виртуальных коммутаторов, которые есть в арсенале у наших гипервизоров:
1) Расширяемые коммутаторы — здесь стоит сразу разобраться с тем, что понимается под «расширяемостью». В моем понимание — это значит возможность добавить, расширить функционал существующего решения, при этом сохранить его целостность. В данном случае Hyper-V и XenServer именно этой идеологии и соответствуют. А вот у VMware я бы их коммутатор назвал бы не «расширяемым», а «заменяемым» — поскольку как только, допусти, ставите Cisco 1000V Nexus, то он заменяет собой vDS, нежели расширяет его возможности.
2) Защита от спуффинга и неавторизованных пакетов — здесь ситуация простая. Бесплатно воспользоваться защитой от нежелательных пакетов и атак можно только в Hyper-V. У Citrix, к сожалению, такого функционала нет, а у VMware вам придется докупать решение vShield App либо от сторонних партнеров.
Из остальных особенностей, наверное, стоит отметить то, что контроль доступа к виртуальным сетевым порта есть у всех, кроме бесплатного ESXi — т.е. у VMware это можно применить опять только за дополнительную плату. Ну и на последок хочется упомянуть о режиме прямого транка к ВМ, который есть только у Hyper-V.
Гибкость инфраструктуры
Теперь давайте рассмотрим в сравнении механизмы миграции ВМ, а также наличие поддержки VXLAN.
1) Живая миграция — ее поддерживают все, кроме бесплатного ESXi. Количество одновременных миграций — параметр очень тонкий. У VMware он ограничен технически на уровне гипервизора, а Hyper-V — на уровне здравой логики и физических возможностей инфраструктуры. У Citrix нет четких официальных данных о количестве поддерживаемых одновременных миграций. Хоть у Hyper-V данный параметр и смотрится более привлекательным, но такой подход очень настораживающий — конечно, очень круто, что можно хоть 1000 ВМ одновременно мигрировать — но это же просто повесит вашу сеть. По незнанию такое может произойти, а вот если с головой дружба — то вы сами выставите нужный параметр — спасает то, что по умолчанию количество одновременных миграций равно 2-м — так что будьте внимательны. Что касается живой миграции виртуального стораджа ВМ — то этим могут похвастать только Hyper-V и vSphere Enterprise Plus. А вот смигрировать с хоста на хост (или куда еще) без общего хранилища под силу только Hyper-V — хотя функция действительно важная и полезная, жалко что только у одного гипервизора реализован данный механизм.
2) VXLAN — механизм абстракции и изоляции виртуальной сети с возможностью ее динамического расширения. Данный механизм очень необходим для непрерывных облачных сред или очень больших дата-центров с внедренной виртуализацией. На сегодняшний день только Hyper-V по умолчания поддерживает данный механизм — у VMware есть возможность реализовать данный механизм, но только за дополнительную плату, т.к. вам придется покупать стороннее расширение от Cisco.
Отказоустойчивость и непрерывность бизнес-процессов
Теперь давайте рассмотрим механизмы отказо- и катастрофоустойчивости, которые присутствуют в платформах виртуализации.
1) Встроенный бэкап — данный механизм бесплатно доступен только в Hyper-V, в XenServer — начиная с редакции Advanced, а если мы говорим про VMware — то начиная с Essentials Plus. На мой взгляд, немного странно не встроить и не сделать бесплатным данный механизм — представьте ситуации, что вы апробируйте виртуализацию, вы развернули виртуалки — и хрясь, все — конец!!! Не очень здорово, я думаю, это будет выглядеть — если уж хотите платформу протолкнуть на рынок — то сделайте это с заботой о клиенте (смайл).
2) Репликация ВМ — решение для катастрофоустойчивого сценария, когда вам необходимо иметь возможность поднять актуальные экземпляры ВМ в другом дата-центре. У VMware для реализации этого решения есть отдельный продукт — Site Recovery Manager (SRM) — а он стоит денег. У Citrix — та же ситуация — Platinum Edition — и вы получите данный функционал. У Hyper-V 3.0 — бесплатно.
3) Мониторинг гостевых приложений — механизм, который следит за состоянием приложения или службы внутри ВМ и на основе этих данных может предпринять какие-либо действия с ВМ, например, перезапустить ее в случае необходимости. Встроенный функционал для снятия параметров и принятия действий есть у Hyper-V, у VMware есть API — но нет самого решения для работы с данной функцией, а у Citrix нету ничего в это плане.
4) Правила распределения ВМ — механизм, который позволяет распределять ВМ на кластере так, чтобы они либо никогда не встречались на одном хосте, либо наоборот — никогда не разъезжались между собой. Citrix не умеет делать такие финты ушами, VMware это умеет во всех платных редакциях, где доступно HA, а Hyper-V как всегда — 0 рублей.
В остальном платформы более-менее одинаковы с точки зрения функциоанла, за исключением ESXi, конечно же.
Прочие прочести
За время проведения IT Camps по России и Москве я пообщался с очень разной аудиторией — а поэтому хочется сразу выделить еще несколько моментов.
1) «А когда Hyper-V научится пробрасывать USB-ключи с хоста внутрь ВМ?» — Скорее всего, никогда. На это есть и ограничения с точки зрения архитектуры гипервизора, и соображения с точки зрения безопасности и доступности сервисов.
2) «У VMware есть технология Fault Tolerance — когда что-то подобное будет в Hyper-V?» — Ответ будет похож на предыдущий, но… Я лично эту технологию считаю кастрированной — судите сами — вы ее включили. Но что вы будете делать с виртуалкой у которой может быть всего 1 процессор и не более 4 Гб ОЗУ? Контроллер домена туда засунете!? Свят-свят-свят — изыйди! Контроллеров домена всегда как минимум должно быть 2, а от сбоя на уровне гостевой ОС или гостевого приложения это вас не спасет — если BSOD наступит — то на обоих экземплярах ВМ. Ограничения на количество процессоров и ОЗУ обещают увеличить уже аж 3 релиза к ряду, если не больше — а воз и ныне там.
3) «У VMware среда лучше приспособлена под Linux-окружение — как дела у Hyper-V?» — Да, действительно — VMware гораздо лучше поддерживает Linux-гостей — это факт. Но и Hyper-V не стоит на месте — увеличивается и количество поддерживаемых дистрибутивов, и возможности служб интеграции.
Заключение
И так — в общем, подведем итоги.
С точки зрения функционала — все гипервизоры примерно одинаковы, но я бы выделил VMware и Hyper-V как 2-х лидеров. Если сравнивать их между собой — то исключительно вопрос денег и функционала, а также вашей ИТ-инфраструктуры — чего у вас больше — Linux или Windows? У VMware все вкусные фичи стоят денег — у Microsoft — нет. Если у вас операционная среда на MS — то VMware станет для вас дополнительным затратами, причем серьезными — лицензии+поддержка+обслуживание…
Если у вас больше Linux — то тут наверное VMware, если среда смешанная — то вопрос открытый.
P.S> Я где-то слышал что на последнем квадрате Гартнера Hyper-V в лидерах — и обогнал vSphere, однако такой картинки я не нашел, так что на этот раз без Гартнера — если у кого есть инфа на эут тему — поделитесь, плз. Я нашел квадрат Гартнера от июня месяца — но это не то…
P.S.S> Что же, я готов к адскому расстрелу))) Что и как использовать — it's up to you, как говориться, но что же, — я жду патронов!
С уважением,
Человек-огонь,
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation
