5 Procuring Resources for an Enterprise Deployment

Use this chapter to procure the required hardware, software, and network settings before you begin configuring the Oracle Identity and Access Management reference topology.

This chapter contains the following sections:

• Hardware and Software Requirements for an Enterprise Deployment

• Exalogic Requirements for an Enterprise Deployment

• Reserving the Required IP Addresses for an Enterprise Deployment

• Identifying and Obtaining Software Downloads for an Enterprise Deployment

5.1 Hardware and Software Requirements for an Enterprise Deployment

This section includes the following sections:

• Section 5.1.1, "Hardware Load Balancer Requirements"

• Section 5.1.2, "Host Computer Hardware Requirements"

• Section 5.1.3, "Operating System Requirements for the Enterprise Deployment Topology"

5.1.1 Hardware Load Balancer Requirements

This enterprise topology uses an external load balancer. This external load balancer should have the following features:

• Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

• Port translation configuration should be possible so that incoming requests on the virtual host name and port are directed to a different port on the backend servers.

• Monitoring of ports on the servers in the pool to determine availability of a service.

• Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

  • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle HTTP Server in the web tier, the load balancer needs to be configured with a virtual server and ports for HTTP and HTTPS traffic.

  • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

• Ability to detect node failures and immediately stop routing traffic to the failed node.

• Fault-tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

• It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the backend services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

• Sticky routing capability: Ability to maintain sticky connections to components. Examples of this include cookie-based persistence, IP-based persistence, and so on.

• The load balancer should be able to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP).

• SSL acceleration (this feature is recommended, but not required for the enterprise topology).

5.1.2 Host Computer Hardware Requirements

The following sections provide information to help you procure host computers that are configured to support the Oracle Identity and Access Management enterprise deployment topologies:

• Section 5.1.2.1, "General Considerations for Enterprise Deployment Host Computers"

• Section 5.1.2.2, "Reviewing the Oracle Fusion Middleware System Requirements"

• Section 5.1.2.3, "Typical Memory, File Descriptors, and Processes Required for an Oracle Identity and Access Management Enterprise Deployment"

• Section 5.1.2.4, "Typical Disk Space Requirements for an Oracle Identity and Access Management"

5.1.2.1 General Considerations for Enterprise Deployment Host Computers

Before you start the process of configuring an Oracle Fusion Middleware enterprise deployment, you must perform the appropriate capacity planning to determine the number of nodes, CPU, and memory requirements for each node depending on the specific system's load as well as the throughput and response requirements. These requirements will vary for each application or custom IAM system being used.

The information in this chapter provides general guidelines and information that will help you determine the host computer requirements. It does not replace the need to perform capacity planning for your specific production environment.

Workbook Note:

As you obtain and reserve the host computers in this section, note the host names and system characteristics in the Enterprise Deployment Workbook. You will use these addresses later when you enable the IP addresses on each host computer.

For more information, see Chapter 4, "Using the Enterprise Deployment Workbook."

5.1.2.2 Reviewing the Oracle Fusion Middleware System Requirements

Review the Oracle Fusion Middleware System Requirements and Specifications to ensure that your environment meets the minimum installation requirements for the products you are installing.

The Requirements and Specifications document contains information about general Oracle Fusion Middleware hardware and software requirements, minimum disk space and memory requirements, database schema requirements, and required operating system libraries and packages.

It also provides some general guidelines for estimating the memory requirements for your Oracle Fusion Middleware deployment.

5.1.2.3 Typical Memory, File Descriptors, and Processes Required for an Oracle Identity and Access Management Enterprise Deployment

Table 5-1 summarizes the memory, file descriptors, and processes required for the Administration Server and each of the Managed Servers computers in a typical Oracle Identity and Access Management enterprise deployment. These values are provided as an example only, but they can be used to estimate the minimum amount of memory required for an initial enterprise deployment.

The example in Table 5-1 reflects the minimum requirements for configuring the Managed Servers and other services required on IAMHOST1, as depicted in the reference topologies in Section 2.1, "Understanding the Primary and Build-Your-Own Enterprise Deployment Topologies".

When you are procuring machines, use the information in the Approximate Top Memory column as a guide when determining how much physical memory each host computer should have available.

After you procure the host computer hardware and verify the operating system requirements, review the software configuration to be sure the operating system settings are configured to accommodate the number of open files listed in the File Descriptors column and the number processes listed in the Operating System Processes and Tasks column.

