Компания VMware на днях выпустила бесплатную книгу об управлении облачной инфраструктурой - Managing a VMware Cloud for Dummies. На 79 страницах этой книги доступным языком рассказывается об устройстве cпектра решений VMware Cloud, анализируются аспекты миграции онпремизной среды в облако и полезных нагрузок между облачными средами, разбираются Day-1-2-3 операции, а также подробно рассматриваются механизмы взаимодействия пользователей с облачными сервисами.

Это полноценная книга со своим ISBN:

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

• Introducing the VMware Cloud
• Discovering the Value of Cloud Management
• Making your VMware Cloud Self-Service
• Operating Your VMware Cloud
• Migrating To and Between VMware Clouds
• Powering Your Cloud Operating Model
• (More than) Ten VMware Cloud Management Resources

Скачать книгу Managing a VMware Cloud for Dummies можно по этой ссылке.

Еще на конференции VMworld 2020 компания VMware представила новый продукт Freestyle Orchestrator, который дополняет и расширяет возможности UEM (Unified Endpoint Management), являющегося частью платформы по работе с пользовательскими окружениями Workspace ONE. VMware Freestyle Orchestrator - это полностью новый способ развертывания и конфигурирования рабочих станций на базе...

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

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

1. Функции vCenter Server Appliance Service Management

В апдейте PowerCLI появилось 4 новых командлета:

• Get-VIApplianceService – получает список сервисов vCenter Server Appliance (vCSA)
• Start-VIApplianceService – запускает один из сервисов
• Stop-VIApplianceService – останавливает
• Restart-VIApplianceService – перезапускает
  

2. Поддержка VMware Cloud on AWS Outpost

Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.

3. Поддержка Hot add / Remove для процессоров и памяти

Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:

• -CpuHotAddEnabled (включить CPU Hot Add)
• -CpuHotRemoveEnabled (включить CPU Hot Remove)
• -MemoryHotAddEnabled (включить Memory Hot Add)

4. Включение шифрованной миграции vMotion

Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.

5. Обновления для Horizon 8.4

Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.

Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.

Компания VMware объявила о выпуске новой версии Photon OS 4.0 rev 2. Напомним, что четвертая версия этой ОС, на базе которой построены виртуальные модули (Virtual Appliances) VMware, вышла в марте прошлого года.

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

• Поддержка OpenSSL 3.0 - теперь этот протокол используется по умолчанию
• Новая утилита pmd-nextgen (photon management daemon), которая дает следующие возможности:
  • Удаленное управление системой с поддержкой мобильных устройств
  • Управление сервисами systemd и другими аспектами Photon OS через REST API
  • Использование REST API для конфигураций в реальном времени и тюнинга производительности, а также мониторинга состояния Linux-систем
• Доработки движка реального времени:
  • Улучшения при работе с низкими задержками (low-latency), а также уменьшение джиттера (OS jitter)
  • Повышение стабильности работы и улучшения средств отладки
• Прочие улучшения:
  • Доработки и багофиксы в tdnf
  • Поддержка GNU tarfs для ядра Linux-esx
  • Поддержка eBPF для ядра Linux
  • Улучшения установщика, такие как поддержка устройства Secondary Kickstart и пользовательских настроек монтирования устройств
• Обновления пакетов:
  • Linux kernel 5.10.83
  • Glibc 2.32
  • Systemd 247.10
  • Python3 3.10.0
  • Openjdk : 11.0.9
  • Openssl : 3.0.0
  • Cloud-init: 21.4

Скачать Photon OS 4.0 rev 2 можно в ISO-дистрибутивах для платформ x86_64 и arm64, а также в формате OVA как виртуальный модуль для платформы VMware vSphere. Там же доступны кастомизированные образы Amazon AMI, Google GCE, Azure VHD, а также образ для Raspberry Pi.

Компания VMware объявила, что теперь ее решение VMware vRealize Automation Cloud можно дополнить продуктом SaltStack SecOps Cloud, который позволяет добавить дополнительные средства безопасности в инфраструктуру автоматизации облака. Этот компонент позволяет добавить функции соблюдения комплаенса и устранения уязвимостей в решение vRA Cloud по модели SaaS из облака.

Напомним, что ранее этот продукт был доступен только для онпремизной инфраструктуры vRealize Automation:

SecOps - это Security плюс Operations, то есть средства, которые позволяют объединить усилия команд безопасников и администраторов при конфигурации и контроле виртуальной среды. Теперь обе команды могут настраивать политики безопасности, сканировать системы на их соблюдение и активно исправлять конфигурации из единой консоли.

Многим организациям приходится соответствовать различным стандартам безопасности (ISO 27000, HIPAA, PCI, NIST и прочим), что требует выполнения тысяч различных требований и проверок. Организация Center for Internet Security (CIS) предоставляет пользователям единый фреймворк для соблюдения комплаенса в рамках различных требований и регуляций.

vRealize Automation SaltStack SecOps Cloud включает в себя базу данных сертифицированного CIS контента и требований DISA STIG (Defense Information Systems Agency Security Technical Implementation Guides), которые являются базой при конфигурации политик безопасности облачной среды.

