Sync time with AD

5,150 views
Skip to first unread message

scott

unread,
Oct 24, 2012, 6:39:57 PM10/24/12
to isilon-u...@googlegroups.com
I have an Isilon cluster joined to Active Directory.  It was my understanding this automatically becomes my cluster's time source as well, but this afternoon I noticed my cluster time had drifted a few minutes from AD time.  

mbisilon02-1# isi auth ads time
Wed Oct 24 15:40:51 2012
mbisilon02-1# date
Wed Oct 24 15:38:53 PDT 2012

Is there something extra I need to do to keep the clocks synced? 

-Scott Hunter

Blake Golliher

unread,
Oct 24, 2012, 7:24:11 PM10/24/12
to isilon-u...@googlegroups.com
You could add an ntp server with isi_ntp_config

-Blake

Greg Jones

unread,
Oct 24, 2012, 8:46:28 PM10/24/12
to isilon-u...@googlegroups.com
Scott,

I'm working through this exact issue with Isilon. They recommend that we don't use both NTP and AD for time services and suggested that we only use AD.

After making the change, we noticed our time was off by 15 seconds within a week. We contacted support and asked them why the time was off. This is what we were told: If you use AD for time services, Isilon nodes will not adjust their time unless they're a minute or more off. This sound unreasonable to me, but we are following up to see if we can adjust the one minute mark or go back to using NTP.

I'll keep the group posted on how we resolve this.

Greg

Richard Kunert

unread,
Oct 24, 2012, 8:53:14 PM10/24/12
to isilon-u...@googlegroups.com
We use NTP but the NTP servers are our domain controllers. Haven't had any problems, time is right on.

Richard

Jerry Uanino

unread,
Oct 24, 2012, 9:50:05 PM10/24/12
to isilon-u...@googlegroups.com
We use NTP, but our AD servers are time synced to our NTP servers as well.

David Bell

unread,
Oct 25, 2012, 3:43:32 AM10/25/12
to isilon-u...@googlegroups.com

We had the same dilema when setting up our clusters. Isilon support insists you should not run AD and NTP together, but when we started looking at the "smbtime" scripts on the Isilon that are responsible for time sync against AD we decided we had to use NTP. If I remember correctly it only rarely (ever N hours or so) checked to make sure time was accurate, and then only did a change if it was a minute or so out, and then used a time-sensitive protocol to sync the time. 

As such we've been running with NTP ever since (and our AD uses the same NTP servers). So far no problems - and time has remained in sync!

Cheers,

David

Donald Coleman

unread,
Oct 25, 2012, 9:05:46 AM10/25/12
to isilon-u...@googlegroups.com, isilon-u...@googlegroups.com
Scott,
If you plan to stay with smbtime it is a cron job which checks time against your ad server every 6 hours. There are two way you can go with this 1. Depending on your version of OneFS you can adjust the cron to run every 2 hours or even every hour for more accuracy. The Job sits in the /etc/crontab if I remember correct. 2) you can create your own cron job to run the command;
# isi_for_array -s "isi auth ads time --sync --force"
To force a sync at regular intervals. The other option is as everyone has pointed out to use ntp which depending on various factors of your environment can be more accurate. Again use one or the other never both.

Donald
Sent from my iPhone

gtjones

