Команда VMware Cloud объявила о публичной доступности платформы VMware Cloud Foundation 5.1.1, поддерживающей первоначальный доступ (initial availability, IA) к инфраструктуре VMware Private AI Foundation with NVIDIA в дополнение к новой модели лицензирования решений VCF, что является первым этапом многоэтапной программы по предоставлению полного стека VCF как единого продукта. Ниже представлен обзор этих важных новых возможностей VCF 5.1.1, а также дополнительные ресурсы и ссылки.

Спецификация версий компонентов VMware Cloud Foundation 5.1.1:

VMware Private AI Foundation with NVIDIA

Как было объявлено на конференции GTC AI Conference 2024, Broadcom предоставила первоначальный доступ (initial availability) к VMware Private AI Foundation with NVIDIA в качестве продвинутого аддона к VMware Cloud Foundation. VMware Private AI Foundation открывает новую эру решений инфраструктуры, поддерживаемых VMware Cloud Foundation для широкого спектра случаев использования генеративного AI. Читайте больше о решениях VMware Cloud Foundation для AI и машинного обучения здесь.

VMware Cloud Foundation является основной инфраструктурной платформой для VMware Private AI Foundation with NVIDIA, предоставляющей современное частное облако, которое позволяет организациям динамически масштабировать рабочие нагрузки GenAI по требованию. VMware Cloud Foundation предлагает автоматизированный процесс самообслуживания в облаке, который ускоряет продуктивность для разработчиков, аналитиков и ученых, обеспечивая при этом комплексную безопасность и устойчивость для защиты и восстановления самой чувствительной интеллектуальной собственности организации.

VMware Cloud Foundation решает многие проблемы, возникающие при развертывании инфраструктуры для поддержки рабочих нагрузок GenAI, за счет архитектуры платформы с полным программно-определяемым стеком, объединяя лучшие в своем классе ресурсы GPU, тесно интегрированные с вычислениями, хранением данных, сетями, безопасностью и управлением.

В VMware Cloud Foundation 5.1.1 существуют хорошо задокументированные рабочие процессы в SDDC Manager для настройки и конфигурации домена рабочих нагрузок Private AI. Также имеется мастер настройки каталога автоматизации VCF, который упрощает конфигурацию этих систем. Зв счет интеграции последних релизов Aria с VMware Cloud Foundation 5.1.1, появляются новые возможности управления, которые можно использовать в решениях Aria Operations и Aria Automation.

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

Поддержка новой модели лицензирования VMware Cloud Foundation

Для дальнейшего упрощения развертывания, VMware Cloud Foundation 5.1.1 предлагает опцию развертывания единого лицензионного ключа решения, которая теперь включает 60-дневный пробный период. Дополнительные продукты и аддоны к VMware Cloud Foundation теперь также могут быть подключены на основе единого ключа (отметим, что лицензия vSAN на TiB является исключением на данный момент и все еще должна применяться отдельно). Поддержка отдельных компонентных лицензионных ключей продолжается, но новая функция единого ключа должна упростить лицензирование решений на базе развертываний VMware Cloud Foundation.

VMware Cloud Foundation 5.1.1 доступен для загрузки и развертывания уже сейчас. Доступ к VMware Private AI Foundation with NVIDIA можно запросить здесь.

Дополнительные ссылки:

• VCF 5.1.1 Release Notes
• Изменения в лицензионной политике VMware в конце 2023 года
• Издания VMware vSphere на 2024 год в картинках
• Анонсирована доступность (Initial Availability) решения VMware Private AI Foundation with NVIDIA
• Бета-программа VMware AI for Tanzu Application Service
• Новые инициативы VMware и Intel в сфере Private AI
• Последние инициативы компании VMware в сфере поддержки систем искусственного интеллекта
• Анонсы VMware Explore 2023: VMware Private AI Reference Architecture for Open Source
• Анонсы VMware Explore 2023: инициатива Private AI от VMware и NVIDIA
• Automation Services for VMware Private AI 
• VMware Private AI
• VMware Cloud Foundation

В прошлом году на конференции Explore 2023 компания VMware рассказала об очень интересном продукте - Project Cypress (сейчас он работает на базе возможностей Intelligent Assist). Это решение позволяет интегрировать генеративный AI в решения по безопасности VMware, выступая в роли копилота при расследовании инцидентов информационной безопасности.

В прошлом году мы писали о том, что на конференции Explore 2023 Europe компания VMware анонсировала решение VMware Live Recovery, которое обеспечит защиту от программ-вымогателей (Ransomware) и восстановление после катастроф в VMware Cloud через единую консоль.

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

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

Ransomware и другие катастрофы

Сегодня организации более уязвимы перед атаками программ-вымогателей и сбоями инфраструктуры, чем когда-либо, и цифры говорят сами за себя: 66% компаний сообщили об успешных атаках программ-вымогателей в 2023 году, а 76% столкнулись с шифрованием своих данных. Недавнее исследование сбоев в работе центров обработки данных показало, что даже однодневные инциденты часто обходятся в среднем в 100 тысяч долларов, а некоторые из них превышают 1 миллион долларов, в зависимости от размера центра обработки данных.

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

Уверенное и надежное восстановление

С учетом этого давайте рассмотрим ключевые компоненты, необходимые для обеспечения уверенного, надежного восстановления:

• Антивирус следующего поколения с поведенческим анализом

Для эффективного выявления и сдерживания вредоносного ПО без файлов в точках восстановления необходим поведенческий анализ.

• Изолированная среда восстановления

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

• Изоляция сети виртуальной машины

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

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

Выпуск VMware Live Recovery

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

VMware Live Recovery включает две ключевые технологии: VMware Live Cyber Recovery (ранее это были продукты VMware Cloud Disaster Recovery + VMware Ransomware Recovery) и VMware Live Site Recovery (ранее он назывался VMware Site Recovery Manager).

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

VMware Live Recovery имеет следующие уникальные преимущества:

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

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

Более подробная информация о новом решении VMware Live Recovery представлена здесь.

Интересно, много ли у нас читателей, кто помнит, что такое операционная система (а точнее, ее половинка) Microsoft OS/2? Недавно известный блоггер Вильям Лам выпустил ностальгический пост об установке OS/2 в виртуальной машине на платформе VMware ESXi.

Один софтверный археолог (да-да, software archaeologist) под ником Neozeed сделал видео об установке предрелизной версии OS/2 2.0, созданной совместно Microsoft и IBM под руководством последней (такое тоже было). Развертывание старинной операционной системы было сделано с помощью бесплатного продукта Workstation Player:

Техспот недавно писал о том, что были обнаружены пакеты OS/2 Warp, подготовленные для виртуальных машин.

Поэтому Вильям взял установочные образы OS/2 от Neozeed и без проблем развернул их в виртуальной машине на ESXi 8.0 Update 2b. И все заработало! Кстати, в оригинальной статье Вильяма много интересных ностальгических каментов.

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

Поэтому обнаружение аномалий является важным и может дать интересные инсайты. Рассмотрим следующие сценарии:

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

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

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

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

Алгоритм Хольта-Винтерса

Алгоритм Holt-Winters (HW), разработанный Хольтом и Винтерсом, помогает построить модель для сезонного временного ряда (например, с учетом суточной сезонности). Эта техника улучшает существующие средства обнаружения аномалий Avi Load Balancer, которое использует алгоритм экспоненциально взвешенного скользящего среднего (EWMA). Если EWMA звучит непонятно, то для быстрого освежения памяти хорошо подходит учебник "Прогнозирование: принципы и практика". По сути, EWMA тесно следует за кривой данных, однако он работает так, что периодические компоненты данных просто игнорируются. Этот момент учитывается при декомпозиции сигнала алгоритмом Хольта-Винтерса. Для сравнения прогностических моделей двух алгоритмов рассмотрим интервалы прогнозирования 80% и 95% EWMA и HW при применении к одним и тем же данным.

Для повышения точности не должно быть игнорирования сезонности входного ряда данных. Алгоритм Хольта-Винтерса работает путем разбиения указанного временного ряда на три компоненты:

• Уровень: Можно представить как усреднение входного сигнала.
• Тренд: Представляет собой наклон или общее направление движения данных.
• Сезонность: Отражает периодичность данных.

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

Временной ряд может иметь аддитивную/мультипликативную тенденцию/сезонность. Для простоты в данной статье мы предполагаем применение алгоритма Хольта-Винтерса к временному ряду с аддитивной тенденцией и аддитивной сезонностью (additive-trend-additive-seasonality, HW-AA), так как это ближе к факторам в реальной жизни. Для такого ряда компоненты тренда и сезонности увеличиваются линейно и суммируются, чтобы составить точки данных на прогрессирующих временных срезах. Временной ряд представлен следующим образом:

Где отдельные компоненты вычисляются следующим образом:

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

Несколько слов о параметрах сглаживания alpha, beta, gamma. Как общее руководство, инженеры используют уравнение для определения параметров сглаживания, как это рекомендуется в статье "Обнаружение аномалий во временных рядах для мониторинга сети".

Это уравнение подчеркивает, какую важность мы хотим придать историческим данным. Например, в Avi, когда применяется алгоритм HW к метрике, представляющей пропускную способность приложения, вес 95% придается сэмплам (с интервалам 5 минут) за последний час. Подставим эти значения в уравнение выше:

Эта схема применима и к другим параметрам сглаживания. Обратите внимание, что, как видно из уравнений выше, объем памяти, потребляемый алгоритмом HW, пропорционален сезонному периоду. В контексте аналитического движка Avi это означает занимаемый объем памяти размером 96 КБ на метрику. Поэтому из тысячи метрик, анализируемых Avi, VMware внимательно балансирует применение алгоритма HW только к наиболее значимым сезонным метрикам, не перегружая операции.

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

По оси X отложено время t, а по оси Y - соответствующее значение выборки данных. График представляет собой сравнение исходных и прогнозируемых значений, а также обозначает интервалы прогнозирования с доверительной вероятностью 95%. Легко заметить, что исходные и прогнозируемые данные довольно хорошо совпадают.

Аналитический движок Avi применяет несколько методов обнаружения аномалий к одному временному ряду. Как описано выше, эти методы обнаружения используют варианты EWMA и HW. Таким образом, результаты каждой модели подвергаются режиму консолидации ALL или ANY, где либо все результаты должны согласиться с решением (о маркировке точки данных как аномальной) или же достаточно и одного. Выбор режима консолидации зависит от баланса между ложноположительными и истинными результатами. В режиме ALL ожидаются более частые ложноположительные результаты с более точными истинными, так как диагностика хотя бы одной моделью достаточна для пометки выборки данных как аномальной. В отличие от этого, режим ALL требует единогласного решения алгоритмов, что требует большей уверенности в маркировке выборки данных. Следовательно, это делает более сложным пометку правильных данных как аномальных (соответственно, меньше ложноположительных, но и меньше истинных результатов). В рамках этого подхода VMware предустанавливает режимы в зависимости от конкретной метрики, основываясь на опыте наблюдений.

Вот преимущества подхода Avi:

• Inline - это встроенная функция контроллера доставки приложений (Application Delivery Controller, ADC), она не требует дополнительных настроек или использования стороннего программного обеспечения.
• Быстрый и действенный - обнаружение аномалий выполняется в реальном времени, а администраторам предоставляются средства по автоматизации их обработки (например, добавление ресурсов). Администраторам не нужно вручную блокировать клиентов, запускать новый сервер или увеличивать ёмкость на основе прогнозов использования ресурсов и т. д.
• Интеллектуальный - машинное обучение операционным шаблонам и поведению позволяет аналитическому движку Avi принимать лучшие решения по обнаружению аномалий, прогнозированию нагрузки, планированию эластичной ёмкости и т. д.

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

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

На конференции Explore 2023 компания VMware объявила о новой инициативе в области поддержки систем генеративного AI - VMware Private AI. Сейчас, когда технологии генеративного AI выходят на первый план, особенно важно организовать инфраструктуру для них - то есть подготовить программное и аппаратное обеспечение таким образом, чтобы расходовать ресурсы, необходимые для AI и ML, наиболее эффективно, так как уже сейчас в сфере Corporate AI требуются совершенно другие мощности, чтобы обслуживать эти задачи.

