Home > Blogs > The Network Virtualization Blog > Tag Archives: NSX

Tag Archives: NSX

New VMworld 2014 Hands-on Labs with VMware NSX Goodness

In 2013 we introduced VMware NSX Hands-on-Labs for the first time. The NSX 1303 Hands-on-lab has been by far one of the most popular labs, giving you an in-depth view of VMware NSX. Hands-on-labs are one of the best ways to get a good tour of the product. You can take all of these labs online at http://labs.hol.vmware.com/HOL/catalogs/ . It requires a registration, but is open to everyone. .

This year at VMworld we introduced several new NSX labs to give you a deeper look at NSX, and to showcase the depth of integration NSX provides with 3rd party partners and other VMware products. All of the new 2014 Hands-on-labs have been published and are available to you. Here is a quick tour of the labs and what you can expect to see.

 

HOL-SDC-1403

If you are just getting started with NSX and want to know what Network Virtualization is all about, we recommend you start here.

HOL-SDC-1403-2nd Image

This lab will walk you through five modules of exercises:

  • NSX Components – Host Preparation, Controller deployment
  • NSX Logical Switching – building VXLAN logical switches
  • NSX Logical Routing  - Distributed Routing, Dynamic Routing with OSPF
  • NSX Distributed Firewall – Micro-segmentation with NSX
  • NSX Edge Services – Load-balancing, SSL VPN

 

HOL-SDC-1425

Once you have completed the introductory lab, we recommend taking the advanced lab which is designed to showcase some of the new features in NSX 6.1. You can read and excellent summary of these new capabilities in Chris Wahl’s blog, “NSX 6.1 Announced, Contains Plethora of Enhancements.”

This lab covers the following areas:

  • Configuring DHCP Relay so that you can use NSX with external IPAM Services
  • Scaling out Layer 3 routing with Equal Cost Multi-Pathing (ECMP) and Dynamic Routing Protocols. Yes we actually build out the topology below in the lab! That’s the power of network virtualization.

HOL-SDC-1425-2nd Image

  • Building out L2VPN services for multi-site and hybrid cloud connectivity services
  • Integration with 3rd parties using Service Composer and Trend Micro AV & IPS with NSX. You will see how to register services and how NSX is a platform to integrate with 3rd party services in this exercise.
  • Networking Monitoring with NSX & Riverbed Cascade – we will even show you how you can monitor with NetFlow in this exercise 

HOL-SDC-1424

The two labs above will surely give you a good view of NSX as a network virtualization platform. Next, let’s see how NSX integrates with other VMware products to build out a complete Software-Defined Data Center. This lab shows the integration capabilities offered by NSX with VMware management solutions.

First up, we will learn about Self-service IT, and how you can deliver applications quickly to your end-users with the integration of vCloud Automation Center and NSX. You will build out a multi-machine blueprint with networking and security, and then deploy it.

Next, if you want to learn about automation and the NSX API, we will walk you through exercises in using vCenter Orchestrator and using the NSX REST API to create a security group. This will give you the fundamentals of NSX automation which you can easily extend upon as you deploy NSX in your own environment.

The third exercise is about operations. We will show you the new NSX Management Pack in vCenter Operations. We will walk you through the dashboards and you will learn how you can actually not just monitor but also troubleshoot you network.

At this point you are surely on your way to become a NSX Ninja

HOL-SDC-1420

If you want to use OpenStack with NSX and vSphere – we’ve got you covered too! We will walk you through OpenStack on vSphere itself and then show you how to connect it to deploy networks with NSX from OpenStack.

And Of Course There Are More

Those are the main labs I would recommend, but there are others too. There’s a lab where you can learn more about the IT Outcome of Fast Infrastructure Delivery and Application Automation (HOL-SDC-1413) which has some NSX goodness with vCloud Automation Center, or learn about the IT Outcome of Policy-based Compliance and Network Security (HOL-SDC-1414).

