In recent years, Cisco has been actively promoting a new architecture for building data transmission networks in data centers — Application Centric Infrastructure (ACI). Some are already familiar with it. Others have even implemented it in their enterprises, including in Russia. However, for most IT specialists and IT leaders, ACI remains either an unclear acronym or merely a discussion about the future.
In this article, we will try to bring that future closer. We will discuss the main architectural components of ACI and illustrate its practical application. Additionally, we will soon organize a visual demonstration of ACI in action, which every interested IT specialist can sign up for.
You can learn more about the new network architecture in Saint Petersburg in May 2019. All details – at . Sign up!
Background
The traditional and most popular network architecture model is the three-tier hierarchical model: core -> distribution (aggregation) -> access. For many years, this model has been the standard, and manufacturers have produced various network devices that match its functionality.
In the past, when information technology was a necessary (and, to be honest, not always welcome) adjunct to business, this model was convenient, quite static, and reliable. However, now that IT is one of the drivers of business development, and in many cases is business itself, the static nature of this model has started to cause significant issues.
Modern business generates a large number of complex requirements for network infrastructure. The success of the business directly depends on the realization timelines of these requirements. Delays in such conditions are unacceptable, and the classic network model often fails to meet all business needs in a timely manner.
For example, the emergence of a new complex business application implies that network administrators must perform a large number of similar routine operations across various network devices at different levels. Not only does this consume a lot of time, but it also increases the risk of making a mistake that could lead to serious downtime of IT services and, as a result, financial losses.
The root of the problem is not the deadlines or the complexity of the requirements themselves. The issue is that these requirements need to be 'translated' from the language of business applications to the language of network infrastructure. As is well-known, any translation always involves a partial loss of meaning. When the application owner speaks about the logic of their application, the network administrator understands a set of VLANs and access lists across dozens of devices that need to be maintained, updated, and documented.
The accumulated experience and constant communication with clients allowed Cisco to design and implement new principles for building data transmission networks in data centers that respond to modern trends and are primarily based on the logic of business applications. Hence the name — Application Centric Infrastructure.
ACI Architecture.
The ACI architecture is best viewed not from a physical standpoint, but from a logical one. It is based on a model of automated policies, the objects of which can be divided at the top level into the following components:
- Network based on Nexus switches.
- APIC Controller Cluster;
- Application Profiles;
Let's examine each level in more detail – moving from simple to complex.
Network based on Nexus switches
The network in an ACI fabric resembles a traditional hierarchical model but is built significantly easier. The Leaf-Spine model is used to organize the network, which has become the standard approach for implementing next-generation networks. This model consists of two levels: Spine and Leaf, respectively.
The Spine level is solely responsible for performance. The total performance of the Spine switches equals the performance of the entire fabric, so at this level, switches with 40G ports or higher should be used.
Spine switches connect with all next-level switches: Leaf switches, to which end hosts are connected. The main role of Leaf switches is port capacity.
Thus, scaling issues are easily addressed: if we need to increase the throughput of the fabric, we add Spine switches, and if we need to increase port capacity, we add Leaf switches.
For both levels, Cisco Nexus 9000 series switches are used, which are the primary tool for building data center networks regardless of their architecture. Nexus 9300 or Nexus 9500 switches are used for the Spine level, and only Nexus 9300 for the Leaf level.
The model range of Nexus switches used in the ACI fabric is shown in the figure below.
Cluster of APIC controllers (Application Policy Infrastructure Controller)
APIC controllers are specialized physical servers, while a cluster can include one physical APIC controller and two virtual ones for small deployments.
APIC controllers perform management and monitoring functions. Importantly, controllers never participate in data transmission, meaning that even if all controllers in the cluster fail, the stability of the network operation will not be affected at all. It should also be noted that through APICs, the administrator manages all physical and logical resources of the fabric, and to make any changes, it is no longer necessary to connect to any specific device, as ACI uses a single point of control.
Now let's move on to one of the main components of ACI – application profiles.
Application Network Profile is the logical foundation of ACI. It is the application profiles that define the interaction policies among all network segments and describe the network segments themselves. ANP allows for abstraction from the physical layer and essentially represents how to organize interaction among different network segments from the application's perspective.
An application profile consists of connection groups (End-point groups – EPG). A connection group is a logical group of hosts (virtual machines, physical servers, containers, etc.) that are in the same security segment (not in the network, but in terms of security). The end hosts that belong to a particular EPG can be defined by a large number of criteria. The following are usually used:
- Physical port
- Logical port (port group on a virtual switch)
- VLAN ID or VXLAN
- IP address or IP subnet
- Server attributes (name, location, OS version, etc.)
To facilitate interaction between different EPGs, there is an entity called contracts. A contract defines the relationships between different EPGs. In other words, a contract specifies what service one EPG provides to another EPG. For example, we create a contract that allows traffic to flow over the HTTPS protocol. Then we connect this contract to, for instance, EPG Web (the web server group) and EPG App (the application server group), enabling these two endpoint groups to exchange traffic over the HTTPS protocol.
The illustration below describes an example of configuring the communication of various EPGs through contracts within a single ANP.
There can be any number of application profiles within an ACI fabric. Moreover, contracts are not tied to a specific application profile; they can (and should) be used to connect EPGs across different ANPs.
Essentially, each application that requires a network in one form or another is described by its own profile. For example, the diagram above shows the standard architecture of a three-tier application, consisting of an arbitrary number of external access servers (Web), application servers (App), and database servers (DB), along with the rules governing their interaction. In traditional network infrastructure, this would be a set of rules written on various devices within the infrastructure. In ACI architecture, we describe these rules within a single application profile. ACI simplifies the creation of a large number of configurations on different devices by grouping them all into a single profile.
The illustration below shows a more practical example. The application profile of Microsoft Exchange, consisting of several EPGs and contracts.
Centralized management, automation, and monitoring are among the key advantages of ACI. The ACI fabric frees administrators from the tedious task of creating a large number of rules across various switches, routers, and firewalls (while the classic manual configuration method is permitted and can be used). Application profiles and other ACI object settings are automatically applied throughout the ACI fabric. Even when physically switching servers to different ports of the fabric switches, there is no need to duplicate settings from old switches to new ones or clean up unnecessary rules. Based on the criteria of host membership in EPG, the fabric will automatically perform these settings and clean up unused rules automatically.
Integrated security policies in ACI are implemented on a whitelist basis, meaning that anything explicitly not allowed is denied by default. Together with the automatic updating of network equipment configurations (removing 'forgotten' unused rules and permissions), this approach significantly enhances the overall security level of the network and narrows the potential attack surface.
ACI allows for the organization of network interactions not only for virtual machines and containers but also for physical servers, hardware security appliances, and network equipment from third-party vendors, making ACI a unique solution at this time.
Cisco's new approach to building a data transfer network based on application logic encompasses not only automation, security, and centralized management but also a modern horizontally scalable network that meets all the requirements of contemporary business.
Implementing a network infrastructure based on ACI allows all departments within the enterprise to communicate in a unified language. The administrator is guided solely by the logic of the application, which defines the needed rules and connections. Similarly, the application logic guides owners and developers of the application, the information security service, economists, and business owners.
In this way, Cisco practically implements the concept of the next-generation data center network. Want to see it for yourself? Come to the demo. Application Centric Infrastructure in Saint Petersburg and start working with the future data center network right now.
You can register for the event .
Source: habr.com
