source-hash balancing...

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

source-hash balancing...

John Doe-3
Hi,

I was just wondering what happens when I use source-hashing balancing and the target server is down...
Will squid fallback to round-robin?

Thx,
JD


     

Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Henrik Nordström
On fre, 2008-08-29 at 06:22 -0700, John Doe wrote:
> Hi,
>
> I was just wondering what happens when I use source-hashing balancing and the target server is down...
> Will squid fallback to round-robin?

It then acts pretty much as if the cache_peer line of the failed peer
isn't there, until it starts responding again. The clients gets
sourche-hash distributed among the other peers.

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

John Doe-3
In reply to this post by John Doe-3
> > I was just wondering what happens when I use source-hashing balancing
> > and the target server is down...
> > Will squid fallback to round-robin?
>
> It then acts pretty much as if the cache_peer line of the failed peer
> isn't there, until it starts responding again. The clients gets
> sourche-hash distributed among the other peers.

Cool, thx.
Would the following work...?

 # u1 servers pool
 cache_peer 192.168.16.101 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
 cache_peer 192.168.16.102 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
 cache_peer 192.168.16.103 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
 
 # u2 servers pool
 cache_peer 192.168.16.201 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
 cache_peer 192.168.16.202 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
 cache_peer 192.168.16.203 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
 
 acl u1 url_regex ^http://u1
 acl u2 url_regex ^http://u2
 cache_peer_access u1pool allow u1
 cache_peer_access u1pool deny u2
 cache_peer_access u2pool allow u2
 cache_peer_access u2pool deny u1

Won't there be a problem with the redundant 'name=u?pool'

Thx,
JD


     

Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Malte Schröder
On Mon, 1 Sep 2008 07:34:37 -0700 (PDT)
John Doe <[hidden email]> wrote:
 

> Cool, thx.
> Would the following work...?
>
>  # u1 servers pool
>  cache_peer 192.168.16.101 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>  cache_peer 192.168.16.102 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>  cache_peer 192.168.16.103 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>  
>  # u2 servers pool
>  cache_peer 192.168.16.201 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
>  cache_peer 192.168.16.202 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
>  cache_peer 192.168.16.203 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u2pool
>  
>  acl u1 url_regex ^http://u1
>  acl u2 url_regex ^http://u2
>  cache_peer_access u1pool allow u1
>  cache_peer_access u1pool deny u2
>  cache_peer_access u2pool allow u2
>  cache_peer_access u2pool deny u1
>
> Won't there be a problem with the redundant 'name=u?pool'
I tried it once with squid 2.6. It did not work. But I would really
like it if that would actually work (i.e. grouping multiple peers
together so one doesn't need to create the same cache_peer_access-rules
for all peers).

Greets
Malte

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Jeff Peng-2
Malte Schröder 写道:

> On Mon, 1 Sep 2008 07:34:37 -0700 (PDT)
> John Doe <[hidden email]> wrote:
>  
>> Cool, thx.
>> Would the following work...?
>>
>>  # u1 servers pool
>>  cache_peer 192.168.16.101 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>  cache_peer 192.168.16.102 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>  cache_peer 192.168.16.103 parent 80 0 no-query originserver no-digest no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>  

each cache_peer must have the unique name, which is different from all
others.
Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Amos Jeffries
Administrator
In reply to this post by Malte Schröder
> On Mon, 1 Sep 2008 07:34:37 -0700 (PDT)
> John Doe <[hidden email]> wrote:
>
>> Cool, thx.
>> Would the following work...?
>>
>>  # u1 servers pool
>>  cache_peer 192.168.16.101 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>  cache_peer 192.168.16.102 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>  cache_peer 192.168.16.103 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u1pool
>>
>>  # u2 servers pool
>>  cache_peer 192.168.16.201 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u2pool
>>  cache_peer 192.168.16.202 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u2pool
>>  cache_peer 192.168.16.203 parent 80 0 no-query originserver no-digest
>> no-netdb-exchange max-conn=256 sourcehash name=u2pool
>>
>>  acl u1 url_regex ^http://u1
>>  acl u2 url_regex ^http://u2
>>  cache_peer_access u1pool allow u1
>>  cache_peer_access u1pool deny u2
>>  cache_peer_access u2pool allow u2
>>  cache_peer_access u2pool deny u1
>>
>> Won't there be a problem with the redundant 'name=u?pool'

