Application Server Installation Groups | Terminal Services for Microsoft Windows Server 2003: Advanced Technical Design Guide (Advanced Technical Design Guide series)

Application / Server Installation Groups

Now is the time to think about your strategy for deciding which applications to put on which servers.

In smaller environments with few applications, you'll likely put all applications on all servers. In 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 to create 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 three basic options:

Install a few related applications on each Terminal Server (or set of Terminal Servers), creating several different server configurations.
Install all applications on all Terminal Servers, creating only one type of server configuration.
Use a third-party application management tool that "virtualizes" all applications.

Similar to other design options we've reviewed thus far, each of these options works well in different situations.

Option 1. Put All Applications on All Servers

Your first option is to configure your Terminal Servers to be identical, meaning that you install all applications onto all 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 other benefits to choosing this course. 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 one of a few servers. No user has any reason not to do everything on one server. Aspects of this environment make it easier to manage, especially since all the servers are configured the same.

In this case, ease of management may come at the expense of complexity. The more applications installed on your system the better the chance of encountering application conflicts. Going with this type of arrangement also increases the amount of regression testing that will have to be done every time an application is installed or updated. And finally, poorly performing or conflicting applications would not be segregated to separate servers, limiting your scalability.

Advantagzes of Putting All Applications on All Servers

Better economies of scale.
Fewer servers.
All servers can be 100% identical.
Less-likely to hit Windows 2003's built-n 32-node load-balancing limit.

Disadvantages of Putting All Applications on All Servers

Extremely complex application upgrades.
Frequent server servicing.
Constantly changing server environment.
Limited scalability.
More difficult to troubleshoot.
Not realistic in large environments.

Option 2. Install a Few Related Applications on Each Server.

If your Terminal Server environment has to support a large number of applications, you might choose to install only a few applications on each server, even if all servers are members of the same cluster. This design essentially creates multiple groups of load-balanced servers, each containing a subset of applications. Such small groups of servers are called "load-balancing groups" or "silos."

The decision already made about the placement of your servers (as discussed in Chapter 3) should not change. The application location decision comes into play only after you've decided where the servers need to reside. Of course, the ability to load balance a set of servers is generally limited within the TCP/IP subnet, affecting your application location decisions. Consider the environment outlined in Figure 5.1.

Applications per Server	Number of Load-Balanced Servers in the Silo

Word Excel PowerPoint Internet Explorer Outlook	60
Data warehouse Production Line Manager	10
Research Application	15
HR Application Payroll	4

Figure 5.1: Applications installed on various silos

The 89 Terminal Servers depicted here are 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 reduced as there are fewer applications per server to potentially interfere with any new update.

If a user needs to access applications from multiple silos, he will need to establish RDP connections with multiple Terminal servers. Of course, if the user is using a thin-client device he will have to connect to two separate servers or establish another RDP session from within his remote desktop.

By limiting each Terminal server to a few applications, the overall environment is generally easier to support and maintain. This is true for several reasons. First, since only a few (or even only one) applications are installed on each server, the chance of applications not being compatible with each other is 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.

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 might more servers be needed, but those servers will most likely be underutilized. Plus, in order to use the session directory components of Windows Server 2003 (discussed in Chapter 7), you'll have to run the "Enterprise" version of Windows. This version is much more expensive than the standard version, an expense that is magnified in designs that call for many servers.

Advantages of Installing a Few 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.
Application silos can be split among geographic locations
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 Applications on Each Server

Higher Cost. More servers are needed.
Thin client users may not have access to all applications within their "desktop".
Potentially underutilized servers.

Option 3. Use a Third-Party Application Management Tool

There is a basic problem with installing many applications on a single server. The applications will conflict with each other since they must first be installed before they can be used. Often the installation process causes common or conflicting components to overwrite each other.

A unique third-party solution is contained in a product called "SoftGrid" from Softricity (www.softricity.com). SoftGrid is an application deployment and management solution. The basic concept behind SoftGrid is to isolate an application in its own virtual environment within the user's session. This virtual environment contains all the information (registry information, INI files, program files, etc.) that the application needs to run. When SoftGrid is used, the application is never actually installed on the Terminal Server. Instead, it's run out of a cache it receives from the SoftGrid server.

Softricity's application virtualization is a simple. Imagine that you could run an application on your desktop without ever having installed it. Unlike using Citrix or Terminal Services to connect to it from a client workstation, the application would execute locally using local resources such as the processor, memory, disk, and network card. Conceptually, this approach is similar to running applications from the network (which was popular several years ago), except that SoftGrid emulates the registry and other critical functions so that the applications think and act as if they're running locally.

