OpenNebula et cluster LVM
Je vous propose de voir comment utiliser OpenNebula dans le cas où l’on utilise un stockage centralisé à base de LVM. Nous verrons rapidement dans cet article le principe du stockage LVM en cluster puis nous verrons comment l’intégrer à notre cluster OpenNebula.
Introduction
Une question m’avait été posée par un lecteur à propos de l’utilisateur de LVM dans le cas d’une utilisation d’OpenNebula en cluster. Je vous présente aujourd’hui comment mettre en place cette architecture qui est composée d’un frontend (frontend.local
) OpenNebula ainsi que de deux hôtes (node1.local
et node2.local
) ainsi qu’un SAN (san.local
) que l’on va joindre en utilisant iSCSI.
Le SAN sera donc partagé entre les différents serveurs composant le cluster OpenNebula. On utilisera pour cela iSCSI en créant une seule cible qui sera utilisable par les différents serveurs. Nous utiliserons LVM pour pouvoir partitionner l’espace de stockage afin de créer les différents disques dur des VMs. Pour que plusieurs serveurs puissent accéder à ce partitionnement, on utilise clvm pour que plusieurs serveurs puissent y accéder simultanément.
Enfin, il va falloir ajouter ce nouvel espace disque à notre cluster OpenNebula. Pour cela, nous devrons créer deux datastores : un pour les images disques et l’autre pour les disques systèmes. Dans cet article, l’installation est réalisée sous CentOS 6.
Préparation de LVM
Les différentes commandes de cette section sont à faire à la fois sur le frontend et sur les nodes.
Installation du client iSCSI
D’abord, nous allons installer le client iSCSI et nous connecter à la cible :
root# yum -y install iscsi-initiator-utils
root# iscsiadm --mode node --targetname iqn.2000-01.com.synology:diskstation.opennebulacluster --portal san.local --login
Une fois cette opération réalisée, nous allons pouvoir installer LVM sur tous les hôtes.
Installation de LVM
Vous devez d’abord installer clvm, et nous allons l’activer l’option correspondante dans la configuration de LVM.
root# yum -y install lvm2-cluster
root# lvmconf --enable-cluster
root# chkconfig clvmd on
On ajoute le fichier /etc/cluster/cluster.conf
:
<cluster name="mycluster" config_version="2">
<clusternodes>
<clusternode name="node1.local" nodeid="1">
</clusternode>
<clusternode name="node2.local" nodeid="2">
</clusternode>
</clusternodes>
</cluster>
A l’intérieur de se fichier on ajoute le nom des différents nœuds. Ensuite, on démarre les différents services associés.
root# service cman start
root# service clvmd start
Création du Volume Group
Après avoir installé LVM en cluster, nous allons créer les Physical Volume (PV) et Volume Group (VG) correspondant :
root@frontend# pvcreate /dev/sdb
root@frontend# vgcreate OpenNebula /dev/sdb
Je crée donc un PV incluant le disque /dev/sdb
puis je crée un VG nommé “OpenNebula” incluant le PV que l’on vient de créer.
Pour le démarrage de la VM
Ensuite, nous allons ajouter l’utilisateur oneadmin
dans le groupe disk
:
root@node1# usermod -G disk oneadmin
Configuration d’OpenNebula
Création du datastore image
Les opérations suivantes se font avec l’utilisateur “oneadmin” :
root@frontend# su - oneadmin
Nous allons d’abord créer le datastore utilisé pour stocker les images sources des VMs. Il est nécessaire d’avoir un datastore LVM pour stocker les images, on crée donc le fichier ds-lvm-images.one
:
NAME = "LVM images"
DS_MAD = lvm
TM_MAD = lvm
DISK_TYPE = block
VG_NAME = OpenNebula
BRIDGE_LIST = frontend.local
Description des paramètres utilisés :
NAME
: nom du datastoreDS_MAD
: driver gérant l’ajout et la création d’imageTM_MAD
: driver gérant l’image lors de l’instanciation de la VMDISK_TYPE
: le type est ici àblock
car on utilise LVM en mode blockVG_NAME
: nom du Volume GroupBRIDGE_LIST
: liste des hôtes exécutant LVM serveur, dans mon cas j’ai choisi de mettre uniquement le frontend dedans
Nous pouvons créer le datastore :
oneadmin@frontend$ onedatastore create ds-lvm-images.one
Ajout d’une image
Comme je l’ai expliqué dans l’article précédent, nous allons créer une image Debian, voici le fichier img-debian.one
:
NAME = "Debian Wheezy"
PATH = /templates/debian-wheezy.qcow2
PUBLIC = YES
DESCRIPTION = "Debian Wheezy with SSH, no GUI."
BUS = "virtio"
DEV_PREFIX = "vd"
DRIVER = "qcow2"
On ajoute l’image dans le datastore que l’on vient de créer :
oneadmin@frontend$ oneimage create -d "LVM images" img-debian.one
Il faut patienter un peu le temps que l’image se copie sur le datastore. Il est possible de suivre l’état de l’image grâce à la commande oneimage list
. L’état “lock” signifie que l’image est encore en train de se télécharger.
Création du datastore système
Le datastore système est utilisé pour stocker le disque de contextualisation et un lien symbolique vers l’image disque de la VM. Il n’a pas connaissance du mode de stockage utilisé pour sauvegarder l’image. Il n’est pas nécessaire de créer ce nouveau datastore si vous en avez déjà un de ce type. Pour le créer quand même, nous éditons un fichier ds-system.one
:
NAME = "system"
TYPE = SYSTEM_DS
TM_MAD = shared
Le seul paramètre intéressant dans notre configuration est le TM_MAD
. Il indique par quel moyen le frontend enverra l’image de contextualisation et créera le lien symbolique. Il y a trois valeurs possibles : shared
est utilisé quand le datastore est partagé entre chaque nœuds et le frontend (par exemple en utilisant NFS). ssh
est utilisé lorsqu’il n’y a pas de dossier partagé, on utiliser alors SSH pour copier les fichiers. Cela nécessite que le frontend puisse se connecter en SSH à tous les nœuds. Enfin, vmfs
peut être utilisé quand on utilise les technologies VMware pour les nœuds.
Après avoir créé le fichier, nous pouvons créer le datastore :
oneadmin@frontend$ onedatastore create ds-system.one
Conclusion
Notre infrastructure est maintenant en place, il ne vous reste plus qu’à créer les modèles (templates) en utilisant les images de notre nouveau datastore. Lors de l’instanciation d’une VM, l’image disque sera cloné vers un nouveau Logical Volume, cette opération est réalisée avec la commande dd
et prend beaucoup de temps.
Pour améliorer le système, il est possible de modifier les “drivers” qui permettent le déploiement. Le fichier /var/lib/one/remotes/tm/lvm/clone
est en charge de l’opération de clonage. Il serait intéressant de voir s’il est possible d’optimiser cette opération.