Yes. The name= option is a UID for each peer. Also regex is very very
slow. dstdomain is better for those ACL.

>
> I tried it once with squid 2.6. It did not work. But I would really
> like it if that would actually work (i.e. grouping multiple peers
> together so one doesn't need to create the same cache_peer_access-rules
> for all peers).

Good idea. They are already done loosely that way for selection methods,
but there does not appear to be anything to group peers based on a tag,
and certainly nothing to group *_access lines together yet.

Want to spec out a 'pool=' option for squid?

Problems:
 How should a group with mixed selection methods be handled?
 How should specific per-peer ACL affect peer group ACL?

Amos


Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

John Doe-3
In reply to this post by John Doe-3
> I tried it once with squid 2.6. It did not work. But I would really
> like it if that would actually work (i.e. grouping multiple peers
> together so one doesn't need to create the same cache_peer_access-rules
> for all peers).

Thx for all the replies.
So what would be the alternative method in my case (2 pools of 3 servers)?
Would this work?

  acl u1 dstdomain u1.example.com
  acl u2 dstdomain u2.example.com

  cache_peer_access u1pool1 allow u1
  cache_peer_access u1pool2 allow u1
  cache_peer_access u1pool3 allow u1
  cache_peer_access u1pool1 deny u2
  cache_peer_access u1pool2 deny u2
  cache_peer_access u1pool3 deny u2

  cache_peer_access u2pool1 allow u2
  cache_peer_access u2pool2 allow u2
  cache_peer_access u2pool3 allow u2
  cache_peer_access u2pool1 deny u1
  cache_peer_access u2pool2 deny u1
  cache_peer_access u2pool3 deny u1

Does it spread the requests or won't the first cache_peer_access always be chosen...?

Thx,
JD


     

Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Jeff Peng-2
Try something like this:

cache_peer 192.168.1.1 parent 80 0 no-query front-end-https=auto
originserver name=origin_1_1 sourcehash
cache_peer 192.168.1.2 parent 8080 0 no-query front-end-https=auto
originserver name=origin_1_2 sourcehash
acl service_1 dstdomain site.com
cache_peer_access origin_1_1 allow service_1
cache_peer_access origin_1_2 allow service_1



John Doe wrote:

>> I tried it once with squid 2.6. It did not work. But I would really
>> like it if that would actually work (i.e. grouping multiple peers
>> together so one doesn't need to create the same cache_peer_access-rules
>> for all peers).
>
> Thx for all the replies.
> So what would be the alternative method in my case (2 pools of 3 servers)?
> Would this work?
>
>   acl u1 dstdomain u1.example.com
>   acl u2 dstdomain u2.example.com
>
>   cache_peer_access u1pool1 allow u1
>   cache_peer_access u1pool2 allow u1
>   cache_peer_access u1pool3 allow u1
>   cache_peer_access u1pool1 deny u2
>   cache_peer_access u1pool2 deny u2
>   cache_peer_access u1pool3 deny u2
>
>   cache_peer_access u2pool1 allow u2
>   cache_peer_access u2pool2 allow u2
>   cache_peer_access u2pool3 allow u2
>   cache_peer_access u2pool1 deny u1
>   cache_peer_access u2pool2 deny u1
>   cache_peer_access u2pool3 deny u1
>
> Does it spread the requests or won't the first cache_peer_access always be chosen...?
>
> Thx,
> JD
>
>
>      
>

Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