In addition to avoiding application installations, SoftGrid also gives you the ability to run multiple versions of the same application on one machine. These virtualized applications are isolated from each other in their own virtual environments, each containing the files and registry settings necessary to allow the application to run without ever having to be installed on the client. The application interacts with the local computer and uses the local system as its base just as any other application, except that the virtualized application is not allowed to change the local file system or registry.

The application executes on the local machine (the Terminal Server in this case) using the local machine's resources, but is not allowed to modify the machine. Instead, it runs in a small virtual environment that contains the registry entries and files that it needs to execute. This virtual environment acts as a layer between the application and the operating system. This layer is very "light" (generally a couple of MB of memory) and loads just prior to the application loading.

While this is a high-level overview of how an application executes in a SoftGrid environment, there is obviously much more to this product. Additional benefits you will see when using Softricity's SoftGrid include:

Advantages of Softricity SoftGrid

Ability to run conflicting applications on a single system.
No application regression testing is needed when deploying new applications.
You can usually reduce the overall number of Terminal Servers since you won't waste resources in as many clusters or silos.
Instant provisioning of applications to Terminal Servers.
Reduced cost in application management.
Reduced costs in application troubleshooting.

Disadvantages of Softricity SoftGrid

You have to pay for SoftGrid on top of your Microsoft and application licenses.
It's an additional layer of software to manage.
Overkill for small environments with only a few applications.
It's one more thing to learn (or one more consultant to hire).

Considerations when Deciding where to Install Applications

A silver-lining to all this apparent complexity is that while there are many issues to consider, each issue on its own is relatively simple solve.

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)?
Where are the servers going to be located?
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 them together on the same servers. That way, each department only has to deal with its own applications. However, if all applications in your environment are supported by one large group of administrators, then this is not a factor.

Application Complexity

Applications that are updated frequently should be kept away from applications that are almost never updated. 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. But if you limit each application to two servers, then you will only need to update those 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 Terminal Servers separate from those that host company-wide applications.

Server Location

If you've decided to locate the servers close to their data resulting in the spread of servers across multiple locations, you will need multiple silos due to the broadcast domain limitation of Microsoft's Network Load Balancing (discussed fully in Chapter 7). Even if this were not an issue due to a third-party load balancer, would you really want to load balance across different locations with the data in only one of them?

Server Resources Needed

If many applications require significant server power, it may not be possible (or economical) to put them on the same server as other applications with 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. With three applications, you can efficiently put all on each server. However, with one hundred applications, there is no way that you would put all on every server.

Server Hardware

The type of server hardware you have (or plan to have) will also help you decide whether to put all applications on all servers or to divide your farm in silos. With six quad-processor servers, your application installation options would be different from having twenty single-processor servers.

Silo Design in the Real World

In most environments, your decision to create a new silo may have to take into account factors that are not listed above. These other factors are not always technical and can include internal political pressures, pressures to segregate applications that don't have to be, or the need (or imagined need) to segregate a mission critical application. Often companies will go to one extreme or the other. Some will wind up segregating every application or application suite onto different servers with an end result of having too many little environments to manage. Or they will try to install every application into one silo creating a nightmare for themselves as the environment grows and applications continue to be added.

Most designs generally begin with a primary application silo consisting of applications needed by a majority of users. These applications should all be well performing, not conflict with each other, and (of course) not change often. This reduces the amount of changes and possible problems within this silo.

Secondary silos are typically added once the primary silo is up and running. Secondary silos contain applications that conflict with the primary applications, change often, or are extremely resource-intensive. By segregating these applications from the primary silo you ensure that the applications with the largest user base are at a reduced risk for problems.

Generally, the split between these two silos follows the good old fashioned "80/20" rule, where applications that 80% of your users use will be installed in the primary silo and the remaining 20% will be installed in secondary silos. Obviously, this is not a hard and fast rule. Your environment may require a 60/40 split due to a large number of misbehaving or frequently changing applications. Your priority should be to keep it as simple as possible so as to reduce the risk of application problems.

As a final thought, remember that your silo design can have a lot to do with the way your users will be accessing the system. If you have a percentage of users that will require a Terminal Server desktop then you will most likely have a primary silo to support these connections. The opposite also applies. If you're going to host only a few applications and these will be connected to via initial program connections, then a primary silo may not be required.