Инвестиции и активность в области исследований и разработок LLM заметно возросли, что привело к обновлению текущих моделей и выпуску новых, таких как Gemini (ранее Bard), Llama 2, PaLM 2, DALL-E и другие. Некоторые из них являются открытыми для общественности, в то время как другие являются собственностью компаний, таких как Google, Meta и OpenAI. В ближайшие несколько лет ценность GenAI будет определяться доработкой и настройкой моделей, адаптированных к конкретным областям бизнеса и отраслям. Еще одним важным развитием в использовании LLM является Retrieval Augmented Generation (RAG), при котором LLM привязываются к большим и разнообразным наборам данных, чтобы предприятия могли взаимодействовать с LLM по вопросам данных.

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

На днях, на конференции NVIDIA GTC, VMware объявила о начальной доступности (Initial Availability) решения VMware Private AI Foundation with NVIDIA.

VMware Private AI Foundation with NVIDIA

VMware/Broadcom и NVIDIA стремятся раскрыть потенциал Gen AI и максимально использовать производительность совместной платформы.

Построенный и запущенный на ведущей в отрасли платформе для частного облака, VMware Cloud Foundation, VMware Private AI Foundation with NVIDIA включает в себя новые микросервисы NVIDIA NIM, модели искусственного интеллекта от NVIDIA и других участников сообщества (таких как Hugging Face), а также инструменты и фреймворки искусственного интеллекта от NVIDIA, доступные с лицензиями NVIDIA AI Enterprise.

Эта интегрированная платформа GenAI позволяет предприятиям запускать рабочие процессы RAG, внедрять и настраивать модели LLM и выполнять эти нагрузки в их центрах обработки данных, решая проблемы конфиденциальности, выбора, стоимости, производительности и комплаенса. Она упрощает развертывание GenAI для предприятий, предлагая интуитивный инструмент автоматизации, образы глубокого обучения виртуальных машин, векторную базу данных и возможности мониторинга GPU. Эта платформа представляет собой дополнительный SKU в дополнение к VMware Cloud Foundation. Обратите внимание, что лицензии NVIDIA AI Enterprise должны быть приобретены отдельно у NVIDIA.

Ключевые преимущества

Давайте разберем ключевые преимущества VMware Private AI Foundation с участием NVIDIA:

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

VMware Private AI Foundation with NVIDIA предлагает архитектурный подход к обслуживанию искусственного интеллекта, обеспечивающий конфиденциальность, безопасность и контроль над корпоративными данными, а также более интегрированную систему безопасности и управления.

VMware Cloud Foundation обеспечивает продвинутые функции безопасности, такие как защита загрузки, виртуальный TPM, шифрование виртуальных машин и многое другое. В рамках услуг NVIDIA AI Enterprise включено программное обеспечение управления для использования рабочей нагрузки и инфраструктуры для масштабирования разработки и развертывания моделей искусственного интеллекта. Стек программного обеспечения для искусственного интеллекта включает более 4500 пакетов программного обеспечения с открытым исходным кодом, включая программное обеспечение сторонних производителей и программное обеспечение NVIDIA.

Часть услуг NVIDIA AI Enterprise включает патчи для критических и опасных уязвимостей (CVE) с производственными и долгосрочными ветвями поддержки и обеспечения совместимости API по всему стеку. VMware Private AI Foundation with NVIDIA обеспечивает средства развертывания, которые предоставляют предприятиям контроль над множеством регуляторных задач с минимальными изменениями в их текущей среде.

• Ускоренная производительность моделей GenAI независимо от выбранных LLM

Broadcom и NVIDIA предоставляют программные и аппаратные средства для достижения максимальной производительности моделей GenAI. Эти интегрированные возможности, встроенные в платформу VMware Cloud Foundation, включают мониторинг GPU, горячую миграцию и балансировку нагрузки, мгновенное клонирование (возможность развертывания кластеров с несколькими узлами с предварительной загрузкой моделей за несколько секунд), виртуализацию и пулы GPU, а также масштабирование ввода/вывода GPU с помощью NVIDIA NVLink и NVIDIA NVSwitch.

Недавнее исследование сравнивало рабочие нагрузки искусственного интеллекта на платформе VMware + NVIDIA AI-Ready Enterprise с bare metal. Результаты показывают производительность, сравнимую или даже лучшую, чем на bare metal. Таким образом, размещение рабочих нагрузок искусственного интеллекта на виртуализированных решениях сохраняет производительность и приносит преимущества виртуализации, такие как упрощенное управление и улучшенная безопасность. NVIDIA NIM позволяет предприятиям выполнять операции на широком диапазоне оптимизированных LLM, от моделей NVIDIA до моделей сообщества, таких как Llama-2, и до LLM с открытым исходным кодом, таких как Hugging Face, с высокой производительностью.

• Упрощение развертывания GenAI и оптимизация затрат

VMware Private AI Foundation with NVIDIA помогает предприятиям упростить развертывание и достичь экономичного решения для своих моделей GenAI. Он предлагает такие возможности, как векторная база данных для выполнения рабочих процессов RAG, виртуальные машины глубокого обучения и мастер автоматического запуска для упрощения развертывания. Эта платформа реализует единые инструменты и процессы управления, обеспечивая значительное снижение затрат. Этот подход позволяет виртуализировать и использовать общие ресурсы инфраструктуры, такие как GPU, CPU, память и сети, что приводит к существенному снижению затрат, особенно для случаев использования, где полноценные GPU могут быть необязательными.

Архитектура

VMware Cloud Foundation, полноценное решение для частного облачного инфраструктуры, и NVIDIA AI Enterprise, полнофункциональная облачная платформа, образуют основу платформы VMware Private AI Foundation with NVIDIA. Вместе они предоставляют предприятиям возможность запуска частных и безопасных моделей GenAI.

Основные возможности, которые следует выделить:

1. Специальные возможности, разработанные VMware

Давайте подробнее рассмотрим каждую из них.

• Шаблоны виртуальных машин для глубокого обучения

Настройка виртуальной машины для глубокого обучения может быть сложным и затратным процессом. Ручное создание может привести к недостатку согласованности и, следовательно, к недостаточной оптимизации в различных средах разработки. VMware Private AI Foundation with NVIDIA предоставляет виртуальные машины для глубокого обучения, которые поставляются предварительно настроенными с необходимыми программными средствами, такими как NVIDIA NGC, библиотеками и драйверами, что освобождает пользователей от необходимости настраивать каждый компонент.

• Векторные базы данных для выполнения рабочих процессов RAG

Векторные базы данных стали очень важным компонентом для рабочих процессов RAG. Они обеспечивают быстрый запрос данных и обновление в реальном времени для улучшения результатов LLM без необходимости повторного обучения этих моделей, что может быть очень затратным и долгим. Они стали стандартом для рабочих процессов GenAI и RAG. VMware применяет векторные базы данных, используя pgvector на PostgreSQL. Эта возможность управляется с помощью автоматизации в рамках инфраструктуры служб данных в VMware Cloud Foundation. Сервис управления данными упрощает развертывание и управление базами данных с открытым исходным кодом и коммерческими базами данных из одного интерфейса.

• Мастер настройки каталога

Создание инфраструктуры для проектов искусственного интеллекта включает несколько сложных шагов. Эти шаги выполняются администраторами, специализирующимися на выборе и развертывании соответствующих классов виртуальных машин, кластеров Kubernetes, виртуальных графических процессоров (vGPU) и программного обеспечения для искусственного интеллекта/машинного обучения, такого как контейнеры в каталоге NGC.

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

Для решения этих проблем VMware Cloud Foundation представляет мастер настройки каталога (Catalog Setup Wizard) - новую возможность Private AI Automation Services. На начальном этапе LOB-администраторы могут эффективно создавать, составлять и предоставлять оптимизированные объекты каталога инфраструктуры искусственного интеллекта через портал самообслуживания VMware Cloud Foundation. После публикации DevOps исследователи данных могут легко получить доступ к элементам каталога машинного обучения и развернуть их с минимальными усилиями. Мастер настройки каталога снижает ручную нагрузку для администраторов и сокращает время ожидания, упрощая процесс создания масштабируемой инфраструктуры.

• Мониторинг GPU

Получая видимость использования и метрик производительности GPU, организации могут принимать обоснованные решения для оптимизации производительности, обеспечения надежности и управления затратами в средах с ускорением на GPU. С запуском VMware Private Foundation with NVIDIA сразу доступны возможности мониторинга GPU в VMware Cloud Foundation. Это дает администраторам дэшборды с информацией об использовании GPU в рамках кластеров и хостов, в дополнение к существующим метрикам мониторинга.

• NVIDIA NIM

NVIDIA NIM - это набор простых в использовании микросервисов, разработанных для ускорения развертывания GenAI на предприятиях. Этот универсальный микросервис поддерживает модели NVIDIA AI Foundation Models - широкий спектр моделей - от ведущих моделей сообщества до моделей, созданных NVIDIA, а также индивидуальные пользовательские модели искусственного интеллекта, оптимизированные для стека NVIDIA. Созданный на основе фундаментальных компонентов NVIDIA Triton Inference Server, NVIDIA TensorRT, TensorRT-LLM и PyTorch, NVIDIA NIM предназначен для обеспечения масштабируемых и гибких моделей AI.

• NVIDIA Nemo Retriever

NVIDIA NeMo Retriever - это часть платформы NVIDIA NeMo, которая представляет собой набор микросервисов NVIDIA CUDA-X GenAI, позволяющих организациям без проблем подключать пользовательские модели к разнообразным бизнес-данным и предоставлять высокоточные ответы. NeMo Retriever обеспечивает поиск информации самого высокого уровня с минимальной задержкой, максимальной пропускной способностью и максимальной конфиденциальностью данных, позволяя организациям эффективно использовать свои данные и генерировать бизнес-инсайты в реальном времени. NeMo Retriever дополняет приложения GenAI расширенными возможностями RAG, которые могут быть подключены к бизнес-данным в любом месте их хранения.

• NVIDIA RAG LLM Operator

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

• NVIDIA GPU Operator

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

• Поддержка ведущих производителей серверного оборудования

Платформа от VMware и NVIDIA поддерживается ведущими производителями серверного оборудования, такими как Dell, HPE и Lenovo.

Более подробно о VMware Private AI Foundation with NVIDIA можно узнать тут и тут.

Продолжаем рассказывать о возможностях решения VMware Cloud Director Object Storage Extension, которое предназначено для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. О версии 2.1.1 этого продукта мы писали вот тут, а сегодня расскажем про версию Cloud Director Object Storage Extension 3.0, которая вышла недавно.

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

1. Установка VMware Cloud Director Add-on

Ключевым нововведением в версии 3.0 является упрощенный процесс установки VMware Cloud Director Object Storage Extension. Эта функция расширила доступность решения для провайдеров, поскольку администраторы теперь могут удобно устанавливать, обновлять и удалять расширения напрямую из пользовательского интерфейса аддонов VMware Cloud Director. Облачные провайдеры могут обеспечить более плавную работу с задачами в результате этого обновления.

Будучи установленным в качестве аддона решение работает как контейнерное приложение в среде Kubernetes. Облачные провайдеры могут развертывать расширение на мультиоблачный кластер Tanzu Kubernetes Grid или на кластер Kubernetes, соответствующий стандартам CNCF, за пределами VMware Cloud Director. Это улучшение предлагает гибкость и простую интеграцию с различными конфигурациями инфраструктуры, расширяя возможности развертывания для облачных провайдеров. Кроме того, интеграция с Tanzu Kubernetes Grid приносит дополнительные преимущества, например оптимизированную работу через стандартные пакеты, такие как Contour для балансировки нагрузки сервиса, Cert-manager для управления сертификатами TLS и метрики сервиса Grafana.

2. Конфигурация развертывания Day-2 через пользовательский интерфейс

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

3. Интеграция VMware Cloud Director с решениями для данных

Версия 3.0 представляет интуитивную интеграцию с экземплярами VMware Postgres из Solutions organization, что позволяет администраторам провайдера назначать их в качестве базы данных для Object Storage Extension. Эта интеграция упрощает задачи управления базами данных и повышает общую эффективность продукта.

4. Накатываемые обновления

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

5. Улучшения для S3 и OSIS

Версия 3.0 принесла значительные улучшения в плане поддержки S3, включая возможность возврата ARN для арендаторов и улучшенный пользовательский опыт для защиты кластера Kubernetes. Кроме того, интерфейс Object Storage Interoperability Services (OSIS) был улучшен для адаптации к различным поставщикам хранилищ, что улучшило совместимость и взаимодействие.

6. Обновленная матрица поддержки

