vSphere 5.1 vs Hyper-V R3. Оценка стоимости ресурсов.

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

То есть вместо того, чтобы платить за фиксированные ресурсы - количество ЦПУ, объём памяти и объёмы ГБ на СХД пользователь платит только за количество реально использованных мощностей поставщика - количество гГц, количество IOPS и утилизированную память. Основываясь на этих данных облачный провайдер уже может выставить счёт заказчику.

Hyper-V
Сам гипервизор позволяет измерять количество гГц, объём занятой памяти, количество переданной по сети информации и объём диска ВМ, но не позволяет считать количество IOPS, что тоже было бы неплохо.

Hyper-V не имеет какого-либо графического интерфейса для составления отчётов, управления стоимостью ресурсов, и т.д. Для создания отчёта об использовании ресурсов необходимо использовать скрипты на PowerShell, а отчёты потом импортировать в соответствующее ПО.

System Center Service Manager 2012 SP1
Оценка стоимости утилизации ресурсов реализована в специальном дполнении Center Cloud Services Process Pack для System Center Service Manager 2012 SP1.

vSphere
VMware предлагает отдельный продукт - vCenter Chargeback Manager, который позволяет считать самые разнообразные параметры и автоматически выставлять счета.

vSphere 5.1 vs Hyper-V R3. Интеграция с СХД.

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

Поддержка SAN 
Обе системы поддерживают основные блочные протоколы доступа - FC, iSCSI, FCoE, тогда как на файловом уровне Hyper-V использует SMB, а vSphere - NFS. Я бы сказал, что это полный паритет.

Do it yourself (DIY) или дешёвые СХД
Системы хранения данных обычно являются самым дорогим компонентом, поэтому некоторые предпочитают собрать самим более дешёвое решение.

VMware предлагает Virtual Storage Appliance (VSA), работающий как ВМ на хосте и использующий локальные диски для создания отказоустойчивого решения.

Hyper-V предлагает встроенную поддержку iSCSI таргета и SMB шары.

Кроме того, существуют сторонние решения для обоих решений типа LeftHand VSA, Datacore, StarWind и т.д.

Выгрузка операций на массив
Некоторые операции гораздо выгоднее выполнять на самом массиве, а не на хосте - например, клонирование ВМ или перемещение на другой LUN.

На данный момент VMware VAAI, в отличие от Hyper-V ODX, может использовать данные примитивы для клонирования ВМ, а также поддерживается более широким количеством производителей.

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

vSphere в данном случае предлагает два механизма:

SIOC (Storage IO Control) - аналог QoS для СХД. Пока задержки не достигнут критического уровня все ВМ потребляют необходимое им количество ресурсов, в случае выхода за критическую отметку - ВМ с большим приоритетом получают большую полосу пропускания.

Storage DRS - данный механизм по необходимости перемещает ВМ между датасторами в автоматическом режиме для оптимизации нагрузки.

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

Максимальный размер виртуального диска поддержка дисков с размером блока 4k
Для vSphere максимальный размер диска составляет 2ТБ-512байт, тогда как Hyper-V поддерживает два формата - VHD и VHDX. Последний ограничен размером в 64ТБ.

Также на данный момент vSphere, в отличие от Hyper-V, не поддерживает Advanced Format и диски с размером сектора в 4кб.

Репликация 
Обе платформы имеют встроенные механизмы репликации данных, работающие независимо от подлежащей СХД.

Управление и автоматизация работы с СХД
Virtual Machine Manager использует протокол SMI-S для интеграции с массивами, как следствие операции проводимые с СХД ограничены возможностями данного протокола.

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

Кэширование для VDI
Boot storm - понятие описывающее резкую пиковую загрузку на СХД из-за массовых логинов пользователей утром при приходе на работу. Для снижения нагрузки на СХД используются алгоритмы интеллектуального кэширования данных.

Данная технология есть у обоих продуктов - CBRC (Content Based Reading Cache) у vSphere и CSV Cache у Hyper-V.

Оригинал: http://up2v.nl/

vSphere 5.1 vs Hyper-V R3. Правила близости (affinity rules)

Этим постом мы открываем серию по сравнению функционала vSphere 5 и Hyper-V R3. Рассматриваться будут ESXi 5.1 + vCenter 5.1 и Hyper-V R3 + Virtual Machine Manager 2012 SP1, который в данный момент находится в состоянии бета тестирования, и финальная версия которого выйдет в начале следующего года.

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

