Parce que tout est possible, même Open vSwitch sous Windows !

Cette histoire se déroule durant l’hiver 2017, c’était un hiver sombre, enneigé et froid… dans un petit village nommé OpenStack. Tout ce que vous lirez dans ce billet s’est réellement déroulé.

Aux âmes sensibles s’abstenir, d’affreux événements se sont déroulés tout au long de cette histoire comme des réinstallations de système et des bases de registre corrompues. Des mots pouvant vous horrifiez tels que Windows, PowerShell, Hyper-V ont été utilisés lors de la rédaction de ce récit, des journées passées sur Technet à lire des horreurs sur la torture de système d’exploitation de production…

Lecteurs, sachez néanmoins que même si au premier abord cette histoire vous semble vile et terrifiante, cette dernière se soldera tout de même par une fin heureuse et certainement féerique pour plusieurs d’entre vous.

Malgré le caractère atroce de cette histoire, je tiens à mentionner qu’aucun Windows ne fut (vraiment) maltraité tout au long de cette aventure.

Hyper-V, un besoin client pour gagner de l’argent ^^

OpenStack c’est bien, mais les fonctionnalités proposées de bases ne sont pas les plus sexy. Par défaut, KVM est la solution de virtualisation choisie par la majorité des installeurs, c’est bien, mais pas suffisant…

Certains clients veulent pouvoir utiliser Hyper-V et cela souvent pour des raisons de support/licence/performances. Dans notre cas, le client devait être capable de déployer des bases de données de type Oracle sur des hyperviseurs Hyper-V dans des instances Windows Server.

Si nous prenons le cas de Microsoft SQL Server, je présume que Microsoft supportera uniquement ce produit s’il est installé sur un système d’exploitation Windows dans une machine virtuelle sur un hyperviseur de type Hyper-V.

Bref, si le client désire avoir Hyper-V alors Hyper-V il aura !

Hyper-V officiellement supporté mais…

D’après les documentations officielles, l’hyperviseur de Microsoft est supporté par OpenStack. D’un point de vue Nova, il n’y a rien à redire mais d’un point de vue Neutron, seul neutron-hyperv-agent est documenté est donc par défaut officiellement supporté.

Dans notre cas, cet agent ne supporte pas la totalité de nos besoins comme par exemple l’isolation des tenants à l’aide du protocole VxLAN… Sans VxLAN comment faire en sorte que les machines virtuelles créées sur les hyperviseurs Hyper-V soient capables de communiquer avec les machines virtuelles créées sur les hyperviseurs KVM ? La seule solution que nous ayons trouvé fut de remplacer neutron-hyperv-agent par neutron-ovs-agent.

Deux autres avantages à utiliser l’agent Neutron Open vSwitch (selon moi):

Il n’est pas nécessaire d’ajouter un second mechanism_drivers (openvswitch, hyperv) au ML2
Nul besoin d’installer la dépendance Python networking-hyperv

Qui dit neutron-ovs-agent dit Open vSwitch (je vous vois entrain de lever un sourcil comme Jack Nicholson), Open vSwitch est disponible sous Windows depuis la version 2.4 (si je ne me trompe pas). La ligne de commande est exactement la même, les données continuent d’être enregistrées dans la base de données Open vSwitch, les services ovsdb et vswitchd sont eux aussi toujours présents.

Bref un vrai portage réussi, la preuve en commande:

> ovs-vsctl.exe -V
ovs-vsctl (Open vSwitch) 2.7.3
DB Schema 7.14.0

Alors, ça vous la coupe hein ? (perso, moi ça me l’a coupé ! 😯 )

Un réseau de production avec Hyper-V et Open vSwitch, c’est compliqué !

Avoir une configuration réseau de production sous Windows avec Hyper-V et Open vSwitch fut une tâche bien difficile à accomplir ! Par réseau de production j’entends une configuration résiliente en cas de problème matériel (carte, câble, switch):

Plusieurs interfaces réseau physique
Un ou plusieurs bond de type LACP (802.3ad) avec différentes interfaces
Plusieurs VLANs (802.1q) configurés sur le bond

Rien de bien exotique me direz-vous (sous Linux tout du moins)… Détrompez-vous !!

Le premier réflexe que vous allez certainement avoir est de vouloir créer un teaming (via l’interface graphique Windows) avec des interfaces VLANisées au dessus de ce teaming, c’est un bon réflexe mais ça ne fonctionnera pas.

Open vSwitch ne supporte par le LBFO (LoadBalancer/FailOver) et le bond ainsi que les VLANs devront être créés par Open vSwitch (et pour ce conseil tu me seras éternellement reconnaissant !!).

Hyper-V a besoin d’un switch virtuel (vswitch) faisant office de bridge, un peu comme KVM le fait avec son virbr0. Ce switch virtuel a besoin d’être connecté à une interface physique pour faire entrer/sortir le trafic généré par les machines virtuelles. Cette première étape est déjà sujette à problématique, comment faire en sorte que cette interface physique soit redondante ? La réponse est simple (quand on la connaît), il suffit de créer un teaming avec ces deux interfaces puis de créer le switch virtuel avec ce nouveau teaming.