Версия 3.0 вводит обновленную матрицу поддержки, сертифицируя новые версии продуктов, включая VMware Cloud Director, VMware Cloud Director Container Service Extension и различные платформы хранения. Это обеспечивает совместимость и надежность для провайдеров, использующих облачные инфраструктурные решения VMware.

Ознакомьтесь с Release Notes и страницей документации, чтобы получить глубокое понимание новых функций, процесса обновления и ограничений. Вы можете обновиться напрямую до Cloud Director Object Storage Extension 3.0 с версий 2.X. Подробнее об этом рассказано тут.

Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

• Версия vCenter 8.0.2 сборка 22385739
• 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
• VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
• Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
• OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

• NVME 0:0 – 80G для OS (/)
• NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
• NVME 0:2 – 100G для GRID_DG
• NVME 0:3 – 200G для DATA_DG
• NVME 0:4 – 200G для DATA_DG
• NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
• NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

• Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
• Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
• Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

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

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

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

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

• Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
• Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
• Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

В рамках сессии Best Practices for Hardening Your VMware Infrastructure на конференции VMware Explore 2023 был рассмотрен подход к комплексному обеспечению безопасности и активной защите виртуальной инфраструктуры:

Вот ключевые моменты, рассмотренные в видео выше:

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

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

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

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

5. Оценки безопасности должны охватывать всю ИТ-экосистему - при проведении оценки безопасности важно охватить всю ИТ-экосистему. Это включает оценку безопасности инфраструктуры, безопасности виртуальных машин и приложений, соответствия требованиям, восстановления после аварий и непрерывности бизнеса, а также управления, рисков и соответствия (governance, risk, and compliance - GRC). Оценивая эти области, вы можете гарантировать, что ваша вся ИТ-инфраструктура безопасна и устойчива.

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

Полный список видеодокладов VMware с конференции Explore 2023 представлен здесь.

В 2022 году надзорный орган Европейского союза (ЕС) - Европейская комиссия - запустила амбициозный проект с целью "обеспечения справедливых и открытых цифровых рынков". Основная цель Закона о цифровых рынках (DMA) заключается в ограничении влияния технологических гигантов и обеспечении их "справедливого поведения в онлайне". Вот шесть онлайн-платформ, определенных как фундаментальные игроки:

• Alphabet
• Amazon
• Apple
• ByteDance
• Meta
• Microsoft

Для этих нескольких платформ еврокомиссия определила ряд бизнес-практик, которые им необходимо изменить в течение ближайших лет, чтобы соответствовать DMA. В случае Apple еврокомиссия считает, что App Store, Safari и Apple Pay считаются "основными сервисами платформы", и что конкурирующим разработчикам должно быть разрешено предлагать альтернативные решения для пользователей iPhone и iPad. В результате в iOS 17.4 было внесено несколько изменений, которые с течением времени значительно повлияют на пользователей в ЕС.

Альтернативные бесконтактные платежные системы

Теперь компании могут разрабатывать решения, использующие технологию бесконтактных платежей (NFC) любым способом, обеспечивающим плавность и удобство, чтобы создавать альтернативные платежные системы tap-and-go, конкурирующие непосредственно с Apple Pay в ЕС. Для того чтобы воспользоваться этой возможностью и конкурировать с Apple Pay, компаниям необходимо получить соответствующие разрешения разработчика. Процесс получения разрешения позволяет Apple обеспечить следующее:

• Разработчики будут платить за использование технологии NFC, на которую Apple потратила значительное время и ресурсы на ее создание.
• Конкуренты, конечно же, должны иметь лицензию у соответствующих органов для предоставления платежных услуг в Европейской экономической зоне (European Economic Area, EEA).
• Разработчики будут соблюдать основные дизайн-принципы Apple.

Варианты для клиентов решения VMware Workspace ONE (недавно продукт был продан компании KKR)

Если вы являетесь клиентом Workspace ONE и имеете опасения относительно альтернативных платежных систем, работающих на корпоративных устройствах, вы можете просто заблокировать загрузку приложений. С помощью функций mobile device management (MDM) вы также можете использовать профиль ограничений для удаления App Store. Чтобы скрыть отдельные приложения и предотвратить их запуск, вы можете использовать функцию Hide App в профиле Restrictions profile. Для получения дополнительных способов блокировки приложений на корпоративных устройствах с помощью Workspace ONE ознакомьтесь с руководством на Tech Zone.

Альтернативные магазины приложений

С момента появления iPhone миллионы пользователей iOS имели единственное место для загрузки приложений — App Store. Поэтому наиболее значимым изменением в iOS 17.4 является появление альтернативных маркетплейсов приложений, конкурирующих непосредственно с App Store в ЕС. Разработчики приложений также могут использовать альтернативных поставщиков платежных услуг (payment service providers, PSP), чтобы реализовывать покупки в приложениях или отправлять пользователей на сторонние веб-сайты для проведения транзакций. Конечно же, они также могут использовать собственную платежную систему Apple за 3% комиссии (стоимость процессинга).

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

Требования для разработчиков сторонних магазинов приложений

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

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

Требования для разработчиков приложений

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

Теперь разработчики приложений также платят комиссию Apple, называемую Комиссией за базовую технологию (Core Technology Fee, CTF). CTF начинает действовать только после того, как приложение было загружено 1 миллион раз — так что для подавляющего большинства приложений она никогда не будет актуальной. Однако в редких ситуациях это может стать накладным для разработчика. Apple предоставила удобный калькулятор комиссий, чтобы помочь разработчикам быстро понять стоимость своего приложения на альтернативном маркетплейсе.

Важные аспекты для клиентов Workspace ONE

Если у клиентов Workspace ONE возникают опасения относительно альтернативных магазинов приложений на корпоративных устройствах, Apple ввела новый ключ ограничений (Restrictions key), доступный для блокировки их запуска на контролируемых устройствах. Этот ключ будет поддерживаться в следующем релизе продукта Workspace ONE Unified Endpoint Management (UEM). Тем не менее, вы также можете легко реализовать это ограничение как Custom Settings profile, используя следующий XML:

<dict>
        <key>allowMarketplaceAppInstallation</key>
        <false/>
        <key>PayloadDisplayName</key>
        <string>Restrictions</string>
        <key>PayloadDescription</key>
        <string>Block Third-Party App Marketplaces</string>
        <key>PayloadOrganization</key>
        <string></string>
        <key>PayloadType</key>
        <string>com.apple.applicationaccess</string>
        <key>PayloadUUID</key>
        <string>a9f1b84e-6695-4f47-bcfa-e6334228bce1</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadIdentifier</key>
 <string>786da36c-8283-48cd-9a23-91dde10cf4d3.Restrictions</string>
</dict>

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

Также профиль ограничений можно использовать для удаления подозрительных приложений с контролируемых устройств с помощью функции Hide Apps. Для получения дополнительной информации о способах блокировки приложений на корпоративных устройствах с помощью Workspace ONE ознакомьтесь с обучающим руководством на Tech Zone.

Браузерные приложения и альтернативные браузерные движки в ЕС

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

Управление приложениями по умолчанию и расширенная совместимость

Кроме перечисленного, Apple позволяет пользователям устанавливать магазины приложений по умолчанию и приложения для бесконтактных платежей по умолчанию. Кроме того, Apple также открыла доступ к более чем 250 000 API-интерфейсам разработчиков для предоставления сторонним приложениям доступа к основным технологиям платформы, таким как Bluetooth-радио, камера и микрофон устройства. Форма запроса на совместимость должна быть заполнена и утверждена Apple для доступа к этому расширенному API.

Возможны дополнительные изменения

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

iOS 17.4 уже доступна

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

Продолжаем рассказывать о решении VMware vSAN Max, которое было анонсировано в рамках конференции VMware Explore 2023 в августе прошлого года.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволяет получить модель развертывания на базе подписки для отдельных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max в рамках отдельных или растянутых кластеров, пользователи могут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max лицензируется отдельно от существующих версий vSAN.

VMware vSAN Max показывает значительный прогресс в гиперконвергентной инфраструктуре (HCI) и решает проблемы хранения данных, с которыми администраторы сталкиваются в современном цифровом мире. Построенный на архитектуре хранилища Express Storage Architecture (ESA) от VMware, vSAN Max предлагает дизагрегированное HCI-решение для хранения данных в масштабах петабайт. Оно обеспечивает беспрецедентный уровень масштабируемости, гибкости и экономичности хранения для ИТ-инфраструктур.

Проблемы современных хранилищ данных

1. Масштабируемость и гибкость

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

2. Управление затратами

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

3. Требования к производительности

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

4. Простота и эффективность

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

VMware vSAN Max: решение для современных вызовов в ИТ

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

Преимущества VMware vSAN Max:

• Эластичное и независимое масштабирование ресурсов хранения

vSAN Max позволяет пользователям динамически корректировать объем хранения в соответствии с изменяющимся спросом на ресурсы. Он поддерживает расширение ресурсов хранения HCI, позволяя масштабировать до более чем 8.5 петабайт в пределах кластера. Каждый узел vSAN Max может поддерживать до 360 ТБ на хост, достигая плотности хранения до 7 раз выше, чем у традиционных узлов HCI.

• Снижение стоимости владения

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

• Исключительная производительность

Построенный на основе vSAN ESA, vSAN Max оснащен для управления огромными объемами данных и удовлетворения строгих требований к производительности и надежности. Он может обеспечивать до 3.6 миллионов операций ввода-вывода в секунду (IOPS) на кластер хранения, обеспечивая плавную работу приложений с высокими требованиями к хранилищу.

• Упрощенное администрирование

vSAN Max нативно интегрируется с гипервизором VMware vSphere, предоставляя единый опыт управления через vSphere Client. Он включает отдельные разделы интерфейса пользователя для развертывания и мониторинга, тем самым уменьшая зависимость от нескольких консолей управления и упрощая административные задачи.

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

Основные технические подробности о vSAN Max рассмотрены в видео ниже:

Больше интересного о VMware vSAN Max вы можете найти по следующим ссылкам:

• Какие функции Datastore Sharing/HCI Mesh/vSAN Max поддерживаются для растянутых кластеров?
• Гибкие сетевые топологии растянутых кластеров в решении VMware vSAN Max
• Анонсы VMware Explore 2023: vSAN 8 Update 2 и vSAN Max
• Сайзинг пропускной способности соединения между площадками для растянутого кластера vSAN Stretched Cluster
• ReadyNode Profiles Certified for vSAN Max
• Introducing vSAN Max
• vSAN Frequently Asked Questions (FAQ)
• vSAN Max Configuration

Как знают многие администраторы платформы vSphere, после покупки компании VMware гигантом Broadcom было официально решено изменить продуктовую линейку vSphere на модель лицензирования по подписке и оставить два Enterprise-издания - VMware vSphere Foundation (VVF - решение для онпремизных сред) и VMware Cloud Foundation (VCF - облачная платформа на базе различных сервис-провайдеров). Мы это также объясняли в картинках, на которых видно, что большинство продуктов теперь доступны как аддоны к указанным выше изданиям. Также остались и решения для небольших организаций - это VMware vSphere Essentials Plus Kit (VVEP) и VMware vSphere Standard (VVS).

Многие пользователи уже привыкли, что бесплатный гипервизор VMware ESXi Free (он официально назывался vSphere Hypervisor) доступен для скачивания с сайта VMware, но вот уже месяц назад это стало недоступно. Причина проста - бесплатного издания больше нет, виртуализация от VMware теперь поставляется только за деньги.

Официальное оповещение пользователей об этом находится в KB 2107518 от 14 февраля этого года - End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x).

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

Кстати, видно, что энтузиасты, эксперты и блоггеры также не очень довольны этим фактом, поэтому, возможно, Broadcom еще вернется к вариантам бесплатной виртуализации для целей обучения и совсем малых инсталляций. Не зря же в статье базы знаний написано "at this time", поэтому посмотрим...

В начале года мы писали о бета-версии продукта VMware vCenter Converter Standalone 6.6.0 Beta, который предназначен для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere, а также конвертации между форматами виртуальных машин.

На днях компания VMware выпустила финальную версию vCenter Converter Standalone 6.6, где было сделано несколько улучшений и нововведений на базе обратной связи от пользователей, в том числе последней бета-версии.

Давайте посмотрим, что нового в Converter 6.6:

• Добавлена поддержка миграции включенных виртуальных машин, запущенных на платформах Red Hat KVM и Nutanix AHV
• Вспомогательный ISO-образ vCenter Converter helper перенесен на операционную систему Photon OS
• Добавлена поддержка ОС Red Hat Enterprise Linux 8.0 (64-bit) и более поздних минорных версий
• Добавлена поддержка ОС Red Hat Enterprise Linux 9.0 (64-bit) и более поздних минорных версий
• Добавлена поддержка ОС Ubuntu Linux 18.04 LTS (64-bit)
• Добавлена поддержка ОС Ubuntu Linux 20.04 LTS (64-bit)
• Добавлена поддержка ОС Ubuntu Linux 22.04 LTS (64-bit)
• Обновлены иконки в графическом интерфейсе консоли Converter

Скачать VMware vCenter Converter Standalone 6.6.0 можно по этой ссылке. Документация доступна тут.

VMware Aria Suite Lifecycle 8.14 представляет новую возможность для автоматического восстановления кластера менеджера идентификации (Identity Manager Cluster Auto-Recovery).

Новая служба автовосстановления облегчает трудоемкий процесс устранения неисправностей из пользовательского интерфейса Suite Lifecycle.

Все новые развертывания VMware Aria Suite Lifecycle 8.14 поставляются с включенным автоматическим восстановлением кластера менеджера идентификации VMware. Вы можете включить функцию автоматического восстановления кластера для обновленных развертываний в разделе "globalenvironment":

Сервис автовосстановления является службой Linux, работающей на всех трех узлах в кластере vIDM.

Как работают процедуры автовосстановления:

• Сервис pgPool запускается и перезапускается программно.
• Только первичный узел будет иметь примененный кластерный адрес VIP или delegateIP.
• Отсоединение VIO выполняется только на резервных узлах с ролью standby.
• Восстановление синхронизируется на основе статуса узла как основного узла базы данных, а лидер кластера назначается, если все узлы находятся в режиме ожидания.

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

Возможности службы "автовосстановления":

• Устраняет потерю кластерного VIP на узле с ролью primary.
• Разрешает проблемы с кластером из-за сбоев сети.
• Выполняет восстановление выпавшего узла или нескольких узлов кластера.
• Убирает необходимость запускать устранение неисправностей (Remediate) из пользовательского интерфейса, что приводило к перезапуску узлов и временной недоступности.
• Устраняет необходимость перезагрузки узлов vIDM из-за проблем с кластером PostgreSQL.
• Восстановление в случаях значительной задержки репликации (степень «значительности» настраивается в байтах, более 1000 байт задержки между первичными и вторичными узлами).
• Восстановление в редких случаях, когда все узлы находятся в состоянии "standby".
• Предотвращение расхождений в /etc/hosts.

Надо отметить, что для Auto-Recovery нет временного простоя при выполнении скрипта автоматического восстановления. После включения функции пользователи могут перейти в раздел операций Day-2 панели globalenvironment или vIDM, а затем выбрать включить или выключить, и наоборот.

На днях компания VMware анонсировала проверенное решение (Validated Solution) в облаке - Intelligent Network Visibility for VMware Cloud Foundation. Приставка Validated Solution означает, что это решение полностью проверено командой технических специалистов VMware и полностью поддерживается для обозначенных вариантов использования.

Что такое Intelligent Network Visibility for VMware Cloud Foundation?

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

Вот некоторые общие проблемы, возникающие в этих средах, на которых сфокусирован Intelligent Network Visibility for VMware Cloud Foundation:

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

Intelligent Network Visibility - это хорошо спроектированное проверенное решение, которое стремится решить эти проблемы, предоставляя подробные рекомендации по проектированию, внедрению, конфигурации и эксплуатации для клиентов VMware Cloud Foundation. Это дает возможность получить критический взгляд на сетевую инфраструктуру и сделать действия по устранению неполадок более эффективными, реализуя интеграцию продукта VMware Aria Operations for Networks в среду VMware Cloud Foundation и настраивая его для получения информации из различных источников данных.

Обзор решения

Intelligent Network Visibility создан с использованием лучших практик проектирования и принципов VMware, а также шагов по имплементации VMware Aria Operations для сетей, развернутых в среде Aria Suite, в режиме совместимости с VMware Cloud Foundation. Этот фреймворк детализирует решения по проектированию относительно того, как и где развертывать платформу и узлы-коллекторы VMware Aria Operations for Networks, а также рассматривает вопросы сайзинга и масштабирования. В решении также описываются различные источники данных VMware Cloud Foundation и их интеграция в платформу Aria Operations for Networks. Это обеспечивает повторяемый процесс, который может быть адаптирован ко всем клиентским средам VMware Cloud Foundation.

В логическом дизайне ниже платформа Aria Operations for Networks развертывается в домене управления первого экземпляра VMware Cloud Foundation. В каждой среде VMware Cloud Foundation устанавливается узел-коллектор, он интегрируется с каждым из источников данных в средах VMware Cloud Foundation и хранит все данные о потоках внутри узла платформы. Это позволяет авторизованному пользователю подключиться к Aria Operations for Networks, получить полный обзор своей сети и разобраться во многих задачах сети.

Решение Intelligent Network Visibility VMware Validated Solution доступно уже сегодня, получить доступ к нему можно по этой ссылке.

На днях компания VMware выпустила обновления для своей флагманской платформы VMware vSphere 8 Update 2 - ESXi 8.0 Update 2b и vCenter 8.0 Update 2b.

Что нового появилось VMware ESXi 8.0 Update 2b:

• 100 GiB пробной емкости хранения на каждое ядро vSAN - начиная с vSphere 8.0 Update 2b, в рамках предложения VMware vSphere Foundation, вы можете использовать до 100 гибибайт (GiB) хранилища vSAN на каждое лицензированное ядро хоста vSAN без применения лицензионного ключа vSAN. Для емкости, превышающей 100 GiB на каждое ядро vSAN, вы можете приобрести емкость vSAN на тебибайт (TiB) и применить ключ vSAN, отражающий общую сырую емкость хранилища кластера vSAN. Для получения дополнительной информации о отчетах по емкости и лицензировании vSAN смотрите "Разъяснение отчетности по емкости в vSAN" и "Подсчет ядер для VMware Cloud Foundation и vSphere Foundation и TiB для vSAN".
• Добавлена поддержка технологии vSphere Quick Boot для множества серверов: 
  • Dell - MX760c vSAN Ready Node, PowerEdge C6615, PowerEdge XR8610t, R7625 vSAN Ready Node, VxRail VP-760xa, VxRail VS-760
  • HPE - Alletra Storage Server 4110/4140, Cray XD670, ProLiant DL110 Gen11/DL20 Gen11/ProLiant ML30 Gen11
  • Lenovo DN8848 V2
• Исправлена ошибка с необнаружением Apple NVMe на Apple Mac Mini 2018. Об этом написал Вильям Лам.

Более подробно об обновлении VMware ESXi 8.0 Update 2b написано в Release Notes.

Что нового появилось VMware vCenter Server 8.0 Update 2b:

• Агрегация статистики по GPU на уровне хоста и кластера - в этом обновлении vCenter вы можете отслеживать агрегацию метрик GPU на уровне хоста и кластера, что полезно для нагрузок генеративного искусственного интеллекта, традиционных нагрузок AI и других, ускоренных с помощью GPU. В клиенте vSphere, в разделе Monitor > Performance, вы увидите:
  • на уровне хоста: обзорные диаграммы производительности и расширенные диаграммы производительности для использования вычислений на GPU, распределения памяти и температуры на хостах.
  • на уровне кластера: расширенные диаграммы производительности с агрегированной статистикой от хостов для памяти GPU и использования GPU.
• Для получения дополнительной информации смотрите "Работа с расширенными и пользовательскими диаграммами" и "Обзорные диаграммы производительности".
• Обновления vSphere with Tanzu (подробности тут) и Photon OS (подробности здесь).

Более подробно об обновлении vCenter Server 8.0 Update 2b написано в Release Notes.

Скачать VMware vSphere 8 Update 2, включая ESXi 8.0 Update 2b и vCenter Server 8.0 Update 2b можно по этой ссылке.

Пару лет назад мы писали о производительности Microsoft SQL Server в облаке VMware Cloud on AWS для инстанса AWS-i4i.metal. С тех пор много что изменилось, а компания VMware анонсировала новый тип экземпляра m7i для VMware Cloud на AWS, который использует сетевое хранилище NFS вместо vSAN. Это предоставляет клиентам гибкое и масштабируемое хранилище на основе VMware Cloud Flex Storage и Amazon FSx для NetApp ONTAP.

Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.

Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:

Методология

Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.

Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.

Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU

Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.

Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.

Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.

Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.

Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:

Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:

Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).

Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:

Сравнение производительности m7i с i4i

Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.

Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.

Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:

Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.

Рисунок 5 - различие между m7i и i4i:

Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.

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

26 февраля 2024 года Шанкар Иер, генеральный директор EUC, объявил, что глобальная инвестиционная компания KKR заключила окончательное соглашение о покупке подразделения EUC у Broadcom.

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

• EUC будет функционировать как независимая компания с долговременным обязательством предоставлять клиентам продукты и услуги высокого класса.
• KKR поддержит EUC долгосрочными инвестициями для повышения удовлетворенности клиентов и поддержки партнеров.
• И EUC, и KKR опубликовали общедоступные заявления, которые можно найти здесь: сообщение EUC и сообщение KKR.
• Workspace ONE и Horizon будут продолжать предоставлять варианты развертывания для государственного сектора в облачных решениях FedRAMP

EUC и Broadcom полностью привержены поддержанию непрерывного клиентского опыта услуг FedRAMP. Отделение систем FedRAMP Workspace ONE и Horizon от границы авторизации FedRAMP VMware будет осуществляться тщательно спланированным образом. Этот процесс будет продолжаться после официальной даты закрытия сделки с KKR, но обязательства по этому процессу были формально зафиксированы в договорных документах, определяющих взаимные обязательства сторон для достижения желаемого конечного состояния.

В конечном итоге, Workspace ONE будет продолжать функционировать в рамках авторизации FedRAMP VMware до завершения действий по разделению, и EUC получит независимую авторизацию FedRAMP. Horizon будет продолжать предоставлять частные или суверенные облачные решения для соответствия требованиям, включая варианты, размещенные в FedRAMP. Главные приоритеты VMware на протяжении этого перехода - постоянное внимание к безопасности систем Workspace ONE и Horizon, непрерывное поддержание статуса авторизации FedRAMP и непрерывная операционная поддержка наших клиентов. Подробнее об этом рассказано тут.

Недавно компания VMware в составе Broadcom объявила о новой продуктовой линейке VMware Cloud Foundation (VCF). Это комплексное решение, разработанное для управления центрами обработки данных, определяемыми программно (Software-Defined Data Centers, SDDC). Оно бесшовно интегрирует различные компоненты для предоставления единой и эффективной инфраструктуры. Компоненты интеграции в составе VCF способствуют его универсализации, позволяя организациям рационализировать и улучшать операции своих датацентров.

С операционной точки зрения, на первый план выходят два критически важных элемента: учет ресурсов (metering) и биллинг. Эти элементы играют ключевую роль для сервис-провайдеров и партнеров, использующих VMware Cloud Foundation. Metering включает измерение и отслеживание использования ресурсов разной природы, тогда как биллинг обеспечивает точный расчет и выставление счетов за предоставленные услуги через SDDC.

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

Что такое VMware Chargeback?

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

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

Что нового появилось в последнее время?

У сервис-провайдеров, использующих решения VMware, есть хорошее понимание chargeback — подхода к отслеживанию и назначению затрат на основе использования ресурсов. Поставщики услуг обычно знают, как Chargeback интегрируется с VMware Cloud Director, платформой для управления облачными ресурсами и услугами.

Теперь, с выпуском VMware Aria Operations версии 8.16 произошли заметные изменения в работе Chargeback. В этом релизе Chargeback наконец полностью интегрирован в VMware Aria Operations.

В отличие от предыдущих версий, Chargeback теперь не является отдельным приложением - он был плавно интегрирован в большую структуру VMware Aria Operations. Эта интеграция указывает на то, что Chargeback теперь является неотъемлемой частью более обширной и взаимосвязанной платформы. Он перешел от статуса изолированного инструмента к тщательно спроектированному для бесперебойной работы в более широком контексте структуры VMware Aria Operations.

В начале рабочего процесса сервис-провайдеры начинают со страницы VMware Aria Operations. В этом интерфейсе у них есть возможность просто интегрировать Cloud Director с Chargeback. После этого поставщики могут приступить к конфигурации Chargeback и тонкой настройке различных параметров, таких как электронная почта.

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

