XenApp Terminology!
Farms
Collection of XenApp servers combined to become a farm which
shares a single databaseknown as data store. We can compare a citrix farm to Active Directory
domain. It is a logical
collection of XenApp servers.
Zone
Zone is a collection
of XenApp servers that communicate with each other using common data collector.
In each zone there is a XenApp server which is designated as data collector.
Data collectors act as communication gateways. Zone can be compared to what
site is in Active Directory terminology.
Zones are basically
used to control the aggregation and replication of data in the farm.
Usually zones are created by taking into consideration network topology where
major geographical locations are created as one zone.
Best practice related to zone is to create zone for larger
geographical locations if in case all small geographical locations are
interconnected with adequate WAN links.
Data Collectors
Data collector is
basically a XenApp server with additional functionality of Data Collector. In a
farm with 100 XenApp servers there will be one server which will be designated
as Data Collector.
All the dynamic
information about the farm is stored by Data collectors. There is one server
which is designated as Zone Data Collector (ZDC) in a zone. If a particular ZDC
becomes unavailable election takes place to elect new data collector. Data
collector relays all the information it has to all other citrix servers. It
receives incremental updates from other servers. A zone data collector is a
server that manages dynamic information about the servers in the zone.
Since each zone has
ZDC, ZDCs in each zone talk to ZDCs of other zones and no other XenApp server
communicate with each other in different or same zones.
Primary
responsibilities of ZDC are:
1. Server loads.
2. Session status, users connected
3. Published applications.
4. License usage
5. Load balancing of user sessions.
6. Distributing updates to all servers in the
zone.
Qfarm command can be
used to know which server is holding the role of ZDC in a farm.
Data Stores
All the persistent /
static information is stored in data stores. In earlier versions of XenApp ,
IBM DB2, Data stores can be SQL or Oracle databases which store this
information. Each farm has single data store and all the servers in the farm
communicate with the datastore. If the datastore goes down administrators will
not be able to make any changes to the citrix farm.
In earlier versions of
XenApp , IBM DB2 database was supported as datastore but now XenApp 6 supports
only SQL Server and Oracle as database.
Information stored in
data store is as follows:
1. Farm/server configuration such a published applications and access
information.
2. Total licenses
3. Load balancing information
4. Administrator accounts.
5. Printer configuration.
DSview command can be
used to view the contents of data store.
Local Host Cache (LHC)
LHC stores subset of the information stored in the datastore. On
each server LHC is aMicrosoft Access database (MDB file) which holds information related to that particular
server and no information is stored about other servers. LHC main purpose is to
allow citrix server to run in case of datastore unavailability. Also it
improves performance by caching information which is used by ICA clients for
enumeration and application resolution. Actual file name of LHC is imalhc.mdb.
The below information
is stored in the local host cache:
• All servers in the
farm, and their basic information.
• All applications
published within the farm and their properties.
• All Windows network
domain trust relationships within the farm.
• All information
specific to itself. (product code, SNMP settings, licensing information)
When the first XenApp
member servers starts , LHC pulls above information from datastore. Once this
is populated, IMA service is responsible for keeping LHC synchronised.
DSmaint recreatelhc
command can be used to recreate LHC. In this case LHC pulls updated information
from Data store.
IMA
IMA stands for
Independent Management Architecture. IMA is not a protocol but main component
of XenApp server. IMA provides a framework for server to server communication.
IMA is installed on every XenApp server by default. It is an architecture which
controls all XenApp servers.
IMA works on port
2512. Server to server communication happens on port 2512 and server to console
communication happens over port 2513.
IMA Service
This service is a core
service on Citrix servers. When XenApp is installed on windows server
this service gets installed apart from other citrix services. If this service
is stopped then citrix server will not be able to communicate with rest of the
citrix servers forcing server not to accept any user connections. This service
is heart of the citrix servers.
This service is
responsible for following activities:
1. Tracking users, sessions, applications,
licenses and server load
2. Communication with other citrix servers.
3. Tracks which users have permissions to access
which applications
Citrix XML Service
This service is responsible for all communication to the IMA
service. Like IMA service this service also runs on all citrix servers. All
servers in the farm must have the same XML port number. The Citrix XML Service
was introduced with MetaFrame 1.8 Service Pack 2 and a Feature Release 1
license needed to be installed. MetaFrame XP and later incorporates the Citrix
XML Service as a standard feature.
XML service uses port 8080 which is shared with IIS which is the
default port and which can be changed using command – CTXXMLSS.EXE. Refer CTX
article - CTX104063 for knowing more about command line options.
This service gets its
information from the servers IMA service and sends information to whomever has
requested it. XML service generates XML files which are generated dynamically
and contain information which is requested by clients.
ICA protocol
ICA stands for
Independent Computing Architecture.
ICA is a very thin
protocol which is created by Citrix for client to server communication. ICA
protocol is a Presentation layer protocol on the OSI model.
It is both a protocol
and file type. When a citrix session is established between client and server,
this protocol is responsible for sending keystrokes and mouse movements from
client to server and sending screen updates from server to client. When a
particular application is published on Citrix server actual processing happens
on citrix server and all the screen images are transmitted to client machine
using ICA protocol. This protocol is a very high level protocol which works on
top of all other protocols such a TCP/IP, IPX/SPX and NetBIOs.
Port number of ICA
protocol is 1494.
If we open up a client
machine and check for file of extension .ica we will find some files with .ica
extension which are basically ICA files which can be opened using text editor
such as notepad which will show the citrix server addresses and other ICA
parameters in order to connect to citrix farm. This is how ICA client machine
connects to citrix server.
HDX
HDX is a new concept
and stands for High Definition Experience. HDX is nor a protocol or feature.
HDX basically contains set of citrix technologies. In order to improve user
experience Citrix has created HDX.
Technologies which are
under HDX are:
HDX MediaStream
HDX RealTime
HDX Broadcast
HDX SmartAccess
HDX Plug-n-Play
HDX RichGraphics with
RemoteFX
HDX WAN Optimization
HDX Adaptive
Orchestration
License Server
License server takes
care of all licensing of citrix products.
Web Interface
Web Interface is
basically a web server. User connects to web interface server while accessing
applications.
Application Publishing
When we deploy a particular application on citrix we call it a
published application. We install application on citrix server and give access
to users so that users can execute the same application from their client
devices. Actual processing / execution of application happen on citrix server
and only the screen updates are traversed to client machine.
Advantages of
application publishing are
1. Remote access to applications – Application
can be accessed from multiple devices such as PCs, laptops, tablets, Smart
Phones and other devices outside of corporate networks.
2. Maintenance of applications – Since
application is installed on only citrix server, any changes to application is
easy. Updates or version changes can be done on server without bothering
users.
Program Neighborhood / Receiver
In older days citrix receiver was known as Program Neighborhood
which has been discontinued by Citrix and no more available. Please refer CTX
article - CTX12172 for
more details.
Just to quote what
Program Neighborhood is from citrix site itself :
Program Neighborhood is the legacy user interface
included in the Citrix online plug-in (formerly Program Neighborhood Agent).
With this interface, users can browse for groups of published resources
(referred to as application sets) or create custom connections to individually
published resources or to computers running Citrix XenApp.
Instead of Program
Neighborhood we have now ICA clients known as Receivers (Also referred as
Citrix online plug-in). Latest Online plug-ins is known as Receiver.
Program Neighborhood
Agent
|
Citrix online
plug-in
|
Citrix Receiver
|
There are Citrix
receivers which are available now for different operating systems and devices:
Operating Systems
|
Devices
|
Microsoft Windows
|
Apple iPhone
|
Mac OS X
|
Apple iPad
|
Linux
|
Android – All
Android based devices such as Samsung Galaxy tablets/Phones etc, Sony
tablets.
|
Chromebook
|
Blackberry Phones
|
Blackberry PlayBook
– Tablet
|
|
Windows Mobile – Any
phone which is using Windows Mobile such Nokia Lumia phones
|
Worker Group
In earlier XenApp
versions only way to group similar servers which were hosting same application
is to create folders in console. This functionality has been taken by a new
concept called worker groups in XenApp 6 onwards. Worker group is a collection
of XenApp servers which are hosting similar applications to be managed as one.
For example if there are 5 servers hosting Microsoft Office applications then
all these 5 servers can be combined to become a worker group. Worker group is
closely associated with “Application silo” concept. All servers in a worker
group share same citrix settings and same published applications. Worker groups
can only consist of XenApp servers in the same farm. Worker groups allow
collecting servers into groups for publishing applications, load balancing and
policy filtering.
Though zones and
server folders still exist in XenApp 6, worker group has been added as
additional concept for load balancing policies. In earlier versions of XenApp ,
zones were created to control load balancing via the Zone Preference and
Failover feature but this has been replaced by citrix policies in XenApp 6.
Worker groups should be created to define load balancing policies and zones
should be created for data replication between data collectors.
Folders can be created
to organize severs in the management console which basically creates a
hierarchy of servers. Also they can be used to control permissions for
delegated administration.
If we navigate to the
properties of each published application in XenApp farm it has got the server
list which tells us on which server’s application has been published. So in
case when you have set of applications which are published on a set of servers
and in case if you wanted to add/remove servers from these applications then
only way to achieve this was to manually edit through the properties of each of
these published applications. With XenApp 6 we can create an AD container
called “worker group” and assign settings such as computer policies, load balancing
polices and applications published on those worker group. So once we
create a worker group and add servers into worker group all the settings
gets applied to all servers in that worker group. We can add / remove servers
from worker group and there is no need to go to each application properties
page. In the server list page instead of adding list of servers we will add
worker groups.
Benefits of worker
groups.
Ads not by this site
Worker Group
|
Similar
functionality
|
|
Location
|
A single server can
belong to multiple worker groups. Servers can be grouped into worker groups
both by geographical location or by the applications they are hosting
|
Single server cannot
be part of two folders simultaneously.
|
Load balancing
|
Worker groups can be
used to control load balancing within a single site. A worker group can
contain a single server.
|
Zones can be used
for load balancing.
|
Dynamic
|
Worker groups are
more dynamic as when AD containers are added to a worker group and if there
are any changes to AD container then they are automatically reflected in the
server’s worker group memberships.
|
This functionality
is not present in earlier versions of XenApp.
|
Worker Group Preference
Worker group
preference is a new feature in load balancing policies. This feature is used to
load balance specific set of users to specific set of servers. We can use this
feature in following scenarios:
§ Allow user to connect to application from the
nearest site in order to reduce WAN traffic and enhance overall user
experience.
§ Allow users to connect to backup site in case
of disaster.
§ Dedicating servers for specific group of
servers.
Session Reliability and ICA keep Alive
Session reliability is
a feature which keeps the session reliable. Common example which is given is
when a user who is travelling , who has connected to application over wireless
connection and when he passes through a tunnel wireless connection drops then
session reliability feature kicks in and keeps the session active so that user
does not get disconnected from session. When session reliability is enabled
users continue to see the application they are using until network connectivity
resumes. When user loses wireless connectivity user’s display freezes and
cursor changes to hourglass until connectivity resumes. With session reliability
user’s session remains active on the server and it does not get disconnected.
Session reliability
works on port 2598.
Port used by ICA
session is 1494 but if Session Reliability feature is enabled, the default port
used for session communication changes from 1494 to 2598.
If Session reliability
is enabled then ICA keep- alive feature does not work.
ICA Keep –alive
feature keeps broken connections from being disconnected. So that means that
both session reliability and keep-alive tries to keep the sessions active. When
keep-alive is enabled, even if there is no mouse movement, no screen updates
than that session does not get disconnected. ICA Keep-alive feature has to be
enabled only when session reliability is not used.
By design, Session Reliability overrides the ICA KeepAlive
setting & this applies to PS 4.0, PS 4.5 as well as XenApp 5.0 product
versions. Refer CTX107659.
Common Ports
Component
|
Type
|
Port Number
|
Details
|
IMA
|
TCP
|
2512
|
Independent
Management Architecture (IMA)
|
Management Console
|
TCP
|
2513
|
Citrix Management
Consoles ( console to XenApp server communication)
|
ICA / HDX
|
TCP
|
1494
|
Access to
applications and virtual desktops
|
ICA with session
reliability
|
TCP
|
2598
|
Access to applications
and virtual desktops
|
Application /
Desktop Request
|
TCP
|
80/8080/443
|
XML Service
|
Secure Sockets Layer
|
TCP
|
443
|
SSL
|
License Manager
Daemon
|
TCP
|
27000
|
Handles initial
point of contact for license requests (Lmadmin.exe)
|
License Management
console
|
TCP
|
8082
|
Web-based
administration console (Lmadmin.exe)
|
Citrix Vendor Daemon
|
TCP
|
7279
|
Check-in/check-out
of Citrix licenses (Citrix.exe)
|
RDP
|
TCP
|
3389
|
Remote Desktop
Protocol
|
Database
|
TCP
|
1433
|
Microsoft SQL Server
|
LDAP
|
TCP/UDP
|
389
|
LDAP connection
|
LDAP
|
TCP/UDP
|
636
|
LDAP SSL connection
|
Active Directory
|
TCP
|
3268
|
LDAP connection to
Global Catalog
|
Active Directory
|
TCP
|
3269
|
LDAP SSL connection
to Global Catalog
|
No comments:
Post a Comment