Компания VMware выпустила очень интересное видео про приложения, доставляемые пользователям в виртуальные ПК по запросу (On-Demand Applications) в инфраструктуре виртуальных томов App Volumes:

Данная функция появилась в версии App Volumes 2111 (анонсирована она была еще в 2019 году), она позволяет не монтировать VMDK с приложениями при загрузке виртуальной машины, но оставлять иконки приложений на рабочем столе. При клике на эти иконки происходит динамическое монтирование томов, выстраивание связей и подгрузка приложения в операционной системе. Это позволяет не тратить время на монтирование дисков при загрузке ВМ и ускорить логин пользователя.

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

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

Не так давно компания VMware обновила параметры Configuration Maximums, которые содержат максимальные параметры конфигураций инфраструктуры виртуализации и доставки настольных ПК VMware Horizon 7 (напомним, что актуальная на сейчас версия 2111 стала доступна в декабре прошлого года).

Давайте посмотрим на актуальные пределы конфигураций Horizon 7, которые VMware приводит в KB 2150348 с учетом имеющихся на сегодня рекомендаций:

Лимиты архитектуры Cloud Pod Architecture

Лимиты RDSH-сессий

Лимиты ESXi и хранилищ виртуальных машин

Параметры серверов Connection Servers

Год назад мы писали о том, что VMware обновила свой основной документ об обеспечении безопасности виртуальной среды VMware vSphere 7 Security Configuration Guide, а также рассказывали о главных настройках и конфигурациях, описанных в нем.

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

Например, недавно обновился документ NSX-T 3.2 Security Configuration Guide, рассказывающий об обеспечении безопасной конфигурации решения для виртуализации и агрегации сетей NSX-T 3.2, о новых возможностях которого мы писали вот тут.

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

Как обычно, руководство состоит из двух файлов:

• XLSX-таблица со всеми конфигурациями и объяснениями по их настройке
• PDF-файл с описанием лучших практик по созданию безопасной конфигурации (документ Securing VMware NSX-T Data Center)

Основная таблица руководства разбита на 5 вкладок:

• Doc. Info - описание колонок таблиц (см. ниже).
• Management Plane - рекомендации и конфигурации для управляющих компонентов.
• Data Plane - настройки, касающиеся работы с трафиком.
• Appendix - ссылка на документ о портах и соединениях для VMware NSX-T.
• Change Log - история изменений документа.

Ну а вот как выглядят основные поля приведенных в таблице конфигураций:

• ID - идентификационное имя рекомендации.
• Component - это продукт VMware или другой компонент виртуальной среды (например, гипервизор KVM).
• Subcomponent - это логическая группировка рекомендаций и конфигураций по категориям.
• Title - лаконичная формулировка сути этой рекомендации.
• Vulnerability Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются безопасности в связи с изменением настройки.
• Assessment Procedure - пошаговое описание процедур, которые нужно выполнить, чтобы получить желаемую конфигурацию.
• Word of Caution - это информация о потенциальном негативном эффекте от изменения данной настройки.
• Desired Value - рекомендуемое значение, часто оно является значением по умолчанию.
• Is the setting default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• API - это ссылка на соответствующий NSX-T REST API.
• Reference - отсылка к документации или другим объектам, которые более детально описывают данную конфигурацию.

Скачать VMware NSX-T 3.2 Security Configuration Guide можно по этой ссылке.

Почти два года назад мы писали об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Сегодня мы расскажем об управлении сертификатами VMware vSphere с помощью PowerCLI на основе материалов вот этой статьи в блоге VMware.

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

Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

Итак, давайте посмотрим, как они работают:

1. Управление доверенным хранилищем сертификатов

Для работы с Trusted Certificate Store можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:

#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates

Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }

Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:

#Read the certificate or certificate chain from a .pem file

$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw



#Add it to the trusted certificate stores of the vCenter and the ESXi servers

Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain

Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:

Get-VITrustedCertificate -VCenterOnly | `

Where-Object { $_.NotValidAfter -lt (Get-Date) } | `

Remove-VITrustedCertificate

2. Управление SSL-сертификатами компьютеров на сервере vCenter Server

Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).

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

Get-VIMachineCertificate -VCenterOnly

После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:

$csrParams = @{

Country="US"

Email="jdoe@vmware.com"

Locality="San Francisco"

Organization="My Company"

OrganizationUnit="PowerCLI"

StateOrProvince="California"

}

$csr = New-VIMachineCertificateSigningRequest @csrParams


$csr.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\vc.csr.pem" -Force

После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:

