Scripting Scheduled Configuration Changes for Cassatt Active Response

Intended for use with Cassatt Active Response Premium Edition and Data Center Edition V5.1.

Can you reliably anticipate daily, monthly, or quarterly capacity demands of the services that run in your data center? If yes, you should take advantage of the Cassatt Active Response scripting SDK to programmatically reconfigure your Cassatt Active Response environment based on your business needs. The Cassatt Active Response scripting SDK provides an interface to many basic Cassatt Active Response operations. (See Cassatt Active Response Scripting SDK Command Reference.) You can combine this scripting capability with standard OS scheduling utilities to completely modify your Cassatt Active Response environment based on well-defined capacity requirements.

This document applies only to tiers that use node-based SLAs. For tiers with load-based SLAs, use the Policy Manager to schedule capacity changes. For more information, see the Policy Manager Users Guide.

ERP example

An engineering resource planning (ERP) system is a good example of software with implicit, scheduled capacity requirements. An ERP system typically provides many services, several of which demand capacity based on business cycles. For example, given an ERP system that provides general ledger and order entry services, let's assume the following:

• The general ledger service is available at all times.
• The general ledger also requires extra compute resources at the beginning of the month to close the books.
• The order entry service requires extra compute resources at the end of the month to finish booking orders.

Using the Cassatt Active Response scripting SDK, you can easily program Cassatt Active Response to reallocate resources from a common pool for beginning-of-the-month or end-of-the-month processing. Let's take a look at how.

top

Script overview

Using the ERP system as an example, I'm going to create a Cassatt Active Response environment that consists of two tiers:

• GeneralLedger tier – Cassatt Active Response will provision this tier with an image of my ERP general ledger software and allocate servers to the tier according to my scripted settings.
• OrderEntry tier – Similarly, Cassatt Active Response will provision this tier with an image of my ERP order entry software and allocate servers to the tier according to my scripted settings.

My configuration goal is to modify my Cassatt Active Response environment so that Cassatt Active Response allocates extra servers to the GeneralLedger tier at the beginning of the month and to the OrderEntry tier at the end of the month. For the rest of the month, I want Cassatt Active Response to allocate fewer servers to each tier, as both have only modest server requirements during that period. To achieve this, I'm going to write 4 scripts:

• tier_setup – While not technically necessary to manage the monthly configuration changes, I'll show you a setup script that configures a Cassatt Active Response environment for the first time. It explains several Cassatt Active Response SDK function calls I'll use in the other scripts.
• GL_begin_month – This script modifies the configuration such that Cassatt Active Response allocates extra servers to the GeneralLedger tier at the beginning of each month.
• OE_end_month – This script modifies the configuration such that Cassatt Active Response allocates extra servers to the OrderEntry tier at the end of the month.
• tier_reset – This script resets the configuration to match the settings in the original setup script. Based on these settings, Cassatt Active Response allocates servers to the two tiers appropriate for their daily capacity demands.

Note that my scripts don't actually have the scheduling logic in them. I'll use standard OS schedulers to handle the scheduling.

top

Setting up variables to simplify the scripts

Most of the Cassatt Active Response scripting SDK functions require the host name, admin user, and admin password of the Cassatt Active Response control node. So, the first thing I do is to set variables so I don't have to enter the details of these arguments in every function call. I'll set up HOST, USER, and PASSWD variables, as follows:

Next, I'll set some variables to modify the tier configuration for my GeneralLedger and OrderEntry tiers. These variables define the resource requirements and software images Cassatt Active Response should apply to these tiers:

top

The actual numbers you enter for operational target, min, and max are a function of the number of nodes in your sever pool and the number of nodes you want Cassatt Active Response to allocate to tiers running the general ledger software. I'm going to manipulate these variables in my scripts and then let Cassatt Active Response allocate servers accordingly. For more information on setting min, max, and operational target values, see Understanding Tier Configuration and Personalization.

