Operational Considerations for Network Functions Virtualization – Part 1

Just a few weeks back I had the pleasure to present at VMworld 2014 in San Francisco. My session „OPT2029 – Considerations for Operational Efficiency in Telco Cloud Deployments“ covered various aspects around Network Functions Virtualization Infrastructure and it’s impact on existing operational models.

Why is NFV important after all? Well, let’s take a look at ETSI’s summary of the key benefits for Network Operators and their customers:

  • Reduced operator CAPEX and OPEX through reduced equipment costs and reduced power consumption
  • Reduced time-to-market to deploy new network services
  • Improved return on investment from new services
  • Greater flexibility to scale up, scale down or evolve services
  • Openness to the virtual appliance market and pure software entrants
  • Opportunities to trial and deploy new innovative services at lower risk

Now, I’d like to start with a quick overview picture around Network Functions Virtualization that I created from ETSI’s NFV overview documents:

ETSI NFV

As you can see, NFV is split up into various parts:

  • NFVI or Network Functions Virtualization Infrastructure
  • VNF or Virtual Network Function(s)
  • NFV M&O or Management and Orchestration
  • Service, VNF and Infrastructure Description
  • OSS / BSS

In this post, I’d like to focus on considerations around introducing NFVI:

ETSI NFVI

One very important thing is that you will only see most of the NFVI benefits come to live if you concentrate on as few NFV Infrastructures as possible. Each NFVI not only means fragmentation of resources but also operational complexity as each „silo“ will have specifics that need to be operated in a separate way. Even though the underlying resources will most likely be consumed via API, the actual infrastructure requires operational procedures. So for the following parts, I will focus on a shared NFVI environment, not fragmented NFVIs:

Fragmented NFVI

As with most IT-related infrastructures, terminology and methodology from ITIL comes very handy to describe and differentiate the necessary processes for Service Strategy, Service Design, Service Transition and of course Service Operation. My experience with Service Operation in a virtual environment is very similar to VMware’s Cloud Operations methodology and publications around Operations Transformation. Some of the ITIL functions need to be much closer aligned than in traditional operations, e.g. Demand, Capacity, Performance, Incident, Problem and Configuration Management.

Also, in a completely shared environment, there will be a logical separation between „Tenants“ and „Provider“ or in our case VNF and NFVI. But this implies a new central function for taking care of NFVI holistically: a NFVI Center Of Excellence. This NFVI COE will be covered in the next part of this series.

New VMware Hands-On Labs available!

I just came across the VMware Hands-On Labs website and was excited to see many great new labs available there. Check them out!

For starters:

A new group, focussed on IT outcomes:

SDDC Labs:

VMware EVO:RAIL Demo

My colleague Duncan Epping (Twitter/Blog) just uploaded a video recorded by EVO:RAIL lead engineer Dave Shanley to demo the setup and usage of VMware EVO:RAIL.

You can read more about EVO:RAIL (the 4 node/16 hosts, 15-minute-setup solution with many partners) and EVO:RACK (in tech preview) at:

Edits:
Sept 2: added more links to the additional materials section

VMworld 2014 – Summary, Notes and Links

no-limits

VMworld 2014 is in full swing. After an amazing Day 1 and many announcements made in the General Session, Day 2’s keynote had even more technical details and demos about the announcements.

Day 1 Keynote:

Day 2 Keynote:

I just want to put my personal summary, notes and links out here. I’ll continue to work on this as well.

So, what was announced and why is VMworld so exciting so far?

First of all: The VMware EVO product family. It’s VMware’s entrance in the Hyper-Converged Infrastructure market. You can read more about EVO:RAIL (the 4 node/16 hosts, 15-minute-setup solution with many partners) and EVO:RACK (in tech preview) at:

Announcement of vRealize Suite as a comprehensive Cloud Management Platform (CMP) for Hybrid Cloud Environments. It also includes the renaming of multiple products:

  • vCloud Automation Center to be renamed to vRealize Automation
  • vCenter Operations Management Suite to be renamed vRealize Operations
  • IT Business Management to be renamed vRealize Business

If you want to learn more, check out:

Interviews with VMware Executives during VMworld:

Containers: there has been a lot of interest and discussion around Docker and Containers in general. As part of the general sessions, VMware involvement in this space has been explained in more detail:

Announcement of VMware Workspace Suite

VMware joins Open Compute Project as Gold Member.

VMware Integrated OpenStack. There were some exciting news around VMware’s Integrated OpenStack product. The overall goal is to provide OpenStack APIs to developers, have a reliable and production-grade OpenStack, simplify OpenStack deployment and operation as well as a single support contact. You can find out more at:

 

Edit Aug 27: added Horizon Workspace Suite announcements
Edit Aug 28: added Keynote videos

Network Functions Virtualization

Virtualization and Cloud Computing (IaaS) have been around for quite some time now. Many industries have introduced a „Virtualization-first“ or even a „Cloud-first“ policy for new applications in their datacenters. IT departments and their customers have seen significant benefits over the past five or even ten years.

At the same time, there are areas where hardware-centric deployments are still dominant. But even these industries are seeing major changes. One great example are Telco providers world-wide.

As a result, the European Telecommunications Standards Institute (ETSI) has established an Industry Specification Group which is focussing on a very interesting topic called Network Functions Virtualization (NFV).

Here is what ETSI is saying about NFV:

Telecoms networks contain an increasing variety of proprietary hardware appliances. To launch a new network service often requires yet another appliance and finding the space and power to accommodate these boxes is becoming increasingly difficult, in addition to the complexity of integrating and deploying these appliances in a network. Moreover, hardware-based appliances rapidly reach end of life: hardware lifecycles are becoming shorter as innovation accelerates, reducing the return on investment of deploying new services and constraining innovation in an increasingly network-centric world.

Network Functions Virtualisation (NFV) aims to address these problems by evolving standard IT virtualization technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage. It involves implementing network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in, various locations in the network as required, without the need to install new equipment.

So it’s all about time to market, agility and cost savings through standardization and reduction of operational complexity. It’s about bringing the benefits of virtualization and Infrastructure-/Platform-as-a-Service to Telco environments. ETSI has also published several NFV Use Cases that can be found in GS NFV 001.

For now, I’d like to share a few links and resources. I’ll post more about this topic in the near future.

– VMware CEO Pat Gelsinger at Mobile World Congress 2014 (Video).

– Blogpost by Ben Fathi (VMware CTO, follow him on Twitter) about NFV – Transforming the Operational Model of the Network.

– VMware’s Principal Engineer Bruce Davie (follow him on Twitter) on NFV and Network Virtualization in 2014.

– VMware’s Solution Exchange that has a special area focussed on Network Functions Virtualization.

– There is a great whitepaper by Lightreading available.

– Blog: „VMware guiding telecom industry on journey towards network function virtualization and software-defined networking“.

Run DRS

In my role as a Technical Account Manager (TAM), I get to work with highly skilled engineers and architects at our customers and partners that put VMware’s products to great use in their datacenters. And even though I am pretty used to all the positive impact these products deliver, I still enjoy seeing the long-term benefits of vSphere happening every day.

One of the examples I’d like to share today is the usage of VMware’s Distributed Resource Scheduler (DRS). This technology has been introduced more than six years ago and still plays a key role to the core virtualization infrastructure. DRS automates the migration process vMotion to load-balance virtual machines across ESXi hosts in a vSphere Cluster.

Last year, the DRS fans and bloggers Frank Denneman and Duncan Epping even came up with a great t-shirt design for VMworld:

run_drs_shirt

„Run DRS“ – this is exactly what a customer of mine is doing with huge success. They were so kind to send me a screenshot of one of their vSphere clusters including the current amount of vMotion processes (initiated by DRS) that happened in the past 1.5 years:

DRS_vMotion

More than 18.000 vMotions in one vSphere Cluster. In less than 1.5 years. That’s roughly 30 vMotions per day. It’s hard to imagine what the datacenter operations team would do without this. But they implemented a well-designed architecture and benefit from the flexibility of this technology every day. Do you?

