Mailing List Archive

At 11:37 PM 6/22/2004, Michael Bellears wrote:
>My other question is regarding the ServerIron switch ports - Must each
>backend "real" server have a dedicated port, or can I connect a layer 2
>switch to one of the ServerIron ports to give me greater capacity?


No need for a dedicated port, you can put your reals on another l2 switch
and have a single port on the serveriron servicing them. There's a
limitation on real servers but it is pretty high up there like 1024 or
something.

-Brent

The way I understood it when I researched it and subsequently set up
gslb, there needed to be ServerIrons at each location. Requests are
handled by the way DNS is handled.

If you're using a remote server to have one server closer to where some
of your users will be, then when they get the DNS response, they're
given the response closest to them. If you're doing it for redundancy
and you don't want anyone to hit that site unless everything else is
down, they're given the DNS of the primary site until none of those real
servers are available, then they're given the DNS for the redundant
site.

Its smoke, mirrors and DNS. The ServerIrons actually have to have DNS
behind them to see the responses and change them if necessary, or they
have to provide the DNS for that (sub)domain themselves and they change
it if necessary. They need to have control of the DNS in some way for
glsb to work. Hard to grasp the first time you hear it, but the
ServerIrons can do DNS.


Cheers,
Em





-----Original Message-----
From: foundry-nsp-bounces@puck.nether.net
[mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Michael
Bellears
Sent: Wednesday, 23 June 2004 4:08 PM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] ServerIronXL 16 or 24 port questions..

We are looking at purchasing one of the above devices, and primarily
want to use it for Global Load Balancing ("real" servers will be located
in geographic disperse locations.)

How is the above achieved on the ServerIron - Eg. For load-balancing of
a webserver: If we have one "real" server directly connected to the
ServerIron, and another "real" server co-located with provider x in
another country - How are requests handled?

- All requests for the webserver are initially handled by the
ServerIron (Virtual Server IP), requests are forwarded to Real IP
(Server directly connected), and also to remote server (Does traffic
destined for this server go back out the Server Irons default GW?)

My other question is regarding the ServerIron switch ports - Must each
backend "real" server have a dedicated port, or can I connect a layer 2
switch to one of the ServerIron ports to give me greater capacity?

Thanks in advance.

Regards,
MB


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hi Emilia,

>
> The way I understood it when I researched it and subsequently
> set up gslb, there needed to be ServerIrons at each location.

Wow! - Ok, so there is no other way to perform Global Load balancing
without having a ServerIron at each site?

Regards,
MB

It very much depends what you're trying to achieve, but does this help
any?
http://www.foundrynet.com/services/documentation/siug/ServerIron_GSLB.ht
ml#71178



Cheers,
Em




-----Original Message-----
From: Michael Bellears [mailto:MBellears@staff.datafx.com.au]
Sent: Thursday, 24 June 2004 9:17 AM
To: Emilia Lambros; foundry-nsp@puck.nether.net
Subject: RE: [f-nsp] ServerIronXL 16 or 24 port questions..

Hi Emilia,

>
> The way I understood it when I researched it and subsequently set up
> gslb, there needed to be ServerIrons at each location.

Wow! - Ok, so there is no other way to perform Global Load balancing
without having a ServerIron at each site?

Regards,
MB

>
> It very much depends what you're trying to achieve, but does
> this help any?
> http://www.foundrynet.com/services/documentation/siug/ServerIr
> on_GSLB.ht
> ml#71178

It certainly does.

If I read correctly, ServerIron performing DNS proxying, responds to the
requesting client a list of Sites, and also moves the geographically
closest site to the top of the list - Does the Server Iron performing
the DNS proxying also keep a state record of the serving sites servers?
If not, and all servers at GSLB Site 1 Sunnyvale(From the diagram) were
down, wouldn't the requesting client get page cannot be displayed error?

If it the ServerIron performing DNS proxying does keep state records of
serving sites servers, then I can see no reason why I would need a
ServerIron at each location?

Thanks for the information also!

Regards,
MB

>
>
>
> Cheers,
> Em
>
>
>
>
> -----Original Message-----
> From: Michael Bellears [mailto:MBellears@staff.datafx.com.au]
> Sent: Thursday, 24 June 2004 9:17 AM
> To: Emilia Lambros; foundry-nsp@puck.nether.net
> Subject: RE: [f-nsp] ServerIronXL 16 or 24 port questions..
>
> Hi Emilia,
>
> >
> > The way I understood it when I researched it and
> subsequently set up
> > gslb, there needed to be ServerIrons at each location.
>
> Wow! - Ok, so there is no other way to perform Global Load
> balancing without having a ServerIron at each site?
>
> Regards,
> MB
>
>
>

Can't say I've ever configured it without SLBs at each site. We did it
slightly differently to the way they did it in any case:

Primary site:

two ServerIrons doing the following:
- regular load balancing for sub.domain.com.au across X web servers
(just http) .. the virtual and real servers are all in the same subnet
as the load balancer, so nothing fancy
- running gslb protocol
- virtual for DNS requests (the subdomain is actually delegated to the
dns virtual server that's configured on both the SLBs)


Secondary site

two serverirons doing the following:
- regular load balancing for sub.domain.com.au across X web servers
(just http) .. again, the virtual and real servers are all in the same
subnet as the load balancer
- running gslb protocol
- virtual for DNS requests (as per any DNS, the subdomain is delegated
to more than one name server - in this case those nameservers are SLBs.


As part of the GSLB config, the presence of every other load balancer is
configured into every other load balancer.

e.g. at the primary site, we configured each location and what
serverirons are located there. Through GSLB, the load balancers
discover what virtual servers are on each and whether they're active or
not based on whether any real servers bound to it are active. We also
set priorities in our case because we only want one of the IP addresses
to be given to the client requesting the site. All servers have to be
failed at the primary site before the secondary site is given as a
response to anyone doing even an nslookup on sub.domain.com.au.

Its a little difficult to understand without being able to sift through
the config for yourself, but if I get a chance I'll "anonymous" it and
add it for you to take a look at :)

Em





-----Original Message-----
From: Michael Bellears [mailto:MBellears@staff.datafx.com.au]
Sent: Thursday, 24 June 2004 10:45 AM
To: Emilia Lambros
Cc: foundry-nsp@puck.nether.net
Subject: RE: [f-nsp] ServerIronXL 16 or 24 port questions..

>
> It very much depends what you're trying to achieve, but does this help

> any?
> http://www.foundrynet.com/services/documentation/siug/ServerIr
> on_GSLB.ht
> ml#71178

It certainly does.

If I read correctly, ServerIron performing DNS proxying, responds to the
requesting client a list of Sites, and also moves the geographically
closest site to the top of the list - Does the Server Iron performing
the DNS proxying also keep a state record of the serving sites servers?
If not, and all servers at GSLB Site 1 Sunnyvale(From the diagram) were
down, wouldn't the requesting client get page cannot be displayed error?

If it the ServerIron performing DNS proxying does keep state records of
serving sites servers, then I can see no reason why I would need a
ServerIron at each location?

Thanks for the information also!

Regards,
MB

>
>
>
> Cheers,
> Em
>
>
>
>
> -----Original Message-----
> From: Michael Bellears [mailto:MBellears@staff.datafx.com.au]
> Sent: Thursday, 24 June 2004 9:17 AM
> To: Emilia Lambros; foundry-nsp@puck.nether.net
> Subject: RE: [f-nsp] ServerIronXL 16 or 24 port questions..
>
> Hi Emilia,
>
> >
> > The way I understood it when I researched it and
> subsequently set up
> > gslb, there needed to be ServerIrons at each location.
>
> Wow! - Ok, so there is no other way to perform Global Load balancing
> without having a ServerIron at each site?
>
> Regards,
> MB
>
>
>

Emilia Lambros wrote:
> Can't say I've ever configured it without SLBs at each site.
> We did it slightly differently to the way they did it in any case:
>
> Primary site:
>
> two ServerIrons doing the following:
> - regular load balancing for sub.domain.com.au across X web
> servers (just http) .. the virtual and real servers are all
> in the same subnet as the load balancer, so nothing fancy
> - running gslb protocol
> - virtual for DNS requests (the subdomain is actually
> delegated to the dns virtual server that's configured on both
> the SLBs)
>
>
> Secondary site
>
> two serverirons doing the following:
> - regular load balancing for sub.domain.com.au across X web
> servers (just http) .. again, the virtual and real servers
> are all in the same subnet as the load balancer
> - running gslb protocol
> - virtual for DNS requests (as per any DNS, the subdomain is
> delegated to more than one name server - in this case those
> nameservers are SLBs.
>
>
> As part of the GSLB config, the presence of every other load
> balancer is configured into every other load balancer.
>
> e.g. at the primary site, we configured each location and
> what serverirons are located there. Through GSLB, the load
> balancers discover what virtual servers are on each and
> whether they're active or not based on whether any real
> servers bound to it are active. We also set priorities in
> our case because we only want one of the IP addresses to be
> given to the client requesting the site. All servers have to
> be failed at the primary site before the secondary site is
> given as a response to anyone doing even an nslookup on
> sub.domain.com.au.

Ahh - This makes things much clearer! Ta!

>
> Its a little difficult to understand without being able to
> sift through the config for yourself, but if I get a chance
> I'll "anonymous" it and add it for you to take a look at :)

That would be awesome Em - If it is too much of a hassle, even a look at
each sites config would be fantastic!( Obviously remove any passes etc!)

>
> Em

"Emilia Lambros" <emilial@hostworks.com.au> writes:

> The way I understood it when I researched it and subsequently set up
> gslb, there needed to be ServerIrons at each location.

Yes. The ServerIrons need to measure the RTT between the real servers
an the clients, so you need a ServerIron in the path between every
server and client, preferably very close to the servers. Hard to
imagine how to do this without having a ServerIron at each location.
But why not? It's a great SLB box anyway.

> Its smoke, mirrors and DNS. The ServerIrons actually have to have DNS
> behind them to see the responses and change them if necessary, or they
> have to provide the DNS for that (sub)domain themselves and they change
> it if necessary. They need to have control of the DNS in some way for
> glsb to work. Hard to grasp the first time you hear it, but the
> ServerIrons can do DNS.

In theory. I practice they can only handle A records, and they will
not respond at all to requests for anything else (at least they didn't
with 07.1.21 and earlier SW)! This means that you *must* have a real
DNS server behind the ServerIron to serve NXDOMAIN answers to e.g.
AAAA requests, or clients supporting IPv6 will suffer a long delay
caused by DNS timeout.


Bj?rn

Agreed - I had my doubts when I first started configuring it, but even with the convoluted solution we put together it still all turned out really well and incredibly redundant (two SLBs at each site, everything running with GSLB and every virtual including DNS running with sym-priorities for failover). I can't imagine what the performance might be without having SLBs at each site - you'd need to run DSR as a start, and the load balancer also wouldn't have an accurate perspective of the RTT as you said, so you couldn't load balance too well based on RTT.

Also with DNS, you're correct - it does only respond to A records so if you want anything more from it, you will need the SLB to sit in front of name servers. In our case, we only required A records with a very low ttl, so the SLB doing the job was perfect.

Cheers,
Em



-----Original Message-----
From: Bj?rn Mork [mailto:bjorn@mork.no]
Sent: Monday, 28 June 2004 5:33 PM
To: Emilia Lambros
Cc: Michael Bellears; foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] ServerIronXL 16 or 24 port questions..

"Emilia Lambros" <emilial@hostworks.com.au> writes:

> The way I understood it when I researched it and subsequently set up
> gslb, there needed to be ServerIrons at each location.

Yes. The ServerIrons need to measure the RTT between the real servers an the clients, so you need a ServerIron in the path between every server and client, preferably very close to the servers. Hard to imagine how to do this without having a ServerIron at each location.
But why not? It's a great SLB box anyway.

> Its smoke, mirrors and DNS. The ServerIrons actually have to have
> DNS behind them to see the responses and change them if necessary, or
> they have to provide the DNS for that (sub)domain themselves and they
> change it if necessary. They need to have control of the DNS in some
> way for glsb to work. Hard to grasp the first time you hear it, but
> the ServerIrons can do DNS.

In theory. I practice they can only handle A records, and they will not respond at all to requests for anything else (at least they didn't with 07.1.21 and earlier SW)! This means that you *must* have a real DNS server behind the ServerIron to serve NXDOMAIN answers to e.g.
AAAA requests, or clients supporting IPv6 will suffer a long delay caused by DNS timeout.


Bj?rn

"Emilia Lambros" <emilial@hostworks.com.au> writes:

> Also with DNS, you're correct - it does only respond to A records so
> if you want anything more from it, you will need the SLB to sit in
> front of name servers. In our case, we only required A records with
> a very low ttl, so the SLB doing the job was perfect.

That's what we wanted too.

The problem is that you can't control which questions it gets. Lots
of clients will ask for AAAA records nowadays. A regular DNS server
will immediately return NXDOMAIN when no AAAA records are defined, but
the ServerIron didn't even when running as a standalone DNS server. It
just dropped the AAAA requests, causing long delays for these clients
before they eventually timed out and fell back to asking for an A
record.

Therefore, you do want to run a real DNS server behind it even if you
are just serving A records. The real DNS server will generate the
proper NXDOMAIN anwsers

Now, I should of course add a disclaimer: This was the observed
behaviour the way we configured it. We might have forgotten some
crucial part. Here are the relevant parts of the config before adding
a real DNS server in case anyone wants to verify it:


server virtual vs 148.x.x.69
predictor round-robin
port http
port dns
bind http real1 http real2 http real3 http real4 http

gslb policy
round-trip-time tolerance 0
round-trip-time cache-prefix 16
round-trip-time cache-interval 1800
dns ttl 60
dns override
dns cache-proxy

gslb site Site1
si serveriron1 148.x.x.67
gslb site Site2
si serveriron2 217.x.x.3

gslb dns zone glsb.example.com
host-info null-host http
host-info null-host ip-list 148.x.x.69 217.x.x.4



Bj?rn

* bjorn@mork.no (Bjrn Mork) [Mon 28 Jun 2004, 13:44 CEST]:
> The problem is that you can't control which questions it gets. Lots
> of clients will ask for AAAA records nowadays. A regular DNS server
> will immediately return NXDOMAIN when no AAAA records are defined, but

Actually they'll reply NOERROR to indicate other data is available, just
not of the requested type


> the ServerIron didn't even when running as a standalone DNS server. It
> just dropped the AAAA requests, causing long delays for these clients
> before they eventually timed out and fell back to asking for an A
> record.

So the SI will only intercept A queries?


-- Niels.

--

Ours is pretty much the same except for having no real servers for DNS and a separate virtual for the actual website and also:

gslb policy
metric-order set health-check preference capacity round-trip-time geographic num-session flashback
preference
dns ttl 5
dns active-only
dns best-only
dns override
dns cache-proxy
protocol status-interval 2


what do your round trip commands do in the policy? I could look it up myself but I'm incredibly lazy :)

Em




-----Original Message-----
From: Bj?rn Mork [mailto:bjorn@mork.no]
Sent: Monday, 28 June 2004 9:14 PM
To: Emilia Lambros
Cc: Michael Bellears; foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] ServerIronXL 16 or 24 port questions..

"Emilia Lambros" <emilial@hostworks.com.au> writes:

> Also with DNS, you're correct - it does only respond to A records so
> if you want anything more from it, you will need the SLB to sit in
> front of name servers. In our case, we only required A records with a
> very low ttl, so the SLB doing the job was perfect.

That's what we wanted too.

The problem is that you can't control which questions it gets. Lots of clients will ask for AAAA records nowadays. A regular DNS server will immediately return NXDOMAIN when no AAAA records are defined, but the ServerIron didn't even when running as a standalone DNS server. It just dropped the AAAA requests, causing long delays for these clients before they eventually timed out and fell back to asking for an A record.

Therefore, you do want to run a real DNS server behind it even if you are just serving A records. The real DNS server will generate the proper NXDOMAIN anwsers

Now, I should of course add a disclaimer: This was the observed behaviour the way we configured it. We might have forgotten some crucial part. Here are the relevant parts of the config before adding a real DNS server in case anyone wants to verify it:


server virtual vs 148.x.x.69
predictor round-robin
port http
port dns
bind http real1 http real2 http real3 http real4 http

gslb policy
round-trip-time tolerance 0
round-trip-time cache-prefix 16
round-trip-time cache-interval 1800
dns ttl 60
dns override
dns cache-proxy

gslb site Site1
si serveriron1 148.x.x.67
gslb site Site2
si serveriron2 217.x.x.3

gslb dns zone glsb.example.com
host-info null-host http
host-info null-host ip-list 148.x.x.69 217.x.x.4



Bj?rn

The responses I've seen using a dodgy little app called DNScape seem to
support that the only responses it will happily give are A records. It
seems to pretty much just ignore anything else, or in the case of
requesting "any", it times out and says "no reply".



-----Original Message-----
From: foundry-nsp-bounces@puck.nether.net
[mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Niels Bakker
Sent: Monday, 28 June 2004 9:31 PM
To: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] ServerIronXL 16 or 24 port questions..

* bjorn@mork.no (Bjrn Mork) [Mon 28 Jun 2004, 13:44 CEST]:
> The problem is that you can't control which questions it gets. Lots
> of clients will ask for AAAA records nowadays. A regular DNS server
> will immediately return NXDOMAIN when no AAAA records are defined, but

Actually they'll reply NOERROR to indicate other data is available, just
not of the requested type


> the ServerIron didn't even when running as a standalone DNS server.
> It just dropped the AAAA requests, causing long delays for these
> clients before they eventually timed out and fell back to asking for
> an A record.

So the SI will only intercept A queries?


-- Niels.

--
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

"Emilia Lambros" <emilial@hostworks.com.au> writes:

> Ours is pretty much the same except for having no real servers for DNS and a separate virtual for the actual website and also:
>
> gslb policy
> metric-order set health-check preference capacity round-trip-time geographic num-session flashback
> preference
> dns ttl 5
> dns active-only
> dns best-only
> dns override
> dns cache-proxy
> protocol status-interval 2
>
>
> what do your round trip commands do in the policy? I could look it up myself but I'm incredibly lazy :)

I'm lazy too :-) So this is from memory (and the config is a few years
old...):

