You can virtualize both storage area networks (SANs) and network-attached storage (NAS). The choice of whether to implement SAN or NAS should depend on the performance you want and its ease of use.
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Cathleen A. Gagne, Senior Editorial Director
NAS is file-based storage
that's less expensive and easier for organizations to work with. SAN is block-based storage that's
more expensive but provides better performance.
Although both can be virtualized, many organizations opt to virtualize only storage area network, leaving network-are storage for secondary tasks like archival storage or backup.
"Our storage area network is a fully virtualized storage array that provides high-speed iSCSI access to our server virtualization hosts," said Scott Gorcester, president of Moose Logic, an IT services firm headquartered in Bothell, Wash. "We wouldn't consider using a network-area storage for that because we don't believe the performance is up to snuff."
 |
||||
|
|
|||
|
||||
While it is theoretically possible to combine NAS and SAN storage in the same pool, it's certainly not recommended because of the disparity in storage device performance. You must know the storage access needs of each application.
Furthermore, storage network architecture has little direct effect on storage virtualization choices; it's merely the plumbing that ties storage to applications. This is another consideration in which cost and performance requirements should dictate choices. For example, Fibre Channel (FC) is the unquestioned leader in block storage networking, but it's also the most expensive and sophisticated technology. On the other hand, iSCSI has embraced 1 Gigabit Ethernet (GbE) and gained tremendous popularity in recent years.
Ethernet-based products are much less expensive than FC. Plus they're readily available, and management and maintenance are well understood. For many small and medium-sized companies that are considering storage virtualization, iSCSI is preferable.
While Fibre Channel over Ethernet (FCoE) is still emerging, it promises yet another alternative that can handle high-performance FC storage commands across standard Ethernet networks. Ultimately, all three network types should be equally suited to storage virtualization.
Although storage virtualization can pool storage and create LUNs from a potentially sizable pool, the OS that will access the LUN ultimately limits its size. For example, LUN sizes are generally limited to 2 TB for current Windows OS platforms. However, huge virtual LUNs are not always the right choice.
Gorcester is quick to point out that large LUNs can cause traffic bottlenecks, and performance problems can occur when multiple VMs are located on the same LUN. "That presents a traffic bottleneck," he said. "There are some concerns about iSCSI conflict if all of that traffic is talking to a single virtualized storage entity."
One way to maintain adequate performance is to configure and present smaller LUNs or otherwise limit the number of VMs placed on a single LUN.
Large LUNs can also pose problems when restoring data to virtual machines. During a rollback,
all virtual machines on that LUN would need to be rolled back, potentially causing unexpected data
loss. In addition, it takes time to restore a LUN on another machine so that necessary pieces of
lost or missing data can be recovered. Smaller LUNs avoid this kind of contention.
This was first published in November 2009