1.2.1 Meeting the Prerequisites

The environment where PlateSpin Orchestrate Server is installed must meet the hardware and software requirements for high availability. This section includes the following information to help you understand those requirements.

1.2.2 Installing the High Availability Pattern for SLES 10

The high availability install pattern is included in the distribution of SLES 10 SP2. Use YaST2 (or the command line, if you prefer) to install the packages that are associated with the high availability pattern to each physical node that is to participate in the PlateSpin Orchestrate cluster.

The packages associated with high availability include:

For more information, see Installing and Removing Software in the SLES 10 Installation and Administration Guide.

1.2.3 Configuring Nodes with Time Synchronization and Installing Heartbeat 2 to Each Node

When you have installed the high availability packages to each node of the cluster, you need to configure the Network Timing Protocol (NTP) and Heartbeat 2 clustering environment on each physical machine that participates in the cluster.

Configuring Heartbeat 2

Heartbeat 2 is an open source server clustering system that ensures high availability and manageability of critical network resources including data, applications, and services. It is a multinode clustering product for Linux that supports failover, failback, and migration (load balancing) of individually managed cluster resources.

Heartbeat 2 packages are installed with the high availability pattern on the SLES 10 SP2 install source. For detailed information about configuring Heartbeat 2, see the installation and setup instructions in the SLES 10 Heartbeat Guide.

An important value you need to specify in order for Heartbeat 2 to be enabled for high availability is configured in the Default Action Timeout field on the settings page of the Heartbeat 2 console (hb_gui).

Figure 1-2 The Main Settings Page in the Heartbeat 2 Graphical Interface

The value in this field controls how long Heartbeat 2 waits for services to start. The default value is 20 seconds. The PlateSpin Orchestrate Server requires more time than this to start. We recommend that you specify the value in this field at 120s. More time might be required if your PlateSpin Orchestrate grid is very large.

1.2.4 Setting Up OCFS2

OCFS2 is a general-purpose journaling file system that is fully integrated in the Linux 2.6 and later kernel that ships with SLES 10 SP2. OCFS2 allows you to store application binary files, data files, and databases on devices in a SAN. All nodes in a cluster have concurrent read and write access to the file system. A distributed lock manager helps prevent file access conflicts. OCFS2 supports up to 32,000 subdirectories and millions of files in each directory. The O2CB cluster service (a driver) runs on each node to manage the cluster.

To set up the high availability environment for PlateSpin Orchestrate, you need to first install the High Availability pattern in YaST (this includes the ocfs2-tools and ocfs2console software packages) and configure the Heartbeat 2 cluster management system on each physical machine that participates in the cluster, and then provide a SAN in OCFS2 where the PlateSpin Orchestrate files can be stored. For information on setting up and configuring OCFS2, see the Oracle Cluster File System 2 section of the SLES 10 Administration Guide.

1.2.5 Installing and Configuring PlateSpin Orchestrate on the First Clustered Node

This section includes information about installing the Orchestrate Server components, configuring those components using two possible methods, and then checking the configuration:

1.2.6 Running the High Availability Configuration Script

Before you run the high availability configuration script, make sure that you have installed the PlateSpin Orchestrate Server to a single node of your high availability cluster. For more information, see Section 1.2.5, Installing and Configuring PlateSpin Orchestrate on the First Clustered Node.

The high availability script, zos_server_ha_post_config, is located in /opt/novell/zenworks/orch/bin with the other configuration tools. You need to run this script on the first node of the cluster (that is, the node where you installed PlateSpin Orchestrate Server) as the next step in setting up PlateSpin Orchestrate to work in a high availability environment.

The script performs the following functions:

The high availability configuration script must be run on all nodes of the cluster. Make sure that you follow the prompts in the script exactly; do not misidentify a secondary node in the cluster as the primary node.

1.2.7 Installing and Configuring Orchestrate Server Packages on Other Nodes in the Cluster for High Availability

After you have followed the steps to set up the primary node in your planned cluster, you need to set up the other nodes that you intend to use for failover in that cluster. Use the following sequence as you set up other cluster nodes (the sequence is nearly identical to setting up the primary node):

1.2.8 Creating the Cluster Resource Group

The resource group creation script, zos_server_ha_resource_group, is located in /opt/novell/zenworks/orch/bin with the other configuration tools. You can run this script on the first node of the cluster to set up the cluster resource group. If you want to set up the resource group using Heartbeat 2 (GUI console or command line tool), running the script is optional.

The script performs the following functions:

The zos_server_ha_resource_group script prompts you for the IP address of the Orchestrate Server cluster. The script then adds this address to a Heartbeat 2 Cluster Information Base (CIB) XML template called cluster_zos_server.xml and uses the following command to create the cluster resource group:

/usr/sbin/cibadmin -o resources -C -x $XMLFILE

The CIB XML template is located at /opt/novell/zenworks/orch/bin/ha/cluster_zos_server.xml. An unaltered template sample is shown below:

<group id="ZOS_Server">
    <primitive id="ZOS_Server_Cluster_IP" class="ocf" type="IPaddr2" provider="heartbeat">
        <instance_attributes>
            <attributes>
                <nvpair name="ip" value="$CONFIG_ZOS_SERVER_CLUSTER_IP"/>
            </attributes>
        </instance_attributes>
    </primitive>
    <primitive id="ZOS_Server_Instance" class="lsb" type="novell-zosserver" provider="heartbeat">
        <instance_attributes id="zos_server_instance_attrs">
            <attributes>
                <nvpair id="zos_server_target_role" name="target_role" value="started"/>
            </attributes>
        </instance_attributes>
        <operations>
            <op id="ZOS_Server_Status" name="status" description="Monitor the status of the ZOS service" interval="60" timeout="15" start_delay="15" role="Started" on_fail="restart"/>
        </operations>
    </primitive>
    <primitive id="Apache2" class="lsb" type="apache2" provider="heartbeat">
        <instance_attributes id="apache_attr">
            <attributes>
                <nvpair id="apache2_target_role" name="target_role" value="started"/>
            </attributes>
        </instance_attributes>
        <operations>
            <op id="Apache2_Status" name="status" description="Monitor the status of Apache2" interval="120" timeout="15" start_delay="15" role="Started" on_fail="restart"/>
        </operations>
    </primitive>
    <primitive id="Gmetad" class="lsb" type="novell-gmetad" provider="heartbeat">
        <instance_attributes id="gmetad_attr">
            <attributes>
               <nvpair id="gmetad_target_role" name="target_role" value="started"/>
            </attributes>
        </instance_attributes>
        <operations>
            <op id="Gmetad_Status" name="status" description="Monitor the status of Gmetad" interval="300" timeout="15" start_delay="15" role="Started" on_fail="restart"/>
        </operations>
    </primitive>
    <primitive id="Gmond" class="lsb" type="novell-gmond" provider="heartbeat">
        <instance_attributes id="gmond_attr">
            <attributes>
                <nvpair id="gmond_target_role" name="target_role" value="started"/>
            </attributes>
        </instance_attributes>
        <operations>
            <op id="Gmond_Status" name="status" description="Monitor the status of Gmetad" interval="300" timeout="15" start_delay="15" role="Started" on_fail="restart"/>
        </operations>
    </primitive>
</group>

The template shows that a cluster resource group comprises these components:

When you have installed and configured the nodes in the cluster and created a cluster resource group, use the Heartbeat 2 tools to start the cluster resource group. You are then ready to test the failover of the PlateSpin Orchestrate Server in the high-availability cluster (see Section 1.2.9, Testing the Failover of the PlateSpin Orchestrate Server in a Cluster).

1.2.9 Testing the Failover of the PlateSpin Orchestrate Server in a Cluster

You can optionally simulate a failure of the Orchestrate Server by powering off or performing a shutdown of the server. After approximately 30 seconds, the clustering software detects that the primary node is no longer functioning, binds the IP address to the failover server, then starts the failover server in the cluster.

Access the PlateSpin Orchestrate Administrator Information Page to verify that the Orchestrate Server is installed and running (stopped or started). Use the following URL to open the page in a Web browser:

http://DNS_name_or_IP_address_of_cluster:8001

The Administrator Information page includes links to separate installation programs (installers) for the PlateSpin Orchestrate Agent and the PlateSpin Orchestrate Clients. The installers are used for various operating systems.

1.2.10 Installing and Configuring other PlateSpin Orchestrate Components to the High Availability Grid

To install and configure other PlateSpin Orchestrate components (including the Orchestrate Agent, the Monitoring Agent, the Monitoring Server, or the VM Builder) on servers that authenticate to the cluster, you need to do the following:

It is important to understand that virtual machines under the management of PlateSpin Orchestrate are also highly available—the loss of a host causes PlateSpin Orchestrate to re-provision it elsewhere. This is true as long as the constraints in PlateSpin Orchestrate allow it to re-provision (for example, if the virtual machine image is on shared storage).