Tolérance de panne sur des partage reseau

[jjbond]

Bonjour,
Je possède un serveur X qui sur lequel est monté deux partage réseau.
Ma problématique est que je voudrais installer une solution de tolérance de panne sur mon serveur en créant une deuxième serveur a l’identique et en installant heartbeat entre les deux.
Jusqu’ici pas de problème j’ai bien l’ip virtuelle entre les deux serveurs.
Mais comment faire pour que les partages switch automatiquement sur le serveur Y quand le serveur X tombe en panne ?
J’ai déjà tenter de paramétrer le partage de façon a dire qu’il utilise l’ip virtuelle comme destination, cela fonctionne mais lorsque je coupe le serveur X le partage ne switchera pas tout seul ( nécessitée de retaper la commande).

Pour l’instant j’utilise SSHFS pour mes partages si il existe d’autres programmes qui pourrait me dépanner je suis preneur.

Cordialement,
JJBOND.

[Clochette]

[quote=“jjbond”]Bonjour,
Je possède un serveur X qui sur lequel est monté deux partage réseau.
Ma problématique est que je voudrais installer une solution de tolérance de panne sur mon serveur en créant une deuxième serveur a l’identique et en installant heartbeat entre les deux.
Jusqu’ici pas de problème j’ai bien l’ip virtuelle entre les deux serveurs.
Mais comment faire pour que les partages switch automatiquement sur le serveur Y quand le serveur X tombe en panne ?
J’ai déjà tenter de paramétrer le partage de façon a dire qu’il utilise l’ip virtuelle comme destination, cela fonctionne mais lorsque je coupe le serveur X le partage ne switchera pas tout seul ( nécessitée de retaper la commande).

Pour l’instant j’utilise SSHFS pour mes partages si il existe d’autres programmes qui pourrait me dépanner je suis preneur.

Cordialement,
JJBOND.[/quote]

Il me semble pourtant que lorsqu’il y a bascule un script est exécuté pour lancé la configuration de heartbeat

/etc/heartbeat/haresources 
Ce fichier indique les opérations à effectuer au démarrage de la haute disponibilité sur une machine. La syntaxe est la suivante :
NOM_1ER_NODE action1 action2 ... actionN

NOM_1ER_NODE
    Ce nom doit être le même pour les 2 machines. C'est le nom de la machine qui sera activée par défaut au démarrage de heartbeat. 
action
    Vous pouvez demander un liste d'actions à effectuer au démarrage de heartbeat. Toutes les actions sont séparées par des espaces. Pour ajouter des paramètres aux actions, utiliser le signe 4-points : "::"
    Voici quelques exemples d'actions possibles :

    Activer une adresse IP virtuelle
        Utilisation : IPaddr::adresse_ip/masque/interface
        node1 IPaddr::192.xxx.xxx.xxx/24/eth0
    Lancer un service
        Utilisation : nom_service
        node1 apache2
        Attention : ce service doit être dans /etc/init.d (ou /etc/heartbeat/ressource.d), et doit reconnaître les arguments 'start' et 'stop'. 
    Monter un système de fichiers local
        Utilisation : Filesystem::periph_source::point_de_montage::type_partition
        node1 Filesystem::/dev/sda1::/data/scsi1::vfat
    Monter un système de fichiers distant (par exemple NFS)
        Utilisation : Filesystem::adresse_ip_source:/dossier_src::point_de_montage::type_partition
        node1 Filesystem::192.x.x.x:/partage_distant::/data/montage_local::nfs
    Monter un système de fichiers distant avec des options de montage
        Utilisation : Filesystem::adresse_ip_source:/dossier_src::point_de_montage::type_partition::options
        node1 Filesystem::192.x.x.x:/src::/dest::nfs::rsize=8192,wsize=8192

De plus rien ne t’empêche de scripter un peu pour tester le montage et le relancer juste au cas où qu’il ne répondent pas correctement.
Tu monitores ton matériel avec quoi ?

Tu peux toujours loger ton heartbeat pour voir un peu ce qu’il se passe avec le montage NFS ou SSHFS en cas de bascule

[syam]

SSHFS a une option [mono]-o reconnect[/mono] justement pour forcer une reconnexion si jamais il s’est déconnecté du serveur. Ça marche très bien par exemple quand on reboot le serveur SSH : quand il est à nouveau disponible, le point de montage se reconnecte et fonctionne à nouveau.

Vu que l’IP / nom d’hôte restent les mêmes quand le serveur failover prend le relais, ça ne devrait poser aucun problème dans ton cas : je pense que c’est assimilable à un reboot (du point de vue du client).

Par contre, la détection de la déconnexion peut prendre du temps avec la config par défaut, mais il suffit d’ajuster [mono]ServerAliveCountMax[/mono] et [mono]ServerAliveInterval[/mono].

Voir [mono]man ssh_config[/mono] et [mono]man sshfs[/mono].

[jjbond]

