Author Archives: obuisson

OpenStack : Introduction à Quantum

Introduction

Dans mon guide précédent, j’avais effectué le choix d’utiliser nova-network pour la gestion du réseau dans un but de simplification. Avec la sortie de Grizzly (la septième version d’OpenStack), je m’attaque à la configuration de Quantum à la place de nova-network. Le guide d’installation sera mis à jour pour Grizzly avec l’utilisation de Quantum. Quantum est le gestionnaire du réseau pour OpenStack à l’instar de Cinder qui est le gestionnaire de volume.

Je dois avouer que c’est le composant d’OpenStack le plus compliqué à appréhender et il est nécessaire de se plonger dedans pour bien comprendre sont fonctionnement. L’objectif de cette article est de comprendre les différents composants et les différentes topologie qu’il est possible de faire avec.

Les composants de Quantum

Comme pour Cinder ou Nova, il existe différents composants pour Quantum. A noter que l’ensemble des composants de Quantum utilise le gestionnaire d’identité (Keystone) pour l’authentification et les autorisations.

quantum-server

Il s’agit du démon qui expose aux autres composants l’API Quantum et va passer les requêtes utilisateurs vers les autres démons. Il agit comme le contrôleur du réseau et il est donc possible de le lancer sur la machine qui agit comme votre contrôleur de nuage.

Plugins d’agent (quantum-*-agent)

Ce démon sera installé sur les hyperviseurs et permet de gérer les configurations de vos switchs virtuels. L’agent dépend du type de plugins que vous utilisez. Il existe en effet un variété de plugins  en fonction de vos choix. Par exemple, vous pouvez utiliser les plugins pour Open vSwitch, Cisco, Nicira NVP, etc… Certains plugins, comme le plugin Cisco, sont dépendant du matériel que vous avez et c’est en dehors du scope de Quantum. Le choix du plugin dépend de votre budget et des vos besoins car des solutions comme Nicira ou Midonet sont des solutions commerciales. Dans le cadre des différents guides que je vais proposer, le plugin Open vSwitch sera utilisé

Agent DHCP (quantum-dhcp-agent)

Ce démon propose un serveur DHCP pour chacun des tenants. Il est identique pour l’ensemble des plugins

Agent L3 (quantum-l3-agent)

Ce démon se charge de la gestion du routage et du NAT afin de permettre l’accès externe aux VM pour les réseaux de chaque tenant. Il est identique pour l’ensemble des plugins

Agent Metadata (quantum-metadata-agent)

Nouveauté de Grizzly, ce démon permet de gérer le serveur de metadata permettant d’injecter des données lors du lancement des VM. Il est identique pour l’ensemble des plugins. A noter que certains configurations n’autorisent pas l’utilisation du serveur de metadata.

L’ensemble des démons communique par l’intérmediaire de RPC (via RabbitMQ ou Qpid) ou via une API.

Les différentes topologies réseaux

Quantum permet de créer différentes topologies réseaux en fonction de vos besoins.

Réseau plat unique :

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_flat.html

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_flat.html

Dans cette configuration un seul réseau est utilisé pour l’ensemble des VM et des tenants. Il ne permet pas l’utilisation des ips flottantes. Le routage est assuré en externe et n’est pas contrôler par OpenStack. Ce cas d’usage permet d’utiliser un réseau physique et de lier les VM sur ce réseau physique unique.

Multiple Réseaux plat :

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_multi_flat.html

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_multi_flat.html

Il s’agit du même principe que pour la topologie précédente sauf qu’il est possible d’utiliser plusieurs réseaux différents. Ces réseaux sont partagés entre les différents tenants.

Mélange entre réseaux plats et réseaux privés :

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_mixed.html

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_mixed.html

Dans cette topologie, il est possible de combiner des réseaux plats partagés entre les différents tenants et des réseaux privés pour chaque tenants. Du coup, il est possible de créer des architectures “multi-tiers” pour chaque tenant et d’avoir plusieurs interfaces réseaux pour chaque VM. L’accès aux réseaux privés est limité et il est donc nécessaire que les VM qui ont une interface sur le réseau partagé jouent un rôle de passerelle. Il est possible que les VM fassent du routage, du NAT ou du load-balacing.

Réseaux privés avec routeur :

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_router.html

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_router.html

Chaque tenant a la possibilité d’avoir des réseaux privés. L’accès à l’extérieur se fait par l’intermédiaire d’un routeur partagé pour l’ensemble des tenants. Chaque tenant va pouvoir avoir un seul réseau privé. Par l’intermédiaire du routeur, il est possible d’assigner des ips flottantes pour chaque VM afin d’être pouvoir recevoir des connections entrantes. Les VM n’ayant pas d’ip flottante peuvent établir des connections vers l’extérieur, le routeur va effectuer du NAT pour permettre cette configuration. Il est aussi possible que les VM puissent communiquer avec les VM des autres tenants par l’intérmédiaire du routeur. Dans cette configuration, il n’est donc pas possible d’utiliser les mêmes plage d’ip entre les différents tenants. C’est donc l’administrateur du nuage qui s’occupe de l’assignation des plages d’ips pour chaque tenant.

Réseaux privés avec routeur par tenant :

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_tenant_router.html

Source: http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_tenant_router.html

Dans cette configuration, chaque tenant a son propre routeur. Il a aussi potentiellement, la possibilité de créer d’autres routeurs en fonction de ces besoins. Il est donc aussi possible d’avoir les mêmes plages d’ips utilisées par chacun des tentants sans conflit entre les tenants. Cette topologie est donc la plus souple pour l’utilisateur. Il est possible de créer des architectures multi-tiers facilement en fonction des ces besoins.

 

Conclusion

Comme nous venons de le voir, Quantum est souple et permet de créer la configuration qui répond le mieux à son besoin. Nous avons pu voir les différents composants et les différentes topologies qu’il est possible de créer avec. Dans un prochain articles, nous verrons l’installation et la configuration de Quantum en utilisant le plugin Open vSwitch.

N’hésitez pas à faire des remarques ou à poser vos questions.