Metaswitch has gained a wealth of NFV experience by helping customers take our virtual network functions (VNFs) from proof of concept to lab trials to production networks. Along the way we have learned a lot about what works and what doesn’t and how to overcome unexpected issues as they arise.
It certainly helps if your VNFs are cloud native - and we'll shortly be running some educational topics on the benefits of being truly cloud native - but here's a quick summary of some of the lessons we've learned so far about deploying NFV:
- NFV is not a silver bullet. Virtualization does a lot of things differently and cleverly, but it doesn’t change the fundamentals of rolling out telco quality networks, particularly when it comes to redundancy and availability. Simply porting some monolithic code from a real chassis to a virtual one, isn't going to bring the benefits originally touted by NFV. Sofware needs to be written as "cloud native" with a specific understanding of how to provide five nines of availability from a cloud infrastructure that isn't.
- Virtualizing real-time products needs careful configuration. Voice and video are real-time applications and have different requirements from enterprise IT applications. It’s important to consider things like the time synchronization of virtual machines (VMs), distribution of VMs across hosts, and even the disabling of some cloud OS features that are not suited to real-time apps.
- Virtual networking needs to be redundant. NFV platforms (think VMware VCloud NFV for example) makes it quite easy to set up virtual networking via graphical user interfaces (GUIs). You can configure multiple virtual switches and logical mappings between the ports and the network interface cards (NICs) to achieve redundancy. And you should.
- Tips for redundancy and availability. High levels of service availability come from a combination of writing your VNFs the right way (aka "being cloud native") and features that might be available in your NFV platform. VMware for example offers a couple of tools for improving availability and redundancy. VMware HA (high availability) monitors VMs and hosts and if a host fails, it will automatically restart the VM on another host. This requires shared storage. The other tool is VMotion, which allows live migration of VMs between hosts with practically no impact on services.
- Understand storage requirements. There are many options for storage. Generally, the choice is between local or shared. With local storage, the VM uses part of the physical hard disk on the host. The disadvantage is that if the host fails, then you will lose access to the hard disk that the VM is running on, which will have to be resolved. With shared storage, there are numerous options: network attached storage, physical filers, VMware’s vSAN. Metaswitch will work with any kind of storage, so long as it meets some minimum requirements. Typically, we recommend shared storage.
- Real time media can be handled too. The media handling component of our Perimeta vSBC is an extreme example of a real-time voice application. Depending on the capacity that you need, you might use SR-IOV (single root input/output virtualization) to accelerate throughput and reduce latency by removing the overhead between certain VMs and NICs. It’s fully supported in VMware, but watch out because not all NICs support it.
- VMware or OpenStack? VMware might just be the easiest way to deliver a redundant, highly available virtualized network today. With a few days of training, you can be competent to operate a VMware deployment. OpenStack's made a lot of progress of late, but it's a toolkit and you normally have to build your own solution, which requires ongoing DevOps resources and investment. Alternatively, service providers could choose an OpenStack partner that has its own distribution and will install it for them.
- It works. If you’ve set it up right, a virtualized network usually just works. We rarely see ongoing problems that stem from the virtualization environment. If there is a problem, it typically results from mistakes make in the initial configuration or changes made to the environment.
- Application operation and management doesn’t need to change. Well designed software-based VNFs, like Metaswitch's Perimeta vSBC, were designed from the ground up to be hardware independent. That means that when they're running in virtual environments, they can be configured and operated in the same way they were on physical hardware platforms. That makes the migration process particularly frictionless if you’re already familiar with our products.
In some ways (mostly vendor marketing), it feels like NFV has been with us for years, and already beaten to death. In other ways (the practicalities of deployment and maximizing performance), the industry is still just getting started. With more than 30 years experience of writing hardware independent, high performance communications software, Metaswitch helps companies get started on and complete their journey to NFV.
