Skip to content

Cluster Ganeti avec Xen et Saltstack

ganeti-bannerNous allons voir comment mettre en place un système de Virtualisation stable et performant sur un système Linux. Pour cela, nous allons utiliser l’hyperviseur Xen, géré par l’outil de management de virtualisation Ganeti (écrit par Google) et le tout managé par le gestionnaire de configuration Saltstack.

Pour mettre en place un cluster Ganeti, il faut plusieurs serveurs (d’où le terme cluster), le but est d’avoir un système redondé qui permet la création de machines virtuelles et leurs migrations dans ce cluster sans interruption de services. Si les performances sont adéquates, un cluster Ganeti peut héberger plusieurs centaines de VMs.
La configuration que j’ai mis en place permet la création de machine virtuelles Debian 8.1 et Ubuntu 14.04 en 64bits, avec kernel propre, disque /boot séparé, partitions en LVM et script automatisé de création et de clonage de VM.

Dans ce tutoriel, nous allons voir comment mettre en place cette configuration sur deux serveurs Debian avec installation minimal. Les performances peuvent variés selon vos serveurs, cependant, il faut favoriser de gros disques (pour stocker les machines) et beaucoup de RAM (pour faire tourner les machines). La vitesse de lecture/écriture peut être importante également, favoriser des SSD si possibles.

Voici les étapes de ce tutoriel :

  1. Installation des paquets nécessaires
  2. Configuration de Xen et Ganeti
  3. Configuration de SaltStack
  4. Mis en place du cluster
  5. Création de machines virtuelles
  6. Gestion du cluster

Voici la configuration IP que nous allons utiliser :

  • Serveur 1 – gnt-master.ouvrard.it – 192.168.1.50
  • Serveur 2 – gnt-node1.ouvrard.it – 192.168.1.60
  • Cluster – gnt-cluster.ouvrard.it – 192.168.1.55

Ganeti doit utiliser une IP en plus, celle du cluster.

I – Installation des paquets nécessaires

On va commencer par installer quelques paquets qui pourront nous être utiles, les commandes sont à saisir en root :

apt-get update
apt-get install htop screen git python-pip lvm2 vlan vim

Ensuite on va mettre en place Xen :

apt-get -y install xen-linux-system xen-tools
dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
sed -i '/TOOLSTACK/s/=.*/=xl/' /etc/default/xen

Maintenant que Xen est correctement installé, on va mettre en place la configuration réseau dans le fichier /etc/network/interfaces :

auto  eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet static
  address   192.168.1.50
  broadcast 255.255.255.255
  netmask   255.255.255.0
  gateway   192.168.1.1
  bridge_ports eth0
  bridge_stp off       # disable Spanning Tree Protocol
  bridge_waitport 0    # no delay unless port available
  bridge_fd 0          # no forwarding delay

Il faut adapter les adresses selon vos serveurs, votre interface réseau ou votre adressage.
Une fois que cela est mis en place sur nos deux serveurs, on les redémarrent comme ceci :

reboot

Une fois redémarrés, on devrait pouvoir lancer la commande xl info qui nous rapporte des information sur notre hyperviseur Xen.
Si cela ne fonctionne pas, il se peut que votre serveur n’ait pas redémarré sous Xen, vérifiez le configuration de grub.

Xen est désormais installé et fonctionnel, on va installer Ganeti et DRBD (le système de disques redondés utilisé par Ganeti).

apt-get install ganeti2 ganeti-instance-debootstrap
apt-get install drbd8-utils
echo "options drbd minor_count=128 usermode_helper=/bin/true" \ > /etc/modprobe.d/drbd.conf 
echo "drbd" >> /etc/modules 
depmod -a 
modprobe drbd

Voilà, tous nos paquets nécessaires sont installés !

2 – Configuration de Xen et Ganeti

On va s’occuper de configurer Xen et Ganeti afin qu’ils tournent au mieux.
Ces commandes sont à saisir sur les deux serveurs (tant que le contraire n’est pas indiqué).

On va créer le répertoire .ssh :

mkdir /root/.ssh

