In this blog, we begin to introduce multi-tenancy and isolation into the Logical Network design process we discussed in Part II, reviewing each of the Logical Networks we identified to determine whether or not you need to isolategroups of virtual machines and services that will use the same logical network. For reference, you can find part II at the following location:
SC VMM 2012 SP1 allows you to isolate workloads using traditional VLAN/PVLANS, Network Virtualization and forwarding extensions that offers their own isolation method. In this post we review how to configure your Logical Network for “No Isolation” where there is no need to separate workloads and what you should do / how you should design your logical network solution when you want to use traditional VLAN isolation. We will cover PVLAN and Network Virtualization in a later blog post.
Look forward to your feedback and comments.
Nigel Cain & Damian Flynn
Step 3: Determine Isolation Requirements
To help explain this concept, let’s start with the basic assumption that computers that connect to and use the same network should be able to communicate with each other, and with routers that are used to connect different networks together should we wish to allow inter-network communication. This principle holds in most cases – indeed, where we find a business need to split off or otherwise isolate certain workloads either for security, to improve performance or simply to facilitate more effective control of network traffic, we essentially create a “new” network – either physically or via Virtual Networks (VLAN or PVLAN technology), place all of the appropriate computers and services on that network and update the network routing tables and security policy to facilitate inter-network communication, should that be required. This approach will be familiar to both Enterprise Customers and Service Providers, with the latter often using dedicated VLANs and PVLANs to isolate different customers from one another.
Logical Networks in SC VMM effectively model this behavior with resources that connect to a given logical network able to communicate with (any) other resource on that the same network, with inter-network communication handled via a router or gateway device. The problem for Service Providers (Hosters) is that following this general guideline, each customer invariably required their own Logical Network - an issue which historically led them to create and manage 100s if not 1,000s of Logical Networks within SC VMM. Given that each logical network needed to be associatedwith physical network adapters in one or more host computers, this solution impacted performance as well as increasing complexity and management overhead.
Virtual Machine (VM) Networks were introduced in VMM 2012 SP1 to address this particular issue; rather than connecting directly to a Logical Network, Virtual Machines in this release connect to a VM Network which acts an interface to a particular part of a Logical Network (as shown). Since VM networks are linked to the logical network, rather than associated with physical host computers, adding, deleting and making changes to these networks is greatly simplified over making changes to Logical Networks. Additionally, if Network Virtualizationis enabledon the Logical Network as we discussed in Part I, multiple VM networks may be linked to a single Logical Network - removing the need for Service Providers to create separate Logical Networks for each of their customers.
If there is no need to separate or otherwise isolate network traffic from these machines, a single VM network linked to the Logical Network will be all that is required. As we discussed earlier, you will normally create multiple VM Networks when you are hosting workloads for multiple customers (tenants) on the same Logical Network, with each tenant needing to be isolated from and totally unaware of the existence of any others.
In VMM 2012 SP1 you can isolate VM Networks using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization. The latter option addressing the scale limitations associated with a traditional VLANs solution as well as allowing tenants to “bring their own network” or otherwise extend their network into your environment.
The diagram above shows each of these options and acts as a reference for the detailed discussion that follows. Note that the diagram is an extract from the Networking in Virtual Machine Manager Poster, available at the following location:
http://www.microsoft.com/en-us/download/details.aspx?id=37137
As the diagram suggests, you can’t mix and match different types of network isolation on the same Logical Network. It is not possible, for example, have some VM Networks configured isolated using VLAN/PVLAN technology with others using Network Virtualization. Should you need to use multiple approaches in your environment, you will need to return to step 2 above, Identify Networks with Different Purposes and define a separate Logical Network for each isolation method.
Note: There is a practical limit of ~2,000 tenants and ~4,000 VM Networks per VMM server. If you expect to approach either of these scale limitations you will most likely need to introduce additional VMM Servers and use Service Provider Foundation (SPF) to manage this environment. You should follow the same process (as above) with respect to identifying and creating logical and VM networks for each VMM server you deploy. You can find more information on SPF at the following location:
http://technet.microsoft.com/en-us/library/jj642895.aspx
No Isolation
As mentioned above, isolation is only necessary in cases where a Logical Network will be used by multiple customers (tenants). Logical Networks created for corporate (internal) workloads, cloud infrastructure services and those that are dedicated to a specific customer are all single tenant, meaning that isolation is not required.
Also mentioned earlier, at least one VM Network is required for Logical Networks that will be accessed by virtual machines. If there is no need to isolate network traffic on the Logical Network, a single VM network configured for “No Isolation” (as shown below) is all that is required. The VM Network in this case simply acting as a “pass through” to the logical network.
Note: In VMM 2012, virtual machines were directly connected to Logical Networks. When customers using this release upgraded to SP1, VM Networks, configured for “no isolation”, were automatically created for each one of these Logical Networks. Virtual machines that existed prior to the upgrade were then connected to the (new) VM Network linked to their original Logical Network.
The result of this configuration that you establish a 1:1 mapping between the VM Network and the Logical Network, as shown below. As a result you can only have one VM Network configured for “No Isolation” per Logical Network. If virtual machines that connect to this VM Network should not be able to communicate with each other, you may need to consider breaking out an additional logical network to accommodate this requirement.
For those logical networks that will not be used by virtual machines, generally those dedicated to infrastructure services like storage and live migration traffic, clearly no VM Networks are required.
VLAN Isolation
Service Providers often use dedicated VLANs and PVLANs (which we will discuss later) to isolate different customers from one another. To reflect this network architecture in SC VMM 2012, administrators had to create Logical Network for each VLAN, a solution which often led to the creation of 100s if not 1,000s of Logical Networks - since each of these networks needed to be associated with physical hosts, the end result was degraded performance and greatly increased complexity.
As we discussed earlier, Virtual Machines in VMM 2012 SP1 connect to a VM Network which acts an interface to a particular Logical Network. Multiple VM networks may be linked to the same Logical Network if Network Virtualization is enabled, with each one of these VM Networks separated from and totally unaware of the existence of any of the others. The nature of these improvements means that instead of creating a separate Logical Network for each customer that will be isolated from others using VLAN technology, you should instead create a single Logical Network for all of these customers, configuring the properties of the network (as shown below) to specify that “sites within this logical network are not connected”.
You should allocate the VLAN to a Network site within the logical network. Multiple VLANS may be allocated to the same Network Site (as shown below)
Finally, VM Networks need to be created to allow customer virtual machines to connect to and use the Logical Network. VM Networks need to be created to allow virtual machines to connect to and use the Logical Network. Each VM Network you create is directly mapped to exactly one of the subnet VLANS that have been defined for a site in that Logical Network. As a result, you can only have as many VM Networks as you have subnet VLANS. The create VM Wizard (below) will display only those Network Sites that have not already been allocated to an existing VM Network.
The added benefit of having a VM Network on top of each VLAN is that you can use a name to clearly identify what it is used for and which customer has access to it. You can also apply access control to control/restrict who is able to use it.
Although you can manually choose which VLAN should be allocated to a VM Network, VMM also provides for automatic assignment. This is useful where customers are allocated a VLAN from a pool, rather than being given an assigned / specific VLAN. In these cases, a VLAN is randomly taken from the pool when you define a new VM Network and is returned and available for re-use when that VM Network is deleted. Note that once all of the available Network Sites have been allocated, no further VM Networks may be linked to this Logical Network until additional VLANS are added and/or some of the existing VM Networks are deleted.
To briefly summarize, create a single Logical Network, configured such that “sites within the logical network are not connected”, create sites and then specify the list of VLANs that exist in each site. Either create a VM Network to represent each VLAN and/or create VM Networks as and when needed, using automatic assignment to allocate a Network Site (VLAN) to that VM Network. The net result should be a 1:1 mapping between the VM Network and the VLAN, as shown below:
Note that that there are a number of limitations to using VLANs to isolate network traffic, most significantly the scalability limits –only 4095 VLANs are permitted per physical network, PVLANs (as discussed in our next blog) may be used to work around this limitation but at cost of increased complexity. The cost of management, level of complexity and the risk of error also increase significantly at high scale. These issues may not be of direct relevance to enterprise customers since, in general, they do not need to manage very large numbers of networks at this scale but are major consideration for Service Providers that provide hosted services to a large number of external customers.
VLAN isolation is expected to remain common practice in many enterprise deployments given its relative simplicity and ease of management at smaller scale. Service Providers (Hosters), however, given their need to manage a much larger number of networks, can be expected to use alternative isolation technologies to help workaround VLAN scale limitations.
Summary
If there is no need to separate or otherwise isolate network traffic from these machines, a single VM network linked to the Logical Network will be all that is required configured for “No Isolation”. If needed, SC VMM 2012 SP1 allows you to isolate workloads using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization. We covered VLAN isolation in this post. In part IV, we will discuss how to design and configure your logical networks for PVLAN and Network Virtualization.