Acropolis Hypervisor (AHV) es la respuesta de Nutanix a algo que no todos los fabricantes de infraestructura siquiera se hubiesen detenido a pensar: VMware ESXi es el líder de los hipervisores tipo I en la industria, pero puede contener más características de las que muchos clientes llegan a conocer: ¿sería posible construir un hipervisor que brinde una alternativa viable y soportada a ESXi con las funcionalidades necesarias?
Hubiese querido iniciar la exploración de Acropolis Hypervisor en orden pero bueno, el networking es un tema que siempre captura mi atención (después de todo, es quizá el campo más académico de la industria de IT); así que en éste post veremos algunos apartes sobre el esquema de redes que AHV entrega para las máquinas virtuales.
Open vSwitch
AHV implementa la conectividad usando Open vSwitch (OVS), que es un proyecto de código abierto respaldado por Linux Foundation y que busca desarrollar un switch virtual (creo que lo intuyeron ya) pensado desde su inicio para la automatización y programabilidad. Brinda muchas de las funcionalidades que un vSphere Distributed/Standard Switch entregarían pero con un enfoque abierto. Soporta características suficientes como para considerar su introducción en las empresas, o es mi conclusión al ver en la lista a:
- LACP
- STP y RSTP (si, aún no han muerto)
- NIC bonding
- IPv6
- IEEE 802.1Q support (VLANs para los más tradicionales)
- Protocolos de tunelamiento: GRE,STT, Geneve y …. VXLAN
¿Para qué VXLAN?
Bueno, quizá no soy la fuente más independiente para hablar de overlays, pues vengo trabajando con VXLAN hace unos años y escribiendo también (mi post al respecto ahora es una de las referencias en la Wikipedia!). Sin embargo y aunque no es para nada el único protocolo de tunelamiento, VXLAN es el que más ampliamente se ha implementado y cuenta con un amplio soporte por parte de fabricantes en el espacio de hardware y software de redes modernas.
VXLAN es, en resumen, el habilitador de la flexibilidad de redes capa 2 dentro del centro de datos y (proveídos algunos requerimientos sencillos) entre centros de datos remotos. Esto es grande, más grande de lo que muchos hemos entendido pues si las cosas salen como lo esperan el 70% de las compañias consultadas por IDC, la nube híbrida será el modelo más ampliamente implementado en un par de años. Y si quitamos del camino los demás factores de un proyecto de éste estilo, al final del día el aspecto que realmente hace que sea viable o no es precisamente la extensión de las funciones de red y las políticas y controles de seguridad desde las premisas del cliente hacia la nube pública. VXLAN no es necesariamente requerido para ello, pero agrega una eficiencia digna de la escala de la nube (webscale).
Por otro lado, hay al menos un túnel VXLAN en ejecución internamente en AHV y es utilizado para distribuir las respuestas a solicitudes DHCP en el IPAM (IP Address Management) interno.
¿Como funcionaría?
Lamentablemente, este es otro post teórico, por lo que todavía será sujeto de completa verificación en campo. Pero con la documentación en mano y una dosis de experiencia con VXLAN puedo aportar los siguientes apuntes:
- Actualmente OVS no soporta los aspectos multicast de VXLAN de los que, en todo caso, muchos fabricantes están tratando de alejarse; como es el caso de VMware con NSX y su soporte para Unicast desde las primeras versiones.
- El que OVS no soporte VXLAN Multicast crea una necesidad: establecer un plano de control. El mismo RFC 7348 indica que éste plano debe ser distribuido y no administrado centralmente. En AHV ésa labor la cumplen las CVM alojadas en cada nodo (vaya que hacen multitasking éstas VMs).
Me he tomado la libertad de usar la siguiente imagen de la Nutanix Bible en la sección 4.1.4. Networking para tratar de describirlo mejor.
Toda máquina virtual en AHV es conectada directamente a un puerto tap (como un puerto de escucha) que entra a ser parte del entorno OVS interno al que también está conectada la vNIC de la CVM (vnet0). El que se trate de un puerto tap me hace pensar que internamente, hay alguna forma de replicación o escucha de tráfico en ambas vías que debe ser el medio por el cual el CVM cumple su rol en la parte de redes frente a las VMs y las VMs hacen allí sus diferentes solicitudes al respecto.
Pero, ¿cuál es ése de rol de las CVM? Bueno, similar a como ocurre con el Controller Cluster de VMware NSX, las CVM actuarán como el plano de control “aprendiendo” ´y distribuyendo información de enrutamiento a todo el clúster Nutanix en el cual tengan alcance. Adicionalmente, deben ser las responsables de mantener y actualizar la tabla de Forwarding (entradas ARP) y distribuirla a todos los nodos. Por supuesto ésto crea ventajas pues con AHV no sería necesario desplegar un producto adicional para tener acceso a una red más controlada por software (siempre han sido definidas por software las redes) y habilita la flexibilidad y optimización propias de un overlay con VXLAN que tiene su plano de control distribuido.
Ideas finales
En caso que AHV soporte nativamente el protocolo de administración de OVS (OVSDB), entonces una integración adicional con los equipos de red físicos es posible y allí toda esa valiosa información de enrutamiento y forwarding sería aprendida y distribuida no sólo dentro del entorno virtualizado sino hacia la red física de transporte. Algunos fabricantes de hardware de red ya soportan éste protocolo, entre ellos Cumulus Networks que está haciendo un trabajo formidable en crear infraestructura abierta y escalable para redes de todos los tamaños. En caso que AHV no lo soportara, habría que considerar VMware NSX que desde sus inicios cuenta con ésta característica.
Conclusión
Estoy consciente que éste post no resuelve una pregunta que se haga todos los días, pero si se que muchos competidores de Nutanix apuntan al “complejo” modelo de redes de AHV como un punto negativo. Aunque no lo he descifrado en éste post para nada, consideré oportuno empezar la exploración de éste tema por el núcleo de todo que es OVS y VXLAN. Espero les sea de utilidad en alguna medida.
Saludos!