В современной динамично развивающейся сфере информационных технологий автоматизация уже не роскошь, а необходимость. Команды, отвечающие за безопасность, сталкиваются с растущей сложностью управления политиками сетевой безопасности, что требует эффективных и автоматизированных решений. Межсетевой экран vDefend, интегрированный с VMware NSX, предлагает мощные возможности автоматизации с использованием различных инструментов и языков сценариев. Выпущенное недавно руководство "Beginners Guide to Automation with vDefend Firewall" рассматривает стратегии автоматизации, доступные в vDefend, которые помогают ИТ-специалистам упростить рабочие процессы и повысить эффективность обеспечения безопасности.

Понимание операций CRUD в сетевой автоматизации

Операции CRUD (Create, Read, Update, Delete) являются основой рабочих процессов автоматизации. vDefend позволяет выполнять эти операции через RESTful API-методы:

• GET — получение информации о ресурсе.
• POST — создание нового ресурса.
• PUT/PATCH — обновление существующих ресурсов.
• DELETE — удаление ресурса.

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

Стратегии автоматизации для межсетевого экрана vDefend

С vDefend можно использовать несколько инструментов автоматизации, каждый из которых предлагает уникальные преимущества:

1. Вызовы REST API через NSX Policy API - API политики NSX Manager позволяют напрямую выполнять действия CRUD с сетевыми ресурсами. Разработчики могут использовать языки программирования, такие как Python, GoLang и JavaScript, для написания сценариев взаимодействия с NSX Manager, обеспечивая бесшовную автоматизацию задач безопасности.

2. Terraform и OpenTofu - эти инструменты «инфраструктура-как-код» (IaC) помогают стандартизировать развертывание сетей и политик безопасности. Используя декларативные манифесты, организации могут определять балансировщики нагрузки, правила межсетевого экрана и политики безопасности, которые могут контролироваться версионно и развертываться через CI/CD-конвейеры.

3. Ansible - этот инструмент часто применяется для развертывания основных компонентов NSX, включая NSX Manager, Edge и транспортные узлы. ИТ-команды могут интегрировать Ansible с Terraform для полной автоматизации конфигурации сети.

4. PowerCLI — это модуль PowerShell для VMware, который позволяет администраторам эффективно автоматизировать конфигурации межсетевых экранов и политик сетевой безопасности.

5. Aria Automation Suite - платформа Aria обеспечивает оркестрацию задач сетевой безопасности корпоративного уровня. Она включает:

• Aria Assembler — разработка и развертывание облачных шаблонов для настройки безопасности.
• Aria Orchestrator — автоматизация сложных рабочих процессов для управления безопасностью NSX.
• Aria Service Broker — портал самообслуживания для автоматизации сетевых и защитных операций.

Ключевые основы работы с API

Для эффективного использования возможностей автоматизации vDefend важно понимать архитектуру его API:

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

Пример полномасштабной автоматизации

Реальный сценарий автоматизации с использованием vDefend включает:

• Сбор информации о виртуальных машинах — идентификацию ВМ и получение тегов безопасности.
• Присвоение тегов ВМ — назначение меток для категоризации ресурсов.
• Создание групп — динамическое формирование групп безопасности на основе тегов ВМ.
• Определение пользовательских служб — создание пользовательских сервисов межсетевого экрана с конкретными требованиями к портам.
• Создание политик и правил межсетевого экрана — автоматизация развертывания политик для применения мер безопасности.

Например, автоматизированное правило межсетевого экрана для разрешения HTTPS-трафика от группы веб-серверов к группе приложений будет выглядеть следующим образом в формате JSON:

{
  "action": "ALLOW",
  "source_groups": ["/infra/domains/default/groups/WebGroup"],
  "destination_groups": ["/infra/domains/default/groups/AppGroup"],
  "services": ["/infra/services/HTTPS"],
  "scope": ["/infra/domains/default/groups/WebGroup"]
}

С момента объявления о том, что VMware Fusion и VMware Workstation стали доступными бесплатно с 11 ноября 2024 года, команда инженеров VMware получила положительный отклик от пользователей в коммерческом, образовательном и личном секторах. Благодаря этому изменению пользователи теперь могут бесплатно использовать эти инструменты виртуализации для настольных платформ.

Положительный отклик клиентов и обратная связь

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

Однако надо напомнить, что пользователи бесплатных версий VMware Fusion и VMware Workstation НЕ ИМЕЮТ ПРАВА НА ПОДДЕРЖКУ ЧЕРЕЗ ГЛОБАЛЬНУЮ СЛУЖБУ ПОДДЕРЖКИ. Компания Broadcom призывает всех пользователей продолжать предоставлять обратную связь, публикуя свои вопросы, замечания и проблемы на различных порталах сообщества (Fusion и Workstation), которые лучше всего подходят для получения ответов на такие вопросы.

Улучшение поддержки с помощью доступных ресурсов

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

Вот что сейчас доступно:

• Обновленные рекомендации по запросам в службу поддержки: VMware создала новую статью в базе знаний, в которой освещены наиболее распространенные вопросы и проблемы, с которыми сталкиваются пользователи при начальном освоении VMware Desktop Hypervisor. В статье представлено краткое описание этих проблем и их решений. Ознакомиться с материалом можно здесь.
• Пошаговое руководство по установке: VMware подготовила подробное руководство по загрузке и установке VMware Desktop Hypervisor. Оно включает полезные ссылки и скриншоты всего процесса, чтобы вы могли быстро начать работу. Доступ к руководству можно получить здесь.
• Обновленные ссылки для загрузки и руководство по установке: VMware обновила ссылки для скачивания VMware Desktop Hypervisor. Актуальные версии VMware Fusion и Workstation теперь можно скачать здесь.
• Расширенная база знаний: VMware пополнила базу знаний новыми статьями и решениями, охватывающими дополнительные сценарии устранения неполадок, расширенные функции и советы по настройке. Независимо от того, являетесь ли вы новым пользователем или опытным специалистом, эти ресурсы помогут вам быстро найти ответы.
• Дополнительные обучающие материалы и руководства: чтобы упростить освоение и эффективное использование VMware Fusion и Workstation, VMware добавила новые пошаговые руководства (Workstation и Fusion). В них рассматриваются вопросы от базовой установки до продвинутых настроек, предлагая практические решения для повседневного использования.
• Доступ к сообществу: пользовательское сообщество остается ценным пространством для обмена советами, решениями и опытом. VMware наблюдает рост активности на форумах, где пользователи помогают друг другу решать проблемы и делятся лучшими практиками. В компании приглашают вас присоединиться к обсуждениям и внести свой вклад:
  • Workstation Community
  • Fusion Community

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

Переход на бесплатную модель – лишь один из шагов в продолжающихся усилиях по удовлетворению потребностей пользователей. VMware продолжает совершенствовать пользовательский опыт, улучшая и расширяя предложения, чтобы VMware Fusion и Workstation оставались ценными инструментами. Чтобы узнать больше о платформах VMware Desktop Hypervisors и получить дополнительные ресурсы, посетите страницу продуктов и раздел FAQ.

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

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

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

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

