Operating System - OpenVMS
1752809 Members
6097 Online
108789 Solutions
New Discussion юеВ

a unknown problem - oh~ urgent man~

 
SOLVED
Go to solution
Davor_7
Regular Advisor

a unknown problem - oh~ urgent man~

one cluster with 2 Alpha nodes
node1: a1.company.com 1.1.1.9
node2: a2.company.com 1.1.1.10
cluster virtual name: a.company.com 1.1.1.8
(no DNS balance function)

when user telnet connect to a.company.com
he will be loaded to a1.company.com(1.1.1.9) all the time.
even the user/data processes and rates in node2 are much higher than those in node1. you will still be loaded to node1.
so strange...

anybody could tell me what kind of problem it was? DNS or some settings in cluster ?


thanks!
urgent~
8 REPLIES 8
Uwe Zessin
Honored Contributor

Re: a unknown problem - oh~ urgent man~

If this is the old "UCX cluster alias", then there is no way around it. It has always been working that way.

An IP address can only be tied to one interface at a time and the 'cluster impersonator' will 'lock' the IP address to this interface/node as long as there are connections.
.
Willem Grooters
Honored Contributor

Re: a unknown problem - oh~ urgent man~

Alas.
TCPIP is _NOT_ cluster-aware. There will be one node be configured as "node impersonator"; typically the one that starts first, and the address will only pass to the other machine when that node fails/loses the NIC.
If you have to stick to TCPIP, your only alternative is an external DNS, and the METRIC and LOADBALANCE services on VMS that will update that DNS server according load determination on the VMS boxes.
The right thing, IMHO, is to use DECNet which is cluster-aware by itself and has load-balancing facilities built-in...(AND, when properly set up, is fail-safe within seconds - keeping sessions alive)
Willem Grooters
OpenVMS Developer & System Manager
Kris Clippeleyr
Honored Contributor

Re: a unknown problem - oh~ urgent man~

Hi,

As Uwe stated, the cluster impersonator is always assigned to one of the cluster members (and it will stay there, unless that node leaves the cluster).
That principle has not changed, not even with the newest TCP/IP kit for VMS.

Regards,
Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Antoniov.
Honored Contributor

Re: a unknown problem - oh~ urgent man~

This is a tcp/ip limitation.
Frame to host are sended to physical NIC (Network Interface Card) by MAC (Medium Access Control) avaiable by arp. To change physicall network, all arp table in network must be changed and this require some minutes.
DecNet instead, setup a virtual MAC on NIC so it's quick in change but this limit to only 1 NIC per host.

Antonio Vigliotti
Antonio Maria Vigliotti
Uwe Zessin
Honored Contributor

Re: a unknown problem - oh~ urgent man~

I think that's not strictly true. You can have multiple NICs, but due to the change of the MAC address on all of them, they need to be separated by a router.

While I don't remember I have ever run a system with multiple NICs and DECnet IV, I know I have run nodes with multiple circuits and different hardware interfaces (Ethernet+CI, Ethernet+X.25, Ethernet+DDCMP).

Now, successfull routing without a routing license - that's a different topic, but an end-node can failover between two circuits.
.
Davor_7
Regular Advisor

Re: a unknown problem - oh~ urgent man~

Kris/all
you mean that if we connect to cluster via UCX(even if DECnet is available but we donot use it to connect), it's certain that we will connect to node1(like this example above). and this setting cannot be changed, right?

another question is that:
is this cluster impersonator created when the cluster having been built ? and it cannot be reversible?

if it's true, when we shutdown the node 1, the connection to a.company.com cannot work further more, right ?

thanks all!
i wanna confirm it , there's a big change next week :)
Willem Grooters
Honored Contributor
Solution

Re: a unknown problem - oh~ urgent man~



Right. Once a node is set as cluster impersonator, it will be so until it is shut down (shot down?)



The first node that holds this address as cluster alias in it's configuration will get it, and it will stay there, until the node is shutdown. So if node2 was to be booted first, that would be the impersonator.



Given node1 boots first:
If Node2 has this cluster alias set in it's configuration, it will signal the address is in use at node1`- and will be latent (present but not used) on node2. When node1 is shut down, node2 will signal that and take over the cluster address. If node1 is booted afterwards, the cluster IP address will stay at node2.



Having said above, it may be clear that in that situation, node2 will become holder of the cluster IP address and therefore will service new requests to a.company.com. It will keep doing so until it is shut down.

Willem
Willem Grooters
OpenVMS Developer & System Manager
Davor_7
Regular Advisor

Re: a unknown problem - oh~ urgent man~

Willem
nice explanation!

thanks to you and thanks to all

very clear :)