Commençons
Bien, cet article est la partie 2 de ma série d'articles sur la mise en place d'un cluster Proxmox.
Dans cet article, je vais partir du début et parler de l'installation des 3 serveurs Proxmox dont nous allons avoir besoin.
Pour rappel :
- Un serveur principal, chargé de faire tourner les principaux services sous forme de machines virtuelles
- Un serveur de secours, moins costaud mais suffisant pour faire tourner les services que vous considérez comme vitaux
- Un 3ème serveur, pas forcément très performant, qui va principalement servir à assurer le quorum, afin que 3 machines soient dans le cluster
Vous trouverez tous les détails dans la partie 1 de cette série, Cluster Proxmox distant (1/4) : le concept
Le petit schéma pour rappeler l'infrastructure et les noms des machines :
.png)
Matériel, serveurs, spécificités et autres joyeusetés
Comme dit plus haut, vous allez avoir besoin de 3 serveurs. Les 2 principaux, je conseille qu'ils soient physiques. De vrais serveurs avec les perfomances dont vous avez besoin.
Le 3eme serveur, servant uniquement pour le quorum, peut être une simple machine virtuelle dans un coin. L'important est que vous puissiez installer proxmox dessus. (Pour ma part, c'est une KVM avec proxmox à l'intérieur, qui tourne sur une autre architecture Proxmox chez moi :) )
Par contre, ne montez pas votre Arbitre sur une KVM dans l'un des 2 premiers serveurs. Sinon vous perdez tout l'intérêt d'avoir un 3eme système indépendant des 2 autres pour assurer le quorum !
Vous allez également avoir besoin d'installer Proxmox sur vos serveurs. Dans ces articles, je me baserai sur l'installation de Proxmox 2.X standard, fournie par Proxmox et donc basée sur Debian Squeeze (actuellement Proxmox 2.2).
L'installation de base présente l'avantage de proposer un partionnement des disques dur via LVM, qui est très pratique pour redimensionner les partitions et utiliser DRBD par la suite. Cependant, je détaillerai le partionnement nécessaire, afin que vous puissiez vous en tirer si vous souhaitez installer Proxmox par dessus une autre distribution Linux.
OVH et Online proposent la distribution Proxmox à l'installation. OVH vous permet de choisir le partionnement via leur interface web, ce qui est assez pratique. Online par contre part sur un partionnement sans LVM qui ne vous permettra pas d'utiliser simplement DRBD par la suite. Attention donc chez Online, mieux vaut passer par leurs cartes ILO/iDrac pour installer Proxmox depuis l'ISO.
Enfin, vous allez avoir besoin d'un PC supportant le SSH pour vous connecter aux différents serveurs. Je vous conseillerai bien un Linux, parce que vous allez passer pas mal de temps connecté, donc un système supprotant bien le bash (et notamment l'encodage de caractère et les couleurs) est préférable. Cependant, Windows avec putty fonctionne aussi, donc à vous de voir.
Une dernière recommandation : pour monter le cluster, il est important qu'AUCUNE machine virtuelle ne soit présente sur les serveurs (pour éviter les conflits de VMID). Si vous récupérez des serveurs existants, il va donc falloir basculer vos machines de droite à gauche pendant la mise en place du cluster. Si vous partez d'une installation neuve, attendez d'avoir monté le cluster pour réimporter vos machines virtuelles.
Installation et partionnement
L'installation de l'ISO proxmox se fait toute seule, sans besoin d'intervention. Insérez le disque (ou la clef USB, maintenant supportée), bootez dessus et procédez à l'installation.
Le partionnement de proxmox utilise LVM, et se décompose de la manière suivante :
- Une partition physique dédiée au boot, /dev/sda1, d'environ 500Mo
- Une parition physique entièrement formatée en LVM, avec le reste du disque
C'est cette deuxième partition qui nous intéresse. Elle utilise LVM, et peut donc être redimensionné par nos soins plus tard. En prenant bien sûr les précautions nécessaires :-)
- Un disque logique d'environ 30Go pour /.
- Un disque logique servant de Swap, calculé à partir de la taille de votre RAM
- Un disque logique utilisant tout le reste du disque (moins 4Mo), qui sera monté comme /var/lib/vz et qui servira à stocker vos VM, les backups, etc
Pour être plus confortable, notamment au niveau du système, vous pouvez utiliser la technique suivante :
- Lors du prompt au boot sur le CD, tapez "debug"
- tapez : linux maxroot=100
Cela va configurer la partition système pour utiliser 100Go. Il existe d'autre options, pour plus de détails, voyez Debugging Installation.
Pour le reste, c'est correct.
Si vous faites votre partionnement vous-même, veillez à utiliser LVM pour au moins /var/lib/vz. Cela nous permettra d'utiliser les snapshot LVM et de gérer l'espace facilement pour DRBD.
Personnalisation et astuces
Bon, votre système est installé.
Avant d'attaquer le vif du sujet, je vous propose quelques petits trucs pour faciliter la suite.
Bash et couleurs
Pour faciliter la gestion de vos 3 serveurs, vous pouvez personnaliser votre bash pour utiliser plusieurs couleurs dans votre connexion SSH.
Pour ce faire, vous pouvez éditer /etc/bash.bashrc
# nano /etc/bash.bashrc
Pour ajouter des couleurs, ajoutez ceci à la fin du fichier :
# couleurs
C_RED="\[\e[1;31m\]"
C_BLUE="\[\e[1;34m\]"
C_GRAY="\[\e[1;30m\]"
C_WHITE="\[\e[1;37m\]"
C_YELLOW="\[\e[1;33m\]"
C_DEF="\[\033[0m\]"
mUID=`id -u`
MACHINE=`hostname -f`
if [ "$mUID" = "0" ] ; then
PS1="${C_RED}\u${C_DEF}@${C_RED}${MACHINE}${C_DEF}:\w${C_RED}#${C_DEF} "
PS2="${C_RED}>${C_DEF} "
else
PS1="${C_BLUE}\u${C_DEF}@${MACHINE}:\w${C_BLUE}\$ ${C_DEF}"
PS2="${C_BLUE}>${C_DEF} "
fi
export PS2
export PS1
case $TERM in
xterm*)
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007"'
echo -ne "\033]0;${USER}@${MACHINE}: ${PWD}\007"
;;
*)
setterm -blength 0
;;
esac
Ce fichier va automatiquement colorer votre nom d'utilisateur et le nom de la machine dans votre connexion SSH.
Si vous êtes connectés avec un autre utilisateur que root, la couleur sera bleue.
Il va également modifier dynamiquement le nom de votre fenêtre SSH selon le dossier où vous êtes. Le but est de ne pas se perdre pour éviter les bêtises ;-)
Je vous conseille de changer les parties en gras (C_RED) selon les machines (avec les couleurs disponibles en gras italique au dessus)
N'hésitez pas à vous amuser pour trouver les combinaisons de couleurs qui vous plaisent.
Une fois le fichier sauvegardé, vous pouvez activer les modifications pour tester les couleurs avec un :
# exec bash
Vous pouvez également ajouter à la fin du fichier ces alias, qui peuvent être utiles :
alias l='ls -ahlF --color=yes --full-time --time-style=long-iso | more'
alias ll='ls -alhF --color=yes --full-time --time-style=long-iso'
alias cpav='cp -av'
Une fois tout cela configuré selon votre souhait, faites une petite mise à jour de la machine, et redémarrez si nécessaire.
# aptitude update && aptitude safe-upgrade -y
Configuration des interfaces réseaux
Pour utiliser openVPN et simplifier la gestion des adresses IP publiques entre les serveurs (toujours sympathique), nous allons créer diverses interfaces supplémentaires sur chacun de nos serveurs.
Architecture interne des serveurs
Après une installation de Proxmox, vous devez disposer d'un bridge virtuel vmbr0.
Nous allons créer les interfaces suivantes :
- vmbr1 : ce bridge permettra la communication en interne au serveur, notamment entre VM. Toutes vos VM devront avoir une interface dans vmbr1 pour discuter entre elles. C'est également cette interface qui permettra la liaison VPN, afin que vos VM puissent discuter entre serveurs, dès fois que vous ayiez plusieurs VM sur chacun de vos serveurs
- vmbr2 : ce bridge un peu particulier permettra la discussion entre les machines "passerelles", qui portent les IP publiques, et les machines ayant besoin d'une connexion entrante ou sortante vers Internet. Ces machines, par exemple en HA, pourront avoir une carte réseau sur vmbr2 et une interface sur vmbr1. Avec une architecture identique sur les 2 serveurs principaux au niveau des VM publiques, les machines basculant en HA retrouveront directement leur connexion
- dummy1 : cette interface "bidon" va permettre d'avoir une interface fixe pour "brancher" openvpn, qui a besoin d'une interface réseau physique pour se lancer correctement au démarrage du serveur
Pour que cela soit plus clair, un schéma (le retour) est le bienvenu :
Les adresses IP sont indicatives, mais il est important que le réseau sur vmbr1 soit différent du réseau sur vmbr2. Il est également important que le réseau utilisé sur vmbr2 soit identique sur les 2 serveurs. Cela va permettre de basculer les machines en HA d'un serveur à l'autre sans changer aucune de leurs configurations internes. Il faut également que les passerelles soient équivalentes (sauf l'IP publique bien sûr).
Si vous configurez des routages de ports entre votre passerelle et les machines en HA, il faudra avoir les même sur la passerelle du PRA, même s'ils pointent dans le vide tant que les machines HA ne sont pas sur le PRA.
Configuration de dummy
Nous allons commencer par créer l'interface dummy nécessaire à OpenVPN. De base, Proxmox peut utiliser une interface dummy pour des usages internes, nous allons donc utiliser une deuxième par précaution :
# echo "options dummy numdummies=2" > /etc/modprobe.d/dummy.conf
# modprobe dummy
Pour vérifier que les interfaces ont bien été créées, tapez la commande suivante :
# ifconfig -a | grep Link | grep -v inet6
Qui doit vous renvoyer quelque chose comme ça :
dummy0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
dummy1 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
eth0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
lo : Link encap:Local Loopback
vmbr0 : Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
Configuration des interfaces
Nous allons aller toucher au fichier /etc/network/interfaces.
Avant ça, sauvegardez le fichier :
# cpav /etc/network/interfaces /etc/network/interfaces.original
Puis éditez le :
# nano /etc/network/interfaces
Ajoutez vmbr1 :
auto vmbr1
iface vmbr1 inet static
address XXX.XXX.XXX.XXX
netmask 255.255.255.0
bridge_ports dummy1
bridge_stp off
bridge_fd 0
post-up route add -net 224.0.0.0 netmask 240.0.0.0 dev vmbr1
Dans le schéma de mon exemple, j'utilise 192.168.11.1 pour le serveur principal, 192.168.11.2 pour le PRA, et 192.168.11.3 pour l'arbitre.
Ajoutez vmbr2 :
auto vmbr2
iface vmbr2 inet static
address XXX.XXX.XXX.XXX
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
Dans le schéma de mon exemple, je prends 192.168.10.253. La passerelle portera par exemple 192.168.10.254.
Pour appliquer les modifications, effectuez un :
# /etc/init.d/networking restart
Pour vérifier que les nouvelles interfaces fonctionnent correctement, vous pouvez les pinguer :
# ping 192.168.10.253
# ping 192.168.11.1
Configuration des services
Pour désactiver l'IPv6, si vous n'en avez pas besoin (pas de troll :-))
# echo "options ipv6 disable=1" > /etc/modprobe.d/disable-ipv6.conf
Il faut configurer Proxmox pour écouter sur l'interface OpenVPN :
# nano /etc/hosts
Vérifiez que c'est bien l'adresse de vmbr1 qui est configurée :
127.0.0.1 localhost.localdomain localhost
xxx.xxx.xxx.xxx serveurprincipal.mon-cluster.vpn pra pvelocalhost
[...]
Où xxx.xxx.xxx.xxx est l'adresse que vous avez indiquée pour vmbr1 (pour moi 192.168.11.1)
Pour avoir des logs propres au démarrage (on sait jamais)
# nano /etc/default/bootlogd
Et modifiez :
BOOTLOGD_ENABLE=Yes
Installation d'OpenVPN
On est parti ! Tout ce qui était avant va vous servir :-)
Installons OpenVPN pour commencer :
# aptitude install openvpn
Faites ceci sur tous vos serveurs.
Préparation des certificats
Sur le serveur PRA, le serveur principal d'OpenVPN, nous allons générer les certificats serveurs et clients.
# cpav /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/
# cd /etc/openvpn/easy-rsa/
# cpav vars vars.original
Editez le fichier vars, tout à la fin du fichier, pour modifier les variables globales. Ainsi votre génération de clef se fera automatiquement. Sinon, vous devrez indiquer les informations à chaque génération.
Puis :
# source ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
# ./clean-all
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
........................................................+......
..+............+...............................................
...............................................................
...+............................................++*++*++*
# ./pkitool --initca
Using CA Common Name: Mon organisation CA
Generating a 1024 bit RSA private key
...++++++
................++++++
writing new private key to 'ca.key'
-----
Générez la clef serveur
# ./pkitool --server server
# openvpn --genkey --secret ./keys/ta.key
Générez les clefs clients
# ./pkitool clientPrincipal
# ./pkitool clientArbitre
Vous pouvez également en profiter pour générer d'autres clefs clients si vous souhaitez vous connecter vous-même au VPN, pour sécuriser à fond vos accès SSH par exemple.
Sauvegarde des clefs
# cd /etc/openvpn/easy-rsa/keys/
# tar cvzf /root/server-keys.tar.gz server.crt server.key ca.crt dh1024.pem ta.key
# tar cvzf /root/clientPrincipal-keys.tar.gz clientPrincipal.crt clientPrincipal.key ca.crt ta.key
# tar cvzf /root/clientArbitre-keys.tar.gz clientArbitre.crt clientPrincipal.key ca.crt ta.key
Configuration des serveurs
Pour mettre en place le fameux triangle OpenVPN permettant un quorum solide, nous allons devoir configurer à la fois le serveur principal ET le serveur PRA comme serveurs OpenVPN.
La différence se jouera dans les fichiers de configurations des clients.
Sur chacune des machines, importez le fichier de configuration par défaut :
# cd /etc/openvpn/
# zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > server.conf
# cpav server.conf server.conf.original
Pour une configuration idéale (d'après mes tests de robustesse personnels), le fichier doit ressemble à ça sans ses commentaires :
# cat server.conf | grep -v -e '^;' | grep -v -e '^#' | grep -v -e '^$'
local IP_PUBLIQUE_SERVEUR
port 4450
proto tcp
dev tap0
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server-bridge XXX.XXX.XXX.XXX 255.255.255.0 YYY.YYY.YYY.YYY TTT.TTT.TTT.TTT
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
max-clients 4
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
mode server
tls-server
script-security 2
up "/etc/openvpn/up.sh"
down "/etc/openvpn/down.sh"
Les choses à modifier selon le serveur sont en gras :
- local IP_PUBLIQUE_SERVEUR : remplacez par l'adresse IP publique de votre serveur, pour écouter en VPN sur cette adresse. Cette adresse est a priori différente selon le serveur ! ;-)
- Le port d'écoute. Par défaut 1194, mais il est conseillé de le changer pour éviter d'être reconnu direct comme un VPN
- XXX.XXX.XXX.XXX : remplacez par l'adresse privée du vmbr1 du serveur. Attention à ne pas vous tromper !
- YYY.YYY.YYY.YYY : cette IP est le début de la plage allouée pour OpenVPN. Pour ma part, je prend 4 clients possibles. Les 2 serveurs et 2 autres (pour vos connexions de gestion par exemple)
- TTT.TTT.TTT.TTT : Cette IP est la fin de la plage allouée commencée par YYY.YYY.YYY.YYY. Cette plage doit contenir les IP de vos serveurs, mais comme ceux-ci sont en IP fixe, pas de risque d'allocation se marchant dessus.
Scripts up.sh et down.sh (pour les serveurs)
Ces scripts vont permettre d'ajouter l'interface OpenVPN (tap0) au bridge vmbr1 à chaque démarrage du serveur VPN. Et bien sûr de le retirer à l'arrêt du serveur VPN (faisons les choses bien :-))
Ces scripts seront sensiblement différents pour les clients, nous verrons ça plus bas.
# nano /etc/openvpn/up.sh
#!/bin/bash
/sbin/ifconfig vmbr1 promisc
/sbin/ifconfig tap0 up promisc
/usr/sbin/brctl addif vmbr1 tap0
# nano /etc/openvpn/down.sh
#!/bin/bash
/usr/sbin/brctl delif vmbr1 tap0
/sbin/ifconfig tap0 down -promisc
#/sbin/ifconfig vmbr1 -promisc
Installation des clefs serveurs
Chacun des serveur devra disposer du set de clef serveur que nous avons généré plus haut. Sans quoi, ils n'accepteront pas les connexions du client.
Physiquement, le client ne sera connecté qu'à un serveur à la fois, mais il faut que les 2 serveurs tournent en permanence pour que le client puisse basculer facilement en cas de souci sur le PRA.
Sur le PRA, où vous avez généré les clefs, il suffit de les placer dans le dossier openVPN puis de les extraire :
# cd /etc/openvpn
# tar xvzf /root/server-keys.tar.gz
Sur le serveur principal, il va d'abord falloir envoyer les clefs via scp :
# scp /root/server-keys.tar.gz root@IP_PUBLIQUE_SERVEUR:
Note : il n'est pas très propre d'utiliser root pour le transfert, mais c'est malheureusement la technique la plus simple sur Proxmox, où quasi-tout doit se faire en root. Vous pouvez cependant créer un autre utilisateur qui ne servira que pour les transferts. De toute façon, le cluster discute avec le compte root, donc le SSH sur le port 22 en root devra au moins être autorisé dans le tunnel OpenVPN. Je vous laisse gérer votre niveau de sécurité :-)
Puis extraire les clefs :
# cd /etc/openvpn
# tar xvzf /root/server-keys.tar.gz
Une fois ceci fait, vous pouvez redémarrer OpenVPN sur les 2 serveurs :
# /etc/init.d/openvpn restart
Normalement, il doit démarrer sans erreurs des deux côtés. Les logs s'écrivent dans /etc/openvpn/openvpn.log
Un démarrage réussit doit se terminer par
Initialization sequence completed
Sinon, vérifiez bien les adresses IP que vous avez indiquée (problème de bind) et la synthaxe des paramètres dans le fichier de conf (problème de "unknown parameter")
Configuration des clients
A ce stade, nous avons uniquement les serveurs VPN qui tournent. Il va vous falloir configurer les clients qui s'y connectent.
Au nombre des clients, nous avons donc l'arbitre, et le serveur principal qui je le rappelle est à la fois client ET serveur.
Nous allons configurer l'arbitre pour qu'il tente en premier lieu de se connecter au PRA, et s'il échoue qu'il tente de se connecter au serveur principal. Nous allons également indiquer dans sa configuration que si sa connexion saute, il doit réessayer immédiatement de se reconnecter.
Par contre, le serveur principal n'essaiera de se connecter qu'au PRA.
Voici le fichier de configuration. La spécificité de l'arbitre est en rouge :
client
dev tap1
proto tcp
remote IP_PUBLIQUE_PRA PORT_VPN
remote IP_PUBLIQUE_SERVEUR_PRINCIPAL PORT_VPN
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert CLIENT.crt
key CLIENT.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
verb 3
log-append openvpnclient.log
script-security 2
up "/etc/openvpn/upclient.sh"
down "/etc/openvpn/downclient.sh"
keepalive 30 120
float
Les paramètres à adapter sont en gras :
- dev tapX : c'est l'interface que crééra openvpn pour sa connexion. Il est important de ne pas mettre tap0, qui est déjà utilisé pour le serveur VPN sur le serveur principal. Pour uniformiser, mieux vaut utiliser la même interface sur les 2 clients
- remote .... : c'est là que vous indiquez sur quel serveur se connecter. Indiquez l'adresse IP du PRA ainsi que le port que vous avez choisi. Sur l'arbitre, rajoutez une ligne avec l'adresse IP du serveur principal. OpenVPN essaiera toujours la première ligne, puis si elle échoue il passera à la deuxième.
- cert, key : c'est là que vous définirez les certificats et les clefs à utiliser pour la connexion client (clientPrincipale ou clientArbitre) que nous allons rapatrier via scp.
- log-append : indique le fichier dans lequel les logs de connexion seront écrits. Indiquez un nom de fichier différent de celui du serveur pour avoir des logs bien séparés
- up, down : les fichiers up.sh et down.sh sont différents entre les serveurs et les clients, donc indiquez là aussi des noms différents ce ceux dans le fichier de conf du serveur
- keepalive 30 120 : cette directive va indiquer aux clients qu'il doivent tenter de relancer leur connexion si jamais elle tombe (On ping toutes les 30s, on redémarre au bout de 120s si pas de réponse). Dans le cas du serveur principal, il essaiera en boucle de se reconnecter sur le PRA. Dans le cas de l'arbitre, il alternera entre le PRA et le serveur principal jusqu'à ce qu'une connexion réussisse
Scripts upclient et downclient
Les fichiers up.sh et down.sh sont différents pour les clients. Comme le serveur principal possède déjà up.sh et down.sh, on les nomme upclient.sh et downclient.sh pour qu'ils ne se marchent pas dessus (quelle imagination ! \o/)
Donc, upclient.sh :
#!/bin/bash
/sbin/ifconfig vmbr1 promisc
/sbin/ifconfig tap1 up promisc
/usr/sbin/brctl addif vmbr1 tap1
/sbin/ifconfig tap1 0
Et downclient.sh :
#!/bin/bash
/sbin/ifconfig vmbr1 -promisc
La principale différence est le nom des interfaces à bridger (tap1 dans mon cas). Le down client ne doit également pas sortir le tap1 du bridge, sinon il risque de générer une erreur qui va bloquer la tentative de connexion en boucle du client. Et donc rendre inefficace le mode de secours. (Un petit souci de gestion de bridge avec OpenVPN vis à vis de tous les bridges/tap qu'on utilise ici...)
Récupération des clefs clients
Bien, il ne reste plus qu'à transmettre les clefs openvpn à qui de droit. Depuis le PRA qui les a générées, envoyez les tar.gz grâce à scp :
# scp /root/clientPrincipal-keys.tar.gz root@IP_PUBLIQUE_SERVEURPRINCIPAL:
# scp /root/clientArbitre-keys.tar.gz root@IP_PUBLIQUE_ARBITRE:
Puis sur chaque serveur, extrayez les clefs dans /etc/openvpn :
# cd /etc/openvpn
# tar xvzf /root/client{Principal,Arbitre}-keys.tar.gz
Et enfin, redémarrez openvpn.
La connexion va s'établir. Là encore, les logs s'écrivent dans /etc/openvpn, dans le fichier openvpnclient.log spécifé dans le fichier de configuration.
Si tout se passe bien, vous pourrez y voir apparaitre un "Initialization sequence completed".
C'est également dans ce fichier que vous pouvez vérifier si la reconnexion se fait bien.
Tests du triangle openvpn
Il est important de tester votre système de connexion/reconnexion.
A l'étape précédente, la connexion de base a dû bien fonctionner. Sinon, faites en sorte que ce soit le cas. Si jamais vous avez des soucis particuliers, faites m'en part dans les commentaires :-)
Pour tester, effectuez quelques ping sur les adresse vmbr1 de chaque serveur :
- Sur le serveur principal, pinguez le vmbr1 du PRA et de l'arbitre
- Sur le PRA, pinguez le vmbr1 du serveur principal et de l'arbitre
- sur l'arbitre, pinguez le vmbr1 du serveur principal et du PRA
Pour tester que la reconnexion fonctionne bien, nous allons essayer de couper le serveur VPN du PRA et voir comment tout cela se comporte.
Ouvrez 3 connexions SSH, une par serveur.
- Sur l'arbitre et le serveur principal, lancez une surveillance du client OpenVPN :
# less /etc/openvpn/openvpnclient.log
Puis effectuez la combinaison de touche "maj + F" qui va permettre une mise à jour en temps réel du fichier. Vous verrez ainsi tout ce qui s'y écrit
- Sur le PRA, coupez openvpn avec un
# /etc/init.d/openvpn stop
Normalement, vous devriez rapidement voir dans les fichiers de log que la connexion s'est interrompue. Sur le serveur Principal, la connexion va tenter en boucle de s'établir à nouveau.
Sur l'arbitre, vous devriez voir rapidement une tentative de connexion sur le serveur principal, qui doit réussir.
Là encore, vous pouvez vérifier avec quelques ping que tout va bien.
Relancez ensuite le serveur VPN sur le PRA. Vous devez observer que le serveur principal revient s'y connecter.
A ce moment là, l'arbitre est connecté sur le serveur principal. Il ne va pas essayer de se reconnecter sur le PRA sauf si le serveur principal tombe.
Pour achever nos tests, coupez le serveur VPN sur le serveur principal, ce qui devrait provoquer la reconnexion de l'arbitre sur le PRA.
Si tout ça fonctionne, on commence à être vraiment bon ! :-)
Mise en place du cluster
Avant de mettre en place le cluster, nous allons vérifier que le multicast passe bien dans le VPN.
Pour ce faire, sur chaque machine, installez l'outil suivant :
# aptitude install ssmping
Ensuite, nous allons tester les serveurs 2 par 2. L'un essaiera de joindre l'autre en multicast, pendant que la cible écoutera les connexions.
Bon je vais pas écrire toutes les combinaisons possibles pour les tests. Sachez qu'il vous faut lancer sur un serveur pour le mettre en écoute :
# ssmpingd
Puis depuis un autre, lancez le test :
# asmping 224.0.2.1 IP_SERVEUR_TEST
Vous devez voir passer sur le serveur en écoute des messages de ce type :
asmping joined (S,G) = (*,224.0.2.234)
pinging IP_SERVEUR_TEST from IP_SERVEUR_SOURCE
unicast from IP_SERVEUR_TEST, seq=1 dist=0 time=38.699 ms
multicast from IP_SERVEUR_TEST, seq=1 dist=0 time=76.405 ms
unicast from IP_SERVEUR_TEST, seq=2 dist=0 time=38.802 ms
multicast from IP_SERVEUR_TEST, seq=2 dist=0 time=76.238 ms
Les lignes importantes à repérer sont celles du multicast, que vous devez impérativement constater pour le bon fonctionnement du cluster !
C'est également le bon moment pour vérifier le fichier /etc/hosts.
Vous devez avoir indiqué l'adresse IP du vmbr1. C'est l'adresse dont se sert Proxmox comme information lors du contact avec les autres membres du cluster.
Création du cluster
Pour le cluster, nous allons effectuer sa création depuis le PRA, puis nous allons y ajouter les 2 autres serveurs.
Je vous rappelle qu'il ne doit y avoir aucune VM sur le serveur principal et sur l'arbitre ! Si votre système a déjà des VM en fonctionnement, migrez les temporairement sur le PRA le temps de créer le cluster. Cette limitation a pour but de s'assurer qu'aucun VMID ne sera en conflit au sein du cluster.
Le nom du cluster est important, dans le sens où une fois le cluster créé, vous ne pourrez plus changer ce nom. Choisissez le bien !
Sur le PRA :
# pvecm create NOM_DU_CLUSTER
qui doit vous renvoyer :
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@proxmox-server-1
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| |
| . So o |
| . .. .O o |
| .. . o* = |
| +o o.=.. |
| . +E * o o . |
+----------------------+
Restarting pve cluster filesystem: pve-cluster[dcdb] crit: unable to read cluster config file '/etc/cluster/cluster.conf' - Failed to open file '/etc/cluster/cluster.conf': No such file or directory
[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'
[dcdb] crit: cman_tool version failed with exit code 1#010
.
Starting cluster:
Checking if cluster has been disabled at boot... [ OK ]
Checking Network Manager... [ OK ]
Global setup... [ OK ]
Loading kernel modules... [ OK ]
Mounting configfs... [ OK ]
Starting cman... [ OK ]
Waiting for quorum... [ OK ]
Starting fenced... [ OK ]
Starting dlm_controld... [ OK ]
Unfencing self... [ OK ]
Puis, sur chacun des autres serveurs :
# pvecm add IP_VMBR1_PRA
qui doit vous renvoyer à peu près la même chose qu'au dessus.
Etat du cluster
La commande pvecm vous permettra d'avoir plusieurs infos sur le cluster.
# pvecm n
vous donnera un aperçu des nodes (date de connexion, état, etc)
# pvecm s
vous donnera des informations sur le cluster lui-même (état du qorum, nombre de node, nombre de vote, etc)
Nous verrons plus tard des commandes plus spécifiques au HA.
Bon, je crois que j'ai rien oublié
Et bien voila qui conclut la création de notre système de cluster !
A la fin de ce tutoriel, vous avez normalement un cluster de 3 nodes, donc avec un quorum qui fonctionne, et des paritions manipulables facilement.
Vous êtes prêts à mettre en place le système de disque répliqué, puis le HA lui-même.
Ces deux étapes seront le sujet des prochains articles.
En attendant, n'hésitez pas à me poser des questions dans les commentaires !
Comments
Si vous avez des questions, si quelque chose n'est pas clair, n'hésitez pas à commenter !
Manu
Posted on
Question bête, est-ce qu'on pourrait faire la même chose avec IPsec à la place d'OpenVPN ? Il me semble que dans ce cas il n'y aurait plus de distinction client/serveur. On aurait alors 3 liens symétriques entre les machines du cluster.
Victor
Posted on
Hello,
Je connais moins IPSec qu'OpenVPN, mais j'avais fait des tests avec il y a quelques temps. Le principal problème que je rencontrais est qu'IPSec est difficile à interfacer avec un bridge. Or, Proxmox fonctionne principalement sur ce type de système. En plus à l'époque c'était Proxmox 1.X, dont le système de cluster était de type maitre/esclave, moyennement adapté à IPSec.
Sur Proxmox V2 et dans l'optique de ce cluster, je vois plusieurs soucis à utiliser IPSec :
- Il faudra faire passer du Multicast dans le tunnel. Pas sûr de voir comment faire avec IPSec, il faudrait chercher la viabilité et la possibilité de router le multicast à travers le tunnel
- En montant un vrai "triangle" IPSec, il y aurait un risque de spanning tree je pense (je l'ai rencontré en faisant un triangle OpenVPN au début). IPSec peut-il gérer ça ?
- Pour IPSec, il faut déclarer chaque plage d'IP qui est derrière le tunnel, donc impossible de mettre les même plages de chaque côtés, ce qui risque de compliquer le basculement des machines en HA, à moins de prévoir un canal de communication exprès pour la gestion du cluster (ce qui n'est pas déconnant je l'accorde :) )
- Dans mon cas particulier où l'arbitre est juste une machine virtuelle dans un coin, il y a le problème du NAT, jamais très apprécié par IPSec. Ce problème ne se pose pas si les 3 machines sont de vrais serveurs avec IP publiques
- Globalement, je n'aime pas trop IPSec, que je trouve plus complexe et moins robuste qu'OpenVPN (trop de contraintes...) (Pas de troll ! :D)
- Le système avec OpenVPN fonctionne plutôt bien, en étant simple à mettre en place ;)
Cependant si tu as des arguments, j'aimerai les entendre, je suis amené à utiliser IPSec de temps en temps, et si je peux améliorer mes connaissances dessus je suis preneur ! (De même que pour améliorer ces tutos ;) )
A plush'
Manu
Posted on
Je vois deux avantages à IPsec, la symétrie de la relation entre les hosts et un overhead sans doute plus faible qu'avec OpenVPN. J'ai aussi la vague intuition que la configuration pourrait être plus simple à l'arrivée, mais pour le moment je n'ai pas encore trouvé la bonne solution :) L'idée serait de monter un tunnel GRE laissant transiter le multicast et de le sécuriser avec IPsec en mode transport. Le tunnel GRE est vraiment très simple à mettre en place, mais je n'ai pas encore bien intégré comment le multicast y passe.
Sinon je crois qu'il y a moyen de faire sans multicast, ce qui simplifierait pas mal les débats :
http://pve.proxmox.com/wiki/Multicast_notes#Use_unicast_instead_of_multicast
Guillaume
Posted on
Hello,
Perso j'ai plutôt choisis une solution OpenVPN sans certificats avec simplement des clés partagées. Avantage on suprime monsieur l'arbitre ( SPOF ) ! Configuré en mode tap entre chaque serveur avec un up.sh qui ajoute l'interface tap0 tap1 un sur une interface bridge, Au final la configuration est plutôt simple et efficace d'après moi.
Victor
Posted on
Hello,
Dans la configuration du tuto, l'arbitre n'est pas un SPOF, puisque s'il tombe, ça ne stoppe pas les services. L'objectif de l'arbitre est uniquement d'avoir un nombre impair de nodes, ce qui est nécessaire dans le cluster pour prendre des décisions automatiquement (je ne parle pas de la possibilité de forcer 2 nodes, qui n'est pas cohérent ici :) )
Ceci dit, ta solution m'intéresse, que veux tu dire par utiliser OpenVPN avec des clefs partagés ? L'ajout des interfaces tap a l'air d'être à peu près ce que je fais ici, mais si tu as seulement 2 serveurs, je ne saisis pas bien quel est l'avantage ?
De la même façon, si tu peux détailler pourquoi tu penses que l'arbitre est un SPOF, ça m'intéresse, j'ai peut être loupé quelque chose dans mon concept, je suis pas infaillible ;)
A plush'
Guillaume
Posted on
Hello,
Toute mes excuses j'ai du lire le tuto en diagonale ! Finalement la seule différence entre nos configurations est l'utilisation pour ma part de openvpn un plus simplement.
Je crée une clé partagé avec la commande
openvpn --genkey --secret static.key
Cette clé est présente sur chaque serveur et identique, ensuite dans la conf client ou serveur il suffit de mettre l'option "secret /etc/openvpn/static.key".
Ca évite de gérer les certificats.
Au niveau de la sécurité on peut il me semble générer des clés plus robuste.
Je pense que le choix entre ces deux solutions dépend de l'importance du projet.
Plus d'info sur le site:
http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html
Guillaume
Posted on
En tout cas ! Félicitation pour ce tuto qui je pense est le plus complet dans la langue de Molière ! J'attend avec impatience de voir comment vous abordez la gestion du stockage drbd ! Personnellement je préfère attendre la version 9.1 qui permettra la mise en place de plus de deux noeuds primaires simultanément. En attendant je suis passé sur une solution ceph. Bonne continuation pour vos articles !
FOYER Julien
Posted on
Bonjour,
Tout d'abord merci pour se tuto. afin de continuer et faire des tests j'aurais une question pour DRDB vous utiliser une interface réseau particulière j'ai lu a plusieurs reprise qu'il lui faudrait une interface réseau dédié pour la réplication ?
Si quelqu'un peut m'aiguillé ou me dire si il faut utilisé VMBR1 dans la configuration de drbd. Merci d'avance.
Cordialement et bonne continuation.
Victor
Posted on
Bonjour Julien,
Pas de soucis pour le tuto :)
Et désolé pour mon temps de réaction longuet.
Pour répondre à ta question, dans une configuration idéale, il vaut mieux en effet avoir une interface dédiée pour DRBD, histoire d'avoir le meilleur débit possible tout en ne paralysant pas les interfaces habituelles de l'hyperviseur.
Cependant dans le cadre du tuto, on a uniquement une connexion Internet entre les 2 serveurs (cluster Distant entre 2 data center), et donc on va être obligé d'utiliser vmbr1 pour cette liaison, à travers le VPN monté dans la partie 2.
Le débit n'est pas du coup pas exceptionnel et peut provoquer quelques latences au niveau des VM (si tu en as beaucoup ou si elles ont des BDD lourdement utilisées).
Dans les faits je n'ai pas constaté de réels ralentissement avec une dizaine de KVM faisant du VPN et du site web interne.
En data center on peut s'attendre à quand même 100Mbps de débit (théorique), c'est normalement suffisant pour s'amuser un peu ;)
J'espère t'avoir répondu.
A plush' !
ROchdi
Posted on
Bonjour,
Super ton tuto :)
Est ce que on va voir très prochainement la publication des parties restantes ?
Rochdi
Yohann P
Posted on
Hello ! A quand la suite ? j'ai hâte, super bien expliqué !
Fabrice
Posted on
Bonjour,
La réplication entre les cluster se fait combien de fois par jours? La HA éteint-elle la VM ou elle reste allumé comme la solution de Fault Tolerance chez VMWare avec un VCPU?
Peux ton faire de la HA en direct avec un cable réseau entre deux machines comme le fait les NAS Synology?
Cordialement
Fabrice
Victor
Posted on
Bonjour,
Pour répondre à tes questions :
1) Avec le système DRBD, la réplication se fait en temps réel, car DRBD permet de faire un système de RAID 1, mais via le réseau. Du coup, tout ce qui est écrit à droite est immédiatement écrit à gauche, à la latence prêt.
Ici, dans le cadre d'un cluster distant, la réplication se fera comme si on utilisait un disque de vitesse égale à la bande passante (pour simplifier). Il est donc préférable de ne pas mettre de machines trop gourmandes en I/O. Pas de souci par contre pour une configuration de ce type sur un réseau local (en gigabits)
2) L'idée du HA est que la machine soit basculée sans coupure. Dans les faits avec ce système, c'est effectivement le cas, la machine bascule sans se rendre compte qu'elle a changée de côté. Il y a par contre forcément une latence pour la joindre (le temps que les ARP se recalent). Cette latence est de nouveau beaucoup plus limitée en cas de configuration sur un réseau local, et quasi nulle si on peut disposer d'IP failover.
3) Du coup, découlant de mes réponses au dessus oui, on peut tout à fait faire ça avec un câble en direct :)
C'est même beaucoup plus performant, et on peut se passer de toute la partie OpenVPN puisque le réseau est direct (l'intérêt de l'OpenVPN étant principalement de donner la possibilité de faire du multicast sur Internet de manière propre, et de chiffrer la discussion DRBD). Par contre du coup, ce qui t'intéresserait plus, c'est la config du DRBD, qui est la suite de ces articles (Et qui arrivera un jour, je ne désespère pas ! :s)
A plush'
Victor
Nicolas
Posted on
Bravo pour cette série d'article. Cependant quand est-il de la suite ? (qui m'intéresse le plus au final, histoire de comparer nos pratiques :) ) Merci
Kriss
Posted on
Mama mia, on attend avec impatience les articles suivants. Peut-être en rajoutant une 25è heure à tes journées? :)
Une question: les fonctionnalités de cluster et de HA sont-elle spécifiques à Proxmox, ou bien sont-ce des fonctionnalités offertes par openvz/kvm (voire par d'autres packages)? Dit différemment, pourrait-on faire la même chose sans proxmox?
Je pose la question car c'est toujours intéressant de garder une certaine autonomie par rapport à une solution dont la société porteuse Proxmox AG a une politique pas forcément très visible ou pérenne.
ibasaw
Posted on
Bonjour,
Super intéressant !
Faudra que j'essaye de faire tout le tuto !!!!
J'attend la suite avec impatience, vu que je n'y connais rien du tout.
Est ce prévu ou c'est un projet abandonné ?
++
Victor
Posted on
Hello ibasaw,
Le projet n'est pas abandonné. Je compte toujours le terminer, mais malheureusement les tas d'autres trucs qui s'accumulent sur mon bureau m'empêchent de trouver le temps pour avancer sur drbd.
En plus, contrairement à OpenVPN qui est assez connu et plutôt stabilisé, DRBD vit énormément, et j'apprends toujours de nouvelles choses dessus, du coup j'ai tendance à ne pas arrêter d'effacer ce que j'écris pour remplacer des trucs à droite et à gauche. Si j'avais écris l'article il y a un an, j'aurai sans doute du le supprimer pour le réécrire en rajoutant des améliorations dedans ^^"
Bon, après il faut avouer que dans l'optique de Proxmox 2.1 où j'avais commencé ce tuto, le HA via un DRBD distant était quand même assez instable, car à la moindre latence le risque de désynchro apparaissait, et ça DRBD n'aime pas du tout. De plus, le système de fichier de cluster de Proxmox est encore plus sensible, et donc déclenchait des basculements alors que tout allait bien, donc comme je l'indiquais au tout début du tuto, cette configuration en production avec des serveurs physiquement distant et assez mal interconnecté est de toute façon peu fiable. C'est surtout pour le trip technique disons.
Du coup, c'est aussi une des principales raisons pour laquelle je me suis arrêté là et que depuis 1 an je n'arrête pas de changer la suite et de corriger des trucs. Peut être que je n'aurai jamais un truc viable à poster, je ne sais pas, mais en tout cas je continue d'y travailler :)
Merci pour ton intérêt en tout cas ! (Et merci à tous ceux qui s'y intéressent sans forcément poster :))
giraudsa
Posted on
Bonjour et merci beaucoup pour toutes ces explications. Effectivement, on attend la suite :) Une petite question me taraude, je n'ai peut être pas bien saisi la différence, mais serait il possible de faire la même chose avec Ceph plutôt que DRDB ? En fait, je ne comprends pas bien la différence entre ces deux solutions ?!
@+
Victor
Posted on
Bonjour,
Je ne connais absolument pas Ceph, du coup il m'est impossible de te répondre de manière construite ^^"
Si Ceph permet également de synchroniser 2 partitions entre 2 serveurs via le réseau, j'imagine qu'il devrait pouvoir faire le job
Cédric
Posted on
Bonjour et un grand merci pour ce tuto vraiment bien expliqué.
La suite se fait toujours attendre.
NL
Posted on
Super article !
je m'en suis servi pour créer un LAN entre mes 2 hyperviseurs qui ont uniquement un eth0 sur internet (serveurs SOYOUSTART ovh).
J'ajouterais qu'il est possible de faire du VLAN tagging sur l'interface VPN tapX et les bridger sur les VMs . Cela permet d'avoir des LAN étanches pour les VMs si on veut cloisonner certaines VMs.
Du coup voici un update de up.sh qui va créé un VLAN 10 et VLAN 20 sur lequel j'associe 192.168.10.X et 192.168.20.X. (les tapX.10 et tapX.20 peuvent etre mise a 0 une fois les tests validés et que tout fonctionne).
idem pour le client avec 10.2 et 20.2
Enfin je recommande l'usage d'une VM pfsense qui fait office de GW pour toutes les VM (FW+NAT+routage) en ayant une NIC dans chaque bridge.
Sinon promox; je trouve trop usine a gaz, surtout avec le fuse sur /etc/pve et le symlink de /root/.ssh/authorized_keys vers /etc/pve et enfin le kernel modifié. Ca reste trop intrusif et on perd la flexibilité de la libvirt.
Je recommande libvirt avec webvirtmgr ou webvirtcloud qui est très simple, interface épurée. RIEN à installer sur les hyperviseurs à part la libvirtd configuré pour le TCP.
Partage storage en GLUSTERFS of course !
Et le monitoring avec XYMON.
Encore merci pour ce partage !