CA XOsoft High Availability for CA Service Desk · CA Service Desk Manager r12 Identity and Access Management Toolkit ... The CA XOsoft High Availability for CA Service Desk Green

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.

http://www.ca.com/greenbooks

http://www.ca.com/support

http://www.casupport.jp/

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


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.


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.



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


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.


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 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.



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


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.



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



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


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 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.

http://ca.com/support


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.



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


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.


The following sections describe the procedures to prepare your CA Service Desk master and

replica servers for high availability.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



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.



9. Add the root directory for CA Service Desk, which is typically:


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.



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.



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:


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\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.



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.

http://support.microsoft.com/kb/814596




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


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.


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


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.


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"


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.



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


if NOT %ERRORLEVEL%==0 (

echo pdm_daemon_manager is already stopped

) ELSE (

sc config pdm_daemon_manager start= disabled

net stop pdm_daemon_manager

)



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




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


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


Exit 0

)

Note: Save the Aos.cmd file on the C: drive of the master and replica servers. The paths


Sample Scripts for Remote MDB (no secondary CA Service Desk servers)


Sample Scripts for Remote MDB (no secondary CA Service Desk

servers)


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




) ELSE (



)



Sample Scripts for Remote MDB (no secondary CA Service Desk servers)


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




) ELSE (



)



IsAlive.cmd

IsAlive.cmd attempts twice to restart the stopped CA Service Desk service, before initiating

a switchover operation.


@echo off

FOR %%G in (1,2) DO (





EXIT )

)



Sample Scripts for Local MDB (secondary CA Service Desk servers present)



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.


@echo off


Exit 0

)



Sample Scripts for Local MDB (secondary CA Service Desk

servers present)


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.



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



echo MSSQLSERVER is already running

) ELSE (

sc config MSSQLSERVER start= auto

net start MSSQLSERVER

)




) ELSE (



)





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




) ELSE (



)



echo MSSQLSERVER is already stopped

) ELSE (

sc config MSSQLSERVER start= demand

net stop MSSQLSERVER

)





IsAlive.cmd

IsAlive.cmd attempts twice to restart a stopped CA Service Desk service before initiating a

switchover operation.


@echo off

FOR %%G in (1,2) DO (





EXIT )

)




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.


@echo off

sc config "MSSQLSERVER" start= auto

sc config "pdm_daemon_manager" start= demand

Exit 0

)





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


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"


echo "pdm_daemon_proctor" is already stopped

) ELSE (

SC \\ <Secondary web server 01> stop "pdm_daemon_proctor"

)


"STOPPED"



) ELSE (


)


"RUNNING"


echo "pdm_daemon_proctor" is already running

) ELSE (

Sample Scripts for Remote MDB (secondary CA Service Desk servers present)


SC \\<Secondary web server 01> start "pdm_daemon_proctor"

)


"RUNNING"



) ELSE (


)

Sleep 10

)

SC query "pdm_daemon_manager" | find "STATE" | find "RUNNING"


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)


1. The MDB (Master Database) is installed on a different server than the primary CA


2. Secondary CA Service Desk servers are present.



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




) ELSE (



)

Stop.cmd

Stop.cmd sets CA Service Desk service to disabled and stops it.

Given below is the script for Stop.cmd:

@echo off




) ELSE (



)



IsAlive.cmd

IsAlive.cmd attempts twice to restart a stopped CA Service Desk service before initiating a

switchover operation.


@echo off

FOR %%G in (1,2) DO (





EXIT )

)

Note: Save the IsAlive.cmd file in the C: drive of the master and replica servers.


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.


@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.



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


set THISHOSTNAME=<CA Service Desk Primary Server>

if NOT %COMPUTERNAME%==%THISHOSTNAME% (

EXIT

)


"STOPPED"



) ELSE (


)

Sleep 10

)


"STOPPED"



) ELSE (


)

Sleep 10

)




"RUNNING"



) ELSE (


)

Sleep 10

)


"RUNNING"



) ELSE (


)

Sleep 10

)

SC query "pdm_daemon_manager" | find "STATE" | find "RUNNING"


echo "pdm_daemon_manager" is already running

) ELSE (

SC start "pdm_daemon_manager"

)


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.


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

CA XOsoft High Availability for CA Service Desk · CA Service Desk Manager r12 Identity and Access Management Toolkit ... The CA XOsoft High Availability for CA Service Desk Green

Documents