Cloud Zone is brought to you in partnership with:

Keith Mayer is a Technical Evangelist at Microsoft focused on Windows Infrastructure, Data Center Virtualization, Systems Management and Private Cloud. Keith has over 17 years of experience as a technical leader of complex IT projects, in diverse roles, such as Network Engineer, IT Manager, Technical Instructor and Consultant. He has consulted and trained thousands of IT professionals worldwide on the design and implementation of enterprise technology solutions Keith is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Build Your Private Cloud Foundation - Networking with Windows Server 2012

04.08.2013
| 1875 views |
  • submit to reddit

When planning network infrastructure for a Private Cloud, there’s a number of technologies to consider and leverage in Windows Server 2012.  At many of my events, IT Pros have lots of questions on when to use various network technologies in their overall Private Cloud design, such as:

  • Teaming modes: Switch independent, Static or Dynamic ( LACP ) network teaming?
  • Load balancing modes: Address hash or Hyper-V port hash?
  • Network isolation: VLAN tagging vs Windows Network Virtualization ( aka WNV or NV-GRE )?

In this article, I’ll walk through a sample architecture for building a Private Cloud network foundation and discuss “when” to leverage each of these components in your overall design.  At the end of this article, I’ll also provide additional references for “how” to implement each configuration item.

  • Did you miss the other articles in this series?
     
    DO IT:
    Get the FULL SERIES of articles in Build Your Private Cloud in a Month at http://aka.ms/BuildYourCloud

Private Cloud Foundational Architecture

When building a Private Cloud, most environments find that they really have two main types of network connections from their Hyper-V hosts: Datacenter Networks and Client VM Networks.

image
Sample Network Architecture for Private Cloud Foundation – Datacenter and Client VM networks

Datacenter Networks

Datacenter networks are the “back-end” networks that Hyper-V hosts use for:

  • Connecting to storage
  • Live migration of running VMs
  • Internal Cluster networks
  • Host management networks
  • Data backup networks

These datacenter networks tend to be relatively static in nature – once the “back-end” network architecture is implemented, it doesn’t usually change drastically until another major network upgrade window occurs.  Commonly, these networks will connect within the datacenter via a set of intelligent core network switches that have a backplane optimized for a high level of concurrency between network ports.

For datacenter networks of this nature, I see most organizations trending towards using dual 1GbE or 10GbE NICs in a teamed configuration for load balancing and redundancy – 10GbE NICs are growing in popularity for new installations to provide higher bandwidth, consolidated physical connections and advanced features, such as RDMA which can be leveraged for high-speed data transfers across storage networks using the newly updated SMB 3.0 network protocol. When implementing a NIC team for datacenter networks, you will generally see the best load balancing and overall performance by configuring your team with:

  • Teaming mode: Use Static or Dynamic ( LACP ) network teaming modes with intelligent core switches that provide support for teaming
  • Load balancing mode: Use Address hashing for network load balancing mode to gain the best level of bidirectional load balancing
  • Network isolation: Use separate NIC Team Interfaces with individual VLANs configured for each type of datacenter network traffic
image
Datacenter Networks – Teaming Parameters


image
Datacenter Networks – Separate Team Interfaces for each VLAN

This configuration works well for static datacenter networks because it provides resilient, high-speed network connectivity while leveraging VLANs to isolate major categories of back-end network traffic for security and QoS.  VLANs and VLAN tags are well understood in modern datacenters, and this approach implements a network architecture that integrates well with other hardware devices that may exist in the datacenter.

Client VM Networks

If datacenter networks are “back-end” networks, think of Client VM Networks as the “front-end” networks that carry client-server traffic between client devices and VMs.  In contrast to the relatively static datacenter networks discussed above, Client VM Networks tend to be much more dynamic in nature.  As new sets of applications are brought online for “customers”, which could be internal or external application consumers, it is often advantageous to be able to isolate traffic from collections of applications for security, routing or QoS purposes.  However, minimizing network router and switch reconfiguration for these dynamic networks is also important to delivering a maintainable Private Cloud solution.

While VLANs could be used to isolate Client VM Traffic from different applications, there are a couple common limitations that you’ll likely encounter if you have a larger environment that is hosting lots of applications for lots of “customers”.  First, managing large numbers of VLANs in an enterprise network can be complex – a level of complexity that often needs to “touch” many Layer-2 devices with every VLAN change to handle traffic efficiently.  Second, most network switches have finite limits on the maximum number of VLANs that they can handle concurrently – even though many intelligent switches appear to support VLANs with a maximum ID value of 4,094, most switches cannot efficiently process traffic from more than 1,000 VLANs concurrently.

To provide resiliency, load balancing and traffic isolation for these dynamic Client VM Networks, you will generally see the best results by configuring your network teams for:

  • Teaming mode: Switch independent – this mode supports even non-intelligent Layer-2 network switches and does not require configuration changes on intelligent network switches.
  • Load balancing mode: Hyper-V port – this mode distributes the virtual MAC addresses of each VM’s virtual NICs evenly across all available physical network adapters in the team.  By doing so, you will gain inbound and outbound load balancing of aggregate VM network traffic on each Hyper-V host. However, each VM virtual NIC will be limited to the maximum bandwidth available via 1 physical adapter in the network team.
  • Network isolation: Windows Network Virtualization ( aka WNV or NV-GRE ) – Windows Network Virtualization isolates network traffic on each VM network by using GRE tunneling between Hyper-V hosts.  As such, we can use this configuration to effectively separate traffic between Hyper-V hosts on a VM-by-VM or Application-by-Application basis without any configuration changes required on intermediary switches. … and no VLANs to manage!
     
    NOTE: If your physical network configuration requires that you absolutely MUST use VLANs to isolate VM traffic, you can certainly still do so – Hyper-V supports VLAN tags in the VM Settings of each VM.
image
Client VM Networks – Teaming Parameters


image
Client VM Networks – Only Default VLAN configured, because WNV used for isolation

OK! I’m ready for the “How” …

Once you’ve decided when to use each of the teaming modes, load balancing modes and network isolation options in your Private Cloud network foundation, leverage these great resources to step through how to configure each component:

What’s Next? Check out the rest of the series!

This article is part of a series of articles on Building Your Private Cloud with Windows Server 2012, Hyper-V Server 2012, System Center 2012 SP1 and Windows Azure.  Check out the complete series at:

And, as you read along in this series, be sure to download each product so that you’re prepared to follow along through the configuration steps as you go …


, , , , , , , , , ,
Published at DZone with permission of Keith Mayer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)