Synchronizing Time On The File Modules - IBM Storwize V7000 Unified Problem Determination Manual

Procedure
1. Log in as a CLI user to the appropriate file module using the service IP.
2. Review the log file /var/adm/ras/mmfs.log.latest. The details in the log are

Synchronizing time on the file modules

Use this information to synchronize the time on all Storwize V7000 Unified file
module.
About this task
Synchronizing the time on all the file module can help as you start troubleshooting
because the timestamps on the logs then indicate whether you have concurrent,
legitimate results.
You can ensure that the Storwize V7000 Unified, Active Directory (AD), Kerberos,
and other servers are synchronized with a valid Network Time Protocol (NTP)
source. This is important both for log checking and because if the cluster falls
behind the correct time, Kerberos tickets, for example, can expire and then no one
can access the cluster. For the Storwize V7000 Unified file module, the ntpq –p
command shows you which server is used for synchronization and any peers and
a set of data about their status. The * in the first column indicates that the local
clock is used for synchronization.
# ntpq -p
==============================================================================
*machine.domain.i 9.19.0.220 2 u 269 1024 377
+machine.domain.i 9.19.0.220 2 u 992 1024 377
As NTP is drift based, large time differences can prevent NTP from synchronizing,
or cause synchronization to take a long time. It can be helpful to synchronize time
manually once and to verify that the time is picked up correctly afterward. Use the
separate commands of service ntpd stop, ntpdate your IP, and service ntpd
start. The following example shows the sequence:
[root@domain.node ~]# service ntpd stop
Shutting down ntpd:
[root@domain.node ~]# ntpdate 9.19.0.220
14 Jan 12:06:46 ntpdate[25360]: adjust time server 9.19.0.220 offset 0.003277 sec
[root@domain.node ~]# service ntpd start
Starting ntpd:
[root@domain.node ~]#
After the time on all of the servers is synchronized, you can verify that the logs
apply to your troubleshooting situation.
listed from oldest to newest, so you can find the latest GPFS information at the
end.
Note: The GPFS log is a complex raw log file for GPFS. If you do not
understand the conditions listed in the log, contact IBM support for assistance.
remote refid
LOCAL(0) .LOCL.
st t when poll reach delay
0.659
1.380
10 l 50 64 377
offset jitter
-0.115 0.164
0.337 0.564
0.000 0.000 0.001
[ OK ]
[ OK ]
Chapter 4. File module
201