This chapter describes how to set up your operating system on the host, mount file systems and create installation users.
Once the environment is commissioned, you will have a number of compute nodes (physical deployment) or vServers (virtual deployment). In this chapter the vServer or compute node is generically referred to as Host.
Parent topic: Preparing Exalogic for an Enterprise Deployment
This topic provides information on the minimum hardware requirements required for each host.
To use a host in an Oracle enterprise deployment, you must verify that it meets the minimum specification described in System Requirements document.
If you are deploying to a virtual host environment, ensure that each of the virtual hosts meets the minimum requirements.
Ensure that you have sufficient local disk and that shared storage is configured as described in Preparing Storage.
Allow sufficient swap and temporary space. Specifically,
Swap Space–The system must have at least 512 MB.
Temporary Space–There must be a minimum of 2 GB of free space in /tmp.
This topic provides information on verifying the Linux operating system requirements.
Before performing an enterprise deployment, ensure that you have installed a certified operating system and that you have applied all the necessary patches for the operating system as described in Oracle Fusion Middleware System Requirements and Specifications.
In addition, review the following sections for information about typical Linux operating system requirements for an enterprise deployment:
25000.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.
The kernel parameter and shell limit values shown below are recommended values only.
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 the Oracle Fusion Middleware System Requirements and Specifications.
Table 7-1 UNIX Kernel Parameters
| Parameter | Value |
|---|---|
|
kernel.sem |
256 32000 100 142 |
|
kernel.shmmax |
2147483648 or higher |
|
net.ipv4.ip_nonlocal_bind 1 |
Note:
If the host is used to host an OTD instance, and you are going to create a listener bound to a virtual IP Address (Recommended for faster failover), then you need to set the kernel parameter net.ipv4.ip_nonlocal_bind as described above. Add the Kernel parameters (/etc/sysctl.conf file) if they are missing from your configuration.To set these parameters:
On UNIX operating systems, the open file limit is an important system setting, which can affect the overall performance of the software running on the host.
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.
This section contains the following topics:
This topic provides information on viewing the number of currently open files.
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
This topic provides information on configuring the local hosts file.
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:
# Host Primary Network Interfaces 192.168.10.5 host1-int.example.com host1-int 10.10.10.5 host1-ext.example.com host1-ext 192.168.32.5 host1-stor.example.com host1-sto 192.168.10.5 host1-data.example.com host1-data #Host Name associated with the ZFS Storage Appliance 172.17.0.9 zfsinternal.example.com zfsinternal #Virtual Hosts 10.10.30.3 adminvhn.example.com adminvhn 192.168.30.5 host1vhn1.example.com host1vhn1 192.168.30.6 host2vhn1.example.com host2vhn1 #OTD Failover Groups 192.168.50.1 idstore.example.com idstore 192.168.50.2 edginternal.example.com edginternal
By default, huge pages are enabled in Exalogic compute nodes. It is recommended that the Huge Page allocation be set to 25000.
To verify the existing allocation, run the following command as root:
grep Huge /proc/meminfo
Specify the number of large pages. In the following example 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048k, then 3g = 3 x 1024m = 3072m = 3072 * 1024k = 3145728k, and 3145728k / 2048k = 1536).
To set the Huge Page allocation, run the following command as root in the compute node:
echo 1536 > /proc/sys/vm/nr_hugepages
Note:
To make use of huge pages in a Java vm you need to add the following to the arguments field of the web logic managed server:-XX:+UseLargePages.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. For example,
LANG=en_GB.UTF-8
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 Fusion Middleware Suite components might 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 host to access your corporate DNS hosts.
/etc/resolv.conf file.It is important that all hosts in the deployment have the same time. The best way to achieve this is to use a NTP (Network Time Protocol) server.
If you are using NFS version 4 (v4), configure a directory service or a NIS (Network Information Host).
If your organization does not have one already, use the built-in one on the ZFS storage appliance. For more information, see Creating Users and Groups in NIS.
Once you have configured your NIS host, configure each compute node or vserver to use it. If you are using the built-in NIS host on the Exalogic ZFS appliance, perform the following steps:
Now that you have added new interfaces to each host, having only one default gateway might not be sufficient. You might want to have one interface for an Internet connection and another for a corporate WAN, for example.
In the example below, the different interfaces are shown, along with example IP addresses and gateway requirements:
| Interface | IP Address | Gateway Requirements |
|---|---|---|
|
eth0 |
201.19.23.128 / 24 |
Gateway IP 201.19.23.1 |
|
bond0 |
192.168.10.1 / 24 |
No Gateway requirements |
|
bond1 |
10.10.10.101/ 24 |
Gateway IP 10.10.10.1 |
As you can see, eth0 and bond1 must have their own respective default gateways.
Bond0, however, does not have any default gateway requirements. It is simply confined to their actual Layer 3 subnet.
To get around this, create rules and tables for routing lookups, as follows.
The enterprise deployment requires that certain hosts, such as the WebLogic Administration hosts or SOA Managed hosts, use virtual IP addresses.
You must enable the appropriate IP address on each host. Preparing the Network describes the mapping of IP addresses to the hosts.
The following tables list the assignment of virtual IP addresses to network interfaces for the typical enterprise deployment topology. Managed hosts not using a virtual IP address use the default network interface for communications.
When you configure networking, you will by default create a default network interface that will be assigned to the network card. For example, bond1 for the client EoIB network and bond0 for the internal IPoIB network.
If you want to then assign another IP address to the same network card, then an index number is applied. For example, assigning VIP1 and VIP2 to bond0 would result in bond0:1 and bond0:2.
Note:
Refer to the appropriate product-specific Enterprise Deployment Guide for the list of VIP addresses you need to create for your deployment.
This section contains the following topics:
This topic provides a summary of Exalogic virtual IP address.
Table 7-2 shows the Virtual IP address mapping for a typical enterprise deployment on Exalogic.
For instructions on defining these virtual IP addresses, see Enabling a Virtual IP Address on a Network Interface.
Table 7-2 Virtual IP Addresses Associated with IPoIB and EoIB Network interfaces
| Interface | Address Example | Netmask Example | Used By | Virtual Host Name | Default Physical Host | Default Virtual Host |
|---|---|---|---|---|---|---|
|
BOND1:1 |
10.10.30.1 |
255.255.224.0 |
OTD Administration Host |
OTDADMINVHN |
HOST1 |
WEBHOST1 |
|
BOND1:1 |
10.10.30.2 |
255.255.224.0 |
Administration Host |
ADMINVHN |
HOST1 |
HOST1 |
|
BOND0:1 |
192.168.30.1 |
255.255.240.0 |
WLS_PRODA1 |
HOST1VHN1 |
HOST1 |
HOST1 |
|
BOND0:1 |
192.168.30.2 |
255.255.240.0 |
WLS_PRODA2 |
HOST2VHN1 |
HOST2 |
HOST2 |
|
BOND0:2 |
192.168.30.3 |
255.255.240.0 |
WLS_PRODB1 |
HOST1VHN2 |
HOST1 |
HOST1 |
|
BOND0:2 |
192.168.30.4 |
255.255.240.0 |
WLS_PRODB2 |
HOST2VHN2 |
HOST2 |
HOST2 |
|
192.168.50.1 |
255.255.224.0 |
OTD Failover group for callbacks |
EDGINTERNAL |
HOST1 |
WEBHOST1 |
|
|
192.168.50.2 |
255.255.224.0 |
OTD Failover group for LDAP |
IDSTORE |
HOST2 |
WEBHOST2 |
Default Physical Host is the compute node that the Virtual Host is assigned to by default. It will only move in the event of host failure.
Default Virtual Host is the virtual host that the Virtual Host is assigned to by default. It will only move in the event of host failure.
In the example above, the Administration host is listening on the External IPoIB network. It could also be on the internal network.
Note:
The virtual IP addresses used here are examples. You should use the IP addresses you reserved in Reserving Virtual IP Addresses.
This topic provides the procedure to enable a virtual IP address on a network interface.
ifconfig command described above has been deprecated and is replaced with the ip command.If you are using NFS 4 then make sure that the users and groups that you enter are in your NIS servers.
Do not create them locally. If you are using NFSv3 then you can create your users locally. Create the following users and groups either locally or in your NIS or LDAP host. This user is the Oracle software owner.
The instructions below are for creating users and groups locally. Refer to your NIS documentation for information about creating these users/groups in your NIS host.
This section contains the following topics:
This topic provides information on creating users and groups.
Refer to creating groups and creating users in the following sections.
This topic provides the procedure to create groups on each node.
You must create the following groups on each node.
oinstall
dba
To create the groups, run the following command as root:
groupadd groupname
For example:
groupadd -g 500 oinstall groupadd -g 501 dba
This topic provides procedure for creating users.
You must create the following user on each node.
oracle – The owner of the Oracle software. You can use a different name. The primary group for this account must be oinstall.
The account must also be in the dba group.
Note:
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.
To create users, run 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
To create an account for an NIS user on the NIS master server.
NIS provides maps for password, group, and auto-home.
The NIS master server uses NFS to export the users home directories.
WARNING:
NIS authentication is deprecated as it has security issues, including a lack of protection of authentication data.This topic provides information on mounting shared storage on the host.
As described in Preparing Storage, you must make shared storage available to each host that will use it.
This section contains the following topics:
This topic provides information on the shared storage.
Mount the shared storage to the hosts according to the following table.
Table 7-3 Mapping the Shares on the Appliance to Mount Points on Each Compute Node
| Volume Mounted | Mounted on Physical Host | Mounted on Virtual Host | Mounted Point | Exclusive |
|---|---|---|---|---|
|
|
HOST1 HOST2 |
vServers on HOST1 vServers on HOST2 |
|
No |
|
|
HOST1 |
WEBHOST1 |
|
Yes |
|
|
HOST2 |
WEBHOST2 |
|
Yes |
|
|
HOST1 HOST2 |
vServers on HOST1 vServers on HOST2 |
|
No |
|
|
HOST1 HOST2 |
vServers on HOST1 vServers on HOST2 |
|
No |
|
|
HOST1 |
vServers on HOST1 |
|
Yes |
|
|
HOST2 |
vServers on HOST2 |
|
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 WEBHOST1 and WEBHOST2 are in the DMZ, SW_ROOT is not shared between those two hosts.
The mount point should be owned by the user and group created in 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.
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 the ZFS storage device to a Linux host.
To mount shared storage on a host, use a command similar to the following:
mount -t nfs zfs:volume mountpoint
For example:
mount -t nfs zfsinternal:/export/product_binaries/shared_binaries /u01/oracle/products
Using the mount command 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 that looks like the following:
zfsinternal:/export/product_binaries/shared_binaries /u01/oracle/products nfs4 nointr,timeo=300