Настройка правил близости в vSphere 5.1 
Правила задаются в свойствах кластера. Настройка доступна как через вэб, так и через классический клиент. Правила начинают действовать сразу после создания.

Существует три вида правил:
VM-VM affinity rules - указанные ВМ будут работать на одном хосте
VM-VM anti-affinity rules - указанные ВМ будут работать на разных хостах
Host-VM affinity - ВМ будет работать на определённой группе хостов.

Данные виды бывают двух типов:
Should - "желательное" правило, может быть нарушено в случае необходимости (например, недостаток хостов в кластере)
Must - обязательное правило, не может быть нарушено ни в каком случае.

Также в vSphere 5.1 была представлена функция Storage DRS, предоставляющая такие же функции, но для жёстких дисков виртуальных машин.

Детали работы vSphere Affinity Rules описаны отдельным постом: http://blog.vadmin.ru/2012/09/affinity-rules.html

Настройка правил близости в SCVMM 2012 SP1
В данном релизе представлена новая функция - availability set. Данная опция настраивается на уровне каждой отдельной виртуальной машины, после чего VMM будет пытаться держать ВМ входящие в одну группу на разных хостах.


Пользователь может указать хосты на которых, по возможности, будут работать данные или хосты на которых ВМ не могут работать.


Мне не удалось найти опции заставить работать ВМ на одном хосте.


Оригинал: http://up2v.nl/

Hyper-V R2 SP1 - Dynamic Memory

Появилась информация о громком технологическом "прорыве" Microsoft - Dynamic Memory. Желающие могут скачать официальную презентацию с сайта TechEd.

Я расскажу о том как это работает и почему маркетинг Microsoft снова вешает лапшу на уши совершенно не стесняясь.

Dynamic Memory = Balloon + Hot-Add. Вот и весь "прорыв". Balloon у VMware существует с незапамятных времен, Memory Hot-Add появилась с выходом vSphere, год назад. Единственное, что добавили в MS - это автоматический Hot-Add.

Итак, по заверениям MS, Dynamic Memory - это НЕ overcommitment. Правда? Очень забавно. Приводится пример, когда две машины используют память попеременно, и сначала им дается дополнительная память через Hot-Add, а потом отбирается баллонным драйвером.
Overcommitment, согласно определения, когда сумма Configured Memory больше физической памяти на сервере. Поэтому Dynamic Memory - НЕ overcommitment только в одном случае, если после всех Hot-Add все еще остается свободная физическая память. Но в таком случае зачем нужен баллонный драйвер? Момент, когда он включается - это нехватка физической памяти, когда нужно отобрать немножко физической памяти у одной машины и отдать другой.
Предположим, для сохранения условия "НЕ overcommitment", что баллонный драйвер будет включаться автоматом, после того как пиковая нагрузка миновала и машина вернулась к обычному потреблению памяти. Однако поскольку Hot-Remove для памяти еще не придумала даже Microsoft, со всей ее армией инженеров и подробным знанием внутренностей Windows, параметр Configured Memory остается увеличенным, хотя SCVMM и будет нам показывать, что выделение памяти уменьшилось. И поскольку "НЕ overcommitment = SUM(Configured Memory) < Physical Memory", включение баллонного драйвера абсолютно бессмысленно.
Вернемся к презентации - показывается, что одной машине надо памяти, и память отбирается у другой машины. Но простите, это же и есть классический Memory Overcommitment через Balloon! Если мы НЕ в состоянии memory overcommitment, то каждой машине хватает физической памяти и ее просто не нужно ни у кого отбирать.

Какой из этого вывод? Очевидный. Microsoft потихоньку догоняет VMware по функционалу, хотя все еще остается в положении догоняющего. А маркетинг MS напускает побольше FUD'а, вводит новые термины, означающие то же, что и раньше, но другое. Не можешь предложить что-то технологическое - запутай, запугай.

MCTS: Hyper-V - настоящая причина

Коллеги, меня многие спрашивали почему и зачем я сертифицировался по Hyper-V, и я решил признаться.

Настоящая причина вот:

MCTS: Hyper-V + SCVMM

70-403 MCTS: Microsoft System Center Virtual Machine Manager 2008, Configuration
70-652 MCTS: Windows Server Virtualization, Configuration

Чемпионат по виртуализации от MS

Microsoft проводит “Чемпионат по виртуализации” с Ford Focus в качестве главного приза.