Если логи вашего vCenter переполнены сообщениями ApiGwServicePrincipal об истечении срока действия токенов, вы не одиноки. Частые записи уровня «info» в файле apigw.log могут засорять вашу систему, затрудняя выявление реальных проблем. К счастью, есть простое решение: измените уровень логирования с «info» на «error». Автор блога cosmin.us подробно рассказал, как именно можно эффективно уменьшить количество этих лишних записей в журнале.

Со стороны сервера VMware vCenter в логе вы можете увидеть записи следующего вида:

The token with id '_9eb499f7-5f0e-4b83-9149-e64ae5bbf202' for domain vsphere.local(9d121150-d80b-4dbe-8f8a-0254435cf32a) is unusable (EXPIRED). Will acquire a fresh one.

Эти сообщения появляются потому, что по умолчанию для файла apigw.log установлен уровень логирования «info». В результате регистрируется каждое истечение срока действия и обновление токена — обычный процесс, который не требует постоянного внимания. Итог — перегруженные журналы и возможное снижение производительности. Изменив уровень логирования на «error», вы сможете ограничить записи в журналах только критически важными проблемами.

Внимательно следуйте данным инструкциям, чтобы изменить уровень логирования для apigw.log. Этот процесс применим как к отдельным серверам vCenter, так и к серверам в режиме Enhanced Linked Mode.

1. Создание снапшота сервера vCenter

   Перед внесением изменений защитите свою среду, создав снапшот vCenter. Если ваши серверы vCenter работают в режиме Enhanced Linked Mode, используйте оффлайн-снапшоты для обеспечения согласованности всех узлов. Этот снимок послужит вариантом отката, если что-то пойдёт не так.

2. Резервное копирование оригинального конфигурационного файла

   Войдите на устройство vCenter Server Appliance (VCSA) по SSH с правами root. Выполните следующую команду для резервного копирования файла vmware-services-vsphere-ui.conf:

cp /etc/vmware-syslog/vmware-services-vsphere-ui.conf /etc/vmware-syslog/vmware-services-vsphere-ui.conf.backup

Это создаст резервную копию (vmware-services-vsphere-ui.conf.backup), к которой можно вернуться при необходимости.

3. Редактирование конфигурационного файла логирования
   
   Откройте конфигурационный файл с помощью редактора vi:

vi /etc/vmware-syslog/vmware-services-vsphere-ui.conf

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

#vsphere-ui apigw log input(type="imfile" File="/var/log/vmware/vsphere-ui/logs/apigw.log" Tag="ui-apigw" Severity="info" Facility="local0")

Измените «info» на «error», чтобы получилось:

#vsphere-ui apigw log input(type="imfile" File="/var/log/vmware/vsphere-ui/logs/apigw.log" Tag="ui-apigw" Severity="Error" Facility="local0")

Теперь vCenter будет записывать в apigw.log только ошибки.

4. Сохранение изменений и выход из редактора

   Нажмите Esc, чтобы выйти из режима вставки. Введите :wq! и нажмите Enter, чтобы сохранить изменения и закрыть редактор.

5. Перезапуск сервисов vCenter

   Чтобы изменения вступили в силу, перезапустите службы vsphere-ui и vmware-stsd следующими командами:

service-control --restart vsphere-ui service-control --restart vmware-stsd

Перезапуск этих служб активирует новые настройки логирования.

Проверка результата

После перезапуска сервисов убедитесь, что избыточные сообщения об истечении срока действия токенов прекратились. Теперь при уровне логирования «error» будут появляться только критические проблемы, делая ваши журналы более понятными и полезными.

Недавно было объявлено о доступности VMware vSphere Kubernetes Service (VKS) 3.3 (ранее известного как решение VMware Tanzu Kubernetes Grid (TKG) Service), а также о выпуске vSphere Kubernetes release (VKr) 1.32, ранее называвшегося Tanzu Kubernetes release. В этом выпуске представлены важные функции и улучшения, направленные на повышение безопасности, масштабируемости и управления кластерами.

Поддержка актуального релиза Kubernetes 1.32

С выпуском VKS 3.3 теперь возможно развертывание рабочих кластеров на базе VKr 1.32, основанного на последнем минорном выпуске Kubernetes 1.32. Использование последних версий Kubernetes обеспечивает безопасность, высокую производительность и совместимость с современными приложениями. vSphere Kubernetes release 1.32 обеспечивает повышение эффективности, безопасности и гибкости рабочих нагрузок.

Гибкость активации режима FIPS на уровне ОС

Данный выпуск вводит новую возможность настройки режима FIPS на уровне операционной системы, гарантируя использование только одобренных FIPS криптографических модулей. Администраторы могут самостоятельно решить, активировать ли режим FIPS для кластеров на Linux и Windows. Для активации функции необходимо настроить переменную класса кластера 'osConfiguration'. Для включения данной функции в Ubuntu-версии vSphere Kubernetes может потребоваться подписка Ubuntu Pro. Подробная информация представлена в документации.

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

Переход на Cluster API

Как было объявлено в документации к выпуску VKS 3.2, API TanzuKubernetesCluster будет удалён не ранее июня 2025 года. VKS 3.3 вводит упрощённый механизм миграции кластеров с TKC на Cluster API для развертывания и настройки рабочих кластеров. Переход на Cluster API обеспечивает лучшую автоматизацию и будущую совместимость. Рекомендуется заранее планировать переход на Cluster API, чтобы избежать сбоев после удаления TKC API.

Другие важные улучшения

• Интеграция узлов Windows с Active Directory (поддержка gMSA) – начиная с VKS 3.3, вы можете подключать узлы Windows к локальной службе Active Directory с использованием учётных записей группового управления (Group Managed Service Accounts, gMSA) для безопасной аутентификации. Можно автоматизировать подключение узлов Windows к домену Active Directory в организационных подразделениях и добавлять их в группу безопасности, управляющую доступом к gMSA. Это упрощает интеграцию рабочих нагрузок Kubernetes на базе Windows в предприятиях, использующих Active Directory, повышая безопасность и операционную эффективность. Подробности можно найти в документации.

• Автомасштабирование кластеров в обе стороны – VKS 3.3 позволяет масштабировать кластеры от нуля до любого количества рабочих узлов при использовании VKr версии 1.31.4 и новее. Ранее эта функция была недоступна со времен появления Cluster Autoscaler в vSphere 8.0 U3. Также это способствует экономии средств и оптимизации ресурсов, позволяя динамически масштабировать рабочие нагрузки до нуля в неиспользуемый период и эффективно справляться с сезонными всплесками активности.
• Механизмы для упрощения обновления (Guard Rails) - обновления через несколько версий могут быть затруднены, особенно с устаревшими ресурсами. В версии VKr 1.31.1 в Antrea 2.1 некоторые CRD были объявлены устаревшими и должны быть заменены на новые версии.
  • Обновление до VKr 1.31.1 – перед обновлением обязательно выполнить минимальные ручные инструкции, указанные в Release Notes 1.31.1, иначе обновление может завершиться неудачно.
  • Обновление до VKr 1.31.4 – При обновлении до версии VKr 1.31.4 устаревшие CRD Antrea автоматически заменяются новыми версиями, поэтому ручные действия не требуются.
