This article contains the information needed to use NetScaler for load balancing.
This article provides guidance on how to deploy a StoreFront server group containing two or more StoreFront servers in all active load balanced configuration. The article provides details of how to configure a NetScaler appliance to load balance incoming requests from Citrix Receiver/Citrix Receiver for Web between all of the StoreFront nodes in the server group and how to configure the new Storefront Monitor for use with a NetScaler or third party load balancer.
For load balancing configuration examples, see the sections "Scenario 1" and "Scenario 2" below.
Consider the following options before purchasing a certificate from a commercial certificate authority or issuing one from your enterprise CA.
For details of email-based discovery configuration, see http://blogs.citrix.com/2013/04/01/configuring-email-based-account-discovery-for-citrix-receiver/ .
Note: When exporting the private key associated with the certificate is not feasible: Use two separate certificates: One on the NetScaler load balancing vServer and a different certificate on the StoreFront server group nodes. Both certificates must include Subject Alternative Names. Citrix does not recommend this unless you are using a FIPS compliant physical NetScaler appliance. This is the only viable option if using a FIPS NetScaler.
o Select the .cer certificate file on the NetScaler file system under /nsconfig/ssl/.
o Select the .key file containing the private key from the same location.
Create a DNS A and PTR record for your chosen shared FQDN. Clients within your network use this FQDN to access the StoreFront server group using the NetScaler load balancer.
Example - storefront.example.com resolves to the load balancing vServer virtual IP (VIP).
This scenario uses a modified StoreFront monitor using port 443.
1. Within your Service Group, select the Members option on the right hand side and add all of the StoreFront server nodes you defined previously in the Servers section.
2. Set the SSL port and give each node a unique server ID as they are added.
3. On the Monitors tab, select the StoreFront monitor you created earlier.
4. On the Certificates tab, bind the SSL certificate you imported earlier.
5. Bind the CA certificate used to sign the SSL certificate you imported earlier and any other CAs that might be part of the PKI chain of trust.
1. Log onto the NetScaler management GUI.
2. Select Traffic Management > Load Balancing > Virtual Servers > Add to create a new vServer.
3. Select the load balancing method for the vServer. Common choices for StoreFront load balancing are round robin or least connection.
4. Bind the Service Group you created earlier to the load balancing vServer.
5. Bind the same SSL and CA certificate you previously bound to the service group, to the load balancing vServer.
6. From within the load balancing vServer menu, select Persistence on the right hand side and set the persistence method to be CookieInsert.
7. Name the cookie. For example, NSC_SFPersistence, as this makes it easy to identify in Fiddler traces during debugging.
8. Set backup persistence to None.
This scenario uses the default StoreFront monitor using port 8000.
Considerations before creating a load balancing vServer include the following:
If a multisite deployment consists of two or more StoreFront server groups located in separate geographic locations, you can replicate subscription data between them using a pull strategy on a repeating schedule. StoreFront subscription replication uses TCP port 808, so using an existing load balancing vServer on HTTP port 80 or SSL 443 fails. To provide high availability for this service, create a second vServer on each NetScaler in your deployment to load balance TCP port 808 for each of the StoreFront server groups. When configuring the replication schedule, specify a server group address that matches the subscription synching vServer virtual IP address. Ensure the server group address is the FQDN of the load balancer for the server group at that location.
For StoreFront server A at Location A to request and pull subscription data from server B at a different location, server A must be a member of the CitrixSubscriptionsSyncUsers local security group on server B. The CitrixSubscriptionsSyncUsers local group contains an access control list of all remote StoreFront servers authorized to pull subscription data from a particular server. For bidirectional subscription synchronization, server B must also be a member of the CitrixSubscriptionsSyncUsers security group on server A to pull subscription data from it.
1. Import the same certificate and private key that was deployed on the NetScaler load balancing vServer to every StoreFront node in the server group.
2. Create an HTTPS binding in IIS on every StoreFront node, and then bind the certificate you imported earlier to it.
3. Install StoreFront on every node in the server group.
4. During installation of StoreFront, set the host base URL on the primary node to be the shared FQDN used by all members of the server group. You must use a certificate containing the load balanced FQDN as a Common Name (CN) or Subject Alternative Name (SAN).
5. When you complete the initial StoreFront configuration, join each of the nodes, one after the other, to the server group using the primary node.
6. Select Server Group > Add Server > Copy the Authorization Code to the joining Server.
7. Propagate the configuration from the primary node to all other server group nodes in the group.
8. Test the load balanced server group using a client that can contact and resolve the shared FQDN of the load balancer.
To enable external monitoring of the run-state of the Windows services on which StoreFront relies for correct operation, use the Citrix Service Monitor Windows service. This service has no other service dependencies and can monitor and report the failure of other critical StoreFront services. The monitor enables the relative health of a StoreFront server deployment to be determined externally by other Citrix components, such as NetScaler. Third party software can consume the StoreFront monitor XML response to monitor the health of essential StoreFront services.
After StoreFront is deployed, a default monitor that uses HTTP and port 8000 is created.
Note: Only a single instance of a monitor can exist within a Storefront deployment.
To make any changes to the existing default monitor, such as changing the protocol and port to HTTPS 443, use the three PowerShell cmdlets to view or reconfigure the StoreFront monitor service URL.
$DefaultServiceURL = "http://localhost:8000/StorefrontMonitor"
Install-DSServiceMonitorFeature -ServiceUrl $DefaultServiceURL
If you have configured the NetScaler Gateway vServer and load balancing vServer on the same NetScaler appliance, internal domain users might experience issues when trying to access the StoreFront load balanced host base URL directly rather than passing through the NetScaler Gateway vServer.
In this scenario StoreFront assumes that the end user has already authenticated at the NetScaler Gateway because StoreFront correlates the source IP address of the incoming user with the NetScaler Gateway Subnet IP Address (SNIP). This triggers StoreFront attempt to use the AGBasic protocol to perform NetScaler Gateway silent authentication, rather than actually prompting the user to log on with their domain credentials. To avoid this issue, omit a SNIP address as shown below so that username and password authentication is used instead of AGBasic.
Configure a Netscaler Gateway on the Storefront Server Group
In previous versions of Storefront such as 2.6 or older, Citrix recommended that you manually modify the hosts file on each StoreFront server to map the fully qualified domain name (FQDN) of the load balancer to the loopback address or the IP address of the specific StoreFront server. This ensures that Receiver for Web always communicates with the StoreFront services on the same server in a load balanced deployment. This is necessary because an HTTP session is created during the explicit login process between Receiver for Web and the authentication service and Receiver for Web communicates with Storefront services using the base FQDN. If the base FQDN were to resolve to the load balancer, the load balancer could potentially send the traffic to a different StoreFront server in the group, leading to authentication failure. This does not bypass the load balancer except when Receiver for Web attempts to contact the Store service residing on the same server as itself.
You can set loopback options using PowerShell. Enabling loopback negates the need to create host file entries on every StoreFront server in the server group.
Example Receiver for Web web.config file:
<communication attempts="2" timeout="00:01:00" loopback="On" loopbackPortUsingHttp="80">
Example PowerShell command:
& "c:\program files\Citrix\receiver storefront\scripts\ImportModules.ps1"
Set-DSLoopback -SiteId 1 -VirtualPath "/Citrix/StoreWeb" -Loopback "OnUsingHttp" -LoopbackPortUsingHttp 81
The -Loopback parameter can take three possible values.
Changes the host of the URL to 127.0.0.1. The schema and port (if specified) are not changed.
Cannot be used if SSL-terminating load balancer is used.
Changes the host to 127.0.0.1 and schema to HTTP and modifies the port the value configured for loopbackPortUsingHttp attribute.
Use only when the load balancer is SSL terminating. Communication between the load balancer and StoreFront servers is with HTTP. You can explicitly configure the HTTP port using the -loopbackPortUsingHttp attribute.
The URL in the request is not modified in any way.
Use for trouble shooting. Tools like Fiddler cannot capture the traffic between Receiver for Web and StoreFront Services if loopback is set to “On”.