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 a 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.
| Panel |
|---|
|
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é:
| Code Block | ||
|---|---|---|
| ||
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.
| Code Block | ||
|---|---|---|
| ||
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 pour prendre en compte le changement de configuration.
| Code Block |
|---|
/etc/init.d/shinken-arbiter 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
WebUIs en HTTPS
En cas de HTTPS, HAProxy
Le souci de WebUI est de ne pouvoir utiliser qu'un seul CPU pour:
- mettre à jours ses données depuis les infos du schedulers (aka les broks)
- répondre aux requêtes des X utilisateurs
En cas de soucis de CPU (pour l'instant le cas rencontré est celui de trop de requêtes des utilisateurs, pas encore de la gestion des broks) il faut plusieurs WebUI load balancées par un frontal devant (haproxy).
Il y a deux cas:
- les WebUI sont en HTTPS
- les WebUI sont en HTTP normal
WebUIs en HTTPS:
...
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-webui.cfg:
| View file | |||
|---|---|---|---|
|
...
|
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
...
Nous n'avons pas encore de scripts d'init pour cette configuration particulière. Il faudra donc lancer la commande suivante dans un screen ou tmux:
| Code Block |
|---|
haproxy -f /etc/haproxy-webui.cfg -V -db |
Pour
...
voir
...
l'état de la redirection:
| Code Block |
|---|
echo "show stat" | nc -U /var/lib/haproxy/stats |
Pour voir les info de haproxy daemon en général:
| Code Block |
|---|
echo "show info" | nc -U /var/lib/haproxy/stats |
Pour lire les stats on peux voir avec (cf https://www.datadoghq.com/blog/how-to-collect-haproxy-metrics/)
Superviser le HAProxy
...
Il faut mettre la sonde check_haproxy en place sur le serveur du broker (dans /var/lib/shinken-user/libexec/).
En Centos7 elle demande des prérequis:
- yum install perl-Switch
| View file | ||||
|---|---|---|---|---|
|
Pour la lancer:
| Code Block |
|---|
/var/lib/shinken-user/libexec/check_haproxy -S /var/lib/haproxy/stats -D 'C<u,.501,0.01,.25,0.5>' |
- 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
- 0.25: on passe en WARNING si on dépasse les 25% de sessions autorisées
- 0.5: on passe en CRITICAL si on dépasse les 50% de sessions autorisées
Voici un exemple de rendu de la sonde:
