Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Tips for migrating applications to Software Defined Networks

Avishai Wool, CTO, AlgoSec | Feb. 22, 2016
The five steps involved in an SDN migration and what you need to consider.

Although vendor-written, this contributed piece does not advocate a position that is particular to the author’s employer and has been edited and approved by Executive Networks Media editors.

Software Defined Networking (SDN) is one of the hottest trends in security and networking right now. Many enterprises are considering moving to virtualized networks such as VMware NSX as part of an overall shift from relatively inflexible hardware-based architectures to nimbler, faster, more scalable virtualized deployments.

But as with any migration project, careful planning and management is required. Here we look at the steps involved in an SDN migration and what you need to consider at each stage.

* Pre-migration project planning and connectivity flow mapping. The most critical aspect of the migration project is actually the pre-planning stage where you need to discover and map the connectivity flows of your business applications. Disciplined organizations that maintain accurate, up-to-date, machine-readable records of traffic flows that support each business application can quickly start the migration process by importing their documentation. However, more often than not, the application discovery stage will combine multiple 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.

It’s also vital to assess the overall business goals of your migration project, such as cost reduction, centralized management, faster application deployment, and scalability etc., and ensure they are incorporated into the project from the planning stage, since these will determine the technical process ahead. One you have full visibility of your network and have properly mapped the connectivity flows you are ready to begin the migration process.

* The migration. Once you have identified the connectivity flows you want to migrate, you can identify the servers you need to move. For every server to be moved you need to define a matching server in the new environment.

The most efficient way of managing this process is by creating a mapping table, with a new IP address identified for each new server. You also need to identify a workload for each server – the required storage, CPU, operating system and database. You will now have one (or more) blank new servers set up with new IP addresses. The next step is to install your existing applications onto that server or server group.

However, installation doesn’t end with the application. You also need to reconfigure the connectivity flows for every server that has been moved as well as any servers and applications that might be connected to these migrated servers. This requires writing new policies, based on the previously discovered traffic patterns that work with the new server IP addresses. If you don’t do this, and you keep your old filtering policies in place, communication to your new servers will be blocked. You need to allow traffic to and from its new addresses.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.