RE: [squid-users] cache_peer and acl random problem

On Wed, 28 Jul 2010 17:43:28 +0000, Jenny Lee <bodycare_5_at_live.com> wrote:
>> Jenny Lee wrote:
>> >
>> > Hello folks,
>> >
>> > I am trying to load-balance a username among 2 parents and the cache
>> > itself (direct).
>> >
>> > I have:
>> >
>> > [auth_param parts snipped, username works fine]
>> >
>> > acl 33PERCENT random 1/3
>> > acl TESTUSER proxy_auth TESTUSER
>> >
>> > cache_peer 2.2.2.3 parent 4444 0 proxy-only name=P2 login=PASS
>> > cache_peer 2.2.2.4 parent 4444 0 proxy-only name=P3 login=PASS
>> >
>> > cache_peer_access P2 allow TESTUSER 33PERCENT
>> > cache_peer_access P3 allow TESTUSER 33PERCENT
>> >
>> > cache_peer_access P2 deny all
>> > cache_peer_access P3 deny all
>> >
>> >
>> > I can't seem to get this working. I surely must be overlooking
>> > something.
>>
>> Are you running the 3.HEAD development (alpha release) code which
>> supports the random ACL?
>
> Yes.
>
>
>> check the particular HEIR codes being logged, I'm not sure what to
>> expect under these circumstances but I suspect you are getting a mix of
>> FIRST_UP_PARENT, DIRECT and something else. For this to work you are
>> wanting only one of the parent selection algorithms to work in addition
>> to DIRECT.
>
> It is never going DIRECT. It is going fine to parent2 and parent3...
> However, I get 407 both from P2 and the local cache trying from
> squidclient. PASS,PASSTHRU,PROXYPASS... all tried witht he same outcome.
>
>> >
>> > How can I make the username go from 2 parents and cache itself
>> > (direct) randomly?
>>
>> The traditional way is still easy...
>>
>> Setup a non-caching gateway instance which does the load balancing
>> between the two parents and a local caching instance.
>
> None of these are doing any caching at the moment. This is for testing
> only. I would like this to be done on the config of one squid only. The
> others don't forward anything. The just fetch whatever leecher squid
asks
> them.
>
>
>> If you have the 3.HEAD code for random ACL you could also try out the
>> new worker-based equivalent to the above....
>> One worker process-id on the localhost+caching, and another on the
>> public port + random ACL + peers to balance between localhost parent
>> and the parents. :)
>
> I didnt really understand the logic how the workers work. Is there any
> documentation or pointers?

Sketchy at present since its so new. In the background its identical to
starting multiple instances with slight variations on their squid.conf.

Only one squid.conf is needed now, with wrapping bits that are specific to
one worker in an if...endif statement using a process number (integer) to
tell the workers apart. Numbering I think is arbitrary 1,2,3,etc as long as
your config is self-consistent. The config bits that are not wrapped in
if...endif are shared by all workers.

>
> acl random has a load balancing example for cache_peer. How to add
DIRECT
> to that equation? always_direct? never_direct? I tried everything
> imaginable. There must be some solution.

Always direct forces peers never to be used.

hmm, I had overlooked *_direct. never_direct would leave a number of
requests with no access if the randomness failed to select a parent and
then selected never_direct.

I think always_direct should work. If you 1/3 randomly the always_direct
and also round-robin the parents it should be expected to always have one
route outwards.

>
> Thanks for acl random. That is a true gem. I waited so long for it, but
> unfortunately you did not incorporate it to 3.1 so i went with 3.HEAD on
a
> production machine.

Ouch, sorry about that. At least it's beta in a few days.

The lame excuse: I/we are trying to get 3.x into a predictable schedule
that works for both us few dev and yourselves the clients. That means some
pressure on feature porting to encourage more testing. 3.2 is only 6 months
off the desired yearly turnover. Fingers crossed the following ones will
close the gap even further.

Amos
Received on Thu Jul 29 2010 - 05:04:52 MDT