Hostname References and Architecture Simplification in the IDM Build Out for Fusion Apps

In my last post, I discussed the reference architecture for the Identity and Access Management build out of Fusion Apps.

The reference architecture is pretty complex in that it is completely HA, separates all the IDM services into 3 tiers for maximum network security, and separate many of the services onto different physical nodes to account for load separation for high volume production environments.

There are reasons one might want to simplify this for development, QA, or even production environments.  Specifically, you may want to consolidate physical hosts, not do HA, or not use a load balancer for some traffic that does in the reference architecture.  

I will now discuss how to use the IDM EDG (Oracle Identity Management Enterprise Deployment Guide, Fusion Apps Edition) as a guide for your build out even if you want to deviate from the reference architecture in some way.  The key to this is understanding how the EDG makes hostname references and understanding how these references translate to the environment you are creating.

 There are two types of host references in the EDG.  The first type is a reference to the logical name for a physical host.  These are the labels for each node name in the reference diagram above: WEBHOST1, IDMHOST1, OIMHOST1, OIDHOST1 etc.  The EDG uses these hosts when they want you to perform some task.  So, it will say things like “Follow these steps to configure the Oracle Internet Directory components, OIDHOST1 and OIDHOST2 on the directory tier with Oracle Internet Directory”.

The other type of host reference are references to the virtual hostnames that define the hosts that requests are made to in the system and here I am referring to requests made by end users and component to component communication which includes the IDM components themselves and components from the Fusion Apps domain.  These virtual hosts are described in chapter 2 of the 11.1.1.5 EDG.  These hosts include sso.mycompany.com, admin.mycompany.com, and idstore.mycompany.com.  In the reference architecture, all these hosts will resolve to load balancers.  Throughout the EDG, these virtual hostnames are referred to when you need to specify a URL or hostname in a components configuration.  For example, when configuring OAM you specify IDSTORE_HOST: idstore.mycompany.com in the properties file that the IDM config tool will utilize to help configure OAM.

What I recommend to people doing IDM build outs for Fusion Apps is to maintain a table that translates the logical names for physical hosts and virtual hostname references in the EDG to the real physical host and virtual hostnames in the environment.

EDG Node Name	Components	Physical Host
WEBHOST	OHS	web-3231
WEBHOST 2	OHS	web-3232
IDMHOST	WLS Admin, OAM, ODSM, EM	app-7473
IDMHOST2	WLS Admin (not running), OAM, ODSM, EM	app-7474
OIMHOST	OIM, SOA Suite	app-7473
OIMHOST2	OIM, SOA Suite	app-7474
OIDHOST	OID	dir-1351
OIDHOST2	OID	dir-1352
OVDHOST	OVD	dir-1351
OVDHOST2	OVD	dir-1352
OIDDBHOST	DB	db-1
OIMDBHOST	DB	db-2

You’ll notice in the above example I’ve defined a mapping for the physical host references that deviates a little from the EDG reference architecture in that the IDMHOSTs are combined with the OIMHOSTs and the OIDHOSTs are combined with the OVDHOSTs.

And

Virtual Host	Maps To
sso.mycompany.com	sso.acme.com
oiminternal.mycompany.com	oiminternal.acme.com
admin.mycompany.com	Idm-fa-admin.acme.com
policystore.mycompany.com	ldap-lbr.acme.com
idstore.mycompany.com	ldap-lbr.acme.com

Likewise, you’ll notice that the above example of a virtual hostname mapping reflects that I’m using a single LDAP directory for both the policy store and identity store.

How to Simplify

So if you want to deviate from the EDG by consolidating physical hosts, simply create a mapping where the hosts you want to consolidate resolve to the same physical host.

If you want to not implement an HA environment or implement partial HA then just eliminate the 2^nd host for each logical host in your table (WEBHOST2, IDMHOST2 etc.).

If you don’t want to use a load balancer for LDAP communication then have policystore.mycompany.com and idstore.mycompany.com resolve directly to the host of your LDAP directory (be it OID or OVD).

If you don’t want to user a load balancer for your HTTP traffic then have the sso, admin, and oiminternal hosts resolve directly to your OHS server.

For consolidation you can then just follow the instruction in the EDG using your map to guide you in making sure that you are really executing each step on the right host and entering the right host in the URL and hostname references that come up during the build out.

If you are skipping HA for some or all of the build out then you also have to skip the steps related to the build out of 2^nd hosts but that is fairly self evident.