HPE entre los líderes de almacenamiento de Gartner
La virtualización de servidores es una realidad en los data centers, creciendo día a día. El aspecto económico está firmemente detrás de esta tendencia. La virtualización de servidores reduce el costo total de propiedad al reducir el número de servidores físicos, requiriendo menos enfriamiento y menos energía a la vez que se incrementa la flexibilidad. Esto es muy bueno para el negocio y el grupo de servidores, ¿pero qué efecto tiene en la administración de la red? La verdad es que la complica.
Hay dos grandes problemas de red asociados con la virtualización de servidores. El primero es configurar las LAN virtuales. Los administradores de red necesitan asegurarse de que la VLAN utilizada por la máquina virtual (VM) está asignada al mismo puerto switch que el servidor físico corriendo la VM.
Una solución es que el grupo de virtualización de servidores le diga la equipo de administración de red cada posible servidor en el que la VM puede iniciarse y preconfigurar los puertos switch. Esta no es una solución perfecta porque puede causar que la VLAN sea definida en un muy gran porcentaje de los puertos switch. Se puede volver más complicado porque el grupo de servidores puede no estar al tanto de todos los servidores en los cuales se pueden iniciar las imágenes, especialmente durante una situación de recuperación cuando están tomando medidas de emergencia.
El segundo problema es asignar QoS y hacer cumplir las políticas de red, tales como listas de control de acceso (ACL, por sus siglas en inglés). Tradicionalmente esto se hace en el switch de red conectado al servidor que corre la aplicación. Con la virtualización de servidores hay un switch de software corriendo bajo el hipervisor en el servidor físico -no el tradicional switch de red físico que conecta con el servidor físico.
Aún es importante que se haga cumplir la política en el switch de software. Por ejemplo, si a dos VM ejecutándose en el servidor no se les permite comunicarse entre sí, alguien que gane control de VM1 podría abrir conexiones a VM2 y robar sus datos. Si el switch de software en el servidor aplica ACL, entonces esto podría ser bloqueado.
Antes de la virtualización, esto se prevenía porque las aplicaciones en VM1 y VM2 corrían en diferentes servidores y las ACL definidas en el switch de red prevenía la comunicación. Tener políticas aplicadas en el switch de software mantiene la seguridad. El problema es cómo lograr que el software aplique las políticas.
Superar estos dos retos es crítico para hacer que la virtualización de servidores funcione sin problemas. Hubiera sido estupendo si la comunidad de fabricantes hubiera creado un estándar uniforme que funcionara con todos los diferentes proveedores de virtualización. Como sucede normalmente con la nueva tecnología que está creciendo rápidamente, esto no sucedió. La industria ha implementado cuatro formas de atender estos problemas.
La solución del fabricante de virtualización
El fabricante de virtualización líder del mercado es VMware, pero existen muchas otras soluciones de virtualización incluyendo Zen de Citrix, Hyper-V de Microsoft, KVM y ofertas de muchos otros fabricantes más pequeños. Como las soluciones más ampliamente disponibles son de VMware, éstas serán utilizadas como ejemplo.
vCenter de VMware controla el proceso de virtualización y dirige dónde se inician las VM. El hipervisor controla el servidor y las VM corriendo sobre el servidor físico. VSwitch es una Capa 2 de software provista por VMware. Cada VM tiene un NIC virtual, etiquetado vNIC. El vNIC utiliza una dirección MAC de, ya sea del fondo de direcciones MAC del fabricante de virtualización, o una creada y asignada por la empresa.
El primer paso es para el grupo de servidores, que debe definir todas las características de red y las políticas para las máquinas VM. El operador le dice a vCenter que inicie VM2 en el Paso 2. Este proceso incluye múltiples mensajes entre vCenter y el hipervisor en el servidor, uno de los cuales empuja la información de políticas de red al hipervisor. En el Paso 3, el hipervisor configura el vSwitch con la correcta información de VLAN, QoS y políticas. Cuando la aplicación en VM2 empieza a enviar paquites, la política es aplicada en el vSwitch, representado por el punto azul.
Esto resuelve el problema de aplicar políticas en el primer switch, pero no resuelve el problema de configuración de VLAN en el switch de red. Los grupos de virtualización necesitan decirle a la administración de la red que configure la VLAN en el puerto del switch antes de que la VM empiece a enviar tráfico, lo cual requiere una coordinación rápida o que el switch sea preconfigurado. La coordinación puede volverse más complicada cuando el grupo de virtualización mueve la VM al vuelo. Luego el grupo de virtualización necesita coordinar con el grupo de red a medida que mueve el servidor, y el grupo de red necesita limpiar la configuración en el viejo switch después de un movimiento exitoso.
Una de las más grandes preocupaciones con este enfoque es la cantidad de coordinación requerida entre los grupos de virtualización y de red. El grupo de virtualización debe configurar parámetros en vCenter que son controlados por el grupo de red, tales como números de VLAN, QoS y ACL. Esto significa que se requiere una buena coordinación constante entre el grupo de virtualización de servidor y el grupo de red. Cualquier cambio en VLAN o políticas, debe ser inmediatamente reflejado en la configuración del servidor virtual, lo cual introduce otro posible punto de falla.
Otra preocupación es la falta de visibilidad de lo que está sucediendo dentro de un componente de red, el vSwitch, para el grupo de networking. El vSwitch está bajo el control del vCenter, no del tradicional software de administración de red. Adicionalmente, el equipo de administración de red tiene poca visibilidad hacia la VM. Este problema de visibilidad ha sido atendido por varios fabricantes de redes haciendo que vCenter notifique al equipo de red de los cambios o de la consulta por cambios, y luego despliegue esta información junto con los datos tradicionales de red, lo cual ayuda grandemente con la determinación del problema.
Primera respuesta
Blade Networks tiene actualmente una aplicación que corre en su switch, y el próximo lanzamiento del sistema operativo Force10 atiende el problema de la VLAN. Los switches consultan a vCenter en busca de algún cambio, o escucha alternativamente a vCenter por si envía un mensaje anunciando un cambio. Si el switch encuentra algún cambio, automáticamente realiza la configuración. El operador de virtualización no tiene que coordinar el cambio con la operación de red, permitiendo que el lanzamiento de la VM ocurra suavemente. El intervalo de consulta sí necesita ser más pequeño que el tiempo que le toma iniciar una VM, para asegurarse de que el switch vea el cambio lo suficientemente rápido. En el primer lanzamiento de Force10, el único parámetro que monitorea es la VLAN. Blade Network va más allá al aplicar también la gama completa de políticas en el switch de red basado en el vNIC o la UUID de la VM. Esta solución aún requiere que las políticas sean implementadas en el vSwitch.
La segunda forma de resolver el problema de configuración es con software de orquestación de fabricantes como HP y Juniper, que funcionan en sus propios switches. También hay soluciones de proveedores de soluciones de gestión tales como Scalent y CA. En este caso, el software de orquestación habla tanto al switch de red como a vCenter, y coordina los cambios en la configuración entre los dos ambientes. Este enfoque tiene el beneficio potencial de ser capaz de trabajar con un amplio rango de fabricantes de switch y virtualización.
La respuesta de Cisco
Cisco provee su propia solución de switch de software para reemplazar vSwitch llamada 1000V. Hay dos componentes en 1000V. El VSM es el Módulo de Switch Virtual y reemplaza el software vSwitch corriendo dentro del hipervisor. El Administrador de Elementos Virtuales (VEM, por sus siglas en inglés) es donde se configuran y almacenan las políticas de red para el VSM.
El gráfico muestra cómo funciona el proceso. Las VLAN y políticas de la VM se configuran primero basadas en la UUID de la VM o direcciones vMAC en el VEM. VCenter inicia una nueva VM o mueve una VM en el Paso 2. El hipervisor informa al VSM en el Paso 3. Entonces el VSM recupera la información de políticas del VEM en el Paso 4. Si el switch de red es de la línea de producto Nexus, también recupera la información necesaria de VLAN y políticas del VEM. En este punto tanto el switch en el hipervisor como el switch Nexus tienen toda la información correcta de cómo manejar VM2. Cuando VM2 empieza a enviar tráfico, todas las políticas correctas están aplicadas en el switch 1000V en el hipervisor.
Los beneficios del enfoque de Cisco son los mismos que con el primer enfoque. Bloquea cualquier comunicación entre las dos VM si no está permitida, y aplica las políticas apropiadas la primera vez que el tráfico llega a un switch. Si el 1000V es utilizado con el switch Nexus que está listo para la virtualización, resolverá el problema de la VLAN en el switch de red. Tiene el beneficio adicional de mover el switch en el hipervisor bajo el control del software de administración de red, regresando la clara responsabilidad al grupo de red. Hay desventajas. Actualmente Cisco solo tiene una solución para VMware y no para Xen o HyperV.
La cuarta forma
El cuarto enfoque toma una visión centrada en el equipo de red; vea la Figura 3. En el Paso 1, la VM es definida en el software de administración de red por su NIC virtual. En el Paso 2, vCenter dirige al hipervisor para que inicie la VM. El hipervisor envía un paquete de anuncio reportando que está iniciando la VM2 en el Paso 3. El anuncio tiene el vNIC y la UUID del VM2. En el Paso 4, el switch ve el anuncio y envía una solicitud por su VLAN y otra información de políticas. Entonces el switch aplica las políticas a cualquier tráfico que ingrese a la red.
El punto clave es que el switch solo aplica la política en el switch de red, mostrado por el punto azul, y no en el vSwitch. El switch también monitorea los mensajes del hipervisor que indiquen que la VM se ha movido, y luego remueve la VLAN y la información de políticas asociadas con el vNIC. Los proveedores que emplean esta solución incluyen Arista Networks, Blade y Enterasys, junto con HP y Juniper a través de su enfoque de orquestación. Otros fabricantes tales como Brocade planean ofrecer esta solución. Extreme Networks utiliza esta técnica para QoS y políticas, pero no para VLAN.
Este enfoque trata de quitar la necesidad de involucrar al grupo de virtualización en hacer cumplir las políticas de red. Sin embargo, aún hay dos problemas. El primero es que la virtualización de servidor y los grupos de red aún deben coordinar los números de VLAN. Actualmente, Enterasys tiene la habilidad de proveer automáticamente al vSwitch con el número de VLAN, con Arista planeando añadirlo a corto plazo.
El mayor problema con este enfoque es que no aplica políticas en el vSwitch, permitiendo así el tráfico entre VM en el servidor para eludir las ALC y otras políticas de seguridad. Enterasys y Arista planean superar este problema añadiendo la habilidad de impulsar las políticas hacia el vSwitch, mostrado por la A en el diagrama.
Una forma futura de superar este problema es permitiendo “curvas muy cerradas” en el switch. Con las curvas cerradas, el vSwitch es configurado para enviar todo el tráfico, incluso el tráfico de VM1 y VM2, directamente al switch de red. Entonces, el switch de red aplica las políticas y asigna QoS. El tráfico de VM1 a VM2 sería enviado de vuelta al vSwitch, el cual lo entrega luego a la VM2.
Esto haría al vSwitch un switch “tonto” con solo un rol de envío hacia adelante. El problema es que 802.1D, el estándar de enlace en el que todos los switches de Capa 2 están basados, no permite que el tráfico que viene desde un puerto sea enviado de vuelta por el mismo puerto por el que vino. Por tanto, bajo las reglas actuales el switch de red no podría regresar el paquete de VM1 dirigido a VM2 ya que rompería esta regla. Esto fue añadido para prevenir que se formen ciclos continuos. El IEEE está trabajando en una revisión de 802.1D que permita al switch realizar curvas cerradas y está en camino trabajo adicional que estandarice el switch tonto en el hipervisor. Cuando esto se generalice atenderá el problema y tendrá el beneficio de quitar la mayoría de la coordinación entre los grupos de red y de servidor.
Enterasys actualmente tiene una solución alterna que dirige el vSwitch para poner cada VM es una VLAN separada. Ellos seleccionan números de VLAN que actualmente no están siendo utilizados para prevenir cualquier problema potencial. Ya que las VM están en VLAN diferentes, no se pueden comunicar entre sí. Cuando el paquete llega al switch de red, el switch reemplaza los números de VLAN con el número real asignado a la VM, haciendo que aparezca ante la red y su destino como si siempre hubieran estado en la VLAN correcta.
Conclusión
Hay otro problema de configuración de VLAN que las técnicas esbozadas arriba no atienden. Cuando un nuevo número de VLAN es asignado a un puerto, necesita estar conectado a todos los otros puertos con ese número de VLAN. Esto requiere que todos los switches de agregación que están en el camino deban tener la VLAN definida.
Por ejemplo, digamos que la VLAN 5 soporta una aplicación de cuentas por pagar. Todas las VM que soportan la aplicación están ubicadas en un switch en la cima del rack que ha sido configurado para VLAN 5. Por razones de carga de trabajo, una de las VM que corre la aplicación de cuentas por pagar es movida a otro rack con sus propios switches en otra parte del data center que es alcanzada por varios switches de agregación.
Preservar la VLAN significa que todos los switches intermedios necesitan ser configurados como VLAN5; si no lo son, entonces la VLAN está rota. Actualmente ninguna de las soluciones esbozadas trata con cómo asignar automáticamente la VLAN en el switch de agregación. Esto significa que si una VM puede moverse a lo largo de un data center, el número de VLAN debe ser preconfigurado en todos los switches de agregación y de núcleo. Adicionalmente, no es probable que este problema sea resuelto en el futuro inmediato.
La industria ha resuelto un conjunto de soluciones adecuadas para los problemas de la VLAN de puerto y de políticas. No hay magia, la mayoría requiere que los grupos de red y de virtualización coordinen sus actividades a corto plazo para hacerlo funcionar sin problemas. La curva cerrada es la mejor solución a largo plazo y la industria se está moviendo hacia ello. Es importante que los administradores de red entiendan cómo las distintas soluciones trabajan con los diferentes fabricantes de virtualización que ellos soportan, ya que la gama completa de soluciones no están disponibles para todas las soluciones de virtualización que hay actualmente en el mercado.
Robin Layland, Network World (US)