unread,
Oct 29, 2012, 12:37:27 PM10/29/12
to isilon-u...@googlegroups.com
We could never get a clear answer out of Isilon why the time was so far off when using smbtime or why you should use smbtime instead of NTP. My colleague and I are speculating that earlier versions of Isilon had problems (we're running 6.5.5.7) running NTP and smbtime together. We decided to go back to NTP time because of the inaccuracy of smbtime. We noticed that when you configure the cluster for NTP using the GUI, the crontab entry for smbtime is commented out.

To see the system cron jobs: cat /etc/crontab
The smbtime script is located at /etc/mcp/override/crontab.smbtime which calls /etc/mcp/scripts/smbtime_cron.py

Greg


On Wednesday, October 24, 2012 8:46:29 PM UTC-4, gtjones wrote:
Scott,

I'm working through this exact issue with Isilon. They recommend that we don't use both NTP and AD for time services and suggested that we only use AD.

After making the change, we noticed our time was off by 15 seconds within a week. We contacted support and asked them why the time was off. This is what we were told: If you use AD for time services, Isilon nodes will not adjust their time unless they're a minute or more off. This sound unreasonable to me, but we are following up to see if we can adjust the one minute mark or go back to using NTP.

I'll keep the group posted on how we resolve this.

Greg

Andrew Stack

unread,
Feb 8, 2013, 2:20:02 PM2/8/13
to isilon-u...@googlegroups.com
I have gone down this rabbit hole.  The bottom line is that using AD for keeping time on your cluster is a horrible solution.  Even if you ratchet down the time diff on querying AD you still will encounter drift.  Why?  Simply put - The clocks on the Isilon nodes are utter crap.  Only NTP keeps your cluster in sync with Atomic Time at an acceptable level for time sensitive apps.  Why?  Because NTP queries the time source every 64 seconds and propagates this value down to it's other nodes over IB.  This affectively negates the drift issue.

There are some tricks to configuring NTP.  I have written a guide which you're welcome to use.  I also recommend you read up on Isilon's Support Site by querying NTP.

Real World Configuration - Step by Step

Step 1

In GUI go to Cluster -> Cluster Settings - > NTP and enter in the NTP servers that Genentech uses:


Step 2 

NTP service uses 3 'chimmer' nodes on each cluster to synchronize time with NTP servers.  These in turn do a comparison (self check) among each other and determine the time to push to the rest of the cluster.   The 3 nodes must be connected to the network and none should be node 1.  

Step 3

Open up a shell to the cluster - In this case nas-vv-is3.  Determine which nodes you want to use.  In this case we will be using 9-12.  Run the following command to Exclude other nodes from pulling time from NTP servers.

nas-vv-is3-9# isi_ntp_config add exclude 1 2 3 4 5 6 7 8 9
Nodes excluded from contacting external NTP servers:

nas-vv-is3-9# 

Step 3 

Verify the overall settings:

nas-vv-is3-9# isi_ntp_config list
NTP Server Setting:

Nodes excluded from contacting external NTP servers:


NTP Auth Keyfile:
No Keyfile is configured.
nas-vv-is3-9# 

Step 4 

Stop and start the ntpd service which will refresh the time and sync time with NTP source.

nas-vv-is3-9# isi_for_array -s "killall ntpd && ntpdate ntp1.gene.com"      
nas-vv-is3-1:  13 Dec 15:41:08 ntpdate[41359]: step time server 128.137.1.1 offset 1034.675395 sec
nas-vv-is3-2:  13 Dec 15:41:08 ntpdate[49625]: step time server 128.137.1.1 offset 1034.644325 sec
nas-vv-is3-3:  13 Dec 15:41:09 ntpdate[54635]: step time server 128.137.1.1 offset 1034.642789 sec
nas-vv-is3-4:  13 Dec 15:41:09 ntpdate[47364]: step time server 128.137.1.1 offset 1034.577387 sec
nas-vv-is3-5:  13 Dec 15:41:10 ntpdate[51548]: step time server 128.137.1.1 offset 1034.670115 sec
nas-vv-is3-6:  13 Dec 15:41:10 ntpdate[59781]: step time server 128.137.1.1 offset 1034.647192 sec
nas-vv-is3-7:  13 Dec 15:41:10 ntpdate[48438]: step time server 128.137.1.1 offset 1034.648501 sec
nas-vv-is3-8:  13 Dec 15:41:11 ntpdate[48500]: step time server 128.137.1.1 offset 1034.660797 sec
nas-vv-is3-9:  13 Dec 15:41:11 ntpdate[49939]: step time server 128.137.1.1 offset 1034.673386 sec
nas-vv-is3-10: 13 Dec 15:41:12 ntpdate[63791]: step time server 128.137.1.1 offset 1033.560341 sec
nas-vv-is3-11: 13 Dec 15:41:12 ntpdate[57463]: step time server 128.137.1.1 offset 1034.668393 sec
nas-vv-is3-12: 13 Dec 15:41:13 ntpdate[55012]: step time server 128.137.1.1 offset 1034.581385 sec
nas-vv-is3-9# 

Step 5

Verify that the time is now accurate by comparing it to a known good clock 


and then running (there should be no more than a second delay between node responses).

nas-vv-is3-9# isi_for_array -s date
nas-vv-is3-1:  Thu Dec 13 15:47:31 PST 2012
nas-vv-is3-2:  Thu Dec 13 15:47:31 PST 2012
nas-vv-is3-3:  Thu Dec 13 15:47:32 PST 2012
nas-vv-is3-4:  Thu Dec 13 15:47:32 PST 2012
nas-vv-is3-5:  Thu Dec 13 15:47:32 PST 2012
nas-vv-is3-6:  Thu Dec 13 15:47:33 PST 2012
nas-vv-is3-7:  Thu Dec 13 15:47:33 PST 2012
nas-vv-is3-8:  Thu Dec 13 15:47:33 PST 2012
nas-vv-is3-9:  Thu Dec 13 15:47:33 PST 2012
nas-vv-is3-10: Thu Dec 13 15:47:34 PST 2012
nas-vv-is3-11: Thu Dec 13 15:47:34 PST 2012
nas-vv-is3-12: Thu Dec 13 15:47:34 PST 2012
nas-vv-is3-9# 

Step 6

Lastly you can dig deep by looking at the ntpq command which is explained here:  ntpq output explained


ntpq output explained

Here is an example of output from a useful command ntpq which essentially tells you everything you need to know about isilon ntp polling.

nas-rwc-is5-24# isi_for_array -s "ntpq -p -n"
nas-rwc-is5-1:       remote           refid      st t when poll reach   delay   offset  jitter
nas-rwc-is5-1:  ==============================================================================
nas-rwc-is5-1:  *192.168.10.22   128.137.1.1      4 u    -   64  177    0.082  395.650  12.236
nas-rwc-is5-1:  +192.168.10.23   128.137.1.1      4 u    -   64   77    0.063  434.358   2.116
nas-rwc-is5-1:   192.168.10.24   128.137.1.3      4 u   29   64  237    0.083  447.656 253.185
nas-rwc-is5-2:       remote           refid      st t when poll reach   delay   offset  jitter
nas-rwc-is5-2:  ==============================================================================
nas-rwc-is5-2:  *192.168.10.22   128.137.1.1      4 u   35   64   77    0.064  433.146   0.651
nas-rwc-is5-2:  +192.168.10.23   128.137.1.1      4 u   30   64   37    0.069  461.890   7.909
nas-rwc-is5-2:   192.168.10.24   128.137.1.3      4 u   28   64  237    0.073  488.201 270.177
nas-rwc-is5-3:       remote           refid      st t when poll reach   delay   offset  jitter
nas-rwc-is5-3:  ==============================================================================
nas-rwc-is5-3:  *192.168.10.22   128.137.1.1      4 u   21   64   77    0.064  416.569   0.730
nas-rwc-is5-3:  +192.168.10.23   128.137.1.1      4 u    2   64   77    0.060  456.831  10.222
nas-rwc-is5-3:   192.168.10.24   128.137.1.3      4 u    9   64  237    0.071  471.196 262.318
nas-rwc-is5-4:       remote           refid      st t when poll reach   delay   offset  jitter
nas-rwc-is5-4:  ============================================================================== 

Columns Defined:

remote: peers specified in the ntp.conf file
* = current time source
# = source selected, distance exceeds maximum value
o = source selected, Pulse Per Second (PPS) used
+ = source selected, included in final set
x = source false ticker
. = source selected from end of candidate list
- = source discarded by cluster algorithm
blank = source discarded high stratum, failed sanity

refid: remote source’s synchronization source

stratum: stratum level of the source

t: types available
l = local (such as a GPS, WWVB)
u = unicast (most common)
m = multicast
b = broadcast
- = netaddr

when: number of seconds passed since last response

poll: polling interval, in seconds, for source

reach: indicates success/failure to reach source, 377 all attempts successful

delay: indicates the roundtrip time, in milliseconds, to receive a reply

offset: indicates the time difference, in milliseconds, between the client server and source

disp/jitter: indicates the difference, in milliseconds, between two samples
Reply all
Reply to author
Forward
0 new messages