The first chapter of the EDG includes a good diagram and description of Oracle’s reference architecture for the IAM platform for Fusion Apps. The rest of the EDG walks you through building out an IDM environment that fits this reference architecture.
In this post I’ll give a guided tour of this reference architecture and at the end discuss how you can still use the EDG to build out a simplified environment if that is the route that you want to take.
1) The directory or data tier consisting of the directory (OID), virtual directory (OVD) and databases supporting the whole IDM environment.
2) The application tier consisting of all the services (OAM, OIM, ODSM, SOA) that run in WebLogic Server.
3) The web tier consisting of the web server (OHS) and HTTP load balancer.
The reference architecture is fully highly available. For the databases, this is accomplished through use of RAC. For everything else, it is accomplished by having 2 nodes with redundant services and utilizing load balancing in some form or another for all communication. If you are no planning on building an HA environment or if you just want a simplified view of things, you can almost cut the above diagram in half and only consider one side.
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.
These simplifications can all be done and I’ll discuss this in more detail in my next post. For now, just know that you can build a functional IDM environment for Fusion Apps without FA and on far less hosts than the reference architecture. In fact, the IDM environment can be consolidated all the way down to 2 hosts, 1 for the DBs and 1 for everything else.
There are two databases in the data tier. The OID RAC DB is the repository for OID and the other DB is the repository for everything else. The EDG shows these as separate databases. They can in fact be on the same physical host and be part of the same database install (ORACLE _HOME) but they should be separate instances. The DBs are specified as RAC but RAC is not required for non-HA environments.
Moving up from the DB in the directory/data tier we have the OIDHOST1, OIDHOST2, OVDHOST1, and OVDHOST2. These hosts contain the instances of OID and OVD respectively. Note, that this does not include ODSM, WLS, EM or other components that come when you do a basic install of OID and/or OVD on a single node. I’ll also mention that combining the OID and OVD hosts is a good way to consolidate nodes (while preserving the tiers) if you are looking to do that.
Moving up into the application tier we have IDMHOST1 and IDMHOST2. The IDMHOST is probably the most central host in the reference architecture. It is the “master node” for the WebLogic domain that will be the central part of the IDM environment. IDMHOST1 contains the following applications all running on WebLogic: WLS admin server, Enterprise Manager, OAM admin server, OAM managed server, and ODSM (the admin app for OID and OVD). IDMHOST2 contains the OAM managed server and ODSM and inactive instances of the WLS admin server, enterprise manager and the OAM admin server.
The reason that the WLS admin server, OAM admin server, and EM are inactive on IDMHOST2 is because you can only have one WLS admin server running in a domain at 1 time and all these apps run in the WLS admin server. In fact, the admin server for a domain is configured to bind to a single specific IP address and so if you want to be able to run it at all on IDMHOST2, you have to configure a virtual IP address (VIP) that can float between IDMHOST1 and IDMHOST2 for the admin server to bind to.
The other hosts in the application tier are OIMHOST1 and OIMHOST2 which host the managed servers for OIM and the OIM specific deployment of SOA suite. OIMHOST can be consolidated with IDMHOST if you are looking to do node/host consolidation. The thing to keep in mind is that OIM can chew up a lot (all) of a system’s resources when it does bulk operations like reconciliations. If you have a small number of users and/or aren’t using OIM as your enterprise identity management / provisioning solution then this probably isn’t too much of an issue. However, one should definitely keep this and mind and tread carefully when running OIM on the same box as other critical services.
Finally in the web tier we have an HTTP load balancer, WEBHOST1 and WEBHOST2 which contains the web servers (OHS). The OAM webgate is installed and enabled on both OHS servers. This is an important point to understand. OAM is used to protect the web interfaces in the IDM environment and all HTTP traffic into the IDM environment comes through the OHS servers in the web tier. There is no direct access to any of the services.
Lastly, I’ll point out that the naming conventions here are somewhat confusing. For instance, IDMHOST does not contain OIM. Rather it is the “master” host for the IDM domain and contains the admin server along with OAM and ODSM. Keep this in mind as you go through your build out as I’ve seen many people get understandably confused by this and attempt to execute steps on the wrong box during the build out.
When one of the services in the app tier needs to talk to the identity store and policy store, it will talk to OVD on OVDHOST and OID on OIDHOST (depending on specific configuration) over well… the LDAP protocol. More accurately, the services will talk to a load balancer that may or may not be the same as the load balancer used for the HTTP traffic. My point being that a load balancer is required here to load balance the LDAP traffic.
LDAP traffic will also come into the system from Fusion Apps itself which will query both the identity store and policy store. Requests to the policy store will come through the load balancer and be dispatched directly to OID. Requests to the identity store will come through the load balancer and be dispatched to either OID or OVD, again depending on the configuration.