3 Configuring Operating Systems for Oracle Grid Infrastructure and Oracle RAC

3.1 Guidelines for Oracle Solaris Operating System Installation

Refer to your Oracle Solaris documentation to obtain information about installing Solaris on your servers. You may want to use Oracle Solaris 11 installation services such as Oracle Solaris Automated Installer (AI) to create and manage services to install the Oracle Solaris 11 operating system over the network.

3.2 Reviewing Operating System and Software Upgrade Best Practices

Review the following information regarding upgrades:

• General Upgrade Best Practices

• Oracle ASM Upgrade Notifications

• Rolling Upgrade Procedure Notifications

3.3 Reviewing Operating System Security Common Practices

Secure operating systems are an important basis for general system security. Ensure that your operating system deployment is in compliance with common security practices as described in your operating system vendor security guide.

3.4 Using Installation Fixup Scripts

Oracle Universal Installer (OUI) detects when the minimum requirements for an installation are not met, and creates shell scripts, called Fixup scripts, to finish incomplete system configuration steps. If OUI detects an incomplete task, then it generates a fixup script (runfixup.sh). You can run the fixup script after you click Fix and Check Again.

You also can have CVU generate fixup scripts before installation.

Fixup scripts do the following:

• If necessary, set kernel parameters to values required for successful installation, including:

  • Shared memory parameters.

  • Open file descriptor and UDP send/receive parameters.

• Create and set permissions on the Oracle Inventory (central inventory) directory.

• Create or reconfigure primary and secondary group memberships for the installation owner, if necessary, for the Oracle Inventory directory and the operating system privileges groups.

• Set shell limits if necessary to required values.

If you have SSH configured between cluster member nodes for the user account that you will use for installation, then you can check your cluster configuration before installation and generate a fixup script to make operating system changes before starting the installation.

To do this, log in as the user account that will perform the installation, navigate to the staging area where the runcluvfy command is located, and use the following command syntax, where node is a comma-delimited list of nodes you want to make cluster members:

$ ./runcluvfy.sh stage -pre crsinst -n node -fixup -verbose

For example, if you intend to configure a two-node cluster with nodes node1 and node2, enter the following command:

$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -fixup -verbose

3.5 Logging In to a Remote System Using X Terminal

During installation, you are required to perform tasks as root or as other users on remote terminals. Complete the following procedure for user accounts that you want to enable for remote display.

To enable remote display, complete one of the following procedures:

• If you are installing the software from an X Window System workstation or X terminal, then:

  1. Start an X terminal session (xterm) on the server where you are running the installation.

  2. Add the local root account to the X server access control list. Run the following command as the user who logged in to the X server:

     # xhost +si:localuser:root
     

  3. If you are installing the software on another system and using the system as an X11 display, then enter a command using the following syntax to enable remote hosts to display X applications on the local X server:

     # xhost + RemoteHost
     

     where RemoteHost is the fully qualified remote host name. For example:

     # xhost + somehost.example.com
     somehost.example.com being added to the access control list
     

  4. If you are not installing the software on the local system, then use the ssh command to connect to the system where you want to install the software:

     # ssh -Y RemoteHost
     

     where RemoteHost is the fully qualified remote host name. The -Y flag ("yes") enables remote X11 clients to have full access to the original X11 display.For example:

     # ssh -Y somehost.example.com
     

     You can use the ssh -V command to check if the SSH version used is Sun_SSH or OpenSSH.

  5. If you are not logged in as the root user, then enter the following command to switch the user to root:

     $ su - root
     password:
     #
     

• If you are installing the software from a PC or other system with X server software installed, then:

  Note:

  If necessary, refer to your X Window System documentation for more information about completing this procedure. Depending on the X server software that you are using, you may need to complete the tasks in a different order.

  1. Start the X Window System software.

  2. Configure the security settings of the X Window System software to permit remote hosts to display X applications on the local system.

  3. Connect to the remote system where you want to install the software as the Oracle Grid Infrastructure for a cluster software owner (grid, oracle) and start a terminal session on that system, for example, an X terminal (xterm).

  4. Open another terminal on the remote system, and log in as the root user on the remote system, so you can run scripts as root when prompted.

3.6 About Operating System Requirements

Depending on the products that you intend to install, verify that you have the required operating system kernel and packages installed.

