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, 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 virtual SANs also provides smaller elements that are easier to manage, change and build out. Virtual SANs also benefit SAN security because a security breach in one virtual SAN does not compromise the entire SAN. Similarly, virtual SANs 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 virtual SAN 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 virtual SAN product can support all of those fabrics. There is also a limit to the traffic that is supported between virtual SANs, so determine the maximum data throughput between virtual SANs 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 virtual SAN product. This can be problematic because the three main virtual SAN 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 virtual SAN 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 virtual SAN 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 virtual SAN 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 virtual SANs is that only the virtual segment being upgraded or changed should experience disruption -- other virtual SAN fabrics should continue to operate normally. Still, even limited service disruptions may be unacceptable for certain applications or users. For example, a virtual SAN 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 virtual SAN product is still in lab testing or pilot deployment.
Evaluate the management features. Although virtual SANs 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. Virtual SANs 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 virtual SAN product specifications page in this chapter covers the following products:
Brocade Communications Systems Inc.; Silkworm MPR AP7420
Cisco Systems Inc.; MDS 9000 Family of Multilayer Directors and Switches
McData Corp.; Intrepid i10K Xtreme Director
Return to the beginning
