Présentation du problème
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
Dans les deux cas on va avoir besoin de l'outil haproxy:
| Code Block |
|---|
yum install haproxy |
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:
| 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
Pour lancer le service haproxy:
| Code Block |
|---|
service haproxy start |
Pour voir l'état de la redirection:
| Code Block |
|---|
echo "show stat" | nc -U /var/lib/haproxy/stats |
Pour voir les info du démon HAProxy en général:
| Code Block |
|---|
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.
| Code Block | ||
|---|---|---|
| ||
...(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:
| Code Block |
|---|
yum install perl-Switch |
Le fichier de la sonde à mettre en place est le suivant:
| View file | ||||
|---|---|---|---|---|
|
Il faut penser à lui donner les droits d’exécutions:
| Code Block |
|---|
chmod a+x /var/lib/shinken-user/libexec/check_haproxy |
Pour la lancer:
| Code Block |
|---|
/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:
