The
general idea
The
FMA is primarily made up out of Delivery Controllers and Agents. Delivery
Agents are installed on all virtual and or physical machines provisioned by
XenDesktop 7, they communicate (and register themselves) with
the Delivery Controller(s) and the license
server. The Controllers on their turn communicate with a central
(SQL) database. This database is very important, next to things like XenDesktop
Site policies, Machine Catalogs, Delivery Groups and
published applications and or (hosted) desktops, it also contains all live
dynamic ‘runtime’ data like: who is connected to which resource, on which
server, server load and connection statuses used to make load balance decisions
and so forth. Make sure you implement some kind of database redundancy
like SQL replication or clustering of some sort. If the database isn’t
reachable for some reason running sessions will keep working but new sessions
cannot be established and configuration changes aren’t possible, keep that in
mind. More on the overall architecture and its components in a minute. The
picture below, owned by Citrix, isn’t new but it does still provides us with a
clear overview on the overall XD7 architecture.
A
quote from Citrix: “Unlike XenApp, the Delivery Agent communicates only with
the controllers in the site and does not need to access the site database or
license server directly” Having quoted that, XenApp workers (session host only
servers) offer the same sort of benefit. As they only host user sessions and
will (or can) never be ‘elected’ as an Data Collector for their zone they
won’t get all the IMA store (database) information pushed into their LHC
enhancing overall performance. However, these workers still consist
of the same bits and bytes as installed on a Data Collector compared to ‘just’
a Delivery Agent which are lighter weight, as Citrix puts it.
FMA
vs IMA
With
the introduction of XenDesktop 7 IMA is gone! But what does this tell
us? Well… It basically means that Zones together with their Zone Data
Collectors are gone (it’s now one big Site) so no more Zone preference policies
and Load Balance policies are now applied at Site level instead of Zones. No
more IMA protocol and Service, these are replaced by the XD7 Virtual Agents
that get installed on all Virtual and or Physical machines provisioned through
XenDesktop 7. Since Data Collectors (and thus Zones) are no longer part of the
overall architecture and all virtual and or physical servers in XD7 basically
function as ‘Workers’ or ‘Session only Mode’ (as far as the former XenApp
servers are concerned anyway) this also means that most of our old XenApp
designs don’t apply anymore and it might be time to re-think and re-design
them. Data flow has changed and in some designs different rules now apply.
LHC
XD7
Delivery Controllers don’t have a Local Host Cache (LHC) this means
that user authentication, application enumeration (and requests) and user
connection requests, plus a few more :-) all need to come from the central SQL
DB, including server Load Balance information. XenDesktop has been doing it
this way for a while now so it should be ok.
Improved
In
XenDesktop 7 the FMA now combines provisioning and personalization tools for
both desktops and applications. New and improved features include: Windows 8
and Windows Server 2012 support, Application publishing, XenApp is merged into
XD or FMA if you will, allowing you to publish applications and or hosted
shared desktops from Server OS’s. As of this release Machine Creation
Services can also be used to provision virtual server machines (also
called Workloads) not just desktops, a big step forward! Note that Citrix
Provisioning Services (PVS) can still be used, no real changes there.
The
best thing is, all Agents communicate with the same controller no matter which
OS is installed! This is what makes the diversity in operating
systems possible especially for XenApp. For example, you can have one
Delivery Group (again, we already had these in previous versions of XD, the
same goes for Machine Catalogs as well) applied to multiple different
Machine Catalogs. See below and as opposed to XenApp, the Delivery Controller
(former Data Collector) no longer needs to have Terminal Services installed.
Machine
Creation Services
Big
part of the overall FMA. As you know MCS within XD7 and earlier version takes
care of the provisioning of virtual machines, multiple (tens, hundreds,
thousands even) at once on your underlying Host Infrastructure (your
Hypervisor of choice) which in the case of XD7 can either be desktop or
server workloads, Windows 8 and Server 2012 included. Some cool new features
have been announced recently, I picked them up during one of Citrix’s Master
Classes, read on below.
With
the introduction of Hyper-V 3.0 in Server 2012 new features have become
available. MCS as well as PVS can now both leverage SMB 3.0 shared folders on
file servers with clustered shared volumes and SAN’s and use them as shared
storage.
When
Hyper-V 3.0 is used as the underlying Hypervisor MCS supports the VHDX
format. Secondary disks attached to the virtual machine destined for PVS Write
cache for example will also automatically leverage the ‘new’ VHDX format, the
same goes for PVS Personal vDisks. PVS disks that are accessed and managed
directly from the Provisioning Server itself will continue to use the VHD
format since PVS is and can still be used on Windows Server 2008 R2 as well.
MCS
can take advantage of another Hyper-V 3.0 feature called: Clustered Shared
Volume Read Caching. I got this from one of the Citrix Blogs: XenDesktop
7 can take advantage of this capability to reduce storage IO for MCS
catalogs during boot and logon storms. The effect is similar to that of
the caching that takes place on PVS hosts, except that the blocks are delivered
once to each Hyper-V host and then shared among the VMs on that host. CSV
cashing makes use of host RAM for this cache so there will be some tradeoff
between cache size and the amount of RAM available to VM’s.
MCS
now also supports KMS during the image creation process. It enables the KMS
system to record each VM as a separate machine. Each machine created provides
unique activation for Windows as well as Office 2010 installations.
When
creating a master image and Personal vDisks are involved, it’s no longer
necessary to manually run an inventory at the end of the image creation
process. Also, during the image preparation process DHCP is now automatically
enabled.
Storage
Superseding. A new concept to MCS, you can configure certain storage in a way
so that existing virtual machines on there will keep functioning but new
provisioned virtual machines won’t be created on that specific storage. A nice
feature to use when your storage is almost full.
PVS
and MCS go hand in hand: you can create a Delivery Group containing both
PVS and MCS provisioned machines. Perhaps not something you will implement in
‘real life’ but it shows you just how flexible the product is. Could be nice
for POC’s though.
Catalogs
As
far as XenDesktop goes a Catalog is still a catalog, you can have a Windows 7
catalog, a Windows 8 catalog etc… For XenApp however, things are different.
From a XenApp point of view you can compare a Catalog with a Worker group with
a few exceptions… As you probably know, in a XenApp Farm all the server systems
need to have the same operating system installed, no exceptions. So if you have
2 or more Worker groups then all the systems within those groups will have the
same OS installed. In XD7 things work different, for example, you can create
two different Catalogs (Worker groups) for use with XenApp in which you can
have one Catalog with Windows Server 2008R2 installed and another with Windows
Server 2012 and publish two separate hosted shared desktops, all within the
same infrastructure, a big change!
Delivery
Groups
Delivery
groups are not a new concept just a name change, used to be called Desktop
groups in XenDesktop, they are still created from, or applied to, Catalogs
and pretty much fulfill the same tasks. There is a big change though… In
earlier versions of XenDesktop you assigned a Desktop Group to a Catalog or
multiple Catalogs if needed, but the Catalogs all needed to be exactly the
same, meaning that they all shared the same common image, 2008R2 for example.
Now, in XD7 it is possible to assign a single Delivery group to multiple
different Catalogs, as mentioned earlier. Think back to the example above,
two Catalogs with two different operating systems installed same here but with
just one Delivery group assigned to them. Simplified management! The same goes
for XenApp, two different Catalogs: 2008R2 and 2012 (which already is a big new
feature on its self), one Delivery group.
A
quick note one the above, I haven’t got the chance to look at the final product
yet, but during one of Citrix’s Masterclasses it showed that Delivery Groups
can be used to either publish applications or (VDI) desktop or both from the
same Delivery Group. This process is slightly different from the App publishing
feature in the Excalibur Tech Preview release where Delivery Groups get added
during the application publishing process. So I’m not sure if both options are
still in there.
All under
one roof
No
more separate infrastructures for desktops and applications, it’s one install,
architecture and console (Citrix Studio) to meet all your delivery needs.
It includes several workflows which simplify and speed up the process of
delivering desktops and applications to users. Delivery Agents in XD7 are
configured via policies. Any combination of Active Directory GPOs, the
Studio console (HDX Policy), and Local GPO settings can be used.
This
comes from one of the Citrix Blogs regarding FMA: The biggest difference
between the two Delivery Agents (there are desktop and server
DA’s) is the ICA protocol stack used. For desktop machines, Citrix
ships a single-user ICA stack (internally known as PortICA) which allows only
one ICA session at a time. This version connects users to the machine’s
console session, similar GoToMyPC or other Remote Access products for a Desktop
OS. It also includes additional HDX features such as USB and Aero redirection,
which are only available on a single-user machine. For server machines,
Citrix includes a multi-user ICA stack, which extends Windows Remote Desktop
Services with the HDX protocol. This is the same ICA protocol stack
developed for Citrix XenApp, just with a different management interface to make
it compatible with Excalibur controllers. I couldn’t have said it any
better :-)
Other high
level FMA changes
Some
new services are introduced # The delegated admin service providing the Roles
and Scopes # Configuration Logging # Monitor Service # Environment Tests #
StoreFront integration # Machine Creation Services has been reduced to two
services in total.
Some
more changes:
There
is a secondary database specifically for Configuration Logging and the Monitor
Service # Remote PC is fully integrated into the Catalogs and Delivery Groups #
Load Balancing is controlled via Group Policy, on Site level that is #
Applications are now associated with Delivery Groups and application
attributes like color depth and audio are also configured through Delivery
Groups.
FlexCast
Delivery Technology
FlexCast
delivery technology… Desktop virtualization for everyone. One of the many
marketing term out there. FlexCast offers you several delivery models, one
solution to meet al use cases. It is designed to support all type of workers
(as Citrix likes to call them) out there. For example, Task Workers access a
small set of applications but at the same time they interact with customers,
partners and employees. As a result they have access to critical data. A local
Virtual Machine might be the best solution, here’s where FlexCast comes in.
Another example, so called Road Warriors need access to their desktop from
anywhere, here a Hosted VDI of Hosted Shared desktop might do the trick, again…
FlexCast! Of-course it’s all up to you, you decide which model best suites the
use case at hand! FlexCast offers you the following desktop delivery models:
- Local Virtual Machine
- Streamed VHD
- Hosted VDI
- Hosted Shared
- On-Demand Apps
Here’s
a nice quote from one of the Citrix Blogs written almost four years ago but
still valid “I find that it helps me to think of FlexCast more as a strategy
for delivering desktops, than as a specific technology. It’s about thinking of
all your virtual desktop and application delivery methods as a toolbox that
enable you to directly address the different performance, security,
personalization and mobility requirements of all your users” Nice one right?!
Below is a graphical overview, well… of FlexCast Delivery in combination
with the ICA / HDX protocol.
Conclusion
That’s
it, I hope this has been somewhat informative. If you have any doubt, send mail
to raghu@rjpinfotek.com
Reference materials
used: Citrix.com, Google.com and the E-Docs website.
