Virtual SAN purchase considerations

Storage area network (SAN) management is complicated, period. SANs have proven invaluable in enterprise storage deployment; however, administrators must frequently overcome scaling, managing and troubleshooting issues. Large SAN architectures are often broken down into one or more virtual SANs (VSAN), which partition the physical SAN into logical sections. Conversely, virtualization can also be used to combine SAN islands into a single SAN entity. SAN virtualization allows SAN traffic to be isolated within the network -- easing troubleshooting and other network disruptions. Breaking down the SAN into VSANs also provides smaller elements that are easier to manage, change and build out. VSANs also benefit SAN security because a security breach in one VSAN does not compromise the entire SAN. Similarly, VSANs can carry duplicate data, allowing a degree of redundant operation and data protection within the physical SAN.

 Now that you've reviewed the essential issues involved in any virtualization product, this guide focuses on the specific considerations for key virtual SAN products. You'll also find a series of specifications to help make on-the-spot product comparisons between vendors, like Cisco Systems Inc., Brocade Communications Systems Inc. and others.

Consider interoperability between real and virtual components. Since virtual SANs are typically deployed through intelligent switches, interoperability with other switches and storage hardware may often be taken for granted. However, it is always advisable to verify the interoperability of your VSAN products with other switches and directors in your infrastructure. Make sure that virtual switches (logical switches partitioned from large physical switches) are fully supported by existing management tools.

Evaluate support for multiple fabrics. An organization may run different or multiple fabrics in the data center, so verify that the VSAN product can support all of those fabrics. There is also a limit to the traffic that is supported between VSANs, so determine the maximum data throughput between VSANs and consider the maximum number of concurrent sessions that can exist between different fabrics. Deficiencies in any of these areas can often be mitigated through SAN architecture changes, additional SAN bandwidth, upgraded SAN hardware or a different VSAN product. This can be problematic because the three main VSAN vendors each treat SAN virtualization a bit differently. For example, Brocade's logical SAN (LSAN) approach is noted for its ability to connect many SAN islands into one ubiquitous SAN; Cisco's VSAN approach is noted for segregating one SAN into multiple logical SANs; and McData Corp.'s director flexible partition (DPAR) can typically take either approach.

Evaluate the fabric routing behaviors. During lab testing, take the time to evaluate some more detailed routing behaviors with the VSAN product. For example, it should be easy to route between fabrics and domains, and virtual zones should be able to span fabrics seamlessly. There should also be several options to map devices across different fabrics. Verify that you can route all of the protocols that you currently use between fabrics. In short, the virtual SAN product should offer tremendous versatility in the way that it handles traffic and devices between fabrics.

Upfront planning is essential. As with virtualization hardware, virtual SAN deployment should not be attempted without a comprehensive deployment plan that addresses adequate preparation, setup and configuration, and testing. The virtualization vendor can generally assist with these considerations prior to purchase. Remember that the VSAN setup will cause some downtime and service interruptions for your users, so deployment may be reserved for evening or weekend hours. Have a fallback plan in place so that the virtualization can be removed or reversed if unexpected problems arise.

Evaluate disruption levels. One of the advantages of VSANs is that only the virtual segment being upgraded or changed should experience disruption -- other VSAN fabrics should continue to operate normally. Still, even limited service disruptions may be unacceptable for certain applications or users. For example, a VSAN may be temporarily unavailable while configuration changes are made or physical devices are added. While many products emphasize nondisruptive upgrades, it's worth a close evaluation of actual disruptions while the VSAN product is still in lab testing or pilot deployment.

Evaluate the management features. Although VSANs can simplify large physical SANs by breaking them up into smaller and more manageable logical SANs, it's important to consider the impact of virtualization on management tools and processes. For example, a storage administrator must understand how routing tables are populated and maintained, and have a clear picture of how addressing and zoning conflicts are resolved. In addition, state and management information must be communicated properly across different fabrics to ensure that the administrator can still "see" the entire SAN once virtualization has been applied.

Verify security between fabrics. VSANs should improve overall security by isolating traffic within virtual segments -- traffic on one virtual segment should not pass to another virtual segment. However, it's important to verify security and ensure that traffic remains confined to its respective segment. Evaluate the security features of your virtualization product and be sure to proactively implement security. Part of any security should also include a comprehensive change policy to help storage administrators prioritize and manage changes to virtual storage resources.

The VSAN product specifications page in this chapter covers the following products:

• Brocade Communications Systems Inc.; Silkworm Multiprotocol Router AP7420
  
• Cisco Systems Inc.; MDS 9509 Multilayer Director
  
• Cisco Systems Inc.; MDS 9513 Multilayer Director
  
• McData Corp.; Intrepid i10K Xtreme Director

  Return to the beginning