Vmware nsx t data center что это

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

VMware NSX

VMware NSX — это платформа виртуализации сети и обеспечения безопасности для программного ЦОД, делающая возможным создание и параллельное выполнение целых сетей на имеющемся сетевом оборудовании.

Содержание

Описание

В основе решения NSX лежит тот же принцип, что и в виртуализации серверов: у пользователя появляется возможность работать с физической сетью как с пулом логических ресурсов, которые могут использоваться и перераспределяться по требованию. Решение NSX воспроизводит программным способом всю сеть, включая сетевые службы уровней 2, 3 и 4–7 в каждой виртуальной сети. NSX предлагает распределенную логическую архитектуру для служб уровней 2–7. Службы инициализируются программным образом при развертывании виртуальных машин и перемещаются вместе с ними. NSX сегодня применяется в микросегментации, при которой используется компонент Distributed Firewall. [Источник 1]

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

Аналогия с VMware vSphere

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

Платформа VMware NSX включает в себя следующие компоненты:

NSX распространяет концепцию программного ЦОД на сетевую безопасность. Возможности виртуализации сети реализуют три важнейших аспекта микросегментации: изоляцию (отсутствие взаимодействия между несвязанными сетями), сегментацию (управляемое взаимодействие внутри сети) и безопасность с расширенными службами (тесная интеграция с ведущими сторонними решениями по обеспечению безопасности). [Источник 2]

Возможности

NSX оперирует собственными виртуальными сетями, которые инкапсулируют в себе физические сети средствами протоколов STT, VXLAN и GRE (как это делается мы уже писали вот тут). А компонент NSX Gateway выполняет функции моста для коммутации на уровне L2 и маршрутизации на уровне L3.

В качестве серверных гипервизоров в инфраструктуре NSX могут быть использованы решения VMware vSphere, KVM или Xen.

Есть два варианта развертывания решения:

На уровне гипервизора работают 4 компонента, так или иначе используемых NSX:

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

Достоинства

Основные преимущества VMware NSX:

Примеры использования NSX

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

Автоматизация также важна для DR. NSX интегрируется с инструментами оркестровки, такими как vSphere Site Recovery Manager (SRM), который автоматизирует переход на другой ресурс и DR. В сочетании с NSX SRM может использоваться для репликации хранилища, а также для управления и тестирования планов восстановления. SRM также интегрируется с Cross-VC NSX. Cross-VC NSX, представленный в NSX 6.2, обеспечивает логическую сеть и безопасность для нескольких vCenters, что упрощает обеспечение последовательных политик безопасности без необходимости ручного вмешательства. При использовании в сочетании с Cross-VC NSX SRM автоматически отображает универсальные сети через защищенные и восстановительные сайты.

Лицензирование и версии NSX

Согласно VMware, лицензия NSX Standard предназначена для организаций, требующих сетевой гибкости и автоматизации, и включает такие функции, как распределенная коммутация, распределенная маршрутизация и интеграция с vRealize Suite и OpenStack. Лицензия на среднюю лицензию NSX Advanced предлагает те же возможности как стандартная лицензия, а также микросегментация для более безопасного центра обработки данных и таких функций, как балансировка нагрузки NSX Edge и распределенная брандмауэр. Наивысшая лицензия NSX Enterprise включает те же возможности, что и расширенная лицензия, а также сетевые и безопасность через несколько доменов с помощью таких функций, как Cross-VC NSX.

В дополнение к этим лицензиям NSX клиенты VMware могут приобретать NSX-T и NSX Cloud. Выпущенный в феврале 2017 года, NSX-T предлагает управление сетью и безопасностью для фреймворков приложений, отличных от vSphere, нескольких распределений виртуальной машины на основе ядра (KVM) и сред OpenStack. NSX-T также поддерживает платформу Photon, программное обеспечение виртуальной инфраструктуры VMware для контейнеров. NSX Cloud принимает компоненты NSX-T и объединяет их с общедоступным облаком. Клиенты NSX Cloud имеют доступ к панели с несколькими арендаторами, которая интегрирована с VMware Cloud Services и может разрабатывать и тестировать приложения с теми же профилями сети и безопасности, которые используются в производственной среде. [Источник 4]

Источник

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

Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

Таблица отличий решений для сетевой виртуализации VMware NSX-T и NSX-V

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

Давайте взглянем на сравнительную таблицу двух версий решений VMware NSX, где собраны основные ключевые отличия:

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

Источник

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

В этом цикле статей мы начнем знакомиться с чудесным продуктом 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, а остальные решения мы просто рассмотрим вкратце:

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

Теперь перейдем от лирического вступления к тому из чего состоит 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

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

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

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 является ресурсом для различных сетевых сервисов, указанных ниже.

То есть все вычисления, связанные с вышеперечисленными сервисами, происходят тут. Виртуальные машины на «эджах» не исполняются. 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, то это:

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

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

Об авторе

Какой то инженер по виртуализации. В данном контексте это не особо важно. Вы же не за этим сюда пришли, верно?

Источник