Standard deployment topology patterns overview

Authors: TimFeeney, ShubjitNaik, DanielMoul, PaulEllis
Build basis: ELM 7.x

This page complements the Standard Topologies Overview by providing diagrams and description of the main pattern alternatives that can be used for specific reasons within an ELM deployment topology. Below we include only the parts of the deployment topology needed to present the pattern and not nodes that would be deployed in the wider topology.

Multiple database servers

For medium to large ELM deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and the most utilized applications (often RM or CCM) are first to be separated onto their own database servers.

Modified Departmental pattern

ELM deployments may begin with the Departmental topology but with increasing scale needs, will need to evolve though not necessarily to a full Enterprise topology. The Modified Departmental pattern is a step in that direction. This is especially useful as usage grows to include widespread use of Global Configuration Management or higher usage of a single application.

Multiple application servers of the same product

• Multiple application servers topology pattern for for ELM 7.x:
  

For guidance regarding multiple instances of the same application server

• Planning for multiple Jazz server instances
• Multiple CCM Applications - A User Perspective

Opportunities for clustering

Clustering various servers in your distributed ELM deployment can provide improved system resilience and system throughput.

ELM application clustering

This pattern shows just the ELM nodes required to cluster EWM (CCM). ETM (QM) can also be clustered in ELM 7.x.

Please Note: The Jazz Authorization Server (JAS) is required for ELM application clustering.

In the topic Setting up a Change and Configuration Management application clustered environment version 6.0.5 and later we provide specific guidance on setting-up a Distributed Cache Microservice (DCM) for clustered applications:

The microservice must be installed and run on a machine that is accessible by all nodes of the clustered application. By default, the microservice is installed on the Jazz Team Server (JTS) machine under the server/clustering/cache directory and is started as part of the JTS startup sequence (on demand, only when a clustered application asks for it).

Note: There should be one DCM per application cluster. Do not share between clusters. For optimal performance, the DCM should be moved to a dedicated machine. The size of this machine will depend on the number of users in your cluster and their usage. DCM can be deployed on a machine as small as 2 core, 4gb RAM and 100GB disk, but you will need to monitor the system and increase its size based on your load. We found that a 4 core, 8gb ram, 200gb disk virtual machine handled 500 users (but it will vary based on what your users do with the system).

IBM HTTP Server (IHS) and Jazz Authorization Server (JAS) Clustering

An application delivery controller (ADC) is a computer network device in a datacenter, often part of an application delivery network, that helps perform common tasks, such as those done by web accelerators to remove load from the web servers themselves.

Many ELM deployments are already using an ADC e.g., F5 BIG-IP, CITRIX NetScaler, A10. We have quite a few customers using a combination of an ADC and an IHS reverse proxy. Some customers are using multiple ADCs and load balancing clustered IHS reverse proxies. Best practice: Reverse Proxies and Load Balancers in CLM Deployment.

If you have an ELM deployment using Jazz Security Architecture (JSA) Single Sign-On, you can reduce the risk of outages by clustering a single Jazz Authorization Server with multiple replicas. If you only have a single JAS instance, then all authenticate requests will fail if that instance goes offline. If you have a JAS cluster, then login requests will succeed since they will automatically fall over to active JAS replicas.

Additional guidance on configuring JAS Clustering: Setting up a cluster of Jazz Authorization Servers.

Eclipse Amlen MQTT broker clustering

See the Eclipse Amlen documentation for details.

Security (OIDC, SCIM, SAML)

Jazz Authorization Server as the OpenID Connect Provider

Jazz Security Architecture SSO is available as an authentication option for ELM 7.x. Based on OpenID Connect, authentication is NOT performed by the container hosting Jazz applications but instead is delegated to a separate Jazz Authorization Server (JAS), which performs the role of an OpenID Connect provider (OP). Jazz Authorization Server is based on the IBM WebSphere Liberty profile.

For further Information on Jazz Security Architecture see Jazz Server Authentication Explained and JAS Landing page