If you want to learn about NSX and the partner integration framework you can take HOL-PRT-1462 which will walk you through the NSX and Palo Alto Networks next-gen firewall integration labs and HOL-PRT-1464 which is focused on how you can use NSX Service Composer and Symantec Data Center Security: Server.

In all we have well over 24 hours of labs, and you can sign-up even if you did not go to VMworld. It is always available 24/7, so if you have a few spare hours and want to learn about NSX you can take the lab.

And I will let you in on a little secret. We actually run the labs on NSX. So as you learn, you are also a user of NSX!!!

You can always sign-up for a NSX class offered by VMware Education.

Happy learning!

Nikhil

VMware NSX Customer Story: Colt Decreases Data Center Networking Complexity

Adoption of network virtualization and SDN technologies from VMware and Arista Networks simplifies cloud infrastructure and enables automation to reduce timescales of cloud and network service provisioning

colt_logo_l_cmyk

Offering the largest enterprise-class cloud footprint in Europe, Colt, an established leader in delivering integrated network, data center, voice and IT services, has implemented software-  defined networking [SDN] and network virtualization to simplify how its managed IT and cloud-based networking environment is deployed, managed and scaled throughout its data centers.

Following an extensive review, Colt selected Arista to provide high speed 10 and 40 gigabit Ethernet cloud-centric switches as an underlay network fabric and VMware NSX™ network virtualization to deliver a fully decoupled software network overlay.

SDN paves the way for automated cloud service delivery

The shift to SDN will provide a flexible, scalable, efficient and cost effective way to support the delivery of Colt’s managed IT services, including cloud based services. This makes Colt one of the first service providers in Europe to adopt SDN in a production environment to remove  automate cloud service delivery.

As a result of deploying a new network architecture based on Arista and VMware networking technologies, the time for Colt to add, change or modify services will now take minutes  rather than days, and will enable Colt to onboard customers faster and expand its service portfolio quicker.

The big transformation in IT in recent years has been the development of cloud services with IT capacity purchased on-demand. In contrast, networking has remained relatively static.  The adoption of server virtualization over the past decade as the foundation for cloud computing and IT-as-a-service have resulted in a completely new operational model for provisioning and managing application workloads. However, the operating model of the network to which dynamic virtualized services are connected has not evolved to help businesses achieve the full benefits of mobile-cloud.

Mirko Voltolini, VP Technology and Architecture at Colt says, “The excitement around SDN and network virtualization is that – for the first time – networking is becoming more software orientated so we’re able to dynamically orchestrate service modification and activation in real-time.  In other words, network connectivity can now keep up when virtual machines and associated compute and storage change or are moved within distributed data centers.  Ultimately this means that servers, storage and now the network are in synch so that we can meet the specific needs of our customers in a timescale they demand.”

With more than 25,000 customers worldwide, Colt offers an information delivery platform comprising network, voice, data center and IT services sold directly to its enterprise customers or indirectly via channel partners and operators. In Europe, it has invested significantly to create a pan European network spanning 22 countries, 195 connected cities, around 19,800 buildings, as well as operating 42 metropolitan area networks.

Turning to the specialist technology firms has really delivered

Colt first considered adopting network overlay technology three years ago. It went out to tender approaching only large, mainstream technology suppliers and was disappointed by the response received.  The cost was too great and solutions not really mature enough to warrant changing. Eighteen months ago, it revisited the process given the technology had evolved, expanding the shortlist of suppliers asked to provide proposals to include specialist firms like Arista and VMware.

VMware NSX enables Colt to decouple the data center network from the underlying physical hardware to gain massive scale while simplifying network design and operations. With NSX, Colt is able to consolidate operations for four disparate physical networks running in the data center and manage these networks as a single logical network. Colt has developed a new data center architecture that leverages the scalability of a Layer 3 data center fabric and NSX’s overlay network virtualization platform.

