Using Borland Deployment Op-Center to manage CaliberRM, StarTeam, and Mercury TestDirector server environments

Transcription

1 Using Borland Deployment Op-Center to manage CaliberRM, StarTeam, and Mercury TestDirector server environments A Borland White Paper By Darrell Kalichak March 2005

2 Contents Introduction... 3 Deployment Op-Center overview... 4 An example: configuring Deployment Op-Center to manage CaliberRM... 4 Orderly startup and shutdown... 7 Ping objects... 8 Other services and processes to monitor... 9 References and additional information

3 Introduction This white paper discusses using Borland Deployment Op-Center to manage the server environments for CaliberRM, StarTeam, and Mercury TestDirector. This includes managing the Web servers, database servers, and other infrastructure services required by these applications. It is assumed that the reader of this white paper is familiar with these environments. This includes issues involved in maintaining these environments, as far as monitoring their runtime status, providing an orderly shutdown and startup for routine backups, and understanding inter-product dependencies that exist in newer versions of these applications. For example, CaliberRM and StarTeam both use the common component MPXServer in day-to-day operations. Figure 1: The Borland Deployment Op-Center logical view 3

4 Deployment Op-Center overview Borland Deployment Op-Center is designed to help you maintain control and availability of highly distributed and heterogeneous software applications. It monitors and provides a consolidated view of networked business services and the infrastructure that supports them to help simplify the modeling and configuration of application components, their relationships, and dependencies. If a system failure occurs in production, Deployment Op-Center can isolate the problem and reestablish service automatically, minimizing impact on profitability. Deployment Op-Center can manage a variety of Web-based J2EE and CORBA services, components, processes, and hosts; its open and extensible architecture allows for straightforward integration with existing event management systems. An example: configuring Deployment Op-Center to manage CaliberRM Borland Deployment Op-Center can be used to manage the two primary services used on the CaliberRM server (SQM Database and SQM Monitor, see Figure 2). As these services must be started in order (SQM Database first, followed by SQM Monitor) and stopped in reverse order, CaliberRM is perfectly suited to be managed by Deployment Op-Center. Figure 2: SQM Database and SQM Monitor in the Windows Services Manager 4

5 Additionally, Deployment Op-Center can be used to manage the underlying Versant database processes cleanbe.exe and obe.exe (Figure 3) that CaliberRM uses. In the event that the database process is unexpectedly terminated, Deployment Op-Center can initiate an orderly shutdown of the remaining CaliberRM services and processes, then initiate an orderly restart. The sequence of events, as well as their successful completion, can be managed by Deployment Op-Center. Figure 3: Active Windows processes cleanbe.exe and obe.exe The configuration of the management of standard Microsoft Windows NT -style services or executable processes is very straightforward (Figure 4 and Figure 5): 5

6 Figure 4: Adding a new Windows Service using Deployment Op-Center Figure 5: Configuring a new Windows Service using Deployment Op-Center 6

7 Orderly startup and shutdown Managed Objects in Deployment Op-Center can be automatically restarted based on dependency rules that are defined to the managed object. For example, it can be defined that Deployment Op-Center should always start the SQM Monitor service after the SQM Database service is up and running. Therefore, if the SQM Database service were to be stopped unexpectedly, Deployment Op-Center can be made to stop the SQM Monitor Service, restart the SQM Database service, then restart the SQM Monitor service. Figure 6: Setting the start/stop order 7

8 Ping objects In addition to managed objects in Deployment Op-Center, you also can define ping objects. These objects can be used in cases in which you simply want to know if an object exists (look for a heartbeat). This is useful with the application lifecycle management (ALM) products. For example, you are able to see if the CaliberRM Java client is available. You could define a ping object to be the opening page for the CaliberRM Java Client (perhaps The ping object will periodically test that page, and if it gets a 200 return code (vs. 404 or some other error) it will show an OK icon; otherwise, it will report an Error. Figure 7: Setting the ping properties for monitoring the CaliberRM Web Client 8

9 Other services and processes to monitor In addition to the CaliberRM services and processes described above, you can manage numerous services and processes that are part of Borland s ALM strategy. The table below lists many of them. Application StarTeam StarTeam StarTeam StarTeam TestDirector Microsoft IIS ArgoSoft SMTP Mail Server Service/process Application Server Service Database Service Notification Agent Service MPX Service Application Service Service Service 9

10 References and additional information Below are links to other white papers and documentation on the Borland Web site: Borland Deployment Op-Center Technical Overview ( Borland CaliberRM for Requirements Management ( Borland StarTeam for Configuration Management ( Made in Borland Copyright 2005 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA Offices in: Australia, Brazil, Canada, China, Czech Republic, Finland, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, Mexico, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States