Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4800 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Платформа VMware vSphere 6.7 Update 2 доступна для загрузки

VMware объявила о выпуске первого VMware Service-defined Firewall - попробуем разобраться, что это.


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

Также у VMware есть продукт vRealize Network Insight, который позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, следить за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

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

Использовав наработки этих трех продуктов за последние годы, компания VMware на днях анонсировала новое решение - первый в отрасли Service-defined Firewall.

Это решение основано на подходе по микросегментации приложений с точки зрения защиты виртуальной среды (см. service insertion и guest introspection), что подразумевает анализ сетевой активности на уровне приложения, при этом мониторинг ведется извне гостевой ОС на уровне гипервизора (данные берутся из NSX или напрямую с серверов ESXi), что позволяет исключить манипуляции средствами обнаружения вторжений, которые могут быть выполнены программным обеспечением внутри ОС.

Но главная штука VMware Service-defined Firewall - это возможность создания политик на уровне приложений/микросервисов, а не сетевых компонентов (серверов/ОС/портов). Это существенно упрощает ввод в эксплуатацию новых сервисов с точки зрения организации их защиты, а также обслуживания при перемещении виртуальных машин внутри датацентра и между ЦОДами.

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

VMware Service-defined Firewall позволит использовать новый подход к защите сетевой инфраструктуры предприятия за счет анализа приложений внутри периметра ЦОД (internal network firewalling), где наблюдение за сервисами происходит на уровне гипервизора и на седьмом уровне модели OSI (L7 packet inspection), без агентов в гостевых ОС, при этом используется модель Zero Trust (то есть изначально нет доверия ни одному компоненту в сети, считается, что атака может прийти откуда угодно, через любое сетевое соединение).

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

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

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

Что интересного можно почитать на тему VMware Service-defined Firewall:

Видео про возможности NSX-T 2.4, которые будут использованы в Service-defined Firewall:

Service-defined Firewall в действии и консоль AppDefense:


Таги: VMware, Security, Networking, NSX, vRNI, AppDefense, ESXi, vSphere

Что нового в VMware Unified Access Gateway (UAG) 3.5?


На днях компания VMware выпустила обновление решения для виртуализации настольных ПК предприятия VMware Horizon 7.8. Одновременно с этим релизом было выпущено и решение VMware Unified Access Gateway (UAG) 3.5, представляющее собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon.

Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon. Напомним, что о версии UAG 3.4 в начале этого года мы писали вот тут.

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

  • Поддержка Unified Access Gateway Powershell для облачных инфраструктур Microsoft Azure и Amazon AWS. Подробнее можно узнать вот тут и из видео выше.
  • Поддержка замены сертификатов SSL для PSG (PCoIP Secure Gateway) .
  • Расширенный мониторинг внешнего балансировщика UAG за счет использования HTTP/HTTPS GET или файла favicon.ico теперь охватывает все edge-сервисы.
  • Теперь не требуется отдельно указывать лицензию UAG (Standard, Advanced или Enterprise) для Workspace ONE и Horizon - все возможности UAG доступны для данных изданий.

Скачать VMware Unified Access Gateway 3.5 можно по этой ссылке. Инструкция по развертыванию решения в облачной среде доступна тут.


Таги: VMware, Cloud, Networking, UAG, Update

Обнаружение девиантов по трафику в группе виртуальных машин с помощью VMware vRealize Network Insight.


Мы часто писали о решении VMware vRealize Network Insight (vRNI), которое позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, смотреть за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Также с помощью vRNI можно найти 3 типа отклонений для виртуальных машин, работающих непрерывно в виртуальной инфраструктуре:

  • Outliers - девианты по трафику в рамках группы ВМ по сравнению с остальными членами группы.
  • Thresholds - машины, которые превысили пороговые значения по трафику или сбросу пакетов.
  • Top Talkers - самые потребляющие сетевые ресурсы машины в каком-то аспекте мониторинга.

Сегодня мы рассмотрим ситуацию, когда с помощью vRNI можно обнаружить девиантов по трафику (Outliers) в группе виртуальных машин, выполняющих одинаковую функцию. К таким машинам можно отнести, например, веб-серверы, размещенные за балансировщиком и принимающие на себя в среднем одинаковую нагрузку.

Если один из серверов начинает существенно отклоняться (например, отдавать трафика намного больше чем остальные), то это может говорить либо об ошибке в конфигурации балансировщика, либо о каких-то проблемах на этом веб-сервере. Также к таким сервисам можно отнести серверы DNS, Active Directory, кластеры серверов SQL и другие масштабируемые сервисы.

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

Здесь мы видим, что виртуальная машина cmbu-sc2dc-01 на порту 53 имеет большой поток трафика, гораздо больше, чем остальные, поэтому и попала в категорию "Outliers" на панели справа.

Для мониторинга такого поведения вы можете выбрать один или несколько портов, а также направление трафика (входящий/исходящий), так как есть сервисы, которые в основном принимают данные (например, обработчики), а есть, которые преимущественно отдают (веб-серверы, DNS и т.п.).

Чтобы создать группу Outliers для мониторинга, нужно в консоли vRNI пойти в меню Analytics и там открыть раздел Outliers:

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

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

Здесь они означают следующее:

  1. Имя группы.
  2. Масштаб наблюдения (application tier, NSX Security tag и т.п.).
  3. Для уровня приложения (application tier) нужно выбрать само приложение и его ярус (tier).
  4. Метрика - total traffic (MB, GB и т.п.), число пакетов или сессий, либо объем трафика в секунду.
  5. Направление обнаруживаемого трафика (incoming, outgoing, both).
  6. Направление трафика в датацентре: north-south (интернет-трафик), east-west (внутренний трафик датацентра), либо оба направления.
  7. Порты назначения - можно мониторить все используемые порты, либо выбранные. Но пока есть лимит 20 портов, если он будет превышен, то их надо будет вводить вручную.
  8. Чувствительность алгоритма обнаружения (low, medium, high).
  9. Когда все установлено, vRNI сгенерирует превьюшку результатов на графике, включающем в себя настроенные сетевые потоки.

Если превью вас устроило, то просто нажимаете Submit и добавляете новую группу в систему мониторинга.

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

В общем, vRNI, хотя бы только с этой стороны - полезная штука!

Источник.


Таги: VMware, vRNI, Networking, Performance, Monitoring

Вышло обновление решения для сетевой виртуализации, агрегации и управления сетями гибридных датацентров - VMware NSX-T 2.4.


Недавно VMware объявила о большом обновлении своего решения для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker - VMware NSX-T 2.4 (кстати, вот видео об отличии этого решения от NSX-V для vSphere).

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

Напомним, что прошлая версия NSX-T 2.3 вышла в сентябре прошлого года. С тех пор многое изменилось, поэтому давайте посмотрим, что нового (из основного) появилось в NSX-T 2.4:

1. Упрощение установки, конфигурации и ежедневного оперирования.

В этой области появилось 3 основных улучшения:

  • Новый виртуальный модуль NSX manager appliance, который поддерживает кластерную конфигурацию до 3 узлов, каждый из которых выполняет функции обеспечения политик и контроля сетевой инфраструктуры. Это дает высокий уровень отказоустойчивости. Также установщик имеет модули Ansible для упрощения процедуры автоматизированной установки и настройки рабочих процессов.
  • Радикально упрощенный пользовательский интерфейс, где еще более продуманы значения по умолчанию и уменьшено число экранов и кликов для ежедневных операций.
  • Контекстный поиск с мощными функциями по автозаполнению, что упрощает решение проблем из консоли NSX-T.

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

2. Декларативная модель политик.

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