vRealize Automation SaltStack SecOps Cloud ежедневно сканирует системы на соблюдение соответствия и предотвращает плавную "утечку" конфигураций безопасности в неправильную сторону.

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

В дополнение к этому vRA SaltStack SecOps Cloud позволяет добавить результаты сканирования решений Tenable, Rapid7, Qualys и Kenna, чтобы ускорить настройку безопасной конфигурации среды.

Более подробно о решении vRealize Automation SaltStack SecOps Cloud можно почитать на официальном сайте.

Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

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

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Мы много писали о решении VMware Cloud Disaster Recovery, которое позволяет обеспечивать катастрофоустойчивость виртуальных инфраструктур за счет резервирования онпремизных ресурсов в облаке. Службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облаке VMware Cloud on AWS.

VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.

У многих пользователей такой схемы возникает вопрос - а за что они отвечают в этом процессе, за что отвечает VMware, а за что - Amazon?

Ответ можно найти вот тут, мы расскажем об этом вкратце. Итак, VMware Cloud Disaster Recovery состоит из трех компонентов:

• Файловая система Scale-out Cloud File System (SCFS)
• Оркестратор (Orchestrator)
• Коннекторы DRaaS Connectors

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

С точки зрения безопасности и операций, ответственность распределяется по трем основным уровням - пользователь, VMware и Amazon AWS:

Пользователь отвечает за:

"Security in the Cloud":

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

VMware отвечает за:

"Security of the Cloud" - то есть за безопасность самого облака, что означает защиту систем и программного обеспечения, составляющего основу облака для служб VMware Cloud Disaster Recovery. Очевидно, что это включает в себя не только DRaaS-cервисы, но и платформенные составляющие, такие как VMware vSphere и vSAN.

Amazon отвечает за:

"Security of the Infrastructure" - физические серверы, доступ к ним в датацентрах, функционирование аппаратного обеспечения, исправность физических линий связи и соединений в рамках ЦОД.

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

Более детальная информация обо всем этом приведена в документе "VMware Cloud Disaster Recovery Service Description".

В конце лета прошлого года мы писали об интереснейшем документе "VMware vSphere Snapshots: Performance and Best Practices", который содержит весьма полезную многим администраторам информацию о производительности снапшотов, а также лучшие практики по обращению с ними. Мы, кстати, часто пишем про это (1, 2, 3), и хорошо, что теперь об этом есть и подробный документ с картинками.

В конце года VMware решила обновить этот whitepaper, добавив туда немного информации о производительности снапшотов в инфраструктуре контейнеризованных приложений Kubernetes на платформе vSphere.

Тестовая конфигурация там выглядела вот так:

Соответственно, процедура тестирования выглядела так:

• Снимаем базовый уровень производительности для ВМ worker-ноды без снапшотов под нагрузкой
• Создаем снапшот ВМ worker-ноды
• Запускаем бенчмарк и получаем данные о производительности
• Увеличиваем по одному число снапшотов и повторяем цикл тестирования

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

Больше подробностей вы можете узнать в обновленном документе "VMware vSphere Snapshots: Performance and Best Practices".

На днях на сайте проекта VMware Labs обновилось средство для развертывания решения NSX Advanced Load Balancer (бывший продукт AVI Networks) - Easy Deploy for NSX Advanced Load Balancing до версии 3.0. Напомним, что об этом продукте мы впервые рассказывали вот тут. С помощью утилиты Easy Deploy можно развернуть балансировщик из интерфейса всего в несколько кликов.

Это позволит вам использовать такие функции, как multi-cloud load balancing, web application firewall и application analytics в любом облаке, без необходимости ручного развертывания и настройки продукта, которая довольно непроста.

Давайте посмотрим, что нового появилось в версии Easy Deploy for NSX ALB 3.0:

• UI-фреймворк был полностью переработан, чтобы соответствовать интерфейсу NSX Advanced Load Balancer
• Теперь для доступа к интерфейсу не нужна аутентификация
• Был переработан API-сервер, а сами API стандартизованы
• Была убрана база данных, которую заменили на систему кэширования, которая больше не сохраняет постоянных данных
• Операции VMC Day 2 теперь можно выполнять за пределами объекта SDDC
• Поддержка продуктов Avi версий 21.1.2, 21.1.1-2p2 и 20.1.7
• Улучшен механизм управления образами, теперь можно загружать их локально через CLI

Скачать Easy Deploy for NSX Advanced Load Balancing 3.0 можно по этой ссылке.

Ну и бонус - видео о том, как работает этот продукт:

Первое в этом году обновление на сайте проекта VMware Labs - это очень полезное мобильное приложение VM News Collector. Оно представляет собой агрегатор всех новостей и обновлений о продуктах и технологиях компании VMware, который собирает все это в реальном времени.

На айфоне это выглядит так:

На андроидах - примерно так же:

VM News Collector построен на базе фидов RSS, которые добавляются из различных источников и сейчас подключены на платформе VMware Blogs.

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

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

