Oracle DBA Tips Corner

     Return to the Oracle DBA Tips Corner.


Adding a Node to an Oracle RAC 10g Release 2 Cluster on Linux - (CentOS 4.5 / iSCSI)

by Jeff Hunter, Sr. Database Administrator


Contents

  1. Overview
  2. Hardware and Costs
  3. Install the Linux Operating System
  4. Network Configuration
  5. Configure Network Security on the Openfiler Storage Server
  6. Configure the iSCSI Initiator
  7. Create "oracle" User and Directories
  8. Configure the Linux Server for Oracle
  9. Configure the "hangcheck-timer" Kernel Module
  10. Configure RAC Nodes for Remote Access using SSH
  11. All Startup Commands for New Oracle RAC Node
  12. Install and Configure Oracle Cluster File System (OCFS2)
  13. Install and Configure Automatic Storage Management (ASMLib 2.0)
  14. Pre-Installation Tasks for Oracle10g Release 2
  15. Extend Oracle Clusterware Software to the New Node
  16. Extend Oracle Database Software to the New Node
  17. Add Listener to New Node
  18. Add Database Instance to the New Node
  19. About the Author



Overview

As your organization grows so too does your need for more application and database resources to support the company's IT systems. Oracle RAC 10g provides a scalable framework which allows DBA's to effortlessly extend the database tier to support this increased demand. As the number of users and transactions increase, additional Oracle instances can be added to the Oracle database cluster to distribute the extra load.

This document is an extension to my article "Building an Inexpensive Oracle RAC 10g Release 2 on Linux - (CentOS 4.5 / iSCSI)". Contained in this new article are the steps required to add a single node to an already running and configured two-node Oracle RAC 10g Release 2 environment on the CentOS 32-bit (x86) platform. Although this article was written and tested on CentOS 4.5 Linux, it should work unchanged with Red Hat Enterprise Linux 4 Update 5.

This article assumes the following:

The reader has already built and configured a two-node Oracle RAC 10g Release 2 environment using the article "Building an Inexpensive Oracle RAC 10g Release 2 on Linux - (CentOS 4.5 / iSCSI)". The article provides comprehensive instructions for building a two-node RAC cluster, each with a single processor running CentOS 4.5, Oracle RAC 10g Release 2, OCFS2, and ASMLib 2.0. The current two-node RAC environment actually consists of three machines — two named linux1 and linux2 which each run an Oracle10g instance and a third node to run the network storage server named openfiler1.

Note: The current two-node Oracle RAC environment has been upgraded from its base release (10.2.0.1.0) to version 10.2.0.3.0 by applying the 5337014 patchset (p5337014_10203_LINUX.zip). The patchset was applied to Oracle Clusterware and the Oracle Database software. I also applied the one-off patchset - "BUNDLE Patch for Base Bug 6000740" (MLR7 ON TOP OF 10.2.0.3) to the Oracle Clusterware and Oracle Database software. The procedures for installing both patchsets are not included in any of the parent article(s).

To maintain the current naming convention, the new Oracle RAC node to be added to the existing cluster will be named linux3 (running a new instance named orcl3) making it a three-node cluster.

The new Oracle RAC node should have the same operating system version and installed patches as the current two-node cluster.

Each node in the existing Oracle RAC cluster has a copy of the Oracle Clusterware and Oracle Database software installed on their local disks. The current two-node Oracle RAC environment does not use shared Oracle homes for the Clusterware or Database software.

The software owner for the Oracle Clusterware and Oracle Database installs will be "oracle". It is important that the UID and GID of the oracle user account be identical to that of the existing RAC nodes. For the purpose of this example, the oracle user account will be defined as follows:
[oracle@linux1 ~]$ id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)
The existing Oracle RAC 10g environment makes use of a clustered file system (OCFS2) to store the two files required to be shared by Oracle Clusterware; namely the Oracle Cluster Registry (OCR) file and the Voting Disk. Instructions for installing and adding the new Oracle RAC node to the "live" OCFS2 file system will be included.

Automatic Storage Management (ASM) is being used as the file system and volume manager for all Oracle physical database files (data, online redo logs, control files, archived redo logs) and a Flash Recovery Area. In addition to ASM, we will also be configuring ASMLib on the new Oracle RAC node.

To add instances to an existing RAC database, Oracle Corporation recommends using the Oracle cloning procedures which is described in the Oracle Universal Installer and OPatch User's Guide. This article, however, uses manual procedures to add nodes and instances to the existing Oracle RAC cluster. The manual procedures method described in this article involve extending the RAC database by first extending the Oracle Clusterware home to the new Oracle RAC node and then extending the Oracle Database home. In other words, you extend the software onto the new node in the same order as you installed the clusterware and Oracle database software components on the existing two-node RAC.

During the creation of the existing two-node cluster, the installation of Oracle Clusterware and the Oracle Database software were only performed from one node in the RAC cluster — namely from linux1 as the oracle user account. The Oracle Universal Installer (OUI) on that particular node would then use the ssh and scp commands to run remote commands on and copy files (the Oracle software) to all other nodes within the RAC cluster. The oracle user account on the node running the OUI (runInstaller) had to be trusted by all other nodes in the RAC cluster. This meant that the oracle user account had to run the secure shell commands (ssh or scp) on the Linux server executing the OUI (linux1) against all other Linux servers in the cluster without being prompted for a password. The same security requirements hold true for this article. User equivalence will be configured so that the Oracle Clusterware and Oracle Database software will be securely copied from linux1 to the new Oracle RAC node (linux3) using ssh and scp without being prompted for a password.

All shared disk storage for the existing Oracle RAC is based on iSCSI using a Network Storage Server; namely Openfiler Release 2.2 (respin 2). Powered by rPath Linux, Openfiler is a free browser-based network storage management utility that delivers file-based Network Attached Storage (NAS) and block-based Storage Area Networking (SAN) in a single framework. Openfiler supports CIFS, NFS, HTTP/DAV, FTP, however, we will only be making use of its iSCSI capabilities to implement an inexpensive SAN for the shared storage components required by Oracle RAC 10g. This solution offers a low-cost alternative to fibre channel for testing and educational purposes, but given the low-end hardware being used, it should not be used in a production environment.

These articles provide a low cost alternative for those who want to become familiar with Oracle RAC 10g using commercial off the shelf components and downloadable software. Bear in mind that these articles are provided for educational purposes only so the setup is kept simple to demonstrate ideas and concepts. For example, the disk mirroring configured in this article will be setup on one physical disk only, while in practice that should be performed on multiple physical drives. In addition, each Linux node will only be configured with two network cards — one for the public network (eth0) and one for the private cluster interconnect "and" network storage server for shared iSCSI access (eth1). For a production RAC implementation, the private interconnect should be at least gigabit (or more) and "only" be used by Oracle to transfer Cluster Manager and Cache Fusion related data. A third dedicated network interface (i.e. eth2) should be configured on another gigabit network for access to the network storage server (Openfiler).

The following is a conceptual look at what the environment will look like after adding the third Oracle RAC node (linux3) to the cluster. Click on the graphic below to enlarge the image:

Oracle RAC 10g Release 2 Environment

Figure 1: Adding linux3 to the current Oracle RAC 10g Release 2 Environment


  While this article provides comprehensive instructions for successfully adding a node to an existing Oracle RAC 10g system, it is by no means a substitute for the official Oracle documentation. In addition to this article, users should also consult the following Oracle documents to gain a full understanding of alternative configuration options, installation, and administration with Oracle RAC 10g. Oracle's official documentation site is docs.oracle.com.

  Oracle Clusterware and Oracle Real Application Clusters Installation Guide - 10g Release 2 (10.2) for Linux
  Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide - 10g Release 2 (10.2)
  2 Day + Real Application Clusters Guide - 10g Release 2 (10.2)



Hardware and Costs

The hardware used in this article to build the third node (linux3) consists of a Linux workstation and components which can be purchased at many local computer stores or over the Internet.

Oracle RAC Node 3 - (linux3)
  Dell Dimension 3000 Series

     - Intel(R) Pentium(R) 4 Processor at 2.80GHz
     - 2GB DDR SDRAM (at 333MHz)
     - 60GB 7200 RPM Internal Hard Drive
     - Integrated Intel 3D AGP Graphics
     - Integrated 10/100 Ethernet - (Broadcom BCM4401)
     - CDROM (48X Max Variable)
     - 3.5" Floppy
     - No Keyboard, Monitor, or Mouse - (Connected to KVM Switch)

US$300
  1 - Ethernet LAN Card

