ACI for (Smarter) Simple Minds

In a previous post I tried to describe the new Cisco ACI architecture in simple terms, from a software designer standpoint.

My knowledge on networking is limited, compared to my colleagues at Cisco that hold CCIE certifications… I am a software guy the just understands the API   ;-)

Though, now I would like to share some more technical information with the same “not for specialists” language.

You can still go to the official documentation for the detail, or look at one of the brilliant demo recorded on YouTube.

These are the main points that I want to describe:

- You don’t program the single switches, but the entire fabric (via the sw controller)

- The fabric has all active links (no spanning tree)

- Policies and performances benefit from a ASIC design that perfectly fits the SDN model

- You can manage the infrastructure as code (hence, really do DevOps)

- The APIC controller manages also L4-7 network services from 3rd parties

- Any orchestrator can drive the API of the controller

- The virtual leaf of the fabric extends into the hypervisor (AVS)
- You get immediate visibility of the Health Score for the Fabric, Tenants, Applications

Next picture shows how the fabric is build, using two types of switches: the Spines are used to scale and connect all the leaves in a non blocking fabric that ensures performances and reliability.
The Leaf switches hold the physical ports where servers are attached: both bare metal servers (i.e. running a Operating System) and virtualized servers (i.e. running ESXi, Hyper-V and KVM hypervisors).
The software controller for the fabric, named APIC, runs on a cluster of (at least) 3 dedicated physical servers and is not in the data path: so it does not affect performances and reliability of the fabric, as it could happen with other solutions on the market.

 

The ACI fabric supports more than 64,000 dedicated tenant networks. A single fabric can support more than one million IPv4/IPv6 endpoints, more than 64,000 tenants, and more than 200,000 10G ports. The ACI fabric enables any service (physical or virtual) anywhere with no need for additional software or hardware gateways to connect between the physical and virtual services and normalizes encapsulations for Virtual Extensible Local Area Network (VXLAN) / VLAN / Network Virtualization using Generic Routing Encapsulation (NVGRE).

The ACI fabric decouples the endpoint identity and associated policy from the underlying forwarding graph. It provides a distributed Layer 3 gateway that ensures optimal Layer 3 and Layer 2 forwarding. The fabric supports standard bridging and routing semantics without standard location constraints (any IP address anywhere), and removes flooding requirements for the IP control plane Address Resolution Protocol (ARP) / Generic Attribute Registration Protocol (GARP). All traffic within the fabric is encapsulated within VXLAN.

The ACI fabric decouples the tenant endpoint address, its identifier, from the location of the endpoint that is defined by its locator or VXLAN tunnel endpoint (VTEP) address. The following figure shows decoupled identity and location.

 

Forwarding within the fabric is between VTEPs. The mapping of the internal tenant MAC or IP address to a location is performed by the VTEP using a distributed mapping database. After a lookup is done, the VTEP sends the original data packet encapsulated in VXLAN with the Destination Address (DA) of the VTEP on the destination leaf. The packet is then de-encapsulated on the destination leaf and sent down to the receiving host. With this model, we can have a full mesh, loop-free topology without the need to use the spanning-tree protocol to prevent loops.

You can attach virtual servers or physical servers that use any network virtualization protocol to the Leaf ports, then design the policies that define the traffic flow among them regardless the local (to the server or to its hypervisor) encapsulation.
So the fabric acts as a normalizer for the encapsulation and allows you to match different environments in a single policy.

Forwarding is not limited to nor constrained by the encapsulation type or encapsulation-specific ‘overlay’ network:





As explained in ACI for Dummies, policies are based on the concept of EPG (End Points Group).
Special EPG represent the outside network (outside the fabric, that means other networks in your datacenter or eventually the Internet or a MPLS connection):

The integration with the hypervisors is made through a bidirectional connection between the APIC controller and the element manager of the virtualization platform (vCenter, System Center VMM, Red Hat EVM...). Their API are used to create local virtual networks that are connected and integrated with the ACI fabric, so that policies are propagated to them.
The ultimate result is the creation of Port Groups, or the like of, where VM can be connected.
A Port Groups represents a EPG.
Events generated by the VM lifecycle (power on/off, vmotion...) will be sent back to APIC so that the traffic is managed accordingly.

How Policies are enforced in the fabric

The policy contains a source EPG, a destination EPG and rules known as Contracts, made of Subjects (security, QoS...). They are created in the Controller and pushed to all the leaf switches where they are enforced.
When a packet arrives to a leaf, if the destination EPG is known it is processed locally.
Otherwise it is forwarded to a Spine, to reach the destination EPG through a Leaf that knows it.

There are 3 cases, and the local and global tables in the leaf are used based on the fact that the destination EP is known or not:
1 - If the target EP is known and it's local (local table) to the same leaf, it's processed locally (no traffic through the Spine).
2 - If the target EP is known and it's remote (global table) it's forwarded to the Spine to be sent to the destination VTEP, that is known.
3 - If the target EP is unknown the traffic is sent to the Spine for a proxy forwarding (that means that the Spine discovers what is the destination VTEP).

You can manage the infrastructure as code.

The fabric is stateless: this means that all the configuration/behavior can be pushed to the network through the controller's API. The definition of Contracts and EPG, of POD and Tenants, every Application Profile is a (set of) XML document that can be saved as text.
Hence you can save it in the same repository as the source code of your software applications.

You can extend the DevOps pipeline that builds the application, deploys it and tests it automatically by adding a build of the required infrastructure on demand.
This means that you can use a slice of a shared infrastructure to create a environment just when it's needed and destroy it soon after, returning the resources to the pool.

You can also use this approach for Disaster Recovery, simply building a clone of the main DC if it's lost.

Any orchestrator can drive the API of the controller.

The XML (or JSON) content that you send to build the environment and the policies is based on a standard language. The API are well documented and lot of samples are available.
You can practice with the API, learn how to use them with any REST client and then copy the same calls into your preferred orchestrator.
Though some products have out of the box native integration with APIC (Cisco UCSD, Microsoft), any other can be used easily with the approach I described above.
See an example in The Elastic Cloud Project.

The APIC controller manages also L4-7 network services from 3rd parties. 

The concept of Service Graph allows a automated and scalable L4-L7 service insertion.  The fabric forwards the traffic into a Service Graph, that can be one or more service nodes pre-defined in a series, based on a routing rule.  Using the service graph simplifies and scales service operation: the following pictures show the difference from a traditional management of the network services.

The same result can be achieved with the insertion of a Service Graph in the contract between two EPG:

The virtual leaf of the fabric extends into the hypervisor (AVS).

Compared to other hypervisor-based virtual switches, AVS provides cross-consistency in features, management, and control through Application Policy Infrastructure Controller (APIC), rather than through hypervisor-specific management stations. As a key component of the overall ACI framework, AVS allows for intelligent policy enforcement and optimal traffic steering for virtual applications.

The AVS offers:

• Single point of management and control for both physical and virtual workloads and infrastructure
• Optimal traffic steering to application services
• Seamless workload mobility
• Support for all leading hypervisors with a consistent operational model across implementations for simplified operations in heterogeneous data centers

Cisco AVS is compatible with any upstream physical access layer switch that complies with the Ethernet standard, including Cisco Nexus Family switches. Cisco AVS is compatible with any server hardware listed in the VMware Hardware Compatibility List (HCL). Cisco AVS is a distributed virtual switch solution that is fully integrated into the VMware virtual infrastructure, including VMware vCenter for the virtualization administrator. This solution allows the network administrator to configure virtual switches and port groups to establish a consistent data center network policy.

Next picture shows a topology that includes Cisco AVS with Cisco APIC and VMware vCenter with the Cisco Virtual Switch Update Manager (VSUM).

 

Health Score

The APIC uses a policy model to combine data into a health score. Health scores can be aggregated for a variety of areas such as for infrastructure, applications, or services.

The APIC supports the following health score types:

●      System—Summarizes the health of the entire network.

●      Leaf—Summarizes the health of leaf switches in the network. Leaf health includes hardware health of the switch including fan tray, power supply, and CPU.

●      Tenant—Summarizes the health of a tenant and the tenant’s applications.

Health scores allow you to isolate performance issues by drilling down through the network hierarchy to isolate faults to specific managed objects (MOs). You can view network health by viewing the health of an application (by tenant) or by the health of a leaf switch (by pod).

You can subscribe to a health score to receive notifications if the health score crosses a threshold value. You can receive health score events via SNMP, email, syslog, and Cisco Call Home.  This can be particularly useful for integration with 3rd party monitoring tools. 

Health Score Use case: 
An application administrator could subscribe to the health score of their application - and receive automatic notifications from ACI if the health of the specific application is degraded from an infrastructure point of view - truly an application-aware infrastructure.

Conclusion

I hope that these few lines were enough to show the advantage that modern network architectures can bring to your Data Center.
Cisco ACI joins all the benefit of the SDN and the overlay networks with a powerful integration with the hardware fabric, so you get flexibility without losing control, visibility and performances.

One of the most important aspects is the normalization of the encapsulation, so that you can merge different network technologies (from heterogeneous virtual environments and bare metal) into a single well managed policy model.

Policies (specifically, the Application Network Policies created in APIC based on EPG and Contracts) allow a easier communication between software application designers and infrastructure managers, because they are simple to represent, create/maintain and enforce.

Now all you need is just a look at ACI Fundamentals on the Cisco web site.

Cloud Computing as an extension of SOA

When I started explaining my view of Cloud Computing as an extension of SOA (Service Oriented Architecture) someone didn't take it seriously.
I delivered some TOI sessions to increase the awareness on topics that Cisco was approaching in its transformation into a IT company: software architecture, distributed systems, IT service management. I reused some of the concepts and the slides that I created when I was a SOA evangelist.

The feedback was positive and generated a useful discussion, but I also got few comments like: "this is old stuff, cloud is different" and "don't be nostalgic".
After those days, indeed, I've seen many articles comparing Cloud and SOA.

And it is natural: both the architectures (actually cloud is a consumption model more that a architecture) are based on the concept of Service. To be precise, to offer and consume cloud services you need to build a SOA.

It is easy to understand: to begin with, the consumer of a cloud service wants to delegate the build, the ownership and the operations to a third party, that assumes the responsibility for the SLA.
The service is considered a function that someone else provides to you, and you only care the interface to access it (and the quality and the price). You are interested only in the protocol and the user interface - or the API - plus the URL where you get the service.

The actual implementation is not your business. The service (IaaS, PaaS, SaaS) can run on any platform, in any part of the world, fully automated or manual, implemented in any of the hundreds of programming languages. You just don't care, as long as they respect the SLA.

Definitions

The most known definition of cloud computing is from NIST:
 

While SOA was defined, when I was at BEA Systems (one of the SOA pioneers), in this way:

SOA is an architectural approach that enables the creation of loosely coupled, 

interoperable business services that can be easily shared  

within and between enterprises.

A slightly more technical definition is: "Service-Oriented Architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.