On va restreindre les performances du Dom0 (hyperviseur des VMs) en ajoutant cette ligne à la fin du fichier /etc/grub/default :

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin"

Cela le restreint à 1Go de RAM et 1vCPU (largement suffisant).

Une étape importante est de désactiver la sauvegarde automatique des VMs par Xen, car si on oublie cela, on peut vite se retrouver avec notre partition /var remplit.
Pour cela on édite le fichier /etc/default/xendomains :

XENDOMAINS_SAVE=

Xen est à présent configuré, on va s’occuper de Ganeti.
On va commencer par créer un lien symbolique du Kernel dans la partition /boot (pour le premier démarrage des VMs) :

cd /boot
ln -s vmlinuz-3.16.0-4-amd64 vmlinuz-3-xenU
ln -s initrd.img-3.16.0-4-amd64 initrd-3-xenU

On peut ensuite éditer le fichier /etc/hosts (à adapter sur les deux serveurs) :

127.0.0.1	localhost
192.168.1.50	gnt-master.ouvrard.it    gnt-master
192.168.1.55	gnt-cluster.ouvrard.it   gnt-cluster
192.168.1.60    gnt-node1.ouvrard.it     gnt-node1

Ganeti se base sur LVM pour créer les VMs, pour cela, il faut qu’on ait un Volume Group qu’on va nommer « vgganeti« , pour cela on saisit les commandes suivantes (à adapter selon vos disques) :

pvcreate /dev/sda2
vgcreate vgganeti /dev/sda2

On peut désormais éditer le fichier de configuration central à Ganeti, qui est en json plus ou moins illisible (en une ligne), recherchez donc les occurrences à modifier avec vim (ou un autre éditeur).
Le fichier se situe dans /var/lib/ganeti/config.data

"xen_cmd":"xl"},
"link":"xenbr0",
"initrd_path":"/boot/initrd-3-xenU",
"kernel_args":"ro",
"kernel_path":"/boot/vmlinuz-3-xenU",
"min disk-size":"150",
"master_netdev":"xenbr0",
"link":"xenbr0",
"volume_group_name":"vgganeti", 
"metavg":"vgganeti",

Ce fichier n’est normalement pas à éditer à la main, pour la première fois, cela ne pose pas problème, mais on n’y touchera plus par la suite.
Xenbr0 correspond à l’interface bridge qu’on à créée, xl correspond à la commande pour manipuler Xen et  vgganeti correspond au VG LVM qu’on a créé.

La configuration de Xen et Ganeti est terminée, on va pouvoir redémarrer une dernière fois les serveurs avant d’attaquer la suite :

reboot

3 – Configuration de SaltStack

salt-logo-

Saltstack (ou Salt) est gestionnaire de configurations, de déploiements et de saisies de commandes à distances très personnalisable et performant (écrit en Python). Il permet de gérer des dizaines voir des centaines de serveurs.

Nous verrons dans un autre tutoriel son utilisation de manière plus poussés.
Dans notre cas, nous allons l’utiliser dans notre cluster seulement pour déployer nos fichiers de configurations lié à Ganeti sur nos nodes afin d’éviter de potentiels problèmes qui nuirait à la stabilité de notre configuration (comme des fichiers disparus ou des paquets manquants).

Salt fonctionne avec le principe de master et minions, comme Ganeti fonctionne avec master et nodes. Dans notre cas, on va installer salt-master sur le serveur Ganeti-Master et salt-minion sur le serveur Ganeti-Node. Cependant, la configuration qu’on souhaite déployer avec Salt doit également être présent sur le Master, pour cela on installe également salt-minion sur le master !

On commence par ajouter le dépôt Salt à Debian (sur les deux serveurs) puis installer les paquets voulus (master et/ou minion) :

echo "deb http://debian.saltstack.com/debian jessie-saltstack main" > /etc/apt/sources.list.d/salt.list
wget -q -O- "http://debian.saltstack.com/debian-salt-team-joehealy.gpg.key" | apt-key add -
apt-get install salt-master salt-minion # ou salt-minion seulement

