Дункан Эппинг опубликовал интересный пост, касающийся изменений в интерфейсе vSAN Data Protection, произошедших в новой версии пакета обновлений VMware vSphere 8 Update 3.

Впервые развернув vSphere/vSAN 8.0 U3, он сразу же начал искать интерфейс vSAN Data Protection. Он не смог его найти, но подумал, что это из-за использования какой-то странной альфа-версии продукта. Теперь, когда продукт вышел, эта функция должна быть доступна из коробки, верно?

Нет, не так. Вам нужно развернуть виртуальный модуль (Virtual Appliance), чтобы эта функция появилась в интерфейсе. Этот модуль можно найти в разделе «Drivers and Tools» в разделе загрузок vSphere Hypervisor, который находится по основными ссылками на дистрибутивы vSphere. Он называется «VMware vSAN Snapshot Service Appliance». Текущая версия называется «snapservice_appliance-8.0.3.0-24057802_OVF10.ova». Вам нужно развернуть этот OVA, при это настоятельно рекомендуется запросить для него DNS-имя и правильно зарегистрировать его. Автор возился с файлом hosts на VCSA и забыл добавить имя в локальный файл hosts на своем ноутбуке, из-за чего возникли странные проблемы.

Еще одна вещь, на которую стоит обратить внимание: документация предлагает загрузить сертификаты и скопировать текст для модуля. Это не то, что большинство из нас делает ежедневно. Вы можете просто открыть веб-браузер и использовать следующий URL «https://<имя вашего сервера vCenter>/certs/download.zip», чтобы загрузить сертификаты, а затем распаковать загруженный файл. Более подробную информацию можно найти здесь.

Внутри будут сертификаты, и если вы откроете сертификат в подходящем текстовом редакторе, вы сможете скопировать/вставить его в экран развертывания для OVA.

Теперь, когда вы развернули OVA и все правильно настроено, вы должны увидеть успешное выполнение задачи, а точнее две: загрузка плагина и развертывание плагина, как показано на следующем скриншоте.

Если вы получите сообщение об ошибке «error downloading plug-in», вероятно, это связано с одной из двух причин:

• Файлы DNS / Hosts настроены некорректно, в результате чего URL недоступен. Убедитесь, что вы можете разрешить URL.
• Отпечаток (thumbprint) сертификата был неправильно скопирован/вставлен. Здесь есть целый раздел по устранению этой проблемы.

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

Автор не хотел вручную создавать резервные копии каждого ESXi хоста, так как это не масштабируется. Вместо этого он создал PowerShell скрипт под названием vCenter ESXi Config Backup, который выполняет в автоматическом режиме.

Вы можете найти скрипт на его GitHub: https://github.com/thedxt/VMware#vcenter-esxi-config-backup.

Требования:

• Установленный VMware PowerCLI (вот документация от Broadcom о том, как это сделать)
• Установленный сертификат VMware vCenter. Пост "Установка сертификата VMware vCenter в Windows" описывает, как это сделать.

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

Скрипт vCenter ESXi config backup подключается к VMware vCenter, далее использует его для подключения к каждому ESXi хосту и последовательно создает резервную копию каждой конфигурации. Поскольку скрипт использует vCenter, вам не нужно включать SSH на каких-либо ESXi хостах для выполнения резервного копирования.

• По умолчанию, скрипт предполагает, что вы не подключены к vCenter, и запросит вас подключиться к vCenter. Вы можете изменить это поведение, если вы уже подключены к vCenter, установив опциональный параметр connected со значением Yes.
• Скрипт проверяет, существует ли указанная вами папка для резервного копирования. Если папка не существует, скрипт создаст ее.
• Затем скрипт получает все ESXi хосты в vCenter, подключается к каждому из них и создает резервную копию конфигурации. Скрипт сохраняет резервную копию в указанную вами папку.
• После завершения резервного копирования скрипт переименовывает файл резервной копии, добавляя к имени хоста установленную версию ESXi, номер сборки и дату резервного копирования.

Для использования скрипта необходимо предоставить несколько параметров. Первый параметр — vcenter, за которым следует FQDN-имя вашего vCenter. Второй параметр — folder, за которым следует расположение, куда вы хотите сохранить резервные копии конфигурации ESXi.

Вот пример запуска сценария:

esxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup"

Вот пример вывода этой команды:

Вот пример того, как должна выглядеть команда, если вы уже подключены к vCenter:

esxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup" -connected Yes

Вот пример вывода этой команды:

Недавно мы писали о новых возможностях пакета обновлений платформы виртуализации VMware vSphere 8 Update 3. Сегодня мы более детально рассмотрим, что нового там появилось в плане поддержки карт GPU.

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

Гетерогенные типы vGPU-профилей с разными размерами

В VMware vSphere мы можем назначить машине vGPU-профиль из набора заранее определенных профилей, чтобы предоставить ей определенную функциональность. Набор доступных vGPU-профилей появляется после установки NVIDIA vGPU менеджера/драйвера на уровне хоста в ESXi посредством vSphere Installation Bundle (VIB).

Эти vGPU-профили называются профилями типа C в случае, если профиль предназначен для интенсивной вычислительной работы, такой как обучение моделей машинного обучения. Существуют и несколько других типов vGPU-профилей, среди которых Q (Quadro) для графических рабочих нагрузок являются одними из самых популярных. Буквы «c» и «q» стоят в конце названия vGPU-профиля, отсюда и название этого типа.

В предыдущем обновлении vSphere 8 Update 2 мы могли назначать машине vGPU-профили, которые предоставляли поддержку различных видов функциональности, используя при этом одно и то же устройство GPU. Ограничением в этой версии vSphere было то, что они должны были быть vGPU-профилями одного и того же размера, например, те, которые заканчиваются на 8q и 8c. Здесь «8» представляет количество гигабайт памяти на самом GPU (иногда называемой framebuffer-памятью), которая назначена ВМ, использующей этот vGPU-профиль. Это значение может изменяться в зависимости от модели основного GPU.

При использовании GPU A40 или L40s мы можем иметь vGPU-профиль типа C, предназначенный для вычислительно интенсивной работы, такой как машинное обучение, и vGPU-профиль типа Q (предназначенный для графической работы), назначенные разным ВМ, которые делят один и тот же физический GPU на хосте.

Теперь в vSphere 8 Update 3 можно продолжать смешивать эти разные типы vGPU-профилей на одном физическом GPU, а также иметь vGPU-профили разного размера памяти, которые делят один и тот же GPU.

В качестве примера новой функциональности vSphere 8 Update 3: ВМ1 с vGPU-профилем l40-16c (для вычислительных нагрузок) и ВМ2 с vGPU-профилем l40-12q (для графических нагрузок) делят одно и то же устройство L40 GPU внутри хоста. Фактически, все вышеупомянутые виртуальные машины делят одно и то же физическое устройство L40 GPU.

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

Включение настроек кластера для DRS и мобильности ВМ с vGPU

В vSphere Client версии 8.0 U3 появились новые настройки кластера, которые предоставляют более удобный метод настройки расширенных параметров для кластера DRS. Вы можете установить ограничение по времени приостановки ВМ, которое будет допускаться для машин с vGPU-профилями, которым может потребоваться больше времени, чем по умолчанию, для выполнения vMotion. Время приостановки по умолчанию для vMotion составляет 100 секунд, но этого может быть недостаточно для некоторых ВМ с большими vGPU-профилями. Дополнительное время требуется для копирования памяти GPU на целевой хост. Вы также можете узнать оценочное время приостановки для вашей конкретной ВМ с поддержкой vGPU в vSphere Client. Для получения дополнительной информации о времени приостановки, пожалуйста, ознакомьтесь с этой статьей.

В vSphere 8 Update 3 появился более удобный пользовательский интерфейс для настройки расширенных параметров для кластера DRS, связанных с vMotion виртуальных машин.

Прежде чем мы рассмотрим второй выделенный элемент на экране редактирования настроек кластера ниже, важно понять, что vGPU как механизм доступа к GPU является одной из множества техник, которые находятся в "спектре проброса устройств" (Passthrough spectrum). То есть, vGPU на самом деле является одной из форм прямого доступа. Возможно, вы считали, что подходы прямого проброса и vGPU сильно отличаются друг от друга до настоящего времени, так как они действительно разделены в vSphere Client при выборе добавления нового PCIe-устройства к ВМ. Однако, они тесно связаны друг с другом. Фактически, vGPU ранее назывался "опосредованным пробросом" (mediated passthrough). Этот спектр использования прямого доступа различными способами показан здесь.

Именно поэтому в vSphere Client на выделенном участке экрана ниже используются термины «Passthrough VM» и «Passthrough Devices». Эти термины на самом деле относятся к виртуальным машинам с поддержкой vGPU – и таким образом, обсуждение касается включения DRS и vMotion для виртуальных машин с поддержкой vGPU на этом экране. vMotion не разрешен для виртуальных машин, использующих фиксированный прямой доступ, как показано на левой стороне диаграммы выше.

Новая функция интерфейса позволяет пользователю включить расширенную настройку vSphere под названием «PassthroughDrsAutomation». С включенной этой настройкой, при соблюдении правил по времени приостановки, виртуальные машины в этом кластере могут быть перемещены vMotion на другой хост по решению DRS. Для получения дополнительной информации об этих расширенных настройках DRS, пожалуйста, ознакомьтесь с этой статьей.

Доступ к медиа-движку GPU

Единый медиа-движок на GPU может использоваться виртуальной машиной, которая хостит приложение, которому требуется выполнять транскодирование (кодирование/декодирование) на GPU, а не на более медленном CPU, например, для видео-приложений.

В vSphere 8 Update 3 поддерживается новый vGPU-профиль для виртуальных машин, которым требуется доступ к медиа-движку внутри GPU. Только одна виртуальная машина может использовать этот медиа-движок. Примеры таких vGPU-профилей («me» означает media engine):

• a100-1-5cme (один срез)
• h100-1-10cme (два среза)

Более высокая скорость vMotion виртуальных машин с большими vGPU-профилями

Новые улучшения в vMotion позволяют нам увеличивать пропускную способность для сети vMotion со скоростью 100 Гбит/с до 60 Гбит/с для vMotion виртуальной машины, к которой подключен современный GPU (H100, L40S), что сокращает время vMotion. Это не относится к GPU A100 и A30, которые относятся к более старой архитектуре (GA100).

Новые технические документы и рекомендации по проектированию GPU с VMware Private AI Foundation with NVIDIA

Недавно были выпущены два важных публикации авторами VMware. Агустин Маланко Лейва и команда опубликовали решение VMware Validation Solution для инфраструктуры Private AI Ready Infrastructure, доступное здесь.

