EditAttachPrintable
r49 - 2020-05-18 - 10:56:47 - Main.sbeardYou are here: TWiki >  Deployment Web > DeploymentPlanningAndDesign > StandardTopologiesOverview

updated.png Standard deployment topologies overview

Authors: StevenBeard, GrantCovell, TimFeeney, DavidChadwick, VaughnRokosz, ThomasPiccoli, BreunReed
Build basis: CLM and SSE 3.x, 4.x, 5.x, CE/CLM 6.x and ELM 7.x

constantchange16.png Note to author: This page is referenced by ELM product documentation and the ELM launchpad.

In past releases, we talked about using the Collaborative Lifecycle Management (CLM) or Systems and Software Engineering (SSE) solutions depending on whether the primary use case was a software development versus a more integrated product development of both hardware and software. The common goal of the standard topologies is to provide a complete solution infrastructure for both software or systems development organizations. To simplify our discussion, we will present a single set of Continuous Engineering (CE) / Collaborative Lifecycle Management (CLM) topologies going forward that can be deployed in part or as a whole depending on what capabilities that you need.

Since April 2019, CE, CLM and other references to the Jazz product set were renamed to Engineering Lifecycle Management (ELM). The Renaming the IBM Continuous Engineering Portfolio article explains what each application will be referred to from now on. For consistency, the older names have been kept in this article, unless referring to the ELM 6.0.6.x release where the name change occurred.

One of the most frequently asked questions is how to deploy the full CE/CLM solution so that it performs well, runs robustly, and evolves without restriction. Administrators ask about possible deployment strategies because they must balance two sometimes opposing forces: the desire to build what's right for their organizations and the desire to stay within the mainstream of the CE/CLM product evolution so they can easily and quickly reap the benefits of new capabilities.

CE/CLM system requirements permit a wide range of supported middleware platforms and topologies upon which to host the solution (though we are opinionated about which, all things being equal, are likely to be optimal – see below). We strongly recommend having a reverse proxy server in front of either a centralized or a distributed set of web application servers. To simplify the wide range of choices, this article outlines several standard topologies which are the expected and most frequently chosen deployment patterns over the past several years.

Publishing these standard topologies represents tried and true examples of successful deployments. Additionally, the CE/CLM solution system testing organization uses these topologies to perform deep “customer simulation” testing, which includes installation, upgrade, functional, performance, and robustness testing. By adhering closely to one of these standard topologies, you will have an easier time characterizing your deployment in the event of an interaction with IBM software support. These topologies become a “shorthand” reference that can be used whenever a CE/CLM deployment is discussed. For example, when system performance testing results or a high availability configuration is discussed, the appropriate standard topology can be referenced.

Several teams came together to define and document these standard topologies. These teams design and execute system, performance, and reliability testing, develop and support the CE/CLM products, and work directly with clients to design and implement the CE/CLM solution at locations worldwide.

Strengthening our recommended deployment guidance for CE/CLM 6.x and beyond

The CE/CLM tools support a variety of web application servers, operating systems and databases. For maximum flexibility to adopt new advanced features and to simplify a potential move in the future to or from the IBM CE/CLM on Cloud SaaS / CLM as a Managed Service offerings, we recommend the following:

  1. In all cases we strongly recommend deploying new environments using WebSphere Liberty. If you currently use WebSphere Application Server, we recommend migrating to WebSphere Liberty when you next upgrade your CE/CLM servers
  2. If your enterprise has the ability to support RedHat Enterprise Linux, then we recommend using that. Some advanced capabilities require IBM IoT MessageSight, which requires at least one server running RedHat Enterprise Linux x86-64
  3. If your organization has the ability to support IBM DB2, then we recommend using it for new environments

Please Note: The above guidance is not meant to steer you away from deployments on z or POWER systems or signal a lessening of our commitment to these environments.

Key topology variants