Полезной возможностью продукта является функция поиска новостей и оповещений для конкретного продукта VMware.

Скачать VMware VM News Collector для iOS и Android можно по этой ссылке.

Компания VMware выпустила четвертое издание документа Global Security Insights Report 2021, в котором рассматриваются глобальные проблемы безопасности ИТ-инфраструктуры, которые были актуальны в прошлом году. В исследовании приняло участие 3 542 специалиста в должности CIO, CTO и CISO из разных организаций, которые находятся в 14 странах.

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

Растет активность Ransomware как одного из самых страшных видов атак с точки зрения экономического ущерба:

Стратегия Cloud-first Security набирает обороты:

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

Ну и самая критичная точка по опросам, через которую может произойти вторжение - приложения:

Больше интересного и полные результаты опроса с разбивкой по странам вы можете найти в документе Global Security Insights Report 2021.

Компания VMware выпустила интересный документ "Intel architecture optimizes VMware SD-WAN Edge performance", в котором рассказывается о решении VMware Secure Access Service Edge (SASE) на базе аппаратных платформ Intel. Решение SASE объединяет компоненты интегрированной среды VMware, предназначенные для создания распределенной инфраструктуры безопасного и производительного доступа пользователей к приложениям и средства контроля этой активности.

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

Идея концепции SASE в том, чтобы обеспечивать защиту доступа к приложениям в географических центрах, максимально приближенных к облачной инфраструктуре, где эти приложения находятся (публичные облака и облака сервис-провайдеров). Сейчас у SASE есть более, чем 150 точек присутствия (points of presence, PoP), где физически размещено оборудование в облачных датацентрах, что позволяет построить безопасный и высокопроизводительный мост к SaaS-сервисам приложений.

Компоненты SASE включают в себя следующие решения:

• Облачную технологию VMware SD-WAN, которая виртуализует WAN-сети в целях отделения программных служб от оборудования, что дает гибкость, простоту управления, производительность, безопасность и возможность быстрого масштабирования в облаках.
• Компонент VMware Secure Access для удаленного доступа в рамках фреймворка zero-trust network access (ZTNA). Это новый уровень VPN-решений, который дает новые инструменты для доступа к облачным приложениям.
• VMware Cloud Web Security - это интегрированное решение на базе таких техник, как Secure Web Gateway (SWG), cloud access security broker (CASB), data loss prevention (DLP), URL filtering, а также remote browser isolation (RBI), что реализовано на уровне SASE PoP для защиты прямого доступа к SaaS-приложениям и веб-сайтам.
• VMware Edge Network Intelligence - это платформа для отслеживания активности подключений и сетевых потоков в рамках концепции AIOps, которая предполагает использование алгоритмов AI/ML для аналитики трафика WAN-to-branch, WiFi/LAN, а также на уровне приложений.

В документе описывается использование компонентов VMware SD-WAN Edge на базе различных платформ Intel, использующих процессоры Atom и Xeon. Требуемая конфигурация устройств SD-WAN рассматривается через призму требований приложений к пропускной способности канала, а также объема виртуализуемых сетевых служб, таких как фаерволы, системы IDS и прочее, которые работают как VNF (virtual network functions) в рамках программно-аппаратных модулей.

Больше деталей вы можете узнать из документа "Intel architecture optimizes VMware SD-WAN Edge performance", ну а о реализации инфраструктуры SASE со стороны Intel можно узнать из этого видео.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

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

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Недавно мы писали об уязвимости Log4j, затрагивающей компоненты веб-серверов Apache Software Foundation log4j Java logging, а значит присутствующей и во многих продуктах VMware. Также мы рассказывали о том, как понять, что вас сканируют на уязвимость log4j, если у вас есть VMware vRealize Network Insight.

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

HealthAnalyzer позволит вам обнаружить угрозы, которые описаны в статьях CVE-2021-4428, CVE-2021-45046 и CVE-2021-45105 (а это 10/10 и 7.5/10 по шкале серьезности). Однако чтобы это работало, вам нужно удалить старую версию VMware HealthAnalyzer и поставить новую с портала Partner Connect.

Чтобы удалить старую Java-версию HealthAnalyzer, нужно просто удалить ее папки и связанные файлы. Для виртуальных модулей - нужно выключить ВМ и удалить ее из инвентори.

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

За установкой продукта HealthAnalyzer обращайтесь к своему поставщику VMware.

Ну и бонус-видео о том, как временно обезопасить свой VMware vCenter от Log4j, пока критические фиксы еще в пути:

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

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

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

1. Переход на PostgreSQL

Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.

2. Улучшения HCX Network Extension

Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.

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

HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.

3. Улучшения OS Assisted-миграций

OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:

• Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
• Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3. 

4. Улучшения юзабилити

• Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
• Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.

Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.

Мы много пишем про растянутые кластеры VMware vSAN Stretched Clusters для онпремизной инфраструктуры VMware vSphere, но не особо затрагивали тему растянутых кластеров в публичных облаках. В частности, в инфраструктуре VMware Cloud on AWS можно создавать такие кластеры, работающие на уровне зон доступности (Availability Zones).

