Understanding Image Creation and Capture
Intended for use with Cassatt Active Response Premium Edition and Data Center Edition V5.1.
This article describes the process for creating and capturing images of your enterprise applications. It also provides some guidelines and best practices.
This article is recommended reading prior to using an application blueprint. Blueprints contain steps similar to those described in this article, but are specific to the application. If you're not using a blueprint, use the steps in the article to guide you.
This article assumes you have a basic understanding of images and image instances as described in: Cassatt Active Response Basic Concepts and Cassatt Active Response Sample Implementation.
High-level steps
To prepare applications to be managed as images in the Cassatt Active Response image matrix, you must understand your applications, how they work, and what they need to function properly. You'll use Cassatt Active Response image tools to set parameters that help determine how fast the application image boots, and how it operates when it's running in a tier. The following table shows the high-level steps for getting applications running in the Cassatt Active Response environment.
Steps |
Task |
Install and configure applications |
On an application node that you temporarily designate as an image host, you create an application image by installing the operating system and enterprise applications, and configuring the software for the Cassatt Active Response environment.
|
Capture the application image |
From the control node, you'll run an interactive command line tool (cccapture) to capture a base image, along with special settings that determine how Cassatt Active Response should manage it. After you complete the cccapture interview, the base image is copied from the image host into the image matrix.
|
Let's look at the above steps in more detail.
top
Creating an image
To create an image, you install the operating system and applications onto an image host and configure the application for Cassatt Active Response. For image host requirements, see the sidebar, Image host requirements.
The next sections provide guidelines for installing and configuring your applications to work with Cassatt Active Response.
Install the operating system: keep it lean
Operating system distributions come with all kinds of tools and applications that are useful for specific purposes, such as when you are running a workstation. Most of these are not applicable in a Cassatt Active Response environment.
Before installing the operating system on the image host, check the package dependencies for your applications. You should install exactly the packages you need, and no more. Superfluous packages increase both image size and time required to boot. Window managers, mail programs, and printing programs are just a few examples of applications that are generally not needed on Cassatt Active Response application nodes.
In addition to any packages your application requires, Cassatt Active Response requires SNMP, SSH, and NTP. Make sure you install these packages.
Operating system configuration tips
- Make sure to set up /etc/ntp.conf to use your site ntp server.
- If you need to add or replace a device driver, install the driver on the image host. If possible, install all drivers required for all types of hardware on which the image will run. Driver vendors generally provide patches or instructions to edit the /usr/share/hwdata/ pcitable file with the required driver information. You should verify that any drivers you add or replace are properly recorded in the file.
- Configure SNMP to allow Cassatt Active Response to monitor the application nodes. The simplest way to configure SNMP for Cassatt Active Response is to replace the file /etc/snmp/snmpd.conf with a new file containing only this line:
rocommunity public
Configuring SNMP by this method sets all values to the defaults, which are in accordance with Cassatt’s requirements for SNMP monitoring. If necessary, make other additions to snmpd.conf to support your site policies.
- Activate and deactivate services as required by your applications and as applicable to your operating system. In general, I recommend the following:
Set to start on boot |
Examples |
SNMP daemon |
snmpd |
sshd daemon |
sshd |
NTP daemon |
ntpd |
Set to never start |
Examples |
Hardware support services for hardware that is not used in the Cassatt Active Response environment |
pcmcia |
Daemon processes that poll for updates via the Internet |
rhnsd |
Conversion servers used for character translation for other languages |
cannaserver, freewnn |
SMTP services and agents, print service daemons, X font servers, and other packages that are needed only when Linux is used as a workstation |
sendmail, cups, xfs |
Unused name services |
ypbind |
|
top
Install your applications
Install your applications as usual, and configure them to run as you want them to run under Cassatt Active Response management.
Configure monitoring
Application images must be set up for monitoring so Cassatt Active Response can detect failures. Ping is the minimum. For more information on monitoring applications and application nodes with Cassatt Active Response, see Understanding Monitoring for Business Applications. Make sure you set up every image for monitoring using at least one supported monitoring collector.
Use scripts to identify instance-specific directories
Thanks to a unique storage structure in the image matrix, Cassatt Active Response deploys applications without risk of version skew. The image matrix stores the base image (with its shared directories) separately from the image instances. Image instances contain directories that individual application nodes need to write to—called instance-specific directories. You don't need to be concerned with the storage structure, but you do need to determine which directories individual nodes running an application need to write to.
Solaris instance-specific directories are allowed only under /usr. Spaces are not allowed in Solaris instance-specific directories.
Linux instance-specific directories are allowed under / as read-write. Spaces are allowed in Linux instance-specific directories.
Cassatt Active Response provides a set of scripts to help you identify which directories your application requires as instance-specific directories. For details on how to use Integrit to identify which directories nodes need to write to, see Using Integrit to identify instance-specific directories.
Shut down all applications
With a few exceptions (see note below), all applications on the image host must be shut down before starting the cccapture interview.
Shut down all applications before capturing an image. If the applications are not shut down, you may or may not get an error during the cccapture interview. Either way, capturing while applications are running can produce an image that does not run properly.
Some virtual machine captures require the VM to be running; refer to the blueprint for more information.
Review file systems and mount points
Review the file
systems on the image host and determine
which file systems should be captured and which should not. During capture, Cassatt Active Response lists each file system, and its type, so you can bypass unneeded file systems.
For NFS-mounted file systems, you can capture the file system or bypass it as usual. Additionally, if the file system is listed in /etc/fstab, you can choose to leave it as an NFS-mounted file system in the image.
In general, capturing unneeded file systems wastes space but is otherwise harmless.
top
Capturing a base image
You capture the base image from the control node by running an interactive command line tool, cccapture. Your inputs are stored in the base image and become the default values whenever you assign the base image to a tier. At the end of tier creation, Cassatt Active Response creates image instances from the base image for use in the tier.
Understand important cccapture questions
Some of the cccapture questions are straightforward, such as entering the OS type:
Enter a name for the operating system for this image (e.g., RedHat):
Other questions require more thought. In the following table, I'll focus on the more thought-provoking questions.
For guidance in answering questions in the cccapture interview about monitoring the operating system and applications, see Understanding Monitoring for Business Applications.
Does the image require personalization? |
Generally, only cluster-aware applications, such as Oracle RAC, require personalization. You can also configure external resources, such as NFS servers, SANs, and load balancers during personalization.
Answering "yes" is your way to inform anyone else who assigns the image to a tier that the image instances must be personalized for the application to function properly. If you answer this question incorrectly during cccapture, you can still personalize the image instances—or not—when you create the tier. Cassatt Active Response does not enforce the personalization step if you say "yes," nor does it prohibit personalization if you say "no."
For more information on personalization, see Understanding Tier Configuration and Personalization. |
| Is this image capable of handling IPV6 networking? [n] |
For utility tiers, IPv6 is not supported for the primary network. For non-primary networks, be sure that IPv6 is enabled and working properly in the operating system and any applications before capturing the image.
If the image is a VMDK or a VBD, you must personalize the image to get a fixed IPv6 address. |
Are there any instance-specific directories to which applications included in this image will need to write? |
If you used the Integrit scripts as described in Using Integrit to identify instance-specific directories, then you are prepared for this question. Cassatt Active Response creates a private copy of each instance-specific directory for each image instance. Remember, a base set of directories (/etc, /dev, /tmp, /var, and /root) is always included. Add each additional directory one by one. When you have entered all directories, Cassatt Active Response logs into the image host to make sure the directories are present, and gives you an opportunity to edit your input if it cannot find a directory you specified. |
Enter the amount of time in seconds that the system should wait for the services provided by this image to start |
The Service Startup Time Limit parameter determines the time Cassatt Active Response should wait to replace an application node during initial startup if a monitoring collector fails. When Cassatt Active Response starts an application node, it waits for every monitoring collector defined for the OS and every application in the image to report in. If any monitoring collector fails to report within the service startup time limit, Cassatt Active Response considers the startup to have failed and replaces the application node.
Roughly, the Service Startup Time Limit for each image should be:
- The time it takes for your hardware to start, plus
- The time it takes for the operating system to start and the monitoring collectors you have defined for your operating system to respond, plus
- The time it takes for your applications to start and the monitoring collectors you have defined for each application to respond.
|
| Should this image be installed on the local disk (allowing the node to boot locally)? |
By default, Cassatt Active Response uses NFS to boot application node images after activation. If you want the image to boot from local disk rather than NFS, choose Yes for this question. Keep in mind that images using this alternative, lose any changes to the image instances when the node is replaced. For details, see Alternative to NFS: Images on Local Disk. |
Do you want to specify the hardware requirements for
a tier using this image? |
Cassatt Active Response uses hardware requirements settings to determine the minimum selection criteria for allocating application nodes to each tier; Cassatt Active Response will not allocate an application node to the tier that does not meet the requirements. Note that hardware requirements specified on the tier take precedence over the hardware requirements set in the base image.
During inventory, basic hardware attributes are collected for each application node. After inventory, if you then specify a hardware requirement for the tier on this page, Cassatt Active Response checks an application node's inventory data to be sure it matches the hardware requirement you've set before allocating the node.
If you set local disk on an image, related settings can only be changed on the image, not on the tier. To understand the local disk setting, see the sidebar Local disk.
If using FibreChannel SAN, you'll need to configure the HBA key; see the sidebar HBA key. |
| Do you want to specify any custom attributes for tiers using this image? |
During inventory, Cassatt Active Response may not gather all of the hardware attributes you care about; for example, your software may require a CD-ROM drive. In this case, you can specify a custom attribute—a label you make up to represent the hardware requirement. In the CD-ROM example, your custom attribute might be the string, CDROM. You tag the application nodes that have CD-ROMs (Tiers > Node > Requirements) with the CDROM custom attribute so Cassatt Active Response can identify them. Then, you tag the tiers that need CD-ROMs with the same custom attribute. Cassatt Active Response allocates only application nodes with CD-ROMs to each tier that requires CD-ROMs.
Cassatt Active Response allocates nodes with custom attributes last because
they have the highest "cost." However, when resources are constrained,
Cassatt Active Response does allocate nodes with custom attributes to tiers that do not
require custom attributes. |
top
After cccapture: where images are stored
Captured base images are stored in the image
matrix. By default, the image matrix is on the Cassatt Active Response base
file system (symbolically linked as /cassatt)
in the the images directory. However,
images can be stored on multiple file
systems depending on how you configure your storage subsystem
for Cassatt Active Response. (See Understanding
Storage Management in Cassatt Active Response for more details.) Regardless
of whether or not you are storing images on multiple file systems,
images should physically reside
on the shared storage device:
- SAN – application nodes mount the image matrix from
the control node
- NAS
– application nodes mount the image matrix
directly from the NAS device
Whether you use SAN or NAS, the image matrix contains each base image and all of its image instances (which Cassatt Active Response creates when you assign the base image to a tier).
Changing cccapture values
You can change values that you set in the cccapture command in the Controller Images tab.
Assigning images to tiers
Images (along with networks, SLAs, policies, and monitoring) come together when you create a tier—a functional set of nodes that provide a business service. For details on how to assign base images to tiers, and how to personalize image instances on tier nodes, see Understanding Tier Configuration and Personalization.
Was this article useful? Tell us what you think.
Email infocentral@cassatt.com.
|
