This chapter describes how to prepare the servers for an enterprise deployment.
It contains the following sections:
Before you deploy Oracle Fusion Middleware on new hardware, you must set up the servers you plan to use so that the Oracle Software can work in an optimum fashion. Specifically, you must ensure that:
The servers are running a certified operating system with the required software patches installed.
You have configured the UNIX Kernel correctly.
You have created Users and Groups to own the Oracle software.
The settings described in this chapter are only a guide. After using your Oracle software, you should use operating system utilities to tune the configuration to ensure that you are maximizing the potential of your servers.
Ensure that the server and operating system that you plan to use is a certified combination for the products you plan to use. Refer to Oracle Certification Matrix for details.
In order to use a server in an Oracle Enterprise Deployment you must verify that it meets the minimum specification described in Section 2.3, "Hardware Requirements for an Enterprise Deployment.". If you plan to use a different deployment architecture, for example, one with more or fewer components deployed on a different number of boxes, you must check Oracle Fusion Middleware System Requirements and Specifications to ensure that you have the minimum specification to support the products you plan to deploy on these servers.
If you are deploying to a virtual server environment, such as Oracle Exalogic, ensure that each of the virtual servers meets the minimum requirements.
Ensure that you have sufficient local disk and shared storage is configured as described in Chapter 4, "Preparing Storage for an Enterprise Deployment."
Allow sufficient swap and temporary space. Specifically:
Swap Space–The system must have at least 500MB.
Temporary Space–There must be a minimum of 500MB of free space in /tmp.
Before starting your operating provisioning you must perform the following tasks:
Install a certified operating system.
Install all necessary patches and packages as listed in the Oracle Fusion Middleware Release Notes.
This section includes the following topics:
The kernel parameter and shell limit values shown below are recommended values only. For production database systems, Oracle recommends that you tune these values to optimize the performance of the system. See your operating system documentation for more information about tuning kernel parameters.
Kernel parameters must be set to a minimum of those below on all nodes in the topology.
The values in the following table are the current Linux recommendations. For the latest recommendations for Linux and other operating systems, see Oracle Fusion Middleware System Requirements and Specifications.
If you are deploying a database onto the host, you might need to modify additional kernel parameters. Refer to the 11g Release 2 Oracle Grid Infrastructure Installation Guide for your platform.
Table 5-1 UNIX Kernel Parameters
| Parameter | Value |
|---|---|
|
kernel.sem |
256 32000 100 142 |
|
kernel.shmmax |
4294967295 |
To set these parameters:
Log in as root and add or amend the entries in the file /etc/sysctl.conf.
Save the file.
Activate the changes by issuing the command:
/sbin/sysctl -p
On all UNIX operating systems, the minimum Open File Limit should be 4096.
Note:
The following examples are for Linux operating systems. Consult your operating system documentation to determine the commands to be used on your system.
You can see how many files are open with the following command:
/usr/sbin/lsof | wc -l
To check your open file limits, use the commands below.
C shell:
limit descriptors
Bash:
ulimit -n
To change the shell limits, login as root and edit the /etc/security/limits.conf file.
Add the following lines:
* soft nofile 4096 * hard nofile 65536 * soft nproc 2047 * hard nproc 16384
For the most recent suggested values, see Oracle Fusion Middleware System Requirements and Specifications.
After editing the file, reboot the machine.
Before you begin the installation of the Oracle software, ensure that your local hosts file is formatted like this:
IP_Address Fully_Qualified_Name Short_Name
Your operating system configuration can influence the behavior of characters supported by Oracle Fusion Middleware products.
On UNIX operating systems, Oracle highly recommends that you enable Unicode support by setting the LANG and LC_ALL environment variables to a locale with the UTF-8 character set. This enables the operating system to process any character in Unicode. Oracle SOA Suite technologies, for example, are based on Unicode.
If the operating system is configured to use a non-UTF-8 encoding, Oracle SOA Suite components may function in an unexpected way. For example, a non-ASCII file name might make the file inaccessible and cause an error. Oracle does not support problems caused by operating system constraints.
The enterprise deployment requires that certain hosts, such as those running the WebLogic Administration Server or SOA managed servers, use virtual IP addresses. You must enable the appropriate IP address on each server.
Section 3.5, "About IP Addresses and Virtual IP Addresses," describes the mapping of IP Addresses to servers.
This section includes the following topics:
Virtual IP Addresses are required for failover of the WebLogic Administration Server, regardless of whether other Oracle Fusion Middleware components are installed later or not.
You associate the Administration Server with a virtual IP address. This allows the Administration Server to be started on a different host if the primary host fails.
Check that the virtual host is enabled as follows:
Table 5-2 Virtual Hosts for Domain
| VIP | Enabled on Host |
|---|---|
|
ADMINVHN.mycompany.com |
IDMHOST1 |
|
OIMHOST1VHN.mycompany.com |
IDMHOST1 |
|
OIMHOST2VHN.mycompany.com |
IDMHOST2 |
|
SOAHOST1VHN.mycompany.com |
IDMHOST1 |
|
SOAHOST2VHN.mycompany.com |
IDMHOST2 |
Note:
This is the DNS name associated with the floating IP address. It is not the DNS name of the virtual host configured on the load balancer.
To enable a virtual IP address, you must associate the IP address with a network interface and set the netmask of that interface. On a Linux host, perform the steps listed in this section. For other operating systems, refer to your manufacturer documentation.
To enable the virtual IP address, you use the ifconfig command to set the IP address and netmask of the interface. Then you use the arping command to enable your network to register the new location of the virtual IP address. Run the following commands as root:
/sbin/ifconfig interface:index IPAddress netmask netmask /sbin/arping -q -U -c 3 -I interface IPAddress
where interface is eth0, eth1, and so forth, and index is 0, 1, 2, and so forth.
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0 /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
Validate that the address is available by pinging it from another node, for example:
/bin/ping 100.200.140.206
The shared storage configured in Chapter 4, "Preparing Storage for an Enterprise Deployment" must be available on the hosts that use it. Mount the shared storage to all servers that require access to it.
Each host must have appropriate privileges set within the NAS or SAN so that it can write to the shared storage.
Follow the best practices of your organization for mounting shared storage. This section provides an example of how to do this on UNIX or Linux using NFS storage.
You must create and mount shared storage locations so that IDMHOST1 and IDMHOST2 can see the same location for binary installation in two separate volumes.
You use the following command to mount shared storage from a NAS storage device to a linux host. If you are using a different type of storage device or operating system, refer to your manufacturer documentation for information about how to do this.
Note:
The user ID used to create a shared storage file system owns and has read, write, and execute privileges for those files. Other users in the operating system group can read and execute the files, but they do not have write privileges. For more information about installation and configuration privileges, see the "Understanding Installation and Configuration Privileges and Users" section in the Oracle Fusion Middleware Installation Planning Guide.
nasfiler is the shared storage filer.
From IDMHOST1:
mount -t nfs nasfiler:VOL1/OracleIDM /u01/oracle
From IDMHOST2:
mount -t nfs nasfiler:VOL1/OracleIDM /u01/oracle
Validating the Shared Storage Configuration
Ensure that you can read and write files to the newly mounted directories by creating a test file in the shared storage location you just configured.
For example:
$ cd newly mounted directory
$ touch testfile
Verify that the owner and permissions are correct:
$ ls -l testfile
Then remove the file:
$ rm testfile
Note:
The shared storage can be a NAS or SAN device. The following illustrates an example of creating storage for a NAS device from IDMHOST1. The options may differ depending on the specific storage device.
mount -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768, wsize=32768 nasfiler:VOL1/OracleIDM /u01/oracle
Contact your storage vendor and machine administrator for the correct options for your environment.
Groups
You must create the following groups on each node.
oinstall
dba
Users
You must create the following users on each node.
oracle–The user that owns the Oracle software. You may use a different name. The primary group for this account must be oinstall. The account must also be in the dba group.
nobody–An unprivileged user.
Notes:
The group oinstall must have write privileges to all the file systems on shared and local storage that are used by the Oracle software.
Each group must have the same Group ID on every node.
Each user must have the same User ID on every node.
You can install Oracle Identity Management components on a multihomed system. A multihomed system is has with multiple IP addresses. Typically, each IP address is associated with a different network card on the system. Each IP address is associated with a host name. You can create aliases for each host name.
The Installer retrieves the fully qualified domain name from the first entry in /etc/hosts file on UNIX. For example, if your file looks like the following sample file, the Installer retrieves MYHOST1.mycompany.com for configuration:
127.0.0.1 localhost.localdomain localhost 10.222.333.444 MYHOST1.mycompany.com myhost1 20.222.333.444 DEVHOST2.mycompany.com devhost2