Интересную статью написал Tom Fojta в своем блоге, касающуюся возможного повреждения данных на платформе VMware vSAN 8.0 (включая пакеты обновлений Update 1 и 2). Согласно статье базы знаний KB 367589, такое повреждение может случиться, если в вашей виртуальной машине некоторые приложения используют набор инструкций AVX-512.

Пока известно, что эти инструкции используются СУБД IBM Db2 и SAP HANA (однако и другие приложения могут их потенциально использовать).

Чтобы проверить, есть ли поддержка AVX-512 у вашего процессора, нужно выполнить следующую команду:

cat /proc/cpuinfo |grep avx512

Вывод команды будет примерно таким:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xsaves arat pku md_clear flush_l1d arch_capabilities

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

Для того, чтобы обнаружить эту поддержку в гостевой ОС Windows, можно запустить утилиту HWiNFO.

Чтобы воспроизвести проблему, можно просто запустить SSH для передачи данных, так как библиотека openssl может использовать инструкции AVX-512:

$ dd if=/dev/zero bs=1M count=1024 | sha256sum -  > sha256sums.zero # one time checksum generation
$ ( while true; rm -f /tmp/zero.$$.img ; do ssh root@localhost "dd if=/dev/zero iflag=fullblock bs=1M count=1024 status=progress" | dd iflag=fullblock bs=1M status=none of=/tmp/zero.$$.img && sha256sum - < /tmp/zero.$$.img | diff -u sha256sums.zero - || exit 1; done )

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

...
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.11915 s, 507 MB/s
1013972992 bytes (1.0 GB, 967 MiB) copied, 2 s, 507 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.09118 s, 513 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2 s, 532 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.01729 s, 532 MB/s
--- sha256sums.zero     2024-10-21 10:44:48.142238490 +0000
+++ -   2024-10-21 10:54:17.289072688 +0000
@@ -1 +1 @@
-49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  -
+4e841c1d34a2a051fab082d10a8105cd34e10c95ee74ce20d280a7c022eaaa53  -

Чтобы решить проблему на уровне процессора (виртуальной машины), нужно отмаскировать некоторые флаги в наборе инструкций CPU. Вы также можете решить проблему и на уровне приложений (для этого обратитесь к KB, указанной выше).

Итак, нужно добавить в Advanced Configuration Parameters виртуальной машины следующие строчки для проблемных инструкций AVX-512:

featMask.vm.cpuid.AVX512F = “Max:0”
featMask.vm.cpuid.AVX512FP16 = “Max:0“

Сделать это можно и через интерфейс vSphere Client или Cloud Director - там нужно создать политику Compute Policy для виртуальных машин (в интерфейсе она называется VM Sizing Policy) с расширенными параметрами:

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

vSAN Data Protection основывается на возможности создания снимков (snapshots), которая была введена с vSAN ESA. Эта функция в ESA значительно отличается от того, как это было реализовано в vSAN OSA или VMFS. В vSAN OSA и VMFS при создании снимка создается новый объект (в vSAN) или файл (в файловой системе VMFS). С vSAN ESA это больше не так, так как теперь не создаются дополнительные файлы или объекты, а вместо этого создается копия структуры метаданных. Именно поэтому снапшоты на vSAN ESA работают гораздо лучше, чем для vSAN OSA или VMFS, так как больше не нужно проходить через множество файлов или объектов для чтения данных. Теперь просто используется тот же объект и задействуется структура метаданных для отслеживания изменений.

В vSAN объекты (и их компоненты) размещаются по всему кластеру в соответствии с тем, что указано в политике хранения, связанной с объектом или виртуальной машиной. Другими словами, если политика FTT=1 и RAID-1, то вы увидите две копии данных. Если политика определяет, что данные должны быть растянуты между локациями и защищены RAID-5 в каждой локации, тогда вы увидите конфигурацию RAID-1 между сайтами и конфигурацию RAID-5 внутри каждого сайта. Поскольку снапшоты vSAN ESA являются неотъемлемой частью объекта, они автоматически следуют всем требованиям, определенным в политике. Другими словами, если политика установлена как "stretched", то снимок также будет автоматически растянутым.

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

На диаграмме ниже показан модуль Data Protection Appliance, также известный как менеджер снимков (snapshot manager appliance). Как вы видите, на диаграмме указано "метаданные отделены от модуля" (metadata decoupled from appliance), и оно как-то связано с объектом глобального пространства имен. Этот объект глобального пространства имен хранит все детали защищенных виртуальных машин (и не только). Как вы можете догадаться, как менеджер снимков, так и объект глобального пространства имен должны также быть растянутыми. Для объекта глобального пространства имен это означает, что вам нужно убедиться, что политика по умолчанию для хранилища данных установлена как "stretched", и, конечно, для менеджера снапшотов вы можете просто выбрать правильную политику при его развертывании. В любом случае убедитесь, что политика по умолчанию для хранилища данных соответствует политике аварийного восстановления и защиты данных.

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

Проблема небезопасных протоколов

Небезопасные протоколы, такие как SMB версии 1, могут быть уязвимы для атак. Например, уязвимость SMBv1 может позволить злоумышленнику получить доступ к виртуальной машине, если система не была своевременно обновлена. Проблема может усугубляться тем, что в некоторых случаях обновление системы невозможно из-за бизнес-ограничений.

Для демонстрации в видео используются две машины:

• Windows 7 с включенным SMBv1, которая не предназначена для предоставления файловых сервисов.
• Windows Server 2016, выступающий в роли файлового сервера, который хранит конфиденциальные данные компании.

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

Как VMware vDefend защищает инфраструктуру

1. Ограничение доступа с использованием брандмауэра (DFW)

В первую очередь, демонстрируется, как злоумышленник использует уязвимость на машине с Windows 7, которая не является файловым сервером, но продолжает принимать SMB-трафик. После успешного взлома злоумышленник получает неограниченный доступ к системе.

Чтобы предотвратить подобные атаки, с помощью VMware vDefend создается правило, которое ограничивает доступ к сервисам SMB только для нужных диапазонов IP-адресов (RFC 1918 в этом примере). Все остальные подключения, использующие SMB, будут заблокированы. Таким образом, злоумышленник больше не может воспользоваться уязвимостью Windows 7, и попытка повторного взлома завершается неудачей.

2. Защита файлового сервера с использованием Intrusion Detection and Prevention (IDP)

Вторая часть видео фокусируется на защите Windows Server 2016. Поскольку файловый сервер должен продолжать предоставлять доступ к конфиденциальным данным, простое блокирование SMB не подходит. Для этого используется система обнаружения и предотвращения вторжений (IDP), которая контролирует трафик и блокирует вредоносные пакеты.

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

Мониторинг событий и дальнейшие действия

После блокировки атаки администраторы могут использовать встроенные инструменты мониторинга для детального анализа инцидента. В VMware vDefend доступны такие данные, как IP-адреса источников, целевые машины, идентификаторы сигнатур атак и другие полезные сведения, которые можно передать в команду безопасности (SOC) для дальнейшего расследования.

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

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

Блогер Дункан Эппинг записал отличное видео по теме защиты данных кластеров отказоустойчивости средствами продукта VMware vSAN Data Protection для VMware Explore в Лас-Вегасе и Барселоне. Так как ему поступали вопросы от людей по поводу защиты данных vSAN, он решил поделиться демо на YouTube и опубликовать его в своем блоге. Ранее он выпустил несколько статей о защите данных vSAN и стал замечать, что некоторые клиенты начинают тестировать эту функцию и даже использовать её в производственных средах, где это возможно. Как мы также писали ранее, решение vSAN Data Protection доступно только только в рамках архитектуры vSAN ESA, так как она использует новые возможности создания моментальных снимков (снапшотов). Также полностью новый интерфейс был представлен в средстве управления Snap Manager Appliance. Обязательно скачайте, разверните и настройте его в первую очередь.

Собственно, само демо VMware vSAN Data Protection, которое стоит посмотреть, если вы интересуетесь защитой данных в рамках виртуальной инфраструктуры VMware vSphere и vSAN:

Вчера мы писали об обновленной утилите SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим еще об одном наборе бесплатных дэшбордов Grafana для мониторинга VMware vSphere, которые сделал Jorge de la Cruz.

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

Итак, сами дэшборды:

1. VMware vSphere - Overview

Этот дэшборд содержит пять различных разделов: один для мониторинга производительности ESXi и vCenter, другой для производительности виртуальных машин, третий для дисков, четвёртый для хранилищ, и последний для хостов и их IPMI. Дэшборд включает переменные, чтобы сделать его использование проще и подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами:

2. VMware vSphere - Datastore

Этот дэшборд содержит два раздела: один для мониторинга производительности ESXi и vCenter, другой - для производительности виртуальных машин. Дашборд включает переменные, чтобы упростить его использование и сделать его подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

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

3. VMware vSphere - Hosts

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