Этот документ предоставляет подробное руководство по настройке GPU/vGPU на VMware Cloud Foundation и многим другим факторам для организации вашей инфраструктуры для развертывания VMware Private AI.

Одним из ключевых приложений, которое будут развертывать в первую очередь в инфраструктуре VMware Private AI Foundation с NVIDIA, является генерация с дополненным извлечением или RAG. Фрэнк Деннеман и Крис МакКейн подробно рассматривают требования к безопасности и конфиденциальности и детали реализации этого в новом техническом документе под названием VMware Private AI – Privacy and Security Best Practices.

На прошлой неделе блогер Дункан Эппинг получил вопрос о vSAN Stretched Cluster, который заставил его задуматься. Человек, задавший этот вопрос, рассматривал несколько сценариев отказа, некоторые из которых Дункан уже рассматривал ранее. Вопрос, который ему задали, заключается в том, что должно произойти в следующем сценарии, показанном на диаграмме, когда разрывается связь между предпочтительным сайтом (Site A) и сайтом свидетеля (Witness):

Ответ, по крайней мере, он так думал, был прост: все виртуальные машины продолжат работать, или, иначе говоря, не будет никакого воздействия на работу vSAN. Во время теста, действительно, результат, который он зафиксировал, а также документированный в Stretched Clustering Guide и PoC Guide, был таким же: виртуальные машины продолжали работать. Однако, он обратил внимание, что когда эта ситуация происходит, и действительно связь между сайтом А и Witness теряется, свидетель почему-то больше не является частью кластера, что не то, что ожидалось. Причина, по которой он не ожидал этого, заключается в том, что если произойдет второй сбой, и, например, связь между сайтом А и сайтом B пропадет, это напрямую повлияет на все виртуальные машины. По крайней мере, так он думал.

Однако, когда был вызван этот второй сбой и отключена связь между сайтом А и сайтом В, Дункан увидел, что Witness снова появляется в кластере сразу же, а объекты свидетеля переходят из состояния «absent» в состояние «active», и, что более важно, все виртуальные машины продолжают работать. Причина, по которой это происходит, довольно проста: при запуске такой конфигурации у vSAN есть «leader» и «backup», и они каждый работают в отдельном домене отказа. И лидер, и резерв должны иметь возможность общаться с Witness для корректного функционирования. Если связь между сайтом А и Witness пропадает, то либо лидер, либо резерв больше не могут общаться со свидетелем, и свидетель исключается из кластера.

Так почему же свидетель возвращается к работе, когда вызывается второй сбой? Когда вызывается второй сбой, лидер перезапускается на сайте В (так как сайт А считается потерянным), а резерв уже работает на сайте В. Поскольку и лидер, и резерв снова могут общаться со свидетелем, свидетель возвращается к работе, и все компоненты кластера автоматически и мгновенно восстанавливаются. Это означает, что даже если связь между сайтом А и сайтом В прервана после того, как свидетель был исключен из кластера, все виртуальные машины остаются доступными, так как свидетель снова включается в работу кластера для обеспечения доступности рабочей нагрузки.

В мае этого года мы писали о том, что продукты семейства VMware EUC (End-User Computing) теперь будут поставляться под брендом Omnissa от KKR. 1 июля официально было объявлено о том, что компания получила полную самостоятельность и начинает поставку продуктов под своим брендом.

Вот что сказал об этом Shankar Iyer, CEO компании Omnissa:

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

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

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

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

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

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

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

Напомним, что продуктовый портфель компании теперь выглядит так (это больше не-VMware продукты):

В конце прошлого года компания VMware выпустила версию решения VMware Cloud Director 10.5.1, предназначенного для управления программно-определяемым датацентром сервис-провайдеров. Это был небольшой сервисный релиз продукта, а вот в vCD 10.6 появилось уже довольно много всего нового.

VMware Cloud Director 10.6 теперь доступен в составе предложения VCF (VMware Cloud Foundation), начиная с 27 июня 2024 года.

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

Основная платформа

Трехуровневая аренда

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

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

Этот инновационный подход позволяет облачным провайдерам принимать различные бизнес-модели, такие как:

• Создание субпровайдерских организаций, что способствует вложенной многоуровневой аренде внутри крупных корпоративных организаций, позволяя создавать отдельные административные иерархии для разных отделов или дочерних компаний.
• Перепродажа облачных услуг через партнеров или MSP (managed service providers).

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

Увеличенные лимиты

Этот выпуск значительно увеличивает максимальные параметры в нескольких областях платформы, таких как:

• Максимальное количество виртуальных машин на инстанс VMware Cloud Director увеличено до 55 000, независимо от состояния питания.
• Количество одновременно поддерживаемых удаленных консолей увеличено до 22 000.
• Максимальное количество пользователей, поддерживаемых платформой, увеличено до 300 000.
• Организационная модель для группы виртуальных датацентров (Org VDC) была переработана в трехуровневую структуру. В рамках этого нового дизайна субпровайдер теперь может управлять группами датацентров, которые могут вмещать до 2000 участников (ранее 16) и делиться сетями и каналами связи между ними.

Множественные снапшоты ВМ и vApp

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

Content Hub

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

Также была выпущена новая версия Content Hub Operator, которая работает нативно в кластере Kubernetes и использует протокол WebSocket для высокопроизводительной связи с VMware Cloud Director. Оператор также предоставляет отчеты о совместимости в реальном времени на портал арендатора, позволяя владельцам кластеров принимать информированные решения о времени обновления для обеспечения бесшовной интеграции с VMware Cloud Director.

Распределенный глобальный каталог

Он позволяет создать глобальную мультисайтовую облачную архитектуру, обеспечивая бесшовный доступ к каталогам через несколько сайтов VMware Cloud Director (VCD), предоставляя единый каталог для арендаторов, независимо от инстанса vCenter или инфраструктуры SDDC. Вы можете использовать независимые от поставщика решения для совместного хранения данных (такие как NetApp, Dell, vSAN и т.д.), чтобы реплицировать данные и обеспечить глобальную согласованность каталога.

Множественные протоколы IDP и локальные пользователи

VMware Cloud Director позволяет организациям использовать несколько протоколов поставщиков индентификации (IDP), включая LDAP, SAML и OpenId Connect (OIDC), для более комплексного подхода к аутентификации. Используя внешних поставщиков, вы можете воспользоваться последними достижениями в технологиях аутентификации. Стоит отметить, что локальные пользователи по-прежнему поддерживаются в текущем выпуске, их использование в производственной среде прекращается, но они будут полностью поддерживаться до следующего крупного выпуска VMware Cloud Director.

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

При развертывании шаблона ВМ на другом vCenter, используя VMware Cloud Director, система использует двухфазный подход для обеспечения эффективного развертывания. Изначально она пытается ускорить процесс путем клонирования шаблона ВМ напрямую, используя скорость и эффективность этого метода. Этот подход позволяет системе быстро создать новый инстанс ВМ без издержек на экспорт и импорт ВМ как OVF-файл. Однако, если операция клонирования сталкивается с любыми проблемами или ошибками, система автоматически переключается на более традиционный метод, используя экспорт/импорт OVF для развертывания ВМ. Этот резервный подход обеспечивает успешное завершение процесса развертывания, даже в случаях, когда клонирование может быть невозможным.

Улучшенное управление шифрованием

VMware Cloud Director 10.6 вводит несколько улучшений в функции управления шифрованием:

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

Поддержка vSAN 4.1 NFS

VMware Cloud Director 10.6 теперь включает поддержку vSAN 4.1 NFS, обеспечивая безопасное совместное использование файлов с аутентификацией Kerberos. Эта интеграция позволяет использовать vSAN 4.1 как надежное и безопасное хранилище, предоставляя дополнительную возможность для совместного использования файлов в вашей организации.

Устранение уязвимости CVE-2024-22272

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

Сеть

Поддержка IPv6 для узлов VMware Cloud Director

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

Индивидуальный монитор здоровья

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

Логирование балансировщика нагрузки Avi

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

WAF для Avi LB

Интеграция WAF (Web Application Firewall) с Avi LB и Cloud Director открывает новые возможности для клиентов по предоставлению дополнительных услуг своим конечным пользователям. Включение функций безопасности WAF в их портфель услуг позволяет обеспечить улучшенную защиту от веб-атак, повысить удовлетворенность клиентов и укрепить свои позиции на рынке.

С введением WAF появляются следующие преимущества:

• Улучшенная безопасность: WAF помогает защищаться от веб-атак, таких как SQL-инъекции и межсайтовый скриптинг (XSS), фильтруя входящий трафик и блокируя вредоносные запросы.
• Усиленное соответствие: WAF может помочь организациям соответствовать нормативным требованиям, предоставляя видимость веб-трафика и возможность блокировать определенные типы трафика или запросов.
• Увеличение доверия клиентов: предлагая WAF как дополнительную услугу, организации могут продемонстрировать свою приверженность безопасности и укрепить доверие своих клиентов.
• Конкурентное преимущество: WAF может стать ключевым отличием для организаций, стремящихся выделиться на переполненном рынке, так как обеспечивает дополнительный уровень безопасности и защиты.

Управление IP-адресами

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

IPsec VPN на шлюзах провайдеров и пограничных шлюзах

VMware Cloud Director расширил свои возможности IPsec VPN, включив установление туннеля на выделенных шлюзах провайдеров. Обновленная структура управления VPN теперь организована в трехуровневую модель, позволяя арендаторам, субпровайдерам и провайдерам настраивать и управлять VPN. С этой улучшенной возможностью провайдеры могут использовать Border Gateway Protocol (BGP) для контроля, какие IP-префиксы используют VPN. Более того, провайдеры и субпровайдеры могут автоматизировать настройку BGP для своих арендаторов, используя IP-пространства для управления сетевыми назначениями для публичного и частного адресации. Более того, провайдеры и субпровайдеры могут делегировать определенные конфигурации BGP своим арендаторам, предоставляя большую гибкость и контроль.

Новый UX для развертывания контроллеров Avi и NSX Cloud Connectors

VMware Cloud Director 10.6 вводит значительные улучшения в развертывание контроллеров Avi и NSX Cloud Connectors, тем самым увеличивая масштабируемость Avi LB. Новый пользовательский опыт позволяет администраторам легко добавлять больше облачных контроллеров к существующим контроллерам Avi, что увеличивает емкость и производительность. Кроме того, UX предоставляет ценные данные о потреблении ресурсов для контроллеров Avi, облаков NSX и пограничных шлюзов, что позволяет администраторам принимать информированные решения о выделении и оптимизации ресурсов.

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

VMware Cloud Director реализует прием и обработку логов, бесшовно подключаясь к VMware Aria Operations for Logs. Логи NSX Gateway Firewall и Distributed Firewall теперь автоматически обрабатываются VMware Aria Operations for Logs, предоставляя легкий доступ к этим логам через портал арендатора. Эта интеграция позволяет арендаторам быстро находить конкретные события, используя фильтры и временные диапазоны, и экспортировать логи в CSV-файлы для дальнейшего анализа и отчетности.

