The vast majority of ACI customers do not start out with an Application Centric deployment of ACI; mainly because they do not have a clear understanding of their applications and the vast amount of interdependencies.
However, with the advent of Tetration and other 3rd party analytics tools, the knowledge about how your applications are connected is increasing and customers are looking to migrate some apps from the “Network-Centric approach (Vlan=EPG=BD) to a full ACI-Centric model.
Let me be clear; The Network-Centric model serves many customers well. It allows them to migrate their existing compute/applications/network into ACI in a way that is familiar and well understood.
Customers operating their fabrics in a Network-Centric model continue to gain numerous benefits from ACI, such as Single Pane of Glass management from the UI, elimination of box-by-box mgmt of the entire data center, the ability to upgrade the entire fabric (APICS+Switches) from one location with ease, decreased time to resolution during issues due to the availability of consolidated faults and health scores, etc.
However, for those customers who want to take their ACI deployment to the next level, moving applications into an ACI-Centric Model is one of the next logical steps.
Below, we will discuss a sample methodology for moving applications into an ACI-Centric Model.
Here are 8 assumptions before we begin:
1) This document assumes that the customer has the data needed to build out the application profiles for their ACI-Centric application.
2) This data can be obtained in several manners, such as:
3) Network Centric Mode is currently used (Network-centric means 1 vlan = 1 bd = 1 epg)
4) VMM Integration to the ACI Fabric must be completed before moving VMs from the Legacy network to the ACI Fabric. Pre-work includes, but not limited to, installation of additional connectivity from FIs to the ACI Fabric, configuration of ESXi vnics, and OOB connectivity.
5) L2 connectivity traffic between the ACI Fabric and Legacy network should be monitored before, during and after migration.
6) All L3GW functionality for applications will migrate from the Legacy network to the ACI Fabric prior to activation of ACI-Centric EPGs.
7) EPG to EPG communication is a permit any. << Highly recommended; Contracts for ACI Centric-mode should be configured last
8) DHCP Labels are created prior to migration
Here are 10 generic migration guidelines.
The following guidelines should be followed when migrating applications to the ACI Fabric.
1) Map existing Vlans into ACI in Network-Centric Mode (L2 only – no contracts)
Create legacy EPGs and BDs on the ACI Fabric. BDs will be initially created as L2. L3GW functionality will remain on the legacy network until after L3GW Migration.
2) L2 BD configurations – For each of your bridge domains, it is recommended that they are configured with the following:
3) Create static bindings for the Legacy EPGs on the L2 trunk between the ACI Fabric and Legacy network
4) Identify list of servers (both bare-metal and VMs) present in the legacy network that will be migrated to ACI.
5) Create L3out for Tenant and establish routing availability from ACI to legacy environment
6) Migrate L3GWs for legacy Vlans into ACI Fabric
Validate routing from inside the ACI Fabric and outside of the ACI Fabric.
7) Create New Application Profile and EPGs from application data analysis
8) Migrate Servers – Servers associated with the various application will move to the ACI Fabric and be associated with the specific EPG designated based on the output of the data analysis.
9) Deploy ACI-centric contracts (optional)
10) Perform Cleanup
Here’s a sample migration of the application “NewApp” to an ACI-Centric Model.
The diagrams below represent a “story-board” approach of how we would migrate an application into ACI.
In general, I would recommend the “crawl/walk/run” approach to ACI deployments. For the application below, there are different components spread across (3) different Vlans, vlan 5, 6, and 7. So the first step (crawl) is to migrate these Vlans in the ACI-fabric in a network-centric approach, meaning that we will implement an approach where Vlan=EPG=BD.
Once we have all of the L2 Vlans available on ACI (EPG/BDs are created, and an L2 trunk is configured between ACI and the Legacy environment), we can then migrate the L3GW services to ACI. This involves creating a L3out (External Routed Network) from ACI to the outside network, and then migrating each Vlan/Subnet to ACI, one at a time.
ACI-Centric component creation
Now that we have L3GW functionality, we are fully operating in a Network-Centric model for our Vlans. Next, assuming we have the data that shows us how to deploy our application in ACI-Centric mode, we will take that data and configure our new Application Profiles, EPGs, and Contracts (to be used later) into ACI.
Server Migration into new ACI-Centric EPGs
Now that we have EPGs built for our ACI-Centric Application, we can begin moving servers (both bare-metal and virtual) into the EPGs. This also serves as an opportunity to determine if we need to remove unneeded EPGs (i.e., EPGs with no endpoints) from the fabric.
Decommission of Legacy components
Once all endpoints have been removed from a legacy network-centric EPG, such as Vlan5_EPG, it can be deleted. Additionally, once all servers have been migrated off of the legacy infrastructure, the L2 trunk between ACI and the Legacy network can be decommissioned.
A couple of caveats…
And that wraps up today’s blog! But more to come on ACI right here on the ACI Board on Cisco Community.
In the meantime, please drop a comment and let us know if this migration piece was helpful. Feel free to even comment in ACI topics you’d like to see discussed here in the near future!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.