Вы очень точно описали не эластичный спрос по цене, когда изменение цены на 3 порядка приводит к изменению спроса "немного". Если спрос вообще не зависит от цены, то спрос абсолютно неэластичен. И такое, действительно, бывает редко.
Честно говоря, я не очень понял вашу мысль. Эластичный спрос означает, что уменьшение цены продукта на 30% приводит к увеличению спроса на него на 30+% (и наоборот). Неэластичный спрос означает, что уменьшение цены на 30% приводит к увеличению спроса на величину от 0 до 29%.
До запуска Starlink (и я думаю, что и сейчас) - предложения от SpaceX было вагон, т.к. они были готовы летать постоянно (я это утверждаю просто потому, что раз они это делают сейчас для Starlink, то могли делать и для других).
Дальше мы видим, что до 2023 Mass to Orbit без учета Starlink менялось слабо:
Ну и еще одно предположение: для многоразовой ракеты - чем больше она летает, тем ниже её себестоимость.
Тогда давайте себе представим, как в 2014-2015 умные дяди и тети садятся и думают, как им увеличить прибыль SpaceX. И тут есть два сценария:
Сценарий 1. Спрос - эластичный. Тогда наиболее выгодная стратегия - уменьшаем цену на запуск. В этом случае уменьшение цены на 10% увеличивает спрос, например, на 20%, т. е. у нас резко начинает расти число коммерческих запусков и несмотря на то, что они стали дешевле, мы в выигрыше. При этом у нас падает себестоимость запуска и позволяет еще сильнее снизить цену пуска. Таким образом, мы должны видеть, постоянное снижение стоимости запуска (до некого фундаментального предела для данной ракеты и достаточно низкого, ибо Маск говорил про стоимость производства Falcon9 порядка 60млн$, а пусков много) и увеличение числа пусков. Но мы этого не видим. Стоимость пуска не уменьшается, а остается примерно такой же - была ~60млн, а сейчас ~67млн.
Сценарий 2. Спрос - неэластичный. Тогда, если мы опустим цену на 10%, то спрос увеличится, например, на 5%. И мы потеряем больше, чем выиграем. Но это работает и в другую сторону - если мы увеличим цену на 10%, то отвалится всего 5% заказчиков, и мы в плюсе. Так что выигрышная стратегия - увеличивать цену путем снижения числа пусков. Но тут есть сразу 3 но:
1.) Вместе с уменьшением числа пусков будет расти себестоимость, а значит сокращаться прибыль.
2.) Есть конкуренты, которые не дадут сильно обнаглеть. И даже, если их ценники будут чуть выше, заказчики могут выбирать их по разным причинам (политика, логистика, сроки, etc). Плюс они смогут в теории еще больше снизить цену за счет объема.
3.) Инвесторы увидят снижение числа пусков и массы на орбиту. И расстроятся, так как им обещали килотонны в год.
Поэтому мы делаем следующее: оставляем ценники +- на месте (или даже чуть-чуть их увеличиваем, но не заметно, и чтобы было далеко до конкурентов), а число пусков наращиваем за счет внутреннего спроса и запусками на орбиту по себестоимости собственных спутников. Тогда у нас получается все отлично - себестоимость падает (а значит прибыль с коммерческих запусков растет даже при той же цене), мы зарабатываем на Starlink, инвесторы счастливы, так как видят рост пусков и грузов, тотальное доминирование на рынке по выведенной массе/пускам, а также потенциал от самого Starlink.
И то, что я вижу сейчас явно напоминает сценарий номер 2. Более того, мне крайне любопытно увидеть, а что будет после Starship. Ибо там проблема такая же, только в еще большем масштабе. И у меня есть сомнения, что только Starlink хватит, чтобы сделать Starship выгодным. Надо будет что-то придумывать еще и ИМХО именно отсюда растут ноги этих идей про перевозку людей на Starship вместо самолетов, кучу рейсов на Марс и т.д.
Ну как бы нет. Коммерческое лекарство от какой-нибудь редкой и смертельной болезни обычно обладает неэластичным спросом - изменение его цены практически не влияет на величину спроса. Более того, есть подозрения, что спрос на коммерческие космические запуски оказался тоже не особо эластичен. Поэтому и пришлось придумывать Starlink, чтобы внешний спрос заменить внутренним.
Цены, как обычно, это комплексный вопрос. Основная история, что perpet был per сокет (если ядер менее 32), а подписка сейчас per Core. Поэтому в зависимости от ядерности получается разное отношение. Плюс с учетом того, что раньше вариантов лицензий был вагон и маленькая тележка, а сейчас осталось только 4 варианта, то сравнивать напрямую сложно. Плюс цены разных регионах разные, скидки и т.д. Но некие примерные цифры (я не готов ручаться за их корректность) есть тут, а описание нового лицензирования тут
Подписочные/term based лицензии были давно и до этого. Это просто была опция в дополнение к бессрочным лицензиям. Теперь осталась только она. Т.е. вводите ключ и в нем прописано, что он действует, условно 3 года до 09-01-2027. После его окончания ESXi не падает, но не дает запускать новые ВМ. Плюс, емнип, там был grace period после окончания в который оно ругается, но полностью работает, но это нет точно.
Разумеется, бессрочные лицензии не отозвали. Но перестали продавать новые бессрочные лицензии, а также больше нельзя продлить поддержку на текущие, после её окончания.
«реализовано 95% функционала VMware vSphere Ent+ и vCenter» - А можно уточнить какие именно 95%? HotAdd нет (Потому что, как вы написали, требуется перезагрузка ВМ, то это, очевидно, не HotAdd), vMotion так себе (только внутри кластера, по вашим словам), по HA тоже все не очень (есть APD, PDL, Guest Heartbeat, Orchestrated HA?), DRS просто нет (равномерное распределение ВМ по хостам — это не DRS), Resource Pools (включая Child), Affinity-rules, NIOC, Host Profiles, vLCM, etc? По стораджу тоже не понятно - есть vNVMe, NVMeOF, UNMAP, Storage DRS, SIOC? Это только самая база и список можно продолжать долго. Ну вот хоть по этому списку (хотя он тоже очень так себе) - Vsphere Feature Comparison (vmware.com). И я не говорю уже про тонкости (типа vHT, NetFlow/PortMirroring, LoadBased Teaming, etc) и того, как оно работает. Просто на уровне наличия/отсутствия.
И я не к тому, что oVirt плохое и пользоваться им нельзя. Но заявления по 95% могут создать, мягко говоря, завышенные и ложные ожидания.
Простите, но странно говорить в 2023, что перезагрузка хоста виртуализации — это прерывание сервиса. vMotion был представлен в 2003. С тех пор (20 лет, как никак) это перестало быть проблемой. Мигрируете ВМ, перезагружаете хост. И со стороны пользователя не произошло ровным счетом ничего. И 100% резервирование тут не нужно. Достаточно n+1, который и так должен быть, потому что еще может внезапно умереть, а нагрузки надо на чем-то перезапустить.
Ну а насчет отсутствия критических патчей... За последние три года выявили, например, Log4j, OpenSSL (openssl.org/news/secadv/20221101.txt), несколько очередных уязвимостей в самих CPU. Этого мало? И это, не говоря, уже про отдельные модули в ОС, уязвимости в прошивках железа и прочего. Если смотреть на CVE database, то только за 2023 было опубликовано 8800 CVE со score >8. Понятно, что подавляющее большинство из них для конкретных решений, но сколько-то десятков (сотен?) из них применимо к широко популярным библиотекам и ОС, которая используется в Росплатформе.
И про закрытый контур управления - понятно, что это необходимый, но не достаточный шаг. Просто, потому что он не является абсолютно изолированным по определению. У вас есть пользователи, которые туда подключаются для управления, у вас есть информационные потоки из/в эти системы (система, которая стоит в закрытой комнате без какой-либо связи с внешним миром и только жужжит лампочками никому не нужна), наконец у вас есть риски bad-actors, риски физического проникновения и много чего еще. Поэтому это вопрос не "если меня ломанут/пошифруют/уведут данные", а "когда". И ИМХО, конечно, но установка обновлений и патчей безопасности является намного более эффективным способом защиты, чем создание невозможного в принципе абсолютно безопасного контура. Это относительно быстро, просто и бесплатно и при этом крайне эффективно.
vVols вы приплели сюда зря. Там оно работает принципиально иначе - там не подключаются руками отдельные LUN'ы или шары к хостам. Там в качестве Primary LUN/T10: Administrative Logic Unit выступает целиком вся СХД (точнее её Protocol Endpoint, но это не суть в данном случае), а LUN на СХД создается автоматически VASA Provider'ом при запросе vCenter'ом для каждого отдельного vVols (например, каждый vmdk каждой ВМ живет в своем собственном LUN) и адресуется через Secondary LUN ID/T10: Subsidiary Logical Unit.
А то, что вы видите в vCenter в качестве datastore - на стороне СХД является исключительно логической/программной сущностью, которая просто ограничивает создание новых vVols, если мы вышли за пределы выданной емкости. Поэтому, кстати, его и можно увеличивать/уменьшать на лету без каких-либо проблем - там нет файловой системы в виде VMFS снизу.
Производительность с точки зрения CPU и RAM везде будет +- одинаковая, если мы не говорим про сценарии с очень сильной переподпиской, NUMA и прочим (и я сомневаюсь, что это тот случай. Да и вообще стандартное правило в любом приличном обществе при выкладывании результатов тестов указывать стенд/настройки/сценарий, на котором они получены, чего я тут не наблюдаю). Просто, потому что это делается на уровне CPU, а виртуализации достаточно ничего не поломать (например, не перетащить часть ядер ВМ на другой NUMA узел).
Разница может (и будет) в тестах на вводе/выводе, что по сети, что по стораджу (кстати, а почему это не протестировали? Или просто не показали?). А вот насчет ограничений производительности по сети тут написаны... очень странные вещи. Еще 8 лет назад показывали 35Gb/s на одном vmxnet3 адаптере (или тут использовали e1000e? :) ) на 40Gb/s pNIC - https://blogs.vmware.com/performance/2015/04/network-improvements-vsphere-6-boost-performance-40g-nics.html А если надо, то можно снять и сильно больше (EDP, выделенные ядра под IO, Pull Mode, PVRDMA, DPU и кучу всего еще), но это надо настраивать дополнительно.
Основной момент, что это крайне вырожденный случай, когда надо такие уровни износостойкости и практически 100% Write-optimized нагрузки. В основном, это нужно, когда есть несколько тиров SSD (SLC/TLC Write Intensive + TLC/QLC Read Intensive) и один из них используется исключительно в качестве буфера на запись. Только вот выясняется, что даже при таком сценарии, обычно стандартных Mixed Used TLC SSD более чем достаточно, чтобы проработать 5+ лет под нормальными нагрузками. Поэтому Optane и помер - слишком мало сценариев, когда от него чувствуется настолько значительный выигрыш, чтобы платить заметно больше денег.
Не соглашусь. Вот как раз vSAN без поддержки обслуживать ИМХО намного проще, чем большинство классических enterprise СХД. Потому что есть доступ ко всем кишкам по умолчанию, нет лока на диски/прошивки/etc, не требуется специализированное железо для замены (aka контроллеры, BBU, etc.) + есть куча материалов и гайдов в открытом доступе по тому, как его строить, обслуживать и траблшутить.
А по-моему, вполне себе показательны. Хорошо видно, что преимущество достигается исключительно на чтении (желательно последовательном и большими блоками). На запись разницы нет. На мелко-блочном чтении получается порядка 30%, в лучшем случае. Что приводит к тому, что в реальной жизни и под реальной нагрузкой (смешанные блоки 4-64k, смешанное чтение/запись), преимущество по IOPS будет порядка 5-15%. Много кто тестировал и проверял.
Другой вопрос, что при включении RDMA может сильно уменьшается потребление CPU на обработку ввода/вывода, но оценить это "сильно" в % сложно, потому что зависит от конфигурации хоста, профиля нагрузки, реальной загруженности по IOPS (не пиковой/потенциальной) и т.д.
Вот вы пишите про совместимость vStack с оборудованием потребительского класса. Расскажите, пожалуйста, каким образом вы собираетесь обеспечивать защиту данных на потребительских SSD и HDD, где отсутствует Power Loss Protection на SSD и нет гарантированной возможности защиту данных в DRAM буфере на SATA HDD? Также каким образом решается задача обеспечения консистентной производительности дисковой подсистемы на потребительских SSD, где есть всякие SLC-буферы, производительность зависит от степени заполнения SSD, Garbage Collection часто ждет TRIM/UNMAP для очистки ячеек и т.д?
"Облака российских провайдеров на базе VMware vCloud Director не поддерживаются импортными DR-решениями. Дело в том, что провайдеры пусть и могут положить “под капот” своего облака одни и те же технологии, но реализуют собственный конечный продукт каждый по-своему – со всем на свете интеграцию не напишешь."
2.) Забыли про один из самых мощных (пусть и платный) инструмент для миграции от VMware - VMware HCX. Там вам и Bulk Migration, и миграция без простоя, и холодная, и смешанные типы. При этом с network extension, и wan оптимизация, и многое другое. Да, он в первую очередь для миграции между разными платформами VMware, но там же есть и OSAM для миграции с Bare-metal или других гипервизоров. https://docs.vmware.com/en/VMware-HCX/4.6/hcx-user-guide/GUID-8A31731C-AA28-4714-9C23-D9E924DBB666.html
1.) Вы в каждой статье пишите про "избыточность в коде" и "тяжеловесности" прочих решений, в частности, VMware. Скажите пожалуйста, каков размер кодовой базы и размер дистрибутива vStack?
2.) CPU Overhead — это прекрасно. Расскажите, пожалуйста, каким образом он измерялся и на каких задачах? Чисто вычислительные? Ввод-вывод? Смешанные нагрузки? За счет чего можно добиться снижения CPU overhead на чисто вычислительных задачах при условии работы на CPU c поддержкой VT-x и AMD-V (aka все процессоры на рынке, которые используются в серверах последние 10-15 лет)
3.) Каким образом связаны настройки памяти, ФС и наличие мониторинга с CPU Overhead? "оптимизация алгоритмов и использование более эффективных вариантов" - вариантов и алгоритмов чего?
P.S. Записывать в накладные расходы на виртуализацию ФОТ - ИМХО странно. Обычно это считается в рамках TCO платформы, но TCO != "накладные расходы".
Вы очень точно описали не эластичный спрос по цене, когда изменение цены на 3 порядка приводит к изменению спроса "немного". Если спрос вообще не зависит от цены, то спрос абсолютно неэластичен. И такое, действительно, бывает редко.
Честно говоря, я не очень понял вашу мысль. Эластичный спрос означает, что уменьшение цены продукта на 30% приводит к увеличению спроса на него на 30+% (и наоборот). Неэластичный спрос означает, что уменьшение цены на 30% приводит к увеличению спроса на величину от 0 до 29%.
До запуска Starlink (и я думаю, что и сейчас) - предложения от SpaceX было вагон, т.к. они были готовы летать постоянно (я это утверждаю просто потому, что раз они это делают сейчас для Starlink, то могли делать и для других).
Дальше мы видим, что до 2023 Mass to Orbit без учета Starlink менялось слабо:
А вот с учетом рост огромный:
Ну и еще одно предположение: для многоразовой ракеты - чем больше она летает, тем ниже её себестоимость.
Тогда давайте себе представим, как в 2014-2015 умные дяди и тети садятся и думают, как им увеличить прибыль SpaceX. И тут есть два сценария:
Сценарий 1. Спрос - эластичный. Тогда наиболее выгодная стратегия - уменьшаем цену на запуск. В этом случае уменьшение цены на 10% увеличивает спрос, например, на 20%, т. е. у нас резко начинает расти число коммерческих запусков и несмотря на то, что они стали дешевле, мы в выигрыше. При этом у нас падает себестоимость запуска и позволяет еще сильнее снизить цену пуска. Таким образом, мы должны видеть, постоянное снижение стоимости запуска (до некого фундаментального предела для данной ракеты и достаточно низкого, ибо Маск говорил про стоимость производства Falcon9 порядка 60млн$, а пусков много) и увеличение числа пусков. Но мы этого не видим. Стоимость пуска не уменьшается, а остается примерно такой же - была ~60млн, а сейчас ~67млн.
Сценарий 2. Спрос - неэластичный. Тогда, если мы опустим цену на 10%, то спрос увеличится, например, на 5%. И мы потеряем больше, чем выиграем. Но это работает и в другую сторону - если мы увеличим цену на 10%, то отвалится всего 5% заказчиков, и мы в плюсе. Так что выигрышная стратегия - увеличивать цену путем снижения числа пусков. Но тут есть сразу 3 но:
1.) Вместе с уменьшением числа пусков будет расти себестоимость, а значит сокращаться прибыль.
2.) Есть конкуренты, которые не дадут сильно обнаглеть. И даже, если их ценники будут чуть выше, заказчики могут выбирать их по разным причинам (политика, логистика, сроки, etc). Плюс они смогут в теории еще больше снизить цену за счет объема.
3.) Инвесторы увидят снижение числа пусков и массы на орбиту. И расстроятся, так как им обещали килотонны в год.
Поэтому мы делаем следующее: оставляем ценники +- на месте (или даже чуть-чуть их увеличиваем, но не заметно, и чтобы было далеко до конкурентов), а число пусков наращиваем за счет внутреннего спроса и запусками на орбиту по себестоимости собственных спутников. Тогда у нас получается все отлично - себестоимость падает (а значит прибыль с коммерческих запусков растет даже при той же цене), мы зарабатываем на Starlink, инвесторы счастливы, так как видят рост пусков и грузов, тотальное доминирование на рынке по выведенной массе/пускам, а также потенциал от самого Starlink.
И то, что я вижу сейчас явно напоминает сценарий номер 2. Более того, мне крайне любопытно увидеть, а что будет после Starship. Ибо там проблема такая же, только в еще большем масштабе. И у меня есть сомнения, что только Starlink хватит, чтобы сделать Starship выгодным. Надо будет что-то придумывать еще и ИМХО именно отсюда растут ноги этих идей про перевозку людей на Starship вместо самолетов, кучу рейсов на Марс и т.д.
Там отвратительно (ИМХО) написанная KB. Но ее суть не в том, что какие-то продукты исчезли и больше не доступны (все продукты из списка там живы на текущий момент), а том, что их больше нельзя лицензировать/купить отдельно, хотя они входят в новые бандлы. Берите только по новым подписочным лицензиям. William Lam прекрасно разобрал новую схему тут - https://williamlam.com/2024/01/whats-in-the-new-vmware-vsphere-foundation-vvf-and-vmware-cloud-foundation-vcf-offers.html
Ну как бы нет. Коммерческое лекарство от какой-нибудь редкой и смертельной болезни обычно обладает неэластичным спросом - изменение его цены практически не влияет на величину спроса. Более того, есть подозрения, что спрос на коммерческие космические запуски оказался тоже не особо эластичен. Поэтому и пришлось придумывать Starlink, чтобы внешний спрос заменить внутренним.
Цены, как обычно, это комплексный вопрос. Основная история, что perpet был per сокет (если ядер менее 32), а подписка сейчас per Core. Поэтому в зависимости от ядерности получается разное отношение. Плюс с учетом того, что раньше вариантов лицензий был вагон и маленькая тележка, а сейчас осталось только 4 варианта, то сравнивать напрямую сложно. Плюс цены разных регионах разные, скидки и т.д. Но некие примерные цифры (я не готов ручаться за их корректность) есть тут, а описание нового лицензирования тут
Подписочные/term based лицензии были давно и до этого. Это просто была опция в дополнение к бессрочным лицензиям. Теперь осталась только она. Т.е. вводите ключ и в нем прописано, что он действует, условно 3 года до 09-01-2027. После его окончания ESXi не падает, но не дает запускать новые ВМ. Плюс, емнип, там был grace period после окончания в который оно ругается, но полностью работает, но это нет точно.
Разумеется, бессрочные лицензии не отозвали. Но перестали продавать новые бессрочные лицензии, а также больше нельзя продлить поддержку на текущие, после её окончания.
«реализовано 95% функционала VMware vSphere Ent+ и vCenter» - А можно уточнить какие именно 95%? HotAdd нет (Потому что, как вы написали, требуется перезагрузка ВМ, то это, очевидно, не HotAdd), vMotion так себе (только внутри кластера, по вашим словам), по HA тоже все не очень (есть APD, PDL, Guest Heartbeat, Orchestrated HA?), DRS просто нет (равномерное распределение ВМ по хостам — это не DRS), Resource Pools (включая Child), Affinity-rules, NIOC, Host Profiles, vLCM, etc? По стораджу тоже не понятно - есть vNVMe, NVMeOF, UNMAP, Storage DRS, SIOC? Это только самая база и список можно продолжать долго. Ну вот хоть по этому списку (хотя он тоже очень так себе) - Vsphere Feature Comparison (vmware.com). И я не говорю уже про тонкости (типа vHT, NetFlow/PortMirroring, LoadBased Teaming, etc) и того, как оно работает. Просто на уровне наличия/отсутствия.
И я не к тому, что oVirt плохое и пользоваться им нельзя. Но заявления по 95% могут создать, мягко говоря, завышенные и ложные ожидания.
Простите, но странно говорить в 2023, что перезагрузка хоста виртуализации — это прерывание сервиса. vMotion был представлен в 2003. С тех пор (20 лет, как никак) это перестало быть проблемой. Мигрируете ВМ, перезагружаете хост. И со стороны пользователя не произошло ровным счетом ничего. И 100% резервирование тут не нужно. Достаточно n+1, который и так должен быть, потому что еще может внезапно умереть, а нагрузки надо на чем-то перезапустить.
Ну а насчет отсутствия критических патчей... За последние три года выявили, например, Log4j, OpenSSL (openssl.org/news/secadv/20221101.txt), несколько очередных уязвимостей в самих CPU. Этого мало? И это, не говоря, уже про отдельные модули в ОС, уязвимости в прошивках железа и прочего. Если смотреть на CVE database, то только за 2023 было опубликовано 8800 CVE со score >8. Понятно, что подавляющее большинство из них для конкретных решений, но сколько-то десятков (сотен?) из них применимо к широко популярным библиотекам и ОС, которая используется в Росплатформе.
И про закрытый контур управления - понятно, что это необходимый, но не достаточный шаг. Просто, потому что он не является абсолютно изолированным по определению. У вас есть пользователи, которые туда подключаются для управления, у вас есть информационные потоки из/в эти системы (система, которая стоит в закрытой комнате без какой-либо связи с внешним миром и только жужжит лампочками никому не нужна), наконец у вас есть риски bad-actors, риски физического проникновения и много чего еще. Поэтому это вопрос не "если меня ломанут/пошифруют/уведут данные", а "когда". И ИМХО, конечно, но установка обновлений и патчей безопасности является намного более эффективным способом защиты, чем создание невозможного в принципе абсолютно безопасного контура. Это относительно быстро, просто и бесплатно и при этом крайне эффективно.
Да и Dell vWorkspace.. Закрытый в еще 2017 году. https://www.dell.com/community/en/conversations/vworkspace/will-vworkspace-863-be-the-last-version/647f7333f4ccf8a8de0f8019
vVols вы приплели сюда зря. Там оно работает принципиально иначе - там не подключаются руками отдельные LUN'ы или шары к хостам. Там в качестве Primary LUN/T10: Administrative Logic Unit выступает целиком вся СХД (точнее её Protocol Endpoint, но это не суть в данном случае), а LUN на СХД создается автоматически VASA Provider'ом при запросе vCenter'ом для каждого отдельного vVols (например, каждый vmdk каждой ВМ живет в своем собственном LUN) и адресуется через Secondary LUN ID/T10: Subsidiary Logical Unit.
А то, что вы видите в vCenter в качестве datastore - на стороне СХД является исключительно логической/программной сущностью, которая просто ограничивает создание новых vVols, если мы вышли за пределы выданной емкости. Поэтому, кстати, его и можно увеличивать/уменьшать на лету без каких-либо проблем - там нет файловой системы в виде VMFS снизу.
Если кому-то интересно получить чуть больше деталей, то они есть тут vVols Getting Started Guide | VMware + vVols FAQ | VMware + Virtual Volumes: VVol Bindings Explained – Cody Hosterman
Производительность с точки зрения CPU и RAM везде будет +- одинаковая, если мы не говорим про сценарии с очень сильной переподпиской, NUMA и прочим (и я сомневаюсь, что это тот случай. Да и вообще стандартное правило в любом приличном обществе при выкладывании результатов тестов указывать стенд/настройки/сценарий, на котором они получены, чего я тут не наблюдаю). Просто, потому что это делается на уровне CPU, а виртуализации достаточно ничего не поломать (например, не перетащить часть ядер ВМ на другой NUMA узел).
Разница может (и будет) в тестах на вводе/выводе, что по сети, что по стораджу (кстати, а почему это не протестировали? Или просто не показали?). А вот насчет ограничений производительности по сети тут написаны... очень странные вещи. Еще 8 лет назад показывали 35Gb/s на одном vmxnet3 адаптере (или тут использовали e1000e? :) ) на 40Gb/s pNIC - https://blogs.vmware.com/performance/2015/04/network-improvements-vsphere-6-boost-performance-40g-nics.html А если надо, то можно снять и сильно больше (EDP, выделенные ядра под IO, Pull Mode, PVRDMA, DPU и кучу всего еще), но это надо настраивать дополнительно.
Существуют. Но дорого. D7-P5810 (solidigm.com) FL6 Series NVMe™ SSD 2.5-inch (U.3) | KIOXIA - Europe (English) Micron XTR NVMe SSD | Data Centers | Micron Technology
Основной момент, что это крайне вырожденный случай, когда надо такие уровни износостойкости и практически 100% Write-optimized нагрузки. В основном, это нужно, когда есть несколько тиров SSD (SLC/TLC Write Intensive + TLC/QLC Read Intensive) и один из них используется исключительно в качестве буфера на запись. Только вот выясняется, что даже при таком сценарии, обычно стандартных Mixed Used TLC SSD более чем достаточно, чтобы проработать 5+ лет под нормальными нагрузками. Поэтому Optane и помер - слишком мало сценариев, когда от него чувствуется настолько значительный выигрыш, чтобы платить заметно больше денег.
Не соглашусь. Вот как раз vSAN без поддержки обслуживать ИМХО намного проще, чем большинство классических enterprise СХД. Потому что есть доступ ко всем кишкам по умолчанию, нет лока на диски/прошивки/etc, не требуется специализированное железо для замены (aka контроллеры, BBU, etc.) + есть куча материалов и гайдов в открытом доступе по тому, как его строить, обслуживать и траблшутить.
А по-моему, вполне себе показательны. Хорошо видно, что преимущество достигается исключительно на чтении (желательно последовательном и большими блоками). На запись разницы нет. На мелко-блочном чтении получается порядка 30%, в лучшем случае. Что приводит к тому, что в реальной жизни и под реальной нагрузкой (смешанные блоки 4-64k, смешанное чтение/запись), преимущество по IOPS будет порядка 5-15%. Много кто тестировал и проверял.
Другой вопрос, что при включении RDMA может сильно уменьшается потребление CPU на обработку ввода/вывода, но оценить это "сильно" в % сложно, потому что зависит от конфигурации хоста, профиля нагрузки, реальной загруженности по IOPS (не пиковой/потенциальной) и т.д.
Я просто оставлю это тут RDG for VMware vSAN ESA over NVIDIA RoCE on VMware vSphere 8.0 Тут и как конфигурировать, и результаты тестов (советую смотреть не на финальные несколько графиков с лучшими сценариями, а на полные результаты)
Вот вы пишите про совместимость vStack с оборудованием потребительского класса. Расскажите, пожалуйста, каким образом вы собираетесь обеспечивать защиту данных на потребительских SSD и HDD, где отсутствует Power Loss Protection на SSD и нет гарантированной возможности защиту данных в DRAM буфере на SATA HDD? Также каким образом решается задача обеспечения консистентной производительности дисковой подсистемы на потребительских SSD, где есть всякие SLC-буферы, производительность зависит от степени заполнения SSD, Garbage Collection часто ждет TRIM/UNMAP для очистки ячеек и т.д?
"Облака российских провайдеров на базе VMware vCloud Director не поддерживаются импортными DR-решениями. Дело в том, что провайдеры пусть и могут положить “под капот” своего облака одни и те же технологии, но реализуют собственный конечный продукт каждый по-своему – со всем на свете интеграцию не напишешь."
Хм.. А тот же VMware Cloud Director Availability? На базе которого есть DRaaS у ряда российских сервис провайдеров?
1.) Вышел в бета VMware Converter 6.4, где появилась миграция с EC2 https://blogs.vmware.com/code/2023/04/19/vcenter-converter-6-4-beta-is-available/
2.) Забыли про один из самых мощных (пусть и платный) инструмент для миграции от VMware - VMware HCX. Там вам и Bulk Migration, и миграция без простоя, и холодная, и смешанные типы. При этом с network extension, и wan оптимизация, и многое другое. Да, он в первую очередь для миграции между разными платформами VMware, но там же есть и OSAM для миграции с Bare-metal или других гипервизоров. https://docs.vmware.com/en/VMware-HCX/4.6/hcx-user-guide/GUID-8A31731C-AA28-4714-9C23-D9E924DBB666.html
1.) Вы в каждой статье пишите про "избыточность в коде" и "тяжеловесности" прочих решений, в частности, VMware. Скажите пожалуйста, каков размер кодовой базы и размер дистрибутива vStack?
2.) CPU Overhead — это прекрасно. Расскажите, пожалуйста, каким образом он измерялся и на каких задачах? Чисто вычислительные? Ввод-вывод? Смешанные нагрузки? За счет чего можно добиться снижения CPU overhead на чисто вычислительных задачах при условии работы на CPU c поддержкой VT-x и AMD-V (aka все процессоры на рынке, которые используются в серверах последние 10-15 лет)
3.) Каким образом связаны настройки памяти, ФС и наличие мониторинга с CPU Overhead? "оптимизация алгоритмов и использование более эффективных вариантов" - вариантов и алгоритмов чего?
P.S. Записывать в накладные расходы на виртуализацию ФОТ - ИМХО странно. Обычно это считается в рамках TCO платформы, но TCO != "накладные расходы".