В стремительно меняющемся ИТ-ландшафте современности организации сталкиваются с совокупностью тенденций, которые меняют их подход к инфраструктуре — особенно к хранилищам данных. VMware Cloud Foundation (VCF) 9.0 предлагает серьёзные усовершенствования в VMware vSAN 9, соответствующие этим тенденциям и позволяющие предприятиям эффективно, производительно и надёжно удовлетворять современные потребности в хранении данных.
Тенденции отрасли и вызовы для клиентов
Предприятия сталкиваются с быстрыми изменениями как в датацентрах, так и на рынке, и всё чаще становится ясно, что существующие подходы не справляются с новыми задачами — цифровая трансформация становится необходимостью.
Первая ключевая тенденция — рост объёма данных. Данные давно называют «цифровым золотом», ведь они дают конкурентное преимущество за счёт аналитики, новых продуктов и услуг. В дата-центрах особенно быстро растёт объём неструктурированных данных, и общий рост объёма информации остаётся высоким. Стоимость хранения и удержания этих данных — одна из главных проблем. ИТ-отделам необходимы технологии повышения эффективности хранения, такие как дедупликация и сжатие, чтобы снизить совокупную стоимость владения (TCO). Также им нужны хранилища большой ёмкости с низкой задержкой, которые сочетают в себе экономичность и производительность, необходимую для приложений, работающих с этими данными.
Меняется и способ доступа приложений к данным. В организациях стремительно внедряются новые интерфейсы хранения, с помощью которых данные превращаются в источники дохода. Для удовлетворения этих требований предприятия обращаются к объектному хранилищу и высокопроизводительным файловым системам как к основным интерфейсам, особенно для AI-нагрузок. Такие задачи требуют также гибкого управления данными, чтобы обеспечить точность моделей AI и снизить задержки. Сегодня ИТ-отделы используют точечные решения под каждый тип данных, но им гораздо удобнее было бы иметь унифицированную платформу, обеспечивающую простое управление и быструю работу.
Инфраструктурная фрагментация и гибридное облако
Рост объёма данных и внедрение новых интерфейсов усугубляется фрагментацией инфраструктуры, вызванной активным переходом к гибридным облачным стратегиям. По недавнему исследованию компании Broadcom, 92% организаций используют смесь частных и публичных облаков. Это означает, что данные и рабочие нагрузки распределены между локальными датацентрами, периферийными (edge) точками и публичными облаками. В результате появляется множество уникальных архитектур на базе точечных решений, которые трудно масштабировать и поддерживать. ИТ-отделам нужен единый подход к хранению данных и операциям с ними во всех средах, чтобы снизить сложность.
Какие рабочие нагрузки вызывают этот рост данных и требуют новых интерфейсов?
AI-задачи предъявляют совершенно новые требования к инфраструктуре хранения. Как прогнозирующий AI (уже широко используемый), так и генеративный AI (стремительно набирающий популярность) зависят от быстрого и надёжного доступа к огромным объёмам данных. Даже такие специфические рабочие нагрузки, как RAG (Retrieval Augmented Generation), нуждаются в хранилищах с высокой производительностью и низкой задержкой — гораздо выше, чем у традиционных систем на жёстких дисках, где сейчас хранятся многие AI-данные. Более того, AI-среды требуют прямого, высокоскоростного доступа к хранилищам с GPU, в обход узких мест, связанных с CPU, чтобы обрабатывать данные с минимальной задержкой.
Контейнеры, хранилище и скорость разработки
Хотя многие приложения по-прежнему работают в виртуальных машинах, использование контейнеров растёт, особенно в AI-сценариях. Контейнеры по своей природе эфемерны, но используемое ими хранилище должно быть постоянным и отделённым от жизненного цикла контейнера. По мере роста количества контейнеров, управление хранилищем должно происходить на более детализированном уровне — часто на уровне отдельного тома — и быть тесно интегрировано с системой оркестрации контейнеров для быстрой разработки.
В итоге ИТ-отделам необходимы программно-определяемые хранилища, которые масштабируются так же быстро, как контейнеры, и которые можно управлять теми же инструментами и с той же точностью, что и виртуальными машинами. Плюс, они должны предоставлять разработчикам быстрый доступ к инфраструктуре через привычные им инструменты, чтобы ускорить вывод продуктов на рынок.
Устойчивость к киберугрозам
Наконец, киберустойчивость остаётся в приоритете. Программы-вымогатели (ransomware) по-прежнему представляют серьёзную угрозу: в 2023 году две трети организаций подверглись атакам, и более 75% таких случаев сопровождались шифрованием данных. Кибербезопасность регулярно занимает первые места среди главных проблем CIO.
Стратегия хранения данных VMware и современные решения
Видение VMware в области хранения данных в рамках VMware Cloud Foundation заключается в предоставлении полностью интегрированных, унифицированных возможностей хранения в составе программно-определяемого частного облака, охватывающего локальные, периферийные (edge), публичные и суверенные облачные среды. Cтратегия VMware направлена на создание единой, универсальной платформы хранения, поддерживающей как первичные, так и вторичные сценарии использования для различных типов данных и рабочих нагрузок. Эта платформа создаётся с целью упростить операции, повысить безопасность, сократить затраты и ускорить инновации.
Снижение стоимости хранения
VMware уделяет особое внимание снижению затрат, что особенно важно для клиентов. VMware Cloud Foundation включает 1 TiB хранилища vSAN на одно ядро в своей лицензионной модели, что позволило клиентам сократить среднюю стоимость хранения на 30%, а в отдельных случаях — снизить TCO более чем на 40% по сравнению с традиционными массивами с контроллерами.
Дополнительно, VMware снижает расходы за счёт поддержки сертифицированных стандартных серверов: более 500 конфигураций vSAN ReadyNode от 15 OEM-производителей. Это в среднем снижает стоимость хранения на 46% за терабайт. Масштабируемая гиперконвергентная архитектура устраняет неиспользуемую ёмкость, типичную для масштабируемых систем (scale-up), а серверный подход позволяет существенно сократить затраты на поддержку и управление. В итоге заказчики получают высокопроизводительное, устойчивое хранилище для критически важных задач — без высокой стоимости устаревших решений.
С выпуском VCF 9.0 VMware представила глобальную дедупликацию на программном уровне, которая позволяет дополнительно сократить объём хранимых данных вплоть до 8 раз, что особенно актуально при росте объёма информации.
Новая дедупликация vSAN:
Имеет минимальную нагрузку на CPU
Работает в фоновом режиме, когда системные ресурсы не загружены
Охватывает все данные в кластере, а не только данные за одним контроллером, как в традиционных системах
Масштабируется вместе с кластером, что даёт более высокую эффективность
В будущем VMware планирует дополнительно снижать стоимость хранения за счёт более плотных носителей, соответствующих жёстким требованиям по производительности и задержкам. Совместно с гибкой лицензионной моделью это откроет новые сценарии использования vSAN, включая вторичное хранилище для резервного копирования.
Хранилище с низкой задержкой для AI-нагрузок
AI-задачи предъявляют повышенные требования к инфраструктуре, и vSAN соответствует этим требованиям благодаря архитектуре Express Storage Architecture (ESA) нового поколения. На сегодняшний день vSAN ESA обеспечивает:
До 300 000 IOPS на узел.
Постоянную задержку менее 1 мс, даже при пиковых нагрузках.
Линейный рост производительности и ёмкости по мере масштабирования кластера — в отличие от традиционного хранилища, где масштабируется только ёмкость.
Гибкость при сбоях: недавние тесты показали на 60% меньшую задержку в аварийных сценариях по сравнению с классическими системами.
В текущем релизе VMware повысила производительность кластеров vSAN до 25% за счёт разделения трафика — теперь можно использовать отдельные сети для вычислений и хранилища. Это не только освобождает пропускную способность для хранилища, но и позволяет использовать существующие инвестиции. Клиенты могут выбрать более дешёвую, низкоскоростную сеть для вычислений, не тратясь на дорогостоящую высокоскоростную сеть для совместного использования вычислительных и хранилищных задач.
В будущем VMware планирует расширить хранилище vSAN с низкими задержками на вторичные сценарии, включая предиктивные и генеративные AI-нагрузки. vSAN будет обладать оптимальным сочетанием высокой ёмкости, низкой задержки и масштабируемости, чтобы точно соответствовать требованиям этих задач.
Программно-определяемое хранилище для любых рабочих нагрузок
VMware vSAN предлагает гибкую, программно-определяемую, масштабируемую архитектуру, позволяющую организациям оптимизировать и расширять объём хранилища по мере необходимости. Клиенты могут масштабироваться линейно или раздельно, начиная с малого и доходя до петабайтового уровня.
С помощью драйвера CSI vSAN поддерживает постоянные тома для контейнерных нагрузок, позволяя разработчикам работать с инфраструктурой VMware через привычные инструменты. Администраторы получают гранулированный контроль и видимость томов контейнеров, воспринимая их как полноправные элементы инфраструктуры. Поскольку vSAN полностью интегрирован с CSI-драйвером, контейнеры могут использовать управление на основе политик хранения, обеспечивая быстрое и масштабируемое развертывание.
Автоматизация VCF
VCF Automation (VCF-A) в VCF 9.0 предоставляет простой способ предоставления томов для различных арендаторов, использующих хранилище как для ВМ, так и для постоянных томов в Kubernetes-среде VMware (VKS).
В будущем VMware планирует развивать многопользовательские сценарии и инфраструктуру как услугу (IaaS), чтобы дать разработчикам быстрый доступ к ресурсам при сохранении корпоративного контроля.
Единая модель управления хранилищем для локальных, периферийных и облачных сред
Для обеспечения последовательности в операциях VMware Cloud Foundation предлагает унифицированную программно-определяемую инфраструктуру во всех средах VMware — в датацентрах, на периферии и в облаках.
VMware сотрудничает с широчайшим кругом облачных партнёров (все крупные гиперскейлеры и сотни региональных провайдеров), чтобы обеспечить единообразный пользовательский опыт, включая управление хранилищем, во всех типах облаков.
VCF 9.0 включает важные инновации в управлении хранилищем:
Автоматическое развертывание, масштабирование и обновление инфраструктуры на базе vSAN
Единая консоль для всей VCF-инфраструктуры (vSAN, VMFS, NFS)
Уведомления о состоянии, рекомендации и пошаговое устранение проблем
Поддержка мультисайтовых сред для единого мониторинга.
В ближайшее время облачные партнёры внедрят vSAN ESA (Express Storage Architecture) в свои стеки VCF: VMware Cloud Foundation на AWS, Google Cloud VMware Engine и Azure VMware Solution добавят поддержку ESA.
В рамках этой стратегии технология vVols будет выведена из эксплуатации, начиная с VCF/VVF 9.0, и полностью отключена в будущих релизах. vVols не обеспечивают единый операционный подход между локальными, edge и облачными средами, так как не были внедрены большинством публичных и суверенных облачных партнёров.
Их распространённость остаётся низкой (единицы процентов), и они остаются нишевым решением. VMware по-прежнему будет поддерживать внешние хранилища через VMFS и NFS.
Безопасность и киберустойчивость для частного облака
Безопасность и устойчивость — основа vSAN, особенно важная для пользователей VCF. С выпуском vSAN 8.0 появилась новая система моментальных снимков (снапшотов), а в vSAN 8 Update 3 — встроенная защита данных, позволяющая администраторам легко защищать ВМ от случайных или вредоносных действий (например, удаления или атак программ-вымогателей).
Это реализуется через группы защиты, где можно задать, что защищать, как часто и как долго, с поддержкой неизменяемых снапшотов и шифрованием (FIPS 140-3) как для хранимых, так и передаваемых данных.
В VCF 9.0 добавлена репликация vSAN-to-vSAN, основанная на защите данных vSAN. Она позволяет удалённо реплицировать снапшоты на любое хранилище vSAN ESA — как гиперконвергентное, так и разнесённое.
Эта асинхронная репликация:
Дешевле и быстрее традиционной массивной репликации
Позволяет восстанавливать отдельные ВМ, а не целые LUN
Требует меньше места и меньше трафика
Значительно упрощает восстановление, переключение и возврат свободного места
Также репликация интегрирована с VMware Live Recovery (VLR) для восстановления после кибератак и аварий. VCF 9.0 поддерживает кибервосстановление в изолированную зону внутри локального VCF, что важно для соблюдения требований суверенитета и конфиденциальности данных.
Интеграция vSAN и VLR позволяет хранить длинную историю снапшотов, что критично при атаке с шифрованием, когда приходится откатываться назад до "чистых" копий. Управление и кибервосстановление, и аварийным восстановлением возможно через один VLR-апплаенс, с масштабированием восстановления с помощью кластеров vSAN.
В перспективе будет реализована функция Intelligent Threat Detection — AI/ML-алгоритмы для превентивной защиты, раннего обнаружения и анализа зашифрованных копий.
Унифицированное хранилище для всех типов данных
Клиенты давно хотят единую платформу хранения для всех задач, а не отдельные решения для блочного, файлового и объектного хранилища, что создаёт избыточную сложность. vSAN изначально предлагает блочное хранилище, а с 2019 года — встроенные файловые сервисы. VCF 9.0 расширяет их масштабируемость: теперь до 500 файловых ресурсов на кластер.
В будущем планируется добавление новых встроенных протоколов, ориентированных на высокую пропускную способность и низкую задержку, необходимых для AI-задач.
Взгляд в будущее
VMware vSAN — это интегрированное хранилище для частных облаков, на которое предприятия полагаются при работе с критически важными приложениями. Оно помогает сократить капитальные и операционные издержки, обеспечивая при этом производительность, масштаб и устойчивость, необходимые для современных нагрузок — от облачных приложений до AI-аналитики.
Благодаря единым операциям во всех средах (edge, core, облако) и ведущим в отрасли возможностям киберустойчивости, vSAN становится фундаментом современного частного облака.
VMware продолжает инвестировать в инновации, чтобы:
На протяжении многих лет цифровую трансформацию рассматривали как выбор между двумя крайностями: либо двигаться быстро в публичном облаке, либо сохранять контроль в локальной инфраструктуре — зачастую ценой потери гибкости, роста сложности и накопления технического долга. Сегодня VCF 9 снимает вопрос об этом компромиссе.
Современные рабочие нагрузки, особенно в сфере AI и обработки данных, диктуют новую реальность. Датасеты размером в петабайты невозможно просто так перемещать между регионами. Законодательные требования всё чаще обязывают размещать критически важные рабочие нагрузки в пределах национальных границ. А шок от реальных затрат в модели облака pay-as-you-go раздражают финансовые отделы по всей индустрии.
С выпуском VCF 9.0 компания VMware переосмыслила, каким может быть современное частное облако, объединив скорость и гибкость облачного опыта с производительностью, управляемостью и контролем затрат, которых требуют предприятия на собственных площадках.
Если всё сделано правильно, частное облако:
Обращается с серверами, хранилищами и сетями как с гибкими программными пулами ресурсов.
Предоставляет разработчикам API самообслуживания вместо очередей заявок.
Запускает виртуальные машины, контейнеры и новые AI-сервисы в одной среде и единым образом.
Масштабируется от центра до периферии и суверенных площадок без хаоса в политике управления.
Изначально включает в себя готовую к аудиту инфраструктуру безопасности и комплаенса, которая следует за рабочей нагрузкой независимо от места её запуска.
Впервые VMware приоткрыла завесу над VCF 9.0 на мероприятии VMware Explore в прошлом году. С тех пор компания провела ее испытания в реальных условиях, а также воркшопы по проектированию внедрений с множеством клиентов. Результат — релиз, ставший следующим крупным шагом на пути частного облака VMware. За 25 лет со времени изобретения гипервизора VMware Cloud Foundation опирается на долгую историю инноваций компании.
Фундаментальный сдвиг в VMware Cloud Foundation 9.0
Каждая основная версия Cloud Foundation продвигала автоматизацию на более высокий уровень. Версия 9.0 проводит чёткую черту: теперь операции и потребление частного облака — центральные компоненты продукта, работающие поверх ключевых инноваций, которые клиенты любят и на которые полагаются.
В основе этого релиза лежит унификация контекста. Независимо от того, устраняете ли вы предупреждение о нехватке ресурсов, подключаете нового арендатора или публикуете шаблон инфраструктуры для CI/CD, вы работаете с одной моделью политик, одним API-интерфейсом и единой системой управления жизненным циклом. Такая согласованность сокращает кривую обучения для операторов, устраняет проблемы разработчиков и — что особенно важно — снижает количество точек отказа, которые возникают при использовании разных инструментов и практик.
Один интерфейс для управления частным облаком — контроль состояния, установка обновлений и соблюдение требований соответствия по всей инфраструктуре из одной консоли, чтобы операционные решения основывались на едином источнике доверия.
Один интерфейс для облачного пользовательского опыта — разработчики взаимодействуют с единой конечной точкой для инфраструктуры как кода (IaC): через Terraform-провайдеры, REST API или VCF Automation Blueprints — без необходимости использовать дополнительные модули.
Запуск ВМ и контейнеров/K8s — запускайте виртуальные машины с производительностью, близкой к bare metal, и полностью управляемые кластеры Kubernetes в одной среде. Интеграция с Argo CD и встроенные CI/CD-механизмы позволяют доставлять контейнерный код из репозитория в продакшн без внешней обвязки.
Суверенность и безопасность как платформа — теги территориальной принадлежности данных, гео-политики и автоматическая ротация сертификатов теперь могут быть частью каждой спецификации кластера. Суверенность — это не просто модное слово, это возможность развертывания с рамками контроля, понимание того, где находятся данные, способность управлять ими, защищать их и обеспечивать постоянное соответствие каждого кластера суверенным требованиям.
Встроенный контроль затрат — механизмы перераспределения и демонстрации затрат, а также панели управления стоимостью и прогнозированием превращают потребление ресурсов в готовые к выставлению счета с цифрами для каждого арендатора или бизнес-единицы. Это не просто showback — это возможность для бизнес-лидеров планировать бюджеты, вводить ограничения, заключать договоры и масштабировать инфраструктуру, опираясь на прозрачную аналитику расходов, основанную на фактическом потреблении.
Эта эволюция VMware Cloud Foundation — не просто шаг вперёд, а переосмысление того, чем может быть современная платформа частного облака. VCF 9.0 представляет собой критически важные усовершенствования в области развертывания, управления, производительности и безопасности, созданные для реальных потребностей предприятий. Результат — платформа, которая не только упрощает управление инфраструктурой, но и создаёт пространство для инноваций, ускоренного исполнения задач и усиленного контроля.
Что нового в VCF 9.0: прорывы платформы с реальными результатами
VCF 9.0 предлагает базовые инновации, которые ускоряют достижение бизнес-ценности, упрощают повседневную эксплуатацию и помогают организациям уверенно масштабироваться. От новой консоли управления до усовершенствований в защите данных, автоматизации и оптимизации производительности — каждая функция нацелена на решение актуальных инфраструктурных задач и подготовку к будущим вызовам.
До этого момента мы говорили в основном о широких платформах изменениях, определяющих VCF 9.0. Теперь давайте копнём глубже. В следующих разделах мы рассмотрим два набора обновлений:
Инновации в ядре платформы, продолжающие развитие прочной базы VCF, включая повышение производительности, защиту данных и эффективность использования ресурсов.
Функции, ориентированные на результат, применяющие эти улучшения к повседневной работе — в рамках категорий: Современная инфраструктура, Унифицированный облачный опыт и Безопасность и отказоустойчивость.
Инновации в ядре
Общее количество новых функций в ядре значительно превышает то, что представлено на этой картинке. Но давайте на минуту остановимся на самых важных из них:
Расширенное многоуровневое использование памяти NVMe — движки высокочастотной торговли, аналитика в оперативной памяти и приложения, активно использующие JVM, сталкиваются с одной и той же проблемой: память DRAM дорогая и ограниченная. VCF 9.0 позволяет расширить пул памяти за счёт NVMe — используя быструю флеш-память как второй, более доступный по стоимости уровень. Вычислительно-интенсивные нагрузки сохраняют активные данные рядом с CPU, в то время как «холодные» страницы переносятся на NVMe, освобождая DRAM для тех задач, которым она действительно нужна. В результате вы можете запускать больше виртуальных машин или контейнеров на каждом узле без необходимости увеличивать бюджет на оборудование.
Глобальная дедупликация в vSAN — флеш-память остаётся ключевым драйвером стоимости в большинстве частных облаков. Теперь глобальная дедупликация на уровне блоков охватывает не только диски, но и целые кластеры, устраняя дубликаты данных один раз и распространяя экономию повсюду. Это позволяет защищать и обслуживать большие объёмы данных на том же объёме флеш-хранилища — и делать это без потери производительности, как это часто бывает с механизмами постобработки дедупликации.
Улучшенные пути передачи данных — задержки — это своеобразный «налог» на трафик east-west в рамках интенсивно использующих сеть рабочих нагрузок, особенно в пайплайнах AI и микросервисных сетках. Новые оптимизации ядра и возможность offload'а нагрузки на DPU значительно снижают этот налог. Пакеты дольше остаются на хосте, проходят меньше сетевых коммутаторов, что означает более быструю обработку запросов на инференс и стабильное время отклика API даже при росте плотности кластера. Во многих случаях это и есть разница между необходимостью обновлять spine-leaf архитектуру в этом году или можно отложить до следующего.
Но дело не только в новых функциях. Ядро VCF 9.0 идеально соответствует целям по повышению эффективности и снижению затрат. Вот лишь некоторые впечатляющие показатели, которые вы увидите при развёртывании инфраструктуры на VCF 9.0:
Возможности современной инфраструктуры
Поскольку VCF 9.0 ориентирован на централизованный опыт с единым интерфейсом, одним из первых изменений, которые вы заметите, станет новый способ взаимодействия с вашей средой.
VCF Operations — это ваша основная точка управления для повседневной диагностики, развертываний и устранения неполадок. Он интегрируется со всеми ключевыми возможностями платформы, но при этом делает такие задачи, как управление инфраструктурой — от обновлений и установки патчей до ротации сертификатов — предельно простыми.
Теперь кратко о некоторых функциях из категории современная инфраструктура:
VCF Installer — развёртывание всего стека на этапе Day-0 — за часы, а не недели.
Простое развертывание и управление арендаторами — создание рабочих доменов и шаблонов политик арендаторов с помощью пошагового мастера.
Производительное управление — установка патчей на тысячи хостов с предварительной предиктивной проверкой и управлением радиусом изменений по этапам. Управление сертификатами, контроль отклонений конфигурации, «живые» патчи, единый вход — всё в одном месте.
Улучшенные диагностические процедуры — корреляция логов с поддержкой AI помогает находить корневые причины до того, как инциденты перерастают в эскалации.
Учёт и распределение затрат — встроенные счётчики в реальном времени показывают, сколько ресурсов потребляет каждое бизнес-подразделение.
Унифицированный облачный опыт
Если модернизация инфраструктуры — это, в первую очередь, о «простой в работе», современной, производительной и масштабируемой среде, то унифицированный облачный опыт фокусируется на том, чтобы предоставить вам удобство публичного облака с надёжными ограничителями и комфортом частного развертывания. И снова — наша цель? — единое, сквозное управление автоматизацией через единую панель.
Унифицированный облачный опыт ориентирован как на администраторов облака, так и на разработчиков. Администраторы облака и ИТ-специалисты могут настраивать потребление инфраструктуры, а также выполнять повседневные задачи быстрее — например, конфигурацию новых виртуальных машин или создание одного pod в Kubernetes. Разработчики же получают удобный интерфейс, где можно быстро и с учётом всех зависимостей получить нужные сервисы. Это экономит время, снижает трение и помогает быстрее приносить бизнес-результаты.
Независимо от того, создаёте ли вы каталог самообслуживания для своих бизнес-заказчиков или просто работаете с инфраструктурой как кодом (IaC), в центре всего находится среда VCF Automation. Используйте шаблоны (blueprints) для создания, копирования и последовательного развертывания инфраструктурных ресурсов — и начните говорить с разработчиками на одном языке.
Возможности унифицированного облачного потребления:
VCF Automation Consumption Experience — единый открытый API (плюс поддержка Terraform и GitOps) обрабатывает все запросы на развёртывание, включая политики и метки стоимости — это дает скорость самообслуживания без потери управляемости.
Упрощённое облачное сетевое взаимодействие и потребление VPC — команды просто описывают VPC в коде, а маршрутизация, балансировка и безопасность настраиваются автоматически — без глубокого погружения в сетевой стек и без тикет-систем.
Готовые шаблоны для самообслуживания, IaC и управления кластерами VKS — преднастроенные blueprints для баз данных, AI-стеков и кластеров Kubernetes запускаются за считаные минуты; команды подставляют параметры, нажимают «развернуть» — и получают готовое к аудиту, согласованное окружение.
Безопасность и устойчивость
Безопасность — один из главных приоритетов для многих клиентов, особенно в условиях, когда угрозы становятся всё сложнее для отслеживания, блокировки и зачастую даже предотвращения. Цепочки обеспечения безопасности удлиняются — и их всё легче нарушить.
Именно поэтому сегодня как никогда важно иметь надёжную стратегию безопасности, которая начинается с базовой платформы и охватывает приложения, конечные точки и периферию.
Вот ключевые возможности в этой категории:
Панель управления операциями безопасности (Security Operations Dashboard) — единая консоль, которая совмещает в себе интерактивные карты атакующей поверхности и оценки соответствия требованиям в реальном времени. Это даёт SecOps-команде единое место для обнаружения уязвимостей, приоритизации патчей и проверки устранения проблем — ещё до того, как это сделает аудитор.
Соответствие конфигурации и мониторинг — постоянные сканирования, сравнивающие параметры времени выполнения с эталонами CIS, NIST и пользовательскими профилями. Отклонения выявляются сразу при появлении, и (где это допускается политиками) автоматически исправляются — так что аудит становится просто проверкой, а не пожарной тревогой.
Управление идентификацией и сертификатами — федерация идентификаций по всей платформе, автоматическая выдача и ротация сертификатов избавляют от ручного управления доверием, предотвращают аврал из-за просроченных сертификатов и обеспечивают бесшовный SSO для всех доменов рабочей нагрузки.
VMware Cloud Foundation 9.0 переосмысливает концепцию частного облака, предлагая более быстрое развертывание, встроенную автоматизацию и унифицированный облачный опыт в локальной среде. Безопасность и устойчивость интегрированы на всех уровнях, а ключевые инновации, такие как многоуровневая память NVMe и глобальная дедупликация, обеспечивают масштабную эффективность. Это фундамент, необходимый предприятиям для запуска современных рабочих нагрузок с контролем, высокой производительностью и полной прозрачностью затрат.
Этот обзор показывает, как VMware Cloud Foundation 9.0 продвигает платформу вперёд как на уровне «машинного отделения» (инфраструктуры), так и на уровне пользовательского опыта. Если вы хотите глубже погрузиться в детали, рекомендуем ознакомиться с этими дополнительными записями блогов VMware — в них подробно разобраны ключевые технологические направления, благодаря которым VCF остаётся флагманской платформой:
ROSA Virtualization — это отечественная платформа для управления виртуальной серверной инфраструктурой, разработанная АО «НТЦ ИТ РОСА». Она построена на базе открытого программного обеспечения (KVM, libvirt и др.) и предназначена для развёртывания отказоустойчивых, масштабируемых и защищённых виртуализованных сред.
Основные функции платформы:
Создание и управление виртуальными машинами
Настройка виртуальных сетей и хранилищ
Кластеры высокой доступности (HA)
Живая миграция ВМ между хостами
Резервное копирование и восстановление
Централизованное управление через веб-интерфейс
Поддержка требований по безопасности и соответствие ГОСТ
Сертификация для использования в госорганах
Главные изменения ROSA Virtualization 3.1 (релиз 27 мая 2025 года)
1. Отказ от CLI — весь функционал в GUI
Теперь все операции, включая настройку LDAP, шифрование дисков и управление пользователями, доступны через единый графический интерфейс. CLI используется только в самых экстренных случаях.
2. Поддержка Ceph
Включение интеграции с распределённым хранилищем Ceph позволило значительно повысить отказоустойчивость, масштабируемость и надёжность платформы.
3. Живая миграция ВМ и автозапуск
Поддерживается безостановочная миграция виртуальных машин между кластерами. Кроме того, при корректной перезагрузке хоста ВМ теперь автоматически запускаются после восстановления.
4. Сеть, визуализация и резервное копирование
Добавлена визуализация сетевой схемы, мастер настройки NFS, улучшен интерфейс бэкапов (включительно поддержка СУСВ через веб), а также адаптация событий под требования ГОСТ.
5. Интеграция с Loudplay и безопасность
Нововведения включают поддержку Loudplay (протокол для передачи консольных данных) и адаптацию событийной логики в соответствии с ГОСТ-стандартами.
6. Лицензирование и сертификация
Платформа доступна по одной из двух моделей лицензирования: либо по числу виртуальных машин, либо по числу хостов. В комплект входит год технической поддержки, включая версию сертифицированную ФСТЭК.
Почему это важно
Упрощение управления: привычные интерфейсы GUI значительно снижают порог входа для операторов и системных администраторов.
Надёжность и масштабируемость: интеграция с Ceph обеспечивает отказоустойчивую, распределённую архитектуру хранения.
Бесшовность и доступность: живая миграция и автозапуск ВМ минимизируют время простоя.
Безопасность и соответствие: ГОСТ-адаптация и сертификация ФСТЭК делают решение готовым к внедрению в государственных структурах и критически важной инфраструктуре.
Кому подойдёт ROSA Virtualization 3.1
Организациям госсектора и тем, кто выполняет требования по импортозамещению и ГОСТ-сертификации.
Компаниям, нуждающимся в простом и визуальном администрировании виртуальной инфраструктуры.
Телеком-операторам, дата-центрам и частным компаниям, которым важна отказоустойчивость и масштабируемость.
ROSA Virtualization 3.1 — зрелое отечественное решение для виртуализации, сочетающее:
Простоту и удобство графического интерфейса
Корпоративную надёжность благодаря Ceph и живой миграции
Соответствие государственным стандартам безопасности.
Платформа отлично подходит для предприятий и госструктур, где нужна надёжная, масштабируемая и управляемая виртуальная инфраструктура отечественного производства.
Недавно вышла новая версия VMware Tanzu Greenplum v7.5, которая уже доступна и предлагает повышенную производительность и меньшие затраты ресурсов при обработке сложных рабочих нагрузок, включая аналитические запросы, машинное обучение, потоковую загрузку данных в реальном времени и геопространственные запросы.
VMware Tanzu Greenplum — один из ключевых компонентов портфеля VMware Tanzu Data — представляет собой мощную платформу для хранилищ данных и аналитики, основанную на открытом исходном коде PostgreSQL. Она предназначена для масштабной агрегации и анализа больших объёмов данных. Tanzu Greenplum идеально подходит для организаций с высокой степенью регулирования и критически важными задачами, которым необходимо обрабатывать данные из множества источников и разных типов, чтобы ускорить принятие решений за счёт более эффективной агрегации, анализа и использования ключевых информационных активов.
Новые возможности
Оптимизатор GPORCA теперь охватывает более широкий спектр пользовательских запросов, а выполнение запросов в Tanzu Greenplum было улучшено для ускорения операций с таблицами, оптимизированными на добавление (Append Optimized, AO).
Обновлённые команды обслуживания ANALYZE и VACUUM снижают нагрузку на систему, обеспечивая более эффективное использование платформы. Greenplum Streaming Server (GPSS) теперь поддерживает масштабируемую архитектуру, способную обрабатывать большие объёмы данных из Apache Kafka и VMware Tanzu RabbitMQ. Компонент gpMLBot автоматизирует машинное обучение с тонкой настройкой гиперпараметров, сокращая время обучения моделей. Также включены расширения для геопространственного анализа: pgPointCloud, 3DCityDB, pgRouting, H3 Index и геокодирование TIGER, что открывает новые сценарии использования.
Ускоренное выполнение запросов
GPORCA в новой версии создаёт планы выполнения запросов с меньшим использованием памяти и более эффективным порядком объединения таблиц. Он поддерживает расширенные возможности SQL, такие как подзапросы по нескольким столбцам, ROW-выражения и оконные агрегаты с квалификатором DISTINCT, ускоряя выполнение сложных запросов. Движок выполнения запросов использует усовершенствования TupleTableSlot, включая частичную и отложенную десериализацию, что снижает нагрузку на CPU. В результате операции с AO-таблицами выполняются до двух раз быстрее, чем в предыдущих версиях.
Сжатые AO-таблицы теперь поддерживают чисто индексное сканирование, устраняя необходимость в дорогостоящих bitmap-сканах. Это обеспечивает значительный прирост производительности, включая ускоренные запросы ORDER BY с LIMIT, более быстрые pg_vector-запросы и более эффективные объединения и агрегирования, делая Tanzu Greenplum подходящей платформой для аналитических нагрузок.
Упрощённое обслуживание и эксплуатация
Процесс ANALYZE в v7.5 стал более эффективным: он пропускает неизменённые партиции и объединяет статистику, уменьшая использование ресурсов и время обслуживания. Это обеспечивает более актуальные статистические данные для планирования запросов без ущерба для производительности системы. Операции COPY, VACUUM и CREATE INDEX для широких таблиц теперь требуют меньше ресурсов CPU благодаря новым оптимизациям десериализации. Инструмент gprecoverseg теперь поддерживает выборочное восстановление сегментов, ускоряя исправление и балансировку. Новый инструмент управления кластером gpctl, основанный на архитектуре gRPC, упрощает и ускоряет развертывание кластера и настройку новых сред.
Масштабируемый приём данных с помощью GPSS
Greenplum Streaming Server теперь использует многозвенную архитектуру на базе Kubernetes. Он работает как распределённая система, способная масштабироваться в зависимости от объёма поступающих данных. GPSS эффективно обрабатывает большие потоки данных из таких источников, как Kafka и RabbitMQ, поддерживая аналитику в реальном времени с низкой задержкой.
Эффективное AutoML с gpMLBot
gpMLBot в версии 7.5 упрощает автоматическое машинное обучение (AutoML), включая подбор гиперпараметров, что помогает находить наилучшую модель и параметры для конкретных наборов данных. Благодаря интеграции с высокопроизводительным движком базы данных Tanzu Greenplum и встроенными библиотеками аналитики, gpMLBot сокращает время обучения и выбора модели, ускоряя работу дата-сайентистов с большими объемами данных или сложными признаковыми пространствами.
Продвинутый геопространственный анализ
Tanzu Greenplum 7.5 поддерживает масштабный геоанализ с помощью расширений pgPointCloud, 3DCityDB, pgRouting, H3 Index и TIGER. pgPointCloud обеспечивает эффективное хранение и запросы к облакам точек LiDAR, 3DCityDB управляет 3D-моделями городов на основе CityGML для планирования и визуализации, pgRouting реализует оптимизированную маршрутизацию в крупных сетях, H3 Index улучшает поиск и распределение данных для объединений, а TIGER геокодирует адреса в координаты, облегчая пространственные запросы.
Итоги
Tanzu Greenplum теперь предлагает более высокую производительность при работе с ресурсоёмкими задачами за счёт оптимизации выполнения запросов, более эффективного обслуживания, масштабируемой потоковой загрузки данных, упрощённого AutoML и мощных геопространственных возможностей. Эти улучшения снижают время обработки и потребление ресурсов, делая платформу надёжным выбором для аналитических и операционных задач.
В предыдущей статье мы рассмотрели, что производительность vSAN зависит не только от физической пропускной способности сети, соединяющей хосты vSAN, но и от архитектуры самого решения. При использовании vSAN ESA более высокоскоростные сети в сочетании с эффективным сетевым дизайном позволяют рабочим нагрузкам в полной мере использовать возможности современного серверного оборудования. Стремясь обеспечить наилучшие сетевые условия для вашей среды vSAN, вы, возможно, задаётесь вопросом: можно ли ещё как-то улучшить производительность vSAN за счёт сети? В этом посте мы обсудим использование vSAN поверх RDMA и разберёмся, подойдёт ли это решение вам и вашей инфраструктуре.
Обзор vSAN поверх RDMA
vSAN использует IP-сети на базе Ethernet для обмена данными между хостами. Ethernet-кадры (уровень 2) представляют собой логический транспортный слой, обеспечивающий TCP-соединение между хостами и передачу соответствующих данных. Полезная нагрузка vSAN размещается внутри этих пакетов так же, как и другие типы данных. На протяжении многих лет TCP поверх Ethernet обеспечивал исключительно надёжный и стабильный способ сетевого взаимодействия для широкого спектра типов трафика. Его надёжность не имеет аналогов — он может функционировать даже в условиях крайне неудачного проектирования сети и плохой связности.
Однако такая гибкость и надёжность имеют свою цену. Дополнительные уровни логики, используемые для подтверждения получения пакетов, повторной передачи потерянных данных и обработки нестабильных соединений, создают дополнительную нагрузку на ресурсы и увеличивают вариативность доставки пакетов по сравнению с протоколами без потерь, такими как Fibre Channel. Это может снижать пропускную способность и увеличивать задержки — особенно в плохо спроектированных сетях. В правильно организованных средах это влияние, как правило, незначительно.
Чтобы компенсировать особенности TCP-сетей на базе Ethernet, можно использовать vSAN поверх RDMA через конвергентный Ethernet (в частности, RoCE v2). Эта технология всё ещё использует Ethernet, но избавляется от части избыточной сложности TCP, переносит сетевые операции с CPU на аппаратный уровень и обеспечивает прямой доступ к памяти для процессов. Более простая сетевая модель высвобождает ресурсы CPU для гостевых рабочих нагрузок и снижает задержку при передаче данных. В случае с vSAN это улучшает не только абсолютную производительность, но и стабильность этой производительности.
RDMA можно включить в кластере vSAN через интерфейс vSphere Client, активировав соответствующую опцию в настройках кластера. Это предполагает, что вы уже выполнили все предварительные действия, необходимые для подготовки сетевых адаптеров хостов и коммутаторов к работе с RDMA. Обратитесь к документации производителей ваших NIC и коммутаторов для получения информации о необходимых шагах по активации RDMA.
Если в конфигурации RDMA возникает хотя бы одна проблема — например, один из хостов кластера теряет возможность связи по RDMA — весь кластер автоматически переключается обратно на TCP поверх Ethernet.
Рекомендация. Рассматривайте использование RDMA только в случае, если вы используете vSAN ESA. Хотя поддержка vSAN поверх RDMA появилась ещё в vSAN 7 U2, наибольшую пользу эта технология приносит в сочетании с высокой производительностью архитектуры ESA, начиная с vSAN 8 и выше.
Как указано в статье «Проектирование сети vSAN», использование RDMA с vSAN влечёт за собой дополнительные требования, ограничения и особенности. К ним относятся:
Коммутаторы должны быть совместимы с RDMA и настроены соответствующим образом (включая такие параметры, как DCB — Data Center Bridging и PFC — Priority Flow Control).
Размер кластера не должен превышать 32 хоста.
Поддерживаются только следующие политики объединения интерфейсов:
Route based on originating virtual port
Route based on source MAC hash
Использование LACP или IP Hash не поддерживается с RDMA.
Предпочтительно использовать отдельные порты сетевых адаптеров для RDMA, а не совмещать RDMA и TCP на одном uplink.
RDMA не совместим со следующими конфигурациями:
2-узловые кластеры (2-Node)
Растянутые кластеры (stretched clusters)
Совместное использование хранилища vSAN
Кластеры хранения vSAN (vSAN storage clusters)
В VCF 5.2 использование vSAN поверх RDMA не поддерживается. Эта возможность не интегрирована в процессы SDDC Manager, и не предусмотрено никаких способов настройки RDMA для кластеров vSAN. Любые попытки настроить RDMA через vCenter в рамках VCF 5.2 также не поддерживаются.
Прирост производительности при использовании vSAN поверх RDMA
При сравнении двух кластеров с одинаковым аппаратным обеспечением, vSAN с RDMA может показывать лучшую производительность по сравнению с vSAN, использующим TCP поверх Ethernet. В публикации Intel «Make the Move to 100GbE with RDMA on VMware vSAN with 4th Gen Intel Xeon Scalable Processors» были зафиксированы значительные улучшения производительности в зависимости от условий среды.
Рекомендация: используйте RDTBench для тестирования соединений RDMA и TCP между хостами. Это также отличный инструмент для проверки конфигурации перед развёртыванием производительного кластера в продакшене.
Fibre Channel — действительно ли это «золотой стандарт»?
Fibre Channel заслуженно считается надёжным решением в глазах администраторов хранилищ. Протокол Fibre Channel изначально разрабатывался с одной целью — передача трафика хранения данных. Он использует «тонкий стек» (thin stack), специально созданный для обеспечения стабильной и низколатентной передачи данных. Детеминированная сеть на базе Fibre Channel работает как единый механизм, где все компоненты заранее определены и согласованы.
Однако Fibre Channel и другие протоколы, рассчитанные на сети без потерь, тоже имеют свою цену — как в прямом, так и в переносном смысле. Это дорогая технология, и её внедрение часто «съедает» большую часть бюджета, уменьшая возможности инвестирования в другие сетевые направления. Кроме того, инфраструктуры на Fibre Channel менее гибкие по сравнению с Ethernet, особенно при необходимости поддержки разнообразных топологий.
Хотя Fibre Channel изначально ориентирован на физическую передачу данных без потерь, сбои в сети могут привести к непредвиденным последствиям. В спецификации 32GFC был добавлен механизм FEC (Forward Error Correction) для борьбы с кратковременными сбоями, но по мере роста масштаба фабрики растёт и её сложность, что делает реализацию сети без потерь всё более трудной задачей.
Преимущество Fibre Channel — не в абсолютной скорости, а в предсказуемости передачи данных от точки к точке. Как видно из сравнения, даже с учётом примерно 10% накладных расходов при передаче трафика vSAN через TCP поверх Ethernet, стандартный Ethernet легко может соответствовать или даже превосходить Fibre Channel по пропускной способности.
Обратите внимание, что такие обозначения, как «32GFC» и Ethernet 25 GbE, являются коммерческими названиями, а не точным отражением фактической пропускной способности. Каждый стандарт использует завышенную скорость передачи на уровне символов (baud rate), чтобы компенсировать накладные расходы протокола. В случае с Ethernet фактическая пропускная способность зависит от типа передаваемого трафика. Стандарт 40 GbE не упоминается, так как с 2017 года он считается в значительной степени устаревшим.
Тем временем Ethernet переживает новый виток развития благодаря инфраструктурам, ориентированным на AI, которым требуется высокая производительность без уязвимости традиционных «безубыточных» сетей. Ethernet изначально проектировался с учётом практических реалий дата-центров, где неизбежны изменения в условиях эксплуатации и отказы оборудования.
Благодаря доступным ценам на оборудование 100 GbE и появлению 400 GbE (а также приближению 800 GbE) Ethernet становится чрезвычайно привлекательным решением. Даже традиционные поставщики систем хранения данных в последнее время отмечают, что всё больше клиентов, ранее серьёзно инвестировавших в Fibre Channel, теперь рассматривают Ethernet как основу своей следующей сетевой архитектуры хранения. Объявление Broadcom о выпуске чипа Tomahawk 6, обеспечивающего 102,4 Тбит/с внутри одного кристалла, — яркий индикатор того, что будущее высокопроизводительных сетей связано с Ethernet.
С vSAN ESA большинство издержек TCP поверх Ethernet можно компенсировать за счёт грамотной архитектуры — без переподписки и с использованием сетевого оборудования, поддерживающего высокую пропускную способность. Это подтверждается в статье «vSAN ESA превосходит по производительности топовое хранилище у крупной финансовой компании», где vSAN ESA с TCP по Ethernet с лёгкостью обошёл по скорости систему хранения, использующую Fibre Channel.
Насколько хорош TCP поверх Ethernet?
Если у вас качественно спроектированная сеть с высокой пропускной способностью и без переподписки, то vSAN на TCP поверх Ethernet будет достаточно хорош для большинства сценариев и является наилучшей отправной точкой для развёртывания новых кластеров vSAN. Эта рекомендация особенно актуальна для клиентов, использующих vSAN в составе VMware Cloud Foundation 5.2, где на данный момент не поддерживается RDMA.
Хотя RDMA может обеспечить более высокую производительность, его требования и ограничения могут не подойти для вашей среды. Тем не менее, можно добиться от vSAN такой производительности и стабильности, которая будет приближена к детерминированной модели Fibre Channel. Для этого нужно:
Грамотно спроектированная сеть. Хорошая архитектура Ethernet-сети обеспечит высокую пропускную способность и низкие задержки. Использование топологии spine-leaf без блокировки (non-blocking), которая обеспечивает линейную скорость передачи от хоста к хосту без переподписки, снижает потери пакетов и задержки. Также важно оптимально размещать хосты vSAN внутри кластера — это повышает сетевую эффективность и производительность.
Повышенная пропускная способность. Устаревшие коммутаторы должны быть выведены из эксплуатации — им больше нет места в современных ЦОДах. Использование сетевых адаптеров и коммутаторов с высокой пропускной способностью позволяет рабочим нагрузкам свободно передавать команды на чтение/запись и данные без узких мест. Ключ к стабильной передаче данных по Ethernet — исключить ситуации, при которых кадры или пакеты TCP нуждаются в повторной отправке из-за нехватки ресурсов или ненадёжных каналов.
Настройка NIC и коммутаторов. Сетевые адаптеры и коммутаторы часто имеют настройки по умолчанию, которые не оптимизированы для высокой производительности. Это может быть подходящим шагом, если вы хотите улучшить производительность без использования RDMA, и уже реализовали два предыдущих пункта. В документе «Рекомендации по производительности для VMware vSphere 8.0 U1» приведены примеры таких возможных настроек.
Дункан Эппинг рассказал о том, как можно убедиться, что ваши диски VMware vSAN зашифрованы.
Если у вас включена техника шифрования "vSAN Encryption – Data At Rest", то вы можете проверить, что действительно данные на этих дисках зашифрованы в разделе настроек vSAN в клиенте vSphere Client. Однако вы можете сделать это и на уровне хоста ESXi, выполнив команду:
esxcli vsan storage list
Как вы можете увидеть из вывода команды, для шифрования указан параметр Encryption: true.
Второй момент - вам надо убедиться, что служба управления ключами шифрования Key Management System доступна и работает как положено. Это вы можете увидеть в разделе vSAN Skyline Health клиента vSphere:
Дункан также обращает внимание, что если вы используете Native Key Server и получаете ошибку "not available on host", проверьте, опцию "Use key provider only with TPM". Если она включена, то вы должны иметь модуль TPM для корректной работы механизмов шифрования. Если у вас модуля такого нет - просто снимите эту галочку.
Есть вопрос, который администраторы платформы виртуализации VMware vSphere задают регулярно:
Какие идеальные соотношения vCPU к pCPU я должен планировать и поддерживать для максимальной производительности? Как учитывать многопоточность Hyper-Threading и Simultaneous Multithreading в этом соотношении?
Ответ?
Он прост - общего, универсального соотношения не существует — и, более того, сам такой подход может привести к операционным проблемам. Сейчас объясним почему.
Раньше мы пользовались рекомендациями вроде 4 vCPU на 1 pCPU (4:1) или даже 10:1, но этот подход основывался на негласной предпосылке — рабочие нагрузки в основном были в простое. Многие организации начинали свою виртуализацию с консолидации наименее нагруженных систем, и в таких случаях высокое соотношение vCPU:pCPU было вполне обычным явлением.
Так появилась концепция коэффициента консолидации, ставшая основой для планирования ресурсов в виртуальных средах. Даже возникала конкуренция: кто сможет добиться более высокого уровня консолидации. Позже появились технологии вроде Intel Hyper-Threading и AMD SMT (Simultaneous Multithreading), которые позволяли достичь ещё большей консолидации. Тогда расчёт стал сложнее: нужно было учитывать не только физические ядра, но и логические потоки. Огромные Excel-таблицы превратились в операционные панели мониторинга ресурсов.
Но этот подход к планированию и эксплуатации устарел. Высокая динамика изменений в инфраструктуре заказчиков и рост потребления ресурсов со стороны виртуальных машин сделали модель статического соотношения нежизнеспособной. К тому же, с переходом к политике virtual-first, многие компании больше не тестируют приложения на "голом железе" до виртуализации.
А если мы не можем заранее предсказать, что будет виртуализовано, какие ресурсы ему нужны и как долго оно будет работать — мы не можем зафиксировать статическое соотношение ресурсов (процессор, память, сеть, хранилище).
Вместо этого нужно "управлять по конкуренции" (drive by contention)
То есть — инвестировать в пулы ресурсов для владельцев приложений и мониторить эти пулы на предмет высокой загруженности ресурсов и конкуренции (contention). Если возникает конфликт — значит, пул достиг предела, и его нужно расширять. Это требует нового подхода к работе команд, особенно с учётом того, что современные процессоры могут иметь огромное количество ядер.
Именно под такие задачи была спроектирована платформа VMware Cloud Foundation (VCF) и ее инструменты управления — и не только для CPU. На уровне платформы vSphere поддерживает крупные кластеры, автоматически балансируемые такими сервисами, как DRS, которые минимизируют влияние конфликтов на протяжении всего жизненного цикла приложений.
Операционный пакет VCF (Aria) следит за состоянием приложений и пулов ресурсов, сообщает о проблемах с производительностью или нехваткой ёмкости. Такая модель позволяет использовать оборудование эффективно, добиваясь лучшего уровня консолидации без ущерба для KPI приложений. Этого нельзя достичь при помощи фиксированного соотношения vCPU:pCPU.
Поэтому — чтобы не быть в рамках ограничений статических коэффициентов, повысить эффективность использования "железа" и адаптироваться к быстро меняющимся бизнес-реалиям, необходимо переосмыслить операционные модели и инструменты. В них нужно учитывать такие вещи, как:
Логические CPU не равно физические CPU/ядра (в случае гиперпоточности)
Важность точного подбора размеров виртуальных машин (right-sizing)
Ключевым фактором снижения рисков становится время вашей реакции на проблемы с производительностью или ёмкостью.
Если обеспечить быструю реакцию пока невозможно — начните с консервативного соотношения 1:1 vCPU:pCPU, не учитывая гиперпоточность. Это безопасный старт. По мере роста зрелости вашей инфраструктуры, процессов и инструментов, соотношение будет естественно улучшаться.
Идеальное финальное соотношение будет уникально для каждой организации, в зависимости от приложений, стека технологий и зрелости эксплуатации.
Вкратце:
Соотношение 1:1 даёт максимальную производительность, но по максимальной цене. Но в мире, где нужно делать больше с меньшими затратами, умение "управлять по конкуренции"— это путь к эффективной работе и инвестициям. VCF и был создан для того, чтобы справляться с этими задачами.
В рамках конференции FinOps X в Сан-Диего команда VMware CloudHealth анонсировала самое большое улучшение платформы с момента её создания. Новый интерфейс CloudHealth специально разработан с учетом потребностей современных специалистов по FinOps и предназначен для решения новых задач и проблем, возникающих в постоянно развивающейся области FinOps (мы писали ранее о CloudHealth вот тут). Благодаря инновационным функциям на базе AI, таким как Intelligent Assist и Smart Summary, новая версия помогает решать ключевые проблемы пользователей и продвигать FinOps как культурную практику во всей организации.
С 2012 года CloudHealth представляет разработки в области управления финансовыми аспектами облаков (FinOps). За последние 13 лет мы стали свидетелями бурного роста облачной инфраструктуры, программного обеспечения, ресурсов и, в последнее время, искусственного интеллекта. Видимость облачного потребления и затрат, рекомендации по оптимизации и обеспечение управления — это теперь базовые ожидания, поскольку от FinOps-команд требуют управления всё более сложными средами, контроля новых направлений ИТ-расходов и взаимодействия с расширяющимся кругом заинтересованных сторон.
Новый интерфейс CloudHealth помогает FinOps-командам и другим участникам процесса понять, где сосредоточить внимание, и упрощает управление сложной инфраструктурой. Это развитие текущих возможностей CloudHealth по масштабной обработке данных из множества источников, интеграции со сторонними инструментами, экспорту детализированных отчетов и гибкому управлению доступом и правами в соответствии со структурой вашей организации. Эти улучшения облегчают достижение FinOps-результатов и ускоряют трансформацию бизнеса.
Intelligent Assist
Одна из главных новинок — Intelligent Assist — генеративный AI-ассистент, встроенный в платформу CloudHealth. Он помогает пользователям в полной мере использовать возможности CloudHealth: предлагает подсказки по продукту, генерирует сложные отчёты, дает практические рекомендации и многое другое. Intelligent Assist — это чат-бот на базе большой языковой модели, позволяющий пользователям получать инсайты о своих облаках и сервисах на естественном языке: например, составлять детализированные кастомные отчёты или получать рекомендации, основанные на конкретных сценариях использования облака.
Эта функция упрощает работу опытных пользователей и одновременно снижает порог входа для бизнес-пользователей, заинтересованных в анализе своих облачных расходов и потребления. Поддерживая как технических, так и нетехнических специалистов, Intelligent Assist усиливает сотрудничество в FinOps-команде и делает данные доступными для всех, кто участвует в принятии решений.
Intelligent Assist обеспечивает более эффективные рабочие процессы для FinOps-специалистов, операторов облаков и других технических пользователей, позволяя быстро погружаться в данные по расходам и использованию облаков. С его помощью можно делать запросы по конкретным типам ресурсов, мгновенно формировать отчёты или отслеживать изменения в мультиоблачных средах. Кроме того, Intelligent Assist встроен в компонент Smart Summary, который информирует пользователей об изменениях на уровне ресурсов, влияющих на затраты и использование, и предлагает действия в соответствии с лучшими практиками FinOps.
Smart Summary
В условиях масштабов публичных облаков — особенно при использовании нескольких облачных провайдеров — становится практически невозможно отслеживать все ежедневные изменения, которые могут влиять на стоимость облака. Smart Summary предоставляет краткое и понятное резюме ключевых факторов, формирующих ваши облачные расходы, объясняет, как и почему они изменяются со временем, и предлагает рекомендации с поддержкой генеративного AI для принятия дальнейших действий.
Благодаря возможности отслеживать изменения на уровне отдельных ресурсов, а также предоставлять обоснования произошедших изменений и рекомендации по следующим шагам, Smart Summary позволяет пользователям быстро выявлять, понимать и объяснять, что происходит с их расходами.
Asset Explorer
Видимость на уровне ресурсов — это не просто информация о стоимости актива или регионе, в котором он работает. Это ещё и визуализация связанных ресурсов, каталогизация тегов и метаданных, а также понимание сценариев использования актива. Asset Explorer предоставляет специалистам по FinOps доступ по требованию к метаданным активов и связям между ними.
Пользователи могут выполнять простые запросы для поиска, например, активов с определёнными тегами, отсоединённых дисков или томов, устаревших снапшотов или простаивающих виртуальных машин. Asset Explorer — это развитие отчёта по активам: он представляет собой визуальный инструмент для исследования ресурсов и их связей, оснащённый встроенным движком запросов для создания, сохранения и повторного использования запросов по нужным типам активов.
Кроме того, активы интегрированы с Intelligent Assist, что позволяет осуществлять поиск по ним на естественном языке. Такие мгновенные, похожие на политики, запросы к активам позволяют быстрее предпринимать действия в рамках FinOps-практики и поддерживать детальную видимость мультиоблачной среды.
Дэшборды оптимизации и фактической экономии
Оптимизация облачных ресурсов — это обширный и непрерывный процесс, но он играет ключевую роль в демонстрации ценности и влияния FinOps-практик. Поиск, анализ и реализация мероприятий по оптимизации требуют значительных усилий, однако результатом становится более эффективная работа облака, снижение потерь и максимальная отдача от вложений.
В новом интерфейсе CloudHealth появились панели Optimization Dashboard и Realized Savings Dashboard, которые обеспечивают FinOps-команды необходимыми данными и отчётностью для принятия эффективных и результативных решений по оптимизации и демонстрации их влияния бизнесу в целом.
Optimization Dashboard — это единая настраиваемая панель, которая объединяет все доступные рекомендации по скидкам на основе обязательств, возможности ресайзинга, аномальные расходы и потенциальную экономию по всем вашим облакам и сервисам. Её цель — помочь пользователям понять, куда в первую очередь стоит направить усилия по оптимизации, указав области, где можно достичь наибольшего эффекта. Если раньше пользователей могли парализовать сотни рекомендаций, то новая панель делает акцент на действиях с наибольшим потенциалом пользы и поддерживает непрерывную мультиоблачную оптимизацию.
Несмотря на значительные усилия и инвестиции в оптимизацию, FinOps-командам часто бывает сложно ответить на вопрос: «Как узнать, сколько мы сэкономили с помощью CloudHealth?». Панель Realized Savings Dashboard позволяет отслеживать достигнутую экономию и демонстрировать финансовую ответственность организации. Клиенты могут видеть агрегированные данные об экономии из различных источников в одном месте. Встроенные виджеты по умолчанию включают охват и использование обязательств, стоимость единицы ресурса и эффективную ставку экономии. Благодаря этой панели FinOps-специалисты получают конкретные показатели, которые позволяют им показать результаты своей работы и её вклад в бизнес.
Пользовательские отчёты (Custom Reports)
Создание и настройка отчётов на уровне масштабов публичного облака остаётся задачей даже для технически подкованных пользователей. В новой версии CloudHealth отчёты были унифицированы, чтобы упростить процесс построения нужных представлений и дать необходимый уровень кастомизации под бизнес-задачи.
Теперь пользователям доступна библиотека готовых отчётов, а также возможность создавать пользовательские отчёты с помощью:
SQL (через новый интерфейс отчётности CloudHealth),
Естественного языка (с помощью Intelligent Assist)
Или визуального конструктора в интерфейсе
Такие отчёты можно легко делиться внутри конкретных подразделений, команд или арендаторов заказчика. Создание пользовательских отчётов через интерфейс или Intelligent Assist устраняет технические барьеры и позволяет FinOps-специалистам любого уровня получать доступ к самым значимым для них данным. Инструмент отчётности включает встроенный SQL-редактор и новую функцию вычисляемых столбцов, что даёт возможность формировать сложные и глубокие отчёты о расходах в облаке — в уникальных и гибких форматах.
Пользовательские виджеты и дэшборды
С учётом множества ролей, участвующих в FinOps-практике, важно, чтобы каждый пользователь CloudHealth мог настроить интерфейс под свои задачи и всегда иметь под рукой самую актуальную информацию. С новыми пользовательскими панелями (Dashboards) и виджетами (Widgets) пользователи могут создавать полностью кастомизированные дашборды, объединяя на одной панели несколько собственных отчётов в виде виджетов.
В новом интерфейсе CloudHealth действует принцип: всё, что можно представить в виде отчёта — можно добавить в пользовательскую панель. Дополнительно доступны готовые виджеты "из коробки", отображающие:
Возможности для оптимизации
Сводки по обязательствам
Аномалии в расходах
Неэффективные затраты и ресурсы и многое другое
Элементы панели можно масштабировать и перемещать в соответствии с предпочтениями пользователя. Дэшборды дают пользователям беспрецедентную гибкость для создания интерфейса, максимально соответствующего их повседневной роли и приоритетам.
Продолжаем рассказывать о российском ПО в сфере серверной виртуализации. Numa vServer — российская платформа серверной виртуализации корпоративного уровня, разработанная компанией «НумаТех». Она предназначена для создания защищённых виртуальных инфраструктур и соответствует требованиям информационной безопасности, установленным ФСТЭК России.
Архитектура и технологии
В основе Numa vServer лежит гипервизор первого типа на базе Xen, доработанный более чем в 300 аспектах для повышения безопасности, надёжности и производительности. Платформа устанавливается напрямую на аппаратное обеспечение (bare-metal), что исключает необходимость в хостовой операционной системе и обеспечивает высокую производительность и безопасность.
Безопасность и сертификация
Numa vServer сертифицирован ФСТЭК России по 4 уровню доверия и 4 классу защиты (сертификат № 4580 от 23.09.2022) . Это позволяет использовать платформу в государственных информационных системах, системах обработки персональных данных, АСУ ТП и критически важных объектах.
Ключевые функции безопасности:
Изолированная среда исполнения управляющей ВМ (Domain 0).
Мандатный контроль доступа и зонирование.
Контроль целостности конфигураций, журналов и образов ВМ.
Журналирование действий пользователей и фильтрация потоков данных.
Поддержка многофакторной аутентификации и интеграция с LDAP/Active Directory.
Функциональные возможности
Кластеризация и высокая доступность: поддержка до 64 серверов в одном пуле с возможностью автоматической миграции ВМ при сбоях.
Резервное копирование и восстановление: полные и дельта-копии, снэпшоты, репликация, поддержка протоколов NFS, SMB/CIFS, S3.
Импорт/экспорт ВМ: поддержка форматов VMware, Citrix, VirtualBox.
Управление через Numa Collider: веб-интерфейс для администрирования, мониторинга и настройки виртуальной инфраструктуры.
Интеграция с OpenStack и CloudStack: поддержка инструментов IaC, таких как Packer и Terraform.
Виртуализация GPU: возможность делить графический адаптер между несколькими ВМ с поддержкой 3D-графики.
Системные требования
Numa vServer предъявляет низкие требования к оборудованию, что позволяет использовать его на серверах возрастом более 10 лет.
Минимальные требования:
Процессор: 2 ядра, 1.5 ГГц.
Оперативная память: 4 ГБ.
Диск: 128 ГБ.
Сетевой адаптер: 1 порт, 100 Мбит/с.
Рекомендуемые характеристики:
Процессор: 4–8 ядер, 2.5 ГГц с поддержкой Intel-VT или AMD-V.
Оперативная память: 16 ГБ с поддержкой ECC.
Диск: 750 ГБ.
Сетевой адаптер: 2 порта, 1 Гбит/с.
Лицензирование и поддержка
Лицензирование Numa vServer осуществляется по количеству физических процессоров. В базовую лицензию входит редакция «Начальная» консоли управления Numa Collider. Доступны также расширенные редакции с дополнительным функционалом, такими как балансировка нагрузки, программно-определяемые сети и расширенные возможности резервного копирования.
Применение и преимущества
Numa vServer подходит для организаций, стремящихся к импортозамещению и обеспечению информационной безопасности. Платформа может использоваться для:
Создания защищённых частных, публичных или гибридных облаков.
Виртуализации отдельных серверных ролей.
Обеспечения высокой доступности критически важных систем.
Выполнения требований регуляторов в области защиты информации.
Преимущества:
Быстрое развёртывание и простота эксплуатации.
Высокий уровень безопасности и соответствие требованиям ФСТЭК.
Низкие системные требования и возможность использования на устаревшем оборудовании.
Гибкая модель лицензирования и конкурентная стоимость владения.
Заключение
Numa vServer представляет собой надёжное и функциональное решение для создания защищённых виртуальных инфраструктур в условиях импортозамещения. Благодаря своей архитектуре, соответствию требованиям безопасности и широкому функционалу, платформа может стать основой для построения эффективных и безопасных ИТ-систем в различных отраслях.
Если вы знакомы с PowerCLI, вам наверняка нравится, как легко с его помощью выполнять обычные административные задачи в экосистеме VMware. Недавно компания рассказала о совершенно новом уровне возможностей. Он предоставляет прямой доступ ко всем API-методам - это пакет PowerCLI SDK. Он уже включён в вашу установку PowerCLI — дополнительных скачиваний или настройки не требуется.
Что такое PowerCLI SDK?
Фоеймворк PowerCLI предлагает высокоуровневые командлеты. Кроме того, он включает автоматически генерируемые SDK-модули для многих основных продуктов VMware, таких как vSphere, NSX, SRM и VMware Cloud Foundation (VCF). Эти SDK дают точный доступ к API через PowerShell, позволяя создавать пользовательские автоматизации низкого уровня.
Чтобы увидеть доступные SDK в вашей среде, выполните команду:
Get-Module -ListAvailable -Name “VMware.SDK*”
Вы увидите вывод наподобие:
Начало работы: изучение VMware Cloud Foundation с помощью SDK
Давайте рассмотрим реальный пример использования модуля VMware.Sdk.Vcf.SddcManager. Этот модуль предоставляет доступ к полному API VMware Cloud Foundation (VCF) через PowerShell.
Загрузка модуля
Import-Module VMware.Sdk.Vcf.SddcManager
Подключение к VCF. Подобно Connect-VIServer, SDK имеет собственную команду подключения:
Таким образом, вы получаете структурированные данные о доменах нагрузки без необходимости писать API-обёртки и вручную управлять заголовками аутентификации.
Встроенная помощь и документация
SDK-командлеты включают полную поддержку справки по всем аспектам вызываемых API:
Get-Help Invoke-VcfGetDomains -Full
Здесь вы найдёте примеры использования, описание параметров и ссылки на онлайн-документацию API. Это существенно облегчает процесс обучения и разработки.
Поддерживаемые продукты
SDK-модули доступны для многих продуктов VMware, включая:
VMware Cloud Foundation (SDDC Manager)
vSphere
NSX-T
Site Recovery Manager (SRM)
vSphere Replication
Важно понимать, что все они автоматически включаются в последние версии фреймворка PowerCLI.
Итог
PowerCLI SDK предоставляет полный доступ к API продуктов VMware с помощью привычного синтаксиса PowerShell. Вы получаете полный контроль при создании сложных автоматизаций и можете интегрировать свои сценарии в конвейеры CI/CD без необходимости выходить из терминала. Вы также можете комбинировать высокоуровневые командлеты PowerCLI с операциями SDK, чтобы получить максимальную эффективность.
По умолчанию скорость соединения (link speed) адаптера vmxnet3 виртуальной машины устанавливается как 10 Гбит/с. Это применяемое по умолчанию отображаемое значение в гостевой ОС для соединений с любой скоростью. Реальная скорость будет зависеть от используемого вами оборудования (сетевой карты).
VMXNET 3 — это паравиртуализированный сетевой адаптер, разработанный для обеспечения высокой производительности. Он включает в себя все функции, доступные в VMXNET 2, и добавляет несколько новых возможностей, таких как поддержка нескольких очередей (также известная как Receive Side Scaling в Windows), аппаратное ускорение IPv6 и доставка прерываний с использованием MSI/MSI-X. VMXNET 3 не связан с VMXNET или VMXNET 2.
Если вы выведите свойства соединения на адаптере, то получите вот такую картину:
В статье Broadcom KB 368812 рассказывается о том, как с помощью расширенных настроек виртуальной машины можно установить корректную скорость соединения. Для этого выключаем ВМ, идем в Edit Settings и на вкладке Advanced Parameters добавляем нужное значение:
ethernet0.linkspeed 20000
Также вы можете сделать то же самое, просто добавив в vmx-файл виртуальной машины строчку ethernetX.linkspeed = "ХХХ".
При этом учитывайте следующие моменты:
Начиная с vSphere 8.0.2 и выше, vmxnet3 поддерживает скорость соединения в диапазоне от 10 Гбит/с до 65 Гбит/с.
Значение скорости по умолчанию — 10 Гбит/с.
Если вами указано значение скорости меньше 10000, то оно автоматически устанавливается в 10 Гбит/с.
Если вами указано значение больше 65000, скорость также будет установлена по умолчанию — 10 Гбит/с.
Важно отметить, что это изменение касается виртуального сетевого адаптера внутри гостевой операционной системы виртуальной машины и не влияет на фактическую скорость сети, которая всё равно будет ограничена физическим оборудованием (процессором хоста, физическими сетевыми картами и т.д.).
Это изменение предназначено для обхода ограничений на уровне операционной системы или приложений, которые могут возникать из-за того, что адаптер vmxnet3 по умолчанию определяется со скоростью 10 Гбит/с.
Платформа vSphere всегда предоставляла несколько способов использовать несколько сетевых карт (NIC) совместно, но какой из них лучший для vSAN? Давайте рассмотрим ключевые моменты, важные для конфигураций vSAN в сетевой топологии. Этот материал не является исчерпывающим анализом всех возможных вариантов объединения сетевых интерфейсов, а представляет собой справочную информацию для понимания наилучших вариантов использования техники teaming в среде VMware Cloud Foundation (VCF).
Описанные здесь концепции основаны на предыдущих публикациях:
Объединение сетевых портов NIC — это конфигурация vSphere, при которой используется более одного сетевого порта для выполнения одной или нескольких задач, таких как трафик ВМ или трафик VMkernel (например, vMotion или vSAN). Teaming позволяет достичь одной или обеих следующих целей:
Резервирование: обеспечение отказоустойчивости в случае сбоя сетевого порта на хосте или коммутатора, подключенного к этому порту.
Производительность: распределение одного и того же трафика по нескольким соединениям может обеспечить агрегацию полосы пропускания и повысить производительность при нормальной работе.
В этой статье мы сосредоточимся на объединении ради повышения производительности.
Распространённые варианты объединения
Выбор варианта teaming для vSAN зависит от среды и предпочтений, но есть важные компромиссы, особенно актуальные для vSAN. Начиная с vSAN 8 U3, платформа поддерживает один порт VMkernel на хост, помеченный для трафика vSAN. Вот три наиболее распространённые подхода при использовании одного порта VMkernel:
1. Один порт VMkernel для vSAN с конфигурацией Active/Standby
Используются два и более аплинков (uplinks), один из которых активен, а остальные — в режиме ожидания.
Это наиболее распространённая и рекомендуемая конфигурация для всех кластеров vSAN.
Простая, надёжная, идеально подходит для трафика VMkernel (например, vSAN), так как обеспечивает предсказуемый маршрут, что особенно важно в топологиях spine-leaf (Clos).
Такой подход обеспечивает надежную и стабильную передачу трафика, но не предоставляет агрегации полосы пропускания — трафик проходит только по одному активному интерфейсу.
Обычно Standby-интерфейс используется для другого типа трафика, например, vMotion, для эффективной загрузки каналов.
2. Один порт VMkernel для vSAN с двумя активными аплинками (uplinks) и балансировкой Load Based Teaming (LBT)
Используются два и более аплинков в режиме «Route based on physical NIC load».
Это можно рассматривать как агрегацию на уровне гипервизора.
Изначально предназначен для VM-портов, а не для трафика VMkernel.
Преимущества для трафика хранилища невелики, могут вызывать проблемы из-за отсутствия предсказуемости маршрута.
Несмотря на то, что это конфигурация по умолчанию в VCF, она не рекомендуется для портов VMkernel, помеченных как vSAN.
В VCF можно вручную изменить эту конфигурацию на Active/Standby без проблем.
3. Один порт VMkernel для vSAN с использованием Link Aggregation (LACP)
Использует два и более аплинков с расширенным хешированием для балансировки сетевых сессий.
Может немного повысить пропускную способность, но требует дополнительной настройки на коммутаторах и хосте.
Эффективность зависит от топологии и может увеличить нагрузку на spine-коммутаторы.
Используется реже и ограниченно поддерживается в среде VCF.
Версия VCF по умолчанию может использовать Active/Active с LBT для трафика vSAN. Это универсальный режим, поддерживающий различные типы трафика, но неоптимален для VMkernel, особенно для vSAN.
Рекомендуемая конфигурация:
Active/Standby с маршрутизацией на основе виртуального порта (Route based on originating virtual port ID). Это поддерживается в VCF и может быть выбрано при использовании настраиваемого развертывания коммутатора VDS. Подробнее см. в «VMware Cloud Foundation Design Guide».
Можно ли использовать несколько портов VMkernel на хосте для трафика vSAN?
Теоретически да, но только в редком случае, когда пара коммутаторов полностью изолирована (подобно Fibre Channel fabric). Это не рекомендуемый и редко используемый вариант, даже в vSAN 8 U3.
Влияние объединения на spine-leaf-сети
Выбор конфигурации teaming на хостах vSAN может показаться несущественным, но на деле сильно влияет на производительность сети и vSAN. В топологии spine-leaf (Clos), как правило, нет прямой связи между leaf-коммутаторами. При использовании Active/Active LBT половина трафика может пойти через spine, вместо того чтобы оставаться на уровне leaf, что увеличивает задержки и снижает стабильность.
Аналогичная проблема у LACP — он предполагает наличие прямой связи между ToR-коммутаторами. Если её нет, трафик может либо пойти через spine, либо LACP-связь может полностью нарушиться.
На практике в некоторых конфигурациях spine-leaf коммутаторы уровня ToR (Top-of-Rack) соединены между собой через межкоммутаторное соединение, такое как MLAG (Multi-Chassis Link Aggregation) или VLTi (Virtual Link Trunking interconnect). Однако не стоит считать это обязательным или даже желательным в архитектуре spine-leaf, так как такие соединения часто требуют механизмов блокировки, например Spanning Tree (STP).
Стоимость и производительность: нативная скорость соединения против агрегации каналов
Агрегация каналов (link aggregation) может быть полезной для повышения производительности при правильной реализации и в подходящих условиях. Но её преимущества часто переоцениваются или неправильно применяются, что в итоге может приводить к большим затратам. Ниже — четыре аспекта, которые часто упускаются при сравнении link aggregation с использованием более быстрых нативных сетевых соединений.
1. Высокое потребление портов
Агрегация нескольких соединений требует большего количества портов и каналов, что снижает общую портовую ёмкость коммутатора и ограничивает количество возможных хостов в стойке. Это увеличивает расходы на оборудование.
2. Ограниченный прирост производительности
Агрегация каналов, основанная на алгоритмическом балансировании нагрузки (например, LACP), не дает линейного увеличения пропускной способности.
То есть 1+1 не равно 2. Такие механизмы лучше работают при большом количестве параллельных потоков данных, но малоэффективны для отдельных (дискретных) рабочих нагрузок.
3. Ошибочные представления об экономичности
Существует мнение, что старые 10GbE-коммутаторы более экономичны. На деле — это миф.
Более объективный показатель — это пропускная способность коммутатора, измеряемая в Гбит/с или Тбит/с. Хотя сам по себе 10Gb-коммутатор может стоить дешевле, более быстрые модели обеспечивают в 2–10 раз больше пропускной способности, что делает стоимость за 1 Гбит/с ниже. Кроме того, установка более быстрых сетевых адаптеров (NIC) на серверы обычно увеличивает стоимость менее чем на 1%, при этом может дать 2,5–10-кратный прирост производительности.
4. Нереализованные ресурсы
Современные серверы обладают огромными возможностями по процессору, памяти и хранилищу, но не могут раскрыть свой потенциал из-за сетевых ограничений.
Балансировка между вычислительными ресурсами и сетевой пропускной способностью позволяет:
сократить общее количество серверов;
снизить капитальные затраты;
уменьшить занимаемое пространство;
снизить нагрузку на систему охлаждения;
уменьшить потребление портов в сети.
Именно по этим причинам VMware рекомендует выбирать более высокие нативные скорости соединения (25Gb или 100Gb), а не полагаться на агрегацию каналов — особенно в случае с 10GbE. Напомним, что когда 10GbE появился 23 года назад, серверные процессоры имели всего одно ядро, а объём оперативной памяти составлял в 20–40 раз меньше, чем сегодня. С учётом того, что 25GbE доступен уже почти десятилетие, актуальность 10GbE для дата-центров практически исчерпана.
Объединение для повышения производительности и отказоустойчивости обычно предполагает использование нескольких физических сетевых карт (NIC), каждая из которых может иметь 2–4 порта. Сколько всего портов следует иметь на хостах vSAN? Это зависит от следующих факторов:
Степень рабочих нагрузок: среда с относительно пассивными виртуальными машинами предъявляет гораздо меньшие требования, чем среда с тяжёлыми и ресурсоёмкими приложениями.
Нативная пропускная способность uplink-соединений: более высокая скорость снижает вероятность конкуренции между сервисами (vMotion, порты ВМ и т.д.), работающими через одни и те же аплинки.
Используемые сервисы хранения данных: выделение пары портов для хранения (например, vSAN) почти всегда даёт наилучшие результаты — это давно устоявшаяся практика, независимо от хранилища.
Требования безопасности и изоляции: в некоторых средах может потребоваться, чтобы аплинки, используемые для хранения или других задач, были изолированы от остального трафика.
Количество портов на ToR-коммутаторах: количество аплинков может быть ограничено самими коммутаторами ToR. Пример: пара ToR-коммутаторов с 2?32 портами даст 64 порта на стойку. Если в стойке размещено максимум 16 хостов по 2U, каждый хост может получить максимум 4 uplink-порта. А если коммутаторы имеют по 48 портов, то на 16 хостов можно выделить по 6 uplink-портов на каждый хост. Меньшее количество хостов в стойке также позволяет увеличить количество портов на один хост.
Рекомендация:
Даже если вы не используете все аплинки на хосте, рекомендуется собирать vSAN ReadyNode с двумя NIC, каждая из которых имеет по 4 uplink-порта. Это позволит без проблем выделить отдельную команду (team) портов только под vSAN, что настоятельно рекомендуется. Такой подход обеспечит гораздо большую гибкость как сейчас, так и в будущем, по сравнению с конфигурацией 2 NIC по 2 порта.
Итог
Выбор оптимального варианта объединения (teaming) и скорости сетевых соединений для ваших хостов vSAN — это важный шаг к тому, чтобы обеспечить максимальную производительность ваших рабочих нагрузок.
VMware/Broadcom представили новую сертификацию — VMware Certified Professional – Private Cloud Security Administrator (VCP-PCS), которая подтверждает квалификацию специалистов по обеспечению безопасности в среде VMware Cloud Foundation (VCF) с использованием решений VMware vDefend. Это важный шаг в направлении усиления защиты частных облаков, особенно в условиях растущего спроса на модели Zero Trust и комплексные меры кибербезопасности.
Что представляет собой VCP-PCS?
Сертификация VCP-PCS предназначена для специалистов, отвечающих за безопасность VCF, включая:
Архитекторов и инженеров облачной инфраструктуры
Администраторов виртуальной инфраструктуры
Системных администраторов
Специалистов по поддержке и внедрению решений
VCP-PCS подтверждает способность кандидата:
Настраивать и управлять распределёнными и шлюзовыми межсетевыми экранами
Реализовывать защиту от продвинутых угроз
Внедрять архитектуру Zero Trust с использованием VMware vDefend
Использовать аналитические инструменты и средства безопасности для мониторинга и реагирования на инциденты
Подготовка и экзамен
Для получения сертификации необходимо:
1. Пройти обучение
Курс: VMware vDefend Security for VCF 5.x Administrator
Темы: архитектура vDefend, управление политиками безопасности, практическое применение в VCF
2. Сдать экзамен
Название: VMware vDefend Security for VCF 5.x Administrator (6V0-21.25)
Формат: 75 вопросов (множественный выбор и множественные ответы)
Обеспечивать безопасность в современных частных облаках
Внедрять и поддерживать архитектуру Zero Trust
Использовать инструменты VMware vDefend для защиты инфраструктуры
Это особенно актуально для организаций, стремящихся усилить защиту своих облачных сред и соответствовать современным требованиям безопасности. Если вы стремитесь углубить свои знания в области безопасности частных облаков и повысить свою профессиональную ценность, сертификация VCP-PCS станет отличным выбором. Она подтверждает вашу экспертизу в одной из самых востребованных областей современной IT-инфраструктуры.
Как сообщает CNews, 15 мая 2025 года было официально подтверждено, что отечественная платформа виртуализации SpaceVM успешно прошла тестовые испытания на совместимость с серверами Fplus «Спутник». Это событие стало важным шагом в направлении формирования полностью отечественной ИТ-инфраструктуры, обеспечивающей технологический суверенитет и независимость от зарубежных решений.
Тестирование и результаты
В ходе испытаний была проверена корректная работа всех ключевых функций виртуализации:
Создание, клонирование и управление виртуальными машинами
Работа со снапшотами, восстановление и миграция ВМ
Операции с виртуальными дисками и проброс хранилищ по Fibre Channel
Настройка виртуальных сетей и интерфейсов
Гостевые операционные системы на архитектуре x86_64 запускались и функционировали без ошибок. Тестирование проводилось на двух конфигурациях серверов Fplus «Спутник», оснащённых процессорами Intel Xeon Scalable и сетевыми адаптерами Broadcom и Mellanox. Все тесты завершились успешно, подтвердив полную интеграцию программного обеспечения SpaceVM с серверной платформой.
Значение для отрасли
Подтверждение совместимости между SpaceVM и серверами Fplus «Спутник» имеет важное значение для российских организаций, стремящихся к импортозамещению в сфере ИТ. Это позволяет формировать независимую ИТ-инфраструктуру, способную заменить зарубежные решения в корпоративном и государственном сегменте.
Алексей Мензовитый, директор по продукту SpaceVM, отметил:
"Подтверждение совместимости с российскими серверами усиливает значение SpaceVM как базовой платформы для виртуализации в импортонезависимых проектах. Мы продолжаем развивать экосистему совместимых решений и обеспечивать реальную альтернативу иностранному ПО."
Михаил Волков, главный исполнительный директор Fplus, добавил:
"Мы как производитель 'железа' продолжаем расширять технологическую совместимость с программным обеспечением ведущих отечественных разработчиков. Успешное тестирование серверов 'Спутник' и платформы SpaceVM гарантирует заказчикам, что их ИТ-инфраструктура будет реализована на полностью совместимых российских реестровых решениях."
Перспективы
Совместимость SpaceVM с серверами Fplus «Спутник» открывает новые возможности для российских предприятий и государственных организаций в создании надежной и безопасной ИТ-инфраструктуры, соответствующей требованиям импортозамещения и технологической независимости. Это сотрудничество между двумя отечественными компаниями демонстрирует потенциал российской ИТ-отрасли в разработке и внедрении высококачественных решений, способных конкурировать с зарубежными аналогами.
Для получения дополнительной информации о платформе виртуализации SpaceVM и серверах Fplus «Спутник» вы можете посетить официальные сайты компаний:
Object First — это компания, основанная Ратмиром Тимашевым, одним из легендарных сооснователей Veeam Software. После того как Veeam был продан инвестиционной компании Insight Partners за $5 млрд в 2020 году, Тимашев отошел от операционного управления компанией, но остался в ИТ-индустрии. Его новым проектом стала Object First, цель которой — предложить максимально простое, защищенное и производительное решение для хранения резервных копий, оптимизированное под решения Veeam.
Цели и философия Object First
Object First была создана с четким пониманием болевых точек ИТ-отделов: сложность настройки хранилищ, высокая стоимость масштабируемых решений и растущие угрозы кибератак, в том числе программ-вымогателей. Команда Object First стремится решить эти проблемы с помощью подхода "Secure by Design" и глубокой интеграции с Veeam Backup and Replication.
Что такое Ootbi?
Флагманский продукт Object First называется Ootbi ("Out-of-the-box immutability") — это on-premise объектное хранилище, специально созданное для Veeam. Основные технические особенности Ootbi:
Готовность к работе "из коробки": решение поставляется в виде готового устройства, не требующего глубокой предварительной настройки.
Поддержка объектного хранилища S3: Ootbi работает по протоколу S3 и полностью совместим с Veeam Backup & Replication.
Неизменяемость данных (immutability): встроенная защита от программ-вымогателей (Ransomware). Используются политики WORM (Write Once, Read Many), гарантирующие, что резервные копии не могут быть удалены или изменены в течение заданного периода (даже с административными привилегиями).
Интеграция с Veeam через Scale-Out Backup Repository (SOBR): Ootbi можно использовать как capacity tier, обеспечивая гибкое и масштабируемое резервное копирование.
Безопасность и упрощенное администрирование: не требуется root-доступ или отдельные операционные системы. Решение изолировано и минимизирует человеческий фактор.
Аппаратная архитектура
На данный момент Ootbi представляет собой масштабируемую кластерную систему из 2-4 узлов:
Каждый узел содержит вычислительные ресурсы и локальное хранилище (HDD и SSD для кэширования).
Используется распределённая файловая система, обеспечивающая отказоустойчивость и высокую доступность.
Производительность: до 4 ГБ/сек совокупной пропускной способности, до 1 ПБ эффективного объема хранения с учетом дедупликации и компрессии на стороне Veeam.
Преимущества для клиентов
Минимизация риска потери данных благодаря immutability и встроенной защите.
Снижение TCO (total cost of ownership) за счет простоты управления и отказа от сложных инфраструктур.
Быстрое развёртывание: установка и настройка возможна за считанные часы.
Отсутствие необходимости в публичном облаке, что важно для компаний с повышенными требованиями к безопасности и локализации данных.
Object First предлагает уникальное, строго специализированное решение для клиентов Veeam, закрывающее потребности в безопасном и удобном хранении резервных копий. Подход компании отражает философию ее основателя — создавать простые и эффективные продукты, фокусируясь на ключевых болевых точках рынка. Ootbi становится привлекательным выбором для компаний, стремящихся к максимальной защищенности своих данных без лишней сложности и затрат.
Недавно мы писали о программном доступе к спискам совместимости Broadcom Compatibility Guide (BCG), а на днях стало известно, что ключевой компонент платформы VMware Cloud Foundation 9 - платформа VMware vSphere 9 - уже присутствует в BCG, так что можно проверять свои серверы и хранилища на предмет совместимости с VMware ESXi 9.0 и VMware vSAN 9.0:
Кстати в списках совместимости с vVols не указан VMware ESXi 9, так как эта технология будет признана deprecated в следующей версии платформы (и окончательно перестанет поддерживаться в vSphere 9.1).
Имейте в виду, что список совместимости еще может поменяться к моменту финального релиза VMware vSphere 9, но ориентироваться на это для планирования закупок можно уже сейчас.
Виртуальные модули VMware NSX Edge Appliances играют ключевую роль в инфраструктуре VMware NSX, обеспечивая маршрутизацию север-юг, функции межсетевого экрана, балансировку нагрузки и VPN-сервисы. Потеря доступа к NSX Edge из-за забытого или истёкшего пароля может нарушить работу системы и ограничить возможности управления. В этой статье мы рассмотрим процедуру сброса пароля для устройства NSX Edge. Описанная ниже процедура подходит для сброса паролей на виртуальных модулях NSX Manager, Edge и Cloud Service Manager.
Чтобы сбросить пароль root, используйте следующую процедуру:
Войдите в графический интерфейс NSX > System > Nodes > Edge Cluster > выберите узел Edge > кликните правой кнопкой мыши > выберите «Put into Maintenance Mode», чтобы перевести хост Edge в режим обслуживания.
Войдите в vCenter, найдите виртуальную машину Edge и установите задержку загрузки (boot delay) на 9000.
Подключитесь к консоли виртуального модуля Edge Appliance.
Перезагрузите систему.
Когда появится меню загрузчика GRUB, быстро нажмите левую клавишу SHIFT или ESC. Если вы не успеете, и процесс загрузки продолжится, необходимо будет перезагрузить систему снова.
Нажмите e, чтобы отредактировать пункт меню. Выберите верхнюю строку с Ubuntu, затем введите имя пользователя root и пароль GRUB для пользователя root (он отличается от пароля пользователя root на самом устройстве). Пароль по умолчанию — NSX@VM!WaR10 (скорее всего, вы его не меняли).
Нажмите e, чтобы отредактировать выбранный пункт. Найдите строку, начинающуюся с linux, и добавьте в конец этой строки следующее: systemd.wants=PasswordRecovery.service
Нажмите Ctrl+X, чтобы продолжить загрузку. Когда появятся последние сообщения журнала, введите новый пароль для пользователя root.
Введите пароль ещё раз. Загрузка продолжится.
После перезагрузки вы можете убедиться в смене пароля, выполнив вход под пользователем root с новым паролем. С помощью входа под root вы также можете изменить пароли пользователей admin и audit, если потребуется.
Заключительный шаг — вывести узел Edge из режима обслуживания.
Как сообщалось еще в апреле, загрузки VMware Fling были перенесены в раздел бесплатных загрузок на портале поддержки Broadcom (BSP), и этот переход завершился на прошедших выходных. В дальнейшем все новые и обновленные версии VMware Flings будут публиковаться на BSP.
Чтобы получить доступ к загрузкам VMware Flings или любому другому бесплатному или предоставленному программному обеспечению Broadcom, необходимо зарегистрировать бесплатную учетную запись BSP — там допускаются и личные email-адреса (например, Gmail).
После перехода в раздел бесплатных загрузок, выберите раздел (Division) VMware и подраздел Flings:
Там вы увидите полный список бесплатных утилит для виртуальной инфраструктуры VMware vSphere / Cloud Foundation:
К сожалению, не все Flings (которые у нас можно найти по тэгу Labs) выжили, плюс не всегда актуальная версия утилиты соответствует вашей версии среды. Поискать прошлые версии этих утилит можно с помощью Wayback Machine.
На прошедшей недавно конференции VeeamON 2025 было рассказано о скором выходе новой версии Veeam Backup & Replication 13, в которой будут представлены новые функции, направленные на повышение доступности (High Availability, HA), что позволяет компаниям поддерживать бесперебойную работу и защищать критически важные данные даже в случае непредвиденных ситуаций. Эта возможность уже давно запрашивалась пользователями, и вот, наконец, она будет реализована в производственной среде.
Помимо высокой доступности, Veeam Backup & Replication v13 предложит впечатляющие возможности, такие как развертывание сервера управления, хранилища, прокси и других компонентов напрямую из Veeam Software Appliance, мгновенное восстановление в Microsoft Azure, расширенное управление доступом на основе ролей (RBAC), а также множество других улучшений.
В Veeam Backup & Replication v13 возможности HA были расширены за счёт внедрения резервного управляющего сервера, готового к моментальному переключению при необходимости. В фоновом режиме репликация базы данных PostgreSQL обеспечивает постоянное дублирование всех конфигурационных данных, что гарантирует готовность системы к любым сбоям. При этом механизм репликации кэша, встроенный в базу данных, непрерывно передаёт данные на резервный сервер, обеспечивая его синхронность с основным узлом. Такая проактивная настройка устраняет время ожидания в случае аварии — резервная машина Veeam Backup & Replication полностью готова к работе и может быть активирована при необходимости.
На первом этапе функция HA будет доступна только для Veeam Backup & Replication на платформе Linux (дистрибутив основан на Rocky Linux). Процесс переключения выполняется вручную и по требованию — администраторы могут инициировать его в нужный момент, так как автоматические триггеры пока не предусмотрены. Архитектура реализована по схеме "активный-пассивный" с двумя узлами, с акцентом на надёжность.
Настройка сервера
После установки Veeam Backup & Replication v13 с помощью Veeam Software Appliance (в формате .ova или .iso), необходимо выполнить несколько базовых шагов конфигурации самого сервера. В этот процесс входят следующие ключевые этапы:
Настройка имени: присвойте виртуальному модулю понятное и информативное имя для его простой идентификации в инфраструктуре.
Сетевые настройки: установите сетевые параметры для надёжной связи с другими компонентами и резервным сервером.
Настройка NTP: укажите сервер синхронизации времени (Network Time Protocol), чтобы обеспечить точное совпадение времени на всех системах. Это критически важно, например, для проверки одноразовых паролей (OTP).
Пароль в соответствии с DISA STIG: создайте безопасный пароль, соответствующий требованиям DISA STIG, чтобы усилить защиту сервера Veeam Backup & Replication.
OTP для администратора и офицера безопасности Veeam: сгенерируйте и настройте одноразовые пароли для ролей администратора и офицера безопасности (Security Officer). Несмотря на то, что для корректной работы OTP требуется точное время, доступ к интернету для их проверки не нужен, что позволяет использовать систему в изолированных средах.
Настройка кластера
Создание кластера и настройка сети - укажите сетевые параметры для надёжной связи с другими компонентами и резервным сервером.
Задайте сетевые параметры основного и резервного узлов. Убедитесь, что оба узла кластера находятся в одной IP-подсети — на этапе бета-тестирования это обязательное условие.
После этого начнется процесс создания и конфигурации кластера.
Если основной узел не отвечает, вы можете инициировать операцию переключения (failover), чтобы ввести в работу резервный узел.
Важным преимуществом такого подхода является то, что нет необходимости импортировать резервную копию конфигурации, заново создавать задания, импортировать бэкапы или повторно вводить учётные данные — Veeam Backup & Replication продолжает работать без перебоев. Мы ещё увидим, какие дополнительные возможности появятся в финальном релизе, запланированном на конец этого года. Возможно, будут добавлены новые функции, но даже на текущем этапе это крайне полезная возможность, которая экономит массу времени в аварийной ситуации.
Хотя процесс переключения не автоматизирован и должен запускаться вручную авторизованным пользователем, появление команд PowerShell в будущих версиях откроет возможность создания и интеграции собственной логики автоматизации — например, с использованием узла-наблюдателя (witness node).
Компания VMware недавно выпустила обновленную версию средства для виртуализации и агрегации сетей NSX 4.2.2, которое предлагает множество новых функций, обеспечивая расширенные возможности виртуализованных сетей и безопасности для частных облаков.
Основные улучшения охватывают следующие направления:
Межсетевой экран vDefend представляет новый высокопроизводительный режим Turbo (SCRX), который повышает производительность распределённой IDS/IPS-системы и механизма обнаружения приложений уровня L7 для распределённого межсетевого экрана. Новый механизм инспекции использует детерминированное распределение ресурсов и расширенные конвейеры обработки пакетов в гипервизоре ESXi, обеспечивая прирост производительности при значительно меньшем потреблении ресурсов памяти и процессора.
Enhanced Data Path (EDP) получил ряд улучшений, включая добавление скрипта, снижающего необходимость ручного вмешательства при включении EDP в кластере, а также улучшения стабильности, совместимости и снижение влияния на операции жизненного цикла.
В этом выпуске VMware NSX включает улучшения платформы Edge, в том числе новую опцию повторного развертывания и улучшенную документацию по API мониторинга Edge.
Скрипт Certificate Analyzer Resolver (CARR) теперь поддерживает проверку сертификатов Compute Manager (vCenter). Он выполняет проверку целостности и восстановление самоподписных сертификатов NSX, а также может заменять сертификаты, срок действия которых истёк или скоро истечёт.
Среди новых улучшений безопасности платформы — предопределённая роль Cloud Admin Partner, увеличение числа поддерживаемых групп LDAP и Active Directory, а также поддержка стандарта FIPS 140-3.
Сетевые возможности
1. Сеть канального уровня (Layer 2 Networking)
Появился скрипт автоматизации включения режима коммутатора EDP для VCF 5.2.x (NSX 4.2.2). В состав NSX Manager добавлен скрипт enable_uens, предназначенный для сокращения ручных действий при включении режима Enhanced Data Path Standard на кластере. Скрипт последовательно выполняет следующие шаги на хостах:
Переводит хост в режим обслуживания
Обновляет режим коммутатора на EDP
Выводит хост из режима обслуживания
Синхронизирует изменения с Transport Node Profile кластера
Он выполняется из той же директории и применяется к одному кластеру за раз, требуя входных данных из JSON-файла. Подробные инструкции приведены в файле readme скрипта.
Скрипт особенно полезен для релизов NSX 4.x, так как смена режима передачи данных на EDP Standard через настройки Transport Node Profile вызывает немедленные изменения на хостах ESXi, что может привести к сетевому простою на несколько секунд на каждом хосте. Метод "Enabling EDP Standard in Active Environments" снижает простой, но требует ручного вмешательства на каждом хосте, что при масштабных развертываниях становится крайне трудоёмким из-за шагов с режимом обслуживания.
2. Повышение надёжности EDP Standard в рамках долгосрочной поддержки (LTS)
NSX 4.2.2 рекомендуется как основная версия для использования Enhanced Data Path во всех развертываниях VMware Cloud Foundation и типах рабочих доменов, включая кластеры NSX Edge и общие вычислительные кластеры (VI Workload Domains).
EDP рекомендован для достижения максимальной производительности обработки сетевого трафика и минимизации затрат ресурсов на сетевую обработку. В этом релизе реализованы улучшения стабильности и совместимости, благодаря чему он рекомендован в качестве версии с долгосрочной поддержкой (LTS) для NSX 4.2.
Основные улучшения надёжности в NSX 4.2.2:
Повышена производительность EDP при масштабных развертываниях.
Улучшена работа EDP в средах на базе vSAN.
Повышена производительность EDP при использовании распределённого межсетевого экрана.
Расширена совместимость с сетевыми адаптерами через механизм driver shimming.
Совместимость EDP с контейнерными платформами (NCP, Antrea).
Повышена доступность (uptime) канала данных EDP Standard при операциях жизненного цикла — время переключения сокращено с десятков секунд до менее чем 3 секунд.
В пользовательском интерфейсе добавлена кнопка Redeploy Edge, позволяющая легко и быстро повторно развернуть узел Edge. Эта операция запускает соответствующий API, как указано в документации: NSX Edge VM Redeploy API.
Это улучшение упрощает процесс повторного развертывания, снижает операционные издержки и улучшает пользовательский опыт, предоставляя возможность настройки параметров Edge при повторном запуске.
Обновлённая документация по API мониторинга NSX Edge теперь предоставляет более понятные и подробные инструкции. В ней содержатся:
Подробные объяснения всех соответствующих API-вызовов с примерами запросов и ответов.
Полные описания возвращаемых мониторинговых данных, включая поэлементную расшифровку каждого поля.
Глубокое разъяснение всех доступных метрик: что они обозначают, как рассчитываются и как их интерпретировать в реальных сценариях.
Безопасность
1. Межсетевой экран (Firewall)
Распределённый межсетевой экран (Distributed Firewall) использует новый высокопроизводительный режим Turbo (SCRX) для фильтрации приложений уровня L7.
NSX Manager теперь поддерживает большее количество сервисов межсетевого экрана для экземпляров класса Extra Large. Подробности см. в разделе Configuration Maximums.
Группировка в межсетевом экране поддерживает большее число активных участников как для конфигураций Large, так и Extra Large. Подробнее — в Configuration Maximums.
2. IDS/IPS
Распределённая система IDS/IPS демонстрирует значительный прирост производительности благодаря новому высокопроизводительному движку Turbo (SCRX). При использовании нового движка возможно достичь скорости анализа трафика до 9 Гбит/с в зависимости от профиля трафика на хосте ESXi.
Показатели производительности и другие операционные метрики Distributed IDS/IPS доступны в реальном времени через Security Services Platform (SSP).
Внимание: новый движок SCRX предъявляет строгие требования к совместимости с версией ESXi, а также имеет особые условия для установки/обновления. См. раздел Getting Started и выполните Turbo Mode Compatibility Pre-Check Script для проверки среды. Дополнительную информацию можно найти в базе знаний (KB) — статья 396277.
Настоятельно рекомендуется запускать скрипт CARR перед обновлением NSX Manager. Цель — убедиться, что срок действия сертификатов Transport Node (TN) не истекает в течение 825 дней. Если срок действия сертификата TN меньше этого значения, скрипт можно повторно запустить для его замены. См. статью Broadcom KB 369034.
2. Управление доступом (RBAC)
Добавлена новая предопределённая роль Cloud Partner Admin — специально для облачных партнёров, которым необходим доступ к функциям сетей и безопасности, но при этом нужно исключить доступ к просмотру лицензий NSX.
3. Аутентификация через LDAP
Увеличено максимальное число поддерживаемых групп LDAP и Active Directory — с 20 до 500.
4. Сертификация платформы
Поддержка стандарта FIPS 140-3: NSX 4.2.2 теперь использует криптографические модули, соответствующие требованиям FIPS 140-3 (Federal Information Processing Standards). NSX работает в режиме соответствия FIPS по умолчанию во всех развертываниях. Подтверждение соответствия стандарту FIPS 140-3 гарантирует, что NSX использует актуальные криптомодули для надёжной защиты рабочих нагрузок. Дополнительная информация о модулях доступна по ссылке в оригинальной документации.
Broadcom Compatibility Guide (ранее VMware Compatibility Guide) — это ресурс, где пользователи могут проверить совместимость оборудования (нового или уже используемого) с программным обеспечением VMware. Вильям Лам написал интересную статью о доступе к BCG через программный интерфейс VMware PowerCLI.
Существует несколько различных руководств по совместимости, которые можно использовать для поиска информации, начиная от процессоров и серверов и заканчивая разнообразными устройствами ввода-вывода, такими как ускорители и видеокарты. Если у вас небольшое количество оборудования, поиск будет достаточно простым. Однако, если необходимо проверить разнообразное оборудование, веб-интерфейс может оказаться не самым быстрым и удобным вариантом.
Хорошая новость в том, что Broadcom Compatibility Guide (BCG) может легко использоваться программно, в отличие от предыдущего VMware Compatibility Guide (VCG), у которого была другая система бэкенда.
Хотя официального API с документацией, поддержкой и обратной совместимостью для BCG нет, пользователи могут взаимодействовать с BCG, используя тот же API, который применяется веб-интерфейсом BCG.
Обе функции предполагают поиск на основе комбинации идентификаторов поставщика (Vendor ID, VID), идентификатора устройства (Device ID, DID) и идентификатора поставщика подсистемы (SubSystem Vendor ID, SVID).
Примечание: BCG предоставляет разнообразные возможности поиска и фильтрации; ниже приведены лишь примеры одного из способов работы с API BCG. Если вам интересны другие методы поиска, ознакомьтесь со справочной информацией в конце документа, где описаны иные опции фильтрации и руководства по совместимости BCG.
Шаг 1 – Загрузите скрипт queryHostPCIInfo.ps1 (который Вильям также обновил, чтобы можно было легко исключить неприменимые устройства с помощью строк исключений), и запишите идентификаторы устройств (VID, DID, SVID), которые вы хотите проверить.
По умолчанию функция возвращает четыре последние поддерживаемые версии ESXi, однако вы можете изменить это, указав параметр ShowNumberOfSupportedReleases:
При проверке SSD-накопителей vSAN через BCG вы также можете указать конкретный поддерживаемый уровень vSAN (Hybrid Cache, All-Flash Cache, All-Flash Capacity или ESA), используя следующие параметры:
Если вы хотите автоматизировать работу с другими руководствами по совместимости в рамках BCG, вы можете определить формат запроса (payload), используя режим разработчика в браузере. Например, в браузере Chrome, перед выполнением поиска в конкретном руководстве по совместимости, нажмите на три точки в правом верхнем углу браузера и выберите "More Tools->Developer Tools", после чего откроется консоль разработчика Chrome. Далее вы можете использовать скриншот, чтобы разобраться, как выглядит JSON-запрос для вызова API "viewResults".
Компания Broadcom официально объявила о запуске средства измерения использования облачных ресурсов VMware Cloud Foundation версии 9.0 (VCF Usage Meter), ранее известного как VMware vCloud Usage Meter. Оно доступно с 7 мая 2025 года.
Обзор VCF Usage Meter
VCF Usage Meter — это виртуальный модуль, развёртываемый на экземпляре сервера vCenter в рамках частного облака VMware Cloud Foundation. Он играет ключевую роль в измерении потребления основных продуктов в средах VMware Cloud Service Provider (VCSP) и создании отчётов об использовании. Этот релиз включает новые возможности измерения, улучшенную безопасность и поддержку VCF 9.0 (после его предстоящего релиза).
VCF Usage Meter 9.0 является обязательным инструментом для всех поставщиков облачных услуг VMware. Он необходим для измерения использования ядер CPU в соответствии с требованиями программы.
Провайдеры VCSP обязаны обновиться до версии VCF Usage Meter 9.0 в течение 90 дней с момента релиза (General Availability). Если обновление не будет завершено в этот срок, Broadcom перестанет принимать данные об использовании со старых версий Usage Meter, а авторизация поставщика как VCSP будет отозвана.
В таких случаях среда партнёра будет помечена как не соответствующая требованиям программы VCSP, что может привести к несоответствиям в выставлении счетов, ограничению поддержки, исключению из участия в программе и другим связанным последствиям.
Чтобы обеспечить бесперебойную работу и соответствие требованиям, рекомендуется начать планирование обновления как можно раньше, чтобы уложиться в 90-дневный срок. У провайдеров есть время до 5 августа 2025 года, чтобы обновить текущие экземпляры Usage Meter до новой версии VCF Usage Meter 9.0 и сохранить соответствие требованиям.
Новые функции, улучшения и обзор
1. Поддержка измерения метрик VCF 9.0
VCF Usage Meter 9.0 полностью готов к измерению использования для предстоящей версии VMware Cloud Foundation 9 — важного этапа на пути к единой и современной платформе частного облака.
Чтобы обеспечить плавный переход для поставщиков облачных услуг VMware (VCSP), процесс измерения в VCF 9.0 максимально схож с предыдущими версиями. Начать работу просто: добавьте конечные точки vCenter в VCF Usage Meter, и измерение начнётся автоматически.
Все знакомые инструменты отчетности — Hourly Usage Report (HUR), Virtual Machine History Report (VMHR) и потоки данных для расчета использования — продолжают предоставлять необходимые вам данные. Эти отчёты полностью интегрированы с консолью VMware Cloud Foundation Business Services (VCF Business Services Console) и поддерживают развертывания VCF 9.0.
Обратите внимание, что лицензионные ключи будут заменены на бесключевым механизмом, активируемым через облако права (entitlements), что упрощает активацию и повышает точность расчётов.
2. Новая аутентификация на основе OAuth-приложения
Broadcom добавила новый уровень безопасности для загрузки данных об использовании в консоль VCF Business Services — авторизация на основе OAuth-приложения для VCF Usage Meter 9.0. Хотя загрузка данных всегда защищалась через HTTPS (и продолжит работать), OAuth позволяет пользователю авторизовать консоль VCF Business Services для доступа к данным измерений, хранящимся в VCF Usage Meter 9.0, без передачи самих учётных данных.
С выходом VCF Usage Meter 9.0 регистрация в консоли VCF Business Services автоматически создаёт выделенное OAuth-приложение и генерирует уникальный токен для каждого экземпляра Usage Meter. Поставщики услуг (VCSP) используют этот токен при установке или обновлении апплаенса VCF Usage Meter 9.0. После установки Usage Meter безопасно обменивается данными с консолью через этот токен OAuth.
Этот шаг обязателен для соответствия требованиям безопасности и не может быть обойдён. VCSP могут управлять своими OAuth-токенами напрямую через консоль VCF Business Services — в том числе отзывать доступ и обновлять токены в соответствии с внутренними политиками безопасности.
Все эти операции доступны в формате самообслуживания через RESTful API. Подробности см. в документации по API.
3. Поддержка измерения и расчёта превышения по vDefend Add-On
Чтобы помочь VCSP в полной мере использовать гибкость модели потребления, Broadcom добавила поддержку измерения и расчёта превышений (overage billing) для дополнений VMware vDefend, которые теперь интегрированы в VCF Usage Meter 9.0.
Как и для основных продуктов VCF, VCSP теперь могут легко использовать следующие дополнения vDefend Firewall по модели с фиксированным контрактом и с учётом превышения:
VMware vDefend Firewall
VMware vDefend Firewall с расширенной защитой от угроз (Advanced Threat Prevention)
Чтобы начать измерение, просто добавьте конечную точку NSX Manager в VCF Usage Meter 9.0. Использование будет отслеживаться и управляться через Hourly Usage Report, доступный в консоли VCF Business Services. Нажмите здесь для получения подробной информации о метеринге vDefend Firewall.
Уже являетесь VCSP с активным контрактом на vDefend? Вы можете немедленно начать измерение, обновившись до VCF Usage Meter 9.0. Убедитесь, что вы используете лицензионные ключи Broadcom, выданные через портал Broadcom Consumption — они необходимы для точного измерения и корректного биллинга.
4. Важное уведомление: соответствие требованиям и точность расчётов с NSX
Устаревшие лицензионные ключи VMware NSX больше не поддерживаются для измерения. Их дальнейшее использование может привести к ошибкам в расчетах и несоответствию требованиям программы VCSP. Также устаревшие версии NSX и просроченные лицензии могут непреднамеренно активировать измерение vDefend из-за существующих конфигураций сетевого экрана.
Чтобы избежать неожиданных начислений и обеспечить корректное измерение в VCF Usage Meter 9.0, настоятельно рекомендуется проверить окружение NSX перед обновлением.
5. Поддержка новой консоли VCF Business Services для управления Usage Meter
Важное обновление для VCSP: управление VCF Usage Meter теперь осуществляется через новую консоль VCF Business Services — единую платформу, созданную для упрощения операций и взаимодействия с поддержкой.
Консоль VCF Business Services тесно интегрирована с экосистемой поддержки Broadcom и предлагает:
Единый вход (SSO) во все сервисы Broadcom
Упрощённое управление пользователями и доступом через Broadcom Site ID
Плавную интеграцию между сайтом и клиентом (tenant), упрощающую управление правами и операциями
6. Новый отчёт Customer Hourly Usage Report (CHUR)
В рамках этого перехода все существующие учётные записи и зарегистрированные конфигурации VCF Usage Meter из текущей консоли VMware Cloud Services будут перенесены в новую платформу VCF Business Services. Сохранятся знакомые процессы регистрации, генерации отчётов и использования API-интеграций — теперь с улучшенным и более масштабируемым интерфейсом.
Почему версия Usage Meter 9.0 так важна для VCSP?
Важно подчеркнуть, что VCF Usage Meter 9.0 полностью поддерживает измерение использования ресурсов (Core Utilization) в частном облаке VMware Cloud Foundation с использованием лицензионных ключей Broadcom — его использование абсолютно необходимо для корректного измерения среды. Поэтому критически важно либо обновить ваш текущий экземпляр Usage Meter до версии VCF Usage Meter 9.0, либо развернуть новый экземпляр, работающий на этой версии.
Для соблюдения требований у вас есть 90 дней — до 5 августа 2025 года, чтобы обновить все экземпляры Usage Meter до новой версии VCF Usage Meter 9.0.
Другие важные обновления
1. Миграция в консоль VCF Business Services
Одновременно с выходом VCF Usage Meter 9.0 в статус General Availability (GA), станет доступной новая консоль VCF Business Services. Более подробную информацию можно найти на странице портала VCSP, в разделе "VCF Cloud Console Migration Updates".
Пожалуйста, ознакомьтесь со следующими материалами:
Примечание: если у вас возникают проблемы с доступом, войдите в партнёрский портал Broadcom через вашу учётную запись OKTA, затем перейдите в "Learning@Broadcom" и выполните поиск по запросу "Cloud Console training for VCSP Pinnacle and Premier Partners", как показано на скриншоте ниже:
Обновление лимита на количество ядер (Core Cap Update)
Начиная с 12 мая 2025 года, для всех поставщиков облачных услуг VMware (VCSP) количество загружаемых лицензионных ключей будет ограничено максимумом в 200% от заявленного объема (commit), чтобы сохранить гибкость бизнес-моделей и возможность сверхнормативного использования (overage).
Пример: если вы законтрактованы на 10 000 ядер VMware Cloud Foundation (VCF), то с 12 мая общее количество созданных лицензионных ключей по данному обязательству будет ограничено 20 000 ядрами VCF.
Это изменение не повлияет на уже сгенерированные ядра, но будет препятствовать генерации дополнительных лицензий, если установленный лимит по конкретному контракту достигнут.
Путь обновления до VCF Usage Meter v9.0
Проверьте возможные пути обновления до VCF Usage Meter 9.0 по этой ссылке.
Другие полезные ресурсы
Чтобы узнать больше о VCF Usage Meter 9.0, воспользуйтесь следующими материалами:
Агентный ИИ (Agentic AI) больше не футуристическая мечта — он уже здесь и стремительно становится необходимостью для компаний, стремящихся ускорить инновации, повысить эффективность и обогнать конкурентов. Согласно исследованию IDC, более 50% корпоративного рынка приложений уже используют AI-ассистентов или советников, а около 20% — полноценных AI-агентов.
Компании, ранее воспользовавшиеся возможностями генеративного AI (GenAI) по обработке запросов, теперь переключают внимание на агентный AI — системы, которые автономно выполняют задачи в заданных рамках, повышая эффективность и снижая издержки. Однако реализация таких решений пока остаётся сложной. Один из опросов показал, что 46% проектов на стадии концепции так и не доходят до промышленного внедрения. Причина? Корпоративный AI требует интеграции с трудносовместимыми компонентами: разрозненными источниками данных и устоявшимися бизнес-процессами. Создание действительно полезных инструментов, таких как виртуальные помощники корпоративного уровня, требует координации этой сложной экосистемы данных, инструментов, моделей и систем управления — непростая задача для компаний, только начинающих осваивать AI.
Платформа Tanzu решает эту задачу, упрощая разработку и развёртывание приложений за счёт встроенного доступа и контроля к ключевым сервисам данных, инструментам для разработчиков, системам управления и брокерам моделей. Эта платформа как услуга (PaaS), оптимизированная под частные облака, позволяет предприятиям использовать возможности GenAI и агентного AI. С Tanzu предприятия могут дополнять критически важные бизнес-приложения информированными, обоснованными ответами на естественном языке или быстро создавать новые приложения и агентов, безопасно интегрируя собственные данные и системы. Это стало возможным благодаря продвинутым AI-функциям Tanzu, таким как планирование, использование инструментов, память и цепочки действий, позволяющим превращать идеи в готовый к развёртыванию код за считанные минуты.
В результате предприятия получают простой способ создать более безопасные и масштабируемые решения на базе GenAI и агентного AI, соответствующие корпоративным требованиям и стандартам комплаенса. На недавнем мероприятии Racing Toward AI App Delivery with Tanzu: Navigating the Fast Lane with Intelligence сотрудники VMware обсудили последние тренды в сфере AI:
Перспективы агентного AI
Начнём с определения агентного AI. Это тип искусственного интеллекта, который не просто отвечает на запросы, но и способен автономно выполнять задачи и предпринимать действия на основе пользовательского ввода или условий окружающей среды. В то время как традиционный генеративный AI работает по модели «только для чтения» — то есть выдаёт ответы, предложения или прогнозы — агентный AI поднимает взаимодействие на новый уровень, выполняя задачи самостоятельно.
Агентный AI становится возможным благодаря добавлению к генеративному AI дополнительного уровня интеллекта. Когда поступает запрос, агентный AI проходит многоэтапный процесс, используя доступные знания и инструменты. Сначала система анализирует запрос и разбивает его на мелкие, выполнимые задачи; затем она самостоятельно выполняет эти задачи — вызывая API, обращаясь к микросервисам или исполняя код; в завершение AI оценивает результаты своих действий (часто с участием человека в процессе) и при необходимости вносит корректировки, чтобы добиться нужного результата.
Например, представим сценарий с использованием агентного AI при обработке страхового случая: при подаче заявления агент координирует работу нескольких AI-модулей — один использует компьютерное зрение для анализа фотографий повреждений, другой применяет обработку естественного языка (NLP) для извлечения данных из форм и отчётов об аварии.
Инновационность этого подхода заключается в способности агента самостоятельно решать, к каким корпоративным системам обратиться для получения информации о полисе, как интерпретировать сложные правила покрытия и когда применять определённую бизнес-логику. Система активирует движок принятия решений, который сопоставляет параметры полиса с данными о происшествии, а также задействует AI для выявления мошенничества, сравнивая случай с тысячами исторических паттернов. В простых, стандартных случаях агент сам принимает решение об одобрении, рассчитывает выплаты с использованием предиктивных моделей и инициирует процесс оплаты — при этом на каждом этапе сохраняется возможность участия человека для проверки или вмешательства. Такой подход с участием человека в процессе («human-in-the-loop») обеспечивает контроль, при этом позволяя AI эффективно обрабатывать рутинные случаи от начала до конца.
Для достижения такой продвиной функциональности агентному AI необходимо больше, чем просто базовый генеративный инструментарий. Приложения с агентным AI требуют фреймворка для управления контекстом и памятью между сессиями, а также системы для управления API-запросами и интеграции различных сервисов — всё это предоставляет платформа VMware Tanzu.
Чтобы повысить доступность и масштабируемость разработки агентных решений для корпоративных клиентов, осенью 2024 года компания Anthropic, один из лидеров в области AI, опубликовала Model Context Protocol (MCP) — стандарт, описывающий, как AI-модели могут взаимодействовать с внешними инструментами и источниками данных. Вскоре после этого команда Tanzu Spring создала MCP Java SDK — реализацию MCP на Java. Этот SDK стал официальной реализацией MCP на Java.
В результате разработчики на Java теперь могут создавать или использовать существующие сторонние MCP-серверы, с которыми смогут взаимодействовать агентные системы. Это устраняет необходимость в сложных, кастомных и жёстко прописанных связях между системами, которые могли бы добавлять месяцы к срокам разработки.
Начинайте уже сейчас c теми разработчиками, что есть
Многие руководители обеспокоены нехваткой навыков программирования AI в своих организациях. VMware старается решать эту вполне реальную проблему, не требуя от корпоративных разработчиков переобучения, а приходя к ним на том уровне, где они уже находятся.
В течение последнего года в VMware внедряли новейшие технологии AI для корпоративных Java-разработчиков с помощью Spring AI — неотъемлемой части платформы Tanzu. Поскольку многие Java-разработчики используют Spring, Spring AI играет ключевую роль в реализации бизнес-ценности: разработчики могут добавлять AI-возможности в свои приложения, не изучая новые языки или инструменты. Можно сказать, что VMware превращает Java-разработчиков в разработчиков агентных систем. Компания предоставляет все возможности проверенной и зрелой PaaS-платформы, помогая быстро переходить от идеи к коду и далее — к продакшену, при этом инструменты для обеспечения безопасности, соответствия требованиям и масштабируемости уже встроены. Это означает более быстрые итерации, меньше доработок и более быструю окупаемость.
Разработка AI-приложений — это глубоко итеративный процесс, поэтому те, кто начинает раньше, быстрее получают важные инсайты, могут добавлять продвинутые AI-функции в приложения и сохранять лидерство за счёт постоянных инноваций.
Но для инноваций нужна прочная основа. Без платформы, которая берёт на себя AI-операции второго уровня — такие как безопасность, контроль и масштабируемость — разработчики вынуждены тратить время на рутинные задачи. Tanzu Platform помогает снять это бремя, чтобы разработчики могли сосредоточиться на главном: превращении идей в код и доставке этого кода в продакшен.
Платформа Tanzu помогает бизнесу идти в ногу с эволюцией AI
Агентный AI стремительно развивается и преобразует как бизнес, так и клиентский опыт. Средствами платформы Tanzu компания VMware предлагает клиентам способ быстро начать работу, чтобы они могли экспериментировать, учиться и развивать свою стратегию создания AI-приложений. Ключ к успеху — это быстрая доставка и обучение через практику. Такой подход не только помогает находить ценные инсайты, но и способствует перестройке организационных процессов для более глубокой и эффективной интеграции AI.
Многие клиенты VMware уже имеют доступ к этим возможностям — через Spring AI или GenAI Tile, в зависимости от текущих условий их подписки. Загляните на сайт Tanzu AI Solutions, чтобы узнать больше.
Возможно, вас смутило выражение «ВМ на голом железе» в заголовке. Но это не опечатка: в этом посте мы расскажем о двух ключевых вещах, а основная тема, которую мы рассмотрим — это запуск виртуальных машин (ВМ) как контейнеров в среде Kubernetes. Поэтому в этой статье будет две основные цели:
Раскрыть преимущества запуска ВМ и контейнеров на единой платформе. Да, этой единой платформой является служба vSphere Kubernetes Service в VMware Cloud Foundation.
Объяснить, почему запуск ВМ и контейнеров на «голом железе» имеет реальные недостатки для предприятий, чтобы вы могли сделать собственные выводы. Мы приведем факты, которые вы сможете проверить независимо от каких-либо поставщиков.
Начнём с того, что разберёмся, что такое служба vSphere Kubernetes Service (далее — VKS) и что она предлагает.
Что такое VKS?
VKS — это промышленный Kubernetes-рантайм от VMware, сертифицированный и совместимый с CNCF (Cloud Native Computing Foundation). Он включён в состав VMware Cloud Foundation (то есть доплачивать за него не нужно), поддерживается и уже доступен.
Если вы сейчас используете Kubernetes у одного из крупных облачных провайдеров или раньше пробовали запускать Kubernetes на vSphere, VKS стоит вашего внимания. Он изначально разрабатывался с учётом потребностей крупных предприятий — включая более простой процесс установки, возможности самообслуживания и наличие всех привычных компонентов, которые ожидают пользователи Kubernetes.
Это даёт клиентам беспрецедентные возможности запускать промышленный Kubernetes у себя на площадке — в более удобной и масштабируемой форме.
Кроме того, для приверженцев философии FOSS (свободного и открытого ПО) есть над чем задуматься:
За последнее десятилетие VMware входила в тройку крупнейших участников по объёму вклада в исходный код Kubernetes.
Соответствие стандарту CNCF означает, что VMware придерживается открытых стандартов. Это важно, поскольку вы получаете гибкость и можете рассчитывать на определённый набор компонентов в платформе, не попадая в ловушку специфических для конкретного вендора решений и ограничений.
VKS развивался с тех пор, как VMware приобрела компанию Pivotal в 2019 году, так что это далеко не «версия 1.0».
Несколько слов о vSphere Supervisor
Чтобы начать использовать VKS, вам нужно установить vSphere Supervisor. Он предоставляет, помимо прочего, возможность использовать все преимущества VMware, а также предлагает компоненты, совместимые с Kubernetes.
Один из примеров: как только vSphere Supervisor будет запущен, вы создаёте пространство имен Kubernetes Namespace, которое будет сопоставлено с пулом ресурсов vSphere. Внутри кластера Kubernetes Namespace будет вести себя так, как и положено, но при этом его ресурсами можно также управлять через интерфейс vSphere для пулов ресурсов.
Другой пример: управляющие и рабочие узлы Kubernetes в буквальном смысле являются виртуальными машинами (ВМ). Это важно для следующего момента, который будет раскрыт далее.
Обратите внимание: «традиционные» виртуальные машины продолжают работать бок о бок с вашими кластерами Kubernetes. Именно такую возможность даёт VKS в составе VMware Cloud Foundation (VCF).
Если вы запомните только одну вещь из этого поста, пусть это будет следующее:
Вашим текущим инженерам VMware не нужно обладать специальными знаниями о Kubernetes, чтобы управлять как виртуальными машинами, так и потребляемыми компонентами Kubernetes или самими кластерами. Инженеры платформ или разработчики могут получать доступ через инструменты самообслуживания, а инженеры по виртуализации продолжают управлять инфраструктурой так же, как и раньше.
Развенчиваем миф о запуске ВМ и контейнеров на «голом железе»
Интересный факт: когда вы разворачиваете кластер Kubernetes у гиперскейлера (большой публичный облачный провайдер), этот кластер на самом деле работает на наборе виртуальных машин под управлением гипервизора. Это справедливо для всех гиперскейлеров на момент написания статьи. Контейнеры, в итоге, не работают напрямую на голом железе — такого просто не существует. VMware подчеркивает это, потому что они видели, как и C-level руководители, и разработчики, и даже инженеры платформ (которые вроде бы должны это знать) были поражены этим фактом.
Более того, не упомянуть ещё один момент было бы упущением: когда вы создаёте виртуальную машину у гиперскейлера, она тоже работает на гипервизоре. То, что вы его не видите — не значит, что его нет.
В результате организации начинают задумываться о:
запуске контейнеров напрямую на голом железе;
запуске традиционных ВМ в виде контейнеров на голом железе.
Начнём с первого: запуск контейнеров на голом железе мог бы быть темой горячих споров… если бы сейчас был 2017 год. Эта дискуссия в индустрии уже была, и виртуализированная платформа с Kubernetes одержала убедительную победу.
Почему? В числе причин: более простое управление, масштабируемость, гибкость, меньшая стоимость и практически полное отсутствие потерь в производительности. Не сказать, что у контейнеров на железе совсем нет применения, но для 98% организаций запуск контейнеров на гипервизоре оказался более выгодным решением.
Простой пример: вспомните, какие возможности даёт вам архитектура отказоустойчивости vSphere HA — ваши контейнеры в виде ВМ отлично вписываются в эту архитектуру уже на этом одном примере.
Или другими словами: запуск контейнеров рядом с ВМ на VMware обходится дешевле, при этом вы сохраняете тот же уровень отказоустойчивости, надёжности и высокой производительности, к которому вы привыкли для технологий VMware.
А как насчёт запуска ВМ как контейнеров? Во-первых, у VMware есть доказательства того, что их платформа обеспечивает лучшую производительность и масштабируемость. Например, при создании ВМ через VM Service, инженеру не нужно разбираться в деталях и компонентах Kubernetes. Обычно это лучшее решение, потому что командам не нужно проходить дорогостоящее переобучение или нанимать более дорогих специалистов, чтобы запускать ВМ внутри кластера Kubernetes.
Когда вы увидите, насколько просто получить низкую совокупную стоимость владения (TCO) с промышленной виртуализацией, которую легко внедрить (и снова напомним про vSphere HA, которая настраивается буквально двумя кликами), становится очевидно: запуск VKS в составе VCF — разумное и эффективное решение.
1. Увеличение минимального объёма лицензии к закупке до 72 ядер и откат обратно к 16
Broadcom продолжает переход на модель подписки для продуктов VMware (не все крупные копании еще перешли на эту модель). Также теперь лицензии предоставляются на основе количества ядер процессора, а не сокетов сервера. При этом минимальный объём лицензии на продукт VMware vSphere Foundation (VVF) недавно должен был быть увеличен с 16 до 72 ядер (то есть минимальный объем заказа). Это означало бы, что даже если у клиента, например, 3 односокетных сервера с 16 ядрами в каждом процессоре, он был бы вынужден приобрести лицензию на 72 ядра, а не 48 как раньше (минимально можно было купить лицензию на 16 ядер на каждый из сокетов серверов). Для небольших компаний и удалённых офисов это привело бы к значительному увеличению затрат.
Напомним основные правила лицензирования VMware vSphere Foundation, которые продолжают действовать:
1. Минимальный объем лицензий на один сокет сервера - 16 ядер.
2. Если на каждом сервере 2 сокета по 12 ядер (24 ядра на сервер) и таких серверов у вас 3, то нужно будет 6 лицензий на 16 ядер каждая (то есть, 96).
3. Если у вас в процессорах серверов более 16 ядер, то вам нужно число процессоров просто умножить на число ядер, чтобы получить необходимое количество лицензий.
4. Если у вас, например, лицензированы 10 односокетных хостов, и вы заменили 16-ядерные CPU на 24 ядерные, то вам нужно докупить (24-16)*10=80 лицензий.
После объявления о повышении минимального количества ядер до 72, Broadcom столкнулась с критикой со стороны клиентов и партнёров. Многие выражали обеспокоенность тем, что это изменение негативно скажется на малом и среднем бизнесе. В результате компания то ли отменила это решение, то ли его и не было (см. комментарии) и сохранила прежний минимум в 16 ядер (в Broadcom отрицают, что вообще анонсировали это). Но мы еще подождем официальных анонсов на эту тему.
2. Штраф за просрочку продления лицензии
Теперь за несвоевременное продление лицензии предусмотрен штраф в размере 20% от стоимости первого года подписки. Этот штраф применяется ретроспективно, что может привести к неожиданным дополнительным расходам для клиентов.
Партнёры и клиенты выражают обеспокоенность новыми условиями. Многие рассматривают альтернативы, такие как Microsoft Hyper-V, Proxmox и Scale Computing, особенно для небольших и средних предприятий. Партнёры VMware отмечают, что новые условия могут оттолкнуть клиентов с небольшими инфраструктурами, которые ранее были основой клиентской базы VMware.
Кстати, смотрите, как выглядит сайт Scale Computing:
VMware Cloud Foundation (VCF) — это полноценное решение для частного облака, которое интегрирует программно-определяемые вычисления, хранилища данных и сетевые ресурсы вместе с инструментами автоматизации и управления облаком. Компонент VCF — VMware Cloud Foundation Operations (VCF Operations) — предоставляет организациям возможность видеть свою инфраструктуру, оптимизировать планирование емкости и ресурсов, отслеживать производительность и контролировать состояние инфраструктуры.
Для поставщиков облачных сервисов VMware Cloud Service Providers (VCSP) крайне важно сохранять финансовую прозрачность перед своими клиентами, одновременно оптимизируя операционные расходы. VMware Chargeback, который теперь является частью VCF Operations (ранее известного как VMware Aria Operations), позволяет провайдерам VCSP распределять и возмещать стоимость облачных ресурсов и услуг между пользователями или подразделениями, которые их используют. VMware Cloud Director (VCD) помогает VCSP управлять несколькими арендаторами на одной и той же инфраструктуре. Chargeback использует эту структуру на уровне арендаторов для точного учета затрат.
О продукте VMware Chargeback
VMware Chargeback разработан, чтобы помочь провайдерам VCSP отслеживать использование ресурсов и применять точные модели расчета стоимости для выставления счетов арендаторам. Он бесшовно интегрируется с VCD и другими многопользовательскими средами, обеспечивая точную финансовую отчетность. Chargeback помогает управлять затратами на ИТ-ресурсы и выставлять счета для различных подразделений, бизнес-единиц и клиентов. Благодаря поддержке мощных инструментов и четко определенных политик, он обеспечивает прозрачное, справедливое и легко понимаемое управление расходами на облачные сервисы.
Ключевые возможности:
Автоматизированное распределение затрат: Chargeback назначает стоимость на основе фактического потребления вычислительных ресурсов, хранилищ данных и сетевых ресурсов каждым арендатором, позволяя им отслеживать свои ИТ-расходы и подтверждать начисления через анализ использования. Отчеты можно настроить для отображения затрат на виртуальную машину, приложение или услугу.
Поддержка многопользовательских сред: VCSP могут предлагать своим арендаторам различные модели биллинга, что усложняет процесс отслеживания, распределения и выставления счетов. Chargeback помогает согласовать разные ценовые модели и обеспечить корректное распределение затрат на уровне арендаторов в VMware Cloud Director. Администраторы могут включить для арендаторов дэшборды самообслуживания, где те будут видеть только свои виртуальные машины, рабочие нагрузки и компоненты инфраструктуры.
Гибкие модели ценообразования: Chargeback поддерживает фиксированную, переменную и многоуровневую структуры цен:
Фиксированная модель: стоимость заранее определена и не зависит от объема использования ресурсов, что обеспечивает предсказуемость бюджета.
Переменная модель: стоимость зависит от фактического использования ресурсов, стимулируя эффективное потребление.
Многоуровневая модель: предполагает скидки при увеличении потребления ресурсов, что выгодно при масштабировании.
Пользовательские отчеты и панели: Chargeback позволяет использовать готовые шаблоны или создавать собственные отчеты для отслеживания нужных метрик, а также настраивать их плановое создание. В реальном времени доступны визуальные дэшборды с графиками, диаграммами, тепловыми картами и т.д., что помогает выявлять тенденции в данных. Можно настраивать оповещения на основе пороговых значений для отдельных арендаторов. Поддерживается мониторинг на уровне кластера с агрегированным использованием ресурсов. Среди доступных инструментов — дэшборды памяти, хранилищ, использования сети, виртуальных машин, сводные дэшборды арендаторов и другие.
Интеграция со сторонними системами: Chargeback интегрируется с внешними платформами биллинга, такими как SAP, Oracle и другими, через API для автоматизации создания биллинговых тикетов и счетов. Организации могут извлекать данные из Chargeback для своих систем аналитики или передавать туда запросы. Пакеты управления позволяют интегрировать внешние среды вроде AWS, Azure и другие, чтобы активировать возможности Chargeback в рамках VCF Operations и отслеживать затраты.
Основные моменты интеграции Chargeback
Оптимизация настроек управления арендаторами: VCSP должны убедиться, что плагин Aria Operations включен для их арендаторов. Он обеспечивает видимость операций в облаке и дает арендаторам инструменты для мониторинга, управления и оптимизации своей деятельности. После активации появляется возможность настраивать пользовательский опыт арендаторов.
Тонкая настройка пользовательского опыта: администраторы могут настраивать представление данных и доступные метрики для арендаторов, чтобы показывать только релевантную информацию и минимизировать «шум». Они также управляют доступом к страницам и задают периоды хранения данных для соблюдения политик хранения.
Управление уведомлениями для арендаторов: функция настройки электронной почты позволяет VCSP создавать уведомления, оповещения и отчеты для арендаторов.
Упрощенное управление политиками: инструмент создания политик облегчает разработку и управление стратегиями ценообразования, делая биллинг арендаторов эффективным и точным. VCSP могут интуитивно определять и адаптировать политики ценообразования в зависимости от своих целей и ожиданий клиентов.
Автоматизация биллинга для финансовой точности: автоматизация процессов выставления счетов повышает точность, согласованность и эффективность расчетов. Счета могут отправляться по установленному расписанию, которое стоит регулярно пересматривать в зависимости от изменяющихся потребностей арендаторов.
Оповещения и отчеты в реальном времени: VCSP могут задавать условия для срабатывания оповещений, привязывать их к профилям арендаторов, определять каналы оповещения (email, SMS) и частоту отправки. Отчеты помогают делиться аналитикой VCD с арендаторами.
Анализ затрат для сравнительного ценообразования: пользователи могут сравнивать метрики расходов VMware Cloud между объектами, группами, приложениями и арендаторами, визуализировать данные в виде графиков и таблиц, а также сохранять результаты для дальнейшего использования.
Почему VMware Chargeback необходим VCSP
Для поставщиков услуг инфраструктура VMware Cloud Director предлагает полный набор инструментов, включая возможности настройки интеграции, управления доступом арендаторов, настройки входящих/исходящих писем арендаторов и отправки отчетов и уведомлений.
Интегрируя ключевые платформы, такие как vCenter, VCD, Cloud Director Availability и NSX, поставщики услуг могут создать целостную среду, которая упрощает и повышает точность процедур расчёта затрат (chargeback). VCSP могут использовать пакеты управления как для этих платформ, так и для других решений, соответствующих их облачной инфраструктуре управления.
1. Оптимизированное возмещение затрат и повышение прибыльности
Одна из главных задач для VCSP — обеспечить, чтобы все инфраструктурные и операционные расходы были корректно распределены между клиентами. VMware Chargeback устраняет потери дохода, предоставляя точную и автоматизированную систему распределения затрат, что обеспечивает прибыльность. Это позволяет избежать ошибок, связанных с ручным отслеживанием, и разделять затраты по отделам или клиентам. Облачные провайдеры могут дополнительно монетизировать свои предложения, используя VMware Chargeback для взимания повышенных ставок за премиальные ресурсы, такие как сети с низкой задержкой или выделенные процессорные мощности (модель ценообразования на основе выделения ресурсов).
2. Прозрачность и доверие со стороны клиентов
Клиенты ожидают получать подробную информацию о своем использовании ресурсов и начисленных платежах. VMware Chargeback предоставляет детализированные отчеты, показывающие, сколько именно стоит каждый используемый ресурс, что помогает VCSP обосновывать начисления и укреплять доверие клиентов, устраняя скрытые расходы и снижая количество споров по счетам. Арендаторы получают доступ к данным биллинга в реальном времени, что позволяет избежать неожиданных расходов. Так как оплата производится на основе фактического использования ресурсов, это способствует сокращению избыточных затрат, оптимизации рабочих нагрузок и помогает клиентам избегать расходов на неиспользуемые ресурсы.
3. Операционная эффективность и автоматизация
Ручное отслеживание затрат требует много времени и подвержено ошибкам. VMware Chargeback автоматизирует измерение использования ресурсов, снижая административную нагрузку и позволяя поставщикам услуг сосредоточиться на предоставлении дополнительных сервисов с высокой добавленной стоимостью. Это также упрощает процесс выставления счетов для большого количества клиентов. Поставщики могут более точно планировать емкость ресурсов, анализируя исторические данные из отчетов.
4. Мониторинг за пределами виртуальных машин
Пользователи могут отслеживать производительность на уровне приложений, анализируя время отклика API, нагрузку на веб-серверы и зависимости приложений, чтобы увидеть, как рабочие нагрузки взаимодействуют с VCF Operations. Также доступен мониторинг Kubernetes и контейнеров — можно отслеживать состояние узлов, сервисов и кластеров. Мониторинг сети и безопасности помогает анализировать микро-сегментацию и отслеживать сетевой трафик, задержки и другие параметры для каждого арендатора. Такая полноуровневая наблюдаемость крайне важна для VCSP при планировании и расчете затрат.
5. Поддержка частного облака
Для VCSP, предоставляющих решения частного облака, VMware Chargeback расширяет возможности частного облака, обеспечивая единое распределение затрат в таких средах, а также финансовую прозрачность и отчетность при внутреннем биллинге.
Заключение
Прозрачность облачных затрат имеет решающее значение для любой организации, а интеграция системы распределения затрат в бизнес-модель VCSP становится важнейшим фактором масштабируемости и роста. Это позволяет клиентам гибко регулировать потребление ресурсов в зависимости от спроса и платить только за фактическое использование. Пользователи могут отслеживать производительность, затраты и емкость ресурсов, что помогает им оптимизировать инвестиции в инфраструктуру. Chargeback позволяет VCSP удовлетворять потребности широкой клиентской базы, предлагая различные модели ценообразования. Арендаторы получают доступ к самообслуживаемым дэшбордам, отчетам и оповещениям, что улучшает их пользовательский опыт. Грамотно реализованная система распределения затрат становится конкурентным преимуществом для VCSP.
Узнать больше о продукте VMware Chargeback можно здесь.
vRO Code Editor Resizer — это лёгкое и полезное расширение для Google Chrome, созданное для разработчиков, работающих с VMware vRealize Orchestrator (vRO) / Aria Orchestrator и VCF Orchestrator. Оно решает распространённую проблему ограниченного пространства в редакторе скриптов, позволяя расширить область кода на весь экран и тем самым повысить удобство и продуктивность при написании и отладке скриптов.
Основные возможности
Максимизация редактора: после установки расширения на странице редактирования vRO появляется кнопка в правом нижнем углу, позволяющая развернуть редактор скриптов на весь экран. Больше пространства для кода означает меньше прокрутки и лучшую видимость, что особенно полезно при работе с длинными скриптами.
Восстановление исходного размера: кнопка также позволяет вернуть редактор к его первоначальному размеру.
Простота использования: установка и использование не требуют дополнительных настроек — достаточно установить расширение и начать работу. Разработчики отмечают, что возможность расширить редактор значительно ускоряет процесс написания и отладки кода.
Расширение весит всего около 9 КБ и не собирает пользовательские данные, что делает его безопасным и ненавязчивым инструментом.
Разбор сложного HTML — это, безусловно, непростая задача, даже с PowerShell. Вильям Лам недавно пытался использовать бесплатную версию ChatGPT и новую модель 4o, чтобы сделать функцию на PowerShell для парсинга HTML, но он постоянно сталкивался с системными ограничениями, а AI часто неправильно понимал, чего от него хотят.
По запросу одного из пользователей он пытался расширить свою статью в блоге за 2017 год об автоматизации глобальных прав vSphere и добавить поддержку их вывода через PowerCLI.
Оказалось, что получить список всех текущих глобальных прав окружения VMware vSphere через приватный API vSphere Global Permissions с помощью vSphere MOB крайне трудно из-за сложного HTML, который рендерит этот интерфейс. На самом деле, Вильяму понадобилось 25 итераций, прежде чем он нашёл рабочее решение с помощью модели ChatGPT 4o. В нескольких попытках прогресс даже откатывался назад — и это было довольно раздражающе.
В итоге, теперь есть файл GlobalPermissions.ps1, который содержит новую функцию Get-GlobalPermission. Эта функция извлекает все глобальные права vSphere, включая имя субъекта (principal), назначенную роль vSphere и то, где именно эта роль определена (глобальное право или право в рамках inventory сервера vCenter).
Ниже приведён пример использования новой функции — перед этим потребуется выполнить Connect-VIServer, чтобы можно было сопоставить ID роли vSphere, полученный из функции, с её реальным именем, которое возвращается встроенным командлетом PowerCLI.
Начиная с ноября 2024 года, VMware vSphere Foundation (VVF) начала включать 0,25 ТиБ ёмкости vSAN на одно ядро для всех новых лицензий VVF. С выходом обновления vSphere 8.0 U3e это преимущество распространяется и на существующих клиентов — теперь им также доступна ёмкость vSAN из расчёта 0,25 ТиБ (аналог терабайта) на ядро. Это новое право на использование включает дополнительные преимущества, которые повышают ценность vSAN в составе VVF.
Вот как это работает:
Ёмкость vSAN агрегируется по всей инфраструктуре, что позволяет перераспределять неиспользованные ресурсы с кластеров, содержащих только вычислительные узлы, на кластеры с включённым vSAN. Это помогает оптимизировать использование ресурсов в рамках всей инфраструктуры.
Новые преимущества для текущих клиентов:
Больше никаких ограничений пробной версии: включённые 0,25 ТиБ на ядро теперь полностью предоставлены по лицензии, а не в рамках пробного периода.
Агрегация ёмкости: объединяйте хранилище между кластерами и используйте его там, где это нужнее всего.
Упрощённое масштабирование: если требуется больше хранилища, чем предусмотрено по включённой норме — достаточно просто докупить нужный объём сверх этой квоты.
Почему это важно
Благодаря этому обновлению VMware vSphere Foundation становится ещё более привлекательным решением для организаций, стремящихся модернизировать и унифицировать свою ИТ-инфраструктуру. Поддерживая как виртуальные машины, так и контейнеры, vSAN добавляет возможности гиперконвергентной инфраструктуры (HCI) корпоративного уровня. Интеграция вычислений, хранения и управления в единую платформу упрощает операционные процессы, снижает сложность и обеспечивает комплексное решение с встроенной безопасностью и масштабируемостью.
Дополнительная ёмкость vSAN в составе VMware vSphere Foundation значительно повышает ценность платформы — будь то оптимизация частного облака, повышение гибкости разработки или упрощение ИТ-операций. Это даёт больше контроля и гибкости над инфраструктурой, снижая совокупную стоимость владения и минимизируя операционные издержки.
Чтобы начать пользоваться бесплатной лицензией VMware vSAN загрузите патч vSphere 8.0 Update 3e по этой ссылке.
Генеративный искусственный интеллект (Gen AI) стремительно трансформирует способы создания контента, коммуникации и решения задач в различных отраслях. Инструменты Gen AI расширяют границы возможного для машинного интеллекта. По мере того как организации внедряют модели Gen AI для задач генерации текста, синтеза изображений и анализа данных, на первый план выходят такие факторы, как производительность, масштабируемость и эффективность использования ресурсов. Выбор подходящей инфраструктуры — виртуализированной или «голого железа» (bare metal) — может существенно повлиять на эффективность выполнения AI-нагрузок в масштабах предприятия. Ниже рассматривается сравнение производительности виртуализованных и bare-metal сред для Gen AI-нагрузок.
Broadcom предоставляет возможность использовать виртуализованные графические процессоры NVIDIA на платформе частного облака VMware Cloud Foundation (VCF), упрощая управление AI-accelerated датацентрами и обеспечивая эффективную разработку и выполнение приложений для ресурсоёмких задач AI и машинного обучения. Программное обеспечение VMware от Broadcom поддерживает оборудование от разных производителей, обеспечивая гибкость, возможность выбора и масштабируемость при развертывании.
Broadcom и NVIDIA совместно разработали платформу Gen AI — VMware Private AI Foundation with NVIDIA. Эта платформа позволяет дата-сайентистам и другим специалистам тонко настраивать LLM-модели, внедрять рабочие процессы RAG и выполнять инференс-нагрузки в собственных дата-центрах, решая при этом задачи, связанные с конфиденциальностью, выбором, стоимостью, производительностью и соответствием нормативным требованиям. Построенная на базе ведущей частной облачной платформы VCF, платформа включает компоненты NVIDIA AI Enterprise, NVIDIA NIM (входит в состав NVIDIA AI Enterprise), NVIDIA LLM, а также доступ к открытым моделям сообщества (например, Hugging Face). VMware Cloud Foundation — это полнофункциональное частное облачное решение от VMware, предлагающее безопасную, масштабируемую и комплексную платформу для создания и запуска Gen AI-нагрузок, обеспечивая гибкость и адаптивность бизнеса.
Тестирование AI/ML нагрузок в виртуальной среде
Broadcom в сотрудничестве с NVIDIA, Supermicro и Dell продемонстрировала преимущества виртуализации (например, интеллектуальное распределение и совместное использование AI-инфраструктуры), добившись впечатляющих результатов в бенчмарке MLPerf Inference v5.0. VCF показала производительность близкую к bare metal в различных областях AI — компьютерное зрение, медицинская визуализация и обработка естественного языка — на модели GPT-J с 6 миллиардами параметров. Также были достигнуты отличные результаты с крупной языковой моделью Mixtral-8x7B с 56 миллиардами параметров.
На последнем рисунке в статье показано, что нормализованная производительность в виртуальной среде почти не уступает bare metal — от 95% до 100% при использовании VMware vSphere 8.0 U3 с виртуализованными GPU NVIDIA. Виртуализация снижает совокупную стоимость владения (TCO) AI/ML-инфраструктурой за счёт возможности совместного использования дорогостоящих аппаратных ресурсов между несколькими клиентами практически без потери производительности. См. официальные результаты MLCommons Inference 5.0 для прямого сравнения запросов в секунду или токенов в секунду.
Производительность виртуализации близка к bare metal — от 95% до 100% на VMware vSphere 8.0 U3 с виртуализированными GPU NVIDIA.
Аппаратное и программное обеспечение
В Broadcom запускали рабочие нагрузки MLPerf Inference v5.0 в виртуализованной среде на базе VMware vSphere 8.0 U3 на двух системах:
Для виртуальных машин, использованных в тестах, было выделено лишь часть ресурсов bare metal.
В таблицах 1 и 2 показаны аппаратные конфигурации, использованные для запуска LLM-нагрузок как на bare metal, так и в виртуализованной среде. Во всех случаях физический GPU — основной компонент, определяющий производительность этих нагрузок — был одинаков как в виртуализованной, так и в bare-metal конфигурации, с которой проводилось сравнение.
Бенчмарки были оптимизированы с использованием NVIDIA TensorRT-LLM, который включает компилятор глубокого обучения TensorRT, оптимизированные ядра, шаги пред- и постобработки, а также средства коммуникации между несколькими GPU и узлами — всё для достижения максимальной производительности в виртуализованной среде с GPU NVIDIA.
Конфигурация оборудования SuperMicro GPU SuperServer SYS-821GE-TNRT:
Конфигурация оборудования Dell PowerEdge XE9680:
Бенчмарки
Каждый бенчмарк определяется набором данных и целевым показателем качества. В следующей таблице приведено краткое описание бенчмарков в этой версии набора:
В сценарии Offline генератор нагрузки (LoadGen) отправляет все запросы в тестируемую систему в начале запуска. В сценарии Server LoadGen отправляет новые запросы в систему в соответствии с распределением Пуассона. Это показано в таблице ниже:
Сравнение производительности виртуализованных и bare-metal ML/AI-нагрузок
Рассмотренные SuperMicro SuperServer SYS-821GE-TNRT и сервера Dell PowerEdge XE9680 с хостом vSphere / bare metal оснащены 8 виртуализованными графическими процессорами NVIDIA H100.
На рисунке ниже представлены результаты тестовых сценариев, в которых сравнивается конфигурация bare metal с виртуализованной средой vSphere на SuperMicro GPU SuperServer SYS-821GE-TNRT и Dell PowerEdge XE9680, использующими группу из 8 виртуализованных GPU H100, связанных через NVLink. Производительность bare metal принята за базовую величину (1.0), а виртуализованные результаты приведены в относительном процентном соотношении к этой базе.
По сравнению с bare metal, среда vSphere с виртуализованными GPU NVIDIA (vGPU) демонстрирует производительность, близкую к bare metal, — от 95% до 100% в сценариях Offline и Server бенчмарка MLPerf Inference 5.0.
Обратите внимание, что показатели производительности Mixtral-8x7B были получены на Dell PowerEdge XE9686, а все остальные данные — на SuperMicro GPU SuperServer SYS-821GE-TNRT.
Вывод
В виртуализованных конфигурациях используется всего от 28,5% до 67% CPU-ядер и от 50% до 83% доступной физической памяти при сохранении производительности, близкой к bare metal — и это ключевое преимущество виртуализации. Оставшиеся ресурсы CPU и памяти можно использовать для других рабочих нагрузок на тех же системах, что позволяет сократить расходы на инфраструктуру ML/AI и воспользоваться преимуществами виртуализации vSphere при управлении дата-центрами.
Помимо GPU, виртуализация также позволяет объединять и распределять ресурсы CPU, памяти, сети и ввода/вывода, что значительно снижает совокупную стоимость владения (TCO) — в 3–5 раз.
Результаты тестов показали, что vSphere 8.0.3 с виртуализованными GPU NVIDIA находится в «золотой середине» для AI/ML-нагрузок. vSphere также упрощает управление и быструю обработку рабочих нагрузок с использованием NVIDIA vGPU, гибких соединений NVLink между устройствами и технологий виртуализации vSphere — для графики, обучения и инференса.
Виртуализация снижает TCO AI/ML-инфраструктуры, позволяя совместно использовать дорогостоящее оборудование между несколькими пользователями практически без потери производительности.
RSS
