Haproxy Apache Graceful

Web, mail, IRC, IM, hálózatok

Van egy apache szerverem egy haproxy mögött. Minden jól működik, kivéve az apache webszerver újraindítását (graceful). Ez esetben a haproxy 503-as hibát ad a kliensek felé, míg az újraindítás tart.Haproxy nélkül az apache a graceful alatt is fogadja a TCP kapcsolatokat, és nem dobja el, csupán várakoztatja azokat, míg az új konfiguráció alapján ki nem tudja szolgálni.
A haproxy azonaban 5-10 másodperc várakoztatás után visszautasítja a kérelmet, 503-as hibával.
A log alapján a haproxy a graceful ideje alatt elérhetetlennek minősíti a webszervert, és emiatt dobja el a kérelmeket.
Nem találtam olyan konfigurációs paramétert, amivel hosszabb várakozásra késztethetném a haproxy-t.
Valakinek van valamilyen ötlete, netán tapasztalata ilyen problémával kapcsolatban?

( gyu v | 2017. 03. 23., cs – 15:58 )

Ha egy szal apache van a haproxy-d mogott, akkor minek ele egyaltalan a haproxy?

( Mcsiv v | 2017. 03. 23., cs – 18:54 )

A mode http környékén helyezd el ezt:

timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms

Illetve játsz az értékekkel.

Egyébként legjobb tudomásom szerint amikor gracefull restartolod az apache-t és szüttyög, akkor nem fut le az accept a kliens socket-re, így vélhetőleg a timeout connect -et kéne emelned. Ha tévedek, akkor a timeout server -t

// Happy debugging, suckers
#define true (rand() > 10)

Ezeket az értékeket emeltem fel először. Most 2m mindegyik. Sőt, próbáltam már az összes többi lehetséges timeout paramétert is felemelni, de bármit is állítok, 10 másodpercen belül eldobja a kapcsolatot. Már kezdem azt hinni, hogy ez nem egy haproxy beállítás, hanem valamilyen rendszerszintű. Kerestem linux tcp timeout paramétereket, de azzal sem sikerült megoldanom a problémát.
Annyi látszik a napló alapján, hogy a haproxy nem a kérelmek alapján minősíti a szervert elérhetetlennek, hanem a háttérben figyel, és egyetlen beérkező kérelem nélkül is észleli, hogy az apache épp nem elérhető. Tehát van valamilyen monitora, de így sem találtam olyan konfigurációs értéket, ahol ezt a monitor lehetne késleltetni.
Számomra érdekesség még, hogy a napló alapján 0 próbálkozás után nyilvánítja elérhetetlennek a szervert, bár a retries értéke 3.

Regebben rpc over http nem mukodott nginx-el, 1.7.11 ota mar az igy megy.
Ami rettenet nagy kulonbseg van ketto kozt, az a monitorozas, nginxbol sok okosat meg nem lattam hogy kiszedtek volna, haproxynak gyakorlatilag mindent tudsz monitorozni.
Illetve nekem a haproxy sokkal robosztusabbnak tunik, de ez lehet szimpla reszrehajlas mar :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Namost az nginx loadbalancer reszet ugy dobnam ki a kodbol, ahogy van. (Esetleg odairnam, hogy experimental, csak sajat szopatasodra hasznald.) A fentebb emlitett monitoring csak a jeghegy csucsa, nekem vannak logjaim eltuno, valamint MEGDUPLAZOTT requestekrol...
Nalunk naivan a tranzakcios api elott volt egy ideig nginx balancer; buli volt kinyomozni, hogy miert lett a penz ketszer elkuldve...

Ha nalatok meg dontes elott vagytok, hat ne habozzatok az nginxet kihuzni a lehetseges loadbalancer listarol, ha fontos a konzisztencia...

> nekem vannak logjaim eltuno, valamint MEGDUPLAZOTT requestekrol...

