TCP/IP v.5.4 Cluster Load Balancing

[Jefferson Humber]

Want to setup TCP/IP load balancing under TCP/IP v.5.4, utilising the METRIC & LOAD_BROKER services.

It would appear from reading the guide that the LOAD_BROKER writes the metric value back to the DNS servers. Has anybody got this working ?

We use Microsoft W2K DNS Servers, all the examples in the guide mentioned Unix BIND. Have managed to get the BIND Resolver talking to the MS DNS servers, so it would appear that this is compatible at least.

Can anybody out there share their experiences on this matter, does any body have a cluster with balanced IP connections to it ??

Thanks is advance,

Jeff

[Jefferson Humber]

Probably should of mentioned in the previous posting that it's a 2 node cluster we want to balance across using an alias. With the connections coming in from PC's around the company.

[Willem Grooters]

Jeff,

No _real_ experience but to my knowlegde it would be enough to define a cluster alias and connect to that address. Load balance will then be automatic since the node that has least work will respond first - and take the job.

[Jan van den Ende]

Willem:

Yes, simply define a cluster alias...
Those were the days when we used DECnet & LAT: simple, straightforward, and secure.
In todays' IP-dominated world you can forget about that. DECnet is machine-oriented, and you can even have a cluster act as ONE machine. IP is device-oriented, and if you have multople network devices in a system, you even have to specify WHICH of those.
Yes, you can trich a DNS server to periodically change which one to use. This applies for different devices in a machine as well as for different machines in a cluster. If you use round-robin (each address a fixed amount of time, then the next etc), then if one of the addresses in the list is not available, every time this address used, the user or application simply has to wait for a timeout and try again (maybe getting the same address). An improvement is the LOAD BROKER (if your DNS server supports that function). In addition to that, you need a metric "Daemon" (urrrghh) on each node of your alias. Those daemons know the relative power of the machine and the "recent" average load, they communicate with one another to decide who can best carry extra load, en tell DNS to translate the "cluster" address to the network device of that system. In this way that system becomes the cluster "impersonator". Oh yeah... you may strike some extra luck. Your networking people might well cache the name resolution for much longer periods as your impersonator switchovers. Then, one system wil get ALL the load. WE had some real "fun" trying to convince them to use shorter caching times than 24 hours, because "otherwise the switches have to lookup name translations much too frequent, that just costs performance".
If you can manage to have your DNS on your VMS, tou might be a lot better off, but the caching issue remains.

"welcome to the wonderfull world of IP"

Jan

[Lokesh_2]

Hi,

I am not sure about V5.4 , but for earlier versions, we are using cluster alias . See below note to find how load balancing is done when you define cluster alias in DNS:

__________________________________________

Incoming requests are switched among the cluster hosts at the end of each cluster time interval (specified with the SET COMMUNICATION command).


Note

--------------------------------------------------------------------------------
The cluster name is not switched from a host if there are any active TCP connections to the cluster interface on that host.

A remote host can use the cluster alias to address the cluster as a single host or the host name of the cluster member to address a cluster member individually.

All of the TCP/IP services support automatic failover and can be run on multiple nodes in an OpenVMS Cluster. For example, if more than one host in the cluster is running the NFS server, the cluster can appear to the NFS client as a single host. For more information about configuring a specific service for cluster failover, refer to the chapter in this manual that discusses the particular service.

________________________________________

see also help on set commun/cluster_time for information.

Thanks & regards,
Lokesh Jain

[Ian Miller. · Accepted solution]

Don't use cluster address as the node who recives connections to the cluster address only changes when no connections are active (which in practice never occurs).

For the metric server stuff the DNS server holds a name (cluster name) and the IP addresses of each node in the cluster. When asked about the name the DNS server returns the addresses in order of system load - least loaded first. System load is measured by the metric server which the DNS server polls periodically. I've done this with a VMS based DNS server (UCX V4.2 :-) and it was fine because I could control TTL values for the names. You have to ensure the TTL value for the cluster IP name is small enough so nodes do not hold the result of resolving the name too long. Also you need a DNS server that knows how to poll systems for the system load. I know VMS based DNS servers work and I think Digital Unix servers work also. MS DNS servers I know not.

