Netscaler Basics – Load Balancing

In a Netscaler load balancing setup, the load balancing server is logically (virtual server) located between the client and the server farm, and manages traffic flow to the servers in the server farm. On the NetScaler appliance, the application servers are represented by virtual entities called Services.

The components of NetScaler load balancing setup:

1. Load balancing virtual server
The IP address, port, and protocol combination to which a client sends connection requests for a particular load-balanced website or application. If the application is accessible from the Internet, the virtual server IP (VIP) address is a public IP address. If the application is accessible only from the local area network (LAN) or wide area network (WAN), the VIP is usually a private (ICANN non-routable) IP address.

2. Service
The IP address, port, and protocol combination used to route requests to a specific load-balanced application server. A service can be a logical representation of the application server itself, or of an application running on a server that hosts multiple applications. After creating a service, you bind it to a load balancing virtual server.

3. Server object
A virtual entity that enables you to assign a name to a physical server instead of identifying the server by its IP address. If you create a server object, you can specify its name instead of the server’s IP address when you create a service. Otherwise, you must specify the server’s IP address when you create a service, and the IP address becomes the name of the server.

4. Monitor
An entity on the NetScaler appliance that tracks a service and ensures that it is operating correctly. The monitor periodically probes (or performs a health check on) each service to which you assign it. If the service does not respond within the time specified by the time-out, and a specified number of health checks fail, that service is marked DOWN. The NetScaler appliance then skips that service when performing load balancing, until the issues that caused the service to quit responding are fixed.

1. Create Server Objects

Configuration > Traffic Management  > Load Balancing > Servers > Add.

Provide web servers name and IP address, create 2 or more servers

2. Create Service Group

Configuration > Traffic Management  > Load Balancing > Service Groups > Add.

Provide Name the group and set the protocol to HTTP.

Click ‘No Service Group members’ and select server based. Select Port as 80 or 443.

3. Create “Monitors” to monitor the Service.

Click ‘No service Group to Monitor Binding’. Select pre-configured HTTP monitor and Bind.

4. Create Vitrual Server. Configuration > Traffic Management  > Load Balancing > Virtual Servers > Add.

Give the Virtual Server name, Protocol- HTTP, IP address and Port -80. This will be the VIP the NetScaler presents to the outside world.

Click ‘No load balancing Virtual Servers Service Group Binding’ and select the Service Group and Bind.

Posted in Citrix XenApp

Persistence on NetScaler

Some transaction based applications require persistence. For example, banking sites are interactive programs based on user input and selections. User logs on by providing a username and password and then the user can do a variety of tasks, such as checking account balance, transferring fund, etc. If persistence is not configured, user might have authenticated with Server 1, but his next request may go to Server 2 or Server 3.

In this case, the application will reject the user request since Server 2 or Server 3 does not have user’s transaction state & authentication details. If persistence is configured, all subsequent requests from the user will be directed to the server which got selected in the first request. In this example, all requests will be forwarded to Server 1.

Persistence can be configured for the following protocols: HTTP, SSL, IP, TCP, UDP, SIP, and RTSP. The administrator can configure persistence interval and persistence type based on the application requirement. NetScaler supports 10 persistence types. Netscaler can support 250K Persistent session for a core and some persistence types (CookieInsert) depends on the Netscaler memory limit. If persistence is configured for a particular domain, it takes precedence over the configured GSLB method. If the configured persistence applies to a site that is down, the NetScaler appliance uses a GSLB method to select a new site, and the new site becomes persistent for subsequent requests from the client.
Citrix recommends to configure the Cookie Insert persistence method on the NetScaler appliance when load balancing Citrix Web Interface servers.

Some persistence types:
Source IP, Cookie Insert, SSL Session ID, URL Passive, Custom Server ID, Rule, DESTIP, SRCIPDESTIP

To configure Cookie persistence by using commands:

> add lb vserver V1 http 10.120.80.50 80 -persistencetype COOKIEINSERT
Done
>
> add service S1 200.205,215.1 HTTP 80
Done
>
> add service S2 200.205,215.2 HTTP 80
Done
>
> add service S3 200.205,215.3 HTTP 80
Done
>
> bind lb vserver V1 S[1-3]
service “S1” bound
service “S2” bound
service “S3” bound
Done

