3 Understanding 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 Chapter 1, "Understanding a Typical Enterprise Deployment."
-
Understanding the Primary and Build your Own Enterprise Deployment Topologies on Exalogic
-
Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies
-
Oracle Identity and Access Management and Exalogic Networking
-
Summary of the Managed Servers and Clusters on the Application Tier Hosts
-
Roadmap for Implementing the Primary Oracle Identity and Access Management Topologies
-
Building your Own Oracle Identity and Access Management Topology
-
About Installing and Configuring a Custom Enterprise Topology
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.
3.1 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.
3.2 Understanding the Primary and Build your Own Enterprise Deployment Topologies on Exalogic
This guide focuses on three primary reference topologies for Oracle Identity and Access Management (IAM) Suite on Exalogic. The components installed into each topology are essentially the same. These topologies are very similar to the platform topologies in that they are distributed topologies which are more suited to virtual Exalogic deployments, and a consolidated topology which is more suited to Physical Exalogic deployments. There is, however, a third topology which is a hybrid topology that uses some components installed in Exalogic and others, for example, the Web tier, installed on commodity hardware outside of the Exalogic machine.
The exact Oracle Identity and Access Management topology you install and configure for your organization might vary, but for the three primary topologies, this guide provides step-by-step instructions for installation and configuration of the topologies. To simplify the installation and configuration process, this guide utilizes the Oracle IAM deployment Wizard, which, once you set it up to layout your topology, will automatically configure the majority of it for you.
Once you have created your deployment, this guide provides instructions for extending the deployment to include additional IAM products. In addition, while procedures in this book do not cover every IAM product, these steps can easily be adapted to any other IAM product.
3.3 Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies
This diagrams in this section illustrate Oracle IAM Exalogic topologies.
This section contains the following topics:
-
Section 3.3.1, "Diagram of Oracle Identity and Access Management on Physical Exalogic"
-
Section 3.3.2, "Diagram of Oracle Identity and Access Management on Virtual Exalogic"
-
Section 3.3.3, "Diagram of Oracle Identity and Access Management with an External Web Tier"
-
Section 3.3.4, "Understanding the Primary Oracle Identity and Access Management Topology Diagrams"
-
Section 3.3.5, "Differences Between an Exalogic Deployment and a Platform Deployment"
3.3.1 Diagram of Oracle Identity and Access Management on Physical Exalogic
Figure 3-1 illustrates the Oracle Identity and Access Management consolidated topology.
3.3.2 Diagram of Oracle Identity and Access Management on Virtual Exalogic
Figure 3-2 illustrates the Oracle Identity and Access Management distributed topology.
3.3.3 Diagram of Oracle Identity and Access Management with an External Web Tier
Figure 3-3illustrates the Oracle Identity and Access Management consolidated topology with an external Web tier.
3.3.4 Understanding 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:
3.3.4.1 About Product Separation
An Oracle Identity and Access Management deployment is made up of a number of components. These components include:
-
Web Servers
-
WebLogic
-
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 3-1, Figure 3-2, and Figure 3-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.
3.3.4.2 Understanding the Directory Tier
The Directory tier consists of two physical host computers, where an LDAP compliant directory is installed. Typically, this is Oracle Internet Directory (OID) or 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 three different directories supported are:
-
Oracle Unified Directory (OUD)
-
Oracle Internet Directory (OID)
-
Microsoft Active Directory (AD)
The directory you choose will be organization dependent.
3.3.5 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 Chapter 1, "Understanding 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.
3.4 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.
3.4.1 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:
-
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.
3.4.2 Typical IAM Network Usage
This section describes a typical IAM network usage. It contains the following sections:
3.4.2.1 Physical Exalogic
Figure 3-4 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment.
Figure 3-4 Physical Exalogic Network Map
Description of ''Figure 3-4 Physical 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 and MSAS are configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 3-4 are defined in Table 3-1.
Table 3-1 Exalogic Physical IP Addresses Worksheet
| Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | 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. |
|
|
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. |
|
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. |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
IADINTERNAL |
OTD |
192.168.50.2/255.255.224.0 |
IPoIB/ Floating |
ComputNode2/IAMHOST2 |
NA |
Oracle Traffic Director failover group for MSM |
|
|
IDSTORE |
OTD |
192.168.50.3/255.255.224.0 |
IPoIB/ Floating |
ComputNode2/IAMHOST2 |
NA |
Oracle Traffic Director failover group for LDAP |
3.4.2.2 Virtual Exalogic
Figure 3-5 shows the typical network map for an Identity and Access Management deployment on a virtual Exalogic environment.
If you are not using an external Web tier, you can configure all components to use the Internal IPoIB network. Oracle traffic Director and MSAS are configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 3-5 are defined in Table 3-2.
Table 3-2 Exalogic Virtual IP Addresses Worksheet
| Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | 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 |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
IADINTERNAL |
OTD |
192.168.50.2/255.255.224.0 |
IPoIB/Floating |
vServer2/WEBHOST2 |
NA |
Oracle Traffic Directory Group for MSM |
|
|
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 3-2 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.3.4.2.3 Physical Exalogic with External Web Tier
Figure 3-6 shows the typical network map for an Identity and Access Management deployment on a physical Exalogic environment with external Web Tier.
Figure 3-6 Physical Exalogic Network Map
Description of ''Figure 3-6 Physical 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 and MSAS are configured to accept requests on the EoIB network, but pass them on to WebLogic and LDAP using the IPoIB network.
The elements of Figure 3-6 are defined in Table 3-3.
Table 3-3 Exalogic Physical IP Addresses Worksheet
| Hostname Example for This Guide | Interface | IP Address/Subnet | Customer Value | 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. |
|
|
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. |
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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 |
3.4.3 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 Section 1.2.3.2, "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.
-
msas.example.com - This virtual server name is used for all incoming Mobile Security traffic. It acts as the access point for all HTTPS traffic to the runtime Mobile Security Access Service. 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:
msas.example.com:9002
If you are using an external web tier, then this virtual host will distribute requests amongst the external MSAS servers, otherwise it will distribute requests amongst the internal MSAS servers.
-
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.
-
iadinternal.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. Specifically, for the Oracle Identity and Access Management enterprise topology, this URL is used by the Mobile Security Access Server to callback to Oracle 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:
iadinternal.example.com:7777
If you are not using external Web Servers, 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 and Oracle Internet Directory and enabled for Microsoft Active 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.
3.5 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 3-4. These clusters function as active-active high availability configurations.
Table 3-4 Summary of Managed Servers and CLusters
| Domain | Cluster | Managed Servers |
|---|---|---|
|
IAMAccessDomain |
Oracle Access Manager |
wls_oam1, wls_oam2 |
|
Oracle Policy Manager |
wls_ama1, wls_ama2 |
|
|
Oracle Mobile Security Manager |
wls_msm1, wls_msm2 |
|
|
IAMGovernanceDomain |
Oracle Identity Manager |
wls_oim1, wls_oim2 |
|
Oracle SOA Suite |
wls_soa1, wls_soa2 |
|
|
Oracle Business Intelligence |
wls_bi1, wls_bi2 |
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.
3.6 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 Section 14.2, "Configuring Oracle Traffic Director."
This section contains the following topics
-
Section 3.6.1, "About Oracle Traffic Director in a Standard Exalogic Deployment."
-
Section 3.6.2, "About Oracle Traffic Director in a Deployment with Oracle HTTP Server."
-
Section 3.6.3, "About Oracle Traffic Director Failover Groups."
-
Section 3.6.4, "About Oracle Traffic Director and the Load Balancer."
-
Section 3.6.5, "About Oracle Traffic Director and Identity and Access Management."
3.6.1 About Oracle Traffic Director in a Standard Exalogic Deployment
Oracle Traffic Director is supported only with Exalogic deployments. It 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 Section 3.3, "Diagrams of the Primary Oracle Identity and Access Management Exalogic Enterprise Topologies."
3.6.2 About Oracle Traffic Director in a Deployment with Oracle HTTP Server
Oracle Traffic Director is supported only with Exalogic deployments. It 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.
3.6.3 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 Section 14.2.10, "Creating a Failover Group for Virtual Hosts."
3.6.4 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.
3.6.5 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.
3.7 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.
3.8 Roadmap for Implementing the Primary Oracle Identity and Access Management Topologies
Table 3-5 provides a roadmap for implementing the primary IAM suite topologies on Exalogic.
Table 3-5 Roadmap for Implementing Primary IAM Suite Topologies on Exalogic
| Scenario | Tasks | For More Information, See |
|---|---|---|
|
Creating an IAM Enterprise Deployment manually on Exalogic |
Review the primary Exalogic enterprise topologies. |
|
|
Review the hardware and software requirements and procure the resources for the enterprise deployment. |
Chapter 5, "Procuring Resources for an Enterprise Deployment" |
|
|
Prepare the load balancers and firewalls. |
Chapter 6, "Preparing the Load Balancer and Firewalls for an Enterprise Deployment" |
|
|
Prepare the storage and understand the directory structure. |
||
|
Prepare the Exalogic machine. |
Chapter 8, "Preparing Exalogic for an Oracle Identity and Access Management Deployment" |
|
|
Configure the host computers. |
Chapter 9, "Configuring the Host Computers for an Enterprise Deployment" |
|
|
Prepare the database. |
Chapter 10, "Preparing the Database for an Enterprise Deployment" |
|
|
Install the required softwares. |
Chapter 11, "Installing Oracle Fusion Middleware in Preparation for an Enterprise Deployment" |
|
|
Configure Oracle LDAP. |
Chapter 12, "Configuring Oracle LDAP for an Identity and Access Manager Enterprise Deployment" |
|
|
Prepare the identity store. |
||
|
Configure the Oracle Web Tier. |
||
|
Create the WebLogic domains. |
||
|
Set up the Node Manager. |
Chapter 16, "Setting Up Node Manager for an Enterprise Deployment" |
|
|
Configure Oracle Access Management (OAM). |
||
|
Configure Oracle Mobile Security Services (OMSS). |
||
|
Configure Oracle Identity Manager (OIM). |
||
|
Configure Oracle BI Publisher (BIP). |
||
|
Configure server migration settings. |
Chapter 21, "Configuring Server Migration for an Enterprise Deployment" |
|
|
Configure Single Sign-On (SSO). |
||
|
Creating an IAM Enterprise Deployment using Life Cycle Management Tools (IDMLCM), on Exalogic |
Understand the automated deployment process. |
Chapter 23, "Introduction to the Life Cycle Management (LCM) Tools" |
|
Prepare the Exalogic machine. |
Chapter 8, "Preparing Exalogic for an Oracle Identity and Access Management Deployment" |
|
|
Install the Oracle Identity and Access Management Life Cycle Management Tools. |
Chapter 24, "Installing Oracle Identity and Access Management Life Cycle Management Tools" |
|
|
Create a deployment response file for the topology you are deploying. |
||
|
Deploy Identity and Access Management. |
||
|
Perform the required post-deployment tasks. |
3.9 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 Section 3.3, "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 ones provided in this guide, then you typically 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.For information about the topologies that you can deploy using LCM Tools, see Chapter 23, "Introduction to the Life Cycle Management (LCM) Tools".
3.10 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.
3.11 About Using Server Migration to Enable High Availability of the Oracle Identity and Access Management Enterprise Topology
To ensure high availability of the Oracle Access Suite products and components, this guide recommends that you enable Oracle WebLogic Server Whole Server Migration for the Oracle Identity Manager, Oracle SOA Suite, and Oracle Business Intelligence clusters that you create as part of the reference topology.
Whole server migration provides for the automatic restart of a server instance, with all of its services, on a different physical machine. When a failure occurs in a server that is part of a cluster that is configured with server migration, the server is restarted on any of the other machines that host members of the cluster.
For more information, see Chapter 21, "Configuring Server Migration for an Enterprise Deployment."