Weigh the software maintenance overhead. Software is rarely installed as a single product. In most cases, virtualization software will require installation on multiple servers, along with agents and "shims" placed onto application servers. Each iteration of the storage virtualization software and agents must be maintained as updates become available or reinstalled as hardware is upgraded and replaced. This takes time and attention from an IT staff, which is already overburdened. Smaller organizations may be hard-pressed to meet the added software maintenance demands.
Consider the added costs of software licensing. Enterprise software is rarely a singular purchase. Each new server installation demands a costly license that must typically be renewed annually. Before purchasing virtualization software, have a clear understanding of the upfront and recurring costs involved, and know how those costs will change as the number of servers, devices or storage capacity increases. See where economies of scale might actually save the company money.
Weigh the software's impact on hardware performance. As with other types of software, storage virtualization software carries system requirements that each host server has to meet. Before purchasing any virtualization software, ensure that the server(s) will meet or exceed the system requirements. If not, each virtualization server may need to be upgraded or replaced -- further escalating the up-front virtualization costs. In addition, virtualization software and drivers demand memory, CPU, network and I/O resources from the host server. This inevitably impacts the virtualization server's performance -- especially if the server is also running other applications on the network. Fabric-based virtualization has become particularly appealing because virtualizing at the switch alleviates performance issues typically found in host/appliance virtualization.
Understand the modes of deployment. Not all storage virtualization software is deployed the same way or has the same hardware requirements. Once system requirements are understood, consider how the system must be deployed. Most host-based products are deployed on a server working out-of-band (out of the direct data path) collecting and handling network data. But software can also be installed on switches. For example, Incipient Inc.'s Network Storage Platform (iNSP) runs on a blade on the Cisco Systems Inc. MDS director, while EMC's Invista runs on an out-of band dual-node cluster, which works with intelligent storage area network (SAN) switches. Select a product that will have minimal impact on your current infrastructure.
Evaluate monitoring and reporting features. Storage administrators must be able to discover storage resources and keep track of virtualized storage allocation. Virtualization software should be able to present comprehensive reports on available storage and detail the existing configuration. In many cases, the software should use email or other warnings to alert administrators of impending storage shortages.
Evaluate the management platform and capabilities. Testing is an important opportunity to examine the management features available in the virtualization software product. Look for interface simplifications and automations designed to ease the most common tasks. For example, SANsymphony from DataCore Software can assign performance and priority levels to each storage domain and configure storage to ease the impact of network congestion on key applications. As another example, IPstor from FalconStor centralizes management under a single Java console, which unifies storage services. It's also important to note the storage management tools should be compatible with the virtualization software, like using Symantec/Veritas Storage Foundation along with Hitachi Data Systems Inc. (HDS) HiCommand software.
Evaluate data movement characteristics. Virtualization software should support storage tiers, and facilitate data movement between tiers. For example, noncritical data may be sent along to a virtualized secondary tier, while mission-critical data would be passed to a virtualized primary tier. The virtualization product should also rely on storage policies to move data between virtual tiers. Also, check for other data allocation features, like provisioning, thin provisioning and capacity-on-demand (COD). As an example, IPstor's COD feature can compress infrequently used files and move them to an "overflow" storage volume -- effectively freeing previously allocated space for more current files. ***
The virtualization software product specifications page in this chapter covers the following products:
This was first published in November 2006