Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have the current configurations active on my default.vcl varnish file on the machine that balances the load for other two machines (the other two machines also have varnish active).

My intention is to have this server do only the load balancing and the other machines do the processing and also their own caching.

My problem is that even with the config testing (not even a stress test or anything, just a few requests a minute) I get the guru meditation error and have to restart varnish.

This is the default.vcl for the load balancing server:

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;
   }
}

Am I doing something wrong or missing something?


EDIT:

This is varnishlog's output:

    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
share|improve this question
1  
Can you fire up varnishlog and provide the output that it gives when you make a request that fails? –  Shane Madden Aug 24 '12 at 16:34
    
Good idea indeed. –  dabito Aug 24 '12 at 20:25
    
I think i see what's going on.. 3s timeout is a lot, though :S something's wrong with my backend servers, I guess. –  dabito Aug 24 '12 at 20:32
1  
Yup, that's right - you're getting the error page because your backends are considered unhealthy from the health check probe. If you run a curl http://app1.server.com/ from the varnish server, what happens? –  Shane Madden Aug 24 '12 at 21:01

2 Answers 2

You have a connection issue with your server. I see you're using DNS addresses in your backends. Varnish resolves DNS on startup and do not notice changes on runtime.

Did you change your FQDN target since Varnish has been started ?

Is your DNS targetting dynamic addresses ?

You should try using a static IP instead of a DNS name.

share|improve this answer
    
I will look into this! –  dabito Sep 11 '12 at 16:35
up vote 0 down vote accepted

Turns out backend servers were taking a lot of time to process requests. I changed my architecture from un varnish load balancer to one on each server and a load balancer.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.