Maintenant que Salt est installé, on va commencer par relier le master et le minion, pour cela on saisit ces commandes sur le Master :

salt-key -L     # devrait lister les minions
salt-key -A gnt-node1.ouvrard.it     # autorise ce minion
salt-key -A gnt-master.ouvrard.it    # autorise lui même
salt '*' cmd.run 'echo Nous sommes les minions contrôlés par le master !'

Si la dernière commande vous renvoie la phrase magique, c’est que salt-minion est correctement contrôlé par le Master.

On va pouvoir mettre en place notre configuration du cluster Ganeti dans Salt pour qu’il l’a déploie sur lui même et sur les différents nodes.

Les fichier de Salt sont à placer dans /srv/salt, la configuration de Ganeti se trouve sur mon Github, on va donc cloner le dépôt dans /srv/salt/ganeti et configurer le déploiement des nos fichiers (à faire uniquement sur le master) :

mkdir /srv/salt
git clone https://github.com/valentin2105/Ganeti.git ganeti
cd ganeti
mv saltstack.sls init.sls

On a désormais une state « ganeti » (une configuration utilisable par Salt grâce au fichier init.sls) qui déploie la configuration qu’on souhaite avoir sur nos nodes. Cependant actuellement, nous n’attribuons cette state à personnes, pour cela il faut créer le fichier /srv/salt/top.sls :

base:  
  '*':
    - ganeti

Dans ce fichier, nous attribuons la state ganeti à tout nos nodes (*).
Notre state Ganeti est attribué à des nodes (2 dans notre cas), on va pouvoir déployer notre configuration avec cette commande :

salt '*' state.highstate

State.highstate permet d’appliquer aux nodes tous les states attribués, dans notre cas, il déploie notre configuration de Ganeti. Si tout s’est bien passé,  vous devriez avoir quelque chose comme cela :

gnt-highstate

Cela confirme que toute la configuration à était déployer sur le node concerné.

Pour aller plus loin avec Salt, je vous conseille de lire la Doc officielle (très bien faite).

Vous pouvez également cloner mon dépot ‘Salt-recipe‘ pour ajouter d’autres configurations à vos serveurs (monit, apt, pkg …)

4 – Mis en place du cluster

Notre cluster est prêt à être initialisé, nous avons Xen et Ganeti de configurés, notre configuration de déployée, il ne reste plus qu’à créer véritablement le cluster, pour cela, il faut saisir cette commande sur le master :

gnt-cluster init --vg-name=vgganeti --master-netdev=xenbr0 gnt-cluster.ouvrard.it

On initialise le cluster, en lui précisant le VG voulus, l’interface voulus et le nom du cluster.

Si votre installation s’est bien passé, Ganeti devrait vous confirmer la bonne création du cluster. On a donc un cluster prêt à l’emploi, mais avec aucun nodes ! (c’est embêtant)

On peut donc ajouter le (ou les) nodes à notre cluster avec la commande suivante :

gnt-node add gnt-node1.ouvrard.it

On vérifie les différents nodes de notre cluster :

gnt-node list

On vérifie la « bonne santé » de notre cluster :

gnt-cluster verify

Si aucune erreur ne s’affiche, notre cluster composé de deux nodes est correctement mis en place.

5 – Création de machines virtuelles

Une fois qu’on a déployé la configuration et qu’on a initialisé le cluster, on va pouvoir commencer à créer des VMs. Pour cela, j’ai fait un script nommé newVM.sh qui permet d’automatiser cette tâche.

Si vous avez déployé la configuration via Saltstack comme dans ce tutoriel, le script devrait être placé dans /usr/local/bin, cela permet donc de l’utiliser directement,

Il va cependant falloir éditer le début du script pour mettre en place les bon paramètres. Pour cela on édite le fichier /srv/salt/ganeti/newVM.sh (sur le master) :

# Ganeti master hostname
GNT_MASTER="gnt-master.ouvrard.it"
# Any Ganeti Node for secondary DRBD
GNT_NODE="gnt-node1.ouvrard.it"
DEFAULT_VLAN=""
VG_MASTER="vgganeti"

