Skip to end of metadata
Go to start of metadata

Description

Describes the components comprising a Virtual Listener in an MCP 2.0 data center location. (VIP, Virtual Listener, Pool, Node, Health Monitor, Persistence Profile, SSL Offload, iRule)


Content / Solution:

Overview of VIP Functionality

A Virtual IP address (commonly referred to as a VIP) refers to an IP address that is configured to accept network traffic arriving to it and redirect that traffic to different IP addresses within a "pool" of IP addresses that have been configured to accept the traffic based on certain rules. VIPs are often used for connection redundancy; a VIP address may still be available if a server fails because an alternative server replies to connection requests. A load-balanced VIP is a VIP where traffic is distributed among a group of servers.  A VIP is sometimes referred to as a reverse proxy (a reverse proxy dispatches inbound network traffic to a set of servers, presenting a single interface to the caller). In addition to redundancy, VIP functionality can be used for port translation - they can answer incoming traffic on a given port, but translate the traffic to a separate port as it is sent to the destination IP address 

What is a Virtual Listener?

In MCP 2.0,  Virtual Listener is the term used for a VIP. A Virtual Listener can be set up to answer to one of the following:

  • Public IPv4 address on a Network Domain - In this case, the Virtual Listener listens to an IPv4 address exposed on the Public Internet. This option is useful for managing traffic coming from the public Internet. However, unlike MCP 1.0, Public VIP addresses are also accessible from servers within the Network Domain
  • "Private" IPv4 address - In this case, the Virtual Listener listens to an IPv4 address that is not associated with the ranges of any VLAN on the Network Domain. Since these IP addresses are only routable inside the Network Domain, they can't be used for traffic coming from the public Internet but instead, are useful for managing traffic between VLANs and/or traffic coming from a CPNC (Cloud Private Network Connection). 

For MCP 2.0, a VIP is configured in the context of a particular Network Domain and is restricted to Advanced Network Domains. A VIP is comprised of a number of component resources, as shown in the diagram below:

The top-level component which brings VIP functionality together in MCP 2.0 is the Virtual Listener. The Virtual Listener declares the public or private IPv4 address (the listener address) through which the VIP routes traffic and optionally a port to limit the scope of the traffic. Traffic is not processed by a VIP unless the Virtual Listener is enabled.

The Virtual Listener can route traffic to two Pools:

  • Pool: this is the primary handler of traffic for the Virtual Listener. 
  • Client Clone Pool: a Client Clone Pool can optionally be added to receive a copy of the incoming traffic to the Virtual Listener for alternate processing. The most common use case for this function is to direct copies of the traffic for network monitoring purposes such as intrusion detection. 

The pool of IP addresses is often made up of addresses corresponding to a Cloud Server NIC, but the functionality is supported for almost any IP address routable within the Network Domain. 

For a detailed breakdown of the full set of configurable properties on a Virtual Listener, please refer to:

For more details on Virtual Listener management, please see:


IPv4 Virtual Listeners with IPv6 Pools are not reachable from within the Network Domain

 If the Virtual Listener is configured with an IPv4 address and a pool of IPv6 nodes, the Virtual Listener IPv4 address will not be reachable from VLANs within the same Network Domain. Other configurations do not have this limitation.

What is a Pool?

A Pool is a logical set of IP addresses (known in network parlance as "real network interfaces")  to which traffic can be routed. Each IP address is represented in the Pool as a Pool Member that is a Node. 

Traffic is routed to Pool Members by a combination of the Load Balancing Method and the Action on Service Down option.

The Slow Ramp Time limits the amount of traffic that is sent to a newly enabled Pool Member for the specified number of seconds.

Up to two Health Monitors may be set to observe and react to the health of the Pool Members. Note that Health Monitors can only be used if the Pool Members are set to use specific port numbers; it is not compatible to have Health Monitors on a Pool that has any Pool Members set to the "Any Port" option. 

For detailed information on Pool properties, creation and management see: 

What is a Pool Member?

Each Pool Member is the link between a Node (the IP address to a Service) on the accessible network and a specific Pool. The same Node can be used for multiple Pool Members within the same Pool or on different Pools.

As well as the Node it points to, the Pool Member a port property and its enablement status.  

It is possible to add a Node as a Pool Member to a Pool with "Any Port", however in the majority of cases, the expectation is that each Pool Member will have a specific port setting. Please see "What is a Pool?" above for an important note regarding the relationship between Health Monitors and Pool Member port settings.

The status of a Pool Member can have one of three settings:

  1. Enabled - Permits traffic.
  2. Disabled - The underlying Node continues to process persistent and active connections. It can accept new connections only if the connections belong to an existing persistent session.
  3. Forced Offline - The underlying Node allows existing connections to time out, but no new connections are allowed.

For further details on Pool Member properties, creation and management see: 

What is a Node?

A Node represents the IP address endpoint to which traffic can be directed in order to provide a real network interface for a Virtual Listener (or Virtual Listeners). A node can be any private IPv4 or IPv6 address within the Network Domain and can be "re-used" across multiple different pools. Note the node does not have to be associated with the NIC of a Cloud Server - clients with CPNC connections can define nodes that are routed across the CPNC connection so long as their firewall rules allow the traffic.

For detailed information about Nodes, their properties, creation, and management see: 

What is a Health Monitor?

Health Monitors are object availability checks used by a load balancer to determine the status of compute resources in a load-balanced configuration. They can be applied to individual Nodes or to Pools. As such each Health Monitor is defined as being Node Compatible and/or Pool Compatible. CloudControl provides a set of pre-defined health monitors which can be applied to nodes and pools.

For detailed information about Health Monitors, please refer to:

What is a Persistence Profile?

A Persistence Profile provides a method for ensuring that traffic from a client is sent to the same server in a pool based on an attribute of the connection. A Fallback Persistence Profile is used when the primary persistence profile fails.  CloudControl provides a set of pre-defined persistence profiles.

For detailed information about Persistence Profiles, please refer to:

What is SSL Offload?

Traditionally, accepting SSL (Secure Sockets Layer) connections using the HTTPS protocol requires installing the necessary SSL certificates and keys on a web server. This allows the webserver to handle the HTTPS requests (and more specifically, the SSL negotiation to start the connection) by decrypting incoming traffic and re-encrypting its outbound traffic. However, this approach is costly in processing power on the server.  When you are load balancing across multiple servers, it also involves installing and managing the certificate and keys across multiple servers.

SSL Offload involves placing the necessary certificates and keys on the MCP 2.0 Network Domain and "offloading" the work of converting external HTTPS traffic into normal HTTP traffic onto the Network Domain, with that conversion being handled at the Virtual Listener level. The traffic then passes unencrypted into the "pool" of nodes so the servers within the pool don’t bear the encryption load, and the certificate and keys can be managed centrally on the Virtual Listener.

For detailed information about SSL Offload, please refer to:

What is Port Translation?

Port translation allows you to accept traffic on the Virtual Listener on one port, then redirect to the pool of nodes on a different port. Such translation is often done for security purposes but has other purposes depending on the scenario.

For an overview of how to set up a Virtual Listener to accomplish this, please refer to:

What is an iRule?

An iRule is a "script" which allows a Virtual Listener to apply custom processing to the traffic it is handling. CloudControl provides a set of pre-defined iRules which can be applied to a Virtual Listener.

For detailed information about iRules, please refer to: