Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Просто в VMware поступили как в старом анекдоте — сначала привели козу в дом, потом прогнали. Теперь, вроде как, и вся модель лицензирования с vRAM не кажется чем-то ужасным.
Чего удивляетесь, «пиар, такой пиар...»
почему пиар? по моему это все таки ударило по компании — за эти две недели достаточно много компаний начало прикидывать и оценивать конкурентные продукты от MS и Citrix.
Кстати, хочу реально увидеть спокойное сравнение функционала Xen Cloud Platform и VMWare.
У XCP я сейчас вижу несколько проблемных мест, и мне бы хотелось узнать, как они решены у vmware… Например, как реализован cross-pool migration, за какое время поднимается из дауна пул из 10к виртуалок и т.д…
У XCP я сейчас вижу несколько проблемных мест, и мне бы хотелось узнать, как они решены у vmware… Например, как реализован cross-pool migration, за какое время поднимается из дауна пул из 10к виртуалок и т.д…
amarao, я пока еще «ненастоящий сварщик», который vSphere впервые увидел 8 месяцев назад, а первый XenServer поставил дома на лабе только позавчера, поэтому подобное сравнение я сейчас не смогу провести. Вот вы бы сами взялись бы за это дело :)
Для этого у меня слишком поверхностные знания vmware (и, главное, ни малейших стимулов изучать, т.к. посмотреть «как это на самом деле в сырцах» не получится).
У XCP есть несколько проблем, насколько я читаю рассылку, они будут исправлены в XCP 1.5, плюс мы пилим paraxe (https://github.com/selectel/paraxe), что чуток снимает проблему подъёма пула.
У XCP есть несколько проблем, насколько я читаю рассылку, они будут исправлены в XCP 1.5, плюс мы пилим paraxe (https://github.com/selectel/paraxe), что чуток снимает проблему подъёма пула.
Упс, пардон, ещё не коммитнули. Ну, в общем, эта штука запускает операции в параллель по всем хостам пула.
Мне вот всегда было интересно — а за какое время поднимаются 10000 виртуалок на xcp?
Ну, я при готовности sr'ов выдержать такой поток fsck на виртуалках синхронно, могу это сделать в пуле из 100 хостов примерно за 25-40 минут. (с учётом paraxe, без него буду страдать и мучаться больше суток). Если пулов несколько, то за 15-25 минут (там есть нюансы начальной синхронизации xapi, чем больше хостов в пуле, тем дольше оно тупит в цветочек).
да, если что, речь идёт про паравиртуализацию и линуксы. Сколько там будут винды в HVM рожать — не имею ни малейшего представления.
Страшно подумать сколько будет стоить лицензия на «пул из 10к виртуалок» под VMware :)
за эти две недели достаточно много компаний начало прикидывать и оценивать конкурентные продукты от MS и Citrix
Думаю, что всерьёз о выборе конкурентов могла задуматься весьма небольшая часть компаний, у которых решение о покупке уже «горело». У них не было возможности ожидать релиза и окончательных цифр.
С другой стороны, если слухи завтра подтвердятся, для многих VMware вмиг превратится из «зажравшегося монополиста» в прогрессивную компанию, которая слышит своих потребителей. Для других лицензионная политика просто станет приемлемой.
И там, и там — profit для VMware.
Отношение к VMWare очень двойственное. С одной стороны они — пионеры виртуализации x86, создатели конецпии binary rewriting (де-факто, основа текущего pv_ops в линуксе) и т.д.
С другой стороны — жирный монолитный гипервизор с уродливой архитектурой, закрытые исходные тексты, закрытая платформа, отвратительное лицензирование и геморрой на ровном месте.
На её фоне xen выглядит как вершина архитектурного совершенства. Хотя его есть за что ругать, но когда их сравниваешь, понимаешь, что VMWare живёт только за счёт своего пионерства (в смысле, раннего старта в области) и приложений, основанных на закрытом тулстеке (всякие directors и т.д.).
До тех пор, пока vmware не вытащит блочные и сетевые устройства из гипервизора, до тех пор у неё гипервизор будет оставаться жирным блобом с нулевыми шансами на более-менее приличную безопасность.
С другой стороны — жирный монолитный гипервизор с уродливой архитектурой, закрытые исходные тексты, закрытая платформа, отвратительное лицензирование и геморрой на ровном месте.
На её фоне xen выглядит как вершина архитектурного совершенства. Хотя его есть за что ругать, но когда их сравниваешь, понимаешь, что VMWare живёт только за счёт своего пионерства (в смысле, раннего старта в области) и приложений, основанных на закрытом тулстеке (всякие directors и т.д.).
До тех пор, пока vmware не вытащит блочные и сетевые устройства из гипервизора, до тех пор у неё гипервизор будет оставаться жирным блобом с нулевыми шансами на более-менее приличную безопасность.
Ну они же «самое зрелое решение на рынке», им простительно. =)
С новой версией Xen становится все лучше и лучше, однако чем больше гипервизоры догоняют друг друга по функционалу, тем больше корпоративные пользователи смотрят на стоимость целостного решения.
С новой версией Xen становится все лучше и лучше, однако чем больше гипервизоры догоняют друг друга по функционалу, тем больше корпоративные пользователи смотрят на стоимость целостного решения.
Несколько дней назад столкнулся со следующе проблемой: У меня ESXi 4.1 (16 GB RAM), и в виртуалке создана 1 ВМ с 8GB vRAM Win2k8, далее я в виртуалке монтирую tmpfs как отдельный диск и запускаю тест скорости. Результаты теста аналогичны тесту скорости жёстких дисков в RAID10, тем самым получается, что этот диск никакой не tmpfs, а самый обычный RAID10. Вопрос — как обстоят дела у XCP, если в ВМ смонтировать tmpfs, то это будет настоящий tmpfs или через своп на RAID?
Сложно ответить не имея подробных данных. Я, кстати, уже второй раз слышу про низкие результаты скорости ram дисков в виртуальных машинах.
Какой процессор в вашем хосте? Какая именно ОС? Как называется аналог tmpfs для Windows? сколько выделили RAM диску? Чем замеряли скорость?
Я попробую сделать замер с условиями близкими к вашим и сравним. А потом уже попробуем сделать выводы.
Какой процессор в вашем хосте? Какая именно ОС? Как называется аналог tmpfs для Windows? сколько выделили RAM диску? Чем замеряли скорость?
Я попробую сделать замер с условиями близкими к вашим и сравним. А потом уже попробуем сделать выводы.
Хост: Intel Xeon E31270 @ 3.40GHz (1 шт.) / 16GB RAM DDR3, ESXi 4.1 (348481)
ВМ: Win2k8 R2 SP1 Standard x64 (8GB vRAM), tmpfs делал средствами ImDisk выделял 2GB.
Для тестов скорости использовал CrystalDiskMark
ВМ: Win2k8 R2 SP1 Standard x64 (8GB vRAM), tmpfs делал средствами ImDisk выделял 2GB.
Для тестов скорости использовал CrystalDiskMark
Это вообще не проблема гипервизора, а гостевой машины. Какой она tmpfs сделает, такое оно и будет.
Сравнивать Xen и ESXi — тоже что холиварить та тему Win vs Unix.
Xen хорош под задачи как у Вас, Amazon'а, Rackspace'а потому что OpenSource и его можно пилить самому + он бесплатен.
Представте себе что будет удобнее, например, для компании в которой IT — не профиль? Там никто не будет ковырять сорци или долго ждать фикс. В таких компаниях интегратор настроит, проведет курсы, выберет железо по HCL и предоставит cаппорт по SLA. Что из того есть у Xen?
Xen хорош под задачи как у Вас, Amazon'а, Rackspace'а потому что OpenSource и его можно пилить самому + он бесплатен.
Представте себе что будет удобнее, например, для компании в которой IT — не профиль? Там никто не будет ковырять сорци или долго ждать фикс. В таких компаниях интегратор настроит, проведет курсы, выберет железо по HCL и предоставит cаппорт по SLA. Что из того есть у Xen?
Кстати, раз уж Вы занимаетесь Xen — в чем он круче KVM? т.е. меня интересует — о чем можно сказать — «тут лучше использовать Xen чем KVM»
Двумя словами: архитектура и производительность.
На Xen'е совершенно спокойно можно иметь 6-8 гигабит за пределы хоста из виртуалок, несколько гигабит дисковой активности. Насколько я знаю, KVM даже близко пока к таким числам не подошёл.
Про архитектуру можно много говорить, но по сути: он реализует микроядро, которое так и не реализовали в линуксе.
На Xen'е совершенно спокойно можно иметь 6-8 гигабит за пределы хоста из виртуалок, несколько гигабит дисковой активности. Насколько я знаю, KVM даже близко пока к таким числам не подошёл.
Про архитектуру можно много говорить, но по сути: он реализует микроядро, которое так и не реализовали в линуксе.
Честно говоря, меня терзают смутные сомнения насчет перевеса Xen в перфомансе перед KVM и именно из за архитектуры. Тем более, что KVM в режиме pass-through выжимает из устройств 100%. Да и virtio не сильно уступает.
Можно посмотреть на вывод iperf на 10G линком под виртуалкой так, чтобы сервер при этом был за пределами самой виртуалки?
честно говоря, нет ниодного 10G в распоряжении. даже в руках не держал.
Это будет не очень честный тест (зен в нём, например, отчаянно мухлюет), но посмотрите под KVM скорость сети между двумя виртуальными машинами на одном хосте.
Это я могу, попробую попоздже вечером.
… напоминаю про обещание, ибо интересно же.
Итак, тест.
Окружение — CentOS 5.5
[root@vmhost1 ~]# uname -a
Linux vmhost1.local 2.6.18-194.32.1.el5.centos.plus #1 SMP Wed Jan 5 18:13:47 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
KVM v.83
Как то так.
Для интереса гонял то же межу Хост<-->Виртуалка — результат примерно тот же.
Окружение — CentOS 5.5
[root@vmhost1 ~]# uname -a
Linux vmhost1.local 2.6.18-194.32.1.el5.centos.plus #1 SMP Wed Jan 5 18:13:47 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
KVM v.83
[root@********]# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.5.221 port 5001 connected with 192.168.5.249 port 45514 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 5.76 GBytes 4.94 Gbits/sec [root@********]# iperf -c 192.168.5.221 ------------------------------------------------------------ Client connecting to 192.168.5.221, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.5.249 port 45514 connected with 192.168.5.221 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 5.76 GBytes 4.94 Gbits/sec
Как то так.
Для интереса гонял то же межу Хост<-->Виртуалка — результат примерно тот же.
Ага.
А вот эти же результаты в xen'е (тоже 64 бита, внутри одного хоста, на интерфейсах включены все читы зена, какие только можно — оффлоад чексумм, большой пйэлоад и т.д.):
Именно потому я очень люблю зен.
PS Разумеется, localhost — это одно большое жульничество, в реальности я с него на физику больше 6Гб/c выжать не могу (при том, что голый линукс может до 8.2Гб/c).
А вот эти же результаты в xen'е (тоже 64 бита, внутри одного хоста, на интерфейсах включены все читы зена, какие только можно — оффлоад чексумм, большой пйэлоад и т.д.):
iperf -c ------------------------------------------------------------ Client connecting to 31.186.97.107, TCP port 5001 TCP window size: 256 KByte ------------------------------------------------------------ [ 3] local port 48789 connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 12.04 GBytes 11.55 Gbits/sec
Именно потому я очень люблю зен.
PS Разумеется, localhost — это одно большое жульничество, в реальности я с него на физику больше 6Гб/c выжать не могу (при том, что голый линукс может до 8.2Гб/c).
Давайте тогда уж vsphere и hyper-v еще :)
Вспомнил, что видел подобные тесты в vSphere тут — www.vm4.ru/2011/03/vsphere-network-test-vmxnet3-jumbo.html
Сегодня не удержался и потестил скорость между VM-ками на одном хосте и между VM-ками на двух разных хостах. Оба хоста HP Blade сервера соединенные по 10Гбит к внутренней фабрике Virtual Connect.
между двумя хостами
между двумя хостами с TCP Windows 256K
Между двумя хостами с TCP Window 256K и JF 4K (увы, физическое ограничение встроенной сетевой карты в HP BL460c )
Между двумя хостами с TCP Window 256K и JF 4Kб, 8 сессий
Тут мы уже в физику уперлись.
На одном хосте, TCP Window 16K
На одном хосте, TCP Window 256K
Странно, тут почему то производительность оказалась ниже — может я в чем то ошибся.
На одном хосте, TCP Window 256K, JF 9K
На одном хосте, TCP Window 256K, JF 9K, 8 сессий
В принципе почти везде производительность упиралась в ограничения ОС и ее сетевого стека.
между двумя хостами
между двумя хостами с TCP Windows 256K
Между двумя хостами с TCP Window 256K и JF 4K (увы, физическое ограничение встроенной сетевой карты в HP BL460c )
Между двумя хостами с TCP Window 256K и JF 4Kб, 8 сессий
Тут мы уже в физику уперлись.
На одном хосте, TCP Window 16K
На одном хосте, TCP Window 256K
Странно, тут почему то производительность оказалась ниже — может я в чем то ошибся.
На одном хосте, TCP Window 256K, JF 9K
На одном хосте, TCP Window 256K, JF 9K, 8 сессий
В принципе почти везде производительность упиралась в ограничения ОС и ее сетевого стека.
С другой стороны — у меня никаких твиков. И скорости между виртуалками — как и между виртуалкой и физикой. У меня там еще и куча VLAN, бриджей и всего такого.
Впрочем, мне понятно почему на Xen такой перфоманс. По сути-то в ситуации гость-гость «никто никуда не идет».
Впрочем, мне понятно почему на Xen такой перфоманс. По сути-то в ситуации гость-гость «никто никуда не идет».
На Xen'е совершенно спокойно можно иметь 6-8 гигабит за пределы хоста из виртуалок, несколько гигабит дисковой активности. Насколько я знаю, KVM даже близко пока к таким числам не подошёл.Мне кажется, у вас очень старая информация, т.е. я смутно помню, что-то такое давно-давно было, но сейчас это уже не актуально. Если я не прав — давайте пруфлинки. :-)
Возможно, т.к. я больше занят зеном, а про KVM больше читаю в статьях из linux symposium. В 2009 их конкретно ругали за low performance. В том числе и virtio.
За 2 года там много что могло поменяться, да. Если мне кто-то покажет циферки буду очень благодарен.
За 2 года там много что могло поменяться, да. Если мне кто-то покажет циферки буду очень благодарен.
да, поменялось, RH взялся очень плотно за KVM
Что он «взялся» я понял. А вот стало ли от этого лучше — не знаю.
PS Я ничего не имею против virtio и даже с большим интересом смотрю за процессом портирования его под xen, но там файловый доступ. А у зена всю жизнь рулил и педалил блочный паравиртуализированный, а в KVM с его qemu'шной базой для блочного ввода/вывода с этим было всегда как в xen'е до установки PV в hvm домене, то есть жить можно, но хреново.
Если у них блочное устройство хотя бы 300Мб/с может выдать — это признак прогресса (и повод посмотреть на KVM чуть серьёзнее). Если нет — ну, пусть RH старается…
Если у них блочное устройство хотя бы 300Мб/с может выдать — это признак прогресса (и повод посмотреть на KVM чуть серьёзнее). Если нет — ну, пусть RH старается…
кажется слышал про 2Тб на хост. А с оверкоммитом ещё в полтора раза больше.
Это зачем вам понадобился такой ESXi?
Чтобы в случае выпадения хоста из кластера до отработки механизма HA, разом пропадало из сети 150-200 продуктивных вм? А перезапуск стакого количества машин может быть весьма небыстрым.
А стораджи? Это сколько и каких СХД нужно, чтобы выдержать такой, совсем необязательный, бутшторм по IOPS'ам, который вы сделаете себе на «ровном месте».
А режим обслуживания серверов? Ставим миграцию машин на 3 ТБ vRAM и
Забудьте, никто в здравом уме в корпоративном секторе не ставит для хостов ESX(i) больше 200-300 ГБ RAM.
это надо десяток лицензий класса Essential
Жаль, не получится такое количество отдать одному хосту. А то бы не плохая бизнес-идея. Кажется, эти лицензии (те которые, без плюса) VMware отпускает по 5$ за пучок :)
cepera_ang,
во-1, десяток лицензий Essentials в приниципе невозможен, потому что их бывает не более 6.
Во-2, объем vRAM и объем памяти на хосте — разные вещи.
Несложно подсчитать, что для двухсокетного сервера с лицензией Enterprise лицензия дает 64 GB памяти, но что делать, если вы хотите использовать сервер с 128 GB памяти? Можно пойти простым и прямым путем, а именно просто купить еще две лицензии и добавить их в пул.
Но давайте посмотрим на ситуацию в целом.
Скорее всего вы не будете использовать память во всех ваших серверах на 100%. Один только факт использования HA в кластере 4+1 дает нам оверхед в 20% памяти (если упростить ситуацию). Плюс к этому, даже на тяжело нагруженных серверах обычно используется 80-85% памяти. Итого, 128*4*0.85 = 436 GB в нагруженной среде. Что в итоге дает 14 лицензий, исходя из реального потребления vRAM. В случае простого и прямого пути это 20 лицензий.
Целиком здесь — blog.vadmin.ru/2011/07/vsphere-5.html
во-1, десяток лицензий Essentials в приниципе невозможен, потому что их бывает не более 6.
Во-2, объем vRAM и объем памяти на хосте — разные вещи.
Несложно подсчитать, что для двухсокетного сервера с лицензией Enterprise лицензия дает 64 GB памяти, но что делать, если вы хотите использовать сервер с 128 GB памяти? Можно пойти простым и прямым путем, а именно просто купить еще две лицензии и добавить их в пул.
Но давайте посмотрим на ситуацию в целом.
Скорее всего вы не будете использовать память во всех ваших серверах на 100%. Один только факт использования HA в кластере 4+1 дает нам оверхед в 20% памяти (если упростить ситуацию). Плюс к этому, даже на тяжело нагруженных серверах обычно используется 80-85% памяти. Итого, 128*4*0.85 = 436 GB в нагруженной среде. Что в итоге дает 14 лицензий, исходя из реального потребления vRAM. В случае простого и прямого пути это 20 лицензий.
Целиком здесь — blog.vadmin.ru/2011/07/vsphere-5.html
>Чтобы в случае выпадения хоста из кластера до отработки механизма HA, разом пропадало из сети 150-200 продуктивных вм? А перезапуск стакого количества машин может быть весьма небыстрым.
1ТБ памяти со средним размером ВМ в 2ГБ и оверкоммите 1.5 даст 750 ВМ, а не 150-200.
Я пока не так много знаю в России крупных предприятий с 750 ВМ на всю инфраструктуру, не то что на хост.
А 750 ВМ на хост при 1.5 vCPU в среднем дадут 1125 vCPU. Рекомендованные VMware 8 vCPU / core дают 140 core.
При использовании последних 10 core Xeon'ов это минимум 4 4-хпроцессорных хоста. Добавим 1 хост под HA, итого 5 хостов по 256GB. Или 20 лицензий vSphere Enterprise Plus по 48GB. Что дает нам 960GB vRAM.
Если же слухи верны и Ent+ станет по 96GB, то 1920 GB vRAM, а это с лихвой перекрывает 1500 GB vRAM под эти виртуалки.
Впрочем цена лицензий VMware все равно капля в море после подсчета стоимости СХД под такую инфраструктуру, системы бэкапа, и (сюрприз-сюрприз!) лицензий на гостевые ОС и прикладной софт.
1ТБ памяти со средним размером ВМ в 2ГБ и оверкоммите 1.5 даст 750 ВМ, а не 150-200.
Я пока не так много знаю в России крупных предприятий с 750 ВМ на всю инфраструктуру, не то что на хост.
А 750 ВМ на хост при 1.5 vCPU в среднем дадут 1125 vCPU. Рекомендованные VMware 8 vCPU / core дают 140 core.
При использовании последних 10 core Xeon'ов это минимум 4 4-хпроцессорных хоста. Добавим 1 хост под HA, итого 5 хостов по 256GB. Или 20 лицензий vSphere Enterprise Plus по 48GB. Что дает нам 960GB vRAM.
Если же слухи верны и Ent+ станет по 96GB, то 1920 GB vRAM, а это с лихвой перекрывает 1500 GB vRAM под эти виртуалки.
Впрочем цена лицензий VMware все равно капля в море после подсчета стоимости СХД под такую инфраструктуру, системы бэкапа, и (сюрприз-сюрприз!) лицензий на гостевые ОС и прикладной софт.
Именно. Они испугались, что кто-нибудь в openstack прикрутит поддержку esxi и после этого окажется, что весь их проприентарный тулстек как-то вдруг и сбоку…
Да, всё просто. Старая модель лицензирования существенно не менялась уже больше 3х лет. С тех пор ресурсы типового сервера значительно увеличились (сходите, если будет такая возможность на какой-нибудь семинар Intel :D) Т.е. чтобы развернуть в N раз больше виртуальных машин на современном железе, я заплачу VMware ровно столько же (не учитывая инфляцию и прочие). Прибыль не должна убывать в долгосрочной перспективе. В том числе и чтобы финансировать разработку новых версий. Ничего лично, просто бизнес.
PS: а вот то, что до сих пор нет ясности с судьбой бесплатной лицензии ESXi, лично меня тоже очень настораживает и огорчает.
PS: а вот то, что до сих пор нет ясности с судьбой бесплатной лицензии ESXi, лично меня тоже очень настораживает и огорчает.
ну вот и официальный анонс если кто пропустил
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VMware пересмотрела объем vRAM entitlement в vSphere 5