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
On distingue 2 cas pour la mise en place du HAProxy:
- Les modules webui servent leur contenu en HTTP
- Les modules webui servent leur contenu en HTTPS
Dans les deux cas on va avoir besoin de l'outil haproxy:
yum install haproxy chkconfig haproxy on |
WebUIs en HTTPS
En cas de HTTPS, HAProxy ne va se comporter que comme un load balancer TCP car il ne peux analyser les trames HTTP.
Le soucis dans ce cas sera qu'alors HAProxy ne donnera pas de page HTML de stats, mais le statistiques du load balancing pourront être consultées via une socket unix.
On place donc le fichier suivant dans /etc/haproxy/haproxy.cfg:
Ceci va faire ouvrir le port 7767 (le port "classique") par HAProxy et répartir les requêtes reçues entre les 2 ports 8767 et 9767.
Il faut deux modules WebUI, sur les ports sont donc respectivement:
- 8767
- 9767
Pour lancer le service haproxy:
service haproxy start |
Pour voir l'état de la redirection:
echo "show stat" | nc -U /var/lib/haproxy/stats |
Pour voir les info du démon HAProxy en général:
echo "show info" | nc -U /var/lib/haproxy/stats |
La page suivante présente des méthodes et outils permettant de visualiser les statistiques du HAProxy de manière plus conviviale:
WebUI en HTTP
Par défaut les interfaces de Visualisation rendues disponibles par les modules WebUI sont en HTTP.
Dans HAProxy, cela nous permet d'obtenir des statistiques plus détaillées sur les redirections effectuées.
Pour cela, il faut modifier le fichier /etc/haproxy/haproxy.cfg mis en place précédemment et changer la ligne mode du backend pour qu'elle choisisse le mode http au lieu du mode tcp.
...(début du fichier coupé)
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend webuis
mode http
balance roundrobin
...(suite du fichier) |
Une page de statistiques est alors mise à disposition par HAProxy:
Les identifiants par défaut (modifiables dans /etc/haproxy/haproxy.cfg) sont admin:admin.
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:
