Вопросы конфигурации и администрирование vRealize Network Insight 6.2

В предыдущем нашем материале «Инсталляция и базовая настройка vRealize Network Insight 6.2» из цикла по такому замечательному, без преувеличения, продукту по мониторингу, аналитике и управлению сетями всех типов и безопасностью – vRealize Network Insight – мы разбирали, что же он представляет собой, на самом деле, узнали о требованиях, которые предъявляются к среде и конфигурации, для успешной работы vRNI, а также научились грамотно его последовательно разворачивать и осуществлять необходимую базовую настройку. Сегодня в прицел нашего внимания попробуем поместить все, что касается практической с ним работы, вопросы глубокой настройки и использования возможностей продукта по максимуму. А обновлению vRNI со старых версий на самые свежие посвятим, обещаем, в обязательном порядке одну из следующих отдельных статей.

Об UI vRNI

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

Домашняя страница поделена на несколько секций:

Поисковая строка (расположена в самом верху). Используется для поиска любых сущностей, доступных в нашем дата-центре. Его можно инициировать, опираясь на следующие параметры временной шкалы:
- Presets (можно сузить результаты поиска по пресетам вида «last week», «last 3 days», «last 24 hours», «yesterday», «today», «last 2 hours», «last hour» и «now»);
- At (поиск задается по конкретной дате и времени);
- Between (поиск данных в заданном интервале времени);
Plan (левая часть длинного, на всю страницу, поля под поиском). Здесь два блока:
- Micro Segments (осуществляется планирование микро-сегментации сети на основе потоков между всеми ВМ);
- Application (определяются приложения и анализируются их потоки, планируется их безопасность);
Operate & Troubleshoot (правая часть длинного, на всю страницу, поля под поиском). Здесь можно найти просмотр, вывод метрик и аналитики по таким компонентам:
- VM,
- Kubernetes,
- Datacenter,
- VeloCloud Enterprize,
- VMware NSX Manager;
Open Problems (левая часть нижнего большого блока). Вывод критических предупреждений об обнаруженных и еще не решенных проблемах. Все однотипные проблемы группируются, и чтобы вывести их на экран все, нужно нажать на «Show all». По каждому предупреждению можно просмотреть детали, если кликнуть по пиктограммке «плюсик в лупе». Также можно отредактировать то или иное предупреждение, если нажать на опцию «Edit Alert» под «More Options», встав на него – перейдем прямо на страницу «Edit – Alert Definition», после чего можно изменить конфигурацию;
What’s Happening (правая часть нижнего большого блока). Быстрый обзор самых ценных объектов дата-центра. Чтобы просмотреть подробности об их свойствах, следует кликнуть на счетчик конкретного. Также в этой секции слева есть фильтры для быстрого поиска подробностей предупреждений и кнопки раскрытия всех их, или, наоборот, сворачивания.

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

Plan & Assess. В его выпадающем меню можно найти:
- Plan Security. Анализ потоков в среде и помощь в планировании микро-сегментации в ней. Можно выбирать сущности или конкретную из них и затем – продолжительность анализа;
- Applications. Создание приложений в vRNI с применением пользовательского поиска. Как только приложение будет создано, можно соответствующим образом его спланировать;
- PCI Compliance. Панель, помогающая оценивать соответствие с PCI-требованиями – только в NSX-средах;
Intents. Желаемые состояния сети, описывающие бизнес-политику или архитектурную цель. Используется в проектировании, управлении и верификации сети, позволяет предсказывать ее поведение в прогрессе. Содержит список определенных системой встроенных намерений и пользовательские;
Alerts. Просмотр предупреждений (изменений и проблем) в среде. Предлагается список типов предупреждений (Critical/Moderate/Warning/Info или All/Intent/Problem/Change, конкретных по NSX, а также меню для управления определениями предупреждений – «Manage Intents» и «Manage Problems»), чтобы легче было выбирать нужный;
Environments. Информация о наших средах и действия с ними;
Analytics. Здесь можно обнаруживать все постороннее в системе, настраивать пороговые значения и получать аналитику потоков;
Path and Topology. Дает просматривать любой путь от ВМ к ВМ или топологию нескольких объектов дата-центра;
Entities. Показывает список всех различных типов сущностей, представленных в среде. Можно выбрать тип сущности из данного списка для вывода. Выше списка есть текстовое поле, используемое для его сужения, путем ввода определенного текста;
Pinboards. Все части приложений обозначены пинами – их можно сохранять, группировать и делиться ими с другими членами команды. В виде пинов оформлять можно что-угодно – от поисковых запросов, до всего, что касается сущностей;
Saved Searches. Содержит сохраненные ранее поиски, для удобства.

Настройка UI vRNI

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

Создание Support Bundle

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

На странице «Settings» кликаем на «Infrastructure and Support» – «Support»;
Выбираем ВМ-платформу и ВМ-коллекторы, для которых хотим создать этот пакет (галочки в заголовках соответствующих таблиц);
Кликаем на «Create Support Bundle»;
В подтверждающем диалоговом окне жмем «Yes».

Через какое-то время пакет создастся (например, в системе размера medium это займет минут 15). Чтобы впоследствии его загрузить, кликаем на ссылку «Download» по соответствующей ВМ.

Важно! В одно и то же время только два пакета поддержки могут существовать. Осторожно: создание нового при уже существующих двух сотрет самый первый из старых!

Включение Support Tunnel

Туннель поддержки позволит VMware удаленно подключаться к вашей платформе и ВМ-коллекторам по защищенному SSL-соединению с целью углубленного траблшутинга и дебаггинга. Включается он специально. Для этого нужно пройти в «Settings» – «Infrastructure and Support» – «Support» и включить опцию «Support Tunnel».

Важно! Предварительно нужно убедиться, что на порте 443 разрешен трафик к support2.ni.vmware.com.

Слежение за здоровьем системы

Значение опции просмотра статуса здоровья системы, конечно же, переоценить сложно. Во vRNI ключевыми его индикаторами являются запаздывание процесса, запаздывание индексатора и использование сетки. Логично, что, если все они – зеленые, с системой все в порядке. Красные показатели, соответственно, – это очень плохо. Обычно, такая ситуация происходит при остановке сбора данных коллектором, при прекращении платформой обработки данных по ряду причин (например, недостаточно места на диске) и при отставании поискового индексатора, в результате которого результаты такого поиска безнадежно устаревают.

Важно! vRNI может не обнаруживать несинхронизированные по времени системы. Синхронизация по NTP – жизненно важна, как мы уже говорили ранее в других статьях из этого цикла. В противном случае некоторые сервисы могут показываться как нездоровые, либо же перестать работать вовсе.

Чтобы следить за здоровьем, со страницы «Settings» переходим на «Infrastructure and Support» – «Overview and Updates» и там увидим соответствующую секцию – «System Health».

Если система в красном состоянии находится более шести часов, крайне рекомендуется обратиться в саппорт vRNI.

Просмотр информации о платформе и коллекторе

С этой целью заходим на «Settings» – «Infrastructure and Support» – «Overview and Updates» – «Platform VMs» и кликаем на имя интересующей ноды платформы в списке. Появится специальная панель мониторинга.

Чтобы сделать то же самое – но для ВМ-коллектора, заходим не на «Platform VMs», а на «Collector VMs» и точно так же ищем ее имя в списке.

Настройка интервала хранения данных

Важно! Подобная настройка возможна исключительно на Enterprise-уровне лицензии. В Advanced-редакциях срок хранения является дефолтным и равен 1 месяцу.

Срок хранения данных зависит от их типа:

предупреждения – от 1 до 13 месяцев,
данные сущностей и конфигураций – 1-3 месяца,
метрики – 1-13 месяцев,
потоки – 1 месяц (не меняется),
другие данные – любое значение – до достижения 100 ГБ использования дополнительного дискового пространства.

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

Чтобы настроить время хранения, нам, по сути, нужно отредактировать его политику. Для этого кликаем на «Settings» и в их секции – на «Data Management». Затем нажимаем на информационную иконку, отвечающую за конкретизацию путей занятия данными диска, и в верхнем правом углу – на иконку редактирования. В появившуюся форму вносим свои коррективы и нажимаем на «Submit» для сохранения и применения.

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

Настройка IP-свойств и подсетей

Для лучшей идентифицируемости и планирования безопасности во vRNI можно настраивать самые разнообразные свойства IP и делать другие интересные вещи. Например, очень полезен может быть импорт файла сопоставления DNS, чтобы предоставить информацию о потоках между физическими устройствами в Bind и CSV-формате (оба должны быть зазипованы вместе).

Важно! Запаролированные архивы vRNI не поддерживаются.

Для этого на странице «Settings» кликаем на «IP Properties and Subnets», а затем – на «Physical IP and DNS Mapping». Нажимаем на «Upload and Replace», чтобы начать подгрузку, выбрав нужный файл (содержит три информативных поля: имя хоста, IP-адрес и доменное имя), после чего обязательно кликнуть на «Validate». После валидации будет показан целый список записей DNS. Эта операция удалит любое существующее сопоставление DNS и заместит его только что импортированным.

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

На странице «Settings» кликаем на «IP Properties and Subnets», и уже там – на «Physical IP and DNS Mapping»;
Далее на странице «Settings» под «IP Properties and Subnets» нажимаем на «Physical Subnets and VLANs» – на странице покажется список всех подсетей и ассоциированных ID VLAN;
Нажимаем на «Add», чтобы добавить подсеть и VLAN-информацию;

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

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

Чтобы удалить такое сопоставление, нужно нажать на иконку удаления.

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

Еще, в завершение разговора о настройке IP, стоит пару слов сказать о конфигурировании IP E-W и N-S направлений. Для начала напомним, что IP диапазона RFC1918-стандарта считаются приватными, а те, которые вне его – это интернет-IP. Иногда пользователи хотят указать свои E-W IP (публичные в дата-центре) как не интернетовские, со всем прелагающимся тэгированием потоков и микро-сегментацией, даже если они не принадлежат диапазону RFC1918. Чтобы этого добиться:

Заходим на «Settings» и далее – в «East-West IPs»;
В боксе «IP Addresses» вводим нужные IP или их диапазон, или даже целые подсети и сохраняем настройку по «Save».

После этого система их станет воспринимать как не принадлежащие к интернет.

С другой стороны, IP из RFC1918-пространства категоризируются как N-S IP. Пользователи могут указать такие свои IP, чтобы и на них работали тэгирование потоков и микро-сегментация. Для этого там же, в «Settings», выбираем уже «North-South IPs» и в соответствующем боксе, как и ранее, вводим нужные IP или их диапазон, или даже целые подсети, после чего сохраняемся по «Save».

Настройка предупреждений и оповещений

В статье «Инсталляция и базовая настройка vRealize Network Insight 6.2» мы упоминали о том, что в vRNI доступна настройка богатого диапазона предупреждений и оповещений – система создает их, как только столкнется с ситуацией, описанной в том или ином правиле. Все это задается в тех же «Settings» – на странице «Alerts and Notification». Для работы с предупреждениями, заходим там на «Alert Definitions», где будет доступен просмотр всех предустановленных и уже созданных ранее пользователем предупреждений:

В vRNI известно несколько типов предупреждений, каждый из которых помещается на одноименную вкладку:

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

Если по предупреждению нажать на «View details» (значок «лупы»), по нему можно можно просмотреть детализированную информацию, включая рекомендации системы по исправлению проблемы:

Changes. Любые обнаруженные vRNI изменения в среде для сущности, свойств или метрик. Процедуры создания, апдейта и удаления чего-угодно является изменением;
Others. Все, сгенерированное внешними источниками данных и не определенное в vRNI. К примеру, предупреждения NSX-T, Kubernetes и пр.

По каждому предупреждению важны идентифицирующие их колонки – по ним можно фильтровать информацию и осуществлять поиск. Это – его имя, категория (Infrastructure/Limits and Threshold/Network Health/NI Platform Health/Search-based/Security), важность (Critical/Moderate/Warning/Info), тип посылаемого оповещения (по email, SNMP или и то, и другое – для критических указывать обязательно!) и статус (Enabled/Disabled). Установив курсор на каждое предупреждение мы должны увидеть не только его имя, но и описание, тэги предупреждений.

Кроме просмотра, с предупреждениями доступны такие действия, как их редактирование, выключение/включение, и даже инициация пакетного редактирования и включения/выключения. Чтобы отредактировать предупреждение, ищем интересующее и кликаем иконку редактирования в колонке «Action» по нему. Меняем, например, важность, добавляем или удаляем тэги, а также включаем или исключаем определенные сущности, о которых хотим получать предупреждения. Для последнего ставим галочку в «Include/Exclude entities» и кликаем на, допустим, «INCLUDE», указываем нужные сущности в выпадающем меню – можно выбрать сразу несколько, если нажать на кнопку «ADD CONDITION». Для удобства здесь доступна опция «Custom search», позволяющая написать свою собственную последовательность для включения или исключения сущностей. Также можно поставить галочку в «Send Notifications», и тогда становится доступным для редактирования условие, при котором будет посылаться оповещение (опции). В зависимости от того, настроен ли у вас Mail-сервер и настроена ли SNMP-ловушка, они создаются с нуля (ниже расскажем, как), или же из выпадающего меню выбирается частота получения писем (меню «Email frequency»), а в текстовое поле «Send notification emails to» вписывается сам адрес, выбираются назначения SNMP-ловушек из меню «Send SNMP Trap to» (можно выбирать не более четырех). А затем все сделанные настройки сохраняются по «SUBMIT»:

Если нужно отредактировать (или включить/выключить) сразу много предупреждений, удобно пользоваться пакетным способом. Для этого на странице «Alert Definitions» выбираем все нуждающиеся в изменении алерты, после чего над их списком появятся опции «ENABLE», «DISABLE» и «EDIT». Выбираем нужное действие, после задаем все то же самое и запускаем процесс по «SUBMIT».

Всплывшее однажды предупреждение можно выключить, если выбрать его прямо в виджете «Open Problems» домашней страницы vRNI, либо напрямую найдя его в списке (например, для удобства воспользовавшись поиском). Когда оно будет выбрано, нажимаем на значок по нему трех вертикальных точек и выбираем действие «Archive». Далее можно выбрать «Disable all alerts of this type in future for» и сущность или ряд сущностей, для которых хотим, чтобы это выполнялось и далее такое не показывало, после чего сохраняем все «SAVE».

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

Помимо описанного варианта создания алертов, существует еще один – весьма удобный во многих ситуациях. Прямо через поиск, что интересно, и, скажем откровенно, необычно. Как только вы выполняете поиск, появляется возможность создать предупреждение на основе результата этого поиска. Для таким образом созданных предупреждений существует отдельная категория – «Search-based alerts», и ее относят к классу «определенных пользователем»/«пользовательским». Процедура очень проста: в верхнем правом углу окна с результатом поиска появляется иконка «колокольчика» – «Define Alert», жмем на нее и нас переносит на специальную страничку определения предупреждения. Там прописываются такие характеристики:

имя («Name»),
критерий поиска для предупреждения («Search query»),
когда создавать предупреждение («Generate alert when»),
тип предупреждения («Definition type»),
важность («Severity»):

Далее ставим галочку в «Alert Notification» и выбираем частоту рассылки предупреждений в «Email frequency», указываем сам email в «Email addresses» и выбираем назначения ловушек из выпадающего меню «SNMP trap destination» (до 4 штук). После чего сохраняем всю настройку по «SUBMIT».

Последнее важное замечание, перед тем, как углубимся в настройку почтового сервера и SNMP-ловушек, касается ограничений по предупреждениям. А именно, одного очень специфичного, но – крайне проблемного предупреждения: «Distributed Firewall Rule Masked by Preceding Rule alert Limitation». Оно поддерживается только правилами распределенного файервола NSX-V и NSX-T, а также правилами файервола Edge и правилами файервола VMware Cloud на AWS. Других вендоров нижеследующее не касается. В маскировке вычислений сейчас актуальны такие параметры правила файервола:

Source,
Destination,
Applied To,
Service protocol and Port ranges,
Packet type,
Layer-7 application IDs.

Также важно помнить, что не поддерживаются правила с инверсией источника или назначения, правила с группами безопасности, содержащими исключенных членов напрямую или не напрямую в Source/Destination или в Applied To, а все выключенные правила – попросту игнорируются. Маскировка вычислений для параметров Source, Destination и Applied To базируется на статическом членстве и преимуществе диапазона IP над членами IPSet. Динамическое членство в группе безопасности при маскировке не рассматривается.

Конфигурирование оповещений почти аналогично тому, что мы описывали для предупреждений:

Выставляем важность, частоту оповещений по email, а также куда именно их отправлять и сохраняем настройку по «SUBMIT».

Настройка Mail-сервера

Если почтовый сервер еще не настроен, его можно инициировать в «Settings» – «Alerts and Notification» – «Mail Server» – «CONFIGURE». Откроется страница «Configure Mail Server», где заполняется email, на который мы хотим получать предупреждения, имя хоста или IP-адрес SMTP-сервера, выбирается из выпадающего меню способ шифрования (None/Use SSL/Support TLS) и вводится (необязательно) количество портов SMTP-сервера (по дефолту – 25).

Чтобы использовать сервер Gmail в качестве почтового, требуется дополнительная настройка параметров, которые выведены списком на Google Support. Опционально, для повышения безопасности, рекомендуется ставить галочку в «Authentication» и ввести там имя пользователя и пароль.

После всей сделанной настройки кликаем на «SUBMIT».

Настройка назначения SNMP-ловушки

Важно! Допустимые на данный момент версии SNMP – v2c и v3.

На странице «Settings» кликаем на «Alerts and Notification» – «SNMP Trap Destinations» – «ADD DESTINATION», откроется страница «Add SNMP Trap Destination», где в выпадающем меню «Version» выбираем протокол «SNMPv2c» или «SNMPv3».

Важно! v2c не требует аутентификации, в то время, как v3 – требует.

В текстовом поле «Destination IP Address/FQDN» вводим значения для нашего SNMP-агента, в «Destination Port» – номер его порта, и в зависимости от того, какой у нас протокол, для v2c в поле «Community String» вписываем строку комьюнити, а для v3 – имя пользователя в «Username» и опционально можно поставить галочку в «Use Authentication», а также выбрать протокол аутентификации (затем ввести пароль) и поставить галочку в «Use Privacy», выбрав протокол защиты, а также введя соответствующую фразу.

Далее в поле «Nickname» вписываем ник пользователя и, при желании, чтобы проверить, правильно ли сделана вся настройка, можно нажать на «SEND TEST TRAP», чтобы послать тестовую ловушку на SNMP-агент. Все назначенное сохраняем по «SUBMIT».

Однажды заданное назначение SNMP-ловушки можно удалить, если кликнуть по соответствующей иконке напротив выбранного назначения ловушки. Появится всплывающее окно подтверждения, и, если нужно смигрировать предупреждение из одного назначения ловушки на другое, следует кликнуть на «Select multiple destinations» в выпадающем меню и выбрать назначение, куда они оно должно переместиться. По завершению всего следует нажать на «CONFIRM».

Список всех существующих алертов приводить здесь не будем – он колоссален. Если интересно, для справки, вот ссылочка с ним. Соответственно, автономный по NSX-T-событиям – здесь, а по событиям Kubernetes – здесь.

Конфигурирование управления идентификацией и доступом

Вопросы регламентации пользовательского доступа для любого продукта VMware являются краеугольными. И для vRNI, конечно же, тоже. Как и везде, мы можем создавать и настраивать доступ LDAP или VMware Identity Manager пользователя, назначать ему ту или иную роль и т.д. Всего поддерживаются три глобальных типа ролей:

Administrator (полный доступ),
Member (ограниченный доступ),
Auditor (доступ «только для чтения» с запретом на действия по созданию, добавлению и удалению).

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

Страница	Действия	Administrator	Member	Auditor
[Settings] Logs: Audit Logs	Просмотр страницы аудит-логов/вкладок	+	–	+
	Включать/выключать персональную идентифицирующую информацию	+	–	Только просмотр
	Просмотр/фильтрация аудит-логов	+	–	+
	Экспорт в CSV	+	–	+
[Settings] Logs: Syslog Configuration	Просмотр страницы конфигурации Syslog	+	–	+
	Включать/выключать Syslog	+	–	Только просмотр
	Добавлять syslog-сервер	+	–	–
	Редактировать/удалять syslog-сервера	+	–	–
	Просмотр syslog-серверов	+	–	+
	Просмотр сопоставления серверов источников	+	–	+
	Редактировать сопоставление серверов источников	+	–	–
[Settings] About	Просмотр информации о продукте (имя, версия, вкладка Service)	+	+	+
[Settings] System Configuration	Просмотр страницы конфигурации системы	+	–	+
	Просмотр таймаута сеанса пользователя	+	–	+
	Редактирование таймаута сеанса пользователя	+	–	–
	Просмотр валидации сертификата источника данных	+	–	+
	Редактирование валидации сертификата источника данных	+	–	–
	Просмотр Google Maps Api Key	+	–	+
	Редактирование Google Maps Api Key	+	–	–
[Settings] My Preferences	Просмотр/редактирование My Preferences	+	+	+
[Settings] License and Usage	Просмотр страницы «License and Usage»	+	–	+
	Просмотр информации о лицензиях	+	–	+ (лицензионный ключ – ненулевой)
	Добавление/валидация лицензионного ключа	+	–	–
	Удаление лицензионного ключа	+	–	–
	Опция «Want to manage data sources»	+	–	–
	Опция (связь с аккаунтами и страницей источников данных) «ADD Data Source to Current Usage»	+	–	Только просмотр
[Settings] SNMP Trap Destinations	Просмотр страницы «SNMP Trap Destination»	+	–	+
	Просмотр списка существующих назначений SNMP (с настроенным количеством предупреждений)	+	–	+
	Просмотр списка настроенных для каждого назначения SNMP предупреждений	+	–	+
	Добавление/редактирование/удаление/миграция назначений SNMP	+	–	–
[Settings] Mail Server	Просмотр страницы «Mail Server»	+	–	+
	Просмотр существующей конфигурации почтового сервера	+	–	+
	Добавление/редактирование/удаление конфигурации почтового сервера	+	–	–
	Отсылка тестового email	+	–	–
[Settings] Identity & Access Management	Просмотр страницы «Identity & Access Management»	+	–	+
[Settings] Identity & Access Management: LDAP	Просмотр страницы LDAP	+	–	+
	Просмотр существующей конфигурации LDAP	+	–	+
	Добавление/редактирование/удаление конфигурации LDAP	+	–	–
[Settings] Identity & Access Management: VIDM	Просмотр страницы VIDM	+	–	+
	Просмотр существующей конфигурации VIDM	+	–	+
	Добавление/редактирование/удаление конфигурации VIDM	+	–	–
	Переключать конфигурацию VIDM	+	–	Только просмотр статуса
[Settings] Identity & Access Management: User Management	Просмотр страницы «User Management»	+	–	+
	Просмотр пользователей локальных/LDAP/VIDM	+	–	+
	Добавление/редактирование/удаление локального/LDAP/VIDM пользователя	+	–	–
[Settings] Events	Просмотр страницы «Events»	+	+	+
[Settings] Events: System Events	Просмотр страницы «System Events»	+	+	+
	Просмотр списка системных событий	+	+	+
	Редактирование системных событий	+	+	–
	Включение/выключение системных событий	+	+	Только просмотр статуса
	Пакетное редактирование/включение/выключение системных событий	+	+	–
[Settings] Events: Platform Health Events	Просмотр страницы «Platform Health Events»	+	+	+
	Просмотр списка событий здоровья платформы	+	+	+
	Редактирование событий здоровья платформы	+	+	–
	Пакетное редактирование событий здоровья платформы	+	+	–
[Settings] Events: User-Defined Events	Просмотр страницы «User-Defined Events»	+	+	+
	Просмотр списка определенных пользователем событий	+	+	+
	Редактирование/удаление определенных пользователем событий	+	+	–
	Включение/выключение определенных пользователем событий	+	+	Только просмотр статуса
[Settings] IP Properties and Subnets	Просмотр страницы «IP Properties and Subnets»	+	–	+
[Settings] Physical IP and DNS Mapping	Просмотр страницы «Physical IP and DNS Mapping»	+	–	+
	Просмотр списка импортированных физических IP и DNS-сопоставлений	+	–	+
	Выгрузка файла с физическими IP и DNS-сопоставлениями	+	–	+
	Загрузка/перемещение физических IP и DNS-сопоставлений	+	–	–
	Удаление существующих физических IP и DNS-сопоставлений	+	–	–
[Settings] Physical Subnets and VLAN	Просмотр страницы «Physical Subnets and VLAN»	+	–	+
	Просмотр списка существующих настроенных подсетей и VLAN	+	–	+
	Добавление/редактирование/удаление физических подсетей и VLAN	+	–	–
[Settings] East-West IPs / North-South IPs	Просмотр страниц «East-West IPs»/«North-South IPs»	+	–	+
	Просмотр существующих тэгов E-W/N-S IP	+	–	+
	Добавление/апдейт/удаление тэгов E-W/N-S IP	+	–	–
[Settings] Accounts and Data Sources	Просмотр страницы «Accounts and Data Source»	+	–	+
	Просмотр существующих источников данных	+	–	+
	Добавление/редактирование/удаление источников данных	+	–	–
	Включение/выключение существующих источников данных	+	–	Только просмотр статуса
[Settings] Data Management	Просмотр страницы «Data Management»	+	–	+
	Просмотр информации об интервале хранения данных	+	–	+
	Редактирование интервала хранения данных	+	–	–
[Settings] Infrastructure and Support	Просмотр страницы «Infrastructure and Support»	+	–	+
[Settings] Infrastructure and Support: Overview and Updates	Просмотр страницы «Overview and Updates»	+	–	+
	Просмотр информации в «Overview and Updates»	+	–	+
	Включение/выключение статуса онлайн-апдейтов	+	–	Только просмотр статуса
	Просмотр «Details/Start Upgrade: Online Update»	+	–	–
	Просмотр оффлайн-апдейта	+	–	–
	Загрузка оффлайн-пакетов	+	–	–
	Просмотр системного здоровья	+	–	+
	Просмотр ВМ-платформы	+	–	+
	Создание кластера	+	–	–
	Выгрузка пакета саппорта	+	–	+
	Просмотр ВМ-коллектора	+	–	+
	Добавление/редактирование/удаление ВМ-коллектора	+	–	–
[Settings] Infrastructure and Support: Support	Просмотр страницы «Support»	+	–	+
	Просмотр информации о саппорте продукта	+	–	+
	Включение/выключение туннеля поддержки	+	–	Только просмотр статуса
	Просмотр CEIP	+	–	+
	Редактирование CEIP	+	–	–
	Создание саппорт-пакета	+	–	–
	Загрузка саппорт-пакетов	+	–	+
[Settings] Templates	Просмотр страницы «Templates»	+	+	+
[Settings] Templates: Property Templates	Просмотр страницы «Property Templates»	+	+	+
	Просмотр существующих шаблонов свойств	+	+	+
	Клонирование/редактирование/удаление существующих шаблонов свойств	+	+ (только для им же созданных)	–
[Settings] Templates: App Discovery Templates	Просмотр страницы «App Discovery Templates»	+	+	+
	Просмотр существующих шаблонов обнаружения приложений	+	+	+
	Клонирование/редактирование/удаление существующих шаблонов обнаружения приложений	+	+ (только для им же созданных)	–
[Dashboard] Plan & Assess	Просмотр вкладки «Plan & Assess»	+	+	+
[Dashboard] Plan & Assess: Security Planning	Просмотр страницы «Security Planning» (микро-сегментация, распределение трафика, топ портов по байтам)	+	+	+
	Анализ планирования безопасности	+	+	+
	Прикрепление виджетов	+	+	–
	Отчет об оценке	+	+	+
	Просмотр механизма/списка микро-сегментации	+	+	+
	Экспорт в CSV	+	+	+
[Dashboard] Plan & Assess: PCI Compliance	Просмотр страницы «PCI Compliance»	+	+	+
	Оценка PCI-соответствия	+	+	+
	Прикрепление виджетов/создание предупреждений	+	+	–
	Экспорт в CSV/PDF	+	+	+
	Помощь	+	+	+
[Dashboard] Plan & Assess: Applications	Просмотр страницы «Applications»	+	+	+
	Добавление приложений	+	+	–
	Редактирование/удаление существующих приложений	+	+	–
	Экспорт	+	+	+
Application Discovery	Просмотр вкладки «Discover»	+	+	–
Application Discovery	Обнаружение приложений	+	+	–
[Dashboard] Analytics	Просмотр страницы «Analytics»	+	+	+
[Dashboard] Analytics: Outliers	Просмотр страницы «Outliers»	+	+	+
	Просмотр существующих посторонних конфигураций	+	+	+
	Добавление/редактирование/удаление посторонних конфигураций	+	+	–
	Включение/выключение существующих посторонних конфигураций	+	+	Только просмотр статуса
	Прикрепление виджетов	+	+	–
[Dashboard] Analytics: Thresholds	Просмотр страницы «Thresholds»	+	+	+
	Просмотр существующих пороговых конфигураций	+	+	+
	Добавление/редактирование/удаление существующих пороговых конфигураций	+	+	–
	Включение/выключение существующих пороговых конфигураций	+	+	Только просмотр статуса
	Прикрепление виджетов	+	+	–
[Dashboard] Analytics: Flow Insights	Просмотр страницы «Flow Insights»	+	+	+
	Анализ потоков	+	+	+
	Прикрепление виджетов	+	+	–
	Экспорт в CSV / увеличение / помощь	+	+	+
Saved Searches	Просмотр дефолтных сохраненных поисков	+	+	+
Saved Searches	Добавление/удаление новых сохраненных поисков	+	+	–

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

Зайти на страницу «Settings» и раскрыть «Identity & Access Management»;
Нажать на «User Management» и выбрать вкладку «VMware Identity Manager Users»;
Кликнуть на «ADD USER» и заполнить поля: Name, Email (Login ID), Role (выбираем подходящую из выпадающего списка), пароль и повторяем его еще раз;
Нажать на «Add User» для сохранения.

Чтобы назначить роль для пользователя LDAP, нам, естественно, предварительно нужно настроить LDAP, а далее:

На странице «Settings» раскрываем «Identity & Access Management»;
Нажимаем «User Management» и выбираем вкладку «LDAP Users»;
Кликаем на «ADD USER»;
Вписываем ID логина пользователя, которому собираемся назначить роль;
Выбираем роль из списка и сохраняем настройку, нажав на «ADD USER».

Еще одной полезной возможностью может считаться импорт пользователей из VMware Identity Manager. Для этого нам, безусловно, нужен изначально настроенный VIDM. Далее:

На странице «Settings» раскрываем «Identity & Access Management»;
Нажимаем на «User Management» и выбираем вкладку «VMware Identity Manager Users»;
Кликаем на «ADD USER» и заполняем доменное имя, вводим строку поиска по пользователям/группам, чтобы показался список подходящих, и выбираем там аккаунт. Учтите, что, если выбрали группу, все ее члены автоматически получат доступ к vRNI, и все они будут обладать того же уровня ролью. Чтобы назначить другую роль какому-то пользователю из этой группы, его нужно добавлять индивидуально – переназначить впоследствии не получится, только через добавление этой роли по-новой. Правда, здорово, что она просто перезапишет старые данные – группа от этого не пострадает и с ней делать ничего не нужно;
Нажимаем на «Add User».

Настройка логов

В vRNI доступны к просмотру и настройке различные типы журналов логов. Например, аудит-логи захватывают все действия по администрированию системы через UI, CLI и API, и существуют как регулярные CRUD-операции в этой связи, так и банальные предупреждения о логонах и выходах. За исключением:

SSH-логины (их можно найти в /var/log/auth.log),
изменения в физических IP и DNS-сопоставлениях,
изменения в физических подсетях и VLAN.

Функции аудит-логов включены всегда и работают они в UTC-формате. Этот вид журналов интегрирован в syslog, причем можно настроить syslog-коллектор так, чтобы он собирал все аудит-логи. И, наконец, можно их экспортировать в CSV-файл. Аудит-логи можно найти на странице «Settings», если в «Logs» зайти в «Audit Logs». Там отображается по каждой записи:

дата и время,
IP-адрес клиента, с которого была установлена связь,
имя пользователя,
объектный тип (объект, над которым совершалось действие),
операция,
идентификатор объекта (уникальный номер конкретного объекта),
ответ (success/failure) операции,
детали (что конкретно поменяли, например, ник, свойство и т.д.).

Можно разрешить сбор информации при входе пользователя через браузер или CLI, если включить «Allow collection of Personally Identifiable Information» – по умолчанию, эта опция выключена. Если она выключена, поля IP-адрес и имя пользователя по записи будут пустыми.

Выгрузка данных аудит-лога в CSV-формат происходит, если кликнуть на «Export as CSV».

Также можно настроить удаленные syslog-серверы под vRNI – делается это со страницы «Syslog Configuration». Потенциально, каждый коллектор может обладать своим удаленным syslog-сервером, а сервера платформ из кластера – использовать один и тот же syslog-сервер. Актуальный релиз продукта предупреждения о проблемах и сислоги платформы/коллектора отсылает на удаленный syslog-сервер. На данный момент vRNI поддерживает связь между серверами vRNI и удаленными syslog-серверами по UDP, поэтому очень важно проследить, чтобы этот трафик был настроен.

Для этого, вначале на странице «Settings» под «Logs» нажимаем на «Syslog Configuration». Эта страница будет содержать информацию обо всех настроенных syslog-серверах и их сопоставлениях с приведенными Virtual Appliance. Первый вход на эту страницу после установки продукта отразит выключенный по дефолту syslog и списка серверов там не будет. Чтобы добавить syslog-сервер, вначале включаем возможность его существования, как такового, вверху страницы, а затем:

Нажимаем на «Add Server»;
Вводим IP-адрес, ник и номер порта сервера (стандартный – UDP 514);
Кликаем на «Send Test Log», чтобы проверить связь;
Сохраняемся по «Submit».

Чтобы сопоставить новый сервер с платформами, коллекторами и предупреждениями, под «Source – Server Mapping» в индивидуальном порядке редактируем его под все нужные платформы, коллекторы или предупреждения, затем выбираем конкретный syslog-сервер и сохраняем настройку «Submit». Если не хотим включать syslog, выбираем опцию «No server». Подождав несколько минут, получим работающую схему.

Настройка интернет-прокси

Можно добавлять, редактировать и удалять интернет-прокси для подключения к другим сущностям (источникам данных, клауд-сервис-платформам и пр.), чтобы связь с ними шла через интернет. Функция работает с такими источниками данных, как VMware SD-WAN, Service Now, Amazon Web Services, Microsoft Azure и VMware Cloud на AWS NSX Manager (все – и по HTTP, и по HTTPS, за исключением Azure. Он – только по HTTP).

Важно! Коммуникация с CSP через веб-прокси на NTLM-аутентификации на данный момент не поддерживается.

Чтобы добавить интернет-прокси, заходим на «Settings» – «Web Proxies» – «ADD WEB PROXY» и в открывшемся окне заполняем поля Type (тип веб-прокси из выпадающего меню), IP Address/FQDN, Port и Nickname. Опционально можно поставить галочку в «Use credentials», вписать имя пользователя, пароль и обозначить метод аутентификации. Сохраняем все по «SUBMIT».

Когда все будет настроено, в конкретном источнике данных нужно включить веб-прокси, открыв его на редактирование и выбрав «Web Proxy (Optional)» в выпадающем меню.

Впоследствии, единожды добавленный интернет-прокси можно отредактировать или удалить. Для первого заходим в «Settings» – «Web Proxies» и по той прокси, которая нуждается в соответствующем действии, кликаем на иконку редактирования, меняем, как хотим, информацию, после чего снова сохраняемся по «SUBMIT».

Важно! Если интернет-прокси была добавлена через CLI, отредактировать ее не получится.

Удаление делается аналогично, но переписывать ничего не нужно, просто вылетит подтверждающее окошко, в котором нужно нажать на «DELETE».

Важно! Перед удалением веб-прокси следует убедиться, что ее «Connected Entities» обнулены. В противном случае их нужно сначала смигрировать на другую интернет-прокси, и только затем приступать к удалению.

Работа с лицензиями в vRNI

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

Важно! Если к апгрейду приурочили переход с Advanced лицензии на Enterprise, переключение предупреждающее сообщение не уберет – старую лицензию нужно будет удалить вручную.

Важно! Использование функций «Assurance and Verification» требует Enterprise-уровня лицензии. В принципе, они обладают своей собственной, которую можно использовать как автономную, однако, если весь продукт на Advanced, vRNI попросту не позволит ее добавить.

Учтите, что расчет лицензий vRNI производится специфично (объект: сокет):

По CPU vSphere машин хостов – 1:1;
По хостам VMware Cloud на AWS – 0,5:1 (если речь о VMC-хостах – 2:1);
vCPU AWS или инстансов Azure – 16:1;
Конечные точки, не относящиеся к VMware – 15:1.

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

Просмотр кол-ва лицензий и сопутствующих деталей доступен по каждой сущности на странице «License and Usage» (клик на индивидуальную ссылку). Там же можно добавлять лицензию (неограниченно) или менять ее тип. Добраться до этой страницы можно с «Settings».

Чтобы добавить новую лицензию, жмем на «Add», вводим ключ в поле «New License Key» и кликаем на «Validate», чтобы ее проверить (доступный для нее счетчик сокетов или ядер, тип и время истечения). После чего нажимаем на «Activate» – эта лицензия появится в общем списке страницы.

Удалить лицензию можно там же, если найти ее в списке и кликнуть по соответствующей иконке в колонке «Expiration».

Важно! Перед тем, как удалять действующую Enterprise-лицензию, и, если она является последней в системе, следует убедиться, что был до того удален аккаунт AWS (если есть).

Сменить лицензию (например, когда появилось предупреждающее сообщение о том, что ознакомительная заканчивается), можно просто, кликнув на ссылку в подобном сообщении, что перенесет нас на страницу «Change License». Либо же просто в «Settings» – «License and Usage» жмем на «Change License». Там в «New License Key» вводим новый ключ, снова «Validate», а затем – и «Activate».

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

Настройка авто-обновления

vRNI позволяет настраивать интервал авто-обновления для страниц сущностей и пинбордов. Панели будут обновляться автоматически каждые указанные в баре заголовка n-минут. Однако, делается это для всех сразу – индивидуально, вразнобой, такое настроить невозможно. Будьте внимательны: если выбрать уже прошедший интервал времени на ползунке, авто-обновление приостановится. А в принципе, если для какой-то конкретной панели именно сейчас авто-обновление не нужно, его можно приостановить для всех, если в баре заголовка установить «ON» там, где «Pause», а вернуть все обратно, соответственно, если выбрать «OFF».

Вообще же настройка этой функции производится также в «Settings», на «My Preferences» (либо прямо на панели, если кликнуть на «Modify» возле «Auto-Refresh» в баре заголовка). Далее нажимаем на «Edit» и меняем временной интервал, как нам угодно, выбрав конкретный из выпадающего меню, и сохраняем настройку «Save».

Чтобы отключить авто-обновление вообще, выбираем при редактировании «Disabled» из выпадающего меню.

Настройка таймаута пользовательского сеанса

По дефолту, таймаут пользовательского сеанса установлен на 15 минут. По желанию, эту цифру можно изменить. Для этого на странице «Settings» нажимаем на «System Configuration» (только под правами администратора) и по «User Session Timeout» кликаем на «EDIT». Двигаем ползунок, выставив то, что необходимо (от 15 минут до 24 часов). Кстати, там же можно посмотреть, кто менял последним значение таймаута, – в поле «Last Modified». И сохраняем настройку по «Submit».

Новое значение вступит в силу после перезахода в систему.

Добавление ключа Google Maps API

Чтобы получить карту вида разворота SD-WAN, нужно добавить ключ Google Maps API в vRNI. Учтите, функция доступна только членам GCP и при включенном биллинге в аккаунте, а также наличии самого ключа, естественно. При этом ограничивается ключ API, чтобы предотвратить любое злоупотребление.

На деле же, на странице «Settings» нужно кликнуть на «System Configuration», и там, где «Google Maps API Key» просто ввести API-ключ и нажать на «Save».

Настройка валидации сертификата безопасности

При добавлении источника данных, настройке LDAP/vIDM все сертификаты, с ними связанные, валидируются. И можно настроить, как именно мы хотим производить валидацию и прием сертификатов. На самом деле, это может происходить двумя путями: в автоматическом режиме или же в ручном. В обоих случаях, вначале нам нужно зайти на «Settings» – «System Configurations» и из выпадающего меню «Security Certificate Validation» выбрать один из указанных методов: «Automatic Acceptance» или «Manual Acceptance». После чего нажать на «Save».

Важно! При переключении с ручного метода на автоматический следует предварительно принять все изменения по сертификатам вручную. Если по «Data Source Certificate Validation» поменять «Manual Acceptance» на «Automatic Acceptance» без приемки всего ожидающего, придется удалять все такие источники данных и добавлять их потом снова.

Присоединение или отключение от CEIP

Если хотите изменить высказанное при инсталляции продукта относительно CEIP мнение, это можно сделать на странице «About» под «Customer Experience Improvement Program», где нужно нажать на «Modify». Выскочит соответствующее окно, где, если хотим присоединиться, ставим галочку на «Enable», а если покинуть программу – эту галочку, соответственно, нужно снять. После чего сохранить изменения «Submit».

Распространенные операции в vRNI 6.2

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

Работа с источниками данных

Источники данных, как мы уже писали в статье «Инсталляция и базовая настройка vRealize Network Insight 6.2», – краеугольный камень функционирования vRNI. И о том, где их добавлять, начиная с vCenter Server, NSX и т.д. – мы писали там же. Заведенные источники данных могут выводиться со следующей группировкой:

All (все доступные),
With Problems (только те, где обнаружены проблемы),
With Recommendations (авто-сгенерированные рекомендации для источников данных, требующие дополнительной информации),
Disabled (выключенные).

И по ним можно просматривать детали таких параметров:

Type(Nickname) – имя источника данных,
Identifier – IP-адрес или FQDN,
Last Collection – время последнего сбора данных,
Discovered VMs – кол-во обнаруженных для этого источника данных ВМ (колонка заполняется только, если источник – vCenter или AWS),
Collector VM – показывает имя коллектора, которому был добавлен источник данных,
Enabled/Disabled – включен или выключен источник данных,
Actions – опции редактирования или удаления источника данных.

Удобно, что доступен поиск источников данных по их имени, IP-адресу, имени ВМ-коллектора (строка поиска над заголовками колонок), а также фильтрация информации по разным источникам в колонке «Type(Nickname)» и фильтрация по разным ВМ-коллекторам в колонке «Collector VM».

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

Миграция источников данных на другой коллектор

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

Проходим в «Settings» – «Infrastructure and Support» – «Overview and Updates» – «Collector VMs» и нажимаем на иконку редактирования возле имени коллектора в списке;
По нужному источнику данных кликаем на «Migrate»;
Вводим запрашиваемую информацию о новом коллекторе на Edit Account или на странице Source:
1. Collector VM (имя новой ВМ-коллектора, куда будут смигрированы данные),
2. IP Address (предзаполненные IP/FQDN источника данных),
3. Username (имя пользователя для источника данных),
4. Password (пароль для источника данных);
Кликаем на «Validate», а затем на «Submit». Стартует процесс удаления источника данных на старом ВМ-коллекторе и добавление его на новый.

Как только он завершится, новая машина коллектора по этому источнику данных появится в колонке «Enabled» на странице «Accounts and Data Sources».

Важно! Если машина коллектора в дауне, покажется сообщение об ошибке.

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

Учтите, что при миграции NSX Manager на другую ВМ-коллектор, дочерние провайдеры данных, вроде NSX-контроллера и NSX Edge, также будут смигрированы на этот новый коллектор.

Удаление источника данных

Заходим в веб-консоль vRNI на «Settings» – «Accounts and Data Sources», кликаем на иконку «Delete Data Source» напротив того источника, который хотим удалить – выскочит окошко подтверждения, в котором надо будет выразить свое согласие «Yes».

Важно! Если никакой источник данных более недоступен в среде, его следует удалить из vRNI.

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

Работа с поисковыми запросами

Выше и далее – по ходу статьи – постоянно упоминаются, т.н. «поисковые запросы». Это, на самом деле, самый адекватный и быстрый способ получить всю информацию, которую способен дать vRNI, поэтому остановимся на обучении работе с ним самым подробным образом.

Как уже упоминалось, существует встроенный предопределенный список поисковых запросов в «Help» – «Useful Searches»:

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

если нажать на кнопку «Add more filters» на левой панели. В маленьком боксе рядом с категорией обозначено кол-во доступных для фильтров.

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

Еще на странице «Help» есть «Supported Properties», где можно подсмотреть список сущностей, который при раскрытии отобразит все поддерживаемые свойства, описания, примеры запросов и тэги каждой конкретной сущности. Там также можно все фильтровать по тэгам.

На виджетах есть опция «View Search Query», клик по которой отобразит ассоциированные с ним поисковые запросы. Можно копировать запрос, уже измененный и выполненный в поисковой строке. Если в виджете множество под-виджетов («Overview», к примеру), под каждый из них можно увидеть соответствующий запрос. Эта опция доступна для 6.2-версии vRNI только с информацией о NSX Manager, Flow Insights, Application, VM, Host, NSX Policy Manager, с домашней страницей, топологией NSX-T Manager и нодами NSX-T Host Transport и NSX-T Edge Transport.

Результаты поиска выводятся на страницу «Results»:

Например, на этом скриншоте показаны результаты для VLAN, с «num vms > 0», за промежуток с определенного времени в прошлом.

Важно! Поисковые запросы нечувствительны к регистру.

Важно! Типы сущностей или свойств конфигурации могут иметь синонимы. К примеру, тип «’virtual machine’» синонимичен «‘vm’», и без разницы, что из них использовать при написании запроса.

Временной контроль позволяет осуществлять поисковые запросы с контекстом выделенного времени или временного диапазона. Можно выбирать из списка пресетов, таких как 24 часа, последние 3 дня и пр. Также можно указывать конкретную дату и время, используя опцию «At», либо промежуток между датами с опцией «Between».

Написание пользовательских запросов

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

Грамотная структура запроса наглядно представлена схемой:

где:

«projection» – определяет, какие поля должны отображаться из отфильтрованных сущностей. Вводить в запрос необязательно. Без него просто будет набор полей по умолчанию, но, если дефолтное не устраивает, пишется эта часть по такому принципу. Она обязательно должна содержать либо свойство (Property, например, если впишем «os of vms», нам покажет все ВМ с «OS property» в поисковом результате. Также возможно использование метрических свойств – по оси y «y-axis» и времени – по оси x «x-axis»), либо счетчик (Count, подсчитает кол-во объектов заданного типа, например, «count of hosts»), список (List, полезно, если условие фильтрации не может быть применено к дополняемой сущности, например, «List(host) of vms where memory <= 2gb»), агрегирование (Aggregation, функции агрегации «sum», «max», «min», «avg», чтобы вычислить общее число инстансов типа конкретной сущности или максимальное ее свойство, единое значение из численного свойства «config» или «metric», пример: «sum(memory), sum(cpu cores) of vms»), серии (Series, оператор для выполнения агрегации на метрических свойствах, пример: «series(avg(cpu usage)) of vms where cpu cores = 4» – в результате будут среднее использование CPU всеми ВМ с 4 ядрами CPU):

«entity_type» – это виртуальная машина, хост, группа безопасности, VLAN, VXLAN, роутер, поток, проблема, событие, или «…»;

«filter» – выражение, которое строится по правилу «где + условие», а вот понятная шпаргалка по синтаксису условия:

«group_by» – сущности могут быть сгруппированы по свойству. По дефолту показывается кол-во результатов в каждой группе. Если добавить projection, вычислятся sum/max/min любого свойства. Добавление выражения «order by» отсортирует результат. Учтите, что и «order by», и «projection» требуют наличия функции агрегации (пример, «sum (bytes) of flows group by dest vm order by sum(bytes)»):

«order_by» – выражение «order by» помогает отсортировать результат поиска. В этом выражении позволено только одно поле. Если ничего не поставить, по дефолту отсортируется в порядке убывания. Схема написания:

пример: «vms order by cpu cores asc». Можно использовать выражение «limit» – это ограничит кол-во результатов в выводе (пример: «vms order by memory limit 5»);

Список возможных операторов, с примерами:

=	flows where source ip address = ‘10.16.240.0/24’
!=	vms where ip address != ‘10.17.0.0/16’
>	vms where memory > 4096 mb
<	vms where cpu usage rate < 70%
>=	vms where memory >= 4096 mb
<=	vms where cpu usage rate <= 70%
like	vms where name like ‘app’
not like	vms where name not like ‘app’
in	flows where port in (22, 23, 80, 443)
not in	flows where port not in (22, 23, 80, 443)
is set	vms where firewall rule is set
is not set	vms where firewall rule is not set
()	flows where (src tier = ‘App’ and destination tier = ‘DB’) OR (destination tier = ‘App’ and source tier = ‘DB’)
And	flows where src tier = ‘App’ and destinationtier = ‘DB’
Or	flows where flow type = ‘Source is VMKNIC’ or flow type = ‘Destination is VMKNIC’
Matches	vm where name matches ‘.*’
not matches	vm where name not matches ‘.*’
nested ‘in’ operator	vm where name in (name of vm where name = ‘x’)

Запрос по сущности и по пути

Любого типа сущность можно искать по ее типу («vms», «hosts», «flows», «nsx managers» и т.д.). Можно производить поиск по имени (полному или частичному), а также и по типу сущности, и по имени (например, запрос «‘vm app1’» выведет все ВМ, в имени которых встречается «app1»).

Запросы могут использоваться, и чтобы вывести демонстрацию пути между двумя ВМ или путь ВМ-интернет. Схема написания:

Примеры: «Vm ‘vm1’ to Vm ‘vm2’», «VM ‘vm1’ to Internet».

Запросы в планировании

Запросы могут использоваться в планировании безопасности дата-центра, помогая в анализе потоков. Схема написания:

Примеры: «plan securitygroup1», «plan host1», «plan security».

Сохранение и удаление поисковых запросов

Для удобства запрос можно сохранить и использовать впоследствии. Нельзя сохранять не прошедшие валидацию системой запросы. Сохраненные запросы считаются пользовательскими и доступны только их создателю, дефолтные же – всем пользователям. Также сохраненные запросы можно всегда удалить. Дефолтные сохраненные запросы касаются «All Flows», «Applications», «Azure», «Kubernetes Dashboard», «Top Trends» и «NSX». Их нельзя удалить.

Чтобы сохранить запрос, запускаем его и кликаем на иконку «закладки» рядом со строкой поиска. Его всегда можно будет потом найти в «Saved Searches» левой навигационной панели. Чтобы просмотреть все сохраненные запросы, заходим туда, а далее – в «Manage saved searches».

Чтобы удалить поисковый запрос, кликаем по нему на иконку «закладки» снова, а затем на «Delete» в подтверждающем диалоговом окне. Также можно удалять запросы напрямую из списка «Manage saved searches». Доступно пакетное удаление: здесь же выбираем сразу вместе запросы, которые подлежат удалению, и кликаем на опцию «Delete», после чего подтверждаем свое намерение.

Расширенные поисковые запросы

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

Запросы по потокам для коммуникационных шаблонов

Весь трафик по всем дата-центрам или сайтам:

sum(bytes) of flows where ( Dst Manager = ‘abc’ AND src manager = ‘cba’) OR ( Dst Manager = ‘cba’ AND src manager = ‘abc’)

Весь трафик VTEP:

sum(bytes) of flows where Flow Type = ‘Src is VTEP’ or flow type = ‘Dst is VTEP’ VTEP traffic grouped by VMKNIC

или

sum(bytes) of flows where Flow Type = ‘Src is VTEP’ or Flow Type = ‘Dst is VTEP’ group by ip

Другой управляющий трафик:

flows where Flow Type = ‘Source is VMKNIC’ or Flow Type = ‘Destination is VMKNIC’

Потоки для расширенной L2-сети:

flows where flow type = ‘Extended L2 Network’ and Destination IP Address = 10.172.13.14

Запросы по потокам для агрегации и группировки

Весь интернет-трафик по ВМ источника:

sum(bytes) of flows where Flow Type = ‘Internet’ group by src vm

Топ-порты по общему кол-ву байтов:

sum(bytes) of flow group by port order by sum(bytes)

Топ пар подсетей по записи маршрутизированного трафика:

sum(bytes) of flow where Flow Type = ‘Routed’ group by Source Subnet Network, destination subnet network order by sum(bytes)

Всего ВМ по общим парам байтов:

sum(bytes) of flows group by src vm , dest vm order by sum(bytes)

Топ серверных ВМ/портов по общему кол-ву байтов:

sum(bytes) of flows group by dest vm , port order by sum(bytes)

Запросы по потокам для оценки емкости и размера

Всего байт всего ВМ-интернет/интернет-ВМ трафика, сгруппированного по ESX (Palo Alto Service VM sizing):

sum(bytes) of flows where flow type = ‘internet’ and (flow type = ‘ src is vm ‘ OR flow type = ‘destination is vm ‘) group by host order by sum(bytes)

Агрегированные серии трафика для соответствующих потоков (Palo Alto Service VM sizing):

series( sum(byte rate)) of flows where host = ‘ddc1-pod2esx012.dm.democompany.net’ and (Flow Type = ‘Source is VM’ OR flow type = ‘Destination is VM’)

Поиски по приложениям

Виртуальные машины как данные приложения:

VM where application = ‘CRM’

Маршрутизированные потоки из данного приложения:

Flows where source application = CRM and Flow Type = ‘Routed’

Потоки между двумя тирами (односторонние):

Flows where src tier = ‘App’ and Destination Tier = ‘DB’

Потоки между двумя тирами (двусторонние):

Flows where ( src tier = ‘App’ and destination Tier = ‘DB’) OR (destination tier = ‘App’ and source tier = ‘DB’)

Запросы для ВМ и ESX

Свойства Prod -Midtier-1 VM (MAC, IP, хост и пр.):

CPU Usage Rate, Network Rate, Memory Usage Rate, mac address, ip , vxlan , host of vm ‘Quality control-VM26’

Сетевые сегменты с самым высоким счетчиком ВМ:

vm group by l2 network

Датасторы с наивысшим счетчиком ВМ:

vm group by datastore

Хосты по версии vSphere:

host group by version

Хосты по билдам vSphere:

host group by OS

Все ВМ на всех хостах/лезвиях, вставленных в конкретное шасси UCS (вложенный запрос):

vm where host in (host where Blade like ‘sys/chassis-1’)

Общая емкость

Кол-во дата-центров:

count of datacenter

Кол-во кластеров:

count of cluster

Кол-во хостов:

count of host

Кол-во ВМ:

count of vm

Кол-во сетей:

count of vlan

Запросы по маршрутам

VNI по праймари-контроллеру:

vxlan group by Primary Controller

Маршруты для провайдера edge 3:

routes where vrf = ‘Provider Edge 3’

Маршруты для DMZ DLR:

NextHop Router of routes where VRF = ‘LDR-DMZ’

Маршруты, у которых данный роутер является следующим прыжком:

routes where NextHop Router = ‘California-Edge’

Запросы по правилам файервола

Правила файервола между двумя ВМ:

firewall rules from ‘Prod-Midtier-1’ to ‘Prod-Db-1’

Правила, у которых источник «ANY»:

firewall rules where Service Any = true

ВМ с данным правилом:

vm where Firewall Rule = ‘Prod MidTier to Prod DB – DBService ‘

Правила файервола, где любой порт разрешен:

firewall rule where action = allow and service any = true

Потоки, удовлетворяющие конкретному правилу файервола:

flows where firewall rule = ‘Admin to Prod and Lab – SSH’

Разрешенные потоки в системе:

flows where firewall action = deny

Вывод файервола шлюза:

Firewall Rule where firewall type = ‘GatewayFirewall’

Вывод распределенного файервола:

Firewall Rule where firewall type = ‘Distributed Firewall’

Запросы на шаблоны общего трафика

Счетчик E-W и N-S трафика, счетчик маршрутизированного трафика, счетчик переключенного трафика, счетчик трафика ВМ-ВМ:

plan security in last 7 days

Трафик через призму безопасности

Информация по самым «общительным» ВМ:

top 7 vm group by name, Vlan order by sum(Total Network Traffic) in last 7 days

Сети, несущие наибольший трафик:

top 7 vlan group by Vlan id, vm count order by sum(Total Network Traffic) in last 7 days

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

top 7 flow where Flow Type = ‘Switched’ group by Subnet Network order by sum(Bytes) in last 7 days

Сети, где больше связей происходит через VLAN (может вызывать проблемы т.н. «бутылочного горлышка» на физическом файерволе):

top 7 flow where Flow Type = ‘Routed’ group by Source Subnet Network, Destination Subnet Network order by sum(Bytes) in last 7 days

ВМ, которые общаются вне страны:

top 7 flow where Destination Country != ‘United States’ group by Source VM, Destination Country order by sum(Bytes) in last 7 days

Хранилища данных с максимальными задержками:

avg(Read Latency), avg(Write Latency) of top 7 vm group by Datastore, vlan order by avg(Write Latency) in last 7 days

Запросы по соответствию/уязвимостям

Информация об уязвимых ОС:

vm where Operating System like ‘Microsoft Windows Server 2003’ or Operating System like ‘Microsoft Windows Server 2008’ or Operating System like ‘Red Hat Enterprise Linux 6’ or Operating System like ‘Red Hat Enterprise Linux 5’ or Operating System like ‘SUSE Linux Enterprise 10’ group by vlan, Operating System

Счетчик уязвимых ОС:

count of vm where Operating System like ‘Microsoft Windows Server 2003’ or Operating System like ‘Microsoft Windows Server 2008’ or Operating System like ‘Red Hat Enterprise Linux 6’ or Operating System like ‘Red Hat Enterprise Linux 5’ or Operating System like ‘SUSE Linux Enterprise 10’

Общая поверхность атаки из-за старых ОС:

vm where vlan in (vlan of vm where os in (‘Microsoft Windows Server 2003’, ‘Microsoft Windows Server 2008’, ‘Red Hat Enterprise Linux 6’, ‘Red Hat Enterprise Linux 5’, ‘SUSE Linux Enterprise 10’)) group by Vlan

count of vm where vlan in (vlan of vm where os in (‘Microsoft Windows Server 2003’, ‘Microsoft Windows Server 2008’, ‘Red Hat Enterprise Linux 6’, ‘Red Hat Enterprise Linux 5’, ‘SUSE Linux Enterprise 10’))

Тэги vCenter

vRNI применяет тэги vCenter в поиске и планировании. Например, можно инициировать поиск ВМ на основе тэгов vCenter и пользовательских параметров:

vm where tag = ‘{keyname}:{value}’

Каждый тэг принадлежит категории. В приведенном примере ключевое имя является категорией, которой принадлежит тэг, и значение ее является названием тэга.

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

vm “other-name-1”

vm “other-name-1″ to vm “other-name-2”

где «other-name-1» и «other-name-2» – пользовательские параметры с ключом имени или тэгами, принадлежащими категории «name».

С тэгами vCenter можно анализировать потоки в сетях:

Чтобы начать с ними работу, нужно выбрать опцию «Tag» в выпадающем списке «Analyze Flows»:

Одновременно можно выбирать до трех тэгов:

И после того, как они выбраны, просто нажимаем на «Analyze». Диаграмма при выбранном в «Group by Criteria» – «Tag» может выглядеть так:

Это прямо на нужных диаграммах. Либо же из «Security Planning» можно задать диапазон, сузив его тэгами, период и другие параметры, после чего кликнуть, аналогично на «Analize»:

Очень полезно в микро-сегментации для определения ВМ.

Бекапирование и восстановление данных

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

Конфигурация (то, что мы задавали в «Settings») – онлайн-апдейт статус, статус CEIP, интервал сохранения данных, IP-свойства и конфигурация подсетей, управление идентификацией и доступом, настройки syslog, статус Personally Identifiable Information в аудит-логах, конфигурация почтового сервера и SNMP, другие системные настройки, вроде времени истечения пользовательского сеанса, валидации сертификатов, ключа Google Maps API, User Рreferences, например, тема интерфейса, авто-обновление панелей;
Источники данных, внесенные в сетап, за исключением сборщика физических потоков (Netflow, sFlow);
Предупреждения, в том числе системные, определенные пользователем и здоровья платформы.

Также можно хранить бекапы локального хранилища (до 5 последних файлов) и загружать любые бекапы на SSH или FTP сервера.

Важно! Не бекапируются данные по потокам и информация о приложениях.

Любые ошибки процессов бекапа и восстановления отслеживаются на странице «Settings» – «Infrastructure and Support» – «Overview and Updates» – «Infrastructure» – «Overall Health section». И можно создавать алерт для сфейлившегося бекапа в «Platform Health Alerts».

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

Важно! Бекапируемая система и та, куда будут восстанавливаться данные, должны иметь одинаковые версии.

В качестве подготовки к процедуре важно помнить о необходимости взятия снэпшотов с ВМ, участвующих в процессе. А также, что только пользователь уровня Admin и Console может настраивать бекапирование и восстановление через публичные API и CLI-команды. Пользователь уровня Auditor может только увидеть, существует ли какой-то бекап и восстановление в сетапе. Инициировать бекап можно двумя путями: через CLI и через API.

Бекапирование и восстановление с помощью CLI

Этот метод потребует ввода определенных команд. Для конфигурирования бекапа:

backup-restore backup –action add –path <config-file-path>

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

backup-restore backup –action update –path config-file-path

Выбора существующей резервной копии конфигурации:

backup-restore backup –action get

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

backup-restore backup –action delete

Демонстрации статуса бекапа:

backup-restore backup –action status

Демонстрации деталей об использовании команды «backup»:

backup-restore backup –action help

А по восстановлению, соответственно, все те же действия, но с таким синтаксисом, по порядку:

backup-restore restore –action add –path config-file-pathbackup-restore restore –action getbackup-restore restore –action deletebackup-restore restore –action statusbackup-restore restore –action helpВсе описанное требует захода на одну из нод платформы под «/home/ubuntu».

Бекапирование и восстановление через API

Все API-вызовы, касающиеся бекапирования и восстановления в vRNI можно подсмотреть здесь в секциях «settings/backup» и «settings/restore», соответственно. С описаниями, примерами ответов и другой полезной информацией. Приводить тут все это нет смысла – табличка весьма наглядна и всегда доступна для общего пользования. Единственное важное замечание: любая предоставляемая конфигурация должна представлять собой тело JSON в запросе.

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

Создание файла бекапа на локальном файловом сервере в дефолтной директории «/var/lib/backup-restore» или любой указанной пользователем:

{“backup_file_server_type” :

“LOCAL”}

или

{“backup_file_server_type”: “LOCAL”,

“local_file_server”:

{

“backup_directory”: “backup_directory_path”

}

Создание бекапа на FTP-сервере в указанной пользователем директории:

{

“backup_file_server_type”: “FTP”,

“ftp_file_server”:

{

“server_address”: “IP address”,

“port”: port_number,

“username”: “username”,

“password”: “password”,

“backup_directory”: “backup_directory_path”

}

Создание бекапа на SSH-сервере в указанной пользователем директории:

“backup_file_server_type”: “SSH”,

“ssh_file_server”:

{

“server_address”: “IP address”,

“port”: port_number,

“username”: “username”,

“password”: “password”,

“backup_directory”: “backup_directory_path”

}

Немедленная инициация бекапа:

“schedule_now”: true

Задание бекапа по расписанию – ежедневно (разрешенное значение для «hour» – 0-23, для «minute» – 0-59):

“backup_schedule”:

{

“schedule_period”: “DAILY”,

“hour”: 16,

“minute”: 51

}

Задание бекапа по расписанию – еженедельно (разрешенное значение для «hour» – 0-23, для «minute» – 0-59, для «day_of_week» – 1 (воскресенье) – 7 (суббота)):

“backup_schedule”:

{

“schedule_period”: “WEEKLY”,

“hour”: 16,

“minute”: 56,

“day_of_week”: 3

}

Бекапирование только нескольких конфигураций – по тем, которые нужны, под «data_filter» выставляем «true», по тем, которые пропускаются – «false» (если не указать параметр «data_filter», сохранятся все):

“data_filter”:

{

“snmp”: true,

“smtp”: true,

“data_sources”: false,

“events”: false,

“syslog”: true,

“ldap”: true,

“vidm”: true,

“user_data”: true,

“physical_subnet_vlan”: true,

“physical_ip_dns_mapping”: true,

“system_configuration”: true,

“east_west_ip”: false,

“north_south_ip”: true,

“data_management”: true,

“online_update_status”: true,

“ceip_status”: true,

“audit_logs_pii_status”: false

}

Восстановление с локального файлового сервера:

{

“backup_file_server_type”: “LOCAL”,

“local_file_server”:

{

“backup_directory”: “backup_directory_path”,

“backup_file_name”: “file_name.tar”

}

Восстановление с FTP-файлового сервера:

{

“backup_file_server_type”: “FTP”,

“ftp_file_server”:

{

“server_address”: “IP address”,

“port”: port_number,

“username”: “username”,

“password”: “password”,

“backup_directory”: “backup_directory_path”

“backup_file_name”: “file_name.tar”

}

Восстановление с SSH-файлового сервера:

“backup_file_server_type”: “SSH”,

“ssh_file_server”:

{

“server_address”: “IP address”,

“port”: port_number,

“username”: “username”,

“password”: “password”,

“backup_directory”: “backup_directory_path”

“backup_file_name”: “file_name.tar”

}

Восстановление только нескольких конфигураций. Под параметром «data_filter» по нужным конфигурациям выставляем «true», по ненужным – «false» (если параметр не указать вообще, восстановится абсолютно все, что было сбекапировано):

“data_filter”:

{

“snmp”: true,

“smtp”: true,

“data_sources”: false,

“events”: false,

“syslog”: true,

“ldap”: true,

“vidm”: true,

“user_data”: true,

“physical_subnet_vlan”: true,

“physical_ip_dns_mapping”: true,

“system_configuration”: true,

“east_west_ip”: false,

“north_south_ip”: true,

“data_management”: true,

“online_update_status”: true,

“ceip_status”: true,

“audit_logs_pii_status”: false

}

В завершение еще одно важное замечание. Если не указать параметр «collector_mapping», все восстановленные источники данных будут сопоставлены с рандомным коллектором на восстановленном сетапе. Пример его введения:

“collector_mapping”: {

“default_collector”: “default_collector_ip”,

“mappings”: [

{

“source”: “source_collector_ip”,

“destination”: “destination_collector_ip”

}

]

}

Создание и расширение кластеров

В статье «Инсталляция и базовая настройка vRealize Network Insight 6.2» мы слегка касались темы организации кластеров платформ и упоминали, что для процедуры нужны еще, минимум, две платформы, развернутые и включенные, а делается все – на странице «Settings» – «Infrastructure and Support» – «Overview and Updates».

Важно! Перед любой операцией по созданию или расширению кластеров обязательно следует сделать бэкап ВМ-платформы.

Важно! Все втаскиваемые в кластер ноды должны быть доступны по SSH.

Далее нам просто нужно кликнуть на «CREATE CLUSTER» для «Platform VMs»:

и на открывшейся странице «Create Cluster» заполнить следующие поля: «IP Address», вписав адрес новой платформы, которую хотим добавить, и пароль в «Password» – саппорт-пользователя. Каждую следующую платформу добавляем аналогичным образом после нажатия на «Add more», а по окончанию стартуем создание кластера кнопкой «SUBMIT» и нажав в подтверждающем окне на «Yes».

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

Важно! Функция кластеризации доступна исключительно для large-размера бриков. Причем, все платформы должны быть именно такого типа.

Важно! Если включаем телеметрию на одной ноде из кластера – она включится и на всех остальных.

Часто, уже созданный и успешно работающий кластер постепенно начинает не успевать за всеми предъявляемыми к нему требованиями. И тогда, по понятным причинам, появляется желание его расширить. Для этого вовсе не нужно расформировывать его и создавать новый с большим кол-вом нод – достаточно просто воспользоваться встроенной в продукт функцией расширения. Кстати, делать это можно только с первой – ведущей ноды. Вначале заходим на страницу «Overview and Updates» и кликаем на «EXPAND CLUSTER» для «Platform VMs». Вписываем, как и при начальной инициации, IP-адрес каждой дополнительной ноды и пароль под нее, и сохраняемся по «SUBMIT». Какое-то время будет отображаться пошаговый прогресс расширения, а по его завершению о том вылетит специальное сообщение.

Важно! Текущая версия vRNI поддерживает не более 10 нод в одном кластере. По достижению этого кол-ва кнопка «Add more» в интерфейсе перестанет быть активной.

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

Заходим на «Settings» – «Overview and Updates» – «Platform Capacity» – «Check capacity of Devices» и проверяем емкость для устройств:

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

Заходим по SSH под саппорт-пользователем на первую платформу (все выполняется только с нее) и меняем пользователя на «ubuntu»:

sudo su Ubuntu

Запускаем команду:

– python3 /home/ubuntu/build-target/deploymentmanager/change_deployment_config.py

– стартует интерактивная программа с такими опциями:

Ввод def ID для разворота к применению;
Вывод списка def для текущей конфигурации;
Вывод списка def для другой конфигурации;
Выход;

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

Получаем ID конфигурации, доступной для применения, применяем ее и ждем завершения операции (Option 1) 5-10 минут.

Логи описанной процедуры всегда можно посмотреть в файле «/home/ubuntu/logs/deployment_change.log».

Емкость загрузки коллектора и платформы

Поинформированность о состоянии емкости загрузки коллектора и платформы – залог достижения оптимальной производительности и предотвращения ошибок в будущем. Емкость в этой теме бывает двух видов: емкость ВМ («VM Capacity» – кол-во обнаруженных ВМ, обслуживающих ноду или сетап в целом) и емкость потока («Flow Capacity» – кол-во потоков, которые удерживает нода или весь сетап). Просмотреть информацию по ним можно на странице «Settings» – «Infrastructure and Support» – «Overview and Updates». Там, кстати, можно увидеть и специальный раздел «Platform Capacity», где отражается информация о ВМ, активных потоках, всех потоках и устройствах.

Важно! Как только кол-во обнаруженных ВМ на источниках данных по всему развороту достигнет лимита емкости всей системы, в целом, или отдельного коллектора (или и того, и другого сразу), апгрейд сделать будет нельзя.

Также полезна в этом плане и страница «Accounts and Data Sources», где показывается количество обнаруженных ВМ для конкретного источника данных, который добавлен и сейчас является активным. Соответствующая колонка, правда, показывает цифру только в том случае, когда источник данных – это vCenter или источник AWS.

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

В vRNI встроена очень дружественная и удобная система обнаружения и решения связанных с емкостью платформы проблем – прямо в сообщении об ошибке будет кнопка или ссылка, воспользовавшись которыми можно все исправить. Например, если поменялась лицензия или размер брика в сетапе и выдало ошибку «Capacity configuration is mismatched», там можно просто кликнуть на «RECONFIGURE». Если использование системы превысило установленную емкость платформы с сообщением «System usage has breached the capacity», надо нажать на кнопку «RECONFIGURE», если она присутствует, если же ее нет – добавить ресурсов, увеличив размер брика, создать кластер (если его еще нет) или расширив уже существующий (см. предыдущий подраздел). Если же мы видим сообщение «Capacity reconfiguration failed», лучше сразу обращаться в саппорт, так как причины могут быть чисто технические и не всегда решаемые на стороне пользователя.

Управление утилизацией диска

Высокая утилизация диска – причина для создания предупреждающего сообщения пользователю на панели платформы или коллектора, ведь для системы в целом и нормальной работы продукта подобная ситуация, конечно же, хорошего несет мало. В таком сообщении, что удобно, будут рекомендации по тому, сколько еще дискового пространства стоит добавить. Также оно продублируется в соответствующей секции проблемной платформы или коллектора на странице «Infrastructure and Support» – «Overview and Updates»:

Важно! Существующий хард-диск увеличивать нельзя.

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

Заходим в vCenter через веб-клиент под соответствующими привилегиями;
Кликаем правой кнопкой на ноду и нажимаем «Edit settings»;
Добавляем жесткий диск в соответствии с рекомендациями из предупреждения.

Буквально через несколько минут vRNI обнаружит приложение и добавит его в партицию «/var».

Работа с потоками в vRNI

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

Включение конфигурации IPFIX

IPFIX, как известно, это IETF-протокол для экспортирования потока информации. На VDS и DVPG схему его работы наглядно описывает диаграмма:

В vSphere VDS можно настроить для экспорта потоковой информации с использованием IPFIX. Мониторинг потока должен быть включен на всех портах прикрепленной к VDS группы. Чтобы проанализировать всю полноту информации по каждому сеансу требуется IPFIX данных о пакетах в обоих направлениях. Как мы видим из показанной схемы, VM-A подключен к DVPG-A и общается с VM-C, и DVPG-A лишь предоставляет данные о C→A-пакетах, тогда как DVPG-Uplink предоставляет данные о пакетах A→C. Чтобы получить полную информацию о трафике на А, IPFIX нужно включить и на DVPG-A, и на DVPG-uplink.

vRNI обладает встроенным коллектором/получателем для потоковой информации IPFIX. Ее сбор можно включить в настройках источника данных vCenter на различных уровнях. Чтобы это сделать, при добавлении vCenter в vRNI ставим галочку в «Enable NetFlow (IPFIX) on this vCenter» – покажется список доступных VDS, в котором нужно выбрать тот, на котором хотим включить IPFIX:

Важно! Если версия ESXi хоста не поддерживается, появится иконка предупреждения для VDS. Если IPFIX уже настраивался когда-либо для VDS с другим IP-адресом, выпадающем из сферы влияния ВМ-коллектора vRNI, появится кнопка «Override». Ее нужно просто нажать, чтобы увидеть список DVPG под этим VDS.

По дефолту, по выбранному VDS все DVPG из списка будут выбраны. Но, можно включить «Manual Selection», чтобы самим определить, на каких DVPG хотим включить IPFIX. После их отметки кликаем на «Submit».

Также мы можем включить IPFIX на NSX. Штука очень полезная, так как дает отличный обзор того, что происходит в виртуальной оверлейной сети. Отчет VXLAN IPFIX использует включенный на аплинке хоста Netflow, показывая, что происходит на инкапсулирующем пакет VTEP, а также информацию о ВМ, сгенерировавшей внутренний трафик на хосте на NSX Logical Switch (VXLAN). Интересно, что распределенный файервол применяет stateful-слежение за потоками. И как только они проходят через набор изменений состояния, IPFIX начинает экспортировать данные о статусе этого потока.

Отслеживаемые предупреждения включают процедуры создания потока, его отклонения и его разрушения. Отклоненные алерты экспортируются как syslog. Чтобы воспользоваться этим функционалом нужно включить IPFIX на NSX. Рассмотрим, как это делается в NSX-Т (NSX-V весьма скоро дойдет до статуса «end-of-life», так что говорить о нем в ракурсе такого современного продукта, как vRNI, смысла нет).

Прежде всего, нам нужно зайти под правами enterprise_admin/network_engineer/security_engineer, убедиться, что включен DFW и приоритетный 0 доступен для профиля IPFIX. Если уже существует другой профиль IPFIX с нулевым приоритетом, нужно поменять его на любое другое значение. Далее нужно просто поставить галочку на «Enable IPFIX», когда добавляется новый источник данных NSX-T Manager, либо же отредактировать таким образом старый. vRNI создаст свой собственный профиль коллектора и профиль IPFIX на NSX-T, которые менять нельзя ни в коем случае, а потоки станут видны для мониторинга.

Если этого не произошло, проблема может быть в отсутствии регистрации профиля коллектора/IPFIX в NSX-T Manager, изменении номера порта профиля IPFIX, несоответствии этих профилей – эти казусы убираются банальным повторным включением NSX-T IPFIX. Также причина может быть в ненулевой приоритетности профиля IPFIX (переустановить на 0), выключенном DFW в NSX-T Manager (включить). Если же все идет как надо, все логические свитчи NSX-T добавятся в профиль IPFIX в течение 10-15 минут.

Поддержка потоков для физических серверов

vRNI поддерживает устройства, посылающие данные NetFlow версий v5/v7/v9. Для процесса требуется предоставление информации о сопоставлении DNS и Subnet-VLAN – решение дополняет данные NetFlow через DNS-домены, имена хостов DNS, подсети и L2-сети. Функция доступна только на Enterprise-лицензии. Чтобы настроить NetFlow в vRNI нужно проделать следующее:

Добавить коллектор физического потока для NetFlow и sFlow. Для этого на странице «Settings» заходим на «Accounts and Data Sources» и кликаем на «Add Source». Под «Flows» нажимаем на «Physical Flow Collector (Netflow, sFlow)» и заполняем поля «Nickname» и «Notes», после чего сохраняемся по «Submit»;

Важно! Для Cisco ASR/ISR (SD-WAN Assessment), если в среде уже есть существующий источник данных, нужно добавить отдельный коллектор. Если источник Cisco ASR/ISR (SD-WAN Assessment) – единственный, в этом нет необходимости.

Настроить коллектор NetFlow на физических устройствах для получения потоков вручную. В большинстве случаев требуется:
1. Создать запись потока, обозначив поля «ipv4 protocol», «ipv4 source address», «ipv4 destination address», «transport source-port», «transport destination-port», «interface input» как «Match», поля «direction», «counter bytes», «counter packets», «timestamp sys-uptime first», «timestamp sys-uptime last» – как «Collect», а поле «transport tcp flags» – как «Match» или «Collect», либо же просто пропускаем последнее;
2. Создать экспортер потока (предоставив vRNI IP коллектора NetFlow и порт 2055);
3. Настроить кэш потока с активным таймаутом в 30 сек, и неактивным – в 60 сек;
4. Создать монитор потока через созданную запись потока и его экспортера;
5. Настроить монитор в каждом интерфейсе;

Конкретные примеры по видам устройств:

Для Cisco 4500:

configure terminal

flow record netflow-original

match ipv4 protocol

match ipv4 source address

match ipv4 destination address

match transport source-port

match transport destination-port

match interface input

collect transport tcp flags

collect counter bytes

collect counter packets

collect timestamp sys-uptime first

collect timestamp sys-uptime last

End

configure terminal

flow exporter e1

destination <PROXY_IP>

transport udp 2055

end

configure terminal

flow monitor m1

record netflow-original

exporter e1

end

configure terminal

cache timeout inactive 30

cache timeout active 60

end

configure terminal

interface <INTERFACE_NAME>

ip flow monitor m1 unicast input

end

Для Cisco Nexus 1000v:

configure terminal

Active timeout 60

Inactive timeout 15

End

configure terminal

flow exporter <EXPORTER_NAME>

destination <PROXY_IP>

transport udp 2055

source <VSM_IP_OR_SUBNET>

end

configure terminal

flow monitor <MONITOR_NAME>

record netflow-original

exporter <EXPORTER_NAME>

end

configure terminal

port-profile type vethernet <IF_NAME>

ip flow monitor <MONITOR_NAME> input

ip flow monitor <MONITOR_NAME> output

End

Для Cisco Nexus 9000:

configure terminal

feature netflow

end

configure terminal

flow record vrni-record

match ipv4 protocol

match ipv4 source address

match ipv4 destination address

match transport source-port

match transport destination-port

match interface input

collect transport tcp flags

collect counter bytes

collect counter packets

collect timestamp sys-uptime first

collect timestamp sys-uptime last

End

configure terminal

flow exporter vrni-exporter

destination <PROXY_IP>

transport udp 2055

version 9

source <INTERFACE_NAME>

end

configure terminal

flow monitor vrni-monitor

record vrni-record

exporter vrni-exporter

end

configure terminal

cache timeout inactive 30

cache timeout active 60

end

configure terminal

interface <INTERFACE_NAME>

ip flow monitor vrni-monitor input

end

Импортировать DNS-сопоставление. См. выше в подразделе «Настройка IP-свойств и подсетей» главы «Об UI vRNI»;
Настроить физические подсети и VLAN. См. там же.

Дополнение потоков и конечных точек, и поиск потоков от физики к физике

Как мы уже писали, информацию о DNS-сопоставлении и сопоставлении подсеть-VLAN можно получить через наш UI. Информация о потоке дополняется следующими типами информации на основе импорта данных DNS и спецификации сопоставления подсеть-VLAN:

DNS домена источника/назначения,
имя хоста DNS источника/назначения,
L2-сеть источника/назначения,
сеть подсети источника/назначения.

Информация о IP конечной точки дополняется такими типами информации, как:

DNS домена,
имя хоста DNS,
FQDN,
L2-сеть,
сеть подсети.

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

bytes,Dns Domain,Dns Host,l2 network of flows where flow type = ‘Physical-Physical’

bytes,Dns Domain,Dns Host,l2 network of flows where flow type = ‘Source is VM’ and flow type = ‘Destination is Physical’

bytes,Dns Domain,Dns Host,l2 network of flows where flow type = ‘Source is Internet’ and flow type = ‘Destination is Physical’

Просмотр заблокированных и защищенных потоков

Интеграция NSX-IPFIX позволяет получить информацию о заблокированных и защищенных потоках в системе. При этом основные фильтры на странице «Micro-Segmentation Planning» выглядят так:

Все разрешенные потоки («All Allowed Flows») – включена по дефолту, показывает потоки, для которых действие в правиле файервола установлено на «Allowed»;
Сброшенные потоки («Dropped Flows»);
Все защищенные потоки («All Protected Flows») – потоки с правилом, отличным от типа «any(source)», «any(dest)», «any(service)», «allow», с ним ассоциированным;
Все незащищенные потоки («All Unprotected Flows») – потоки с дефолтным правилом «any(source)», «any(dest)», «any(service)», «allow».

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

На странице «Micro-Segmentation Planning» по интересующей группе выбираем «All Allowed Flows» из выпадающего меню;
Кликаем на сброшенные потоки в диаграмме топологии, чтобы увидеть соответствующие рекомендованные правила файерволлинга;
Применяем эти правила путем экспортирования их в NSX Manager:

NAT

vRNI поддерживает SNAT, DNAT, рефлексивные правила в потоках и пути ВМ-ВМ для NSX-V, NSX-T Edge, Fortinet и Check Point. Потоки NAT поддерживаются в vRNI в таком разрезе:

Как вложенная NAT-иерархия для NSX для vSphere и NSX-T, а также для физических устройств (для Fortinet – только одиночная иерархия DNAT);
Edge и многоуровневые маршрутизаторы с определяемыми NAT восходящими каналами (NSX Edge 5.5 и более старые не поддерживаются);
Поддерживаются SNAT-правила в этом диапазоне. Однако, DNAT должны быть однозначным сопоставлением между транслируемым IP-адресом и IP-адресом назначения;
Для Check Point NAT правила, сгенерированные автоматически или вручную как для источника, так и для назначения, в качестве сети, сети-группы или адреса-диапазона.

Чтобы просмотреть правила NAT нужно использовать следующие запросы:

В NSX-T – «NSX-T Edge NAT Rule»,
В NSX-V – «Edge NAT Rules»,
В Fortinet – «Fortinet NAT Rule»,
В Check Point – «Check Point NAT Rule»,
Все – «NAT Rule».

Несколько важных моментов. В NSX-T правила NAT могут применяться на сервисном уровне. Любая трансляция на уровне портов не поддерживается, как и соответствующие адреса назначения SNAT и исходные адреса совпадения DNAT. Файервол NSX-T Edge влияет на путь данных, если он включен со службой NAT на том же логическом маршрутизаторе. Если поток соответствует как NAT, так и файерволу Edge, результат поиска NAT имеет приоритет над файерволом, и в результате к такому потоку файервол не применяется. Кроме того, вообще не поддерживается трансляция сервисов, как и vSEC NAT.

Потоки VMware Cloud на AWS

Если мы включили IPFIX на источнике данных на странице «Settings», мы можем видеть счетчик потоков и последнее время сбора данных. А также осуществлять поиск по конкретному потоку и получать информацию, ассоциированную с сущностями. Например, в «Source L2 Network» и «Source Security Group» нам покажут политику сегмента и информацию о политике группы, соответственно. И, конечно же, все прикрепленные к потоку правила политики файервола. vRNI поддерживает гибридные потоки через VPN. Информация о таких потоках дополняется сущностями источника и назначения:

Однако, будьте аккуратны: если вы предварительно грейдили VMware Cloud на AWS с версии 1.8 на 1.9, в UI потоки могут демонстрироваться задвоенными.

Создание логов VPC-потоков

Логи потоков Virtual Private Cloud (VPC) позволяют захватывать информацию о проходящем туда-обратно через сетевые интерфейсы в VPC IP-трафике. Эти логи потоков можно создать через портал AWS, зайдя в консоль:

В текстовом поле «Find Service» вводим «CloudWatch»;
Заходим в «Logs» – «Action» – «Create log group» – появится соответствующее окно;
В поле «Create Group Name» вписываем имя группы и кликаем на «Create log group»;
В верхней навигационной панели кликаем на «Service» и затем вводим «VPC»;
На странице «VPC Dashboard» жмем на «Your VPCs», выбираем нужный VPC и кликаем на «Flow Logs» – «Create flow log»;
В появившемся окне настраиваем наш журнал, в «Filter» выбрав «Accept/Reject/All», в «Destination» – «Send to CloudWatch Logs» и в «Destination log group» – ту группу, которую создали в п. 2 – 3 выше;
Кликаем на «Set Up Permissions», после чего откроется страница «VPC Flow Logs is requesting permission to use resources in your account»;
Создаем здесь IAM-роль, в «IAM Role» выбрав «Create a new IAM Role», и введя имя роли в текстовом поле «Role Name», после чего нажимаем на «Allow»;
На странице «Create flow log» в выпадающем меню «IAM role» выбираем только что созданную роль, и финально кликаем на «Create».

В результате лог потока начнет публиковать данные в выбранную группу логов. Больше почитать об этом можно здесь.

Отсылка записей потоков с F5 на коллекторы vRNI

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

Создать пул IPFIX-коллекторов для получения сообщений логов из BIG-IP-системы. Для этого заходим в F5-консоль, кликаем на «Main» – «Local Traffic» – «Pools» – «Pool Lists» – «Create», и в экране «New Pool» вписываем уникальное имя для пула в «Name», в «Health Monitors» выбираем «gateway_icmp» и перемещаем его в бокс «Active». В секции «New Member» настраиваем IP-адрес коллектора («Node Name» – его айпишник, «Service Port» – 2055), кликаем на «Add» и финально – на «Finished»;
Создать место назначения лога форматирования журналов в шаблонах IPFIX. Для этого в F5-консоли нажимаем на «Main» – «System» – «Logs» – «Configuration» – «Log Destinations» – «Create», и в появившемся экране «Log Destinations» в текстовом поле «Name» вводим уникальное имя, в списке «Type» кликаем на «IPFIX» и настраиваем его параметры: в «Protocol» выбираем «Netflow V9», а в «Pool Name» – то, что только создали в п. 1. «Finished»;
Создать издателя лога для отправки журналов в указанные места назначения. Для этого в той же консоли кликаем на «Main» – «System» – «Logs» – «Configuration» – «Log Publishers» – «Create» и в экране «Log Publishers» заполняем поля «Name», в «Destination» из бокса «Available» выбираем место назначения, которое создали в предыдущем пункте, перемещаем его в бокс «Selected». «Finished»;
Создать iRule для посылки информации о потоке на настроенный коллектор vRNI. С этой целью в той же консоли нажимаем на «Main» – «iRules» – «iRule List» – «Create» и в экране «New iRule» вписываем имя в «Name» в боксе «Definition» вводим TCP-правила для TCP-протокола и UDP-правило для соответствующего протокола. Для TCP-правила вписываем такое:

when RULE_INIT {

set static::http_rule1_dest “”

set static::http_rule1_tmplt “”

}

# CLIENT_ACCEPTED event to initiate IPFIX destination and template

when CLIENT_ACCEPTED {

set start [clock clicks -milliseconds]

if { $static::http_rule1_dest == “”} {

# open the logging destination if it has not been opened yet

set static::http_rule1_dest [IPFIX::destination open -publisher /Common/<Log Publisher>]

}

if { $static::http_rule1_tmplt == “”} {

# if the template has not been created yet, create the template

set static::http_rule1_tmplt [IPFIX::template create “flowStartMilliseconds \

sourceIPv4Address \ sourceIPv6Address \ destinationIPv4Address \ destinationIPv6Address \ sourceTransportPort \ destinationTransportPort \ protocolIdentifier \ octetTotalCount \ packetTotalCount \ octetDeltaCount \ packetDeltaCount \ postNATSourceIPv4Address \ postNATSourceIPv6Address \ postNATDestinationIPv4Address \ postNATDestinationIPv6Address \ postNAPTSourceTransportPort \ postNAPTDestinationTransportPort \ postOctetTotalCount \ postPacketTotalCount \ postOctetDeltaCount \ postPacketDeltaCount \ flowEndMilliseconds \ “]

}

set rule1_msg1 [IPFIX::msg create $static::http_rule1_tmplt]

}

# SERVER_CONNECTED event to initiate flow data to Tetration and populate 5 tuples

when SERVER_CONNECTED {

set client_closed_flag 0

set server_closed_flag 0

IPFIX::msg set $rule1_msg1 flowStartMilliseconds $start

IPFIX::msg set $rule1_msg1 protocolIdentifier [IP::protocol]

# Clientside

if { [clientside {IP::version}] equals “4” } {

# Client IPv4 address

IPFIX::msg set $rule1_msg1 sourceIPv4Address [IP::client_addr]

# BIG-IP IPv4 VIP address

IPFIX::msg set $rule1_msg1 destinationIPv4Address [clientside {IP::local_addr}]

} else {

# Client IPv6 address

IPFIX::msg set $rule1_msg1 sourceIPv6Address [IP::client_addr]

# BIG-IP IPv6 VIP address

IPFIX::msg set $rule1_msg1 destinationIPv6Address [clientside {IP::local_addr}]

}

# Client port

IPFIX::msg set $rule1_msg1 sourceTransportPort [TCP::client_port]

# BIG-IP VIP port

IPFIX::msg set $rule1_msg1 destinationTransportPort [clientside {TCP::local_port}]

# Serverside

if { [serverside {IP::version}] equals “4” } {

# BIG-IP IPv4 self IP address

IPFIX::msg set $rule1_msg1 postNATSourceIPv4Address [IP::local_addr]

# Server IPv4 IP address

IPFIX::msg set $rule1_msg1 postNATDestinationIPv4Address [IP::server_addr]

} else {

# BIG-IP IPv6 self IP address

IPFIX::msg set $rule1_msg1 postNATSourceIPv6Address [IP::local_addr]

# Server IPv6 IP address

IPFIX::msg set $rule1_msg1 postNATDestinationIPv6Address [IP::server_addr]

}

# BIG-IP self IP port

IPFIX::msg set $rule1_msg1 postNAPTSourceTransportPort [TCP::local_port]

# Server port

IPFIX::msg set $rule1_msg1 postNAPTDestinationTransportPort [TCP::server_port]

}

# SERVER_CLOSED event to collect IP pkts and bytes count on serverside

when SERVER_CLOSED {

set server_closed_flag 1

# when flow is completed, BIG-IP to server REQUEST pkts and bytes count

IPFIX::msg set $rule1_msg1 octetTotalCount [IP::stats bytes out]

IPFIX::msg set $rule1_msg1 packetTotalCount [IP::stats pkts out]

# when flow is completed, server to BIG-IP RESPONSE pkts and bytes count

IPFIX::msg set $rule1_msg1 octetDeltaCount [IP::stats bytes in]

IPFIX::msg set $rule1_msg1 packetDeltaCount [IP::stats pkts in]

IPFIX::destination send $static::http_rule1_dest $rule1_msg1

}

# CLIENT_CLOSED event to collect IP pkts and bytes count on clientside

when CLIENT_CLOSED {

set client_closed_flag 1

# when flow is completed, client to BIG-IP REQUEST pkts and bytes octetDeltaCount

IPFIX::msg set $rule1_msg1 postOctetTotalCount [IP::stats bytes in]

IPFIX::msg set $rule1_msg1 postPacketTotalCount [IP::stats pkts in]

# when flow is completed, BIG-IP to client RESPONSE pkts and bytes count

IPFIX::msg set $rule1_msg1 postOctetDeltaCount [IP::stats bytes out]

IPFIX::msg set $rule1_msg1 postPacketDeltaCount [IP::stats pkts out]

# record the client closed time in ms

IPFIX::msg set $rule1_msg1 flowEndMilliseconds [clock click -milliseconds]

# send the IPFIX log

IPFIX::destination send $static::http_rule1_dest $rule1_msg1

}

а для UDP:

when RULE_INIT {

set static::http_rule1_dest “”

set static::http_rule1_tmplt “”

}

# CLIENT_ACCEPTED event to initiate IPFIX destination and template

when CLIENT_ACCEPTED {

set start [clock clicks -milliseconds]

if { $static::http_rule1_dest == “”} {

# open the logging destination if it has not been opened yet

set static::http_rule1_dest [IPFIX::destination open -publisher /Common/<Log Publisher>]

}

if { $static::http_rule1_tmplt == “”} {

# if the template has not been created yet, create the template

set static::http_rule1_tmplt [IPFIX::template create “flowStartMilliseconds \

sourceIPv4Address \

sourceIPv6Address \ destinationIPv4Address \ destinationIPv6Address \ sourceTransportPort \ destinationTransportPort \ protocolIdentifier \ octetTotalCount \ packetTotalCount \ octetDeltaCount \ packetDeltaCount \ postNATSourceIPv4Address \ postNATSourceIPv6Address \ postNATDestinationIPv4Address \ postNATDestinationIPv6Address \ postNAPTSourceTransportPort \ postNAPTDestinationTransportPort \ postOctetTotalCount \ postPacketTotalCount \ postOctetDeltaCount \ postPacketDeltaCount \ flowEndMilliseconds \ “]

}

set rule1_msg1 [IPFIX::msg create $static::http_rule1_tmplt]

}

# SERVER_CONNECTED event to initiate flow data to Tetration and populate 5 tuples

when SERVER_CONNECTED {

set client_closed_flag 0

set server_closed_flag 0

IPFIX::msg set $rule1_msg1 flowStartMilliseconds $start

IPFIX::msg set $rule1_msg1 protocolIdentifier [IP::protocol]

# Clientside

if { [clientside {IP::version}] equals “4” } {

# Client IPv4 address

IPFIX::msg set $rule1_msg1 sourceIPv4Address [IP::client_addr]

# BIG-IP IPv4 VIP address

IPFIX::msg set $rule1_msg1 destinationIPv4Address [clientside {IP::local_addr}]

} else {

# Client IPv6 address

IPFIX::msg set $rule1_msg1 sourceIPv6Address [IP::client_addr]

# BIG-IP IPv6 VIP address

IPFIX::msg set $rule1_msg1 destinationIPv6Address [clientside {IP::local_addr}]

}

# Client port

IPFIX::msg set $rule1_msg1 sourceTransportPort [TCP::client_port]

# BIG-IP VIP port IPFIX::msg set $rule1_msg1 destinationTransportPort [clientside {TCP::local_port}]

# Serverside

if { [serverside {IP::version}] equals “4” } {

# BIG-IP IPv4 self IP address

IPFIX::msg set $rule1_msg1 postNATSourceIPv4Address [IP::local_addr]

# Server IPv4 IP address

IPFIX::msg set $rule1_msg1 postNATDestinationIPv4Address [IP::server_addr]

} else {

# BIG-IP IPv6 self IP address

IPFIX::msg set $rule1_msg1 postNATSourceIPv6Address [IP::local_addr]

# Server IPv6 IP address

IPFIX::msg set $rule1_msg1 postNATDestinationIPv6Address [IP::server_addr]

}

# BIG-IP self IP port

IPFIX::msg set $rule1_msg1 postNAPTSourceTransportPort [TCP::local_port]

# Server port

IPFIX::msg set $rule1_msg1 postNAPTDestinationTransportPort [TCP::server_port]

}

# SERVER_CLOSED event to collect IP pkts and bytes count on serverside

when SERVER_CLOSED {

set server_closed_flag 1

# when flow is completed, BIG-IP to server REQUEST pkts and bytes count

IPFIX::msg set $rule1_msg1 octetTotalCount [IP::stats bytes out]

IPFIX::msg set $rule1_msg1 packetTotalCount [IP::stats pkts out]

# when flow is completed, server to BIG-IP RESPONSE pkts and bytes count

IPFIX::msg set $rule1_msg1 octetDeltaCount [IP::stats bytes in]

IPFIX::msg set $rule1_msg1 packetDeltaCount [IP::stats pkts in]

IPFIX::destination send $static::http_rule1_dest $rule1_msg1

}

# CLIENT_CLOSED event to collect IP pkts and bytes count on clientside

when CLIENT_CLOSED {

set client_closed_flag 1

# when flow is completed, client to BIG-IP REQUEST pkts and bytes octetDeltaCount

IPFIX::msg set $rule1_msg1 postOctetTotalCount [IP::stats bytes in]

IPFIX::msg set $rule1_msg1 postPacketTotalCount [IP::stats pkts in]

# when flow is completed, BIG-IP to client RESPONSE pkts and bytes count

IPFIX::msg set $rule1_msg1 postOctetDeltaCount [IP::stats bytes out]

IPFIX::msg set $rule1_msg1 postPacketDeltaCount [IP::stats pkts out]

# record the client closed time in ms

IPFIX::msg set $rule1_msg1 flowEndMilliseconds [clock click -milliseconds]

# send the IPFIX log

IPFIX::destination send $static::http_rule1_dest $rule1_msg1

}

«Finished»;

Важно! iRule должно обязательно указывать на ранее созданного издателя логов.

Добавить iRule на виртуальный сервер конфигурации, чтобы оно парсило весь существующий виртуальный серверный сетевой трафик. Для этого там же, в F5-консоли, кликаем на «Main» – «Virtual Server» – «Virtual Server List» и в появившемся окне «Virtual Server List» выбираем сервер, которому хотим добавить только что созданное нами iRule, заходим на вкладку «Resources» и в секции «iRule» жмем на «Manage». Выбираем только что нами заведенные iRule (TCP и UDP) и перемещаем их из бокса «Available» в «Enable». «Finished».

Если ВМ-коллектора недоступна с F5, следует создать запись маршрута для нее, чтобы посылать записи потока. Проверка доступа по команде:

ping <collector-ip> -I <virtual interface>

Создаем запись маршрута так. В F5-консоли заходим на «Main» – «Network» – «Routes» – «Add» и в экране «New Route» в секции «Properties» настраиваем запись маршрута, чтобы записи потоков с F5 на коллектор vRNI посылались через виртуальный сервер.

Работа с картой сети

Страница «Network Map» рассказывает нам, какая сетевая модель для источников данных добавлена в vRNI. Это сквозная интерактивная карта топологии сети, включающая физические и виртуальные устройства. И, конечно же, функция эта доступна только для Enterprise-уровня лицензии и бриков размера XL.

Доступ к этой странице осуществляется с домашнего экрана, где нужно просто нажать на «Network Map» и тогда откроется такая картина:

где и показываются все ее компоненты (номера списка ниже соответствуют маркерам на скриншоте):

Summary (сводка) – диаграмма предупреждений, кол-во локальных виртуальных сетей, файерволы, балансировщики нагрузки и прочие физические объекты;
Events (события) – список доступных событий в сети (вкладка «Events»), чтобы получить по каждому больше информации, следует кликнуть на «+» (если есть), а чтобы увидеть связанные события с этим – на «Show all»;
Entities (сущности) – список сущностей и их групп в сети (одноименная вкладка). Все виртуальные сущности показаны в логической группировке. Чтобы посмотреть информацию о сущности или группе и ее локацию, следует кликнуть по ним, а если нажать на пиктограмму «лупы», можно можно увидеть еще больше деталей. «Back to Entities» вернет нас после этого обратно на список сущностей. На вкладке «Entities» доступен поиск по сущностям или IP-адресам. Примеры запросов:

«device ххх» – выведет устройства, чье имя содержит «ххх»,

«device ‘ххх‘» – … чье имя точно совпадает с «ххх»,

«ххх» – покажет сущности, чье имя содержит «ххх»,

«‘ххх’» – … чье имя точно совпадает с «ххх»,

«‘1.1.1.1’» – покажет сущности, чей управляющий IP-адрес – 1.1.1.1,

«1.1.1.1» – … чей IP-адрес содержит 1.1.1.1, но может и другие знаки,

«device where manager = 1.1.1.1» – покажет устройства, чей управляющий IP-адрес 1.1.1.1,

«host switch» – список свитчей хоста,

«host switch where name = ‘DSwitch-1-localhost’» – хост свитч, чье имя – «DSwitch-1-localhost»;

Paths (пути) – показаны пути между указанными сущностями (одноименная вкладка). На этой вкладке есть функция «SHOW PATHS», если кликнуть на которую, система начинает искать в доступной сетевой топологии все возможные пути совпадения поисковых параметров. Результат поиска будет сгруппирован в соответствии с заголовками трафика. Каждое описание заголовка трафика содержит список путей, которым могут следовать пакеты с этими заголовками. Если используется мультипассинговая пересылка, покажется множество путей. А вообще вывод осуществляется до 25 результатов в списке. Чтобы увидеть детали по пути, стоит кликнуть на «Path n» (n – это его номер) – данные по пересылке, резервному пути, информация о прыжках и пр.;
Network Topology (сетевая топология) – сквозная интерактивная карта топологии сети, включающая и физические, и виртуальные устройства (графическая схема);
Alerts (предупреждения) – показывается на устройствах, на которых они открыты (пиктограммка восклицательного знака в треугольнике – правый нижний угол страницы);
Edit (редактирование) – быстрый доступ к реорганизации сущностей и групп, создание групп и их удаление, редактирование их параметров (пиктограммка карандашика – там же) – учиться делать это будем ниже;
Zoom In/Zoom Out (увеличение/уменьшение экрана) – зумминг топологии (значки «+» и «-»);
Legend (расшифровка) – можно показывать или скрывать значение каждой иконки, используемой в сетевой топологии (стилизация книжечки).

А теперь немного поговорим о полезнейших действиях, которые можно осуществлять со страницы «Network Map».

Углубленный поиск путей

Простой, доступный на «Network Map», поиск выглядит, примерно, так, в зависимости от введенного запроса:

Что ищем?	From (от)	To (к)
Пути от порта маршрутизации с IP 61.0.1.1 к порту маршрутизации 61.0.1.2	switch port where routedportips = 61.0.1.1	switch port where routedportips = 61.0.1.2
Пути от ethernet1 интерфейса R1-arista к интерфейсу ethernet1 R2-arista	interface ‘ethernet1’ where Device = ‘R1-arista’	interface ‘ethernet1’ where Device = ‘R2-arista’
Пути от 61.0.1.1 к 61.0.2.1, где оба IP относятся к портам маршрутизации	61.0.1.1	61.0.1.2

Обычно, для поиска на странице «Network Map» заходим в «Paths» и в текстовых полях «Source» и «Destination» вводим запрос на сущность или IP-адрес, который хотим найти (описывалось выше в расшифровке вкладки «Entities»), и опционально, если нужно найти пути, пересекающие определенные промежуточные сущности, можно кликнуть на «Add Hop» и добавить несколько прыжков. Часто этого недостаточно. И тогда можно воспользоваться функцией расширенного поиска. Для этого ставим галочку на «Advanced Options» и вводим такую информацию:

Packet Headers. Выбираем либо «At Source» (сопоставление полей заголовков пакетов в начале или конце пути), либо «At Destination» (в конце пути), либо «Any» (для вывода соответствия любых доступных портов/протоколов);
Path Type. Выбираем одно из трех: «Primary» (основные), «Backup» (пути бекапирования) или «ALL» (все);
Path Direction. Выбираем одно из: «Forward» (пути только в направлении вперед) или «Bidirectional» (полный цикл пути из исходной точки к пункту назначения и обратно);
Path Status. Указываем либо «All» (и доступные, и заблокированные пути), либо «Reachable» (доступные), либо «Blocked» (пути, для которых пакеты блокируются до того, как достигнут точки назначения).

А выбрав, нажимаем на «SHOW PATHS».

Добавление/удаление группы

Группировка сущностей облегчает управление и поиск, улучшает обзорность сети. Группы могут состоять не только из сущностей, но и из других групп. Некоторые типы групп vRNI формирует автоматически, например, системные группы виртуальных сущностей внутри того же физического хоста. Пользователь может самостоятельно добавлять свои собственные группы к системным, редактировать их и удалять (но не сгенерированные системой!). Делается это на странице «Network Map», после клика на значок редактирования («карандашик») в нижнем правом углу.

В соответствующем режиме, чтобы создать группу, кликаем на «Add Group» в нижнем правом углу и в появившемся окне вписываем имя новой группы (поле «Name»), из выпадающего списка «Entities» выбираем все сущности, которые хотим сюда включить, а из выпадающего списка «Color» определяем цвет для этой группы, после чего сохраняем всю настройку «SUBMIT».

Чтобы удалить группу, выбираем ее в списке и кликаем на «Delete Group» там же, появится окно подтверждения, в котором нажимаем на «Confirm».

Работа с намерениями (Intents)

Намерение – это, по сути, желаемое состояние нашей сети. Это может быть, как архитектурная цель, так и бизнес-политика, и используется намерение для проектирования, управления и верификации сетей, опираясь на бизнес-политики, помогая предсказывать поведение сети в будущем. vRNI предлагает мощный набор системных «коробочных» намерений (их нельзя удалить или отредактировать, но можно отключить), кроме того можно настраивать собственные интенты из меню шаблонов. Полезно, что периодически vRNI проверяет адекватность каждого намерения, опираясь на все возможные поведения всей сети. Если какое-то намерение нарушено, вы получаете предупреждение. Функция доступна только на «Enterprise»-уровне лицензии при размерах бриков XL.

Все намерения сгруппированы в три категории типов:

здоровье устройств,
здоровье сети,

STIG (только для устройств Cisco ASA, Cisco Catalyst, Cisco Nexus, Juniper EX, QFX, Palo Alto).

Полный список поддерживаемых типов намерений:

Категория типа	Тип	Название/ название в UI	Важность	Виртуальный/физический	Описание
Здоровье устройств (Device Health)	Link MTU Mismatch	Link MTU Mismatch / MTU configuration of the ports on each link should match	Средняя	Физический/виртуальный	Конфигурация MTU портов на каждом линке должна совпадать
Здоровье устройств (Device Health)	HSRP/VRRP Master and STP Root Co-location	HSRP/VRRP Master and STP Root Co-location / HSRP/VRRP Master should be colocated with STP Root, if both protocols are enabled	Средняя	Физический	Мастер HSRP/VRRP не совмещен с последующим STP Root
Здоровье сети (Network Health)	Segmentation	Segmentation Failure / Network endpoints should be segmented	Критическая	Физический/виртуальный	Конечные точки сети должны быть сегментированы
	Reachability	Reachability Failure / Network endpoints should be reachable	Критическая	Физический/виртуальный	Конечные точки сети должны быть доступны
	Duplicate IP Address	Duplicate IP Address / Duplicate IP address has been configured on the following interfaces	Критическая	Физический	Дублирующие IP-адреса не должны быть сконфигурированы в нескольких интерфейсах
	Duplicate MAC Address	Duplicate MAC Address / Duplicate MAC address has been configured on the following interfaces	Критическая	Физический	Дублирующие MAC-адреса не должны быть сконфигурированы в нескольких интерфейсах
	Duplex Mismatch	Duplex Mismatch / Duplex configuration does not match on the following ports	Критическая	Физический/виртуальный	Дуплексная конфигурация портов на каждом линке должна совпадать
	Loop Detection	Loop Detection / Network contains the following loop	Критическая	Физический/виртуальный	Сеть должны быть свободна от петель
	STP Path Cost Method Consistency	STP Path Cost Method Consistency / Inconsistent STP path cost methods have been configured on the following switches	Средняя	Физический	Методы калькуляции стоимости STP-пути должны быть одинаковыми для всех свитчей
	Trunk VLAN Mismatch	Trunk VLAN Mismatch / Allowed VLANs configuration does not match on the following trunk ports	Критическая	Физический/виртуальный	Разрешенные VLAN-конфигурации должны совпадать на портах каждого канала магистрали
	Port Mode Mismatch	Port Mode Mismatch / Port mode configuration does not match on the following ports	Критическая	Физический/виртуальный	Конфигурация режима порта должна быть одинаковой на всех портах каждого канала
	Port Channel Member Mismatch	Port Channel Member Mismatch / Port channel member ports should not connect to non-member ports on linked devices	Критическая	Физический	Порты-участники канала порта не должны подключаться к портам на связанных устройствах, не являющимся членами
	Native VLAN Mismatch	Native VLAN Mismatch / Native VLAN configuration does not match on the following ports	Критическая	Физический	Нативная конфигурация VLAN портов на каждом канале должна совпадать
	Native VLAN Tagging Mismatch	Native VLAN Tagging Mismatch / Native VLAN Tagging does not match on the following ports	Критическая	Физический	Нативное тэггирование VLAN портов на каждом канале должно совпадать
STIG	Account Password Protection	Account Not Password Protected / Administrative account access is not password protected on the following devices	Высокая	Физический	Сетевое устройство должно быть защищено паролем для административного доступа
	Console Access Password Protection	Console Access Not Password Protected / Console port access is not password protected on the following devices	Высокая	Физический	Сетевое устройство должно требовать аутентификацию для консольного доступа
	Default Password Existence	Default Password Existence / Default manufacturer password is used on the following devices	Высокая	Физический	Сетевое устройство не должно иметь ни одного дефолтного пароля от производителя
	Management Connection Password Protection	Management Connection Not Password Protected / Management port access is not password protected on the following devices	Высокая	Физический	Сетевое устройство должно требовать аутентификацию до установки менеджмент-связи для административного доступа
	Plaintext Password Visibility	Plaintext Password Visibility / Plaintext passwords are visible on the following devices	Высокая	Физический	Сетевое устройство не должно иметь паролей в виде открытого текста

Информация о намерениях доступна на странице «Intents» (открывается из левой навигационной панели). Там показывается счетчик всех намерений, а также с разбивкой по каждому существующему типу, и можно кликнуть на этот счетчик, чтобы отфильтровать и просмотреть детали по конкретному типу. По каждому интенту показывается счетчик поднятых им предупреждений, а если кликнуть на этот счетчик, будет доступен просмотр деталей этих предупреждений. Кроме того, обозначается статус намерения как «Pass» или «Fail» и его важность («Critical», «Moderate», «Warning», «Info»). И встроен поиск в списке по имени.

Создание/редактирование/удаление/дублирование/включение/выключение пользовательских намерений

Важно! После создания намерения нельзя изменять его тип. Однако пока этот процесс еще не завершился, можно использовать опцию «Modify», чтобы поменять тип.

В левой навигационной панели кликаем на «Manage Intents» и на странице «Intents» нажимаем «DEFINE INTENT»;
Раскрываем категорию под «Intent Type» и кликаем на «Select» по типу, который хотим определить для нашего нового намерения;
В параметрах вписываем его имя, указываем важность и тэг. Там есть и дополнительные поля, зависящие от того, какой конкретно тип интента был выбран – разбираетесь по ситуации;
Выбираем, каким образом хотим получать сообщения о предупреждениях (почтовый сервер или SNMP-ловушка с адресом – там можно поставить галочки сразу в нескольких, в зависимости от необходимости).

Сохраняем настройку по «Submit», после чего наше новое намерение покажется в общем списке на странице.

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

Работа с микро-сегментацией и планирование безопасности

Анализировать потоки можно, выбрав диапазон, и сегментируя их в соответствии с сущностями, например, опираясь на VLAN/VXLAN, группы безопасности, приложения, тиры, папки, подсеть, кластер, ВМ, порт, тэг безопасности и IPSet. В vRNI для этого есть специальная страница – «Micro-Segmentation», предоставляющая анализ информации с помощью диаграммы топологии:

На этой странице мы найдем виджеты:

Micro-Segments (диаграмма планирования топологии. Выбирается тип группы и потоков и на основе этого система строит наиболее подходящую диаграмму),
Traffic Distribution (информация о распределении трафика в байтах),
Top Ports by Bytes (выводится список из топ-100 портов, записывающих самый высокий трафик. Предлагаются метрики для счетчика потоков и записи потока, также можно посмотреть потоки по конкретному порту, кликнув на соответствующий ему счетчик).

Чтобы попасть на панель микро-сегментации, в левой навигационной панели UI ищем «Security» – «Plan Security», выбираем диапазон, под-диапазон и период, для которого хотим осуществить планирование и анализ и кликаем на «Analyze» – появится соответствующее окно.

Важно! Механизм микро-сегментации может показать до 600 нод и 6000 edge. Когда достигается этот лимит, появится ошибка: «Too many micro-segments to analyse. Please select a different entity or mocro-segmentation criteria».

Работа с приложениями

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

В vRNI можно создавать или добавлять приложении тремя способами:

Вручную в пользовательском интерфейсе;
Через публичные API (список можно посмотреть здесь);
Обнаружением приложений.

Первый и третий способы будут рассмотрены ниже.

Вся информация о приложениях содержится на странице «Application», помогая в аналитике и траблшутинге. На этой странице, в частности, можно найти:

Overview (сводка с диаграммами предупреждений, входящим и исходящим трафиком, потоками, ВМ, физическими IP, счетчиками сервисов Kubernetes и пр., топология с тирами, списком ВМ, физическими IP, от которых зависит приложение или которые использует, службами общего пользования и приложениями, с которыми это конкретное сейчас общается, а также все предупреждения и VM Manager приложений),
What’s New (за последние 24 часа что случилось – счетчик входящего и исходящего трафика, сброшенные потоки, новые и незащищенные члены, сервисы, к которым осуществлялся доступ – внешние и интернет, использованные порты приложений),
Traffic flows/flow analytics (самые активные визави по потокам, топ-потоки приложений по правилу, топ-трафик по App-Id входящий и исходящий),
Микро-сегментация (контекстные потоки между сущностями, предоставляющие данные различных типов потоков, например, разрешенные, сброшенные, защищенные и незащищенные по NSX DFW, что нового в приложении в этом разрезе),
Метрики (метрическая информация по ВМ, репрезентующая скорость сети, данные по CPU, памяти и диску, метрики Kubernetes).

Создание приложений вручную

С домашней страницы vRNI переходим на «Security» – «Applications», и далее:

Там кликаем на «Add»:

и на открывшейся странице в поле «Application Name» вводим его имя;

В секции «Tier/Deployment» вводим уникальное имя (для ВМ, физических машин или сервисов – смотря, что надо);
В поле «Members» выбираем условие из выпадающего списка, чтобы создать тир, опираясь на свойства ВМ, ее расположение (приложение, кластер, папка) или на сервисах Kubernetes (имя сервиса, IP-адрес кластера, пространство имен или сервисные ярлыки);
Вводим значение (или выбираем), которое хотим добавить тиру (если нужно ввести несколько значений, используем запятую после каждого). Чтобы добавить сервис как часть тира, выбираем «Service Name» и прописываем его имя. Исходя из определенного условия, увидим связанный с ним или ассоциированный счетчик ВМ, либо физических IP, сервисов:

Рекомендуется добавить дополнительные условия, для чего кликаем на «Add another Condition»:

Кстати, это можно сделать и позднее, открыв приложение на редактирование («Modify Application»). Шаг полезен, так как тир заполняется виртуалками, соответствующими определенному критерию. На скриншоте выше показано, как если кликнуть на линк счетчика ВМ, появится окно с условиями, где выведены каждая из машин, ему соответствующая. Очевидно, что добавление условия помогает впоследствии в поиске и анализе всего, что затрагивает наше приложение;

Опционально, если нужно добавить другой тир под это же приложение, нажимаем на «Add Tier/Deployment» и все повторяем снова;
Опционально, чтобы создать конфигурацию с динамическим пороговым значением, ставим галочку в «Enable Threshold Analytics» – эта конфигурация создастся на специальной странице «Threshold Configurations» и будет отличаться префиксом «Sys» (учтите, что процесс займет не менее 20 минут);

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

Выбираем «Analyze Flows», чтобы увидеть потоки до того, как окончательно добавить приложение – покажутся тиры, опирающиеся на ВМ или физическую адресацию, соответственно:

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

Теперь это приложение появится в «Saved Application».

Обнаружение и добавление приложений

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

Обнаружение приложений здесь опирается на тэги (vCenter Server или AWS), имена ВМ и ServiceNow. Что же при этом происходит? Поясним на примере. Допустим, у нас есть vCenter Server, добавленный как источник данных и в нем 4 ВМ (VM1, VM2, VM3 и VM4), определены тэги, указывающие на имя приложения, которому принадлежит каждая из машин, а также тэги, определяющие, к каким тирам они относятся:

VM1 (имя приложения – MyApplication1, тир – App)

VM2 (MyApplication1/Web)

VM3 (MyApplication2/App)

VM4 (MyApplication2/Web).

В vRNI мы можем определять критерий группировки для обнаружения приложений по этим тэгам, называя машины в специальном формате: «ApplicationName : Tier : VMName» («MyApplication1 : App : VM1» – как у нас). Исходя из нашего примера, благодаря этому, система обнаружит два приложения с двумя тирами и связанными с ними машинами.

Важно! Названные рандомно ВМ не могут быть сгруппированы для обнаружения приложений.

Если использовать регулярное выражение:

App Regex: (.*)_(.*)_.*-.*

Tier Regex: (.*)_(.*)_(.*)-.*

– vRNI как раз и обнаружит два наших приложения.

Чтобы осуществить на практике обнаружение приложений, в поисковой строке вводим «applications», и на вкладке «Applications», либо сортируем приложения по имени, тиру или членам, либо используем фильтрацию, чтобы увидеть топологию (например, Top 10/Top20 и т.д.) – каждый гексагон соответствует приложению и чем большим является его счетчик, тем темнее будет его цвет, а наведясь на него, можно узнать о нем всю информацию, а линии здесь отражают связь между приложениями и интернетом. На линии, кстати, можно кликать, чтобы увидеть детали о потоках, включая счетчики потоков исходных и назначения, незащищенных обоих типов:

Далее заходим на вкладку «Discover», где будет помогающий в добавлении приложения ряд вкладок, выбираем, какая больше нравится и проделываем следующее, в зависимости от выбора:

На «Tags» определяем диапазон (выбираем «All VMs», чтобы увидеть список всех машин из всех источников данных, либо же «Manual Selection» и фильтруем их, опираясь на аккаунт, дата-центр, менеджера и пр.), вводим ключ и, опционально, значение для тэга, кликаем на «Found countApplication», чтобы увидеть список имен приложений, имен ВМ и кол-во машин, которые соответствуют указанному критерию, затем – на «Unclassified VMs», чтобы увидеть список тех, которые не соответствуют шаблону имени или тэга (можно отредактировать ВМ, чтобы исправить имя или критерий тэга), выбираем опцию «Save changes to» , чтобы создать новый шаблон или проапдейтить уже существующий и окончательно жмем на «Discover»:

На «ServiceNow» – здесь проще всего. Будут сразу показаны все доступные приложения;
На «Names» – определяем диапазон как для «Tags», кликаем на «Pattern Builder»:

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

Кликаем на «Submit», а затем – на ссылку «Found count Applications», чтобы вывелся список имен приложений, имен ВМ и кол-во ВМ, которые соответствуют regex. Жмем на «Unclassified VMs», чтобы увидеть список ВМ, не совпадающих с указанным шаблоном имени, и выбираем опцию «Save changes to», чтобы создать новый шаблон или проапдейтить уже существующий, а затем финально – на «Discover»;

«Advanced» – по факту, то же, что и в «Names».

Результатом обнаружения станет табличное представление и гексагональная карта всех приложений, которые отвечают нашим критериям. Теперь наши новые приложения сами туда добавятся, и мы в любой момент о них самих, и обо всем с ними связанном сможем узнать доступную информацию. Иногда, на гексагоне стоит значок «вопросика» – это означает, что vRNI не может найти или дополнить никакие детали о потоке относительно этого приложения, возможно, потому, что приложение достигло лимита потока или имеет незащищенные потоки. В табличном представлении будут значиться имена приложений, счетчик потоков, которые не достигли своего назначения и были сброшены из-за отказа файервола, а также счетчик тиров и членов. Интересно, что и табличка, и гексагональная топология взаимосвязаны – если кликнуть по каким-то данным в таблице, подсветится соответствующий гексагон, и наоборот, а кроме того подсветятся все сетевые соединения.

С обнаруженными приложениями возможны разные действия. Например, их можно сохранить в vRNI. Для этого либо на карте наводимся мышкой на нужный гексагон и кликаем на «Save Application», после чего появится окошко «Add Application», где заполняем требуемые данные и сохраняемся по «SUBMIT», либо в таблице выбираем приложение и просто кликаем на «SAVE», после чего система запросит подтверждение, с которым соглашаемся еще одним «SAVE»:

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

Сохраненные приложения и информацию о них можно выгружать в «.csv»-формате, нажав на «Export as CSV», и выбрав количество приложений, а также поля, которые хотим экспортировать.

Объединение обнаруженных и добавленных приложений

На вкладке «Discover» в таблице с приложениями выбираем те, которые хотим объединить (см. скриншот выше), и кликаем на «MERGE AND SAVE» – появится окно «Merge & Save Applications». Там в поле «Application Name» вводим новое уникальное имя приложения, также там увидим сводку по этим приложениям с кол-вом тиров (если мы объединяем два приложения, каждое с одним тиром, у нас в итоге получится одно приложение с двумя тирами), ВМ, физическими IP и сервисами, а также их начальными именами. Проверяем данные в «Tier/Deployment», если нужно – переименовываем тиры (система создает дефолтное имя, комбинируя первоначальное имя приложения и имя тира, например, если у нас приложение App1 с тиром t1 объединяется с App2 с тиром t2, в базе получится два тира App1_t1 и App2_t2, что не всегда красиво и информативно в новых условиях). Далее можно включить или выключить пороговую аналитику, выбрав или очистив чек-бокс на «Enable Threshold Analytics». Сохраняем все по «SUBMIT» и закрываем окно «CLOSE».

Анализ приложений

Чтобы увидеть потоки после сохранения нового приложения, нужно нажать по нему на «Analyze». Если выбрать в «Plan and Assess» – «Security Planning», установить диапазон для «Entities» – «Applications» и кликнуть на «Analyze», выведется список тиров по ВМ или физических адресов.

После сохранения приложение будет готово для планирования безопасности:

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

Уменьшить диапазон анализа безопасности по выбранному приложению можно здесь:

Например, можно выбрать сегмент («Web» на скриншоте), чтобы увидеть записанные сервисы и потоки, а также правила файервола.

Работа с аналитикой

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

Просмотр информации на «Flow Insight»

Страница «Flow Insight» дает видение дата-центров, устройств и потоков, и эта опирающаяся на контекст страница предоставляет аналитику на основе сущностей, потоков и выбранного временного диапазона. Зайти на эту страницу можно с левой навигационной панели, кликнув там на «Analytics», а затем – на «Flow Insights». В открывшемся окне из выпадающего списка «Scope» нам нужно выбрать одно из:

«All flows» – выбираем для анализа всех доступных в среде потоков;
«Entities» – для анализа потоков по конкретной сущности, после выбрав тип сущности из выпадающего меню. Здесь также можно использовать текстовое поле «Search entity by name», чтобы найти подходящие и выбрать сразу несколько сущностей;
«Between entities» – анализ потоков между двумя сущностями. Здесь в первом выпадающем списке «Entity type 1» выбираем тип первой сущности (также можно использовать поисковую строку «Search entity by name»), и аналогично в «Entity type 2»;
«Flows matching properties» – выбираем для анализа потоков, которые соответствуют указанному условию. Можно добавлять несколько условий, кликнув на «ADD CONDITION»;
«Custom search» – выбираем для анализа соответствующих пользовательскому поисковому запросу потоков.

Далее из меню «Duration» выбираем временные рамки, в которых хотим анализировать потоки, а из списка «Ports» выбираем одно из:

«All» – чтобы анализировать все порты, доступные для выбранного диапазона;
«Include Ports» – чтобы включить указанные порты, введя их имена в текстовое поле «Search Ports»;
«Exclude Ports» – чтобы исключить указанные порты, введя их имена в «Search Ports».

Это меню не будет видно, если выбрать «Flows matching properties» и «Custom search» в «Scope». После всего нужно просто кликнуть на «ANALYZE».

Панель аналитики потоков поделена на несколько секций:

Top Talkers. Здесь можно увидеть самые «общительные» сущности в среде. Выбираются различные типы сущностей (пары Source-Destination, ВМ, кластера, L2-сети, подсети и др.). В виджете демонстрируются топ-10 участников по каждой выбранной категории сущностей, что помогает пользователю в оптимизации сети. Метрики показаны полосками и поделены по:
- тому потока («Flow Volume»),
- скорости трафика («Traffic Rate»),
- счетчику сеансов («Session Count»),
- счетчику потоков («Flow Count»):

Замечание. Если ВМ попала в несколько метрик, когда указываешь на нее в одной полосе, она подсвечивается и во всех остальных. Если на нее кликнуть, покажется полный список относящихся к ней потоков. Если рассматриваются физические потоки, выбирать следует либо «Source IP», либо «Destination IP». Для просмотра группы потоков или проекции сущности потока, запроса группы потоков кнопка «Flow Analytics» не отображается.

What’s New. Секция помогает отслеживать сервисы и сущности, обнаруженные в дата-центре в выбранном временном диапазоне. В этом виджете мы можем найти:
- New Virtual Machines Accessing Internet (новые ВМ, получившие доступ в интернет),
- New Internet Services Accessed (новые интернет-сервисы, обнаруженные в среде),
- New Internal Services Accessed (список новых интранет-сервисов, обнаруженных, и к которым был получен доступ с конечной точки интернет),
- New Internal/E-W Services Accessed (список сервисов, представленных и доступных на машинах в дата-центре),
- New Services with Blocked Flows (список сервисов, блокирующих потоки. Заполняется только для IPFIX),
- New Firewall Rule Hits (новые правила файервола, вступившие в силу. Заполняется только для IPFIX),
- New App-Ids (новые ID приложений. Заполняется только для NSX Intelligence).
Network Performance. Здесь находятся и визуализируются анормальные потоки для различных диапазонов TCP Round Trip Time (RTT) значений, опираясь на выбранный критерий (только за последние 24 часа и только с пятиминутным обновлением информации). Визуализация слева содержит разные диапазоны TCP RTT, а справа – сами нормальные и ненормальные диапазоны отклонения. Опираясь на значение в процентах отклонения, а также абсолютное отклонение, потоки слева соединяются с теми, что справа:

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

- - Inter-Host,
  - Intra-Host,
  - Internet,
  - All Flows;

Можно менять процент отклонения и абсолютное отклонение, учитывая специфику среды. Если кликнуть на цветную линию здесь, можно получить больше информации о распределении TCP RTT и счетчик потоков:

Outliers. Секция помогает отслеживать и анализировать связанные данные, и поделена на две секции:
- Elephant Flows. Идентификация потоков с маленьким счетчиком сеансов, но очень высокой пропускной способностью по сравнению с потоками с большим кол-вом сеансов, но с маленькой пропускной способностью. Вторые, кстати, часто называют «mice flows». Анализ построен на соотношении байтов к кол-ву сеансов. Каждая точка на графике представляет несколько потоков, и, если мышкой на нее навестись, отобразится их список. Чтобы посмотреть информацию о конкретном потоке, можно на него просто кликнуть;
- Custom Analysis. Здесь визуализируются данные потоков в двух измерениях по выбору. Что помогает анализировать данные с целью поиска аутлайеров различными способами. В этой секции метрики – это приблизительные, но не точные значения:

Обнаружение аутлайеров

На боковой панели заходим в «Analytics» и кликаем на «Outlier», а затем – на «Add», чтобы добавить конфигурацию. На странице «Analytics/Configure» вписываем:

ее имя,
диапазон («Scope», здесь указывается имя группы, определяющее ВМ и айпишники, для которых хотим произвести анализ. Можно выбрать «Application Tier»/«Security Group» в качестве диапазона. В первом случае, помните, что имя приложения и тир нужно предоставлять отдельно. Также можно посмотреть сегментацию для выбранной конфигурации, если нажать на «View Micro-Segments»),
«Detection Type»,

«Metric» – обнаружение будет базироваться на этой метрике потока. Это могут быть «Bytes», «Packets», «Sessions» и «Traffic Rate»,
«Traffic Direction» – выбирается «Outgoing»/«Incoming»/«Both»,
«Traffic Type» – выбирается «Internet»/«East-West»/«All based»,
«Destination Ports» – можно либо выбирать все порты («All Ports» – покажется кол-во портов), обнаруженные на потоках обозначенного диапазона, или же вручную вводить порты назначения устройства («Manually enter ports») в строке автозаполнения,

Важно! Сейчас лимит по кол-ву портов установлен на 20.

«Sensitivity» – чувствительность обнаружения («Medium» по дефолту),
«Preview».

Аутлайер будет обнаружен из оценки данных за последние 24 часа.

Важно! Необходима непрерывность потока IPFIX-данных.

Далее кликаем на «Submit», создастся приложение, которое будет доступно в списке приложений на странице «Analytics Configurations». Чтобы увидеть ассоциированную с ним панель, нужно просто на него нажать.

Статические и динамические пороговые значения

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

При Еnterprise-уровне лицензии в «What’s Happening» обязательно отражается кол-во нарушений пороговых значений. Чтобы посмотреть информацию о предупреждении, нужно просто кликнуть на число «Threshold Violations». Если не видно ни одной конфигурации пороговых значений, прямо в секции «What’s Happening» можно нажать на ссылку «+Configure».

Создание пороговых значений

С левой навигационной панели уходим на «Analytics» – «Thresholds» – «Add», откроется страница «Threshold – Add configuration», и заполняем на ней поле «Name», из выпадающего списка «Scope» (сущности «Virtual Machines», «Flows», «Application», «SD-WAN Link», «SD-WAN Edge» и «SD-WAN Edge Application») выбирается диапазон, а в текстовом поле «Select criteria» вводим критерий:

В секции «Condition» устанавливаем условие для создания предупреждения. Дефолтной метрикой ялвяется «network traffic rate». Чтобы назначить статическое пороговое значение, выбираем «exceeds threshold»/«drops below»/«is outside range». Если вводим «Upper Bound» или «Lower Bound» для «network traffic rate» или «total traffic», либо любой другой метрики, стоит убедиться, что ввели значение в указанных метриках для этого конкретного текстового поля. Например, можно рассмотреть значения: «1 Kbps=1000bps», «1 Mbps=1000kbps», «1Gbps=1000mbps», «1KB=1024B», «1MB=1024KB», «1GB=1024MB».

Для настройки динамического порогового значения выбираем «deviates from the past behavior» и выбираем чувствительность, опираясь на требования к отчету:

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

Далее настраиваем предупреждение, установив свойства «Severity», «Email frequency» и «Send notification emails to:» – точно так же, как мы делали в подразделах выше. И сохраняем всю конфигурацию по «Submit».

Просмотр страницы конфигурации пороговых значений

После добавления конфигурации порогового значения, его можно просматривать на странице «Threshold Configuration», куда заходим с «Analytics», кликнув на «Thresholds»:

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

с виджетами:

График пороговых значений, помогающий определить, какие сущности нарушили границы;
Список предупреждений, сгенерированных для нарушенных пороговых значений за последние три дня;
Top Entities by Violation. Топ-нарушителей за последние три дня.

Пользовательский анализ

Опция «Custom Analysis» позволяет визуализировать данные потоков в двух измерениях по выбору:

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

Работа с пинами

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

Функции пинов:

Фильтрация по показанным в пине данным;
Увеличение детализации каждого пина с помощью кнопки «More options» (информацию о пин можно посмотреть в «Help»);
Большая часть пинов могут экспортировать данные в CSV (учтите, что эта операция для данных потока, к примеру, может занять от получаса и более по времени, если у нас где-то 180 000 потоков и выбраны все поля);
Можно вернуться на исходную страницу с закрепленной. Для этого с сохраненного пина кликаем на «More options» – «Go to original page».

Глобально, пины можно распределить по трем категориям:

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

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

Пины списка просмотра предупреждений. Список предупреждений эти пины выводят в хронологическом порядке для конкретной сущности или их группы (можно выбрать из выпадающего меню в заголовке пина). Также можно поменять границу времени, начиная с которого пин выводит предупреждения, отфильтровать данные по «Alert Status» или «Alert Type» и т.д.:

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

Создание нового пинборда и прикрепление виджета

Чтобы создать пинборд, кликаем на иконку пина на выбранном виджете и нажимаем на «Create New Pinboard» (если еще ни один пин в системе не создавался, можно выбрать «Default Pinboard» из списка «Recently Modified» – она на начальных порах вполне удовлетворяет нужды пользователя). В появившемся окне вводим имя и описание, а затем жмем на «Create and Pin»:

Важно! В последних измененных покажется не более 15 записей. Максимальное кол-во пинбордов, создаваемое всеми пользователями, не может превышать 500 штук. Сюда включаются пользовательские пинборды, расшаренные и дефолтные. На каждый пинборд выносится не более 20 пинов.

Важно! Имя пина должно быть уникальным в системе, содержать не более 100 знаков в виде букв, цифр и пробелов.

После этого покажется сообщение «Pinboard created», и, если хотим предоставить его для общего доступа сразу, кликаем на «Share Now».

Чтобы прикрепить виджет к существующему пинборду, выбираем пинборд в «Recently Modified» и кликаем на «Pin». Сообщение «Your Pin has been added» будет содержать ссылку на соответствующий пинборд:

Опции пинбордов

Если кликнуть на «More Options» в самом верху правого угла пинборда, покажутся его опции (доступно только для создателя или того, кому расшарили доступ в разрешениях в «View and Edit». Все остальные пользователи могут только «Export to PDF» и «Switch to original pin time»). Доступные опции:

Расшаривание пинборда другому пользователю;
Редактирование имени пинборда и пина;
Реорганизация пинов на пинборде;
Удаление пинборда («Delete»);
Экспорт в PDF (соответствующее окно покажет список виджетов и их соответствующих свойств, доступных на панели PCI Compliance, выбираем нужные – минимум одно, максимум – 20, -записей должно быть не более 100, называем отчет – знаков не более 200, страниц – не более 50, – кликаем на «Preview» и финально – на «Export PDF»);
Просмотр данных на пине, как только они были закреплены, нажав на «Switch to original pin time» – покажет данные по каждому пину ровно в тот момент, когда он был создан.

Другие функции пинбордов

Также можно просматривать данные пинборда за любое желаемое время, используя ползунок временной шкалы. Когда пинборд только загрузился, он показывает пины в текущий момент времени («Now»).

Пользователи уровня администратора могут удалять любой пинборд и видеть вкладки «My Pinboards» и «All Pinboards» в библиотеке:

Остальные – только их список в библиотеке пинбордов. Индикатором режима только для просмотра служит значок «глаза» около имени пинборда. Чтобы попасть в библиотеку, в левой навигационной панели кликаем на «Pinboards», а затем – на «All Pinboards». Последние измененные покажутся вверху списка. Чтобы просмотреть конкретный пинборд, на него достаточно просто нажать и подождать немножко времени:

Также доступен поиск пинборда в библиотеке.

Еще можно скопировать пин. Для этого кликаем на иконку пина на виджете, выбираем пинборд, куда хотим его скопировать, после чего нажимаем на «Add». Или сделать его дубликат: для этого по конкретному пинборду кликаем на иконку «Duplicate» («пара листочков») в колонке «Actions»:

Всплывающее окошко попросит ввести нас имя пинборда, описание переползет со старого, после чего кликаем на «Duplicate». Если попробовать продублировать расшаренный пинборд, можно выбрать сохранение пользователей с исходного и их разрешений, отметив «Keep source pinboard users and permissions». Но, это лишь, если у вас разрешения не «только для чтения». Пользователь, продублировавший пинборд становится собственником нового пинборда.

Чтобы настроить общее пользование и совместную работу над пинбордами между членами LADP/AD/vIDM:

Для этого кликаем по нужному пинборду на «More Options» и затем – на «Share» (либо из «Pinboard Library», нажав на иконку расшаривания под «Actions»). По дефолту ссылка на общий ресурс доступна и ее можно показать другим пользователям или группам. Также можно добавить пользователей, с которыми хотим совместно пользоваться пинбордом, указав по каждому привилегии «view» или «view and edit». Учтите, что, если у пользователя привилегии только на просмотр, он не может расшаривать пинборд с другими. Затем жмем на «Save». Информацию об общем пользовании покажет колонка «Shared» в «Pinboard Library», по конкретному пинборду. Либо ее можно посмотреть, если кликнуть на иконку пина на виджете.

Пользователи всех уровней могут расшаривать пинборды как между другими администраторами, так и пользователями уровня «Member», просматривать их и редактировать, а также удалять. Однако, то, что создано администратором, члены могут только просматривать и редактировать (если на второе дано разрешение), а вот администраторы могут производить любые действия, независимо от того, кто является создателем пинборда.

Пинборд как стартовая страница продукта

Сохраненный пинборд можно установить в качестве пользовательской домашней страницы. Для этого проходим на нужный пинборд, кликаем на «Pinboard Options» и на «Set as Home Page». Также это можно сделать со страницы «My Preferences» в «Settings». Чтобы вернуться к предыдущему виду домашней страницы vRNI, в левой навигационной панели кликаем на «Pinboards» и под ним на «Network Insight Home». Появится сообщение: «Do you want to set Network Insight Home as Homepage?», – где нужно кликнуть на «Set Homepage», а затем нажать на «Dismiss», чтобы закрыть окно.

Важно! Если пинборд, установленный в качестве домашней страницы был удален, ею автоматически станет дефолтная домашняя страница «Network Insight Home».

Работа с рекомендованными правилами файервола

На странице «Plan security», если кликнуть на клин диаграммы или ее ребро, можно увидеть список сервисов и потоков для этого конкретного сегмента. Нажав на «Recommended Firewall Rules», получим определенные для него правила, и члены источника или назначения будут представлены списком под такими типами правил:

физика-физика (вкладка покажет список правил, ассоциированных с физическими и интернет-IP. Правила в этом случае могут быть для физика-физика, физика-интернет, интернет-физика и интернет-интернет сущностей);
виртуальные (вкладка со всеми правилами, где, по крайней мере, одна точка – это ВМ):

Если по каждому правилу файервола кликнуть на значок «+» возле имени сущности, увидим членов группы:

Важно! Из категории «Internet» члены не покажутся. Если в группе безопасности и виртуальные, и физические IP, они не отразятся в списке членов этой конкретной группы. Членов сервисов Kubernetes можно посмотреть на отдельной вкладке «Kubernetes Services». Если счетчик членов нулевой (или сама запись) по Virtual Machine, Physical & Internet IPs или Kubernetes Services, вкладка не отобразится.

Также в деталях, помимо членов группы, покажутся: источник, назначение, сервисы, протоколы, действия, связанные потоки (можно нажать на кол-во потоков, чтобы увидеть их список с соответствующей информацией о потоке), примененные правила файервола (если нажать значок «+» рядом с колонкой «Related Flows»):

Рекомендованные правила можно экпортировать в XML или CSV-формате (правила относительно объектов Kubernetes также можно экспортировать в YAML).

Просмотр правил файервола NSX-T Data Center

Если ввести в поисковую строку «nsx-t firewall rules», результат поиска продемонстрирует все правила файервола, работающие в дата-центре:

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

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

Защита уязвимых ОС с помощью рекомендованных правил файерволлинга

Заходим на «Security» – «Application» – «Create application», вводим имя приложения и тир/разворот;
В выпадающем списке «Member» выбираем «Custom VM Search» и в текстовом поле добавляем условие:

in the qualifier put the matching criteria as: Operating System like ‘Microsoft Windows Server 2003’ or Operating System like ‘Microsoft Windows Server 2008’ or Operating System like ‘Red Hat Enterprise Linux 6’ or Operating System like ‘Red Hat Enterprise Linux 5’ or Operating System like ‘SUSE Linux Enterprise 10’

Нажимаем «Save»;

Проходим на «Security» – «Plan Security»;
В выпадающем меню «Scope» выбираем «Application» и имя нашего только что созданного приложения;
В списке «Duration» выбираем «Last 7 days»;
Кликаем на «Analyze», чтобы получить список рекомендованных правил файервола.

Экспорт правил файервола

Меню экспорта всех правил для общей топологии можно найти на странице «Micro-Segmentation Planning»:

Или же можно встать на само правило в списке «Recommended Firewall Rules» и в меню «три вертикальные точки» выбирать соответствующее действие:

Опция доступна для сущностей «Security Group» и «Application Tier». Если диапазон планирования охватывает только один NSX Manager, сгенерированные артефакты будут содержать XML-файлы, соответствующие рекомендованным сервисам и правилам файервола. Если же он расширяется на несколько – там будут не только они, но и IPset, и группы безопасности. Местохранением артефактов для групп безопасности будут файлы «SG-Others_Internet.xml и «SG-Other.xml».

Универсальные артефакты NSX DFW

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

Важно! Импортировать универсальные артефакты следует исключительно на главный NSX Manager. Управлять членством в универсальной группе безопасности можно только через него.

Универсальная группа безопасности может состоять из:

других универсальных групп,
универсальных IP-сетов,
универсальных тэгов безопасности.

Когда экспортируются правила, в дополнение к специфическим папкам NSX Manager создается универсальная папка с универсальными артефактами NSX DFW. После же импорта универсальных артефактов NSX DFW создаются соответствующие универсальные группы безопасности, универсальные IP-наборы, универсальные тэги безопасности и универсальные правила DFW.

Важно! Универсальные тэги безопасности поддерживаются только в active-standby-режиме. Универсальные IP-сеты поддерживаются как в режиме active-active, так и в active-standby.

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

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

«-uni» – чтобы импортировать артефакты из универсальной папки;
«-utag» – чтобы импортировать универсальные артефакты с универсальными тэгами безопасности в членстве универсальной группы безопасности;
«-log» – чтобы создавать правила, где разрешено создание логов (не специфично для опции универсала).

Сохранение конфигурации для экспорта в CSV как шаблона свойства

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

Если открыть модальное окно экспорта CSV, увидим выбор свойств по умолчанию для результатов поиска (отличается для разных типов сущности). Этот список можно изменить и сохранить получившуюся конфигурацию для будущего использования. Предварительно сохраненный шаблон свойств можно загрузить и открыть из раздела «Templates» в модальном окне экспорта CSV. Если поменять значение, увидим выбранные свойства для выбранного шаблона свойств. Кстати, шаблон будет того же типа сущности, который и у выведенного текущего результата поиска.

Список существующих шаблонов свойств в системе можно просмотреть, пройдя в «Settings» – «Property Templates». Эта страница показывает детали шаблонов, в том числе, такие как тип сущности, последний апдейт и количество свойств. Редактировать или удалять шаблон свойств можно оттуда же, за исключением изменения его имени.

Экспорт и применение сетевых политик Kubernetes

Связанные с объектами Kubernetes рекомендованные правила сетевых политик можно также экспортировать – но в YAML-формат. Операция поддерживается только для топологий по группам пространства имен и группам сервисов. Оговоримся, заранее у нас должен быть добавлен кластер Kubernetes и VMware PKS в качестве источника данных (см. выше).

Загружается файл ZIP, поименованный с указанием сетевой политики Kubernetes и ассоциированным с ней временным маркером. Если его разархивировать, увидим пять файлов CSV и несколько папок, количество которых зависит от кол-ва кластеров. В каждой папке будет несколько YAML-файлов. Названия файлов в архиве:

«network-policy-others-ipaddress.csv» – содержит IP-адреса физических серверов и виртуальной машины, с которыми сервисы или пространство имен контактируют;

«recommended-namespace-labels-to-add.csv» – содержит ярлыки, которые нужно прикрепить к подам, ассоциированным с пространством имен (Cluster – «pdk8s», Namespace – «sock-shop», Label – «sock-shop-pdk8s»);

«recommended-service-labels-to-add.csv» – содержит ярлыки, которые нужно прикрепить к сервисам (Cluster – «pdk8s», Namespace – «sock-shop», Service – «front-end», Label – «Service:front-sock-shop-pdk8s», или Cluster – «pdk8s», Namespace – «sock-shop»,Service – «user», Label – «Service:user-sock-shop»);

«recommended-network-policy.csv» – правила, рекомендованные vRNI;

«exported-network-policy-rule-names.csv» – список сетевых политик, экспортированных на основе рекомендованных правил.

Сама процедура:

В модели «Plan Security» выбираем наш кластер Kubernetes и либо раскрываем список опций в виджете Micro-Segments и кликаем на «Export Rules as YAML», либо выбираем ноду в виде механизма Micro-Segments и нажимаем на счетчик «Recommended Firewall Rules», раскрываем список опций и там, и жмем на такую же фразу;
Чтобы применить сервисные ярлыки, запускаем Kubernetes CLI и вводим:

kubectl edit deployment service-name -n namespace-name

kubectl edit deployment redis-primary -n guestbook

Откроется файл разворота сервисов. Далее в списке сервисных ярлыков следует добавить ярлыки, предложенные в файле CSV;

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

kubectl edit namespace namespace-name

kubectl edit namespace guestbook

а в открывшемся файле добавляем предложенные в CSV файле ярлыки к уже имеющимся;

Чтобы убедиться, что ярлыки применились к поду, запускаем:

kubectl get pods -n namespace-name–show-labels

kubectl get pods guestbook–show-labels

Важно! Если ярлыки применяются на пространстве имен, на подах они не отражаются.

Создаем сетевую политику, скопировав, предварительно, YAML-файл из соответствующей папки кластера в другую и запустив команду:

kubectl apply -f <folder-name>/

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

kubectl apply -f <folder-name>/<firewall-rule>.yaml

Мониторинг сущностей

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

Один из виджетов – это «Timeline», временная шкала, где можно поставить галочку в «Show Changes», чтобы отображались на ней любые произошедшие с системой изменения, также там можно выбирать интересующий отрезок времени (например, 1 день). Очень полезная штука, показывающая состояние дата-центра в каждый конкретный момент времени и обеспечивающая комплексный обзор всех предупреждений, которые были обнаружены в выбранном диапазоне времени.

Виджет свойств («Property») показывает важные параметры в виде пары колонок. Некоторые пины свойств могут также отображать только отдельное какое-то значение параметра. Например, пин «VM Properties», показывающий свойства ВМ, такие как ОС, IP-адрес, дефолтный шлюз и логические маршрутизаторы, CPU, память, статус включенности и пр.

Информация о системе vRNI (NI-System)

Страница NI-System – это снэпшот всей, относящейся к системной, информации. Пройти на нее можно из «Install and Support», где кликаем на «View Details» возле «Overview». Либо же в поисковом запросе вбиваем «NI-System».

Она поделена на три секции:

Overview – информация о ключевых свойствах, источниках данных, открытых проблемах и всех изменениях, связанных с системой. Можно посмотреть детали по каждому источнику данных, кликнув на него;
Events – список всех проблем и изменений в системе, источниках данных, платформах и коллекторах;
Platforms and Collectors – список всех платформ и коллекторов, ассоциированных с системой. По каждому можно посмотреть детали, если на него кликнуть.

Информация о ВМ

Информацию о любой ВМ в vRNI можно получить на странице «VM». Там всего пять секций:

Overview – обзор информации о ВМ, топологии, различные конфигурационные параметры, параметры, связанные с безопасностью, путь ВМ-интернет;
Neighbors – графическое представление разных метрических свойств в сравнении с соседними ВМ, список ВМ, принадлежащих к тому же хосту;
Alerts – список связанных с этой ВМ предупреждений;
Flows – список потоков, которые создаются или же пытаются достичь этой ВМ, независимо от того, разрешено это или запрещено файерволом;
Metrics – метрики, связанные с этой ВМ, информация об использовании портов сетью по дороге к ToR, о всех свойствах метрик, информация о входящих-исходящих метриках, месте на виртуальном диске, производительности датастора (не vSAN), о задержках (только при открытом порте 1991):

ВМ-платформы и ВМ-коллектора

Страница «Platform VM» – это снэпшот свойств, изменений и проблем по конкретной ноде платформы. Там мы увидим всю важную информацию о ней, вроде ее имени, IP-адреса, ядрах CPU, памяти, последней даты апгрейда и версии, открытых проблемах, связанных с ней предупреждений, а также графическую презентацию метрик использования CPU, памяти и дискового пространства.

Страница «Collector VM» – это снэпшот свойств, изменений и проблем по данной ноде коллектора. Там, кроме тех же характеристик, что и для ВМ-платформы, будут показаны список изменений, случившихся с источником данных за последнюю неделю, а также кол-во открытых по ним проблем, информация по источникам данным и репортерах NetFlow, доступных на коллекторе, и по каждому – кол-во потоков и обнаруженные ВМ.

Информация о балансировщике нагрузки

На странице «Load Balancer» отражается вся информация, касающаяся виртуальных серверов и пулов, созданных на балансировщике нагрузки. А именно: список виртуальных серверов с их проблемами на балансировщике нагрузки, список пулов на балансировщике нагрузке и их проблемы, предупреждения, ассоциированные с LB, список потоков, их счетчик и сетевой трафик на различных IP назначения, свойства LB (вендор, тип, серийный номер, виртуальные серверы, пулы).

Важно! Информация о потоке не подхватывается для балансировщика нагрузки NSX-V.

Просмотр данных по виртуальному серверу

Страница «Virtual Server» покажет:

Список всех членов пула в виртуальном сервере и информацию о них, включая любые предупреждения о проблемах с ними;
Список ВМ;
Список физических серверов;
Список предупреждений о проблемах с виртуальным сервером;
Список метрик, связанных с виртуальным сервером (условия – счетчик, продолжительность, сетевые метрики – пакеты и байты полученные или посланные, использование CPU);
Топ-потоки для членов пула, используемые виртуальным сервером;
Свойства виртуального сервера, которые предоставляют информацию об IP-адресе LB, сетевом трафике, сервисном порте:

Чтобы посмотреть путь в топологии, ассоциированный с LB, нужно ввести запрос: «client VM name to Virtual server IP». Если виртуальных серверов на различных сервисных портах несколько, отобразится список в секции «Select a Destination VM». Там можно выбрать сервер и кликнуть на «Show Path», чтобы увидеть путь ВМ-виртуальный сервер. В топологии «VM Path» можно кликнуть на виртуальный сервер, чтобы увидеть набор ВМ в его окне. Если там нажать на «View Path», можно будет увидеть путь виртуальный сервер – ВМ.

Информация об источниках данных

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

Источник данных VMware vCenter

Страница «VMware vCenter Data Source» показывает важную информацию по выбранному источнику vCenter, например, IP-адрес/FQDN, имя коллектора, статус включен/выключен, кол-во обнаруженных ВМ, статус включения IPFIX и пр., а также ассоциированные с ним открытые проблемы и все случившиеся изменения за последние 7 дней.

Источник данных Kubernetes

Под Kubernetes vRNI выделяет отдельную панель, описывающую все, что происходит с развернутыми в нем Kubernetes или Tanzu Kubernetes Grid Integrated Edition. Там перечисляются все самые популярные кластера и пространства имен на основе потоков, показаны сущности кластера Kubernetes (пространство имен, поды, сервисы и ноды), добавленные в vRNI кластера Kubernetes, список образов контейнеров, запущенных на подах и счетчик подов для каждого образа контейнера, список новых обнаруженных подов, их счетчик, пространство имен и информация о кластере. В дополнение можно кликнуть на счетчик любой сущности на панели, чтобы получить вид списком и пройти в детали по каждой сущности.

Всего в этот комплекс включено пять панелей:

Cluster (уровень кластера с счетчиком пространств имен, сервисов, подов и нод в развороте, список самых часто используемых пространств имен на основе потоков, взаимодействие между пространствами имен),
Namespace (счетчик подов, сервисов и нод по этому конкретному пространству имен, список самых популярных сервисов на основе потоков, взаимодействие сервисов в пространстве имен, сетевой трафик по пакетам и байтам),
Service (обзор сервиса со счетчиком открытых предупреждений за последние сутки, входящие и исходящие потоки за 24 часа, поды, ноды, на которых этот сервис развернут, подключение между компонентами Kubernetes и NSX-T, счетчик активных нод и подов за указанный период, взаимодействие сервиса в пространстве имен, сетевой трафик по пакетам и байтам),
Pods (информация о кластере, пространстве имен и ноде, которым принадлежит под, сетевой трафик между подами на основе пакетов и байтов),
Nodes (список данных пространства имен, сервисов, подов контейнера, сетевой трафик по пакетам и байтам):

Сбор этих данных по кластеру идет каждые 10 минут, а все объекты (пространство имен, нода, под, сервис) обновляются в vRNI каждые 4 часа. По основным нодам Kubernetes не предоставляется информация Tanzu Kubernetes Grid Integrated Edition, как и не будет данных по кластерам, которые в лишь в статусе «successfully created».

Источники данных NSX

Страница «NSX Manager» отвечает за детальный обзор доступного в vRNI NSX Manager. Чтобы попасть на нее, в поиске забиваем «NSX Manager where SDDC Type = ‘VMC’» и в выведенном результате кликаем на ту страницу «NSX Manager», которая интересует. Здесь мы увидим секции:

Overview (сводка по сущностям политики NSX, измененные за последние 24 часа сущности, топ-потоки по правилу, список маршрутизаторов),
Top Talkers (самые часто используемые сущности в среде),
Network Traffic and Alerts (сетевой трафик и обзор предупреждений, сам список предупреждений).

Также есть отдельная страница «VMware NSX-T Manager» (для нее в поиске вводим «NSX-T Manager» и выбираем сущность, по которой хотим увидеть информацию). Здесь немного другие секции:

Overview (сводка по всему NSX-T Manager, включая диаграмму предупреждений, кол-во правил файервола, IPSET, транспортные зоны, приложения и незащищенные потоки, а также записи потоков за последние сутки, список свойств, правил файервола по количеству хитов, топ-потоки по правилу и менеджеры вычислений, информация о топологии с предупреждениями, ассоциированными с сущностями, самые часто используемые потоки по App-Id),
Alert (список разнообразных предупреждений и предупреждения по анализу пороговых значений),
Flows (разная аналитика потоков),
Metrics (информация о здоровье ноды NSX-T Management – только для версий NSX-T 2.4.0 и свежее):

И еще – отдельная панель для управляющей ноды NSX-T (на нее заходим, если в поиске вбиваем «NSX-T Management Node», а после – выбираем интересующую сущность из списка). Секции этой страницы:

Overview (сводка по NSX-T Management Node, в т.ч. информация о свойствах, системных метриках и служебном статусе),
Event (список разных событий),
Interface Stats (характеристики интерфейса разного вида, включая полученные, переданные, полученные сброшенные и переданные сброшенные пакеты и пр.),
System Stats (разные характеристики системы, в т.ч. системную загрузку, ее использование и использование файловой системы).

Также есть страница и для транспортной ноды NSX-T, тип которой – хост, – «NSX-T Transport Node», открыть которую можно через поиск «NSX-T Transport Node where Node Type = ‘HostNode’» и клик на нужную сущность. Здесь можно увидеть:

Overview (сводка по транспортной ноде хоста, в т.ч. диаграмма предупреждений, входящий и исходящий трафик, внутренний трафик, кол-во сетевых интерфейсов и общее кол-во ВМ, информация о свойствах, статусе транспортной ноды, статистика PNIC, TEP и системные метрики за последние 24 часа. Последние – только для NSX-T 2.4.0 и свежее),
Alert (список разнообразных предупреждений),
Latency (информация о задержке TEP-TEP),
Interface Stats (разные характеристики интерфейса, в т.ч. полученные, полученные сброшенные, переданные и переданные сброшенные пакеты),
System Stats (различные системные характеристики, в т.ч. системная загрузка, использование системы и использование файловой системы. Последнее – тоже только для NSX-T 2.4.0 и новее),
Flows (самые загруженные ВМ по потокам и самые часто применяемые правила по потокам за последние сутки).

Если тип транспортной ноды – Edge, введя в поиске «NSX-T Transport Node where Node Type = ‘EdgeNode’» и выбрав нужную сущность, увидим:

Overview (сводка по ТН Edge, включая диаграммы предупреждений, кол-во сетевых интерфейсов, служебные роутеры Т0 и Т1, маршруты, информация о свойствах, статусе ТН, статистика по аплинку и ТЕР, а также системные метрики за последние сутки),
Alert (разнообразные предупреждения),
NAT Stats (характеристики NAT, в т.ч. статистика правил NAT, самые часто используемые правила по общему кол-ву байтов и по пакетам, а также по счетчику сеансов),
Interface Stats (характеристики интерфейса, в т.ч. полученные, переданные, полученные сброшенные и переданные сброшенные пакеты и пр.),
System Stats (разные системные характеристики, в т.ч. загрузка системы и ее использование, а также использование файловой системы).

Информация о пограничных устройствах

Введя в поиск «Edge Device» и выбрав интересующую сущность, можно пройти на страницу «VMware Edge Device», где будет:

Overview (сводка по всем Edge-устройствам, в т.ч. диаграмма предупреждений, байты, пакеты, потоки члены сеансов, список свойств NSX Edge, служб NSX Edge и NSX Edge Appliance ВМ),
Alert (список деталей разнообразных предупреждений),
Flows (разная аналитика по потокам, например, всего байт и всего пакетов прошедших через NSX Edge, всего потоков и всего сеансов через NSX Edge),
Metrics (разные метрики, вроде использования CPU и сети ВМ Appliance NSX Edge, использования сети на каждый vNIC).

Просмотр PCI Compliance

Доступно только для Enterprise-лицензии в «Security» – «PCI Compliance», и когда откроется окошко «PCI Compliance», там нужно выбрать требуемый диапазон, соответствующую сущность и сроки, за которые нас интересуют данные, после чего нажать на «Assess». После этого нас перенаправит на отвечающую нашему запросу страницу «PCI Compliance», которая помогает оценить соответствие между требованиями PCI и NSX-средой (доступно только для нее!):

Эти требования упомянуты на первом же пине панели. Остальные пины там предоставляют такую информацию:

диаграмма потоков сети (потоки, файерволы, связь и другие сетевые детали),
потоки (список потоков из диаграммы),
потоки протокола открытого текста в зависимости от порта назначения (трафик через них – это открытый текст),
ВМ в диапазоне (исходящие и входящие правила, группы безопасности для них),
группы безопасности ВМ (список),
ВМ, посчитанные группами безопасности (если кликнуть на этом пине на «Count», можно увидеть список ВМ в конкретной группе безопасности),
ВМ, посчитанные тэгами безопасности,
правила файервола, примененные к входящему трафику (трафик от машины вне диапазона к машине из диапазона),
правила файервола, примененные к исходящему трафику (трафик от машины из диапазона к машине вне него),
изменения в членстве тэгов безопасности,
изменения в членстве группы безопасности,
изменения в правилах файервола (список).

Важно! Если в NSX есть вложенные группы безопасности, диапазон PCI Compliance должен отличаться от группы безопасности.

Данные с панели «PCI Compliance» могут быть экспортированы в PDF-отчет. Для этого на странице кликаем на «Export as PDF» в правом верхнем углу, появится соответствующее окошко, в котором отобразится список всех существующих виджетов с их свойствами, где выбираем только те, которые интересуют. Всего можно выбрать не более 20 свойств, а экспортируется до 100 записей. Учтите, что некоторые виджеты не позволяют выбирать конкретные свойства, и там можно указывать только кол-во записей. Далее называем наш файл отчета (до 200 знаков, всего в файле может быть не более 50 страниц), нажимаем на «Preview» для предварительного просмотра результата и окончательно кликаем на «Export PDF».

Информация о группах безопасности

Быстрый доступ к информации по группам безопасности непрост. Но, в vRNI встроен опционал, помогающий в их поиске, получении данных по их элементам. Если в поиск ввести «NSX-T security group» система выведет все настроенные в дата-центре группы безопасности NSX-T Data Center:

Группы безопасности, напомним, это контейнеры, способные содержать множество типов объектов, в т.ч. логические свитчи, vNIC, IPset и виртуалки. Они могут обладать динамическим критерием членства, опирающимся на тэги безопасности, имя ВМ и имя логического свитча. Как только группа безопасности создается, к ней применяется политика безопасности.

На панели «Security Group» показывается топология и с точки зрения файервола, и с точки зрения контейнера:

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

Информация об Internet Service Provider

Страница «Internet Service Provider» помогает получить обзор ISP по всем edge корпорации. Доступ к ней осуществляется через ввод в поисковую строку «Internet Service Provider» и клик в выданном списке на сущность, которая интересует. Там будет только одна секция – «Overview», в которой отразится список эджей VeloCloud, качество отчетов об опыте на Edge и каналах, информация о пакетах, задержке и пакетах потоков:

Информация о топологии сущностей

Оценить топологию сущностей помогает специальный функционал vRNI, исчерпывающе ее отображающий в графическом представлении по каждой сущности, в отдельности. В левой боковой навигационной панели под нее выделен отдельный блок «Path and Topology» с соответствующими подпунктами. Со страниц диаграмм топологий можно пройти в предупреждения, кликнув на выделенный значком предупреждения элемент:

Топология виртуальной машины

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

Топология хоста

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

Топология VXLAN и VLAN

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

Причем, показываются и виртуальные, и физические компоненты.

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

Топология NSX Manager

Топология NSX Manager показывает компоненты, ассоциированные с NSX Manger:

Она становится отличным дополнением аудиторской информации об объектах NSX в целом, которая включает в себя, в свою очередь, данные об имени пользователя, который создал или изменил объект, времени операции и ее деталях. Если включить аудит-логи в NSX-T Manager/NSX-V Manager, vRNI начнет собирать информацию. Для NSX-V объекты – это: SecurityGroup, SecurityGroupTranslation, FirewallConfiguration, FirewallStatus, IPSet, SecurityTag, UniversalSecurityGroup, UniversalSecurityGroupTranslation, UniversalIPSet. Данные будут захватываться для предупреждений типа «Discovery», «Property Change» и «Delete»:

Традиционно, аудиторская информация показывается по объектам и в разрезе временной шкалы:

Для NSX-T объекты – это: NSGroup, NSService, NSServiceGroup, NSFirewallRule, IPSet, NSX Policy Group, NSX Policy Firewall Rule. Захватываются они аналогичного типа предупреждениями, однако для «Delete» не берутся операции по NSFirewallRule. И, важно знать, что предупреждения этого же типа на панели сущностей не доступно. Однако, для них можно всегда задействовать поиск. Примеры его запросов:

alerts where user = username

discovery alerts where user = username

delete alerts where user = username

change alerts where user = username

Топология L3

Все данные, относящиеся к NSX Edge доступны на единой панели:

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

Информация о сети

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

Начать стоит, пожалуй, с инструмента «Data Center Security and Networking Assessment» – полезнейшего помощника, генерирующего общий отчет о текущем состоянии дата-центра, опираясь на записанные потоки трафика:

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

Еще очень полезной и интересной может стать оценка виртуальной сети («VMware Virtual Network Assessment»), анализирующая шаблоны сетевого трафика в дата-центре. В течение 24-72 часов оценка дает:

Инсайт кол-ва E-W-трафика в сети, отражающего риски безопасности;
Превью рекомендаций к действию в NSX-T Data Center по микро-сегментации в сети;
Возможности оптимизации сетевой производительностью с помощью NSX.

Погрузимся в эту тему, в деталях.

Топология пути

Топология пути рисует в подробностях существующую между двумя ВМ связь в среде:

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

Показывается путь ВМ-ВМ между источником и назначением, но, если дефолтный путь не сконфигурирован, мы получим сообщение об ошибке, поинформирующее нас об этом, или о том, что не найден интерфейс роутера. Если имеем дело с Kubernetes, топология пути демонстрирует его для сценариев: Kubernetes Service – Kubernetes Service, Kubernetes Service – Kubernetes Pod, Kubernetes Pod – Kubernetes Pod:

Важно! Вовлеченные в физические устройства пути не поддерживаются.

Интересна опция «Path Via Load Balancer» – она выводит список всех балансировщиков нагрузки, используемых на протяжении пути с выбранного источника на машину назначения. Чтобы посмотреть путь между ВМ через конкретный LB, его имя просто выбираем в списке, а если навести мышку на этот компонент в готовой топологии пути, нам расскажут все о:

имени виртуального сервера,
IP-адресе LB,
номере порта,
алгоритме LB,
дефолтном шлюзе.

Также будут видны и компоненты маршрутизации – если навести мышь на любой из них (маршрутизаторы, эджи, LDR), продемонстрируется полная информация о них, или о NAT.

В правой части топологии пути ВМ есть секция «VM Underlay» (см. скриншот выше), где отображены данные о подложке задействованных ВМ и их подключение к TOR и задействованным портам. Для сущностей Kubernetes этот раздел покажет ВМ или информацию о ноде Kubernetes, на которой находится под. Здесь можно навешивать ярлыки на компоненты, используя «Show labels» под «Path Details», а выпадающий список в верхней части покажет ВМ конечных точек и активные машины на edge. Для каждой ВМ edge выпадающее меню окружения демонстрирует восходящие и нисходящие IP-адреса интерфейса, и опираясь на выбор в нем можно вывести подлежащий путь для каждого конкретного интерфейса.

Стрелочки в верху карты топологии позволяют обратить направление путей.

Еще стоит сказать о секции «Path Details» – она показывает имя актуального канала порта, вовлеченного в путь ВМ-ВМ.

Путь ВМ-ВМ для AWS и VMware Cloud на AWS

Путь между on-premise ВМ и инстансами AWS EC2 можно посмотреть в этом же меню. Поддерживаются сценарии: путь ВМ-ВМ внутри VPC, путь ВМ-ВМ между VPC через пиринговое соединение, ВМ-интернет, ВМ-дата-центр. Пример второго варианта:

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

Важно! Топология гибридных путей к NSX-T или NSX-V дата-центрам работает только, если роутеры эджей настроены с публичными IP-адресами. vRNI не поддерживает топологию подложки ВМ для AWS.

Для пути ВМ-ВМ в AWS доступен поиск сущностей по следующим запросам:

AWS Subnet

AWS Route Table

AWS Virtual Private Gateway

AWS Internet Gateway

AWS VPN Connection

AWS VPC Peering Connection

По VMware Cloud на AWS поддерживаются такие гибридные пути:

VMware Cloud на AWS – VMware Cloud на AWS,
VMware Cloud на AWS – NSX-T/NSX-V,
VMware Cloud на AWS – AWS,
внутренние.

Показывается информация о подложке для всех существующих в VMware Cloud на AWS, но только до сегмента, на котором они лежат, так как подлежащие физические элементы сети абстрагируются с помощью VMware Cloud on AWS и на этом уровне отсутствует видимость. Пример:

Темно-синие линии соответствуют туннелю.

Путь ВМ-ВМ для NSX-T и ВМ-ВМ путь магистрального интерфейса NSX-V Edge

Пример пути ВМ-ВМ для NSX-T:

Синим цветом показывается нода хоста, а серым – нода edge. Все используемые на схеме иконки выведены справа экрана возле ярлыков под Path Details. Распределенный маршрутизатор будет того же цвета, что и соответствующие ему уровни. Цвет сервисного роутера здесь меняется в соответствии с ассоциированным тиром. Все Т-1 компоненты показаны на одном уровне, а Т-0 – на другом. Также показаны и файерволы edge.

Показывается ВМ-ВМ путь и путь ВМ-интернет при подключении DVPG к транковому vNIC NSX Edge и суб-интерфейсов – к VLAN/VXLAN:

Топология путей ВМ-ВМ через NAT

Пути ВМ-ВМ поддерживаются для NSX для vSphere, NSX-T Edges, Fortinet и Check Point. Пример пути ВМ-ВМ через NAT:

А через Check Point NAT:

Чтобы увидеть эти топологии через NAT, следует использовать такие поисковые запросы:

VMware VM ‘<name of the VM>’ to VMware VM ‘<name of the VM>’ via DNAT

если ВМ назначения позади роутера Fortinet и Check Point. И

VMware VM ‘<name of the VM>’ to VMware VM ‘<name of the VM>’

если ВМ назначения позади NSX для vSphere или NSX-T Edge.

Путь ВМ-ВМ для VMware SD-WAN

Под развороты SD-WAN поддерживаются такие сценарии:

путь IP-IP (оба IP должны быть непосредственно в VLAN позади VMware SD-WAN Edge);
IP-интернет или IP-неизвестный IP (местонахождение обоих IP – аналогично);
ВМ-IP, IP-ВМ, ВМ-ВМ (ВМ поддерживаются только в NSX/NSX-T дата-центрах – не в VMware Cloud на AWS, Amazon Web Services и AZURE! VMware SD-WAN Edge должен быть подключен к физическому/виртуальному роутеру в дата-центре через VLAN);

Пример пути ВМ-ВМ для VMware SD-WAN:

Важно! Если шлюз VMware SD-WAN настроен для источника VMware SD-WAN Edge, и он не совпадает с Edge назначения, путь будет показан через шлюзы VMware SD-WAN Edge источника. Если VPN «Branch to Branch» между эджами VMware SD-WAN сделан через кластер VMware SD-WAN, все члены кластера будут показаны на пути.

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

Путь ВМ-ВМ на ECMP показывает такие данные:

Множество ECMP-путей из источника к назначению;
Роутеры, на которых случается ECMP;
Возможные исходящие пути для данного роутера (VRF),
Маршрут для возможного пути:

Если навестись на роутеры, на которых включен ECMP, покажутся дополнительные пути. Также, можно создать путь, выбрав и залочив роутеры. А если нужно посмотреть все ECMP-пути между двумя ВМ, стоит выбрать опцию «Show all ECMP paths» на диаграмме топологии. Если же нужно посмотреть путь для конкретного роутера, надо указать на него и кликнуть «Keep Focus».

Поддержка L2 мостов

В ранних релизах vRNI путь ВМ-ВМ, вовлеченный в мост L2 между двумя и более VLAN не работал. С версии 6.2 соединение мостом поддерживается. Однако, эта функция работает пока только для роутеров Cisco ASA.

Просмотр маршрутов

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

Информация о BGP-окружении

Доступен просмотр окружения BGP NSX edge или логического маршрутизатора. Чтобы его получить, нужно ввести в поисковую строку: «Router where bgp= ‘Disabled’», и раскрыть конкретный роутер из списка. Выведется информация, если NSX-V/NSX-T: IP-адрес, Remote AS, Weight, время активности, время удерживания, статус.

Если статус показывается как «Unknown», информация об окружении не дополняется. Если статус не «Established.up», по этому эджу покажется предупреждение «One or more BGP neighbours are not in established state». Также оно будет доступно в поиске по проблемам.

Еще опционально можно запустить поиск по «Router where bgp= ‘Disabled’», чтобы увидеть роутеры, на которых выключен статус BGP.

Путь в интернет

По каждой машине в среде vRNI показывает, как она подключена к интернету, применяя анимированный путь в пине «Path to Internet». Там заполняются как виртуальные, так и физические компоненты, существующие между ВМ и интернетом. Направление пути можно обернуть, используя стрелочки над визуализацией. Если навести мышку на иконки сущностей, можно получить их имена адресации. Кликнув на иконку на пути, можно увидеть сводный аккаунт их основных атрибутов. Кстати, для удобства можно увеличить размер этого пина, чтобы лучше видеть детали пути:

vRNI и SRM

VMware Site Recovery Manager – поистине замечательный и беспрецедентный продукт VMware, в задачи которому вменяется автоматизация аварийного восстановления на базе основанного на политиках управления, беспрерывное тестирование и автоматизированная оркестровка. Ему в нашем блоге отведен целый подраздел, в котором достаточно много внимания уделялось как вопросам инсталляции и обновления, так и его администрирования, а также регулярно публикуются новости, как только прилетают свежие релизы.

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

Убедиться, что проинсталлирована и настроена vSphere Replication на каждой защищаемой ноде из сетапа vRNI, а SRM развернут и сконфигурирован и на защищаемом сайте, и на сайте восстановления, и что размер нод, а также данные по использованию позволяют все это развернуть и впоследствии использовать без казусов;
Проверить грамотность настройки пары для этих сайтов из UI SRM;
Создать план восстановления и добавить группы защиты, содержащие ВМ vRNI к этому плану. В такой группе обязательно должны быть ноды платформы. В плане восстановления основная нода платформы должна быть помещена в группу с более высоким приоритетом, чем остальные.

Важно! Рекомендовано мигрировать или восстанавливать ВМ vRNI на идентичную сетевую конфигурацию. И не указывать никакую IP-кастомизацию для плана восстановления, если сайт восстановления не в той же сети, что и защищаемый. Сети нужно назначать вручную таким образом:

Запустить команду «change-network-settings» на всех платформах, чтобы поменять IP$
Запустить «update-IP-change» на всех нодах;
Запустить на первой платформе команду «finalize-IP-change»;
Запустить «show-connectivity-status» на всех коллекторах и найти «Platform_VM_IP/URL», чтобы идентифицировать ассоциированные ноды платформы;
Запустить «vrni-proxy set-platform –-ip-or-fqdn platform-newIP» на всех коллекторах;
Проверить служебный статус. Если какие-то из нод платформы не запускаются, перезагрузить их в рекомендованном порядке.

Далее просто следуем инструкциям по работе с SRM и обращаемся с нодами vRNI, как обычно для этой интеграции.

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

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

А об интересных изменениях и улучшениях последней, на данный момент – 6.2 – версии продукта, написано в деталях в нашей новости «vRealize Network Insight 6.2 Release Notes».