The CE/CLM applications and Jazz Team Server can be installed on shared application servers, or distributed across multiple application servers for improved scalability. Although this flexibility allows you to design a topology to best fit your needs, that flexibility also adds complexity to the planning process. As a result, it is important to plan your deployment topology carefully as changing your topology later can be very complex and require substantial application downtime. Potential deployment topologies are divided into three key topology variants: Department, Enterprise and Federated.

With CE/CLM 6.x we have decided to retire the Evaluation Topology. With the additional capabilities recently added it is no longer practical to deploy all the applications, supporting capabilities, such as reporting, and the database on a single server. The different workloads of user interactive applications, automated reporting data processing and database workloads do not work well together on a single server. With the vast majority of our customers deploying the CE/CLM environments on virtual servers, it makes much more sense to use a Departmental Topology with minimum resources. The Proof of Concept Sizing when using Application Lifecycle Management capabilities in 6.x wiki page provides specific guidance on deploying a proof of concept or evaluation environment.

There is also specific guidance on how to evolve your topology between a Departmental to a partial or full Enterprise Topology.

Departmental topologies

The Departmental topology is the minimum topology we recommend for any production environment. Use a stable, company-approved hostname and register it with the domain name server (DNS) to keep the URLs of the data stable. In this type of installation, databases are installed on a dedicated database server, and one or more other applications are installed on an application server. The DCC and LQE applications must be installed on separate application servers. A key advantage of the departmental topologies is that they require less hardware and are easier to deploy initially. These topologies are best for smaller projects and smaller-sized teams. Due to the resource constraints of the departmental topology, it is also recommended that the DCC collection jobs are only run once daily, during "off hours". Crucially, if you are fairly certain that your deployment will likely expand, you should consider starting with a Modified Departmental pattern. The following diagram is a generic example of a departmental topology for the CE/CLM v6.x solution. Note that the VVC application is only present in release 6.0 and has been incorporated in other applications in later releases. Additionally, Rhapsody Model Manager, first available in version 6.0.5, is now the recommended architecture management tool.

A Modified Departmental pattern would be a combination of application servers that serve single applications with other servers hosting multiple applications. This can be used initially or as an interim step towards full Enterprise deployment based on application usage and resource availability.

Please refer to the Alternative CE/CLM Topologies, version 6.0.0 to 6.0.4 wiki page for further details.

  • Generic Departmental Topology for CE/CLM 6.x:
    Departmental.png

Please see the Modified Departmental pattern for further guidance on how to scale your Departmental topology as you grow, such as active use of Global Configuration Management or higher usage of a single application.

Enterprise topologies

Enterprise topologies are useful for production or medium-sized to large-sized teams and multiple server (or distributed) deployments. Use a stable, company-approved host name and register it with the domain name server (DNS) to keep the URLs of the data stable. Enterprise topologies distribute the CE/CLM applications, Jazz Team Server, the database software, etc, and are more flexible. These topologies enable you to incrementally adopt applications into your deployment and configure them to use the same Jazz Team Server. In this type of installation, databases are installed on a single database server and each application is usually installed on its own dedicated application server. In addition, to connect multiple application instances to a shared Jazz Team Server, the instances must all be authenticated from the same authentication realm and thus share the same set of users. The following diagram is a generic example of an enterprise topology for the CE/CLM v6.x solution. Note that the VVC application is only present in release 6.0 and has been incorporated in other applications in later releases. Additionally, Rhapsody Model Manager, first available in version 6.0.5, is now the recommended architecture management tool. If Rhapsody Design Manager continues to be used, it should be deployed on its own server.

  • Generic Enterprise Topology for CE/CLM 6.x:
    Enterprise.png

Please Note:

  • All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilised applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.

Federated topologies

Federated topologies are useful to very large enterprises who tend to deploy an ELM solution per product line or organizational division but would still like to be able to pull together an enterprise-wide view of their current status and report on a rolled-up view of their entire portfolio of software or product set. Often versions of products or subsystems in one division are used as a part of a larger solution. By coordinating the planning and monitoring the status across divisional boundaries, the customer can manage these larger and more complex solutions. The following diagram is a generic example of a federated topology for the CE/CLM v6.x solution. Note that the VVC application is only present in release 6.0 and has been incorporated in other applications in later releases. Additionally, Rhapsody Model Manager, first available in version 6.0.5, is now the recommended architecture management tool. If Rhapsody Design Manager continues to be used, it should be deployed on its own server.

  • Generic Federated Topology for CE/CLM 6.x:
    Federated.png

Please Note:

  • Federated GCMs is only supported from ELM 6.0.6.
  • This topology contains multiple data warehouses. Use the instructions from How to upgrade data warehouse for Generic Modified Federated Topology document to upgrade data warehouse.
  • Busines Unit 1 represents a larger business unit whereas Business Unit 2 a smaller business unit or a business unit just starting its adoption of CE/CLM. Business Unit 1 can be easily scaled to the pattern of Business Unit 1 or incrementally through the Modified Departmental pattern.
  • All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilised applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.
  • Since CE/CLM 6.0.6.1 you can separate the LDX Server onto its own server, see Installing Link Index Provider (LDX) on its own Server.

Modified federated topologies

The modified federated topology is similar in intent to the federated topology but is implemented with a single ELM instance. The grey dotted boxes in the below diagram are only logical groups of servers, all within the same ELM instance.

  • Generic Modified Federated Topology for CE/CLM 6.x:
    ModifiedFederated.png

Please Note:

  • Federated GCMs is only supported from ELM 6.0.6.
  • This topology contains multiple data warehouses. Use the instructions from How to upgrade data warehouse for Generic Modified Federated Topology document to upgrade data warehouse.
  • Busines Unit 1 represents a larger business unit whereas Business Unit 2 a smaller business unit or a business unit just starting its adoption of CE/CLM. Business Unit 1 can be easily scaled to the pattern of Business Unit 1 or incrementally through the Modified Departmental pattern.
  • All the databases in this topology are shown hosted by a single logical Database Server. However, for medium to large deployments we recommend multiple database servers or database clustering using Db2 or Oracle. Typically the Data Warehouse (DCC) and most utilised applications (typically RM or CCM) are first to be separated onto their own Database Servers, see Multiple Database Servers.
  • Since CE/CLM 6.0.6.1 you can separate the LDX Server onto its own server, see Installing Link Index Provider (LDX) on its own Server.

Metadata variables

The following variables describe the key characteristics that provide variation in the typical ELM deployment topologies. These, along with the previously mentioned key topology variants are used to distinguish the standard topologies.

  1. Operating system (Windows, AIX, Linux, z/OS, etc.)
  2. Database management system (DB2, Oracle, SQL Server)
  3. Application server (WebSphere Application Server, WebSphere Liberty)
  4. License management systems (Evaluation, Floating, Token)
  5. User management system (Apache Tomcat, Active Directory, Tivoli Directory Server)
  6. Other technologies such as proxy servers, virtual host names, WAN accelerators

Although integrations are an important dimension, they are not addressed in this article or included in the recommended or alternative deployment topologies. Additionally, specific hardware architectures and virtualization technologies are not included among these variables. Hardware architecture and virtualization technologies are very important considerations when defining a deployment architecture, however, mostly due to their implications for performance and sizing. Recommended hardware architectures against these standard topologies will be discussed in follow-on articles.

Recommended and alternate topologies

Please Note: Going forward from CE/CLM 6.0.5 we are not going to publish Recommended and Alternative Topologies but rather provide more guidance in the strengthening our recommended deployment guidance section above.

Versions 6.0.0 to 6.0.4

Versions 5.x

Versions 3.x, 4.x

Datasheets and sizing guidelines

Find CE/CLM-specific performance datasheets, sizing guidelines and performance-related case studies on the Performance datasheets and sizing guidelines page.

Related topics:

Additional contributors: JoePesot, KrzysztofKazmierczyk

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r66 | r51 < r50 < r49 < r48 | More topic actions...
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.