A Blueprint for Migrating Applications to VMware NSX

VMware’s NSX technology offers new and exciting capabilities for virtual datacenter owners: the ability to secure East-West traffic within the data center using filtering policies that are enforced by the VMware infrastructure. However, migrating from existing traditional filtering technologies to VMware NSX may seem like a daunting task. In this blog post I will present a blueprint for migrating applications and their underlying filtering policies to the VMware NSX platform, based on actual use cases implemented at several large financial institutions.

Know Your Objective

As your organization begins to consider migrating to the VMware NSX platform, the first question you need to ask itself is why – i.e., what is the objective? The objective is important because the technical migration process heavily depends on the project’s goals. I suggest that there are two different business drivers for migrating to VMware NSX that require somewhat different processes and tools:

• You may want to make your network security tighter by creating internal zoning within your virtualized data center and filter East-West traffic that is currently unfiltered.
• Alternatively, you may want to eliminate some of the traditional firewalls protecting the data center for cost reduction and/or improved performance. In other words, your goal is to replace the existing East-West traffic filtering with VMware NSX equivalents in the virtualized infrastructure.

The success of both these scenarios hinges on being able to produce accurate, up-to-date mapping of the traffic flows used by each business application, before you migrate.

In the first case (a) the process of identifying East-West traffic and associating it with the right business applications is usually a major challenge, in part because it’s unlikely you have accurate records for each application’s datacenter-internal connectivity requirements, and because of the complexity involved in designing a new zoning structure within the VMware estate.

In the second case (b) filtering policies already exist in the traditional firewalls, and moreover the network zoning structure is already defined based on the division into VLANs and the placement of the traditional firewalls. Therefore it is much easier to define a VMware NSX zoning structure to match the traditional zoning structure it’s replacing.

Discover Application Connectivity Flows

With both cases, discovering business application connectivity flows is the critical first stage in any successful migration project. Disciplined organizations that maintain accurate, up-to-date, machine-readable records of the traffic flows that support each business application can quickly start the migration process by importing their documentation.  Organizations following scenario (b) are already filtering some East-West traffic using traditional firewalls inside the datacenter, and can therefore often discover an application’s connectivity requirements from those firewalls’ rules. But for less disciplined organizations, that lack visibility into East-West traffic, an intelligent traffic-sniffing discovery process is needed.

More often than not, the application discovery stage will combine all available data sources: importing data from CMDB or home-grown repositories, machine-assisted discovery from traditional firewall policies, and intelligent traffic-based application connectivity flow discovery.

The Application Migration Process

Once you have successfully discovered all the traffic flows for the applications you wish to migrate – including datacenter-internal East-West flows and North-South flows that cross the datacenter boundary – you are ready to migrate your applications to the VMware NSX estate. The steps involved in migrating a discovered application should include:

1. Allocating IP addresses and assigning the server workloads onto the new addresses (optional)
2. Reconfiguring the application software to use the new IP addresses (optional)
3. Writing VMware NSX policies to allow the application’s discovered traffic
4. Deploying and validating the VMware NSX policy via policy simulation
5. Testing the application’s functionality
6. Moving the application to production
7. Decommissioning the legacy application

Prepare for a Steady State

Once you have successfully migrated your applications to the VMware NSX estate you need to prepare for ongoing security policy management. This means that various teams will need visibility into the VMware NSX policies:

• The information security team will need to have access to VMware NSX change tracking, and to audit, risk and compliance reporting.
• The network architecture team will need to include the VMware NSX estate in their policy simulation activities.
• The security operations staff will need to modify the VMware NSX policies to support changes to the business applications.

To do this you need a holistic machine-assisted change-request process that supports both the VMware and traditional firewall estate.

A Few Final Tips and Cautions

First, it’s important to realize – and to convey to peers and management – that a VMware NSX migration project will require a repetitive process. Don’t believe any vendor that promises a “magic elixir” that automatically converts everything for you all at once. While automation solutions are crucial for the success of the project, there is no way around the fact that you will still need to discover, model, migrate, and test business applications in “digestable” batches.

Second, migrating to VMware NSX is an opportunity to reduce clutter and improve policy efficiency: if your application discovery is based on firewall rules, you should only convert the actively used rules to VMware NSX. A good migration solution will automatically flag redundant firewall rules for you.

Third, test performance in advance. Traffic filtering consumes CPU resources – sometimes a lot of resources. Traditional firewall vendors have the advantage of running their traffic filtering engine on dedicated hardware – often with custom hardware accelerators and smart network processors. Software-based VMware NSX does not have this privilege, so all CPU cycles used by VMware NSX filtering may reduce the total horsepower available for running VM workloads. It’s therefore a wise idea to test whether the VMware hardware infrastructure can support the extra processing required to filter the datacenter’s traffic bandwidth without impacting the performance of the workloads. To do this you can simply turn on your VMware NSX firewall with an “allow all” policy and test under a variety of workloads (normal and stress), to measure the impact of CPU utilization both at the hypervisor level and within each guest OS.

If you going to VMworld next week, feel free to stop by AlgoSec’s booth #443 where we can show you how we help companies discover, migrate and manage their business application connectivity on VMware NSX.