$vcCert = Get-Content "C:\Users\jdoe\Downloads\vc.cert.jdoe.pem" -Raw

Set-VIMachineCertificate -PemCertificate $vcCert

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

3. Управление SSL-сертификатами машин для серверов ESXi

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

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'

$certModeSetting = Get-AdvancedSetting "vpxd.certmgmt.mode" -Entity $vCenterConnection

Set-AdvancedSetting $certModeSetting -Value "custom"

После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.

$esxRequest = New-VIMachineCertificateSigningRequest `

-VMHost $vmhost `

-Country "US" `

-Locality "San Francisco" `

-Organization "My Company" `

-OrganizationUnit "PowerCLI" `

-StateOrProvince "California" `

-CommonName <ESXi host's FQDN> or <ESXi host's IP address>


$esxRequest.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\esx.csr.pem" -Force

Теперь, когда мы получим сертификат от центра сертификации, нужно выполнить 3 операции:

1. Выводим хост в режим обслуживания (maintenance mode) и удаляем его из vCenter:

$vmhost = Get-VMHost 'MyESXiHost' `

Set-VMHost -VMHost $vmhost -State Maintenance

Remove-VMHost $vmhost

2. Соединяемся с хостом ESXi напрямую, устанавливаем там сертификат и перезагружаем хост:

$esxConnection = Connect-VIServer $vmhost.Name `

-User 'My User' `

-Password 'My Password' `

-Force


$esxCertificatePem = Get-Content "C:\Users\jdoe\downloads\myesxcert.pem" -Raw

$targetEsxHost = Get-VMHost $vmhost.Name

Set-VIMachineCertificate -PemCertificate $esxCertificatePem -VMHost $targetEsxHost | Out-Null



Restart-VMHost $targetEsxHost



Disconnect-VIServer $esxConnection

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

Снова добавляем наш хост ESXi в vCenter:

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'


$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `

-Location (Get-Datacenter "My Datacenter")`

-User "My User" `

-Password "My Password"


$vmhost = Set-VMHost -VMHost $vmhost -State Connected

Ну и остальные идеи вы можете почерпнуть в документе PowerCLI User’s Guide.

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

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

• RVTools теперь использует VMware vSphere Management SDK 7.0U3.
• Новая вкладка vSource, на которой отображается информация о сервере, где исполняется веб-сервис SDK, который используется для сбора данных (это сервер vCenter или хост ESXi).
• Новая колонка Host UUID на вкладке vHost.
• Новые чекбоксы в разделе Health, которые включают/отключают сообщения о безопасности и производительности.
• Раньше колонка UUID заполнялась значениями SMBIOS UUID, которые не уникальны. Теперь там отображается уникальный 128-битный UUID.
• Улучшение производительности при обработке данных.
• На вкладке vHealth появились советы по улучшению производительности ввода-вывода и памяти.
• Исправления ошибок.

Также приведем основные улучшения RVTools с момента выпуска четвертой версии:

• Новая вкладка vUSB, отображающая хосты с присоединенными USB-устройствами.
• Новая вкладка vFileInfo с информацией обо всех файлах на датасторах vSphere (полная информация включается чекбоксом Get fileinfo detail information").
• Log4net обновлен до версии 2.0.12 (защита от уязвимости CVE-2018-1285).
• Отображение информации о том, является ли объект плейсхолдером резервной инфраструктуры VMware SRM.
• Новая колонка Virtual machine tags на вкладках vInfo, vCPU, vMemory, vDisk, vPartition, vCD, vFloppy, vNetwork, vSnapshot, vTools.
• Новая колонка вкладки vInfo: min Required EVC Mode Key.
• Новая колонка вкладки vMemory: Memory Reservation Locked To Max.
• Новые колонки вкладки vRP: Resource Pool path, Resource Pool tags, число ВМ в пуле ресурсов и object ID.
• Новые колонки вкладки vCluster: Cluster tags, custom attributes и object ID.
• Новые колонки вкладки vHost: число ВМ в пуле ресурсов, vSAN Fault Domain Name, Host tags, in Maintenance Mode и in Quarantine Mode.
• Новые колонки вкладки dvSwitch: Distributed VirtualSwitch tags, custom attributes и object ID.
• Новые колонки вкладки dvPort: Distributed VirtualSwitch Port Group tags и object ID.
• Новые колонки вкладки vDatastore: число ВМ в пуле ресурсов, Datastore tags, custom attributes и object ID.
• Новые колонки вкладки vNetwork: ipv4 и ipv6, NIC label, "Internal Sort Column".
• Новые колонки вкладки vDisk: Disk key, disk path, "Internal Sort Column".
• Новые колонки вкладки vPartition: "Internal Sort Column", Disk key.
• Новый чекбокс в настройках "Exclude tags" и параметр CLI -ExcludeTags.
• Объем отображается не в MB, а в MiB.
• Предупреждение о том, что данные собраны не со всех ВМ.

Скачать RVTools 4.3.1 можно по этой ссылке.

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

Сделано это было из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивается - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз о нем мы упоминали вот тут. Выглядел он тогда так:

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

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

Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.

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

stat -f /

Либо можно использовать также команду df -i.

Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.

Решением этой проблемы является только апгрейд вашей инфраструктуры на VMware vSphere ESXi 7.0 Update 3c.

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

Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.

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

Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.

Итак, для начала вам нужно остановить службы StarWind Virtual SAN:

• В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
• Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
• На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
• На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA

Далее открываем конфигурационный файл:

• На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
• На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg

Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).

