Comment installer Memcached avec repcached "Répartition intégrée côté serveur" sur Debian Lenny

Comment installer Memcached avec repcached “Répartition intégrée côté serveur” sur Debian Lenny

Les gens connaissent probablement memcached ( http://memcached.org/) et son interface de cache d’objets en mémoire basée sur des paires clé-valeur à haute performance. Son principal objectif est de fournir un moteur de mise en cache distribué facile à utiliser dans un environnement multinode. Avez-vous déjà voulu laisser memcached gérer la réplication ?

Si vous souhaitez ajouter des capacités de haute disponibilité, il est conseillé de laisser le client (-bibliothèque) gérer la réplication de vos données à travers tous les nœuds. Disons que l’utilisation de memcached comme backend de stockage pour les sessions php est configurée comme suit :

# configuration pour le module php memcache
extension=memcache.so
session.save_handler = memcache
session.save_path = "tcp://192.168.168.61:11211?persistent=1,tcp://192.168.168.62:11211?persistent=1"

Maintenant, les sessions sont distribuées (non répliquées) à travers les deux nœuds. Dès qu’un nœud tombe en panne, vous perdrez toutes ces données. Tant que vous utilisez uniquement memcached comme un booster de performance et distributeur de certaines données “cachables”, cela ne devrait pas faire de mal : les données perdues sont remplies comme elles l’étaient lors de la création des entrées de cache.

Pour répliquer vos données de session, vous devrez utiliser un gestionnaire de session personnalisé qui se connecte à chacun de ces nœuds par lui-même… pour la réplication. Il en va de même si vous souhaitez écrire vos propres objets mis en cache dans votre cher memcached. Votre application doit toujours connaître tous les nœuds sur lesquels écrire.

Faciliter la réplication en laissant memcached s’en occuper comme repcached

Ces problèmes peuvent confondre les développeurs qui souhaitent simplement se concentrer sur leur application et ne veulent pas se soucier autant de la haute disponibilité, de l’équilibrage de charge et de la scalabilité. Avec repcached, au moins une solution HA à 2 nœuds peut être mise en place facilement et de manière transparente.

Un simple patch ajoute une réplication maître-maître élégante à votre memcached. Vous n’aurez maintenant besoin que de vous connecter à votre memcached local qui gère ensuite la réplication de lui-même.

Ainsi, votre application peut rester simple et basique, en utilisant votre système de fichiers POSIX local (qui peut être répliqué par DRBD, GlusterFS, etc.), votre base de données locale (vous l’avez deviné : “qui gère la réplication de lui-même”) et en se connectant à une instance locale de votre “cluster memcached”. Cette configuration ouvre quelques options plus simples et transparentes pour une scalabilité HA facile et légère.

Installation, configuration et test d’un cluster à 2 nœuds

Tout d’abord, récupérez une copie du patch repcached ou téléchargez même la source memcached pré-patchée depuis http://repcached.lab.klab.org/. Il y a une dépendance sur libevent qui devra peut-être être résolue avant l’installation.

root@ha-01 ~ # apt-get install libevent-dev

Maintenant, décompressez et accédez au répertoire :

root@ha-01 ~ # tar xvf memcached-1.2.8-repcached-2.2.tar
root@ha-01 ~ # cd memcached-1.2.8-repcached-2.2/

Configurez avec l’option –enable-repcached.

root@ha-01 ~/memcached-1.2.8-repcached-2.2 # ./configure –enable-replication
root@ha-01 ~/memcached-1.2.8-repcached-2.2 # make
root@ha-01 ~/memcached-1.2.8-repcached-2.2 # make install

Ne vous inquiétez pas trop d’un package memcached.dep précédemment installé. Cette installation manuelle n’installera qu’un binaire dans /usr/local/bin/memcached laissant votre memcached “original” intact dans /usr/bin/memcached.

Contrairement au package debian, vous voudrez peut-être fournir des options de ligne de commande en utilisant une simple configuration par défaut dans /etc/default/memcachedrep (rep => ‘réplication’), c’est-à-dire :

configuration par défaut

## options de ligne de commande supplémentaires pour démarrer memcached en mode répliqué
# -x < ip_addr > nom d'hôte ou adresse IP du serveur de réplication maître
# -X < num > numéro de port TCP du maître (par défaut : 11212)
DAEMON_ARGS="-m 64 -p 11211 -u root -P /var/run/memcachedrep.pid -d -x 192.168.168.2"

Avec cela en place, un script d’initialisation est mis en place assez facilement en utilisant et en modifiant le squelette debian :

script d’initialisation

#! /bin/sh
### BEGIN INIT INFO
# Provides:             memcached
# Required-Start:       $syslog
# Required-Stop:        $syslog
# Should-Start:         $local_fs
# Should-Stop:          $local_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    memcached - Daemon de mise en cache en mémoire répliqué
# Description:          memcached - Daemon de mise en cache en mémoire répliqué
### END INIT INFO
# Author: Marcus Spiegel <[email protected]>
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="memcachedrep"
NAME=memcached
DAEMON=/usr/local/bin/$NAME
DAEMON_ARGS="--options args"
PIDFILE=/var/run/memcachedrep.pid
SCRIPTNAME=/etc/init.d/$DESC
VERBOSE="yes"
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$DESC ] && . /etc/default/$DESC
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
        || return 1
    start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
        $DAEMON_ARGS \
        || return 2
    # Add code here, if necessary, that waits for the process to be ready
    # to handle requests from services started subsequently which depend
    # on this one.  As a last resort, sleep for some time.
}
#
# Function that stops the daemon/service
#
do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    # Wait for children to finish too if this is a daemon that forks
    # and if the daemon is only ever run from this initscript.
    # If the above conditions are not satisfied then add some other code
    # that waits for the process to drop all resources that could be
    # needed by services started subsequently.  A last resort is to
    # sleep for some time.
    start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
    [ "$?" = 2 ] && return 2
    # Many daemons don't delete their pidfiles when they exit.
    rm -f $PIDFILE
    return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
    #
    # If the daemon can reload its configuration without
    # restarting (for example, when it is sent a SIGHUP),
    # then implement that here.
    #
    start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
    return 0
}
case "$1" in
  start)
    [ "$VERBOSE" != no ] && log_daemon_msg "Démarrage de $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    [ "$VERBOSE" != no ] && log_daemon_msg "Arrêt de $DESC" "$NAME"
    do_stop
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  #reload|force-reload)
    #
    # If do_reload() is not implemented then leave this commented out
    # and leave 'force-reload' as an alias for 'restart'.
    #
    #log_daemon_msg "Rechargement de $DESC" "$NAME"
    #do_reload
    #log_end_msg $? 
    #;;
  restart|force-reload)
    #
    # If the "reload" option is implemented then remove the
    # 'force-reload' alias
    #
    log_daemon_msg "Redémarrage de $DESC" "$NAME"
    do_stop
    case "$?" in
      0|1)
        do_start
        case "$?" in
            0) log_end_msg 0 ;;
            1) log_end_msg 1 ;; # Ancien processus est toujours en cours d'exécution
            *) log_end_msg 1 ;; # Échec du démarrage
        esac
        ;;
      *)
        # Échec de l'arrêt
        log_end_msg 1
        ;;
    esac
    ;;
  *)
    #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
    echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
    exit 3
    ;;