Однако пользователи-арендаторы могут получить доступ к возможностям Chargeback через портал VMware Cloud Director, используя плагин Operation Manager.

Возможности VMware Cloud Director (VCD) Operations и Chargeback:

• Все возможности Chargeback (ранее известного как VMware Chargeback или Tenant App) теперь доступны нативно в Aria Operations.
• Специализированный стартовый экран для инфраструктурного слоя Cloud Director для всех ключевых возможностей Chargeback и операций.
• Возможность создавать и назначать политики ценообразования Cloud Director через политики Aria Operations.
• Возможность управления представлением для арендатора.
• Поддержка возможностей управления пользователями арендаторов и электронной почтой.
• Поддержка возможностей управления отчетами, оповещениями и уведомлениями арендаторов.
• Просмотр деталей Chargeback по организациям, OVDC, vApp и ВМ.
• Поддержка генерации счетов и планирования.
• Поддержка VMware Cloud Director (VCD 10.5.1 и выше) в Aria Operations на локальных серверах (Aria Operations 8.16).
• Новый и улучшенный плагин менеджера операций в VMware Cloud Director (VCD 10.5.1 и выше).
• Новый процесс миграции для перехода от VMware Chargeback (VMware Chargeback 8.16) к Chargeback на основе VMware Aria Operations (VMware Aria Operations 8.16) и операциям VMware Cloud Director (VCD 10.5.1 и выше).

Более подробно о возможностях Chargeback в Aria Operations можно узнать из документации.

Продолжаем рассказывать о решении VMware Avi Load Balancer, которое недавно стало доступно в качестве балансировщика как услуги (Load Balancer as a Service, LBaaS) для решения Aria Automation 8.16.1.

Часто менеджеров датацентров мучает простой вопрос – как администраторы знают, что приложения находятся в "хорошем" состоянии? В VMware провели огромное количество встреч и дебатов по теме, касающейся "здоровья приложений" - приведем ниже основные моменты статьи сотрудников Avi, касающейся здоровья приложений.

В команде были люди с разным опытом, им всем задали один и тот же вопрос – "что для вас значит здоровье приложения?". Вот некоторые из ответов, которые были получены:

• "Здоровье" – это пропускная способность (throughput), которую может обеспечивать приложение. Если она составляет 10 Гбит/с, это значит, что оно в хорошем состоянии.
• Здоровье плохое, когда CPU и память загружены более чем на 100%.
• Здоровье хорошее, когда задержка (latency) ниже 100 мс.
• Здоровье хорошее, если приложение работает и отвечает на проверки (health checks).

В реальном мире, если спросить вас - "вы считаете, что у меня хорошее здоровье, если я пробежал сегодня 3 мили?", в зависимости от того, кто вы, вы, скорее всего, ответите: "это зависит от разных факторов", "конечно!", "ты пробежал только сегодня или бегаешь каждый день?" или "каков был твой пульс и жизненные показатели после бега?". У вас будет много дополнительных вопросов, чтобы углубиться в детали. С этой точки зрения, теннисист Роджер Федерер, скорее всего, выиграл бы по этому показателю у большинства людей, даже если бы бегал с гриппом. Сделало бы это его здоровым? Конечно нет!

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

Аналогии со здоровьем человека

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

На секунду давайте представим команду Golden State Warriors как веб-приложение. Тогда звездный баскетболист Стефен Карри, вероятно, был бы важным микросервисом в этом приложении. Как бы мы измеряли его здоровье? Конечно, когда Карри здоров, мы ожидаем, что он будет набирать около 30 очков за игру в среднем. Мы также не ожидаем, что он устанет во время игры. В хорошем состоянии здоровья (измеряемом с помощью таких показателей, как пульс, кровяное давление и т. д.) от Карри ожидают, что он будет последовательно и ровно выступать.

Автор применил аналогичную философию к измерению здоровья приложений. Вот определение здоровья от Merriam-Webster, которое он счел релевантным:

"состояние организма в отношении выполнения его жизненно важных функций, особенно оцениваемое субъективно или непрофессионально"

Автор немного улучшил это определение для "оценки здоровья" приложений в Avi:

"Avi Health (Score) – это мера производительности приложения и его постоянства, которая отражает любые риски для приложения в контексте различных факторов, таких как ресурсы и безопасность."

Пока все хорошо. Авторы определили оценку здоровья Avi. Однако оставался "слон в комнате" — как определять термины "производительность", "риски" и т. д. Вот как дальше было конкретизировано определение оценки здоровья:

• Performance Score: оценка производительности приложения отражает способность приложения соответствовать и превосходить SLA (соглашения об уровне обслуживания). Метрики производительности должны однозначно показывать хорошее состояние против плохого и указывать на соответствие приложения SLA. В этом случае метрики, такие как максимальное количество одновременных подключений или транзакций в секунду, стали неприемлемы, поскольку эти метрики не могли быть выражены как хорошие или плохие транзакции. Поэтому в VMware построили платформу, использующую множество метрик производительности, таких как качество ответа, качество соединения и качество опыта клиентов, для представления производительности приложения.
• Resources Risk (Penalty): следующим важным набором метрик было определение, достаточно ли у приложений ресурсов (или выносливости, энергии и т.д.) для постоянного соответствия требованиям производительности. Оценка здоровья Avi комбинирует несколько метрик, таких как использование CPU, использование памяти, использование программной очереди, использование лицензий и т.д. Вместо прямой шкалы были применены человеческие принципы к ресурсам, которые накладывают штрафы только тогда, когда использование ресурсов превышает пороговое значение (скажем, 80%).
• Security Risk (Penalty): так же, как люди лучше работают, когда они находятся в безопасной умственной, физической и социальной среде, в VMware пришли к выводу, что уязвимости приложения должны приводить к снижению его здоровья. Например, использование слабых шифров для SSL приводит к снижению оценки здоровья Avi.
• Application Performance Consistency (Anomaly penalty): тут считается, что согласованность производительности является очень важной мерой здоровья приложения. Неважно, если производительность достаточна в периоды низкой нагрузки, если она снижается в периоды пиковой нагрузки.

Теперь, когда определена оценка здоровья Avi, все еще нужно проработать детали того, как комбинировать качество сети с качеством HTTP-ответа, как рассчитывать оценку, когда и память, и CPU используются более чем на 80% и т.д.

Уточнение алгоритма

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

1. Когда есть две метрики или факторы здоровья различного рода, то используется наименее здоровый фактор для представления Health Score. Например, у человека может быть очень крепкое сердце, но опухоль в головном мозге. Нет смысла вычислять "среднее здоровье" между этими органами, но важно подчеркнуть, что тело не в очень хорошем состоянии из-за опухоли в мозге. Для программного обеспечения выразили эти ситуации как здоровье = min(здоровье_A, здоровье_B), когда необходимо объединить здоровье двух факторов A и B.

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

Еще одним важным моментом было, должно ли здоровье приложения основываться на мгновенных метриках или должно включать историю производительности. Большинство пользователей и сотрудников разделились на две группы: 1) команда с опытом в индустрии аппаратного обеспечения, которая отвечала, что здоровье приложения должно основываться на мгновенной информации и 2) команда с программным/операционным опытом, которая склонялась к анализу тенденций и истории. Опять же, в VMware использовали стратегии принятия решений в области здоровья человека, чтобы разрешить спор – считается, что человек еще не в хорошем здоровье, если он все еще восстанавливается после недавней болезни.

Поэтому было принято решение смотреть на метрики последних 6 часов, чтобы определить оценку здоровья приложения. На платформе Avi Vantage, когда администратор приложения видит идеальную оценку здоровья (100), он может с уверенностью сказать, что за предыдущие 6 часов здоровье приложения было идеальным и приложение соответствовало его ожиданиям по производительности.

Avi Health Score - это основа

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

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

Так что теперь вы знаете, как работает метрика Health Score в Avi, и что означают все эти пункты:

На днях, одновременно с релизом продукта Aria Operations 8.16, компания VMware объявила о доступности для загрузки решения Aria Automation 8.16.1 (ранее о версии Aria Automation 8.16 мы писали вот тут).

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

Как VMware рассказывала ранее в своем блоге, в компании рады объявить о новых возможностях балансировщика нагрузки как услуги (Load Balancer as a Service, LBaaS), реализованных на основе Aria Automation 8.16.1 с Avi Load Balancer, которые усиливают решение по автоматизации сетей VMware Cloud Foundation. Напомним, что Avi доступен как аддон к VMware Cloud Foundation (VCF).

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

Как VMware Cloud Foundation и Avi реализуют модель управления облачными операциями

VCF и Avi вместе упрощают операции с частным облаком на протяжении жизненного цикла - с Day-0 по Day-2. Возможности автоматизации VCF, основанные на Aria Automation, позволяют организациям максимально использовать инвестиции в Avi и масштабировать свои возможности LBaaS.

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

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

Широкий спектр опций, предлагаемых Avi, что было недоступно ранее с NSX-T LB, и гибкая архитектура автоматизации VCF обеспечивают клиентам большую свободу и выбор для предоставления именно тех возможностей LBaaS, которые им нужны.

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

Благодаря встроенным возможностям VCF, администраторы облака смогут предложить командам разработчиков приложений доступ к самообслуживанию для услуг балансировки нагрузки с Day-4 по Day-7 уровень. Это позволит командам приложений и инфраструктуры немедленно развертывать балансировку нагрузки в момент доставки приложения, с минимальными знаниями технологии балансировки нагрузки или необходимостью создания ручных заявок.

О развертывании балансировщика Avi Load Balancer можно почитать вот тут. Release Notes по продукту VMware Aria Automation 8.16.1 доступны тут.

Недавно компания VMware объявила о выпуске решения Aria Operations 8.16, предназначенного для комплексного управления и мониторинга виртуальной среды на платформе VMware vSphere в облаке. В прошлый раз мы писали о нововведениях решения Aria Operations вот тут. Этот релиз сосредоточен на упрощении использования продукта, улучшении производительности и возможностей управления.

Как было недавно объявлено, VMware Aria Operations теперь будет доступно только как часть VMware Cloud Foundation и VMware vSphere Foundation. VMware Cloud Foundation — это комплексное решение, которое сочетает в себе масштабируемость и гибкость публичного облака с безопасностью и производительностью частного облака. Aria Operations больше не продается как отдельный продукт или как SaaS, а доступно только как аддон.

Вот некоторые из новых функции функций Aria Operations версии 8.16:

1. Интеграция функции Chargeback в Aria Operations

Chargeback, ранее известный как приложение Tenant, был отдельным продуктом, который работал в сочетании с операциями VMware Aria и vCloud Director. В этом релизе Chargeback был интегрирован в VMware Aria Operations.

Это позволит:

• Вести упрощенный учет расходов для арендаторов с гибким планированием и выставлением счетов на уровне организации или виртуального датацентра.
• Настраивать ценообразование с поддержкой моделей распределения ресурсов.
• Более глубоко понимать использование сети арендаторами.
• Получить обширные возможности самостоятельного мониторинга.
• Использовать пользовательские панели управления и отчеты для провайдеров и арендаторов.

2. Улучшенная информация мониторинга сети через LLDP

Протокол обнаружения на уровне канала (Link-Layer Discovery Protocol, LLDP) — это протокол, не зависящий от производителя, используемый вендорами сетевых устройств, не относящимися к Cisco. VMware Aria Operations предоставлял ограниченный набор информации для протокола LLDP по сравнению с CDP (Cisco Discovery Protocol). С этим релизом будут доступны следующие данные для протокола LLDP:

• Описание системы
• Размер MTU
• Описание порта
• Состояние агрегирования ссылок для конфигураций LACP

3. Уменьшение разнообразия виджетов для упрощения взаимодействия с дашбордами

vSphere и vSAN из коробки включают дашборды, использующие ограниченное количество виджетов и представлений. Для расширения возможностей при одновременном увеличении удобства использования было решено уменьшить это число до 17. Ниже приведен список виджетов и представлений:

1. List
2. Top-N List
3. Summary Table
4. Health Chart
5. Trend Chart
6. Distribution Chart
7. Scoreboard
8. Heat Map
9. Property List
10. Geo
11. Relationship (ранее называлось Object Relationship)
12. Weekly Pattern
13. Alert List
14. Top Alerts
15. Metric Chart
16. Metric Picker
17. Object List