С одной стороны начинание интересное, полезное. А с другой… Это полный и безоговорочный bullshit. Начнем с того, что заявлен проект по *виртуализации*, т.е. можно ожидать, что проекты не на платформе MS могут занять хоть какие-то места. Ан нет, в том-то и фокус!

Вот смотрите, предположим у нас есть два проекта:
Вариант 1: 100 хостов VMware vSphere, два сайта, disaster recovery и так далее. Стоимость проекта с 7ю нулями.
Вариант 2: 2 хоста с Hyper-V, железо наколенной сборки, 5-6 виртуальных машинок для фирмы из 25 человек, SCVMM. Стоимость проекта – ну пусть будет 9 тыс долларов.

Считаем баллы:

* 5 баллов начисляется за факт размещения проекта на Сайте конкурса. ( 5 / 5 )
* 1 балл начисляется за каждый сервер, использованный при реализации проекта, но не более 5 баллов. ( 10 / 7 )
* 10 баллов начисляется за использование при реализации проекта платформы «Hyper-V» или «Hyper-V R2». ( 10 / 17 )
* 5 баллов начисляется за использование при реализации проекта «System Center». ( 10 / 22 )
* 3 балла начисляется за отказоустойчивость. ( 13 / 25 )
* 5 баллов начисляется за использование при реализации проекта «Web Server» ( 18 / 25 )

Итого: извините, но это попросту маркетинговый фарс.

Kroll: ESX + Hyper-V

Буквально неделю назад Chris Steffen, архитектор компании Kroll Factual Data и по совместительству Microsoft MVP: Virtualization, опубликовал 9 пунктов против ESX.

Но удивительные дела творятся в Kroll.

В апреле 2009 Chris Steffen публикует отчет:

После внедрения Windows 2008 85% продуктивных серверов компании виртуализованы на платформе Hyper-V + System Center с коэффициентом консолидации 30(!). 650 физических серверов были смигрированы на 22 хоста.

В июле 2009 Joel Fuller, архитектор Kroll Ontrack, публикует отчет о виртуализации 500 файл-серверов в Kroll Ontrack на платформе VMware.

С учетом уже упомянутых идей, которые высказал Chris Steffen, хочется пожелать компании Kroll навести порядок среди инженеров.

Очередные 9 пунктов про Hyper-V

Microsoft опубликовала мнение гостя, независимого эксперта о том, почему Hyper-V отлично подходит сектору Enterprise.

Но не тут-то было, Eric Gray по традиции жжет напалмом. В чем же самая соль опубликованного?

MVP по виртуализации Microsoft, Chris Steffen, утверждает:

Надеяться на Memory Overcommitment для обеспечения отказоустойчивости потенциально опасно и может привести к серьезному падению производительности. (выделение мое)

Ну так ведь никто и не утверждает, что Memory Overcommitment - это полностью безопасная технология. Действительно, при неаккуратных действиях можно "положить" важные сервисы. Но вообще-то говоря, при неаккуратном вождении можно задавить насмерть несколько человек, кухонным ножом оттяпать себе палец, и выстрелить из ружья себе в ногу. Memory Overcommitment - это инструмент, который может вам сэкономить много памяти и, как следствие, железа и лицензий, если вы будете им пользоваться аккуратно.
Chris Steffen продолжает:

Я никогда не позволю своим продуктивным хостам уйти в Memory Overcommitment.

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

Постойте, но ведь мы что-то подобное уже слышали. В CIO Magazine не так давно никто иной как Chris Steffen назвал VMotion "хитрым трюком" и заявил:

Живой миграции ВМ не будет ни в одной продуктивной среде, за которую я отвечаю.

Однако как поменялась позиция! Что же он говорить теперь, когда в Hyper-V есть Live Migration?

А также не забывайте, что при использовании пакета System Center, решение Microsoft позволяет осуществлять живую миграцию ВМ...

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

Так ли бесплатен Hyper-V и так ли дорога vSphere?

Не утихают споры о нужности / ненужности Memory Overcommitment. Сторонники Hyper-V утверждают, что все эти модные штучки с памятью не нужны, цена лицензии VMware выше, чем стоимость памяти, которая сейчас стоит "like a trash".
Лично мне захотелось посчитать и получить цифры, которые не вешают лапшу на уши как маркетинг.

Методика расчета

- считается полная стоимость системы, включая железо и лицензии.
- не считается стоимость СХД, подразумевается, что СХД в обоих случаях будет использоваться и стоить одинаково.
- предполагается, что на всех хостах будет достаточное количество ВМ с Windows и считается стоимость Windows Datacenter для всех хостов.
- цены взяты рекомендованные вендорами для US.