Requirements listed in this document are current as of the date listed on the title page. To obtain the most current information about kernel requirements, see the online version on the Oracle Technology Network at the following URL:

http://www.oracle.com/technetwork/indexes/documentation/index.html

OUI performs checks on your system to verify that it meets the listed operating system package requirements. To ensure that these checks complete successfully, verify the requirements before you start OUI.

3.7 Operating System Requirements for Oracle Solaris on SPARC (64-Bit)

The Oracle Solaris kernels and packages listed in this section are supported on SPARC 64-bit systems for Oracle Database and Oracle Grid Infrastructure 12c Release 1 (12.1).

• Supported Oracle Solaris 11 Releases for SPARC (64-Bit)

• Supported Oracle Solaris 10 Releases for SPARC (64-Bit)

SUNWarc
SUNWbtool
SUNWcsl
SUNWdtrc
SUNWeu8os
SUNWhea
SUNWi1cs (ISO8859-1)
SUNWi15cs (ISO8859-15)
SUNWi1of
SUNWlibC
SUNWlibm
SUNWlibms
SUNWsprot
SUNWtoo
SUNWxwfnt
147440-25

http://www.oracle.com/technetwork/java/javase/solaris-font-requirements-142758.html">>http://www.oracle.com/technetwork/java/javase/solaris-font-requirements-142758.html

3.8 Operating System Requirements for Oracle Solaris x86-64 (64-Bit) Platforms

The Oracle Solaris kernels and packages listed are supported on x86-64 (64-bit) bit systems for Oracle Database and Oracle Grid Infrastructure 12c Release 1 (12.1).

• Supported Oracle Solaris 11 Releases for x86-64 (64-bit)

• Supported Oracle Solaris 10 Releases for x86-64 (64-bit)

SUNWarc
SUNWbtool
SUNWcsl
SUNWdtrc
SUNWeu8os
SUNWhea
SUNWlibC
SUNWlibm
SUNWlibms
SUNWsprot
SUNWtoo
SUNWi1of
SUNWi1cs (ISO8859-1)
SUNWi15cs (ISO8859-15)
SUNWxwfnt
147441-25

3.9 Additional Drivers and Software Packages for Oracle Solaris

You are not required to install additional drivers and packages, but you may choose to install or configure drivers and packages in the following list:

• Installation Requirements for Open Database Connectivity

• Installation Requirements for Oracle Messaging Gateway

• Installation Requirements for Lightweight Directory Access Protocol

• Installation Requirements for Programming Environments for Oracle Solaris

• Installation Requirements for Web Browsers

3.10 Oracle Solaris Cluster Configuration on SPARC

Review the following information if you are installing Oracle Grid Infrastructure on SPARC processor servers.

If you use Oracle Solaris Cluster 3.3 or later or Oracle Solaris Cluster 4.0 or later, then refer to the Oracle Solaris Cluster Documentation library before starting Oracle Grid Infrastructure installation and Oracle RAC installation. In particular, refer to Oracle Solaris Cluster Data Service for Oracle Real Application Clusters Guide, which is available at the following URL:

https://download.oracle.com/docs/cd/E18728_01/html/821-2852/index.html

Review the following additional information for UDLM and native cluster membership interface:

• With Oracle Solaris Cluster 3.3 and later, Oracle recommends that you do not use UDLM. Instead, Oracle recommends that you use the native cluster membership interface functionality (native SKGXN), which is installed automatically with Oracle Solaris Cluster 3.3 if UDLM is not deployed. No additional packages are needed to use this interface.

• Oracle UDLM is not supported for Oracle RAC 12.1 release or later. If you are upgrading from a prior release with UDLM, you will first need to migrate to Oracle Solaris Cluster native SKGXN and then upgrade. The steps to migrate to Oracle Solaris Cluster native SKGXN are documented at the following URL:

  http://docs.oracle.com/cd/E18728_01/html/821-2852/gkcmt.html#scrolltoc

• If you choose to use UDLM for Oracle RAC releases earlier than 12.1, then you must install the ORCLudlm package for the supported Oracle Solaris Cluster version for this release.

• The native Oracle Solaris Cluster and the UDLM interfaces cannot co-exist in the same Oracle RAC cluster: Every node of the Oracle RAC cluster must either have ORCLudlm installed, or none of the nodes of the Oracle RAC cluster may have ORCLudlm installed.