В средах, где присутствует большое количество рабочих нагрузок, становится сложно отслеживать множество операций vMotion и ВМ, перемещаемых из-за workload placement (WLP). Новая метрика WLPVmMovedCount была добавлена на уровне объекта кластера для:

• фиксации числа миграций ВМ, происходящих при каждом действии WLP
• определения вовлеченных кластеров и времени этих миграций

4. Обновленный пакет соответствия VCF на основе руководства по аудиту VCF 4.5

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

5. Использование тегов для исключения ВМ и кластеров из участия в размещении рабочих нагрузок

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

6. Возможность изменения языка отображения VMware Aria Operations

VMware Aria Operations в настоящее время выбирает язык отображения на основе настроек браузера. С последним релизом пользователь сможет изменить язык отображения в разделе настроек пользователя.

Больше подробностей о новом релизе VMware Aria Operations 8.16 приведено в Release Notes.

Недавно компания VMware представила очередной релиз платформы виртуализации и доставки настольных ПК и приложений Horizon 8 2312, в котором появилось несколько функций, разработанных для улучшения опыта работы как администраторов, так и конечных пользователей. Horizon 2312 предлагает набор возможностей, направленных на оптимизацию операций, обеспечение безопасности сессий, повышение производительности и добавление большей персонализации к каждой сессии. Напомним, что о прошлой версии VMware Horizon 8 2306 мы рассказывали вот тут.

Horizon 2312 является последним релизом ветки Extended Service Branch (ESB) - это означает, что VMware предоставит несколько будущих обновлений, содержащих критические исправления ошибок и поддержку новых версий ОС в течение трехлетнего периода. Более подробно об этом рассказано здесь.

Давайте посмотрим, что нового в Horizon 2312:

Улучшения клиента и агента Horizon

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

1. Автоматическое обновление агента Horizon для упрощения обслуживания

Вы можете оптимизировать ваши Day-2 операции с помощью активной технологии виртуального рабочего стола (VDI), используя функцию auto-upgrade для агента Horizon, которая автоматизирует обновления по всем вашим VDI или RDSH десктопам, убирая необходимость в ручных обновлениях. Эта функция доступна эксклюзивно для клиентов с лицензией Horizon Plus или Horizon Universal и применима для рабочих столов Full Clone и серверов RDSH. Для обновления агента Horizon в пулах мгновенных клонов или фермах удаленных рабочих столов (RDS) просто обновите агент Horizon в золотом образе и запланируйте окно технического обслуживания для развертывания нового образа.

2. Оптимизированная производительность CPU

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

3. Улучшенные изображения с бинарным lossless-режимом для кодека Blast

Horizon 2312 вводит бинарный lossless-режим для кодека Blast. Он делает так, что при сжатии изображений не теряется ни одна деталь — обеспечивая пиксель-к-пикселю воссоздание оригинального изображения. Эта функция обеспечивает максимальную четкость изображения, гарантируя, что конечные пользователи получают лучший опыт использования. С бинарным lossless-режимом Blast пользователи в критически важных областях, таких как здравоохранение, могут быть уверены, что их изображения, включая рентгеновские снимки и другие детализированные сканы, передаются без потери информации.

4. Увеличение персонализации с помощью настраиваемых фонов Microsoft Teams

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

5. Размытие фона для клиента Linux

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

6. Модуль FIPS для MacOS

Для клиентов, требующих модуль обработки федеральных стандартов информации (FIPS) для macOS, клиент Horizon MacOS использует шифры, соответствующие FIPS.

7. Упрощенное развертывание Horizon Linux с помощью инструмента легкой настройки

Horizon 2312 получил легкую настройку для агента Horizon Linux. Этот новый инструмент предназначен для упрощения процесса установки с помощью CLI-инсталлятора и руководства администратора. Он предлагает пошаговый подход к развертыванию агента Horizon Linux, облегчая более гладкую и эффективную настройку. С помощью инструмента легкой настройки администраторы ИТ теперь могут без труда устанавливать агент, упрощая и обеспечивая успешное развертывание в операционной системе Linux.

8. Улучшения режима эмуляции, совместимого с ARM, для клиента Windows

На основе релиза Horizon 2309, который добавил поддержку режима эмуляции, совместимого с устройствами на базе ARM, решение Horizon 2312 предоставляет дополнительную функциональность с поддержкой «Login as Current User» (LACU). Эта функция, эксклюзивная для Windows, упрощает рабочие процессы для устройств, входящих в домен, используя функциональность LACU, чтобы позволить пользователям запускать Horizon без необходимости повторной аутентификации. Поддержка Horizon для ARM предоставляет клиентам больше выбора оборудования для их конечных пользователей, предлагая больше вариантов аппаратного обеспечения и обеспечивая операционную эффективность.

9. Возможность блокировки SendKey для защиты ВМ от вредоносных скриптов

Horizon 2312 вводит возможность блокировать скрипты PowerShell и другие скрипты SendKey от передачи с устройства пользователя в виртуальную машину. Блокируя скрипты от отправки вредоносных нажатий клавиш, эта функция предотвращает манипуляции злоумышленников с сессией конечного пользователя. Доступная для Horizon Client for Windows, эта защитная мера помогает предотвратить потенциальные атаки типа "отказ в обслуживании" (DoS) и внедрение вредоносного программного обеспечения, обеспечивая безопасность виртуальных сессий.

10. Интеграция DEEM улучшает возможности телеметрии Horizon

Horizon интегрировал возможности управления цифровым опытом сотрудников (DEEM) для улучшения аналитики по опыту сотрудников. Horizon будет предоставлять информацию, связанную с сессией, агенту DEEM, оптимизируя сбор и передачу телеметрии ВМ внутри гостевой системы напрямую в Workspace ONE Intelligence. С этим обновлением агент Horizon делится телеметрией гостевой ОС — такой как ID сессии Horizon, ID пула и имя пула — с агентом DEEM, предоставляя набор данных, доступных для анализа. Собранная информация о производительности ВМ и опыте пользователя позволяет администраторам превентивно решать проблемы, оптимизировать ресурсы и улучшать общий опыт пользователя. Эта интеграция DEEM и агента Horizon в настоящее время находится в бета-тестировании до конца марта 2024 года. Если вы заинтересованы в участии в бета-программе, то можно зарегистрироваться тут.

Новые возможности платформы Horizon 2312

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

1. Права доступа Horizon Cloud

Horizon 2312 позволяет конечным пользователям получать права доступа как из Horizon 8, так и из Horizon Cloud Service (HCS). Пользователи могут входить в локальный сервер подключения Horizon с использованием своих учетных данных без необходимости повторного входа для доступа к тем же правам на рабочие столы и приложения в облаке. Эта интеграция устраняет необходимость в использовании множества URL, выходов и дополнительных входов в систему при переключении между локальными и облачными рабочими столами, синхронизируя права доступа в обеих средах. Конечные пользователи могут аутентифицироваться через клиент Horizon для Windows или HTML Access, получить свои права Horizon 8 и затем получить доступ к своим правам Azure в Horizon Cloud Next-Gen с использованием токена JWT. Для получения дополнительной информации обращайтесь сюда.

2. Интуитивно понятный графический интерфейс для функции форензики

На основе функции форензики, представленной в релизе Horizon 2206, которая позволяет сохранять непостоянные ВМ для последующего просмотра, Horizon 8 теперь добавил графический пользовательский интерфейс (GUI). Специально разработанный для рабочих столов Instant Clone, этот интуитивно понятный графический интерфейс предоставляет информацию, связанную с пользователем, и детали форензических действий внутри ВМ. Новый графический интерфейс служит мостом, добавляя видимость и простоту к процессам расследований в виртуальных средах.

Функции форензики могут быть применены к пользователям или группам:

Отдельные машины пользователя или группы можно выбрать для более детального изучения:

3. Оптимизированная база данных ADAM для улучшения производительности репликации

В связи с ростом баз данных Active Directory Application Mode (ADAM), Horizon 2312 предлагает решение, направленное на уменьшение размера базы данных за счет сокращения периода "tombstone-lifetime" для уменьшения времени репликации. Ранее удаленные объекты сохранялись в течение 180 дней, что приводило к увеличению базы данных и удлинению времени репликации. В версии 2312 этот период сокращается до 60 дней, что приведет к уменьшению размера базы данных, ускорению репликации и повышению надежности работы системы. Кроме того, это помогает сократить время, необходимое для полной репликации базы данных ADAM, например, при добавлении Connection Server в существующую среду.

4. Настройка маршрутизации RDSH для опубликованных приложений и рабочих столов

Для предоставления администраторам более точного контроля во время тестирования и устранения неполадок, Horizon 2312 позволяет использовать опубликованные приложения и рабочие столы для направления пользователей на конкретные RDSH в рамках фермы. Эта функциональность сделана в ответ на потребности заказчиков — будь то для проверки и мониторинга всего процесса end-to-end или для проведения теста на каждом RDSH внутри фермы. Эта функция активируется в настройках опубликованного приложения или рабочего стола и требует использования параметра командной строки клиента Horizon для Windows. Функция также доступна для выбора конкретной виртуальной машины из пула non-persistent рабочих столов.

5. Автоматизированное обслуживание мгновенных клонов с автоматическим отключением хостов RDS

В обновлении Horizon 2313 автоматически отключаются отдельные хосты RDS в фермах мгновенных клонов RDS при выполнении обслуживания и использовании опции "Wait for users to logoff". Ранее администраторам приходилось вручную вмешиваться, чтобы отключить хосты для обслуживания. Теперь система автоматизирует этот процесс, оставляя достаточное количество хостов RDS включенными для поддержания доступа пользователей, позволяя другим хостам RDS освобождаться и обновляться.

6. Политика приостановки питания для мгновенных клонов с vGPU

Применение политик управления питанием полезно для экономии ресурсов, когда ВМ не используются. В Horizon 2312 администраторы могут использовать политику приостановки удаленной машины для пулов мгновенных клонов с поддержкой NVIDIA vGPU. Эта функция активируется ESXi, который поддерживает политики приостановки/возобновления питания для ВМ с vGPU. Отметим, что только версии ESXi 6.7 или выше поддерживают эту функцию.

7. Настройка текста запроса на сброс пароля в консоли администратора

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

Настроенное сообщение будет показано при неудачной попытке изменения пароля:

8. Завершена модернизация API с полным переходом на REST

Horizon 2312 завершает переход с API, основанных на SOAP, на REST API с полным сохранением функциональности предыдущих SOAP API. Все новые RESTful API можно загрузить с сайта API сервера Horizon.

9. Архитектура vSAN Express Storage

Horizon 8 2309 начал поддерживать vSAN 8 Express Storage Architecture (ESA) как для полных, так и для мгновенных клонов. Сейчас эта поддержка была улучшена. vSAN ESA — это новая, опциональная архитектура хранения, введенная в vSAN 8. Кроме того, с этой новой поддерживаемой архитектурой, Horizon может поддерживать до 500 ВМ на хост ESXi в зависимости от рабочей нагрузки и конфигурации оборудования. vSAN 8 предоставляет клиентам свободу выбора, какую из двух архитектур (vSAN OSA или vSAN ESA) использовать, чтобы лучше всего удовлетворить их потребности. vSAN ESA обеспечивает новые уровни производительности, масштабируемости, надежности и простоты использования на базе высокопроизводительных устройств хранения. Чтобы узнать больше почитайте вот эту статью блога VMware.

На этом обзор основных моментов релиза Horizon 2312 закончен. Для полного ознакомления со всеми улучшениями обратитесь к Horizon 8 2312 Release Notes.

Ransomware стало настоящей напастью последних лет - выплаты компаний злоумышленникам, зашифровавшим данные и держащим их в заложниках, перевалили за миллиард долларов в прошлом году (и это только то, что известно). Серверы VMware ESXi и vCenter, являющиеся основными компонентами инфраструктуры vSphere, представляют главную мишень для атак Ransomware.

В рамках конференции VMware Explore Europe 2023 прошла интересная сессия, где рассматривались примеры из реального мира по борьбе с программами-вымогателями, а также обсуждались проактивные методики, которые позволят избежать атаки или минимизировать последствия:

Вот основные выводы, которые суммаризуют выступление выше:

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

2. Важно провести различие между защитой рабочих нагрузок (виртуальные машины, серверы, клиенты, AD) и защитой инфраструктурной платформы (vSphere, хранилище и т.д.), поскольку каждое требует различных мер безопасности. Эти аспекты должны быть отделены друг от друга.

