Gestion


Destiné aux équipes opérationnelles, l'outil de management facilite et sécurise l'administration du centre de données. Il permet de faciliter la gestion en proposant un langage dédié à l'administration simple, synthétique, permettant de piloter rapidement des centres composés de plusieurs centaines de serveurs et de plusieurs milliers de machines virtuelles. Il permet de sécuriser l'administration par l'utilisation de règles de placement. Ces règles d'administration permettent, entre autres, de forcer un ensemble de VM à s’exécuter sur un ensemble de serveurs (et inversement), d'empêcher des VM de cohabiter sur un même ensemble de serveur ou à l'inverse de regrouper des VM sur un même ensemble de serveurs.

L’utilisation d’un langage pour administrer une infrastructure de taille conséquente fournit une alternative intéressante aux gestionnaires de VM. En effet, l’utilisation d’un langage permet à l’administrateur l’utilisation de scripts et la manipulation d’ensembles d’éléments de grande taille. Le langage a été classé d’après trois sous-domaines de l’administration : la description de l’infrastructure, la sélection d’éléments au sein d’une infrastructure et la reconfiguration d’une infrastructure virtualisée.


1. Description des vues d'un centre de données


La description de l’infrastructure est utilisée pour construire une représentation de l’infra- structure interne à l’outil d’administration. Cette description comprend de nombreuses informations sur l’organisation des ressources dans l’infrastructure. Ces informations seront ensuite utilisées par le langage de gestion de l’infrastructure afin de sélectionner efficacement des éléments et de faciliter la reconfiguration de l’infrastructure.

Une infrastructure comme un centre de données doit être perçue sous différents angles afin d’en faciliter son administration. Par exemple, une vue physique permettra de décrire de manière hiérarchique l'architecture physique du centre de données en précisant qu'un serveur X se trouve dans une baie B elle même dans le couloir C situé dans la salle S du centre de données DC situé dans la ville V. Une vue électrique permettra de décrire que la prise P est connecté au disjoncteur D du tableau basse tension T alimenté par l'arrivée A. Ces vues sont génériques et paramétrables en fonction du contexte d'utilisation de btrCloud.

Une fois les vues décrites, il est alors aisé pour un administrateur de manipuler ces abstractions et de déterminer, par exemple, quelle est la consommation instantanée des serveurs connectés sur le disjoncteur D. Pour ce faire, il utilisera le langage proposé par la brique logicielle btrScript, présentée ci-après.


2. Navigation dans les vues


Chaque élément d'un centre de données (prise, serveur, baie) se voit attribuer un type lors de la description de l’infrastructure. Ces types sont reliés entre eux afin de créer une hiérarchie cohérente entre les éléments. À partir de cette hiérarchie typée, il est alors possible de récupérer tous les fils d’un élément grâce à l’opérateur « / ». Cette opération est appelée une navigation. Prenons la hiérarchie de types suivante : ville -> centre -> baie -> serveur. Un élément de type « ville » contient donc des éléments de type « centre » représentant des centres de données qui sont composés de baies contenant, à leur tour, des serveurs.

La sélection de tous les éléments de type « ville » se fait en utilisant l’opérateur « / » :

/ville
> nantes, lille
L'obtention de tous les fils d'un élément est possible en utilisant une navigation sur le type. Par exemple, l’obtention des fils de type « centre » du site « nantes » est alors effectuée par la navigation suivante :
nantes/centre
> emn-center, polytech-center
La réponse permet de savoir qu’il existe deux centres de données localisés à Nantes. Cette navigation est dite « directe » car le type « centre » suit le type « ville » dans la hiérarchie. La navigation de type « indirect » est aussi autorisée. Les types intermédiaires sont alors omis. Par exemple, la liste de tous les serveurs du centre de données nommé « emn-center » est obtenue par la navigation :
emn-center/serveur
> kvm1, kvm2, kvm3, kvm4
Les noms des serveurs sont ainsi obtenus et peuvent être utilisés pour une navigation. Dans les exemples précédents, les navigations débutent d’un élément père pour atteindre des éléments fils. Les navigations étant bidirectionnelles, il est possible de connaître le site hébergeant le serveur « kvm1 » avec la commande suivante :
kvm1/site
> nantes
Lors d’une navigation fils/père, un seul élément sera obtenu car si un père peut avoir plusieurs fils, un fils ne peut avoir qu’un seul père. La navigation est aussi utilisée pour parcourir les ponts et donc, naviguer d’une vue à une autre. Ajoutons à notre exemple, une deuxième vue contenant des VM et possédant la hiérarchie suivante : utilisateur -> vm. Un pont entre les types « serveur » et « vm » est créé pour symboliser la relation d’hébergement entre un hyperviseur et ses VM. À l’aide d’une navigation directe, on peut alors lister toutes les VM présentes sur un serveur :
kvm1/vm
> vm1, vm4
Une navigation indirecte permet d’obtenir tous les serveurs utilisés par l’utilisateur « invite1 » :
invite1/serveur
> kvm2, kvm3