Object Storage Extension 3.1

В версии расширения VMware Cloud Director Object Storage Extension 3.1 появились следующие новые функции:

• Поддержка MinIO для внешних кластеров Kubernetes.
• Пересылка клиентских IP для настройки доступа к бакетам.
• Улучшенный интерфейс резервного копирования и восстановления Kubernetes для лучшей видимости и управления.
• Обновления OSIS (Object Storage Interoperability Service) для совместимых с S3 поставщиков хранилищ и асинхронного включения арендаторов.

Загрузите OSE 3.1 отсюда и прочитайте документацию по OSE 3.1 здесь.

Несколько полезных ресурсов о VMware Cloud Director 10.6

• Начните с VMware Cloud Director 10.6, загрузив последнюю версию отсюда.
• Для получения подробной информации о том, как использовать и настраивать VCD 10.6, ознакомьтесь с официальной документацией здесь.
• Для получения дополнительных ресурсов и информации о VCD посетите специальную страницу VMware Cloud Director на сайте vmware.com здесь.
• Для просмотра руководства по API прочитайте старое руководство по API здесь и руководство по OpenAPI здесь.

Недавно мы писали о новых возможностях обновленной версии платформы VMware vSphere 8.0 Update 3, а также о том, что нового появилось в плане основных функций хранилищ (Core Storage). Сегодня мы расскажем о новой версии решения VMware vSphere IaaS Control Plane 8.0.

Для начала - что это за решение? VMware внедрила декларативный API в vSphere, чтобы обеспечить современный опыт IaaS для потребителей облачных услуг. Решение vSphere IaaS Control Plane основывается на работе, проделанной в рамках инициативы vSphere with Tanzu, и расширяет её новым набором возможностей IaaS.

Давайте посмотрим, что нового появилось с выпуском vSphere 8 Update 3.

Независимая служба TKG Service

VMware представляет независимую службу TKG Service, которая отделена от vCenter и реализована как основная служба Supervisor Service. Это позволит выпускать асинхронные обновления сервиса и предоставлять новые версии Kubernetes быстрее, чем когда-либо.

Администраторы смогут обновлять TKG Service без необходимости обновлять Supervisor или vCenter, чтобы без проблем получать и использовать новые версии Kubernetes. Эти версии затем могут быть использованы непосредственно потребителями услуг.

Local Consumption Interface (LCI)

Интерфейс потребления облака (Cloud Consumption Interface, CCI) в Aria Automation предоставляет пользовательский интерфейс для создания виртуальных машин, кластеров TKG, балансировщиков нагрузки и запросов постоянных томов (Persistent Volume Claims).

Этот интерфейс теперь доступен в vCenter для каждого отдельного пространства имен. Пользовательский интерфейс поддерживает сложные спецификации для виртуальных машин и кластеров TKG, автоматически генерируя YAML для пользователей, которые хотят взаимодействовать с API напрямую. Интерфейс виртуальной машины поддерживает создание секретов и configmap для хранения конфигурации облака для настройки экземпляра виртуальной машины. Мастер создания кластеров расширен для поддержки сложных типов кластеров, которые могут включать смешанные рабочие узлы с конфигурациями GPU и без GPU.

Автомасштабирование для кластеров Kubernetes

VMware представила автоматическое масштабирование для кластеров Kubernetes с использованием Cluster Autoscaler. Это позволит кластерам Kubernetes соответствовать текущим потребностям, уменьшать количество узлов при низкой загрузке и увеличивать их количество при росте запросов. Рабочие узлы будут автоматически добавляться, когда ресурсов недостаточно для выполнения планирования подов.

Cluster Autoscaler может быть установлен как стандартный пакет с использованием kubectl или tanzu cli. Версия пакета должна соответствовать минорным версиям Kubernetes, например, чтобы установить пакет на кластер Kubernetes версии v1.26.5, необходимо установить пакет Cluster Autoscaler версии v1.26.2.

Минимально требуемая версия для Cluster Autoscaler — v1.25.

Поддержка растянутых кластеров vSAN Stretched Cluster

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

Основное внимание следует уделить доступности etcd, который является основной базой данных, хранящей все данные кластера Kubernetes. Etcd использует механизм кворума, что означает, что для его работы необходимо, чтобы более половины реплик были доступны в любое время. Поэтому нет смысла распределять нечетное количество виртуальных машин с Control Pane (CP) по двум сайтам. Вместо этого, для развертывания Active/Active, VMware рекомендует:

• Три виртуальные машины CP Supervisor (SV CP) должны быть размещены на одном сайте, при этом этот сайт может быть любым из двух, поскольку оба сайта активны.
• Все виртуальные машины CP любого кластера TKG должны быть размещены на одном сайте, который может быть любым из двух.

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

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

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

Автоматическая ротация сертификатов Supervisor

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

Аларм сработает только в случае, если процесс автоматического обновления не удастся, и это будет видно в интерфейсе vCenter. По умолчанию процесс попытается обновить сертификат снова через 12 часов. Как только замена будет успешной, алерт исчезнет.

Пользователи также могут решить заменить сертификат вручную.

Расширенная конфигурация класса виртуальных машин (VM Class Expanded Configuration)

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

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

Резервное копирование и восстановление кластера

Velero теперь является основным сервисом, включенным в Supervisor. Этот сервис координирует резервное копирование и восстановление как кластера Supervisor, так и любых развернутых кластеров TKG. Velero необходимо устанавливать на отдельные кластеры TKG через CLI. Резервное копирование и восстановление также выполняются через CLI. Резервное копирование и восстановление Supervisor осуществляется через интерфейс vCenter.

Сервис виртуальных машин (VM Service) – резервное копирование и восстановление виртуальных машин

Служба VM Service теперь включает возможность резервного копирования и восстановления виртуальных машин с использованием любого программного обеспечения VMware Advanced Data Protection. Этот метод не требует изменений в вашем инструменте резервного копирования или специальной конфигурации. Резервное копирование можно выполнять на уровне виртуальных машин или для всего пространства имен. Для пространства имен вы просто указываете пул ресурсов, который поддерживает пространство имен в vCenter.

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

Виртуальные машины, развернутые с использованием VM Service, теперь сохраняют в полях Extra-Config всю информацию, необходимую для воссоздания метаданных Supervisor. Этот процесс регистрации автоматический и происходит при восстановлении. Если автоматическая регистрация по какой-либо причине не удается, например, из-за отсутствия политики хранения или класса виртуальных машин, доступен API для ручного запуска регистрации после устранения проблемы.

Недавно мы писали о выходе большого обновления VMware vSphere 8 Update 3, а несколько дней назад пользователи стали сталкиваться с ошибкой при попытке наката обновления. Текст ошибки выглядит так:

Pre-install failed for vmidentity:Expand

Выглядит это как-то так (только вместо vpxd написано vmidentity):

При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.

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

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

2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store TRUSTED_ROOTS --alias <Alias> --output /var/tmp/non_ca_ssoserver.crt

4. Удалите сертификат из хранилища VECS.
Примечание: замените <Alias> на идентификатор псевдонима, определенный на шаге 2

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias> -y

5. Повторно выведите список сертификатов и убедитесь, что сертификат удален

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'

Теперь можно продолжить обновление vCenter.

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

Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).

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

Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.

Ключевые улучшения

• Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
• Новая спецификация vVols VASA 6
• Кластеризация VMDK для NVMe/TCP
• Ограничение максимального количества хостов, выполняющих Unmap
• Поддержка NFS 4.1 Port Binding и nConnect
• Дополнительная поддержка CNS/CSI для vSAN

vVols

Поддержка растянутого кластера хранилища vVols на SCSI

Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.

Почему это заняло так много времени?

Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.

Сценарии отказа и восстановления

• Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
• PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
• Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.

Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.

Требования

• Хранилище SCSI (FC или iSCSI)
• Макс. время отклика между хостами vSphere — 11 мс
• Макс. время отклика массива хранения — 11 мс
• Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
• Один vCenter (vCenter HA не поддерживается с vVols)
• Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC

Дополнительная поддержка UNMAP

Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.

Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.

Возврат пространства в хранилищах виртуальных томов vSphere описан тут.

Кликните на картинку, чтобы посмотреть анимацию:

Поддержка кластеризации приложений на NVMe-oF vVols

В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.

Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.

Обновление отчетности по аутентификации хостов для VASA Provider

Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.

Гранулярность хостов Storage Provider для vVols

С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.

NVMe-oF

Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP

В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.

Поддержка NVMe Cross Namespace Copy

В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.

Кликните на картинку, чтобы посмотреть анимацию:

VMFS

Сокращение времени на расширение EZT дисков на VMFS

В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.

Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.

Кликните на картинку для просмотра анимации:

Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore

В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.

Кликните на картинку для просмотра анимации:

По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.

См. статью Space Reclamation on vSphere VMFS Datastores.

Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>

Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:

PSA

Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)

VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.

Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.

Кликните на картинку, чтобы посмотреть анимацию:

NFS

Привязка порта NFS v4.1 к vmk

Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.

См. статью "Настройка привязки VMkernel для хранилища данных NFS 4.1 на хосте ESXi".

Поддержка nConnect для NFS v4.1

Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.

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

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

Максимальное количество соединений на сессию по умолчанию ограничено "4", однако его можно увеличить до "8" с помощью продвинутого параметра NFS:

esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
esxcfg-advcfg -g /NFS41/MaxNConnectConns

Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.

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

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>


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

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

Кликните на картинку, чтобы посмотреть анимацию:

CNS/CSI

Поддержка 250 файловых томов для vSAN ESA

В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).

Поддержка файловых томов в топологии HCI Mesh в одном vCenter

Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.

Поддержка CNS на TKGs на растянутом кластере vSAN

Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.

Миграция PV между несвязанными datastore в одном VC

Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.

Поддержка CNS на vSAN Max

Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.

На днях компания VMware в составе Broadcom выпустила очередной пакет обновлений своей флагманской платформы виртуализации - VMware vSphere 8.0 Update 3. vSphere 8 Update 3 улучшает управление жизненным циклом, безопасность и производительность, включая поддержку двойных DPU и улучшенную настройку виртуального оборудования.

Калькулятор лицензий для VCF, VVF и vSAN позволяет вводить данные о примерных конфигурациях виртуальной среды для проведения различных симуляций с целью определения необходимых подписных лицензий для VCF, VVF и vSAN. Более подробная информация об этом процессе изложена в KB 96426.

