Surveillance de l’intégrité de votre cluster

Pour garantir les performances et la redondance d’un cluster GitHub Enterprise Server, vous pouvez surveiller son intégrité.

Qui peut utiliser cette fonctionnalité ?

GitHub détermine l’éligibilité au clustering et doit activer la configuration de la licence de votre instance. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

Dans cet article

À propos de l’intégrité d’un cluster GitHub Enterprise Server

Un cluster GitHub Enterprise Server comprend plusieurs nœuds, avec des services redondants distribués sur plusieurs nœuds. Si un service individuel ou un nœud entier échoue, les utilisateurs ne doivent pas le remarquer. Les échecs affectent les performances et la redondance. Il est donc important de surveiller l’intégrité de votre cluster. Vous pouvez surveiller l’intégrité de votre cluster à l’aide d’un utilitaire de ligne de commande ou d’un outil de surveillance externe comme Nagios.

Vérification manuelle de l’état d’un cluster

GitHub Enterprise Server intègre un utilitaire en ligne de commande qui permet de superviser l’intégrité d’un cluster. Dans l’interpréteur de commandes d’administration, l’exécution de la commande ghe-cluster-status déclenche une série de contrôles d’intégrité sur chaque nœud, avec notamment une vérification de la connectivité et de l’état du service. La sortie présente tous les résultats de test, dont le texte ok ou error. Par exemple, pour afficher uniquement les tests non concluants, exécutez :

admin@ghe-data-node-0:~$ ghe-cluster-status | grep error
> mysql-replication ghe-data-node-0: error Stopped
> mysql cluster: error

Remarque : En l’absence de tests non concluants, cette commande ne produit aucune sortie. Cela indique que le cluster est sain.

Supervision de l’état d’un cluster avec Nagios

Vous pouvez configurer Nagios pour qu’il supervise GitHub Enterprise Server. En plus de superviser la connectivité de base de chaque nœud du cluster, vous pouvez vérifier l’état du cluster en configurant Nagios pour qu’il utilise la commande ghe-cluster-status -n. Elle retourne une sortie dans un format que comprend Nagios.

Prérequis

Hôte Linux exécutant Nagios.
Accès réseau au cluster GitHub Enterprise Server.

Configuration de l’hôte Nagios

Générez une clé SSH avec une phrase secrète vide. Nagios l’utilise pour s’authentifier auprès du cluster GitHub Enterprise Server.

nagiosuser@nagios:~$ ssh-keygen -t ed25519
> Generating public/private ed25519 key pair.
> Enter file in which to save the key (/home/nagiosuser/.ssh/id_ed25519):
> Enter passphrase (empty for no passphrase): LEAVE BLANK BY PRESSING ENTER
> Enter same passphrase again: PRESS ENTER AGAIN
> Your identification has been saved in /home/nagiosuser/.ssh/id_ed25519.
> Your public key has been saved in /home/nagiosuser/.ssh/id_ed25519.pub.

Avertissement de sécurité : Une clé SSH sans phrase secrète peut présenter un risque de sécurité si elle est autorisée pour un accès complet à un hôte. Limitez l’autorisation de cette clé à une simple commande en lecture seule.

Remarque : Si vous utilisez une distribution de Linux qui ne prend pas en charge l’algorithme Ed25519, utilisez la commande :

nagiosuser@nagios:~$ ssh-keygen -t rsa -b 4096

1. Copiez la clé privée (`id_ed25519`) dans le dossier de base de `nagios` et définissez la propriété appropriée.

nagiosuser@nagios:~$ sudo cp .ssh/id_ed25519 /var/lib/nagios/.ssh/
nagiosuser@nagios:~$ sudo chown nagios:nagios /var/lib/nagios/.ssh/id_ed25519

Pour autoriser la clé publique à exécuter uniquement la commande ghe-cluster-status -n, utilisez un préfixe command= dans le fichier /data/user/common/authorized_keys. À partir de l’interpréteur de commandes d’administration de n’importe quel nœud, modifiez ce fichier pour ajouter la clé publique générée à l’étape 1. Par exemple : command="/usr/local/bin/ghe-cluster-status -n" ssh-ed25519 AAAA....
Validez et copiez la configuration sur chaque nœud du cluster en exécutant ghe-cluster-config-apply sur le nœud où vous avez modifié le fichier /data/user/common/authorized_keys.
```
admin@ghe-data-node-0:~$ ghe-cluster-config-apply
> Validating configuration
> ...
> Finished cluster configuration
```

Pour vérifier que le plug-in Nagios peut bien exécuter la commande, exécutez-la de manière interactive à partir de l’hôte Nagios.

nagiosuser@nagios:~$ /usr/lib/nagios/plugins/check_by_ssh -l admin -p 122 -H HOSTNAME -C "ghe-cluster-status -n" -t 30
> OK - No errors detected

Créez une définition de commande dans votre configuration Nagios.

Exemple de définition

define command {
     command_name    check_ssh_ghe_cluster
     command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "ghe-cluster-status -n" -l admin -p 122 -t 30
}

Ajoutez cette commande à une définition de service pour un nœud du cluster GitHub Enterprise Server.

Exemple de définition

define host{
     use                     generic-host
     host_name               ghe-data-node-0
     alias                   ghe-data-node-0
     address                 10.11.17.180
     }

define service{
       use                             generic-service
       host_name                       ghe-data-node-0
       service_description             GitHub Cluster Status
       check_command                   check_ssh_ghe_cluster
       }

Une fois que vous avez ajouté la définition à Nagios, la vérification du service s’exécute en fonction de votre configuration. Le service nouvellement configuré doit apparaître dans l’interface web Nagios.