3. Construction d'ensembles d'éléments


Afin d’exécuter une introspection ou une reconfiguration sur plusieurs éléments, la construction d’un ensemble d’élément est nécessaire. Dans ce but, l’opérateur « [] » permet la sélection de plusieurs éléments d’après leur nom.
Cet opérateur permet d’exprimer des énumérations afin de sélectionner plusieurs éléments ayant des noms proches. Par exemple, les éléments « serveur1 », « serveur2 », « serveur3 » et « serveur4 » sont sélectionnés à partir de l’expression suivante : serveur[1-4].
La création d’un ensemble d’éléments peut utiliser les opérateurs « [] » et « / » dans la même expression :

[ nantes/serveur & invite[1-2]/serveur ]
À l’aide des opérateurs de constructions d’ensembles, l’administrateur peut sélectionner des ensembles importants d’éléments. Ces sélections vont ensuite être utilisées pour obtenir des informations sur l’infrastructure et réorganiser les ressources.
La sélection de tous les éléments ayant une partie de leur nom commune est effectuée à l’aide du caractère «*».


4. Opérations sur les ensembles


Pour les éléments possédant des noms radicalement différents, l’opérateur « [] » propose la construction d’ensembles à partir des opérations ensemblistes traditionnelles. Toutes les expressions ci-dessous sélectionnent uniquement les serveurs « serveur1 », « serveur2 », « serveur3 » et « serveur4 » :


5. Gestion des propriétés


Nom de la propriété Définition
cpu La capacité d'un processeur
cpu_nb Le nombre de processeurs (pour les serveurs) ou de VCPU (pour les machines virtuelles)
cpu_cons La consommation CPU en pourcentage
cpu_free La quantité de CPU disponible en MHz
mem La capacité mémoire
mem_cons La consommation mémoire en pourcentage
mem_free La quantité de mémoire disponible en Mo
power_cons La consommation électrique
power_min La consommation électrique minimale d'un serveur
power_max La consommation électrique maximale d'un serveur
mac L'adresse MAC
ip L'adresse IP
La consultation d’une propriété par l’administrateur est effectuée avec l’opérateur « : ». Par exemple, la consommation CPU du serveur nommé « serveur1 » s’écrit : serveur1:cpu_cons. La consultation d’une propriété n’existant pas ou n’ayant pas de valeur renvoie la valeur « empty ».
Afin de garantir la flexibilité du modèle, les propriétés peuvent être ajoutées et modifiées par l’administrateur après la construction du modèle. L’ajout de propriétés permet de prendre en compte l’évolution de l’infrastructure.


6. Filtres et sélections


Les propriétés associées aux éléments peuvent être utilisées pour effectuer une sélection plus précise d’un ou plusieurs éléments. En effet, des filtres peuvent être utilisés pour sélectionner un ou plusieurs éléments parmi un ensemble préalablement sélectionné. Par exemple, la sélection de tous les serveurs ayant un hyperviseur est définie grâce à l’opérateur « == » de la façon suivante :

\serveur{role == hyperviseur}
Des fonctions peuvent aussi être utilisées afin d’obtenir une sélection de plusieurs éléments possédant des propriétés communes. Par exemple, la sélection des serveurs ayant la plus forte et la plus faible consommation CPU s’écrit respectivement :
\serveur{max(cpu_cons,1)} 
\serveur{min(cpu_cons,1)}
Le deuxième paramètre des fonctions « max » et « min » représente le nombre d’éléments à sélectionner. Par exemple, la sélection des trois VM ayant le plus de mémoire est précisée par l’expression :
\vm{max(mem,3)} 
La création de filtres basés sur la structure de l’infrastructure sont aussi disponible. De cette manière, l’administrateur peut sélectionner tous les serveurs hébergeant au moins une VM :
\serveur{size(vm) > 1}


7. Actions


La création de l’image disque d’une nouvelle VM dans btrScript est une copie d’une image disque modèle préalablement créée.

serveur1:createvm(vm[1-3],lenny)
Afin de simplifier la syntaxe de l’opération de création de VM, les informations nécessaires à l’initialisation de la VM sont décrites dans un modèle de VM nommé « template ». Ce modèle regroupe le nombre de VCPU, la mémoire et le modèle de l’image disque à copier. Ainsi, pour la création d’une VM, seuls le nom de l’élément et le modèle de la VM sont à préciser. La création de la VM ne démarre pas la VM et donc ne consomme pas de ressource. Cette opération permet d’enregistrer toutes les caractéristiques de la VM afin de permettre l’opération de démarrage de la VM :
vm1:start
Si aucun serveur n’est donné à l’opérateur « start », la VM est démarrée sur le serveur sur lequel elle a été crée. Dans le cas d’un espace de stockage partagé entre plusieurs serveurs, la VM peut être démarrée sur un de ces serveurs. Dans ce cas, un serveur peut être spécifié lors du démarrage :
vm1:start serveur2
Les autres actions disponibles sont :
vm1:stop
vm1:destroy
vm1:suspend
vm1:resume
vm1:reboot
La gestion des applications d’une VM ou d’un serveur en cours d’exécution peut être faite à l’aide de l’opérateur « exec » responsable d’exécuter des commandes sur la VM. L’administrateur peut alors lancer ou arrêter des applications comme un serveur d’application tomcat :
vm1:exec(/lib/tomcat/startup.sh)
La migration d’une VM est effectuée à l’aide de l’opérateur « migrate » :
vm1:migrate serveur2


