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.
In the context of Exalogic, the servers are either compute nodes in physical Exalogic or vServers in virtual Exalogic.
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 3.6, "Hardware Requirements for the Identity Management on Exalogic." 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 for Oracle Identity and Access Management 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, 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 7, "Preparing Storage for an Enterprise Deployment."
Allow sufficient swap and temporary space. Specifically:
Swap Space–The system must have at least 512MB.
Temporary Space–There must be a minimum of 2GB of free space in /tmp.
Before performing Identity and Access Management Deployment, you must perform the following tasks:
Install a certified operating system.
Install all necessary patches and packages as listed in the Release Notes.
This section includes the following topics:
The kernel parameter and shell limit values shown below are recommended values only. For production 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 9-1 UNIX Kernel Parameters
| Parameter | Value |
|---|---|
|
kernel.sem |
256 32000 100 142 |
|
kernel.shmmax |
2147483648 or higher |
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
Note:
If your limits are already set higher than these values, you do not need to change them.To change the shell limits, login as root and edit the /etc/security/limits.conf file.
Add the following lines:
* soft nofile 65536 * hard nofile 150000 * soft nproc 2048 * hard nproc 16384
Oracle Linux 6 and Red Hat Enterprise Linux 6 Only
To change the shell limits, login as root and edit the /etc/security/limits.conf file.
Add the following lines:
* soft nofile 65536 * hard nofile 150000
Also edit: /etc/security/limits.d/90-nproc.conf
Add the following lines:
* soft nproc 2048 * 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 /etc/hosts file is formatted like this:
IP_Address Fully_Qualified_Name Short_Name
For example
192.168.30.1 oimhost1vhn.mycompany.com oimhost1vhn 192.168.30.2 oimhost2vhn.mycompany.com oimhost2vhn 192.168.30.3 soahost1vhn.mycompany.com soahost1vhn 192.168.30.4 soahost2vhn.mycompany.com soahost2vhn 192.168.50.1 idstore.mycompany.com idstore 192.168.50.2 idminternal.mycompany.com idminternal 192.168.10.1 iamhost1.mycompany.com iamhost1 192.168.10.2 iamhost2.mycompany.com iamhost2 192.168.10.1 webhost1.mycompany.com webhost1 192.168.10.2 webhost2.mycompany.com webhost2
Note:
If idstore.mycompany.com and idminternal.mycompany.com have DNS entries, you do not need to add to the /etc/hosts.
If using virtual Exalogic, entries for IAMHOSTs should be replaced with entries for OAMHOSTs and OIMHOSTs
By default huge pages are enabled in Exalogic compute nodes, verify the existing allocation by running.
grep Huge /proc/meminfo
Set the recommended Huge Page allocation to 25000.
To set the Huge Page allocation, run the following command as root in the compute node:
echo 25000 > /proc/sys/vm/nr_hugepages
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 environment variable 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.
Set the LANGUAGE environment variable as follows:
LANG=en_GB.UTF-8
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.
Configure the vServer to access your corporate DNS Servers. To do this, update DNS settings by updating the file /etc/resolv.conf.
If you are using NFS Version 4, configure a directory service or an NIS (Network Information Server). If your organization does not have one already, use the built-in one on the ZFS storage appliance. See Configuring NFS Version 4 (NFSv4) on Exalogic in the Oracle Fusion Middleware Exalogic Machine Owner's Guide for more information.
Once you have configured your NIS server, configure each compute node to use it. If you are using the built-in NIS server on the Exalogic ZFS appliance, use the following steps:
Determine the name of the NIS server by logging into the storage BUI using the URL:
https://exalogicsn01-priv:215
Click Configuration, Services, and then NIS.
Make a note of one of the listed NIS servers.
Login to the compute node as root.
Edit the /etc/idmapd.conf configuration file:
vi /etc/idmapd.conf
Set the domain value, as in the following example:
Domain = mycompany.com
Restart the rpcidmapd service:
service rpcidmapd restart NISDOMAIN=mycompany.com
Update the /etc/yp.conf configuration file, and set the correct domain value, as in the following example:
vi /etc/yp.conf
Add the following line:
domain mycompany.com server NIS_Server_hostname_or_IP
Where mycompany.com is the example domain and NIS_Server_hostname_or_IP is the host name or IP address of the NIS server. You must replace these sample values with values appropriate for your environment.
Set NIS domain name on the command line:
domainname NIS_DOMAIN_NAME
For example:
domainname nisdomain.example.com
Edit the /etc/nsswitch.conf configuration file:
vi /etc/nsswitch.conf
Change the following entries:
passwd: files nis shadow: files nis group: files nis automount: files nis nisplus aliases: files nis nisplus
Restart the rpcidmapd service:
service rpcidmapd restart
Edit the file /etc/sysconfig/network and add the following line:
NISDOMAIN=mycompany.com
Restart the ypbind service by running the following command:
service ypbind restart
Check the yp service by running this command:
ypwhich
Verify if you can access Oracle user accounts:
ypcat passwd
Add ypbind to your boot sequence, so that it starts automatically after rebooting.
chkconfig ypbind on
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.
Chapter 4, "Networking Overview" describes the mapping of IP Addresses to servers.
This section includes the following topics:
Section 9.8.1, "Summary of Exalogic Physical Virtual IP Addresses"
Section 9.8.2, "Summary of Exalogic Logical Virtual IP Addresses"
Section 9.8.3, "Enabling a Virtual IP Address on a Network Interface"
Section 9.8.4, "Verifying the Required Virtual IP Addresses on the Network"
For all communications over the IPoIB network, the IAMHOST compute nodes and WebLogic Server managed servers use the default bond0 IP addresses assigned when the Exalogic hardware was commissioned.
Table 9-3 lists the Virtual IPs you must define for the Access Manager and Oracle Identity Manager Managed Servers on IAMHOST1 and IAMHOST2.
For instructions on defining these virtual IP addresses, see Section 9.8.3, "Enabling a Virtual IP Address on a Network Interface."
Table 9-2 Physical Virtual IP Addresses Associated with IPoIB and EoIB Network interfaces
| Interface | Address Example | Netmask Example | Used By | Virtual Host Name | Default Physical HostFoot 1 |
|---|---|---|---|---|---|
|
BOND1:1 |
10.10.30.1 |
255.255.224.0 |
OTD Administration Server |
IAMHOST1 |
|
|
BOND1:1 |
10.10.30.2 |
255.255.224.0 |
Administration Server (IADADMINVHN) |
IAMHOST1 |
|
|
BOND1:2 |
10.10.30.3 |
255.255.224.0 |
Administration Server (IGDADMINVHN) |
IAMHOST1 |
|
|
BOND0:1 |
192.168.30.1 |
255.255.240.0 |
WLS_OIM1 |
OIMHOST1VHN |
IAMHOST1 |
|
BOND0:1 |
192.168.30.2 |
255.255.240.0 |
WLS_OIM2 |
OIMHOST2VHN |
IAMHOST2 |
|
BOND0:2 |
192.168.30.3 |
255.255.240.0 |
WLS_SOA1 |
SOAHOST1VHN |
IAMHOST1 |
|
BOND0:2 |
192.168.30.4 |
255.255.240.0 |
WLS_SOA2 |
SOAHOST2VHN |
IAMHOST2 |
|
BOND0:1 |
192.168.50.1 |
255.255.224.0 |
OTD Failover group for SOA |
IDMINTERNAL |
IAMHOST1 |
|
BOND0:1 |
192.168.50.2 |
255.255.224.0 |
OTD Failover group for OUD |
IDSTORE |
IAMHOST2 |
Footnote 1 Default Physical Host is the compute Node used in a physical exalogic deployment
Note:
Physical IP addresses are managed manually. Oracle Traffic Director IP Addresses are handled by Oracle Traffic Director.For all communications over the IPoIB network, the WEBHOST compute nodes and WebLogic Server managed servers use the default bond0 IP addresses assigned when the Exalogic hardware was commissioned.
Table 9-3 lists the Virtual IPs you must define for the Access Manager and Oracle Identity Manager Managed Servers on IAMHOST1 and IAMHOST2.
For instructions on defining these virtual IP addresses, see Section 9.8.3, "Enabling a Virtual IP Address on a Network Interface."
Table 9-3 Logical Virtual IP Addresses Associated with IPoIB Network interfaces
| Interface | Address Example | Netmask Example | Used By | Virtual Host Name | Default Virtual HostFoot 1 |
|---|---|---|---|---|---|
|
BOND1:1 |
10.10.30.1 |
255.255.224.0 |
OTD Administration Server |
WEBHOST1 |
|
|
BOND1:2 |
10.10.30.2 |
255.255.224.0 |
Administration Server (IADADMINVHN) |
OAMHOST1 |
|
|
BOND1:3 |
10.10.30.3 |
255.255.224.0 |
Administration Server (IGDADMINVHN) |
OIMHOST1 |
|
|
BOND0:1 |
192.168.30.1 |
255.255.240.0 |
WLS_OIM1 |
OIMHOST1VHN |
OIMHOST1 |
|
BOND0:1 |
192.168.30.2 |
255.255.240.0 |
WLS_OIM2 |
OIMHOST2VHN |
OIMHOST2 |
|
BOND0:2 |
192.168.30.3 |
255.255.240.0 |
WLS_SOA1 |
SOAHOST1VHN |
OIMHOST1 |
|
BOND0:2 |
192.168.30.4 |
255.255.240.0 |
WLS_SOA2 |
SOAHOST2VHN |
OIMHOST2 |
Footnote 1 Default Virtual Host is the vServer used in the Virtual Exalogic Deployment.
Note:
The virtual IP addresses used here are examples. You should use the IP addresses you reserved in Part , "Reserving Virtual IP Addresses."To enable the virtual IP addresses listed in Table 9-2 and Table 9-3 on IAMHOST1 and IAMHOST2:
Use the ifconfig command to create the virtual IP address:
ifconfig subinterface virtual_ip_address netmask netmask_value
For example, on IAMHOST1, enter the following:
ifconfig bond0:1 192.168.20.3 netmask 255.255.240.0
Note:
the example in this section is applicable for both physical and virtual Exalogic deployments.For each virtual IP address you define, update the ARP caches using the following command:
arping -b -A -c 3 -I bond0 192.168.20.3
Check that each node can communicate with each other node using both physical and virtual host names for example:
ping -I bond0 WEBHOST1 (192.168.10.1) ping -I bond0 WEBHOST2 (192.168.10.2) ping -I bond0 IAMHOST1 (192.168.10.3) ping -I bond0 IAMHOST2 (192.168.10.4) ping -I bond0 OIMHOST1VHN (192.168.30.1) ping -I bond0 OIMHOST2VHN (192.168.30.2) ping -I bond0 SOAHOST1VHN (192.168.30.3) ping -I bond0 SOAHOST2VHN (192.168.30.4)
This step is only required if you have an Exadata Machine connected to the Exalogic machine and you want to connect to the database using SDP.
This addresses an issue where Automatic Path migration can cause the database to stop responding.
Add 'sdp_apm_enable=0' and 'ib_sdp' option in /etc/modprobe.conf file. For example, once it is added, it should output as follows:
cat /etc/modprobe.conf | grep ib_sdp alias net-pf-27 ib_sdp options ib_sdp sdp_zcopy_thresh=0 recv_poll=0 sdp_apm_enable=0
Save the file.
Reload the ib_sdp driver as follows:
modprobe -r ib_sdp modprobe ib_sdp
Validate that the change took effect by executing the command:
cat /sys/module/ib_sdp/parameters/sdp_apm_enable
The result should be 0
As shown in Chapter 7, "Preparing Storage for an Enterprise Deployment," you must make shared storage available to each host that will use it.
Mount the shared storage to the hosts according to one of the following tables, depending on whether you are using physical or virtual Exalogic.
Table 9-4 Mapping the Shares on the Appliance to Mount Points on Each Compute Node
| Volume Mounted | Mounted on Host | Mounted Point | Exclusive |
|---|---|---|---|
|
|
IAMHOST1 IAMHOST2 |
|
No |
|
|
ALL Hosts |
|
No |
|
|
IAMHOST1 IAMHOST2 |
|
No |
|
|
IAMHOST1 |
|
Yes |
|
|
IAMHOST2 |
|
Yes |
Table 9-5 Mapping the Shares on the Appliance to Mount Points on Each vServer
| Volume Mounted | Mounted on Host | Mounted Point | Exclusive |
|---|---|---|---|
|
|
OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2 |
|
No |
|
|
All Hosts |
|
No |
|
|
OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2 |
|
No |
|
|
OIMHOST1 |
/u02/private/oracle/config |
Yes |
|
|
OIMHOST2 |
/u02/private/oracle/config |
Yes |
|
|
OAMHOST1 |
|
Yes |
|
|
OAMHOST2 |
|
Yes |
|
|
WEBHOST1 |
|
Yes |
|
|
WEBHOST2 |
|
Yes |
|
|
WEBHOST1 |
|
Yes |
|
|
WEBHOST2 |
|
Yes |
Note the following points:
Each host must have appropriate privileges set within the NAS or SAN so that it can write to the shared storage.
Temporary mounts are only required during provisioning and patching.
If your directory tier is placed into a dedicated zone, you must share the ORACLE_BASE between the two directory hosts in a distributed topology.
If WEBHOST1 and WEBHOST2 are in the DMZ, ORACLE_BASE is not shared between those two hosts.
The mount point should be owned by the user and group created in Section 9.11, "Configuring Users and Groups."
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.
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.You must create and mount shared storage locations so that each application tier host can see the same location for the binary installation.
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.
To mount shared storage on a host, use a command similar to the following:
mount -t nfs nasfiler:volume mountpoint
For example:
mount -t nfs nasfiler:VOL1/OracleIAM /u01/oracle
Where nasfiler is the name of the shared storage device.
Using the mount command as described mounts the shared storage until the host is rebooted. Once rebooted, the storage must be remounted to the host.
To ensure that storage is made available following a host reboot, place an entry into the file /etc/fstab which looks like the following:
nasfiler:VOL1/OracleIAM /u01/oracle nfs auto,rw,bg,hard,nointr,proto=tcp,vers=3,timeo=300,rsize=32768,wsize=32768
Note:
The shared storage can be a NAS or SAN device. The following illustrates an example of creating storage for a NAS device from OAMHOST1. The options may differ depending on the specific storage device.mount -t nfs -o rw,bg,hard,nointr,proto=tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/OracleIAM /u01/oracle
Contact your storage vendor and machine administrator for the correct options for your environment.
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 /u01/oracle/products touch testfile
Verify that the owner and permissions are correct:
ls -l testfile
Then remove the file:
rm testfile
Create the following users and groups either locally or in your NIS or LDAP server. This user is the Oracle Software Owner.
The instructions below are for creating the users locally. Refer to your NIS documentation for information about creating these users/groups in your NIS server.
Groups
You must create the following groups on each node.
oinstall
dba
To create the groups, use the following command as root:
groupadd groupname
For example
groupadd -g 500 oinstall groupadd -g 501 dba
Users
You must create the following users on each node.
oracle–The owner of 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.
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.
The user and group should exists at the NIS server due to the NFSv4 mount requirement.
To create users use the following command as root:
useradd -g primary group -G optional groups -u userid username
For example:
useradd -g oinstall -G dba -u 500 oracle