Avant de continuer plus loin, assurez-vous d’avoir un Windows 2012 R2 ou 2016 activé avec les dernières mises à jour de Windows Update, synchronisé à un serveur NTP ainsi que les derniers pilotes d’installés et il va de soit qu’Hyper-V est obligatoire. Bien sûr Open vSwitch est un pré-requis donc si ce dernier n’est pas installé veuillez le faire à l’aide de l’installeur fournit par Cloudbase.

Il va de soit que toutes ces actions sont à effectuer via l’interface iLO/iDRAC de votre serveur !

Reprenons, la création de notre teaming ainsi que de notre switch virtuel Hyper-V (j’ai renommé mes interfaces physique Nic1 et Nic2 pour ne pas avoir les noms liés aux pilotes). Ces commandes sont à exécuter dans un terminal PowerShell.

> New-NetSwitchTeam -Name external -TeamMembers Nic1,Nic2
> New-VMSwitch -Name vSwitch -NetAdapterName external -AllowManagementOS $false
> Enable-VMSwitchExtension -VMSwitchName vSwitch -Name "Cloudbase Open vSwitch Extension"

Explications:

Création d’un teaming se nommant external ayant Nic1 et Nic2 comme membres
Création d’un switch virtuel Hyper-V se nommant vSwitch et ayant pour interface physique notre teaming précédemment créé: external
Activation de l’extension Open vSwitch sur le switch virtuel external

Petite vérification de routine afin de s’assurer que la création de notre teaming s’est correctement déroulée.

> Get-NetSwitchTeam

