Understanding Storage Management in Cassatt Active Response

Intended for use with Cassatt Active Response V5.0.

Cassatt Active Response places a few requirements on your storage subsystem and provides a range of possibilities in how you divvy up storage. In this article, I'll discuss the storage requirements and options available in Cassatt Active Response, describe the general setup, and give you some practical advice on how to maximize storage use to satisfy some common site requirements and to take full advantage of Cassatt Active Response.

Overview

Cassatt Active Response has been enhanced such that it can take advantage of a wider range of storage configurations than previous versions. Specifically, this version of Cassatt Active Response removes the restriction that Cassatt Active Response software and supporting files all reside on one file system. This new flexibility provides several benefits:

• It fits better with site policies that mandate or cap file system sizes, which are sometimes enforced to streamline the backup process.
• It supports the ability to isolate applications on their own file systems, which may be desirable for a couple of reasons:
  • To prevent problems presented by one application from adversely affecting another application.
  • To enable restoring applications from backup in a priority order (e.g., you may want to bring up a high-priority application from backup before a low-priority application).
• It simplifies the process to add storage to a running Cassatt Active Response environment.

I'll go over each of these in more detail later, but first, let's review the Cassatt Active Response storage requirements.

top

Cassatt Active Response storage requirements

In a small Cassatt Active Response configuration in a lab or prototype setting, you can configure Cassatt Active Response entirely on a control node's local disk. However, in production environments, Cassatt strongly recommends you use an enterprise-level storage solution like a NAS or SAN. In these environments, Cassatt Active Response has two distinct requirements for access to your storage subsystem:

• Access to a dedicated raw device that is used to support failing over from one control node to another. I've captured this topic in Understanding Control Node Failover and Configuring Storage Access, so I'm not going to go into detail about it here.
• Access to storage that holds Cassatt Active Response system data, software, database, and application images. This is the stuff I'm going to focus on in this article. In the recommended dual-control node configuration, I'll refer to this as the shared storage, since it's available to both control nodes.

top

Storage hardware

As I've already mentioned, Cassatt recommends using a NAS or SAN as your storage solution (for more information, see Understanding Storage Hardware Options). That said, be aware that you can't use both at the same time. For example, you can't put one partition on a SAN and another partition on a NAS.

I'm not going to give you much detail on setting up your storage device. I assume you've got a handle on that. However, in the related Cassatt Active Response storage setup documentation, I do try to call out any specifics required to set up NAS or SAN correctly for a Cassatt Active Response environment.

top

Cassatt Active Response shared storage

Cassatt Active Response minimally requires two partitions on the shared storage device (above and beyond that dedicated raw device that I mentioned is required for failover). These required partitions are used to host the:

• Cassatt Active Response base file system
• Cassatt Active Response database file system

The Cassatt Active Response base file system includes Cassatt Active Response system data, software, and application images. This file system is visible via the symbolic link, /cassatt, as highlighted in the next illustration:

The Cassatt Active Response database file system predominantly includes the database, but as shown in the next illustration, it also includes Cassatt Active Response configuration files. This file system is visible via the symbolic link, /cassatt/database.

The Cassatt Active Response base and database file systems are required, but you can also set up additional partitions for use by Cassatt Active Response. Later I'll talk about some of the storage customizations you might want to consider in a Cassatt Active Response implementation.

top

Adding storage to Cassatt Active Response

You must have the two required file systems available when you install Cassatt Active Response. You may specify more during the Cassatt Active Response installation, or you can add storage capacity to a running Cassatt Active Response system. Either way, the setup procedure is similar. The next table outlines the general steps to configure Cassatt Active Response shared storage and make it available for Cassatt Active Response:

Because Cassatt Active Response creates the symbolic link /cassatt, you cannot use /cassatt or any subdirectory of /cassatt as a mount point. That said, I advise creating descriptive mount points for the disk partitions you want to be available in Cassatt Active Response. Doing so will make it a lot clearer downstream when users are determining what storage locations to use for application or service images.