Table 5-1 Typical Memory, File Descriptors, and Processes Required for Each Enterprise Deployment Host

Managed Server, Utility, or Service	Approximate Top Memory	Number of File Descriptors	Operating System Processes and Tasks
Access Administration Server	3.0 GB	1300	180
Governance Administration Server	3.0 GB	2100	100
WLS_SOA	2.0 GB	1400	210
WLS_OIM	2.0 GB	1400	190
WLS_BI	2.0 GB	900	100
WLS_OAM	1.0 GB	900	170
WLS_AMA	2.0 GB	1200	160
WLS_MSM	2.0 GB	900	120
Node Manager	268 MB	300	20

5.1.2.4 Typical Disk Space Requirements for an Oracle Identity and Access Management

For the latest disk space requirements for the Oracle Fusion Middleware 11g (11.1.2.3) products, including the Oracle Identity and Access Management products, review the Oracle Fusion Middleware System Requirements and Specifications.

Use the this information and the information in Section 7, "Preparing Storage for an Enterprise Deployment" to determine the disk space requirements required for your deployment.

Table 5-2 Typical Disk Space Requirements for a Oracle Identity and Access Management Enterprise Deployment

Server	Local Storage Required (per host)	Shared Storage Required
Oracle Web Tier	5 GB
Oracle Directory	5 GB	10 GB
Oracle Access Manager	3 GB	10 GB
Oracle Governance	3 GB	10 GB
Life Cycle Management tools including software repository		30 GB

5.1.3 Operating System Requirements for the Enterprise Deployment Topology

The Oracle Fusion Middleware software products and components described in this guide are certified on various operating systems and platforms, which are listed in the Oracle Fusion Middleware Supported System Configurations.

About the Examples in this Guide:

This guide focuses on the implementation of the enterprise deployment reference topology on Oracle Linux systems.

The topology can be implemented on any certified, supported operating system, but the examples in this guide typically show the commands and configuration steps as they should be performed using the bash shell on Oracle Linux.

5.2 Exalogic Requirements for an Enterprise Deployment

This section describes Exalogic requirements for an enterprise deployment.

This section contains the following topics:

• Section 5.2.1, "Exalogic Virtual Server Requirements"

• Section 5.2.2, "About Private Networks"

• Section 5.2.3, "About Exalogic Elastic Cloud Networks"

• Section 5.2.4, "About Virtual Server Templates"

5.2.1 Exalogic Virtual Server Requirements

If you are deploying onto an Exalogic Virtual deployment then you will need to create the following virtual servers in order to be able to host a typical Oracle Identity and Access Management Enterprise Deployment.

• Section 5.2.1.1, "Virtual Servers Required for IAM on Exalogic"

• Section 5.2.1.2, "About Distribution Groups"

Note:

As you obtain and reserve the host computers in this section, note the host names and system characteristics in the Enterprise Deployment Workbook. Use these addresses later when you enable the IP addresses on each host computer. For more information, see Chapter 4, "Using the Enterprise Deployment Workbook."

5.2.1.1 Virtual Servers Required for IAM on Exalogic

When you deploy the Oracle Identity and Access Management software as part of a virtual configuration on an Exalogic system, then you must be sure to configure the vServers shown in Table 5-3.

Table 5-3 vServer Information

Name	vServerType	Virtual Networks	Host Name	Distribution Group
otdhost1	LARGE	IPoIB-EDGFoot 1  EoIB-clientFoot 2  IPoIB-StorageFoot 3	otdhost1 otdhost1-ext otdhost1-stor	IAM_OTD
otdhost2	LARGE	IPoIB-EDG EoIB-client IPoIB-Storage	otdhost2 otdhost2-ext otdhost2-stor	IAM_OTD
oamhost1	EXTRA_LARGE	IPoIB-EDG EoIB-client IPoIB-Storage	oamhost1 oamhost1-ext oamhost1-stor	IAM_IAD
oamhost2	EXTRA_LARGE	IPoIB-EDG EoIB-client IPoIB-Storage	oamhost2 oamhost2-ext oamhost2-stor	IAM_IAD
oimhost1	EXTRA_LARGE	IPoIB-EDG EoIB-client IPoIB-Storage	oimhost1 oimhost1-ext oimhost1-stor	IAM_IAG
oimhost2	EXTRA_LARGE	IPoIB-EDG EoIB-client IPoIB-Storage	oimhost2 oimhost2-ext oimhost2-stor	IAM_IAG
ldaphost1	EXTRA_LARGE	IPoIB-EDG IPoIB-Storage	ldaphost1 ldaphost1-stor	IAM_LDAP
ldaphost2	EXTRA_LARGE	IPoIB-EDG IPoIB-Storage	ldaphost2 ldaphost2-stor	IAM_LDAP

