Intégration OpenNebula 5.4 dans le laboratoire BOSSTEK

Depuis 2012, BOSSTEK intègre une solution de gestion des environnements virtuels pour le fonctionnement de son laboratoire, le Lab BOSSTEK. La définition des utilisateurs de ce service se fait par le biais de l'appartenance au groupe BosstekVDC au niveau de l'annuaire LDAP. Ce groupe est attribué automatiquement aux consultants et permet de partager les ressources virtuelles au sein de ce datacentre virtuel. Cette solution répond au besoin de gestion des ressources d'infrastructures (espace de stockage, réseaux, système d'exploitation, gestion des accès, etc) nécessaires aux différents projets internes et également des tests ponctuels (travaux de support, reproduction d'incidents, expérimentation, proof-of-concept, etc). Ce service typiquement appelé IaaS (Infrastructure as a Service) est accessible depuis le portail SSO. Il est largement et quotidiennement utilisé par les consultants de la société.

Depuis la version 3.8, le service technique a continuellement conduit les montées de version sans difficultés particulières. Seule exception, l'adaptation du code source du module Sunstone d'OpenNebula afin de permettre la connexion au service via le portail SSO de l'entreprise sous LemonLDAP.

Chez BOSSTEK le service technique a pour mission de maintenir à niveau la disponibilité et la sécurité du système d'information. Conscient de l'utilisation quotidienne des environnements du laboratoire, une interruption de service n'est pas envisageable. Une question se pose : comment effectuer la migration de la version 4.12 à la version 5.4 d'OpenNebula en minimisant le temps d'interruption du service au maximum.

Important

La migration OpenNebula 4.12 vers 5.4 oblige (entre autres) de passer à la version 2 de Ruby au niveau des hyperviseurs gérés par OpenNebula. Ce changement de version et de ses dépendances impose la migration du système d'exploitation et par conséquent, implique une interruption de service. Il faut savoir que les pilotes de gestion d'OpenNebula sont des scripts bash et Ruby lancés à distance par secured shell (SSH). Il est facile de comprendre que si la version correspondante de Ruby n'est pas correcte, les pilotes ne fonctionnent plus correctement et la stabilité de l'ensemble est compromise. Conclusion : dans le cas de BOSSTEK, l'opération de migration vers OpenNebula 5.4 impose de migrer les systèmes d'exploitation depuis CentOS 6 vers CentOS 7.

Impacts

Dans le cadre de la montée de version de cette solution de gestion d'infrastructure, le laboratoire BOSSTEK doit subir une intervention importante de migration de tous les hyperviseurs de recette et de production. Dans la mesure où l'infrastructure est utilisée en journée par les applications en production et les utilisateurs du laboratoire (consultants et développeurs), cette intervention doit être testée, reproductible, réversible, sécurisée et si possible de courte durée (l’objectif donné est de deux heures maximum).

Dans un premier temps, ces quatre critères ont orienté le choix de l'intervention technique vers une installation des hyperviseurs par boot PXE (installation automatisée par le réseau). L'installation doit se faire avec comme pré-requis : la préparation de l'espace disque de sorte que l'installation ne soit à l'origine d'aucune perte de données. Les tests de migrations par cette méthode ont offert de bons résultats en phase de test et l'intervention a été rapidement planifiée.

Catastrophe

Le jour J de l'opération, les environnements ont été stoppés (suspended) le temps de l'installation mais une surprenante erreur lors de l'installation du système CentOS 7 remet en cause toute l'opération. Le message d'erreur anaconda : "no valid bootloader target device found" compromet la mise en place du double boot. L'erreur à l'origine de cet incident est déconcertante. La source de cet incident n'est pas analysée d'avantage et l'opération est annulée. Le service est rétabli immédiatement. Une autre méthode est rapidement étudiée et la solution de migration par dump de disque est retenue. Cette méthode a pour avantage de pouvoir anticiper la copie de l'ensemble des données du système d'exploitation sans coupure de service et de réduire l'opération de bascule à une simple relance du système (avec l'opération supplémentaire d'autorelabel SELINUX dans notre cas). L'autre avantage important de cette technique est la possibilité de retour arrière par simple relance sur l'ancien système encore présent sur l'hyperviseur, ce qui est gage de réversibilité et de sécurité.

Le détail de cette opération sera exposé dans une prochaine publication car cette technique est très intéressante pour les migrations de serveurs distants. Ceci pour les deux raisons principales suivantes : préparation et bascule sur le nouveau système ; retour arrière par relance sur l'ancien système en cas d'invalidation de l'opération.

Résultat

Au deuxième essai, le lendemain, les hyperviseurs sont tous relancés sur leurs nouvelles versions du système CentOS 7.4 / Ruby 2 et l'instance OpenNebula avec sa nouvelle version 5.4 sont maintenant en place. Quelques incidents anecdotiques sont survenus lors de la migration de la base de données technique d'OpenNebula mais globalement, l'opération a été un succès !

Qu'apporte la nouvelle version OpenNebula 5.4 par rapport à la version 4.12 ?

Les routeurs virtuels

Permet de définir un serveur DHCP/NTP interne à OpenNebula ou une passerelle (règles de translation réseau - NAT) entre le réseau publique et le réseau privé des machines virtuelles.

Les groupes de VM

Permet de définir des modèles de groupe de VM et d'influencer le gestionnaire de déploiement (scheduler) lors de leurs répartitions sur les différents hyperviseurs du datacenter virtuel. Cette fonctionnalité s'appuie sur la gestion des affinités et anti-affinités. Celle-ci va bénéficier d'amélioration dans les prochaines versions.

Le groupe de sécurité pour le réseau

Permet de gérer des profils de sécurité sous forme de groupe et d'appliquer par défaut ou spécifiquement des flux autorisés / interdits au niveau des modèles de VM.

Topologie graphique des noeuds et des réseaux virtuels :

Le VXLAN

Le VXLAN permet d'encapsuler des VLAN privés au niveau d'un environnement Cela permet de définir et d'isoler les sous VLAN à l'intérieur d'un VLAN fédérateur. OpenNebula propose un "VLAN natif" sur une interface physique de l'hyperviseur mais notre préférence est de permettre l'utilisation des VXLAN sur les interfaces virtuelles d'openvswitch. Un driver openvswitch compatible VXLAN doit être créé à cet effet. Malheureusement, en l'état la seule solution est de modifier le driver openvswitch d'Opennebula, c'est à dire qu'il n'est pas possible de créer un driver indépendant pour l'instant.

La possibilité de redéfinir la configuration des VM avant déploiement

Jusqu'à présent, modifier un modèle pour le personnaliser impliquait d'en créer un nouveau ou de modifier l'existant. Dorénavant, il est possible d' "intercepter" et de modifier la configuration d'une VM avant son déploiement.

La gestion des adresses IP avec une connexion à un IPAM (IP Adress Manager)

Jusqu'à présent l'attribution dynamique des adresses IP par DHCP ne pouvait se faire que par DHCP externe et l'utilisateur ne pouvait pas retrouver l'adresse du bail DHCP dans son interface OpenNebula. Désormais, avec IPAM les adresses sont gérées et récupérables dans l'interface OpenNebula.

Le redimensionnement à chaud des disques des VM

Il est possible de redimensionner les disques des VM sans les arrêter, bien-sûr une intervention technique est nécessaire sur le système d'exploitation de la VM pour rendre visible cette augmentation.

La gestion des hotfix par le service de support pour les versions intermédiaires (exemple 5.4.3 par le service de support ONE)

Pour l'instant les versions correctrices d'OpenNebula ne sont plus mises à disposition de la communauté. Dorénavant seul les versions majeures sont présentes dans les dépôts.

Nous sommes heureux de pouvoir utiliser la toute nouvelle version d'OpenNebula et nous félicitons toute l'équipe projet pour leurs innovations et la qualité de leurs travaux. Il nous reste à explorer et tester les nouvelles fonctionnalités d'OpenNebula 5.4. Nous publierons nos retours d'expériences sur les points qui nous auront marqués sous forme de notes technique.

À tous les membres de l'équipe d'OpenNebula nous souhaitons une bonne continuation et aux autres, longue route et une bonne utilisation. Profitez de l'open source et à bientôt !