На конференции VMware Explore 2024 в Барселоне компания Broadcom представила революционную сетевую архитектуру VeloRAIN, предназначенную для поддержки и оптимизации рабочих нагрузок, связанных с искусственным интеллектом (AI), в рамках больших предприятий. VeloRAIN (RAIN - это Robust AI Networking) создана для улучшения производительности и безопасности AI-нагрузок в распределенных средах, что делает её важным инструментом для современных предприятий, сталкивающихся с растущими потребностями в передаче данных и выполнении AI-задач.
Основные Преимущества VeloRAIN
Выявление AI-приложений с помощью AI и машинного обучения (ML)
Одной из ключевых особенностей VeloRAIN является способность обнаруживать зашифрованный трафик приложений, который ранее было невозможно анализировать стандартными решениями для оптимизации сети. Это дает компаниям возможность более точно определять и выделять приоритеты для AI-приложений, что, в свою очередь, позволяет повысить качество обслуживания (QoS) и улучшить пользовательский опыт.
Повышение эффективности сети и оптимизация трафика
VeloRAIN предлагает инновационные методы оценки качества каналов связи, которые помогают улучшить обслуживание пользователей при работе с беспроводными каналами, включая 5G и спутниковые соединения. Это позволяет достичь качества, сравнимого с проводной связью, даже при изменяющихся условиях сети. Кроме того, архитектура ускоряет настройку сетей в удаленных офисах или филиалах, делая запуск инфраструктуры более быстрым и менее трудоемким.
Динамическая система управления приоритетами на основе AI
Новая динамическая платформа управления политиками автоматизирует присвоение приоритетов для приложений, что упрощает управление сетью. С помощью функции Dynamic Application-Based Slicing (DABS) платформа VeloRAIN обеспечивает высокое качество обслуживания для каждого приложения, даже если сети, по которым передаются данные, не поддерживают послойную сегментацию. DABS также использует профили пользователей, чтобы предоставлять приоритетный трафик ключевым сотрудникам, улучшая их опыт и общую производительность сети.
Автоматизация и мониторинг сети с использованием AI
VeloRAIN позволяет компаниям получить глубокую видимость работы сети, автоматизировать процессы приоритезации и мониторинга, а также сократить вмешательство со стороны IT-специалистов. Это особенно важно для AI-нагрузок, которые являются автономными и требуют оркестрации, а не ручного администрирования. Используя VeloRAIN, предприятия могут более эффективно и оперативно настраивать свои сети под потребности бизнес-нагрузок, что улучшает адаптивность к изменениям в рабочем процессе и инфраструктуре.
Стратегическая Значимость VeloRAIN для современного бизнеса
VeloRAIN представляет собой значительный шаг вперед в управлении распределенными рабочими нагрузками AI, так как позволяет предприятиям быстро адаптироваться к изменениям и обеспечивать безопасность и производительность своих AI-нагрузок. С помощью этой архитектуры компании смогут не только улучшить качество взаимодействия с клиентами, но и оптимизировать расходы, так как система автономно распределяет приоритеты и адаптируется под изменения в сети.
Цель Broadcom в развитии сетевой инфраструктуры на базе AI
Как отметил Санжай Аппал, вице-президент и генеральный директор подразделения VeloCloud компании Broadcom, VeloRAIN станет основой инноваций компании в AI-сетях, предоставляя компаниям инструменты для оптимизации их AI-нагрузок. Broadcom планирует активно развивать свою экосистему партнеров, чтобы предоставить компаниям инфраструктуру нового поколения для поддержки AI и облачных рабочих нагрузок в будущем.
Прочие анонсы VeloCloud
VeloCloud Edge 4100 и 5100: высокопроизводительные устройства для крупных предприятий
Broadcom представила устройства VeloCloud Edge 4100 и 5100, которые обеспечивают повышенную пропускную способность и масштабируемость. Устройство Edge 4100 поддерживает до 30 Гбит/с и до 12 000 туннелей, а Edge 5100 — до 100 Гбит/с и до 20 000 туннелей. Эти решения упрощают сетевую архитектуру и обеспечивают высокую надежность для AI и других рабочих нагрузок.
Titan: Новая партнерская программа для поддержки MSP
Программа Titan предлагает партнерам Managed Service Providers (MSP) эксклюзивные преимущества, такие как стабильный рост бизнеса, доступ к передовым технологиям, новую модель лицензирования и улучшенные возможности по предоставлению управляемых услуг для клиентов.
Особенности новой программы:
Вознаграждение на основе показателей, включая совместную разработку решений, признание на рынке и стабильный и предсказуемый рост бизнеса.
Эксклюзивный доступ к инновационным технологиям и каналам выхода на рынок.
Новая модель лицензирования, обеспечивающая переносимость лицензий, простоту управления и стабильность цен.
Программа создания услуг, ориентированная на ключевые ценностные драйверы, вертикальное выравнивание и более высокие маржинальные показатели.
Новое предложение «White label», позволяющее партнерам высшего уровня расширять базу VeloCloud через региональных и специализированных партнеров канала.
Вместе с релизом основной платформы VMware Cloud Foundation 5.2 в самом конце июля компания Broadcom представила обновленную версию решения NSX 4.2, предназначенного для виртуализации и агрегации сетей виртуального датацентра. Напомним, что о возможностях прошлой версии VMware NSX 4.1 мы писали вот тут.
Релиз NSX 4.2.0 предоставляет множество новых функций, предлагая новые возможности для виртуализованных сетей и безопасности для частных, публичных и мультиоблачных инфраструктур. Основные новшества:
Простота внедрения виртуальных сетей для виртуальных машин, подключенных к VLAN-топологиям.
Поддержка IPv6 для доступа к NSX Manager и Edge Nodes.
Повышенная доступность сетевого подключения с поддержкой двойных DPU, группировкой TEP, улучшенным обнаружением сбоев и приоритизацией пакетов, обнаруживающих сбои.
Дополнительная поддержка событий, алармов и других эксплуатационных функций.
Улучшения в области многопользовательского доступа и виртуальных частных облаков (VPC).
Увеличение масштаба правил и групп для брандмауэра как в Local Manager, так и в Global Manager.
Доступность функции IDS/IPS на T0 для Gateway Firewall.
Распределенная защита от вредоносных программ на растянутых кластерах VSAN.
Добавлен захват пакетов для анализа угроз и экспертизы в NDR для событий IDS/IPS.
Сетевые возможности
Сетевой уровень 2
Группы TEP более эффективно используют несколько TEP на узел Edge Node, выполняя балансировку трафика на основе потоков, что обеспечивает больше двунаправленной пропускной способности для Tier-0 шлюза.
Поддержка MPLS и DFS трафика улучшает пропускную способность трафика для данных протоколов.
Инструмент для легкого внедрения виртуальных сетей помогает плавно перейти на использование оверлейных сетей.
Совмещенные VIB для безопасности и сетей позволяют настроить распределенный брандмауэр на DVPG и виртуализацию сети на одном хосте ESXi.
Улучшения в области видимости путей данных включают новые возможности мониторинга путей данных через API и UI.
Поддержка неизвестных типов Ethertypes обеспечивает пересылку трафика любого типа, гарантируя пересылку двойных VLAN-меток.
Поддержка неприоритетной active-standby политики тиминга для обеспечения отсутствия сбоев трафика при возврате активного соединения.
Улучшения в области производительности и гибкости коммутаторов включают изменения режима VDS без необходимости удаления конфигурации.
Ускорение на базе DPU
Поддержка Dual DPU для обеспечения высокой доступности, где отказ одного DPU не влияет на серверный хост.
Поддержка двух активных DPU без высокой доступности, при отказе одного DPU трафик на нем не защищен и не будет перенаправлен на второй DPU.
Сетевой уровень 3
Поддержка IPv6 для NSX Managers и Edge Nodes позволяет развертывать NSX без необходимости в IPv4 адресах.
Поддержка уникального идентификатора маршрута EVPN на каждом Tier-0 SR и VRF для active/active шлюзов Tier-0.
Усовершенствованные возможности отладки и журналирования для неудачных сеансов BGP и BFD.
Платформа Edge
Алармы для платформы Edge улучшают ее видимость и служб, работающих на ней.
Аларм при долгом захвате пакетов на Edge.
Функция "Edge Agent Down" помогает определить работоспособность агента Edge.
Аларм "Tunnels down" помогает быстрее идентифицировать проблемы с туннелями на Edge.
Обнаружение событий петли моста при обнаружении петли в сети между мостовыми сетями и сетью NSX.
Поддержка High Security Cipher для NSX Load Balancer.
VPN
Улучшения управления сертификатами VPN с изоляцией между проектами и поддержка VPN на Tier-1 шлюзах проекта.
Сетевые возможности для контейнеров
Поддержка NSX Child Segment для Antrea Egress позволяет использовать сеть в конфигурации Egress IP Pool отличную от сети узлов.
Безопасность
Шлюз брандмауэра
Функция IDS/IPS на T0 Gateway позволяет создавать правила IDS/IPS на шлюзе Tier-0.
Увеличение масштабируемости для vDefend Gateway Firewall.
Увеличение масштабируемости для правил и групп распределенного фаервола.
Распределенный фаервол
Повышение видимости сетевых политик Kubernetes.
Улучшения UI для отображения соответствующих критериям группировок членов.
Network Detection and Response (NDR)
Поддержка корреляции всех кампаний NDR на сайте клиента.
Ведение журналов событий обнаружения и кампаний в SIEM.
Возможность экспорта и загрузки захваченных пакетов (PCAP) для событий IDPS.
Включение событий вредоносных программ из распределенного брандмауэра в корреляцию кампаний NDR.
Система обнаружения и предотвращения вторжений (IDPS)
Обновленный движок для IDPS на NSX Edge для лучшей производительности и улучшенного обнаружения.
Поддержка IDPS на Tier-0 для NSX Edge.
Распределенное обнаружение и защита от вредоносных программ
Поддержка ATP в VCF для конфигурации с растянутым кластером vSAN.
Упрощение развертывания SVM.
Поддержка файлов OneNote для обнаружения и предотвращения распространения вредоносного ПО.
Платформа и операции
Автоматизация
Поддержка Terraform для управления установкой и обновлением NSX Fabric.
Поддержка Terraform для настройки GRE туннелей.
Многопользовательский доступ
Возможность создания проекта и VPC без правил брандмауэра по умолчанию.
Возможность создания VPN в проекте.
Установка и обновление
Прямое обновление с NSX 3.2.x до NSX 4.2.0.
Дополнительные проверки памяти перед обновлением NSX.
Управление сертификатами NSX.
Операции и мониторинг
Доступность NSX Manager в конфигурации XL.
Введение динамических онлайн-руководств по диагностике системы.
Дополнительные метрики в API NSX.
Захват пакетов с трассировкой в Enhanced Datapath Host Switch.
Сокращение размера пакетов поддержки.
Платформенная безопасность
Поддержка TLS 1.3 для внутренних коммуникаций между компонентами NSX.
Масштабируемость
Несколько обновлений максимальной поддерживаемой масштабируемости NSX.
Федерация
Размер XL для Global Manager.
Интеллектуальная безопасность
Расширенные аналитические панели для оперативной безопасности фаервола.
NSX Application Platform (NAPP)
Поддержка развертывания NSX Application Platform за прокси-сервером.
Для получения более подробной информации о новых возможностях NSX 4.2.0 и руководствах по установке и эксплуатации, обращайтесь к официальной документации и ресурсам VMware.
После переезда ресурсов компании VMware на портал Broadcom было опубликовано несколько полезных материалов, касающихся решения для виртуализации и агрегации сетей виртуального датацентра VMware NSX. Основные из них мы приводим ниже: 1. NSX Certificate Management Cookbook...
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 добавила еще одну технику поведенческого обучения в свой арсенал - алгоритм для выявления аномалий в сезонных временных рядах.
Алгоритм Хольта-Винтерса
Алгоритм Holt-Winters (HW), разработанный Хольтом и Винтерсом, помогает построить модель для сезонного временного ряда (например, с учетом суточной сезонности). Эта техника улучшает существующие средства обнаружения аномалий Avi Load Balancer, которое использует алгоритм экспоненциально взвешенного скользящего среднего (EWMA). Если EWMA звучит непонятно, то для быстрого освежения памяти хорошо подходит учебник "Прогнозирование: принципы и практика". По сути, EWMA тесно следует за кривой данных, однако он работает так, что периодические компоненты данных просто игнорируются. Этот момент учитывается при декомпозиции сигнала алгоритмом Хольта-Винтерса. Для сравнения прогностических моделей двух алгоритмов рассмотрим интервалы прогнозирования 80% и 95% EWMA и HW при применении к одним и тем же данным.
Для повышения точности не должно быть игнорирования сезонности входного ряда данных. Алгоритм Хольта-Винтерса работает путем разбиения указанного временного ряда на три компоненты:
Уровень: Можно представить как усреднение входного сигнала.
Тренд: Представляет собой наклон или общее направление движения данных.
Сезонность: Отражает периодичность данных.
На рисунке ниже представлены три составляющие временного ряда (под основным сигналом), который мы прогнозировали выше:
Временной ряд может иметь аддитивную/мультипликативную тенденцию/сезонность. Для простоты в данной статье мы предполагаем применение алгоритма Хольта-Винтерса к временному ряду с аддитивной тенденцией и аддитивной сезонностью (additive-trend-additive-seasonality, HW-AA), так как это ближе к факторам в реальной жизни. Для такого ряда компоненты тренда и сезонности увеличиваются линейно и суммируются, чтобы составить точки данных на прогрессирующих временных срезах. Временной ряд представлен следующим образом:
Где отдельные компоненты вычисляются следующим образом:
Обратите внимание, что каждое уравнение компоненты по сути представляет собой расчет в стиле EWMA. Для дальнейшего понимания обратитесь к книге "Прогнозирование: принципы и практика".
Несколько слов о параметрах сглаживания alpha, beta, gamma. Как общее руководство, инженеры используют уравнение для определения параметров сглаживания, как это рекомендуется в статье "Обнаружение аномалий во временных рядах для мониторинга сети".
Это уравнение подчеркивает, какую важность мы хотим придать историческим данным. Например, в Avi, когда применяется алгоритм HW к метрике, представляющей пропускную способность приложения, вес 95% придается сэмплам (с интервалам 5 минут) за последний час. Подставим эти значения в уравнение выше:
Эта схема применима и к другим параметрам сглаживания. Обратите внимание, что, как видно из уравнений выше, объем памяти, потребляемый алгоритмом HW, пропорционален сезонному периоду. В контексте аналитического движка Avi это означает занимаемый объем памяти размером 96 КБ на метрику. Поэтому из тысячи метрик, анализируемых Avi, VMware внимательно балансирует применение алгоритма HW только к наиболее значимым сезонным метрикам, не перегружая операции.
Для оценки нашего выбора параметров для встраиваемой реализации алгоритма HW мы сравниваем прогнозные значения с уже известным временным рядом. Вот результат:
По оси X отложено время t, а по оси Y - соответствующее значение выборки данных. График представляет собой сравнение исходных и прогнозируемых значений, а также обозначает интервалы прогнозирования с доверительной вероятностью 95%. Легко заметить, что исходные и прогнозируемые данные довольно хорошо совпадают.
Аналитический движок Avi применяет несколько методов обнаружения аномалий к одному временному ряду. Как описано выше, эти методы обнаружения используют варианты EWMA и HW. Таким образом, результаты каждой модели подвергаются режиму консолидации ALL или ANY, где либо все результаты должны согласиться с решением (о маркировке точки данных как аномальной) или же достаточно и одного. Выбор режима консолидации зависит от баланса между ложноположительными и истинными результатами. В режиме ALL ожидаются более частые ложноположительные результаты с более точными истинными, так как диагностика хотя бы одной моделью достаточна для пометки выборки данных как аномальной. В отличие от этого, режим ALL требует единогласного решения алгоритмов, что требует большей уверенности в маркировке выборки данных. Следовательно, это делает более сложным пометку правильных данных как аномальных (соответственно, меньше ложноположительных, но и меньше истинных результатов). В рамках этого подхода VMware предустанавливает режимы в зависимости от конкретной метрики, основываясь на опыте наблюдений.
Вот преимущества подхода Avi:
Inline - это встроенная функция контроллера доставки приложений (Application Delivery Controller, ADC), она не требует дополнительных настроек или использования стороннего программного обеспечения.
Быстрый и действенный - обнаружение аномалий выполняется в реальном времени, а администраторам предоставляются средства по автоматизации их обработки (например, добавление ресурсов). Администраторам не нужно вручную блокировать клиентов, запускать новый сервер или увеличивать ёмкость на основе прогнозов использования ресурсов и т. д.
Интеллектуальный - машинное обучение операционным шаблонам и поведению позволяет аналитическому движку Avi принимать лучшие решения по обнаружению аномалий, прогнозированию нагрузки, планированию эластичной ёмкости и т. д.
Как отмечалось ранее, вы можете использовать модель не только для идентификации аномалий, но и для прогнозирования результатов в будущем. Фактически, прогностические модели используются аналитическим движком Avi для автомасштабирования ресурсов. Это требует оценки метрик, которые могут иметь суточный или другой сезонный характер. Таким образом, прогнозируемую ёмкость теперь можно использовать для масштабирования ресурсов приложений вверх/вниз, что значительно оптимизирует затраты.
В Avi постоянно улучшают эту технологию, разрабатывая и интегрируя все более интеллектуальные методы. Помимо интеграции Хольта-Винтерса в систему обнаружения аномалий, также разрабатываются модели, использующие теории машинного и глубокого обучения. Входные данные от таких новых концепций и технологий продолжают обеспечивать высокое качество моделирования.
Продолжаем рассказывать о решении VMware Avi Load Balancer, которое недавно стало доступно в качестве балансировщика как услуги (Load Balancer as a Service, LBaaS) для решения Aria Automation 8.16.1.
Часто менеджеров датацентров мучает простой вопрос – как администраторы знают, что приложения находятся в "хорошем" состоянии? В VMware провели огромное количество встреч и дебатов по теме, касающейся "здоровья приложений" - приведем ниже основные моменты статьи сотрудников Avi, касающейся здоровья приложений.
В команде были люди с разным опытом, им всем задали один и тот же вопрос – "что для вас значит здоровье приложения?". Вот некоторые из ответов, которые были получены:
"Здоровье" – это пропускная способность (throughput), которую может обеспечивать приложение. Если она составляет 10 Гбит/с, это значит, что оно в хорошем состоянии.
Здоровье плохое, когда CPU и память загружены более чем на 100%.
Здоровье хорошее, когда задержка (latency) ниже 100 мс.
Здоровье хорошее, если приложение работает и отвечает на проверки (health checks).
В реальном мире, если спросить вас - "вы считаете, что у меня хорошее здоровье, если я пробежал сегодня 3 мили?", в зависимости от того, кто вы, вы, скорее всего, ответите: "это зависит от разных факторов", "конечно!", "ты пробежал только сегодня или бегаешь каждый день?" или "каков был твой пульс и жизненные показатели после бега?". У вас будет много дополнительных вопросов, чтобы углубиться в детали. С этой точки зрения, теннисист Роджер Федерер, скорее всего, выиграл бы по этому показателю у большинства людей, даже если бы бегал с гриппом. Сделало бы это его здоровым? Конечно нет!
Как вы видите, простой факт возможности пробежки на 3 мили недостаточен для врача, чтобы выдать заключение о хорошем здоровье. Аналогично, если вы думаете, что можете определить здоровье сервера, исходя из простого факта, что он может обрабатывать пропускную способность 10 Гбит/с, вы, вероятно, ошибаетесь. Автору было трудно с этим смириться, особенно учитывая, что большую часть своей карьеры до Avi он провел в компании по производству оборудования, где было нормально считать, что сетевое оборудование в отличном состоянии, когда соединение работает и передает данные с пропускной способностью 10 Гбит/с.
Аналогии со здоровьем человека
В VMware обнаружили, что в ответах всех было много убежденности и субъективности, но это просто не имело смысла. Тогда авторы решили обратиться к аналогиям со здоровьем человека.
На секунду давайте представим команду Golden State Warriors как веб-приложение. Тогда звездный баскетболист Стефен Карри, вероятно, был бы важным микросервисом в этом приложении. Как бы мы измеряли его здоровье? Конечно, когда Карри здоров, мы ожидаем, что он будет набирать около 30 очков за игру в среднем. Мы также не ожидаем, что он устанет во время игры. В хорошем состоянии здоровья (измеряемом с помощью таких показателей, как пульс, кровяное давление и т. д.) от Карри ожидают, что он будет последовательно и ровно выступать.
Автор применил аналогичную философию к измерению здоровья приложений. Вот определение здоровья от Merriam-Webster, которое он счел релевантным:
"состояние организма в отношении выполнения его жизненно важных функций, особенно оцениваемое субъективно или непрофессионально"
Автор немного улучшил это определение для "оценки здоровья" приложений в Avi:
"Avi Health (Score) – это мера производительности приложения и его постоянства, которая отражает любые риски для приложения в контексте различных факторов, таких как ресурсы и безопасность."
Пока все хорошо. Авторы определили оценку здоровья Avi. Однако оставался "слон в комнате" — как определять термины "производительность", "риски" и т. д. Вот как дальше было конкретизировано определение оценки здоровья:
Performance Score: оценка производительности приложения отражает способность приложения соответствовать и превосходить SLA (соглашения об уровне обслуживания). Метрики производительности должны однозначно показывать хорошее состояние против плохого и указывать на соответствие приложения SLA. В этом случае метрики, такие как максимальное количество одновременных подключений или транзакций в секунду, стали неприемлемы, поскольку эти метрики не могли быть выражены как хорошие или плохие транзакции. Поэтому в VMware построили платформу, использующую множество метрик производительности, таких как качество ответа, качество соединения и качество опыта клиентов, для представления производительности приложения.
Resources Risk (Penalty): следующим важным набором метрик было определение, достаточно ли у приложений ресурсов (или выносливости, энергии и т.д.) для постоянного соответствия требованиям производительности. Оценка здоровья Avi комбинирует несколько метрик, таких как использование CPU, использование памяти, использование программной очереди, использование лицензий и т.д. Вместо прямой шкалы были применены человеческие принципы к ресурсам, которые накладывают штрафы только тогда, когда использование ресурсов превышает пороговое значение (скажем, 80%).
Security Risk (Penalty): так же, как люди лучше работают, когда они находятся в безопасной умственной, физической и социальной среде, в VMware пришли к выводу, что уязвимости приложения должны приводить к снижению его здоровья. Например, использование слабых шифров для SSL приводит к снижению оценки здоровья Avi.
Application Performance Consistency (Anomaly penalty): тут считается, что согласованность производительности является очень важной мерой здоровья приложения. Неважно, если производительность достаточна в периоды низкой нагрузки, если она снижается в периоды пиковой нагрузки.
Теперь, когда определена оценка здоровья Avi, все еще нужно проработать детали того, как комбинировать качество сети с качеством HTTP-ответа, как рассчитывать оценку, когда и память, и CPU используются более чем на 80% и т.д.
Уточнение алгоритма
Пока спор о том, как определить оценку здоровья Avi, еще не был урегулирован, у авторов возник еще один горячий спор о том, как должны работать числа. Аналитическая команда Avi создала два правила, которые должны служить руководящими принципами для объединения информации, связанной со здоровьем приложений:
1. Когда есть две метрики или факторы здоровья различного рода, то используется наименее здоровый фактор для представления Health Score. Например, у человека может быть очень крепкое сердце, но опухоль в головном мозге. Нет смысла вычислять "среднее здоровье" между этими органами, но важно подчеркнуть, что тело не в очень хорошем состоянии из-за опухоли в мозге. Для программного обеспечения выразили эти ситуации как здоровье = min(здоровье_A, здоровье_B), когда необходимо объединить здоровье двух факторов A и B.
2. Когда две метрики или факторы здоровья подобны, то здоровье усредняется по всем подобным факторам. Например, если виртуальная служба имеет 100 серверов, то здоровье пула определяется через среднее здоровье всех 100 серверов, учитывая, что все серверы должны быть схожей природы.
Еще одним важным моментом было, должно ли здоровье приложения основываться на мгновенных метриках или должно включать историю производительности. Большинство пользователей и сотрудников разделились на две группы: 1) команда с опытом в индустрии аппаратного обеспечения, которая отвечала, что здоровье приложения должно основываться на мгновенной информации и 2) команда с программным/операционным опытом, которая склонялась к анализу тенденций и истории. Опять же, в VMware использовали стратегии принятия решений в области здоровья человека, чтобы разрешить спор – считается, что человек еще не в хорошем здоровье, если он все еще восстанавливается после недавней болезни.
Поэтому было принято решение смотреть на метрики последних 6 часов, чтобы определить оценку здоровья приложения. На платформе Avi Vantage, когда администратор приложения видит идеальную оценку здоровья (100), он может с уверенностью сказать, что за предыдущие 6 часов здоровье приложения было идеальным и приложение соответствовало его ожиданиям по производительности.
Avi Health Score - это основа
Процесс получения объективной оценки путем объединения серии субъективных метрик не был простым. Оценка здоровья Avi и метрики и компоненты, определяющие эту оценку, являются темой, над которой очень долго работали в Avi. Как только авторы справились с этим, создание программного обеспечения для имплементации принципов в коде было более простой частью.
Позже определение, которое предложил один из технических советников по здоровью приложений (должно отражать, как приложение функционирует, что оно не должно испытывать нехватку ресурсов и не должно быть аномалий), точно совпало с предложением авторов, о котором он не знал.
Так что теперь вы знаете, как работает метрика Health Score в Avi, и что означают все эти пункты:
В последнем релизе Aria Operations for Networks 6.12 представлено много новых возможностей для обеспечения видимости сети, чтобы помочь пользователям решения VMware Cloud Foundation улучшить производительность сети приложений и устранять проблемы с сетью.
1. Функция Network Map Scope - область видимости сети
Корпоративные сети обширны и сложны, поэтому важно сузить круг устройств, которые могут быть отображены в топологии, когда пользователи устраняют конкретные проблемы с сетевым взаимодействием приложений. Видимость масштаба сети позволяет пользователям создавать визуальную карту области сети для конкретных типов устройств, чтобы лучше понять, где могут возникать проблемы. К типам устройств, которые могут быть включены в область, относятся как физические, так и виртуальные объекты, такие как узлы NSX Host Transport Nodes и NSX Edge Transport Nodes, хосты vCenter, коммутаторы, маршрутизаторы, брандмауэры, балансировщики нагрузки, блейд-серверы и расширители фабрик.
2. Тэги для устройств
Эта новая возможность позволит пользователям создавать теги на основе города, местоположения, дата-центра, отдела, инвентарного номера или пользовательского свойства. Теги помогут пользователям при составлении отчетов или создании панелей мониторинга на основе этих тегов. Пользователи могут добавлять теги к виртуальным машинам, коммутаторам, маршрутизаторам, брандмауэрам и другим физическим и виртуальным устройствам. Теги упрощают идентификацию устройств в сетевой инфраструктуре в рамках повседневной работы.
3. API и Databus
Для качественного устранения неполадок и анализа их причин в средах NSX были представлены несколько API NSX и vCenter для databus, которые будут извлекать метрики через NSX Edge, хост vCenter и кластер хостов vCenter. Примерами улучшенной видимости сети являются метрики хоста vCenter, такие как usage, transmission и drop rate.
4. Сохранение изменений в таблицах и виджетах
Вы долго настраивали таблицу или представление, но эти изменения исчезли, когда возникла другая проблема? В релизе 6.12 пользователям стало легче устранять неполадки, поскольку любые сортировки таблиц, фильтрации, упорядочивание столбцов и предпочтения таблиц, сделанные пользователем - запоминаются. Кроме того, когда пользователь изменяет размер окна или переставляет виджеты, платформа запоминает измененные настройки в различных экранах и пользовательских панелях мониторинга.
5. Уведомления по почте о закрытии алертов
Теперь в релизе 6.12 есть механизм закрытия алертов, который генерирует сообщение SNMP для инструментов вроде ServiceNow и IBM Netcool. В этом случае пользователям может быть отправлено письмо о закрытом алерте. Эта возможность обеспечивает лучшую видимость для ИТ-команд, делая проблемы более доступными для отслеживания со стороны службы поддержки. Новая функция оповещения о закрытом алерте упростит сотрудничество пользователей, позволив им сосредоточить внимание на текущих открытых и актуальных оповещениях.
Более подробно о VMware Aria Operations for Networks 6.12 можно прочитать в Release Notes, а также на странице продукта.
В прошлом году мы много писали о технологии SmartNIC/DPU (data processing unit). На конференции VMworld 2020 Online ковидного года компания VMware представила одну из самых интересных своих инициатив по сотрудничеству с вендорами оборудования - Project Monterey. Тогда же и была представлена технология SmartNIC, которая позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.
SmartNIC - это специальный сетевой адаптер (NIC) c модулем CPU на борту, который берет на себя offload основных функций управляющих сервисов (а именно, работу с хранилищами и сетями, а также управление самим хостом).
DPU (data processing unit) - это эволюционное развитие технологии SmartNIC. Этот модуль включает в себя функции оффлоадинга, гибкого программируемого конвейера, обработки данных и CPU, характерные для SmartNIC. Однако DPU является эндпоинтом сетевой инфраструктуры, а не сервером, в котором он находится. DPU содержат специализированные чипы и, в некоторых случаях, настраиваемые программируемые вентильные массивы или специальные интегральные схемы под конкретный сценарий использования.
DPU может поддерживать гораздо больше функций, чем SmartNIC, включая сетевые возможности на основе программируемых конвейеров P4, состояний брандмауэров четвертого уровня, сетевого взаимодействия L2/L3, балансировки нагрузки L4, маршрутизации хранения данных, аналитики хранения и VPN. Функциональность DPU варьируется в зависимости от производителя. Некоторые из крупнейших игроков на рынке в 2022-2023 годах - это Fungible, AMD Pensando и Marvell.
Недавно компания VMware выпустила интересное видео, в котором рассказывается о производительности и безопасности DPU-модулей, которые существенно улучшают быстродействие сетевой инфраструктуры, при этом повышая уровень безопасности коммуникаций (но, само собой, это стоит дополнительных денег):
Приведем немного интересных скриншотов из видео. Результаты теста iperf по сравнению с обычными сетевыми картами:
Результаты теста под нагрузкой на CPU (здесь очевидно результаты лучше, так как DPU берет на себя функции CPU в части обработки сетевых функций):
Нормализованное использование ядер хостовых процессоров на 1 Гбит/сек при обработке сетевых задач (CPU почти не используется, когда есть DPU):
Таги: VMware, Networking, Performance, Hardware, DPU, SmartNIC, Video
Сегодня мы расскажем о том, как определить пропускную способность сети между площадками при использовании кластеров vSAN HCI и кластеров vSAN Max в конфигурации Stretched Cluster.
В растянутом кластере два домена отказоустойчивости данных содержат один или несколько хостов, а третий домен отказоустойчивости содержит виртуальный модуль Witness для определения доступности сайтов данных. Далее каждый домен отказоустойчивости данных мы будем называть сайтом. Конфигурации растянутого кластера vSAN могут распространяться на разные расстояния, при условии что соблюдаются требования по пропускной способности (bandwidth) и задержке (latency).
Минимально поддерживаемая пропускная способность и latency между сайтами
Пропускная способность, которая требуется между сайтами, в большой степени зависит от объема операций ввода-вывода (I/O), который генерируют рабочие нагрузки, но будут влиять и другие факторы, такие как используемая архитектура (vSAN ESA или OSA), размер кластера и сценарии обработки сбоев. Ниже указаны минимально поддерживаемые значения, но рассчитанные оценки для конкретной инфраструктуры могут привести к требованиям по пропускной способности, превышающим указанные минимумы.
Приведенные ниже формулы помогут оценить необходимую пропускную способность сети между сайтами. Предполагается, что два сайта данных географически расположены достаточно близко друг к другу, чтобы соответствовать требованиям по задержке.
Понимание активности I/O, соотношения чтения и записи и размеров I/O
Рабочие нагрузки состоят из нескольких характеристик. Не только количество активности I/O значительно различается от нагрузки к нагрузке, но чтения и записи часто происходят с разными скоростями и разными размерами I/O. С целью предоставления простой формулы для расчета мы будем использовать следующие переменные для расчета оценочной пропускной способности связи между сайтами для растянутого кластера (ISL):
Скорость I/O всех команд чтения и записи, измеряемая в IOPS
Соотношение чтения/записи (например, 70/30)
Средний размер I/O, измеряемый в KB
Пропускная способность - это измерение на основе скорости, что означает, как много данных передается за определенный период времени. В отличие от измерения неактивных данных, где оно принимает форму байтов, килобайтов и т. д., измерение данных в процессе передачи по сети выражается в битах (b), килобитах (Kb), мегабитах (Mb) или гигабитах (Gb), и период времени - "в секунду" (ps). Обсуждая скорости, мы должны помнить о конвертации байтов в биты.
Давайте используем простой пример, где общий профиль I/O требует 100 000 I/O в секунду (IOPS), в среднем 8 KB каждый, где 70% IOPS - это чтение, и 30% - запись, в растянутой конфигурации. В этом сценарии запись I/O (30 000 IOPS в среднем 8 KB каждый) будет равна 240 000 Kbps или 240 Mbps. Это будет оценкой пропускной способности ISL, необходимой для этого профиля.
Простейший, но потенциально менее точный способ оценки требований к пропускной способности - это просто использовать входные данные, представляющие общие потребности кластера. Если кто-то использует формулу для расчета отдельных рабочих нагрузок в кластере, сумма этих расчетов предоставит результирующие требования к пропускной способности. Возможно, вы захотите выделить гораздо больше минимального рассчитанного количества, так как рабочие нагрузки со временем неизбежно становятся более ресурсоемкими.
Формулы для расчета оценок пропускной способности указаны ниже, они привязаны к используемой архитектуре: vSAN OSA или vSAN ESA. С введением архитектуры vSAN Express Storage (ESA) появляются все новые возможности по обеспечению производительности хранилища на совершенно новом уровне. Поэтому при использовании ESA рекомендуется тщательно отслеживать использование ISL, чтобы убедиться, что есть достаточная пропускная способность, необходимая для того, чтобы рабочие нагрузки не были ограничены со стороны ISL. Для дополнительной информации см. статью: "Использование vSAN ESA в топологии растянутого кластера".
Формулы расчета пропускной способности для vSAN ESA
Трафик репликации от I/O гостевой ВМ - это доминирующий тип трафика, который мы должны учесть при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). У растянутых кластеров vSAN ESA трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ. Требуемая пропускная способность между двумя сайтами данных (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr) * коэффициент сжатия (CR).
Расчет пропускной способности для ISL, обслуживающего растянутый кластер vSAN с использованием ESA, отличается от формулы, используемой для OSA. vSAN ESA сжимает данные до их репликации между сайтами. В результате ESA уменьшает использование пропускной способности ISL, эффективно увеличивая его возможности для передачи большего количества данных.
Чтобы учесть это в расчете в топологии, использующей ESA, формула учитывает оценочное соотношение сжатия сохраненных данных. Давайте рассмотрим следующий пример, где мы оцениваем экономию в 2 раза благодаря использованию сжатия в vSAN ESA. Мы используем простое значение "2x" (также называемое 2:1 или 50%) для простоты. Фактические коэффициенты сжатия будут зависеть от данных, хранящихся в вашей среде. Пример 2:1 - это не предположение о том, что вы на самом деле можете увидеть в своей среде.
Преобразуйте это в процент от исходного размера, разделив конечный размер на начальный размер. Это даст, например, результат ".50".
Умножьте окончательное рассчитанное значение из описанной в этой статье формулы на ".50".
В результате формула будет выглядеть так:
B = Wb * md * CR * mr * CR
Как отмечалось выше, коэффициенты сжатия часто могут быть представлены разными способами, чтобы выразить экономию места.
Например:
Сжатие, выраженное в соотношении. [начальный размер]:[конечный размер]. Соотношение сжатия 2:1 указывает на то, что данные будут сжаты до половины своего исходного размера.
Сжатие, выраженное в виде множителя экономии. Соотношение сжатия 2x указывает на то, что данные будут сжаты до половины своего исходного размера. Это то, что отображается в представлении ёмкости кластера vSAN.
Сжатие, выраженное в процентах от исходного размера. Значение сжатия 50% (или, .50) указывает на то, что данные будут сжаты до половины своего исходного размера.
Примеры между сайтами (для vSAN ESA)
Рабочая нагрузка 1
С примером рабочей нагрузки в 10 000 записей в секунду на рабочую нагрузку vSAN со средним размером записи 8 KB потребуется 80 МБ/с или 640 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 640 Мбит/с * 1.4 * 1.25 * .50 = 560 Мбит/с.
Учитывая требования к сети vSAN, требуемая пропускная способность составляет 560 Мбит/с.
Рабочая нагрузка 2
В другом примере, 30 000 записей в секунду, 8KB записи, потребуется 240 MB/s или 1 920 Мбит/с пропускной способности. Предположим, что данные имеют коэффициент сжатия 2x.
B = 1,920 Мбит/с * 1.4 * 1.25 * .50 = 1,680 Мбит/с или примерно 1,7 Гбит/с.
Требуемая пропускная способность составляет примерно 1,7 Гбит/с.
Рабочие нагрузки редко состоят только из чтений или записей, и обычно включают общее соотношение чтения к записи для каждого варианта использования. Используя общую ситуацию, когда общий профиль I/O требует 100 000 IOPS, из которых 70% являются записью, а 30% чтением, в растянутой конфигурации, IO записи - это то, на что рассчитана пропускная способность межсайтовой связи. С растянутыми кластерами vSAN, трафик чтения по умолчанию обслуживается сайтом, на котором находится ВМ.
Формулы расчета пропускной способности для vSAN OSA
Как и в растянутых кластерах с использованием ESA, трафик репликации от I/O гостевой ВМ в растянутом кластере с использованием OSA является доминирующим типом трафика, который мы должны учитывать при оценке необходимой пропускной способности для трафика межсайтовой связи (ISL). В растянутых кластерах vSAN OSA трафик чтения по умолчанию обслуживается сайтом, на котором размещена ВМ. Требуемая пропускная способность между двумя данными сайтами (B) равна пропускной способности записи (Wb) * множитель данных (md) * множитель ресинхронизации (mr), или:
B = Wb * md * mr
Множитель данных состоит из накладных расходов на трафик метаданных vSAN и различных связанных операций. VMware рекомендует использовать множитель данных 1.4. Множитель ресинхронизации включен для учета событий ресинхронизации. Рекомендуется выделять пропускную способность по верхней границе требуемой пропускной способности для событий ресинхронизации. Для учета трафика ресинхронизации рекомендуются дополнительные 25%.
Планируйте использование vSAN ESA для всех новых кластеров vSAN. Эта архитектура быстрее и эффективнее, чем vSAN OSA, и, зачастую, уменьшает количество хостов, необходимых для того же объема рабочих нагрузок. Формула для vSAN OSA остается актуальной для тех, у кого уже есть установки vSAN OSA.
Требования к пропускной способности между Witness и сайтом данных
В топологии растянутого кластера хост-машина Witness просто хранит компоненты, состоящие из небольшого объема метаданных, которые помогают определить доступность объектов, хранящихся на сайтах с данными. В результате сетевой трафик, отправляемый на сайт для этой машины, довольно мал по сравнению с трафиком между двумя сайтами с данными через ISL.
Одной из наиболее важных переменных является объем данных, хранящихся на каждом сайте. vSAN хранит данные в виде объектов и компонентов. Она определяет, сколько компонентов нужно для данного объекта, и где они должны быть размещены по всему кластеру, чтобы поддерживать устойчивость данных в соответствии с назначенной политикой хранения.
Архитектура vSAN ESA обычно использует больше компонентов, чем OSA. Это следует учитывать при расчете потенциально необходимой пропускной способности для машины Witness.
Обязательно выберите правильный размер хоста vSAN Witness. При развертывании предлагается четыре размера машины (Tiny, Medium, Large и Extra Large), каждый из которых предназначен для размещения разных размеров сред. Посмотрите статью "Deploying a vSAN Witness Appliance" для получения дополнительной информации.
Формулы расчета пропускной способности Witness для vSAN ESA и OSA
Сетевое взаимодействие сайтов с Witnessn состоит исключительно из метаданных, что делает запросы к сетевым ресурсам Witness гораздо более легковесными, что отражается в поддерживаемых минимальных требованиях к пропускной способности и задержке.
Поскольку формула для оценки необходимой пропускной способности Witness основана на количестве компонентов, ее можно использовать для расчета растянутых кластеров, использующих OSA или ESA. Поскольку ESA обычно использует больше компонентов на объект (возможно, в 2-3 раза больше) по сравнению с OSA, следует учитывать большее количество компонентов на ВМ при использовании архитектуры на базе ESA.
Базовая формула
Требуемая пропускная способность между Witness и каждым сайтом равна ~1138 Б x Количество компонентов / 5с
1138 Б x Кол-во компонентов / 5 секунд
Значение 1138 Б происходит от операций, которые выполняются, когда предпочтительный сайт выходит из строя, и второстепенный сайт берет на себя владение всеми компонентами. Когда основной сайт выходит из строя, второстепенный сайт становится лидером. Witness отправляет обновления новому лидеру, после чего новый лидер отвечает Witness, по мере обновления владения. Требование в 1138 Б для каждого компонента происходит из сочетания полезной нагрузки от Witness к резервному агенту, за которым следуют метаданные, указывающие, что предпочтительный сайт не работает. В случае отказа предпочтительного сайта, связь должна быть достаточно хорошей, чтобы позволить изменение владения кластером, а также владение всеми компонентами в течение 5 секунд.
Примеры пропускной способности Witness к сайту (OSA)
Нагрузка 1
Если ВМ состоит из:
3 объектов
Параметр допустимого числа отказов (FTT=1)
Приблизительно 166 ВМ с этой конфигурацией потребовало бы, чтобы Witness содержал 996 компонентов (166 ВМ * 3 компонента/ВМ * 2 (FTT+1) * 1 (Ширина полосы)). Чтобы успешно удовлетворить требования пропускной способности Witness для общего числа 1 000 компонентов на vSAN, можно использовать следующий расчет:
Преобразование байтов (Б) в биты (б), умножьте на 8:
В = 1138 Б * 8 * 1 000 / 5с = 1 820 800 бит в секунду = 1.82 Мбит/с
VMware рекомендует добавить безопасный запас в 10% и округлить вверх.
B + 10% = 1.82 Мбит/с + 182 Кбит/с = 2.00 Мбит/с
Таким образом, с учетом безопасного запаса в 10%, можно утверждать, что для каждых 1 000 компонентов подходит канал 2 Мбит/с.
Нагрузка 2
Если ВМ состоит из:
3 объектов
FTT=1
Stripe с параметром 2
Приблизительно 1 500 ВМ с этой конфигурацией потребовало бы хранения 18 000 компонентов на Witness. Чтобы успешно удовлетворить требования пропускной способности Witness для 18 000 компонентов на vSAN расчет будет таким:
B = 1138 Б * 8 * 18 000 / 5с = 32 774 400 бит в секунду = 32.78 Мбит/с
B + 10% = 32.78 Мбит/с + 3.28 Мбит/с = 36.05 Мбит/с
Используя общее уравнение 2 Мбит/с на каждые 1 000 компонентов, (NumComp/1000) X 2 Мбит/с, можно увидеть, что 18 000 компонентов действительно требует 36 Мбит/с.
Пропускная способность Witness для конфигураций с 2 узлами (OSA)
Пример удаленного сайта 1
Рассмотрим пример 25 ВМ в конфигурации с 2 узлами, каждая с виртуальным диском 1 ТБ, защищенные при FTT=1 и Stripe Width=1. Каждый vmdk будет состоять из 8 компонентов (vmdk и реплика) и 2 компонентов для пространства имен ВМ и swap-файла. Общее количество компонентов составляет 300 (12/ВМx25ВМ). С 300 компонентами, используя правило (300/1000 x 2 Мбит/с), требуется пропускная способность 600 кбит/с.
Пример удаленного сайта 2
Рассмотрим другой пример 100 ВМ на каждом хосте, с таким же ВМ выше, с виртуальным диском 1 ТБ, FTT=1 и SW=1. Общее количество компонентов составляет 2 400. Используя правило (2 400/1000 x 2 Мбит/с), требуется пропускная способность 4.8 Мбит/с.
Вот так и рассчитывается пропускная способность для разных рабочих нагрузок и конфигураций в среде vSAN. Понимание этих метрик и формул поможет в проектировании и развертывании решений vSAN, которые обеспечивают оптимальную производительность и надежность.
Недавно опубликованный компанией VMware технический документ "Troubleshooting TCP Unidirectional Data Transfer Throughput" описывает, как устранить проблемы с пропускной способностью однонаправленной (Unidirectional) передачи данных по протоколу TCP. Решение этих проблем, возникающих на хосте vSphere/ESXi, может привести к улучшению производительности. Документ предназначен для разработчиков, опытных администраторов и специалистов технической поддержки.
Передача данных по протоколу TCP очень распространена в средах vSphere. Примеры включают в себя трафик хранения между хостом VMware ESXi и хранилищем данных NFS или iSCSI, а также различные формы трафика vMotion между хранилищами данных vSphere.
В компании VMware обратили внимание на то, что даже крайне редкие проблемы с TCP могут оказывать несоразмерно большое влияние на общую пропускную способность передачи данных. Например, в некоторых экспериментах с чтением NFS из хранилища данных NFS на ESXi, кажущаяся незначительной потеря пакетов (packet loss) в 0,02% привела к неожиданному снижению пропускной способности чтения NFS на 35%.
В документе описывается методология для выявления общих проблем с TCP, которые часто являются причиной низкой пропускной способности передачи данных. Для этого производится захват сетевого трафика передачи данных в файл трассировки пакетов для офлайн-анализа. Эта трассировка пакетов анализируется на предмет сигнатур общих проблем с TCP, которые могут оказать значительное влияние на пропускную способность передачи данных.
Рассматриваемые проблемы с TCP включают в себя потерю пакетов и их переотправку (retransmission), длительные паузы из-за таймеров TCP, а также проблемы с Bandwidth Delay Product (BDP). Для проведения анализа используется решение Wireshark и описывается профиль для упрощения рабочего процесса анализа. VMware описывает системный подход к выявлению общих проблем с протоколом TCP, оказывающих значительное влияние на пропускную способность канала передачи данных - поэтому инженерам, занимающимся устранением проблем с производительностью сети, рекомендуется включить эту методологию в стандартную часть своих рутинных проверок.
В документе рассмотрены рабочие процессы для устранения проблем, справочные таблицы и шаги, которые помогут вам в этом нелегком деле. Также в документе есть пример создания профиля Wireshark с предустановленными фильтрами отображения и графиками ввода-вывода, чтобы упростить администраторам процедуру анализа.
Скачать whitepaper "Troubleshooting TCP Unidirectional Data Transfer Throughput" можно по этой ссылке.
Прошлой осенью мы писали о версии 6.8 этого продукта, а сегодня посмотрим на нововведения версии 6.11:
Улучшения в обнаружении приложений на основе потоков - теперь пользователи могут загружать дополнительные данные приложений через файлы .csv или из CMDB (например, ServiceNow).
Улучшения траблшутинга VMware HCX в плане идентификации потоков и виртуальных машин с включенным MON (Mobility Optimized Networking).
Улучшения Network Assurance and Verification для поддержки карты сети (Network Map): массовый выбор объектов, сброс группы, перетаскивание и прочие улучшения группировки.
Улучшения в оповещениях SNMP для Problem entity и Entity manager (поля IBM Netcool).
Поддержка Ubuntu 20.04.
Поддержка TLS 1.3.
Возможность изменения имени хоста для узлов Platform и Collector.
Допускается смешивание лицензий на процессор и ядра на одной платформе (универсальное лицензирование).
Обнаружение устройств Fortinet для облегчения интеграции с существующей инфраструктурой безопасности.
В целом, с учетом всех новых возможностей в версии 6.11, VMware Aria Operations for Networks становится все более мощным инструментом для предприятий, которые хотят гарантировать, что их приложения и сеть работают на максимальной производительности.
Более подробная информация о продукте доступна по этой ссылке.
Недавно мы писали о большом релизе облачной архитектуры VMware Cloud Foundation 5.0 (VCF), неотъемлемой частью которой является решение VMware NSX, предназначенное для для виртуализации, агрегации и централизованного управления сетями виртуального датацентра.
Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
Давайте взглянем на основную новую функциональность NSX:
Если кратко, то вот основные моменты, которые заслуживают внимания:
VMware Cloud Foundation 5.0 с поддержкой NSX 4.1 предлагает усовершенствования платформы, такие как многопользовательский доступ к ресурсам сети и NAPP 4.0.1.1.
Antrea - это проект, совместимый с платформой Kubernetes, который реализует CNI и политики сетей Kubernetes для обеспечения сетевой связности и безопасности рабочих нагрузок в подах (pods). NSX 4.1 представляет новые усовершенствования сетевого взаимодействия и безопасности контейнеров, которые позволяют создавать правила сетевого экрана с комбинацией виртуальных машин и ingress/egress объектов Kubernetes.
Дополнительные службы сетевой маршрутизации уровня 3 становятся доступными для фабрики VMware Cloud Foundation Fabric за счет развертывания маршрутизации между VRF.
Улучшенная онлайн-система диагностики, которая содержит шаги для отладки и устранения конкретных проблем.
Теперь рассмотрим все это подробнее:
Улучшения в области сетевого взаимодействия и безопасности
VMware Container Networking with Antrea предлагает пользователям подписанные образы и бинарные файлы, а также полную корпоративную поддержку для проекта Antrea. VMware Container Networking интегрируется с управляемыми сервисами Kubernetes для дальнейшего улучшения сетевых политик Kubernetes. Также поддерживаются рабочие нагрузки Windows и Linux на Kubernetes в нескольких облаках.
NSX 4.1 имеет новые улучшения в области сетевого взаимодействия и безопасности контейнеров, которые позволяют создавать правила сетевого экрана с комбинацией виртуальных машин и объектов Kubernetes. Кроме того, можно создавать динамические группы на основе тегов NSX и меток Kubernetes. Это улучшает удобство использования и функциональность управления кластерами Antrea с помощью NSX.
Пользователи имеют возможность создания политик сетевого экрана, которые разрешают и/или блокируют трафик между различными виртуальными машинами и модулями Kubernetes в одном правиле. Также вводится новая точка принудительного выполнения, которая включает все эндпоинты, а эффективное применение (apply-to) определяется на основе исходных и целевых групп участников.
Более эффективная защита от кибератак с функциональностью NDR
По мере того как сетевые атаки становятся все более распространенными, возрастает важность использования новейших функций в области безопасности. Развертывание NSX 4.1.0 как части VMware Cloud Foundation 5.0 с новыми возможностями распределенного сетевого экрана в сочетании с новыми функциями NDR улучшает защиту.
Технология обнаружения и реагирования на сетевые угрозы (Network Detection and Response, NDR) позволяет команде безопасности визуализировать цепочки атак, преобразуя огромное количество сетевых данных в несколько "кампаний вторжения". NDR строит такие визуализации, объединяя и сопоставляя события безопасности, такие как обнаруженные вторжения, подозрительные объекты и аномальные сетевые потоки.
Усовершенствованная система онлайн-диагностики
Онлайн-диагностика предлагает предопределенные руководства (runbooks), которые содержат шаги отладки для устранения конкретной проблемы. Руководства по устранению неполадок или runbooks - это серия шагов или процедур, которые следует выполнять для диагностики и устранения проблем в системе или приложении. Они разработаны для структурированного подхода к устранению неполадок и помогают быстро и эффективно решать проблемы.
Эти руководства можно вызвать через API, и они запустят шаги отладки с использованием CLI, API и скриптов. После отладки будут предложены рекомендуемые действия для исправления проблемы, а сгенерированные в ходе отладки артефакты можно загрузить для дальнейшего анализа.
Больше технических ресурсов и руководств для архитектуры VMware Cloud Foundation 5.0 вы можете найти на этой странице.
Архитектура SD-WAN является отличным инструментом для организаций, стремящихся оптимизировать производительность сети и улучшить связность между географически разбросанными локациями. Однако, чтобы получить полную выгоду от SD-WAN, вам необходимы эффективные операционные средства и утилиты для мониторинга. Это становится всё более важным из-за операционных сложностей и проблем с безопасностью, которые возникают по мере того как SaaS-приложения становятся более популярными, а пользователи могут работать из любого места.
VMware SD-WAN имеет мощные возможности, включая технологию VMware Edge Network Intelligence, которые помогут вам идентифицировать и решить проблемы с сетью прежде, чем они станут большими проблемами, использовать ресурсы на полную мощность, и обеспечить качественный пользовательский опыт. В видео ниже показаны некоторые из лучших практик для оперирования и мониторинга сети SD-WAN, с акцентом на мониторинг производительности в реальном времени, мониторинг безопасности и видимость приложений.
Мониторинг производительности в реальном времени
Возможность видеть поведение сети в реальном времени необходима для обеспечения оптимальной производительности сети и своевременного определения и решения потенциальных проблем. Вот некоторые лучшие практики эксплуатации сетей SD-WAN:
Мониторьте состояние сети - VMware SASE Orchestrator предоставляет детальное отображение показателей производительности сети, таких как latency, jitter и потери пакетов для каждого доступного WAN-соединения. В то время как функция Dynamic Multipath Optimization (DMPO) автоматически с миллисекундной задержкой принимает меры по устранению проблем со статусом соединения, она также может мониторить состояние сети и использование пропускной способности в реальном времени, чтобы своевременно выявить и решить любые проблемы с производительностью.
Включите механизмы оповещения - настройте алерты для платформ управления производительностью сети для сетевых параметров для метрик, таких как использование связи, потеря пакетов или отклонения в производительности приложения. Это позволяет получать своевременные уведомления, когда производительность отклоняется от ожидаемых уровней, давая возможность проактивно устранять неполадки. Потоковые метрики, которые предоставляются Webhooks и NetFlow, могут быть проанализированы для формирования почти в реальном времени представления о состоянии сети и производительности. Механизмы по запросу, такие как SNMP и API-вызовы, также могут быть использованы для периодического получения автоматизированных снимков состояния сети.
Используйте AI/ML аналитику - продвинутые платформы сетевой аналитики предоставляют ценные, пригодные для использования инсайты в среде SD-WAN для сетевого окружения на периферии. VMware Edge Network Intelligence использует техники искусственного интеллекта (AI) и машинного обучения (ML) для сбора, анализа и обработки данных о телеметрии сети в реальном времени от устройств на периферии. VMware Edge Network Intelligence позволяет пользователям выполнять мониторинг в реальном времени, обнаружение аномалий, прогнозирование, анализ безопасности, визуализацию, отчетность, интеграцию и автоматизацию. Он постоянно отслеживает сетевой трафик и показатели производительности на периферии, и может обнаруживать аномалии и ненормальные паттерны в поведении сети.
Применяйте непрерывный бенчмаркинг - используйте инструменты для непрерывного мониторинга, чтобы собирать и анализировать данные о производительности на постоянной основе. Это позволяет выявлять паттерны и тенденции, помогая администраторам сети принимать обоснованные решения для планирования емкости и оптимизации. Также фиксируйте ценные исторические базовые показатели производительности, которые могут быть использованы для определения, привели ли изменения в сети к улучшению или ухудшению производительности. Периодические автоматизированные отчеты также могут быть использованы для предоставления ценных исторических инсайтов и точек сравнения.
Хотя все эти механизмы рекомендуется использовать, большинство организаций могут сосредоточиться на некотором их подмножестве, которое наилучшим образом соответствует операционным требованиям и целям производительности. Возможности интеграции любых существующих платформ для логирования и алертинга также могут играть роль в выборе наилучших механизмов оповещения.
Кроме того, интегрированное решение на базе AI/ML, такое как VMware Edge Network Intelligence, может сократить необходимость передачи метрик для анализа стороннему решению и сократить среднее время до устранения проблем (mean-time-to-resolution).
Видимость приложений
Для обеспечения оптимальной производительности и пользовательского опыта критически важно иметь широкую видимость трафика приложений. Здесь можно рассмотреть следующие практики:
Используйте маршрутизацию соединений на базе приложений - осведомленность о приложениях предоставляет дополнительный способ контролировать трафик, соответствовать бизнес-целям организации и более эффективно использовать доступные сетевые каналы. Например, трафик критически важных или чувствительных приложений с более высоким приоритетом может быть настроен на использование более безопасных частных соединений, в то время как приложения с более низким приоритетом могут оставаться на более дешевых интернет-соединениях. VMware SD-WAN позволяет осуществлять маршрутизацию, основанную на приложениях, позволяя вам отдавать приоритет критически важным приложениям по сравнению с менее важным трафиком, и имеет возможность динамически перемещать трафик приложений с одного соединения на другое при необходимости.
Используйте инструменты мониторинга производительности приложений (Application Performance Monitoring, APM) - инструменты APM предоставляют глубокие инсайты о метриках производительности приложений, включая время отклика, пропускную способность и успешность транзакций. Эти инструменты помогают администраторам определять проблемы, связанные с приложениями, и эффективно их устранять.
Отслеживайте пользовательский опыт - реализуйте мониторинг пользовательского опыта end-to-end, включая время отклика и доступность приложений. VMware Edge Network Intelligence обеспечивает видимость пользовательского опыта, позволяя администраторам заблаговременно решать проблемы производительности. VMware Edge Network Intelligence обеспечивает динамический бенчмаркинг для приложений в реальном времени, таких как Zoom, и предупреждает о любых значительных отклонениях от этого бенчмарка. Он также отслеживает связанные индикаторы и предоставляет предложения по устранению основной причины проблем, сокращая среднее время до их устранения и, во многих случаях, позволяя ИТ-команде заранее решить проблему, прежде чем она затронет конечных пользователей.
Мониторинг безопасности
Обеспечение безопасности вашей SD-WAN сети является первоочередной задачей. Поскольку SD-WAN становится частью более крупного интегрированного решения SASE, важно, чтобы команды, отвечающие за транспорт и безопасность, также интегрировали свои операционные политики для обеспечения координации мониторинга, логирования, оповещений и отчетности, их согласованности и совместного управления. Вместо двух отдельных действий единый подход обеспечивает обеим командам полное представление о состоянии сети.
Вот ключевые практики для реализации лучших практик SD-WAN по безопасности:
Использовать безопасные соединения - для защиты конфиденциальности и подлинности трафика, проходящего через сетевой оверлей SD-WAN, следует использовать безопасные протоколы, такие как IPsec. SD-WAN от VMware использует шифрованный оверлей на основе IPsec для обеспечения подлинности и конфиденциальности трафика, использующего сети транспорта WAN. Также поддерживаются туннели на основе IPSec и GRE для подключения к не-SD-WAN назначениям.
Реализовать фаерволы нового поколения (next-generation firewalls, NGFW) - организации имеют возможность использовать интегрированный файрвол на основе приложений, размещенный на периферии, IDS и IPS, а также VMware Cloud Web Security для проверки и фильтрации трафика на предмет потенциальных угроз. Также поддерживается интеграция с решениями NGFW от сторонних производителей. Это обеспечивает многоуровневый подход к безопасности против вредоносных действий, а также детальную видимость для попыток вредоносной активности. Эта видимость критически важна для быстрого анализа угрозы и принятия мер по ее устранению, если это необходимо.
Мониторинг событий безопасности - используйте решения по управлению информацией и событиями безопасности (security information and event management, SIEM) для мониторинга и определения корреляции событий безопасности в сети SD-WAN. Анализируя логи и генерируя предупреждения, администраторы могут быстро реагировать на инциденты безопасности.
События безопасности могут быть записаны и проанализированы через логи файрвола, а также интеграцию с платформами SIEM. Orchestrator SASE от VMware также имеет обновляемый в реальном времени дэшборд обнаруженных угроз, включая информацию о затронутых локациях, распределение угроз и их источники.
На сайте проекта VMware Labs обновился пакет драйверов USB Network Native Driver for ESXi до версии 1.12. Напомним, с помощью данных драйверов пользователи могут подключать различные сетевые устройства к ESXi через USB-порт, например дополнительные сетевые адаптеры хостов, если у них больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этого комплекта драйверов мы рассказывали тут.
Компания VMware недавно выпустила новую версию своей основной платформы для виртуализации, агрегации и централизованного управления сетями виртуального датацентра VMware NSX 4.1. Напомним, что о прошлой версии этого решения - VMware NSX 4.0 - мы рассказывали вот тут.
Давайте посмотрим, что там появилось нового:
1. Отправка логов IDS/IPS к NDR
В NSX 4.1 появилась возможность отправки логов системы IDS/IPS от NSX Gateway firewall (GFW) к компоненту Network Detection and Response (NDR), который является частью продукта VMware NSX Advanced Threat Prevention (ATP). Эта функциональность бесплатна для пользователей NSX Distributed Firewall (DFW), в котором есть возможности отправляемых логов IDS/IPS в NDR. Теперь пользователи могут получить больше средств мониторинга сетевой активности и более эффективно и быстро реагировать на возникающие угрозы. За счет анализа логов IDS/IPS от GFW и DFW, в комбинации с функциями Network Traffic Analysis (NTA) и Sandboxing, система NDR может сопоставлять события и идентифицировать паттерны атак, предоставляя пользователю полную картину угроз, существующих в корпоративной сети.
2. Защита Windows 11
В NSX 4.1 появилась поддержка механизма NSX Guest Introspection для ОС Windows 11, что дает расширенные инструменты обнаружения угроз и борьбы с ними для виртуальных машин. Все прошлые версии Windows и Linux также продолжают поддерживаться. Guest Introspection использует тонкий драйвер-агент в составе VMware Tools, чтобы предоставлять информацию в реальном времени о состоянии виртуальных машин, чтобы наиболее эффективно принимать меры по обеспечению безопасности.
3. Улучшенная безопасность контейнеров
Теперь появились расширенные функции по защите контейнеров на базе политик с централизованным управлением правилами сетевого экрана за счет интеграции Antrea и NSX. Теперь в NSX 4.1 правила фаервола могут быть созданы для обоих объектов - Kubernetes и NSX, а динамические группы можно создавать как на базе тэгов NSX, так и на основе меток Kubernetes. Также в этом релизе можно создавать политики фаервола, которые позволяют блокировать/разрешать трафик между виртуальными машинами и Kubernetes pods в рамках одного правила. Правила фаервола могут быть также применены к эндпоинтам, которые включают объекты NSX и Kubernetes. Кроме того, в NSX 4.1 есть улучшения пользовательского интерфейса и компонента Traceflow, которые дают возможности расширенного траблшутинга и централизованного управления сетевыми политиками Kubernetes через консоль NSX.
4. Поддержка IPv6
В NSX 4.0 были добавлены функции IPv6 based Management Plane, которые поддерживали коммуникацию от внешних систем к NSX management cluster (только для Local Manager). Это включало в себя поддержку NSX Manager для двойного стека IPv4 и IPv6 во внешнем управляющем интерфейсе. В NSX 4.1 теперь появилась поддержка IPv6 для коммуникации Control-plane и Management-plane между Transport Nodes и NSX Manager. Кластер NSX manager cluster должен быть по-прежнему быть развернут в режиме dual-stack и позволяет поддерживать коммуникацию транспортных узлов (хостов ESXi и узлов Edge Nodes) через IPv4 и IPv6. Если Transport Node настроен как dual-stack, то коммуникация через IPv6 является предпочтительной.
5. Маршрутизация Inter-VRF
В этом релизе представлена более расширенная модель для VRF interconnect и route leaking. Пользователи могут настраивать маршрутизацию inter-VRF с использованием более простых рабочих процессов и средств управления путем импорта и экспорта маршрутов между объектами VRF. Клиенты облака в разных VRF получают полный контроль над своим частным пространством маршрутизации и могут принимать независимые решения по маршрутам (accept / advertise).
6. Улучшения Multi-Tenancy
В NSX 4.1 появились новые конструкты для окружений с несколькими клиентами, что позволяет более гибко выделять ресурсы и управлять операционными задачами. Enterprise Admin (Provider) может сегментировать платформу на проекты, давая разные пространства для разных клиентов, сохраняя полный контроль над окружением. Это расширение к модели потребления ресурсов позволяет пользователям NSX потреблять собственные объекты, просматривать алармы только для своих конфигураций, а также тестировать соединение между рабочими нагрузками и Traceflow.
Пользователи могут переключать контекст из одного проекта на другой на базе настроенных прав RBAC (role-based access control). Пользователи, привязанные только к конкретным проектам, сохраняют доступ только к ним. Логи можно привязать к проекту, используя функцию "Project short log id", которую можно применить к логам Gateway Firewall и Distributed Firewall.
7. Онлайн-система диагностики
В NSX 4.1 появилась Online Diagnostic System - новая возможность, которая упрощает траблшутинг и помогает автоматизировать процесс отладки. Эта система содержит предопределенные runbooks, которые содержат шаги по отладке и траблшутингу для специфических ситуаций. Данные runbooks можно вызвать через API и обрабатывать шаги отладки через CLI, API и пользовательские сценарии. Рекомендуемые действия предоставляются после отладки, чтобы дать инструменты решения проблем, а также артефакты, сгенерированные во время отладки, могут быть загружены для последующего анализа.
Более подробно о новых возможностях VMware NSX 4.1 можно почитать в Release Notes. Основная страница продукта находится вот тут.
На сайте проекта VMware Labs вышло еще одно полезное обновление - комплект драйверов USB Network Native Driver for ESXi версии 1.11. USB-драйвер для ESXi может понадобиться для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этого комплекта драйверов мы рассказывали тут.
Основным и единственным нововведением данного комплекта стала поддержка гипервизора VMware ESXi 8.0 в составе VMware vSphere 8.0 (пакет SXi800-VMKUSB-NIC-FLING-61054763-component-20826251.zip).
Актуальная таблица поддерживаемых сетевых адаптеров на сегодня выглядит так:
Установка драйвера для vSphere версии 7.0 и выше выполняется командой:
Не секрет, что являясь конкурентами в плане технологий виртуализации, компании VMware и Microsoft также ведут и сотрудничество. Как раз результатом такого сотрудничества и стала интеграция драйверов VMware Paravirtual SCSI controller (PVSCSI) в операционную систему Microsoft Windows 11, начиная с версии 2H22 (выпущена 20 сентября этого года).
Раньше при установке гостевой ОС в виртуальной машине на дисках PVSCSI система Windows просто не видела диски на этом контроллере, поэтому установить ее на них было нельзя. Теперь же на шаге обнаружения диска и сетевых устройств (виртуальный сетевой адаптер с драйверов VMware VMXNET3) вы можете их увидеть в рамках рабочего процесса Windows Out of Box Experience (OOBE):
Между тем, это вовсе не значит, что после установки операционной системы вы не должны устанавливать пакет VMware Tools. Его обязательно нужно поставить, так как он содержит не только драйверы устройств, но и другие важные вспомогательные инструменты.
Также драйверы VMware Paravirtual SCSI и VMware VMXNET3 теперь включены в обновления Windows Updates:
Для получения более подробной информации об интеграции службы обновлений Windows и драйверов VMware вы можете воспользоваться статьей KB 82290 или поиском в Microsoft Update Catalog.
На сайте проекта VMware Labs появилась еще одна интересная утилита Horizon Network Label Assignment Tool. Она предназначена для решения проблемы исчерпания IP-адресов в сетях, назначаемых виртуальным машинам пулов VMware Horizon.
Виртуальные десктопы в пулах Horizon Automated Linked Clone или Full Clone по умолчанию наследуют сетевой интерфейс (NIC) с сетью (network label) от родительской виртуальной машины или шаблона. Это означает, что если в этой сети кончаются IP-адреса, то там уже нельзя развернуть новые машины и администратору нужно как-то расширить диапазон адресов в сети для пула или добавить новую сеть, назначив ее членам пула.
Horizon Network Label Assignment Tool помогает администратору развертывать большие пулы десктопов с одной родительской виртуальной машиной (Parent Virtual Machine) или шаблоном (Template) за счет установки сети из нескольких доступных, которые настроены на хосте ESXi нужного кластера. Утилита также дает возможность сбросить и просмотреть установленные ранее настройки network label в табличном формате.
Network Label Assignment Tool дает возможность изменять сети для следующих пулов и ферм виртуальных ПК:
Пулы Linked Clones Automated Desktop
Пулы Full Clone Automated Desktop
Фермы RDS (Linked Clones)
Вот какие настройки доступны в интерфейсе утилиты:
Задание настроек Network Label для пулов и ферм
Сброс этих настроек до изначальной сети родительской ВМ или шаблона
Просмотр существующих настроек для пулов и ферм
Утилита Horizon Network Label Assignment Tool построена на базе Windows PowerShell и имеет следующие требования:
Windows 10 x64 / Windows Server 2016 или более поздние
PowerShell версии 5.1
Модуль VMware PowerCLI
Horizon 7.13.x / Horizon 8 2006 (поддержка пулов и ферм) Horizon 8 2012 (поддержка только пулов) или более поздние
Скачать Horizon Network Label Assignment Tool можно по этой ссылке, документация доступна тут.
Недавно мы писали об анонсированной на конференции VMware Explore 2022 платформе VMware Aria, которая пришла на смену семейству продуктов VMware vRealize для управления кросс-облачными виртуальными датацентрами, присоединив к себе решение Skyline.
Сегодня мы поговорим еще об одном продукте VMware Aria Operations for Networks 6.8, сменившем средство vRealize Network Insight 6.7, продвинув его версию на 0.1. Напомним, что vRNI - это платформа для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре.
Первое большое нововведение Aria Operations for Networks - это обновленный стартовый дэшборд, где собрана сводная информация об инфраструктуре сетевых взаимодействий виртуального датацентра.
Здесь есть информация о здоровье платформы и ее сборщиков, различные источники данных, такие как vCenter, NSX-T, AWS и физические серверы, алерты, инстайты в сетевом разрезе, а также выявленные аномалии.
Также тут представлены тепловые карты окружения, объединяющего онпремизные, облачные и гибридные облачные ресурсы. Среди инсайтов представлены рекомендации по оптимизации правил фаерволов, подсистемы безопасности и многого другого, что требует внимания администратора.
Ну и главное, что здесь визуально видно, что именно требует немедленного реагирования, чтобы обеспечить работоспособность, безопасность и производительность приложений:
Также появились улучшения функций Network Assurance and Verification, основанных на приложениях. Теперь они позволят повысить производительность за счет нахождения проблем в TCP-трафике с точки зрения задержек (latency), повторной передачи и отображения алертов на дэшборде. Также есть возможность сравнить поведение приложения на разном оборудовании инфраструктуры, чтобы определить есть ли ошибки конфигурации, такие как некорректный размер пакета или MTU.
Онпремизные инсталляции теперь поддерживают функции Guided Network Troubleshooting (ранее было доступно только для SaaS-версии), которые позволяют визуализовать взаимозависимости компонентов и пройти по шагам к источнику проблемы, что дает администратору ответ на вопрос, куда копать в поисках решения:
Также добавилось еще несколько новых возможностей:
Улучшения Cisco ACI, включая возможность поиска путей в топологиях NSX-T и Cisco ACI, а также поддержка различных сценариев Endpoint Groups (EPG).
VMware HCX API для автоматизации действий по миграции рабочих нагрузок в облако и между облаками.
Улучшенная интеграция с VMware Cloud on AWS, что позволяет упростить развертывание продукта Aria Operations for Networks как аддона в облаке SDDC.
Встроенные обучающие гайды для операций с трафиком, планирования инфраструктуры безопасности, обнаружения приложений, влияния найденных проблем на бизнес, сетевого здоровья компонентов и поисковых запросов.
Пробную версию продукта VMware Aria Operations for Networks 6.8 можно загрузить по этой ссылке.
В прошлом году компания VMware анонсировала технологию Elastic Application Security Edge (EASE), которая обеспечивает надежное и безопасное соединение между облаками на уровне датацентров или облачных edge-компонентов для приложений, которые постоянно меняются и нуждаются в мобильности. Для того, чтобы защитить текущие инвестиции компаний в оборудование, которое не может обеспечить все потребности меняющейся структуры облачных приложений, и был придуман Project Watch.
Эта технология позволит исполнять операции и надежно поддерживать мультиоблачные соединения поверх существующей аппаратной архитектуры и инфраструктуры безопасности. Это будет включать в себя следующие аспекты:
Автоматическое поддержание зашифрованных межоблачных соединений Clouds (AWS, Azure, and GCP), виртуальные домены Cloud Zones (VPC и VNET), а также операции в сфере обеспечения безопасности для снижения вероятности человеческой ошибки.
Непрерывный анализ рисков и комплаенса в сфере безопасности с возможностью получить набор средств для ограничения рисков и следования корпоративным политикам.
Интеграция рабочих процессов SecOps, CloudOps и бизнес-подразделений для более эффективной коммуникации между командами.
То есть, Project Watch - это расширение существующей архитектуры доступности и безопасности приложений:
Когда мы говорим о доступности, то есть стандартные термины в SLA, как, например, надежность 5 девяток (99.999%), а вот в плане безопасности таких общепринятых метрик нет.
Project Watch как раз будет вводить стандарт в области оценки рисков, который будет говорить о численных метриках взаимодействий. Например, в соответствии с корпоративной политикой типы взаимодействий user-to-app и app-to-app могут осуществляться только, если их risk score составляет менее 73.
При этом будут приниматься во внимание и небинарные решения, где администратор выбирает не только правила Permit/Deny. С помощью Project Watch можно будет поддерживать высокий уровень доступных коммуникаций с постепенным ограничением рисков и гибким регулированием правил.
Поддерживая и традиционную структуру политик Permit/Deny, Project Watch позволит постоянно анализировать риски источника, назначения и структуру коммуникации при проведении транзакций, чтобы обеспечить следующее:
Решения по предоставлению доступа становятся адаптивными и пересматриваемыми в реальном времени для баланса факторов доверия, риска, чувствительности данных и критичности для бизнеса.
Теперь можно будет дать либо "добро" на коммуникацию, либо устранить риск, чтобы иметь такую возможность, и дать зеленый свет транзакциям, для которых ранее стояло жесткое правило Deny.
Этот подход требует вовлечения и других вендоров экосистемы безопасности в этот процесс. Чтобы все действовали в рамках одного набора определений, нужно договориться о методике оценки risk score, а также способах мониторинга, оценки и ограничения рисков.
Таким образом, VMware работает, что стандартизировать индустрию безопасности в рамках политик и оценки рисков, для чего будет доступен open risk framework, который реализует следующие вещи:
Indicators of Risk (IoR) - это параметры, которые будут доступны стороннему ПО. Там будут утилиты для безопасности, метки рабочих нагрузок, контекст окружения, а также классификация операций и данных при коммуникации в рамках сессии источника и назначения.
IoR могут быть организованы в объекты buckets, такие как индикаторы типа Strategic, Operational, Security и Compliance, которые можно использовать для численного измерения рисков между источником и назначением.
Далее риски просчитываются непрерывно, как часть транзакции, а также появляется и оценка потенциальных рисков для источника, назначения и самой коммуникации.
Далее можно делать базовые уровни для рисков (baselining) для разных приложений и окружений, используя стандартные профили рисков, а также гибко ограничивать риски путем регулировки пороговых значений (thresholds).
Доступность технологического превью платформы Project Watch ожидается в ближайшие несколько месяцев.
На конференции Explore 2022 компания VMware анонсировала множество новых проектов, обновлений и технологий, которые мы увидим в ближайшем будущем. Недавно мы писали о новых версиях платформ VMware vSphere 8 и VMware vSAN 8, а сегодня расскажем о Project Northstar, в рамках которого пользователям будут доступны доставляемые как SaaS облачные сетевые сервисы.
Сейчас в больших компаниях, использующих гибридную облачную среду, существует большая проблема по управлению сетевым взаимодействием сервисов, многие из которых находятся в различных публичных облаках. Это ведет к проблемам с унификацией, управляемостью и безопасностью, что влияет на стабильность и надежность сетевой коммуникации облачных приложений между собой.
Решая эту проблему, компания VMware представила Project Northstar - новое превью технологии, построенной на базе SaaS-сервисов, которые будут доступны пользователям решения NSX. Она позволит получить набор мультиоблачных инструментов, получаемых по запросу и реализующих службы кроссоблачной безопасности, end-to-end видимости сетевых потоков и контроля над сетевым взаимодействием.
Эта архитектура строится на стеке технологий и продуктов Network Detection and Response (NDR), NSX Intelligence, Advanced Load Balancing (ALB), Web Application Firewall (WAF) и HCX. Она поддерживает как частные, так и публичные облака, в том числе на базе инфраструктуры VMware Cloud.
Project Northstar будет давать следующие преимущества:
Faster time to value - сервисы, мгновенно доступные по запросу в любом из публичных облаков, поддерживающих технологии VMware, на базе служб федерации. Они будут обеспечивать совместимость и консистентность сетевого взаимодействия приложений, соблюдение единых корпоративных политик, платформу для быстрого масштабирования облака (cloud bursting) и эластичное взаимодействие cloud-to-cloud.
Flexible service consumption - теперь сетевые службы будут доставляться как SaaS-сервис, что позволит оптимизировать затраты и контролировать все аспекты сетевой коммуникации в централизованной панели управления. Также саму платформу можно будет обслуживать без остановки сетевых служб и в большой степени в автоматическом режиме.
Scalable lateral security - мультиоблачные окружения Northstar можно будет защищать с помощью таких технологий, как распределенный сетевой экран и NDR (Network Detection and Response), а надзор за этим будет осуществляться со стороны VMware. Технология NDRaaS будет давать пользователям инструменты для обнаружения сетевых вторжений и реакции на эти атаки по запросу. В дополнение к NSX Intelligence as a Service этот комплекс решений будет давать полную защиту рабочих нагрузок в мультиоблачных средах.
Project Northstar избавит крупные компании от необходимости использования разного набора сетевых инструментов (управление, безопасность, автоматизация операций), которые сейчас доступны в каждом из частных или публичных облаков. На данный момент администраторы используют разные консоли этих облачных провайдеров, что на большом масштабе неизбежно приводит к ошибкам из-за человеческого фактора.
Теперь же для мультиоблачного сетевого взаимодействия будет нужна только одна консоль, управляющая всеми сетевыми службами:
По-сути, Project Northstar - это эволюция платформы NSX, которая будет реализовывать 5 различных сервисов:
Policy-aaS - централизованное управление сетевыми политиками для разных облаков в одной консоли. Там же доступны политики безопасности и средства решения проблем.
NSX Intelligence-aaS - это инструменты для просмотра сетевой активности между облаками в реальном времени. Также тут будет использоваться VMware Data Lake, управляемое со стороны VMware, которое будет использоваться для предоставления рекомендаций для политик и безопасности в мультиоблачных окружениях. Ну и тут будут доступны средства визуализации Network Traffic Analysis (NTA), в которых будут доступны инсайты по обработке потенциальных точек вторжения, а также средства обнаружения сетевых аномалий.
NDR-aaS - сервис Network Detection and Response (NDR) дает средства обнаружения и пресечения вторжений. Он анализирует события IDPS, вредоносного ПО (malware) и сетевые аномалии, чтобы дать администратору полную картину с точки зрения безопасности. Далее можно организовать threat hunting на базе фреймворка MITRE ATT&CK.
NSX ALB-aaS - это расширенные средства балансировки нагрузки (Advanced Load Balancing), которые будут поддерживать онпремизные и облачные окружения. Они будут работать как standalone-система, так и как SaaS-службы, управляемые со стороны VMware. То есть пользователи будут подключаться к соответствующему Advanced Load Balancer provider, которые будет из коробки давать все необходимые службы балансировки без необходимости их развертывания.
HCX-aaS - это набор служб для миграции рабочих нагрузок как услуга, которая управляется на стороне VMware. Для них можно использовать централизованный дэшборд, где доступна оркестрация подключений, перебалансировки и миграций сервисов между облаками. Также тут доступны и функции централизованной отчетности о мобильности сервисов.
Если раньше все эти службы были доступны только пользователям решения NSX и облачного решения VMware Cloud on AWS, то теперь в Project Northstar они будут работать для разных облаков и гибридных сред по модели доставки SaaS.
Ну и в заключение пара полезных статей на тему Project Northstar с конференции Explore 2022:
Недавно компания VMware выпустила большое обновление своего продукта для виртуализации сетей датацентров VMware NSX 4.0. Это платформа для сетевой виртуализации и агрегации программно-определяемых сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes.Напомним, что прошлая версия этого решения называлась VMware NSX-T 3.2, таким образом произошло упрощение названия.
Давайте взглянем на наиболее важные нововведения VMware NSX 4.0.0.1 (именно такая версия открывает четвертую линейку):
Поддержка коммуникации по IPv6 внешних систем с NSX management cluster (только для Local Manager). NSX Manager поддерживает dual-stack конфигурации (IPv4 и IPv6) для внешнего management-интерфейса. Полностью IPV6 конфигурации пока не поддерживаются.
Изменение префикса транзитной подсети T0-T1 после создания Tier0 (ранее это было доступно только во время создания Tier-0).
Поддержка NAT для Policy-based VPN на шлюзе T0/T1.
Улучшения рабочего процесса конфигурации DHCP в интерфейсе.
Возможность перемещения сервера DHCP Standby.
Edge relocate API позволяет при вводе Edge VM в режим обслуживания корректно переместить T1 SR на другие Edge-машины.
Сохранение параметров узла Edge Node после апгрейда, они больше не скидываются на дефолтные.
Блокировка вредоносных IP в Distributed Firewall.
NSX Distributed Firewall теперь поддерживает физические серверы RHEL 8.2/8.4, Ubuntu 20.04, CentOS 8.2/8.4.
Физические серверы теперь поддерживаются на Local Managers, которые работают в рамках федерации сервисов (Federation).
Дополнительные алармы для отслеживания состояния Service Insertion.
Совместимость с NSX Application Platform 3.2.1 (поддержка NSX Intelligence, NSX Network Detection and Response, NSX Malware Prevention и NSX Metrics).
Апгрейд NSX проходит на 10% быстрее по сравнению с прошлыми версиями.
Новые алармы для статусов жизненного цикла физических серверов (install, uninstall, upgrade).
Оповещения в интерфейсе о доступности новых версий NSX.
Поддержка функций Live Traffic Analysis & Traceflow для VPN.
Поддержка Live Traffic Analysis для интерфейсов NSX Edge.
В 2017 году компания VMware купила компанию VeloCloud, которая занималась продвижением технологии SD-WAN (software-defined WAN) для организации программно-определяемых WAN-сетей. Напомним, что для корпоративных онпремизных и облачных сетевых сред у VMware есть решение NSX, но решения VeloCloud предназначались для управления WAN-инфраструктурой компаний, которым было необходимо организовать и контролировать доступ пользователей из разных точек земного шара, с разных устройств и разных условиях защищенности и стабильности каналов, когда ресурсы организации, а также внешние SaaS-сервисы, находятся в географических разнесенных датацентрах. Сегодня мы поговорим об инфраструктуре VMware SASE - Secure Access Service Edge, которая призвана решить проблемы нового времени.
Недавно компания VMware объявила о скором выпуске обновленной версии решения vRealize Network Insight 6.7, предназначенного для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в онпремизном и облачном датацентре. Напомним, что о новых возможностях версии vRNI 6.6 мы писали вот тут.
Давайте посмотрим, что нового появилось в vRealize Network Insight 6.7:
Поддержка протокола IPv6 для обнаружения приложений, а также видимость потоков трафика IPv6 для Center и NSX
Мониторинг сетевого взаимодействия и траблшутинг компонентов VMware HCX
Функции Assurance and Verification для сетевых визуализаций Cisco ACI Network Map. Теперь там отображаются Cisco Endpoint Groups (EPG), HSRP, контракты и другие элементы
Улучшения в дэшбордах Federation в части NSX Advanced Load Balancer (Avi) для пользователей SaaS-подписки vRealize Network Insight Universal
Повышение информативности для сетевых потоков NSX-T для identity-based аутентификации и метрик CPU core usage на устройствах NSX-T Edge Node CPU
Новые метрики интерфейсов роутеров NSX-T Transport Node
Метрики пакетов uRPF для портов VMware NSX-T и Cisco ASR 1000
Обновились обучающие материалы по продукту, включая внутренний туториал для планирования безопасности приложений и организации траблшутинга сети
Подробнее о решении VMware vRealize Network Insight 6.7 можно узнать здесь .
На сайте проекта VMware Labs вышло обновление USB Network Native Driver for ESXi 1.10. Напомним, что это средство представляет собой нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этих драйверов мы писали вот тут.
Давайте посмотрим, что нового в версии пакета 1.10:
Добавлена поддержка VMware ESXi 7.0 Update 3c и 3d
Исправлена проблема с выпадением ESXi в BSOD при использовании драйвера с последними версиями ESXi
Драйверы версии 1.10 подходят только для ESXi 7.0 Update 3c и Update 3d, вот их дистрибутив:
Таблица поддерживаемых устройств теперь выглядит так:
Для других версий ESXi нужно использовать одну из предыдущих версий драйвера. Вот, например, обновилась также и версия 1.9, куда были добавлены следующие возможности:
Добавлена поддержка ESXi 7.0 Update 3, 3a и 3b.
Добавлена поддержка идентификаторов VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100.
Исправлена проблема в механизме управления питанием в xHCI.
Сканирование шины USB (usbBusFullScanOnBootEnabled=0) отключено по умолчанию, что позволяет предотвратить выпадение в PSOD для пользователей, у которых есть несколько сетевых карточек USB.
Этот релиз предназначен только для ESXi 7.0 Update 3, Update 3a и Update 3b:
На днях компания VMware опубликовала отчет по уязвимостям VMSA-2022-0014, которые были обнаружены в решениях Workspace ONE Access, VMware Identity Manager (vIDM), vRealize Lifecycle Manager, vRealize Automation и VMware Cloud Foundation. Напомним также, что vIDM является компонентом таких продуктов, как NSX vRealize Operations, vRealize Log Insight и vRealize Network Insight. Это критическая уязвимость, которая позволяет обойти процедуры аутентификации пользователя и повысить привилегии в соответствующем продукте.
Обход аутентификации означает, что злоумышленник, который имеет доступ только к сети, в которой работает одно из перечисленных решений, может потенциально получить административный доступ к ним. То есть, уязвимость очень важная и опасная, уровня "emergency" в терминологии ITIL.
Основная информация о том, как закрыть эти дыры, приведена по следующим двум ссылкам:
Компания VMware недавно выпустила пару интересных материалов о Project Monterey. Напомним, что продолжение развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, только с аппаратной точки зрения для инфраструктуры VMware Cloud Foundation (VCF).
Вендоры аппаратного обеспечения пытаются сделать высвобождение некоторых функций CPU, передав их соответствующим компонентам сервера (модуль vGPU, сетевая карта с поддержкой offload-функций и т.п.), максимально изолировав их в рамках необходимостей. Но вся эта новая аппаратная архитектура не будет хорошо работать без изменений в программной платформе.
Project Monterey - это и есть переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. За счет технологии SmartNIC инфраструктура VCF будет поддерживать операционные системы и приложения, исполняемые на "голом железе" (то есть без гипервизора).
Вот что нового в последнее время появилось о Project Monterey:
На сайте проекта VMware Labs обновился продукт Community Networking Driver for ESXi до версии 1.2.7. Напомним, что этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. О прошлой версии этих драйверов мы писали осенью прошлого года вот тут.
Давайте посмотрим, что нового появилось в версии 1.2.7 сетевых драйверов:
Поддержка устройств Intel I225 с любым идентификатором PHY ID
Поддержка новых устройств Intel I226-K (также для любых PHY ID)
Исправлен возможный дэдлок в изменяющемся MTU
Исправлено возможное зависание RX при операциях device layer ops
Исправлена возможная ошибка PHY reset failure
Драйверы работают для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:
Установка драйверов производится следующей командой (после этого нужно перезагрузить хост):
esxcli software vib install -d /path/to/the offline bundle zip
Скачать пакет драйверов VMware Community Networking Driver for ESXi 1.2.7 можно по этой ссылке.
Компания VMware на днях анонсировала доступность решения vRealize Network Insight Universal, представляющего собой комплекс средств по мониторингу сетевого окружения и аналитике в экосистеме продуктов NSX, NSX Advanced Load Balancer, vCenter / vSphere, VMware SD-WAN, а также сторонних решений по обеспечению сетевого взаимодействия и защиты виртуальных сред.
vRNI Universal доступен для пользователей, начиная с версии vRNI 6.5 (в прошлый раз мы писали о возможностях версии vRNI 6.3). vRealize Network Insight в онпремизной и Cloud-версии использует алгоритмы машинного обучения для поддержки миграций из собственных датацентров в облачные и мониторинга процессов сетевой активности.
Облачная версия vRNI обеспечивает мониторинг публичных облачных сред AWS и Azure, а также решений на базе технологии VMware Cloud, таких как VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine, Oracle Cloud VMware Solution, VMware Cloud on Dell EMC и публичные облака сервис-провайдеров VSPP, у которых vRNI также мониторит сетевое оборудование, такое как маршрутизаторы, балансировщики, фаерволы, коммутаторы и многое другое.
Дэшборд vRealize Network Insight Universal обеспечивает единую точку контроля над инстансами в разных датацентрах:
Средства Federated Network Analytics позволяют администраторам в одном дэшборде контролировать собственный датацентр совместно с различными SaaS-сервисами, размещенными по всему миру. Федерация позволяет объединить датацентры надежным шифрованным каналом и видеть все алерты и элементы, которые были добавлены или удалены за прошедшие 24 часа.
Также администратор может видеть состояние окружения и движение трафика между географическими точками, где расположены инстансы. Можно переключаться между списком или наглядным представлением в виде карты, где администратор может выбрать нужный инстанс и уже там более детально проводить траблшутинг сетевого окружения. Есть функции и по делегированию возможностей работы с Federated Network Analytics другим пользователям организации.
vRealize Network Universal использует vRealize Cloud Subscription Manager для управления лицензиями vRNI как SaaS-продукта. Прямо сейчас можно попробовать 30-дневную версию vRNI Universal по этой ссылке.
Компания VMware выпустила интересный документ "Intel architecture optimizes VMware SD-WAN Edge performance", в котором рассказывается о решении VMware Secure Access Service Edge (SASE) на базе аппаратных платформ Intel. Решение SASE объединяет компоненты интегрированной среды VMware, предназначенные для создания распределенной инфраструктуры безопасного и производительного доступа пользователей к приложениям и средства контроля этой активности.
Экосистема решения, описанного в документе, выглядит следующим образом:
Идея концепции SASE в том, чтобы обеспечивать защиту доступа к приложениям в географических центрах, максимально приближенных к облачной инфраструктуре, где эти приложения находятся (публичные облака и облака сервис-провайдеров). Сейчас у SASE есть более, чем 150 точек присутствия (points of presence, PoP), где физически размещено оборудование в облачных датацентрах, что позволяет построить безопасный и высокопроизводительный мост к SaaS-сервисам приложений.
Компоненты SASE включают в себя следующие решения:
Облачную технологию VMware SD-WAN, которая виртуализует WAN-сети в целях отделения программных служб от оборудования, что дает гибкость, простоту управления, производительность, безопасность и возможность быстрого масштабирования в облаках.
Компонент VMware Secure Access для удаленного доступа в рамках фреймворка zero-trust network access (ZTNA). Это новый уровень VPN-решений, который дает новые инструменты для доступа к облачным приложениям.
VMware Cloud Web Security - это интегрированное решение на базе таких техник, как Secure Web Gateway (SWG), cloud access security broker (CASB), data loss prevention (DLP), URL filtering, а также remote browser isolation (RBI), что реализовано на уровне SASE PoP для защиты прямого доступа к SaaS-приложениям и веб-сайтам.
VMware Edge Network Intelligence - это платформа для отслеживания активности подключений и сетевых потоков в рамках концепции AIOps, которая предполагает использование алгоритмов AI/ML для аналитики трафика WAN-to-branch, WiFi/LAN, а также на уровне приложений.
В документе описывается использование компонентов VMware SD-WAN Edge на базе различных платформ Intel, использующих процессоры Atom и Xeon. Требуемая конфигурация устройств SD-WAN рассматривается через призму требований приложений к пропускной способности канала, а также объема виртуализуемых сетевых служб, таких как фаерволы, системы IDS и прочее, которые работают как VNF (virtual network functions) в рамках программно-аппаратных модулей.