• В VKS 3.3 встроены механизмы защиты от потенциальных ошибок при обновлении. Если рабочий кластер использует Kubernetes версии 1.30.x и обновлен до VKS 3.3, обновление до Kubernetes версии 1.31.1 заблокировано. Вместо этого рекомендуется сразу перейти на версию 1.31.4, которая не требует ручных действий. Если рабочий кластер уже на версии VKr 1.31.1, то обновление до VKS 3.3 заблокировано до предварительного обновления до VKr 1.31.4.

Заключение

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

Документ Network Observability Maturity Model от компании Broadcom представляет собой руководство по достижению высокого уровня наблюдаемости (observability) сетей, что позволяет ИТ-командам эффективно управлять современными сложными сетевыми инфраструктурами.

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

Основные вызовы в управлении сетями

1. Растущая сложность – 78% компаний отмечают, что управление сетями стало значительно сложнее из-за многообразия технологий и распределенных архитектур.
2. Удаленная работа – 95% компаний используют гибридный режим работы, что усложняет контроль за производительностью сетей, зависящих от домашних Wi-Fi и внешних провайдеров.
3. Облачные технологии – 98% организаций уже используют облачную инфраструктуру, что приводит к недостатку прозрачности в управлении данными и сетевым трафиком.
4. Зависимость от сторонних сервисов – 65% компаний передают часть сетевого управления сторонним поставщикам, что затрудняет полное наблюдение за сетью.
5. Рост потребности в пропускной способности – развитие AI и других технологий увеличивает нагрузку на сети, требуя более эффективных стратегий управления трафиком.
6. Устаревшие инструменты – 80% компаний считают, что традиционные средства мониторинга не обеспечивают должного уровня видимости сети.

Последствия недостаточной наблюдаемости

• Проблемы с диагностикой – 76% сетевых команд испытывают задержки из-за недостатка данных.
• Реактивный подход – 84% компаний узнают о проблемах от пользователей, а не от систем мониторинга.
• Избыточные тревоги – 41% организаций сталкиваются с ложными срабатываниями, что увеличивает время поиска неисправностей.
• Сложности с наймом специалистов – 48% компаний не могут найти специалистов с нужными навыками.

Ключевые требования для построения наблюдаемости сети

1. Видимость внешних сред – важна мониторинговая прозрачность не только для внутренних сетей, но и для облаков и провайдеров.
2. Интеллектуальный анализ данных – использование алгоритмов для корреляции событий, подавления ложных тревог и прогнозирования отказов.
3. Активный мониторинг – симуляция сетевого трафика позволяет выявлять узкие места в режиме реального времени.
4. Автоматизация и интеграция – объединение разрозненных инструментов в единую систему с автоматическими рекомендациями по устранению неполадок.

Модель зрелости наблюдаемости сети

Модель зрелости состоит из пяти уровней:

1. Ручной уровень – разрозненные инструменты, долгие поиски неисправностей.
2. Традиционный уровень – базовое объединение инструментов, но с разрывами между данными.
3. Современный уровень – использование активного мониторинга и потоковой телеметрии.
4. Следующее поколение – автоматизированные решения на основе AI/ML, минимизация ложных тревог.
5. Самообслуживание и самовосстановление – автоматическая коррекция сетевых аномалий без вмешательства человека.

Практическая реализация модели

Для внедрения зрелой системы наблюдаемости компании должны:

• Создать единую модель данных для многовендорных сетей.
• Инвестировать в решения с AI-аналитикой.
• Использовать активное и потоковое наблюдение за сетью.
• Интегрировать мониторинг как внутренних, так и внешних сетей.

Документ Network Observability Maturity Model подчеркивает важность перехода от традиционного мониторинга к интеллектуальной наблюдаемости сети. Автоматизация, AI-аналитика и активный мониторинг позволяют существенно сократить время диагностики проблем, снизить издержки и повысить надежность сетевых сервисов. В документе даны полезные рекомендации по развитию мониторинговых систем, обеспечивающих полную прозрачность работы сети и снижение нагрузки на ИТ-отделы.

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

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

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

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

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

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

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

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

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

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

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

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

$roles = Get-VIRole
$permissions = Get-VIPermission

$results = @{}
foreach ($permission in $permissions) {
    $role = $permission.Role
    if($results.ContainsKey($role)) {
        $results[$role]+=1
    } else {
        $results[$role]=1
    }
}

Write-Host "`nTotal Roles: $($roles.count)"
Write-Host "Total Roles Used: $($results.count)"
Write-Host "Role Usage:"

$results.GetEnumerator() | Sort-Object -Property Value -Descending

$outfile = "used-roles.txt"
foreach ($key in $results.keys) {
    $role = Get-VIRole $key
    if(!$role.IsSystem) {
        $key | Out-File -Append -LiteralPath $outfile
        "=========================================================" | Out-File -Append -FilePath $outfile
        $role.ExtensionData.Privilege | Out-File -Append -LiteralPath $outfile
        "" | Out-File -Append -LiteralPath $outfile
    }
}

Вот пример выполнения сценария:

А вот пример вывода из файла used-roles.txt, который генерируется и содержит список привилегий для каждой используемой роли:

Недавно Дункану Эппингу задали вопрос о том, сколько памяти должна иметь конфигурация AF-4 ReadyNode, чтобы она поддерживалась. Понтяно, откуда возник этот вопрос, но большинство людей не осознают, что существует набор минимальных требований, а профили ReadyNode, как указано в базе знаний (KB), являются лишь рекомендациями. Перечисленные конфигурации – это ориентир. Эти рекомендации основаны на предполагаемом потреблении ресурсов для определенного набора виртуальных машин. Конечно, для вашей нагрузки требования могут быть совершенно другими. Именно поэтому в статье, описывающей аппаратные рекомендации, теперь четко указано следующее:

Чтобы конфигурация поддерживалась службой глобальной поддержки VMware Global Services (GS), все сертифицированные для vSAN ESA ReadyNode должны соответствовать или превышать ресурсы самой минимальной конфигурации (vSAN-ESA-AF-0 для vSAN HCI или vSAN-Max-XS для vSAN Max).

Это относится не только к объему памяти, но и к другим компонентам, при условии соблюдения минимальных требований, перечисленных в таблице ниже (учтите, что это требования для архитектуры ESA, для OSA они другие):

С выходом TKG Service 3.2.0 в октябре 2024 года VMware объявила об устаревании API Tanzu Kubernetes Cluster (TKC), направляя клиентов на использование Cluster API в качестве поддерживаемого метода для инициализации, настройки и управления кластерами Kubernetes. Ниже описан процесс отказа от использования API TKC в пользу более современной методологии на основе Cluster API.

Далее термины "TKG Service", "TKGS" и "vSphere Kubernetes Service" (VKS) используются взаимозаменяемо. VMware проводит небольшую ребрендинг-кампанию, и в будущих выпусках вы начнете замечать обновленный брендинг.

API TanzuKubernetesCluster долгое время был полезным инструментом для управления кластерами Kubernetes, но по мере развития экосистемы Cluster API стал предлагать более зрелый, функциональный и управляемый по версиям подход к управлению жизненным циклом кластеров. Этот переход гарантирует клиентам стандартизацию, большую гибкость и долгосрочную поддержку. Однако в VMware понимают, что у многих пользователей уже развернуты кластеры, созданные с помощью API Tanzu Kubernetes Cluster. Это создает определенные сложности: необходимо обеспечить возможность корректного отказа от TKC-ресурсов без нарушения существующих рабочих процессов. Общий план по обновлению включает три ключевых этапа:

Начиная с TKG Service 3.2.0, пользователи, работающие с ресурсами TKC, получают предупреждения об устаревании и рекомендации по переходу на Cluster API.

С выпуском TKG Service 3.3.0 был представлен упрощенный процесс вывода ресурсов TKC для существующих кластеров, при этом управление ими продолжается через Cluster API. Подробное описание этого процесса приведено ниже.

В одном из будущих выпусков поддержка API TKC будет полностью прекращена. К этому моменту пользователи должны будут вывести из эксплуатации все ресурсы TKC перед обновлением до новых версий TKG Service/VKS.

Обзор процесса вывода из эксплуатации

Этот процесс позволяет корректно удалить ресурсы TKC, при этом кластеры остаются полностью работоспособными и управляемыми через ресурс Cluster в Cluster API.

При применении метки kubernetes.vmware.com/retire-tkc к кластеру TKC:

• Если кластер соответствует предварительным условиям вывода из эксплуатации, ресурс TKC удаляется, а управление кластером полностью переходит на его ресурс Cluster.
• Если условия не выполнены, валидация заблокирует процесс вывода, и вам будут предоставлены подробные сведения об ошибках, которые помогут устранить проблемы.

Примечание: вывод ресурса TKC из эксплуатации не влияет на сам кластер или его узлы и не вызывает поэтапного обновления (rolling update).

Начало работы

Перед началом убедитесь, что ваш кластер не работает на устаревшей версии Kubernetes. Устаревшие версии совместимы только с vSphere 7.x (и 8.x для обновления) и должны быть обновлены до поддерживаемой версии Kubernetes перед выводом из эксплуатации. Используйте шаги проверки совместимости кластера, чтобы определить и обновить устаревшие версии.

Также убедитесь, что в кластере нет активных обновлений, и что он находится в стабильном состоянии. Важно об управлении через TMC: на данный момент кластеры, управляемые Tanzu Mission Control (TMC), не могут быть выведены из эксплуатации. Эта функциональность пока не поддерживается.

Шаги

Подробное руководство по процессу вывода из эксплуатации можно найти в официальной документации в разделе Retiring Tanzu Kubernetes Cluster resources.

Добавьте метку к ресурсу TKC для кластера, который вы хотите вывести из эксплуатации:

kubectl label tanzukubernetescluster/<cluster-name> kubernetes.vmware.com/retire-tkc="" 

После применения метки webhook выполняется ряд автоматизированных проверок. В частности, проверяются следующие условия:

• Неустаревшая версия Kubernetes: кластер должен работать на поддерживаемой версии Kubernetes (не может быть переопределено).
• Существующий ресурс Cluster: должен существовать соответствующий ресурс Cluster, находящийся в состоянии Ready (можно переопределить — см. документацию).
• Нет активных обновлений: в кластере не должно выполняться обновление (можно переопределить, если версии Kubernetes совпадают).
• Нет других миграций: кластеры, находящиеся в процессе миграции, не могут быть выведены из эксплуатации (не может быть переопределено).
• Кластер не управляется TMC: кластеры, управляемые Tanzu Mission Control, не могут быть выведены из эксплуатации (не может быть переопределено).

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

Чтобы отслеживать процесс вывода из эксплуатации, используйте команду:

После запуска процесса вывода вы увидите обновления через события:

• RetirementTriggered – событие публикуется при запуске процесса.
• RetirementDone – событие публикуется при удалении ресурса TKC.

Остановка процесса при необходимости

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

Результат

При успешном завершении процесса:

• Старый ресурс API TKC будет удален.
• Кластер продолжит работать без перебоев и будет полностью управляться через ресурс Cluster.
• Все операции жизненного цикла, включая обновления и масштабирование, будут выполняться через Cluster API.

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

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

Например:

• Тестирование сценариев отказоустойчивости сети.
• Определение и изоляция сетевых проблем за счет отключения подозрительного неисправного сетевого адаптера (NIC).
• Временное отключение сетевого адаптера (NIC), чтобы оценить влияние на производительность сети и проверить эффективность балансировки нагрузки.
• Проверка того, как виртуальные машины реагируют на отказ определенного сетевого пути.
• Отключение vmnic, который подключен к ненадежному VLAN или неправильно настроенной сети.
• Тестирование различных сетевых конфигураций без внесения постоянных изменений в физические соединения.

Итак, чтобы отключить vmnic, нужно зайти на ESXi по SSH и выполнить там следующую команду, чтобы вывести список сетевых адаптеров:

esxcli network nic list

Далее отключаем vmnic командой (X - это номер в имени адаптера):

esxcli network nic down -n vmnicX

В разделе физических адаптеров vSphere Client мы увидим следующую картину (адаптер в статусе "down"):

Чтобы вернуть vmnic в исходное состояние, просто выполняем команду:

esxcli network nic up -n vmnicX

Источник.

В январе 2025 года компания VMware опубликовала технический документ под названием «Performance Tuning for Latency-Sensitive Workloads: VMware vSphere 8». Этот документ предоставляет рекомендации по оптимизации производительности для рабочих нагрузок, критичных к задержкам, в среде VMware vSphere 8.

Документ охватывает различные аспекты конфигурации, включая требования к базовой инфраструктуре, настройки хоста, виртуальных машин, сетевые аспекты, а также оптимизацию операционной системы и приложений. В разделе «Host considerations» обсуждаются такие темы, как изменение настроек BIOS на физическом сервере, отключение EVC, управление vMotion и DRS, а также настройка продвинутых параметров, таких как отключение action affinity и открытие кольцевых буферов.

В разделе «VM considerations» рассматриваются рекомендации по оптимальному выделению ресурсов виртуальным машинам, использованию актуальных версий виртуального оборудования, настройке vTopology, отключению функции hot-add, активации параметра чувствительности к задержкам для каждой ВМ, а также использовании сетевого адаптера VMXNET3. Кроме того, обсуждается балансировка потоков передачи и приема данных, привязка потоков передачи к определенным ядрам, ассоциация ВМ с конкретными NUMA-нодами и использование технологий SR-IOV или DirectPath I/O при необходимости.

Раздел о сетевых настройках акцентирует внимание на использовании улучшенного пути передачи данных для NFV-нагрузок и разгрузке сервисов vSphere на DPU (Data Processing Units), также известных как SmartNICs.

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

Компания VMware представила новый документ "Simplify Storage with VMware vSAN".

Он представляет собой презентацию, в которой подробно рассматриваются три основных способа упрощения управления хранилищами данных с помощью VMware vSAN:

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

2. Упрощение управления жизненным циклом хранилища: традиционные системы хранения часто требуют сложного и трудоемкого обслуживания. VMware vSAN интегрируется непосредственно в гипервизор vSphere, что позволяет автоматизировать многие процессы, такие как обновление и масштабирование, значительно снижая операционные затраты и облегчая сопровождение инфраструктуры.

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

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