Bonjour,
Merci a tous pour vos réponses ! je vais tester les deux solutions proposés je vous redis si cela fonctionne correctement
EDIT: Après avoir tester la technique du -o reconnect le partage fonctionne bien pour l’instant tout va bien mais, lorsque j’éteins le serveur pour simuler une panne le partage plante … impossible d’effectuer des commandes dans le dossier de partage " erreur d’entrée / sortie " j’ai donc rebooter le serveur pour remédier a ce problème et la BAM lorsque je tente de remonter le partage celui ci ce fait sans erreur mais impossible d’accéder a mon répertoire partagé celui ci est “vide” alors qu’il a bien quelque-chose de dans coté serveur ^^ …
EDIT2: Le problème du répertoire vide est résolu ! mais j’ai toujours cette erreur d’ " entrée / sortie " la déconnexion du partage est trop violente ?

[jb1]

bonjour,
pour que cela soit parfait,
ne pas oublier de mettre sur le courant secouru,
le ou les hubs, en plus des autres matériels
j’ai vu de mes yeux, vu, ce type de big architecture,

quand une architecture disparait, elle doit vérifier l’absence de la première
avant de lancer sa procédure d’actions
l’architecture devient maitre-bus ou réseau
c’est du boulot,
A+
JB1

[jjbond]

Effectivement mais je vais déjà essayer de faire fonctionner ce montage et ce sera déjà bien …
Edit:

encore plus drôle … voila l’état de mon répertoire de montage après “panne” du serveur.

root@debian:/mnt# ls -l
ls: impossible d'accéder à partage1: Erreur d'entrée/sortie
total 0
d????????? ? ? ? ?              ? partage1
root@debian:/mnt#

Je vais déprimer …

[Clochette]

[quote=“jb1”]bonjour,
pour que cela soit parfait,
ne pas oublier de mettre sur le courant secouru,
le ou les hubs, en plus des autres matériels
j’ai vu de mes yeux, vu, ce type de big architecture,

quand une architecture disparait, elle doit vérifier l’absence de la première
avant de lancer sa procédure d’actions
l’architecture devient maitre-bus ou réseau
c’est du boulot,
A+
JB1
[/quote]

Ce n’est en rien comparable, tu parle de stockage haute disponibilité, là il est question d’un montage sur un plateforme dite haute disponibilité.

Si effectivement le cas était de pouvoir ‘switcher’ le stockage de master à slave et slave à master un l’option drdb serait la plus adéquat.
Mieux encore monté du glusterfs mais attention au perfs disques dans cas là.

[syam]

[quote=“jjbond”]EDIT: Après avoir tester la technique du -o reconnect le partage fonctionne bien pour l’instant tout va bien mais, lorsque j’éteins le serveur pour simuler une panne le partage plante … impossible d’effectuer des commandes dans le dossier de partage " erreur d’entrée / sortie " j’ai donc rebooter le serveur pour remédier a ce problème et la BAM lorsque je tente de remonter le partage celui ci ce fait sans erreur mais impossible d’accéder a mon répertoire partagé celui ci est “vide” alors qu’il a bien quelque-chose de dans coté serveur ^^ …
EDIT2: Le problème du répertoire vide est résolu ! mais j’ai toujours cette erreur d’ " entrée / sortie " la déconnexion du partage est trop violente ?[/quote]
Première réaction : bizarre, quand j’avais testé l’autre jour pour être sûr de pas raconter de conneries ça me faisait pas ça, il se reconnectait bien automatiquement.
Là je teste à nouveau, pareil : aucun problème.

Finalement je me suis aperçu que sur le “serveur” avec lequel j’ai testé (une carte ARM de dév), j’utilisais une clé privée sans mot de passe…
Je teste donc sur une autre machine à laquelle j’accède avec une clé privée protégée par mot de passe : je retombe sur le même problème que toi. Idem si je tente d’accéder avec un mot de passe pour un compte utilisateur.

Conclusion, c’est certainement un problème d’authentification : quand il se déconnecte il ne peut pas se reconnecter sans te demander un mot de passe (soit pour le compte utilisateur, soit pour accéder à la clé privée) et comme SSHFS s’est détaché de la console il ne peut pas, il bloque.

Je n’ai pas essayé avec [mono]ssh-agent[/mono] mais ça me paraît une bonne piste : tu débloques ta clé privée et tu la mets dans l’agent, puis celui-ci est utilisé pour la reconnexion.

[jjbond]

Bonjour,
Effectivement il y a cette notion d’authentification qui bloque … depuis que j’ai mis en place le couple clef privé , clef publique sa marche nettement mieux !
Toutefois j’ai bricolé un petit script qui me permet de faire la connexion d’une manière automatique quand un des serveurs tombe.

#!/bin/bash
if [ -f info.txt ] # on teste l'existence du fichier d'info
        then rm info.txt # si il existe déja on le supprime 
fi
touch info.txt # création du fichier d'info
ifconfig | grep eth0:0 > info.txt # test si le serveur possede l'ip virtuelle
rez=`wc -l info.txt|cut -d ' ' -f1` # on compte le nombre de lignes dans le fichier info
if [ $rez -gt 0 ] # si le nombre de ligne est strictement superieur a 0 
        then # on effectue le partage :)
           sshfs user@IPdistante:/mnt/repertoire distant /mnt/Pointdemontage -o nonempty -o ServerAliveInterval=1
	rm info.txt # suppression du fichier info
fi

En tout cas merci beaucoup pour vos réponses bonne continuation a vous et bonne journée.