About the IAM Exalogic Enterprise Deployment

4 About the IAM Exalogic Enterprise Deployment

This chapter introduces and describes the Oracle Identity and Access Management deployment topologies on Exalogic hardware. These topologies represent specific reference implementations of the concepts described in Understanding an Enterprise Deployment.

This book assumes you have an understanding of Exalogic, if you wish to gain further information on how Exalogic works, refer to the Enterprise Deployment Guide for Exalogic for the release of Exalogic you are using.

Topics:

Parent topic: Understanding an Enterprise Deployment

Why Install Oracle IAM on Exalogic

Oracle Exalogic is a highly available, high performance integrated hardware appliance from Oracle. Oracle Fusion Middleware components, when deployed onto Oracle Exalogic, get the benefit of its superior networking, resulting in improved application throughput. In addition, WebLogic server has had a number of optimizations that enable it to run faster on Oracle Exalogic. These optimizations further increase the throughput of the applications deployed.

Deploying Oracle IAM on Exalogic ensures that you have a highly available infrastructure that provides you with the maximum availability and performance available.

Parent topic: About the IAM Exalogic Enterprise Deployment

Understanding the Primary and Build your Own Enterprise Deployment Topologies on Exalogic

This guide focusses on the primary deployment topology of deploying Oracle Identity and Access Management on virtual Exalogic or Oracle Cloud Machine.

The following secondary topologies are illustrated and explained in this document:

Oracle Identity Management on Physical Exalogic
Oracle Identity Management on Exalogic with an external web tier

Virtual Exalogic vs Physical Exalogic:

A physical Exalogic deployment uses the raw processing power of an Exalogic rack. Products are deployed directly onto the compute nodes. Oracle Virtual Exalogic uses the same underlying hardware, but the Oracle Elastic Cloud or Oracle Cloud Machine infrastructure is used to provide a virtualization layer allowing smaller virtual servers to be created.

Virtual servers are used to provide a similar set of hosts to the platform deployment. Physical Exalogic deployments have access to greater computing power but some of that power can be wasted if the compute nodes are not used to the maximum. A virtualized deployment provides greater separation and manageability, but provides extra design complexity to ensure that no two virtual servers of the same type run on the same underlying compute node.

Parent topic: About the IAM Exalogic Enterprise Deployment

Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

This diagrams in this section illustrate the Oracle Identity and Access Management Exalogic topologies.

Topics:

Parent topic: About the IAM Exalogic Enterprise Deployment

Diagram of Oracle Identity and Access Management on Physical Exalogic

Figure nameillustrates the Oracle Identity and Access Management consolidated topology.

Figure 4-1 Exalogic Physical Deployment Topology

Parent topic: Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

Diagram of Oracle Identity and Access Management on Virtual Exalogic

Figure name illustrates the Oracle Identity and Access Management distributed topology.

Figure 4-2 Exalogic Virtual Deployment Topology Diagram

Parent topic: Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

Diagram of Oracle Identity and Access Management with an External Web Tier

Figure name illustrates the Oracle Identity and Access Management consolidated topology with an external Web tier.

Figure 4-3 Exalogic Topology with External OHS

Parent topic: Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

About the Primary Oracle Identity and Access Management Topology Diagrams

This section describes the Primary Oracle Identity and Access Management Topology diagrams.

This section contains the following topics:

Parent topic: Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

About Product Separation

An Oracle Identity and Access Management deployment is made up of a number of components. These components include:

Web Servers
WebLogic Application Servers
LDAP - Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.

Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network.
Database

About Access and Governance Domains

Figure 4-1, Figure 4-2, and Figure 4-3 depict a separation between each component. In addition, the WebLogic components are further split into two different WebLogic domains: IAMAccessDomain, and IAMGovernanceDomain. Products are distributed as follows:

IAMAccessDomain contains Oracle Access Manager, Oracle Mobile Security Suite.
IAMGovernanceDomain contains Oracle Identity Manager, Oracle Business Intelligence.

This split is due to the different operational and availability requirements demanded of the individual components. Typically components in the IAMAccessDomain have a higher availability requirement than those in the IAMGovernanceDomain. By separating these components, you can manage the availability requirements differently. You can patch governance components independently of access components, and you can shutdown the governance instance without impacting the access components.

This separation is extended to the Directory tier as well, which is often released at a different time to that of the Web tier and the Application tier components. Separation of the directory provides the same benefits as splitting the domains, for example, Independent upgrade and patching.

A further benefit of this separation is that you can build a topology in a modular fashion. You can start with a directory and extend it to Access Components, and later extend it to Governance components, without needing to affect the deployed software or configuration of existing components, unless you are wiring them together.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

Understanding the Directory Tier

The Directory tier consists of two physical host computers, where an LDAP compliant directory is installed. Typically, this is Oracle Unified Directory (OUD).

The Directory tier is often combined with the Data tier.

