At its core, the resource sharing protocol SMB 3.0 allows users to connect to file shares and printers. But this latest version, new in Windows Server 2012, offers resource
More on what's new in Windows Server 2012
New virtual data center design decisions with Hyper-V 3.0
Windows Server 2012 Hyper-V soothes VM import process
Windows Server 2012 Hyper-V missing features and potential fixes
SMB 3.0 doesn't deviate from the basic construct: A Windows admin accesses remote files by typing in \\Servername\Sharename to get to the location on another server or workstation. The protocol still allows for file access, but it performs resource sharing in a new, multi-channeled and multithreaded way that allows for much faster and more reliable throughput as well as encryption. This change enables users to access much larger files in real time and at high speed.
However, if not architected to match your business needs and service level requirements, it will only create a performance bottleneck. By first examining your options for designing a Hyper-V infrastructure using the new SMB 3.0 protocol, and the implications for a test environment, you'll be equipped to avoid potential bottlenecks.
What to expect with SMB 3.0
Using remote clustered shares with the SMB 3.0 protocol creates a transport channel that functions as a high-speed, threaded data channel for connecting to storage, similar to transport channels created with iSCSI or Fibre Channel. This viable third option for remote file access in Windows Server 2012 creates a simple way to design your Hyper-V virtual machine (VM) storage. It enables connections between Hyper-V Hosts running on Windows Server 2012 and a SMB share located on a Windows Server 2012 server or cluster of servers. The cluster nodes might use iSCSI or Fibre Channel as back storage. This configuration allows you the benefit of having multiple Hyper-V VMs pointed to the same share on the cluster that has high bandwidth connections.
Designing your infrastructure around the resource sharing protocol
In order to house your Hyper-V VM storage, configuration files and snapshots on a remote share location using SMB 3.0, you must run Hyper-V under Windows Server 2012. The remote share location must run Windows Server 2012 as well. The word from Microsoft at this point is that the code will not be backported to previous versions of Windows Server.
How you design a Hyper-V infrastructure around remote share Hyper-V VM storage will vary according to your storage I/O needs and the nature of the workload. The infrastructure could simply consist of a single server with local storage.
Or it could be more complex and consist of a multi-node cluster with multiple high bandwidth network interfaces. Your I/O, redundancy requirements and budget will all be important factors contributing to the end design.
SMB 3.0 in a test environment
For a limited test environment that does not require high availability, you only need a Hyper-V host and a secondary server with some onboard storage. For example, two desktops or two lower-end servers with single 1 Gigabit Ethernet connections could suffice, but to use SMB 3.0, they must both be able to run Windows Server 2012.
You could also expand and have multiple standalone test Hyper-V hosts as the processing power of the environment, all pointing back to one Windows Server 2012 server for your storage. This reduces the amount of distributed/wasted local storage, and simplifies provisioning additional transport technologies, such as iSCSI or Fibre Channel, on each Hyper-V host. This configuration would make the remote storage a single point of failure, but it would reduce costs and provide a very simple architecture.
Once you've evaluated SMB 3.0 in a test environment, you only need to go through a few more steps to make your infrastructure production-ready. Learn how in part two of this series.
This was first published in September 2012