Считается, что проект "Виртуальные машины" живет на полностью выделенном для него оборудовании. В качестве железа взяты блейд-серверы HP BL490c G6, СХД подключается по Fibre Channel.

ESX vs Hyper-V: горячее подключение/отключение дисков

VMware vSphere 4 поддерживает несколько вариантов горячего управления дисковой подсистемой:

• Расширение VMFS разделов
• Горячее расширение виртуальных дисков
• Горячее подключение/отключение виртуальных дисков

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

• Выделить дополнительное место / физические диски на SAN для соответствующего LUN
• Расширить VMFS Datastore, используя выделенное только что место
• Расширить существующие или создать новые виртуальные диски
• Расширить тома в соответствующих ВМ 

Все это без перезагрузки, с нулевым простоем.

Все больше и больше слоев FUD'а

Невероятно, но старая байка про то, что VMware добавляет еще один слой, до сих пор рассказывается Microsoft в их Virtualization Comparison Brochure. Довольно удивительно и совершенно нечестно - использование термина "слой" лишь для порядка следования в иерархии, но не в смысле объема. И что, черт побери, слой виртуализации делает поверх слоя приложений?

В данном случае Microsoft хочет доказать, что если у вас нет виртуализации VMware, то нет и VMware. В общем-то соответвует действительности, но слоев на самом деле столько же.
Я взял право сделать несколько поправок к материалу Microsoft и рад показать еще три более корректных варианта представления слоев виртуализации.

Veeam будет поддерживать Hyper-V

По словам Дага Хейзелмана (Doug Hazelman), директора Global Systems Engineers Group, Veeam будет поддерживать Hyper-V и Windows Server 2008.

Ждем Veeam Backup для Hyper-V :)

Hyper-V делают в Китае?

Извините, не смог удержаться :)

В качестве полемики с сотрудниками MS

А конкретно с Алексеем Кибкало.

На данный момент известно 14 критических обновлений безопасности (сравним с 36 критическими и 31 обновлений безопасности для VMware ESX Server 3.5 за тот же срок), а всех исправлений к Windows Server 2008 на сегодня известно 41 (сравним с 148 исправлениями для VMware ESX Server 3.5). Очевидно, что большая часть новых обновлений включает в себя часть предыдущих, заменяя их. Однако, если их устанавливать их не все сегодня, а постепенно — сразу после выхода, то количество установок было было бы именно такое. Эти числа приведены для полного варианта установки и наличии всех ролей и функций ОС.

Насколько же изменится ситуация в варианте установки Server Core?

Говоря языком цифр, получится следующее. Для Server Core со всеми ролями и функциями количество критических обновлений меньше на 35%, суммарное количество всех обновлений на 59%, а перезагрузок при их установке потребуется на 62% меньше, чем для полного варианта установки.

1. Наличие бОльшего количества обновлений и даже критических обновлений для ESX не говорит ни о чем, кроме бОльшего количества обновлений.
2. В обновления ESX включаются так же и обновления драйверов (!). Напомните пожалуйста, как там с обновлением драйверов у Hyper-V?
3. При наличии лицензии VMotion (Live Migration) даунтайма для сервисов при установке обновлений на хост нет вообще. Сравним с Hyper-V, у которого Live Migration только-только выйдет.
4. Обновления VMware выпускаются обычно сразу по несколько и ставятся за один раз, что автоматически опровергает расчеты количества перезагрузок.

Итого, вроде и цифры есть, а толку в них?

Интересна и реакция данного сотрудника Microsoft на вот этот пост у меня в блоге.

Даже не буду комментировать бред параноидального MS-ненавистника.

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

У меня возник вопрос: параноидальным MS-ненавистником назвали Stu (vinternals.com) или меня? И лично я не припомню никаких комментариев с цифрами, не говоря уже о том, чтобы я что-то удалял (за исключением спама).
Да и MS-ненавистником я не являюсь ни в какой мере, за исключением пожалуй, неприязни к многим методам маркетинга MS. И я рад тому, что в рунете есть возможность дискутировать на эту тему с НЕмаркетинговыми специалистами.

Как работает маркетинг Microsoft?

В связи с очередным обострением священной войны между Hyper-V и ESX силами Scott Drummonds (VMware) и Jeff Woolsey (Microsoft) (1, 2, 3), нашлась интересная ссылка (спасибо Duncan Epping).

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

Upd: В данном случае интересно то, что это прямые слова сотрудника Microsoft, а не пересказ кем-то из третьих лиц. С учетом того, что хоть это мнение и не официальная позиция Microsoft, но встречается (точнее встречалось) у практически любого сотрудника MS как под копирку.

Краткое содержание.

Microsoft утверждает, что необходимость в Live Migration (VMotion) - миф. Абсолютное большинство заказчиков все равно планируют обслуживание и установку обновлений на физические хосты в офф-тайм, нерабочее время. Так что нет никакой разницы между 5-20 секундами даунтайма для Quick Migration и менее одной секунды даунтайма для VMotion. Их просто некому будет замечать.

Датировано 24.04.2008

Сравните с текущей позицией Microsoft и размахиванием Live Migration как сверхдостижением, которое нужно всем. Настолько, что Microsoft не стесняется им размахивать в Beta и RC - ведь у них есть теперь Live Migration!

Есть и еще один "факт", который полюбился маркетингу Microsoft - ведь у VMware для виртуализации на один слой больше! У VMware есть слой виртуализации, гипервизор, в то время как у Microsoft есть просто ОС. И тут действительно, добавить к словам Duncan Epping нечего, "вы запускаете ваши ВМ напрямую на железе?"

Мифы и реальность Microsoft

Stu (vinternals.com) нашел очень интересный документ, опубликованный самой Microsoft, описывающий достижения Microsoft по консолидации серверов на платформе Hyper-V. Только холодные и бездушные цифры. Сама статья и пост Stu на английском, поэтому перевод мой (в сокращенном виде).

IT служба Microsoft разработала стандарт, определяющий, какие именно машины подлежат виртуализации. Под него подпало большое количество лабораторных и development серверов с очень низкой загрузкой и требованиями. Для хостинга данных серверов используются 4-сокетные серверы с 16 и 24 ядрами и 64ГБ памяти, что дает возможность запуска большого количества виртуальных машин (ВМ) со средним соотношением 10.4 ВМ на хост.

Представьте себе, сервер с 16 ядрами и более 32ГБ памяти тянет только 10.4 "лабораторных машины с очень низкой загрузкой". А теперь представьте сколько "боевых" машин с рабочей нагрузкой смогут там работать.

Для рабочих машин Microsoft IT использует 2-сокетные серверы с 8 или 12 ядрами и 32ГБ памяти.
...
В среднем, хост-серверы с 8 процессорами и 32ГБ памяти хостят 5.7 ВМ на хост.

Меньше 6 машин на 8-процессорную железку с 32ГБ!

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

При использовании Windows Server 2008 failover clustering необходимо хранить каждую ВМ на отдельном LUN. Поскольку администратор должен предоставить доступ к каждому разделяемому хранилищу под той же буквой, то в failover cluster может работать максимум 23 машины. Microsoft IT может обойти данное ограничение, используя точки монтирования и группы виртуальных машин, но было сочтено, что в данной конфигурации администрирование станет слишком сложным. Из-за этого ограничения Microsoft IT приняла в качестве стандарта использование кластеров из 3-х узлов, сконфигурированных так, чтобы выдерживать отказ 1 узла.

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

При миграции машины в Windows Server 2008 failover cluster сервисы должны сохранить состояние ВМ, передать контроль над разделяемым хранилищем другому узлу и перезапустить ВМ из сохраненного состояния. Несмотря на то, что процесс занимает всего несколько секунду, ВМ остается в этот промежуток времени недоступной. Если же администратору необходимо перезагрузить все хосты в кластере (например, при установки обновлений безопасности), ВМ в кластере придется мигрировать несколько раз, и соотв. каждый раз ВМ будут недоступны. Таким образом Microsoft IT определила, что виртуальные машины высокой доступности могут иметь большее время недоступности, чем виртуальные машины на одиночных серверах, в случаях простых запланированных простоев, таких как установка обновлений ПО.

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

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

Общий смысл статьи очевиден. Все расчеты стоимости можно выкинуть в помойку, теорию и коэффициенты консолидации тоже. Сравнения производительности к черту. О сравнении эффективности датацентров можно даже и не задумываться. В свете холодных и бездушных фактов маркетинговые ходы для VMware не нужны. С Microsoft, рождающей подобные документы и выставляющей их в публичный доступ, VMware просто не нужен никакой маркетинг. Заранее прошу прощения за то, что ставлю под вопрос рабочие места 90% отдела маркетинга VMware. Пожалуйста, в любом случае оставьте Джона Тройера (John Troyer), ему придется восстанавливать сообщество после того, как мы все помрем со смеху.

Оригинальная статья Microsoft: http://technet.microsoft.com/en-us/library/cc974012.aspx
Пост Stu: http://vinternals.com/2009/04/microsoft-myths-and-realities

10 "мифов" от VMware развенчаны Microsoft

Gabrie van Zanten написал очень развернутый комментарий на "развенчание 10 мифов". В меру сил перевел "разбор полетов" на русский язык.

***

Сегодня посмотрел видеоролик, выпущенный Microsoft якобы для "развенчания мифов" о VMware ESX. Разозлился - почему нельзя просто играть честно? Я считаю, что Hyper-V достаточно хорош для версии 1.0, но все эти маркетинговые кампании, уверяющие нас, что он уже достаточно стабилен и "взросл"... Почему нельзя признать, что Hyper-V 1.0 не конкурент ни Xen, ни ESX и просто рассказать про новую функциональность R2?

В видеоролике они собираются развенчать 10 мифов, 10 пунктов, в которых VMware некорректно сравнивает ESX и Hyper-V. При этом сами "развенчания" весьма некорректны. Итак, мой список:

1) У Microsoft нет Live Migration

Согласно двум джентльменам в видеоролике у Microsoft есть Live Migration: "В Windows 2008 R2, которая очень скоро выйдет, есть Live Migration". Точно!!! В R2 есть Live Migration, которая работает так же, как и VMware VMotion. Миф развенчан!!!
Хотя нет, погодите. Windows 2008 R2 все еще в бете, и пока нет официальной даты выхода. Последний раз я что-то слышал про начало 2010, но до него еще 8 месяцев. Так что на сегодня (Апрель 2009) Hyper-V не поддерживает Live Migration.

2) Кластерная файловая система

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

3) Hyper-V - продукт версии 1.0

Джентльмены ссылаются на VMware, которая утверждает, что Hyper-V - продукт версии 1.0, а следовательно, недостаточно масштабируем, недостаточно "взросл" и недостаточно быстр. В противовес приводится 4500 виртуальных машин, работающих под управлением Hyper-V в датацентрах Microsoft. Позвольте, но это ровным счетом ничего не говорит о масштабируемости, стабильности и надежности. Если у вас все системы 1-к-1 (одна ВМ на один хост), то у вас точно так же целых 4500 машин, и наверняка они работают весьма стабильно. Нет, я, конечно, не верю, что у Microsoft все эти машины работают 1-к-1, но никаких подтверждений стабильности и масштабируемости я тоже не вижу. Если хотите действительно развенчать миф, то приведите аргументы получше.

4) Низкая производительность

Должен признать, что производительность Hyper-V выглядит куда лучше, чем я ожидал. Но вот проблема: во всех этих тестах слишком мало деталей "что" и "как". Пожалуйста, кто-нибудь, покажите мне хороший проработанный отчет о тесте, который я могу собственноручно воспроизвести в собственной лаборатории, и который охватывает три главных гипервизора на сегодня - ESX, Hyper-V и Xen.

5) "Отпечаток"

А так ли велика разница в размере "отпечатка", и вдобавок поднимается вопрос "а так ли это вообще важно?"
Должен с ними согласиться. Если вы собираетесь установить ESX или Hyper-V на диск, то не так уж и важно, сколько занимает места гипервизор или ОС с гипервизором, 2 ГБ или 10. Сегодня самый маленький доступный на рынке диск имеет размер 36ГБ, и только если очень поискать, то можно найти 18. К тому же вы в большинстве случаев можете считать этот диск "потерянным", на нем не будут размещаться виртуальные машины.
Но совсем другой вопрос, разумеется, про бездисковые серверы и загрузке с USB Flash. Здесь размер действительно играет большое значение.

Отпечаток в оперативной памяти, на мой взгляд, не имеет решающего значения. По умолчанию ESX использует 272МБ для загрузки ядра, сервис-консоли и агентов управления. Тем не менее, большинство администраторов устанавливают резерв памяти для консоли на уровне 800МБ. Windows 2008 Server Core с установленным Hyper-V будет занимать примерно столько же.

Самый большой вопрос: а миф ли это вообще? Есть ли конечным пользователям какое-то дело до этого?

6) Широкая поддержка оборудования

