haproxy/doc/haproxy-fr.txt

1554 lines
64 KiB
Plaintext
Raw Normal View History

2005-12-17 11:21:26 +00:00
H A - P r o x y
---------------
version 1.2.1
2005-12-17 11:21:26 +00:00
willy tarreau
2004/06/06
2005-12-17 11:21:26 +00:00
================
| Introduction |
================
2005-12-17 11:21:26 +00:00
HA-Proxy est un relais TCP/HTTP offrant des facilit<69>s d'int<6E>gration en
environnement hautement disponible. En effet, il est capable de :
- effectuer un aiguillage statique d<>fini par des cookies ;
- effectuer une r<>partition de charge avec cr<63>ation de cookies pour assurer la
persistence de session ;
2005-12-17 11:21:26 +00:00
- fournir une visibilit<69> externe de son <20>tat de sant<6E> ;
- s'arr<72>ter en douceur sans perte brutale de service ;
- modifier/ajouter/supprimer des ent<6E>tes dans la requ<71>te et la r<>ponse ;
- interdire des requ<71>tes qui v<>rifient certaines conditions ;
- utiliser des serveurs de secours lorsque les serveurs principaux sont hors
d'usage.
Il requiert peu de ressources, et son architecture <20>v<EFBFBD>nementielle mono-processus
lui permet facilement de g<>rer plusieurs milliers de connexions simultan<61>es sur
plusieurs relais sans effondrer le syst<73>me.
2005-12-17 11:21:26 +00:00
===========================
| Param<61>tres de lancement |
===========================
Les options de lancement sont peu nombreuses :
-f <fichier de configuration>
-n <nombre maximal total de connexions simultan<61>es>
-N <nombre maximal de connexions simultan<61>es par proxy>
-d active le mode debug
-D passe en daemon
-q d<>sactive l'affichage de messages sur la sortie standard.
-V affiche les messages sur la sortie standard, m<>me si -q ou 'quiet' sont
sp<73>cifi<66>s.
-c v<>rifie le fichier de configuration puis quitte avec un code de retour 0
si aucune erreur n'a <20>t<EFBFBD> trouv<75>e, ou 1 si une erreur de syntaxe a <20>t<EFBFBD>
d<>tect<63>e.
-p <fichier> indique au processus p<>re qu'il doit <20>crire les PIDs de ses
fils dans ce fichier en mode d<>mon.
2005-12-17 11:21:26 +00:00
-s affiche les statistiques (si option compil<69>e)
-l ajoute des informations aux statistiques
Le nombre maximal de connexion simultan<61>es par proxy est le param<61>tre par d<>faut
pour les proxies pour lesquels ce param<61>tre n'est pas pr<70>cis<69> dans le fichier de
configuration. Il s'agit du param<61>tre 'maxconn' dans les sections 'listen'.
Le nombre maximal total de connexions simultan<61>es limite le nombre de connexions
TCP utilisables <20> un instant donn<6E> par le processus, tous proxies confondus. Ce
param<EFBFBD>tre remplace le param<61>tre 'maxconn' de la section 'global'.
2005-12-17 11:21:26 +00:00
Le mode debug correspond <20> l'option 'debug' de la section 'global'. Dans ce
mode, toutes les connexions, d<>connexions, et tous les <20>changes d'ent<6E>tes HTTP
sont affich<63>s.
Les statistiques ne sont disponibles que si le programme a <20>t<EFBFBD> compil<69> avec
l'option "STATTIME". Il s'agit principalement de donn<6E>es brutes n'ayant
d'utilit<69> que lors de benchmarks par exemple.
2005-12-17 11:21:26 +00:00
============================
| Fichier de configuration |
============================
Structure
=========
2005-12-17 11:21:26 +00:00
L'analyseur du fichier de configuration ignore des lignes vides, les espaces,
les tabulations, et tout ce qui est compris entre le symbole '#' (s'il n'est pas
pr<EFBFBD>c<EFBFBD>d<EFBFBD> d'un '\'), et la fin de la ligne, ce qui constitue un commentaire.
Le fichier de configuration est d<>coup<75> en sections r<>p<EFBFBD>r<EFBFBD>es par des mots cl<63>s
tels que :
- 'global'
- 'listen'
- 'defaults'
Tous les param<61>tres font r<>f<EFBFBD>rence <20> la section d<>finie par le dernier mot cl<63>
reconnu.
1) Param<61>tres globaux
=====================
Il s'agit des param<61>tres agissant sur le processus, ou bien sur l'ensemble des
proxies. Ils sont tous sp<73>cifi<66>s dans la section 'global'. Les param<61>tres
support<EFBFBD>s sont :
- log <adresse> <cat<61>gorie> [niveau_max]
- maxconn <nombre>
- uid <identifiant>
- gid <identifiant>
- chroot <r<>pertoire>
- nbproc <nombre>
- daemon
- debug
- quiet
- pidfile <fichier>
1.1) Journalisation des <20>v<EFBFBD>nements
----------------------------------
La plupart des <20>v<EFBFBD>nements sont journalis<69>s : d<>marrages, arr<72>ts, disparition et
apparition de serveurs, connexions, erreurs. Tous les messages sont envoy<6F>s en
syslog vers un ou deux serveurs. La syntaxe est la suivante :
log <adresse_ip> <cat<61>gorie> [niveau_max]
Les connexions sont envoy<6F>es en niveau "info". Les d<>marrages de service et de
serveurs seront envoy<6F>s en "notice", les signaux d'arr<72>ts en "warning" et les
arr<EFBFBD>ts d<>finitifs de services et de serveurs en "alert". Ceci est valable aussi
bien pour les proxies que pour les serveurs test<73>s par les proxies. Le param<61>tre
optionnel <niveau_max> d<>finit le niveau maximal de traces <20>mises parmi les 8
valeurs suivantes :
emerg, alert, crit, err, warning, notice, info, debug
Par compatibilit<69> avec les versions 1.1.16 et ant<6E>rieures, la valeur par d<>faut
est "debug" si l'option n'est pas pr<70>cis<69>e.
Les cat<61>gories possibles sont :
kern, user, mail, daemon, auth, syslog, lpr, news,
uucp, cron, auth2, ftp, ntp, audit, alert, cron2,
local0, local1, local2, local3, local4, local5, local6, local7
Conform<EFBFBD>ment <20> la RFC3164, les messages <20>mis sont limit<69>s <20> 1024 caract<63>res.
Exemple :
---------
global
log 192.168.2.200 local3
log 127.0.0.1 local4 notice
1.2) limitation du nombre de connexions
---------------------------------------
Il est possible et conseill<6C> de limiter le nombre global de connexions par
processus. Les connexions sont comprises au sens 'acceptation de connexion',
donc il faut s'attendre en r<>gle g<>n<EFBFBD>ral <20> avoir un peu plus du double de
sessions TCP que le maximum de connexions fix<69>. C'est important pour fixer le
param<EFBFBD>tre 'ulimit -n' avant de lancer le proxy. Pour comptabiliser le nombre
de sockets n<>cessaires, il faut prendre en compte ces param<61>tres :
- 1 socket par connexion entrante
- 1 socket par connexion sortante
- 1 socket par couple adresse/port d'<27>coute par proxy
- 1 socket pour chaque serveur en cours de health-check
- 1 socket pour les logs (tous serveurs confondus)
Dans le cas o<> chaque proxy n'<27>coute que sur un couple adresse/port, positionner
la limite du nombre de descripteurs de fichiers (ulimit -n) <20>
(2 * maxconn + nbproxy + nbserveurs + 1). Dans une future version, haproxy sera
capable de positionner lui-m<>me cette limite.
1.3) Diminution des privil<69>ges
------------------------------
Afin de r<>duire les risques d'attaques dans le cas o<> une faille non identifi<66>e
serait exploit<69>e, il est possible de diminuer les privil<69>ges du processus, et
de l'isoler dans un r<>pertoire sans risque.
Dans la section 'global', le param<61>tre 'uid' permet de sp<73>cifier un identifiant
num<EFBFBD>rique d'utilisateur. La valeur 0, correspondant normalement au super-
utilisateur, poss<73>de ici une signification particuli<6C>re car elle indique que
l'on ne souhaite pas changer cet identifiant et conserver la valeur courante.
C'est la valeur par d<>faut. De la m<>me mani<6E>re, le param<61>tre 'gid' correspond <20>
un identifiant de groupe, et utilise par d<>faut la valeur 0 pour ne rien
changer. Il est particuli<6C>rement d<>conseill<6C> d'utiliser des comptes g<>n<EFBFBD>riques
tels que 'nobody' car cette pratique revient <20> utiliser 'root' si d'autres
processus utilisent les m<>mes identifiants.
Le param<61>tre 'chroot' autorise <20> changer la racine du processus une fois le
programme lanc<6E>, de sorte que ni le processus, ni l'un de ses descendants ne
puissent remonter de nouveau <20> la racine. Ce type de cloisonnement (chroot) est
g<EFBFBD>n<EFBFBD>ralement contournable sur certains OS (Linux, Solaris) pour peu que
l'attaquant poss<73>de des droits 'root' et soit en mesure d'utiliser ou de cr<63>er
un r<>pertoire. Aussi, il est important d'utiliser un r<>pertoire sp<73>cifique au
service pour cet usage, et de ne pas mutualiser un m<>me r<>pertoire pour
plusieurs services de nature diff<66>rente. Pour rendre l'isolement plus robuste,
il est conseill<6C> d'utiliser un r<>pertoire vide, sans aucun droit, et de changer
l'uid du processus de sorte qu'il ne puisse rien faire dans ledit r<>pertoire.
Remarque: dans le cas o<> une telle faille serait mise en <20>vidence, il est fort
probable que les premi<6D>res tentatives de son exploitation provoquent un arr<72>t du
programme, <20> cause d'un signal de type 'Segmentation Fault', 'Bus Error' ou
encore 'Illegal Instruction'. M<>me s'il est vrai que faire tourner le serveur en
environnement limit<69> r<>duit les risques d'intrusion, il est parfois bien utile
dans ces circonstances de conna<6E>tre les conditions d'apparition du probl<62>me, via
l'obtention d'un fichier 'core'. La plupart des syst<73>mes, pour des raisons de
s<EFBFBD>curit<EFBFBD>, d<>sactivent la g<>n<EFBFBD>ration du fichier 'core' apr<70>s un changement
d'identifiant pour le processus. Il faudra donc soit lancer le processus <20>
partir d'un compte utilisateur aux droits r<>duits (mais ne pouvant pas effectuer
le chroot), ou bien le faire en root sans r<>duction des droits (uid 0). Dans ce
cas, le fichier se trouvera soit dans le r<>pertoire de lancement, soit dans le
r<EFBFBD>pertoire sp<73>cifi<66> apr<70>s l'option 'chroot'. Ne pas oublier la commande suivante
pour autoriser la g<>n<EFBFBD>ration du fichier avant de lancer le programme :
# ulimit -c unlimited
Exemple :
---------
global
uid 30000
gid 30000
chroot /var/chroot/haproxy
1.4) Modes de fonctionnement
----------------------------
Le service peut fonctionner dans plusieurs modes :
- avant- / arri<72>re-plan
- silencieux / normal / debug
Le mode par d<>faut est normal, avant-plan, c'est <20> dire que le programme ne rend
pas la main une fois lanc<6E>. Il ne faut surtout pas le lancer comme ceci dans un
script de d<>marrage du syst<73>me, sinon le syst<73>me ne finirait pas son
initialisation. Il faut le mettre en arri<72>re-plan, de sorte qu'il rende la main
au processus appelant. C'est ce que fait l'option 'daemon' de la section
'global', et qui est l'<27>quivalent du param<61>tre '-D' de la ligne de commande.
Par ailleurs, certains messages d'alerte sont toujours envoy<6F>s sur la sortie
standard, m<>me en mode 'daemon'. Pour ne plus les voir ailleurs que dans les
logs, il suffit de passer en mode silencieux par l'ajout de l'option 'quiet'.
Cette option n'a pas d'<27>quivalent en ligne de commande.
Enfin, le mode 'debug' permet de diagnostiquer les origines de certains
probl<EFBFBD>mes en affichant les connexions, d<>connexions et <20>changes d'en-t<>tes HTTP
entre les clients et les serveurs. Ce mode est incompatible avec les options
'daemon' et 'quiet' pour des raisons de bon sens.
1.5) Accroissement de la capacit<69> de traitement
-----------------------------------------------
Sur des machines multi-processeurs, il peut sembler g<>ch<63> de n'utiliser qu'un
processeur pour effectuer les t<>ches de relayage, m<>me si les charges
n<EFBFBD>cessaires <20> saturer un processeur actuel sont bien au-del<65> des ordres de
grandeur couramment rencontr<74>s. Cependant, pour des besoins particuliers, le
programme sait d<>marrer plusieurs processus se r<>partissant la charge de
travail. Ce nombre de processus est sp<73>cifi<66> par le param<61>tre 'nbproc' de la
section 'global'. Sa valeur par d<>faut est naturellement 1. Ceci ne fonctionne
qu'en mode 'daemon'.
Exemple :
---------
global
daemon
quiet
nbproc 2
2005-12-17 11:21:26 +00:00
1.6) Simplification de la gestion des processus
-----------------------------------------------
Haproxy supporte dor<6F>navant la notion de fichiers de pid (-> pidfiles). Si le
param<EFBFBD>tre '-p' de ligne de commande, ou l'option globale 'pidfile' sont suivis
d'un nom de fichier, alors ce fichier sera supprim<69> puis recr<63><72> et contiendra
le num<75>ro de PID des processus fils, <20> raison d'un par ligne (valable
uniquement en mode d<>mon). Ce fichier n'est PAS relatif au cloisonnement chroot
afin de rester compatible avec un r<>pertoire prot<6F>g<EFBFBD> en lecture seule. Il
appartiendra <20> l'utilisateur ayant lanc<6E> le processus, et disposera des droits
0644.
Exemple :
---------
global
daemon
quiet
nbproc 2
pidfile /var/run/haproxy-private.pid
# pour stopper seulement ces processus parmi d'autres :
# kill $(</var/run/haproxy-private.pid)
2005-12-17 11:21:26 +00:00
2) D<>finition d'un service en <20>coute
====================================
2005-12-17 11:21:26 +00:00
Les sections de service d<>butent par le mot cl<63> "listen" :
2005-12-17 11:21:26 +00:00
listen <nom_instance> [ <adresse_IP>:<plage_ports>[,...] ]
2005-12-17 11:21:26 +00:00
- <nom_instance> est le nom de l'instance d<>crite. Ce nom sera envoy<6F> dans les
logs, donc il est souhaitable d'utiliser un nom relatif au service relay<61>. Aucun
test n'est effectu<74> concernant l'unicit<69> de ce nom, qui n'est pas obligatoire,
mais fortement recommand<6E>e.
- <adresse_IP> est l'adresse IP sur laquelle le relais attend ses connexions.
L'absence d'adresse ainsi que l'adresse 0.0.0.0 signifient que les connexions
pourront s'effectuer sur toutes les adresses de la machine.
- <plage_ports> correspond soit <20> un port, soit <20> une plage de ports sur
lesquels le relais acceptera des connexions pour l'adresse IP sp<73>cifi<66>e.
Cette plage peut <20>tre :
- soit un port num<75>rique (ex: '80')
- soit une plage constitu<74>e de deux valeurs s<>par<61>es par un tiret
(ex: '2000-2100') repr<70>sentant les extr<74>mit<69>s incluses dans la
plage.
Il faut faire attention <20> l'usage des plages, car chaque combinaison
<adresse_IP>:<port> consomme une socket, donc un descripteur de fichier.
Le couple <adresse_IP>:<port> doit <20>tre unique pour toutes les instances
d'une m<>me machine. L'attachement <20> un port inf<6E>rieur <20> 1024 n<>cessite un
niveau de privil<69>ge particulier lors du lancement du programme (ind<6E>pendamment
du param<61>tre 'uid' de la section 'global').
- le couple <adresse_IP>:<plage_ports> peut <20>tre r<>p<EFBFBD>t<EFBFBD> ind<6E>finiment pour
demander au relais d'<27>couter <20>galement sur d'autres adresses et/ou d'autres
plages de ports. Pour cela, il suffit de s<>parer les couples par une virgule.
2005-12-17 11:21:26 +00:00
Exemples :
---------
listen http_proxy :80
listen x11_proxy 127.0.0.1:6000-6009
listen smtp_proxy 127.0.0.1:25,127.0.0.1:587
listen ldap_proxy :389,:663
2005-12-17 11:21:26 +00:00
Si toutes les adresses ne tiennent pas sur une ligne, il est possible d'en
rajouter <20> l'aide du mot cl<63> 'bind'. Dans ce cas, il n'est m<>me pas n<>cessaire
de sp<73>cifier la premi<6D>re adresse sur la ligne listen, ce qui facilite parfois
l'<27>criture de configurations :
2005-12-17 11:21:26 +00:00
bind [ <adresse_IP>:<plage_ports>[,...] ]
2005-12-17 11:21:26 +00:00
Exemples :
----------
listen http_proxy
bind :80,:443
bind 10.0.0.1:10080,10.0.0.1:10443
2005-12-17 11:21:26 +00:00
2.1) Inhibition d'un service
----------------------------
Un service peut <20>tre d<>sactiv<69> pour des besoins de maintenance, sans avoir <20>
commenter toute une partie du fichier. Il suffit de positionner le mot cl<63>
"disabled" dans sa section :
2005-12-17 11:21:26 +00:00
listen smtp_proxy 0.0.0.0:25
disabled
Remarque: le mot cl<63> 'enabled' permet de r<>activer un service pr<70>alablement
d<>sactiv<69> par le mot cl<63> 'disabled', par exemple <20> cause d'une
configuration par d<>faut.
2.2) Mode de fonctionnement
---------------------------
Un service peut fonctionner dans trois modes diff<66>rents :
2005-12-17 11:21:26 +00:00
- TCP
- HTTP
- supervision
Mode TCP
--------
Dans ce mode, le service relaye, d<>s leur <20>tablissement, les connexions TCP vers
un ou plusieurs serveurs. Aucun traitement n'est effectu<74> sur le flux. Il s'agit
simplement d'une association source<adresse:port> -> destination<adresse:port>.
Pour l'utiliser, pr<70>ciser le mode TCP sous la d<>claration du relais.
2005-12-17 11:21:26 +00:00
Exemple :
---------
2005-12-17 11:21:26 +00:00
listen smtp_proxy 0.0.0.0:25
mode tcp
Mode HTTP
---------
Dans ce mode, le service relaye les connexions TCP vers un ou plusieurs
serveurs, une fois qu'il dispose d'assez d'informations pour en prendre la
d<EFBFBD>cision. Les ent<6E>tes HTTP sont analys<79>s pour y trouver un <20>ventuel cookie, et
certains d'entre-eux peuvent <20>tre modifi<66>s par le biais d'expressions
r<EFBFBD>guli<EFBFBD>res. Pour activer ce mode, pr<70>ciser le mode HTTP sous la d<>claration du
relais.
2005-12-17 11:21:26 +00:00
Exemple :
---------
2005-12-17 11:21:26 +00:00
listen http_proxy 0.0.0.0:80
mode http
Mode supervision
----------------
Il s'agit d'un mode offrant <20> un composant externe une visibilit<69> de l'<27>tat de
sant<EFBFBD> du service. Il se contente de retourner "OK" <20> tout client se connectant
sur son port. Il peut <20>tre utilis<69> avec des r<>partiteurs de charge <20>volu<6C>s pour
d<EFBFBD>terminer quels sont les services utilisables. Si l'option 'httpchk' est
activ<EFBFBD>e, alors la r<>ponse changera en 'HTTP/1.0 200 OK' pour satisfaire les
attentes de composants sachant tester en HTTP. Pour activer ce mode, pr<70>ciser
le mode HEALTH sous la d<>claration du relais.
2005-12-17 11:21:26 +00:00
Exemple :
---------
# r<>ponse simple : 'OK'
2005-12-17 11:21:26 +00:00
listen health_check 0.0.0.0:60000
mode health
# r<>ponse HTTP : 'HTTP/1.0 200 OK'
listen http_health_check 0.0.0.0:60001
mode health
option httpchk
2005-12-17 11:21:26 +00:00
2.3) Limitation du nombre de connexions simultan<61>es
---------------------------------------------------
Le param<61>tre "maxconn" permet de fixer la limite acceptable en nombre de
connexions simultan<61>es par proxy. Chaque proxy qui atteint cette valeur cesse
d'<27>couter jusqu'<27> lib<69>ration d'une connexion. Voir plus loin concernant les
limitations li<6C>es au syst<73>me.
2005-12-17 11:21:26 +00:00
Exemple :
---------
listen tiny_server 0.0.0.0:80
maxconn 10
2.4) Arr<72>t en douceur
---------------------
Il est possible d'arr<72>ter les services en douceur en envoyant un signal SIG_USR1
au processus relais. Tous les services seront alors mis en phase d'arr<72>t, mais
pourront continuer d'accepter des connexions pendant un temps d<>fini par le
param<EFBFBD>tre 'grace' (en millisecondes). Cela permet par exemple, de faire savoir
rapidement <20> un r<>partiteur de charge qu'il ne doit plus utiliser un relais,
tout en continuant d'assurer le service le temps qu'il s'en rende compte.
Remarque : les connexions actives ne sont jamais cass<73>es. Dans le pire des cas,
il faudra attendre en plus leur expiration avant l'arr<72>t total du processus. La
valeur par d<>faut est 0 (pas de gr<67>ce, arr<72>t imm<6D>diat de l'<27>coute).
2005-12-17 11:21:26 +00:00
Exemple :
---------
# arr<72>ter en douceur par 'killall -USR1 haproxy'
2005-12-17 11:21:26 +00:00
# le service tournera encore 10 secondes apr<70>s la demande d'arr<72>t
listen http_proxy 0.0.0.0:80
mode http
grace 10000
# ce port n'est test<73> que par un r<>partiteur de charge.
2005-12-17 11:21:26 +00:00
listen health_check 0.0.0.0:60000
mode health
grace 0
2.5) Temps d'expiration des connexions
--------------------------------------
Il est possible de param<61>trer certaines dur<75>es d'expiration au niveau des
connexions TCP. Trois temps ind<6E>pendants sont configurables et acceptent des
valeurs en millisecondes. Si l'une de ces trois temporisations est d<>pass<73>e, la
session est termin<69>e <20> chaque extr<74>mit<69>.
2005-12-17 11:21:26 +00:00
- temps d'attente d'une donn<6E>e de la part du client, ou de la
possibilit<69> de lui envoyer des donn<6E>es : "clitimeout" :
# time-out client <20> 2mn30.
clitimeout 150000
- temps d'attente d'une donn<6E>e de la part du serveur, ou de la
possibilit<69> de lui envoyer des donn<6E>es : "srvtimeout" :
# time-out serveur <20> 30s.
2005-12-17 11:21:26 +00:00
srvtimeout 30000
- temps d'attente de l'<27>tablissement d'une connexion vers un serveur
"contimeout" :
# on abandonne si la connexion n'est pas <20>tablie apr<70>s 4 secondes
contimeout 4000
2005-12-17 11:21:26 +00:00
Remarques :
-----------
- "contimeout" et "srvtimeout" n'ont pas d'utilit<69> dans le cas du serveur de
type "health".
- sous de fortes charges, ou sur un r<>seau satur<75> ou d<>fectueux, il est
possible de perdre des paquets. Du fait que la premi<6D>re retransmission TCP
n'ait lieu qu'au bout de 3 secoudes, fixer un timeout de connexion inf<6E>rieur
<20> 3 secondes ne permet pas de se rattraper sur la perte de paquets car la
session aura <20>t<EFBFBD> abandonn<6E>e avant la premi<6D>re retransmission. Une valeur de
4 secondes r<>duira consid<69>rablement le nombre d'<27>checs de connexion.
2.6) Tentatives de reconnexion
------------------------------
2005-12-17 11:21:26 +00:00
Lors d'un <20>chec de connexion vers un serveur, il est possible de
retenter (potentiellement vers un autre serveur, en cas de r<>partition
de charge). Le nombre de nouvelles tentatives infructueuses avant
abandon est fourni par le param<61>tre "retries".
2005-12-17 11:21:26 +00:00
Exemple :
---------
2005-12-17 11:21:26 +00:00
# on essaie encore trois fois maxi
retries 3
2.7) Adresse du serveur
-----------------------
Le serveur vers lequel sont redirig<69>es les nouvelles connexions est d<>fini par
le param<61>tre "dispatch" sous la forme <adresse_ip>:<port>. Il correspond <20> un
serveur d'assignation de cookie dans le cas o<> le service consiste <20> assurer
uniquement une persistence HTTP, ou bien simplement au serveur destination dans
le cas de relayage TCP simple. Cet ancien mode ne permet pas de tester l'<27>tat
du serveur distant, et il est maintenant recommand<6E> d'utiliser de pr<70>f<EFBFBD>rence
le mode 'balance'.
2005-12-17 11:21:26 +00:00
Exemple :
---------
2005-12-17 11:21:26 +00:00
# on envoie toutes les nouvelles connexions ici
dispatch 192.168.1.2:80
Remarque :
----------
Ce param<61>tre n'a pas d'utilit<69> pour un serveur en mode 'health', ni en mode
'balance'.
2005-12-17 11:21:26 +00:00
2.8) Adresse de sortie
----------------------
Il est possible de forcer l'adresse utilis<69>e pour <20>tablir les connexions vers
les serveurs <20> l'aide du param<61>tre "source". Il est m<>me possible de forcer le
port, bien que cette fonctionnalit<69> se limite <20> des usages tr<74>s sp<73>cifiques.
C'est particuli<6C>rement utile en cas d'adressage multiple, et plus g<>n<EFBFBD>ralement
pour permettre aux serveurs de trouver le chemin de retour dans des contextes de
routage difficiles. Si l'adresse est '0.0.0.0' ou '*' ou vide, elle sera choisie
librement par le systeme. Si le port est '0' ou vide, il sera choisi librement
par le syst<73>me. Il est <20> noter que depuis la version 1.1.18, les tests de bon
fonctionnement des serveurs seront aussi effectu<74>s <20> partir de la source
sp<EFBFBD>cifi<EFBFBD>e par ce param<61>tre.
Exemples :
----------
listen http_proxy *:80
# toutes les connexions prennent l'adresse 192.168.1.200
source 192.168.1.200:0
listen rlogin_proxy *:513
# utiliser l'adresse 192.168.1.200 et le port r<>serv<72> 900
source 192.168.1.200:900
2.9) D<>finition du nom du cookie
--------------------------------
En mode HTTP, il est possible de rechercher la valeur d'un cookie pour savoir
vers quel serveur aiguiller la requ<71>te utilisateur. Le nom du cookie est donn<6E>
par le param<61>tre "cookie".
2005-12-17 11:21:26 +00:00
Exemple :
---------
listen http_proxy :80
2005-12-17 11:21:26 +00:00
mode http
cookie SERVERID
On peut modifier l'utilisation du cookie pour la rendre plus intelligente
vis-<2D>-vis des applications relay<61>es. Il est possible, notamment de supprimer ou
r<EFBFBD><EFBFBD>crire un cookie retourn<72> par un serveur acc<63>d<EFBFBD> en direct, et d'ins<6E>rer un
cookie dans une r<>ponse HTTP adress<73>e <20> un serveur s<>lectionn<6E> en r<>partition
de charge, et m<>me de signaler aux proxies amont de ne pas cacher le cookie
ins<EFBFBD>r<EFBFBD>.
Exemples :
----------
Pour ne conserver le cookie qu'en acc<63>s indirect, donc <20> travers le
dispatcheur, et supprimer toutes ses <20>ventuelles occurences lors des acc<63>s
directs :
cookie SERVERID indirect
Pour remplacer la valeur d'un cookie existant par celle attribu<62>e <20> un serveur,
lors d'un acc<63>s direct :
cookie SERVERID rewrite
Pour cr<63>er un cookie comportant la valeur attribu<62>e <20> un serveur lors d'un acc<63>s
en r<>partition de charge interne. Dans ce cas, il est souhaitable que tous les
serveurs aient un cookie renseign<67>. Un serveur non assign<67> d'un cookie
retournera un cookie vide (cookie de suppression) :
cookie SERVERID insert
Pour ins<6E>rer un cookie, en s'assurant qu'un cache en amont ne le stockera pas,
ajouter le mot cl<63> 'nocache' apr<70>s 'insert' :
cookie SERVERID insert nocache
Pour ins<6E>rer un cookie seulement suite aux requ<71>tes de type POST, ajouter le mot
cl<EFBFBD> 'postonly' apr<70>s 'insert' :
cookie SERVERID insert postonly
Remarques :
-----------
- Il est possible de combiner 'insert' avec 'indirect' ou 'rewrite' pour s'adapter
<20> des applications g<>n<EFBFBD>rant d<>j<EFBFBD> le cookie, avec un contenu invalide. Il suffit
pour cela de les sp<73>cifier sur la m<>me ligne.
- dans le cas o<> 'insert' et 'indirect' sont sp<73>cifi<66>s, le cookie n'est jamais
transmis au serveur vu qu'il n'en a pas connaissance et ne pourrait pas le
comprendre.
- il est particuli<6C>rement recommand<6E> d'utiliser 'nocache' en mode insertion si
des caches peuvent se trouver entre les clients et l'instance du proxy. Dans
le cas contraire, un cache HTTP 1.0 pourrait cacher la r<>ponse, incluant le
cookie de persistence ins<6E>r<EFBFBD>, donc provoquer des changements de serveurs pour
des clients partageant le m<>me cache.
- lorsque l'application est bien connue, et que les parties n<>cessitant de la
persistence sont syst<73>matiquement acc<63>d<EFBFBD>es par un formulaire en mode POST,
il est plus efficace encore de combiner le mot cl<63> "postonly" avec "insert"
et "indirect", car la page d'accueil reste cachable, et c'est l'application
qui g<>re le 'cache-control'.
2005-12-17 11:21:26 +00:00
2.10) Assignation d'un serveur <20> une valeur de cookie
----------------------------------------------------
En mode HTTP, il est possible d'associer des valeurs de cookie <20> des serveurs
par le param<61>tre 'server'. La syntaxe est :
2005-12-17 11:21:26 +00:00
server <identifiant> <adresse_ip>:<port> cookie <valeur>
2005-12-17 11:21:26 +00:00
- <identifiant> est un nom quelconque de serveur utilis<69> pour l'identifier dans la
configuration et les logs.
- <adresse_ip>:<port> est le couple adresse-port sur lequel le serveur <20>coute.
- <valeur> est la valeur <20> reconna<6E>tre ou positionner dans le cookie.
2005-12-17 11:21:26 +00:00
Exemple : le cookie SERVERID peut contenir server01 ou server02
---------
listen http_proxy :80
2005-12-17 11:21:26 +00:00
mode http
cookie SERVERID
dispatch 192.168.1.100:80
server web1 192.168.1.1:80 cookie server01
server web2 192.168.1.2:80 cookie server02
Attention : la syntaxe a chang<6E> depuis la version 1.0.
-----------
3) R<>partiteur de charge autonome
=================================
Le relais peut effectuer lui-m<>me la r<>partition de charge entre les diff<66>rents
serveurs d<>finis pour un service donn<6E>, en mode TCP comme en mode HTTP. Pour
cela, on pr<70>cise le mot cl<63> 'balance' dans la d<>finition du service,
<EFBFBD>ventuellement suivi du nom d'un algorithme de r<>partition. En version 1.1.9,
seul 'roundrobin' est g<>r<EFBFBD>, et c'est aussi la valeur implicite par d<>faut. Il
est <20>vident qu'en cas d'utilisation du r<>partiteur interne, il ne faudra pas
sp<EFBFBD>cifier d'adresse de dispatch, et qu'il faudra au moins un serveur.
Exemple : m<>me que pr<70>c<EFBFBD>demment en r<>partition interne
---------
listen http_proxy :80
mode http
cookie SERVERID
balance roundrobin
server web1 192.168.1.1:80 cookie server01
server web2 192.168.1.2:80 cookie server02
Depuis la version 1.1.22, il est possible de d<>terminer automatiquement le port
du serveur vers lequel sera envoy<6F>e la connexion, en fonction du port d'<27>coute
sur lequel le client s'est connect<63>. En effet, il y a 4 possibilit<69>s pour le
champ <port> de l'adresse serveur :
- non sp<73>cifi<66> ou nul :
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
lequel le relais a re<72>u la connexion.
- valeur num<75>rique (seul cas support<72> pour les versions ant<6E>rieures) :
le serveur recevra la connexion sur le port d<>sign<67>.
- valeur num<75>rique pr<70>c<EFBFBD>d<EFBFBD>e d'un signe '+' :
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
lequel le relais a re<72>u la connexion, auquel on ajoute la valeur d<>sign<67>e.
- valeur num<75>rique pr<70>c<EFBFBD>d<EFBFBD>e d'un signe '-' :
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
lequel le relais a re<72>u la connexion, duquel on soustrait la valeur
d<>sign<67>e.
Exemples :
----------
# m<>me que pr<70>c<EFBFBD>demment
listen http_proxy :80
mode http
cookie SERVERID
balance roundrobin
server web1 192.168.1.1 cookie server01
server web2 192.168.1.2 cookie server02
# relayage simultan<61> des ports 80 et 81 et 8080-8089
listen http_proxy :80,:81,:8080-8089
mode http
cookie SERVERID
balance roundrobin
server web1 192.168.1.1 cookie server01
server web2 192.168.1.2 cookie server02
# relayage TCP des ports 25, 389 et 663 vers les ports 1025, 1389 et 1663
listen http_proxy :25,:389,:663
mode tcp
balance roundrobin
server srv1 192.168.1.1:+1000
server srv2 192.168.1.2:+1000
3.1) Surveillance des serveurs
------------------------------
Il est possible de tester l'<27>tat des serveurs par <20>tablissement de connexion TCP
ou par envoi d'une requ<71>te HTTP. Un serveur hors d'usage ne sera pas utilis<69>
dans le processus de r<>partition de charge interne. Pour activer la surveillance,
ajouter le mot cl<63> 'check' <20> la fin de la d<>claration du serveur. Il est
possible de sp<73>cifier l'intervalle (en millisecondes) s<>parant deux tests du
serveur par le param<61>tre "inter", le nombre d'<27>checs accept<70>s par le param<61>tre
"fall", et le nombre de succ<63>s avant reprise par le param<61>tre "rise". Les
param<EFBFBD>tres non pr<70>cis<69>s prennent les valeurs suivantes par d<>faut :
- inter : 2000
- rise : 2
- fall : 3
- port : port de connexion du serveur
2005-12-17 11:21:26 +00:00
Le mode par d<>faut consiste <20> <20>tablir des connexions TCP uniquement. Dans
certains cas de pannes, des serveurs peuvent continuer <20> accepter les connexions
sans les traiter. Depuis la version 1.1.16, haproxy est en mesure d'envoyer des
requ<EFBFBD>tes HTTP courtes et tr<74>s peu co<63>teuses. Les versions 1.1.16 et 1.1.17
utilisent "OPTIONS / HTTP/1.0". Dans les versions 1.1.18 <20> 1.1.20, les requ<71>tes
ont <20>t<EFBFBD> chang<6E>es en "OPTIONS * HTTP/1.0" pour des raisons de contr<74>le d'acc<63>s aux
ressources. Cependant, cette requ<71>te document<6E>e dans la RFC2068 n'est pas
comprise par tous les serveurs. Donc <20> partir de la version 1.1.21, la requ<71>te
par d<>faut est revenue <20> "OPTIONS / HTTP/1.0", mais il est possible de
param<EFBFBD>trer la partie URI. Les requ<71>tes OPTIONS pr<70>sentent l'avantage d'<27>tre
facilement extractibles des logs, et de ne pas induire d'acc<63>s aux fichiers c<>t<EFBFBD>
serveur. Seules les r<>ponses 2xx et 3xx sont consid<69>r<EFBFBD>es valides, les autres (y
compris non-r<>ponses) aboutissent <20> un <20>chec. Le temps maximal imparti pour une
r<EFBFBD>ponse est <20>gal <20> l'intervalle entre deux tests (param<61>tre "inter"). Pour
activer ce mode, sp<73>cifier l'option "httpchk", <20>ventuellement suivie d'une
m<EFBFBD>thode et d'une URI. L'option "httpchk" accepte donc 4 formes :
- option httpchk -> OPTIONS / HTTP/1.0
- option httpchk URI -> OPTIONS <URI> HTTP/1.0
- option httpchk METH URI -> <METH> <URI> HTTP/1.0
- option httpchk METH URI VER -> <METH> <URI> <VER>
Voir les exemples ci-apr<70>s.
Depuis la version 1.1.17, il est possible de d<>finir des serveurs de secours,
utilis<EFBFBD>s uniquement lorsqu'aucun des autres serveurs ne fonctionne. Pour cela,
ajouter le mot cl<63> "backup" sur la ligne de d<>finition du serveur. Un serveur
de secours n'est appel<65> que lorsque tous les serveurs normaux, ainsi que tous
les serveurs de secours qui le pr<70>c<EFBFBD>dent sont hors d'usage. Il n'y a donc pas
de r<>partition de charge entre des serveurs de secours. Ce type de serveurs
peut servir <20> retourner des pages d'indisponibilit<69> de service. Dans ce cas,
il est pr<70>f<EFBFBD>rable de ne pas affecter de cookie, afin que les clients qui le
rencontrent n'y soient pas affect<63>s d<>finitivement. Le fait de ne pas mettre
de cookie envoie un cookie vide, ce qui a pour effet de supprimer un <20>ventuel
cookie affect<63> pr<70>c<EFBFBD>demment.
Depuis la version 1.1.22, il est possible d'envoyer les tests de fonctionnement
vers un port diff<66>rent de celui de service. C'est n<>cessaire principalement
pour les configurations o<> le serveur n'a pas de port pr<70>d<EFBFBD>fini, par exemple
lorsqu'il est d<>duit du port d'acceptation de la connexion. Pour cela, utiliser
le param<61>tre 'port' suivi du num<75>ro de port devant r<>pondre aux requ<71>tes.
Enfin, depuis la version 1.1.17, il est possible de visualiser rapidement l'<27>tat
courant de tous les serveurs. Pour cela, il suffit d'envoyer un signal SIGHUP au
processus proxy. L'<27>tat de tous les serveurs de tous les proxies est envoy<6F> dans
les logs en niveau "notice", ainsi que sur la sortie d'erreurs si elle est
active. C'est une bonne raison pour avoir au moins un serveur de logs local en
niveau notice.
Depuis la version 1.1.18 (et 1.2.1), un message d'urgence est envoy<6F> dans les
logs en niveau 'emerg' si tous les serveurs d'une m<>me instance sont tomb<6D>s,
afin de notifier l'administrateur qu'il faut prendre une action imm<6D>diate.
Exemples :
----------
# conf du paragraphe 3) avec surveillance TCP
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
# m<>me que pr<70>c<EFBFBD>demment avec surveillance HTTP par 'OPTIONS / HTTP/1.0'
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
# m<>me que pr<70>c<EFBFBD>demment avec surveillance HTTP par 'OPTIONS /index.html HTTP/1.0'
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk /index.html
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
# idem avec surveillance HTTP par 'HEAD /index.jsp? HTTP/1.1\r\nHost: www'
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
# Insertion automatique de cookie dans la r<>ponse du serveur, et suppression
# automatique dans la requ<71>te, tout en indiquant aux caches de ne pas garder
# ce cookie.
listen web_appl 0.0.0.0:80
mode http
cookie SERVERID insert nocache indirect
balance roundrobin
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check
# idem avec serveur applicatif de secours sur autre site, et serveur de pages d'erreurs
listen web_appl 0.0.0.0:80
mode http
cookie SERVERID insert nocache indirect
balance roundrobin
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie server02 check
server web-backup 192.168.2.1:80 cookie server03 check backup
server web-excuse 192.168.3.1:80 check backup
# relayage SMTP+TLS avec test du serveur et serveur de backup
listen http_proxy :25,:587
mode tcp
balance roundrobin
server srv1 192.168.1.1 check port 25 inter 30000 rise 1 fall 2
server srv2 192.168.1.2 backup
2005-12-17 11:21:26 +00:00
3.2) Reconnexion vers un r<>partiteur en cas d'<27>chec direct
----------------------------------------------------------
En mode HTTP, si un serveur d<>fini par un cookie ne r<>pond plus, les clients
seront d<>finitivement aiguill<6C>s dessus <20> cause de leur cookie, et de ce fait,
d<EFBFBD>finitivement priv<69>s de service. La sp<73>cification du param<61>tre 'redispatch'
autorise dans ce cas <20> renvoyer les connexions <20>chou<6F>es vers le r<>partiteur
(externe ou interne) afin d'assigner un nouveau serveur <20> ces clients.
2005-12-17 11:21:26 +00:00
Exemple :
---------
2005-12-17 11:21:26 +00:00
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
dispatch 192.168.1.100:80
server web1 192.168.1.1:80 cookie server01
server web2 192.168.1.2:80 cookie server02
redispatch # renvoyer vers dispatch si refus de connexion.
Par d<>faut (et dans les versions 1.1.16 et ant<6E>rieures), le param<61>tre redispatch
ne s'applique qu'aux <20>checs de connexion au serveur. Depuis la version 1.1.17,
il s'applique aussi aux connexions destin<69>es <20> des serveurs identifi<66>s comme
hors d'usage par la surveillance. Si l'on souhaite malgr<67> tout qu'un client
disposant d'un cookie correspondant <20> un serveur d<>fectueux tente de s'y
connecter, il faut pr<70>ciser l'option "persist" :
listen http_proxy 0.0.0.0:80
mode http
option persist
cookie SERVERID
dispatch 192.168.1.100:80
server web1 192.168.1.1:80 cookie server01
server web2 192.168.1.2:80 cookie server02
redispatch # renvoyer vers dispatch si serveur HS.
4) Fonctionnalit<69>s additionnelles
=================================
D'autres fonctionnalit<69>s d'usage moins courant sont disponibles. Il s'agit
principalement du mode transparent, de la journalisation des connexions, et de
la r<><72>criture des ent<6E>tes.
4.1) Fonctionnement en mode transparent
---------------------------------------
En mode HTTP, le mot cl<63> 'transparent' permet d'intercepter des sessions rout<75>es
<EFBFBD> travers la machine h<>bergeant le proxy. Dans ce mode, on ne pr<70>cise pas
l'adresse de r<>partition 'dispatch', car celle-ci est tir<69>e de l'adresse
destination de la session d<>tourn<72>e. Le syst<73>me doit permettre de rediriger les
paquets vers un processus local.
Exemple :
---------
listen http_proxy 0.0.0.0:65000
mode http
transparent
cookie SERVERID
2005-12-17 11:21:26 +00:00
server server01 192.168.1.1:80
server server02 192.168.1.2:80
# iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \
--dport 80 -j REDIRECT --to-ports 65000
2005-12-17 11:21:26 +00:00
Remarque :
----------
Si le port n'est pas sp<73>cifi<66> sur le serveur, c'est le port auquel s'est adress<73>
le client qui sera utilis<69>. Cela permet de relayer tous les ports TCP d'une m<>me
adresse avec une m<>me instance et sans utiliser directement le mode transparent.
Exemple :
---------
listen http_proxy 0.0.0.0:65000
mode tcp
server server01 192.168.1.1 check port 60000
server server02 192.168.1.2 check port 60000
# iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \
-j REDIRECT --to-ports 65000
2005-12-17 11:21:26 +00:00
4.2) Journalisation des connexions
----------------------------------
4.2.1) Niveaux de log
---------------------
Les connexions TCP et HTTP peuvent donner lieu <20> une journalisation sommaire ou
d<EFBFBD>taill<EFBFBD>e indiquant, pour chaque connexion, la date, l'heure, l'adresse IP
source, le serveur destination, la dur<75>e de la connexion, les temps de r<>ponse,
la requ<71>te HTTP, le code de retour, la quantit<69> de donn<6E>es transmises, et m<>me
dans certains cas, la valeur d'un cookie permettant de suivre les sessions.
Tous les messages sont envoy<6F>s en syslog vers un ou deux serveurs. Se r<>f<EFBFBD>rer <20>
la section 1.1 pour plus d'information sur les cat<61>gories de logs. La syntaxe
est la suivante :
2005-12-17 11:21:26 +00:00
log <adresse_ip_1> <cat<61>gorie_1> [niveau_max_1]
log <adresse_ip_2> <cat<61>gorie_2> [niveau_max_2]
ou
log global
Remarque :
----------
La syntaxe sp<73>cifique 'log global' indique que l'on souhaite utiliser les
param<EFBFBD>tres de journalisation d<>finis dans la section 'global'.
2005-12-17 11:21:26 +00:00
Exemple :
---------
listen http_proxy 0.0.0.0:80
mode http
log 192.168.2.200 local3
log 192.168.2.201 local4
4.2.2) Format des logs
----------------------
Par d<>faut, les connexions sont journalis<69>es au niveau TCP d<>s l'<27>tablissement
de la session entre le client et le relais. En pr<70>cisant l'option 'tcplog',
la connexion ne sera journalis<69>e qu'en fin de session, ajoutant des pr<70>cisions
sur son <20>tat lors de la d<>connexion, ainsi que le temps de connexion et la
dur<EFBFBD>e totale de la session.
Exemple :
---------
listen relais-tcp 0.0.0.0:8000
mode tcp
option tcplog
log 192.168.2.200 local3
>>> haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 --
Une autre option, 'httplog', fournit plus de d<>tails sur le protocole HTTP,
notamment la requ<71>te et l'<27>tat des cookies. Dans les cas o<> un m<>canisme de
surveillance effectuant des connexions et d<>connexions fr<66>quentes, polluerait
les logs, il suffit d'ajouter l'option 'dontlognull', pour ne plus obtenir une
ligne de log pour les sessions n'ayant pas donn<6E> lieu <20> un <20>change de donn<6E>es
(requ<71>te ou r<>ponse).
2005-12-17 11:21:26 +00:00
Exemple :
---------
listen http_proxy 0.0.0.0:80
mode http
option httplog
option dontlognull
log 192.168.2.200 local3
>>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/7/147/723 200 243 - - ---- "HEAD / HTTP/1.0"
Le probl<62>me de loguer uniquement en fin de session, c'est qu'il est impossible
de savoir ce qui se passe durant de gros transferts ou des sessions longues.
Pour pallier <20> ce probl<62>me, une nouvelle option 'logasap' a <20>t<EFBFBD> introduite dans
la version 1.1.28 (1.2.1). Lorsqu'elle est activ<69>e, le proxy loguera le plus t<>t
possible, c'est <20> dire juste avant que ne d<>butent les transferts de donn<6E>es.
Cela signifie, dans le cas du TCP, qu'il loguera toujours le r<>sultat de la
connexion vers le serveur, et dans le cas HTTP, qu'il loguera en fin de
traitement des ent<6E>tes de la r<>ponse du serveur, auquel cas le nombre d'octets
repr<EFBFBD>sentera la taille des ent<6E>tes retourn<72>s au client.
Afin d'<27>viter toute confusion avec les logs normaux, le temps total de transfert
et le nombre d'octets transf<73>r<EFBFBD>s sont pr<70>fix<69>s d'un signe '+' rappeleant que les
valeurs r<>elles sont certainement plus <20>lev<65>es.
Exemple :
---------
listen http_proxy 0.0.0.0:80
mode http
option httplog
option dontlognull
option logasap
log 192.168.2.200 local3
>>> haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- "GET /image.iso HTTP/1.0"
4.2.3) Chronom<6F>trage des <20>v<EFBFBD>nements
-----------------------------------
Pour d<>celer des probl<62>mes r<>seau, les mesures du temps <20>coul<75> entre certains
<EFBFBD>v<EFBFBD>nements sont d'une tr<74>s grande utilit<69>. Tous les temps sont mesur<75>s en
millisecondes (ms). En mode HTTP, quatre points de mesure sont rapport<72>s sous
la forme Tq/Tc/Tr/Tt :
- Tq: temps total de r<>ception de la requ<71>te HTTP de la part du client.
C'est le temps qui s'est <20>coul<75> entre le moment o<> le client a <20>tabli
sa connexion vers le relais, et le moment o<> ce dernier a re<72>u le dernier
en-t<>te HTTP validant la fin de la requ<71>te. Une valeur '-1' ici indique
que la requ<71>te compl<70>te n'a jamais <20>t<EFBFBD> re<72>ue.
- Tc: temps d'<27>tablissement de la connexion TCP du relais vers le serveur.
C'est le temps <20>coul<75> entre le moment ou le relais a initi<74> la demande de
connexion vers le serveur, et le moment o<> ce dernier l'a acquitt<74>e, c'est
<20> dire le temps entre l'envoi du paquet TCP SYN la r<>ception du SYN/ACK.
Une valeur '-1' ici indique que la connexion n'a jamais pu <20>tre <20>tablie
vers le serveur.
- Tr: temps de r<>ponse du serveur. C'est le temps que le serveur a mis pour
renvoyer la totalit<69> des ent<6E>tes HTTP <20> partir du moment o<> il a acquitt<74>
la connexion. Ca repr<70>sente exactement le temps de traitement de la
transaction sans le transfert des donn<6E>es associ<63>es. Une valeur '-1'
indique que le serveur n'a pas envoy<6F> la totalit<69> de l'ent<6E>te HTTP.
- Tt: dur<75>e de vie totale de la session, entre le moment o<> la demande de
connexion du client a <20>t<EFBFBD> acquitt<74>e et le moment o<> la connexion a <20>t<EFBFBD>
referm<72>e aux deux extr<74>mit<69>s (client et serveur). La signification change
un peu si l'option 'logasap' est pr<70>sente. Dans ce cas, le temps correspond
uniquement <20> (Tq + Tc + Tr), et se trouve pr<70>fix<69> d'un signe '+'. On peut
donc d<>duire Td, le temps de transfert des donn<6E>es, en excluant les autres
temps :
Td = Tt - (Tq + Tc + Tr)
Les temps rapport<72>s <20> '-1' sont simplement <20> <20>liminer de cette <20>quation.
En mode TCP ('option tcplog'), seuls les deux indicateurs Tc et Tt sont
rapport<EFBFBD>s.
Ces temps fournissent de pr<70>cieux renseignement sur des causes probables de
probl<EFBFBD>mes. Du fait que le protocole TCP d<>finisse des temps de retransmission
de 3 secondes, puis 6, 12, etc..., l'observation de temps proches de multiples
de 3 secondes indique pratiquement toujours des pertes de paquets li<6C>s <20> un
probl<EFBFBD>me r<>seau (c<>ble ou n<>gociation). De plus, si <Tt> est proche d'une
valeur de time-out dans la configuration, c'est souvent qu'une session a <20>t<EFBFBD>
abandonn<EFBFBD>e sur expiration d'un time-out.
Cas les plus fr<66>quents :
- Si Tq est proche de 3000, un paquet a tr<74>s certainement <20>t<EFBFBD> perdu entre
le client et le relais.
- Si Tc est proche de 3000, un paquet a tr<74>s certainement <20>t<EFBFBD> perdu entre
le relais et le serveur durant la phase de connexion. Cet indicateur
devrait normalement toujours <20>tre tr<74>s bas (moins de quelques dizaines).
- Si Tr est presque toujours inf<6E>rieur <20> 3000, et que certaines valeurs
semblent proches de la valeur moyenne major<6F>e de 3000, il y a peut-<2D>tre
de pertes entre le relais et le serveur.
- Si Tt est l<>g<EFBFBD>rement sup<75>rieur au time-out, c'est souvent parce que le
client et le serveur utilisent du keep-alive HTTP entre eux et que la
session est maintenue apr<70>s la fin des <20>changes. Voir plus loin pour
savoir comment d<>sactiver le keep-alive HTTP.
Autres cas ('xx' repr<70>sentant une valeur quelconque <20> ignorer) :
-1/xx/xx/Tt : le client n'a pas envoy<6F> sa requ<71>te dans le temps imparti ou
a referm<72> sa connexion sans compl<70>ter la requ<71>te.
Tq/-1/xx/Tt : la connexion n'a pas pu s'<27>tablir vers le serveur (refus ou
time-out au bout de Tt-Tq ms).
Tq/Tc/-1/Tt : le serveur a accept<70> la connexion mais n'a pas r<>pondu dans
les temps ou bien a referm<72> sa connexion trop t<>t, au bout
de Tt-(Tq+Tc) ms.
4.2.4) Conditions de d<>connexion
--------------------------------
Les logs TCP et HTTP fournissent un indicateur de compl<70>tude de la session.
C'est un champ de 4 caract<63>res (2 en TCP) pr<70>c<EFBFBD>dant la requ<71>te HTTP, indiquant :
- sur le premier caract<63>re, un code pr<70>cisant le premier <20>v<EFBFBD>nement qui a caus<75>
la terminaison de la session :
C : fermeture de la session TCP de la part du client
S : fermeture de la session TCP de la part du serveur, ou refus de connexion
P : terminaison pr<70>matur<75>e des sessions par le proxy, pour cas d'erreur
interne, de configuration (ex: filtre d'URL), ou parce qu'un
contr<74>le de s<>curit<69> a d<>tect<63> une anomalie dans la r<>ponse du
serveur.
c : expiration du d<>lai d'attente c<>t<EFBFBD> client : clitimeout
s : expiration du d<>lai d'attente c<>t<EFBFBD> serveur: srvtimeout et contimeout
- : terminaison normale.
- sur le second caract<63>re, l'<27>tat d'avancement de la session HTTP lors de la
fermeture :
R : terminaison en attendant la r<>ception totale de la requ<71>te du client
C : terminaison en attendant la connexion vers le serveur
H : terminaison en traitant les ent<6E>tes du serveur
D : terminaison durant le transfert des donn<6E>es du serveur vers le client
L : terminaison durant le transfert des derni<6E>res donn<6E>es du proxy vers
le client, alors que le serveur a d<>j<EFBFBD> fini.
- : terminaison normale, apr<70>s fin de transfert des donn<6E>es
- le troisi<73>me caract<63>re indique l'<27>ventuelle identification d'un cookie de
persistence (uniquement en mode HTTP) :
N : aucun cookie de persistence n'a <20>t<EFBFBD> pr<70>sent<6E>.
I : le client a pr<70>sent<6E> un cookie ne correspondant <20> aucun serveur
connu.
D : le client a pr<70>sent<6E> un cookie correspondant <20> un serveur hors
d'usage. Suivant l'option 'persist', il a <20>t<EFBFBD> renvoy<6F> vers un
autre serveur ou a tout de m<>me tent<6E> de se connecter sur celui
correspondant au cookie.
V : le client a pr<70>sent<6E> un cookie valide et a pu se connecter au
serveur correspondant.
- : non appliquable
- le dernier caract<63>re indique l'<27>ventuel traitement effectu<74> sur un cookie de
persistence retrourn<72> par le serveur (uniquement en mode HTTP) :
N : aucun cookie de persistence n'a <20>t<EFBFBD> fourni par le serveur.
P : un cookie de persistence a <20>t<EFBFBD> fourni par le serveur et transmis
tel quel.
I : aucun cookie n'a <20>t<EFBFBD> fourni par le serveur, il a <20>t<EFBFBD> ins<6E>r<EFBFBD> par le
proxy.
D : le cookie pr<70>sent<6E> par le serveur a <20>t<EFBFBD> supprim<69> par le proxy pour
ne pas <20>tre retourn<72> au client.
R : le cookie retourn<72> par le serveur a <20>t<EFBFBD> modifi<66> par le proxy.
- : non appliquable
Le mot cl<63> "capture" permet d'ajouter dans des logs HTTP des informations
captur<EFBFBD>es dans les <20>changes. La version 1.1.17 supporte uniquement une capture
de cookies client et serveur, ce qui permet dans bien des cas, de reconstituer
la session d'un utilisateur. La syntaxe est la suivante :
capture cookie <pr<70>fixe_cookie> len <longueur_capture>
Le premier cookie dont le nom commencera par <pr<70>fixe_cookie> sera captur<75>, et
transmis sous la forme "NOM=valeur", sans toutefois, exc<78>der <longueur_capture>
caract<EFBFBD>res (64 au maximum). Lorsque le nom du cookie est fixe et connu, on peut
le suffixer du signe "=" pour s'assurer qu'aucun autre cookie ne prendra sa
place dans les logs.
Exemples :
----------
# capture du premier cookie dont le nom commence par "ASPSESSION"
capture cookie ASPSESSION len 32
# capture du premier cookie dont le nom est exactement "vgnvisitor"
capture cookie vgnvisitor= len 32
Dans les logs, le champ pr<70>c<EFBFBD>dant l'indicateur de compl<70>tude contient le cookie
positionn<EFBFBD> par le serveur, pr<70>c<EFBFBD>d<EFBFBD> du cookie positionn<6E> par le client. Chacun de
ces champs est remplac<61> par le signe "-" lorsqu'aucun cookie n'est fourni par le
client ou le serveur.
4.2.5) Exemples de logs
-----------------------
- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/7/147/6723 200 243 - - ---- "HEAD / HTTP/1.0"
=> requ<71>te longue (6.5s) saisie <20> la main avec un client telnet. Le serveur a
r<>pondu en 147 ms et la session s'est termin<69>e normalement ('----')
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- "GET /image.iso HTTP/1.0"
=> requ<71>te pour un long transfert. L'option 'logasap' <20>tait sp<73>cifi<66>e donc le
log a <20>t<EFBFBD> g<>n<EFBFBD>r<EFBFBD> juste avant le transfert de donn<6E>es. Le serveur a r<>pondu
en 14 ms, 243 octets d'ent<6E>tes ont <20>t<EFBFBD> transf<73>r<EFBFBD>s au client, et le temps
total entre l'accept() et le premier octet de donn<6E>e est de 30 ms.
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/30 502 243 - - PH-- "GET /cgi-bin/bug.cgi? HTTP/1.0"
=> le proxy a bloqu<71> une r<>ponse du serveur soit <20> cause d'un filtre 'rspdeny'
ou 'rspideny', soit parce qu'il a d<>tect<63> un risque de fuite sensible
d'informations risquant d'<27>tre cach<63>es. Dans ce cas, la r<>ponse est
remplac<61>e par '502 bad gateway'.
- haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/8490 -1 0 - - CR-- ""
=> Le client n'a pas envoy<6F> sa requ<71>te et a referm<72> la connexion lui-m<>me
('C---') au bout de 8.5s, alors que le relais attendait l'ent<6E>te ('-R--').
Aucune connexion n'a <20>t<EFBFBD> envoy<6F>e vers le serveur.
- haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/50001 408 0 - - cR-- ""
=> Le client n'a pas envoy<6F> sa requ<71>te et son time-out a expir<69> ('c---') au
bout de 50s, alors que le relais attendait l'ent<6E>te ('-R--'). Aucune
connexion n'a <20>t<EFBFBD> envoy<6F>e vers le serveur, mais le relais a tout de m<>me
pu renvoyer un message 408 au client.
- haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 cD
=> log en mode 'tcplog'. Expiration du time-out c<>t<EFBFBD> client ('c----') au bout
de 5s.
- haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/11215 503 0 - - SC-- "HEAD / HTTP/1.0"
=> La requ<71>te client met 3s <20> entrer (peut-<2D>tre un probl<62>me r<>seau), et la
connexion ('SC--') vers le serveur <20>choue au bout de 4 tentatives de 2
secondes (retries 3 dans la conf), puis un code 503 est retourn<72> au client.
4.3) Modification des ent<6E>tes HTTP
----------------------------------
En mode HTTP uniquement, il est possible de remplacer certains en-t<>tes dans la
requ<EFBFBD>te et/ou la r<>ponse <20> partir d'expressions r<>guli<6C>res. Il est <20>galement
possible de bloquer certaines requ<71>tes en fonction du contenu des en-t<>tes ou de
la requ<71>te. Une limitation cependant : les en-t<>tes fournis au milieu de
connexions persistentes (keep-alive) ne sont pas vus car ils sont consid<69>r<EFBFBD>s
comme faisant partie des <20>changes de donn<6E>es cons<6E>cutifs <20> la premi<6D>re requ<71>te.
Les donn<6E>es ne sont pas affect<63>es, ceci ne s'applique qu'aux en-t<>tes.
La syntaxe est :
reqadd <string> pour ajouter un en-t<>te dans la requ<71>te
reqrep <search> <replace> pour modifier la requ<71>te
reqirep <search> <replace> idem sans distinction majuscules/minuscules
reqdel <search> pour supprimer un en-t<>te dans la requ<71>te
reqidel <search> idem sans distinction majuscules/minuscules
reqallow <search> autoriser la requ<71>te si un ent<6E>te valide <search>
reqiallow <search> idem sans distinction majuscules/minuscules
reqdeny <search> interdire la requ<71>te si un ent<6E>te valide <search>
reqideny <search> idem sans distinction majuscules/minuscules
reqpass <search> inhibe ces actions sur les ent<6E>tes validant <search>
reqipass <search> idem sans distinction majuscules/minuscules
rspadd <string> pour ajouter un en-t<>te dans la r<>ponse
rsprep <search> <replace> pour modifier la r<>ponse
rspirep <search> <replace> idem sans distinction majuscules/minuscules
rspdel <search> pour supprimer un en-t<>te dans la r<>ponse
rspidel <search> idem sans distinction majuscules/minuscules
rspdeny <search> remplace la r<>ponse par un HTTP 502 si un
ent<6E>te valide <search>
rspideny <search> idem sans distinction majuscules/minuscules
2005-12-17 11:21:26 +00:00
<search> est une expression r<>guli<6C>re compatible POSIX regexp supportant le
groupage par parenth<74>ses (sans les '\'). Les espaces et autres s<>parateurs
doivent <20>tres pr<70>c<EFBFBD>d<EFBFBD>s d'un '\' pour ne pas <20>tre confondus avec la fin de la
cha<EFBFBD>ne. De plus, certains caract<63>res sp<73>ciaux peuvent <20>tre pr<70>c<EFBFBD>d<EFBFBD>s d'un
backslach ('\') :
\t pour une tabulation
\r pour un retour charriot
\n pour un saut de ligne
\ pour diff<66>rencier un espace d'un s<>parateur
\# pour diff<66>rencier un di<64>se d'un commentaire
\\ pour utiliser un backslash dans la regex
\\\\ pour utiliser un backslash dans le texte
\xXX pour un caract<63>re sp<73>cifique XX (comme en C)
<replace> contient la cha<68>ne rempla<6C>ant la portion v<>rifi<66>e par l'expression.
Elle peut inclure les caract<63>res sp<73>ciaux ci-dessus, faire r<>f<EFBFBD>rence <20> un
groupe d<>limit<69> par des parenth<74>ses dans l'expression r<>guli<6C>re, par sa
position num<75>rale. Les positions vont de 1 <20> 9, et sont cod<6F>es par un '\'
suivi du chiffre d<>sir<69>. Il est <20>galement possible d'ins<6E>rer un caract<63>re non
imprimable (utile pour le saut de ligne) inscrivant '\x' suivi du code
hexad<EFBFBD>cimal de ce caract<63>re (comme en C).
<string> repr<70>sente une cha<68>ne qui sera ajout<75>e syst<73>matiquement apr<70>s la
derni<EFBFBD>re ligne d'en-t<>te.
Remarques :
-----------
- la premi<6D>re ligne de la requ<71>te et celle de la r<>ponse sont trait<69>es comme
des en-t<>tes, ce qui permet de r<><72>crire des URL et des codes d'erreur.
- 'reqrep' est l'<27>quivalent de 'cliexp' en version 1.0, et 'rsprep' celui de
'srvexp'. Ces noms sont toujours support<72>s mais d<>conseill<6C>s.
- pour des raisons de performances, le nombre total de caract<63>res ajout<75>s sur
une requ<71>te ou une r<>ponse est limit<69> <20> 4096 depuis la version 1.1.5 (cette
limite <20>tait <20> 256 auparavant). Cette valeur est modifiable dans le code.
Pour un usage temporaire, on peut gagner de la place en supprimant quelques
ent<6E>tes inutiles avant les ajouts.
- une requ<71>te bloqu<71>e produira une r<>ponse "HTTP 403 forbidden" tandis qu'une
r<>ponse bloqu<71>e produira une r<>ponse "HTTP 502 Bad gateway".
2005-12-17 11:21:26 +00:00
Exemples :
----------
###### a few examples ######
# rewrite 'online.fr' instead of 'free.fr' for GET and POST requests
reqrep ^(GET\ .*)(.free.fr)(.*) \1.online.fr\3
reqrep ^(POST\ .*)(.free.fr)(.*) \1.online.fr\3
# force proxy connections to close
reqirep ^Proxy-Connection:.* Proxy-Connection:\ close
# rewrite locations
rspirep ^(Location:\ )([^:]*://[^/]*)(.*) \1\3
###### A full configuration being used on production ######
# Every header should end with a colon followed by one space.
reqideny ^[^:\ ]*[\ ]*$
# block Apache chunk exploit
reqideny ^Transfer-Encoding:[\ ]*chunked
reqideny ^Host:\ apache-
# block annoying worms that fill the logs...
reqideny ^[^:\ ]*\ .*(\.|%2e)(\.|%2e)(%2f|%5c|/|\\\\)
reqideny ^[^:\ ]*\ ([^\ ]*\ [^\ ]*\ |.*%00)
reqideny ^[^:\ ]*\ .*<script
reqideny ^[^:\ ]*\ .*/(root\.exe\?|cmd\.exe\?|default\.ida\?)
# allow other syntactically valid requests, and block any other method
reqipass ^(GET|POST|HEAD|OPTIONS)\ /.*\ HTTP/1\.[01]$
reqipass ^OPTIONS\ \\*\ HTTP/1\.[01]$
reqideny ^[^:\ ]*\
# force connection:close, thus disabling HTTP keep-alive
option httpclos
# change the server name
rspidel ^Server:\
rspadd Server:\ Formilux/0.1.8
2005-12-17 11:21:26 +00:00
De plus, l'option 'forwardfor' ajoute l'adresse IP du client dans un champ
'X-Forwarded-For' de la requ<71>te, ce qui permet <20> un serveur web final de
conna<EFBFBD>tre l'adresse IP du client initial.
Enfin, l'option 'httpclose' apparue dans la version 1.1.28/1.2.1 supprime tout
ent<EFBFBD>te de type 'Connection:' et ajoute 'Connection: close' dans les deux sens.
Ceci simplifie la d<>sactivation du keep-alive HTTP par rapport <20> l'ancienne
m<EFBFBD>thode impliquant 4 r<>gles.
Exemple :
---------
listen http_proxy 0.0.0.0:80
mode http
log global
option httplog
option dontlognull
option forwardfor
option httpclose
4.4) R<>partition avec persistence
---------------------------------
La combinaison de l'insertion de cookie avec la r<>partition de charge interne
permet d'assurer une persistence dans les sessions HTTP d'une mani<6E>re
pratiquement transparente pour les applications. Le principe est simple :
- attribuer une valeur d'un cookie <20> chaque serveur
- effectuer une r<>partition interne
- ins<6E>rer un cookie dans les r<>ponses issues d'une r<>partition uniquement,
et faire en sorte que des caches ne m<>morisent pas ce cookie.
- cacher ce cookie <20> l'application lors des requ<71>tes ult<6C>rieures.
2005-12-17 11:21:26 +00:00
Exemple :
---------
listen application 0.0.0.0:80
mode http
cookie SERVERID insert nocache indirect
balance roundrobin
server 192.168.1.1:80 cookie server01 check
server 192.168.1.2:80 cookie server02 check
2005-12-17 11:21:26 +00:00
4.5) Protection contre les fuites d'informations du serveur
-----------------------------------------------------------
Dans les versions 1.1.28 et 1.2.1, une nouvelle option 'checkcache' a <20>t<EFBFBD> cr<63><72>e.
Elle sert <20> inspecter minutieusement les ent<6E>tes 'Cache-control', 'Pragma', et
'Set-cookie' dans les r<>ponses serveur pour d<>terminer s'il y a un risque de
cacher un cookie sur un proxy c<>t<EFBFBD> client. Quand cette option est activ<69>e, les
seules r<>ponses qui peuvent <20>tre retourn<72>es au client sont :
- toutes celles qui n'ont pas d'ent<6E>te 'Set-cookie' ;
- toutes celles qui ont un code de retour autre que 200, 203, 206, 300, 301,
410, sauf si le server a positionn<6E> un ent<6E>te 'Cache-control: public' ;
- celles qui font suite <20> une requ<71>te POST, sauf si le serveur a positionn<6E>
un ent<6E>te 'Cache-control: public' ;
- celles qui ont un ent<6E>te 'Pragma: no-cache' ;
- celles qui ont un ent<6E>te 'Cache-control: private' ;
- celles qui ont un ent<6E>te 'Cache-control: no-store' ;
- celles qui ont un ent<6E>te 'Cache-control: max-age=0' ;
- celles qui ont un ent<6E>te 'Cache-control: s-maxage=0' ;
- celles qui ont un ent<6E>te 'Cache-control: no-cache' ;
- celles qui ont un ent<6E>te 'Cache-control: no-cache="set-cookie"' ;
- celles qui ont un ent<6E>te 'Cache-control: no-cache="set-cookie,'
(autorisant d'autres champs apr<70>s set-cookie).
Si une r<>ponse ne respecte pas ces pr<70>-requis, alors elle sera bloqu<71>e de la
m<EFBFBD>me mani<6E>re que s'il s'agissait d'un filtre 'rspdeny', avec en retour un
message "HTTP 502 bad gateway". L'<27>tat de session montre "PH--" ce qui veut
dire que c'est le proxy qui a bloqu<71> la r<>ponse durant le traitement des
ent<EFBFBD>tes. De plus, un message d'alerte sera envoy<6F> dans les logs de sorte que
l'administrateur sache qu'il y a une action correctrice <20> entreprendre.
4.6) Personalisation des erreurs
--------------------------------
Certaines situations conduisent <20> retourner une erreur HTTP au client :
- requ<71>te invalide ou trop longue => code HTTP 400
- requ<71>te mettant trop de temps <20> venir => code HTTP 408
- requ<71>te interdite (bloqu<71>e par un reqideny) => code HTTP 403
- erreur interne du proxy => code HTTP 500
- le serveur a retourn<72> une r<>ponse incompl<70>te ou invalide => code HTTP 502
- aucun serveur disponible pour cette requ<71>te => code HTTP 503
- le serveur n'a pas r<>pondu dans le temps imparti => code HTTP 504
Un message d'erreur succint tir<69> de la RFC accompagne ces codes de retour.
Cependant, en fonction du type de client<6E>le, on peut pr<70>f<EFBFBD>rer retourner des
pages personnalis<69>es. Ceci est possible par le biais de la commande "errorloc" :
errorloc <code_HTTP> <location>
Au lieu de g<>n<EFBFBD>rer une erreur HTTP <code_HTTP> parmi les codes cit<69>s ci-dessus,
le proxy g<>n<EFBFBD>rera un code de redirection temporaire (HTTP 302) vers l'adresse
d'une page pr<70>cis<69>e dans <location>. Cette adresse peut <20>tre relative au site,
ou absolue. Comme cette r<>ponse est tra<72>t<EFBFBD>e par le navigateur du client
lui-m<>me, il est indispensable que l'adresse fournie lui soit accessible.
Exemple :
---------
listen application 0.0.0.0:80
errorloc 400 /badrequest.html
errorloc 403 /forbidden.html
errorloc 408 /toolong.html
errorloc 500 http://haproxy.domain.net/bugreport.html
errorloc 502 http://192.168.114.58/error50x.html
errorloc 503 http://192.168.114.58/error50x.html
errorloc 504 http://192.168.114.58/error50x.html
4.7) Changement des valeurs par d<>faut
--------------------------------------
Dans la version 1.1.22 est apparue la notion de valeurs par d<>faut, ce qui <20>vite
de r<>p<EFBFBD>ter des param<61>tres communs <20> toutes les instances, tels que les timeouts,
adresses de log, modes de fonctionnement, etc.
Les valeurs par d<>faut sont positionn<6E>es dans la derni<6E>re section 'defaults'
pr<EFBFBD>c<EFBFBD>dent l'instance qui les utilisera. On peut donc mettre autant de sections
'defaults' que l'on veut. Il faut juste se rappeler que la pr<70>sence d'une telle
section implique une annulation de tous les param<61>tres par d<>faut positionn<6E>s
pr<EFBFBD>c<EFBFBD>demment, dans le but de les remplacer.
La section 'defaults' utilise la m<>me syntaxe que la section 'listen', aux
param<EFBFBD>tres pr<70>s qui ne sont pas support<72>s. Le mot cl<63> 'defaults' peut accepter
un commentaire en guise param<61>tre.
Dans la version 1.1.28/1.2.1, seuls les param<61>tres suivants peuvent <20>tre
positionn<EFBFBD>s dans une section 'defaults' :
- log (le premier et le second)
- mode { tcp, http, health }
- balance { roundrobin }
- disabled (pour d<>sactiver toutes les instances qui suivent)
- enabled (pour faire l'op<6F>ration inverse, mais c'est le cas par d<>faut)
- contimeout, clitimeout, srvtimeout, grace, retries, maxconn
- option { redispatch, transparent, keepalive, forwardfor, logasap, httpclose,
checkcache, httplog, tcplog, dontlognull, persist, httpchk }
- redispatch, redisp, transparent, source { addr:port }
- cookie, capture
- errorloc
Ne sont pas support<72>s dans cette version, les adresses de dispatch et les
configurations de serveurs, ainsi que tous les filtres bas<61>s sur les
expressions r<>guli<6C>res :
- dispatch, server,
- req*, rsp*
Enfin, il n'y a pas le moyen, pour le moment, d'invalider un param<61>tre bool<6F>en
positionn<EFBFBD> par d<>faut. Donc si une option est sp<73>cifi<66>e dans les param<61>tres par
d<EFBFBD>faut, le seul moyen de la d<>sactiver pour une instance, c'est de changer les
param<EFBFBD>tres par d<>faut avant la d<>claration de l'instance.
Exemples :
----------
defaults applications TCP
log global
mode tcp
balance roundrobin
clitimeout 180000
srvtimeout 180000
contimeout 4000
retries 3
redispatch
listen app_tcp1 10.0.0.1:6000-6063
server srv1 192.168.1.1 check port 6000 inter 10000
server srv2 192.168.1.2 backup
listen app_tcp2 10.0.0.2:6000-6063
server srv1 192.168.2.1 check port 6000 inter 10000
server srv2 192.168.2.2 backup
defaults applications HTTP
log global
mode http
option httplog
option forwardfor
option dontlognull
balance roundrobin
clitimeout 20000
srvtimeout 20000
contimeout 4000
retries 3
listen app_http1 10.0.0.1:80-81
cookie SERVERID postonly insert indirect
capture cookie userid= len 10
server srv1 192.168.1.1:+8000 cookie srv1 check port 8080 inter 1000
server srv1 192.168.1.2:+8000 cookie srv2 check port 8080 inter 1000
defaults
# section vide qui annule tous les param<61>tes par d<>faut.
=======================
| Param<61>trage syst<73>me |
=======================
2005-12-17 11:21:26 +00:00
Sous Linux 2.4
==============
-- cut here --
#!/bin/sh
# set this to about 256/4M (16384 for 256M machine)
MAXFILES=16384
echo $MAXFILES > /proc/sys/fs/file-max
ulimit -n $MAXFILES
if [ -e /proc/sys/net/ipv4/ip_conntrack_max ]; then
echo 65536 > /proc/sys/net/ipv4/ip_conntrack_max
fi
if [ -e /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_fin_wait ]; then
# 30 seconds for fin, 15 for time wait
echo 3000 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_fin_wait
echo 1500 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_time_wait
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_invalid_scale
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
fi
2005-12-17 11:21:26 +00:00
echo 1024 60999 > /proc/sys/net/ipv4/ip_local_port_range
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
2005-12-17 11:21:26 +00:00
echo 262144 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 262144 > /proc/sys/net/ipv4/tcp_max_orphans
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
2005-12-17 11:21:26 +00:00
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 0 > /proc/sys/net/ipv4/tcp_ecn
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 0 > /proc/sys/net/ipv4/tcp_dsack
# auto-tuned on 2.4
#echo 262143 > /proc/sys/net/core/rmem_max
#echo 262143 > /proc/sys/net/core/rmem_default
echo 16384 65536 524288 > /proc/sys/net/ipv4/tcp_rmem
echo 16384 349520 699040 > /proc/sys/net/ipv4/tcp_wmem
-- cut here --
2005-12-17 11:21:26 +00:00
Sous FreeBSD
============
Un port de HA-Proxy sous FreeBSD est d<>sormais disponible, gr<67>ce <20>
Clement Laforet <sheepkiller@cultdeadsheep.org>.
Pour plus d'informations :
http://www.freebsd.org/cgi/url.cgi?ports/net/haproxy/pkg-descr
http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/haproxy/
http://www.freshports.org/net/haproxy
2005-12-17 11:21:26 +00:00
-- fin --