加载中…
个人资料
Albert小徐
Albert小徐
  • 博客等级:
  • 博客积分:0
  • 博客访问:25,741
  • 关注人气:1
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

Component CRS Title Cluster Time Synchronization Service CTSS

(2013-08-02 09:59:43)
标签:

it

分类: oracle

Component CRS Title Cluster Time Synchronization ServiceCTSS Version 11.2.0 Problem 

What is Cluster Time Synchronization Service CTSS ?

The Cluster Time Synchronization Service (CTSS) is one of the newprocesses in the Oracle Clustware 11gR2 layer the CTSS is installed duringthe GRID infrastructure installation.

The Daemon is responsible for the time management within the cluster. Makingsure each node in the cluster is using the same time. But before doing this theCTSS will first determine if Network Time Protocol (NTP) daemon is running inthe system. If this is not the case CTSS will run in active mode and performthe same task as the NTP daemon. If NTP daemon is running CTSS will be started,but in observer mode. The reason Oracle has implemented CTSS is to make suretime management within the cluster is performed. CTSS is Oracles implementationof the NTP daemons normally setup by the OS administrators

The first node in the cluster where CTSS is started will become the mastertime manager. Other CTSS daemons will communicate with the master CTSS andvalidate the time. If time difference between hosts in the cluster isdetected it will adjust the time, similar to the NTP daemon. CTSS will never goback into time. If time differences are taking place, it will be reported inthe alert.log. If the time difference between hosts during startup is too large( 1000 msec) Oracle Clusterware will not startup on the newly joined nodes. Analert will be written to the alert.log of the Oracle Clusterware home e.g. (/u01/app/11.2.0/grid/log//alert.log).You manually need to modify the time and start Oracle Clusterware in thatcase.


Solution


How does Oracle Clusterware decide to start CTSS in observe or active mode?

CTSS is process which runs as root on each node. As soon as OracleClusterware is started the CTSS daemon validates if the /etc/ntp.conf fileexists, if this file exists CTSS will run in observer mode. To determine if NTPdaemon is active cluster verification utility to get that part of heinformation. 

root 3582 11:24 00:00:12 /u01/app/11.2.0/grid/bin/octssd.binreboot

How to validate CTSS is running in observer mode or active mode?

Of course there is the alert.log on cluster level which will report the statusas well as the trace file. But the two easiest way is to use crsctl or cluvfufor this purpose. Crsctl will tell if CTSS is running and when the role isActive report the Offset in msec. Cluvfy will report much more information.Below are examples:

crsctl check ctss
cluvfy comp clocksync -n all
cluvfy comp clocksync -verbose

This will list the status of CTSS, if it is running and after that it willreport the current mode, active or observer. If the mode is active it will alsoreport if time synchronization issue exists. 

Sample output using CRSCTL:

[oracle@server1 log]$  /u01/app/11.2.0/grid/bin/crsctlcheck ctss
CRS-4701: The Cluster Time Synchronization Service is in Active mode.
CRS-4702: Offset (in msec): 0

Sample output CTSS in Observer mode but NTP not active:

[oracle@server1 server1]$ cluvfy comp clocksync
Verifying Clock Synchronization across the cluster nodes 

Checking if Clusterware is installed on all nodes...
Check of Clusterware install passed
Checking if CTSS Resource is running on all nodes...

CTSS resource check passed

Querying CTSS for time offset on all nodes...
Query of CTSS for time offset passed
Check CTSS state started...

CTSS is in Observer stateSwitchingover to clock synchronization checks using NTP

Starting Clock synchronization checks using NetworkTime Protocol(NTP)...
NTP Configuration file check started...
NTP Configuration file check passed 

Checking daemon liveness...
Liveness check failed for "ntpd"
Check failed on nodes: server1

PRVF-5415Check to see if NTP daemon is running failed
Clock synchronization check using Network Time Protocol(NTP) failed
PRVF-9652Cluster Time Synchronization Services checkfailed

Verification of Clock Synchronization across thecluster nodes was unsuccessful on all the specified nodes. 

Here we see the error messagesPRVF-5415followed byPRVF-9652,indicating there is an issue with NTP. This is correct as it wasnotconfigured.

Sample output CTSS in Observer mode but NTP not active in verbose mode:

[oracle@server1]$ cluvfy comp clocksync -verbose
Verifying Clock Synchronization across the cluster nodes
Checking if Clusterware is installed on all nodes...
Check of Clusterware install passed
Checking if CTSS Resource is running on all nodes...
Check: CTSS Resource running on all nodes

Node Name Status

------------------------------------------------------------
server1 passed
Result: CTSS resource check passed

Querying CTSS for time offset on all nodes...
Result: Query of CTSS for time offset passed
Check CTSS state started...
Check: CTSS state
Node Name State

------------------------------------------------------------

server1 Observer

CTSS is in Observer state. Switching over to clocksynchronization checks using NTP 
Starting Clock synchronization checks using NetworkTime Protocol(NTP)...

NTP Configuration file check started...
The NTP configuration file "/etc/ntp.conf" is available on all nodes
NTP Configuration file check passed

Checking daemon liveness...
Check: Liveness for "ntpd"
Node Name Running?

------------------------------------------------------------

server1 no
Result: Liveness check failed for "ntpd"
PRVF-5415 Check to see if NTP daemon is running failed
Result: Clock synchronization check using Network Time Protocol(NTP) failed
PRVF-9652 Cluster Time Synchronization Services check failed

Verification of Clock Synchronization across thecluster nodes was unsuccessful on all the specified nodes. 

Same result as above, although easier to see the State and that NTP is notactive.

Sample output when CTSS is in active mode using cluvfy:

[oracle@server1~]$ cluvfy comp clocksync -verbose

Verifying Clock Synchronization across the clusternodes 
Checking if Clusterware is installed on all nodes...
Check of Clusterware install passed

Checking if CTSS Resource is running on all nodes...
Check: CTSS Resource running on all nodes
NodeName                            Status
------------------------------------  ------------------------
 server1                              passed
Result: CTSS resource check passed

Querying CTSS for time offset on all nodes...
Result: Query of CTSS for time offset passed
Check CTSS state started...
Check: CTSS state
  NodeName                            State
  ------------------------------------  ------------------------
  server1                              Active
CTSS is in Active state. Proceeding with check of clock time offsets on allnodes...
Reference Time Offset Limit: 1000.0 msecs
Check: Reference Time Offset
  Node Name     TimeOffset              Status
  ------------  ------------------------ ------------------------
  server1      0.0                      passed

 

Time offset is within the specified limits on thefollowing set of nodes:
"[server1]"
Result: Check of clock time offsets passed

Oracle Cluster Time Synchronization Services checkpassed

Verification of Clock Synchronization across the cluster nodes was successful.
[oracle@server1 ~]$ 

Sample output when time offset is violated using cluvfy:

[oracle@server1 ~]$ cluvfy comp clocksync -n all
Verifying Clock Synchronization across the cluster nodes
Checking if Clusterware is installed on all nodes...
Check of Clusterware install passed
Checking if CTSS Resource is running on all nodes...

CTSS resource check passed
Querying CTSS for time offset on all nodes...
Query of CTSS for time offset passed

Check CTSS state started...
CTSS is in Active state. Proceeding with check of clock time offsets on allnodes...
PRVF-9661 Time offset is NOT within the specified limits on the followingnodes:"[server2]"

PRVF-9652 Cluster Time Synchronization Services check failed

Verification of Clock Synchronization across the cluster nodes wasunsuccessful.
Checks did not pass for the following node(s): server2

 [oracle@server2 ~]$ crsctl check ctss
CRS-4701: The Cluster Time Synchronization Service is in Active mode.
CRS-4702: Offset (in msec): 13700 

How to switch between observer mode to active mode in either direction?

To execute this task it is very simple. Make sure the /etc/ntp.conf fileis not available. Based on the existence of ntp.conf file CTSS will be inactive or observe mode. So remove/rename the file. 

Every 30 second CTSS will check if the current state is still correct.When CTSS discovers this state is incorrect it will automatically switch fromobserver to active mode when the file is removed. If you don’t want to use theCTSS for the time management create the ntp.conf file again, and on the fly thestate will change.

Trace output explaining the above:

2009-09-28 16:27:13.768: [CTSS][3010210704]sclsctss_gvss1NTP default config file found
2009-09-28 16:27:13.768: [CTSS][3010210704]sclsctss_gvss8: Return [0] and NTP status [2].
2009-09-28 16:27:13.768: CTSS][3010210704]ctss_check_vendor_sw: Vendor timesync software is detected. status [2].
2009-09-28 16:27:15.375: CTSS][3020700560]ctsscomm_prh: Handler called
CTSS][3020700560]ctss_process_request_handler: Master: Received sync messageevent
2009-09-28 16:27:15.375: CTSS][3020700560]ctsscomm_pi: Received sync msg
2009-09-28 16:27:15.375: CTSS][3020700560]ctsscomm_pi: Received from slave (mode [0x46] nodenum [2] hostname [server2] )
2009-09-28 16:27:23.378: CTSS][3020700560]ctsscomm_prh: Handler called
CTSS][3020700560]ctss_process_request_handler: Master: Received sync messageevent
2009-09-28 16:27:23.378: CTSS][3020700560]ctsscomm_pi: Received sync msg
2009-09-28 16:27:23.378: CTSS][3020700560]ctsscomm_pi: Received from slave (mode [0x46] nodenum [2] hostname [server2] )
2009-09-28 16:27:31.389: CTSS][3020700560]ctsscomm_prh: Handler called
CTSS][3020700560]ctss_process_request_handler: Master: Received sync messageevent
2009-09-28 16:27:31.389: CTSS][3020700560]ctsscomm_pi: Received sync msg
2009-09-28 16:27:31.389: CTSS][3020700560]ctsscomm_pi: Received from slave (mode [0x46] nodenum [2] hostname [server2] )
2009-09-28 16:27:39.389: CTSS][3020700560]ctsscomm_prh: Handler called
CTSS][3020700560]ctss_process_request_handler: Master: Received sync messageevent
2009-09-28 16:27:39.389: CTSS][3020700560]ctsscomm_pi: Received sync msg
2009-09-28 16:27:39.389: CTSS][3020700560]ctsscomm_pi: Received from slave (mode [0x46] nodenum [2] hostname [server2] )
2009-09-28 16:27:43.383: CTSS][2978741136]ctss_checkcb: clsdm requested checkalive. Returns [6e]
2009-09-28 16:27:43.769: CTSS][3010210704]sclsctss_gvss2: NTP default pid file not found<==== here /etc/ntp.conf is renamed.
2009-09-28 16:27:43.770: [CTSS][3010210704]sclsctss_gvss8: Return [0] and NTP status [1].
2009-09-28 16:27:43.770: CTSS][3010210704]ctss_check_vendor_sw: Vendor timesync software is not detected. status [1].
2009-09-28 16:27:43.786: CTSS][3010210704]ctsselect_determine_role: node [1]with mode [0x4e] in the modes table
2009-09-28 16:27:43.799: CTSS][3010210704]ctsselect_determine_role: node [2]with mode [0x46] in the modes table
2009-09-28 16:27:43.799: CTSS][3010210704]ctsselect_determine_role: Vendor time synchronizationsoftware is not detected on any node in the cluster. Switched to active role.