Chris King, vice president, product marketing, networking and security business unit at VMware, said,  “Colt is an all too common story of an organization that simply hit the limits of what the physical network could provide in a virtualized world. VLAN limitations prevented Colt’s ability to scale. They needed to simplify the physical infrastructure in order to gain flexibility which in turn would allow them to adapt quickly to the business environment. VMware NSX helped Colt successfully execute a data center re-architecture which can now operate at cloud scale with better performance, easier management and lower overall costs.”

In addition to wanting to capitalize on the all the benefits offered by network overlays, the requirement for a new switch supplier was driven by Colt’s need to replace its existing legacy switches which had reached end of life and are not supported anymore.  Furthermore, the business wanted to reduce the total cost of ownership [TCO] of its networking equipment.

Voltolini explains, “Our target was to reduce the unit cost of our switches which includes the cost per port, along with maintenance, power, space and so on.  We wanted a step change in TCO which we will now achieve working with Arista.”

VXLAN addresses the limitations of Spanning Tree

From a technical perspective, Colt also wanted to move away from legacy protocols like Spanning Tree protocol which requires ports to be available – but not used – to deliver service availability. This underutilizes switch assets and adds unnecessary cost to its operation. Moreover, Colt required new switches which could scale to support increased connectivity capabilities both in terms of the number of ports [so that more customers can be connected] as well as logical scale.

Voltolini says, “The new VXLAN protocol removes traditional Ethernet limitations which is crucial for a service provider so that we can handle multiple tenants per port across numerous physical locations.”

Ultimately Arista switches will be installed in all Colt data center locations, the roll out of which will be driven by service and capacity demands.  The expectation is that this will happen over the next 18 to 24 months.  Deployment is made straightforward as all Arista switches – irrespective of port count or speed – feature the same network operating system, the Arista EOS.

Mark Foss, VP Global Operations and Marketing, concludes, “It is important to stress that this project is one of collaboration.  Being an innovative nimble company, we’re accommodating Colt’s requirements and helping shape their service design, while they’re guiding us in terms of our future product roadmap so we develop features pertinent to all cloud service providers.”

A Customer Perspective: VMware NSX, Micro-Segmentation & Next-Generation Security

VMware NSX and Palo Alto Networks are transforming the data center by combining the Columbia-S12_WTR_MGHI_564fast provisioning of network and security services with next-generation security protection for East-West traffic. At VMworld, John Spiegel, Global IS Communications Manager for Columbia Sportswear will take the stage to discuss their architecture, their micro-segmentation use case and their experience. This is session SEC1977 taking place on Tuesday, Aug 26, 2:30-3:30 p.m.

Micro-segmentation is quickly emerging as one of the primary drivers for the adoption of NSX. Below, John shares Columbia’s security journey ahead of VMworld

+++++++++++++++++++++++++++++++++++++++

When I started at Columbia, we were about a $500 million company. Now we’re closing in on $2 billion and hoping to get to $3 billion rather quickly. So as you can imagine, our IT infrastructure has to scale with the business. In 2009, we embarked on a huge project to add a redundant data center for disaster recovery. As part of the project, we partnered with VMware and quickly created a nearly 100% virtualized datacenter.  It was a huge success. But something was missing; a security solution that matched our virtualized data center. There just wasn’t a great way to insert security in order to address east-west traffic between VMs, nor have the security tied to the applications as they moved around dynamically.

 We set out looking for a solution to bridge that gap.

To address our security needs in the data center, we looked at several different strategies and at that time, there really weren’t any good solutions. Many of the solutions were physical in nature. They required us to do some crazy configurations to apply security. We looked at the Cisco 6500 firewall blades, Juniper’s virtual solution and a few other lightweight security offerings, but they just didn’t have what we needed. The solutions at the time didn’t have what we needed. We kept looking.