To verify the cookie value of a service:

>show lb vserver V1

To capture the Service selection counter and Cookie persistence counter from NetScaler shell prompt:

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

To configure Source IP Persistence by using commands:

> add lb vserver V1 http 10.120.80.50 80 -persistencetype sourceIP -timeout 5
Done
> bind lb vserver V1 S[1-3]
service “S1” bound
service “S2” bound
service “S3” bound
Done

To displays persistence session information:

> show persistentSessions -summary

Posted in Citrix XenApp

Citrix Migration Trends and Usage Survey Results – 2018

q1

Citrix XenApp and XenDesktop 7.x is the leading app and desktop virtualization platform that delivers a high-definition user experience on any device and a cloud service from Citrix Cloud. With Citrix XenApp 6.5 nearing End of Life (EOL) on 30th June-2018, many Citrix customers are planning to upgrade to XenApp and XenDesktop 7.x.

To understand this market trend a survey was conducted across 795 Citrix professionals during November 2017 and February 2018 around the world by a Citrix Ready partner. The results of this survey conducted have been compiled into an industry insight report, which will be helpful for any Citrix professional considering upgrading to XenApp and XenDesktop 7.x.

The survey was designed to find out about organizations’ migration plans, challenges, and performance expectations, as they plan their upgrade path. Analysis of the survey results helped shed light on when Citrix customers are planning to complete their migration, the factors driving the migration, adoption of Citrix Cloud, and many other interesting trends.

Here is a preview of some of the key findings:

2018 will be the year of Citrix migration. 70% of organizations are expected to complete the migration to XenApp and XenDesktop 7.x by the end of the year as older versions are nearing EOL.

The Long-term Service Release (LTSR), with 5 years of mainstream support, as well as support for Windows 10 are other important factors driving customers’ migration plans to 7.x.

45% are considering Citrix Cloud in the near future, and only 5% of respondents are already using Citrix Cloud.

90% of XenDesktop deployments are on version 7.x.

93% are running XenApp.

40% are running only XenApp and 7% are running only XenDesktop where as 53% are running both XenApp and XenDestop.

66% of respondents are running XenApp 7.x, and 65% are running 6.x.

18% of respondents are still running very old versions of XenApp.

There is a significant overlap between organizations using 7.x and 6.x. This indicates that organizations have deployed newer workloads on 7.x and they have continued on 6.x for the older applications and workloads.

Organizations are using multiple tools for monitoring their Citrix infrastructures. 91% agreed that having a single-pane-of-glass monitoring solution would simplify troubleshooting.

At 59%, slow logon continues to be the most common complaint faced by Citrix administrators. Measuring logon slowness is rated the most important aspect of Citrix user experience.

In large organizations (5,000+ employees), usage of 6.x, 5.x, and 4.x is comparatively higher.

The actual migration process does not seem to be a big concern for Citrix professionals. Only 19% of professionals have some reservations and fears about the steps involved during migration. This mainly applies to those migrating from 6.x to 7.x and about the pre-migration and post-migration phases.

The latest version of XA/XD 7.17 is only supported on Windows Server 2016 and 2012 R2.

75% respondents are considering using VMware vSphere hypervisor for XenApp and XenDesktop 7.x deployments.

Majority of respondents (67%) are using Citrix Director for performance monitoring. 28% are still using EdgeSight, which reaches EOL on June 30, 2018.

83% large organizations are using up to 10 tools for Citrix performance monitoring.

37% are not able to pinpoint infrastructure issues affecting Citrix performance. Most of the Citrix admins want to prove it is not Citrix that is causing a problem!

Performance monitoring for Citrix administration teams has become increasingly reactive and admins are constantly in a firefighting mode. 86% of respondents feel faster problem diagnosis and troubleshooting is their most critical need.

25% of Information Technology, 15% of Health Care and 10% of Financial Services industries use Citrix products

Posted in Citrix XenApp

Components of a Global Server Load Balancing (GSLB) in NetScaler

Global Server Load Balancing (GSLB) is used to share the load between multiple locations (datacenters) or to make sure that users will always be connected to the datacenter that is closest, improving the overall user experience.