Вместо детализированных вызовов API, которые должны быть выполнены в строго определенной последовательности, NSX Manager теперь принимает на вход декларативное описание политики в виде одной API команды с данными в формате JSON, которое несложно понять (а значит, увеличивается прозрачность операций).

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

3. Расширенные возможности безопасности.

Новый релиз NSX продолжает развивать концепцию микросегментации приложений. В этом направлении появились следующие новые возможности:

  • Фаервол на базе сетевой идентичности приложения.
  • Белые списки адресов FQDN/URL на распределенном фаерволе (DFW) для разрешения определенного типа трафика ВМ к определенным адресам или хостам в датацентре:

  • Возможность анализа трафика на уровне гостевой ОС (guest introspection).
  • Возможности E-W service insertion (контроль трафика в пределах датацентра средствами сторонних IDS/IPS-систем).

Также в NSX-T 2.4 существенно был улучшен механизм аналитики и визуализации данных, а также появилась поддержка Splunk и VMware vRealize Log Insight.

Ну а о новых возможностях обеспечения сетевой безопасности можно узнать из этого видео:

4. Высокий уровень масштабируемости, надежности и производительности.

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

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

5. Партнерства и новые возможности для пользователей.

Со стороны NSX-T поддержка продуктовой линейки VMware и партнерских решений была существенно расширена. Теперь такие решения, как Kubernetes, VMware PKS, Pivotal Application Service (PAS) и Red Hat OpenShift в различной мере поддерживаются NSX-T, и их поддержка будет только расширяться.

Конечно же, обеспечивается поддержка облачных решений, особенно VMware Cloud on AWS и нативных облачных нагрузок через VMware NSX Cloud. Также продукт NSX-T включен в состав таких платформ, как VMware Cloud Foundation, VMware vCloud NFV, а в будущем и в AWS Outposts и VMware Cloud Foundation for EC2.

Более подробно о новых возможностях VMware NSX-T 2.4 рассказано в Release Notes. Скачать продукт можно по этой ссылке. Вот еще несколько полезных ресурсов:


Таги: VMware, NSX, Update, Networking, vNetwork

Мир до и после. Как изменилась жизнь с наступлением DNS Flag Day.


Это гостевой пост нашего партнера - компании ИТ-ГРАД, предоставляющей услугу аренды виртуальных машин из облака по модели IaaS.

Что изменилось с наступлением DNS Flag Day? Еще до недавнего времени этот вопрос активно обсуждали в Рунете. Одни полагали, что большинство государственных сайтов и других веб-ресурсов могут стать недоступными, другие – были уверены, что ничего существенного не произойдет. В целом, становилось понятно, что сложности возникнут лишь в том случае, если DNS-серверы окажутся неготовыми отвечать на запросы EDNS. Но эксперты заранее поспешили всех успокоить. К тому же результаты исследования по ситуации в российских национальных доменных зонах .ru и .рф были довольно позитивными – процент DNS-серверов, некорректно отвечающих на запросы по обновленной схеме, оказался ничтожно мал.

Чем не угодил старый добрый DNS

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

Какие изменения происходили? В 1999 году придумали расширение EDNS0, благодаря которому работает механизм DNSSEC. Если кратко, DNSSEC умеет вычислять «подмену», то есть узнавать, кто ответил на DNS-запрос: легитимный источник либо же кто-то другой, не имеющий к нему никакого отношения. Это хоть и стало некой подвижкой к переменам, но в целом не решило всех проблем. Читать статью далее->>


Таги: IT-Grad, IaaS, DNS, Networking

Полезные утилиты для решения проблем в сетевом стеке VMware vSphere.


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

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

  • Консольная утилита esxtop (представление network)
  • ping / vmkping
  • traceroute

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

  • net-stats
  • pktcap-uw
  • nc
  • iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

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

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

 

  • Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

  • Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

  • Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

  • Ограничить захват заданным числом пакетов:

pktcap-uw -c 100

  • Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

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

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.


Таги: VMware, vSphere, Networking, ESXi, Troubleshooting

Zscaler. Новая защита «дорожного воина».


Гостевой пост нашего спонсора - компании ИТ-ГРАД (теперь часть МТС), предоставляющей услуги виртуальной инфраструктуры VMware в аренду по модели IaaS.

В 1981 году на экраны вышел культовый фильм Джорджа Миллера с участием Мела Гибсона «Безумный Макс: Воин дороги». Этот фильм принес в английский  язык новый термин: «road warrior», которым стали называть сотрудников, чья работа требовала большого количества путешествий. Такие сотрудники должны были только время от времени приезжать в офис для выполнения административных задач вроде оформления отчета о расходах или получения информации о клиентах. По мере развития информационных и телекоммуникационных технологий сотрудникам уже не нужно было появляться в офисе – многие операции можно было выполнять дистанционно – сначала при помощи модема, затем, после развития Интернет – с помощью VPN-канала.

В наше время современные технологии позволяют выполнять офисную работу все большему количеству людей, не выходя из дома. По данным Eurostat, 35% предприятий в Европе в настоящее время предлагают своим сотрудникам возможность работать из дома.

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

Согласно исследованию Ponemon Institute средняя стоимость ущерба, связанного с нарушением безопасности, возросла с 3,62 млн. долларов в 2017 г.  до 3,86 млн. долларов в 2018 г., то есть на 6,4 процента. Количество и сложность инцидентов, связанных с безопасностью, также возросли.

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

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

Проблемы возникают тогда...Читать статью далее->>


Таги: IT-Grad, IaaS, Zscaler, Networking, Security

VMware выпустила vRealize Network Insight 4.0 - новые возможности.


В конце декабря компания VMware сделала доступной для скачивания новую версию vRealize Network Insight 4.0 (vRNI). Напомним, что о прошлой версии vRNI 3.9 мы писали в сентябре прошлого года вот тут.

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

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

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

Новая большая версия vRNI представляет поддержку облачной среды VMware Cloud on AWS (правда пока в режиме Preview). Администраторы могут смотреть метрики для NSX и vCenter, а также потоки IPFIX flows между виртуальными машинами в облаке VMware Cloud on AWS и вашей онпремизной инфраструктурой NSX и vSphere.

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

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

2. Возможность Plan Security и микросегментация.

Для VMware Cloud on AWS можно использовать функцию Plan Security, которая позволяет распознавать паттерны трафика приложений, визуализовывать его и дать исходные данные для его оптимизации с точки зрения приложений.

Все это работает в рамках общего подхода по микросегментации трафика:

3. Возможность просмотра путей VM-to-VM и сущностей Cisco ACI.

Теперь Network Insight может отображать сущности Cisco ACI. Просто укажите vRNI адрес контроллера APIC и вы получите детали конфигурации, такие как фабрика ACI, EPG и их маппинги, Bridge Domains, пути L2 к leaf-узлам, а также схемы VRF для путей ВМ-ВМ.

Помимо этого, для коммутаторов и APIC поддерживаются метрики на базе SNMP. На каждый из элементов фабрики можно нажать, чтобы посмотреть дополнительную информацию (показан дэшборд для фабрики Leaf and Spine):

Индивидуальные дэшборды доступны для следующих объектов:

  • Leaf and Spine fabric
  • Switches
  • EPG
  • Application profile

Также для сущностей ACI доступен мощный поиск, который позволяет добавить результаты на pinboard и к ним привязать алармы, если это необходимо.

4. Детали фаерволов Cisco ASA.

Для ASA поддержка со стороны vRNI включает в себя видимость контекста безопасности (security context), прав доступа, групп доступа, сетевых и сервисных объектов или групп, обнаружение и изменение событий, а также правил фаервола в рамках пути VM-to-VM.

На картинке ниже показано представление для VRF на фаерволе ASA с таблицами маршрутизации и другими деталями интерфейсов маршрутизаторов (они показываются для конкретного пути VM-to-VM):

