Выложена компанией Citrix. Правда, предназначена она для отдела продаж, то есть техническим специалистам туда лучше не смотреть.
Но мы все-таки попробуем 🙂
Вот сравнение фич:
Модель лицензирования – согласен.
Поддержка многоядерных процессоров – согласен, все так.
Bare-metal deployment – непонятен ответ “Yes” у VMware. В vSphere 4.1 обещается официальная поддержка загрузки через PXE.
P2V&V2V – VMware Converter Standalone – бесплатен.
Управление несколькими серверами одновременно – указанные 6000 – 8000 актуальны для vCenter Standard. Кроме него есть еще vCenter Essentials (идет в бандле, стоимостью от 495$) и vCenter Foundation (от 2000$).
Ресурсные пулы и общие хранилища – доступно в бесплатной редакции ESXi.
Наличие снапшотов – доступно в бесплатной редакции ESXi. Кроме того, в VMware ESX/ESXi при создании снапшотов есть две опции:
- сделать снапшот ОЗУ. При откате к снапшоту вы получаете УЖЕ загруженную и работающую машину;
- сделать снапшот диска, используя VMware tools. Соответственно, шансов “развалить” файловую систему меньше, если она входит в список поддерживаемых ОС. А как раз у VMware этот список наиболее полный. Кроме того, большинство современных средств создания бэкапа используют именно механизм создания снапшотов для бэкапа!
Судя по документу, XenServer пока может предложить только VSS к снапшоту.
Мониторинг в режиме реального времени – доступен даже в ESXi.
Живая миграция и бэкапы – действительно доступны только в vSphere Advanced и выше. Если нужны только бэкапы, они есть в vSphere Essentials Plus.
Поддержка 8 виртуальных процессоров для ВМ – согласен.
Катастрофоустойчивое решение – смотрим сноску №1.
Производительность систем Windows – бред.
Производительность Linux – бред с точки зрения Vmware, которая считает паравиртуализацию не очень нужной технологией. Рассудит время.
Патчи – смотрим патчи Security(10) и Critical(13) для ESXi 3.5 на сайте http://support.vmware.com/selfsupport/download/. И где тут сотни патчей – я вижу 23? Кроме того, есть мнение, что кода без “дырок” не бывает. Начиная с определенных объемов дешевле вложиться в систему своевременного выпуска апдейтов, нежели повышать надежность.
VM HA (отказоустойчивость с перезапуском ВМ при отказе хоста) – доступна в vSphere Essentials Plus, который несколько дешевле, чем vSphere Standard, если вас устроит ограничение в три хоста.
Отказоустойчивость управляющих сервисов – в целом согласен. Не согласен с тем, что vCenter HeartBeat – единственное средство обеспечения отказоустойчивости vCenter. Я бы лично защитил кластером SQL, а vCenter положил на виртуальную машину и защитил VMware HA (до определенных объемов это пройдет). Кроме того, Citrix использует свою внутреннюю базу для хранения данных. Я бы не сказал, что это оптимально и надежно для больших инфраструктур. Вопрос знатокам Citrix – сколько хостов держит одна управлялка и как может расти их число, если управлялок становится несколько?
Мониторинг с сохранением данных за прошедший период – доступно, начиная с vSphere Essentials.
Оповещения администраторам – доступно, начиная с vSphere Essentials.
Динамическое управление памятью vs VMware MO – доступно в бесплатной редакции ESXi. Также смотрим сноску №1.
StorageLink – для VMware видел скриншоты интерфейсов для EMC. Про остальных вендоров пока не знаю.
Provisioning Services for VM – для виртуальных машин есть очень удобный механизм шаблонов. Для физической – согласен, нет.
Автоматическая балансировка виртуальных машин – в принципе согласен, но смотрим сноску №1.
Lab/Stage management – не силен в данных продуктах, так что может быть и так.
Администрирование на основе ролей – доступно, начиная с vSphere Essentials.
Отказоустойчивость ВМ без перезапуска – в принципе согласен, хотя я не знаком с продуктами, названными для Citrix. Вроде бы для них также есть некоторые ограничения.
Долгожданная сноска №1 – допустим, “***” есть в продукте A и в продукте B. Из чего следует равенство функционала “***” в обоих продуктах? Тот же VMware Memory Overcommitment остальным вендорам еще догонять и догонять, особенно в предверии Memory Compression.
На прайс без слез смотреть нельзя 🙂
- При лицензировании VMware активно используется лицензия vSphere Enterprise Plus. Между тем, озвученный функционал есть в vSphere Enterprise, которая дешевле баксов на 500 (без учета поддержки). Соответственно, народ минимум на 10% завышает стоимость VMware.
- Основная фишка VMware – это степень консолидации. Если ваша степень консолидации 5:1 или 8:1 – действительно, зачем вам VMware. У них в кейсах встречается консолидация 19:1. Всего-то в 2,5-4 раза выше, чем у Citrix 😉
Мораль: маркетологи потихоньку совершенствуют свое кунфу – скоро научатся незаметно лапшу на уши вешать.
Черт. Картинки совсем нечитабельные 🙁
vSphere Enterprise же нельзя купить, как она дешевле?
Общался с знакомым из реселлера – вроде можно.
Известная мне теория гласит, что он ошибается 😉
http://www.vmware.com/vmwarestore/vsphere_purchaseoptions.html
А как же эта ссылка? Вполне себе доступная для выбора опция, нигде никаких надписей и сносок?
уточню, интересно.
Вообще-то патчей на ESX(i) уже 114, если смотреть через VUM.
А то, что Vmware стоит по умерить аппетит это точно.
Теперь про консолидацию – можно и 40 VM, а на новых процах и ваще до 100 смело, но вопрос в том, что с IOPs будет.
По-моему, пенисконтест в любом случае будет выигрывать vmware, см. механизмы работы с ОЗУ.
Теперь очередь за vmware. Они точно ситриху запулят круче 🙂
phily – я не являюсь админом Citrix, поэтому не могу прокомментировать их пост про 6 хотфиксов.
Просто я выделил из множества апдейтов самые-самые.
Что VMware иногда неоправданно дорог – согласен 🙂
Для малого бизнеса так просто пипец :)))
кстати, что за пенисконтест? Мне чудятся в слове ругательные компоненты 😉
Ничего ругательного, просто “penis contest” – когда меряются тем, что в спаме удлинить предлагают 🙂
Ситрикс и Вмварь разгулялись не на шутку, похоже, что атака Ситрикса это бессильная злоба на выход 4.1 – им реально нечем ответить.
У Ситрикса очень плохо с управлением памятью, реально скверно.
Плюс Вмварь за счет Vblock и партнерства с Cisco поставила крест на их baremetal-виртуализации. Они злятся, причем сильно, вот и пишут такие отчаянные сравнения и постоянно теряют долю рынка.
🙂
Мне очень интересно посмотреть на технологии управления памятью от MS
Microsoft, я думаю, тоже не прочь. Они их в SP1 обещают 🙂 И утверждают что page sharing это самое лучшее и передовое, а мерзкий balooning и уж конечно compessing это плохо, потому как страдает общая производительность.
Плохо у них в данном случае и с маркетингом, и с технологиями…
Не срастается.
Кстати, FT (хоть он и кривой и избирательный по процам) тоже ни у кого нет.
Вот тут коллега делится опытом работы с аналогами под Xen (oper source)
http://virt.cnews.ru/project/byid/353
-itwarranty: Коллега, насколько я понимаю Remus и VMware Fault Tolerance аналогичные технологии, а Kemari отличается от них.
Хотя все они предназначены для обеспечения отказоустойчивости, что не могут дать high availability кластеры.
Механизмы VMware Fault Tolerance и Remus Fault Tolerance синхронизируют состояние виртуальных машин между серверами:
Шаг 1 – сделать копию работающей ВМ (де факто – содержимое оперативки) на другом хосте;
Шаг 2 – непрерывно синхронизируются процессорные инструкции. Т.е. наша ВМ работает, на процессоре что то там делается – и эти инструкции по сети передаются на другой хост, на копию этой ВМ. Таким образом, она все все повторяет за оригинальной виртуалкой;
Шаг 3 – в случае аппаратного сбоя сервера с оригиналом, в сеть выпускается копия(до того она, разумеется, к сети доступа не имеет). (можем, кстати, такой перенос инициировать ручками, по желанию – тогда ВМ просто меняются ролями).
Kemari более производительная технология, чем вышеописанные.
-Я: Насколько надежный механизм? Давно ли вы его используете, не было сбоев?
-itwarranty: Около четырёх месяцев тестируем обе технологии и Remus и Kemari постоянно. Сбоев нет. Есть ограничения на используемые компоненты виртуальной инфраструктуры.