tuto:virtualisation:cluster_dedibox [WikiT]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Cluster HA entre deux dedibox ======

<note>Sauf mention contraire, toutes les commandes sont à lancer sur les deux hyperviseurs. Seule la gestion de gluster peut se faire depuis un seul des deux</note>

===== But =====

Le but de ce how-to est de monter un cluster qui hébergera des machines virtuelles. Il utilisera deux serveurs de chez [[http://online.net|Online]] (on a pas d'action chez eux, c'est juste que leurs offres sont très agressives ^^) en tant qu'hyperviseurs. Il doit être possible de:

  * Migrer à chaud des machines virtuelles de l'un vers l'autre (pour maintenance planifiée, répartition de charge etc...), sans perte de connectivité
  * Attribuer des IP publiques à des invités (via les IP Failovers de Online.net), sans aucun filtrage, ni NAT: les VM ont leur adresse IP publique directement connectée à Internet
  * La possibilité d'attribuer plusieurs IP Failover à une seule machine virtuelle
  * Créer des réseaux virtuels isolés (une partie publique, et autant de réseaux privés que nécessaire, tous parfaitement étanches entre eux)
  * Les réseaux virtuels ne doivent pas être liés aux hyperviseurs (si deux invités sont reliés au même réseau logique, ils peuvent se contacter peu importe sur quel hyperviseur ils tournent)
  * Redémarrer rapidement des invités en cas de crash d'un des hyperviseurs
  * Perdre aucune donnée en cas de crash d'un hyperviseur
  * Empêcher le démarrage de la même machine virtuelle sur les deux hyperviseurs en même temps (ce qui corromprait presque immédiatement le disque de l'invité)


<note tip>Une toute petite partie est vraiment spécifique aux serveurs d'Online, la majorité peut être ré-utilisée pour monter un cluster sur des serveurs hébergés chez vous</note>
===== Composants =====

  * Deux serveurs [[http://www.online.net/fr/serveur-dedie|dedibox]] PRO (hyperviseur et serveur de stockage)
  * [[http://www.centos.org|CentOS]] 6 x86_64 (système hôte)
  * [[http://libvirt.org|libvirt]] (API de gestion de la virtualisation)
  * [[http://wiki.qemu.org/|qemu]]-kvm (l'hyperviseur)
  * [[http://virt-manager.org/|virt-manager]] (l'interface graphique de gestion des machines virtuelles)
  * [[http://www.gluster.org/|GlusterFS]] (solution de stockage distribué)
  * [[http://openvpn.net/index.php/open-source.html|OpenVPN]] (pour créer les tunnels entre les deux hyperviseurs)
  * [[https://fedorahosted.org/sanlock/|sanlock]] (gère les verrous sur les disques et empêche de démarrer la même machine virtuelle sur les deux hyperviseurs en même temps)
  * Quelques notions en réseau et virtualisation (bien maitriser une installation simple de libvirt + KVM + virt-manager vous sera probablement utile)
  * Un peu d'huile de coude
  * Quelques pack de bières et/ou une grande cafetière selon vos préférences

===== Schéma global =====

Voilà une représentation schématique de ce qu'on cherche à obtenir:

{{:tuto:virtualisation:dedibox_ha.png|Schéma global de l'installation}}

===== Prérequis =====

==== À préparer sur la console online.net ====

  * Deux serveur dedibox PRO (ou supérieur, l'important étant de disposer de l'option RPN)
  * Accès iLO / iDRAC sur les deux serveurs (pour installer CentOS via le média virtuel)
  * Créer un groupe RPN, et y assigner les deux serveurs, rendez-vous sur [[http://documentation.online.net/fr/serveur-dedie/tutoriel/rpn-by-online.net|cette page]] pour savoir comment faire

<note important>Il est vivement recommandé de prendre l'option RPN-G (pour avoir du gigabit sur le réseau RPN), sinon par défaut, c'est du 100M, ce qui impactera les performances des invités puisqu'il y a une réplication synchrone entre les deux hyperviseurs</note>

===== Installation des systèmes hôtes =====


La première étape est d'installer une CentOS 6 (6.4 étant la dernière version actuellement) en édition x86_64. CentOS n'étant plus supportée par l'installateur d'Online ((CentOS 6.4 est de nouveaux disponible maintenant, mais l'installation via le média virtuelle reste possible)), il faut d'abord installer n'importe quel système (une debian par exemple), puis, une fois installé, on peut accéder à l'interface iLO (ou iDRAC selon la marque du serveur, iLO pour les IBM, iDRAC pour les Dell). On peut ensuite charger un applet java (oui, beurk, mais c'est toujours mieux que de l'activeX :-) ) pour prendre la main sur la console du serveur (une sorte de KVM sur IP) ainsi qu'un lecteur CD virtuel. Il faut simplement connecter une ISO netinstall de CentOS dans ce lecteur virtuel et redémarrer le serveur, qui va s'amorcer dessus. L'amorce peut prendre du temps selon la vitesse de votre connexion, puisque l'image netinstall sera streamée depuis votre poste.


La suite de ce how-to considère que:


    * Les deux hyperviseurs sont installés, avec les noms hyp1 et hyp2 respectivement
      * L'IP publique de hyp1 est 88.190.30.8
      * l'IP privée (réseau RPN) de hyp1 est 10.25.9.46
      * l'IP publique de hyp2 est 88.190.30.9
      * l'IP privée (réseau RPN) de hyp2 est 10.25.9.47
    * LVM a été utilisé pour gérer le partitionnement, et l'unique groupe de volumes (VG) se nomme **main**
===== Désactivation des services =====


Certains services ne sont pas nécessaires et sont donc désactivés maintenant. 


<code bash>
chkconfig ip6tables off
chkconfig iptables off
/etc/init.d/iptables stop
/etc/init.d/ip6tables stop
</code>

<note>Ne prenez pas peur, on va remettre du filtrage dans la suite bien entendu, mais c'est en général plus simple de monter la base sans avoir à s'embêter avec un firewall</note>
===== Optimisations des hyperviseurs =====

==== Réglages systèmes ====

Pour éviter des chutes de performances, il faut éviter à tout prix de swapper, quitte à exploiter moins de cache. On désactive aussi l'IPv6 puisqu'on ne s'en servira pas dans notre cas

<code bash>
echo "vm.swappiness=0" >> /etc/sysctl.conf
echo "vm.vfs_cache_pressure=10000" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
sysctl -p
</code>

Avec cette configuration, le swap ne devrait être utilisé que pour éviter un OOM (dans la pratique, il semble que le swap soit toujours un peu utilisé, même si moins qu'avant. La version 6.4 de CentOS semble utiliser beaucoup plus facilement le swap, espérons que ce comportement soit corrigé dans la 6.5)
===== Préparation de l'environnement =====
Dans cette étape, nous allons, sur chacun des hyperviseurs, créer quelques fichiers texte simples, qui contiennent des variables. Ça simplifiera la suite

<code bash>
mkdir /etc/install
chmod 700 /etc/install
echo hyp1 > /etc/install/hostname
echo hyp2 > /etc/install/peer_hostname
echo firewall-services.com > /etc/install/dnsdomainname
echo 10.25.9.46 > /etc/install/rpn_ip
echo B4:B5:2F:51:9B:61 > /etc/install/rpn_mac
echo 10.25.8.47 > /etc/install/rpn_peer_ip
echo 1 > /etc/install/host_id
echo 37651 > /etc/install/online_sdx
echo xxxxxxxxxxxxxxxxxxxxx > /etc/install/api_key
</code>

Faites la même chose sur hyp2, en adaptant les valeurs.

<note important>la valeur de host_id doit impérativement être différente entre hyp1 et hyp2. C'est cet identifiant qui sera utilisé pour la gestion des verrous sur les disques</note>
<note>Dans cet exemple, 37651 est l'identifiant de votre serveur Online (vu dans votre console comme sd-37651). Adaptez cette valeur à l'identifiant de votre dedibox</note>
<note important>xxxxxxxxxxxxxxxxxxxxx est votre clé pour l'accès à l'API Online, vous pouvez la trouver sur cette page: https://console.online.net/fr/api/access

Gardez cette clé secrète, elle permet de gérer à distance vos serveurs, y compris les redémarrer</note>

===== Configuration des dépôts =====

Il va falloir ajouter quelques dépôts, certains composants logiciels n'étant pas disponibles dans les dépôts de base, ou leur version étant trop ancienne

==== Dépôt EPEL ====

Le dépôt EPEL contient de nombreux logiciels, et sera utilisé pour openvpn, ainsi que quelques outils de base

<code bash>
rpm -Uvh http://fr2.rpmfind.net/linux/epel/6/i386/epel-release-6-8.noarch.rpm
</code>

=== Installation d'outils de base ===
Maintenant que le dépôt EPEL est configuré, on peut en profiter pour installer quelques outils de base que je juge indispensables ;-)
<code bash>
yum install htop screen strace pbzip2 iftop iptraf man rsync bash-completion wget openssh-clients vim acpid tcpdump pciutils patch sysstat
</code>

==== Dépôt GlusterFS ====

La version de GlusterFS dans les dépôts de base est un peu vieillotte, et surtout, ne permet pas un recovery pendant que les fichiers sont ouverts. On va donc utiliser le dépôt RHEL fourni par gluster.org pour avoir une version plus récente.


<code bash>
wget -P /etc/yum.repos.d/ \
  http://download.gluster.org/pub/gluster/glusterfs/3.4/LATEST/RHEL/glusterfs-epel.repo
</code>

===== Installation des outils de virtualisation =====

Il faut maintenant installer les outils de base pour virtualiser tout notre petit monde

<code bash>
yum install libvirt qemu-kvm \
            bridge-utils policycoreutils-python
</code>


On va appliquer une configuration minimale, mais fonctionnelle de libvirt. Le but est de:

  * Gérer l'accès à libvirt uniquement via ssh (<nowiki>qemu+ssh://hyp1/system</nowiki> par exemple)
  * Donner cet accès à un utilisateur non privilégié, appelé **fws**

==== Activer KSM ====

KSM ((**K**ernel **S**ame page **M**erging)) est un mécanisme permettant de mettre en commun des pages mémoire identiques (y compris entre plusieurs invités). En utilisant un peu de CPU, on peut donc récupérer de la mémoire. Au plus vous faites tourner des systèmes identiques ou proche, au plus vous avez de chance d'voir des pages identiques, et donc d’économiser de la RAM. Le démon ksmtuned permet quand à lui de surveiller la pertinence et KSM (démarrage quand la mémoire vient à manquer, ajustement de l'agressivité du scan en fonction de la pression sur la RAM, désactivation quand ce n'est plus nécessaire etc...)

<code bash>
chkconfig ksm on
chkconfig ksmtuned on
mv /etc/ksmtuned.conf /etc/ksmtuned.conf.default
cat <<'EOF' > /etc/ksmtuned.conf
KSM_MONITOR_INTERVAL=10
KSM_SLEEP_MSEC=5
KSM_NPAGES_BOOST=600
KSM_NPAGES_DECAY=-200
KSM_NPAGES_MIN=64
KSM_NPAGES_MAX=4094
KSM_THRES_COEF=45
KSM_THRES_CONST=9144
LOGFILE=/var/log/ksmtuned.log
DEBUG=1
EOF
cat <<'EOF' > /etc/logrotate.d/ksmtuned
/var/log/ksmtuned.log {
        weekly
        missingok
        rotate 4
        compress
        delaycompress
        copytruncate
        minsize 100k
}
EOF
/etc/init.d/ksm start
/etc/init.d/ksmtuned start
</code>

<note>vous pouvez ajuster la configuration de ksmtuned, regardez le fichier /etc/ksmtuned.conf.default pour avoir une explication sur les différents paramètres</note>
==== Configuration de base de libvirt ====

<code bash>
mv /etc/libvirt/libvirtd.conf \
   /etc/libvirt/libvirtd.conf.default
cat <<EOF > /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 0
mdns_adv = 0
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
EOF
</code>

On va aussi empêcher le marquage des machines  virtuelles pour un démarrage automatique. Si pour un hyperviseur simple c'est une fonction intéressante, dans le cas d'un cluster, c'est plutôt dangereux, il vaut mieux maîtriser cette phase.

<code bash>
mkdir -p /etc/libvirt/qemu/autostart/
chattr +i /etc/libvirt/qemu/autostart/
</code>
==== Création d'un compte utilisateur non privilégié ====

<code bash>
useradd fws
passwd fws
</code>

<code bash>
groupadd libvirt
usermod -a -G libvirt fws
</code>

==== Configuration SELinux ====

Une variable SELinux doit être activée pour certains types de sauvegardes utilisant rsync.

<code bash>
setsebool -P rsync_export_all_ro=1
</code>

===== Configuration des interfaces privées (réseau RPN) =====

Sur les deux hyperviseurs, il faut maintenant configurer l'interface privée (celle connectée sur le réseau RPN, normalement eth1):
<code bash>
cat <<'EOF' > /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=__MAC__
ONBOOT=yes
NM_CONTROLLED=no
TYPE=Ethernet
BOOTPROTO=dhcp
MTU=9000
EOF
sed -i -e "s/__MAC__/$(cat /etc/install/rpn_mac)/g" \
    /etc/sysconfig/network-scripts/ifcfg-eth1
/etc/init.d/network restart
</code>

Si tout se passe bien, vous devriez pouvoir pinguer les deux hyperviseurs entre eux via le réseau RPN. Ça ne sert à rien d'aller plus loin tant que ça n'est pas le cas.

<note important>Les interfaces du réseau RPN doivent être configurée via le protocole DHCP, n'essayez pas de les mettre en IP fixe, ça ne fonctionnera pas</note>

===== Ajustement du fichier /etc/hosts =====
Il faut que les deux hyperviseurs puissent toujours se joindre, même en cas de problème de DNS, le plus simple est donc de rajouter quelques alias dans /etc/hosts

<code bash>
cat <<'EOF' > /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 __HOSTNAME__ __HOSTNAME__.__DOMAINNAME__
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
__PEER_IP__    peer __PEER_HOSTNAME__ __PEER_HOSTNAME__.__DOMAINNAME__
EOF
sed -i -e "s/__HOSTNAME__/$(cat /etc/install/hostname)/g" \
       -e "s/__DOMAINNAME__/$(cat /etc/install/dnsdomainname)/g" \
       -e "s/__PEER_IP__/$(cat /etc/install/rpn_peer_ip)/g" \
       -e "s/__PEER_HOSTNAME__/$(cat /etc/install/peer_hostname)/g" /etc/hosts
</code>

===== GlusterFS =====

GlusterFS sera utilisé pour fournir l'espace de stockage accessible depuis les deux hyperviseurs en simultané.

==== Installer les paquets nécessaires ====

<code bash>
yum install glusterfs-fuse glusterfs \
            glusterfs-server
</code>

==== Créer un volume GlusterFS pour le stockages des images ====

=== Créer un volume LVM ===

Les données exportées par GlusterFS seront stockées sur un volume LVM sur chaque hyperviseur. Dans cet exemple, on va créer un volume de 800Go. Vous pouvez ajuster en fonction de l'espace disponible sur vos serveurs.

<note>Pensez à garder un peu d'espace libre sur votre VG, pour les autres volumes (voir suite du how-to) et pour la prise de snapshots LVM)</note>
<note important>GlusterFS sera utilisé en mode réplication, il faut donc créer des volumes de tailles égales sur les deux hyperviseurs</note>

<code bash>
lvcreate -L 800G -n vmstore main
</code>

=== Formater ce volume ===

Red Hat recommande l'utilisation du système de fichier XFS pour l'utilisation de Gluster. Ext4 fonctionne aussi, à vous de voir celui que vous préférez

<code bash>
yum install xfsprogs
</code>

<code bash>
mkfs.xfs -f -i size=512 -L VMSTORE /dev/main/vmstore
</code>

=== Monter ce nouveau volume ===

Les volumes qui stockeront les données Gluster seront montés dans /mnt/bricks/<nom du volume>

  * Créer le point de montage
<code bash>
mkdir -p /mnt/bricks/vmstore
</code>

  * Ajouter une ligne à fstab pour le montage automatique, et monter immédiatement le volume
<code bash>
echo "/dev/main/vmstore    /mnt/bricks/vmstore    xfs    noatime    0    0" \
    >> /etc/fstab
mount -a
mount
</code>

=== Activer et démarrer le démon gluserd ===

<code bash>
chkconfig glusterd on
/etc/init.d/glusterd start
</code>

<note important>Faites la même chose (lvcreate, mkfs.ext4, montage etc...) sur le deuxième hyperviseur avant d'aller plus loin</note>

=== Contacter l'hyperviseur distant ===

Depuis un hyperviseur (peu importe lequel), on va vérifier la connectivité avec l'hyperviseur distants, via un //**probe**//

<code bash>
gluster peer probe hyp2
</code>

=== Créer le volume GlusterFS "vmstore" ===

<note tip>À faire sur un seul hyperviseur (peu importe lequel)</note>

<code bash>
gluster volume create vmstore replica 2 \
    hyp1:/mnt/bricks/vmstore hyp2:/mnt/bricks/vmstore
</code>

=== Démarrer le volume "vmstore" ===

<note tip>À faire sur un seul hyperviseur (peu importe lequel)</note>

<code bash>
gluster volume start vmstore
</code>

=== Réglage du volume ===

On peut faire quelques réglages sur ce volume pour améliorer les performances

<code bash>
gluster volume set vmstore nfs.disable on
gluster volume set vmstore network.ping-timeout 5
gluster volume set vmstore network.frame-timeout 300
</code>

Autres réglages recommandés pour optimiser les performances

<code bash>
gluster volume set vmstore performance.stat-prefetch off
gluster volume set vmstore performance.io-cache off
gluster volume set vmstore performance.read-ahead off
gluster volume set vmstore remote-dio on
gluster volume set vmstore cluster.eager-lock on
</code>
=== Ajout du point de montage ===
Ce nouveau volume GlusterFS sera monté dans /var/lib/libvirt/images, on pourra ensuite définir plusieurs pool de stockage:

<code bash>
echo "localhost:/vmstore    /var/lib/libvirt/images    glusterfs    defaults,_netdev    0    0" \
    >> /etc/fstab
chkconfig netfs on
mount -a
</code>



=== Autoriser les VM à utiliser des systèmes de fichiers FUSE ===

GlusterFS étant basé sur FUSE, il faut autoriser les VM à accéder aux systèmes de fichiers FUSE (SELinux le bloque par défaut):

<code bash>
setsebool -P virt_use_fusefs=1
</code>

===== Sanlock =====

le démon sanlock va permettre de poser des verrous sur les images disques, et ainsi d'empêcher la même machine virtuelle de démarrer en même temps sur les deux hyperviseurs (ce qui corromprait les données à coup sûre)

==== Installer les paquets ====

<code bash>
yum install libvirt-lock-sanlock
</code>

==== Démarrer le démon watchdog pour sanlock ====
wdmd agit comme un watchdog et forcera l'hyperviseur à redémarrer en cas de problème
<code bash>
chkconfig wdmd on
/etc/init.d/wdmd start
</code>

==== Créer un volume GlusterFS pour sanlock ====

sanlock doit pouvoir écrire sur un répertoire commun entre les deux hyperviseurs. Le plus simple est donc de créer un nouveau volume GlusterFS pour le stockage des verrous.

<note>Il faut compter 1Mo pour chaque verrous, soit pour chaque disque virtuel utilisé (si une VM utilise 3 disques -> 3 verrous), pensez donc à dimensionner correctement ce volume</note>

=== Préparation des bricks ===

<code bash>
lvcreate -L 10G -n sanlock main
mkfs.xfs -f -i size=512 -L SANLOCK /dev/main/sanlock
mkdir -p /mnt/bricks/sanlock
chown :sanlock /mnt/bricks/sanlock
chmod 770 /mnt/bricks/sanlock
echo "/dev/main/sanlock    /mnt/bricks/sanlock    xfs    noatime    0    0" >> /etc/fstab
mount -a
</code>

=== Création du volume GlusterFS ===

<note tip>À faire sur un seul hyperviseur (peu importe lequel)</note>

<code bash>
gluster volume create sanlock replica 2 \
    hyp1:/mnt/bricks/sanlock hyp2:/mnt/bricks/sanlock
gluster volume start sanlock
gluster volume set sanlock nfs.disable on
gluster volume set sanlock network.ping-timeout 5
gluster volume set sanlock network.frame-timeout 10
</code>

=== Configurer pour un montage automatique ===

<code bash>
echo "localhost:/sanlock    /var/lib/libvirt/sanlock    glusterfs    defaults,_netdev    0    0" \
    >> /etc/fstab
mount -a
</code>

<note important>Si vous utilisez ext3 ou ext4 à la place de xfs pour ce volume, il vaut mieux supprimer le répertoire /var/lib/libvirt/sanlock/lost+found sinon, il va générer des messages d'erreur dans les journaux de sanlock</note>
=== Démarrer le démon sanlock ===

<code bash>
chkconfig sanlock on
/etc/init.d/sanlock start
</code>

=== Configurer le plugin sanlock de libvirt ===

<code bash>
mv /etc/libvirt/qemu-sanlock.conf \
   /etc/libvirt/qemu-sanlock.conf.default
cat <<'EOF' > /etc/libvirt/qemu-sanlock.conf
auto_disk_leases = 1
host_id = __HOST_ID__
user= "sanlock"
group = "sanlock"
EOF
sed -i -e "s/__HOST_ID__/$(cat /etc/install/host_id)/g" \
    /etc/libvirt/qemu-sanlock.conf
</code>

<code bash>
mv /etc/libvirt/qemu.conf \
    /etc/libvirt/qemu.conf.default
cat <<'EOF' > /etc/libvirt/qemu.conf
lock_manager = "sanlock"
EOF
</code>

=== Autoriser l'utilisation de sanlock au niveau de SELinux ===

<code bash>
setsebool -P virt_use_sanlock=1
setsebool -P sanlock_use_fusefs=1
</code>


=== Redémarrer libvirt ===

<code bash>
chkconfig libvirtd on
/etc/init.d/libvirtd restart
</code>

À partir de maintenant, vous devriez pouvoir ajouter les connexions vers hyp1 et hyp2 dans virt-manager. Ne créez pas de machine virtuelle pour l'instant, vérifier juste que la connexion est OK (avec l'URI <nowiki>qemu+ssh://fws@hyp1/system</nowiki>)


=== Nettoyage des verrous ===

Dans certains cas, un verrou peut se perdre (crash d'une VM, crash du démon sanlock etc...), on va donc mettre en place une tâche cron qui va nettoyer les verrous qui ne devraient plus être là. Ces cas sont suffisamment rares pour que la tâche ne s'exécute qu'une fois par jour (une fois par semaine serait même probablement suffisant)

<code bash>
cat <<'EOF' > /etc/cron.daily/sanlock-cleanup
#!/bin/bash

# Sleep between 0 second and 30 minutes
# So hypervisors do not cleanup at the same time
sleep $[ $RANDOM % 1800 ]
/usr/sbin/virt-sanlock-cleanup >/dev/null 2>&1
EOF
chmod +x /etc/cron.daily/sanlock-cleanup
</code>

=== Déclaration des pools de stockage libvirt ===

On peut maintenant définir un premier pool de stockage pour les images ISO

<code bash>
mkdir -p /var/lib/libvirt/images/iso
cat <<'EOF' > iso.xml
<pool type='dir'>
  <name>iso</name>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images/iso</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

EOF
virsh pool-define iso.xml
virsh pool-start iso
virsh pool-autostart iso
</code>

On va aussi créer un second pool pour le stockage des images des VM. Vous pouvez créer autant de pool que nécessaire, par exemple, un pool (aka répertoire dans le volume Gluster) par client

<code bash>
mkdir -p /var/lib/libvirt/images/firewallservices
cat <<'EOF' > firewallservices.xml
<pool type='dir'>
  <name>firewallservices</name>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images/firewallservices</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

EOF
virsh pool-define firewallservices.xml
virsh pool-start firewallservices
virsh pool-autostart firewallservices
</code>

===== Création d'un espace commun pour les dumps mémoire =====

Libvirt peut utiliser une fonction de sauvegarde sur disque pour suspendre un invité en sauvegardant son état dans un fichier sur disque. Par défaut, ces dumps mémoire sont stockés dans /var/lib/libvirt/qemu/save. L'idéal est donc de créer un volume partagé entre les deux hyperviseurs (ainsi une VM suspendue sur l'un peu être réveillée sur l'autre). 

<code bash>
lvcreate -L50G -n save main
mkfs.xfs -L QEMU -i size=512 -f /dev/main/save
mkdir -p /mnt/bricks/save
echo "/dev/main/save    /mnt/bricks/save    xfs    noatime    0    0" \
    >> /etc/fstab
mount -a
</code>

Maintenant, on crée un volume gluster

<note tip>À faire sur un seul hyperviseur</note>
<code bash>
gluster volume create save replica 2 hyp1:/mnt/bricks/save hyp2:/mnt/bricks/save
gluster volume start save
gluster volume set save nfs.disable on
gluster volume set save network.ping-timeout 5
gluster volume set save network.frame-timeout 300
</code>

Puis on monte ce volume
<code bash>
echo "localhost:/save    /var/lib/libvirt/qemu/save    glusterfs    defaults,_netdev    0    0" \
    >> /etc/fstab
mount -a
</code>


===== Création des réseaux =====

On va maintenant créer deux réseaux pour les VM. Le premier, nommé **wan** sera utilisé pour connecter les VM à Internet (avec une IP publique), l'autre, nommé **lan** sera isolé et permettra de disposer d'un réseau privé. Les hyperviseurs n'ont pas d'accès à ces réseau, le routage entre le **lan** et le **wan** sera donc à charge d'une VM (qui aura une interface dans chaque réseau). Ces réseaux seront reliés à leur homologue entre les deux hyperviseurs via des tunnels OpenVPN, permettant de migrer une VM d'un hyperviseur à l'autre sans perte de connexion.
Tout le trafic entre les deux hyperviseurs se faisant sur le réseau privé (RPN), OpenVPN sera utilisé sans aucune authentification, ni chiffrement, afin d'économiser des ressources CPU.

==== Suppression du réseau "default" ====

Les réseau par défaut ne seront pas utilisés:

<code bash>
virsh net-destroy default
virsh net-undefine default
</code>

==== Réseau wan ====
On crée un bridge nommé brwan sur les hyperviseurs. Ce bridge n'aura pour l'instant aucune interface esclave:
<code bash>
cat <<'EOF' > /etc/sysconfig/network-scripts/ifcfg-brwan
DEVICE=brwan
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
EOF
</code>

==== Réseau lan ====
Même manipulation, pour le réseau lan avec un bridge brlan

<code bash>
cat <<'EOF' > /etc/sysconfig/network-scripts/ifcfg-brlan
DEVICE=brlan
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
EOF
</code>

==== Redémarrer la pile réseau ====

<code bash>
/etc/init.d/network restart
</code>

==== Tunnels entre les hyperviseurs ====
Il faut maintenant créer des tunnels entre les deux hyperviseurs pour relier les deux brwan entre eux, ainsi que les deux brlan (mais les deux réseau lan et wan resteront parfaitement étanches)

=== Script "up" pour OpenVPN ===

Ce script sera appelé par OpenVPN au démarrage de chaque tunnel, et il se chargera d'ajouter l'interface tap du tunnel au bridge correspondant (par exemple taplan sera ajouté automatiquement à brlan)

<code bash>
mkdir -p /etc/openvpn/bin
cat <<'EOF' > /etc/openvpn/bin/up
#!/bin/bash

sleep 2
TAP=$1
ID=${TAP#tap}
/sbin/ifconfig $1 0.0.0.0 up promisc
/usr/sbin/brctl addif br$ID $TAP
EOF
chmod +x /etc/openvpn/bin/up
restorecon -Rv /etc/openvpn
</code>

=== Ajustement SELinux ===
Par défaut, SELinux va empêcher OpenVPN de faire appel à brctl, il faut donc créer une politique de sécurité personnalisée.

<code bash>
cat <<'EOF' > mycluster.te
module mycluster 1.0;

require {
        type openvpn_t;
        type brctl_exec_t;
        class file { read execute open getattr execute_no_trans };
}

#============= openvpn_t ==============
allow openvpn_t brctl_exec_t:file { read execute open getattr execute_no_trans };
EOF
checkmodule -M -m -o mycluster.mod mycluster.te
semodule_package -o mycluster.pp -m mycluster.mod
mkdir -p /usr/share/selinux/packages/mycluster/
mv mycluster.pp /usr/share/selinux/packages/mycluster/
semodule -i /usr/share/selinux/packages/mycluster/mycluster.pp
</code>


=== Configuration des tunnels OpenVPN ===
Même si les deux hyperviseurs seront parfaitement équivalent, pour OpenVPN, il faut en définir un qui jouera le rôle de serveur, et l'autre de client. Dans cet exemple, hyp1 sera le serveur, et hyp2 le client

<code bash>
yum install openvpn
</code>
== Sur hyp1 ==

<code bash>
cat <<'EOF' > /etc/openvpn/wan.conf
lport 1195
proto udp
dev tapwan
user openvpn
group openvpn
up bin/up
persist-key
persist-tun
cipher none
ping 5
ping-restart 20
EOF
cat <<'EOF' > /etc/openvpn/lan.conf
lport 1194
proto udp
dev taplan
user openvpn
group openvpn
up bin/up
persist-key
persist-tun
cipher none
ping 5
ping-restart 20
EOF
semanage port -a -t openvpn_port_t -p udp 1195
</code>

== Sur hyp2 ==

<code bash>
cat <<'EOF' > /etc/openvpn/wan.conf
rport 1195
proto udp
dev tapwan
nobind
remote __PEER_IP__
up bin/up
user openvpn
group openvpn
chroot /etc/openvpn/
persist-key
persist-tun
cipher none
ping 5
ping-restart 60
EOF
cat <<'EOF' > /etc/openvpn/lan.conf
rport 1194
proto udp
dev taplan
nobind
remote __PEER_IP__
up bin/up
user openvpn
group openvpn
chroot /etc/openvpn/
persist-key
persist-tun
cipher none
ping 5
ping-restart 60
EOF
sed -i -e "s/__PEER_IP__/$(cat /etc/install/rpn_peer_ip)/g" \
    /etc/openvpn/wan.conf
sed -i -e "s/__PEER_IP__/$(cat /etc/install/rpn_peer_ip)/g" \
    /etc/openvpn/lan.conf
</code>
=== Activer et démarrer openvpn ===

<code bash>
chkconfig openvpn on
/etc/init.d/openvpn start
</code>

Si tout se passe comme prévu, les deux tunnels se monteront (vous pouvez vérifier dans /var/log/messages), et les deux bridges **brwan** et **brlan** auront une interface esclave chacune: respectivement **tapwan** et **taplan**

<note tip>Il est possible de créer autant de réseaux isolés entre eux que nécessaire, en suivant la même procédure que pour le réseau **lan**</note>

====== Échange des clés SSH entre hyperviseurs ======

Cette étape est optionnelle, puisque toutes les migrations, créations, etc... pourront se faire depuis l'outil graphique virt-manager. Cependant, si vous voulez aussi pouvoir gérer les migrations en ligne de commande, le mieux est de générer quelques clés SSH et de les échanger entre les différents hyperviseurs. Sur chaque hyperviseur, il faut:

  * Générer une clé SSH pour le compte root (ssh-keygen -t rsa -b 4096)
  * Déposer cette clé sur le compte fws de l'hyperviseur distant (ssh-copy-id fws@hyp2)

====== Configuration du par feu sur les hyperviseurs ======

Maintenant que la majorité est en place, il est temps de se préoccuper du par feu sur les hyperviseurs. Étant le cœur de l'infrastructure, inutile de préciser que leur sécurité est primordial. L'accès ne doit être possible que depuis des IP de confiances, et uniquement par SSH. Shorewall sera utilisé pour définir les règles de par feu.

<code bash>
yum install shorewall
</code>

===== Définition des interfaces =====

Shorewall utilise la notion de zones pour établir des règles de filtrage, en général, une zone correspond à une réseau accessible depuis une interface donnée. Dans notre configuration, chaque hyperviseur à 3 zones sur lesquels un filtrage doit/peut être appliqué:

  * eth0: cette interface relie l'hyperviseur au réseau publique, et doit faire l'objet d'une politique strict. On nommera cette zone **wan**
  * brwan: cette interface relie les machines virtuelles disposant d'une IP publique. Les hyperviseurs ne doivent pas réellement faire de filtrage entre eth0 et brwan, mais simplement passer les paquets dans un sens comme dans l'autre. Cette zone sera appelée **pwan** (pour proxy wan)
  * eth1: cette interface relie l'hyperviseur au réseau privé RPN, ce réseau étant isolé physiquement, il n'y a pas de filtrage à appliquer, on peut donc autoriser tout le trafic. Cette zone sera appelée **rpn**

Contenu du fichier /etc/shorewall/interfaces:
<file bash interfaces>
#
# Shorewall version 4 - Interfaces File
#
# For information about entries in this file, type "man shorewall-interfaces"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-interfaces.html
#
###############################################################################
FORMAT 2
###############################################################################
#ZONE           INTERFACE               OPTIONS
wan             eth0
rpn             eth1
pwan            brwan                   bridge
</file>

===== Définitions des zones =====

Il faut maintenant définir le type de chaque zone. Dans notre cas assez simple, nous ne voulons que du trafic IPv4, nous allons donc éditer le fichier /etc/shorewall/zones:

<file bash zones>
#
# Shorewall version 4 - Zones File
#
# For information about this file, type "man shorewall-zones"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-zones.html
#
###############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
wan     ipv4
rpn     ipv4
pwan    ipv4
</file>

===== Définitions des politiques par défaut =====

Le fichier **/etc/shorewall/policy** permet de définir l'action du par feu si aucune règle définie ne correspond au paquet:

<file bash policy>
#
# Shorewall version 4 - Policy File
#
# For information about entries in this file, type "man shorewall-policy"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-policy.html
#
###############################################################################
#SOURCE DEST    POLICY          LOG     LIMIT:          CONNLIMIT:
#                               LEVEL   BURST           MASK
$FW     rpn     ACCEPT
rpn     $FW     ACCEPT
wan     pwan    ACCEPT
pwan    wan     ACCEPT
all     all     DROP            info
</file>

Ici:
  * Tout le trafic initié par l'hyperviseur à destination du réseau RPN est autorisé par défaut
  * De même, tout le trafic provenant du réseau RPN à destination de l'hyperviseur est également autorisé. Ces deux règles sont nécessaires pour que les deux hyperviseurs puissent communiquer tranquillement entre eux (établissement des tunnels VPN, trafic GlusterFS, migration des VM etc...)
  * Tout le trafic entre les zones wan et pwan est autorisé
  * Tout le trafic entre pwan et wan l'est également (les hyperviseurs ne filtrent rien, ils transmettent simplement les paquets aux VM concernées, selon leurs IP Failover attribuées. À charge des VM de faire du filtrage sur leur interface connectée à ce réseau)
  * Tout le reste est interdit, et les blocages sont journalisés

===== Définitions des variables =====

Le fichier **/etc/shorewall/params** permet de définir des variables, qui peuvent ensuite être utilisées dans les règles de filtrage. Ça facilite la maintenance des règles. Dans ce fichier, on peut y placer les IP de confiances qui seront les seules à pouvoir se connecter en SSH aux hyperviseurs par exemple

<file bash params>
#
# Shorewall version 4 - Params File
#
# /etc/shorewall/params
#
#       Assign any variables that you need here.
#
#       It is suggested that variable names begin with an upper case letter
#       to distinguish them from variables used internally within the
#       Shorewall programs
#
#       Example:
#
#               NET_IF=eth0
#               NET_BCAST=130.252.100.255
#               NET_OPTIONS=routefilter,norfc1918
#
#       Example (/etc/shorewall/interfaces record):
#
#               net     $NET_IF         $NET_BCAST      $NET_OPTIONS
#
#       The result will be the same as if the record had been written
#
#               net     eth0            130.252.100.255 routefilter,norfc1918
#
###############################################################################

IP_BDX=11.12.13.14
IP_MRS=74.5.236.77,198.20.21.22
IP_RBX=57.26.2945

IP_TRUST=$IP_BDX,$IP_MRS,$IP_RBX

IP_ZBX=62.33.89.127

#LAST LINE -- DO NOT REMOVE
</file>

<note tip>Dans cette exemple, on a définie les adresses IP des différents locaux de la société, qui pourront accéder gérer les hyperviseurs. La variable $IP_TRUST rassemble toutes les IP définies</note>

===== Définition des règles de filtrage =====

Le fichier le plus important est probablement **/etc/shorewall/rules**. C'est dans ce fichier qu'on va définir nos règles spécifiques de filtrage. Il va falloir adapter ce fichier à votre environnement, voici un exemple:

<file bash rules>
#
# Shorewall version 4 - Rules File
#
# For information on the settings in this file, type "man shorewall-rules"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-rules.html
#
######################################################################################################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME         HEADERS         SWITCH
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
#SECTION ALL
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
# OUTPUT
ACCEPT          $FW             wan             UDP     53
ACCEPT          $FW             wan             UDP     123
ACCEPT          $FW             wan             TCP     80,443,20,21
ACCEPT          $FW             all             ICMP    8
# INPUT
ACCEPT          any             $FW             ICMP    8
ACCEPT          wan:$IP_TRUST   $FW             TCP     22
ACCEPT          wan:$IP_ZBX     $FW             TCP     10050
</file>

Dans cet exemple:
  * Connexions sortantes (initiées par l'hyperviseur)
    * L'hyperviseur peut envoyer ses requêtes DNS via l'interface eth0 (UDP port 53)
    * Il peut envoyer ses requêtes NTP via eth0 également (UIDP port 123)
    * Il peut initier des connexions TCP sur les ports 80 (HTTP), 443 (https), 20 et 21 (FTP). Ces connexions sortantes sont nécessaires pour les mises à jour et l'installation de paquets depuis les dépôts
    * Il peut émettre des icmp echo request (ping, aka icmp 8) vers n'importe qui toujours via eth0
  * Connexion entrante (reçu par l'hyperviseur)
    * N'importe qui peut le pinguer sur son IP publique. Vous pouvez le restreindre aux IP de confiance si nécessaire, mais en général, une réponse au ping ne pose aucun problème de sécurité
    * Seules les IP de confiances ($IP_TRUST) peuvent ouvrir une connexion SSH (TCP port 22)
    * Le serveur de monitoring ($IP_ZBX) peut se connecter sur le port 10050 (pour les curieux, c'est un serveur [[http://www.zabbix.com|Zabbix]] qui contact l'agent Zabbix sur ce port :-))

===== Activation du par feu =====

Avec une installation par défaut, shorewall refusera de démarrer, il faut éditer le fichier **/etc/shorewall/shorewall.conf** et remplacer STARTUP_ENABLED=No par STARTUP_ENABLED=Yes

<code bash>
sed -i -e "s/STARTUP_ENABLED=.*/STARTUP_ENABLED=Yes/g" \
    /etc/shorewall/shorewall.conf
</code>

===== Démarrer le par feu =====

Attention, roulement de tambours, on va maintenant appliquer nos règles de filtrage.

<note important>Avant d'aller plus loin, assurez-vous de pouvoir récupérer l'accès à l'hyperviseur en cas d'erreur sur une règle qui vous couperait l'accès. Vous pouvez soit avoir à porté la console virtuelle depuis l'interface Online.net, soit vous créer un petit watchdog simpliste: dans une fenêtre, lancez la commande <code bash>sleep 300 && reboot</code> puis activez le par feu depuis une autre fenêtre. Si tout est OK, vous pouvez annuler la commande de redémarrage, mais si vous vous êtes coupé l'accès, le serveur redémarrera au bout de 5 minutes (et les règles de par feu ne s'appliqueront pas automatiquement puisqu'on a pas encore activé le démarrage de shorewall)</note>

<code bash>
/etc/init.d/shorewall start
</code>

Si tout se passe bien, shorewall ne devrait loguer aucune erreur, et commencer son filtrage. Vous pouvez suivre les paquets bloqués dans **/var/log/messages**.

Vous pouvez maintenant faire exactement la même chose sur le deuxième hyperviseur.

Une fois que vous vous êtes assuré que les règles de filtrages sont fonctionnelles, il ne reste plus qu'à activer shorewall au démarrage:
<code bash>
chkconfig shorewall on
</code>

====== Définition des règles de proxy ARP ======

On y est presque, il ne manque plus qu'à définir les règles de proxy ARP. Ce n'est pas du par feu à proprement parler, mais Shorewall permet de simplifier cette mise en place (activation du mode proxy sur l'interface brwan, ajout des règles de routage etc...) alors pourquoi s'en priver ;-)

Les hyperviseurs ne feront pas de routage du trafic, excepté entre les réseaux **wan** et **pwan**. L'interface physique des hyperviseurs (eth0) recevra les trames à destinations des IP publiques des VM (les IP failovers), et les transmettra sur le réseau **pwan** (via le pont **brwan**) grâce à une configuration en proxy ARP. Cette technique présente plusieurs avantages par rapport à du bridging simple:

  * Pas de risque de diffuser une MAC non déclarée sur le réseau Online, et donc pas de risque d'une mise en sécurité du port de l'hyperviseur.
  * Possibilité d'attribuer plusieurs IP publiques à une seule VM (ce qui n'est pas possible avec le bridging, puisqu'on doit déclarer à l'avance une MAC générée aléatoirement à chaque IP Failover)
  * Grâce au tunnel OpenVPN mis en place, les VM se chargeant du routage peuvent également être migrées d'un hyperviseur à l'autre sans perte de connectivité.

Dans le fichier **/etc/shorewall/proxyarp**, nous allons ajouter une ligne par IP Failover qui sera attribuée à une machine virtuelle:

<file bash proxyarp>
#
# Shorewall version 4 - Proxyarp File
#
# For information about entries in this file, type "man shorewall-proxyarp"
#
# See http://shorewall.net/ProxyARP.htm for additional information.
#
###############################################################################
#ADDRESS        INTERFACE       EXTERNAL        HAVEROUTE       PERSISTENT
88.190.23.99   brwan           eth0            No              Yes
88.191.89.16   brwan           eth0            No              Yes
</file>

Dans cet exemple, **88.190.23.99** et **88.191.89.16** sont deux IP failovers redirigées vers un des deux hyperviseurs (et la beauté de tout ce système, c'est qu'on s'en fou sur lequel des deux l'IP est redirigée).

Ajoutez sur chaque hyperviseurs uniquement les adresses IP Failovers qui lui sont redirigées dessus.

===== Automatiser les mises à jour des règles de prox ARP =====

On vient de voir comment mettre en place les règles de proxy ARP, mais ça serait quand même plus classe si nos deux hyperviseurs pouvaient mettre à jour automatiquement ces règles: ainsi plus besoin de toucher aux hyperviseurs, on ajoute une IP failover sur un des deux, et il modifiera sa configuration automatiquement en conséquence. Non seulement ça serait plus classe, mais en plus, c'est possible :-)

==== Création d'un script de re-configuration des interfaces wan ====
En cas de changement d'une IP failover d'un hyperviseur vers l'autre, il fat re-configurer les deux interfaces eth0 et brwan. Plutôt que de relancer toute la stack réseau (qui couperait l'accès aux volumes gluster), on va créer un script qui ne re-configure que les deux interfaces nécessaires:

<code bash>
cp -a /etc/init.d/network /etc/init.d/wan
cat <<'EOF' > wan.patch
--- /etc/init.d/network 2013-01-09 12:13:29.000000000 +0100
+++ /etc/init.d/wan     2013-07-21 16:13:06.526176211 +0200
@@ -40,12 +40,7 @@
 
 # find all the interfaces besides loopback.
 # ignore aliases, alternative configurations, and editor backup files
-interfaces=$(ls ifcfg* | \
-           LANG=C sed -e "$__sed_discard_ignored_files" \
-                      -e '/\(ifcfg-lo$\|:\|ifcfg-.*-range\)/d' \
-                      -e '/ifcfg-[A-Za-z0-9#\._-]\+$/ { s/^ifcfg-//g;s/[0-9]/ &/}' | \
-           LANG=C sort -k 1,1 -k 2n | \
-           LANG=C sed 's/ //')
+interfaces="brwan eth0"
 rc=0
 
 # See how we were called.
@@ -60,9 +55,6 @@
   
        apply_sysctl
 
-       # bring up loopback interface
-       action $"Bringing up loopback interface: " ./ifup ifcfg-lo
-
        case "$VLAN" in
          yes)
            if [ ! -d /proc/net/vlan ] && ! modprobe 8021q >/dev/null 2>&1 ; then
@@ -213,10 +205,6 @@
                )
        done
 
-       action $"Shutting down loopback interface: " ./ifdown ifcfg-lo
-
-       sysctl -w net.ipv4.ip_forward=0 > /dev/null 2>&1
-
        # IPv6 hook (post IPv4 stop)
        if [ -x /etc/sysconfig/network-scripts/init.ipv6-global ]; then
                /etc/sysconfig/network-scripts/init.ipv6-global stop post
EOF
patch /etc/init.d/wan wan.patch
</code>

==== Mise en place du script failover_updater ====
On va créer un petit script perl sur chaque hyperviseur. Ce script demandera à intervalles régulières quelles IP Failovers lui sont redirigées dessus, et il pourra ainsi mettre à jour la configuration de shorewall. 

Placez ce script dans /usr/local/bin/failover_updater.pl

<file perl failover_updater.pl>
#!/usr/bin/perl -w

use strict;
use LWP;
use JSON;
use Getopt::Long;
use File::Compare;
use File::Copy;

my ($key, $id) = '';

GetOptions(
    "key=s" => \$key,
    "id=s"  => \$id
);

if ($key eq '' || $id eq ''){
    print "Usage: $0 --key=<online api key> --id=<server id>\n";
    exit(1);
}

# Used to hide api key
$0 = 'failover updater';

my $c = LWP::UserAgent->new;

my $r = $c->get("https://api.online.net/api/v1/server/info/$id",
    "Authorization" => "Authorization: Bearer $key",
);

unless ($r->is_success){
    print "an error occured while querying the API" .
          "The error is: " . $r->status_line;
    exit(2);
}

my $data = from_json($r->content);

open TMP, ">/tmp/proxyarp" || die "Cannot open /tmp/proxyarp";
# Print the file header
print TMP <<"EOF";
###############################################################################
##ADDRESS\t\tINTERFACE\tEXTERNAL\tHAVEROUTE\tPERSISTENT
EOF

# Now add one arp proxy rule per failover IP
# redirected to ourself
foreach my $ip ( @{$data->{'network'}->{'ipfo'}} ){
    print TMP "$ip\t\tbrwan\t\teth0\t\tNo\t\tYes\n";
}
close TMP;

if (compare("/etc/shorewall/proxyarp", "/tmp/proxyarp") != 0){
    # Looks like IP Failover changed, we need to update shorewall
    # # config, reload it and flush the ARP cache
    print "Updating ARP Proxy config and flushing cache...\n";
    move ("/tmp/proxyarp", "/etc/shorewall/proxyarp");
    system("/sbin/restorecon -R /etc/shorewall >/dev/null 2>&1");
    # Wait a few second for the new routing rules to take place
    # It will result in more down time if we update too early
    sleep(90);
    system("/etc/init.d/wan restart  >/dev/null 2>&1");
    system("/etc/init.d/shorewall reload >/dev/null 2>&1");
}
else{
    unlink "/tmp/proxyarp";
}
</file>

Donnez les droits d'exécution:
<code bash>
chmod +x /usr/local/bin/failover_updater.pl
</code>

Installez les dépendances perl:
<code bash>
yum install perl-JSON perl-libwww-perl
</code>

Ajoutez une tâche cron:
<code bash>
cat <<'EOF' > /etc/cron.d/failover_updater
* * * * * root /usr/local/bin/failover_updater.pl --key=__API_KEY__ --id=__ONLINE_ID__
EOF
chmod 640 /etc/cron.d/failover_updater
sed -i -e "s/__API_KEY__/$(cat /etc/install/api_key)/g" \
       -e "s/__ONLINE_ID__/$(cat /etc/install/online_sdx)/g" \
       /etc/cron.d/failover_updater
</code>

Et voilà, tout est prêt. Toutes les minutes, les hyperviseurs vont demander quelles IP Failover leur sont attribuées, et re-configurer ce qui est nécessaire. En cas de bascule d'une IP Failover d'un hyperviseur vers l'autre (pour maintenance par exemple), il faut compter entre 1 et 2 minutes de coupure le temps que le nouveau routage se mette en place, que les hyperviseur récupèrent la nouvelle configuration et re-configure le nécessaire.

====== Migration des invités à l'arrêt ======
Pour finir, on va mettre un petit script sur les deux hyperviseurs. Il va permettre de migrer automatiquement les VM sur le deuxième hyperviseur pendant l'arrêt du serveur. Si le deuxième hyperviseur n'est pas joignable, alors on va simplement sauvegarder l'état des VM (virsh managedsave)

  * Placez ce script dans /usr/local/bin/migrate_all.pl
<file perl migrate_all.pl>
#!/usr/bin/perl -w

use strict;
use Sys::Virt;

my ($local,$remote) = undef;

eval { $local = Sys::Virt->new( uri => 'qemu:///system' ); };
if ($@){
    # No connection to the local libvirt
    # We can't do anything
    die 'Error connecting to libvirt on URI: qemu:///system: '. $@;
}

eval { $remote = Sys::Virt->new( uri => 'qemu+ssh://fws@peer/system' ); };
if ($@){
    # No connection to the remote server
    # Let's try to managed save all running domain
    foreach my $dom ($local->list_all_domains()){
        next unless $dom->is_active;
        $dom->managed_save();
    }  
}   
else{
    # We have a connection to both the local and
    # the remote libvirt. Lets try to migrate
    # all our running domain to our friend
    foreach my $dom ($local->list_all_domains()){
        next unless $dom->is_active;
        $dom->migrate($remote, Sys::Virt::Domain::MIGRATE_LIVE | Sys::Virt::Domain::MIGRATE_PEER2PEER | Sys::Virt::Domain::MIGRATE_TUNNELLED);
    }
}
</file>
  * Rendez-le exécutable
<code bash>
chmod +x /usr/local/bin/migrate_all.pl
</code>
  * Créez un script d'init rc.shutdown
<code bash>
cat <<'EOF' > /etc/init.d/rc.shutdown
#! /bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin

case "$1" in 
  stop)
    if [ -x /etc/rc.shutdown ]; then
      logger "Running local shutdown scripts (/etc/rc.shutdown)"
      /etc/rc.shutdown
    fi 
  ;;

  start)
    # nothing to do
  ;;

  *)
    echo "Usage: $0 start|stop" >&2
    exit 3
  ;;

esac
EOF
chmod +x /etc/init.d/rc.shutdown
ln -sf /etc/rc.d/init.d/rc.shutdown /etc/rc0.d/K00rc.shutdown
ln -sf /etc/rc.d/init.d/rc.shutdown /etc/rc6.d/K00rc.shutdown
</code>

  * Créez le fichier /etc/rc.shutdown, qui appelera notre petit script perl responsable de la migration
<code bash>
cat <<'EOF' > /etc/rc.shutdown
#!/bin/sh
/usr/local/bin/migrate_all.pl
EOF
chmod +x /etc/rc.shutdown
</code>

  * Enlevez le script libvirt-guests
<code bash>
chkconfig --del libvirt-guests
</code>

<note important>si ce script fonctionne très bien en exécution manuelle, il ne contact pas l'hyperviseur distant pendant un arrêt (il est pourtant appelé au tout début de la phase d'arrêt) et se contente de mettre les VM en pause. Elles peuvent être réveillées immédiatement sur le second, mais ça demande une intervention manuelle, et c'est justement pas le but :-/ Si quelqu'un à une idée, je suis preneur</note>

====== Créer un invité ======

On peut maintenant s'attaquer à la création d'un invité sur notre nouveau cluster tout neuf. La création est assez simple, pensez simplement à utiliser le pool **iso** pour stocker les ISO d'installation, et un autre pool pour les VM (pas obligatoire, mais plus propre)

  * Au niveau réseau, vous pouvez connecter les interfaces des invités au pont **brlan** ou **brwan**. Les interfaces connectées sur **brwan** disposeront d'une IP publique (voir la suite). Les machines connectées uniquement à **brlan** sont complètement isolés. Il vous faudra probablement créer une passerelle virtuelle ayant une interface sur **brwan** et une autre sur **brlan** qui servira de passerelle. [[http://wiki.contribs.org|SME Server]] et [[http://pfsense.org|PfSense]] sont d'excellents candidats :-)
  * Au niveau des disques, il faut mettre le cache à "**none**" (par défaut, il a la valeur "default", qui correspond à "passthrough"). Les migrations à chaud entre les deux hyperviseurs ne seront pas possibles tant que le cache ne sera pas mis à "none"

===== Configuration d'une IP publique dans un invité =====

Pour donner une IP publique à un invité, et donc faire en sorte qu'il soit directement connecté à Internet (sans aucun NAT ou filtrage), il faut:
  * Rediriger une IP failover sur un de vos deux hyperviseurs depuis la console Online (peut importe sur quel hyperviseur l'IP est redirigée)
  * Pendant l'installation, vous n'aurez probablement pas la possibilité de mettre la configuration réseau définitive, il va donc falloir jouer avec le masque réseau. Pour faire court:
    * L'adresse IP à configurer est l'IP failover
    * La passerelle est la passerelle de l'hyperviseur sur lequel l'IP failover est redirigée
    * ajustez le masque réseau pour que l'IP failover soit dans le même réseau que la passerelle (avec un peu de chance un 255.255.255.0 suffit, mais on peut augmenter jusqu'au 255.0.0.0 si nécessaire, selon les IP failover dont vous disposez)
  * Une fois que l'installation est terminée, on va pouvoir mettre en place la configuration définitive. En gros, il faut:
    * Mettre un masque réseau de 255.255.255.255 sur l'interface externe
    * Ajouter une route statique vers la passerelle (qui est la passerelle de l'hyperviseur sur lequel est attribué l'IP failover), par exemple:
<code bash>
ip route add 88.190.47.1 dev eth1
</code>

<note tip>voir [[http://documentation.online.net/fr/serveur-dedie/reseau/ip-failover#configuration_de_votre_serveur|cette page]] pour plus d'information sur la configuration réseau</note>

====== Réinstallation d'un serveur ======
En cas de crash important, nécessitant une ré-installation complète d'un des deux hyperviseurs, la plupart de ce tuto peut être suivit sans actions particulière, sauf pour la partie GlusterFS. Voilà les étapes à suivre pour re-synchroniser les 3 volumes:

  * Re-créez les bricks à leur emplacement normal (/mnt/bricks/sanlock, /mnt/bricks/save et /mnt/bricks/vmstore)
  * Installez les composants glusterfs
  * Récupérez l'UUID de l'hôte qui vient d'être réinstallé (cet UUID peut se récupérer sur le serveur encore fonctionnel dans le répertoire /var/lib/glusterd/peers<uuid>
  * Restaurez cet UUID sur le nouveau serveur dans le fichier /var/lib/glusterd/glusterd.info. Ce fichier doit ressembler à quelques chose comme ça:
<file ini glusterd.info>
UUID=34de250b-fba2-462f-8f68-e19cdee31111
operating-version=2
</file>
  * Depuis le nouveau serveur, faites un peer probe de l'ancien, exemple:
<code bash>
gluster peer probe hyp2
</code>
  * On re-synchronise les informations de volumes depuis l'ancien serveur encore fonctionnel
<code bash>
gluster volume sync hyp1 all
</code>
  * On restaure les attributs étendus utilisé par GlusterFS sur les bricks. Sans cette étape, point de synchro. On lance cette commande depuis l'ancien serveur (hyp1)
<code bash>
rsync -dvPt --xattrs /mnt/bricks/ root@hyp2:/mnt/bricks/
</code>
  * On remonte les 3 volumes GlusterFS à leurs emplacements
  * On force une synchronisation des données:
<code bash>
find /var/lib/libvirt/
</code>



====== TODO ======

  * <todo #>Ajouter codes couleurs (hyp1, hyp2 ou les deux)</todo>
  * <todo #>Verrous sur les disques (sanlock ?)</todo> (voir http://libvirt.org/locking.html)
    * <todo #>Ajouter une tâche cron pour nettoyer les leases (virt-sanlock-cleanup)</todo>
  * <todo #>Mesure perf GlusterFS sur du Gigabit</todo>
  * <todo>Migrer automatiquement les VM vers l'autre hyperviseur pendant l'arrêt ?</todo>
  * <todo #>Solution de sauvegardes à chaud des VM</todo>
  * <todo #>Scripts d'ajout des interfaces OpenVPN tab au bridge correspondant</todo>
  * <todo #>Script d'ajout de nouveau réseau privé</todo>
    * <todo #>Crée un réseau isolé libvirt</todo>
    * <todo #>Crée une configuration OpenVPN qui va bien</todo>
    * <todo #>Relance OpenVPN pour connexion immédiate</todo>
  * <todo #>Config firewall hyperviseurs</todo>
    * <todo #>Pas de communication entre les VM et les hyperviseurs</todo>
  * <todo #>Config proxy ARP hyperviseurs / attribution d'IP failover aux VM sans NAT</todo>
  * <todo #>Lors du redémarrage d'un hyperviseur surlequel des IP failover sont redirigées, il faut désactiver le proxy arp sur brwan de l'autre hyperviseur pour que le routage revienne</todo> (echo 0 > /prox/sys/net/ipv4/conf/brwan/proxy_arp && sleep 3 && echo 1 > /prox/sys/net/ipv4/conf/brwan/proxy_arp)
  * <todo #>Il semble qu'il faille relancer openvpn sur les deux hyperviseurs après un redémarrage de l'un des deux</todo> (même si les tunnels s'établissent proprement, pas de lien ethernet)
  * <todo #>Empêcher le démarrage auto des VM au démarrage de l'hôte</todo> (via un script hook de libvirt ?)
  * <todo #>Créer un volume gluster indépendant pour stocker les ISO d'install</todo>
  * <todo>Depuis Gluster 3.4, il peut y avoir des conflits entre les ports utilisés par glusterfsd et les ports utilisés pour la migration simple (plain TCP) des VM. Il faut trouver comment modifier la plage de port de l'un ou de l'autre (au pire, une migration tunnelée (--tunnelled) de libvirt fonctionne toujours, mais ça serait plus élégant si les options de migrations par défaut de virt-manager fonctionnaient à tous les coups)</todo>