----------------------------------------------------------------------------------------------
Environnement matériel :
2 pc identiques :
P4 3ghz 1go Ram
Carte SCSI Adpatec 2120S sur laquelle sont montés les 3 disques durs. 1 disque pour la partition système et 2 disques identiques pour les partitions de données.
Après avoir réussi linstallation dun système à Haute disponibilité (2 serveurs de données dans un cluster pour une réplication de données au travers dun réseau local) nous avons commencé à avoir des problèmes après 4 mois dutilisation quotidienne.
Le premier problème qui est apparu est le passage en lecture seule de la partition « système » sur le serveur secondaire (serveur N°2). Sans que personne nintervienne sur les machines, la partition contentant le système dexploitation a basculé en lecture seule et le DRBD sest mis a fonctionné avec un seul serveur dans la solution de clustering. Suite à ceci nous avons redémarré les 2 serveurs simultanément et après une synchronisation des disques de données, tout était reparti à la normale. Seulement 2 semaines plus tard le même problème sest reproduit. Afin de tenter de comprendre nous avons éteint le serveur n° 2 et laissé tourner le cluster avec 1 seul pc. 10 jours plus tard, alors que le serveur n° 1 était toujours seul dans le cluster, une partition stockant les données sest elle aussi mise à fonctionner en lecture seule. Un redémarrage rapide du serveur a permis aux utilisateurs denregistrer leur travail et à peine quelques heures plus tard le problème est de nouveau apparu. Un nouveau redémarrage (le temps darriver sur le site) permet une nouvelle fois la sauvegarde du travail puis nous arrivons devant la machine où tout semble fonctionner normalement.
Fin de journée nous redémarrons les machines en les déconnectant du réseau, nous lançons la commande « e2fsck » sur les 2 pc, nous les laissons fonctionner un moment, rien danormal ne se produit devant nos yeux.
Après quelques tests décriture, nous voulons remettre les serveurs en route sur le réseau afin de synchroniser les données avant de poursuivre la maintenance. Nous rallumons tout le système, après vérification du statut du DRBD tout semble « ok » mais à notre arrivée le lendemain matin, les données présentes sur le serveur ne sont pas celles de la veille mais celles datant de larrêt du serveur n° 2. La synchronisation s est effectuée dans le mauvais sens !
Après vérification des fichiers de logs on saperçoit quau démarrage des machines le serveur n° 2 a basculé pour une durée de 3 SECONDES (très difficilement visible à lécran, puisquil aurait fallu regarder létat du DRBD pendant ce temps là) en serveur primaire alors que cela ne sest jamais produit pendant 4 mois au cours des quels nous avons parfois stoppé les serveurs.
Quelquun aurait-il une explication dune part sur la mise en lecture seule des partitions et dautre part sur le fait que le serveur secondaire est pu passer en primaire alors que le serveur n° 1 était déjà en ligne et fonctionnait sans problème apparent ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mna
Bonjour,
[...]
Je ne sais pas concernant le basculement en mode RO du système de fichier encore que j'aurais tendance à penser à un problème hard d'écriture sur le disque mais ça devrait se voir dans la syslog système ou kernel par contre
Après quelques tests décriture, nous voulons remettre les serveurs en route sur le réseau afin de synchroniser les données avant de poursuivre la maintenance. Nous rallumons tout le système, après vérification du statut du DRBD tout semble « ok » mais à notre arrivée le lendemain matin, les données présentes sur le serveur ne sont pas celles de la veille mais celles datant de larrêt du serveur n° 2. La synchronisation s est effectuée dans le mauvais sens !
Après vérification des fichiers de logs on saperçoit quau démarrage des machines le serveur n° 2 a basculé pour une durée de 3 SECONDES (très difficilement visible à lécran, puisquil aurait fallu regarder létat du DRBD pendant ce temps là) en serveur primaire alors que cela ne sest jamais produit pendant 4 mois au cours des quels nous avons parfois stoppé les serveurs.
Quelquun aurait-il une explication dune part sur la mise en lecture seule des partitions et dautre part sur le fait que le serveur secondaire est pu passer en primaire alors que le serveur n° 1 était déjà en ligne et fonctionnait sans problème apparent ?
là j'ai déjà rencontré le problème sur un cluster linux.
Le problème pour moi venait des scripts d'initialisation du système dans lesquels il y une commande équivalente à "drdbadmin primary all" qui indique à drbd de se considérer comme primaire et donc de prendre le contenu du disque de la machine sur laquelle la commande a été exécutée (serveur 2 chez toi) comme étant la référence (ou tout au moins le dernier état valide).
le danger apparaît après lorsque les 2 extrémités drbd se reconnectent, car elles ont basculées toutes les 2 en primary. et du coup le système ne sais plus quelles sont les données ! (enfin c'est ce moi j'en ai déduis)
pour éviter ce genre de désagrément j'ai désactivé le flag auto_failback on dans /etc/ha.d/ha.cf
dans cette configuration la bascule du cluster est assurée mais le retour en mode nominal est à gérer à la main, ce qui permet de s'assurer de l'état des disques drbd avant rebasculement et surtout de ré initialiser les disques correctement au besoin.
dans ton cas tu aurais du allumer ta machine 1 machine1# drbdadmin disconnect all machine1# hb_takeover allumer ta machine 2 machine2# demarrer le service drbd (service drbd start ?) machine2# drbdadm secondary all machine2# drbdadmin connect all machine1# drbdadmin connect all machine# drbdadm invalidate -> surveiller la reconstruction du disk (wtach -n 10 "cat /proc/drbd") une fois fini machine2# lancer le heartbeat
peut être d'autres utilisateurs auront trouvé une meilleur parade, mais dans mon cas ça marche plutôt bien. j'ai ajouter un script qui m'alerte lorsque le cluster bascule afin que je puisse gérer le retour arrière.
je sais pas si j'ai été clair dans ma réponse mais n'hésites pas au besoin.
en gros vérifies bien les scripts qui sont lancés au reboot de ta machine et ceux lancés par heatbeat.
Merci par avance de rien
a+ mna.
Bonjour,
[...]
Je ne sais pas concernant le basculement en mode RO du système de fichier
encore que j'aurais tendance à penser à un problème hard d'écriture
sur le disque mais ça devrait se voir dans la syslog système ou kernel
par contre
Après quelques tests décriture, nous voulons remettre les serveurs
en route sur le réseau afin de synchroniser les données avant de
poursuivre la maintenance. Nous rallumons tout le système, après
vérification du statut du DRBD tout semble « ok » mais à notre
arrivée le lendemain matin, les données présentes sur le serveur ne
sont pas celles de la veille mais celles datant de larrêt du serveur
n° 2. La synchronisation s est effectuée dans le mauvais sens !
Après vérification des fichiers de logs on saperçoit quau
démarrage des machines le serveur n° 2 a basculé pour une durée de 3
SECONDES (très difficilement visible à lécran, puisquil aurait
fallu regarder létat du DRBD pendant ce temps là) en serveur
primaire alors que cela ne sest jamais produit pendant 4 mois au cours
des quels nous avons parfois stoppé les serveurs.
Quelquun aurait-il une explication dune part sur la mise en lecture
seule des partitions et dautre part sur le fait que le serveur
secondaire est pu passer en primaire alors que le serveur n° 1 était
déjà en ligne et fonctionnait sans problème apparent ?
là j'ai déjà rencontré le problème sur un cluster linux.
Le problème pour moi venait des scripts d'initialisation du
système dans lesquels il y une commande équivalente à
"drdbadmin primary all"
qui indique à drbd de se considérer comme
primaire et donc de prendre le contenu du disque de la machine sur
laquelle la commande a été exécutée (serveur 2 chez toi) comme étant
la référence (ou tout au moins le dernier état valide).
le danger apparaît après lorsque les 2 extrémités drbd se
reconnectent, car elles ont basculées toutes les 2 en primary.
et du coup le système ne sais plus quelles sont les données !
(enfin c'est ce moi j'en ai déduis)
pour éviter ce genre de désagrément j'ai désactivé le flag
auto_failback on dans /etc/ha.d/ha.cf
dans cette configuration la bascule du cluster est assurée mais le retour
en mode nominal est à gérer à la main, ce qui permet de s'assurer de
l'état des disques drbd avant rebasculement et surtout de ré initialiser
les disques correctement au besoin.
dans ton cas tu aurais du
allumer ta machine 1
machine1# drbdadmin disconnect all
machine1# hb_takeover
allumer ta machine 2
machine2# demarrer le service drbd (service drbd start ?)
machine2# drbdadm secondary all
machine2# drbdadmin connect all
machine1# drbdadmin connect all
machine# drbdadm invalidate
-> surveiller la reconstruction du disk (wtach -n 10 "cat /proc/drbd")
une fois fini
machine2# lancer le heartbeat
peut être d'autres utilisateurs auront trouvé une meilleur parade, mais
dans mon cas ça marche plutôt bien.
j'ai ajouter un script qui m'alerte lorsque le cluster bascule afin que je
puisse gérer le retour arrière.
je sais pas si j'ai été clair dans ma réponse mais n'hésites pas au
besoin.
en gros vérifies bien les scripts qui sont lancés au reboot de ta
machine et ceux lancés par heatbeat.
Je ne sais pas concernant le basculement en mode RO du système de fichier encore que j'aurais tendance à penser à un problème hard d'écriture sur le disque mais ça devrait se voir dans la syslog système ou kernel par contre
Après quelques tests décriture, nous voulons remettre les serveurs en route sur le réseau afin de synchroniser les données avant de poursuivre la maintenance. Nous rallumons tout le système, après vérification du statut du DRBD tout semble « ok » mais à notre arrivée le lendemain matin, les données présentes sur le serveur ne sont pas celles de la veille mais celles datant de larrêt du serveur n° 2. La synchronisation s est effectuée dans le mauvais sens !
Après vérification des fichiers de logs on saperçoit quau démarrage des machines le serveur n° 2 a basculé pour une durée de 3 SECONDES (très difficilement visible à lécran, puisquil aurait fallu regarder létat du DRBD pendant ce temps là) en serveur primaire alors que cela ne sest jamais produit pendant 4 mois au cours des quels nous avons parfois stoppé les serveurs.
Quelquun aurait-il une explication dune part sur la mise en lecture seule des partitions et dautre part sur le fait que le serveur secondaire est pu passer en primaire alors que le serveur n° 1 était déjà en ligne et fonctionnait sans problème apparent ?
là j'ai déjà rencontré le problème sur un cluster linux.
Le problème pour moi venait des scripts d'initialisation du système dans lesquels il y une commande équivalente à "drdbadmin primary all" qui indique à drbd de se considérer comme primaire et donc de prendre le contenu du disque de la machine sur laquelle la commande a été exécutée (serveur 2 chez toi) comme étant la référence (ou tout au moins le dernier état valide).
le danger apparaît après lorsque les 2 extrémités drbd se reconnectent, car elles ont basculées toutes les 2 en primary. et du coup le système ne sais plus quelles sont les données ! (enfin c'est ce moi j'en ai déduis)
pour éviter ce genre de désagrément j'ai désactivé le flag auto_failback on dans /etc/ha.d/ha.cf
dans cette configuration la bascule du cluster est assurée mais le retour en mode nominal est à gérer à la main, ce qui permet de s'assurer de l'état des disques drbd avant rebasculement et surtout de ré initialiser les disques correctement au besoin.
dans ton cas tu aurais du allumer ta machine 1 machine1# drbdadmin disconnect all machine1# hb_takeover allumer ta machine 2 machine2# demarrer le service drbd (service drbd start ?) machine2# drbdadm secondary all machine2# drbdadmin connect all machine1# drbdadmin connect all machine# drbdadm invalidate -> surveiller la reconstruction du disk (wtach -n 10 "cat /proc/drbd") une fois fini machine2# lancer le heartbeat
peut être d'autres utilisateurs auront trouvé une meilleur parade, mais dans mon cas ça marche plutôt bien. j'ai ajouter un script qui m'alerte lorsque le cluster bascule afin que je puisse gérer le retour arrière.
je sais pas si j'ai été clair dans ma réponse mais n'hésites pas au besoin.
en gros vérifies bien les scripts qui sont lancés au reboot de ta machine et ceux lancés par heatbeat.
Merci par avance de rien
a+ mna.
mna
je fais quelques petites précisions et remise en page:
dans ton cas tu aurais du
allumer ta machine 1 machine1# drbdadmin disconnect all machine1# hb_takeover allumer ta machine 2 machine2# demarrer le service drbd (service drbd start ?) machine2# drbdadm secondary all machine2# drbdadmin connect all machine1# drbdadmin connect all machine2# drbdadm invalidate îîîîîîî cette ligne n'est pas indispensable comme tu as au préalable correctement positionné l'état des extrémités drbd en primary et secondary la synchro se fera toute seule en incrémentale
-> dans les 2 cas surveiller la reconstruction du disk (wtach -n 10 "cat /proc/drbd") une fois fini
machine2# lancer le heartbeat
je fais quelques petites précisions et remise en page:
dans ton cas tu aurais du
allumer ta machine 1
machine1# drbdadmin disconnect all
machine1# hb_takeover
allumer ta machine 2
machine2# demarrer le service drbd (service drbd start ?)
machine2# drbdadm secondary all
machine2# drbdadmin connect all
machine1# drbdadmin connect all
machine2# drbdadm invalidate
îîîîîîî
cette ligne n'est pas indispensable
comme tu as au préalable correctement positionné l'état
des extrémités drbd en primary et secondary la synchro
se fera toute seule en incrémentale
-> dans les 2 cas surveiller la reconstruction du disk
(wtach -n 10 "cat /proc/drbd")
une fois fini
je fais quelques petites précisions et remise en page:
dans ton cas tu aurais du
allumer ta machine 1 machine1# drbdadmin disconnect all machine1# hb_takeover allumer ta machine 2 machine2# demarrer le service drbd (service drbd start ?) machine2# drbdadm secondary all machine2# drbdadmin connect all machine1# drbdadmin connect all machine2# drbdadm invalidate îîîîîîî cette ligne n'est pas indispensable comme tu as au préalable correctement positionné l'état des extrémités drbd en primary et secondary la synchro se fera toute seule en incrémentale
-> dans les 2 cas surveiller la reconstruction du disk (wtach -n 10 "cat /proc/drbd") une fois fini
