Reg comments5

Do you speak NFV? Time to go back to school and learn

Software – not shelves – is the answer, whatever the other kids may say

classroom_shutterstock_648

Administrators have some growing up to do before they're ready to properly implement Network Functions Virtualisation (NFV), as it not only has to be automated and integrated into extant management systems, it needs to be a lot more lightweight than most administrator believe is possible.

NFV is the ability to stand up, tear down, automate and orchestrate network elements in some easy-to-use manner. Network elements can include switches, routers, firewalls, Intrusion Detection Systems (IDS), monitoring, port mirroring, and even entire clusters of virtual or physical server instances.

In some cases, many of these functions are performed by a single virtual machine. In some cases multiple virtual machines are required. In still other cases, hardware appliances are used.

Depending on how things are set up, NFV could involve spinning up a new VM to perform a single function for every instance where some network functions are required. This is the least efficient way to go about things.

Rationally slicing up our networks

Working with Yottabyte has recently given me an appreciation for how this is balanced. In Yottabyte's world, everything is about "virtual environment". Each virtual environment has its own dedicated slice of storage, storage policy, VMs etc. More critically, each virtual environment has a single NFV VM that provides basic routing, firewall and NAT.

Virtual environments can be used in any number of ways. You can create one for each service you deploy, or – if you really wanted – for each VM. In reality, Yottabyte sees that on-premises customers create virtual environments to encapsulate collections of like VMs and services that typically have to interoperate closely, and use the NFV VM to defend it.

Service providers using Yottabyte, including Yottabyte itself, usually create a virtual environment per customer – though nothing stops a customer from having more than one. This is roughly mirrored by how other cloud providers handle NFV.

I know of several OpenStack cloud providers that slice up their networks in a manner very similar to Yottabyte's virtual environments. Signing up as a customer gets me some storage space and a single NFV VM. I can spin up more NFV elements if I need, but that one VM will probably handle all my needs until I start scaling to several hundred workload instances.

If I go to Microsoft’s Azure and spin up some services, what I am given looks very similar. I am given what appears to be a single NFV VM, unless I explicitly create more. That VM can handle load balancing, firewall NAT and more. Of course, Azure is a lot less transparent.

What appears to me to be a single NFV VM could in fact be my "virtual slice" of an NFV VM that handles multiple customers. Right now, today, I don't think Microsoft is doing this – mostly because Microsoft likes using Windows and Windows doesn't really have the technology for it. Having said that, the multi-tenant capabilities in Windows Server 2012 R2's RRAS could well make a liar out of me here.

In the Linux world, I'm seeing this sort of "multi-tenant NFV" increasingly done with containers. A single NFV VM is stood up with some services operating in a multi-tenant mode (the firewall and load balancer are generally capable of this) while other services (such as IDS and monitoring) are provided via containerised instances.

Multiple users share an NFV VM, largely unaware that they are doing so, until one or more of them place such a strain on the NFV VM that the system (or the cloud admins) decides the "noisy neighbour" needs their own NFV VM.

Sponsored: The Joy and Pain of Buying IT - Have Your Say


Biting the hand that feeds IT © 1998–2017