3. Понимание путей атаки, ведущих к появлению программы-вымогателя в инфраструктуре vSphere, является ключевым. Эти пути включают начальный доступ, использование Active Directory и различные способы добраться и атаковать vCenter Server и ESXi.

4. Восстановление среды vSphere после атаки не должно включать в себя выплату выкупа. Платеж атакующим увеличивает риск будущих атак и не гарантирует полного решения проблемы.

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

6. Очистка и восстановление скомпрометированных компонентов, таких как виртуальные машины, vCenter Server и хосты ESXi после атаки, требует тщательного рассмотрения и технического анализа (форензика).

7. Для защиты vSphere от атак должны быть предприняты несколько мер, включая сегментацию vSphere от рабочих нагрузок и клиентов, использование EDR/XDR/SIEM для конечных точек и vSphere, установку обновлений безопасности и следование рекомендациям по защите платформы vSphere.

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

9. UEFI Secure Boot может использоваться для проверки целостности файлов загрузки и ядра ESXi, что защищает от угроз с использованием неподписанных VIB.

10. Деактивация доступа к Shell для не-root пользователей ESXi может предотвратить боковое движение от vCenter к ESXi, что является важной мерой для остановки или замедления атакующего.

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

Хранение данных (критически важная часть частного облака) поддерживается в двух категориях: Основное (Principal) и Дополнительное (Supplemental).

Основное хранилище (Principal Storage)

Основное хранилище настраивается при создании нового домена рабочей нагрузки (Workload Domain) или кластера в консоли SDDC Manager. После создания тип основного хранилища для кластера изменить нельзя. Однако Workload Domain может включать несколько кластеров с собственными типами основного хранилища.

Основные варианты хранения данных (principal storage) включают:

• vSAN
• vVols
• NFSv3
• VMFS на FC-хранилищах

Следует отметить, что vSAN является единственно поддерживаемым типом основного хранилища для всех кластеров в управляющем домене (Management Domain). vSAN требуется для управляющего домена, поскольку он предсказуем с точки зрения производительности. vSAN предоставляет высокопроизводительное решение для хранения данных Enterprise-уровня для SDDC. Использование vSAN исключает внешние зависимости и облегчает использование средств автоматизации для инициализации управляющего домена VCF. Во время первоначальной установки VCF Cloud Builder инициализирует все основные компоненты центра обработки данных, определяемые программно - такие как vSphere, NSX и vSAN, на минимально необходимом количестве хостов. Этот процесс первоначального запуска в среднем занимает около двух часов.

Дополнительное хранилище (Supplemental storage)

Supplemental storage предоставляет дополнительную емкость кластеру и рекомендуется для данных Tier-2 или Tier-3, таких как библиотеки контента vSphere, шаблоны виртуальных машин, резервные копии, образы ISO и т. д. Дополнительное хранилище требует ручной настройки, не интегрировано и не отображается в SDDC Manager.

Доступные варианты таких хранилищ включают vSAN, vVols, VMFS на FC или iSCSI, NFSv3 или v4.1, а также NVMe-FC или NVMe-TCP.

Роль vSAN ESA

Начиная с версии 5.1, vSAN поддерживает как OSA (оригинальная архитектура хранения), так и ESA (экспресс архитектура хранения). vSAN ESA оптимизирован для использования с высокопроизводительными устройствами хранения нового поколения на базе NVMe, чтобы обеспечить еще более высокие уровни производительности для требовательных рабочих нагрузок, таких как OLTP и генеративный AI. Broadcom рекомендует использовать vSAN ESA в качестве основного хранилища для всех доменов рабочих нагрузок, чтобы получить все преимущества управления и обслуживания полностью программно-определенного стека.

vSAN также обновляется и патчится через LCM (Lifecycle Manager) в SDDC Manager. Обновление и патчинг хранилищ, отличных от vSAN, является ручной задачей и не входит в процедуры управления жизненным циклом, реализованные в SDDC Manager. Для обеспечения поддержки, само хранилище и его HBA необходимо проверять на соответствие VMware Compatibility Guide, когда vSAN не используется.

vSAN использует движок Storage Policy-Based Management (SPBM), который позволяет управлять политиками хранения на уровне виртуальных машин, а не на уровне всего хранилища (datastore). С помощью этого механизма вы можете управлять всеми хранилищами инфраструктуры VCF. Если у вас большая инфраструктура, то необходимо использовать программные средства автоматизации, так как вручную управлять LUN и виртуальными томами и их возможностями очень проблематично в большом масштабе.

Также на эту тему есть интересная статья: "Why vSAN and vVols are Best for VMware Cloud Foundation".

Выводы

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

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

• VMware Cloud Foundation Resource Center
• vSAN ReadyNode Sizer
• Why vSAN and vVols are Best for VMware Cloud Foundation

Недавно в компании VMware решили несколько переработать состав доступных онлайн лабораторных работ Hands-On Labs (HoL), включив туда новый контент в соответствии с последними изменениями в продуктовой линейке, а также убрав уже не актуальные лабы. Напомним, что полный список доступных онлайн лабораторных работ доступен по этой ссылке. А о прошлом пакете новых работ HoL мы писали вот тут.

Сейчас в списке находятся 103 лабы:

Давайте посмотрим, какие новые HoL появились на начало этого года:

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

Ну и некоторые лабораторные были отправлены в архив, поскольку полностью потеряли актуальность:

Конструктор лаборатории VMware Cloud Foundation Lab Constructor (VLC) Holodeck Toolkit предназначен для обеспечения масштабируемого, повторяемого способа развертывания вложенных сред VMware Cloud Foundation (VCF) непосредственно на хостах VMware ESXi. Эти среды идеально подходят для практических занятий нескольких команд, изучающих возможности VCF и реализации управляемого заказчиком облака VMware.

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

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

• Снижение требований к оборудованию - при работе в физической среде VCF требует четыре узла vSAN Ready Nodes для домена управления и дополнительные хосты для создания кластеров и доменов рабочих нагрузок. Во вложенной среде те же четыре-восемь хостов легко виртуализируются для работы на одном хосте ESXi.
• Самодостаточные сервисы - конфигурация Holodeck Toolkit предоставляет общие инфраструктурные сервисы, такие как NTP, DNS, AD, сервисы сертификатов и DHCP внутри среды, исключая необходимость полагаться на сервисы центра обработки данных во время тестирования. Каждой среде требуется один внешний IP.
• Изолированная сеть - конфигурация Holodeck Toolkit устраняет необходимость в соединениях VLAN и BGP в сети клиента на ранних этапах тестирования.
• Изоляция между средами - каждая развертываемая среда Holodeck полностью самодостаточна. Это избегает конфликтов с существующими сетевыми конфигурациями и позволяет развертывать множество вложенных сред без опасений насчет перекрытия.
• Множественные развертывания VCF на одном хосте VMware ESXi с достаточной мощностью - типичное развертывание стандартной архитектуры VCF с четырехузловым доменом управления и четырехузловым доменом рабочих нагрузок VI, а также дополнениями, такими как VMware vRealize Automation, требует примерно 20 ядер процессора, 512 ГБ памяти и 2.5 ТБ диска.
• Автоматизация и повторяемость - развертывание вложенных сред VCF почти полностью автоматизировано и легко повторяемо с использованием файлов конфигурации. Типичное развертывание занимает менее 3 часов, с менее чем 15 минутами активного времени использования клавиатуры.

Среда Holodeck Toolkit 2.0

Пакет Holodeck Toolkit 2.0 состоит из нескольких основных компонентов:

• Пакет VCF Lab Constructor (VLC) 5.0 для полной автоматизации развертывания повторяемых вложенных лабораторий Cloud Foundation на одном хосте ESXi. Этот релиз поддерживает VCF 4.5, 4.5.1 и 5.0.
• Пользовательские файлы конфигурации VLC-Holo-Site-1 и VLC-Holo-Site-2 для VLC, поддерживающие развертывания VMware Cloud Foundation с несколькими сайтами.
• Пользовательский Holo-Router на базе VMware Photon OS для поддержки коммуникаций внутри вложенной среды VCF и из этой среды во внешнюю сеть.
• Пользовательская Holo-Console на базе Microsoft Windows Server 2019.
• Полностью автоматизированный механизм создания ISO-образа Holo-Console.
• Полные руководства по развертыванию и эксплуатации одного или нескольких серверов Holodeck.
• Набор лабораторий Holodeck "Always succeed" для демонстрации модели облачной эксплуатации нескольким командам внутри центра обработки данных.
• Программно-определенные сети и безопасность с VMware NSX Data Center.
• Автоматизация частного облака на базе VMware Cloud Foundation.
• Масштабирование развертывания и мониторинга приложений с VMware vRealize Automation.
• Миграция рабочих нагрузок с VMware HCX.
• Модернизация приложений с VMware Tanzu.

Обзор VCF Lab Constructor (VLC)

VLC - это утилита PowerShell/PowerCLI, разработанная для автоматизации развертывания VMware Cloud Foundation во вложенной среде. VLC, используемый с конфигурацией Holodeck, автоматизирует предоставление стандартизированной среды Holodeck "Pod".

Каждый Pod Holodeck содержит:

• Четырехузловой домен управления VCF на вложенных узлах, готовых к использованию с vSAN.
• Опционально три дополнительных вложенных хоста в домене рабочих нагрузок - или второй кластер vSphere в домене управления, или просто дополнительные элементы первого.
• NSX полностью настроен.
• Развернутый AVN/NSX Edge (рекомендуется).
• Развернутый Tanzu (опционально).
  
• VM Cloud Foundation Cloud Builder, настроенный для предоставления DHCP, NTP, DNS, BGP peering и L3 маршрутизации внутри пода.

VLC также может автоматизировать развертывание второго экземпляра VCF на под для предоставления многосайтовой конфигурации VCF для продвинутых лабораторных занятий, таких как NSX Federation, VMware Site Recovery Manager и VCF с vSAN Stretched Cluster.

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

Примечание: VCF Lab Constructor не поддерживается VMware как официальный продукт, это что-то похожее на VMware Flings. Вы также можете присоединиться к каналу поддержки VLC в Slack.

Обзор вложенной среды

Конфигурация "VLC Holodeck Standard" является вложенной конфигурацией VMware Cloud Foundation, используемой в качестве базовой для нескольких лабораторных упражнений по эксплуатации частного облака, созданных командой технического маркетинга Cloud Foundation. Стандартный "VLC-Holo-Site-1" является основной развертываемой конфигурацией. Дополнительный VLC-Holo-Site-2 может быть развернут в любое время позже в рамках нового Pod. Конфигурация VLC-Holo-Site-1 соответствует лабораторной конфигурации в VCF Hands-On Lab HOL-2246 и вложенной конфигурации в программе VCF Experience, запущенной на платформе лабораторий VMware.

Каждый Pod в развертывании Holodeck работает с идентичной вложенной конфигурацией. Pod может быть развернут с автономной конфигурацией VLC-Holo-Site-1 или же с одновременно активными конфигурациями VLC-Holo-Site-1 и VLC-Holo-Site-2. Разделение подов, а также между сайтами внутри пода, обрабатывается на уровне виртуального коммутатора vSphere Standard Switch (VSS). Каждый Pod Holodeck настроен с уникальным VSS для сайта. Группа портов VMware vSphere настроена на каждом VSS и сконфигурирована как транк VLAN.

• Компоненты в группе портов используют тегирование VLAN для изоляции коммуникаций между вложенными VLAN. Это устраняет необходимость в физических VLAN, подключенных к хосту ESXi для поддержки вложенных лабораторий.
• Когда развертывается конфигурация Holo-Site-2, она использует второй VSS и группу портов для изоляции от Holo-Site-1.
• Конфигурация VLC Holodeck настраивает виртуальную машину VCF Cloud Builder для предоставления нескольких сервисов поддержки внутри пода, чтобы не требовать дополнительных сервисов со стороны клиента. VM Cloud Builder развертывается на сайт для предоставления следующих услуг внутри пода:
  • DNS (локально для Site1 и Site2 внутри пода, действует как промежуточный узел).
  • NTP (локально для Site1 и Site2 внутри пода).
  • DHCP (локально для Site1 и Site2 внутри пода).
  • L3 TOR для сетей vMotion, vSAN, управления, Host TEP и Edge TEP в каждом сайте.
  • BGP-пир с VLC Tier 0 NSX Application Virtual Network (AVN) Edge (обеспечивает подключение к оверлей-сетям NSX из лабораторной консоли).

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-1 внутри Pod Holodeck. Конфигурация Site-1 использует домен DNS vcf.sddc.lab и VLAN 10-15.

