Varnish est un excellent serveur de cache HTTP, mais il peut aussi être un très bon load balancer.

Photo des produits Vanish

Pour se faire nous allons commencer par définir dans notre fichier .vcl les différents backend


backend server01 {
    .host = "172.16.1.1";
    .port = "80";
}

backend server02 {
    .host = "172.16.1.2";
    .port = "80";
}

backend server03 {
    .host = "172.16.1.3";
    .port = "80";
}

Puis nous allons définir le director qui va lier les backend entre eux selon une règle. Ici la règle sera le round robin.


director servers round-robin {
    { .backend = server01; }
    { .backend = server02; }
    { .backend = server03; }
}

Et en fin dans la partie sub vcl_recv de votre .vcl nous allons déclarer le director comme backend à utiliser.


sub vcl_recv {
    #votre code

    set req.backend = servers;
}

Il suffit de relancer Varnish pour que cela fonctionne.

Ce n’est pas fini car il faut surtout rajouter un probe sur les backend, cela permettra de vérifier la santé de ceux-ci et de les exclure si besoin.


probe checkserver {
    .url = "/";
    .timeout = 1s;
    .interval = 10s;
    .window = 8;
    .threshold = 6;
}
  • url : indique l’url que varnish va demander pour vérifier que le backend fonctionne
  • timeout : le temps que varnish va attendre avant de considéré que la vérification a échoué.
  • interval : le temps entre chaque vérification
  • window : le nombre de vérification permettant de déterminer la santé du backend
  • threshold : le nombre de vérification réussi sur le pool window permettant de dire que le backend est en bonne santé

Dans l’exemple si dessus pour le serveur server01 varnish va appeler http://172.16.1.1/ toutes les 10 secondes et comptabiliser l’appel comme bon si la page répond une page valide (code http 200) en moins d’1 secondes.

Varnish regardera les 8 dernières vérification et si le serveur a mal (ou pas répondu) plus de 2 fois alors il sera considéré comme malade et sorti des backend tant qu’il ne répondra pas bien à nouveau.

Vous pouvez faire en sorte que l’url appelée par Varnish soit un script qui va faire des vérifications supplémentaires (ecrire un fichier sur le disque par exemple) et répondre une erreur 500 si les vérifications ne sont pas bonnes. Ainsi même si le serveur répond, Varnish va quand même considérer la vérification échouée.

Donc un fois votre probe défini il faudra le rajouter dans la config de vos backend.

Comme cela :


backend server01 {
    .host = "172.16.1.1";
    .port = "80";
    .probe = checkserver;
}

backend server02 {
    .host = "172.16.1.2";
    .port = "80";
    .probe = checkserver;
}

backend server03 {
    .host = "172.16.1.3";
    .port = "80";
    .probe = checkserver;
}

Une fois Varnish relancé vous pourrez voir l’état de vos backend avec la commande varnishadm puis dans la console backend.list vous donnera :


server01(172.16.1.1,,80)        3     probe      Healthy 8/8
server02(172.16.1.2,,80)        3     probe      Healthy 8/8
server03(172.16.1.3,,80)        3     probe      Healthy 8/8

Dans varnishadm vous pouvez aussi utiliser debug.healt pour voir l’état détaillé de chaque vérification faites par Varnish pour chaque backend.


Backend server01 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.003597
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Backend server02 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.007632
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRR RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Backend server03 is Healthy
Current states  good:  8 threshold:  6 window:  8
Average responsetime of good probes: 0.004433
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

Dans l’exemple ci-dessus on remarquera qu’il y a un trou dans l’état de server02, cela indique que lors de cette vérification la page n’a pas répondu correctement.

Enfin, toujours dans Varnish, si vous souhaitez exclurcommee manuellement un backend il suffit de faire :


backend.set_health server01 sick

Cela forcera Varnish à considérer server01 comme malade et il ne l’utilisera plus tant que vous ne lui dirai pas de le gerer automatiquement comme ceci :


backend.set_health server01 auto