Each Linux server for Oracle RAC should contain two NIC adapters. The Dell Dimension includes an integrated 10/100 Ethernet adapter that will be used to connect to the public network. The second NIC adapter will be used for the private network (RAC interconnect and Openfiler networked storage). Select the appropriate NIC adapter that is compatible with the maximum data transmission speed of the network switch to be used for the private network. For the purpose of this article, I used a Gigabit Ethernet switch (and 1Gb Ethernet cards) for the private network.

Used for RAC interconnect to linux1, linux2 and Openfiler networked storage.

     Gigabit Ethernet

       Intel 10/100/1000Mbps PCI Desktop Adapter - (PWLA8391GT)

US$35

  2 - Network Cables

       Category 5e patch cable - (Connect linux3 to public network)
       Category 5e patch cable - (Connect linux3 to interconnect ethernet switch)

US$5
US$5

Total     US$345  


We are about to start the installation process. As we start to go into the details of the installation, it should be noted that most of the tasks within this document will need to be performed on the new Oracle RAC node (linux3). I will indicate at the beginning of each section whether or not the task(s) should be performed on the new Oracle RAC node, the current Oracle RAC node(s), or on the network storage server (openfiler1).



Install the Linux Operating System


  Perform the following installation on the new Oracle RAC node!

After procuring the required hardware, it is time to start the configuration process. The first task we need to perform is to install the Linux operating system. As already mentioned, this article will use CentOS 4.5. Although I have used Red Hat Fedora in the past, I wanted to switch to a Linux environment that would guarantee all of the functionality contained with Oracle. This is where CentOS comes in. The CentOS project takes the Red Hat Enterprise Linux 4 source RPMs and compiles them into a free clone of the Red Hat Enterprise Server 4 product. This provides a free and stable version of the Red Hat Enterprise Linux 4 (AS/ES) operating environment that I can now use for testing different Oracle configurations. I have moved away from Fedora as I need a stable environment that is not only free, but as close to the actual Oracle supported operating system as possible. While CentOS is not the only project performing the same functionality, I tend to stick with it as it is stable and reacts fast with regards to updates by Red Hat.


Downloading CentOS

Use the links (below) to download CentOS 4.5. After downloading CentOS, you will then want to burn each of the ISO images to CD.

  CentOS.org

  If you are downloading the above ISO files to a MS Windows machine, there are many options for burning these images (ISO files) to a CD. You may already be familiar with and have the proper software to burn images to CD. If you are not familiar with this process and do not have the required software to burn images to CD, here are just two (of many) software packages that can be used:

  UltraISO
  Magic ISO Maker


Installing CentOS

This section provides a summary of the screens used to install CentOS. For more detailed installation instructions, it is possible to use the manuals from Red Hat Linux http://www.redhat.com/docs/manuals/. I would suggest, however, that the instructions I have provided below be used for this Oracle RAC 10g configuration.

  Before installing the Linux operating system on the new Oracle RAC node, you should have the two NIC interfaces (cards) installed.

After downloading and burning the CentOS images (ISO files) to CD, insert CentOS Disk #1 into the new Oracle RAC server (linux3 in this example), power it on, and answer the installation screen prompts as noted below.

Boot Screen

The first screen is the CentOS boot screen. At the boot: prompt, hit [Enter] to start the installation process.
Media Test
When asked to test the CD media, tab over to [Skip] and hit [Enter]. If there were any errors, the media burning software would have warned us. After several seconds, the installer should then detect the video card, monitor, and mouse. The installer then goes into GUI mode.
Welcome to CentOS
At the welcome screen, click [Next] to continue.
Language / Keyboard Selection
The next two screens prompt you for the Language and Keyboard settings. In almost all cases, you can accept the defaults. Make the appropriate selection for your configuration and click [Next] to continue.
Installation Type
Choose the [Custom] option and click [Next] to continue.
Disk Partitioning Setup
Select [Automatically partition] and click [Next] continue.

If there were a previous installation of Linux on this machine, the next screen will ask if you want to "remove" or "keep" old partitions. Select the option to [Remove all partitions on this system]. Also, ensure that the [hda] drive is selected for this installation. I also keep the checkbox [Review (and modify if needed) the partitions created] selected. Click [Next] to continue.

You will then be prompted with a dialog window asking if you really want to remove all partitions. Click [Yes] to acknowledge this warning.

Partitioning
The installer will then allow you to view (and modify if needed) the disk partitions it automatically selected. For most automatic layouts, the installer will choose 100MB for /boot, double the amount of RAM (systems with < 2GB RAM) or an amount equal to RAM (systems with > 2GB RAM) for swap, and the rest going to the root (/) partition. Starting with EL 4, the installer will create the same disk configuration as just noted but will create them using the Logical Volume Manager (LVM). For example, it will partition the first hard drive (/dev/hda for my configuration) into two partitions — one for the /boot partition (/dev/hda1) and the remainder of the disk dedicate to a LVM named VolGroup00 (/dev/hda2). The LVM Volume Group (VolGroup00) is then partitioned into two LVM partitions - one for the root filesystem (/) and another for swap.

The main concern during the partitioning phase is to ensure enough swap space is allocated as required by Oracle (which is a multiple of the available RAM). The following is Oracle's requirement for swap space:

Available RAM Swap Space Required
Between 1 GB and 2 GB 1.5 times the size of RAM
Between 2 GB and 8 GB Equal to the size of RAM
More than 8 GB .75 times the size of RAM

For the purpose of this install, I will accept all automatically preferred sizes. (Including 2GB for swap since I have 2GB of RAM installed.)

If for any reason, the automatic layout does not configure an adequate amount of swap space, you can easily change that from this screen. To increase the size of the swap partition, [Edit] the volume group VolGroup00. This will bring up the "Edit LVM Volume Group: VolGroup00" dialog. First, [Edit] and decrease the size of the root file system (/) by the amount you want to add to the swap partition. For example, to add another 512MB to swap, you would decrease the size of the root file system by 512MB (i.e. 36,032MB - 512MB = 35,520MB). Now add the space you decreased from the root file system (512MB) to the swap partition. When completed, click [OK] on the "Edit LVM Volume Group: VolGroup00" dialog.

Once you are satisfied with the disk layout, click [Next] to continue.

Boot Loader Configuration
The installer will use the GRUB boot loader by default. To use the GRUB boot loader, accept all default values and click [Next] to continue.
Network Configuration
I made sure to install both NIC interfaces (cards) in the new Linux machine before starting the operating system installation. This screen should have successfully detected each of the network devices.

First, make sure that each of the network devices are checked to [Active on boot]. The installer may choose to not activate eth1 by default.

Second, [Edit] both eth0 and eth1 as follows. You may choose to use different IP addresses for both eth0 and eth1 and that is OK. Configure eth1 (the interconnect and storage network) on a different subnet than eth0 (the public network):

eth0:
- Check OFF the option to [Configure using DHCP]
- Leave the [Activate on boot] checked ON
- IP Address: 192.168.1.107
- Netmask: 255.255.255.0

eth1:
- Check OFF the option to [Configure using DHCP]
- Leave the [Activate on boot] checked ON
- IP Address: 192.168.2.107
- Netmask: 255.255.255.0

Continue by setting your hostname manually. I used "linux3" for this new Oracle RAC node. Finish this dialog off by supplying your gateway and DNS servers.

Firewall
On this screen, make sure to select [No firewall]. Also under the option to "Enable SELinux?", select [Disabled] and click [Next] to continue.

You will be prompted with a warning dialog about not setting the firewall. If this occurs, simply hit [Proceed] to continue.

Additional Language Support / Time Zone
The next two screens allow you to select additional language support and time zone information. In almost all cases, you can accept the defaults. Make the appropriate selection for your configuration and click [Next] to continue.
Set Root Password
Select a root password and click [Next] to continue.
Package Group Selection
Scroll down to the bottom of this screen and select [Everything] under the "Miscellaneous" section. Click [Next] to continue.

Please note that the installation of Oracle does not require all Linux packages to be installed. My decision to install all packages was for the sake of brevity. Please see section "Pre-Installation Tasks for Oracle10g Release 2" for a more detailed look at the critical packages required for a successful Oracle installation.

Also note that with some RHEL 4 distributions, you will not get the "Package Group Selection" screen by default. There, you are asked to simply "Install default software packages" or "Customize software packages to be installed". Select the option to "Customize software packages to be installed" and click [Next] to continue. This will then bring up the "Package Group Selection" screen. Now, scroll down to the bottom of this screen and select [Everything] under the "Miscellaneous" section. Click [Next] to continue.

