The MultiNet master server maintains the lock that says which system in
the cluster is currently offering the alias address. The command file
that is used to restart the master server releases ownership of the
alias and lock, which allows another system to obtain it. When the
master server has restarted it should be queued for ownership of the
lock. It is necessary to tell the master server of the system that
currently maintains the cluster alias to release it so that the cluster
alias can roll over to another system.
Was there another cluster member that could have possibly taken over the
alias? The cluster alias was originally designed for UDP traffic.
Changes were made such that most TCP traffic can now work on it as
customers insisted on using it for TCP traffic even when told that it
wasn't designed for it and that either DNS load balancing or round-robin
DNS would be a better choice. BIND 9 has caused a number of
difficulties for customers that are using DNS load balancing and work is
being done to address these issues.
-----Original Message-----
From: Marty Kuhrt [mailto:***@spamloop.kuhrt.net]
Sent: Tuesday, August 19, 2008 6:38 PM
To: info-***@process.com
Subject: Re: Cluster Aliases goes away
Post by Richard Whalen49 is EADDRNOTAVAIL, which means that it could not assign the
requested
Post by Richard Whalenaddress. MultiNet 5.n uses the routing tables to determine which
interface should get the cluster alias assigned to it; if it can not
find an interface that has the proper routing for the desired address,
then it will not assign it to an interface.
Why would you think restarting the MU server to roll the SMTP logfile on
a single node (for now) cluster cause this failure? How can it be
prevented in the future?
Post by Richard Whalen-----Original Message-----
Sent: Friday, August 08, 2008 4:44 PM
Subject: Re: Cluster Aliases goes away
Marty Kuhrt presented these words - circa 8/7/08 10:15 PM->
Post by Marty Kuhrtlook at errno.h (I don't recall where the bloody thing is stored
anymore)
EADDRNOTAVAIL - can't assign requested address.
Patrick
Marty Kuhrt presented these words - circa 8/6/08 2:34 PM->
Post by Marty KuhrtHad an interesting problem pop up today. I restarted the Multinet
server and the cluster aliases stopped working.
Process Software MultiNet V5.2 Rev A-X, AlphaServer DS10L 466 MHz,
OpenVMS AXP V7.3-2
All the patches up to around 31-MAR, the last reboot.
%%%%%%%%%%% OPCOM 6-AUG-2008 14:00:44.94 %%%%%%%%%%%
Message from user MARTY on BLUE
MultiNet Server: Cluster Alias: Failed to register alias
172.17.17.238 status 49
Error 49? An odd error number? I tried to set the terminal width
to 132, thinking a digit or two got chomped. Nope.
Eventually I rebooted (GASP) and it works fine now.
So what is an error 49?
OK, but what does _that_ mean? All of a sudden .238 stopped
responding which made the name servers, web servers, time servers, and
anyone else using that alias, stop responding. Anything that was
looking to .238 to respond started chirping "host down".
Can't assign address, why?
And just an FYI, I restarted the Multinet server to roll the smtp.log
file (to do some smtp debugging). Seems you have to rename the log
file and then restart the main MU server to get it to stop writing the
old log file.
It could be for many reasons: 1) failed to get the cluster lock setup,
the address is invalid for your configuration (not sure what your subnet
mask, node IP, etc are set too), 2) This address might already be in use
on another node? 3) Arp cache was corrupted causing the IP address to
fail validation?
I have not played on a MulitNet system for close to 10 years now, so I
apologize for not being more helpful. (but I did help develop and
maintain it for close to
8 years)
Good luck,
Patrick Mahan
nee Window Washer