.png)
Et sans terre sur les mains. Classe non ?
+ +Et bien, c'est possible grâce à SSH. (entre autre hein, tunnel est un terme plutôt répandu en informatique, mais bon ça fait une bonne accroche)
+ +Pour parler plus directement, un tunnel ssh va vous permettre de communiquer via SSH avec un serveur distant, et plus pécisément de rediriger certains ports locaux vers ce serveur, qui en fera ce que vous voulez.
+ ++ +
Typiquement, rediriger un port VNC dans un tunnel SSH permet de se connecter sur une machine distante de manière sécurisée. Alors que VNC de base, c'est quand même tout en clair à l'arrache.
+ +Ce système permet de sécuriser la plupart des routages de ports sales que l'on peut faire sur une box pour rentrer dans son réseau. Bien sûr, il y a aussi des applications techniques plus intéressantes au niveau entreprise :-)
+ +L'un des gros intérêts également, c'est que ça peut être utilisé sur un smartphone (ordiphone) sans aucun hack (ou rootage, ou jailbreak), contrairement à OpenVPN par exemple.
+ +## Il faut pas le dire + +Avec cette technique, vous pouvez également (ouh, c'est mal) passer certaines protections ou proxy, par exemple en redirigeant toutes vos connexion HTTP (port 80) sur un tunnel ssh sur le port 443 (HTTPS très rarement filtré) vers votre serveur, qui ensuite vous redirigera vers le site que vous vouliez.
+ +Inconvenient : vous profitez de votre bande passante potentiellement pourrie, surtout si vous vous auto-hébergez (c'est le bien !), puisque où que vous soyiez, toutes vos requêtes Internet passeront par chez vous.
+ +Avantage : vous mettez un doigt dans l'os à tout ces "filtrages" pseudo sécurité qui en fait font chier que les gens honnêtes. (Dont vous faites bien sûr partie)
+ +Ce besoin qu'on a tous connu (ou qu'on imagine au moins) servira de contexte pour ce tuto.
+ ++ +## Le principe + +
Comme d'habitude, un petit rappel du principe technique de la chose.
+ +Nous allons mettre en place sur un serveur, placé où bon vous semble, ce qu'on appelle un shell SSH qui attendra des connexions extérieures.
+ +Ce système est sensé permettre un accès SSH à votre serveur. Comme ce n'est pas le but ici, nous allons détourner le problème en mettant en place un shell hyper restreint. De cette façon vous pourrez fournir la connexion à qui vous voulez, en étant sûr qu'ils ne feront pas de mauvaises choses avec votre serveur. (On ne sait jamais :-) )
+ +La connexion se fera grâce à un couple clef/mot de passe, pour une sécurité maximum. La connexion au tunnel sera interdite par tout autre moyen, ce qui permet de limiter les attaques par brute force notamment.
+ +Chaque personne voulant se connecter devra donc posséder un couple clef/mot de passe fourni par vous. Dans cette optique et pour suivre plus simplement qui a quoi, nous allons créer pour chaque compte un utilisateur du système, qui aura le droit d'utiliser le tunnel. Ces utilisateurs appartiendront tous au groupe tunnelssh.
+ +Ce système, même s'il peut créer beaucoup d'utilisateur, présente l'avantage d'être à la fois clair et d'avoir des logs faciles à lire (chaque tentative de connexion étant loggué par utilisateur)
+ +Le système de redirection de port sera à votre convenance. Comme dit plus haut, j'utiliserais pour ma part le port 443, le plus communément ouvert même dans des lieux "limitatifs" sur des wifi "ouverts".
+ ++ +## Matériels, connaissances, besoins divers + +
Comme toujours quand on est un gros hacker barbu, plusieurs choses s'imposent.
+ +Tout d'abord, il va vous falloir un serveur sous Linux, qui permettra d'installer la sortie du tunnel. Vous vous connecterez avec votre machine sur lui, qui se chargera de rediriger ce que vous voulez où vous voulez.
+ +Pour ma part, j'utilise debian, mais SSH étant plutôt répandu, ça ne posera pas de problème à transcrire ailleurs.
+ +Il vous faudra aussi une autre machine servant de client pour les tests (Ordiphone Android/Iphone, PC fixe, PC portable, tablette, ...)
+ +Il est conseillé de disposer d'un minimum de connaissances dans la ligne de commande, et connaître un peu le réseau (notamment les ports) est un plus apprécié. Cependant, il est possible de copier-coller les commandes, donc pas la peine de trembler si vous ne maitrisez pas le bousin :-)
+ ++ +
Enfin, comme l'objectif est de travailler honnêtement pour promouvoir un Internet plus libre, une bonne bière n'est pas de refus !
+ ++ +## Bien. On est parti. + +### configuration du tunnel + +
Pour commencer, connectez vous sur votre serveur, via un SSH classique. Si vous utilisez directement un écran/clavier/souris, il faudra vérifier qu'openSSH est correctement installé :
+ +$ sudo aptitude install openssh-server
+ +Une fois cela fait, nous allons créer une deuxième instance d'OpenSSH server, qui va écouter sur le port 443 et qui servira exclusivement pour le tunnel. Pour ce faire, créez un fichier sshd_config_tunnel, placé dans /etc/ssh :
+ +$ sudo nano /etc/ssh/sshd_config_tunnel
+ +A l'intérieur, copiez-collez ce qui suit :
+ +Port 443
+
+#ListenAddress ::
+#ListenAddress 0.0.0.0
+Protocol 2
+# HostKeys for protocol version 2
+HostKey /etc/ssh/ssh_host_rsa_key
+HostKey /etc/ssh/ssh_host_dsa_key
+#Privilege Separation is turned on for security
+UsePrivilegeSeparation yes
+
+KeyRegenerationInterval 3600
+ServerKeyBits 768
+
+# Logging
+SyslogFacility AUTH
+LogLevel INFO
+
+# Authentication:
+LoginGraceTime 120
+PermitRootLogin no
+AllowGroups tunnelssh
+StrictModes yes
+
+AllowTcpForwarding yes
+#PermitOpen IP_LOCALE:PORT_LOCAL
+AllowAgentForwarding no
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+AuthorizedKeysFile %h/.ssh/authorized_keys
+
+IgnoreRhosts yes
+RhostsRSAAuthentication no
+
+HostbasedAuthentication no
+#IgnoreUserKnownHosts yes
+
+PermitEmptyPasswords no
+
+ChallengeResponseAuthentication no
+PasswordAuthentication no
+
+# Kerberos options
+#KerberosAuthentication no
+#KerberosGetAFSToken no
+#KerberosOrLocalPasswd yes
+#KerberosTicketCleanup yes
+
+# GSSAPI options
+#GSSAPIAuthentication no
+#GSSAPICleanupCredentials yes
+
+X11Forwarding no
+X11DisplayOffset 10
+PrintMotd no
+PrintLastLog yes
+TCPKeepAlive yes
+#UseLogin no
+
+#MaxStartups 10:30:60
+#Banner /etc/issue.net
+
+AcceptEnv LANG LC_*
+
+Subsystem sftp /usr/lib/openssh/sftp-server
+
+UsePAM yes
C'est en fait un fichier de configuration ssh classique modifié pour notre usage. Je l'ai épuré des commentaires pour qu'il ne soit pas trop lourd, et j'ai mis en gras les morceaux importants :
+ ++ +
Il va également vous falloir lancer ce serveur en parallèle du vrai serveur SSH (que je vous conseille de laisser pour les accès "administratifs" dont vous pourriez avoir besoin).
+ +Pour ce faire, il suffit de créer dans le dossier /etc/init.d/ un nouveau fichier de lancement ssh :
+ +$ sudo nano /etc/init.d/ssh_tunnel
+ +Dans lequel vous pouvez copiez-collez :
+ +#! /bin/sh
+
+### BEGIN INIT INFO
+# Provides: sshd_tunnel
+# Required-Start: $remote_fs $syslog
+# Required-Stop: $remote_fs $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: OpenBSD Secure Shell server
+### END INIT INFO
+
+set -e
+
+# /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon
+
+test -x /usr/sbin/sshd || exit 0
+( /usr/sbin/sshd -\? 2>&1 | grep -q OpenSSH ) 2>/dev/null || exit 0
+
+umask 022
+
+if test -f /etc/default/ssh; then
+. /etc/default/ssh
+fi
+
+. /lib/lsb/init-functions
+
+if [ -n "$2" ]; then
+SSHD_OPTS="$SSHD_OPTS $2"
+fi
+
+SSHD_OPTS="$SSHD_OPTS -f /etc/ssh/sshd_config_tunnel"
+
+# Are we running from init?
+run_by_init() {
+([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]
+}
+
+check_for_no_start() {
+# forget it if we're trying to start, and /etc/ssh/sshd_not_to_be_run exists
+if [ -e /etc/ssh/sshd_not_to_be_run ]; then
+if [ "$1" = log_end_msg ]; then
+log_end_msg 0
+fi
+if ! run_by_init; then
+log_action_msg "OpenBSD Secure Shell server not in use (/etc/ssh/sshd_not_to_be_run)"
+fi
+exit 0
+fi
+}
+
+check_dev_null() {
+if [ ! -c /dev/null ]; then
+if [ "$1" = log_end_msg ]; then
+log_end_msg 1 || true
+fi
+if ! run_by_init; then
+log_action_msg "/dev/null is not a character device!"
+fi
+exit 1
+fi
+}
+
+check_privsep_dir() {
+# Create the PrivSep empty dir if necessary
+if [ ! -d /var/run/sshd_tunnel ]; then
+mkdir /var/run/sshd_tunnel
+chmod 0755 /var/run/sshd_tunnel
+fi
+}
+
+check_config() {
+if [ ! -e /etc/ssh/sshd_not_to_be_run ]; then
+/usr/sbin/sshd $SSHD_OPTS -t || exit 1
+fi
+}
+
+export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
+
+case "$1" in
+start)
+check_privsep_dir
+check_for_no_start
+check_dev_null
+log_daemon_msg "Starting OpenBSD Secure Shell server" "sshd_tunnel"
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/sshd_tunnel.pid --exec /usr/sbin/sshd -- $SSHD_OPTS; then
+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+stop)
+log_daemon_msg "Stopping OpenBSD Secure Shell server" "sshd_tunnel"
+if start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd_tunnel.pid; then
+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+
+reload|force-reload)
+check_for_no_start
+check_config
+log_daemon_msg "Reloading OpenBSD Secure Shell server's configuration" "sshd_tunnel"
+if start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile /var/run/sshd_tunnel.pid --exec /usr/sbin/sshd; then
+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+
+restart)
+check_privsep_dir
+check_config
+log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd"
+start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile /var/run/sshd_tunnel.pid
+check_for_no_start log_end_msg
+check_dev_null log_end_msg
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/sshd_tunnel.pid --exec /usr/sbin/sshd -- $SSHD_OPTS; then
+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+
+try-restart)
+check_privsep_dir
+check_config
+log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd"
+set +e
+start-stop-daemon --stop --quiet --retry 30 --pidfile /var/run/sshd_tunnel.pid
+RET="$?"
+set -e
+case $RET in
+0)
+# old daemon stopped
+check_for_no_start log_end_msg
+check_dev_null log_end_msg
+if start-stop-daemon --start --quiet --oknodo --pidfile /var/run/sshd_tunnel.pid --exec /usr/sbin/sshd -- $SSHD_OPTS; then
+log_end_msg 0
+else
+log_end_msg 1
+fi
+;;
+1)
+# daemon not running
+log_progress_msg "(not running)"
+log_end_msg 0
+;;
+*)
+# failed to stop
+log_progress_msg "(failed to stop)"
+log_end_msg 1
+;;
+esac
+;;
+
+status)
+status_of_proc -p /var/run/sshd_tunnel.pid /usr/sbin/sshd sshd && exit 0 || exit $?
+;;
+
+*)
+log_action_msg "Usage: /etc/init.d/ssh_tunnel {start|stop|reload|force-reload|restart|try-restart|status}"
+exit 1
+esac
+
+exit 0
Ce fichier est une copie du fichier /etc/init.d/ssh classique, mais modifié pour lancer le bon fichier de configuration et pour tourner en parallèle du serveur classique (notamment avec son propre pid)
+ +Les parties modifiées sont en gras.
+ +Enregistrez le fichier puis rendez-le exécutable.
+ +$ sudo chmod 755 /etc/init.d/ssh_tunnel
+ +Si vous le souhaitez, vous pouvez configurer le tunnel pour se lancer au démarrage :
+ +$ sudo update-rc.d ssh_tunnel defaults
+ +### Configuration du groupe d'utilisateur + +Nous allons ensuite créer le groupe tunnelssh, qui sera utilisé pour toutes les connexions.
+ +$ sudo groupadd tunnelssh
+ +Il suffira ensuite de créer vos utilisateurs comme appartenant à ce groupe pour leur donner l'autorisation de se connecter au tunnel. Nous allons voir un script permettant de faire ça tout seul. :-)
+ +### Configuration du shell + +Afin que vos utilisateurs ne puissent pas se balader dans votre serveur via l'accès SSH du tunnel, nous allons créer un shell bidon. Cela permettra en plus d'afficher une jolie bannière pour l'utilisation du tunnel.
+ +En avant. Créez un fichier dans /usr/bin :
+ +$ sudo nano /usr/bin/tunnelshell
+ +Qui contient quelque chose dans ce genre là :
+ +#!/bin/bash
+echo "Connexion limitée au tunnel SSH."
+read -p "Appuyez sur ENTREE pour vous déconnecter..."
Ainsi, toute personne se connectant sur votre tunnel verra apparaître ce message :
+ +Connexion limitée au tunnel SSH.
+ +Appuyez sur ENTREE pour vous déconnecter...
+ +Comme indiqué, une pression de la touche entrée provoque la déconnexion immédiate du tunnel.
+Vous êtes bien sûr libre de changer le message ! ;-)
A ce stade, votre tunnel ssh est prêt à être utilisé. Il suffit de créer un utilisateur appartenant au groupe tunnelssh, de lui configurer comme shell /usr/bin/tunnelshell, puis de lui créer son couple clef/mot de passe.
+ +Comme je suis super sympa (mouahahah), je vous propose un petit script qui fait tout ça tout seul.
+ +Je vous conseille de le placer dans le dossier /root, ou à défaut dans un dossier à accès limité, puisqu'il contiendra tous les certificats de tous vos utilisateurs.
+ +$ sudo mkdir /root/tunnelSSH
+ +$ sudo nano /root/tunnelSSH/Addsshtunneluser.sh
+ +Dans celui-ci, vous pouvez mettre :
+ +#!/bin/bash
+
+if [ "$1" = "" ]; then
+echo "Usage : Addsshtunneluser.sh name passphrase
+fi
+
+if [ "$2" = "" ]; then
+echo "Usage : Addsshtunneluser.sh name passphrase
+fi
+
+mkdir /home/$1
+mkdir /home/$1/.ssh
+useradd $1 --home-dir /home/$1 --groups tunnelssh --no-user-group --shell /usr/bin/tunnelshell
+ssh-keygen -t dsa -b 1024 -N $2 -f /home/$1/.ssh/id_dsa
+cp /home/$1/.ssh/id_dsa.pub /home/$1/.ssh/authorized_keys
+chmod 700 /home/$1/.ssh
+chmod 600 /home/$1/.ssh/authorized_keys
+chown -R $1:tunnelssh /home/$1
+cp /home/$1/.ssh/id_dsa tunnelssh-$1
Ce script s'exécute de la manière suivante :
+ +$ sudo bash /root/tunnelSSH/Addsshtunneluser.sh UTILISATEUR MOTDEPASSE
+ +Le script va alors créer un utilisateur portant ce nom. L'utilisateur appartiendra au groupe tunnelssh, et disposera de son répertorie /home/UTILISATEUR
+ +Le script va ensuite créer la clef SSH à l'aide du MOTDEPASSE (on parle bien sûr d'un couple clef privée/clef publique). Il va ensuite copier la dite clef dans le dossier /root/tunnelSSH/ avec un nom du type tunnelssh-UTILISATEUR, ce qui va vous permettre de la récupérer facilement pour la transmettre à l'utilisateur concerné.
+ +Il lui faudra alors utiliser cette clef pour configurer son tunnel ssh de la manière suivante :
+ +Normalement, tout doit baigner !
+ +## Voila, c'est creusé + +Avec tout ça, vous devriez être à même de vous connecter depuis n'importe où sur votre serveur.
+ +A titre informatif, pour mettre en place le tunnel côté client :
+ +Si jamais j'ai des demandes, je me lancerai dans un petit tuto pour l'une ou l'autre des plateformes :-)
+ +Si vous avez des soucis, posez la question dans les commentaires !
diff --git a/content/Système/cluster-proxmox-distant-1.4-concept.md b/content/Système/cluster-proxmox-distant-1.4-concept.md new file mode 100644 index 0000000..e9fbe04 --- /dev/null +++ b/content/Système/cluster-proxmox-distant-1.4-concept.md @@ -0,0 +1,196 @@ +Title: Cluster Proxmox distant (1/4) +subtitle: ; le concept +Date: 2013-01-16 19:00 +Modified: 2013-01-16 19:00 +Category: Système +Tags: proxmox, système, haute disponibilité, virtualisation, cluster +keywords: proxmox, système, haute disponibilité, virtualisation, cluster +Slug: cluster-proxmox-distant-1.4-concept +Authors: Victor +Status: published + +[TOC] + +## Commençons par le début + +Oui, car ça fait un petit moment que je souhaite écrire une série d'articles sur Proxmox, articles présentant la mise en place de A à Z d'un cluster.
+ +En effet, Proxmox depuis sa version 2 propose un système de clustering basé sur Red Hat, qui présente un potentiel très intéressant de fonctionnalités pour parvenir à un système très stable.
+ +Accessoirement, ça présente également un potentiel de problèmes clairement non négligeables. Mais bon.
+ +Dans cette série d'articles, je vais donc tâcher de présenter sous le biais de tutoriel, la mise en place d'un tel cluster. Cependant, comme il est difficile de couvrir tous les cas possibles, je vais me permettre de me placer dans un cas précis et défini, adaptable et qui correspond à une problématique assez difficile.
+ +L'idée va être de configurer 3 serveurs distants géographiquement en cluster proxmox, avec un système de haute disponibilité.
+ +Dans ce premier article, je vais donc présenter la problématique du système, ainsi que le vocabulaire et les concepts importants à comprendre et à retenir. Les prochains articles seront plus techniques, promis !
+ +Néanmoins, je partirais du principe que vous avez déjà une petite expérience de Proxmox (au moins savoir l'installer !), et que vous maitrisez SSH tout en ayant des bases de réseaux. J'essaierai quand même de rendre le plus compréhensible possible les problématiques techniques !
+ +Je m'excuse d'avance pour la longueur des articles, mais la réalisation est quand même assez complexe ;-)
+ +Pour ces articles, je m'appuie principalement sur les 3 liens suivants (merci beaucoup à eux pour leur travail !)
+ +Je me suis également servi du forum et du wiki proxmox.
+ +## Vocabulaire + +Dans le cas d'un cluster, on peut donner à chaque serveur du cluster un poids différent ou identique, qui va influencer sur les choix que va prendre l'intelligence du cluster en cas de besoin. Par exemple, tous les serveurs ont un poids de un. S'il y a 5 serveurs, le quorum va être de 3. Il faut être au moins 3 pour prendre une décision. Dans ce cas, en cas de panne par exemple sur la liaison réseau entre les serveurs, ceux-ci prendront des décisions en fonction de leur quorum. Prenons un exemple :
+ +Nous avons 5 serveurs, montés en HA, avec un poids de 1 chacun. Une panne réseau survient, qui isole 3 serveurs d'un côté et 2 de l'autre. Chaque serveur va vérifier la connectivité avec les autres. Les serveurs ayant le quorum (le groupe de 3), se trouvant en majorité, peuvent prendre la décision de démarrer chez eux les services précédemment hébergés chez les 2 serveurs manquants. Les serveurs n'ayant plus le quorum (le groupe de 2) vont par contre décider qu'ils ne sont plus en majorité, et donc déduire que d'autres ayant le quorum vont prendre leur place. Ils vont donc prendre la décision de couper leurs services, voire de s'éteindre en attendant une intervention extérieure.
+ +Ce système permet d'éviter que des services tournent en même temps à deux endroits différents. Imaginez par exemple que la connexion entre les 2 groupes saute, mais que la connectivité Internet de chaque groupe fonctionne encore. Sans quorum, alors les utilisateurs seraient dirigés sur le site web de gauche ou de droite, rendant ingérable la restauration. En effet, si le site est un forum, alors les utilisateurs ont postés des messages à droite ET à gauche, il faudrait donc les fusionner pour revenir à un état stable sans perdre de données ! C'est un casse-tête qui a été réglé par la notion de Quorum.
+ +Bien sûr, ce système n'est pas parfait. Pour reprendre notre exemple, si le problème de connectivité fait que nous avons deux groupes de 2 serveurs et un groupe de 1, aucun des groupes n'a le quorum et tous risquent de s'éteindre. De la même façon, si nous avons un nombre pair de serveurs (Par exemple 4), le quorum est exactement la moitié, ce qui fait qu'en cas de répartition égale des groupes de serveurs, chacun va décider de démarrer les services de l'autre groupe !
+ +En conséquence, il est très important de bien comprendre cette notion. Dans l'idéal, vous devez toujours monter des clusters avec un nombre impair de serveurs, quitte à ce que l'un deux soit juste une machine virtuelle dans un coin servant 'd'arbitre'. Monter un cluster pair est possible, mais vous acceptez alors le risque de créer des situations qui seront difficilement gérables.
+ +Par exemple, si un serveur redémarre par accident, le cluster se voyant en majorité va démarrer les services de la node défaillante. Sauf que une fois la node redémarrée, elle va rentrer de nouveau dans le cluster, donc avoir la majorité, et donc décider de lancer ses services. Ce qui va provoquer de nouveau une situation de doublon.
+ +Le rôle du fencing est donc d'autoriser le groupe du cluster ayant le quorum (ayant la majorité) à isoler artificiellement la ou les nodes défaillantes. Cela peut se faire en coupant le courant de la node (via un onduleur pilotable en réseau, via une carte DRAC ou ILO, ...), en coupant son réseau (via un switch manageable), en lui envoyant en boucle des ordres d'exctinction en ssh, ... Plusieurs techniques sont disponibles. Ce concept est important, et en général le plus compliqué et le plus lourd à mettre en place techniquement. Accepter de s'en passer peut poser un certains nombre de problème à l'administrateur, nous en parlerons plus loin. Dans Proxmox, le système de HA ne fonctionne pas si le fencing n'est pas configuré correctement.
+ +Globalement, le quorum sert à pallier à une panne sur la liaison entre les machines, alors que le fencing sert à pallier à une panne matérielle de la machine. Ces deux concepts fonctionnent donc côte à côte.
+ +Voila pour le vocabulaire. Si d'autres mots vous posent problèmes durant la lecture d'un des articles, indiquez le dans les commentaires, je le rajouterai ici.
+ ++ +## Problématique + +
Dans le cadre de la mise en place d'un cluster, le principe basique consiste à mettre plusieurs serveurs identiques dans une baie, et à se servir d'eux pour augmenter la disponibilité de ceux-ci.
+ +Par exemple, vous avez 3 serveurs, si l'un d'eux tombe, vous basculez tous ses services quasiment instantanément sur les deux autres, vous permettant d'avoir une disponibilité des services continue, même en cas de panne matérielle.
+ +De plus le cluster vous permet de gérer, depuis une seule interface, tous vos serveurs.
+ +C'est ce que propose Proxmox V2. En montant différents serveurs en cluster, vous pouvez en vous connectant à l'interface web de n'importe quel serveur créer des machines virtuelles sur le serveur de votre choix, gérer les sauvegardes de manière globale, créer des droits d'accès, bref, faire tout ce qui est possible d'habitude, mais sur tous vos serveurs d'un coup !
+ +En fait, la vraie problématique qui se pose est la suivante :
+ +Quid si vous voulez également une redondance géographique ?
+ +Là, ça devient plus compliqué. Se posent directement les problèmes de communication entre les serveurs (qui doit être sécurisée !), le temps de basculement en cas de panne (qui doit être réduit, sinon sans intérêt), la détection de panne, le basculement des IP publiques, la gestion des serveurs qui ne sont pas identiques, etc, etc.
+ +Rare sont les hébergeurs (en fait, inexistant à moins de payer 3 bras par mois, et encore) qui proposent ce genre de service, à savoir notamment une communication cryptée et des serveurs identiques dans deux lieux géographiquement redondés. A la rigueur, dans deux salles différentes ça peut être possible, et vous leur déléguez tout l'aspect sécurité/redondance/basculement, en leur faisant confiance. (Voir cet article...)
+ +Bon, la question ne se pose pas, je voulais tout faire moi-même, pour la gloire (et aussi pour mon porte monnaie, et également avoir une redondance de fournisseur, ça mange pas de pain).
+ +## Architecture + +Mon système de serveur est assez simple. Je dispose d'un serveur principal, assez costaud, permettant de faire tourner la majorité des services. Certains de ces services sont importants et devront donc faire partie du HA. D'autres le sont moins et il est acceptable de s'en passer en cas de panne matérielle
+ +En secours, je dispose également d'un deuxième serveur, chez un hébergeur différent, bien moins costaud mais à même de faire tourner les quelques services importants dans un mode déprécié.
+ +Ces deux serveurs n'ont aucune liaison locale (étant chez deux hébergeurs différents), présentent des composants matériels différents (ils ne sont pas identiques) et dont donc placés à des endroits géographiquement différents, dans des réseaux différents. Ils ont également leurs propres IP publiques chez chacun des hébergeurs, rendant tout fail over impossible.
+ +Chacun de ces serveurs utilise Proxmox comme système d'exploitation, et tous ces fameux services sont en fait placés dans des machines virtuelles, l'hyperviseur assurant un service minimum (en gros du routage et du NAT).
+ +L'idée va donc consister à mettre en place un système de haute disponibilité pour les services souhaités, entre les deux serveurs, afin qu'une panne du serveur principal ne soit pas handicapante.
+ +### Quorum + +Comme il est important de disposer d'un nombre impair de nodes pour permettre le fonctionnement du quorum, je rajoute à cette infrastructure un troisième serveur, qui n'héberge aucun service et sert uniquement d'arbitre. En fait, c'est une simple machine virtuelle avec Proxmox d'installé, hébergée chez moi.
+ +### Fencing + +Malheureusement, peu d'hébergeurs proposent un système permettant la mise un place d'un fencing. Encore moins à travers Internet. J'ai donc du choisir de me passer de fencing. Ceci est un choix qui vous attirera les foudres de la communauté Proxmox/Red Hat, et qui risque de transformer toutes vos demandes sur les forums officiels en chasse à l'homme. J'en ai pleinement conscience. Cependant, la problématique technique imposée ne me laisse pas d'autres choix. Je proposerai donc dans ces articles un moyen de "tromper" le fencing pour permettre le bon fonctionnement du HA.
+ +Il est important de comprendre que c'est un choix qui peut amener un certain nombres de problématiques techniques importantes, notamment pour remonter les services après une panne. Cependant, rien d'insurmontable. Mais c'est quand même très moche. Nécessité fait loi...
+ +### Multicast + +Le système de cluster Proxmox nécessite une liaison multicast entre toutes les nodes. En effet, le cluster communique via ce biais entre les différentes nodes. Ce système présente l'avantage de supprimer la notion de maître/esclave présent dans Proxmox v1.X, mais est une problématique importante dans le sens qu'AUCUN réseau public n'autorise le multicast. Et surtout pas le réseau Internet.
+ +Pour résoudre ce problème, j'utilise une liaison OpenVPN entre les nodes, et le cluster est construit via ce tunnel. Cela présente le double avantage de permettre facilement le Multicast sur Internet et de crypter la communication entre les nodes.
+ +Cela présente le double inconvénient de remettre en place une notion de maitre/esclave (il faut un serveur VPN et des clients qui s'y connectent) et de rajouter un point de panne dans le système (si OpenVPN tombe, tout le cluster tombe). Nous verrons comment limiter ces deux problèmes.
+ +### Disque commun et réplication + +Un autre point important dans un cluster HA est que les services HA doivent être répliqués. En effet, si vous voulez que votre serveur de secours puisse redémarrer les machines virtuelles en cas de panne du serveur principal, et bien il faut qu'il ait les données de ces machines à disposition. De plus dans un système HA, ces données doivent être temporellement les plus proches possibles entre le serveur principal et son serveur de secours, sinon vous risquez de perdre pas mal de données lors du démarrage du serveur de secours.
+ +Comme il est couteux d'avoir à disposition un disque réseau supplémentaire à partager entre les serveurs (et qu'il est de plus impossible de le faire via Internet entre deux hébergeurs différents), j'ai fait le choix d'utiliser DRBD, un système permettant de mettre en place un RAID 1 via un réseau. Chaque action faite sur le disque du serveur principal est donc immédiatement répliquée sur le serveur de secours.
+ +Ce système est plutôt robuste, mais est dépendant de la connexion entre vos serveurs. Plus votre liaison sera lente, plus le serveur de secours sera en retard par rapport au serveur principal, ce qui pose notamment problème dans le cas de base de données SQL. Cependant, la latence est minimale dans le cas d'hébergement proposant souvent au minimum 100Mo/s de bande passante.
+ +Sachez tout de même qu'être trop grourmand sur le nombre de services répliqués peut entrainer des lenteurs sur vos machines virtuelles, le disque DRBD pouvant mettre en pause certains processus le temps d'écrire toutes ces données (Comme un disque classique d'ailleurs, bienvenue dans le monde des I/O Wait)
+ +La synchronisation DRBD se fait via le tunnel Openvpn de la même façon que la communication inter-cluster.
+ +Pour ma part, avec une base de données accessible à plusieurs dizaines d'utilisateurs plus une dizaine de serveurs écrivant leurs logs, je n'ai pas eu de soucis à ce niveau-là.
+ +Edit : Attention, et c'est une contrainte importante, utiliser DRBD impose d'avoir des KVM comme uniques machines virtuelles HA. Je n'ai pas réussi à avoir de manière satisfaisante de l'OpenVZ sur du DRBD. Il reste possible d'utiliser OpenVZ pour toutes vos autres machines non HA.
+ +### Terminologie + +Pour simplifier la suite, j'utiliserai les terminologies suivantes :
+ +Parce que c'est toujours plus visible sur un bô schéma :)
+ +
+
+Le PRA fera serveur VPN principal, pour une raison simple : c'est lui qui est sensé tourner en permanence.
+ ++ +## Bon, on commence quand ? + +
Et bien voila, je crois avoir fait le tour de présentation du système que je vais vous apprendre à monter.
+ +Les tutoriels suivants expliqueront comment mettre en place le cluster via OpenVPN, comment monter la réplication DRBD et comment mettre en place le HA en lui-même.
+ +Normalement, tout cela devrait tenir en 4 articles.
+ +Si vous avez des questions sur ce concept ou avez besoin de détails, n'hésitez pas à me laisser un commentaire !
+ ++ +
EDIT : un petit sommaire pour avoir une idée de ce que devrait parler les prochaines articles
+ +A bientôt :-)
diff --git a/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md b/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md new file mode 100644 index 0000000..8ede0e5 --- /dev/null +++ b/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md @@ -0,0 +1,713 @@ +Title: Cluster Proxmox distant (2/4) +subtitle: ; construction du cluster (openvpn) +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 :
+ +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 :
+ +
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 :
+ +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 :-)
+ +Pour être plus confortable, notamment au niveau du système, vous pouvez utiliser la technique suivante :
+ +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 :
+ +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
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'
+-----
# ./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 :
+ +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
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 :
+ +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 ! 
)
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 :
+ ++ +
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.
+ +# 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
+ +# /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 !
+ +diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/0.md b/content/comments/cluster-proxmox-distant-1.4-concept/0.md new file mode 100644 index 0000000..176cbf2 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/0.md @@ -0,0 +1,24 @@ +email: tranxene50@developpeur-neurasthenique.fr +date: 2013-01-17T00:10+01:00 +author: tranxene50 +website: http://blog.developpeur-neurasthenique.fr/ + +Hello ! + +Ouh punaise... J'attends la suite (technique) avec impatience ! + +Je crois que je n'ai jamais lu un article aussi didactique (en français) et notamment en ce qui concerne la notion de quorum avec Proxmox. + +Pour le fencing, c'est clair qu'une solution matérielle est a privilégier mais il est possible (me semble-t-il) de tricher avec un "fence device" virtuel (à creuser, cela implique quelques sacrifices). + +Au niveau de DRBD, même si cela fonctionne correctement, je pense qu'il va y avoir un souci avec les applications qui utilisent massivement la mémoire (cache/buffer), par exemple MySQL. + +Ce que je veux dire c'est que, répliquer les fichiers Innodb ne suffit pas pour garantir l'intégrité des bases : si le serveur de secours démarre, il y aura forcément un recovery des BDD. (A tester dans la vie réelle, MySQL se démerde plutôt bien dans ce cas de figure). + +De tout ce que j'ai lire, pour migrer des containers OpenVZ sans aucune perte de données, il faut impérativement sauvegarder l'état de la mémoire (checkpointing). + +Concernant les IP fail over, quand on utilise des serveurs dédiés via des prestataires différent, c'est clairement la plaie (marche pas...). + +Je cherche toujours une solution a ce problème mais, de ce que j'ai pu comprendre, il faudrait passer un prestataire tiers qui reroute le trafic (donc c'est du transit) là où il faut. Le souci c'est qu'on utilise leur bande passante (logique) et donc, il facturent cela. + +A+ diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/1.md b/content/comments/cluster-proxmox-distant-1.4-concept/1.md new file mode 100644 index 0000000..25a4a5e --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/1.md @@ -0,0 +1,13 @@ +email: courriel@victor-hery.com +date: 2013-01-17T13:21+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 0md + +Hello ! +Merci, j'essaye d'être précis :) + +Pour tes questions, je vais tâcher de traiter ces sujets dans la suite. Mais rapidement, ce que je peux en dire : + - Le fencing peut être détourné via Node Assassin (qui peut faire du fencing via SSH) ou du Manual Fencing (qui consiste à attendre une intervention humaine se chargeant du fencing, donc aucun intérêt). Node Assassin est assez intéressant, mais dans l'optique où la connexion entre les 2 machines est mortes (ce qui est le cas le plus répandu dans un contexte distant comme ça), ça ne sert à rien et le PRA tourne en boucle en attendant de réussir son fencing. La solution la plus simple (et moche !) consiste à bidouiller un script qui retourne exit 0 après avoir envoyé un courriel d'alerte... + - DRBD va imposer (j'aurai peut être pu en parler là d'ailleurs, désolé) d'utiliser KVM. J'ai passé de longues semaines à tenter de faire fonctionner OpenVZ sur DRBD, mais à travers un lien Internet, la latence est trop importante, et le système d'OpenVZ fonctionnant avec des dossiers (private, root, ...) n'est pas viable. Peut être avec le futur ploop, mais alors on perd tout l'intérêt d'openvz-diff-backup :) Etre sous KVM est donc une contrainte importante en effet. Mais ça fonctionne correctement, même avec Mysql, dans le sens où DRBD a une notion de cohérence des données plutôt bien foutue. Pour ma part, je n'ai pas eu de soucis lors de mes tests à ce niveau là. + - Pour les IP failover, je "règle" le problème avec une passerelle portant l'IP publique sur chaque système, qui n'est pas en HA. Et cette passerelle met un jour les DNS dynamiques automatiquement en cas de besoin. C'est le moyen le plus propre que j'ai pu trouver. (Voir l'article sur le DynDNS OVH) Pas vraiment du failover, mais la vitesse de réplication est acceptable (environ 10 minutes), ça marche parfaitement avec des liens IPsec par exemple. diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/10.md b/content/comments/cluster-proxmox-distant-1.4-concept/10.md new file mode 100644 index 0000000..1a6d5f1 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/10.md @@ -0,0 +1,16 @@ +email: lecorvaisier.jerome@gmail.com +date: 2013-02-10T05:14+01:00 +author: Jérôme +website: +replyto: 4md + +Bonsoir, + +Veuillez s'il vous plait continuez à régler le problème par commentaire, ça m'intéresse beaucoup. En effet je suis aussi en train de mettre Proxmox en place en environnement de test pour le moment seulement je ne dispose pas encore de suffisamment de serveurs pour tester le fencing en fonctionnement réel. J'utilise le mode "human" qui indique que c'est aux admins de s'occuper du fencing. + +Utilisant DRBD pour synchroniser le disque, j'ai une petite question. Est-ce qu'on doit utiliser (dans mon cas /var/lib/vz) le mode master-slave ou master-master ? Car la aussi, si on utilise DRBD en master-slave il doit y avoir des options de fencing pour que le noeud slave prenne la main sur la ressource n'est-ce pas ? Ca m'arrangerait bien que vous validiez mes dires :) + +Victor vous avez l'air vraiment documenté sur le sujet. Les commentaires sont vraiment constructifs. + +Merci à vous pour cette mine d'informations! +Bien cordialement diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/11.md b/content/comments/cluster-proxmox-distant-1.4-concept/11.md new file mode 100644 index 0000000..66fc4e4 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/11.md @@ -0,0 +1,23 @@ +email: courriel@victor-hery.com +date: 2013-02-10T13:05+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 4md + +Hello, + +Désolé, c'est vrai que je pense que les commentaires ne sont pas un support très appropriés pour une discussion technique de ce type. Les courriels sont plus pratiques, et permettent plus d'espace de discussion. Surtout que j'ai tendance à être très verbeux ^^ + +Pour l'instant, la discussion avec Gégé semble porter sur un problème de fencing. Le système marche bien en cas de coupure réseau ou de tests manuels, mais le fencing n'est plus efficace lors d'une coupure de courant. En effet l'interface permettant le fencing n'est plus alimentée non plus, et donc impossible de s'en servir. +Du coup les nodes encore allumées tentent en boucle de fencer la node morte, sans succès. +Dans ce genre de cas, les machines en HA ne sont jamais relancées, puisque tout les services cluster sont bloqués même si les nodes ont le quorum. Une solution est alors effectivement de configurer un fencing 'human' pour pallier ce défaut, mais du coup adieu l'automatisme. Pour gégé, il faut essayer de trouver une solution avec une alimentation de secours, voire un onduleur permettant de donner le temps au fencing d'agir :) + +Pour ton problème de DRBD, et dans le cas particulier de Proxmox, il est bien plus simple de mettre en place un disque master/master. ATTENTION ! Il faut que le disque ne soit utilisé que d'un côté à la fois ! Typiquement, prévoir un disque DRBD pour les machines de la node A, et un disque DRBD pour les machines de la node B. En master/master, dès l'activation du HA les machines basculées ont les droits d'écriture et peuvent démarrer. Mais il est impératif que toutes les machines tournant sur le disque DRBD basculent d'un coup. Si certaines tournent à gauche et d'autres à droite, ça peut poser de gros problèmes. (Split brain, comme on dit) +Dans tous les cas et dans le cadre de ce tuto, le basculement est prévu pour être automatique, mais pour remonter le cluster, il faudra y aller à la main, principalement pour cette raison : il faut dire à DRBD quelle node possède les bonnes données et quelle node doit voir ses données écrasées par une synchro. + +Dans le cas où tu n'utilises pas l'ISO Proxmox, et tout particulièrement si tu n'utilises pas LVM pour ta partition système/ton swap, il est possible dans le cluster.conf de définir des "failover domains" qui gèrent les ressources, donc DRBD et LVM. Dans ce cas, tu peux activer le mode master sur un disque DRBD en cas de déclenchement de HA, et tu peux également utiliser CLVM (Clustered LVM), une extension de LVM qui permet de gérer la synchronisation sur DRBD de manière très sympathique (notamment la gestion de qui a le droti d'écrire à quel moment, et qui a raison). Cependant, utiliser ces techniques demandent que LVM soient lancé par les processus de cluster uniquement une fois que les nodes ont démarrées, ce qui est impossible dans le cas de l'ISO Proxmox, puisque la partition système est sur LVM. +Cette technique de CLVM semble permettre plus facilement l'utilisation d'OpenVZ sur DRBD également. + +J'ai choisi dans ces tutos d'utiliser l'ISO Proxmox car son partitionnement LVM se prête bien à la gestion des disques DRBD. Je n'utilise donc pas CLVM, et mes disques DRBD sont en master/master, ce qui pose au final relativement peu de problèmes, étant prévu pour fonctionner en mode Serveur principal/Serveur de secours (Aucune VM ne tournant donc sur le disque DRBD du serveur de secours) + +Voila, j'espère avoir pu vous aider :) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/12.md b/content/comments/cluster-proxmox-distant-1.4-concept/12.md new file mode 100644 index 0000000..7a0eeee --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/12.md @@ -0,0 +1,15 @@ +email: lecorvaisier.jerome@gmail.com +date: 2013-02-11T10:00+01:00 +author: Jérôme +website: +replyto: 4md + +Bonjour, + +Le problème de Gégé m'interpelle, admettons qu'on dispose d'un cluster Proxmox en HA (principal, secondaire, arbitre) avec une partition logique DRBD repliquée entre le serveur principal et secondaire. La solution est basé sur du fencing au niveau node, carte de management uniquement. + +Si un des noeuds est coupé électriquement, l'arbitre et le secondaire s'arrange pour "fencer" le noeud principal via sa carte de management qui n'est plus alimentée et donc... va attendre indéfiniment qu'il revienne dans le cluster pour le killer ? ... + +Les deux serveurs secondaire et arbitre n'auront donc jamais démarré les services du principal ? + +Y'a bon ou je suis vraiment à côté ? :) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/13.md b/content/comments/cluster-proxmox-distant-1.4-concept/13.md new file mode 100644 index 0000000..30ccf3c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/13.md @@ -0,0 +1,16 @@ +email: courriel@victor-hery.com +date: 2013-02-12T17:35+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 4md + +Hello, + +Je confirme, c'est effectivement le cas. Si le système de fencing est en rade, et que du coup le fencing échoue en boucle sur l'arbitre et/ou le serveur de secours, alors les services en HA ne démarreront jamais. +Et en plus dès que le serveur principal se fera de nouveau alimenté, il sera fencé direct. +C'est pourquoi il est conseillé par Proxmox (et Red Hat) d'avoir plusieurs systèmes de fencing pour gérer tous les types de pannes. +En l'occurrence, je pense qu'il est possible d'alimenter indépendamment une carte iDrac ou ILO ? (je ne connais pas bien ce matériel) + +Pour ma part, j'ai remplacé un script de fencing (le script de node assassin) par un script envoyant un courriel et se terminant par exit 0 pour que la node ait l'impression de réussir le fencing. Surement pas la solution idéale, mais à distance... Enfin j'en ai déjà parlé :) + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/14.md b/content/comments/cluster-proxmox-distant-1.4-concept/14.md new file mode 100644 index 0000000..5c4ed51 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/14.md @@ -0,0 +1,20 @@ +email: lecorvaisier.jerome@gmail.com +date: 2013-02-13T11:34+01:00 +author: Jérôme +website: +replyto: 4md + +Bonjour, + +Je re-confirme, après en avoir discuté avec d'autres personnes sur freenode.org, il m'a été dit que ce genre de pannes n'était pas pris en charge, il est donc vivement conseillé de disposer d'un système de fencing au niveau node de type PDU, onduleur manageable plutôt que des cartes de management, ou du moins, en plus du fencing avec les cartes. + +Je commence de plus en plus à me demander, comment le HA de VMware fonctionne. Il s'agit d'environ 80% du parc de virtualisation qui est fournit par VMware, est-ce que le fencing est-il aussi abordé qu'avec Proxmox ? + +Je ne sais pas si c'est de vous, ou de quelqu'un d'autre mais il me semble avoir entendu que les noeuds se suicident dans les systèmes HA de VMware, en savez-vous davantage? Et si oui, quel est votre point de vue entre ces deux types de fencing ? + +Pour ma part, ce problème d'alimentation des cartes de management n'est pas en soi un problème étant donné que c'est aux administrateurs d'intervenir sur les systèmes pour promouvoir un master pour DRBD, activer les volumes LVM et démarrer la VM mais c'est des notions très intéressantes qui montrent combien le fencing peut être contraignants (selon le point de vue de chacun :)) et combien le HA de Proxmox ne se permet pas de créer des situations de split brain. + +Voyez, moi aussi je suis très verbeux :) + +Bien cordialement +Jérôme diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/15.md b/content/comments/cluster-proxmox-distant-1.4-concept/15.md new file mode 100644 index 0000000..1a6ee14 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/15.md @@ -0,0 +1,20 @@ +email: courriel@victor-hery.com +date: 2013-02-14T13:34+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 4md + +Hello, + +Ah, je ne pense pas que cette affirmation sur VMWare vienne de moi. Là, je dois bien admettre mon manque (total ? :s) de connaissance sur VMWare. +Je n'ai encore jamais eu l'occasion d'y toucher, sans parler du temps. Ceci dit, c'est effectivement intéressant de confronter les fonctionnements vis à vis du HA, qui est un système critique mais en même temps extrêmement difficile à gérer. + +A ce sujet là Proxmox est très limitatif, et autant ça peut parfois être bloquant, autant c'est un fonctionnement qui peut se comprendre. Après, si on l'outrepasse, il faut également être conscient des risques ;) +Et puis sur ce genre de principe de cluster en HA, il y aura toujours (toujours !) des cas qu'on n'aura pas pu tester, ou auxquels on n'aura même pas pensé... + +Des noeuds qui se suicident sont une solution intéressante, mais c'est quand même étrange, comment font-ils sans alimentation (par exemple) ? Et comment les nodes restantes peuvent-elles être sûres que c'est le cas ? +Ou alors, en partant du fait que sans le quorum, la node DOIT se suicider, alors les nodes restantes sont sûres que c'est bien le cas, et si jamais elle n'a pas pu le faire (alimentation, encore) c'est qu'elle n'est de toute façon plus en état de fournir le service. Pourquoi pas en effet, c'est une vision inverse de Proxmox mais qui a ses arguments :) + +Merci de m'avoir signalé ça tiens ! + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/16.md b/content/comments/cluster-proxmox-distant-1.4-concept/16.md new file mode 100644 index 0000000..d59b6c8 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/16.md @@ -0,0 +1,21 @@ +email: lecorvaisier.jerome@gmail.com +date: 2013-02-16T16:04+01:00 +author: Jérôme +website: +replyto: 4md + +Bonjour :) + +Oui, la notion peut paraître déroutante... Si ce n'est pas de vous, c'est en dévorant des blogs ou des sites qui parlent de libre où j'ai du voir ça... Il me semble que c'était soufflé sans affirmation, aucunes. + +Dans le principe, le noeud ne peut plus transmettre au cluster (pas de réponses au multicast par exemple), il ping la passerelle, s'il n'obtient pas de réponses, alors il désactive ses services du cluster en se disant que les autres noeuds du cluster vont activer les services qu'il proposait auparavant... Il se suicide via un reboot, une extinction, je ne sais pas vraiment... en ce qui concerne un problème réseau par exemple... + +En ce qui concerne une panne d'alimentation... Le cluster fonctionne normalement, un des noeuds vient à sortir du cluster (il ne répond plus à ses pairs), ses services sont donc considéré comme éteint/libre par le cluster et il va alors s'arranger pour les démarrer sur les noeuds restants.... + + +Voilà.. voilà.. mais encore une fois, ce n'est là en aucune manière une affirmation du fonctionnement du HA de VMware... Enfin, les hypothèses sont vraiment intéressante. Il serait sympa de pouvoir choisir dans les modes de fonctionnement du HA de Proxmox, afin de pouvoir coller avec toutes les situations... ;) + +A proposer dans la roadmap ;) + +Bien cordialement +Jérôme diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/17.md b/content/comments/cluster-proxmox-distant-1.4-concept/17.md new file mode 100644 index 0000000..7745d9e --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/17.md @@ -0,0 +1,9 @@ +email: bentien@live.fr +date: 2013-04-17T15:35+01:00 +author: Ozzi +website: + +Bonjour, +Tout d'abord merci pour votre explication très claire des notions de quorum et de fencing et pour votre article en général ! +Vous dites qu'utiliser drbd avec openVZ n'est pas réalisable, est-ce vraiment le cas ? Je suis actuellement le tuto de nedProduction que vous citez au début de l'article et il me semble que toutes ses VM sont en openVZ lorsqu'il met en place drbd. +D'ailleurs pensez vous bientôt publier votre 3ème article dans lequel vous aborderez drbd ? :) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/18.md b/content/comments/cluster-proxmox-distant-1.4-concept/18.md new file mode 100644 index 0000000..a9eeebf --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/18.md @@ -0,0 +1,17 @@ +email: courriel@victor-hery.com +date: 2013-04-18T08:44+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 17md + +Hello, +C'est vrai que je n'ai pas précisé en détail le problème d'OpenVZ avec DRBD. En fait, le principal souci est que via DRBD, on gère un système de fichier, et que du côté d'OpenVZ, on gère une arborescence de fichier. Du coup, autant DRBD marche très bien avec KVM (qui est un disque virtuel, pour lesquels DRBD peut utiliser un système d'état de cohérence), autant il a du mal avec l'arborescence OpenVZ. De plus, OpenVZ utilise un dossier "private" où il stocke les fichiers de la VM, et un 2eme dossier "root" où il place les fichiers de la VM quand elle fonctionne, mais qui n'existe plus quand elle est arrêtée, etc. +Et ça, d'expérience DRBD n'aime pas du tout, car il se lance dans des réplications dans tous les sens quand une VM démarre, et ensuite a du mal à retrouver un état de cohérence de disque. +J'ai fait des tests en utilisant un système de fichier lvm fait exprès pour gérer ce genre de souci avec LVM (clvm), mais le problème est que clvm doit être lancé au démarrage de LVM, et comme Proxmox utilise LVM pour ses propres partitions, CLVM se lançait dès le démarrage, c'est à dire avant que DRBD n'ai pu établir sa connexion, ce qui crashait complètement le système (à éviter donc !) C'est une technique qui fonctionnerait sans doute sur une machine sans LVM pour ses partitions (peut être une debian classique avec Proxmox par dessus), mais je n'ai pas été plus loin, Proxmox étant à utiliser pour moi :) +Ce problème pourrait également être réglé avec le nouveau système de fichiers en projet d'OpenVZ, ploop, qui consisterait à utiliser comme KVM un genre de disque virtuel plutôt que directement l'arborescence de fichiers, mais ça pose d'autres soucis (notamment que c'est quand même super pratique pour les backups et les manip' cette arborescence ^^) +Plus précisément pour le tuto de NedProduction, il utilise DRBD uniquement dans un sens, c'est à dire plus à vue de backup. Son deuxième disque ne peut en aucun cas servir à faire redémarrer une machine en étant monté sur le système de secours. Dans un système HA, il faut que les deux côtés du disque puissent être utilisées en écriture par le système (mode "primary" dans DRBD), et donc il s'agit de faire très attention à ce que le PRA n'écrivent rien dessus tant que le serveur principal est encore là (sinon, fort risque de conflit, écriture sur les même secteurs disques, etc, et là, tout plante). NedProduction n'a pas cette problématique et donc ses machines OpenVZ se synchronisent tranquillement sur son deuxième serveur uniquement en lecture, fichier par fichier. Ceci dit, peut être que quelque chose m'a échappé, mais j'ai testé sa configuration, dans une problématique de HA ce n'est pas viable (l'option de synchronisation "C" de DRBD interdit que les deux côté du disque puissent être en écriture) +Pour ce qui est du 3eme article, je suis toujours sur le brouillon, mais ces derniers mois ont été chargés niveau boulot, je n'ai pas eu tout le temps que j'aurai voulu pour me remettre sur les configurations et les tests du tuto... Cependant je ne l'oublie pas ! + +Voila, j'espère que le problème est un peu plus clair après cette (longue :s) explication. Et merci pour votre lecture :) + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/19.md b/content/comments/cluster-proxmox-distant-1.4-concept/19.md new file mode 100644 index 0000000..2bfcb61 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/19.md @@ -0,0 +1,11 @@ +email: bentien@live.fr +date: 2013-04-19T11:06+01:00 +author: Ozzi +website: +replyto: 17md + +Bonjour ! +Oui le problème est beaucoup plus clair maintenant, merci pour l'explication :) +C'est très embêtant pour moi car nous n'avons que des container OpenVZ et qu'on me demande de mettre en place de la HA... Mais on trouvera une solution ! + +Bonne continuation pour vos tutos en tout cas ;) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/2.md b/content/comments/cluster-proxmox-distant-1.4-concept/2.md new file mode 100644 index 0000000..c6c935a --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/2.md @@ -0,0 +1,22 @@ +email: lecorvaisier.jerome@gmail.com +date: 2013-01-23T11:05+01:00 +author: Jérôme +website: + +Bonjour, + +Alors, on commence quand ? :) + +Je suis actuellement en train de réfléchir à mettre en place une solution basé sur Proxmox HA/DRBD mais non pas entre différents hébergeurs sur une ligne à forte latence mais en LAN. + +Je risque d'avoir au moins autant de problèmes que vous étant donné que je n'ai encore aucunes solutions pour tromper le fencing et que le projet partait avec 2 noeuds dans le cluster et non 3. + + +Je vous remercie pour les détails que vous avez apporté notamment sur les notions de quorum et de fencing pas très simple à comprendre à la première approche. + +En ce qui me concerne, la solution me servira à mettre des serveurs M$ SQL donc des machines KVM synchronisés via DRBD mais comme le fait remarquer tranxene50 et à juste titre, il risque d'y avoir quelques / nombreuses incohérences dans les données.... Vous faites d'ailleurs remarqué que vous n'avez pas eu de soucis lors de vos tests, faisiez vous des nombreuses requêtes sur le serveur SQL avant de le copier et de couper subitement le serveur principal ? + +Ceci étant dit, j'attend la suite avec impatience, la pub commence à se faire longue :) + +Bonne journée à vous +Bien cordialement diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/20.md b/content/comments/cluster-proxmox-distant-1.4-concept/20.md new file mode 100644 index 0000000..be4d575 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/20.md @@ -0,0 +1,8 @@ +email: bentien@live.fr +date: 2013-04-26T12:00+01:00 +author: Ozzi +website: + +Bonjour, +Je continue mes tests pour avoir de la HA pour mes containers OpenVZ. J'utilise ipmi pour le fencing, et lorsque j'utilise fence_node j'ai toujours success comme résultat. Si je stoppe un host avec le bouton power, la migration de machine se fait automatiquement et correctement. Cependant, si je débranche le cable réseau ou le cable d'alim, le fencing échoue en boucle, comme pour Gégé. C'est pourquoi je reviens vers vous, avez vous résolu son problème ? Pensez-vous qu'il est possible d'avoir du fencing correct en utilisant seulement ipmi ? +Merci d'avance pour vos réponses diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/21.md b/content/comments/cluster-proxmox-distant-1.4-concept/21.md new file mode 100644 index 0000000..08ce6d3 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/21.md @@ -0,0 +1,15 @@ +email: courriel@victor-hery.com +date: 2013-04-30T11:46+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 20md + +Hello, + +Je pense que le souci vient de là effectivement. En ipmi, dès que la machine est coupée du monte (pb réseau ou courant coupé), elle ne peut être joignable, et du coup les serveurs de secours doivent échouer en boucle à lancer le fencing. +Du coup, ils ne prennent pas la responsabilité de lancer les machines en HA. +A mon avis, en utilisant uniquement ipmi, le fencing ne sera pas 100% fonctionnel pour cette raison. Il faudrait peut être rajouter une deuxième option de fencing (qui sera lancée automatiquement si ipmi échoue) et qui appelle un script qui renvoi toujours le status 0 (c'est à dire fencing réussi). C'est malheureusement la seule solution que j'ai pu trouver pour ma part en l'absence de matériel dédié au fencing, même si elle n'est pas très propre. Tant qu'à faire d'ailleurs, mieux vaut inclure dans ce script un envoi de courriel automatique, comme ça tu seras prévenu rapidement s'il se trouve qu'il est appelé :) + +Bon courage + +Victor diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/22.md b/content/comments/cluster-proxmox-distant-1.4-concept/22.md new file mode 100644 index 0000000..ee28d91 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/22.md @@ -0,0 +1,14 @@ +email: +date: 2013-05-22T17:14+01:00 +author: Arnaud +website: + +Bonjour, + +Merci beaucoup pour ton article t ;) + +Cependant j'ai quelque question . +Pourquoi à ton besoin de LVM ? pour les snapshot ? +Et pour NFS, il y a un intérêt ou pas ? + +Merci pour vos futurs réponses. diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/23.md b/content/comments/cluster-proxmox-distant-1.4-concept/23.md new file mode 100644 index 0000000..1db890c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/23.md @@ -0,0 +1,14 @@ +email: briensc@hotmail.com +date: 2013-06-03T01:09+01:00 +author: Damien +website: + +Bonjour! + +Merci pour le tuto qui est très bien rédigé! +je suis entrain de construire un projet de test via: vmware workstation. j'aurais voulu tester la HA de proxmox. le seul problème c'est comment fencer une vm via vmware? ou alors tromper le fencing, pour lui faire croire que c'est bon. + +j'ai pour l'instant 3 node proxmox + 2 drbd avec server nfs en cluster(en actif/passif), qui tourne sur workstation 9. + +si vous avez une petite idée? +merci! diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/24.md b/content/comments/cluster-proxmox-distant-1.4-concept/24.md new file mode 100644 index 0000000..da9f622 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/24.md @@ -0,0 +1,19 @@ +email: courriel@victor-hery.com +date: 2013-06-17T12:00+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 22md + +Hello, + +Désolé pour la latence dans la réponse :s + +LVM être très intéressant pour utiliser DRBD derrière. +D'abord parce qu'il va permettre de redimensionner et de libérer facilement de la place pour le disque DRBD (et de laisser de la souplesse si plus tard tu as besoin de changer ces espaces disques). +Ensuite parce que DRBD aime bien LVM en ce sens qu'il peut utiliser les snapshot pour faire des "points de cohérence". C'est à dire que lors de la synchronisation des disques DRBD entre-eux, il utilise l'espace libre LVM pour optimiser la synchronisation afin que les données soient toujours au maximum cohérentes :) + +Pour NFS, je ne sais pas trop si LVM apporte un réel intérêt, à part encore la possibilité d'être souple sur le dimensionnement des partitions et des disques (Enfin ça, c'est l'avantage inhérent à LVM :) ) + +J'espère avoir répondu à ta question. + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/25.md b/content/comments/cluster-proxmox-distant-1.4-concept/25.md new file mode 100644 index 0000000..f5f4e21 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/25.md @@ -0,0 +1,25 @@ +email: courriel@victor-hery.com +date: 2013-06-17T12:08+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 23md + +Hello Damien, + +Désolé, je ne connais pas du tout vmware. + +A l'instinct, je te dirais de chercher si via ton hyperviseur vmware tu peux envoyer des signaux de simulation type "extinction physique de la machine virtuelle" pour faire croire à proxmox que c'est bon la node est bien éteinte. + +Une façon universelle de le tromper sinon, ça peut être de permettre aux nodes de se connecter sur ton vmware en ssh/telnet/ipmi, et de faire sur le vmware un script appelé par le fencing qui couperait la node demandée : + - La node 1 est en défaut + - La node 2 demande le fencing, elle contacte l'hyperviseur en lui demandant de couper la node 1 + - L'hyperviseur effectue un shutdown de la node 1 + - L'hyperviseur répond par le biais sur script qu'il a correctement coupé la node 1 (code de retour 0) +Ca devrait suffire à faire croire au HA que le fencing a fonctionné. +Pour la réalisation technique par contre, ça dépendra beaucoup de comment une node peut comuniquer avec l'hyperviseur, je n'en sais pas plus :s + +Ca reste du bidouillage, en production je te conseille quand même du proxmox sur des machines physiques :) + +Bon courage. + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/26.md b/content/comments/cluster-proxmox-distant-1.4-concept/26.md new file mode 100644 index 0000000..6b17395 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/26.md @@ -0,0 +1,19 @@ +email: mcmyst@hotmail.fr +date: 2013-10-11T09:29+01:00 +author: matthieu +website: + +Bonjour, + +Merci pour cet article intéressant. + +J'ai une interrogation que j'aimerai confirmer auprès de vous: +Le fencing est utile uniquement dans le cas où, le serveur hôte ne répond plus sur son interface de management (système figé), mais que les VM continu de fonctionner. Dans ce cas, pour éviter d'avoir deux hyperviseurs qui accède au stockage partagé le fencing rentre en action pour tuer l'hôte planté. + +Mais sérieusement, dans combien de cas cette situation arrive ? + +Corrigez moi si je dis une bêtise, mais de mon point de vue, dans 90% des cas, le mécanisme quorum doit suffire. Je m'explique, notre hôte principale se trouve isolé du réseau suite à une panne d'un switch. +Dans ce cas, le fencing de l'autre neoud ne peut rien y faire et tourne en boucle, mais le serveur va automatiquement détecter qu'il a perdu le quorum et stopper automatiquement les ressources HA. +J'aimerai bien avoir un retour sur combien de personne se sont trouvé dans des situations ou le fencing a été plus utile que le quorum. + +Merci diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/27.md b/content/comments/cluster-proxmox-distant-1.4-concept/27.md new file mode 100644 index 0000000..95aecbb --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/27.md @@ -0,0 +1,20 @@ +email: courriel@victor-hery.com +date: 2013-10-16T22:46+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 26md + +Bonjour Matthieu, + +Je suis tout à fait d'accord, le fencing est plutôt rarement utile, et souvent même une source d'ennui. + +Cependant, les 10% de cas où il s'avère utile (hyperviseur planté mais VM continuant de tourner), il est absolument nécessaire car 2 machines qui écrivent au même instant sur un disque, c'est le plantage définitif assuré, avec peu d'espoir de réparer. +Du coup, restauration de sauvegardes, remise en route, tout ça tout ça. A condition d'avoir bien géré ces parties bien sûr :) + +Du coup, même si le fencing est parfois compliqué à gérer (notamment sur des clusters distant), il est absolument nécessaire. Au début, je pensais aussi que c'était vraiment une perte de temps pour pas grand chose, j'ai mis un peu d'eau dans mon vin depuis après avoir rencontré quelque cas d'écritures concurrentes comme dis au dessus. + +Il est parfois préférable que le cluster décide de ne pas remettre en route les machines s'il ne peut pas être sûr qu'elles sont effectivement coupées, et envoie un message à l'administrateur pour le prévenir de son indécision, plutôt qu'il prenne une décision catastrophique au niveau des machines. + +En nombre de cas, le fencing est sans doute "peu" utile. Par contre comparativement à la difficulté de régler un cas où il n'a pas fonctionné, je pense que ça vaut le coup de s'y pencher quand même. + +Voila pour mon avis, j'espère qu'il aura été constructif :) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/28.md b/content/comments/cluster-proxmox-distant-1.4-concept/28.md new file mode 100644 index 0000000..dc9db0f --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/28.md @@ -0,0 +1,6 @@ +email: fetra.randriamiranto@wamada.com +date: 2014-04-01T10:07+01:00 +author: belou +website: http://malagasy-admin.com + +euh, un an après, tu n'arrive plus à ecrirer l suite, je hate de voire le technique pour tromper fence device diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/29.md b/content/comments/cluster-proxmox-distant-1.4-concept/29.md new file mode 100644 index 0000000..0ec54d9 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/29.md @@ -0,0 +1,8 @@ +email: +date: 2015-02-16T14:31+01:00 +author: Pier +website: http://cavepopo.hd.free.fr + +Bonjour, + +Merci pour cet article (je ne l'ai pas encore terminé), j'ai une suggestion pour la traduction de fencing (ca me permet également de vérifier que j'ai bien compris le concept), on pourrait traduire fencing par "cloisonnement" , non ? diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/3.md b/content/comments/cluster-proxmox-distant-1.4-concept/3.md new file mode 100644 index 0000000..515fa4c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/3.md @@ -0,0 +1,21 @@ +email: courriel@victor-hery.com +date: 2013-01-23T11:39+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 2md + +Hello, + +En fait, j'ai des brouillons en cours, mais je prend pas mal de temps à retester chaque chose que j'écris et à essayer que ça ne soit pas trop abstrait, donc ça me prend un peu de temps. (Et de motivation) +Ceci dit, vu qu'effectivement ça a l'air d'intéresser, ça va me pousser un peu en avant (ça fait jamais de mal ^^) + +J'espère pouvoir sortir la série d'ici la fin février, mais ça dépends de mon temps libre donc c'est toujours sujet à caution... + +Pour ce qui est du reste, mes tests se sont fait en Mysql sur une BDD de quelques Go. Ce n'est pas une base SQL en frontend pour un site de plusieurs milliers d'utilisateur, donc elle n'est pas intensément utilisée, mais ceci dit j'ai effectivement fait des tests en coupant les machines et en les redémarrant, ça ne m'a pas posé de problème. + +Ceci dit le problème est plus conceptuel. En pratique, vu que la HA prend le secours d'une machine en panne, la machine principale s'est en général fait couper "mochement", et donc s'il y avait du SQL en cache, il est perdu. La machine en HA redémarre complètement (ce n'est pas une live migration ou un resume), donc la base SQL lance ses patch correctifs s'il y a lieu. En tout cas, c'est ce que j'ai constaté avec Mysql, je ne connais pas assez SQL server. + +Si vous êtes en LAN, je ne saurais trop vous conseiller de trouver un moyen de faire du fencing matériel. Si vous avez la main sur le matériel, un onduleur manageable est très envisageable. Ceci dit, j'ai eu à faire face à ces contraintes donc je ne vous jetterai pas la pierre :) +Par contre, 3 noeuds restent conseillés pour bien gérer le HA. Ceci dit, le wiki proxmox a été mis à jour assez récemment pour supporter un disque de quorum (en fait, juste un petit disque ISCSI servant d'arbitre), c'est un concept qui peut être intéressant dans votre cas en LAN (Sur Internet, OpenVPN est nécessaire) : Quorum disk Proxmox + +A plush' diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/30.md b/content/comments/cluster-proxmox-distant-1.4-concept/30.md new file mode 100644 index 0000000..d77e4e6 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/30.md @@ -0,0 +1,15 @@ +email: courriel@victor-hery.com +date: 2015-02-18T12:56+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 29md + +Bonjour Pier, + +Question intéressante pour la traduction, je ne suis pas fan de "cloisonnement" dans le sens ou tu ne cloisonne pas vraiment le serveur (tu ne l'empêche pas vraiment de fonctionner), mais plutot tu t'assures qu'il soit vraiment coupé. + +Ca peut être effectivement en coupant son réseau (donc en le cloisonnant), mais aussi en lui coupant l'alimentation, en lui disant "sors du cluster", etc + +A ce titre il faut avouer que c'est un mot qui prête un peu à confusion. + +(mais il est vrai que la traduction littérale de fence en français correct serait clôture) diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/31.md b/content/comments/cluster-proxmox-distant-1.4-concept/31.md new file mode 100644 index 0000000..1f99cb0 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/31.md @@ -0,0 +1,10 @@ +email: +date: 2016-07-02T12:30+01:00 +author: Simon +website: http://reseauxeasyandfree.simonlena.com/ + +Article vraiment génial !! J'éspère que cela donnera envie a certain de passer a proxmox ! + +Le petit vocablaire en début d'article est assez utile, de plus nous n'avons p-e pas tous les mêmes conception de certains termes. + +A + diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/4.md b/content/comments/cluster-proxmox-distant-1.4-concept/4.md new file mode 100644 index 0000000..5d92cea --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/4.md @@ -0,0 +1,15 @@ +email: +date: 2013-02-01T14:06+01:00 +author: Gégé +website: + +Bonjour, + +j'ai trouvé votre article très intéressant et assez précis pour répondre à pas mal de questions sur le cluster HA de Proxmox. +Je suis moi-même en train de monter un cluster à trois noeuds avec HA et je retrouve dans votre article quelques réponses à mon questionnement. +J'en ai pourtant encore quelques unes (des questions) qui n'ont pas encore trouvé de réponse. +exemple: dans un cluster ha proxmox quelle doit être l'attitude des noeuds valides lorsqu'un troisième noeuds à perdu le contact (perte alimentation par exemple) . Dan mon cas lors de la perte totale d'un noeud il ne se passe rien jusqu'au retour du noeud arrêté . Les VM configurées avec HA et présentes sur ce noeud migrent à ce moment là. Je ne pense pas que ce soit un fonctionnement normal. +J' ajoute que mes test de fencing (notamment avec l'outil fence_node ou en debranchant le reseau d'un des noeuds) ont donnés des résultats satisfaisant. +si vous avez un petit moment de libre à consacrer a ce problème, je vous en serais très reconnaissant . +merci d'avance +cordialement diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/5.md b/content/comments/cluster-proxmox-distant-1.4-concept/5.md new file mode 100644 index 0000000..923bfc6 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/5.md @@ -0,0 +1,25 @@ +email: courriel@victor-hery.com +date: 2013-02-02T09:16+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 4md + +Bonjour Gégé, +Effectivement, ce n'est pas un comportement normal. Normalement, dès que le 3eme serveur disparait, toutes les machines en HA devraient migrer quasi-instantanément vers les serveurs de secours. +Pour trouver ce qui cloche, il faudrait regarder ce qui se passe dans les logs. Normalement, le syslog (/var/log/syslog) donne pas mal d'informations sur le fonctionnement du cluster. Dès qu'un serveur disparait, ça apparait dans les logs sous la forme d'une dizaine de lignes expliquant la nouvelle configuration (qui est parti, qui est resté, état du quorum, etc). De plus, un des serveur restant est élu aléatoirement pour s'occuper du fencing. Le résultat du fencing est également écrit dans les logs. +Il faut savoir que le cluster est freezé tant que le fencing n'est pas réussit, c'est à dire qu'aucune machine en HA ne migrera si le fencing échoue. Dans le fonctionnement, le serveur élu pour effectuer le fencing va essayer toutes les méthodes qui ont été définies dans le cluster.conf pour la machine en panne. Si elles échouent toutes, il va les réessayer, et ainsi de suite jusqu'à ce qu'une des méthodes réussissent. +Il est possible que lorsque tu déconnectes ton 3eme serveur, le système qui te sert de fencing se déconnecte aussi ? Auquel cas, il est possible que le fencing n'arrive jamais à se faire et du coup les machines en HA ne migrent pas. Et dès que le serveur revient, le fencing aussi, donc il réussit et les machines migrent. +Il y a également une sécurité lorsque leHA est activé, qui fait qu'une machine qui est sorti du quorum et qui revient va automatiquement être exclue des décisions tant qu'elle n'aura pas été redémarré proprement. (En fait, le cluster "tue" le gestionnaire clvm du serveur fautif, cela apparait dans les log sous la forme "clvm killed by node X") +Il est aussi possible de définir des priorité, des temps de migration, etc pour chaque machine dans le cluster.conf, peut être as-tu un problème à ce niveau là ? +Pour en savoir plus, tu peux essayer de regarder l'état du cluster lorsqu'un de tes serveurs est tombé, à l'aide des commandes suivantes : + +- pve n : va te montrer l'état des nodes (Online, offline, est ce que rgmanager tourne) +- pve s : va te montrer l'état du cluster (notamment est ce qu'il a la quorum ou non) +- clustat : va te donner des informations plus précises sur le HA, notamment l'état des VM déclarées en HA, et le dernier serveur où elles ont été vues + +Voila, c'est tout ce que je peux dire avec ces éléments. +Bon courage ! + +A plush' + +Victor diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/6.md b/content/comments/cluster-proxmox-distant-1.4-concept/6.md new file mode 100644 index 0000000..f89b51c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/6.md @@ -0,0 +1,19 @@ +email: +date: 2013-02-04T11:48+01:00 +author: Gégé +website: +replyto: 4md + +Bonjour et merci pour ta réponse. + +j'ai réitéré la manip . +le pvecm n me met bien le node arrété en status X +le pvecm s prend bien en compte que 2 nodes avec un quorum de 2 +le clustat m'indique bien que le node arrété est "Offline" le rgmanager est bien arrété le service qui concerne la VM (pvevm:100) me donne le dernier possesseur mais son état est "started" + +en ce qui concerne le syslog il y a une erreur dans le fencing du node arrété ( peut-être que mon fencing n'est pas tout a fait OK, ou peut être est ce normal). +je me permet de t'envoyer le partie du syslog intéressante . J'espère ne pas trop abuser de ton temps . +En tous cas merci pour tout. +A bientôt + +Gégé diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/7.md b/content/comments/cluster-proxmox-distant-1.4-concept/7.md new file mode 100644 index 0000000..26bb05f --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/7.md @@ -0,0 +1,39 @@ +email: +date: 2013-02-04T13:25+01:00 +author: Gégé +website: +replyto: 4md + +Oups! +ça ira mieux si j'envoie le fichier. + + machine-proxmox2 corosync[2327]: [TOTEM ] A processor joined or left the membership and a new membership was formed. + machine-proxmox2 rgmanager[2541]: State change: machine-proxmox1 DOWN + machine-proxmox2 kernel: dlm: closing connection to node 2 + machine-proxmox2 corosync[2327]: [CPG ] chosen downlist: sender r(0) ip(10.XX.XX.169) ; members(old:3 left:1) + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: members: 1/2216, 3/1989 + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: starting data syncronisation + machine-proxmox2 corosync[2327]: [MAIN ] Completed service synchronization, ready to provide service. + machine-proxmox2 fenced[2390]: fencing node machine-proxmox1 + machine-proxmox2 pmxcfs[2216]: [status] notice: cpg_send_message retried 1 times + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: members: 1/2216, 3/1989 + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: starting data syncronisation + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received sync request (epoch 1/2216/00000004) + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received sync request (epoch 1/2216/00000004) + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received all states + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: leader is 1/2216 + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: synced members: 1/2216, 3/1989 + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: start sending inode updates + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: sent all (0) updates + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: all data is up to date + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: received all states + machine-proxmox2 pmxcfs[2216]: [dcdb] notice: all data is up to date + machine-proxmox2 fenced[2390]: fence machine-proxmox1 dev 0.0 agent fence_ilo3 result: error from agent + machine-proxmox2 fenced[2390]: fence machine-proxmox1 failed + machine-proxmox2 fenced[2390]: fencing node machine-proxmox1 + machine-proxmox2 fenced[2390]: fence machine-proxmox1 dev 0.0 agent fence_ilo3 result: error from agent + machine-proxmox2 fenced[2390]: fence machine-proxmox1 failed + machine-proxmox2 fenced[2390]: fencing node machine-proxmox1 + +encore merci +GG diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/8.md b/content/comments/cluster-proxmox-distant-1.4-concept/8.md new file mode 100644 index 0000000..4635537 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/8.md @@ -0,0 +1,25 @@ +email: courriel@victor-hery.com +date: 2013-02-04T13:43+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 4md + +Hello, + +Si tu veux, je t'invite à mettre ton adresse courriel dans tes commentaires, elle ne sera visible que par moi, et ça sera plus pratique pour discuter :) +(En attendant que je répare mon formulaire de contact ^^") + +Pour ce qui est des logs, il semble bien que c'est le fencing qui pose problème. +la machine-proxmox1 (qui est node 2 si je lis bien) disparait, et donc machine-proxmox2 essaye le fencing. +On voit bien qu'il échoue en boucle, dans ce cas là, aucun service HA ne se lancera. En effet, le cluster considère qu'il ne peut pas être sûr que la node est vraiment "morte", et donc que peut être les VM tournent encore dessus. Pour éviter des corruptions sur le disque de données synchronisé (DRBD, NFS, SAN, ...), le cluster ne peut pas relancer les VM en HA tant qu'il n'est pas sûr que l'hôte est down. + +Après, si ton fencing marche quand tu débranches des câbles, et pas en cas de coupure de courant, il faudrait peut être brancher ta carte ILO sur une alimentation séparée ? Voir avec un onduleur séparé ? +Est ce que en lançant un fencing à la main avec le fence_agent ça fonctionne bien ? Même si le courant est coupé ? + +En tout cas, ton problème semble venir de là :) + +Bon courage + +A plush' + +Victor diff --git a/content/comments/cluster-proxmox-distant-1.4-concept/9.md b/content/comments/cluster-proxmox-distant-1.4-concept/9.md new file mode 100644 index 0000000..a29ce99 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-1.4-concept/9.md @@ -0,0 +1,18 @@ +email: gerard.ormieres@free.fr +date: 2013-02-04T14:49+01:00 +author: Gégé +website: +replyto: 4md + +Hello aussi, + +j'ai desalimenté un node ,puis j'ai tenté le fencing de ce node en essayant: + fence_node machine-proxmox1 +mais j'ai un retour failed +quand je l'execute machine allumée c'est OK. + +Ah Dur! Dur! le fencing +je sens que j'y suis presque mais il me manque toujours un petit truc pour valider un HA digne de ce nom +en tout cas merci pour ton aide + +Gégé diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/0.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/0.md new file mode 100644 index 0000000..455e54b --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/0.md @@ -0,0 +1,6 @@ +email: ebourg@apache.org +date: 2013-02-15T23:40+01:00 +author: Manu +website: + +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. diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/1.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/1.md new file mode 100644 index 0000000..49439f1 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/1.md @@ -0,0 +1,19 @@ +email: courriel@victor-hery.com +date: 2013-02-14T14:51+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 0md + +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' diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/10.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/10.md new file mode 100644 index 0000000..4b4b780 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/10.md @@ -0,0 +1,6 @@ +email: prigent.yohann@gmail.com +date: 2013-06-23T21:35+01:00 +author: Yohann P +website: + +Hello ! A quand la suite ? j'ai hâte, super bien expliqué ! diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/11.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/11.md new file mode 100644 index 0000000..5de0a2e --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/11.md @@ -0,0 +1,13 @@ +email: fabrice.cardinale@adi-informatique.fr +date: 2013-09-20T11:51+01:00 +author: Fabrice +website: www.adi-informatique.fr + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/12.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/12.md new file mode 100644 index 0000000..7259559 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/12.md @@ -0,0 +1,20 @@ +email: courriel@victor-hery.com +date: 2013-09-20T14:17+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 11md + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/13.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/13.md new file mode 100644 index 0000000..2882574 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/13.md @@ -0,0 +1,7 @@ +email: nicolas@paccaud.com +date: 2013-10-02T18:27+01:00 +author: Nicolas +website: www.np-solutions.fr + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/14.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/14.md new file mode 100644 index 0000000..8c503a7 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/14.md @@ -0,0 +1,10 @@ +email: kriss.free@free.fr +date: 2013-10-04T11:21+01:00 +author: Kriss +website: + +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. diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/15.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/15.md new file mode 100644 index 0000000..0582b09 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/15.md @@ -0,0 +1,16 @@ +email: ibasaw@gmail.com +date: 2014-01-16T17:24+01:00 +author: ibasaw +website: + +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é ? + +++ diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/16.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/16.md new file mode 100644 index 0000000..f766e9b --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/16.md @@ -0,0 +1,15 @@ +email: courriel@victor-hery.com +date: 2014-01-27T23:27+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 15md + +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 :)) diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/17.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/17.md new file mode 100644 index 0000000..7ac7f0f --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/17.md @@ -0,0 +1,8 @@ +email: giraudsa@gmail.com +date: 2014-05-27T19:38+01:00 +author: giraudsa +website: https://www.chronosave.com + +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 ?! +@+ diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/18.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/18.md new file mode 100644 index 0000000..6ee122c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/18.md @@ -0,0 +1,9 @@ +email: courriel@victor-hery.com +date: 2014-07-17T17:44+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 17md + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/19.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/19.md new file mode 100644 index 0000000..94d997d --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/19.md @@ -0,0 +1,8 @@ +email: +date: 2015-03-12T21:58+01:00 +author: Cédric +website: + +Bonjour et un grand merci pour ce tuto vraiment bien expliqué. + +La suite se fait toujours attendre. diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/2.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/2.md new file mode 100644 index 0000000..a7eb0f2 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/2.md @@ -0,0 +1,10 @@ +email: ebourg@apache.org +date: 2013-02-17T01:40+01:00 +author: Manu +website: +replyto: 0md + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/20.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/20.md new file mode 100644 index 0000000..729f918 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/20.md @@ -0,0 +1,48 @@ +email: +date: 2015-10-25T12:52+01:00 +author: NL +website: + +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. + + # cat /etc/modules-load.d/8021q.conf + 8021q + +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). + + # Legacy - TAP1 generic encapsulé dans le bridge vmbr1 + /sbin/ifconfig vmbr1 promisc + /sbin/ifconfig tap1 up promisc + /usr/sbin/brctl addif vmbr1 tap1 + /sbin/ifconfig tap1 0 + + # CONF VLAN (VM) + vconfig add tap1 10 + vconfig add tap1 20 + brctl addbr br10 + brctl addbr br20 + brctl addif br10 tap1.10 + brctl addif br20 tap1.20 + ifconfig tap1.10 promisc + ifconfig tap1.20 promisc + ifconfig tap1.10 up + ifconfig tap1.20 up + ifconfig br10 192.168.10.1 + ifconfig br20 192.168.20.1 + +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 ! diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/3.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/3.md new file mode 100644 index 0000000..e62309e --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/3.md @@ -0,0 +1,8 @@ +email: guillaume.melon@gmail.com +date: 2013-02-21T15:33+01:00 +author: Guillaume +website: + +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. diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/4.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/4.md new file mode 100644 index 0000000..d156b09 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/4.md @@ -0,0 +1,12 @@ +email: courriel@victor-hery.com +date: 2013-02-22T13:56+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 3md + +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' diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/5.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/5.md new file mode 100644 index 0000000..8c65096 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/5.md @@ -0,0 +1,22 @@ +email: guillaume.melon@gmail.com +date: 2013-02-28T16:02+01:00 +author: Guillaume +website: +replyto: 3md + +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 diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/6.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/6.md new file mode 100644 index 0000000..1bba13c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/6.md @@ -0,0 +1,7 @@ +email: guillaume.melon@gmail.com +date: 2013-02-28T16:16+01:00 +author: Guillaume +website: +replyto: 3md + +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 ! diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/7.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/7.md new file mode 100644 index 0000000..f92500c --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/7.md @@ -0,0 +1,9 @@ +email: jufoyer@laposte.net +date: 2013-06-12T12:11+01:00 +author: FOYER Julien +website: + +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. diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/8.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/8.md new file mode 100644 index 0000000..c7eeace --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/8.md @@ -0,0 +1,20 @@ +email: courriel@victor-hery.com +date: 2013-06-17T12:13+01:00 +author: Victor +website: http://blog.xn--hry-bma.com/ +replyto: 7md + +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' ! diff --git a/content/comments/cluster-proxmox-distant-2.4-construction-cluster/9.md b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/9.md new file mode 100644 index 0000000..95a8ba7 --- /dev/null +++ b/content/comments/cluster-proxmox-distant-2.4-construction-cluster/9.md @@ -0,0 +1,12 @@ +email: rochdi@fogits.com +date: 2013-06-17T16:47+01:00 +author: ROchdi +website: + +Bonjour, + +Super ton tuto :) + +Est ce que on va voir très prochainement la publication des parties restantes ? + +Rochdi diff --git a/content/comments/construisez-tunnel-ssh/0.md b/content/comments/construisez-tunnel-ssh/0.md new file mode 100644 index 0000000..f9004ff --- /dev/null +++ b/content/comments/construisez-tunnel-ssh/0.md @@ -0,0 +1,6 @@ +email: alban.ermope@hotmail.fr +date: 2015-10-26T12:23+01:00 +author: Alban +website: + +Pendant un moment j'ai cru qu'il s'agissait d'un tuto pour s'échapper de prison ^^