Облачные администраторы знают, что публичное облако AWS разделено на регионы (Regions), в рамках которых есть зоны доступности (Availability Zones, AZ), представляющие собой домены отказа (аналогичные таковым в vSAN). То есть если произойдет сбой (что довольно маловероятно), он затронет сервисы только одной зоны доступности, остальные AZ этого региона продолжат нормально функционировать.

Сама Amazon рекомендует дублировать критичные сервисы на уровне разных зон доступности, а с помощью растянутых кластеров VMware vSAN можно сделать полноценную задублированную среду на уровне AZ в рамках одного региона с компонентом Witness для защиты от ситуации Split-brain, когда будет разорвана коммуникация между зонами:

Для такой конфигурации вам потребуется создать SDDC с поддержкой Stretched Cluster, который создается на этапе настройки SDDC на платформе VMC on AWS. Надо понимать, что при развертывании SDDC можно задать тип кластера Standard или Stretched, который уже нельзя будет поменять в дальнейшем.

Пользователь задает AWS Region, тип хоста, имя SDDC и число хостов, которые он хочет развернуть. Далее администратор выбирает аккаунт AWS и настраивает VPC-подсеть, привязывая ее к логической сети для рабочих нагрузок в аккаунте. Нужно выбрать 2 подсети для обслуживания двух зон доступности. Первая устанавливается для preferred-площадки vSAN, а вторая помечается как сеть для "non-preferred" сайта.

После создания кластера, когда вы зайдете в инстанс Multi-AZ SDDC vCenter вы увидите растянутый кластер vSAN с одинаковым числом узлов на каждой из AZ и один компонент Witness, находящийся за пределами данных AZ.

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

Конечно же, нужно позаботиться и о защите виртуальных машин как на уровне площадки, так и на уровне растянутого кластера. Лучше всего использовать политику хранения "Dual site mirroring (stretched cluster)" на уровне ВМ. В этом случае при сбое виртуальной машины в рамках одной зоны доступности она будет автоматически перезапущена в другой AZ с помощью механизма VMware HA.

Также администратору надо контролировать физическое размещение виртуальных машин по площадкам, а также политику Failures to tolerate (FTT):

Конечно же, не все виртуальные машины нужно реплицировать между площадками - иначе вы просто разоритесь на оплату сервисов VMConAWS. Администратор должен выставить правила site affinity rules, которые определяют, какие машины будут реплицироваться, а какие нет. Делается это с помощью движка политик storage policy-based management (SPBM) для ВМ и их VMDK-дисков: 

Также более подробно обо всем этом вы можете почитать в статьях vSAN Stretched Cluster Guide и VMware Cloud on AWS: Stretched Clusters.

Недавно мы писали про критическую уязвимость log4j, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Атакующий, который имеет доступ к отсылке логов, может исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее для различных программных продуктов еще находится в процессе.

Если у вас есть средство VMware vRealize Network Insight, предназначенное для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре, то вы можете легко обнаружить злоумышленников, которые пытаются использовать уязвимость log4j.

Итак, вам понадобится собранный участниками краудсорсинговой кампании список IP-адресов, а также вот этот Python-скрипт от автора Martijn Smit. В VMware vRNI должен быть включен анализ потоков (flows), кроме того у вас должен быть развернут vRealize Network Insight Python SDK.

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

# export PYTHONPATH=/your/path/tp/network-insight-sdk-python/swagger_client-py2.7.egg

# python3 vrni-log4j-flow-check.py --platform_ip yourvRNIPlatformIP --username yourUsername --password yourPassword

Отработают эти команды примерно следующим образом (кликните для анимации):

Также этот скрипт можно запустить и в облачной версии vRealize Network Insight Cloud с токеном Cloud Services Portal API. Для этого надо посмотреть параметры скрипта:

# python3 vrni-log4j-flow-check.py --help

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

Вот еще немного информации по теме, которая может оказаться вам полезна:

• Detecting & Preventing CVE-2021-44228 (Log4Shell) with the NSX Distributed IDS/IPS
• Log in the Shell: An Analysis of Log4Shell Exploitation

Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.8. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.

Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.8:

• Исправление для ACPI, что позволяет поддерживать гостевые ОС OpenBSD.
• Улучшенная обработка ITS device ID width в реализации без поддержки indirect table.
• Улучшенная обработка VMkernel TLB (Translation Lookaside Buffer - он представляет собой кэш для MMU).
• Улучшенная обработка механизма NUMA, особенно в части сообщений об ошибках.

Скачать VMware ESXi ARM Edition 1.8 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново.

На сайте проекта VMware Labs появилось обновление утилиты Virtual Machine Desired State Configuration. О прошлой ее версии мы писали вот тут.

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

Раньше подход был таким - к нужной дате/времени, согласованному с владельцами систем, происходила перезагрузка машин, которые за некоторое время уже поднимались в желаемой конфигурации (Desired State). Но это рождает довольно сложный административный процесс такого согласования.

