ca xosoft high availability for ca service desk · ca service desk manager r12 identity and access...
TRANSCRIPT
CA GREEN BOOKS
CA XOsoft™ High
Availability for CA Service Desk
LEGAL NOTICE
This publication is based on current information and resource allocations as of its date of publication and
is subject to change or withdrawal by CA at any time without notice. The information in this publication
could include typographical errors or technical inaccuracies. CA may make modifications to any CA
product, software program, method or procedure described in this publication at any time without
notice.
Any reference in this publication to non-CA products and non-CA websites are provided for convenience
only and shall not serve as CA’s endorsement of such products or websites. Your use of such products,
websites, and any information regarding such products or any materials provided with such products or
at such websites shall be at your own risk.
Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute
product documentation or specifications under any existing or future written license agreement or
services agreement relating to any CA software product, or be subject to any warranty set forth in any
such written agreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under
any existing or future written license agreement or services agreement relating to any CA software
product; or (iii) serve to amend any product documentation or specifications for any CA software
product. The development, release and timing of any features or functionality described in this
publication remain at CA’s sole discretion.
The information in this publication is based upon CA’s experiences with the referenced software
products in a variety of development and customer environments. Past performance of the software
products in such development and customer environments is not indicative of the future performance of
such software products in identical, similar or different environments. CA does not warrant that the
software products will operate as specifically set forth in this publication. CA will support only the
referenced products in accordance with (i) the documentation and specifications provided with the
referenced product, and (ii) CA’s then-current maintenance and support policy for the referenced
product.
Certain information in this publication may outline CA’s general product direction. All information in
this publication is for your informational purposes only and may not be incorporated into any contract.
CA assumes no responsibility for the accuracy or completeness of the information. To the extent
permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including,
without limitation, any implied warranties of merchantability, fitness for a particular purpose, or
non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use
of this document, including, without limitation, lost profits, lost investment, business interruption,
goodwill or lost data, even if CA is expressly advised of the possibility of such damages.
COPYRIGHT LICENSE AND NOTICE:
This publication may contain sample application programming code and/or language which illustrate
programming techniques on various operating systems. Notwithstanding anything to the contrary
contained in this publication, such sample code does not constitute licensed products or software under
any CA license or services agreement. You may copy, modify and use this sample code for the
purposes of performing the installation methods and routines described in this document. These
samples have not been tested. CA does not make, and you may not rely on, any promise, express or
implied, of reliability, serviceability or function of the sample code.
Copyright © 2010 CA. All rights reserved. All trademarks, trade names, service marks and logos
referenced herein belong to their respective companies. Microsoft product screen shots reprinted with
permission from Microsoft Corporation.
TITLE AND PUBLICATION DATE:
CA XOsoft™ High Availability for CA Service Desk Green Book Version 2.1
Publication Date: June 7, 2010
ACKNOWLEDGEMENTS
Principal Authors
The principal authors and CA would like to thank all of the team members that contributed
to this document:
CA Services
Development
Marketing
QA
Support
SWAT
Technical Sales
Technical Information
Third-Party Acknowledgements
Microsoft product shots reprinted with permission from Microsoft Corporation. Microsoft and
Windows are registered trademarks of Microsoft Corporation in the United States and other
countries.
CA PRODUCT REFERENCES
This document references the following CA products:
■ CA XOsoft™ Replication r12 SP1
■ CA XOsoft™ High Availability r12 SP1
■ CA Service Desk r11.2
■ CA Service Desk Manager r12
■ Identity and Access Management Toolkit (IAM Toolkit) r8.0
■ Embedded Identity and Access Management (EIAM) r8.1 and r8.2
■ CA Embedded Entitlements Manager (CA EEM) r8.3
FEEDBACK
Please email us at [email protected] to share your feedback on this publication. Please
include the title of this publication in the subject of your email response. For technical
assistance with a CA product, please contact CA Technical Support at
http://ca.com/support. For assistance with support specific to Japanese operating systems,
please contact CA at http://www.casupport.jp.
DOCUMENTATION CHANGES
June 7, 2010
The following documentation updates have been made since the last release of this
documentation:
Introduction (see page 9)--Added that the information in this Green Book conforms to CA
ARCserve Replication r15 and CA ARCserve High Availability r15.
The following documentation updates have been made since the January 22, 2010, version
2.0 release of this documentation:
Scripting samples in Appendix A have been reorganized as given below to improve
sequence flow:
■ Sample scripts for Local MDB (no secondary CA Service Desk server).
■ Sample scripts for Remote MDB (no secondary CA Service Desk server).
■ Sample scripts for Local MDB (secondary CA Service Desk server present).
■ Sample scripts for Remote MDB (secondary CA Service Desk server present).
January 22, 2010 version 2.0 release
The following documentation updates have been made since the last release of this
documentation:
■ SDSecondary.bat Script (see page 63)—This new sample script gives details about
running routines on the active primary CA Service Desk server based on the host name
of the server.
■ Aos_remoteMDB.cmd Script Remote MDB (see page 59)—This script is modified to
include settings for secondary servers in the CA Service Desk environment.
■ Configure CA Service Desk on Primary and Secondary Servers (see page 43)—This new
section explains how you can configure CA Service Desk on primary and secondary
servers.
■ Start_remoteMDB.cmd Script-Remote MDB (see page 57)—Redundant details are
deleted from this script.
CA XOsoft™ High Availability for CA Service Desk 7
Contents
Chapter 1: Introduction 9 CA XOsoft Replication and CA XOsoft High Availability ........................................................ 9 Application High Availability............................................................................................. 9 Components of CA XOsoft High Availability ...................................................................... 10
CA XOsoft Control Service .......................................................................................... 11 CA XOsoft Engine ...................................................................................................... 11 Management Center .................................................................................................. 11 CA XOsoft PowerShell ................................................................................................ 11
The CA XOsoft High Availability Synchronization Process ................................................... 12 The CA XOsoft High Availability Replication Process .......................................................... 12 Synchronization and Replication in a High Availability Scenario .......................................... 12
Chapter 2: CA Service Desk 15 What IT service challenges does CA Service Desk meet? ................................................ 15 What features does CA Service Desk offer? .................................................................. 15
CA Service Desk Components ........................................................................................ 15 Implementation Types .................................................................................................. 17
Centralized Implementation ....................................................................................... 17 Distributed Implementation ........................................................................................ 18
CA Service Desk with Tomcat and SQL Server ................................................................. 19 CA Service Desk High Availability ................................................................................... 19
CA XOsoft High Availability Solution for CA Service Desk ................................................ 20
Chapter 3: Implementing CA XOsoft High Availability for CA Service
Desk 23 Software Requirements................................................................................................. 23 System Requirements................................................................................................... 24 Logon Account Requirements ........................................................................................ 24 CA XOsoft Control Service and Manager Installation ......................................................... 25
Install CA XOsoft Control Service ................................................................................ 25 Install CA XOsoft Manager.......................................................................................... 25 Connect to CA XOsoft Manager from a Remote System .................................................. 25
CA XOsoft Engine Installation on Master and Replica Servers ............................................. 26 Install CA XOsoft Engines Using Remote Installer .......................................................... 26 Install CA XOsoft Engines Locally ................................................................................ 28
Preparing CA Service Desk for High Availability ................................................................ 28 Prepare CA Service Desk on the Master Server ............................................................. 29 Prepare CA Service Desk on the Replica Server ............................................................. 31 Create and Configure Replication Scenarios .................................................................. 32 Configure CA Service Desk with CA EEM ...................................................................... 42 Configure CA Service Desk with CA Workflow ............................................................... 42 Configure CA Service Desk on Primary and Secondary Servers ....................................... 43
Chapter 4: Switchover and Switchback 45 Perform a Manual Switchover ........................................................................................ 45 Automatic Switchover ................................................................................................... 45 Perform a Manual Switchback ........................................................................................ 46 Automatic Switchback .................................................................................................. 47
8 Contents
Chapter 5: Best Practices for CA XOsoft High Availability and CA
Service Desk 49 CA XOsoft High Availability Spool Directory Location ......................................................... 49 Spool Directory Settings ............................................................................................... 49 CA XOsoft High Availability and Real-Time Antivirus Protection .......................................... 50 CA XOsoft High Availability Recover Active Server ............................................................ 50 Tuning for High Bandwidth Situations ............................................................................. 51 Setting Up CA Service Desk for High Availability .............................................................. 52
Appendix A: Sample Scripts 53 Sample Scripts for Local MDB (no secondary CA Service Desk servers) ............................... 53
Start.cmd ................................................................................................................ 54 Stop.cmd ................................................................................................................. 55 IsAlive.cmd .............................................................................................................. 56 Aos.cmd (Action on Success) ...................................................................................... 56
Sample Scripts for Remote MDB (no secondary CA Service Desk servers) ........................... 57 Start.cmd ................................................................................................................ 57 Stop.cmd ................................................................................................................. 58 IsAlive.cmd .............................................................................................................. 58 Aos.cmd (Action on Success) ...................................................................................... 59
Sample Scripts for Local MDB (secondary CA Service Desk servers present) ........................ 59 Start.cmd ................................................................................................................ 60 Stop.cmd ................................................................................................................. 61 IsAlive.cmd .............................................................................................................. 62 Aos.cmd (Action on Success) ...................................................................................... 62 SDSecondary.cmd ..................................................................................................... 63
Sample Scripts for Remote MDB (secondary CA Service Desk servers present) .................... 64 Start.cmd ................................................................................................................ 65 Stop.cmd ................................................................................................................. 65 IsAlive.cmd .............................................................................................................. 66 Aos.cmd (Action on Success) ...................................................................................... 66 SDSecondary.cmd ..................................................................................................... 67
Glossary 69
Index 71
CA XOsoft™ High Availability for CA Service Desk 9
Chapter 1: Introduction
The CA XOsoft High Availability for CA Service Desk Green Book is a guide to implementing
a high availability solution for CA Service Desk Manager r12, CA Service Desk r11.2, and
the underlying database infrastructure of Microsoft® SQL Server® (SQL Server). The
implementation described in this book is based on CA XOsoft High Availability replication to
remote secondary servers with automated switchover and client redirection during critical
failures. The procedures, scripts, and implementation best practices described in this book
also apply to CA ARCserve Replication r15 and CA ARCserve High Availability r15.
CA XOsoft Replication and CA XOsoft High Availability
CA XOsoft Replication is a data protection solution that uses asynchronous real-time
replication over network infrastructure (both LAN and WAN) to provide cost-effective
disaster recovery capabilities for Microsoft Exchange Server, SQL Server, Oracle, Microsoft
IIS, file servers, and other applications on 32-bit and 64-bit Windows, AIX, Linux, and
Solaris servers.
CA XOsoft High Availability contains all the features of CA XOsoft Replication, and also
provides switchover and switchback support, ensuring high availability of your protected
applications.
Application High Availability
When events such as virus attacks, software errors, or hardware failures occur, you must
ensure that you do not incur significant losses in application data. Your response to such
critical situations directly affects your business, customers, investors, and other
stakeholders. Business continuity is not just about insurance, but it is also about
maintaining your competitive edge.
Application-specific versions of CA XOsoft High Availability support the ability to:
■ Monitor application services
■ Start and stop services during switchover or switchback
■ Check the currently active and standby (passive) servers
■ Redirect users from one server to another
Components of CA XOsoft High Availability
10 Chapter 1: Introduction
For supported applications such as SQL Server, Exchange Server, Microsoft IIS, and Oracle,
all of these capabilities are built into the product and are available out-of-the-box.
However, using CA XOsoft High Availability, it is possible to associate a user-defined script
with each of the functions listed earlier, which can augment or replace the functions in the
application-specific versions, or which can be added to the CA XOsoft High Availability
Server version. This Green Book focuses on implementing CA Service Desk high availability
with Tomcat and SQL Server.
Components of CA XOsoft High Availability
CA XOsoft High Availability consists of the following components:
■ CA XOsoft Control Service
■ CA XOsoft Engine
■ CA XOsoft Management Center
> Overview Page
> Manager
> Report Center
■ CA XOsoft PowerShell
CA XOsoft High Availability components are described in the following sections.
Components of CA XOsoft High Availability
CA XOsoft™ High Availability for CA Service Desk 11
CA XOsoft Control Service
The CA XOsoft Control Service (Control Service) functions as the single point of control of
the CA XOsoft operation, and it contains the entire data of the existing scenarios. The
Control Service communicates with both, the Engines and the Managers. It manages all
scenario-related tasks such as creating, configuring, monitoring, and running scenarios.
CA XOsoft Engine
The CA XOsoft Engine (Engine) is a Windows service that must be running before any
scenario can start. It is installed on every server, that is, the master (source) and the
replica (target) hosts participating in any given scenario. Each Engine supports both master
and replica functions for replication and high availability scenarios. It may participate in
multiple scenarios and serve in a different role in each scenario. You can install the Engines
either locally on each host at a time, or through a remote installer on multiple hosts
simultaneously.
Management Center
The CA XOsoft Management Center (Management Center) consists of the Overview Page,
Manager, and Report Center. It communicates directly with the Control Service through the
web browser. When you connect to the Management Center from a remote computer, the
components are downloaded and installed locally.
A brief description of the components is as follows:
Overview Page
The initial landing page. Provides a statistical overview of the state of replication and
high availability scenarios. You use the Overview Page to access the Manager and Report Center interfaces.
Manager
This is a user interface you access from the Overview Page. You use the Manager to create, configure, manage, and monitor replication scenarios.
Report Center
This is a user interface you access from the Overview Page. You use the Report Center to gather all existing reports, and information about the scenarios. You can decide where these reports will be stored, and for how long they will be displayed and saved in the Report Center.
CA XOsoft PowerShell
The CA XOsoft PowerShell is a plug-in to Microsoft PowerShell, that provides command-line
shell and scripting environment. CA XOsoft PowerShell lets you configure a replication
scenario, control, and monitor the replication process.
The CA XOsoft High Availability Synchronization Process
12 Chapter 1: Introduction
The CA XOsoft High Availability Synchronization Process
Synchronization is the process of making the set of files to be protected identical on the
master and replica servers. You must synchronize the master and replica as the initial step
of a replication scenario.
To properly synchronize the master and the replica, you must compare their file structures
to determine what content (files and folders) on the master is missing or is different from
that on the replica. CA XOsoft High Availability supports the following synchronization
modes:
File Synchronization
Recommended when the data being synchronized comprises many relatively small and medium-sized files (less than 100 MB).
Block Synchronization
Recommended when the data being synchronized consists of several huge files (more than 100 MB).
The CA XOsoft High Availability Replication Process
The replication mechanism maintains identical copies of files and databases (established by
the synchronization process) by capturing real-time, byte-level changes in the files on the
master server. The changes are then asynchronously transmitted to the replica servers
using a file-system filter-driver. The replication process does not interfere with write
operations.
Synchronization and Replication in a High Availability Scenario
The implementation of the high availability scenario for CA Service Desk depends on the
location where the Management Database (MDB) is installed. If you install the MDB on the
same computer as the CA Service Desk server, then you must create a SQL Server type
and include block synchronization with real-time replication. If you install the MDB on a
computer other than the CA Service Desk server, then you must create a file server
scenario and include file synchronization with real-time replication.
Synchronization and Replication in a High Availability Scenario
CA XOsoft™ High Availability for CA Service Desk 13
When you run the scenario, the following actions are performed:
■ CA XOsoft High Availability starts the synchronization process to make sure that the
data on the master CA Service Desk server and the replica CA Service Desk server are
identical.
■ The replication process starts automatically and captures any changes to the database
and files of CA Service Desk.
■ In real-time, the replication process replicates the changes on the CA Service Desk
replica server, to ensure that the CA Service Desk master and replica servers are in
sync at any given time.
CA XOsoft™ High Availability for CA Service Desk 15
Chapter 2: CA Service Desk
CA Service Desk offers you service request, incident, problem, and change management
capabilities that maximize analyst productivity and enhance responsiveness. It is
compatible with the IT Infrastructure Library (ITIL) and is built on a proven, scalable
architecture. CA Service Desk aligns IT processes with your business goals while providing
superior service for employees, customers, and partners.
What IT service challenges does CA Service Desk meet?
CA Service Desk addresses the common challenges of managing service commitments,
keeping your end users productive, and customers happy by simplifying and managing
complex service and support requirements.
What features does CA Service Desk offer?
CA Service Desk features workflow-driven ITIL automation for incident, problem, and
change management, and offers self-service capabilities to end users. The product
manages service levels to ensure response time commitments and automated customer
surveys to ensure high-quality support.
CA Service Desk Components
Several CA Service Desk components run on a primary or secondary server. These
components are identical, and can be physically distributed, regardless of platform. The
main components are as follows:
Management Database (MDB)
The relational database, and the common operational store or repository for CA
products. The recommended practice is to host the MDB on its own server separate from the CA Service Desk Server.
CA Service Desk Components
16 Chapter 2: CA Service Desk
Object Manager (domsrvr)
The distributed object manager server. It is the most important process in the CA
Service Desk product. When you install a primary server, two Object Managers are installed by default, one for client connections and one dedicated to Web Screen Painter (WSP). When you install a secondary server, you can configure additional Object Managers. For scalability, we recommend that you configure multiple Object Manager
and Web Engine pairs either on your primary server or on secondary servers as deemed appropriate to handle your expected end user load and hardware configuration.
Web Engine (webengine)
Provides back-end functionality for access to CA Service Desk through a browser. It is a
daemon or service that responds to cgi requests from a Microsoft IIS or Apache Tomcat web server. You must have a Web Engine for WSP on the primary server so WSP Schema Designer can write schema files. Web Engines are the true client of an Object Manager for user client web browsers. Web Engines maintain sessions and cache htmpl web forms for connected users. You can manipulate the cache using the pdm_webcache utility and see web client connection statistics using the pdm_webstat utility.
Web Director
An optional process that balances load among multiple Web Engines. Web Director is a
specially configured pdmweb cgi. The basic way of using Web Director is for simple load balancing. The Web Director selects the Web Engine with the least amount of active users and redirects users to the desired Web Engine. The Web Engine handles the subsequent requests directly without involving the Web Director. You can also use the Web Director to provide enhanced security for login while allowing most user interactions to use a higher performance standard connection. You can configure the Web Director to direct login requests to a specific Web Engine that uses the SSL
(secure socket) protocol. After Web Director authenticates a user, it redirects subsequent requests to a different Web Engine using a standard protocol.
CA Embedded Entitlements Manager (CA EEM)
Can act as an authentication and authorization mechanism as well as serve as an LDAP repository for supported platforms. Typically this component is installed on the same server as the MDB.
CA Workflow
The common workflow engine for CA products. It provides a graphical representation of processes, actors or users, decision points, and flow. It supports complex branching, approval, and parallel processing mechanisms; and seamlessly integrates out-of-the-box with the CA Service Desk Change Order module.
Determining the optimal distribution of these components depends on the environment use,
supported number of users, available hardware and budget, as well as scalability,
availability, and failover requirements.
Implementation Types
CA XOsoft™ High Availability for CA Service Desk 17
Implementation Types
CA Service Desk supports two types of implementations-centralized and distributed. The
following sections describe these implementations.
Centralized Implementation
When you perform a default installation of CA Service Desk, you configure a centralized
implementation. In this type of implementation, all components are installed and configured
on one network-addressable entity, which is a primary server. You can implement multiple
Object Managers and Web Engines for client load balancing and failover, but if the business
continues to grow, you may encounter issues with all users connecting back to the primary
server. In this case, the architecture can be expanded into a distributed environment.
Centralized architectures would typically be implemented to support a development
environment, a test environment, or a very small implementation in a production
environment. This environment would consist of one primary server with a local MDB
instance. One or more Object Manager and Web Engine pairs may exist if there is sufficient
CPU and memory available.
Implementation Types
18 Chapter 2: CA Service Desk
Distributed Implementation
In this type of implementation, components of CA Service Desk are placed on servers that
are closer to the clients receiving the service. For example, a physical location of the
business that has a number of subnets may have many analysts using the CA Service Desk
Web Client. Placing a secondary server at this location reduces the network traffic and
response times for those analysts because the secondary server localizes client traffic.
Network traffic between that location and the primary server is also reduced because the
secondary server performs caching. This type of implementation still enables you to
implement multiple Object Managers and Web Engines for client load balancing and failover.
The best practice is to implement Object Managers and Web Engines in pairs.
CA Service Desk with Tomcat and SQL Server
CA XOsoft™ High Availability for CA Service Desk 19
The CA Service Desk components can be distributed to exist on two or more servers, so
that there is a primary server, a separate database server for a remote MDB, and optional
secondary servers with the following local components:
■ Database Server
> MDB
> CA EEM
■ Primary Server
> Object Manager and Web Engine pair
> Web Director (optional)
> CA Workflow
■ Secondary Server (optional)
> Object Manager and Web Engine pair
> Web Director (optional)
This environment would optimally support large implementations and have the most
flexibility to support scalability and availability, as well as failover configurations.
CA Service Desk with Tomcat and SQL Server
CA Service Desk supports different combinations of web servers and database servers;
however, this Green Book focuses on Tomcat and SQL Server. You can apply the concepts
described in this Green Book to Microsoft IIS and Oracle.
Important! You must thoroughly verify any high availability solution before implementing
it in your production environment.
CA Service Desk High Availability
More and more companies are consolidating due to mergers and buy-outs or simply want to
consolidate separate service desks so as to benefit from economies of scale. Therefore, a
new need exists to create an enterprise service desk solution. The enterprise service desk
will run 24 hours a day, seven days a week. This means that the service desk is expected to
maintain high availability (HA) to provide for the company's business needs.
CA Service Desk High Availability
20 Chapter 2: CA Service Desk
High availability for CA Service Desk begins by following the same principles as any high
availability project. This book cannot go beyond issues specific to CA Service Desk. We
encourage sites to investigate high availability best practices on all levels. Consider the
following points:
■ On the first level, a clean Uninterruptible Power System (UPS) will provide continuous
service.
■ An auxiliary generator added to the UPS will maintain power during blackouts.
■ The servers themselves should have dual power supply, dual network interface
controller (NIC), and RAID Level 5 or better for disk redundancy.
The existence of all this redundancy in the server components will not necessarily prevent
the failure of the server over time and subsequent downtime, but it will extend the life of
the server before a failure occurs.
The CA Service Desk environment includes a primary CA Service Desk application server,
database server, and possibly a few secondary web servers. The primary CA Service Desk
application server is not cluster aware, but is cluster tolerant. Therefore, to achieve high
availability on the next level, each server must have its own redundancy.
CA XOsoft High Availability Solution for CA Service Desk
The CA XOsoft High Availability solution for CA Service Desk provides high availability using
a scripted approach. CA Service Desk is vital for your organization's continued operation
and business continuity plan. This solution can provide protection from events that could be
isolated to the CA Service Desk server and situations affecting entire sites or regions.
This solution provides the following benefits:
■ Provides high availability for CA Service Desk (CA Service Desk r11.2 and CA Service
Desk Manager r12)
■ Ensures CA Service Desk continuity and integrity during server maintenance
CA Service Desk High Availability
CA XOsoft™ High Availability for CA Service Desk 21
The CA XOsoft High Availability solution supports the following product scenarios:
■ CA Service Desk with the MDB on the same computer where CA Service Desk service
resides
■ CA Service Desk with the MDB on a remote computer, different from the machine
where CA Service Desk service resides
■ CA Service Desk with Embedded Identity and Access Management (EIAM) or CA EEM
installed depending upon the version of CA Service Desk enabled
Note: With CA Service Desk, you can install IAM Toolkit, EIAM, or CA EEM (EIAM is
now known as CA EEM and has the release number 8.3).
■ CA Service Desk with CA Workflow
■ CA Service Desk with primary and secondary server setup
CA XOsoft™ High Availability for CA Service Desk 23
Chapter 3: Implementing CA
XOsoft High Availability for CA
Service Desk
This chapter describes the following:
■ Requirements for running CA XOsoft High Availability for CA Service Desk r11.2 and CA
Service Desk Manager r12
■ Procedures for installing CA XOsoft components on CA Service Desk master and replica
servers
Software Requirements
You must have the following software installed to implement the high availability scenario
with CA XOsoft High Availability for CA Service Desk:
■ CA XOsoft High Availability r12 SP1
■ CA Service Desk r11.2 or CA Service Desk Manager r12
■ SQL Server 2005 (Enterprise or Standard Edition), or SQL Server 2008
Note: CA Service Desk Manager r12 and CA XOsoft r12 SP1 support SQL Server 2005 and
SQL Server 2008. These releases do not support SQL Server 2000.
System Requirements
24 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
System Requirements
The system requirements to implement the high availability scenario with CA XOsoft High
Availability for CA Service Desk are:
■ You must have two servers (a production server and a stand-by server) with SQL
Server 2005 or SQL Server 2008 installed on each server.
Note: CA Service Desk Manager r12 and CA XOsoft r12 SP1 support SQL Server 2005
and SQL Server 2008. These releases do not support SQL Server 2000.
■ Both servers must have the same SQL version, service packs and hot fixes installed.
■ Both servers must have identical SQL Server instances, default or named.
■ Both servers must have identical drive letters for database files.
■ Both servers must have identical full path to the default system database of each
instance.
■ The master and replica servers must have identical and statically assigned ports
defined in the Network Configuration TCP/IP properties of the SQL instances.
■ If ODBC connections are made to the servers, all clients must connect using the defined
port.
Logon Account Requirements
The CA XOsoft High Availability service logon account must satisfy all of the following
conditions:
■ The account must be a member of the Domain Admins group. If the Domain Admins
group is not a member of the built-in domain local group Administrators, you must use
an account that is a member of the local built-in Administrators group.
■ The account must be a member of the local computer's Administrators Group on all
servers. If the Domain Admins group is not a member, add the account manually.
■ If the account does not have built-in administrator permissions on all SQL Server
instances, add appropriate permissions.
■ The account must be able to modify the SQL Master and Replica DNS A-Record.
Note: If your company's security policy requires even more granular permissions than
described, or any special circumstances apply to your case, contact Technical Support to
receive detailed instructions on the permissions required.
CA XOsoft Control Service and Manager Installation
CA XOsoft™ High Availability for CA Service Desk 25
CA XOsoft Control Service and Manager Installation
The CA XOsoft Control Service functions as the single point-of-control of the CA XOsoft
operation, and it contains the entire data of the existing scenarios.
The installation package for CA XOsoft contains the setup.exe file, which runs a standard
installation wizard to guide you through the installation procedure.
For additional information on purchasing the CA products featured in this publication, please
contact your account representative, or visit http://ca.com/support and select How to Buy.
Install CA XOsoft Control Service
You can install the CA XOsoft Control Service on any stand-alone server in the network.
To install the CA XOsoft Control Service, use the setup.exe file, select the CA XOsoft Control
Service option, and follow the instructions in the wizard.
Install CA XOsoft Manager
You can install the CA XOsoft Manager through the CA XOsoft Overview Page.
To install the CA XOsoft Manager, open the CA XOsoft Overview Page, and click the
Scenario Management link. The system automatically installs the CA XOsoft Manager on
your local computer.
Connect to CA XOsoft Manager from a Remote System
You can connect to the CA XOsoft Manager from a remote system.
To connect to the CA XOsoft Manager
1. Open Internet Explorer.
2. Enter the address as CA XOsoft Control Service host name (or IP address) and port
number as given below:
http://host_name:port_no/start_page.aspx
Note: If you selected the SSL Configuration option when installing the CA XOsoft
Control Service, then, in the Overview page, enter the host name of the CA XOsoft
Control Service system instead of its IP address. Enter the CA XOsoft Control Service
host name and port number as follows:
https://host_name:port_no/start_page.aspx
3. Click the Scenario Management link to access the CA XOsoft Manager.
CA XOsoft Engine Installation on Master and Replica Servers
26 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
CA XOsoft Engine Installation on Master and Replica Servers
Install the CA XOsoft Engines on the primary, and the replica or standby CA Service Desk
servers using the remote or local CA XOsoft installation procedure.
Install CA XOsoft Engines Using Remote Installer
The Remote Installer option lets you install the CA XOsoft Engine on multiple servers
simultaneously. Use the CA XOsoft Remote Installer to deploy the Engine to servers that
will be later used in CA XOsoft High Availability scenarios.
Verify the following before you install the CA XOsoft Engine using the Remote Installer:
■ Exclude the CA XOsoft Engine installation and spool directories from antivirus
protection on all servers.
■ If the master server is a cluster, install CA XOsoft Engine using the Remote Installer on
all nodes of the cluster. You need not fail over the SQL Server group during installation.
To install CA XOsoft Engine using the Remote Installer
1. Open the CA XOsoft Overview Page and launch the Manager.
2. Click Tools, Remote Installer.
3. Select and add the servers where you want to install CA XOsoft Engine. You can also
add servers manually, using the server name or IP address.
4. Click Next.
5. Enter the login details for a domain that has administrator rights on all the selected
hosts.
The Remote Installer connects to all servers and verifies the availability of the host,
version of the currently installed CA XOsoft Engine, details of service logon account,
and whether reboot is required after installing the CA XOsoft Engine.
Note: If you are not logged on with an administrative account, use an account with
appropriate permissions.
CA XOsoft Engine Installation on Master and Replica Servers
CA XOsoft™ High Availability for CA Service Desk 27
6. Set the installation properties such as service logon information, CDP repository
installation information, and port for all selected hosts.
When the installation is complete, a status message appears for each server.
Note: The logon account you use must meet the requirements described in the Logon
Account Requirements section.
7. Click Next.
The installation report appears.
Note: If you have installed CA XOsoft Engine under a different account than required, you
can change it under the Windows Services console at any time. In the Windows Services
console, find the CA XOsoft Engine service and change the Log On Account. Restart the
service to apply the change.
Preparing CA Service Desk for High Availability
28 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
Install CA XOsoft Engines Locally
You can install the CA XOsoft Engines on the master and replica CA Service Desk servers
manually by running the CA XOsoft setup program locally on these servers.
To install CA XOsoft Engine on the master or replica server
1. Use a logon account that meets the requirements described in the Logon Account
Requirements section.
Note: If you installed under a different account than required, you can change it under
the Windows Services console at any time.
2. If you have installed antivirus software, exclude the CA XOsoft Engine installation and
Spool directories from antivirus protection.
3. If the master/replica server is a cluster, perform steps 1 and 2 on all nodes. You need
not fail over the SQL Server group during installation on the passive node.
Preparing CA Service Desk for High Availability
The following sections describe the procedures to prepare your CA Service Desk master and
replica servers for high availability.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 29
Prepare CA Service Desk on the Master Server
This procedure applies when you use SQL as the back-end database.
For CA Service Desk to properly start after a failover, the replica server must have the
same (case sensitive) host name as the master server when starting. Check and ensure
that the following registry entries are set to ensure that host names are in uppercase.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Hostname
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\NV Hostname
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NV
Hostname
To prepare the master server
1. Install and configure a master server, and then connect to the MDB.
2. Create registry key dependency for CA Service Desk Service (pdm_daemon_manager)
on SQL Server Service in the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pdm_daemon_manager
Note: This is required for CA Service Desk r11.2 when the MDB is on the same server
as the primary server. CA Service Desk Manager r12 automatically sets this entry as
part of the configuration process. Also for Oracle, the DependOnService value would be
the name of the Oracle service.
a. Select the sub-key representing the service you want to delay, and then click
Edit.
b. Click Add Value.
c. Create a value DependOnService with a data type of REG_MULTI_SZ, and then
click OK.
The Data dialog opens.
d. Type the name or names of the services that you prefer to start before this
service with one entry per line, and then click OK.
The name of the service that you enter in the Data dialog is the name of the
service as it appears in the registry under the Services key.
Preparing CA Service Desk for High Availability
30 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
3. Install the CA XOsoft Engine on the master server (see Install CA XOsoft Engines using
Remote Installer (see page 26)).
4. Verify CA Service Desk by logging in and creating a few requests, incidents, or change
orders.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 31
Prepare CA Service Desk on the Replica Server
When installing or configuring the replica server, use the same user name and password
that you used when installing or configuring the master server for both SQL and CA Service
Desk.
To prepare the replica server
1. Shut down the master server before preparing and installing CA Service Desk on the
replica server.
2. Remove the replica server from the domain and connect it to a temporary workgroup.
3. Change the replica host name to master host name, and then install CA Service Desk.
4. Validate the dependency for the existence of the CA Service Desk Service
(pdm_daemon_manager) on SQL Server Service. If it does not exist, use the procedure
given below to create in the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pdm_daemon_manager
Note: This is required for CA Service Desk r11.2 when the MDB is on the same server
as the primary server. CA Service Desk Manager r12 automatically sets this entry as
part of the configuration process. Also for Oracle, the DependOnService value would be
the name of the Oracle service.
a. Select the sub-key representing the service you want to delay, and then click
Edit.
b. Click Add Value.
c. Create a value DependOnService with a data type of REG_MULTI_SZ, and then
click OK.
The Data dialog opens.
d. Type the name or names of the services that you prefer to start before this
service with one entry per line, and then click OK.
The name of the service that you enter in the Data dialog is the name of the
service as it appears in the registry under the Services key.
Preparing CA Service Desk for High Availability
32 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
5. Verify CA Service Desk by logging in and creating a few requests, incidents, or change
orders.
6. Set the value of CA Service Desk service to disabled, and the value of Startup for SQL
Server Service to manual.
7. Install the CA XOsoft Engine on the replica server. (See Remote Install Considerations
(see page 26).)
8. Change the host name back to the replica server's actual name and connect it to the
domain.
9. Reboot the server.
Create and Configure Replication Scenarios
You can create replication scenarios with CA XOsoft High Availability using either SQL
Server or Oracle as the database server for the MDB. Also, you can create a CA XOsoft High
Availability SQL scenario and configure scripts to protect CA Service Desk either with a local
SQL Server or with a remote SQL Server.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 33
Create a Scenario with a Local MDB (SQL Server) and Tomcat
This procedure applies when you use a local SQL Server as the database and Tomcat as the
web server.
To create a scenario with a local SQL Server
1. Open CA XOsoft Manager and click File, New.
The Welcome window opens.
2. Select Create a New Scenario, and click Next.
The Select Server and Product Type window opens.
3. Under Select Server Type, select SQL Server, and under Select Product Type, select
High Availability Scenario [HA].
4. (Optional) Under Tasks on Replica, select Integrity Testing for Assured Recovery (AR).
5. Click Next.
The Master and Replica Hosts window opens.
6. Enter a name for the scenario, and the server names for the master and replica hosts.
Click Next.
Note: If either server is a MSCS cluster, enter the SQL virtual server name (or IP
address) as the master and/or replica name. Also, make sure you enter the correct
path of server if you are creating the scenario on a remote server.
Preparing CA Service Desk for High Availability
34 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
The Master Configuration window opens.
7. Verify that the MDB is selected for replication, and click Next.
8. In the Scenario Properties window, set the Replication Mode to Online.
9. In the High Availability Properties window, select the following options.
> Under Network Traffic Redirection:
Set Redirect DNS to On.
Set Switch Computer Name to On.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 35
Set Reboot after Switchover and Switchback to On.
> Under Is Alive:
Set Check Script on Active Host to On. In Script Name (Full Path),
enter C:\IsAlive.cmd.
> Under DB Management, set Automatic to Off. Under User-Defined Scripts:
Set Start DB Script to On. In Script Name (Full Path), enter
C:\start_localMDB.cmd.
Set Stop DB Script to On. In Script Name (Full Path), enter
C:\stop_localMDB.cmd.
> Under Action upon Success, set User Defined Script to On. In Script Name (Full
Path), enter C:\aos_localMDB.cmd.
Preparing CA Service Desk for High Availability
36 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
10. Add the root directory for CA Service Desk, which is typically:
C:\Program Files\CA\Service Desk
Note: The directories added in the previous step are replicated between the master
and replica. Additionally, you may need to select more directories for replication
depending on which components you want to protect (for example, CA Workflow, CA
EEM Server, secondary server, and so on). Typically these directories are located in the
folder:
C:\Program Files\CA\SC or C:\Program Files\CA\SharedComponents
11. Set the Switchover Initiation and Reverse Replication Initiation to Switchover manually
and Start manually respectively.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 37
12. Click Next, and then click Finish in the next page.
Note: If there are no errors, the scenario creation process ends; if there are errors, the
errors are displayed and the verification starts.
The scenario is created successfully.
13. Execute the scenario.
The following illustration shows a synchronization process:
The following illustration shows a completed synchronization process.
Preparing CA Service Desk for High Availability
38 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
Create a Scenario with a Remote MDB and Tomcat
This procedure applies when you use a remote MDB as the database and Tomcat as the
web server.
To create a scenario with a remote SQL Server
1. Open CA XOsoft Manager and click File, New.
The Welcome window opens.
2. Select Create a New Scenario, and click Next.
The Select Server and Product Type window opens.
3. Under Select Server Type, select File Server, and under Select Product Type, select
High Availability Scenario [HA].
4. (Optional) Under Tasks on Replica, select Integrity Testing for Assured Recovery (AR).
5. Click Next.
The Master and Replica Hosts window opens.
6. Enter a name for the scenario, and the server names for the master and replica hosts.
Click Next.
Note: If either server is a MSCS cluster, enter the SQL virtual server name (or IP
address) as the master and/or replica name. Also, make sure you enter the correct
path of server if you are creating the scenario on a remote server.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 39
The Master Root Directories window opens.
7. In the Scenario Properties window, set the Replication Mode to Online.
8. In the High Availability Properties window, select the following options:
> Under Network Traffic Redirection:
Set Redirect DNS to On.
Set Switch Computer Name to On.
Under Switch Computer Name, set Reboot after Switchover and
Switchback to On.
> Under Is Alive:
Set Check Script on Active Host to On. In Script Name (Full Path),
enter C:\IsAlive.cmd.
> Under DB Management, set Automatic to Off. Under User-Defined Scripts:
Set Start DB Script to On. In Script Name (Full Path), enter
C:\start_remoteMDB.cmd.
Set Stop DB Script to On. In Script Name (Full Path), enter
C:\stop_remoteMDB.cmd.
> Under Action upon Success, set User Defined Script to On.
In Script Name (Full Path), enter C:\aos_remoteMDB.cmd.
Preparing CA Service Desk for High Availability
40 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
9. Add the root directory for CA Service Desk, which is typically:
C:\Program Files\CA\Service Desk
Note: The directories added in the previous step are replicated between the master
and replica. Additionally, you may need to select more directories for replication
depending on which components you want to protect (for example, CA Workflow, CA
EEM Server, secondary server, and so on). Typically these directories are located in the
folder:
C:\Program Files\CA\SC or C:\Program Files\CA\SharedComponents
10. Set the Switchover Initiation and Reverse Replication Initiation to Switchover manually
and Start manually respectively.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 41
11. Click Next, and then click Finish in the next page.
Note: If there are no errors, the scenario creation process ends; if there are errors, the
errors are displayed and the verification starts.
The scenario is created successfully.
12. Execute the scenario.
The following illustration shows a synchronization process.
The following illustration shows a completed synchronization process.
Preparing CA Service Desk for High Availability
42 Chapter 3: Implementing CA XOsoft High Availability for CA Service Desk
Configure CA Service Desk with CA EEM
You can configure CA Embedded Entitlements Manager (CA EEM) with CA Service Desk for
replication.
To configure CA EEM with CA Service Desk
1. Define CA EEM authentication for CA Service Desk in one of the following ways:
> Set the value of <NX_USE_EIAM_AUTHENTICATION> to Yes.
> Reconfigure CA Service Desk by running pdm_configure from the command
prompt and select the User CA EEM Authentication check box on the CA EEM
configuration window.
2. Add the following root directories to the high availability scenario when CA EEM is
installed on the same computer as CA Service Desk:
C:\Program Files\CA\Advantage Ingres [ET]
C:\Program Files\CA\Shared Components\iTechnology
It is not necessary to replicate the entire Shared Components directory as it may
contain data not related to CA Service Desk.
3. (Optional) Add the following to the high availability scenario when CA EEM is installed
on a different computer than CA Service Desk:
C:\Program Files\CA\Service Desk
Configure CA Service Desk with CA Workflow
You can configure CA Service Desk with CA Workflow. CA Service Desk r11.2 automatically
installs CA Workflow. CA Workflow uses CA EEM for all user information, so all
authentication attempts and certain permissions are managed by CA EEM.
To configure CA Workflow for CA Service Desk, add the following root directories to the CA
Service Desk file server or SQL scenario:
C:\Program Files\CA\Service Desk
C:\Program Files\CA\Advantage Ingres [ET]
C:\Program Files\CA\Shared Components
If required, replicate the directories which you have mapped to CA EEM scenarios. However,
it is not necessary to replicate the entire Shared Components directory, as it may contain
data not related to CA Service Desk. Please check the directory to determine if there are
subdirectories that should be replicated.
Preparing CA Service Desk for High Availability
CA XOsoft™ High Availability for CA Service Desk 43
Configure CA Service Desk on Primary and Secondary Servers
As part of the switchover process, the primary CA Service Desk and replica primary CA
Service Desk servers are rebooted. After you perform the switchover of the primary CA
Service Desk server, you must restart the pdm_daemon_proctor services on the secondary
servers. You can automatically stop and start the pdm_daemon_proctor services on an
active primary CA Service Desk server by executing a batch file. In addition, you can
execute this batch file when the server boots, and you can create a scheduled task to
execute this file.
Note: You must stop and restart the pdm_daemon_proctor services on the secondary
server before you start the pmd_daemon_manager on the active CA Service Desk primary
server, if not the pdm_daemon_manager may hang during startup.
A sample SDSecondary.bat script is available in Appendix A: Sample Scripts (see page 63).
The SDSecondary.bat file stops and restarts all pdm_daemon_proctor services on all
secondary servers. After the pdm_daemon_proctor services on all secondary servers are
started, the local pdm_daemon_manager service is also started.
Create a Scheduled Task to Execute the SDSecondary.bat File
You can execute the SDSecondary.bat file when the server boots, and you can create a
scheduled task to execute this file.
To create a new scheduled task for executing the SDSecondary.bat file
1. Click Start, Programs, Accessories, System Tools, and then Scheduled Tasks.
2. Click Add Scheduled Task.
The Scheduled Task Wizard appears.
3. Click Next, browse to the location of the SDSecondary.bat file and select it.
4. Under the Perform this task option, select “when my computer starts" and then click
Next.
5. Enter the user name and password with which you access the computer, and then click
Next.
The task is created to execute the SDSecondary.bat file when the system boots.
For more information about how to schedule a task manually in Windows 2003, see the
Microsoft Knowledge Base article, How to use Schtasks.exe to Schedule Tasks in Windows
Server 2003.
CA XOsoft™ High Availability for CA Service Desk 45
Chapter 4: Switchover and
Switchback
The following sections describe how you can perform manual switchover and switchback
operations in a CA Service Desk high availability scenario.
Perform a Manual Switchover
Use the CA XOsoft Manager to perform a manual switchover either from the master server
to the replica server or from the replica server to the master server.
To initiate a manual switchover
1. Open the XOsoft Manager and select the desired CA Service Desk high availability
scenario.
2. Click Tools, Perform Switchover.
A confirmation message appears.
3. Click Yes to confirm the switchover.
CA XOsoft Manager initiates a switchover from the master SQL Server to the replica
SQL Server. The event pane of the CA XOsoft Manager displays detailed information
about the switchover event.
Automatic Switchover
Automatic switchover is in many ways identical to the manual switchover performed by an
administrator. A resource failure on the master server triggers an automatic switchover,
while an administrator initiates a manual switchover.
When you create a scenario, you can configure switchover in the Switchover and Reverse
Replication Initiation window.
You can also configure switchover from CA XOsoft Manager, after creating the scenario.
Perform a Manual Switchback
46 Chapter 4: Switchover and Switchback
Perform a Manual Switchback
A manual switchback is a switchover in the reverse direction. This means that a scenario
which has already initiated a switchover exists, and is performed successfully.
To perform a switchback manually
1. Ensure that both master and replica servers are available on the network, and the CA
XOsoft Engine service is running.
2. Run CA XOsoft Manager from the toolbar.
3. Select the desired CA Service Desk high availability scenario.
4. Determine if the backward scenario is running. If it is running, skip to step 5.
5. If the backward scenario is not running, click Run to start the scenario.
CA XOsoft High Availability detects that a switchover has occurred and prompts you
that it is running a backward scenario.
6. If resynchronization has been initiated, wait for it to complete.
A message confirming that all modifications were replicated appears in the Event
window.
7. Click Tools, Perform Switchover.
The Perform Switchover confirmation window appears.
8. Click OK.
The switchback operation starts.
9. Open CA Service Desk.
10. Check that the sample incidents, requests, etc. that were created on the master when
CA Service Desk was installed are available after switchover.
This indicates that the switchover is successful.
After switchback is completed, you can run the scenario again in its original (forward)
state. To avoid resynchronization after a successful switchover, use the Run Reverse
Replication Scenario Automatically option.
Automatic Switchback
CA XOsoft™ High Availability for CA Service Desk 47
Automatic Switchback
Automatic switchback is identical to manual switchback. A resource failure triggers
automatic switchback on the master server, while an administrator initiates the manual
switchover.
Note: Similar to manual switchback, an automatic switchback is initiated after a successful
automatic switchover.
CA XOsoft™ High Availability for CA Service Desk 49
Chapter 5: Best Practices for CA
XOsoft High Availability and CA
Service Desk
The following sections discuss the best practices for CA XOsoft High Availability and CA
Service Desk.
CA XOsoft High Availability Spool Directory Location
We recommend that you place the CA XOsoft High Availability spool directory on a separate
disk than that of the SQL DB files and the transaction logs. CA XOsoft High Availability
needs to write replication files to the spool directory. Placing the spool directory on the
same physical disk as the SQL DB files or transaction logs will increase disk I/O overhead
and can cause performance issues.
Spool Directory Settings
The CA XOsoft High Availability spool directory is a space on the disk where data to be
replicated is backed up (that is, spooled) if bandwidth is not sufficient to transfer the
amount of changes in real-time. Data can spool due to temporary network disconnections,
network congestion, or simply because the network bandwidth is not sufficient to transfer
the amount of data changing over on the server. In addition to storing changes waiting on
available bandwidth, spool space is also used as part of the normal synchronization process.
Thus, some spool build up during synchronization is normal.
Place the CA XOsoft High Availability spool folder on a drive with relatively low use such as
a dedicated volume or boot/system volume. Do not place the spool folder on a volume
containing frequently accessed system (OS), user, or application data. Examples include
volumes containing databases, shared files, or the system pagefile. By default, the spool
folder is located in the tmp folder under the CA XOsoft High Availability installation
directory. The spool parameters, either located in the Properties tab (on both master and
replica) or set with the New Scenario Wizard, determine how much disk space is available
for the spool. Typically, the default values are sufficient. However, if you choose to change
this value, it should be at least 10% of the total data set size. For example, if you are
replicating 50 GB of data on a server, you must ensure that at least 5 GB of space is
available for the spool.
Important! If you change the spool location, you must remember to remove the new path
from file level antivirus scans (scheduled and real time).
Note: CA XOsoft High Availability Spool Directory is not a pre-allocated space folder and
will be used only if needed.
CA XOsoft High Availability and Real-Time Antivirus Protection
50 Chapter 5: Best Practices for CA XOsoft High Availability and CA Service Desk
CA XOsoft High Availability and Real-Time Antivirus Protection
If you are running file-level antivirus software on the SQL server, then you must exclude
the CA XOsoft High Availability Spool directory from the virus scan by the antivirus
software.
CA XOsoft High Availability replicates changes in real-time; the changes are stored in
special replication files in the Spool directory. If each replication file is examined by the
antivirus software, the overall time it will take to complete the replication process will
increase.
Also, when the changes are made to the SQL database and subsequent CA XOsoft High
Availability replication files are being created as quickly as the changes are being applied to
the DB files, scanning each replication file can slow down the replication process.
When replication files are created faster than they can be sent to the replica server, they
begin to cache sequentially in the CA XOsoft High Availability Spool directory. If the master
server were to go down while those changes were cached in the Spool directory on the
master server, those changes would not be available on the replica if a switchover were to
occur and the replica became active.
CA XOsoft High Availability Recover Active Server
In certain circumstances, it may be necessary to forcibly make the master or replica server
the active server without completing the data synchronization process. You may need to do
so in cases where the switchover actually occurred but no data was changed on the replica
server. In such cases, you may even have newer data on the master server making it
undesirable to synchronize data from the replica to the master server.
CA XOsoft High Availability allows for this option through a process called Recover Active
Server. To use this option, you must stop the scenario, and select Recover Active Server
from the Tools menu.
Important! While this option is the right choice in many situations, use it with caution. If
used improperly, data loss can occur. Normally CA XOsoft High Availability will not allow
switchover from one host to another until all data is synchronized. It is designed this way
so that you are not redirected to an old data set that overwrites a current data set. When
using Recover Active Server, CA XOsoft High Availability lets you use one server or the
other with no regard as to which server has the correct data set. As an administrator, you
must manually ensure that the server you are making active has the most current data set.
Tuning for High Bandwidth Situations
CA XOsoft™ High Availability for CA Service Desk 51
Tuning for High Bandwidth Situations
When replicating data over a high speed bandwidth, the latency (ping times reported in
milliseconds) of the link can affect how much actual bandwidth is used. The impact caused
by latency can potentially limit the actual bandwidth you can use to a fraction of what is
available.
CA XOsoft High Availability compensates for latency by internally adjusting the TCP Window
Size of its TCP session over the WAN. By adjusting the TCP window size, CA XOsoft High
Availability properly uses your WAN link.
The TCP window size in CA XOsoft High Availability is tuned for WAN links up to 10M bit. If
your WAN link exceeds 10M bit or has exceptionally high latency, you may want to adjust
it. For assistance, contact CA Support at http://ca.com/support.
Important! Do not adjust the TCP window size in the operating system, as doing so will
affect other applications. You must tune the TCP window size from within CA XOsoft High
Availability.
Setting Up CA Service Desk for High Availability
52 Chapter 5: Best Practices for CA XOsoft High Availability and CA Service Desk
Setting Up CA Service Desk for High Availability
The following illustration shows the CA Service Desk high availability best practice. It
includes a primary application server and a backup primary server. There is an enterprise
database cluster server and the backup database node. The secondary web servers are by
location or region.
CA XOsoft™ High Availability for CA Service Desk 53
Appendix A: Sample Scripts
The following sections give the sample scripts for local and remote MDB.
Sample Scripts for Local MDB (no secondary CA Service Desk
servers)
This section gives the sample scripts which meet the following conditions:
1. The MDB (Master Database) is installed on the same server as the primary CA Service
Desk server.
2. No secondary CA Service Desk servers are present.
Sample Scripts for Local MDB (no secondary CA Service Desk servers)
54 Appendix A: Sample Scripts
Start.cmd
Start.cmd sets SQL server and CA Service Desk services to auto and starts the services.
Given below is the script for start.cmd:
@echo off
SC query MSSQLSERVER | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo MSSQLSERVER is already running
) ELSE (
sc config MSSQLSERVER start= auto
net start MSSQLSERVER
)
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already running
) ELSE (
sc config "pdm_daemon_manager" start= auto
net start pdm_daemon_manager
)
Note: Save the Start.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (no secondary CA Service Desk servers)
CA XOsoft™ High Availability for CA Service Desk 55
Stop.cmd
Stop.cmd sets the CA Service Desk service to disabled, SQL server service to manual, and
stops the services.
Given below is the script for stop.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already stopped
) ELSE (
sc config pdm_daemon_manager start= disabled
net stop pdm_daemon_manager
)
SC query MSSQLSERVER | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo MSSQLSERVER is already stopped
) ELSE (
sc config MSSQLSERVER start= demand
net stop MSSQLSERVER
)
Note: Save the Stop.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (no secondary CA Service Desk servers)
56 Appendix A: Sample Scripts
IsAlive.cmd
IsAlive.cmd attempts twice to restart a stopped service, before initiating a switchover
operation.
Given below is the script for the IsAlive.cmd:
@echo off
FOR %%G in (1,2) DO (
SC query PDM_DAEMON_MANAGER | find "STATE" | find "RUNNING"
if errorlevel == 1 ( net start PDM_DAEMON_MANAGER )
if errorlevel == 0 (
echo PDM_DAEMON_MANAGER is running
EXIT )
)
Note: Save the IsAlive.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Aos.cmd (Action on Success)
The Aos.cmd script sets services to automatic before rebooting during the switchover
process. This command is executed only on the node that is becoming the Active Server.
Given below is the script for the Aos.cmd:
@echo off
sc config "MSSQLSERVER" start= auto
sc config "pdm_daemon_manager" start= auto
Exit 0
)
Note: Save the Aos.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Remote MDB (no secondary CA Service Desk servers)
CA XOsoft™ High Availability for CA Service Desk 57
Sample Scripts for Remote MDB (no secondary CA Service Desk
servers)
This section gives the sample scripts which meet the following conditions:
1. The MDB (Master Database) is installed on a different server than the primary CA
Service Desk server.
2. No secondary CA Service Desk servers are present.
Start.cmd
Start.cmd sets the CA Service Desk service to auto and starts it.
Given below is the script for the Start.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already running
) ELSE (
sc config "pdm_daemon_manager" start= auto
net start pdm_daemon_manager
)
Note: Save the Start.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Remote MDB (no secondary CA Service Desk servers)
58 Appendix A: Sample Scripts
Stop.cmd
Stop.cmd sets the CA Service Desk service to disabled and stops it.
Given below is the script for the Stop.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already stopped
) ELSE (
sc config pdm_daemon_manager start= disabled
net stop pdm_daemon_manager
)
Note: Save the Stop.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
IsAlive.cmd
IsAlive.cmd attempts twice to restart the stopped CA Service Desk service, before initiating
a switchover operation.
Given below is the script for the IsAlive.cmd:
@echo off
FOR %%G in (1,2) DO (
SC query PDM_DAEMON_MANAGER | find "STATE" | find "RUNNING"
if errorlevel == 1 ( net start PDM_DAEMON_MANAGER )
if errorlevel == 0 (
echo PDM_DAEMON_MANAGER is running
EXIT )
)
Note: Save the IsAlive.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (secondary CA Service Desk servers present)
CA XOsoft™ High Availability for CA Service Desk 59
Aos.cmd (Action on Success)
The Aos.cmd script sets the CA Service Desk service to automatic before rebooting during
the switchover process. This command is executed only on the node that is set to become
the active server.
Given below is the script for the Aos.cmd:
@echo off
sc config "pdm_daemon_manager" start= auto
Exit 0
)
Note: Save the Aos.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (secondary CA Service Desk
servers present)
This section gives the sample scripts which meet the following conditions:
1. The MDB (Master Database) is installed on the same server as the primary CA Service
Desk server.
2. Secondary CA Service Desk servers are present.
Sample Scripts for Local MDB (secondary CA Service Desk servers present)
60 Appendix A: Sample Scripts
Start.cmd
Start.cmd sets SQL server and CA Service Desk services to auto and starts the services.
Given below is the script for start.cmd:
@echo off
SC query MSSQLSERVER | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo MSSQLSERVER is already running
) ELSE (
sc config MSSQLSERVER start= auto
net start MSSQLSERVER
)
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already running
) ELSE (
sc config "pdm_daemon_manager" start= auto
net start pdm_daemon_manager
)
Note: Save the Start.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (secondary CA Service Desk servers present)
CA XOsoft™ High Availability for CA Service Desk 61
Stop.cmd
Stop.cmd sets CA Service Desk service to disabled, SQL server service to manual, and
stops the services.
Given below is the script for Stop.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already stopped
) ELSE (
sc config pdm_daemon_manager start= disabled
net stop pdm_daemon_manager
)
SC query MSSQLSERVER | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo MSSQLSERVER is already stopped
) ELSE (
sc config MSSQLSERVER start= demand
net stop MSSQLSERVER
)
Note: Save the Stop.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (secondary CA Service Desk servers present)
62 Appendix A: Sample Scripts
IsAlive.cmd
IsAlive.cmd attempts twice to restart a stopped CA Service Desk service before initiating a
switchover operation.
Given below is the script for the IsAlive.cmd:
@echo off
FOR %%G in (1,2) DO (
SC query PDM_DAEMON_MANAGER | find "STATE" | find "RUNNING"
if errorlevel == 1 ( net start PDM_DAEMON_MANAGER )
if errorlevel == 0 (
echo PDM_DAEMON_MANAGER is running
EXIT )
)
Note: Save the IsAlive.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Aos.cmd (Action on Success)
The Aos.cmd script sets the CA Service Desk service to manual before rebooting during the
switchover process. This command is executed only on the node that is set to become the
active server.
Given below is the script for the Aos.cmd:
@echo off
sc config "MSSQLSERVER" start= auto
sc config "pdm_daemon_manager" start= demand
Exit 0
)
Note: Save the Aos.cmd file on the C: drive of the master and replica servers. The paths
on the master and replica must match.
Sample Scripts for Local MDB (secondary CA Service Desk servers present)
CA XOsoft™ High Availability for CA Service Desk 63
SDSecondary.cmd
The SDSecondary.cmd script runs routines on the active primary CA Service Desk server
based on the host name of the server, and stops and restarts all pdm_daemon_proctor
services on all secondary servers.
You must have the Sleep command for the script to function properly. You can download
the Sleep command from the Microsoft website or install it from the Windows 2003
Resource kit.
Note: You must define this command as a scheduled task and run it when the computer
starts. You can run the script only on a node that holds the host name of the active CA
Service Desk server.
set THISHOSTNAME=<CA Service Desk Primary Server>
if NOT %COMPUTERNAME%==%THISHOSTNAME% (
EXIT
)
SC \\<Secondary web server 01> query "pdm_daemon_proctor" | find "STATE" | find
"STOPPED"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already stopped
) ELSE (
SC \\ <Secondary web server 01> stop "pdm_daemon_proctor"
)
SC \\<Secondary web server 02> query "pdm_daemon_proctor" | find "STATE" | find
"STOPPED"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already stopped
) ELSE (
SC \\ <Secondary web server 02> stop "pdm_daemon_proctor"
)
SC \\<Secondary web server 01> query "pdm_daemon_proctor" | find "STATE" | find
"RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already running
) ELSE (
Sample Scripts for Remote MDB (secondary CA Service Desk servers present)
64 Appendix A: Sample Scripts
SC \\<Secondary web server 01> start "pdm_daemon_proctor"
)
SC \\<Secondary web server 02> query "pdm_daemon_proctor" | find "STATE" | find
"RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already running
) ELSE (
SC \\<Secondary web server 02> start "pdm_daemon_proctor"
)
Sleep 10
)
SC query "pdm_daemon_manager" | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_manager" is already running
) ELSE (
SC start "pdm_daemon_manager"
)
Note: Save the SDSecondary.cmd file on the C: drive of the master and replica servers.
The paths on the master and replica must match.
Sample Scripts for Remote MDB (secondary CA Service Desk
servers present)
This section gives the sample scripts which meet the following conditions:
1. The MDB (Master Database) is installed on a different server than the primary CA
Service Desk server.
2. Secondary CA Service Desk servers are present.
Sample Scripts for Remote MDB (secondary CA Service Desk servers present)
CA XOsoft™ High Availability for CA Service Desk 65
Start.cmd
Start.cmd sets services CA Service Desk service to auto and starts the service.
Given below is the script for Start.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already running
) ELSE (
sc config "pdm_daemon_manager" start= auto
net start pdm_daemon_manager
)
Stop.cmd
Stop.cmd sets CA Service Desk service to disabled and stops it.
Given below is the script for Stop.cmd:
@echo off
SC query pdm_daemon_manager | find "STATE" | find "RUNNING"
if NOT %ERRORLEVEL%==0 (
echo pdm_daemon_manager is already stopped
) ELSE (
sc config pdm_daemon_manager start= disabled
net stop pdm_daemon_manager
)
Sample Scripts for Remote MDB (secondary CA Service Desk servers present)
66 Appendix A: Sample Scripts
IsAlive.cmd
IsAlive.cmd attempts twice to restart a stopped CA Service Desk service before initiating a
switchover operation.
Given below is the script for the IsAlive.cmd:
@echo off
FOR %%G in (1,2) DO (
SC query PDM_DAEMON_MANAGER | find "STATE" | find "RUNNING"
if errorlevel == 1 ( net start PDM_DAEMON_MANAGER )
if errorlevel == 0 (
echo PDM_DAEMON_MANAGER is running
EXIT )
)
Note: Save the IsAlive.cmd file in the C: drive of the master and replica servers.
Aos.cmd (Action on Success)
The Aos.cmd script sets the CA Service Desk services to manual before rebooting during
the switchover process. This command is executed only on the node that is set to become
the active server.
Given below is the script for the Aos.cmd:
@echo off
sc config "pdm_daemon_manager" start= demand
Exit 0
)
Note: Save the Aos.cmd file in the drive where you have the operating system in the
master and replica servers.
Sample Scripts for Remote MDB (secondary CA Service Desk servers present)
CA XOsoft™ High Availability for CA Service Desk 67
SDSecondary.cmd
The SDSecondary.cmd script runs routines on the active primary CA Service Desk server
based on the host name of the server, and stops and restarts all pdm_daemon_proctor
services on all secondary servers.
You must have the Sleep command for the script to function properly. You can download
the Sleep command from the Microsoft website or install it from the Windows 2003
Resource kit.
Note: You must define this command as a scheduled task and run it when the computer
starts. You can run the script only on a node that holds the host name of the active CA
Service Desk server.
set THISHOSTNAME=<CA Service Desk Primary Server>
if NOT %COMPUTERNAME%==%THISHOSTNAME% (
EXIT
)
SC \\<Secondary web server 01> query "pdm_daemon_proctor" | find "STATE" | find
"STOPPED"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already stopped
) ELSE (
SC \\ <Secondary web server 01> stop "pdm_daemon_proctor"
)
Sleep 10
)
SC \\<Secondary web server 02> query "pdm_daemon_proctor" | find "STATE" | find
"STOPPED"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already stopped
) ELSE (
SC \\ <Secondary web server 02> stop "pdm_daemon_proctor"
)
Sleep 10
)
Sample Scripts for Remote MDB (secondary CA Service Desk servers present)
68 Appendix A: Sample Scripts
SC \\<Secondary web server 01> query "pdm_daemon_proctor" | find "STATE" | find
"RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already running
) ELSE (
SC \\<Secondary web server 01> start "pdm_daemon_proctor"
)
Sleep 10
)
SC \\<Secondary web server 02> query "pdm_daemon_proctor" | find "STATE" | find
"RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_proctor" is already running
) ELSE (
SC \\<Secondary web server 02> start "pdm_daemon_proctor"
)
Sleep 10
)
SC query "pdm_daemon_manager" | find "STATE" | find "RUNNING"
if %ERRORLEVEL%==0 (
echo "pdm_daemon_manager" is already running
) ELSE (
SC start "pdm_daemon_manager"
)
CA XOsoft™ High Availability for CA Service Desk 69
Glossary
Assured Recovery
Assured Recovery is a breakthrough technology that lets you conduct comprehensive and
regular tests of your disaster recovery standby servers without any disruption to your
production servers or any interruption in your disaster recovery protection. Assured
Recovery performs a real test of your disaster recovery server by actually running the
application, even modifying data, but without impacting the production environment in any
way.
Assured Recovery is an optionally licensed extension to the CA XOsoft High Availability
product suite.
Continuous Data Protection (CDP)
A continuous data protection (CDP) solution complements your backup infrastructure to
enable very rapid recovery from data corruption caused by viruses, software errors, and
user errors. It gives you the ability to rewind your data back in time to a point before the
corruption happened, regardless of how much data has changed, to ensure the absolute
minimum possible data loss following a corruption event, without the need for
special-purpose appliances.
CDP is an integral part of the CA XOsoft High Availability product suite.
master
A master server or simply master is the main or production server where database and file
activities occur. In a replication scenario, a master is the server that you want to replicate.
recovery
Recovery is the process of retrieving lost or corrupted master data from any replica by
activating a synchronization process in the reverse direction.
replica
A replica is a server set up to receive replication data from a master server.
replication
Replication is the process of capturing changes to files and databases on a master server
and transferring them to one or more replica servers, in real-time.
scenario
A scenario is a full replication process definition including master and replica servers and
their connectivity (replication tree), report and event handling rules, properties of nodes,
directories, sub-directories, databases and files that will be participating in the replication
process. Each scenario is saved as an XML file.
70 Glossary
synchronization
Synchronization is the process of producing an exact copy of the contents of the master
server on one or more remote replica servers.
CA XOsoft™ High Availability for CA Service Desk 71
Index
A
active server • 50 antivirus • 28, 50 assured recovery • 69 automatic switchback • 47 automatic switchover • 45
C
CA Workflow, configuring • 42
CDP • 69 components, CA XOsoft High Availability • 10 continuous data protection • 69 control service • 11
D
different account • 28
E
EIAM, configuring • 42 engine • 11
H
high availability benefits • 20 preparing servers • 28 software requirement • 23 system requirements • 24
I
implement, high availability scenario • 12 installing
backend, SQL database • 29 manually • 28 multiple servers • 26 using remote installer • 26
L
latency • 51 local MDB scripts
aos.cmd • 56, 62 IsAlive.cmd • 56, 62 sdsecondary.cmd • 63
start.cmd • 54, 60 stop.cmd • 55, 61
location, spool directory • 49 logon account • 24
M
Management Center • 11 manual switchback • 46 master server • 69 master server, preparing • 29 master-replica cluster • 28
P
PowerShell • 11
R
real-time antivirus protection • 50 remote MDB scripts
aos.cmd • 59, 66 IsAlive.cmd • 58, 66 sdsecondary.cmd • 67 start.cmd • 57, 65 stop.cmd • 58, 65
replica server definition • 69 preparing • 31
replication • 12 modes • 12 process • 69
scenario, creating • 33
S
sample scripts • 53, 57 scripts
aos.cmd • 56, 59, 62, 66 IsAlive.cmd • 56, 58, 62, 66 sdsecondary.cmd • 63, 67
start.cmd • 54, 57, 60, 65 stop.cmd • 55, 58, 61, 65
secondary server, configuring • 43 spool directory
changing • 49 location • 49 settings • 49
switch back manually • 46 switch over manually • 45 switchback, automatic • 47 switchover, automatic • 45 synchronization • 12
72 Index
T
TCP window size adjusting • 51 tuning • 51