Conceptos de OpenStack Networking (Neutron)

La terminología que usa el proyecto de OpenStack Networking (aka. Neutron) puede llegar a confundir a mas de alguno; conceptos como agentes, recursos, extensiones, plugins y drivers en ocasiones son referidos indistintamente. Es por ello que me parece necesario clarificar estos conceptos y proveer información acerca de su uso.

Comenzare con los conceptos relacionados a su arquitectura. El servicio web (RESTful) principal por medio del cual Neutron expone sus capacidades a los usuarios es denominado neutron-server. Este servicio primordialmente tiene dos funcionalidades. La primera, referida como Neutron API, es responsable de procesar peticiones, validar información y restringir accesos. La segunda, Neutron RPC, es responsable de delegar las solicitudes de los usuarios a otros servicios llamados agentes, esta comunicación se realiza mediante una cola de mensajes.

Agentes

Los agentes de Neutron son servicios que escuchan la cola de mensajes y procesan las solicitudes provenientes del neutron-server, ejecutan tareas específicas en la red y por lo general son ubicados en los nodos de computo. En el código fuente, estos pueden ser localizados en la carpeta de neutron/cmd/eventlet/agents y tienen distintas funciones:

  • neutron-dhcp-agent: Encargado de proveer servicios de DHCP a todas las redes.
  • neutron-l3-agent: Responsable de ofrecer servicios de ruteo, nateo(natting), grupo de reglas de seguridad (security-group rules) y asignación de IPs Flotantes.
  • neutron-ns-metadata-proxy: Agrega encabezados de X-Forwarded-For y X-Neutron-Router-ID a las peticiones realizadas por las instancias hacia el servicio de nova-api-metadata que son interceptadas por neutron-metadata-agent.
  • neutron-metadata-agent: Agrega encabezados de X-Instance-ID, X-Tenant-ID y X-Instance-ID-Signature y determina desde que namespace se realizo dicha petición para enviar la respuesta.

Recursos y Extensiones

Ambos terminos se refieren a las entidades que son expuestas en la API y que pueden ser consumidas mediante los verbos HTTP (GET, POST, DELETE, PUT, etc.). Su diferencia radica en la manera en que son registradas en el servicio de neutron-server.
Los Recursos son las entidades que siempre son registradas esto se debe a este registro es realizado por el constructor de la clase RouterAPI. Hoy en dia se cuenta con cuatro clases de recursos: «network», «subnet», «subnetpool» y «port».
Por otro lado, las Extensiones son aquellas entidades que dinámicamente son registradas. Como ejemplo de ello estan los «security groups». Otros proyectos como lo es neutron-lbaas hacen uso de la función register_resource_by_name para registrar «member».

Plugins

La API de Neutron tiene la capacidad de extender su funcionalidad mediante la adición de plugins de terceros. Las peticiones validadas por el neutron-server son trasmitidas a los agentes por medio de ellos. Existen dos tipos de plugins:

  • Core Plugin: Implementa las acciones sobre los Recursos «core» (L2 + IPAM). Cabe mencionar que en el release de Havana se libero el Modular Layer 2 (ML2), el cual permite utilizar simultáneamente una variedad de tecnologías de red(por ejemplo, LinuxBridge, Open vSwitch, HyperV) que pueden ser encontradas en los centros de datos.
  • Service Plugin: Provee servicios adicionales de red, como ruteo (routing), balanceo de carga (load balancing), cortafuegos (firewalling) y mas.

Drivers

El concepto de «drivers» fue introducido gracias a la creación del plugin ML2. De acuerdo a su propósito los drivers pueden ser catalogados como:

  • Type Drivers: Cada tipo de red disponible es administrada por un TypeDriver. El cual mantiene el estado, ejecuta una validación  y realiza la asignación de redes. Algunos posibles valores son: local, flat, vlan, gre y vxlan. 
    type_drivers = local,flat,vlan,gre,vxlan
  • Mechanism Drivers: Se asegura de implementar la información requerida dependiendo del tipo de driver definido. Actualmente soporta acciones de creación, actualización y eliminación de recursos de red y puertos. Algunos posibles valores son: linuxbridge, openvswitch, omniswitch, brocade, cisco_nexus, lenovo, etc. 
    mechanism_drivers = openvswitch,