This release of the Enterprise Deployment Guide supports three different LDAP directories. You may be creating these directories for the first time, or you may be using existing directories from within the organization. The directories supported are Oracle Unified Directory (OUD).

The directory you choose will be organization dependent.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

Understanding the Web Tier

In Oracle 12c, Oracle Traffic Director (OTD) can be used in either collocated or standalone mode.

Standalone mode does not support the use of failover groups, and its management via graphical interface is limited. Therefore, it is recommended that you deploy OTD using the collocated mode. When using the collocated mode, the OTD management components are placed into a WebLogic administration server. These components can be placed into an existing webLogic domain.

When your OTD instance is routing requests to multiple domains as it is, in Oracle Identity and Access Management, it is recommended that you use a dedicated domain for Oracle Traffic Director. This allows Oracle Traffic director to be managed independently of the domains to which it is routing requests.

In a platform deployment where each zone is separated by firewalls, it is recommended that the administration server be placed into the application zone. In an Oracle Exalogic deployment, where there is no zone separation, the administration server can co—exist with the OTD instances.

If you are using an external web tier, and if your external webtier is running OTD, then it is recommended that the OTD administration server be placed outside of the Web Tier DMZ.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

Differences Between an Exalogic Deployment and a Platform Deployment

When you deploy Oracle Identity and Access Management on Exalogic, most, if not all of the components are installed inside the Exalogic appliance. As described in About a Typical Enterprise Deployment, a typical enterprise deployment is distributed amongst various tiers. Because the hardware components are incorporated into the Exalogic Appliance, the number of tiers available is reduced.

There is no need for an application or directory tier and if your Exalogic Appliance is linked to an Exadata appliance. Database tier is moved to Exadata if Exalogic is linked to it.

The second major difference between a platform and an Exalogic deployment is that the Exalogic deployment use Oracle Traffic Director instead of Oracle HTTP server. In an Exalogic deployment, Oracle Traffic Director performs a number of roles. It can act as both a load balancer for internal traffic ensuring that it is not exposed outside the Exalogic Appliance, and as a Web Server.

If you use an external Web tier, you do not need to use the Web serving characteristics of Oracle Traffic Director.

When you deploy Oracle Fusion Middleware on Oracle Exalogic, you gain access to a number of in-built WebLogic optimizations which ensure that the Fusion Middleware deployment uses some of the in-built Exalogic technologies to provide better performance.

Parent topic: Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies

Oracle Identity and Access Management and Exalogic Networking

One of the core advantages of Exalogic is its fast and flexible network. When deploying Oracle IAM on Exalogic, you have to consider how you wish to use the Oracle Exalogic Networking.

There are three types of networks within an Exalogic appliance:

IPoIB - This is the internal Infiniband Network that connects the internal components of the Exalogic appliance. This network is fast, but cannot be connected to the outside world. The benefit of this network is that it can be used to ensure that network traffic is kept private from the outside world. The downside to using this network is where external components need to access application components inside the Exalogic Appliance.
EoIB - This network also uses the Exalogic Infiniband Network but it is possible to connect this network to the standard corporate network. This allows external component to communicate directly to components inside Exalogic. This network is always used for communication between your hardware load balancer and Oracle Traffic Director.
eth0 - This is the management network it is used for connecting to the Exalogic components through the built-in ethernet network. This network is only used for management operations and should not be used for production deployments. Its this network that is used to log in to the Exalogic components to configure them.

This section includes the following topics:

Parent topic: About the IAM Exalogic Enterprise Deployment

Considerations for Choosing your Exalogic Network

Some components within IAM, by default, only talk on a single network. For example, WebLogic Managed servers, other components such as Oracle Traffic Director communicate on both the internal networks. This is why Oracle Traffic Director is the preferred load balancer for traffic once it enters the Exalogic Appliance.

When choosing which Exalogic Network to use, consider the following:

If you are planning to create a multi-data center deployment, you should configure your components to use the EoIB network.
Are you planning to use an external Web tier? If so, by default, you can configure your components to work on the EoIB Network.
If all Traffic comes through Oracle Traffic Director, and once it reaches there, all traffic stays within the Exalogic appliance, configure components to use the IPoIB network.
If all LDAP traffic originates within the Exalogic Appliance, configure your LDAP server to use the IPoIB network.
If your database resides in an Exadata appliance, which is directly connected to the Exalogic appliance, use the IPoIB network. If not, then you should use the EoIB network.

Note:

You can configure Oracle Access Manager Managed Servers to communicate on both networks using the OAM Proxy port.

You can configure Standard WebLogic Managed Servers to listen on multiple networks using different channels.

Parent topic: Oracle Identity and Access Management and Exalogic Networking

Typical IAM Network Usage

This section describes a typical IAM network usage. It contains the following sections:

Parent topic: Oracle Identity and Access Management and Exalogic Networking

Virtual Exalogic

