В этой статье мы завершаем рассказывать об итогах 2025 года в сферах серверной и настольной виртуализации на базе российских решений. Сегодня мы поговорим о том, как их функционал соотносится с таковым от ведущего мирового производителя - VMware.

Первую часть статьи можно прочитать тут, вторая - доступна здесь.

Сравнение с VMware vSphere

Как же отечественные решения выглядят на фоне VMware vSphere, многолетнего эталона в сфере виртуализации? По набору функций российские платформы стремятся обеспечить полный паритет с VMware – и во многом этого уже достигли. Однако при более глубоком сравнении выявляются отличия в зрелости, экосистеме и опыте эксплуатации.

Функциональность

Почти все базовые возможности VMware теперь доступны и в отечественных продуктах: от управления кластерами, миграции ВМ на лету и снапшотов до сетевой виртуализации и распределения нагрузки. Многие платформы прямо ориентируются на VMware при разработке. Например, SpaceVM позиционирует свои компоненты как аналоги VMware: SDN Flow = NSX, FreeGRID = NVIDIA vGPU (для Horizon), Space Dispatcher = Horizon Connection Server. ZVirt, Red, ROSA, SpaceVM – все поддерживают VMware-совместимые форматы виртуальных дисков (VMDK/OVA) и умеют импортировать ВМ из vSphere.

То есть миграция технически осуществима без кардинальной переделки ВМ. Live Migration, HA, кластеры, резервирование – эти функции стали стандартом де-факто, и российские продукты их предоставляют. Более того, появились и некоторые новые возможности, которых нет в базовом издании vSphere: например, интеграция с Kubernetes (KubeVirt) в решении Deckhouse от Flant позволяет управлять ВМ через Kubernetes API – VMware предлагает нечто подобное (vSphere with Tanzu), но это отдельно лицензируемый модуль.

Другой пример – поддержка облачных сервисов: некоторые отечественные платформы сразу рассчитаны на гибридное облако, тогда как VMware требует vCloud Suite (сейчас это часть платформы VMware Cloud Foundation, VCF). Тем не менее, зрелость функционала различается: если у VMware каждая возможность отполирована годами использования по всему миру, то у новых продуктов возможны баги или ограничения. Эксперты отмечают, что просто сравнить чекбоксы “есть функция X” – недостаточно, важна реализация. У VMware она, как правило, образцовая, а у российского аналога – может требовать ручных доработок. Например, та же миграция ВМ в российских системах работает, но иногда возникают нюансы с live migration при специфических нагрузках (что-то, что VMware давно решила).

Производительность и масштабирование

VMware vSphere славится стабильной работой кластеров до 64 узлов (в v7 – до 96 узлов) и тысяч ВМ. В принципе, и наши решения заявляют сопоставимый масштаб, но проверены они временем меньше. Как упоминалось, некоторые продукты испытывали сложности уже на 50+ хостах. Тем не менее, для 90% типовых инсталляций (до нескольких десятков серверов) разницы в масштабируемости не будет. По производительности ВМ – разница тоже минимальна: KVM и VMware ESXi показывают близкие результаты бенчмарков. А оптимизации вроде vStack с 2% overhead вообще делают накладные расходы незаметными. GPU-виртуализация – здесь VMware имела преимущество (технология vGPU), но сейчас SpaceVM и другие сократили отставание своим FreeGRID. Зато VMware до последнего времени обеспечивала более широкую поддержку оборудования (драйверы для любых RAID, сетевых карт) – российские ОС и гипервизоры поддерживают далеко не все модели железа, особенно новейшие. Однако ситуация улучшается за счет локализации драйверов и использования стандартных интерфейсов (VirtIO, NVMe и пр.).

Совместимость и экосистема

Ключевое различие – в экосистеме смежных решений. Окружение VMware – это огромный пласт интеграций: сотни backup-продуктов, мониторингов, готовых виртуальных апплаенсов, специальных плагинов и т.д. В российской экосистеме такого разнообразия пока нет. Многие специализированные плагины и appliance, рассчитанные на VMware, не будут работать на отечественных платформах.

Например, виртуальные апплаенсы от зарубежных вендоров (сетевые экраны, балансировщики), выпускались в OVF под vSphere – их можно включить и под KVM, но официальной поддержки может не быть. Приходится либо искать аналогичный российский софт, либо убеждаться, что в open-source есть совместимый образ. Интеграция с enterprise-системами – тоже вопрос: у VMware был vCenter API, поддерживаемый многими инструментами. Отечественным гипервизорам приходится писать собственные модули интеграции. Например, не все мониторинговые системы «из коробки» знают про zVirt или SpaceVM – нужно настраивать SNMP/API вручную.

Такая же ситуация с резервным копированием: знакомые всем Veeam и Veritas пока не имеют официальных агентов под наши платформы (хотя Veeam частично работает через стандартный SSH/VIX). В итоге на текущем этапе экосистема поддержки у VMware гораздо более развита, и это объективный минус для новых продуктов. Однако постепенно вокруг популярных российских гипервизоров формируется своё сообщество: появляются модули для Zabbix, адаптеры для Veeam через скрипты, свои решения backup (например, CyberProtect для Cyber Infrastructure, модуль бэкапа в VMmanager и т.п.).

Надёжность и поддержка

VMware десятилетиями оттачивала стабильность: vSphere известна редкими «падениями» и чётким поведением в любых ситуациях. Российским платформам пока ещё не хватает шлифовки – пользователи отмечают, что полностью «скучной» работу с ними назвать нельзя. Периодически инженерам приходится разбираться с нетривиальными багами или особенностями. В пример приводят трудоёмкость настройки сетевой агрегации (линков) – то, что на VMware привычно, на некоторых отечественных системах реализовано иначе и требует дополнительных манипуляций.

При обновлении версий возможны проблемы с обратной совместимостью: участники рынка жалуются, что выход каждого нового релиза иногда «ломает» интеграции, требуя доработки скриптов и настроек. Отсюда повышенные требования к квалификации админов – нужно глубже понимать «под капотом», чем при работе с отлаженной VMware. Но есть и плюс: почти все российские вендоры предоставляют оперативную техподдержку, зачастую напрямую от команд разработчиков. В критических случаях они готовы выпустить патч под конкретного заказчика или дать обходной совет. В VMware же, особенно после перехода на Broadcom, поддержка стала менее клиентоориентированной для средних клиентов. В России же каждый клиент на вес золота, поэтому реакция, как правило, быстрая (хотя, конечно, уровень экспертизы разных команд разнится).

Стоимость и лицензирование

Ранее VMware имела понятную, хоть и недешёвую модель лицензирования (по процессорам, +опции за функции). После покупки Broadcom стоимость выросла в разы, а бессрочные лицензии отменены – только подписка. Это сделало VMware финансово тяжелее для многих. Отечественные же продукты зачастую предлагают более гибкие условия: кто-то лицензирует по ядрам, кто-то по узлам, у кого-то подписка с поддержкой. Но в целом ценовой порог для легального использования ниже, чем у VMware (тем более, что последняя официально недоступна, а «серыми» схемами пользоваться рискованно). Некоторые российские решения и вовсе доступны в рамках господдержки по льготным программам для госучреждений. Таким образом, с точки зрения совокупной стоимости владения (TCO) переход на отечественную виртуализацию может быть выгоден (но может и не быть), особенно с учётом локальной техподдержки и отсутствия валютных рисков.

Подведём коротко плюсы и минусы российских платформ относительно VMware.

Плюсы отечественных решений:

• Импортонезависимость и соответствие требованиям. Полное соблюдение требований законодательства РФ для госкомпаний и КИИ (реестр ПО, совместимость с ГОСТ, сертификация ФСТЭК у компонентов).
• Локальная поддержка и доработка. Возможность напрямую взаимодействовать с разработчиком, получать кастомные улучшения под свои задачи и быстро исправлять проблемы в сотрудничестве (что практически невозможно с глобальным вендором).
• Интеграция с отечественной экосистемой. Совместимость с российскими ОС (Astra, РЕД, ROSA), СУБД, средствами защиты (например, vGate) – упрощает внедрение единого импортозамещённого ландшафта.
• Новые технологии под свои нужды. Реализация специфичных возможностей: работа без лицензий NVIDIA (FreeGRID), поддержка гостевых Windows без обращения к зарубежным серверам активации, отсутствие жёсткого вендорлока по железу (любое x86 подходит).
• Стоимость и модель владения. Более низкая цена лицензий и поддержки по сравнению с VMware (особенно после удорожания VMware); оплата в рублях, отсутствие риска отключения при санкциях.

Минусы и вызовы:

• Меньшая зрелость и удобство. Интерфейсы и процессы менее отточены – администрирование требует больше времени и знаний, некоторые задачи реализованы не так элегантно, больше ручной работы.
• Ограниченная экосистема. Не все привычные внешние инструменты совместимы – придется пересматривать решения для бэкапа, мониторинга, а автоматизация требует дополнительных скриптов. Нет огромного сообщества интеграторов по всему миру, как у VMware.
• Риски масштабируемости и багов. На больших нагрузках или в сложных сценариях могут всплывать проблемы, которые VMware уже давно решила. Требуется тщательное пилотирование и возможно компромиссы (уменьшить размер кластера, разделить на несколько и др.).
• Обучение персонала. ИТ-специалистам, годами работавшим с VMware, нужно переучиваться. Нюансы каждой платформы свои, документация не всегда идеальна, на русском языке материалов меньше, чем англоязычных по VMware.
• Отсутствие некоторых enterprise-фишек. Например, у VMware есть многолетние наработки по гибридному облаку, экосистема готовых решений в VMware Marketplace. Российским аналогам предстоит путь создания таких же богатых экосистем.

Таким образом, при функциональном паритете с VMware на бумаге, в практической эксплуатации российские продукты могут требовать больше усилий и доставлять больше проблем. Но этот разрыв постепенно сокращается по мере их развития и накопления опыта внедрений.

Выводы и перспективы импортозамещения VMware

За почти четыре года, прошедшие с ухода VMware, российская индустрия виртуализации совершила огромный рывок. Из десятков появившихся решений постепенно выделился костяк наиболее зрелых и универсальных продуктов, способных заменить VMware vSphere в корпоративных ИТ-инфраструктурах. Как показывают кейсы крупных организаций (банков, промышленных предприятий, госструктур), импортозамещение виртуализации в России – задача выполнимая, хотя и сопряжена с определёнными трудностями. Подводя итоги обзора, можно назвать наиболее перспективные платформы и технологии, на которые сегодня стоит обратить внимание ИТ-директорам:

• SpaceVM + Space VDI (экоcистема Space) – комплексное решение от компании «ДАКОМ M», которое отличается максимальной полнотой функционала. SpaceVM обеспечивает производительную серверную виртуализацию с собственными технологиями (SDN, FreeGRID), а Space VDI дополняет её средствами виртуализации рабочих мест. Этот тандем особенно хорош для компаний, которым нужны все компоненты "как у VMware" под одним брендом – гипервизор, диспетчеры, клиенты, протоколы. Space активно набирает популярность: 1-е место в рейтингах, успешные внедрения, награды отрасли. Можно ожидать, что он станет одним из столпов корпоративной виртуализации РФ.
• Basis Dynamix – продукт компании «Базис», ставший лидером технических рейтингов. Basis привлекает госзаказчиков и большие корпорации, ценящие интегрированный подход: платформа тесно сопряжена с отечественным оборудованием, ОС и имеет собственный центр разработки. Ее козыри – высокая производительность, гибкость (поддержка и классической, и HCI-схем) и готовность к кастомизации под клиента. Basis – хороший выбор для тех, кто строит полностью отечественный программно-аппаратный комплекс, и кому нужна платформа с длительной перспективой развития в России.
• zVirt (Orion soft) – одна из самых распространённых на практике платформ, обладающая богатым набором функций и сильным акцентом на безопасность. За счет происхождения от oVirt, zVirt знаком многим по архитектуре, а доработки Orion soft сделали его удобнее и безопаснее (SDN, микросегментация, интеграция с vGate). Крупнейшая инсталляционная база говорит о доверии рынка. Хотя у zVirt есть ограничения по масштабированию, для средних размеров (десятки узлов) он отлично справляется. Это надежный вариант для постепенной миграции с VMware в тех организациях, где ценят проверенные решения и требуются сертификаты ФСТЭК по безопасности.
• Red Виртуализация – решение от РЕД СОФТ, важное для госсектора и компаний с экосистемой РЕД ОС. Его выбрал, к примеру, Россельхозбанк для одной из крупнейших миграций в финансовом секторе. Продукт относительно консервативный (форк известного проекта), что можно считать плюсом – меньше сюрпризов, более понятный функционал. Red Virtualization перспективна там, где нужна максимальная совместимость с отечественным ПО (ПО РЕД, СУБД РЕД и пр.) и официальная поддержка на уровне регуляторов.
• vStack HCP – хотя и более нишевое решение, но весьма перспективное для тех, кому нужна простота HCI и высочайшая производительность. Отсутствие зависимости от громоздких компонентов (ни Linux, ни Windows – гипервизор на FreeBSD) дает vStack определенные преимущества в легковесности. Его стоит рассматривать в том числе для задач на периферии, в распределенных офисах, где нужна автономная работа без сложной поддержки, или для быстрорастущих облачных сервисов, где горизонтальное масштабирование – ключевой фактор.
• HostVM VDI / Veil / Termidesk – в сфере VDI помимо Space VDI, внимания заслуживают и другие разработки. HostVM VDI – как универсальный брокер с множеством протоколов – может подойти интеграторам, строящим сервис VDI для разных платформ. Veil VDI и Termidesk – пока чуть менее известны на рынке, но имеют интересные технологии (например, Termidesk с собственным кодеком TERA). Для компаний, уже использующих решения этих вендоров, логично присмотреться к их VDI для совместимости.

В заключение, можно уверенно сказать: российские продукты виртуализации достигли уровня, при котором ими можно заменить VMware vSphere во многих сценариях. Да, переход потребует усилий – от тестирования до обучения персонала, – но выгоды в виде независимости от внешних факторов, соответствия требованиям законодательства и поддержки со стороны локальных вендоров зачастую перевешивают временные сложности. Российские разработчики продемонстрировали способность быстро закрыть функциональные пробелы и даже внедрить новые инновации под нужды рынка. В ближайшие годы можно ожидать дальнейшего роста качества этих продуктов: уже сейчас виртуализация перестает быть "экзотикой" и становится обыденным, надёжным инструментом в руках отечественных ИТ-специалистов. А значит, корпоративный сектор России получает реальную альтернативу VMware – собственный технологический базис для развития ИТ-инфраструктуры.

В новом видео на канале Gnan Cloud Garage подробно разобраны ключевые отличия между VMware Cloud Foundation (VCF) версии 5.2 и VCF 9.0, причем автор подчеркивает: речь идёт не о простом обновлении, а о кардинальной архитектурной переработке платформы.

VCF — это флагманская платформа частного облака от компании VMware, объединяющая вычисления, сеть, хранилище, безопасность, автоматизацию и управление жизненным циклом в едином программно-определяемом стеке. В версии 9.0 VMware делает шаг в сторону «облачного» подхода, ориентированного на масштаб, автоматизацию и гибкость.

Основные отличия VCF 5.2 и VCF 9.0

1. Модель развертывания

• VCF 5.2: установка строилась вокруг SDDC Manager и требовала загрузки Cloud Builder размером около 20 ГБ. Развёртывание компонентов происходило последовательно.
• VCF 9.0: представлен новый VCF Installer (~2 ГБ) и fleet-based модель. Это обеспечивает более быстрое развертывание, модульную архитектуру и гибкость с первого дня.

Результат: ускорение внедрения и переход от монолитного подхода к модульному.

2. Управление жизненным циклом (LCM)

• VCF 5.2: весь LCM был сосредоточен в SDDC Manager.
• VCF 9.0: управление разделено между Fleet Management Appliance и SDDC Manager.
  
  
• Fleet Management отвечает за операции, автоматизацию и управление идентификацией.
• SDDC Manager фокусируется на базовой инфраструктуре.

Результат: параллельные обновления, меньшее время простоя и более точный контроль.

3. Управление идентификацией

• VCF 5.2: использовались Enhanced Linked Mode и vCenter Identity.
• VCF 9.0: внедрены VCF Single Sign-On и VCF Identity Broker, обеспечивающие единую систему идентификации для всех компонентов.

Результат: действительно унифицированная и современная модель identity management.

4. Лицензирование

• VCF 5.2: традиционные лицензии — по продуктам и ключам (vSphere, NSX, vSAN, Aria).
• VCF 9.0: keyless subscription model — без ключей, с подпиской.

Результат: упрощённое соответствие требованиям, обновления и соответствие современным облачным моделям потребления.

5. Операции и мониторинг

• VCF 5.2: VMware Aria Operations — опциональный компонент.
• VCF 9.0: операции встроены по умолчанию, обеспечивая fleet-wide мониторинг и compliance «из коробки».

6. Автоматизация

• VCF 5.2: автоматизация была дополнительной опцией.
• VCF 9.0: решение VCF Automation встроено и оптимизировано для:

• AI-нагрузок
• Kubernetes
• виртуальных машин

Результат: платформа самообслуживания, полностью готовая для разработчиков.

• VCF 5.2: NSX — опциональный компонент.
• VCF 9.0: NSX становится обязательным для management и workload-доменов.

Результат: единая программно-определяемая сетевая архитектура во всей среде VCF.

8. Хранилище

• VCF 5.2: поддержка vSAN, NFS и Fibre Channel SAN.
• VCF 9.0: акцент на vSAN ESA (Express Storage Architecture) и Original Storage Architecture, с планами по расширению поддержки внешних хранилищ.

Результат: фундамент для более современной и производительной storage-архитектуры.

9. Безопасность и соответствие требованиям

• VCF 5.2: ручное управление сертификатами и патчами.
• VCF 9.0: встроенные средства управления:
  
  
  • унифицированное управление ключами
  • live patching
  • secure-by-default подход

Результат: серьёзная модернизация безопасности и Zero Trust по умолчанию.

10. Модель обновлений

• VCF 5.2: последовательные апгрейды.
• VCF 9.0: параллельные обновления с учётом fleet-aware LCM.

Результат: меньше простоев и лучшая предсказуемость обслуживания.

11. Kubernetes и контейнеры

• VCF 5.2: ограниченная поддержка Tanzu.
• VCF 9.0: нативный Kubernetes через VCF Automation.

Результат: единая платформа для VM и Kubernetes — полноценная application platform.

12. Импорт существующих сред

• VCF 5.2: импорт существующих vSphere/vCenter не поддерживался.
• VCF 9.0: можно импортировать существующие окружения как management или workload-домены.

Результат: упрощённая миграция legacy-нагрузок в современное частное облако.

Итог

VCF 5.2 — это классическая платформа частного облака с опциональными возможностями, ну а VCF 9.0 — это современное, cloud-like частное и гибридное облако, ориентированное на масштабирование, автоматизацию и управление флотом инфраструктуры.

Как подчёркивает автор видео, VCF 9.0 — это не апгрейд, а полноценный редизайн, нацеленный на лучший пользовательский опыт и соответствие требованиям современных enterprise и облачных сред.

В этой части статьи мы продолжаем рассказывать об итогах 2025 года в плане серверной и настольной виртуализации на базе российских решений. Первую часть статьи можно прочитать тут.

Возможности VDI (виртуализации рабочих мест)

Импортозамещение коснулось не только серверной виртуализации, но и инфраструктуры виртуальных рабочих столов (VDI). После ухода VMware Horizon (сейчас это решение Omnissa) и Citrix XenDesktop российские компании начали внедрять отечественные VDI-решения для обеспечения удалённой работы сотрудников и центрального управления рабочими станциями. К 2025 году сформировался пул новых продуктов, позволяющих развернуть полнофункциональную VDI-платформу на базе отечественных технологий.

Лидерами рынка VDI стали решения, созданные в тесной связке с платформами серверной виртуализации. Так, компания «ДАКОМ М» (бренд Space) помимо гипервизора SpaceVM предложила продукт Space VDI – систему управления виртуальными рабочими столами, интегрированную в их экосистему. Space VDI заняла 1-е место в рейтинге российских VDI-решений 2025 г., набрав 228 баллов по совокупности критериев.

