{"id":14863,"date":"2020-10-13T10:56:00","date_gmt":"2020-10-13T08:56:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/"},"modified":"2020-10-13T10:56:00","modified_gmt":"2020-10-13T08:56:00","slug":"oda-x8-2-ha-cluster-issue-and-ntp-configuration","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/","title":{"rendered":"ODA X8-2-HA cluster issue and NTP configuration"},"content":{"rendered":"<p>I have been recently deploying some new ODA X8-2-HA. After reimaging and creating the appliance, I had to patch the ODA. The day after, checking status, I could realize that my node 0 was not working as expected. I did some interesting troubleshooting that I wanted to share hoping it might be helpful for someone.<\/p>\n<p><!--more--><\/p>\n<h3>Why patching an ODA after reimaging it?<\/h3>\n<p>It might be curious to speak about patching an ODA after fresh installation (reimaging). The problem is that reimaging with last available version will only install last operating system and grid version. ILOM and BIOS will not be updated.  The need to patch can easily been seen when you are checking the installed components :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [24,26,30,32,66,68,72,74]\">\n[root@ODA-node0 ~]# odacli describe-component\nSystem Version\n---------------\n19.8.0.0.0\n\nSystem node Name\n---------------\nODA-node0\n\nLocal System Version\n---------------\n19.8.0.0.0\n\nComponent                                Installed Version    Available Version\n---------------------------------------- -------------------- --------------------\nOAK                                       19.8.0.0.0            up-to-date\n\nGI                                        19.8.0.0.200714       up-to-date\n\nDB                                        12.1.0.2.200714       up-to-date\n\nDCSAGENT                                  19.8.0.0.0            up-to-date\n\nILOM                                      4.0.4.38.r130206      4.0.4.51.r134837\n\nBIOS                                      52010400              52021300\n\nOS                                        7.8                   up-to-date\n\nFIRMWARECONTROLLER                        16.00.01.00           16.00.08.00\n\nFIRMWAREEXPANDER                          0309                  0310\n\nFIRMWAREDISK {\n[ c2d0,c2d1 ]                             1120                  1102\n[ c0d0,c0d1,c0d2,c0d3,c0d4,c0d5,c0d6,     A959                  up-to-date\nc0d7,c0d8,c0d9,c0d10,c0d11,c0d12,c0d13,\nc0d14,c0d15,c0d16,c0d17,c0d18,c0d19,\nc0d20,c0d21,c0d22,c0d23,c1d0,c1d1,c1d2,\nc1d3,c1d4,c1d5,c1d6,c1d7,c1d8,c1d9,\nc1d10,c1d11,c1d12,c1d13,c1d14,c1d15,\nc1d16,c1d17,c1d18,c1d19,c1d20,c1d21,\nc1d22,c1d23 ]\n}\n\nHMP                                       2.4.5.0.1             up-to-date\n\nSystem node Name\n---------------\nODA-node1\n\nLocal System Version\n---------------\n19.8.0.0.0\n\nComponent                                Installed Version    Available Version\n---------------------------------------- -------------------- --------------------\nOAK                                       19.8.0.0.0            up-to-date\n\nGI                                        19.8.0.0.200714       up-to-date\n\nDB                                        12.1.0.2.200714       up-to-date\n\nDCSAGENT                                  19.8.0.0.0            up-to-date\n\nILOM                                      4.0.4.38.r130206      4.0.4.51.r134837\n\nBIOS                                      52010400              52021300\n\nOS                                        7.8                   up-to-date\n\nFIRMWARECONTROLLER                        16.00.01.00           16.00.08.00\n\nFIRMWAREEXPANDER                          0309                  0310\n\nFIRMWAREDISK {\n[ c2d0,c2d1 ]                             1120                  1102\n[ c0d0,c0d1,c0d2,c0d3,c0d4,c0d5,c0d6,     A959                  up-to-date\nc0d7,c0d8,c0d9,c0d10,c0d11,c0d12,c0d13,\nc0d14,c0d15,c0d16,c0d17,c0d18,c0d19,\nc0d20,c0d21,c0d22,c0d23,c1d0,c1d1,c1d2,\nc1d3,c1d4,c1d5,c1d6,c1d7,c1d8,c1d9,\nc1d10,c1d11,c1d12,c1d13,c1d14,c1d15,\nc1d16,c1d17,c1d18,c1d19,c1d20,c1d21,\nc1d22,c1d23 ]\n}\n\nHMP                                       2.4.5.0.1             up-to-date<\/pre>\n<p>In my case here, I have been redeploying version ODA 19.8 on the ODA and I&#8217;m having a gap in version for ILOM, BIOS and storage. There are some very good blogs for patching an ODA to version 19.X :<br \/>\n<a href=\"https:\/\/www.dbi-services.com\/blog\/patching-oracle-database-appliance-from-18-8-to-19-6\/\">Patching ODA from 18.8 to 19.6<\/a><br \/>\n<a href=\"https:\/\/www.dbi-services.com\/blog\/reimaging-an-oda-to-19-8-part-ii\/\">Reimaging ODA in version 19.8 and patching<\/a><\/p>\n<p>In some cases the ODA patching is failing to update the ILOM and the BIOS and this needs to be done manually. Such an operation is also described in details in same last blog :<br \/>\n<a href=\"https:\/\/www.dbi-services.com\/blog\/reimaging-an-oda-to-19-8-part-ii\/\">ILOM and BIOS manual updates<\/a><\/p>\n<h3>Cluster offset issue<\/h3>\n<p>Day after, before moving forward I checked the ODA status and could see some problem with my node 0.  The ASM instance was not started, as well as the ASM listener, see below.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [11]\">\noracle@ODA-node0:\/home\/oracle\/ [rdbms12102_1] ser\n2020-09-16_10-23-05::dmk-run.pl::CheckListenerFile     ::ERROR ==&gt; Couldn't open the listener.ora : \/u01\/app\/oracle\/product\/12.1.0.2\/dbhome_1\/network\/admin\n\nDummy:\n------\nrdbms12102_1         : DUMMY           (12.1.0.2\/dbhome_1)\n\n\nDatabase(s):\n------------\n+ASM1                : STOPPED         (grid)\n\n\n\n\noracle@ODA-node0:\/home\/oracle\/ [rdbms12102_1]\n<\/pre>\n<p>Please note that our customer environments are running <a href=\"https:\/\/www.dbi-services.com\/offering\/products\/dmk-management-kit\/\">dbi DMK management kit<\/a>, that&#8217;s why some of those displays might not be usual.<\/p>\n<p>Easy, even surprised, I decided to try and to start ASM listener :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\ngrid@ODA-node0:\/home\/grid\/ [+ASM1] srvctl status listener -listener ASMNET1LSNR_ASM\nPRCR-1070 : Failed to check if resource ora.ASMNET1LSNR_ASM.lsnr is registered\nCRS-0184 : Cannot communicate with the CRS daemon.\n<\/pre>\n<p>Which was definitively unsuccessfull.<\/p>\n<p>I then checked the Oracle Restart status :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\ngrid@psrpri230:\/home\/grid\/ [rdbms12102_1] crsctl check crs\nCRS-4638: Oracle High Availability Services is online\nCRS-4535: Cannot communicate with Cluster Ready Services\nCRS-4529: Cluster Synchronization Services is online\nCRS-4533: Event Manager is online\n<\/pre>\n<p>The cluster was having problems. I tried to stop and to start it.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [3,6]\">\n[root@ODA-node0 bin]# .\/crsctl start cluster\nCRS-2672: Attempting to start 'ora.ctssd' on 'ODA-node0'\nThe clock on host ODA-node0 differs from mean cluster time by 21656584768 microseconds. The Cluster Time Synchronization Service will not perform time synchronization because the time difference is beyond the permissible offset of 600 seconds. Details in \/u01\/app\/grid\/diag\/crs\/ODA-node0\/crs\/trace\/octssd.trc.\nCRS-2674: Start of 'ora.ctssd' on 'ODA-node0' failed\nCRS-2672: Attempting to start 'ora.ctssd' on 'ODA-node0'\nThe clock on host ODA-node0 differs from mean cluster time by 21656573817 microseconds. The Cluster Time Synchronization Service will not perform time synchronization because the time difference is beyond the permissible offset of 600 seconds. Details in \/u01\/app\/grid\/diag\/crs\/ODA-node0\/crs\/trace\/octssd.trc.\nCRS-2674: Start of 'ora.ctssd' on 'ODA-node0' failed\nCRS-4000: Command Start failed, or completed with errors.\n<\/pre>\n<p>There was definitively a time synchronization issue between my 2 nodes node0 and node1. This could be seen in the log file as well :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [20]\">\n[root@ODA-node0 bin]# tail -20 \/u01\/app\/grid\/diag\/crs\/ODA-node0\/crs\/trace\/octssd.trc\n2020-09-16 10:51:56.830 : GIPCTLS:2817517312:  gipcmodTlsSetAuthFlags: nzcred auth (global 0) flags, feature: 32, optional:0\n2020-09-16 10:51:56.830 : GIPCTLS:2817517312:  gipcmodTlsAuthInit: tls context initialized successfully\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthStart: TLS HANDSHAKE - SUCCESSFUL\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthStart: peerUser: NULL\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthStart: name_CN=ea78a0117f76ff9cff4967dc0d8bf3cf_4294692300,O=Oracle Clusterware,\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthStart: name_CN=ea78a0117f76ff9cff4967dc0d8bf3cf_1599664758,O=Oracle_Clusterware,\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthStart: endpoint 0x7efe9003ac00 [0000000000000a28] { gipcEndpoint : localAddr 'gipcha:\/\/ODA-node0:3202-6a4f-ef55-4696', remoteAddr 'gipcha:\/\/ODA-node1:CTSSGROUP_2\/a7fa-52e9-ad59-eca4', numPend 2, numReady 0, numDone 1, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, readyRef (nil), ready 0, wobj 0x7efe9003d410, sendp (nil) status 13flags 0x200b8602, flags-2 0x10, usrFlags 0x20020 }, auth state: gipcmodTlsAuthStateReady (3)\n2020-09-16 10:51:56.839 : GIPCTLS:2817517312:  gipcmodTlsAuthReady: TLS Auth completed Successfully\n2020-09-16 10:51:56.977 :  CRSCCL:2817517312: ConnAccepted from Peer_msgTag= 0xcccccccc version= 0 msgType= 4 msgId= 0 msglen = 0 clschdr.size_clscmsgh= 88 src= (2, 4294731470) dest= (1, 1099434)\n2020-09-16 10:51:56.977 :    CTSS:2811213568: ctssslave_swm2_1: Waiting for time sync message from master. sync_state[2].\n2020-09-16 10:51:56.977 :    CTSS:2815416064: ctsscomm_recv_cb4_2: Receive active version change msg. Old active version [318767104] New active version [318767104].\n2020-09-16 10:51:56.977 :    CTSS:2815416064: ctssslave_msg_handler4_1: Waiting for slave_sync_with_master to finish sync process. sync_state[3].\n2020-09-16 10:51:56.977 :    CTSS:2811213568: ctssslave_swm2_3: Received time sync message from master.\n2020-09-16 10:51:56.977 :    CTSS:2811213568: ctssslave_swm: The magnitude [21656573817] of the offset [21656573817 usec] is larger than [600000000 usec] sec which is the CTSS limit. Hence CTSS is exiting.\n2020-09-16 10:51:56.977 :    CTSS:2811213568: (:ctsselect_msm3:): Failed in clsctssslave_sync_with_master [12]: Time offset is too much to be corrected, exiting.\n2020-09-16 10:51:56.977 :    CTSS:2815416064: ctssslave_msg_handler4_3: slave_sync_with_master finished sync process. Exiting clsctssslave_msg_handler\n2020-09-16 10:51:57.310 :  CRSCCL:3293234944: clsCclGetPriMemberData: Detected pridata change for node[1]. Retrieving it to the cache.\n2020-09-16 10:51:57.532 :    CTSS:3315066624: ctss_checkcb: clsdm requested check alive. checkcb_data{mode[0xf6], offset[21656573 ms]}, length=[8].\n2020-09-16 10:51:57.532 :    CTSS:2811213568: ctsselect_msm: CTSS daemon exiting [12] as offset is to large.\n2020-09-16 10:51:57.532 :    CTSS:2811213568: CTSS daemon aborting\n<\/pre>\n<p>I then decided to check server time displayed on the OS :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [5]\">\ngrid@ODA-node0:\/home\/grid\/ [rdbms12102_1] date\nWed Sep 16 11:10:17 CEST 2020\n\noracle@ODA-node1:\/home\/oracle\/ [rdbms12102_1] date\nWed Sep 16 05:09:29 CEST 2020\n<\/pre>\n<p>Node 0 was on time but node 1 definitively not.<\/p>\n<p>But why? NTP has been configured on the appliance :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [18]\">\n[root@ODA-node1 ~]# odacli describe-system\n\nAppliance Information\n----------------------------------------------------------------\n                     ID: 74352d02-f2f6-4547-a5cf-71b40f7b7879\n               Platform: X8-2-HA\n        Data Disk Count: 24\n         CPU Core Count: 32\n                Created: September 9, 2020 2:04:08 AM CEST\n\nSystem Information\n----------------------------------------------------------------\n                   Name: \n            Domain Name: domain_name\n              Time Zone: Europe\/Zurich\n             DB Edition: EE\n            DNS Servers: 10.X.X.X 10.X.X.X\n            NTP Servers: 10.10.40.2 10.7.40.23 10.7.40.25\n\nDisk Group Information\n----------------------------------------------------------------\nDG Name                   Redundancy                Percentage\n------------------------- ------------------------- ------------\nData                      Normal                    50\nReco                      Normal                    50\n<\/pre>\n<p>Please note that the IP addresses have been changed not to display customer&#8217;s one.<\/p>\n<h3>NTP configuration on the ODA<\/h3>\n<p>NTP configuration on the ODA is a common linux NTP configuration.<\/p>\n<p>I have checked the NTP configuration and all was looking good and ok. In the mean time I could realize that the NTP pool from Redhat are by default configured and active. Main customers won&#8217;t accept such external connection and are having their own internal NTP server. This was the case by this customer, so I have commented the lines in the NTP configuration file.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 bin]# cp -p \/etc\/ntp.conf \/etc\/ntp.conf.20200916\n\n[root@ODA-node1 bin]# vi \/etc\/ntp.conf\n\n[root@ODA-node1 bin]# diff \/etc\/ntp.conf \/etc\/ntp.conf.20200916\n21,24c21,24\n&lt; #server 0.rhel.pool.ntp.org iburst\n&lt; #server 1.rhel.pool.ntp.org iburst\n&lt; #server 2.rhel.pool.ntp.org iburst\n server 0.rhel.pool.ntp.org iburst\n&gt; server 1.rhel.pool.ntp.org iburst\n&gt; server 2.rhel.pool.ntp.org iburst\n&gt; server 3.rhel.pool.ntp.org iburst\n<\/pre>\n<p>The NTP configuration file looks then like this :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 bin]# cat \/etc\/ntp.conf\n# For more information about this file, see the man pages\n# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).\n\ndriftfile \/var\/lib\/ntp\/drift\n\n# Permit time synchronization with our time source, but do not\n# permit the source to query or modify the service on this system.\nrestrict default nomodify notrap nopeer noquery\n\n# Permit all access over the loopback interface.  This could\n# be tightened as well, but to do so would effect some of\n# the administrative functions.\nrestrict 127.0.0.1\nrestrict ::1\n\n# Hosts on local network are less restricted.\n#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap\n\n# Use public servers from the pool.ntp.org project.\n# Please consider joining the pool (http:\/\/www.pool.ntp.org\/join.html).\n#server 0.rhel.pool.ntp.org iburst\n#server 1.rhel.pool.ntp.org iburst\n#server 2.rhel.pool.ntp.org iburst\n#server 3.rhel.pool.ntp.org iburst\n\n#broadcast 192.168.1.255 autokey        # broadcast server\n#broadcastclient                        # broadcast client\n#broadcast 224.0.1.1 autokey            # multicast server\n#multicastclient 224.0.1.1              # multicast client\n#manycastserver 239.255.254.254         # manycast server\n#manycastclient 239.255.254.254 autokey # manycast client\n\n# Enable public key cryptography.\n#crypto\n\nincludefile \/etc\/ntp\/crypto\/pw\n\n# Key file containing the keys and key identifiers used when operating\n# with symmetric key cryptography.\nkeys \/etc\/ntp\/keys\n\n# Specify the key identifiers which are trusted.\n#trustedkey 4 8 42\n\n# Specify the key identifier to use with the ntpdc utility.\n#requestkey 8\n\n# Specify the key identifier to use with the ntpq utility.\n#controlkey 8\n\n# Enable writing of statistics records.\n#statistics clockstats cryptostats loopstats peerstats\n\n# Disable the monitoring facility to prevent amplification attacks using ntpdc\n# monlist command when default restrict does not include the noquery flag. See\n# CVE-2013-5211 for more details.\n# Note: Monitoring will not be disabled with the limited restriction flag.\ndisable monitor\nserver 10.10.40.2 prefer\nserver 10.7.40.23\nserver 10.7.40.25\n<\/pre>\n<p>I wanted to check how the server was synchronized using ntpq tool.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 bin]# ntpq -p\nntpq: read: Connection refused\n<\/pre>\n<p>But I had to restart the service first. Reason is explained in my blog <a href=\"https:\/\/www.dbi-services.com\/blog\/ntp-is-not-working-for-oda-new-deployment-reimage-in-version-19-8\/\">NTP is not working for ODA new deployment (reimage) in version<\/a> :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 bin]# service ntpd restart\nRedirecting to \/bin\/systemctl restart ntpd.service\n<\/pre>\n<p>I could then check the NTP configuration.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 bin]# ntpq -p\n     remote           refid          st t when poll reach   delay   offset  jitter\n==============================================================================\n lantime.domain_name .INIT.          16 u    -  512    0    0.000    0.000   0.000\n+ntp1.domain_name    131.188.3.223    2 u   32   64  377    0.364    0.635   0.247\n*ntp2.domain_name    131.188.3.223    2 u   26   64  377    0.385    0.851   0.173\n<\/pre>\n<h4>remote<\/h4>\n<p>The remote column will display the NTP server names that should be known by the DNS server. In my case those are the NTP servers I configured when creating the appliance, see previous odacli describe-system command and nslookup below command. <\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [1,5,6,8,12,13]\">\n[root@psrpri231 ~]# nslookup ntp2.domain_name\nServer:         10.7.9.9\nAddress:        10.7.9.9#53\n\nName:   ntp2.domain_name\nAddress: 10.7.40.25\n\n[root@psrpri231 ~]# nslookup ntp1.domain_name\nServer:         10.7.9.9\nAddress:        10.7.9.9#53\n\nName:   ntp1.domain_name\nAddress: 10.7.40.23\n<\/pre>\n<p>At that time there was a network routing issue to the preferred NTP. This is why only the 2 other NTP servers are displayed in the ntpq command. This was certainly the root cause of the synchronization problem between both nodes.<\/p>\n<h4>refid<\/h4>\n<p>The refid entry will show the current source of synchronization for each peer. In my case the source was 131.188.3.223 which is a NTP server of the Friedrich-Alexander university in Erlangen (Germany). This can be confirmed by doing a simple nslookup from my laptop.<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [1,5,6]\">\nC:Usersmaw&gt;nslookup 131.188.3.223\nServer:  UnKnown\nAddress:  192.168.1.254\n\nName:    ntp3.rrze.uni-erlangen.de\nAddress:  131.188.3.223\n<\/pre>\n<p>The character at the left margin will display the synchronization status for the peer.<br \/>\nThe character * will highlight which peer is currently selected. It is named the system peer.<br \/>\nThe character + will highlight the peers which are designated as been acceptable for synchronization but not currently selected. They are considered as good reference time sources and are survivors of the selection process. They can be potential system peers and are then called candidates.<br \/>\nThe character &#8211; will highlight a peer that is discarded from the selection. Those other time sources display a time that differs from the survivors&#8217; time. They are called falsetickers.<\/p>\n<h4>st<\/h4>\n<p>The st entry will display the peer stratum. The stratum will measure the distance between the peer to the NTP source. That would show how many hops\/servers there are until the hardware refclock. In my case, the customer NTP servers are stratum 2 servers. This indicates that they are synchronized directly with the NTP server of the Friedrich-Alexander university which is itself a stratum 1 which has a hardware refclock (stratum 0). The stratum can be seen as a level in the timing hierarchy.<\/p>\n<h4>t<\/h4>\n<p>The t enty will display the type of the peer.<br \/>\nu=unicast<br \/>\nm=multicast<br \/>\nl=local<br \/>\n-=don&#8217;t know<\/p>\n<h4>when<\/h4>\n<p>The when entry will display the time in seconds since the peer was last heard.<\/p>\n<h4>poll<\/h4>\n<p>The poll entry will display the polling interval in seconds. This is the time in seconds the NTP daemon took to synchronize with the peer. That&#8217;s to say the delay in seconds between 2 requests.<\/p>\n<h4>reach<\/h4>\n<p>The reach entry will display in octal format the status of the server availability. After 8 successful synchronization attempts the value will be 377.<\/p>\n<h4>delay<\/h4>\n<p>The delay entry will display the latency the request will take from client to server and back again. It describe the round-trip delay of the NTP request. This value is important for the NTP to take the network latency in account and adjust accordingly the timing.<\/p>\n<h4>offset<\/h4>\n<p>The offset entry will give the time difference between the ODA itself and the peer (the synchronization server).<\/p>\n<h4>jitter<\/h4>\n<p>The jitter entry will give the dispersion, the magnitude of variance. Each peer has a different amount of jitter. The lower the jitter value is, more accurate will be the peer.<\/p>\n<h3>Resolving and checking the cluster offset issue<\/h3>\n<p>Now that the NTP issue is resolved, I could restart Oracle cluster. I could also check the nodes was up and running again.<\/p>\n<p>I first could see that the ODA date has been automatically adjusted by the NTP :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node1 ~]# date\nWed Sep 16 11:29:31 CEST 2020\n<\/pre>\n<p>I could restart the cluster :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">\n[root@ODA-node0 bin]# cd \/u01\/app\/19.0.0.0\/grid\/bin\/\n\n[root@ODA-node0 bin]#  .\/crsctl start cluster\nCRS-2672: Attempting to start 'ora.ctssd' on 'ODA-node0'\nCRS-2676: Start of 'ora.ctssd' on 'ODA-node0' succeeded\nCRS-2672: Attempting to start 'ora.asm' on 'ODA-node0'\nCRS-2672: Attempting to start 'ora.crsd' on 'ODA-node0'\nCRS-2676: Start of 'ora.crsd' on 'ODA-node0' succeeded\nCRS-2676: Start of 'ora.asm' on 'ODA-node0' succeeded\n<\/pre>\n<p>And I could check the cluster is up and running :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1 highlight: [1,7]\">\n[root@ODA-node0 bin]# .\/crsctl check crs\nCRS-4638: Oracle High Availability Services is online\nCRS-4537: Cluster Ready Services is online\nCRS-4529: Cluster Synchronization Services is online\nCRS-4533: Event Manager is online\n\n[root@ODA-node0 bin]# .\/crsctl status resource -t\n--------------------------------------------------------------------------------\nName           Target  State        Server                   State details\n--------------------------------------------------------------------------------\nLocal Resources\n--------------------------------------------------------------------------------\nora.DATA.COMMONSTORE.advm\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\nora.LISTENER.lsnr\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\nora.chad\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\nora.data.commonstore.acfs\n               ONLINE  ONLINE       ODA-node0                mounted on \/opt\/orac\n                                                             le\/dcs\/commonstore,S\n                                                             TABLE\n               ONLINE  ONLINE       ODA-node1                mounted on \/opt\/orac\n                                                             le\/dcs\/commonstore,S\n                                                             TABLE\nora.net1.network\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\nora.ons\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\nora.proxy_advm\n               ONLINE  ONLINE       ODA-node0                STABLE\n               ONLINE  ONLINE       ODA-node1                STABLE\n--------------------------------------------------------------------------------\nCluster Resources\n--------------------------------------------------------------------------------\nora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)\n      1        ONLINE  ONLINE       ODA-node0                STABLE\n      2        ONLINE  ONLINE       ODA-node1                STABLE\nora.DATA.dg(ora.asmgroup)\n      1        ONLINE  ONLINE       ODA-node0                STABLE\n      2        ONLINE  ONLINE       ODA-node1                STABLE\nora.LISTENER_SCAN1.lsnr\n      1        ONLINE  ONLINE       ODA-node0                STABLE\nora.LISTENER_SCAN2.lsnr\n      1        ONLINE  ONLINE       ODA-node1                STABLE\nora.RECO.dg(ora.asmgroup)\n      1        ONLINE  ONLINE       ODA-node0                STABLE\n      2        OFFLINE OFFLINE                               STABLE\nora.asm(ora.asmgroup)\n      1        ONLINE  ONLINE       ODA-node0                Started,STABLE\n      2        ONLINE  ONLINE       ODA-node1                STABLE\nora.asmnet1.asmnetwork(ora.asmgroup)\n      1        ONLINE  ONLINE       ODA-node0                STABLE\n      2        ONLINE  ONLINE       ODA-node1                STABLE\nora.cvu\n      1        ONLINE  ONLINE       ODA-node1                STABLE\nora.ODA-node0.vip\n      1        ONLINE  ONLINE       ODA-node0                STABLE\nora.ODA-node1.vip\n      1        ONLINE  ONLINE       ODA-node1                STABLE\nora.qosmserver\n      1        ONLINE  ONLINE       ODA-node1                STABLE\nora.scan1.vip\n      1        ONLINE  ONLINE       ODA-node0                STABLE\nora.scan2.vip\n      1        ONLINE  ONLINE       ODA-node1                STABLE\n--------------------------------------------------------------------------------\n<\/pre>\n<p>And finally, the ASM instance and the ASM listener were up and running again :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1; highlight: [11,16,17,18,19]\">\noracle@ODA-node0:\/home\/oracle\/ [rdbms12102_1] ser\n2020-09-16_11-34-31::dmk-run.pl::CheckListenerFile     ::ERROR ==&gt; Couldn't open the listener.ora : \/u01\/app\/oracle\/product\/12.1.0.2\/dbhome_1\/network\/admin\n\nDummy:\n------\nrdbms12102_1         : DUMMY           (12.1.0.2\/dbhome_1)\n\n\nDatabase(s):\n------------\n+ASM1                : STARTED         (grid)\n\n\nListener(s):\n------------\nASMNET1LSNR_ASM      : Up              (grid)\nLISTENER             : Up              (grid)\nLISTENER_SCAN1       : Up              (grid)\n<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>I have been recently deploying some new ODA X8-2-HA. After reimaging and creating the appliance, I had to patch the ODA. The day after, checking status, I could realize that my node 0 was not working as expected. I did some interesting troubleshooting that I wanted to share hoping it might be helpful for someone.<\/p>\n","protected":false},"author":48,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[38,123,79],"type_dbi":[],"class_list":["post-14863","post","type-post","status-publish","format-standard","hentry","category-oracle","tag-cluster","tag-ntp","tag-oda"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.2) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>ODA X8-2-HA cluster issue and NTP configuration - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"ODA X8-2-HA cluster issue and NTP configuration\" \/>\n<meta property=\"og:description\" content=\"I have been recently deploying some new ODA X8-2-HA. After reimaging and creating the appliance, I had to patch the ODA. The day after, checking status, I could realize that my node 0 was not working as expected. I did some interesting troubleshooting that I wanted to share hoping it might be helpful for someone.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-10-13T08:56:00+00:00\" \/>\n<meta name=\"author\" content=\"Marc Wagner\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Marc Wagner\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\"},\"author\":{\"name\":\"Marc Wagner\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628\"},\"headline\":\"ODA X8-2-HA cluster issue and NTP configuration\",\"datePublished\":\"2020-10-13T08:56:00+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\"},\"wordCount\":1087,\"commentCount\":0,\"keywords\":[\"Cluster\",\"NTP\",\"ODA\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\",\"name\":\"ODA X8-2-HA cluster issue and NTP configuration - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2020-10-13T08:56:00+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"ODA X8-2-HA cluster issue and NTP configuration\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628\",\"name\":\"Marc Wagner\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g\",\"caption\":\"Marc Wagner\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/marc-wagner\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"ODA X8-2-HA cluster issue and NTP configuration - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/","og_locale":"en_US","og_type":"article","og_title":"ODA X8-2-HA cluster issue and NTP configuration","og_description":"I have been recently deploying some new ODA X8-2-HA. After reimaging and creating the appliance, I had to patch the ODA. The day after, checking status, I could realize that my node 0 was not working as expected. I did some interesting troubleshooting that I wanted to share hoping it might be helpful for someone.","og_url":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/","og_site_name":"dbi Blog","article_published_time":"2020-10-13T08:56:00+00:00","author":"Marc Wagner","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Marc Wagner","Est. reading time":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/"},"author":{"name":"Marc Wagner","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628"},"headline":"ODA X8-2-HA cluster issue and NTP configuration","datePublished":"2020-10-13T08:56:00+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/"},"wordCount":1087,"commentCount":0,"keywords":["Cluster","NTP","ODA"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/","url":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/","name":"ODA X8-2-HA cluster issue and NTP configuration - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2020-10-13T08:56:00+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/oda-x8-2-ha-cluster-issue-and-ntp-configuration\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"ODA X8-2-HA cluster issue and NTP configuration"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/225d9884b8467ead9a872823acb14628","name":"Marc Wagner","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a873cc6e7fbdbbcbdbcaf5dbded14ad9a77b2ec2c3e03b4d724ed33d35d5f328?s=96&d=mm&r=g","caption":"Marc Wagner"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/marc-wagner\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/14863","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/48"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=14863"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/14863\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=14863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=14863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=14863"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=14863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}