2.1 Topology

Each major subsystem can have many instances and many ways of connecting. Not every possible layout is supported. This section includes the following subsections that describe the possible configurations.

2.1.1 Design Constraints

Audit Server: This application is responsible for capturing event information (and possibly a good deal of other information) from the User Application environment at runtime. It might also be doing double duty as a persistence store for other applications in your company. For a variety of reasons, you must never put other major pieces of the Identity Manager system (for example, the application server or the Identity Vault) on the same machine as the Audit server.

Identity Vault: This is a heavily trafficked component with a need for good performance and good scalability. You must put the Identity Vault on a dedicated machine. You should never put another high-traffic system, such as an application server with a deployment of the User Application, on the same machine as the Identity Vault.

Database: If this instance of a supported database is also your auditing database, it is probably on a dedicated machine. The User Application uses this component in the following ways:

  • As a persistence store for portal configuration data

  • As the persistence store for state information on in-process workflows

  • Optionally, as the logging store for Novell Identity Audit.

Application Server: For performance and capacity reasons, you must run this piece on a dedicated machine.

These considerations require at a minimum a three-machine configuration.

Additional Constraints The following additional architectural constraints apply to any User Application configuration:

  • No User Application instance can service (search, query, add users to, and so forth) more than one user container. Also, a user container association with an application is meant to be permanent.

  • No User Application driver can be associated with more than one User Application, except when the User Applications are installed on sister nodes of the same JBoss cluster. In other words, a one-to-many mapping of drivers to User Applications is not supported.

The first constraint enforces a high degree of encapsulation in User Application design.

Suppose you have the following organizational structure:

Figure 2-1 Sample Organizational Structure

Illustration

During installation of the User Application, you are asked to specify the top-level user container that your installation looks for in the Identity Vault. In this case, you could specify ou=Marketing,o=ACME or (alternatively) ou=Finance,o=ACME. You cannot specify both. All User Application searches and queries (and administrator log-ins) are scoped to whichever container you specify.

NOTE:In theory, you could specify a scope of o=ACME in order to encompass Marketing and Finance. But in a large organization, with potentially many ou containers (rather than just two relating to Marketing and Finance), this is not likely to be practical.

It is possible, of course, to create two independent installations of the User Application (sharing no resources in common), one for Marketing and another for Finance. Each installation would have its own database, its own appropriately configured User Application driver, and each User Application would be administered separately, possibly having unique themes.

If you truly need to place Marketing and Finance within the same scope for one User Application installation, there are two possible tactics to consider. One is to insert a new container object (for example, ou=MarketingAndFinance) in the hierarchy, above the two sibling nodes; then point to the new container as the scope root. Another tactic is to create a filtered replica (a special type of eDirectory tree) that combines the needed parts of the original ACME tree, and point the User Application at the replica’s root container. For more information about filtered replicas, see the eDirectory Administration Guide.

If you have questions about a particular system layout, contact your Novell representative for assistance or advice.

2.1.2 High Availability Design

Clustering for high availability and capacity is discussed in Section 2.8, Clustering. For now, you should know that:

  • High availability of the User Application is available through clustering. You can set up a cluster so that each node runs one User Application instance. The instances are all coequals (peers).

  • Automatic failover is supported. Tasks can still be completed after a loss of a cluster node. A manual process needs to be used to resume processing of workflows assigned to the node that has been lost.

See Section 2.8, Clustering for more information.