Tenants (fvTenant) are top-level objects that identify and separate administrative control, network/failure domains, and application policies. A tenant’s sublevel objects can be grouped into two basic categories: tenant networking and tenant policy.
The decision on how to leverage tenancy models is driven by a number of factors:
1. Overall IT operations and support models in your organization to manage application, networking, servers, security, and so on
2. Separation of environments from a software development lifecycle perspective: development, quality assurance, and production
3. Separation of duties by domain owner, such as web, app, and database owners
4. Fault domain size and scope to limit the impact of failures, such as different business units
Tenant networking is used to define networking policies and will be applied to the underlying hardware in a transparent way thanks to the layer of abstraction provided by ACI using VRFs, bridge domains, and subnets.
Tenant policies are where applications are defined. An application could consist of a combination of physical servers or virtual machines, which we will call servers from now on.
For example, a website could use a three-tier application model, composed of web servers, application servers, and database servers. When users browse the website, they might actually be communicating with a virtual IP address on a load balancer that, in turn, can distribute the web request to a number of different web servers. The web servers, in turn, communicate with core applications that can be divided among several application servers for load balancing or high-availability purposes. Finally, the application servers communicate with the database, which could also be a cluster of servers.
Each server is referred to as an endpoint in the ACI. Endpoints are classified in the ACI to apply policies. You need to create endpoint groups for endpoints that share the same types of policies, such as with whom they are going to communicate and what types of communication or restrictions are required. Therefore, an application can be formed by several endpoint groups, and they are grouped in an application profile.
Although the tenant networking and the tenant policies are defined separately, the networking policies used by an application are defined with a relationship between the endpoint groups and the bridge domain.
The following three tenants are preconfigured in the ACI system by default:
1. Common: This special tenant has unique abilities to easily share its resources with other tenants, with the purpose of providing “common” services to other tenants in the ACI fabric. Global reuse is a core principle in the common tenant. Some examples of common services are
Shared L3 out
Shared VRFs
Shared bridge domains
DNS
DHCP
Active directory
2. Infra: This infrastructure tenant is used for all internal fabric communications, such as tunnels and policy deployment. This includes switch-to-switch (leaf, spine, Application Virtual Switch) and switch-to-Application Policy Infrastructure Controller communications. The infra tenant does not get exposed to the user space (tenants), and it has its own private network space (VRF) and bridge domains. Fabric discovery, image management, and DHCP for fabric functions are all handled within this tenant.
3. Mgmt: The management tenant provides a convenient means to configure access policies for fabric nodes. While fabric nodes are accessible and configurable through the APIC, they can also be accessed directly using in-band and out-of-band connections. In-band and out-of-band policies are configured under the mgmt tenant:
