willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 1 | ------------------- |
Willy Tarreau | 94b4591 | 2006-05-31 06:40:15 +0200 | [diff] [blame] | 2 | HAProxy |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 3 | Manuel de référence |
| 4 | ------------------- |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 5 | version 1.3.2 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 6 | willy tarreau |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 7 | 2006/09/03 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 8 | |
Willy Tarreau | a080eca | 2009-10-14 20:30:15 +0200 | [diff] [blame] | 9 | |
| 10 | !!!! NOTE: CE DOCUMENT EST PERIME !!!! |
| 11 | |
| 12 | Veuillez utiliser le fichier "configuration.txt" situé dans le même |
| 13 | répertoire, ou télécharger une version à jour à l'emplacement ci-dessous : |
| 14 | |
Willy Tarreau | be6008f | 2009-10-14 22:22:03 +0200 | [diff] [blame] | 15 | http://haproxy.1wt.eu/download/1.4/doc/configuration.txt |
Willy Tarreau | a080eca | 2009-10-14 20:30:15 +0200 | [diff] [blame] | 16 | |
| 17 | |
willy tarreau | b719f00 | 2005-12-17 12:55:07 +0100 | [diff] [blame] | 18 | ================ |
| 19 | | Introduction | |
| 20 | ================ |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 21 | |
Willy Tarreau | 94b4591 | 2006-05-31 06:40:15 +0200 | [diff] [blame] | 22 | HAProxy est un relais TCP/HTTP offrant des facilités d'intégration en |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 23 | environnement hautement disponible. En effet, il est capable de : |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 24 | - effectuer un aiguillage statique défini par des cookies ; |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 25 | - effectuer une répartition de charge avec création de cookies pour assurer |
| 26 | la persistence de session ; |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 27 | - fournir une visibilité externe de son état de santé ; |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 28 | - s'arrêter en douceur sans perte brutale de service ; |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 29 | - modifier/ajouter/supprimer des en-têtes dans la requête et la réponse ; |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 30 | - interdire des requêtes qui vérifient certaines conditions ; |
| 31 | - utiliser des serveurs de secours lorsque les serveurs principaux sont hors |
| 32 | d'usage. |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 33 | - maintenir des clients sur le bon serveur serveur d'application en fonction |
| 34 | de cookies applicatifs. |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 35 | - fournir des rapports d'état en HTML à des utilisateurs authentifiés, à |
| 36 | travers des URI de l'application interceptées. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 37 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 38 | Il requiert peu de ressources, et son architecture événementielle mono- |
| 39 | processus lui permet facilement de gérer plusieurs milliers de connexions |
| 40 | simultanées sur plusieurs relais sans effondrer le système. |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 41 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 42 | |
| 43 | =========================== |
| 44 | | Paramètres de lancement | |
| 45 | =========================== |
| 46 | |
| 47 | Les options de lancement sont peu nombreuses : |
| 48 | |
| 49 | -f <fichier de configuration> |
| 50 | -n <nombre maximal total de connexions simultanées> |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 51 | = 'maxconn' dans la section 'global' |
| 52 | -N <nombre maximal de connexions simultanées par instance> |
| 53 | = 'maxconn' dans les sections 'listen' ou 'default' |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 54 | -d active le mode debug |
| 55 | -D passe en daemon |
Marc-Antoine Perennou | 992709b | 2013-02-12 10:53:52 +0100 | [diff] [blame] | 56 | -Ds passe en daemon systemd |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 57 | -q désactive l'affichage de messages sur la sortie standard. |
| 58 | -V affiche les messages sur la sortie standard, même si -q ou 'quiet' sont |
| 59 | spécifiés. |
| 60 | -c vérifie le fichier de configuration puis quitte avec un code de retour 0 |
| 61 | si aucune erreur n'a été trouvée, ou 1 si une erreur de syntaxe a été |
| 62 | détectée. |
willy tarreau | fe2c5c1 | 2005-12-17 14:14:34 +0100 | [diff] [blame] | 63 | -p <fichier> indique au processus père qu'il doit écrire les PIDs de ses |
| 64 | fils dans ce fichier en mode démon. |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 65 | -sf specifie une liste de PIDs auxquels envoyer un signal FINISH |
| 66 | -st specifie une liste de PIDs auxquels envoyer un signal TERMINATE |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 67 | -s affiche les statistiques (si option compilée) |
| 68 | -l ajoute des informations aux statistiques |
Willy Tarreau | de99e99 | 2007-04-16 00:53:59 +0200 | [diff] [blame] | 69 | -dk désactive l'utilisation de kqueue() |
| 70 | -ds désactive l'utilisation de epoll() speculatif |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 71 | -de désactive l'utilisation de epoll() |
| 72 | -dp désactive l'utilisation de poll() |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 73 | -db désactive la mise en arrière-plan (utile pour débugger) |
| 74 | -m <megs> applique une limitation de <megs> Mo d'utilisation mémoire |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 75 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 76 | Le nombre maximal de connexion simultanées par proxy est le paramètre par |
| 77 | défaut pour les proxies pour lesquels ce paramètre n'est pas précisé dans le |
| 78 | fichier de configuration. Il s'agit du paramètre 'maxconn' dans les sections |
| 79 | 'listen'. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 80 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 81 | Le nombre maximal total de connexions simultanées limite le nombre de |
| 82 | connexions TCP utilisables à un instant donné par le processus, tous proxies |
| 83 | confondus. Ce paramètre remplace le paramètre 'maxconn' de la section 'global'. |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 84 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 85 | Le mode debug correspond à l'option 'debug' de la section 'global'. Dans ce |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 86 | mode, toutes les connexions, déconnexions, et tous les échanges d'en-têtes HTTP |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 87 | sont affichés. |
| 88 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 89 | Pour debugger, l'option '-db' est très pratique car elle désactive |
| 90 | temporairement le mode daemon et le mode multi-processus. Le service peut alors |
| 91 | être arrêté par un simple appui sur Ctrl-C, sans avoir à modifier la |
| 92 | configuration ni à activer le mode debug complet. |
| 93 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 94 | Les statistiques ne sont disponibles que si le programme a été compilé avec |
| 95 | l'option "STATTIME". Il s'agit principalement de données brutes n'ayant |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 96 | d'utilité que lors de benchmarks par exemple, et sont amenées à disparaitre. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 97 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 98 | Les paramètres '-st' et '-sf' sont utilisés pour la reconfiguration à chaud. |
| 99 | Voir la section à ce sujet. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 100 | |
| 101 | ============================ |
| 102 | | Fichier de configuration | |
| 103 | ============================ |
| 104 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 105 | Structure |
| 106 | ========= |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 107 | |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 108 | L'analyseur du fichier de configuration ignore des lignes vides, les espaces, |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 109 | les tabulations, et tout ce qui est compris entre le symbole '#' (s'il n'est |
| 110 | pas précédé d'un '\'), et la fin de la ligne, ce qui constitue un commentaire. |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 111 | |
| 112 | Le fichier de configuration est découpé en sections répérées par des mots clés |
| 113 | tels que : |
| 114 | |
| 115 | - 'global' |
| 116 | - 'listen' |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 117 | - 'defaults' |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 118 | |
| 119 | Tous les paramètres font référence à la section définie par le dernier mot clé |
| 120 | reconnu. |
| 121 | |
| 122 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 123 | 1) Paramètres globaux |
| 124 | ===================== |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 125 | |
| 126 | Il s'agit des paramètres agissant sur le processus, ou bien sur l'ensemble des |
| 127 | proxies. Ils sont tous spécifiés dans la section 'global'. Les paramètres |
| 128 | supportés sont : |
| 129 | |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 130 | - log <adresse> <catégorie> [niveau_max] |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 131 | - maxconn <nombre> |
| 132 | - uid <identifiant> |
| 133 | - gid <identifiant> |
Willy Tarreau | 95c20ac | 2007-03-25 15:39:23 +0200 | [diff] [blame] | 134 | - user <nom d'utilisateur> |
| 135 | - group <nom de groupe> |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 136 | - chroot <répertoire> |
| 137 | - nbproc <nombre> |
| 138 | - daemon |
| 139 | - debug |
Willy Tarreau | de99e99 | 2007-04-16 00:53:59 +0200 | [diff] [blame] | 140 | - nokqueue |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 141 | - noepoll |
| 142 | - nopoll |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 143 | - quiet |
willy tarreau | fe2c5c1 | 2005-12-17 14:14:34 +0100 | [diff] [blame] | 144 | - pidfile <fichier> |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 145 | - ulimit-n <nombre> |
Willy Tarreau | 1db3771 | 2007-06-03 17:16:49 +0200 | [diff] [blame] | 146 | - tune.maxpollevents <nombre> |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 147 | |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 148 | |
| 149 | 1.1) Journalisation des événements |
| 150 | ---------------------------------- |
| 151 | La plupart des événements sont journalisés : démarrages, arrêts, disparition et |
| 152 | apparition de serveurs, connexions, erreurs. Tous les messages sont envoyés en |
| 153 | syslog vers un ou deux serveurs. La syntaxe est la suivante : |
| 154 | |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 155 | log <adresse_ip> <catégorie> [niveau_max] |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 156 | |
| 157 | Les connexions sont envoyées en niveau "info". Les démarrages de service et de |
| 158 | serveurs seront envoyés en "notice", les signaux d'arrêts en "warning" et les |
| 159 | arrêts définitifs de services et de serveurs en "alert". Ceci est valable aussi |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 160 | bien pour les proxies que pour les serveurs testés par les proxies. Le |
| 161 | paramètre optionnel <niveau_max> définit le niveau maximal de traces émises |
| 162 | parmi les 8 valeurs suivantes : |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 163 | emerg, alert, crit, err, warning, notice, info, debug |
| 164 | |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 165 | Par compatibilité avec les versions 1.1.16 et antérieures, la valeur par défaut |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 166 | est "debug" si l'option n'est pas précisée. |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 167 | |
| 168 | Les catégories possibles sont : |
| 169 | kern, user, mail, daemon, auth, syslog, lpr, news, |
| 170 | uucp, cron, auth2, ftp, ntp, audit, alert, cron2, |
| 171 | local0, local1, local2, local3, local4, local5, local6, local7 |
| 172 | |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 173 | Conformément à la RFC3164, les messages émis sont limités à 1024 caractères. |
| 174 | |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 175 | Exemple : |
| 176 | --------- |
| 177 | global |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 178 | log 192.168.2.200 local3 |
| 179 | log 127.0.0.1 local4 notice |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 180 | |
| 181 | 1.2) limitation du nombre de connexions |
| 182 | --------------------------------------- |
| 183 | Il est possible et conseillé de limiter le nombre global de connexions par |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 184 | processus à l'aide du mot clé global 'maxconn'. Les connexions sont comprises |
| 185 | au sens 'acceptation de connexion', donc il faut s'attendre en règle général à |
| 186 | avoir un peu plus du double de sessions TCP que le maximum de connexions fixé. |
| 187 | C'est important pour fixer le paramètre 'ulimit -n' avant de lancer le proxy. |
| 188 | Pour comptabiliser le nombre de sockets nécessaires, il faut prendre en compte |
| 189 | ces paramètres : |
| 190 | |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 191 | - 1 socket par connexion entrante |
| 192 | - 1 socket par connexion sortante |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 193 | - 1 socket par couple adresse/port d'écoute par proxy |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 194 | - 1 socket pour chaque serveur en cours de health-check |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 195 | - 1 socket pour les logs (tous serveurs confondus) |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 196 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 197 | Dans le cas où chaque proxy n'écoute que sur un couple adresse/port, |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 198 | positionner la limite du nombre de descripteurs de fichiers (ulimit -n) à |
| 199 | (2 * maxconn + nbproxy + nbserveurs + 1). A partir des versions 1.1.32/1.2.6, |
| 200 | il est possible de spécifier cette limite dans la configuration à l'aide du |
| 201 | mot-clé global 'ulimit-n', à condition bien entendu que le proxy ait été |
| 202 | démarré sous le compte root (ou avec des droits suffisants pour élever le |
| 203 | nombre de descripteurs de fichiers). Cette solution met un terme au problème |
| 204 | récurrent d'incertitude de l'adéquation entre les limites systèmes lors de la |
| 205 | dernière relance du proxessus et les limites en nombre de connexions. Noter que |
| 206 | cette limite s'applique par processus. |
| 207 | |
| 208 | Exemple : |
| 209 | --------- |
| 210 | global |
| 211 | maxconn 32000 |
| 212 | ulimit-n 65536 |
| 213 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 214 | |
| 215 | 1.3) Diminution des privilèges |
| 216 | ------------------------------ |
| 217 | Afin de réduire les risques d'attaques dans le cas où une faille non identifiée |
| 218 | serait exploitée, il est possible de diminuer les privilèges du processus, et |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 219 | de l'isoler dans un répertoire sans risque. |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 220 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 221 | Dans la section 'global', le paramètre 'uid' permet de spécifier un identifiant |
| 222 | numérique d'utilisateur. La valeur 0, correspondant normalement au super- |
| 223 | utilisateur, possède ici une signification particulière car elle indique que |
| 224 | l'on ne souhaite pas changer cet identifiant et conserver la valeur courante. |
| 225 | C'est la valeur par défaut. De la même manière, le paramètre 'gid' correspond à |
| 226 | un identifiant de groupe, et utilise par défaut la valeur 0 pour ne rien |
Willy Tarreau | 95c20ac | 2007-03-25 15:39:23 +0200 | [diff] [blame] | 227 | changer. Dans le cas où il ne serait pas possible de spécifier un identifiant |
| 228 | numérique pour l'uid, il est possible de spécifier un nom d'utilisateur après |
| 229 | le mot-clé 'user'. De la même manière, il est possible de préciser un nom de |
| 230 | groupe après le mot-clé 'group'. |
| 231 | |
| 232 | Il est particulièrement déconseillé d'utiliser des comptes génériques tels que |
| 233 | 'nobody' car cette pratique revient à utiliser 'root' si d'autres processus |
| 234 | utilisent les mêmes identifiants. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 235 | |
| 236 | Le paramètre 'chroot' autorise à changer la racine du processus une fois le |
| 237 | programme lancé, de sorte que ni le processus, ni l'un de ses descendants ne |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 238 | puissent remonter de nouveau à la racine. Ce type de cloisonnement (chroot) est |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 239 | généralement contournable sur certains OS (Linux, Solaris) pour peu que |
| 240 | l'attaquant possède des droits 'root' et soit en mesure d'utiliser ou de créer |
| 241 | un répertoire. Aussi, il est important d'utiliser un répertoire spécifique au |
| 242 | service pour cet usage, et de ne pas mutualiser un même répertoire pour |
| 243 | plusieurs services de nature différente. Pour rendre l'isolement plus robuste, |
| 244 | il est conseillé d'utiliser un répertoire vide, sans aucun droit, et de changer |
| 245 | l'uid du processus de sorte qu'il ne puisse rien faire dans ledit répertoire. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 246 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 247 | Remarque importante : |
| 248 | --------------------- |
| 249 | Dans le cas où une telle faille serait mise en évidence, il est fort probable |
| 250 | que les premières tentatives de son exploitation provoquent un arrêt du |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 251 | programme, à cause d'un signal de type 'Segmentation Fault', 'Bus Error' ou |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 252 | encore 'Illegal Instruction'. Même s'il est vrai que faire tourner le serveur |
| 253 | en environnement limité réduit les risques d'intrusion, il est parfois bien |
| 254 | utile dans ces circonstances de connaître les conditions d'apparition du |
| 255 | problème, via l'obtention d'un fichier 'core'. La plupart des systèmes, pour |
| 256 | des raisons de sécurité, désactivent la génération du fichier 'core' après un |
| 257 | changement d'identifiant pour le processus. Il faudra donc soit lancer le |
| 258 | processus à partir d'un compte utilisateur aux droits réduits (mais ne pouvant |
| 259 | pas effectuer le chroot), ou bien le faire en root sans réduction des droits |
| 260 | (uid 0). Dans ce cas, le fichier se trouvera soit dans le répertoire de |
| 261 | lancement, soit dans le répertoire spécifié après l'option 'chroot'. Ne pas |
| 262 | oublier la commande suivante pour autoriser la génération du fichier avant de |
| 263 | lancer le programme : |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 264 | |
| 265 | # ulimit -c unlimited |
willy tarreau | a159808 | 2005-12-17 13:08:06 +0100 | [diff] [blame] | 266 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 267 | Exemple : |
| 268 | --------- |
| 269 | |
Willy Tarreau | 95c20ac | 2007-03-25 15:39:23 +0200 | [diff] [blame] | 270 | # with uid/gid |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 271 | global |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 272 | uid 30000 |
| 273 | gid 30000 |
| 274 | chroot /var/chroot/haproxy |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 275 | |
Willy Tarreau | 95c20ac | 2007-03-25 15:39:23 +0200 | [diff] [blame] | 276 | # with user/group |
| 277 | global |
| 278 | user haproxy |
| 279 | group public |
| 280 | chroot /var/chroot/haproxy |
| 281 | |
| 282 | |
willy tarreau | fe2c5c1 | 2005-12-17 14:14:34 +0100 | [diff] [blame] | 283 | 1.4) Modes de fonctionnement |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 284 | ---------------------------- |
| 285 | Le service peut fonctionner dans plusieurs modes : |
| 286 | - avant- / arrière-plan |
| 287 | - silencieux / normal / debug |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 288 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 289 | Le mode par défaut est normal, avant-plan, c'est à dire que le programme ne |
| 290 | rend pas la main une fois lancé. Il ne faut surtout pas le lancer comme ceci |
| 291 | dans un script de démarrage du système, sinon le système ne finirait pas son |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 292 | initialisation. Il faut le mettre en arrière-plan, de sorte qu'il rende la main |
| 293 | au processus appelant. C'est ce que fait l'option 'daemon' de la section |
| 294 | 'global', et qui est l'équivalent du paramètre '-D' de la ligne de commande. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 295 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 296 | Le paramètre de ligne de commande '-db' inhibe les options globales 'daemon' |
| 297 | et 'nbproc' pour faire fonctionner le processus en mode normal, avant-plan. |
| 298 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 299 | Par ailleurs, certains messages d'alerte sont toujours envoyés sur la sortie |
| 300 | standard, même en mode 'daemon'. Pour ne plus les voir ailleurs que dans les |
| 301 | logs, il suffit de passer en mode silencieux par l'ajout de l'option 'quiet'. |
| 302 | Cette option n'a pas d'équivalent en ligne de commande. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 303 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 304 | Enfin, le mode 'debug' permet de diagnostiquer les origines de certains |
| 305 | problèmes en affichant les connexions, déconnexions et échanges d'en-têtes HTTP |
| 306 | entre les clients et les serveurs. Ce mode est incompatible avec les options |
| 307 | 'daemon' et 'quiet' pour des raisons de bon sens. |
| 308 | |
willy tarreau | fe2c5c1 | 2005-12-17 14:14:34 +0100 | [diff] [blame] | 309 | 1.5) Accroissement de la capacité de traitement |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 310 | ----------------------------------------------- |
| 311 | Sur des machines multi-processeurs, il peut sembler gâché de n'utiliser qu'un |
| 312 | processeur pour effectuer les tâches de relayage, même si les charges |
| 313 | nécessaires à saturer un processeur actuel sont bien au-delà des ordres de |
| 314 | grandeur couramment rencontrés. Cependant, pour des besoins particuliers, le |
| 315 | programme sait démarrer plusieurs processus se répartissant la charge de |
| 316 | travail. Ce nombre de processus est spécifié par le paramètre 'nbproc' de la |
| 317 | section 'global'. Sa valeur par défaut est naturellement 1. Ceci ne fonctionne |
willy tarreau | 4302f49 | 2005-12-18 01:00:37 +0100 | [diff] [blame] | 318 | qu'en mode 'daemon'. Un usage déjà rencontré pour ce paramètre fut de dépasser |
| 319 | la limite de nombre de descripteurs de fichiers allouée par processus sous |
| 320 | Solaris. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 321 | |
| 322 | Exemple : |
| 323 | --------- |
| 324 | |
| 325 | global |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 326 | daemon |
| 327 | quiet |
| 328 | nbproc 2 |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 329 | |
willy tarreau | fe2c5c1 | 2005-12-17 14:14:34 +0100 | [diff] [blame] | 330 | 1.6) Simplification de la gestion des processus |
| 331 | ----------------------------------------------- |
| 332 | Haproxy supporte dorénavant la notion de fichiers de pid (-> pidfiles). Si le |
| 333 | paramètre '-p' de ligne de commande, ou l'option globale 'pidfile' sont suivis |
| 334 | d'un nom de fichier, alors ce fichier sera supprimé puis recréé et contiendra |
| 335 | le numéro de PID des processus fils, à raison d'un par ligne (valable |
| 336 | uniquement en mode démon). Ce fichier n'est PAS relatif au cloisonnement chroot |
| 337 | afin de rester compatible avec un répertoire protégé en lecture seule. Il |
| 338 | appartiendra à l'utilisateur ayant lancé le processus, et disposera des droits |
| 339 | 0644. |
| 340 | |
| 341 | Exemple : |
| 342 | --------- |
| 343 | |
| 344 | global |
| 345 | daemon |
| 346 | quiet |
| 347 | nbproc 2 |
| 348 | pidfile /var/run/haproxy-private.pid |
| 349 | |
| 350 | # pour stopper seulement ces processus parmi d'autres : |
| 351 | # kill $(</var/run/haproxy-private.pid) |
| 352 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 353 | # pour recharger une configuration avec un impact minimal sur le service, |
| 354 | # et sans casser les sessions existantes : |
Willy Tarreau | 10806d5 | 2007-09-09 23:49:18 +0200 | [diff] [blame] | 355 | # haproxy -f haproxy.cfg -p /var/run/haproxy-private.pid -sf $(</var/run/haproxy-private.pid) |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 356 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 357 | 1.7) Mécanismes de traitements des événements |
| 358 | --------------------------------------------- |
| 359 | A partir de la version 1.2.5, haproxy supporte les mécanismes poll() et |
| 360 | epoll(). Sur les systems où select() est limité par FD_SETSIZE (comme Solaris), |
| 361 | poll() peut être une alternative intéressante. Des tests de performance |
| 362 | montrent que les performances de poll() ne décroissent pas aussi vite que le |
| 363 | nombre de sockets augmente, ce qui en fait une solution sûre pour les fortes |
| 364 | charges. Cela dit, Soalris utilise déjà poll() pour émuler select(), donc tant |
| 365 | que le nombre de sockets ne dépasse pas FD_SETSIZE, poll() ne devrait pas |
| 366 | apporter de performances supplémentaires. Sur les systèmes à base Linux |
| 367 | incluant le patch epoll() (ou tous les Linux 2.6), haproxy utilisera epoll() |
| 368 | qui est extrèmement rapide indépendamment du nombre de sockets. Les tests sur |
| 369 | haproxy ont montré une performance constante de 1 à 40000 sessions simultanées. |
Willy Tarreau | de99e99 | 2007-04-16 00:53:59 +0200 | [diff] [blame] | 370 | La version 1.3.9 a introduit le support de kqueue() pour FreeBSD/OpenBSD, ainsi |
| 371 | qu'une variante appelée "speculative epoll()" consistant à tenter d'effectuer |
| 372 | les opérations d'entrées/sorties avant de chaîner les événements par les appels |
| 373 | système. |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 374 | |
Willy Tarreau | 1db3771 | 2007-06-03 17:16:49 +0200 | [diff] [blame] | 375 | Afin d'optimiser la latence, il est désormais possible de limiter le nombre |
| 376 | d'événements remontés à chaque appel. La limite par défaut est fixée à 200. Si |
| 377 | une latence plus petite est recherchée, il peut être justifié d'abaisser cette |
| 378 | limite par l'utilisation du paramètre 'tune.maxpollevents' dans la section |
| 379 | 'global'. L'augmenter permettra d'économiser un peu le processeur en présence |
| 380 | de très grands nombres de connexions simultanées. |
| 381 | |
Willy Tarreau | de99e99 | 2007-04-16 00:53:59 +0200 | [diff] [blame] | 382 | Haproxy utilisera kqueue() ou speculative epoll() lorsque ce sera disponible, |
| 383 | puis epoll(), et se repliera sur poll(), puis en dernier lieu sur select(). |
| 384 | Cependant, si pour une raison quelconque il s'avérait nécessaire de désactiver |
| 385 | epoll() ou poll() (p.ex: à cause d'un bug ou juste pour comparer les |
| 386 | performances), de nouvelles options globales ont été ajoutées dans ce but : |
Willy Tarreau | e9f49e7 | 2012-11-11 17:42:00 +0100 | [diff] [blame] | 387 | 'nokqueue', 'noepoll' et 'nopoll'. |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 388 | |
| 389 | Exemple : |
| 390 | --------- |
| 391 | global |
| 392 | # utiliser seulement select() |
| 393 | noepoll |
| 394 | nopoll |
Willy Tarreau | 1db3771 | 2007-06-03 17:16:49 +0200 | [diff] [blame] | 395 | tune.maxpollevents 100 |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 396 | |
| 397 | Remarque : |
| 398 | ---------- |
| 399 | Dans le but d'assurer une portabilité maximale des configurations, ces options |
| 400 | sont acceptées et ignorées si les mécanismes poll() ou epoll() n'ont pas été |
| 401 | activés lors de la compilation. |
| 402 | |
| 403 | Afin de simplifier la résolution de problèmes, le paramètre '-de' en ligne de |
Willy Tarreau | de99e99 | 2007-04-16 00:53:59 +0200 | [diff] [blame] | 404 | commande désactive epoll(), le paramètre '-dp' désactive poll(), '-dk' kqueue() |
| 405 | et '-ds' désactive speculative epoll(). Ils sont respectivement équivalents à |
Willy Tarreau | e9f49e7 | 2012-11-11 17:42:00 +0100 | [diff] [blame] | 406 | 'noepoll', 'nopoll', et 'nokqueue'. |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 407 | |
| 408 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 409 | 2) Définition d'un service en écoute |
| 410 | ==================================== |
| 411 | |
| 412 | Les sections de service débutent par le mot clé "listen" : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 413 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 414 | listen <nom_instance> [ <adresse_IP>:<plage_ports>[,...] ] |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 415 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 416 | - <nom_instance> est le nom de l'instance décrite. Ce nom sera envoyé dans les |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 417 | logs, donc il est souhaitable d'utiliser un nom relatif au service relayé. |
| 418 | Aucun test n'est effectué concernant l'unicité de ce nom, qui n'est pas |
| 419 | obligatoire, mais fortement recommandée. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 420 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 421 | - <adresse_IP> est l'adresse IP sur laquelle le relais attend ses connexions. |
| 422 | L'absence d'adresse ainsi que l'adresse 0.0.0.0 signifient que les connexions |
| 423 | pourront s'effectuer sur toutes les adresses de la machine. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 424 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 425 | - <plage_ports> correspond soit à un port, soit à une plage de ports sur |
| 426 | lesquels le relais acceptera des connexions pour l'adresse IP spécifiée. |
| 427 | Cette plage peut être : |
| 428 | - soit un port numérique (ex: '80') |
| 429 | - soit une plage constituée de deux valeurs séparées par un tiret |
| 430 | (ex: '2000-2100') représentant les extrémités incluses dans la |
| 431 | plage. |
| 432 | Il faut faire attention à l'usage des plages, car chaque combinaison |
| 433 | <adresse_IP>:<port> consomme une socket, donc un descripteur de fichier. |
| 434 | Le couple <adresse_IP>:<port> doit être unique pour toutes les instances |
| 435 | d'une même machine. L'attachement à un port inférieur à 1024 nécessite un |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 436 | niveau de privilège particulier lors du lancement du programme |
| 437 | (indépendamment du paramètre 'uid' de la section 'global'). |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 438 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 439 | - le couple <adresse_IP>:<plage_ports> peut être répété indéfiniment pour |
| 440 | demander au relais d'écouter également sur d'autres adresses et/ou d'autres |
| 441 | plages de ports. Pour cela, il suffit de séparer les couples par une virgule. |
| 442 | |
| 443 | Exemples : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 444 | --------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 445 | listen http_proxy :80 |
| 446 | listen x11_proxy 127.0.0.1:6000-6009 |
| 447 | listen smtp_proxy 127.0.0.1:25,127.0.0.1:587 |
| 448 | listen ldap_proxy :389,:663 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 449 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 450 | Si toutes les adresses ne tiennent pas sur une ligne, il est possible d'en |
| 451 | rajouter à l'aide du mot clé 'bind'. Dans ce cas, il n'est même pas nécessaire |
| 452 | de spécifier la première adresse sur la ligne listen, ce qui facilite parfois |
| 453 | l'écriture de configurations : |
| 454 | |
| 455 | bind [ <adresse_IP>:<plage_ports>[,...] ] |
| 456 | |
| 457 | Exemples : |
| 458 | ---------- |
| 459 | listen http_proxy |
| 460 | bind :80,:443 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 461 | bind 10.0.0.1:10080,10.0.0.1:10443 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 462 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 463 | 2.1) Inhibition d'un service |
| 464 | ---------------------------- |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 465 | Un service peut être désactivé pour des besoins de maintenance, sans avoir à |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 466 | commenter toute une partie du fichier. Il suffit de positionner le mot clé |
| 467 | "disabled" dans sa section : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 468 | |
| 469 | listen smtp_proxy 0.0.0.0:25 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 470 | disabled |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 471 | |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 472 | Remarque: le mot clé 'enabled' permet de réactiver un service préalablement |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 473 | désactivé par le mot clé 'disabled', par exemple à cause d'une |
| 474 | configuration par défaut. |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 475 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 476 | 2.2) Mode de fonctionnement |
| 477 | --------------------------- |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 478 | Un service peut fonctionner dans trois modes différents : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 479 | - TCP |
| 480 | - HTTP |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 481 | - état de santé |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 482 | |
| 483 | Mode TCP |
| 484 | -------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 485 | Dans ce mode, le service relaye, dès leur établissement, les connexions TCP |
| 486 | vers un ou plusieurs serveurs. Aucun traitement n'est effectué sur le flux. Il |
| 487 | s'agit simplement d'une association |
| 488 | source<adresse:port> -> destination<adresse:port>. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 489 | Pour l'utiliser, préciser le mode TCP sous la déclaration du relais. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 490 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 491 | Exemple : |
| 492 | --------- |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 493 | listen smtp_proxy 0.0.0.0:25 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 494 | mode tcp |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 495 | |
| 496 | Mode HTTP |
| 497 | --------- |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 498 | Dans ce mode, le service relaye les connexions TCP vers un ou plusieurs |
| 499 | serveurs, une fois qu'il dispose d'assez d'informations pour en prendre la |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 500 | décision. Les en-têtes HTTP sont analysés pour y trouver un éventuel cookie, et |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 501 | certains d'entre-eux peuvent être modifiés par le biais d'expressions |
| 502 | régulières. Pour activer ce mode, préciser le mode HTTP sous la déclaration du |
| 503 | relais. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 504 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 505 | Exemple : |
| 506 | --------- |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 507 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 508 | mode http |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 509 | |
| 510 | Mode supervision |
| 511 | ---------------- |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 512 | Il s'agit d'un mode offrant à un composant externe une visibilité de l'état de |
| 513 | santé du service. Il se contente de retourner "OK" à tout client se connectant |
| 514 | sur son port. Il peut être utilisé avec des répartiteurs de charge évolués pour |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 515 | déterminer quels sont les services utilisables. Si l'option 'httpchk' est |
| 516 | activée, alors la réponse changera en 'HTTP/1.0 200 OK' pour satisfaire les |
| 517 | attentes de composants sachant tester en HTTP. Pour activer ce mode, préciser |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 518 | le mode HEALTH sous la déclaration du relais. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 519 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 520 | Exemple : |
| 521 | --------- |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 522 | # réponse simple : 'OK' |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 523 | listen health_check 0.0.0.0:60000 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 524 | mode health |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 525 | |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 526 | # réponse HTTP : 'HTTP/1.0 200 OK' |
| 527 | listen http_health_check 0.0.0.0:60001 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 528 | mode health |
| 529 | option httpchk |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 530 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 531 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 532 | 2.2.1 Supervision |
| 533 | ----------------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 534 | Les versions 1.1.32 et 1.2.6 apportent une nouvelle solution pour valider le |
| 535 | bon fonctionnement du proxy sans perturber le service. Le mot-clé 'monitor-net' |
| 536 | a été créé dans le butd de spécifier un réseau d'équipements qui ne PEUVENT PAS |
| 537 | utiliser le service pour autre chose que des tests de fonctionnement. C'est |
| 538 | particulièrement adapté aux proxies TCP, car cela empêche le proxy de relayer |
| 539 | des établissements de connexion émis par un outil de surveillance. |
| 540 | |
| 541 | Lorsque c'est utilisé sur un proxy TCP, la connexion est acceptée puis refermée |
| 542 | et rien n'est logué. C'est suffisant pour qu'un répartiteur de charge en amont |
| 543 | détecte que le service est disponible. |
| 544 | |
| 545 | Lorsque c'est utilisé sur un proxy HTTP, la connexion est acceptée, rien n'est |
| 546 | logué, puis la réponse suivante est envoyée et la session refermée : |
| 547 | "HTTP/1.0 200 OK". C'est normalement suffisant pour qu'un répartiteur de charge |
| 548 | HTTP en amont détecte le service comme opérationnel, aussi bien à travers des |
| 549 | tests TCP que HTTP. |
| 550 | |
| 551 | Les proxies utilisant le mot-clé 'monitor-net' peuvent accessoirement se passer |
| 552 | de l'option 'dontlognull', ce qui permettra de loguer les connexions vides |
| 553 | émises depuis d'autres adresses que celles du réseau de tests. |
| 554 | |
| 555 | Exemple : |
| 556 | --------- |
| 557 | |
| 558 | listen tse-proxy |
| 559 | bind :3389,:1494,:5900 # TSE, ICA and VNC at once. |
| 560 | mode tcp |
| 561 | balance roundrobin |
| 562 | server tse-farm 192.168.1.10 |
| 563 | monitor-net 192.168.1.252/31 # L4 load-balancers on .252 and .253 |
| 564 | |
| 565 | |
Willy Tarreau | 1c47f85 | 2006-07-09 08:22:27 +0200 | [diff] [blame] | 566 | Lorsque le système effectuant les tests est situé derrière un proxy, le mot-clé |
| 567 | 'monitor-net' n'est pas utilisable du fait que haproxy verra toujours la même |
| 568 | adresse pour le proxy. Pour pallier à cette limitation, la version 1.2.15 a |
| 569 | apporté le mot-clé 'monitor-uri'. Il définit une URI qui ne sera ni retransmise |
| 570 | ni logée, mais pour laquelle haproxy retournera immédiatement une réponse |
| 571 | "HTTP/1.0 200 OK". Cela rend possibles les tests de validité d'une chaîne |
| 572 | reverse-proxy->haproxy en une requête HTTP. Cela peut être utilisé pour valider |
| 573 | une combinaision de stunnel+haproxy à l'aide de tests HTTPS par exemple. Bien |
| 574 | entendu, ce mot-clé n'est valide qu'en mode HTTP, sinon il n'y a pas de notion |
| 575 | d'URI. Noter que la méthode et la version HTTP sont simplement ignorées. |
| 576 | |
| 577 | Exemple : |
| 578 | --------- |
| 579 | |
| 580 | listen stunnel_backend :8080 |
| 581 | mode http |
| 582 | balance roundrobin |
| 583 | server web1 192.168.1.10:80 check |
| 584 | server web2 192.168.1.11:80 check |
| 585 | monitor-uri /haproxy_test |
| 586 | |
| 587 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 588 | 2.3) Limitation du nombre de connexions simultanées |
| 589 | --------------------------------------------------- |
| 590 | Le paramètre "maxconn" permet de fixer la limite acceptable en nombre de |
| 591 | connexions simultanées par proxy. Chaque proxy qui atteint cette valeur cesse |
| 592 | d'écouter jusqu'à libération d'une connexion. Voir plus loin concernant les |
| 593 | limitations liées au système. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 594 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 595 | Exemple : |
| 596 | --------- |
| 597 | listen tiny_server 0.0.0.0:80 |
| 598 | maxconn 10 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 599 | |
| 600 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 601 | 2.4) Arrêt en douceur |
| 602 | --------------------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 603 | Il est possible d'arrêter les services en douceur en envoyant un signal |
willy tarreau | 22739ef | 2006-01-20 20:43:32 +0100 | [diff] [blame] | 604 | SIGUSR1 au processus relais. Tous les services seront alors mis en phase |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 605 | d'arrêt, mais pourront continuer d'accepter des connexions pendant un temps |
| 606 | défini par le paramètre 'grace' (en millisecondes). Cela permet par exemple, |
| 607 | de faire savoir rapidement à un répartiteur de charge qu'il ne doit plus |
| 608 | utiliser un relais, tout en continuant d'assurer le service le temps qu'il |
| 609 | s'en rende compte. |
| 610 | |
| 611 | Remarque : |
| 612 | ---------- |
| 613 | Les connexions actives ne sont jamais cassées. Dans le pire des cas, il faudra |
willy tarreau | 22739ef | 2006-01-20 20:43:32 +0100 | [diff] [blame] | 614 | attendre en plus leur expiration avant l'arrêt total du processus, ou bien tuer |
| 615 | manuellement le processus par l'envoi d'un signal SIGTERM. La valeur par défaut |
| 616 | du paramètre 'grace' est 0 (pas de grâce, arrêt immédiat de l'écoute). |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 617 | |
| 618 | Exemple : |
| 619 | --------- |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 620 | # arrêter en douceur par 'killall -USR1 haproxy' |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 621 | # le service tournera encore 10 secondes après la demande d'arrêt |
| 622 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 623 | mode http |
| 624 | grace 10000 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 625 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 626 | # ce port n'est testé que par un répartiteur de charge. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 627 | listen health_check 0.0.0.0:60000 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 628 | mode health |
| 629 | grace 0 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 630 | |
willy tarreau | 39df2dc | 2006-01-29 21:56:05 +0100 | [diff] [blame] | 631 | A partir de la version 1.2.8, un nouveau mécanisme de reconfiguration à chaud |
willy tarreau | 22739ef | 2006-01-20 20:43:32 +0100 | [diff] [blame] | 632 | a été introduit. Il est désormais possible de mettre les proxies en "pause" en |
| 633 | envoyant un signal SIGTTOU aux processus. Cela désactivera les sockets d'écoute |
| 634 | sans casser les sessions existantes. Suite à cela, l'envoi d'un signal SIGTTIN |
| 635 | réactivera les sockets d'écoute. Ceci est très pratique pour tenter de charger |
| 636 | une nouvelle configuration ou même une nouvelle version de haproxy sans casser |
| 637 | les connexions existantes. Si le rechargement s'effectue correctement, il ne |
| 638 | reste plus qu'à envoyer un signal SIGUSR1 aux anciens processus, ce qui |
| 639 | provoquera leur arrêt immédiat dès que leurs connexions seront terminées ; en |
| 640 | revanche, si le rechargement échoue, il suffit d'envoyer un signal SIGTTIN pour |
| 641 | remettre les ports en écoute et rétablir le service immédiatement. Veuillez |
| 642 | noter que le paramètre 'grace' est ignoré pour le signal SIGTTOU ainsi que le |
| 643 | signal SIGUSR1 une fois le processus en pause. Aussi, il peut s'avérer très |
| 644 | utile de sauver le fichier de pid avant de démarrer une nouvelle instance. |
| 645 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 646 | Ce mécanisme est pleinement exploité à partir de la version 1.2.11 avec les |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 647 | options '-st' et '-sf' (voir ci-dessous). |
| 648 | |
| 649 | 2.4) Reconfiguration à chaud |
| 650 | ---------------------------- |
| 651 | Les paramètres '-st' et '-sf' sont utilisés pour informer des processus |
| 652 | existants que la configuration va être rechargée. Ils recevront le signal |
| 653 | SIGTTOU, leur demandant de libérer les ports en écoute afin que le nouveau |
| 654 | processus puisse les prendre. Si quoi que ce soit se passe mal, le nouveau |
| 655 | processus leur enverra un signal SIGTTIN pour leur indiquer qu'ils peuvent |
| 656 | se remettre en écoute et continuer leur travail. En revanche, si la |
| 657 | configuration se charge correctement, alors ils recevront un signal de demande |
| 658 | de fin de travail en douceur (-sf), ou de terminaison immédiate (-st) qui |
| 659 | coupera les sessions en cours. Un usage typique tel que celui-ci permet de |
| 660 | recharger une configuration sans interruption de service : |
| 661 | |
| 662 | # haproxy -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) |
| 663 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 664 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 665 | 2.5) Temps d'expiration des connexions |
| 666 | -------------------------------------- |
| 667 | Il est possible de paramétrer certaines durées d'expiration au niveau des |
| 668 | connexions TCP. Trois temps indépendants sont configurables et acceptent des |
| 669 | valeurs en millisecondes. Si l'une de ces trois temporisations est dépassée, la |
| 670 | session est terminée à chaque extrémité. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 671 | |
| 672 | - temps d'attente d'une donnée de la part du client, ou de la |
| 673 | possibilité de lui envoyer des données : "clitimeout" : |
| 674 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 675 | # time-out client à 2mn30. |
| 676 | clitimeout 150000 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 677 | |
| 678 | - temps d'attente d'une donnée de la part du serveur, ou de la |
| 679 | possibilité de lui envoyer des données : "srvtimeout" : |
| 680 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 681 | # time-out serveur à 30s. |
| 682 | srvtimeout 30000 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 683 | |
| 684 | - temps d'attente de l'établissement d'une connexion vers un serveur |
| 685 | "contimeout" : |
| 686 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 687 | # on abandonne si la connexion n'est pas établie après 4 secondes |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 688 | contimeout 4000 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 689 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 690 | Remarques : |
| 691 | ----------- |
| 692 | - "contimeout" et "srvtimeout" n'ont pas d'utilité dans le cas du serveur de |
| 693 | type "health". |
| 694 | - sous de fortes charges, ou sur un réseau saturé ou défectueux, il est |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 695 | possible de perdre des paquets. Du fait que la première retransmission |
| 696 | TCP n'ait lieu qu'au bout de 3 secoudes, fixer un timeout de connexion |
| 697 | inférieur à 3 secondes ne permet pas de se rattraper sur la perte |
| 698 | de paquets car la session aura été abandonnée avant la première |
| 699 | retransmission. Une valeur de 4 secondes réduira considérablement |
| 700 | le nombre d'échecs de connexion. |
Willy Tarreau | befdff1 | 2007-12-02 22:27:38 +0100 | [diff] [blame] | 701 | - A compter de la version 1.3.14, il est possible de spécifier les durées |
| 702 | d'expiration dans des unités de temps arbitraires à choisir parmi |
| 703 | { us, ms, s, m, h, d }. Pour cela, la valeur entière doit être suffixée |
| 704 | de l'unité. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 705 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 706 | 2.6) Tentatives de reconnexion |
| 707 | ------------------------------ |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 708 | Lors d'un échec de connexion vers un serveur, il est possible de |
| 709 | retenter (potentiellement vers un autre serveur, en cas de répartition |
| 710 | de charge). Le nombre de nouvelles tentatives infructueuses avant |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 711 | abandon est fourni par le paramètre "retries". |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 712 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 713 | Exemple : |
| 714 | --------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 715 | # on essaie encore trois fois maxi |
| 716 | retries 3 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 717 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 718 | Il est à noter que la tentative de reconnexion peut amener à utiliser un autre |
| 719 | serveur si le premier a disparu entre deux tentatives de connexion. |
| 720 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 721 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 722 | 2.7) Adresse du serveur |
| 723 | ----------------------- |
| 724 | Le serveur vers lequel sont redirigées les nouvelles connexions est défini par |
| 725 | le paramètre "dispatch" sous la forme <adresse_ip>:<port>. Il correspond à un |
| 726 | serveur d'assignation de cookie dans le cas où le service consiste à assurer |
| 727 | uniquement une persistence HTTP, ou bien simplement au serveur destination dans |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 728 | le cas de relayage TCP simple. Cet ancien mode ne permet pas de tester l'état |
| 729 | du serveur distant, et il est maintenant recommandé d'utiliser de préférence |
| 730 | le mode 'balance'. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 731 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 732 | Exemple : |
| 733 | --------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 734 | # on envoie toutes les nouvelles connexions ici |
| 735 | dispatch 192.168.1.2:80 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 736 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 737 | Remarque : |
| 738 | ---------- |
| 739 | Ce paramètre n'a pas d'utilité pour un serveur en mode 'health', ni en mode |
| 740 | 'balance'. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 741 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 742 | |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 743 | 2.8) Adresse de sortie |
| 744 | ---------------------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 745 | Il est possible de forcer l'adresse utilisée pour établir les connexions vers |
| 746 | les serveurs à l'aide du paramètre "source". Il est même possible de forcer le |
| 747 | port, bien que cette fonctionnalité se limite à des usages très spécifiques. |
| 748 | C'est particulièrement utile en cas d'adressage multiple, et plus généralement |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 749 | pour permettre aux serveurs de trouver le chemin de retour dans des contextes |
| 750 | de routage difficiles. Si l'adresse est '0.0.0.0' ou '*' ou vide, elle sera |
| 751 | choisie librement par le systeme. Si le port est '0' ou vide, il sera choisi |
| 752 | librement par le système. Il est à noter que depuis la version 1.1.18, les |
| 753 | tests de bon fonctionnement des serveurs seront aussi effectués à partir de la |
| 754 | source spécifiée par ce paramètre. |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 755 | |
| 756 | Exemples : |
| 757 | ---------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 758 | listen http_proxy *:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 759 | # toutes les connexions prennent l'adresse 192.168.1.200 |
| 760 | source 192.168.1.200:0 |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 761 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 762 | listen rlogin_proxy *:513 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 763 | # utiliser l'adresse 192.168.1.200 et le port réservé 900 |
| 764 | source 192.168.1.200:900 |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 765 | |
| 766 | |
| 767 | 2.9) Définition du nom du cookie |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 768 | -------------------------------- |
| 769 | En mode HTTP, il est possible de rechercher la valeur d'un cookie pour savoir |
| 770 | vers quel serveur aiguiller la requête utilisateur. Le nom du cookie est donné |
| 771 | par le paramètre "cookie". |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 772 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 773 | Exemple : |
| 774 | --------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 775 | listen http_proxy :80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 776 | mode http |
| 777 | cookie SERVERID |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 778 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 779 | On peut modifier l'utilisation du cookie pour la rendre plus intelligente |
| 780 | vis-à-vis des applications relayées. Il est possible, notamment de supprimer ou |
| 781 | réécrire un cookie retourné par un serveur accédé en direct, et d'insérer un |
| 782 | cookie dans une réponse HTTP adressée à un serveur sélectionné en répartition |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 783 | de charge, et même de signaler aux proxies amont de ne pas cacher le cookie |
| 784 | inséré. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 785 | |
| 786 | Exemples : |
| 787 | ---------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 788 | |
| 789 | Pour ne conserver le cookie qu'en accès indirect, donc à travers le |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 790 | dispatcheur, et supprimer toutes ses éventuelles occurences lors des accès |
| 791 | directs : |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 792 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 793 | cookie SERVERID indirect |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 794 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 795 | Pour remplacer la valeur d'un cookie existant par celle attribuée à un serveur, |
| 796 | lors d'un accès direct : |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 797 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 798 | cookie SERVERID rewrite |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 799 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 800 | Pour créer un cookie comportant la valeur attribuée à un serveur lors d'un |
| 801 | accès en répartition de charge interne. Dans ce cas, il est souhaitable que |
| 802 | tous les serveurs aient un cookie renseigné. Un serveur non assigné d'un cookie |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 803 | retournera un cookie vide (cookie de suppression) : |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 804 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 805 | cookie SERVERID insert |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 806 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 807 | Pour réutiliser un cookie applicatif et lui préfixer l'identifiant du serveur, |
| 808 | puis le supprimer dans les requêtes suivantes, utiliser l'option 'prefix'. Elle |
| 809 | permet d'insérer une instance de haproxy devant une application sans risquer |
| 810 | d'incompatibilités dûes à des clients qui ne supporteraient pas d'apprendre |
| 811 | plus d'un cookie : |
| 812 | |
| 813 | cookie JSESSIONID prefix |
| 814 | |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 815 | Pour insérer un cookie, en s'assurant qu'un cache en amont ne le stockera pas, |
| 816 | ajouter le mot clé 'nocache' après 'insert' : |
| 817 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 818 | cookie SERVERID insert nocache |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 819 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 820 | Pour insérer un cookie seulement suite aux requêtes de type POST, ajouter le |
| 821 | mot clé 'postonly' après 'insert' : |
willy tarreau | cd87894 | 2005-12-17 13:27:43 +0100 | [diff] [blame] | 822 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 823 | cookie SERVERID insert postonly |
willy tarreau | cd87894 | 2005-12-17 13:27:43 +0100 | [diff] [blame] | 824 | |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 825 | |
willy tarreau | 96d4037 | 2005-12-17 13:11:56 +0100 | [diff] [blame] | 826 | Remarques : |
| 827 | ----------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 828 | - Il est possible de combiner 'insert' avec 'indirect' ou 'rewrite' pour |
| 829 | s'adapter à des applications générant déjà le cookie, avec un contenu |
| 830 | invalide. Il suffit pour cela de les spécifier sur la même ligne. |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 831 | |
willy tarreau | 96d4037 | 2005-12-17 13:11:56 +0100 | [diff] [blame] | 832 | - dans le cas où 'insert' et 'indirect' sont spécifiés, le cookie n'est jamais |
| 833 | transmis au serveur vu qu'il n'en a pas connaissance et ne pourrait pas le |
| 834 | comprendre. |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 835 | |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 836 | - il est particulièrement recommandé d'utiliser 'nocache' en mode insertion si |
| 837 | des caches peuvent se trouver entre les clients et l'instance du proxy. Dans |
| 838 | le cas contraire, un cache HTTP 1.0 pourrait cacher la réponse, incluant le |
| 839 | cookie de persistence inséré, donc provoquer des changements de serveurs pour |
| 840 | des clients partageant le même cache. |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 841 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 842 | - le mode 'prefix' ne nécessite pas d'utiliser 'indirect', 'nocache', ni |
| 843 | 'postonly', car tout comme le mode 'rewrite', il s'appuie sur un cookie |
| 844 | présenté par l'application qui est censée savoir à quel moment il peut |
| 845 | être émis sans risque. Toutefois, comme il nécessite de rectifier le cookie |
| 846 | présenté par le client dans chaque requête ultérieure, il est indispensable |
| 847 | de s'assurer que le client et le serveur communiqueront sans "keep-alive |
| 848 | HTTP". Dans le doute, il est recommandé d'utiliser l'option "httpclose". |
| 849 | |
willy tarreau | cd87894 | 2005-12-17 13:27:43 +0100 | [diff] [blame] | 850 | - lorsque l'application est bien connue, et que les parties nécessitant de la |
| 851 | persistence sont systématiquement accédées par un formulaire en mode POST, |
| 852 | il est plus efficace encore de combiner le mot clé "postonly" avec "insert" |
| 853 | et "indirect", car la page d'accueil reste cachable, et c'est l'application |
| 854 | qui gère le 'cache-control'. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 855 | |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 856 | 2.10) Assignation d'un serveur à une valeur de cookie |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 857 | ---------------------------------------------------- |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 858 | En mode HTTP, il est possible d'associer des valeurs de cookie à des serveurs |
| 859 | par le paramètre 'server'. La syntaxe est : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 860 | |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 861 | server <identifiant> <adresse_ip>:<port> cookie <valeur> |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 862 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 863 | - <identifiant> est un nom quelconque de serveur utilisé pour l'identifier dans la |
| 864 | configuration et les logs. |
| 865 | - <adresse_ip>:<port> est le couple adresse-port sur lequel le serveur écoute. |
| 866 | - <valeur> est la valeur à reconnaître ou positionner dans le cookie. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 867 | |
| 868 | Exemple : le cookie SERVERID peut contenir server01 ou server02 |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 869 | --------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 870 | listen http_proxy :80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 871 | mode http |
| 872 | cookie SERVERID |
| 873 | dispatch 192.168.1.100:80 |
| 874 | server web1 192.168.1.1:80 cookie server01 |
| 875 | server web2 192.168.1.2:80 cookie server02 |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 876 | |
| 877 | Attention : la syntaxe a changé depuis la version 1.0. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 878 | ----------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 879 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 880 | 3) Répartiteur de charge autonome |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 881 | ================================= |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 882 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 883 | Le relais peut effectuer lui-même la répartition de charge entre les différents |
| 884 | serveurs définis pour un service donné, en mode TCP comme en mode HTTP. Pour |
| 885 | cela, on précise le mot clé 'balance' dans la définition du service, |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 886 | éventuellement suivi du nom d'un algorithme de répartition. Jusqu'à la version |
| 887 | 1.2.11, seul 'roundrobin' était géré, et c'est aussi la valeur implicite par |
Willy Tarreau | 2fcb500 | 2007-05-08 13:35:26 +0200 | [diff] [blame] | 888 | défaut. Avec la version 1.2.12, le nouveau mot clé 'source' est apparu. La |
| 889 | version 1.3.10 a également apporté le mot clé 'uri'. Il est évident qu'en cas |
| 890 | d'utilisation du répartiteur interne, il ne faudra pas spécifier d'adresse de |
| 891 | dispatch, et qu'il faudra au moins un serveur. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 892 | |
| 893 | Exemple : même que précédemment en répartition interne |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 894 | --------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 895 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 896 | listen http_proxy :80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 897 | mode http |
| 898 | cookie SERVERID |
| 899 | balance roundrobin |
| 900 | server web1 192.168.1.1:80 cookie server01 |
| 901 | server web2 192.168.1.2:80 cookie server02 |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 902 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 903 | Depuis la version 1.1.22, il est possible de déterminer automatiquement le port |
| 904 | du serveur vers lequel sera envoyée la connexion, en fonction du port d'écoute |
| 905 | sur lequel le client s'est connecté. En effet, il y a 4 possibilités pour le |
| 906 | champ <port> de l'adresse serveur : |
| 907 | |
| 908 | - non spécifié ou nul : |
| 909 | la connexion sera envoyée au serveur sur le même port que celui sur |
| 910 | lequel le relais a reçu la connexion. |
| 911 | |
| 912 | - valeur numérique (seul cas supporté pour les versions antérieures) : |
| 913 | le serveur recevra la connexion sur le port désigné. |
| 914 | |
| 915 | - valeur numérique précédée d'un signe '+' : |
| 916 | la connexion sera envoyée au serveur sur le même port que celui sur |
| 917 | lequel le relais a reçu la connexion, auquel on ajoute la valeur désignée. |
| 918 | |
| 919 | - valeur numérique précédée d'un signe '-' : |
| 920 | la connexion sera envoyée au serveur sur le même port que celui sur |
| 921 | lequel le relais a reçu la connexion, duquel on soustrait la valeur |
| 922 | désignée. |
| 923 | |
| 924 | Exemples : |
| 925 | ---------- |
| 926 | |
| 927 | # même que précédemment |
| 928 | |
| 929 | listen http_proxy :80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 930 | mode http |
| 931 | cookie SERVERID |
| 932 | balance roundrobin |
| 933 | server web1 192.168.1.1 cookie server01 |
| 934 | server web2 192.168.1.2 cookie server02 |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 935 | |
| 936 | # relayage simultané des ports 80 et 81 et 8080-8089 |
| 937 | |
| 938 | listen http_proxy :80,:81,:8080-8089 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 939 | mode http |
| 940 | cookie SERVERID |
| 941 | balance roundrobin |
| 942 | server web1 192.168.1.1 cookie server01 |
| 943 | server web2 192.168.1.2 cookie server02 |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 944 | |
| 945 | # relayage TCP des ports 25, 389 et 663 vers les ports 1025, 1389 et 1663 |
| 946 | |
| 947 | listen http_proxy :25,:389,:663 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 948 | mode tcp |
| 949 | balance roundrobin |
| 950 | server srv1 192.168.1.1:+1000 |
| 951 | server srv2 192.168.1.2:+1000 |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 952 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 953 | Comme indiqué précédemment, la version 1.2.12 apporta le nouveau mot clé |
| 954 | 'source'. Lorsque celui-ci est utilisé, l'adresse IP du client est hachée et |
| 955 | distribuée de manière homogène parmi les serveurs disponibles, de sorte qu'une |
| 956 | même adresse IP aille toujours sur le même serveur tant qu'il n'y a aucun |
| 957 | changement dans le nombre de serveurs disponibles. Ceci peut être utilisé par |
| 958 | exemple pour attacher le HTTP et le HTTPS sur un même serveur pour un même |
| 959 | client. Cela peut également être utilisé pour améliorer la persistance |
| 960 | lorsqu'une partie de la population des clients n'accepte pas les cookies. Dans |
| 961 | ce cas, seuls ces derniers seront perturbés par la perte d'un serveur. |
| 962 | |
| 963 | NOTE: il est important de prendre en compte le fait que beaucoup d'internautes |
| 964 | naviguent à travers des fermes de proxies qui assignent des adresses IP |
| 965 | différentes à chaque requête. D'autres internautes utilisent des liens à |
| 966 | la demande et obtiennent une adresse IP différente à chaque connexion. De |
| 967 | ce fait, le paramètre 'source' doit être utilisé avec une extrème |
| 968 | précaution. |
| 969 | |
| 970 | Exemples : |
| 971 | ---------- |
| 972 | |
| 973 | # assurer qu'une même adresse IP ira sur le même serveur pour tout service |
| 974 | |
| 975 | listen http_proxy |
| 976 | bind :80,:443 |
| 977 | mode http |
| 978 | balance source |
| 979 | server web1 192.168.1.1 |
| 980 | server web2 192.168.1.2 |
| 981 | |
| 982 | # améliorer la persistance par l'utilisation de la source en plus du cookie : |
| 983 | |
| 984 | listen http_proxy :80 |
| 985 | mode http |
| 986 | cookie SERVERID |
| 987 | balance source |
| 988 | server web1 192.168.1.1 cookie server01 |
| 989 | server web2 192.168.1.2 cookie server02 |
| 990 | |
Willy Tarreau | 2fcb500 | 2007-05-08 13:35:26 +0200 | [diff] [blame] | 991 | De plus, tel qu'indiqué ci-dessus, la version 1.3.10 a introduit le mot clé |
| 992 | 'uri'. Il est très pratique dans le cas de répartition de charge entre des |
| 993 | reverse-proxy-caches, parce qu'il utilisera le résultat d'un hachage de l'URI |
| 994 | pour choisir un serveur, ce qui aura pour effet d'optimiser le taux de cache |
| 995 | du fait que la même URI sera toujours envoyée au même cache. Ce mot-clé n'est |
| 996 | autorisé qu'en mode HTTP. |
| 997 | |
| 998 | Example : |
| 999 | --------- |
| 1000 | |
| 1001 | # Envoie toujours une URI donnée au même serveur |
| 1002 | |
| 1003 | listen http_proxy |
| 1004 | bind :3128 |
| 1005 | mode http |
| 1006 | balance uri |
| 1007 | server squid1 192.168.1.1 |
| 1008 | server squid2 192.168.1.2 |
| 1009 | |
Willy Tarreau | 0173280 | 2007-11-01 22:48:15 +0100 | [diff] [blame] | 1010 | La version 1.3.14 a apporté une nouvelle méthode 'balance url_param'. Elle |
| 1011 | consiste à se baser sur un paramètre passé dans l'URL pour effectuer un hachage |
| 1012 | utilisé pour déterminer le serveur à utiliser. Ceci est principalement utile |
| 1013 | pour des applications n'ayant pas une exigence stricte de persistance, mais |
| 1014 | pour lesquelles elle procure un gain de performance notable dans des |
| 1015 | environnements où il n'est pas toujours possible d'utiliser des cookies. En cas |
| 1016 | d'absence du paramètre dans l'URL, alors une répartition de type 'round robin' |
| 1017 | est effectuée. |
| 1018 | |
| 1019 | Example : |
| 1020 | --------- |
| 1021 | |
| 1022 | # hache le paramètre "basket_id" dans l'URL pour déterminer le serveur |
| 1023 | |
| 1024 | listen http_proxy |
| 1025 | bind :3128 |
| 1026 | mode http |
| 1027 | balance url_param basket_id |
| 1028 | server ebiz1 192.168.1.1 |
| 1029 | server ebiz2 192.168.1.2 |
| 1030 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1031 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1032 | 3.1) Surveillance des serveurs |
| 1033 | ------------------------------ |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1034 | Il est possible de tester l'état des serveurs par établissement de connexion |
| 1035 | TCP ou par envoi d'une requête HTTP. Un serveur hors d'usage ne sera pas |
| 1036 | utilisé dans le processus de répartition de charge interne. Pour activer la |
| 1037 | surveillance, ajouter le mot clé 'check' à la fin de la déclaration du serveur. |
| 1038 | Il est possible de spécifier l'intervalle (en millisecondes) séparant deux |
| 1039 | tests du serveur par le paramètre "inter", le nombre d'échecs acceptés par le |
| 1040 | paramètre "fall", et le nombre de succès avant reprise par le paramètre "rise". |
| 1041 | Les paramètres non précisés prennent les valeurs suivantes par défaut : |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1042 | |
willy tarreau | e47c8d7 | 2005-12-17 12:55:52 +0100 | [diff] [blame] | 1043 | - inter : 2000 |
| 1044 | - rise : 2 |
| 1045 | - fall : 3 |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1046 | - port : port de connexion du serveur |
Willy Tarreau | 2ea3abb | 2007-03-25 16:45:16 +0200 | [diff] [blame] | 1047 | - addr : adresse de connexion du serveur (par defaut: adresse du serveur) |
| 1048 | |
willy tarreau | bc4e1fb | 2005-12-17 13:32:07 +0100 | [diff] [blame] | 1049 | Le mode par défaut consiste à établir des connexions TCP uniquement. Dans |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1050 | certains cas de pannes, des serveurs peuvent continuer à accepter les |
| 1051 | connexions sans les traiter. Depuis la version 1.1.16, haproxy est en mesure |
| 1052 | d'envoyer des requêtes HTTP courtes et très peu coûteuses. Les versions 1.1.16 |
| 1053 | et 1.1.17 utilisent "OPTIONS / HTTP/1.0". Dans les versions 1.1.18 à 1.1.20, |
| 1054 | les requêtes ont été changées en "OPTIONS * HTTP/1.0" pour des raisons de |
| 1055 | contrôle d'accès aux ressources. Cependant, cette requête documentée dans la |
| 1056 | RFC2068 n'est pas comprise par tous les serveurs. Donc à partir de la version |
| 1057 | 1.1.21, la requête par défaut est revenue à "OPTIONS / HTTP/1.0", mais il est |
| 1058 | possible de paramétrer la partie URI. Les requêtes OPTIONS présentent |
| 1059 | l'avantage d'être facilement extractibles des logs, et de ne pas induire |
| 1060 | d'accès aux fichiers côté serveur. Seules les réponses 2xx et 3xx sont |
| 1061 | considérées valides, les autres (y compris non-réponses) aboutissent à un |
| 1062 | échec. Le temps maximal imparti pour une réponse est égal à l'intervalle entre |
| 1063 | deux tests (paramètre "inter"). Pour activer ce mode, spécifier l'option |
| 1064 | "httpchk", éventuellement suivie d'une méthode et d'une URI. L'option "httpchk" |
| 1065 | accepte donc 4 formes : |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1066 | |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 1067 | - option httpchk -> OPTIONS / HTTP/1.0 |
| 1068 | - option httpchk URI -> OPTIONS <URI> HTTP/1.0 |
| 1069 | - option httpchk METH URI -> <METH> <URI> HTTP/1.0 |
| 1070 | - option httpchk METH URI VER -> <METH> <URI> <VER> |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1071 | |
Willy Tarreau | f3c6920 | 2006-07-09 16:42:34 +0200 | [diff] [blame] | 1072 | HAProxy est souvent utilisé pour relayer divers protocoles reposant sur TCP, |
| 1073 | tels que HTTPS, SMTP ou LDAP, le plus commun étant HTTPS. Un problème assez |
| 1074 | couramment rencontré dans les data centers est le besoin de relayer du trafic |
| 1075 | vers des serveurs lointains tout en maintenant la possibilité de basculer sur |
| 1076 | un serveur de secours. Les tests purement TCP ne suffisent pas toujours dans |
| 1077 | ces situations car l'on trouve souvent, dans la chaîne, des proxies, firewalls |
| 1078 | ou répartiteurs de charge qui peuvent acquitter la connexion avant qu'elle |
| 1079 | n'atteigne le serveur. La seule solution à ce problème est d'envoyer des tests |
| 1080 | applicatifs. Comme la demande pour les tests HTTPS est élevée, ce test a été |
| 1081 | implémenté en version 1.2.15 sur la base de messages SSLv3 CLIENT HELLO. Pour |
| 1082 | l'activer, utiliser "option ssl-hello-chk". Ceci enverra des messages SSLv3 |
| 1083 | CLIENT HELLO aux serveurs, en annonçant un support pour la majorité des |
| 1084 | algorithmes de chiffrement. Si en retour, le serveur envoie ce qui ressemble à |
| 1085 | une réponse SSLv3 SERVER HELLO ou ALERT (refus des algorithmes), alors la |
| 1086 | réponse sera considérée comme valide. Noter qu'Apache ne produit pas de log |
| 1087 | lorsqu'il reçoit des messages HELLO, ce qui en fait un type de message |
| 1088 | parfaitement adapté à ce besoin. |
| 1089 | |
Willy Tarreau | 2367790 | 2007-05-08 23:50:35 +0200 | [diff] [blame] | 1090 | La version 1.3.10 est accompagnée d'un nouveau test d'état pour le SMTP. Par |
| 1091 | défaut, il consiste à envoyer "HELO localhost" aux serveurs, et à attendre le |
| 1092 | message "250" en retour. Notez qu'il peut aussi envoyer une requête plus |
| 1093 | spécifique : |
| 1094 | |
| 1095 | - option smtpchk -> envoie "HELO localhost" |
| 1096 | - option smtpchk EHLO mail.mydomain.com -> envoie ce message ESMTP |
| 1097 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1098 | Voir les exemples ci-après. |
willy tarreau | bc4e1fb | 2005-12-17 13:32:07 +0100 | [diff] [blame] | 1099 | |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1100 | Depuis la version 1.1.17, il est possible de définir des serveurs de secours, |
| 1101 | utilisés uniquement lorsqu'aucun des autres serveurs ne fonctionne. Pour cela, |
| 1102 | ajouter le mot clé "backup" sur la ligne de définition du serveur. Un serveur |
| 1103 | de secours n'est appelé que lorsque tous les serveurs normaux, ainsi que tous |
| 1104 | les serveurs de secours qui le précèdent sont hors d'usage. Il n'y a donc pas |
Willy TARREAU | 3481c46 | 2006-03-01 22:37:57 +0100 | [diff] [blame] | 1105 | de répartition de charge entre des serveurs de secours par défaut. A partir |
| 1106 | de la version 1.2.9, il est possible de les utiliser simultanément grâce à |
| 1107 | l'option 'allbackups'. Ce type de serveurs peut servir à retourner des pages |
| 1108 | d'indisponibilité de service. Dans ce cas, il est préférable de ne pas affecter |
| 1109 | de cookie, afin que les clients qui le rencontrent n'y soient pas affectés |
| 1110 | définitivement. Le fait de ne pas mettre de cookie envoie un cookie vide, ce |
| 1111 | qui a pour effet de supprimer un éventuel cookie affecté précédemment. |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1112 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1113 | Depuis la version 1.1.22, il est possible d'envoyer les tests de fonctionnement |
| 1114 | vers un port différent de celui de service. C'est nécessaire principalement |
| 1115 | pour les configurations où le serveur n'a pas de port prédéfini, par exemple |
| 1116 | lorsqu'il est déduit du port d'acceptation de la connexion. Pour cela, utiliser |
Willy Tarreau | 2ea3abb | 2007-03-25 16:45:16 +0200 | [diff] [blame] | 1117 | le paramètre 'port' suivi du numéro de port devant répondre aux requêtes. Il |
| 1118 | est possible d'envoyer les tests de fonctionnement vers une adresse différente |
| 1119 | de celle de service. Cela permet d'utiliser, sur la machine faisant fonctionner |
| 1120 | HAproxy, un démon permettant des tests specifiques ( REGEX sur un résultat et |
| 1121 | basculement de plusieurs fermes en cas d'erreur sur l'une d'elles). |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1122 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1123 | Enfin, depuis la version 1.1.17, il est possible de visualiser rapidement |
| 1124 | l'état courant de tous les serveurs. Pour cela, il suffit d'envoyer un signal |
| 1125 | SIGHUP au processus proxy. L'état de tous les serveurs de tous les proxies est |
| 1126 | envoyé dans les logs en niveau "notice", ainsi que sur la sortie d'erreurs si |
| 1127 | elle est active. C'est une bonne raison pour avoir au moins un serveur de logs |
| 1128 | local en niveau notice. |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1129 | |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1130 | Depuis la version 1.1.18 (et 1.2.1), un message d'urgence est envoyé dans les |
| 1131 | logs en niveau 'emerg' si tous les serveurs d'une même instance sont tombés, |
| 1132 | afin de notifier l'administrateur qu'il faut prendre une action immédiate. |
| 1133 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 1134 | Depuis les versions 1.1.30 et 1.2.3, plusieurs serveurs peuvent partager la |
| 1135 | même valeur de cookie. C'est particulièrement utile en mode backup, pour |
| 1136 | sélectionner des chemins alternatifs pour un serveur donné, pour mettre en |
| 1137 | oeuvre l'arrêt en douceur d'un serveur, ou pour diriger les clients |
| 1138 | temporairement vers une page d'erreur en attendant le redémarrage d'une |
| 1139 | application. Le principe est que lorsqu'un serveur est détecté comme inopérant, |
| 1140 | le proxy cherchera le prochain serveur possédant la même valeur de cookie pour |
| 1141 | chaque client qui le demandera. S'il ne trouve pas de serveur normal, alors il |
| 1142 | le cherchera parmi les serveurs de backup. Consulter le guide d'architecture |
| 1143 | pour plus d'informations. |
| 1144 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1145 | Exemples : |
| 1146 | ---------- |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1147 | # conf du paragraphe 3) avec surveillance TCP |
willy tarreau | bc4e1fb | 2005-12-17 13:32:07 +0100 | [diff] [blame] | 1148 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1149 | mode http |
| 1150 | cookie SERVERID |
| 1151 | balance roundrobin |
| 1152 | server web1 192.168.1.1:80 cookie server01 check |
| 1153 | server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 |
willy tarreau | bc4e1fb | 2005-12-17 13:32:07 +0100 | [diff] [blame] | 1154 | |
willy tarreau | 2f6ba65 | 2005-12-17 13:57:42 +0100 | [diff] [blame] | 1155 | # même que précédemment avec surveillance HTTP par 'OPTIONS / HTTP/1.0' |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1156 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1157 | mode http |
| 1158 | cookie SERVERID |
| 1159 | balance roundrobin |
| 1160 | option httpchk |
| 1161 | server web1 192.168.1.1:80 cookie server01 check |
| 1162 | server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1163 | |
willy tarreau | 2f6ba65 | 2005-12-17 13:57:42 +0100 | [diff] [blame] | 1164 | # même que précédemment avec surveillance HTTP par 'OPTIONS /index.html HTTP/1.0' |
| 1165 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1166 | mode http |
| 1167 | cookie SERVERID |
| 1168 | balance roundrobin |
| 1169 | option httpchk /index.html |
| 1170 | server web1 192.168.1.1:80 cookie server01 check |
| 1171 | server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 |
willy tarreau | 2f6ba65 | 2005-12-17 13:57:42 +0100 | [diff] [blame] | 1172 | |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 1173 | # idem avec surveillance HTTP par 'HEAD /index.jsp? HTTP/1.1\r\nHost: www' |
| 1174 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1175 | mode http |
| 1176 | cookie SERVERID |
| 1177 | balance roundrobin |
| 1178 | option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www |
| 1179 | server web1 192.168.1.1:80 cookie server01 check |
| 1180 | server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2 |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 1181 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 1182 | # répartition avec persistence basée sur le préfixe de cookie, et arrêt en |
| 1183 | # douceur utilisant un second port (81) juste pour les health-checks. |
| 1184 | listen http_proxy 0.0.0.0:80 |
| 1185 | mode http |
| 1186 | cookie JSESSIONID prefix |
| 1187 | balance roundrobin |
| 1188 | option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www |
| 1189 | server web1-norm 192.168.1.1:80 cookie s1 check port 81 |
| 1190 | server web2-norm 192.168.1.2:80 cookie s2 check port 81 |
| 1191 | server web1-stop 192.168.1.1:80 cookie s1 check port 80 backup |
| 1192 | server web2-stop 192.168.1.2:80 cookie s2 check port 80 backup |
| 1193 | |
willy tarreau | 96d4037 | 2005-12-17 13:11:56 +0100 | [diff] [blame] | 1194 | # Insertion automatique de cookie dans la réponse du serveur, et suppression |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 1195 | # automatique dans la requête, tout en indiquant aux caches de ne pas garder |
| 1196 | # ce cookie. |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1197 | listen web_appl 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1198 | mode http |
| 1199 | cookie SERVERID insert nocache indirect |
| 1200 | balance roundrobin |
| 1201 | server web1 192.168.1.1:80 cookie server01 check |
| 1202 | server web2 192.168.1.2:80 cookie server02 check |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1203 | |
willy tarreau | eedaa9f | 2005-12-17 14:08:03 +0100 | [diff] [blame] | 1204 | # idem avec serveur applicatif de secours sur autre site, et serveur de pages d'erreurs |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1205 | listen web_appl 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1206 | mode http |
| 1207 | cookie SERVERID insert nocache indirect |
| 1208 | balance roundrobin |
| 1209 | server web1 192.168.1.1:80 cookie server01 check |
| 1210 | server web2 192.168.1.2:80 cookie server02 check |
| 1211 | server web-backup 192.168.2.1:80 cookie server03 check backup |
| 1212 | server web-excuse 192.168.3.1:80 check backup |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1213 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1214 | # relayage SMTP+TLS avec test du serveur et serveur de backup |
| 1215 | |
| 1216 | listen http_proxy :25,:587 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1217 | mode tcp |
| 1218 | balance roundrobin |
| 1219 | server srv1 192.168.1.1 check port 25 inter 30000 rise 1 fall 2 |
| 1220 | server srv2 192.168.1.2 backup |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1221 | |
Willy Tarreau | f3c6920 | 2006-07-09 16:42:34 +0200 | [diff] [blame] | 1222 | # relayage HTTPS avec test du serveur et serveur de backup |
| 1223 | |
| 1224 | listen http_proxy :443 |
| 1225 | mode tcp |
| 1226 | option ssl-hello-chk |
| 1227 | balance roundrobin |
| 1228 | server srv1 192.168.1.1 check inter 30000 rise 1 fall 2 |
| 1229 | server srv2 192.168.1.2 backup |
| 1230 | |
Willy TARREAU | 3481c46 | 2006-03-01 22:37:57 +0100 | [diff] [blame] | 1231 | # Utilisation d'un groupe de serveurs pour le backup (nécessite haproxy 1.2.9) |
| 1232 | listen http_proxy 0.0.0.0:80 |
| 1233 | mode http |
| 1234 | balance roundrobin |
| 1235 | option httpchk |
| 1236 | server inst1 192.168.1.1:80 cookie s1 check |
| 1237 | server inst2 192.168.1.2:80 cookie s2 check |
| 1238 | server inst3 192.168.1.3:80 cookie s3 check |
| 1239 | server back1 192.168.1.10:80 check backup |
| 1240 | server back2 192.168.1.11:80 check backup |
| 1241 | option allbackups # all backups will be used |
| 1242 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1243 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1244 | 3.2) Reconnexion vers un répartiteur en cas d'échec direct |
| 1245 | ---------------------------------------------------------- |
| 1246 | En mode HTTP, si un serveur défini par un cookie ne répond plus, les clients |
| 1247 | seront définitivement aiguillés dessus à cause de leur cookie, et de ce fait, |
| 1248 | définitivement privés de service. La spécification du paramètre 'redispatch' |
| 1249 | autorise dans ce cas à renvoyer les connexions échouées vers le répartiteur |
| 1250 | (externe ou interne) afin d'assigner un nouveau serveur à ces clients. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1251 | |
| 1252 | Exemple : |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1253 | --------- |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1254 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1255 | mode http |
| 1256 | cookie SERVERID |
| 1257 | dispatch 192.168.1.100:80 |
| 1258 | server web1 192.168.1.1:80 cookie server01 |
| 1259 | server web2 192.168.1.2:80 cookie server02 |
| 1260 | redispatch # renvoyer vers dispatch si refus de connexion. |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1261 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1262 | Par défaut (et dans les versions 1.1.16 et antérieures), le paramètre |
| 1263 | redispatch ne s'applique qu'aux échecs de connexion au serveur. Depuis la |
| 1264 | version 1.1.17, il s'applique aussi aux connexions destinées à des serveurs |
| 1265 | identifiés comme hors d'usage par la surveillance. Si l'on souhaite malgré |
| 1266 | tout qu'un client disposant d'un cookie correspondant à un serveur défectueux |
| 1267 | tente de s'y connecter, il faut préciser l'option "persist" : |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1268 | |
| 1269 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1270 | mode http |
| 1271 | option persist |
| 1272 | cookie SERVERID |
| 1273 | dispatch 192.168.1.100:80 |
| 1274 | server web1 192.168.1.1:80 cookie server01 |
| 1275 | server web2 192.168.1.2:80 cookie server02 |
| 1276 | redispatch # renvoyer vers dispatch si serveur HS. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1277 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1278 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1279 | 3.3) Assignation de poids différents à des serveurs |
| 1280 | --------------------------------------------------- |
| 1281 | Parfois il arrive d'ajouter de nouveaux serveurs pour accroître la capacité |
| 1282 | d'une ferme de serveur, mais le nouveau serveur est soit beaucoup plus petit |
| 1283 | que les autres (dans le cas d'un ajout d'urgence de matériel de récupération), |
| 1284 | soit plus puissant (lors d'un investissement dans du matériel neuf). Pour cette |
| 1285 | raison, il semble parfois judicieux de pouvoir envoyer plus de clients vers les |
| 1286 | plus gros serveurs. Jusqu'à la version 1.2.11, il était nécessaire de répliquer |
| 1287 | plusieurs fois les définitions des serveurs pour augmenter leur poids. Depuis |
| 1288 | la version 1.2.12, l'option 'weight' est disponible. HAProxy construit alors |
| 1289 | une vue des serveurs disponibles la plus homogène possible en se basant sur |
| 1290 | leur poids de sorte que la charge se distribue de la manière la plus lisse |
| 1291 | possible. Le poids compris entre 1 et 256 doit refléter la capacité d'un |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1292 | serveur par rapport aux autres. Le poids de 1 donne la fréquence d'apparition |
| 1293 | la plus faible, et 256 la fréquence la plus élevée. De cette manière, si un |
| 1294 | serveur disparait, les capacités restantes sont toujours respectées. |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1295 | |
| 1296 | |
| 1297 | Exemple : |
| 1298 | --------- |
| 1299 | # distribution équitable sur 2 opteron and un ancien pentium3 |
| 1300 | |
| 1301 | listen web_appl 0.0.0.0:80 |
| 1302 | mode http |
| 1303 | cookie SERVERID insert nocache indirect |
| 1304 | balance roundrobin |
| 1305 | server pentium3-800 192.168.1.1:80 cookie server01 weight 8 check |
| 1306 | server opteron-2.0G 192.168.1.2:80 cookie server02 weight 20 check |
| 1307 | server opteron-2.4G 192.168.1.3:80 cookie server03 weight 24 check |
| 1308 | server web-backup1 192.168.2.1:80 cookie server04 check backup |
| 1309 | server web-excuse 192.168.3.1:80 check backup |
| 1310 | |
| 1311 | Notes : |
| 1312 | ------- |
| 1313 | - lorsque le poids n'est pas spécifié, la valeur par défaut est à 1 |
| 1314 | |
| 1315 | - le poids n'impacte pas les tests de fonctionnement (health checks), donc il |
| 1316 | est plus propre d'utiliser les poids que de répliquer le même serveur |
| 1317 | plusieurs fois. |
| 1318 | |
| 1319 | - les poids s'appliquent également aux serveurs de backup si l'option |
| 1320 | 'allbackups' est positionnée. |
| 1321 | |
| 1322 | - le poids s'applique aussi à la répartition selon la source |
| 1323 | ('balance source'). |
| 1324 | |
| 1325 | - quels que soient les poids, le premier serveur sera toujours assigné en |
| 1326 | premier. Cette règle facilite les diagnostics. |
| 1327 | |
| 1328 | - pour les puristes, l'algorithme de calculation de la vue des serveurs donne |
| 1329 | une priorité aux premiers serveurs, donc la vue est la plus uniforme si les |
| 1330 | serveurs sont déclarés dans l'ordre croissant de leurs poids. |
| 1331 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1332 | La distribution du trafic suivra exactement le séquencement suivant : |
| 1333 | |
| 1334 | Request| 1 1 1 1 |
| 1335 | number | 1 2 3 4 5 6 7 8 9 0 1 2 3 |
| 1336 | --------+--------------------------- |
| 1337 | p3-800 | X . . . . . . X . . . . . |
| 1338 | opt-20 | . X . X . X . . . X . X . |
| 1339 | opt-24 | . . X . X . X . X . X . X |
| 1340 | |
| 1341 | |
| 1342 | 3.4) Limitation du nombre de sessions concurrentes par serveur |
| 1343 | -------------------------------------------------------------- |
| 1344 | Certains serveurs web multi-processus tels qu'Apache souffrent dès qu'il y a |
| 1345 | trop de sessions concurrentes, parce qu'il est très coûteux de faire |
| 1346 | fonctionner des centaines ou des milliers de processus sur un système. Une |
| 1347 | solution consiste à augmenter le nombre de serveurs et de répartir la charge |
| 1348 | entre eux, mais cela pose un problème lorsque le but est uniquement de résister |
| 1349 | à des pics de charge occasionnels. |
| 1350 | |
| 1351 | Pour résoudre ce problème, une nouvelle fonctionnalité a été implémentée dans |
| 1352 | HAProxy 1.2.13. Il s'agit d'une limite "maxconn" par serveur, associée à une |
| 1353 | file d'attente par serveur et par proxy. Ceci transforme HAProxy en un tampon |
| 1354 | entre des milliers de clients et quelques serveurs. Dans bien des cas, le fait |
| 1355 | de diminuer la valeur maxconn améliorera notablement les performances des |
| 1356 | serveurs et diminuera les temps de réponse simplement parce que les serveurs |
| 1357 | seront moins congestionnés. |
| 1358 | |
| 1359 | Quand une requête cherche à joindre n'importe quel serveur, le premier serveur |
| 1360 | non saturé est utilisé, en respectant l'algorithme de répartition de charge. Si |
| 1361 | tous les serveurs sont saturés, alors la requête sera mise dans la file |
| 1362 | d'attente globale de l'instance. Elle sortira de cette file d'attente lorsque |
| 1363 | toutes les requêtes précédentes auront été libérées et qu'un serveur aura été |
| 1364 | libéré d'une connexion pour la traiter. |
| 1365 | |
| 1366 | Si une requête fait référence à un serveur en particulier (p.ex: hachage d'IP |
| 1367 | source, ou persistance par cookie), et que ce server est saturé, alors la |
| 1368 | requête sera mise dans la file d'attente dédiée à ce serveur. Cette file |
| 1369 | d'attente est prioritaire sur la file d'attente globale, de sorte qu'il soit |
| 1370 | plus facile d'atteindre le site pour les utilisateurs qui s'y trouvent déjà |
| 1371 | que pour les nouveaux utilisateurs. |
| 1372 | |
| 1373 | Pour cela, les logs ont dû être enrichis pour indiquer le nombre de sessions |
| 1374 | par serveur, la position de la requête dans les files d'attentes, et le temps |
| 1375 | passé en file d'attente. Ceci aide considérablement à faire de la prévision de |
| 1376 | capacité. Voir la section 'logs' plus bas pour plus d'informations. |
| 1377 | |
| 1378 | Exemple : |
| 1379 | --------- |
| 1380 | # Prendre soin du P3 qui n'a que 256 Mo de RAM. |
| 1381 | listen web_appl 0.0.0.0:80 |
| 1382 | maxconn 10000 |
| 1383 | mode http |
| 1384 | cookie SERVERID insert nocache indirect |
| 1385 | balance roundrobin |
| 1386 | server pentium3-800 192.168.1.1:80 cookie s1 weight 8 maxconn 100 check |
| 1387 | server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 maxconn 300 check |
| 1388 | server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 maxconn 300 check |
| 1389 | server web-backup1 192.168.2.1:80 cookie s4 check maxconn 200 backup |
| 1390 | server web-excuse 192.168.3.1:80 check backup |
| 1391 | |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 1392 | Cette option se montra si efficace pour réduire les temps de réponse des |
| 1393 | serveurs que certains utilisateurs voulaient utiliser des valeurs trop basses |
| 1394 | pour améliorer les performances de leurs serveurs. Seulement, ils n'étaient |
| 1395 | alors plus en mesure de supporter de très fortes charges parce qu'il n'était |
| 1396 | plus possible de les saturer. Pour cette raison, la version 1.2.14 a apporté la |
| 1397 | limitation dynamique de connexions avec l'addition du paramètre "minconn". |
| 1398 | Lorsque ce paramètre est associé à "maxconn", il active la limitation dynamique |
| 1399 | basée sur la charge de l'instance. Le nombre maximal de sessions concurrentes |
| 1400 | sur un serveur devient alors proportionnel au nombre de sessions de l'instance |
| 1401 | par rapport à son 'maxconn'. Un minimum de <minconn> sessions sera toujours |
| 1402 | permis quelle que soit la charge. Ceci assurera que les serveurs travailleront |
| 1403 | au meilleur de leurs performances sous des charges normales, et qu'ils seront |
| 1404 | tout de même capables de supporter de fortes pointes lorsque nécessaire. La |
| 1405 | limite dynamique est calculée comme ceci : |
| 1406 | |
| 1407 | srv.dyn_limit = max(srv.minconn, srv.maxconn * inst.sess / inst.maxconn) |
| 1408 | |
| 1409 | Exemple : |
| 1410 | --------- |
| 1411 | # Prendre soin du P3 qui n'a que 256 Mo de RAM. |
| 1412 | listen web_appl 0.0.0.0:80 |
| 1413 | maxconn 10000 |
| 1414 | mode http |
| 1415 | cookie SERVERID insert nocache indirect |
| 1416 | balance roundrobin |
| 1417 | server pentium3-800 192.168.1.1:80 cookie s1 weight 8 minconn 10 maxconn 100 check |
| 1418 | server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 minconn 30 maxconn 300 check |
| 1419 | server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 minconn 30 maxconn 300 check |
| 1420 | server web-backup1 192.168.2.1:80 cookie s4 check maxconn 200 backup |
| 1421 | server web-excuse 192.168.3.1:80 check backup |
| 1422 | |
| 1423 | Dans l'exemple ci-dessus, le serveur "pentium3-800' recevra au plus 100 |
| 1424 | connexions simultanées lorsque l'instance du proxy en atteindra 10000, et |
| 1425 | recevra seulement 10 connexions simultanées tant que le proxy sera sous les 1000 |
| 1426 | sessions. |
| 1427 | |
Elijah Epifanov | acafc5f | 2007-10-25 20:15:38 +0200 | [diff] [blame] | 1428 | Il est possible de limiter la taille de la file d'attente dans le but de |
| 1429 | redistribuer les connexions destinées à un serveur en particulier qui sont trop |
| 1430 | loin pour avoir une chance d'être servies en un temps raisonnable. Ceci n'est |
| 1431 | acceptable que dans le cas où l'affinité entre le client et le serveur n'est |
| 1432 | pas obligatoire, mais motivée uniquement par des raisons de performances, par |
| 1433 | exemple, par l'utilisation d'un cache local au serveur. L'option 'maxqueue' |
| 1434 | permet de préciser la limite par serveur, tel que dans l'exemple ci-dessous : |
| 1435 | |
| 1436 | ... (même exemple que précédemment) |
| 1437 | server pentium3-800 192.168.1.1:80 cookie s1 weight 8 minconn 10 maxconn 100 check maxqueue 50 |
| 1438 | server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 minconn 30 maxconn 300 check maxqueue 200 |
| 1439 | server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 minconn 30 maxconn 300 check |
| 1440 | |
| 1441 | En l'absence du paramètre 'maxqueue', la file d'un serveur n'a pas de limite |
| 1442 | définie. Dans le cas contraire, lorsque la file atteint la limite fixée par |
| 1443 | 'maxqueue', les clients sont déplacés vers la file globale. |
| 1444 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1445 | Notes : |
| 1446 | ------- |
| 1447 | - la requête ne restera pas indéfiniment en file d'attente, elle est |
| 1448 | assujétie au paramètre 'contimeout', et si une requête ne peut pas |
| 1449 | sortir de la file avant ce time-out, soit parce que le serveur est |
| 1450 | saturé, soit parce qu'il y a trop de requêtes en file d'attente, |
| 1451 | alors elle expirera avec une erreur 503. |
| 1452 | |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 1453 | - si seul <minconn> est spécifié, il a le même effet que <maxconn> |
| 1454 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1455 | - positionner des valeurs trop basses pour 'maxconn' peut améliorer les |
| 1456 | performances mais aussi permettre à des utilisateurs trop lents de bloquer |
| 1457 | un serveur pour les autres utilisateurs. |
| 1458 | |
willy tarreau | 34f4530 | 2006-04-15 21:37:14 +0200 | [diff] [blame] | 1459 | |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 1460 | 3.5) Abandon des requêtes abortées |
| 1461 | ---------------------------------- |
| 1462 | En présence de très fortes charges, les serveurs mettront un certain temps à |
| 1463 | répondre. La file d'attente du proxy se remplira, et les temps de réponse |
| 1464 | suivront une croissance proportionnelle à la taille de file d'attente fois |
| 1465 | le temps moyen de réponse par session. Lorsque les clients attendront plus de |
| 1466 | quelques secondes, ils cliqueront souvent sur le bouton 'STOP' de leur |
| 1467 | navigateur, laissant des requêtes inutiles en file d'attente et ralentissant |
| 1468 | donc les autres utilisateurs. |
| 1469 | |
| 1470 | Comme il n'y a aucun moyen de distinguer un vrai clic sur STOP d'une simple |
| 1471 | fermeture du canal de sortie sur le client (shutdown(SHUT_WR)), les agents HTTP |
| 1472 | doivent être conservateurs et considérer que le client n'a probablement fermé |
| 1473 | que le canal de sortie en attendant la réponse. Toutefois, ceci introduit des |
| 1474 | risques de congestion lorsque beaucoup d'utilisateurs font de même, et s'avère |
| 1475 | aujourd'hui complètement inutile car probablement aucun client ne referme la |
| 1476 | session en attendant la réponse. Certains agents HTTP supportent ceci (Squid, |
| 1477 | Apache, HAProxy), et d'autres ne le supportent pas (TUX, et la plupart des |
| 1478 | répartiteurs de charge matériels). Donc la probabilité pour qu'une notification |
| 1479 | de fermeture d'un canal d'entrée côté client représente un utilisateur cliquant |
| 1480 | sur 'STOP' est proche de 100%, et il est vraiment tentant d'abandonner la |
| 1481 | requête prématurément sans polluer les serveurs. |
| 1482 | |
| 1483 | Pour cette raison, une nouvelle option "abortonclose" a été introduite en |
| 1484 | version 1.2.14. Par défaut (sans l'option), le comportement reste conforme à |
| 1485 | HTTP. Mais lorsque l'option est spécifiée, une session dont le canal entrant |
| 1486 | est fermé sera abortée si cela est possible, c'est à dire que la requête est |
| 1487 | soit en file d'attente, soit en tentative de connexion. Ceci réduit |
| 1488 | considérablement la longueur des files d'attentes et la charge sur les serveurs |
| 1489 | saturés lorsque les utilisateurs sont tentés de cliquer sur 'STOP', ce qui à |
| 1490 | son tour, réduit les temps de réponse pour les autres utilisateurs. |
| 1491 | |
| 1492 | Exemple : |
| 1493 | --------- |
| 1494 | listen web_appl 0.0.0.0:80 |
| 1495 | maxconn 10000 |
| 1496 | mode http |
| 1497 | cookie SERVERID insert nocache indirect |
| 1498 | balance roundrobin |
| 1499 | server web1 192.168.1.1:80 cookie s1 weight 10 maxconn 100 check |
| 1500 | server web2 192.168.1.2:80 cookie s2 weight 10 maxconn 100 check |
| 1501 | server web3 192.168.1.3:80 cookie s3 weight 10 maxconn 100 check |
| 1502 | server bck1 192.168.2.1:80 cookie s4 check maxconn 200 backup |
| 1503 | option abortonclose |
| 1504 | |
| 1505 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1506 | 4) Fonctionnalités additionnelles |
| 1507 | ================================= |
| 1508 | |
| 1509 | D'autres fonctionnalités d'usage moins courant sont disponibles. Il s'agit |
willy tarreau | 8f635a4 | 2006-05-21 23:05:54 +0200 | [diff] [blame] | 1510 | principalement du mode transparent, de la journalisation des connexions, de la |
| 1511 | réécriture des en-têtes, et du statut sous forme de page HTML. |
| 1512 | |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1513 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 1514 | 4.1) Fonctionnalités réseau |
| 1515 | --------------------------- |
| 1516 | 4.1.1) Fonctionnement en mode transparent |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1517 | --------------------------------------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1518 | En mode HTTP, le mot clé 'transparent' permet d'intercepter des sessions |
| 1519 | routées à travers la machine hébergeant le proxy. Dans ce mode, on ne précise |
| 1520 | pas l'adresse de répartition 'dispatch', car celle-ci est tirée de l'adresse |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1521 | destination de la session détournée. Le système doit permettre de rediriger les |
| 1522 | paquets vers un processus local. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1523 | |
| 1524 | Exemple : |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1525 | --------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1526 | listen http_proxy 0.0.0.0:65000 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1527 | mode http |
| 1528 | transparent |
| 1529 | cookie SERVERID |
| 1530 | server server01 192.168.1.1:80 |
| 1531 | server server02 192.168.1.2:80 |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 1532 | |
| 1533 | # iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \ |
| 1534 | --dport 80 -j REDIRECT --to-ports 65000 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1535 | |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1536 | Remarque : |
| 1537 | ---------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1538 | Si le port n'est pas spécifié sur le serveur, c'est le port auquel s'est |
| 1539 | adressé le client qui sera utilisé. Cela permet de relayer tous les ports TCP |
| 1540 | d'une même adresse avec une même instance et sans utiliser directement le mode |
| 1541 | transparent. |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1542 | |
| 1543 | Exemple : |
| 1544 | --------- |
| 1545 | listen http_proxy 0.0.0.0:65000 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1546 | mode tcp |
| 1547 | server server01 192.168.1.1 check port 60000 |
| 1548 | server server02 192.168.1.2 check port 60000 |
willy tarreau | a41a8b4 | 2005-12-17 14:02:24 +0100 | [diff] [blame] | 1549 | |
| 1550 | # iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \ |
| 1551 | -j REDIRECT --to-ports 65000 |
| 1552 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 1553 | |
| 1554 | 4.1.2) Choix d'une adresse source par serveur |
| 1555 | --------------------------------------------------- |
| 1556 | Avec les versions 1.1.30 et 1.2.3, il devient possible de spécifier une adresse |
| 1557 | IP source pour joindre chaque serveur. C'est utile pour joindre des serveurs de |
| 1558 | backup à partir d'un LAN différent, ou pour utiliser des chemins alternatifs |
| 1559 | pour joindre le même serveur. C'est également utilisable pour faciliter une |
| 1560 | répartition de charge selon l'adresse IP source pour des connexions sortantes. |
| 1561 | Bien entendu, la même adresse est utilisée pour les health-checks. |
| 1562 | |
| 1563 | Exemple : |
| 1564 | --------- |
| 1565 | # utiliser une adresse particulière pour joindre les 2 serveur |
| 1566 | listen http_proxy 0.0.0.0:65000 |
| 1567 | mode http |
| 1568 | balance roundrobin |
| 1569 | server server01 192.168.1.1:80 source 192.168.2.13 |
| 1570 | server server02 192.168.1.2:80 source 192.168.2.13 |
| 1571 | |
| 1572 | Exemple : |
| 1573 | --------- |
| 1574 | # utiliser une adresse particulière pour joindre chaque serveur |
| 1575 | listen http_proxy 0.0.0.0:65000 |
| 1576 | mode http |
| 1577 | balance roundrobin |
| 1578 | server server01 192.168.1.1:80 source 192.168.1.1 |
| 1579 | server server02 192.168.2.1:80 source 192.168.2.1 |
| 1580 | |
| 1581 | Exemple : |
| 1582 | --------- |
| 1583 | # faire une répartition d'adresse sources pour joindre le même proxy à |
| 1584 | # travers deux liens WAN |
| 1585 | listen http_proxy 0.0.0.0:65000 |
| 1586 | mode http |
| 1587 | balance roundrobin |
| 1588 | server remote-proxy-way1 192.168.1.1:3128 source 192.168.2.1 |
| 1589 | server remote-proxy-way2 192.168.1.1:3128 source 192.168.3.1 |
| 1590 | |
| 1591 | Exemple : |
| 1592 | --------- |
| 1593 | # forcer une connexion TCP à s'attacher à un port particulier |
| 1594 | listen http_proxy 0.0.0.0:2000 |
| 1595 | mode tcp |
| 1596 | balance roundrobin |
| 1597 | server srv1 192.168.1.1:80 source 192.168.2.1:20 |
| 1598 | server srv2 192.168.1.2:80 source 192.168.2.1:20 |
| 1599 | |
willy tarreau | b952e1d | 2005-12-18 01:31:20 +0100 | [diff] [blame] | 1600 | 4.1.3) Maintien de session TCP (keep-alive) |
| 1601 | ------------------------------------------- |
| 1602 | Avec la version 1.2.7, il devient possible d'activer le maintien de session |
| 1603 | TCP (TCP keep-alive) à la fois côté client et côté serveur. Cela permet |
| 1604 | d'empêcher des sessions longues d'expirer sur des équipements de niveau 4 |
| 1605 | externes tels que des firewalls ou des répartiteurs de charge. Cela permet |
| 1606 | aussi au système de détecter et terminer des sessions figées lorsqu'aucun |
| 1607 | time-out n'a été positionné (fortement déconseillé). Le proxy ne peut pas |
| 1608 | positionner l'intervalle entre les annonces ni le nombre maximal, veuillez |
| 1609 | vous référer au manuel du système d'exploitation pour cela. Il existe 3 options |
| 1610 | pour activer le maintien de session TCP : |
| 1611 | |
| 1612 | option tcpka # active le keep-alive côté client et côté serveur |
| 1613 | option clitcpka # active le keep-alive côté client |
| 1614 | option srvtcpka # active le keep-alive côté serveur |
| 1615 | |
Alexandre Cassen | 87ea548 | 2007-10-11 20:48:58 +0200 | [diff] [blame] | 1616 | 4.1.4) Rémanence des données TCP (lingering) |
| 1617 | -------------------------------------------- |
| 1618 | Il est possible de désactiver la conservation de données non acquittées par un |
| 1619 | client à la fin d'une session. Cela peut parfois s'avérer nécessaire lorsque |
| 1620 | haproxy est utilisé en face d'un grand nombre de clients non fiables et qu'un |
| 1621 | nombre élevé de sockets en état FIN_WAIT est observé sur la machine. L'option |
| 1622 | peut être utilisée dans un frontend pour ajuster les connexions vers les |
| 1623 | clients, et dans un backend pour ajuster les connexions vers les serveurs : |
| 1624 | |
| 1625 | option nolinger # désactive la conservation de données |
| 1626 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1627 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1628 | 4.2) Journalisation des connexions |
| 1629 | ---------------------------------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1630 | |
| 1631 | L'un des points forts de HAProxy est indéniablement la précision de ses logs. |
| 1632 | Il fournit probablement le plus fin niveau d'information disponible pour un |
| 1633 | tel outil, ce qui est très important pour les diagnostics en environnements |
| 1634 | complexes. En standard, les informations journalisées incluent le port client, |
| 1635 | les chronométrages des états TCP/HTTP, des états de session précis au moment de |
| 1636 | la terminaison et sa cause, des informations sur les décisions d'aiguillage du |
| 1637 | trafic vers un serveur, et bien sûr la possibilité de capturer des en-têtes |
| 1638 | arbitraires. |
| 1639 | |
| 1640 | Dans le but d'améliorer la réactivité des administrateurs, il offre une grande |
| 1641 | transparence sur les problèmes rencontrés, à la fois internes et externes, et |
| 1642 | il est possible d'envoyer les logs vers des serveurs différents en même temps |
| 1643 | avec des niveaux de filtrage différents : |
| 1644 | |
| 1645 | - logs globaux au niveau processus (erreurs système, arrêts/démarrages, ...) |
| 1646 | - erreurs système et internes par instance (manque de ressources, bugs, ...) |
| 1647 | - problèmes externes par instance (arrêts/relance serveurs, limites, ...) |
| 1648 | - activité par instance (connexions clients), aussi bien lors de leur |
| 1649 | établissement qu'à leur terminaison. |
| 1650 | |
| 1651 | La possibilité de distribuer différents niveaux de logs à différents serveurs |
| 1652 | permet à plusieurs équipes de production d'intéragir et de corriger leurs |
| 1653 | problèmes le plus tôt possible. Par exemple, l'équipe système peut surveiller |
| 1654 | occasionnellement les erreurs système, pendant que l'équipe application |
| 1655 | surveille les alertes d'arrêts/démarrages de ses serveurs en temps réel, et |
| 1656 | que l'équipe sécurité analyse l'activité en différé d'une heure. |
| 1657 | |
| 1658 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1659 | 4.2.1) Niveaux de log |
| 1660 | --------------------- |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1661 | Les connexions TCP et HTTP peuvent donner lieu à une journalisation sommaire ou |
| 1662 | détaillée indiquant, pour chaque connexion, la date, l'heure, l'adresse IP |
| 1663 | source, le serveur destination, la durée de la connexion, les temps de réponse, |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1664 | la requête HTTP, le code de retour, la quantité de données transmises, et même |
| 1665 | dans certains cas, la valeur d'un cookie permettant de suivre les sessions. |
| 1666 | Tous les messages sont envoyés en syslog vers un ou deux serveurs. Se référer à |
| 1667 | la section 1.1 pour plus d'information sur les catégories de logs. La syntaxe |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1668 | est la suivante : |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1669 | |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 1670 | log <adresse_ip_1> <catégorie_1> [niveau_max_1] |
| 1671 | log <adresse_ip_2> <catégorie_2> [niveau_max_2] |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1672 | ou |
| 1673 | log global |
| 1674 | |
| 1675 | Remarque : |
| 1676 | ---------- |
| 1677 | La syntaxe spécifique 'log global' indique que l'on souhaite utiliser les |
| 1678 | paramètres de journalisation définis dans la section 'global'. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1679 | |
| 1680 | Exemple : |
| 1681 | --------- |
| 1682 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1683 | mode http |
| 1684 | log 192.168.2.200 local3 |
| 1685 | log 192.168.2.201 local4 |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 1686 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1687 | 4.2.2) Format des logs |
| 1688 | ---------------------- |
| 1689 | Par défaut, les connexions sont journalisées au niveau TCP dès l'établissement |
| 1690 | de la session entre le client et le relais. En précisant l'option 'tcplog', |
| 1691 | la connexion ne sera journalisée qu'en fin de session, ajoutant des précisions |
| 1692 | sur son état lors de la déconnexion, ainsi que le temps de connexion et la |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1693 | durée totale de la session. Le nombre de sessions restantes après la |
| 1694 | déconnexion est également indiqué (pour le serveur, l'instance et le process). |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1695 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1696 | Exemple de journalisation TCP : |
| 1697 | ------------------------------- |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1698 | listen relais-tcp 0.0.0.0:8000 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1699 | mode tcp |
| 1700 | option tcplog |
| 1701 | log 192.168.2.200 local3 |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1702 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1703 | >>> haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/0/5007 0 -- 1/1/1 0/0 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1704 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1705 | Champ Format / Description Exemple |
| 1706 | |
| 1707 | 1 nom_processus '[' pid ']:' haproxy[18989]: |
| 1708 | 2 ip_client ':' port_client 127.0.0.1:34550 |
| 1709 | 3 '[' date ']' [15/Oct/2003:15:24:28] |
| 1710 | 4 nom_instance relais-tcp |
| 1711 | 5 nom_serveur Srv1 |
| 1712 | 6 temps_file '/' temps_connect '/' temps_total 0/0/5007 |
| 1713 | 7 octets lus 0 |
| 1714 | 8 etat_terminaison -- |
| 1715 | 9 conn_srv '/' conns_inst '/' conns_processus 1/1/1 |
| 1716 | 10 position en file d'attente srv '/' globale 0/0 |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1717 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1718 | Une autre option, 'httplog', fournit plus de détails sur le protocole HTTP, |
| 1719 | notamment la requête et l'état des cookies. Dans les cas où un mécanisme de |
| 1720 | surveillance effectuant des connexions et déconnexions fréquentes, polluerait |
| 1721 | les logs, il suffit d'ajouter l'option 'dontlognull', pour ne plus obtenir une |
| 1722 | ligne de log pour les sessions n'ayant pas donné lieu à un échange de données |
| 1723 | (requête ou réponse). |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 1724 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1725 | Exemple de journalisation HTTP : |
| 1726 | -------------------------------- |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1727 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1728 | mode http |
| 1729 | option httplog |
| 1730 | option dontlognull |
| 1731 | log 192.168.2.200 local3 |
| 1732 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1733 | >>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/0/7/147/723 200 243 - - ---- 2/3/3 0/0 "HEAD / HTTP/1.0" |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1734 | |
| 1735 | Exemple plus complet : |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1736 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1737 | haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/-1/11215 503 0 - - SC-- 137/202/205 0/0 {w.ods.org|Mozilla} {} "HEAD / HTTP/1.0" |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1738 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1739 | Champ Format / Description Exemple |
| 1740 | |
| 1741 | 1 nom_processus '[' pid ']:' haproxy[18989]: |
| 1742 | 2 ip_client ':' port_client 10.0.0.1:34552 |
| 1743 | 3 '[' date ']' [15/Oct/2003:15:26:31] |
| 1744 | 4 nom_instance relais-http |
| 1745 | 5 nom_serveur Srv1 |
| 1746 | 6 Tq '/' Tw '/' Tc '/' Tr '/' Tt 3183/-1/-1/-1/11215 |
| 1747 | 7 Code_retour_HTTP 503 |
| 1748 | 8 octets lus 0 |
| 1749 | 9 cookies_requête_capturés - |
| 1750 | 10 cookies_reponse_capturés - |
| 1751 | 11 etat_terminaison SC-- |
| 1752 | 12 conns_srv '/' conns_inst '/' conns_processus 137/202/205 |
| 1753 | 13 position file serveur '/' globale 0/0 |
| 1754 | 14 '{' entetes_requête_capturés '}' {w.ods.org|Mozilla} |
| 1755 | 15 '{' entetes_reponse_capturés '}' {} |
| 1756 | 16 '"' requête_HTTP '"' "HEAD / HTTP/1.0" |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1757 | |
| 1758 | Note pour les analyseurs de logs : l'URI est TOUJOURS le dernier champ de la ligne, et |
| 1759 | commence par un guillemet '"'. |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1760 | |
| 1761 | Le problème de loguer uniquement en fin de session, c'est qu'il est impossible |
| 1762 | de savoir ce qui se passe durant de gros transferts ou des sessions longues. |
| 1763 | Pour pallier à ce problème, une nouvelle option 'logasap' a été introduite dans |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1764 | la version 1.1.28 (1.2.1). Lorsqu'elle est activée, le proxy loguera le plus |
| 1765 | tôt possible, c'est à dire juste avant que ne débutent les transferts de |
| 1766 | données. Cela signifie, dans le cas du TCP, qu'il loguera toujours le résultat |
| 1767 | de la connexion vers le serveur, et dans le cas HTTP, qu'il loguera en fin de |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1768 | traitement des en-têtes de la réponse du serveur, auquel cas le nombre d'octets |
| 1769 | représentera la taille des en-têtes retournés au client. |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1770 | |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 1771 | Afin d'éviter toute confusion avec les logs normaux, le temps total de |
| 1772 | transfert et le nombre d'octets transférés sont préfixés d'un signe '+' |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1773 | rappelant que les valeurs réelles sont certainement plus élevées. |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1774 | |
| 1775 | Exemple : |
| 1776 | --------- |
| 1777 | |
| 1778 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1779 | mode http |
| 1780 | option httplog |
| 1781 | option dontlognull |
| 1782 | option logasap |
| 1783 | log 192.168.2.200 local3 |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1784 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1785 | >>> haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- 3/3 "GET /image.iso HTTP/1.0" |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1786 | |
| 1787 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1788 | 4.2.3) Chronométrage des événements |
| 1789 | ----------------------------------- |
| 1790 | Pour déceler des problèmes réseau, les mesures du temps écoulé entre certains |
| 1791 | événements sont d'une très grande utilité. Tous les temps sont mesurés en |
| 1792 | millisecondes (ms). En mode HTTP, quatre points de mesure sont rapportés sous |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1793 | la forme Tq/Tw/Tc/Tr/Tt : |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1794 | |
| 1795 | - Tq: temps total de réception de la requête HTTP de la part du client. |
| 1796 | C'est le temps qui s'est écoulé entre le moment où le client a établi |
| 1797 | sa connexion vers le relais, et le moment où ce dernier a reçu le dernier |
| 1798 | en-tête HTTP validant la fin de la requête. Une valeur '-1' ici indique |
| 1799 | que la requête complète n'a jamais été reçue. |
| 1800 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1801 | - Tw: temps total passé dans les files d'attente avant d'obtenir une place |
| 1802 | vers un serveur. Ceci tient compte à la fois de la file d'attente globale |
| 1803 | et de celle du serveur, et dépend du nombre de requêtes dans la file et du |
| 1804 | temps nécessaire au serveur pour compléter les sessions précédentes. La |
| 1805 | valeur '-1' indique que la requête a été détruite avant d'atteindre une |
| 1806 | file. |
| 1807 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1808 | - Tc: temps d'établissement de la connexion TCP du relais vers le serveur. |
| 1809 | C'est le temps écoulé entre le moment ou le relais a initié la demande de |
| 1810 | connexion vers le serveur, et le moment où ce dernier l'a acquittée, c'est |
| 1811 | à dire le temps entre l'envoi du paquet TCP SYN la réception du SYN/ACK. |
| 1812 | Une valeur '-1' ici indique que la connexion n'a jamais pu être établie |
| 1813 | vers le serveur. |
| 1814 | |
| 1815 | - Tr: temps de réponse du serveur. C'est le temps que le serveur a mis pour |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1816 | renvoyer la totalité des en-têtes HTTP à partir du moment où il a acquitté |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1817 | la connexion. Ca représente exactement le temps de traitement de la |
| 1818 | transaction sans le transfert des données associées. Une valeur '-1' |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1819 | indique que le serveur n'a pas envoyé la totalité de l'en-tête HTTP. |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1820 | |
| 1821 | - Tt: durée de vie totale de la session, entre le moment où la demande de |
| 1822 | connexion du client a été acquittée et le moment où la connexion a été |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 1823 | refermée aux deux extrémités (client et serveur). La signification change |
| 1824 | un peu si l'option 'logasap' est présente. Dans ce cas, le temps correspond |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1825 | uniquement à (Tq + Tw + Tc + Tr), et se trouve préfixé d'un signe '+'. On |
| 1826 | peut donc déduire Td, le temps de transfert des données, en excluant les |
| 1827 | autres temps : |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1828 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1829 | Td = Tt - (Tq + Tw + Tc + Tr) |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1830 | |
| 1831 | Les temps rapportés à '-1' sont simplement à éliminer de cette équation. |
| 1832 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1833 | En mode TCP ('option tcplog'), seuls les deux indicateurs Tw, Tc et Tt sont |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1834 | rapportés. |
| 1835 | |
| 1836 | Ces temps fournissent de précieux renseignement sur des causes probables de |
| 1837 | problèmes. Du fait que le protocole TCP définisse des temps de retransmission |
| 1838 | de 3 secondes, puis 6, 12, etc..., l'observation de temps proches de multiples |
| 1839 | de 3 secondes indique pratiquement toujours des pertes de paquets liés à un |
| 1840 | problème réseau (câble ou négociation). De plus, si <Tt> est proche d'une |
| 1841 | valeur de time-out dans la configuration, c'est souvent qu'une session a été |
| 1842 | abandonnée sur expiration d'un time-out. |
| 1843 | |
| 1844 | Cas les plus fréquents : |
| 1845 | |
| 1846 | - Si Tq est proche de 3000, un paquet a très certainement été perdu entre |
| 1847 | le client et le relais. |
| 1848 | - Si Tc est proche de 3000, un paquet a très certainement été perdu entre |
| 1849 | le relais et le serveur durant la phase de connexion. Cet indicateur |
| 1850 | devrait normalement toujours être très bas (moins de quelques dizaines). |
| 1851 | - Si Tr est presque toujours inférieur à 3000, et que certaines valeurs |
| 1852 | semblent proches de la valeur moyenne majorée de 3000, il y a peut-être |
| 1853 | de pertes entre le relais et le serveur. |
| 1854 | - Si Tt est légèrement supérieur au time-out, c'est souvent parce que le |
| 1855 | client et le serveur utilisent du keep-alive HTTP entre eux et que la |
| 1856 | session est maintenue après la fin des échanges. Voir plus loin pour |
| 1857 | savoir comment désactiver le keep-alive HTTP. |
| 1858 | |
| 1859 | Autres cas ('xx' représentant une valeur quelconque à ignorer) : |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1860 | -1/xx/xx/xx/Tt: le client n'a pas envoyé sa requête dans le temps imparti ou |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1861 | a refermé sa connexion sans compléter la requête. |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1862 | Tq/-1/xx/xx/Tt: Il n'était pas possible de traiter la request, probablement |
| 1863 | parce que tous les serveurs étaient hors d'usage. |
| 1864 | Tq/Tw/-1/xx/Tt: la connexion n'a pas pu s'établir vers le serveur (refus ou |
| 1865 | time-out au bout de Tt-(Tq+Tw) ms). |
| 1866 | Tq/Tw/Tc/-1/Tt: le serveur a accepté la connexion mais n'a pas répondu dans |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1867 | les temps ou bien a refermé sa connexion trop tôt, au bout |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1868 | de Tt-(Tq+Tw+Tc) ms. |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1869 | |
| 1870 | 4.2.4) Conditions de déconnexion |
| 1871 | -------------------------------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1872 | Les logs TCP et HTTP fournissent un indicateur de complétude de la session dans |
| 1873 | le champ 'etat_terminaison', juste avant le nombre de connexions actives. C'est |
| 1874 | un champ long de 2 caractères en TCP et de 4 caractères en HTTP, chacun ayant |
| 1875 | une signification précise : |
| 1876 | |
| 1877 | - sur le premier caractère, un code précisant le premier événement qui a causé |
| 1878 | la terminaison de la session : |
| 1879 | |
| 1880 | C : fermeture inattendue de la session TCP de la part du client. |
| 1881 | |
| 1882 | S : fermeture inattendue de la session TCP de la part du serveur, ou |
| 1883 | refus explicite de connexion de la part de ce dernier. |
| 1884 | |
| 1885 | P : terminaison prématurée des sessions par le proxy, pour cause |
| 1886 | d'imposition d'une limite sur le nombre de connexions, pour cause |
| 1887 | de configuration (ex: filtre d'URL), ou parce qu'un contrôle de |
| 1888 | sécurité a détecté et bloqué une anomalie dans la réponse du |
| 1889 | serveur qui aurait pu causer une fuite d'informations (par exemple, |
| 1890 | un cookie cachable). |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1891 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1892 | R : une ressource sur le proxy a été épuisée (mémoire, sockets, ports |
| 1893 | source, ...). Généralement, cela arrive au cours de l'établissement |
| 1894 | d'une connexion, et les logs système doivent contenir une copie de |
| 1895 | l'érreur précise. |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1896 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1897 | I : une erreur interne a été identifiée par le proxy à la suite d'un |
| 1898 | auto-contrôle. Ceci ne doit JAMAIS arriver, et vous êtes encouragés |
| 1899 | à remonter n'importe quel log contenant ceci car il s'agira un bug. |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1900 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1901 | c : le délai maximal d'attente du client a expiré (clitimeout). |
| 1902 | |
| 1903 | s : le délai maximal d'attente du serveur a expiré (srvtimeout et contimeout) |
| 1904 | |
| 1905 | - : terminaison normale de session. |
| 1906 | |
| 1907 | - sur le second caractère, l'état d'avancement de la session TCP/HTTP lors de |
| 1908 | la fermeture : |
| 1909 | |
| 1910 | R : attente d'une REQUETE HTTP complète de la part du client. Rien n'a |
| 1911 | été transmis au serveur. |
| 1912 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 1913 | Q : attente en file d'attente (QUEUE) d'une place pour avoir une |
| 1914 | connexion vers un serveur. Ne peut apparaître que sur un serveur |
| 1915 | possédant un paramètre 'maxconn'. Aucune connexion n'a été envoyée |
| 1916 | au serveur. |
| 1917 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1918 | C : attente de l'établissement d'une CONNEXION vers le serveur. Le |
| 1919 | serveur peut au plus avoir vu la tentative de connexion, mais |
| 1920 | aucune donnée n'a été échangée. |
| 1921 | |
| 1922 | H : attente, réception ou traitement des en-têtes HTTP ("HEADERS"). |
| 1923 | |
| 1924 | D : transfert des DONNEES du serveur vers le client. |
| 1925 | |
| 1926 | L : transfert des dernières ("LAST") données du proxy vers le client, |
| 1927 | alors que le serveur a déjà fini. |
| 1928 | |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 1929 | T : requête bloquée en mode "tarpit" par le proxy. Elle a été maintenue |
Willy Tarreau | 08fa2e3 | 2006-09-03 10:47:37 +0200 | [diff] [blame] | 1930 | ouverte vers le client pendant toute la durée du contimeout ou |
| 1931 | jusqu'à l'abandon de la part du client. |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 1932 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1933 | - : terminaison normale, après fin de transfert des données. |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1934 | |
| 1935 | - le troisième caractère indique l'éventuelle identification d'un cookie de |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 1936 | persistence (uniquement en mode HTTP) : |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1937 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1938 | N : aucun cookie de persistence n'a été présenté. C'est généralement le |
| 1939 | cas sur les NOUVELLES connexions clients. |
| 1940 | |
| 1941 | I : le client a présenté un cookie INVALIDE ne correspondant à aucun |
| 1942 | serveur connu. Ceci peut être dû à un changement de configuration |
| 1943 | récent, à des mélanges de noms de cookies entre sites HTTP/HTTPS, |
| 1944 | ou à une attaque. |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1945 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1946 | D : le client a présenté un cookie correspondant à un serveur hors |
| 1947 | d'usage ("DOWN"). Suivant l'option 'persist', il a été renvoyé vers |
| 1948 | un autre serveur ou a tout de même tenté de se connecter sur celui |
| 1949 | correspondant au cookie. |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1950 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1951 | V : le client a présenté un cookie VALIDE et a pu se connecter au |
| 1952 | serveur correspondant. |
| 1953 | |
| 1954 | - : non appliquable (pas de cookie positionné dans la configuration). |
| 1955 | |
| 1956 | - le dernier caractère indique l'éventuel traitement effectué sur un cookie de |
| 1957 | persistence retrourné par le serveur (uniquement en mode HTTP) : |
| 1958 | |
| 1959 | N : aucun cookie de persistance n'a été fourni par le serveur, et aucun |
| 1960 | n'a été inséré. |
| 1961 | |
| 1962 | I : aucun cookie de persistance n'a été fourni par le serveur, et le |
| 1963 | proxy en a INSERE un. |
| 1964 | |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 1965 | P : un cookie de persistence a été fourni par le serveur et transmis |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1966 | tel quel ("PASSIF"). |
| 1967 | |
| 1968 | R : le cookie retourné par le serveur a été REECRIT par le proxy. |
| 1969 | |
| 1970 | D : le cookie présenté par le serveur a été DETRUIT par le proxy pour |
| 1971 | ne pas être retourné au client. |
| 1972 | |
| 1973 | - : non appliquable |
| 1974 | |
| 1975 | |
| 1976 | La combinaison des deux premiers indicateurs fournit une grande quantitié |
| 1977 | d'informations sur ce qui se passait lorsque la session s'est terminée. Cela |
| 1978 | peut notamment aider à détecter une saturation de serveur, des troubles réseau, |
| 1979 | des épuisements de ressources système locales, des attaques, etc... |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 1980 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 1981 | Les combinaisons d'indicateurs les plus fréquentes sont énumérées ici. |
| 1982 | |
| 1983 | Indic Raison |
| 1984 | CR Le client a abandonné avant d'émettre une requête complète. Il est |
| 1985 | très probable que la requête ait été tapée à la main dans un client |
| 1986 | telnet et abortée trop tôt. |
| 1987 | |
| 1988 | cR Le temps imparti au client a expiré avant réception d'une requête |
| 1989 | complète. Ceci est parfois causé par un paramètre TCP MSS trop élevé |
| 1990 | sur le client pour des réseaux PPPoE sur ADSL qui ne peuvent pas |
| 1991 | transporter des paquets entiers, ou par des clients qui énvoient des |
| 1992 | requêtes à la main et ne tapent pas assez vite. |
| 1993 | |
| 1994 | SC Le serveur a explicitement refusé la connexion (le proxy a reçu un |
| 1995 | RST TCP ou un message ICMP en retour). Dans certains cas, cela peut |
| 1996 | être la couche réseau qui indique au proxy que le serveur n'est pas |
| 1997 | joignable (p.ex: pas de route, pas de réponse ARP en local, etc...) |
| 1998 | |
| 1999 | sC La connexion au serveur n'a pas pu s'établir dans le temps imparti. |
| 2000 | |
| 2001 | PC Le proxy a refusé d'établir une connexion au serveur parce que le |
| 2002 | nombre de connexions a atteint la limite 'maxconn' (global ou de |
| 2003 | l'instance). Le paramètre 'maxconn' de l'instance pourrait être |
| 2004 | augmenté, tout comme le paramètre 'maxconn' global. |
| 2005 | |
| 2006 | RC Une ressource locale a été épuisée (mémoire, sockets, ports source), |
| 2007 | empêchant la connexion au serveur de s'établir. Les logs d'erreurs |
| 2008 | diront précisément ce qui manquait. Dans tous les cas, le seul remède |
| 2009 | consiste à affiner le paramétrage système. |
| 2010 | |
| 2011 | cH Le temps imparti au client a expiré au cours d'une requête POST. Ceci |
| 2012 | est parfois causé par un paramètre TCP MSS trop élevé sur le client |
| 2013 | pour des réseaux PPPoE sur ADSL qui ne peuvent pas transporter des |
| 2014 | paquets entiers. |
| 2015 | |
willy tarreau | 078c79a | 2006-05-13 12:23:58 +0200 | [diff] [blame] | 2016 | CH Le client a abandonné alors qu'il attendait un début de réponse de la |
| 2017 | part du serveur. Cela peut être causé par le serveur qui mettait trop |
| 2018 | de temps à répondre, ou par un client cliquant précipitamment sur le |
| 2019 | bouton 'Stop'. |
| 2020 | |
| 2021 | CQ Le client a abandonné alors que sa session était mise en file |
| 2022 | d'attente pour obtenir un serveur avec suffisamment de connexions |
| 2023 | libres pour l'accepter. Cela signifie soit que l'ensemble des |
| 2024 | serveurs étaient saturés, soit que le serveur assigné a mis trop de |
| 2025 | temps à répondre. |
| 2026 | |
Willy Tarreau | 08fa2e3 | 2006-09-03 10:47:37 +0200 | [diff] [blame] | 2027 | CT Le client a abandonné alors que sa session était bloquée en mode |
| 2028 | tarpit. |
| 2029 | |
willy tarreau | 078c79a | 2006-05-13 12:23:58 +0200 | [diff] [blame] | 2030 | sQ La session a attendu trop longtemps en file d'attente et a été |
| 2031 | expirée. |
| 2032 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2033 | SH Le serveur a aborté brutalement alors qu'il devait envoyer ses |
| 2034 | en-têtes. En général, cela indique qu'il a crashé. |
| 2035 | |
| 2036 | sH Le serveur n'a pas pu répondre durant le temps imparti, ce qui montre |
| 2037 | des transactions trop longues, probablement causées par un back-end |
| 2038 | saturé. Les seules solutions sont de corriger le problème sur |
| 2039 | l'application, d'accroître le paramètre 'srvtimeout' pour supporter |
| 2040 | des attentes plus longues au risque que les clients abandonnent à |
| 2041 | leur tour, ou bien d'ajouter des serveurs. |
| 2042 | |
| 2043 | PR Le proxy a bloqué une requête du client, soit à cause d'une syntaxe |
| 2044 | HTTP invalide, auquel cas il a renvoyé une erreur HTTP 400 au client, |
| 2045 | soit à cause d'une requête validant un filtre d'interdiction, auquel |
| 2046 | cas le proxy a renvoyé une erreur HTTP 403. |
| 2047 | |
| 2048 | PH Le proxy a bloqué la réponse du serveur parce qu'elle était invalide, |
| 2049 | incomplète, dangereuse ('cache control'), ou parce qu'elle validait |
| 2050 | un filtre de sécurité. Dans tous les cas, une erreur HTTP 502 est |
| 2051 | renvoyée au client. |
| 2052 | |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 2053 | PT Le proxy a bloqué une requête du client et a maintenu sa connection |
| 2054 | ouverte avant de lui retourner une erreur "500 server error". Rien |
| 2055 | n'a été envoyé au serveur. |
| 2056 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2057 | cD Le client n'a pas lu de données pendant le temps qui lui était |
| 2058 | imparti. Ceci est souvent causé par des problèmes réseau côté client. |
| 2059 | |
| 2060 | CD Le client a aborté sa connection de manière inattendue pendant le |
| 2061 | transfert des données. Ceci est provoqué soit par le crash d'un |
| 2062 | navigateur, ou par une session en HTTP keep-alive entre le serveur |
| 2063 | et le client terminée en premier par le client. |
| 2064 | |
| 2065 | sD Le serveur n'a rien fait durant le temps imparti par le paramètre |
| 2066 | 'srvtimeout'. Ceci est souvent causé par des timeouts trop courts |
| 2067 | sur des équipements de niveau 4 (firewalls, répartiteurs de charge) |
| 2068 | situés entre le proxy et le serveur. |
| 2069 | |
| 2070 | 4.2.5) Caractères non-imprimables |
| 2071 | --------------------------------- |
| 2072 | Depuis la version 1.1.29, les caractères non-imprimables ne sont plus envoyés |
| 2073 | tels quels dans les lignes de logs, mais inscrits sous la forme de deux chiffres |
| 2074 | hexadécimaux, préfixés du caractère d'échappement '#'. Les seuls caractères |
| 2075 | dorénavant logués tels quels sont compris entre 32 et 126. Bien évidemment, le |
| 2076 | caractère d'échappement '#' est lui-même encodé afin de lever l'ambiguité. Il en |
| 2077 | est de même pour le caractère '"', ainsi que les caractères '{', '|' et '}' pour |
| 2078 | les en-têtes. |
| 2079 | |
| 2080 | 4.2.6) Capture d'en-têtes HTTP et de cookies |
| 2081 | -------------------------------------------- |
| 2082 | La version 1.1.23 a apporté la capture des cookies, et la version 1.1.29 la |
| 2083 | capture d'en-têtes. Tout ceci est effectué en utilisant le mot-clé 'capture'. |
| 2084 | |
| 2085 | Les captures de cookies facilitent le suivi et la reconstitution d'une session |
| 2086 | utilisateur. La syntaxe est la suivante : |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2087 | |
| 2088 | capture cookie <préfixe_cookie> len <longueur_capture> |
| 2089 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2090 | Ceci activera la capture de cookies à la fois dans les requêtes et dans les |
| 2091 | réponses. De cette manière, il devient facile de détecter lorsqu'un utilisateur |
| 2092 | bascule sur une nouvelle session par exemple, car le serveur lui réassignera un |
| 2093 | nouveau cookie. |
| 2094 | |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2095 | Le premier cookie dont le nom commencera par <préfixe_cookie> sera capturé, et |
| 2096 | transmis sous la forme "NOM=valeur", sans toutefois, excéder <longueur_capture> |
| 2097 | caractères (64 au maximum). Lorsque le nom du cookie est fixe et connu, on peut |
| 2098 | le suffixer du signe "=" pour s'assurer qu'aucun autre cookie ne prendra sa |
| 2099 | place dans les logs. |
| 2100 | |
| 2101 | Exemples : |
| 2102 | ---------- |
| 2103 | # capture du premier cookie dont le nom commence par "ASPSESSION" |
| 2104 | capture cookie ASPSESSION len 32 |
| 2105 | |
| 2106 | # capture du premier cookie dont le nom est exactement "vgnvisitor" |
| 2107 | capture cookie vgnvisitor= len 32 |
| 2108 | |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 2109 | Dans les logs, le champ précédant l'indicateur de complétude contient le cookie |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 2110 | positionné par le serveur, précédé du cookie positionné par le client. Chacun |
| 2111 | de ces champs est remplacé par le signe "-" lorsqu'aucun cookie n'est fourni |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2112 | par le client ou le serveur, ou lorsque l'option est désactivée.. |
| 2113 | |
| 2114 | Les captures d'en-têtes ont un rôle complètement différent. Elles sont utiles |
| 2115 | pour suivre un identifiant de requête globalement unique positionné par un |
| 2116 | autre proxy en amont, pour journaliser les noms de serveurs virtuels, les types |
| 2117 | de clients web, la longueur des POST, les 'referrers', etc. Dans la réponse, on |
| 2118 | peut chercher des informations relatives à la longueur annoncée de la réponse, |
| 2119 | le fonctionnement attendu du cache, ou encore la localisation d'un objet en cas |
| 2120 | de redirection. Tout comme pour les captures de cookies, il est possible |
| 2121 | d'inclure les en-têtes de requêtes et de réponse simultanément. La syntaxe est |
| 2122 | la suivante : |
| 2123 | |
| 2124 | capture request header <nom> len <longueur max> |
| 2125 | capture response header <nom> len <longueur max> |
| 2126 | |
| 2127 | Note: Les noms d'en-têtes ne sont pas sensibles à la casse. |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2128 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2129 | Exemples: |
| 2130 | --------- |
| 2131 | # conserver le nom du serveur virtuel accédé par le client |
| 2132 | capture request header Host len 20 |
| 2133 | # noter la longueur des données envoyées dans un POST |
| 2134 | capture request header Content-Length len 10 |
| 2135 | |
| 2136 | # noter le fonctionnement attendu du cache par le serveur |
| 2137 | capture response header Cache-Control len 8 |
| 2138 | # noter l'URL de redirection |
| 2139 | capture response header Location len 20 |
| 2140 | |
| 2141 | Les en-têtes non trouvés sont logués à vide, et si un en-tête apparait plusieurs |
| 2142 | fois, seule la dernière occurence sera conservée. Les en-têtes de requête sont |
| 2143 | regroupés entre deux accolades '{' et '}' dans l'ordre de leur déclaration, et |
| 2144 | chacun séparés par une barre verticale '|', sans aucun espace. Les en-têtes de |
| 2145 | réponse sont présentés de la même manière, mais après un espace suivant le bloc |
| 2146 | d'en-tête de requête. Le tout précède la requête HTTP. Exemple : |
| 2147 | |
| 2148 | Config: |
| 2149 | |
| 2150 | capture request header Host len 20 |
| 2151 | capture request header Content-Length len 10 |
| 2152 | capture request header Referer len 20 |
| 2153 | capture response header Server len 20 |
| 2154 | capture response header Content-Length len 10 |
| 2155 | capture response header Cache-Control len 8 |
| 2156 | capture response header Via len 20 |
| 2157 | capture response header Location len 20 |
| 2158 | |
| 2159 | Log : |
| 2160 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2161 | Aug 9 20:26:09 localhost haproxy[2022]: 127.0.0.1:34014 [09/Aug/2004:20:26:09] relais-http netcache 0/0/0/162/+162 200 +350 - - ---- 0/0/0 0/0 {fr.adserver.yahoo.co||http://fr.f416.mail.} {|864|private||} "GET http://fr.adserver.yahoo.com/" |
| 2162 | Aug 9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34020 [09/Aug/2004:20:30:46] relais-http netcache 0/0/0/182/+182 200 +279 - - ---- 0/0/0 0/0 {w.ods.org||} {Formilux/0.1.8|3495|||} "GET http://w.ods.org/sytadin.html HTTP/1.1" |
| 2163 | Aug 9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34028 [09/Aug/2004:20:30:46] relais-http netcache 0/0/2/126/+128 200 +223 - - ---- 0/0/0 0/0 {www.infotrafic.com||http://w.ods.org/syt} {Apache/2.0.40 (Red H|9068|||} "GET http://www.infotrafic.com/images/live/cartesidf/grandes/idf_ne.png HTTP/1.1" |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2164 | |
| 2165 | 4.2.7) Exemples de logs |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2166 | ----------------------- |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2167 | - haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/0/7/147/6723 200 243 - - ---- 1/3/5 0/0"HEAD / HTTP/1.0" |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2168 | => requête longue (6.5s) saisie à la main avec un client telnet. Le serveur a |
| 2169 | répondu en 147 ms et la session s'est terminée normalement ('----') |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2170 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2171 | - haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/1230/7/147/6870 200 243 - - ---- 99/239/324 0/9 "HEAD / HTTP/1.0" |
| 2172 | => Idem, mais la requête a été mise en attente dans la file globale derrière |
| 2173 | 9 autres requêtes déjà présentes, et y a attendu 1230 ms. |
| 2174 | |
| 2175 | - haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/0/7/14/+30 200 +243 - - ---- 1/3/3 0/0 "GET /image.iso HTTP/1.0" |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2176 | => requête pour un long transfert. L'option 'logasap' était spécifiée donc le |
| 2177 | log a été généré juste avant le transfert de données. Le serveur a répondu |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2178 | en 14 ms, 243 octets d'en-têtes ont été transférés au client, et le temps |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2179 | total entre l'accept() et le premier octet de donnée est de 30 ms. |
| 2180 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2181 | - haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/0/7/14/30 502 243 - - PH-- 0/2/3 0/0 "GET /cgi-bin/bug.cgi? HTTP/1.0" |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2182 | => le proxy a bloqué une réponse du serveur soit à cause d'un filtre 'rspdeny' |
| 2183 | ou 'rspideny', soit parce qu'il a détecté un risque de fuite sensible |
| 2184 | d'informations risquant d'être cachées. Dans ce cas, la réponse est |
| 2185 | remplacée par '502 bad gateway'. |
| 2186 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2187 | - haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/-1/8490 -1 0 - - CR-- 0/2/2 0/0 "" |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2188 | => Le client n'a pas envoyé sa requête et a refermé la connexion lui-même |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2189 | ('C---') au bout de 8.5s, alors que le relais attendait l'en-tête ('-R--'). |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2190 | Aucune connexion n'a été envoyée vers le serveur. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2191 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2192 | - haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/-1/50001 408 0 - - cR-- 0/2/2 0/0 "" |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2193 | => Le client n'a pas envoyé sa requête et son time-out a expiré ('c---') au |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2194 | bout de 50s, alors que le relais attendait l'en-tête ('-R--'). Aucune |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2195 | connexion n'a été envoyée vers le serveur, mais le relais a tout de même |
| 2196 | pu renvoyer un message 408 au client. |
| 2197 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2198 | - haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 cD |
| 2199 | => log en mode 'tcplog'. Expiration du time-out côté client ('cD') au bout de |
| 2200 | 5s. |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2201 | |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2202 | - haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/-1/11215 503 0 - - SC-- 115/202/205 0/0 "HEAD / HTTP/1.0" |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2203 | => La requête client met 3s à entrer (peut-être un problème réseau), et la |
| 2204 | connexion ('SC--') vers le serveur échoue au bout de 4 tentatives de 2 |
willy tarreau | 532bb55 | 2006-05-13 18:40:37 +0200 | [diff] [blame] | 2205 | secondes (retries 3 dans la conf), puis un code 503 est retourné au |
| 2206 | client. Il y avait 115 connexions sur ce serveur, 202 connexions sur cette |
| 2207 | instance, et 205 sur l'ensemble des instances pour ce processus. Il est |
| 2208 | possible que le serveur ait refusé la connexion parce qu'il y en avait |
| 2209 | déjà trop d'établies. |
willy tarreau | 4302f49 | 2005-12-18 01:00:37 +0100 | [diff] [blame] | 2210 | |
willy tarreau | 4302f49 | 2005-12-18 01:00:37 +0100 | [diff] [blame] | 2211 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2212 | 4.3) Modification des en-têtes HTTP |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2213 | ---------------------------------- |
| 2214 | En mode HTTP uniquement, il est possible de remplacer certains en-têtes dans la |
| 2215 | requête et/ou la réponse à partir d'expressions régulières. Il est également |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 2216 | possible de bloquer certaines requêtes en fonction du contenu des en-têtes ou |
| 2217 | de la requête. Une limitation cependant : les en-têtes fournis au milieu de |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2218 | connexions persistentes (keep-alive) ne sont pas vus car ils sont considérés |
| 2219 | comme faisant partie des échanges de données consécutifs à la première requête. |
| 2220 | Les données ne sont pas affectées, ceci ne s'applique qu'aux en-têtes. |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2221 | |
| 2222 | La syntaxe est : |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2223 | reqadd <string> pour ajouter un en-tête dans la requête |
| 2224 | reqrep <search> <replace> pour modifier la requête |
| 2225 | reqirep <search> <replace> idem sans distinction majuscules/minuscules |
| 2226 | reqdel <search> pour supprimer un en-tête dans la requête |
| 2227 | reqidel <search> idem sans distinction majuscules/minuscules |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2228 | reqallow <search> autoriser la requête si un en-tête valide <search> |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2229 | reqiallow <search> idem sans distinction majuscules/minuscules |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2230 | reqdeny <search> interdire la requête si un en-tête valide <search> |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 2231 | reqideny <search> idem sans distinction majuscules/minuscules |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2232 | reqpass <search> inhibe ces actions sur les en-têtes validant <search> |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 2233 | reqipass <search> idem sans distinction majuscules/minuscules |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 2234 | reqtarpit <search> bloquer et maintenir une request validant <search> |
| 2235 | reqitarpit <search> idem sans distinction majuscules/minuscules |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2236 | |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 2237 | rspadd <string> pour ajouter un en-tête dans la réponse |
| 2238 | rsprep <search> <replace> pour modifier la réponse |
| 2239 | rspirep <search> <replace> idem sans distinction majuscules/minuscules |
| 2240 | rspdel <search> pour supprimer un en-tête dans la réponse |
| 2241 | rspidel <search> idem sans distinction majuscules/minuscules |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2242 | rspdeny <search> remplace la réponse par un HTTP 502 si un |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2243 | en-tête valide <search> |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2244 | rspideny <search> idem sans distinction majuscules/minuscules |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2245 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2246 | |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 2247 | <search> est une expression régulière compatible POSIX regexp supportant le |
| 2248 | groupage par parenthèses (sans les '\'). Les espaces et autres séparateurs |
| 2249 | doivent êtres précédés d'un '\' pour ne pas être confondus avec la fin de la |
| 2250 | chaîne. De plus, certains caractères spéciaux peuvent être précédés d'un |
| 2251 | backslach ('\') : |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2252 | |
| 2253 | \t pour une tabulation |
| 2254 | \r pour un retour charriot |
| 2255 | \n pour un saut de ligne |
| 2256 | \ pour différencier un espace d'un séparateur |
| 2257 | \# pour différencier un dièse d'un commentaire |
willy tarreau | 036e1ce | 2005-12-17 13:46:33 +0100 | [diff] [blame] | 2258 | \\ pour utiliser un backslash dans la regex |
| 2259 | \\\\ pour utiliser un backslash dans le texte |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2260 | \xXX pour un caractère spécifique XX (comme en C) |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2261 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2262 | |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2263 | <replace> contient la chaîne remplaçant la portion vérifiée par l'expression. |
| 2264 | Elle peut inclure les caractères spéciaux ci-dessus, faire référence à un |
| 2265 | groupe délimité par des parenthèses dans l'expression régulière, par sa |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 2266 | position numérale. Les positions vont de 0 à 9, et sont codées par un '\' |
| 2267 | suivi du chiffre désiré (0 désignant la ligne complète). Il est également |
| 2268 | possible d'insérer un caractère non imprimable (utile pour le saut de ligne) |
| 2269 | inscrivant '\x' suivi du code hexadécimal de ce caractère (comme en C). |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2270 | |
| 2271 | <string> représente une chaîne qui sera ajoutée systématiquement après la |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2272 | dernière ligne d'en-tête. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2273 | |
| 2274 | Remarques : |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2275 | ----------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2276 | - la première ligne de la requête et celle de la réponse sont traitées comme |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2277 | des en-têtes, ce qui permet de réécrire des URL et des codes d'erreur. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2278 | - 'reqrep' est l'équivalent de 'cliexp' en version 1.0, et 'rsprep' celui de |
| 2279 | 'srvexp'. Ces noms sont toujours supportés mais déconseillés. |
| 2280 | - pour des raisons de performances, le nombre total de caractères ajoutés sur |
willy tarreau | 535ae7a | 2005-12-17 12:58:00 +0100 | [diff] [blame] | 2281 | une requête ou une réponse est limité à 4096 depuis la version 1.1.5 (cette |
| 2282 | limite était à 256 auparavant). Cette valeur est modifiable dans le code. |
| 2283 | Pour un usage temporaire, on peut gagner de la place en supprimant quelques |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2284 | en-têtes inutiles avant les ajouts. |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2285 | - une requête bloquée produira une réponse "HTTP 403 forbidden" tandis qu'une |
| 2286 | réponse bloquée produira une réponse "HTTP 502 Bad gateway". |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 2287 | - une requête bloquée par 'reqtarpit' sera maintenue pendant une durée égale |
Willy Tarreau | 08fa2e3 | 2006-09-03 10:47:37 +0200 | [diff] [blame] | 2288 | au paramètre 'contimeout', ou jusqu'à l'abandon du client. Rien ne sera |
| 2289 | envoyé au serveur. Lorsque le temps alloué expire, le proxy répondra avec |
| 2290 | une réponse "500 server error" de sorte que l'attaquant ne suspecte pas |
| 2291 | qu'il ait été bloqué. Les logs rapporteront aussi ce code 500, mais les |
| 2292 | flags de terminaison indiqueront "PT". |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2293 | |
| 2294 | Exemples : |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2295 | ---------- |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2296 | ###### a few examples ###### |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2297 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2298 | # rewrite 'online.fr' instead of 'free.fr' for GET and POST requests |
| 2299 | reqrep ^(GET\ .*)(.free.fr)(.*) \1.online.fr\3 |
| 2300 | reqrep ^(POST\ .*)(.free.fr)(.*) \1.online.fr\3 |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2301 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2302 | # force proxy connections to close |
| 2303 | reqirep ^Proxy-Connection:.* Proxy-Connection:\ close |
| 2304 | # rewrite locations |
| 2305 | rspirep ^(Location:\ )([^:]*://[^/]*)(.*) \1\3 |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2306 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2307 | ###### A full configuration being used on production ###### |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2308 | |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2309 | # Every header should end with a colon followed by one space. |
| 2310 | reqideny ^[^:\ ]*[\ ]*$ |
| 2311 | |
| 2312 | # block Apache chunk exploit |
| 2313 | reqideny ^Transfer-Encoding:[\ ]*chunked |
| 2314 | reqideny ^Host:\ apache- |
| 2315 | |
| 2316 | # block annoying worms that fill the logs... |
| 2317 | reqideny ^[^:\ ]*\ .*(\.|%2e)(\.|%2e)(%2f|%5c|/|\\\\) |
| 2318 | reqideny ^[^:\ ]*\ ([^\ ]*\ [^\ ]*\ |.*%00) |
| 2319 | reqideny ^[^:\ ]*\ .*<script |
| 2320 | reqideny ^[^:\ ]*\ .*/(root\.exe\?|cmd\.exe\?|default\.ida\?) |
| 2321 | |
Willy Tarreau | 2272dc1 | 2006-09-03 10:19:38 +0200 | [diff] [blame] | 2322 | # tarpit attacks on the login page. |
| 2323 | reqtarpit ^[^:\ ]*\ .*\.php?login=[^0-9] |
| 2324 | |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2325 | # allow other syntactically valid requests, and block any other method |
| 2326 | reqipass ^(GET|POST|HEAD|OPTIONS)\ /.*\ HTTP/1\.[01]$ |
| 2327 | reqipass ^OPTIONS\ \\*\ HTTP/1\.[01]$ |
| 2328 | reqideny ^[^:\ ]*\ |
| 2329 | |
| 2330 | # force connection:close, thus disabling HTTP keep-alive |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2331 | option httpclos |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2332 | |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2333 | # change the server name |
willy tarreau | 197e8ec | 2005-12-17 14:10:59 +0100 | [diff] [blame] | 2334 | rspidel ^Server:\ |
| 2335 | rspadd Server:\ Formilux/0.1.8 |
| 2336 | |
willy tarreau | 0f7af91 | 2005-12-17 12:21:26 +0100 | [diff] [blame] | 2337 | |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2338 | De plus, l'option 'forwardfor' ajoute l'adresse IP du client dans un champ |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2339 | 'X-Forwarded-For' de la requête, ce qui permet à un serveur web final de |
Willy Tarreau | 7ac51f6 | 2007-03-25 16:00:04 +0200 | [diff] [blame] | 2340 | connaître l'adresse IP du client initial. Depuis la version 1.3.8, il est |
| 2341 | possible de préciser le mot-clé "except" suivi d'une adresse ou un réseau |
| 2342 | IP source pour lequel l'entête ne sera pas ajouté. C'est très pratique dans le |
| 2343 | cas où un autre reverse-proxy ajoutant déjà l'entête est installé sur la même |
| 2344 | machine ou dans une DMZ connue. Le cas le plus fréquent est lié à l'utilisation |
| 2345 | de stunnel en local. |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2346 | |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2347 | Enfin, l'option 'httpclose' apparue dans la version 1.1.28/1.2.1 supprime tout |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2348 | en-tête de type 'Connection:' et ajoute 'Connection: close' dans les deux sens. |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2349 | Ceci simplifie la désactivation du keep-alive HTTP par rapport à l'ancienne |
| 2350 | méthode impliquant 4 règles. |
| 2351 | |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2352 | Exemple : |
| 2353 | --------- |
| 2354 | listen http_proxy 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2355 | mode http |
| 2356 | log global |
| 2357 | option httplog |
| 2358 | option dontlognull |
Willy Tarreau | 7ac51f6 | 2007-03-25 16:00:04 +0200 | [diff] [blame] | 2359 | option forwardfor except 127.0.0.1/8 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2360 | option httpclose |
willy tarreau | c1cae63 | 2005-12-17 14:12:23 +0100 | [diff] [blame] | 2361 | |
Willy TARREAU | 767ba71 | 2006-03-01 22:40:50 +0100 | [diff] [blame] | 2362 | Notons que certains serveurs HTTP ne referment pas nécessairement la session |
| 2363 | TCP en fin de traitement lorsqu'ils reçoivent un entête 'Connection: close', |
| 2364 | ce qui se traduit par des grands nombres de sessions établies et des temps |
| 2365 | globaux très longs sur les requêtes. Pour contourner ce problème, la version |
| 2366 | 1.2.9 apporte une nouvelle option 'forceclose' qui referme la connexion sortant |
| 2367 | vers le serveur dès qu'il commence à répondre et seulement si le tampon de |
| 2368 | requête est vide. Attention toutefois à ne PAS utiliser cette option si des |
| 2369 | méthodes CONNECT sont attendues entre le client et le serveur. L'option |
| 2370 | 'forceclose' implique l'option 'httpclose'. |
| 2371 | |
| 2372 | Exemple : |
| 2373 | --------- |
| 2374 | listen http_proxy 0.0.0.0:80 |
| 2375 | mode http |
| 2376 | log global |
| 2377 | option httplog |
| 2378 | option dontlognull |
| 2379 | option forwardfor |
| 2380 | option forceclose |
| 2381 | |
| 2382 | |
willy tarreau | c29948c | 2005-12-17 13:10:27 +0100 | [diff] [blame] | 2383 | 4.4) Répartition avec persistence |
| 2384 | --------------------------------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2385 | La combinaison de l'insertion de cookie avec la répartition de charge interne |
| 2386 | permet d'assurer une persistence dans les sessions HTTP d'une manière |
| 2387 | pratiquement transparente pour les applications. Le principe est simple : |
willy tarreau | 96d4037 | 2005-12-17 13:11:56 +0100 | [diff] [blame] | 2388 | - attribuer une valeur d'un cookie à chaque serveur |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2389 | - effectuer une répartition interne |
willy tarreau | 240afa6 | 2005-12-17 13:14:35 +0100 | [diff] [blame] | 2390 | - insérer un cookie dans les réponses issues d'une répartition uniquement, |
| 2391 | et faire en sorte que des caches ne mémorisent pas ce cookie. |
| 2392 | - cacher ce cookie à l'application lors des requêtes ultérieures. |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2393 | |
| 2394 | Exemple : |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2395 | --------- |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2396 | listen application 0.0.0.0:80 |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2397 | mode http |
| 2398 | cookie SERVERID insert nocache indirect |
| 2399 | balance roundrobin |
| 2400 | server srv1 192.168.1.1:80 cookie server01 check |
| 2401 | server srv2 192.168.1.2:80 cookie server02 check |
willy tarreau | 5cbea6f | 2005-12-17 12:48:26 +0100 | [diff] [blame] | 2402 | |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 2403 | L'autre solution apportée par les versions 1.1.30 et 1.2.3 est de réutiliser un |
| 2404 | cookie en provenance du serveur et de lui préfixer l'identifiant du serveur. |
| 2405 | Dans ce cas, ne pas oublier de forcer le mode "httpclose" pour empêcher le |
| 2406 | client et le serveur de travailler en mode "keep-alive" afin que le proxy |
| 2407 | puisse corriger le nom du cookie dans toutes les futures requêtes. |
| 2408 | |
| 2409 | listen application 0.0.0.0:80 |
| 2410 | mode http |
| 2411 | cookie JSESSIONID prefix |
| 2412 | balance roundrobin |
willy tarreau | 598da41 | 2005-12-18 01:07:29 +0100 | [diff] [blame] | 2413 | server srv1 192.168.1.1:80 cookie srv1 check |
| 2414 | server srv2 192.168.1.2:80 cookie srv2 check |
willy tarreau | 0174f31 | 2005-12-18 01:02:42 +0100 | [diff] [blame] | 2415 | option httpclose |
| 2416 | |
| 2417 | |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2418 | 4.5) Protection contre les fuites d'informations du serveur |
| 2419 | ----------------------------------------------------------- |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 2420 | Dans les versions 1.1.28 et 1.2.1, une nouvelle option 'checkcache' a été |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2421 | créée. Elle sert à inspecter minutieusement les en-têtes 'Cache-control', |
willy tarreau | 64a3cc3 | 2005-12-18 01:13:11 +0100 | [diff] [blame] | 2422 | 'Pragma', et 'Set-cookie' dans les réponses serveur pour déterminer s'il y a |
| 2423 | un risque de cacher un cookie sur un proxy côté client. Quand cette option est |
| 2424 | activée, les seules réponses qui peuvent être retournées au client sont : |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2425 | - toutes celles qui n'ont pas d'en-tête 'Set-cookie' ; |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2426 | - toutes celles qui ont un code de retour autre que 200, 203, 206, 300, 301, |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2427 | 410, sauf si le serveur a positionné un en-tête 'Cache-control: public' ; |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2428 | - celles qui font suite à une requête POST, sauf si le serveur a positionné |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2429 | un en-tête 'Cache-control: public' ; |
| 2430 | - celles qui ont un en-tête 'Pragma: no-cache' ; |
| 2431 | - celles qui ont un en-tête 'Cache-control: private' ; |
| 2432 | - celles qui ont un en-tête 'Cache-control: no-store' ; |
| 2433 | - celles qui ont un en-tête 'Cache-control: max-age=0' ; |
| 2434 | - celles qui ont un en-tête 'Cache-control: s-maxage=0' ; |
| 2435 | - celles qui ont un en-tête 'Cache-control: no-cache' ; |
| 2436 | - celles qui ont un en-tête 'Cache-control: no-cache="set-cookie"' ; |
| 2437 | - celles qui ont un en-tête 'Cache-control: no-cache="set-cookie,' |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2438 | (autorisant d'autres champs après set-cookie). |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2439 | |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2440 | Si une réponse ne respecte pas ces pré-requis, alors elle sera bloquée de la |
| 2441 | même manière que s'il s'agissait d'un filtre 'rspdeny', avec en retour un |
| 2442 | message "HTTP 502 bad gateway". L'état de session montre "PH--" ce qui veut |
| 2443 | dire que c'est le proxy qui a bloqué la réponse durant le traitement des |
willy tarreau | c5f73ed | 2005-12-18 01:26:38 +0100 | [diff] [blame] | 2444 | en-têtes. De plus, un message d'alerte sera envoyé dans les logs de sorte que |
willy tarreau | 982249e | 2005-12-18 00:57:06 +0100 | [diff] [blame] | 2445 | l'administrateur sache qu'il y a une action correctrice à entreprendre. |
| 2446 | |
| 2447 | 4.6) Personalisation des erreurs |
| 2448 | -------------------------------- |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2449 | Certaines situations conduisent à retourner une erreur HTTP au client : |
| 2450 | - requête invalide ou trop longue => code HTTP 400 |
| 2451 | - requête mettant trop de temps à venir => code HTTP 408 |
| 2452 | - requête interdite (bloquée par un reqideny) => code HTTP 403 |
| 2453 | - erreur interne du proxy => code HTTP 500 |
| 2454 | - le serveur a retourné une réponse incomplète ou invalide => code HTTP 502 |
| 2455 | - aucun serveur disponible pour cette requête => code HTTP 503 |
| 2456 | - le serveur n'a pas répondu dans le temps imparti => code HTTP 504 |
| 2457 | |
| 2458 | Un message d'erreur succint tiré de la RFC accompagne ces codes de retour. |
| 2459 | Cependant, en fonction du type de clientèle, on peut préférer retourner des |
Willy Tarreau | 3f49b30 | 2007-06-11 00:29:26 +0200 | [diff] [blame] | 2460 | pages personnalisées. Ceci est possible de deux manières, l'une reposant sur |
| 2461 | une redirection vers un serveur connu, et l'autre consistant à retourner un |
| 2462 | fichier local. |
| 2463 | |
| 2464 | 4.6.1) Redirection |
| 2465 | ------------------ |
| 2466 | Une redirection d'erreur est assurée par le biais de la commande "errorloc" : |
willy tarreau | 8337c6b | 2005-12-17 13:41:01 +0100 | [diff] [blame] | 2467 | |
| 2468 | errorloc <code_HTTP> <location> |
| 2469 | |
| 2470 | Au lieu de générer une erreur HTTP <code_HTTP> parmi les codes cités ci-dessus, |
| 2471 | le proxy génèrera un code de redirection temporaire (HTTP 302) vers l'adresse |
| 2472 | d'une page précisée dans <location>. Cette adresse peut être relative au site, |
| 2473 | ou absolue. Comme cette réponse est traîtée par le navigateur du client |
| 2474 | lui-même, il est indispensable que l'adresse fournie lui soit accessible. |
| 2475 | |
| 2476 | Exemple : |
| 2477 | --------- |
| 2478 | listen application 0.0.0.0:80 |
| 2479 | errorloc 400 /badrequest.html |
|