Módulo de red Openstack

Openstack nuevo diagrama de flujo de host en la nube

Proceso de creación de la máquina virtual:

1. La interfaz o línea de comando obtiene información de autenticación de Keystone a través de la API RESTful.
2. Keystone solicita información de autenticación a través del usuario y genera un token de autenticación para volver a la solicitud de autenticación correspondiente.
3. La interfaz o línea de comando envía una solicitud de instancia de arranque (que lleva el token de autenticación) a nova-api a través de la API RESTful.
4. Después de recibir la solicitud, nova-api envía una solicitud de autenticación a Keystone para verificar si el token es un usuario y un token válidos.
5. Keystone verifica si el token es válido y devuelve la autenticación válida y los roles correspondientes si son válidos (Nota: Algunas operaciones requieren permisos de rol para operar).
6. Después de pasar la autenticación, nova-api se comunica con la base de datos.
7. Inicialice el registro de la base de datos de la máquina virtual recién creada.
8. Nova-api solicita nova-Scheduler a través de rpc.call si hay un recurso (ID de host) para crear una máquina virtual.
9. El proceso nova-planificador escucha la cola de mensajes y obtiene solicitudes nova-api.
10. Nova-Scheduler consulta el estado de los recursos informáticos en la base de datos de Nova y utiliza algoritmos de programación para calcular los hosts que satisfacen las necesidades de creación de máquinas virtuales.
11. Para un host que coincide con la creación de una máquina virtual, nova-planificador actualiza la información del host físico correspondiente a la máquina virtual en la base de datos.
12. Nova-Scheduler envía el mensaje correspondiente de la solicitud de creación de la máquina virtual a nova-compute a través de rpc.cast.
13. nova-compute obtendrá el mensaje de la solicitud de creación de la máquina virtual de la cola de mensajes correspondiente.
14. nova-compute solicita a nova-conductor que obtenga información de la máquina virtual a través de rpc.call. (Sabor)
15. nova-conductor obtiene el mensaje de solicitud nova-compute de la cola de mensajes.
16. nova-conductor consulta la información correspondiente a la máquina virtual según el mensaje.
17. nova-conductor obtiene la información correspondiente de la máquina virtual de la base de datos.
18. Nova-conductor envía la información de la máquina virtual a la cola de mensajes en forma de mensajes.
19. nova-compute obtiene mensajes de información de la máquina virtual de la cola de mensajes correspondiente.
20. nova-compute obtiene el token autenticado a través de la API RESTfull de keystone y solicita el look-api a través de HTTP para obtener la imagen necesaria para crear la máquina virtual.
21. vistazo-api verifica si el token es válido para Keystone y devuelve el resultado de la verificación.
22. Una vez que se pasa la verificación del token, nova-compute obtiene la información de la imagen de la máquina virtual (URL).
23. nova-compute obtiene el token para la autenticación k a través de la API RESTfull de keystone y solicita a neutron-server a través de HTTP para obtener la información de red necesaria para crear una máquina virtual.
24. El servidor de neutrones verifica si el token es válido para Keystone y devuelve el resultado de la verificación.
25. Se pasa la verificación del token y nova-compute obtiene la información de red de la máquina virtual.
26. nova-compute obtiene el token autenticado a través de la API RESTfull de keystone y solicita el cinder-api a través de HTTP para obtener la información de almacenamiento persistente necesaria para crear la máquina virtual.
27. Cinder-api verifica si el token es válido para Keystone y devuelve el resultado de la verificación.
28. Se pasa la verificación del token y nova-compute obtiene la información de almacenamiento persistente de la máquina virtual.
29. Nova-compute llama al controlador de virtualización configurado para crear una máquina virtual basada en la información de la instancia.

La interacción entre keystone y cada componente.

Neutrón

En el área de redes, OpenStack ha pasado por el proceso de evolución de nova-network (temprano) a Quantum (versión F) y luego a Neutron (versión H).

neutron-server recibe la solicitud -> envía la solicitud a MQ -> neotron-plugins obtiene la solicitud -> envía la solicitud a MQ -> neotron-agent establece el equipo de red.
Neutron incluye introducción de componentes y funciones:

• neutron-server: proporcione rest api externamente, reciba solicitudes y distribúyalas a diferentes neutron-plugins.
• neutron-plugin: procese las solicitudes de Neutron Server, mantenga el estado de la red lógica de OpenStack y llame al Agente para procesar las solicitudes. Cada fabricante desarrolla software que simula su propio hardware basado en Openstack, y este software es un complemento. En los primeros días, cada proveedor desarrolló su propio complemento, y sus funciones se implementaron por separado, y se duplicó una gran cantidad de código; además, diferentes proveedores tenían diferentes estándares de desarrollo, lo que resultaba en una mala compatibilidad del programa. En respuesta a esta situación, neutron-plugin se divide en dos partes: Core-plugin y Service-plugin.
• Core-plugin: ML2 (Modular Layer 2) en Neutron es responsable de administrar la conexión de red de L2. ML2 incluye principalmente tres tipos de recursos centrales: red, subred y puerto. La API REST que opera en los tres tipos de recursos es considerada como API central por neutron-server y es compatible de forma nativa con Neutron. entre ellos:
• Red: representa un segmento de red de Capa 2 aislado, que es un dominio de difusión reservado para crear su inquilino. La subred y el puerto siempre se asignan a una red específica. Los tipos de red incluyen Flat, Vlan, VxLan, Gre, etc.
• Subred: representa un grupo de direcciones CIDR IPv4 / v6 y su configuración relacionada, como puerta de enlace, DNS, etc. La instancia de VM en la subred heredará automáticamente la configuración. La subred debe estar asociada a una red.
• Puerto: representa un puerto de conmutador virtual en el conmutador virtual. Después de que la tarjeta de red de la VM esté conectada al VIF para conectarse al puerto, tendrá la dirección MAC y la dirección IP. La dirección IP del puerto se asigna desde el grupo de direcciones de subred.
• Complemento de servicio: Son otros complementos además del complemento de núcleo, incluido el enrutador l3, firewall, equilibrador de carga, VPN, medición, etc. Se da cuenta principalmente de servicios de red L3-L7. Los recursos que estos complementos necesitan para operar son relativamente ricos, y las API REST que operan en estos recursos son consideradas API de extensión por el servidor de neutrones y deben ser extendidas por los fabricantes.
• Agente de neutrones: Solicita el complemento de proceso y es responsable de realizar varias funciones de red en el proveedor de red. Existe una correspondencia uno a uno con el complemento,

En términos de diseño de arquitectura, Neutron sigue la idea completamente distribuida de OpenStack, y cada componente se comunica a través de un mecanismo de mensaje, de modo que cada componente e incluso cada proceso en Neutron puede ejecutarse en cualquier nodo, como se muestra en el diagrama de flujo anterior. Esta arquitectura de micro-kernel permite a los desarrolladores centrarse en la realización de servicios de red. En la actualidad, Neutron proporciona una gran cantidad de complementos y controladores, que básicamente pueden satisfacer las necesidades de diversas implementaciones. Si es difícil admitir el entorno real requerido, puede ampliar fácilmente los complementos o controladores en el marco de Neutron. .

En términos generales, el servidor de neutrones y cada complemento de neutrones se implementan en nodos de control o nodos de red, mientras que el agente de neutrones se implementa en nodos de red y nodos de computación. Primero analicemos simplemente el trabajo del servidor de neutrones y el complemento de neutrones en el lado de control, y luego analicemos el trabajo del agente de neutrones en el lado del dispositivo.
(Tenga en cuenta que tanto el complemento L2 como ML2 desarrollados por fabricantes anteriores existen en el directorio neutron / plugins, mientras que los controladores de dispositivo ML2 conectables existen en el directorio neutron / plugins / ml2 / drivers)

La realización del terminal de control:
comienza desde el inicio del servidor de neutrones. Cuando se inicia neutron-server, principalmente hace dos cosas. La primera es iniciar el servidor wsgi para escuchar la API REST de Neutron. La segunda es iniciar el servicio rpc, que se utiliza para la comunicación entre el complemento central y el agente. Los dos tipos de servicios se ejecutan simultáneamente como subprocesos verdes. Desde la perspectiva de SDN, wsgi es responsable de la interfaz hacia el norte de Neutron, y el mecanismo de comunicación hacia el sur de Neutron se basa principalmente en rpc para lograrlo (por supuesto, los complementos de diferentes fabricantes pueden tener otros mecanismos de comunicación hacia el sur).

• En dirección norte: el wsgi de Neutron utiliza la herramienta Pegar para la implementación basada en plantillas. Recibe la solicitud comercial de la API REST de Neutron y luego la distribuye al complemento correspondiente a través de APIRouter.
• Dentro de Neutron, el complemento interactúa con la base de datos para obtener los parámetros globales del negocio, y luego transmite la operación y los parámetros al Agente en el dispositivo a través del mecanismo rpc (algunos complementos y ML2 Mechanism Driver se comunican con el Agente a través de otros medios, como REST API, NETCONF, etc.).
• El mecanismo RPC puede entenderse como el mecanismo de comunicación en dirección sur de Neutron. La implementación de RPC de Neutron se basa en el modelo AMPQ. Los complementos y agentes suelen utilizar el modo "publicar-suscribirse" para transferir mensajes. Después de que los agentes reciben el *** NotifyApi de los complementos correspondientes, volverá a llamar al *** CallBack local del dispositivo para operar el dispositivo y completar la implementación subyacente del servicio.