Ez az elosztott rendszereknél előfordul. Érdemes tisztában lenni az elosztott rendszerek tulajdonságaival és nem téveszmékben hinni.
Ha nálatok a "tranzakciós api" fel lenne erre készülve és pl. idempotens üzenetekkel dolgozna, akkor a dupla üzenetből nem származna semmi gond.
Természetesen, ha a "tranzakciós api" erre nincs felkészülve, akkor minél inkább törekedni kell arra, hogy minél megbízhatóbb legyen a hálózat. Ez a nehezebb ügy.

Az idempotens reszt nem vitatom, mindenkinek konnyebb lenne az elete. Pl hiaba kell nonce a request bekuldesehez, de sajat magunk alatt vagjuk a fat, mert van grace period is (pl a halozat megbizhatatlansagabol nem sorrendben erkezo requestek validalasara - na pl attol is befontam a hajam anno). A nem eleg pontos nonce-t hasznalo ugyfelekrol (duplikatumok, pl) ne is beszeljuk.

Visszaterve az nginxre, kirohanasom igazi oka az, hogy esetemben localhost-rol beszelunk, az nginx tobb local instance kozott balanszolt. A jelenseg reprodukalhato volt tobb kornyezetben is; a konkurrencia sem volt tenyezo, egy szalon bekuldott requestek is megduplazodnak. Beletettunk par munkaorat a konfigolasba, mire letettunk errol az iranyrol.

Felreertes ne essek, velemenyem szerint az nginx nagyon jo webszerver, millio masik helyen hasznaljuk (pl akar a balancerrel lancba fuzve is), de "lampat a lampaboltbol".

Sokan mások is így gondolják és csodálkoznak, ha elvesznek, több példányban, illetve rossz sorrendben mennek üzenetek.

Én kb. ezt a definíciót értem alatta:
A distributed system is a network that consists of autonomous computers that are connected using a distribution middleware. They help in sharing different resources and capabilities to provide users with a single and integrated coherent network.

Természetesen minél kisebb, minél kevesebb elemből áll, minél közelebb vannak egymáshoz, minél jobb minőségű hálózati eszközök vannak, annál kisebb a problémák lehetősége, de ugyanúgy fennáll.

"A distributed system is a network that consists of autonomous computers that are connected using a distribution middleware. They help in sharing different resources and capabilities to provide users with a single and integrated coherent network."

Ettől kezdve elosztott rendszer egy webszerver és egy adatbázis szerver? Elosztott rendszer a kliens-szerver architektúra? Minden önálló számítógép, amelyek között bármilyen hálózat van, az elosztott rendszer?

Szóval mitől lesz elosztott rendszer egy darab load-balancer mögé tett két darab szerver? :)

"Sokan mások is így gondolják és csodálkoznak, ha elvesznek, több példányban, illetve rossz sorrendben mennek üzenetek."

Akkor fordítva kérdezem: a definíciód szerint mi az, ami nem elosztott rendszer?

"Természetesen minél kisebb, minél kevesebb elemből áll, minél közelebb vannak egymáshoz, minél jobb minőségű hálózati eszközök vannak, annál kisebb a problémák lehetősége, de ugyanúgy fennáll."

Szóval akkor hol húzzuk meg a határt?

"Szerk.: Ha nem derült volna ki az én korábbi írásaimból, akkor nálam a fenti definíciót megvalósító legkisebb egységnél van a határ, ami kettő gép."

Bármilyen hálózaton összekötött bármilyen két gép már elosztott rendszer? Biztos?

Stateless komponensek felett egy darab buta load-balancer semmiképp nem elosztott rendszer. Komolyan azt mondod, hogy két statikus webszerver round-robin DNS beállítással már elosztott rendszer?!

"Te hol húzod meg?"

Ha már belinkelted a https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing oldalt, akkor onnan vezet egy link, ahol leírják, hogy mi is az elosztott rendszer: https://en.wikipedia.org/wiki/Distributed_computing

Esetleg tanulmányozd át...

Elfelejtettél válaszolni, hogy te hol húzod meg.

> Esetleg tanulmányozd át...

Nem látok benne semmi ellentmondást az eddigi álláspontomhoz képest.

Ehhez pl. mit szólsz?

Distributed programming typically falls into one of several basic architectures: client–server, three-tier, n-tier, or peer-to-peer; or categories: loose coupling, or tight coupling.