• With Oracle Solaris Zones, it is possible for one physical server to host multiple Oracle RAC clusters, each in an isolated zone cluster. Those zone clusters must each be self-consistent in terms of the membership model being used. However, because each zone cluster is an isolated environment, you can use zone clusters to create a mix of ORCLudlm and native cluster membership interface Oracle RAC clusters on one physical system.

3.11 Checking the Software Requirements

To ensure that the system meets these requirements, follow these steps:

1. To determine which version of Oracle Solaris is installed, enter the following command:

   # uname -r
   5.11
   

   In this example, the version shown is Oracle Solaris 11 (5.11). If necessary, refer to your operating system documentation for information about upgrading the operating system.

2. To determine the release level, enter the following command:

   # cat /etc/release
   Oracle Solaris 11.1 SPARC
   

   In this example, the release level shown is Oracle Solaris 11.1 SPARC.

3. To determine if the required packages are installed on Oracle Solaris 10, enter the following command:

   pkginfo -i pkg_name

   where pkg_name is the name of the package to check.

   For example:

   # pkginfo -i SUNWarc SUNWbtool SUNWcsl SUNWhea SUNWlibC SUNWlibm SUNWlibms \ 
   SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt
   

   Use the pkg list command on Oracle Solaris 11 to determine if required packages are installed.

   If a package that is required for your system architecture is not installed, then install it. Refer to your operating system or software documentation for information about installing packages.

3.12 Enabling the Name Service Cache Daemon

To allow Oracle Clusterware to better tolerate network failures with NAS devices or NFS mounts, enable the Name Service Cache Daemon (nscd).

Starting with Oracle Solaris 11, when you enable nscd, nscd performs all name service lookups. Before this release, nscd cached a small subset of lookups. By default, nscd is started during system startup in runlevel 3, which is a multiuser state with NFS resources shared.

To check to see if nscd is running, enter the following Service Management Facility (SMF) command:

# svcs name-service-cache
STATE          STIME    FMRI
online         Oct_08   svc:/network/nfs/status:default
online         Oct_30   svc:/system/name-service-cache:default

For Solaris 11, the SMF service svc:/system/name-service/cache contains the configuration information for nscd. The file /etc/nscd.conf is deprecated. Note that svc:/system/name-service-cache still exists on Solaris 11 systems but it is not connected.

If the nscd service is not online, you can enable it using the following command:

# svcadm enable svc:/system/name-service-cache:default

3.13 Verifying Operating System Packages on Oracle Solaris 11

Use the pkg list command to determine whether an update exists for the package, whether an update can be installed, and whether a package is obsolete or renamed.

Use the pkg install command to install packages that are not currently installed and update packages that are already installed. The pkg install command requires one or more package names.

Use the pkg verify command to verify the validity of the package signature.

3.14 Verifying Operating System Patches on Oracle Solaris 10

Verify that you have required operating system patches. To ensure that the system meets these requirements:

1. To determine whether an operating system patch is installed, and whether it is the correct version of the patch, enter a command similar to the following:

   # /usr/sbin/patchadd -p | grep patch_number
   

   For example, to determine if any version of the 119963 patch is installed, use the following command:

   # /usr/sbin/patchadd -p | grep 119963
   

   If an operating system patch is not installed, then download it from the following website and install it:

   https://support.oracle.com
   

2. Use the pkg info command to determine whether an update exists for the package, whether an update can be installed, and whether a package is obsolete or renamed.

3. Use the pkgadd or patchadd commands to install packages that are not currently installed and update packages that are already installed.

3.15 Running the Rootpre.sh Script on x86 with Oracle Solaris Cluster

On x86 (64-bit) platforms running Oracle Solaris, if you install Oracle Solaris Cluster in addition to Oracle Clusterware, then complete the following task:

1. Switch user to root:

   $ su - root
   

2. Complete one of the following steps, depending on the location of the installation

   • If the installation files are on a DVD, then enter a command similar to the following, where mountpoint is the disk mount point directory or the path of the database directory on the DVD:

     # mountpoint/grid/rootpre.sh
     

   • If the installation files are on the hard disk, change directory to the directory /Disk1 and enter the following command:

     # ./rootpre.sh
     

3. Exit from the root account:

   # exit
   

4. Repeat steps 1 through 3 on all nodes of the cluster.

3.16 Setting Network Time Protocol for Cluster Time Synchronization