About to Install
This screen is basically a confirmation screen. Click [Next] on this screen and then the [Continue] button on the dialog box to start the installation. During the installation process, you will be asked to switch disks to Disk #2, Disk #3, and then Disk #4.

Note that with CentOS 4.5, the installer would ask to switch to Disk #2, Disk #3, Disk #4, Disk #1, and then back to Disk #4.

Graphical Interface (X) Configuration
With most RHEL 4 distributions (not the case with CentOS 4.5), when the installation is complete, the installer will attempt to detect your video hardware. Ensure that the installer has detected and selected the correct video hardware (graphics card and monitor) to properly use the X Windows server. You will continue with the X configuration in the next serveral screens.
Congratulations
And that's it. You have successfully installed CentOS on the new Oracle RAC node (linux3). The installer will eject the CD from the CD-ROM drive. Take out the CD and click [Reboot] to reboot the system.

When the system boots into Linux for the first time, it will prompt you with another Welcome screen. The following wizard allows you to configure the date and time, add any additional users, test the sound card, and to install any additional CDs. The only screen I care about is the time and date (and if you are using CentOS 4.x, the monitor/display settings). As for the others, simply run through them as there is nothing additional that needs to be installed (at this point anyways!). If everything was successful, you should now be presented with the login screen.



Network Configuration


  Perform the following network configuration tasks on the new Oracle RAC node!


Introduction to Network Settings

Although we configured several of the network settings during the installation of CentOS, it is important to not skip this section as it contains critical steps that are required for a successful RAC environment.

During the Linux O/S install we already configured the IP address and host name for the new Oracle RAC node. We now need to configure the /etc/hosts file as well as adjusting several of the network settings for the interconnect.

All nodes in the RAC cluster should have one static IP address for the public network and one static IP address for the private cluster interconnect. The private interconnect should only be used by Oracle to transfer Cluster Manager and Cache Fusion related data along with data for the network storage server (Openfiler). Although it is possible to use the public network for the interconnect, this not recommended as it may cause degraded database performance (reducing the amount of bandwidth for Cache Fusion and Cluster Manager traffic). For a production RAC implementation, the interconnect should be at least gigabit (or more) and only be used by Oracle as well as having the network storage server (Openfiler) on a separate gigabit network.


Configuring Public and Private Network

With the new Oracle RAC node, we need to configure the network for access to the public network as well as the private interconnect.

The easiest way to configure network settings in Red Hat Linux is with the program Network Configuration. This application can be started from the command-line as the "root" user account as follows:

# su -
# /usr/bin/system-config-network &

  Do not use DHCP naming for the public IP address or the interconnects - we need static IP addresses!

Using the Network Configuration application, we will need to configure both NIC devices as well as the /etc/hosts file on all nodes in the RAC cluster. Both of these tasks can be completed using the Network Configuration GUI.

Please note that for the purpose of this example configuration the /etc/hosts entries will be the same for all three Oracle RAC nodes (linux1, linux2, and linux3) as well as the network storage server (openfiler1):

Our example configuration will use the following settings for all nodes:

Oracle RAC Node 3 - (linux3)
Device IP Address Subnet Gateway Purpose
eth0 192.168.1.107 255.255.255.0 192.168.1.1 Connects linux3 to the public network
eth1 192.168.2.107 255.255.255.0   Connects linux3 (interconnect) to linux1/linux2 (linux1-priv/linux2-priv)
/etc/hosts
127.0.0.1        localhost.localdomain localhost

# Public Network - (eth0)
192.168.1.100    linux1
192.168.1.101    linux2
192.168.1.107    linux3

# Private Interconnect - (eth1)
192.168.2.100    linux1-priv
192.168.2.101    linux2-priv
192.168.2.107    linux3-priv

# Public Virtual IP (VIP) addresses - (eth0:1)
192.168.1.200    linux1-vip
192.168.1.201    linux2-vip
192.168.1.207    linux3-vip

# Private Storage Network for Openfiler
192.168.1.195    openfiler1
192.168.2.195    openfiler1-priv

Oracle RAC Node 2 - (linux2)
Device IP Address Subnet Gateway Purpose
eth0 192.168.1.101 255.255.255.0 192.168.1.1 Connects linux2 to the public network
eth1 192.168.2.101 255.255.255.0   Connects linux2 (interconnect) to linux1/linux3 (linux1-priv/linux3-priv)
/etc/hosts
127.0.0.1        localhost.localdomain localhost

# Public Network - (eth0)
192.168.1.100    linux1
192.168.1.101    linux2
192.168.1.107    linux3

# Private Interconnect - (eth1)
192.168.2.100    linux1-priv
192.168.2.101    linux2-priv
192.168.2.107    linux3-priv

# Public Virtual IP (VIP) addresses - (eth0:1)
192.168.1.200    linux1-vip
192.168.1.201    linux2-vip
192.168.1.207    linux3-vip

# Private Storage Network for Openfiler
192.168.1.195    openfiler1
192.168.2.195    openfiler1-priv

Oracle RAC Node 1 - (linux1)
Device IP Address Subnet Gateway Purpose
eth0 192.168.1.100 255.255.255.0 192.168.1.1 Connects linux1 to the public network
eth1 192.168.2.100 255.255.255.0   Connects linux1 (interconnect) to linux2/linux3 (linux2-priv/linux3-priv)
/etc/hosts
127.0.0.1        localhost.localdomain localhost

# Public Network - (eth0)
192.168.1.100    linux1
192.168.1.101    linux2
192.168.1.107    linux3

# Private Interconnect - (eth1)
192.168.2.100    linux1-priv
192.168.2.101    linux2-priv
192.168.2.107    linux3-priv

# Public Virtual IP (VIP) addresses - (eth0:1)
192.168.1.200    linux1-vip
192.168.1.201    linux2-vip
192.168.1.207    linux3-vip

# Private Storage Network for Openfiler
192.168.1.195    openfiler1
192.168.2.195    openfiler1-priv


In the screen shots below, only the new Oracle RAC node (linux3) is shown. Ensure that the /etc/hosts file is updated on all participating nodes to access the new Oracle RAC node!



Figure 2: Network Configuration Screen - Node 3 (linux3)



Figure 3: Ethernet Device Screen - eth0 (linux3)



Figure 4: Ethernet Device Screen - eth1 (linux3)



Figure 5: Network Configuration Screen - /etc/hosts (linux3)


Once the network is configured, you can use the ifconfig command to verify everything is working. The following example is from the new Oracle RAC node linux3:

# /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1E:2A:37:6B:9E
          inet addr:192.168.1.107  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:2aff:fe37:6b9e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1167677 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1842517 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:576629131 (549.9 MiB)  TX bytes:2143836310 (1.9 GiB)
          Interrupt:209 Base address:0xef00

eth1      Link encap:Ethernet  HWaddr 00:0E:0C:C0:78:64
          inet addr:192.168.2.107  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::20e:cff:fec0:7864/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4782 (4.6 KiB)  TX bytes:5564 (5.4 KiB)
          Base address:0xdd80 Memory:fe9c0000-fe9e0000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2034 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2386686 (2.2 MiB)  TX bytes:2386686 (2.2 MiB)

sit0      Link encap:IPv6-in-IPv4
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


Verify Network Access to All Nodes

Verify that the new Oracle RAC node has access to the public and private network for all current nodes. From linux3:
# ping -c 1 linux1 | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms

# ping -c 1 linux1-priv | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms

# ping -c 1 linux2 | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms

# ping -c 1 linux2-priv | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms

# ping -c 1 openfiler1 | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms

# ping -c 1 openfiler1-priv | grep '1 packets transmitted'
1 packets transmitted, 1 received, 0% packet loss, time 0ms


Confirm the RAC Node Name is Not Listed in Loopback Address

Ensure that the new Oracle RAC node (linux3) is not included for the loopback address in the /etc/hosts file. If the machine name is listed in the in the loopback address entry as below:
    127.0.0.1        linux3 localhost.localdomain localhost
it will need to be removed as shown below:
    127.0.0.1        localhost.localdomain localhost

  If the RAC node name is listed for the loopback address, you will receive the following error during the RAC installation:
ORA-00603: ORACLE server session terminated by fatal error
or
ORA-29702: error occurred in Cluster Group Service operation


Confirm localhost is defined in the /etc/hosts file for the loopback address

Ensure that the entry for localhost.localdomain and localhost are included for the loopback address in the /etc/hosts file for the new Oracle RAC node:
    127.0.0.1        localhost.localdomain localhost

  If an entry does not exist for localhost in the /etc/hosts file, Oracle Clusterware will be unable to start the application resources — notably the ONS process. The error would indicate "Failed to get IP for localhost" and will be written to the log file for ONS. For example:
CRS-0215 could not start resource 'ora.linux3.ons'. Check log file
"/u01/app/crs/log/linux3/racg/ora.linux3.ons.log"
for more details.
The ONS log file will contain lines similar to the following:

Oracle Database 10g CRS Release 10.2.0.1.0 Production Copyright 1996, 2005 Oracle. All rights reserved.
2007-04-14 13:10:02.729: [ RACG][3086871296][13316][3086871296][ora.linux3.ons]: Failed to get IP for localhost (1)
Failed to get IP for localhost (1)
Failed to get IP for localhost (1)
onsctl: ons failed to start
...


Adjusting Network Settings

With Oracle 9.2.0.1 and onwards, Oracle now makes use of UDP as the default protocol on Linux for inter-process communication (IPC), such as Cache Fusion and Cluster Manager buffer transfers between instances within the RAC cluster.

Oracle strongly suggests to adjust the default and maximum send buffer size (SO_SNDBUF socket option) to 256 KB, and the default and maximum receive buffer size (SO_RCVBUF socket option) to 256 KB.

The receive buffers are used by TCP and UDP to hold received data until it is read by the application. The receive buffer cannot overflow because the peer is not allowed to send data beyond the buffer size window. This means that datagrams will be discarded if they don't fit in the socket receive buffer. This could cause the sender to overwhelm the receiver.

The default and maximum window size can be changed without a reboot. Add the following entries to the /etc/sysctl.conf file on the new Oracle RAC node:

# +---------------------------------------------------------+
# | ADJUSTING NETWORK SETTINGS                              |
# +---------------------------------------------------------+
# | With Oracle 9.2.0.1 and onwards, Oracle now makes use   |
# | of UDP as the default protocol on Linux for             |
# | inter-process communication (IPC), such as Cache Fusion |
# | and Cluster Manager buffer transfers between instances  |
# | within the RAC cluster. Oracle strongly suggests to     |
# | adjust the default and maximum receive buffer size      |
# | (SO_RCVBUF socket option) to 256 KB, and the default    |
# | and maximum send buffer size (SO_SNDBUF socket option)  |
# | to 256 KB. The receive buffers are used by TCP and UDP  |
# | to hold received data until it is read by the           |
# | application. The receive buffer cannot overflow because |
# | the peer is not allowed to send data beyond the buffer  |
# | size window. This means that datagrams will be          |
# | discarded if they don't fit in the socket receive       |
# | buffer. This could cause the sender to overwhelm the    |
# | receiver.                                               |
# +---------------------------------------------------------+

# +---------------------------------------------------------+
# | Default setting in bytes of the socket "receive" buffer |
# | which may be set by using the SO_RCVBUF socket option.  |
# +---------------------------------------------------------+
net.core.rmem_default=262144

# +---------------------------------------------------------+
# | Maximum setting in bytes of the socket "receive" buffer |
# | which may be set by using the SO_RCVBUF socket option.  |
# +---------------------------------------------------------+
net.core.rmem_max=262144

# +---------------------------------------------------------+
# | Default setting in bytes of the socket "send" buffer    |
# | which may be set by using the SO_SNDBUF socket option.  |
# +---------------------------------------------------------+
net.core.wmem_default=262144

# +---------------------------------------------------------+
# | Maximum setting in bytes of the socket "send" buffer    |
# | which may be set by using the SO_SNDBUF socket option.  |
# +---------------------------------------------------------+
net.core.wmem_max=262144
Then, ensure that each of these parameters are truly in effect by running the following command on the new Oracle RAC node:
# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144


Check and turn off UDP ICMP rejections:

During the Linux installation process, I indicated to not configure the firewall option. (By default the option to configure a firewall is selected by the installer.) This has burned me several times so I like to do a double-check that the firewall option is not configured and to ensure udp ICMP filtering is turned off.

If UDP ICMP is blocked or rejected by the firewall, the Oracle Clusterware software will crash after several minutes of running. When the Oracle Clusterware process fails, you will have something similar to the following in the <machine_name>_evmocr.log file:

08/29/2005 22:17:19
oac_init:2: Could not connect to server, clsc retcode = 9
08/29/2005 22:17:19
a_init:12!: Client init unsuccessful : [32]
ibctx:1:ERROR: INVALID FORMAT
proprinit:problem reading the bootblock or superbloc 22
When experiencing this type of error, the solution is to remove the udp ICMP (iptables) rejection rule - or to simply have the firewall option turned off. The Oracle Clusterware software will then start to operate normally and not crash. The following commands should be executed as the root user account:

  1. Check to ensure that the firewall option is turned off. If the firewall option is stopped (like it is in my example below) you do not have to proceed with the following steps.
    # /etc/rc.d/init.d/iptables status
    Firewall is stopped.

  2. If the firewall option is operating you will need to first manually disable UDP ICMP rejections:
    # /etc/rc.d/init.d/iptables stop
    
    Flushing firewall rules: [  OK  ]
    Setting chains to policy ACCEPT: filter [  OK  ]
    Unloading iptables modules: [  OK  ]

  3. Then, to turn UDP ICMP rejections off for next server reboot (which should always be turned off):
    # chkconfig iptables off 



Configure Network Security on the Openfiler Storage Server


  Perform the following configuration tasks on the network storage server (openfiler1)!

With the network now setup, the next step is to configure network access in Openfiler so that the new Oracle RAC node (linux3) has permissions to the shared iSCSI volumes used in the current Oracle RAC 10g environment. For the purpose of this example, all iSCSI traffic will use the private network interface eth1 which in this article is on the 192.168.2.0 network.

Openfiler administration is performed using the Openfiler Storage Control Center — a browser based tool over an https connection on port 446. For example:

https://openfiler1:446/
From the Openfiler Storage Control Center home page, login as an administrator. The default administration login credentials for Openfiler are:

The first page the administrator sees is the [Accounts] / [Authentication] screen. Configuring user accounts and groups is not necessary for this article and will therefore not be discussed.


Services

This article assumes that the current Oracle RAC 10g environment is operational and therefore the iSCSI services should already be enabled within Openfiler.

To verify the iSCSI services are running, use the Openfiler Storage Control Center and navigate to [Services] / [Enable/Disable]:


Figure 6: Verify iSCSI Services are Enabled

Another method is to SSH into the Openfiler server and verify the iscsi-target service is running:

[root@openfiler1 ~]# service iscsi-target status
ietd (pid 3784) is running...


Network Access Restriction

The next step is to configure network access in Openfiler so that the new Oracle RAC node (linux3) has permissions to the shared iSCSI volumes used in the current Oracle RAC 10g environment.

Again, this task can be completed using the Openfiler Storage Control Center by navigating to [General] / [Local Networks]. The Local Networks screen allows an administrator to setup networks and/or hosts that will be allowed to access resources exported by the Openfiler appliance. For the purpose of this article, we will want to add the new Oracle RAC node individually rather than allowing the entire 192.168.2.0 network have access to Openfiler resources.

When entering the new Oracle RAC node, note that the 'Name' field is just a logical name used for reference only. As a convention when entering nodes, I simply use the node name defined for that IP address. Next, when entering the actual node in the 'Network/Host' field, always use it's IP address even though its host name may already be defined in your /etc/hosts file or DNS. Lastly, when entering actual hosts in our Class C network, use a subnet mask of 255.255.255.255.

It is important to remember that you will be entering the IP address of the private network (eth1) for the new Oracle RAC node.

The following image shows the results of adding the new Oracle RAC node linux3 to the local network configuration:


Figure 7: Configure Openfiler Host Access for new Oracle RAC Node


Current Logical iSCSI Volumes

The current Openfiler configuration contains five logical iSCSI volumes in a single volume group named rac1.

iSCSI / Logical Volumes in Volume Group rac1
Volume Name Volume Description Required Space (MB) Filesystem Type
crs Oracle Clusterware 2,048 iSCSI
asm1 Oracle ASM Volume 1 118,720 iSCSI
asm2 Oracle ASM Volume 2 118,720 iSCSI
asm3 Oracle ASM Volume 3 118,720 iSCSI
asm4 Oracle ASM Volume 4 118,720 iSCSI

To view the available iSCSI volumes from within the Openfiler Storage Control Center, navigate to [Volumes] / [List of Existing Volumes]. There we will see all five logical volumes within the volume group rac1:


Figure 8: Current Logical (iSCSI) Volumes


Grant Access Rights to New Logical Volumes

