AppDynamics Application Intelligence Platform

3.8.x Documentation

PDFs

Videos

Release Notes

Skip to end of metadata
Go to start of metadata

This topic describes how to use scripts provided by AppDynamics to perform failover and failback operations for your AppDynamics Controller. It provides a simpler alternative to the manual failover and failback procedures described at Controller HA Failover and Failback Process.

It assumes that you have already provisioned a primary and secondary controller in High Availability (HA) mode. For information on how to do this see Provisioning Controllers in High Availability Mode by Script. It also assumes that you also have a provisioning server, which has SSH access to both controller machines, from which to run the scripts.

Failover is the operation to perform if the primary controller experiences a failure; it switches all operations to your secondary controller on the backup machine. Failback is the operation that switches operations from the secondary controller back to the primary controller after the primary controller has been restored.

Failover and Failback Scripts

AppDynamics provides a set of scripts that you can run to perform failover and failback. To acquire the scripts needed to perform this configuration, contact AppDynamics Support

The scripts that you run directly are:

  • failover.sh: to perform failover
  • failback.sh: to perform failback

These two scripts invoke the other scripts to perform support tasks.

These scripts do not handle switching traffic between the primary and secondary controllers. See Moving Traffic between Controllers for information on how to do this.

Failover Script

This script performs the following tasks:

  1. Stops traffic to the primary controller.
  2. Sets the primary controller to passive mode.
  3. Turn off replication.
  4. Records where the primary controller last stopped replicating.
  5. Stops the controller on the primary machine.
  6. Makes the secondary controller the active controller.
  7. Directs traffic to the secondary controller.

To Failover

  • Run failover.sh from the provisioning server to failover from the primary to the secondary controller.

Failback Script

This script performs the following tasks:

  1. Stops traffic to the secondary controller.
  2. Sets the secondary controller to passive mode.
  3. Turn off the database on the primary controller and lets it replicate from the secondary controller until the primary controller has all the data collected since the failover.
  4. Sets up replication again.
  5. Makes the primary controller the active controller so that it can receive traffic.
  6. Directs traffic to the primary controller

To Failback

  • Run failback.sh from the provisioning server to failback from the secondary to the primary controller after the primary controller has been restored.

Moving Traffic between Controllers

To move traffic between controllers, choose from the common options listed below:

Based on the option you choose, make the appropriate changes to the failover and failback scripts.

Using Virtual IP (VIP)

To use the VIP approach, assign a single IP which can be grabbed and released by either machine. During failover, the machine with the primary controller releases the VIP and the machine with the secondary controller takes it by binding it to eth1.

You implement this solution using the Linux ifup and ifdown commands.

Using a Load Balancer

To use the load balancer approach, point agent and UI traffic to a loadbalancer IP which then redirects the traffic to the active controller

During failover, you can manually direct the loadbalancer to switch traffic to the other controller.

Modifying and Testing the Scripts

To Modify and Test the Scripts

Modify the scripts as needed and then test them.

  1. Edit the export entries in setup.sh with the information for your own environment.
  2. Edit the failover.sh script as needed based on your failover strategy.
    At the start of the script, stop traffic to the primary controller. At the end of the script, direct traffic to the secondary controller.
  3. Edit the failback.sh script as needed based on your failback strategy. At the start of this script, stop traffic to the secondary controller. At the end of the script, direct traffic to the primary controller.
  4. Test these scripts simulating a failover and failback to make sure everything works as expected.
     
    Then just execute failover.sh and failback.sh when needed.

Learn More