Сообщество - Лига Сисадминов

Лига Сисадминов

2 236 постов 18 766 подписчиков

Популярные теги в сообществе:

32

Пора прощаться с VMware by Broadcom. История в нескольких частях. Часть 1

Для лиги лени: про бывшую VMware, теперь VMware by Broadcom. Чего было и чего ждать

План, наверное, такой.
Часть 1. Чего и почему ждать.
Часть 2. Fast start. Литература и сайты для тех, кто вляпается в это легаси. 
Часть 3. Прочее.

Часть 1. Чего и почему ждать.

2 октября 2025 года закончится эпоха VMware, как ее помнят олды, заставшие выход ESX (без i), переход на ESXi (с i), и ее покупку Broadcom 22 ноября 2023.
2 октября 2025 заканчивается продление поддержки VMware vSphere 7.x и VMware vSAN 7.x, но проблемы с этой «поддержкой» начались уже сейчас.
В чем проблемы? Да во всем.
Базу поддерживаемого оборудования сломали, и для ESXi и для vSAN. Они разные, если вы не знали.
Базу статей переломали и убирают за paywall.
Последние патчи тоже убрали за paywall.
Возможно, следующие патчи будут с уникальной подписью – то есть, встающие только на эти процессоры, при наличии именно этих серийных номеров процессора и материнской платы.
Цены поднимают, как и минимальный набор закупки.
Это все просто про деньги. Кто с FC от Broadcom работает, тот знает, что их FC коммутаторы где-то на рубеже перехода от FOS 6 на FOS 7 (могу путать, давно было) при обновлениях и при окончании поддержки, стали превращаться в бесполезный кирпич.
Но все равно, одним движением перейти, пусть от даже крайне тормозной Broadcom (Brocade G710 460 ns port-to-port latency at 64G speed) к нормальной 200/400G Cisco и Arista (на Xilinx В 7130 с его примерно 50 ns и ниже), не выйдет. Дорого, проще рядом строить инфраструктуру поверх 200/400G и гиперскейлеров. И уже есть 800 G (Arista 7060X5, Hyawei CloudEngine 16800-X).

Разумеется, у разных министерств РФ есть шанс занять оплатить захват освобождающихся ниш на рынке – как раз тут отдельные энтузиасты говорят, что они завтра готовы вернутся к играм на Pentium 2, так можно рядом и производство хабов возродить. На 350 нм можно даже, наверно, мегабитный свитч сделать, или модем ISDN-128, а рядом и мегабитный роутер на Zebra, или даже Quagga. Жаль, что энтузиасты не готовы рассказать, почему судьба как-бы-полу-готовой линии  350 нм будет лучше, чем у купленной и доставленной в РФ готовой линии 130 нм, но я все понимаю.

Так что, пока все идет так, как и предсказывали чрезвычайно уважаемые люди – как в Computer Associates и в UCC-7 - CA-7. Будет дорого и плохо.

Почему так будет – понятно. Broadcom вложил в покупку 69 миллиардов долларов, надо как-то отбивать, а при текущем состоянии доходов – расходы окупятся хорошо если лет через 10, хотя операционная прибыль уже выросла.

Почему так будет в глобальном смысле – тоже понятно. На рынок выходят решения на arm, число ядер на Intel и AMD растет, значит в те же 2U «обычного» сервера можно набить 2*6 терабайт памяти и запускать виртуализацию даже на KVM. Вдобавок, облака и контейнеры отбивают долю рынка у он-прем виртуализации, поэтому проще сосредоточиться на тех, кто будет плакать, но заплатит, чем на тех, у кого денег нет. Капитализм. Может, кто-то из сервис провайдеров еще купит, за все заплатит конечный покупатель.

Подводя итог, начинать спрыгивать надо было в 2022 году, все было сказано еще тогда открытым текстом, Broadcom's stated strategy ignores most VMware customers. Сейчас надо бежать, и чем быстрее, тем лучше.

Бежать особо некуда.
Microsoft S2D проще в настройке, но лицензирование стоит, с учетом дозакупок лицензий на ядра, таких как Microsoft Windows Server 2025 16-core Datacenter Additional License WW SW SKU # P77107-B21, по 5500$ – 5800 $, очень дорого.
Получается где-то по 350$ за ядро, и тогда 150$ за ядро на VCF в год – не так и дорого. Тем более, что VMware standard стоит всего 50$ (за ядро в год). 

(Уточнение. Согласно калькулятору Windows лицензия обойдется в 36960 за 2*48 ядер, $385 за ядро)

Плюс новые люди, плюс смена архитектуры, поэтому в целом, с новыми серверами, где ядер на сокет побольше, можно и потерпеть.

Нет проблем с убежать на KVM в масштабе 1-2 серверов.
Проблемы убежать на KVM, если у вас реальных задач на 10 современных серверов (48 – 64  физических ядер на сокет, 6 тб памяти на сокет, 24 PCIe Gen5 NVME диска на 2U сервер) – нет никаких. На таком железе вы хоть на Ceph можете строить архитектуру, с выделенными нодами хранения. Ну да, будет дорого, хотя как посчитать. Будет нужно много дорогого железа, будут нужны люди, умеющие что-то большее, чем apt install, но сейчас не 2010 -2015 год, и проблему скорости на опенсорс решениях можно решить даже железом. Людей, разве что, дешевых, нет. Все подались в девопсы и SRE, инфраструктурщики и прочие Linux админы на рыне труда РФ не нужны (то есть нужны, но за цену эникея).
Раньше, очень давно, лет 10 назад, еще можно было намайнить себе премию на корпоративном проде, до сих пор в телеграмме есть «Российская группа по майнингу на виртуалках» - Virtual mining user group, но, при текущем хешрейте, производительности не хватит даже на пиво в месяц.

Проблемы будут, если у вас огромная старая архитектура 10-15 летней давности, где 4-6-8, или даже 10, ядер на сокет, и общий подход «оно же работает, а ключи сгенерите, там точнее не сложнее, чем в ArtMoney». Возможно, не сгенерите. Возможно, сгенерите, и получите кирпич. Можно ли не обновлять, и так и остаться работать на линейке 7? Можно. Но, рано или поздно, там повторится ситуация или с лицензиями, или с тем, что патчей просто не будет. Как уже нет для 5.5., 6.0, 6.5 и 6.7. Будут только индивидуальные патчи, только на версию 9, и больше никаких. И людей не будет, готовых этих нормально заниматься. Да их и было не так много.

Подводя итог.
Кто хотел убегать – давно побежал. Кто не очень хотел, как Siemens – не побежал. Для конечного работника важно другое – продукты VMware by Broadcom уходят с мирового публичного рынка, и спрос на таких сотрудников, с такими знаниями, будет падать. Может быть, но это не точно, будет как с IBM + Cobol – когда продукт очень нужен, очень дорогой, но весь рынок, это десяток очень больших покупателей.

Показать полностью

Точёные vs Дрочёные...

Или saas vs onpremise.

Собственно с одной стороны казалось бы передал каким то ба́шковитым спецам узкую функцию и пусть они её и крутят на своих серверах.

Но всё это хорошо ровно до тех пор пока у них не случается факап. Факапят все, не надо думать что факапы по оборудованию, софту или персоналу это удел мелких компаний, вон недавно Яндекс жиденько...

А с другой стороны сижу смотрю, ну лежит. Но проблема то не на моей стороне, вне моих задач и обязанностей.

Так что же получается, для сисадмина лучше saas а для надёжности бизнеса on premise?

Или нет :)

Отличная работа, все прочитано!