Tuesday, February 14, 2012

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 2nd 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 2nd hosts but that is fairly self evident.

2 comments:

  1. Brian,
    thank you for great posts. You make the mountains of confusing Oracle online documentation to make some sense.
    I have a question regarding OIF deployment simplification. We have deployed OIF in a stand-alone mode on a single server, and would like to add a second server for HA, but your support informed us that we cannot convert existing single node into the cluster, we need to do new installation. We would like to avoid re-install on the first server. Can we simply install another stand-alone OIF on a second server and connect them to the same OIF schema, and use sticky sessions on Load Balancers abobe OHS to ensure proper routing?

    ReplyDelete
  2. Hmmm. It may work but I don't think it is supported. I wouldn't go that route. I've heard that there is a way to migrate from single server to a cluster but I've never done it.

    Next time, create a cluster of one during the install so you can move to move servers easily going forward.

    Good luck.

    ReplyDelete

Note: Only a member of this blog may post a comment.