Что такое NSX-T?

vladimir NSX

В этом цикле статей мы начнем знакомиться с чудесным продуктом NSX-T. Этого момент я ждал долго, а кнопка NSX в моем блоге не имела никакого вывода до сего момента. Итак, что же это за продукт и для чего он нужен? NSX это решение для виртуализации сети в вашем ЦОД. Обычно мы имеем пачку хостов ESXi, которые умеют обращаться с сетевым трафиком на уровне L2, то есть тегировать кадры и принимать из физического мира VLAN-ы и доставлять их до виртуальных машин. Да нам доступны функции базового Firewall на VDS, а ESXi понимают IP адреса виртуальных машин и видят их в трафике, но это и в принципе все, основная сетевая «движуха» происходит на наших роутерах, фаерволлах, всевозможных навороченных коммутаторах и прочих вендорных железках, которые конечно функциональны и прекрасно справляются со своими обязанностями, но не лишены недостатков любого физического оборудования. Например, любой высоко функциональный роутер с функциями NGFW ограничен своим железом, пропускной способностью портов, и небезграничными функциями его OS. Со временем его железо станет не таким производительным по сравнению с новыми моделями его конкурентов, его OS не сможет проделывать какие-нибудь новомодные финты с сетевым трафиком, да и на обслуживание его периодически нужно будет останавливать. В общем налицо все те же ограничения, присущие любой физической машине, которые исключает виртуализация. Ну и стоит помнить, что что бы трафику пройти обработку на железном оборудовании, ему (трафику) нужно на это оборудование прибыть, загружая каналы связи, даже если ему (трафику) после обработки (маршрутизации или ACL) нужно будет потом лететь на тот же самый хост ESXi, к примеру, на машину, расположенную в другом VLAN, но на том же самом гипервизоре.

Теперь давайте взглянем на мир виртуальных сетей. Где базовые операции маршрутизации и фаерволла трафик проходит, не выходя в физический мир. На каждом хосте в инфраструктуре работает свой фаерволл и маршрутизатор. И трафик наших машин не бежит по каналам связи до ядра, чтобы маршрутизироваться, а делает это на хосте и затем летит физически туда, куда ему нужно, не делая крюков в инфраструктуре. Целевая идея виртуальных сетей NSX – предоставлять сетевые функции там, где это нужно. Так повелось, что практически везде нас поджидает архитектура x86, будь то вычислительные мощности, системы хранения данных или сетевое оборудование. Конечно не прям везде и всюду, но пока что она явно лидирует. Да сейчас происходит становление ARM и появившийся недавно во flings ESXi для ARM прямое тому подтверждение, но пока что этот процесс только запущен, а мы возвращаемся к x86 и к тому, что VMware чудесным образом использует ее в пределах одного хоста для предоставление вычислительных ресурсов (vSphere), а также распределенного хранилища (vSAN) и сети (NSX). И эта концепция определяет, что такое Software Defined Data Center.

NSX-T это не только средство виртуализации сетей у вас в ЦОДе. Помимо «наземного» использования этого продукта, есть возможность «дотянуть» ваши сети до публичных облаков, среди которых — VMware Cloud on AWS или Microsoft Azure Cloud. В облаке можно также развернуть NSX, только это будет «облачный» NSX Cloud. Его архитектура и компоненты будут слегка отличаться от «наземного». Но он обеспечит тот же уровень микросегментации и безопасности, что и обычный. Главная причина использования Cloud NSX – это что бы приложения и службы в облаке были оснащены теми же инструментами защиты и подчинялись тем же политикам, что «наземные».

Портфолио продуктов NSX

Сам NSX-T является большой частью семейства Virtual Cloud Network продуктов, которое включает помимо него другие решения в области виртуализации сети (SD-WAN так далее). Но так как остальные продукты вне данного цикла, мы фокусируемся на NSX и посмотрим из каких решений он состоит.

Как видим на картинке, сам NSX не ограничивается только NSX-T Data Сenter. Присутствуют и другие решения, которые могут быть как частью NSX-T Data Center, так и являться отдельными объектами, которые интегрируются между собой, или полностью независимы. Напомню, что цикл по NSX-T Data Center, а остальные решения мы просто рассмотрим вкратце:

  • NSX Data Center – главный герой нашего цикла.
  • NSX Cloud – про него упоминалось выше, разворачивается в облаках и дает возможность объединить облачные и наземные сети в одну инфраструктуру и подчинить одним политикам.
  • NSX Intelligence — это решение для распределенной аналитики, которое обеспечивает прозрачность и динамическое применение политик безопасности для сред NSX-T Data Center. Да-да маркетинговые слова, а если вкратце, то это аплайнс, который можно развернуть и интегрировать с NSX-T. Используется для аналитики и «подсказок», где что улучшить в инфраструктуре виртуальных сетей.
  • Распределенный IDS / IPS NSX — это усовершенствованный механизм обнаружения угроз, специально созданный для обнаружения угроз в сетевом трафике в инфраструктуре NSX.
  • NSX Advanced Load Balancer – отдельный продукт. Является очень функциональным сетевым балансировщиком нагрузки с кучей навороченных функций, например, динамическое увеличение вычислительных ресурсов балансировщика при увеличении подключений.  
  • NSX Service Mesh обеспечивает обнаружение и безопасную связь микросервисов в гетерогенной инфраструктуре.
  • VMware HCX обеспечивает гибкость и мобильность приложений и сетей.

