topic Re: NTP sync issues in Operating System - OpenVMS

NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 09:16:24 GMT

Hello all, I have been subscribed to these forums for quite a while through different jobs and enjoy using the questions to test myself. Now I have an issue I can not seem to figure out. I recently started a new position with 2 servers clustered together, it appears only for administration reasons. Note: I have never administered a cluster before.

The players (please don't laugh):
DIGITAL TCP/IP Services for OpenVMS VAX Version V5.0A on a VAX 7000-630 running OpenVMS V7.1 does batch processing.

DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A on a AlphaServer 4100 5/466 4MB running OpenVMS V7.1 has several Oracle databases.

When I arrived, there was a note that the time on these servers needed to be checked every night and set 2-3 seconds ahead of the Windows system clock. Being the VMS bigot I am, that did not sit right with me and I investigated. It appears if the time was the same it would not be a problem, but if the VMS systems get behind, a number of the processes have issues (data not loaded into database until the time stamp).

I talked to them about NTP and they said they were told by the previous administrators that it could not be done. Anyway, I setup NTP on both systems. It works fine on the VAX, but the Alpha keeps drifting behind and looking into it, it appears not to be using the config file.

1. In a cluster environment, is there a way for one member to use NTP to get the time, then sync the entire cluster (like set time/cluster does) to that time? Seems like there should be, but I am not puting the right searches together.

2. If there is not, why would the Alpha appear not to using the config files? Attached is the ntptrace from both servers which are configured identically. I just added the peer statements recently when I found the times were off between the systems, then noticed the Alpha seems not to be using the config (notice the "***Server reports data not found" error. Please direct me if there is any other information you would like.

Thank you in advance

Re: NTP sync issues

Wim Van den Wyngaert — Wed, 03 Oct 2007 09:30:10 GMT

I don't have NTP but did you check SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP_RUN.LOG ? Or the operator log file ? Are the nodes used defined in the host table ? Config file protection violation ?

Wim

Re: NTP sync issues

EdgarZamora — Wed, 03 Oct 2007 09:51:37 GMT

On the Alpha, does the system know dc1, dc2 and/or noah (are those ip addresses correct?)
Is your DNS working correctly?

Re: NTP sync issues

EdgarZamora — Wed, 03 Oct 2007 10:07:37 GMT

Another thing I thought of, did you restart ntp after you updated the config file? You need to shut it down with SYS$STARTUP:TCPIP$NTP_SHUTDOWN then start it with SYS$STARTUP:TCPIP$NTP_STARTUP

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 10:28:29 GMT

All versions of: SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP_RUN.LOG on both systems contain only the line:
$ set noverify

Both systems have similiar SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.LOG file entries:
3 Oct 09:26:30 ntpd version = 3-5.91
3 Oct 09:26:30 tickadj = 83, tick = 833, tvu_maxslew = 99517, est. hz = 1200
3 Oct 09:26:30 precision = 833 usec
3 Oct 09:26:30 read drift of 0.000 from SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT
3 Oct 09:26:30 Parent - Starting Host Name Resolver

File protection/privs are the same or more leinent on the Alpha.

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 10:42:33 GMT

DNS is working and NTP was shutdown and started several times (even prior to my post).

BTW... Thanks all for the replies.

Re: NTP sync issues

Wim Van den Wyngaert — Wed, 03 Oct 2007 10:53:01 GMT

I've read that it may take 30 minutes before they behave normal ... did you test it after 30 minutes uptime ?

Wim

Re: NTP sync issues

Robert_Boyd — Wed, 03 Oct 2007 10:55:23 GMT

Steven,

Did you verify that you can do nslookups and pings to the ntp servers from the Alpha? It looks as if there is a connectivity problem based on your ntptrace output.

Is it possible that there is any blocking of ntp between the Alpha and the ntp servers by a firewall?

I wasn't sure from your last post if you resolved the problem or not.

Robert

Re: NTP sync issues

Robert_Boyd — Wed, 03 Oct 2007 10:57:44 GMT

Also, did you try NTPQ to list what it's thinking about each of the servers and peers?

Whenever I'm having issues with my ntp.conf I use NTPQ quite often to track what's happening.

Robert

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 11:03:57 GMT

Still have the issue, all servers reachable with TRACEROUTE. All servers on the same network, so no filrwall interceding.

SYSMGR-on-MOSES->tracert dc1
traceroute to DC1 (192.168.4.1), 30 hops max, 38 byte packets
1 DC1 (192.168.4.1) 0 ms 1 ms 0 ms
SYSMGR-on-MOSES->tracert dc2
traceroute to DC2 (192.168.4.2), 30 hops max, 38 byte packets
1 DC2 (192.168.4.2) 1 ms 0 ms 0 ms
SYSMGR-on-MOSES->tracert noah
traceroute to NOAH (192.168.4.17), 30 hops max, 38 byte packets
1 NOAH (192.168.4.17) 1 ms 1 ms 1 ms
SYSMGR-on-MOSES->

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 11:09:01 GMT

NTPQ is one of the reasons I think it is not reading the config files: NOAH is the VAx, MOSES is the Alpha with the issue.

CSW-on-NOAH->ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
*DC1 timekeeper.isi. 2 u 11 64 377 0.00 -14.224 9.14
+DC2 DC1 3 u 14 64 377 0.00 -27.298 8.33
MOSES 0.0.0.0 16 u 38 1024 0 0.00 0.000 16000.0
CSW-on-NOAH->ntptrace
LOCALHOST: stratum 3, offset 0.005000, synch distance 0.19643
DC1: stratum 2, offset -0.008523, synch distance 0.15201
timekeeper.isi.edu: stratum 1, offset -0.012773, synch distance 0.00000, refid '
GPS'
CSW-on-NOAH->

SYSMGR-on-MOSES->ntpq -p
No association ID's returned
SYSMGR-on-MOSES->ntptrace
LOCALHOST: stratum 16, offset -0.000416, synch distance 1.11162
0.0.0.0: *Timeout*
SYSMGR-on-MOSES->

Re: NTP sync issues

Bill Hall — Wed, 03 Oct 2007 11:16:16 GMT

Steven,

Are you sure the Alpha's conf file can be read by the TCPIP$NTP account? Do you have a homogeneous cluster?

Bill

Re: NTP sync issues

Hoff — Wed, 03 Oct 2007 11:18:50 GMT

Does the Windows box have a real NTP server, or does it have the (simple) SNTP server? Most Windows boxes I've dealt with use an SNTP infrastructure, and NTP (on any platform) doesn't like to sync to SNTP. SNTP can sync to NTP, but the other way doesn't work so well. (There was a very scathing posting from an NTP expert a while back, blasting the problems with W32TIME service; the versions of SNTP found prior to Windows XP were very flaky. At best. More recently, the synch does occur though within the SNTP limits, which is some seconds of skew-age, IIRC. NTP is tighter.)

There exists a list of public NTP servers here:
http://support.ntp.org/bin/view/Servers/WebHome

Check the local (SYS$SPECIFIC:) roots for differences in the ntp.conf file.

In a cluster, you can (also) use SET TIME/CLUSTER (which was undocumented for a while, but it's back) to zonk the time cluster-wide. That written, the usual approach is to run NTP across the hosts.

In the immediate case, the first thing I'd check is the TCP/IP Services version. V5.0A is old and pretty crufty. If you can't upgrade that version to a more current one, do apply the most current ECO for V5.0A.

Patch (ECO) FAQ:
http://64.223.189.234/node/348

Why the Alpha isn't picking up the file implies that NTP client is shut down, or is not finding the ntp.conf file you think it is, it cannot connect to the time provider, or the ntpd daemon is malfunctioning.

Longer-duration information on the run log would be interesting. It can take a very long time for the serves to synchronize. At least a couple of hours run, and mayhap a day.

On the server line, I'd probably add "minpoll 12 maxpoll 17" (very conservative, 6 and 12 is significantly more aggressive), or "burst minpoll 12 maxpoll 17", or iburst onto the time server definition lines in your ntp.conf file.

I don't know off-hand if V5.0A has an ntp which support burst or iburst. (The current stuff does have this.)

And for a question you might get to: NTP doesn't do daylight saving time (DST), and you're too far back (or not far enough back) to have the most recent timezone definitions. You'll be rolling your own update here, if you need to track the US changes. OpenVMS TZ and DST details are here:

http://64.223.189.234/node/72

Stephen Hoffman
HoffmanLabs LLC

Re: NTP sync issues

EdgarZamora — Wed, 03 Oct 2007 12:22:38 GMT

A couple of suggestions:

Increase your log level by defining a systemwide logical TCPIP$NTP_LOG_LEVEL 6 then restarting ntp. That should give you more information in the log file.

Secondly, the config file comment mentions that the hostnames should be fully qualified. You might want to try that just to get that out of the way (I know it works on the VAX with just using the alias but you never know). Change the dc1 and dc2 to fully qualified names.

Good luck and please post the log file results.

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 13:36:13 GMT

Thank you all... It appears to be the alias as mentioned in the last post. All these hosts are in the local hosts table on the server, but entering the IP address seems to have gotten it working. I did raise the LOG_LEVEL to keep a closer eye on it for a while.

To answer the other questions...
DC1 and DC2 are Win2003 servers which are allowed out to the internet (not my decision).
I was trying to get away from the manual $ SET TIME/CLUSTER needed every night.
I know these are old versions, but the config is frozen, I'm told because of the COBOL version being used and an unwillingness to recompile all the code. If I could not get it running, it was going to need to stay manual :(
DST change is handled via a batch queue job.

Again, thanks.

Re: NTP sync issues

Steven P Underwood — Wed, 03 Oct 2007 13:37:02 GMT

Closing thread, Details in the previous post.

Re: NTP sync issues

EdgarZamora — Wed, 03 Oct 2007 13:38:43 GMT

Make sure you turn off or lower the log level as the log file will get quite large.