Утилита VMDSC использует другой подход - виртуальные машины окажутся в Desired State при следующей перезагрузке гостевой ОС. Это позволяет не договариваться о простое ВМ в определенные периоды, а просто встраивать процесс реконфигурации процессора и памяти в жизненный цикл систем, когда им и так требуется перезагрузка (например, при накатывании обновлений).

Что нового появилось в VMDSC версии 1.0.1:

• Исправлена проблема, когда сервис VMDSC мог использовать неправильный сервисный аккаунт vCenter при восстановлении соединения.
• Сценарий первоначальной загрузки виртуального модуля теперь проверяет URL опционального сертификата vCenter CA в форматах DER или PEM.
• Теперь в составе есть vRealize Log Insight VMDSC Content Pack (1.0), который реализует дэшборд для исторических событий VMDSC.
• Появилась поддержка модуля PowerVMDSC, которая дает пользователям возможность взаимодействовать напрямую с VMDSC из PowerShell.

Скачать утилиту Virtual Machine Desired State Configuration версии 1.0.1 можно по этой ссылке.

В конце ноября мы писали о том, что "уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3", но ситуация оказалась гораздо хуже. Никаких новостей об исправлениях для новой версии, по-прежнему, нет. Напомним, что о новых возможностях vSphere 7 U3 мы писали тут.

Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:

Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:

Если мы зайдем на статью базы знаний "Build numbers and versions of VMware ESXi/ESX (2143832)", то увидим, что последние три релиза vSphere просто зачеркнуты в таблице:

18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:

Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.

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

Ждем исправлений!

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

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

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

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

Структура списка конфигураций и рекомендаций

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

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

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

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

На днях компания VMware объявила о скором обновлении своего средства NSX-T до версии 3.2. Напомним, что NSX-T - это решение для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes. О версии VMware NSX-T 3.0 мы писали в прошлом году вот тут.

Отметим, что поддержка продукта VMware NSX Data Center for vSphere заканчивается 16 января 2022 года, поэтому все партнеры и клиенты должны перевести рабочие нагрузки на VMware NSX-T. При этом могут переезжать как окружения на базе Cloud Director, так и без него - все ресурсы, описывающие этот процесс, доступны. Основной инструмент для этого переезда - это VMware NSX Data Center for vSphere to VMware NSX-T Data Center migration tool.

Давайте посмотрим, что появилось нового в VMware NSX-T 3.2.

Функции мультиоблачной безопасности

Здесь появились следующие улучшения:

1. Возможности Tapless Network Traffic Analysis (NTA)

Функции Network traffic analysis (NTA) и средства для создания песочниц интегрированы в единый NSX Distributed Firewall (DFW). Сам сервис NTA встроен в гипервизор. Вместе с функциями IDS/IPS решения NSX администраторы могут виртуализовать весь стек безопасности и устранить слепые зоны для применения политик безопасности, чтобы контролировать сетевые потоки, безотносительно того, какие физические уровни под ними лежат.

2. Сетевой экран шлюза (Gateway Firewall)

Улучшенный gateway firewall служит как программный шлюз с возможностью контроля на уровнях L2-L7, включая URL-фильтрацию и расширенные функции предотвращения угроз с возможностями анализа вредоносного ПО и сэндбоксинга.

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

3. Интегрированный механизм NDR и NSX Intelligence

Теперь решение NSX Network Detection and Response (NDR) интегрировано в платформу NSX Intelligence, что позволяет решению NDR понимать сигналы от IDS/IPS, NTA и сэндбокса, чтобы идентифицировать настоящие вторжения. Также NSX Intelligence получил улучшения производительности, а также улучшения движка рекомендаций для правил фаервола.

4. Распределенная Switch-agnostic безопасность

NSX Distributed Firewall теперь поддерживает рабочие нагрузки, развернутые на распределенных группах портов (Distributed Port Groups) распределенных коммутаторов (VDS). Это позволяет реализовать фаервол NSX без внесения изменений в vSphere Distributed Switch и без конвертации портов в N-VDS, а также без развертывания сетевых оверлеев.

Улучшения сетевого взаимодействия и механизма политик

Здесь мы увидим 3 основных улучшения:

1. Работа с сетью и обеспечение безопасности для связки NSX-T и Antrea

Начиная с NSX-T 3.2, сетевые администраторы могут определить политики для Antrea в плане сетевых настроек и безопасности для контейнеров прямо из интерфейса NSX-T Manager. Политики применяются к кластерам Kubernetes на базе Antrea 1.3.1-1.2.2 с использованием interworking controller. Объекты K8s, такие как поды, пространства имен и сервисы, объединяются в инвентаре NSX-T и тэгируются, а значит их можно выбрать при настройке политик Distributed Firewall. Также NSX-T может управлять компонентом Antrea Traceflow и собирать лог-бандлы с кластеров, используя Antrea.

2. Улучшенный координатор миграции

