Dans mon environnement, nous gérons plusieurs services fonctionnant sur des dispositifs drbd (traditionnels, conteneurs lxc, conteneurs docker, bases de données, ...). Nous utilisons le stack opensvc (https://www.opensvc.com) qui est gratuit et open source, et fournit des fonctionnalités de basculement automatique. Ci-dessous se trouve un service test avec drbd, et une application redis (désactivée dans l'exemple)
Tout d'abord au niveau du cluster, nous pouvons voir dans la sortie svcmon que :
- Cluster opensvc de 2 nœuds (node-1-1 et node-1-2)
- le service servdrbd est actif (O majuscule vert) sur node-1-1, et en attente (o minuscule vert) sur node-1-2
- node-1-1 est le nœud maître préféré pour ce service (accent circonflexe proche de O majuscule)
Au niveau du service svcmgr -s servdrbd print status, nous pouvons voir :
- sur le nœud primaire (à gauche) : nous pouvons voir que toutes les ressources sont actives (ou en attente active ; signifiant qu'elles doivent rester actives lorsque le service s'exécute sur l'autre nœud). Et en ce qui concerne le dispositif drbd, il est indiqué comme Primaire
- sur le nœud secondaire (à droite) : nous pouvons voir que seules les ressources en attente sont actives, et le dispositif drbd est dans l'état Secondaire.
Pour simuler un problème, j'ai déconnecté le dispositif drbd sur le nœud secondaire, ce qui produit les avertissements suivants
Il est important de noter que le statut de disponibilité du service est toujours actif, mais le statut global du service est dégradé en avertissement, signifiant "ok, la production fonctionne toujours bien, mais quelque chose ne va pas, jetez un coup d'œil"
Dès que vous savez que toutes les commandes opensvc peuvent être utilisées avec le sélecteur de sortie json (nodemgr daemon status --format json ou svcmgr -s servdrbd print status --format json), il est facile de les intégrer dans un script NRPE, et simplement surveiller les états des services. Et comme vous l'avez vu, tout problème sur le primaire ou le secondaire est détecté.
Le nodemgr daemon status est préférable car c'est la même sortie sur tous les nœuds du cluster, et toutes les informations des services opensvc sont affichées en une seule commande.
Si vous êtes intéressé par le fichier de configuration du service pour cette configuration, je l'ai posté sur pastebin ici