Ну и, наконец, надо запустить службы StarWind VSAN:

• На StarWind VSAN для Windows: net start starwindservice
• На виртуальном модуле StarWind VSA: systemctl start StarWindVSA

Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:

И смотрим, какие настройки там выставлены:

Нас интересует:

• RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
• NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
• NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.

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

Компания VMware в конце января обновила свою облачную версию решения для аналитики лог-файлов и мониторинга инфраструктуры в облаке VMware vRealize Log Insight Cloud (January 2022 Update).

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

Давайте посмотрим на новые возможности январского обновления Log Insight Cloud:

1. Разделы Index и Non-Index Log Partitions

Теперь в продукте появилась поддержка безындексных разделов (non-index Log Partitions), что позволяет увеличить масштабируемость решения для публичных многооблачных сред, где происходит мониторинг огромного количества объектов (AWS, Microsoft Azure, Google Cloud Platform), а также облаков на базе VMware Cloud (VMware on AWS, Azure VMware Solutions, Google Cloud VMware Solutions, Oracle Cloud VMware Solutions). Также это доступно и для онпремизной инфраструктуры на базе VMware SDDC (software-defined-datacenter).

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

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

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

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

2. Визуализация потребления хранилищ

Настройка логирования - это всегда компромисс между объемом собираемых и анализируемых данных и трат на их хранение. С помощью функций Ingestion and Storage Summary в реальном времени можно наблюдать за тем, как разделы заполняются логами и с какой скоростью, в соответствии с опциями, которые вы задали для них. На дэшборде видны наиболее потребляющие дисковое пространство разделы:

3. Функции Cloud Native Collector

Cloud Native Collector - это Docker-контейнер, который можно установить в любом облаке. Он предоставляет функции агрегации логов и управления конфигурациями логирования в части их форвардинга в систему vRealize Log Insight Cloud. Это позволяет собирать логи откуда угодно, без ограничений по хранимым емкостям.

Более подробно о новом релизе VMware vRealize Log Insight Cloud от января 2022 года можно узнать в Release Notes.

На прошедшей в конце прошлого года конференции VMworld 2021 компания VMware объявила о выпуске новой версии продукта vRealize Operations 8.6, который также включал в себя релиз облачной версии Operations Cloud. Напомним, что vROPs - это решение для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах.

На днях компания VMware сделала обновление облачной версии vRealize Operations Cloud, давайте посмотрим, что там появилось нового:

1. Выбор региона размещения сервисов vROPs Cloud

Теперь пользователь может выбрать один из восьми географических регионов (см. карту VMware Global Infrastructure Availability Map), где будут физически размещены сервисы vRealize Operations Cloud.

2. Покупка решения прямо из интерфейса

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

Можно купить либо отдельные подписки на облачные продукты Operations, Automation, Log Insight и Network Insight, либо взять пакет подписок в рамках предложения vRealize Cloud Universal:

3. Удаление дочерних объектов в соответствии с политикой

Теперь политика Deleted Objects retention применяется и ко всем дочерним объектам, которые зависят от Adapter instance. Это позволяет не оставлять не привязанные ни к чему дочерние экземпляры адаптеров при удалении родительского:

Также можно при удалении инстанса поставить галочку "Delete related objects", чтобы удалить все объекты, исторические данные, назначения пользователей и прочие сопутствующие вещи.

Больше подробностей об обновлении VMware vRealize Operations Cloud приведено в Release Notes. Пробную версию этого решения на 30 дней можно запросить тут. Также можете поработать с этим продуктом в виртуальной лаборатории по этой ссылке.

