Tips for migrating applications to Software Defined Networks
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.
In order to do this, you need to go over every filtering rule in your network security equipment, discovering all the places where the servers’ old addresses appear. Then you need to duplicate those rules, modifying them to include the new server addresses.
As a side note, migrating to SDN is a great opportunity to reduce clutter and improve your policy efficiency. So, you should only convert actively used rules to the new network – in fact, a good migration solution will automatically flag redundant firewall rules for you.
Once your new filtering policies are written, you need to deploy them to the relevant devices. This involves configuring firewalls, routers and load balancers to allow traffic to and from the new servers.
* Testing to production. At this point you’ll have a functional system which you should test rigorously, to ensure that all the required functionality is in place and everything operates as it is meant to. You can only move on from this stage once you are confident that the application in its test environment is equivalent to the ultimate production environment.
Moving from test to production, at its most fundamental level is about renaming things. It may be that there is a public name for the server, or a website that users need to access your application. You now need to reconfigure the official published access points to direct to the new server instead of the old.
This stage could involve creating another version of the software configuration already outlined, or it could involve changing default actions within your network. Again, it’s important at this stage to check whether you need to make changes to your filtering policy too.
* Decommissioning legacy versions. The final part of the migration process is decommissioning the legacy versions of application connectivity - but don’t do it before you’re absolutely ready. Make sure your new system has had time to mature, to be stable and fully tested for an adequate time period.
Then, getting rid of the old system doesn’t just involve shutting down old servers. To avoid creating security gaps and breach points for hackers, best practice requires decommissioning all the filtering rules from your old firewalls, routers and load balancers. However it’s important to check that these rules aren’t still used by other functioning applications in your data center, before decommissioning them!
* Managing the network. Once deployed in production, you should now prepare for ongoing security policy management of your SDN environment. This means structured change management processes, auditing, and compliance reporting, risk management etc. The best way to manage this is with a holistic, automated change-request system that supports both the software-defined network firewalls and security controls, as well as the traditional firewall estate – since the likelihood is that your enterprise environment will still comprise both and therefore unified management is critical to ensure your security posture.
Overall, a SDN migration project will require a strong, repeatable process to ensure success. Don’t believe any vendor that promises a ‘silver bullet’ that automatically converts everything for you at a click of a button. However, with proper planning, testing and management, organizations can quickly and smoothly migrate their applications, and reap the performance scalability benefits of software-defined networking.