Comment surveiller les volumes de glusterfs


12

Glusterfs, tout en étant un joli système de fichiers distribué, ne fournit presque aucun moyen de surveiller son intégrité. Les serveurs peuvent aller et venir, les briques peuvent devenir périmées ou échouer et j'ai peur de le savoir quand il est probablement trop tard.

Récemment, nous avons eu un étrange échec lorsque tout a semblé fonctionner, mais une brique est tombée du volume (trouvée par pure coïncidence).

Existe-t-il un moyen simple et fiable (script cron?) Qui me permettra de connaître l'état de santé de mon volume GlusterFS 3.2 ?


Pour l'instant, nous utilisons une surveillance basée sur un script de shell sale: check_gluster.sh
Arie Skliarouk

Jetez un œil à glfs-health.sh .
quanta

1
J'ai vérifié le glfs-health.sh et il semble que ce soit pour les anciennes versions de glusterfs, qui étaient contrôlées par le fichier de configuration. Je vais clarifier ma question pour représenter glusterfs 3.2.
Arie Skliarouk

Réponses:


3

Cela a été une demande aux développeurs de GlusterFS depuis un certain temps maintenant et il n'y a rien de solution prête à l'emploi que vous pouvez utiliser. Cependant, avec quelques scripts, ce n'est pas impossible.

La quasi-totalité du système Gluster est gérée par une seule commande gluster et avec quelques options, vous pouvez écrire vous-même des scripts de surveillance de la santé. Voir ici pour lister les informations sur les briques et les volumes - http://gluster.org/community/documentation/index.php/Gluster_3.2:_Displaying_Volume_Information

Pour surveiller les performances, consultez ce lien - http://gluster.org/community/documentation/index.php/Gluster_3.2:_Monitoring_your_GlusterFS_Workload

MISE À JOUR: Envisagez de passer à http://gluster.org/community/documentation/index.php/About_GlusterFS_3.3

Vous êtes toujours mieux avec la dernière version car ils semblent avoir plus de corrections de bugs et bien pris en charge. Bien sûr, exécutez vos propres tests avant de passer à une version plus récente - http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ :)

Il y a un guide d'administration avec une section spécifique pour surveiller votre installation de GlusterFS 3.3 dans le chapitre 10 - http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US .pdf

Voir ici pour un autre script nagios - http://code.google.com/p/glusterfs-status/


Merci Chida, je suppose que ce qui m'a fait bloquer, c'est que certaines personnes ( github.com/semiosis/puppet-gluster ) surveillent le gluster via la table proc ('--with-brick', etc) et les fichiers journaux (egrep 'E' pour erreur), et certaines personnes utilisent la CLI et je n'ai aucune idée de ce qui est plus susceptible de signaler avec précision l'état de gluster.
r_2

Je recommanderais d'utiliser la CLI car c'est celle que GlusterFS recommande et est forcément à jour.
Chida


2

Veuillez vérifier le script joint à https://www.gluster.org/pipermail/gluster-users/2012-June/010709.html pour gluster 3.3; il est probablement facilement adaptable à gluster 3.2.

#!/bin/bash

# This Nagios script was written against version 3.3 of Gluster.  Older
# versions will most likely not work at all with this monitoring script.
#
# Gluster currently requires elevated permissions to do anything.  In order to
# accommodate this, you need to allow your Nagios user some additional
# permissions via sudo.  The line you want to add will look something like the
# following in /etc/sudoers (or something equivalent):
#
# Defaults:nagios !requiretty
# nagios ALL=(root) NOPASSWD:/usr/sbin/gluster peer status,/usr/sbin/gluster volume list,/usr/sbin/gluster volume heal [[\:graph\:]]* info
#
# That should give us all the access we need to check the status of any
# currently defined peers and volumes.

# define some variables
ME=$(basename -- $0)
SUDO="/usr/bin/sudo"
PIDOF="/sbin/pidof"
GLUSTER="/usr/sbin/gluster"
PEERSTATUS="peer status"
VOLLIST="volume list"
VOLHEAL1="volume heal"
VOLHEAL2="info"
peererror=
volerror=

