1. Enterprise Deployment Guide for Oracle Analytics Server
  2. Preparing for an Enterprise Deployment
  3. Preparing the Host Computers for an Enterprise Deployment

8 Preparing the Host Computers for an Enterprise Deployment

It is important to perform a set of tasks on each computer or server before you configure the enterprise deployment topology. This involves verifying the minimum hardware and operating system requirements for each host, configuring operating system users and groups, enabling Unicode support, mounting the required shared storage systems to the host and enabling the required virtual IP addresses on each host.

This chapter describes the tasks that you must perform from each computer or server that is hosting the enterprise deployment.

Parent topic: Preparing for an Enterprise Deployment

Verifying the Minimum Hardware Requirements for Each Host

After you procure the required hardware for the enterprise deployment, it is important to ensure that each host computer meets the minimum system requirements.

After you have procured the required hardware for the enterprise deployment, log in to each host computer and verify the system requirements listed in Hardware and Software Requirements for the Enterprise Deployment Topology.

If you deploy 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 storage and shared storage configured as described in Preparing the File System for an Enterprise Deployment.

Allow sufficient swap and temporary space; specifically:

  • Swap Space–The system must have at least 500 MB.

  • Temporary Space–There must be a minimum of 500 MB of free space in the /tmp directory.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Verifying Linux Operating System Requirements

You can review the typical Linux operating system settings for an enterprise deployment in this section.

To ensure the host computers meet the minimum operating system requirements, ensure that you have installed a certified operating system and that you have applied all the necessary patches for the operating system.

In addition, review the following sections for typical Linux operating system settings for an enterprise deployment.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Setting Linux Kernel Parameters

The kernel-parameter and shell-limit values shown in Table 8-1are recommended values only. 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 in Table 8-1 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 deploy a database onto the host, you might need to modify additional kernel parameters. Refer to 12c (12.2.1.3.0) Configuring Kernel Parameters in Oracle Grid Infrastructure Installation Guide for Linux.

Table 8-1 UNIX Kernel Parameters

Parameter Value

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

To set these parameters:

  1. Sign in as root and add or amend the entries in the /etc/sysctl.conf file.
  2. Save the file.
  3. Activate the changes by entering the following command:
    /sbin/sysctl -p

Parent topic: Verifying Linux Operating System Requirements

Setting the Open File Limit and Number of Processes Settings on UNIX Systems

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 computer.

For guidance on setting the Open File Limit for an Oracle Fusion Middleware enterprise deployment, see Host Computer Hardware Requirements.

Note:

The following examples are for Linux operating systems. Consult your operating system documentation to determine the commands to be used on your system.

For more information, see the following sections.

Parent topic: Verifying Linux Operating System Requirements

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 following commands.

C shell: 

limit descriptors

Bash: 

ulimit -n
Setting the Operating System Open File and Processes Limits

To change the Open File Limit values:

  1. Sign in as root user and edit the following file:

    /etc/security/limits.conf

  2. Add the following lines to thelimits.conf file. (The values shown here are for example only):
    * soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

    The nofiles values represent the open file limit; the nproc values represent the number of processes limit.

  3. Save the changes, and close thelimits.conf file.
  4. Re-login into the host computer.

Verifying IP Addresses and Host Names in DNS or Hosts File

Before you begin the installation of the Oracle software, ensure that the IP address, fully qualified host name, and the short name of the host are all registered with your DNS server. Alternatively, you can use the local hosts file and add an entry similar to the following: 

IP_Address Fully_Qualified_Name Short_Name

For example:

10.229.188.205  host1.example.com  host1

Oracle also recommends that you use aliases to map to different IPs in different data centers in preparation for disaster recovery. You can also use these aliases to configure the listen address for some of the components.

In this guide, the abstract hostnames that are provided on the Hardware - Host Computers tab of the workbook ( and ADMINVHN) are used for these aliases, so the /etc/hosts can be similar to this example:

Parent topic: Verifying Linux Operating System Requirements

Configuring Operating System Users and Groups

The users and groups to be defined on each of the computers that host the enterprise deployment are listed in this section.

Groups

You must create the following groups on each node.

  • oinstall

  • dba

Users

You must create the following user on each node.

  • nobody–An unprivileged user.

  • 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.

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.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Enabling Unicode Support

