Problem Upgrade to Varnish 4.1 - Multiple Backends Not Working
Drew, AJ
Drew.AJ at principal.com
Fri Sep 23 15:20:46 CEST 2016
Sorry for not being for specific.
The initial backend being set is the one that is always used no matter what the URL.
So, when I come in with a URL of /syscheck/blah.htm, I would expect the alternative backend to be used. It does not get select, and instead the original one is the one used, and therefore I end up with either a HTTP 404 or a HTTP 503, depending on the mood of Drupal the destination of the initial backend.
Thanks!
A J Drew
Here is some output from varnishlog of a call:
2 Begin c req 1 rxreq
2 Timestamp c Start: 1474629889.600227 0.000000 0.000000
2 Timestamp c Req: 1474629889.600227 0.000000 0.000000
2 ReqStart c 127.0.0.1 34608
2 ReqMethod c GET
2 ReqURL c /syscheck/wwwul2370.htm
2 ReqProtocol c HTTP/1.1
2 ReqHeader c Host: xxxxxx.example.com
2 ReqHeader c Accept: text/html, application/xhtml+xml, */*
2 ReqHeader c Accept-Language: en-US
2 ReqHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
2 ReqHeader c Accept-Encoding: gzip, deflate
2 ReqHeader c Cookie: ObSSOCookie=loggedout; TLTSID=A5D86DBA4DA97DFA943BD59DA9EFF5B8; dtCookie=3A7E953F591088FA2F6DB23E157B3A54|Q1NTX19FQV9fYXV0aG9yaXphdGlvbi1oYW5kbGVyLWVhcnwxfENTU19fRUFfX2FjY291bnQtYWdncmVnYXRpb24tZWFyfDE; dtLatC=36971; dtPC=-; RANDOM_ID=6529725af06
2 ReqHeader c Via: 1.1 xxxxxx.example.com
2 ReqHeader c X-Forwarded-For: 172.22.159.116
2 ReqHeader c X-Forwarded-Host: xxxxxx.example.com
2 ReqHeader c X-Forwarded-Server: xxxxxx.example.com
2 ReqHeader c Connection: Keep-Alive
2 ReqUnset c X-Forwarded-For: 172.22.159.116
2 ReqHeader c X-Forwarded-For: 172.22.159.116, 127.0.0.1
2 VCL_call c RECV
2 VCL_return c pass
2 VCL_call c HASH
2 VCL_return c lookup
2 VCL_call c PASS
2 VCL_return c fetch
2 Link c bereq 3 pass
2 Timestamp c Fetch: 1474629891.152683 1.552456 1.552456
2 RespProtocol c HTTP/1.1
2 RespStatus c 404
2 RespReason c Not Found
2 RespHeader c Date: Fri, 23 Sep 2016 11:24:49 GMT
2 RespHeader c Server: Apache
2 RespHeader c X-Drupal-Cache: MISS
2 RespHeader c Expires: Sun, 19 Nov 1978 05:00:00 GMT
2 RespHeader c Cache-Control: public, max-age=3600
2 RespHeader c Content-Language: en
2 RespHeader c X-Generator: Drupal 7 (http://drupal.org)
2 RespHeader c Etag: "1474629889-0"
2 RespHeader c Last-Modified: Fri, 23 Sep 2016 11:24:49 GMT
2 RespHeader c Vary: Cookie,Accept-Encoding
2 RespHeader c Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
2 RespHeader c X-XSS-Protection: 1;
2 RespHeader c Content-Type: text/html; charset=utf-8
2 RespHeader c X-Varnish: 2
2 RespHeader c Age: 0
2 RespHeader c Via: 1.1 varnish-v4
2 VCL_call c DELIVER
2 RespHeader c X-Cache: MISS
2 RespUnset c Via: 1.1 varnish-v4
2 RespUnset c X-Generator: Drupal 7 (http://drupal.org)
2 RespUnset c Server: Apache
2 VCL_return c deliver
2 Timestamp c Process: 1474629891.152737 1.552510 0.000054
2 RespHeader c Content-Length: 7685
2 Debug c "RES_MODE 2"
2 RespHeader c Connection: keep-alive
2 Timestamp c Resp: 1474629891.152783 1.552556 0.000046
2 ReqAcct c 791 0 791 500 7685 8185
2 End c
From: Guillaume Quintard [mailto:guillaume at varnish-software.com]
Sent: Friday, September 23, 2016 8:12 AM
To: Drew, AJ
Cc: varnish-misc at varnish-cache.org
Subject: Re: Problem Upgrade to Varnish 4.1 - Multiple Backends Not Working
What does "stop working" mean? Does the vcl fail to compile? do you receive 503s? does it open a portal to an ancient dimension filled with unspoken nightmares? Help us help you.
--
Guillaume Quintard
On Fri, Sep 23, 2016 at 1:52 PM, Drew, AJ <Drew.AJ at principal.com<mailto:Drew.AJ at principal.com>> wrote:
Hello,
We are trying to upgrade to Varnish 4.1 from Varnish 3.0.5.
Most things are working fine, but a big problem we are running into is that we have multiple backends. We switch backends based on URLs. This was working fine in Varnish 3, but when we switched over to Varnish 4, it stopped working.
I have tried many variations of the URLs, and even simplified the directors so that they only contain one backend (in my tests) so that I could switch from trying the backend directly to trying the director.
Using either of the options does not seem to matter.
Has anyone else run into this problem?
Here are the sections of my VCL that contain the backends / director definitions and the if statements to switch. I have also left in the different options (lines) I have used to come up with different combinations for testing.
probe B_probe {
.request =
"GET /zzzzzz/status.php HTTP/1.1"
"HOST: xxxxxx.example.com<http://xxxxxx.example.com>"
"Connection: close";
.timeout = 0.3 s;
.window = 8;
.threshold = 7;
}
backend B_backend1 {
.host = "162.131.196.220";
.port = "8080";
.probe = B_probe;
}
backend syscheck {
# .host = "localhost";
.host = "127.0.0.1";
.port = "8081";
}
backend searchBackend {
.host = "rp.www.example.com<http://rp.www.example.com>";
.port = "80";
}
backend providerBackend {
.host = "172.23.82.28";
.port = "80";
}
sub vcl_init {
new examplehosts = directors.round_robin();
examplehosts.add_backend(B_backend1);
new examplesyscheck = directors.round_robin();
examplesyscheck.add_backend(syscheck);
}
sub vcl_recv {
# set req.backend_hint = examplehosts.backend();
set req.backend_hint = B_backend1;
if (req.url ~ "^/syscheck/.*$") {
# if (req.url ~ "^/syscheck/*") {
# if (req.url ~ "^/syscheck/") {
set req.backend_hint = syscheck;
# set req.backend_hint = examplesyscheck.backend();
return(pass);
}
# Add simple health check for upstream load balancers
if (req.url ~ "^/health-check") {
return( synth(200, "UP"));
}
...
Thanks!
A J Drew
-----Message Disclaimer-----
This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to Connect at principal.com<mailto:Connect at principal.com> and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act ("E-Sign") unless a specific statement to the contrary is included in this message.
If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.
_______________________________________________
varnish-misc mailing list
varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20160923/aabb3edf/attachment-0001.html>
More information about the varnish-misc
mailing list