Understanding Storage Hardware Options
Intended for use with Cassatt Active Response V5.0.
A key point to understand in considering storage for Cassatt Active Response is that Cassatt Active Response relies on NFS. Cassatt Active Response application nodes boot diskless, using NFS to mount their root file systems (that is, their images) from network attached storage. For diskless nodes to run properly, they must have continuous access to their root file systems.
In the simplest implementation, the Cassatt Active Response control node is the file server that serves the images, but you can achieve greater availability and increase scalability by using external NAS.
Your most robust storage solution with Cassatt Active Response is a high-availability NAS (or NAS gateway with SAN) to serve NFS directly—bypassing the control node: check out NetApp or EMC, for example. If high availability and scalability are secondary to other considerations, you have several options.
In this article I'll detail the Cassatt Active Response storage requirements for Cassatt Active Response data and application data, and help you decide what storage solution—or solution combination—works for you. Finally, I'll provide some configuration recommendations.
Cassatt Active Response data: storage options
Cassatt Active Response minimally requires two file systems:
one to store its system data and image matrix and one to
store the Cassatt Active Response database. By default, the Cassatt Active Response installation
program creates the symbolic links /cassatt and
/cassatt/database
to these two file systems. (For more information, see Understanding Storage Management in Cassatt Active Response.)
You can physically create these file systems on
SAN, NAS, or a locally attached disk.
Each of these choices has implications, which I'll list in the next table.
In addition to storage for system data, if you are using two control nodes, the nodes also require raw device access to a small partition on a shared dedicated disk. This storage is used to maintain state information about the control nodes to support failover.
The next table lists options for storing Cassatt Active Response data, and the pros and cons of each option.
|
Pros |
Cons |
Locally attached disk |
|
- Limited size
- Single point of failure
- Supports only a single control node
- Control node functions as NFS server, so application nodes do not have access to their images if the control node fails
|
SAN |
- Supports dual-control nodes for failover
|
- Control node functions as NFS server, so application nodes do not have access to their images during failover
- NFS scalability limited by the control node
|
NAS |
- Supports dual-control nodes for failover
- Serves NFS to application nodes directly, so NFS service continues to run during control node failover
- Better NFS scalability for the same reason
- Can dynamically grow the underlying storage if necessary
- Can achieve highly tuned NFS performance
|
- Requires additional dual-ported disk or SAN to maintain state information for failover
- Cannot use for failover partition as you can with SAN
|
The next table provides the requirements for Cassatt Active Response data storage using each of the storage options.
|
Requirements for control node failover |
Requirements for shared storage of system
data and database |
Locally attached disk |
N/A |
To calculate your storage space needs, see Storage Space: Calculating Requirements.
|
SAN |
A separate disk dedicated for use by the control nodes:
- Disk must not have a file system on it
- Disk must be accessible as a raw device
- Disk must have a minimum of 200 MB
Control nodes must have HBAs |
To calculate your storage space needs, see Storage
Space: Calculating Requirements. |
NAS |
A dual-ported disk with two 100-MB partitions that is dedicated for use by the control nodes
- Disk must not have a file system on it
- Disk must be accessible as a raw device
- Disk must have a minimum of 200 MB
OR
SAN (as listed above) |
To calculate your storage space needs, see Storage
Space: Calculating Requirements.
Note: Cassatt Active Response requires root access to the NAS device.
|
Whichever option you use for control node failover, I recommend that you use RAID, and configure the shared partitions according to these guidelines:
- Use RAID 1 (mirroring) to make the logical unit that contains the shared partitions highly available. Optionally, parity RAID can be used for high availability.
- Do not use RAID 0 (striping) alone for shared partitions.
- Place both shared partitions on the same RAID set, or on the same disk if RAID is not employed, because both shared partitions must be available.
- If possible, do not put the shared partitions on a disk that contains heavily-accessed service data.
For information on setting up storage access, see Control Node: Configuring Storage Access.
Application data: storage options
If you are running an application that uses a large amount of data, shares data with other systems, or requires high reliability, you can mount file systems to store application data outside the application image. These file systems can reside on SAN or NAS, depending on the application's requirements, but not on an application node's local disk. This is because Cassatt Active Response treats application node hardware as interchangeable across applications; Cassatt Active Response might move a given application node—and its local disk—into or out of a tier at any time based on your SLAs and policies.
The next table lists options for storing application data, and the pros and cons of each option.
|
Pros |
Cons |
SAN |
- Emulates direct attached storage
|
- Extra hardware: each application node that uses the SAN must have an HBA
- Limits which nodes can be assigned to an application requiring SAN to those with an HBA configured for particular SAN access
- Sharing data requires a clustered file system
|
NAS |
- No HBAs required
- Serves NFS to application nodes directly, so NFS service continues to run during control node failover
- Better NFS scalability for the same reason
- Can dynamically grow the underlying storage if necessary
- Can achieve highly tuned NFS performance
- Can easily share data
|
|
If you have both, you can use SAN for some applications and NAS for others, depending on your application requirements.
Setting up application nodes for SAN access
When you use SAN to store application data, you need to do some extra configuration so Cassatt Active Response can correctly allocate application nodes with HBAs.
SAN access options
The complexity of the configuration depends on your data security needs: the more tightly you need to control data access, the more steps you'll need to take and the less flexibility Cassatt Active Response will have in node allocation.
Application node and HBA configuration |
Most secure |
Most flexible |
Description |
All HBAs have access to a zone or to all LUNs used by any application in the Cassatt Active Response environment. |
|
|
Cassatt Active Response can allocate any node with an HBA to any tier that requires one.
Applications could access data for which they are not authorized. |
Each HBA has access to only the zone or LUNs associated with one application. |
|
|
Nodes cannot be shared across tiers that use SAN for application data storage. This could leave applications short of nodes even while nodes with appropriate hardware sit idle in the free pool. |
Configuring SAN access
Cassatt Active Response uses a matching mechanism—called an HBA key—to select application nodes with SAN access for allocation to tiers. You can affect how Cassatt Active Response allocates nodes to meet your security and flexibility requirements by composing and assigning HBA keys.
Use the next table to configure HBA keys to achieve the level of security and flexibility you need for your site.
For this application node and HBA configuration... |
Follow these steps to configure HBA keys... |
Most flexible... All HBAs have access to a zone or to all LUNs used by any application in the Cassatt Active Response environment. |
Configure the SAN switch with all WWNs. No HBA keys are needed.
|
Most secure... Each HBA has access to only the LUNs associated with one application. |
- Compose a unique HBA key for each application.
- Determine the number of application nodes you want to allot for each application, including spares in case of failure. Make sure you have sufficient nodes with HBAs to meet this total.
- In the free pool, select an application node with an HBA and assign it the HBA key for the first application. Repeat until you have assigned the HBA key to the number of nodes you allotted to the first application.
- Create a tier for the first application. Set the maximum number of nodes to the same total you allotted for the tier. Set the target to the number you want to run simultaneously. Set the HBA key to the same key as you set for the first group of nodes.
- During personalization, Cassatt Active Response boots all of the nodes with the matching HBA key. Configure the SAN switch to allow access for the WWN of each HBA to the appropriate zones or LUNs.
- Repeat steps 3–5 for each application.
|
Limiting allocation for nodes with SAN access
You configured HBA keys to ensure that applications requiring SAN storage receive only application nodes that have the appropriate SAN access. The HBA key, however, does not prohibit Cassatt Active Response from allocating nodes with HBAs to tiers that don't require (and should not have) them.
To protect your SAN from unauthorized access, you can disallow allocation of application nodes to tiers that should not have SAN access. To permanently disqualify all nodes with HBAs to any tier that does not specifically require them across your entire Cassatt Active Response environment, contact support@cassatt.com.
For a more flexible, ad hoc approach, set a custom attribute on all application nodes without HBAs and on all tiers that should receive application nodes without HBAs.
top
|