Её сильные стороны – полностью собственная разработка брокера и агентов (не опирающаяся на чужие open-source) и наличие всех компонентов, аналогичных VMware Horizon: Space Dispatcher (диспетчер VDI, альтернатива Horizon Connection Server), Space Agent VDI (клиентский агент на виртуальной машине, аналог VMware Horizon Agent), Space Client для подключения с пользовательских устройств, и собственный протокол удалённых рабочих столов GLINT. Протокол GLINT разработан как замена зарубежных (RDP/PCoIP), оптимизирован для работы в российских сетях и обеспечивает сжатие/шифрование трафика. В частности, заявляется поддержка мультимедиа-ускорения и USB-перенаправления через модуль Mediapipe, который служит аналогом Citrix HDX. В результате Space VDI предоставляет высокую производительность графического интерфейса и мультимедиа, сравнимую с мировыми аналогами, при этом полностью вписывается в отечественный контур безопасности.

Вторым крупным игроком стала компания HOSTVM с продуктом HostVM VDI. Этот продукт изначально основыван на открытой платформе UDS (VirtualCable) и веб-интерфейсе на Angular, но адаптирован российским разработчиком. HostVM VDI поддерживает широкий набор протоколов – SPICE, RDP, VNC, NX, PCoIP, X2Go, HTML5 – фактически покрывая все популярные способы удалённого доступа. Такая всеядность упрощает миграцию с иностранных систем: например, если ранее использовался протокол PCoIP (как в VMware Horizon), HostVM VDI тоже его поддерживает. Решение заняло 2-е место в отраслевом рейтинге с 218 баллами, немного уступив Space VDI по глубине интеграции функций.

Своеобразный подход продемонстрировал РЕД СОФТ. Их продукт «РЕД Виртуализация» является, в первую очередь, серверной платформой (форком oVirt на KVM) для развертывания ВМ. Однако благодаря тесной интеграции с РЕД ОС и другим ПО компании, Red Виртуализация может использоваться и для VDI-сценариев. Она заняла 3-е место в рейтинге VDI-платформ. По сути, РЕД предлагает создать инфраструктуру на базе своего гипервизора и доставлять пользователям рабочие столы через стандартные протоколы (для Windows-ВМ – RDP, для Linux – SPICE или VNC). В частности, поддерживаются протоколы VNC, SPICE и RDP, что покрывает базовые потребности. Кроме того, заявлена возможность миграции виртуальных машин в РЕД Виртуализацию прямо из сред VMware vSphere и Microsoft Hyper-V, что упрощает переход на решение.

Далее, существуют специализированные отечественные VDI-продукты: ROSA VDI, Veil VDI, Termidesk и др.

• ROSA VDI (разработка НТЦ ИТ РОСА) базируется на том же oVirt и ориентирована на интеграцию с российскими ОС РОСА.
• Veil VDI – решение компаний «НИИ Масштаб»/Uveon – представляет собственную разработку брокера виртуальных рабочих столов; оно также попало в топ-5 рейтинга.
• Termidesk – ещё одна проприетарная система, замыкающая первую шестёрку лидеров. Каждая из них предлагает конкурентоспособные функции, хотя по некоторым пунктам уступает лидерам. Например, Veil VDI и Termidesk пока набрали меньше баллов (182 и 174 соответственно) и, вероятно, имеют более узкую специализацию или меньшую базу внедрений.
  

Общей чертой российских VDI-платформ является ориентация на безопасность и импортозамещение. Все они зарегистрированы как отечественное ПО и могут применяться вместо VMware Horizon, Citrix или Microsoft RDS. С точки зрения пользовательского опыта, основные функции реализованы: пользователи могут подключаться к своим виртуальным рабочим столам с любых устройств (ПК, тонкие клиенты, планшеты) через удобные клиенты или даже браузер. Администраторы получают централизованную консоль для создания образов ВМ, массового обновления ПО на виртуальных рабочих столах и мониторинга активности пользователей. Многие решения интегрируются с инфраструктурой виртуализации серверов – например, Space VDI напрямую работает поверх гипервизора SpaceVM, ROSA VDI – поверх ROSA Virtualization, что упрощает установку.

Отдельно стоит отметить поддержку мультимедийных протоколов и оптимизацию трафика. Поскольку качество работы VDI сильно зависит от протокола передачи картинки, разработчики добавляют собственные улучшения. Мы уже упомянули GLINT (Space) и широкий набор протоколов в HostVM. Также используется протокол Loudplay – это отечественная разработка в области облачного гейминга, адаптированная под VDI.

Некоторые платформы (например, Space VDI, ROSA VDI, Termidesk) заявляют поддержку Loudplay наряду со SPICE/RDP, чтобы обеспечить плавную передачу видео и 3D-графики даже в сетях с высокой задержкой. Терминальные протоколы оптимизированы под российские условия: так, Termidesk применяет собственный кодек TERA для сжатия видео и звука. В результате пользователи могут комфортно работать с графическими приложениями, CAD-системами и видео в своих виртуальных десктопах.

С точки зрения масштабируемости VDI, российские решения способны обслуживать от десятков до нескольких тысяч одновременных пользователей. Лабораторные испытания показывают, что Space VDI и HostVM VDI могут управлять тысячами виртуальных рабочих столов в распределенной инфраструктуре (с добавлением необходимых серверных мощностей). Важным моментом остаётся интеграция со средствами обеспечения безопасности: многие платформы поддерживают подключение СЗИ для контроля за пользователями (DLP-системы, антивирусы на виртуальных рабочих местах) и могут работать в замкнутых контурах без доступа в интернет.

Таким образом, к концу 2025 года отечественные VDI-платформы покрывают основные потребности удалённой работы. Они позволяют централизованно развертывать и обновлять рабочие места, сохранять данные в защищённом контуре датацентра и предоставлять сотрудникам доступ к нужным приложениям из любой точки. При этом особый акцент сделан на совместимость с российским стеком (ОС, ПО, требования регуляторов) и на возможность миграции с западных систем с минимальными затратами (поддержка разных протоколов, перенос ВМ из VMware/Hyper-V). Конечно, каждой организации предстоит выбрать оптимальный продукт под свои задачи – лидеры рынка (Space VDI, HostVM, Red/ROSA) уже имеют успешные внедрения, тогда как нишевые решения могут подойти под специальные сценарии.

Кластеризация, отказоустойчивость и управление ресурсами

Функциональность, связанная с обеспечением высокой доступности (HA) и отказоустойчивости, а также удобством управления ресурсами, является критичной при сравнении платформ виртуализации. Рассмотрим, как обстоят дела с этими возможностями у российских продуктов по сравнению с VMware vSphere.

Кластеризация и высокая доступность (HA)

Почти все отечественные системы поддерживают объединение хостов в кластеры и автоматический перезапуск ВМ на доступных узлах в случае сбоя одного из серверов – аналог функции VMware HA. Например, SpaceVM имеет встроенную поддержку High Availability для кластеров: при падении хоста его виртуальные машины автоматически запускаются на других узлах кластера.

Basis Dynamix, VMmanager, Red Virtualization – все они также включают механизмы мониторинга узлов и перезапуска ВМ при отказе, что отражено в их спецификациях (наличие HA подтверждалось анкетами рейтингов). По сути, обеспечение базовой отказоустойчивости сейчас является стандартной функцией для любых платформ виртуализации. Важно отметить, что для корректной работы HA требуется резерв мощности в кластере (чтобы были свободные ресурсы для поднятия упавших нагрузок), поэтому администраторы должны планировать кластеры с некоторым запасом хостов, аналогично VMware.

Fault Tolerance (FT)

Более продвинутый режим отказоустойчивости – Fault Tolerance, при котором одна ВМ дублируется на другом хосте в режиме реального времени (две копии работают синхронно, и при сбое одной – вторая продолжает работать без прерывания сервиса). В VMware FT реализован для критичных нагрузок, но накладывает ограничения (например, количество vCPU). В российских решениях прямая аналогия FT практически не встречается. Тем не менее, некоторые разработчики заявляют поддержку подобных механизмов. В частности, Basis Dynamix Enterprise в материалах указывал наличие функции Fault Tolerance. Однако широкого распространения FT не получила – эта технология сложна в реализации, а также требовательна к каналам связи. Обычно достаточен более простой подход (HA с быстрым перезапуском, кластерные приложения на уровне ОС и т.п.). В критических сценариях (банковские системы реального времени и др.) могут быть построены решения с FT на базе метрокластеров, но это скорее штучные проекты.

Снапшоты и резервное копирование

Снимки состояния ВМ (snapshots) – необходимая функция для безопасных изменений и откатов. Все современные платформы (zVirt, SpaceVM, Red и прочие) поддерживают создание мгновенных снапшотов ВМ в рабочем состоянии. Как правило, доступны возможности делать цепочки снимков, однако требования к хранению диктуют, что постоянно держать много снапшотов нежелательно (как и в VMware, где они влияют на производительность). Для резервного копирования обычно предлагается интеграция с внешними системами бэкапа либо встроенные средства экспорта ВМ.

Например, SpaceVM имеет встроенное резервное копирование ВМ с возможностью сохранения бэкапов на удалённое хранилище. VMmanager от ISPsystem также предоставляет модуль бэкапа. Тем не менее, организации часто используют сторонние системы резервирования – здесь важно, что у российских гипервизоров обычно открыт API для интеграции. Почти все продукты предоставляют REST API или SDK, позволяющий автоматизировать задачи бэкапа, мониторинга и пр. Отдельные вендоры (например, Basis) декларируют принцип API-first, что упрощает связку с оркестраторами резервного копирования и мониторинга.

Управление ресурсами и балансировка

Мы уже упоминали наличие аналогов DRS в некоторых платформах (автоматическое перераспределение ВМ). Кроме этого, важно, как реализовано ручное управление ресурсами: пулы CPU/памяти, приоритеты, квоты. В VMware vSphere есть ресурсные пулы и shares-приоритеты. В российских системах подобные механизмы тоже появляются. zVirt, например, позволяет объединять хосты в логические группы и задавать политику размещения ВМ, что помогает распределять нагрузку. Red Virtualization (oVirt) исторически поддерживает задание весов и ограничений на ЦП и ОЗУ для групп виртуальных машин. В Basis Dynamix управление ресурсами интегрировано с IaC-инструментами – можно через Terraform описывать необходимые ресурсы, а платформа сама их выделит.

Такое тесное сочетание с DevOps-подходами – одно из преимуществ новых продуктов: Basis и SpaceVM интегрируются с Ansible, Terraform для автоматического развертывания инфраструктуры как кода. Это позволяет компаниям гибко управлять ИТ-ресурсами и быстро масштабировать кластеры или развертывать новые ВМ по шаблонам.

Управление кластерами

Центральная консоль управления кластером – обязательный компонент. Аналог VMware vCenter в отечественных решениях присутствует везде, хотя может называться по-разному. Например, у Space – SpaceVM Controller (он же выполняет роль менеджера кластера, аналог vCenter). У zVirt – собственная веб-консоль, у Red Virtualization – знакомый интерфейс oVirt Engine, у VMmanager – веб-панель от ISPsystem. То есть любой выбранный продукт предоставляет единый интерфейс для управления всеми узлами, ВМ и ресурсами. Многие консоли русифицированы и достаточно дружелюбны. Однако по отзывам специалистов, удобство администрирования ещё требует улучшений: отмечается, что ряд операций в отечественных платформах более трудоёмкие или требуют «танцев с бубном» по сравнению с отлаженным UI VMware. Например, на Хабре приводился пример, что создание простой ВМ в некоторых системах превращается в квест с редактированием конфигурационных файлов и чтением документации, тогда как в VMware это несколько кликов мастера создания ВМ. Это как раз то направление, где нашим решениям ещё есть куда расти – UX и простота администрирования.

В плане кластеризации и отказоустойчивости можно заключить, что функционально российские платформы предоставляют почти весь минимально необходимый набор возможностей. Кластеры, миграция ВМ, HA, снапшоты, бэкап, распределенная сеть, интеграция со сториджами – всё это реализовано (см. сводную таблицу ниже). Тем не менее, зрелость реализации зачастую ниже: возможны нюансы при очень крупных масштабах, не все функции могут быть такими же «отполированными» как у VMware, а администрирование требует большей квалификации.

Продолжение следует...

В Broadcom сосредоточены на том, чтобы помочь клиентам модернизировать инфраструктуру, повысить устойчивость и упростить операции — без добавления сложности для команд, которые всем этим управляют. За последние несколько месяцев было выпущено несколько обновлений, делающих облако VMware Cloud on AWS (VMC) более гибким и простым в использовании. Легко пропустить последние обновления в последних примечаниях к релизам, поэтому мы хотим рассказать о некоторых из самых свежих функций.

Последние обновления предоставляют корпоративным клиентам более экономичную устойчивость благодаря нестандартным вторичным кластерам (non-stretched secondary clusters) и улучшенным возможностям масштабирования вниз, более прозрачную операционную информацию благодаря обновлённому пользовательскому интерфейсу, улучшенный VMC Sizer, новые Host Usage API, а также продолжающиеся улучшения продукта HCX 4.11.3.

Оптимизация развертываний SDDC: улучшения для stretched-кластеров

Когда вы развертываете Software Defined Datacenter (SDDC) в VMC, вам предоставляется выбор между стандартным развертыванием и stretched-развертыванием. Стандартный кластер развертывается в одной зоне доступности AWS (AZ), тогда как stretched-кластер обеспечивает повышенную доступность, развертывая SDDC в трёх зонах доступности AWS. Две зоны используются для размещения экземпляров, а третья — для компонента vSAN Witness.

Поскольку SDDC в stretched-кластерах размещает хосты в двух зонах доступности AWS, клиентам необходимо планировать ресурсы по схеме два к одному, что может быть слишком дорого для рабочих нагрузок, которые не требуют высокой доступности. Кроме того, если stretched-кластер масштабируется более чем до шести хостов, ранее его нельзя было уменьшить обратно. Чтобы улучшить обе эти ситуации, команда VMC внедрила нестандартные вторичные кластеры (Non-Stretched Secondary Clusters) в stretched-SDDC, а также улучшенные возможности масштабирования вниз для stretched-кластеров.

Нестандартные вторичные кластеры в stretched-SDDC

Ранее все кластеры в stretched-SDDC были растянуты между двумя зонами доступности. В этом обновлении только первичный кластер должен быть stretched, в то время как вторичные кластеры теперь могут развертываться в одной зоне доступности.
В stretched-кластере хосты должны развертываться равномерно, поэтому минимальный шаг масштабирования — два хоста.
Но в нестандартном вторичном кластере можно добавлять хосты по одному, что позволяет увеличивать количество развернутых хостов только в той зоне доступности AWS, где они действительно нужны.

Некоторые ключевые преимущества:

• Обеспечивает преимущества как stretched-, так и non-stretched-кластеров в одном и том же SDDC.
• Позволяет расширять кластер в одной AZ по одному хосту в non-stretched-кластерах.
• Снижает стоимость для рабочих нагрузок, которым не требуется доступность stretched-кластера, включая тестовые и/или девелоперские окружения, где высокая доступность не обязательна.
• Поддерживает архитектуры приложений с нативной репликацией на уровне приложения — их можно развертывать в двух независимых нестандартных вторичных кластерах (Non-Stretched Secondary Clusters).

VMC поддерживает stretched-кластеры для приложений, которым требуется отказоустойчивость между AZ. Начиная с версии SDDC 1.24 v5, клиенты получают большую гибкость в том, как их кластеры развертываются и масштабируются. Non-stretched-кластеры могут быть развернуты только в одной из двух AWS AZ, в которых находятся stretched-хосты, и эта функция доступна только для SDDC версии 1.24v5 и выше. Кроме того, SLA для non-stretched-кластера отличается от SLA для stretched-кластера, так как non-stretched не предоставляет повышенную доступность.

При планировании новых развертываний SDDC рассмотрите возможность использования Stretched Cluster SDDC, чтобы получить преимущества и высокой доступности, и оптимизированного размещения рабочих нагрузок.

Улучшенные возможности масштабирования вниз (Scale-Down) для stretched-кластеров

Ранее stretched-кластеры нельзя было уменьшить ниже шести хостов (три в каждой AZ). Теперь вы можете уменьшить кластер с шести или более хостов до четырёх хостов (два в каждой AZ) или даже до двух хостов (по одному в каждой AZ), в зависимости от доступных ресурсов и других факторов. Это даёт вам больший контроль над инфраструктурой и помогает оптимизировать расходы.

Ключевые сценарии использования:

• Если использование ресурсов рабочей нагрузки снижалось со временем, и теперь вам необходимо уменьшить stretched-кластер, ориентируясь на текущие потребности.
• Если ранее вы увеличивали stretched-кластер до шести или более хостов в период пикового спроса, но сейчас такие мощности больше не нужны.
• Если вы недавно перевели свои кластеры с i3.metal на i4i.metal или i3en.metal и больше не нуждаетесь в прежнем количестве хостов. Новые типы инстансов обеспечивают такую же или лучшую производительность с меньшим набором хостов, что позволяет экономично уменьшить кластер.

Однако перед уменьшением stretched-кластера необходимо учитывать несколько важных моментов:

• Если в вашем первичном кластере используются крупные управляющие модули (large appliances), необходимо поддерживать минимум шесть хостов (три в каждой AZ).
• Для кластеров с кастомной конфигурацией 8 CPU минимальный размер — четыре хоста (два в каждой AZ).
• Масштабирование вниз невозможно, если кластер уже на пределе ресурсов или если уменьшение нарушило бы пользовательские политики.

Изучите текущую конфигурацию, сравните её с рекомендациями выше — и вы сможете эффективно адаптировать свой stretched-кластер под текущие потребности.

Контролируйте свои данные: новый Host Usage Report API

VMware представила новый Host Usage Report API, который обеспечивает программный доступ к данным о потреблении хостов. Теперь вы можете получать ежедневные отчёты об использовании хостов за любой период и фильтровать их по региону, типу инстанса, SKU и другим параметрам — всё через простой API.

Используйте эти данные, чтобы анализировать тенденции использования хостов, оптимизировать расходы и интегрировать метрики напрямую в существующие инструменты отчётности и дашборды. Host Usage Report API поддерживает стандартные параметры запросов, включая сортировку и фильтрацию, что даёт вам гибкость в получении именно тех данных, которые вам нужны.

Изображение выше — это пример вывода API. Вы можете автоматизировать этот процесс, чтобы передавать данные в любой аналитический инструмент по вашему выбору.

Улучшения продукта: HCX версии 4.11.3 теперь доступен для VMC

Теперь VMware HCX версии 4.11.3 доступен для VMware Cloud on AWS, и он включает важные обновления, о которых вам стоит знать.

Что нового в HCX 4.11.3?

Этот сервисный релиз содержит ключевые исправления и улучшения в областях datapath, системных обновлений и общей эксплуатационной стабильности, чтобы обеспечить более плавную работу. Полный перечень всех улучшений можно найти в официальных HCX Release Notes. Версия HCX 4.11.3 продлевает поддержку до 11 октября 2027 года, обеспечивая долгосрочную стабильность и спокойствие. VMware настоятельно рекомендует всем клиентам обновиться до версии 4.11.3 как можно скорее, так как более старые версии больше не поддерживаются.

Если вы настраиваете HCX впервые, VMware Cloud on AWS автоматически развернёт версию 4.11.3. Для существующих развертываний 4.11.3 теперь является единственной доступной версией для обновления. Нужна помощь, чтобы начать? Ознакомьтесь с инструкциями по активации HCX и по обновлению HCX в VMware Cloud on AWS.

Функция WAN Optimization больше не доступна в этом релизе. Перед обновлением необходимо удалить все модули WAN-OPT из ваших Service Mesh и профилей compute profiles. Подробные инструкции по удалению WAN-OPT доступны в документации (HCX no longer supports WANOPT from the 4.11.3 release + HCX version 4.11.3 Upgrade).

Улучшенный интерфейс: обновлённый VMware Cloud on AWS UI

VMware Cloud on AWS теперь оснащён обновлённым пользовательским интерфейсом с более упрощённой компоновкой, более быстрой навигацией и улучшенной согласованностью на всей платформе. Новый интерфейс уже доступен по адресу https://vmc.broadcom.com.

Улучшенные рекомендации по сайзингу среды: обновления VMC Sizer и Cluster Conversion

VMware представила серьёзные улучшения в процессе конвертации кластеров VMC (VMC Cluster Conversion) в инструменте VMware Cloud Sizer. Эти обновления обеспечивают более точные рекомендации по сайзингу, большую прозрачность и улучшенный пользовательский опыт при планировании перехода с хостов i3.metal на i3en.metal или i4i.metal.