4. VMware vSphere - VMs

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Ну и главное - вот эта статья. Она описывает, как настроить мониторинг VMware с помощью дэшбордов Grafana, InfluxDB и Telegraf. В ней пошагово объясняется создание стека контейнеров с использованием Docker Compose, настройка InfluxDB и Telegraf для сбора метрик VMware из vCenter, а также визуализация данных в Grafana. Там подробно рассматривается использование готовых дэшбордов для ускорения процесса настройки и предлагаются советы по устранению неполадок.

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

Наш читатель Сергей справедливо заметил, что мы давно не писали о новых релизах бесплатной утилиты SexiGraf, предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом в январе прошлого года, а на днях вышло обновление этого продукта - SexiGraf 0.99k (Lighthouse Point).

Это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Давайте посмотрим на новые возможности двух недавних релизов:

Релиз Lighthouse Point (0.99k) от 7 октября 2024

VMware Snapshot Inventory

Начиная с версии SexiGraf 0.99h, панель мониторинга «VI Offline Inventory» заменена на VMware Inventory с инвентаризацией ВМ, хостов и хранилищ данных (вскоре добавятся портгруппы и другие элементы). Эти новые панели имеют расширенные возможности фильтрации и значительно лучше подходят для крупных инфраструктур (например, с более чем 50 000 виртуальных машин). Это похоже на извлечение данных из RVtools, которое всегда отображается и актуально.

В релизе v0.99k появилось представление VM Snapshot Inventory:

Улучшения "Cluster health score" для VMware vSAN 8

Вместо того чтобы бесконечно нажимать на кнопку обновления на вкладке «Resyncing Components» в WebClient, начиная с версии SexiGraf 0.99b разработчики добавили панель мониторинга vSAN Resync:

Shell In A Box

В версии SexiGraf 0.99k разработчики добавили отдельный дэшборд Shell In A Box за обратным прокси-сервером, чтобы снова сделать отладку удобной.

Прочие улучшения:

• Официальная поддержка vSphere и vSAN 8.3 API, а также Veeam Backup & Replication v12
• Движок обновлен до Grafana 8.5.9
• PowerShell core обновлен до 7.4.4 LTS
• PowerCLI 13.3
• Graphite 1.2.0
• Автоматическая очистка /var/lib/grafana/png/
• Добавлен выбор версии в панель мониторинга VMware Evo Version
• Добавлена многострочная панель в панель мониторинга репозиториев Veeam
• Обработка учетных записей с очень ограниченными правами
• Опция использования MAC-адреса вместо Client-ID при использовании DHCP
• Добавлено имя хоста гостевой ОС в инвентаризацию виртуальных машин

Релиз St. Olga (0.99j) от 12 февраля 2024

В этой версии авторы добавили официальную поддержку новых API vSphere и vSAN 8.2, а также Veeam Backup & Replication v11+.

Новые возможности:

• Поддержка Veeam Backup & Replication
• Автоматическое слияние метрик ВМ и ESXi между кластерами (функция DstVmMigratedEvent в VROPS)
• Количество путей до HBA
• PowerShell Core 7.2.17 LTS
• PowerCLI 13.2.1
• Grafana 8.5.9 (не 8.5.27 из-за ошибки, появившейся в v8.5.10)
• Ubuntu 20.04.6 LTS

Улучшения и исправления:

• Метрика IOPS для виртуальных машин
• Инвентаризация VMware VBR
• История инвентаризации
• Панель мониторинга эволюции версий активов VMware
• Исправлено пустое значение datastoreVMObservedLatency на NFS
• Различные исправления ошибок

SexiGraf теперь поставляется только в виде новой OVA-аппаратной версии, больше никаких патчей (за исключением крайних случаев). Для миграции необходимо использовать функцию Export/Import, чтобы извлечь данные из вашей предыдущей версии SexiGraf и перенести их в новую.

Актуальная версия SexiGraf доступна для бесплатной загрузки на странице Quickstart.

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

На мероприятии VMware представила последнюю версию своего пакета безопасности VMware vDefend 4.2, о котором мы рассказывали вот тут. Эта версия представляет собой значительный шаг вперёд и опирается на прочную основу, заложенную её предшественниками, предлагая улучшенную масштабируемость, более точное обнаружение угроз и упрощённое управление.

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

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

Функция распределённого брандмауэра в vDefend 4.2 теперь поддерживает защиту VLAN и распределённых порт-групп наряду с сегментами, поддерживаемыми NSX. Это дополнение дает администраторам большую гибкость в применении политик безопасности для различных сетевых сегментов, что упрощает защиту широкого спектра виртуализированных сред.

Продвинутая защита от угроз

В vDefend 4.2 появилось 14 детекторов сетевого трафика, использующих машинное обучение и AI для обнаружения аномалий. Эта возможность продвинутой защиты от угроз позволяет осуществлять проактивную защиту как от известных, так и от неизвестных угроз. Решение для обнаружения и реагирования на сетевые угрозы (NDR), управляемое AI, непрерывно мониторит сетевой трафик, изучая нормальные шаблоны, чтобы в реальном времени обнаруживать и реагировать на вредоносную активность.

Упрощённое управление и дополнительные функции

Управление обнаружением и предотвращением вредоносного ПО стало проще в vDefend 4.2 благодаря новой функции упрощённого управления жизненным циклом Malware SVM. Эта функция устраняет необходимость в ручной установке веб-серверов, позволяя развертывать служебные виртуальные машины (Service VM) напрямую через API-вызовы. Кроме того, vDefend 4.2 поддерживает файлы OneNote, расширяя возможности обнаружения вредоносного ПО. Решение также вводит настраиваемую пользователем функцию обхода избыточной переподписки, которую можно применить глобально или для отдельных правил, что обеспечивает эффективное управление конкуренцией ресурсов без ущерба для безопасности.

Централизованное управление политиками и мониторинг

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

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

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

Как работает система обнаружения и реагирования на сетевые угрозы (NDR)?

Системы Network Detection & Response (NDR) непрерывно мониторят и анализируют огромные объёмы сетевого трафика и событий безопасности по различным элементам и сегментам сети. Эти системы собирают данные как с периметра сети, охватывая трафик «north-south», так и с внутренних сетевых сенсоров, которые отслеживают трафик «east-west». Используя AI и машинное обучение, инструменты NDR устанавливают базовую линию нормальной сетевой активности. Эта базовая линия позволяет системе идентифицировать и отмечать любые отклонения, которые могут указывать на вредоносное поведение.

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

Обновления продукта в будущем

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

• Gen AI Intelligent Assist: VMware планирует интегрировать интеллектуальную помощь на базе GenAI для защиты от угроз, что улучшит сортировку оповещений и предоставит контекстные данные о кампаниях угроз. Эта функция также будет предлагать рекомендации по устранению проблем, что упростит управление и реагирование на инциденты безопасности.
• Продвинутая защита от угроз: ожидаются значительные улучшения производительности распределённых систем IDS/IPS, с увеличением производительности до 3 раз по сравнению с текущими уровнями. VMware также представит настраиваемые сигнатуры для IDS/IPS, возможности быстрой оценки угроз и улучшенные меры по предотвращению вредоносных программ для локальных сред. Кроме того, будут развернуты новые датчики NDR для защиты физических серверов, что расширит возможности обнаружения угроз vDefend.
• Упрощение операций: предстоящие обновления упростят операции безопасности за счёт интеграции рабочих процессов с нативной функциональностью VPC в VCF 9. VMware также планирует ввести поддержку федерации для политик IDS/IPS и улучшить анализ правил брандмауэра, что сделает управление политиками более эффективным.

Более подробно о продукте VMware vDefend можно почитать здесь.

Недавно мы писали о технологии NVMe Tiering, которая появилась в режиме технологического превью в платформе VMware vSphere 8.0 Update 3.

Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.

Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.

Memory Tiering Enabled

Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTieringType

Tier 0 Memory

Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size

Tier 1 Memory

Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size

Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).

Устройства NVMe для тиринга

Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

$storageSystem = Get-View (Get-vmhost "esxi-01.williamlam.com").ExtensionData.ConfigManager.StorageSystem
($storageSystem.StorageDeviceInfo.ScsiLun | where {$_.UsedByMemoryTiering -eq $true}).CanonicalName

Соотношение NVMe-тиринга и DRAM

Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-vmhost "esxi-01.williamlam.com" | Get-AdvancedSetting -Name Mem.TierNvmePct).Value

Сводный отчёт

Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).

Вот скриншот того, как выглядит вывод скрипта:

В последнем релизе VMware vSAN 8.0 Update 3, утилита vSAN IO Trip Analyzer была существенно доработана. В чем именно заключается это улучшение? Теперь IO Trip Analyzer может быть включен для нескольких ВМ одновременно. Это особенно полезно при устранении проблем с производительностью комплексного сервиса, состоящего из нескольких ВМ.

Данное улучшение позволяет вам одновременно мониторить несколько ВМ и анализировать, на каком уровне у каждой из выбранных ВМ возникает задержка (latency). Обратите внимание, что это улучшение работает как для vSAN ESA, так и для vSAN OSA.

Дункан Эппинг записал на эту тему интересное обзорное видео:

Дункан Эппинг написал интересный пост.

Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.

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

