Example 1

Let’s take an example of an infrastructure comprising two load balanced web servers that deliver a web application to the end user. The web application is connected to a database server in the back end. The access to the database server goes down, but the web application servers remain in operation. The users will be trying to use the web application and will be receiving errors.

The solution is to use Monitor End Point.

• The example shows two web servers, 10.0.0.20 and 10.0.0.21, together with a third web server 10.0.0.22. The 10.0.0.22 server has been placed in a Standby mode.
• The two active web servers have been configured with a Monitoring End Point value of 10.0.0.111:4033 which is the database server connection IP Address and Port.
• In the event that the database server connection was to drop, the two active servers will be placed into an Offline mode, and the Standby server will go online, serving a web page that may inform the customer that the systems are under maintenance.

Example 2

Another example of Monitor End Point usage is when you are load balancing UDP protocol servers, such as Always-On-VPN. As you may know, UDP ports are not reliably monitored, and so there arises a need to monitor a TCP port.

Using Monitor End Point allows us to do just that. The main port being used by the Always-on-VPN servers will be 53/UDP, but you will monitor, say, 8433/TCP. In such a case, you just need to enter the port value in the Monitor End Point field.

Gateway mode allows you to route all traffic through the ADC, allowing the Real Servers to be routed via the ADC to other networks via the ADC virtual services or hardware interfaces. Using the device as a gateway device for Real Servers is ideal when running in multi-interface mode.
Load balancing persistence policies are also restricted to Least Connections, Shared IP List Based, Round Robin and IP List Based.

This method requires that the Real Server sets its default gateway to the ADC’s local interface address (eth0, eth1, etc.). Please refer to the Real Server Changes section in the Administration Guide.

Please note that Gateway mode does not support failover in a cluster environment.

You can choose to use Reverse Proxy (default method), or use Gateway or DSR mode. Setting can be found in the Advanced tab of the Real Servers section when defining a Virtual Service.

If this is needed you can achieve this by using the setting in the Real Server’s Advanced tab. See image below.

The one condition here is that you will need to bring the Real Server online manually.

We need to redirect this Virtual Service to a Real Server on port 80. In other words, Port 443 >>> Port 80.

In the example above, we can see this done on the ADC. The Virtual Service ingress port is 443, while the Real Server it is directed to is Port 80. You could also redirect to different ports if there are more Real Servers.

The ID field highlighted in the image above is used for Cookie ID-based persistence when load balancing. It is also used to define each server’s IDs and then within flightPATH to direct traffic to servers based on the ID value.

The example image shows each server with a unique ID value. This is used to identify each server.

Below is an example flightPATH rule set that directs requests to the correct server based on the value within the PATH.

The flightPATH example above relates to traffic direction to server A101794. Two more flightPATH rules are defined for the remaining two servers, A101795 and A101796.

So let us suppose we are load balancing three servers.

• Server 1 is a hardware server with a Dual quad-core Xeon CPU, 128GB RAM, and 10 Gigabit NIC.
• Server 2 is a hardware server with a Single quad-core Xeon CPU, 32GB RAM, and quad Gigabit NICs bonded.
• Server 3 is a Virtual Machine with 4 vCPU, 16GB RAM, and a Gigabit NIC.

Server 1 is the most powerful and capable of handling the most traffic and processing. This is followed by Server 2 and, finally, Server 3.

In such a situation we would place the highest weighting on Server 1, with Server 2 following and Server 3 last with the lowest weighting. See the image below as an example. The actual figures will be different to the one in the image.

As long as the DNS configuration has been completed on the page, System > Networking, then you will be able to do this.

The problem arises when the server is part of a load-balanced pool, and the load-balancing service uses persistence to maintain stickiness. In such cases, taking a server offline will cause loss of service to any users that may be active on that server.

The solution to this is provided by the ADC by way of a Drain functionality.

When we look at the Real Servers we normally see the image below. As you can see the servers are indicating that they are all online as seen by the Activity field.

The Activity field is actually a menu that contains several options, one of which is Drain. see image below.

If you were to click Drain for the server you wish to service, it will be placed into Drain mode, and its Status indicator will change to Blue.

Drain mode ensures that no new connections are sent to the server.

The Drain behaviour is also affected by the Drain Behaviour setting within the Advanced tab of the Virtual Service (from v4.3 b1966 onward).

To do this is very easy:

• Navigate to, and click the Virtual Service under which you wish to increase (or decrease) the number of Real Servers.
• You will see the Real Servers in the lower section.

• Click on one of them.
• Click the Copy Server button.
• A new row will be created with the details of the server you clicked on.

• Edit the details as required.
• Click the Update button.
• Repeat as needed.

To delete a particular server, click on the server and click the Remove Server button.