At VMworld last year, we were introduced to VMware NSX. I saw the power of the platform, and it all started to click. And when Palo Alto Networks (our perimeter firewall vendor) announced they were a major partner, and that their technology integrated with NSX to give us an additional level of security, things really came together for us. The ability to drive security down into the infrastructure, down to the kernel level, and then take advantage of Palo Alto Networks next generation security was very attractive. Doing micro-segmentation with NSX, and then having the option of inserting next generation firewalling services from Palo Alto Networks in those areas of the business that require them, will really help us improve our overall security posture. A solution like this is where we need to be. These tools give us the ability to manage both physical and virtual security policies centrally with Palo Alto Networks management tool Panorama. I know that when workloads move the security and policies follow the workloads.

To me, that’s what it is about – advanced security inside the data center, plus automation via software that’s completely independent of the underlying physical infrastructure. With solutions such as NSX and the integration with Palo Alto Networks to provide advanced security services, we are going put security back in the data center, the right way.=

Jspiegel

John Spiegel
Columbia Sportswear

 

VMware NSX Use Case – Simplifying Disaster Recovery (Part 1)

Nicolas Vermandé (VCDX#055) is practice lead for Private Cloud & Infrastructure  at Kelway, a VMware partner. Nicolas covers the Software-Defined Data Center on his blog www.my-sddc.om,

This series of posts describes a specific use case for VMware NSX in the context of Disaster Recovery. The goal is to demonstrate the routing and programmability capabilities through a lab scenario. This first part presents the NSX components and details the use case. The second part will show how to deploy the lab and the third part will deal with APIs and show how to use python to execute REST API calls to recreate the required NSX components at the recovery site.

Introduction

When considering dual datacenter strategy with VMs recovery in mind, one important decision is whether to adopt an active/active or active/standby model. The former is generally much more complex to manage because it requires double the work in terms of procedures, testing and change controls. In addition, capacity management becomes challenging as you need to accommodate physical resources to be able to to run all workloads within whatever site. On top of that, stretched VLANs are sometimes deployed across datacenters so that recovered VMs can keep their IP addresses. This is generally very costly if you want to leverage proper L2 extension technology, such as Cisco OTV.

Alternatively, in a SDDC environment, you can leverage VMware NSX to efficiently manage connectivity and network changes required in the event of a full site failover. NSX gives you the ability to maintain the same IP address scheme for all you workloads by leveraging APIs, with little effort. Or with more granularity, you could even move a single subnet as part of a specific recovery plan. NSX will make this possible by providing:

  • An overlay network that allows you to decouple the backend VM network from the physical network. NSX-V is using VXLAN, each ESXi host acting as a VTEP.
  • Programmability through RESTful APIs that allows you to provision Logical Switches and modify Logical Routers configuration in seconds.
  • Dynamic routing protocol (OSPF, IS-IS, BGP) that will advertise VM subnets to your enterprise network, making them accessible for end users or other applications (North-South or East-West traffic)

NSX Components

As many NSX introduction blog posts can be found on the web (like here or here), I’m not gonna spend much time on this topic. NSX components are:

  • NSX Manager: it’s the single point of configuration and the REST API (and UI) interface. It is provided as a VM appliance and is actually the only appliance you have to manually install. There is a 1:1 mapping between the vCenter Server an the NSX Manager. The manager is responsible for deploying NSX Controllers, NSX Edge Gateways and Logical Router Controllers. It also installs the Distributed Routing and the firewall kernel modules on ESXi hosts, as well as the User World Agent (UWA). NSX configuration is accessible through vCenter once you’ve installed the NSX plugin.
  •  NSX Controller: it provides a control plane to distribute VXLAN Logical Routing and Switching network information to ESXi hosts. It also enables ARP suppression to reduce flooding. It is typically implemented as a 3-node cluster and maintains MAC, ARP and VTEP tables. It is finally responsible for installing routes into each ESXi host.
  • Logical Switch (LS): it acts as the L2 domain boundary for VMs, identified by a VXLAN ID (VNI) and associated with a specific subnet. Its vCenter representation is a distributed Portgroup with specific capabilities.
  • Distributed Logical Router (DLR): it’s the distributed L3 first-hop for VM traffic. As its name suggests, it’s completely distributed. You can think about it as an anycast gateway, where each ESXi corresponds to a node, sharing a single virtual IP and virtual MAC address. The data-path routing process runs within each ESXi in vmkernel space and enables East-West traffic optimisation, avoiding well-known hair-pinning effects when VMs want to talk to their default gateway.
  • Logical Router Control VM: it provides the DLR with a control plane and can be deployed as a redundant pair of VM appliances, in an active/standby fashion. It supports both OSPF and BGP as dynamic routing protocols. The Control VM receives its initial configuration from the NSX Manager.
  • Edge Services Gateway (ESG): it provides network perimeter services to the virtual environment. It is intended for North-South communication, i.e. between the physical and the virtual network or at the edge of your tenant. It is NOT distributed, meaning that its placement is critical. It can run in HA-mode, where the appliances are deployed in an active/standby fashion. The HA mechanism doesn’t rely on VMware HA (as some people at Cisco seem to think), but with minimum common sense, you’re gonna create a DRS anti-affinity rule to separate active and stanby VMs. Depending on specific requirements, the edge gateway can be deployed with several sizes:
    • Compact (1vCPU – 512MB RAM)
    • Large (2 vCPUs – 1GB RAM)
    • Quad-Large (4 vCPUs – 1GB RAM)
    • X-Large (6 vCPUs – 8GB RAM).

Available services include: Firewall, NAT, DHCP, Routing, Load-Balancing, Site-to-Site VPN, SSL VPN and L2VPN.

  • Distributed Firewall (DFW): It enables distributed security capabilities at VM NIC level as an East-West L2-L4 stateful firewall. The module is present on each ESXi host as a kernel module and therefore removes any form of bottleneck. If you need more bandwidth, just add a new host! It also includes the Service Composer feature, which allows you to create specific services by integrating additional 3rd party capabilities to the firewall, such as endpoint services (e.g. Anitivirus, Data Security) and deep packet inspection (Palo Alto). I have to say that this feature is one of the most compelling to me!

The following picture shows how those components fit together:

togetherNSX

Basic Understanding

To understand NSX concepts, it’s useful to map vSphere network components to NSX components:

In a traditional vSphere environment, a VM wishing to communicate with the outside world first hits a virtual port on the virtual switch. This virtual port is part of a Portgroup, which is basically a group of virtual network ports tagged with a specific VLAN ID. In the NSX world, when a VM is part of a Logical Switch, it hits a virtual port member of a Portgroup specifically created by the NSX Manager. It is created on every host member of the VDS, like a traditional distributed Portgroup. However, the difference is that all egress frames hitting this Portgroup will be forwarded inside a VXLAN tunnel, tagged with a specific external VLAN ID to transport the VXLAN frames on the physical network .

The role of the Logical Router is to connect two or more Logical Switches together, enabling routing between the corresponding subnets (you can assume 1 LS = 1 subnet). It also advertises (and learns) prefixes and routes to its neighbor(s) if a dynamic routing protocol has been activated. Alternatively, you can also configure static routes.

As an example, the following diagram shows the DLR establishing adjacency with the ESG, which is also running a dynamic routing protocol, and advertises VM subnets to the physical world. The ESG has its internal interface connected to a VXLAN and its uplink connected to a VLAN. As a result, the physical network can learn about the virtual network, and vice-versa.

example

Lab Architecture

Now that you’ve had a basic introduction to NSX principles, I can detail my scenario. In my lab environment, I’ve simulated the following architecture:

globalNSX

I didn’t actually deploy two sets of controllers and two managers linked to two different Virtual Centers in separate physical datacenters. Instead I’ve created logical containers called “Transport Zones” to make both virtual datacenters completely independent from a data-plane standpoint. The goal here is to demonstrate how to integrate virtual network operations into an orchestrated Disaster Recovery Plan with NSX. The only requirement is the ability to run a script as part of your DR procedures. This may be ultimately be achieved by VMware Site Recovery Manager, or another orchestration tool.

This architecture represents a traditional dual datacenter environment, connected over a L3 IP cloud. In a standard network environment, it basically means that you have to change VMs IP addresses upon recovery. (There are other alternatives, like host routes, RHI and NAT, but these solutions come at a certain complexity cost).

The main goal of the scenario is to show how to provide a flexible orchestrated Disaster Recovery solution without having to change VMs IP addresses. Let’s see how we can achieve this with NSX. The order of operations would be:

  1. Disconnect LS1 and LS2 in DC1.
  2. Create new LS in DC2: DR_LS1 and DR_LS2 (Or pre-create them without connecting the upstream DLR).
  3. Add two new interfaces to DLR2 in DC2, with the same IP addresses as previously used by DLR1 to connect LS1 and LS2. In this way, we don’t have to change the default gateway of the recovered VMs.
  4. Connect those interfaces to the corresponding LS.
  5. Recover VMs in DC2.
  6. Connect VMs to the appropriate LS.
  7. Boot VMs and test connectivity.
  8. Check route updates on the physical network.

Note: I’m assuming here that security devices configuration are synchronized between datacenters.

NSX

Because OSPF is running within the virtual network on both DLR1 and DLR2, routing updates will be sent up to the IP cloud to reflect that DR_LS1 and DR_LS2 subnets are now reachable through DC2. In the same way, because LS1 and LS2 have been disconnected from DLR1, corresponding routes will be removed to reflect that LS1 and LS2 subnets are not reachable in DC1 anymore. Magic??!! No, just awesome technology :-)

