Présentation du problème

Sur un installation de Shinken Entreprise volumineuse contenant beaucoup d'hôte, le démon Broker et en particulier l'interface de Visualisation peuvent montrer des ralentissements. C'est principalement dû au fait que le module WebUI du Broker en charge de l'interface de Visualisation ne s'exécute que sur un seul CPU.

Ce module consomment beaucoup de resources CPU car il effectue notamment les opérations suivantes:

  • Mise à jour des données dans l'interface de Visualisation par communication avec le Scheduler (Broks)
  • Réponse aux requêtes en parallèle des X utilisateurs


Les problèmes de performances sont observés notamment sur l'interface de Visualisation lorsque le nombre d'utilisateurs simultanés est élevé. Pour regler ce problème, il est possible de mettre à disposition plusieurs interfaces de Visualisation (modules WebUI) qui seront accessible via un load balancer (HAProxy). Cette modification de l'architecture est donc invisible du point de vue de l'utilisateur.



Mise en place du load balancing

L'interface mise en place et décrite dans cette documentation est la suivante.

A gauche du schéma, on voit un architecture classique, dans laquelle l'utilisateur effectue directement sa requete à l'interface de Visualisation.

A droite, l'utilisateur fait sa requête au HAProxy à la place, qui va répartir les requetes équitablement et de manière transparente vers une des 2 instances de l'interface de Visualisation.




Mise à disposition de plusieurs interfaces de Visualisation

La première étape pour la mise en place du load balancing est d'avoir plusieurs interfaces de Visualisation disponibles, sur lequelles HAProxy va répartir la charge.

Pour cela, il faut avoir plusieurs modules WebUI de disponibles. On commence donc par dupliquer le module WebUI en copiant /etc/shinken/modules/webui.cfg vers /etc/shinken/modules/webui2.cfg.

On change ensuite le nom du module en WebUI2 et le port en 9767 dans notre module fraîchement dupliqué:

define module {
    #======== Module identity =========
    # Module name. Must be unique
    module_name               WebUI2

    # Module type (to load module code). Do not edit.
    module_type               webui



    #======== Listening address =========
    # host: IP address to listen to.
    #       note: 0.0.0.0 = all interfaces.
    host                      0.0.0.0
    # port to listen
    port                      9767


	...(suite du fichier coupée)
}


Pour rester fidèle au schéma ci-dessus, on change également le port du module WebUI (/etc/shinken/modules/webui.cfg) en 8767.


Il faut ensuite ajouter ce module sur le Broker pour qu'il soit activé. Dans la ligne modules, on ajoute le module WebUI2.

define broker {

# Shinken Enterprise. Lines added by import core. Do not remove it, it's used by Shinken Enterprise to update your objects if you re-import them.
    _SE_UUID            core-broker-060340145ade11e5b703080027f08538
    _SE_UUID_HASH       8e00136f9e61061e07ca0f4a63509b68
# End of Shinken Enterprise part

    #======== Daemon name and address =========
    # Daemon name. Must be unique
    broker_name               broker-master

    # IP/fqdn of this daemon (note: you MUST change it by the real ip/fqdn of this server)
    address                   172.16.0.5

    ...(contenu coupé)                                                                                                                      
                                                                                                                                                 
                                                                                                                                                 
    #======== Modules to enable for this daemon =========                                                                                        
    # Available:                                                                                                                                 
    # - Simple-log            : save all logs into a common file                                                                                 
    # - WebUI                 : visualisation interface                                                                                          
    # - Graphite-Perfdata     : save all metrics into a graphite database                                                                        
    # - sla                   : save sla into a database                                                                                         
    # - Livestatus            : TCP API to query element state, used by nagios external tools like NagVis or Thruk                               
    modules                   Simple-log, WebUI, WebUI2, Graphite-Perfdata, sla, Livestatus                                                      
                                                                                                                                    
    ...(suite du fichier coupée)
}


Enfin on redémarre l'Arbiter et le broker pour prendre en compte le changement de configuration.

/etc/init.d/shinken-arbiter restart
/etc/init.d/shinken-broker restart


Mise en place du HAProxy

La première étape est d'installer HAProxy et de l'activer au démarrage:

  • Installer HAProxy


    yum install haproxy


  • Activer HAProxy au démarrage
    Selon la version de CentOS utilisée, cette activation se fait d'une manière différente:

    # CentOS 6
chkconfig haproxy on


# CentOS 7
systemctl enable haproxy


On copie ensuite la configuration de HAProxy présente dans le fichier suivant dans /etc/haproxy/haproxy.cfg sur la machine du Broker:


Pour explication, cette configuration de HAProxy se découpe comme suivant:

  • Déclaration d'un frontend: Tout ce qui arrive sur la machine en tcp sur le port 7767 utilise le backend "webuis"

    frontend  main *:7767
    mode  tcp
    default_backend             webuis


  • Déclaration d'un backend: On configure ensuite comme traiter les requêtes envoyées par le frontend. Dans notre cas, on repartit les requêtes entre 2 serveurs "webui1" et "webui2" qui ont chacun leur adresse et leur port.

    backend webuis
    mode tcp
    balance     roundrobin

    server  webui1 127.0.0.1:8767  check  fall 1  rise 1  inter 1s
    server  webui2 127.0.0.1:9767  check  fall 1  rise 1  inter 1s


  • Mise à disposition d'une page de statistiques HAProxy: HAProxy permet de mettre à disposition une page qui présente en temps réel l'état des backends (dans notre cas les 2 WebUI).
    Cette page de statistiques se configure de la manière suivante:

    listen stats
    bind :8080
    mode http
    stats enable
    stats hide-version
    stats refresh 1s
    stats show-node
    stats auth admin:shinken
    stats uri  /loadbalancer-stats

    Dans cet exemple, elle est accessible via http://ip-haproxy:8080/loadbalancer-stats, protégée par une authentification (user: "admin", password: "shinken") et se présente comme suivant:


La dernière étape est de démarrer le service HAProxy (ou le redémarrer pour prendre en compte la configuration):

  • Sous CentOS 6

    service haproxy restart


  • Sous CentOS 7

    systemctl restart haproxy


Les URL suivantes sont alors disponibles:

Superviser le HAProxy

Le HAProxy peut aussi être supervisé depuis Shinken. Pour ça, il faut mettre la sonde check_haproxy en place sur le serveur du broker (dans /var/lib/shinken-user/libexec/).

En Centos7, cette sonde nécessite la dépendance suivante:

yum install perl-Switch


Le fichier de la sonde à mettre en place est le suivant:

Il faut penser à lui donner les droits d’exécutions:

chmod a+x /var/lib/shinken-user/libexec/check_haproxy

Pour la lancer:

/var/lib/shinken-user/libexec/check_haproxy -S /var/lib/haproxy/stats -D 'C<u,.501,0.01,25,50>'
  • u: on ne compte que les serveurs up
  • 0.501 : on passe en WARNING si on passe en dessous de 50.1% des serveurs disponibles
  • 0.01: on passe en CRITICAL si on passe en dessous de 0.1% des serveurs disponibles
  • 25: on passe en WARNING si on dépasse les 25% de sessions autorisées
  • 50: on passe en CRITICAL si on dépasse les 50% de sessions autorisées

Voici un exemple de rendu de la sonde: