Based on the IP addresses, it looks like this is something which is
used just internally, not for external clients coming in over the
internet.

That's not to say that round-robin DNS can't still be used, but only
as long as you are using accessing via a host name, and probably only
if you are using actual DNS server lookups (i.e. using a hosts table
probably won't work). Is that the case?

The client being well-coded means that if the client receives multiple
IP addresses back on a DNS lookup of the server's host name, it needs
to retain all of them. If it can't establish a connection using the
first IP address, it needs to automatically try again using the second
IP address, and then using the third IP address, and so on, until it
either can establish the connection or runs through the entire list.

If the server on a particular machine isn't running, so nothing is
listening on that port, the OS should automatically send an a TCP RST
and the client should immediately move on to the next IP address. You
shouldn't need to have that interface down if that the point of your
description below. And in fact it will probably take longer for the
client to failover to the next IP address if the interface is down
because the OS probably won't respond at all to the connection request
and the client will have to time out before moving on.

On Mon, 30 Jul 2012 07:22:18 -0400, rob@xxxxxxxxx wrote:

I guess the trick in that case is to not start the IP address until just
before you start the server? For example if NETSTAT *IFC shows these
addresses on my i
10.17.6.32
10.17.6.33
10.17.6.34
10.17.6.35
10.17.6.36
10.17.6.37
10.17.6.38
10.17.6.39
10.17.6.40
10.17.6.41
10.17.6.42
10.17.6.43
10.17.252.190
and 10.17.6.36 is one of these addresses, it serves this server, then I
should turn autostart off and only start it right before starting the
server and I should drop it right before stopping the server? Is this
what you meant by "If the client is coded well"?


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Ken Sims <mdrg8066@xxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 07/27/2012 04:43 PM
Subject: Re: Intelligent IP sprayer or round robin
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Hi Rob -

On Fri, 27 Jul 2012 15:54:20 -0400, rob@xxxxxxxxx wrote:

I also don't want to go from saying:
"We only have one sametime server. If that is down we're toast."
to saying:
"We only have one intelligent IP sprayer. If that is down we're toast."
IOW, I don't want to just trickle up the single point of failure.

One thought is round-robin DNS. Of course this requires both the DNS
server and the client to be coded appropriately. It also requires
that each server have it's own internet-routable IP address. (The IP
address selection is made by the client in this scenario.)

Assuming that the DNS servers can handle it, you put in multiple A
records for the same host name with different IP addresses. These
different IP addresses don't have to have any relationship to each
other, so they can be for completely different locations, thereby
helping to eliminate your single-point-of-failure. (And of course you
should already have multiple DNS servers at different locations.)

When a request is made for that host name, the DNS server returns all
of the IP addresses. It rotates the order (hence "round-robin") which
provides some crude load balancing.

If the client is coded well, if it can't connect to the port with the
first IP address, it will try the second and so forth.

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

Ken
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.