Поэтому данную опцию было решено убрать.

Прошло довольно много времени с момента последнего крупного выпуска RabbitMQ — версия 3.0 была запущена еще в ноябре 2012 года. Хотя ожидание следующего большого обновления могло показаться долгим, за это время произошло немало событий. Вместе с несколькими приобретениями команда VMware Tanzu RabbitMQ представила значительные функции и улучшения в промежуточных выпусках. Сегодня RabbitMQ является ключевым компонентом портфеля VMware Tanzu Data Solutions в VMware Tanzu. Приверженность Broadcom к сообществу с открытым исходным кодом также имеет важное значение, поскольку все участники основной инженерной команды являются сотрудниками Broadcom.

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

Старое хранилище метаданных Mnesia использовалось столько же, сколько существует RabbitMQ. Как и следовало ожидать, за последние 17 лет в функциональности RabbitMQ произошло множество изменений, и многие функции были улучшены. Новое хранилище метаданных в RabbitMQ 4.0 (Khepri) использует тот же проверенный raft-based алгоритм, который уже несколько лет поддерживает безопасность данных в очередях Quorum Queue. Это делает систему очень устойчивой к разделению сети, что, в свою очередь, делает продукт Tanzu RabbitMQ более надежным.

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

Что касается производительности, в этом выпуске протокол AMQP 1.0 включен в ядро RabbitMQ. Это не означает, что старый протокол AMQP 0.9.1 не будет поддерживаться — это просто значит, что теперь можно выбрать более современный и стандартизированный протокол. Поддержка этой новой версии, опубликованной OASIS, укрепляет многопротокольный подход RabbitMQ и увеличивает его универсальность. В соответствии с другими "нативизациями" поддержка AMQP 1.0 также обеспечивает такие же улучшения производительности, которые были достигнуты при внедрении "нативного" MQTT в версиях 3.12 (MQTTv3) и 3.13 (MQTTv5).

На самом деле, пропускная способность (throughput) AMQP 1.0 между версиями 3.13 и 4.0 более чем удвоилась для классических очередей и очередей Quorum, а также для потоков. Как мы видели с нативной реализацией MQTT, такой подход к протоколам ведет к меньшему потреблению памяти на соединение. Это значит, что кластеры RabbitMQ теперь могут обрабатывать более чем в два раза больше соединений AMQP 1.0 по сравнению с предыдущими выпусками. Для получения дополнительной информации об этих улучшениях производительности, пожалуйста, ознакомьтесь с этой статьей в блоге.

Ранее пользователи не могли воспользоваться возможностями управления топологией, определенными в спецификации AMQP 1.0, что требовало заранее заданных очередей, байндингов и обменов. Такая жесткая настройка ограничивала ключевую силу RabbitMQ — его гибкие маршрутизационные возможности. Однако в версии 4.0 клиентские приложения теперь могут самостоятельно объявлять, удалять, очищать, связывать или отсоединять как очереди, так и обмены при использовании AMQP 1.0. Можно даже выполнять команду "get queue", которая предоставляет полезную информацию о лидере очереди и ее репликах в случае очередей Quorum. Эти клиентские библиотеки значительно помогают разработчикам извлекать максимум из протокола с минимальными усилиями. Например, такие функции, как подтверждения отправителя, становятся очень простыми. На сегодняшний день доступны клиенты Java и .NET, а скоро появятся и другие.

Нечасто удаление функции вызывает столько внимания, как удаление классических зеркальных очередей (Classic Mirrored Queues) в RabbitMQ. Несмотря на то, что эти старые зеркальные очереди были устаревшими более 3 лет, многие разочарованы их окончательным удалением. Хорошая новость заключается в том, что, хотя зеркалирование и было удалено, любые очереди, которые были зеркальными, не будут полностью удалены в версии 4.0, только их зеркальная часть. Также стоит отметить, что пользователям не обязательно использовать зеркалирование для публикации или потребления сообщений с конкретных узлов. Фактически, даже после удаления зеркальной очереди можно публиковать сообщения или потреблять их из очереди на любом узле в том же кластере RabbitMQ. Таким образом, приложения могут использовать те же классические очереди, что и раньше. Классические очереди продолжают поддерживаться без каких-либо изменений, нарушающих совместимость с клиентскими библиотеками. Для обеспечения дальнейшей безопасности данных реплицируемыми типами остаются очереди Quorum и потоки, обе из которых являются очень зрелыми технологиями. Дополнительную информацию о том, как мигрировать с классических зеркальных очередей на очереди Quorum, можно найти в этой статье в блоге.

Инженерная команда RabbitMQ продолжает развивать очереди Quorum, чтобы они работали быстрее и безопаснее, чем раньше. Ранее пользователи могли назначать до 255 приоритетов с помощью классических зеркальных очередей, однако это путь к полному приоритетному хаосу и путанице. В спецификации JMS для AMQP 1.0 определено всего два приоритета — нормальный и высокий.

Это то, что было реализовано в очередях Quorum для версии 4.0. Любое значение приоритета между 0 и 4 (включительно) считается нормальным приоритетом. Значения выше 4 считаются высоким приоритетом, а если издатель не указывает приоритет сообщения, предполагается значение 4 (нормальный приоритет). Что делать, если пользователям нужно больше контроля? Возможно, пришло время пересмотреть определения приоритетов сообщений. Приоритеты часто наследуются от старых систем и редко пересматриваются, как видно из спецификации JMS. Если это не удается разрешить, одним из решений является использование нескольких очередей — теперь это стало проще благодаря более быстрому времени загрузки очередей Quorum в RabbitMQ 4.0 и программной декларации AMQP 1.0. Кроме того, в очередях Quorum теперь установлено значение по умолчанию для ограничения на доставку — 20, а также приоритеты для одного активного потребителя (Single Active Consumer).

Добавлен и новый тип обмена — Random Exchange. В основном предназначен для использования в сценариях "запрос-ответ", в которых сообщения всегда доставляются в локальную очередь (чтобы уменьшить задержку при публикации). Если к тому же обмену подключено несколько локальных очередей, для доставки сообщения будет выбрана одна из них случайным образом.

Для пользователей Kubernetes добавлена новая диаграмма Helm, которая развертывает как операторы Kubernetes с открытым исходным кодом, так и коммерческие операторы кластеров и топологии Tanzu. Кроме того, теперь в определениях пользовательских ресурсов Kubernetes (Custom Resource Definitions) поддерживаются регулярные выражения, что позволяет пользователям определять диапазон виртуальных хостов (vhosts) вместо их явного объявления каждый раз.

Функции устойчивости репликации "Горячий резерв" (Warm Standby Replication) также получили улучшения в этом выпуске. В версии 3.13 был добавлен конфигурационный файл, облегчающий пользователям настройку и конфигурацию WSR, который в версии 4.0 был улучшен поддержкой списков и шаблонов для виртуальных хостов и т. д. Поддержка секретов теперь доступна через тот же конфигурационный файл, чтобы помочь обеспечить дополнительную безопасность для репликационной связи между верхним и нижним кластерами; в настоящее время поддерживается Hashicorp Vault. Пользователи также могут помечать конкретные определения shovel и federation для синхронизации в рамках процесса репликации горячего резерва. Оператор Standby Replication для Kubernetes заменен этим конфигурационным файлом, что упрощает настройку WSR независимо от среды.

Таким образом, RabbitMQ 4.0 приносит несколько ключевых улучшений, особенно в области совместимости и устойчивости. Наиболее заметное для пользователей изменение — внедрение AMQP 1.0 как основного протокола с значительными улучшениями пропускной способности и подключений. Этот выпуск и его дополнительные клиентские библиотеки открывают путь к дальнейшему развитию RabbitMQ, что позволит ему оставаться наиболее широко используемым брокером сообщений во всем мире на долгие годы.

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

Обновление и патчинг в одном рабочем процессе

Одним из ключевых улучшений в VMware Cloud Foundation 5.2 является новая функция под названием «Flexible Bill of Materials (BOM)», которая позволяет выбирать конкретные версии отдельных компонентов во время обновления домена рабочих нагрузок (workload domain). Это упрощает процесс обновления, сокращая количество операций по обслуживанию и минимизируя простои. В предыдущих версиях VCF процесс требовал двух операций обслуживания: одной для обновления и второй для применения асинхронного патча. Теперь же гибкий BOM в VCF 5.2 упрощает процесс, снижая административную нагрузку и потенциальные риски.

Выглядит это следующим образом (кликните на картинку, чтобы открыть анимацию):

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

Также на эту тему есть хорошее обзорное видео от VMware:

Улучшения VCF 5.2 в управлении жизненным циклом

Помимо опции гибкого списка компонентов (BOM), VCF 5.2 вводит несколько других улучшений, упрощающих процесс обновления и развертывания. Например, администраторы VCF теперь могут применять асинхронные патчи напрямую через интерфейс SDDC Manager, что упрощает поддержание актуальности среды. Процесс развертывания доменов рабочих нагрузок также был оптимизирован: асинхронные патчи автоматически включаются, чтобы обеспечить более безопасные и актуальные новые развертывания.

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

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