NSX Migration Coordinator был улучшен, теперь он поддерживает определенные пользователем топологии NSX, больший масштаб развертываний и другие возможности, которые ранее не поддерживались, например, VMware Integrated OpenStack (VIO), фиксированные топологии OSPF, функции guest introspection для партнеров, которые поддерживают Migration Coordinator, а также конфигурации identity-based firewall (IDFW/RDSH).

3. Функции NSX Federation

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

Теперь NSX Federation поддерживает репликацию тэгов виртуальных машин между local managers, что позволяет виртуальным машинам при восстановлении после сбоя сохранить нужные политики безопасности. Также в NSX-T 3.2 есть мониторинг состояния каналов коммуникации между global и local manager.

Улучшения настройки сети и операций

В этой категории VMware сделала 4 основных улучшения:

1. Улучшенное развертывание NSX

Теперь администраторы могут развернуть NSX-T manager и различные сценарии networking and security напрямую из клиентов vSphere. Также есть guided workflows, которые упрощают развертывание NSX Manager и настройку политик.

2. Упрощенное развертывание для NSX Advanced Load Balancer 

Установка NSX Advanced Load Balancer (ALB) теперь стала проще за счет тесной интеграции с NSX Manager. Вы можете использовать графический интерфейс NSX Manager для установки и настройки контроллеров NSX Advanced Load Balancer, после чего запустить ALB UI для настройки расширенных параметров. Также появились возможности по миграции своего решения по балансировке с NSX for vSphere на VMware NSX Advanced Load Balancer с использованием Migration Coordinator.

3. Поддержка vRealize Network Insight Support для NSX-T Federation and Firewall

Тесная интеграция между vRealize Network Insight 6.4 и NSX-T Federation позволяет улучшить сетевую видимость между разными датацентрами на базе NSX-T на разных уровнях: глобальном, региональном и уровне локального сайта. Новые возможности позволяют оптимизировать производительность и просмотр сетевых потоков VM-to-VM как в рамках одного сайта, так и между сайтами в рамках федерированной топологии. vRealize Network Insight 6.4 теперь поддерживает  NSX-T Distributed Firewall (DFW) на распределенных порт-группах (Distributed Port Groups, DVPG), что дает дополнительные возможности анализа незащищенных потоков трафика, возможности безопасности, такие как Name Space (NS) groups, а также правила распределенного фаервола на существующих группах vSphere VLAN DVPG.

4. Улучшения сетевого мониторинга и механизма решения проблем

Новые функции Edge и L3 time-series monitoring позволяют получить представления во времени для метрик Edge и L3, такие как использование CPU, памяти, диска, пакетов в секунду, байтов в секунду, packet drop rate и многое другое в NSX Manager. Это позволяет сетевым администраторам получать больше данных для анализа в историческом контексте. Функции Live Traffic Analysis в NSX Manager дают возможность производить оперативную диагностику и решение проблем в плане состояния кластера, компонентов управления, федерации, состояния транспортных узлов, distributed firewall, Edge, VPN, NAT, Load Balancing и платформы NSX Application Platform. 

Компания VMware сообщает пользователям, что разобралась с проблемой, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Эта уязвимость описана в CVE-2021-44228 - атакующий, который имеет доступ к отсылке логов (к отсылке самих сообщений или к настройке их параметров), может исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее еще находится в процессе.

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

Итак, вот какие ресурсы помогут вам защититься от этой уязвимости:

• VMware Security Advisory VMSA-2021-0028 (главное описание проблемы и путей ее решения)
• VMSA-2021-0028 Questions & Answers (вопросы и ответы)
• VMSA-2021-0028 & Log4j: What You Need to Know (источник этого поста)
• VMware Communities Thread On CVE-2021-44228 (место, где можно задать вопросы по этой теме)
• Tips for Patching VMware vSphere & Cloud Infrastructure (практические советы по патчингу)
• VMware vSphere Security Configuration Guide (основной документ о безопасности vSphere)

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

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

Помните, что уязвимость критическая и имеет оценку 10 из 10 по методике CVSS 3.1 (remote code execution, RCE), поэтому надо проверить все компоненты инфраструктуры уже сегодня, особенно те, что смотрят в интернет. Самым простым способом для злоумышленника будет посылка кода со страницы логина атакуемого сервиса, так как все такие действия логируются.

Ну и есть положительный момент - в облачных инфраструктурах, таких как VMware Cloud on AWS, эти проблемы уже устранены, но на стороне онпремизных облаков или небольших сервис-провайдеров они все еще могут быть.

VMware продолжает свою кампанию по раскрутке решения Avi Vantage Platform, которое было приобретено вместе с компанией Avi Networks пару лет назад. В хорошо оформленной мини-книге Multi-Cloud Load Balancing for Dummies на 48 страницах рассказывается о том, как с помощью Avi Vantage Platform можно осуществлять мультиоблачную балансировку на уровне приложений в гибридных средах.

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

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

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

• Консистентная доставка сервисов в мультиоблачной среде
• Гибкое автомасштабирование сервисов по запросу
• Автоматизация операций по доставке приложений
• Мониторинг происходящего в реальном времени и сервисы аналитики
• Возможность предоставить разработчикам функции самообслуживания
• Упрощение управления инфраструктурой безопасности
• Модернизация доставки микросервисных приложений