Не так давно VMware создала калькулятор лицензий, чтобы пользователи могли ознакомиться с новым упрощённым портфелем подписок (напомним, что perpetual лицензий больше нет) для решений с VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF) и VMware vSAN. Этот калькулятор можно использовать для симуляции различных сценариев лицензирования. Перед использованием калькулятора обратитесь к статье базы знаний KB 95727, чтобы узнать основы и принципы лицензирования продуктов VCF, VVF и vSAN.

Как использовать калькулятор лицензий

Необходимые условия:

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

При использовании шаблона CSV, пожалуйста, учтите следующие правила:

1. Не переименовывайте колонку ID, так как на неё ссылается скрипт.
2. Каждая строка представляет собой отдельный кластер vSphere и/или vSAN.

Введите данные для каждого из идентификаторов колонок по порядку в каждой строке. Описания идентификаторов колонок и примеры данных приведены в таблице ниже.

Инструкции по использованию калькулятора VCF/VVF

# Подключите исходную функцию

. ./vcf-vvf-calculator.ps1

# Пример использования калькулятора для VCF

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF

# Пример использования калькулятора для VVF

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF

# Пример использования калькулятора для VCF и экспорт результатов в CSV

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VCF - Csv

# Пример использования калькулятора для VVF и экспорт результатов в CSV

Get-VCFandVVFCalculator -InputFile sample-input.csv -DeploymentType VVF - Csv

Пример вывода

Вот пример вывода после использования калькулятора лицензий для VVF и vSAN. Обратите внимание, что внизу вывода указано общее количество требуемых лицензий на ядра VVF и TiB vSAN.

В таблице ниже описаны все колонки в разделах VVF/VCF Compute и vSAN:

Загрузить калькулятор лицензий VMware Cloud Foundation, VMware vSphere Foundation и VMware vSAN можно по этой ссылке.

Решение VMware Cloud Foundation Instance Recovery предоставляет собой руководство по восстановлению экземпляра VMware Cloud Foundation (VCF) с нуля до полностью работоспособной среды. Процесс включает подробные инструкции по восстановлению всего экземпляра VCF, включая управляющий домен и домены рабочей нагрузки VI, где необходимо восстановить все компоненты.

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

Сценарии использования

Примеры сценариев, когда вам может понадобиться этот процесс:

• Полный сбой площадки
• Восстановление после атаки вредоносного ПО или вымогателей (Ransomware)
• Катастрофическая логическая порча данных

Это особенно важно для отраслей, которые должны соблюдать нормативные требования (такие как Акт о цифровой операционной устойчивости (DORA) в Европейском Союзе).

Немного о DORA

DORA — это регламент Европейского Союза (ЕС), вступивший в силу 16 января 2023 года, который создал обязательную, всеобъемлющую систему управления рисками информационных и коммуникационных технологий (ИКТ) для финансового сектора ЕС.

DORA устанавливает технические стандарты, которые финансовые учреждения и их критически важные поставщики технологий третьих сторон должны внедрить в свои ИКТ системы до 17 января 2025 года.

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

Хотя DORA является европейским регламентом, его действия распространяются на компании, работающие в ЕС, независимо от места нахождения их штаб-квартиры. Более того, DORA является примером регламента, который станет более распространенным в других юрисдикциях в ближайшие годы.

Восстановление экземпляра VCF — это не просто на бумаге

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

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

Краткое описание решения

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

• Перестройка/ребилд хостов VMware vSphere с использованием того же или нового оборудования на основе данных, извлеченных из резервной копии инвентаря VCF SDDC Manager
• Выполнение частичного развертывания VCF
• Восстановление экземпляров VMware vCenter и NSX Manager, а также SDDC Manager
• Реконструкция кластеров vSphere, включая их сетевые конфигурации и настройки
• Восстановление NSX Edges
• Восстановление рабочих нагрузок (виртуальных машин)
• Восстановление настроек рабочих нагрузок (группы DRS, теги vSphere и местоположения инвентаря)

Временная шкала восстановления VMware Cloud Foundation Instance Recovery

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

• 3 домена рабочих нагрузок VI
• Домен VI 1 и домен VI 2 находятся в том же домене единого входа vCenter SSO, что и домен управления. Они находятся в режиме расширенной связи (Enhanced Link Mode, ELM).
• Используется только версия VMware Cloud Foundation 5.x. Домен VI 3 находится в изолированном домене единого входа vCenter (SSO).
• Шаблон восстановления для домена рабочих нагрузок VI в том же домене SSO можно расширить, если к домену управления vCenter подключены дополнительные домены рабочих нагрузок VI.

Автоматизация с помощью PowerShell

Автоматизация представлена в виде модуля PowerShell под названием VMware.CloudFoundation.InstanceRecovery, являющимся комплексным набором командлетов, который упрощает рутинные процессы и уменьшает вероятность ошибок в процессе реконструкции потенциально сложного и большого программно-определяемого центра обработки данных.

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

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

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

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

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

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

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

Известный блоггер Эрика Слуф опубликовал интересное видео, посвященное обеспечению высокой доступности и восстановлению после сбоя в кластере NSX-T Management Cluster.

В этом видео Эрик демонстрирует эти концепции в действии, рассматривая различные сценарии отказов и подробно обсуждая стратегии аварийного восстановления. Вы можете получить копию оригинального файла Excalidraw и презентационные слайды в форматах PDF и PowerPoint на GitHub.

Введение

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

Обзор кластера управления NSX-T

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

Высокая доступность в кластере управления NSX-T

1. Поддержание кворума

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

2. Отказы узлов и их влияние

• Отказ одного узла: кластер продолжает работать нормально с двумя узлами.
• Отказ двух узлов: кластер теряет кворум, интерфейс NSX Manager становится недоступным. Управление через CLI и API также будет невозможно.

Стратегии восстановления

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

1. Развертывание нового управляющего узла

• Разверните новый управляющий узел как четвертый член существующего кластера.
• Используйте команду CLI detach node <node-uuid> или API-метод /api/v1/cluster/<node-uuid>?action=remove_node для удаления неисправного узла из кластера.
• Эту команду следует выполнять с одного из здоровых узлов.

2. Деактивация кластера (по желанию)

• Выполните команду deactivate cluster на активном узле для формирования кластера из одного узла.
• Добавьте новые узлы для восстановления кластера до конфигурации из трех узлов.

Лучшие практики для аварийного восстановления

1. Регулярные резервные копии

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

2. Географическая избыточность

• Развертывайте NSX Manager на нескольких площадках для обеспечения географической избыточности.
• В случае отказа одной площадки другая может взять на себя операции управления с минимальными перебоями.

Проактивный мониторинг

• Используйте встроенные инструменты мониторинга NSX-T и интегрируйте их с решениями сторонних производителей для постоянного мониторинга состояния кластера управления.
• Раннее обнаружение проблем может предотвратить серьезные сбои и уменьшить время простоя.

Площадка аварийного восстановления

• Подготовьте площадку для аварийного восстановления с резервными NSX Manager, настроенными для восстановления из резервных копий.
• Такая настройка позволяет быстро восстановить и обеспечить непрерывность работы в случае отказа основной площадки.

Заключение

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

Для более детального изучения технических деталей ознакомьтесь с следующими ресурсами:

• Документация VMware NSX-T Data Center
• Резервное копирование и восстановление VMware Cloud Foundation
• Кластер NSX Manager не работает или недоступен, если все узлы кластера NSX Manager вышли из строя или большинство узлов не работает
  

Недавно Дункан Эппинг выступал с докладом на конференции VMUG в Бельгии, где была тема «Инновации в VMware от Broadcom». В ходе доклада он кратко изложил процесс и различные типы инноваций, а также то, к чему это может привести. Во время сессии он рассмотрел три проекта, а именно vSAN ESA, Distributed Services Engine и проект, над которым сейчас работают, под названием Memory Tiering.

Memory Tiering — это очень интересная концепция, которая впервые была публично представлена на конференции VMware Explore несколько лет назад как потенциальная будущая фича гипервизора. Вы можете задаться вопросом, зачем кому-то захочется ранжировать память, ведь влияние этого процесса на производительность может быть значительным. Существует несколько причин для этого, одна из которых — стоимость памяти. Еще одна проблема, с которой сталкивается индустрия, заключается в том, что емкость (и производительность) памяти не росли такими же темпами, как емкость CPU, что привело к тому, что во многих средах память стала узким местом. Иными словами, дисбаланс между процессором и памятью значительно увеличился. Именно поэтому VMware запустила проект Capitola.

Когда обсуждался проект Capitola, большинство внимания было уделено Intel Optane, и большинство интересующихся знает, что с этим случилось. Некоторые думали, что это также приведет к закрытию проекта Capitola, а также технологий ранжирования и объединения памяти. Но это совершенно не так: VMware продолжает активно работать над проектом и публично обсуждает прогресс, хотя нужно знать, где искать эту информацию. Если вы посмотрите эту сессию, станет ясно, что существует множество усилий, которые позволят клиентам ранжировать память различными способами, одним из которых, конечно, являются различные решения на базе CXL, которые скоро появятся на рынке.

Один из способов — это Memory Tiering с помощью карты ускорителя CXL, по сути, это FPGA, предназначенная исключительно для увеличения емкости памяти, аппаратной разгрузки техник ранжирования памяти и ускорения определенных функций, где память имеет ключевое значение, таких как, например, vMotion. Как упоминалось в сессии SNIA, использование карты ускорителя может привести к сокращению времени миграции на 30%. Такая карта ускорителя также открывает другие возможности, например, memory pooling, чего клиенты просили с тех пор, как в VMware создали концепцию кластера.

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

Именно здесь вступают в игру технологии VMware. На VMworld в 2021 году, когда был представлен проект Capitola, команда VMware также поделилась результатами последних тестов производительности, и было показано, что снижение производительности составило около 10% при использовании 50% оперативной памяти (DRAM) и 50% памяти Optane. Эта демонстрация показывает истинную мощь VMware vSphere, а также техник ранжирования памяти и ускорения (проект Peaberry).

В среднем снижение производительности составило около 10%, при этом примерно 40% виртуальной памяти было доступно через ускоритель Peaberry. Обратите внимание, что tiering полностью прозрачен для приложения, поэтому это работает для всех типов рабочих нагрузок. Важно понимать, что поскольку гипервизор уже отвечает за управление памятью, он знает, какие страницы являются "горячими", а какие "холодными", а это значит, что он может определить, какие страницы можно переместить на другой уровень, сохраняя при этом производительность.

В общем, ждем больше интересной информации от VMware на эту тему!

На сайте проекта Sample Exchange появилась утилита vKaan - vSphere Health Check - решение для управления виртуальной средой, предназначенное для поддержания конфигураций инсталляций VMware vSphere. Пакет vKaan позволяет отслеживать конфигурации Cluster HA и DRS и идентифицировать различающиеся объекты. Он также выявляет нарушения правил vSphere DRS и генерирует оповещения. Идентифицируя нарушения правил, он помогает обеспечить стабильность, эффективность и соответствие вашей среды vSphere желаемому состоянию.