It is recommended to enable Unicode support in your operating system so as to allow processing of characters in Unicode.

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 Analytics Server technologies, for example, are based on Unicode.

If the operating system is configured to use a non-UTF-8 encoding, Oracle Analytics Server 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.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Setting the DNS Settings

Configure the host to access your corporate DNS hosts. To do this, update DNS settings by updating the file /etc/resolv.conf.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Configuring Users and Groups

Create the following groups and user either locally or in your NIS or LDAP server. This user is the Oracle Software Owner.

The instructions below are for creating the user locally. Refer to your NIS documentation for information about creating these groups and user 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

User

You must create the following user 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.

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.

  • The user and group should exists at the NIS server due to the NFSv4 mount requirement.

To create a local user, 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

Note:

To create this user in NIS, refer to your NIS documentation.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Configuring a Host to Use an NTP (time) Server

All servers in the deployment must have the same time. The best way to achieve this is to use an NTP server. To configure a host to use an NTP server:

  1. Determine the name of the NTP server(s) you wish to use. For security reasons, ensure that these are inside your organization.
  2. Log in to the host as the root user.
  3. Edit the file /etc/ntp.conf to include a list of the time servers. After editing, the file should include the multiple server entries:
    server ntphost1.example.com
server ntphost2.example.com

    Note:

    If desired, add additional peer entries to /etc/ntp.conf for each of the app-tier hosts, DB hosts, and storage appliance. This enables additional redundancy and accuracy in the event of loss or inaccuracy of the NTP servers. Add one entry per host as follows: 
    # # enable app-to-app host time sync redundancy 
peer BIHOST1 
peer BIHOST2
peer BIHOST1
peer BIHOST2
# enable app-to-db host time sync redundancy, if permitted 
peer DBHOST1 
peer DBHOST2 
# enable app-to-Storage time sync redundancy, if permitted 
peer NFSAPLIANCE
  4. Run the following command to synchronize the system clock to the NTP server:
    /usr/sbin/ntpdate ntpserver1.example.com
  5. Start the NTP client using the following command:
    service ntpd start
  6. Validate that NTP time synchronization is active, the NTP servers and app-tier hosts are reachable, and the time offset (milliseconds) is not significantly high for any listed host. Run the ntpq command as follows:
    /usr/sbin/ntpq -p       

remote                refid       st t 	when poll  reach  delay  offset  jitter 
===============================================================================
+ntphost1.example.com 10.1.1.13   3  u 	1    16    377    0.549  0.032   0.041 
*ntphost2.example.com 10.1.2.10   2  u 	11   16    377    0.349  0.079   0.039 
-wcchost1.example.com 10.1.2.200  3  u 	54   64    376    0.124  -0.068  3.681 
-wcchost2.example.com 10.1.2.201  3  u 	66   64    376    0.059  -0.123  2.038 
-wcphost1.example.com 10.1.2.205  3  u 	18   64    377    0.050  -0.091  2.930 
#wcphost2.example.com 10.1.2.206  3  u 	25   64    376    0.041  -0.105  4.919

    Note:

    It may take several minutes for all servers to register and coordinate NTP sync once fully configured. Run the ntpq command periodically until assured that all servers and peers are synchronizing their time.
  7. To make sure that the server always uses the NTP server to synchronize the time. Set the client to start on reboot by using the following command:
    chkconfig ntpd on

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Configuring a Host to Use an NIS/YP Host

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 host, configure each compute node to use it. Before beginning, determine the host names of the NIS servers you are going to use.

  1. Login to the host as root.
  2. Edit the /etc/idmapd.conf configuration file: 
    vi /etc/idmapd.conf

    Set the domain value, as in the following example:

    Domain = example.com
  3. Restart the rpcidmapd service: 
    service rpcidmapd restart
  4. 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 example.com server NIS_Server_hostname_or_IP

    Where example.com is the example domain and NIS_Server_hostname_or_IP is the host name or IP address of the NIS host. You must replace these sample values with values appropriate for your environment.

  5. Set NIS domain name on the command line: 
    domainname NIS_DOMAIN_NAME

    For example:

    domainname nisdomain.example.com

  6. Edit the /etc/nsswitch.conf configuration file: 
    vi /etc/nsswitch.conf

    Add nis to each of the following entries:

    Note:

    The first value may be compat or files depending on your OS and enterprise requirements. 
     passwd:     files nis
 shadow:     files nis
 group:      files nis
 automount:  files nis nisplus
 aliases:    files nis nisplus
  7. Restart the rpcidmapd service:
    service rpcidmapd restart
  8. Restart the ypbind service by running the following command: 
    service ypbind restart

  9. Check the yp service by running this command: 
    ypwhich
  10. Verify if you can access Oracle user accounts:
    ypcat passwd
  11. Add ypbind to your boot sequence, so that it starts automatically after rebooting.
    chkconfig ypbind on

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Mounting the Required Shared File Systems on Each Host

