How to verify that NetScaler COOKIEINSERT persistent sessions are working?


Ever had issues with your Storefront load balancing setup not working after painstakingly setting up NetScaler load balancing?

Now, let’s discuss a few reasons why cookie based persistence are better (in some scenarios) compared to Source-IP based persistence.

In some circumstances, using persistence based on source IP address can overload your servers. All requests to a single Web site or application are routed through the single gateway to the NetScaler appliance, even though they are then redirected to multiple locations. In multiple proxy environments, client requests frequently have different source IP addresses even when they are sent from the same client, resulting in rapid multiplication of persistence sessions where a single session should be created. This issue is called the “Mega Proxy problem.” You can use HTTP cookie-based persistence instead of Source IP-based persistence to prevent this from happening.

If all incoming traffic comes from behind a Network Address Translation (NAT) device or proxy, the traffic appears to the NetScaler appliance to come from a single source IP address. This prevents Source IP persistence from functioning properly. Where this is the case, you must select a different persistence type.

HTTP Cookie Persistence

When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the HTTP headers of the initial client request. The cookie contains the IP address and port of the service selected by the load balancing algorithm. As with any HTTP connection, the client then includes that cookie with any subsequent requests.

When the NetScaler appliance detects the cookie, it forwards the request to the service IP and port in the cookie, maintaining persistence for the connection. You can use this type of persistence with virtual servers of type HTTP or HTTPS. This persistence type does not consume any appliance resources and therefore can accommodate an unlimited number of persistent clients.

Note: If the client’s Web browser is configured to refuse cookies, HTTP cookie-based persistence will not work. It might be advisable to configure a cookie check on the Web site, and warn clients that do not appear to be storing cookies properly that they will need to enable cookies for the Web site if they want to use it.

By default, the NetScaler appliance sets HTTP version 0 cookies for maximum compatibility with client browsers. (Only certain HTTP proxies understand version 1 cookies; most commonly used browsers do not.) You can configure the appliance to set HTTP version 1 cookies, for compliance with RFC2109. For HTTP version 0 cookies, the appliance inserts the cookie expiration date and time as an absolute Coordinated Universal Time (GMT). It calculates this value as the sum of the current GMT time on the appliance and the time-out value. For HTTP version 1 cookies, the appliance inserts a relative expiration time by setting the “Max-Age” attribute of the HTTP cookie. In this case, the client’s browser calculates the actual expiration time.

So some of the benefits of using cookie based persistence are

  • Easy to configure
  • Load balancer does all the work without involving the back end services (mostly a web server)
  • No connection table to maintain
  • Activity based – Time out is based on idle connection and not the total connection time
  • caters to most of the load balancing scenarios
  • if proxies are involved in the setup where source IPs are masked, this makes it an easy choice

Cons of Cookie based persistence

  • can throw off the load balancing where timeouts are set to 0 or when time outs are long lived
  • when Type 0 cookie is used, time of the cookie value is absolute(GMT time). When type 1 is used, relative time is used (local time)
  • hard to troubleshoot

Testing COOKIEINSERT persistence

Use Putty or some other SSH clients to login to the NetScaler.

sh lb vserver vservername

If you take a closer look at the snippet above, the letters in yellow shows that COOKIEINSERT persistence is turned ON with a time out value of 0 mins. This means that the cookies doesn’t have an expiry time set by the NetScaler appliance. The backup persistence is set to SourceIP with a time out value of 60mins. You can also see the cookie values at the bottom of the results staring with NSC_xxxxxxx

You will now need to get into Shell with an account that has permissions. To get to shell, type shell and hit enter

Now type the following

nsconmsg -i vservername -s ConLb=1 -d oldconmsg

In the snippet above, the highlighted text in yellow shows that persistence is set to Cookieinsert and the number of hits for each service. You will also get values such as response times, CPU and memory utilization.

VIP value shows the total number of hits to the vServer hits
Each service has a line starting with S (IP Address) and its status.
Hits (x, x/sec) shows the initial (method) hits to the service for a new connection.
P (x, x/sec) shows hits to the service that are served using a persistence cookie

Also, check the current persistent session via the commands below

sh persistentsessions
sh persistentsessions -summary

Advertisements

Storefront Load balancing using NetScaler


It’s been a while since I wrote on my blog so let’s get straight into the post without much mucking around. This time we will discuss how to go about setting up Storefront load balancing using NetScalers. This can be configured on a standalone NetScaler or a NetScaler pair in HA. The recommendation is obviously to get this setup on a HA NetScaler pair so that NetScaler outage wouldn’t result in Storefront also being unavailable.

My Storefront version is 3.11 and have a cluster with 2 Storefront servers. NetScaler version is 11.1 but the NS version shouldn’t matter much as the steps would be more or less the same for other NetScaler firmware versions – newer or older. (unless you are too far behind)

Pre-Requisites

To configure Storefront load balancing we need the following –

  • 2 or more Storefront servers
  • an IP address for the virtual server that hosts the LB configuration
  • SSL certificate that points to the intended load balanced URL of Storefront – the certificate can be a wild card or a named certificate