You can find a discussion of the SOA reference architecture (sorry, it's limited to my italian readers...) here. Also IBM has a good definition of SOA here.

 

SOA concepts that apply to Cloud 

There are some concepts that you find in both the models: each one would deserve a dedicated post, or maybe a book. I will try to give some essential detail in this post.

• The concept of Service: Consumer and Provider’s responsibility
• Distributed systems, where remote API are invoked over standard protocols
• Separation of concerns: interface vs implementation
• Interface and Contract
• Reuse and Loose Coupling
• Service Repository and Service Catalog
• Service Lifecycle
• Service Assurance
• Strategy and Governance

Basic detail 

 

Distributed systems

A distributed system is made of components that are deployed separately, in most cases remotely. Each of them provides a lower level functionality that can be used as a building block for the solution of a business need.
To inter-operate, they need connectivity and a well defined framework for sending and receiving data, managing security, transactions consistency, availability and many other non-functional requirements.

To make the development of such a complex system easier, the software industry has separated the concept of interface from the actual implementation.
The interface of a sw component specifies the functions it implements, the parameters it expects and  returns, their format, the conversation style (sync/async) and the security constraints. It is an artifact that can be produced - and deployed - before the actual implementation is ready: you can generate a stub (or mock) component that always returns fake data, but at least it replies to clients allowing the end to end test of the architecture.

So different developers can split the implementation of the system in components that are built in parallel, based on the definition of the interface that they present to each other. The basic integration test can be executed against a stub, to ensure that the conversation works. This also helps rapid prototyping and agile development.

The separation of the interface from the implementation is fundamental when a distributed system is designed.


A Service = Contract + Interface + Implementation 
The set of the above mentioned artifacts identifies a service.

As I stated, the implementation is not relevant for the consumer of the service - but it must exist, otherwise the service cannot be delivered.

The interface is the only visible part of the service, because the consumer will use that one. Depending on the service, it could be a GUI or the API that a client program invokes.

The most important part is the Contract: the agreement (generally defined in a document) defining who has the right to consume the service, the credentials, the price, the SLA, the constraints (e.g. the response time is granted up to 1000 transactions per second), and more.

A given interface could be offered with two distinct contracts, e.g. with different security requirements. Or different price, or different SLA, ect.
If you do that, a new service is generated (a different triple of contract+interface+implementation):

And of course you can differentiate the interface (e.g. sysnchronous vs asynchronous, that is pretty easy if you use a service bus). Also the addition of a new interface will generate a new service:

Reuse and Loose Coupling 

The effort of building a service in a way that makes it reusable is bigger than just implementing a local component in a software project.
Potential consumers of the service will trust it if it is robust enough, it scales, it is secure, etc.
You need to provide information on what the service does, how to use it, how do you support it.
So a business justification is needed for the additional effort to create a reusable service, both for internal usage (SOA) or as a cloud service.

The integration between service consumers and providers should not create tight dependencies, to allow for innovation and maintenance. Coupling refers to the degree of direct knowledge that one element has of another. The separation of the interface from the implementation plays an important role here, because one could change the implementation without affecting the published interface.
In case of major changes, versioning the interface helps.
See also these definitions of loose coupling on Wikipedia and Techtarget.

Service Repository and Service Catalog

I said that you need to provide information on the service and, eventually, market it. If potential consumers don't know that it exists, they will never use it. They also need descriptive info and technical details.
This is true when you build services for the enterprise architecture, even more if you want to sell them in the cloud. 

An important element of the Service Oriented Architecture was the Service Repository. A central point where all the artifacts produced by projects are exposed for reuse, complemented by the Registry offering a link to the service end points.
Now we have the concept of Service Catalog, managing the entire life cycle of a cloud service: from the inception to the decommissioning, passing through cost models and tenants management.
You can find a definition of a service catalog and its usage in this excellent free book: Defining IT Success Through the Service Catalog

 

Service Lifecycle

When a new service is created, you need to design its provisioning process - that could include fully automated or manual steps, including authorizations - its cost model, the management of the resources allocated for a tenant, the assurance of the quality of the service, the billing and end user reporting, the decommissioning and returning the resource to the shared pool.

It is good to have tools to manage all these phases of the life cycle. A choice of CMS (Cloud Management Systems) is offered by Cisco, that have a solution for a ready to run cloud implementation with pre built services (Cisco Intelligent Automation for Cloud, aka IAC) and the just released Cisco ONE Enterprise Cloud suite, a flexible environment where you can create new services with a very little effort, in a bottom-up approach (from the infrastructure to the catalog).
Both the suites use Cisco Prime Service Catalog (PSC) and the front end. PSC is ranked very high by analysts when they examine the features of service catalogs on market.

 

Service Assurance

Monitoring the infrastructure is essential, if you are a service provider. But it is not enough, because you can't immediately correlate the health status of the infrastructure with the quality of the services that consumers perceive (availability, response time, completeness of the result...).
More sophisticated tools are needed to report the services heath score to the Operations team and to the end users, and to allow troubleshooting.
Root cause analysis is the investigation of the ultimate cause for a service failure that could be due to software, servers, network, storage.
Impact analysis is the notification of the list of services impacted by a fault in the infrastructure, that helps the Operations team to restore the services before consumers complain for a violation of the SLA.

Strategy and Governance

IT governance provides the framework and structure that links IT resources and information to enterprise goals and strategies. Furthermore, IT governance institutionalizes best practices for planning, acquiring, implementing, and monitoring IT performance, to ensure that the enterprise's IT assets support its business objectives.

In recent years, IT governance has become integral to the effective governance of the modern enterprise. Businesses are increasingly dependent on IT to support critical business functions and processes; and to successfully gain competitive advantage, businesses need to manage effectively the complex technology that is pervasive throughout the organization, in order to respond quickly and safely to business needs.

In addition, regulatory environments around the world are increasingly mandating stricter enterprise control over information, driven by increasing reports of information system disasters and electronic fraud. The management of IT-related risk is now widely accepted as a key part of enterprise governance.

It follows that an IT governance strategy, and an appropriate organization for implementing the strategy, must be established with the backing of top management, clarifying who owns the enterprise's IT resources, and, in particular, who has ultimate responsibility for their enterprise-wide integration.

I discussed this topic with reference to SOA (only in italian, again... sorry) in SOA è solo tecnologia? and in

6 errori da non fare in un progetto SOA

 

Enterprise Service Bus

The ESB is a core component in the SOA Reference Architecture. It has the role of a mediation layer between the consumers and the providers of any service, managing the match of available interfaces, the security, the quotas and - in general - the enforcement of the Contract.
The ESB is the backbone of a Enterprise Architecture where new projects benefit from reusing already implemented services.

When you think about cloud, the public interface to available services is offered publicly to consumers. Very often, it consists in a set of API to provision and consume the services. A ESB is not strictly required to expose your implementation as a service, but it can certainly help.
Creating multiple interfaces, as long as new contracts are defined for a service, is just a few clicks activity. There are many ESB available as commercial products, next paragraph shows one example but the same capabilities are commonly available on the market and in the open source.

ESB Core Capabilities (courtesy of Mule Soft - http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb):

• Service Mediation
  Separate business logic from protocols and message formats for rapid, nimble development and long-term flexibility.
• Service Orchestration
  Coordinate and arrange multiple services and expose them as a second-generation composite application.
• Service Creation & Hosting
  Expose app functionality as a service and create an efficient standards-based architecture or host existing services in lightweight containers.
• Message Routing
  Direct messages based on content or predetermined rules and filter, aggregate, or re-sequence as required.
• Data Transformation
  Transform data to and from any format across heterogeneous transport protocols and data types or enhance incomplete messages.
• Event Handling
  Deliver synchronous and asynchronous events, transactions, streaming, routing patterns, and a SEDA architecture.

So are SOA and Cloud identical?

Of course not. They have a lot of common concerns, but while SOA was created to address IT and business needs in a single Enterprise context, Cloud is a wider model that offers commercial services across companies.
There's still the private cloud model, where services are offered internally.
Here we have the same self service consumption model, so the automation of the provisioning is critical as well as the quality of the Service Catalog that you offer to consumers.

The most important lesson from SOA that we can reuse in Cloud is that the human factor is sometimes more impactful than the technology.
Change management is one of the key initiatives that help winning the resistance (both in the IT organization, when a new operational model is adopted, and across consumers that are offered a new way of using applications or implementing new projects). 

A proper documentation of the services is key, and the definition of a go-to-market strategy before you start your journey is fundamental: technology should not be adopted because it's smart or because others are doing the same.
It should always be functional to business requirements and be aligned with the corporate strategy.

Links

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://www.alleywatch.com/2013/03/people-as-a-service/
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
http://www-01.ibm.com/software/solutions/soa/what-is-soa.html
http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb

ACI for Simple Minds

Cisco ACI means Application Centric Infrastructure 

Why application designers and developers don't want to speak to network engineers. 

In my previous life I was an enterprise architect and I led design and development of software systems in many projects. When we were in the phase of planning the procurement and the setup of the various environments for the project (dev, test, QA, prod) I was bored by the meetings with the infrastructure guys.
What I needed was a given amount of memory and CPU power, that I could calculate myself, on a single big server or on a number of smaller machines. Then I needed connectivity among the different deployment units in my architecture (a cluster of web servers, a cluster of application servers, a database and some pre-existing systems), and just some services like load balancing.
But those nasty network engineers and the ugly security guys wanted to discuss a long list of requirements and settings: vlans, ip addresses, subnets, firewalls, quality of service, access lists   :-(
I was only interested in application tiers and dependencies, SLA, application performances and compliance and I wanted to discuss that in my language, not in their unfamiliar slang.

How the system engineers see the world: a number of devices with their configuration.

 

How I see the world: a number of servers (or processes) with their role in the application. We can call them End Points.

The communication can be described as a contract.

Provided by some end points, consumed by others. 

And saved as a reusable policy, that could be applied to End Point Groups:

 

 

Eventually, network services like load balancers or firewalls can be added (creating a service graph):

You can easily understand that our meetings were not that easy    ;-)
It was not their fault (and of course it was not... mine): we only saw the world from different angles, or maybe with different glasses.

For the software guys, abstracting the topology of the deployment is essential. For the system guys, devil is in the detail and they need to know exactly what traffic is flowing to engineer the setup accordingly.

Having a set of policies that describe the desired behavior makes the conversation easy: what service is offered by a end point group, what group (or single end point) can consume it, what SLA should be enforced, etc... Contracts could be: access to a web application on http on port 80, access to montoring agents or to log collectors, access to a LDAP server for authentication and so on.
You will see later in the post that ACI allows this conversation.

After long discussions and escalations, the setup of the environment was never as fast as I needed.
It was not the DevOps time yet, but we still tried to roll out many builds of the application for rapid prototyping and quick wins.

Now imagine that you were able to agree on the policy definition.
Having an instant enforcement of those policies on all your network devices without touching them one by one, in a consistent way that prevents human errors and grants compliance by default, and have it done soon would be a miracle... or a magic.

Now we have a network architecture that makes this miracle real: Cisco ACI.
A single software controller (redundant, of course) manages all the network connectivity, security and the network services like load balancers and firewalls.
The network is a hardware fabric, with great performances, scalability, resiliency that I will not discuss here (see the links below for the detail), that extends smoothly into the virtual networks of any vendor or open source solution enforcing the policies for physical servers and VM as end points without any difference.
The controller (named APIC) has a GUI but, most important, a rich set of open API that can be invoked by your scripts, by orchestration tools from Cisco or 3rd parties, by cloud management systems.
You can create the policy from here, and also see the "telemetry" of the network with easy display of the health score of the fabric or individual applications as well.

Use cases for ACI

Fast provisioning

A stateless network like ACI can be provisioned and completely reshaped in seconds by pushing new policies through the controller.
This concept is pretty similar to what the UCS Service Profile made possible in the server industry, introducing the stateless computing.
You can add the complete configuration for a new application to a multitenant shared infrastructure, you can create a new tenant environment, you can create the test environment and the production environment just by cloning the development environment and applying any needed policies to ensure compliance.
Everything is represented as a XML document or a JSON data structure: in any case a small piece of text data that can be saved, versioned and built automatically by a automation script or tool.
Infrastructure as code is one of the pillars of DevOps.

Physical and virtual networking managed the same

When you design End Point Groups and their Contracts, they can be mapped to physical servers (i.e. servers running a single Operating System, like Linux, Unix or Windows servers) or to VM running on any hypervisor.
Traffic from a VM is encapsulated and isolated from other VM's, then the policies are applied to allow it to flow to the destination (physical or virtual).
The spine-leaf architecture of the fabric is extended by a virtual leaf that runs in the hypervisor, under the control of the APIC Controller.

Service Graph

The integration of network services (LB, FW, etc.) from 3rd parties is easy thanks to the Opflex protocol, that allows the extension of the declarative style (vs imperative) of the configuration.
You can add the services to a contract and all the end point that offer and consume that contract will benefit from the insertion without any need for local configuration (e.g. changing the default gateway to the newly inserted firewall).
Many 3rd party vendors added - or will add soon - Opflex agents to their product. The wide ecosystem of ACI becomes richer every day.

Easy deprovisioning

Often, when an existing application is deprovisioned, the network and security configurations created for it are not deleted.
This is due to different reasons: either because it's hard to find them (not all the organizations use a CMDB to track everything) or because the responsible for the operation is afraid of removing firewall rules, ACL, vlans that could potentially be used by a different application, creating a problem as a consequence.

If you have all the policies for a given application defined as attributes of a specific Application Network Profile in APIC, simply removing that ANP will clean all the configurations. You were not applying rules to ports (where other application could be attached) but to end points.

Finally, what advantages can you get from ACI?

Centralized Policy-Defined Automation Management
 • Holistic application-based solution that delivers flexibility and automation for agile IT
 • Automatic fabric deployment and configuration with single point of management
 • Automation of repetitive tasks, reducing configuration errors

Open and Comprehensive End-to-End Security
 • Open APIs, open standards, and open source elements that enable software flexibility for DevOps teams, and firewall and application delivery controller (ADC) ecosystem partner integration
 • Automatic capture of all configuration changes integrated with existing audit and compliance tracking solutions
 • Detailed role-based access control (RBAC) with fine-grained fabric segmentation

Real-Time Visibility and Application Health Score
 • Centralized real-time health monitoring of physical and virtual networks
 • Instant visibility into application performance combined with intelligent placement decisions
 • Faster troubleshooting for day-2 operation

Application Agility
 • Management of application lifecycle from development, to deployment, to decommissioning in minutes
 • Automatic application deployment and faster provisioning based on predefined profiles
 • Continuous and rapid delivery of virtualized and distributed applications

If you liked this post, you may want to read also ACI for (smarter) Simple Minds. You have passed the basic stage now   :-)

Links

Serious product documentation

ACI Marketing page
ACI at a glance
ACI in one page
Application Centric Infrastructure (ACI) Documentation
Learning ACI - Adam's blog

Cartoons (2 min. each)

2015 ACI Video Episode 1: An Impossible Deadline

2015 ACI Video Episode 2: The Needle in the Haystack 

2015 ACI Video Episode 3: Operation Clean Up

The Elastic Cloud project - Methodology

This posts is the continuation of the post The Elastic Cloud Project - Architecture.

Here I will explain how we worked in the project: the sequence of activities that were required and the basic technologies we adopted.

The concepts are mostly explained by using pictures and screen shots, because an image is often worth 1000 words.

If you are interested in more detail, please add a comment or send me a message: I’ll be glad to provide detailed information.

To begin with, we had to:

• map the data model of the products used to understand what objects should be created, for a Tenant, in all the layers of the architecture
• create sequence diagrams to make the interaction clear to all the members of the team - and to the customer
• understand how the API exposed by Openstack Neutron and from Cisco APIC work, how they are invoked and what results they produce
• implement workflows in the CPO orchestrator to call the APIC controller and reuse the existing services in Cisco IAC
• integrate Hyper-V compute nodes in Openstack Nova
• create a new service in the Service Catalog to order the deployment of our 3 tiers application

Some detail about the activities above:

1 - Map the data model of the products used to understand what objects should be created, for a Tenant, in all the layers of the architecture

know that some of you still don’t know Cisco ACI… I promise that I will post a “ACI for dummies” soon.   :-)

  

This picture shows how concepts in Openstack Neutron map to concepts in Cisco ACI:

2 - Create sequence diagrams to make the interaction clear to all the members of the team

3 - Understand how the API exposed by Openstack Neutron and from Cisco APIC work, how they are invoked and what results they produce

This is a call to the Cisco APIC controller, using XML

This is a call to the Openstack Nova API, using JSON:

to do this, we used a REST client to learn the individual behavior and how the parameters need to be passed

a REST call is essentially a http call (GET or POST) where the body contains XML or JSON documents

some http headers are required to specify the content type and to hold security information (like a token for single sign on, that is returned by the authorization call and you need to resend in all the following calls to be recognized.

So we adopted Google Postman, that is a plugin for the Chrome browser (latest version is also released as a standalone application) to practice with the REST Calls then,after we learned how to manage them, we just copied the same content (plus the headers) into the “http call” tasks in the CPO workflow editor.

The XML or JSON variables that we passed are essentially static documents with some placeholders for current values, i.e. the Tenant name, the Network name, etc. were passed according to the user input.

Of course the XML elements tags are described in the APIC product documentation, you don’t have to reverse engineer their meaning   ;-)