Figure 4-4 shows the typical network map for an Identity and Access Management deployment on a virtual Exalogic environment.

Figure 4-4 Virtual Exalogic Network Map

Description of "Figure 4-4 Virtual Exalogic Network Map"

If you are not using an external Web tier, you can configure all components to use the Internal IPoIB network. Oracle traffic Director is configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.

The elements of Figure 4-4 are defined in Table 4-1.

Table 4-1 Exalogic Virtual IP Addresses Worksheet

Hostname Example for This Guide	Interface	IP Address/Subnet	Type	Host	Bound By	Details
WEBHOST1	bond0	192.168.2.1/255.255.224.0	IPoIB/Fixed	vServer1/WEBHOST1	NA	Access to vServer11/WEBHOST1 via the internal IPoIB network.
WEBHOST2	bond0	192.168.2.2/255.255.224.0	IPoIB/Fixed	vServer2/WEBHOST2	NA	Access to vServer2/WEBHOST2 via the internal IPoIB network.
OAMHOST1	bond0	192.168.2.3/255.255.224.0	IPoIB/Fixed	vServer3/OAMHOST1	NA	Access to vServer3/OAMHOST1 via the internal IPoIB network
OAMHOST2	bond0	192.168.2.4/255.255.224.0	IPoIB/Fixed	vServer4/OAMHOST2	NA	Access to vServer4/OAMHOST2 via the internal IPoIB network
OIMHOST1	bond0	192.168.10.5/255.255.224.0	IPoIB/Fixed	vServer5/OIMHOST1	NA	Access to vServer5/OIMHOST1 via the internal IPoIB network
OIMHOST2	bond0	192.168.10.6/255.255.224.0	IPoIB/Fixed	vServer6/OIMHOST2	NA	Access to vServer6/OIMHOST2 via the internal IPoIB network
LDAPHOST1	bond0	192.168.10.7/255.255.224.0	IPoIB/Fixed	vServer7/LDAPHOST1	NA	Access to vServer7/LDAPHOST1 via the internal IPoIB network
LDAPHOST2	bond0	192.168.10.8/255.255.224.0	IPoIB/Fixed	vServer8/LDAPHOST2	NA	Access to vServer8/LDAPHOST2 via the internal IPoIB network
OTDADMINVHN	bond1:1	10.10.30.1/255.255.224.0	EoIB/Floating	vServer1/WEBHOST1	OTD Administration Server	A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from WEBHOST1 to WEBHOST2.
IADADMINVHN	bond1:1	10.10.30.2/255.255.224.0	EoIB /Floating	vServer3/OAMHOST1	IAMAccessDomain Administration Server	A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from OAMHOST1 to OAMHOST2.
IGDADMINVHN	bond1:1	10.10.30.3/255.255.224.0	EoIB /Floating	vServer5/OIMHOST1	IAMGovernanceDomain Administration Server	A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from OIMHOST2 to OIMHOST1
WEBHOST1VHN1	OTD	10.10.50.1/255.255.224.0	EoIB /Floating	vServer1/WEBHOST1	OTD - WEBHOST1	A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is optional
WEBHOST2VHN1	OTD	10.10.50.2/255.255.224.0	EoIB /Floating	vServer2/WEBHOST2	OTD - WEBHOST2	A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is optional.
OIMHOST1VHN1	bond0:1	192.168.30.1/255.255.240.0	IPoIB/Floating	vServer5/OIMHOST1	WLS_OIM1 Default Channel	Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2 Used for Whole server migration only.
OIMHOST2VHN1	bond0:1	192.168.30.2/255.255.240.0	IPoIB/Floating	vServer6/OIMHOST2	WLS_OIM2 Default Channel	Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1 Used for Whole server migration only.
OIMHOST1VHN2	bond0:2	192.168.30.3/255.255.240.0	IPoIB/Floating	vServer5/OIMHOST1	WLS_SOA1 Default Channel	Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2 Used for Whole server migration only.
OIMHOST2VHN2	bond0:2	192.168.30.4/255.255.240.0	IPoIB/Floating	vServer6/OIMHOST2	WLS_SOA2 Default Channel	Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1. Used for Whole server migration only.
OIMHOST1VHN3	bond0:3	192.168.30.5/255.255.224.0	IPoIB/Floating	vServer5/OIMHOST1	WLS_BI1 Default Channel	Initially enabled in OIMHOST1 and can be failed over by server migration to OIMHOST2. Used for Whole server migration only.
OIMHOST2VHN3	bond 0:3	192.168.30.6/255.255.224.0	IPoIB/Floating	vServer6/OIMHOST2	WLS_BI2 Default Channel	Initially enabled in OIMHOST2 and can be failed over by server migration to OIMHOST1. Used for Whole server migration only.
WEBHOST1-EXT	bond1	10.10.10.1/255.255.240.0	EoIB/Fixed	vServer1/WEBHOST1	NA	A fixed IP allowing the vServer to be accessed by an External Load balancer
WEBHOST2-EXT	bond1	10.10.10.2/255.255.240.0	EoIB/Fixed	vServer2/WEBHOST2	NA	A fixed IP allowing the vServer to be accessed by an External Load balancer
WEBHOST1-STOR	bond3	192.168.32.1/255.255.240.0	IPoIB/Fixed	vServer1/WEBHOST1	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
WEBHOST2-STOR	bond3	192.168.32.2/255.255.240.0	IPoIB/Fixed	vServer2/WEBHOST2	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
OAMHOST1-STOR	bond3	192.168.32.3/255.255.240.0	IPoIB/Fixed	vServer3/OAMHOST1	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
OAMHOST2-STOR	bond3	192.168.32.4/255.255.240.0	IPoIB/Fixed	vServer4/OAMHOST2	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
OIMHOST1-STOR	bond3	192.168.32.5/255.255.240.0	IPoIB/Fixed	vServer5/OIMHOST1	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
OIMHOST2-STOR	bond3	192.168.32.6/255.255.240.0	IPoIB/Fixed	vServer6/OIMHOST2	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
LDAPHOST1-STOR	bond3	192.168.32.7/255.255.240.0	IPoIB/Fixed	vServer7/LDAPHOST1	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
LDAPHOST2-STOR	bond3	192.168.32.8/255.255.240.0	IPoIB/Fixed	vServer8/LDAPHOST2	NA	A fixed IP address allowing the vServer to connect to the ZFS Storage appliance using the internal network.
OAMHOST1-DATA	bond4	192.168.10.3/255.255.240.0	IPoIB/Fixed	vServer3/OAMHOST1	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
OAMHOST2-DATA	bond4	192.168.10.4/255.255.240.0	IPoIB/Fixed	vServer4/OAMHOST2	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
OIMHOST1-DATA	bond4	192.168.10.5/255.255.240.0	IPoIB/Fixed	vServer5/OIMHOST1	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
OIMHOST2-DATA	bond4	192.168.10.6/255.255.240.0	IPoIB/Fixed	vServer6/OIMHOST2	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
LDAPHOST1-DATA	bond4	192.168.10.7/255.255.240.0	IPoIB/Fixed	vServer7/LDAPHOST1	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
LDAPHOST2-DATA	bond4	192.168.10.8/255.255.240.0	IPoIB/Fixed	vServer8/LDAPHOST2	NA	A fixed IP address allowing the vServer to connect to the Exadata appliance using the default internal network.
IGDINTERNAL	OTD	192.168.50.1/255.255.224.0	IPoIB/ Floating	vServer1/WEBHOST1	NA	Oracle Traffic Director failover group for SOA
IDSTORE	OTD	192.168.50.3/255.255.224.0	IPoIB/ Floating	vServer2/WEBHOST2	NA	Oracle Traffic Director failover group for LDAP.