^Footnote 1 IPoIB-EDG is the internal IPoIB network used for inter vServer communication

^Footnote 2 EoIB-client is the Client Access Network which connects to the corporate ethernet

^Footnote 3  IPoIB-Storage is the internal network that vServers use to communicate with the ZFS storage appliance.

5.2.1.2 About Distribution Groups

Distribution groups are used to ensure that the same application running in multiple virtual servers do not all run on the same physical host. By preventing different vServers of the same type running on the same physical server, you prevent the failure of the underlying physical server from taking out the complete system.

For an Oracle Fusion Middleware Enterprise Deployment you need to the following Distribution Groups:

• EDG_OTD: Prevents two Oracle Traffic Director Servers from running on the same physical server

• EDG_OAM: Prevents two IAMAccessDomain Servers from running on the same physical server

• EDG_OIM: Prevents two IAMGovernanceDomain Servers from running on the same physical server

• EDG_LDAP: Prevents two LDAP servers running on the same physical server.

5.2.2 About Private Networks

If you are going to keep interapp communication on the internal network. Then you must create a private VLAN. In virtual Exalogic this is done via EMOC, in physical Exalogic this is done manually. When creating a private network in EMOC for IAM, you must allow space for at least 20 IP addresses. Instructions for doing this are in the Exalogic Hardware Enterprise Deployment Guide.

5.2.3 About Exalogic Elastic Cloud Networks

When you commission Exalogic Elastic cloud a number of networks will be available for attachment to your virtual servers. The names may differ depending on how they were created at commissioning but the networks you will need are:

• EoIB-Client - This is the network used to connect to the main corporate network. Often known as the external network.

• IPoIB-EDG - This is the private network used for inter app communication. The outside world cannot connect to it.

• IPoIB-Storage - This is the private network that virtual servers use to connect to the ZFS storage appliance.

5.2.4 About Virtual Server Templates

When you commission the Oracle Exalogic Elastic Cloud, a number of virtual server templates will be used.

The following are the typical virtual server templates that are created in Oracle Exalogic Elastic Cloud. You can customize these values depending on the results of your capacity planning.

Table 5-4 Virtual Server Templates

Type	Description	Memory (GB)	Number of Virtual CPUs
VERY_LARGE	Large Memory Intensive Applications	20	6
EXTRA_LARGE	CPU Intensive Applications	16	6
LARGE	Average Intensity Applications	8	2
SMALL	Low intensity applications	4	1

5.3 Reserving the Required IP Addresses for an Enterprise Deployment

Before you begin installing and configuring the enterprise topology, you must obtain and reserve a set of IP addresses:

• Physical IP (IP) addresses for each of the host computers you have procured for the topology

• Virtual IP (VIP) addresses for each Managed Server in the Oracle WebLogic Server domain

• A unique virtual host name to be mapped to each VIP.

You can then work with your network administrator to be sure these required VIPs are defined in your DNS server. (Alternatively, for non-production environments, you can use the /etc/hosts file to define these virtual hosts).

For more information, see the following sections:

• Section 5.3.1, "What Is a Virtual IP (VIP) Address?"

• Section 5.3.2, "Why Use Virtual Host Names and Virtual IP Addresses?"

• Section 5.3.3, "Physical and Virtual IP Addresses Required by the Enterprise Topology"

5.3.1 What Is a Virtual IP (VIP) Address?

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually. Individual Managed Servers and Administration Servers within the Oracle WebLogic Server domain are configured to listen on this IP Address.

5.3.2 Why Use Virtual Host Names and Virtual IP Addresses?

For an enterprise deployment, in particular, it is important that a set of VIPs--and the virtual host names to which they are mapped--are reserved and enabled on the corporate network.

Alternatively hostnames can be resolved through appropriate /etc/hosts file propagated through the different nodes.

In the event of the failure of the host computer where the IP address is assigned, the IP address can be assigned to another host in the same subnet, so that the new host can take responsibility for running the managed servers assigned to it.

The reassignment of virtual IP addresses for Managed Servers can be performed automatically using the Server Migration feature of Oracle WebLogic Server. The reassignment of virtual IP address for the Administration Server must be performed manually.

