Move your VMware and KVM applications to the cloud without making any changes

  • January 27, 2016

NFV Orchestration: Overcome multi-tenancy challenges (part 1 of 4 post series)

Matt Conran
Matt Conran is a Network Architect based out of Ireland and a prolific blogger at Network Insight. In his spare time he writes on topics ranging from SDN, OpenFlow, NFV, OpenStack, Cloud, Automation and Programming.

This article details NFV orchestration using public cloud NFVI as a 4 part series. This post looks into challenges traditional networks have with multi-tenancy and workload mobility. In the next, we'll show how Network Function Virtualization (NFV) fits in and can increase service velocity.

Leap-frogging the network to the advances in data-center

Over the last 10 years there has been an increasing proliferation of virtualization, primarily seen in the areas of compute and storage. However, in a data centre there is an additional functional block called the network. Networks have been lagging behind with slow innovation and has not virtualized to the same extent as storage and compute. We need to view and manage the network as one large fabric system in a centralized fashion. To increase agility, the network must become programmatic and not viewed as individual nodes managed box by box. Central view and managerial points for the network increase network efficiency.

Networks should be consumed by the consumers of the infrastructure in a self service manner. For example, an application developer can deploy a stack without having to wait for the network team to provision rules or by interacting with multiple technical teams for deployment. The network must become seamless and automated. The ability to rollout network services, applications in VM or containers without network intervention is key to increase time to market.

There has been a transition from hardware centric data centres to agile virtual cloud data centres. One important aspect of the cloud data centre is that infrastructure is being consumed as a service. When infrastructure is consumed as a service, then the consumers of the infrastructure become the tenants of the cloud infrastructure. Multiple tenants accessing cloud's resources make the cloud data centre multi tenant in nature. In a public cloud, this would be resources made available to multiple customers. In a private cloud, this is resources made available to different departments or organisation units. Multi-tenancy and the ability for many customers to share resources puts pressure on traditional networking technologies.

Issues resulting from network multi-tenancy

Securing multi tenant cloud environments drives the need for tenant isolation. Tenant A should not communicate to tenant B, without explicit permit statements. A tenant should consist of an independent island of resources, protected and isolated from other islands. Every tenant should have an independent view of an isolated portion of the network and peak loads should not affect neighboring tenants in separate virtual networks. Noisy neighbors are prevented by policing and shaping at a VM or tenant level. Both shaping and policing limit the output rate but both with functional differences.

Security is a major concern in multi tenancy environments and breaches in one tenant should not affect others. Beachheading, the process of an attacker jumping from one compromised location to the other should not be permitted. And if a tenant becomes compromised, traffic pattern and analytics should be provided, enabling the administrator to then block the irregular traffic patterns caused by the attacker.

Increasing number and type of applications are moving to the cloud but unfortunately traditional network infrastructures are not near agile enough to support them. Traditional networks are not designed for the cloud or to connect virtual endpoints within a cloud environment. Originally, they were invented to connect physical end points together. We are beginning to see the introduction of software based network in the form of overlays used in combination with traditional physical networks, underlays.

Legacy VLANs are used to segment the network, which has proved to be inefficient to segment a dynamic and elastic multi tenant network. VLANs are very tedious and intervention was needed on every switch in the data centre as tenant state was held on individual nodes in the fabric. VLANs also restrict the number of tenants due to the number of bits available, limiting you to 4096 VLANs. This will soon run out when deploying multi tenant tier application stacks. VLAN designs also require MAC visibility in the core and when a switch runs out of MAC tables size it will start to flood. Unnecessary flooding wastes network bandwidth and hampers network performance. Also, layer 2 domains convert to a single broadcast and failure domain, causing havoc in the event of a broadcast storm. Instead of all these kludges we need to run networks over IP. Similar to how Skype runs over the Internet. Scalable networks are built over IP and overlays can be used to provide Layer 2 connectivity.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.