В дополнение, вся эта «шайка» может интегрироваться с инструментами мониторинга и автоматизации из семейства vRealize:

  • vRealize Network Insight Cloud (SaaS) и vRealize Network Insight
  • vRealize Automation
  • vRealize Operation Manager

Теперь перейдем от лирического вступления к тому из чего состоит NSX и как он работает. NSX это достаточно сложный продукт с множеством компонентов и технических возможностей. И для того что бы освоить его нужно быть знакомым с vSphere и вообще с концепцией и принципами виртуализации, а также что немаловажно — неплохо знать сеть и сетевые протоколы. Некоторое время назад NSX делился на два независимых продукта – NSX-V и NSX-T. NSX-V был заточен под vSphere и исключал использользование других гипервизоров и платформ, управлялся из vСenter, но сейчас его жизнь прекращается и в скором времени он будет упразднен. NSX-T это мультиплатформенный NSX, имеющий независимую консоль управления и не требующий vCenter. NSX-T может охватывать как vSphere так и KVM в одну фабрику. Если сравнивать эти два продукта (V и T), то NSX-T значительнее сложен и функционален. Продукты отличаются технически во многих аспектах, но принципы работы у них одинаковые. В данном цикле мы будем говорить о NSX-T.

Архитектура NSX-T Data Center

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

Архитектура управления NSX-T

Управляется вся эта махина с помощью:

  1. Management Plane
  2. Control Plane
  3. Data Plane

Management Plane – является точкой входа для запросов пользователей, принимает конфигурацию, заданную пользователем, API запросы. На уровне Management Plane пользователь или другая система через REST API взаимодействует с NSX-T и «говорит» что ему нужно, далее Management Plane комплектует полученное в более технический «вид» и передает на Control Plane. Располагается на NSX Manager-е. Отказоустойчивость ему обеспечивает NSX Manager Cluster.

Control Plane – получает от Management Plane конфигурацию, запросы, структурирует их и затем передает для исполнения на Data Plane. Control Plane разделен на Central Control Plane (CCP) и Local Control Plane (LCP). Это разделение значительно упрощает работу CCP и позволяет платформе расширяться и масштабироваться.

Management Plane и Central Control Plane живут на NSX Manager. Local Control Plane располагается на гипервизорах и Edge нодах, он получает от CCP конфигурацию для своего гипервизора или эджа, а затем «инструктирует» нижележащий Data Plane что нужно делать. В NSX-V для CP разворачивался отдельный аплайнс и затем он резервировался кластером из трех нод. В NSX–T CP разделился на CCP и LCP, CCP же как сказано выше расположен на NSX Manager-е и его отказоустойчивость обеспечивается NSX Management Cluster-ом.

Каждый NSX Manager в Management Cluster-е имеет в себе по CCP Conroller-у, которые работают совместно и делят между собой управление Транспортными Нодами и типы конфигурации этих нод.

И если вдруг один NSX Manager с Controller-ом на борту в кластере вдруг упадет, то оставшиеся участники кластера распределят управление «осиротевшими» Транспортными Нодами между собой.

Data Plane – живет у нас на Транспортных Нодах (ТН это гипервизоры и Edge ноды, подготовленные для NSX-T) и занимается простой машинной работой по обработке сетевых пакетов, ему и невдомек о существовании пользователей и всякого «высокого», его мир – это фреймы, заголовки и данные в них, а так же куча всяческих утомительных инструкций, переданных «прорабом» Local Control Plane.

Физическая архитектура NSX-T

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

  • NSX Manager
  • Transport Nodes
  • Edge Nodes

NSX Manager

NSX Manager – консоль управления нашего NSX. Это полноценный аплайнс, который вы разворачиваете на гипервизоре и который служит для управления всем NSX. С его установки и начинается процесс развертывания NSX в инфраструктуре. С ним взаимодействует пользователь через web-интерфейс, CLI, API и так далее. Может и должен собираться в отказоустойчивый кластер из трех Manager-ов с виртуальным IP.

На NSX Manager околачиваются Management plane и Control plane, о которых мы говорили выше. Причем они претерпели некоторые изменения по сравнению с классической версией. Management Plane обзавелся компаньоном – Policy Plane, который расположен выше по иерархии. По сути эти две сущности являются одним и тем же, они предоставляют конечному пользователю интерфейс для взаимодействия и «понимают» его хотелки. Так в чем же их различие и зачем нужен этот Policy Plane? Policy Plane – это центральный интерфейс который принимает от пользователя простые запросы без определения что для их достижения нужно сделать. А management plane получает от него конфигурацию и определяет, что нужно сделать, проталкивает конфиги в Control Plane. Интерфейс NSX Manager-а может представляется администратору в двух режимах – policy/manager, отсылая нас к вышеупомянутым плейнам.

Так же у нас есть на борту у каждого NSX Manager-a База Данных, которая реплицируется между участниками кластера.

Transport Nodes

Транспортные Ноды. Это наши гипервизоры – ESXi и KVM, а также Edge Nodes (про них потом). В процессе развёртывания NSX гипервизоры добавляются к NSX. На них устанавливаются соответствующие пакеты, которые делают возможным распределенную обработку сетевого трафика виртуальных машин. Как мы писали выше NSX-T может работать как c ESXi так и с KVM, а так же и с физическими серверами — RHEL, CentOS, Ubuntu, SLES, Windows (да-да, на них ставится специальный агент и они так же могут быть добавлены в NSX как и гипервизоры). Транспортные Ноды после установки необходимого ПО NSX Manager-ом, умеют делать следующие вещи:

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

На этом заканчиваются умения Транспортной Ноды, но не всего NSX. Весь остальной функционал работает на Edge Node (это тоже транспортные ноды, но они «другие»J). Транспортные Ноды после добавления в NSX образуют Транспортные Зоны (это новое понятие о нем позже), в пределах которых и существует виртуальна сеть.

Теперь снова немного о Control Plane и Data Plane. CCP у нас тусит на NSX Manager-е и регулярно получает конфиги от Management Plane, формирует их в более машинное представление и через APH (Appliance Proxy Hub) и далее по протоколу NSX-RPC пуляет на Транспортные Ноды по сети, где NSX-Proxy ловит их и передает на Lосаl Control Plane. LCP это своего рода филиал CP на транспортных нодах, он записывает поступившую информацию в местную БД, под названием NestedDB, это не персистентное место хранение конфигов и после перезагрузки хоста оно пустеет, это скорее временное место куда помещается информация для Data Plane. Он (DP) получает указания от LCP и занимается непосредственно обработкой трафика – делает возможным логический свитчинг, роутинг и файрволл.

Для того что бы все это заработало, NSX-у нужно иметь на Транспортной Ноде управляемый виртуальный коммутатор. NSX-T предоставляет свой «брендовый» N-VDS, который устанавливается на Транспортную Ноду в момент добавления ее к NSX. Что касается vSphere 7.0, то есть возможность использовать для NSX-T 3.0 и новее обычный VDS. Но он должен быть не ниже 7-ой версии.  Соответственно у нас должна быть вся инфраструктура vSphere не ниже 7-ой версии. Для всего остального, а это vSphere 6.7 и старше, KVM — мы используем N-VDS.

Edge Nodes

NSX Edge по сути является такой же Транспортной Единицей как и ESXi или KVM хост, но я выделил ее в отдельный топик, потому что Edge является ресурсом для различных сетевых сервисов, указанных ниже.

  • SNAT/DNAT
  • Reflexive NAT
  • Пограничный брандмауэр
  • DHCP Server/Relay
  • L2 VPN
  • IPSec VPN
  • Балансировщики нагрузки
  • DNS Relay
  • Маршрутизация пограничного трафика

То есть все вычисления, связанные с вышеперечисленными сервисами, происходят тут. Виртуальные машины на «эджах» не исполняются. NSX Edge является вычислительным горлышком, через которое сетевой трафик покидает виртуальную сеть или входит в нее из вне. Выходя из аплинков «эджа», сетевой трафик покидает NSX и попадает в реальный мир.

NSX Edge может быть развернут как виртуальный аплайнс или физический сервер. Edge является своего рода гипервизором, но только для сетевых сервисов. В виде виртуальной машины наш эдж может пользоваться всеми прелестями отказоустойчивости и гибкости, но немного теряет в производительности. Будучи физической машиной, эдж может стать производительным «молотильщиком» трафика. Эджи так же можно собирать в кластер до 10 штук, для организации отказоустойчивости сервисов и увеличения пропускной способности. Кластера могут работать в режимах active-active и active-standby. Для базового роутинга нам отлично подойдет первый вариант, который увеличит пропускную способность нашей виртуальной сети в мир с помощью ECMP, а если нам нужны различные statefull сервисы типа NAT или балансировщики нагрузки, пограничные файрволлы, VPN и так далее, то наш выбор это active-stanby. Почему так мы разберем дальше по циклу.

Логическая архитектура NSX-T

Это самая комплексная часть, которая собственно представляет собой архитектуру виртуальной сети. Стоит запомнить, что большинство объектов в NSX-T являются логическими. Это логический роутер, логический свитч и так далее. Хотя в современном NSX-T в контексте Policy mode названия этих сущностей изменили, в большинстве случаев при чтении документации или в разговоре вы будите встречаться с этими понятиями.

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

Если вкратце взглянуть на логическую архитектуру NSX-T, то это:

  • Сегменты или логические свичи
  • Tier1 и Tier0 маршрутизаторы/логические роутеры
  • Балансировщики нагрузки
  • Распределенные и пограничные брандмауэры
  • И много всего…

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

Итог

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