John Doe-3
In reply to this post by John Doe-3
> > So what would be the alternative method in my case (2 pools of 3 servers)?
> > Would this work?
> >
> >   acl u1 dstdomain u1.example.com
> >   acl u2 dstdomain u2.example.com
> >
> >   cache_peer_access u1pool1 allow u1
> >   cache_peer_access u1pool2 allow u1
> >   cache_peer_access u1pool3 allow u1
> >   cache_peer_access u1pool1 deny u2
> >   cache_peer_access u1pool2 deny u2
> >   cache_peer_access u1pool3 deny u2
> >
> >   cache_peer_access u2pool1 allow u2
> >   cache_peer_access u2pool2 allow u2
> >   cache_peer_access u2pool3 allow u2
> >   cache_peer_access u2pool1 deny u1
> >   cache_peer_access u2pool2 deny u1
> >   cache_peer_access u2pool3 deny u1
> >
> > Does it spread the requests or won't the first cache_peer_access always be
> > chosen...?
> >
>
> Try something like this:
>
> cache_peer 192.168.1.1 parent 80 0 no-query front-end-https=auto
> originserver name=origin_1_1 sourcehash
> cache_peer 192.168.1.2 parent 8080 0 no-query front-end-https=auto
> originserver name=origin_1_2 sourcehash
> acl service_1 dstdomain site.com
> cache_peer_access origin_1_1 allow service_1
> cache_peer_access origin_1_2 allow service_1

Do I need to explicitly deny the other dstdomains or can I just use a deny all (unless it will override the previous allow)?
By example If I have 3 pools of 2 servers:

acl u1 dstdomain u1.example.com
acl u2 dstdomain u2.example.com
acl u3 dstdomain u3.example.com

cache_peer_access u1_1 allow u1
cache_peer_access u1_2 allow u1
cache_peer_access u1_1 deny all
cache_peer_access u1_2 deny all

cache_peer_access u2_1 allow u2
cache_peer_access u2_2 allow u2
cache_peer_access u2_1 deny all
cache_peer_access u2_2 deny all

etc...

Thx,
JD


     

Reply | Threaded
Open this post in threaded view
|

Re: source-hash balancing...

Amos Jeffries
Administrator
>> > So what would be the alternative method in my case (2 pools of 3
>> servers)?
>> > Would this work?
>> >
>> >   acl u1 dstdomain u1.example.com
>> >   acl u2 dstdomain u2.example.com
>> >
>> >   cache_peer_access u1pool1 allow u1
>> >   cache_peer_access u1pool2 allow u1
>> >   cache_peer_access u1pool3 allow u1
>> >   cache_peer_access u1pool1 deny u2
>> >   cache_peer_access u1pool2 deny u2
>> >   cache_peer_access u1pool3 deny u2
>> >
>> >   cache_peer_access u2pool1 allow u2
>> >   cache_peer_access u2pool2 allow u2
>> >   cache_peer_access u2pool3 allow u2
>> >   cache_peer_access u2pool1 deny u1
>> >   cache_peer_access u2pool2 deny u1
>> >   cache_peer_access u2pool3 deny u1
>> >
>> > Does it spread the requests or won't the first cache_peer_access
>> always be
>> > chosen...?
>> >
>>
>> Try something like this:
>>
>> cache_peer 192.168.1.1 parent 80 0 no-query front-end-https=auto
>> originserver name=origin_1_1 sourcehash
>> cache_peer 192.168.1.2 parent 8080 0 no-query front-end-https=auto
>> originserver name=origin_1_2 sourcehash
>> acl service_1 dstdomain site.com
>> cache_peer_access origin_1_1 allow service_1
>> cache_peer_access origin_1_2 allow service_1
>
> Do I need to explicitly deny the other dstdomains or can I just use a deny
> all (unless it will override the previous allow)?
> By example If I have 3 pools of 2 servers:
>
> acl u1 dstdomain u1.example.com
> acl u2 dstdomain u2.example.com
> acl u3 dstdomain u3.example.com
>
<snip>

The *_access lines are run from top down an a first-match-wins basis per
peer. So an allow of whatever you want, followed by a deny all for each
peer should be fine.

Amos