This past May Cassatt announced availability of demand-based policies, which monitor the changing demand on servers and automatically turn them off when they become idle.

The technical publications team is pleased to follow up with the details: what exactly do these policies do, and how do you configure them.

Briefly: demand-based policies allow you to measure load on your servers using a protocol that is relevant for your application. Cassatt Active Response compares the measurements with your preset optimal service levels, then adds or removes servers to optimize for your goals. In the software and the docs, we call these demand-based policies "load-based SLAs."

Node-based SLAs continue to work as usual for those who prefer to specify capacity in number of nodes, but we've added the ability to deactivate an application tier when servers are idle for a specified period of time. The new "idle timer" (also available with load-based SLAs) lets you save on power over nights and weekends when servers aren't being used.

To read about improvements to node-based SLAs, and our new load-based SLAs, see Tier Configuration and Personalization, and look for the section entitled "SLA."

As our customers scale out their Cassatt Active Response environments, we're finding that a beefier control node is a must for optimum performance. To meet this need, we have upgraded our minimum control node specs to support a configuration with 400 tiers, 400 image-managed nodes, and 400 images. A control node that meets this scalability requirement will work for Cassatt Active Response Standard Edition, and can easily be transitioned to support Premium Edition or Data Center Edition. The new specifications are listed in the control node setup documentation:

• Single control node
• Dual control nodes

We've seen some support calls where Cassatt Active Response was not auto-discovering servers that were otherwise correctly configured. Turns out that the control node , which you'll remember acts as a DHCP server, had run out of IP addresses. So, the control node fielded the server's DHCP request, but couldn't do anything about it. The visible result was that the server did not get placed in the Cassatt Active Response discovered pool.

Remember that your network address calculation is an important one: you might want to review the related docs: Network Addresses: Calculating Requirements.

Hopefully, with some up-front thought put into Cassatt's networking requirements you can avoid these types of failures.

Labels: automatic discovery IP address range

Our recent project work and lab investigations have led us to make a couple of significant changes to our recommended control node configuration that you should be aware of. In summary:

• Control node operating system is now Red Hat ELAS 4 Update 5.
• Control node recommended memory is now 2 Gbytes.

For the inquisitive, here's a little background on these changes.

First, it turns out there was a bug in Red Hat 4U4 that we were able to reproduce reliably with application nodes running Solaris x86. We just recently added the Solaris x86 support to the Cassatt Active Response product, so we upped the required control node OS revision to Red Hat 4 Update 5 at the same time.

Second, Cassatt Active Response now configures the Java VM it runs in with 1 Gbyte of heap, so we're increasing the minimum memory requirement on the control node to 2 Gbytes. This should minimize any possible memory issues with the system.

Labels: Cassatt Active Response, control node operating system, memory requirements

We've recently introduced a new programmatic interface to Cassatt Active Response—the Cassatt Event Registration Interface, or CERI. Cassatt Active Response tracks all kinds system events in its environment. Using CERI, you can access this event stream and trigger other, automated actions in your environment. Say, for example, you want to populate a site CMDB with inventory data collected by Cassatt Active Response or to communicate with load balancing software to modify application node configuration. You can write a CERI client program to gather event data from the Cassatt event stream and use that information to automate other actions in the Cassatt Active Response environment.

CERI is distributed as a set of Java library classes and methods needed to register and authenticate requests from a calling application. CERI is available on the Cassatt Active Response distribution media as a JAR file. You simply place the JAR where you want your client program to run, ensure the JAR is in the classpath, and execute your client program.

If you're interested in giving CERI a try, take a look at this recently published article: Cassatt Event Registration Interface (CERI): Writing Client Programs for Use With Cassatt Active Response.

Labels: Cassatt Event Registration Interface CERI

We've just updated the site with new documentation you might be interested in:

• Sun RSC power controllers - Cassatt Active Response now manages Sun servers via their Remote System Control (RSC) interface. For more info, see Application Node Setup: Sun.
• SSDK - We've added a few new functions:
• startTierPersonalization() and completeTierPersonalization(), which support more sophisticated scripted automation activities.
• listFreeIPs() and reserveFreeIPs(), which provide a scripted way to identify and reserve IPs in the Cassatt Active Response environment.
• addCustomAttributeToTier(), which provides a scripted way to set a custom attribute on a specified tier. For the updated function descriptions, see the Scripting SDK Command Reference.

Labels: Cassatt Active Response Sun RSC power SSDK

If you're looking through Info Central, it probably won't take long to encounter a reference to Cassatt Active Response's discovery capability. This is the process by which Cassatt Active Response identifies and catalogs 1) a server's power controller and 2) the accompanying application server for use in the CAR environment.

Many systems provide some means of discovering resources and assets in their particular environment, but these frequently involve installing some kind of software agent across the environment to facilitate the discovery process. Cassatt Active Response, however, does not require any special agents. Rather, it only requires some configuration on the servers in the environment to enable already installed and available technologies (namely, DHCP and PXE). Once these are enabled, CAR discovery accounts for on-board power controllers and their accompanying application servers (including power controllers that service multiple servers in a blade enclosure.

One of the things that can be a little confusing is the difference between automatic and manual discovery:

• Automatic Discovery - With automatic discovery enabled, CAR discovers both the power controller (via its DHCP requests) and then the accompanying application node. This is a hands-off activity.
• Manual Discovery - With manual discovery (automatic discovery is disabled), you manually enter configuration data about the power controller (e.g., its IP address or MAC address) directly into the CAR controller. CAR then goes on to discover the accompanying application node.

So, except in rare circumstances, CAR discovers the application nodes whether you use automatic or manual discovery.

We probably tend to overload the term "discovery," so I'll try to follow this up with another entry or two and give more detail about how discovery works in Cassatt Active Response.

Labels: automatic discovery, manual discovery