www.serena.com
SERENA DIMENSIONS CM: SCALING FOR THE ENTERPRISE February 2009 Executive Summary Serena Dimensions is the industry’s leading end to end, process‐centric Application Lifecycle Management solution for distributed development. It integrates application development across global sites, stakeholders and platforms, and automates development steps based on consistent processes to streamline delivery of the applications that drive the business. Dimensions is comprised of a suite of components that can be deployed separately or in a single integrated fashion. Dimensions CM is at the core of Dimensions, the industry’s leading software change and configuration management solution. Dimensions CM seamlessly orchestrates application change and configuration across platforms, locations, and teams. Dimensions CM delivers: • End‐to‐end traceability, from the inception of a project or issue through delivery of the functionality • Streamlined regulatory compliance though development lifecycle process definition and enforcement • Enhanced team productivity with an infrastructure that supports collaboration between co‐
located or geographically distributed stakeholders • Visibility and control over project status, progress, and prioritization This document describes the high‐level architecture of Dimensions CM highlighting the major components of the system and how to deploy them in an enterprise environment to ensure your Dimensions solution scales and performs well. 2
www.serena.com
Architecture The following diagram gives a general overview of the tiers in the Dimensions CM architecture and which components reside in each tier and how they connect: As you can see Dimensions CM has an n‐tier cross‐platform architecture consisting of the following layers: •
Presentation tier •
Business logic tier •
Database/Metadata tier 3
www.serena.com
•
File/Storage tier The components in each of these tiers can be installed all on a single system or onto separate physical machines. Because the components can be scaled horizontally (spread across a number of machines) to expand capacity, Dimensions CM can grow to meet the needs of your enterprise. Presentation Tier The presentation tier consists of the clients that end‐users will make use of to access the functionality of Dimensions CM. There are a number of different clients to allow support for different platforms and access methods. Below is a detailed diagram of this tier. •
Desktop Client The Desktop Client provides a rich Windows user interface built using the Microsoft Foundation Class (MFC) library and other native Windows user interface technologies. This is a fully‐featured client providing access to all the end‐user functionality of Dimensions CM. This client uses TCP/IP to communicate over the network to the business logic tier. The Project Merge Tool and Synchronize Wizard are also Windows Desktop Clients built using similar technologies. •
Command Line (CLI) The Command Line Interface (dmcli) is a small native component that can run on Unix and Windows platforms and allows power users access to a flexible command line for the full Dimensions CM functionality. This client also uses TCP/IP to communicate to the business logic tier. •
Eclipse IDE Integration Dimensions CM has a rich Eclipse plug‐in that integrates the request and version management functionality of Dimensions directly into the developers Eclipse workspace environment. This client has been developed as an Eclipse Plug‐in (see http://www.eclipse.org/articles/Article‐Plug‐in‐
architecture/plugin_architecture.html for details). The plug‐in uses TCP/IP to communicate to the business logic tier. •
Microsoft Visual Studio Integration Similar to the Eclipse plug‐in the Dimensions CM Visual Studio Integration allows access to request and version management functionality from within the IDE. There are two pieces to this integration, the version control aspects of the integration are implemented using a Microsoft Source Code Control Interface (SCC) plug‐in while the request management features are provided by a separately installed 4
www.serena.com
plugin implemented using the Visual Studio Integration Program (VSIP) SDK. This integration communicates to the business logic tier of Dimensions CM using TCP/IP. •
Administration Console The Administration Console provides a web‐based front‐end for performing tool administration and configuration activities. See below for more detail on implementation technologies. •
Web Client The Web Client provides a web‐based interface to the end‐user features of Dimensions CM. Both this client and the Administration Console use the standard HTTP (or HTTPS) protocol to communicate to a Web Application Container (aka servlet container) in the business logic tier. The use of browser‐based HTTP communication enables deployment of these clients across a wide variety of platforms and network topologies. Some use of a signed applet is made on the client side to present UI elements and interact with the file system. Also optionally the user can choose to download some native code that allows file compare/merge operations. •
Other clients In addition to those mentioned above there are many other clients for Dimensions CM including integrations with other IDEs and 3rd party products, the Dimensions z/OS clients. All of these clients either use HTTP/HTTPS or use TCP/IP to communicate with the business logic tier in a similar way to the clients listed above. Business Logic Tier Components within the business logic tier are server components responsible for carrying out Dimensions operations on behalf of the clients (e.g. authenticating users, checking privileges/authorization, enforcing process rules, maintaining metadata about products, projects, baselines, requests, and items under control). These server components are supported on a wide variety of platforms including Windows, Linux and a number of Unix platforms. See our web site or the Readme file for a list of the latest supported platforms. Below is a detailed diagram of this tier. •
5
Dimensions CM Server www.serena.com
The Dimensions CM Server component is where the main business logic of Dimensions is performed. This component is implemented using a proprietary C/C++ application management framework that provides high scalability and performance and has been proven in many enterprise environments over the years. There is a “listener” component (dmlsnr.exe) that simply monitors the health of the Dimensions server and re‐starts the server processes in the event of a failure giving the system maximum availability. The “listener” starts a “pool manager” process (dmpool.exe) whose main job is to manage a pool of “application servers”. When a user is actively using a Dimensions CM client they are allocated a process from the pool, when they become idle the process returns for the pool to become available for other users. The initial, minimum and maximum size of the pool can be configured as can the period of time that a client must be inactive for their application server to return to the pool. This pooling architecture allows high scalability as many users can be connected to Dimensions but only the active ones are taking up precious system resources. The “application server” process (dmappsrv.exe) is where the main business logic for Dimensions is performed; these processes connect to the database to perform metadata queries/updates and communicate with the client. It is these processes that are “pooled”. When a user wants to retrieve file content for an item revision it is also the job of the “application server” to communicate via TCP/IP to the file/storage tier to retrieve the content from the file system. On Unix platforms the “pool manager” process must be run as the privileged user account “root” so that it can authenticate users credentials (access passwords and shadow password files) and run processes as the client user (to access the file system on behalf of that user). For similar reasons on Windows platforms the “pool manager” must be run as the Windows System account or an account with similar access rights. •
Web Application Container The Web Application Container is a J2EE servlet container (such as Apache Tomcat); this component deals with requests from the Administration Console, Web Client and Web Services clients. The Administration Console and Web Client are built using Java, HTML and JavaScript, JSP (Java Server Pages) technologies and their implementation follows a model 2 MVC (Model‐View ‐Controller) pattern to separate presentation, logic and content. Most of the product’s business logic is implemented by the Dimensions CM Server; the servlet code does not itself access the database directly, it communicates over TCP/IP to the Dimensions CM Server to perform operations, query data, store/retrieve file content etc. When the product is installed it is deployed and configured to run under Apache Tomcat but it can also run under other supported Web Application Containers (see product release notes for details) and the roles of the web server and servlet container can be separated, e.g. Microsoft IIS (Internet Information Services) could be used as the web server and Tomcat for the servlet container. By default the web applications are hosted by Tomcat on TCP/IP port number 8080 but again this is configurable. •
Serena License Manager The license manager is basically an extension of the Macrovision FlexLM licensing product; it supports both concurrent and named user licensing models. In addition to the license server Serena also provides a Java Swing based GUI to perform license administration activities. When a connection is made from a client to the Dimensions CM Server the “pool manager” process calls the license manager to obtain a license for the client. When the user exists his client or a session timeout (configurable in length) occurs the license is returned. Communication between the license manager and Dimensions server is via TCP/IP using Macrovisions own APIs and protocols. Database/Metadata Tier Dimensions is a highly configurable tool with a rich set of relationships and properties of the assets being managed, so to enable high performance and scalability Dimensions CM uses relational database technology to store and query this metadata. 6
www.serena.com
Below is a diagram of this tier. As you can see, to support enterprises that have already made an investment in database technology Dimensions supports multiple industry leading databases. For a list of the latest supported databases, check our web site or the Readme file for the version you are evaluating. Depending on your choice of database the Dimensions Application Server will use different network protocols and APIs to access the database. For Oracle Dimensions uses the Oracle Call Interface API (OCI), for DB2 the DB2 CLI (Call Level Interface) is used and for SQL Server Dimensions will use Open Database Connectivity (ODBC) APIs. A single Dimensions server can connect to multiple database instances, within an instance there can be a number of Dimensions CM base databases (for example perhaps one base database is used for your production work and another one for testing), each of these has their own schema and there is also a single common schema (referred to as PCMS_SYS) that stores some common metadata. Tools are provided to carry out routine database maintenance and monitoring and documentation is provided covering backup and recovery of the database. File/Storage Tier In addition to managing the metadata about assets under control Dimensions CM also needs to securely manage the content of the assets themselves (versions of your source code, documents etc). These file storage/retrieval tasks are carried our by this tier in the architecture. Below is a detailed diagram of this tier. The only component in this tier is the Dimensions CM Agent, this is a group of components that interact with the file system either to store/retrieve content in the item library (repository of versioned assets) or manage content in a remote area (deployment area, work area). 7
www.serena.com
The agent is similar in its architecture to the Dimensions CM Server in that there is a “listener” process which ensures the server is healthy, a “pool manager” process to authenticate the user and allocate “library server” processes. The “library server” process is the one that actually accesses the file system and communicates back to the Dimensions CM Server or client via TCP/IP. There are three primary uses for Dimensions Agent technology: 1.
To host a Dimensions Item Library When assets are checked‐into Dimensions their content needs to be stored in a secure location (called an Item Library). The machine hosting the item library must have a Dimensions CM server or agent installed on it to interact with the file system to store the assets. Different item types can be placed in different item library locations; these might be separate directories on disk but on the same machine or you could even have separate physical machines hosting item libraries for different item types. By default when an item library is accessed the “library server” process runs as SYSTEM on Windows and root on Unix but this is configurable. There are three options for storing the content of the files in the item library: •
Content can be stored in flat files e.g. one file on disk for every revision of an item held in Dimensions CM. This type of item library is referred to as a “normal” item library. •
Content can be stored using delta storage where you get one file on disk per item and that one file contains all revisions of the item (with only the differences between each revision being stored). If disk space is a limiting factor for your Dimensions configuration then the use of deltas would be helpful but otherwise we would recommend using flat files for storage (as described above). •
Content can be stored in a compressed form. The content is stored in flat files e.g. one file on disk for every revision of an item held in Dimensions CM but each of these files is compressed. This type of item library is referred to as a “normal compressed” item library. Obviously if compression is used there is some CPU overhead in uncompressing the data each time it is accessed. 2.
To host a remote work/deployment area For example a Dimensions user might be running Desktop Client on Windows but he actually does mainframe software development so wants his assets checked‐out and back‐in to partitioned datasets (PDS) on the mainframe MVS file system (rather than his local hard disk). In this situation the customer would need a Dimensions CM Agent installed on the mainframe to interact with the mainframe system. When a remote work area is accessed the “pool manager” on the CM agent node attempts to login using the credentials you used to login to the Dimensions Server. If this fails it will prompt the end‐user for credentials to access that work area. Once a user has entered their credentials for a particular area they are not prompted again unless they logout of their client or their session expires. When a deployment area is accessed if the Dimensions CM administrator chose to store credentials for that area then those credentials are used but if they were not stored then the user is prompted (just like for work areas above). 3.
To host an item library cache To enhance performance across slow networks (for example across a high latency Wide Area Network) Dimensions provides a unique caching feature (called an item library cache) that stores asset content at a location nearer the user who needs that content. So instead of going over the WAN to obtain the content it can instead be obtained directly from a cache on the same LAN as the user. For example consider the scenario where a company has a data center somewhere in North America but has some outsourced development occurring in India. The developers in India are using Dimensions CM clients to connect over a high bandwidth high latency wide area network to the Dimensions CM server in the data center. Without an item library cache when a client in India retrieves the content of a project the file content will be sent over the low‐speed WAN, despite Dimensions network optimizations such as 8
www.serena.com
compression and only sending files that have changed if the project contains some large files or a very high number of files then the fetch of the files will be slowed down by the network speed. But imagine the developers in India install a Dimensions CM Agent on a host on the LAN in India and configure an item library cache on that machine as shown in the diagram below: Overnight they can schedule a job to populate the cache (download all their important/frequently accessed project content). In the morning when developers start work if they have setup Dimensions to make use of their locale cache then when they get project content it will not come over the WAN but instead come from the local item library cache which is on their LAN so will be faster than obtaining the content from the server. When the developers in India create new file versions those must be transferred over the WAN to the main item library (in North America). When those new versions are fetched to India the cache is also updated so future fetches are optimized, in this way the cache grows as development is performed. If any developers in North America access file content they would not have chosen the India library cache so content would come directly across their LAN from the main Dimensions CM Agent hosting the item library. Utilities are provided to purge or completely clean the item library cache to optimize the usage of disk space on the cache machine. The Dimensions CM Agent is used to manage the storage for an item library cache. When an item library cache is defined in the Dimensions CM Administration console credentials are associated with that cache area so when the “pool manager” needs to start a “library server” to access a cache area it runs using those credentials. Platform Support Dimensions CM has broad platform support allowing the use of Windows, Linux, many flavors of Unix and z/OS for the IBM Mainframe. See the Dimensions CM Readme document for further details on supported platforms. 9
www.serena.com
Application Programming Interfaces (APIs) Dimensions CM offers a number of publicly available supported APIs (Application Programming Interfaces) allowing customers to create their own applications that make use of Dimensions functionality or to extend the functionality of Dimensions CM. •
C/C++ API A set of documented C functions and structures are provided along with examples and makefiles to allow users to write C/C++ applications that can query Dimensions CM metadata and perform Dimensions CM operations. This API is a cross‐platform (supported on Windows, Linux and many flavors of Unix) client API and uses TCP/IP to communicate to the Dimensions CM Server. •
Java API The Java API (referred to as dmclient) is a fully featured object‐orientated API for accessing Dimensions CM functionality. It comes with complete JavaDoc documentation, examples and is documented in the Developer’s Reference guide. This API is cross‐platform and uses TCP/IP to communicate to the Dimensions CM Server. •
Web Services A set of SOAP Web Services are provided with Dimensions CM to perform common Request management operations. The Document Literal Wrapped style of WSDL declaration is used and the WSDL is WS‐I Basic 1.0 compliant. In the diagram below a web service client is using some kind of SOAP Client API to send the SOAP request over HTTP to the Web Application Container. This could be any SOAP 1.1 compliant client. In the business logic tier the Dimensions Web Servcies are implemented using Apache AXIS so the AXIS servlet receives the request and calls into the Dimensions CM web services code. The web services call the Dimensions CM server using TCP/IP in the same way as the other Dimensions CM web applications. •
10
Published Views www.serena.com
In addition to using programmatic interfaces to access Dimensions CM metadata you can also use standard SQL to access the database via a set of read‐only published views. This allows customers to write their own reports using Dimensions metadata or to perform complex queries perhaps as part of an API program. Network Protocols In the description of the tiers and components above it was noted that most of the components communicate using TCP/IP, the messages sent over these connections are RPC (Remote Procedure Call) style messages, the caller requests a particular function and sends a number of input parameters, then the other end responds with some output parameters. We call this SDP (the Standard Dimensions Protocol). The Dimensions CM Server and Agent components listen on TCP/IP port number 671 by default but this is configurable. The TCP/IP connection is initiated from the client to the server so if you are configuring a firewall on your network you will have to allow incoming connections on that port to the Dimensions server and if needed also from the server to your Dimensions CM Agents. When an RPC request or response is large it is automatically compressed by Dimensions to provide efficient low‐bandwidth delivery of data. When transferring files the file content is automatically compressed, and the level of compression can be configured from the Administration Console. When transferring many files (for example downloading the contents of a project) Dimensions CM will read the file content from the file/storage tier into an in‐memory buffer (configurable in size) in the server compressing the data as it goes and then it delivers the compressed data buffer to the client. Also note that files are only transferred if they have not changed since the client last obtained that file, this optimization along with the compression ensures Dimensions CM performs exceptionally, even when over a slow Wide Area Network. Security When communicating between tiers (across the network) Dimensions employs various strong encryption technologies to ensure sensitive data is transmitted securely. •
SSDP SSDP is the Secure Standard Dimensions Protocol and is identical to that described in the (Network Protocols section above) but all data sent over the wire is SSL encrypted. If your Dimensions network traffic travels over a public network link we would strongly recommend you configure Dimensions to use SSDP. Encryption is provided using TLS version 3.1 using the following cipher suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA The encryption is performed using the OpenSSL API (http://www.openssl.org). Diffie‐Hellman key agreement using ephemeral keying (key exchange via a temporary key) is employed to encrypt the traffic using a customer provided certificate, we recommend a 1024 bit key but this is configurable by your Dimensions Administrator. •
Encryption of passwords 11
During authentication the client needs to send the password of the user to the Dimensions CM server, even when you are not using SSDP or other encryption the password will still be encrypted. The sensitive data is encrypted using a 64bit key based on the current system time and a hard‐coded 1024bit seed generated by a PRNG (PseudoRandom Number Generator). This protects your sensitive data from being easily discovered using a network packet sniffer, if further security is needed we recommend enabling the SSDP protocol to SSL encrypt all traffic. •
HTTPS www.serena.com
The Web Client and Administration console can be used over the industry standard HTTPS protocol to encrypt all communication between the browser and the Web Application Container using SSL/TLS. •
LDAPS When using LDAP to authenticate user credentials Dimensions CM can support both LDAPS (LDAP over a SSL tunnel) and LDAP with StartTLS extensions. Both of these security mechanisms encrypt the LDAP communication using strong SSL/TLS encryption. Not all LDAP servers support both secure protocols so choose the relevant one for your particular server. •
Encryption of stored passwords Passwords for a few key Dimensions user accounts must be stored on the Dimensions CM Server on the file system (in a file located in dfs/registry.dat under your Dimensions CM Server installation root folder). To ensure these are secure on Unix they are owned and only readable by root on Windows you can secure these files after installation of Dimensions CM. In addition to file permissions this information is also protected by encryption technology. The user names and passwords stored in this file are encrypted using a 64 bit Blowfish (symmetric block cipher) encryption algorithm. A utility called dmpasswd is provided to administer the accounts stored in this file. The three accounts that are stored in this way are: 1. Dimensions Pool Manager: The “application server” (dmappsrv.exe) processes running on the Dimensions Server are by default all owned by a single user account (referred to as the pool manager). The “pool manager” needs to know the password for this user to start these “application server” processes. 2. Database Schema: Each Dimensions base database is itself a database schema, the schema username and password need to be stored to allow Dimensions to connect to the schema. 3. LDAP bind user: If you have configured Dimensions CM to use LDAP and are using a specific user account for performing searches on the LDAP directory then their DN and password must be stored in this file. Also if the Dimensions administrator has entered user credentials for a deployment area in the Administration Console these will be stored using the same 64 bit Blowfish encryption scheme in the database. These are stored in the administrative schema (PCMS_SYS). Authentication When a user invokes a Dimensions CM client they must login before using the tool, a user name and password must be provided. The Dimensions CM Server needs to validate the user name and password are correct and it can be configured to do this using a number of different authentication systems. Native OS Authentication This is the default configuration for authentication and uses the servers native operating system authentication mechanisms to validate the users credentials. •
Unix On Unix we use the POSIX standard getpwnam, getspnam and crypt functions to encrypt the password provided by the client and compare it to the value stored in the systems password file. If the values match then the user is successfully authenticated. 12
www.serena.com
•
Windows On Windows platforms we first query user account information using the NetGetUserInfo function provided by the Microsoft Platform SDK. Which domain controller we query that information from depends on how the system has been configured. If a domain name was specified as part of the user name (e.g. mydomain\myuser) we query the domain controller for that domain and call NetGetUserInfo against that domain controller. If the Dimensions CM Server is configured to authenticate against a given domain name (using the DM_LOGON_DOMAIN parameter) then we lookup the domain controller for that specific domain and call NetGetUserInfo against that domain controller. Finally if no domain was specified in the user name and no domain name has been configured we query the primary domain controller for the Dimensions CM Server. Having obtained account information we verify if the user’s password has expired and if necessary allow them to change it. Once that is complete we call the Microsoft Win32 API function LogonUser passing it the default logon provider and a logon type of LOGON32_LOGON_NETWORK. If LogonUser succeeds then the user’s credentials have been validated successfully and they can access Dimensions CM. •
z/OS On a Dimensions z/OS agent machine the POSIX getpwnam and crypt functions are used just like on Unix. These system calls will then authenticate users against your chosen security system (RACF, TopSecret etc). Also note that on Unix you can run the command line client on the Dimensions CM Server (on the same physical machine) and it will not enforce the entry of a user/password pair, it can use the credentials of the already logged in user. LDAP The Dimensions CM Server can be configured to authenticate users using a LDAP (Lightweight Directory Access Protocol) server. Some examples of LDAP servers are Microsoft Active Directory Server, the Java Directory Server from Sun Microsystems and the OpenLDAP directory server. Enterprise customers often use these directory servers to centralize their user account information. Dimensions uses the OpenLDAP API to communicate between the “pool manager” and the LDAP server. As mentioned in the Security section above the Dimensions CM server can be configured to use secure/encrypted versions of the LDAP protocol. To authenticate using LDAP Dimensions CM needs to identify the DN (Distinguished Name) for the user and “bind” to the LDAP directory server using that name and the provided password. LDAP is a highly configurable directory server so Dimensions CM provides three ways of identifying the DN of user: 1. Search for a matching DN This is probably the most common way of authenticating using LDAP, with this setup the Dimensions CM Server searches the LDAP directory for a DN that has a particular attribute value then binds using that DN. You need to configure a “bind user” which is the DN of a user who has authority to search the directory and register their password using the dmpasswd utility. Dimensions CM will then “bind” initially as that user, perform a search (from a given point in the LDAP directory tree) to find a DN where a specific attribute has the value set to the name of the user logging into Dimensions and if a match is found Dimensions will “bind” using that DN. If binding is successful then the user is authenticated successfully and can access Dimensions CM. 13
www.serena.com
2.
Search anonymously for a matching DN If you do not configure a bind user but you do configure Dimensions CM to perform an LDAP search then the search will be performed anonymously. It will function as described above (searching for a matching DN and then binding to it) but you will need to have anonymous searches enabled on your LDAP server. 3. Construct a specific DN The final LDAP authentication option allows you to configure Dimensions CM to construct a specific DN instead of searching to find one. You need to configure the “base” of the DN and an attribute to use as the RDN (Relative Distinguished Name). Dimensions will form a DN by first specifying the RDN followed by the user’s name, followed by the “base”. Dimensions then tries to “bind” to that DN using the password provided when the user logged in. If binding is successful then the user is authenticated successfully and can access Dimensions CM. PAM On Solaris Dimensions CM also supports authentication using PAM (Pluggable Authentication Modules) allowing many common authentication systems to be supported. The Dimensions CM PAM implementation only support authentication modules that require user name and password only (e.g. the PAM LDAP module), modules that require more data to authenticate the user are not supported. When PAM authentication is configured the Dimensions “pool manager” component calls PAM APIs to authenticate the user, passing in the user name and password when required. PAM will call whatever authentication module has been configured for the Dimensions service (as configured in the /etc/pam.conf file). Dimensions CM uses a PAM service name of “dimensions_cm” by default but this is configurable. If the PAM conversation succeeds then the user is authenticated successfully and can access Dimensions CM. Authorization Each Dimensions operation is controlled by a privilege; these privileges have a set of rules which (if met) grant the user permission to carry out the operation. These privilege rules are very flexible allowing control over who can do what based on the state of the object being operated upon, the groups the user is a member of, the roles that the user holds etc. In addition to the privilege other process rules are also evaluated to see if the operation can be performed. For example you might have the “Relate Item to Request” privilege but you still cannot check‐out files against a change request if it is in the closed phase of its lifecycle. Roles are an important aspect of the Dimensions CM authorization mechanism, roles can be used in conjunction with privileges to control access to assets depending on which design part (functional area or logical component of the system) that the asset belongs to. For example a piece of source code could be owned by a design part called “GUI” and privileges could be configured so that only users who hold the “developer” role on that part would be allowed to edit that code. They might hold the “developer” role on a different part (e.g. Database) so they can edit “database” code but not GUI code. In this way you can break you product/application up into areas and define roles/responsibilities for those areas. See the Process Modeling User’s Guide for further details on how Dimensions privileges, users, design parts and roles function. Deployment There are a wide variety of configurations that are supported by Dimensions CM , especially when you factor in the number of platforms that are supported. The next set of diagrams shows Dimensions CM deployed in a few common configurations. 14
www.serena.com
•
•
•
Standalone Server Multiple Servers Distributed Environments They show how the architecture that as been descried can be deployed onto physical systems. The components are designed to be installed and configured easily. Once you have chosen to deploy your initial system, it is possible to change and expand as your needs grow. Standalone Server In this configuration the components from the lower three tiers of the Dimensions CM architecture (business logic, database and storage tiers) are all hosted on a single physical server machine. This may work well if you have a small user community or a powerful server machine. Multiple Servers In this configuration the database has been moved off onto a separate machine from the Dimensions CM server. This spreads the CPU and RAM needs of the server components across the two machines allowing for better performance and scalability. 15
www.serena.com
Distributed
Environments
The following configuration shows Dimensions CM usage spread across several geographically dispersed sites. Users connect using Dimensions CM clients from India and England to a central Dimensions CM server in the United States. In both India and England Dimensions CM Agents have been installed to act as item library caches for those locations allowing the users to keep content they frequently access close to them. Scalability As you have seen Serena Dimensions CM is architected to scale to a variety of Enterprise needs, but providing a scalable environment for enterprise applications is complex. Dimensions CM is supported on a variety of platforms and has many possible configurations. Many factors must be closely considered including network hardware and software, WAN integration, server hardware and software, network load, server load, and more. Prior to deploying Dimensions CM, these factors should be considered by your IT professionals and if needed with advice from Serena Software Professional Services. Your data and usage models will need to be considered as well when determining how to scale Dimensions CM to meet your needs. For example a heavy web user population may need more Web Server resources where as heavy Desktop or IDE client population may require additional CM servers. 16
www.serena.com
Vertical Scaling Scaling up involves applying higher powered hardware on the Dimensions CM server. This can involve faster CPUs, multiple CPUs, more memory, faster Network cards, or more likely, some combination of all of these. Although the information shared in this section applies to scaling up a system with the entire application installed on it, it is also applicable when choosing to scale horizontally and should be considered there as well. Processors Depending on the operations being performed, the Dimensions CM server and the database can be CPU intensive. When using multi‐processor or hyperthreading configurations, the server is able to use more system resources than under single processor configurations. In memory intensive situations, the server may even consume all available memory. Having two gigabytes of memory available per processor (virtual or physical) is a good general rule of thumb. Choosing a 64bit platform over a 32bit platform will allow you to scale further vertically. It will be able to address more memory and is capable of processing more per CPU cycle. Dimensions CM will take advantage of both faster and additional processors and improve the performance. Memory Memory is important to scaling Dimensions CM. There are several processes that run and require memory and making sure there is available memory when needed will allow you to scale further. Dimensions CM Server memory The CM Server can be scaled by adding memory. The processes of the CM server were described earlier. The “application server” process’s (dmappsrv.exe) can be controlled in the listener.dat configuration file (see User documentation for more details). Here you can control the number of active processes and how they startup. One of these processes is needed by each active/concurrent connection you plan to support. Starting more initially and leaving them running to service user connections will consume more memory, but will reduce the amount of CPU and other processing activity involved in starting the process when they are not readily available. For each active/concurrent user you plan to support, you can estimate using approximately 50MB for each. By adding more memory on the CM server, you will find the ability to support additional “application server” processes is increased and will allow your system to handle more user connections efficiently. File Storage Server memory The processes of the File Storage Tier were described earlier. The processes that perform the work for this layer are “library server” process’s (dmlibsrv.exe). Generally there will be one process for each active file transfer (ie: get, check in, check out,…). They are created for the duration of the operation and utilize approximately 20MB. Adding additional memory to the system will allow more of these processes to run enabling additional file transfer actives to take place. Web Application Container memory Our default installation installs a java based Web Application Container (Apache Tomcat). Adding more memory to the Application server can improve your ability to scale vertically and support additional web clients. The amount of memory that is used is controllable via configuration settings which can be located in our documentation. Since we do also support other Web Application Containers as well, you should consult their documentation for details on expanding memory if you are using one of those containers. 17
www.serena.com
Database server memory Making sure your database has ample memory is important for scaling your system. Simply adding more memory may not necessarily allow the database to properly utilize it in all cases. We recommend that you consult your database documentation for how to optimize the memory and configuration for the database you have chosen. But as a general rule, for each additional active/concurrent process approximately 20MB is consumed. You should consider the type of activities that your user population will be performing when sizing this area. For example if you expect many people to be constantly running reports, you will want to make sure there is enough memory to support those processes and the database is tuned properly to take advantage of it. Storage Areas The disk subsystem in a single system configuration can also be used to get additional scalability. Generally the faster the disks are, the faster your operations will be performed. If you have the ability to use multiple drives, doing things such as separating the database data and the database logs on to separate physical drives (or spindles) will allow the system to operate more efficiently. Having a separate drive for the Item Library location will also allow the drives to function better in parallel. If possible place the operating system on a drive of its own. The more you can reduce the contention for data access off the physical disk drive, the more scalable the configuration will be. There are also techniques such as disk striping that can assist in increasing the throughput in certain disk configurations. In addition to the speed and configuration of the disk subsystem, additional performance can be gained from the Item Library in the File Storage tier, but organizing your file types in to separate directories. When too many files accumulate on the file system in a particular directory, it can impact the operating systems speed to serve up the file. Networking The systems’ networking is an important aspect of scaling. If the network card is saturated with network traffic in your configuration, an additional network card can be used to help scale the application. Whether you are scaling vertically or horizontally and are planning to support clients in a WAN environment, we suggest you consult our “Optimizing WAN Development” guidelines document. Horizontal Scaling When it comes to achieving the highest levels of concurrency, scaling out horizontally becomes necessary. Simply moving the components to separate machines is a great start when attempting to scale horizontally. Since the Database and CM Server will most likely be contending for CPU, RAM and disk I/O, it is recommended that you separate these pieces first. When you begin to apply a horizontal scaling strategy, you will have further networking considerations. Consider keeping the CM Server and DB Server on the same network subnet if possible. The closer in proximity the servers the less impact you will see due to network traffic/delay. To extend the capacity of the system you essentially have the option of doing some form of load separation and load balancing. Dynamic Load Balancing 18
The Web Application will be able to take advantage of a web farm that contains multiple Web Application Containers (e.g. Tomcat) . The farm of Web Application Containers can be implemented using either hardware or software. Hardware web farms require specialized hardware and skills to implement and tend to be more costly. A software web farm can be implemented completely using Microsoft Windows 2003/2000 Server. The network load balancing capabilities of Windows 2003 and Windows 2000 Server automatically distribute the load across servers in the farm. In either type of Web Farm, the end user continues to access the system via a single URL and is completely unaware of the Web Farm implementation. www.serena.com
Specifically the Web Application Container can be load balanced using usual techniques: DNS based (with the known drawback of the DNS Caching mechanism) or Reverse Proxy based (whether using software techniques as Squid Internet Object Cache, Netscape's or Microsoft's Proxy Server, and Sun's Netra Proxy Cache Server or using hardware techniques as Cisco Systems' LocalDirector and Coyote Point Systems' Equalizer). The Dimensions CM server can also be load balanced using a hardware load balancer that supports the use of “server affinity” algorithms. A Dimensions client needs to connect to the same physical hardware for the Dimensions Server after an "idle" time, this means that the client needs to communicate to the same IP address for the server for the lifetime of its session. If you wanted to expand the capacity of your CM servers to support additional IDE and Desktop clients and add more capacity for your Browser based clients, your system deployment might look similar to this next diagram. Dynamic load balancing Static Load Balancing The nice part about dynamic load balancing is that all the Web Farms are seen to the end users as a single system even though they are made up of multiple systems. If you are not able to implement dynamic scaling, you can still scale the deployment manually. Each Dimensions CM Servers would be set‐up and linked to the central database. Each Dimensions server will hold part of the load of the users connecting to Dimensions. There will be no dynamic Load balancing happening and you will have to define a set of fixed users to connect on each of the server that you will set up. You might do this by instructing different departments of your organization to access one of the specific systems that had been designated for them. 19
www.serena.com
Depending on the bandwidth of your network and the organization of your projects it is even possible to set up the Dimensions Server “locally” and connect to a central database located “remotely” that holds the entire configuration Management Meta‐data for your organization. Configuration Guidelines Dimensions CM performance/scalability can be most impacted by the following factors: •
Network Configuration/Topology •
Server CPU speed •
Serna Dimension CM Configuration •
Usage Model Network Configuration/Topology – Dimensions CM is distributed across the clients, Servers, and database server. Consequently, network hardware and software configuration and capabilities have a significant impact on the performance characteristics of Dimensions deployment. The closer in proximity on the network these pieces are the better performance you will see. As a general rule of thumb, you should attempt to have your Servers and Database tiers on the same network segment if possible. Dimensions CM CPU speed – The server and database transactions can be CPU intensive. Faster CPUs translate directly to improved server performance. Do not under invest in the quality and speed of the Server CPUs. The more processes that are running on a single machine, the more the CPU demand will be once additional load is applied. Software Configuration – Dimensions CM’s configurability, while being one of the products greatest advantages, can lead to performance issues if not implemented in accordance with best practices. Serena’s technical support and professional services teams are well versed in these best practices and should be engaged to review implementations and help diagnose performance issues. Usage Model ‐ Dimensions CM is used by each customer to solve different types of business problems. You can imagine that there are many possible usage models and of course each one will utilize systems resources in a unique way. Understanding the usage model for your user base will allow you to determine how to best scale the servers to meet your companies needs. A General Approach for considering your needs When optimizing performance, focus first on getting servers with the fastest possible CPUs. Second, look closely at memory utilization and insure there is enough. Then, consider multiple processor configurations. These principles should be applied to servers when both scaling vertically and scaling horizontally. In the end, any single Dimensions CM operation happens fastest when CPU speed, network bandwidth, and available memory are high. Using the fastest possible CPU at the client, server, and database tiers result in the best end user experience. 20
www.serena.com
The following chart illustrates scalability zones for Dimensions CM. Dimensions
CM
Scalability
Zones
In this chart there are four zones. Zone 1 represents low concurrency and simple configuration and usage patterns. Zone 4 is highest end of the spectrum. It represents high concurrent user load and complex data and usage patterns. This table can be used to determine appropriate server configurations based on usage patterns and expected number of concurrent active users. The configuration recommendations are the results of analysis of data collected as part of the rigorous Dimensions CM acceptance and certification process. A concurrent user is defined by a user in the system who is actively performing work (e.g., two users refreshing their workspace at the same time). More users can be logged into the system but are not considered concurrent until they are performing some activity. With this definition you can determine your usage pattern and the number of concurrent processes that you anticipate to consider a hardware configuration that might fit your needs. If for example, if you want to support a population of 250 users and you believe at any one time you will have 50 users performing moderate operations (submitting new requests, updating records, performing file operations, etc…) then Zone 2 would be the starting point for the hardware you might consider. If you had a 1000+ user population to support, Zone 3 at 100 concurrent users might be appropriate for you. 21
www.serena.com
Summary Serena Dimensions CM has been architected, implemented and tested to meet the complexity and scalability challenges of the enterprise. Its meta‐data driven design provides extreme configurability and flexibility. Its open architecture provides several solutions to enterprise data connectivity. And, by leveraging state‐of‐the‐art technology, Serena Dimensions CM provides a platform that will grow to meet the ever expanding needs of the enterprise. 22
www.serena.com
Serena Worldwide Headquarters Serena Software, Inc. Corporate Offices 1900 Seaport Boulevard 2nd Floor Redwood City, CA 94063‐5587 United States 800.457.3736 T 650‐481‐3700 F info@serena.com ABOUT SERENA
Serena Software, Inc. is the leading global independent software company focused on Business Mashups, Project Portfolio Management and Application Lifecycle Management. More than 15,000 organizations around the world, including 96 of the Fortune 100, rely on Serena solutions to automate the application development process and effectively manage their IT portfolio. Serena is headquartered in Redwood City, California, and has offices throughout the U.S., Europe, and Asia Pacific. Learn more about the enterprise‐wide power of Serena products by visiting www.serena.com or contacting one of our sales representatives in your area. Serena European Headquarters Serena Software Europe Ltd. Hertfordshire Abbey View Everard Close St. Albans Hertfordshire AL 1 2PS United Kingdom +44 (0)800.328.0243 T +44 (0)1727.869.804 F ukinfo@serena.com Serena Asia Pacific Headquarters Serena Software Pte Ltd. 360 Orchard Road #12‐10 International Building Singapore 238869 +65 6834.9880 T +65 6836.3119 F apinfo@serena.com Copyright © 2008 Serena Software, Inc. All rights reserved. 23
www.serena.com