Вильям Лам написал интересную статью о поддержке технологии Intel Neural Processing Unit (NPU) на платформе VMware ESXi.

Начиная с процессоров Intel Meteor Lake (14 поколения), которые теперь входят в новый бренд Intel Core Ultra Processor (серия 1), встроенный нейронный процессор (Neural Processing Unit, NPU) интегрирован прямо в систему на кристалле (system-on-chip, SoC) и оптимизирован для энергоэффективного выполнения AI-инференса.

Автор дает ссылку на эту статью от Chips and Cheese о новом нейронном процессоре Intel Meteor Lake NPU, которую он нашел очень познавательной и определённо рекомендует прочесть, если вы новичок в теме NPU.

Хотя вы уже можете использовать интегрированную графику Intel iGPU на таких платформах, как Intel NUC, с ESXi для инференса рабочих нагрузок, Вильяму стало интересно, сможет ли этот новый нейронный процессор Intel NPU работать с ESXi?

Недавно Вильям получил доступ к ASUS NUC 14 Pro (на который позже он сделает подробный обзор), в котором установлен новый нейронный процессор Intel NPU. После успешной установки последней версии VMware ESXi 8.0 Update 3, он увидел, что акселератор Intel NPU представлен как PCIe-устройство, которое можно включить в режиме passthrough и, видимо, использовать внутри виртуальной машины.

Для тестирования он использовал Ubuntu 22.04 и библиотеку ускорения Intel NPU, чтобы убедиться, что он может получить доступ к NPU.

Шаг 1 - Создайте виртуальную машину с Ubuntu 22.04 и настройте резервирование памяти (memory reservation - это требуется для PCIe passthrough), затем добавьте устройство NPU, которое отобразится как Meteor Lake NPU.

Примечание: вам нужно будет отключить Secure Boot (этот режим включен по умолчанию), так как необходимо установить более новую версию ядра Linux, которая всё ещё находится в разработке. Отредактируйте виртуальную машину и перейдите в VM Options -> Boot Options, чтобы отключить его.

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

dmesg | grep vpu

После подачи обращения в поддержку Github по поводу драйвера Intel NPU, было предложено, что можно инициализировать устройство, используя новую опцию ядра, доступную только в версии 6.11 и выше.

Шаг 2 - Используя эту инструкцию, мы можем установить ядро Linux версии 6.11, выполнив следующие команды:

cd /tmp

wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-headers-6.11.0-061100rc6_6.11.0-061100rc6.202409010834_all.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-headers-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-image-unsigned-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb
wget -c https://kernel.ubuntu.com/mainline/v6.11-rc6/amd64/linux-modules-6.11.0-061100rc6-generic_6.11.0-061100rc6.202409010834_amd64.deb

dpkg -i *.deb

reboot

После перезагрузки вашей системы Ubuntu вы можете убедиться, что теперь она использует версию ядра 6.11, выполнив команду:

uname -r

Шаг 3 - Теперь мы можем установить драйвер Intel NPU для Linux, и на момент публикации этой статьи последняя версия — 1.8.0. Для этого выполните следующие команды:

cd /tmp

wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-driver-compiler-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-fw-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/intel/linux-npu-driver/releases/download/v1.8.0/intel-level-zero-npu_1.8.0.20240916-10885588273_ubuntu24.04_amd64.deb
wget https://github.com/oneapi-src/level-zero/releases/download/v1.17.6/level-zero_1.17.6+u22.04_amd64.deb

apt --fix-broken install -y
apt install build-essential libtbb12 cmake -y

dpkg -i *.deb

Нам также нужно создать следующий файл, который включит необходимую опцию ядра (force_snoop=1) для инициализации NPU по умолчанию, выполнив следующую команду:

cat > /etc/modprobe.d/intel_vpu.conf << EOF

options intel_vpu force_snoop=1

EOF

Теперь перезагрузите систему, и NPU должен успешно инициализироваться, как показано на скриншоте ниже.

Наконец, если вы хотите убедиться, что NPU полностью функционален, в библиотеке Intel NPU Acceleration есть несколько примеров, включая примеры малых языковых моделей (SLM), такие как TinyLlama, Phi-2, Phi-3, T5 и другие.

Для настройки вашего окружения Python с использованием conda выполните следующее:

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda
eval "$(/$HOME/miniconda3/bin/conda shell.bash hook)"

conda config --set auto_activate_base true
conda init
conda create -n npu python=3.10 -y
conda activate npu
conda install -c conda-forge libstdcxx-ng=12 -y

pip install accelerate intel-npu-acceleration-library==1.3.0 transformers==4.39.3

git clone https://github.com/intel/intel-npu-acceleration-library.git
cd intel-npu-acceleration-library
git checkout v1.3.0

Автор попробовал пример tiny_llama_chat.py (видимо, тренировочные данные для этой модели могли быть основаны на изображениях или художниках).

Независимо от того, используете ли вы новую библиотеку Intel NPU Acceleration или фреймворк OpenVino, теперь у вас есть доступ к ещё одному ускорителю с использованием ESXi, что может быть полезно для периферийных развертываний, особенно для рабочих нагрузок, требующих инференса AI, и теперь с меньшим энергопотреблением.

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

from openvino.runtime import Core

def list_available_devices():
    # Initialize the OpenVINO runtime core
    core = Core()

    # Get the list of available devices
    devices = core.available_devices

    if not devices:
        print("No devices found.")
    else:
        print("Available devices:")
        for device in devices:
            print(f"- {device}")

        # Optional: Print additional device information
        for device in devices:
            device_info = core.get_property(device, "FULL_DEVICE_NAME")
            print(f"\nDevice: {device}\nFull Device Name: {device_info}")

if __name__ == "__main__":
    list_available_devices()

Компания Broadcom выпустила интересное видео, где Mark Achtemichuk и Uday Kulkurne обсуждают оптимизацию AI/ML нагрузок с использованием аппаратной платформы NVIDIA GPU и решения VMware Cloud Foundation:

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

Виртуализация AI/ML задач, работающих на GPU, представляет собой вызов, так как традиционно считается, что виртуализация может значительно снижать производительность по сравнению с «чистой» конфигурацией на физическом оборудовании (bare metal). Однако VMware Cloud Foundation демонстрирует почти аналогичную производительность с минимальными потерями за счет умной виртуализации и использования технологий NVIDIA.

Рассматриваемые в данном видо графические процессоры от NVIDIA включают модели H100, A100 и L4, каждая из которых имеет уникальные характеристики для обработки AI/ML задач. Например, H100 оснащен 80 миллиардами транзисторов и способен ускорять работу трансформеров (на основе архитектуры GPT) в шесть раз. Особенностью H100 является возможность разделения GPU на несколько независимых сегментов, что позволяет обрабатывать задачи параллельно без взаимного влияния. A100 и L4 также обладают мощными возможностями для AI/ML, с небольшими различиями в спецификациях и применимости для графических задач и машинного обучения.

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

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

В серии тестов было проверено, как виртуализированные GPU справляются с различными AI/ML задачами по сравнению с физическим оборудованием. Используя стандартные бенчмарки, такие как ML Commons, было показано, что виртуализированные GPU демонстрируют производительность от 95% до 104% по сравнению с bare metal конфигурациями в режиме инференса (вычисления запросов) и около 92-98% в режиме обучения. Это означает, что даже в виртуализированной среде можно добиться почти той же скорости, что и при использовании физического оборудования, а в некоторых случаях — даже превзойти её.

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

Компания VMware представила обновленную версию документа "Best Practices for VMware vSphere 8.0 Update 3", описывающего лучшие практики повышения производительности для последней версии платформы VMware vSphere 8.0 Update 3 — ценный ресурс, наполненный экспертными советами по оптимизации быстродействия. Хотя это и не является всеобъемлющим руководством по планированию и настройке ваших развертываний, он предоставляет важные рекомендации по улучшению производительности в ключевых областях.

Краткий обзор содержания:

• Глава 1: Оборудование для использования с VMware vSphere (Стр. 11) — узнайте важные советы по выбору правильного оборудования, чтобы максимально эффективно использовать вашу среду vSphere.
• Глава 2: ESXi и виртуальные машины (Стр. 25) — ознакомьтесь с лучшими практиками для платформы VMware ESXi и тонкими настройками виртуальных машин, работающих в этой среде.
• Глава 3: Гостевые операционные системы (Стр. 57) — узнайте, как правильно оптимизировать гостевые ОС, работающие в ваших виртуальных машинах vSphere.
• Глава 4: Управление виртуальной инфраструктурой (Стр. 69) — получите советы по эффективному управлению для поддержания высокопроизводительной виртуальной инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vSphere Memory Tiering - это очень интересная функция, которую VMware выпустила в качестве технического превью в составе vSphere 8.0 Update 3, чтобы дать своим клиентам возможность оценить механику ранжирования памяти в их тестовых средах. Об этом мы уже немного рассказывали, а сегодня дополним.