5. Динамические и статические пороги для собираемых метрик (thresholds).

vRNI позволяет добавлять статические пороги для метрик (аларм срабатывает, когда значение больше указанного в течение какого-то времени) и динамические (когда значение отклоняется от предыдущего на определенное значение, например, произошло изменение паттерна трафика):

6. Обновленный NSX-T datasource.

Теперь для NSX-T можно получать такую информацию, как проблемы связности между компонентами NSX, число вызовов NSX API, количество packet drops, flow count, network rate и byte count. Эти метрики доступны для логических коммутаторов и портов, интерфейсов маршрутизаторов и правил фаерволов.

Также поддерживается и NAT с возможностью просмотра правил SNAT, DNAT и Reflexive (stateless). Здесь можно увидеть оригинальные и транслируемые IP-адреса, сервисное соединение, а также входные и выходные интерфейсы:

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

Полный список новых возможностей vRealize Network Insight 4.0 доступен в Release Notes.

Попробовать VMware vRNI можно также как облачный сервис VMware Cloud Service по этой ссылке. Для онпремизных инсталляций поддерживается прямое обновление с версий vRNI 3.8 и 3.9.


Таги: VMware, vRNI, Update, Networking, Cisco, NSX

Что нового появилось в VMware Unified Access Gateway 3.4?


В прошлом году мы писали о выпуске обновленной версии решения VMware Horizon 7.7, а также о его компонентах - VMware App Volumes 2.15 и VMware User Environment Manager 9.6, а сегодня расскажем о последнем из важных компонентов для создания инфраструктуры виртуальных ПК - новой версии VMware Unified Access Gateway 3.4.

VMware UAG представляет собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon.

Напомним, что о прошлой версии Unified Access Gateway 3.3 мы писали вот тут.

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

1. Обеспечение собственной высокой доступности (High Availability).

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

Делается это средствами виртуального IP-адреса и Group ID, что позволяет балансировать трафик на порту 443 для более чем 10 тысяч одновременных подключений. Это позволяет снизить операционные затраты на обслуживание таких сервисов, как VMware Horizon 7, Web Reverse Proxy, Per-App Tunnel и VMware Content Gateway.

2. Механизм мониторинга Session Statistic Monitoring для оконечных сервисов.

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

3. Режим Cascade Mode для поддержки Horizon 7.

Для организаций, где требуется использование двухслойного DMZ, сервер UAG может работать в каскадном режиме (Cascade Mode). В этом случае внешний сервер UAG работает как Web Reverse Proxy для интернет-соединений пользователей, а внутренний - как Horizon Edge Service.

 

4. Ограничение доступа к службам Amazon Web Services.

Теперь с помощью UAG можно лимитировать доступ к облачным ресурсам AWS в целях разграничения доступа. В этом случае Unified Access Gateway можно импортировать в облако Amazon EC2, зарегистрировать как Amazon Image Machine (AMI) и развернуть с помощью сценария PowerShell.

5. Поддержка custom thumbprints.

Custom thumbprints позволяют использовать разные сертификаты для соединений Blast TCP и VMware Tunnel. Это можно сделать в консоли UAG или через PowerShell INI.

6. Нативная поддержка Horizon 7.

В консоли Horizon Administrator в дэшборде System Health теперь отображаются детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

Скачать VMware Unified Access Gateway 3.4 можно по этой ссылке.


Таги: VMware, UAG, Update, Networking

Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.


Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

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

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

  • Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

  • Обычный или распределенный виртуальный коммутатор (VSS или VDS).

Основная задача этого уровня - направлять пакеты к нужному порту (аплинку), через которые они достигнут адреса назначения. Он оперирует MAC-адресами источника и назначения, а также определяет, отдавать ли трафик локально (в рамках одного или нескольких виртуальных коммутаторов на хосте), либо перенаправлять его к уровню аплинка хоста ESXi.

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

  • Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

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

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

 

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

  • Fastpaths – фильтры трафика на уровне ядра ESXi.
  • Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
  • Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

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


Таги: VMware, Networking, ESXi, VDS, VSS, VMachines

Апгрейд распределенного виртуального коммутатора (vSphere Distributed Switch) при обновлении VMware vSphere.


Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

  • vSphere 6.0 = VDS 6.0
  • vSphere 6.5 = VDS 6.5
  • vSphere 6.7 = VDS 6.6 (да, вот так странно)

После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.


Таги: VMware, vSphere, VDS, Upgrade, Networking

3 очень серьезных бага VMware vSphere - обязательно накатите обновления!


Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.

1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.

Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).

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

Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:

Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:

esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing

2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.

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

  • vSAN начинает процесс ресинхронизации
  • В этот момент вы расширяете диск VMDK виртуальной машины
  • vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины

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

Для устранения бага накатите патчи на vSAN:

Также вы можете временно избежать проблемы, выполнив такую команду на каждом хосте ESXi:

esxcfg-advcfg -s 0 /VSAN/ClomEnableInplaceExpansion

3. Получение доступа root к хосту ESXi из виртуальной машины.

Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.

Кстати, это было публично показано впервые:

Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).


Таги: VMware, vSphere, Bug, Bugs, vSAN, Security, VMachines, Storage, Networking

Что такое и как работает Network I/O Control (NIOC) в VMware vSphere 6.7.


Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.

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

NIOC позволяет системным и сетевым администраторам настраивать приоритизацию следующих видов трафика для пула сетевых адаптеров хостов ESXi:

  • Fault tolerance traffic
  • iSCSI traffic
  • vMotion traffic
  • Management traffic
  • vSphere Replication traffic
  • Network file system (NFS) traffic
  • Virtual machine (VM) traffic
  • User-defined traffic

Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).

В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):

В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:

Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:

  • Reservation - гарантирует тому или иному типу трафика пропускную способность канала в Мбит/с. Важно помнить, что эта ширина канала резервируется, но в случае ее простоя ее смогут использовать другие типы системного трафика. Между тем, простой канала зарезервированного системного трафика не дает возможность распределить полосу на виртуальные машины. В любом случае, Reservation (если он вам очень нужен) нужно выставлять таким, чтобы обеспечить только минимальные запросы сервиса для его функционирования, а не средние и максимальные.
  • Limit - ограничивает сверху используемый канал для выбранного типа трафика.
  • Shares - с помощью чисел приоритета (от 1 до 100) позволяет выделить группы которые будут получать больше или меньше пропускной способности канала (например, если одна группа имеет 100, а другая 50 - то первая будет получать в два раза больше на фоне распределения всего трафика адаптеров по группам). Механизм этот начинает распределять канал после раздачи всех заданных резерваций.

Есть еще один нюанс - только 75% совокупной ширины канала на хосте ESXi может быть зарезервировано (а если говорить точнее - от адаптера с самой низкой пропускной способностью в этой группе на хосте). Остальные 25% остаются на всякий случай (например, компенсация всплесков управляющего трафика). Все, что не распределено с помощью Reservation, будет регулироваться средствами механизма Shares.

Для изменения резервации, лимита или shares категорий системного трафика надо открыть настройки конкретного типа трафика:

Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.

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

NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула Virtual machine (VM) traffic.

Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.

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

Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:

Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:

А потом указать резервацию для него:

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

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

При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.

В итоге картина выглядит подобным образом:

Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:

Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.


Таги: VMware, vSphere, NIOC, Networking, Performance, Обучение, ESXi, vDS

Отозваны VMware Tools 10.3.0 из-за проблем с драйвером VMXNET3 - хосты падают, а виртуальные машины валятся в синий экран.