Компания VMware в конце января объявила о том, что ее сервис Skyline доступен через партнерскую сеть облачных сервис-провайдеров (Cloud Providers, они же участники программы VCPP), которые предоставляют свои услуги, используя платформу Cloud Partner Navigator (CPN). Напомним, что это решение предназначено для проактивного получения рекомендаций по технической поддержке продуктов линейки VMware vSphere, включая vSAN. В частности, с помощью VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут делать заключения о правильности работы виртуальной инфраструктуры и вырабатывать основные рекомендации по ее улучшению.

С помощью Skyline Advisor пользователи могут получать проактивную аналитику для своей виртуальной инфраструктуры в целях идентификации текущих и будущих проблем. Он поддерживает не только продукты vSphere, vSAN, NSX, vROps и Horizon, но и среды Cloud Foundation и Dell EMC VxRail.

Все партенры, имеющие доступ к VMware Partner Connect с действующим соглашением VMware Cloud Provider Program agreement, могут получить доступ к поддержке уровня Production. А начиная с 27 января, у них уже есть доступ к сервисам VMware Skyline.

Для сервис-провайдеров тут будет 2 больших плюса:

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

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

• VMware vSphere
• VMware NSX
• VMware vSAN
• VMware vRealize Operations
• VMware vRealize Automation
• VMware Cloud Foundation.

Также сервис распознает Skyline инфраструктуру VxRail и инсталляции типа VMware Validated Design.

Если вы являетесь сервис-провайдером VCPP и уже имеете доступ к Cloud Partner Navigator, то сервис доступен в разделе "Services Available for Provisioning".

Как знают многие администраторы, еще в прошлом году в ESXi 7 Update 2 компания VMware стала убирать различные настройки из основного конфигурационного файла esx.conf. Кстати, и не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет - они переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli.

То же самое произошло и с NTP - теперь настройки времени, хранящиеся в /etc/ntp.conf (для NTP) и /etc/ptp.conf (для PTP), недоступны для редактирования через файлы конфигураций. Кстати, если вы не знаете, чем NTP отличается от PTP, у нас есть отличная статья на эту тему (а вот тут - о поддержке PTP в vSphere 7 Update 2).

Более того, теперь все файлы каталога /etc помечены как только для чтения и не сохраняют своих изменений при перезагрузке!

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

• Получение настроек времени

# esxcli system ntp get
# esxcli system ptp get

• Установка настроек времени

# esxcli system ntp set
# esxcli system ptp set

Если вы хотите узнать список всех конфигурационных файлов, которыми теперь заведует ConfigStore, можно выполнить следующую команду в консоли ESXi:

# configstorecli files get

Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.

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

Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)

Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.

Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:

• vSphere ESXi 7 Update 3c Release Notes
• vCenter Server 7 Update 3c Release Notes
• vSphere 7 Update 3c – List of Known Issues and Workarounds

О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.

Недавно VMware и издательство O'Reilly выпустили бесплатную для всех электронную книгу "Production Kubernetes - Building Successful Application Platforms", которая рассказывает о применении линейки решений VMware Tanzu для контейнерной виртуализации приложений в рамках производственных кластеров Kubernetes. Написана она авторами Josh Rosso, Rich Lander, Alexander Brand и John Harris.

В Enteprise-инфраструктуре перед администраторами контейнеров и серверов виртуализации встают следующие задачи:

• Удовлетворение все растущего спроса разработчиков на размещение контейнеров приложений в кластерах.
• Уход от механизма тикетов на выполнение задач DevOps путем предоставления разработчикам средств самообслуживания и API-механизмов для решения собственных задач.
• Предотвращение ситуации, когда все будет завязано на одного вендора (например, только на его API).
• Соответствие регуляторным требованиям, которые часто требуют размещения приложений и данных только в онпремизной инфраструктуре.
• Поддержка железа для кластеров Kubernetes, а также виртуального датацентра на базе VMware vSphere.

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

Скачать книгу "Production Kubernetes - Building Successful Application Platforms" можно бесплатно по этой ссылке.

В прошлом году на VMworld 2021 компания VMware представила обновление продукта Workspace ONE Intelligence, который предназначен для для анализа поведения пользователей и устройств и выдачи рекомендации администраторам ИТ-инфраструктуры по применению тех или иных действий. На вход этого движка подаются данные об использовании устройств, приложений и данных пользователей, затем они агрегируются, анализируются, а потом для администраторов генерируются некоторые рекомендации и правила, которые можно применить для повышения эффективности инфраструктуры виртуальных ПК и приложений.