Name    : external
Members : {Nic1, Nic2

Une petite capture d’écran pour imager ce que vous devriez avoir via l’interface graphique Hyper-V:

L’activation de l’extension permet à Hyper-V de rediriger tout le trafic de son switch virtuel vers Open vSwitch. Sans l’activation de l’extension, toutes les commandes ovs-vsctl exécutées ne rendront pas la main.

Création de notre bond et de nos VLANs à l’aide d’Open vSwitch

Comme mentionné plus haut, le bonding ainsi que les VLANs seront gérés par Open vSwitch. Comme la partie userland d’Open vSwitch a été entièrement portée sous Windows, les commandes seront les mêmes que sous Linux (si familier avec vous êtes déjà).

> ovs-vsctl.exe add-br br-bond0
> ovs-vsctl.exe add-bond br-bond0 bond0 Nic1 Nic2 lacp=active bond_mode=balance-slb other_config:lacp-time=fast
> ovs-vsctl.exe add-port br-bond0 vlan53 tag=53 -- set interface vlan53 type=internal
> ovs-vsctl.exe add-port br-bond0 vlan70 tag=70 -- set interface vlan70 type=internal
> ovs-vsctl.exe add-port br-bond0 vlan72 tag=72 -- set interface vlan72 type=internal
> ovs-vsctl.exe add-port br-bond0 vlan73 tag=73 -- set interface vlan73 type=internal

Explications:

Création d’un bridge Open vSwitch nommé br-bond0
Création du bonding de type LACP nommé bond0 ayant Nic1 et Nic2 comme interfaces physiques
Création de l’interface vlan53 dans le bridge br-bond0 ayant pour VLAN ID 53

Le mode balance-slb sera l’algorithme utilisé par le bond LACP, le mode balance-tcp est à proscrire car d’expérience certains paquets peuvent être droppés.

Si nous listons les interfaces nous devrions voir nos interfaces physiques (NICx), notre teaming (external), notre bonding (br-bond0) et nos interfaces avec VLAN (vlanXX).

> Get-NetAdapter

Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
vlan73 Hyper-V Virtual Ethernet Adapter #6 28 Up 00-15-5D-1C-E9-0C 10 Gbps
vlan72 Hyper-V Virtual Ethernet Adapter #5 25 Up 00-15-5D-1C-E9-0B 10 Gbps
vlan70 Hyper-V Virtual Ethernet Adapter #4 24 Up 00-15-5D-1C-E9-0A 10 Gbps
vlan53 Hyper-V Virtual Ethernet Adapter #3 22 Up 00-15-5D-1C-E9-09 10 Gbps
br-bond0 Hyper-V Virtual Ethernet Adapter #2 21 Up 00-15-5D-1C-E9-08 10 Gbps
Nic2 HPE Ethernet 10Gb 2-port 560FLB Ad...#2 13 Up 8C-DC-D4-B7-21-45 10 Gbps
Nic1 HPE Ethernet 10Gb 2-port 560FLB Adapter 12 Up 8C-DC-D4-B7-21-44 10 Gbps
external Microsoft Network Adapter Multiplexo... 18 Up 8C-DC-D4-B7-21-44 20 Gbps

Si ces interfaces sont visibles cela signifie qu’elles sont aussi configurables et donc qu’elles peuvent être activées et avoir une adresse IP.

> Enable-NetAdapter br-bond0
> Enable-NetAdapter vlan53
> Enable-NetAdapter vlan70
> Enable-NetAdapter vlan72
> Enable-NetAdapter vlan73
> New-NetIPAddress -IPAddress 10.160.53.70 -InterfaceAlias vlan53 -PrefixLength 24
> New-NetIPAddress -IPAddress 10.160.70.70 -InterfaceAlias vlan70 -PrefixLength 24
> New-NetIPAddress -IPAddress 10.160.8.70 -InterfaceAlias vlan72 -PrefixLength 22 -DefaultGateway 10.160.11.254
> New-NetIPAddress -IPAddress 10.160.73.70 -InterfaceAlias vlan73 -PrefixLength 24

Interfaces activées et configurées, vous devriez être capable de lancer quelques ping et d’avoir la joie de contempler les réponses.

Du côté d’Open vSwitch, nous devrions être capable de voir le résultat incroyable de nos commandes précédentes.

> ovs-vsctl.exe show
0deb7824-eff5-42bc-9f8a-c9defb05628b
    Bridge "br-bond0"
        Port "bond0"
            Interface "Nic1"
            Interface "Nic2"
        Port "vlan53"
            tag: 53
            Interface "vlan53"
                type: internal
        Port "br-bond0"
            Interface "br-bond0"
                type: internal
        Port "vlan70"
            tag: 70
            Interface "vlan70"
                type: internal
        Port "vlan73"
            tag: 73
            Interface "vlan73"
                type: internal
        Port "vlan72"
            tag: 72
            Interface "vlan72"
                type: internal

Voilà enfin la partie la plus complexe terminée !

À ton tour OpenStack, viens là que je t’installe !

Maintenant que Windows, Hyper-V et Open vSwitch cohabitent tous ensemble dans la joie et la bonne humeur il est enfin possible de passer à l’installation d’OpenStack. Encore une fois, nous allons passer par l’installeur proposé par Cloudbase pour déployer OpenStack dans sa version Pike.

L’installeur vous posera plusieurs questions, comme:

Quels composants seront à installer
Quel switch virtuel utiliser ou à créer
URL, utilisateurs, mot de passe, options, etc…

Parce que je suis un mec sympa, je vous joins deux captures d’écran sur les choix à effectuer (je joue avec votre libre arbitre ^^).

La première capture consiste à vous montrer ce qu’il ne faut pas faire, à savoir sélectionner « Neutron Hyper-V Agent » !

La seconde vous montre quoi faire, étant donné que nous avons créé au préalable le switch virtuel Hyper-V il suffit simplement de sélectionner ce dernier dans la liste de switch existants. Pour ce qui est de la page suivante (que je n’ai pas pu capturer), cette dernière vous posera quelques questions importantes:

Quel protocole utiliser, dans notre cas ça sera VxLAN
L’adresse IP et le sous-réseau sur laquelle seront connectés les tunnels VxLAN

Une fois l’installation terminée et les services Nova, Neutron et Ceilometer démarrés, les bridges br-int, br-tun et br-data doivent apparaître dans Open vSwitch. Pour ce qui est de br-tun, des tunnels VxLAN entre les computes et les contrôleurs doivent être visibles.

    Bridge br-tun
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "vxlan-0aa0491f"
            Interface "vxlan-0aa0491f"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.160.73.70", out_key=flow, remote_ip="10.160.73.31"}
        Port "vxlan-0aa04921"
            Interface "vxlan-0aa04921"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.160.73.70", out_key=flow, remote_ip="10.160.73.33"}

Pour ce qui est de br-data, l’interface external fait office de passerelle entre Open vSwitch et Hyper-V (même si j’ai un léger doute sur ceci).

    Bridge br-data
        Port external
            Interface external
                error: "could not add network device external to ofproto (Invalid argument)"
        Port br-data
            Interface br-data
                type: internal

Dès lors, les agents Nova et Neutron sont listés et actifs; la création d’instances via les APIs OpenStack sur les compute Hyper-V est désormais possible !

Conclusion

Dans ce poste, j’ai volontairement passé quelques étapes non-utiles comme par exemple l’installation de Ceilometer ou de FreeRDP.

Notre quête de diversité au sein de notre plate-forme OpenStack fut toute une aventure pleine de rebondissements, j’espère que ce billet vous apportera l’aide nécessaire dans la vôtre !

Les points négatifs répertoriés pour le moment:

Impossible d’attacher un volume Ceph ou de créer une instance depuis un volume Ceph
- L’une des solutions consiste à utiliser Ceph iSCSI Gateway
- Autre problème, il n’existe aucun pilote Cinder pour RBD/iSCSI
La live migration fonctionne uniquement si les hyperviseurs Hyper-V sont connectés à un Active Directory
FreeRDP n’est pas compatible avec la ligne de commande OpenStack