Что нового в оценках VMC Cluster Conversion?

Обновлённый алгоритм оценки в VMC Sizer теперь позволяет получить более полное представление о ваших потребностях в ресурсах перед переходом с i3.metal на более новые типы инстансов.

Рекомендация по количеству хостов в обновлённом выводе VMC Sizer формируется на основе шести ресурсных измерений, и итоговая рекомендация определяется наибольшим из них.

В отчёт включены следующие параметры:

• Вычислительные ресурсы (compute)
• Память (memory)
• Использование хранилища (storage utilization) — с консервативным и агрессивным вариантами оценки
• Политики хранения vSAN (vSAN storage policies)
• NSX Edge
• Другие критически важные параметры

Все эти данные объединены в ясный и практичный отчёт VMC Sizer с рекомендациями, адаптированными под ваш сценарий миграции на новые типы инстансов.

Этот результат оценки является моментальным снимком текущего использования ресурсов и не учитывает будущий рост рабочих нагрузок. При планировании конвертации кластеров следует учитывать и несколько других важных моментов:

• Итоговое количество хостов и параметры сайзинга будут подтверждены уже в ходе фактической конвертации кластера.
• Клиентам рекомендуется повторно выполнять оценку сайзинга после любых существенных изменений конфигурации, ресурсов или других параметров.
• В ходе конвертации политики RAID не изменяются.
• Предоставляемые в рамках этого процесса оценки подписки VMware служат исключительно для планирования и не являются гарантированными финальными требованиями.
• Фактические потребности в подписке могут оказаться выше предварительных оценок, что может потребовать покупки дополнительных подписок после конвертации.
• Возвраты средств или уменьшение объёма подписки не предусмотрены, если предварительная оценка превысит фактические потребности.

Оптимальная ИТ-инфраструктура характеризуется способностью поддерживать растущее количество рабочих нагрузок со временем и управлять колебаниями требований к ресурсам в реальном времени при сохранении максимальной производительности. VMware Cloud Foundation 9 облегчает внедрение облачной операционной модели в масштабах организации, тем самым ускоряя гибкость ИТ, повышая масштабируемость инфраструктуры, улучшая безопасность и снижая совокупную стоимость владения.

Одной из ключевых инженерных инициатив в VMware Cloud Foundation 9 (VCF 9) стало улучшение пользовательского опыта при развертывании. VMware не только упростила процесс развертывания нового экземпляра VCF, но и расширила поддержку различных типов топологий и сценариев развертывания. В результате пользователи vSphere получают более простой, быстрый и воспроизводимый процесс перехода на VCF.

VMware Cloud Foundation 9 предлагает несколько вариантов развертывания для модернизации инфраструктуры:

• Развертывание нового экземпляра VCF
• Расширение существующего пула VCF (VCF Fleet)
• Конвертация существующего развертывания vCenter в VCF
• Импорт существующего развертывания vCenter в VCF

Начнём с того, как происходит развертывание и масштабирование VCF 9.

VMware Cloud Foundation 9 — это крупный релиз, включающий ряд важных новых возможностей и более интегрированный опыт для администраторов частных облаков. Виртуальный модуль установщика VMware Cloud Foundation (VCF Installer) — это новый компонент в VCF 9, предоставляющий более гибкие сценарии развертывания, подходящие для расширенного набора задач.

VCF Installer можно использовать для:

• Развертывания нового экземпляра VCF как части нового пула (Fleet)
• Если у заказчика уже есть несколько сред, он может развернуть дополнительные экземпляры VCF в существующем пуле.

Каждый экземпляр VCF развёртывается с использованием vSphere и сервера vCenter, NSX, VCF Operations и VCF Automation. Настройка VCF-среды с использованием vSAN обеспечивает полный стек SDDC (программно-определяемого датацентра).

VCF Installer также содержит встроенные рабочие процессы для конвертации (повторного использования) существующего развертывания vCenter в управляющий кластер VCF. В этом сценарии под существующей средой vCenter понимается развертывание вне VCF. При выполнении конвертации VCF Installer развертывается в том же кластере, где находится виртуальный модуль сервера vCenter. VMware поддерживает как кластеры vCenter, настроенные с vSAN, так и кластеры, использующие внешнее хранилище.

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

И это ещё не всё, что умеет VCF Installer. Рабочий процесс установщика также предоставляет возможность конвертировать существующий экземпляр VCF Operations и/или VCF Automation. Виртуальный модуль VCF Installer обеспечивает более простой, быстрый и воспроизводимый процесс перехода к VMware Cloud Foundation для клиентов.

Подробнее о виртуальном модуле VCF Installer

Виртуальный модуль VCF Installer заменяет Cloud Builder, использовавшийся в предыдущих версиях VCF. Он предоставляет гибкий набор опций, ещё больше упрощающих развертывание полноценной частной облачной среды.

VCF Installer содержит интерфейс с пошаговым управлением (UI-driven workflow) и больше не требует использования файла Deployment Parameters Workbook (таблица Excel). Также в него встроены функции конвертации и импорта существующих инстанций vCenter, VCF Operations и VCF Automation — без необходимости использовать скрипты VCF Import.

В предыдущих версиях Cloud Foundation требовалось устанавливать Aria Operations и Aria Automation отдельно и управлять ими на этапе Day 2 (после начального развертывания). Начиная с VCF 9, VCF Installer используется для развертывания всего стека VCF, включая гипервизор vSphere, хранилище, сеть, управление и самообслуживание, а VCF Operations отвечает за полное управление жизненным циклом этого стека.

Как работает VCF Installer?

В этом новом и очень легковесном виртуальном модуле VCF Installer встроен набор усовершенствованных сценариев развертывания и множество новых параметров конфигурации.

При подключении к порталу поддержки Broadcom пользователь загружает программные бинарные файлы, подключаясь к онлайн-репозиторию. В отличие от Cloud Builder, модуль VCF Installer не содержит бинарных файлов ПО.

Пользователи также могут настроить собственный автономный (offline) репозиторий, который можно использовать для нескольких экземпляров VCF. В этом случае бинарные файлы необходимо загрузить только один раз, что удобно при управлении несколькими экземплярами VCF.

После загрузки бинарных файлов модуль можно использовать для развертывания VMware Cloud Foundation (VCF) или VMware vSphere Foundation (VVF). Развертывание можно выполнить с помощью встроенного мастера установки или путем загрузки JSON-спецификации, которую можно повторно использовать, просматривать и валидировать через интерфейс. JSON-спецификацию также можно редактировать прямо в мастере установки.

Экземпляр VCF может быть развернут как часть нового пула (VCF Fleet) или добавлен к существующему пулу. VCF Fleet может включать в себя несколько развертываний VCF, использующих общие экземпляры VCF Operations и VCF Automation.

VCF Installer используется для начальной настройки управляющего кластера, который можно развернуть двумя способами:

1. Развертывание новых компонентов, включая виртуальные машины для vCenter Server, NSX, VCF Operations и VCF Automation.

2. Использование уже существующих компонентов, например, существующих экземпляров vCenter Server, VCF Operations и VCF Automation.

При выборе конвертации (повторного использования) существующего vCenter Server, VCF Installer конвертирует существующий кластер vSphere или vSphere с vSAN в управляющий кластер VCF. В рамках этого процесса VCF Installer автоматически развёртывает NSX.

Если выбран повторный запуск уже существующего экземпляра VCF Operations, рекомендуется указать тот vCenter Server, на котором он размещена, в качестве управляющего vCenter для первого кластера VCF.

Виртуальные машины для новых экземпляров VCF Operations, VCF Automation и NSX можно развернуть в двух режимах:

• Простой режим (Simple Model) — одноузловые виртуальные модули.
• Режим высокой доступности (High Availability Model) — несколько модулей для отказоустойчивости.

После успешного развертывания VCF Installer предоставляет ссылку для запуска VCF Operations, который используется для управления.

Подробнее о двух моделях виртуальных модулей

Простой режим (Simple Model)

Минимум 7 виртуальных модулей:

• 1 для vCenter Server
• 1 для SDDC Manager
• 1 для NSX Manager
• 3 для VCF Operations: Operations Manager, Fleet Management, Operations Collector
• 1 для VCF Automation

Если выбрана опция Supervisor, разворачивается виртуальный модуль VKS. Дополнительно после установки можно развернуть:

• Поддержку логов в VCF Operations
• Безопасное подключение к NSX Edge кластеру
• Базу данных VIDB для управления доступом и идентификацией

Модель высокой доступности (High Availability Model)

Рекомендуется для производственных сред. Развертывается минимум 13 виртуальных модулей:

• 3 NSX Manager
• 3 VCF Operations
• 3 VCF Automation
• 3 для логов и 1 для VKS

Наличие трёх экземпляров каждого компонента обеспечивает отказоустойчивость при сбоях оборудования, уменьшает влияние обновлений и упрощает управление жизненным циклом (патчи, апгрейды и т.д.). Также доступны дополнительные опции (не указаны выше), например, настройка балансировщиков нагрузки NSX для отдельных компонентов.

В любое время после установки клиент может масштабировать дополнительные компоненты. Дополнительно можно развернуть:

• VCF Operations for Networks
• HCX
• Другие дополнительные сервисы VCF Advanced (Add-ons)

Как управлять средой VCF 9?

Начиная с VCF 9, управление и эксплуатация частного облака выполняются через консоль VCF Operations. VCF Operations предоставляет администраторам облака единый и функционально насыщенный интерфейс, охватывающий управление вычислениями, хранилищем, сетью, флотом экземпляров и жизненным циклом всей системы.

Но и это ещё не всё - VCF Operations для VCF 9 также включает встроенные рабочие процессы, которые поддерживают ещё два дополнительных сценария развертывания VCF. С помощью VCF Operations можно:

• Создавать новые домены рабочих нагрузок (workload domains)
• Импортировать существующие развертывания vCenter в существующий экземпляр VMware Cloud Foundation

Оба варианта позволяют масштабировать частное облако и обеспечивают централизованное управление и эксплуатацию.

Импорт существующих развертываний vCenter в экземпляр VMware Cloud Foundation

VCF Operations упрощает добавление существующей инфраструктуры vSphere, vSAN и NSX в уже развернутый экземпляр VCF. В интерфейсе доступны интерактивные пошаговые сценарии импорта существующей инфраструктуры vSphere в VCF в виде доменов рабочей нагрузки.

Возможность импорта уже существующей инфраструктуры позволяет клиентам ускорить переход к VCF, использовать уже сделанные инвестиции и одновременно снижать затраты. Более того, теперь не требуется вручную переносить рабочие нагрузки со старой инфраструктуры на VCF.

При импорте развертывания vCenter в VCF, все кластеры внутри этого сервера vCenter автоматически импортируются и настраиваются как часть домена рабочей нагрузки.

Можно импортировать:

• Кластеры vSphere с или без vSAN
• Кластеры с или без NSX
• Любую комбинацию этих компонентов

Если NSX в кластере ещё не развернут, он будет установлен автоматически в процессе конвертации.

При импорте развертывания vCenter в экземпляр VCF все кластеры, находящиеся на этом сервере vCenter, импортируются и настраиваются как часть домена рабочей нагрузки. Этот сценарий в VCF Operations поддерживает широкий спектр конфигураций кластеров, которые часто встречаются в существующих средах vSphere.

• Хосты с одним физическим сетевым адаптером (pNIC)
• Кластеры с включённым LACP
• Одноузловые кластеры и отдельные хосты (standalone)

• Кластеры vSAN из 2 узлов
• HCI Mesh
• Кластеры хранения vSAN
• Растянутые кластеры vSAN (stretched clusters)

Также можно импортировать кластеры, использующие внешние хранилища, например:

• NFS
• VMFS over Fibre Channel (FC)
• iSCSI

• Развертывания vCenter Server, как с NSX, так и без него, могут быть импортированы

Резюме

VMware Cloud Foundation 9 (VCF 9) предлагает несколько вариантов развертывания для модернизации вашей инфраструктуры:

• Для нового развертывания VCF 9 требуется минимум 4 хоста для управляющего кластера, который может быть развернут с использованием vSAN, NFS или VMFS по FC.
• Начиная с VCF 9, управляющий кластер можно настраивать с помощью узлов vSAN Ready Nodes (рекомендуется).
• Также поддерживается оборудование vSphere, сертифицированное для использования с топологиями хранения на NFS/VMFS over FC. Подробности — в руководстве по совместимости (Compatibility Guide).
• Управляющий домен нового экземпляра VCF настраивается с использованием NSX. Каждый рабочий домен (Workload Domain) также конфигурируется с NSX и готов к использованию виртуальной сети NSX (SDN).

• Развертывание нового экземпляра VCF как части уже существующего пула.
• Каждый VCF Fleet управляется общими экземплярами VCF Operations и VCF Automation.

• VMware поддерживает конвертацию (повторное использование) существующих кластеров vSphere в VCF.
• Такие среды могут быть развернуты с vSphere или vSphere с vSAN.
• Среды vCenter с уже установленным NSX пока не поддерживаются для конвертации в управляющий домен VCF. В процессе будет установлен новый экземпляр NSX.

Требуется минимум:

• 3 узла vSAN Ready.
• Или 2 хоста vSphere, настроенные с NFS или VMFS over FC (cм. VCF configmax для дополнительной информации).

Импорт развертывания vCenter в VCF:

Требуется минимум:

• 3 узла vSAN Ready.
• Или 2 хоста vSphere, настроенные с NFS или VMFS over FC (cм. VCF configmax для дополнительной информации).
• Существующие среды vCenter с установленным NSX могут быть импортированы как домены рабочей нагрузки.

• Новый экземпляр VCF развертывается в режиме оценки (evaluation mode).
• В этом режиме VCF полностью функционален и позволяет развертывать дополнительные хосты, домены рабочей нагрузки и кластеры.
• Экземпляр VCF 9 необходимо активировать лицензией в течение 90 дней с момента установки.
• VCF Operations направляет пользователя в Broadcom Business Services Console для завершения процесса лицензирования.

• Начиная с VCF 9, VCF Operations используется для управления одним или несколькими экземплярами VCF.
• SDDC Manager 9 устанавливается или обновляется как компонент любого экземпляра VCF 9.
• SDDC Manager будет выведен из эксплуатации в одном из будущих релизов.

На днях было официально выпущено долгожданное руководство по проектированию VMware Cloud Foundation (VCF) версии 9. Оно предоставляет архитекторам облаков, инженерам платформ и администраторам виртуальной инфраструктуры всестороннюю основу для проектирования надёжных, масштабируемых и эффективных инфраструктур частных облаков с использованием VCF.

Будь то развертывание с нуля или оптимизация существующей среды, это руководство предлагает практические рекомендации, структурированные шаблоны и продуманную систему принятия решений, адаптированную под последнюю версию VCF.

Что внутри VMware Cloud Foundation 9 Design Guide?

Руководство тщательно структурировано по нескольким ключевым разделам, каждый из которых помогает принимать обоснованные решения на каждом этапе проектирования и развертывания VCF.

Изучите обзор на высоком уровне каждого компонента VCF — включая вычисления, хранилище и сеть — а также компромиссы, преимущества и последствия различных архитектурных решений.

Быстро начните реализацию, используя заранее подготовленные шаблоны, адаптированные под конкретные сценарии использования. Эти шаблоны содержат рекомендации по проектированию «от и до» — их можно использовать как в готовом виде, так и как основу для настройки под нужды вашей организации.

Доступные шаблоны включают описания VCF-компонентов в следующих конфигурациях:

• На одной площадке с минимальным размером
• Полноценно на одной площадке
• На нескольких площадках в одном регионе
• На нескольких площадках в разных регионах
• На нескольких площадках в одном регионе плюс дополнительные регионы

Глубоко погрузитесь в особенности проектирования каждого отдельного компонента VCF. Каждый раздел включает:

• Требования к проекту – обязательные конфигурации, необходимые для корректной работы VCF.
• Рекомендации по проекту – лучшие практики, основанные на реальном опыте и инженерной проверке.
• Варианты проектных решений – точки выбора, где допустимы несколько подходов, с рекомендациями, в каких случаях стоит предпочесть тот или иной.

Недавно компания VMware обновила свой распределенный сетевой экран vDefend 9 в рамках релиза VMware Cloud Foundation 9.0. Новые усовершенствования включают поддержку lateral security с учетом среды VPC, самостоятельную микро-сегментацию, упрощённую миграцию vDefend в VCF и централизованное глобальное управление IDS/IPS-политиками для ускоренного реагирования на угрозы и их устранения.

Современные предприятия стремительно внедряют стратегию частного облака в своих инфраструктурах. Недавнее исследование, охватившее 1 800 руководителей высокого уровня, показало, что их организации отдают приоритет частным облакам для решения проблем, связанных со стоимостью, необходимостью предсказуемости, требованиями AI-нагрузок, lateral security и соблюдением нормативных требований.

Поскольку цифровые компании всё активнее делают ставку на частные облачные стратегии, ИТ- и службы безопасности сталкиваются с задачей максимально быстрого и эффективного обеспечения защиты рабочих нагрузок. Поскольку большинство атак программ-вымогателей включает боковое распространение угроз с целью поиска ценных активов, стратегии кибербезопасности эволюционируют в сторону защиты как критичных, так и некритичных нагрузок во всех частных облаках.

vDefend — это ведущая программно-определяемая, интегрированная с гипервизором система боковой безопасности (lateral security), созданная специально для комплексной защиты каждой рабочей нагрузки в среде VMware Cloud Foundation (VCF). vDefend внедряет надёжные встроенные средства сетевой безопасности непосредственно в архитектуру VCF. Решение позволяет быстро внедрять, управлять и масштабировать микро-сегментацию и защиту от угроз, ускоряя реализацию стратегий нулевого доверия в организации.

Новые возможности vDefend для VCF 9.0

• Боковая безопасность с поддержкой VPC (VPC-Aware Lateral Security): теперь пользователи могут применять vDefend на уровне виртуального частного облака (VPC), внедряя изолированные и управляемые политики боковой безопасности для каждого арендатора/потребителя. Это обеспечивает точный контроль и делегированное управление, упрощая многопользовательские среды.

• Самостоятельная микросегментация (Self-Service Micro-segmentation): команды инфраструктуры создают централизованные политики межсетевого экранирования для «огороженных» зон приложений. В версии vDefend 9.0 владельцам приложений можно делегировать создание детализированных политик внутри этих зон. Автоматизация возможна через API в рамках DevOps CI/CD-процессов.

• Интеграция импорта в VCF (VCF Import Integration): существующие развертывания vDefend вне VCF могут быть импортированы в среду VCF 9.0 с сохранением политик, что снижает усилия по миграции. Это упрощает и ускоряет переход на полнофункциональную платформу VCF.

• Глобальное управление IDS/IPS-политиками (Global Policy Management): централизованное управление политиками предотвращения и обнаружения вторжений на разных площадках обеспечивает единообразие политики и ускоренное реагирование на угрозы вне зависимости от местоположения рабочих нагрузок.

• Портал сигнатур IDS/IPS (Signature Portal): позволяет в реальном времени изучать изменения сигнатур без входа в консоль vDefend, что оптимизирует рабочие процессы, повышает осведомлённость об угрозах и ускоряет реагирование на инциденты.

• Фильтрация по геолокации (Geo-IP Filtering): межсетевой экран шлюза vDefend теперь может управлять трафиком с учётом географии, разрешая или блокируя подключения к определённым странам прямо на шлюзе уровня T0, обеспечивая точный контроль глобальных потоков.

Интеграция vDefend с VCF 9.0 делает передовые меры безопасности более доступными, учитывающими многопользовательскую среду и централизованно управляемыми, превращая безопасность из препятствия в встроенную возможность.

Боковая безопасность с поддержкой VPC

Многопользовательская архитектура — основа корпоративного ИТ, но достижение полной изоляции как на уровне данных, так и управления всегда было сложной задачей. Внедрение VPC значительно улучшило ситуацию, позволив разделять как каналы передачи данных, так и управляющие плоскости в сетевой и безопасной архитектуре, обеспечивая более детальную изоляцию на уровне приложений, часто под управлением DevOps-команд.

С выпуском VMware Cloud Foundation (VCF) 9.0, vDefend расширяет возможности боковой безопасности, предоставляя полноценную изоляцию сетей на уровне VPC с помощью микро-сегментации, пропуская только доверенный трафик между приложениями. Это улучшение позволяет делегировать управление: администратор каждого VPC может видеть и настраивать только собственную среду. Команды теперь могут работать параллельно, обладая полной самостоятельностью и изоляцией, делая безопасную многопользовательскую работу в частном облаке реальностью.