Before an iSCSI client can have access to any of the iSCSI volumes, it needs to be granted the appropriate permissions. In this section, we need to grant access to each of the five local iSCSI volumes to the new Oracle RAC node linux3.

From the Openfiler Storage Control Center, navigate to [Volumes] / [List of Existing Volumes]. This will present the screen shown in the previous section. For each of the five logical volumes, click on the 'Edit' link (under the Properties column). This will bring up the 'Edit properties' screen for that volume. Scroll to the bottom of this screen; change the access for host linux3-priv from 'Deny' to 'Allow' and click the 'Update' button. Perform this task for all five logical volumes.


Figure 9: Grant Host Access to Logical (iSCSI) Volumes



Configure the iSCSI Initiator


  Configure the iSCSI initiator on the new Oracle RAC node!

An iSCSI client can be any system (Linux, Unix, MS Windows, Apple Mac, etc.) for which iSCSI support (a driver) is available. In our case, the clients are the three Oracle RAC nodes, (linux1, linux2, and linux3), running Red Hat 4.

In this section we will be configuring the iSCSI initiator on the new Oracle RAC node linux3. This involves configuring the /etc/iscsi.conf file on the new Oracle RAC node with the name of the network storage server (openfiler1) so it can discover the current iSCSI volumes.


iSCSI (initiator) service

On the new Oracle RAC node, we have to make sure the iSCSI (initiator) service is up and running. If not installed as part of the operating system setup, the iscsi-initiator-utils RPM (i.e. iscsi-initiator-utils-4.0.3.0-5.i386.rpm) should be downloaded and installed on the new Oracle RAC node.

  The new Oracle RAC node must have the iscsi-initiator-utils RPM installed. To determine if this package is installed, perform the following:
# rpm -qa | grep iscsi
iscsi-initiator-utils-4.0.3.0-5
If not installed, the iscsi-initiator-utils RPM package can be found on disk 3 of 4 of the RHEL4 Update 5 distribution or downloaded from one of the Internet RPM resources.

Use the following command to install the iscsi-initiator-utils RPM package if not present:

# rpm -Uvh iscsi-initiator-utils-4.0.3.0-5.i386.rpm
warning: iscsi-initiator-utils-4.0.3.0-5.i386.rpm: 
  V3 DSA signature: NOKEY, key ID 443e1821
Preparing...                ########################################### [100%]
   1:iscsi-initiator-utils  ########################################### [100%]

After verifying that the iscsi-initiator-utils RPM is installed, the only configuration step required on the new Oracle RAC node (iSCSI client) is to specify the network storage server (iSCSI server) in the /etc/iscsi.conf file. Edit the /etc/iscsi.conf file and include an entry for DiscoveryAddress which specifies the hostname of the Openfiler network storage server. In our case that was:

...
DiscoveryAddress=openfiler1-priv
...
After making the change to the /etc/iscsi.conf file on the new Oracle RAC node, we can start (or restart) the iscsi initiator service on that node:
# service iscsi restart
Searching for iscsi-based multipath maps
Found 0 maps
Stopping iscsid: iscsid not running

Checking iscsi config:  [  OK  ]
Loading iscsi driver:  [  OK  ]
Starting iscsid: [  OK  ]
We should also configure the iSCSI service to be active across machine reboots for the new Oracle RAC node. The Linux command chkconfig can be used to achieve that as follows:
# chkconfig --level 345 iscsi on


Discovering iSCSI Targets

The iSCSI initiator service should now be configured and started on the new Oracle RAC node. In the parent to this article ("Building an Inexpensive Oracle RAC 10g Release 2 on Linux - (CentOS 4.5 / iSCSI)"), we needed go through the arduous task of mapping the iSCSI target names discovered from Openfiler to the local SCSI device name on one of the Oracle RAC nodes. Given that all five logical iSCSI volumes were partitioned and formatted with labels in that article, we don't have to perform that task again. Note that one of the iSCSI volumes was formatted and labeled using OCFS2 while the other four were labeled for use by ASM.

In this section, we simply want to verify that the new Oracle RAC node was able to successfully discover the five logical iSCSI volumes on the Openfiler server.

When the Openfiler server publishes available iSCSI targets, configured clients get the message that new iSCSI disks are now available. This happens when the iscsi-target service gets started/restarted on the Openfiler server or when the iSCSI initiator service is started/restarted on the client. We would see something like this in the client's /var/log/messages file:

...
Jan 21 16:41:29 linux3 iscsi: iscsid startup succeeded
Jan 21 16:41:29 linux3 iscsid[13822]: Connected to Discovery Address 192.168.2.195
Jan 21 16:41:29 linux3 kernel: iscsi-sfnet:host0: Session established
Jan 21 16:41:29 linux3 kernel: iscsi-sfnet:host2: Session established
Jan 21 16:41:29 linux3 kernel: iscsi-sfnet:host1: Session established
Jan 21 16:41:29 linux3 kernel: scsi0 : SFNet iSCSI driver
Jan 21 16:41:29 linux3 kernel: scsi2 : SFNet iSCSI driver
Jan 21 16:41:29 linux3 kernel: scsi1 : SFNet iSCSI driver
Jan 21 16:41:29 linux3 kernel:   Vendor: Openfile  Model: Virtual disk      Rev: 0
Jan 21 16:41:29 linux3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Jan 21 16:41:29 linux3 kernel: SCSI device sda: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:29 linux3 kernel: SCSI device sda: drive cache: write through
Jan 21 16:41:29 linux3 kernel:   Vendor: Openfile  Model: Virtual disk      Rev: 0
Jan 21 16:41:29 linux3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Jan 21 16:41:29 linux3 kernel: SCSI device sda: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:29 linux3 kernel: iscsi-sfnet:host3: Session established
Jan 21 16:41:29 linux3 kernel: iscsi-sfnet:host4: Session established
Jan 21 16:41:29 linux3 kernel: scsi3 : SFNet iSCSI driver
Jan 21 16:41:29 linux3 kernel: SCSI device sda: drive cache: write through
Jan 21 16:41:29 linux3 kernel:  sda: unknown partition table
Jan 21 16:41:29 linux3 kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Jan 21 16:41:29 linux3 kernel:   Vendor: Openfile  Model: Virtual disk      Rev: 0
Jan 21 16:41:29 linux3 scsi.agent[13934]: disk at /devices/platform/host0/target0:0:0/0:0:0:0
Jan 21 16:41:29 linux3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Jan 21 16:41:29 linux3 kernel:   Vendor: Openfile  Model: Virtual disk      Rev: 0
Jan 21 16:41:29 linux3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Jan 21 16:41:29 linux3 kernel: scsi4 : SFNet iSCSI driver
Jan 21 16:41:29 linux3 kernel: SCSI device sdb: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:29 linux3 kernel:   Vendor: Openfile  Model: Virtual disk      Rev: 0
Jan 21 16:41:29 linux3 kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Jan 21 16:41:29 linux3 kernel: SCSI device sdb: drive cache: write through
Jan 21 16:41:29 linux3 scsi.agent[13983]: disk at /devices/platform/host2/target2:0:0/2:0:0:0
Jan 21 16:41:29 linux3 scsi.agent[13996]: disk at /devices/platform/host3/target3:0:0/3:0:0:0
Jan 21 16:41:30 linux3 kernel: SCSI device sdb: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sdb: drive cache: write through
Jan 21 16:41:30 linux3 kernel:  sdb: unknown partition table
Jan 21 16:41:30 linux3 kernel: Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0
Jan 21 16:41:30 linux3 kernel: SCSI device sdc: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sdc: drive cache: write through
Jan 21 16:41:30 linux3 kernel: SCSI device sdc: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sdc: drive cache: write through
Jan 21 16:41:30 linux3 kernel:  sdc: unknown partition table
Jan 21 16:41:30 linux3 kernel: Attached scsi disk sdc at scsi3, channel 0, id 0, lun 0
Jan 21 16:41:30 linux3 kernel: SCSI device sdd: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sdd: drive cache: write through
Jan 21 16:41:30 linux3 kernel: SCSI device sdd: 243138560 512-byte hdwr sectors (124487 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sdd: drive cache: write through
Jan 21 16:41:30 linux3 kernel:  sdd: unknown partition table
Jan 21 16:41:30 linux3 kernel: Attached scsi disk sdd at scsi1, channel 0, id 0, lun 0
Jan 21 16:41:30 linux3 kernel: SCSI device sde: 4194304 512-byte hdwr sectors (2147 MB)
Jan 21 16:41:30 linux3 scsi.agent[14032]: disk at /devices/platform/host4/target4:0:0/4:0:0:0
Jan 21 16:41:30 linux3 scsi.agent[14045]: disk at /devices/platform/host1/target1:0:0/1:0:0:0
Jan 21 16:41:30 linux3 kernel: SCSI device sde: drive cache: write through
Jan 21 16:41:30 linux3 kernel: SCSI device sde: 4194304 512-byte hdwr sectors (2147 MB)
Jan 21 16:41:30 linux3 kernel: SCSI device sde: drive cache: write through
Jan 21 16:41:30 linux3 kernel:  sde: unknown partition table
Jan 21 16:41:30 linux3 kernel: Attached scsi disk sde at scsi4, channel 0, id 0, lun 0
...
The above entries show that the client (linux3) was able to establish the iSCSI sessions with the iSCSI storage server (openfiler1-priv at 192.168.2.195).

Another method not only checks for the existence of the iSCSI volumes, but also displays how the local SCSI device names map to iSCSI targets' host IDs and LUNs. Use the following script which was provided by Martin Jones to display these mappings:

iscsi-ls-map.sh
# ---------------------
# FILE: iscsi-ls-map.sh
# ---------------------

RUN_USERID=root
export RUN_USERID

RUID=`id | awk -F\( '{print $2}'|awk -F\) '{print $1}'`
if [[ ${RUID} != "$RUN_USERID" ]];then
    echo " "
    echo "You must be logged in as $RUN_USERID to run this script."
    echo "Exiting script."
    echo " "
    exit 1
fi

dmesg | grep "^Attach"  \
      | awk -F" " '{ print "/dev/"$4 " " $6 }'  \
      | sed -e 's/,//' | sed -e 's/scsi//'  \
      | sort -n -k2  \
      | sed -e '/disk1/d' > /tmp/tmp_scsi_dev

iscsi-ls | egrep -e "TARGET NAME" -e "HOST ID"   \
         | awk -F" " '{ if ($0 ~ /^TARGET.*/) printf $4; if ( $0 ~ /^HOST/) printf " %s\n",$4}'  \
         | sort -n -k2  \
         | cut -d':' -f2-  \
         | cut -d'.' -f2- > /tmp/tmp_scsi_targets

join -t" " -1 2 -2 2 /tmp/tmp_scsi_dev /tmp/tmp_scsi_targets > MAP


echo "Host / SCSI ID    SCSI Device Name         iSCSI Target Name"
echo "----------------  -----------------------  -----------------"

cat MAP | sed -e 's/ /                 /g'

rm -f MAP

Example run:

# ./iscsi-ls-map.sh
Host / SCSI ID    SCSI Device Name          iSCSI Target Name
----------------  ------------------------  -----------------
0                 /dev/sda                  asm4
1                 /dev/sdd                  asm3
2                 /dev/sdb                  asm2
3                 /dev/sdc                  asm1
4                 /dev/sde                  crs



Create "oracle" User and Directories


  Perform the following tasks on the new Oracle RAC node!

I will be using the Oracle Cluster File System, Release 2 (OCFS2) to store the files required to be shared for the Oracle Clusterware software. When using OCFS2, the UID of the UNIX user "oracle" and GID of the UNIX group "oinstall" must be the same on all of the Oracle RAC nodes in the cluster. If either the UID or GID are different, the files on the OCFS2 file system will show up as "unowned" or may even be owned by a different user. For this article and its parent article, I will use 501 for the "oracle" UID and 501 for the "oinstall" GID.

Note that members of the UNIX group oinstall are considered the "owners" of the Oracle software. Members of the dba group can administer Oracle databases, for example starting up and shutting down databases. In this article, we are creating the oracle user account to have both responsibilities!

  This guide adheres to the Optimal Flexible Architecture (OFA) for naming conventions used in creating the directory structure.


Create Group and User for Oracle

Lets start this section by creating the UNIX oinstall and dba group and oracle user account:

# groupadd -g 501 oinstall
# groupadd -g 502 dba
# useradd -m -u 501 -g oinstall -G dba -d /home/oracle -s /bin/bash -c "Oracle Software Owner" oracle
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)
Set the password for the oracle account:
# passwd oracle
Changing password for user oracle.
New UNIX password: xxxxxxxxxxx
Retype new UNIX password: xxxxxxxxxxx
passwd: all authentication tokens updated successfully.