В июле этого года мы писали о релизе новой версии VMware Tools 10.3, где была закрыта уязвимость HGFS Out-Of-Bounds Read, которая могла привести к повышению привилегий злоумышленника в гостевой ОС виртуальной машины (для этого должны быть включены сервисы File sharing на ВМ с Windows на борту).

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

Как пишут в KB 57796, хосты ESXi из-за этого могут выпасть в розовый экран (Purple Diagnostic Screen, PSOD), а гостевые ОС потерять сетевое соединение.

Наш постоянный читатель Стас рассказал, что данная проблема в его инфраструктуре привела к тому, что тяжело нагруженные виртуальные машины c MS SQL на борту вываливаются в синий экран. В итоге VMware Tools 10.3 были отозваны, а ссылка на них и их загрузку была убрана с ресурсов VMware.

Таким образом, на данный момент workaround заключается в том, чтобы использовать VMware Tools 10.2.5.

Будьте внимательны!


Таги: VMware, Tools, Bug, Networking, Update, Bugs, vSphere, VMachines

Что такое и как работает Blast Extreme Network Intelligent Transport (BENIT) в решении VMware Horizon View.


Как многие уже знают, не так давно VMware выпустила обновленную версию решения для виртуализации и доставки рабочих окружений пользователей VMware Horizon 7.5. Среди новых возможностей клиентов Horizon View была такая фича: "VMware Blast выбирает оптимальный транспорт автоматически (UDP или TCP) для предоставления лучшего качества обслуживания пользователю (ранее нужно было делать это вручную)".

Оказывается, это очень важная штука, и называется она Blast Extreme Network Intelligent Transport (BENIT). Ранее компания VMware анонсировала механизм Blast Extreme Adaptive Transport (BEAT), который позволял переходить на UDP-протокол в сетях с плохим качеством связи, предоставляя пользователю выбор типа соединения:

Blast Extreme автоматически подстраивается под параметры Bandwidth, Latency и Packet Loss в различных сетях и выбирает наиболее эффективный транспорт: TCP или UDP. Работало это так:

  • Excellent - предназначен для LAN-сетей с хорошим качеством (высокая скорость и низкие потери пакетов). В этом случае используется только TCP протокол - и для управления передачей, и для отправки самих данных.
  • В случае выбора Poor протокол Blast Extreme использует только UDP для управления передачей и отсылки данных. Это оптимально для WAN-сетей с большими задержками и коэффициентом потерь пакетов 20% и более.
  • Дефолтный пункт - Typical - это оптимальный выбор для 99% пользователей. В этом случае будет использоваться TCP для управления передачей, а UDP для основной отправки данных, с учетом адаптивного алгоритма. Если по каким-то причинам UDP будет недоступен (например, заблокирован политикой на сетевом экране), то произойдет незаметное для пользователя переключение на TCP.

Далее в версии VMware Horizon 7.3.1 появились отдельные каналы для для USB и CDR внутри протокола Blast. Это позволило инкапсулировать весь трафик в рамках одного протокола, что удобно с точки зрения управления каналом.

Между тем, некоторые недостатки такого механизма еще оставались, особенно при использовании UDP:

  • UDP часто заблокирован в корпоративной инфраструктуре или сильно зажат по ширине канала.
  • Маршрутизация на основе политик может вести TCP и UDP трафик через совершенно разные пути.
  • Некоторым приложениям (например, копированию файлов) гораздо важнее сырая пропускная способность, чем уровень отклика для пользователя, с чем отлично справляется TCP.
  • При использовании TCP в протоколе Blast нагрузка на CPU является несколько повышенной, если сравнивать с собственными механизмами оптимизации TCP в операционных системах.

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

Еще одной проблемой является использование мобильных клиентов - протоколы TCP или Adaptive Transport предоставляют надежное соединение только когда постоянно доступно. Но мобильное устройство может переключиться с Wi-Fi на 3G/LTE, при этом, например, копирование файлов в гостевой ОС не должно прерываться.

Как следствие, VMware разработала протокол сеансового уровня для Blast, который появился в VMware Horizon View 7.5.0 и Horizon Clients 4.8.0 - Blast Extreme Network Intelligent Transport (BENIT).

Этот протокол предоставляет следующие характеристики:

  • Надежность - гарантия последовательной доставки данных в условиях прерывания сетевого соединения / переключения сетевых адаптеров.
  • Переключение транспорта для отдельного приложения на основе отклика приложения в сети.
  • Балансировка нагрузки за счет одновременного использования обоих транспортов для различных приложений, а также за счет выбора конкретного транспорта для определенного класса трафика (например, File Copy).

Так это выглядит наглядно:

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

Давайте посмотрим на некоторые аспекты такого решения:

Надежность

Тут возникает 2 основных проблемы:

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

Переключение транспорта

Для того, чтобы механизм BENIT работал эффективно, нужна возможность смотреть на производительность транспорта для определенных приложений, которая и реализована в протоколе. Решение по переключению может приниматься на основе заранее заданной политики (дефолтно это потери пакетов > 1%, задержка > 50 мс и пропускная способность < 200 Мб/с), либо с помощью интеллектуального алгоритма, который сам понимает необходимость переключения. Статические политики вы можете задать самостоятельно, на основе эмпирических результатов производительности для отдельных приложений или инфраструктуры в целом.

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

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

Аналитика при переключении транспорта

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

Поэтому здесь есть механизм обучения - если, например, произошла серия "плохих" переключений с BEAT на TCP и обратно, то BENIT запомнит эту связь и будет поддерживать TCP-соединение, даже если все требования по переключению будут выполнены.

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

  • Lazy switching - если одна порция трафика пока еще целиком не послалась через транспорт, то следующая посылается уже через новый канал, при этом на старом еще некоторое время ожидается квитанция о приеме, и если ее не приходит - то сообщение перепосылается уже через новый канал. Это вызывает некоторую задержку времени переключения, но зато эффективно с точки зрения использования канала.
  • Rollback and switch - в этом случае недопосланное сообщение аннулируется, происходит мгновенное переключение и перепосылка этого сообщения по новому каналу. Это приводит к максимально быстрому переключению, но часть трафика в канале дублируется.

Некоторые результаты тестирования

Вот так выглядят результаты по FPS при просмотре видео на виртуальном десктопе при использовании протоколов TCP и BENIT в условиях различных сетевых соединений:

Network Profile BENIT TCP Blast Extreme Adaptive Transport
10 Mbps, 20% Loss, 200 ms RTT 13.40 fps 00.65 fps 13.38 fps
10 Mbps, 10% Loss, 200 ms RTT 16.52 fps 02.25 fps 16.52 fps
100 Mbps, 0% Loss, 200 ms RTT 27.52 fps 27.53 fps 25.68 fps
200 Mbps, 0% Loss, 200 ms RTT 28.23 fps 28.25 fps 27.92 fps

А вот результаты по копированию файлов через механизм Drive Redirection:

Network Profile BENIT TCP Blast Extreme Adaptive Transport
10 Mbps, 1% Loss, 50 ms RTT 8.32 Mbps 2.38 Mbps 8.32 Mbps
100 Mbps, 0% Loss, 0 ms RTT 98.8 Mbps 98.8 Mbps 91.28 Mbps

Ну и главное - BENIT позволяет сохранить поток копирования файлов при переключении между соединениями Wi-Fi и 3G/LTE на мобильном интернете или при потере сетевого соединения (по умолчанию настроено время ожидания 120 секунд, его можно изменять):


Таги: VMware, Horizon, View, Blast, Networking, Обучение, VDI

Демон SNMP постоянно падает в VMware vSphere 6.7.


Интересная штука обнаружилась у пользователей, которые сделали апгрейд на VMware vSphere 6.7. Каждые 30 минут служба SNMPD падает и перестает отвечать, перезапуск сервиса на ESXi помогает, но только на 30 минут.

