Ich habe die aktuellen Konfigurationen in meiner Varnish-Datei default.vcl auf der Maschine aktiviert, die die Last für die beiden anderen Maschinen ausgleicht (auf den beiden anderen Maschinen ist Varnish ebenfalls aktiviert).
Ich möchte, dass dieser Server nur den Lastenausgleich durchführt und die anderen Maschinen die Verarbeitung und auch ihr eigenes Caching übernehmen.
Mein Problem ist, dass ich sogar beim Konfigurationstest (nicht einmal ein Stresstest oder so, nur ein paar Anfragen pro Minute) den Guru-Meditationsfehler bekomme und Varnish neu starten muss.
Dies ist die Datei default.vcl für den Lastausgleichsserver:
backend vader {
.host = "app1.server.com";
.probe = {
.url = "/";
.interval = 10s;
.timeout = 4s;
.window = 5;
.threshold = 3;
}
}
backend malgus {
.host = "app2.server.com";
.probe = {
.url = "/";
.interval = 10s;
.timeout = 4s;
.window = 5;
.threshold = 3;
}
}
director dooku round-robin {
{
.backend = vader;
}
{
.backend = malgus;
}
}
sub vcl_recv {
if (req.http.host ~ "^balancer.server.com$") {
set req.backend = dooku;
}
}
Mache ich etwas falsch oder übersehe ich etwas?
BEARBEITEN:
Dies ist die Ausgabe von Varnishlog:
0 CLI - Rd ping
0 CLI - Wr 200 19 PONG 1345839995 1.0
0 CLI - Rd ping
0 CLI - Wr 200 19 PONG 1345839998 1.0
0 CLI - Rd ping
0 CLI - Wr 200 19 PONG 1345840001 1.0
0 Backend_health - malgus Still sick 4--X--- 0 3 5 0.000000 3.846876
0 Backend_health - vader Still sick 4--X--- 0 3 5 0.000000 3.839194
0 CLI - Rd ping
0 CLI - Wr 200 19 PONG 1345840004 1.0
14 SessionOpen c 10.150.7.151 38272 :80
14 ReqStart c 10.150.7.151 38272 458200540
14 RxRequest c GET
14 RxURL c /
14 RxProtocol c HTTP/1.1
14 RxHeader c Host: dooku-dev.excelsior.com
14 RxHeader c Connection: keep-alive
14 RxHeader c User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
14 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
14 RxHeader c Accept-Encoding: gzip,deflate,sdch
14 RxHeader c Accept-Language: en-US,en;q=0.8,es-419;q=0.6,es;q=0.4
14 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
14 RxHeader c Cookie: SESSa87d6c6da0c61037a9169122dc5e4a19=HR_0Srhgc-uDArT3aJFzOBy31FtzneTXg38byr1eGMU; __atuvc=4%7C33
14 VCL_call c recv pass
14 VCL_call c hash
14 Hash c /
14 Hash c dooku-dev.excelsior.com
14 VCL_return c hash
14 VCL_call c pass pass
14 FetchError c no backend connection
14 VCL_call c error deliver
14 VCL_call c deliver deliver
14 TxProtocol c HTTP/1.1
14 TxStatus c 503
14 TxResponse c Service Unavailable
14 TxHeader c Server: Varnish
14 TxHeader c Content-Type: text/html; charset=utf-8
14 TxHeader c Retry-After: 5
14 TxHeader c Content-Length: 418
14 TxHeader c Accept-Ranges: bytes
14 TxHeader c Date: Fri, 24 Aug 2012 20:26:44 GMT
14 TxHeader c X-Varnish: 458200540
14 TxHeader c Age: 0
14 TxHeader c Via: 1.1 varnish
14 TxHeader c Connection: close
14 Length c 418
14 ReqEnd c 458200540 1345840004.916415691 1345840004.965190172 0.020933390 0.048741817 0.000032663
14 SessionClose c error
14 StatSess c 10.150.7.151 38272 0 1 1 0 1 0 256 418
14 SessionOpen c 10.150.7.151 38273 :80
14 ReqStart c 10.150.7.151 38273 458200541
14 RxRequest c GET
14 RxURL c /favicon.ico
14 RxProtocol c HTTP/1.1
14 RxHeader c Host: dooku-dev.excelsior.com
14 RxHeader c Connection: keep-alive
14 RxHeader c Accept: */*
14 RxHeader c User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
14 RxHeader c Accept-Encoding: gzip,deflate,sdch
14 RxHeader c Accept-Language: en-US,en;q=0.8,es-419;q=0.6,es;q=0.4
14 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
14 RxHeader c Cookie: SESSa87d6c6da0c61037a9169122dc5e4a19=HR_0Srhgc-uDArT3aJFzOBy31FtzneTXg38byr1eGMU; __atuvc=4%7C33
14 VCL_call c recv pass
14 VCL_call c hash
14 Hash c /favicon.ico
14 Hash c dooku-dev.excelsior.com
14 VCL_return c hash
14 VCL_call c pass pass
14 FetchError c no backend connection
14 VCL_call c error deliver
14 VCL_call c deliver deliver
14 TxProtocol c HTTP/1.1
14 TxStatus c 503
14 TxResponse c Service Unavailable
14 TxHeader c Server: Varnish
14 TxHeader c Content-Type: text/html; charset=utf-8
14 TxHeader c Retry-After: 5
14 TxHeader c Content-Length: 418
14 TxHeader c Accept-Ranges: bytes
14 TxHeader c Date: Fri, 24 Aug 2012 20:26:45 GMT
14 TxHeader c X-Varnish: 458200541
14 TxHeader c Age: 0
14 TxHeader c Via: 1.1 varnish
14 TxHeader c Connection: close
14 Length c 418
14 ReqEnd c 458200541 1345840005.226389885 1345840005.226457834 0.000026941 0.000043154 0.000024796
14 SessionClose c error
14 StatSess c 10.150.7.151 38273 0 1 1 0 1 0 256 418
Antwort1
Sie haben ein Verbindungsproblem mit Ihrem Server. Ich sehe, dass Sie in Ihren Backends DNS-Adressen verwenden. Varnish löst DNS beim Start auf und bemerkt keine Änderungen zur Laufzeit.
Haben Sie Ihr FQDN-Ziel geändert, seit Varnish gestartet wurde?
Ist Ihr DNS auf dynamische Adressen ausgerichtet?
Sie sollten versuchen, anstelle eines DNS-Namens eine statische IP zu verwenden.
Antwort2
Es stellte sich heraus, dass die Verarbeitung der Anfragen auf Backend-Servern sehr lange dauerte. Ich habe meine Architektur von einem Load Balancer ohne Varnish auf einen auf jedem Server und einen Load Balancer geändert.