Comme pour les solutions logicielles utilisées traditionnellement afin de gérer les infrastructures distribuées (cf. chapitre 1), les LGIV sont chargés d’exploiter deux grands types de ressources : les ressources de calcul et les ressources de sto-ckage.
3.2.1 Ressources de calcul
Bien que la terminologie varie fortement d’un LGIV à l’autre, la façon d’orga-niser les ressources de calcul reste relativement similaire.
Nœuds de calcul et hyperviseurs supportés
La plus petite granularité de travail est le nœud de calcul ; chaque nœud de calcul héberge un hyperviseur.
Les solutions académiques et communautaires sont assez tolérantes en matière d’hyperviseurs ; elles sont en effet capables de gérer des nœuds sur lesquels sont installés KVM, Xen (ou ses dérivés XenServer et Xen Cloud Platform), ESX(i), ou même Hyper-V dans le cas d’OpenStack. Nimbus est la seule exception, puisque seuls KVM et Xen sont reconnus.
A contrario, les solutions propriétaires privilégient généralement l’hyperviseur conçu par la même entreprise. Ainsi, VMware vCloud et vSphere tirent parti des fonctionnalités de ESXi, et l’écosystème Citrix XenServer n’accepte que des nœuds tournant sous l’hyperviseur éponyme. En revanche, Microsoft SCVMM s’accom-mode aussi bien de Hyper-V que de ESX ou de XenServer.
Unité de regroupement
La plus petite unité de regroupement, qui offre également le plus de flexibi-lité dans la gestion des nœuds de calcul, équivaut à un ensemble (de taille arbi-traire) de nœuds appartenant à une même grappe. Cette unité est nommée VMM poolpour Nimbus, virtual datacenter pour OpenNebula (avec l’extension oZones), host groups pour SCVMM, et resource pool pour vCloud/vSphere, XenServer et OpenStack.
La grappe (ou cluster) est l’autre unité de gestion couramment rencontrée, no-tamment avec Eucalyptus, OpenNebula et CloudStack.
Multiples des unités de regroupement
Le premier multiple de ces unités correspond généralement à une fraction d’un centre de données et de calculs. Cela s’appelle availability zone pour Nimbus et OpenStack, private cloud pour SCVMM, virtual datacenter pour vCloud, et pod pour CloudStack.
Le plus grand multiple est la zone, typiquement un centre de données et de calculs. Ce concept apparaît dans OpenNebula (avec l’extension oZones) et Cloud-Stack, et est en cours de développement pour OpenStack. La gestion des zones peut avoir plusieurs finalités : (i) proposer une isolation forte entre utilisateurs de deux zonesdifférentes, (ii) diminuer le temps d’accès en aiguillant les utilisateurs vers la zonequi est la plus proche d’eux géographiquement, ou encore (iii) mettre en place une zone de secours qui est capable de prendre le relais en cas de défaillance de la zoneprincipale.
3.2.2 Ressources de stockage
L’organisation des ressources de stockage suit une approche similaire à celle des ressources de calcul.
Stockage local des nœuds de calcul
Certaines solutions font appel au stockage local des nœuds de calcul pour conser-ver tout ou partie du contenu des disques durs des machines virtuelles. L’utilisation du stockage local permet de garantir un niveau de performance élevé.
Nimbus stocke l’intégralité des images disque des machines virtuelles sur les nœuds de calcul. OpenNebula et CloudStack peuvent également être configurés pour fonctionner de cette manière.
En revanche, Eucalyptus et OpenStack ne stockent que les partitions racines des machines virtuelles sur les nœuds de calcul, chaque partition racine contenant le système d’exploitation invité et la plupart des applications d’une machine virtuelle. Stockage partagé
En complément ou en remplacement du stockage local, nombre de solutions sont conçues pour tirer parti d’un espace de stockage partagé par les nœuds de calcul d’une même unité. De même que précédemment, cet espace de stockage sert à conserver une partie ou la totalité des images disque des machines virtuelles.
Eucalyptus et OpenStack stockent exclusivement les données utilisateurs per-sistantes des machines virtuelles sur un support partagé. Eucalyptus utilise pour cela des storage controllers (chacun d’entre eux étant associé à un cluster), tandis qu’OpenStack se sert de Cinder.
Les autres solutions recourant à du stockage partagé s’en servent pour conser-ver l’intégralité des images disque des machines virtuelles, ainsi que les instanta-nés (à l’exception de CloudStack qui garde les instantainstanta-nés ailleurs, comme nous le verrons par la suite). Cela permet notamment de migrer à chaud des machines virtuelles entre des nœuds ayant accès au même système de stockage partagé. Pour cela, SCVMM utilise des storage pools (adjoints aux host groups), vCloud/vSphere des datastores (assignés aux resource pools), et XenServer des storage repositories (alliés aux resource pools). Si OpenNebula et CloudStack ont été configurés afin de tirer parti d’un stockage partagé, ils utilisent respectivement des datastores et des primary storagesassociés aux clusters.
Stockage secondaire
En plus du stockage local et/ou partagé, un stockage secondaire est utilisé à l’échelle des multiples des unités de regroupement des nœuds de calcul, afin de conserver des données qui ont une longue durée de vie et qui n’ont pas besoin d’être accédées très rapidement, notamment :
– les instantanés, quand ils ne sont pas stockés sur un support partagé ; – les modèles de machines virtuelles ;
– éventuellement d’autres types de données.
Eucalyptus se sert de Walrus comme stockage secondaire, Nimbus de Cumulus, OpenNebula d’un template repository, SCVMM d’un VMM library, vCloud de datastores spécifiques, XenServer de storage repositories particuliers, CloudStack d’un secondary storage, et OpenStack de Glance (pour les modèles et les instanta-nés) et de Swift (pour tout autre type de données).
Les informations relatives à l’organisation des ressources physiques sont réca-pitulées dans le tableau3.1.
Nom Hyperviseurssupportés Ressources de calcul Ressources de stockage Eucalyptus
3.1.1 *ESXi*KVM *Xen
clusters(aussi appelés
availability zones) *local (partitions racines)*storage controllers (stockage persistant des VMs)
*Walrus (modèles, instantanés) Nimbus 2.10 *KVM
*Xen
*vmm pools *availability zones
*local (images disque)
*Cumulus (modèles, instantanés) OpenNebula 3.8 *ESX *KVM *Xen *clusters *virtual datacenters (1 VDC = partie d’un cluster) *zones (1 zone = 1 centre de données)
*local (images disque des VMs actives, si copie en local à l’instanciation des VMs) *local du frontend (images disque des VM arrêtées, si copie en local à l’instanciation des VMs)
*datastores (images disque, instantanés, iso)
*template repository (modèles) SCVMM 2012 *ESX
*Hyper-V *XenServer
*host groups *private clouds
*storage pools (images disque, instantanés)
*vmm library (modèles, iso) vCloud /
vSphere 5.1 ESXi *resource pools (1 RP =partie d’une grappe ; grappe max 32 nœuds) *vCloud provider virtual datacenters(1 PVDC = 1 cluster vSphere) *vCloud organization VDC(1 OVDC = partie d’un PVDC)
*datastores (images disque, instantanés, iso, modèles vCloud) *stockage de la machine client ou URL (modèles vSphere)
XenServer 6.0 XenServer resource pools(1 RP = partie d’une grappe ; grappe max 16 nœuds)
storage repositories(images disque, instantanés, iso, modèles) CloudStack 4.0.0 *ESX*KVM *Xen, XenServer *clusters *pods *zones (typiquement un centre de données)
*local (images disque, si configuré ainsi)
*primary storage (cluster ; images disque, si configuré ainsi) *secondary storage (zone ; modèles, iso et instantanés) OpenStack Folsom *ESXi *Hyper-V *KVM *Xen, XenServer, Xen Cloud Platform *resource pools *availability zones *zones (travail en cours)
*local (partitions racines) *Cinder, anciennement Nova volume workers(stockage persistant des VMs) *Glance (modèles, iso, instantanés)
*Swift (tout autre type de données)
TABLEAU3.1 – Organisation des ressources physiques