Verify That the User nobody Exists

Before installing the Oracle software, complete the following procedure to verify that the user nobody exists on the system:

  1. To determine if the user exists, enter the following command:
    # id nobody
    uid=99(nobody) gid=99(nobody) groups=99(nobody)
    If this command displays information about the nobody user, then you do not have to create that user.

  2. If the user nobody does not exist, then enter the following command to create it:
    # /usr/sbin/useradd nobody


Create the Oracle Base Directory

The next step is to create a new directory that will be used to store the Oracle Database software. When configuring the oracle user's environment (later in this section) we will be assigning the location of this directory to the $ORACLE_BASE environment variable.

The following assumes that the directories are being created in the root file system. Please note that this is being done for the sake of simplicity and is not recommended as a general practice. Normally, these directories would be created on a separate file system.

After the directory is created, you must then specify the correct owner, group, and permissions for it. Perform the following on the new Oracle RAC node:

# mkdir -p /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/app/oracle

At the end of this procedure, you will have the following:


Create the Oracle Clusterware Home Directory

Next, create a new directory that will be used to store the Oracle Clusterware software. When configuring the oracle user's environment (later in this section) we will be assigning the location of this directory to the $ORA_CRS_HOME environment variable.

As noted in the previous section, the following assumes that the directories are being created in the root file system. This is being done for the sake of simplicity and is not recommended as a general practice. Normally, these directories would be created on a separate file system.

After the directory is created, you must then specify the correct owner, group, and permissions for it. Perform the following on the new Oracle RAC node:

# mkdir -p /u01/app/crs
# chown -R oracle:oinstall /u01/app/crs
# chmod -R 775 /u01/app/crs

At the end of this procedure, you will have the following:


Create Mount Point for OCFS2 / Clusterware

Let's now create the mount point for the Oracle Cluster File System, Release 2 (OCFS2) that will be used to store the two Oracle Clusterware shared files.

Perform the following on the new Oracle RAC node:

# mkdir -p /u02
# chown -R oracle:oinstall /u02
# chmod -R 775 /u02


Create Login Script for oracle User Account

To ensure that the environment is setup correctly for the "oracle" UNIX userid on the new Oracle RAC node, use the following .bash_profile:

  When you are setting the Oracle environment variables for each Oracle RAC node, ensure to assign each RAC node a unique Oracle SID!

For this example, I used:

  • linux1 : ORACLE_SID=orcl1
  • linux2 : ORACLE_SID=orcl2
  • linux3 : ORACLE_SID=orcl3

Login to the new Oracle RAC node as the oracle user account:

# su - oracle
.bash_profile for Oracle User
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
      . ~/.bashrc
fi

alias ls="ls -FA"

export JAVA_HOME=/usr/local/java

# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1
export ORA_CRS_HOME=/u01/app/crs
export ORACLE_PATH=$ORACLE_BASE/common/oracle/sql:.:$ORACLE_HOME/rdbms/admin
export CV_JDKHOME=/usr/local/java

# Each RAC node must have a unique ORACLE_SID. (i.e. orcl1, orcl2, orcl3,...)
export ORACLE_SID=orcl3

export PATH=.:${JAVA_HOME}/bin:${PATH}:$HOME/bin:$ORACLE_HOME/bin
export PATH=${PATH}:/usr/bin:/bin:/usr/bin/X11:/usr/local/bin
export PATH=${PATH}:$ORACLE_BASE/common/oracle/bin
export ORACLE_TERM=xterm
export TNS_ADMIN=$ORACLE_HOME/network/admin
export ORA_NLS10=$ORACLE_HOME/nls/data
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:$ORACLE_HOME/oracm/lib
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib
export CLASSPATH=$ORACLE_HOME/JRE
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/jlib
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/rdbms/jlib
export CLASSPATH=${CLASSPATH}:$ORACLE_HOME/network/jlib
export THREADS_FLAG=native
export TEMP=/tmp
export TMPDIR=/tmp



Configure the Linux Server for Oracle


  Perform the following tasks on the new Oracle RAC node!

The kernel parameters and shell limits discussed in this section will need to be defined on the new Oracle RAC node every time the machine is booted. This section will not go into great depth in explaining the purpose of those kernel parameters that are required by Oracle (These parameters are described in detail in the parent to this article). Provided in this section, however, are instructions on how to set all required kernel parameters for Oracle and how to have them enabled when the node boots. Further instructions for configuring kernel parameters in a startup script (/etc/sysctl.conf) is included in the section "All Startup Commands for New Oracle RAC Node".


