Planning Application Migration to VMware Cloud on AWS with vRealize Network Insight Cloud

When the decision is made to migrate applications to a cloud like VMware Cloud on AWS (VMC on AWS), a few things need to happen. First and foremost, insight into your applications and application behavior is critical. Questions that you need to ask itself are:

1. “Which components make up an application?”
2. “To what resources does it need access to function?”
3. “How much data is being shipped from and to that application?”
4. “What is the network throughput profile (packets per second, routed or switched traffic, throughput) of the application?”

There are four steps in the application migration process:

1. Assess the current application landscape and get insight into the application blueprints,
2. Use this insight to determine suitable applications for migration, and create “migration waves”, which are groups of applications that are migrated together. Also, calculating the bandwidth requirements and related cloud costs cannot be skipped,
3. Migrate the selected applications,
4. Validate application behavior, post-migration.

vRealize Network Insight Cloud can help with step 1, 2, and 4. VMware HCX can help with step 3. This blog post focuses heavily on step 2, which is critical in the planning phase. Future and past blog posts cover the other steps.

Note that vRealize Network Insight is available both as a VMware Cloud service and as an on-premises perpetual product. You can sign up for a 30-day free trial of vRealize Network Insight Cloud, or check out the on-premises vRealize Network Insight product.

Application Discovery & Assessment

It’s not uncommon to have an incomplete CMDB or to have multiple sources where applications and the workloads that it consists of are documented. vRealize Network Insight can use a combination of sources (tags, naming conventions, CMDB input) to discover the applications from the infrastructure metadata. For more details on application discovery, check out this blog post.

After getting the applications into the database, there is a beautiful view of application dependencies and network requirements:

Application Dependency Mapping	Application Details (Services, Recommended Firewall Rules)

I’ve focused on the CRM-Records application here, which consists of a MySQL database server. You can see the other applications that are talking to this application, and if you zoom in on the application itself, the network requirements for this application present themselves. In this case, this app is using up 727.5MB of total traffic, with a peak throughput of 79.9kbps. This same view can be used to implement security policies when migrating the application, as the Recommended Firewall Rules tab shows the exact firewall rules that need to be implemented for this application.

Internet Traffic

One of the perks of migration to a public cloud is that you can choose the optimal location to make sure your end-users benefit. But, without networking insights, this is often overlooked. For internet-facing applications, vRealize Network Insight can help with determining where the network traffic is coming from, so you can choose the most optimal cloud location.

The above search query gives the amount of traffic for the CRM-Records application, grouped by country. As you can see, most of the traffic is coming from Northern Europe. To ensure users have the best experience, this application should be migrated to London.

Note that the same information can be used to calculate egress traffic costs from the cloud.

Creating Migration Waves

After gaining visibility into the existing applications and their behavior, it’s time to define the migration waves and put together the applications that should be migrated together. From the application list, that is curated inside vRealize Network Insight; assign priorities. There are always some applications more important than others (e.g. production vs. test).

Now, while I’m focusing on a per-application process (as most organizations tend to focus on applications), this same exercise can be done on a per-network (VLAN) basis; just change the grouping. Fun fact: it is possible to get a list of applications that are on an L2 network by executing the following search query:

Application where IP Endpoint.Network Interface.L2 Network = 'VLAN-10'

After assigning priorities, grouping of the applications can start – making migration wave groups. While doing this, there are questions that need to be asked:

1. What are the network requirements in order to move this migration wave?
   1. How much traffic will the migration wave create between the cloud and on-prem network?
   2. Have you sized the connection to the cloud to support this traffic?
2. Will there be any limits triggered on the destination cloud?
   1. Is there a limit for the number of VMs in a network?
   2. Is there a limit of the amount of throughput or packets per second?
3. Is a temporary layer-2 bridge necessary?
   1. If you are migrating on a per-application basis, it might be required to create a layer-2 bridge to allow the IP subnet to exist in both the on-prem infra as the cloud infra. VMware HCX can create these layer-2 extensions, but there will be a limit to how much throughput and the number of layer-2 extensions it can handle.
   2. Should proximity routing be enabled while the layer-2 extension is online?

