28.7. Écriture d'un agent d'alerte pour les clusters
Il existe trois types d'alertes de grappes Pacemaker : les alertes de nœuds, les alertes de clôtures et les alertes de ressources. Les variables d'environnement transmises aux agents d'alerte peuvent varier en fonction du type d'alerte. Le tableau suivant décrit les variables d'environnement transmises aux agents d'alerte et précise quand la variable d'environnement est associée à un type d'alerte spécifique.
| Variable d'environnement | Description |
|---|---|
|
| Le type d'alerte (nœud, clôture ou ressource) |
|
| La version de Pacemaker qui envoie l'alerte |
|
| Le destinataire configuré |
|
| Un numéro de séquence augmente chaque fois qu'une alerte est émise sur le nœud local, ce qui peut être utilisé pour référencer l'ordre dans lequel les alertes ont été émises par Pacemaker. Une alerte pour un événement qui s'est produit plus tard dans le temps a, de manière fiable, un numéro de séquence plus élevé que les alertes pour des événements antérieurs. Sachez que ce numéro n'a aucune signification à l'échelle de la grappe. |
|
|
Un horodatage créé avant l'exécution de l'agent, dans le format spécifié par la méta-option |
|
| Nom du nœud affecté |
|
|
Détail de l'événement. Pour les alertes de nœuds, il s'agit de l'état actuel du nœud (membre ou perdu). Pour les alertes de clôture, il s'agit d'un résumé de l'opération de clôture demandée, y compris l'origine, la cible et le code d'erreur de l'opération de clôture, le cas échéant. Pour les alertes relatives aux ressources, il s'agit d'une chaîne lisible équivalente à |
|
| ID du nœud dont l'état a changé (fourni avec les alertes de nœuds uniquement) |
|
| L'opération de clôture ou de ressource demandée (fournie uniquement avec les alertes de clôture et de ressource) |
|
| Le code de retour numérique de l'opération de clôture ou de ressource (fourni uniquement avec les alertes de clôture et de ressource) |
|
| Le nom de la ressource affectée (alertes sur les ressources uniquement) |
|
| Intervalle de l'opération sur la ressource (alertes sur les ressources uniquement) |
|
| Code de retour numérique attendu de l'opération (alertes sur les ressources uniquement) |
|
| Code numérique utilisé par Pacemaker pour représenter le résultat de l'opération (alertes sur les ressources uniquement) |
Lors de la rédaction d'un agent d'alerte, vous devez tenir compte des éléments suivants.
- Les agents d'alerte peuvent être appelés sans destinataire (si aucun n'est configuré) ; l'agent doit donc être capable de gérer cette situation, même s'il ne fait que sortir dans ce cas. Les utilisateurs peuvent modifier la configuration par étapes et ajouter un destinataire ultérieurement.
- Si plusieurs destinataires sont configurés pour une alerte, l'agent d'alerte sera appelé une fois par destinataire. Si un agent n'est pas en mesure de fonctionner simultanément, il doit être configuré avec un seul destinataire. L'agent est toutefois libre d'interpréter le destinataire comme une liste.
- Lorsqu'un événement se produit dans un cluster, toutes les alertes sont déclenchées en même temps en tant que processus distincts. En fonction du nombre d'alertes et de destinataires configurés et de ce qui est fait au sein des agents d'alerte, il peut se produire une augmentation significative de la charge. L'agent pourrait être écrit de manière à prendre cela en considération, par exemple en mettant en file d'attente les actions gourmandes en ressources dans une autre instance, au lieu de les exécuter directement.
-
Les agents d'alerte sont exécutés sous l'utilisateur
hacluster, qui dispose d'un ensemble minimal d'autorisations. Si un agent a besoin de privilèges supplémentaires, il est recommandé de configurersudopour permettre à l'agent d'exécuter les commandes nécessaires en tant qu'autre utilisateur disposant des privilèges appropriés. -
Prenez soin de valider et d'assainir les paramètres configurés par l'utilisateur, tels que
CRM_alert_timestamp(dont le contenu est spécifié par le paramètretimestamp-formatconfiguré par l'utilisateur),CRM_alert_recipient, et toutes les options d'alerte. Cela est nécessaire pour se prémunir contre les erreurs de configuration. En outre, si un utilisateur peut modifier la CIB sans disposer d'un accès de niveauhaclusteraux nœuds du cluster, il s'agit également d'un problème de sécurité potentiel et vous devez éviter la possibilité d'une injection de code. -
Si un cluster contient des ressources avec des opérations pour lesquelles le paramètre
on-failest défini surfence, il y aura plusieurs notifications de clôture en cas d'échec, une pour chaque ressource pour laquelle ce paramètre est défini plus une notification supplémentaire. Les notifications seront envoyées à la fois parpacemaker-fencedetpacemaker-controld. Dans ce cas, Pacemaker n'effectue qu'une seule opération de clôture, quel que soit le nombre de notifications envoyées.
L'interface des alertes est conçue pour être rétro-compatible avec l'interface des scripts externes utilisée par la ressource ocf:pacemaker:ClusterMon. Pour préserver cette compatibilité, les variables d'environnement transmises aux agents d'alerte sont disponibles avec les préfixes CRM_notify_ et CRM_alert_. Une rupture de compatibilité est due au fait que la ressource ClusterMon exécutait les scripts externes en tant qu'utilisateur root, alors que les agents d'alerte sont exécutés en tant qu'utilisateur hacluster.
