Standard Collaborative Lifecycle Management Topologies
Please be aware:The content of this article has been migrated to the Deployment wiki: Standard topologies overview topic page. The content will be maintained and updated in the wiki going forward. Therefore, this version of the article might not contain the most up to date information.All deployment guidance and best practice will be published in the Deployment wiki rather than as Jazz.net articles going forward.
Overview
Many of our customers implement Collaborative Lifecycle Management (CLM) solutions to provide a complete tool infrastructure for their software or systems development organizations. One of the most frequently asked questions is how should they deploy the full CLM solution so that it will perform well, run robustly, and evolve without restriction. Customers have asked us 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 CLM product evolution so they can easily and quickly reap the benefits of the new technology.
The CLM system requirements permit a wide range of supported middleware platforms and topologies upon which to host the solution. The CLM products run on several commercial databases and two of the most popular web application servers. It is also possible and recommended to introduce reverse proxy servers in front of either a centralized or a distributed set of web application servers.
In order to simplify the wide range of choices, this article outlines several standard topologies which are the expected and most frequently chosen deployment patterns that we have seen over the past several years. Keeping in mind the continual evolution of the CLM solution, these topologies can be used with the CLM 2011 product versions. Additionally, these standard topologies contain the direction for future support of high-availability clustered configurations.
By publishing these standard topologies, we seek to represent tried and true examples of how customers have successfully deployed the CLM solution. Additionally, our 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, customers will have an easier time characterizing their deployment in the event of an interaction with IBM product support. These topologies become a “short hand” that can be used whenever a CLM deployment is discussed. For example, when we discuss the system performance testing results or we write about a high availability configuration, we can now reference the appropriate standard topology.
Several different teams came together to define and document these standard topologies. We are the teams which design and execute system, performance and reliability testing, the teams which develop and support the CLM products, and the teams which work directly with customers to design and implement CLM solutions at customer locations worldwide.
Key Dimensions
The CLM applications and the Jazz Team Server (JTS) 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. We’ve divided the potential deployment topologies into three basic dimensions: Evaluation, Department, and Enterprise.
Evaluation Topologies
An evaluation topology is useful for demonstration or training deployments only. In this type of installation, all the application and database software is installed on the same server. It is not recommended that you start with this topology and then attempt to expand it into a Departmental or Enterprise topology. If you have any intent to create production level artifacts, you should consider either a Departmental or Enterprise topology.
Departmental Topologies
Departmental topologies are useful for small team and single-server 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. 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. 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. Crucially, if you are fairly certain that your deployment will likely expand, you should consider starting with an Enterprise topology.
Enterprise Topologies
Enterprise topologies are useful for production or medium- 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 CLM applications Jazz Team Server (JTS), 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 JTS. 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 JTS, the instances must all be authenticated from the same authentication realm and thus share the same set of users.
Metadata Variables
The following variables describe the key characteristics which provide variation in the typical CLM deployment. These along with the previously mentioned key dimensions are used to distinguish the standard topologies.
- Operating system (Windows, AIX, Linux, z/OS, etc.)
- Database management system (DB2, Oracle, SQL Server, Derby)
- Application Server (Tomcat, Websphere Application Server (WAS))
- License management systems (Evaluation, Floating, Token)
- User management system (Tomcat, Active Directory, Tivoli Directory Server, etc.)
- Other technologies such as proxy servers, virtual host names, WAN accelerators
Though integrations are an important dimension, they are not addressed in this article or included in the referenced topologies. Additionally, you should note that specific hardware architectures and/or virtualization technologies are not included among these variables. Hardware architecture and virtualization technologies are very important considerations when defining a deployment architecture, however, more from a performance and sizing perspective. Recommended hardware architectures against these standard topologies will be discussed in a follow-on article.
Catalog of Topologies
Based on several sources of input from experiences with customer environments, using the previously mentioned key dimensions and metadata variables, the following standard topologies were identified. These expand on the installation topologies referenced in the CLM 3.0.1 InfoCenter.
- Evaluation (V)
- Departmental (D)
- Enterprise (E)
In the following catalog, each topology will be briefly described and depicted. The metadata variables defining each will be noted.
Evaluation
(V1) Evaluation – Single server / Tomcat / Derby
This is a simple, single server topology whose primary use is supporting evaluations, demonstrations, proofs of concept and training. Given the use of Derby and Tomcat, it can be stood up very quickly, especially with the upcoming express install feature.
Metadata Variable | Value |
|---|---|
| Operating System | Windows |
| Database Management System | Derby |
| Application Server | Tomcat |
| License Management System | Trial |
| User Management System | Tomcat |
| Other technologies | None |
Departmental
(D1) Departmental – Single application server, Windows / DB2
This departmental topology uses Windows for the server operating systems. The CLM applications and JTS are deployed to a single WAS instance. Virtual host names are used to ensure public URI stability. DB2 is used for the databases and is hosted on a separate server. Rational Reporting for Development Intelligence (RRDI) is included in this department configuration but is hosted on a separate server and WAS instance for performance reasons. Finally, licenses are served by a floating license server and Active Directory provides the Lightweight Directory Access Protocol (LDAP) based user management.
Metadata Variable | Value |
|---|---|
| Operating System | Windows |
| Database Management System | DB2 |
| Application Server | WAS |
| License Management System | Floating |
| User Management System | Active Directory |
| Other technologies | Virtual host names |
Enterprise
(E1) Enterprise – Distributed / Linux / DB2
This enterprise topology uses Linux for the server operating systems. The CLM applications, RRDI and JTS are distributed across separate servers and WAS instances. A reverse proxy is used to ensure public URI stability. DB2 is used for the databases and is hosted on a separate server. Finally, licenses are served by a floating license server and Tivoli Directory Server provides the LDAP based user management.
Metadata Variable | Value |
|---|---|
| Operating System | Linux |
| Database Management System | DB2 |
| Application Server | WAS |
| License Management System | Floating |
| User Management System | Tivoli Directory Server |
| Other technologies | Reverse Proxy |
(E2) Enterprise – Distributed / all Microsoft
This enterprise topology uses Windows for the server operating systems. The CLM applications, RRDI and JTS are distributed across separate servers and WAS instances. A reverse proxy is used to ensure public URI stability. SQL Server is used for the databases and is hosted on a separate server. Finally, licenses are served by a floating license server and Active Directory provides the LDAP based user management.
Metadata Variable | Value |
|---|---|
| Operating System | Windows |
| Database Management System | SQL Server |
| Application Server | WAS |
| License Management System | Floating |
| User Management System | Active Directory |
| Other technologies | Reverse Proxy |
(E3) Enterprise – Clustered / Linux / Oracle
This enterprise topology uses Linux for the server operating systems. The CLM applications and JTS are each deployed to a cluster of WAS nodes. Though clusterable, RRDI is hosted on a separate server pending completion of reliability and performance tests. A load balancer fronts multiple reverse proxy server (used to ensure public URI stability) and balances the inbound requests between them. Oracle is used for the databases and is hosted on a separate server. Finally, licenses are served by a token license server and Tivoli Directory Server provides the LDAP based user management.
Metadata Variable | Value |
|---|---|
| Operating System | Linux |
| Database Management System | Oracle |
| Application Server | WAS |
| License Management System | Token |
| User Management System | Tivoli Directory Server |
| Other technologies | Load Balancer, Reverse Proxy |
(E4) Enterprise – Clustered / AIX / all IBM
This enterprise topology uses AIX for the server operating systems. The CLM applications and JTS are each deployed to a cluster of WAS nodes each in a separate LPAR. Though clusterable, RRDI is hosted on a separate server pending completion of reliability and performance tests. A load balancer fronts multiple reverse proxy server (used to ensure public URI stability) and balances the inbound requests between them. DB2 is used for the databases and is hosted on a separate server. The server-side converter.war, needed to view graphical artifacts in RRC, is deployed on a Linux server. Finally, licenses are served by a token license server and the AIX LDAP server provides the user management.
Metadata Variable | Value |
|---|---|
| Operating System | AIX |
| Database Management System | DB2 |
| Application Server | WAS |
| License Management System | Token |
| User Management System | AIX LDAP server |
| Other technologies | Load Balancer, Reverse Proxy |
(E5) Enterprise – zOS / Linux on System z / DB2
This enterprise topology uses Linux on System z for the operating system on the CLM server. The CLM applications, RRDI and JTS run in separate profiles on a single WAS instance. A reverse proxy is used to ensure public URI stability. DB2 is used for the databases and is hosted on a separate z/OS LPAR. Finally, licenses are served by a floating license server and Tivoli Directory Server provides the LDAP based user management . Each of these run on a Linux server. Metadata Variable | Value |
|---|---|
| Operating System | Linux on System z |
| Database Management System | DB2 |
| Application Server | WAS |
| License Management System | Token |
| User Management System | Tivoli Directory Server |
| Other technologies | Reverse Proxy |
(E6) Enterprise – zOS / DB2
This enterprise topology uses z/OS for the operating system on the CLM. The CLM applications and JTS run in separate profiles on a single WAS instance. RRDI does not run on z/OS so is deployed on WAS hosted on a Linux server. A reverse proxy is used to ensure public URI stability. DB2 is used for the databases and is hosted on a separate LPAR. Finally, licenses are served by a floating license server running on Linux and Resource Access Control Facility (RACF) provides the user management. Metadata Variable | Value |
|---|---|
| Operating System | z/OS |
| Database Management System | DB2 |
| Application Server | WAS |
| License Management System | Token |
| User Management System | RACF |
| Other technologies | Reverse Proxy |
Applying the Topologies
Every customer’s environment is different with unique, necessary and often immutable characteristics. We recognize that these standard topologies may not provide enough detail to make them immediately implementable in some customer environments, but we wanted to describe several topologies with enough variability to give an indication of what is possible and where our recommendations start.
One of the CLM solution’s strengths is that it can be deployed in an infinite variety of ways to meet each individual customers’ needs. We support the leading database management systems so that you can choose the one which makes the most sense for your organization, just as we support multiple operating systems (see the CLM System Requirements for details). While we recommend customers start with a standard topology that is most applicable to them, we recognize they will need to make changes and customizations to support their own unique needs and requirements. IBM will support your own implementations, but may ask you to describe which topology is most applicable to your deployment and ask you to document what is unique in your environment to expedite any potential support situation.
To aid you in documenting your chosen deployment topology, we have made the Rational Software Architect (RSA) model files available for download. These may be imported into RSA then further modified or expanded to represent your environment. Look for the Installation_Instructions.txt file for information on how to import the models into RSA.
Next Steps
This article is meant to briefly introduce these standard topologies and describe how they might be applied. Work is already underway to build upon and apply them. Subsequent articles will provide additional insight into their usage.
Future updates to this article or additional articles may cover such topics as:
- Deeper look at select topologies
- Publish performance and reliability test results using select topologies
- Provide sizing and hardware recommendations based on test results
- Discuss virtualization pros and cons
- Provide suggested tuning parameters
- Include Rational Design Manager
- Include RRDI in the clustered nodes of all the enterprise topologies
- Include Windows clustered configuration when supported
- Consider high availability database topologies
- Begin to expand this topology model into other domains
- Discussion of strategic integrations with other Rational and non-Rational products
Copyright © 2012 IBM Corporation