Haproxy kuren op Debian 9

[Xtremelead]

Mijn situatie:
Internet komt via FRITZ!Box 7581 binnen op Ubiquity Edgerouter. Poorten 80 en 443 zijn geforward naar Debian VM op MS HyperV 2012. Op deze VM heb ik haproxy en nginx geinstalleerd om als reverse proxy (zonder loadbalancing) inkomende webrequests door te sturen naar een paar interne webservers. LAN netwerk is 192.168.100.0/24 en DMZ netwerk is 172.16.3.0/24. In dit DMZ netwerk zit de haproxy server en een webserver.

Na het starten van haproxy duurt het even voordat de websites zichtbaar zijn. Waarschijnlijk omdat haproxy even nodig heeft om op te starten, maar daar heb ik geen bewijs van. Zodra haproxy eenmaal draait zijn de websites te benaderen, maar na een aantal nieuwe sessies stopt haproxy ermee.

In de haproxy logs zie ik dan onder andere de volgende meldingen:
...... http web01/web01 0/0/5/-1/10006 504 194 - - sH-- 0/0/0/0/0 0/0......
en
.......http web01/web01 0/0/-1/-1/40008 503 212 - - cC-- 0/0/0/0/3 0/0......
en
....... http http/<NOSRV> -1/-1/-1/-1/0 503 212 - - SC-- 0/0/0/0/0 0/0.......

mijn haproxy.conf:

code:

global
  log                       /dev/log local0 
  log                       /dev/log local1 notice
  daemon
  chroot                    /var/lib/haproxy
  user                      haproxy
  group                     haproxy

defaults
  mode                      http
  log                       global
  timeout server            10s
  timeout client            10s
  timeout connect           10s
  option http-ignore-probes
  option http-server-close
  option forwardfor
  option contstats
  option socket-stats
  option prefer-last-server
  
frontend http
  bind *:80
  option httplog
  acl host_domein hdr(host) -i domein.nl
  use_backend web01 if host_domein
  
backend web01
  server web01 172.16.3.2:80

Dit is niet mijn productie config, maar een uitgeklede configuratie voor test. In tests heb ik nginx ook gestopt. (Nginx gebruik ik oa voor letsencrypt acme challenges en wat authenticaties voor bepaalde sites.)

Volgens de haproxy site:
sH The "timeout server" stroke before the server could return its
response headers. This is the most common anomaly, indicating too
long transactions, probably caused by server or database saturation.
The immediate workaround consists in increasing the "timeout server"
setting, but it is important to keep in mind that the user experience
will suffer from these long response times. The only long term
solution is to fix the application.
c the client-side timeout expired while waiting for the client to send or receive data.
C the proxy was waiting for the CONNECTION to establish on the
server. The server might at most have noticed a connection attempt.
SC The server or an equipment between it and haproxy explicitly refused
the TCP connection (the proxy received a TCP RST or an ICMP message
in return). Under some circumstances, it can also be the network
stack telling the proxy that the server is unreachable (eg: no route,
or no ARP response on local network). When this happens in HTTP mode,
the status code is likely a 502 or 503 here.

Als ik de websites rechtstreeks oproep, dus buiten haproxy om, werken die zonder problemen, dus het lijkt geen webserver probleem.

Ik heb het vermoeden dat er iets in het netwerk deel niet goed gaat, aangezien ssh sessies naar de haproxy server er soms ook uitgegooid worden. Enkele minuten later beginnen de websites en ssh het langzamerhand weer te doen, waarna de websites er meestal weer me kappen.

Ik dacht in eerste instantie dat ik tegen het maximum tcp connecties aan zat, dus die heb ik verhoogd en nog wat settings aangepast:
sysctl net.ipv4.ip_local_port_range="15000 61000"
sysctl net.ipv4.tcp_fin_timeout=30
sysctl net.ipv4.tcp_tw_recycle=1
sysctl net.ipv4.tcp_tw_reuse=1
sysctl net.core.somaxconn=1024

Dit lijkt niet te helpen. Ook als ik met tcpdump het netwerkverkeer bekijk, zie ik rare dingen:
- Soms komen er helemaal geen connecties binnen (in de edgerouter logs worden ze wel verstuurd)
- Soms komen er wel connecties binnen, maar zie ik niet dat haproxy er iets mee doet: niks te zien in logs.

Ik heb de timeout settings in de config al hoger en lager ingesteld.
Debian 9 is geinstalleerd met alleen de basis componenten (ssh server en standard system utils).

Iemand een idee wat hier aan de hand kan zijn? Mist het OS misschien wat webserver tuning oid?

[ik222]

Werkt normaal netwerkverkeer van en naar de HAProxy VM wel goed? Dus zie je geen packetloss als je bijvoorbeeld vanaf deze VM een floodping doet naar je webserver?

[Hero of Time]

Eerste waar ik aan denk is Hyper-V. Wat als je ipv Hyper-V bijvoorbeeld VirtualBox gebruikt, of een heel ander host OS?

Wist je dat je ook een pagina bij HAProxy kan opvragen met de statistieken erop, en de status van je backend(s) (dus de webserver(s) waar je naar verbindt)? Dat is erg nuttig om te achterhalen wat er mogelijk mis gaat. Je kan tevens de 'check' optie meegeven op je backend zodat haproxy kan controleren of deze echt online is en indien dat niet het geval is, een http/500 pagina weergeven.

[Sandor_Clegane]

Xtremelead schreef op zondag 15 april 2018 @ 15:22:
Snip

Is het een Gen2 of een Gen1 VM? Volgens mij gebruikt HaProxy ook promiscuous mode voor zijn netwerkkaarten om zijn werk te doen niet?

Kan zijn dat je in HyperV op de netwerkkaart van de VM aan moet zetten dat hij in promiscuous mode mag draaien.

Edit: Volgens mij is het "Enable MAC address spoofing" in de advanced features van de netwerkkaart.

[ Voor 12% gewijzigd door Sandor_Clegane op 15-04-2018 21:46 ]

[Xtremelead]

ik222 schreef op zondag 15 april 2018 @ 20:58:
Werkt normaal netwerkverkeer van en naar de HAProxy VM wel goed? Dus zie je geen packetloss als je bijvoorbeeld vanaf deze VM een floodping doet naar je webserver?

Tijdens de problemen uiteraard wel. Ik zal vanavond eens haproxy en nginx stoppen en kijken hoe het dan gaat

Hero of Time schreef op zondag 15 april 2018 @ 21:05:
Eerste waar ik aan denk is Hyper-V. Wat als je ipv Hyper-V bijvoorbeeld VirtualBox gebruikt, of een heel ander host OS?

Wist je dat je ook een pagina bij HAProxy kan opvragen met de statistieken erop, en de status van je backend(s) (dus de webserver(s) waar je naar verbindt)? Dat is erg nuttig om te achterhalen wat er mogelijk mis gaat. Je kan tevens de 'check' optie meegeven op je backend zodat haproxy kan controleren of deze echt online is en indien dat niet het geval is, een http/500 pagina weergeven.

Een andere hypervisor is mijn laatste optie.
Die stats pagina ken ik en bevestigen eigenlijk alleen maar de problemen: ik zie meerdere 5xx meldingen voorbij komen.
De check optie heb ik in mijn productie config staan, maar niet zo goed naar gekeken. Ik zal dit in mijn test config aanzetten.

Sandor_Clegane schreef op zondag 15 april 2018 @ 21:43:
[...]


Is het een Gen2 of een Gen1 VM? Volgens mij gebruikt HaProxy ook promiscuous mode voor zijn netwerkkaarten om zijn werk te doen niet?

Kan zijn dat je in HyperV op de netwerkkaart van de VM aan moet zetten dat hij in promiscuous mode mag draaien.

Edit: Volgens mij is het "Enable MAC address spoofing" in de advanced features van de netwerkkaart.

Die optie is dacht ik alleen nodig voor loadbalancing, maar ik zal 'm aanzetten en zien of het iets helpt. Gen1 of 2 is geen optie in HyperV 2012.

[Hero of Time]

Een andere hypervisor is in eerste instantie puur om te testen, zodat je dat stuk in je netwerk uit kan sluiten. Als je met VB bijvoorbeeld geen issue hebt, zit Hyper-V gewoon ergens enorm te fucken en kan je niets in je VM met HAProxy configuratie oplossen, want daar ligt het probleem niet. Het is namelijk niet de eerste keer dat Linux VMs op Hyper-V gezeik hebben met netwerk.

[Xtremelead]

Ping test doet raar...
- Terwijl nginx en haproxy draaien en websites moeilijk bereikbaar zijn: flood ping vanaf proxy naar webserver (overigens ook een VM op zelfde server) gaat ok. Ping vanaf userlan (192.168.100.0/24) naar proxy geeft veel timeouts, maar naar de webserver ok.
- Nginx en haproxy gestopt: floodping nog steeds ok naar webserver. Ping vanaf userlan proxy en webserver ok.
- Nog wat pings en ssh sessies gestart van userlan, pings nog steeds ok. WinSCP vanaf userlan gestart: begint 1 pingsessie timouts te geven....na een aantal minuten verdwijnen te timeouts weer en gaat de ping vanaf userlan weer ok.

Tussen de proxy en webserver lijkt het dus wel goed te gaan, maar zodra er (te?) veel sessies gemaakt worden, beginnen de problemen.

Tijdens het schrijven zie ik pings vanaf het userlan weer timeouts geven, maar naar de webserver blijft het goed gaan. Tussen proxy en webserver blijft het goed gaan.

Edit: een aantal minuten nadat ik de WinSCP sessie heb gesloten, begint de ping vanaf userlan weer te lopen

[ Voor 5% gewijzigd door Xtremelead op 16-04-2018 19:41 ]

[Hero of Time]

Aangezien ik geen enkel issue ken met netwerken op Linux, zowel bare metal als in een VM draaiende op VMWare ESXi en VirtualBox, geef ik hier toch echt de schuld aan Hyper-V. Als je ook gaat zoeken, vind je meer issues tussen Linux en Hyper-V.

Ik wil je toch echt aanraden om de VMs die je nu hebt eens te draaien in VirtualBox. Of desnoods op ESXi.

[Xtremelead]

Daar gaat het inderdaad op lijken ja. Ik ga eerst even een andere distro proberen.

[Xtremelead]

Heb inmiddels haproxy met nginx op CentOS 7 draaien en tot nu toe zonder uitvallen.

Het enige waar ik nu nog tegen aan loop, is dat de module headers-more van het nginx package niet via yum beschikbaar is. Deze is in Debian 9 te installeren als nginx-extras, maar in CentOS moet deze blijkbaar handmatig gecompileerd worden...

[patatman12]

Even helemaal "out of the box" denkende. Je zou ook naar Caddy kunnen kijken als reverse proxy.
Ben zelf enige tijd geleden overgestapt, en ben er super tevreden over. Vooral met Let's encrypt certificaten werkt het echt super goed!

[Hero of Time]

patatman12 schreef op vrijdag 20 april 2018 @ 14:18:
Even helemaal "out of the box" denkende. Je zou ook naar Caddy kunnen kijken als reverse proxy.
Ben zelf enige tijd geleden overgestapt, en ben er super tevreden over. Vooral met Let's encrypt certificaten werkt het echt super goed!

Maar dat had het initiële probleem niet opgelost van connectie issues door Hyper-V icm Debian.