Cloud Docs Home > F5 Application Services Proxy Index

F5 Application Services Proxy

The F5 Application Services Proxy (ASP) is an application delivery controller (ADC) for container environments, serving East-West traffic. The ASP deploys on-demand to act as a proxy and load balancer for distributed applications running in containerized environments.

Important

The ASP functionality is environment-agnostic, but its implementation differs.

In Kubernetes environments, the ASP is a forward proxy. One ASP instance runs on each Node in the Cluster. You can attach an ASP instance to Kubernetes Services. In Kubernetes, all ASP configurations are global.

In Mesos Marathon, the ASP is a reverse proxy. You can use the ASP Controller for Marathon to deploy an ASP instance for an Application. You can use the Marathon ASP configuration labels to define global settings for the ASP, or use the override labels to configure the ASP on a per-Application basis.

Release Notes

Attributions

Attributions.md

Features

User Guides

Upgrade

Beginning with ASP v1.1.0, installing the Ephemeral Store is a required setup task. Because of the major differences in functionality from v1.0.0 to v1.1.0, the recommended upgrade path is as follows:

  • Remove the existing ASP from your environment;
  • Kill all running instances;
  • Deploy ASP v1.1.0 as a new application.

See the ephemeral store documentation for your environment for details.

Architecture

The ASP is a Node.js application that uses a built-in middleware framework to handle proxied traffic.

Important

ASP uses Node.js version 8.2.1

The ASP comprises four (4) basic components:

Table 6 ASP components
Config Manages ASP configurations.
Merges configuration inputs from static and dynamic sources.
Normalizes the configuration for the other components.
Proxy Manages virtual server configuration.
Creates a proxy in the routing infrastructure for each virtual server.
Routing Provides the framework for creating traffic services.
Invokes the middleware functions.
Uses feedback to determine how to handle data events and the transaction lifecycle.
Telemetry Sends transaction events and statistics to an analytics provider (such as Splunk).

Built-in Middleware

The ASP has a built-in Middleware stack that handles data events and transaction lifecycles. See Middleware Architecture and API Reference for detailed information.

Header Manipulator

The header manipulation module adds, removes, or modifies HTTP headers. It uses the same semantics as the Node.js setHeader, getHeader, and removeHeader methods.

Load Balancer

The load balancer module directs traffic to an available server, according to the configured load balancing algorithm. This module also collects load balancing-related statistics.

Connection Manager

The connection manager module tracks and manages server connections:

  • maps client-to-server connections;
  • conducts lookups for client-to-server and server-to-client connections;
  • reuses existing connections (when found) or creates new ones;
  • manages the connection lifetime;
  • closes server connections when the client closes the connection or when the inactivity timeout fires.

Forwarder

The forwarder module forwards data back and forth between client and server connections.

Telemetry

The telemetry component gathers global and transaction stats for tcp and http connections. By default, the telemetry component logs stats internally. You can also send stats to a backend system for reporting and analysis.

Supported backend systems:

Transaction Stats

The transaction stats (x-stats) module supports the collection of transactional stats used by the telemetry component.

Global Stats
  • splunk source: asp.global
  • splunk sourcetype: f5:asp:stats:json
  • facility: test-location
  • devicegroup: test-group
  • Frequency: periodic (can be controller via config)
Table 7 ASP global stats
Name Description
tot_requests Number of HTTP requests received from clients
clientside_tot_conns Number of TCP connections received from clients
clientside_bytes_in Number of bytes read from clients
clientside_bytes_out Number of bytes written to clients
serverside_tot_conns Number of TCP connections opened to servers
clientside_failed_conns Number of failed TCP connections from clients
serverside_failed_conns Number of failed TCP connections to servers
clientside_other_killed Number of connections killed by OOM killer
aggr_period Time interval for flushing aggregate statistics
HTTP Transaction Stats
  • splunk source: asp.http.transactions
  • splunk sourcetype: f5:asp:stats:json
  • facility: test-location (config can update this field)
  • devicegroup: test-group (config can update this field)
  • Frequency: per request
