Load balancing is a feature that is implemented in most Citrix NetScaler environments. Load balancing allows you to load balance different backend servers with the same purpose, for example, a web shop. A large web shop requires more than one web server because of the heavy load from visiting users. With load balancing, Citrix NetScaler will load balance the traffic between the visiting servers and the several backend servers. Besides load balancing, Citrix NetScaler can also monitor the backend server if, for example, the web server responds with HTTP Error code 200.
In order to configure the load balancing service in Citrix NetScaler, you need the following:
Servers: This refers to the actually backend server that provides the information. In this case, it is an Apache web server.
The IP address and server name are
10.0.10.234forwebserver01and10.0.10.125forwebserver02.Service/service group: The service or service group is what provides the information to the user. A service is a particular server and a service group is a part of servers that provide the same information. Also, we bind a monitor to the service or service group. It checks the backend based on the configured monitor:
The service groups name is
LB_SG_WebServer.The members are
LB_SRV_WebServer01andLB_SRV_WebServer02.The used protocol is HTTP and the port is 80.
The configured monitor in this case is the HTTP monitor. This monitor checks of the
WebServerresponds with an HTTP 200 error.
Virtual server: The load balancing virtual server is the actual virtual server that will be used to connect to. So, the user connects to this virtual server. Citrix NetScaler connects to the selected backend server, which is configured in the service / service group, based on the configured persistence or load balancing method:
Virtual server name: The virtual server name is
LB_VS_WebServer. This virtual server name is only for your own information; choose a virtual server name that recognizes the service it's providing.VIP address: This is the listing address of the load balancing service. In this example, it's DNS record is:
https://www.abc.com. The DNS record was IP address:192.168.12.87.Protocol and port: This is the responding protocol and port that the services respond to. Here, they are SSL and port 443.
Services or service groups: Select the proper service or service group responding with the load balancing service. This is the backend service that will be load-balanced. In the example, this would be service group
LB_SG_WebServer.Load balancing method: This option defines the load balancing method. There are a lot of options to select here. In this example, least bandwidth is used.
Persistence: This option defines the persistence. This persistence will be useful if you want the user to connect for a certain period of time to a particular backend server. In this case, it would be
COOKIEINSERT.
Tip
Backup persistence
If the primary persistence can't be set, the backup persistence will be used, if configured. Use logical names for load balancing backend servers, services, service groups, and load balancing virtual servers. I prefer this so that it's always recognizable what the purpose of the item is. Some examples are LB_VS_ServiceName or LB_S_WebServer for a service, LB_SG_WebServers for service groups, and LB_SRV_ServerName for a backend server name.
So, in the default configuration, the user only has a web browser session with Citrix NetScaler, and Citrix NetScaler proxies the request to the backend server. Therefore, if the backend servers and Citrix NetScaler are in a demilitarized zone, the only firewall port from other networks should be the listen port of the load balancing virtual server.
Tip
When Citrix NetScaler is in the demilitarized zone, make sure that the MIP or SNIP has access to the backend. This is the source IP address that Citrix NetScaler uses to connect to the backend.
With active/active, you load balance at least two backend machines with the same functionality. To configure active/active load balancing, it's necessary to create services or service groups for all backend servers that will be used for load balancing. While configuring active/active with different weights, I recommend that you use services instead of service groups, because you need to adjust the weight per service. Configuring active/active load balancing requires at least two services or service groups. Adjusting the weight while configuring the load balancing will change the percentage of traffic that will be sent to the backend server. Services or service groups with higher values can handle more requests; services or service groups with lower values can handle fewer requests. Assigning weights to services or service groups allows the Citrix NetScaler appliance to determine how much traffic each load-balanced server can handle and, therefore, balance the load more effectively.
In order to use active/active load balancing, it's necessary to configure the right persistence based on the requirement. In the following table, you can find all the persistence types available in Citrix NetScaler. This table also shows which persistence type will be available for a certain protocol:
|
Persistence type |
HTTP |
HTTPS |
TCP |
UDP/IP |
SSL_Bridge |
SSL_TCP |
RTSP |
SIP_UDP |
|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Setting a SOURCEIP persistence type for the load balancing vserver LB_VS_WebServer through the command line can be done using this command:
set lb vserver LB_VS_WebServer -persistenceType SOURCEIP
In order to use the load balancing feature in a proper way, you should always select the right load balancing algorithms. Citrix NetScaler has a lot of built-in load balancing algorithms. These algorithms can be configured during the configuration of the load balancing virtual server and could be different from other load balancing virtual servers. The default load balancing algorithm is least connection. The different algorithms have been explained here:
Least connection: This is the default algorithm. The backend service with the fewest active connections is used.
Round robin: The first session will be connected to the service that is at the top of the list, the second session will be connected to the second service on the list, the third session will be connected to the third service, and so on. After the last service is connected, the connections will be started at the top of the list.
Least response time: The service that has the fastest response will be used.
URL hash: Citrix NetScaler creates a hash for every destination URL that is created for the first time. This hash will be cached. So, when the destination URL is contacted, Citrix NetScaler connects to the backend, connection is made to a URL for the first time, Citrix NetScaler creates a hash to that URL and caches it.
Domain hash: Citrix NetScaler creates a hash for every first connecting domain. This hash will be cached. So, frequent connections to the same domain will contact the same service. The hash will be fetched from the HTTP header or from the URL.
Destination IP hash: The destination IP hash will be created when a connection is made to an IP address for the first time. All traffic after the first connection will be forwarded to the same service.
Source IP hash: This is same hash configuration as the destination IP; it's just that in this method the Source IP will be used.
Source destination IP hash: Citrix NetScaler creates a hash based on the source and destination IP.
Call ID hash: This creates a hash based on the call ID in the SIP header. This method makes sure that an SIP session is directed to the same backend server.
Source IP source port hash: Citrix NetScaler creates a hash based on the source and source port.
Least bandwidth: Least bandwidth will contact the service that uses the least bandwidth usage.
Least packets: This method is based on the service with the fewest packets.
Custom load: This method allows a user to create custom weights.
Token: This method contacts the service based on a value from the configured expression.
LRTM: This method contacts the service based on the least response time of the services.
So, after you have chosen the correct persistence type and algorithm, you can build the load balancing virtual server.
Citrix NetScaler also supports active/passive load balancing. This basically means that you have an active load balancing virtual server and another load balancing virtual server that will be used for passive load balancing. So, when all the services or service groups on the primary load balancing virtual server stop running, Citrix NetScaler will automatically will contact the backup load balancing virtual server. This functionality is widely used in environments with two different data centers, where one data center is passive. When the backend servers in the active load balancing virtual servers come back online, they will be the primary backend servers again instead the backend servers.
Citrix StoreFront is the replacement of Citrix Web Interface, which will end on June 30, 2018, if you have the software maintenance or subscription advantage. Otherwise, the end of life would be August 24, 2016. Besides, Citrix StoreFront allows you to work with the full-blown Citrix Receiver instead of only Receiver for Web. In order to load balance StoreFront, it is necessary that you install and configure Citrix StoreFront. To use the full-blown Citrix Receiver, it's necessary to configure Citrix StoreFront with an SSL certificate. This SSL certificate can be an internal certificate created by your own certificate authority, or it can be from a public certificate authority. When you are using your own certificate authority, for example, Microsoft, all clients will automatically trust the SSL certificate. Clients outside the Active Directory should install the root certificate to work with Citrix StoreFront and the full-blown Citrix Receiver.
In the following figure, you can find the most commonly used configuration for the load balancing of StoreFront:
Citrix NetScaler is a good load balancer for the Citrix StoreFront environment. It contains a monitor for checking whether the StoreFront store is running and fully functional. This monitor is way better than the regular HTTPS monitor, because Citrix NetScaler also verifies that StoreFront is healthy. A lot of other vendors / load balancers can't do this because they don't have the value that is needed. Also, make sure you use service groups instead of services. Because the StoreFront monitor isn't the default monitor, the first step in load balancing Citrix StoreFront is to create the monitor.
Go to Traffic Management | Load Balancing | Monitors, and click on Add. Select Type as STOREFRONT from the list, and go to the Special Parameters tab. Fill in the Store Name field, as shown in the following screenshot. The store name can be found in the StoreFront console under the Store menu. Also add the monitor name and click on Create, as shown here:
The monitor can also be created using a command-line interface. The command required would be as follows:
add lb monitor storefront_ssl STOREFRONT -storename myStore -storefrontacctservice YES -secure YES
Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
The best way to create a load balancing environment is by starting from the bottom and going towards the top in the menu structure. In this way, you can create a decent name instead of the default names:
First, we need to add the backend servers that are running StoreFront to the server list.
The next step is to create a service group. This service group consists of the backend servers. Select the custom-made StoreFront monitor. This monitor will verify the StoreFront service even before the user connects to it. It's also possible to use the default monitor if you don't want any functionality checks. For troubleshooting or logging, it's very useful to have the client IP address. Because Citrix NetScaler operates as a load balancer, the source IP address to the backend servers will always be the SNIP. To have the client IP address as well, it's possible to insert the client IP into an HTTP header. This can be done while creating the service group. After you have added the backend servers, add the Settings menu on the right-hand side. Enable client IP and fill in the header box with X-Forwarded-For. Now, we are ready to create the load balancing virtual server.
Go to Virtual Servers and click on Add. Enter an IP address, a port, and a protocol. After this step, add the service group that you created in the preceding step. Depending on the configuration and the user access, we configure the proper protocol. If we also need support for the Citrix Receiver, we should use the SSL protocol because the Citrix Receiver requires a trusted communication. If this not necessary, the SSL certificate isn't required and we can use the HTTP protocol.
The regular deployments are SSL setups. After the members, protocol, IP address, and port are configured, we need to configure the persistence. This allows the user to stay connected to the same StoreFront server while working. The recommended settings are
COOKIEINSERTand a timeout value from0. The value 0 means that there is no expiry time. By configuring another timeout value, for example, 2 minutes, the user can connect to another StoreFront server. When this happens, the user needs to log in again, because there is no session available. As backup persistence, selectSOURCEIPwith the proper timeout. The timeout can't be zero and must be at least 2 minutes. When using the SSL protocol, we also need to add the certificate that is required for the load balancing virtual server.When using SSL as the protocol, you should also consider disabling SSLv3 and enabling TLS 1.1 and TLS 1.2 on the load balancing virtual server. Since NetScaler 10.5 build 57.7 and higher, Citrix NetScaler supports TLS 1.1 and TLS 1.2 on the virtual appliance (VPX) as well. SSLv3 is an non-secure SSL protocol and should be disabled. This SSLv3 vulnerability is called POODLE (https://en.wikipedia.org/wiki/POODLE).
After creating the load balancing virtual server, the DNS record for the StoreFront base URL should be changed to the virtual IP from the load balancing virtual server.
Tip
When using Citrix StoreFront through SSL, configure the base URL and the load balancing virtual server, but bind the backend servers through HTTP. When you are using this deployment, Citrix NetScaler will be used as SSL offload functionality. However, please be aware that the credentials will be sent in plain text between Citrix NetScaler and the backend environment.
If you get the Cannot complete your request warning after connecting, there could be many reasons for it. For some explanations and fixes, refer to http://support.citrix.com/article/CTX133904.