- Installing the Oracle Solaris OS on a Cluster Node
- Securing Your Solaris Operating System
- Solaris Cluster Software Installation
- Time Synchronization
- Cluster Management
- Cluster Monitoring
- Service-Level Management and Telemetry
- Patching and Upgrading Your Cluster
- Backing Up Your Cluster
- Creating New Resource Types
- Tuning and Troubleshooting
Time Synchronization
Every aspect of managing, securing, planning, and debugging a network involves determining when events happen. Time is the critical element that enables an event on one network node to be mapped to a corresponding event on another network node. In many cases, these challenges can be overcome by the enterprise deployment of the Network Time Protocol (NTP) service. You can configure this service to operate in the following modes: NTP server, NTP client, or NTP peer.
The xntpd daemon (see the xntpd(1M) man page) is bundled with the Solaris software to provide time synchronization services to all cluster nodes. The Solaris Cluster software installation creates a /etc/inet/ntp.conf.cluster file on each cluster node and a legacy /etc/rc2.d/S74xntpd_cluster script (or legacy Solaris Management Facility [SMF] service) to start xntpd with this file, instead of the default /etc/inet/ntp.conf file. The standard Solaris 10 SMF service, /network/ntp:default, is disabled.
The ntp.conf.cluster file, created by the Solaris Cluster configuration process, synchronizes the time across all cluster nodes by naming the cluster nodes as peers. You can also synchronize your cluster nodes to an external NTP server either by naming a specific NTP server or by broadcasting or multicasting for one. To do this, you can specify the appropriate directive in the /etc/inet/ntp.conf.cluster file on each cluster node. Because the S74xntpd_cluster script calls ntpdate (see the ntpdate(1M) man page), do not restart this service while the cluster is running. If the cluster nodes are not closely synchronized with the external source, restarting the service will result in a large and sudden change in the system clocks, either backward or forward. Under some circumstances, this change can result in a system panic. Instead, follow the recommended procedure, which involves rebooting the cluster. Clearly, you should schedule such a task for the next maintenance window.