License pooling paper - Alon Systems

existencetubΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

61 εμφανίσεις

Citrix License Pooling

An explanation of the ICA Browser Service as it relates to the storage and
manipulation of pooled license data.


Introduction:

As corporations deploy greater numbers of Citrix based servers within the enterprise; the concurrent serve
r
based licensing model proves to be vital in the cost
-
effective deployment of Server
-
based computing
solutions. A key feature of Citrix concurrent server based licensing is the ability to “pool” the available
server based licenses for use by all servers
on the network. Citrix license pooling enables an administrator
to allocate some or all of the licenses installed on a server, to a central pool of licenses to be shared among
multiple servers. With License Pooling, administrators can cost
-
effectively
simplify the administration of
their Citrix server licenses while protecting the investment in their existing infrastructure.


The ICA Browser Service is central to a license pool:

The Citrix ICA Browser Service maintains Server and Published Application d
ata for use by the ICA
clients. Data is stored and maintained separately for each network transport (i.e. TCP/IP, IPX, and
NetBIOS). The ICA Browser Service consists of ICA clients, Member Servers, and a Master Browser.

MetaFrame and WinFrame servers part
icipate in the ICA Browser Service. All servers are Member
Browsers with the exception of a single server on each subnet being designated as the Master Browser for
each transport protocol the server will support.


ICA Clients:

Within the ICA Browser Servi
ce system, the ICA client requests browser data for use in connecting to an
ICA Server, Load Balanced Server Farm, or Published Application. ICA Clients query the ICA Browser
Service to obtain the current list of Servers, Load Balanced Server Farms and Pub
lished Applications, as
well as all information used to connect to these objects. The ICA Browser is not necessary for a point to
point connection between an ICA client and a specific ICA Server. However, when name resolution is
required as in connecting
to a Published Application, or Server Farm, the ICA Browser Service is central to
the success of the connection. When an ICA client makes a request for server information, the request is
passed to the Master Browser for response, this ensures that the mos
t complete, up to date information is
returned to the requesting client.


Member Browsers:

Member Browsers are Citrix servers that communicate ICA browser information to a central Master
Browser. Each ICA Member Browser is by default a potential ICA Maste
r Browser based on its individual
election criteria.


The Master Browser:

The ICA Master Browser behaves like a Member Browser with the exception that it maintains the central
browse list containing; connection, licensing, load balancing and other administ
rative data used by both the
ICA clients and servers; ICA Member Browsers periodically update this central list. In consideration of the
lowest possible bandwidth utilization, the ICA Master Browser does not request information from each
Member Browser, b
ut instead receives directed data from each Member Browser at regular intervals or as
the data on a given Member Browser changes.


A Master Browser exists for each transport protocol used on a network. At this time, ICA Browser support
exists for TCP/I
P, IPX, and NetBIOS transports. If all three protocols are used in a single subnet there will
be three separate Master Browser threads running simultaneously. All three Master Browsers can run on
the same physical server if it is configured to support al
l three transports. If a server is not configured for a
given protocol, it may not participate as the master browser for that protocol. For example; in the diagram
below, ServerA is configured to support both the TCP/IP and NetBIOS protocols, ServerB is
configured to
support both the IPX and NetBIOS protocols, and ServerC is configured to support the TCP/IP, IPX, and
NetBIOS protocols. If a Browser election were to take place for all of the protocols the potential exists that
the TCP/IP master browser wo
uld be ServerA or ServerC but never ServerB.



ServerA




ServerB




ServerC










TCP/IP

No TCP/IP

TCP/IP

NetBIOS

NetBIOS

NetBIOS

No IPX

IPX

IPX



Master Browser Elections:

What causes a Master Browser Election?

A Master Browser becomes such by w
inning a Master Browser election. A Master Browser election will
be forced when one of the following occurs:


1.

The current Master Browser does not acknowledge a Member Browser after an update has been sent.

2.

The current Master Browser does not respond to an

ICA client requesting information.

3.

Because there can be only one Master Browser per transport on a given subnet, If two Master Browsers
are detected on the same network subnet, an election will be forced to resolve the conflict.

4.

When a Citrix server is br
ought on
-
line it will request an election to occur.


What determines the winner of a Master Browser Election?

A set of election criteria is used to determine who becomes the Master Browser during an election. An ICA
Browser begins its participation in an I
CA browser election by broadcasting its election criteria to the ICA
browser service. If a browser within the service has higher election criteria, it broadcasts its own election
criteria. The ICA Browser to respond to the election with the highest criteri
a will become the Master
Browser.


The election criteria used in the election of a master browser are in order of weighting highest to lowest:


1.

Statically configured as a Master Browser

2.

Highest browser version number

3.

Running on a NT domain controller

4.

Lon
gest running browser

5.

Lexically lower browser name


Higher ordered criteria have precedence over lower criteria.

For example, a Master Browser that is not statically configured to be the Master has been running for two
hours when another Citrix server is br
ought on
-
line. If the second server is running a newer, higher version
of WinFrame or MetaFrame, the second server wins the Master Browser election.


The License Pool


Administering the pooled license count for a server.

All pooled licenses are made avail
able to all servers within a given subnet, regardless of NT Domain or
server farm membership. Allowing licenses to be pooled independently of a server’s domain affiliation
allows for a more efficient use of the concurrent licenses purchased. To determin
e the total number of
pooled licenses for a subnet, the command line utility QUERY SERVER should be used.


The number of pooled licenses for a specific server can be determined by using the MetaFrame
Administration utility on MetaFrame servers or the WinSt
ation Administration utility on WinFrame
servers. To view the total number of pooled licenses for a server from within MetaFrame Administration
or WinStation Administration; choose a server from the Server list on the left side of the utility and then
cho
ose the Licenses tab in the right side of the utility; the license count for the server is displayed at the top
of the details area, as in the example below:





Changing the pooled license count:

By default, all licenses installed on a server are pooled

to the subnet. If an administrator wishes to allocate
a number of licenses to always be available for a specific server, they may lower the number of pooled
licenses; from within the Citrix Licensing Utility on MetaFrame systems, or the WinFrame Licensin
g
utility on WinFrame systems. The number of pooled licenses can be changed by double
-
clicking the
license to be effected and then increasing or decreasing the “#Pooled” value.




Note!

Licenses can not be pooled across subnets.


What happens to a licen
se pool when a server goes off
-
line?

When a server in a license pool goes off
-
line, the licenses that were installed on that server stay available to
the license pool for up to 48 hours or until a new Master Browser is elected, which ever happens first. T
his
48
-
hour grace period is designed to ensure minimal impact to the pool when a server is taken off
-
line.


The only caveat to the 48
-
hour grace period comes in the event of a Master Browser election, when a new
Master Browser is chosen. The Master Bro
wser is a passive repository for the most current ICA Browser
Service data. When a new Master Browser is chosen in an election, all of the Member Browsers will update
the new Master Browser with their own machine
-
local browsing and licensing information, t
he information
that was stored in the previous Master Browser is discarded.


Conclusion:

A thorough understanding of the Citrix License Pooling architecture will enable WinFrame and MetaFrame
administrators to plan for the most efficient use of their conc
urrent user license base. When efficiently
implemented, licenses are made available for a higher number of users when, and where, the licenses are
actually needed.