Note:

The IP addresses listed in Table 4-1 are for example only. Because of the way that IP addresses are allocated in virtual Exalogic, it is highly unlikely that you will be able to use the exact values in this table.

Parent topic: Typical IAM Network Usage

Physical Exalogic

Figure 4-5 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment.

Figure 4-5 Physical Exalogic Network Map

Description of "Figure 4-5 Physical Exalogic Network Map"

The elements of Figure 4-5 are defined in Table 4-2.

Table 4-2 Exalogic Physical IP Addresses Worksheet

Hostname Example for This Guide	Interface	IP Address/Subnet	Type	Host	Bound By	Details
IAMHOST1	bond0	192.168.10.1/255.255.224.0	IPoIB/ Fixed	ComputNode1/IAMHOST1	NA	Access to IAMHOST1 using the internal IPoIB network.
IAMHOST2	bond0	192.168.10.2/255.255.224.0	IPoIB/ Fixed	ComputNode2/IAMHOST2	NA	Access to IAMHOST2 using the internal IPoIB network.
OTDADMINVHN	bond1:1	10.10.30.1/255.255.224.0	EoIB /Floating	ComputNode1/IAMHOST1	OTD Administration Server	A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from IAMHOST1 to IAMHOST2.
IADADMINVHN	bond1:2	10.10.30.2/255.255.224.0	EoIB /Floating	ComputNode2/IAMHOST1	IAMAccessDomain Administration Server	A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2.
IGDADMINVHN	bond1:3	10.10.30.3/255.255.224.0	EoIB /Floating	ComputNode1/IAMHOST1	IAMGovernanceDomain Administration Server	A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2.
WEBHOST1VHN	OTD	10.10.50.1/255.255.224.0	EoIB /Floating	ComputNode1/IAMHOST1	OTD - IAMHOST1	A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is recommended but optional.
WEBHOST2VHN	OTD	10.10.50.2/255.255.224.0	EoIB /Floating	ComputNode2/IAMHOST2	OTD - IAMHOST2	A floating IP Address managed by OTD. This is the IP Address to which load balancers will connect. This is recommended but optional
OIMHOST1VHN1	bond0:1	192.168.30.1/255.255.240.0	IPoIB/ Floating	ComputNode1/IAMHOST1	WLS_OIM1 Default Channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole server migration only.
OIMHOST2VHN1	bond0:1	192.168.30.2/255.255.240.0	IPoIB/ Floating	ComputNode2/IAMHOST2	WLS_OIM2 Default Channel	Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole server migration only.
OIMHOST1VHN2	bond0:2	192.168.30.3/255.255.240.0	IPoIB/ Floating	ComputNode1/IAMHOST1	WLS_SOA1 default channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole server migration only.
OIMHOST2VHN2	bond0:2	192.168.30.4/255.255.240.0	IPoIB/ Floating	ComputNode2/IAMHOST2	WLS_SOA2 default channel	Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole server migration only.
OIMHOST1VHN3	bond 0:3	192.168.30.5/255.255.240.0	IPoIB/Floating	ComputeNode1/IAMHOST1	WLS_BI1 default channel	Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1 Used for Whole server migration only.
OIMHOST2VHN3	bond 0:3	192.168.30.6/255.255.240.0	IPoIB/Floating	ComputeNode2/IAMHOST2	WLS_BI1 default channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2 Used for Whole server migration only.
IAMHOST1EXT	bond1	10.10.10.1/255.255.240.0	EoIB/Fixed	ComputNode1/IAMHOST1	NA	A fixed IP allowing the compute node to be accessed by an External Corporate Network (EoIB)
IAMHOST2EXT	bond1	10.10.10.2/255.255.240.0	EoIB/Fixed	ComputNode2/IAMHOST2	NA	A fixed IP allowing the compute node to be accessed by an External Corporate Network (EoIB)
IGDINTERNAL	OTD	192.168.50.1/255.255.224.0	IPoIB/ Floating	ComputNode1/IAMHOST1	NA	Oracle Traffic Director failover group for SOA
IDSTORE	OTD	192.168.50.3/255.255.224.0	IPoIB/ Floating	ComputNode2/IAMHOST2	NA	Oracle Traffic Director failover group for LDAP