Один из клиентов VMware недавно обратился к Вильяму Ламу с вопросом о том, как можно легко провести аудит всей своей инфраструктуры серверов VMware ESXi, чтобы определить, какие хосты всё ещё загружаются с использованием устаревшей прошивки BIOS, которая будет удалена в будущих выпусках vSphere и заменена на стандартную для индустрии прошивку типа UEFI.

В vSphere 8.0 Update 2 было введено новое свойство API vSphere под названием firmwareType, которое было добавлено в объект информации о BIOS оборудования ESXi, что значительно упрощает получение этой информации с помощью следующей однострочной команды PowerCLI:

(Get-VMHost).ExtensionData.Hardware.BiosInfo

Пример ее вывода для сервера ESXi при использовании UEFI выглядит вот так:

Если же используется устаревший BIOS, то вот так:

Поскольку это свойство vSphere API было недавно введено в vSphere 8.0 Update 2, если вы попытаетесь использовать его на хосте ESXi до версии 8.0 Update 2, то это поле будет пустым, если вы используете более новую версию PowerCLI, которая распознаёт это свойство. Или же оно просто не отобразится, если вы используете более старую версию PowerCLI.

В качестве альтернативы, если вам всё же необходимо получить эту информацию, вы можете подключиться напрямую к хосту ESXi через SSH. Это не самый удобный вариант, но вы можете использовать следующую команду VSISH для получения этих данных:

vsish -e get /hardware/firmwareType

Группы пользователей VMware (VMware User Groups, VMUG) – это активные сообщества IT-специалистов, предоставляющие платформу для установления связей, совместной работы и решения проблем. Недавно 453 участника VMUG приняли участие в опросе, чтобы поделиться своим мнением о ключевых вызовах, приоритетах и целях, определяющих их ИТ-стратегии. Ниже будут показаны интересные результаты, опубликованные здесь.

Главные приоритеты для ИТ-специалистов

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

Основные выводы опроса по планируемым на ближайший год ИТ-инициативам :

• Модернизация кибербезопасности (инфраструктуры и практик предотвращения угроз и восстановления после атак): 51% опрошенных назвали это своим главным IT-приоритетом на ближайшие 12–18 месяцев.
• Повышение устойчивости IT-инфраструктуры и улучшение механизмов восстановления после сбоев: 47% участников выделили этот пункт.
• Улучшение операционной эффективности в локальной (on-premises) среде: 42% респондентов отметили важность оптимизации работы своих внутренних систем.

Ключевые возможности, которые ИТ-команды ценят больше всего

Опрос выявил три важнейшие возможности, которые способствуют укреплению IT-операций и достижению успеха:

Рассмотрим их немного детальнее:

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

Преодоление трудностей при модернизации приложений

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

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

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

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

Эволюция кейсов применения генеративного AI

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

Однако в течение следующих 12 месяцев, по данным опросов, наибольший прирост ценности ожидается в областях, требующих большего учета специфики рабочих процессов и внутреннего контекста компании, таких как генерация кода, улучшение клиентского опыта, продвинутый поиск информации и безопасная генерация контента. Еще одной быстро развивающейся сферой является агентный AI (Agentic AI), который, как ожидается, приведет к улучшению процессов оптимизации и автоматизации задач.

Фокус на безопасной генерации контента

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

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

В рамках исследования Voice of the Enterprise: AI & Machine Learning, Use Cases 2025 компании 451 Research (опрошено 1006 компаний) был задан следующий вопрос: "Вашей организацией была приобретена или разработана технология генеративного AI, используемая для создания любого из следующих типов контента?". Вопрос касался исключительно технологий, которые были приобретены или разработаны.

После обработки ответов текущие и планируемые модальности контента GenAI были представлены так:

Одной из распространенных проблем при использовании сотрудниками публичных инструментов генеративного AI или базовых моделей является отсутствие учета специфики организации. Эффективным решением для создания контента, соответствующего корпоративным стилевым требованиям и отражающего идентичность бренда, является тонкая настройка моделей (fine-tuning) в защищенной среде. В сочетании с генерацией, дополненной поиском (retrieval-augmented generation), которая позволяет LLM-моделям использовать и перерабатывать существующие материалы, это помогает компаниям создавать высокорелевантный контент с большей скоростью и частотой, что ведет к росту продуктивности.

Взгляд в будущее

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

Автоматизация поиска ISO-файлов в хранилищах данных VMware vCenter с помощью PowerShell

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

PowerShell — это мощный скриптовый язык, позволяющий системным администраторам автоматизировать задачи и эффективно управлять системами. Его интеграция с VMware PowerCLI дает возможность беспрепятственно взаимодействовать со средами VMware vSphere.

Перед запуском скрипта убедитесь, что у вас установлен модуль VMware.PowerCLI:

VMware.PowerCLI Install-Module -Name VMware.PowerCLI -Scope CurrentUser 

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

1. Подключитесь к серверу vCenter:

Connect-VIServer -Server $vcenterServer -User $vcUser -Password $vcPassword 

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

# Get all datastores

$datastores = Get-Datastore


# Write the header once

Write-Host "Datastore | FilePath | FileName"


foreach ($datastore in $datastores) {

    # Get all .iso files in the datastore

    $isoFiles = Get-ChildItem -Path $datastore.DatastoreBrowserPath -Recurse -Include *.iso


        foreach ($isoFile in $isoFiles) {

        $isoFileDetail = @{

            "Datastore" = $datastore.Name

            "FilePath" = $isoFile.FullName

            "FileName" = $isoFile.Name

        }


        # Output the file details under the header

        Write-Host "$($datastore.Name) | $($isoFile.FullName) | $($isoFile.Name)"

    }

}

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

Ниже приведены скриншоты для справки

Ситуация:

Есть несколько ISO-файлов, расположенных в различных хранилищах данных в vCenter.

Подключаемся к vCenter с использованием командной строки, как описано выше. Теперь, имея PowerShell-скрипт, можно автоматизировать получение тех же данных/результатов. Ниже представлен вывод после выполнения указанного скрипта.

Источник.

Команда инженеров подразделения производительности VMware Cloud Foundation в Broadcom представила обновленный технический документ о лучших практиках производительности тегирования для VMware vCenter 8.0 U3.

В документе описаны улучшения производительности различных API тегирования, которые доступны для vCenter в VMware vSphere Automation SDK. Он содержит примеры кода и обновленные данные о производительности.

По сравнению с выпуском vCenter 7.0 U3, версия 8.0 U3 демонстрирует значительное ускорение работы API привязки тегов:

• attach() – увеличение скорости на 40%.
• attachTagToMultipleObjects() – увеличение скорости на 200%.
• attachMultipleTagsToObject() – увеличение скорости на 31%–36%.

Помимо привязки тегов, в документе представлены данные о запросах виртуальных машин, связанных с тегами, а также об улучшениях работы режима связи нескольких vCenter - Enhanced Linked Mode. vCenter 8.0 U3 поддерживает те же лимиты, что и 7.0 U3, в отношении количества тегов, категорий и привязок тегов, но при этом обеспечивает повышенную производительность.

Ниже представлена диаграмма, демонстрирующая некоторые из достигнутых улучшений. В частности, attachTagToMultipleObjects() показывает увеличение производительности на 200% при привязке 15 тегов к 5000 виртуальным машинам в vCenter 8.0 U3 по сравнению с 7.0 U3.