The next post will focus on how to deploy this lab environment.

Nicolas

 

Geneve, VXLAN, and Network Virtualization Encapsulations

In this post, Bruce Davie and T. Sridhar of VMware’s Networking and Security Business Unit take a look at a proposed a new encapsulation protocol that would standardize how traffic is tunneled over the physical infrastructure by network overlay software.

++++

For as long as we’ve been doing Network Virtualization, there has been debate about how best to encapsulate the data. As we pointed out in an earlier post, it’s entirely reasonable for multiple encapsulations (e.g. VXLAN and STT) to co-exist in a single network. With the recent publication of “Geneve”, a new proposed encapsulation co-authored by VMware, Microsoft, Red Hat and Intel, we thought it would be helpful to clarify a few points regarding encapsulation for network virtualization. First, with all the investment made by us and our partners in developing support for VXLAN (described here), we very much intend to continue supporting VXLAN — indeed, we’ll be enhancing our VXLAN capabilities. Second, we want to explain why we believe Geneve is a necessary and useful addition to the network virtualization landscape.

Read the rest of Bruce’s blog on the Office of the CTO blog here.

Micro-Segmentation: VMware NSX’s Killer Use Case

The advantages a software-defined data center, using network virtualization as a core underpinning, include service delivery speed, operational efficiency, reduced hardware dependency and lower cost. However, by far the most popular use case by customers thus far has been the use of NSX for network microsegmentation. Why? Because perimeter-centric network security has proven insufficient, and micro-segmentation has to date been operationally and economically infeasible. With NSX, security teams, in partnership with their network and virtualization teams, are benefiting from network micro-segmentation to begin to transform their data center security architecture. Then read the VMware SDDC Micro-Segmentation White Paper.