Пакет Holodeck также предоставляет предварительно настроенную виртуальную машину Photon OS, называемую "Holo-Router", которая функционирует как виртуализированный маршрутизатор для базовой среды. Эта ВМ позволяет соединять вложенную среду с внешним миром. Holo-Router настроен на перенаправление любого трафика Microsoft Remote Desktop (RDP) к вложенному jump-хосту, известному как Holo-Console, который развертывается внутри пода.

Интерфейс пользователя для вложенной среды VCF предоставляется через виртуальную машину Windows Server 2019 "Holo-Console". Holo-Console предоставляет место для управления внутренней вложенной средой, подобно рабочему столу системного администратора в центре обработки данных. Holo-Console используется для запуска пакета VLC для развертывания вложенного экземпляра VCF внутри пода. Виртуальные машины Holo-Console развертываются из специально созданного ISO, который настраивает следующее:

1. Microsoft Windows Server 2019 Desktop Experience, имеющий на борту:

• Домен Active directory "vcf.holo.lab"
• DNS-форвардер к Cloud Builder
• Сервер сертификатов, Web Enrollment и шаблон сертификата VMware
• Включенный RDP
• Настроенный IP, подсеть, шлюз, DNS и VLAN для развертывания как Holo-Console
• Отключенный брандмауэр и улучшенная безопасность IE
• Настроенное рабочее окружение SDDC Commander

2. Дополнительные программные пакеты, развернутые и настроенные:

• Google Chrome с закладками Holodeck
• VMware Tools
• VMware PowerCLI
• VMware PowerVCF
• VMware Power Validated Solutions
• Клиент PuTTY SSH
• VMware OVFtool

3. Дополнительные программные пакеты, скопированные в Holo-Console для последующего использования:

• VMware Cloud Foundation Cloud Builder OVA в C:\CloudBuilder.

4. VCF Lab Constructor 5.0 с двойной конфигурацией Holodeck:

• C:\VLC\VLC-Holo-Site-1
• C:\VLC\VLC-Holo-Site-2

5. VMware vRealize Automation 8.10 Easy Installer

На рисунке ниже показаны виртуальные машины, работающие на физическом хосте ESXi для предоставления пода Holodeck под названием "Holo-A". Обратите внимание на экземпляры Holo-Console, Holo-Router, Cloud Builder и четыре вложенных хоста ESXi. Они все общаются через группу портов VLC-A-PG.

Добавление второго сайта включает дополнительный экземпляр Cloud Builder и дополнительные вложенные хосты ESXi. VLC-Holo-Site-2 подключается ко второй внутренней линии Holo-Router на VLAN 20. Доступ в сеть из Holo-Console к VLC-Holo-Site-2 осуществляется через Holo-Router.

На рисунке ниже показан логический вид конфигурации VLC-Holo-Site-2 внутри пода Holodeck. Конфигурация Site-2 использует домен DNS vcf2.sddc.lab и VLAN 20-25.

Доступ к среде Holodeck

Доступ пользователей к поду Holodeck осуществляется через Holo-Console. Доступ к Holo-Console возможен двумя способами:

1. Подключение через Microsoft Remote Desktop Protocol (RDP) к внешнему IP Holo-Router. Holo-Router настроен на перенаправление всего RDP-трафика к экземпляру Holo-Console внутри пода:

• Клиент Microsoft Remote Desktop для Mac
• Клиент Remote Desktop для Windows (доступен в Microsoft Store)

2. Доступ к Holo-Console через хост ESXi:

• Консоль браузера (встроенная в клиент vSphere)
• VMware Remote Console (требуется вход в VMware Customer Connect)

Предварительные требования для развертывания VLC Holodeck

Размер хоста ESXi:

• Good (один под): Один хост ESXi с 16 ядрами, 384 ГБ памяти и 2 ТБ SSD/NVME
• Better (два пода): Один хост ESXi с 32 ядрами, 1024 ГБ памяти и 4 ТБ SSD/NVME
• Best (четыре или более подов): Один хост ESXi с 64+ ядрами, 2.0 ТБ памяти и 10 ТБ SSD/NVME

Конфигурация хоста ESXi:

• vSphere 7.0U3 или 8.0
• Виртуальный коммутатор и группа портов, настроенные с подключениями к сети клиента/интернету
• Поддерживается автономный хост, не управляемый сервером vCenter, и одноузловой кластер, управляемый экземпляром сервера vCenter
• Кластеры с несколькими хостами НЕ поддерживаются в этом выпуске из-за требования физической поддержки VLAN

Хост Holo-Build:

• Хост Windows 2019 или VM с локальным доступом к хостам ESXI, используемым для Holodeck + доступом в интернет для загрузки программного обеспечения. (Этот пакет был протестирован только на Microsoft Windows Server 2019)
• 200 ГБ свободного дискового пространства
• Действительный вход в CustomerConnect
• Лицензия на VCF 4.5 или 5.0 Enterprise для минимум 8 хостов (16 хостов, если планируется тестирование Cloud Foundation Multi region с NSX Federation)

Ключи лицензий для следующих компонентов VCF 4.5 или 5.0 (на данный момент Toolkit Holodeck не поддерживает подписочные лицензии):

• VMware Cloud Foundation
• VMware NSX-T Data Center Enterprise
• VMware vSAN Enterprise
• VMware vSphere Enterprise Plus
• VMware vCenter Server (одна лицензия)
• VMware vRealize Suite Advanced или Enterprise (теперь это VMware Aria Suite)

Требуемые внешние/клиентские сети:

• IP-адрес управления хоста ESXi (один на хост)
• Адрес Holo-Router на под

Требуемое программное обеспечение (ссылки и инструкции есть в модуле создания пользовательского ISO Holodeck):

• Microsoft Server 2019 Desktop Experience (Eval копия с истечением срока действия через 6 месяцев)
• Свежий пакет VMware VMTools
• Отдельная установка Google Chrome
• Последний архив VMware PowerCLI
• Свежий архив VMware PowerVCF
• Свежий модуль VMware Power Validated Solutions Module
• Свежий MSI клиента PuTTY SSH
• Свежий VMware OVFtool (требуется вход в CustomerConnect)
• VMware Cloud Foundation 4.5 или 5.0 Cloud Builder OVA (требуется вход в CustomerConnect)
• Архив VLC holodeck-standard-main zip - включает VCF Lab Constructor, Holo-Router.ova, скрипты автоматизации поддержки Holodeck и руководства по развертыванию в файле holodeck-standard-main.zip
• Notepad ++ 8.4.7
• VMware vRealize Automation 8.11.2 Easy Installer (требуется вход в CustomerConnect) - эта лаборатория разработана для работы только с VMware vRealize Automation 8.11.2.

Полезные ссылки

• Holodeck 2.0 Setup
• SDDC Manager Operations
• Software-Defined Networking
• Cloud Operations
• Tanzu Operations
• Exploring Holodeck

VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

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

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

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

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

Как вы можете применить эти знания при планировании собственной среды? Утилита vSAN ReadyNode Sizer делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.

Недавно компания VMware выпустила новую версию решения VMware Aria Operations for Networks 6.12. Напомним, что этот продукт сменил средство vRealize Network Insight (vRNI) в рамках большого ребрендинга и перепаковки линейки vRealize. vRNI - это платформа для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре. О прошлой версии Aria Operations for Networks 6.11 мы писали вот тут.

В последнем релизе Aria Operations for Networks 6.12 представлено много новых возможностей для обеспечения видимости сети, чтобы помочь пользователям решения VMware Cloud Foundation улучшить производительность сети приложений и устранять проблемы с сетью.

1. Функция Network Map Scope - область видимости сети

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

2. Тэги для устройств

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

3. API и Databus

Для качественного устранения неполадок и анализа их причин в средах NSX были представлены несколько API NSX и vCenter для databus, которые будут извлекать метрики через NSX Edge, хост vCenter и кластер хостов vCenter. Примерами улучшенной видимости сети являются метрики хоста vCenter, такие как usage, transmission и drop rate.

4. Сохранение изменений в таблицах и виджетах

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

5. Уведомления по почте о закрытии алертов

Теперь в релизе 6.12 есть механизм закрытия алертов, который генерирует сообщение SNMP для инструментов вроде ServiceNow и IBM Netcool. В этом случае пользователям может быть отправлено письмо о закрытом алерте. Эта возможность обеспечивает лучшую видимость для ИТ-команд, делая проблемы более доступными для отслеживания со стороны службы поддержки. Новая функция оповещения о закрытом алерте упростит сотрудничество пользователей, позволив им сосредоточить внимание на текущих открытых и актуальных оповещениях.

Более подробно о VMware Aria Operations for Networks 6.12 можно прочитать в Release Notes, а также на странице продукта.

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

VMware предлагает предприятиям готовые возможности, чтобы удовлетворить потребности современного бизнеса за счет новых функций в решениях VMware Cloud Disaster Recovery и VMware Ransomware Recovery. VMware Ransomware Recovery for VMware Cloud Disaster Recovery предлагает уверенное восстановление от критических угроз, быстрое восстановление с помощью управляемой автоматизации и упрощенные операции восстановления. Это полностью управляемое решение Ransomware Recovery as-a-Service, которое позволяет безопасно восстанавливаться от современных программ-вымогателей через поведенческий анализ включенных рабочих нагрузок в изолированной среде восстановления (IRE) в облаке.

На днях компания VMware выпустила обновленную версию Cloud Disaster Recovery с функциями Ransomware Recovery. Давайте посмотрим, что нового стало доступно пользователям в этом феврале:

1. 15-минутное RPO с частыми снимками

Потеря доступа организации к некоторым (или всем) данным может обойтись в миллионы упущенной выручки, повреждении репутации бренда и штрафах за несоблюдение нормативных требований - и это лишь некоторые из возможных последствий. По этой причине минимизация потерь данных при восстановлении давно является ключевой задачей, особенно в крупных организациях или в сильно регулируемых отраслях. Чтобы решить эту важную проблему, VMware Cloud DR и VMware Ransomware Recovery теперь поддерживают 15-минутное RPO (требование к контрольной точке восстановления), которое предоставляет клиентам большую гибкость и выбор. Эта техника позволяет делать до 96 снимков в день и поддерживает приостановку работы приложений для обеспечения их согласованности. В сочетании с глубокой историей неизменяемых точек восстановления, сохраненных в Cloud Filesystem, это предоставляет клиентам больший выбор в частоте и политиках хранения снимков. Такая гибкость важна для достижения баланса между готовностью к восстановлению и общей стоимостью владения инфраструктурой.

2. Запуск рабочих нагрузок в облаке

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

3. Transit Connect для репликации, переключения на резерв и возврата к исходному сайту

Расширенная поддержка Transit Connect обеспечивает улучшенную безопасность сети для клиентов, которые не могут передавать данные по общедоступным сетям из-за требований комплаенса или просто желают минимизировать риски передачи. С этим улучшением передача данных для репликации, переключения на резерв (failover) и возврата (failback) осуществляется через защищенную частную сеть, полностью изолированную от общедоступного интернета. Трафик автоматически шифруется в состоянии покоя и в процессе передачи, а правила брандмауэра на облачном шлюзе в сочетании со списками доступа на стороне VMware Cloud DR добавляют слой безопасности.

4. Улучшенное сетевое подключение

VMware Cloud DR и VMware Ransomware Recovery теперь позволяют клиентам изолировать DR-сеть от той, что используется для тестирования и восстановления. Наличие DR-сети, полностью отделенной от сети изолированной среды восстановления (Isolated Recovery Environment, IRE), предотвращает перемещение киберугроз в SDDC-датацентр восстановления, которые могли бы заразить рабочие нагрузки, если они работают в одной и той же среде. Сегментация сети, создаваемая на уровне NSX в резервном SDDC, теперь является опцией конфигурации плана DR. VMware Cloud DR и VMware Ransomware Recovery будут использовать NSX Compute Gateway для указания отдельных сетей, что позволяет операциям DR и восстановления проводиться одновременно и безопасно в одном и том же SDDC. Это также позволяет клиентам консолидировать инфраструктуру сайта восстановления без риска заражения рабочих нагрузок.

Более подробно о новых возможностях VMware Cloud Disaster Recovery можно прочитать в Release Notes.