Требования к системе Aria Operations

• Для интеграции с пакетом управления версия vSphere API должна быть выше 8.0.1.0 (версии vSphere 7.x не поддерживаются).
• Версия Aria Operations Manager должна быть выше 8.10.x.

Требования к правам пользователя Aria Operations Manager

Сервисная учетная запись для Aria Operations должна иметь разрешение только на чтение (read-only) с выбранной опцией распространения на дочерние объекты (Propagate to children) в vCenter Server.

Руководство по установке

Инструкции по установке и развертыванию:

• Скачайте файл "vKaan - vSphere Health Check.zip" и извлеките его в папку.
• Установите файл "vKaan - vSphere Health Check-1.x.x.x.pak" через меню Data Sources > Integration > Repository.
• Импортируйте файл "vKaan - Cluster Configuration Views.xml" из меню Environment > Views.
• Добавьте ваш vCenter Server в vKaan через меню Data Sources > Integrations > Repository.
• После того как vKaan MP завершит сбор данных, вы сможете открыть представление "vKaan - Cluster Configuration Summary Dashboard".

Скачать vKaan - vSphere Health Check можно по этой ссылке.

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

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

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

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

Обновления удобства использования VMmark 4:

• Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
• Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
• Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
• Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
• Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
• Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
• Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
• Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

• NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
• SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
• DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
• Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
• Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

• vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
• Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
• Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
• Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

Скачать VMware VMmark 4.0 можно по этой ссылке.

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

Это видео представляет собой углубленное обсуждение передовых методов управления емкостью в среде VMware Aria и Tanzu. Ведущие Brandon Gordon и Nico Guerra делятся опытом и знаниями о различных аспектах управления емкостью, начиная с определения ключевых терминов и понятий, таких как общая емкость, резерв под отказоустойчивость (HA), буфер, накладные расходы, использование, спрос и т.д. Особое внимание уделяется предсказательной аналитике, которая использует AI для анализа емкости и рекомендаций по оптимизации ресурсов.

Ключевые моменты видео включают:

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

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

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

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

• Tanzu Kubernetes Grid (TKG)
• Tanzu Application Service (TAS)
• Tanzu Mission Control (TMC)
• Tanzu Observability
• Tanzu Application Catalog (TAC)
• Spring Boot

Многие продукты и технологии, которые вы знали ранее в продуктовом портфеле VMware (см. ниже о Wavefront или Cloud Foundry), были заведены под зонтик Tanzu (уже в составе Broadcom), который объединяет множество интересных направлений. Например, в состав экосистемы Tanzu входит решение Greenplum, которое представляет собой мощную и масштабируемую аналитическую базу данных с открытым исходным кодом, разработанную для выполнения сложных запросов и обработки больших объемов данных.

Кстати, посмотрите, как изменилась стоимость компании Broadcom, поглотившей VMware, с момента консолидации активов последней, в состав которых входят и решения Tanzu:

Основные компоненты VMware Tanzu

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

1. Tanzu Kubernetes Grid (TKG)

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

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

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

• Единый дистрибутив Kubernetes
  TKG предоставляет готовый к использованию дистрибутив Kubernetes, который включает все необходимые компоненты для развертывания и управления кластерами. Это обеспечивает консистентность среды разработки и эксплуатации в различных окружениях.
• Мультиоблачная поддержка
  TKG поддерживает развертывание в различных облачных средах, включая AWS, Azure, Google Cloud, а также в локальных дата-центрах на базе vSphere. Это позволяет организациям выбирать наилучшее окружение для своих приложений.
• Автоматизация управления кластерами
  TKG автоматизирует многие аспекты управления кластерами Kubernetes, включая развертывание, обновление, масштабирование и мониторинг. Это сокращает трудозатраты и повышает эффективность операций.
• Интеграция с экосистемой VMware
  TKG интегрируется с другими продуктами VMware, такими как vSphere, vSAN и NSX, что обеспечивает высокую степень управления и безопасности для контейнеризированных приложений.
• Поддержка современных рабочих нагрузок
  TKG поддерживает развертывание и управление современными облачными приложениями, включая микросервисы и серверлесс-архитектуры, что позволяет организациям быстро адаптироваться к изменяющимся бизнес-требованиям.

Архитектура TKG:

• Управляющий кластер
  Management Cluster является основой инфраструктуры TKG. Он отвечает за управление всеми рабочими кластерами, включая их развертывание, обновление и масштабирование. Управляющий кластер также обеспечивает централизованное управление политиками и безопасностью.
• Рабочие кластеры
  Workload Clusters предназначены для развертывания приложений. Каждый рабочий кластер является полностью управляемым экземпляром Kubernetes, который может быть настроен и масштабирован в зависимости от потребностей приложения.
• Tanzu CLI
  Это командная строка, которая позволяет администраторам и разработчикам управлять кластерами Kubernetes и взаимодействовать с компонентами TKG. Tanzu CLI упрощает выполнение задач, таких как развертывание кластеров, обновление версий Kubernetes и управление политиками безопасности.
• Расширения Tanzu Kubernetes Grid Extensions
  TKG Extensions включают дополнительные компоненты и интеграции, которые расширяют возможности Kubernetes. Это включает мониторинг, журналирование, управление конфигурацией и сетевой политикой.

Преимущества использования TKG:

• Упрощение управления Kubernetes
  TKG значительно упрощает управление кластерами Kubernetes, предоставляя готовые к использованию инструменты и автоматизируя многие рутинные задачи. Это позволяет администраторам сосредоточиться на более стратегических задачах.
• Гибкость и масштабируемость
  С поддержкой мультиоблачных сред TKG обеспечивает высокую гибкость и масштабируемость, что позволяет организациям развертывать кластеры Kubernetes там, где это наиболее целесообразно с точки зрения производительности и затрат.
• Повышенная безопасность
  TKG интегрируется с инструментами безопасности VMware, такими как NSX, что обеспечивает высокую степень защиты для контейнеризированных приложений. Это включает сетевую сегментацию, контроль доступа и шифрование данных.
• Быстрое развертывание приложений
  TKG позволяет быстро развертывать и масштабировать приложения, что особенно важно в условиях динамически меняющихся бизнес-требований. Это обеспечивает конкурентное преимущество и ускоряет вывод новых продуктов на рынок.

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

Продолжить читать статью ->>

После переезда ресурсов компании VMware на портал Broadcom было опубликовано несколько полезных материалов, касающихся решения для виртуализации и агрегации сетей виртуального датацентра VMware NSX. Основные из них мы приводим ниже: 1. NSX Certificate Management Cookbook...

В блоге Angry Admin появилась интересная статья, посвященная новому варианту основанного на Linux ПО, которое использует пакет TargetCompany Ransomware для атаки серверов VMware ESXi.

Важное событие в сфере кибербезопасности: исследователи Trend Micro выявили новый вариант Linux из печально известного семейства программ-вымогателей TargetCompany.

Этот вариант специально нацелен на среды VMware ESXi, используя сложный пользовательский shell-скрипт для доставки и выполнения вредоносных программ. Известный под несколькими псевдонимами, включая Mallox, FARGO и Tohnichi, ветка TargetCompany представляет собой постоянную угрозу с момента ее появления в июне 2021 года, в основном сосредотачиваясь на атаках на базы данных в Тайване, Южной Корее, Таиланде и Индии.

Эволюция вымогателя TargetCompany

Вымогатель TargetCompany первоначально привлек внимание своими агрессивными атаками на различные системы баз данных, такие как MySQL, Oracle и SQL Server. В феврале 2022 года антивирусная компания Avast сделала значительный прорыв, выпустив бесплатный инструмент для расшифровки, который мог противодействовать известным на тот момент вариантам вымогателя. Однако к сентябрю 2022 года группа вымогателей восстановила свои позиции, переключив внимание на уязвимые серверы Microsoft SQL и используя Telegram в качестве платформы для угроз жертвам утечками данных.

Новый Linux-вариант вымогателя: подробный обзор

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

После проникновения в целевую систему, вымогатель проверяет наличие среды VMware ESXi, выполняя команду uname и ища строчку "vmkernel". Затем создается файл "TargetInfo.txt", который отправляется на сервер управления и контроля (C2). Этот файл содержит важную информацию о жертве, такую как имя хоста, IP-адрес, сведения об операционной системе, зарегистрированные пользователи и их привилегии, уникальные идентификаторы и подробности о зашифрованных файлах и каталогах.

Скрытные операции и атрибуция

Операции вымогателя разработаны так, чтобы оставлять минимальные следы. После завершения своих задач, shell-скрипт удаляет полезную нагрузку с помощью команды ‘rm -f x’, эффективно уничтожая любые доказательства, которые могли бы помочь в расследованиях после инцидента. Аналитики Trend Micro приписали эти атаки актору по имени «vampire», который также был упомянут в отчете Sekoia в прошлом месяце. IP-адреса, связанные с доставкой полезной нагрузки и получением информации о жертве, были отслежены до интернет-провайдера в Китае, хотя этого недостаточно для точного определения происхождения атакующего.

Влияние и рекомендации

Исторически вымогатель TargetCompany в основном нацеливался на машины под управлением Windows. Появление варианта для Linux и акцент на средах VMware ESXi подчеркивают эволюционирующую тактику и расширяющийся вектор угроз этой заразы. В отчете Trend Micro подчеркивается важность надежных мер кибербезопасности для противодействия этой растущей угрозе. Основные рекомендации включают включение многофакторной аутентификации (MFA), регулярное резервное копирование (в том числе на immutable хранилища) и поддержание обновленными всех систем. Кроме того, исследователи предоставили список индикаторов компрометации, включая хэши для версии вымогателя для Linux, пользовательского shell-скрипта и образцы, связанные с актором «vampire».

Заключение

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

1. Включите многофакторную аутентификацию (MFA)

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

2. Отключите доступ по SSH

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

3. Используйте режим блокировки (lockdown mode)

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

4. Регулярное резервное копирование

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

5. Обновляйте системы

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

6. Сегментация сети

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

7. Обучение сотрудников

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

8. Внедрите сильные политики безопасности

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

9. Развертывание передовых решений безопасности

Используйте передовые решения безопасности, такие как обнаружение и реагирование на конечных точках (Endpoint Detection and Response, EDR), системы обнаружения вторжений (IDS) и системы предотвращения вторжений (IPS), чтобы обнаруживать и смягчать угрозы в режиме реального времени.

10. Мониторинг сетевого трафика

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

11. План реагирования на инциденты

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

12. Ограничение привилегий пользователей

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

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

Консоль Workspace ONE UEM включает различные способы развертывания приложений Win32. Рекомендуемыми методами являются механизм развертывания программного обеспечения (Windows Desktop Software Deployment) и оркестратор для последовательной установки. Метод Product Provisioning, хотя и поддерживается, считается устаревшим для настольных ПК Windows.

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

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

Данное руководство предназначено для ИТ-специалистов и администраторов Workspace ONE в существующих производственных средах. Также будет полезен опыт управления устройствами Windows.

Если вы новичок в Workspace ONE, ознакомьтесь с документом Evaluation Guide: Managing Apps and Devices with Cloud-Based Workspace ONE, которое содержит пошаговые упражнения по реализации таких функций, как мобильный единый вход (SSO) в UEM.

Общее поведение установки

Контекст установки

На настольных ПК с Microsoft Windows установщик может запускаться в системном контексте или в контексте пользователя.

Контекст установки:

• Device: Команда установки выполняется как System.
• User: Команда установки выполняется как User, при необходимости позволяя отображать интерфейс пользователю.

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

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

Контекст System

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

Команда установки унаследует системные права на устройстве, что позволит ей получить доступ к ресурсам с использованием учетной записи "NT AUTHORITY\SYSTEM". Любая попытка доступа к папке или ключу реестра будет оцениваться в соответствии с этой учетной записью и списком управления доступом (ACL), установленным на объекте.

Контекст User

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

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

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

Как UAC влияет на развертывание приложений

Контроль учетных записей (User Account Control, UAC) — это функция безопасности операционной системы Microsoft Windows. Она основана на принципе, что пользователь или устройство должны иметь возможность вносить определенные изменения в конфигурацию или файлы в операционной системе без дополнительных привилегий, если это не может потенциально повлиять на стабильность или безопасность ОС. В таких случаях требуются административные права, также известные как супер-токены (super tokens).

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

Защищенные папки включают следующие:

• \Program Files\ с подкаталогами
• \Windows\system32\
• \Program Files (x86)\ с подкаталогами для 64-битных версий Microsoft Windows

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

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

Как правило, приложения устанавливаются в каталог "Program Files", так как это место по умолчанию. Однако многие приложения могут быть установлены в других местах. Это верно для приложений в пользовательском контексте, которые могут потребовать установки исключительно в области пользователя (т.е. в папке пользователя).

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

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

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

Поведение установки приложений Win32 с использованием ресурсов

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

Поведение установки приложений Win32 с использованием Product Provisioning

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

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

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

Перейдите в раздел Devices > Provisioning > Components > Files/Actions и выберите Add Files/Actions, перейдите на вкладку Manifest и установите Action(s) To Perform = Install/ Run.

Предложения для параметров Retry Count, Retry Interval, Install Timeout для ваших приложений Win32

Значения параметров "Retry Count", "Retry Interval" и "Install Timeout" для приложений Win32 влияют на время, которое система затрачивает на сообщение о неудачном процессе установки. Вы можете изменить значения по умолчанию, чтобы сократить время развертывания.

Значения по умолчанию для этих параметров:

• Retry Count — 3 раза
• Retry Interval — 5 минут
• Install Timeout — 60 минут

работают в следующей последовательности для одного неудачного процесса установки:

Через 3 часа и 15 минут система однократно сообщает о неудачной установке приложения. Затем система устанавливает следующее приложение.

Настройка параметров в зависимости от приложения

Настройте значения, соответствующие приложению.

Пример быстрой установки

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

• Retry Count — 2 раза
• Retry Interval — 5 минут
• Install Timeout — 5 минут

Система сообщает о сбое этого приложения в течение 20 минут. Затем она устанавливает следующее приложение.

Пример медленной установки

Крупное приложение для повышения производительности устанавливается на устройство за 30 минут. Рассмотрите следующие значения для этого приложения:

• Retry Count — 3 раза
• Retry Interval — 5 минут
• Install Timeout — 35 минут

Система может сообщить о сбое этого приложения в течение 120 минут. Затем она устанавливает следующее приложение.

Предложения для параметра Device Restart для ваших приложений Win32

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

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

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

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

Для получения информации о настройках перезагрузки устройства см. шаг 8 темы "Upload and Configure Win32 Files for Software Distribution", а также чтобы узнать, как изменить поведение перезагрузки по умолчанию, см. шаг 3.a. темы "Assign Applications to your Windows Desktop".

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

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

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

• Windows Modern Management Security Design and Implementation
• Managing Updates for Windows Devices
• Deploying Traditional Win32 Applications to Windows Devices

Как вы знаете, недавно платформа VMware Fusion стала бесплатной для некоммерческого использования. В том числе, теперь пользоваели Macbook и компьютеров на базе macOS с процессорами архитектуры ARM (Apple Silicon - M1/M2 и другие) могут устанавливать в виртуальной машине релизы Microsoft Windows 11 for ARM (пока в статусе Insider Preview).

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

This PC doesn't currently meet Windows 11 system requirements

Также эта проблема была задокументирована вот тут, она связана с использованием нового механизма TPM и Secure Boot.

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

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability : BranchName -> CanaryChannel
• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Selection : UIBranch -> CanaryChannel

После этого обновление пройдет успешно:

Недавно мы писали о портируемости лицензий VMware Cloud Foundation, которая стала доступной для использования в сертифицированных услугах Pinnacle-партнеров обновленной программы VMware Cloud Service Provider (VCSP). Сегодня мы поговорим о совместной программе Broadcom и Microsoft по портируемости лицензий облачного решения Azure VMware Solution.

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

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

Azure VMware Solution предоставляет полностью управляемую среду VMware, которая управляется и поддерживается со стороны Microsoft. Клиенты могут перемещать рабочие нагрузки VMware в Azure "как есть" с минимальными изменениями или вообще без них. Это упрощает миграцию и позволяет клиентам продолжать использовать знакомые навыки, обучаясь новым навыкам в Azure.

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

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

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

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

• Защита цен. С зарезервированными инстансами клиенты могут зафиксировать цены на год, три или пять лет.
• Экономия на Windows Server и SQL Server. Windows Server и SQL Server - это общие рабочие нагрузки в средах VMware. С программным обеспечением Assurance для локальных лицензий Windows Server и SQL Server организации могут претендовать на скидку Azure Hybrid Benefit для использования существующих лицензий Windows Server и SQL Server в Azure VMware Solution. Бесплатные расширенные обновления безопасности доступны для более старых версий ПО, которое приближается к концу срока службы.
• Поддержка миграции. Используйте Azure Migrate and Modernize, чтобы получить ресурсы, экспертную помощь и финансирование от Microsoft и ее партнерской экосистемы.
• Кредиты Azure. Клиенты, приобретающие новый зарезервированный экземпляр для Azure VMware Solution, могут получить дополнительные кредиты Azure, действительные для Azure VMware Solution или других сервисов Azure.

Переносимость лицензий VMware Cloud Foundation на Azure VMware Solution станет доступной в конце этого года, поэтому сейчас самое подходящее время, чтобы связаться с командой по работе с клиентами или партнером Microsoft для начала планирования перехода.

На днях мы писали об обновлениях проверенных решений VMware Validated Solutions, которые произошли в мае этого года. Сегодня мы остановимся подробнее на одном из них - VMware Private AI Ready Validated Solution.

Private AI Ready Infrastructure – это уже готовое модульное решение, которое предлагает руководство по проектированию, внедрению и эксплуатации для развертывания AI-нагрузок на стеке VMware Cloud Foundation. Используя GPU-ускоренные VCF Workload Domains, vSphere with Tanzu, NSX и vSAN, это решение обеспечивает прочную основу для современных инициатив в области AI.

Разбор сложностей инфраструктуры, связанных с GPU, и оптимизация AI-нагрузок может быть трудной задачей для администраторов без специальной экспертизы. Трудности, связанные с конфигурацией и управлением средами с GPU, значительны и часто требуют глубоких знаний характеристик оборудования, совместимости драйверов и оптимизации производительности. Однако с решением Private AI Ready Infrastructure VMware Validated Solution, организации могут обойти эти проблемы и уверенно развертывать свои AI нагрузки с проверенными валидированными конфигурациями и лучшими практиками.

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

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

• Детальный документ по проектированию архитектуры, охватывающий высокоскоростные сети, вычислительные мощности, хранилища и Accelerators для AI, а также компоненты VMware Private AI Foundation с NVIDIA.
• Руководство по сайзингу
• Руководство по внедрению
• Руководство по эксплуатации и управлению жизненным циклом, включая проверку работоспособности с помощью VMware Starter Pack на основе vLLM RAG
• Руководство по совместимости

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

Ели вы готовы раскрыть весь потенциал вашей Private AI инфраструктуры, получите доступ к этому решению VMware Validated Solution по этой ссылке.

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

Основные нововведения этого месяца включают:

• Новые решения – инфраструктура Private AI Ready для VMware Cloud Foundation.
• Добавлена поддержка VxRail для отчетности о состоянии и мониторинга для VMware Cloud Foundation.
• Добавлена поддержка VMware Aria Automation 8.16.2 для автоматизации частного облака (Private Cloud Automation) для VMware Cloud Foundation.
• Добавлена поддержка VMware Site Recovery Manager 9.0 и vSphere Replication 9.0 для защиты сайтов и восстановления после аварий для VMware Cloud Foundation.
• Обновлены шаги автоматизации для управления идентификацией и доступом для VMware Cloud Foundation.
• Новый релиз PowerValidatedSolutions v2.10.0.

Инфраструктура Private AI Ready для VMware Cloud Foundation

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

Отчетность о состоянии и мониторинг для VMware Cloud Foundation

Проверенное решение для отчетности о состоянии и мониторинга для VMware Cloud Foundation теперь поддерживает узлы Dell VxRail как для консолидированных, так и для стандартных архитектур.

Private Cloud Automation для VMware Cloud Foundation

Проверенное решение для автоматизации частного облака для VMware Cloud Foundation теперь поддерживает VMware Aria Automation 8.16.2.

Защита сайтов и восстановление после аварий для VMware Cloud Foundation

Проверенное решение Site Protection and Disaster Recovery for VMware Cloud Foundation для VMware Cloud Foundation теперь поддерживает VMware Site Recovery Manager 9.0 и vSphere Replication 9.0.

Управление идентификацией и доступом для VMware Cloud Foundation

Проверенное решение для управления идентификацией и доступом для VMware Cloud Foundation теперь предоставляет процедуру для полной автоматизации с использованием нового меню проверенных решений, предоставленного модулем PowerShell для VMware Validated Solutions. См. Реализация управления идентификацией и доступом с использованием автоматизации PowerShell.

Новая версия PowerValidatedSolutions v2.10.0

• Документация
• Галерея PowerShell
• Проект GitHub

Модуль PowerShell, написанный для поддержки автоматизации многих процедур, связанных с реализацией проверенных решений VMware для VMware Cloud Foundation.

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