Output from the alert.log when there is en Time synchronizationissue.[ctssd(3416)]CRS-2408:The clock on host server2 has been updated by theCluster Time Synchronization Service to be synchronous with the mean clustertime.

2009-10-01 13:50:51.727[ctssd(3416)]CRS-2411:The Cluster TimeSynchronization Service will take long time to perform time synchronizationas local time is significantly different from mean cluster time.Details in/u01/app/11.2.0/grid/log/server2/ctssd/octssd.log.

You can find similar output in the operation system logfile. 

Remark: 
CTSS will run in observe mode as soon as an NTPconfiguration is found. This doesn’t tell if the NTP daemon is really workingproperly. Be aware of this! Default Linux installation will have the ntp.conffile in /etc/
Use either NTP configuration or CTSS for time management. Don’t “play’ withCTSS on production environments. So discuss what you require. 

Additional trace information:

When you look into the details when using cluvfy you will find out thefollowing checks are performed.

  1. Validate     if this is cluster environment, does ocr.loc exists?

  2. Check     if CTSS is running using: /u01/app/11.2.0/grid/bin/crsctl check ctss 

  3. Check     if ntp configuration file exists (when found mark as exists):/tmp/CVU_11.2.0.1.0_oracle/exectask.sh     -chkfile /etc/ntp.conf

  4. Validate     if NTP daemon is really active using:/tmp/CVU_11.2.0.1.0_oracle/exectask.sh     -chkalive ntpd

