« LINUX:Pacemaker - Serveurs en Failover » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (3 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 134 : | Ligne 134 : | ||
==Contraintes== | ==Contraintes== | ||
Les contraintes d'ordre de démarrage sont connues; elles ont déjà été rencontrées dans les articles précédents. Il tombe sous le sens que la ressource "drbddata" active doit être effective avant de pouvoir | Les contraintes d'ordre de démarrage sont connues; elles ont déjà été rencontrées dans les articles précédents. Il tombe sous le sens que la ressource "drbddata" active doit être effective avant de pouvoir monter cet espace partagé. | ||
Les deux ressources "ClusterFs" et "ClusterIP" doivent se situer sur la même machine ("INFINITY") que la ressource Drbd (ClusterDrbd") qui est active ("Promoted"), parmi les deux ("clone"), d'où la syntaxe "Promoted ClusterDrbd-clone". | Les deux ressources "ClusterFs" et "ClusterIP" doivent se situer sur la même machine ("INFINITY") que la ressource Drbd (ClusterDrbd") qui est active ("Promoted"), parmi les deux ("clone"), d'où la syntaxe "Promoted ClusterDrbd-clone". | ||
| Ligne 276 : | Ligne 276 : | ||
==Ajouts des ressources | ==Ajouts des ressources== | ||
La création de ces ressources des différents services sont sur le même gabari; on utilise la fonction Systemd du type "systemd:<service>". | La création de ces ressources des différents services sont sur le même gabari; on utilise la fonction Systemd du type "systemd:<service>". | ||
(excepté la ressource classique "ClusterMailTo" déjà vue) | |||
==Localisation des | ==Localisation des ressources== | ||
Tous les services sont placés sur la machine où Drbd est actif et que l'espace partagé "/data" est monté. | Tous les services sont placés sur la machine où Drbd est actif et que l'espace partagé "/data" est monté. | ||
| Ligne 286 : | Ligne 287 : | ||
==Ordre de lancement== | ==Ordre de lancement des ressources== | ||
Nous avons déjà rencontré ce type de commande; chaque service est chargé chacun à la suite de l'autre après la ressource "ClusterIP". | Nous avons déjà rencontré ce type de commande; chaque service est chargé chacun à la suite de l'autre après la ressource "ClusterIP". | ||
=Statut de la seconde partie= | =Statut après l'activation de la seconde partie= | ||
Après cette opération, l'état du cluster peut être visualisé par la commande: | Après cette opération, l'état du cluster peut être visualisé par la commande: | ||
crm_mon -1 | crm_mon -1 | ||
| Ligne 335 : | Ligne 336 : | ||
Du côté de la messagerie, Le serveur est "cluster.home.dom". Par exemple pour l'utilisateur "pdupont", l'adresse mail est "pdupont@failover.dom" et le nom de compte est "pdupont" | Du côté de la messagerie, Le serveur est "cluster.home.dom". Par exemple pour l'utilisateur "pdupont", l'adresse mail est "pdupont@failover.dom" et le nom de compte est "pdupont" accompagné du mot de passe Linux associé. Le reste est classique. | ||