Оказывается это обычный баг, описанный в KB 57245. Просто-напросто SNMP в VMware vSphere 6.7 не работает (причина в механизме реализации потоков - основной thread не завершается, в то время, как дочерний уже вызывается). На данный момент нет способа обхода проблемы.

Инженеры VMware обещают, что эта ошибка будет исправлена до конца года (we are currently investigating what is causing this issue and hope to have a solution out for this issue later this year), но пока пользоваться SNMP невозможно.


Таги: VMware, vSphere, Bug, Bugs, Networking

Вышло обновление продукта VMware vRealize Network Insight 3.8 - что нового?


Компания VMware на днях выпустила обновление своего средства для обеспечения сетевой безопасности витуальной инфраструктуры VMware vRealize Network Insight 3.8 (vRNI). Напомним, что о новых функциях версии vRNI 3.6 мы писали вот тут.

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

1. Функции Outlier Detection.

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

Такая активность анализируется аналитическим движком и визуализуется на графике. Также по подозрительным машинам показывается дополнительная информация, такая как объем трафика, число сессий и IP-адрес. Это позволяет выявить не только подозрительные активности, но и определить неправильно настроенные ВМ (например, балансировщики).

2. Улучшения работы с сервисом Amazon AWS.

Здесь было сделано множество мелких улучшений:

Очень важная фича для пользователей облачных инфраструктур AWS - поддержка зон доступности (Availability Zones) при просмотре окружения, поиске машин и их фильтрации. Также несколько поменялся интерфейс, облачные инстансы теперь обозначаются как AWS EC2, а AWS Manager переименован в AWS Account.

3. Интеграция с VMware Log Insight.

Про это средство для централизованного сбора и анализа логов мы много пишем в последнее время. Теперь в vRNI 3.8 можно посылать webhook-нотификации сразу же, как случается какое-то событие. Log Insight через этот механизм может посылать в сторону vRNI алерты, например, об изменении Security Groups в решении VMware NSX (эти изменения фиксируются в логах, которые обрабатывает Log Insight).

Также в VMware vRealize Network Insight 3.8 появилось несколько небольших нововведений, полный список которых указан в Release Notes. Скачать vRNI 3.8 можно по этой ссылке.


Таги: VMware, vRealize, Network Insight, Update, Security, Networking

VMware vMotion зависает на 21% - некорректный размер MTU пакета.


У некоторых администраторов VMware vSphere время от времени возникает проблема с горячей миграцией vMotion виртуальных машин, например, когда они выводят хост в режим обслуживания (Maintenance Mode). vMotion зависает на 21%, и на vCenter Server появляется ошибка наподобие такой:

Failed waiting for data. Error 195887137. Timeout. vMotion migration failed to send buffer to remote host. vMotion migration failed writing stream completion.

Еще одно сообщение об ошибке в этом случае выглядит вот так:

The vMotion failed bacause the destination host did not receive data from the source host on the vMotion network. Failed to initialize migration at source. Error 195887109.

На панели задач мы видим вот такую картину:

Если посмотреть на лог-файлы, то там не обнаруживается никаких проблем. Но подобного рода ошибки, если внимательно поискать их в VMware KB, указывают на разные сконфигурированные значения MTU пакета в виртуальной инфраструктуре и на портах физических коммутаторов. Например, на vSphere Distributed Switch для порта VMkernel, через который идет миграция vMotion, размер MTU у вас выставлен в 9000 (для поддержки Jumbo Frames), а вот на на порту свича - 1500.

Поэтому всегда проверяйте, чтобы размер MTU был одинаковым на всех компонентах физической и виртуальной инфраструктуры - vDS и портах коммутатора. Более подробно о настройке Jumbo frames написано в KB 1038827.


Таги: VMware, vSphere, vMotion, Networking, Enterprise, Troubleshooting

Бесплатное руководство по подготовке к экзаменам Cisco CCNA на 350 страницах!


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

Специально для таких администраторов, активист Neil Anderson выпустил руководство по лабораторным работам на 350 страницах (!), которое поможет сдать экзамены на сертификацию Cisco CCNA (Cisco Certified Network Associate). В частности, в нем раскрываются детали лаб последних версий экзаменов 200-125 CCNA, 100-105 ICND и 200-105 ICND.

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

  • The IOS Operating System
  • The Life of a Packet
  • The Cisco Troubleshooting Methodology
  • Cisco Router and Switch Basics
  • Cisco Device Management
  • Routing Fundamentals
  • Dynamic Routing Protocols
  • Connectivity Troubleshooting
  • RIP Routing Information Protocol
  • EIGRP Enhanced Interior Gateway Routing Protocol
  • OSPF Open Shortest Path First
  • VLANs and Inter-VLAN Routing
  • DHCP Dynamic Host Configuration Protocol
  • HSRP Hot Standby Router Protocol
  • STP Spanning Tree Protocol
  • EtherChannel
  • Port Security
  • ACL Access Control Lists
  • NAT Network Address Translation
  • IPv6 Addressing
  • IPv6 Routing
  • WAN Wide Area Networks
  • BGP Border Gateway Protocol
  • Cisco Device Security
  • Network Device Management 

Скачать документ можно по этой ссылке: Free CCNA Lab Guide. Штука-то очень нужная для тех, кто сдает на CCNA, так что качайте.


Таги: Cisco, Networking, Whitepaper

Диаграмма компонентов, соединений и портов vRealize Operations Manager 6.6.


Компания VMware выпустила полезную администраторам VMware vSphere диаграмму компонентов, соединений и портов, посвященную решению vRealize Operations Manager 6.6. Напомним, что о самом продукте vROPs 6.6, выпущенном летом этого года, мы писали вот тут.

Коммуникации, обозначенные на диаграмме рассматриваются как на уровне кластера, так и в рамках компонентов одного узла. Слева на плашках приведены комментарии для различных уровней - на зеленом фоне пояснение принципов взаимодействия между компонентами и требования продукта (например, необходимость обеспечения 5 ms latency между узлами или пояснения к механизму HA), а на синем фоне детально рассказывается об устройстве ноды, ее компонентах - сервисах, базе данных, адаптерах и прочем.

На странице KB о диаграмме vRealize Operations Manager 6.6 есть ссылка на загрузку файла в формате PDF.


Таги: VMware, vROPs, Diagram, Networking, Automation, Monitoring

Диаграмма портов и соединений VMware Horizon 7 - обновления.


Довольно давно мы не писали о диаграмме портов и соединений VMware Horizon 7 (последний раз вот тут год назад). С тех пор этот документ порядочно обновился, и совсем недавно его новая версия стала доступна для загрузки (от сентября 2017 года). Пока это диаграмма для VMware Horizon 7.2, хотя пару недель назад вышел Horizon 7.3. Но существенно, в плане портов, там ничего не изменилось.

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

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


Таги: VMware, Horizon, Networking, View, VDI, Ports

Что такое Veeam Powered Network (VeeamPN), и для чего нужен.


Еще на VeeamON 2017 весной этого года компания Veeam Software рассказала о новом решении Veeam Powered Network (Veeam PN), которое стало первым продуктом Veeam в области сетевого взаимодействия.

Вот его небольшой видеообзор от Anthony Spiteri, евангелиста Veeam:

Veeam PN - это простое средство для организации VPN между всеми компонентами вашей инфраструктуры - главным офисом, филиалами и подразделениями, удаленными работниками и т.п. Решение построено на базе открытой технологии OpenVPN и представляет собой специальную виртуальную машину, работающую в облаке Microsoft Azure (Veeam PN Server) или на стороне частного облака клиента, а также компоненты на стороне оконечных потребителей (Veeam PN Gateway):

Помимо готовой машины Veeam PN на стороне Azure, в качестве центрального координационного сервера, выполняющего функции маршрутизации, можно использовать обычную ВМ в онпремизной инфраструктуре VMware vSphere. Для этого нужно загрузить и развернуть виртуальный модуль Veeam PN Appliance в формате OVA.

Надо отметить, что Veeam PN - это полностью бесплатный продукт, который является сетевой подложкой для комплексного решения по обеспечению катастрофоустойчивости датацентров Veeam Recovery to Microsoft Azure. Но Veeam PN можно использовать и как простой VPN для предприятий, которым необходима простая в развертывании инфраструктура виртуальной частной сети.

Архитектура сетевой инфраструктуры Veeam PN может быть любой, например, может быть топология, где есть виртуальная машина Veeam PN Server на стороне Azure, клиентское ПО Veeam PN Gateway в трех географически разделенных датацентрах, а также отдельные внешние пользователи частной сети, подключающиеся с помощью клиента OpenVPN Client.

При развертывании продукта нужно выбрать одну из двух опций:

Network Hub - это сервер Veeam PN, который развертывается в облаке Azure или в частной инфраструктуре, а Site gateway - это виртуальная машина, выступающая как шлюз для Veeam PN. Для коммуникации используются 2048-битные самоподписанные сертификаты. Первоначальная настройка сервера выглядит так:

Далее мы задаем опции сетевой коммуникации:

  • Network hub public IP or DNS name - это публичный адрес, к которому должны иметь доступ все члены частной сети, включая удаленных клиентов вне частных облаков, которые будут подключаться к инфраструктуре.
  • Enable site-to-site VPN - эту опцию надо поставить, если необходима коммуникация между датацентрами (между Veeam PN Gateways).
  • Enable point-to-site VPN - эти настройки выставляются для коммуникации между клиентом OpenVPN Client и компонентом Veeam PN Gateway на стороне датацентра.

После того, как вы развернете Veeam PN сервер, нужно сгенерировать настройки для сетей датацентров (сценарий site-to-site) и отдельных компьютеров (сценарий point-to-site). Для этого нужно зарегистрировать сайты и компьютеры на стороне Veeam PN Server (Hub portal):

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

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

Если сервер Network Hub развернут в онпремизной сети, вам нужно добавить новый маршрут на шлюзе по умолчанию (Default gateway) в онпремизной сети, где у вас развернут Veeam PN Server, а также в сетях площадок, где есть Site Gateways, чтобы обе стороны VPN-туннеля знали маршрут (подробнее об этом написано тут).

Когда вы регистрируете Site Gateways на стороне Network Hub и добавляете XML-конфигурацию сетевого хаба на стороне площадки, то вы даете им возможность узнать, за какие сетевые зоны отвечают Site Gateways, и где находится Network Hub. Однако виртуальные машины на площадках также должны иметь возможность достучаться до виртуальных машин в других зонах через шлюзы по умолчанию, для того и нужно добавлять статические маршруты. Ведь после того, как трафик через Site Gateway одной площадки доходит до Network Hub, он уже корректно перенаправляется к соответствующей площадке через ее Site Gateway.

Например, у вас есть такая инфраструктура (пример взят отсюда):

Тогда таблица статических маршрутов на сайте MEL будет выглядеть так:

В качестве Next hope тут указан Site Gateway данной площадки, который далее отправит трафик к Veeam PN Server, дальше он будет направлен к машине на другой площадке. Аналогично маршруты будут выглядеть и на других площадках.

Если вы используете Veeam PN Server на стороне Azure добавлять новые маршруты не потребуется - Veeam PN сам добавит все необходимые маршруты в таблицы маршрутизации. Кстати, в качестве компонентов сетевой инфраструктуры Veeam PN можно использовать инфраструктуры на стороне публичных IaaS-сервисов AWS, IBM или Google, а также любого другого публичного облака.

Загрузить бесплатное решение Veeam PN можно по этой ссылке. Там же можно скачать и пробную версию продукта Veeam Recovery to Microsoft Azure.


Таги: Veeam, Veeam PN, Security, vNetwork, Networking, VPN

Все, что вы хотели знать о VMware NSX, на сайте VMware Walkthrough.


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

Недавно обновился раздел Walkthrough, посвященный решению VMware NSX. Теперь можно сказать, что там можно узнать о продукте все. Напомним, что NSX - это средство объединения и виртуализации сетей предприятия, реализующее единую точку управления виртуальными и физическими сетями в рамках концепции Software Defined Networking (SDN).

Серия обучающих интерактивных сцен включает в себя следующие разделы:

  • VMware NSX - этот раздел показывает различные возможности NSX, включая такие компоненты, как Manager, Gateway Service, Firewall, а также средства мониторинга, решения проблем и интеграции с системами CMS.
  • NSX for vSphere - здесь рассказывают о том, как использовать возможности NSX, такие как VXLAN, Network Virtualization и средства бриджинга сетей между VXLAN и традиционными VLAN.
  • Security and Compliance - в этой секции обсуждаются вопросы адаптации концепции Software Defined Datacenter (SDDC) в корпоративном датацентре, такие как распределенный сетевой экран и возможности NSX service composer.
  • NSX Partner Integration - тут демонстрируют расширяемость решения NSX за счет интеграции с партнерскими решениями, такими как шлюзы и средства обеспечения информационной безопасности.
  • NSX and Log Insight - полезный раздел об интеграции с решением для сбора и анализа о жизнедеятельности датацентра Log Insight.
  • Integration with VMware Components - этот раздел об интеграции с другими продуктами и платформами VMware.
  • NSX 2.0 - эта секция посвящена глобальным возможностям по автоматизации датацентра, операционным функциям решения и безопасности сетевой среды.

VMware Walkthrough о решении VMware NSX доступны по этой ссылке.


Таги: VMware, NSX, Walkthrough, Update, Networking

Диаграмма портов и соединений в среде сетевой виртуализации VMware NSX.


В крупных компаниях, где виртуальная инфраструктура является основой всего ИТ, иногда используется продукт VMware NSX для виртуализации и агрегации сетей виртуальных (на базе vSphere) и физических сред. Напомним, что с 3 мая этот продукт также стал доступен в трех изданиях, что позволит приобретать его и небольшим компаниям в базовом издании Standard.

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

Вот эти порты, протоколы и коммуникации для компонентов NSX:

  • Client PC > NSX Manager 443/TCP (NSX Manager Administrative Interface)
  • Client PC > NSX Manager 80/TCP (NSX Manager VIB Access)
  • ESXi Host > ESXi Host 6999/UDP (ARP on VLAN LIFs)
  • ESXi Host > NSX Controller 1234/TCP (User World Agent Connection)
  • ESXi Host > NSX Manager 5671/TCP (AMQP)
  • ESXi Host > NSX Manager 8301, 8302/UDP (DVS Sync)
  • ESXi Host > vCenter Server 80/TCP (ESXi Host Preparation)
  • NSX Controller > NSX Controller 2878, 2888, 3888/TCP (Controller Cluster – State Sync)
  • NSX Controller > NSX Controller 30865/TCP (Controller Cluster -State Sync )
  • NSX Controller > NSX Controller 7777/TCP (Inter-Controller RPC Port)
  • NSX Controller > NTP Time Server 123/TCP (NTP client connection)
  • NSX Controller > NTP Time Server 123/UDP (NTP client connection)
  • NSX Manager > DNS Server 53/TCP (DNS client connection)
  • NSX Manager > DNS Server 53/UDP (DNS client connection)
  • NSX Manager > ESXi Host 443/TCP (Management and provisioning connection)
  • NSX Manager > ESXi Host 8301, 8302/UDP (DVS Sync)
  • NSX Manager > ESXi Host 902/TCP (Management and provisioning connection)
  • NSX Manager > NSX Controller 443/TCP (Controller to Manager Communication)
  • NSX Manager > NTP Time Server 123/TCP (NTP client connection)
  • NSX Manager > NTP Time Server 123/UDP (NTP client connection)
  • NSX Manager > Syslog Server 514/TCP (Syslog connection)
  • NSX Manager > Syslog Server 514/UDP (Syslog connection)
  • NSX Manager > vCenter Server 443/TCP (vSphere Web Access)
  • NSX Manager > vCenter Server 902/TCP (vSphere Web Access)
  • REST Client > NSX Manager 443/TCP (NSX Manager REST API)
  • vCenter Server > ESXi Host 80/TCP (ESXi Host Preparation)
  • vCenter Server > NSX Manager 80/TCP (Host Preparation)
  • VTEP > VTEP 8472/UDP (Transport network encapsulation between VTEPs.)

Таги: VMware, NSX, Poster, Networking, vNetwork, Enterprise

Как правильно настроить сетевые интерфейсы для StarWind Virtul SAN - вебинар.


Компания StarWind Software, производитель лучшего решения для создания программных iSCSI-хранилищ под виртуализацию, весьма часто проводит практические вебинары, посвященные отдельным аспектам настройки своего продукта. Некоторое время назад сотрудники компании рассказывали о том, как обновить Virtual SAN без простоя инфраструктуры, а также о настройке решения StarWind VTL. В этот раз речь пойдет о правильной настройке сетевых интерфейсов Virtual SAN для доступа к хранилищам по протоколу iSCSI (инициатор и таргет), а также необходимой конфигурации сетевых интерфейсов на хосте хранения.

Присоединяйтесь к бесплатному вебинару "Support Case: Network Interface Tuning for iSCSI and Synchronization":

Дата и время мероприятия: 26 мая в 15-00 по московскому времени.

Регистрируйтесь!


Таги: StarWind, Virtual SAN, Webinar, Networking

Новые издания VMware NSX - теперь и для небольших компаний, а также VDI-сред.


Некоторые из вас слышали о продукте VMware NSX, которые представляет собой платформу для виртуализации сетей виртуальных (на базе vSphere) и физических сред, которая ранее была доступна только для крупных предприятий ввиду своей высокой цены.

С 3 мая компания VMware решила изменить этот подход, представив решение NSX в трех изданиях - Standard, Advanced и Enterprise. Теперь и небольшие компании смогут использовать издание Standard за меньшую цену и постепенно расти до издания Enteprise, если возникнет потребность в большем функционале платформы.

Все три издания лицензируются по физическим процессорам серверов (чтобы соответствовать изданиям VMware Virtual SAN), однако издание Advanced лицензируется также и по пользователям, чтобы NSX было удобно применять в VDI-средах.

В целом издания VMware NSX можно описать так:

  • Standard - это базовые возможности распределенной коммутации и маршрутизации, которые подходят для совместного использования с vSphere Standard. Вы сможете создавать сети VXLAN в виртуальной инфраструктуре и соединять их с физической сетью предприятия с помощью NSX Edge, но остальные интересные возможности NSX будут недоступны, так как Distributed Firewalling и балансировка нагрузки. Также доступна интеграция с OpenStack через API.
  • Advanced - это уже более интересное издание, здесь уже есть интеграция с Active Directory и такие компоненты, как Edge load balancing и Distributed Firewall. Но здесь еще нет возможностей VPN и поддержки нескольких сайтов со своими vCenter. Это издание подойдет большинству пользователей, у которых есть только один датацентр. Также его удобно использовать для создания сетевой платформы инфраструктуры виртуальных ПК.
  • Enterprise - это полнофункциональное издание для большой сетевой инфраструктуры, а также предприятий с несколькими ЦОД, в которых присутствует несколько серверов vCenter, объединенных между собой. Тут также присутствуют функции распределенной балансировки (пока только в режиме Tech Preview).

Приведем ниже полное сравнение возможностей изданий VMware NSX 6.2, а краткое доступно вот тут.

NSX for vSphere 6.2

Возможность

Standard

Advanced

Enterprise

Hypervisors supported

ESXi 5.5

ESXi 6.0

vCenter 5.5

vCenter 6.0

Cross vCenter Networking & Security

Controller Architecture

NSX Controller

Universal Controller for X-VC

Optimized ARP Learning, BCAST supression

Switching

Encapsulation Format

 

 

 

VXLAN

Replication Mode for VXLAN

 

 

 

Multicast

Hybrid

Unicast

Overlay to VLAN bridging

 

 

 

SW Bridge (ESXi-based)

Hardware VTEP (OVSDB) with L2 Bridging

Universal Distributed Logical Switching (X-VC)

Multiple VTEP Support

Routing

Distributed Routing (IPv4 Only)

 

 

 

Distributed Routing - Static

Distributed Routing - Dynamic Routing with BGP

Distributed Routing - Dynamic Routing with OSPF

Equal Cost Multi-Pathing with Distributed Routing

Universal Distributed Logical Router (X-VC)

Dynamic Routing without Control VM (Static Only)

Active-standby Router Control VM

Edge Routing (N-S)

 

 

 

Edge Routing Static - IPv4

Edge Routing Static - IPv6

Dynamic Routing with NSX Edge (BGP) IPv4

Dynamic Routing with NSX Edge (OSPFv2) IPv4

Equal Cost Multi-Pathing with NSX Edge

Egress Routing Optimization in X-VC

DHCP Relay

Active-Standby NSX Edge Routing

VLAN Trunk (sub-interface) support

VXLAN Trunk (sub-interface) support

Per Interface RPF check on NSX Edge

Services

NAT Support

 

 

 

NAT Support for NSX Edge

Source NAT

Destination NAT

Stateless NAT

ALG Support for NAT

DDI

 

 

 

DHCP Server

DHCP Relay

DNS Relay

VPN

 

 

 

IPSEC VPN

SSL VPN

L2 VPN (L2 extension with SSL VPN)

802.1Q Trunks over L2 VPN

Security

 

 

 

Firewall - General

 

 

 

Single UI for Firewall Rule Enforcement - NS+ EW

Spoofguard

Firewall Logging

Rule Export

Auto-save & Rollback of Firewall rules

Granular Sections of Firewall rule table

Distributed Firewall

 

 

 

DFW - L2, L3 Rules

DFW - vCenter Object Based Rules

Identity Firewall Rules (AD Integration)

IPFix Support for DFW

Context-based control of FW enforcement 
(applied to objects)

Edge Firewall

Edge High-Availability

Service Composer

 

 

 

Security Policy

Security Tags

vCenter Object based security groups

IPSet, MACset based security groups

Data Security

Scan Guest VMs for Sensitive Data

Third Party Integration

 

 

 

Endpoint Service Insertion - Guest Introspection

 

Network Service Insertion

Public API based Integration

 

Load-Balancing

Edge Load-Balancing Protocols

 

 

 

TCP (L4 - L7)

UDP

FTP

HTTP

HTTPS (Pass-through)

HTTPS (SSL Termination)

LB Methods

Round Robin

Src IP Hash

Least Connection

URI, URL, HTTP (L7 engine)

vCenter Context-aware LB

L7 Application Rules

Health Checks

TCP

ICMP

UDP

HTTP

HTTPS

Connection Throttling

High-Availability

Monitoring

View VIP/Pool/Server Objects

View VIP/Pool/Server Stats

Global Stats VIP Sessions

Distributed Load-Balancing

 

 

 

L4 Load-balancing

(tech-preview)

Health checks

(tech-preview)

Operations / Tools

Tunnel Health Monitoring

TraceFlow

Port-Connections Tool

Server Activity Monitoring

Flow Monitoring

IPFix (VDS Feature)

VMware Tools

 

 

 

vR Operations Manager

vR Log Insight

Cloud Management Platform

vRealize Automation

 

 

 

Logical Switch Creation

Distributed router creation

Distributed firewall security consumption

Load-balancing consumption

App Isolation

VMware Integrated OpenStack (Neutron Plugin)

 

 

 

VLAN Provider Networks

Overlay Provider Networks

Overlay Tenant Networks

Metadata Proxy Service

DHCP Server

Neutron Router - Centralized - Shared

Neutron Router - Centralized - Exclusive

Neutron Router - Distributed

Static Routes on Neutron Router

Floating IP Support

-NAT Neutron Routers

Neutron Security Groups using Stateful Firewall

Port Security

Neutron L2 Gateway

Load Balancing (LBaaS)

Admin Utility ( Consistency Check, Cleanup)

Cross VC Logical Networking and Security

 


Таги: VMware, NSX, Licensing, Update, Networking

Новый документ VMware Virtual SAN 6.2 Network Design Guide с практическими рекомендациями по конфигурации сетевого окружения.


Компания VMware выпустила весьма полезный документ "VMware Virtual SAN 6.2 Network Design Guide", в котором приведены конкретные рекомендации по настройке и конфигурации сети при организации отказоустойчивых кластеров хранилищ.

Посмотрим, какие интересные моменты есть в документе. Например, рассматривается следующая архитектура построения кластера Virtual SAN (это Leaf-Spine архитектура):

В такой сети показатель переподписки (oversubscription) между стойками равен 4:1 (от хостов идет 16 линков по 10 Гбит к свичу, от которого идет 4 линка по 10 Гбит к Spine-коммутатору). В этом случае, если предположить, что на хостах 10 ТБ емкости, из которых 6 ТБ занимают данные виртуальных машин, и вдруг возникнет необходимость операции rebuild для кластера (при FTT=1), то при использовании 3/4 пропускной способности канала (то есть 30 Гбит/с) операция займет 26 минут. Если же объем данных на хосте увеличить до 12 ТБ, а канал уменьшить до 10 Гбит/с, то rebuild займет 156 минут. Мораль такова - нельзя перебарщивать с переподпиской, а также нужно обеспечить широкий канал между узлами кластера.

Еще из рекомендаций в документе:

  • Отключите Flow Control на физическом оборудовании, у Virtual SAN есть свой механизм контроля перегрузки канала.
  • Используйте vSphere Distributed Switch (VDS) совместно с Virtual SAN.
  • Настройте Load Based Teaming (LBT), который балансирует нагрузку, в зависимости от загрузки физического адаптера (похоже на Virtual Port ID, только привязка к порту пересматривается каждые 30 секунд).
  • Если используете несколько кластеров Virtual SAN - помещайте трафик каждого из них в отдельный VLAN.
  • Если в датацентре используются большие кадры jumbo frames - используйте их в кластере Virtual SAN, но если не используются - то отдельно включать их не надо.
  • Включите Cisco Discovery Protocol (CDP) и Link Layer Discovery Protocol (LLDP) в режимах и приема, и передачи.

В документе присутствует еще несколько интересных рекомендаций, прочитать которые будет особенно интересно администраторам крупных инфраструктур и больших кластеров Virtual SAN.


Таги: VMware, Virtual SAN, Whitepaper, Performance, Обучение, VSAN, Networking

Диаграмма портов и соединений VMware Horizon 7 - новые компоненты.


Вчера мы писали о том, что компания VMware выпустила новую версию решения для виртуализации и доставки ПК предприятия VMware Horizon 7. А сегодня приятное дополнение - полная диаграмма портов и соединений в инфраструктуре VMware Horizon 7, включая компоненты VMware View, App Volumes, Identity Manger, vRealize Operations и прочие:

Что нового появилось в этой диаграмме по сравнению с ее прошлой версией:

  • View Agent был переименован в Horizon Agent.
  • Компонент Access Point расположен том же месте, что и View Security Server (это альтернативные компоненты при развертывании решения).
  • Объект RDSH / Virtual Desktop включает в себя декстопы с гостевыми ОС Windows, Linux и RDSH. (Horizon for Linux использует протокол Blast Extreme).
  • VMware vRealize Operations for Horizon теперь является частью диаграммы.
  • Добавлен App Volumes Agent.
  • Добавлен новый компонент Enrollment Server, относящийся к True SSO.

Таги: VMware, Horizon, Diagram, Poster, View, Networking

Как перезапустить Management Network на VMware ESXi из командной строки.


Многим администраторам виртуальной инфраструктуры VMware vSphere зачастую приходится перезапускать Management Network после различных операций с хостом VMware ESXi (например, чтобы обновить аренду IP-адреса у DHCP-сервера).

Делается это из консоли сервера ESXi (DCUI) в пункте меню "Restart Management Network":

Напомним, что доступ к графическому интерфейсу консоли сервера (DCUI) можно получить и по протоколу SSH, выполнив команду:

# dcui

Однако многие хотели бы рестартовать сеть ESXi консольной командой ESXCLI, которую можно выполнить, например, из vSphere Management Assistant. Для этого нужно просто отключить и включить сетевой интерфейс VMkernel на хосте. Делается это через пространство имен esxcli network.

При этом, поскольку вы подключены к ESXi через этот интерфейс, то нужно, чтобы две команды (отключение и включение) были выполнены обязательно вместе. Делается это добавлением точки с запятой (";") между командами.

Итак, узнаем имя интерфейса командой:

esxcli network ip interface ipv4 get

Далее отключаем и включаем интерфейс vmk0, что соответствует функции Restart Management Network в графическом интерфейсе хоста:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0


Таги: VMware, ESXi, vNetwork, Networking, VMachines, Blogs

Очередная диаграмма VMware - порты и соединения VMware Horizon View 5.2.


Компания VMware время от времени выпускает интересные постеры и диаграммы (кстати, они вывешены у нас в правой колонке чуть пониже), которые отражают различные процессы и описывают компоненты инфраструктуры VMware vSphere, View, vCloud и прочие. Не так давно был выпущен постер с портами и соединениями VMware vSphere 5.1, а на днях VMware выпустила аналогичный плакат с диаграммой портов "Network port diagram for Horizon View", который наглядно показывает взаимодействие компонентов, а заодно и дает информацию сетевым администраторам о том, какие правила нужно добавить в сетевой экран:

Там же, на страницах за постером, приведена таблица портов с пояснениями к используемым соединениям в инфраструктуре виртуальных ПК VMware View 5.2:

Нужная и полезная штука. Хотя с выходом VMware View 5.3 ее все же придется обновить, так как появятся новые компоненты (например, View Agent Direct Connection Plugin) или изменятся существующие (например, HTML Access).


Таги: VMware, View, Poster, Horizon, Networking, VDI

1 | 2    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

24/04/2019:  VMware vForum Online 2019
29/05/2019:  IT&SECURITY FORUM 2019
05/06/2019:  IT Management Forum 2019

Быстрый переход:
StarWind VMware IT-Grad Veeam PowerCLI Offtopic Gartner Citrix VSAN 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V HCI Labs vSAN App Volumes Tools Video vROPs Workspace ONE Backup Horizon VMUG vCloud NSX vRNI HA Update Manager VCP VVols Workstation Update UEM DR Networking Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio SRM Log Insight Operations Manager SDDC Virtual Appliance OpenStack Forum PowerShell LSFS Client vCSA Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL iSCSI Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint CLI Helpdesk Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils Memory API Android Graphics Diagram Air Plugin DPM SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Работа с дисками виртуальных машин VMware.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.