Наш постоянный читатель Сергей обратил внимание на статью Michael Schroeder о том, куда переехали основные онлайн-ресурсы VMware после интеграции с Broadcom.

1. Техническая документация

C 1 января 2025 года техническая документация сайта docs.vmware.com была перемещена на ресурс techdocs.broadcom.com:

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

2. Максимумы конфигурации

Сайт configmax.vmware.com переехал на ресурс compatibilityguide.broadcom.com. Тут вроде все как прежде, ничего пока не поломали:

3. Списки совместимости оборудования (HCL)

Списки VMware Hardware Compatibility Lists (HCL) теперь располагаются по адресу compatibilityguide.broadcom.com. Тут в принципе выглядит это все неплохо:

4. Технический ресурс VMware Core

Один из самых полезных ресурсов VMware Core (core.vmware.com) компания Broadcom просто прикончила - теперь по этой ссылке редиректит по адресу vmware.com/resources/resource-center. На этом ресурсе теперь хрен что найдешь - раздел поиска неинтуитивен. Сейчас хоть поправили названия продуктов, а то раньше вместо NSX надо было искать в категории "Networking by NSX", а vSAN - в разделе "Storage by vSAN".

5. Ресурс для разработчиков

Сайт code.vmware.com теперь находится по адресу community.broadcom.com/vmware-code/home. Тут тоже выглядит все как-то аляповато, но про детали могут рассказать только сами разработчики:

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

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

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

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

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

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

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

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

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

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

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

Применение:

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

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

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

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

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

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

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

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

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

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

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

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

VMware HCX (Hybrid Cloud Extension)

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

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

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

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

VMware Cloud Foundation (VCF) Import Tool

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

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

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

VMware Live Site Recovery

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

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

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

Некоторое время назад Вильям Лам поделился решением, позволяющим установить VIB-пакет в сборке для Nested ESXi при использовании vSAN Express Storage Architecture (ESA) и VMware Cloud Foundation (VCF), чтобы обойти предварительную проверку на соответствие списку совместимого оборудования vSAN ESA (HCL) для дисков vSAN ESA.

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

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

Вильям быстро переустановил последнюю версию ESXi 8.0 Update 3b на одном из своих физических серверов, установил vSAN ESA Hardware Mock VIB и, используя последнюю версию VCF 5.2.1 Cloud Builder, успешно прошел предварительную проверку vSAN ESA, после чего развертывание началось без проблем!

Отлично, что теперь это решение работает как для физических, так и для вложенных (nested) ESXi при использовании с VCF, особенно для создания демонстрационных сред (Proof-of-Concept)!

Примечание: В интерфейсе Cloud Builder по-прежнему выполняется предварительная проверка физических сетевых адаптеров, чтобы убедиться, что они поддерживают 10GbE или более. Таким образом, хотя проверка совместимости vSAN ESA HCL пройдет успешно, установка все же завершится с ошибкой при использовании UI.

Обходной путь — развернуть домен управления VCF с помощью Cloud Builder API, где проверка на 10GbE будет отображаться как предупреждение, а не как критическая ошибка, что позволит продолжить развертывание. Вы можете использовать этот короткий PowerShell-скрипт для вызова Cloud Builder API, а затем отслеживать процесс развертывания через UI Cloud Builder.

$cloudBuilderIP = "192.168.30.190"
$cloudBuilderUser = "admin"
$cloudBuilderPass = "VMware123!"
$mgmtDomainJson = "vcf50-management-domain-example.json"

#### DO NOT EDIT BEYOND HERE ####

$inputJson = Get-Content -Raw $mgmtDomainJson

$pwd = ConvertTo-SecureString $cloudBuilderPass -AsPlainText -Force
$cred = New-Object Management.Automation.PSCredential ($cloudBuilderUser,$pwd)

$bringupAPIParms = @{
    Uri         = "https://${cloudBuilderIP}/v1/sddcs"
    Method      = 'POST'
    Body        = $inputJson
    ContentType = 'application/json'
    Credential = $cred
}

$bringupAPIReturn = Invoke-RestMethod @bringupAPIParms -SkipCertificateCheck

Write-Host "Open browser to the VMware Cloud Builder UI to monitor deployment progress ..."

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

Количество хостов в кластере

Количество хостов в кластере VMware vSAN напрямую влияет на масштабируемость, производительность и отказоустойчивость. Минимальные требования тут такие:

• Кластер из 2 хостов — минимальная конфигурация, поддерживаемая внешней witness-машиной для обеспечения кворума. Такая настройка является экономичной, но не обладает продвинутыми функциями и масштабируемостью.
• Кластер из 3 хостов — устраняет необходимость в выделенном witness-узле и обеспечивает базовую избыточность с использованием RAID 1.

Несмотря на эти минимальные требования, VMware рекомендует использовать не менее 4 хостов для производственных сред. Кластер из 4 и более хостов позволяет использовать конфигурации RAID 5 и RAID 6, обеспечивая защиту до двух отказов одновременно (в этом случае потребуется больше 4 хостов ESXi) и поддерживая операции обслуживания отдельных хостов ESXi без потери доступности машин кластера.

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

Если вы хотите использовать RAID 5/6 в кластере vSAN, то вам нужно принять во внимание требования к количеству хостов ESXi, которые минимально (и рекомендуемо) вам потребуются, чтобы удовлетворять политике FTT (Failures to tolerate):

Домены отказов (Fault Domains)

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

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

В больших кластерах сбой всей стойки (или группы хостов) может привести к потере данных, если домены отказов не настроены. Например:

• Без доменов отказов: vSAN может сохранить все реплики объекта на хостах внутри одной стойки, что приведет к риску потери данных в случае выхода стойки из строя.
• С доменами отказов: vSAN распределяет реплики данных между разными стойками, значительно повышая защиту данных.

• Соответствие физической инфраструктуре: создавайте домены отказов на основе стоек, подключений источников питания или сетевого сегментирования.
• Минимальные требования: для обеспечения производственной отказоустойчивости доменов требуется как минимум 3 домена отказов.
• Размер кластера:
  • Для 6-8 хостов — настройте как минимум 3 домена отказов.
  • Для кластеров с 9 и более хостами — используйте 4 и более домена отказов для оптимальной защиты.
• Тестирование и валидация: регулярно проверяйте конфигурацию доменов отказов, чтобы убедиться, что она соответствует политикам vSAN.

Архитектура дисковых групп vSAN OSA

Группы дисков (disk groups) являются строительными блоками хранилища VMware vSAN в архитектуре vSAN OSA. В архитектуре vSAN ESA дисковых групп больше нет (вместо них появился объект Storage Pool).

Дисковые группы vSAN OSA состоят из:

• Яруса кэширования (Caching Tier): нужны для ускорения операций ввода-вывода.
• Яруса емкости (Capacity Tier): хранит постоянные данные виртуальных машин.

Ярус кэширования улучшает производительность чтения и записи. Для кэширования рекомендуется использовать диски NVMe или SSD, особенно в полностью флэш-конфигурациях (All-Flash).