Tételesen is válaszolok.

> Ettől kezdve elosztott rendszer egy webszerver és egy adatbázis szerver?

Igen, ha a működése több gépre van szétosztva. Pl. az adatbázis cluster-ek, azok elosztott adatbázis rendszerek; vagy amit nagyon nem akarsz elhinni: két statikus webszerver round-robin DNS beállítással már elosztott rendszer

> Elosztott rendszer a kliens-szerver architektúra?

Igen.

> Minden önálló számítógép, amelyek között bármilyen hálózat van, az elosztott rendszer?

Nem, csak akkor, ha ugyanazon feladat megoldását oldják meg együtt.

> Szóval mitől lesz elosztott rendszer egy darab load-balancer mögé tett két darab szerver? :)

Attól, hogy ugyanazon feladat megoldását oldják meg együtt, elosztott módon.

> Akkor fordítva kérdezem: a definíciód szerint mi az, ami nem elosztott rendszer?

Minden, ami nem elosztott módon, vagy nem egy feladat megoldására való.

Remélem minden nézőpontomat tisztáztam. További kérdésekre már nem szeretnék válaszolni, de azt szívesen látnám, hogy Te ezeket miért nem tartod elosztott rendszereknek.

Észrevetted, hogy még egy kérdésemre se válaszoltál?
Én mindegyik kérdésedre válaszoltam, ez így elég egyoldalú.

> Egyetlen példát mondj csak, amire nem lehet ráfogni valamilyen módon azok alapján, amit leírtál.

Na jó, ez az utolsó:
Egyik gépen egy adatbáziskezelő, a másik gépen egy web server program, ami nem használja az adatbázist. Ez a két, hálózattal összekötött gépen futó két program nem alkot elosztott rendszert.
Sok ugyanolyan (vagy más) program fut egy gépen, amik tetszőleges módon kommunikálnak egymással, ezek sem alkotnak elosztott rendszert.

"Észrevetted, hogy még egy kérdésemre se válaszoltál? Én mindegyik kérdésedre válaszoltam, ez így elég egyoldalú."

Értelmesen egyikre se válaszoltál és a kérdésekre értelmesen nem tudok válaszolni, amíg az ki nem derül, hogy hol húzod meg a határt... a definícióértelmezésed alapján _minden_ rendszer elosztott rendszer.

"Egyik gépen egy adatbáziskezelő, a másik gépen egy web server program, ami nem használja az adatbázist. Ez a két, hálózattal összekötött gépen futó két program nem alkot elosztott rendszert."

De ezek így rendszert se alkotnak.

"Sok ugyanolyan (vagy más) program fut egy gépen, amik tetszőleges módon kommunikálnak egymással, ezek sem alkotnak elosztott rendszert."

És rendszert alkotnak? Hol a határvonal az elosztott és nem elosztott rendszer között?

> Értelmesen egyikre se válaszoltál és a kérdésekre értelmesen nem tudok válaszolni, amíg az ki nem derül, hogy hol húzod meg a határt... a definícióértelmezésed alapján _minden_ rendszer elosztott rendszer.

Még ekkora bullshit-et!
Azért nem tudod megmondani, hogy pl. egy kliens-server program miért nem elosztott rendszer, mert nem tudod, hogy én mit gondolok? Hogyan függ ez össze? Az összes kérdésem ilyen, egyik válasz se függ attól, hogy én mit gondolok. Másért nem lesz az, ha A-t gondolok és mástól nem lesz az, ha B-t gondolok? Ez azért elég gyenge próbálkozás.

"Még ekkora bullshit-et!"

Nincs ebben semmi bullshit.

"Azért nem tudod megmondani, hogy pl. egy kliens-server program miért nem elosztott rendszer, mert nem tudod, hogy én mit gondolok?"

Kliens-szerver architektúra nem lesz automatikusan elosztott rendszer. De egy elosztott rendszer architektúrája lehet kliens-szerver architektúra.

"Az összes kérdésem ilyen, egyik válasz se függ attól, hogy én mit gondolok."