Основные моменты нового релиза:

• Добавлено Start-ValidatedSolutionsMenu вместе с подменю для облегчения и ускорения использования.
• Добавлены функции для проверки предварительных условий для каждого проверенного решения.
• Добавлены функции для генерации подписанных сертификатов от Microsoft Certificate Authority для VMware Aria Suite и Site Recovery Manager, устраняя необходимость в использовании CertGenVVS.
• Добавлена поддержка настройки ролей в VMware Aria Suite Lifecycle.
• Многочисленные улучшения в функциях и решениях.

Полный список изменений можно найти в Changelog на GitHub.

Вильям Лам написал интересную статью о том, как можно редактировать настройки SMBIOS для вложенного/виртуального (Nested) VMware ESXi в части hardware manufacturer и vendor.

Nested ESXi продолжает оставаться полезным ресурсом, который часто используется администраторами: от прототипирования решений, воспроизведения проблем клиентов до автоматизированных развертываний лабораторий, поддерживающих как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF).

Хотя с помощью Nested ESXi можно сделать почти все, но имитировать или симулировать конкретные аппаратные свойства, такие как производитель или поставщик (hardware manufacturer и vendor), не совсем возможно или, по крайней мере, очень сложно. Коллега Вильяма Люк Хакаба нашел хитрый трюк, играя с настройками загрузочных ROM виртуальной машины по умолчанию, которые поставляются с ESXi и VMware Desktop Hypervisors (платформы Workstation/Fusion).

Виртуальная машина vSphere может загружаться, используя либо BIOS, либо EFI прошивку, поэтому в зависимости от желаемого типа прошивки вам нужно будет изменить либо файл BIOS.440.ROM, либо EFI64.ROM. Эти файлы ROM можно найти в следующих каталогах для соответствующих гипервизоров VMware:

• ESXi: /usr/lib/vmware/roms
• VMware Fusion: /Applications/VMware Fusion.app/Contents/Library/roms
• VMware Workstation: C:\Program Files (x86)\VMware\VMware Workstation\x64

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

Редактирование BIOS

Шаг 1 - Скачайте и установите Phoenix BIOS Editor. Установщик Phoenix BIOS Editor имеет проблемы при запуске на системе Windows Server 2019, и единственным способом завершить установку - это изменить совместимость приложения на Windows 8, что позволит успешно завершить установку.

Шаг 2 - Скачайте и откройте файл BIOS.440.ROM с помощью Phoenix BIOS Editor, затем перейдите на панель DMI Strings для изменения нужных полей.

Когда вы закончите вносить все изменения, перейдите в меню "Файл" и нажмите "Собрать BIOS" (Build BIOS), чтобы создать новый файл ROM. В данном примере это файл BIOS.440.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi. Второй вариант позволит вам повторно использовать один и тот же кастомный файл ROM в нескольких виртуальных машинах, поэтому, с точки зрения тестирования, возможно, вам захочется создать несколько файлов ROM в зависимости от ваших нужд и просто перенастроить виртуальную машину для использования нужного файла ROM.

Шаг 4 - Чтобы кастомный файл ROM мог быть использован нашей виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку (Advanced Setting) виртуальной машины, которая указывает путь к нашему кастомному файлу ROM:

bios440.filename = "BIOS.440.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить нашу виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS, как показано на скриншоте ниже.

Редактирование EFI

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

Шаг 2 - Скачайте и откройте файл EFI64.ROM с помощью редактора ImHex и найдите строку "VMware7,1". Как только вы найдете расположение этой строки, вам нужно аккуратно отредактировать значения hex, чтобы получить желаемые ASCII строки.

Кроме того, вы можете использовать UEFITool (версия 28 позволяет модифицировать ROM), который имеет гораздо более удобный и функциональный поиск, а также позволяет извлекать часть файла ROM для редактирования с помощью HEX-редактора. В этой утилите можно использовать поиск (CTRL+F), и как только он находит нужный раздел, двойным щелчком по результату переходите к точному месту в файле ROM. Чтобы извлечь раздел для редактирования, щелкните правой кнопкой мыши и выберите "Extract as is" и сохраните файл на рабочий стол.

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

После того как вы сохранили свои изменения, не теряйте указатель в UEFITool. Теперь мы просто заменим раздел нашим измененным файлом, щелкнув правой кнопкой мыши и выбрав "Replace as is", указав измененный раздел. Вы можете подтвердить, что изменения были успешными, просто найдя строку, которую вы заменили. Затем перейдите в меню "Файл" и выберите "Сохранить образ файла" (Save image file), чтобы создать новый файл ROM. В данном случае - это файл EFI64.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi.

Шаг 4 - Чтобы наш кастомный файл ROM мог быть использован виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку ВМ в файл vmx, которая указывает путь к нашему кастомному файлу ROM:

efi64.filename = "EFI64.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS.

Как видно на скриншоте, Вильяму удалось изменить только модель оборудования, но не значение вендора.

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

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

Как написал Farnky, проверить это свойство у всех виртуальных машин в окружении vCenter можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List

Если вы увидите в результатах значение NoStartConnected, значит этот адаптер vmnic не будет подключен при запуске ВМ:

Исправить эту ситуацию можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List

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

Avi Load Balancer реализует новые возможности по следующим направлениям:

1. Приложения для VCF Private Cloud

Avi является предпочтительным балансировщиком нагрузки благодаря своей модели plug-and-play для VCF, предоставляя следующие уникальные преимущества:

• Быстрое развертывание балансировщика благодаря встроенным интеграциям с vSphere и NSX.
• Автоматизированный рабочий процесс LB с Aria Operations (ранее vRealize Operations, vROPs).
• Новое - самообслуживание LB через интеграцию с Aria Automation (ранее vRealize Automation, vRA).
• Расширенная видимость приложений для администраторов VCF, что позволяет быстро решать проблемы, связанные с приложениями, до обращения к команде сетевых администраторов.

2. Приложения для Kubernetes

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

• Встроенная автоматизация с Avi Kubernetes Operator (AKO).
• Новое - Gateway API – это следующее поколение Kubernetes ingress, значительно уменьшающее потребность в настройках через аннотации и определения пользовательских ресурсов (CRD), а также обеспечивающее защиту клиентов для Kubernetes и бессерверных рабочих нагрузок.
• Встроенная безопасность ingress – включая Web Application Firewall (WAF) – для защиты контейнерных рабочих нагрузок.

Дополнительная лицензия на эти функции не требуется.

3. Мобильные и 5G приложения

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

• Новое - нативная многопользовательская поддержка, теперь обеспечивающая в 3 раза большую многопользовательскую поддержку с VCF и Telco Cloud Platforms (TCP).
• Новое - полная поддержка недавно выпущенного TCP 4.0.
• Новое - дальнейшие улучшения программно-определяемого IPv6 балансировщика нагрузки (с разделенными слоями управления IPv6 и распределенными слоями данных) для локальных и облачных решений.

4. Инструмент конвертации старых LB в Avi

Для упрощения и ускорения развертывания Avi в существующих инфраструктурах, VMware представила инструмент конвертации Avi. Этот инструмент:

• Обнаруживает старые LB.
• Извлекает конфигурации.
• Конвертирует конфигурации и пользовательские правила старых LB (например, iRules) в Avi.
• Развертывает конфигурации на Avi.

Этот инструмент ускорит миграцию старых LB на Avi, в том числе выполняемую командой профессиональных услуг VMware.

Самообслуживание балансировки нагрузки для VCF Private Cloud

Avi Load Balancer является предпочтительным балансировщиком нагрузки для VCF, полностью интегрированным и поддерживаемым, с функциями plug-and-play. Avi предоставляет беспрецедентную видимость приложений, что помогает администратору VCF быстро выявлять и устранять причины проблем с производительностью приложений в течение нескольких минут.

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

Интеграция Avi с Aria Automation предлагает командам приложений доступ в форме самообслуживания к услугам балансировки нагрузки уровней L4-L7 (см. Включение балансировки нагрузки как услуги для частного облака на основе VCF). Это позволяет командам приложений и инфраструктуры немедленно развертывать балансировку нагрузки при предоставлении приложений, с минимальными знаниями технологий балансировки нагрузки и без необходимости создания ручных тикетов. Интеграция помогает клиентам снизить операционные затраты, упростить и автоматизировать развертывание и управление емкостью балансировки нагрузки. Смотрите это короткое демонстрационное видео, чтобы увидеть, как легко включить балансировку нагрузки как услугу с использованием Aria Automation.

Увеличение многопользовательской поддержки Avi Load Balancer примерно в 3 раза

Предприятия развертывают крупномасштабные приложения, которые требуют эластичной и надежной балансировки нагрузки. Несколько команд и арендаторов должны иметь доступ к инфраструктуре частного облака. Avi Load Balancer значительно улучшил производительность и масштабируемость, увеличив поддержку многопользовательского режима почти в 3 раза. Теперь клиенты могут управлять большим количеством Avi Service Engines (балансировщиков нагрузки) для каждого развернутого Avi Controller.

Каждый контроллер может поддерживать до 800 маршрутизаторов уровня Tier-1 для VMware NSX-T Cloud. Клиенты не только имеют меньшее количество контроллеров для управления, но и значительно снижают операционные расходы по сравнению с устаревшими балансировщиками нагрузки. В результате, та же команда может управлять большим количеством арендаторов, что повышает производительность. Провайдеры облачных услуг VMware, ранее известные как VMware Cloud Provider Program (VCPP), используют Avi Load Balancer для оптимизации облачных операций и повышения качества предоставляемых услуг. Подробнее см. в этом вебинаре Feature Friday на YouTube.

Avi для Ingress-балансировки нагрузки Kubernetes и бессерверных рабочих нагрузок

Контейнеры по своей природе являются эфемерными и эластичными, постоянно запускаются и останавливаются, что делает устаревшие аппаратные балансировщики нагрузки с традиционными архитектурами неактуальными для облачных и контейнерных сред. В условиях, когда все больше рабочих нагрузок в производственной среде развертываются на платформах Kubernetes, открытые решения становятся нецелесообразными для требований предприятий. Чтобы идти в ногу со скоростью развертывания приложений и предоставлять решения по балансировке нагрузки и ingress корпоративного уровня, Avi Load Balancer предлагает идеальную архитектуру для контейнерных рабочих нагрузок со встроенной безопасностью.

Avi предлагает интегрированные ingress-услуги, которые включают ingress-контроллер, балансировку нагрузки, глобальную балансировку нагрузки серверов в нескольких кластерах (GSLB), WAF и аналитику приложений на одной платформе. Для клиентов, которые развернули Avi для своих виртуализированных рабочих нагрузок, это простое расширение на Kubernetes с использованием того же пользовательского интерфейса, последовательных рабочих процессов и политик. Avi является независимым от контейнерных платформ и поддерживает VMware Tanzu, RedHat OpenShift, Tanzu Application Service (TAS, ранее Pivotal Cloud Foundry) и другие.