Global Server Load Balancing Domain: The Global Server Load Balancing Domain is a publicly resolvable domain or zone for which the Global Server Load Balancing setup is responsible. You can set up a NetScaler appliance to be the Authoritative Server for this domain or to proxy the information to an internal DNS server.

Global Server Load Balancing Site: The Global Server Load Balancing Site is the top-level entity for the Global Server Load Balancing communications. The information used when configuring the site is used for linking LOCAL sites to REMOTE sites and sharing monitoring data by using the Metric Exchange Protocol (MEP). The IP address used must be owned by the NetScaler appliance, such as subnet IP (SNIP), and must use TCP port 3011.

Global Server Load Balancing vServer: The Global Server Load Balancing VServer is used as the decision intermediary for directing client requests to the Load Balancing VServers of one of the GSLB site. The Global Server Load Balancing VServer is bound to a Global Server Load Balancing service.

Global Server Load Balancing Service: The Global Server Load Balancing Service is basically a monitoring link to the Load Balancing VServer. The Global Server Load Balancing Service monitors the link to the Load Balancing VServer that is created on the NetScaler appliance. The state of the local Global Server Load Balancing Service depends on the corresponding local virtual server state.

The Global Server Load Balancing is setup by adding a site identifier at each site. The site identifier includes a site name, a type, and an IP address that is owned by the NetScaler appliance and is used for the GSLB communications.

Each site, has a site type of LOCAL, which defines the site to be a local to the appliance. Additionally, each site, has two or more sites of type REMOTE, which defines the other sites as remote to the local appliance. On each site, a Global Server Load Balancing VServer is created with the same name. This VServer identifies the web site of the organization globally and does not have any IP address associated to it.

The GSLB services are pointing to the Load Balancing vServers configured on each GSLB site by specifying the IP address, protocol, and port number of the respective VServer. These services are bound to each GSLB VServer.

When configuring GSLB the NetScaler will serve as an authoritative nameserver for the address, or domain you would like to control between multiple locations. The NetScaler also serve as a proxy for the authoritative nameservers on the internal network. The authoritative DNS service (ADNS) resolves the DNS queries made and hands it over to the GSLB vServer. The NetScalers will function as authoritative nameservers within a so-called GSLB domain

The GSLB selection process (Load Balancing) can be based on multiple metrics like Round Robin, Least Connection, Least Bandwidth, SourceIPhash, random and a few more. Users can also be bound to a specific location / data center if needed using a method called Static Proximity. When using RTT, Round Trip Time it will calculate the distance between the local NetScaler and the DNS server from where the initial request originated. The RTT is then used to determine the site closest to the user.

After the authoritative nameserver has been contacted, the GSLB vServer will select a GSLB service representing either a load balance, content switching or Gateway vServer to reply with the VIP. Next, the client device from where the DNS request originated will contact the VIP address and will eventually end up on one of the load balanced web servers or the NetScaler Gateway login page.

Posted in Citrix XenApp

Troubleshoot authentication issue in NetScaler

Authentication processing in NetScaler Gateway is handled by the Authentication, Authorization, and Auditing (AAA) daemon. The raw authentication events that AAA daemon processes can be monitored by viewing the output of the aaad.debug module and serves as a valuable troubleshooting tool. The aaad.debug does not display the results or log them, so cat command can be used to view the output of aaad.debug. The process of using nsaaad.debug to troubleshoot an authentication problem is typically referred to as debugging aaad. This process is useful for troubleshooting authentication issues such as:

•General authentication errors
•Username/password failures
•Authentication policy configuration errors
•Group extraction discrepancies

To troubleshoot authentication with aaad.debug module, complete the following procedure:

1. Connect to NetScaler Gateway command line interface with a Secure Shell (SSH) client such as PuTTY.
2. Run the following command to switch to the shell prompt: shell
3. Run the following command to change to the /tmp directory: cd /tmp
4. Run the following command to start the debugging process: cat aaad.debug
5. Perform the authentication process that requires troubleshooting, such as a user logon attempt.
6. Monitor the output of the cat aaad.debug command to interpret and troubleshoot the authentication process.
7. Stop the debugging process by pressing Ctrl+Z.
8. Run the following command to record the output of aaad.debug to a file:

cat aaad.debug | tee /var/tmp/debuglogname.log

Posted in Citrix XenApp