Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
2010/1/15 Rob S > John Norman wrote: > > Folks, > > > > A couple more questions: > > > > (1) Are they any good strategies for splitting load across Varnish > > front-ends? Or is the common practice to have just one Varnish server? > > > > (2) How do people avoid single-point-of-failure for Varnish? Do people > > run Varnish on two servers, amassing similar local caches, but put > > something in front of the two Varnishes? Or round-robin-DNS? > > > We're running with two instances and round-robin DNS. The varnish > servers are massively underused, and splitting the traffic also means we > get half the hit rate. But it avoids the SPOF. > > Is anyone running LVS or similar in front of Varnish and can share their > experience? > We run two varnish servers behind a netscaler load balancer to eliminate SPOF. Works fine, as the previous poster mentions you lower your hit rate - but not as much as I expected. As far as load is concerned, we could easily use just one server and it would probably still be 99% idle. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <8c3f8d23-3e20-4e2c-ba7c-902d843ff...@dynamine.net>, "Michael S. Fis cher" writes: >On Jan 18, 2010, at 1:52 PM, Poul-Henning Kamp wrote: >Can you describe in more detail your comparative analysis and plans? =20 First of all, the major player in this are the 'stevedores' like "malloc", "file" and "persistent". I'm trying to apply what I have learned so far to the persistent stevedore and it has much more VM-hintable behaviour than the "file" stevedore, and hopefully a much more disk-scheduling friendly (ie: sequential) layout policy. In particular, I'm trying to make the "persistent" stevedore as "cheap-SSD" friendly as possible, by optmising for sequential writes where at all possile. Exactly how much help this will be, depends on everything in your world, including what your kernel does for madvise(), and if you have a usable sendfile() syscall, and therefore giving any specific promises is pretty impossible for me. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Jan 18, 2010, at 1:52 PM, Poul-Henning Kamp wrote: > In message , "Michael S. > Fis > cher" writes: > >> What VM can overcome page-thrashing incurred by constantly referencing a >> working set that is significantly larger than RAM? > > No VM can "overcome" the task at hand, but some work a lot better than > others. > > Varnish has a significant responsibility, not yet fully met, to tell > the VM system as much about what is going on as possible. Can you describe in more detail your comparative analysis and plans? Thanks, --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , "Michael S. Fis cher" writes: >What VM can overcome page-thrashing incurred by constantly referencing a >working set that is significantly larger than RAM? No VM can "overcome" the task at hand, but some work a lot better than others. Varnish has a significant responsibility, not yet fully met, to tell the VM system as much about what is going on as possible. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Jan 18, 2010, at 1:05 PM, Poul-Henning Kamp wrote: > In message <43a238d7-433d-4000-8aa5-6c574882d...@dynamine.net>, "Michael S. > Fis > cher" writes: > >> I should have been more clear. If you overcommit and use disk you >> will die. Even SSD is a problem as the write latencies are high. > > That is still very much dependent on the quality of the VM subsystem > in your OS kernel. What VM can overcome page-thrashing incurred by constantly referencing a working set that is significantly larger than RAM? --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <43a238d7-433d-4000-8aa5-6c574882d...@dynamine.net>, "Michael S. Fis cher" writes: >I should have been more clear. If you overcommit and use disk you >will die. Even SSD is a problem as the write latencies are high. That is still very much dependent on the quality of the VM subsystem in your OS kernel. And I will admit that most kernels can be curdled with a solid varnish-load, but hopefully this will improve over time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <14b75f07-969a-43d1-8cc9-9605a2642...@slide.com>, Ken Brownfield wri tes: >> If you receive more than 100 requests/sec per Varnish instance and you >use a disk cache, you will die. > >I was surprised by this, what appears to be grossly irresponsible >guidance, given how large the installed base is that does thousands per >second quite happily. Just for the record: I didn't comment onthat one, since I sort of assumed that everybody could see that a blanket statement like that could never be universally true. Obviously, if your 100 requests are for DVD images, you have tough row to hoe when it comes to designing a disk subsystem, but for more reasonable loads, the above is patently wrong. And yes, if your're worried about diskperformance SSD is the way to go. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Jan 18, 2010, at 12:31 PM, Ken Brownfield wrote: On Jan 16, 2010, at 7:32 AM, Michael Fischer wrote: On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne wrote: Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB memory and the backends have a much easier life than before Varnish. We are about to upgrade RAM on the Varnish boxes, and eventually we can switch to disk cache if needed. If you receive more than 100 requests/sec per Varnish instance and you use a disk cache, you will die. I was surprised by this, what appears to be grossly irresponsible guidance, given how large the installed base is that does thousands per second quite happily. Perhaps there's missing background for this statement? Do you mean swap instead of Varnish file/mmap? Disk could just as easily mean SSD these days. Even years ago on Squid and crappy EIDE drives you could manage 1-2,000 requests per second I should have been more clear. If you overcommit and use disk you will die. Even SSD is a problem as the write latencies are high. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Jan 16, 2010, at 7:32 AM, Michael Fischer wrote: > On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne wrote: > > Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB > memory and the backends have a much easier life than before Varnish. > We are about to upgrade RAM on the Varnish boxes, and eventually we > can switch to disk cache if needed. > > If you receive more than 100 requests/sec per Varnish instance and you use a > disk cache, you will die. I was surprised by this, what appears to be grossly irresponsible guidance, given how large the installed base is that does thousands per second quite happily. Perhaps there's missing background for this statement? Do you mean swap instead of Varnish file/mmap? Disk could just as easily mean SSD these days. Even years ago on Squid and crappy EIDE drives you could manage 1-2,000 requests per second. -- Ken ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
]] Ken Brownfield | 3) Hash/bucket URLs to cache pairs. | | Same as 2), but for every hash bucket you would send those hits to two | machines (think RAID-10). This provides redundancy from the effects | of 2a), and gives essentially infinite scalability for the price of | doubling your miss rate once (two machines per bucket caching the same | data). The caveat from 2b) still applies. I've pondered having a semi-stable hash algorithm which would hash to one host, say, 90% of the time and another 10% of the time. This would allow you much more flexible scalability here as you would not need twice the number of servers, only the number you need to have redundant. And you could tune the extra cache miss rate versus how much redundancy you need. I don't know of any products having this out of the box. I am fairly sure you could do it on F5s using iRules, and I would not be surprised if HAProxy or nginx can either do it or be taught how to do this. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Hey, folks, I just want to thank for this great thread -- I think it would be well worth breaking it up into Q/A for the FAQ. We're still a bit undecided as to how we're going to configure our systems, but we feel like we have options now. On Sun, Jan 17, 2010 at 4:10 PM, Ross Brown wrote: > I hadn't used varnishadm before. Looks useful. > > Thanks! > > -Original Message- > From: p...@critter.freebsd.dk [mailto:p...@critter.freebsd.dk] On Behalf Of > Poul-Henning Kamp > Sent: Monday, 18 January 2010 9:38 a.m. > To: Ross Brown > Cc: varnish-misc@projects.linpro.no > Subject: Re: Strategies for splitting load across varnish instances? And > avoiding single-point-of-failure? > > In message <1ff67d7369ed1a45832180c7c1109bca13e23e7...@tmmail0.trademe.local>, > Ross Brown writes: >>> So it is possible to start your Varnish with one VCL program, and have >>> a small script change to another one some minutes later. >> >>What would this small script look like?=20 > > sleep 600 > varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" > varnishadm vcl.use real_thing > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
RE: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
I hadn't used varnishadm before. Looks useful. Thanks! -Original Message- From: p...@critter.freebsd.dk [mailto:p...@critter.freebsd.dk] On Behalf Of Poul-Henning Kamp Sent: Monday, 18 January 2010 9:38 a.m. To: Ross Brown Cc: varnish-misc@projects.linpro.no Subject: Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In message <1ff67d7369ed1a45832180c7c1109bca13e23e7...@tmmail0.trademe.local>, Ross Brown writes: >> So it is possible to start your Varnish with one VCL program, and have >> a small script change to another one some minutes later. > >What would this small script look like?=20 sleep 600 varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" varnishadm vcl.use real_thing -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <1ff67d7369ed1a45832180c7c1109bca13e23e7...@tmmail0.trademe.local>, Ross Brown writes: >> So it is possible to start your Varnish with one VCL program, and have >> a small script change to another one some minutes later. > >What would this small script look like?=20 sleep 600 varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" varnishadm vcl.use real_thing -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
RE: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
> So it is possible to start your Varnish with one VCL program, and have > a small script change to another one some minutes later. What would this small script look like? Sorry if it's a dumb question :) ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <4c3149fb1001161400n38a1ef1al18985bc3ad1ad...@mail.gmail.com>, pub c rawler writes: >Just trying to figure out the implications of this because in our >environment we regularly find ourselves pulling servers offline. >Wondering if the return of a Varnish would operate like a cold-cache >miss or what magic in Varnish deals with the change in hashing per se. There is no built-in magic for that[1]. One of the really powerful things Varnish can do, is chance VCL code on-the-fly, instantly. So it is possible to start your Varnish with one VCL program, and have a small script change to another one some minutes later. You can use that, to start with a VCL where it only uses its neighbors as backends, and then some minutes later when the cache has the most common objects loaded, switch to another VCL that goes directly to the backend. If you want to get fancy, you can use VCL restarts, to ask the neighbors and if they don't have it, go directly to the backend on restart. Poul-Henning [1] In general Varnish has no built in magic, all the magic is your responsibility to write in the VCL code :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Thanks again Poul for all you do. How does Varnish handle the hashing and locating of data where a backend returns to the pool? Wouldn't the hashing be wrong for prior loaded items since a machine has returned and the pool widens? Just trying to figure out the implications of this because in our environment we regularly find ourselves pulling servers offline. Wondering if the return of a Varnish would operate like a cold-cache miss or what magic in Varnish deals with the change in hashing per se. > It's probably simplest to paraphrase the code: > > Calculate hash over full complement of backends. > Is the selected backend sick > Calculate hash over subset of healthy backends > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 1:37 PM, Poul-Henning Kamp wrote: >Are you saying that the default hash is not a mod-n-type algorithm? > > Well, it is mod-n, with the footnote that n has nothing to do with > the number of backends, because these have a configurable weight. > > >If not, what happens when the failed backend is restored to service? > > It's probably simplest to paraphrase the code: > >Calculate hash over full complement of backends. >Is the selected backend sick >Calculate hash over subset of healthy backends Ah, ok. That should behave reasonably in the event of a backend failure if you're implementing Varnish tiers. Thanks for the clarification. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , Micha el Fischer writes: >> In message , >> David >> Birdsong writes: >> >> >Right, but those 2 remaining are at least still being asked for the >> >same url's they were prior to the 1 dying. >> >> Correct, the hashing is "canonical" in the sense that if the >> configured backend is up, all traffic for "its" objects will be >> sent to it. > >Are you saying that the default hash is not a mod-n-type algorithm? Well, it is mod-n, with the footnote that n has nothing to do with the number of backends, because these have a configurable weight. >If not, what happens when the failed backend is restored to service? It's probably simplest to paraphrase the code: Calculate hash over full complement of backends. Is the selected backend sick Calculate hash over subset of healthy backends -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 1:19 PM, Poul-Henning Kamp wrote: > In message , > David > Birdsong writes: > > >Right, but those 2 remaining are at least still being asked for the > >same url's they were prior to the 1 dying. > > Correct, the hashing is "canonical" in the sense that if the > configured backend is up, all traffic for "its" objects will be > sent to it. Are you saying that the default hash is not a mod-n-type algorithm? If not, what happens when the failed backend is restored to service? --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , David Birdsong writes: >Right, but those 2 remaining are at least still being asked for the >same url's they were prior to the 1 dying. Correct, the hashing is "canonical" in the sense that if the configured backend is up, all traffic for "its" objects will be sent to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 10:44 AM, Poul-Henning Kamp wrote: > In message , > Micha > el Fischer writes: > >>For instance sizes larger than 2, I think a consistent hash is needed. >> Otherwise, the overall hit ratio will fall dramatically upon failure of an >>instance as the requests are rerouted. > > If you have perfect 1/3 splitting between 3 varnishes, having one die > will do bad things to your hitrate until the remaining two distribute > the load between them. > > That's a matter of math, and has nothing to do with the hash algorithm. Right, but those 2 remaining are at least still being asked for the same url's they were prior to the 1 dying. They're just now responsible for the dead varnish's urls in addition to their own working set. This is much better than the entire url space being hashed against 2 buckets. ...or is my understanding of consistent hashing flawed? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 10:44 AM, Poul-Henning Kamp wrote: > In message , > Micha > el Fischer writes: > > >For instance sizes larger than 2, I think a consistent hash is needed. > > Otherwise, the overall hit ratio will fall dramatically upon failure of > an > >instance as the requests are rerouted. > > If you have perfect 1/3 splitting between 3 varnishes, having one die > will do bad things to your hitrate until the remaining two distribute > the load between them. > > That's a matter of math, and has nothing to do with the hash algorithm. Let me put it this way and leave the math up to you: it will be way worse if you don't use a consistent hash. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , Micha el Fischer writes: >For instance sizes larger than 2, I think a consistent hash is needed. > Otherwise, the overall hit ratio will fall dramatically upon failure of an >instance as the requests are rerouted. If you have perfect 1/3 splitting between 3 varnishes, having one die will do bad things to your hitrate until the remaining two distribute the load between them. That's a matter of math, and has nothing to do with the hash algorithm. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 9:22 AM, Poul-Henning Kamp wrote:
> In message ,
> Micha
> el Fischer writes:
>
> >On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp >wrote:
> >
> >>director h1 hash {
> >>{ .backend webserver; .weight 1; }
> >>{ .backend varnish2; .weight 1; }
> >>{ .backend varnish3; .weight 1; }
> >
> >
> >What happens when varnish2 or varnish3 dies?
>
> If a particular backend in the director is unhealthy, the requests
> for it will be redistributed by rehashing over the healthy subset
> of directors. Once it becomes healthy, normality will be restored.
>
> So everything should work out fine, for some value around 99.9% of fine.
For instance sizes larger than 2, I think a consistent hash is needed.
Otherwise, the overall hit ratio will fall dramatically upon failure of an
instance as the requests are rerouted.
--Michael
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , Micha
el Fischer writes:
>On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp wrote:
>
>>director h1 hash {
>>{ .backend webserver; .weight 1; }
>>{ .backend varnish2; .weight 1; }
>>{ .backend varnish3; .weight 1; }
>
>
>What happens when varnish2 or varnish3 dies?
If a particular backend in the director is unhealthy, the requests
for it will be redistributed by rehashing over the healthy subset
of directors. Once it becomes healthy, normality will be restored.
So everything should work out fine, for some value around 99.9% of fine.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <4c3149fb1001160738l2233481dn82c34c2ba1fcc...@mail.gmail.com>, pub c rawler writes: >Poul, is anyone running the hash director distribution method like >you provided (in production)? No idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp wrote:
>director h1 hash {
>{ .backend webserver; .weight 1; }
>{ .backend varnish2; .weight 1; }
>{ .backend varnish3; .weight 1; }
What happens when varnish2 or varnish3 dies?
--Michael
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Poul, is anyone running the hash director distribution method like
you provided (in production)?
What sort of throughput and what sort of use limitations has anyone
experienced with this?
This is quite exciting - and seems like a fairly good solution to
scale/cluster Varnish.
-Paul
> You can do some clever stuff with the hash director to distribute the
> content over a cluster of varnishes:
>
> varnish1 has:
>
> backend webserver {...}
> backend varnish2 {...}
> backend varnish3 {...}
>
> acl partner {
> "varnish1 ip"
> "varnish2 ip"
> "varnish3 ip"
> }
>
> director h1 hash {
> { .backend webserver; .weight 1; }
> { .backend varnish2; .weight 1; }
> { .backend varnish3; .weight 1; }
> }
>
> sub vcl_fetch {
> if (beresp.http.x-partner == "yes") {
> set beresp.ttl = 0s;
> unset beresp.http.x-partner;
> }
> }
>
> sub vcl_deliver {
> if (client.ip ~ partner) {
> set resp.http.x-partner = yes;
> }
> }
>
> On varnish2 you change the "h1" director to read:
>
> director h1 hash {
> { .backend varnish1; .weight 1; }
> { .backend webserver; .weight 1; }
> { .backend varnish3; .weight 1; }
> }
>
> On varnish3:
>
> director h1 hash {
> { .backend varnish1; .weight 1; }
> { .backend varnish2; .weight 1; }
> { .backend webserver; .weight 1; }
> }
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne wrote: > I must say that i am a bit confused. > I don't understand the need of routing requests to different varnish > servers based on hash algorithm. So I am wondering what kind of sites > are we talking about? > We're talking about sites that have a hot working set much larger than the amount of RAM you can fit in a single Varnish instance (i.e., 32-64GB). Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB > memory and the backends have a much easier life than before Varnish. > We are about to upgrade RAM on the Varnish boxes, and eventually we > can switch to disk cache if needed. If you receive more than 100 requests/sec per Varnish instance and you use a disk cache, you will die. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message <4c3149fb1001151733g73f7a5dfjc84342b9df7f0...@mail.gmail.com>, pub c
rawler writes:
>Varnish performs very well. Extending this to have a cluster
>functionality within Varnish I think just makes sense.
You can do some clever stuff with the hash director to distribute the
content over a cluster of varnishes:
varnish1 has:
backend webserver {...}
backend varnish2 {...}
backend varnish3 {...}
acl partner {
"varnish1 ip"
"varnish2 ip"
"varnish3 ip"
}
director h1 hash {
{ .backend webserver; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend varnish3; .weight 1; }
}
sub vcl_fetch {
if (beresp.http.x-partner == "yes") {
set beresp.ttl = 0s;
unset beresp.http.x-partner;
}
}
sub vcl_deliver {
if (client.ip ~ partner) {
set resp.http.x-partner = yes;
}
}
On varnish2 you change the "h1" director to read:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend webserver; .weight 1; }
{ .backend varnish3; .weight 1; }
}
On varnish3:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend webserver; .weight 1; }
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
> I'm all for putting backend hashing into Varnish for the purpose of routing > requests to backends based on a consistent hash of the request parameters -- > and there's no reason why the backend can't be another Varnish instance. > But the appropriate use of this is to more efficiently utilize cache memory > by associating an object with a designated Varnish server in a pool, not for > HA. This was one of my first requests that still (alas) has seen no > traction. I must say that i am a bit confused. I don't understand the need of routing requests to different varnish servers based on hash algorithm. So I am wondering what kind of sites are we talking about? If we talk about huge sites with a lot of traffic I find it strange that hardware costs are so problematic. The most common scenarios is that you want load-balancing and/or redundancy. Routing request to different servers will cause you to loose redundancy unless you add extra servers wich again will cost more than upgrade disk or RAM. If you have shared cache you will also loose redundancy unless you compansate on some ways. If you have a small site you could easily get both redundancy and loadbalancing by running HAProxy and Varnish on 2 or 3 servers with failover using Hearbeat or something else (I must admit that i am not familier with HAProxy, so it may support failover out of the box). Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB memory and the backends have a much easier life than before Varnish. We are about to upgrade RAM on the Varnish boxes, and eventually we can switch to disk cache if needed. Since we run a news/media site we know that a few pages gets most of the traffic so refilling the cache on restarts is not a problem. In my opinion refilling the cache should be a problem whatever type of site you are running, but hey, I could be wrong. Varnish should nevertheless not be an excuse for writing slow/poor applications making rebuilding slow or application server crash. Am I missing something here? - Bendik ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message , Ken Brownfield wri tes: It is important to be absolutely clear about what your objective is here, availability, cache-hit-ratio or raw performance, the best solution will depend on what you are after. For a lot of purposes, you will get a lot of mileage out of a number of parallel Varnish machines with DNS round-robin, for all practical purposes, a zero-cost solution. In the other end, you have a load-balancer in front of your varnishes, which gives you all sorts of neat features at a pretty steep cost. The spectrum between is filled with things like pound, haproxy and other open-source solution, which may, or may not, run on their own hardware. There is no "perfect fit for all" solutions in this space, you will need to make your own choice. >Squid has a peering feature; [...] Squids peering feature was created for hit-rate only, the working scenario is two squids each behind a very slow line to the internet, asking each other before they pull down a file. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 5:33 PM, pub crawler wrote: Varnish performs very well. Extending this to have a cluster > functionality within Varnish I think just makes sense. haproxy and F5 equipment also both perform very well. > The workaround > solutions so far seem to involve quite a bit of hardware as well as > having a miss rate of 50% in example of 2 Varnish instances. Sure it > can hot populate fast, but it's two stacks of memory wasted for the > same data per se. If you hash your requests from a load balancer across a pool of n varnish instances, the most you lose in the event of a failure is 1/n. You don't cache objects in more than one instance. There's no "wasted" memory. I suppose a custom solution to hash the inbound > requests somehow and determine which Varnish should have the data can > be done, but unsure if anyone now is doing that. > That's precisely what L7 switches do. As David said, haproxy has this functionality, as do other implementations. > Squid is a total disaster. If it wasn't none of us would be here > using Varnish now would we :) It's amazing Squid even works at this > point. > Can you quantify this statement? Squid works very well at some installations. It's not like the code that was out there working spontaneously started to become buggier. > I put in a feature request this evening for this functionality. We'll > see what the official development folks think. If it can't be > included in the core, then perhaps a front-end Varnish proxy is in > order developmentally. I'll say this akin to Moxi in front of > memcached instances: http://labs.northscale.com/moxi/ I'm all for putting backend hashing into Varnish for the purpose of routing requests to backends based on a consistent hash of the request parameters -- and there's no reason why the backend can't be another Varnish instance. But the appropriate use of this is to more efficiently utilize cache memory by associating an object with a designated Varnish server in a pool, not for HA. This was one of my first requests that still (alas) has seen no traction. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 6:14 PM, Michael Fischer wrote: I'm all for putting backend hashing into Varnish for the purpose of routing > requests to backends based on a consistent hash of the request parameters -- > and there's no reason why the backend can't be another Varnish instance. > But the appropriate use of this is to more efficiently utilize cache memory > by associating an object with a designated Varnish server in a pool, not for > HA. This was one of my first requests that still (alas) has seen no > traction. > Although now that haproxy does it, my request may now be moot. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 5:33 PM, pub crawler wrote:
>> At first glance, this is doing something that you can more cheaply and
>> efficiently do at a higher level, with >software dedicated to that purpose.
>> It's interesting, but I'm not sure it's more than just a restatement of the
>> >same solution with it's own problems.
>
> Varnish performs very well. Extending this to have a cluster
> functionality within Varnish I think just makes sense. The workaround
> solutions so far seem to involve quite a bit of hardware as well as
> having a miss rate of 50% in example of 2 Varnish instances. Sure it
> can hot populate fast, but it's two stacks of memory wasted for the
> same data per se. I suppose a custom solution to hash the inbound
> requests somehow and determine which Varnish should have the data can
> be done, but unsure if anyone now is doing that.
>
I'm doing it on a decent scale. This makes the most sense. Let a
load balancer load balance and a cache server cache.
>> F5/NetScaler is quite expensive, but they have significant functionality,
>> too.
>>
>> The hardware required to run LVS/haproxy (for example) can be very cheap --
>> Small RAM, 1-2 CPU cores > per ethernet interface. When you're already
>> talking about scaling out to lots of big-RAM/disk Varnish
>> boxes, the cost of a second load balancer is tiny, and the benefit of
>> redundancy is huge.
>
> F5 has always made good gear. The price point limits adoption to deep
> pockets. I am not convinced that most people need a hardware
> balancing solution. They have their limited adoption, and the N+1
> purchase amounts - 2 minimum, 3 more optimally = $$.
>
>> Squid has a peering feature; I think if you had ever tried it you would know
>> why it's not a fabulous idea. :) > It scales terribly. Also, Memcache
>> pooling that I've seen scale involves logic in the app (a higher level).
>
> Squid is a total disaster. If it wasn't none of us would be here
> using Varnish now would we :) It's amazing Squid even works at this
> point.
>
> The memcached pooling is a simple formula really - it's microsecond
> fast - yes typically done on the client:
> Most standard client hashing within memcache clients uses a simple
> modulus calculation on the value against the number of configured
> memcached servers. You can summarize the process in pseudocode as:
>
> @memcservers = ['a.memc','b.memc','c.memc'];
> $value = hash($key);
> $chosen = $value % length(@memcservers);
> Replacing the above with values:
>
> @memcservers = ['a.memc','b.memc','c.memc'];
> $value = hash('myid');
> $chosen = 7009 % 3;
> In the above example, the client hashing algorithm will choose the
> server at index 1 (7009 % 3 = 1), and store or retrieve the key and
> value with that server.
yes and from my experience, each client api has a different hashing
implementation. you set a key on a pool of servers in php and you
cannot retrieve the value for that key python. if you set a key in
python, you can't retrieve it in the nginx module(it follows php
iirc.)
>
>> Varnish as a pool/cluster also doesn't provide redundancy to the client
>> interface.
why should it? it's pretty busy dealing with memory management and io
heavy threaded craziness.
in it's current form, it doesn't care from where the request is coming
from and it shouldn't. it should try to reach into it's cache or
fetch from a backend.
>>
>> A distributed Varnish cache (or perhaps a memcache storage option in
>> Varnish?) is really interesting; it might be scalable, but not obviously.
>> It also doesn't eliminate the need for a higher-level balancer.
>>
>
> Well, in this instance, Varnish can do the modulus math versus the not
> Varnish servers in config pool. Wouldn't take any sort of time and the
> logic already seems to exist in the VCL config to work around when a
> backend server can be reached. Same logic could be adapted to the
> "front side" to try connecting to other Varnish instances and doing
> the failover dance as needed.
>
i love that it doesn't do this. i can debug haproxy separately, i can
debug varnish sepately, i can debug nginx separately. they're all
great tools.
> I put in a feature request this evening for this functionality. We'll
> see what the official development folks think. If it can't be
> included in the core, then perhaps a front-end Varnish proxy is in
> order developmentally. I'll say this akin to Moxi in front of
> memcached instances: http://labs.northscale.com/moxi/
i vote for big no on this request.
if this theoretical varnish performed a hash of a url and determined
that it should fetch from a remote *peer* varnish and not from it's
own cache file(or backend for that matter), then it would presumably
fetch from a different machine, while a different uri would hash to
the local cache and fetch from itself. so you'd have traffic going in
and out of varnish ports talking to each other before you've even done
a backend fetch.
the logic of all this
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
> At first glance, this is doing something that you can more cheaply and
> efficiently do at a higher level, with >software dedicated to that purpose.
> It's interesting, but I'm not sure it's more than just a restatement of the
> >same solution with it's own problems.
Varnish performs very well. Extending this to have a cluster
functionality within Varnish I think just makes sense. The workaround
solutions so far seem to involve quite a bit of hardware as well as
having a miss rate of 50% in example of 2 Varnish instances. Sure it
can hot populate fast, but it's two stacks of memory wasted for the
same data per se. I suppose a custom solution to hash the inbound
requests somehow and determine which Varnish should have the data can
be done, but unsure if anyone now is doing that.
> F5/NetScaler is quite expensive, but they have significant functionality, too.
>
> The hardware required to run LVS/haproxy (for example) can be very cheap --
> Small RAM, 1-2 CPU cores > per ethernet interface. When you're already
> talking about scaling out to lots of big-RAM/disk Varnish
> boxes, the cost of a second load balancer is tiny, and the benefit of
> redundancy is huge.
F5 has always made good gear. The price point limits adoption to deep
pockets. I am not convinced that most people need a hardware
balancing solution. They have their limited adoption, and the N+1
purchase amounts - 2 minimum, 3 more optimally = $$.
> Squid has a peering feature; I think if you had ever tried it you would know
> why it's not a fabulous idea. :) > It scales terribly. Also, Memcache
> pooling that I've seen scale involves logic in the app (a higher level).
Squid is a total disaster. If it wasn't none of us would be here
using Varnish now would we :) It's amazing Squid even works at this
point.
The memcached pooling is a simple formula really - it's microsecond
fast - yes typically done on the client:
Most standard client hashing within memcache clients uses a simple
modulus calculation on the value against the number of configured
memcached servers. You can summarize the process in pseudocode as:
@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash($key);
$chosen = $value % length(@memcservers);
Replacing the above with values:
@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash('myid');
$chosen = 7009 % 3;
In the above example, the client hashing algorithm will choose the
server at index 1 (7009 % 3 = 1), and store or retrieve the key and
value with that server.
> Varnish as a pool/cluster also doesn't provide redundancy to the client
> interface.
>
> A distributed Varnish cache (or perhaps a memcache storage option in
> Varnish?) is really interesting; it might be scalable, but not obviously. It
> also doesn't eliminate the need for a higher-level balancer.
>
Well, in this instance, Varnish can do the modulus math versus the not
Varnish servers in config pool. Wouldn't take any sort of time and the
logic already seems to exist in the VCL config to work around when a
backend server can be reached. Same logic could be adapted to the
"front side" to try connecting to other Varnish instances and doing
the failover dance as needed.
I put in a feature request this evening for this functionality. We'll
see what the official development folks think. If it can't be
included in the core, then perhaps a front-end Varnish proxy is in
order developmentally. I'll say this akin to Moxi in front of
memcached instances: http://labs.northscale.com/moxi/
I think tying Varnish into Memcached is fairly interesting as it
appears the market is allocating many resources towards memcached. At
some point I believe memcached will become at least an unofficial
standard for fast memory based storage. There a number of
manufacturers making custom higher performance memcached solutions -
Gear6 and Schooner come to mind foremost.
That's my $1 worth :)
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Jan 15, 2010, at 3:39 PM, pub crawler wrote: > Have we considered adding pooling functionality to Varnish much like > what they have in memcached? > > Run multiple Varnish(es) and load distributed amongst the identified > Varnish server pool So an element in Varnish gets hashed and the > hash identifies the server in the pool it's on. If the server isn't > there or the element isn't there cold lookup to the backend server > then we store it where it should be. > > Seems like an obvious feature - unsure of the performance implications though. At first glance, this is doing something that you can more cheaply and efficiently do at a higher level, with software dedicated to that purpose. It's interesting, but I'm not sure it's more than just a restatement of the same solution with it's own problems. > The recommendation of load balancers in front on Varnish to facilitate > this feature seems costly when talking about F5 gear. The open > source solutions require at least two severs dedicated to this load > balancing function for sanity sake (which is costly). F5/NetScaler is quite expensive, but they have significant functionality, too. The hardware required to run LVS/haproxy (for example) can be very cheap -- Small RAM, 1-2 CPU cores per ethernet interface. When you're already talking about scaling out to lots of big-RAM/disk Varnish boxes, the cost of a second load balancer is tiny, and the benefit of redundancy is huge. VMs don't solve the redundancy problem, and add significant overhead to network-intensive loads like high-traffic LVS or iptables configs. > Finally, Vanish > already offers load balancing (although limited) to the back end > servers - so lets do the same within Varnish to make sure Varnish > scales horizontally and doesn't require these other aids to be deemed > totally reliable. Squid has a peering feature; I think if you had ever tried it you would know why it's not a fabulous idea. :) It scales terribly. Also, Memcache pooling that I've seen scale involves logic in the app (a higher level). Varnish as a pool/cluster also doesn't provide redundancy to the client interface. A distributed Varnish cache (or perhaps a memcache storage option in Varnish?) is really interesting; it might be scalable, but not obviously. It also doesn't eliminate the need for a higher-level balancer. All just IMHO! -- Ken ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 3:39 PM, pub crawler wrote: > The recommendation of load balancers in front on Varnish to facilitate > this feature seems costly when talking about F5 gear. The open > source solutions require at least two severs dedicated to this load > balancing function for sanity sake (which is costly). You can use virtual machines for the front-end load balancers if you're concerned about cost. Alternatively, you can run the load balancers on the same hosts as the caches, provided the Varnish caches listen on different ports or different IP addresses than the load balancers. --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Have we considered adding pooling functionality to Varnish much like what they have in memcached? Run multiple Varnish(es) and load distributed amongst the identified Varnish server pool So an element in Varnish gets hashed and the hash identifies the server in the pool it's on. If the server isn't there or the element isn't there cold lookup to the backend server then we store it where it should be. Seems like an obvious feature - unsure of the performance implications though. The recommendation of load balancers in front on Varnish to facilitate this feature seems costly when talking about F5 gear. The open source solutions require at least two severs dedicated to this load balancing function for sanity sake (which is costly). Finally, Vanish already offers load balancing (although limited) to the back end servers - so lets do the same within Varnish to make sure Varnish scales horizontally and doesn't require these other aids to be deemed totally reliable. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
Lots of good suggestions; I would look to LVS and/or haproxy for going on the cheap; otherwise a NetScaler or F5 would do the trick. With multiple caches, there are three ways I see to handle it: 1) Duplicate cached data on all Varnish instances. This is a simple, stateless configuration, but it reduces your overall hit rate: 2 servers will halve your miss traffic; 3 servers will triple it, etc.. If your miss rate is low enough that your origin can handle the misses, this is simple, easy to implement, and offers good performance (CPU and link scalability). If you lose a host, you would see essentially no miss rate increase. But it won't scale forever. For servers with 8GB of RAM, the machines will only provide 8GB of RAM overall for caching, whether it's 4 machines or 400. (same applies to disk space) 2) Hash URLs or otherwise bucket incoming requests and send unique traffic to each Varnish instance. This requires some smarts in your load balancer, but this means you can add as many Varnish instances as you want without losing hit rate, and each server's RAM footprint is additive. 8 servers with 8GB of RAM will provide 64GB of RAM overall for caching. But there are caveats: 2a) If you lose a cache server, you will get a 100% miss rate for all objects that used to be directed to that server. This might overwhelm your origin. 2b) If you resize the cache server pool, the hash (or other algorithm) will send different objects to different machines, which will increase misses (possibly catastrophically) and may overwhelm your origin. Some implementations of URL hashing will cause a full rehashing of URLs if a single host even temporarily goes out of service. Additionally, some hash implementations may also reduce the effect of server loss. 3) Hash/bucket URLs to cache pairs. Same as 2), but for every hash bucket you would send those hits to two machines (think RAID-10). This provides redundancy from the effects of 2a), and gives essentially infinite scalability for the price of doubling your miss rate once (two machines per bucket caching the same data). The caveat from 2b) still applies. With the right hash/bucket algorithm, 3) is probably the best choice. But they all have drawbacks. I'd love to hear other ideas too. Hope it helps, -- kb John Norman wrote: > Folks, > > A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? > > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? > > John ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 1:19 PM, David Birdsong wrote: > On Fri, Jan 15, 2010 at 10:11 AM, Rodrigo Benzaquen > wrote: > > HA PROXY is open spurce and works pretty well. Also you can do load > balance > > based on HAS URL if you want. > > aye, the development is pretty active also. i asked for a consistent > hash option in haproxy and got one in less than 2 weeks -only > available in the dev version for now. Awesome! Now if we could just get one in Varnish :-) --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
On Fri, Jan 15, 2010 at 10:11 AM, Rodrigo Benzaquen wrote: > HA PROXY is open spurce and works pretty well. Also you can do load balance > based on HAS URL if you want. aye, the development is pretty active also. i asked for a consistent hash option in haproxy and got one in less than 2 weeks -only available in the dev version for now. > > > On Fri, Jan 15, 2010 at 3:09 PM, Bendik Heltne wrote: >> >> > A couple more questions: >> > >> > (1) Are they any good strategies for splitting load across Varnish >> > front-ends? Or is the common practice to have just one Varnish server? >> >> We have 3 servers. A bit overkill, but then we have redundancy even if >> one fail. I guess 2 is the minimum option if you have an important >> site and 99,5% uptime guarantee. >> >> > (2) How do people avoid single-point-of-failure for Varnish? Do people >> > run Varnish on two servers, amassing similar local caches, but put >> > something in front of the two Varnishes? Or round-robin-DNS? >> >> We use a loadbalancer from F5 called BigIP. It's no exactly free, but >> there are free alternatives that will probably do much of the basic >> stuff: >> http://lcic.org/load_balancing.html >> >> - Bendik >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
HA PROXY is open spurce and works pretty well. Also you can do load balance based on HAS URL if you want. On Fri, Jan 15, 2010 at 3:09 PM, Bendik Heltne wrote: > > A couple more questions: > > > > (1) Are they any good strategies for splitting load across Varnish > > front-ends? Or is the common practice to have just one Varnish server? > > We have 3 servers. A bit overkill, but then we have redundancy even if > one fail. I guess 2 is the minimum option if you have an important > site and 99,5% uptime guarantee. > > > (2) How do people avoid single-point-of-failure for Varnish? Do people > > run Varnish on two servers, amassing similar local caches, but put > > something in front of the two Varnishes? Or round-robin-DNS? > > We use a loadbalancer from F5 called BigIP. It's no exactly free, but > there are free alternatives that will probably do much of the basic > stuff: > http://lcic.org/load_balancing.html > > - Bendik > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
> A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? We have 3 servers. A bit overkill, but then we have redundancy even if one fail. I guess 2 is the minimum option if you have an important site and 99,5% uptime guarantee. > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? We use a loadbalancer from F5 called BigIP. It's no exactly free, but there are free alternatives that will probably do much of the basic stuff: http://lcic.org/load_balancing.html - Bendik ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
John Norman wrote: > Folks, > > A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? > > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? > We're running with two instances and round-robin DNS. The varnish servers are massively underused, and splitting the traffic also means we get half the hit rate. But it avoids the SPOF. Is anyone running LVS or similar in front of Varnish and can share their experience? Rob ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
