Cisco Blogs
Share

ACI, the SDN Purpose-Built for Data Center Operations and Automation


November 6, 2015 - 1 Comment

ACI, the SDN Purpose-Built for Data Center Operations and Automation

A couple of years ago we talked about our SDN vision and strategy, and a little over a year ago we started shipping the ACI solution. Since then over 1,000 customers have embraced ACI, and of those 150+ customers now have live production traffic running on ACI, with more coming on board at a steady pace. In this blog I want to give you a sense of ACI’s value to our customers who use it every day.

Looking back, when we started working on ACI, the industry had multiple definitions of SDN. Some confused it with APIs driving networking while other thought it’s related to software overlays. Our goal was clear – “automating the network and eliminating the gaps between application owners requirements vs. networking constructs.” This led us to architect the ACI from the ground up to meet these needs.

aci-pic2

Each of the items above probably requires a separate blog but let me provide a brief overview of them below.

Network Virtualization

The ability to host multiple independent tenants on the same infrastructure while providing full isolation and security was a key driver for ACI. These tenants can be independent companies, separate businesses within the same company or anything else which requires isolation and a private IP address space. You can draw a parallel to compute virtualization where the same server is used for multiple VMs, here the same network infrastructure is used for multiple independent networks for tenants.

Further, in traditional networks, the workloads mobility is limited within a layer 2 or layer 3 segment (aka VLAN or subnet). ACI eliminates this and provides placement of any workload anywhere in the infrastructure. This not only avoids need for pre-planning but also helps in placing workloads wherever capacity exists.

Unified Network

ACI was architected to provide a unified network independent of the type of workload – bare metal, virtual machine, or container. At the end of the day, workloads are IP endpoints and two IP end points want to connect. They need load balancing, security, and other services. Their life cycle may be static, may need migration, or simply a quick start/stop. ACI handles it all.

L4-L7 services are a critical part of any application workload deployment. There are plenty of choices in the industry and customers settle on a vendor based on its needs. Here in ACI, we took an open approach of integrating with any vendor and any form factor (physical appliance, or VM) for service delivery. Please see my blog on service insertion here.

Application Centric

What if the network can understand what application teams want to deploy? For example, an application owner asks for a web application with three tiers being Web, App, and DataBase. The Web tier needs to be load balanced and all tiers must enforce security and isolation.

This is what makes ACI an “Application Centric Infrastructure”. The APIC controller takes application centric inputs like the ones above, provisions physical switches, virtual switches for multi hypervisors, and multi-vendor L4-L7 services to provide consistent deployment, monitoring, and visibility. As an IaaS admin, you may still want to see VLANs, ports, route tables, etc. and all of these are still preserved.

Security is fundamental to all these deployments and I’ve described the security aspects of ACI in my earlier blog here

Controller Built to Scale

Remember, whenever you have a central controller, impact of failures could be broad. These failures could be the result of unauthorized access, weak high availability, scale limitations, or even fat fingering during configuration.

These were the exact considerations we had in mind as we started building the APIC controller. Let me highlight a few aspects of the APIC. In ACI, all customer traffic is switched by the infrastructure while the APIC acts as a highly available policy controller. The APIC itself is built on principles of distributed processing and data sharding providing unmatchable scale in the industry. Based on customer demand, so far we have released 200 leafs with 5 APIC controllers in a single ACI fabric. If you assume 48 ports per leaf this is 9600 server ports. The architecture isn’t limited at this level but horizontally scales out further; it just requires a qualification effort.

The security of the controller is captured here. A recently released capability in ACI release 1.1(3f) called “show usage” lets admins see what will be the impact of pending changes before a change is made and thus preventing “fat fingers” from causing disruption.

Operationalizing the ACI Fabric

Our customers constantly demand help with their day 2 operations. It’s not just about ability to configure but also being able to operate the fabric day in, day out.

Some of their top operational challenges were:

  1. Provisioning and de-provisioning takes a lot of time
  2. There is no integration of end-to-end infrastructure with the Application
  3. Problems are hard to isolate if networks are large or complex
  4. What are the causes of application performance issues
  5. Resolving and preventing human errors
  6. How to correlate with L4-L7 services devices
  7. Finding defective or malfunctioning devices

To deliver pro-active management of the fabric, we enabled the APIC to provide visibility across bare metal and/or virtual workloads including L4-L7 services from any vendor. Native application level visibility and trouble-shooting capabilities in ACI make it truly unique SDN fabric for day to day operation. Please check one such example video here.

Unified Northbound APIs

Every aspect of the system, whether it’s application centric specifications or the finer details of switch fabric, are exposed through the APIC northbound RESTful APIs. The APIC’s GUI itself is built using these published open APIs. This is what allows our customers and partners to easily integrate ACI into their ecosystem. You can find our ever-growing list of ecosystem partners here.

Conclusion

Our customers inspire us to continuously improve ACI, delivering on our vision to help them operationalize their data center transformations. Together we are on a journey that the networking industry has never traveled before. We apply our best architects and operational experts to engineer a smoother path for our customers. In future blogs, I hope to share more insights for those of you just beginning your journeys. 

For More Information:

Here is a list of excellent videos by Joe Onisick on ACI overview:

ACI Overview

Traffic Flows Through the ACI Fabric and the Application of Policy

End Point Groups operation in ACI

How Cisco ACI Stands out from other Network Virtualization Solutions

Tags:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

1 Comments

  1. Our customers have been asking for policy driven app level network isolation and ACI was the best possible way to deliver the security and compliance they needed.