¿Por qué deberías hacer el curso oficial de VMware NSX?

En esta oportunidad quisiera contarles que el viernes 12/9/14 completé los requisitos de mi training plan, lo que me habilita a partir de ahora a impartir el curso oficial VMware NSX: Install, Configure, Manage [v6.0].

Me pareció un curso estupendo, porque si bien había leído con antelación sobre el producto, no lograba que me quedaran bien claro los componentes del mismo y su gestión.

El curso es de mucha utilidad tanto para los responsables de la gestión como para los que deberán hacer el diseño, así como también para aquellos que desean conocer el alcance de las funcionalidades para poder sacar mejor provecho del producto.

Quisiera en este primer post hacer una introducción técnica de este producto que muy probablemente se convierta en un componente esencial en los Software Defined Data Center del futuro.

VMware NSX es el resultado de la compra de Nicira, una compañía pionera en el desarrollo de soluciones de Software Defined Networking (SDN). Para los que no lo saben, SDN está llamada a ser la forma de implementar y gestionar las redes en el futuro. Se basa en la estrategia de separar el control y la gestión de la red del hardware propiamente dicho. Y en NSX esas funcionalidades están perfectamente definidas por distintos componentes que son responsables de llevar a cabo funciones específicas con la agilidad y versatilidad a la que VMware nos tiene acostumbrados.

Tratar de explicar todos estos componentes y funciones en un solo post sería imposible, por lo que he decidido tratarlo en sucesivos post. En este post solo quisiera definir algunos conceptos y características para que la curva de aprendizaje sea más suave.

Versiones

Uno de las primeras características que debería quedar clara es que para la versión 6.0 del producto existirán dos versiones de NSX, uno para plataformas vSphere ESXi y otro para otras plataformas con otros hypervisores como Hyper-V o Linux KVM llamado Multi-Hypervisor.

En estas notas hablaremos principalmente de la primera versión.

Funciones

NSX agrupa una serie de funcionalidades muy importantes en el Data Center.

Es un switch. Pero no es un switch común, como los VSS o los dVS, es un switch de nivel 2 con esteroides, que permite separar el alcance del transporte a servidores que pueden estar separados por varios kilómetros, y más importante, que pueden estar conectados a través de redes de nivel 3 (es decir IP). Para aquellos novatos, este concepto puede ser confuso. ¿Cómo dos segmentos de una misma red de nivel 2 (una vlan) puede estar unida a través de una red de nivel 3? No es mi objetivo explicar en este post como se logra, sino en otro posterior. Para los más avanzados en cambio mencionar que no es ni más ni menos que una red overlay (un túnel) que puede lograrse mediante protocolos de encapsulamiento como VXLAN, STT o NVGRE.

Es un router (o más bien dos). Esta función que hasta ahora era llevada a cabo por un apliance físico, o por un virtual appliance de otro fabricante (por ejemplo Cisco CSR 1000v) ahora será una función nativa del NSX, que soporta protocolos como rutas estáticas, OSPF, IS-IS, o BGP. Pero lo más interesante es que ofrece dos clases de router. Una es una VM (o más si fuera necesario escalarlo) que actúa como un router de borde (o de distribución/edge si prefieren, o un End Of Row). Es decir un router que controlará todo el tráfico de nuestras VMs contra la red física, similar al router que nos conecta a Internet.

La otra clase, es un router distribuido (mismo concepto que un dSW, o un Top Of Rack) que permite que el Default Gateway (DG) de cada VM sea una interfaz  que se encuentra en el mismo host (atendida por un agente que ejecuta el VMkernel), y no en una VM que quizás esté en otro host, lo que obligaría a que el tráfico tuviera que ir hasta allí y luego volver (hairpinning).

El router de borde soporta más funciones que el router distribuido, como por ejemplo NAT.

NSX soporta tanto IPv4 como IPv6.

A continuación se muestra un esquema de los dos tipos de routers:

Se debe notar que el router distribuído consta a su vez de dos componentes, el control, que es una VM y los agentes, que son componentes de software (VIB) que corren en el hypervisor. Las interfaces de este router son lógicas (los DGs de las distintas subnets) y pueden ser  hasta 1000. Por el contrario, el router EDGE es una VM y sus interfaces son las clásicas vNics (hasta 10). Si necesitaran más redes/subredes en el EDGE podrían crear más VMs.

Veamos en el dibujo si por ejemplo, si la VM1 quiere enviar tráfico a la VM2 (tráfico Este-Oeste) que está en otra subnet, lo enviará a la dirección de su DG que es provista por el mismo kernel (en mi ejemplo 20.1 y 30.1). Se puede observar que esas direcciones están repetidas en cada uno de los host actuando como un router distribuído. También comparten la misma MAC virtual. Si la máquina migra a otro host, no notará la diferencia.

En cambio, si la VM1 quiere enviar tráfico a Internet pasará primero por el router distribuído (su DG) y luego por el router de perímetro (el EDGE router) para salir hacia afuera (tráfico Norte-Sud).

