Pool Sharing Across Virtual Services

Starting with release 17.1.6, Avi Vantage supports the sharing of a single pool across multiple virtual services. The feature supports use cases wherein the same back-end servers are being used by different virtual services, each virtual service having its own purpose and properties. This article explains the feature’s capabilities, its CLI interface, and lists use restrictions.

Overview

In the past, a pool could be used by only one virtual service at a time. Each pool was exclusively “owned” by exactly one virtual service. In addition, a virtual service could own several pools. A virtual service might refer to a given pool through multiple techniques:

• As the default pool defined for the VS
• Through policy-based content-switching, a VS might choose one of its pools
• Via DataScript, a VS might programmatically choose one of its pools

As of 17.1.6, a pool can be referenced by multiple virtual services. In accessing the shared pool, each VS can independently use any one of the multiple techniques listed above. As before, a virtual service may access multiple pools, some of them shared and others not. Virtual services sharing a pool need not be placed on the same SE group.

Summary: A virtual service can refer to any combination of shared and non-shared pools at any given time, utilizing multiple and different techniques.

Note: The current implementation supports sharing across simple pools only. Pool group sharing is planned for a future release.

Restrictions

Some of the following restrictions may be lifted in future releases.

• Pool sharing is supported only for HTTP/HTTPs virtual services.
• All virtual services sharing a pool need to be of the same application profile type.
• Cookie persistence is the only persistence method.
• Request queing, caching, compression and basic auth are not supported.
• Connection multiplexing is supported, but all virtual services sharing the pool must be optioned identically with regard to connection multiplexing.
• A pool group or pools that are part of a pool group cannot be shared.

Configuration and Reporting

Pool-related workflow is essentially the same as prior to the advent of pool sharing. The differences are:

1. Users enjoy an increased number of pool choices when configuring a virtual service.
2. There are more ways by which to extract pool-related information when querying for statistics.

Impact on the Avi UI User

Figure 1 illustrates the fact that pool sharing provides more choices when configuring a virtual service. In the past, pools already assigned to virtual services would not be offered as candidates for the algoApp-1 virtual service shown in the figure.

Figure 1. Additional pool choices in the VS editor

Now that a given pool may serve more than one virtual service, displays such as the one shown in Figure 2 change.

Figure 2. Pool displays now likely to shown multiple virtual services

The ability for a single virtual service to be associated with multiple pools is unchanged. Figure 3 illustrates such a VS.

Figure 3. Virtual Service display continues to show multiple pools

Impact on the Avi CLI User

Configuration of a shared pool is no different than before.

Reporting has been expanded, as illustrated by the below command line examples.

• Show stats for each server in the named pool, filtered by SE and virtual service.

  show pool <pool-name> server detail  filter <se-name> filter <vs-name>

• Show stats for all servers in the named pool for each visual service placed on the given SE.

  show pool <pool-name> server detail  filter <se-name>

• Aggregating across all SEs on which the named virtual service is placed, show stats for each server in the named pool.

  show pool <pool-name> server detail  filter  <vs-name>

• For all virtual services placed on the SE group, and aggregating across all SEs, show stats for each server in the named pool.

  show pool <pool-name> server detail

• Aggregating across all SEs on which the named virtual service is placed, show stats for the named pool.

  show pool <pool-name> detail  filter  <vs-name>

State of Virtual Services

When virtual services sharing the same pool are placed on multiple SEs, and each SE has different reachability to application servers in the back-end pool, the virtual service and the pool states reflect this. This is different from the state reported when a single virtual service is scaled out across Service Engines. One can check a pool’s operational capability with a show pool <shared-pool> summary command, which has percent_servers_up_enabled set to True. As an example, if 1 of the 2 SEs has no reachability to the back-end servers, then this would be 50%.

Virtual Service Placement

Unless specifically constrained, virtual services sharing the same pool can be placed on multiple Service Engines. If the virtual services are placed on multiple SEs in different SE groups (not to be confused with intra-SE-group scaleout), constraints such as max-connections are enforced on a per-SE-group of scaled-out SEs.

Virtual Service Events

Any operational events on the shared pool is reflected on all its virtual services’ contexts. However, when adding subsequent VSs (after the first VS is created and associated with a pool) to share the pool, the pool’s prior events will not be reflected on the subsequently added VSs. However, all future events will show up.

Metrics, Alerts and Health Score

Metrics, alerts and health score for the pool are an aggregate of the pool’s traffic/state across all virtual services. Service Engines do keep metrics information on a per-server, per-virtual-service basis. CLI commands/REST APIs can be used to get this information for troubleshooting purposes.

L4 and L7 Pool Sharing

Starting with Avi Vantage version 21.1.1, different types of virtual services can use the same pool for backend traffic.
The supported pool sharing matrix is as below:

• Multiple L4 virtual services can share the same pool

• L4 SSL and L7 virtual services can share the pool

• L4 SSL and L4 virtual services can share the pool

• L4, L4 SSL and L7 can share the same pool

With the pool sharing feature, you can:

• Avoid creating duplicate pools and hence preserve resources

• Apply persistence across virtual services

• Have less configuration, and therefore easy management

An example use case for pool sharing is client IP persistence shared between L4 and L7 virtual services.

Points to Note

• Syslog/DNS/SIP Application profiles do not support Pool sharing.

• With L4/L7 Pool sharing , only client IP persistence is supported. Other persistence types are specific to L7 and are not applicable when pool is shared between L4 and L7. Here is the snippet of error that is displayed when the persistence is changed to some other type -

• When client IP persistence is required and persistence to be shared between virtual services: The virtual services should be scaled out to the same SEs.
  If different virtual services are scaled out to different set of SEs, use override_application_profile for L4 service ports with a single virtual service .

The use_service_port/ Disable Port Translation is a pool-level property, not a virtual service property. Hence L4 and L7 virtual services sharing the same pool cannot have use_service_port for one virtual service and have it disabled for the other virtual service.

• L4 SL does not support use_service_port. So, if the use case is to disable port translation on pool level, then pool cannot be shared with an L4-SSL type virtual service

DSR scenario: Using pool sharing for DSR with TCP/UDP/HTTP type Health Monitors is not supported because the health monitors in DSR do loop back VIP verification on the server, not only on the actual server IP.

Refer to the Direct Server Return on Avi Vantage article for more information.
Ping health Monitor works with pool sharing in the DSR scenario.

Document Revision History

Date	Change Summary
11 August, 2021	Updted the Content for Pool Sharing Across Virtual Services