Parent topic: Typical IAM Network Usage

Physical Exalogic with External Web Tier

Figure 4-6 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment with external Web Tier.

Figure 4-6 Physical Exalogic Network Map

Description of "Figure 4-6 Physical Exalogic Network Map"

The elements of Figure 4-6 are defined in Table 4-3.

Table 4-3 Exalogic Physical IP Addresses Worksheet

Hostname Example for This Guide	Interface	IP Address/Subnet	Type	Host	Bound By	Details
IAMHOST1	bond0	192.168.10.1/255.255.224.0	IPoIB/Fixed	ComputNode1/IAMHOST1	NA	Access to IAMHOST1 using the internal IPoIB network.
IAMHOST2	bond0	192.168.10.2/255.255.224.0	IPoIB/Fixed	ComputNode2/IAMHOST2	NA	Access to IAMHOST2 using the internal IPoIB network.
OTDADMINVHN	bond1:1	10.10.30.1/255.255.224.0	EoIB/Floating	ComputNode1/IAMHOST1	OTD Administration Server	A floating IP address for the Administration Server is recommended, if you want to manually migrate the OTD Administration Server from IAMHOST1 to IAMHOST2.
IADADMINVHN	bond1:2	10.10.30.2/255.255.224.0	EoIB/Floating	ComputNode2/IAMHOST1	IAMAccessDomain Administration Server	A floating IP address for the IAMAccessDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2.
IGDADMINVHN	bond1:1	10.10.30.3/255.255.224.0	EoIB/Floating	ComputNode1/IAMHOST1	IAMGovernanceDomain Administration Server	A floating IP address for the IAMGovernanceDomain Administration Server is recommended, if you want to manually migrate the Administration Server from IAMHOST1 to IAMHOST2.
OIMHOST1VHN1	bond1:3	10.10.30.4/255.255.240.0	EoIB/Floating	ComputNode1/IAMHOST1	WLS_OIM1 Default Channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only.
OIMHOST2VHN1	bond1:2	10.10.30.7/255.255.240.0	EoIB/Floating	ComputNode2/IAMHOST2	WLS_OIM2 Default Channel	Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only.
OIMHOST1VHN2	bond1:4	10.10.30.5/255.255.240.0	EoIB/Floating	ComputNode1/IAMHOST1	WLS_SOA1 default channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only.
OIMHOST2VHN2	bond0:3	10.10.30.8/255.255.240.0	EoIB/Floating	ComputNode2/IAMHOST2	WLS_SOA2 default channel	Initially enabled in ComputeNode3 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only.
OIMHOST1VHN3	bond1:5	10.10.30.6/255.255.224.0	EoIB/Floating	ComputNode1/IAMHOST1	WLS_BI1 Default Channel	Initially enabled in IAMHOST1 can be failed over by server migration to IAMHOST2. Used for Whole Server Migration only.
OIMHOST2VHN3	bond1:4	10.10.30.9/255.255.224.0	EoIB/Floating	ComputNode2/IAMHOST2	WLS_BI1 Default Channel	Initially enabled in IAMHOST2 can be failed over by server migration to IAMHOST1. Used for Whole Server Migration only.
IAMHOST1-EXT	bond1	10.10.10.1/255.255.240.0	EoIB/Fixed	ComputNode1/IAMHOST1	NA	A fixed IP allowing the compute node to be accessed by an External Load balancer
IAMHOST2-EXT	bond1	10.10.10.2/255.255.240.0	EoIB/Fixed	ComputNode2/IAMHOST2	NA	A fixed IP allowing the compute node to be accessed by an External Load balancer
IDSTORE	OTD	192.168.50.3/255.255.224.0	IPoIB/Floating	ComputNode2/IAMHOST2	NA	Oracle Traffic Director failover group for Oracle Unified Directory

