Home > Articles > Building Blocks for Data Center Cloud Architectures

Building Blocks for Data Center Cloud Architectures

Chapter Description

This chapter from The Policy Driven Data Center with ACI: Architecture, Concepts, and Methodology describes the components of a cloud infrastructure and how ACI provides network automation for the cloud. It also explains the Amazon Web Services approach; covers the role of the various orchestration tools; introduces some key concepts on how to automate the provisioning of servers and how to get started with OpenStack; explains the OpenStack modeling of the cloud infrastructure; and discusses the administrator’s task of mapping the requirements of IaaS services onto the models of these technologies.

Network Requirements of Clouds and the ACI Solution

The network infrastructure that provides support for cloud deployments must meet several requirements, such as:

  • Scale for a very large number of virtual machines
  • Support Layer 2 adjacency between workloads
  • Support multi-tenancy
  • Be highly programmable
  • Support the insertion of load balancers and firewalls
  • Support the insertion of virtual load balancers and virtual firewalls

The first and second requirements are almost incompatible because if the data center were built with traditional spanning-tree technologies, it would incur two problems:

  • Spanning-tree scalability limits on the control plane
  • Exhaustion of the MAC address tables

To address these requirements, the ACI fabric is built based on a VXLAN overlay, which allows switches to maintain perceived Layer 2 adjacency on top of a Layer 3 network, thus removing the control plane load associated with spanning tree from the switching infrastructure. To address the mobility requirements over a Layer 3 infrastructure, the forwarding is based on host-based forwarding of full /32 addresses combined with the mapping database.

This overlay, like most, requires the data path at the edge of the network to map from the tenant end point address in the packet, a.k.a. its identifier, to the location of the endpoint, a.k.a. its locator. This mapping occurs in a function called a tunnel endpoint (TEP). The challenge with this mapping is having to scale for very large data centers, because the mapping state must exist in many network devices.

The second problem with scale is that when an endpoint moves (that is, its locator changes), the mapping state must be updated across the network in all TEPs that have that mapping.

The ACI solution addresses these problems by using a combination of a centralized database of the mappings implemented in the packet data path, at line rate, and a caching mechanism, again in the data path, at the TEP. (Chapter 7, “ACI Fabric Design Methodology,” explains the traffic forwarding in ACI in detail.)

The other key requirement of building a cloud solution is to be able to instantiate networks in a programmatic way. If the network is managed box by box, link by link, the script or the automation tool must access individual boxes and trace where a workload is in order to enable VLAN trunking on a number of links. It must also ensure that the end-to-end path is provisioned according to the abstraction model. ACI solves this issue by providing a centralized configuration point, the APIC controller, while still maintaining individual control plane capabilities on each node in the fabric. The controller exposes the entire network as a hierarchy of objects in a tree. It describes network properties related to workloads as logical properties instead of physical properties. So, to define connectivity requirements for workloads, you don’t have to express which physical interface a particular workload is on.

Furthermore, the fabric exposes the networking properties of all the switches so that they can all be configured and managed via Representational State Transfer (REST) calls as a single giant switch/router. The APIC REST API accepts and returns HTTP or HTTPS messages that contain JSON or XML documents. Orchestration tools can easily program the network infrastructure by using REST calls. (Chapter 4, “Operational Model,” illustrates this new model and how to automate configurations with REST calls and scripting.)

Multi-tenancy is conveyed in the management information model by expressing all configurations of bridge domains, VRF contexts, and application network profile as children of an object of type fvTenant. The segmentation on the network transport is guaranteed by the use of different VXLAN VNIDs.

Insertion of firewall and load balancers is also automated to simplify the creation of virtual containers comprising physical or virtual firewall and load balancing services. (Chapter 8, “Service Insertion with ACI,” illustrates in more detail the modeling of services and how they are added to the fabric.)

3. Amazon Web Services Model | Next Section Previous Section

There are currently no related articles. Please check back later.