MyXenApp

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.

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

NetScaler Gateway Express License: The Express license is used with the NetScaler VPX and allows for up to five concurrent user connections by using Receiver or the NetScaler Gateway Plug-in. The Express license is available for the VPX appliance and expires after one year. Users can connect to either Basic or SmartAccess virtual servers.

NetScaler Gateway Platform License (ICA license): The Platform license allows unlimited user connections to published applications on XenApp or virtual desktops from XenDesktop. Connections using Citrix Receiver do not use a NetScaler Gateway Universal license. These connections only need the Platform license. The Platform license is delivered electronically with all new NetScaler Gateway orders, whether physical or virtual. If you already own an appliance covered by a warranty or maintenance agreement, you can obtain the Platform license from the Citrix web site.

NetScaler Gateway Universal License (CCU license): This license allows VPN connections to the network from the NetScaler Gateway Plug-in, a SmartAccess logon point, or Secure Hub, Secure Web, or Secure Mail.

Use Serial Number. The software internally fetches the serial number of your appliance and uses this number to display your license(s).
Use License Activation Code. Citrix emails the LAC for the license that you purchased.

Sample commands:

login: nsroot
Password: nsroot
> shell
root@ns# mkdir /nsconfig/license
root@ns# cd /nsconfig/license

Copy the new license file(s) to this directory.

sh ns license
show feature
enable feature lb

In a nutshell, “target” systems (Virtual Machines that don’t have an OS disk) are configured to boot from the network (PXE). A PVS streaming server(s) provides a PXE bootstrap which instructs the machines to request a vDisk from one of the PVS streaming servers to boot off. The PVS Servers hold a record of all preconfigured “targets”, identifiable by MAC address. When the requesting MAC address is found in the backend database of all targets, a vDisk is streamed to the target, along with unique personalization (machine name, SID, domain computer account password, etc.) injected in. The streamed OS disk (C: drive) is appears as a Citrix Virtual Disk from within the guest.

Targets are VMs that will boot up and stream its OS volume (C: Drive) over the network from one or more PVS Streaming servers. The vDisk that a target boots from, is determined in the properties of each target object that are created and managed within the PVS Console. A target uses the MAC address from the requesting VM to determine what its logical identity (i.e. Windows machine name) will be on the network and in the Active Directory, and what vDisk version to present to it. Targets are stored in “Device Collections”, which are logical groups that allow you to manage many targets that share common characteristics, such as which vDisk is used. Create a unique Device Collection for each Machine Catalog you will create in XenDesktop.