esac
:

Test

Après avoir configuré repcached sur les deux nœuds, vous devriez probablement le tester. Vous pouvez vous connecter à memcached sur chaque nœud par telnet :

root@ha-01 ~ # telnet 127.0.0.1 11211

Essai 127.0.0.1…
Connecté à 127.0.0.1.
Le caractère d’échappement est ‘^]’.

Maintenant, émettez une commande set pour écrire quelques valeurs de test juste sur un nœud :

set foo 0 0 3
bar
STORED

Déplacez-vous vers l’autre nœud, connectez-vous et essayez de lire :

root@ha-02 ~ # telnet 127.0.0.1 11211

Essai 127.0.0.1…
Connecté à 127.0.0.1.
Le caractère d’échappement est ‘^]’.
get foo
VALUE foo 0 3
bar
END

Essayez cela à l’envers et amusez-vous ! Et enfin, éteignez l’un de ces nœuds après avoir poussé quelques valeurs supplémentaires en mémoire. Le nœud en cours d’exécution continue de répondre avec toutes les données - excellent.

La vraie partie amusante est que dès que vous redémarrez le nœud indisponible, il récupère toutes les données “perdues” de l’autre maître. Allez-y, essayez par vous-même. Il en sera de même si vous éteignez maintenant l’autre nœud et le redémarrez. Même les données qui ont été définies sur un nœud pendant que l’autre nœud était hors service seront ajoutées au nœud à venir après le démarrage.

Cette configuration est capable d’une configuration de réplication à 2 nœuds seulement - pour l’instant. Pensez à construire un cluster à 4 nœuds avec une sorte de configuration raid10 où la réplication et la distribution sont combinées… ou quelque chose comme ça. Eh bien, au moins dans cette configuration HA à 2 nœuds, repcached fonctionne comme un charme.

Personnellement, j’aimerais essayer un cercle de 3 nœuds ensuite :) (peut-être avec heartbeat pour combler tout manque dans ce cercle).