Parent topic: Typical IAM Network Usage

Summary of Oracle Identity and Access Management Load Balancing Virtual Server Names

In order to distribute requests equally between servers, and to provide high availability, a hardware load balancer is required. The hardware load balancer should exist on redundant hardware to ensure maximum availability. The hardware load balancer is configured to recognize a set of virtual server names.

If you have configured your Exalogic appliance so that all traffic is using the EoIB network, your load balancer can be configured the same way as platform deployments. However, a better approach on Exalogic is to use Oracle Traffic Director for load balancing between internal components.

For information about the purpose of these server names, see Summary of the Typical Load Balancer Virtual Server Names.

The hardware load balancer in Oracle Identity and Access Management deployments recognizes the following virtual server names.

login.example.com - This virtual server name is used for all incoming access traffic. It acts as the access point for all HTTP traffic to the runtime Access Management components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:
```
login.example.com:443
```
If you are using an external Web tier, this virtual host distributes requests among the external Web servers. Otherwise, it distributes requests between the internal Oracle Traffic Director servers.
prov.example.com - This virtual server name is used for all incoming governance traffic. It acts as the access point for all HTTP traffic to the runtime Access Management components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:
```
prov.example.com:443
```
If you are using an external Web tier, this virtual host distributes requests between the external Web servers. Otherwise, it distributes requests between the internal Oracle Traffic Director servers.

In previous releases of the Enterprise Deployment Guide login.example.com and prov.example.com were the same entry point. This release allows for them to be separated out. This will enable smarter routing from the load balancer, allow a more modular deployment and will facilitate future Multi-datacenter deployments. If desired these two entry points can still be combined to provide a single point of entry into the IAM deployment.
iadadmin.example.com - This virtual server name is for internal communications between the application tier components in the Access Domain only and is not exposed to the Internet. The primary use of this virtual server is to allow the Mobile Security Access Service to communicate with either the Oracle HTTP server, which is being used to distribute requests to Oracle Mobile Security Manager, or it can be used to send requests directly to the WebLogic Managed Servers hosting Mobile Security Manager.

The traffic from clients to this URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:
```
iadadmin.example.com:80
```
If you are not using external Web Servers, then this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
igdadmin.example.com - This virtual server name is for internal communications between the application tier components in the Governance Domain only and is not exposed to the Internet. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Identity Manager System Administration console.

The traffic from clients to this URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:
```
igdadmin.example.com:80
```
If you are not using external Web Servers, this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
igdinternal.example.com - This virtual server name is for internal communications between the application tier components in the Governance domain only and is not exposed to the Internet. Specifically, for the Oracle Identity and Access Management enterprise topology, this URL is used for both Oracle OIM Suite and Oracle SOA Suite internal communications.

The traffic from clients to this URL is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2:
```
igdinternal.example.com:7777
```
If you are not using external Web Servers, then this virtual host can be configured on Oracle Traffic Director rather than the hardware load balancer.
idstore.example.com - This virtual server name is used for all incoming identity store traffic. It acts as the access point to the LDAP directory instances. This virtual server is not exposed to the Internet.

The traffic from clients to this URL is may or may not be SSL-enabled, depending on the type of LDAP directory in use, typically this is non-SSL enabled for Oracle Unified Directory. Clients access this service using the following address and the requests are forwarded to the LDAP instances.

This virtual host is configured on Oracle Traffic Director rather than the hardware load balancer.
oam.example.com:5575 – This is an additional load balancer virtual host used in multi datacenter deployments only. This virtual host routes requests to the Oracle Access Management (OAM) proxy port on the OAM Managed servers. For example, 5575.

Parent topic: Oracle Identity and Access Management and Exalogic Networking

Summary of the Managed Servers and Clusters on the Application Tier Hosts