Self-service микросегментация

Межсетевой экран vDefend предоставляет возможности как администраторам инфраструктуры, так и владельцам VPC. Администраторы инфраструктуры могут создавать защищённые виртуальные частные облака (VPC), сводя к минимуму горизонтальный (east-west) трафик. Одновременно с этим владельцы VPC получают гибкость в настройке детализированных правил для своих приложений, обеспечивая их работоспособность без нарушения централизованных политик безопасности. Такой подход способствует внедрению модели «самообслуживания» в вопросах безопасности для конечных пользователей при сохранении общего уровня защищённости организации.

Бесшовная миграция с импортом в VCF

Существующие развертывания vDefend вне VMware Cloud Foundation (VCF) можно легко импортировать в среду VCF 9.0 с сохранением текущих политик межсетевого экрана vDefend. Это снижает затраты и усилия, связанные с таким переходом. Упрощённый процесс миграции позволяет клиентам эффективно перейти на полнофункциональную платформу VCF, без необходимости начинать всё с нуля.

Упрощённое и централизованное управление IDS/IPS-политиками в многокомпонентных VCF-средах с поддержкой изолированных (air-gapped) сред

Крупные, многокомпонентные (федеративные) среды VCF требуют единых, масштабируемых политик безопасности IDS/IPS и централизованного управления сигнатурами, при этом операции должны оставаться простыми и эффективными. Теперь клиенты могут внедрять глобальные политики IDS/IPS во всех распределённых развертываниях VCF с помощью централизованного управления, обеспечивая единообразие защиты на уровне всей организации.

Кроме того, возможность назначать несколько пакетов сигнатур IDS/IPS позволяет пользователям применять конкретные наборы сигнатур в нужных местах своих развертываний VCF. Для изолированных (air-gapped) сред поддерживается доставка пакетов сигнатур IDS/IPS на локальные управляющие узлы (Local Managers), даже при отсутствии подключения к интернету и наличии ограничений по соблюдению требований безопасности.

В совокупности эти возможности обеспечивают единообразное и централизованное управление политиками предотвращения угроз в многокомпонентных развертываниях VCF. Все события IDS/IPS отображаются в единой консоли управления.

Мониторинг в реальном времени с новым порталом сигнатур IDS/IPS

Поддержание актуальности защитных механизмов — критически важная задача; предприятия полагаются на частые обновления сигнатур, чтобы опережать новые угрозы. Хотя vDefend уже позволяет легко загружать и просматривать актуальные пакеты сигнатур IDS/IPS через свою консоль, аналитикам по безопасности зачастую требуется более глубокое понимание — например, определение новшеств в каждом пакете, отслеживание истории версий, поиск сигнатур по конкретным уязвимостям (CVE) или по определённым шаблонам атак, таким как каналы управления и контроля (Command and Control).

В новом портале сигнатур IDS/IPS VMware представила мощный инструмент, который позволяет операторам исследовать обновления сигнатур в реальном времени — без необходимости входа в консоль vDefend. Благодаря удобному веб-доступу портал позволяет командам изучать сигнатуры, искать покрытия по конкретным угрозам, сравнивать версии и экспортировать списки сигнатур. Эта возможность не только упрощает начальное планирование и развертывание, но и способствует более эффективному взаимодействию команд и ускоренному реагированию, повышая осведомлённость об угрозах и улучшая реагирование на инциденты в масштабе всей организации.

Точный контроль трафика с геозональной фильтрацией по странам

Администраторы инфраструктуры теперь могут разрешать или блокировать входящий и исходящий трафик на уровне межсетевого экрана шлюза vDefend в зависимости от конкретного географического расположения. Эта новая возможность обеспечивает точное, адресное управление трафиком, усиливает уровень безопасности и способствует соблюдению нормативных требований.

Более подробно о VMware vDefend 9 можно узнать на странице продукта. Release Notes доступны тут.

В рамках конференции 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 действует принцип: всё, что можно представить в виде отчёта — можно добавить в пользовательскую панель. Дополнительно доступны готовые виджеты "из коробки", отображающие:

• Возможности для оптимизации
• Сводки по обязательствам
• Аномалии в расходах
• Неэффективные затраты и ресурсы и многое другое

Элементы панели можно масштабировать и перемещать в соответствии с предпочтениями пользователя. Дэшборды дают пользователям беспрецедентную гибкость для создания интерфейса, максимально соответствующего их повседневной роли и приоритетам.

Возможно, вас смутило выражение «ВМ на голом железе» в заголовке. Но это не опечатка: в этом посте мы расскажем о двух ключевых вещах, а основная тема, которую мы рассмотрим — это запуск виртуальных машин (ВМ) как контейнеров в среде Kubernetes. Поэтому в этой статье будет две основные цели:

1. Раскрыть преимущества запуска ВМ и контейнеров на единой платформе. Да, этой единой платформой является служба vSphere Kubernetes Service в VMware Cloud Foundation.

2. Объяснить, почему запуск ВМ и контейнеров на «голом железе» имеет реальные недостатки для предприятий, чтобы вы могли сделать собственные выводы. Мы приведем факты, которые вы сможете проверить независимо от каких-либо поставщиков.

Начнём с того, что разберёмся, что такое служба 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 — разумное и эффективное решение.

Источник.

Недавно Broadcom и VMware поделились новостями тесного партнёрства с Microsoft, которые привели к расширению списка сервисов Azure, поддерживаемых на платформе VMware Cloud Foundation (VCF). В ноябре прошлого года добавили поддержку Azure AI Video Indexer на VCF, а на днях было объявлено, что теперь также поддерживается Azure Machine Learning (AML) на платформе VCF.

Благодаря этому, у пользователей появляется ещё больше возможностей использовать подход Private AI для запуска моделей искусственного интеллекта и машинного обучения в непосредственной близости от приватных данных, как локально (on-premises), так и в облаке Azure VMware Solution.

Высокоуровневые компоненты данного решения представлены ниже:

Для получения подробных технических рекомендаций по интеграции Azure Machine Learning (AML) с VMware Cloud Foundation (VCF), пожалуйста, обратитесь к недавно опубликованной архитектуре решения.

Общие клиенты Broadcom и Microsoft признают, что гибридные решения в области искусственного интеллекта, сочетающие преимущества публичного облака и локальной (on-premises) или периферийной (edge) инфраструктуры, являются важнейшей частью их текущих и будущих архитектурных планов. Совместно с Microsoft компания Broadcom упрощает для организаций задачу обеспечения единого входа в Azure для разработчиков и специалистов по данным при планировании сервисов машинного обучения, таких как классификация данных или компьютерное зрение, и при этом дает возможность развертывать их на платформе VCF в любой точке присутствия бизнеса.

На просторах обнаружился интересный сайт VeeamClick.be, предлагающий интерактивные демонстрации продуктов Veeam, что позволяет пользователям ознакомиться с функциональными возможностями решений компании в режиме онлайн. Сайт создан и поддерживается Стийном Маривоетом (Stijn Marivoet) и предоставляет бесплатный доступ к своим материалам.

Основные разделы сайта:

• Veeam Backup and Replication: в этом разделе представлены как базовые, так и расширенные операции, компоненты архитектуры продукта и функции, ориентированные на безопасность.
• M365 Backup: здесь можно найти демонстрации по резервному копированию Microsoft 365 с использованием Veeam Backup for M365 и Veeam Data Cloud.
• Veeam Backup for Cloud: демонстрации, посвященные резервному копированию облачных сред.
• Veeam Orchestrator: интерактивные материалы по оркестрации процессов резервного копирования и восстановления.
• Veeam Backup for Salesforce: демонстрации, показывающие возможности резервного копирования данных Salesforce.
• K10: материалы, связанные с инфраструктурой Kubernetes и решениями Veeam для контейнеризированных приложений.

Каждый из этих разделов содержит списки потенциальных операций и функций, доступных для изучения. Если у пользователей есть специфические запросы, они могут связаться с администратором сайта для получения дополнительной информации.

VMware Validated Solutions – это проверенный портфель технически валидированных решений, разработанных для того, чтобы помочь клиентам создавать безопасную, высокопроизводительную, устойчивую и эффективную инфраструктуру для их приложений и рабочих нагрузок, развернутых в облаке VMware Cloud Foundation. Эти решения предлагают систематический подход к быстрому и эффективному развертыванию, охватывая планирование и подготовку, принятие проектных решений, реализацию, эксплуатационные рекомендации и совместимость решений. Кроме того, многие из таких решений могут автоматизировать значительную часть процесса развертывания. Примером такого решения служит VMware Private AI Ready Validated Solution.

Lateral Security for VMware Cloud Foundation with VMware vDefend – это хорошо продуманное, модульное решение, которое направляет процесс проектирования, внедрения и эксплуатации VMware vDefend для защиты компонентов управления и рабочих нагрузок VMware Cloud Foundation. О нем мы подробно писали вот тут.

Создание безопасной инфраструктуры является ключевым фактором в обеспечении защиты рабочих нагрузок частного облака клиентов с первого дня. Решение этой задачи может оказаться сложным для администраторов без специализированных знаний. Настройка и управление безопасными средами требуют глубокого понимания инфраструктуры и специфики сетевого взаимодействия приложений.

Использование проверенного решения Lateral Security for VMware Cloud Foundation with VMware vDefend позволяет организациям эффективно решать эти задачи и уверенно защищать свои частные облака и рабочие нагрузки с помощью проверенных конфигураций и индивидуальных рекомендаций.

Что входит в решение?

Решение основывается на лучших принципах проектирования Broadcom для использования продуктов и функций безопасности VMware vDefend в средах VMware Cloud Foundation.

Оно включает в себя проектные решения и автоматизированные шаги по защите компонентов домена управления VMware Cloud Foundation, а также упрощенные рекомендации по проектированию и внедрению макро- и микросегментации для защиты клиентских рабочих нагрузок в доменах рабочих нагрузок. Решение направляет эффективное развертывание NSX Application Platform, предоставляя важные рекомендации по выбору размеров и масштабированию для обеспечения оптимальной производительности.

Кроме того, оно предлагает руководство по использованию Security Intelligence для автоматизации и расширения возможностей защиты vDefend, обеспечивая повторяемые процессы, которые можно адаптировать для любых сред и рабочих нагрузок VMware Cloud Foundation.

Готовы углубиться и раскрыть полный потенциал продукта VMware vDefend? Вы можете получить доступ к готовому решению VMware Validated Solution по этой ссылке.

VMware vDefend – это передовая служба для VMware Cloud Foundation, обеспечивающая новейшие возможности для реализации принципов нулевого доверия (zero-trust) в области латеральной безопасности. Это единственное решение безопасности, которое предоставляет детализированную защиту компонентов управления VMware Cloud Foundation с использованием микросегментации.

Lateral Security for VMware Cloud Foundation – это корпоративное решение, позволяющее клиентам быстро и эффективно разрабатывать, планировать и развертывать защиту VMware vDefend для обеспечения безопасности инфраструктуры и рабочих нагрузок VMware Cloud Foundation.

Облачные технологии постоянно развиваются, и VMware Cloud Director (VCD) продолжает совершенствоваться с новыми обновлениями, которые укрепляют безопасность, упрощают управление ресурсами и предоставляют пользователям больше возможностей контроля. VMware недавно объявила, что VMware Cloud Director 10.6.1 теперь доступен в составе VMware Cloud Foundation (VCF), начиная с 31 января 2025 года.

Основные улучшения в этом релизе

Теперь вы можете легко размещать виртуальные машины на определенных хостах или кластерах в зависимости от их гостевой операционной системы. Эта функция позволяет администраторам создавать группы ВМ для конкретных типов ОС, обеспечивая правильное распределение и соответствие требованиям всех арендаторов. Кроме того, это помогает организациям соответствовать требованиям лицензирования Microsoft и других поставщиков, упрощая управление лицензиями и оптимизируя использование ресурсов.

• Автоматическое применение правил гарантирует, что ВМ всегда размещаются в назначенных группах.
• Простая реконфигурация: существующие ВМ автоматически примут это правило при следующем изменении конфигурации, например при перезагрузке или редактировании ВМ.
• Улучшенное распределение нагрузки и упрощенное управление мультиарендами.

Безопасность имеет первостепенное значение, и теперь VCD включает возможность принудительного истечения срока действия API-токенов. Если необходимо немедленно отозвать токен — по соображениям безопасности или в связи с изменениями в управлении, администраторы могут сделать это мгновенно. Это обеспечивает более проактивный подход к управлению доступом к API и защите облачных сред.

• Мгновенный отзыв токенов для повышения уровня безопасности.
• Повышенный контроль администраторов над аутентификацией и управлением доступом.

Управлять IP-адресами стало проще! Теперь VMware Cloud Director позволяет настраивать индивидуальные периоды хранения IP-адресов как на уровне субпровайдеров, так и на уровне управляемых организаций. Это означает, что IP-адреса могут сохраняться даже после удаления ВМ или сетевых интерфейсов (NIC), независимо от способа их назначения (Static Pool, Static Manual или DHCP).

• Настраиваемое хранение IP-адресов обеспечивает их сохранность и снижает необходимость повторного выделения.
• Конфигурация на основе метаданных позволяет администраторам задавать периоды хранения в соответствии с потребностями организации.
• Использование API Manual Reservation для сохранения IP-адресов при повторном развертывании.

Теперь появилась возможность явного включения или отключения принудительного применения правил межсетевого экрана на шлюзе. Этот функционал интегрирован в стек VCF и предоставляет полный обзор статуса применения правил на межсетевых экранах уровней T1 и T0. Администраторы арендаторов и субарендаторов могут просматривать и изменять настройки по умолчанию, обеспечивая соответствие политике безопасности организации.

• Полная прозрачность статуса межсетевого экрана.
• Административный контроль для включения или отключения правил при необходимости.

Администраторы провайдеров теперь могут более детально управлять службой Stateful сетевого экрана, встроенной в стек VCF. В этом обновлении они могут запрещать арендаторам добавлять правила на T1, T0 и vApps, если безопасность ANS не включена. Кроме того, новая опция конфигурации для кластеров Edge позволяет провайдерам включать или отключать сетевые экраны по мере необходимости.

Применение:

• Детализированный контроль правил сетевого экрана обеспечивает соответствие требованиям безопасности.
• Гибкость в управлении сетевой безопасностью на уровне кластеров Edge.

Теперь провайдеры услуг могут делиться пользовательскими профилями сегментов с организациями-арендаторами, что упрощает стандартизацию сетевых политик среди нескольких арендаторов.

• Улучшенное взаимодействие между провайдерами и арендаторами.
• Единые сетевые конфигурации для нескольких организаций.

Теперь поддержка IPv6 и VMware Avi Load Balancer Transparent Load Balancing снова доступна! Члены пулов могут видеть IP-адреса исходных клиентов, что повышает уровень видимости и эффективность работы сети. Для включения этой функции необходимо интегрировать VMware Avi Load Balancer с VMware Cloud Director.

• Легкая поддержка IPv6 для современных сетевых инфраструктур.
• Улучшенная балансировка нагрузки с прозрачной маршрутизацией трафика.

• Исправленный API обновления кастомных задач – устранена проблема двойного выполнения, теперь API работает корректно с первой попытки.
• Исправленный просмотр всех виртуальных датацентров – теперь администраторы могут беспрепятственно переключаться между представлениями без ошибок.
• Удалены ссылки на NSX MP API – упрощенный интерфейс без устаревших ссылок.

Обновление VMware Cloud Director 10.6.1 направлено на повышение контроля, улучшение безопасности и расширение сетевых возможностей. Независимо от того, оптимизируете ли вы размещение ВМ, усиливаете защиту API или настраиваете сетевые экраны, эти изменения предоставляют больше возможностей как облачным провайдерам, так и арендаторам.

VMware Cloud Foundation (VCF) — это гибридная облачная платформа, которая позволяет запускать приложения и рабочие нагрузки в частном или публичном облаке. VCF — отличный вариант для предприятий, стремящихся модернизировать свою ИТ-инфраструктуру.

Существует несколько способов переноса рабочих нагрузок в VCF. В этой заметке мы рассмотрим три различных варианта:

• Решение VMware HCX
• Утилита VCF Import Tool
• Средство комплексной DR-защиты виртуальных сред VMware Site Recovery

Дорожная карта миграции в VCF обычно включает следующие этапы:

• Оценка (Assessment): на этом этапе вы анализируете свою текущую ИТ-среду и определяете оптимальный способ миграции рабочих нагрузок в VCF.
• Планирование (Planning): вы разрабатываете детальный план миграции.
• Миграция (Migration): осуществляется перенос рабочих нагрузок в VCF.
• Оптимизация (Optimization): в заключение, вы оптимизируете среду VCF, чтобы обеспечить стабильную и эффективную работу рабочих нагрузок.

VMware HCX (Hybrid Cloud Extension)

VMware HCX — это продукт, который позволяет переносить виртуальные машины между различными средами VMware. В том числе, он поддерживает миграцию виртуальных машин из локальных сред vSphere в облако VCF (также поддерживаются платформы Hyper-V или KVM на источнике).

HCX — отличный вариант для предприятий, которым необходимо перенести большое количество виртуальных машин с минимальным временем простоя.

VMware HCX позволяет создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Live Site Recovery.

HCX предоставляет возможность миграции виртуальных машин и приложений между различными видами облаков по принципу Any2Any. С точки зрения виртуальной машины, ее ОС и приложений, HCX выступает уровнем абстракции, который представляет машине единую гибридную среду в которой находятся все локальные и облачные ресурсы (infrastructure hybridity). Это дает возможность машинам перемещаться между датацентрами, не требуя реконфигурации самих ВМ или инфраструктуры.

VMware Cloud Foundation (VCF) Import Tool

В обновлении платформы VMware Cloud Foundation 5.2 был представлен новый инструмент командной строки (CLI), называемый VCF Import Tool, который предназначен для преобразования или импорта существующих сред vSphere, которые в настоящее время не управляются менеджером SDDC, в частное облако VMware Cloud Foundation. Вы можете ознакомиться с демонстрацией работы инструмента импорта VCF в этом 6-минутном видео.

Инструмент импорта VCF позволяет клиентам ускорить переход на современное частное облако, предоставляя возможность быстро внедрить Cloud Foundation непосредственно в существующую инфраструктуру vSphere. Нет необходимости приобретать новое оборудование, проходить сложные этапы развертывания или вручную переносить рабочие нагрузки. Вы просто развертываете менеджер SDDC на существующем кластере vSphere и используете инструмент импорта для преобразования его в частное облако Cloud Foundation.

Импорт вашей существующей инфраструктуры vSphere в облако VCF происходит без сбоев, поскольку это прозрачно для работающих рабочих нагрузок. В общих чертах, процесс включает сканирование vCenter для обеспечения совместимости с VCF, а затем регистрацию сервера vCenter и его связанного инвентаря в менеджере SDDC. Зарегистрированные экземпляры сервера vCenter становятся доменами рабочих нагрузок VCF, которые можно централизованно управлять и обновлять через менеджер SDDC как часть облака VMware. После добавления в инвентарь Cloud Foundation все доступные операции менеджера SDDC становятся доступны для управления преобразованным или импортированным доменом. Это включает в себя расширение доменов путем добавления новых хостов и кластеров, а также применение обновлений программного обеспечения.

VMware Live Site Recovery

VMware Live Site Recovery (бывший VMware Site Recover, SRM) — это решение для аварийного восстановления (DR), которое также можно использовать для миграции виртуальных машин в среду VCF как часть исполнения DR-плана. Оно является частью комплексного предложения VMware Live Recovery.

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

Последняя версия документации по этому продукту находится здесь.

Компания VMware представила видео "VCF Cloud Console Migration Overview of changes", в котором описываются будущие нововведения для сервис-провайдеров по программе VCPP, которых переведут на новую объединенную консоль VCF Cloud Console, приходящую на смену VCPP Cloud Console.

В видео представлен обзор изменений, которые в ближайшие месяцы будут внедрены в облачный консольный сервис VMware (VCF Business Services). Автор, Алиса Мотри, рассказывает о миграции текущих консолей, таких как cloud.vmware.com, VCPP Cloud Console и usage meters, в новый сервис VCF Business Services Console.

Ключевые моменты:

1. Текущая и будущая архитектуры:
   Текущая система, где сайты и порталы для управления контрактами и лицензиями функционируют независимо, будет заменена на единую архитектуру. В новой системе каждый сайт с активным контрактом будет напрямую связан с VCF Business Services Console.
2. Миграция пользователей:
   Пользователи из текущих организаций VCPP Cloud Console будут перенесены в новый сервис с сохранением их ролей и разрешений. Это позволит минимизировать сбои в работе партнеров.
3. Миграция Usage meters:
   Активные Usage meters, передающие данные о лицензиях Broadcom, также будут перенесены в новую консоль вместе с их отчетами. Usage meters, работающие только с лицензиями VMware, миграции не подлежат.
4. Интеграция через API:
   Партнеры смогут взаимодействовать с новой консолью через API. Однако приложения OAuth, созданные в старой системе, не подлежат переносу, и их потребуется настроить заново.
5. Действия для партнеров:
   Если Usage meters зарегистрированы в нескольких организациях VCPP, рекомендуется связаться с техподдержкой для их объединения перед миграцией.

Эти изменения направлены на упрощение управления и повышения интеграции между сервисами VMware для партнеров.

С выпуском VMware Cloud Foundation (VCF) 5.2 в июле 2024 года VMware представила инструмент VCF Import Tool — новый интерфейс командной строки (CLI), разработанный для упрощения перехода клиентов к частному облаку. Этот инструмент позволяет быстро расширить возможности управления инвентарем SDDC Manager, такие как управление сертификатами, паролями и жизненным циклом, на ваши существующие развертывания vSphere или vSphere с vSAN. Интеграция управления SDDC Manager с вашей текущей инфраструктурой проходит бесшовно, без влияния на работающие нагрузки, сервер vCenter, API vSphere или процессы управления.

Недавно вышло обновление инструмента VCF Import Tool, которое еще больше упрощает импорт существующей инфраструктуры vSphere в современное частное облако. Последний релиз добавляет поддержку более широкого спектра сред и топологий vSphere, а также снимает некоторые ограничения, существовавшие в предыдущих версиях.

Загрузка последних обновлений

Это обновление доступно в составе выпуска 5.2.1.1 для VCF 5.2.1. Чтобы загрузить обновление, войдите в портал Broadcom Software и в разделе «My Downloads» перейдите в «VMware Cloud Foundation», раскройте пункт «VMware Cloud Foundation 5.2» и выберите «5.2.1». Последняя версия инструмента VCF Import (5.2.1.1) доступна на вкладке «Drivers & Tools», как показано на изображении ниже.

Новые возможности VMware Cloud Foundation Import Tool

Возможность импорта кластеров vSphere с общими vSphere Distributed Switches (VDS)

До этого обновления инструмент VCF Import требовал, чтобы у каждого кластера был выделенный VDS. Это соответствовало рекомендуемой практике изоляции кластеров vSphere и избегания зависимости между ними. Однако многие клиенты предпочитают минимизировать количество VDS в своей среде и часто создают единый VDS, который используется несколькими кластерами. С последним обновлением добавлена поддержка как выделенных, так и общих конфигураций VDS. Это дает клиентам гибкость в выборе топологии развертывания VDS и упрощает импорт существующих рабочих нагрузок в Cloud Foundation.

Поддержка импорта кластеров с включенным LACP

Многие клиенты используют протокол управления агрегацией каналов (Link Aggregation Control Protocol, LACP) на своих физических коммутаторах для объединения каналов. Ранее использование LACP с VCF не поддерживалось. Это обновление добавляет поддержку LACP как для преобразованных, так и для импортированных доменов. Теперь использование LACP больше не является препятствием для переноса инфраструктуры vSphere в Cloud Foundation.

Импорт сред vSphere с использованием смешанных конфигураций vLCM Images и Baselines

При развертывании кластеров vSphere VCF предоставляет возможность выбора между использованием образов vSphere Lifecycle Manager (vLCM) и базовых конфигураций (Baselines). Образы vLCM представляют собой современный подход к обновлению программного обеспечения хостов vSphere, основанный на модели желаемого состояния. Базовые конфигурации следуют традиционному подходу, включающему создание базовых профилей и их привязку к кластерам.

Во время перехода клиентов от традиционного подхода с базовыми конфигурациями к новому подходу с образами vLCM многие используют смешанную конфигурацию, где одни кластеры применяют образы, а другие — базовые профили. Ранее VCF требовал, чтобы все кластеры в инвентаре vCenter использовали один тип vLCM. Последнее обновление устраняет это ограничение, добавляя поддержку смешанных сред, где одни кластеры используют vLCM Images, а другие — vLCM Baselines. Это упрощает переход клиентов на VCF, позволяя импортировать существующую инфраструктуру в частное облако Cloud Foundation без необходимости вносить изменения или модификации.

Ослабление ограничений для vSphere Standard Switches и автономных хостов

Помимо изменений, описанных выше, последнее обновление снимает несколько ограничений, ранее мешавших импортировать некоторые топологии. Это включает:

• Разрешение импорта сред vSphere с использованием стандартных коммутаторов vSphere Standard Switches.
• Поддержку сред vSphere с автономными хостами в инвентаре vCenter.
• Поддержку одноузловых кластеров.

При этом важно отметить, что, несмотря на ослабление ограничений для этих компонентов, каждый экземпляр vCenter должен иметь хотя бы один кластер vSphere, соответствующий минимальным требованиям, изложенным в руководстве по администрированию Cloud Foundation.

На портале технических ресурсов Broadcom появилась полезная статья, посвященная производительности облачных приложений и причинам их земедления в производственной среде.

Часто бывает, что приложение, работающее на физическом сервере, демонстрирует хорошую производительность. Однако после упаковки приложения в образ, тестирования в Docker/Podman и последующей миграции в окружение Kubernetes производительность резко падает. По мере увеличения числа запросов к базе данных, выполняемых приложением, время отклика приложения возрастает.

Эта распространённая ситуация часто вызвана задержками ввода-вывода, связанными с передачей данных. Представьте, что это же приложение снова запускается на физическом сервере, но в следующем сценарии: устройство хранения базы данных создаётся на удалённом хранилище с Network File System (NFS).

Это означает, что необходимо учитывать следующие факторы:

• Количество приложений, обращающихся к конечной точке хранилища (предполагается, что оно быстрое по своему устройству).
  Это будет влиять на общую производительность отклика из-за производительности подсистемы ввода-вывода хранилища.

• Способ, которым приложение извлекает данные из базы данных.
  Кэширует ли оно данные, или просто отправляет очередной запрос? Являются ли запросы небольшими или крупными?

• Задержка, вызванная сетевым доступом к хранилищу, и общая скорость работы хранилища.
  При доступе к сетевому устройству несколько ключевых факторов влияют на скорость передачи данных:

  • Доступная скорость соединения
  • Используемое максимальное время передачи (MTU) / максимальный размер сегмента (MSS)
  • Размер передаваемой полезной нагрузки
  • Настройки TCP окна (скользящее окно)
  • Среднее время задержки при прохождении маршрута (RTT) от точки A до точки B в мс.

В датацентре скорость соединения обычно не является проблемой, поскольку все узлы соединены с пропускной способностью не менее 1 Гбит/с, иногда 10 Гбит/с, и подключены к одному коммутатору. MTU/MSS будет оптимальным для настроенного соединения. Остаются размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT. Наибольшее влияние окажут размер полезной нагрузки, задержка соединения и его качество, которые будут влиять на параметры скользящего окна.

Вот пример задержек между узлами в текущей настройке Kubernetes:

При увеличении размера полезной нагрузки пакета в пинге, как только он превышает текущий MTU, время отклика начинает увеличиваться. Например, для node2 размер полезной нагрузки составляет 64k — это экстремальный случай, который наглядно демонстрирует рост задержки.

Учитывая эти три момента (размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT), если разработчик создаёт приложение без использования встроенных возможностей кэширования, то запросы к базе данных начнут накапливаться, вызывая нагрузку на ввод-вывод. Такое упущение направляет все запросы через сетевое соединение, что приводит к увеличению времени отклика всего приложения.

На локальном хранилище или в среде с низкой задержкой (как сети, так и хранилища) можно ожидать, что приложение будет работать хорошо. Это типичная ситуация, когда команды разработки тестируют все в локальной среде. Однако при переходе на сетевое хранилище задержка, вызванная сетью, будет влиять на возможный максимальный уровень запросов. При проведении тех же тестов в производственной среде команды, вероятно, обнаружат, что система, способная обрабатывать, скажем, 1000 запросов к базе данных в секунду, теперь справляется только с 50 запросами в секунду. В таком случае стоит обратить внимание на три вероятные причины:

1. Переменные размеры пакетов, средний размер которых превышает настроенный MTU.
2. Сетевая задержка из-за того, что база данных размещена на отдельном узле, вдали от приложения.
3. Уменьшенное скользящее окно, так как все связанные системы подключаются к узлу базы данных. Это создаёт нагрузку на ввод-вывод файловой системы, из-за чего база данных не может обрабатывать запросы достаточно быстро.

Тесты показали, что алгоритм скользящего окна привёл к снижению скорости передачи данных (для справки: это механизм, используемый удалённым хранилищем на основе NFS). При среднем размере полезной нагрузки 4 Кб скорость передачи данных упала с 12 МБ/с на быстром соединении 1 Гбит/с (8 мс задержки) до ~15 Кбит/с, когда задержка соединения достигла 180 мс. Скользящее окно может вынудить каждую передачу данных возвращать пакет подтверждения (ACK) отправителю перед отправкой следующего пакета на соединениях с низкой задержкой.

Эту ситуацию можно протестировать локально с помощью утилиты tc на системе Linux. С её помощью можно вручную задать задержку для каждого устройства. Например, интерфейс можно настроить так, чтобы он отвечал с задержкой в 150 мс.

На Kubernetes, например, вы можете развернуть приложение с фронтендом, сервером приложений и бэкендом базы данных. Если сервер приложений и бэкенд базы данных развернуты на разных узлах, даже если эти узлы быстрые, они будут создавать сетевые задержки для каждого пакета, отправленного с сервера приложений в базу данных и обратно. Эти задержки суммируются и значительно ухудшают производительность!

Ниже приведён реальный пример, показывающий время отклика приложения. База данных развернута на node2.

В этом случае выполнение приложения требует большого количества запросов к базе данных, что значительно влияет на среднее время отклика затронутых компонентов. В данном случае среднее время отклика составляет 3,9 секунды.

Для этого теста функция graph_dyn запрашивает из базы данных 80 тысяч строк данных, где каждая строка содержит метаданные для построения различных точек графика.

Переместив базу данных на ту же машину, где размещена часть приложения, удалось снизить среднее время отклика до 0,998 секунды!

Это значительное улучшение производительности было достигнуто за счёт сокращения задержек сетевых запросов (round trip), то есть перемещения контейнера базы данных на тот же узел.

Ещё одним распространённым фактором, влияющим на производительность Kubernetes, являются ESXi-среды, где узлы кластера имеют избыточную нагрузку на ввод-вывод сети, а узлы Kubernetes развёрнуты в виде виртуальных машин. Узел Kubernetes не может увидеть, что CPU, память, ввод-вывод диска и/или подключённое удалённое хранилище уже находятся под нагрузкой. В результате пользователи сталкиваются с ухудшением времени отклика приложений.

Как оптимизировать производительность приложения

1. Учтите кэширование в дизайне приложения.
   Убедитесь, что приложение учитывает кэширование (общих запросов, запросов к базе данных и так далее) и не выполняет лишних запросов.

2. Отключите переподписку ресурсов (oversubscription) в средах ESXi.
   Если Kubernetes/OpenShift работают поверх ESXi, убедитесь, что переподписка ресурсов отключена для всех доступных CPU и памяти. Учтите, что даже небольшие задержки могут быстро накопиться и привести к эластичному поведению времени отклика приложения. Кроме того, если хост ESXi уже находится под нагрузкой, запущенные на нём образы не будут осведомлены об этом, и оркестратор Kubernetes может развернуть дополнительные поды на этом узле, считая ресурсы (CPU, память, хранилище) всё ещё доступными. Поэтому, если вы используете Kubernetes/OpenShift, а у вас есть возможность запустить их на физическом сервере, сделайте это! Вы получите прямую и полную видимость ресурсов хоста.

3. Минимизируйте сетевые задержки ввода-вывода в Kubernetes.
   Сократите сетевые задержки ввода-вывода при развёртывании подов. Упакуйте контейнеры в один под, чтобы они развертывались на одном узле. Это значительно снизит сетевые задержки ввода-вывода между сервером приложений и базой данных.

4. Размещайте контейнеры с высокими требованиями к базе данных на узлах с быстрым хранилищем.
   Развёртывайте контейнеры, которым требуется быстрый доступ к базе данных, на узлах с быстрым хранилищем. Учитывайте требования к высокой доступности и балансировке нагрузки. Если хранилище NFS недостаточно быстрое, рассмотрите возможность создания PV (Persistent Volume) на определённом узле с локальным RAID 10 диском. Учтите, что в этом случае резервирование придётся настраивать вручную, так как оркестратор Kubernetes не сможет управлять этим при отказе оборудования конкретного узла.

Как мониторить задержки между компонентами

Для Kubernetes, OpenShift и Docker (Swarm) можно использовать Universal Monitoring Agent (UMA), входящий в решения AIOps and Observability от Broadcom, для мониторинга взаимодействия всего окружения. Этот агент способен извлекать все релевантные метрики кластера. Если UMA обнаруживает поддерживаемую технологию, такую как Java, .Net, PHP или Node.js, он автоматически внедряет пробу (probe) и предоставляет детализированную информацию о выполнении приложения по запросу. Эти данные включают запросы ввода-вывода (I/O) от компонента к базе данных, удалённые вызовы и другие внутренние метрики приложения.

Если приложение работает некорректно, встроенное обнаружение аномалий UMA запускает трассировку транзакций (это не требует дополнительной настройки). UMA собирает подробные метрики с агентов, связанных с компонентами, по пути выполнения конкретного приложения. Эти возможности позволяют получить детализированное представление выполнения приложения вплоть до строки кода, вызывающей замедление. Администраторы могут настроить полный сквозной мониторинг, который предоставляет детали выполнения, включая производительность фронтенда (браузера).

Ниже приведен пример сбора полных сквозных метрик, чтобы команда администраторов могла проанализировать, что пошло не так, и при необходимости принять корректирующие меры:

User front-end => Web-Server front-end => app-server => databases | remote services

Одним из преимуществ этого решения для мониторинга является то, что оно показывает среднее время выполнения компонентов внутри кластера. Со временем решение может начать считать плохие средние значения нормой в среде ESXi с избыточной загрузкой. Тем не менее, оператор может оценить реальные значения и сравнить их с показателями других приложений, работающих на том же узле.

В ноябре этого года компания Broadcom объявила о продолжении эволюции портфолио в сфере серверной виртуализации, включающего в себя платформы VMware Cloud Foundation (VCF) и VMware vSphere Foundation (VVF).

VMware Cloud Foundation остаётся флагманским решением, предоставляя комплексную интегрированную платформу частного облака, которая обеспечивает масштаб и гибкость публичного облака вместе с локальной безопасностью, устойчивостью, производительностью и низкой общей стоимостью владения — как для локальной инфраструктуры, так и для периферии (edge locations), а также публичных и партнерских облаков провайдеров.

Чтобы предложить клиентам более мощное и ценное решение корпоративного класса для гиперконвергентной инфраструктуры (HCI), которое позволяет запускать виртуальные машины и контейнеры с оптимизацией ИТ-инфраструктуры, VMware увеличит объём предоставляемого дискового пространства vSAN в составе VMware vSphere Foundation в 2.5 раза — до 250 GiB на ядро (аналог гигабайт). А для завершения портфеля, для клиентов, сосредоточенных на виртуализации вычислений, теперь будет два издания платформы: VMware vSphere Enterprise Plus (раньше это издание отменили, а теперь возвращают снова) и VMware vSphere Standard. Весь портфель VCF доступен конечным пользователям через дистрибьюторскую сеть или напрямую от Broadcom.

Спасибо Сергею за новость.

На ресурсе Technopedia вышла статья с интригующим заголовком "Cloud Exit: 42% of Companies Move Data Back On-Premises". Интересно узнать, что такой большой процент компаний, оказывается, перемещают свои данные обратно из облака в онпремизную инфраструктуру.

Почему набирает популярность тренд «выход из облака»?

Простыми словами, «выход из облака» — это тренд, при котором компании оптимизируют свою зависимость от облачных сервисов и пересматривают свои расходы на облако, либо планируя полный отказ от облака, либо сокращая его использование. Значительная часть компаний активно пересматривает свои обязательства по использованию облачных решений.

42% организаций, опрошенных в США компанией Citrix в начале этого года, рассматривают возможность или уже переместили как минимум половину своих облачных рабочих нагрузок обратно на локальные инфраструктуры.

Фактически, 94% респондентов, участвовавших в этом недавнем опросе, были вовлечены в проекты, связанные с частичным отказом от облака.

Как отмечается в подробной статистике по облачным расходам, высокая стоимость облачных решений оказалась серьезным сдерживающим фактором для корпораций. Более 43% ИТ-руководителей заявили, что перенос приложений и данных из локальной инфраструктуры в облако оказался дороже, чем ожидалось.

Одним из первых известных случаев «выхода из облака» был пример Dropbox в 2015 году, когда компания сократила операционные расходы на 74,6 миллиона долларов за два года. Несмотря на начальные преимущества масштабируемости и гибкости облачных решений, быстрый рост Dropbox сделал постоянные расходы на облако неприемлемыми.

Некоторые компании растут настолько быстро, что для них имеет смысл создать собственную инфраструктуру с использованием кастомных технологий и отказаться от облака. При этом выход из облака помог им снизить зависимость от облачных сервисов крупных поставщиков, таких как Amazon и Google, за счет использования собственных технологий и создания собственной сети.

Выход из облака: ключевая статистика

• 42% организаций в США рассматривают возможность или уже переместили как минимум половину своих облачных рабочих нагрузок обратно в собственную инфраструктуру.
• 94% респондентов опроса участвовали в каком-либо проекте, связанном с частичным отказом от облака.
• 43% ИТ-руководителей считают, что перенос приложений и данных в облако оказался дороже, чем ожидалось.
• Dropbox сэкономил 74,6 миллиона долларов за два года, сократив использование облачных сервисов.
• Basecamp потратил 3,2 миллиона долларов на облачные сервисы в 2022 году и прогнозирует экономию 7 миллионов долларов за пять лет, перейдя на локальную инфраструктуру.
• В настоящее время доля рынка Amazon Web Services составляет 31%, Microsoft Azure — 25%, Google Cloud — 11%.

«Облако — не благотворительность»

Вице-президент Dropbox по инженерным вопросам и бывший инженер Facebook Адитья Агарвал отметил, что, несмотря на экономию на крупных операциях, облачные провайдеры не предоставляют услуги по себестоимости — они не передают все сэкономленные средства клиентам.

Агарвал сказал: «Никто не ведет облачный бизнес как благотворительность». Когда компании достигают таких масштабов, при которых создание собственной инфраструктуры становится экономически выгодным, это позволяет значительно сэкономить, устранив «облачного посредника» и связанные с этим расходы.

Тем не менее, облако, конечно, не «просто чей-то компьютер», как гласит шутка. Оно принесло огромную пользу тем, кто смог к нему адаптироваться.

Но, как и искусственный интеллект (AI), облачные технологии мифологизировали и преувеличивали как универсальный инструмент для повышения эффективности — романтизировали до такой степени, что повсеместные мифы о его рентабельности, надежности и безопасности побуждали компании без раздумий внедрять их. Эти мифы часто обсуждаются на высоких уровнях, формируя восприятие, которое не всегда соответствует реальности, что приводит к тому, что многие компании принимают решения, не полностью учитывая потенциальные недостатки и реальные проблемы.

Более того, небольшое количество гигантских корпораций с монополистическими тенденциями управляют рынком облачных технологий и влияют на все: от ценообразования до технологических инноваций. Такое неравномерное распределение рыночной силы может подавлять конкуренцию и ограничивать оперативную гибкость, вынуждая компании пересматривать свои облачные стратегии.

Мечты об облаке vs. реальность

В 2019 году Gartner смело предсказала, что 80% предприятий закроют свои традиционные центры обработки данных к 2025 году и перейдут в облако, но насколько это предсказание верно?