First Things First

Logon to your NetScaler and navigate to System — Settings — Configure Basic Features. Ensure that Load Balancing is selected, if not select it and click OK

1

NetScaler Configuration

Create Servers

Now, navigate to Traffic Management — Load Balancing — Servers. Click Add

2

Give the Storefront server a name and enter the IP address of the server. Ensure that “Enable after creating” is selected. Click Create

Add the second Storefront server following the above steps. If you have more than 2  servers, add all of them.

3

Create Monitors

New NetScaler version come with a built-in Storefront monitor so we are going to make use of it here. Go to Traffic Management –Load Balancing — Monitors and click Add

Here I am only going to create a single monitor to probe all my Storefront servers. You can choose to create multiple monitors depending upon the number of Storefront servers that you have. In my case, i will create just one.

Give a name to the monitor and select the type as STOREFRONT

5

Now select Special Parameters tab and provide the name of the Store that you have created in Storefront. Check the 2 entries – Storefront Account Service and Check Back End Services. 

4

Click on the Standard Parameters tab. Ensure that Secure is selected as below. Click Create

6

Create Service Groups

Go to Traffic Management –Load Balancing — Service Groups

Give a name to the service group and select the protocol as SSL. Check the entries below

  • State
  • Health Monitoring
  • AppFlow Logging (only if you have NetScaler MAS in your environment)

Click OK

7

Under Service Group Members, add the server entities that we created earlier. Once done, they will look like the below

8

Under Settings, type the Header as X-Forwarded-For

9

Under Monitors, bind the monitor that we created before

10

Under SSL Parameters, setup the settings as below

11

Under Ciphers, setup the ciphers based on your company security policy.

12

Once done, Service Group for Storefront should look like this

13

Now, it’s time to create the Virtual Server

Virtual Server

As mentioned in the pre-requisites section , we need an IP address for this. If the NetScalers are sitting in the DMZ, a DMZ IP address is required. In my case, NetScalers are hosted internally so i will use an internal unused IP address.

We will also need the SSL certificate here.

Go to Traffic Management –Load Balancing — Virtual Servers

Click Add

Give a Name to the virtual server and select the protocol as SSL

Specify the IP address under IP Address field and specify the port # as 443

14

Click More and specify the settings as below (note, that AppFlow logging only needs to be enabled if you have a NetScaler MAS setup or other monitoring solutions that could make use of AppFlow logs)

15

 

Under Services and Service Groups, click on Load Balancing Virtual Server ServiceGroup Binding

Click Add Binding and select the Service Group that you created in the previous step. Click OK

Once completed, the page should look like the below. Click Close and click Done

16

It’s time to attach the certificate. Go to Traffic Management — SSL — Manage Certificates / Keys / CSRs

17

 

Click on Upload button and upload your certificate file to NetScaler

Go to Traffic Management — SSL — Certificates — Server certificates

Under Certificate, click on Server Certificate and then Install

Give a certificate key-pair name and choose the certificate that was just uploaded in the previous step. Click Install

Now, go back to Traffic Management –Load Balancing — Virtual Servers

Select the Virtual server created for Storefront and click Edit. Under Certificates, select Server Certificate and then Click Add Binding

Under SSL Ciphers, select the ciphers that you would like to be in place. I am going with the default one. This is not the most secure for a production setup so go with something that’s secure enough for your organization.

Under SSL Parameters, configure the settings as below. Click OK

18

Under Method, Select LEASTRESPONSETIME for the Load Balancing Method. Configure a Backup LB Method, I choose LEAST CONNECTION

You can read more about the LB Methods here

19

Click OK

Under Persistence, select COOKIEINSERT for Persistence with a time-out value of 0. You can also read why I selected the timeout value of 0 here

Under Backup persistence, select SOURCEIP with a timeout of 60. Fill in the Netmask as in the picture

20

Click OK and then Done

We have now completed almost 90% of the config. There are a couple of things left so hold on tight.

The configuration so far will ensure that load balancing will be performed between the Storefront servers ( I know, i know I haven’t setup the DNS entries for the load balanced VIP)

If someone type in the http URL of LB Storefront in their browser, it will not go anywhere. It will show them the IIS page instead. So how do we ensure that the users are redirected to the correct Storefront page (https version) every single time? We will setup another virtual server on port 80 with a redirect URL configured.

Let’s do that now.

Under Traffic Management –Load Balancing — Virtual Servers, Click Add

Under Basic Settings, give the virtual server a Name and select protocol as HTTP

Specify the same IP address as for the Storefront LB VIP and provide 80 for the Port #

Click OK/Create

Under Persistence, select SOURCEIP with a timeout of 2 mins

21

Click OK

Under Protection, type in the correct HTTPS URL that you would want the users to be redirected to under Redirect URL field

22

Click OK. Then click Done

You will notice that the virtual server will be marked as down

23

DNS Changes

Now head over to the DNS server and open the DNS Console