Тогда мы рассказали о новых возможностях этого продукта, а сегодня вкратце расскажем о том, какие основные его функции позволяют повысить безопасность пользовательской среды в рамках концепции Zero Trust Security, то есть когда никакие из систем предприятия по умолчанию не считаются 100% защищенными.

1. Мониторинг и отслеживание аномалий

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

2. Доверенная экосистема (Trust Network)

В дополнение к данным окружения платформы Workspace ONE (включая Workspace ONE UEM и Workspace ONE Access), данные могут быть дополнены средствами внешних систем, входящих в доверенную экосистему Trust Network.

Например, вы можете подключить систему VMware Carbon Black, которая также может встроиться в окружение Workspace ONE. Например, вот два виджета, которые отображают Threat Count и Threat Type от Carbon Black в консоли Workspace ONE Intelligence:

3. Автоматизации для работы с данными об угрозах

Вы можете настроить различные автоматизации для действий в ситуации наступления определенных угроз. К примеру, если решение Carbon Black обнаружило какое вредоносное ПО в системе, например, ransomware, то система может быть помещена на карантин, а в Slack будет отправлено сообщение, оповещающее о проблеме. Затем будет создан тикет в ServiceNow, а Workspace ONE UEM протэгирует опасный объект и поместит его на карантин:

4. Аналитика рисков устройств и пользователей

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

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

Весной 2020 года компания VMware объявила об интеграции своей платформы для виртуализации и доставки настольных ПК предприятия Horizon с решениями компании ControlUp, которая является технологическим партнером VMware.

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

Первый продукт, который поддерживает новый релиз - это решение Scoutbees. Оно позволяет мониторить доступность сетевых ресурсов (десктопы, приложения, компоненты VMware UAG и DNS и прочее) и оповещать администраторов о проблемах, с которыми сталкиваются пользователи. Путем анализа проблем (они могут и не подтвердиться на стороне клиента) - администраторы предпринимают определенные действия по улучшению соединений.

Scoutbees осуществляет синтетический мониторинг, то есть посылает запросы к удаленному ресурсу и получает не только ответ, но и метрики key performance indicators (KPI), которые могут использоваться для целей прогнозирования и анализа подозрительных активностей. Для анализа инфраструктуры виртуальных ПК вы можете подключить мониторинг компонентов VMware Unified Access Gateway (UAG) и Horizon Connection Server. Также решение может проактивно тестировать доступность веб-приложений, сетевых служб, DNS-серверов, файловых шар, принтеров и других ресурсов.

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

Вторая интеграция - это возможность использования решения Remote DX для мониторинга компьютеров удаленных пользователей. Это средство позволяет удаленно собрать информацию о скорости и качестве Wi-Fi соединения, а также производительности подключения пользователя к интернету. Вследствие этого администраторы могут делать скоринг пользователей по этому параметру и решать возникающие проблемы пользователей. Вот, например, у пользователя задержка (latency) составляет 219 миллисекунд между его устройством точкой доступа Wi-Fi. А между Horizon Client и его десктопом Horizon задержка равна 362 миллисекундам.

С использованием Remote DX администратор видит, что у пользователя относительно сильный сигнал Wi-Fi на уровне 81% и round-trip time (RTT), которое для гугла составляет 244 миллисекунды. А вот от роутера до гугла пользователь получает задержку 25 мс - это значит проблема в связи между устройством пользователя и его роутером.

По умолчанию решение Remote DX отображает только основные метрики, но собирает оно все, и их можно вывести для отображения в таблице:

Также можно использовать ControlUp Real-Time Console для вывода информации информации в колонках в соответствии с заранее сделанными пресетами:

Самая главная метрика здесь - это Client Device Score, которая дает администратору понять, все ли в порядке у пользователя с интернетом и доступом к удаленному десктопу в целом. Также есть и другие колонки, которые помогут вам понять, в чем дело, если у пользователя есть проблемы:

Более подробно об интеграции VMware Horizon и Remote DX рассказано вот в этой статье.

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

OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.

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

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

• VMware NSX-T 3.2 | 3.1 | 3.0 | 2.5 | 2.4
• VMware NSX Advanced Load Balancer
• VMware NSX for vSphere 6.x
• VMware Cloud Director 10 | 10.2 | 10.3
• VMware vRealize Operations Manager 8.1
• VMware vRealize Orchestrator 8.1
• VMware vSphere Integrated Containers
• VMware ESXi Virtual Appliance
• VMware Photon OS 3.0 (cloud-init)
• VMware Event Broker Appliance 0.7

Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.

Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:

Компания 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 можно по этой ссылке.

Компания 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-устройстве.