Application / Server Installation Groups - Citrix MetaFrame XP

You need to think about your strategy for deciding which applications you'll put on which servers.

Now that you understand how application publishing and load management work, you need to think about your strategy for deciding which applications you'll put on which servers.

In smaller environments with only a few applications, you'll probably put all applications on all servers. However, if you have a larger environment you might be faced with a tougher decision; What should you do if you have twenty applications and twenty servers? Do you put one application on each server? Do you put all twenty applications on all twenty servers? Most likely your solution will be a mixed environment, grouping some applications together on some servers and other applications on other servers.

What are the Application Location Options?

When deciding which applications to put on which servers, there are two basic options:

  1. Install a few related applications on each MetaFrame XP server, creating several different server configurations.
  2. Install all applications on all MetaFrame XP servers, creating only one type of server configuration.

Similar to other design options that we've been reviewing in this book, each of these works well in different situations. Let's take a look at each one now.

Option 1. Install A Few Related Applications on Each Server

If your MetaFrame environment has to support a large number of applications, you might choose to install only a few of your applications on each server, even if all the servers are members of the same farm. This will essentially create a server farm made up of multiple groups of load-balanced servers, each group containing a subset of the entire farm's applications. These small groups of servers are called "load-balancing groups" or "silos." (Authors Note: I used to call these "farmlets," but that term didn't catch on. The de facto industry term is "silo.")

All servers from all of the silos can still belong to the same server farm. In fact, the decision as to how you will design your server farms does not change. The application location decision only comes into play after you've decided how you will design your server farms and where your servers will be located. Consider the environment outlined in Figure 4.13 (facing page).\

  • Applications per Server: Word, Excel, PowerPoint, Internet Explorer, Outlook
    • Number of Load-Balanced Servers in the Silo: 60
  • Applications per Server: Data warehouse, Production Line Manager
    • Number of Load-Balanced Servers in the Silo: 10
  • Applications per Server: Research Application
    • Number of Load-Balanced Servers in the Silo: 15
  • Applications per Server: HR Application, Payroll
    • Number of Load-Balanced Servers in the Silo: 4

Figure 4.13: Applications installed on various silos

In this environment, one large server farm of 89 MetaFrame XP servers is broken down into four separate silos. Each silo contains servers that are load-balanced with similar applications. With this design, an update to a payroll application will not affect servers outside of the HR silo. Additionally, application integration and testing time is drastically reduced because there are fewer applications per server to potentially interfere with any new update.

If a user needs to access applications from multiple silos, they will need to establish ICA connections with multiple MetaFrame XP servers. Of course as long as the servers are members of the same server farm, the user will not consume multiple ICA connection licenses.

By limiting each MetaFrame XP server to a few applications, the overall environment is generally easier to support and maintain. This is true for several reasons. First, because only a few (or even only one) application is installed on each server, the chance of applications not being compatible with each other is greatly diminished. Also, fewer applications mean fewer application updates with hotfixes and service packs. In general, the fewer number of applications per server, the more static-and stable-the server can be.

Of course this added stability comes at a price. Because applications are spread across many servers, servers (and applications) are not used as efficiently as they could be. Not only does this mean that more servers could be needed, it also means that servers will most likely be underutilized.

Advantages of Installing a Few Related Applications on Each Server

  • Ease of support. There are no conflicts between applications.
  • Simpler application upgrades. Application version compatibility tests are easier when there are fewer applications that could potentially interfere.
  • More static servers. If application hotfixes are released quarterly, six applications on one server result in new server code every other week.

Disadvantages of Installing a Few Related Applications on Each Server

  • Higher Cost. More servers are needed.
  • Potentially under-utilized servers.

Option 2. Install All Applications on All Servers

Alternatively, you could choose to configure your MetaFrame XP servers to be 100% identical. This would mean that you install all of your applications onto all of your servers. If there are a total of five applications in a server farm, then every server in the farm would run all five applications.

There are several benefits to doing this. Users who access multiple applications only need to connect to one server. Greater economies of scale can be realized since every user can be crammed onto a few servers. No user has any reason not to do everything on one server. Certain aspects of this environment could make it easier to manage, especially since all the servers are configured the same.

Unfortunately, deploying each application to every server is not always feasible. This can cause complex application upgrades because many applications on one server increases the chance that there will be some incompatibilities. Also, the MetaFrame XP servers will need to be taken out of service frequently due to the large number of applications on each server and the inevitability that there will always be something that will need to be updated. Finally, installing all applications on every server will not allow your environment to realistically grow any larger than a few dozen applications.

Advantages of Putting All Applications on All Servers

  • Better economies of scale.
  • Fewer servers.
  • All servers can be 100% identical.

Disadvantages of Putting All Applications on All Servers

  • Extremely complex application upgrades.
  • Frequent server servicing.
  • Constantly changing server environment.
  • You need to install one application many times.
  • Difficult to troubleshoot.
  • Not realistic in large environments.

Considerations when Deciding where to Install Applications

Unfortunately, the decision as to which MetaFrame servers you'll use for each application can be complex. The good aspect of this complexity is that while there are many issues to consider, each issue on its own is relatively simple solve.

To understand these issues, ask the following questions about each application:

  • Who owns and maintains the application?
  • How often is the application updated (including new versions, service packs, and hotfixes)? How long does this take?
  • Can this application be grouped with others into a logical family (such as Microsoft Word and Excel)?
  • How much server power does the application require?
  • What is the total number of applications that you have?
  • What type of server hardware do you have?

Application Ownership

If certain groups of applications are owned or maintained by the same groups of administrators, then it makes sense to keep all of their applications together on the same servers. That way, each department only has to deal with their own applications. However, if all of the applications are supported by one large group of administrators (i.e. you), then this is not a factor.

Application Complexity

Applications that are updated frequently should be kept away from applications that are almost never updated. For example, imagine that you have two applications each hosted by two servers. Application A is updated every other week, and application B is updated quarterly. If you publish both applications to all four servers then you will need to touch and update all four servers every other week. However, if you limit each application to two servers then you will only need to update the two servers for application A every other week.

Application Groups

If you have certain groups of applications that are used by the same groups of users, it might make sense to confine them to selected servers. Many companies keep all applications specific to a department on MetaFrame XP servers separate from those that host company-wide applications.

Server Resources Needed

If you have many applications that require significant server power, it may not be possible (or economical) to put them on the same server as other applications that also have high resource requirements.

Number of Applications

The more applications you have, the more likely it is that you will need to put specific applications on specific servers. If you only have three applications, you can afford to put them all on each server. However, if you have one hundred applications, there is no way that you would put them all on every MetaFrame server.

Server Hardware

The type of server hardware you have (or plan to have) will also help you decide whether you should put all applications on all servers or whether you should divide your farm in silos. Obviously, if you have six quad-processor servers then your application installation options would be a bit different than if you had twenty single-processor servers. A full analysis of server hardware and server sizing as it relates to your application and farm design is covered in Chapter 6.

 

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close