Instructions for configuring Server Migration and for manually reassigning the Administration Server VIP are provided in Chapter 21, "Configuring Server Migration for an Enterprise Deployment."

5.3.3 Physical and Virtual IP Addresses Required by the Enterprise Topology

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is reassigned to another node in the same subnet, so that the new node can take responsibility for running the WebLogic Servers assigned to it. In other words, these virtual IP addresses are associated with a virtual host name. That way, should it be required, the underlying IP address can be changed.

The examples below show the virtual host names required by this document. These are associated with a virtual IP address as described above.

The following is a list of the virtual servers required by Oracle Identity and Access Management:

• IADADMINVHN.example.com

  In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from OAMHOST1 to OAMHOST2, or vice versa.

• IGDADMINVHN.example.com

  In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. This virtual IP address fails over along with the Administration Server from OIMHOST1 to OIMHOST2, or vice versa.

• OIMHOSTxVHNn.example.com

  Where x is the host name and n is a unique number for the virtual host.

  One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.

  Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 5-1.

You can assign any unique host name to the VIPs, but in this guide, we reference each VIP using the suggested host names in the table.

Workbook Note:

As you obtain and reserve the IP addresses and their corresponding virtual host names in this section, note the values of the IP addresses and host names in the Enterprise Deployment Workbook. You will use these addresses later when you enable the IP addresses on each host computer.

For more information, see Chapter 4, "Using the Enterprise Deployment Workbook"

Figure 5-1 IP and VIrtual IP Addresses of the Servers in IAMAccessDomain

Description of ''Figure 5-1 IP and VIrtual IP Addresses of the Servers in IAMAccessDomain''

Figure 5-2 IP and Virtual IP Addresses of the Servers in IAMGovernanceDomain

Description of ''Figure 5-2 IP and Virtual IP Addresses of the Servers in IAMGovernanceDomain''

Table 5-5 Summary of the Virtual IP Addresses Required for the Oracle Identity and Access Management Enterprise Deployment Topology

Virtual IP	VIP Maps to...	Description
VIP1	IADADMINVHN	IADADMINVHN is the virtual host name used as the listen address for the Access Domain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.
VIP2	IGDADMINVHN	IGDADMINVHN is the virtual host name used as the listen address for the Governance Domain Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.
VIP3	OIMHOST1VHN1	OIMHOST1VHN1 is the virtual host name that maps to the listen address for WLS_OIM1 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_OIM1 process is running.
VIP4	OIMHOST1VHN2	OIMHOST1VHN2 is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_SOA1 process is running
VIP5	OIMHOST1VHN3	OIMHOST1VHN3 is the virtual host name that maps to the listen address for WLS_BI1 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_BI1 process is running
VIP6	OIMHOST2VHN1	OIMHOST2VHN1 is the virtual host name that maps to the listen address for WLS_OIM2 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_OIM2 process is running
VIP7	OIMHOST2VHN2	OIMHOST2VHN2 is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_SOA2 process is running
VIP8	OIMHOST2VHN3	OIMHOST3VHN3 is the virtual host name that maps to the listen address for WLS_BI2 and fails over with Whole Server Migration of this managed server. It is enabled on the node where WLS_BI2 process is running

5.4 Identifying and Obtaining Software Downloads for an Enterprise Deployment

The procedure for obtaining the Oracle Identity and Access Management software varies, depending on whether you are using the manual installation and configuration procedures or the Oracle Identity and Access Management Life Cycle Management (LCM) Tools for an automated installation and configuration:

• Section 5.4.1, "Obtaining the LCM Tools and Oracle Identity and Access Management Software Repository for an Automated Deployment"

• Section 5.4.2, "Obtaining Required Patches for an Automated Deployment with the LCM Tools"

• Section 5.4.3, "Applying Patches Automatically as Part of the LCM Tools Automated Deployment Process"

• Section 5.4.4, "Obtaining the Oracle Identity and Access Management Software for a Manual Deployment"

• Section 5.4.5, "Obtaining Patches for a Manual Deployment"

5.4.1 Obtaining the LCM Tools and Oracle Identity and Access Management Software Repository for an Automated Deployment

Before you can use the LCM Tools to automate the deployment of Oracle Identity and Access Management, you must locate and download the Oracle Identity and Access Management Deployment Repository 11.1.2.3.0.

The repository is packaged as a set of downloadable archives. When unpacked, these archives provide you with the LCM Tools and all the software installers required to install and configure Oracle Identity and Access Management software.