De, nagyon is függenek a kérdések és a válaszok attól, hogy _szerinted_ mi különböztet meg egy _rendszert_ egy _elosztott rendszertől_. Ha olyan példákat hozol fel, mint nem elosztott rendszer, amelyek nem is alkotnak rendszert, akkor bizony közös alapokra kell hozni a definíciókat.

> Kliens-szerver architektúra nem lesz automatikusan elosztott rendszer.

Mondj már egy példát erre, amikor nem az. Egyik gépen a kliens, másikon a szerver, hálózaton kommunikálnak és mégsem elosztott rendszer.

> Ha olyan példákat hozol fel, mint nem elosztott rendszer, amelyek nem is alkotnak rendszert, akkor bizony közös alapokra kell hozni a definíciókat.

Egy példát kértél, ami nem az. Adtam kettőt, egyikben az összetevők nem voltak egy rendszer, a másikban rendszer volt, de nem volt elosztott.
Ha olyat vársz, ami rendszer is és elosztott is, de mégsem elosztott rendszer, na olyat nem tudok.
Volt harmadik példa is, a két gépen a kliens-szerver; volt negyedik is, a LoadBalancer mögött a két web szerver.

"Mondj már egy példát erre, amikor nem az. Egyik gépen a kliens, másikon a szerver, hálózaton kommunikálnak és mégsem elosztott rendszer."

Baszki. Mitől lenne elosztott rendszer kliens-szerver architektúra? Attól, hogy (hálózaton) kommunikál egymással két dolog, attól még nem lesz elosztott egy rendszer. Jól látszik, hogy teljesen félreértetted az idézett Wikipedia részt is, ahol azt írják, hogy egy elosztott rendszer architektúrája lehet kliens-szerver architektúra, de ettől még nem lesz minden kliens-szerver architektúra elosztott rendszer.

"Egy példát kértél, ami nem az. Adtam kettőt, egyikben az összetevők nem voltak egy rendszer, a másikban rendszer volt, de nem volt elosztott."

Baszki. Ami nem rendszer, az nyilván nem lehet elosztott rendszer se. A másik példád se volt rendszer: a rendszer feltételezi a részeinek egymáshoz való kapcsolatát, ha pedig a részei kapcsolódnak, akkor szerinted innentől elosztott rendszer. Önmagában álló dolog vagy egymástól teljesen független dolgok nem alkotnak rendszert.

Például nem egy rendszer, hanem kettő különálló dolog, ha: "Egyik gépen egy adatbáziskezelő, a másik gépen egy web server program, ami nem használja az adatbázist. Ez a két, hálózattal összekötött gépen futó két program nem alkot elosztott rendszert.", mert az adatbáziskezelő teljesen irreleváns a webszerver szempontjából. Rendszereknél nem a _lehetőségét_ nézzük a kapcsolódásnak, hanem a _tényét_.

Szerinted "Sok ugyanolyan (vagy más) program fut egy gépen, amik tetszőleges módon kommunikálnak egymással, ezek sem alkotnak elosztott rendszert.", pedig lehet elosztott rendszer akkor is, ha _fizikailag_ egy hardveren fut az összes komponense és lehet klasszikus rendszer, ha külön gépeken futnak a komponensei, mert nem a konkrét telepítéstől függ a _elosztott_ minősítése, hanem a topológiájától.

De tételezzük fel, hogy egy gépnél húzod meg a határt:
- Ha egy gépen két külön CPU magon fut, akkor már elosztott lesz?
- Ha két külön virtuális gépben fut egy fizikai hardveren, akkor már elosztott lesz?
- Ha egy blade chassis-ban, de külön blade szerveren fut, akkor az már elosztott vagy még egy gép, mert egy blade önmagában működésképtelen?
- Függ az elosztottsága egy rendszernek attól, hogy a komponensei egy időpillanatban egy fizikai hardverre kerülnek vagy egy adatközpontban vannak épp virtualizálva?

"Ha olyat vársz, ami rendszer is és elosztott is, de mégsem elosztott rendszer, na olyat nem tudok."