Джентльмены показывают скриншот сайта VMware и говорят, что VMware сравнивает HCL (список поддерживаемого оборудования) с Citrix и VirtualIron, но не с Hyper-V HCL. Чисто формально они право, однако если взглянуть поближе, то VMware дает комментарий: "Microsoft заявляет об очень широком HCL потому что в Hyper-V используются драйверы для Windows 2008. Однако драйверы всегда были повинны в большой доле проблем со стабильностью Windows." Я предлагаю джентльменам возразить на данное замечание вместо утверждения, что Hyper-V может работать на любом оборудовании.

Еще один момент, который следует прояснить - большинство драйверов сторонних вендоров не были оптимизированы для Hyper-V и не были оптимизированы для высокой производительности. Я припоминаю некоторые сетевые адаптеры, к которым шли драйверы размером 45 МБ со всеми модными функциями, о которых я никогда не просил, и которые явно не добавляли системе стабильности. Вдобавок, список сетевых адаптеров, которые вы можете использовать, если хотите иметь поддержку транков, VLAN'ов и автоматического переключения линков при отказах, весьма невелик. Что в конечном итоге ведет нас к еще более короткому списку оборудования, действительно совместимого с Hyper-V.

7) Управление

Они утверждают: "В VMware говорят лишь о Virtual Machine Manager, они (VMware) не говорят о полном Systems Center". В данном случае джентльмены хотят сказать, что следует сравнивать vCenter не с System Center Virtual Machine Manager, а с полным Systems Center. Довольно сложно понять к чему это вообще, и к тому же я не уверен, что в VMware что-то вообще утверждали по данному вопросу.

8) Memory Overcommit

Утверждение джентльменов в том, что memory overcommit (MO) полезно лишь в очень редких случаях, и они ни разу не видели соотношение 2 к 1, о котором говорит VMware. Если вы хотите действительно техническую дискуссию, то они правы, что MO не дает соотношение 2 к 1. Но что они забыли упомянуть, так то, что MO лишь одна часть из технологий экономии памяти, а наибольший эффект достигается технологией "Transparent Page Sharing" (TSP). Эти две технологии, работающие вместе, могут давать соотношение 2 к 1 и даже более (у некоторых моих заказчиков).

Следующий пункт. Если вы тщательно мониторите свои виртуальные машины и выдаете им ровно необходимое количество памяти, то MO вам не нужно. Честно, я никогда не даю виртуальной машине 893МБ памяти. Скорее всего, это будет 1ГБ или даже 1,5ГБ, чтобы не попасть в процесс свопирования при внезапном пике нагрузки. Если же у вас на хосте работает 50-60 ВМ, то вы явно некоторое немаленькое количество памяти расходовали бы впустую, если бы не MO. Вдобавок, это экономит мне немало времени, которое пришлось бы потратить на мониторинг сколько памяти требуется виртуальной машине, 893МБ, 900МБ или может быть 1150МБ.

9) Более низкая цена из расчета на одну ВМ

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


Как уже было рассмотрено в п. 8, технологии Memory Overcommit работают и позволяют экономить память, а в конечном итоге уменьшить количество требуемых хостов.

Во второй части "развенчания" мифа номер 9, они говорят о том, что VMware требуется более высокий коэффициент консолидации, чтобы приблизиться к Hyper-V по цене. Хм, но что в этом плохого? Разве виртуализация не была в большой своей части консолидацией? И как я уже говорил, если более высокая консолидация позволяет покупать меньше хостов и лицензий, то что же в этом плохого?

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

10) Вам нужна виртуализация VMware

Это начинает уже раздражать... Первое утверждение джентльменов касается уровней Hyper-V, в сравнении с VMware ESX. Джентльмен слева говорит: "В случае с VMware вам приходится иметь дело с 4 уровнями - железом, уровень VMware, уровень ОС, уровень приложений. С нашим решением (Hyper-V), уровня всего 3. Железо, ОС и приложения". Прошу прощения! В Hyper-V у вас ровно столько же уровней, как и в ESX, с одной лишь разницей - какие именно компоненты на каком уровне. К счастью, не все в Microsoft так плохо информированы, см. http://technet.microsoft.com/en-us/magazine/2008.10.hyperv.aspx, рисунок 2. Ошибочные утверждения в данном случае превращают само развенчание мифа в миф.

Update: Hyper-V R2 & CSV

Уточнил ситуацию с поддержкой CSV у Андрея Бешкова.

