SUMMARY: [f-nsp] Bouncing L4 Health Checks
Ethan Burnside
burnside at kattare.com
Thu Jun 12 22:00:10 EDT 2003
Hi all,
With Brent, Tim, and George's help, I think we got it hammered out.
Using Brent's advice, I put in the "server no-fast-bringup", and all
hell broke loose. Not because it was the wrong thing to do. But
because the cause was in fact that the L7 health checks were failing on
http and pop3. Both gslb serverirons detected that the slb serverirons
were "down" and started spitting out unmodified DNS responses. heh.
So after some fiddling, I figured out the problems with the health
checks... the http was in fact a redirect issue. I added in the bit to
make a 302 response ok and it's happy now. (the http page is just a
redirect to https.) The pop3 checks were unhappy because we didn't have
the serverirons in our /etc/hosts.allow files on the servers for pop3.
So, that resolves that issue. ;-) I'd like to thank Brent, Tim,
and George for their very helpful suggestions.
All of this brings me to my next question... which I'll post in a
seperate email.
Cheers,
~Ethan B.
--
--------------------------
Ethan Burnside - Founder
Kattare Internet Services
http://www.kattare.com
--------------------------
Quoting Brent Van Dussen <vandusb at attens.com>:
> Try adding the following global command:
>
> server no-fast-bringup
>
> this will force the serveriron to make sure the L7 healtcheck passes
> before
> bringing the server up. Without this command the serveriron will
> bring the
> server up after passing l4 healtcheck and then fail it again when
> performing the L7.
>
> Try using the following command for troubleshooting:
>
>
> show server real http REALSERVERNAME
>
> You'll be able to see what kind of status code the server is
> returning. If
> it is a redirect (somewhat common these days) then you'll need to
> specifiy
> additional status codes that are OK. Default is 200-299. Redirect is
> 302
> so you may need to add the following under each real server config
>
> port http status_code 200 299 302 302
>
> HTH,
> -Brent
>
>
> At 09:29 PM 6/11/2003, Ethan Burnside wrote:
> >Greetings,
> >
> > I've been using a ServerIron XL for SLB and GSLB and have been
> >seeing the health checks bounce up and down for quite some time
> now,
> >similar to the following:
> >
> >0 days 1:7:52 notification L4 server 206.163.128.131
> >front-01-800mcmahan port 110 is up
> >0 days 1:7:52 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 110 is down due to healthcheck
> >0 days 1:7:46 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 80 is up
> >0 days 1:7:46 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 80 is down due to healthcheck
> >0 days 1:7:32 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 110 is up
> >0 days 1:7:32 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 110 is down due to healthcheck
> >0 days 1:7:31 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 80 is up
> >0 days 1:7:31 notification L4 server 206.163.128.131
> front-01-800mcmahan
> >port 80 is down due to healthcheck
> >
> > The server itself hasn't really seen any interruptions in
> service.
> >I can connect directly to it over and over without trouble. The
> logs
> >actually look similar for all of the hosts on the ServerIron, it's
> not
> >limited to a single host. All of the hosts are directly connected
> to
> >the ServerIron.
> >
> > I see the same behavior under both of the following images:
> >
> >Compressed Pri Code size = 1724176, Version 07.3.06T12
> >Compressed Sec Code size = 1873161, Version 07.1.21T12
> (SLB07121.bin)
> >
> > If I disable the L4 health checks, it seems to decide to not do
> the
> >L7 checks. The status remains "active" seemingly no matter what I
> do,
> >(shut down apache, etc.) until I shut down the server at which time
> it
> >changes to "enabled". (I assume because of the failure of the L3
> >check.) I'd really like to use the L4 checks anyway. It's just
> that
> >this "flapping" is causing all kinds of problems with the GSLB
> stuff.
> >We're using the GSLB for a backup/failover "we're working on it"
> error
> >page and to avoid "cannot connect" errors with smtp, pop3, etc.
> But
> >with the L4 checks failing, we're seeing people ending up on the
> backup,
> >despite the primary being fully accessible, etc. I suspect they get
> the
> >backup when the L4 checks on the primary fail simultaneously for
> both
> >the SLB machines.
> >
> > TYIA!
> >
> >Cheers,
> >
> >~Ethan B.
> >
> >
> >--
> >--------------------------
> >Ethan Burnside
> >Kattare Internet Services
> >http://www.kattare.com
> >--------------------------
> >
> >
> >
> >Quoting Brent Van Dussen <vandusb at attens.com>:
> >
> > > You'll need to keep the serveriron and the customers webservers
> in
> > > the same
> > > L2 domain. If the webservers and the serveriron are all part of
> the
> > > same
> > > customer installation I don't see why it has to be separated out
> into
> > > VLAN's.
> > >
> > > DSR will do everything else that you need it to, just remember
> that
> > > you'll
> > > have to configure Loopbacks on each of the real servers.
> > >
> > > If the real servers are in a different subnet than the serveriron
> you
> > > can
> > > use the source-ip or just put both subnets on the upstream L3
> device
> > > and
> > > the serveriron will route health checks up to the router and
> back
> > > down to
> > > the real servers.
> > >
> > > -Brent
> > >
> > >
> > > At 10:36 AM 1/22/2003, Clifton Royston wrote:
> > > > I am trying to configure a particular
> load-balancing+failover
> > > setup
> > > >for a web customer who will be colo'ed with us, and am wondering
> if
> > > >there is a way to do this. I've got 2 original ServerIrons and
> one
> > > >ServerIron XL, I'm planning to put this onto the XL.
> > > >
> > > > I would like the configuration to have the following
> properties:
> > > >
> > > >1) The ServerIron can determine when any of the real servers is
> > > down
> > > > (i.e. failover works correctly)
> > > >
> > > >2) The customer web servers do not have to be physically
> connected
> > > > "through" the ServerIron.
> > > >
> > > >3) The original source IP address of the connection is
> preserved
> > > (they
> > > > need that for their logging and analysis.)
> > > >
> > > >4) Preferably, the customer servers are in their own address
> block
> > > and
> > > > VLAN (Ethernet broadcast domain.)
> > > >
> > > > Is there any way to get all of these at one time?
> > > >
> > > > I know I can achieve 1, 3, and 4 by physically routing their
> > > >connection through a ServerIron port dedicated to their VLAN;
> > > that's
> > > >close to our standard configuration so I'm not showing that
> here.
> > > >That's my fallback solution, but I'd like to be able to do this
> > > without
> > > >dedicating a port.
> > > >
> > > > I think I could achieve 2, 3, and 4 by defining the servers
> as
> > > >"remote" instead of "real" and configuring DSR, but the
> > > documentation
> > > >seems to imply that the ServerIrons can't automatically detect
> a
> > > failed
> > > >server in that case.
> > > >
> > > > I know I can achieve the combination of properties 1, 2, and
> 4
> > > by
> > > >configuring a tagged VLAN on the main Ethernet link to our main
> > > switch
> > > >and configuring their servers with source NAT like this; this
> > > rewrites
> > > >the source IP, but routes everything correctly, distributes
> load
> > > >fairly, detects failed servers, and keeps them in their own
> VLAN:
> > > >
> > > >server source-ip xx.yy.zz.14 255.255.255.240 xx.yy.zz.1
> > > >real server their-server-1 xx.yy.zz.2
> > > > source-nat
> > > > port http
> > > > port http url "HEAD /"
> > > >real server their-server-2 xx.yy.zz.3
> > > > source-nat
> > > > port http
> > > > port http url "HEAD /"
> > > >server virtual virtual-85 ww.vv.uu.tt
> > > > sym-priority 100
> > > > port http
> > > > bind http their-server-1 their-server-2
> > > >
> > > > Is there any way to get all of what I want - failover
> detection,
> > > not
> > > >dedicating a port to put the servers "behind" the ServerIron,
> source
> > > IP
> > > >preserved, and keeping them in their own VLAN?
> > > >
> > > > Thanks in advance for any help.
> > > > -- Clifton
> > > >
> > > >--
> > > > Clifton Royston -- LavaNet Systems Architect --
> > > cliftonr at lava.net
> > > >
> > > > "If you ride fast enough, the Specialist can't catch you."
> > > > "What's the Specialist?" Samantha says.
> > > > "The Specialist wears a hat," says the babysitter. "The hat
> makes
> > > noises."
> > > > She doesn't say anything else.
> > > > Kelly Link, _The Specialist's Hat_
> > > >_______________________________________________
> > > >foundry-nsp mailing list
> > > >foundry-nsp at puck.nether.net
> > > >http://puck.nether.net/mailman/listinfo/foundry-nsp
> > >
> > >
> > > _______________________________________________
> > > foundry-nsp mailing list
> > > foundry-nsp at puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/foundry-nsp
> > >
> >
> >_______________________________________________
> >foundry-nsp mailing list
> >foundry-nsp at puck.nether.net
> >http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
More information about the foundry-nsp
mailing list