Baszki. Olyat nem írtál eddig, ami rendszer, de nem elosztott és a definícióértelmezésed szerint minden, ami rendszer, az már elosztott rendszer, így nincs értelme az _elosztott_ minősítésnek. Szóval a világodban mi különbözteti meg a rendszert az elosztott rendszertől?

> Mitől lenne elosztott rendszer kliens-szerver architektúra? Attól, hogy (hálózaton) kommunikál egymással két dolog, attól még nem lesz elosztott egy rendszer.

Többször kértem már, hogy magyarázd meg, hogy miért nem lesz az. Eddig nem sikerült.

> Jól látszik, hogy teljesen félreértetted az idézett Wikipedia részt is, ahol azt írják, hogy egy elosztott rendszer architektúrája lehet kliens-szerver architektúra, de ettől még nem lesz minden kliens-szerver architektúra elosztott rendszer.

Gondolom ezt a részt is félreértem teljesen: A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages.[1] The components interact with each other in order to achieve a common goal.

Magyarázd el miért nem igaz ez minden kliens-szerver architektúrára! Ha nem tudod megmagyarázni, akkor legalább egy példát mondj!

"Többször kértem már, hogy magyarázd meg, hogy miért nem lesz az. Eddig nem sikerült."

Ahogy neked sem sikerült elmagyaráznod, hogy mitől az...

"Magyarázd el miért nem igaz ez minden kliens-szerver architektúrára! Ha nem tudod megmagyarázni, akkor legalább egy példát mondj!"

Attól, hogy igaz rá, még nem lesz elosztott rendszer. Attól, hogy minden minden bogár rovar, nem lesz minden rovar bogár. Attól, hogy _megvalósítható_ az elosztott rendszer kliens-szerver architektúrában _is_, még nem lesz _minden_ kliens-szerver architektúra _elosztott rendszer_. Ha megkérdezed egy darab klienssel egy darab NTP szervertől, hogy mennyi az idő, az nem lesz ettől elosztott rendszer.

De felőlem nevezd, ahogy akarod, csak akkor ne csodálkozz, ha itt-ott hülyének néznek, ha egy darab statikus webszervert üzemeltetsz évek óta és beírod a CV-be, hogy komoly tapasztalatod van elosztott rendszerekkel kapcsolatban.

Elnézést, hogy megszakítom a gondolatot, de nekem túl sokat nem adott az elkövetkező eszmecsere arról, mi az elosztott rendszer, és mi nem. Azonban úgy tűnik, mindkettőtöknek természetes az a tény, hogy egy csomag kétszer is megérkezhet a backend szerverekhez.
Megvallom, én nem értem, miért.
Anno azt tanultam, hogy a TCP például abban is különbözik az UDP-től, hogy a küldő tudja, sikerült-e a csomagot továbbítania. Tehát a frontend gép teljesen tisztában van azzal, hogy egy csomagot sikeresen továbbított-e vagy sem.
Akkor miből fakadhat az ilyen duplikált kérelemtovábbítás?

Nem, nem természetes, hogy kétszer is megérkezik. :)

"Anno azt tanultam, hogy a TCP például abban is különbözik az UDP-től, hogy a küldő tudja, sikerült-e a csomagot továbbítania. Tehát a frontend gép teljesen tisztában van azzal, hogy egy csomagot sikeresen továbbított-e vagy sem. Akkor miből fakadhat az ilyen duplikált kérelemtovábbítás?"

Valószínűleg nem TCP szinten dupláz, hanem felette. Van egy stateful ethernet protokollod, azon egy stateless IP protokollod, azon van egy stateful TCP protokollod, azon van egy stateless HTTP protokollod és azon van egy stateful protokollod, amelyik a terhelés elosztási logikát végzi. Ha ezek közül a legfelső hibás, akkor hiába stateful a TCP protokollod, ha felette sok réteggel duplázza a kérést egy komponens...

Már írtam egy hosszú választ, amikor - azt hiszem - megértettem.
A lényeg az, hogy a http válaszról nem lehet tudni, hogy sikeres volt-e a teljes kiszolgálás vagy sem?
A content-size header és a http status együttesen nem biztosítják azt, hogy a http válasz sikerességét el lehessen dönteni? Vagy az az elvi baj, hogy a válasz elkészült részei még a teljes válasz befejezése előtt továbbításra kerülnek a kliens felé?

Messzire vezető dolog ez. A webszervered nem biztosítja azt a lehetőséget, hogy ha maradéktalanul nem teljesíti a kliens kérését, akkor visszavonja a teljes tranzakciót és nincs SLA definiálva arra, hogy mennyi időn belül vesszük úgy, hogy teljesíti a tranzakciót, akkor nem tudsz jól kéréseket megbízhatóan kezelni.

"A lényeg az, hogy a http válaszról nem lehet tudni, hogy sikeres volt-e a teljes kiszolgálás vagy sem?"

Ha előáll egy HTTP válasz, akkor abból el lehet dönteni, hogy sikeres volt-e a kiszolgálás. A baj akkor van, ha időben nem áll elő a HTTP válasz, mert valamelyik komponens belassult vagy meg is állt. Ilyenkor beküldöd a kérést, a szerver elkezd dolgozni, de SLA időn túl válaszolna csak, a kliens meg már bontotta a kapcsolatot, mert nem jött válasz a megbeszélt ideig, fogalma nincs arról, hogy mi történik a szerveren. Ha ezt feldolgozod a szerver oldalán és visszavonod az összes módosítást, akkor a kliens beküldheti újra a kérést gond nélkül. Ha ezt az állapotot nem dolgozod fel a szerver oldalán, akkor van a baj, mert nem tudod eldönteni, hogy a szerver végrehajtja-e az SLA időn túl a kérést vagy sem. :)

"A content-size header és a http status együttesen nem biztosítják azt, hogy a http válasz sikerességét el lehessen dönteni?"

Nem biztos, hogy előáll egy Content-size fejléc addig, amíg a kérést teljes egészében fel nem dolgozod és ki nem szolgálod, mert általában nem tudod előre, hogy mekkora lesz a válasz. Ugyanígy bizonytalan a visszaadott HTTP status is.

"Vagy az az elvi baj, hogy a válasz elkészült részei még a teljes válasz befejezése előtt továbbításra kerülnek a kliens felé?"

Ez esetben maximum félbemarad a válasz.

A HTTP protokoll kérés-válasz alapú. A frontend kliens gép elküld egy kérést a backend szerverhez, arról tudomása van, hogy az üzenet megérkezett, de ha nem érkezik válasz (egy adott ideig), akkor nem tudja, hogy fel is dolgozta-e a backend. Itt két lehetősége van:
1) elküldi újra és akkor, ha mégis feldolgozta a backend, akkor kétszer kerül feldolgozásra; ha nem dolgozta fel, akkor egyszer fogja feldolgozni;
2) nem küldi újra, akkor ha a backend már feldolgozta, akkor minden rendben van, ha nem dolgozta fel, akkor egy kérés "elveszik", nem kerül feldolgozásra.

Ez picit ellenkezik az én elképzeléseimmel - ami persze nem az állítás minősítése. :)
Én úgy gondolom, a kérést a kliens indítja, és amíg nem kap választ, a kapcsolat él. Emiatt a frontendnek tudnia kell a kapcsolat megszakadásáig - azaz a válaszig vagy a timeout-ig -, hogy a backend feldolgozta-e a kérést vagy sem. Szerintem a frontend gépnek nincs is joga minősíteni a válaszadási időt. Maximum stabilitási okokból egy határ után megszakíthatja a várakozást a válaszra.
Tehát azt a szélsőséges helyzetet képzeljem el, ahol a frontend timeout-tal megszünteti fenntartani a kapcsolatot, és a backend ezek után válaszol? Ez akkor azért átlagos kérelemkiszolgálások esetén mégsem léphet fel, csak szélsőséges környezeti esetekben.

Bugreportot nem talaltam ra, google-ben is turni kellett kicsit, de nem csak nalunk jelentkezett a problema, lattam ruby deveket is ugyanezt feltetelezni / erre panaszkodni.

