Очередная кака от маркетологов

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

Но мы все-таки попробуем 🙂

Вот сравнение фич:

xevm1

Модель лицензирования – согласен.

Поддержка многоядерных процессоров – согласен, все так.

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, которая считает паравиртуализацию не очень нужной технологией. Рассудит время.

xevm2

Патчи – смотрим патчи 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.

xevm3

На прайс без слез смотреть нельзя 🙂

  1. При лицензировании VMware активно используется лицензия vSphere Enterprise Plus. Между тем, озвученный функционал есть в vSphere Enterprise, которая дешевле баксов на 500 (без учета поддержки). Соответственно, народ минимум на 10% завышает стоимость VMware.
  2. Основная фишка VMware – это степень консолидации. Если ваша степень консолидации 5:1 или 8:1 – действительно, зачем вам VMware. У них в кейсах встречается консолидация 19:1. Всего-то в 2,5-4 раза выше, чем у Citrix 😉

Мораль: маркетологи потихоньку совершенствуют свое кунфу – скоро научатся незаметно лапшу на уши вешать.

12 thoughts on “Очередная кака от маркетологов”

  1. Вообще-то патчей на ESX(i) уже 114, если смотреть через VUM.
    А то, что Vmware стоит по умерить аппетит это точно.
    Теперь про консолидацию – можно и 40 VM, а на новых процах и ваще до 100 смело, но вопрос в том, что с IOPs будет.
    По-моему, пенисконтест в любом случае будет выигрывать vmware, см. механизмы работы с ОЗУ.
    Теперь очередь за vmware. Они точно ситриху запулят круче 🙂

  2. phily – я не являюсь админом Citrix, поэтому не могу прокомментировать их пост про 6 хотфиксов.
    Просто я выделил из множества апдейтов самые-самые.
    Что VMware иногда неоправданно дорог – согласен 🙂
    Для малого бизнеса так просто пипец :)))
    кстати, что за пенисконтест? Мне чудятся в слове ругательные компоненты 😉

  3. Ничего ругательного, просто “penis contest” – когда меряются тем, что в спаме удлинить предлагают 🙂
    Ситрикс и Вмварь разгулялись не на шутку, похоже, что атака Ситрикса это бессильная злоба на выход 4.1 – им реально нечем ответить.
    У Ситрикса очень плохо с управлением памятью, реально скверно.
    Плюс Вмварь за счет Vblock и партнерства с Cisco поставила крест на их baremetal-виртуализации. Они злятся, причем сильно, вот и пишут такие отчаянные сравнения и постоянно теряют долю рынка.

  4. Microsoft, я думаю, тоже не прочь. Они их в SP1 обещают 🙂 И утверждают что page sharing это самое лучшее и передовое, а мерзкий balooning и уж конечно compessing это плохо, потому как страдает общая производительность.
    Плохо у них в данном случае и с маркетингом, и с технологиями…
    Не срастается.

    Кстати, FT (хоть он и кривой и избирательный по процам) тоже ни у кого нет.

  5. Вот тут коллега делится опытом работы с аналогами под 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 постоянно. Сбоев нет. Есть ограничения на используемые компоненты виртуальной инфраструктуры.

Leave a Reply

Your email address will not be published. Required fields are marked *