Another way to get the XML ready to use is to export it from the APIC user interface: if you select an object that has been created already (either though the GUI or the API), you can export the corresponding XML definition:

This is how we copied the XML content from the test made in Postman and replaced some elements with placeholders for current values (that are variables in the workflow designer):

This is how the variable appear in the workflow instance viewer, after you have executed the process because a user ordered the service:

4 - Implement workflows in the CPO orchestrator to call the APIC controller and reuse the existing services in Cisco IAC

An example of the services that Cisco IAC provides out of the box.

They are also available through the API exposed by the product, so we created a custom workflow that reused some of the services as building block for our use case implementation.

his is the workflow editor, where we created the orchestration flow:

5 - integrate Hyper-V

At the time of this project, a direct support for Microsoft Hyper-V was not available in Openstack Nova.

But a free library was available from Cloudbase, so we decided to install it on our Hyper-V serverso that the virtual data center (VDC) we had created in Cisco IAC thanks to the integration with Openstack could use also Hyper-V resources to provision the VM.

More detail on the integration can be found here: http://www.cloudbase.it/openstack/

In the current Openstack release (Juno), Hyper-V servers are managed directly.

6 - create a new service in the Service Catalog

Conclusion

This project had a complexity that derived from being the among the first teams in the world to try the integration of so many disparate technologies: Cisco software products for Service Catalog and Orchestration, three hypervisors (ESXi, Hyper-V, and KVM), physical networks (Cisco ACI) and virtual networks in all the hypervisors, Openstack.

I didn't tell you, but also load balancers and firewalls were integrated.

Maybe I will post some detail about the Layer 4 - Layer 7 service chaining in the next weeks.

We had to learn the concepts before learning the products. Actually theinvestigation of the API and their integration was the easiest part... and was also fun for my ancient memory of programmer   :-)

Now, with the current release of the products involved in this project, everything would be much easier.

Their features are more complete (actually the integration of the Neutron API in the management of Virtual Data Centers in ACI was fed back to our engineering during this project).

Skills available on the field are deeper and widespread.

I've already implemented the same use case with alternative architectures twice.

Cisco UCS Director was used once, replacing the IAC orchestration and pre-built services.

And, in another variation, the Openstack API were integrated directly instead of reusing the existing services that manage the Openstack VDC in IAC.

Just to have more fun... ;-)

The Elastic Cloud Project - Architecture

This posts is the continuation of The Elastic Cloud Project post.

There is a team at Cisco, called System Development Unit, that creates reference architectures and CVD (Cisco Validated Design).

They work with the product Business Units to define the best way to approach common use cases with the best technology.

But at the time of this project, they hadn’t completed their job yet (some of the products were not even released).

So we had to invent the solution based on our understanding of the end to end architecture and integrate the technologies on the field.

As I explained before, the most important components were:

- servers - Cisco UCS blades and rack mount servers

- network - Cisco ACI fabric, including the APIC software controller

- virtualization - ESXi, Hyper-V, KVM

- cloud and orchestration software - Cisco PSC and CPO, Openstack (PSC and CPO, plus pre-built services, make up Cisco Intelligent Automation - IAC)

IAC can integrate different “element managers” in the datacenter, so that their resources are used to deliver the cloud services (e.g. single VM or Virtual Data Centers - VDC).

Element managers include vmware vCenter and Openstack, so a end user can get a VDC based on one of these platforms.

There is a autometed process in IAC, called CloudSync, that discovers all the resources available in the element managers and allow the admin to select those he wants to use to provision services (resource management and lifecycle management are amongst the features of the product).

The ACI architecture

I will cover it in detail in one of next posts, but essentially ACI (http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html), that stands for Application Centric Infrastructure, is a holistic architecture with centralized automation and policy-driven application profiles. ACI delivers software flexibility with the scalability of hardware performance. 

Cisco ACI consists of:

• The new Cisco Nexus 9000 Series Switches
• A centralized policy management and Cisco Application Policy Infrastructure Controller (APIC)
• A Cisco Application Virtual Switch (AVS) for the virtual network edge
• Software and hardware innovations
• Integrated physical and virtual infrastructure
• An open ecosystem of network, storage, management, and orchestration vendors
  
  
  

The policies that you create in the software controller (APIC) are enforced by the fabric, including physical and virtual networks.

You describe the behavior your application need from the network, non the configuration you need.

This is easier for the application designer, in the collaboration with network managers, because it can be graphically described by the Application Network Profile.