Table 8 ASP HTTP Transaction stats
Name Description
client_ip Client IP Address
client_port Client TCP Port
ttfb Time-to-first-byte; time (in milliseconds) between request receipt and start of response header write-out
ttlb Time-to-last-byte; time (in milliseconds) between request reciept and writing last byte of response body
response_status_code HTTP response code (e.g., 200)
http_version Client HTTP protocol version (e.g., “1.1”)
method_name HTTP method for the request (e.g., “POST”)
request_date Time (in milliseconds) request received
pool_member_name Server pool member ID (embeds the server name)
pool_member_ip Server pool member IP address
pool_member_port Server pool member TCP port
url HTTP request URL
user_agent Client HTTP user agent
app Application name
appComponent Application component
TCP Transaction Stats
  • splunk source: asp.tcp.transactions
  • splunk sourcetype: f5:asp:stats:json
  • facility: test-location (config can update this field)
  • devicegroup: test-group (config can update this field)
  • Frequency: per connection
Table 9 ASP TCP transaction stats
Name Description
client_ip Client IP Address
client_port Client TCP Port
client_error_code Client-side socket system error code (e.g., HPE_INVALID_EOF_STATE)
server_error_code Server-side socket system error code (e.g., ECONNREFUSED)
pool_member_name Server pool member ID (embeds the server name)
pool_member_ip Server pool member IP address
pool_member_port Server pool member TCP port
app Application name
appComponent Application component

Ephemeral Store

The ASP ephemeral store is a distributed, in-memory, secure, key-value store used to share data across ASP instances. The ephemeral store configuration parameters are part of the Global settings.

In Kubernetes environments, where the ASP is a client-side proxy, one (1) ASP instance runs on every node. All instances share the same set of global configurations. This means every ASP instance will send probes to every node in the cluster. You can use health sharding with the ephemeral store to reduce the number of redundant health probes. When you use health sharding, each instance has an assigned range of endpoints it sends health probes to. When an instance determines that an endpoint in its assigned range is unhealthy, it adds that information to the ephemeral store. All other ASP instances immediately have access to the endpoint’s health status without having to send their own probes.

Important

F5 recommends using health sharding to reduce the amount of redundant probes across the cluster in Kubernetes environments.

In Mesos Marathon, where the ASP is a server-side proxy, ASP instances run on a per-Application bases. You can configure the ASP settings globally, or customize the settings for individual Applications. For this reason, the health sharding required to avoid redundancy in Kubernetes environments isn’t needed in Marathon.

Event Handlers

Event handlers allow you to trigger additional actions in the ASP data path when specific events occur. The event handler configuration parameters are part of the Virtual Server settings.

When a specified event fires, the corresponding event handler(s) activate. Set up event handlers in groups as entries in a JSON array. Event handler groups activate in the order in which they appear in the array.

Learn more about ASP event handlers.

Table 10 ASP event handler configuration parameters
Parameter Type Required Default Description
http-request string Optional   Action(s) you want to occur when ASP receives request headers from the client.
http-response string Optional   Action(s) you want to occur when ASP receives response headers from the backend server.

Health Monitors

Use the health-checks configuration parameters to define health monitors for the endpoints associated with a particular Virtual Server. If an ASP health check determines that an endpoint is unhealthy, the ASP removes the endpoint from the load balancing pool until it’s marked as healthy again.

Health check types

The ASP can perform two (2) types of health checks: active and passive.

Active health checks probe endpoints at the defined interval.

  • If the response-status falls within the accepted range, the endpoint receives a health status of “healthy”.
  • If a probe doesn’t receive an acceptable response within the timeout period, the endpoint receives a health status of “unhealthy”.
  • The ASP removes unhealthy endpoints from the load balancing pool when it registers the number of unhealthy checks set for the down-count parameter.
  • The ASP returns the endpoint to the pool when it registers the number of healthy checks set for the up-count parameter.

Note

Active health checks only support HTTP probes.

You can set up zero (0) or more active health checks for each virtual server.

Passive health checks determine endpoint health by monitoring backend traffic. Endpoints marked as unhealthy due to a failed passive health check return to “healthy” status when the inactivity-timeout period expires.

Note

You can set up zero (0) or one (1) passive health check per virtual server.

The ASP ignores health checks in the “unknown” state when determining an endpoint’s overall health status. The default state “unhealthy” only applies to active health checks.

Learn more about ASP health monitors.