38 KiB
Title: Construction du cluster (openvpn) subtitle: ; cluster Proxmox distant (2/4) Date: 2013-02-02 13:35 Modified: 2013-02-02 13:35 Tags: proxmox, debian, iptables, linux, sécurité, tunnel, cluster, haute disponibilité keywords: proxmox, debian, iptables, linux, sécurité, tunnel, cluster, haute disponibilité Slug: cluster-proxmox-distant-2.4-construction-cluster Authors: Victor Status: published
[TOC]
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 !