# check for commands
for cmd in $SUDO $PIDOF $GLUSTER; do
    if [ ! -x "$cmd" ]; then
        echo "$ME UNKNOWN - $cmd not found"
        exit 3
    fi
done

# check for glusterd (management daemon)
if ! $PIDOF glusterd &>/dev/null; then
    echo "$ME CRITICAL - glusterd management daemon not running"
    exit 2
fi

# check for glusterfsd (brick daemon)
if ! $PIDOF glusterfsd &>/dev/null; then
    echo "$ME CRITICAL - glusterfsd brick daemon not running"
    exit 2
fi

# get peer status
peerstatus="peers: "
for peer in $(sudo $GLUSTER $PEERSTATUS | grep '^Hostname: ' | awk '{print $2}'); do
    state=
    state=$(sudo $GLUSTER $PEERSTATUS | grep -A 2 "^Hostname: $peer$" | grep '^State: ' | sed -nre 's/.* \(([[:graph:]]+)\)$/\1/p')
    if [ "$state" != "Connected" ]; then
        peererror=1
    fi
    peerstatus+="$peer/$state "
done

# get volume status
volstatus="volumes: "
for vol in $(sudo $GLUSTER $VOLLIST); do
    thisvolerror=0
    entries=
    for entries in $(sudo $GLUSTER $VOLHEAL1 $vol $VOLHEAL2 | grep '^Number of entries: ' | awk '{print $4}'); do
        if [ "$entries" -gt 0 ]; then
            volerror=1
            let $((thisvolerror+=entries))
        fi
    done
    volstatus+="$vol/$thisvolerror unsynchronized entries "
done

# drop extra space
peerstatus=${peerstatus:0:${#peerstatus}-1}
volstatus=${volstatus:0:${#volstatus}-1}

# set status according to whether any errors occurred
if [ "$peererror" ] || [ "$volerror" ]; then
    status="CRITICAL"
else
    status="OK"
fi

# actual Nagios output
echo "$ME $status $peerstatus $volstatus"

# exit with appropriate value
if [ "$peererror" ] || [ "$volerror" ]; then
    exit 2
else
    exit 0
fi


1

@Arie Skliarouk, votre check_gluster.sha une faute de frappe - sur la dernière ligne, vous recherchez exitstplutôt que exist. Je suis allé de l'avant et l'ai réécrit pour être un peu plus compact et pour supprimer l'exigence d'un fichier temporaire.

#!/bin/bash

# Ensure that all peers are connected
gluster peer status | grep -q Disconnected && echo "Peer disconnected." && exit 1

# Ensure that all bricks have a running log file (i.e., are sending/receiving)
for vol in $(gluster volume list); do
  for brick in $(gluster volume info "$vol" | awk '/^Brick[0-9]*:/ {print $2}'); do
    gluster volume log locate "$vol" "$brick";
  done;
done |
 grep -qE "does not (exist|exitst)" &&
 echo "Log file missing - $vol/$brick ." &&
 exit 1

1
La faute de frappe "exitst" est ce qui est écrit dans les journaux. Je n'achète pas l'avantage "compact" - le script est beaucoup plus difficile à comprendre lorsque les lignes sont surchargées. Le fichier temporaire est un prix bon marché à payer pour le code facile à comprendre.
Arie Skliarouk

@ArieSkliarouk: mise à jour pour couvrir les deux cas, mais sachez que le message pertinent a été supprimé en novembre 2011; voir git.gluster.org/… . Ainsi, cela ne fonctionnera probablement pas sur les nouveaux Glusters. Si vous trouvez le code plus court plus difficile à comprendre, c'est bien, mais il est nettement plus robuste que l'utilisation d'un fichier temporaire, alors pensez à le refactoriser pour plus de lisibilité au lieu de le rejeter pour manque perçu de cet attribut.
BMDan

1
Un éditeur anonyme a noté que cela gluster volume info | awk ...peut être abrégé en gluster volume list.
Lekensteyn
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.