Service Manager Mode via REST API with ACI on Write Access VMware Cloud

Overview

Avi Vantage integrates with ACI’s service manager mode via REST APIs to provide complete automation and flexibility to insert L4-L7 services with ease in an ACI fabric. To know more about ACI Integration refer to Service Manager Mode with REST API.

In this integration mode, Avi Service Engine can be deployed in one-arm mode or two-arm mode.

Avi Vantage deployment in the one-arm mode is recommended for the north-south traffic where client traffic is coming from outside of ACI fabric using L3Out. This can be the case where client traffic is coming from branch networks.

Avi Vantage deployment in the two-arm mode is recommended for east-west (server-to-server) traffic load balancing in a DC hosted on VMware infrastructure.

Note: The service manager mode via REST API integration is only supported for the Avi Vantage hosted on VMware infrastructure with write access. For more information on VMware write access deployment please refer to Deploying in Write Access Mode.

Avi Service Engine in One-Arm Mode with Source NAT

Local Network Topology

The following image represents the logical view of one-arm mode:

One Arm Mode

As shown, Avi Service Engine will be connected to a single port group. The clients are expected to come from outside the ACI fabric from the L3Out and access the virtual service hosted on Avi Service Engine.

The following image represents the logical network topology of the one-arm mode design for north-south traffic:

one arm mode NorthSouth Traffic

Logical Traffic Flow

The traffic flow for clients accessing virtual service web in comparison to those hosted on Avi Service Engines is as shown below:

  1. Clients → L3Out ACI fabric → External EPG
  2. Avi Service Engines → Contract with SG → App EPG
  3. APP EPG → ACI fabric → App VM

The return traffic will take the same path as that used by the App VMs to respond to the Service Engine’s NAT IP address. The Service Engines will send the return traffic back to the external EPG.

SE and Servers VMwareInfra ACI

Physical Traffic Flow

The physical traffic flow is as discussed below:

  1. Clients → L3Out on ACI fabric external EPG with service graph contact ) → Avi Service Engine

  2. Avi Service Engine with Source NAT and load balancing) → App VMs.

Physical Traffic Flow

Avi Service Engine in Two-Arm Mode with Source NAT

Local Network Topology

The following image represents the logical view of two-arm mode:

two arm mode logical

One interface will be connected to the client side port group and the other interface will be connected to the server side. In east-west design, the client side port group will be one of the port groups in 3-Tier application architecture which is trying to access the virtual service hosted on Avi Service Engines.

The logical network topology of two-arm mode for east-west traffic in which Avi Service Engines are hosted on VMware ESXi hosts and the Avi Controller is integrated with ACI is as shown below:

two arm mode EastWest Traffic

Logical Traffic Flow

The traffic flow for web VM accessing app virtual service hosted on Avi’s Service Engines is shown below:

  1. Web VM → ACI Fabric → Web Endpoint Groups (EPG)
  2. Web EPG → Contract with Service Graphs (SG) → Avi SE’s
  3. Avi SE’s → Contract with SG → APP EPG
  4. APP EPG → ACI Fabric → App VM

The return traffic will take the same path as used by the App VMs to respond to the Service Engines’s translated IP address. The Service Engines will send the return traffic back to the Web VM which initiated the request.

Avi SE and Servers VMwareInfra ACI

Physical Traffic Flow

The traffic flow for web VM, accessing app virtual service hosted on Avi’s Service Engines is shown below:

  1. Web VM → ACI fabric (with Service Graph Contact ) → Avi SE
  2. Avi SE (with Source NAT and load balancing) → App VMs

Physical Traffic Flow

Service Graph Considerations

Starting with release 17.2.10, Avi Vantage creates automated service graphs by default, as follows:

AviLayer2 Service Graph – Created automatically with L2 Adjacency connectors and can be used for two-arm mode deployments.

AviLayer3 Service Graph – Created automatically with L3 Adjacency connectors and can be used for one-arm mode deployments.

We recommend use of automated service graphs for one-arm or two-arm mode deployments. You can create manual service graphs if L4-L7 device like firewall is required with Avi Vantage load balancer in the service graph.

High Availability Considerations

Avi Vantage provides a couple of elastic high availability (HA) modes for data traffic resiliency. Both of these are scalable. Therefore, multiple Service Engines can be utilized for any given virtual service.

For critical applications, active/active HA is recommended. In the HA mode, the virtual service is placed on at least two Service Engines. This ensures that the traffic is not disrupted in case of a Service Engine failure.

For lower priority applications, n+m HA mode can also be considered. This ensures that there is at least “m” number of Service Engine capacity available as buffer for any SE failure.

To know more about Avi Vantage high availability features, refer to Overview of Avi Vantage High Availability.