• Выделяйте примерно 10% от общего объема VMDK-дисков машин для яруса кэширования в гибридных конфигурациях vSAN, однако при этом нужно учесть параметр политики FTT. Более подробно об этом написано тут. Для All-Flash конфигураций такой рекомендации нет, размер кэша на запись определяется профилем нагрузки (кэша на чтение там нет).
• Используйте NVMe-диски корпоративного класса для высокопроизводительных нагрузок.

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

• Используйте полностью флэш-конфигурации для приложений, чувствительных к задержкам (latency).
• Включайте дедупликацию и сжатие данных для оптимизации дискового пространства. При этом учтите требования и характер нагрузки - если у вас write-intensive нагрузка, то включение дедупликации может привести к замедлению работы системы.

Добавление нескольких групп дисков на каждом хосте улучшает отказоустойчивость и производительность.

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

VMware vSAN и блочные хранилища

Решения для организации блочных хранилищ, такие как Dell PowerStore и Unity, остаются популярными для традиционных ИТ-нагрузок. Вот как они выглядят в сравнении с vSAN:

Сильные и слабые стороны

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

• Глубокая интеграция с vSphere упрощает развертывание и управление.
• Гибкость масштабирования за счет добавления хостов, а не выделенных массивов хранения.
• Поддержка снапшотов и репликации для архитектуры vSAN ESA.
• Экономически выгоден для организаций, уже использующих VMware.

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

Преимущества блочного хранилища:

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

Недостатки блочного хранилища:

• Меньшая гибкость по сравнению с гиперконвергентными решениями.
• Более высокая стоимость и сложность при первоначальном развертывании. Однако также нужно учитывать и политику лицензирования Broadcom/VMware, где цена входа также может оказаться высокой (см. комментарий к этой статье).

Развертывание баз данных на VMware vSAN

Базы данных создают сложные паттерны ввода-вывода, требующие низкой задержки (latency) и высокой пропускной способности (throughput). vSAN удовлетворяет этим требованиям за счет кэширования и конфигураций RAID.

Политики хранения (Storage Policies)

Политики хранения vSAN позволяют точно контролировать производительность и доступность баз данных.

Лучшие практики:

• Настройте параметр FTT (Failures to Tolerate) = 2 для критически важных баз данных.
• Используйте RAID 5 или RAID 6 для экономии емкостей при защите данных, если вас устраивает производительность и latency.

Регулярный мониторинг помогает поддерживать оптимальную производительность баз данных. Используйте продукт vRealize Operations для отслеживания таких метрик, как IOPS и latency.

Дункану Эппингу задали интересный вопрос: учитываются ли файлы, хранящиеся на общих хранилищах vSAN с включенным vSAN File Services, в максимальном количестве объектов (max object count)? Поскольку Дункан не обсуждал это в последние несколько лет, он решил сделать краткое напоминание.

С vSAN File Services файлы, которые пользователи хранят в своем файловом хранилище, размещаются внутри объекта vSAN. Сам объект учитывается при подсчёте максимального количества компонентов в кластере, но отдельные файлы в нем - конечно же, нет.

Что касается vSAN File Services, то для каждого созданного файлового хранилища необходимо выбрать политику. Эта политика будет применяться к объекту, который создаётся для файлового хранилища. Каждый объект, как и для дисков виртуальных машин, состоит из одного или нескольких компонентов. Именно эти компоненты и будут учитываться при подсчёте максимального количества компонентов, которое может быть в кластере vSAN.

Для одного узла vSAN ESA максимальное количество компонентов составляет 27 000, а для vSAN OSA – 9 000 компонентов на хост. Имейте в виду, что, например, RAID-1 и RAID-6 используют разное количество компонентов. Однако, как правило, это не должно быть большой проблемой для большинства клиентов, если только у вас не очень большая инфраструктура (или наоборот, небольшая, но вы на пределе возможностей по количеству хранилищ и т. д.).

В видео ниже показана демонстрация, которую Дункан проводил несколько лет назад, где исследуются эти компоненты в интерфейсе vSphere Client и с помощью CLI:

Летом 2024 года Фрэнк Даннеман написал интересный аналитический документ «VMware Private AI Foundation – Privacy and Security Best Practices», который раскрывает основные концепции безопасности для инфраструктуры частного AI (в собственном датацентре и на базе самостоятельно развернутых моделей, которые работают в среде виртуализации).

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

Основные моменты документа:

1. Преимущества Private AI в корпоративных датацентрах:

   • Контроль и безопасность: организации получают полный контроль над своими данными и моделями, что позволяет минимизировать риски, связанные с конфиденциальностью, и избегать зависимости от сторонних поставщиков.
   • Экономическая эффективность: Private AI позволяет управлять расходами на AI, избегая неожиданных затрат от сторонних сервисов и оптимизируя ИТ-бюджет.
   • Гибкость и инновации: быстрое тестирование и настройка AI-моделей на внутренних данных без задержек, связанных с внешними сервисами, что способствует повышению производительности и точности моделей.
2. Принцип совместной ответственности в Private AI:
   
   • Документ подчеркивает важность распределения обязанностей между поставщиком инфраструктуры и организацией для обеспечения безопасности и соответствия требованиям.
3. Моделирование угроз для Gen-AI приложений:
   • Рассматриваются потенциальные угрозы для генеративных AI-приложений и предлагаются стратегии их смягчения, включая анализ угроз и разработку соответствующих мер безопасности.
4. Модель CIA (Конфиденциальность, Целостность, Доступность):
   • Конфиденциальность: обсуждаются методы защиты данных, включая контроль доступа, шифрование и обеспечение конфиденциальности пользователей.
   • Целостность: рассматриваются механизмы обеспечения точности и согласованности данных и моделей, а также защита от несанкционированных изменений.
   • Доступность: подчеркивается необходимость обеспечения постоянного и надежного доступа к данным и моделям для авторизованных пользователей.
5. Защита Gen-AI приложений:
   • Предлагаются лучшие практики для обеспечения безопасности генеративных AI-приложений, включая разработку безопасной архитектуры, управление доступом и постоянный мониторинг.
6. Архитектура Retrieval-Augmented Generation (RAG):
   • Документ подробно описывает процесс индексирования, подготовки данных и обеспечения безопасности в архитектурах RAG, а также методы эффективного поиска и извлечения релевантной информации для улучшения работы AI-моделей.

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

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

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

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

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

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

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

Вильям Лам написал очень полезную статью, касающуюся развертывания виртуальных хостов (Nested ESXi) в тестовой лаборатории VMware Cloud Foundation.

Независимо от того, настраиваете ли вы vSAN Express Storage Architecture (ESA) напрямую через vCenter Server или через VMware Cloud Foundation (VCF), оборудование ESXi автоматически проверяется на соответствие списку совместимого оборудования vSAN ESA (HCL), чтобы убедиться, что вы используете поддерживаемое железо для vSAN.

В случае использования vCenter Server вы можете проигнорировать предупреждения HCL, принять риски и продолжить настройку. Однако при использовании облачной инфраструктуры VCF и Cloud Builder операция блокируется, чтобы гарантировать пользователям качественный опыт при выборе vSAN ESA для развертывания управляющего или рабочего домена VCF.