The Application tier hosts the Administration Server and Managed Servers in the Oracle WebLogic Server domains.

Depending upon the components you select, the Oracle WebLogic Server domain for the Oracle Identity and Access Management consists of the clusters shown in Table 4-4. These clusters function as active-active high availability configurations.

Table 4-4 Summary of Managed Servers and Clusters

Domain	Cluster	Managed Servers
IAMAccessDomain	Oracle Access Manager	WLS_OAM1, WLS_OAM2
NA	Oracle Policy Manager	WLS_AMA1, WLS_AMA2
IAMGovernanceDomain	Oracle Identity Manager	WLS_OIM1, WLS_OIM2
NA	Oracle SOA Suite	WLS_SOA1, WLS_SOA2
NA	Oracle Web Service Manager	WLS_WSM1, WLS_WSM2

Depending upon the components you select, the Oracle WebLogic Server domain for the Oracle Identity and Access Management consists of the clusters shown in …. These clusters function as active-active high availability configurations.

Parent topic: About the IAM Exalogic Enterprise Deployment

Understanding Oracle Traffic Director

Oracle Traffic Director (OTD) serves as a load balancer and a Web router. OTD is not a fully functional Web server, but can perform many tasks that a Web server performs. It is made up of an administration server, instances, and Failover Groups.

For information about installing and configuring Oracle Traffic Director, see Configuring Oracle Traffic Director for an Enterprise Deployment.

Topics:

Parent topic: About the IAM Exalogic Enterprise Deployment

About Oracle Traffic Director in a Standard Exalogic Deployment

Oracle Traffic Directory is used to load balance requests to:

LDAP - Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.

Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network
Internal call backs - Manage a Virtual IP Address that internal servers can access for the purposes of making Inter application call backs

Receive requests on the Callback Virtual IP address and pass them on to the appropriate Weblogic Managed Servers using the IPoIB Network

The hardware load balancer sends requests to Oracle Traffic Director.

Oracle Traffic Director receives requests from the Load balancer and from internal applications requiring access to other internal applications or LDAP. Upon receipt of these requests, Oracle Traffic Director forwards them on to WebLogic Managed Servers or LDAP.

For more information about the standard Exalogic topology described in this guide, see Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies.

Parent topic: Understanding Oracle Traffic Director

About Oracle Traffic Director in a Deployment with Oracle HTTP Server

Oracle Traffic Directory is used to load balance requests to:

LDAP - Receive HTTP requests from the hardware load balancer on the EoIB network and forward them on to the WebLogic Managed Servers on the IPoIB network.

Manage a Virtual IP Address that internal servers can access for the purposes of making LDAP calls.

Receive requests on the LDAP Virtual IP address and pass them on to the running LDAP instances using the IPoIB Network.
Internal call backs - Manage a Virtual IP Address that internal servers can access for the purposes of making Inter application call backs.

Receive requests on the Callback Virtual IP address and pass them on to the appropriate Weblogic Managed Servers using the IPoIB Network.

A hardware load balancer sends requests to Oracle HTTP Server (OHS), which resides on commodity servers on the corporate ethernet network. The OHS then passes these requests onto WebLogic servers using the EoIB network.

Parent topic: Understanding Oracle Traffic Director

About Oracle Traffic Director Failover Groups

Oracle Traffic Director manages floating IP addresses for LDAP and internal callbacks on the IPoIB network. When a failover group is created, you specify the IP address netmasks you wish to use for a primary node and a failover node. It uses a heartbeat between instances to detect a failure.

For information about creating and configuring failover groups, see Creating a Failover Group for Virtual Hosts.

Parent topic: Understanding Oracle Traffic Director

About Oracle Traffic Director and the Load Balancer

You can configure the load balancer to point to Oracle Traffic Director instances. However, the load balancer failure detection is slower than using OTD failover groups. Therefore, Oracle recommends creating an external failover group for each Oracle Traffic Director instance and pointing the load balancer to the failover groups.

Parent topic: Understanding Oracle Traffic Director

About Oracle Traffic Director and Identity and Access Management

Oracle Traffic Director has its own WebGate, which is used for authentication. After WebGate is installed and configured, Oracle Traffic Director intercepts requests for the consoles and forwards them to Access Manager for validation.

Internal callbacks go back to failover groups to make efficient use of the Infiniband network.

Parent topic: Understanding Oracle Traffic Director

About Exalogic Optimizations for WebLogic

Exalogic offers the following optimizations for WebLogic:

Domain Level:

Check box in WebLogic Domain
Increased Network IO
Increased efficiency in session replication
Self-tuning thread pool

Cluster Level:

Creates a custom network replication channel for improved network throughput.

For more information about, and procedures for Exalogic Optimization see "WebLogic Server Domain Optimizations for Exalogic Elastic Cloud Software" in Administering WebLogic Server for Oracle Exalogic Elastic Cloud.

