Configuration basique d'OpenVswitch

Configuration de la partie OpenVswitch sur CentOS 7.

OpenVswitch est composé de plusieurs parties:

  • Une partie noyau qui gère vraiment les flux, très performante car elle s'appuie sur les mécanismes de datapath intégrés au kernel
  • Une partie utilisateur (userland) composée:
    • d'un démon de configuration, qui lit régulièrement sa base de configuration (ovsdb-server)
    • dun démon qui contrôle et gère les switchs virtuels (ovs-vswitchd)
    • d'une partie utilisateur, qui fournit les commandes systèmes (ovs-*) pour intéragir avec tout ça.

Le but de ce billet est de configurer OpenVswitch sur CentOS 7 dans un cas simple, où l'hyperviseur n'aurait qu'une seule carte réseau (au hasard, comme sur mon Proliant N54L).

Voici le schema du "câblage"/fonctionnement interne dans l'hyperviseur :

ovs.png

Notre switch virtuel (appelé aussi bridge) sera nommé "br0". Notre interface réseau physique "eth0" sera intégralement gérée par OpenVswitch. Elle sera donc considérée comme un port de ce switch. Ici c'est la grande force d'OpenVswitch d'utiliser directement des trames ethernet pour les échanges. Ainsi quand le traffic sort par une carte réseau physique, c'est transparent. Cela permet de relier facilement la partie réseau virtuel au monde physique.

A noter que dans notre exemple, eth0 est relié à un switch qui ne gère aucun VLAN. Nous allons arbitrairement associé l'accès à ce réseau physique au VLAN 10 au sein de notre switch virtuel. Toutes les interfaces qui seront associées à ce VLAN 10 (futures VMs par ex) pourront donc communiquer avec le réseau physique. Comme les trames sortantes sur le switch physique ne doivent pas avoir de VLAN, il faut utiliser le terme native_untagged (contribution d'un collègue).

Installation d'OpenVswitch

Sur CentOS 7 (voire même 6), la partie noyau d'OpenVswitch fait déjà partie du noyau :

[root@hyperivseur] # modinfo openvswitch
filename:       /lib/modules/3.10.0-123.20.1.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
license:        GPL
description:    Open vSwitch switching datapath
srcversion:     1241855A733802E089FD201
depends:        libcrc32c,vxlan,gre
intree:         Y
vermagic:       3.10.0-123.20.1.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux kernel signing key
sig_key:        18:2E:BB:09:CD:40:C9:4C:A0:C3:CE:4E:E3:F7:1D:F5:20:B4:DA:80
sig_hashalgo:   sha256

Donc rien de plus à faire à ce niveau.

Pour la partie userland afin de gérer tout ça, nous passons par le dépôt RDO, qui est la partie communautaire d'OpenStack pour RedHat. Pour installer ce dépôt RDO :

[root@hyperivseur] # yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

Pour installer les outils OpenVswitch :

[root@hyperivseur] # yum install openvswitch

Voilà!

Configuration OpenVswitch

Depuis quelques version, les paquets OpenVswitch fournissent les scripts de configuration (auxquels j'ai pu apporter une modeste contribution) pour supporter les distributions RedHat&co. Il est donc possible de faire la configuration d'OpenVswitch en passant uniquement par les habituels fichiers ifcfg.

Pour rappel, ces fichiers de configuration se trouvent dans /etc/sysconfig/network-scripts/ et il est de plus conseiller de ne pas passer par NetworkManager :

[root@hyperviseur] # systemctl disable NetworkManager
[root@hyperivseur] # systemctl enable network

Attention, avant de procéder, il faut s'assurer d'avoir un accès console à la machine.

Fichier de configuration ifcfg-br0 du switch virtuel br0 :

DEVICE=br0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge

Fichier de configuration ifcfg-eth0 de notre interface réseau physique eth0 qui sera intégrée au br0 :

DEVICE=eth0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=br0
OVS_OPTIONS="tag=10 vlan_mode=native-untagged"

Fichier de configuration ifcfg-vi0 de notre interface virtuelle vi0 qui portera l'adresse IP de notre hyperviseur (pour son exploitation) :

DEVICE=vi0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSIntPort
OVS_BRIDGE=br0
OVS_OPTIONS="tag=10"
IPADDR=192.168.10.101
NETMASK=255.255.255.0

Attention c'est bien vi0 qui portera notre adresse IP. Elle est "taggué" sur le VLAN 10 ce qui lui permet de sortir par notre interface eth0 aussi associée à ce VLAN 10.

Il ne reste plus qu'à activer le service OpenVswitch:

[root@hyperivseur] # systemctl enable openvswitch

Validation

Pour vérifier que la configuration est correcte et effective, il est conseillé d'effectuer un redémarrage complet (pour valider que les services sont bien activées etc, rien n'est plus efficace).