По сути, Memory Tiering использует более дешевые устройства в качестве памяти. В vSphere 8.0 Update 3 vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Memory Tiering также решает проблемы несоответствия между ядрами процессора и объемом памяти и способствует лучшей консолидации рабочих нагрузок и виртуальных машин.

Memory Tiering настраивается на каждом ESXi в кластере, и все хосты должны работать на vSphere 8.0 U3. По умолчанию соотношение DRAM к NVMe составляет 4:1, но его можно изменить для использования большего количества ресурсов NVMe в качестве памяти.

Для изменения этого соотношения нужно зайти в Host > Manage > System > Advanced settings и поменять там настройку Mem.TierNvmePct. По умолчанию это 25, то есть NVMe занимает 25% от общей оперативной памяти хоста ESXi. Максимальное значение составляет 400, минимальное - 1.

Технические подробности настройки vSphere Memory Tiering описаны в статье базы знаний KB 95944. Там можно скачать документ "Memory Tiering over NVMe Tech Preview", где описываются все аспекты использования данной технологии:

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

• NVMe Tiering in vSphere 8.0 Update 3 is a Homelab game changer!
• Quick Tip - NVMe Tiering configured but not working?

На конференции VMware Explore 2024, вместе с презентацией новой версии платформы VMware Cloud Foundation 9, Broadcom также объявила о планах разработки следующего поколения VMware vSphere Virtual Volumes (vVols). Следующее поколение vVols будет преследовать три основные цели: обеспечить согласованный и оптимизированный пользовательский опыт на разных платформах хранения, адаптировать vVols для современных масштабируемых задач, таких как рабочие нагрузки AI/ML и развёртывания облачных провайдеров, а также полностью интегрироваться с VMware Cloud Foundation (VCF).

vVols использует управление на основе политик хранилищ (Storage Policy-Based Management, SPBM) для оптимизации операций и минимизации потребности в специализированных навыках для работы с инфраструктурой хранения. vVols устраняет необходимость в ручном предоставлении хранилища, заменяя это описательными политиками на уровне ВМ или VMDK, которые могут быть применены или обновлены через простой рабочий процесс.

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

Планируемые преимущества следующего поколения vVols для клиентов включают:

• Полная интеграция с VMware Cloud Foundation: установка, развертывание и управление хранилищем с VCF, пригодность для использования в качестве основного и дополнительного хранилища для всех доменов рабочих нагрузок.
• Прописанная модель VASA для обеспечения согласованного и оптимизированного пользовательского опыта на всех платформах хранения.
• Поддержка масштабируемых сценариев использования для облаков.
• Обеспечение высокой доступности и развертывания с растянутыми кластерами.
• Бесшовная миграция с платформы vVols без простоев.
• Масштабируемые, неизменяемые снимки (immutable snapshots) как для традиционных, так и для современных приложений.

Для получения дополнительной информации о планируемых нововведениях vSAN и vVols рекомендуем посмотреть записи вот этих сессий VMware Explore 2024:

• VMware’s Vision for Storage and Data Protection in VMware Cloud Foundation [VCFB2086LV]
• What’s New with vSAN and Storage Operations in VMware Cloud Foundation [VCFB2085LV]
• vVols and Stretched Clusters with Pure Storage and VMware [VCFB2397LVS]
• Workload Provisioning And Protection Made Easy With VMware And NetApp [VCFB2433LVS]

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

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

• Быстрота и уверенность в условиях кризиса - VMware Live Recovery предлагает и то, и другое. Когда случаются атаки вымогателей или катастрофы, скорость и уверенность являются решающими факторами для успешного восстановления.
• Унифицированный подход к киберустойчивости - VMware Live Recovery отвечает потребностям в восстановлении как после атак вымогателей, так и при катастрофах. Используя комбинацию механизмов безопасного восстановления, защиты east-west и укрепленной (hardened) инфраструктуры, VMware гарантирует, что критически важные рабочие нагрузки защищены в вашей среде VMware vSphere.
• Ускоренное восстановление и упрощённое использование - VMware Live Recovery предоставляет мощную киберустойчивость и устойчивость данных для VMware Cloud Foundation. Это решение обеспечивает восстановление после атак вымогателей и катастроф в унифицированной системе управления, с ускоренным процессом восстановления и упрощенным потреблением, с гибким лицензированием для различных сценариев и облаков.
• Защита вашей виртуальной среды VMware - с помощью VMware Live Recovery вы можете защищать свою среду VMware на различных платформах: в вашем локальном датацентре, в VMware Cloud на AWS или другом облачном провайдере. Это гарантирует защиту от широкого спектра угроз, включая ransomware, аппаратные сбои и природные катастрофы.

Какие новые возможности были представлены на VMware Explore 2024:

1. Локальное восстановление vSAN
2. Удалённая репликация снимков vSAN
3. Изолированная среда восстановления в собственном датацентре (On-Premises Isolated Recovery Environment, IRE)

Локальное восстановление vSAN

Теперь вы можете применять ускоренное до 16 раз обратное восстановление (failback) из VMware Cloud на AWS, используя локальные снимки VMware как основу для процесса восстановления, восстанавливая только проверенные изменения. Это приводит к 75%-му сокращению времени простоя, минимизируя сбои в работе.

Удалённая репликация снапшотов vSAN

Теперь расширены возможности локальных снимков vSAN для создания удалённых снимков, что позволят сохранять более глубокую историю неизменяемых снимков (до 200) с помощью унифицированного виртуального модуля (Virtual Appliance) для управления. Эта новая функция обеспечивает репликацию vSAN-to-vSAN и позволяет достичь следующих результатов:

• Повышенная устойчивость данных: до 200 точек восстановления на ВМ.
• Снижение простоев, благодаря опыту VMware в оркестрации восстановления.
• Упрощённое управление: единый модуль упрощает процесс.
• Повышенная масштабируемость и эффективность: использование кластеров хранения vSAN улучшает производительность.

Преимущества локальной изолированной среды восстановления (IRE)

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

Особенности:

• Гибкость и выбор: выбирайте изолированные "чистые комнаты" VCF локально или в облаке.
• Суверенитет данных: сохраняйте контроль над своими данными и обеспечивайте соответствие требованиям конфиденциальности и местонахождения данных.
• Интеграция полного стека: раскройте потенциал интегрированной киберустойчивости VCF для защиты рабочих нагрузок в любом месте.

Более подробно о новых возможностях VMware Live Recovery вы можете узнать из записанных сессий на VMware Explore.

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

Недавно был выпущен документ "VMware vSAN 8 Express Storage Architecture on Intel Fourth Generation Xeon Scalable Processors", в котором рассказывается о преимуществах использования архитектуры vSAN 8 ESA на Intel Xeon Gen 4:

Преимущества работы vSAN 8 ESA на Intel Xeon 4 поколения

• Оптимизация хранения: в отличие от двухуровневой архитектуры предыдущих версий, ESA использует одноуровневую систему с NVMe-накопителями на базе TLC флэш-памяти, что позволяет увеличить емкость и производительность хранилища. Это снижает расходы на хранение данных, благодаря более эффективной компрессии данных и встроенной системе снапшотов.
• Скорость и производительность: VMware vSAN 8 ESA, в сочетании с Intel Xeon 4, значительно ускоряет работу как традиционных, так и современных приложений. Интеграция с новейшими технологиями Intel, такими как AMX (Advanced Matrix Extensions) и AVX-512 (Advanced Vector Extensions), увеличивает количество транзакций и снижает время отклика при обработке больших данных.
• Снижение задержек и повышение производительности: в тестах ESA показала до 6.2-кратного роста производительности и до 7.1-кратного снижения задержек по сравнению с предыдущими поколениями vSAN и Intel Xeon. Это позволяет консолидировать критически важные рабочие нагрузки, такие как базы данных SQL и VDI, без снижения производительности.

Поддержка AI и современных рабочих нагрузок

Для обеспечения поддержки AI-приложений, vSAN 8 ESA, благодаря новейшим процессорам Intel Xeon, справляется с обработкой больших объемов данных, необходимых для глубокого обучения и инференса, особенно в задачах классификации изображений и обработки естественного языка. Тесты показали до 9-кратного увеличения производительности при использовании INT8 в задачах машинного обучения.

Снижение затрат и повышение эффективности

За счет высокой плотности виртуальных машин и оптимизированного использования ресурсов, VMware vSAN 8 ESA позволяет сократить инфраструктурные расходы, связанные с оборудованием и энергопотреблением. Использование RAID-6 на уровне кластера с производительностью RAID-1 повышает надежность и безопасность данных без ущерба для производительности.

Заключение

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

Только мы порадовались тому, что Broadcom продолжает поддерживать решения VMware, в частности выпустив VMware Workstation 17.6 Pro, которая стала бесплатной для некоммерческого использования - так пришли новости о том, что продукт просто не устанавливается:). Об этом нам рассказал наш читатель Сергей, дав ссылку на соответствующую ветку форумов Broadcom.

Сообщение об ошибке при установке выглядит так:

An error occurred while applying security settings. Authenticated Users is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network. Check your network connection and click Retry, or Cancel to end the install.