Всего три года спустя, в отчете Accenture за 2022 год был представлен неоднозначный прогресс. Хотя девять из десяти компаний признают значительные выгоды от своих инвестиций в облако, только 42% полностью реализовали свои ожидаемые результаты, и лишь 32% считают свои облачные проекты завершенными и удовлетворительными.

Учитывая разрыв между идеализированным восприятием облачных технологий и их фактическим функционированием, компании должны подходить к облаку с более взвешенной перспективой. Давайте разберемся, что такое выход из облака, почему компании оптимизируют облачные решения и как монополистические практики замедляют инновации.

Основные причины отказа от облака

Компании всё чаще пересматривают свои обязательства по использованию облака и изучают возможности стратегий отказа от него. Вот ключевые факторы, которые способствуют изменению настроений на рынке:

1. Финансовые соображения

Все говорят о том, как переход в облако снижает капитальные затраты и устраняет необходимость в физических серверах и оборудовании. И хотя это может быть правдой на первых порах, долгосрочные операционные расходы на облако часто оказываются неожиданно высокими.

Один из примеров — известный поставщик решений для управления проектами Basecamp, чьи ежемесячные расходы на облако достигли примерно $180 000, когда они обнаружили, что услуги облачных провайдеров, таких как Amazon и Google, оказались дороже и сложнее, чем ожидалось.

Потратив $3,2 млн на облачные сервисы в 2022 году, компания подсчитала, что использование локального оборудования будет стоить $840 000 ежегодно. Отказавшись от этого финансового бремени, Basecamp прогнозирует экономию $7 млн за пять лет.

Такая ситуация не уникальна. Многие организации обнаруживают, что постоянные расходы, связанные с облачными сервисами, особенно в отношении масштабирования и хранения данных, могут превышать затраты на поддержку локальной инфраструктуры.
Когда преимущества масштабируемых облачных сервисов уменьшаются, компании с предсказуемым спросом на данные приходят к выводу, что высокая цена за гибкость облачных решений становится неоправданной.

2. Непредсказуемые расходы и избыточность облачных ресурсов

Расходы, которых можно избежать, и избыточные облачные ресурсы стали другой важной проблемой, выявленной в опросе «Стратегия облака 2023» от Hashicorp. 94% респондентов сообщили о ненужных расходах из-за неиспользуемых облачных ресурсов.

Эти расходы часто связаны с поддержанием простаивающих ресурсов, которые не обслуживают реальные операционные нужды компании. Такие раздутые расходы не только не способствуют росту бизнеса, но и отвлекают средства от потенциальных зон развития.

3. Уязвимости в безопасности

Согласно глобальному опросу PwC «Надежды и страхи сотрудников» за 2024 год, около 47% технических лидеров считают облачные угрозы основной проблемой в сфере кибербезопасности. Распространено мнение, что локальная инфраструктура менее безопасна, поскольку она физически доступна.

Но действительно ли это так, или все дело в том, насколько хорошо контролируется доступ? Правда в том, что удаленный доступ значительно увеличивает вероятность кибератак, так как количество потенциальных точек входа для хакеров растет. Кроме того, облако является привлекательной целью для злоумышленников. Более 80% утечек данных в 2023 году были связаны с данными, хранящимися в облаке, а средняя глобальная стоимость утечки составила $4,45 млн.

Крупные компании, такие как Capital One, Twilio, Pegasus Airlines и Uber, в прошлом сталкивались с утечками через AWS. Эти громкие случаи усилили опасения по поводу хранения конфиденциальных данных в облаке.

4. Проблемы с производительностью и надежностью

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

В 2023 году сбои у крупных облачных провайдеров, таких как Oracle, Azure и AWS, приводили к нарушению работы сотен тысяч пользователей каждый раз, что могло приводить к миллионным потерям для компаний. К сожалению, в 2024 году частота облачных сбоев продолжает расти.

5. Монополистические тенденции в облаке

Зависимость от одного поставщика и ограниченная гибкость — серьезные проблемы, с которыми сталкиваются компании, пытающиеся использовать облачные сервисы. С долей рынка в 31% у Amazon Web Services, 25% у Microsoft Azure и 11% у Google Cloud, небольшое количество крупных провайдеров доминирует на рынке.

Из-за такой концентрации власти эти компании получают почти монопольный контроль не только над ценообразованием и условиями предоставления услуг, но и над гибкостью управления технологической инфраструктурой бизнеса. Это также позволяет этим гигантам несправедливо продвигать свои собственные приложения и сервисы, что затрудняет конкуренцию для сторонних решений.

Очевидно, что неконтролируемое доминирование на облачном рынке может замедлить технологические инновации. В феврале 2024 года Google усилил критику Microsoft, предупредив, что стремление Microsoft к облачной монополии может затормозить развитие технологий следующего поколения, таких как AI, и призвал к государственному вмешательству.

Выход из облака или переход на другие сервисы не всегда проходит гладко. Поскольку провайдеры полностью управляют облачной инфраструктурой, клиенты имеют ограниченный контроль над внутренними операциями. Во время отказа или миграции они часто сталкиваются с потенциальными уязвимостями в безопасности, высокими расходами и сложностями в перенастройке.

Хотя издержки на выход из облака постепенно становятся менее серьезной проблемой в 2024 году, соглашения с конечными пользователями (EULA) и политика управления со стороны провайдеров могут еще больше ограничить свободу операций.

Все эти факторы увеличивают риски, связанные с облачными технологиями. Компании должны подходить к облачным решениям с тщательно продуманной стратегией, чтобы извлечь выгоду, не став заложниками своих технологий.

В обновлении платформы VMware Cloud Foundation 5.2 был представлен новый инструмент командной строки (CLI), называемый VCF Import Tool, который предназначен для преобразования или импорта существующих сред vSphere, которые в настоящее время не управляются менеджером SDDC, в частное облако VMware Cloud Foundation. Вы можете ознакомиться с демонстрацией работы инструмента импорта VCF в этом 6-минутном видео.

Инструмент импорта VCF позволяет клиентам ускорить переход на современное частное облако, предоставляя возможность быстро внедрить Cloud Foundation непосредственно в существующую инфраструктуру vSphere. Нет необходимости приобретать новое оборудование, проходить сложные этапы развертывания или вручную переносить рабочие нагрузки. Вы просто развертываете менеджер SDDC на существующем кластере vSphere и используете инструмент импорта для преобразования его в частное облако Cloud Foundation.

Импорт вашей существующей инфраструктуры vSphere в частное облако VCF происходит без сбоев, поскольку это прозрачно для работающих рабочих нагрузок. В общих чертах, процесс включает сканирование vCenter для обеспечения совместимости с VCF, а затем регистрацию сервера vCenter и его связанного инвентаря в менеджере SDDC. Зарегистрированные экземпляры сервера vCenter становятся доменами рабочих нагрузок VCF, которые можно централизованно управлять и обновлять через менеджер SDDC как часть частного облака VMware. После добавления в инвентарь Cloud Foundation все доступные операции менеджера SDDC становятся доступны для управления преобразованным или импортированным доменом. Это включает в себя расширение доменов путем добавления новых хостов и кластеров, а также применение обновлений программного обеспечения.

Обзор инструмента импорта VCF

Существует два способа начать работу с инструментом импорта VCF.

Если у вас еще нет развернутого виртуального модуля (Virtual Appliance) менеджера SDDC в вашем датацентре, первый шаг — вручную развернуть экземпляр устройства в существующей среде vSphere. Затем вы используете инструмент импорта VCF для преобразования этой среды в управляющий домен VMware Cloud Foundation.

Если в вашем датацентре уже работает экземпляр менеджера SDDC, просто обновите его до версии VCF 5.2 и используйте его для начала импорта существующих сред vSphere как доменов рабочих нагрузок VI. Обратите внимание, что помимо импорта и преобразования сред vSphere в VCF в качестве доменов рабочих нагрузок, инструмент импорта VCF также может быть использован для развертывания NSX в преобразованном или импортированном домене. Это можно сделать как во время преобразования/импорта, так и в качестве операции «Day-2», выполняемой в любое время после добавления среды в качестве домена рабочих нагрузок. Также в инструменте импорта есть функция синхронизации, которая позволяет управлять расхождением конфигураций между сервером vCenter и менеджером SDDC. Подробнее об этих функциях будет рассказано ниже.

Требования для использования инструмента импорта VCF

Чтобы начать работу с инструментом импорта VCF, необходимо выполнить несколько требований. Эти требования различаются в зависимости от того, преобразуете ли вы существующую среду vSphere в управляющий домен VCF или импортируете существующую среду vSphere как домен виртуальной инфраструктуры (VI). Начнем с рассмотрения требований, уникальных для преобразования управляющего домена VCF. Затем перейдем к требованиям, общим для обоих случаев использования — преобразования и импорта.

Примечание: требования и ограничения, указанные в этой статье, основаны на первоначальном релизе инструмента импорта VCF, доступного с VCF 5.2. Обязательно ознакомьтесь с Release Notes, чтобы узнать, применимы ли эти ограничения к версии VCF, которую вы используете.

Требования для преобразования кластера vSphere в управляющий домен VCF

Для преобразования существующей среды vSphere в управляющий домен VCF необходимо учитывать два основных требования.

• Во-первых, среда vSphere, которую вы хотите преобразовать, должна работать на версии vSphere 8.0 Update 3 или выше. Это относится как к экземпляру сервера vCenter, так и к хостам ESXi. Эта версия vSphere соответствует спецификации (Bill of Materials, BOM) VCF 5.2. Это требование связано, в частности, с тем, что сначала нужно развернуть виртуальный модуль менеджера SDDC в кластере, а версия 5.2 этого устройства требует версий vCenter и ESXi 8.0 Update 3 (или выше).
• Во-вторых, при преобразовании среды vSphere сервер vCenter должен работать в кластере, который будет преобразован. В документации это называется требованием «совместного размещения» сервера vCenter с кластером.

Требования для импорта кластера vSphere в домен VI VCF

Как и при преобразовании в новый управляющий домен, при импорте среды vSphere в домен VI VCF также необходимо учитывать два основных требования.

• Во-первых, поддерживаемые версии vSphere для импорта в качестве домена VI — это vSphere 7.0 Update 3 и выше. Это включает как экземпляр сервера vCenter, так и хосты ESXi. Минимальная версия 7.0 с обновлением 3 соответствует версии vCenter и ESXi, которая входит в спецификацию VCF 4.5 (BOM).
• Во-вторых, при импорте среды vSphere сервер vCenter должен работать либо в кластере, который преобразуется (совместно размещенный), либо в кластере в управляющем домене.

Общие требования при преобразовании и импорте кластеров vSphere

Помимо указанных выше требований, существуют следующие общие требования для преобразования и импорта инфраструктуры vSphere.

• Все хосты внутри кластера vSphere должны быть однородными. Это означает, что все хосты в кластере должны быть одинаковыми по мощности, типу хранилища и конфигурации (pNIC, VDS и т.д.). Конфигурации серверов могут различаться между кластерами, но внутри одного кластера хосты должны быть одинаковыми.
• Кластеры, которые будут преобразованы или импортированы, должны использовать один из трех поддерживаемых типов хранилищ: vSAN, NFS или VMFS на Fibre Channel (FC). Это часто вызывает путаницу, так как при развертывании с нуля (greenfield deployment) с использованием устройства Cloud Builder для управляющего домена требуется всегда использовать vSAN. Учтите, что требование vSAN не применяется к преобразованным управляющим доменам, где можно использовать vSAN, NFS или VMFS на FC.
• При использовании vSAN минимальное количество хостов для управляющего домена всегда составляет четыре. Однако при использовании NFS или VMFS на FC минимальное количество хостов составляет три. Это также отличается от требований при развертывании с нуля с использованием Cloud Builder.
• Режим расширенной связи (Enhanced Linked Mode, ELM) не поддерживается инструментом импорта VCF. Каждый экземпляр сервера vCenter, который будет преобразован или импортирован в качестве домена рабочих нагрузок VCF, должен находиться в собственной доменной структуре SSO. Таким образом, каждый преобразованный или импортированный экземпляр vCenter создаст изолированный домен рабочих нагрузок в VCF. Это может стать проблемой для клиентов, которые привыкли к централизованному управлению своей средой VCF через одну панель управления. Обратите внимание на новые дэшборды мониторинга VCF Operations (ранее Aria Operations), которые могут помочь смягчить это изменение.
• Все кластеры в инвентаре vCenter должны быть настроены с использованием одного или нескольких выделенных vSphere Distributed Switches (VDS). Учтите, что стандартные коммутаторы vSphere (VSS) не поддерживаются. Более того, если в кластере настроен VSS, его необходимо удалить перед импортом кластера. Также важно отметить, что VDS не могут быть общими для нескольких кластеров vSphere.
• В инвентаре vCenter не должно быть отдельных хостов ESXi. Отдельные хосты нужно либо переместить в кластер vSphere, либо удалить из инвентаря vCenter.
• Во всех кластерах должно быть включено полное автоматическое распределение ресурсов (DRS Fully Automated), и на всех хостах должна быть настроена выделенная сеть для vMotion.
• Все адаптеры vmkernel должны иметь статически назначенные IP-адреса. В рамках процесса преобразования/импорта в менеджере SDDC будет создан пул сетей с использованием этих IP-адресов. После завершения импорта эти IP-адреса не должны изменяться, поэтому они должны быть статически назначены.
• Среды vSphere не могут иметь несколько адаптеров vmkernel, настроенных для одного и того же типа трафика.

Значимые ограничения инструмента импорта в VCF 5.2

После указания требований для использования инструмента импорта VCF важно отметить несколько ограничений, связанных с версией VCF 5.2, о которых нужно знать. Имейте в виду, что рабочие процессы импорта VCF включают функцию «проверки», которая сканирует инвентарь vCenter перед попыткой преобразования или импорта. Если обнаруживаются ограничения, процесс будет остановлен.

Следующие топологии не могут быть преобразованы или импортированы с использованием инструмента импорта VCF в версии 5.2:

• Среда vSphere, настроенная с использованием NSX.
• Среды vSphere, настроенные с балансировщиком нагрузки AVI.
• Среды vSphere, настроенные с растянутыми кластерами vSAN Stretched Clusters.
• Среды vSphere, где vSAN настроен только в режиме сжатия (compression-only mode).
• Кластеры vSphere с общими распределенными коммутаторами vSphere (VDS).
• Среды vSphere с включенной контрольной панелью IaaS (ранее vSphere with Tanzu).
• Среды vSphere, настроенные с использованием протокола управления агрегированием каналов (LACP).
• Среды VxRail.

Установка NSX на преобразованные и импортированные домены рабочих нагрузок

При обсуждении ограничений, связанных с инструментом импорта VCF, мы отметили, что нельзя преобразовывать или импортировать кластеры, настроенные для NSX. Однако после того, как домен будет преобразован/импортирован, вы можете использовать инструмент импорта VCF для установки NSX. Вы можете выбрать установку NSX одновременно с преобразованием/импортом или в любое время после этого в рамках операций Day-2.

Одна важная вещь, которую следует помнить при использовании инструмента импорта VCF для установки NSX на преобразованный или импортированный домен рабочих нагрузок, заключается в том, что виртуальные сети и логическая маршрутизация не настраиваются в процессе установки NSX. Инструмент импорта устанавливает NSX и настраивает распределенные группы портов в NSX Manager. Это позволяет начать использовать распределенный межсетевой экран NSX для защиты развернутых рабочих нагрузок. Однако для того, чтобы воспользоваться возможностями виртуальных сетей и логического переключения, предоставляемыми NSX, требуется дополнительная настройка, так как вам нужно вручную настроить туннельные эндпоинты хоста (TEPs).

Использование инструмента импорта VCF для синхронизации изменений с сервером vCenter

Помимо возможности импортировать существующую инфраструктуру vSphere в Cloud Foundation, инструмент импорта также предоставляет функцию синхронизации, которая позволяет обновлять менеджер SDDC с учетом изменений, внесенных в инвентарь сервера vCenter, что помогает поддерживать согласованность и точность всей среды.

При управлении инфраструктурой vSphere, которая является частью частного облака Cloud Foundation, могут возникнуть ситуации, когда вам потребуется внести изменения непосредственно в среду vSphere. В некоторых случаях изменения, сделанные непосредственно в инвентаре vCenter, могут не быть захвачены менеджером SDDC. Если инвентарь менеджера SDDC выйдет из синхронизации с инвентарем vCenter, это может временно заблокировать некоторые рабочие процессы автоматизации. Чтобы избежать этого, вы запускаете инструмент импорта CLI с параметром «sync», чтобы обновить инвентарь менеджера SDDC с учетом изменений, внесенных в конфигурацию vCenter.

На конференции Explore 2024 в Лас-Вегасе компания VMware представила VMware Cloud Foundation 9 – решение, которое упростит переход от разрозненных ИТ-сред к единой, интегрированной платформе частного облака. VMware Cloud Foundation 9 сделает развертывание, использование и управление безопасным и экономичным частным облаком быстрее и проще, чем когда-либо прежде.

Упрощение развертывания и эксплуатации современной инфраструктуры

VMware Cloud Foundation 9 (VCF 9) разрабатывается с целью упростить процесс развертывания и эксплуатации современной инфраструктуры. Она позволит организациям управлять всей своей инфраструктурой как единым, унифицированным комплексом.

Эта возможность помогает удовлетворить потребности современных приложений, интегрируя передовые функции VMware в платформу частного облака. Основная платформа VCF улучшена за счет набора новых сервисов, что расширяет области ее применения, повышает безопасность и поддерживает комплексную экосистему для разработки приложений.

VCF отвечает потребностям двух ключевых групп: команд инфраструктуры, отвечающих за создание и поддержку ИТ-сред, и потребителей инфраструктуры, таких как инженеры платформ и ученые данных, которые используют эти среды для запуска приложений.

Для команд инфраструктуры VCF 9 предлагает унифицированную платформу, которая автоматизирует и упрощает операции, позволяя эффективно развертывать среды частного облака.

Но давайте уделим внимание тому, как решается задача удовлетворения потребностей разных ролей в различных ИТ-средах.

Расширение возможностей как для администраторов облака, так и для инженеров платформы

Для облачных администраторов VCF 9 предложит упрощенный подход к управлению инфраструктурой. Новая централизованная консоль предоставляет единый обзор среды, позволяя администраторам управлять емкостями и арендаторами, настраивать политики управления и получать доступ к комплексной панели безопасности — все в одном месте.

Включение таких функций, как диагностика VCF и анализ топологии приложений и сети, позволит быстрее решать проблемы и оптимизировать производительность, превращая повседневное управление из рутины в простую организованную операцию.

Для инженеров платформ VCF 9 предлагает среду, готовую к использованию, поддерживающую традиционные виртуальные машины, Kubernetes и контейнеризированные приложения. Расширенные возможности мультиаренды обеспечивают гибкость, необходимую для управления несколькими проектами, сохраняя при этом строгие протоколы безопасности и изоляции.

Инженеры могут легко использовать возможности самообслуживания платформы для быстрого развертывания ресурсов, следуя стандартам управления, установленным облачными администраторами. Такой подход не только повышает продуктивность, но и ускоряет вывод новых приложений на рынок, соответствуя требованиям современных высокоскоростных сред разработки.

Трансформация основной ИТ-инфраструктуры

В Cloud Foundation 9 компания VMware предлагает не только унифицированный опыт, но и возможность непрерывного внедрения инноваций в существующую платформу, представляя прорывные новые функции. Однако, что изменилось в VCF 9, так это инновации как на уровне платформы, так и на уровне отдельных технологий.

Начнем с усовершенствований платформы в целом:

Улучшенный импорт VCF

Интегрирует VMware NSX и различные топологии vSAN непосредственно в среды VCF.
Сокращает время простоя при миграции, обеспечивая бесшовную интеграцию и защиту существующих настроек.

Суверенная мультиаренда VCF

Обеспечивает безопасные, изолированные многопользовательские среды в общей инфраструктуре. Предоставляет индивидуальное управление политиками и ресурсами, увеличивая операционную гибкость.

Операции и безопасность на уровне всех инфраструктур

Централизованное управление всеми развертываниями VCF, улучшая видимость и контроль. Единые конфигурации безопасности по всем активам снижают уязвимости и повышают соответствие требованиям.

Улучшения вычислительных возможностей в VCF9

Начнем с вычислительного стека, где гипервизор находится в центре VCF. Давайте рассмотрим новый набор функций, представленных в VCF 9, которые разработаны для поддержки требований инфраструктуры:

• Расширенное распределение памяти с использованием NVMe - эта функция оптимизирует управление памятью, выгружая холодные данные на хранилище NVMe, при этом горячие данные остаются в DRAM. Это приводит к увеличению консолидации серверов на 40%, что позволяет компаниям запускать больше рабочих нагрузок на меньшем количестве серверов.
• Конфиденциальные вычисления с TDX - обеспечивает улучшенную безопасность за счет изоляции и шифрования рабочих нагрузок, гарантируя целостность данных и конфиденциальность на уровне гипервизора.
• Улучшения службы Kubernetes в vSphere - VCF будет включать готовую поддержку контейнеров Windows, прямое сетевое подключение через VPC и поддержку OVF на нативном уровне, что увеличивает гибкость и масштабируемость контейнеризованных приложений.

Предоставление возможностей хранения с помощью vSAN в VCF 9

Теперь перейдем к стеку хранения данных. vSAN интегрирован в VCF уже много лет и стал основой для развертывания частного облака. Что же будет новым и примечательным в VCF9 в отношении хранения данных?

• Нативная защита данных vSAN-to-vSAN с использованием глубоких снапшотов (Deep Snapshots) - обеспечивает практически мгновенное восстановление данных с RPO в 1 минуту, предоставляя надежное решение для восстановления после катастроф и повышения устойчивости данных.
• Интегрированная глобальная дедупликация vSAN - снижает затраты на хранение на 46% за терабайт по сравнению с традиционными решениями благодаря эффективной дедупликации данных между кластерами.
• Расширенное восстановление vSAN ESA для распределенных сайтов - обеспечивает непрерывность бизнеса, поддерживая операции и доступность данных даже при сбоях на двух сайтах, поддерживая критически важные приложения с использованием архитектуры распределенного кластера.

VCF9 и мощь интегрированных сетей

И наконец, давайте поговорим о сетях. Наличие сетевой инфраструктуры, охватывающей все ваше частное облако, обеспечивающей производительность и соответствие требованиям подключения ваших рабочих нагрузок, имеет ключевое значение. Именно здесь NSX занимает свое место в истории VCF9. Давайте рассмотрим некоторые инновации:

• Нативные VPC в vCenter и автоматизация VCF - упрощает создание и управление безопасными, изолированными сетями, снижая сложность и уменьшая время, необходимое для настройки виртуальных сетей.
• Высокопроизводительная коммутация сети с NSX Enhanced Data Path - обеспечивает до трехкратного увеличения производительности коммутации, удовлетворяя потребности современных приложений, требующих высокой интенсивности передачи данных, и снижая задержку сети.
• Легкий переход от VLAN к VPC - упрощает миграцию от традиционных сетей на основе VLAN к VPC и управление сетью, улучшая безопасность.

Заключение

Предстоящий выпуск VMware Cloud Foundation 9 представляет собой важное усовершенствование в инфраструктуре частного облака, предлагая интегрированные, нативные функции для вычислений, хранения данных и сетей. Это ключевой релиз для любой организации, стремящейся повысить безопасность, оптимизировать производительность и упростить операции в своей ИТ-среде.

Однако, в то время как мы с нетерпением ожидаем инноваций в VCF 9, VMware Cloud Foundation 5.2 уже сегодня делает значительные шаги вперед. Обладая мощными возможностями для управления современной инфраструктурой и модернизации частного облака, VCF 5.2 предлагает мощную платформу, на которой компании могут начать улучшать свои облачные среды уже сейчас.

Для предприятий, стремящихся оставаться конкурентоспособными и безопасными, сейчас самое подходящее время изучить, что может предложить VMware Cloud Foundation, как сегодня, так и в будущем.

На прошлой неделе мы писали о новых возможностях следующих продуктов:

• VMware NSX 4.2
• Aria Operations 8.18
• Aria Suite Lifecycle 8.18
• Aria Operations for Networks 6.3

Все они стали доступны одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware HCX 4.10, предназначенное для миграции с различных онпремизных инфраструктур (как на платформе vSphere, так и Hyper-V или KVM) в облако на базе VMware Cloud и между облаками.

VMware HCX 4.10.0 является минорным релизом, который предоставляет новые функции, улучшения совместимости и удобства использования, а также обновления безопасности и исправления. Важные изменения касаются лицензионного фреймворка, улучшения управления трафиком, миграции, интерконнекта и поддержки различных систем.

Давайте посмотрим на новые возможности VMware HCX 4.10:

Важная информация

В версии HCX 4.9.0 VMware ввела единый лицензионный фреймворк для активации продуктов VMware Cloud Foundation и VMware vSphere Foundation. При обновлении до HCX 4.10 с версии ниже HCX 4.9.0, ознакомьтесь с изменениями в лицензировании и активации, описанными в заметках к релизу HCX 4.9.0. Всем существующим клиентам HCX, не использующим hyperscaler-облака, рекомендуется обновиться как можно скорее для обеспечения наивысшего уровня поддержки и портируемости продуктов VMware.

Улучшения управления трафиком

• Настраиваемое шифрование транспорта для миграции и трафика расширения сети: по умолчанию трафик миграции и расширения сети HCX зашифрован. В этой версии введена опция Service Mesh для активации или деактивации шифрования для каждого из этих сервисов. Отключение шифрования доступно для безопасных сетей Uplink.
• Generic Receive Offload (GRO): для входящего трафика расширения сети можно настроить GRO в настройках Traffic Engineering для Service Mesh, что улучшает производительность приложений.

Улучшения миграции

• Параметризация сайтов с не-vSphere для OS Assisted Migration (OSAM): теперь можно связывать сайты не на базе vSphere с HCX Connector или HCX Cloud Manager для миграции рабочих нагрузок с помощью OSAM, упрощая процесс миграции.
• HCX Assisted vMotion: новый тип миграции, работающий в сочетании с native cross-vCenter vMotion для оркестрации миграций между хостами VMware ESXi.
• Поддержка новых гостевых ОС для OSAM: Поддерживаются дополнительные операционные системы, такие как RHEL 8.9 и выше, Ubuntu 20.04 и 22.04, а также Rocky Linux 8.4 и выше.
• Массовая миграция (per-VM EVC): включает опцию деактивации Enhanced vMotion Compatibility для отдельных виртуальных машин.
• Миграция тегов vCenter: введена репликация тегов vCenter с исходного сайта на целевой сайт для более удобной настройки.

Улучшения интерконнекта

• HCX Intrasite Control Network: Новый тип сети для связи между HCX Interconnect и WAN Optimization, что разгружает задачи от сети Management Network.
• Конфигурация Compute Profile: HCX проверяет, что все профили сети охватывают все кластеры, чтобы предотвратить ошибки развертывания.

Улучшения расширения сети

• Разрешение пересекающихся подсетей: появилась опция разрешения пересекающихся подсетей для Network Extension, что полезно в случаях, когда сети имеют разные vLAN.

Улучшения совместимости

• VMware Cloud Foundation 5.2: HCX 4.10 совместим с VMware Cloud Foundation 5.2, улучшая масштабируемость и отказоустойчивость.
• VMware vSphere/vSAN 8.0 Update 3: поддержка миграций для виртуальных машин, использующих HW версию 21.
• VMware NSX 4.2: поддержка всех сетевых и миграционных функций в средах vSphere с NSX 4.2.
• VMware vSAN Max: возможность использования хранилищ vSAN Max в качестве целевых для мигрируемых рабочих нагрузок.

Улучшения пользовательского интерфейса

• Интерфейс Site Pairs: Теперь связанные сайты отображаются как отдельные карточки.

• Интерфейс Interconnect: локальные менеджеры Interconnect теперь показывают настройки Network Profile, Compute Profile и Service Mesh в одном месте.

• Конфигурация Service Mesh: включает отдельные мастера для создания Service Mesh для сайтов на основе vSphere и не-vSphere.

Эти улучшения делают VMware HCX 4.10.0 более мощным инструментом для миграции и управления сетями, обеспечивая повышение производительности, безопасности и удобства использования.

Подробнее обо всем этом вы можете почитать в Release Notes.

В конце прошлого года компания VMware выпустила версию решения VMware Cloud Director 10.5.1, предназначенного для управления программно-определяемым датацентром сервис-провайдеров. Это был небольшой сервисный релиз продукта, а вот в vCD 10.6 появилось уже довольно много всего нового.

VMware Cloud Director 10.6 теперь доступен в составе предложения VCF (VMware Cloud Foundation), начиная с 27 июня 2024 года.

В этом последнем обновлении вы найдете значительные улучшения и новые функции в следующих областях:

Основная платформа

Трехуровневая аренда

VMware Cloud Director позволяет облачным провайдерам создавать многоуровневую организационную структуру через интерфейс пользователя, известную как модель трехуровневой аренды, для создания субпровайдерских организаций с ограниченными административными привилегиями над определенным набором арендаторов.

С этой возможностью облачные провайдеры могут предоставлять ограниченный доступ к конкретным ресурсам и услугам внутри своей инфраструктуры, при этом гарантируя, что каждый арендатор имеет контролируемый доступ только к нужным ресурсам. Эта усовершенствованная модель аренды также обеспечивает большую масштабируемость, гибкость и безопасность, так как облачные провайдеры могут легко управлять и выделять ресурсы на различных уровнях администрирования.

Этот инновационный подход позволяет облачным провайдерам принимать различные бизнес-модели, такие как:

• Создание субпровайдерских организаций, что способствует вложенной многоуровневой аренде внутри крупных корпоративных организаций, позволяя создавать отдельные административные иерархии для разных отделов или дочерних компаний.
• Перепродажа облачных услуг через партнеров или MSP (managed service providers).

Этот выпуск приносит возможность трехуровневой аренды во все аспекты ресурсов и услуг, доступных через VMware Cloud Director, делая его идеальным решением для облачных провайдеров, стремящихся предлагать гибкие и масштабируемые облачные услуги своим клиентам.

Увеличенные лимиты

Этот выпуск значительно увеличивает максимальные параметры в нескольких областях платформы, таких как:

• Максимальное количество виртуальных машин на инстанс VMware Cloud Director увеличено до 55 000, независимо от состояния питания.
• Количество одновременно поддерживаемых удаленных консолей увеличено до 22 000.
• Максимальное количество пользователей, поддерживаемых платформой, увеличено до 300 000.
• Организационная модель для группы виртуальных датацентров (Org VDC) была переработана в трехуровневую структуру. В рамках этого нового дизайна субпровайдер теперь может управлять группами датацентров, которые могут вмещать до 2000 участников (ранее 16) и делиться сетями и каналами связи между ними.

Множественные снапшоты ВМ и vApp

VMware Cloud Director теперь предлагает улучшенную гибкость для виртуальных машин и vApps с возможностью делать множественные снимки ВМ или vApp, до максимального количества, установленного вашим облачным провайдером.

Content Hub

Администраторы кластеров Kubernetes теперь могут определять точные контрольные точки доступа, предоставляя индивидуальным пользователям или группам персонализированные разрешения на доступ к конкретным кластерам, пространствам имен или приложениям. Эта функция позволяет создать multi-tenant архитектуру, позволяющую нескольким организациям безопасно сосуществовать в одном Kubernetes окружении, каждая с изолированным пространством имен для развертывания, управления и контроля своих контейнеризованных рабочих нагрузок.

Также была выпущена новая версия Content Hub Operator, которая работает нативно в кластере Kubernetes и использует протокол WebSocket для высокопроизводительной связи с VMware Cloud Director. Оператор также предоставляет отчеты о совместимости в реальном времени на портал арендатора, позволяя владельцам кластеров принимать информированные решения о времени обновления для обеспечения бесшовной интеграции с VMware Cloud Director.

Распределенный глобальный каталог

Он позволяет создать глобальную мультисайтовую облачную архитектуру, обеспечивая бесшовный доступ к каталогам через несколько сайтов VMware Cloud Director (VCD), предоставляя единый каталог для арендаторов, независимо от инстанса vCenter или инфраструктуры SDDC. Вы можете использовать независимые от поставщика решения для совместного хранения данных (такие как NetApp, Dell, vSAN и т.д.), чтобы реплицировать данные и обеспечить глобальную согласованность каталога.

Множественные протоколы IDP и локальные пользователи

VMware Cloud Director позволяет организациям использовать несколько протоколов поставщиков индентификации (IDP), включая LDAP, SAML и OpenId Connect (OIDC), для более комплексного подхода к аутентификации. Используя внешних поставщиков, вы можете воспользоваться последними достижениями в технологиях аутентификации. Стоит отметить, что локальные пользователи по-прежнему поддерживаются в текущем выпуске, их использование в производственной среде прекращается, но они будут полностью поддерживаться до следующего крупного выпуска VMware Cloud Director.

Улучшенная производительность развертывания шаблонов ВМ

При развертывании шаблона ВМ на другом vCenter, используя VMware Cloud Director, система использует двухфазный подход для обеспечения эффективного развертывания. Изначально она пытается ускорить процесс путем клонирования шаблона ВМ напрямую, используя скорость и эффективность этого метода. Этот подход позволяет системе быстро создать новый инстанс ВМ без издержек на экспорт и импорт ВМ как OVF-файл. Однако, если операция клонирования сталкивается с любыми проблемами или ошибками, система автоматически переключается на более традиционный метод, используя экспорт/импорт OVF для развертывания ВМ. Этот резервный подход обеспечивает успешное завершение процесса развертывания, даже в случаях, когда клонирование может быть невозможным.

Улучшенное управление шифрованием

VMware Cloud Director 10.6 вводит несколько улучшений в функции управления шифрованием:

• Одновременная регистрация нескольких поставщиков ключей, обеспечивающая большую гибкость и масштабируемость.
• Имя кластера можно редактировать во время публикации поставщика ключей, что позволяет сервис-провайдерам легко идентифицировать, какой поставщик ключей принадлежит какому арендатору.
• При аутентификации поставщика ключей или регистрации нового ключа пользователи теперь могут выбрать генерацию нового ключа для каждой операции шифрования, обеспечивая дополнительную безопасность.
• Введена новая функция ротации ключей, позволяющая автоматическую ротацию ключей на основе настроек конфигурации. Этот процесс ненавязчив и обеспечивает бесшовное шифрование.
• VMware Cloud Director 10.6 вводит новую функцию, позволяющую пользователям применять различные политики шифрования к различным политикам хранения, предоставляя большую гибкость и настройку в их стратегиях шифрования.
• При удалении политики шифрования VMware Cloud Director 10.6 теперь предоставляет возможность "не перешифровывать" ранее зашифрованные данные.

Поддержка vSAN 4.1 NFS

VMware Cloud Director 10.6 теперь включает поддержку vSAN 4.1 NFS, обеспечивая безопасное совместное использование файлов с аутентификацией Kerberos. Эта интеграция позволяет использовать vSAN 4.1 как надежное и безопасное хранилище, предоставляя дополнительную возможность для совместного использования файлов в вашей организации.

Устранение уязвимости CVE-2024-22272

Для получения дополнительной информации об этой уязвимости и ее влиянии на продукты VMware, см. VMSA-2024-0014.

Сеть

Поддержка IPv6 для узлов VMware Cloud Director

VMware Cloud Director поддерживает развертывание ячеек устройств в IPv6 сетях, позволяя клиентам воспользоваться преимуществами современного сетевого протокола, сохраняя совместимость с существующей инфраструктурой.

Индивидуальный монитор здоровья

В рамках постоянных усилий по улучшению пользовательского опыта, VMware добавила Custom Health Monitors в дополнение к существующим HTTP-политикам. С этой функцией арендаторы теперь могут отслеживать и устранять неполадки различных характеристик здоровья своих балансируемых услуг, включая такие метрики, как время ответа, потеря пакетов и ошибки подключения. Это позволяет им принимать проактивные меры для поддержания надежности и отзывчивости услуг.

Логирование балансировщика нагрузки Avi

С новой функцией логирования Avi LB на уровне арендатора, арендаторы и облачные провайдеры теперь могут получить более глубокое понимание использования Avi LB. Эта функция предоставляет детализированное представление о действиях Avi LB, позволяя отслеживать модели использования, устранять события и экспортировать логи для аудита, соответствия и регуляторных целей.

WAF для Avi LB

Интеграция WAF (Web Application Firewall) с Avi LB и Cloud Director открывает новые возможности для клиентов по предоставлению дополнительных услуг своим конечным пользователям. Включение функций безопасности WAF в их портфель услуг позволяет обеспечить улучшенную защиту от веб-атак, повысить удовлетворенность клиентов и укрепить свои позиции на рынке.

С введением WAF появляются следующие преимущества:

• Улучшенная безопасность: WAF помогает защищаться от веб-атак, таких как SQL-инъекции и межсайтовый скриптинг (XSS), фильтруя входящий трафик и блокируя вредоносные запросы.
• Усиленное соответствие: WAF может помочь организациям соответствовать нормативным требованиям, предоставляя видимость веб-трафика и возможность блокировать определенные типы трафика или запросов.
• Увеличение доверия клиентов: предлагая WAF как дополнительную услугу, организации могут продемонстрировать свою приверженность безопасности и укрепить доверие своих клиентов.
• Конкурентное преимущество: WAF может стать ключевым отличием для организаций, стремящихся выделиться на переполненном рынке, так как обеспечивает дополнительный уровень безопасности и защиты.

Управление IP-адресами

Значительные обновления были внесены в управление IP-адресами, с упором на упрощение резервирования IP для рабочих нагрузок и выделения IP-адресов для долгоживущих услуг, таких как виртуальные IP-адреса балансировщиков нагрузки. Эти улучшения призваны соответствовать трехуровневой структуре разрешений, обеспечивая удобный опыт управления жизненным циклом IP-адресов, который исходит из IP-пулов для арендаторов, субпровайдеров и провайдеров.

IPsec VPN на шлюзах провайдеров и пограничных шлюзах

VMware Cloud Director расширил свои возможности IPsec VPN, включив установление туннеля на выделенных шлюзах провайдеров. Обновленная структура управления VPN теперь организована в трехуровневую модель, позволяя арендаторам, субпровайдерам и провайдерам настраивать и управлять VPN. С этой улучшенной возможностью провайдеры могут использовать Border Gateway Protocol (BGP) для контроля, какие IP-префиксы используют VPN. Более того, провайдеры и субпровайдеры могут автоматизировать настройку BGP для своих арендаторов, используя IP-пространства для управления сетевыми назначениями для публичного и частного адресации. Более того, провайдеры и субпровайдеры могут делегировать определенные конфигурации BGP своим арендаторам, предоставляя большую гибкость и контроль.

Новый UX для развертывания контроллеров Avi и NSX Cloud Connectors

VMware Cloud Director 10.6 вводит значительные улучшения в развертывание контроллеров Avi и NSX Cloud Connectors, тем самым увеличивая масштабируемость Avi LB. Новый пользовательский опыт позволяет администраторам легко добавлять больше облачных контроллеров к существующим контроллерам Avi, что увеличивает емкость и производительность. Кроме того, UX предоставляет ценные данные о потреблении ресурсов для контроллеров Avi, облаков NSX и пограничных шлюзов, что позволяет администраторам принимать информированные решения о выделении и оптимизации ресурсов.

Интеграция логов безопасности

VMware Cloud Director реализует прием и обработку логов, бесшовно подключаясь к VMware Aria Operations for Logs. Логи NSX Gateway Firewall и Distributed Firewall теперь автоматически обрабатываются VMware Aria Operations for Logs, предоставляя легкий доступ к этим логам через портал арендатора. Эта интеграция позволяет арендаторам быстро находить конкретные события, используя фильтры и временные диапазоны, и экспортировать логи в CSV-файлы для дальнейшего анализа и отчетности.

Object Storage Extension 3.1

В версии расширения VMware Cloud Director Object Storage Extension 3.1 появились следующие новые функции:

• Поддержка MinIO для внешних кластеров Kubernetes.
• Пересылка клиентских IP для настройки доступа к бакетам.
• Улучшенный интерфейс резервного копирования и восстановления Kubernetes для лучшей видимости и управления.
• Обновления OSIS (Object Storage Interoperability Service) для совместимых с S3 поставщиков хранилищ и асинхронного включения арендаторов.

Загрузите OSE 3.1 отсюда и прочитайте документацию по OSE 3.1 здесь.

Несколько полезных ресурсов о VMware Cloud Director 10.6

