Но компания Broadcom, которая приобрела VMware в декабре 2023, уже перевела лицензирование на подписочную модель. Теперь, чтобы получить новую лицензию, нужно полностью менять все ключи с 7.0 на 8.0 и приобретать подписку, а в России это невозможно сделать легально:
Если читать то, что вы написали, то тут написано "Нужно сделать X, а в РФ это сделать нельзя". Я вам возражаю, что делать X не нужно.
Так что обновление VMware vSphere до версии 8.0 с учетом новой подписочной модели лицензирования на ПО — задача практически невыполнимая.
Как я писал выше - обновление до 8ки и подписочная модель никак не связана явным образом.
Ну и кмк, вы так и не разобрались до конца, как работало лицензирование VMware:
на свежую версию VMware vSphere 8.0, которая появилась на рынке осенью 2022 года. Сразу после выхода можно было приобрести бессрочную лицензию на нее.
Лицензии никогда не приобретались на какую-то конкретную версию (6/7/8). Лицензия приобреталась на продукт и редакцию (vSphere Enterprise Plus). На момент покупки лицензии вы имели право использовать любую доступную в этот момент версию - например, 6 или 7 или 8. После этого вы имеете право использовать любую новую версию (включая патчи), пока у вас активен Support and Subscription. После его окончания вы имеете право использовать последнюю версию, которая вышла на момент окончания SnS. Таким образом, в 2022 году заказчики легко могли получить ключи на 8ую версию на my.vmware.com сделав upgrade ключей (это в общем-то не связано с обновлением самой инфраструктуры).
но ни один системный интегратор не возьмет ее на саппорт
Ну и вот тут у меня большие сомнения. Потому что насколько я знаю, такая поддержка уже оказывается и далеко не одним интегратором. Не говоря уже о том, что скачать дистрибутивы vSphere в общем-то совсем не сложно, т.к. все SHA/MD5 хэши известны и их можно проверить на портале.
Теперь, чтобы получить новую лицензию, нужно полностью менять все ключи с 7.0 на 8.0 и приобретать подписку
Это не правда. Вы видимо так и не разобрались до конца, как работает SnS у VMware/Broadcom. Любой заказчик VMware, у которого была активна SnS на момент выхода 8.0 (а это напомню 1.5 года назад) и у которого активен личный кабинет имеет право на обновление ключей и установку 8.0. Те, у которых SnS активен и сейчас (и, разумеется, не заблокирован ЛК) - имеет право на установку любых последних релизов (включая 8.0U3). Для этого не требуется приобретать новый подписочные лицензии.
После этой даты для пользователей больше не будет доступных обновлений и патчей продукта, в том числе по информационной безопасности
Это не так. Если есть действующий SnS на perpet лицензии (а самые мудрые заказчики купили поддержку на 3 года осенью 2023, а у многих она и так не кончилась), то они имеют полное право на обновление.
Понятно, что там не линейно, но если вы посмотрите, например, на Dell PowerStore (а так же на большинство других), то объем RAM в контроллере там различается от 192GB до 2.5TB. При этом максимумы (число дисков, почти все лимиты и прочее) там одинаковые, но также, главное, и одинаковая ОС во всей линейке тоже (отсюда и одинаковые/близкие overhead, потребление системных служб и т.д.). А различие между ними в производительности и объеме кэша на чтение и буфера на запись, что напрямую влияет на производительность (как минимум через % Cache Hits) - Dell EMC PowerStore: Data Efficiencies (raxcdn.com)
А еще RAM может использоваться (и обычно используется) как Write Buffer и/или Read Cache, что позволяет 1.) Значительно сократить latency при чтении горячих данных 2.) Сериализировать запись (из кучи маленьких случайных блоков сформировать один большой блок и почти последовательно сбросить его на диски) 3.) Уменьшить число операций на дисках на бекенде. В этих сценариях -чем больше RAM на системе, тем больше размер буферов/кэшей.
Плотность тут не принципиальна вообще. HCI может быть построен как на обычных 2U железках (или 4U), так и на 1U, или даже на 4N/2U коробках. И да, высокоплотные сервера (те же 4N/2U) сейчас уже не популярны, потому что там вылезают ограничения по набивке (макс. TDP CPU, число RAM слотов, число дисков, карт I/O, etc), а толку никакого нет, т.к. стойку вы ими все равно не забьете. 42U стойка забитая 40 стандартными 1U серверами в средней/обычной набивке потребляет 32кВт и дает 109к BTU/h. Как правило, подвести столько электричества и забрать столько тепла проблематично в большинстве ЦОД. Поэтому плотность, наоборот, принудительно снижают, переходя на 2U сервера и, соответственно, уменьшая их количество на стойку в два раза.
где там объемы дисковые?
Когда блейд системы были более популярны, HCI можно было строить и на них - What Blade Servers Are Certified as VMware vSAN Ready Nodes? | Blades Made Simple Нужно ли это - другой вопрос. Для этого, в реальных кейсах, использовались или дисковые корзины в блейды (типа D3940 в Synergy) или лезвия с бОльшим число дисков (типа CH225 V5). Но сейчас это, действительно, уже мало кому нужно.
дисковые полки высокой плотности AIC JBOD J4078-02 и AIC JBOD J4078-01 (от 100 дисков 3,5)
Такие полки имеют крайне мало отношения к рассматриваемому сценарию. Ибо это, по определению, холодный/архивный тир хранения. Для промышленной нагрузки, в лице смешанной виртуальной инфраструктуры, уже давно большинство крупного Enterprise перешло на All Flash. HCI - это тоже быстрый/основной тир, а никак не холодное хранения. Более того, если мы говорим про плотность, то по сценарию из первого пункта у вас просто вместе с серверами уже идет 480 2.5 слотов на стойку. В случае классической инфраструктуры вам сервера и так, и так надо ставить, а сверху еще контроллеры и полки.
можно лицензировать только количество дисков, а диски докупать какие душе угодно
Не буду говорить за всех, но в самых популярных HCI решениях все аналогично - покупаете лицензии, а диски ставите какие угодно (понятно, что из HCL, но там есть практически все от вендорского железа до оригинальных Samsung/Intel/Micron/Seagate/WD/etc) дисков.
при потере части серверов (при перегреве) у меня "падает" вся инфраструктура и по всей видимости очень проблемно будет восстанавливаться
просто множество одинаковых хостов (или сразу стоек с серверами и ToR) + leaf (или leaf+spine если рост идет подами/блоками и есть superspine). Хосты, как правило, докупаются на основании рамочного договора закупки - есть цена одного сервера в нужной набивке (или несколько типов, если нагрузка сильно разнородная), по которым вы можете купить сколько вам надо в течение срока контракта.
Так и раньше было далеко не одна позиция. Как минимум, лицензия + поддержка/подписка. А теперь одна VVF, а вторая vSAN. Или вообще одна - VCF. Оптимизация. :) А если серьезно, то какая, по большому счету, разница? Все равно спеку всегда делал или партнер, или вендор, поэтому заказчику пофигу.
и что там, говорите, с постоянными лицензиями, которые купил и используешь ?
Да все просто - их больше нельзя купить. Только подписка на 1/3/5 года.
Модель лицензирования перетрясли, это просто неприятно. Как и цены.
Модель лицензирования сделали проще (с 8000 парт-номеров до нескольких десятков (ну может сотни, если все считать)). Как и просили пунктом выше. А цены.. It depends. Знаю тех, кто остался очень доволен. А знаю тех, кто остался ОЧЕНЬ нет.
Во-первых, потому что я в этой статье не вижу вопроса. Это не приглашение к диалогу, а монолог, который даже заканчивается выводом.
Во-вторых, ответ на вопрос "чем заменить vSAN" очень сильно зависит от кучи факторов. Например, окружения, требований и т.д. Под какую платформу, требования по импортозамещению, страна, куда это покупается и т.д.
Ну а если вам интересно мое мнение, то лично я считаю, что наиболее (если не единственная) адекватная замена vSAN для SMB сегмента в РФ - классический внешний сторадж (а там уж на вкус и цвет). Все остальное или требует очень высоких компетенций для проектирования и сопровождения, которых, как правило, нет в SMB организациях, или имеет те же ограничения, как и vSAN (например, не доступно к официальной покупке в РФ).
Самое болезненное Согласно VMware End Of Availability of Perpetual Licensing and SaaS Services - больше не будет таких пролуктов, как: VMware vSAN ROBO, VMware vSAN+, VMware HCI Kit
Не очень понимаю в чем описанная выше боль:
HCI Kit - это просто две лицензии (vSphere + vSAN), которые продавались под одним парт-номером. Не более того.
vSAN+ - это лицензия по подписке с серверов лицензирования в облаке. Вроде тут, да и много где такое, наоборот, не любят. Да и популярность оно не обрело.
vSAN ROBO - тут, с одной стороны, да, потому что если было много площадок, где мало хостов + мало ВМ на хост, то per-VM выходило заметно дешевле, чем per-CPU. Но теперь vSAN идет per-TiB, что в общем-то компенсирует (мало ВМ - мало TiB, мало платить за vSAN). Отсутствие ROBO, скорее, по vSphere ударило, чем по vSAN.
Но уж, чтобы сделать этот комментарий более полезным, то боль может быть в других местах:
1.) Больше нет редакций vSAN Std/Adv. Только старшая, полнофункциональная, которая бывшая Enterprise. И да, на Std сидело достаточно мало людей, ибо см. пункт 4, но вот Advanced был достаточно популярным, если не нужны были растянутые кластера, шифрование, файлеры, HCI Mesh и т.д.
2.) vSAN теперь per-TiB. Это значит, что если раньше у кого-то было очень много RAW Capacity per Node/CPU, то может стать дороже. Но если у кого-то было мало RAW per CPU, то наоборот. Но ИМХО, мне такой подход больше нравится. Стоимость схд должена определяться хранением, а не количеством хостов, к которым оно подключено (я сознательно оставляю за скобками сценарии с HCI Mesh/vSAN MAX).
3.) vSAN можно купить только для VVF (и там практически всегда надо платить сразу за TiB), или для VCF (но там уже входит 1 TiB на ядро, что часто перекрывает потребности). Отсюда вылезает момент, что если нужно много емкости, то дешевле купить сразу VCF, чем VVF+vSAN. Хорошо это или плохо - it depends.
4.) Плоское Per-RAW TiB лицензирование, по сути, убило гибриды. Потому что Usable на All Flash заметно выше при том же RAW, чем на гибридах, за счет Erasure Coding, Compression, Deduplication (это все входило в Advanced). И хотя гибридные vSAN уже давно были крайне нишевой штукой (по моим ощущениям, заметно меньше четверти инсталляций), кейсы под них были. Поэтому остается только vSAN All Flash, да еще и ESA, потому что там EC и Сompression намного лучше работают.
Я не обсуждаю дешево/дорого и удобно/неудобно. Кому-то дешево/удобно, и они покупают. Кому-то нет, и они не покупают. Тут у всех индивидуально.
Я говорю только то, использование образов MacOS для VMware, которые запускаются на НЕ-Apple железе нелегально: " The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so."
Поэтому при условии, что мы остаемся в правовом поле, нужно покупать Apple железо. Какое и как - дело лично каждого. И VMware никак не поможет в данном случае. Потому что multi-tenancy тоже нельзя: "only one (1) Device may remotely connect at any one time, whether directly or indirectly, to control the graphical desktop session of the Apple Software that is running and being displayed on the Home Mac;"
для разовых операций в виде теста софта можно использовать образы под VMWare
MacOS можно запускать только на железе Apple согласно их EULA. Вы, конечно, можете сказать, что пофиг и кто проверит, но если оставаться в легальном поле (потому что так мы можем дойти и до того, что еще дешевле будет MacMini украсть со склада), то для тестирования/разработки софта под MacOS/iOS нужно железо от Apple.
Вертикальное масштабирование — это здорово, но имеет несколько существенных недостатков в реальной жизни. 1.) Вертикально от масштабировать вы можете только диски (вариант выкинуть процессоры и заменить их на новые я не рассматриваю, ибо в реальности так никто не делает). А это значит, что если у вас кончился Compute, то хочешь не хочешь добавляй узлы. 2.) Это приводит к зоопарку, т.к. у вас получаются разные узлы на разных кластерах (ведь вам нужно разное отношение Storage/Compute под разные нагрузки). На больших объемах это сложно/дорого, и с точки зрения закупок, и с точки зрения эксплуатации. Даже в вашей документации: "Одно из выгодных для промышленной эксплуатации преимуществ гиперконвергенции – идентичность элементов инфраструктуры, а именно: узлов кластера. Это позволяет иметь "под рукой" ZIP-пакет в виде шасси, которым можно оперативно заменить вышедший из строя узел кластера vStack." 3.) На больших кластерах вертикальное масштабирование дает большой шаг роста, ибо диски вам стоит добавлять более-менее равномерно во все хосты в кластере. Плюс, если у вас два тира (SSD и HDD), то вам нужно наращивать не только Capacity, но и Cache, чтобы не уменьшать Cache/Capacity ratio 4.) Для действительно крупных заказчиков закупать отдельно диски просто организационно бывает сложно, ибо играется рамочный контракт на узлы целиком.
А про Storage Only узлы - можно ссылки на материалы по этому поводу? В документации, почему-то, ничего не могу найти.
Ну странно было (нет) не отметить главную проблему HCI архитектуры - невозможность независимого масштабирования (или ограниченную возможность) вычислительных ресурсов и ресурсов хранения? Т.е. если у вас кончилось место, но с Compute все хорошо, то все равно надо добавлять целиком сервера (т.е. и Compute, и Storage). И наоборот. А это не эффективно.
И разные производители, по-разному эту проблему решают. Отсюда и Compute-only nodes, и Storage-nodes, и шаринг емкости между кластерами, и вообще растаскивание компонентов обратно (aka dHCI, хотя ИМХО это ужасный термин).
из очереди на покупку выходят озадаченными те, кому был нужен CAPEX.
Ну как минимум доступна подписка на 5 лет и у очень многих заказчиков она проходит, как CAPEX, а не OPEX.
этого давно с опасением ждали, но откладывалось такое злое решение несколько раз.
Что к этому ведет, стало очевидно, когда ввели ограничение сверху на число ядер на сокет. Update to VMware’s per-CPU Pricing Model Плюс подписочные варианты (которые существовали и до Broadcom) были тоже per-Core. Да и стимул понятен (хотя и неприятно, безусловно) - число ядер растет намного более быстрыми темпами, чем рост нагрузок. И сейчас можно, например, взять и шесть 5-и летних двух сокетных серверов по 16 pCore, и упаковать в один сервер с двумя AMD EPYC™ 9654, что даст те же 196pCore, но два только сокета. И количество сокетов/лицензий схлопывается с 6 раз.
Broadcom было анонсировано закрытие 56 программных решений
Было анонсировано не закрытие "програмных решений", а прекращение продаж старых лицензий. Старые лицензии больше не доступны к покупке, но в новых бандлах все эти продукты по-прежнему доступны.
компания перестанет поддерживать и продавать перечисленные решения.
Поддержка на всё купленное продолжает оказываться в полном объеме до тех пор, пока действует поддержка. После её окончания, поддержку купить будет больше нельзя и нужно будет покупать подписку (которая включает в себя поддержку + подписку).
Платные решения перестанут поддерживаться по окончанию срока купленной лицензии.
У бессрочных лицензий (а в списке, в основном они, за некоторым исключением типа версий "+") нет срока лицензий. Ими можно пользоваться столько, сколько хотите, но поддерживаться они перестанут по окончанию срока купленной поддержки.
Больше нет лицензий per-socket - вместо этого per-core (для Addon могут быть свои метрики).
Текущие заказчики могут пользоваться бессрочными лицензиями сколько они захотят (на то они и бессрочные).
Поддержка на perpet будет до конца окончания контракта (условно те, кто в Октябре продлил/купил поддержку на 3 года, то она будет оказываться для них до Октября 2026). У кого она кончится - продлить ее на старые лицензии больше нельзя. Только переход на новую модель.
Нет конечно. Ниже себестоимости запускать никакого смысла нет. Но я писал не про себестоимость пуска, а себестоимость производства Falcon 9 (хотя я скептичен относительно озвученных абсолютных цен). Но если ракета стоит 60M и летает она 20 раз, то "себестоимость пуска" будет 3M. Да, я знаю, что там вторая ступень одноразовая, сверху топливо, обслуживание и многое другое, но и там будет сильно больше, но суть такая.
Внезапно, если спрос превышает предложение, то мы смело можем выкручить ценники вверх до тех пор, пока количество согласных запустить нагрузку по такой цене не станет строго равно числу доступных ракет. И при этом мы должны видеть резкое увеличение доли запусков коммерческих нагрузок (потому что сами себе мы ценники-то не увеличиваем).
И да, я понимаю, что и мое первое утверждение, и это является сильным упрощением, потому что есть огромное количество других не экономических факторов (от политики до желания левой пятки Маска и основных акционеров), но направление в целом мне видится все же корректным.
Вы лукавите. У вас написано явно другое:
Если читать то, что вы написали, то тут написано "Нужно сделать X, а в РФ это сделать нельзя". Я вам возражаю, что делать X не нужно.
Как я писал выше - обновление до 8ки и подписочная модель никак не связана явным образом.
Ну и кмк, вы так и не разобрались до конца, как работало лицензирование VMware:
Лицензии никогда не приобретались на какую-то конкретную версию (6/7/8). Лицензия приобреталась на продукт и редакцию (vSphere Enterprise Plus). На момент покупки лицензии вы имели право использовать любую доступную в этот момент версию - например, 6 или 7 или 8. После этого вы имеете право использовать любую новую версию (включая патчи), пока у вас активен Support and Subscription. После его окончания вы имеете право использовать последнюю версию, которая вышла на момент окончания SnS. Таким образом, в 2022 году заказчики легко могли получить ключи на 8ую версию на my.vmware.com сделав upgrade ключей (это в общем-то не связано с обновлением самой инфраструктуры).
Ну и вот тут у меня большие сомнения. Потому что насколько я знаю, такая поддержка уже оказывается и далеко не одним интегратором. Не говоря уже о том, что скачать дистрибутивы vSphere в общем-то совсем не сложно, т.к. все SHA/MD5 хэши известны и их можно проверить на портале.
Это не правда. Вы видимо так и не разобрались до конца, как работает SnS у VMware/Broadcom. Любой заказчик VMware, у которого была активна SnS на момент выхода 8.0 (а это напомню 1.5 года назад) и у которого активен личный кабинет имеет право на обновление ключей и установку 8.0. Те, у которых SnS активен и сейчас (и, разумеется, не заблокирован ЛК) - имеет право на установку любых последних релизов (включая 8.0U3). Для этого не требуется приобретать новый подписочные лицензии.
Это не совсем так. Окончание поддержки означает, что Broadcom имеет право не выпускать новые патчи, но не означает, что точно не будет. В этом месяце Broadcom выпустил патчи на 6.7 (VMware vCenter Server 6.7 Update 3u Release Notes), поддержка которой закончилась еще в 2022. При этом для того, чтобы его скачать не требуется наличие активной SnS, т.к. это критический патч безопасности, которые теперь доступны всем. Zero Day (i.e., Critical) Security Patches for vSphere (7.x and 8.x) Perpetual License Customers with Expired Support Contracts (broadcom.com)
Это не так. Если есть действующий SnS на perpet лицензии (а самые мудрые заказчики купили поддержку на 3 года осенью 2023, а у многих она и так не кончилась), то они имеют полное право на обновление.
Понятно, что там не линейно, но если вы посмотрите, например, на Dell PowerStore (а так же на большинство других), то объем RAM в контроллере там различается от 192GB до 2.5TB. При этом максимумы (число дисков, почти все лимиты и прочее) там одинаковые, но также, главное, и одинаковая ОС во всей линейке тоже (отсюда и одинаковые/близкие overhead, потребление системных служб и т.д.). А различие между ними в производительности и объеме кэша на чтение и буфера на запись, что напрямую влияет на производительность (как минимум через % Cache Hits) - Dell EMC PowerStore: Data Efficiencies (raxcdn.com)
А еще RAM может использоваться (и обычно используется) как Write Buffer и/или Read Cache, что позволяет 1.) Значительно сократить latency при чтении горячих данных 2.) Сериализировать запись (из кучи маленьких случайных блоков сформировать один большой блок и почти последовательно сбросить его на диски) 3.) Уменьшить число операций на дисках на бекенде. В этих сценариях -чем больше RAM на системе, тем больше размер буферов/кэшей.
Раньше были бесплатные VMware Workstation Player и VMware Fusion Player + платные (даже для личного использования) более функциональные Workstation/Fusion Pro. Сравнения на сайте больше не доступно, но осталось, например, вот тут - VMware Workstation Pro vs VMware Workstation Player (nakivo.com) Теперь сделали Pro версии бесплатными для личного использования, а Player убрали (т.к. в них нет больше смысла, ибо это урезанные версии Pro). Там в статье есть ссылка на блог с деталями - https://blogs.vmware.com/teamfusion/2024/05/fusion-pro-now-available-free-for-personal-use.html
Вы как-то намешали всё в огромную кучу...
Плотность тут не принципиальна вообще. HCI может быть построен как на обычных 2U железках (или 4U), так и на 1U, или даже на 4N/2U коробках. И да, высокоплотные сервера (те же 4N/2U) сейчас уже не популярны, потому что там вылезают ограничения по набивке (макс. TDP CPU, число RAM слотов, число дисков, карт I/O, etc), а толку никакого нет, т.к. стойку вы ими все равно не забьете. 42U стойка забитая 40 стандартными 1U серверами в средней/обычной набивке потребляет 32кВт и дает 109к BTU/h. Как правило, подвести столько электричества и забрать столько тепла проблематично в большинстве ЦОД. Поэтому плотность, наоборот, принудительно снижают, переходя на 2U сервера и, соответственно, уменьшая их количество на стойку в два раза.
Когда блейд системы были более популярны, HCI можно было строить и на них - What Blade Servers Are Certified as VMware vSAN Ready Nodes? | Blades Made Simple Нужно ли это - другой вопрос. Для этого, в реальных кейсах, использовались или дисковые корзины в блейды (типа D3940 в Synergy) или лезвия с бОльшим число дисков (типа CH225 V5). Но сейчас это, действительно, уже мало кому нужно.
Такие полки имеют крайне мало отношения к рассматриваемому сценарию. Ибо это, по определению, холодный/архивный тир хранения. Для промышленной нагрузки, в лице смешанной виртуальной инфраструктуры, уже давно большинство крупного Enterprise перешло на All Flash. HCI - это тоже быстрый/основной тир, а никак не холодное хранения. Более того, если мы говорим про плотность, то по сценарию из первого пункта у вас просто вместе с серверами уже идет 480 2.5 слотов на стойку. В случае классической инфраструктуры вам сервера и так, и так надо ставить, а сверху еще контроллеры и полки.
Не буду говорить за всех, но в самых популярных HCI решениях все аналогично - покупаете лицензии, а диски ставите какие угодно (понятно, что из HCL, но там есть практически все от вендорского железа до оригинальных Samsung/Intel/Micron/Seagate/WD/etc) дисков.
В HCI решениях, вы легко можете потерять хоть всю стойку и ничего не упадет. В VMware vSAN это Fault Domains (Designing and Sizing vSAN Fault Domains (vmware.com)), в Nutanix - Rack Awareness (Rack Awareness (nutanix.com)),
просто множество одинаковых хостов (или сразу стоек с серверами и ToR) + leaf (или leaf+spine если рост идет подами/блоками и есть superspine). Хосты, как правило, докупаются на основании рамочного договора закупки - есть цена одного сервера в нужной набивке (или несколько типов, если нагрузка сильно разнородная), по которым вы можете купить сколько вам надо в течение срока контракта.
Скорее наоборот. HCI очень активно используется в супер большом Enterprise, где уже задолбались СХД добавлять в инфраструктуру пачками каждый квартал.
На VMworld в далеком 2020 показывали цифры с телеметрии (~20% заказчиков и самых крупных там нет, т.к. им нельзя в телеметрию).
Так и раньше было далеко не одна позиция. Как минимум, лицензия + поддержка/подписка. А теперь одна VVF, а вторая vSAN. Или вообще одна - VCF. Оптимизация. :) А если серьезно, то какая, по большому счету, разница? Все равно спеку всегда делал или партнер, или вендор, поэтому заказчику пофигу.
Да все просто - их больше нельзя купить. Только подписка на 1/3/5 года.
Модель лицензирования сделали проще (с 8000 парт-номеров до нескольких десятков (ну может сотни, если все считать)). Как и просили пунктом выше. А цены.. It depends. Знаю тех, кто остался очень доволен. А знаю тех, кто остался ОЧЕНЬ нет.
Во-первых, потому что я в этой статье не вижу вопроса. Это не приглашение к диалогу, а монолог, который даже заканчивается выводом.
Во-вторых, ответ на вопрос "чем заменить vSAN" очень сильно зависит от кучи факторов. Например, окружения, требований и т.д. Под какую платформу, требования по импортозамещению, страна, куда это покупается и т.д.
Ну а если вам интересно мое мнение, то лично я считаю, что наиболее (если не единственная) адекватная замена vSAN для SMB сегмента в РФ - классический внешний сторадж (а там уж на вкус и цвет). Все остальное или требует очень высоких компетенций для проектирования и сопровождения, которых, как правило, нет в SMB организациях, или имеет те же ограничения, как и vSAN (например, не доступно к официальной покупке в РФ).
Самое болезненное Согласно VMware End Of Availability of Perpetual Licensing and SaaS Services - больше не будет таких пролуктов, как:VMware vSAN ROBO,
VMware vSAN+,
VMware HCI Kit
Не очень понимаю в чем описанная выше боль:
HCI Kit - это просто две лицензии (vSphere + vSAN), которые продавались под одним парт-номером. Не более того.
vSAN+ - это лицензия по подписке с серверов лицензирования в облаке. Вроде тут, да и много где такое, наоборот, не любят. Да и популярность оно не обрело.
vSAN ROBO - тут, с одной стороны, да, потому что если было много площадок, где мало хостов + мало ВМ на хост, то per-VM выходило заметно дешевле, чем per-CPU. Но теперь vSAN идет per-TiB, что в общем-то компенсирует (мало ВМ - мало TiB, мало платить за vSAN). Отсутствие ROBO, скорее, по vSphere ударило, чем по vSAN.
Но уж, чтобы сделать этот комментарий более полезным, то боль может быть в других местах:
1.) Больше нет редакций vSAN Std/Adv. Только старшая, полнофункциональная, которая бывшая Enterprise. И да, на Std сидело достаточно мало людей, ибо см. пункт 4, но вот Advanced был достаточно популярным, если не нужны были растянутые кластера, шифрование, файлеры, HCI Mesh и т.д.
2.) vSAN теперь per-TiB. Это значит, что если раньше у кого-то было очень много RAW Capacity per Node/CPU, то может стать дороже. Но если у кого-то было мало RAW per CPU, то наоборот. Но ИМХО, мне такой подход больше нравится. Стоимость схд должена определяться хранением, а не количеством хостов, к которым оно подключено (я сознательно оставляю за скобками сценарии с HCI Mesh/vSAN MAX).
3.) vSAN можно купить только для VVF (и там практически всегда надо платить сразу за TiB), или для VCF (но там уже входит 1 TiB на ядро, что часто перекрывает потребности). Отсюда вылезает момент, что если нужно много емкости, то дешевле купить сразу VCF, чем VVF+vSAN. Хорошо это или плохо - it depends.
4.) Плоское Per-RAW TiB лицензирование, по сути, убило гибриды. Потому что Usable на All Flash заметно выше при том же RAW, чем на гибридах, за счет Erasure Coding, Compression, Deduplication (это все входило в Advanced). И хотя гибридные vSAN уже давно были крайне нишевой штукой (по моим ощущениям, заметно меньше четверти инсталляций), кейсы под них были. Поэтому остается только vSAN All Flash, да еще и ESA, потому что там EC и Сompression намного лучше работают.
Я не очень понимаю в чем я утрирую.
Я не обсуждаю дешево/дорого и удобно/неудобно. Кому-то дешево/удобно, и они покупают. Кому-то нет, и они не покупают. Тут у всех индивидуально.
Я говорю только то, использование образов MacOS для VMware, которые запускаются на НЕ-Apple железе нелегально: " The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so."
Поэтому при условии, что мы остаемся в правовом поле, нужно покупать Apple железо. Какое и как - дело лично каждого. И VMware никак не поможет в данном случае. Потому что multi-tenancy тоже нельзя: "only one (1) Device may remotely connect at any one time, whether directly or indirectly, to control the graphical desktop session of the Apple Software that is running and being displayed on the Home Mac;"
MacOS можно запускать только на железе Apple согласно их EULA. Вы, конечно, можете сказать, что пофиг и кто проверит, но если оставаться в легальном поле (потому что так мы можем дойти и до того, что еще дешевле будет MacMini украсть со склада), то для тестирования/разработки софта под MacOS/iOS нужно железо от Apple.
Вертикальное масштабирование — это здорово, но имеет несколько существенных недостатков в реальной жизни. 1.) Вертикально от масштабировать вы можете только диски (вариант выкинуть процессоры и заменить их на новые я не рассматриваю, ибо в реальности так никто не делает). А это значит, что если у вас кончился Compute, то хочешь не хочешь добавляй узлы. 2.) Это приводит к зоопарку, т.к. у вас получаются разные узлы на разных кластерах (ведь вам нужно разное отношение Storage/Compute под разные нагрузки). На больших объемах это сложно/дорого, и с точки зрения закупок, и с точки зрения эксплуатации. Даже в вашей документации: "Одно из выгодных для промышленной эксплуатации преимуществ гиперконвергенции – идентичность элементов инфраструктуры, а именно: узлов кластера. Это позволяет иметь "под рукой" ZIP-пакет в виде шасси, которым можно оперативно заменить вышедший из строя узел кластера vStack." 3.) На больших кластерах вертикальное масштабирование дает большой шаг роста, ибо диски вам стоит добавлять более-менее равномерно во все хосты в кластере. Плюс, если у вас два тира (SSD и HDD), то вам нужно наращивать не только Capacity, но и Cache, чтобы не уменьшать Cache/Capacity ratio 4.) Для действительно крупных заказчиков закупать отдельно диски просто организационно бывает сложно, ибо играется рамочный контракт на узлы целиком.
А про Storage Only узлы - можно ссылки на материалы по этому поводу? В документации, почему-то, ничего не могу найти.
Ну странно было (нет) не отметить главную проблему HCI архитектуры - невозможность независимого масштабирования (или ограниченную возможность) вычислительных ресурсов и ресурсов хранения? Т.е. если у вас кончилось место, но с Compute все хорошо, то все равно надо добавлять целиком сервера (т.е. и Compute, и Storage). И наоборот. А это не эффективно.
И разные производители, по-разному эту проблему решают. Отсюда и Compute-only nodes, и Storage-nodes, и шаринг емкости между кластерами, и вообще растаскивание компонентов обратно (aka dHCI, хотя ИМХО это ужасный термин).
Для конфигурации самой гостевой ОС есть еще SaltMinion, который интегрирован с vmtools - Enable Salt Minion Using VMware Tools
А для передачи данных/конфигураций между ОС и платформой можно еще посмотреть на DataSets - vSphere DataSets | VMware
Ну как минимум доступна подписка на 5 лет и у очень многих заказчиков она проходит, как CAPEX, а не OPEX.
Что к этому ведет, стало очевидно, когда ввели ограничение сверху на число ядер на сокет. Update to VMware’s per-CPU Pricing Model Плюс подписочные варианты (которые существовали и до Broadcom) были тоже per-Core. Да и стимул понятен (хотя и неприятно, безусловно) - число ядер растет намного более быстрыми темпами, чем рост нагрузок. И сейчас можно, например, взять и шесть 5-и летних двух сокетных серверов по 16 pCore, и упаковать в один сервер с двумя AMD EPYC™ 9654, что даст те же 196pCore, но два только сокета. И количество сокетов/лицензий схлопывается с 6 раз.
Не было анонсировано закрытие решений. Было анонсировано изменение лицензирования. Хотя KB, справедливости ради, действительно, была отвратительно написана и требовала вдумчивого вчитывания. Поэтому её убрали и заменили на VMware End Of Availability of Perpetual Licensing and SaaS Services - VMware Cloud Foundation (VCF) Blog (хотя я думаю, что и его еще доработают)
Было анонсировано не закрытие "програмных решений", а прекращение продаж старых лицензий. Старые лицензии больше не доступны к покупке, но в новых бандлах все эти продукты по-прежнему доступны.
Поддержка на всё купленное продолжает оказываться в полном объеме до тех пор, пока действует поддержка. После её окончания, поддержку купить будет больше нельзя и нужно будет покупать подписку (которая включает в себя поддержку + подписку).
У бессрочных лицензий (а в списке, в основном они, за некоторым исключением типа версий "+") нет срока лицензий. Ими можно пользоваться столько, сколько хотите, но поддерживаться они перестанут по окончанию срока купленной поддержки.
В сухом остатке:
Практически все продукты из списка, на текущий момент, живы и здоровы, с технической точки зрения, а изменилось только модель их лицензирования. VMware End Of Availability of Perpetual Licensing and SaaS Services - VMware Cloud Foundation (VCF) Blog
SaaS версии Aria/vRealize EoA/depricated. Теперь только онпрем. При этом SaaS версии продолжат поддерживаться до окончания подписки на них. Dramatic Simplification of VMware Aria as part of VMware Cloud Foundation - VMware Cloud Management
Вместо отдельных лицензий, всё теперь покупается двумя основными бандлами (VVF + VCF) + Addon на них. Плюс есть два бандла для SMB (Ess+ и vSphere Std). https://williamlam.com/2024/01/whats-in-the-new-vmware-vsphere-foundation-vvf-and-vmware-cloud-foundation-vcf-offers.html
Перпет больше не доступен - только подписка. VMware by Broadcom Dramatically Simplifies Offer Lineup and Licensing Model - VMware News and Stories
Больше нет лицензий per-socket - вместо этого per-core (для Addon могут быть свои метрики).
Текущие заказчики могут пользоваться бессрочными лицензиями сколько они захотят (на то они и бессрочные).
Поддержка на perpet будет до конца окончания контракта (условно те, кто в Октябре продлил/купил поддержку на 3 года, то она будет оказываться для них до Октября 2026). У кого она кончится - продлить ее на старые лицензии больше нельзя. Только переход на новую модель.
Нет конечно. Ниже себестоимости запускать никакого смысла нет. Но я писал не про себестоимость пуска, а себестоимость производства Falcon 9 (хотя я скептичен относительно озвученных абсолютных цен). Но если ракета стоит 60M и летает она 20 раз, то "себестоимость пуска" будет 3M. Да, я знаю, что там вторая ступень одноразовая, сверху топливо, обслуживание и многое другое, но и там будет сильно больше, но суть такая.
Внезапно, если спрос превышает предложение, то мы смело можем выкручить ценники вверх до тех пор, пока количество согласных запустить нагрузку по такой цене не станет строго равно числу доступных ракет. И при этом мы должны видеть резкое увеличение доли запусков коммерческих нагрузок (потому что сами себе мы ценники-то не увеличиваем).
И да, я понимаю, что и мое первое утверждение, и это является сильным упрощением, потому что есть огромное количество других не экономических факторов (от политики до желания левой пятки Маска и основных акционеров), но направление в целом мне видится все же корректным.