Проблема появляется на тех системах, которые работают не в нативной локали en-us (а значит тестировщики тупо не протестировали другие локали).

Обходной путь для установки версии 17.6 на неанглоязычные версии Windows 11 выглядит так:

При установке 17.6 требуется работа с группами "Users" и "Authenticated Users", что вызывает сбой на неанглийских версиях Windows, где у этих групп локальные названия. Чтобы решить проблему, можно вручную добавить группы с именами "Users" и "Authenticated Users" в разделе Computer Administration / Local Users and Groups. В эти группы нужно добавить локальные эквиваленты, например, "Авторизованные пользователи" (или другую версию на вашем языке).

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

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

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

Команды часто сталкиваются с серьезными препятствиями при создании собственных решений на основе машинного обучения. Какую технику суммаризации следует использовать для больших документов, которые превышают размер контекстного окна моделей LLM? Какие библиотеки лучше всего подходят для парсинга больших документов, таких как PDF, с их сложными структурами (например, таблицы, графики и изображения)? Какая LLM подходит для суммаризации длинных расшифровок встреч, где есть множество смен диалогов, что затрудняет понимание ценной контекстной информации? Какие эффективные подсказки (prompts) следует использовать для выбранных моделей?

Сервис Summarize-and-Chat

Summarize-and-Chat — это проект с открытым исходным кодом для VMware Private AI, который решает вышеуказанные задачи и помогает командам начать работу с их кейсами. Этот проект может быть развернут на VMware Private AI Foundation с NVIDIA, чтобы клиенты могли начать использовать GenAI на своих приватных данных. Данная возможность предоставляет универсальный и масштабируемый подход для типичных задач суммаризации, обеспечивая взаимодействие на естественном языке через чат-интерфейсы. Интеграция суммаризации документов и общения через чат в единой системе имеет несколько преимуществ. Во-первых, это позволяет пользователям получать краткие резюме различного контента, включая статьи, отзывы клиентов, баги/проблемы или пропущенные встречи.

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

Ключевые особенности

Summarize-and-Chat предоставляет следующие возможности:

• Поддержка различных типов и форматов документов (PDF, DOCX, PPTX, TXT, VTT и популярных аудиофайлов - mp3, mp4, mpeg, mpga, m4a, wav и webm).
• Поддержка открытых LLM на движке вывода, совместимого с OpenAI.
• Интуитивно понятный пользовательский интерфейс для загрузки файлов, генерации резюме и чатов.
• Суммаризация:
  • Вставляйте, копируйте или загружайте файлы и просматривайте их.
  • Выбирайте способ суммаризации (пользовательские подсказки, размер фрагмента, диапазон страниц для документов или временной диапазон для аудио).
  • Регулируйте длину резюмирующего вывода.
  • Получайте резюме за считанные секунды и загружайте его.
• Чат с вашим документом:
  • Автоматически сгенерированные вопросы по документу.
  • Получайте ответ с указанием источника за считанные секунды.
• Анализ инсайтов:
  • Выбирайте два или более документа.
  • Пишите запрос для сравнения или определения инсайтов из выбранных документов.
• Преобразование речи в текст.
• Поддержка различных PDF-парсеров: PyPDF, PDFMiner, PyMUPDF.
• API.

Шаги развертывания

Настройка Summarize-and-Chat проста и включает несколько конфигурационных шагов для каждого компонента.

Summarize-and-Chat включает три компонента:

1. Summarization-client: веб-приложение на Angular/Clarity.
2. Summarization-server: сервер-шлюз на FastAPI для управления основными функциями приложения, включая:

• Контроль доступа.
• Пайплайн обработки документов: обработка документов, извлечение метаданных для заполнения векторного индекса (текстовые эмбеддинги).
• Суммаризация с использованием LangChain Map Reduce. Этот подход позволяет суммаризовать большие документы, которые превышают лимит токенов на входе модели.
• Улучшенное извлечение с помощью Retrieval Augmented Generation (RAG), используя возможности ранжирования LlamaIndex и pgvector для повышения производительности в системах вопрос-ответ.

3. Speed-to-text (STT): преобразование аудио в текст с использованием OpenAI's faster-whisper.

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

Использование Summarize-and-Chat

Теперь давайте посмотрим, как можно использовать Summarize-and-Chat для суммаризации длинного PDF-документа и полноценного взаимодействия с ним.

Для начала войдите в клиент суммаризации, используя ваши учетные данные Okta.

1. Загрузите файл и добавьте метаданные (дату, версию).
2. Выберите опцию QUICK для краткого резюме или DETAILED для детальной суммаризации.
3. Нажмите кнопку SUMMARIZE, и резюме будет сгенерировано мгновенно. Для длинного документа вы увидите оценку времени и получите уведомление, когда резюме будет готово к загрузке.

Чат с вашим документом

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

Что дальше

Broadcom представила Summarize-and-Chat с открытым исходным кодом, чтобы поддержать проекты по работе с данными и машинному обучению на платформе VMware Private AI.

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

В рамках анонсов конференции Explore 2024, касающихся VMware Private AI Foundation с NVIDIA (PAIF-N), в компании VMware решили обновить Improved RAG Starter Pack v2.0, чтобы помочь клиентам воспользоваться новейшими микросервисами для инференса NVIDIA (модули NIM), которые обеспечивают атрибуты промышленного уровня (надёжность, масштабируемость и безопасность) для языковых моделей, используемых в системах Retrieval Augmented Generation (RAG).

Следуя духу оригинального Improved RAG Starter Pack (v1.0), Broadcom предлагает серию Jupyter-блокнотов, реализующих улучшенные методы поиска. Эти методы обогащают большие языковые модели (LLMs) актуальными и достоверными контекстами, помогая им генерировать более точные и надёжные ответы на вопросы, связанные с специализированными знаниями, которые могут не быть частью их предобученного датасета. Благодаря этому можно эффективно снизить "галлюцинации" LLM и повысить надёжность приложений, управляемых AI.

Новые функции обновлённого Improved RAG Starter Pack:

• Используются NVIDIA NIMs для LLM, текстовых встраиваний и ранжирования текстов — трёх основных языковых моделей, которые питают RAG-пайплайны.
• Обновили LlamaIndex до версии v0.11.1.
• Используются Meta-Llama3-8b-Instruct в качестве генератора LLM, который управляет RAG-пайплайном.
• Заменили OpenAI GPT-4 на Meta-Llama-3-70b-Instruct как движок для DeepEval для выполнения двух ключевых задач, связанных с оценкой RAG-пайплайнов:
  • Для синтеза наборов данных для оценки систем RAG.
  • Для оценки ("судейства") RAG-пайплайнов путём оценки ответов пайплайна на запросы, извлечённые из набора для оценки. Каждый ответ оценивается по нескольким метрикам DeepEval.

Анатомия улучшенного RAG Starter Pack

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

Помимо NVIDIA NIM, системы RAG используют такие популярные технологии, как LlamaIndex (фреймворк для разработки приложений на основе LLM), vLLM (сервис для инференса LLM) и PostgreSQL с PGVector (масштабируемая и надёжная векторная база данных, которую можно развернуть с помощью VMware Data Services Manager).

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

Структура каталога организована следующим образом.

Теперь давайте обсудим содержание каждой секции.

Настройка сервисов NIM и vLLM (00)

Эта секция содержит инструкции и скрипты для Linux shell, которые необходимы для развертывания сервисов NVIDIA NIM и vLLM, требуемых для реализации RAG-пайплайнов и их оценки.

Инициализация PGVector (01)

Эта секция предлагает несколько альтернатив для развертывания PostgreSQL с PGVector. PGVector — это векторное хранилище, которое будет использоваться LlamaIndex для хранения базы знаний (текстов, встраиваний и метаданных), что позволит расширить знания LLM и обеспечить более точные ответы на запросы пользователей.

Загрузка документов базы знаний (02)

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

Загрузка документов в систему (03)

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

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

Генерация оценочного набора данных (04)

Jupyter-блокнот в этой папке демонстрирует использование Synthesizer из DeepEval для создания набора данных вопросов и ответов, который впоследствии будет использоваться метриками DeepEval для оценки качества RAG-пайплайнов. Это позволит определить, как изменения ключевых компонентов пайплайна RAG, таких как LLM, модели встраиваний, модели повторного ранжирования, векторные хранилища и алгоритмы поиска, влияют на качество генерации. Для синтетической генерации оценочного набора данных используется модель Meta-Llama-3-70b-Instruct.

Реализация вариантов RAG (05)

В этом каталоге содержатся три подкаталога, каждый из которых включает Jupyter-блокнот, исследующий один из следующих вариантов реализации RAG-пайплайна на основе LlamaIndex и открытых LLM, обслуживаемых через vLLM:

• Стандартный RAG-пайплайн + повторное ранжирование: этот блокнот реализует стандартный RAG-пайплайн с использованием LlamaIndex, включая финальный этап повторного ранжирования, который управляется моделью ранжирования. В отличие от модели встраиваний, повторное ранжирование использует вопросы и документы в качестве входных данных и напрямую выдаёт степень схожести, а не встраивание. Вы можете получить оценку релевантности, вводя запрос и отрывок в модель повторного ранжирования. VMware использует следующие микросервисы NVIDIA (NIM) для работы RAG-системы:
  • Генератор LLM для RAG: Meta-Llama-3-8b-Instruct
  • Модель встраиваний для RAG: nvidia/nv-embedqa-e5-v5
  • Модель повторного ранжирования для RAG: nvidia/nv-rerankqa-mistral-4b-v3

Следующая картинка иллюстрирует, как работает эта RAG-система.

• Извлечение с использованием окон предложений:

Метод извлечения с использованием окон фраз (Sentence Window Retrieval, SWR) улучшает точность и релевантность извлечения информации в RAG-пайплайнах, фокусируясь на определённом окне фраз вокруг целевой фразы. Такой подход повышает точность за счёт фильтрации нерелевантной информации и повышает эффективность, сокращая объём текста, обрабатываемого во время поиска.

Разработчики могут регулировать размер этого окна, чтобы адаптировать поиск к своим конкретным задачам. Однако у метода есть потенциальные недостатки: узкая фокусировка может привести к упущению важной информации в соседнем тексте, что делает выбор подходящего размера окна контекста критически важным для оптимизации как точности, так и полноты процесса поиска. Jupyter-блокнот в этой директории использует реализацию SWR от LlamaIndex через модуль Sentence Window Node Parsing, который разбивает документ на узлы, каждый из которых представляет собой фразу. Каждый узел содержит окно из соседних фраз в метаданных узлов. Этот список узлов повторно ранжируется перед передачей LLM для генерации ответа на запрос на основе данных из узлов.

• Автоматическое слияние при извлечении:

Метод автоматического слияния при извлечении — это подход RAG, разработанный для решения проблемы фрагментации контекста в языковых моделях, особенно когда традиционные процессы поиска создают разрозненные фрагменты текста. Этот метод вводит иерархическую структуру, где меньшие текстовые фрагменты связаны с более крупными родительскими блоками. В процессе извлечения, если определённый порог меньших фрагментов из одного родительского блока достигнут, они автоматически сливаются. Такой подход гарантирует, что система собирает более крупные, связные родительские блоки, вместо извлечения разрозненных фрагментов. Ноутбук в этой директории использует AutoMergingRetriever от LlamaIndex для реализации этого варианта RAG.

Оценка RAG-пайплайна (06)

Эта папка содержит Jupyter-блокнот, который использует DeepEval для оценки ранее реализованных RAG-пайплайнов. Для этой цели DeepEval использует оценочный набор данных, сгенерированный на предыдущем шаге. Вот краткое описание метрик DeepEval, используемых для сравнения различных реализаций RAG-пайплайнов. Обратите внимание, что алгоритмы метрик DeepEval могут объяснить, почему LLM присвоил каждую оценку. В нашем случае эта функция включена, и вы сможете увидеть её работу.

• Contextual Precision оценивает ретривер вашего RAG-пайплайна, проверяя, расположены ли узлы в вашем контексте поиска, которые релевантны данному запросу, выше, чем нерелевантные узлы.
• Faithfulness оценивает качество генератора вашего RAG-пайплайна, проверяя, соответствует ли фактический вывод содержимому вашего контекста поиска.
• Contextual Recall оценивает качество ретривера вашего RAG-пайплайна, проверяя, насколько контекст поиска соответствует ожидаемому результату.
• Answer Relevancy измеряет, насколько релевантен фактический вывод вашего RAG-пайплайна по отношению к данному запросу.
• Hallucination — эта метрика определяет, генерирует ли ваш LLM фактически корректную информацию, сравнивая фактический вывод с предоставленным контекстом. Это фундаментальная метрика, так как одной из главных целей RAG-пайплайнов является помощь LLM в генерации точных, актуальных и фактических ответов на запросы пользователей.

Оценки DeepEval были выполнены с использованием следующей конфигурации:

• LLM-оценщик, оценивающий метрики DeepEval: Meta-Llama-3-70b-Instruct, работающая на vLLM в режиме guided-JSON.
  
  Следующая таблица показывает результаты оценки из одного из экспериментов VMware, который включал более 40 пар вопросов и ответов.

Следующая диаграмма представляет другой ракурс взгляда на предыдущий результат:

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

Заключение

Обновлённый RAG Starter Pack предоставляет ценный инструментарий для тех, кто внедряет системы RAG, включая серию хорошо документированных Python-блокнотов, предназначенных для улучшения LLM за счёт углубления контекстного понимания. В этот пакет включены передовые методы поиска и такие инструменты, как DeepEval, для оценки системы, которые помогают снизить такие проблемы, как "галлюцинации" LLM, и повысить надёжность ответов AI. Репозиторий на GitHub хорошо структурирован и предлагает пользователям понятное пошаговое руководство, которому легко следовать, даже если вы не являетесь специалистом в области данных. Клиенты и партнёры Broadcom, использующие PAIF-N, найдут этот пакет полезным для запуска приложений на базе генеративного AI в инфраструктурах VMware Cloud Foundation. Ожидайте новых статей, в которых VMware рассмотрит ключевые аспекты безопасности и защиты в производственных RAG-пайплайнах.

Компания Broadcom, после того, как объявила о бесплатности платформы VMware Workstation, продолжает поддерживать продукт, что радует. Сразу после конференции Explore 2024 было выпущено обновление VMware Workstation 17.6 Pro.

Давайте посмотрим на новые функции VMware Workstation 17.6 Pro:

1. Интерфейс vmcli

vmcli — это инструмент командной строки, включённый в VMware Workstation Pro, который позволяет пользователям взаимодействовать с гипервизором напрямую из терминала Linux или macOS, либо командной строки Windows. С помощью vmcli вы можете выполнять различные операции, такие как создание новых виртуальных машин, создание шаблонов ВМ, включение машин и изменение их различных настроек. Кроме того, вы можете создавать скрипты для последовательного выполнения нескольких команд.

2. Поддержка новых гостевых и хостовых ОС

Основные новые возможности Workstation 17.6 включают поддержку новых гостевых операционных систем и обновленных версий этих ОС. Обратите внимание на следующие системы, поддержка которых была добавлена в этом выпуске:

• Windows Server 2025
• Windows 11 версии 23H2
• Ubuntu 24.04
• Fedora 40

Кроме того, VMware Workstation теперь поддерживает и новые хостовые операционные системы, на которые можно установить VMware Workstation, которые полностью совпадают с новыми операционными системами, поддерживаемыми как гостевые.

3. Новый процесс обновления

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

Как многим уже известно, существует два типа лицензий, которые вы можете использовать с VMware Workstation. Они включают:

• VMware Workstation и Fusion для личного использования

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

• VMware Workstation и Fusion для коммерческого использования

Вам нужно будет пройти процесс регистрации на портале поддержки и использовать процесс создания профиля с идентификатором сайта для загрузки коммерческих сборок. Для этого в строке поиска нужно будет вбить "vmware workstation":

Больше подробностей о VMware Workstation 17.6 Pro можно узнать в Release Notes.

В рамках прошедшей недавно конференции VMware Explore 2024 компания Broadcom объявила о появлении нового трека сертификации для специалистов VCP (VMware Certified Professional) с названием VMware Cloud Foundation Administrator 2024.

Сертификация VMware Certified Professional - VMware Cloud Foundation Administrator (VCP-VCF Admin) 2024 подтверждает навыки, необходимые для развертывания, управления и поддержки частных облачных сред, построенных на VMware Cloud Foundation (VCF).

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

Для получения сертификации нужно сдать экзамен VMware Cloud Foundation 5.2 Administrator (2V0-11.24), руководство по которому находится тут.

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

На прошедшей недавно конференции VMware Explore 2024 компания Broadcom объявила о новом минорном релизе VMware Edge Compute Stack 3.6 (ECS), который наделен мощными функциями, разработанными для улучшения опыта работы с периферийными вычислениями. Следуя за выпуском ECS 3.5 с возможностями оркестрации, этот релиз ECS 3.6 сосредоточен на том, чтобы сделать развертывания еще проще и эффективнее, обеспечивая более доступное и легкое управление вашей периферийной инфраструктурой.

VMware Edge Compute Stack — это комплексное решение для управления и оркестрации вычислительных ресурсов на периферии сети (Edge), обеспечивающее безопасность, управляемость и производительность в распределённых вычислительных средах. Оно предназначено для компаний, которые разворачивают приложения и сервисы на различных объектах, таких как розничные точки, заводы, удалённые офисы и IoT-устройства.

Основные компоненты и возможности решения:

1. Управление периферийными устройствами: VMware Edge Compute Stack включает в себя средства централизованного управления, которые позволяют ИТ-администраторам развертывать, управлять и обновлять приложения на периферийных узлах из одного интерфейса. Это снижает сложность управления распределённой инфраструктурой.

