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

Выложена компанией 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 😉

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

Запись опубликована в рубрике Citrix, VMware, vSphere, XenServer с метками . Добавьте в закладки постоянную ссылку.

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

  1. A.Vakhitov говорит:

    Черт. Картинки совсем нечитабельные 🙁

  2. Михаил говорит:

    vSphere Enterprise же нельзя купить, как она дешевле?

  3. A.Vakhitov говорит:

    Общался с знакомым из реселлера — вроде можно.

  4. Михаил говорит:

    Известная мне теория гласит, что он ошибается 😉

  5. A.Vakhitov говорит:

    http://www.vmware.com/vmwarestore/vsphere_purchaseoptions.html
    А как же эта ссылка? Вполне себе доступная для выбора опция, нигде никаких надписей и сносок?

  6. Михаил говорит:

    уточню, интересно.

  7. phily говорит:

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

  8. A.Vakhitov говорит:

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

  9. phily говорит:

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

  10. Андрей Вахитов говорит:

    🙂
    Мне очень интересно посмотреть на технологии управления памятью от MS

  11. phily говорит:

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

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

  12. Андрей Вахитов говорит:

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *