vRealize Network Insight – это приложение для операций и аналитики, обеспечивающее интеллектуальную работу в программно-определяемых сетях, физических сетях, а также отвечающее за настройку безопасности. Оно используется в обнаружении и устранении неполадок безопасности приложений и сетевого подключения, в оптимизации по всем направлениям, затрагивающим любые сферы интересов виртуализации от дата-центра до облака и пользовательских конечных точек:
Сегодня, открывая в библиотеке нашего блога цикл посвященных этому продукту VMware статей, мы поговорим, в деталях, что же он собой представляет на практике, какова его сфера применения и конкретная польза для администратора виртуальной сети, расскажем, какие существуют в его отношении требования и научимся грамотно готовить среду для его установки, рассмотрим сам процесс инсталляции, а также базовую настройку vRNI для работы. В качестве небольшого анонса, пообещаем последующий выпуск еще нескольких материалов на эту тему, в частности, касающихся обновления с предыдущих версий этого продукта до актуальной, а также разбор вопросов его администрирования и применения.
Напомним, на данный момент актуальной является версия 6.2 vRealize Network Insight, выпущенная вендором 15 апреля 2021 года, о новом функционале и интересных изменениях которой мы писали в соответствующей новости. А ее траблшутинг, в свою очередь, рассматривался вот здесь. Настоятельно рекомендуем перед тем, как приступать к изучению нижеизложенного, обратиться к этим статьям. Также, подразумевается, что с программно-определяемыми сетями VMware в их последней инкарнации читатель на короткой ноге, а если хочется освежить знания по этому предмету, вот список крайне полезных материалов нашего блога из раздела, посвященного NSX-T Data Center: «Дизайн VMware NSX-T Data Center 3.1», «VMware NSX-T Data Center 3.1: Разворот с нуля», «Администрирование и настройка VMware NSX-T Data Center 3.1» и «Обновление VMware NSX-T Data Center до версии 3.1».
Что ж, давайте закругляться с предисловиями и переходить непосредственно к предмету нашего сегодняшнего обсуждения.
О vRealize Network Insight: функции, архитектура и область применения
Современный рынок предельно изменчив, и организациям, существующим в его рамках, приходится постоянно добавлять новые приложения для пользователей, масштабировать свою сетевую инфраструктуру и перераспределять ее ресурсы для обеспечения продуктивной и конкурентоспособной деятельности. В результате сетевая инфраструктура начинает напоминать этакого монстра-Франкенштейна, беспорядочно обрастающего все новыми компонентами и связями, непрерывно расширяющего свой функционал, поэтому неудивительно, что сетевикам порой весьма трудно разбираться и наводить порядок во всех этих хитросплетениях.
И тогда им на помощь готов прийти vRNI – он обнаружит приложения и оценит, какие рабочие нагрузки, виртуальные машины, физические серверы и контейнеры Kubernetes в нем участвуют, упорядочит их и поможет организовать к ним безопасный доступ из разных мест, включая публичные облака. Полученная данным продуктом информация затем будет применена в процессах включения политик сегментации сети, в организации средств безопасности, а также в миграции, причем в своей работе он активно пользуется machine learning, становясь динамически совершенствуемым и выгодно оптимизированным.
Область применения и функции vRNI
Интересы vRealize Network Insight концентрируются на трех масштабных и, бесспорно, злободневных направлениях. Это:
- сетевая организация мульти-облачных сред,
- слежение за приложениями и их миграцией,
- безопасность приложений и облаков:
Попробуем понять, что может дать vRNI каждой из этих зон ответственности.
В гибридных и мульти-облачных средах, в том числе в NSX, VMware SD-WAN, VMware Tanzu Kubernetes Grid Integrated, VMware Cloud на AWS, Azure VMware Solution, Amazon AWS и Microsoft Azure, vRNI дает единый взгляд и полную прозрачность динамики сетевой организации и процессов работы приложений, помогает в налаживании оверлейных и основных сетей, предоставляет инструменты для сквозного обнаружения и устранения проблем. Кроме того, это – мощнейший анализатор трафика и путей, инструмент мониторинга сети и управления облачными объектами и услугами, с которым на порядок легче планировать свою работу ИТ-департаментам, видоизменять свою инфраструктуру для соответствия текущим и будущим требованиям бизнеса, и, наконец – незаменимый помощник в прогнозной аналитике, минимизирующий риски и дающий представление о том, чего нам ждать от своего сетевого хозяйства завтра:
Помощь в миграции приложений в облако – одна из ключевых функций vRNI. Гибкость, скорость доставки и масштабируемость, грамотный выбор очередности кандидатов на перемещение с точки зрения потребления пропускной способности и безопасности, глубокое понимание зависимостей приложений и минимизация рисков при миграции – вот неполный список того, что vRNI готов нам предложить здесь и сейчас. И, конечно же, нельзя забывать о его способности весомо сократить время простоя при всем этом, благодаря чему падение производительности в организации перестает ощущаться.
Помимо всего перечисленного, vRealize Network Insight активно применяется в разработке собственной системы безопасности приложений и процессов миграции в облако – идеально подходящей к конкретным бизнес-условиям и политике предприятия. С ним можно рекомендовать политики файервола, создать сегментацию сети для приложений и назначить зависимости для снижения любых актуальных для сетей рисков – особенно, связанных с миграцией. И, наконец, это мощнейший инструмент мониторинга и траблшутинга сетей, крайне оперативно обнаруживающий возникшие неполадки и устраняющий их, независимо от сложности, проявления и источника.
По факту, vRNI будет полезен в работе сразу трем категориям администраторов:
- сетевикам (обзор оверлейных и основных сетей, траблшутинг бранч/дата-центр/облако, сетевая оптимизация),
- инфраструктурщикам, в том числе, облаков (обнаружение, миграция, связь и безопасность приложений),
- безопасникам (планирование безопасности, микро-сегментация, аудит и проверки на соответствие).
Это своеобразный информационный мост между приложениями и инфраструктурой, их поддерживающей. Со всеми сопутствующими возможностями и функционалом.
Функции Network Assurance и Verification
В последних релизах добавились интереснейшие функции – Assurance и Verification. В их задачу входит проверка на соответствие сети поставленным целям:
Формальная проверка использует унифицированную математическую модель функционирования сети, при этом легко поддерживая целую плеяду дополнительных источников данных, в т. ч. Cisco UCS, ASA и Juniper QFX Network Map. Например, страница «Network Map» предоставляет информацию о текущей сетевой модели для всех поддерживаемых источников данных, добавленных в vRNI, и выполняет поиск путей на основе IP-адресации.
Об этих функциях мы подробнейшим образом поговорим в будущей статье по администрированию нашего vRealize Network Insight.
Тандем NSX и vRealize Network Insight
Не секрет, что vRNI – продукт который специально создавался, в первую очередь, для и под NSX. Запряженные в одну упряжку эти решения поистине непобедимы. NSX расширяет диапазон физической сети с помощью vTEP, VXLAN и VLAN, интеграцию между гипервизором, виртуальной сетью и физической сетью, и именно эта его способность является фундаментальной по своему значению. И нужда в глубоком понимании взаимосвязей между элементами NSX, разумеется, породила и новый соответствующий инструмент-помощник.
По большому счету эффективная работа с виртуальными сетями невозможна без:
- Понимания в масштабе, где построены и работают сетевые сервисы на всей структуре с ее множеством хостов и приложений;
- Организации служб путей коммуникации, в том числе, коммутации, маршрутизации, безопасности и балансировки нагрузки по каждому запросу от ВМ;
- Обеспечения надежности системы в сфере синхронизации обмена данными, управления, между контроллерами и службами хоста;
- Отладки разворотов и конфигурационных проверок в соответствии с существующими best practice;
- Слежения за аналитикой трафика с целью настройки производительности и безопасности (и по каждому хосту, и по каждой ВМ).
И во всем этом NSX подпирает плечом именно vRNI. Он обеспечивает конвергентную плоскость операций между виртуальной и физической сетью, помогая в управлении и масштабировании развертываний NSX-T Data Center и предоставляя информацию обо всем многообразии объектов сети (папок, кластеров, VLAN, тэгов безопасности и др.), их взаимосвязях. Именно vRNI автоматизирует группировку безопасности на основе конструкций vCenter Server и NSX, характеристик рабочих нагрузок, портов и общих служб, работает с микро-сегментацией:
Мониторинг инфраструктуры NSX-T Data Center представляет собой скрупулезную проверку на работоспособность и соответствие в виде прохождения своеобразного чек-листа, правила которого можно задавать, как и настраивать предупреждения, связанные с проведенной проверкой:
Сколько бы ни использовалось инстансов NSX-T Data Center Manager, их здоровье и топология будут наглядно визуализированы, время даунтаймов сократится в разы, так как обнаружение несоответствий конфигурациям будет происходить проактивно, а работа с Федерацией станет куда проще и прозрачнее:
Не говоря о случаях, когда приходится налаживать отношения между NSX Data Center для vSphere и NSX-T Data Center с целью достижения соответствия. Причем все полученные данные могут быть экспортированы в CSV-файл.
Интеграция vRealize Operations Manager и vRealize Network Insight
Специальный пакет «VMware vRealize Operations Management Pack for vRealize Network Insight» позволяет получать предупреждения о проблемах из vRNI и публиковать их в vROPs. Эти предупреждения сопоставлены с общими объектами и для vRNI, и для vROPs:
vROPs использует набор API vRNI и выводит список предупреждений на панели «Alerts» – они отличаются префиксом «vrni-» в имени ото всех прочих. Для обеспечения интеграции этих двух продуктов пользователя vRealize Operations Manager нужно добавить в vRNI с, по крайней мере, привилегией «Member», чтобы получить доступ к функционалу.
Приложения, обнаруженные vRNI, синхронизируются с vROPs.
Kubernetes и vRNI
Kubernetes vRNI уделяет весьма много внимания. Специальная панель, ему посвященная, дает быстрый обзор развертываний Kubernetes или Tanzu Kubernetes Grid Integrated Edition:
Там можно получить информацию о наиболее активных кластерах и пространствах имен на основе потоков, данные о сущностях кластера Kubernetes (пространство имен, поды, сервисы и ноды), о кластерах добавленных в vRNI, список образов контейнеров, запущенных на подах, и количество подов для каждого образа контейнера, а также перечень новых обнаруженных подов, их счетчики, пространства имен и детали кластера. Также доступно отслеживание сетевых путей для подов и служб Kubernetes (ВМ-под Kubernetes, под-под, назначение как под, источник как под):
SD-WAN и vRNI
В качестве источника данных в vRNI может быть добавлен один и только один SD-WAN, и для него на специальную информационную панель будет вынесено представление Edge-Edge и Edge-Gateway подключения:
Здесь могут быть показаны прямые и одно-хоповые подключенные сущности (edge/шлюзы), нездоровое состояние оверлейного интерфейса (выделяется красным цветом, если значение Tunnel QoE меньше 7), а из выпадающего меню можно конкретизировать характеристику отражения (Healthy/Un-Healthy (дефолтная)/All Tunnel), и указатель на линки покажет значения QoE туннелей для видео, звука и транзакций как сетевого типа:
Панели ISP
Представлена специальная панель (страница «Internet Service Provider») для обзора Internet Service Provider (ISP) по всем edge в организации. Там можно выбрать нужную сущность и получить по ней информацию о списке Edge VMware SD-WAN, пакетах, задержке и потоках пакетов, отчеты о качестве опыта по edge и линкам:
Терминология и архитектура
Чтобы упростить задачу понимания всего, о чем мы сегодня будем разговаривать, давайте кое-что вспомним, а кое-что – изучим с нуля в отношении терминов, применяемых в vRealize Network Insight:
Сущность (Entity) – логическая часть дата-центра. vRNI изучает все множество известных для него сущностей и их взаимосвязи:
Причем, здесь важно понимать двуликость сущностей и их свойство вкладываемости: к примеру, ВМ – это сущность, но она также является частью хоста, который, в свою очередь, тоже является сущностью – но другой. Обзор сущностей дата-центра vRNI предоставляет на специальных страницах, включая детализированные метрики для них, подробные топологии с демонстрацией взаимосвязей с другими сущностями и многое другое.
Поток (Flow) – набор IP-пакетов, проходящий через точку наблюдения в сети в течение определенного интервала времени (о потоках мы много говорили в серии про NSX – см. выше ссылки на статьи). Обзорность потока дает представление о схемах связей между сущностями в дата-центре. В vRNI любой поток состоит из четырех компонент:
- IP источника,
- IP назначения
- порт назначения,
- протокол.
Потоки анализируются с учетом выбора диапазона, а сегментация потоков опирается на сущности VLAN/VXLAN, группу безопасности, приложение, тир, папку, подсеть, кластер, ВМ, порт, тэг безопасности и IPSet. На диаграммах vRNI, обычно, синие линии отвечают за исходящие потоки, желтые – за входящие, а зеленые – за двунаправленные.
Приложение (Application) – это коллекция тиров. Каждый тир в приложении – это набор ВМ, опирающийся на определенные пользователем критерии фильтрации. Можно создавать иерархическую группу ВМ и визуализировать трафик или потоки между типами одного и того же приложения, а также наглядно представлять потоки между приложениями с помощью vRNI:
vRealize Network Insight идентифицирует границы приложений и определяет сами приложения, чтобы начать планировать микро-сегментацию. Приложения обнаруживаются независимо от расположения (ВМ, контейнеры, облака и др.). Сохраненные приложения – это конструкции приложений, используемые vRNI в планировании миграции и безопасности, траблшутинге и прочем. Обнаружение приложений происходит автоматическим образом/вручную на основе тегов, имен ВМ, ServiceNow или изученных потоков:
Пути данных (Data Path) – способ передачи данных в рамках дата-центра и вовне него. Являются непосредственными участниками распределения трафика, формируя, в свою очередь, потоки. Визуализация топологии путей данных в виде схем подключений помогает в понимании взаимосвязей между сущностями, составляющими путь:
vRNI показывает типы путей данных ВМ-ВМ, ВМ-физика, ВМ-интернет с разбивкой по каждому прыжку по оверлейным (логические маршрутизаторы, шлюзы edge) и основным сетям (физическим сетевым устройствам), демонстрируя метрики производительности и все выявленные проблемы, а также эффективные правила файервола и политик безопасности по NSX и другим сетевым Аppliance.
Архитектура и принцип работы vRealize Network Insight
По сути, vRNI состоит из двух отдельных Аppliance: ВМ-платформы и ВМ-коллектора. Первая обрабатывает и предварительно настраивает сетевые данные, а вторая – собирает их для ВМ-платформы:
Все системные компоненты можно просмотреть на странице «Overview and Updates» в подразделе «Infrastructure and Support» секции «Settings»:
Верхний уровень ВМ-платформы включает в себя:
- UI на верхнем уровне REST API,
- Механизм поиска,
- Компонент высокопроизводительной потоковой аналитики:
После того, как ВМ-коллектора переслали данные, ВМ-платформы их складируют для vRNI. В данном случае компоненты хранилища данных и поискового механизма выполняют следующие функции:
- Хранение конфигураций, изменений и статистики производительности;
- Индексы, конфигурации и предупреждения;
- Поддержка политик хранения данных:
Сетка аналитики декодирует информацию, которую ВМ-коллектор отправляет на ВМ-платформы. Этой сетке вменяются такие функции:
- Хранение данных от ВМ-коллекторов;
- Процессы в реальном времени и в пакетном режиме;
- Предоставление графиков, маршрутов трафика, предупреждений MTU и т.д.:
ВМ-коллектор отвечает за следующее:
- Сбор данных с источников данных;
- Получение данных IPFIX и NetFlow на порте UDP 2055;
- Получение данных sFlow на порте UDP 6343;
- Безопасное соединение с ВМ-платформы перед загрузкой данных или получением инструкций;
- Сжатие пакетных данных до подгрузки;
- Использование Foundation DB для хранения информации о статусе, требуемой для компонентов на ВМ-коллектора.
Данные ВМ-коллектором собираются из самых различных источников. В том числе из vCenter Server, NSX, компонентов облачных сервисов и физических устройств. Распределенный свитч vSphere может быть настроен на экспорт потока информации с помощью IPFIX – точно так же, как с NetFlow. С IPFIX проприетарная информация может быть сформирована в поток, поддерживая экспортирование виртуализации любой информации. Также в IPFIX есть переменной длины текстовые поля, поддерживающие экспортирование HTTP хоста, URL или сообщений. Поддержка NetFlow (с vRNI 3.6) расширяет прозрачность потоков приложений, включая bare-metal сервера и устройства, работающие с версиями NetFlow 5/7/9. Поддержка sFlow (с версии vRNI 4.0) помогает продвинуться в понимании подложки физической сети. Приемка данных sFlow требует открытого порта 6343 на ВМ-коллектора. Используемая для NetFlow или sFlows ВМ-коллектора является привязанным коллектором и не может применяться ни для каких других источников данных. Если любой другой источник данных добавляется на ВМ-коллектора, машина становится недоступной для коллектора физического потока под потоки NetFlow или sFlows.
Работа ВМ-коллектора наглядно поясняется такой схемой:
И для нее справедлив ряд утверждений. Во-первых, существует один и только один способ загрузки данных и получения инструкций от платформы. Во-вторых, ВМ-коллектор обладает указанными адаптерами для источников данных и получает сообщения с данными только из них. И, наконец, стоит отметить, что он, кроме того, получает данные от потокового процессора.
Важно несколько слов сказать еще и о механизме хранения оффлайн-сообщений. Соответствующее хранилище временно хранит последние данные, если ВМ-платформы не доступна. Оно ограничено процентом дискового пространства и вполне функционально для использования в промежутках времени от нескольких часов до дней, в зависимости от размера среды. А также стоит упомянуть и о потоковом процессоре – высокопроизводительном компоненте, отвечающем за первичную обработку захваченных потоков. Последний обрабатывает необработанные файлы записей потока (nfcapd) и генерирует 5/4-конечные упорядоченные списки элементов, агрегирует статистику, применяет алгоритмы и эвристический анализ для сшивания записей, выполнения дедупликации потока и обнаружения угроз, например, сканирования портов. Потоковый процессор поддерживает до 10 млн. уникальных 4-конечных упорядоченных списков элементов одновременно.
Важно! Если ВМ-коллектор падает, источники данных не переключаются на новый ВМ-коллектор.
Завершая разговор об архитектуре и механизмах действия vRNI, немного уделим внимания гибкости разворота продукта. Множество ВМ-коллекторов могут подключаться к единственной ВМ-платформе, поддерживая зоны безопасности, гео-распределенные сайты сбора и масштабирование:
Требования и совместимость
Перед тем, как приступать к процессу подготовки к инсталляции и к ней самой, стоит привести ряд требований к развороту vRNI. В том числе по совместимости с другими компонентами виртуальной среды, поддержке топологий и прочего.
Начнем с самого простого – с совместимости с другими продуктами виртуализации от VMware. Как обычно, исчерпывающую информацию по этому вопросу нам дает онлайн-инструмент PIM. О доступных путях апгрейда с версии на версию vRNI мы поговорим в нашей следующей статье этого цикла, посвященной конкретно обновлению.
Важно! Для системных операций доступ к NTP-сервису критично важен. Если он недоступен, ни в коем случае нельзя перегружать ноду платформы или ноду коллектора.
Важно! Для Network Map максимально поддерживаемое кол-во правил файервола на каждый VMware NSX-T Manager (включая DFW и правила edge) равняется 5 000.
Поддерживаемые топологии
Приложения могут собирать данные из дата-центра, опираясь на источники данных, представляющие такие технологии:
- Технологии VMware (vCenter Server, vRealize Log Insight, NSX Manager, VMware SD-WAN, VMware Cloud на AWS, VMware HCX Layer 2, VMware Tanzu Kubernetes Grid Integrated Edition);
- Сторонний софт (Amazon Web Services, OpenShift, Palo Alto Networks Panorama, Check Point Management Server, Cisco ASA, Infoblox, Azure Subscription);
- Hardware (Dell OS10 Switches, Huawei 6800/7800/8800 Series, Physical Flow Collector для Flows и NetFlows, маршрутизаторы и свитчи ServiceNow Generic, F5 BIG-IP).
О том, как добавлять источники данных мы поговорим ниже, в разделе, посвященном первичной настройке vRNI после его установки.
Системные требования и размеры разворотов
Вообще, все конфигурационные ограничения, по традиции, смотрим в инструменте – версии сменяют друг друга, поэтому самую свежую информацию об изменениях можно почерпнуть только там. Сейчас же приведем только то, что касается 6.2 и в разрезе самых важных при проектировании будущей системы параметров.
Размеры при развороте платформы
Минимальные рекомендации по развороту платформы, в зависимости от типа размера брика:
| Размер брика | Ядер для 2.1 GHz CPU, шт | Ядер для 2.3 GHz CPU, шт | Ядер для 2.6 GHz CPU, шт | RAM, ГБ | Размер диска, ТБ |
| Medium | 10 | 9 | 8 | 32 | 1 |
| Large | 15 | 14 | 12 | 48 | 1 |
| Extra Large | 20 | 18 | 16 | 64 | 2 |
Важно! Резервирование скорости CPU и памяти по каждой ноде должно вдвое превышать указанное значение. Если любой из дисков нод платформы достигнет 95% своего заполнения, пользовательский интерфейс vRNI перестанет отвечать. Тем не менее, в процессе работы такая ситуация весьма обычна, и тогда поможет процедура добавления дополнительного дискового пространства, которая доходчиво описана, как и все связанные с ней нюансы, в этом КБ.
При некластерном развороте известны следующие максимумы:
| Размер брика | Кол-во ВМ | Потоков в день | Потоков всего | Плановые потоки | Кол-во устройств | Кол-во правил | Кол-во Edge для VMware SD-WAN | Кол-во ВМ для потоков на основе обнаружения приложений |
| Medium | 4 тыс. | 1 млн. | 4 млн. | 2 млн. | 10 | 2 тыс. | 2 тыс. | не поддерживается |
| Large | 6 тыс. | 2 млн. | 8 млн. | 4 млн. | 20 | 4 тыс. | 2 тыс. | не поддерживается |
| Extra Large | 10 тыс. | 2 млн. | 8 млн. | 4 млн. | 30 | 5 тыс. | 4 тыс. | 3 тыс. |
При кластерном развороте указывается одна из двух опций (Option 1/Option 2), и в зависимости от этого максимумы будут различны. В первом случае для Option 1:
| Размер брика | Размер кластера | Кол-во ВМ | Потоков в день | Потоков всего | Плановые потоки | Кол-во устройств | Кол-во правил | Кол-во Edge для VMware SD-WAN | Кол-во ВМ для потоков на основе обнаружения приложений |
| Large | 3 | 10 тыс. | 2 млн. | 8 млн. | 4 млн. | 30 | 5 тыс. | 4 тыс. | Не поддерживается |
| Extra Large | 3 | 18 тыс. | 6 млн. | 24 млн. | 6 млн. | 50 | 10 тыс. | 6 тыс. | 3 тыс. |
| Extra Large | 5 | 30 тыс. | 10 млн. | 40 млн. | 10 млн. | 50 | 10 тыс. | 10 тыс. | 3 тыс. |
| Extra Large | 7 | 58 тыс. | 12 млн. | 48 млн. | 10 млн. | 50 | 10 тыс. | 10 тыс. | 3 тыс. |
| Extra Large | 10 | 100 тыс. | 15 млн. | 55 млн. | 10 млн. | 50 | 10 тыс. | 10 тыс. | 3 тыс. |
А для Option 2:
| Размер брика | Размер кластера | Кол-во ВМ | Потоков в день | Потоков всего | Плановые потоки | Кол-во устройств | Кол-во правил | Кол-во Edge для VMware SD-WAN | Кол-во ВМ для потоков на основе обнаружения приложений |
| Extra Large | 3 | 12 тыс. | 3 млн. | 12 млн. | 4 млн. | 300 | 275 тыс. | 6 тыс. | 8 тыс. |
| Extra Large | 5 | 18 тыс. | 6 млн. | 24 млн. | 6 млн. | 400 | 575 тыс. | 10 тыс. | 18 тыс. |
| Extra Large | 7 | 30 тыс. | 10 млн. | 40 млн. | 6 млн. | 400 | 575 тыс. | 10 тыс. | 24 тыс. |
| Extra Large | 10 | 72 тыс. | 13 млн. | 50 млн. | 10 млн. | 400 | 575 тыс. | 10 тыс. | 24 тыс. |
Важно! Функции Network Verification and Assurance, а также Flow Based Application Discovery доступны исключительно для размера Extra Large.
Важно! Кол-во ВМ включает шаблоны на vCenter.
Важно! Кол-во правил включает и все записи пересылки, в т. ч. L2/L3, контроль доступа и NAT.
vRNI поддерживает не более 10 000 групп безопасности и 10 000 IPSet при кластерном развороте 10XL.
Размеры разворота коллектора
В разрезе типов размеров бриков:
| Размер брика | Ядер для 2.1 GHz CPU, шт | Ядер для 2.3 GHz CPU, шт | Ядер для 2.6 GHz CPU, шт | RAM, ГБ | Размер диска, ТБ |
| Medium | 5 | 5 | 4 | 12 | 200 |
| Large | 10 | 9 | 8 | 16 | 200 |
| Extra Large | 10 | 9 | 8 | 24 | 200 |
А требования к максимальной емкости таковы:
| Размер коллектора | Кол-во ВМ | Потоков в день | Счетчик потоков за 4 дня | Кол-во Edge для VMware SD-WAN |
| Medium | 4 тыс. | 2,5 млн. | 3,25 млн. | 4 тыс. |
| Large | 10 тыс. | 5 млн. | 6,5 млн. | 6 тыс. |
| Extra Large | 35 тыс. | 10 млн. | 13 млн. | 10 тыс. |
Требования к сети и связи
Максимальный временной сдвиг между нодами платформы не должен превышать 30 секунд. Между нодой платформы и сервером обновлений задержка должна быть меньшей 500 мс, иначе vRNI выдаст ошибку. А рекомендованные значения задержки между ВМ платформы под оптимальную производительность приводятся на уровне 3 мс, между ВМ платформы и коллектора – до 150 мс. А время отзыва диска не должно превышать 5 мс.
Связь от ВМ-коллектора к ВМ-платформы происходит через порт 443. Общей шпаргалкой по необходимым открытым портам можно, как обычно, воспользоваться на этом замечательном ресурсе. Если платформа vRNI размещена позади прокси, следует разрешить такие домены:
- Для службы метрик и апгрейда: svc.ni.vmware.com;
- Поддержка службы туннелирования: supportni.vmware.com;
- Служба регистрации: reg.ni.vmware.com;
- Служба ведения журналов логов: log.ni.vmware.com.
Все – через 443-й порт.
Требования к «железу»
Рекомендованные значения IOPS установлены на уровне 7 500.
Поддерживаемые браузеры
В UI vRNI на ВМ-платформы можно попасть из Google Chrome или Mozilla Firefox последних двух валидированных версий. Альтернативно всегда есть доступ через CLI.
Уровни лицензий vRNI
Набор функций vRealize Network Insight весьма разнится от лицензии к лицензии. На данный момент их сравнительная таблица выглядит следующим образом:
Подготовка к инсталляции vRNI 6.2
Допустим, нами полностью рассчитан и спроектирован наш vRNI, удовлетворены требования из раздела «Требования и совместимость». Какой-то еще специфической подготовки инсталляция продукта не требует, разве что важно предварительно проверить компоненты среды и сетевое хозяйство (см. выше), которым и будем управлять, и нужно будет скачать отдельные OVA для платформы и коллектора отсюда:
Разворот vRNI 6.2
Схема процесса разворота нашего vRNI выглядит так:
Для начала импортируем OVA Platform в наш vCenter Cerver. Визард разворота шаблона проходится стандартно (правой кнопкой мыши на наш хост в инвентаре и в выпавшем меню выбираем разворот OVF-шаблона):
- «Select an OVF template». В нашем примере забираем предварительно выкаченную инсталляцию из локального хранилища (ставим флажок на «Local file» и нажимаем на кнопку «Upload files». После чего выбираем искомый в проводнике). «Next»:
- «Select a name and a folder». При желании называем как-то информативно нашу ВМ-платформы и выбираем ее местоположение. «Next»:
- «Select a compute resource». Выбираем наш вычислительный ресурс. «Next»:
- «Review details». Промежуточные настройки должны выглядеть как-то так:
«Next»;
- «License agreements». Ставим галочку. «Next»:
- «Configuration». Выбираем подходящий тип конфигурации, в зависимости от того, какова будет нагрузка на систему (см. теоретическую часть и раздел «Требования и совместимость» выше). «Next»:
- «Select storage». Выбираем хранилище флажком, после чего сверху – формат виртуального диска. «Next»:
- «Select networks». Выбираем сеть для нашей ВМ. «Next»:
- «Customize template». Здесь нам напоминают, что нужно будет вручную потом настроить Appliance. «Next»:
- «Ready to complete». В конце ревью должно выглядеть, примерно, так, с оглядкой на индивидуальную конфигурацию. «Finish»:
На скриншоте, как мы видим, выделена строка, где написано, что требуется ручная настройка Appliance через консольную машину. Для этого запускаем ВМ и консоль, заходим под учетной записью в нее и вводим команду «setup», чтобы сконфигурировать дефолтные пароли на аккаунт, а также сетевые настройки:
Вообще же, за инсталляцией платформы следует фундаментальный шаг валидации и активации лицензии. Затем генерируется общий секретный ключ и только после этого – инсталлируется OVA коллектора. В финале нужно будет зайти в vRNI и настроить источники данных, а также задать другую необходимую конфигурацию для нормальной работы продукта (об этом поговорим в следующем разделе). Для этого сначала в браузерную строку вводим «https://vRealize Network InsightPlatform IP address» – появится окно веб-интерфейса инсталлятора ВМ-платформы:
где нужно нажать на кнопку «Install». Появится мини-визард, в первом пункте которого – «Add License» – вводим наш лицензионный ключ и нажимаем на кнопку «Validate», чтобы проверить его. «Next»:
Далее в «Set Admin Password» вводим пароль администратора и повторяем его, после чего кликаем на «Activate»:
В «Add Collector VM» нужно сначала нажать на кнопку «Generate», чтобы сгенерировался общий секретный ключ (понадобится при развороте OVA ВМ-коллектора – пока этот ключ не настроен и ВМ самого коллектора не включена, она не обнаружится), а затем – на «Copy», для копирования его в буфер обмена:
«Finish» пока не нажимаем – нужно сначала создать ВМ-коллектора (снова через vCenter) и прописать в ней этот ключ.
Важно! Каждый раз при добавлении новой ВМ-коллектора, нужно опять проходить этот визард и генерировать новый ключ.
Через правую кнопку по нашему хосту в инвентаре vCenter Server запускаем процесс разворота нового OVF-шаблона, однако в качестве файла-инсталлятора выбираем уже тот, который соответствует коллектору:
Далее все полностью аналогично тому, что мы делали для платформы, до шага «Customize template»:
Скопированный ранее ключ вставляем в предназначенное для него поле и нажимаем на «Next»:
Проверяем, все ли грамотно назначили в «Ready to complete»:
И запускаем разворот по кнопке «Finish». После добавления этой ВМ, ее тоже включаем, заходим в CLI (все, как мы делали для машины-платформы), назначаем там пароли и сетевую конфигурацию.
Кстати, уже по окончанию разворота можно будет использовать команду «set-proxy-shared-secret» для изменения ключа в CLI коллектора:
Теперь в визарде регистрации коллектора он должен обнаружиться («<имя коллектора> detected successfully») и можно уже будет нажимать на кнопку «Finish»:
После чего нас перенаправит на страницу логина.
Интересно, что получить представление о том, нужен ли вам вообще этот продукт на практике, о его возможностях и том, как с ним работать, в самом базовом варианте можно и с помощью ознакомительной лицензии. С ней vRNI стартует в режиме оценки NSX, и можно добавлять разные источники данных (рассмотрим ниже), анализировать поток трафика, а также генерировать отчеты.
В режим «Full Product» всегда можно переключиться, если кликнуть в верхнем правом углу на «Switch to Full Product Evaluation».
Начальная конфигурация vRNI 6.2
После успешного разворота обоих типов нужных нам OVA и их сопоставления, нам стоит произвести начальную конфигурацию vRNI, чтобы был доступ к его, хотя бы, минимальному функционалу.
Добавление источников данных
В первую очередь нам следует добавить источники данных – начнем, естественно, с vCenter Server. Для этого заходим в UI vRNI, где на приветственной странице выбираем бокс «VMware vCenter», после чего в боковом меню под «Settings» ищем «Accounts and Data Sources» и заполняем все нужные поля, добавляя наш новый vCenter:
Здесь можно настроить распределенный свитч vSphere, чтобы он экспортировал потоковую информацию с использованием IPFX. Для этого ставим галочку в «Enable NetFlow (IPFIX) on this vCenter», после чего ниже появится блок для опционального выбора VDS:
Важно! Для настройки и использования IPFIX нужна учетная запись на vCenter Server по распределенному свитчу на уровне «Modify» и по «dvPort group» – «Modify». Также предустановленные роли на vCenter Server с привилегиями: System.Anonymous, System.Read, System.View и global.settings, – должны быть распространены на дочерние роли, назначенные на корневом уровне.
Добавление стартует после нажатия на «Submit» внизу. (Таких инстансов vCenter Server в vRNI можно добавить несколько).
Вообще же можно внести множество источников данных с целью их экспорта в vRNI. Для этого, также как и по vCenter Server, в «Settings» – «Accounts and Data Sources» нажимаем на «Add Source», после чего выбираем нужный источник из предложенного диапазона (от NSX-T Data Center до физических устройств):
В том числе и NSX-T Manager:
Важно! По NSX Manager в NSX-T-провайдере данных требуется роль уровня «Enterprise». Если включен CLI, для провайдера данных NSX Manager требуются учетные данные системного администратора.
Важно! Если управляющих нод в одном развороте NSX-T более одной, только одна добавляется как источник данных в vRNI. Либо же используется VIP для нод.
При желании включить сбор потока из NSX Intelligence ставится галочка в «Enable DFW IPFIX», а если выбрать «Enable Latency Metric Collection», будут получаться и метрики задержек, вроде VTEP – VTEP, vNIC – pNIC, pNIC – vNIC, vNIC – vNIC из NSX-T.
После настройки источников данных нужно подождать минимум два часа, пока можно будет использовать vRNI для анализа потоков в дата-центре. А чтобы получить исчерпывающий отчет – лучше опираться на собранные за целые сутки данные.
Создание кластера платформы
Кластера создавать можно прямо со страницы «Install and Support» нашего UI. В качестве подготовки к этому шагу помним, что предварительно обязательно нужно сделать бэкап нод платформы (по best practice выполнять это рекомендуется через vSphere Storage API – Data Protection). Всего нам понадобится, кроме начальной, минимум еще две дополнительные платформы – разворачиваем их и включаем по аналогии с первой. Далее кликаем на «CREATE CLUSTER»:
Важно! Операция кластеризации доступна исключительно для платформ с размером брика Large и Extra Large.
В материале про администрирование vRNI рассмотрим процедуры расширения уже имеющегося кластера.
Что еще можно сделать после инсталляции vRNI и его начальной настройки?
О большинстве аспектов использования и конфигурирования vRNI под различные нужды мы поговорим в деталях в нашей следующей статье из посвященного ему цикла. Сейчас же остановимся только на нескольких – опять-таки – стартовых аспектах интеграции этого продукта с упомянутыми нами выше в теоретической части другими произведениями VMware.
Добавление Tanzu Kubernetes Grid Integrated Edition в качестве источника данных
Можно добавить Tanzu Kubernetes Grid Integrated Edition как источник данных и в результате получать информацию о кластере непосредственно в vRNI. Эта интеграция позволяет получить представление о работе сети между контейнерами и виртуальной и физической инфраструктурой, а также планировать политики безопасности для микро-сервисов.
Чтобы приступить к этой интеграции нам нужны привилегии на уровне pks.clusters.admin, а также добавить соответствующий NSX Manager. После чего операция добавления Tanzu Kubernetes Grid Integrated Edition в качестве источника данных практически идентична тому, что мы делали ранее для прочих разновидностей.
Работа с мониторингом HCX Network Extension через vRNI
Добавление VMware HCX в качестве источника в vRNI позволит мониторить пропускную способность для L2-расширений HCX, осуществлять наблюдение над сетевым трафиком и анализировать его по расширениям HCX L2, а также траблшутить повышение задержки на приложениях там же. Вообще же VMware HCX – чрезвычайно интересный и полезный продукт, дающий доступ к миграциям без изменения IP, чисто через сетевые расширения.
Что ж, вот, пожалуй, и все, что хотелось рассказать сегодня о vRNI, в целом. Надеемся, с помощью нашего мануала вам удалось подготовить среду, успешно развернуть и предварительно настроить базис этого продукта. Пользуясь случаем, анонсируем следующие статьи из посвященного ему цикла: по администрированию и отдельно – по апгрейду с предыдущих версий на самую свежую. Если же возникли какие-то вопросы, хочется изучить предмет нашего обсуждения на продвинутом уровне, либо же интересует какая-то экзотика по проектированию и применению vRNI, добро пожаловать на авторизированные курсы VMware по нему, обращайтесь к комьюнити и сертифицированным консультантам сферы, либо же пишите в саппорт вендора.