Presentation Server Farm Design - Citrix Presentation Server 4.5 Book - BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.

Presentation Server Farm Design

Written on Nov 08 2007 20,057 views, 3 comments


by Brian Madden

A lot of people commonly think of a Citrix Presentation Server “farm” the same way they think about a Windows domain. They think of a farm as a group of servers managed as a single unit with common users, applications, and security. This is the way I used to think too. I don't anymore. In today's versions of Presentation Server (say, CPS 3 and newer), a Citrix Presentation Server “farm” is not as much about shared management as it is about a shared database. (An “IMA Data Store,” to be exact.)

One database = one farm. Period.

If you have a single Presentation Server storing its configuration information in an SQL Express database running locally, that's your farm. If you have two servers sharing a configuration database running on SQL, there's your farm. And if you have 1500 servers sharing one (really big and fully redundant) configuration database, there's your farm.

From the design standpoint, if you only have one Presentation Server, your farm design is simple: you have one farm. But as soon as you add a second server to your mix you have a decision to make: One farm (both servers sharing the same configuration database) or two farms (each server using its own configuration database).

So what will it be? One farm or two?

In the old days (the days of MetaFrame XP, like, in 2001/2002), farm design was simple. Why? Because farms were not flexible at all. Licensing was farm-wide. Administration was farm-wide. Load balancing was farm-wide. Citrix made decision of whether to have one farm or multiple farms for you due to the inflexibility of their products!

Customers complained and Citrix listened. Hooray! Now we can choose whether we license on a farm-wide basis or not. Now we can choose whether we configure administration farm-wide or not. Now we can choose whether we load-balance farm-wide or not. We can choose… we can choose… we can choose! Great! Except what do you think that means for design complexity? Where before we had zero choices to make, we now have several. (Don't get me wrong. The evolution of the farm is awesome! It's just that now we have a lot more work to do at design time.)

Here's a good analogy. New cars come in lots of colors. Before we buy a new car, we fret and think and worry about the color. We argue with our spouses. 100 years ago cars came in one color-black. That means that car color decision-making has actually gotten harder in the last 100 years! While no one is suggesting that all new cars should be black today, it's easy to see how more choice leads to a tougher design process.

What are the server farm design options?

When thinking about your CPS farm layout, there are really two choices:

  • Build large farms that include CPS servers from multiple geographic areas
  • Build multiple small farms, each including a single group of CPS servers.

Note that the “geographic area” referred to here relates to geographic area of the CPS servers only, which is why we design the server farm after we decide where we're going to put the CPS servers. If you have users all over the country, but you've decided that all the Presentation Servers will be in one location, then that would be considered a single “geographic area,” with regards to server farm design.

Another important note is that the whole “one farm” versus “multiple farms” is that this is just a way of characterizing this specific design issue. This decision point just could as easily been called “fewer farms” versus “more farms.”

Really you just need to look at your servers one-by-one. Start with the first server. That's Farm 1. Then look at Server 2. Should that go in it's own farm, or be added to the same farm as the first server? Then look at Server 3. Can that be in the same farm as Server 1 or Server 2? If not, then put it in it's own farm.

The bottom line though, especially with these new versions of Presentation Server, is that you don't need to break your environment into multiple farms unless you have a specific reason to. There are plenty of production farms in the world with over 1,000 servers.

Farm design strategy

Remember that this chapter proceeds in order, so you should design you server farm boundaries only after you've decided where you're going to put your Presentation Servers. The decision to create one all-encompassing server farm or several smaller server farms impacts several areas in your environment, specifically:

  • Ease of site-to-site failover
  • Network bandwidth usage
  • Ease of management
  • Management scope

Ease of site-to-site failover

If you would like to have one group of servers that automatically is used at a secondary site if your primary servers go down, then putting servers from both locations into the same farm makes that task much easier. (We'll go into the details in the chapter about high availability later in the book.)

Network Bandwidth Usage / WAN Usage

CPS servers in the same farm, by definition, share the same configuration database. Therefore if you have servers in the same farm on different sides of a WAN link, there must be some level of network communication between those servers. (We'll look into the specifics of this in the next two sections.) For now, just know that if you have multiple and you don't want any WAN traffic, you'll need multiple farms.

Ease of Management

The Java-based Presentation Server management console can only connect to one farm at a time. Even though Citrix has moved much of the day-to-day tasks over to the MMC-based Access Management Console, you will have to run multiple simultaneous Java consoles if you want to manage multiple farms.

Management Scope

Remember that two Presentation Servers “in the same farm” means that they're sharing the same configuration database. While Citrix has moved all the configuration settings into “policies” instead of “farm-wide” that they can, there are still some settings that can only be set on a farm-wide basis. If you want to create one big farm, take a look through the management console at the farm-wide settings to make sure these settings will not have to be unique per-server in your environment. (Access Management Console | Presentation Server | Right-click on Farm Name | Properties)

All of the CPS servers in one farm can be managed together. They are managed via the same tool, and many security and configuration settings are configured on a farm-wide basis. CPS servers that belong to different farms must be managed separately. Applications cannot be load-balanced across servers in different server farms (although users can simultaneously run sessions on CPS servers that are members of different farms).

 
 




Our Books


Comments

John Radcliffe wrote Feedback now or later?
on Wed, Nov 21 2007 8:08 AM Link To This Comment
Brian,  do you want our feedback on your book content here?   Do you want feedback on typos, etc here?  or save it for later?
Guest wrote Just print the friggin' book
on Tue, Feb 5 2008 11:08 AM Link To This Comment

I take the lack of response from Brian as "I really don't give a ***".  One chapter???  After all these months?  And we're just supposed to keep coming back here, clicking on your ads, and paying for your training classes like a bunch of idiots. 

Just print the friggin' book!!!

Brian Madden wrote Re: Just print the friggin' book
on Wed, Feb 6 2008 10:01 AM Link To This Comment
Man, I've written like 50 1000+ word original articles since this chapter came out. If you're not interested in that content, then just subscribe to this book's RSS feed. Then you'll be notified when new stuff is posted. You don't have to click on the ads or come to the training classes if you don't want to.

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.