Az az igazsag, hogy nem olyan konnyen reprodukalhato a dolog, nincs szabad kezunk ennek a tortenetnek a reportig meno teljes felderitesere (jelenleg).

A backend paramétereinél vannak a checkhez kapcsolódó ismétlések, ezeket nézted?

server akarmi x.x.x.x:80 check port 80 inter 12000 rise 3 fall 3

inter - check időköze
rise - ennyiszer kell pozitív teszt, hogy elérhetőnek minősítse
fall - ennyiszer kell negatív teszt, hogy elérhetetlennek minősítse

Köszönöm, épp tegnap találtam rá erre a három server paraméterre a backend részben. Úgy tűnik, az inter hihetetlen mértékű felemelése javított a helyzeten valamit, bár meg nem oldotta. Azért paranoid vagyok, és a downinter értékét 2s-re állítottam.
Ez segít abban, hogy auotmatikusan - nagy valószínűséggel - ne detektálja elérhetetlennek a webszervert, de ha kérelem érkezik, még mindig eltimeoutol. Igaz, azóta lemértem, és nem 10 másodperc ez a timeout, hanem 35. De ettől még nem tudom feljebb emelni.

A haproxy mögé csak a https kérések vannak irányítva, három külön IP-ről érkezően. 


global
        log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /var/run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	maxconn 1000
	daemon
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	tune.ssl.default-dh-param 2048
	ssl-default-bind-options no-sslv3 no-tls-tickets
	ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

	ssl-default-server-options no-sslv3 no-tls-tickets
	ssl-default-server-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
	stats hide-version

    retries                 3
    timeout http-request    120s
    timeout queue           2m
    timeout connect         120s
    timeout client          2m
    timeout server          2m
    timeout http-keep-alive 120s
    timeout check           120s

	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend listen_ip7
    mode http
    bind 8.8.8.7:443 ssl crt /etc/haproxy/certs/8.8.8.7
    option http-server-close
    option forwardfor
    option originalto
    use_backend backend_server7

frontend listen_ip8
    mode http
    bind 8.8.8.8:443 ssl crt /etc/haproxy/certs/8.8.8.8
    option http-server-close
    option forwardfor
    option originalto
    use_backend backend_server8

frontend listen_ip9
    mode http
    bind 8.8.8.9:443 ssl crt /etc/haproxy/certs/8.8.8.9
    option http-server-close
    option forwardfor
    option originalto
    use_backend backend_server9

backend backend_server7
    mode http
    server localApache7 127.0.0.7:443 maxconn 500 check inter 2h downinter 2s ssl verify none

backend backend_server8
    mode http
    server localApache8 127.0.0.8:443 maxconn 100 check inter 2h downinter 2s ssl verify none

backend backend_server9
    mode http
    server localApache9 127.0.0.9:443 maxconn 100 check inter 2h downinter 2s ssl verify none

A 2 orankenti allapotellenorzes teljes nonszensz... Allitsd be ertelmesre, par masodpercre, kulonben az eletben nem veszi eszre a haproxy, hogy ledolt mogule az apache. Ami neked kell az az ellenorzes megfeleloen beallitasa. Merd meg, mennyi ideig tart az apache ujrakonfiguralasa, es utana a fall * fastinter legyen ennek megfeleloen belove, a mostani konfigoddal ez 6 masodperc.

Az inter nonszensz értékű felemelése eddig a legjobb megoldás. Azóta érdemben kevesebb az 503 (egy nap 3-6 darab). Itt már megjelentek a CC-- és az ---- státusszal naplózott 503-ak.
Ha több apache szerver lenne mögötte, aggódnék én is a magas inter időn, de így, hogy csak 1 szerver szolgálja ki a kérelmeket, ha nem elérhető, úgyis kiderül a kérelem alatt. Tehát sokat nem veszítek vele. Természetesen, több webszerver esetén én sem merném ilyen magasan hagyni.
Ki fogom próbálni azt is, amit ajánlottál, és majd meglátjuk, a napi 503 mennyiség melyiknél lesz a nagyobb. Egyelőre pár napig hagyom még ezt a változatot, hogy lássam, valóban stabilan tartja-e a minimális visszautasítási mennyiséget.