top

Distributed file system support

One of the key benefits of the way Cassatt Active Response interfaces with your storage subsystem is that Cassatt Active Response maintains a single view of the Cassatt Active Response image matrix and WebLogic Feature Pack service matrix, while allowing those images and services to be distributed across multiple file systems. The fact that you can distribute images and services across multiple file systems suggests some interesting possibilities, so let's discuss some of the ways you might want to customize your storage subsystem for use with Cassatt Active Response. In the process, I'll show you more explicitly how Cassatt Active Response supports distributed file systems.

top

Customizing use of your storage

Although Cassatt Active Response only requires that you provide partitions for the Cassatt Active Response base and Cassatt Active Response database file systems, it allows you to extend use of your storage subsystem as you see fit. In the Cassatt Active Response environment, you might specifically want to consider customizing use of your storage subsystem to accommodate the Cassatt Active Response image matrix and service matrix. These are potentially complex concepts. So as not to lose my focus too much, I'll just define them as follows:

• Image matrix—a repository that contains application images that Cassatt Active Response manages.
• Service matrix—a repository that contains WebLogic Feature Pack services and WebLogic Feature Pack service images.

As suggested in the following illustration, Cassatt Active Response creates the image matrix on the base file system, and when the WebLogic Feature Pack is installed, it creates the service matrix on the base file system:

When configuring storage for Cassatt Active Response, make sure to allocate both enough space and enough inodes to accommodate images in the image matrix. If there is insufficient space or number of inodes for the image matrix, Cassatt Active Response performance will degrade. Cassatt Active Response does, however, warn you if any configured file system is running short of disk space, running short of inodes, or is no longer writable.

The image matrix and service matrix are potentially large disk consumers, and they represent the applications and services Cassatt Active Response is going to manage. Following are some good reasons to consider allocating them to their own disk partitions:

• To optimize backup and restore
• To isolate an application on its own file system
• To consolidate groups of applications and services on their own file system
• To prevent large image operations from affecting Cassatt Active Response performance

Let's look at these more closely.

top

Optimizing backup and restore

I'll treat these separately, as the practical use case for each is unique.

Backup

It's not unusual to have a site policy that mandates the size of file systems in use strictly for the purpose of streamlining the backup procedures. For example, say your site caps file system size to some number of Gbytes so that no one backup takes an inordinate amount of time or space. If your site is similarly prescriptive in the size of file systems that can be used, then simply define your storage partitions accordingly and add them to Cassatt Active Response. (Remember, you can add file systems to Cassatt Active Response at installation time, or you can add capacity later via the Controller.)

Restore

In preparing your disaster recovery plan, you may want to ensure that your most important, mission critical applications are restored before any others. Because business applications are stored as images in the Cassatt Active Response image matrix, you can designate where on your storage subsystem you want to store them. (Images are stored by default in the Cassatt Active Response base file system.) For example, say you wanted to isolate your Oracle database for this purpose. As shown in the next illustration, you could put a mission critical application like Oracle on its own file system:

By placing mission critical applications on their own file systems, you can orchestrate the system recovery based on the criticality of your business applications; if you are in the unenviable situation of recovering from a disaster, you can bring the system back up in priority order.

top

Isolating applications

The previous example—putting a high priority business application on its own file system to make sure you can restore it before any others—is one example of isolating an application on your storage subsystem. There is at least one other reason to do this. Do you have troublesome applications that are prone to fill up or corrupt the file system? If so, these are excellent candidates to isolate on their own disk partitions. That way, you can prevent any problems they might cause from affecting other applications.

top

Consolidating groups of applications

There might be cases where, rather than isolate an application on its own file system, it makes sense to consolidate a group of applications together. (Again, doing so might expedite your backup and restore, or it might just simplify day-to-day system management of those applications.) Say you are using Cassatt's WebLogic Feature Pack with WebLogic 8.1. You could consolidate your WebLogic Feature Pack services and service images on the same partition as WebLogic. For example, in the next illustration, the petstore_prod service definition and petstore service image are distributed on the same file system as the supporting WebLogic 8.1 application image. The result is that all the application components are consolidated on a single file system:

With this storage configuration, you can bring up all the necessary components of the WebLogic Feature Pack implementation at one time in the case of a restore scenario.

top

Avoiding resource contention with Cassatt Active Response

Some image operations—for example, duplicating an image or creating a new version—can be resource intensive. During these operations, Cassatt Active Response services could slow down because of competition for system resources. An easy way to prevent this is to store images on their own file systems, thus avoiding contention on the Cassatt Active Response base file system.

top

Cassatt Active Response user interfaces to the storage subsystem

Cassatt Active Response provides the following interfaces to allocate application and service images to specific storage volumes:

• ccinstall—used to install Cassatt Active Response; it prompts for the two required storage partitions—for the Cassatt Active Response base and Cassatt Active Response database file systems—and lets you specify others if they have been configured.
• cccapture—used when initially capturing an application image and bringing it under Cassatt Active Response control.
• ccimport—used when importing a pre-existing image that was saved with the ccexport command.
• ccservicecapture—used when initially capturing a WebLogic Feature Pack service image and bringing it under Cassatt Active Response control.
• ccserviceconfigure—used when initially configuring a WebLogic Feature Pack service for use in Cassatt Active Response.

When using these utilities, you are prompted to select the disk partition to use. (See a sample of the command-line prompts for file system information.) If you are extending use of your storage subsystem beyond the two required partitions, you'll want to be familiar with that storage strategy so you can match images and services to the appropriate disk partitions. (This is where it is helpful to have descriptive names for storage volumes or mount points. If you're customizing use of your storage subsystem, descriptive names for storage volumes or mount points make it a lot more obvious where a user should store an image or service.)

The Controller also provides an interface to the storage subsystem. After Cassatt Active Response has been installed, use the Controller as the primary interface for adding or removing file systems to Cassatt Active Response. (See a sample of the Controller UI page.)

After an application image is allocated to a file system, you can't simply move it to another file system. To achieve this, you would need to create a new version of the application image, allocate it to the new file system, and update all tiers running that application to use the new image.)

top

Related docs

This article is meant to be an introduction to managing the storage subsystem for your Cassatt Active Response implementation. I recommend you review the other related documentation before diving too deep into your setup:

• Understanding Storage Hardware Options—describes optimal hardware storage configurations coupled with Cassatt Active Response's use of NFS.
• Understanding Control Node Failover—describes particularly how a common storage device is used to support control node failover.
• Cassatt Active Response File System Layout—shows where common and important files are stored by default after a Cassatt Active Response installation.
• Storage Space: Calculating Requirements—describes factors to consider when planning storage space needs for your Cassatt Active Response implementation and shows various formulas to use to calculate that space.
• Control Nodes: Configuring Storage Access—describes setting up both shared storage and failover storage. For the former, this document specifies the storage mount options to use in the /etc/fstab file on the control nodes.
• Control Node: Install Cassatt Active Response—describes the installation script, including the prompts to identify the two required disk partitions and any extra partitions you want Cassatt Active Response to use.

top

Conclusion

I've covered a lot of ground here, so let me leave you with a summary of key points:

• Cassatt Active Response software and the Cassatt Active Response database are now separated on their own file systems.
• The Cassatt Active Response image matrix and WebLogic Feature Pack service matrix provide a single view of application images and service images, but those images can be distributed across multiple file systems.
• Consider customizing use of your storage subsystem with Cassatt Active Response to:
• Optimize backup/restore
• Isolate applications on their own file system
• Consolidate related applications on their own file system

These storage capabilities in Cassatt Active Response give you quite a bit of flexibility to extend use of your storage subsystem and greatly simplify the process to add storage capacity to a running Cassatt Active Response system, so the criticality of your initial planning is lessoned a bit. However, there are a lot of factors to consider in your overall storage strategy, so do your work up-front and then add or remove capacity to your running system as conditions change.

top

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