The four main virtualization architectural options are storage controller, server, network attached appliance, or storage fabric-resident function. All architectures work well for I/O light environments where recovery is less complex, but for most situations, the choice will be using virtualization appliances (e.g. IBM's SVC, EMC Invista) or solutions where virtualization is built into the storage controller (e.g. Hitachi, 3Par).
The advantage of appliance-based virtualization is it cost-effectively unifies virtualization methodologies, enabling the mapping of heterogeneous storage. The big drawback here is that because storage management services reside in each respective controller, the locus of control is shared between appliance and storage controller. This makes storage management more cumbersome for the system. Additionally, while appliance-based approaches can accommodate heterogeneous storage, when LUN limitations are exceeded, another appliances must be installed and virtualization cannot occur across appliances.
Having multiple points of control (e.g. different storage controllers and appliances) creates potential bottlenecks in high I/O environments, especially during recovery. This is where controller-based virtualization shines. With a single point of control, virtualization within a high performance storage controller enables the attachment of heterogeneous storage arrays (if supported by the vendor) and logical mapping across all attached assets. Whatever path is taken, there will be some degree of vendor lock-in, especially at the storage resource management (SRM) level.
Action Item: Keep the initial environments for virtualization as simple and homogeneous as possible with single vendor solutions; consider different virtualization approaches for different storage pools-- one size does not fit all. For high performance and high availability environments there are strong theoretical and practical reasons for putting the virtualization engine in the storage controller. For other environments the choice is wider.
Footnotes: Related research: Managing geometric data growth in SANs
