By Evan Morris
The first of two articles provides tips to help you get started on storage resource management testing, installation, and deployment.
There are several aspects of storage resource management (SRM) software to test, from measuring performance impact to assessing system stability and avoiding negative interactions with third-party applications (antivirus, backup, and other disk utilities) and Windows 2000 (Win2K) storage features. Testing more-complex storage systems and scenarios such as Doffs and clustered servers may also be necessary.
Some SRM products are designed around a model called policy-based management. The idea is to create a set of storage-management policies and apply those policies to storage objectshopefully in a centralized cascading manner made possible by Active Directory. I used a policy-based SRM product for years (which was not integrated with Active Directory), but that software lacked a dynamic approach to storage management and mostly generated reports on-demand to let me know who or what was operating outside of policy. I turned to Storage Central SRM (from Precise-W. Quinn) and put it to use actively controlling disk usage in real time.
Storage Central 4.1 had some policy-based management features, as storage policies were stored in pre-defined templates. However, the 5.0 version allows greater integration of storage allocations and file blocking into the same set of policies, as well as centralized management when integrated into Active Directory.
Installing and Testing SRM
When installing SRM software, be sure to capture information about the installation process, because this information is much easier to gather while you're performing the installation rather than trying to recreate the same scenario later.
To monitor and administer storage policies on servers that have an SRM suite installed, you will want to install the management console on your computer (as opposed to the server component). Depending on the type of policy-based storage manager you use, installing and configuring your policies on a per-server and per-share basis can be easy (using a centralized, template-driven product) or difficult (if you have to export and import or manually configure Win2K quotas).
It is advisable to create a template for setting your organizational storage policies that lists some of the information that should be determined before handing over the SRM implementation to the systems administrators or server operators. This information should be captured and distributed to any site or location within your organization that wants to implement policy-based storage management.
Depending on how you prefer to deploy your software, you may require the SRM software to support unattended installation and configuration. Check with the vendor to determine whether the product comes with a Windows Installer package and supports deployment through Microsoft Systems Management Server (SMS). The pilot phase offers the opportunity to learn and test the automated deployment.
The SRM software most likely uses service accounts. Many applications provide the option to install under local system authentication with service start-up logon options, but this functionality can limit network access for the service between servers. Instead, you may need to define necessary service accounts and grant them appropriate privileges.
To assist in delegating the configuration portion of the installation, the following section defines the objects to be managed and the storage policy configuration settings. Rather than starting from scratch, your policy-based storage management software may have pre-defined templates or policy definitions that you can re-use and copy from one system to another.
A key to evaluating SRM products is to properly set up the test environment. Ideally, you want to evaluate the SRM product's performance and features relative to your needs. But you will also want to measure the impact of SRM on performance and the end users' perceptions of how the SRM product either hinders or helps their daily tasks.
Testing system stability
To ensure thorough testing, a helpful practice is to break this phase of the project into sub-phases and assign roles (see table).
SRM application monitoring
During this system testing you will also be integrating the SRM software into your application management framework. This task might be as simple as setting the service to notify you of failure, or it may involve using an application monitor from Net to trigger an alert if the service does not respond.
Upgrading to Win2K
Upgrading from NT 4.0 to Win2K may be part of your SRM projecta worthy upgrade. However, not all applications will be compatible with Win2K. Applications written for Win9x or the Win16 environment may have compatibility problems, and even applications that work on NT do not guarantee full compatibility with Win2K. I have seen changes in the Win2K filter driver model cause problems for storage subsystem applications, so it would be wise to check with the application vendor before upgrading to Win2K.
As part of your SRM deployment, you may need to test interaction with the following Win2K features to guarantee compatibility:
Doffs SRM policies are typically designed to operate and provide functionality at the server and disk-partition level, but the Win2K Doffs architecture is designed to provide a layer of abstraction into the enterprise-directory level. You should test your SRM software with Doffs if you are using them in combination.
MSCS clusters Several products are available for clustering file servers, the most common of which is Microsoft Cluster Server (MSCS), a component of Win2K Advanced Server. Setting up clustering in Win2K is wizard-driven and is much easier than in NT 4.0.
Check with your SRM vendor before attempting to install the SRM software into an MSCS cluster. The SRM software should be cluster-aware and not cause any interference during cluster node fail-over as the resources are brought online.
Offline files were introduced with Win2K Pro and provide performance benefits and convenience features (even when used with an NT 4.0 file server). For this phase of the SRM project, you need to determine whether storage policies interfere with offline files. What happens when a user attempts to synchronize a large file that places the user over the quota? You mainly test to determine whether your SRM software causes any error condition on the client side that would prevent the client from successfully saving the file.
Interaction with third-party utilities: Antivirus
Antivirus software can cause severe problems on servers, including data loss and operating systems that no longer boot. It is no secret that there were compatibility issues with previous versions of some antivirus software filter drivers, and that these issues even affected SRM applications. The best advice is to make sure you have the latest antivirus software.
There are several ways to test the action of antivirus software when it identifies and attempts to either repair or quarantine a suspected file.
The safest way is to use the EICAR test string, which should be recognized by all antivirus scanners. As part of my antivirus testing, I typically use a real virus included in a .ZIP file. But I caution you to be careful with a real virus, and if it is an executable, rename it to a file extension that will not automatically execute. I also perform another suite of tests that includes several abnormal situations that can either occur naturally or as a denial of service (DoS) attack.
Validating the interaction of SRM products with your backup applications is as simple as performing routine backups and testing the restoration of data. You will determine whether you need to disable or turn off your SRM software during large restorations. This task is more complex if you are using snapshot services or volume replication to perform backups and restores.
Other disk utilities
Finally, you should test interaction with any other third-party disk utilities such as volume managers and defragmentation software. The reason is not so much that you will encounter problems, but if you do it is better to find them in the pilot-testing phase than in the deployment phase.
File blocking and quarantining
In the past, some SRM products allowed file blocking or screening, which would prevent a user from saving a specific type of file to a location. File blocking was typically based on file extension, instead of looking into the file header to determine the actual file type. But new versions of SRM software can actually determine the file type and can be configured to quarantine the file in a location configured by the administrator, just as antivirus software does. If you plan to use this feature, you will want to add it to your test suite to make sure that there are no interference issues with third-party utilities.
In this article, we began preparations for SRM deployment staging. The next step is the pilot phase rollout. Part II, to be published in an upcoming issue, will give you some sample tests and tools to use in your lab evaluation to help test SRM software. In addition to stability testing, we will gain feedback in other areas such as measuring the effectiveness of SRM software. This feedback will come from system testers as well as the end users involved in the pilot phase.
Evan Morris is an MCSE, MCT, Compaq MasterASE, and a messaging consultant in Compaq's Exchange Solution Engineering division.
Portions of this article were excerpted from the free eBook, The Definitive Guide to Storage Resource Management (Realtimepublishers.com). The full text of the article, which includes a number of templates, is available at www.wquinn.com/ebook.