Configure load balancing

In a real-world scenario with a limited number of servers providing service to many clients, a server can become overloaded and degrade the performance of the server farm. Using load balancing algorithms, you can evenly distribute network traffic to avoid overloading any resource. The result is a better experience for end users in terms of improved performance and availability of your apps.

The load balancing module of the Citrix App Delivery and Security distributes client requests across multiple app servers, such as EC2 instances, FQDN/IP address-based servers, and Autoscale groups.

When the Citrix App Delivery and Security receives a client request, it selects a target server based on the specified rules or routes all traffic to the default server. It uses load balancing criteria to prevent bottlenecks by forwarding each client request to the server best suited to handle the request when it arrives.

Specifying the maximum number of requests per server ensures that a server is not overloaded. You can also specify a URL to redirect traffic, to avoid dropping requests if a server is not reachable.

Health checks monitor the health of servers by sending probes to the back-end app servers. If the server responds within the specified time interval, the state of the server is set to UP. That is, the server can accept traffic. If the server does not respond to the designated number of probes within the specified time period, the server is set to DOWN. No requests are forwarded to this server until its state changes to UP. Traffic is distributed only among healthy servers.

Prerequisites

  1. You have created an environment and a cloud access profile.
  2. You have specified the basic details, such as the name of the application, environment, services, and endpoints by navigating to Applications > New Application. For more information, see Deliver an application.

Before you begin

Decide which algorithm and stickiness you plan to use for your load balancer. The following algorithms and stickiness are supported.

Algorithm

Algorithm is the method used to direct the client request to the server. In the HASH methods, the Citrix App Delivery and Security extracts a predetermined portion of the request, creates a hash of the portion, and uses that value to select the server. The following methods are supported:

  • Round Robin: Requests are distributed across the servers sequentially regardless of the load.
  • Least Connection: Request is assigned to the server with the least number of active connections depending on the relative compute capacity of the server. This method is the most used method and is also the default method.
  • Least Response Time: Request is assigned to the server with the lowest average response time.
  • SOURCEIPHASH - Create a hash of the source IP address.
  • DOMAINHASH - Create a hash of the domain name, or part of the domain name if it exceeds 80 characters, in the request. The domain name is taken from either the URL or the host header. If the domain name appears in both, the URL is preferred. If the request does not contain a domain name, the algorithm defaults to LEASTCONNECTION.
  • URLHASH: Create a hash of the request URL, or part of the URL if it exceeds 80 characters.

Stickiness

The Citrix App Delivery and Security uses the configured load balancing method for the initial selection of a server. It forwards all subsequent requests from the same client to that same server during a session. This setting is especially helpful in shopping cart and banking transactions. However, a server can become overloaded if it has too many open sessions or a specific session requires more resources.

The following stickiness types are supported:

  • NONE - No stickiness is configured. Successive requests from the same client are directed to any server. This option is the preferred one for stateless applications. This value is the default value.
  • SESSION COOKIE - The Citrix App Delivery and Security inserts an HTTP cookie that is used to direct all requests to the same server during a session. This cookie uniquely identifies the session when a client accesses the application for the first time. It then refers to the cookie for subsequent requests from the same client. The HTTP cookie inserted by the service is a temporary cookie and is erased when the browser is closed. This type of stickiness is typically selected when the stickiness must be valid only until the browser is open.
  • STICKY COOKIE - The Citrix App Delivery and Security inserts an HTTP cookie that is valid for the configured duration. Default duration = 2 mins.
  • SOURCEIP - Connections from the same IP address belong to the same stickiness session. That is, all requests from the same source IP address are forwarded to the same server for the configured duration. Default duration = 2 mins.
  • SSLSESSION - Connections with the same SSL session ID belong to the same stickiness session. The back-end app server assigns an SSL session ID to each session. All requests with the same SSL session ID are forwarded to the same server for the duration configured. For example, use SSL session ID if you cannot use source IP stickiness because the device is behind a NAT gateway. As a result, the requests might not have the same source IP address. Default timeout= 2 mins.

Create a load balancer

A default load balancer is available. Bind a service to the load balancer and optionally configure content rules and security protection features. Deliver the application.

Follow these steps to create a load balancer.

  1. Navigate to Applications > New Application.
  2. Specify basic details, such as name of the application, environment, services, and endpoints. For more information, see Deliver an application.
  3. Click Add Load Balancer.
  4. In the Select Load Balancer page, click Create Load Balancer.
  5. Specify values for the following parameters. For more information about algorithms, see #Algorithm. For more information about stickiness, see #Stickiness.
    • Name* - Name for the load balancer.
    • Algorithm*
    • Stickiness*
    • Stickiness Timeout - Time period, in minutes, for which stickiness is in effect. After the timeout expires, the request is treated as a new request and can be directed to any server depending on the configured load balancing algorithm.
    • Max Connections to Server - Maximum number of permissible simultaneous open connections per server. This number ensures that the server is not overloaded.
    • Redirect URL - If the server is DOWN or not reachable due to any reason, the requests are dropped. To avoid such a situation, you can specify a URL to redirect traffic to, if none of the servers are reachable. For example, the redirect might be to a page that simply states that “The servers are not reachable. Try after some time.” * Indicates a required parameter

      Create a load balancer

  6. (Optional) Click Add Health Check.
    1. Specify values for the following parameters:
      • Name* - Name for the health check.
      • Protocol - Protocol of the health check. and port number used by the server in your EC2 instance.
      • Port - Destination port where the health checks are sent. If this parameter is not configured, the health checks are sent to the same port as regular traffic.
      • Interval - Time interval, in seconds, between two successive health checks to the server. Must be greater than the “Response Timeout” value.
      • Response Timeout - The time, in seconds, within which a response must be received from the server. Must be less than the “Interval” value.
      • Unhealthy Time Interval - Time interval, in seconds, between two successive health checks to an unhealthy server.
      • Failed Check Count- Number of failed health checks after which a server is marked unhealthy.
      • Request URL Path* - HTTP request URL path to which health checks are sent. Applicable only to HTTP/HTTPS health checks. A “/” specifies that the monitor checks the server. To check a specific endpoint, specify the URL for the endpoint. For example, if the server is “example.com” then a specific endpoint might be “/example.com/comments.html”.
      • Request Header - HTTP header to be sent in the health checks. Applicable only to HTTP/HTTPS health checks.
      • Response Type* - Expected HTTP response code or text to be present in the HTTP response body to mark the server as healthy. Applicable only to HTTP/HTTPS health checks. * Indicates a required parameter

        Add health check

    2. Click Add Health Check. The configured health checks for the load balancer are displayed in a tabular format.
  7. Click Create.
  8. Select a load balancer and click Add.

You have completed the steps to create a load balancer. The load balancers are displayed in a tabular format.

Bind a service to the load balancer

  1. In Services, select a service to bind to the load balancer.

    Bind a service to a load balancer

  2. Select from one of the following options:

    • Click Next to configure content rules and security protection.
    • Click Deploy to start application delivery.
Configure load balancing