Rod

The Goldilocks Zone: Security In The Software-Defined Data Center Era

Last week, we spoke at the RSA Conference about a new concept in security – the Goldilocks zone.  With the help of Art Coviello, Executive Chairman of RSA, Chris Young, senior vice president and GM of Cisco’s Security business unit, and Lee Klarich, senior vice president of product management from Palo Alto Networks, we departed from the typical discussions about new controls or the latest threats.  We took the opportunity to lay out what we believe is a fundamental architectural issue holding back substantial progress in cyber security, and how virtualization may just provide the answer. The growing use of virtualization and the move towards software-defined data centers enable huge benefits in speed, scalability and agility; those benefits are undeniable. It may turn out, however, that one of virtualization’s biggest benefits is security. Continue reading

Network Security: The VMware NSX Network Virtualization Platform’s Hidden Gem

This week, we announced a new joint solution with our partner Palo Alto Networks that will

Best-In-Class Partners

automate and accelerate the deployment of next-generation network security with centralized management across physical and virtual domains. You can read the full announcement about the forthcoming integrated solution from our companies in our press release here.

For most data center operators, the idea of achieving the operational model of a VM for their data center networks is a top of mind benefit associated with the VMware NSX network virtualization platform. Through this model they can gain greater agility, efficiency and provisioning speed while reducing complexity as they implement a software-defined data center architecture. An often-overlooked feature set, fundamental to VMware NSX, is network security. Continue reading

