Комментарии 98
Начиная с момента отказа от толстого клиента, по моим ощущениям все становилось только хуже от версии к версии. Да, появлялись новые фичи, исправлялись старые баги, но общее ощущение ухудшалось. А после покупки Broadcom возникает ощущение, что они хотят угробить продукт. В принципе все проблемы указали в статье: стоимость, тех. поддержка, портал за полтора года так и не достиг уровня который был.
У нас около 40 серверов с ESXi, мы не стали переходить на новые лицензии, пока работаем с тем, что есть и рассматриваем варианты миграции на другие платформы
В целом, все стало понятно, когда они объявили, что основной фокус будет теперь на избранной когорте крупных клиентов. Злобный оскал тупости капитализма: зачем тратить ресурс/деньги на хотелки не пойми кого, когда основную долю прибыли приносят условные 600 клиентов? Еще было бы интересно проверить, какого уровня качества поддержку получают эти самые шесть сотен в сравнении со всеми остальными.
Уже не раз обсуждалось и прогнозировалось.
Эти крупные клиенты потом тоже перейдут на аналоги.
Новые сотрудники, пришедшие из других фирм, в глаза не видели вмваре. Их надо учить на него. И наоборот, на другое они обучены.
Среди аналогов вмваре стремительно развивается опенсорсное решение. Зачем потом платить вмваре, если есть бесплатные решения, на которые ещё и потенциальные сотрудники обучены?
Это вы о Proxmox?
Скорее всего про apache cloudstack.
это админы локалхоста, видимо, все что описано настолько тупо что просто не влазит, НИЧТО не может заменить ЭТО, будет боль и страдание по сравнению с 10летней беспроблемной работы
Врядли только Proxmox. Но собственно многие альтернативы - opensource в той или иной мере. У Proxmox VE "есть сетапы где Proxmox VE на аж целых 50 нод пусть даже с крутым железом" - это повод хвалится - https://pve.proxmox.com/wiki/Cluster_Manager (там правда 2021 год указан - видимо существенно лучше - не стало) зато статьи про проблемы с CoroSync'ом на значительно меньших объемах - бывают-с. А даже на хабре люди пишут пор маленькие конфигурации с сотней-другой нод...явно не на Proxmox'е они.
. Зачем потом платить вмваре, если есть бесплатные решения
Для крупняков такого уровня на которые ориентируется вмваре, бесплатность или платность решения не имеет значения, им важна гарантированная поддержка вендора..а уж сколько стоит лицензия - это не важно
ставить в облаке какогонить Bank of America опенсорсный гипервизор и ИТ отдел из сеньоров-админов которые могут такую штуку тянуть, никто не будет, проще купить вмварю и выводок миддлов-джунов под руководством двух сеньоров...на длинной дистанции это дешевле выйдет во всех смыслах
ставить в облаке какогонить Bank of America
Мне кажется основной рынок виртуализации это не банки и т.п. конторы где IT только вспомогательная структура цена которой не критична для основного бизнеса, а хостинги/облака разного уровня, зарабатывающие на перепродаже серверных мощностей.
И количество серверов там огромно, лицензию за каждый надо окупить, причем ставить любой ценник не получится - съедят конкуренты.
А без сеньоров-админов крупному хостингу в любом случае не обойтись, так что требования к квалификации подъемные.
А без сеньоров-админов крупному хостингу в любом случае не обойтись, так что требования к квалификации подъемные.
Это вам так кажется, я же не просто так банк упомянул
У банка огромная ИТ инфраструктура и она крайне критичная для их бизнеса
также особенность их работы такова что её нельзя полностью вынести из контура банка, т.к. отдать на полный оутсорс например банковский АБС просто невозможно
А вот хостинги и облака, таких компаний не настолько и много, особенно крупняков...а у крупняков которые прям серьёзные ИТ компании (типа гугла и т.п.) там свои отделы разработки
И количество серверов там огромно, лицензию за каждый надо окупить,
я же и говорю про крупняков, им плевать
например я в начале своей карьеры удивлялся как популярен оракл, у нас был небольшой процессинг с 5 серверами под Oracle DB...и стоимость лицензий на кол-во процессоров и поддержки этого всего чутьли не превышала стоимость железа в серверной...а там были сотни серверов... каждый месяц там по несколько лямов за их подписки-поддержки оплачивали..хотя мы звонили туда раз в квартал не больше (и то оракл относился к нам как к бомжам...буквально бросая трубки узнав что у нас самая дешевая подписка)
Эти крупные клиенты потом тоже перейдут на аналоги.
А вот это уже напрямую зависит от действий вмвари. И сосредотачиваться на интересах своих крупных клиентов - правильная стратегия. Вмварь сейчас нет большого смысла использовать вне крупных базово дорогих инфраструктур. В ширь - на массмаркет - они идти могут, но смысла в этом куда меньше. Весь вопрос в том, как они эту стратегию реализуют, но сама стратегия вполне разумна.
Толстый клиент был ххххх (тут непечатное слово). Продукты от VMware отлично развивается. VSAN в 7 версии вообще стал топчик. Важно что развитие активно идет.
Жаль только бесплатного esxi - для небольших систем было очень удобно.
После того как поадминишь кластеры на hyper-v (особенно если процессоры разных поколений), на vmware возвращаешься, как в домашние тапочки. Да, в win окружении, datacenter лицензии выходят сильно дешевле, если всё раскатать поверх hyper-v, но надо сильно любить нетрадиционные виды секса, чтобы добровольно вписываться в это. (имхо, конечно же)
"Может, и бизнес компании чувствовал бы себя лучше, если бы она не отказалась от российских клиентов"
Вы правда верите в значимость рынка РФ на фоне мирового? Сколько % составляет ИТ рынок РФ от мирового? 1%?
А по остальному... Да, я вижу, что это перевод, но... Это классический FUD без нормального понимания ситуации, Cherry picking односторонним представлением фактов и допущениями.
Не, я понимаю, почему у многих подгорает, но факты, к сожалению, говорят что:
"The CEO also told investors that 17 million of those newly-sold cores will be used to run the flagship private cloud suite VMware Cloud Foundation (VCF), and that 4,500 of Broadcom's top 10,000 VMware customers have signed up for VCF since the acquisition" При этом это не означает, то оставшиеся 5500 свалили - куча самых мудрых заказчиков купило поддержку на 3/5 лет перед закрытием сделки и сидят на перпет лицензиях и поддержке и смотрят чем все это закончится.
"Full-year revenue for Broadcom’s software division hit $21.5 billion, up from $7.6 billion for FY 2023 – an increase of $13.8 billion. VMware’s last full year of revenue as an independent company was $13.4 billion, and Broadcom did not own the virty giant for a few weeks of its FY 2024 and therefore can't count a few hundred million dollars of revenue. The Register also feels safe in assuming that the other parts of Broadcom’s software biz – CA and Symantec – are not growing fast, if at all."
https://www.theregister.com/2024/12/13/broadcom_q4_fy_2024_vmware/
Итого, стонов много, но по факту цифры хорошие - многие (большинство?) заказчики покупают по новым условиям, что видно как в revenue, так и в абсолютном числе.
Плюсом к этому новая модель влияет на IT-бюджет: вместо разовых затрат возникают регулярные расходы.
Что вам (заказчикам) мешает купить подписку на 5 лет вперед? Обычно, по фин. правилам в компаниях, подписка на 5 лет считается в CAPEX, а не OPEX.
Все это — отсутствие гибкости, рост расходов, потенциальная привязка к единственному поставщику — многим очень не понравилось. Особенно остро отреагировали облачные провайдеры, чей бизнес во многом зависел от технологий виртуализации VMware.
Они остро отреагировали вообще не поэтому. А потому что раньше сервис провайдеры платили pay-as-you-use и per vRAM. А их перевели на обычные per-core лицензии с оплатой upfront. И тем, у кого был большой парк старого железа (с 8-12 ядрами на CPU) стало больно и дорого.
"Так, например, Broadcom запретила AWS и их партнерам перепродавать VMware Cloud и сделала невозможным перенос существующих бессрочных лицензий в облако."
Cherry picking, да и еще и с неточностями. Давайте вспомним, что в Azure, GCP изменений не было. Потому что это сервис/продукт от гиперскейлера, в отличии от VMC on AWS (который был продуктом/сервисом от VMware). Но даже с AWS, почему-то забыли упомянуть про Amazon Elastic VMware Service, который появился на замену https://aws.amazon.com/evs/
Не стоит забывать и о новой стратегии Broadcom, подразумевающей концентрацию на небольшом числе крупных клиентов (около 600),
Очень часто вижу эту ссылку, но любопытно, что если почитать оригинал, то там написано другое. Это стратегия всего Broadcom. И для Broadcom (который чипы в основном делает) - это очень логично ибо "We believe aggregate sales to our top five end customers, through all channels, accounted for approximately 40% and 35% of our net revenue for fiscal years 2024 and 2023, respectively. We expect to continue to experience significant customer concentration in future periods." https://investors.broadcom.com/node/62761/html При этом нигде не заявлялось, что VMware так же сфокусируют на 600 заказчиков. Вон выше в квартальном отчете писали про Top-10000.
VMware vSphere Enterprise Plus стоит $4780 за процессор в год
Показательно, как взяли цифру от балды из крайне фигового источника в качестве пруфа. "per processor per year for a perpetual license" - а нечего, что Ent+ только subscription и per-core?
в то время как альтернативные решения, такие как Red Hat Virtualization и Oracle Linux Virtualization Manager, предлагают более гибкие подписные модели по потенциально более низким ценам.
По каким ценам-то? Есть ссылки? И вы про тот Red Hat Virtualization, который "Red Hat Virtualization is currently in maintenance or extended support for existing customers only."
Есть опасения, что политика Broadcom по сокращению расходов приведет к уменьшению расходов на R&D
Опасения-то есть. А пруфы есть? Потому что официальные заявления говорят про +1 млрд $ А еще в официальных данных для комиссии по ценным бумагам написано, что на VCF 9.0 "The Form 10-K, however, mentions planned major releases in March and July. The March release has been allocated $2.9 billion of in-process research and development costs, suggesting it’s a big one"
Любопытно, а сколько R&D spends у Базиса и остальных?
VMware Workstation Pro
Почему-то умолчали, что его при этом сделали бесплатным. Для всех.
Короче там такого еще много.
Есть те, кому стало грустно и плохо? Безусловно.
Поднялись ли цены? Для кого-то да, для кого-то нет.
Есть ли заказчики, которые уходят? Очевидно, хотя справедливости ради, они всегда были. Некоторые потом возвращались.
Но вот заявления про "Будущее VMware висит на волоске" - выглядит как FUD, ибо нет никаких фактов на текущий момент, которые это подтверждают. И хотя не факт, что они не появятся в будущем, пока выглядит так, будто план Хока работает. И работает хорошо.
Вы правда верите в значимость рынка РФ на фоне мирового?
Рынок есть рынок, значимость обычно определяется не столько его размером, сколько возможностью на нем заработать. В России VMware перед уходом, занимала, кажется, более 80% с выручкой более 1 млрд руб.
классический FUD
Классический FUD, все же, подразумевает намерение что-то продать, вряд ли автор преследовал такую цель. Мы ее точно не преследовали. Да и интонация статьи больше похожа на легкую ностальгию по временам, когда трава была зеленее, смешанную с беспокойством за будущее компании. Каким будет это будущее - покажет время.
Любопытно, а сколько R&D spends у Базиса и остальных?
У Базиса - до 1 млрд рублей ежегодно, за остальных говорить не готовы. Однако мы не то чтобы соревнуемся с Broadcom (или кем-то еще) по этому параметру.
Рынок есть рынок, значимость обычно определяется не столько его размером, сколько возможностью на нем заработать. В России VMware перед уходом, занимала, кажется, более 80% с выручкой более 1 млрд руб.
Я не знаю откуда вы взяли эти цифры и у меня сильные сомнения насчет них, но допустим вы правы. Предположим, что это число за 2021 год (последний полный год до войны, хотя в другие года +- похоже должно быть). Средний курс в 2021 был 74, тогда 1 млрд рублей = 13.5 млн$. В 2021 году, revenue VMware по миру было 12.85 млрд$. Таким образом, доля РФ составляла 0.1% от мирового. Я не вижу причин почему маржинальность должна отличаться хотя бы в несколько раз, не говоря уже про порядки. Тогда каким образом "бизнес компании чувствовал бы себя лучше, если бы она не отказалась от российских клиентов", мне совершенно не очевидно.
Классический FUD, все же, подразумевает намерение что-то продать, вряд ли автор преследовал такую цель. Мы ее точно не преследовали.
FUD — это просто способ психологической манипуляции. Причины/цели который могут быть совершенно различные - начиная от желания продать до желания сорвать побольше хайпа от своей статьи. А то, что перевод размещен в корп. блоге компании Базис, которая по собственным заявлениям делает альтернативу и замену этого самого VMware — это так просто совпало, да. Никакого желания продать и заменить VMware, очевидно, у вас тоже нет.
У Базиса - до 1 млрд рублей ежегодно, за остальных говорить не готовы. Однако мы не то чтобы соревнуемся с Broadcom (или кем-то еще) по этому параметру.
А вот тут любопытно. Смотрите, вы пишите: "и при этом не уступать по показателям эффективности зарубежным аналогам, например, VMware. Сегодня, по результатам работы, мы с уверенностью можем сказать, что по большинству параметров наш гипервизор даже превосходит зарубежные аналоги». Т.е. вы делаете замену и заявляете, что ваш продукт не то, чтобы догнал, но и превосходит то же самое от VMware. Вопрос как у вас это так прекрасно получается, если VMware инвестирует 2.9 млрд $ в один релиз (обращаю внимание, что это даже не в год. И не на все продукты. Просто базовая платформа, которую вы и пытаетесь догнать и перегнать), а вы в 269 раз меньше? Ок, зарплаты в Штатах выше. Ваша компания, допустим, меньше, а её эффективность выше. Еще там что-то. Это все дает повышение эффективности разработки в 300-500 раз? Я уж молчу, что VMware за прошлые года (например, с 2016 по 2023) потратило на R&D 20млрд$ и это не полностью растворилось в воздухе (хотя согласен, что некая часть была закопана и закрыта), а вошло в текущую платформу.
В любом случае, пинать в R&D под лозунгом "есть опасения" - очень такое себе. Ибо как раз классический FUD.
В ваших расчетах слишком много допущений, но мысль вполне ясна, спасибо.
Единственное, логика "раз делает альтернативу и замену этого самого VMware, значит наговаривает на компанию" не работает: мы тут с вами можем ругать VMware или восхвалять, компания от этого на российский рынок не вернется и потребность в замене ее продуктов на другие решения ("Базиса" или чьи-то еще) от этого никуда не денется.
В ваших расчетах слишком много допущений, но мысль вполне ясна, спасибо.
Эм.. А какие допущения в моих расчетах вам кажутся сомнительными? Все цифры из них - из официальных документов + ваши собственных заявлений. Но главная штука в моих расчетах, что там даже на порядок ошибись в любую сторону - смысл не изменится.
логика "раз делает альтернативу и замену этого самого VMware, значит наговаривает на компанию" не работает
Я подчеркиваю очевидный и прямой конфликт интересов. Если бы это написал Вася, который не имеет отношения ни к одному производителю, то аргумент бы действительно не работал. А тут корп. блог вендора, который пытается заменить VMware.
И потребность-то замены, может быть, и есть. Но некоторых вполне себе устраивает то, что они используют VMware и не видят весомых причин или возможности переходить. А тут вы приходите и начинаете рассказывать, что у VMware все плохо, ужасно и вообще она висит на волоске. Используя FUD, что такое себе.
А тут вы приходите и начинаете рассказывать, что у VMware все плохо, ужасно и вообще она висит на волоске. Используя FUD, что такое себе.
Вообще-то это - перевод, и что-либо использовать в нем может только автор оригинала. Переводчик имеет лишь свободу выбрать, что именно перевсти. Но и вы тоже имеете свободу найти и опубликовать ссылку на статью, полемизирующую с опубликованной. Ссылки на английский вариант IMHO достаточно: переводить не обязательно, английский технический тут многие знают на достаточном уровне. Причем - полемизирующую на базе фактов, а не других смутных сомнений, чтобы дать информацию, а не крыть одни домыслы другими. IMHO это сильно повысит полезность вашего комментария для читателей.
Переводчик имеет лишь свободу выбрать, что именно перевсти.
Вот именно. И если компания решает перевести и опубликовать что-то в своем корпоративном блоге, то логично, что она хочет распространить исходную статью и информацию из неё. Разве нет?
Но и вы тоже имеете свободу найти и опубликовать ссылку на статью, полемизирующую с опубликованной.
Эм.. Т. е. если кто-то перевел статью, то я не могу прийти в комментарии и написать, что это фигня, потому что A, B, C? Мне нужно сначала обязательно найти кого-то, кто это опубликовал и только потом отправить это в комментах?
Причем - полемизирующую на базе фактов, а не других смутных сомнений, чтобы дать информацию,
Мне кажется что в моем исходном комментарии почему эта статья фиговая, было достаточно и фактов, и ссылок. Ровно как в и в дальнейших я писал цифры (хотя каюсь не вставлял на каждый из них пруфов) и я пока не видел сообщений, где я ошибся.
а не крыть одни домыслы другими.
А вы не могли бы привести пример моих домыслов, которые не вытекают логически из фактов, которые я привел?
Копейки для вмвари, да еще и процентов 80 наверное на пиратке сидели.
Миллиард рублей - это вообще ни о чем по меркам Vmware.
Да просто рынок изменился, все больше решений уходит в контейнеры, как таковые виртуальные машины теперь нужны разве что под виндовые сервисы и их мало.
Ну и конечно альтернативные решения вроде proxmox ve и proxmox backup server, просто уничтожают конкурентов на взлёте. Альтернатив просто нет, сейчас VMware в связке с veeambackup юзать - себя не уважать. Разумеется, veem все ещё удобное решение для резервирования mssql и ms exchange.
СУБД в контейнере, конечно, запускать можно. Но пилоты с PostgreSQL и ClickHouse у нас показали, что для продуктива контейнеризация никаких преимуществ перед VM не дает, а поддержку заметно усложняет. Вот для разработки и тестирования контейнеризация СУБД иногда удобна. Но опять не всегда.
Чуть не забыл. Разделять GPU между контейнерами тоже не получилось. Поэтому все A100 так и остались под VMWare.
Чуть не забыл. Разделять GPU между контейнерами тоже не получилось. Поэтому все A100 так и остались под VMWare.
Странно. Оно должно работать https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ Только по умолчанию выключено и надо через nvidia-smi включить + GPU Operator поставить.
Я сам этим не занимался, но подсказали, что под k8s приходится вручную изобретать, как пилить партиции с каждой A100 между контейнерами. Под VMWare такой проблемы нет, так как поддерживается vCS.
Получается, что под k8s одну A100 может грузить не более 7 контейнеров, а под VMWare - сколько угодно VM.
Получается, что под k8s одну A100 может грузить не более 7 контейнеров, а под VMWare - сколько угодно VM.
Не, это не так работает. Число (и тип) vGPU профилей определяется картой, а не платформой. Поэтому если вы хотите разделить A100, то максимум у вас может быть 7 частей при использовании MIG или 20 Time-sliced. https://docs.nvidia.com/ai-enterprise/release-5/latest/appendix/appendix-misc.html + https://blogs.vmware.com/performance/2021/09/mig-or-vgpu-part1.html + https://www.vmware.com/docs/vgpu-vs-mig-perf
У VMware есть vSGA режим, где ВМ действительно может быть много, но это ни разу не шаринг карты. Это скорее оффлоад на неё некоторых инструкций.
Я сам этим не занимался, но подсказали, что под k8s приходится вручную изобретать, как пилить партиции с каждой A100 между контейнерами. Под VMWare такой проблемы нет, так как поддерживается vCS.
Не очень понятно, потому что vCS поддерживается на bare-metal https://docs.nvidia.com/ai-enterprise/deployment/bare-metal/latest/advanced-gpu.html
Ну а нарезать профили можно через nvidia-smi -i 0 -mig 1 + nvidia-smi mig -cgi 19/nvidia-smi mig -cci 1 9
MIG или 20 Time-sliced
Вы хотите сказать, что в k8s вместо MIG со статическим распределением между контейнерами ресурсов GPU и возможностью одновременно использовать GPU только в 7 контейнерах, можно использовать vGPU с динамическим распределением до 20 контейнеров и возможностью в любой момент отключить или подключить vGPU к контейнеру, как это позволяет VMWare?
Тогда почему Вы для нарезки профилей используете MIG?
Я сказал не совсем это, а то что:
1.) Если вы используете MIG с A100, то вы можете разделить карту максимум на 7 частей, что на bare-metal, что в vSphere. Потому что это определяется картой.
2.) C vGPU карта может делиться на большее число, но не любое. Максимум 20 для A100 80GB. Работает только с виртуализацией.
3.) Дальше есть просто time-slicing без vGPU. Я его руками не ставил на bare-metal, но оно должно работать и с bare-metal при помощи NVIDIA device plugin for Kubernetes
4.) Есть еще CUDA MPS, который тоже должен работать с bare-metal k8s, но я его не копал, так что нюансов не подскажу. https://docs.google.com/document/d/1H-ddA11laPQf_1olwXRjEDbzNihxprjPr74pZ4Vdf2M/edit?tab=t.0 + https://docs.nvidia.com/deploy/mps/index.html + https://ronanquigley.com/blog/understanding-gpu-sharing-strategies-in-kubernetes/
Ну а MIG, потому что это единственный способ сделать максимально честную изоляцию между ВМ на картах. ИМХО не плохой пост для начала изучения: https://developer.nvidia.com/blog/improving-gpu-utilization-in-kubernetes/
P.S. Я согласен, что терминология на этот счет у NVIDIA так себе и постоянно меняется, так что бывает сложно.
Если вы используете MIG с A100, то вы можете разделить карту максимум на 7 частей
Для нас это мало. Даже 14 разделов на спарке A100 через NVLink. Да и потребность в вычислительных ресурсах у нас намного выше, чем в памяти. Кстати, я не уверен, что MIG NVLink поддерживает.
C vGPU карта может делиться на большее число, но не любое. Максимум 20 для A100 80GB. Работает только с виртуализацией.
Виртуализация позволяет динамически добавлять и отнимать vGPU у VM. Хотя 40 слайсов нам пока хватает. В нашем случае, когда есть несколько десятков VM, периодически (раз в час, сутки, неделю или даже в месяц - смотря как часто обновляются данные) занимающихся прогнозированием, размеры моделей и объемы для дообучения не столь велики, сколь важны вычислительные ресурсы GPU. Отсюда и выбор в пользу VMWare, а не k8s.
Дальше есть просто time-slicing без vGPU
Выглядит грустно: "nothing special is done to isolate workloads that are granted replicas from the same underlying GPU, and each workload has access to the GPU memory and runs in the same fault-domain as of all the others (meaning if one workload crashes, they all do)".
Спасибо за развернутую консультацию со ссылками!
СУБД в контейнере конечно запускать можно, но наверное где то в тестовых средах или в невысоко нагруженных проектах. Например, у меня nextcloud с базой postgresql замечательно живёт в докере.
Но все серьезные базы это железо, как правило, уж точно не VMware.
Но все серьезные базы это железо, как правило, уж точно не VMware.
А как мигрировать при необходимости обслуживания железа?
Десятки терабайт и жесткое требование 24/7 доступности для всего холдинга по половине планеты - это разве не серьезные базы?
А как мигрировать при необходимости обслуживания железа?
Так несколько серверов, переключаете рабочую реплику на резервную, а новую резервную (бывшую основную) останавливаете на обслуживание
как жили до виртуализации то? ничего нового не появилсь
а сама БД лежит на отдельном СХД
То есть данная схема требует, как минимум трех серверов в кластере, вместо двух? Оригинально. Особенно если речь идет о СУБД, которым нужно по 64 ядра и терабайту оперативки.
Для двух десятков таких СУБД в VMWare (реальная ситуация на текущем проекте) требуется 41 терабайт RAM и 2624 ядра. А при предложенной Вами схеме - 60 терабайт RAM и 3840 ядер. Разницу не замечаете?
А теперь назовите хотя бы одну причину, запускать СУБД на голом железе вместо VM, оправдывающую эти многомиллионные затраты.
То есть данная схема требует, как минимум трех серверов в кластере, вместо двух? Оригинально. Особенно если речь идет о СУБД, которым нужно по 64 ядра и терабайту оперативки.
ну да, а вас это так удивляет? я в конце нулевых работал в банковском процессинге и у нас реально было 3 сервера БД и около 7 тестовых (которые можно было оперативно перекинуть в прод если чтото прям совсем рухнет)
и они (основные) были прям грандиозные по мощности
когда я туда пришел, помню только появился ESXi и мы на него начали перетаскивать обвязку чтобы разгрузить серверную...но прод как был на железных спарках так и остался
Одно дело, если больше двух серверов в кластере требуется с точки зрения производительности. А совсем другое - если только ради отказа от виртуализации. Опять не видите разницы?
Железный сервер обскочит по производительности VM) Это и есть разница. Причем, разница в десятки процентов.
На самом деле при СУБД нагрузке - не более 3%. Но даже если бы были десятки процентов, то это по любому меньше, чем почти 50%, для тех случаев, когда достаточно fail-over кластера из двух хостов.
Если на пальцах, то если есть fail-over с 64+64 ядрами и 1+1 ТБ RAM, то добавив всего по 4 ядра и 100 ГБ RAM точно компенсируем деградацию производительности из-за виртуализации. А для третьего хоста надо на 56 ядер и 900 ГБ больше.
Причем заметно теряем в стоимости владения не только по капитальным затратам/амортизации, но и по обслуживанию. Например, VM на другую площадку или даже другой ЦОД мигрируются совершенно прозрачно, чего не скажешь о физических серверах.
Всмысле, "мигрировать"? Просто выключается одна нода и на запросы отвечают оставшиеся.
Вполне возможно что базы серьезные, но я говорю про те что вообще Oracle где целые стойки.
Да просто рынок изменился, все больше решений уходит в контейнеры, как таковые виртуальные машины теперь нужны разве что под виндовые сервисы и их мало.
Ахахахахах. Нет. Контейнеры запускаются на тех же виртуалках, потому что виртуалки гораздо легче бекапить, мигрировать и обслуживать, чем bare-metal. Виртуалку в пределах кластера я могу перебросить с даунтаймом в пару секунд на другую физическую машину, а с контейнерами так нельзя.
А даунтайм в пределах кластера откуда возьмётся, если хост, на котором была ВМ - в порядке?
На время перемещение между хостами ВМ фризится и не может ничего делать, плюс время на перестройку ARP-кеша прежде чем роутер поймет, куда пакеты надо пересылать
На время перемещение между хостами ВМ фризится
"перемещение между хостами" следует читать как "переключение между копиями на хостах", правильно? Потому как перемещение как целое, включая перенос содержимого оперативной памяти VM - это никак не пара секунд, а сильно больше.
плюс время на перестройку ARP-кеша
Если просто пассивно ждать, когда он сам по себе переключится, то это долго: на Cisco, помнится таймаут ARP был лет двадцать назад по дефолту полчаса. Но скорее всего, в виртуалку передается сигнал об отключении, а потом - подключении виртуального сетевого адаптера, а ОС, подерживающая media sense (сейчас они, наверное, уже все поддерживают) по факту подключения рассылает по ARP свой MAC. А то и просто обе копии VM используют один и тот же MAC, и ARP трогать не надо - достаточно просто послать пакет с этим MAC источника в нужный порт физического коммутатора, чтобы он понял, куда дальше слать пакеты с эти адресом. Наверное, так?
PS Эти предположения у меня - по факту знакомства с онлайновой миграцией в Hyper-V, но, предполагаю, что VmWare работает аналогично
До секунды на переключение (vm stun time), но даже этого много для нагруженных приложений, а ненагруженные переживут переключение контейнера в кластере и vmotion тоже не сильно нужен.
Предлагаете и мне присоединиться к теме "vMotion не нужен"? Не буду. Я тут комментарий оставил чисто чтобы уточнить, что автор предыдущего имел в виду.
PS Когда я занимался эксплуатацией ПО, то под конец это были чисто AD и Exchange, а и в том, и в другом отказоустойчивость реализуется на уровне самого приложения. То есть, там - третий вариант реализации, который тут не рассматривается.
"перемещение между хостами" следует читать как "переключение между копиями на хостах", правильно? Потому как перемещение как целое, включая перенос содержимого оперативной памяти VM - это никак не пара секунд, а сильно больше.
Сначало копируется диск, потом память, потом фризится диск, копируется дифф диска, останавливается вм, копируется дифф памяти, запускается вм на новом хосте, разфризивается диск. Реальный простой вм — время копирования диффа памяти, а это мегабайты.
А то и просто обе копии VM используют один и тот же MAC, и ARP трогать не надо - достаточно просто послать пакет с этим MAC источника в нужный порт физического коммутатора, чтобы он понял, куда дальше слать пакеты с эти адресом. Наверное, так?
Один мак, да. Вот в зависимости от того, как там проснувшаяся ВМ посылает пакет, и определяется, сколько она без сети будет после миграции. По опыту — в районе пары секунд.
потом фризится диск, копируется дифф диска
а если хранилище вынесено в SAN какойнить то и диск фризить не надо и дифы хранить, только перенос оперативки
p.s. давно не брал в руки шашку, но это было настолько быстро что юзеры терминального сервера которые сидели в этой ВМки не замечали остановки при миграциях
@zatorax по сути прав. Ничего смешного нет, вы забываете про overhead. Сравните какой он у контейнеров, а какой у ВМ. Раньше то, что группировали по ВМ, теперь запихивают в одну ВМ с контейнерами. ВМ останутся конечно же, но контейнеры частично отъели этот рынок.
И еще есть такое явление, как доставка ВМ, обернутая в контейнер. Вы развертываете как обычно контейнер, управляете контейнером, но внутри ВМ работающая на базе KVM.
Виртуалку в пределах кластера я могу перебросить с даунтаймом в пару секунд на другую физическую машину, а с контейнерами так нельзя.
Необходимо уточнить, нельзя сделать именно живую миграцию, а все остальное без проблем можно. По факту это не особе критично. Если у вас есть план миграции, и вы его тщательно продумали, то даунтайм будет минимальный. На эти жертвы можно пойти, если вы желаете сэкономить на ресурсах, потому что, overhead у ВМ достаточно большой.
Зачем бекапить контейнеры?
Maas поможет решить проблему с развертыванием ос на голом железе, я уж не говорю про какие то там manageriq или ironic.
В таблице где сравниваются различные продукты, что за KVM такой? Или это опять модуль ядра Линукс в целый продукт выделяют?
Мне кажется, что под KVM имеется ввиду Docker, Qemu, CRI-O и т.д.
Докер никакого отношения к KVM не имеет
Вы погуглили "Docker KVM", и радостно принесли первую же ссылку, так?
А Вы даже погуглить не смогли, для того чтобы узнать, что контейнеры докер запускает в предварительно созданной одной на все контейнеры VM?
В вашей тутошней Специальной Олимпиаде я участвовать не хочу, но хочу получить уточнение к той интересной ингформации, которую вы тут выше приводили:
пилоты с PostgreSQL и ClickHouse у нас показали, что для продуктива контейнеризация никаких преимуществ перед VM не дает.
Уточните, пожалуйста, запускались ли в этих пилотах контейнеры в Docker Desktop или же чисто под Docker Engine в хостовой ОС?
Без разницы. В любом случае миграцию в живую реализовать не удалось.
С точки зрения поддержки, миграция VM в живую оказалась жирным плюсом для VMWare.
Хотя вы ответили не на тот вопрос, всё равно, благодарю.
Тогда я не понял вопроса. Я писал:
"Но пилоты с PostgreSQL и ClickHouse у нас показали, что для продуктива контейнеризация никаких преимуществ перед VM не дает, а поддержку заметно усложняет."
Указать в ответе отсутствующие преимущества невозможно. А ни Docker Desktop, ни Docker Engine миграцию контейнеров в живую не поддерживают. Что еще Вы ожидали услышать?
Тогда я не понял вопроса.
Вопрос был про окружение, в котором запускались контейнеры:
Уточните, пожалуйста, запускались ли в этих пилотах контейнеры в Docker Desktop или же чисто под Docker Engine в хостовой ОС?
PS На самом деле, меня заинтересовал вопрос о накладных расходах на выполнение. А вопросы трудоемкости поддержки меня не интересуют.
Миграцию контейнеров? Если да, то там есть наработки по миграции процессов ОС, но до mainline linux вроде пока не добралось.
А Вы даже погуглить не смогли, для того чтобы узнать, что контейнеры докер запускает в предварительно созданной одной на все контейнеры VM?
Как сказать "я ничерта не шарю в технологии" не говоря этого.
Уже сказали:
Докер никакого отношения к KVM не имеет
При том что в документации на Docker Desktop популярно описано, какое отношение к нему имеет KVM.
Ну так я про то же. Вы можете принести ссылку, но совершенно не способны осмыслить то, что по ней говорится.
Это же уровня "ну вот видите, какая-то часть машин использует водород, значит у нас авто-индустрия, основанная на водороде."
По факту — 99% докер-инсталляций никак не связаны с KVM, потому что его использует Docker Desktop, совершенно отдельная штука уровня "красивый интерфейс для разработчиков".
Что совсем не тянет на первоначальный тезис "под KVM имеется ввиду Docker", в реплаи к которому вы и влезли со своим навыком гугления.
"ну вот видите, какая-то часть машин использует водород, значит у нас авто-индустрия, основанная на водороде."
Наоборот, исходя из этого нельзя сказать, что автоиндустрия не имеет никакого отношения к водороду.
По факту — 99% докер-инсталляций никак не связаны с KVM
Да даже если 99.99%, достаточно 0.01% для того, чтобы из-за слова "никакого" эта фраза стала ложной:
Докер никакого отношения к KVM не имеет
тезис "под KVM имеется ввиду Docker"
Я тоже считаю этот тезис ложным, так как докер вполне может обходиться без KVM. Но их этого следует, что докер с KVM связан лишь косвенно, но вполне определенное отношение к KVM в ряде случаев он имеет.
А вы осознанно игнорируете контекст диалога, да? Потому что иначе невозможно будет читать это "никакого" в отрыве от всего остального и цепляться за это.
Т.е. для меня это абсолютно абсурдный диалог, который при замене KVM на JS выглядит так:
— Под JS подразумевается Docker
— Что, простите? Docker не имеет никакого отношения к JS, это совсем не пересекающиеся технологии
— А вот и нет, смотрите, Docker Desktop использует JS!!
— Но ведь то, что в какой-то системе Y используется технология Х никак не помогает аргументировать тезис "Под Х подразумевается Y"...
— Что, нечего возразить, да? Вот документация, там упоминается JS! Вот код, там есть JS! А значит есть связь! А значит твое "никакого отношения" неверно! А значит весь твой тезис ложный! А раз твой тезис ложный, я выиграл в споре! Выиграл!
А вы осознанно игнорируете контекст диалога, да?
Вполне осознанно, так как ключевые слова демагогии, такие как "никакого", "никогда", "всегда" и т.п. считаю недопустимыми в дискуссии.
— Под JS подразумевается Docker— Что, простите? Docker не имеет никакого отношения к JS, это совсем не пересекающиеся технологии— А вот и нет, смотрите, Docker Desktop использует JS!!
Всё, косвенная связь между Docker и JS доказана, значит слово "никакого" уже употреблять было недопустимо.
Вполне осознанно, так как ключевые слова демагогии, такие как "никакого", "никогда", "всегда" и т.п. считаю недопустимыми в дискуссии.
Всё, косвенная связь между Docker и JS доказана, значит слово "никакого" уже употреблять было недопустимо.
А, я правильно понимаю, что вы выбрали в споре борьбу не с самой идеей а со способом формулировки?
Который, в свою очередь, основан на том, что люди обычно держат в голове контекст и часто не считают нужным предварять каждое сообщение дисклеймером вида "когда я использую слово "никакого", то я его применяю относительно тезиса, представленного в прошлом сообщении, и не пытаюсь этим сказать, что во всей IT-области невозможно найти ни одного близкого пересечения между понятиями "Docker" и "KVM", включая ситуации когда докер запускается в KVM и когда KVM запускается в докере, а так же случаи обмена кодом и общения разработчиков этих проектов на конференциях, а так же случаи, когда один человек коммитит в два проекта".
И после всего этого вы гордо называете меня демагогом?! У вас там белый плащ-то, как, не жмет? Он хоть с подкладом у вас? А то как бы вы там не замерзли, на вершине моральных устоев.
А, я правильно понимаю, что вы выбрали в споре борьбу не с самой идеей а со способом формулировки?
А я хоть слово сказал про идею? Я оспариваю только применение ключевых слов демагогии в технической дискуссии.
У вас там белый плащ-то, как, не жмет? Он хоть с подкладом у вас? А то как бы вы там не замерзли, на вершине моральных устоев.
Спасибо, что вынуждены были перейти на личности, подтвердив мои подозрения. ЧТД.
А я хоть слово сказал про идею? Я оспариваю только применение применение ключевых слов демагогии в технической дискуссии.
Так вот это и удивляет.
Построить всю аргументацию на формальном несоответствии реальности слова, вырванного из контекста
@
В конце заявить что собеседник использует приемы демагогии.
Ребята позвольте добавить свои пять копеек. @vvzvladне прав что Docker не имеет никакого отношения к KVM. И зря минусуете @ptr128.
Первое. Вы говорите про два продукта, это: Docker CE и Docker Desktop.
Docker CE является движком и базируется на механизмах изоляции ядра Linux. Функции cgroups и namespaces. Docker CE позволяет автоматизировать управление контейнерами. Вы можете запустить контейнер и без Docker, но вам придется все делать ручками.
Итак, для работы Docker CE необходима ОС на базе Linux, серверный или desktop вариант, ни KVM, ни какая другая поддержка аппаратной визуализации не требуется. Docker CE работает без KVM прекрасно.
Второе. Docker Desktop это графический инструмент, позволяющий работать с Docker контейнерами. Просто приятно тупо тыкать на кнопки, взамен ввода тонны команд.
Docker Desktop работает на базе Docker CE.
И вот для Docker Desktop действительно необходима поддержка KVM, ну так это реализовали программисты из компании Docker Inc. Причем необходима не серверная версия Linux, а с рабочим столом: Gnome, KDE, или MATE Desktop. @ptr128 прав когда ссылается на Install Docker Desktop on Linux, но это справедливо только для Docker Desktop.
Отвечаем на вопрос, требуется ли KVM для работы Docker?
Для работы Docker CE, НЕТ. А для графического продукта Docker Desktop, ДА.
Кратко читаем Основы современной контейнеризации.
Хабр конечно же меня умиляет, поставить комментарию -1 это круто) мне прям смешно). Уважаемый минусующий, напишите хоть что вам не понравилось). Я никого не выгораживаю, просто хабрапользователю @ptr128необходимо было сразу объяснить, что у меня написано в комментарии, и все вопросы бы отпали. Необходимо было четко развести понятия Docker CE и Docker Desktop, а то про какой-то нативный Docker начали писать, пользуйтесь нормально терминами. В споре что-то упомянули про cgroups и namespaces, но не объяснили что это.
В подобных случаях вспоминается момент, слон это что-то хвостатое, нет, неверно, это что-то с хоботом, нет, это что-то с толстыми ногами!
Это только десктоп версия для упрощения разработки, на Win и Mac тоже в виртуалке. В бой уже нативная идёт только на Linux (namspaces + cgroups) - без KVM.
Может, и бизнес компании чувствовал бы себя лучше, если бы она не отказалась от российских клиентов, но история не знает сослагательного наклонения.
Доооо, конечно, российские клиенты наверное отвечали за целых 0.01% выручки, и исключительно нежелание продолжать отношения с ними похоронило целый бизнес технологического гиганта.
... а может просто дело в том, что некогда сложная технология вышла в тираж - появилось больше конкурентов, продукты которых даже не зазорно использовать в проде? Контейнеры, опять же, потеснили виртуалки
"Контейнеры вытеснили виртуалки" звучит как "трансмиссии вытеснили автомобили".
Совершенно верно, но я сказал не это. Я сказал, цитирую: "потеснили виртуалки", что звучит уже как "самокаты потеснили велосипеды".
Нет, не звучит. Раньше действительно нарезали виртуалки под каждый сервис, потому что так проще было. Щас одна виртуалка под несколько связанных сервисов или даже под десяток обычное дело, потому что накладных расходов меньше, чем с виртуалками.
как "элетромоторы вытяснили бензиновые автомобили", уж. Хорошая аналогия - она как кошка с дверцей!
Самой виртуализацией сейчас никого не удивить, но если добавить SDS, SDN и DR, то конкурент останется всего один - Nutanix с подпиской и сопоставимым ценником.
Мое личное мнение: технологии VMware имели и до сих пор имеют хороший потенциал. То, что "убило" рынок, - это облако. VMware проиграла, не захватив свою долю этого рынка, слишком сильно сосредоточившись на хостинге и ентерпрайз..
Статья с определенным подтекстом. Вечно кого то хоронят. Амд Хоронили когда то, сейчас интел. У ВМВаре есть фундаментальное отличие от всех типо конкурентов, это наличие за спиной мощного хардверного игрока. На российском рынке давно сложилось одно впечатление, зачем еще за один форк квм платить, если есть бесплатное.
тут всегда вилка - с одной стороны большие компании которые приносят прибыль с другой много мелких которые требуют отвлечения но процент прибыли не такой. понятно что можно убрать всех кто не приносит достаточной прибыли, но тогда vmware скатывается в нишевый продукт и приводит к тому что нет специалистов ни кто новые решения на ней не заказывает.
даже сейчас у них есть люди которые знают от a(A) До Z(Я) весь продукт и выросли они не из vmware, а сначала работали с ним в коммерции. то через условные 5-10 лет где они возьмут специалистов? и пойдет замкнутый круг - нет специалистов, нет поддержки, нет довольных клиентов.
Что ж, похоже хоть одну компанию потребители и пользователи наказали долларом за "подписку на всё" и отсутствие бессрочных лицензий. Кто следующий?
"Не уйди VMware с нашего рынка виртуализации в 2022 году, ситуация на нем была бы совсем другой" - тут поспорю. Развивались бы и наши компании, просто не так быстро. А так те же айсиписистем и редсофт норм так скакнули и прокачались буквально за год-полтора
Пост опубликован с тегом "Мнение", но боюсь это факт.
Неприятно резкое увеличение стоимости лицензий VMWare привело к тому, что хостер поднял стоимость машин практически в два раза. Причем держался до последнего, до декабря прошлого 2024 года. Пришлось под новый год переносить все на OpenStack.
Если новая схема лицензирования привела бы к увеличению стоимости машины на 20-30%, ну ОК. Но цена поднялась практически в два раза, Карл, 2x!
С таким подходом Broadcom гарантированно закопает VMware.
Кто-то сказал про Red Hat Virtualization? А как вы забыли про oVirt?
На Хабре последний пост про oVirt за 2 часа. Часть 4. Базовые операции, датирован 2020 годом, но все же.
Перевод хороший, но могли немного поглубже капнуть и проработать вопрос с ситуацией увеличения стоимости лицензий.
У вас в посте, первым в разделе Отзывы клиентов, фигурирует VMware Workstation Pro.
Создается такое впечатление, что это одна из самых основных проблем. На самом деле, VMware на VMware Workstation Pro практически ничего не зарабатывала. Именно поэтому Broadcom сделала его бесплатным. Поэтому проблема вовсе не в VMware Workstation Pro.
А вот рост стоимости лицензий для VMware vSphere, могли написать КАПСЛОКОМ, выделить жирным, установить цвет КРАСНЫЙ, и еще добавить мигание.
Закат VMware: как технологический гигант утратил лидерство