La realización del lado del dispositivo: el
servidor de neutrones del lado de control recibe la solicitud de API REST en dirección norte a través de wsgi, y el complemento de neutrones se comunica con el lado del dispositivo a través de rpc en la dirección sur. El agente en el lado del dispositivo se comunica con el lado de control a través del rpc hacia arriba y configura el equipo de red directamente en el lado hacia abajo.

Modo de red

Según la autoridad del usuario que creó la red, la red Neutron se puede dividir en:

• Red de proveedores: una red virtual creada por el administrador que tiene una relación de mapeo directa con la red física.
• Red de inquilinos: La red creada por usuarios ordinarios del inquilino. La red física es transparente para el creador. Su configuración es determinada por Neutorn en base a la configuración del administrador en el sistema.

Según el tipo de red, la red Neutron se puede dividir en:

• Local
• Plano / Plano Dhcp
• VLan
• Vamos
• VxLan
• y muchos más

1.
Todos los componentes locales se instalan en una sola máquina, y se utilizan principalmente en entornos de prueba.
2. Flat / Flat Dhcp
Flat El modelo es el más simple. Todas las máquinas virtuales comparten un segmento de red IP privada. La dirección IP se inyecta cuando se inicia la máquina virtual. La comunicación entre máquinas virtuales se reenvía directamente a través del puente en HyperVisor. Tráfico de red pública Este NAT se realiza en la puerta de enlace de este segmento de red (Nova-network se implementa como iptables del kernel de host de nova-network y Neutron se implementa como el agente l3 en el nodo de red). La diferencia entre el modelo Flat DHCP y Flat es que el proceso DHCP está habilitado en el puente y la máquina virtual obtiene una dirección IP a través de mensajes DHCP (Nova-network se implementa como dnsmaq en el host de nova-network y Neutron se implementa como dhcp-agent en el nodo de red).

• Ventajas: estructura simple y estable
• Desventajas: Todos los inquilinos están en el mismo nivel y no hay aislamiento entre los inquilinos, porque todos los inquilinos están en una subred. Después de una implementación a gran escala, la tormenta de difusión será un gran factor negativo.
  
  3. VLan
• LAN:  representa la red de área local, la red de área local, por lo general, el concentrador y el conmutador se utilizan para conectar computadoras en la LAN. En términos generales, cuando conecta dos computadoras al mismo Hub o Switch, están en la misma LAN. Del mismo modo, si conecta dos conmutadores, también estarán en la misma LAN. Una LAN representa un dominio de difusión, lo que significa que todos los miembros de la LAN recibirán un paquete de difusión enviado por un miembro de la LAN. Se puede ver que el límite de la LAN está en el enrutador o en un equipo similar de capa 3.
• VLAN:  representa la LAN virutal. Un conmutador con función VLAN puede estar en varias LAN al mismo tiempo. En los términos más simples, VLAN es un método para dividir un conmutador en varios conmutadores. Por ejemplo, tiene dos grupos de máquinas, el grupo A y el grupo B. Desea configurar las máquinas del grupo A para que se accedan entre sí, y las máquinas del grupo B también pueden acceder entre sí, pero las máquinas del grupo A no pueden acceder las máquinas del grupo B. Puede usar dos interruptores y los dos grupos están conectados a un interruptor respectivamente. Si solo tiene un conmutador, puede usar VLAN para lograr el mismo efecto. Usted asigna los puertos configurados para conectar las máquinas del grupo A y B en el conmutador como puertos de acceso VLAN. Este conmutador solo reenviará paquetes entre puertos en la misma VLAN.

Los puertos de los conmutadores con VLAN se dividen en dos categorías:

• Puerto de acceso: estos puertos están etiquetados con etiquetas VLAN. No hay una etiqueta de VLAN en la trama de Ethernet que sale del puerto de acceso del conmutador y entra en la computadora, lo que significa que la máquina conectada a los puertos de acceso no se dará cuenta de la existencia de la VLAN. Los marcos de datos que salen de la computadora y entran en estos puertos están etiquetados con etiquetas VLAN.
• Puerto troncal: cuando hay varios conmutadores, algunas máquinas del grupo A están conectadas al conmutador 1 y las otras máquinas están conectadas al conmutador 2. Para permitir que estas máquinas se comuniquen entre sí, debe conectar dos conmutadores. Para evitar usar un cable para conectar los dos puertos de cada VLAN, podemos configurar un puerto troncal VLAN en cada conmutador. Los paquetes de datos enviados y recibidos por el puerto troncal tienen un encabezado de VLAN, que indica a qué VLAN pertenece el paquete de datos. Por lo tanto, todos los paquetes de datos se pueden reenviar solo conectando un puerto troncal de los dos conmutadores, respectivamente. En términos generales, solo use el puerto troncal para conectar dos conmutadores, no para conectar la máquina y el conmutador, porque las máquinas no quieren ver los paquetes que reciben con el encabezado VLAN.