- Sun StorADE 2.3 Features
- How StorADE Works
- StorADE Best Practices
- StorADE Deployment Worksheets
- Related Resources
- About the Authors
StorADE Best Practices
Refer to the StorADE product documentation for details on installing, deploying, and using StorADE. The following sections highlight some best practices to follow.
Installing StorADE
The following list describes the high-level tasks you perform when installing StorADE.
Download the Sun StorADE package from the Sun Download Center.
If you are upgrading from an older version of StorADE, remove the older version before you install the newer version of StorADE.
Complete the Site Planning Worksheets (see "StorADE Site Planning Worksheets" on page 19).
Identify the hosts you plan to use as the StorADE master and slaves.
Install the StorADE package as a master or slave based on your desired deployment configuration, as you listed in the Site Planning Worksheets.
Initialize the StorADE configuration using the ras_install script. Perform this task for each master and slave in your environment.
Configure the StorADE environment to suit your monitoring needs.
Verify StorADE functionality.
Deploying StorADE
There are a variety of ways to deploy the StorADE utility in your environment. Your best practice StorADE deployment depends on the type of storage you plan to monitor and the topology of your enterprise.
This article outlines five sample monitoring solutions for entry-level and mid-range servers. These solutions correspond with the overall environment (topology) rather than with particular applications running in it. You can use any of these deployment solutions as is, or tailor them to fit your exact needs. Examples of customization opportunities include adding additional slaves or data hosts to distribute load and scale the StorADE utility.
Review the four sample monitoring solutions to identify which solution meets your needs, and use the configuration to plan your StorADE deployment. Large complex environments might benefit by using a combination of the given solutions.
You can use the worksheets provided in this article to plan your configuration. See "StorADE Deployment Worksheets" on page 18.
TABLE 2 Configuration Guidelines
Rule |
Count |
Description |
Maximum Slaves per Master |
50 |
Scalability |
Maximum Devices per Master |
1000 |
Scalability |
Minimum Masters |
1 |
Administration and control |
Solution A Single Agent With In-Band and Out-of-Band Devices
The configuration shown in FIGURE 3 is made up of a single master agent installed on one host that is used to monitor everythingin-band devices, out-of-band devices, and log files. The master provides the console and is responsible for sending all notifications. The host must have access to all log files, all out-of-band devices, and connectivity for notifications (such as email and SRS Net Connect).
FIGURE 3 StorADE Deployment for Solution A
TABLE 3 Pros and Cons for Solution A
StorADE Configuration |
1 Master |
Pros |
This configuration is the simplest and easiest to implement. |
Cons |
StorADE has a single point of failure. If the master host goes down, no monitoring or notifications take place. All monitoring is performed by one host. Depending on the number of devices monitored, this configuration might reach saturation, or become negatively affected by a bottleneck (in the host's network interface, for example). |
TIP
If your site includes multiple hosts and only one agent is installed, the topology will be incomplete. Consider Solution B if a complete topology is important. If array log files are stored on a separate host, consider Solution C or D.
Solution B Master and Slave Configuration With In-band and Out-of-band Devices
The configuration shown in FIGURE 4 uses one master host that monitors in-band and out-of-band devices, provides the console, and sends notifications. The slave host is used to monitor in-band host bus adapters (HBAs). Log files are managed by the master and the slave hosts. This solution provides a more complete SAN topology because there is an agent on multiple hosts. This solution is well adapted to sites that have multiple hosts with multiple log files.
FIGURE 4 StorADE Deployment for Solution B
TABLE 4 Pros and Cons for Solution B
StorADE Configuration |
1 Master 1 or more Slaves |
Pros |
This configuration provides some redundancy. If one of the StorADE hosts is down, the others continue to monitor devices. The slave host provides log monitoring for out-of-band devices and in-band HBA monitoring. |
Cons |
StorADE is more complex to install than in Solution A. |
Solution C Master and Slave With In-Band and Out-of-band Devices and a Loghost
The configuration shown in FIGURE 5 uses a master host to monitor in-band devices, out-of-band devices, and slaves. A slave is added to monitor HBAs and log files, with another slave installed (as a data host) on a loghost server to capture log messages from the Sun StorEdge T3 arrays. For sites where a separate host is used to store log files, this solution can be used to relay the log information to the master agent. Otherwise, Solution C is the same as Solution B.
FIGURE 5 StorADE Deployment for Solution C
TABLE 5 Pros and Cons for Solution C
StorADE Configuration |
1 Master (in-band and out-of-band access) 1 or more Slaves (for in-band coverage only) 1 Slave (for log hosting only) |
Pros |
You get the same advantages as Solution B, with the addition of a data host that provides log monitoring of out-of-band devices. |
Cons |
StorADE is more complex to install than in Solution A or B. |
Solution D Management Station Configuration
The configuration shown in FIGURE 6 uses the master host to receive monitoring information for out-of-band devices from slaves. The master provides the console and sends all notifications. Slaves are needed to monitor HBAs and log files. Multiple slaves are used to scale the monitoring activities. One slave is installed on a loghost for log monitoring. When a large number of slaves are present, there is often a need for a separate master to aggregate the slaves and reach the remote monitoring notifiers. When the master's only functions are aggregating the slaves, providing the BUI, and sending notifications, it is often referred to as a management station. This solution is necessary if none of the slaves have access to the remote notification providers (such as SRS Net Connect). This situation can be common on large sites with multiple subnets.
FIGURE 6 StorADE Deployment for Solution D
TABLE 6 Pros and Cons for Solution D
StorADE Configuration |
1 Master (out-of-band log host) 1 or more Slaves 1 Slave (for the data host) |
Pros |
You get the benefits of a management station where you have a central point for the BUI, aggregation of slave monitoring, and logging of out-of-band devices. This configuration provides the best monitoring topology of all four solutions. |
Cons |
This is the most complex solution to install. |
Solution E StorADE 2.3 Integrated with ESM 2
Sun StorEdge Enterprise Storage Manager (ESM) 2.1 is SAN management software that couples StorADE health and monitoring modules with a management interface. StorADE is installed and configured as part of the ESM 2.1 installation. Interaction with StorADE is limited to interfaces within the ESM software.
FIGURE 7 StorADE 2.3 and ESM 2.1 Integration Components
TABLE 7 Pros and Cons for Solution E
StorADE Configuration |
1 ESM Management Station and optional data hosts agents (one for each host) 1 StorADE master and optional Slaves |
Pros |
This configuration presents a single management and monitoring pane. |
Cons |
ESM 2.1 adds an additional layer of software to maintain. All storage monitoring is performed by one host. Depending on the number of devices monitored, this configuration might reach saturation, or become negatively affected by a bottleneck (in the host's network interface, for example). |
Enabling Security
No matter which deployment solution you use, if security is a concern, you should install all agents with security enabled. StorADE is installed with security turned on when you run the ras_install installation script and answer yes to the security question.
The StorADE secure installation uses the Secure Sockets Layer (SSL) Protocol for transmission of information between the master and slaves, and between the master and the StorADE BUI. The highest grade encryption (RC4 with 128-bit secret key) is used. The StorADE package includes a default certificate that expires in 2008. This certificate is located in /opt/SUNWstade/System/certificate.pem.
With secure mode, the default URL (port 7653) is used when a redirect occurs. The non-secure URL is http://hostname:7654. Site-specific certificates can be created with the openssl utilities (part of the public domain OpenSSL product).
StorADE also supports user-level security. StorADE user accounts are created by the root (ras) login. Each user is assigned user privileges based on one of the following roles:
guest can read StorADE data
admin can read StorADE data and make StorADE configuration modifications
expert can run StorADE reports and diagnostics
test can run StorADE diagnostics
ras has all the privileges of all the roles (the root equivalent for the StorADE utility)
Each login account allows users to log in to StorADE with their own login and password, and results in users having a restricted set of functions available in the BUI.
Using StorADE
When StorADE is deployed, there are a variety of administrative activities that you should perform.
On a routine basis (when the event occurs):
Review all notifications (email).
Check and maintain alarms from the BUI.
Clear acknowledged alarms.
Weekly:
Maintain the event stream (make modifications to notification levels and filters as necessary).
Check and remove hardware entries for decommissioned devices.
Discover new devices.
Periodically (every six months or so):
Check for StorADE patches at the SunSolve Online web site.
Perform a revision check whenever a new patch is applied or new hardware is discovered.