For information about locating and downloading the repository, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files.

For more information about the directory structure of the Oracle Identity and Access Management Deployment Repository, see Section 7.5.2, "About the Lifecycle Repository" and Section 7.5.5.1, "Life Cycle Management and Deployment Repository".

Note:

If you plan to deploy Oracle Identity and Access Management on Exalogic, then you must also download Oracle Traffic Director 11.1.1.9.0 and WebGate for Oracle Traffic Director 11.1.1.9.0 separately.

5.4.2 Obtaining Required Patches for an Automated Deployment with the LCM Tools

If you are using the LCM Tools to perform an automated deployment, then after you download the LCM Tools, you must download the latest LCM Tools bundle patch before attempting an automated deployment.

At the time this document was published, the latest available bundle patch was IDMLCM BUNDLE PATCH 11.1.2.3.160419, which is available at the following URL:

https://updates.oracle.com/download/22083030.html

Be sure to review the readme.html file that is packaged with in the downloadable patch archive. The readme.html file includes important information about installing the bundle patch, as well as information about additional installation requirements.

For more information about required patches, see the Release Notes for Identity and Access Management.

5.4.3 Applying Patches Automatically as Part of the LCM Tools Automated Deployment Process

If you are using Life Cycle Management tools to perform an automated deployment, patches can be applied at the time of commissioning. To do this, patches need to be downloaded and placed into specific locations within the software repository.

Before starting the deployment, download any patches that are listed in the Release Notes, plus any other patches that are appropriate for your environment. The deployment tool can apply these patches automatically at the time it runs.

Download the patches from http://support.oracle.com and expand each patch to the directory appropriate for the product, as listed in Table 5-6. If the directory does not exist, create it.

After expanding the patch, make sure that the Patch Directory (as listed in Table 5-6) contains a directory which is a number. That directory contains directories and files similar to:

• etc

• files

• README.txt

This is the directory layout for most patches. In some cases, such as bundle patches, the layout might be similar to:

bundle_patch_no/product/product_patch_no

In this case, make sure that it is product_patch_no which appears in the Patch Directory not bundle_patch_no.

If a bundle patch contains fixes for multiple products make sure that the individual patches appear in the correct Patch Directory as listed below.

Table 5-6 Product Patch Directories in the Life Cycle Repository

Product	Patch Directory
Oracle Common	REPOS_HOME/installers/oracle_common/patch
Directory	REPOS_HOME/installers/oud/patch/oud REPOS_HOME/installers/oud/patch/odsm
Oracle Access Management Access Manager	REPOS_HOME/installers/iamsuite/patch/oam
OHS	REPOS_HOME/installers/webtier/patch
WebGate	REPOS_HOME/installers/webgate/patch
Oracle Identity Manager	REPOS_HOME/installers/iamsuite/patch/oim
SOA	REPOS_HOME/installers/soa/patch
WebLogic Server	REPOS_HOME/installers/smart_update/weblogic

5.4.4 Obtaining the Oracle Identity and Access Management Software for a Manual Deployment

For a manual enterprise deployment of Oracle Identity and Access Management, you must obtain all the software downloads listed in Table 5-7.

For information on obtaining Oracle Fusion Middleware 11g software, see the Oracle Fusion Middleware Download, Installation, and Configuration ReadMe.

Table 5-7 Oracle Software Required for an Oracle Identity and Access Management Enterprise Deployment

Product	Version
Oracle HTTP Server	11.1.1.9.0
Java	1.7
Oracle WebLogic Server	10.3.6.0
Oracle Identity and Access Management	11.1.2.3.0
Oracle Unified Directory	11.1.2.3.0
Oracle Internet Directory	11.1.1.9.0
Oracle Traffic Director	11.1.1.9.0
Oracle SOA Suite	11.1.1.9.0
Oracle WebGate for Oracle HTTP Server	11.1.1.9.0
Oracle WebGate for Oracle Traffic Director	11.1.1.9.0
Repository Creation Utility	11.1.1.9.0

Note:

You can also use the software repository described in Section 5.4.3, "Applying Patches Automatically as Part of the LCM Tools Automated Deployment Process".

5.4.5 Obtaining Patches for a Manual Deployment

Before using the manual procedures for installing and configuring an enterprise deployment, be sure you have obtained the latest patches from My Oracle Support. For more information, see the Release Notes for Oracle Identity and Access Management.