2.1 Topology

The number of instances of each major subsystem and the ways in which they can be connected are potentially great in number. Not every possible layout is supported. It is important to understand not only the possibilities but why some configurations are preferred over others.

2.1.1 Minimal design

The simplest logical configuration of the user application is a one-of-everything installation, consisting of one identity vault tree, one instance of the Identity Manager engine and drivers, and one instance of JBoss running a single instance of the user application. In terms of physical implementation, you could, in theory, run all of this on one box. But you would not do that in the real world, for a variety of reasons (security, maintainability, and performance chief among them). In deciding on the number of machines needed for a practical real-world installation, you would want (at a minimum) to take the following into account:

  • Novell Audit server: This piece is responsible for capturing event information (and possibly a good deal of other information) from the user application environment at runtime. It may also be doing double-duty as a persistence store for other applications in your company. For a variety of reasons, you probably will not want to put other major pieces of the Identity Manager system (for example, JBoss 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. In all likelihood, you will want to consider having the identity vault exist on a dedicated machine. That is to say, you probably do not want another high-traffic system, such as JBoss with a deployment of the user application, running alongside the identity vault on the same machine.

  • Database: If this instance of MySQL (or other supported database) is also your Novell Audit database, it will probably be on a dedicated machine. Consider that this piece is used by the user application in the following ways:

  • As a persistence store for portal configuration data

  • As the persistence store for state information on in-process workflows (if the Provisioning Module is installed)

  • Optionally, as the logging store for Novell Audit.

  • JBoss: For performance and capacity reasons, you will probably want to run this piece on a dedicated machine.

These considerations suggest the following minimal 3-machine configuration:

Description: Description: Illustration

2.1.2 High availability design

Clustering for high availability/capacity is discussed in detail in a later section of this chapter. For now, you should know that:

  • Identity Manager supports high availability of the identity vault, engine, and drivers through the multinode installation and shared-storage mechanisms described in the chapter on “High Availability” in the main Identity Manager Administration Guide. A comprehensive recipe for setting up such a system using SUSE Linux is given in the article at:

    http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm

  • High availability of the user application is available through JBoss clustering. You can set up a JBoss cluster such that each node runs one user application instance. The instances will all be coequals (peers). Nevertheless, there is no session replication across instances. Each instance is responsible for its own unit of work and will not finish a session that was started on a sister node.

  • Automatic failover is not supported (for the reasons just stated). But an interrupted workflow can resume again after the loss of a cluster node, if a new node is brought online with the same workflow engine ID as the one that went down. (In this case, resumption of the interrupted workflow occurs automatically, as soon as the new workflow engine starts.)

Again, see Section 2.4, Clustering (further below) for a more detailed discussion of these issues.

2.1.3 Design constraints

In general, the two most important architectural constraints to be aware of are:

  • No user application instance can service (search/query, add users to, and so forth) more than one user container. Also, once a user container has been associated with the application, that association 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:

Description: Description: Illustration

During installation of the user application, you are asked to specify the top-level user container that your installation will look 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) will be 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. (Consult the Novell eDirectory Administration Guide for more information on filtered replicas.)

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