A profile contains End Point Groups (EPG, representing deployment units of the application: both physical and virtual servers) and Contracts (that define the way EPG can communicate).

A profile can be saved as a XML or JSON document, stored in a repository, participate in the Devops lifecycle, used to clone a environment and managed by any orchestrator.

ACI is integrated with the main virtualization platforms (ESXi, Hyper-V, KVM).

To deploy our 3 tier application on 3 different hypervisors, we had to manage vmware and Openstack separately - but in a single process, because everything should be provisioned with a single click.

Initially we based our custom implementation of the new service on the standard IAC services, using them as building blocks.

So we had not to implement the code to create a network, create a VDC, create a Virtual Server, trigger CloudSync, integrate the virtual network with the hardware fabric.

This sequence of operations was common to the Openstack environment and the vmware environment.

The main workflow was built with two parallel branches, the Openstack branch (creating 2 web servers on one network and 1 application server on anothernetwork) and the vmware branch (doing the same for the database tier).

The problem is that the integration of IAC with Openstack, in the 4.0 release that we used at that time, only deals with Nova - that, in turn, manages both KVM and Hyper-V servers.

No Neutron integration was available out of the box, hence no virtual networks for the Openstack based VDC.

So we built the Neutron integration form scratch (implementing direct REST calls to the Neutron API) to create the networks.

The ACI plugin for Neutron does the rest: it talks to the APIC controller to create the corresponding EPG (End Point Group).

This implementation has been fed back to IAC 4.1 by the Cisco engineering, so in the current release it is available out of the box.

Solution for Openstack

A plugin distributed by Cisco ACI was installed in Openstack Neutron, to allow it to integrate into the APIC controller.

This is transparent to the Openstack user, that goes on working in the usual way: create network, create router, create VM instances.

Instructions are sent by Openstack to APIC, so that the corresponding constructs are deployed in the APIC data model (Application Profiles, End Point Groups, Contracts).

The orchestrator can then use these objects to create a specific application logic, spanning the heterogeneous server farms and allowing networks in KVM to connect to networks in ESXi and Hyper-V.

So the workflow that we built only needed to work with the native API in Openstack.

Logical flow:

— web tier --

create a virtual network for the web tier via Neutron API

     the Neutron plugin for ACI calls - implicitly - the APIC controller and creates a corresponding EPG.

     the Neutron plugin for OVS creates a virtual network in the hypervisor's virtual switch

trigger the CloudSync process, so that the new network is discovered and attached to the VDC

create a VM for the web server and attach it to the network created for the web tier

     this was initially done by reusing the existing IAC service “Provision a new VM"

— application server tier — 

create a virtual network for the app tier via Neutron API

     the Neutron plugin for ACI calls - implicitly - the APIC controller and creates a corresponding EPG.

     the Neutron plugin for OVS creates a virtual network in the hypervisor's virtual switch

trigger the CloudSync process, so that the new network is discovered and attached to the VDC

create a VM for the application server and attach it to the network created for the app tier

     this was initially done by reusing the existing IAC service “Provision a new VM"

— connect the tiers via the controller —  

connect the two EPG with a Contract, that specifies the business rules of the application to be deployed

     this is done via the APIC Controller’s API, creating the Application Profile for the new application in the right Tenant

Solution for vmware

The APIC controller has a direct integration with vmware vCenter, so the integration is slightly different from the Openstack case:

The operations are performed directly against the APIC API and, when you create a EPG there, APIC uses the vCenter integration to create a corresponding virtual network (a Port Group) in the Distributed Virtual Switch.

So we added a branch to the main process to operate on APIC and vCenter, to complete the deployment of the 3 tier application with the database tier. 

Logical flow:

— database server tier — 

call the APIC REST interface, implementing the right sequence (authentication, create Tenant, Bridge Domain, End Point Group, Application Network Profile).

     specifically a EPG for the database tier is created in the APIC data model, and this triggers the creation of a port group in vCenter.

trigger the CloudSync process, so that the new network is discovered and attached to the VDC

create a VM for the database server and attach it to the network created for the app tier

     this was initially done by reusing the existing IAC service “Provision a new VM"

Service Chaining

The communication between End Point Groups can be enriched by adding network services: load balancing, firewalling, etc.

L4-L7 services are managed by APIC by calling external devices, that could be either physical or virtual.

This automation is based on the availability of device packages (set of scripts for the target device), and a protocol (Opflex) has been defined to allow the declarative model supported by ACI being adopted by all 3rd party L4-L7devices. 

Cisco and its partners are working through the IETF and open source community to standardize OpFlex and provide a reference implementation.


In next post, I will describe the methodology we used to integrate the single pieces of the architecture, how we learned to use the API exposed by the target systems (APIC and Openstack) and to insert these calls into the orchestration flow.

Link to next post: The Elastic Cloud Project - Methodology