For instructions to configure CE/CLM to authenticate via JAS as OIDC provider please visit Configure OIDC Authentication for CE/CLM

• OIDC topology pattern for ELM 7.x:
  

System for Cross-domain Identity Management (SCIM)

You can configure the Jazz Authorization Server (Liberty OpenID Connect Provider) to use the System for Cross-domain Identity Management (SCIM) for the WebSphere Application Server Liberty profile. SCIM is a standard for cloud-based identity management for single sign-on (SSO) in browsers. It is a RESTful protocol for identity account management operations. Jazz Authorization Server supports SCIM in the Liberty profile.

Restriction : When you configure your Jazz Authorization Server to use the System for Cross-domain Identity Management (SCIM), you cannot use the electronic signatures features in EWM, ETM or DOORS Next, since they currently require a direct connection to the Identity Provider (LDAP).

For instructions to configure JAS with SCIM see Configure JAS for SCIM

• SCIM topology pattern for ELM 7.x:
  

Third party OIDC provider

You can configure Jazz Authorization Server (Liberty OpenID Connect provider) to further delegate the user authentication to your standard, corporate OpenID Connect provider using the Liberty Social Login feature. Using this method, one can delegate authentication from JAS to another OIDC provider.

In this approach, user authentication is further delegated from JAS to another OIDC provider. This leads to redirections which some clients cannot work with. Following are the limitations:

• Authenticating through a third party OIDC provider works only for browser-based clients
• Rich clients (Eclipse, Visual Studio) and command line utilities can be configured to authenticate via JAS, and hence JAS needs to be connected to the LDAP / directory server that the third party OIDC provider works with.

For instructions to configure ELM to authenticate via your in-house OIDC provider, see Configure CE/CLM with Third Party OIDC Provider

• Third party OIDC provider topology pattern for ELM 7.x:
  

SAML as Identity Provider

Jazz Authorization Server supports Security Assertion Markup Language (SAML) web browser single sign-on (SSO) which enables web applications to delegate user authentication to a SAML identity provider instead of a configured user registry.

SAML is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. A SAML assertion is an XML formatted token that is used to transfer user identity and attribute information from the identity provider (IdP) of a user to a trusted service provider (SP) as part of completing an SSO request. For more information, see SAML web single sign-on.

In this approach the user authentication is further delegated from JAS to a SAML Identity Provider, this leads to redirections which some clients cannot do. Following are the limitations:

• Authenticating through a SAML Identity Provider for ELM works only for browser-based clients
• Rich clients (Eclipse, Visual Studio) and command line utilities can be configured to authenticate via JAS, and hence JAS needs to be connected to the LDAP / directory server that is configured with the SAML Identity Provider.

For instructions to configure ELM to Authenticate via SAML IDP see Configure CE/CLM with SAML IDP

• SAML topology pattern for ELM 7.x:
  

LQE rs deployment options

Existing ELM deployments

For customers with existing data, IBM's recommendation is to deploy the two LQE architectures side-by-side, keeping the LQE Jena system as is while adding an additional system to host LQE rs. A Report Builder can be configured to run both Jena and SQL queries, and even to compare the queries for correctness and performance. This allows you to transition to LQE rs with the least amount of risk. The LQE Jena system can be decommissioned after the transition is completed.

New ELM deployments

For customers just starting out with the ELM solution, IBM's recommendation is to deploy LQE rs only.

For more information on LQE rs, see LQE rs 703 Performance Report

Multiple Distributed LDX Servers in Modified Federated Topology

In some highly active environments, a single LDX server in the modified federated topology may not be sufficient. To alleviate this, multiple LDX instances can be deployed to manage versioned links for individual business units that only index the application sources used by that business unit. This is similar to the configuration in the federated topology where individual business units deploy their own LDX where there may be performance issues due to overall load or volume.

• Optional Distributed LDX Topology for ELM 7.x:
  

• For deployment and configuration information, see Multiple Distributed LDX instances in a Modified Federated Topology Configuration

Related topics:

• Standard Topologies Overview
• Deployment planning
• Deployment planning and design