There are several ways to implement storage virtualization: software, appliances, switch-level and array-level. Which method an organization chooses depends on factors such as cost and technical complexity, performance, flexibility, ease of use and interoperability with storage types and subsystems.
Software interoperability is a common concern, particularly when deployed in conjunction with high-end operating systems and hypervisors. Moreover, updates or changes to virtualization software must be thoroughly tested before rolling them out to the entire enterprise.
An appliance-based approach, such as IBM SAN Volume Controller (SVC), has dedicated storage virtualization servers that already contain the hardware and software needed to implement storage virtualization. Appliances usually cost a bit more, but they offer better performance compared to software. There are also fewer risks during internal software updates and revisions and an appliance can typically handle heterogeneous storage.
You can also implement virtualization at the SAN switch, which possibly yields the lowest latency and highest performance of any approach. The centralized nature of a storage switch lends itself well to centralized management. Still, switch-level virtualization can be more expensive than other approaches and the feature set may not be as rich.
Storage virtualization can appear as an integrated feature of the actual storage array too. Older systems on the market virtualized only internal storage, which provided excellent performance but resisted heterogeneity and centralized management. Newer systems can include virtualization support for external storage, which improves heterogeneity and makes the array appear more like an appliance. One example of a legacy system is the Universal Storage Platform V from Hitachi Data Systems.
Consider these six factors for storage virtualization
Keep in mind these six important points when virtualizing storage in your enterprise.
1. Heterogeneous support. Heterogeneity allows you to pool and allocate more storage while reducing the total number of management tools required in the environment. As a minimum, a storage virtualization product should support a variety of principal storage arrays or subsystems within the enterprise and, if possible, future storage systems.
2. Deployment mode. Storage virtualization can be deployed through software, dedicated appliances, intelligent SAN switches and vendor-specific storage subsystems. Each deployment method has its own pros and cons, including cost and performance as well as other barriers to entry. Therefore, it's important to weigh each approach and decide which best fits your company's storage goals.
3. Backup and disaster recovery. Virtual storage can use hardware-level data protection schemes such as RAID, but virtual LUNs must also be integrated into existing backup and disaster recovery plans. In most cases, you can protect virtual LUNs with conventional tools like snapshots, continuous data protection and copy/migration software. In addition, do not ignore backup testing and verification.
4. Reliability and resiliency. RAID can go a long way toward protecting physical storage devices, but this may not be enough to ensure data integrity -- especially when storage is pooled across a number of different systems. Consider the characteristics of storage performance and keep pools restricted to key storage types, i.e., tiers, and implement high-availability tactics to protect virtual LUNs.
5. Back-out plan. Storage virtualization may not operate as intended, so enterprises must prepare a back-out plan prior to deployment. This plan will reverse troublesome deployments with minimal disruption to applications that depend on storage. In many cases, risk is minimized by deploying storage virtualization in phases, starting with the least critical storage systems.
6. Application performance. Virtualize storage consistently using physical tiers so that high-performance (Fibre Channel) pools can be allocated to the most demanding applications. Low-performance (SAS/SATA) pools should be allocated to less-demanding applications. Otherwise, storage may not be able to meet an application's storage requirements and, ultimately, the application will crash.