¿Que es NSX? – parte 1

NSX

Que tal gente, el día de hoy les voy a hablar sobre algo que estamos escuchando todos los días (al menos yo :D) y es NSX. Debemos comenzar por entender ciertos términos antes de entrar de lleno a NSX para vSphere o NSX Multi Hipervisor, así que los invito a leer este articulo introductorio.

“Refresh” de redes a nivel de vSphere

Si tienen la costumbre de seguir este blog debe de ser porque ya manejan bien los temas de virtualización y comprenden que es virtualización,  vamos a repasar rápidamente como se maneja el tema de redes desde una perspectiva clasica de vSphere para tener los conceptos “frescos”

Screen Shot 2013-12-06 at 11.51.02 PM

Analizando esta imagen podemos notar que se trata de un vSwitch o switch standard de vSphere, como pueden ver en el host ESXi se tienen tanto el plano de “control” y el  plano de “I/O”, el acceso a la red externa se le entrega a las VMs a través de una tarjeta virtual de red o “vNIC” que a su vez se conecta a este plano de “I/O” del switch standard a través de un “portgroup” o grupo de puertos lógicos que existen en este vSwitch. El plano de I/O tiene salida al mundo externo haciendo uso de tarjetas físicas del servidor ESXi, estas tarjetas conectadas al vSwitch en cuestión son llamdas “vmnics”. Toda configuración y modificación en el caso del switch standard o vSwitch sucede en el host ESXi, por ejemplo, para agregar puertos para que las VMs tengan salida al mundo exterior debemos realizarlo desde el servidor ESXi.

Ahora revisemos el vDS, DVS o Switch Distribuido de vSphere, como podemos ver el principio básico de puertos lógicos, vmnics o tarjetas físicas conectadas al switch,Screen Shot 2013-12-07 at 12.12.38 AMgrupos de puertos o “portgroups” existen en este tipo de switch virtual, lo que cambia en cuanto a temas de arquitectura es que el plano de control reside en el vCenter Server, es decir, cualquier modificación que se quiera realizar a nivel de red tiene que ser hecha directamente en el vCenter para que esta se vea reflejada en los servidores ESXi que formen parte de este Switch Distribuido.

Existen otras ventajas y capacidades de un switch distribuido vs un vSwitch o switch standard, pero básicamente la diferencia principal reside en el tema de la arquitectura. Ambos switches proveen de una plataforma L2 para que las VMs o servicios de vSphere (vMotion, svMotion, FT, IP storage, etc) puedan comunicarse con el mundo exterior.

Es importante notar que la simplicidad de un vSwitch o DVS esta en todos los aspectos, es decir, es simple de configurar, de operar y realizar troubleshooting pero esta simplicidad también deja al descubierto muchas “desventajas” en contra de switches físicos o por ejemplo un switch Nexus 1000v (escribí entre comillas desventajas ya que dependiendo totalmente del ambiente y los casos de uso un vswitch o DVS podría ser perfecto y no representaría ninguna desventaja). Entre las desventajas  que un vSwitch o DVS se encuentra el no participar en STP, no se tiene un mecanismo de “mac learning” dinámico, etc. Cabe destacar que los switches distribuidos han mejorado bastante últimamente con el soporte para LACP, mucho mejor escalabilidad con VXLAN (vs VLANs), Net IOC….. etc.

La virtualización de redes con VSS o DVS es algo muy básico en comparación de la virtualización de redes con NSX (o alguna solución parecida), ya que NSX toca servicios de otras capas L3 – L7 mientras que los switches virtuales de VMware quedan solo en L2.

 ¿Que es NSX?