Итак, Hyper-V R2 в бесплатной поставке будет поддерживать Failover Clustering и CSV. Довольно суровая штука получается даже в бесплатном варианте в таком случае.

Тем не менее, Citrix уже выпустила бесплатный XenServer5 в аналогичной комплектации (не считая отсутствия кластерной FS). И еще - не забывайте, что сравниваем мы пока продающийся уже несколько лет ESX 3 и Hyper-V R2, который пока даже не вышел, а случится это событие ближе к концу 2009 года. В 2009 же году выйдет и vSphere (VMware VI 4), о которой мы слышали много, но лишь о технологической стороне, цены не озвучивались никем. Так что у VMware еще есть время подумать и достойно ответить.

ESX vs Hyper-V: цена

Хочется сравнить ESX и Hyper-V по цене. Разумеется, сравнивать будем варианты, интересные enterprise уровню, ибо в случае с SOHO и так все понятно, оба гипервизора бесплатны.

1) простой кластер из 3х хостов
ESX: $3624 (vCenter, VMFS, vSMP, VCB) - VMware Infrastructure Foundation Acceleration Kit (1 год поддержки включен)
Hyper-V: $0 ($505) - без и с SC VMM.

2) HA кластер из 3х хостов
ESX: $7254 + $3624 = $10878 - VMware Infrastructure Standard High Availability Acceleration Kit + VMware Infrastructure Standard
Hyper-V: $12000 + $505 = $12505 - 3*Windows 2008 Enterprise + SC VMM (в "комплекте" идут 12 лицензий на Windows 2008)
Hyper-V 2: $24000 + $505 = $24505 - 6*Windows 2008 Datacenter (исходя из предположения о 2х-процессорных серверах) + SC VMM

3) DRS+HA кластер на 6 хостов (или 2 по 3, что одно и то же)
ESX: $23218 + $20874 = $44092 - VMware Infrastructure Midsize Acceleration Kit + 3*VMware Infrastructure Enterprise
Hyper-V: $24000 + $5214 = $29214 - 6*Windows 2008 Enterprise + SC VMM (в "комплекте" идут 24 лицензии на Windows 2008)
Hyper-V 2: $48000 + $5214 = $53214 - 12*Windows 2008 Datacenter (исходя из предположения о 2х-процессорных серверах) + SC VMM

Казалось бы, все ясно и прекрасно - Hyper-V однозначно выигрывает по цене. Особенно с учетом того, что при использовании ESX необходимо еще и покупать лицензии на гостевые Windows Server. Но, как говорил Василий Иванович, "есть один нюанс". На самом деле нюансов куда больше.

1) В данном расчете не учитывается цена на иные гостевые ОС и продукты, работающие в этих ВМ. Таким образом, если мы создаем виртуальную инфраструктуру для Linux, то замечательные "бесплатные" лицензии на Windows Server нам попросту не нужны.
2) Hyper-V безоговорочно проигрывает ESX по возможностям и удобству настройки сетевого окружения ВМ.
3) Hyper-V в текущем релизе НЕ имеет Live Migration aka VMotion, поэтому сравнение номер 3 в известной мере некорректно.
4) Hyper-V в паре с SC VMM НЕ имеет средств резервного копирования ВМ, аналогичного VCB. И соотв. вместо $505 для рабочих групп (до 5 хостов) и $864 за хост (для SC VMM) придется брать уже SC SMSE по цене в $1500 за хост.
5) Hyper-V не умеет и даже неясно когда будет уметь Memory Overcommit, не говоря уже о Transparent Page Sharing. А эти технологии позволяют более плотно "упаковывать" ВМ на хост. Так что при кластере в 6 Hyper-V вполне может получиться, что на ESX достаточно кластера всего в 4 хоста для того же количества ВМ. В случае с VDI все станет совсем интересно.
6) Развивая пункт 1 - неправильно считать цены на гипервизоры, нужно считать TCO. А TCO - это TOTAL cost ownership, цена содержания всего хозяйства, начиная от серверных помещений и заканчивая зарплатой системных администраторов. Даже если ограничиться лишь стоимостью серверов и памяти, а так же лицензиями на софт, разница в цене виртуальной инфраструктуры на базе разных гипервизоров может оказаться попросту незаметной. И в итоге выбор вендора инфраструктуры основывается на уровне подготовки системных адимнистраторов и их знакомства с соотв. технологиями, либо необходимой функциональностью.

Впрочем, все это лирика :)