Operating System - OpenVMS
1751971 Members
4657 Online
108783 Solutions
New Discussion юеВ

Re: Virtual IP in VMS cluster?

 
SOLVED
Go to solution
Henrik Karlsson
Occasional Contributor

Virtual IP in VMS cluster?

Hi

TCP/IP services on OpenVMS support failover Ip's i.e. in case of a network card breaks, but what about VIPs (Virtual IP's)?

-> If it works on VMS, can the same IP address be defined on multiple servers BUT only "plumbed" (turned on, visible to the network) on one of them. In a failover scripts automatically attempt to "unplumb" the IP address on the failed node and "plumb" the IP address on the standby node.

This all in order to have an instance of an application in a cluster (client communication with server). And provide a fail-over solution that a application-client to be automatically directed to other instance on a server node if problems with client-application or the HW problem on the client server problems prevent normal operation (client to server).

Thanks in advance
Henrik
5 REPLIES 5
Wim Van den Wyngaert
Honored Contributor

Re: Virtual IP in VMS cluster?

Yes.

You can define an alias (or multiple aliases) on any machine (while using IP) and do :

ifconfig WE0 alias q.x.y.z
(-alias to remove)

and ifconfig -a to list

Wim
Wim
Andy Bustamante
Honored Contributor
Solution

Re: Virtual IP in VMS cluster?

I'm not sure I see the difference between a virtual IP and the FAILsafe (or cluster alias address in available in earlier versions of TCPIP). Within a cluster, you can assign the same address to multiple NICs on multiple nodes.

See this write up on the OpenVMS Technical Journal http://h71000.www7.hp.com/openvms/journal/v2/articles/tcpip.html for an write up of the options available and excellent comparision. TCPIP won't know about an application failure, but you can create a batch job to monitor a node and fail an interface in the event of application issues.

Welcome to VMS Forum,


Andy
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Jan van den Ende
Honored Contributor

Re: Virtual IP in VMS cluster?

Henrik,

Andy already pointed to the cluster alias.
The workings of that are such: the first device (in time) to be assigned this name, will become the CLUSTER IMPERSONATOR, and will broadcast its name and address to point to that device. Should the device stop being reachable (by device or node going out of service), then the next device given the cluster alias becomes the IMPERSONATOR.
Fully automagically. But NO load sharing, and therefor not very popular on most VMS sites.

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: Virtual IP in VMS cluster?

If your application is not cluster ware (as is e.g. Sybase), you can forget about cluster aliases and so. Then you can better assign the normal alias during server startup (and have an address for each db server so you can move them independently).

Wim
Wim
Sebastian Bazley
Regular Advisor

Re: Virtual IP in VMS cluster?

I work with Henrik, and have started experimenting with IP aliases (thanks for the documentation pointers!)

TCPIP SET INTERFACE and ifconfig can be used to create/disable aliases on two nodes, and the IP address switches nicely between them, at least as far as an external client is concerned.

However the server application needs to be running on both nodes in the cluster, and needs to only accept connections addressed to the virtual IP address.

For example, assume we have:

Node A; IP 1.2.3.1; VIP 1.2.3.4; server1
Node B; IP 1.2.3.2; VIP 1.2.3.4; server2

If the VIP is currently assigned to Node A, then server1 can successfully listen on 1.2.3.4 port 1234

However server2 is not able to listen on 1.2.3.4:1234.

Of course both servers can listen on port 1234 if they accept connections on all IP addresses, but then they will accept direct connections to the node.

Is there any solution to this?
Either:
- some way of disabling the VIP externally, but still allowing a local server to wait on it; or
- the server waits for connections to any host, and then somehow establishes which host name was used by the remote client. It could then reject connections that were made to the wrong IP address.