Alert.log will show when inobserver mode

[ctssd(3582)]CRS-2403:The Cluster TimeSynchronization Service on host server1 is in observer mode.
2009-09-27 21:24:46.766[ctssd(3582)]CRS-2407:The new Cluster TimeSynchronization Service reference node is host server2.
2009-09-27 21:24:46.938[ctssd(3582)]CRS-2412:The Cluster Time SynchronizationService detects that the local time is significantly different from the meancluster time. Details in /u01/app/11.2.0/grid/log/server1/ctssd/octssd.log.
2009-09-27 21:24:46.986[ctssd(3582)]CRS-2409:The clock on host server1 is notsynchronous with the mean cluster time. No action has been taken as the ClusterTime Synchronization Service is running in observer mode.
2009-09-27 21:24:47.277[ctssd(3582)]CRS-2401:The Cluster Time SynchronizationService started on host server1.
2009-09-27 21:26:38.926.....
[ctssd(3582)]CRS-2409:The clock on host server1 is not synchronous with themean cluster time. No action has been taken as the Cluster Time SynchronizationService is running in observer mode.
2009-09-27 22:00:32.725[ctssd(3582)]CRS-2409:The clock on host server1 is notsynchronous with the mean cluster time. No action has been taken as the ClusterTime Synchronization Service is running in observer mode.

Here you can read the state of CTSS as well, but also see there is asynchronization issue No action is taken to fix this issue as CTSS is inobserver mode. 

Alert.log will show when in active mode:

[ctssd(3578)]CRS-2401:TheCluster Time Synchronization Service started on host server1 is in active mode. 

Advise: As time management is extremely important in clusterenvironments you must make sure NTP is running correctly. In general NTP willbe configured as standard on each system. But as soon as you are not able toconfirm this would advise that the file /etc/ntp.conf is removed so CTSS willtake over this responsibility and become active. Make sure this is done on eachnode in the cluster.

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有