While number 1 is the most important to check, as it directly impacts application performance after migration, the rest can prevent the migration from finishing (as you would discover those limitations during the migration).

To start answering these questions, create another application within vRealize Network Insight that’s called “Migration Wave X” and place the applications that are in each migration wave in it. Essentially, you are creating nested applications. After creating these applications, it is possible to scope the security planner on each migration wave and see its dependencies.

As an example, the below screenshot lists the security planner for Migration Wave 1, which I built from the previously used CRM-Records. This migration wave 1 includes the CRM-Records app, and all of its dependencies (Test-CRM, Webshop, SAP, and tanzu tees).

Zooming in (clicking) on each of these connections is possible, to make sure the previously asked questions, are answered. Using this view, question 1 can be answered fully.

Limitation Check

Question 2 is more around inventory and maximum usage. To understand the compute inventory requirements, use this search query:

sum(CPU Cores), sum(Memory Consumed) of VMs where application = 'Migration Wave 1'

To proper plan the destination infrastructure, we need to know the bandwidth throughput and packet per second usage of the VMs inside the migration wave. Because vRealize Network Insight correlates all possible information together, we can link these metrics back to the migration wave group.

Uncovering the required information can be done by using the search engine. Below are the search queries that can be used.

series(sum(byte rate),300) of flow where source application = 'Migration Wave 1' and flow type = 'Destination is Internet'

Graph of throughput per second from Migration Wave 1 to the internet

Also, get the maximum peak throughput by adding the max() operator:

max(series(sum(byte rate),300)) of flow where source application = 'Migration Wave 1' and flow type = 'Destination is Internet'

This will show you the peak throughput, which you can use for sizing the internet gateway.

Get these graphs and maximum values for a few different traffic types; internet, east-west, and within the migration wave. Splitting up the different types of traffic is easy; the flow type can be changed to view a bunch of different traffic types. From the Internet, to East-West, to Routed, to Switched, and a lot more. Have a look at the auto-completion and scroll through the options:

Sample of the flow type auto-complete

In some cases, there will be a limit of packets per second at the migration destination. To make sure there are no surprises, get the packets per second as well. All you have to do is to change the focus property in the search query, like this:

series(sum(flow.totalPackets.delta.summation.number),300) of flow where source application = 'Migration Wave 1' and flow type = 'Destination is Internet'

Graph of packets per second from Migration Wave 1 to the internet

Make sure the packet per second rate is also sized properly, and use the max operator to get the maximum number of packets per second:

max(series(sum(flow.totalPackets.delta.summation.number),300)) of flow where source application = 'Migration Wave 1' and flow type = 'Destination is Internet'

Rinse and repeat for routed and switched traffic by changing the flow types, to get data you need.

Using the output of these searches will allow you to determine the minimum requirements for the network at the destination cloud. vRealize Network Insight tells you precisely what is needed.

Migrating the Applications

Now that the planning is done, the migrations itself can begin. I cannot recommend VMware HCX enough for this task, and not only because it’s one of VMware’s products. It allows for cold and live migrations from and to different vSphere platforms, using already built-in tooling, like vSphere replication. HCX can extend layer-2 networks to stretch an IP subnet between on-premises and VMC on AWS.

Learn more about VMware HCX here.

Validating Application Behavior

Once an application is migrated, validate its behavior by going into the security planner and checking connectivity from before the application was migrated and after. This is done by using the time machine that is built-in:

There are more ways to validate an applications behavior. For example, the Application Dashboard will show a topology of the application, all metrics that relate to it, any and all events that might cause problems; a full picture.

More on day 2 operations with vRealize Network Insight, in a later post.

Learn more

To learn more about vRealize Network Insight and the application migration planning capabilities, check out our Hands-on Labs, and reach out to your VMware representative.

If you happen to be at AWS Re:Invent 2019 in Las Vegas, visit the VMware booth #2108 to learn more!