Bonjour les linuxiens,
Je souhaiterai avoir quelques explications sur la configuration de serveurs apache en mode reverse proxy, avec des serveurs applicatifs apache.
J'ai monté pour ma boite actuelle, des environnements "haute dispo" et "redondés" en mode direct routing :
2 Loadbalancers piranha - nommés lb1 et lb2 - (centos6.5) avec une VIP. Le noeud actif redirige mode WLC les requêtes sur les 2 reverse proxy
2 reverse proxy apache - nommés rp1 et rp2 -(centos6.5) qui redirigent les connexions vers des serveurs d'arrière plan (backend)
1 serveur applicatif - nommé app - (centos6.5) apache/php5/etc. Il y aura d'autres serveurs applicatifs après.
En mode direct routing, ce sont les reverse proxy qui répondent aux clients sans que la requête ne passe par les loadbalancers.
VOilà, le cadre est posé :-)
Si je fais appel à vous c'est bien évidemment parce qu'il y a un souci sur lequel je bute depuis un petit moment.
Lorque je me connecte sur ma VIP (via mes navigateurs favoris), j'accède bien à la page d'accueil de mon site (hébergé sur app1). (ex : http://vip/index.php)
lb1 (actif) et lb2 fonctionnent correctement.
rp1 (httpd arrêté) et rp2 (httpd démarrré)
app renvoi bien les pages que je demande.
je vais sur une app (ex : http://vip/app1/index.php), ca fonctionne.
Je fais quelques tests dans l'app1 (essentiellement des validations de formulaire qui vont faire des selections dans une base de données).
Les petites requêtes semblent fonctionner mais dès que la requête semble durer trop longtemps : messages d'erreurs dans mon navigateur:
POST https://vip/app1/ws/ws1.php net::ERR_CONNECTION_RESET
Côté RP il faut attendre quelques minutes pour voir le logs
==> /var/log/httpd/extranet.error.log <==
[Tue Nov 24 09:26:06 2015] [error] [client ipcliente] (70007)The timeout specified has expired: proxy: error reading status line from remote server app1.domaine.fr, referer: https://vip/app1/index.php
[Tue Nov 24 09:26:06 2015] [error] [client ipcliente] proxy: Error reading from remote server returned by /app1/ws/ws1.php, referer: https://vip/app1/index.php
==> /var/log/httpd/extranet.access.log <==
ipcliente - - [24/Nov/2015:09:23:06 +0100] "POST /app1/ws/ws1.php HTTP/1.1" 502 434 "https://vip/app1/index.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
ipcliente - - [24/Nov/2015:09:22:20 +0100] "POST /app1/ws/ws1.php HTTP/1.1" 200 14187 "https://vip/app1/index.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
Côté app, l'erreur apparaît au même moment :
==> /var/log/httpd/extranet.error.log <==
[Tue Nov 24 09:28:39 2015] [info] [client rp2] (32)Relais brisé (pipe): core_output_filter: writing data to the network
==> /var/log/httpd/extranet.access.log <==
rp2 - - [24/Nov/2015:09:23:06 +0100] "POST /app1/ws/ws1.php HTTP/1.0" 200 16652 "https://vip/app1/index.php" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/45.0.2454.101 Chrome/45.0.2454.101 Safari/537.36"
Voyant cela, j'ai essayé d'optimiser les serveurs apache un peu de partout… Mais rien n'y fait! Pas moyen d'utiliser mes reverse proxy. Quand je tests en contactant directement l'app1 (http://app/app1/index.php) tout fonctionne, je n'ai pas ces problèmes de coupures de connexion. Je ne peux pas remettre en cause les connexions app <-> base oracle, puisque en contactant le serveur backend en direct tout fonctionne.
Je ne suis pas un expert apache mais j'ai pris le temps de lire les documentations officielles
VOici la configuration de mes serveurs apache :
RP :
NameVirtualHost *:443
<VirtualHost *:443>
ServerName extranet.domaine.fr
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/extranet.key
SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
ProxyRequests Off
ProxyPreserveHost On
ProxyReceiveBufferSize 2048
ProxyStatus On
#ProxyTimeout 300
#EnableSendfile Off
ServerSignature Off
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1
SetEnv X-Forwarded-User On
SetEnv X-Forwarded-For On
SetEnv X-Forwarded-Host On
SetEnv X-Forwarded-Server On
<Location /ok.html>
Order deny,allow
Allow from all
</Location>
# ProxyPass / http://app.domaine.fr/ disablereuse=on retry=0 flushpackets=On
# ProxyPassReverse / http://app.domaine.fr/
ProxyPass / http://app.domaine.fr/
ProxyPassReverse / http://app.domaine.fr/
LogLevel notice
CustomLog /var/log/httpd/extranet-ssl.access.log combined
ErrorLog /var/log/httpd/extranet-ssl.error.log
</VirtualHost>
Et côté app
<VirtualHost *:80>
AddDefaultCharset UTF-8
ServerAdmin email.mondomaine.fr
ServerName extranet.mondomaine.fr
DocumentRoot /var/www/extranet
TimeOut 900
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
EnableSendfile Off
<Location /ok.html>
Order deny,allow
Allow from all
</Location>
<Directory "/var/www/extranet">
Order Deny,Allow
Allow from all
EnableSendfile Off
EnableMMAP Off
<Files ~ "inc\~*$">
Order allow,deny
Deny from all
Allow from 127.0.0.1
</Files>
<filesMatch ".(pdf|doc|docx|xls|xlsx|zip|ppt|pptx)$">
Header unset ETag
Header set Cache-Control "store, no-cache, must-revalidate, post-check=0, pre-check=0"
Header set Pragma "no-cache"
Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
</filesMatch>
</Directory>
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
ErrorLog /var/log/httpd/extranet.error.log
CustomLog /var/log/httpd/extranet.access.log combined
</VirtualHost>
Ce qui m'agace le plus c'est que j'ai déjà configuré ce genre d'infra 8 fois sur des serveurs redhat avec des RP en mode_jk. Mais là je ne comprends pas pourquoi le serveur applicatif n'arrive pas à répondre à temps.
Sur app, J'ai optimisé php.ini comme ceci dans le doute :
max_execution_time = 600
max_input_time = 300
memory_limit = 512M
J'ai aussi vérifié la configuration des service httpd (worker et prefork).
rp en mode worker (à la mode "nginx") : pas de changement
app en mode prefork - avec optimisation :
<IfModule worker.c>
StartServers 16
MaxClients 1000
MinSpareThreads 50
MaxSpareThreads 150
ThreadsPerChild 50
MaxRequestsPerChild 0
</IfModule>
Je vous remercie de m'avoir lu et j'espère que vous saurez enlever l'épine de mon pied endolori !
# Keepalive des apaches
Posté par jemore . Évalué à 1.
Essaye de diminuer, voir d'annuler, le "keepalive" des apaches "App". Peut etre que par défaut, si tu es en HTTP1.1, les apaches maintiennent la connection HTTP ouverte avec les LB. Cela abouti à un timeout au bout d'un moment. Tu peux aussi mettre une directive "Timeout" sur tes ProxyPass.
[^] # Re: Keepalive des apaches
Posté par popof . Évalué à 1.
Salut Merci pour ta réponse.
J'avais déjà essayé les paramètres que tu suggères
J'ai pu refaire des tests, même erreur.
POur info voici ce que j'avais mis dans la partie globale du vhost:
Comme tu vois j'ai essayé de mettre le paquet. (peut être que j'ai écris des erreurs ??)
# Ca timeout quand ?
Posté par romain11 . Évalué à 1.
Est ce que ca timeout apres un certain temps que tout soit lancé et quelle que soit la requete (ce que suggère jemore)?
Ou alors est ce que ca timeout lorsque cest la requete qui échoue qui est longue (par ex une requete qui prend >5s) ?
Si c'est le second cas, tu as peut etre un timeout trop bas qqpart :
{timeout TCP , timeout HTTP} X {Client , LB , RP , app} ca va vite d'oublier une possibilité.
[^] # Re: Ca timeout quand ?
Posté par popof . Évalué à 1.
Ca timeout assez rapidemment en fait.
VOici quelques échantillons faits depuis la VIP, ca provient du débugeur de chrome.
La dernière requête à dépasser les 3 secondes et pourtant elle a abouti, contrairement aux 2 derniers plantage.
Je ne sais vraiment pas quoi en penser
[^] # Re: Ca timeout quand ?
Posté par popof . Évalué à 1.
Bon, je suis toujours un peu perdu :-)
VOici les différents logs que j'obtiens :
Si quelqu'un a le courage de regarder les logs… :-)
J'ai fait quelques modifs dans les vhosts côté RP et côté APPS. J'ai mis ces paramètres des 2 côtés :
# Problème résolu
Posté par popof . Évalué à 1.
Le problème ne se situait pas au niveau des RP et du serveur backend.
Les loadbalancers étaient mal configurés…
Tout fonctionne. Il m'a fallu démanteler briques après briques pour comprendre.
Ouf
Merci pour votre aide
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.