VMware NSX – ESX for Networking

Do you still remember the first virtual machine you created? The first hypervisor-based server that you worked with? I do. And do you want to know why? Because it was such a great experience compared to all the steps that were related to setting up a physical server in the datacenter. Identifying a rack, network cabling, ordering storage capacity, labeling all cables… But before that you had to choose the appropriate (final) server hardware. What does the customer actually need? 2 or 4 sockets? How much memory? How many NICs? Because any hardware upgrade would become pretty complex. You still remember those days? I don’t want to go back…

So, where are we today? We still need to deploy servers in racks. But (at least to my observation), this process has lost it’s complexity. Besides a certain standardization of ESXi hosts and their storage and network connectivity, resource pooling and capacity management on a cluster or virtual datacenter level brought more agility to the infrastructure.

Deploying a new VM on an existing vSphere infrastructure is pretty easy. From a compute and memory perspective, there is (nearly) always an empty slot somewhere in the cluster.

For storage, the introduction of Thin Provisioning and Storage DRS have provided lots of flexibility as well. You are now able to place new VMDKs on shared datastores more efficiently. And – if necessary – there is still the option to change the size of the individual VM or to (Storage) vMotion a VM for example from it’s temporary to a production location. Elasticity, flexibility, agility – we are done, aren’t we?

We are not. One of the biggest limitations I am seeing these days is around networking. Truth is, compute and memory resources are very often fragmented by networking constraints. „This VLAN is not available in this part of the datacenter“, „the customer can only work with this VLAN/IP range“, „we don’t have Firewall capacity and need to order a new hardware appliance in this network segment“. If you hear any of these comments, it means additional complexity. And time.

Last year, VMware acquired a company called Nicira to address this „missing piece“ of the Software-Defined Datacenter vision. And just a few weeks back, VMware announced „NSX“ – or „ESX for Networking“ as I will call it.

In VMware NSX, the very best of Nicira’s Network Virtualization Platform (NVP) and VMware’s vCloud Networking and Security will come together to virtualize the network.

Quoting the blog article:

VMware NSX exposes a complete suite of simplified logical networking elements and services including logical switches, routers, firewalls, load balancers, VPN, QoS, monitoring, and security; arranged in any topology with isolation and multi-tenancy through programmable APIs – deployed on top of any physical IP network fabric, resident with any compute hypervisor, connecting to any external network, and consumed by any cloud management platform (e.g. vCloud, OpenStack, CloudStack).

Personally, I am pretty excited about the things to come. And the day, on which I can say: I virtualized my first network

Horizon Workspace behind a DMZ loadbalancer

During the implementation of Horizon Workspace at a customer I’ve experienced a quite challenging situation last week. While the installation was a pretty straight forward process if you stick to our install guide we weren’t able to reach Horizon from outside the company network.  After typing the external web address in the browser it always went to the internal address which of course wasn’t reachable from outside. The setup was exactly our reference architecture shown in the picture below with a loadbalancer in the DMZ that points to the Horizon Gateway appliance on the internal network.

Horizon Workspace
(Source: https://www.vmware.com/files/pdf/techpaper/vmware-horizon-workspace-reference-architecture.pdf)

After some troubleshooting we found a very easy solution, but it was not that obvious or very well documented. When the OVA has been deployed you have to check the DNS resolution for all internal and external names and make sure the PTR record (reverse resolution) is working. It’s critical that no aliases for the names are configured, the reverse resolution is working fine and no other records (MX,etc.) are configured. Now comes the important part: while completing the console-based configurator menu after starting the vApp it’s absolutely important to enter – when asked by the wizard – the EXTERNAL name, i.e. horizon.yourcompany.com as the Horizon FQDN and NOT the internal name, i.e. horizon.justforinternal.local. In other words enter the name which points to the loadbalancer and not the name of the Horizon gateway-ca.

Once that configuration was done, it worked like a charm!