|
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
|