On déploie notre modification sur tous les nodes grâce à Salt :

salt '*' state.highstate

On peut maintenant créer notre première VM :

newVM --name masupervm.io --ram 3G --disk 12g

Le script devrait vous afficher un récapitulatif qui demandera une confirmation avant de commencer. De base, il s’agit d’une VM Debian 8.

newVM
Pour afficher l’aide du script (et les différentes options) faite ceci :

newVM --help

On peut facilement spécifier plus de paramètres lors de la création d’une VM, par exemple :

newVM --name virtserv2.ouvrard.it --ram 3g --disk 15g --ipv4 192.168.1.32 --gw 192.168.1.1 --netmask /24 --variant trusty --vcpu 4

Voici les processus de création d’une VM :

  1. Création de la VM (debootstrap dans LVM)
  2. Démarrage de la VM sur le Kernel du dom0
  3. Mis à jours de grub
  4. Reboot de la VM
  5. Mis en place du propre kernel
  6. Démarrage finale de la VM

Si la configuration des disques est en DRBD, la création de la VM sera un peu longue à cause de la copie du disque à travers le réseau (env 5mn pour 10g de disque). Si vous faite une VM en plain-disk (sur un seul serveur) cela est plus rapide (env 1mn).

N’hésitez pas à regarder la documentation de DRBD pour le configurer à votre grès (de base ça fonctionne très bien).

Le script est fait pour vérifier que la configuration du cluster est correct avant de commencer la création d’une VM. Si vous avez utilisé Saltstack, aucun problème de devrais se poser.

Vous pouvez facilement cloner une VM existante avec la commande suivante :

newVM --name virtserv1-clone.ouvrard.it --disk 10g --ram 3g --clone virtserv1.ouvrard.it

Lors d’un clonage, la VM à cloner sera éteinte, le disque monté, la nouvelle VM créer et finalement la copie est effectué grâce à Rsync.

6 – Gestion du cluster

Nous allons voir comment manipuler les machines virtuelles qu’on à créées.
Pour lister les VMs, on utilise cette commande :

gnt-instance list

De base nos VMs sont en primaire sur le master et en secondaire sur le node1, pour switcher d’un serveur à l’autre (sans interruption de service) on utilise cette commande :

gnt-instance migrate virtserv1.ouvrard.it

Si on à plus de deux nodes, il peut être intéressant de migrer le disque secondaire vers un autre serveur, cela prend plusieurs minutes (selon la taille du disque) :

gnt-instance migrate-disks gnt-node2.ouvrard.it virtserv1.ouvrard.it

Pour lister tous les nodes du cluster, on utilise la commande suivante :

gnt-node list

Pour vérifier la « santé » de notre cluster, on fait cela :

gnt-cluster verify-disk
gnt-cluster verify

Pour évacuer (proprement) un node, on saisit cette suite de commandes :

gnt-node migrate <node>
gnt-node failover <node>
# on marque le node "offline"
gnt-node modify -C no -O yes <node>

Avec les commandes précédentes, vous devriez pouvoir gérez correctement votre Cluster, et permettre une haute disponibilité de vos serveurs grâce à Ganeti et DRBD. Si l’un de vos serveur physiques à des problèmes (disques ou autre) vous migrerez rapidement les VMs le temps de réparer votre node.

Si vous avez des questions, n’hésitez pas !

Voici quelques liens utiles,

https://wiki.osuosl.org/ganeti/common_commands.html#node-commands

Migration d’instances Xen dans un Cluster Ganeti


http://www.wepoca.net/howto/install-ganeti-cluster-hetzner/
http://mancoosi.org/~abate/how-create-vms-ganeti-xen-and-dnsmasq
https://www.ceondo.com/notes/ganeti/
https://wiki.arn-fai.net/ganeti

Présentation de Ganeti

sans oublier la documentation officiel de Ganeti :

http://docs.ganeti.org/ganeti/2.14/html/install.html

Published inLinuxScriptsTutorielVirtualisation

Be First to Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Proudly hosted with Open-sources Softwares.