VMware @ OpenStack Summit Hong Kong

Next week in Hong Kong, the VMware team will have a major presence at the OpenStack Summit, and we have an ever-growing presence on the agenda of speaking sessions and demos. As we did with the Portland show, he is a show planner with a schedule of all the VMware sessions. Here’s a snapshot of what you can expect (and experience) at the show. Continue reading

Network Virtualization: The Holy Grail of Workload Agility

This is a guest post from vCloud Service Provider Logicworks which originally appeared on the VMware vCloud Blog. You can read more from Logicworks on their blog, Gathering Clouds.

Everyone is familiar with virtualization. It’s become the IT standard for achieving greater levels of resource efficiency and functionality. While it’s just a tool, the vast majority of new builds utilize it in some way.

This holds true for managed service providers (MSPs) as well. The benefits of virtualization to an MSP are similar to what an enterprise would experience. Given the nature of their business, MSPs put a great emphasis on truly being agile to client requirements, both in terms of build times and modifications of client environments.

Virtualization is absolutely key to that, and has been since the inception of VMware. The ability to resize a component of a client’s infrastructure on-demand and on the fly is an absolute must nowadays.

However, when we talk about virtualization, we mean virtualization of the compute layer, which is what everyone speaks about relative to virtual machines (VMs). And while VMs are an amazing innovation, the really interesting stuff is happening at the storage and network virtualization layers.

Logicworks is very keen on network virtualization, as opposed to the traditional configuration of hardware switches, which is a major reason we joined the NSX Beta Program.

Historically, the challenge with network virtualization’s centered on the limitations of spanning the network virtualization layer from a client’s existing virtual environment to other environments, including other data centers.

One of the major benefits we’re looking to achieve with the NSX beta program is that the technology after the acquisition of Nicira makes it possible to span virtualization between data centers which helps realize the dream of true, still completely active mobile workloads.

One of the challenges that this resolves is lead times in deployments. As it is today, providers still need to log into various switches between different vendors to configure and test them. While this is somewhat automatable, it hasn’t achieved that same degree of automation, which compute virtualization enjoys. Network virtualization gives us the ability, using software and scripts and predetermined runbooks, to deploy clients via API calls to a control cluster instead of logging into physical devices.

In addition, providers also use various vendors’ networks offerings. This means that the set of commands one will have to run on a Juniper device is going to different than on an Extreme device, and complex configurations can be quite a bit different between the two.

If we abstract that away by making the basic configuration of either of those hardware devices as simple as possible, enough to enable network virtualization on top of it, then we can standardize our configurations across our clients. This process becomes more repeatable and much quicker to deploy –like the DevOps model applied to network virtualization, to a degree. If the work being done is as close to possible from one client to another, then we can remove potential errors and increase efficiencies through more automation.

Being on the cutting edge of not-yet-industry-standard technology enables Logicworks to deploy cross-production workloads, and serve as an agile service provider. This dovetails nicely with the next generation of network virtualization in that it mirrors our ability to respond quickly and dynamically to make adjustments in deployments.  For the first time, the capabilities of the technology match exactly what it is that we, as a hosting provider, do every day.