Quantum avec Open vSwitch

Avec Quantum et Open vSwitch on utilise 4 types d’interfaces virtuelles :

  • Interfaces TAP.
  • Linux Bridge (qbrXX voir ci-dessous).
  • Open vSwitch Bridge (br-int et br-vm).
  • Virtual Ethernet Interfaces (veth) (qvbXX et qvoXX voir ci-dessous).

1. Architecture réseau du nœud Compute

arch_compute_node 

Une trame prévenante de l’interface eth0 de l’instance virtuelle doit parcourir 9 interfaces pour atteindre l’interface physique eth0 de l’hyperviseur : TAP, Linux Bridge qbrXX, la paire Veth (qvbXX,qvoXX), Open vSwitch br-int , la paire Veth (int-br-vm, phy-br-vm), Open vSwitch br-vm , et enfin l’interface eth0 du compute.

La séparation de VMs se fait au niveau du switch virtuel br-int, ce dernier se charge d’isoler les réseaux des tenants en taguant les ports par des VlanID, et la translation des Vlans se fait au niveau des interfaces «init-br-vm» et «phy-br-vm».

L’API Nova se charge de faire le filtrage dans une installation de base d’Openstack, cependant cette tâche peut être déléguer au gestionnaire des réseaux « Quantum ». La mise en œuvre est toujours à base de l’outil « iptables » de linux, mais l’implémentation change :

  • Nova applique les mêmes règles de security group à l’instance (sur toutes ses interfaces)
  • Quantum applique les règles par port, c’est-à-dire qu’une instance virtuelle peut avoir plusieurs interfaces et pour chacune ses propres règles de security group.

L’agent L2 reçoit les commandes de créations/taguer des ports sur le bridge intérieur, et il exécute localement (sur l’hyperviseur) les règles iptables pour chaque port crée.
Les règles de filtrages sont appliquées sur les interfaces TAP sur le compute, et l’agent L2 se charge d’exécuter ces règles suite à une demande de l’API Quantum (via le RabbitMQ) et l’interrogation de la base de données mysql.

2. Architecture réseau du nœud Network

arch_network_node

Comme dans le noeud de compute, on retrouve les deux virtuels switch br-int et br-vm, ce dernier est utilisé pour les échanges des données entre le host network et les hosts compute, il est relié au br-int par la paire veth (int-br-vm , phy-br-vm) et la translation Vlan se fait à ce niveau par L2 agent.

Au niveau du br-int, le host network utilise le mécanisme des « internals ports » d’openvswitch pour adresser (@IP) les interfaces, dans le schéma ci-dessus chaque port internal : tap-WW, tap-VV, qr-ZZZ, qr-YYY possède sa propre adresse IP. Le port internal qg-XXX sur le switch br-ex possède aussi une adresse IP accessible depuis l’extérieur (@IP public).

Toutes les interfaces TAP du bridge br-int sont taguées par un Vlan ID : par exemple les interfaces tap-WW et qr-YYY appartient au même réseau, donc au même vlan.

DHCP Agent
Par default dans openstack, le DHCP Agent utilise le processus Dnsmasq pour fournir les services DHCP aux instances virtuelles. Un port internal (tap-WW, tap-VV) est créé pour chaque réseau qui nécessite le service DHCP, et un processus Dnsmasq est configuré pour écouter sur ce port.

L3 Agent
Le L3 agent héberge un ou plusieurs routeurs virtuels, chaque routeur possède au moins une interface sur le bridge br-int, cette interface est configurée avec l’adresse IP de la gateway du subnet auquel elle appartient.
Un routeur peut avoir aussi une interface sur le bridge extérieur br-ex, ceci lui permet de récupérer une adresse IP publique et d’implémenter le routage et le NAT ainsi qu’héberger les adresses flottantes des instances virtuelles.
Les interfaces qr-YYY et qr-ZZZ se sont des ports internals, chacune appartient à un réseau différent et considérée comme passerelle par défaut pour ce réseau, l’interface qg-XXX est la passerelle par défaut du routeur vers le monde extérieur, elle possède une adresse ip publique, celle-ci est utilisée pour faire du NAT pour les instances virtuelles qui ne possède pas d’adresse flottante pour communiquer avec le monde extérieur, et si l’instance possède une adresse flottante, le routeur translate l’adresse privé de l’instance par l’adresse flottante correspondante.

Overlapping d’adresses et les Namespaces

Si on expose l’API Network d’OpenStack aux utilisateurs finaux, il y aura une forte chance d’avoir des réseaux qui se chevauchent et ce qui posera un problème de routage, et il sera impossible de déterminer sur quelle interface un paquet devrait être envoyé.
Openstack Networking est désigné pour autoriser les utilisateurs finaux à créer leurs propres réseaux, routeurs. Et il s’appuie sur le concept de namespace pour séparer les réseaux physiques des réseaux virtuels ainsi que les réseaux virtuels entre eux.

Le network namespaces est un environnement isolé qui possède sa propre pile réseau donc ses propres interfaces, son propre table de routage et de filtrage. Dans un network namespaces les ressources réseaux (interfaces, les IP, routes, sockets …) sont attribuées à un ou plusieurs processus, et les processus externes au namespaces ne peuvent y accéder. Les processus à l’intérieur des networks namespaces ne savent rien sur les ressources réseau en dehors de namespaces et utilisent leurs propres ressources sans entrer en conflit avec d’autres namespaces.

Dans Openstack un namespace est créé suite à la création d’un réseau avec l’option DHCP activée, ou la création d’un routeur.

La commande suivante permet d’afficher tous les namespaces crées :

ip netns show

Le nom du namespaces DHCP (DHCP Agent) se compose de qdhcp-<id-réseaux>.
Le nom du namespaces Routeur (L3 Agent) se compose de qrouter-<id-routeur>.

La commande suivante permet d’afficher les interfaces d’un namespaces :

ip netns exec qrouter-<id-router> ip addr show

Dans le schéma ci-dessous, on trouve trois networks namespaces :

arch_namespace_network_node

  • Deux qdhcp-<network-id> : chacun héberge une interface TAP sur laquelle il configure un processus Dnsmasq en écoute, afin de répondre aux requêtes DHCP des Instances dans le réseau dont l’id =<network-id>.
  • Un qrouter-<router-id> : possède trois interfaces, chacune des deux (qr-YYY, qr-ZZZ) appartient à un réseau dans lequel elle joue le rôle de la Gateway par default, alors que l’interface qg-XXX appartient au réseau externe.
  • L’utilisation de l’Overlapping d’adresses implique la création au moins d’un ou plusieurs routeurs par tenant.
  • Un routeur ne peut pas être connecté à des réseaux qui se chevauchent.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


+ 8 = 10

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>