Building Next-Generation Data Center

12 module online course

Start now!

Virtualize Network Services

ipSpace.net » Documents » Optimize Your Data Center Infrastructure » Virtualize Network Services

After virtualizing the compute and storage infrastructure, it's time to virtualize the network services, and it's amazing how many vendors started offering virtual appliances in the last few years. Unfortunately, these appliances are usually nothing else than the traditional products repackaged in VM format with low-level packet forwarding code rewritten to work with paravirtual drivers.

Let’s start with virtual routers. Vyatta (now Brocade) was probably the first commercial virtual router, with Juniper with their virtual SRX being close behind them (whether you call vSRX a router or firewall is a different story). Cisco launched Cloud Services Router (IOS-XE) a few years ago, and today every major network vendor (including HP and Alcatel-Lucent, now Nokia) has a virtual router. You can also get service provider-focused products like Cisco IOS XR or Juniper vMX in virtual format.

Want to know more about benefits and drawbacks of virtual network services appliances? We discussed them in Designing Private Cloud Infrastructure and Network Function Virtualization webinars.

Every major firewall vendor has a virtual firewall. It started with Juniper vSRX a long time ago, Cisco launched vASA and ASAv a few years later, and Palo Alto and Checkpoint quickly followed suit. The situation is very similar in load balancing market. In short, whatever network services box you need, you can get it in a virtual appliance format today.

Why would you want to replace physical network services devices with virtual appliances? You’ll immediately gain increased flexibility because you can deploy virtual appliances whenever you need them. There are no racking and stacking delays, and sometimes you can use temporary licenses to streamline the acquisition process and deploy network services on-demand.

Interestingly, once something runs in production on a temporary license, budget usually stops being a problem.

Virtual appliances also simplify high availability and disaster recovery designs:

  • Quite often you don’t need redundant firewall or load balancer pairs (or clusters) because you can restart a virtual appliance in a few seconds.
  • You can always restart the virtual appliances (remember, they are just virtual machines like any other virtual machine) in your disaster recovery data center, so you don't need spare hardware sitting idle in your DR location.

The only hardware you need in a disaster recovery data center that relies on virtual appliances is enough compute capacity so that you can run the extra workload when your primary data center dies.

The savings you gain with virtual appliances became so obvious that F5 started charging more for the virtual load balancer than for the physical one because they know that you will only buy one virtual load balancer when previously you had to buy four physical ones.

We already mentioned how virtual appliances reduce deployment time. They also minimize hardware sparing requirements because you don’t need a spare router, a spare firewall, a spare load balancer, a spare IDS, or an expensive hardware maintenance contract, because you’re running all network services on unified compute infrastructure.

Finally, using virtual appliances simplifies the physical network infrastructure. Instead of a spaghetti mess of hardware appliances connected to data center switches at just the right point (shown in the left-hand side of the following diagram) you’re left with servers connected to a leaf-and-spine fabric.

You could argue that we virtualized the spaghetti mess and you’d be absolutely correct.

Going even further: if you decide to use distributed file system and virtual network services appliances in your data center, then you need just two hardware components: switches and servers. Imagine how that would reduce the costs of your maintenance agreements.

Some engineers went as far as connecting their private cloud to the public Internet straight through virtual SRXs running on their servers.