¿AWS utiliza la tecnología SDN (red definida por software)?

Para admitir soluciones como AWS VPC (nube privada virtual) que le permite aprovisionar una sección aislada lógicamente de la nube de Amazon, es imprescindible que AWS cree una red superpuesta que requiera el uso de la tecnología SDN. Sin embargo, Amazon no ha hablado de usar la tecnología de un proveedor en particular o una oferta SDN disponible comercialmente, por lo que probablemente sea una solución local.

Como se describe en “Redes empresariales avanzadas en AWS EC2: una guía práctica”, verá que todas las nubes públicas tienen una red L2 y que las máquinas virtuales en la nube tienen adaptadores Ethernet virtuales que se conectan a una red virtual L2, pero Las tramas que se envían y reciben se filtran fuertemente. Todas las nubes principales, incluidas Amazon EC2, Amazon VPC, Google Compute Engine y Microsoft Azure, solo permiten datagramas de unidifusión con cargas de IP. Los datagramas de transmisión y las cargas útiles que no son IP no están permitidos (con excepciones muy limitadas para que funcionen partes de los protocolos esenciales ARP y DHCP).

El problema es que algunas aplicaciones requieren algo más que la “unidifusión con carga útil de IP” que se admite en las nubes públicas como Amazon en la actualidad. Por ejemplo:

  1. Equilibrio de carga de varios servidores a través de una IP virtual (VIP). Esto se puede hacer a través de varios servicios y dispositivos como el Big IP de F5. Esto requiere la capacidad de enviar solicitudes ARP específicas a la dirección de transmisión, solicitudes que se filtran en la nube.
  2. Uso de diversos dispositivos de red, como la optimización de la red y los servicios de seguridad en el entorno de la aplicación. Muchos de estos dispositivos requieren definiciones de red avanzadas, como el uso de vlans, puertos troncales, puertos promiscuos y puertos espejo.
  3. Servicio DHCP dentro del entorno de la aplicación. Un servicio DHCP hace uso de la transmisión (ver más abajo).
  4. Algunos protocolos más antiguos, como el protocolo “wake on LAN” o el arranque de red (PXE), utilizan tipos de IP no IP.

La superposición de redes en la nube como se describe en Cloud Networking: IP Broadcasting and Multicasting en Amazon EC2 puede proporcionar acceso completo de capa 2 en la nube pública. Esencialmente, una red en la nube superpuesta puede imitar la configuración de red del centro de datos y puede habilitar funcionalidades como la difusión IP y la multidifusión.

Su competidor Rackspace es uno de los mayores partidarios de Openstack y lo usa en sí mismo. OpenStack depende en gran medida de SDN para proporcionar un mecanismo para simular un entorno de red completo en el clúster.

Los bits Neutron / Quantum de Openstack usan Openvswitch por defecto.

Así que estoy bastante seguro de que Amazon tiene un mecanismo equivalente para admitir su entorno de red virtualizado de manera programable.

No estoy trabajando en Amazon, no lo sé, y creo que se supone que ningún extraño debe saberlo.

Sin embargo, estoy 100% seguro de que la infraestructura de AWS usa “SDN” dadas las características que admiten para los clientes (por ejemplo, permitir que los clientes tengan sus propias VLAN).

También creo que Amazon usa todas las cosas de SDN de cosecha propia, y probablemente no usan ninguno de los conocidos desafíos, herramientas y protocolos de Stan generalmente asociados con “SDN”. En mis años dando vueltas por el mundo y las conferencias SDN / OpenFlow / NFV, no recuerdo haber visto nada ni nadie de Amazon

AWS es una empresa de nube pública, lo que quiere decir que ejecuta una enorme plataforma de computación en la nube con Multi-inquilino. Como tal, creo que es imperativo que usen algún tipo de tecnología SDN, o al menos su propia variante local para soportar la escala masiva y el rendimiento con el que tienen que lidiar.