After I define the TIER_GL_* variables, I define another set for the OrderEntry tier, only I name them TIER_OE_*.

I'll use some combination of these variables in all of my scripts.

top

Setting up two tiers

After I have set up my helper variables, I can get to the business of creating my Cassatt Active Response tiers for general-ledger and order-entry processing. In my tier_setup script, I'll call the addTier function twice—once for the GeneralLedger tier and once for the OrderEntry tier—and pass in the variables I've set as arguments.

./addTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL} ${TIER_GL_OP} ${TIER_GL_MIN} ${TIER_GL_MAX} ${TIER_GL_IMG} ${TIER_GL_IMGVERSION}
./addTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE} ${TIER_OE_OP} ${TIER_OE_MIN} ${TIER_OE_MAX} ${TIER_OE_IMG} ${TIER_OE_IMGVERSION}

These tiers are not operational until my script activates them, but before I do that, I want to set a handful of properties for how Cassatt Active Response should manage the servers it allocates to the tiers. I use setTierHarvestable, setTierRebootOnFailure, setTierAutoMoveToMaint, and setTierHarvestPriority as follows:

#
# setTierHarvestable indicates to Collage whether or not it is allowed to
# harvest nodes from the named tier. Setting to true means it is okay for
# Collage to reallocateservers to tiers that require more capacity.
# Note that Collage never harvests nodes such that the tier runs with
# less that its minimum.
#
./setTierHarvestable.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL} true
./setTierHarvestable.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE} true

#
# setTierRebootOnFailure sets a flag on the tier that indicates Collage
# should reboot nodes in the tier if they fail before replacing them.
#
./setTierRebootOnFailure.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL} true
./setTierRebootOnFailure.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE} true

#
# setTierAutoMoveToMaint sets a flag on the tier indicating that Collage
# should automatically move a failed node to the maintenance pool.
#
./setTierAutoMoveToMaint.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL} true
./setTierAutoMoveToMaint.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE} true

#
# setTierHarvestPriority sets the tier harvest priority. Setting to low
# means that the tier is low priority, relative to other tiers, and that it
# is okay for Collage to harvest servers from this tier. Setting to high
# means that the tier is high priority, relative to other tiers.
# Collage is less likely to harvest servers from this tier.
#
./setTierHarvestPriority.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL} medium
./setTierHarvestPriority.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE} medium

After I set these properties on the tiers, I allocate (that is, have Collage assign nodes to) and activate the tiers:

./allocateTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL}
./allocateTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE}

./activateTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_GL}
./activateTier.sh ${HOST} ${USER} ${PASSWD} ${TIER_OE}

See the complete tier setup_shell script.
See the complete tier_setup batch file.

top

This script establishes two running tiers, as in the following illustration:

Increasing capacity at the beginning of month

My tier_setup script gets my GeneralLedger and OrderEntry tiers up-and-running. Next, I want to create a script to modify the operational parameters of the GeneralLedger tier to increase the number of servers used. My GL_begin_month script looks like this:

#
# Create a new variable to increase the operational target number
# of nodes that Collage should allocate to the GeneralLedger tier.
# Also, ensure that the OrderEntry tier is set for daily operations.
#
TIER_GL_NEW_OP=4
TIER_OE_NEW_OP=1

#
# setOpTarget sets the operational target for the named tier.
#
./setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_GL} ${TIER_GL_NEW_OP}
./setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_OE} ${TIER_OE_NEW_OP}

#
# Setting the harvest priority to high for the GeneralLedger tier means it
# is unlikely that Collage will harvest servers from this tier and
# reallocate them to other tiers. It also means that this tier is more
# likely to be allocated a node if it needs one than a medium or low
# priority tier.
#
./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_GL} high
./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_OE} medium

See the GL_begin_month shell script.
See the GL_begin_month batch file.

After running the GL_begin_month script, Cassatt Active Response attempts to allocate available servers until the operational targets are achieved. The end result resembles the following illustration:

top

Increasing capacity at the end of month

Making the OE_end_month script to modify the operational target on the OrderEntry tier is simply a variation of the previous script:

#
# Create new variables used to modify the operational target number
# of nodes that Collage should allocate to the OrderEntry and
# GeneralLedger tiers.
#
TIER_OE_NEW_OP=4
TIER_GL_NEW_OP=2

#
# Setting the harvest priority to high for the OrderEntry tier means it is
# unlikely that Collage will harvest servers from this tier and reallocate
# them to other tiers. It also means that this tier is more
# likely to be allocated a node if it needs one than a medium or low
# priority tier.
#
./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_GL} medium
./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_OE} high

#
# Sets the operational target for the named tier.
#
./setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_GL} ${TIER_GL_NEW_OP}
./setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_OE} ${TIER_OE_NEW_OP}

See the OE_end_month shell script.
See the OE_end_month batch file.

Again, after this script runs and changes the operational target, Cassatt Active Response attempts to allocate available servers until the operational targets are achieved. The result is that the OrderEntry tier is allocated additional servers. The results look like this:

top

Resetting Cassatt Active Response for daily use

Now that I have my GL_begin_month and OE_end_month scripts, I just need one more. I'll call this one tier_reset, and I'll run it after the first week of the month to reallocate servers to the GeneralLedger and OrderEntry tiers for typical, daily capacity requirements as I defined them in the original tier_setup script.

#
# Set operational targets to match the values in the setup script.
#
TIER_GL_NEW_OP=2
TIER_OE_NEW_OP=1

setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_GL} ${TIER_GL_NEW_OP}
setOpTarget ${HOST} ${USER} ${PASSWD} ${TIER_OE} ${TIER_OE_NEW_OP}

./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_GL} medium
./setTierHarvestPriority ${HOST} ${USER} ${PASSWD} ${TIER_OE} medium

See the tier_reset shell script.
See the tier_reset batch file.

top

Scheduling script execution with crontab

For the Linux savvy, crontab is well known for its ability to schedule system actions. Simply use crontab -e to edit the crontab file and add these lines (which assume the scripts are in /usr/local):

      0 1 1 * * /usr/local/GL_begin_month.sh
      0 1 7 * * /usr/local/tier_reset.sh
      0 1 26 * * /usr/local/OE_end_month.sh

• The first line indicates that the GL_begin_month script will be executed the 1st day of every month at 1:00 a.m.
• The second line indicates that the tier_reset script will be executed the 7th day of every month at 1:00 a.m. This effectively returns the tiers to normal operations.
• The third line indicates that the OE_end_month script will be executed the 26th day of every month at 1:00 a.m. This configuration will be in effect until the GL_begin_month script is executed again on the 1st.

You can similarly schedule to run batch files from a Windows computer. Open the Control Panel and select Scheduled Tasks. That launches a wizard from which you can schedule your batch files to run. In addition to using Windows task scheduler, you can also use the Schtasks.exe command-line utility to schedule commands and programs to run periodically or at a specific time.

top

Conclusion

I've focused on scripts that modify the Cassatt Active Response environment to handle different workloads based on well-understood capacity demands and I've used standard OS schedulers to activate those scripts. Using the Cassatt Active Response scripting SDK like this is a great way to programmatically and dynamically react to capacity demands based on business cycles. I've implicitly leveraged Cassatt Active Response's ability to pool resources and allocate servers based on user-defined policies such as the operational target number of servers I want allocated to a service. Besides achieving automation and providing better service, I've also reduced the capital costs of my data center because I no longer require a dedicated stack of servers for each software application in my ERP system. (Each of these applications is typically provisioned for peak capacity, which means there are often servers sitting idle until required at the beginning or end of the month.) So, with all those benefits, there's no time like now to start scripting configuration changes for your own Cassatt Active Response environment.

top

Was this article useful? Tell us what you think.
Email infocentral@cassatt.com.