Parent topic: About the IAM Exalogic Enterprise Deployment

Roadmap for Implementing the Primary Oracle Identity and Access Management Topologies

Table 4-5 provides a roadmap for implementing the primary IAM suite topologies on Exalogic.

Table 4-5 Roadmap for Implementing Primary IAM Suite Topologies on Exalogic

Tasks	For More Information, See
Review the primary Exalogic enterprise topologies.	About the IAM Exalogic Enterprise Deployment
Review the hardware and software requirements and procure the resources for the enterprise deployment.	Procuring Resources for an Enterprise Deployment
Prepare the load balancers and firewalls.	Preparing the Load Balancer and Firewalls for an Enterprise Deployment
Prepare the storage and understand the directory structure.	Preparing the File System for an Enterprise Deployment
Prepare the Exalogic machine.	Preparing Exalogic for an Oracle Identity and Access Management Deployment
Configure the host computers.	Preparing the Host Computers for an Enterprise Deployment
Prepare the database.	Preparing the Database for an Enterprise Deployment
Configure Oracle LDAP.	Configuring Oracle LDAP for an Enterprise Deployment
Create the Infrastructure domain for Oracle Access Management.	Creating Infrastructure for Oracle Access Management
Create the Infrastructure domain for Oracle Identity Governnance.	Creating Infrastructure for Oracle Identity Governance
Configure the Oracle Traffic Director.	Configuring Oracle Traffic Director for an Enterprise Deployment
Configure the Oracle Access Management.	Configuring Oracle Access Management
Configure the Oracle Identity Governance (OIG).	Configuring Oracle Identity Governance
Configure multi-data center setup.	Configuring Multi-Data Center
Configure server migration settings.	Using Whole Server Migration and Service Migration in an Enterprise Deployment
Configure Single Sign-On (SSO).	Configuring Single Sign-On for an Enterprise Deployment

Parent topic: About the IAM Exalogic Enterprise Deployment

Building your Own Oracle Identity and Access Management Topology

This document provides step-by-step instructions for configuring the two primary enterprise topologies for Oracle Identity and Access Management, which are described in Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies.

However, Oracle recognizes that the requirements of your organization may vary, depending on the specific set of Oracle Fusion Middleware products you purchase and the specific types of applications you deploy.

In many cases, you can install and configure an alternative topology, one that includes additional components, or one that does not include all the Oracle Identity and Access Management products shown in the primary topology diagrams.

The following sections describe some alternative Oracle Identity and Access Management topologies you can implement, using some variations of the instructions in this guide:

OAM Only with an Existing Directory
OIM Only with an Existing Directory
OAM/OIM Integrated in a Modular Deployment
OAM/OIM Integrated with an Existing Directory

Note:

The deployment can be extended with Oracle Adaptive Access Manager or Oracle Privileged Account Manager. See the MAA Web site for details.

Note:

If you decide to deploy a custom environment that varies from the one provided in this guide, then deploy Oracle Identity and Access Management manually. The Life Cycle Management (LCM) Tools provided to automate the installation and deployment do not support all the alternative topologies.

Parent topic: About the IAM Exalogic Enterprise Deployment

About Installing and Configuring a Custom Enterprise Topology

If you choose to implement a topology that is not described in this guide, be sure to review the certification information, system requirements, and interoperability requirements for the products you want to include in the topology.

After you verify that the topology is supported, you can either use these instructions as a guide to installing and configuring the components you need, or you can install and configure a standard installation topology using the Oracle Fusion Middleware 11g installation guides and use the "Start Small and Scale Out" approach to configuring your environment.

Parent topic: About the IAM Exalogic Enterprise Deployment

About Using Service or Server Migration to Enable High Availability of the Enterprise Topology

To ensure high availability of the Oracle Identity Governance products and components, this guide recommends that you enable Oracle WebLogic Server Whole Server Migration for the Oracle Identity Manager and Oracle SOA Suite clusters that you create as part of the reference topology.

For static clusters, you can configure Automatic Service Migration by using the Configuration Wizard HA Options screen. If you select the Enable Automatic Service Migration option, it configures migratable target definitions that are required for automatic service migration. In the same screen, you can use JTA Transaction Log Persistence and JMS Server Persistence options to configure them with JDBC stores automatically. Oracle recommends that you enable these options when you configure static clusters in the OIM enterprise deployment.

For dynamic clusters, migratable targets are not required because some functionalities of the automatic service migration are provided inherently by the dynamic cluster. The Configuration Wizard High Availability Options screen is not used for dynamic clusters but some additional steps are required to configure the leasing and the persistent stores migration policies. Oracle recommends that you perform these post-steps when you configure dynamic clusters in the OIM enterprise deployment.

For more information, see Using Whole Server Migration and Service Migration in an Enterprise Deployment.

Parent topic: About the IAM Exalogic Enterprise Deployment