vCNS

Tip de diseño – Dimensionamiento de vShield Edge

Que tal gente creo que la información que estaremos tocando en este articulo es de crucial importancia para un correcto dimensionamiento de un ambiente de vCloud o en el caso de estar utilizando vCNS en un ambiente vSphere. vShield Edge cuenta con 3 distintos tamaños para poder cumplir con distintos requerimientos, vamos a conocer que tamaños tenemos y en donde aplican cada uno de ellos. Es importante saber que aún cuando realicemos la entrega de algún tamaño en especifico, tenemos la opción de poder modificar posteriormente su tamaño.

Si realizamos la entrega de un appliance vShield edge a través de vShield Manager tenemos las siguientes opciones o tamaños de vShield edge:

tamañosedge

Y si lo comparamos en el caso de vCloud Director tenemos lo siguiente:

tamañosedgevcd

Básicamente en el caso de vCloud Director no contamos con el tamaño x-large, solo contamos con compacta y full que vendrían siendo compacta y large en vShield Manager. Pero… ¿Que diferencia existe entre estos distintos tamaños?

  • Compacta – Esta configuración o tamaño de vShield edge cuenta con 1 vCPU, 256MB de RAM y 512MB de Disco duro para almacenamiento de logs. Este tamaño esta pensado para un uso bajo en cuanto a ancho de banda y conexiones concurrentes se refiere, los casos de uso vendrían siendo VMs de bajo consumo en red o ambientes de lab/Desarrollo. Esta pensada para hasta 64,000 conexiones concurrentes y un throughput de <1Gbps. El uso de IPsec VPN o SSL VPN-Plus no es recomendado con este tamaño de apliance debido al overhead o la cantidad de procesamiento que se requiere para manejar dichas conexiones.
  • Large – Cuenta con 2 vCPUs , 1GB en RAM y 320 MB en disco para logs. Este tamaño o configuración esta pensado para soportar hasta 1,000,000 de conexiones con aproximado de 7Gbps y soporta el uso de SSL VPN-Plus y IPsec. Este es el tamaño que debemos de utilizar en ambientes productivos en vCD aunque no esta pensado para VMs con un tráfico excesivo.
  • x-large – Este tamaño de vShield edge cuenta con 2 vCPUs, 8GB en RAM y 320MB para logs. En este caso utiliza un sistema operativo de 64-bits a diferencia de large y compact. Este tamaño esta pensado para mas de 1,000,000 conexiones concurrentes pero no cuenta con soporte para SSL VPN-Plus. No esta soportado para vCloud Director.

Aunque no tengamos soporte por vCD para x-large, podemos realizar el “upgrade” o modificar el tamaño de nuestros vShield Edge desde la consola de administración de vShield Manager, claramente esto no esta soportado.

En la siguiente imagen podemos ver que tenemos 2 appliances de vShield Edge, ambas de tamaño “Large” estas fueron entregadas desde vCD 5.1:

applianceslab

Para poderlas llevar al tamaño x-large es tan simple como seleccionar el appliance en cuestión y hacer click en el menu de “actions” lo que nos permitirá seleccionar “Convert to X-large”:

conv-x-large

Entendiendo VXLAN

Que tal gente, el día de hoy vamos a hablar de algo que llegó para quedarse y que de seguro han estado o estarán escuchando en esta epoca, estaremos analizando de que se trata VXLAN y su arquitectura.

Antes que nada quiero dejarles claro que aunque dentro de VMware pertenezca a un grupo de SMEs para networking en lo absoluto me considero un guru ni nada por el estilo, así que si en algo podemos mejorar este articulo o si pueden descubrir un problema con el mismo les pido que puedan apoyarme con sus comentarios.

¿Que es VXLAN?

Bueno, creo que esta es la pregunta obligada… VXLAN por sus siglas en ingles Virtual eXtensible Local Area Network actualmente es un draft del IEEE (Internet Engineering Task Force) que ha sido desarrollado por varias compañias lideres como Cisco, Arista, VMware, Broadcom, etc. Básicamente se trata de un prótocolo de encapsulamiento para poder crear redes de L2 sobre L3, cada red de L2 creada se le conoce como un segmento de VXLAN que es identificado de los demas mediante un ID de segmento que esta constituido por 24 bits lo cual en teoría nos puede permitir crear hasta 16 millones de segmentos de VXLAN unicos lo que equivale al mismo numero de redes lógicas.

Encapsulación

en el caso específico de VMware, la encapsulación de los paquetes de L2 en L3 sucede a través de un módulo de kernel en conjunto con una vmknic (puerto de vmkernel) que hacen las veces de VTEP (Virtual Tunnel End Point)  la ip que es asignada al puerto de vmkernel es la que estará usando el VTEP, esto se vería de la siguiente manera:

vtep

Este VTEP se encarga de manejar toda la encapsulación y desencapsulación del tráfico de VMs que sucede en dicho host el VTEP encapsula el tráfico con el siguiente formato:

VXLAN + UDP + IP

Enviando el paquete inicialmente en un multicast y en comunicaciones conocidas como unicast aquí podemos ver el formato:

vlxan encap

Aquí podemos ver la información que se maneja en el encapsulado, esta constituida por lo siguiente:

  • Outer MAC DA – Básicamente la MAC address del destination address o quien estará recibiendo este paquete, en este caso se trata del VTEP donde se recibirán los paquetes para ser desencapsulados y después enviados como comunicación L2 a la VM en cuestión. Se trata del host ESXi que contiene la VM destino en la comunicación.
  • Outer MAC SA – Aquí estamos hablando del Source Address o el VTEP encargado de crear todo este paquete. A partir de donde se generó el paquete. Se trata del host ESXi que contiene la VM origen en la comunicación.
  • Outer 802.1 q – básicamente la VLAN de transporte para el paquete
  • Outer IP DA – IP del VTEP destino, host ESXi ejecutando la VM receptora del paquete en cuestión
  • Outer IP SA – IP del VTEP origen , host ESXi ejecutando la VM que esta enviando el paquete.
  • Outer UDP – Contiene el puerto origen, destino e información de checksum. El puerto origen es generado a partir de un hash del header que contiene el paquete ethernet interno (la información que se pretende enviar).
  • VXLAN ID – se trata de 8 bytes que contienen toda la información del VNI (VXLAN Network Identifier).

Flujo de información

Si consideramos el siguiente escenario:

  • VM1 “Base de datos”
  • VM2 “Aplicación”
  • VXLAN ID 100
  • Multicast Group 239.119.1.1

Y se precisa entablar una comunicación entre la VM1  y la VM2 que estan siendo ejecutadas en distintos hosts ESXi en un segmento de 192.168.1.x/24 comenzando esta comunicación desde la VM1 sucedería lo siguiente:

  1. ambos VTEPs se anuncian en el multicas group 239.119.1.1 a través de IGMP.
  2. La VM 1 envia un ARP para descubrir la MAC address de la VM2 (en el caso que esta sea desconocida) este ARP (broadcast) es encapsulado en un multicast con la información pertinente del VTEP y VNI donde se esta generando la información y es enviado al multicast group al que pertenece la L2 de la VM origen.
  3. Todos los VTEPs receptores verificarán de primera instancia el ID de la L2, desencapsulando el paquete en el caso que se encuentre una VM perteneciente a dicha L2 para que la información sea recibida por la VM.
  4. La VM2 en este caso ya recibió el ARP y lo responde a través de un unicast y el VTEP de la VM destino (VM2) entabla una comunicación directa con el VTEP de la VM origen (VM1)

Gráficamente se vería de la siguiente manera:

vxlan-com

Es importante notar que en este ejercicio no se consideró las IPs de los VTEPs por temas de simplicidad, al igual es importante saber que el multicast inicial solo se da en el caso que la tabla de ruteo del VTEP no contenga la relación entre MAC address de la VM destino con la IP del VTEP destino, una vez que esta información es agregada a la tabla de ruteo la comunicación se realiza de punto a punto.

¿Que hay de comunicación inter- VXLAN?

Utilizemos la siguiente imagen para poder entender los distintos casos:

inter

  • Escenario 1 – Todos los participantes en la comunicación se encuentran en un solo host ESXi, VM1, VM2, VM3 y vShield Edge.

En este caso en específico estariamos teniendo una comunicación en un mismo host ESXi, la comunicación sería enviada al gateway que es nuestro vShield Edge quien se encargaría de rutear entre ambos segmentos.

  • Escenario 2 –  VM1,VM2 (azul) y vShield Edge se estan ejecutando en el mismo host ESXi y la VM3 en otro host ESXi

En este caso estariamos teniendo comunicación que viaja a través de la infraestructura física, aquí estarían participando los distintos VTEPs y vShield Edge para rutear entre los distintos segmentos. Puede darse el caso que se trate de comunicación entre la VM1 y VM2 lo cual mantendría esto dentro del mismo host ESXi.

  • Escenario 3 – Todas las VMs se ejecutan en distintos hosts ESXi incluyendo a vShield Edge

Este es el caso más dificil debido a que aquí la información tendría que estar saliendo siempre a través de la infraestructura física para ser ruteada por vShield edge y regresar a al destino. Esto puede tener implicaciones muy grandes en cuestiones de diseño, debido a que si esto sucede entre datacenters, es posible que la información este viajando entre datacenters dependiendo de donde se coloca vShield edge lo que nos puede llevar a tener tromboning en la red.