Google PlusFacebookTwitter

Hyper-V, Nova, VxLAN et Open vSwitch, enfin une belle histoire !

By on Déc 31, 2017 in OpenStack, Windows | 0 comments

Share On GoogleShare On FacebookShare On Twitter

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):

  1. Il n’est pas nécessaire d’ajouter un second mechanism_drivers (openvswitch, hyperv) au ML2
  2. 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:

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):

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.

Explications:

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

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à).

Explications:

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).

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.

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.

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:

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:

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.

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).

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:

Liens

The following two tabs change content below.

Gaëtan Trellu (goldyfruit)

Cloud Operations Lead chez Ormuco
Autodidacte en informatique, depuis 2005 je parcours l’écosystème Unix à la recherche de nouvelles connaissances et de nouvelles rencontres.

CC BY 4.0 Hyper-V, Nova, VxLAN et Open vSwitch, enfin une belle histoire ! par Gaëtan Trellu (goldyfruit) est sous Licence Creative Commons Internationale Attribution 4.0.