Скачать книгу Multi-Cloud Load Balancing for Dummies можно по этой ссылке.

Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.7. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.

Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.7:

• Экспериментальная поддержка платы Quartz64 от Pine64.
• Поддержка драйвера VMware SVGA (теперь он совместим с платой Fusion on AS, где исправлены многие ошибки)
• Монитор виртуальных машин, который поддерживает архитектуру NUMA, что улучшает производительность на двухсокетных машинах Ampere Altra.
• Улучшенная совместимость для систем без IORT.
• Исправлены проблемы с производительностью в гостевых ОС с новыми ядрами Linux, такими как Debian 10 и Photon 4.
• Добавлено распознавание ядра Cortex-A55.
• Улучшенная обработка TLBI в мониторе виртуальных машин и в VMkernel.
• Улучшения обработки одновременных базовых операций в гипервизоре.

Скачать VMware ESXi ARM Edition 1.7 можно по этой ссылке.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Компания VMware на днях выпустила новую версию флагманской платформы для виртуализации и доставки виртуальных ПК и приложений Horizon 8 2111. Напомним, что формат версий для продуктов Horizon Server, Horizon Client, Horizon Agent и Horizon Console указывается в формате YYMM. Например, эта версия от ноября 2021 года - 2111. О прошлой версии 2106 мы писали вот тут.

Давайте посмотрим, что именно нового появилось в Horizon 8 2111:

1. Более предсказуемая поддержка Horizon

Теперь клиентам VMware дается 30-дневный бесплатный период по истечении оплаченного периода Horizon, чтобы пользоваться услугами техподдержки, пока руководство занимается вопросом продления лицензий. Также появился релиз Extended Service Branch (ESB) Maintenance Release, который расширяет поддержку Horizon 8 2111 до 36 месяцев. Ну и прямой апгрейд с версий ESB 7.10.3 и 7.13.1 теперь полностью поддерживается. За более подробной информацией можно обратиться к KB 86744.

2. Улучшение эффективности и безопасности мгновенных клонов (Instant Clones)

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

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

После того, как сканирование закончено, у образа появляется статус "ready to clone". Вот как это работает:

3. Оптимизация Windows для виртуального окружения

Многие из вас знают про очень полезную утилиту Windows OS Optimization Tool for VMware Horizon, которая предназначена для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

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

4. Улучшенный траблшутинг с функцией Events Filtering

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

5. Улучшенная безопасность пользователей и решение проблем с помощью VMware Horizon Recording

Многим администраторам Horizon известна утилита Horizon Session Recording, которая теперь называется VMware Horizon Recording и стала частью Horizon. Данная утилита предназначена для записи пользовательских сессий и активности в виртуальных десктопах и приложениях. С помощью Session Recording администратор Horizon имеет возможность перенаправить запись экрана сессий пользователей, сделанных в определенное время, на центральный сервер, где потом он может воспроизвести их в HTML5-консоли. Саму сессию в виде видеофайла можно скачать как MP4 для воспроизведения в локальном плеере.

Вот как это работает:

6. Поддержка нескольких экранов для Samsung Desktop Experience (DeX)

7. Решение Microsoft Teams теперь доступно для Google Chrome OS и HTML Access 

Технология Microsoft Teams Optimization теперь была добавлена в клиент Horizon Chrome и HTML Access. Это позволяет полноценно использовать Teams на хромбуках для видеозвонков, получая отличное качество картинки и аудио. Можно использовать браузеры Chrome или Microsoft Chromium Edge. Полный список поддерживаемых фич Teams можно найти в Release Notes.

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

В Horizon 8 2111 на 17% была улучшена плотность сессий на хост RDSH, которая достигла 88. Также на 10% была улучшена плотность сессий Windows Virtual Desktops (WVD) - их может быть до 37. Кроме того, были сделаны некоторые оптимизации использования CPU, а кодек Blast теперь потребляет на 9.5% меньше пропускной способности канала.

9. Независимость версий клиента и агента

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

10. Защита виртуальных ПК и приложений от кейлоггеров на клиенте для Mac

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

11. Улучшенная работа для приложений по запросу

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

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

Вот как это работает:

12. Хранение пользовательских профилей в облаке Microsoft OneDrive for Business

Теперь VMware Dynamic Environment Manager (DEM) интегрирован со службами Microsoft OneDrive for Business, что позволяет хранить профили пользователей на их собственных хранилищах OneDrive. Это позволяет легко и гибко использовать профиль, доступный напрямую из публичного облака, и не использовать SMB-ресурсы компании.

Более детально об этой возможности рассказано в документе DEM Installation Guide.

Скачать пробную версию VMware Horizon 8 2111 можно по этой ссылке. Release Notes доступны тут.

На днях компания VMware обновила свое облачное решение VMware vRealize Log Insight Cloud. Напомним, что это решение предназначено для аналитики лог-файлов и мониторинга инфраструктуры в облаке. О прошлой версии этого продукта мы писали вот тут.