[Willem Grooters]

Jan,

If you re-assign IP addresses to names, yes, you're sure to get trouble with DNS and certainly when expiration times differ. But that has nothing to do with IP or DNS, but more with your configuration. Why would you do that?

For what I've learned in VMS system management and TCPIP configuration:

If a program request data from the _cluster_, it will be served by the least occupied node. The result will carry this sender's address, not the cluster alias. In normal situations quite obvious, even required, since images talk to eachother and each should address the other exactly. So by NODE address, not by CLUSTER address.

Same applies to requests that are issued from a cluster node to a machine outside the cluster (whether this carries a clusetr alias or not). The request will carry the IP address of the sender (that is: the originating node) and the result will be sent to that one. Again: this is task-to-task communication.

Put simple: the cluster alias is for accessing any node within that cluster; the load on each will determine what node will react.

DNS connects name and address. In a clustered environment, you should have 1 name/address pair more than you have nodes: One for each node + the cluster alias one.
Well set up, DNS does it's job AFAIK. I haven't seen or heard of the opposite. And there quite a lot of systems out there that run with a cluster alias. Without trouble.

In case that DNS is to handle load balancing, it's the non-VMS way. I would suggest: DON'T USE IT. Let VMS handle it. Clustering on VMS can handle this, by nature.
(Unless anyone can explain why I should use it. What's the advantage?)

Willem

(FYI: I'm an IP fanatic, I'm well aware of it's shortcomings (don't forget it's old and Unix-ware) but in most circumstances, it's just a requirement)

[Lokesh_2]

Hi Willem,

I agree with Ian. Lets say you have two systems in cluster with ip address x.x.x.1 & x.x.x.2 and on both of them you defined cluster address as x.x.x.3 . Now on DNS , you have defined the cluster name with IP address x.x.x.3 only.

Assume right now there are not active TCP/IP connection to any of the nodes, and I am telneting the cluster with x.x.x.3 . My connection goes to say x.x.x.1 .

Now , as per documentation "The cluster name is not switched from a host if there are any active TCP connections to the cluster interface on that host" , therefore unless I close my telnet connection, all other telnet connection will go to x.x.x.1 only.

So where is the load balancing in this case ? Am I missing something here ?

Thanks & regards,
Lokesh

[Willem Grooters]

ian,

You confuse me.

Don't use cluster address as the node who recives connections to the cluster address only changes when no connections are active

When to be read as:

Don't use cluster address as the node who recives connections to the cluster. Address only changes when no connections are active

In that case I don't see a reason why there would be a cluster alias in the first place. It's of no use if I first have to locate the node in that cluster that hosts the program I'm wanting to connect to.
That cannot be meaning, or am I mistaken?

(Your reply came in when I was typing mine)

Willem

Willem

[Jan van den Ende]

Willem:

we use (have to use) Tru64 DNS, which we cannot manage, we can just request for settings.

>>In a clustered environment, you should have 1 name/address pair more than you have nodes: One for each node + the cluster alias one.<<

Well, nearly correct. If you have redundant network cards, you need an address for each CARD + a cluster alias.
The big fun is, DNS knows your cluster alias name, and of course the corresponding address. In the DNS this is resolved into the MAC address of the current Cluster Impersonator. That's fine, but how does the DNS know? Eighter by assigning it in a round-robin way ( the choice of our Unix people) or by periodically updating by Metric-&-Loadbroker. That requires the right for unattended update, and they are not liking that. As far as I know (please educate me if I miss something, we would be really glad with it) VMS can only apply the cluster alias if it may update the DNS.
And all this still does nothing to prevent the network routers chaching the MAC address to the cluster alias name.
Of course, task-to-task links stay alive for the duration of the communication; as long as there is a link that is used, and not reconfigured.
For outgoing messages (non task-to-task) eg, mail, or any application that uses a messaging communication, nobody has been able yet to tell me how (in DECnet terminology) to "enable outgoing cluster alias". A mail reply should arrive 'somewhere' at any than available cluster node, and not hard linked at the node that happened to be yesterday's sending node that gave its address to the message(which might be not-up for maintenance, or even replacement?)


Jan