Swap Space Considerations


Configuring Kernel Parameters and Shell Limits

The kernel parameters and shell limits presented in this section are recommended values only as documented by Oracle. For production database systems, Oracle recommends that you tune these values to optimize the performance of the system.

On the new Oracle RAC node, verify that the kernel parameters described in this section are set to values greater than or equal to the recommended values. Also note that when setting the four semaphore values that all four values need to be entered on one line.


Setting Shared Memory / Semaphores / File Handles / Local IP Range

Set the following kernel parameters in the /etc/sysctl.conf file on the new Oracle RAC node.
cat >> /etc/sysctl.conf <<EOF
# +---------------------------------------------------------+
# | ADJUSTING ADDITIONAL KERNEL PARAMETERS FOR ORACLE       |
# +---------------------------------------------------------+
# | Configure the kernel parameters for all Oracle Linux    |
# | servers by setting shared memory and semaphores,        |
# | setting the maximum amount of file handles, and setting |
# | the IP local port range.                                |
# +---------------------------------------------------------+

# +---------------------------------------------------------+
# | SHARED MEMORY                                           |
# +---------------------------------------------------------+
kernel.shmmax=2147483648

# +---------------------------------------------------------+
# | SEMAPHORES                                              |
# | ----------                                              |
# |                                                         |
# | SEMMSL_value  SEMMNS_value  SEMOPM_value  SEMMNI_value  |
# |                                                         |
# +---------------------------------------------------------+
kernel.sem=250 32000 100 128

# +---------------------------------------------------------+
# | FILE HANDLES                                            |
# ----------------------------------------------------------+
fs.file-max=65536

# +---------------------------------------------------------+
# | LOCAL IP RANGE                                          |
# ----------------------------------------------------------+
net.ipv4.ip_local_port_range=1024 65000
EOF


Setting Shell Limits for the oracle User

To improve the performance of the software on Linux systems, Oracle recommends you increase the following shell limits for the oracle user:

Shell Limit Item in limits.conf Hard Limit
Maximum number of open file descriptors nofile 65536
Maximum number of processes available to a single user nproc 16384

To make these changes, run the following as root:

cat >> /etc/security/limits.conf <<EOF
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
EOF

cat >> /etc/pam.d/login <<EOF
session required /lib/security/pam_limits.so
EOF
Update the default shell startup file for the "oracle" UNIX account.


Activating All Kernel Parameters for the System

At this point, we have covered all of the required Linux kernel parameters needed for a successful Oracle installation and configuration. The sections above configured the Linux system to persist each of the kernel parameters through reboots on system startup by placing them all in the /etc/sysctl.conf file.

We could reboot at this point to ensure all of these parameters are set in the kernel or we could simply "run" the /etc/sysctl.conf file by running the following command as root on the new Oracle RAC node:

# sysctl -p

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144
kernel.shmmax = 2147483648
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000


Setting the Correct Date and Time on the new Oracle RAC Node

When adding the new Oracle RAC node to the cluster, the Oracle Universal Installer (OUI) copies the Oracle Clusterware and Oracle Database software from the source RAC node (linux1 in this article) to the new node in the cluster (linux3). During the remote copy process, the OUI will execute the UNIX "tar" command on the remote node (linux3) to extract the files that were archived and copied over. If the date and time on the node performing the install is greater than that of the node it is copying to, the OUI will throw an error from the "tar" command indicating it is attempting to extract files stamped with a time in the future:

Error while copying directory 
    /u01/app/crs with exclude file list 'null' to nodes 'linux3'.
[PRKC-1002 : All the submitted commands did not execute successfully]
---------------------------------------------
linux3:
   /bin/tar: ./bin/lsnodes: time stamp 2008-02-13 09:21:34 is 735 s in the future
   /bin/tar: ./bin/olsnodes: time stamp 2008-02-13 09:21:34 is 735 s in the future
   ...(more errors on this node)

Please note that although this would seem like a severe error from the OUI, it can safely be disregarded as a warning. The "tar" command DOES actually extract the files; however, when you perform a listing of the files (using ls -l) on the remote node (the new Oracle RAC node), they will be missing the time field until the time on the remote server is greater than the timestamp of the file.

Before attempting to add the new node, ensure that all nodes in the cluster are set as closely as possible to the same date and time. Oracle strongly recommends using the Network Time Protocol feature of most operating systems for this purpose, with all nodes using the same reference Network Time Protocol server.

Accessing a Network Time Protocol server, however, may not always be an option. In this case, when manually setting the date and time for the nodes in the cluster, ensure that the date and time of the node you are performing the software installations from (linux1) is less than the new node being added to the cluster (linux3). I generally use a 20 second difference as shown in the following example:

Show the date and time from linux1:

# date
Thu Feb 14 00:17:00 EST 2008

Setting the date and time on the new Oracle RAC node linux3:

# date -s "2/14/2008 00:17:20"

The RAC configuration described in this article does not make use of a Network Time Protocol server.



Configure the "hangcheck-timer" Kernel Module


  Perform the following tasks on the new Oracle RAC node!

Oracle 9.0.1 and 9.2.0.1 used a userspace watchdog daemon called watchdogd to monitor the health of the cluster and to restart a RAC node in case of a failure. Starting with Oracle 9.2.0.2 (and still available in Oracle10g Release 2), the watchdog daemon has been deprecated by a Linux kernel module named hangcheck-timer which addresses availability and reliability problems much better. The hang-check timer is loaded into the Linux kernel and checks if the system hangs. It will set a timer and check the timer after a certain amount of time. There is a configurable threshold to hang-check that, if exceeded will reboot the machine. Although the hangcheck-timer module is not required for Oracle Clusterware (Cluster Manager) operation, it is highly recommended by Oracle.


The hangcheck-timer.ko Module

The hangcheck-timer module uses a kernel-based timer that periodically checks the system task scheduler to catch delays in order to determine the health of the system. If the system hangs or pauses, the timer resets the node. The hangcheck-timer module uses the Time Stamp Counter (TSC) CPU register which is a counter that is incremented at each clock signal. The TCS offers much more accurate time measurements since this register is updated by the hardware automatically.

Much more information about the hangcheck-timer project can be found here.


Installing the hangcheck-timer.ko Module

The hangcheck-timer was normally shipped only by Oracle, however, this module is now included with Red Hat Linux AS starting with kernel versions 2.4.9-e.12 and higher. The hangcheck-timer should already be included. Use the following to ensure that you have the module included:
# find /lib/modules -name "hangcheck-timer.ko"
/lib/modules/2.6.9-55.EL/kernel/drivers/char/hangcheck-timer.ko
In the above output, we care about the hangcheck timer object (hangcheck-timer.ko) in the /lib/modules/2.6.9-55.EL/kernel/drivers/char directory.


Configuring and Loading the hangcheck-timer Module

There are two key parameters to the hangcheck-timer module:

  The two hangcheck-timer module parameters indicate how long a RAC node must hang before it will reset the system. A node reset will occur when the following is true:
system hang time > (hangcheck_tick + hangcheck_margin)


Configuring Hangcheck Kernel Module Parameters

Each time the hangcheck-timer kernel module is loaded (manually or by Oracle) it needs to know what value to use for each of the two parameters we just discussed: (hangcheck-tick and hangcheck-margin).

These values need to be available after each reboot of the Linux server. To do this, make an entry with the correct values to the /etc/modprobe.conf file as follows:

# su -
# echo "options hangcheck-timer hangcheck_tick=30 hangcheck_margin=180" >> /etc/modprobe.conf
Each time the hangcheck-timer kernel module gets loaded, it will use the values defined by the entry I made in the /etc/modprobe.conf file.


Manually Loading the Hangcheck Kernel Module for Testing

Oracle is responsible for loading the hangcheck-timer kernel module when required. It is for this reason that it is not required to perform a modprobe or insmod of the hangcheck-timer kernel module in any of the startup files (i.e. /etc/rc.local).

It is only out of pure habit that I continue to include a modprobe of the hangcheck-timer kernel module in the /etc/rc.local file. Someday I will get over it, but realize that it does not hurt to include a modprobe of the hangcheck-timer kernel module during startup.

So to keep myself sane and able to sleep at night, I always configure the loading of the hangcheck-timer kernel module on each startup as follows:

# echo "/sbin/modprobe hangcheck-timer" >> /etc/rc.local

  You don't have to manually load the hangcheck-timer kernel module using modprobe or insmod after each reboot. The hangcheck-timer module will be loaded by Oracle (automatically) when needed.

Now, to test the hangcheck-timer kernel module to verify it is picking up the correct parameters we defined in the /etc/modprobe.conf file, use the modprobe command. Although you could load the hangcheck-timer kernel module by passing it the appropriate parameters (e.g. insmod hangcheck-timer hangcheck_tick=30 hangcheck_margin=180), we want to verify that it is picking up the options we set in the /etc/modprobe.conf file.

To manually load the hangcheck-timer kernel module and verify it is using the correct values defined in the /etc/modprobe.conf file, run the following command:

# su -
# modprobe hangcheck-timer
# grep Hangcheck /var/log/messages | tail -2
Feb 14 01:22:52 linux3 kernel: Hangcheck: starting hangcheck timer 0.9.0 (tick is 30 seconds, margin is 180 seconds).
Feb 14 01:22:52 linux3 kernel: Hangcheck: Using monotonic_clock().



Configure RAC Nodes for Remote Access using SSH


  Perform the following configuration procedures on linux1 and the new Oracle RAC node!

During the creation of the existing two-node cluster, the installation of Oracle Clusterware and the Oracle Database software were only performed from one node in the RAC cluster — namely from linux1 as the oracle user account. The Oracle Universal Installer (OUI) on that particular node then would use the ssh and scp commands to run remote commands on and copy files (the Oracle software) to all other nodes within the RAC cluster. The oracle user account on the node running the OUI (runInstaller) had to be trusted by all other nodes in the RAC cluster. This meant that the oracle user account had to run the secure shell commands (ssh or scp) on the Linux server executing the OUI against all other Linux servers in the cluster without being prompted for a password. The same security requirements hold true for this article. User equivalence will be configured so that the Oracle Clusterware and Oracle Database software will be securely copied from linux1 to the new Oracle RAC node (linux3) using ssh and scp without being prompted for a password.

As was the case when configuring the existing two-node cluster, this article assumes the Oracle software installation to the new Oracle RAC node will be performed from linux1. This section provides the methods required for configuring SSH1, an RSA key, and user equivalence for the new Oracle RAC node.


Configuring the Secure Shell

To determine if SSH is installed and running on the new Oracle RAC node, enter the following command:
# pgrep sshd
3695
If SSH is running, then the response to this command is a list of process ID number(s).


Creating the RSA Keys on the new Oracle RAC Node

The first step in configuring SSH is to create an RSA public/private key pair on the new Oracle RAC node. An RSA public/private key should already exist on both of the two nodes in the current two-node cluster. The command to do this will create a public and private key for RSA (for a total of two keys per node). The content of the RSA public keys will then be copied into an authorized key file on linux1 which is then distributed to all other Oracle RAC nodes in the cluster.

Use the following steps to create the RSA key pair from the new Oracle RAC node (linux3);

  1. Logon as the "oracle" UNIX user account.
    # su - oracle

  2. If necessary, create the .ssh directory in the "oracle" user's home directory and set the correct permissions on it:
    $ mkdir -p ~/.ssh
    $ chmod 700 ~/.ssh

  3. Enter the following command to generate an RSA key pair (public and private key) for the SSH protocol:
    $ /usr/bin/ssh-keygen -t rsa
    At the prompts:
    • Accept the default location for the key files.
    • Enter and confirm a pass phrase. This should be different from the "oracle" UNIX user account password however it is not a requirement.

    This command will write the public key to the ~/.ssh/id_rsa.pub file and the private key to the ~/.ssh/id_rsa file. Note that you should never distribute the private key to anyone!


Updating and Distributing the "authorized key file" from linux1

Now that the new Oracle RAC node contains a public and private key for RSA, you will need to update the authorized key file on linux1 to add (append) the new RSA public key from linux3. An authorized key file is nothing more than a single file that contains a copy of everyone's (every node's) RSA public key. Once the authorized key file contains all of the public keys, it is then distributed to all other nodes in the cluster.

Complete the following steps on linux1 to update and then distribute the authorized key file to all nodes in the Oracle RAC cluster.

  1. As the "oracle" UNIX user account, verify that an authorized key file currently exists on the node linux1 (~/.ssh/authorized_keys). The authorized key file should already exist from the initial installation of Oracle RAC.
    $ cd ~/.ssh
    $ ls -l *.pub
    -rw-r--r-- 1 oracle oinstall 223 Sep  2 01:18 id_rsa.pub

  2. In this step, use SCP (Secure Copy) or SFTP (Secure FTP) to copy the content of the ~/.ssh/id_rsa.pub public key from the new Oracle RAC node to the authorized key file on linux1. You will be prompted for the oracle UNIX user account password for the new Oracle RAC node.

    Again, this task will be performed from linux1.

    $ ssh linux3 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
    The authenticity of host 'linux3 (192.168.1.107)' can't be established.
    RSA key fingerprint is f5:38:37:e8:84:4e:bd:6d:6b:25:f7:94:58:e8:b2:7a.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'linux3,192.168.1.107' (RSA) to the list of known hosts.
    oracle@linux3's password: xxxxx

      The first time you use SSH to connect to a node from a particular system, you will see a message similar to the following:
    The authenticity of host 'linux3 (192.168.1.107)' can't be established.
    RSA key fingerprint is f5:38:37:e8:84:4e:bd:6d:6b:25:f7:94:58:e8:b2:7a.
    Are you sure you want to continue connecting (yes/no)? yes
    Enter yes at the prompt to continue. You should not see this message again when you connect from this system to the same node.

  3. At this point, we have the RSA public key from every node in the cluster (including the new Oracle RAC node) in the authorized key file on linux1. We now need to copy it to all other nodes in the cluster. Use the scp command to copy the authorized key file to all remaining nodes in the RAC cluster:
    $ scp ~/.ssh/authorized_keys linux2:.ssh/authorized_keys
    Enter passphrase for key '/home/oracle/.ssh/id_rsa': xxxxx
    authorized_keys                             100%  669     0.7KB/s   00:00
    
    $ scp ~/.ssh/authorized_keys linux3:.ssh/authorized_keys
    oracle@linux3's password: xxxxx
    authorized_keys                             100%  669     0.7KB/s   00:00

  4. Change the permission of the authorized key file on all Oracle RAC nodes in the cluster by logging into the node and running the following:
    $ chmod 600 ~/.ssh/authorized_keys

  5. At this point, if you use ssh to log in to or run a command on the new Oracle RAC node, you are prompted for the pass phrase that you specified when you created the RSA key. For example, test the following from linux1:
    $ ssh linux3 hostname
    Enter passphrase for key '/home/oracle/.ssh/id_rsa': xxxxx
    linux3

      If you see any other messages or text, apart from the host name, then the Oracle installation can fail. Make any changes required to ensure that only the host name is displayed when you enter these commands. You should ensure that any part of a login script(s) that generate any output, or ask any questions, are modified so that they act only when the shell is an interactive shell.


Enabling SSH User Equivalency for the Current Shell Session

When running the addNode.sh script from linux1 (which runs the OUI), it will need to run the secure shell tool commands (ssh and scp) on the new Oracle RAC node without being prompted for a pass phrase. Even though SSH is now configured on all Oracle RAC nodes in the cluster, using the secure shell tool commands will still prompt for a pass phrase. Before running the addNode.sh script, you need to enable user equivalence for the terminal session you plan to run the script from. For the purpose of this article, the addNode.sh script will be run from linux1.

User equivalence will need to be enabled on any new terminal shell session on linux1 before attempting to run the addNode.sh script. If you log out and log back in to the node you will be performing the Oracle installation from, you must enable user equivalence for the terminal shell session as this is not done by default.

To enable user equivalence for the current terminal shell session, perform the following steps:

  1. Logon to the node where you want to run the addNode.sh script from (linux1) as the "oracle" UNIX user account.
    # su - oracle

  2. Enter the following commands:
    $ exec /usr/bin/ssh-agent $SHELL
    $ /usr/bin/ssh-add
    Enter passphrase for /home/oracle/.ssh/id_rsa: xxxxx
    Identity added: /home/oracle/.ssh/id_rsa (/home/oracle/.ssh/id_rsa)
    At the prompt, enter the pass phrase for each key that you generated.

  3. If SSH is configured correctly, you will be able to use the ssh and scp commands without being prompted for a password or pass phrase from this terminal session:
    $ ssh linux1 "date;hostname"
    Fri Feb 22 12:13:57 EST 2008
    linux1
    
    $ ssh linux2 "date;hostname"
    Fri Feb 22 12:14:43 EST 2008
    linux2
    
    $ ssh linux3 "date;hostname"
    Fri Feb 2