Avi Load Balancer вводит общую доступность (GA) поддержки Gateway API в выпуске AKO 1.12.1. Avi добавляет продвинутые функции маршрутизации уровня L7, включая поддержку безсерверного Kubernetes, модификацию заголовков, вставку cookie и ключевой набор функциональных возможностей HTTProute. Avi предлагает продвинутую маршрутизацию трафика, лучшую масштабируемость и мониторинг на основе каждого маршрута, без необходимости в CustomResourceDefinition (CRD) или аннотациях.

Расширение программно-определяемого подхода для мобильных и 5G-приложений

С поддержкой распределенного IPv6, обеспеченной уникальной программно-определяемой архитектурой Avi и поддержкой Telco Cloud Platform 4.0, VMware Avi Load Balancer продолжает предлагать широкий набор сценариев использования: от 4G рабочих нагрузок в ВМ и виртуальных сетевых функций (VNF) до 5G контейнерных рабочих нагрузок и контейнерных сетевых функций (CNF).

Крупный телекоммуникационный клиент VMware сначала развернул Avi в своей корпоративной сети в качестве пилотного проекта. Впечатленная его простотой использования и аналитикой приложений, команда сетевых администраторов представила Avi своей основной телекоммуникационной команде, которая решила расширить использование Avi в Telco Cloud Platform, обеспечивающую 5G сеть для рабочих нагрузок Kubernetes.

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

Инструмент конвертации старых балансировщиков нагрузки в Avi

Чтобы еще больше упростить миграцию с устаревших аппаратных балансировщиков нагрузки и ускорить переход на частное облако VCF, Avi Load Balancer объявляет о начальной доступности (Initial Availability) инструмента конвертации на базе UI, который берет старые правила политик, преобразует конфигурации в встроенные функции Avi, а также в Avi DataScript (скриптовый язык на базе Lua). Клиенты разрывают цепь старых балансировщиков нагрузки, переходя от сложных конфигураций для каждого устройства к простому управлению политиками из центральной панели управления.

Больше деталей о последней версии VMware Avi Load Balancer вы можете узнать по этим ссылкам:

• VMware Avi Load Balancer Conversion Tool Demo
• VMware Avi Load Balancer 30.2.1 Release Note
• Avi Kubernetes Operator (AKO) 1.12.1 Release Notes
• Enabling Load Balancing as a Service for VCF-based Private Cloud

У Brock Peterson есть хорошая подборка статей о решении VMware Aria Operations (ранее этот продукт назывался vRealize Operations или vROPs). Сегодня мы посмотрим на то, как работает кластер vROPs/Aria с точки зрения основных архитектур отказоустойчивости - Standalone, High Availability (HA) и Continuous Availability (CA). Официальная документация на эту тему находится тут, а мы начнем с некоторых понятий:

• Primary Node (основной узел) - начальный и единственный обязательный узел в Aria Ops. Все остальные узлы управляются основным узлом. В установке с одним узлом основной узел выполняет все функции.
• Data Node (дата-узел) - на этих узлах установлены адаптеры, они собирают данные и выполняют анализ. В крупных развертываниях адаптеры обычно устанавливаются только на дата-узлах, чтобы основной узел и реплики могли сосредоточиться на управлении кластером.
• Replica Node (реплика) - высокая доступность (HA) и непрерывная доступность (CA) Aria Ops требует преобразования дата-узла в реплику. Это копия основного узла, которая используется в случае его отказа.
• Witness Node (свидетель) - непрерывная доступность (CA) Aria Ops требует наличие узла-свидетеля. Свидетель выступает в качестве арбитра при принятии решений о доступности Aria Ops.
• Remote Collectors (удаленные сборщики) - распределенные развертывания могут требовать удаленных сборщиков (RC), которые могут обходить брандмауэры, взаимодействовать с удаленными источниками данных, снижать нагрузку на каналы передачи данных между центрами обработки данных или уменьшать нагрузку на кластер аналитики Aria Ops. Узлы RC только собирают объекты для инвентаризации, без хранения данных или выполнения анализа. Кроме того, удаленные сборщики могут быть установлены на другой операционной системе, чем остальные узлы кластера.

Важно отметить, что основные узлы и реплики также являются дата-узлами. Кластер аналитики (Analytics Cluster) включает все основные узлы, реплики и дата-узлы. Кластер Aria Ops включает кластер аналитики и любые узлы удаленных сборщиков.

Вне кластера Aria Ops также могут быть Cloud Proxies (CP). Первоначально они назывались Remote Collectors для развертываний vROps Cloud, но потом они были доработаны для полного замещения RC. Рекомендации по их сайзингу можно найти здесь. Отдельное развертывание может выглядеть следующим образом:

Вы можете построить кластер Aria Ops несколькими способами: автономный (Standalone), с высокой доступностью (HA) или с непрерывной доступностью (CA).

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

• Single Primary Node Cluster (кластер с одним основным узлом) - в этом развертывании ваш основной узел Aria Ops будет выполнять все функции: административный интерфейс, продуктовый интерфейс, REST API, хранение данных, сбор и аналитика. Такие развертывания часто используются для пробных версий или пилотных проектов (proof-of-concept). Сайзинг основных узлов зависит от количества объектов и метрик, которые они будут обрабатывать, подробности можно найти здесь.
• Кластеры с несколькими узлами (Multi-Node Clusters):
  • Основной узел и как минимум один дата-узел, но может включать и до 16 дата-узлов. Дата-узлы могут выполнять все функции, которые выполняет основной узел, кроме обслуживания Admin UI. Они часто используются для разгрузки основного узла. Обратите внимание, что основной узел также является дата-узлом.
  • Основной узел и как минимум один облачный прокси (CP), но может включать и до 60 CP. Ранее известные как удаленные сборщики (RC), они используются для обхода брандмауэров, получения данных из удаленного источника, уменьшения пропускной способности между центрами обработки данных и других задач. Они только собирают метрики, не хранят данные и не выполняют анализ данных. RC являются частью кластера Aria Ops, тогда как CP не являются частью кластера.

Автономные варианты визуально выглядят следующим образом.

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

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

В версии vRealize Operations 6.0 была введена функция HA, обеспечивающая некоторую защиту от потери аналитического узла (основной узел, реплика узел или дата-узел). Следует отметить, что Aria Ops HA не является стратегией аварийного восстановления (DR), но обеспечивает некоторую защиту от потери данных. Как и для кластеров без HA, мы просто добавляем узел реплики, получая следующие конфигурации:

• Основной узел и реплика
• Основной узел, реплика и до 16 дата-узлов
• Основной узел, реплика и до 60 облачных прокси (CP)
• Основной узел, реплика, до 16 дата-узлов и до 60 CP

Как описано здесь, Aria Ops HA создает копию основного узла, называемую репликой, и защищает кластер аналитики от потери дата-узла. Aria Ops использует базу данных PostgreSQL, распределенную между всеми дата-узлами (включая основной узел и реплики) для хранения всех данных, поэтому если мы потеряем основной узел, узел реплики будет повышен до основного, и мы продолжим работу без потери данных. Если мы потеряем дата-узел, эти данные также доступны на основных/реплика узлах (эта схема похожа на RAID5), поэтому потери данных не будет. Если мы потеряем более одного дата-узла, произойдет потеря данных.

Лучшие практики для развертывания кластера Aria Ops HA можно найти здесь. В итоге, ваш кластер Aria Ops HA будет выглядеть примерно так:

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

В версии Aria Ops 8.0 были введены функции непрерывной доступности (CA) и концепция доменов отказа. Можно сказать, что Aria Ops CA - это Aria Ops HA с репликой в другом физическом расположении, а также с парными дата-узлами и узлом Witness, чтобы отслеживать все процессы.

Aria Ops CA защищает нас от потери целого домена отказа, например, всего датацентра. Как описано здесь, с CA данные, хранящиеся в основном узле и дата-узлах в домене отказа 1, постоянно синхронизируются с узлом реплики и дата-узлами в домене отказа 2. Aria Ops CA требует как минимум один дата-узел в дополнение к основному узлу, и они должны быть парными, то есть дата-узел в домене отказа 1 требует дата-узел в домене отказа 2.

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

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

Ресурсы VMware Digital Learning и MyLearn успешно перешли на новую платформу с 6 мая 2024 года. Теперь ИТ-специалисты могут управлять своими учебными активностями из единого централизованного места. В результате этой миграции создана прочная основа для будущих улучшений и упрощения пользовательского опыта управления обучением.

Все пользователи MyLearn должны создать аккаунт Broadcom перед первым доступом к Learning@Broadcom. На платформе будут регулярно появляться новые курсы, предоставляя ИТ-специалистам всеобъемлющий и актуальный каталог курсов по стеку VMware Cloud.

Доступ к новой платформе

Чтобы получить доступ к новой платформе, выполните следующее:

1. Посетите портал поддержки Broadcom.
2. Введите свои учетные данные в правом верхнем углу. Вы должны были получить инструкции по созданию аккаунта в отдельном письме. Если вы не получили инструкции, обратитесь к руководству "Как получить доступ к цифровому контенту VMware VCF" для помощи в создании профиля.
3. Через вкладку "My Dashboard" прокрутите вниз до "Learning@Broadcom", чтобы получить доступ к порталу.

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

Что вам следует ожидать:

• Изменения в обучении с инструктором - имейте в виду, что все не-VCF клиенты должны обращаться к одному из авторизованных партнеров VCF Authorized Education Partners в своем регионе для регистрации на курс с инструктором. Нажмите здесь, чтобы найти партнера по образованию рядом с вами. Все клиенты VCF будут регистрироваться через Learning@Broadcom, следуя вышеописанным шагам, находя курс и прокручивая вниз до доступных дат.
• Текущие клиенты VCF – Learning@Broadcom предлагает функции для самостоятельной регистрации на предстоящие курсы. Чтобы начать, получите доступ к порталу, следуя вышеуказанным инструкциям. Рекомендуется самостоятельно исследовать платформу и искать значок "Events".

• Доступ к содержимому курсов - получите доступ к вашей текущей подписке через вкладку "VMware Subscriptions" на новой платформе и перейдите к выбранному курсу.

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

Поддержка

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

• Создайте тикет на Broadcom Support Portal - войдите, как указано выше, и создайте заявку через "My Cases" в левом навигационном меню. Дополнительную документацию по навигации поддержки можно найти здесь.
• Создайте заявку через форму Broadcom Support Form - для этого используйте эту ссылку.

Добавьте страницу VCF Learning Page в закладки для получения дополнительных ресурсов.