BMC Enterprise Manager, Batch Impact Manager, Forecast, Server, Agent CONTROL-M Implementation Guide

CONTROL-M on Microsoft
Windows Clusters
Implementation Guide
Supporting
CONTROL-M/Enterprise Manager 6.3.01
BMC Batch Impact Manager 6.3.01
CONTROL-M/Forecast 6.3.01
CONTROL-M/Server for Microsoft Windows 6.3.01
CONTROL-M/Agent for Microsoft Windows 6.3.01
December 2006
www.bmc.com
Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address
BMC SOFTWARE INC
2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or
800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada
Telephone
(01) 713 918 8800
Copyright December 11, 2006 BMC Software, Inc., as an unpublished work. All rights reserved.
BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks
or trademarks of BMC Software, Inc.
IBM is a registered trademark of International Business Machines Corporation.
DB2 is a registered trademark of International Business Machines Corporation.
Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle
Corporation.
All other trademarks belong to their respective companies.
BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this
information is subject to the terms and conditions of the applicable End User License Agreement for the product and the
proprietary and restricted rights notices included in this documentation.
Restricted rights legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the
U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS
252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is
BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to
this address.
Customer support
You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer
Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”
Support website
You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support_home.
From this website, you can
■
■
■
■
■
■
■
read overviews about support services and programs that BMC offers
find the most current information about BMC products
search a database for issues similar to yours and possible solutions
order or download product documentation
report an issue or ask a question
subscribe to receive proactive e-mail alerts when new product notices are released
find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and
telephone numbers
Support by telephone or e-mail
In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or
send an e-mail message to [email protected]. Outside the United States and Canada, contact your local support center for
assistance.
Before contacting BMC
Have the following information available so that Customer Support can begin working on your issue immediately:
■
product information
—
—
—
■
product name
product version (release number)
license number and password (trial or permanent)
operating system and environment information
—
—
—
—
—
machine type
operating system type, version, and service pack or other maintenance level such as PUT or PTF
system hardware configuration
serial numbers
related software (database, application, and communication) including type, version, and service pack or
maintenance level
■
sequence of events leading to the issue
■
commands and options that you used
■
messages received (and the time and date that you received them)
—
—
—
product error messages
messages from the operating system, such as file system full
messages from related software
3
4
CONTROL-M on Windows Clusters
Contents
Chapter 1
Introduction to cluster technologies
7
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
What is in this document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 2
Cluster architecture and terminology
9
Server clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Cluster network configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Private and public network addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Cluster storage media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Quorum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Resource group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Cluster administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 3
CONTROL-M database configuration
15
Clustered configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microsoft SQL Server 2000 Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Oracle Real Application Cluster (RAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local database configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote database configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
17
17
Chapter 4
19
Best practices for CONTROL-M/Server and CONTROL-M/Agent
Creating IP Address and Network Name cluster resources . . . . . . . . . . . . . . . . . . . . . 19
Job disappearance workaround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Implementing CONTROL-M control modules in cluster installations . . . . . . . . . . 22
Starting and stopping CONTROL-M/Server and CONTROL-M/Agent . . . . . . . . . . 23
Chapter 5
Best practices for CONTROL-M/EM
25
Phase 1 Pre-installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 2 Installing CONTROL-M/EM on the cluster machine . . . . . . . . . . . . . . . . . . .
CONTROL-M/Forecast feature (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Batch Impact Manager (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 3 Post-installation procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set up the host and listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create CONTROL-M/EM Gateway cluster resource . . . . . . . . . . . . . . . . . . . . . . .
Contents
26
28
28
29
29
29
29
5
Verifying a cluster installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Install and log on to CONTROL-M/EM client components . . . . . . . . . . . . . . . . . . 31
Running BMC Batch Impact Manager web application under cluster
environment (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Updating BMC Batch Impact Manager and CONTROL-M/Forecast cluster
resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A
Example of installing Apache Tomcat on Windows clusters
Index
6
CONTROL-M on Windows Clusters
35
37
Chapter
1
1
Introduction to cluster technologies
Overview
This document contains technical information about how to implement
CONTROL-M on Microsoft Windows clusters and is intended for system
administrators and database administrators (DBAs). A relatively high level of
understanding of CONTROL-M architecture and internals, as well as cluster
administration, is needed to implement the content of this document. Therefore,
consider contacting BMC Software personnel to assist you while you carry out these
instructions.
A cluster is a group of independent computers working together as a single system to
ensure that mission-critical applications and resources are as highly available as
possible. The group is managed as a single system specifically designed to tolerate
component failures and transparently support the addition or removal of
components. The individual computers that compose the cluster are called nodes,
and the collection of components on each node that perform cluster-specific activities
is called a cluster service.
Cluster service is the Windows 2000 and Windows 2003 name for the cluster
technology that Microsoft Corporation introduced in Windows NT 4 Server
Enterprise Edition. The service was called Microsoft Cluster Server (MSCS).
In Windows 2000, Microsoft Corporation introduced two clustering technologies that
can be used independently or in combination, based on the requirements of a given
application or service:
■
cluster service: This service is intended primarily to provide failover support for
applications such as databases, enterprise resource planning (ERP) applications,
messaging systems, and file/print services. Cluster service is ideal for ensuring the
availability of critical line-of-business and other back-end systems, such as
Microsoft Exchange Server, Microsoft SQL Server database, or CONTROL-M.
Chapter 1 Introduction to cluster technologies
7
What is in this document?
The number of supported nodes depends on the specifics of the operating system:
— In the Windows 2000 Advanced Server operating system, cluster service
supports 2-node failover clusters.
— In the Windows 2000 Datacenter Server operating system, cluster service
supports 4-node failover clusters.
— In the Windows 2003 Enterprise Edition and Datacenter Edition, cluster service
supports 8-node failover clusters.
■
network load balancing (NLB): Network load balancing (NLB): This service is
available in the Windows 2000 Advanced Server operating system, Windows 2000
Datacenter Server and in all editions of the Windows Server 2003 family. It
load-balances incoming Internet Protocol (IP) traffic across clusters of up to 32
nodes. NLB enhances both the availability and scalability of Internet server-based
programs.
NOTE
CONTROL-M is not supported on an NLB service; therefore, NLB will not be further
discussed in this document.
What is in this document?
This document discusses the following topics:
■
considerations related to the implementation of the CONTROL-M database
CONTROL-M database configuration on page 15 describes the various ways to
configure the CONTROL-M database in a Windows cluster environment and the
installation of MS-SQL Server 2000 (Enterprise Edition) in a Windows cluster.
■
guidelines for implementing CONTROL-M/Enterprise Manager in a Windows
cluster environment
The guidelines in Best practices for CONTROL-M/EM on page 25 describe the
configuration steps required for CONTROL-M/Enterprise Manager to run in a
Windows cluster.
8
CONTROL-M on Windows Clusters
Chapter
2
2
Cluster architecture and terminology
This chapter describes the architecture of Windows cluster technology and explains
some of the relevant components and terms.
Server clusters
Server clusters are based on a shared-nothing model of cluster architecture. This model
refers to how servers in a cluster manage and use local and common cluster devices
and resources. In the shared-nothing cluster, each server owns and manages its local
devices. Devices common to the cluster, such as a common disk array and connection
media, are selectively owned and managed by a single server at any given time.
Cluster network configuration
The nodes in a cluster can exist in a single cabinet or be physically separated and
connected in a local area network (LAN).
All nodes in a cluster must be a part of the same domain, and each node can be
configured as a domain controller or member server. Ideally, clusters will have at
least two nodes acting as domain controllers and providing failover for critical
domain services. If the domain controllers are not cluster members, the availability of
the cluster resources is tied to those domain controllers.
Chapter 2
Cluster architecture and terminology
9
Private and public network addresses
Private and public network addresses
Each node in a cluster is typically configured with both private network and public
network addresses.
■
Private network addresses are used for node-to-node communications; that is,
transferring cluster configuration and administration data between the nodes in
the cluster. This is also referred to as an internal network.
■
Public network addresses are used for client-to-cluster communications; that is,
transferring data between the applications that are configured on the cluster and
the application clients. This is also referred to as an external network.
Cluster storage media
In addition to the local (system) disks of each node, the active node and all backup
nodes in the cluster are physically connected to a shared storage medium. The shared
disk is usually divided into multiple logical volumes, where each volume can be
available to only one node at a given time and will typically be used by only one
application (resource group).
Figure 1 illustrates the typical two-node cluster architecture:
Figure 1
10
Typical two-node cluster architecture
CONTROL-M on Windows Clusters
Resources
NOTE
■
This document describes installation on a two-node cluster, but the same principles apply
to cluster implementations with a larger number of nodes.
■
In Windows 2003 servers, a cluster technology was introduced, named Majority Node Set
(MNS) clusters. This technology allows you to connect multiple Windows 2003 servers in
a cluster without using a shared disk by saving a copy of the cluster configuration on the
local (system) disk of each node. Because the application data is not shared between nodes
in this configuration, this technology is irrelevant to CONTROL-M and therefore will not
be further discussed in this document.
Resources
The term resource refers to each hardware or software component within the cluster
that is managed by the cluster service. They are physical or logical entities. Hardware
devices such as disk drives and network interfaces are examples of physical cluster
resources. Internet Protocol (IP) addresses, applications, and application databases
are example of logical cluster resources.
Each node in the cluster has its own local resources. However, the nodes in a cluster
also share common resources (such as a common data storage array and private
cluster network) that are accessible by each node in the cluster.
Resources have the following characteristics. They can be
■
■
■
brought online and taken offline
managed by a cluster service
owned by only one node at a time
A resource is online when it is available and providing service to the cluster.
Chapter 2 Cluster architecture and terminology
11
Quorum
Quorum
One special common resource is the quorum resource, a physical disk in the common
cluster disk array that plays a critical role in cluster operations. It must be present for
node operations to occur, such as forming or joining a cluster. Figure 2 illustrates the
role of the quorum resource:
Figure 2
A quorum resource in a cluster
The quorum resource is used as a tie-breaker to avoid “split-brain,” a situation in
which all network communication links between two or more cluster nodes fails. In
such a case, only the cluster partition that “owns” the quorum can continue and run
the cluster applications. The rest of the cluster partitions are evicted from the cluster.
The quorum disk also contains the quorum log, which is a configuration database for
the server cluster. It holds cluster configuration information such as which servers are
part of the cluster, what resources are installed in the cluster, and what state those
resources are in (for example, online or offline). The quorum log is located by default
in \MSCS\quolog.log on the quorum disk.
Since the quorum disk is critical to the cluster operation it is not recommended to
install any application on it.
Resource group
A resource group is a collection of resources managed by the cluster service as a
single, logical unit. Application resources and cluster entities can be more easily
managed when logically related resources are defined into a resource group. A
cluster service operation performed on a resource group affects all individual
resources in the group. Typically, a resource group is defined to contain all the
elements needed by a specific application server and clients for successful use of the
application.
12
CONTROL-M on Windows Clusters
Virtual servers
Before adding an application to a resource group, whether the application can work
within the cluster environment must be determined, which depends on whether the
application is cluster-aware or cluster-unaware:
■
Cluster-aware applications are those that can work within the cluster environment
and support cluster events. Cluster-aware applications can register with the cluster
service to receive status and notification information. CONTROL-M/Enterprise
Manager, CONTROL-M/Server, and CONTROL-M/Agent are cluster-aware
applications.
■
Cluster-unaware applications do not support cluster events. Some cluster-unaware
applications, however, can be assigned to resource groups and can be failed over,
although failover usually requires intervention by the cluster administrator during
configuration of the application resources in the cluster.
Applications that meet the following criteria can be assigned to resource groups:
■
The application uses an IP-based protocol for its network communications (it
cannot use NetBEUI, IPX, AppleTalk or other protocols to communicate).
■
The application stores its data in a configurable location. This criterion is necessary
because nodes in the cluster access the application data through shared storage
devices. (If the application does not do so, the application data will not be available
on failover.)
■
The application client can retry and recover from a temporary loss of network
connectivity that occurs during failover.
Virtual servers
Applications and services running on a server cluster can appear to users and
workstations as running on virtual servers. A virtual server is a resource group that
contains at least one Network Name resource and one IP Address resource, in
addition to the specific application resources. Multiple virtual servers representing
multiple applications can be hosted in a cluster.
The user or client software that connects to an application that is running in a virtual
server does not know which node is actually hosting the virtual server. To users and
clients, connecting to an application or service that is running as a clustered virtual
server appears no different from connecting to a single, physical server.
Services or applications not accessed by user or client applications can run on a
cluster node without being managed as a virtual server.
Chapter 2 Cluster architecture and terminology
13
Cluster administration
In the event of an application or server failure, the cluster service moves the entire
virtual server resource group to another node in the cluster. When such a failure
occurs, the client will detect a failure in its session with the application and attempt to
reconnect in exactly the same manner as the original connection. The reconnection is
possible because the cluster service simply maps the published IP address of the
virtual server to a surviving node in the cluster during recovery operations. The client
session can reestablish the connection to the application without needing to know
that the application is now physically hosted on a different node in the cluster.
Each resource in a group may depend on other resources in the cluster. Dependencies
are relationships between resources that indicate which resources need to be started
and available before another resource can be started. For example, a database
application may depend on the availability of a disk, IP address, and network name
to be able to start and provide services to other applications and clients.
Resource dependencies are identified by using cluster resource properties and enable
the cluster service to control the order in which resources are brought online and
offline. The scope of any identified dependency is limited to resources within the
same resource group. Cluster-managed dependencies cannot extend beyond the
resource group, because resource groups can be brought online and offline and
moved independently.
Cluster administration
A cluster is administered using the Cluster Administrator interface, which enables
the performance of maintenance, monitoring, and failover administration. Also, the
Cluster Administrator interface contains an automation tool that you can use to create
cluster resources, nodes, and the cluster itself.
In Windows 2003 server platforms, the Cluster Administrator interface can be
installed and used regardless of whether the server is a cluster node.
14
CONTROL-M on Windows Clusters
Chapter
3
3
CONTROL-M database configuration
You can use the following types of implementations for the CONTROL-M database in
a Windows cluster environment:
■
clustered configuration: A single database installation on the cluster can be accessed
by both nodes. The database files are located on the shared disk and the database
server availability is controlled by the cluster.
■
local database configuration: The database server is locally installed on one of the
cluster nodes. Only a database client is installed on the other node.
■
remote database configuration: The database is installed on a non-clustered server or
on a cluster different from where CONTROL-M is installed. In this case, only
database clients are installed on each of the CONTROL-M cluster nodes.
Clustered configuration
This section describes a cluster configuration for both a Microsoft SQL Server 2000
Enterprise Edition and Oracle Real Application Cluster (RAC).
Microsoft SQL Server 2000 Enterprise Edition
When you install Microsoft SQL (MS-SQL) Server 2000 Enterprise Edition on a
cluster, the software binaries of the product are placed on the local drives of each one
of the selected nodes and the data files are placed on the assigned disk resource on
the shared drive. This configuration differs from the MS-SQL Server 7.0
configuration, in which both the binaries and the data files were placed on the
assigned disk resource on the shared drive.
Chapter 3 CONTROL-M database configuration
15
Clustered configuration
Also, the MS-SQL Server services (one service is created on each cluster node) are
named by default as the virtual server name. When the MS-SQL resource group is
moved from one node to another, the MS-SQL services are stopped on the original
(primary) node and started on the alternate node.
Installation of MS-SQL Server 2000 Enterprise Edition on a Windows 2000 cluster
automatically creates, in the selected resource group, the Network Name and IP
Address resources, in addition to the MS-SQL services resources. At that point, the
MS-SQL resource group becomes a virtual server and can be accessed by client
applications by the virtual name.
NOTE
If, during installation, the Virtual Server option in the Computer Name window is
disabled, you are installing an edition of MS-SQL different from the Enterprise
Edition, and the MS-SQL server cannot be installed in a clustered mode.
For more information about installing MS-SQL Server 2000 Enterprise Edition on a
Windows 2000 Cluster, see “SQL Server 2000 Failover Clustering” at
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx.
Oracle Real Application Cluster (RAC)
A normal Oracle installation consists of a single Oracle instance that accesses a
database on the same computer system. With RAC (formerly known as Oracle
Parallel Server), multiple instances on different nodes can access the same database
files simultaneously. In case of a node failure, the workload of this node will be
handled by the other node of the cluster.
After you prepare the system for installation, the Oracle Universal Installer (OUI)
presents the list of all cluster nodes, enabling you to select a subset as targets. Then
the OUI copies the Oracle software onto the first node, and then propagates the
software onto the rest of the chosen nodes of the cluster. Along with all the Oracle
software, Oracle Enterprise Manager (the central managing console) is automatically
installed and set up. When the installation is finished, the database creation wizard
and the network configuration wizard will be automatically invoked.
For more information about Oracle RAC installation, see the Oracle installation
documentation or the Oracle RAC whitepapers at
http://www.oracle.com/technology/products/database/clustering/RACWhitepapers.html.
NOTE
Oracle high availability features are only relevant for CONTROL-M/Enterprise Manager.
16
CONTROL-M on Windows Clusters
Local database configuration
Local database configuration
This configuration is based on the concept of installing the database server on one of
the cluster nodes and the database clients on the rest of the cluster nodes. In this way,
the database can be accessible to all the nodes in the cluster, but it will not be
maintained in a highly available manner. This configuration is not recommended for
CONTROL-M when implemented in a clustered configuration.
Remote database configuration
When the database server is located on a remote node (not one of the cluster nodes),
you can install a database client on each of the cluster nodes and connect them to the
remote database server. In this type of implementation, you do not need to install
additional database software on the cluster (besides the database client).
This configuration is common when database platforms reside in a centralized
location. However, the availability of CONTROL-M in this type of configuration is
tied to and dependent on the remote database server availability.
Chapter 3 CONTROL-M database configuration
17
Remote database configuration
18
CONTROL-M on Windows Clusters
Chapter
4
Best practices for
CONTROL-M/Server and
CONTROL-M/Agent
4
CONTROL-M/Server and CONTROL-M/Agent are cluster-aware applications and
can be installed on Windows clusters. The complete installation procedures are
provided in the installation guides, so they are not discussed in this document. This
chapter presents tips, hints, and best-practices information for the implementation of
version 6.3.01 of CONTROL-M/Server and CONTROL-M/Agent.
Creating IP Address and Network Name
cluster resources
CONTROL-M/Server and CONTROL-M/Agent installations require that the
Physical Disk, Network Name, and IP Address virtual resources are created before
you begin. When you install CONTROL-M/Agent to the same virtual server
(resource group) as CONTROL-M/Server, you do not need to manually create the
Network Name and IP address cluster resources.
When you install CONTROL-M/Server or CONTROL-M/Agent into a new resource
group or a resource group that does not include Physical Disk, Network Name, and
IP Address resources, use the following procedures to create these cluster resources
and bring them online.
NOTE
To install CONTROL-M/Server and CONTROL-M/Agent in a Windows cluster environment
you require administrator privileges on all the relevant cluster nodes.
Chapter 4 Best practices for CONTROL-M/Server and CONTROL-M/Agent
19
Creating IP Address and Network Name cluster resources
To create the IP Address resource
1 From the Cluster Administrator interface, select the relevant resource group.
2 Right-click an empty space in the group and choose New => Resource.
3 In the New Resource window perform the following steps, and then click Next:
A Enter the name that will be assigned to the IP address cluster resource (for
example, AG630 – IP Address).
B Enter a description for the IP address cluster resource (for example, Virtual IP
Address).
C Select resource type IP Address.
D Ensure that the selected group is the CONTROL-M/Server or CONTROLM/Agent resource group (for example, AG630).
4 In the Possible Owners window, ensure that all the nodes on which the
CONTROL-M/Server r CONTROL-M/Agent can be brought online are listed in
the Possible owners column, and then click Next:
5 In the Dependencies window click Next.
6 In the TCP/IP Address Parameters window perform the following steps, and then
click Finish:
A Enter the CONTROL-M/Server or CONTROL-M/Agent virtual IP address.
The Subnet mask field is automatically set.
B Select Network type External.
C Select the Enable NetBIOS for this address check box.
To create the Network Name resource
1 From the Cluster Administrator interface, select the relevant resource group.
2 Right-click an empty space in the group and choose New => Resource.
3 In the New Resource window, perform the following steps, and then click Next:
20
CONTROL-M on Windows Clusters
Job disappearance workaround
A Enter the name that will be assigned to the Network Name cluster resource (for
example, AG630 – Network Name).
B Enter a description for the Network Name cluster resource (for example, AG630
– Network Name).
C Select resource type Network Name.
D Ensure that the selected group is the CONTROL-M/Server or CONTROLM/Agent resource group (for example, AG630).
4 In the Possible Owners window ensure that all the nodes on which the CONTROLM/Server or CONTROL-M/Agent can be brought online are listed in the Possible
owners column, and then click Next.
5 In the Dependencies screen, select the Network Name cluster resource that you are
creating and click Add to add it to the resource dependencies list in the right
column.
6 In the Network Name Parameters window enter the name for the CONTROLM/Server or CONTROL-M/Agent virtual server, and then click Finish.
To bring the resources online
1 From the Cluster Administrator interface, select the CONTROL-M/Server or
CONTROL-M/Agent resource group.
2 Right-click the group and choose Bring Online.
Job disappearance workaround
Every time a job is submitted, a ctmrjobwin2k.exe process is created to monitor the job
and report about its completion. When the ctmrjobwin2k.exe process is started (with
each job), it creates the PROCID file for the job.
In a normal scenario, the ctmrjobwin2k.exe process detects the job completion,
updates the PROCID file and sends a trigger to the Agent Tracker (p_ctmat.exe) about
the completion. The p_ctmat.exe then sends the update to CONTROL-M/Server.
Chapter 4 Best practices for CONTROL-M/Server and CONTROL-M/Agent
21
Implementing CONTROL-M control modules in cluster installations
In a failover scenario, while the job is still executing, the agent process is stopped and
the agent partition is disconnected from the first host. In this case the job can keep
running, but the PROCID file will not be updated when the jobs completes (the agent
partition will be mapped to the backup node). Therefore, when the agent is started on
the backup node, and the next Track-All time arrives, it will find the original PROCID
file but it will not find the actual process. This is why the job is marked as
disappeared.
As an optional workaround, you can define a JLOST ON statement for the jobs that
run on the clustered agent (Statement=*, Code=JLOST) and execute a DO RERUN
command. In this case the jobs will be automatically restarted (rerun) on the backup
server when CONTROL-M/Server finds they have disappeared.
NOTE
You must enter value greater than 0 in the MAX RERUN parameter in order for the job
to be resubmitted.
Implementing CONTROL-M control modules in
cluster installations
NOTE
The section is relevant when installing CONTROL-M control modules versions earlier than
6.2.01.
When CONTROL-M/Agent is installed in cluster mode (as opposed to local mode),
every CONTROL-M/Agent must have a unique name so that they can all run on the
same cluster node. In such an installation, the default agent installation is disabled.
CONTROL-M control modules (CMs) versions earlier than version 6.3.01 are
supported only on default agents. Use the following procedure to work around this
problem and implement CMs local Windows cluster nodes:
1 Install a local CONTROL-M/Agent on each of the relevant cluster nodes.
2 Install the relevant CONTROL-M/CM on each of the local agents.
3 Apply the latest software updates (maintenance updates, fix packs, and so forth).
22
CONTROL-M on Windows Clusters
Starting and stopping CONTROL-M/Server and CONTROL-M/Agent
4 After the CONTROL-M/CM accounts are created on one of the nodes, copy the
account file from that node to the others.
5 In CONTROL-M/Server, create a node group that includes the physical host
names of all the relevant cluster nodes.
6 When creating the relevant skeleton in CONTROL-M/EM for the CM jobs, use the
node group name.
NOTE
The node group name can be different from the CONTROL-M/Server virtual host name in
case another agent is implemented in clustered mode in the CONTROL-M/Server virtual
server.
Starting and stopping CONTROL-M/Server and
CONTROL-M/Agent
When CONTROL-M/Server or CONTROL-M/Agent is installed in a Windows
cluster environment, only use either one of the following for starting and stopping
CONTROL-M/Server or CONTROL-M/Agent:
■
■
the Cluster Administrator
the cluster.exe utility
NOTE
When CONTROL-M/Server is managed in a cluster, the cluster software starts, stops, and
monitors CONTROL-M/Server actions. When used in a cluster, if the CONTROL-M/Server is
defined on CONTROL-M Configuration Manager, the CONTROL-M/Server desired state
defined on CONTROL-M Configuration Manager should be set to value ignore.
Chapter 4 Best practices for CONTROL-M/Server and CONTROL-M/Agent
23
Starting and stopping CONTROL-M/Server and CONTROL-M/Agent
24
CONTROL-M on Windows Clusters
Chapter
5
5
Best practices for CONTROL-M/EM
This chapter comprises the following phases, which help you install
CONTROL-M/Enterprise Manager (CONTROL-M/EM) to work on Windows
clusters:
“Phase 1 Pre-installation considerations” on page 26
“Phase 2 Installing CONTROL-M/EM on the cluster machine” on page 28
“Phase 3 Post-installation procedures” on page 29
In the implementation of CONTROL-M/EM on Windows Clusters, the
CONTROL-M/EM server components are not managed by the CONTROL-M
Configuration Manager. Instead each EM server component is defined as a cluster
resource and is managed by the Cluster Administrator.
When CONTROL-M/EM is installed in a Windows Cluster environment the
installation creates the CONTROL-M/EM Configuration Agent service with the
Startup Type set to "Manual" so the CONTROL-M/EM Configuration Agent will
remain down during normal operation.
The CONTROL-M Configuration Manager can be used to view the status of each
CONTROL-M server component.
NOTE
To avoid a conflict between the Cluster Administrator and the CONTROL-M/EM
Configuration Agent service, the Desired State for each CONTROL-M/EM component being
monitored must remain in the "Ignore" state.
Chapter 5
Best practices for CONTROL-M/EM
25
Phase 1 Pre-installation considerations
Phase 1 Pre-installation considerations
Review the following notes if you will be installing CONTROL-M/EM in a Microsoft
Windows cluster environment:
■
Do not share the IP and Network Name resources that identify the cluster with a
CONTROL-M/EM cluster instance.
■
Disk, IP, and Network Name resources must be online in the virtual server group
where an instance of CONTROL-M/EM on Microsoft Windows is to be installed.
■
Silent installation of CONTROL-M/EM is not supported for Microsoft Windows
cluster environments.
CONTROL-M/EM version 6.3.01 installation require Disk, Network Name and IP
Address virtual resources to be created before you begin. When you install
CONTROL-M/EM to the same virtual server (resource group) as
CONTROL-M/Server or MS-SQL Server, you do not need to manually create the
Network Name and IP address cluster resources. They are automatically created by
the CONTROL-M/Server or MS-SQL Server installation.
When you install CONTROL-M/EM into a new resource group or a resource group
that does not include Disk, Network Name and IP Address resources, use the
following procedures to create these cluster resources and bring them online.
To create the IP Address resource
1 From the Cluster Administrator interface, select the relevant resource group.
2 Right-click an empty space in the group and choose New => Resource.
3 In the New Resource window, perform the following steps, and then click Next:
A Enter the name that will be assigned to the IP address cluster resource (for
example, EM630 – IP Address).
B Enter a description for the IP address cluster resource (for example, Virtual IP
Address).
C Select resource type IP Address.
D Ensure that the selected group is the CONTROL-M/EM resource group (by
default, EM630).
4 In the Possible Owners window, ensure that all the nodes on which the
CONTROL-M/EM can be brought online are listed in the Possible owners column,
and then click Next.
26
CONTROL-M on Windows Clusters
Phase 1 Pre-installation considerations
5 In the Dependencies window, click Next.
6 In the TCP/IP Address Parameters window, perform the following steps, and then
click Finish:
A Enter the CONTROL-M/EM virtual IP address. The Subnet mask field is
automatically set.
B Select Network type External.
C Select the Enable NetBIOS for this address check box.
To create the Network Name resource
1 From the Cluster Administrator interface, select the relevant resource group.
2 Right-click an empty space in the group and choose New => Resource. The New
Resource window is displayed.
3 In the New Resource window, perform the following steps, and then click Next:
A Enter the name that will be assigned to the Network Name cluster resource (for
example, EM630 – Network Name).
B Enter a description for the Network Name cluster resource (for example, EM630
– Network Name).
C Select resource type Network Name.
D Ensure that the selected group is the CONTROL-M/EM resource group (by
default, EM630).
4 In the Possible Owners window, ensure that all the nodes on which the
CONTROL-M/EM can be brought online are listed in the Possible owners column,
and then click Next.
5 In the Dependencies screen, select the IP Address cluster resource that you are
creating and click Add to add it to the resource dependencies list in the right
column.
6 In the Network Name Parameters window, enter the name for the
CONTROL-M/EM virtual server, and then click Finish.
Chapter 5
Best practices for CONTROL-M/EM
27
Phase 2 Installing CONTROL-M/EM on the cluster machine
To bring the resources online
1 From the Cluster Administrator interface, select the CONTROL-M/EM resource
group.
2 Right-click the group and choose Bring Online.
3 To ensure the network name and IP address are published in the network, ping the
CONTROL-M/EM virtual server, as defined in step 6 of the “To create the
Network Name resource”task, from the command prompt.
Phase 2 Installing CONTROL-M/EM on the
cluster machine
NOTE
CONTROL-M/EM must be installed on the shared disk that was designated for the
CONTROL-M/EM Resource Group in the cluster environment.
Follow the instructions for installing CONTROL-M/EM as described in the
“Installing CONTROL-M/EM on Windows” section located in
CONTROL-M/Enterprise Manager Installation Guide Version 6.3.01.
NOTE
As part of the CONTROL-M/EM cluster aware installation procedure, TAO CORBA settings
and CONTROL-M/EM server component parameters are configured to work with the Virtual
Hostname that is being provided by the user during the installation process.
CONTROL-M/Forecast feature (optional)
After installing CONTROL-M/EM, the user has the option of installing
CONTROL-M/Forecast. It is intended only for customers who are licensed to use
CONTROL-M/Forecast. To install CONTROL-M/Forecast in the cluster
environment see the Release Notes for CONTROL-M/Forecast Version 6.3.01.
If you are installing CONTROL-M/Forecast on a cluster, it should be installed on the
primary node only.
28
CONTROL-M on Windows Clusters
Phase 3 Post-installation procedures
BMC Batch Impact Manager (optional)
Installing BMC Batch Impact Manager is optional. It is intended only for customers
who are licensed to use BMC Batch Impact Manager. To install BMC Batch Impact
Manager in the cluster environment see the chapter on installation in the BMC Batch
Impact Manager Version 6.3.01 User Guide. See also “Running BMC Batch Impact
Manager web application under cluster environment (optional)” on page 32 below.
If you are installing BMC Batch Impact Manager on a cluster, it should be installed on
the primary node only.
Phase 3 Post-installation procedures
Set up the host and listener
The cluster environment on Oracle required you to perform the following actions:
1 Change the HOST parameter to the new host name in the Oracle configuration files
tnsnames.ora and listener.ora. The files are located in the
<oracleHome>\ora1010\network\admin folder.
2 Stop and then restart the listener service.
Create CONTROL-M/EM Gateway cluster resource
CONTROL-M/EM Gateway cluster resources must be defined manually after
installation of CONTROL-M/EM had been completed as the location of
CONTROL-M/Server is not available during the installation.
To create the CONTROL-M/EM Gateway cluster resource
1 Define CONTROL-M/Server definition using the CONTROL-M Configuration
Manager. The Desired State parameter for the gateway must be set to ignored.
2 For each CONTROL-M/Server defined, define a cluster resource for each gateway
component. Create a new "generic application" resource using the details in the
following table:
Chapter 5
Best practices for CONTROL-M/EM
29
Phase 3 Post-installation procedures
Table 1
CONTROL-M/EM Gateway resource definition
Resource
Attribute
CONTROL-M-EM-Gateway (CTM/SRVName)
Description
CONTROL-M/EM Gateway
Resource type
generic application
Group
EM630
Dependencies
CONTROL-M-EM-NuTCRACKER
Command line
<emRoot>\bin\ecs_gtw.exe
-dc dcName
Current directory
<emRoot>\bin
Use network name
Yes (select check box)
Pending timeout
(seconds)
10
NOTE
Before defining the CONTROL-M/EM Gateway cluster resource, the CONTROL-M/Server
should be defined using the CONTROL-M Configuration Manager.
Create a gateway cluster resource for each CONTROL-M/Server that is connected to
CONTROL-M/EM. In the Command line attribute, specify the CONTROL-M/Server name
for the value of the -dc parameter.
Verifying a cluster installation
On each failover node, perform the following steps:
1 Verify that the owner of the CONTROL-M on Microsoft Windows Clusters cluster
group is the primary node on which you installed the Full CONTROL-M on
Microsoft Windows Clusters installation.
2 Open a command prompt and navigate to the <rootFolder>\3rd folder on the
installation DVD or CD.
3 run setup.bat.
4 Restart the computer.
5 Check that the current node of CONTROL-M on Microsoft Windows Clusters
cluster group is online by performing the following steps:
30
CONTROL-M on Windows Clusters
Phase 3 Post-installation procedures
A Issue the Move Group command to move the CONTROL-M on Microsoft
Windows Clusters cluster group to the current node.
B Verify that the disc on which you installed CONTROL-M on Microsoft
Windows Clusters is accessible from this node.
C Issue the Bring Online command to bring the CONTROL-M on Microsoft
Windows Clusters cluster group on this node online and
D Verify that the current node is online in the Windows Cluster Administrator
window.
Install and log on to CONTROL-M/EM client components
1 Ensure that the virtual host name is properly defined in the DNS or host file so it
can be accessed by name or IP address from Microsoft Windows.
2 During installation, enter the virtual host name as the location for the:
■
■
■
CONTROL-M Configuration Server
GUI Server
CORBA Naming Service
3 When logging on to the CONTROL-M/EM GUI, use the virtual host name
configured by the installation to connect to the CORBA Naming repository.
Enter the virtual host name in the Host Name field, which is displayed after clicking
Advanced. This name is resolved by the network and must be identical to the name
configured by the CONTROL-M/EM cluster aware installation.
4 The server name is automatically displayed once the connection to the CORBA
Naming service is established.
5 By default, CONTROL-M/EM client components are configured to reconnect to
the GUI Server upon disconnection. If the failover time of the resource group is
longer than the value for Max reconnection retries times the value for Wait seconds
between reconnection attempts, change the values for these parameters in the
CONTROL-M/EM Reconnection panel of the Options menu.
If the CONTROL-M/EM installation, which is on the cluster machine, is configured
to function in a firewall environment and orbconfigure is activated, the following
commands must be executed from the cluster machine command line to correctly
configure the local CONTROL-M/EM client components. For more information, see
the section on configuring CONTROL-M/EM in a firewall environment in the
CONTROL-M/Enterprise Manager Administrator Guide.
Chapter 5
Best practices for CONTROL-M/EM
31
Phase 3 Post-installation procedures
The change is required because the CORBA configuration on the cluster nodes is
configured to publish the CONTROL-M/EM virtual network name while the
components of these clients run locally.
■
orbadmin variable modify -scope GUI -value "iiop://" -ORBListenEndpoints
■
orbadmin variable modify -scope Desktop -value "iiop://" -ORBListenEndpoint
■
orbadmin variable modify -scope CLI -value "iiop://" -ORBListenEndpoints
■
orbadmin variable modify -scope Sweep -value "iiop://" -ORBListenEndpoints
Running BMC Batch Impact Manager web application under
cluster environment (optional)
This procedure is optional. It is intended only for customers who are licensed to use
BMC Batch Impact Manager (BIM) and have installed BMC Batch Impact Manager in
the cluster environment.
1 Install the web application server on the shared disk where the entire
CONTROL-M/EM installation was installed.
NOTE
Refer to Appendix A for an example of installing Apache Tomcat in a cluster environment.
2 Deploy the BMC Batch Impact Manager web application according to the
instructions provided in the BMC Batch Impact Manager User Guide.
3 Using the Cluster Administrator interface, create the web application server
resource in the CONTROL M/EM resource group (see Appendix A, “Example of
installing Apache Tomcat on Windows clusters”).
4 Bring online the BMC Batch impact Manager and the web application server
cluster resources.
5 Open the web browser and enter the following URL:
http://virtualName:8080/bim
32
CONTROL-M on Windows Clusters
Phase 3 Post-installation procedures
6 Click Advanced.
7 Modify the following field values:
Field
Value
Host
By default, the host name indicates the physical host
name of the cluster node. Replace the default host name
with the CONTROL-M/EM virtual host name.
8 Click Add Host.
9 Click Login to log on to BMC Batch Impact Manager.
Updating BMC Batch Impact Manager and
CONTROL-M/Forecast cluster resources
If BMC Batch Impact Manager or CONTROL-M/Forecast were installed on a cluster,
the cluster resource properties must be changed manually from do not restart to
restart.
To change the cluster resource properties
1 From the cluster administration application, open the BMC-BIM-Server Properties
dialog box or the CONTROL-M-EM-Forecast Properties dialog box as required.
2 Select the restart option button.
3 If you are working on a Windows 2000 cluster, open the BMC Batch Impact Manager
Cluster resource and clear the Use network name check box. If the check box is not
cleared, the BMC Batch Impact Manager process will not start.
Chapter 5
Best practices for CONTROL-M/EM
33
Phase 3 Post-installation procedures
34
CONTROL-M on Windows Clusters
Appendix
A
Example of installing Apache Tomcat
on Windows clusters
A
This appendix provides an example of installing Apache Tomcat version 5.0.28 on
Windows clusters. This version of Apache Tomcat requires JAVA SDK version 1.4.x
or later to be installed on each of the cluster nodes.
NOTE
You can download Apache Tomcat from http://jakarta.apache.org/tomcat.
1 Install Apache Tomcat on each the cluster nodes.
2 Ensure that you are installing the software on the local drive (for example,
D:\Program Files\Apache Software Foundation\Tomcat 5.0).
3 During the installation, select the Service component.
4 When you are prompted for the JAVA virtual machine location, enter the JAVA
SDK installation folder.
5 When the installation is finished, do not start the Apache Tomcat Windows
service.
6 On each of the cluster nodes (TLVD0006, TLVD0007) modify the Apache Tomcat
Windows service to start in Manual mode.
7 Using the Cluster Administrator interface, create the Apache Tomcat resource in
the CONTROL M/EM resource group:
Appendix A
Example of installing Apache Tomcat on Windows clusters
35
Table 2
36
Attributes for the Apache Tomcat resource
Attribute
Value
Resource Name
Apache Tomcat
Description
Apache Tomcat Web Server
Resource Type
generic service
Group
EM630
Dependencies
EM630 - Network Name
Service name
Tomcat5
Use network name
Yes (select check box)
CONTROL-M on Windows Clusters
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A
administering clusters 14
applications 13
architecture 9
domain controllers 9
B
external network 10
BMC Batch Impact Manager 32
BMC Software, contacting 2
F
C
client-to-cluster communications 10
Cluster Administrator interface 14
cluster service 7
cluster-aware applications 13, 19
clustered database configuration 15
clusters
administration 14
architecture 9
dependencies within 14
general 7
Majority Node Set (MNS) 11
multiple nodes 11
Oracle Real Application Cluster (RAC) 16
supported nodes 8
typical two-node architecture 10
cluster-unaware applications 13
control modules 22
CONTROL-M Configuration Manager 25
CONTROL-M/EM Configuration Agent 25
CONTROL-M/Forecast 28
creating IP Address cluster resources 20
creating Network Name cluster resources 19
customer support 3
D
database configurations 15
dependencies in a cluster 14
disappeared reasons
job 21
disappeared workaround
job 21
E
failure of cluster nodes 12
Forecast 28
I
implementing
control modules 22
installation process 25
internal network 10
J
job
disappeared reasons 21
disappeared workaround 21
Job disappearance workaround 21
L
local database configuration 17
logical resources 11
M
Majority Node Set (MNS) clusters 11
managing resources 12
N
network configuration 9
network load balancing (NLB) 8
nodes supported in a cluster 8
Index
37
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
node-to-node communications 10
O
Oracle Real Application Cluster (RAC) 16
P
physical resources 11
private network addresses 10
product support 3
public network addresses 10
Q
quorum resource 12
R
RAC (Real Application Cluster, Oracle) 16
remote database configuration 15, 17
resource dependencies 14
resource groups 12
resources 11
S
server clusters 9
shared disk 10
shared-nothing model 9
split-brain situation 12
storage media 10
support, customer 3
T
TAO CORBA Settings 28
technical support 3
terminology 9
two-node cluster 10
V
virtual servers 13
38
CONTROL-M on Windows Clusters
Notes
*63779*
*63779*
*63779*
*63779*
*63779*
">