Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Problemas de VLAN en la Nube privada: ¿Es OpenFlow la respuesta?

Al crear redes dinámicas de nube privada, los ingenieros cambiarán el software definido de red y control de planos de la conmutación virtual y física.

En la primera parte de esta serie sobre la red de nube privada, examinamos si la red física es hostil a la nube privada. En la segunda parte, veremos cómo el software definido para control de planos de redes puede integrar capas de conmutación virtual y física.

La red de nube privada debe ser mucho más flexible y dinámica que las redes tradicionales. Esencialmente, las nubes privadas requieren una red en la cual los servicios son una abstracción de la infraestructura virtual y física subyacente utilizando Software Definido para Red (SDN), permitiendo en última instancia la Red Como Servicio (NaaS).

Sin embargo, aparte de las implementaciones propietarias, estamos muy lejos del NaaS/SDN en un multi-proveedor, multi-hipervisor de nube privada. Mientras tanto, hay algunos avances en la creación de redes virtuales que podemos utilizar en el camino hacia las redes definidas por software de nube privada.

Redes de nubes privadas: Gestión de VLAN a través de lo virtual y lo físico

Como punto de partida de esta discusión, la red de nube privada tiene dos capas de conmutación: la capa de conmutación virtual y la capa de conmutación física. El switch físico es el conmutador estándar de Ethernet que hemos estado utilizando durante más de 20 años. El conmutador virtual es un componente de cada hipervisor. La mayoría de las arquitecturas de hipervisor vinculan los switches virtuales, junto con un plano de control común, creando un gran interruptor distribuido y virtual. Hay interruptores virtuales mejorados en el mercado, así como el desarrollo continuo de un interruptor virtual de sistemas abiertos virtual llamado el Open vSwitch.

Los switches virtuales y físicos siguen siendo dos entidades de red diferentes que deben trabajar juntos para habilitar la nube privada. La mayoría de los arquitectos de red usan las VLAN para llenar este vacío, pero esto requiere de switches virtuales y físicos para mantenerse en paso seguro.

Virtual and physical switches are still two distinct network entities that must work together to enable the private cloud. Most network architects use VLANs to bridge this gap, but this requires physical and virtual switches to stay in lock step.

Algunos pueden pensar que un enfoque es configurar cada VLAN posible en cada tronco y cada puerto en el centro de datos. Sin embargo, ésta es una estrategia de fuerza bruta que no escala bien y está cargada del riesgo de una mala configuración y violaciones potenciales de seguridad y cumplimiento. Otro enfoque es la aplicación de una solución de aprendizaje de VLAN que gestiona dinámicamente las VLANs a través de la red virtual y física, en particular cuando las máquinas virtuales se mueven. Algunas soluciones funcionan muy bien, pero siguen siendo propietarias. Edge Virtual Bridging (EVB) IEEE 802.1qbg es un estándar en desarrollo para VLAN de aprendizaje y cartografía.

Apoyo a las VLAN a través de Capa 3: NVGRE y VXLAN

La red privada de Nube VLAN requieren de un puente a gran escala para apoyar el movimiento VM y las comunicaciones. Este enfoque no escala bien, ni distribuye las cargas de trabajo en apoyo de los límites de la Capa 3. Para abordar estas cuestiones VLAN, hay dos multifabricantes de protocolos soportados que están ganando apoyo: VXLAN (LAN Virtual Extensible) y NVGRE (Virtualización de Red Mediante Encapsulación de Enrutamiento Genérico). VXLAN y NVGRE son proyectos de estándares IETF para encapsulamiento de la capa de tráfico MAC sobre IP. Impulsando las cosas a un nivel superior, abrimos la puerta a la distribución de las cargas de trabajo a través de los límites de la Capa 3 con las VM aún en la misma Capa 2 de la red. Esto es interesante, ya que también rompe la relación fija entre la ubicación y la identidad. Esto significa que una máquina virtual puede mantener su dirección IP, incluso después de moverse a otra subred. Esto puede ser eficaz, pero no necesariamente eficiente.

Donde VXLAN y NVGRE se quedan cortos en la red de Nube privada

VXLAN y NVGRE son un gran paso hacia una red de Nube privada más dinámica y extensible, pero no son la solución total. Son protocolos de encapsulación y no tienen control de plano. En su lugar, se basan en las funciones de la red. Por ejemplo, VXLAN se basa en Protocol Independent Multicast (PIM UDP), y para el establecimiento de comunicaciones VM-VM requiere flujo a Layer 2 y el aprendizaje de dimensionamiento dinámico MAC.

Es más, VXLAN y NVGRE no resuelven el reto fundamental de ampliar los dominios del nivel 2 a través del núcleo de la red: “red de trombón.” Aunque las dos máquinas virtuales pueden estar en el mismo switch, el tráfico todavía puede enrutarse hacia el núcleo de la red y regresar, de manera parecida a un trombón. Esto es comparable a hacer de tu hogar un aeropuerto SFO porque vives en San Francisco, luego, mudarte a Nueva York, pero aun viajando primero a San Francisco antes de ir a ningún otro lado, incluyendo Nueva Jersey. Es una arquitectura muy ineficiente que no escala. Por último, VXLAN es una construcción virtual y no se conecta a dispositivos físicos, como firewalls, balanceadores de carga, etc.

¿Puede SDN resolver el desafío para las redes VLAN de Nube privada?

Más allá de VXLAN y NVGRE, necesitamos un plano de control fuerte que integre conmutación virtual y física. En el frente de los estándares abiertos, la actividad más emocionante es el proyecto OpenFlow de la Fundación Open Networking (ONF). OpenFlow abstrae las aplicaciones de control (controladores) fuera de los planos de datos subyacentes (switches).

OpenFlow mantiene la promesa de una nueva manera de conmutar paquetes a través de switches virtuales y físicos, eliminando la necesidad de encapsulación, el etiquetado y las VLAN, mientras sigue soportando la multi-tenencia, movimiento VM y escalabilidad. Esto hará realidad que SDN entregue de NaaS, como parte de la Nube privada.

Por desgracia, la palabra clave es “hará”, ya que la aplicación OpenFlow está creciendo, pero limitada. Es importante presionar a los proveedores de conmutadores en sus planes para la SDN/NaaS, así como apoyar OpenFlow. Tenemos que ir más allá de la VLAN para redes de Nube privada. VXLAN y NVGRE son pasos en la dirección correcta, pero no son la solución final.

También hay otras razones por las que debemos movernos a SDN/NaaS para Nube privada. En el próximo artículo nos centramos en los problemas de desempeño y cumplimiento para las redes nube privada de hoy en día.

Este artículo se actualizó por última vez en noviembre 2012

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close