Après le rédemarrage, la commande suivante donnera la configuration actuelle du switch virtuel :

[root@hyperivseur] # ovs-vsctl show

En sortie devrait apparaître notre switch br0 et ses ports, donc notre vi0 et notre eth0.

Un prochain billet expliquera comment intégrer automatiquement les VM dans ce switch virtuel.

 

Commentaires

1. Le 6. janvier 2016, 15:28 par titiFedoraNasIpcop

Salut, super ton post. Ça m'aide beaucoup.
As-tu eu le temps de préparer le billet pour intégrer automatiquement les VM dans le switch virtuel ?

2. Le 5. mars 2016, 11:17 par Edouard

J'ai corrigé la coquille qu'il y avait pour le systemctl enable openvswitch, merci Titi !

J'en ai profité pour mettre à jour l'url du dépôt RDO.

3. Le 9. mars 2016, 11:04 par doys

Bonjour;
Je suis en production de machine virtuelle de serveur Linux (25 serveurs)et Windows(4 serveurs) et poste de travail (90) avec KVM/libvirt depuis quelques années déjà. J'en suis très satisfait.
Nous souhaitons l'installation d'un NAC (packetfence) dans notre infra.
Je n'utilise pas OVS pour le moment, jusque-là j'utilise le bridge + bonding + VLAN. Cependant j'aimerais changer à chaud les vlans des postes de travail via OVS.
Je chipote un peu en test pour me faire à l'outil, cependant, je ne comprends ce qu'apporte OVS pour la connexion vers le physique par rapport à une configuration Bridge + bonding + VLAN traditionnel.
pourrais-tu m'éclairer ?
Merci d'avance

4. Le 26. mars 2016, 17:25 par Edouard

Déjà OVS est plus performant que le bridge linux natif, en terme de latence me semble, ce qui est un très bon point. Je crois que les bench sont dans les archives de la mailing list officielle OVS. C'est du coup rassurant. Niveau stabilité aucun soucis depuis que je l'utilise (3000 VMs au boulot)

L'avantage principale que je vois pour le lien avec le physique c'est de tout gérer avec OVS. Avoir les interfaces physique dans OVS, y ajouter des VLANs comme si c'était n'importe quel port c'est efficace. Il gère aussi le bonding avec pas mal d'option (LACP etc). Si l'archi réseau est un poil complexe, ça devient vite compliqué avec du bridge. Mais bon j'ai pas non plus creuser à fond ce qu'on peut faire avec les bridges en dehors des cas classiques.

J'assimilerais le bridge natif comme un hub, alors qu'OVS serait un switch qui ne commute que sur les ports nécessaires. C'est encore plus vrai quand on travaille avec, on est plus dans la logique d'un switch que d'un OS avec du "bricolage" (qui marche très bien) pour que ça sorte.

Pour le travail il nous fallait quelque chose de pilotable facilement via scripts, c'était donc plus simple avec OVS que de passer par des VLAN traditionnels, du bridge etc. Bref faire du SDN avant que ça devienne la mode ;) Il nous fallait aussi des tunnels pour que les flux virtuels passent d'un hyperviseur à l'autre etc

Ensuite il y a toutes les fonctionnalités d'OVS, comme SFLOW et surtout OPENFLOW. Me semble en plus que maintenant la version 2.5 gère le contracking ce qui devrait simplifier le filtrage des flux. Et comme c'est une solution que l'on retrouve un peu partout, c'est assez pérenne.

Je sais pas si ça t'éclaireras, n'hésite pas si tu as d'autres questions.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : https://www.linuxed.net/trackback/134

Fil des commentaires de ce billet