• Начните с VMware Cloud Director 10.6, загрузив последнюю версию отсюда.
• Для получения подробной информации о том, как использовать и настраивать VCD 10.6, ознакомьтесь с официальной документацией здесь.
• Для получения дополнительных ресурсов и информации о VCD посетите специальную страницу VMware Cloud Director на сайте vmware.com здесь.
• Для просмотра руководства по API прочитайте старое руководство по API здесь и руководство по OpenAPI здесь.

Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.

Руководство предлагает пошаговые инструкции для ручного восстановления вашего экземпляра VMware Cloud Foundation, а также комплексную автоматизацию в виде модуля PowerShell, чтобы ускорить и упростить процесс ручного восстановления, используя данные из инвентаря VCF SDDC Manager для реконструкции конфигураций. Это устраняет необходимость обращаться к документации, которая может быстро устареть в условиях постоянно меняющегося и сложного программно-определяемого центра обработки данных.

Сценарии использования

Примеры сценариев, когда вам может понадобиться этот процесс:

• Полный сбой площадки
• Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
• Катастрофическая логическая порча данных

Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).

Немного о DORA

DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.

DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.

Организации также должны разработать планы обеспечения непрерывности бизнеса и восстановления после аварий для различных сценариев киберрисков, таких как сбои ИКТ-услуг, природные катастрофы и кибератаки. Эти планы должны включать меры по резервному копированию и восстановлению данных, а также процессы восстановления систем.

Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.

Восстановление экземпляра VCF — это не просто на бумаге

Регламенты возлагают на предприятия, такие как финансовые учреждения и связанные с ними поставщики технологий третьих сторон, серьезные обязательства по разработке надежных планов реагирования на сбои их систем.

Организации должны будут проводить периодическое тестирование своих планов, инструментов и систем, чтобы продемонстрировать способность восстанавливать критически важную инфраструктуру в случае сбоев в своевременной и повторяемой манере.

Краткое описание решения

Решение VMware Cloud Foundation Instance Recovery использует комбинацию процессов восстановления из бэкапов, восстановления работоспособности и ребилда данных для воссоздания экземпляра VCF с точно такой же конфигурацией, даже если было утрачено основное оборудование и центр обработки данных, в котором он находился.

• Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
• Выполнение частичного развертывания VCF
• Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
• Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
• Восстановление NSX Edges
• Восстановление рабочих нагрузок (виртуальных машин)
• Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)

Временная шкала восстановления VMware Cloud Foundation Instance Recovery

Чтобы минимизировать время общего восстановления в VMware Cloud Foundation, задачи восстановления могут выполняться в нескольких доменах рабочих нагрузок по перекрывающемуся графику, адаптированному под требования клиентов. Временная шкала предназначена для следующего примера конфигурации:

• 3 домена рабочих нагрузок VI
• Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
• Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
• Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.

Автоматизация с помощью PowerShell

Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.

Это особенно полезно в случаях, когда задачи выполняются многократно, например, для каждого хоста ESXi или для каждой восстанавливаемой виртуальной машины.

Процесс полагается на способность извлекать данные из резервной копии менеджера SDDC, которую вы собираетесь восстановить. Это означает, что автоматизация может восстановить последнюю жизнеспособную резервную копию без необходимости полагаться на актуальность ручных процессов и документации.

Пример извлечения данных конфигурации из резервной копии менеджера SDDC для использования при восстановлении:

После извлечения каждый шаг процесса использует эти данные для контроля и автоматизации реконструкции.

В лабораторных условиях полные экземпляры VCF, включая домен управления и домены рабочих нагрузок VI, были восстановлены всего за два часа. Многие задачи для дополнительных доменов рабочих нагрузок можно выполнять параллельно или в пересекающемся режиме, чтобы минимизировать общее время восстановления экземпляра.

Это уже было протестировано в лабораторной среде одним из крупнейших клиентов VCF, и они очень рады тому, что это решение предлагает им в плане соблюдения нормативных требований.

У Broadcom есть планы по дальнейшему расширению автоматизации и процессов для поддержки дополнительных топологий, конфигураций и технологий, так что следите за обновлениями!

Недавно мы писали о портируемости лицензий VMware Cloud Foundation, которая стала доступной для использования в сертифицированных услугах Pinnacle-партнеров обновленной программы VMware Cloud Service Provider (VCSP). Сегодня мы поговорим о совместной программе Broadcom и Microsoft по портируемости лицензий облачного решения Azure VMware Solution.

Microsoft и Broadcom тесно сотрудничают на протяжении многих лет, поддерживая общих клиентов и продолжая совместно развиваться и внедрять инновации по мере изменения потребностей клиентов. Microsoft и Broadcom расширяют партнерство с планами поддерживать подписки на VMware Cloud Foundation (VCF) в рамках облака Azure VMware Solution. Клиенты, которые владеют или приобретают лицензии на VMware Cloud Foundation, смогут использовать эти лицензии на платформе Azure VMware Solution, а также в своих собственных центрах обработки данных, что даст им гибкость для удовлетворения изменяющихся бизнес-потребностей.

Это предоставляет дополнительный вариант покупки для Azure VMware Solution, который продается и управляется Microsoft с 2019 года. В настоящее время клиенты могут приобретать решение с включенными лицензиями VMware, и эта возможность останется доступной для клиентов, которые предпочитают покупать лицензии VMware в составе решений от Microsoft.

Azure VMware Solution предоставляет полностью управляемую среду VMware, которая управляется и поддерживается со стороны Microsoft. Клиенты могут перемещать рабочие нагрузки VMware в Azure "как есть" с минимальными изменениями или вообще без них. Это упрощает миграцию и позволяет клиентам продолжать использовать знакомые навыки, обучаясь новым навыкам в Azure.

Применяя миграцию на Azure VMware Solution, которое доступно в 33 регионах по всему миру, организации могут воспользоваться масштабируемой и высокопроизводительной облачной инфраструктурой Azure. Клиенты могут развертывать решения с критически важными для бизнеса возможностями, такими как резервное копирование, высокая доступность, защита от угроз и мониторинг производительности. Более того, рабочие нагрузки, выполняемые на Azure VMware Solution, могут быть интегрированы с портфолио Azure из более чем 200 облачных сервисов для ускорения инноваций, получения более глубоких данных с помощью передовых AI-сервисов и модернизации бизнес-приложений.

VMware Cloud Foundation предоставляет частную облачную платформу, которая является универсальной, гибкой и интегрированной на различных облачных эндпоинтах. Развертывая VMware Cloud Foundation на Azure, клиенты получают преимущества высокооптимизированной модели облачных операций, обеспечивающей масштаб и гибкость публичного облака с безопасностью и производительностью частного облака. Работа VCF на Azure позволяет организациям модернизировать ИТ-инфраструктуру с существенным снижением общего объема затрат (TCO), предоставлять разработчикам возможность самообслуживания в частном облаке, что повышает их продуктивность, и достигать лучшей цифровой устойчивости и безопасности.

С улучшенной переносимостью лицензий для клиентов, имеющих соответствующие права на VMware Cloud Foundation, клиенты смогут приобретать подписки на новое программное обеспечение VMware Cloud Foundation и иметь полную мобильность между своей локальной средой и Azure VMware Solution. Клиенты VMware, которые уже приобрели и начали развертывание нового VMware Cloud Foundation, смогут перенести оставшуюся стоимость существующей подписки на Azure VMware Solution. Кроме того, клиенты смогут перемещать свою подписку на VMware Cloud Foundation между локальной средой и Azure VMware Solution по мере изменения их потребностей и требований. Клиенты сохранят права на свою подписку при ее перемещении на VMware Cloud Foundation в рамках Azure VMware Solution.

В дополнение к новой переносимости лицензий VMware, план быстрой миграции VMware предоставляет дополнительный и комплексный набор лицензионных преимуществ и программ, чтобы сократить стоимость и время, необходимое для миграции организаций на Azure VMware Solution. VMware Rapid Migration Plan включает в себя следующие моменты:

• Защита цен. С зарезервированными инстансами клиенты могут зафиксировать цены на год, три или пять лет.
• Экономия на Windows Server и SQL Server. Windows Server и SQL Server - это общие рабочие нагрузки в средах VMware. С программным обеспечением Assurance для локальных лицензий Windows Server и SQL Server организации могут претендовать на скидку Azure Hybrid Benefit для использования существующих лицензий Windows Server и SQL Server в Azure VMware Solution. Бесплатные расширенные обновления безопасности доступны для более старых версий ПО, которое приближается к концу срока службы.
• Поддержка миграции. Используйте Azure Migrate and Modernize, чтобы получить ресурсы, экспертную помощь и финансирование от Microsoft и ее партнерской экосистемы.
• Кредиты Azure. Клиенты, приобретающие новый зарезервированный экземпляр для Azure VMware Solution, могут получить дополнительные кредиты Azure, действительные для Azure VMware Solution или других сервисов Azure.

Переносимость лицензий VMware Cloud Foundation на Azure VMware Solution станет доступной в конце этого года, поэтому сейчас самое подходящее время, чтобы связаться с командой по работе с клиентами или партнером Microsoft для начала планирования перехода.

Решение VMware Cloud Foundation (VCF) помогает организациям модернизировать инфраструктуру частного облака, обеспечивая оптимальной общей стоимостью владения (TCO). Он обеспечивает операционную модель облака, которая предоставляет гибкость и масштабируемость, сохраняя при этом безопасность и производительность.

Как ключевой компонент VMware Cloud Foundation, VCF Automation (VMware Aria Automation) позволяет организациям предоставлять автоматизированный, самостоятельный опыт работы с частным облаком. Новая версия VMware Aria Automation 8.17.0 теперь доступна для всех, и вот основные нововведения и улучшения:

Новая домашняя страница VMware Aria Automation

Теперь есть новая панель управления, разработанная для упрощения и оптимизации пользовательского опыта для администраторов облака. Эта централизованная панель устраняет необходимость переключения между несколькими вкладками, предоставляя всю необходимую информацию в одном удобном месте:

• Обзор облачных сред по сегментам и статусу виртуальных машин
• Резюме инвентори, разбитое по облачным зонам и проектам
• Сводка развертывания с предстоящими изменениями политики аренды и недавно истекшими политиками
• Обзор недавних уведомлений в продукте и возможность ответа на запросы напрямую

Новая стартовая панель теперь также доступна на домашней странице. Администраторы облака могут легко начать работу или выполнять быстрые действия в VMware Aria Automation. Интуитивно понятный хаб предоставляет легкий доступ к следующим действиям с пошаговыми инструкциями:

• Добавление облачных аккаунтов: проверка и привязка облачных аккаунтов с использованием существующих учетных данных
• Управление истечением аренды: создание политик аренды в несколько кликов для управления истечением срока использования ресурсов и их оптимизацией

Эта новая панель управления предоставляет администраторам облака улучшенную видимость их облачной среды. Они могут эффективно управлять облачными ресурсами и напрямую отвечать на запросы, добавлять облачные аккаунты и применять политики аренды - всё это из централизованного места.

Вот как выглядит интерфейс облачного потребления (Cloud Consumption Interface, CCI) для пространства имен Супервизора, Tanzu Kubernetes Grid (TKG) и поддержка других ресурсов в конструкторе Automation Assembler:

CCI для локальных развертываний VMware Aria Automation был выпущен еще в VMware Aria Automation 8.16.2. Интерфейс облачного потребления, работающий на основе VCF Automation, обеспечивает гибкость в опциях потребления для конечных пользователей, при этом сохраняя полный контроль для администратора vSphere. Он предоставляет облачный опыт, аналогичный публичному облаку, который администратор может легко настроить под специфические нужды организации. CCI обеспечивает простой и безопасный доступ самообслуживания ко всем Kubernetes API IaaS в платформе vSphere. Для включения CCI и начала предоставления облачного IaaS в пределах предприятия требуется всего несколько кликов.

Этот релиз VMware Aria Automation 8.17.0 расширяет CCI для VMware Aria Automation Templates, вводя новые элементы шаблонов CCI, которые пользователи могут перетаскивать и настраивать. Это позволяет администраторам использовать шаблоны для развертывания многоуровневых приложений, состоящих из ресурсов Супервизора, работающих на основе виртуальных машин, TKG и других IaaS услуг.

Создание комплексного многоуровневого приложения, включающего настройку виртуальной машины, кластера TKG или других типов ресурсов, может быть сложной и трудоемкой задачей, независимо от того, выбирает ли пользователь CCI UI или CLI. Однако шаблоны каталога могут упростить процесс, объединяя все необходимые элементы в единой платформе Infrastructure-as-Code (IaC), которая может легко справляться даже с самыми сложными настройками. Используя тот же код, который был бы создан через UI или CLI, теперь вы можете выполнить всё это в рабочей области шаблона, делая весь процесс более простым и эффективным.

Теперь администраторы могут настраивать и управлять классами и конфигурациями пространства имен Супервизора, которые можно назначить конкретному проекту для самостоятельного развертывания. Разработчики могут легко развертывать рабочие нагрузки через CCI UI или элемент каталога, подготовленный администратором, который содержит предопределенный шаблон с ресурсами CCI.

Более подробно об этом можно узнать в статье VMware Aria Automation 8.17.0 – Cloud Consumption Interface (CCI) Template Elements.

В дополнение к уже представленным новым функциям, VMware Aria Automation предлагает ряд улучшений, направленных на повышение удобства использования как для администраторов облака, так и для конечных пользователей.

Политика общего доступа к контенту теперь поддерживает область на уровне организации и типы прав доступа, основанных на ролях

Начиная с этого выпуска, политика общего доступа к контенту поддерживает два улучшения:

1. Администраторы облака могут делиться контентом в рамках всей организации, выбирая область как "organization".
2. Администраторы облака могут предоставлять права доступа, основанные на ролях, чтобы позволить участникам команды с выбранными ролями в указанной области делиться контентом.

Эти два улучшения позволяют участникам команды с указанными ролями в выбранной области организации проще делиться контентом.

Интеграция одного экземпляра VMware Aria Operations с несколькими арендаторами VMware Aria Automation

Теперь один экземпляр VMware Aria Operations может интегрироваться с несколькими арендаторами VMware Aria Automation, работающими на одном локальном устройстве. С ростом популярности частных облаков с более сильной многопользовательской архитектурой в стеке VCF, лучшая интеграция между VMware Aria Automation (VCF Automation) и VMware Aria Operations (VCF Operations) позволяет администраторам облака более эффективно мониторить среду частного облака.

Увеличение числа учетных записей частного облака в VMware Aria Automation

С этим выпуском VMware увеличила количество поддерживаемых учетных записей частного облака в VMware Aria Automation с 50 до 100. Это улучшение повышает масштабируемость платформы и позволяет одному экземпляру охватывать больше доменов рабочей нагрузки VCF.

Действие Day-2 для отмены регистрации кластера виртуальных машин

VMware Aria Automation теперь предлагает большую гибкость в управлении виртуальными машинами. Новое действие позволяет пользователям отменять регистрацию кластеров виртуальных машин вместо полного удаления всего кластера из vCenter. Это улучшение позволяет пользователям сохранять кластеры виртуальных машин в vCenter для потенциального будущего использования, удаляя их из области управления VMware Aria Automation. Это действие второго дня помогает всем пользователям лучше управлять своими виртуальными машинами.

Для получения дополнительной информации о релизе VMware Aria Automation 8.17.0 посетите страницу Release Notes.

Продолжаем рассказывать о переходе компании VMware под зонтик бренда Broadcom. Недавно мы рассказывали о веб-ресурсах VMware, которые переехали на сервисы Broadcom, а также о миграции сообществ VMware Communities. Сегодня мы поговорим о том, как Broadcom будет предоставлять возможность переноса лицензий VMware на новую модель лицензирования.

Недавно компания Broadcom объявила, что новая возможность портирования лицензий VMware Cloud Foundation (VCF) теперь доступна для использования в сертифицированных услугах Pinnacle-партнеров обновленной программы VMware Cloud Service Provider (VCSP).

Эта привилегия для лицензий VCF позволяет клиентам развертывать свои существующие лицензии VCF (версии 5.1 или выше, приобретенные после 13 декабря 2023 года) на любом сертифицированном публичном или частном облачном сервисе. Партнеры VCSP уровня Pinnacle теперь могут подавать свои облачные услуги на сертификацию и включение в список сертифицированных облачных сервисов VCF. Это не просто о переходе в облако — это об оптимизации инвестиций и предоставлении бизнесу возможности ориентироваться в облачной среде с более широким выбором партнеров, что дает уверенность клиентов в гибком и надежном исполнении рабочих нагрузок в любом облаке и получении мощностей, соответствующих ключевым корпоративным целям.

Одним из основных преимуществ портирования лицензий (License Portability) является защита инвестиций. Клиенты с новым предложением VCF больше не нуждаются в покупке новых лицензий при переходе своих рабочих нагрузок на сертифицированный облачный сервис VCF, чтобы воспользоваться широкими возможностями управляемых сервисов партнера. Это обеспечивает значительную экономию средств и улучшает возврат инвестиций в подписки VCF.

При переходе на сертифицированный облачный сервис VCF предприятия получают поддержку, опираясь на обширный опыт партнеров. Партнеры VCSP обладают высокой квалификацией в VCF, что обеспечивает клиентам быстрое и полное использование их стека VCF и, следовательно, получение экономии и повышения производительности. Партнеры могут предлагать дополнительные управляемые услуги для эксплуатации, упрощения и оптимизации рабочих нагрузок для клиентов. Это позволяет клиентам сосредоточиться на выполнении проектов, а не тратить время на создание стека и управление развернутыми рабочими нагрузками.

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

Стратегия Broadcom по предоставлению клиентам возможности использовать свои существующие лицензии в сертифицированном облачном сервисе VCF поддерживает их цифровую трансформацию и приводит к осязаемым результатам. В будущем это будет крайне важно для бизнеса, стремящегося максимально использовать свои инвестиции в облачные технологии и сохранять гибкость в условиях изменяющихся отраслевых ландшафтов. Сообщение для корпоративных клиентов таково: ваши инвестиции в VMware Cloud Foundation теперь более ценны и универсальны, чем когда-либо.

Партнеры Broadcom Advantage Pinnacle Service Provider, участвующие в новой программе, должны соблюдать определенные условия и самостоятельно сертифицировать свои среды. Подробные инструкции будут предоставлены в скором времени по каналам VCSP. Клиенты, ищущие поставщика услуг, способного предоставить услуги по портированию лицензий, могут найти подходящих поставщиков на веб-сайте Broadcom или, начиная с июня, в разделе Advantage Insights Cloud Service Provider.

Heath Johnson из VMware представляет обзор решения VMware Cloud Foundation (VCF), которое включает в себя комплексное решение для частных облачных данных, объединяющее вычислительные мощности, хранилища и сетевые технологии. В основе решения лежат гипервизор ESXi и центр управления vCenter, образующие vSphere, интегрированные в VMware Cloud Foundation. Также в состав входят продукты для программно-определяемого хранения данных vSAN и программно-определяемых сетей NSX, которые позволяют создавать виртуальные частные облака.

Для управления операциями в облаке используется пакет продуктов vRealize, который обеспечивает мониторинг, автоматизацию и возможности самообслуживания для развертывания бизнес-приложений. Инициализация системы осуществляется через виртуальный модуль Cloud Builder, который автоматически развертывает ESXi, vCenter, vSAN и NSX, после чего управление и автоматизация переходят к SDDC Manager. Это устройство отвечает за дальнейшее добавление ресурсов и обновление системы, обеспечивая единообразие и упрощение управления инфраструктурой.

VMware Cloud Foundation предлагает эффективное решение для современных ИТ-задач, включая поддержку современных приложений через Kubernetes и AI, упрощая управление данными, приложениями и оборудованием в рамках частного облака на предприятии.

Недавно компания VMware выпустила интересное обзорное видео, посвященное решению VMware HCX, которое предназначено для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.

В этом видео эксперт VMware рассказывает о продукте VMware HCX в контексте сценариев для миграции рабочих нагрузок между различными облачными и локальными средами. Обсуждаются основные проблемы клиентов, связанные с миграцией данных и приложений, и какие решения предлагает VMware HCX для этих вызовов.

Рассматриваются ключевые возможности и версии HCX, включая мобильность рабочих нагрузок, оптимизацию WAN и гибридную связность. Также поднимаются вопросы управления ресурсами датацентров, проактивного избежания катастроф и управления затратами при миграции. Видео охватывает также стратегии выбора облака для специфических рабочих нагрузок и поддержку множественных облачных платформ. Это идеальный обзор для тех, кто хочет глубже понять возможности и преимущества использования VMware HCX в современных IT-инфраструктурах.