NSX es la evolución de lo que VMware adquirió a través de la compra de Nicira, NSX es una plataforma de virtualización de networking real, permitiendo tener un pool de redes lógicas qScreen Shot 2013-12-08 at 1.02.28 PMue se ejecutan sobre redes físicas (podría ser una sola red física) permitiendo así entregar de manera programática (a través de APIs) todos estos recursos para ambientes de “nube” (ese termino siempre me ha resultado algo ambiguo y muy de marketing) brindando conectividad L2 y L3 de manera distribuida y permitiendo sobre estas redes lógicas definir servicios de L4 – L7 que podrán ser asignados a las VMs.
Podrán pensar, “Esto suena muy parecido a lo que VCNS nos permite hacer” y lo entiendo, pero ¿Que les parece si mejor le damos un clavado a la arquitectura de NSX para que descubran que son dos distintos enfoques para virtualizar redes?, estaremos tocando poco a poco todas las capacidades que ofrece NSX en esta seríe de articulos.

Arquitectura de NSX

Antes que nada es importante notar que existen dos distintas ofertas de NSX, NSX for vSphere y NSX MH (multi hypervisor), en esta sección estaremos enfocándonos a NSX for vSphere y en un post futuro estaremos hablando sobre NSX MH.

Screen Shot 2013-12-07 at 3.25.28 PM

  • Data Plane – Aquí básicamente sucede el I/O en el caso de vSphere hablamos de un VDS o switch distribuido (estaremos revisando para NSX MH de que se trata), se instalan  módulos en el kernel del host ESXi y se tiene un “user world agent” en el mismo host (todo esto en cada host ESXi) que estará comunicándose tanto con el módulo de kernel como con la controladora para realizar tareas como aplicar cambios.
    También como pueden ver en la imagen tenemos algo que se llama “NSX Edge” este componente nos permite tener comunicación fuera de las redes lógicas de NSX, es decir, tiene la función de gateway hacia el mundo físico (tráfico “north-south”), de igual manera ofrece servicios de L4-L7 (balanceador, FW, etc) este componente esta derivado de vShield Edge en el caso de la versión de NSX para vSphere, estaremos revisando esto mas a profundidad en un articulo futuro.
  • Control Plane – Aquí podemos encontrar los controladores (que pueden formar clusters para temas de HA) los cuales contienen el “running state” (un ejemplo podrían ser las tablas de ruteo) y datos persistentes de configuración que envia NSX manager. Existen dos razones muy importantes del porque utilizar este esquema de controladores, la primera es que estos apoyan a los VTEPs (en el caso de VXLAN) para no necesitar multicasting, esto a través de tablas donde los controladores almacenan tanto los VTEPs disponibles como las MAC Adrresses que sirven estos VTEPs por lo que ya a través de unicast podemos tener VXLAN funcional. Otra razón importante es el Ruteo distribuido del cual estaremos hablando en un articulo futuro.

Screen Shot 2013-12-08 at 1.19.09 PM

  • Management Plane – Aquí encontramos el NSX  Manager, el cual nos permite configurar toda la solución de NSX for vSphere, por ejemplo, preparar VXLAN, entregar controladores,servicios de terceros, etc. NSX manager es un appliance virtual que importamos a través de un OVA.
  • CMP – Aquí encontramos las plataformas de gestión nube o “Cloud Management Platform” que permiten interactuar con NSX for vSphere, en este caso estaríamos hablando de vCAC y vCD, a través de las cuales podrían entregarse servicios bajo demanda a partir de un catálogo y que estos incluyan los servicios necesarios de red provistos por NSX.

Una imagen que me dejo claro como podrían estar colocados cada uno de los componentes de NSX es la siguiente:

Screen Shot 2013-12-08 at 1.29.58 PMAquí pueden ver los distintos clusters de computo donde se encuentran en cada host ESXi instalados los módulos de kernel para poder tener servicios distribuidos de L2 y L3, y también podemos ver que tenemos como en cualquier ambiente bien diseñado un cluster de infraestructura o gestión donde estarían todos los appliances como los controladores, vCenter y NSX manager, por último tenemos algo que se le conoce como “Edge Racks” los cuales estarían permitiendo que el tráfico que viaja de intra cluster (“EastWest Traffic“) pueda salir al mundo exterior a través de los NSX Edges.

Estén atentos a la serie de artículos de NSX donde estaré hablando sobre distributed routing,Firewall, temas de ruteo dinámico (OSPF/BGP) y otros mas.

 

 

Leave a Reply