2. Унифицированная платформа: решение объединяет программное и аппаратное обеспечение в единую платформу, обеспечивая поддержку широкого спектра приложений и сервисов. Оно поддерживает работу как с традиционными, так и с более современными контейнерными приложениями.

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

4. Высокая производительность и низкие задержки: VMware Edge Compute Stack оптимизирован для работы в условиях низких задержек и высокой производительности, что особенно важно для приложений, требующих мгновенного отклика, таких как системы автоматизации производства или управления транспортом.

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

6. Масштабируемость: VMware Edge Compute Stack может масштабироваться в зависимости от нужд организации, поддерживая как небольшие периферийные узлы, так и крупные развертывания с тысячами устройств.

Ключевые функции в релизе Edge Compute Stack v3.6:

1. Удобный идентификатор хоста

Broadcom продолжает упрощать использование VMware Edge Compute Stack, и получает ценные отзывы о том, что идентификация хостов на периферийных объектах становится затруднительной при масштабировании на несколько сайтов и хостов в этих сайтах. В связи с этим, в новом релизе добавили удобный host identifier, который позволяет присваивать имя вашему хосту при его регистрации. Это позволит легко идентифицировать хост не только через SaaS-сервис ECS, но и в вашем манифесте развертывания (YAML) как nodeSelector.

2. Регистрация через активационный код

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

3. Статические IP-адреса для всех компонентов хоста

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

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

В этом году на VMware Explore 2024 в Лас-Вегасе компания VMware представила новую версию платформы Tanzu Platform 10. Этот новый релиз предназначен для современных предприятий и направлен на трансформацию управления, обеспечения безопасности и оптимизации приложений с улучшенной гибкостью и возможностями мониторинга. Tanzu Platform 10 позволяет выбирать между Cloud Foundry и Kubernetes в качестве среды выполнения, будь то в публичных или частных облаках. Такая гибкость обеспечивает возможность адаптации Tanzu Platform под конкретные нужды вашего бизнеса. Если вы используете Cloud Foundry, теперь вы можете также подключиться и к экосистеме Kubernetes и воспользоваться надежной интеграцией данных, продолжая использовать уникальные функции Cloud Foundry. Вы также получите более глубокую видимость своих систем благодаря улучшенному пользовательскому интерфейсу и усовершенствованиям в области безопасности, циклов развертывания и создания приложений с поддержкой GenAI.

GenAI для Tanzu Platform теперь в публичной бета-версии

Проект, начавшийся на хакатоне на прошлом VMware Explore, вырос в публичную бета-версию GenAI для Tanzu Platform, запущенную в июне. В VMware рады представить еще больше функций и обновлений в последней публичной бета-версии, включая дополнительные возможности для разработчиков, чтобы быстрее и эффективнее создавать приложения в Tanzu Platform для Cloud Foundry.

На волне успеха GenAI в Tanzu Platform компания VMware объявляет о новых возможностях, которые помогут текущим и будущим клиентам Tanzu Platform создавать корпоративные приложения с поддержкой GenAI. VMware Tanzu AI Solutions — это революционный набор возможностей, доступных в Tanzu Platform, который поддерживает организации в ускорении и масштабировании безопасной поставки интеллектуальных приложений.

Последние функции, доступные в публичной бета-версии, включают:

• Поддержку VMware vSphere, Google Cloud Platform, AWS и Azure
• Безопасный и приватный доступ к совместимому с OpenAI API через Tanzu AI Server
• Брокер для моделей, работающих на VMware Private AI Foundation и моделях сторонних поставщиков
• Развертывание частных больших языковых моделей (LLM) через BOSH в вашей инфраструктуре Tanzu Platform для Cloud Foundry
• Поддержка открытых моделей через vLLM и Ollama, а также поддержка доступа к приватным или ограниченным репозиториям Hugging Face
• Поддержка Nvidia GPU (vGPU и режим pass-through) и Intel Xeon CPU (производительность может варьироваться в зависимости от модели и поколения процессора)

Мультиинфраструктурная видимость теперь доступна в Tanzu Platform для Cloud Foundry

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

В последнем релизе Tanzu Platform 10 теперь поддерживаются мультиинфраструктурные представления и улучшенная видимость Tanzu Platform для Cloud Foundry, что позволяет инженерам платформ видеть все свои системы и компоненты в одном месте. Это упрощает устранение проблем со "здоровьем приложений" во всех развертываниях Cloud Foundry, включая дополнительные возможности для встраивания проверок здоровья в Tanzu Platform.

Интерфейс Tanzu Platform hub, который объединяет инфраструктуры в едином представлении:

Функции, которые будут доступны в Tanzu Platform for Cloud Foundry 10, включают:

• Просмотр всех платформ (Multi-foundation view): Tanzu Platform предоставляет возможность видеть все ваши платформы в одном консолидированном представлении. Это объединение упрощает управление приложениями на различных платформах, предлагая более четкую картину всей вашей экосистемы.
• Снижение затрат (Cost Savings): Используя интегрированное представление центра Tanzu Platform, команды платформ могут сэкономить деньги за счет сокращения потребности в сторонних продуктах. Эта интеграция не только снижает затраты, но и упрощает операции, повышая эффективность и контроль вашего бизнеса.
• Метрики в одном представлении (At-a-glance metrics): Интуитивно понятная панель управления Tanzu Platform предлагает простые метрики для всех платформ. Эта функция позволяет быстро оценить состояние всей вашей среды Cloud Foundry, включая количество приложений и сервисов, работающих на каждой платформе. Этот всеобъемлющий обзор обеспечивает своевременное выявление и устранение проблем.

Посмотрите демонстрацию работы Tanzu Platform в действии в этом эпизоде подкаста Cloud Foundry Weekly.

Прозрачность безопасности

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

Теперь в Tanzu Platform 10 клиенты могут анализировать список компонентов программного обеспечения (SBOM) своих приложений, чтобы выявлять устаревшие библиотеки и быстро предоставлять разработчикам информацию о том, какие действия необходимо предпринять для обновления кода приложения. Это также позволяет инженерам платформ поддерживать актуальность библиотек и обеспечивать непрерывные обновления платформы для снижения рисков безопасности.

Быстрее циклы развертывания с улучшенными возможностями для разработчиков

В основе работы VMware с сообществом лежит поддержка разработчиков. Tanzu Platform 10 представляет улучшенные возможности для разработчиков, предлагая надежные инструменты и интеграции, которые упрощают процесс разработки.

В Tanzu Platform 10 канареечные и прокатные развертывания помогут клиентам улучшить опыт развертывания, повысить продуктивность и ускорить циклы развертывания. Канареечные развертывания позволяют тестировать новую сборку на небольшом объеме пользователей, сохраняя старую сборку для большей части трафика.

Клиенты также могут оценить улучшения в автоматическом масштабировании приложений благодаря переработанной архитектуре CF CLI. Автоматическое масштабирование приложений можно применять к еще большему количеству приложений для увеличения времени запуска и улучшения общей устойчивости приложений.

Непрерывные обновления, сертификации и улучшения платформы

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

Также дополнительные сведения о VMware Tanzu Platform 10 вы можете узнать тут и тут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Чтобы облегчить этот переход и предоставить больше гибкости, недавно было объявлено о продлении периода общей поддержки VMware vSphere 7.x.

Изначально vSphere 7.x должна была достичь окончания общей поддержки 2 апреля 2025 года. С этим объявлением общий период поддержки был продлен до 2 октября 2025 года.

Продление этой поддержки будет осуществляться с учетом следующих условий:

• В течение периода продленной общей поддержки Broadcom будет стремиться решать любые критические уязвимости в исходном коде, которые могут быть обнаружены. Однако возможность обновления компонентов с открытым исходным кодом, включая обновление до более новой версии пакета, зависит от различных факторов, включая, но не ограничиваясь доступностью патча в upstream и поддержкой версии пакета его разработчиками.
• Broadcom не гарантирует, что будут выпущены обновления для всех выявленных уязвимостей в исходном коде. Broadcom оставляет за собой право не включать исправления ошибок, уязвимостей безопасности или любое другое обслуживание компонентов с открытым исходным кодом, даже если они доступны в upstream.
• Последняя поддерживаемая версия Kubernetes на VCF 4.x (vCenter 7.x) будет минорной версией 1.28. Клиентам, использующим панель управления vSphere IaaS, следует планировать переход на vCenter 8.x до окончания общей поддержки Kubernetes v1.28 28 мая 2025 года. Начиная с vCenter 8.0 Update 3, служба TKG может быть обновлена независимо для поддержки новых версий Kubernetes.
• В vSphere 7.x включен встроенный реестр Harbor, который можно активировать на Supervisor кластере для хранения и обмена образами контейнеров. Поддержка этого встроенного реестра Harbor на vSphere 7.x не будет продлена в период продленной общей поддержки. Клиенты, использующие встроенный реестр Harbor, могут выбрать один из следующих вариантов:
  • Рассмотреть возможность миграции на внешний частный реестр контейнеров на продленный период.
  • Обновиться до последней версии vSphere 8.x и перейти на использование службы Harbor Supervisor.