Давайте посмотрим, что появилось нового в декабрьском обновлении vRLI Cloud:

1. Расширение локаций, где доступен продукт

Теперь Log Insight Cloud можно получить в регионе Asia Pacific (Tokyo, Japan).

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

• US West (Oregon)
• Europe (London, Frankfurt)
• Canada (Central)
• Asia Pacific (Sydney, Singapore)
• South America (Sao Paulo)
• Asia Pacific (Tokyo, Japan)

2. Загрузка локальных логов в облако

Часто администраторы загружают лог-файлы своей онпремизной инфраструктуры в облако во время пробного периода, для этого и предусмотрели данную возможность. Можно загружать файлы в формате .log и .txt и 10 файлов одновременно (до 10 МБ каждый).

3. Интеграция с AWS Lamba и HashiCorp Vault

Новая возможность интеграции с функциями платформы AWS Lambda теперь позволяет перенаправить логи CloudWatch, CloudTrail и многих других сервисов в Log Insight Cloud. Если вам нужна дополнительная безопасность по хранению учетных данных, то можно использовать функции интеграции с защищенным хранилищем учетных данных HashiCorp Vault.

4. Новые функции аудита событий через VMware Cloud Services Content Pack 2.0

Дополнительные аудируемые события контент-пака были добавлены для того, чтобы соблюсти регуляторные требования платформы VMware Cloud Service Portal (CSP). Теперь в VMware Cloud Services Content Pack 2.0 есть следующие новые события:

• Access Request Raised by Org Members
• Access Request Raised by Non Org Members
• Entitlement Request for Org Member Cancelled
• Entitlement Request for Non Org Member Cancelled
• Entitlement Request Actions
• Entitlement Request Approval Actions
• Violation Policies Updated
• Entity Violations Count Update OAuth App
• Entity Violations Count Update API Token
• Advance Features Toggled

5. Поддержка SSL для Cloud Proxy

Cloud Proxy получает логи и информацию о событиях из разных источников мониторинга и отправляет эти данные в vRealize Log Insight Cloud, которые уже дальше запрашиваются и анализируются. Теперь эти логи могут пересылаться по защищенному каналу SSL.

6. Алерты об изменении статуса форвардинга логов

Теперь по почте можно получать оповещения о следующих событиях:

• Log Forwarding Disabled Temporarily – перенаправление логов отключено на несколько следующих минут, ввиду обнаружения слишком большого количества ошибок на источнике. 
• Log Forwarding Disabled – перенаправление логов отключено постоянно из-за невозможности установить соединение.

Попробовать vRealize Log Insight Cloud в виртуальной тестовой лаборатории и запросить пробную версию в облаке VMware Cloud on AWS можно по этой ссылке.

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

Начиная с 25 ноября, провайдеры получили доступ к VMware Tanzu Standard - платформе, которая позволяет разработчикам развертывать и поддерживать свою инфраструктуру контейнеризованных приложений в кластерах Kubernetes. Теперь это возможно и в облаке посредством интеграции решений VMware Tanzu Standard и VMware Cloud Director (пока поддерживается версия 10.2), что позволяет создать инфраструктуру Kubernetes as-a-Service (KaaS) для мультиоблачных сред.

Теперь сервис-провайдеры имеют выбор между инфраструктурой Tanzu Kubernetes Grid, построенной на собственном дистрибутиве Kubernetes от VMware, и полностью интегрированном сервисе на платформе vSphere. Управлять всем этим можно через консоль Tanzu Mission Control.

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

• Создание кластеров K8s
  • Развертывание кластеров
  • Служба VMware Storage service для окружений разработчиков
  • Библиотека контента (Content library) для версий Kubernetes
  • Сетевой сервис для K8s-кластеров, включая балансировку нагрузки (NSX ALB Basic), сервисы NAT и другое
  • Плагин для интерфейса Antrea Container Networking Interface (CNI)
  • Сервисы обслуживания жизненного цикла через Cluster API
• Операции с кластерами K8s
  • Привязка и управление CNCF-совместимыми кластерами K8s
  • Централизованный доступ и управление политиками
  • Служба vSphere Pod Service
  • Служба Image Registry на базе Harbor для управления версиями в контейнерном окружении
  • Возможности мониторинга состояния рабочих нагрузок через Fluent Bit, а также Prometheus и Grafana для мониторинга самой платформы
  • Управление на базе vCenter
  • Резервное копирование и восстановление пространств имен, а также запланированный бэкап
  • Возможности аудита системы и произошедших событий, включая срез кластера по производительности
  • Возможность загрузить opensource-пакеты для мониторинга через Fluent Bit, а также службу image registry через Harbor и Calico CNI

Больше интересного о решении Tanzu Standard Edition для сервис-провайдеров можно узнать на следующих ресурсах:

• Tanzu Standard Solution Brief
• VMware Tanzu Editions – Tanzu Standard
• VMware Developer Ready Cloud
• VMware Tanzu Blog