evoformations/support/varnish.tex

% Copyright (c) 2004-2010 Evolix <info@evolix.fr>
%  Permission is granted to copy, distribute and/or modify this document
%  under the terms of the GNU Free Documentation License, Version 1.2
%  or any later version published by the Free Software Foundation;
%  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
%  A copy of the license is included at http://www.gcolpart.com/howto/fdl.html

\chapter{Varnish}

Site officiel: \url{https://www.varnish-cache.org/}

\section{Présentation}

Varnish est un reverse proxy HTTP dans le but premier est la mise en cache de
contenu. Il est également capable de gérer plusieurs backend, avec
répartition de charge et détection de panne.

Varnish, développé en C, se concentre principalement sur la performance sur des infrastructures
à haut et très haut trafic.

Un autre point fort est son langage de configuration, qui permet de paramétrer
finement le comportement de Varnish aux différentes étapes du traitement de la
requête.

Le développement de Varnish a commencé en 2005, et il est distribué sous licence
BSD.

\section{Installation}

Varnish est disponible dans les dépôts de Debian Squeeze en version 2.1.3. Il
existe également un backport du paquet de Wheezy, qui fournit la version 3.0.2.
Cette version apporte de nombreuses amélioration et fonctionnalité dans la
gestion du load-balancing entre les backends.

Installation du paquet:
\begin{verbatim}
# aptitude install varnish
\end{verbatim}

\section{Configuration}

Les possibilités offertes pour la configuration de Varnish sont assez vastes,
elles seront abordés par grands thèmes.

\subsection{Paramétrage de base}

Tout d'abord, il est nécessaire de renseigner quelques informations de base au
démon \texttt{varnishd}. Cette configuration se passe dans le fichier
\texttt{/etc/default/varnish}. Plusieurs cas de figure sont proposés à titre
d'exemple dans ce fichier, en voici un autre avec quelques optimisations
supplémentaires:
\begin{verbatim}
DAEMON_OPTS="-a 192.0.2.1:80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,3G
             -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,10G
             -p thread_pools=<Number of CPU cores>
             -p thread_pool_add_delay=2
             -p thread_pool_max=5000"
umask 022
\end{verbatim}

Et voici quelques explications sur les paramètres:
\begin{description}
  \item[\texttt{-a 192.0.2.1:80}] \hfill \\
    Il s'agit du couple IP,port sur lequel Varnish attendra les requêtes HTTP à
    traiter.
  \item[\texttt{-T localhost:6082}] \hfill \\
    Il s'agit du couple IP,port sur lequel sera accessible l'interface
    d'administration de Varnish (traité plus loin dans ce chapitre).
  \item[\texttt{-f /etc/varnish/default.vcl}] \hfill \\
    Cette option indique le fichier de configuration à utiliser.
  \item[\texttt{-S /etc/varnish/secret}] \hfill \\
  \item[\texttt{-s malloc,3G}]
  \item[\texttt{-s file,/var/lib/varnish/\$INSTANCE/varnish\_storage.bin,10G}] \hfill \\
    On indique ici qu'une partie du cache sera stocké en mémoire 3~Go, ainsi que
    dans un fichier plat sur le disque, qui sera limité à 10~Go.
  \item[\texttt{-p thread\_pools=<Number of CPU cores>}]
  \item[\texttt{-p thread\_pool\_add\_delay=2}]
  \item[\texttt{-p thread\_pool\_max=5000}] \hfill \\
    L'option \texttt{-p} permet de modifier différents paramètres d'exécution.
    De nombreux paramètres peuvent être modifiés, la liste complète avec leur
    description se trouve ici:
    \url{https://www.varnish-cache.org/docs/2.1/reference/varnishd.html}.

    \texttt{thread\_pools} indique le nombre de groupe de threads à lancer. Cette
    valeur ne devrait pas dépasser le nombre de c\oe{}ur disponible sur le système
    (pour des raisons de performance). Pour \texttt{threa\_poo\_ad\_delay}, il
    s'agit du temps en milisecondes à attendre avant la création d'un nouveau
    thread. Et enfin \texttt{threa\_poo\_max} représente le nombre total de
    thread maximum à ne pas dépasser, tout pool confondus.
  \item[\texttt{umask 022}] \hfill \\
    Varnish s'attend à avoir un umask à 022 pour s'exécuter
    correctement. \'Etant donné qu'il n'est pas forcé dans le script d'init,
    nous le plaçons ici manuellement.
\end{description}

\subsection{Aperçu de la syntaxe du langage VCL}

\subsection{Gestion du cache}

En se positionnant entre le client et le serveur applicatif, Varnish permet de
lire et surcharger si besoin les entêtes HTTP de contrôle du cache. Par défaut,
celle ci sont lues et pris en compte, mais on peut redéfinir le comportement
dans la configuration.

Voici quelques exemples d'utilisation typique:

\paragraph{Forcer le TTL pour certains contenu}
\begin{verbatim}
sub vcl_fetch {
    if (req.url ~ "\.(png|gif|jpg)$") {
        set beresp.ttl = 5d;
        set beresp.http.magicmarker = "1";
    }
}

sub vcl_deliver {
    if (resp.http.magicmarker) {
        unset resp.http.magicmarker;
        set resp.http.Age = "0";
      }
}
\end{verbatim}
\texttt{beresp.http.magicmarker} permet de marquer l'objet pour pouvoir ensuite
remettre son age à 0 (dans \texttt{vcl\_deliver}.

Pour que le changement de TTL le soit également coté client, on réécrit le
header HTTP \emph{Cache-Control} en ajoutant (dans le premier \texttt{if}:
\begin{verbatim}
set beresp.http.cache-control = ``max-age=432000'';
\end{verbatim}

\paragraph{Indiquer si un objet provient du cache ou pas dans les headers HTTP}
Dans un but de debugage, il peut être intéressant d'indiquer si un contenu
provient du cache de Varnish ou non. Cela se fait simplement comme ceci:
\begin{verbatim}
sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}
\end{verbatim}

\subsection{Gestion du load-balancing}

Tout d'abord, il faut définir au moins un backend pour que l'ensemble puisse
fonctionner correctement. Cela se fait à l'aide de la directive
\texttt{backend}, comme ceci:
\begin{verbatim}
backend www00 {
    .host = "192.0.2.8";
    .port = "80";
}

backend www01 {
    .host = "192.0.2.14";
    .port = "80";
}
\end{verbatim}

Il est ensuite possible de grouper ces backends dans un cluster, appelé
\emph{director} dans le langage de Varnish:
\begin{verbatim}
director baz round-robin {
    { .backend = www00; }
    { .backend = www01; }
}
\end{verbatim}

Et enfin, on indique dans quel cas il sera utilisé (dans l'exemple il sera
utilisé dans tous les cas, pas de condition):
\begin{verbatim}
sub vcl_recv {
    set req.backend = baz;
}
\end{verbatim}

Il s'agit ici de la configuration la plus simple possible. Maintenant, il peut
être intéressant d'ajuster certains paramètres:
\begin{itemize}
  \item Dans l'exemple ci dessus, le director est en mode round-robin. Le trafic
    est alors réparti équitablement entre les backend. On peut définir un
    «poids» pour chacun des backends, afin de jouer sur la répartition du trafic
    entre eux:
    \begin{verbatim}
director baz random {
    {
        .backend = www00;
        .weight = 6;
    }
    {
        .backend = www01;
        .weight = 4;
    }
}
    \end{verbatim}
    Pour cela, on change le mode du director pour \emph{random}.
  \item Une directive importante est \texttt{.max\_connections}. Elle permet de
    limiter le nombre de connexions concurrentes envoyées sur un backend. En en
    positionnant une sur chacun des backends, Varnish saura qu'il devra ignorer
    le backend saturé et en choisir un autre, afin de ne pas le surchargé.
    \begin{verbatim}
backend www00 {
    .host = "192.0.2.8";
    .port = "80";
    .max_connections = 80;
}
\end{verbatim}

  \item Il est possible également de répartir les requêtes sur les backends
    suivant des critères sur la requête. Le mode du director à utiliser est
    alors \emph{client}:
    \begin{verbatim}
director baz client {
    { .backend = www00; }
    { .backend = www01; }
}

sub vcl_recv {
   set req.backend = baz;
   set client.identity = req.ip;
}
\end{verbatim}
Dans l'exemple ci-dessus, le critère utilisé est l'IP du client
(\texttt{client.identity = req.ip}. Les autres critères possibles sont le
user-agent (\texttt{req.http.user-agent}), l'URL (\texttt{client.url}) ou encore
un cookie de session (\texttt{req.http.cookie}).

\end{itemize}

\subsection{Gestion du failover}

Nous avons vu que Varnish était capable de gérer plusieurs backend en contrôlant
la répartition des requêtes sur chacun d'eux. Il est aussi capable de détecter
une panne sur un backend, et de prendre en compte cet évènement pour modifier
son comportement: utiliser un autre backend, ou renvoyer ces fichiers en cache.

\subsubsection{Détection lors de la requête}

Il est possible d'ajuster différent paramètres indiquant le temps d'attente
maximum toléré par Varnish lors de l'interrogation d'un backend:
\begin{verbatim}
backend www00 {
    .host = "192.0.2.6";
    .port = "80";
    .connect_timeout = 1s;
    .first_byte_timeout = 3s;
    .between_bytes_timeout = 2s;
}
\end{verbatim}
Les directives sont assez explicites. Passé ce délai, Varnish ira interroger le
backend suivant.

\subsubsection{Surveillance périodique des backends}

La méthode précédente est essentielle, mais pas suffisante en elle-même; en
effet, même si Varnish basculera sur un autre backend en cas de saturation du
premier, le traitement de la requête sera ralenti par l'expiration des délais
d'attente. D'autre part, une erreur HTTP 5xx par exemple sur un backend
n'empêchera pas Varnish de continuer à lui envoyer des requêtes.

Varnish offre la possibilité de surveiller régulièrement ses backends et les
marquer éventuellement comme «down». Pour cela, il est nécessaire de lui
indiquer comment les surveiller, avec la directive
\texttt{.probe}:
\begin{verbatim}
backend www00 {
    .host = "192.0.2.6";
    .port = "80";
    .probe = {
     .request = "GET / HTTP/1.1"
             "Host: www.example.com"
             "User-Agent: test Varnish"
             "Connection: close"
             "Accept-Encoding: text/html" ;
     .timeout = 1s;
     .interval = 5s;
     .window = 8;
     .threshold = 6;
   }
}
\end{verbatim}
On définit la requête HTTP que Varnish devra envoyer au backend, ainsi que
diverses directives. Le backend devra obligatoirement retourné un code HTTP 200,
il sera considéré comme «down» si ce n'est pas le cas.

Dans l'exemple ci-dessus, les checks sont fait sur un intervalle de 5 secondes,
et s'attend à avoir une réponse en moins d'une seconde. Les directives
\texttt{.window} et \texttt{.threshold} permet de définir un cycle d'hystérésis:
pour que le backend soit vu comme étant «down», il faut que, sur une quantité de
8, 6 checks ont échoué. Et inversement, pour qu'il repasse «up», il faut que 6
checks sur les 8 ont réussi.

\subsubsection{Saint mode}

\section{Administration}

\section{Gestion des logs}