It is important to understand how to mount the shared storage to all the servers that require access.

The shared storage configured, as described in Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment, must be available on the hosts that use it.

In an enterprise deployment, it is assumed that you have a hardware storage filer, which is available and connected to each of the host computers that you have procured for the deployment.

You must mount the shared storage to all servers that require access.

Each host must have appropriate privileges set within the Network Attached Storage (NAS) or Storage Area Network (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 Linux by using NFS storage.

You must create and mount shared storage locations so that BIHOST1 and BIHOST2 can see the same location if it is a binary installation in two separate volumes.

See Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

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 account 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 process the files, but they do not have write privileges.

See Selecting an Installation User in the Oracle Fusion Middleware Installation Planning Guide.

In the following example, nasfiler represents the shared storage filer. Also note that these are examples only. Typically, the mounting of these shared storage locations should be done by using the /etc/fstabs file on UNIX systems, so that the mounting of these devices survives a reboot. Refer to your operating system documentation for more information.

To mount the shared storage on Linux:

  1. Create the mount directories on BIHOST1, as described in Summary of the Shared Storage Volumes in an Enterprise Deployment , and then mount the shared storage. For example: 

    mount-tnfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/

  2. Repeat the procedure on BIHOST2 using VOL2.

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 that 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 example illustrates creating storage for a NAS device from BIHOST1. 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/Oracle/u01/oracle

Contact your storage vendor and machine administrator to learn about the appropriate options for your environment.

Parent topic: Preparing the Host Computers for an Enterprise Deployment

Enabling the Required Virtual IP Addresses on Each Host

You must enable the required virtual IP addresses on each host in order to prepare the host for the enterprise deployment.

To prepare each host for the enterprise deployment, you must enable the virtual IP (VIP) addresses that are described in Reserving the Required IP Addresses for an Enterprise Deployment.

It is assumed that you have already reserved the VIP addresses and host names and that they have been enabled by your network administrator. You can then enable the VIPs on the appropriate host.

Note that the virtual IP addresses used for the enterprise topology are not persisted because they are managed by Whole Server Migration (for selected Managed Servers and clusters) or by manual failover (for the Administration Server).

To enable the VIP addresses on each host, run the following commands as root:
  1. Determine the CIDR notation of the netmask. Each Netmask has a CIDR notation. For example, 255.255.240.0 has a CIDR of 20.
    If the netmask you are adding is the same as the interface, the fastest way to determine this is to examine the existing IP address that are assigned to the network card. You can do this by using the following command: 
    ip addr show dev eth0
    Sample output:
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:21:f6:03:85:9f brd ff:ff:ff:ff:ff:ff
int 192.168.20.1/20 brd 10.248.11.255 scope global eth0
    In this example, the CIDR value is the value after the forward slash (/), which is, 20. If you are unsure of the CIDR value, contact your network administrator.
  2. Configure the additional IP address on the appropriate network interface card with an appropriately suffixed label using the following command:
    ip addr add VIP/CIDR dev nic# label nic#:n

    Note:

    For each VIP/VHN that you need to add, increment the :n suffix starting with :1
    Example: For VIP IP of 192.168.20.3, netmask: 255.255.240.0 (CIDR: 20), and the eth0 NIC:
    ip addr add 192.168.20.3/20 dev eth0 label eth0:1
  3. For each of the virtual IP addresses that you define, update the ARP caches by using the following command:
    arping -b -A -c 3 -I eth0 192.168.20.3

Parent topic: Preparing the Host Computers for an Enterprise Deployment