"round-trip-time tolerance 0" was an attempt to compensate for a short
distance between the sites (20 - 30 ms).

"round-trip-time cache-prefix 16" makes the SI assume all clients in a
/16 are equally far away, requiring fewer clients to populate the RTT
cache (but of course also reducing precision)

"round-trip-time cache-interval 1800" increases the cache interval to
1800 seconds, also to reduce the number of clients necessary to
populate the cache.


Bj?rn

Niels Bakker <niels=foundry-nsp@bakker.net> writes:
> * bjorn@mork.no (Bjrn Mork) [Mon 28 Jun 2004, 13:44 CEST]:
>
>> The problem is that you can't control which questions it gets. Lots
>> of clients will ask for AAAA records nowadays. A regular DNS server
>> will immediately return NXDOMAIN when no AAAA records are defined, but
>
> Actually they'll reply NOERROR to indicate other data is available, just
> not of the requested type

You're of course right. I have to learn to be precise one day...

>> the ServerIron didn't even when running as a standalone DNS server. It
>> just dropped the AAAA requests, causing long delays for these clients
>> before they eventually timed out and fell back to asking for an A
>> record.
>
> So the SI will only intercept A queries?

That's my experience. But this was with 07.1.21 which is 2.5 years
old now. I've not tried GSLB with any newer SW.


Bj?rn