С учетом вышеизложенного, существует обходное решение, при котором вы можете создать свой собственный пользовательский JSON-файл HCL для vSAN ESA на основе имеющегося у вас оборудования, а затем загрузить его в Cloud Builder для настройки нового управляющего домена VCF или в SDDC Manager для развертывания нового рабочего домена VCF. Вильям уже писал об этом в своих блогах здесь и здесь.

Использование Nested ESXi (вложенного ESXi) является популярным способом развертывания VCF, особенно если вы новичок в этом решении. Этот подход позволяет легко экспериментировать и изучать платформу. В последнее время Вильям заметил рост интереса к развертыванию VCF с использованием vSAN ESA. Хотя вы можете создать пользовательский JSON-файл HCL для vSAN ESA, как упоминалось ранее, этот процесс требует определенных усилий, а в некоторых случаях HCL для vSAN ESA может быть перезаписан, что приводит к затруднениям при решении проблем.

После того как Вильям помогал нескольким людям устранять проблемы в их средах VCF, он начал задумываться о лучшем подходе и использовании другой техники, которая, возможно, малоизвестна широкой аудитории. Вложенный ESXi также широко используется для внутренних разработок VMware и функционального тестирования. При развертывании vSAN ESA инженеры сталкиваются с такими же предупреждениями HCL, как и пользователи. Одним из способов обхода этой проблемы является "эмуляция" оборудования таким образом, чтобы проверка работоспособности vSAN успешно проходила через HCL для vSAN ESA. Это достигается путем создания файла stress.json, который размещается на каждом Nested ESXi-хосте.

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

После анализа обоих обходных решений он обнаружил, что вариант с использованием stress.json имеет свои плюсы: он требует меньше модификаций продукта, а возня с конфигурационными файлами — не самый лучший способ, если можно этого избежать. Учитывая ситуации, с которыми сталкивались пользователи при работе с новыми версиями, он нашел простое решение — создать пользовательский ESXi VIB/Offline Bundle. Это позволяет пользователям просто установить stress.json в правильный путь для их виртуальной машины Nested ESXi, решая вопросы сохранения данных, масштабируемости и удобства использования.

Перейдите в репозиторий Nested vSAN ESA Mock Hardware для загрузки ESXi VIB или ESXi Offline Bundle. После установки (необходимо изменить уровень принятия программного обеспечения на CommunitySupported) просто перезапустите службу управления vSAN, выполнив следующую команду:

/etc/init.d/vsanmgmtd restart

Или вы можете просто интегрировать этот VIB в новый профиль образа/ISO ESXi с помощью vSphere Lifecycle Manager, чтобы VIB всегда был частью вашего окружения для образов ESXi. После того как на хосте ESXi будет содержаться файл stress.json, никаких дополнительных изменений в настройках vCenter Server или VCF не требуется, что является огромным преимуществом.

Примечание: Вильям думал о том, чтобы интегрировать это в виртуальную машину Nested ESXi Virtual Appliance, но из-за необходимости изменения уровня принятия программного обеспечения на CommunitySupported, он решил не вносить это изменение на глобальном уровне. Вместо этого он оставил все как есть, чтобы пользователи, которым требуется использование vSAN ESA, могли просто установить VIB/Offline Bundle как отдельный компонент.

Pete Del Vecchio, Data Center Switch Product Line Manager в компании Broadcom, выпустил интересное видео, в котором он высказывает свои предположения касательно развития сетевой инфраструктуры в 2025 году:

1. Переход от InfiniBand к Ethernet для крупных GPU-кластеров:
   Broadcom прогнозирует, что в 2025 году все крупные гипермасштабируемые GPU-кластеры окончательно перейдут с технологии InfiniBand на Ethernet. Уже сейчас большинство объявленных продуктов и кластеров для GPU используют Ethernet, и эта тенденция продолжится.
2. Ethernet станет стандартом для масштабируемых сетей (Scale-Up):
   Ethernet не только заменит InfiniBand в сетях Scale-Out (соединения между GPU-узлами), но и станет основой для сетей Scale-Up, обеспечивая связи внутри отдельных GPU-систем. В 2025 году ожидаются новые продукты и системы GPU на основе Ethernet для этих задач.
3. Демократизация искусственного интеллекта (AI):
   Broadcom считает, что AI станет доступнее для компаний разного масштаба, а не только для крупных гипермасштабируемых компаний. Основой для этого будет использование более эффективных процессоров и сетевых технологий от различных производителей. Broadcom видит свою роль в создании высокоэффективных сетевых решений, поддерживающих распределённые системы для обучения и работы AI.

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

Блогер Эрик Слуф опубликовал интересные 30-секундные видео в формате Youtube Shorts, посвященные платформе VMware Cloud Foundation.

Ролики очень удобно смотреть с телефона:

• Workload Domain Types - Management
• Workload Domain Types - VI Workload
• Single Instance - Single Availability Zone
• Single Instance - Multiple Availability Zones
• Multiple Instances - Single Availability Zone per Instance
• Multiple Instances - Multiple Availability Zones per Instance

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

Обратите внимание, что в будущей версии vSAN в интерфейсе появится опция, которая поможет с операциями, описанными ниже.

Прежде всего, вам нужно проверить, реплицированы ли все данные. В некоторых случаях мы видим, что клиенты фиксируют данные (виртуальные машины) в одном месте без репликации, и эти виртуальные машины будут напрямую затронуты, если весь сайт будет переведен в режим обслуживания. Такие виртуальные машины необходимо выключить, либо нужно убедиться, что они перемещены на работающий узел, если требуется их дальнейшая работа. Обратите внимание, что если вы переключаете режимы "Preferred / Secondary", а множество ВМ привязаны к одному сайту, это может привести к значительному объему трафика синхронизации. Если эти виртуальные машины должны продолжать работать, возможно, стоит пересмотреть решение реплицировать их.

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

1. Убедитесь, что vSAN Witness работает и находится в здоровом состоянии (проверьте соответствующие health checks).
2. Проверьте комплаенс виртуальных машин, которые реплицированы.
3. Настройте DRS (распределённый планировщик ресурсов) в режим "partially automated" или "manual" вместо "fully automated".
4. Вручную выполните vMotion всех виртуальных машин с сайта X на сайт Y.
5. Переведите каждый хост ESXi на сайте X в режим обслуживания с опцией "no data migration".
6. Выключите все хосты ESXi на сайте X.
7. Включите DRS снова в режиме "fully automated", чтобы среда на сайте Y оставалась сбалансированной.
8. Выполните все необходимые работы по обслуживанию.
9. Включите все хосты ESXi на сайте X.
10. Выведите каждый хост из режима обслуживания.

Обратите внимание, что виртуальные машины не будут автоматически возвращаться обратно, пока не завершится синхронизация для каждой конкретной виртуальной машины. DRS и vSAN учитывают состояние репликации! Кроме того, если виртуальные машины активно выполняют операции ввода-вывода во время перевода хостов сайта X в режим обслуживания, состояние данных, хранящихся на хостах сайта X, будет различаться. Эта проблема будет решена в будущем с помощью функции "site maintenance", как упоминалось в начале статьи.

Также для информации об обслуживании сети и ISL-соединения растянутого кластера vSAN прочитайте вот эту статью.