Create an A record pointing to the Storefront LB name with the IP address configured on the vServer for LB configuration.

Storefront Changes

This is the last step, I promise. Head over to the Storefront servers and it’s time now to run some Powershell commands

Now, the monitors that we created earlier will be marked as Down if we didn’t perform this step prior to creating them on the NetScaler. That’s because the monitor created was based on HTTPS and by default, Storefront monitoring is done on HTTP

To change this to HTTPS. We need to configure the monitor service to use HTTPS instead. On all the StoreFront 3.0 servers perform the following steps.

Run PowerShell as an administrator.

Navigate to the Scripts (C:\Program Files\Citrix\Receiver StoreFront\Scripts) folder via the Powershell on the Storefront server,

Run ImportModules.ps1

24

Run the below command

 Get-DSServiceMonitorFeature

25

Now, type the below to setup the Storefront Monitor on HTTPS

Set-DSServiceMonitorFeature -ServiceURL https://localhost:443/StoreFrontMonitor

 

Repeat the above steps on all the Storefront servers.

Now, head back to the NetScaler and you can see that the monitor will be in GREEN and showing a status of UP

That’s all we need to do to setup Storefront load balancing using NetScalers.

 

 

 

 

XenApp & XenDesktop 7.x – Citrix Director Load Balancing using NetScaler


Here is a quick and easy way to load balance your Citrix Director instances in a XenApp or XenDesktop environment.

Below is my environment

  • Citrix Director servers ( Controller servers in most cases) – director-1 and director-2
  • A NetScaler HA pair ( you can do this on a stand alone NetScaler as well)

 

Monitors

Firstly, create a monitor for the Director services

Navigate to Traffic Management >Load Balancing >Monitors and click Add

mon1

Give it a name and select type as HTTP ( if there are no SSL certificates installed on the Director servers). Click on the Special Parameters tab and under the HTTP Type box, enter GET /Director/LogOn.aspx?cc=true

mon3

Before you click Create, ensure that it is enabled and Secure box is ticked if SSL certs are being used.

mon4

Click Create

Servers

  • Second step is to create Servers

Navigate to Traffic Management >Load Balancing >Servers and click Add

mon5

Add your Director servers here

mon6

Similarly, add the second Director servers as well

Service Groups

  • Now create the Service Group

Navigate to Traffic Management >Load Balancing >Service Groups and click Add

mon7

Give the Service Group a name and protocol is HTTP and click OK

mon8

Now Edit the service group that was just created and click on Service Group members and add the newly created services, director-1 and director-2

mon9

Once added, it will look like the below

mon10

 

Click Close. Click on the Monitors link as below and add the monitor that was created in Step 1

mon11

Once add the screen will look like the below. Click Close

mon12

The service group will look like the below once the above steps are completed.

mon13

Click Done

Responder Policy

A Responder policy needs to be created to redirect the users from the root of the IIS web server to the Director page.

Please note that Responder feature may need to be enabled first before you can use it.

Click on the + sign next to AppExpert and select Responder. Right click and choose Enable Feature. The yellow exclamation mark will disappear when you do that.

Once enabled, Navigate to AppExpert >Responder > Actions

mon14

Now think of a nice name to call the load balanced Director instance. you will need to add a DNS host entry later on for this name. the name that i have chosen is director

Give it a descriptive name and use the drop down for Type to select Redirect

Under Expressions, type the string here with the quotes as below

"http://director.domain.co.nz/Director"

mon15

Click Create

Time now to create the Responder policy. The one that we created earlier was a Responder action.

Give a descriptive name to the Responder policy and under the Action drop down menu, select the name of the action that was created in previous step. Under the Expressions field,  type

HTTP.REQ.URL.CONTAINS(“Director”).NOT

mon16

Click Create

Virtual Server for Load balancing

Reserve an IP address to use for the virtual server.

On the left, navigate to Traffic Management >Load Balancing >Virtual Servers and click Add on the right. Give it a name and select the Protocol as HTTP

Specify the IP address for virtual server and the port number as 80. Click OK.  Note that in production environments, use secure Director access by using an SSL certificate. For the purpose of demo, we are using an unsecure connection

mon17

On the page where it says, Services and Service Groups, click No Load Balancing Virtual Server ServiceGroup Binding

mon18.PNG

Add the service group that was created in earlier steps

Click Continue

On the right hand side under Advanced Settings, Click Persistence

Select SOURCE IP as the Persistence and change the timeout value to 245 ( the default time out value for Director is 245 mins). Leave the rest of the settings as defaults and Click OK

mon19

Now, move on to the right hand side again and select Policies

Select Responder as the policy and Type as Request and click Continue

mon20.

Select the redirect policy created earlier and click Bind

mon21

Click Done

Ensure that the virtual server is marked as UP in green.

DNS Config

Create a host A record in DNS for the name which in my case is director

Test the Director URL and ensure that it redirects you to the correct URL and also login and confirm that Director is usable.

That’s all you need to do to setup Director load balancing using NetScaler.