Deploying the IBM Rational Build Forge Management Console: Getting results and performance
This document is for system administrators or IBM Rational Build Forge console administrators who install the Rational Build Forge console software and agent software.
This document covers these topics:
- Planning the installation
- Choosing an operating system for the management console
- Preparing a computer to host a management console
- Configuring the database server
- Configuring computers to host agents
- Deciding network locations for the servers
- Using virtual machines
- Installing the database, the management console, and the agent software
- Configuring system settings for the management console
- Configuring classes to purge schedules and start related projects
- Configuring access groups of users who can see and control features
Planning the installation
Before you begin an installation, consider these factors:
- The operating system to use for the management console
- The database to use
- The systems to install the console software and the database software on
- Your corporate guidelines that influence the decisions on the previous factors
The following topics discuss some of these factors that you can add to your corporate guidelines.
Choosing an operating system for the management console
The Rational Build Forge management console runs on the Linux, IBM AIX, Solaris, and Microsoft Windows operating systems. The main tasks of the management console are as follows:
- Communicate with the database
- Generate processes to run jobs
Although you can run job steps by using a Rational Build Forge agent on the same computer as the management console, you typically install agents on other computers.
Given the main tasks of the management console, for optimal performance, choose an operating system that is effective with network communications and generating processes. Of the supported management console operating systems, none have significant issues with database communications. However, Microsoft Windows operating systems tend to have more capacity issues that are associated with starting a new process. If you plan to run many jobs, use one of the supported UNIX-based operating systems.
This document assumes the management console is installed on a computer that runs the Linux operating system.
Preparing a computer to host a management console
Your system administrators can best determine the processor, memory, and storage configuration for your management console system by taking these factors into consideration:
- The number of jobs that typically run at any given time
- The number of users who access the management console
This table discusses the suggested resources.
| Resource | Specifications for best operating results |
|---|---|
| Processors | The number of jobs that run at the same time affects the number of required processors. A mid-range server with four processors is adequate for most deployments. |
| Memory | Allocate at least 2 GB for the management console. If the host uses virtual memory, memory and disk accesses will be slower. Adequate memory is essential for the management console to perform effectively. A computer with at least 4 GB can handle most deployments. |
| Storage | Allocate 2 GB for installation and for the management console to use. |
You can deploy a management console on a virtual machine. However, because virtual machines do not typically have dedicated resources, the performance of the management console might be affected by activity on other virtual machines on the host. Given this behavior, deployment on a virtual machine is considered an advanced installation topic and is not covered in detail in this document.
Configuring the database server
Configuring a production database system is beyond the scope of this document, but consider several basic factors:
- Available I/O operations are key. When database servers start to slow down, the cause is typically I/O constraints. You can ensure the most available I/O operations to the storage holding the database data files by striping the storage volume across many disks. Your system or storage administrator should have a good idea about how to do this striping.
- The amount of storage that the database requires depends entirely on your projects. If your projects are short runs with little or no output, you could have thousands of builds in your database and use only a few megabytes of disk space. At the other extreme, if your projects contain many steps and each generates considerable output, you might have tens of builds in the database taking up several gigabytes of disk storage. For example, the Rational Build Forge production build system generally has fewer than 200 builds in the database, and the size of the database hovers around 9 GB. This database is that size because the builds have hundreds of steps, and many of those steps have several hundred (sometimes a couple thousand) lines of output.
Seek guidance from your database administrator. However, know that having too much available storage is better than too little. - The Rational Build Forge installation documentation contains details about the database server. Carefully read the section about database configuration for information about character set requirements and tuning parameters for optimal performance.
Configuring computers to host agents
The computers that you run Rational Build Forge agents on can be quite diverse. With this diversity, you can use Rational Build Forge to automate more tasks. If your tasks are platform-dependent, such as building software on multiple platforms, then you must have a computer for each platform with an agent installed.
The resource configuration of a computer running an agent depends on the tasks being automated on the computer. The agent itself uses minimal resources. The computer needs the processing power to run the maximum number of jobs you want to run at any one time. With more processors available to the agent, you can run more jobs without affecting performance. Similarly, the computer requires enough memory to accomplish the tasks in any given job and enough disk space to store the artifacts that are produced during job runs. If agent jobs process data on disk, storage space and I/O speed might be your primary concerns. Consult with your IT team when planning hardware for your servers.
Agents can run well on virtual systems; however, standard limitations apply. The resources that are available and the performance of the virtual machine are affected by the activity of other virtual machines on that host system. Allocating virtualized storage requires special consideration. Because of the nature of most virtualization technologies, virtualized storage does not have as much I/O as the underlying physical storage has. If a process frequently writes to the virtualized storage, the performance of the process may suffer.
Deciding network locations for the servers
Another important factor is the location of the servers. Network proximity reduces latency in network communications. Placing the computers on the same network segment produces the lowest latency in their communications. Because all output from the agents is transmitted across the network to the management console and then to the database, high network latency can lead to increased job run times.
If you have access to shared storage, making it available to the Rational Build Forge agent computers is beneficial. Rational Build Forge has built-in commands to move files around, but the commands are for moving a few small files. Although the commands can transfer large numbers of files or large files, the transfers are not efficient. With shared storage, you can have direct storage, without secondary transfer, of artifacts resulting from a job and reading of files needed to complete the job.
Using virtual machines
As mentioned earlier, installing management consoles and agents on virtual machines is an option. A goal of virtualization is greater resource utilization. With increased resource utilization comes more resource sharing. When sharing resources, your application performance can vary depending on the activity of other virtual machines on your virtual machine (VM) host. Virtualization of management consoles and agents is a viable deployment option if you allocate sufficient resources to each virtual machine. In some cases, insufficient memory can affect performance on a virtual machine more than it would on a physical computer. For optimal performance, allocate a little extra memory to each virtual machine to prevent the virtual machines from swapping.
Virtualizing database servers is the topic of many white papers. Contact your database vendor about best practices for virtualizing the database server for the management console.
Installing the database, the management console, and the agent software
For optimal performance and scalability, install the management console and the database on separate computers.
Installing the management console or agents on a network-mounted location can result in added latency on software startup and project execution. For optimal performance, install the management console on the local disk.
After you decide on which computers to install the management console and agents, have your database administrator create the database. For requirements regarding your database version, character set information, and other considerations, see the Rational Build Forge documentation. The documentation also provides information about the installation of the management console and the agents.
After you complete installation, read the next section to learn about system settings to consider.
Configuring system settings for the management console
Evaluate these system settings before you start creating server definitions and running jobs to decide whether the settings can benefit your environment. Your usage pattern determines the values of these settings. This section helps you determine those values.
- SMTP Server: This setting determines which mail server Rational Build Forge uses to send outgoing mail notifications. If your management console is in a network behind a firewall, the value of this setting should be the mail relay server for the network, and you should discuss the setting with your network administrators.
- Run Queue Size: This setting controls how many jobs the management console attempts to run at any given time. The default value is 3, which is a fairly conservative number. If your console has four processors, a value of 3 might be too small. Consider that none of the Rational Build Forge processes is likely to use 100% of any processor. If you do not run many threaded steps in your jobs, the highest processor utilization you will see will be about 25% for any given job. With such low utilization of four processors, you could increase your Run Queue Size. Plan on one processor for the Rational Build Forge system processes, and then divide the remaining number of processors by the expected processor utilization. Next, reduce the size slightly to ensure you do not overload the management console. With the above example, set the Run Queue Size to 10. (Four processors minus one for management console system processes is 3. Divide 3 by 25% to get 12. Add a little safety room, and 10 is an adequate setting.)
- Max Simultaneous Purges: This setting controls how many purges can run at the same time. Adjust this value to ensure that purges are completed in an acceptable period of time without affecting the performance and usability of the management console. The more purges that run at the same time, the busier and less responsive your management console is. If you have a large computer hosting your management console, this setting will not matter as much. Similarly, if you schedule your purges to run during off hours, the performance is not as large an issue. However, if your management console has international users and is used at all hours, set this value to a smaller number to maintain usability of the management console. Be careful not to set the value so small that your purges cannot be completed faster than new jobs are added. For example, if you are running 20 jobs an hour and your jobs take 12 minutes to purge each, you would need to run at least four purges concurrently. Adding a safety factor to this value, for this example, start at 10 Max Simultaneous Purges.
- Max Console Procs: This setting controls the maximum number of processes that the management console runs at one time. If you set this value too low, your Run Queue Size setting becomes ineffective. If you set this value too high, the stability of the computer that runs your management console might be affected. A good initial value for this setting is 10 + Run Queue Size + Max Simultaneous Purges. So for our earlier examples, set this value to 30.
- AutoClean settings: The AutoClean settings determine how long to retain system messages of different types. These are the settings and the related messages:
- AutoClean Error Log Days: Error messages help determine faults within the management console.
- AutoClean Warning Log Days: Warning messages can help determine faults or decide when to perform maintenance.
- AutoClean Audit Log Days: Audit messages can let you know when security settings have been changed. Keep them longer.
- AutoClean Info Log Days: Info messages act as a log of activity on the system. These messages will be quite numerous. Typically, you do not refer to these messages after a few days.
All of these messages help you understand what is going on in your management console, but the default settings are for a large organization with a high-performance database server with requirements to keep messages for long periods. Typically, you do not require that any of these messages be saved for more than 30 days. Perhaps you only require them for a few days.
Configuring classes to purge schedules and start related projects
Rational Build Forge uses classes to determine different attributes of both running and completed jobs. For example, you can start a project as a chain when changing into or out of any given class. You can use this feature to have Rational Build Forge deploy built software to be tested. Classes also determine how soon builds are purged.
Consider defining a few basic types of classes: short-term, mid-term, and long-term.
You might assign a short-term class to a build that happens every day to send a status email or clean files on build servers. You might assign a short-term class to purge jobs after one day. Frequent purging is useful for jobs that are not required for logging purposes and for jobs that do not generate important output.
A mid-term class might have a purge time of a few weeks. Use this class for daily builds that you keep an eye on and perhaps check for changes after a few days. However, do not use this class for builds that you need to keep forever.
A long-term class might be set to never purge. For example, if you released software to the public that was built from your management console, you would likely want to keep that build forever. Setting the build to such a long-term class is one way to accomplish that.
Configure classes shortly after you start running builds to maintain order in your completed jobs and to keep completed jobs from cluttering your database.
Configuring access groups of users who can see and control features
Rational Build Forge uses access groups to control two critical aspects of security: the ability of a user to see a Rational Build Forge object and permissions to act upon those objects. The best way to use access groups in Rational Build Forge is to effectively have two sets of access groups. One set limits what objects users can see; the other set controls what permissions users have. For example, if you have two teams whose projects you want to isolate, you can place their users in different access groups. You might create the group “widgets” for your teams that work with the widget group and the group “wodgets” for your teams that work with the wodget group. Putting management console users in these groups would limit what Rational Build Forge objects they can see. The widgets team cannot access the wodget projects, and the wodget team cannot see the widget projects. Administrators need to be able to see both groups. If you create a group for administrator access and make that group a subgroup of both the widgets and wodgets groups, members of that subgroup will be able to see both projects. (A subgroup inherits the accessibility of its parent group.)
This example does not discuss permissions. Permissions are separate from visibility and apply to all objects that users can see. Because permissions are separate, create a separate set of groups to manage permissions. Set up access groups that manage permissions to separate management of different sets of permissions you want to grant to your different users.
For example, perhaps a user named Allen requires access to edit projects and run projects using the devtest build servers (access levels on selectors control that access). Perhaps a user, Betty, must not have access to edit projects but must be able to run projects on production build servers. To manage these permissions, create two groups for access and two groups for permissions. Put Allen in the devtest group (which has access to the devtest build servers) and both the proj_run and proj_edit groups that have been assigned the needed permissions to run and edit projects. Then put Betty in the prod_operators group (which has access to the production build servers) and also in the proj_run group. With these groups, Betty can run projects, but not edit them. Also, while Allen can run projects, he cannot do so on production servers because he does not have the access to see them.
Note: In the Rational Build Forge access model, permissions apply to all visible objects.
For more information
© Copyright 2010 IBM Corporation