8. Les règles de placement


Les règles « on » vont forcer un ensemble de VM à s’exécuter sur un ensemble de serveurs. L’administrateur pourra alors forcer des VM à s’exécuter sur les machines les plus puissantes. La règle suivante force les VM « vm1 », « vm2 » et « vm3 » à être hébergées par les serveurs « serveur1 » ou « serveur2 » :

vm[1-3] on serveur[1,2] 
Les règles « noton » vont forcer un ensemble de VM à ne pas s’exécuter sur un ensemble de serveurs. Cette règle permettra de faciliter l’écriture des règles « on ». Si l’administrateur veut forcer l’exécution d’une VM sur toutes les serveurs de l’infrastructure sauf une, il sera plus aisé de décrire le serveur sur laquelle la VM ne doit pas s’exécuter.
vm[1-3] noton serveur1 
Les règles « spread » empêchent des VM de cohabiter sur le même serveur. Cette règle permet de mettre en place des politiques de tolérance aux pannes. Si un service est dispensé par trois VM, l’administrateur doit s’assurer que les trois VM s’exécutent sur des serveurs différents. Si un des serveurs tombe en panne, deux VM continuent d’offrir le service. La règle suivante empêche la cohabitation des VM « vm1 », « vm2 » et « vm3 » :
vm[1-3] spread 
Les règles « group » regroupent des VM sur le même serveur. Pour des raisons d’efficacité, l’administrateur peut regrouper des VM qui communiquent entre elles via le réseau. La règle suivante regroupe les VM « vm1 », « vm2 » et « vm3 » sur le même serveur :
vm[1-3] group


9. Gestion des règles de placement


L’administrateur dispose de quatre opérateurs afin de gérer les règles de placement :

À l’aide des règles de placement, l’administrateur précise l’organisation des éléments afin d’exprimer des besoins précis. Cependant, les règles n’engendrent pas de reconfigurations qui seront effectuées par l’administrateur au moment opportun.

Les règles de placement peuvent être activées ou désactivées automatiquement :
[00:6:14:4:12:*] vm1 on serveur1
[00:6:*:*:*:5,6 - 00:20:*:*:*:5,6] vm2 on serveur2
La première règle sera activée le 14 avril 2012 à 6h. La deuxième règle sera activée à 6h et désactivée à 20h tous les samedis et dimanches.

Chaque programmation utilise la syntaxe suivante :
mm hh jj MM JJ ma_tâche
mm : les minutes de l’horaire
hh : l’heure de l’horaire
jj : le jour de l’horaire
MM : le mois de l’horaire
JJ : le jour de la semaine (par exemple, 5 désigne le vendredi)

Chaque champs peut utiliser les notations suivantes :
* : chaque unité (0, 1, 2, 3,..., 8, 9) ;
5,8 : les unités 5 et 8 ;
2-5 : les unités de 2 à 5 (2, 3, 4, 5) ;
*/3 : toutes les 3 unités (0, 3, 6) ;
10-20/3 : toutes les 3 unité entre 10 et 20 (10, 13, 16, 19).


10. Appel au module d'optimisation


Dans une infrastructure de taille conséquente, il peut être difficile à l’administrateur de résoudre plusieurs problèmes de surcharge survenant simultanément, par exemple, lors d’une hausse conséquente des consommations des VM. Dans ce cas, l’opérateur « solve » propose à l’administrateur l’utilisation d’algorithmes de placement calculant les reconfigurations nécessaires afin de résoudre les problèmes de surcharges :

/serveur:solve(checker)
Cet opérateur prend en paramètre le nom de l’algorithme à utiliser. Suivant l’algorithme sélectionné, l’administrateur pourra tenter de résoudre les problèmes de surcharge en favorisant une politique d’ordonnancement. Dans l’exemple précédent, l’algorithme « checker » permet de corriger les problèmes de surcharges en exécutant le moins de reconfigurations possibles. La mise en place d’une politique d’ordonnancement comme l’équilibrage de charge ou la consolidation devient compliquée pour une infrastructure possédant de nombreuses VM. Les algorithmes « loadbalancing » et « consolidation » vont alors permettre à l’administrateur d’effectuer respectivement un équilibrage de charge et une consolidation sur l’ensemble ou une partie de l’infrastructure.