LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] 2 LVS problems

To: Michael Sparks <zathras@xxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] 2 LVS problems
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Craig Sanders <cas@xxxxxxxxxxxxx>
Date: Wed, 26 Jan 2000 12:42:39 +1100
On Wed, Jan 26, 2000 at 01:03:43AM +0000, Michael Sparks wrote:
> Forwarding mechanisum? (I presume from the above it's VS-DR)

yep. iplvsadm defaults to -g. 

all machines on the same /24 network on the same ethernet, so no need to
mess around with VS-NAT or VS-TUN.


> The real servers need the following line in their squid config unless
> you're using NAT:
> 
> udp_incoming_address x.x.x.8
> ie
> udp_incoming_address VIP
>
> Or else client caches that talk ICP will get confused, and run really
> slowly.

ok, that sounds like the answer. i'll try this tomorrow after i reboot
the director. thank you :)

> Take a look in your cache.log rather than your access.log - if you see
> info along the lines of "unexpected ICP reply from IP x.x.x.215" then
> that's possibly the root cause of your problem.

yep...

2000/01/25 18:46:25| WARNING: Ignored 1 replies from non-peer x.x.x.217
2000/01/25 18:48:32| Failed to select source for 
'http://www.luv.asn.au/overheads.html'
2000/01/25 18:48:32|   always_direct = -1
2000/01/25 18:48:32|    never_direct = 1
2000/01/25 18:48:32|        timedout = 1
2000/01/25 18:48:39| Detected DEAD Parent: x.x.x.8/8080/3130


> > here's where i encountered the first problem. some requests would
> > just fail. i'd get a message from the squid on my WS saying "unable
> 
> My guess is this is just a squid thing rather than anything else - UDP
> based services balanced using VS-DR or VS-TUN like ICP need to be bound to
> the virtual service address or else everything goes a bit screwy. 

that explains a lot. makes perfect sense when i think about it.

> For an excerpt of a detailled discussion I had
> with someone on this, please feel take a look at
> http://epsilon3.wwwcache.ja.net/~zathras/ICP-service.txt (Won't be
> there permenently, but I don't want to clutter up the list)

thanks, i'll read through it.

> > at that point, i had to go out for dinner and left everything as it was.
> > when i got home a few hours later i logged in and discovered that the
> > director had locked up approximately half an hour after i left. it's
> > a public holiday today ("Australia Day") and i haven't yet been in to
> > work to restart it and examine the logs. so there's the second problem:
> > mysterious lockup of a mostly idle director machine.

this is the one that worries me. looks like we have a solution for the
first problem, but mysterious lockups are not good. unfortunately, i
probably wont see the log files until tomorrow (and even then, it's
unlikely that anything was actually logged).




> > any comments, suggestions, ideas would be very welcome...
> >
> > one question: would i be better off using an old pentium box as a
>
> Probably - given squid can be a bit of a beast under high load, and
> fail just when you don't want it to, 

i've found that squid is as stable as the underlying operating system.
it's one of the reasons i always use debian for squid boxes rather
than RH or freebsd. i've reformatted several RH or FreeBSD squid boxes
which were quite flaky and unreliable - installed debian and they run
perfectly stable on exactly the same hardware. admittedly, i'm not as
good at tuning freebsd machines as i am at tuning linux boxes, and i've
heard lots of people say that freebsd does make a good squid box if you
tune it right.

> and the LVS code seems to be as stable as a very stable thing indeed,

that is a very good thing to hear. :-)

> putting the director on a machine that's
> unlikely to fail is a Very Good Thing (tm).

it would also allow me to have all the real-servers identically
configured. IMO, that's a Good Thing. i like consistency - makes it
easier to isolate and track down problems....and it's easier to scale up
as required.

> That said, having one of your proxy's configured to be able to take over
> as a director in an emergency is also a good thing.

i think i'll go for two old pentium machines for the director, with one
running as a failover box.


thanks for your comments, much appreciated.

craig

--
Craig Sanders
Systems Administrator
VICNET- Victoria's Network              http://www.vicnet.net.au/

----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>