Oracle Clusterware requires the same time zone variable setting on all cluster nodes. During installation, the installation process picks up the time zone environment variable setting of the Grid installation owner on the node where OUI runs, and uses that time zone value on all nodes as the default TZ environment variable setting for all processes managed by Oracle Clusterware. The time zone default is used for databases, Oracle ASM, and any other managed processes.

You have two options for time synchronization:

• An operating system configured network time protocol (NTP)

• Oracle Cluster Time Synchronization Service

Oracle Cluster Time Synchronization Service is designed for organizations whose cluster servers are unable to access NTP services. If you use NTP, then the Oracle Cluster Time Synchronization daemon (ctssd) starts up in observer mode. If you do not have NTP daemons, then ctssd starts up in active mode and synchronizes time among cluster members without contacting an external time server.

On Oracle Solaris Cluster systems, Oracle Solaris Cluster software supplies a template file called ntp.conf.cluster (see /etc/inet/ntp.conf.cluster on an installed cluster host) that establishes a peer relationship between all cluster hosts. One host is designated as the preferred host. Hosts are identified by their private host names. Time synchronization occurs across the cluster interconnect. If Oracle Clusterware detects either that the Oracle Solaris Cluster NTP or an outside NTP server is set default NTP server in the system in the /etc/inet/ntp.conf or the /etc/inet/ntp.conf.cluster files, then CTSS is set to the observer mode. See the Oracle Solaris 11 Information Library for more information about configuring NTP for Oracle Solaris.

If you have NTP daemons on your server but you cannot configure them to synchronize time with a time server, and you want to use Cluster Time Synchronization Service to provide synchronization service in the cluster, then disable the NTP.

To disable the NTP service, run the following command as the root user

# /usr/sbin/svcadm disable ntp

When the installer finds that the NTP protocol is not active, the Cluster Time Synchronization Service is installed in active mode and synchronizes the time across the nodes. If NTP is found configured, then the Cluster Time Synchronization Service is started in observer mode, and no active time synchronization is performed by Oracle Clusterware within the cluster.

To confirm that ctssd is active after installation, enter the following command as the Grid installation owner:

$ crsctl check ctss

If you are using NTP, and you prefer to continue using it instead of Cluster Time Synchronization Service, then you need to modify the NTP configuration to set the -x flag, which prevents time from being adjusted backward. Restart the network time protocol daemon after you complete this task.

To do this, edit the /etc/sysconfig/ntpd file to add the -x flag, as in the following example:

# Drop root to id 'ntp:ntp' by default.
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
 
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
 
# Additional options for ntpdate
NTPDATE_OPTIONS=""

Then, restart the NTP service:

# /sbin/service ntpd restart

To enable NTP after it has been disabled, enter the following command:

# /usr/sbin/svcadm enable ntp

3.17 Using Automatic SSH Configuration During Installation

To install Oracle software, Secure Shell (SSH) connectivity should be set up between all cluster member nodes. OUI uses the ssh and scp commands during installation to run remote commands on and copy files to the other cluster nodes. You must configure SSH so that these commands do not prompt for a password.

You can configure SSH from the OUI interface during installation for the user account running the installation. The automatic configuration creates passwordless SSH connectivity between all cluster member nodes. Oracle recommends that you use the automatic procedure if possible.

To enable the script to run, you must remove stty commands from the profiles of any Oracle software installation owners, and remove other security measures that are triggered during a login, and that generate messages to the terminal. These messages, mail checks, and other displays prevent Oracle software installation owners from using the SSH configuration script that is built into the Oracle Universal Installer. If they are not disabled, then SSH must be configured manually before an installation can be run.

By default, OUI searches for SSH public keys in the directory /usr/local/etc/, and ssh-keygen binaries in /usr/local/bin. However, on Oracle Solaris, SSH public keys typically are located in the path /etc/ssh, and ssh-keygen binaries are located in the path /usr/bin. To ensure that OUI can set up SSH, use the following command to create soft links:

# ln -s /etc/ssh /usr/local/etc
# ln -s /usr/bin /usr/local/bin

In rare cases, Oracle Clusterware installation may fail during the "AttachHome" operation when the remote node closes the SSH connection. To avoid this problem, set the following parameter in the SSH daemon configuration file /etc/ssh/sshd_config on all cluster nodes to set the timeout wait to unlimited:

LoginGraceTime 0