Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry

ServerIron config question - can this be done?

 

 

nsp foundry RSS feed   Index | Next | Previous | View Threaded


cliftonr at lava

Jan 22, 2003, 1:36 PM

Post #1 of 5 (1907 views)
Permalink
ServerIron config question - can this be done?

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

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


vandusb at attens

Jan 22, 2003, 2:38 PM

Post #2 of 5 (1835 views)
Permalink
ServerIron config question - can this be done? [In reply to]

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
>
> "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
>http://puck.nether.net/mailman/listinfo/foundry-nsp


cliftonr at lava

Jan 22, 2003, 4:14 PM

Post #3 of 5 (1833 views)
Permalink
ServerIron config question - can this be done? [In reply to]

On Wed, Jan 22, 2003 at 11:38:35AM -0800, Brent Van Dussen wrote:
> 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.

Thanks for the quick response!

The ServerIrons are not dedicated to this customer; the customer's
virtual server will be "sharing time" on a ServerIron we also use for
in-house load-balanced virtual servers. Ultimately other customers
might end up in a similar configuration, and we prefer to map our colo
customers into separate L2 domains.

Is the point of having them in the same L2 domain that the ServerIron
can see ARPs for the servers directly?

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

Sorry, you lost me here.

Are you talking about just adding the "server source-ip
[IP-in-their-netblock]" globally, with a usual "server real foo"
definition, and "port http dsr" on the virtual server, and that that
should do it all? I've never tried this particular permutation, but if
it should work, I'll give it a shot!

-- Clifton

--
Clifton Royston -- LavaNet Systems Architect -- cliftonr [at] lava

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


cliftonr at lava

Jan 23, 2003, 9:45 PM

Post #4 of 5 (1844 views)
Permalink
ServerIron config question - can this be done? [In reply to]

On Wed, Jan 22, 2003 at 11:14:27AM -1000, Clifton Royston wrote:
...
> Are you talking about just adding the "server source-ip
> [IP-in-their-netblock]" globally, with a usual "server real foo"
> definition, and "port http dsr" on the virtual server, and that that
> should do it all? I've never tried this particular permutation, but if
> it should work, I'll give it a shot!

This seems to be working fine; thanks for all the help!

We are running into some minor problems on their servers, because the
Linux kernel is insisting on proxy-arping for the virtual IP and
causing some ARP conflicts.

<http://www.linuxvirtualserver.org/docs/arp.html>

This is a Linux bug or serious misfeature IMHO, but there is a patch
the customer will apply for it as they have built a custom kernel
anyway.

Apart from this, the solution is working fine even in the VLAN
environment, and has saved us having to dedicate a physical ServerIron
switch port to them.

-- Clifton

--
Clifton Royston -- LavaNet Systems Architect -- cliftonr [at] lava

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


jba at analogue

Jan 23, 2003, 11:07 PM

Post #5 of 5 (1842 views)
Permalink
ServerIron config question - can this be done? [In reply to]

On Thu, 23 Jan 2003, Clifton Royston wrote:

:: We are running into some minor problems on their servers, because the
:: Linux kernel is insisting on proxy-arping for the virtual IP and
:: causing some ARP conflicts.
::
:: <http://www.linuxvirtualserver.org/docs/arp.html>
::
:: This is a Linux bug or serious misfeature IMHO, but there is a patch
:: the customer will apply for it as they have built a custom kernel
:: anyway.
::

I agree this is a horrible linux bug, and have yet to see a reasonable
argument why it has become the default behavior for loopback interfaces
in the 2.4 kernel. Anyone?

-jba
__
[jba [at] analogue] :: analogue.networks.nyc :: http://analogue.net

nsp foundry RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.