In Part I, we looked at how Logical Networks fit into a Virtualized Network solution. In Part II, which is split over a number of different posts, we focus our attention on Logical Network design and architecture. As with all of the previous posts , it’s taken a lot longer to develop this material than first planned but we hope you think the content was worth the wait. Look forward to your feedback and comments.
In the next post, we begin to introduce security considerations into the Logical Network design process, reviewing each Logical Network to determine whether or not there is a need to isolate different groups of virtual machines and services and if so, how that isolation can be best achieved.
Nigel Cain & Damian Flynn
As a starting point, it’s useful to return to the definition of a Logical Network as outlined in the VMM documentation “ A logical network is used to organize and simplify network assignments for hosts, virtual machines and services…. they can be used to describe networks with different purposes, create traffic isolation and even support traffic with different types of service-level agreements”. [Emphasis added]. As logical networks represent an abstraction of the underlying physical network infrastructure, they enable you to model the network based on business needs and connectivity properties.
In the following sections, we take a look at some of the main reasons why you would (or would not) create a Logical Network, provide an overview of the key considerations, outline some best practice guidance and recommendations for identifying Logical Networks in your environment and ultimately, try to help answer the question “how many logical networks do you really need?”
Note: It is important to remember as you work through this blog post that VM Networks provide the (network) interface through which virtual machines will connect to a particular Logical Network. We look at VM Networks in more detail in the post on logical network isolation.
From previous blog posts, we know that least one Logical Network needs to be associated with a given host computer for it to be able to support deployed virtual machines and services. To help ensure this is the case, SC VMM verifies that physical Network adapters on all new host computers are associated with one or more Logical Network(s).
If no such association exists, VMM checks to see if a Logical Network exist with the same name as the first DNS suffix label on each network adapter - in the case of server called REA-HST-01. Corp .Northwind.Com for example, it would expect to find a pre-created Logical Network called “ Corp ”. If it does find a match, it will automatically associate the host network adapter with the selected Logical Network. If it does not, VMM will create a new Logical Network with that name (“Corp” in our example) and make the necessary association with the host. If the new host computer is connected to a number of different physical networks, VMM could potentially create a new Logical Network for every physical network the host is connected to.
In a test or proof of concept environment, this type of behaviour is perfectly acceptable since you want to get up and running as quickly and easily as possible but if you follow the guidance in this blog post, however, you will have carefully planned and structured your environment and will want to purposely associate a host with the required Logical Network(s) rather than rely on any default behaviours. We therefore recommend turning this setting off (as shown below). The same is true of the option to automatically create Virtual Switches but we will discuss this in a future blog.
If you did leave this setting on initially, you can certainly turn it off at a later stage but be aware that VMM will not allow you to delete any default logical network(s) that have existing associations with network adapters in your host computers. You will need to associate these adapters with different Logical Networks first. You may also have to remove VM Networks and other objects that have dependencies on these logical network(s) before you can successfully delete them.
There are a number of reasons why you might need to create a Logical Network; to facilitate the movement of virtual machines and services across different physical locations, apply settings and capabilities to hosts or virtual machines that have specific network requirements or which require guaranteed service levels, to isolate network traffic or to facilitate access to networks that are configured through / managed by third party network management tools. As a result, there is no clear and simple answer to the question “how many Logical Networks do I need”, since the number will depend on your business requirements, your physical network and any constraints that exist in your physical environment.
We consider a step by step approach to Logical Network design to be the best way to achieve this, starting from the basic principle that you should aim to start as simple as possible, adding additional Logical Networks only where there is a compelling business or technical reason to do so. The process can be summarized as follows – we cover step 1 and 2 in this blog, the remaining steps will be covered in future posts.
Finally, as with everything else, defining and adhering to a sound naming convention for Logical Networks is important both from the perspective of promoting understanding as well as helping to simplify management and reduce cost.
As an initial starting point, you should consider creating a logical network that maps to each of the physical networks that exist in your environment. In reality, and as we will discuss in more detail below, you will probably create many more logical networks than you have physical – logical networks may be created to support host and virtual machines with different purposes; development, test or production, for example, isolate network traffic and/or to support different network service levels but the principle of creating one Logical Network for each Physical Network is a useful beginning.
In the example below, our Seattle location contains two physical networks. The Datacenter network is used for corporate production workloads and cloud infrastructure traffic (live migration, cluster, storage and management) with the Provider Network used for traffic from virtual machines. As a starting point, we would consider creating two logical networks in SC VMM; one for each physical network, as shown in the diagram below:
This initial logical structure is a starting point only - as we will discuss over the course of this blog, you may find that you need to create additional logical networks but you should aim to start as simple as possible, adding additional logical networks only where there is a clear business or technical reason for doing so.
The next step in our design process is to review the different computers, virtual machines and services such as storage, backup, management, etc that will be connected to and use the (same) physical network. As the VMM documentation outlines, Logical Networks enable you to define networks that serve a specific purpose and/or which perform a particular function within your environment, with Port Profiles (which we covered in Part I but will discuss in much more detail in our next blog) used to apply the appropriate properties, capabilities and priority tags to computers which use that network.
Note: If you find that the physical network is dedicated to a single purpose, a single Logical Network which maps directly to the physical network may be all that is required. In these cases, you can move straight into Reviewing the Network Isolation Requirements (which we will cover in the next post)
In our example organization, the Datacenter physical network carries network traffic for both Cloud Infrastructure (including live migration, cluster traffic, storage and host management) as well as that created by Corporate (internal) Services and Applications. In Step 1, we started with a single logical network “datacenter”, the key question is whether this simplistic approach will be sufficient for our needs or whether we should consider creating a number of logical networks.
Logical Networks are often used to apply different service levels and capabilities to cloud infrastructure component such as cluster node communication, iSCSI and SMBv3 storage, backup services, Live Migration and infrastructure management since in the majority of cases, you will want to apply different capabilities, bandwidth controls and network traffic prioritization to each one of these services. We have chosen to follow this best practice approach to design in our example since it provides us with the ability to apply different Quality of Service (QoS) levels to each one of these services.
Corporate (Internal) Applications and Services
Although a single Logical Network may be your initial starting point for corporate (internal) services and applications, it becomes apparent very quickly that you need to create logical networks for production and development/test workloads. Production systems are likely to be allocated the largest share of the (available) bandwidth and network traffic from these systems needs to be prioritized. As we discussed in Part I, you may even have a policy which mandates that only production workloads are permitted on certain servers in your environment and you achieve this, in part, by defining a separate Logical Network and associating this network with the selected host computers (see Logical Networks, part I for more information)
In our example organization, development, pre-production and production workloads will all share and co-exist on the physical “Datacenter” network and as a consequence, we have decided to create three separate Logical Networks as shown below, one for each type of workload. We will use Port Profiles to apply the required properties and capabilities to each network, including bandwidth limitations and IEEE Priority tags.
The SC VMM 2012 SP1 documentation also suggests that you consider creating separate Logical Networks for the front end (web servers) and the backend components (application and database servers) of multi-tier applications. The primary benefit of this approach is that it allows you to use Network Sites – of which more later – to define the set of VLANs and IP Subnets that will be used by virtual machines in each tier and, further, through the use of port profiles, apply a different set of security settings and capabilities to each network.
Since our example organization is expecting to deploy and use multi-tier applications, we have decided to further refine our design and create separate logical networks for the front end and backend components – as shown below. Production systems that are not part of a multi-tier application will connect to and use the Backend logical network.
Once you have identified the set of Logical Networks that should be created on one of the physical networks that exist in your environment, you need to turn your attention to and perform a similar exercise on all of the others.Hosted Software and Services
If we assume our example organization is a Service Provider (Hoster), meaning that it offers hosted software and services, which include web hosting, application hosting, messaging, collaboration, and platform infrastructure, to its end customers, the Provider network we mentioned earlier will most likely be dedicated to and used exclusively for customer (tenant) network traffic. The physical separation between customer network traffic on the Provider Network and Cloud Infrastructure/Internal traffic on the Datacenter physical Network helping to improve security, simplify management and additionally, removing any potential competition between customer and internal workloads.
Note: Although there are organizations whose primary business is that of Service Provider, in the context of our discussion, the phrase can equally be applied to enterprise customers who wish to provide hosted software and services internally and/or to their customers or business partners. The discussion relating to physical network design in the sense of planning to separate Internal/Cloud Infrastructure and Customer (tenant) workloads is hence as valid to these organizations as it is to the dedicated Service Provider. You can find more details at the following location:
In designing a logical network solution for a provider network such as the one in our example, your first consideration is compute model(s) you intend to support – essentially whether workloads from multiple customers will run on the same physical hardware (shared compute) and/or if you intend to dedicate certain host computers and resources to a single customer (dedicated compute). Setting aside the discussion around security and how you can and should isolate customer workloads from each other, since we will return to this point later in the blog, you should initially plan on creating a single logical network for the shared compute workloads and a logical network for each customer with a set of dedicated resources.
Our example organization provides customers with the option of having their workloads hosted on shared or dedicated resources. Two customers have taken up the option of having physical servers dedicated to their workloads, with the remainder utilizing the shared compute model. The logical network design (ignoring isolation requirements) to support this scenario is as shown in the diagram below. The design assumes that as new customers with dedicated compute requirements are onboarded to the service, additional logical network(s) will be added to the solution. In reality and in common with what we discussed for the Datacenter network above, you may find you need to extend this initial model, breaking out / defining additional Logical Networks to support a specific (hosted) service or to provide for a specific business or customer requirement.
In the case of customers with dedicated resources, you will use Host Groups and Network Sites in SC VMM to associate the Logical Network with the host computer(s) within each physical location that either have been allocated to / reserved for that customer.
At the end of step 2 of this process, you should have arrived at a set of candidate logical networks for each physical network in your environment. As mentioned earlier, we have to this point purposely ignored security and the need to isolate/separate network traffic – something which is clearly a key consideration for Service Providers hosting external customer workloads and enterprise customers wishing to isolate network traffic from certain business groups or restricted (special) projects. The isolation options we discuss in the next blog post , and which you should review for each logical network you have identified thus far, may lead you to create additional Logical Networks or at least further refine your Logical Network design but at this point, you know which networks you need to support your business and perhaps more importantly, why you need them.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.