Understanding and Designing Presentation Server Farms

Looking for an overview of the various components of a Presentation Server farm? In this Citrix Tech Video, Brian Madden covers the basic architecture of a farm and considerations in building a single zone farm design. (Running time: 18:31 minutes)

Tags: technical video
Views: 3,613
Rating: 5

Transcript : Hello. This is Brian Madden. In this video, we’re going to talk about the design of a Citrix Presentation Server farm. Citrix uses the term server farm to describe a collection of Presentation Servers that are managed together as one single entity. Server farms can vary in size from a single server on a small end to thousands of servers on the large end. Regardless of the size of the farm that’s going into your environment, though, it’s important to understand some basics about how farms are designed, architected, and how they operate. This video will review those basics. Now it’s important to note that this video is only going to cover the basics. So we’re not going to get into the details of large farms or multi WAN-side deployments, or anything like that. But after watching this video, you’ll have an understanding of how Citrix server farms operate. The other important note regarding this video is that complete Citrix Presentation Server environments have many different components. In addition to your Presentation Servers, there are License Servers, there are Web Interface Servers, Citrix Secure Gateway, Farm Metric Servers, Citrix Access Gateways, all sorts of different components. This video itself, however, is just focusing on the architecture of the farm. Future videos will go into the details of these other topics. Now before we get into the details of that, there’s something we should start off with, and that is to look at the Citrix Presentation Server itself. A Citrix Presentation Server is built on top of a Microsoft Windows Terminal Server. And Citrix extends the platform with their Presentation Server product. So throughout this video, when we refer to a Citrix server or a Citrix Presentation Server, we’re talking about a Microsoft Windows Server with Terminal Services enabled that has the Citrix software installed on top of it. That being said, let’s take a look at the design of our farm. Well the first, and potentially most important thing that you need to take into consideration when you’re designing your farm, is you need to think about your applications. Because, after all, the whole point of Presentation Server is to provide your end users with access to your applications. And so it makes sense to think of an application-centric approach. So what you want to think about is your applications, how they’ll be used by users, where your users will be when they use those applications, where the applications are installed on the network, and how they function within your environment. So once you think about the applications, you can think about how your Citrix Presentation Server is going to fit into your existing environment. So to do that, let’s fill out this environment a little bit. And we’ll first look at a central location. Here you can see, in addition to our Citrix Presentation Server, we also have a web server and a database server, and probably some file servers and other things. Of course, most environments may also have remote offices, and these remote offices may have their own servers and their own clients. We may also have users who we’re going to want to provide access to our applications from across the Internet. And those users will probably access our environment via our firewall, and they will connect from hotels and airports and home and all over the place. Well, the real beauty of Citrix’s Presentation Server approach is that all of these users, from all these locations, can access these applications in the exact same way. So we take the Citrix ICA client software, and we can access these applications from the Internet and remote sites and local sites and everywhere, all accessing the same centralized Citrix Presentation Servers. In fact, if I were to jump over here and take a look at a window to two client, we’ll see that there are several different ways we can connect in to our Presentation Server environment. So for example, we could use the traditional Program Neighborhood. This gives our users a local interface that they can use to launch different applications from your Presentation Server farm. We also could use Citrix’s Web Interface. And by logging on here, we see that the applications are presented for the users via a web site. And this allows them to see the same applications that they could see otherwise. Alternately, we could use Citrix’s Program Neighborhood Agent, which puts a little icon in our system tray and allows us to launch the applications via this agent. What’s nice about this agent is it actually has the capability to drop icons onto our Start Menu for us, so that we can have these icons presented to the user in a way that, for them, is very seamless and transparent to the ordinary way that they’re used to seeing applications. The real beauty of what you just saw was that these various access methods can be combined with access from clients in different locations to provide a seamless experience, so that the application that the user is using looks the same no matter where or how they’re connecting to it. But, of course, that’s all based around the central Presentation Servers. The point I want to make, though, is that the server farm you design for your Citrix Presentation Servers will enable all of these access methods and all these access devices. But, of course, this video is really talking about the farm and how the farm is designed. So, to do that, let’s kind of get all the other clutter out of the way and focus just on our Citrix Presentation Server. So the first important thing to know about a Citrix Presentation Server is that it stores all of its configuration information in a database. It does not use the registry or it does not use INI files, like some applications do. Everything is stored in a database. So when the Presentation Server needs to read a setting or needs to see how it’s configured, it contacts that database, and the database sends the information back down to the Presentation Server. Now this drawing, as it is on your screen, represents a logical view of how the Citrix Presentation Server relates to the database. Let’s take a look at how this logical architecture would be designed within your environment. Because, of course, the database—which, by the way, Citrix calls the database the IMA store—but it is, as we said, a centralized configuration database. Well, within your environment, that IMA datastore, it needs to be installed somewhere and loaded somewhere. Well, where do we put that? With Citrix, there’s a lot of choices you can use. A couple examples here, maybe we have that database on an Oracle Server. Or maybe it’s on a SQL Server. Or, and this is very important, we also have the capability to put that Citrix configuration database, that IMA datastore, locally on a Citrix Presentation Server. And that can either be a Microsoft Access database or it can be an MSDE or SQL Server 2005 Desktop Edition database. What’s really important to know is that every single Citrix Presentation Server farm must have a database. Even if you have a single server environment with only one Presentation Server, you still will have that IMA Datastore configuration database. In case you’re wondering why Citrix architected the Presentation Server product so that it stores its configuration information in a database and not locally. Well, the answer to that is because, by storing information in a database, it allows us to build multiple Presentation Servers that all attach to the same database. And in doing so, we can manage all of these together as one single unit. And this, technically, is what Citrix means when they say a server farm. The term server farm means a group of Citrix Presentation Servers that are sharing the same IMA datastore, which is that configuration database, and being managed together as one single unit. And as I said, a server farm may be built of only one single Citrix Presentation Server. Or, of course, a Citrix server farm might have over one thousand servers. It just depends on what your environment is like. Something else that people wonder about this scenario is a couple of the perceived downsides from using a centralized configuration database. One of them has to do with performance. People wonder, if I have to look at all of my configuration information across the network, will that negatively impact performance? The second question people ask about has to do with availability. What happens if there is a network failure, and the centralized database is not available to the individual Citrix Presentation Servers? Will that cause an environmental outage? Well, fortunately, Citrix thought of this when they architected the Presentation Server product. And there’s actually a component that Citrix calls the Local Host Cache. The Local Host Cache is actually a subset of the centralized configuration database that is stored locally, or cached, on each individual Citrix Presentation Server. So what happens is each Presentation Server is able to interact with its own Local Host Cache, and then it only updates the cache from the centralized database as needed. In the event of a centralized configuration database failure, your Citrix server farm will continue to function indefinitely. There’s one other important thing to understand before we leave this slide, and that is that all of the individual Citrix Presentation Servers in your farm will communicate with each other via a protocol that Citrix has, called the IMA protocol. Now, in case you’re wondering, the letters IMA stand for Independent Management Architecture. The name itself is not that important. What’s important for you to know is that the letters IMA represent the backend framework and architecture that Citrix uses to run a Presentation Server environment. This is why, for example, we have the IMA Datastore. The red arrows on the screen represent the IMA protocol. So Citrix has a protocol. It operates on port 2512. And all Citrix Presentation Servers that are sharing the same configuration database, that is all servers that are members of the same farm, will communicate with each other via this IMA protocol. And this is sort of backend overhead communication, and keeping track of users, and servers that are up and down, and things like that. We’ll actually dig into this more as we go through this video. But the next thing we’ll look at is something called the Data Collector. Now the data collector is a very important concept in Citrix Presentation Server farm design. Simply put, the data collector is a role that one server in your farm will perform. What’s nice about the data collector, is that you do not have to configure it. So back when we were talking about the datastore that maintains the configuration information of your servers, that was a database we had to configure. The data collector is a role that one of the servers in your farms will take on automatically. Whenever a Presentation Server is started up, it will communicate with the other servers in the farm via that IMA protocol we saw earlier, and all the servers in the farm will select one of them to act as the data collector. So in this particular case, we see server #3 has been chosen, or elected, to be the data collector. So what’s that mean? Well, the server that is acting as the data collector is a regular Citrix Presentation Server. It’s going to use some of its memory to keep track of what’s going on, on the other servers in the farm. So for instance, the data collector is going to keep track of information, like which users are using which applications on which servers, which servers are online, which are offline, which applications happen to be running on what servers, performance metrics for the servers. The key with this is that the data collector keeps track of dynamic information. So whereas that datastore held the actual hard coded configuration of your servers, the data collector keeps track of all the dynamically and constantly changing status of the servers within your environment. So once one server has been elected to be the data collector, the other servers will use that IMA protocol to send their information. And the data collector can build its own information in memory, so that it knows everything about every server in the farm. So the question is, why do we need to have this data collector? Well, it does a few different things, but the most important is that it helps users connect into sessions within your farm. So for example, you mention a user would like to use an application. And, as we saw earlier, you’ll recall that when users connect into your Citrix environment, they only do request applications. So it’s up to the server farm on the backend to figure out what server is most appropriate for them. So a user decides they would like to launch an application. That request is sent to the data collector. The data collector can then check the information it has in memory about all of the servers in the farm and select which server is most appropriate to run the application for the user who’s just made that request. In this case, we see that is server 4. So now the data collector sends the address of server 4 down to the client device. And then the client is able to establish an ICA session with the appropriate server. Of course, if the data collector did not exist, then there would be no way for new clients to be able to connect, because they would not know which server is most appropriate for them to connect to. And so if the data collector ever does fail, then these servers that are remaining will work together to have a new election to select a new one of them to become the data collector. In this case, we see that is now server 1. So in this case, server 1 will have to build up its own memory to learn what the status is of all the other servers in the environment. So again, we’ll see this information via the IMA protocol. And now we see that the data collector has a good picture of what’s going on within the farm. So now additional clients that want to connect, their request will go to the new data collector, and they’ll select what server is most appropriate for them for the application the want to run. In this case, we see that’s server 2. So the data collector sends the address of server 2 down to the client, and the client establishes an ICA connection with the appropriate server. There’s a few very important takeaways that we need to have from this, and that is that the datastore and the data collector are not the same thing. The datastore is Citrix’s name for the centralized configuration database that physically stores all of the configuration settings for all of the servers in the farm. If you ever lose the database that is acting as your datastore, then you will have to rebuild your farm configuration from scratch. That’s very different than the data collector. The data collector is just one of your regular Citrix Presentation Servers that is a farm member. There’s nothing special about it at all, except for the fact that the various Citrix Presentation Servers you have, have gotten together and chosen that it will be the one that keeps track of all of the dynamic information in the store. But the key is the data collector only has dynamic information. And if that data collector is ever lost, that’s okay, because it’s very easy to rebuild that information, on demand and completely in the background, for a new data collector to be built. So what does this all mean for you? Well, in smaller environments with maybe five or ten servers, you don’t necessarily have to have a SQL or Oracle datastore. Of course, if you already have a SQL Server in your environment, and you can just add a new database to it to be used for your Citrix Presentation Server datastore, that’s great. But if you need to run MSDE or access locally on one of your Citrix Presentation Servers, that’s okay. With regard to the data collector, everything we’ve seen in this video has shown that you have one data collector for your entire farm. Now it’s worth mentioning that it is possible to configure your server farm so that you have multiple data collectors. And you actually break up your Citrix Presentation Servers into multiple groups, and each group uses its own data collector. Citrix calls this zones. This is an interesting concept to keep in the back of your mind, but this is not really necessary unless you have a large farm that is spanning multiple physical sites. So if you have 200 servers in two different offices, you will probably build two zones, one zone for each office, so that each office has its own data collector. But for initial environments and smaller farms, there’s no need to really worry about the data collector at all. It’s more important to understand that it exists, but it’s nothing you have to particularly worry about. So there you have it. Now you understand the basics of how a Citrix Presentation Server communicates with its peers and communicates with its configuration database, called the IMA datastore, and the role of the data collector. You also know the things, like having dedicated datastore database servers and breaking your farm into multiple zones, are concepts that you don’t have to worry about as much for smaller farms. So with that, I thank you for your time today. I want to thank my colleague, Katie Kepke, for creating all of these animations. And happy configuration.

anonymous - Would be nice to see an updated version of this, and expand to show how secure gateways fit into the picture.

anonymous - This was a great presentation. Very helpful information and made very understandable.

anonymous - Good stuff! The nice simple slides and Brian's clear and jargon-free explanations are much appreciated.

anonymous - Awesome Explanation!. Could you create ones incorporating web interface/secure gateway/netscaler. I am having trouble grasping the understanding on how all these work together. Thanks

anonymous - Your presentation made my Interst in Citrix technology. I'll follow your other videos too . Thanks.

abdelli.s - I liked this introduction, great work, thank you.