Es un bridge. Esta función permite conectar equipos físicos conectados a una VLAN tradicional heredada, con los segmentos L2 manejados por el NSX mediante la tecnología de overlay mencionada anteriormente, lo que nos permite tener conectividad de nivel 2 con la red heredada (legacy). En otras palabras, nos permite la conectividad de VMs conectadas a una VXLAN con equipos físicos conectados a un VLAN tradicional, donde ambos representan el mismo segmento.

Es un firewall (o más bien dos). Es un statefull firewall de nivel 3/4. Para esta función también tenemos dos clases de firewalls, uno de borde que controla todo el tráfico entrante y saliente entre las redes virtuales y la red física (llamado tráfico Norte/Sud), y un firewall distribuido que controla el tráfico entre las VMs. (llamado tráfico Este/Oeste). En este último caso, la solución también está basada en un agente que ejecuta cada host ESXi que forma parte del NSX. Este componente ya formaba parte de la solución vShield y en ese producto estaban bien diferenciados, porque uno era el vShield Edge (N/S), y otro era el vShield Zones (E/O).

Es un terminador de VPN. NSX ha heredado la funcionalidad del vShield Edge que incluía un terminador de túnel, para permitir proteger el tráfico Site to Site (o Lan to Lan), o bien permitir a los usuarios conectarse desde un hotel o su casa, es decir Remote Access.

Esta funcionalidad soporta el tradicional protocolo IPsec para el primer tipo de conexiones y también SSL para el segundo tipo. La solución puede usar una conexión clientless, en la que el usuario solo necesita un navegador que soporte SSL o TLS, o bien puede descargar el cliente e instalarlo de una forma muy sencilla, para luego proceder a conectarse, lo que le permitirá usar cualquier tipo de aplicación y no solo web based.

Es un balanceador de carga. Y como si todo esto fuera poco, ofrece servicios de balanceo de carga. De esta manera que el tráfico de los usuarios o aplicaciones puede ser distribuido entre múltiples VMs, permitiendo acelerar el rendimiento, al mismo tiempo que ofrece tolerancia a fallos, redistribuyendo el tráfico al resto de las VMs sobrevivientes en el caso de que una o más fallaran. El balanceador soporta dos clases de diseños, tradicionales en balanceadores de otros fabricantes, llamados One Arm y Transparent.

Otras características

Además de las características específicas mencionadas, la solución contempla como era de esperar, mecanismos de HA. Dicho mecanismo no está soportado ni por el HA ni por el FT de vSphere, sino, como es más tradicional en las soluciones de networking por la presencia de una segunda instancia de la VM que lleva a cabo una función, pero que está en un estado de standby. En caso de fallo de la primera instancia, entonces se produce el failover, que puede tardar unos segundos.

Como el plano de datos está separado del plano de control, este tipo de fallos puede no afectar en absoluto al tráfico, que seguirá siendo transmitido por los agentes hasta que el control se haya re-establecido. Distinto es el caso donde el tráfico pasa a través de un virtual appliance, en cuyo caso puede verse afectado por algunos segundos hasta que se produzca el failover y todo vuelva a la normalidad.

El management está integrado con el web-client. Ciertos componentes soportan interfaz por línea de comando (CLI), aunque principalmente para troubleshooting más que para configuración. Eché en falta el soporte de Radius o TACACS, en cambio el Role Based Access Control (RBAC) está apoyado solo para la autenticación por el servicio de Single Sign On (SSO) incluido en vSphere.

La otra forma de administración está basada en las APIs REST, componente fundamental para lograr que herramientas como el Cloud Manager, OpenStack y otras desarrolladas por terceros, sean las responsables de orquestrar los servicios de red necesarios para los Software Defined Data Centers.

La solución es escalable, ya que permite distribuir muchas de las funciones en VMs que son fáciles de crear. Los potentes procesadores de hoy en día, combinados con una cantidad adecuada de memoria RAM y placas de red de 10 Gbps superan con creces la velocidad de procesamiento de apliances por hardware con recursos de procesadores y memoria mucho mas limitados. Para más información acerca de los límites and throughput haga click aquí.

Sin embargo esta tecnología no reemplazará en forma inmediata a los tradicionales appliance físicos como firewalls, routers o balancedores de carga existentes en las organizaciones. Más bien creo que los departamentos TIC comenzarán a implementar esta solución en proyectos green field, es decir proyectos que comienzan de cero, probablemente no muy críticos, tal como ocurrió con la virtualización de servidores en un principio. A medida que los administradores de red vayan adquiriendo confianza y se vayan familiarizando con las herramientas de gestión, entonces comenzarán a utilizar cada vez más el producto, dado que la facilidad de implementación y los ahorros en el CAPEX y OPEX se harán más evidentes.

Como primera versión del producto creo que NSX es muy poderoso e incluye muchas funcionalidades. Creo que es un producto que hay que conocer y comenzar a probar cuanto antes. Poco a poco irá haciéndose habitual, y con el correr de los años reemplazará definitivamente a los tradicionales apliances físicos tal como los conocemos hoy.

Espero que esta nota haya sido de su interés. Los espero en la próxima para continuar explicando con más detalles la arquitectura y los elementos de este innovador producto, o mejor, los espero en alguna de mis clases.

Gracias por leer nuestro blog, participar y compartir.