NTP Server (Chrony) Setup Guide for Oracle RAC Construction

In an Oracle Real Application Clusters (Oracle RAC) environment, ensuring that the time on all nodes is accurately synchronized is essential for the normal operation of Oracle Grid Infrastructure (GI). This document explains the procedure for constructing an NTP server (Master) that distributes time to RAC nodes using Oracle Linux 7 (OL7).

1. Environment Information
2. Construction of NTP Server Side (192.168.56.18)
3. Operation Check
4. Advice for Deployment to RAC Nodes
5. FAQ (Frequently Asked Questions)
6. Summary

1. Environment Information

Item	Setting Value
NTP Server (Master)	192.168.56.18
RAC Nodes (Clients)	Any IP address (each node)
OS	Oracle Linux 7.x
Synchronization Protocol	Chrony (NTP)

2. Construction of NTP Server Side (192.168.56.18)

2.1 Installing the Package

First, check if chrony is installed and perform the installation.

# Check installation
rpm -q chrony

# Install (if not already installed)
sudo yum install chrony -y

2.2 Editing the Configuration File (/etc/chrony.conf)

Configure the server to allow requests from RAC nodes and to operate as a master even if the external connection is unstable.

# Take a backup
sudo cp /etc/chrony.conf /etc/chrony.conf.bak

# Edit the configuration
sudo vi /etc/chrony.conf

[Configuration Content] Delete or comment out the existing content and write the following:

# --- Synchronization Source (Upstream) Servers ---
# Specify public NTP servers if internet access is available.
# If in a closed network, specify the IP of an upstream switch, etc.
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

# File to record drift information
driftfile /var/lib/chrony/drift

# Configuration to allow large offsets immediately after startup 
# (Step correction for offsets of 1 second or more up to 3 times)
makestep 1.0 3

# Enable kernel RTC synchronization
rtcsync

# ★IMPORTANT: Allow access from the subnet where the RAC nodes belong.
# Adjust the network address according to your environment.
allow 192.168.56.0/24

# ★IMPORTANT: Operational setting for isolated environments.
# Even if communication with upstream servers is impossible, 
# trust its own clock and continue distribution.
local stratum 10

# Log settings
logdir /var/log/chrony

2.3 Starting the Service and Enabling Auto-start

# Enable and start the service
sudo systemctl enable chronyd
sudo systemctl start chronyd

# Check the startup status
sudo systemctl status chronyd

2.4 Opening the Firewall

Allow NTP (UDP port 123).

sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

3. Operation Check

Check on the server side if time synchronization has started correctly.

# Check synchronization sources
chronyc sources -v

If the line starts with ^*, synchronization is complete. If it shows ^?, it is still synchronizing or unreachable, but it should change to ^* after a few minutes.

4. Advice for Deployment to RAC Nodes

In the /etc/chrony.conf of each RAC node, specify the server constructed this time.

# Example of /etc/chrony.conf on the RAC node side
server 192.168.56.18 iburst

5. FAQ (Frequently Asked Questions)

Q1: During GI installation, a warning appears saying “NTP is configured, but CTSSD is recommended.” A: This is normal behavior. When NTP (Chrony) is running, Oracle’s Cluster Time Synchronization Service (CTSSD) stays in “Observer Mode.” If the configuration is correct, you can proceed with the installation without issues.

Q2: Even after running chronyc sources on the RAC node side, it stays as ^? (unsynchronized). A: Please check the following three points:

Does the allow setting on the Master server (18) side correctly cover the network?
Is the firewall (UDP 123) on the Master server side open?
Is the Master server itself in a trusted state indicated by ^* or local stratum?

Q3: What if the time becomes significantly offset during installation? A: If it is before the GI installation, stop the service with systemctl stop chronyd, then execute chronyd -q 'server 192.168.56.18 iburst' to force synchronization, and restart the service.

Q4: Is it dangerous to “roll back” the time after RAC is operational? A: Yes, it is dangerous. To prevent database inconsistency, the basic rule after RAC is operational is to adjust the time gradually (Slew adjustment) rather than jumping it backward. Chrony performs this behavior by default, and since the makestep setting in this procedure is limited to “immediately after startup,” it is safe.

6. Summary

The key points for building time synchronization in an Oracle RAC environment can be summarized into the following three points:

Ensuring Availability: By setting local stratum 10, you maintain time synchronization within the cluster even during external network failures, preventing node eviction.
Appropriate Access Control: Use the allow setting to ensure that requests from the network where the RAC nodes belong are permitted.
Compatibility with GI Installer: Before starting the installation, verify that chronyc sources on all nodes is normal (the synchronization source is visible).

Accurate time synchronization is the first step toward stable RAC operation. Aim to get a “Pass” when running cluvfy (Verification Tool) after construction.